11 posts tagged “business system”

There is no doubt that ERP can bring benefit to manufacturing business. The move from silo mentality to that of a process one, makes people within the business take a fresh view (or so it should) of how they do business.

Back at the end of the 1990’s there was a frenzy as companies rushed to ERP in the hope, initially, of avoiding the millennium bug, and latterly in ensuring that the had fit for purpose business systems for the future. An awful lot of claims were made by all the vendors about how the ERP system could bring visibility to the enterprise – how the CEO would be able to sit at his desk and with the simple click of a mouse get the latest information on how his business was performing. A good number of CEO’s and their colleagues were to be later disappointed not only by the cost overruns of the ERP project and the complexity, but also by the fact that they didn’t get their point and fire business insights.

Why was it such a problem? Firstly it was a great deal more complex than many people imagined (and salesman dared to admit) to implement a new business system – the cultural change is enormous. Secondly, for a lot of businesses the principal activity was manufacturing and most ERP systems really stopped short of the factory floor. By this I mean that they certainly were capable of planning and scheduling production orders in the factory but once released they went into a black hole and didn’t appear again until the work was complete (and in some poorer implementations until days afterwards). Where a product had a short run time this would generally not be a problem, but for more complex items built over a longer period the loss of visibility was critical to the business. Although deemed critical the additional cost of putting in shop floor and machine data collection to these businesses didn’t seem to be worth the effort or money. This was probably down to ERP mission fatigue.

So, unfortunately, there are a large number of people out there that have a dim view of ERP and what it can deliver. If data collection had been budgeted and been part of the project in the first place then, I suspect, there would be a much better view of ERP in manufacturing than there is today.

Whenever we are undertaking an ERP project with a manufacturing client we certainly make them aware of the value of shop floor data collection and ensure that it is included in their business case.

At some point in your ERP project you will need to show the key players in your organisation how you and your project team members expect the system to be configured and how it will work within the business. This simulation will give comfort to the future users and managers that the investment has been worthwhile and that it is going to ‘useable’ within the company.

You will use a subset of your current data from your legacy system and demonstrate the most ‘common’ processes – typically ‘Enquiry to Cash’ and ‘Procure to pay’. You will probably take it in turns as team members to present the parts of the process that you own so you can demonstrate to your constituency, sales, production, etc that you have overlaid your experience onto the new business system.

I believe that it is very important that you treat this as a ‘Sales Presentation’ to your colleagues in the business – by this I mean that you should be very well rehearsed and make sure that what you are gong to present is very ‘slick’. You may think that this is unnecessary to an audience that has no choice about the software that is coming their way but I would contend that you will make the acceptance of what is coming a great deal easier if they fully understand your presentation and feel that it is being managed by a very professional team.

In the past I have seen some dreadful presentations. The most common mistakes are these; disjointed process flows where it is clear that people across the disciplines have not really worked together and therefore present an overall process flow that is inconsistent or just plain doesn’t work.

I’ve also seen the different team members have their own ‘logical company’ with their own data. This requires the presenters to switch between companies. This means there is no consistency in the data – it also means that the audience witness a great deal of ‘flicking’ between screens as companies are changed. This is difficult for the audience to follow and appears to give the impression of too much complexity.

Powerpoint slideshows are really useful to explain what is happening in tandem with the live system. But don’t use it as a replacement – I have seen a team present the entire business model in Powerpoint with screen dumps to show each session from the business system. This didn’t allow for the demonstration of any functionality that wasn’t in the script.

So make sure that you have a proper grasp of what you are going to demonstrate, do it in one logical company, rehearse at least a couple of times, and, if required, polish up your presentation skills.

In one extreme case I have witnessed a project halted because this critical event was so badly presented that the management team lost complete confidence in the team and the product.

What’s the worst, or the best, you have witnessed in a business simulation? Let me know.

Well, I was going to say ‘The Never Ending Project’ but it didn’t sound so good, and it would make a lot of CEO’s and CFO’s shudder at the thought.

However, anyone who has got an ERP system, or is considering implementing one should recognise that the effort of getting the best out of your new business system doesn’t stop a month (or six months!) after ‘go-live’. Sure, there is a shift from the frenetic activity of moving to the new system and training people, not only the basics, but in the advanced or infrequent activities within the software, but for many companies they believe that is the end of their project and they often move the key players in the implementation team either within, or sadly, out of the business.
I’ve yet to see any project where the entire functionality that could be used, is used by the business.
Yet many companies believe that they should stop developing their understanding of their ERP and lose the opportunity to gain a better ROI.

Here at Neustro we are often called in to offer consulting and managed services for Microsoft Dynamics AX and Infor Baan and I find in some instances that the last time the system was ‘developed’, by this I mean functionality that is available is used, is often around the time of the original implementation project. Part of our review process, and the value we bring to our clients, is getting more value from the software they own. I’ve often sat with the directors and managers of companies where they have lamented the fact that they have lost years of opportunity to get additional value out of their ERP system, or worse, where they have invested in alternative solutions not realising that they already had the functionality available to them.

