Does The Functionality Of Your Current System Match Your Business Requirements?
Here’s a question for you. How many of you out there have a stock control system that was specified specifically and only for the key task of inventory management?
Not many? I didn’t think so.
OK, hands down everyone.
Here’s another question. How many of you have a stock control system that is integrated into a larger ERP system? Wow.. that many!
I’m going to make a few guesses here. To gain the functionality that every department needs from your inventory management system you guys in the second group have to do some, “manual intervention”, maybe use the export options from the ERP system and create your own lists, maybe parse blocks of data through Excel or similar to get the reports you need.
Now think back. Try and remember the time when the discussion documents and specification for your ERP system were being passed around. Were you aware of these data needs at the time, and if so, were you told that the ERP system could produce them?
If the answer to those last two questions is yes, then join the growing crowd of medium sized and larger businesses that have found two of the stumbling points that seem common to an unsettling number of adopters of well known ERP systems.
Specific Requirements Meet Generic Functionality
I’ve sat in on more ERP implementations than I care to remember. Initially as an employee of the company buying the system, then later as part of implementation teams.
The line early in the process, regardless of the solution being implemented has always been
“You won’t need to use these hand made reports any more, this new system will do everything for you”
I’ve yet to see that become a reality. Some have got close for a while, but even then the disconnect between what the system as implemented produces and what is required for daily operation tends to drift over time.
Why The Disconnect?
I’m going to give a couple of ideas here and would love you to add your own underneath in the comments section.
Poor Initial Specification
Is it perhaps partly your own fault that the management system does not meet your requirements? Did one or two departments (I’m looking at you accounts) have too much of a say in the implementation at the exclusion of input from others?
Was the consultation of other departmental needs, a full assessment of inputs and output requirements properly worked through?
In the case of inventory management and stock control I’ve seen instances where the departments were not consulted at all.
This happens, while the problem can’t be placed firmly at the door of the management system, it certainly is the fault of the implementation process. Having the excuse that departments were “too busy” to fully detail their requirements at the beginning of the specification process is an example of how these situations occur.
Fit Your Working Practice To Our System
Does the ERP solution you’re looking at require that you change your entire method of operation to suit it’s way of working? While I have experience of this as an issue specific to inventory control, it is something that can, and does affect every other department sometimes.
My feeling is that this simply shouldn’t be the case.
It is the job of the system to mirror the working practices where at all possible, Of course some changes are inevitable.
However, in general a successful company knows how to work – that’s why it’s successful.
To have to fundamentally alter it’s entire structure to fit around an ERP system is not satisfactory, yet, many of the biggest solutions in the field, while headlining flexibility as a bullet point, deliver a requirement for slavish conformity once you get down to brass tacks.
What is your experience of ERP implementation, particularly the impact on inventory control but also in general. Are you finding a disconnect between the specification promises and the working reality?