Developing a Business Case for ERP Customizations

To customize or not to customize – that is the question which continues to be a source of contention and confusion.  On one hand, customization(s) can result in an expensive ERP solution.  However, ERP software enhancements can provide a competitive advantage or cost reduction that is customer-specific.  The challenge is not in the question itself but rather how the answer is justified.  Unfortunately, many business cases for ERP customizations are either too short-sighted or do not fully comprehend the impacts to the ERP investment.  In the next section we will discuss the key components required for an ERP business case for customization(s).

 Business Case Overview

 Following is a business case template I’ve used as a consultant to justify ERP customizations. 

Valuation and Justification for ERP customization
Business Case Format

Let’s briefly discuss each section in greater detail.  The Problem (or Opportunity) section should clearly define the issue(s) as well as the target audience who will benefit from addressing the problem.  The problem section should also explain the compelling reason (s) why the problem should be addressed.  The Solution section should speak directly to solving the problem or addressing the opportunity.  The solution section must include the method(s) used to validate that the proposed solution solved the defined problem.

The Approach section details the viable methods available to implement the solution.  The approach section should not be a theoretically exploration of all possible options.  Too often I have observed where unrealistic approaches were defined, which did more to confuse decision makers rather than create a focused, compelling argument.  In general, I typically provide three approaches when pitching an ERP customization:

  • Full Customization (Extreme)
  • Partial Customization (Middle of the Road)
  • Out Of The Box (OOTB) (Extreme)

Following is a generic example of comparing the above options:

Possible Approaches for ERP Gaps
Possible Approaches for ERP Gaps

Moving back to the business case, the Risk Assessment section outlines the risk(s) associated with each approach option defined in the previous section as well as identifying the risk(s) of doing nothing to address the problem/opportunity.  The final section is the Value Analysis section.  The key challenge I have noted is that short-term value methods (examples: benefit/cost analysis, payback period) are used to support a decision with a long-term impact.   In the next section we will discuss the unique considerations one must address in developing a valid ERP software customization value analysis.

Value Assessment Considerations for ERP

In addition to the short-term costs associated with ERP customizations one must consider the following areas to calculate the long-term costs:

  1. Impact to Upgrade and Maintenance:  What is the impact that the customization will have to the ERP maintenance and upgrade process.  Is the software customization intrusive? – Meaning is it an add-on enhancement or a fundamental change to how the ERP software works?  The more intrusive the customization is the greater the costs required for ERP support and upgrades.   Frequent ERP upgrades are a key strategy for driving additional business value.
  2. Impact to IT Resource Sourcing:  The more you customize the ERP software the more customer-specific ERP knowledge an IT resource requires to provide an effective level of service.  Additional customizations will have a shrinking effect on the IT resource pool and may have the potential of driving up related IT support costs. 
  3. Cumulative Impact to the IT Footprint:  Too often we consider customizations individually and not part of the total ERP software changes made.   A field change here or a new application page may not seem like a big deal but you must remember that you must support everything you customize.

The above areas will ensure that you generate a holistic set of information for an informed decision.  Too often, short-sighted decisions are made to customize ERP without completely understanding the potential impacts.  The next section will shed more light on some of the less obvious risks associated with not having a holistic business case.

 Risks of not developing an effective ERP customization business case

Incomplete information results in incomplete decisions and more importantly – missed expectations and business results.  Following are a few of the key risks generated from over-customizing your ERP software:

  1. Greater operational costs:  There is an additional cost associated with customizations –typically required from the IT organization to support and manage the software changes. 
  2. Slower deployments of technology:  With additional technology dependencies generated by ERP customizations come the additional planning and testing activities required to deploy new ERP functionality.
  3. Lost opportunity costs:  This is an area that is typically overlooked in customization value analysis.  It is more than just comparing one ERP customization to another but also identifying the potential reduction in flexibility ERP software can provide to the business. 

Summary