My clear recommendation is that your ERP project shouldn’t stop when it’s implemented – make sure that you have the budget and resolve to optimise its use on an ongoing basis.

If you are British you will probably understand the expression ‘The Full Monty’- it normally refers to not holding back or going as far as possible in a particular activity. There is a British film by the same title that ‘displays’ one interpretation of the term.

If you are in the process forming the business case for your ERP project then certainly consider what I call ‘The Full Monty Approach’. I don’t mean that you should lose your job and resort to taking off your clothes in Midlands’ nightclubs (you need see the film I talked about earlier to prove that I am not rambling or mad) but that you should consider all the elements that will get the very best out of your business system investment.

For instance if you are, as part of your implementation, going to consider a high level of control in your warehousing, to include lots and locations, aging, FIFO etc, then not including a barcoding data collection package will potentially be an action that may seriously damage your project. Your users and managers will appreciate the additional traceability that your new ERP system has but certainly will baulk at the overhead involved in attaining it. Adding barcode data collection will definitely make the implementation easier as well as the day-to-day operational activities of managing materials.

Likewise, if a key aim of the ERP implementation is to give you a real insight as to your labour (or if you are reading this in the USA, labor) costs compared to your standard costs then not investing at the same time in shop floor data collection, that allows for real-time capture of operation and downtime, is cheating you out of the value that could be achieved from your investment in ERP.
I strongly advocate that you make these elements, if you need them, part of your budgeted project costs. Not doing so will lead to disappointment from your people because the system won’t meet their expectations. Furthermore, you will have to go to the board again to ask for more money. Sadly, after spending money on ERP many boards resist spending even modest amounts, even when it shows a good ROI, because they lose confidence in the overall strategy. They will also question why such an obvious and perceived essential requirement was not included in the first place.

If you already have an ERP system in your business, or are contemplating buying one, for instance Microsoft Dynamics AX2009, then I’d recommend an ERP away day. I have seen many companies where the senior management have handed off responsibility of the business system either to middle management or the IT department. The truth is that the same Directors and Owners wouldn’t dream of doing the same for a production machine they had spent a great deal of money on. Yet, for many the ERP system doesn’t even register on the radar.

Your business system is a serious investment and has the opportunity, if used properly to add real value to your business. If you don’t know what it is capable of then you will not be able to take advantage of those opportunities. Even worse, when things are not going right errors can be covered up or lost by blaming ‘the system’.

I’m not suggesting for one moment that you should learn every functional detail of the system – I propose that you should understand what the modules do, and what modules you are not using, but possibly could. This will furnish you with the knowledge to challenge your people to make better use of your systems investment and also help you resolve disputes regarding what the system is capable of.

If you already have an ERP system, ask your support partner or vendor to come and talk to you about its capabilities. Make it clear it’s not about buying more software – you don’t want to give them a day to do an extended sales pitch!

If you are contemplating implementing an ERP system then either seek out an independent consultant or find a partner that promises not to spend the day selling to you. We have now presented several ERP information days, in our ERP Demo Suite, where we run through the functionality that is available in most ERP systems and the response has been universally positive.

In my early days of being involved in ERP implementation projects I witnessed a phenomenon that I later dubbed ‘Wobbly Wednesday’.

This was normally the day, often a week and a half after go-live of the new business system, when the ‘negatives’ and impact of the go-live reached a crescendo and the senior management sat down and seriously considered ‘pulling’ the project and returning to the old legacy system.

And it would normally all start so well. Go-lives are typically scheduled for a Monday so data migration and manual order entry can be completed over the weekend. Monday comes and goes and the users have been so nervous about the system they are surprised it all went so smoothly. Tuesday sees another ‘good’ day and the project team, who stayed late on Monday night getting things right for the Tuesday morning, actually get to go back home. Sometime later in the week the team get together and possibly drink to the success of the project. And then the wheels used to begin to fall off. In those first days all that was dealt with was the basic transactions – more difficult ones would be handled by the project team or consultants. As the week wore on users became more nervous and confused and started to make mistakes. They’d also begin to complain. A delivery would be missed. The wrong product would be made. And the ‘management; would hear and call a crisis meeting. They would honestly consider backing out of the project. This typically happened on the second Wednesday after go live hence me giving it the moniker; Wobbly Wednesday (though I guess I would come up with another alliteration had it been another day of the week).

Fortunately, these days, I don’t witness wobbly Wednesdays anymore. Our detailed planning and preparation for go-live of new ERP systems ensures that everyone has the training and knowledge to be effective from day one. Also, keeping clear communications with the project sponsors, and senior management, means that there are no surprises and no ‘wobbles’.

