Projects that change processes, without appropriate business analysis

Another common way to poorly conceive a project is when the deliverables for a project involve changing tools and business processes simultaneously and analysis of the “as-is” and “to-be” business environments are not considered as part of the project scope. Automating a process that is not well defined or implementing new or changed automation without the appropriate examination of the existing and new business processes results in disaster. Examples of this abound, as evidenced by the large number of failed projects in the Enterprise Resource Planning (ERP) space, using extensive product suites such as PeopleSoft ®, SAP®, and J.D. Edwards®. These software suites are quite capable – but they are frequently installed in hopes they will facilitate the improved execution of existing business processes. It doesn’t take long for the users to report that the product doesn’t work. The reality of the situation is this – the software suites do “work,” just not to facilitate the precise business process the users are trying to execute. A significant mismatch exists between the processes the users are accustomed to executing and the processes that are inherent in or implied by the software.

Projects that seek to change both processing tools and the user’s business processes need to contain a number of required initiatives in order to succeed. These initiatives include an analysis of existing business processes – the “as-is” model. Only with a well defined set of current processes will the project manager and her team understand what processes are going to change, where current complexities exist, and areas for improvement – and therefore what needs to be communicated and taught to the user community.

The second major required initiative for these projects is the definition of the “to-be” model – the set of processes that will result from the project deliverables. ERP product suites have an implied set of processes inherent within them. The providers of these software tools seek to support and promote business processes that reflect common practices across a broad swath of industries, as well as focus on “best-practices” to achieve efficiencies across the organization. Inevitably however, the ERP product processes will differ from the processes that are part of your organization’s “as-is” profile. Conscious and well thought out management decisions need to be made to decide: a) if processes in the organization are to be altered to match the processes supported by the tool; b) if the processes inherent in the tool will be changed by customizing the tool to match the business environment or, c) both the tool and the businesses’ processes will be changed to “meet in the middle.”

In many situations the process modeling work effort can be perceived as a waste of time and simply slowing the project down. In reality; performing effective process modeling will enable the project to run more smoothly by identifying problem areas up-front and ensures the overall success that the product that is ultimately delivered to the business will truly meet their needs.

Let’s examine one more project hazard that requires the project manager to be a hurdle…

continue>>

<<back