Ever since I started working with ERP systems in the mid 90’s, one of the most controversial and heated discussions in the industry has been how to handle business process re-engineering. When selecting and implementing a new system, do you focus on your as-is or your to-be business processes?

Pose this question to an organizational change management consultant and they will likely emphasize the importance of as-is processes in helping employees understand the new ERP system in the context of their current environment. Ask an ERP vendor, on the other hand, and you are likely to hear the virtues of throwing out the as-is and using to-be business processes built into the system. Two very different responses indeed, so which is true?

The reality is that it’s a bit of both. No one disputes the desire to use ERP software to re-engineer business processes to improve efficiency and effectiveness, but it’s not as simple as just flipping the switch and assuming to-be processes and best practices built in the system will magically embed themselves in your organization. Instead, you need to first understand your current environment and where you’re starting before you can determine where you’re headed. Much like taking a road trip to New York, it isn’t likely that you would just start driving aimlessly without first consulting a map and determining the best route based on whether you are starting from Los Angeles or Miami.

In addition, migrating from your as-is to your to-be business processes is an iterative process that starts during software selection and continues through and after go-live. Again using our road trip analogy, a trip to New York will require constant adjustments based on traffic, weather, and desire to reach certain milestones along the way. While the end point remains the same (New York), the route to get there needs to be planned and adjusted based on environmental realities. The long journey from your current state to your future state ERP environment requires similar planning and adjustments.

As Is To Be ERP Process MigrationFour Key Steps in the Journey From Your Current, As-Is Processes to Your Future-State To-Be Processes

  1. Software Selection. The first step toward to-be processes begins with ERP selection. During this phase of your ERP initiative, it is important to define high-level business requirements to help evaluate potential ERP vendors. Typically the evaluation is conducted with an understanding of how you currently conduct business, while at the same time casting your mind toward how the business can be improved in general with a new ERP system. The evaluation process is also generally conducted using high-level business requirements that are independent of software transactions.
  2. ERP Business Blueprint. Once the software is selected and before the technical implementation begins, it is important to design the business blueprint, which provides the first real tangible views of how future to-be processes will look. Here is where you begin to re-engineer business processes, re-define organizational roles and responsibilities to improve efficiency, and look for opportunities to improve the operational model. Although this step involves business process workflows and requirements in more detail than the ERP selection process, it is still at a technology-agnostic level that does not yet dive into the detail of how transactions will be completed in the new system.  For example, we are working with a manufacturing and distribution client who is leveraging their new ERP system to consolidate operations of three business units into one standardized business model. However, the software we helped them select is not going to tell them how to define this new operating model; instead, they are defining how business processes and organizational roles and responsibilities will look across the three business units. These changes need to be well defined whether they implement SAP, Oracle EBS, Microsoft Dynamics, or any other ERP system. We are working with another global chemical manufacturer that is about to implement their ERP system across over a dozen different countries while adopting a shared services model in key areas such as procurement and supply chain management. Again, the key for them is going to be to define their shared service model at a high-level, then leverage their selected ERP software to enable the new model.
  3. ERP Implementation and Configuration. Once the ERP business blueprint is complete, the software can then be designed, configured, and if necessary, customized to meet the defined business process workflows. Rather than flying blind and configuring and implementing the software based on their own experiences or assumptions, your ERP vendor’s technical resources will be much more effective in deploying a system that is aligned with your business needs and requirements based on the business blueprint. In addition, the configuration can be easily validated by using the business blueprint as a sort of roadmap for everything from configuration, integration, testing, and training.
  4. Organizational Change Management and Training. Business processes aren’t real just because they’re documented in a nice Visio diagram. They become real when employees start using the new business processes in the new system. Because it provides the tools that will enable employees to bridge the gap between the as-is and to-be processes, organizational change management and training is where the rubber meets the road. This final step in the migration to to-be utopia is why organizational change management activities are so important, including organizational impact analysis, stakeholder analysis, change agents, communications, and training.

Migrating from your current, broken, or manual business processes to more efficient future-state ERP processes is a journey that is worth the effort, but requires a great deal of planning and iteration. Many companies jump right into focusing on the functionality of their new ERP system without first defining their current processes, which as illustrated above, can lead to implementation challenges later on. A measured and more effective process, on the other hand, begins with ERP selection, continues through ERP blueprint and implementation, and becomes reality via organizational change management activities.

Learn more about how we help our clients plan and execute their business process reengineering by reading about our ERP business blueprint services. Whether you are implementing a Tier I or Tier II ERP system, SaaS vs. on-premise, or single-system vs. best of breed, Panorama can help define and execute the best route to improved business processes.

Posts You May Like:

How to Avoid ERP Implementation Failure: 9 Tips

How to Avoid ERP Implementation Failure: 9 Tips

Enterprise resource planning (ERP) is used to manage and integrate functions like marketing, finance, human resources, and supply chain management. While ERP software is a transformative solution for many business owners, others are too concerned about project failure...