Neustro

Above the planning board in the sales office of one of our customers is a sign that says ‘Failing to Plan is Planning to Fail’. Although we do come across a few customers, when undertaking our business process reengineering projects, that don’t plan at all, it is the rare exception. The truth is that there are a number of business that believe that they plan well but make it hard work for themselves by not utilising properly the business systems that they have – but there are a few that have too much planning going on. To see what I mean by this take a look at my whitepaper ‘Too much planning hurts your business’ at our free downloads website section.

The most common issue we find is customers who have implemented ERP but then, over time, begin to ignore what it is telling them. Rather than address the issues that are making the output from MRP ‘wrong’ they spend a great deal of time, effort and sometimes money on producing reports or developing stupendous spreadsheets that will give them the data they need to plan correctly (but it doesn’t).

During our BPR and ERP optimisation projects we spend time with each department and discuss the challenges they are facing. Regularly we sit down with purchasing and we meet a harassed purchasing manager and frazzled purchasing clerks who are at their wits end because they simply do not have enough time in their days to handle the workload. What do we hear? It’s often these expressions;

‘The output from MRP is wrong...’

‘We have had to develop our own reports to ignore the bad output...’

‘We download the MRP output to Excel and then manipulate it to come up with some sort of reasonable purchasing plan...’

‘If we bought in everything MRP was suggesting we’d need five more warehouses!’

‘Although we have got too much inventory it’s never the right stuff...’ etc

I’ve yet to come across an ERP systems’ MRP programme that doesn’t basically work in the same way – looks at all demand and then produces suggestions that can then be confirmed into purchase orders. It will also make suggestions for orders to be cancelled, brought forward, moved back, increased or decreased. OK, some MRP can be quite crude and simply aggregate all demand whereas others can have sophisticated order pegging that allows you to see where the demand is coming from. But overall, they do pretty much the same thing. At the end of the day it’s nothing more than a calculation.

What has often happened is that there has been a lack of housekeeping on the ERP and there are backorders that have been ignored, or production orders with back-flushed items have not been completed, receipts of goods inwards have not been carried out in a timely fashion – amongst a number of other things.

We also find that blanket policies may have been put in place – for instance all lead times on all items set at a standard number of weeks. Sometimes we see safety time added to every item from every supplier.

In these situations it is absolutely obvious why the output from MRP is as it is – the data that all the calculations are based on is garbage.... and if it’s garbage in it is highly unlikely that anything sensible will come out.

Rather than address the underlying issues with the data people begin to develop their own suite of reports – these will try to ignore some of the output as it is known that this is ‘wrong’. Sometimes people will have all the MRP output shipped out to a spreadsheet where highly developed macros and code will mash the data and make it ‘sensible’.

Sadly, it doesn’t. What really happens is that things turn up too late, some turn up too early and some don’t appear at all.  Production and warehousing start beating up purchasing and purchasing respond by employing more people. Soon there is a whole department focussed on expediting orders rather than negotiating deals and forming long term relationships with suppliers.

The reality is that the best way to address the issues is to get in there and tidy up all the data – make it sensible in terms of lead times etc and educate the other departments about the need to housekeep their data too.

On a few occasions we have helped customers get a few more years out of their existing ERP system rather than move or upgrade to a new one by helping them ‘sort out’ MRP.

So if you have a purchasing department that has a larger than expected headcount yet they can’t seem to get the suppliers to deliver on time then ask them what they are using to plan....

Q. What turns old, underused, disliked ERP software into the best ERP package ever written?

 A. New ERP software.

I’ve implemented ERP into dozens of businesses over hundreds of sites. I’ve also picked up and tried to fix problem implementations which have come to me by way of acquisition. The one thing that I have witnessed over the years is however much the users disliked their old system and criticised it during the selection of the new ERP, they soon would be lauding its use-ability and proficiency once they were in the process of going live with a new system.

You may often hear that the old system did this in such a way or that you can’t find information on the new system like you can on the old one – a series of complaints that undermine confidence in the new system and can quickly send users scurrying to the old ERP to look for data.

