2 posts tagged “bpr”

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....

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.