ERP is a long-term proposition and requires a long-term business case and value analysis for any change in the ERP’s value proposition.   Too often decisions on ERP customizations are based upon partial information and are made in isolation.   ERP is only one component of a business solution.  Business processes and People have a greater impact on business results. 

Key Drivers for Business Results
Key Drivers for Business Results

Granted, the full impact of a customization decision may not be fully appreciated in the short-term but poor decisions will build into a formidable wave that will keep you from experiencing value from your ERP investment.

Join the community! 10k followers across 100 countries!

Viable – Manageable ERP

Several ERP implementations suffer from what I call a “fast-food” mentality of delivering value.  Customers feel that they need to get functionality that addresses both existing needs but also future needs given long implementation cycles.  Business needs and business wants get blurred together during requirements gathering which make it harder to differentiate and validate.  Finally, more analysis and effort is spent trying to fit one more feature or capability into the ERP implementation versus understanding the support requirements after the implementation.  Typically, the result is a solution that causes more problems than it solves because the ERP solution is not sustainable.  In the next sections, we will discuss some principles to prevent your ERP project from delivering an unmanageable solution.

Set REAL Expectations for Executives (i.e. There is no such thing as a “push button” solution)

How many time(s) have you heard an executive say “All I want is a button to push so I can produce what I need!”  That statement is enough to indicate that there is a huge “expectation gap” and no matter what you do it will be a losing battle.  To establish expectations for success I use the following strategy:

Setting Realistic Expecations
Setting Realistic Expectations

The first and most important step is to establish realistic expectations.  This effort will require educating your executives on the organizational effort, potential business value, and possible risks involved in meeting an executive mandate.  Be prepared to articulate in layman’s terms what is you can do and what should not do with technology.  Second, use the language that every executive knows and understands: money!  Quantifying business value, costs, and risks in an executive business case can quickly align executive wishes with business reality.  Third, come to an agreement on expectations.  This agreement should be formalized via a signed project charter.  Finally, there should be boundaries (limits) on the agreed upon expectations.  These limits should be defined within a scope statement with constraints and assumptions.  Next, we need to further define and refine expectations for key business personnel that will enable you to meet executive expectations. 

Set REAL Expectations for Business Users (i.e. theoretically correct vs. practically accurate)

Today’s ERP software has increased the amount of data that business users can capture.  In addition, naturally business users see this as an opportunity to drive more business value.  However, capturing additional data does not automatically equate to additional business value.  Consider the following illustration:

theoretically correct vs. practically accurate
theoretically correct vs. practically accurate

It is important to challenge the assumption that more data creates greater value and better decisions.  In the illustration above what is the level of precision required to get to the right answer?  In the pursuit of driving better decisions we can easily start down the path of creating a data-gathering monster that cannot realistically be maintained.  The result is bad or missing data and the goal of driving better decisions is unattainable. 

Set REAL Expectations for IT (i.e. developing software is not the most valuable thing IT performs)

I’m sure if you ask a majority of IT personnel how they generate business value that software development is right there at the top. However, this value generator is in conflict with a core ERP value proposition.  Organizations purchase packaged software like ERP to minimize internal software development.    Internal IT organizations that support ERP solutions must change their definition of value generation for their customers.  Consider the following illustration: 

ERP Service Categories for ERP
ERP Service Value Chain

As you can see above the highest level of services that IT organizations can provide are advisory services that assist internal customers in how to best leverage technology.  Another key concept that is a huge mind shift for IT organizations is to utilize ERP as the fundamental driver for generating additional value versus utilizing a traditional requirements-driven approach.  Let’s look at the implications of IT organizations do not adapt to take full advantage of their largest software investment (ERP).

Impacts of an Unmanageable Solution (i.e. we are not getting value from ERP)