Why does this happen? I’d like to suggest a few reasons – some which are easy to address (in theory) and some that is about preparing your team of users for the new world of their new ERP.

Firstly, no matter how much training that you do it is likely to not be enough! But you must try…

Secondly, the training should not only cover the easy day to day stuff but must include some of the most frequent infrequent events…. What? By this I mean the users will soon become familiar with the regular tasks such as entering orders if there is a high volume. The challenge is ensuring that you identify the events that are not everyday occurrences such as sales returns or the process surrounding mis-delivery.  If you can prepare the users and give them confidence in how they will deal with the infrequent events then they will not complain that they have to rely on a key member of the project team or even a consultant to do in the new system what they could easily do their old one.

 An important thing is ensuring that people understand the overall business process that is being catered for in the software. When people understand the impact of errors on other departments and their colleagues’ workload they are more likely to take additional care when they understand ….

Finally do remember that when people are facing change they do get very nervous. The chances are that they have been using their old system for a number of years and they are very likely experts in that system. It gives them some security (whether real or imagined) about their importance to the company and increases their self esteem. By giving them the new ERP they may suddenly feel very vulnerable and worry that if they can’t master the new system they may be at risk of losing their jobs. Some reassuring words when they ask for the umpteenth time how to complete a form or print a report can certainly help sooth frazzled nerves.

One idea is to give each person in the department a particular responsibility to learn a single ‘infrequent’ process and be master of it. This will address two issues at once. First you will have an expert that colleagues can turn to when such an event occurs and two, you will make each person feel that they have key knowledge that makes them important to the success of the implementation.

Then maybe the new ERP may be the best system they’ve ever used...

Sometimes I sit here in front of the computer gathering my thoughts for another blog and I wonder if anyone is really interested. Well, clearly they are, as a few people have noticed I’ve not posted for a while and dropped me a line to see if I’m alright and when I’m due to post again. Well folks, thanks for your concern and more importantly for your interest.

The reason for the gap in blogs is that we were preparing and then exhibiting at the PPMA show at the NEC in Birmingham. You may recall that we have been appointed as a Partner to Shoplogix – and we were taking the show at the NEC as an opportunity to launch the product properly here in the UK.

As a business we have deep experience in delivering ERP – particularly Infor ERP LN / Baan and Microsoft Dynamics AX / Axapta but we took the Shoplogix product line on as it is absolutely suited to our target market of manufacturing companies.

If you take a look at our Shoplogix webpage you’ll see all about the product there. In short, if you haven’t read any of my previous blogs (and it still surprises me when you do) , (by the way, say hello) Plantnode by Shoplogix is a device that collects data on the status of your production machinery and allows your operators to collect data in real-time so you can improve efficiency.

Anyway we were at the NEC with my now famous Rolling Ball Sculpture which is what I use to simulate a machine (see the Video on Youtube!) and we had a great deal of interest.

I’ve been around ERP and senior IT management for a long time and I know how difficult it is to put a business case together for a serious investment in either large infrastructure projects or complex business systems. What is refreshing about the Shoplogix Plantnode product is that I can draw up a business case in a matter of minutes – it can deliver real improvement in performance and it’s easily quantifiable and I can demonstrate a rapid return on investment (ROI) within minutes.

Having spent years either justifying ERP or auditing other people’s business cases it’s a refreshing change when the document can be so concise. No calculating transaction value or cost to raise a purchase order required.... (though, I do enjoy the intellectual thrust of that).

On a couple of occasions last week I was also able to change some businesses view with a couple of focussed questions – which in the world of ERP I don’t think would simply be possible.

