Documenting your current processes can be a waste of time and money.
When we are preparing the project plan for conducting a selection project, one topic that is always discussed is whether the client needs to document the existing processes before starting the selection engagement. We believe that the answer to this question is “NO”. Let me explain why:
Our research indicates that clients who engage us to assist them with a software selection have know for at least two, and more likely three years, that they need to replace their software. The decision to replace software requires a significant amount of time and money.
During this period of dissatisfaction, various workarounds are added to address the weaknesses of the system. This includes external applications that are bolted on or developed in-house, applications that are purchased and not integrated, workarounds developed using Excel spreadsheets and more. In other systems we see comment field crammed with actionable information since this is the only place that users have for storing this important information. Unfortunately, if users have not read these instructions or follow the instructions errors will occur in handling orders. To prevent this from occurring more ad-hoc systems or procedures are implemented.
Investing significant time and money in documenting and flowcharting doesn’t result in a better set of requirements. At the Brown Smith Wallace Consulting Group, we have developed process outlines that reflect the standard process flows that the most new ERP packages will follow. We use these outlines to conduct interviews with groups of users to aid us in developing the requirements for a new ERP package. Typically users like to tell us what their software doesn’t do and how hard it is for them to get the right job done on time. These process indexes help us to keep the focus on the process and not the flaws of the current system.
Having a flowchart of the existing system only helps us to understand how dysfunctional the existing system is. It doesn’t help create the vision of the future state of the business. This doesn’t occur until they see demonstrations of new systems and the capabilities that are available to them. Only then can they start to understand the value of the new processes incorporated into the new software.
So if you know your current system needs to be replaced, start by documenting the requirements to achieve the future vision and do not document the past that you want to replace.
4 comments:
Wow. I make a lot of money correcting implementations that are handled this way. Granted, you should not spend a lot of time on AS IS, but it is a foundation to:
1) Understand if the process meets business needs or direction
2) Address non-system related issue and inefficiency
3) Is your platform for a gap analysis and transition plan.
Remember, people process and technology are "enablers" of business.
I would agree that for the implementation phase of the ERP project that reconciling the current processes and the processes in the ERP package is important. My point was that for the selection phase the business requirements can be derived without investing serious time and dollars in documenting processes that are broken. I've been talking to a large company on the East Coast for over 5 years about their need to replace their software but they can't get over the hurdle of flowcharting and documenting every process that is in use. So they just tolerate the cost of having a ERP system that doesn't work very well.
I still recommend to do AS IS, added points:
I totally agree that processes get laden down with work around tasks and patches...which then impact the enablers too - technology, job roles and procedures.
We go through the As Is focus on:
1) where are the issues and root cause - driving to be design points
2) look to "lean out" the process - I focus on Excel spread sheets and Access databases as a trigger, as well as the usual process waste.
3) Then validate where the business is going - strategically
These actions may change the future requirements. Plus there will be quick hits not related to the system that can be leveraged for financial and team excitement.
The company that has wrestling with ERP issues for over 5 years:
1) Probably an ownership issue, as to who owns - so it is not a priority, or there is not a sense of urgency by the leadership
2) If they are taking 5 years to map out their processes, then they have an internal issue. Buying software now, would only expend cash that most likely will not be implemented until later or even correctly.
Just mapping out the process, does only tell you how you are doing business...it is the analysis afterward that drives value and requirements. By the way, I have not seen anyone agree to the current state in over 25 years.
By the way, this has been a great discussion.
I have been putting down Anonymous as I did not want to sign up for another account name. If you would like to talk further, I can be reached at rjs@blcn.net. I work with integrators for all the non-system actions - leadership alignment, process (improvement and transformation) and organizational change.
Cheers,
Thanks for the additional comments. I'm enjoying the discussion as well.
We conduct a "getting started" phase at the beginning of every problem where we define goals, constraints, process identification, problem identification, and a survey of the business processes and IT environments. Those preliminary steps help us to identify and address the areas you focus on in your AS IS assessment. So I think we do many of the same things, just call them parts of different phases.
Your assessment of the problems at the customer I've been talking to for 5 years were accurate.
Post a Comment