To-Be or Not To-Be: When and How to Design Business Processes for your IT or ERP Project

One of the most contentious issues in the world of ERP and IT is how much attention to give to as-is and to-be business processes.

Opinions on the issue run the whole spectrum on how this should be addressed; some people feel that companies should let their ERP systems dictate what new processes will be, while others feel that as-is and to-be processes should be documented and analyzed in detail before selecting IT software. Many people, including myself, feel that the approach should fall somewhere in between.

It is helpful to break down the issues and look at each individual aspect of business processes to decide which approach is best for your company and your IT or ERP implementation.

As-Is Processes
This is one of the more controversial aspects of ERP projects. In my experiences with clients implementing ERP, IT, or any other large business change initiative, there needs to be a decent amount of attention devoted to defining current business reasons. The benefits of doing so are three-fold:

1) It helps get alignment and understanding among various business units and geographies on how things currently operate. More often than not, especially in very large organizations, many managers and key stakeholders do not have a big-picture view of what other parts of the organization are doing. Documenting as-is business processes helps develop clarity on what is working well and what is broken with the current business processes.

2) It helps define how employees are doing their work now, which will help define the gaps between the current and future states. This is critical when it comes to organizational change management and training initiatives later on in the project.

3) It helps determine the key operational pain points, and therefore the to-be processes and business requirements during the software selection process.

This is not to say, however, that companies should spend an excessive amount of time documenting or over-analyzing current processes. At a minimum, organizations should develop level 1 detail around their current processes.

To-Be Processes
This area is very important as well. In order to develop the appropriate business requirements and select the software that is most effective for your business, you need to understand how you want your business processes to look in the future. Doing so provides four key benefits:

1) It helps you define your future operational model and business processes independent of software. This allows you to think out of the box and look for opportunities to score big wins by leveraging IT as a tool to enable measurable business improvements. If you skip this step, you are more likely to be influenced by sales messages instead of functional fit.

2) In conjunction with the as-is processes, it helps you identify the gaps between the current and future jobs, roles, and responsibilities. This is critical from an organizational change management perspective.

3) It helps define key performance indicators to help drive business improvements and accountability. With new processes come new responsibilities and opportunities for improvement, so you need performance measures to enable this.

4) It helps prioritize customization, integration, and report-writing needs after the software is selected. Without this understanding of where you want your organization to go from an operational perspective, it is very difficult to determine where customization and additional development is appropriate.

In short, I have found it helpful to view the business process aspects of your IT projects independent of the software itself. Your future strategic direction and business processes should drive the IT project, not the other way around.

Read more blog entries in our corporate ERP blog on our website.