One person suggested that the Shoplogix product was perhaps too expensive for them. Not knowing the price this was quite an assumption – and he was certainly pleasantly surprised when told. The question I asked was ‘Why are you at the show?’ and the answer was (and a likely and probable answer given that is was a packaging and processing machinery show) that they were looking to buy another production line. I asked if they were happy with the efficiency of their current lines – and they said they couldn’t be sure because they didn’t know how efficient, or not, they were now. I have persuaded them to delay a significant investment into a new line until they have established this with a relatively low investment into a Shoplogix Plantnode unit. Likewise a company that was considering moving to two shifts is deploying Plantnode to see if they really need to do this. We reckon that we can improve their OEE from the region of 60% to, a still not World class, 75% which will allow them to delay a second shift by somewhere around 12 months.  A considerable saving and return on their investment.

 If only ERP were so easy to justify!

The main focus of our business is offering consultancy and support for Microsoft Dynamics AX and Infor Baan ERP LN. However, because we also offer support for all the IT for a business we are frequently approached to provide pure IT support too. A recent visit to a potential customer put me in mind of one of my favourite books and radio series; The Hitchhikers Guide to the Galaxy (I don’t rate the film much though). Among the many wonderful ideas was the ‘Peril Sensitive Sunglasses’. These are designed to help people develop a relaxed attitude to danger. At the first hint of trouble they totally black and thus prevent you from seeing anything that might alarm you.

 I suspect the glasses the potential customer I was visiting was wearing are similar to those that become progressively darker the brighter the sun gets – or in this case darker the greater the danger.

Let me explain. This was quite a successful business that is providing a software product to a niche market. It has obviously performed very well as it has grown quite quickly and has a good number of customers and 40 odd employees. We had been called in to review their support arrangements after they had suffered a small disaster when a server went down. Being a software house full of people who work with computers for a living they managed to scramble through and restore their system but they realised that it wasn’t a core skill and that they should call in external resource to help them rationalise and care for their systems. I think they deserve a lot of credit for this because software houses with rooms full of techies (and I want you to know some of my best friends are techies) would naturally continue to try and do it all themselves. No, they had made the sensible decision to outsource this and concentrate on what they do best – develop software.

Anyway, we turned up on site to see how we could help. After introductions we took a tour around the facility. Whilst our guide was almost wholly focussed on the number of servers and the inconvenience they might cause if they stopped working I was dealing with the fact that there were, firstly, so many servers at all, and secondly that they were in a uniquely vulnerable situation.

The building is two storeys and had, to my mind, very little security. The windows were single glazed and top hinged allowing anyone who gained access to have plenty of space to pass the equipment through the window. Yes, it had an alarm system and CCTV, but all that would allow for is to be able to watch a grainy video on how efficient the burglars were before the police arrived.

Many of the servers were in full view and a simple walk around the building, at night, would have given anybody planning a break-in plenty of time to work out their plan of action.

The servers contained the development software of the company at different stages, and in a couple of cases were actually running a customers live e-commerce site!

The odd thing to me was that it was the first thing that I saw in terms of risk to the business – I felt very uncomfortable that a single break in could put them out of business for a least a week and could put one of their customers out of business too. It would be the sort of event that could actually lead to the business closing down and people losing their jobs.

Importantly, it was something that could be easily improved – simply moving the servers to the first floor, out of sight, would take the temptation away from any opportunistic thieves. I pointed out that this was perhaps the greatest danger that they faced right now and that losing a server to a technical fault would have a lesser impact.

It was as though the owner of the business had just taken off his ‘peril sensitive sunglasses’ and could suddenly see the risk he was running – it was just that it had sort of crept up on him.

Anyway, we proposed a number of ideas and solutions that would solve the problem anyway through our managed services, co-location and virtualisation offerings and in the meantime we have simply moved all the servers out of sight.

Because they got to where they were through steady growth and adding new servers here or there they just hadn’t seen the danger creeping up on them. I’d recommend on a regular basis that you take off your peril sensitive sunglasses and see what is creeping up on you.

I’m always wary of writing about experiences I’ve recently had in my business dealings for fear that I may offend someone and that an ongoing piece of work may be compromised.

However, I think on this occasion there is no danger that the person will read this blog, and even if they did, what they read wouldn’t bother them anyway.