I don’t know about you but I’m guessing that you are being asked to do more with less.  I have a very small IT staff that is responsible for both ERP support and ERP-driven enhancements/transformations.  The IT staff spends the majority of their time (up to 70%) on ERP support.  Even though ERP support is at the lower end of the ERP value chain the activty is a very high priority.   However, this leaves us with a small level of capacity to support higher services.  A high maintenance ERP solution limits your ability to generate greater perceived value to business users.  Business users usually do not perceive value from ERP support services unless something goes wrong. 

Summary

As the ERP industry continues to mature we are observing the rise of more functionality and capabilities to capture even more data.  However, nothing is free. Additional functionality and data capture requires additional discipline and support requirements from both IT and Business users.   Please do not take an extreme approach and stifle innovation.  Business is all about take risks.  My point is – take calculated risks.

Join the community! 10k followers across 100 countries!

Creating a Flexible and Adaptable ERP Solution

Every customer I assisted in their ERP implementation wanted an ERP solution that would be flexible and adaptable.   One of the key challenges and disappointments customers have with ERP are around flexibility and adaptability.  We also need to address the common misinterpretations associated with the concepts of a flexible and adaptable ERP solution.  Referring back to a previous blog we know that ERP is only one component of a business solution.  There are three key areas to address as part of developing a flexible and adaptable business solution.

Know The Limitations

Technically speaking, there are two key methods to enable packaged software like ERP to be flexible and adaptable:

  1. Programming (addresses flexibility or the ability to change)
  2. Configuration (addresses adaptability or the ability to easily change)

Each of these methods has inherent advantages and challenges associated with them.  Configuration has been a key area of focus for ERP vendors to create greater software adaptability.  Configurations enable less technical, business-oriented users to determine how ERP behaves to specific events and conditions.  Configuration provides the opportunity for cost-effective flexibility to meet the unique business requirements.  However, where there is no option for configuration then programming must be used to enable ERP software the flexibility to meet the unique requirement.

Programming provides an exact prescription to address a specific business event, condition, or activity.  There are programming techniques and add-on utilities that provide some level of technical flexibility (examples: object-oriented programming, services-oriented architecture) but business flexibility is extremely limited at best (unless an ERP vendor can devise a practical means of applying artificial intelligence – fuzzy logic to their software).   There are limitations with the amount of flexibility and adaptability you can create via software.  What is important to remember is that there are other components of a business solution that better suited to address flexibility and adaptability.

Know Your Strengths

Let’s revisit the components of a business solution along with their inherent strengths.

Strengths of Business Solution

Business Solution Strengths

Too often we do not effectively utilize the strengths of the key components of a business solution.  ERP software is good at automating consistent, repeatable activities based upon a prescribed logic (business rules).  ERP software is not a sustainable, cost-effective option for dynamic activities based upon fuzzy logic (business rules).  People are more flexible and adaptable than ERP software.  Please do not take the above statement to an extreme and infer that every customer should conform their business activities to the ERP software.  ERP implementations should include software enhancements to address the unique value-add requirements of a customer.

Flexibility and adaptability only have value within the context of enabling ERP to position itself optimally in supporting key business drivers.   Next, we will discuss the common drivers that must be coordinated as part of addressing flexibility and adaptability.

Finding Balance

Every customer will have unique business drivers that must be managed in a balanced approach.  Given my implementation experience following are what I consider the common business drivers that we might address as part of an ERP implementation

Balancing ERP

A balanced ERP solution

Can we have a flexible and adaptable ERP solution?  I believe that the answer is yes.  Can we have an efficient and effective ERP solution?  Yes.  Can we have a scalable and efficient solution?  Yes, however we can only experience both characteristics to a certain level.  The challenge I observed is when an extreme position is taken in one of these areas.  Like a ball on a flat table once we start tilting the table (taking an extreme position) the ball will roll off the table – – along with your ERP implementation.

Finding balance is an ongoing exercise to find the right level of applying the influence of the specific business driver upon the ERP project.  It is also important to know and understand at what level of influence will business drivers start conflicting with one another.

