When Panorama Consulting engages in ERP systems projects with our clients, a key first step in the implementation process is to define a business blueprint. Most ERP vendors claim to do some form of blueprint or system design, so we are often asked to explain the difference between the two.

The simple answer is that is comes down to the business versus technology argument that I often make. In other words, do you want your business to drive the software, or do you want the software to dictate how you run your business? The problem with the latter is that most ERP software is flexible enough to handle multiple variations of the same business process or workflow, so you don’t necessarily want technical consultants making these decisions for you. In addition, while most companies want to leverage best practices built into ERP systems, these best practices are designed to accommodate what’s best for the software, not necessarily what’s best for your business.

Which brings us back to the first point: your business needs to drive your software, underscoring the need for a business blueprint. Each successful ERP implementation I have been a part of has defined a clear business blueprint, while each troubled and failed implementation I’ve seen over the years has neglected to do so.

It’s important to differentiate the subtle but important differences between the two. Here are a few questions that will help determine if you are creating business blueprint elements that all successful implementations address:

1. Are your implementation partner’s blueprint deliverables solely focused on how the software will be configured? If so, this is too myopic of a view of your business processes and we would recommend a more holistic and integrated view of your business processes and workflows. This more comprehensive view should define streamlined and disciplined processes that are standardized across the company where possible.

2. Do your blueprint deliverables identify organizational change impacts according to key workgroups in your company? If not, the designed changes won’t matter much because employees won’t necessarily understand how to use the new system. An effective blueprint defines who exactly is impacted and how, and we find that many of the corresponding organizational improvements can be rolled out independent of the software, reducing some of the chaos that inevitably occurs close to go-live.

3. Can your blueprint deliverables be used to test and validate all of your end-to-end business processes? If not, they should. Your end results should identify the comprehensive processes, including who in the companies will execute the work, the expected outcome, touchpoints and handoffs, etc.

At the end of the day, most of our clients want to reduce risk, ensure their projects don’t go over budget, and deliver measurable business benefits to their companies. If I had to pick the single most important step that a company needed to take to accomplish those goals, it would be to develop a true business blueprint rather than a more limited software blueprint. It saves time by providing clear direction during implementation, reduces cost by allowing expensive software consultants to focus on what they’re good at (configuring and implementing software), and delivers business benefits per more disciplined and streamlined business processes.

Originally posted on 360º ERP Blog

Understanding the Difference Between a Business Blueprint and an ERP Systems Blueprint

Comments

TrackBack Link

Print Page Email To A Friend

Insightful business speaker Jim Harris talks innovation in
Speaker's Corner

Backbone's Digital Economy Acceleration Committee


Remember me
Name
URL (remove the http://)
Email
Comments (field is limited to 2000 characters)