I was asked by an old friend to have a meeting with the owner of a small successful company. She had looked at his business systems and suggested that he really needed to get an expert in to give him some advice as to what to do. My default position on business systems is to look at ERP first and then Best of Breed second – you’ll find a white paper about my views on ERP v BOB here.

Anyway, I sat down with the owner of the business and he told me about his current business system – he had developed it himself entirely in Microsoft Access. It soon became clear that he understood his business very well indeed and that the Access ‘business system’ he had written was entirely tailored to his needs. Except that his needs seemed to be changing every day. He is spending hours each day changing and tinkering with his system. He insisted to me that an ‘off the shelf’ package just wouldn’t suit his needs.  

Before I go any further I need to repeat some of the expressions that he used during our meeting;

“I get frustrated because no-one else here knows how to use the system”

“Every time someone needs a report I need to get into the system and write it – no one does it themselves”

It was clear that he didn’t have any user instructions – he didn’t have the time to write them, but it seems unfair to me that he blames other people for this!

His solution is to get a local VB programmer to take his Access application and turn it into ‘A proper system’. Recognising that I was perhaps not ever going to convince him to invest in a packaged solution I tried to give him some good advice (for free) on how best to approach this.

I suggested that rather than just hand over the Access database as it was he might be better to take some time to put together a requirements specification listing the functionality his business needed to run. Then he should consider turning this into a functional specification to give the programmers some insight as to what is required – a good business analyst would be able to help them produce this functional specification and also bring some external knowledge of how a business system generally works. Although this is the type of work that we do as a business I was reaching the conclusion that I wasn’t likely to be doing this with him.

The reason I came to this way of thinking was that he explained to me that he had tried on two previous occasions to have his business system ‘written properly’ and on both occasions (costing a sum of around £30,000) he had halted the project because the programmer ‘just didn’t understand what I needed’. I reiterated the importance of the approach I outlined but he wouldn’t take it on board at all – he insisted that handing over his database was specification enough.

Finally, I suggested that at the very least he should view a couple of packaged solutions – not because he should consider buying them but simply to see what they do, how they do it and why. This would, I suggested, give him some ideas on how his system should perform.

His response to this was that he just couldn’t sit through software demonstrations because he became bored with them and switched off after a few minutes.

So, in summary, he wouldn’t consider a packaged solution. He complained that no-one understood the solution he had written himself. He’d had two previous attempts to write the solution ‘professionally’ but had aborted them. He couldn’t be bothered to write any specifications. He couldn’t be bothered to look ‘for reference’ at any other business packages.

I occasionally you meet people that you just can’t help – this was genuinely one of them. I’d have been better banging my head against a brick wall.

I wrote in a previous blog that we have become a partner to Shoplogix to implement their product Plantnode. The best way to describe it is as a ‘device’ that captures machine performance data and presents it in via the web through an outstanding user interface.

As a business we very much like to row our own boat and only enter into channel partnerships it we believe we can do them justice – we don’t collect logos as trophies to put on our website. It’s testament therefore to the quality and usefulness of the Plantnode product that we are fully committed to promoting it.

All manufacturing companies right now are looking to improve their performance and Plantnode reveals ‘machine truth’ by attaching sensors to the machine and collecting data automatically. If you are involved, or have ever been involved, in data collection that is manual for operational improvement activities then you will know that the greatest barrier to improvement is the veracity of the data. With manual data collection the machine operators are often relying on memory to record the job data such as set-up time and run time. They almost certainly record the ‘big stops’ that prevents the machine running but not the ‘little stops’ – and this is an area that can be attacked to improve OEE. Automated data collection overcomes this by recording when the machine is running or not and allowing the operator, through a simple barcode scan, to record the reason for the downtime. With Plantnode alerts can be sent via email or SMS so if a particular event requires an engineer the scan will prompt a rapid response.