Summary

Flexibility and adaptability are reasonable expectations for a business solution.  The key challenges in this area tend to be around inaccurate expectations and not effectively utilizing the individual components of a business solution.  What is required is a practical analysis of the strengths, weaknesses, and business drivers to develop a balanced approach for success.  This analysis is not a one-time event but a continuous effort that is triggered when emerging pain is experienced.  Experiencing pain provides the opportunity for rebalancing your ERP solution.

Customers – Insist on an ERP Knowledge Transfer Plan

What Gets Tracked and Measured Gets Done

How do you measure knowledge transfer?  Customers – have you ever received a report or completed checklist that demonstrated the Implementation Partner conducted knowledge transfer?   Knowledge transfer is a process, not just a milestone task on a project plan.  Consider the following illustration to identify the importance of knowledge transfer.

ERP Business Solution
Business Solution Defined

In a previous article I referred to this view and also identified people as the component with the largest impact to a successful business solution.  A key enabler for people being successful is Implementation Partners conducting effective knowledge transfer.  For many ERP implementations, knowledge transfer is a process that is loosely managed which results in the Implementation Partner providing support long after the go-live date. For an area so important it demands that we formalize this process to ensure completeness.

Best Practice: Knowledge Transfer Plan

Simply put, if you want to ensure that an objective is reached then you need a plan.  A knowledge transfer plan first defines the knowledge transfer process and the methods that will be used to conduct knowledge transfer.    Second, it defines all the customer’s roles & responsibilities that are required to support the entire business solution – both from a functional and technical perspective.  Third, the knowledge transfer plan should act as a checklist for each individual role validating that effective knowledge transfer has taken place.    Following is an example of a knowledge transfer plan.

Knowledge Transfer Process for Consultants
Knowledge Transfer Plan

Effective knowledge transfer is more than just training or having a user sit next to a consultant.  It requires a holistic approach in using several methods (training, mentoring, knowledge generation, and interactions) to be successful.  The end result of knowledge transfer is enabling the customer to support their new business solution.  

Implications for Implementation Partners

Knowledge is power!  Knowledge can be money and a key source of competitive advantage for an Implementation Partner.  For an Implementation Partner a key concern is balancing knowledge transfer to ensure customer success versus providing too much knowledge resulting in the customer terminating services early.  It’s important for customers to keep in mind that knowledge sharing happens more freely in a trusted environment.

There are two broad categories of service that an Implementation Partner can provide: staff leadership and staff augmentation.

Broad categories for ERP implementation services
ERP Implementation Service Spectrum

To achieve greater customer enablement Implementation Partners should play more of a staff leadership role during the implementation.  Customers, there is a price associated with effective knowledge transfer.  Also keep in mind that there are greater resource requirements (i.e. knowledge, experience, advisory) for staff leadership services.  Price should not be the only consideration when comparing staff leadership versus staff augmentation services.

Summary

True enablement is based upon customers selecting consulting firms that act as a true partner and not just staff augmentation.  If customers only require staff augmentation then I suggest customers get it as cheap as possible, yet don’t expect any reliable knowledge transfer to occur. If this is the first ERP implementation for the customer then I would recommend that the customer selects an Implementation Partner that not only assist your project team but more importantly train and enable your project team to be successful on your own.  That is what a true partner would do.  To maximize knowledge transfer the customer needs to foster a trusted work environment.  Customers – it’s in your best interest to take the lead in creating this environment.

Join the community! 10k followers across 100 countries!

Embrace Changing Requirements for ERP Implementations

Business is Changing!  Don’t Fight it – Embrace It!

A key challenge with any ERP implementation is changing business requirements.  Yet many project teams are surprised when business requirements change.  Think about it, the scope of an ERP implementation is based upon a “point in time” solution.  Competitive business models are constantly evolving to meet customer demands.  Today, the majority of ERP implementation approaches discourage changing requirements by having laborious scope change control procedures that tends to be more of a roadblock than an enabler.   What is required is a more proactive approach to identify differentiated requirements that can provide a competitive advantage to ERP customers.

