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.