Having been an IT Director for a major packaging company the stand out thing about Plantnode that I really appreciate is the ease of implantation for the IT department. I well recall the multitude of demands coming from the business regarding ‘systems’ required that were often ill thought out or simply resource hungry. I was often in the position whereby I was defending the fact that we didn’t have the people available to give support to ‘business initiatives’ whilst also coming under attack for not cutting my costs. If ever there was a rock and a hard place this is it. Anyway, a Plantnode implementation for the IT department consists of providing an Ethernet connection (so it’s on your network and the interface can be presented through a web browser) and a VPN connection (to allow remote support). This is as light as it gets and you, as an IT ‘bod’, get the credit for helping the business!

I have the pleasure of demonstrating Plantnode to prospective users and when I was contemplating how best to do this in the early days I thought it would be good to give a ‘live’ demonstration on a real piece of ‘machinery’. I spent some time thinking about the best way to do this and eventually came up with the idea of a marble run. This works a treat in that I take a small marble run into the demonstration, connect it to Plantnode, and then start and stop the machine, record the downtime reasons and show in real-time the benefit of automated data collection. Mind you, it took a few days before I alighted on the idea of a marble run. There were a couple of false starts – a handheld fan for instance (too boring) a Lego Mindstorm machine (too noisy). Looking for inspiration I typed ‘adult’ and ‘toys’ into my favourite search engine and was about to press enter when my subconscious interrupted and saved me from huge embarrassment by suggesting the marble run.

At the end of September we are going to be demonstrating Plantnode at the PPMA show at the NEC in the UK. I’ve gone one further than my marble run and commissioned a work of art – it’s a rolling ball sculpture that will, I think, show off Plantnode at its best whilst also being a great deal of fun. There is a video of the rolling ball sculpture on Youtube – take a look.

If you are coming to the NEC in Birmingham for the show then come and see it live – and introduce yourself – I’d be delighted to meet you.

The idea of CRM has always appealed to me. The concept that you could look at all your interactions with a customer and then discuss what has been happening with apparent authority does, I believe, enhance the customer relationship.

Of course the ability to mine the CRM system and locate prospects for new products and services is also incredibly useful.

My first experience of a CRM system (though it was called a ‘Customer follow up System’ then) was back in 1985 when I implemented it at a BMW car franchise. Of course back in those days the idea of a PC or terminal on every desk was fanciful because of the cost implications.

Moreover, it was not a particularly user friendly application. It was a green screen text based interface and asking a group of guys who were focussed on selling high speed motors to use (probably for the first time in their lives) a keyboard was a step too far.

The deployment was simply printing out reams of paper each day with their ‘to-do’ list activities and people to follow up, and then collecting the papers back, after much chiding, so the their scribbles could then be deciphered and manually input into the system.

The great thing was that the service and parts departments were also on the system so the salesman could talk about the last service or the new radio they had had fitted recently. Mind you, occasionally the customer would get upset because their car was in for service on the very day they were being called (and had just been presented with a huge bill) – but that was the only draw back of the system.

Remarkably this was a major step forward in terms of customer relationship management and certainly did produce an increase in sales because of improved customer loyalty. It was quite unusual for car salesman to call you to ask how you were!

Of course nowadays CRM is a great deal easier to use. For instance, Microsoft Dynamics CRM is so familiar with its ‘Outlook’ and ‘Office’ look and feel that the effort in training is minimal (relatively!).

I guess another significant difference is the ability to customise CRM to meet you precise needs. I think I would have given a used car salesman’s  right arm for the ability to easily add a few fields here and there rather than compromise and use fields that were ‘spare’ (at that time).

I suppose that the only thing that does surprise me is that almost 25 years after I completed my first implementation of a CRM system that there are quite so many companies who still don’t use one. Particularly considering the ability to start at a low cost through hosted services or even buy outright for a few users.

Interestingly, even the franchise that sold me my car doesn’t appear to use CRM. My warranty is about to expire and they haven’t been in touch to suggest a renewal. Or maybe, because it’s an Alfa Romeo, they have worked out, using Excel, that it’s not worth it!   

In some ERP implementations the company will build an internal team taken from different parts of the business to review and build the business processes for the ‘to-be’ model. For my thoughts on getting the right team see my paper ‘Simply the Best (ERP Project Team Members)’.