What Are Differentiated Requirements?

Differentiated requirements are business requirements that will support a business solution that is uniquely different from another business solution.  They allude to a significant, comparative difference.  Differentiated business requirements are very useful in ERP software selections because they focus on the unique differences between the ERP software packages.   In the context of an ERP implementation differentiated business requirements refer to unique business requirements that are different from company’s peers or competitors.  Consider the following illustration:

How ERPs address business requirements

How ERPs address Business Requirements

Allow me expand on a couple of thoughts:

  • Differentiated requirements are not best practices.  Best practices are common and generally accepted business practices across a specific industry and/or country.  Best practices are generally available in the market and therefore are not competitive (or no longer competitive).
  • Differentiated requirements should focus on competitive business requirements that uniquely position a customer’s offerings in the market.  Practically speaking, a customer should be more concerned about being competitive in revenue-generating business processes (i.e. Order to Cash) rather than revenue-supporting business processes (i.e. Expense Reporting).
  • Competent ERP software is designed to address generally accepted best practices.  ERP software will not address the unique competitive business requirements of an individual customer.

 

Handling Differentiated Business Requirements Late in the Game

Now comes the challenge of handling differentiated business requirements late in the implementation.   If you notice I did not say we should address all requirements.  There are risks associated with addressing business requirements at the end of an implementation cycle.  The question you need to ask is whether the business requirement will create more business value than the implementation risk generated.  There are four steps you can take to address differentiated business requirements:

  • Reduce the possibility for late competitive business requirements by proactively searching for these requirements during earlier stages of the implementation.  This will require a competent understanding of business processes, their key results, and how they can be competitive.
  • Maintain a business solution modeling environment to quickly determine how the differentiated requirement can be addressed.  Business solution modeling will enable simulations on how the three components of a business solution could support the competitive requirement.  The simulation may take several iterations.

Modeling ERP against business scenarios

Business Solution Modeling

  • Plan for this scenario to happen.  Let me restate that the scope for an ERP implementation is based upon a point in time solution.  This scenario should be formally listed as a risk and managed as such.  This scenario is almost a certainty for a revenue-generating business process (ex. Order to Cash) given the external competitive forces at work.
  • Develop a roadmap during the implementation to articulate how new or advanced business requirements will be handled in the future.  Too often a customer may believe that they have only a single opportunity to get both their needs and wants addressed in the ERP software. 

Summary

Just as we expect a customer’s organization to adopt change with an ERP implementation, project teams need to expect and embrace change for differentiated requirements.  The key challenge is identifying which requirements are competitive and strategic.   Too often we narrowly focus on functional areas and not the entire business process.

  

Project team focus during ERP implementations

Silo Functional Focus vs. Business Process Focus

 

This is a challenge that all three key players of an ERP implementation (software providers, implementation partners, customers) must address.   Please do not underestimate this under-appreciated challenge.  It can be a huge mindset change for business owners that focus more on functional optimization rather than strategic customer advantage.  The best strategy for addressing late requirements is to plan for this scenario and have the appropriate iterative processes in place to quickly define, assess, and implement requirements that have competitive value to the customer.

Decisions – Not Documents – Move ERP Implementations Forward

Information Alone Does Not Generate Value 

I grew up in a time when information was hard to obtain.  Generating information was seen as a valuable exercise because information was a scarce resource.  The first software development life cycle (SDLC) I learned was Waterfall.  One of the key focus areas for the Waterfall SDLC was documentation (i.e. information).  However, there is a limit regarding what value information can provide.  In our enthusiasm to create information we sometimes go to an extreme and generate so much information that it becomes a roadblock.  What we often forget is that the key purpose of gathering information is to make decisions!