In ERP implementation projects that are multi-country everyone involved is keen to make the implementation a success – it’s just that different national cultures determine the way that success is achieved. Understanding some basic differences between how different nationalities react to situations can certainly help you overcome barriers to success.

There are four key areas where significant differences in approach can affect your project. Firstly, there is the hierarchical nature of the society. This means that in some societies decision making is a process that can be made quickly because there is little distance between the bosses and the ‘doers’ and decisions made will be supported whereas in some societies there is a strict hierarchy and it is likely you will not have the decision makers in a room.

If you are used to the decision making process in the UK you may find yourself frustrated by the one in Poland – they are very different. The second key trait is how success is viewed within the society. The old saying ‘work to live or live to work’ is important. The French for instance will ensure that the project progresses on a consensual basis wanting to gain agreement from all stakeholders whereas the British will be more inclined to make a decision – right or wrong. Thirdly, how individualistic a nation is can affect the approach to implementation projects. The British tend to be highly individualistic by comparison to, say the Portuguese (excepting Jose Morhinho). So, for instance, relationships will be more important than tasks and this can impact the progress of a project. Finally, avoiding uncertainty and ambiguity is another societal trait that can demonstrate areas of difference to a project approach. The British can live with uncertainty and ambiguity in the hope that things will sort out later whereas Germans are very keen to have all decisions made before progression.

Don’t mistake what I am saying here. There is no ‘better’ approach. Each nation brings many different values to your project but also can impact that project in many ways. If you are involved in multi-national projects and implementations it is wise to gain an understanding of the different cultures involved as it will certainly help you avoid conflict and frustration.

We know that selecting a business system, particularly ERP, isn’t easy. I’ve been through the process many times both as a business executive and as an ERP consultant. It’s a big decision and I’ve seen senior managers, CEO’s and CFO’s caught like rabbits in the headlights as they wrestle with the task of reaching a conclusion.

I’ve met some IT Directors and Managers that get very frustrated with the fact that the same group of people, when faced with a major investment into capital equipment, can be very swift and robust in their conclusions. But often it’s same IT Directors and Managers that are contributing to the paralysis. Firstly, they take on too great a sponsorship of the project and it becomes perceived as an IT project only. This leads to a circular problem; the decision makers don’t feel that it’s their project and they also don’t feel qualified to make an IT decision. The IT Sponsor doesn’t feel it’s an IT decision and that the ‘business’ should make it. Catch 22.

Sometimes a decision is made to get external help – an IT or Business Consultant is called in to present the case for and against. In some cases, if it’s not managed properly, this can lead to the business effectively abdicating responsibility for one of the most important decisions that a business can take.

The reason the board can often make swift decisions with regards to capital equipment is that the business case is clear. There is an investment, there is a payback period and there is a profit from the investment. The same has to apply to a business case for ERP and this is where often the sponsors fail. Some of my thoughts on developing a business case can be found in my white paper ‘Developing a business case for ERP’.

Some businesses never get as far as developing a business case – good or bad. They simply spend a huge amount of time and resources trying to decide which ERP system to select in the first place. My view on this can be found im my white paper about ERP Selection’.
The important thing to remember is that talking about a new ERP doesn’t realise the benefits of it. Using it, properly, does.

Name your ERP project carefully. Over the many years of being involved in ERP projects I have come across many titles and names for them. Here are some of my favourites: Project Bacchus. Named after the Roman god of wine. Why? Well it seemed like a good idea at the time. It gained a new resonance when the expenses started rolling in for the project team who happened to be staying at a hostelry famous in its parts for its food, and wine. It is even rumoured that the project launch presentation laid down the challenge to the business ‘Bacchus or sack us’.

Choosing less florid titles can also lead to some interesting outcomes. At one company they decided to name their project IBS, for Integrated Business System. The name was later changed when the kick off meeting, which took place in a local hotel, had several of the business stakeholders turning up in the wrong function room. They sat and listened to the background of IBS. Irritable Bowel Syndrome.

Some companies take a more structured approach in setting a theme for project naming conventions. One theme used was landmarks. Some of the letters of the alphabet were easy such as Danube for D, Everest for E etc. Some letters were more difficult – and for Q the alleged Chinese river of Quinshenshang (though trying to research it now I get no matches on Google). The rumour was that the project sponsor was disliked by the IT department and so gave it this name to annoy him. However he soon dispensed with the effort of having to say the name over and over again by simply referring to it as project ‘Q’. They succeeded in annoying him all the same by stepping one project name backwards for his next venture by naming his project after another river, ‘Po’.

When we are involved in our Microsoft Dynamics AX implementation projects here at Neustro we normally arrive too late in the process to influence the naming. Except where we had to insist that an implementation project was renamed as it was international in nature. The UK had given a great deal of thought to their project name and had settled on ‘Speed’. This was duly dropped when it became clear that ‘Speed’ in Swedish is ‘Fart’.