Often the people drawn into the project team will take specific responsibility for different areas of the business. For example someone will take care of Sales, reviewing and designing the appropriate sales order processes, sales contract set up use, commissions and rebates etc. Another person will be responsible for warehousing whilst someone will understand and design the use for product configuration.

The approach will be for these people to undertake training in the ERP product and they will then design, with the knowledge they have gained, the best business processes to suit the business.

Whilst they will have had to gain an insight as to how the entire business system works and will have an appreciation of how their areas of responsibility interacts with that of their colleagues it is vitally important that they are not allowed to continue without reference to the work their colleagues are undertaking. Why do I say this?

Well, I have seen on a number of projects where I have been brought in to review progress, the following issue: Good modern ERP systems have multiple parameters that allow for many different ways of doing business. These will cover engineer to order, make to order, make to stock and a number of other business topologies – each with their own nuances.  Some business types will and can make good use of more than one of these and this is where the challenge can potentially lie.

In one example I came across there was a mis-match  between business processes designed by different people which meant that the overall process wouldn’t work. This example was because the product design and configuration was based around project type customised items whilst the production planning and warehouse management processes were based purely around an anonymous product philosophy. Unfortunately, this wasn’t discovered until after several months work had been undertaken by the team members.

This is why I recommend the appointment of a BPD Tsar on such projects (BPD = Business Process Design). This doesn’t have to be a formal role but it is someone, either internally or externally, that ensures that the business process works from end to end, and in the event of dispute between the functional area experts, has the final say in how the business process will look. Clearly this person should have a full appreciation of how the business works and should be able to overlay this on the functionality of the business system.

Sometimes this can be the project manager but typically it is not.

However, it is an important responsibility and it can save you months of wasted effort.  

There is no doubt that ERP software such as Microsoft Dynamics AX and Infor Baan has become easier to use over the past few years. It is also true to say that CRM has also become a great deal more user friendly.

However, to suggest that there has been an equal reduction in the complexity of the underlying technology would probably be misleading.

We probably know that the possibilities of CRM are endless. The promise of being able to see all of your customers’ detail in one place, including all their recent purchases, returns, inquiries etc is very appealing.

Most people will experience CRM in a B2C (Business to Consumer) context – you’ll probably know that one of your utility suppliers or insurance provider has an extensive  database about you which is also probably linked into your credit record from a credit reference agency so all your details are in one place when they speak to you. (I’m going to have a rant – but I’ll put it at the bottom of this blog so I don’t spoil the flow).

Of course there is a place for CRM in B2B too (Business to Business) and primarily this is the area we deal in.

Let’s get to the point of the blog. Typically a CRM implementation is made at a different time to an ERP one. And typically, it is not by the same vendor. But if you are looking for a single deployment most of the ERP vendors have a good element of CRM in their offerings now. The point is (and I am getting there, honestly) is that to get all the detail from the ERP to the CRM and any other systems , such as manufacturing execution software, so the person using the CRM can have useful information at their fingertips, is quite complex and does require a considerable amount of expertise.

Yes, CRM is relatively easy to implement and use but to get the real value out of it, where you have data from different sources, then don’t just listen to the sales person, dig deeper and understand what the associated costs are to get the ideal solution.

Mind you some people only want to hear about the great things that business systems will do and delight in ignoring, or just be plain oblivious to the underlying complexity.

When I was an IT Director for a large European business I was once called to a meeting with a vendor of a ‘mobility solution’. The pitch was that you could on the PDA he was selling present your ERP and CRM data and have access to that information out in the field.

This was music to the ears of the commercial director. He had always wanted this – and the price of a few pounds per month per device made it a no-brainer to him. The salesman of the product had said that this was entirely possible. The problem was that commercial director had taken this as a literal translation! He told me he was going to buy 50 of the devices because it would give him what he always wanted. The only reason I’d been invited was because he wanted me to confirm the spec of the PDA.

It took quite a while to explain that there would be quite a huge project, at some cost, to get the data he wanted from umpteen systems onto his magical PDA. I had torpedoed the project. I’m not sure he genuinely understood and I have a suspicion he thought I was being difficult so I could follow my own ‘complicated’ agenda.