There is a direct relationship between the speed of customer decisions and the speed of ERP implementations.   The faster a customer can make a decision results in a faster implementation cycle.  Naturally, customers want to make right decisions therefore the project team must gather the right information.  To gather the right information we first need to understand the key decisions that must be made as part of the ERP implementation.

Decision-Oriented Information Gathering

Before the project team begins gathering information they first should consider what key decisions the project must make.  The ERP implementation scope will determine both the information gathering scope and key decisions to be made.  Consider the following illustration:

Gathering information to support decisions

Decision-Oriented Information Gathering

Simply stated, the scope for an ERP implementation consists of the software features that will be deployed (product scope) and the project activities and audience for the deployment (project scope).  Once the implementation scope has been defined, the project team can better identify the information requirements.   Gathering the required information and presenting that information in the appropriate context will enable the customer to make both software configuration and fit/gap decisions.  

Utilize Best Practices to Drive Decisions

A best practice is a process, method, or approach that is considered the most effective at delivering a desired outcome.   A best practice is repeatable and has proven itself over a period of time.   For ERP implementations there are two areas of best practices that should be considered:

  1. Industry best practices
  2. Configuration best practices

Once the implementation scope has been clearly defined, the project team should leverage industry best practices to assist the customer in making decisions.  Providing these best practices up-front to the customer will streamline the information gathering process.  As the project team moves from gathering information to driving decisions on ERP configurations and Fit/Gap, configuration and gap decision best practices can be referenced to provide proven knowledge to key decision makers.   Having the right Implementation Partner can have a significant impact on effective information gathering and decision support.  An Implementation Partner may not know every single decision that the customer must make as part of their ERP implementation but they should be able to identify up-front the key decisions required based upon the scope. 

Consequences of Not Driving to Decisions

The ability to make informed decisions is fundamental to ERP implementation success.  I would like to encourage the two key players that impact the decision-making process for ERP projects:

Customers

We live in a society where we like to keep our options open.  Many say that keeping your options open will make one flexible to future opportunities.  Many customers have applied this concept to technology and business systems.  I have seen this philosophy trickle down into a customer’s decision-making approach for ERP implementations.  Customers desire to have a business solution that is both adaptable and flexible.  It is an understandable and legitimate requirement.  However, customers need to keep two things in mind:

  • Keeping your options open (i.e. not making decisions) will slow down the implementation project and increase your risk for failure.   
  • People, not technology, is the most flexible and adaptable component of a business solution.

Strengths of Business Solution

Business Solution Strengths

Implementation Partners

Implementation Partners should be able to provide industry and ERP configuration best practices to their customers.  These best practices should be formally documented and provided early in the implementation where they have the greatest benefit.  These documents will provide evidence that the Implementation Partner can provide a repeatable and reliable service.

Summary

As a project manager, I’ve observed where project team members focused more on producing information and focused less on producing decisions.     Producing information (i.e. documents) is far easier than driving decision(s).    There is a false perception that generating more information will result in more knowledge and enable customers to make better decisions.  Nothing is further from the truth.  Only when the right information is communicated in the right context then knowledge is created for making informed decisions.

Get it wrong the first time! The case for ERP iterations.

We have all heard the phrase “Get right the first time” used as part of an effort to reduce costs and accelerate implementations.  Unfortunately, many have interpreted this to mean doing an activity once.  We attempt to run ERP implementations as a production process.   Good production processes deliver the anticipated result (a known result), for a standard cost, within a given time.  In contract, ERP implementations are more of an exploration process given the customer variability.  Consider the following illustration:

Every ERP Implementation is Unique

Unique Factors for ERP Implementations

A recurring problem we have with ERP implementations is that we try to “big bang” activities and do not provide an opportunity to learn, adjust, and correct for success.   Iterating certain implementation activities will give us that opportunity.  Let me provide you with a just a few examples.
 

Project Estimating

 As stated in the Project Management Institute’s (PMI) Project Manager’s Body of Knowledge (PMBOK) there are three types of estimates or what I like to call “levels of understanding”.  Estimating is based upon our level of understanding regarding effort, scope, assumptions, constraints, and objectives.

Estimating for ERP Implementations

ERP Estimates

As you move further into an ERP implementation the better we are able to estimate. Why?  The key reason is that you have more proven information to base your estimation.  I worked on generating ERP implementation estimates for the last 10 years and I can safely say that I could never generate a definitive estimate without first going through a detailed fit/gap.  Yet, we expect to hit an implementation estimate that was created before any implementation work is done.  There should be no surprise to the fact that most ERP implementations do not hit their budget given the level of accuracy associated with the estimate. 

Gathering Requirements

Another area for an iterative approach is in requirements gathering.  Recently, I was asked what the best approach for gathering requirements was and my response was that there is no one good approach.

Gathering ERP requirements

Methods for gathering ERP requirements

 

Do not limit yourself to one method for defining requirements.  The more methods (perspectives) you employ to gather requirements the greater the probability for success because the project will have the opportunity to create a holistic requirements definition.

Summary

I firmly believe that every customer’s ERP implementation is unique.  Because every ERP implementation is unique there are a large number of unknowns that we try to address given the limited information we have.  We should take a risk-adverse, iterative approach to remove implementation uncertainty.  Do you think this cause and effect could apply to other areas of an implementation (example: testing, development)?   I am interested to hear your thoughts.

IT to Business Alignment for ERP implementations

You’ve decided on the ERP software you need, the Business side has bought into it, and you’ve even picked your Implementation Partner. Now the hard work begins: Making sure that your software deployment strategy sets your company up for success, and that means making sure Business, IT and the Implementation Partner are all speaking the same language.

 

Increasing knowledge transfer and collaboration between business and IT

Driving IT to Business Alignment

First, we need to understand that Business, IT, and the Implementation Partner are coming from different perspectives.   Every party has a knowledge gap to address.  Business best understands their existing business model and the underlying success drivers.  The Implementation Partner understands the ERP software and has multiple years of implementation experience.  IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies.  Alignment is generated only when a common understand of the business model, ERP software, and technology capabilities are shared by all three parties.  When this alignment occurs there is effective communications and faster decision-making.  Decisions move implementations forward. 

Following is a recommended set of steps to develop a common understanding for effective collaboration:

  • Document existing business processes

It is an area that I see many ERP implementations lack.  The typical challenge I hear is “Why document my existing business processes if I know they are changing?”  Here are my reasons:

  1. Business users usually do not have a consistent understanding of their business model.   Going through the exercise of documenting business process will highlight these differences and drive deeper understanding.
  2. Documenting the existing business model will enable you to highlight the EXACT organizational changes that will occur.  How can you manage organizational change when you do not have a clear understanding of what’s changing?
  3. Business process maps can be a key source of information to quickly educate IT and the Implementation Partner on the existing business process model.
  • Educate IT and the Implementation Partner on the existing business model

Business should take a formal, iterative process to educate IT and the Implementation Partner on the existing business model.  The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level.   Following is a suggested approach for conducting this training:

Level Description Suggested Duration
Business Solution Provide an executive overview of the existing business processes, systems, and organizations that make up the existing business solution. 4 hours
Business Process Provide a work flow of business activities that result from a business event.  Key variations and exceptions should be noted. 2 hours for each business process
Business Activities grouped by Role Provide a “day in the life” experience for key roles that support the business solution. 1 hour for each role
  • Complete ERP software training BEFORE the Implementation Partner arrives

Just as it is important for your Implementation Partner to understand your business model and your language it is important that Business and IT have an understanding of the ERP software and its language.  Effective communication is a two party effort.  Taking the required ERP training before the arrival of your Implementation Partner will enable you to more effectively work together.

  • Have the Implementation Partner conduct supplemental ERP software training