Anyway, time for my rant as promised.

All those companies that have CRM in the B2C space – why do they only use it to sell insurance?

I’ll explain quickly. I’ve had two events in the past month that have required me to use or buy something I didn’t really want to. Firstly I had a tyre blow out on my car. At the tyre garage they took my phone number. Two days later I get a call asking  ”if I was happy with the service?”.  “Was I given a choice?”  “Was everything clearly explained to me? And “when is my car insurance due for renewal?”  And  “Your house insurance?”

A week later – a flat battery. Recovery service out and I was sorted. A day later a phone call. “Happy with the response?”, “Did the service guy explain the problem?” and “When is your home insurance due for renewal?”

CRM – sometimes I’m not so fond of it.

An important part of our business is providing a managed service to companies who use Microsoft AX (formally known as Axapta) and Infor ERP LN (formally known as Baan). This covers both technical support and functional consulting. We also, for a number of customers, provide support for all of their IT systems – we become the IT department.

Often businesses approach us because they are looking to save money on their internal resource, or realise that they are facing some risk in that the people that they employ could depart and leave them in a fix. It is not untypical to find that the people who work in IT, and who support the ERP system, have been around the business a long time. They have had the excitement of implementing the ERP system and are now lynchpins in the continued use of it.

There is a paper on our website ‘IT Support Options’ that discusses this in more detail – take a look and tell me what you think.

The challenge we always face when discussing our pricing with the potential customer is often centred around our estimates for the number of calls we believe we are likely to receive each month. We always suggest a higher number than the customer anticipates. For clarity we don’t just pick a number out the air – we will go on site and interview the users and look closely at how the systems are currently set up and used.

Why the disparity? Why do we always, in the eyes of the customer, overstate the number of calls (cases) that will be handled? We call it the ‘Not Jim Syndrome’.

‘Not Jim Syndrome’ is this: Where a long serving employee is in sole charge of IT and ERP the demand from the users decline in proportion to the user friendliness of Jim and how Jim feels valued by the organisation.

Actually I am being particularly flippant here and I don’t want to offend unnecessarily any Jims out there. It is obvious though that an internally resourced IT department of one, or two, is going to be limited by a number of things. Mainly time – there are just not enough hours in the day to solve all the problems, or importantly, take advantage of the features of your IT and, more particularly, your ERP system. It is also likely that the person just won’t have the breadth of knowledge about your IT and ERP to be able maximise the use of it. And finally, there’s history. I’ll expand a little more on this if I may.

The chances are that the user requests came in thick and fast in the early days of the ERP implementation and on some days Jim could, under the pressure of work, become a little tetchy. After a while people stop asking. They either accept that something can’t be done or start working round ‘the problem’. (See my other blogs on using spreadsheets for reporting).

Another issue is that it is often easier to keep fixing the symptoms of an issue rather than dealing with the underlying cause. Each day Jim ‘fixes’ an error rather than investigating and changing the system to prevent the error occurring in the first place. This is sometimes done for one of three reasons; one, they just don’t have the time to do the investigation. Two, they just don’t have the knowledge on how to solve the problem or three, they prefer it that way as it makes then ‘indispensable’.

Anyway, to return to the main body of this blog: Eventually, after some haggling we agree a managed service contract with our customer and we offer our helpdesk service. The calls start at a trickle and then, when people realise they are getting answers to their questions, and solving some long term issues, the trickle becomes a stream and then a river. Importantly they begin to ask about the functionality they are not currently using in their ERP systems and we help them investigate the use of that.

So, what conclusions could you draw from this? Well I’d suggest these; If you’re a business that is relying on one or two people to run your IT and ERP then you may not save vast sums by outsourcing but you will probably make greater use of the IT and ERP you already own – get better value from it. Or, if you are a Jim – then you might do your business a favour by contracting with some external resource to help you get the best out of your systems.

Tell me what you think…..

Hey, and I know I like my syndromes!