Education is an iterative process – you will never learn everything you need to know for supporting ERP  in one training class.  ERP vendors only provide foundational training.  I always say that the Implementation Partner completes ERP training for the customer.  Implementation Partners have hands-on experience with configuration and maintenance of ERP solutions. 

  • Implementation documentation should be more business-oriented

Nothing encourages alignment more than being able to think like your end customer.  Too often we create project documentation that focuses more on technology than business reasoning and justification.  There are times were I am guilty of moving too quickly from what needs to be done to how will it be done without understanding why does it need to be done.  At the end of the day we build software to drive business results.

 Summary

Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust.  Implementing ERP software is an opportunity to generate greater alignment by developing a common language for effective collaboration.  When alignment is achieved then decision-making is effective resulting in a greater opportunity for success.

From the book “Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations” by Brett Beaubouef.

Join the community! 10k followers across 100 countries!

Key Project Management Strategies for ERP implementations

I had a colleague ask me what are the key project management strategies for successful ERP/COTS implementations. I laughed and told my friend that I’m still learning! My friend is an experienced, certified project manager (PMP) so I spared him the foundational best practices (approved project charter, executive support, risk management, communications, etc). These core best practices are well known and documented. I wanted to go to extra mile and provide advice that may not be well known or understood. Following are the key strategies that drive my project management approach for ERP/COTS implementations:

(1) FOCUS

Need to have a clearly defined scope. This includes (a) what’s in scope, (b) what’s out of scope, (c) and who is doing what. Just as important to scope definition is to define constraints and assumptions. Example: for packaged software implementations (like ERP) I create scope statements with the following sections:

i. Packaged software features in scope (product scope)

ii. Packaged software features out of scope (product scope)

iii. Implementation activities and party responsible (project scope)

iv. Assumptions

v. Constraints

A clearly defined scope allows the project team to focus on the activities that have a direct impact on the project objective(s) while filtering out “out of scope” work.

(2) KNOW THE BUSINESS

How can you lead a project to generate value for a business if you do not understand the business? You may be able to perform project control/admin but you will not be able to lead a project team in their efforts. Analyzing whether your project is generating business value is difficult if you do not understand what results drive real value.

(3) ENABLEMENT OVER CONTROL

Would you rather have one person (PM) focused on project scope or the entire project team (including your customer) guarding project scope? It’s been my experience that undetected scope creep starts outside of project meetings – ex. water cooler discussions, off topic discussions. Addressing project scope changes in a change control process is reactive – you already wasted time/effort writing up the potential change. I educate the entire project team on the project management basics of scope, schedule, and resources. I also make the scope easy to understand so that every individual on the project team understands scope boundaries. Individual team members are your first line of defense – the project manager cannot be everywhere at once.

Governance by itself does guarantee business value – a project manager has to do more than just control.

(4) BE RESULTS-ORIENTED

Focus on the right results: On-time, On-Budget are good project metrics but it does not guarantee that business value is generated. Decisions drive projects forward – not action items. As your project evolves your meetings should start generating more decisions and less action items. Running software is a good beginning but is not the end of generating business value.

(5) CREATE AND PROMOTE TRUST

Like the old adage says “Trust but verify!” The only thing I would add to this is to build in an iterative approach so that verification is frequent versus a one-time event. Waiting to develop trust during the Testing phase (i.e. validation) is not a smart risk to take.

(6) BE ADAPTABLE

Do not confuse a plan with execution. A project plan is a simplified model of reality based upon many factors whose definition will further elaborate during the project. Change will occur – be flexible and adaptable to reach the desired goals. A process (methodology) supports achieving the desired results but the methodology is not more important than achieving the desired business results.

Effective project management must be more than coordination and control – it must include enablement and leadership. Always keep the end goal in sight and on the minds of your project team.

Join the community! 10k followers across 100 countries!