Applying Pareto’s Principle to ERP Selections

The Pareto principle (also known as the 80-20 rule), states that, for many events, roughly 80% of the effects comes from 20% of the causes.  The principle was developed to explain income and wealth distribution in Italy.  This principle has evolved into a “rule of thumb” in business.  In the software industry the Pareto principle has been applied to several areas:

  • Fixing the top 20% software errors would result in addressing 80% of reported software issues.
  • 80% of the value customers receives from software comes from 20% of the software’s functionality.

ERP Selection Case Study

I recently completed a software selection project for a mid-market discrete manufacturer.  A key activity for software selection is prioritizing requirements.    The following table provides an executive summary of our requirements gathered.

Area

Requirements Pains

Benefit Opportunities

Order Management

207

35 25
Warehouse

93

19

16

Manufacturing

88

17

9

Engineering

44

24

16

Finance

142

8

24

Purchasing

37

23

11

Reporting

77

14

38

Total

688 140

139

 

Allow me to make a few key points.  Gathering requirements is an iterative process.  The objective of requirements gathering was to define requirements to a level where the customer could make an informed decision on selecting an ERP solution.  As the implementation progresses from software selection to implementation the high-level business requirements will be further refined.  Second, as you gather requirements it is important to capture business pains and benefit opportunities.  Pains are limitations or barriers that keep business from meeting their objectives.  Pains may result in additional requirements and/or opportunities for quick wins.  Benefit opportunities are directly related to business requirements and will enable the customer to start with developing the business case up-front versus towards the end of software selection (which is reactive and a bad practice for software selection). 

Requirements Prioritization Guidelines

Requirements prioritization can be a painstaking, time-consuming process.  For the customer in this case study we had a single prioritization session instead of individual, functional prioritization sessions.  As part of the joint session we defined the following guidelines:

  1. Individuals should consider their top 3 – 5 business requirements.
  2. As a group we will determine priorities for all requirements (not just your own).
  3. Priority classifications: “Must Have”, “Valuable”, “Nice to Have”
    • “Must Have” requirements include competitive, strategic, and compliance business needs.  Revenue-generating business processes should drive the majority of these requirements.
    • “Valuable” requirements are usually not “show stoppers” however, they will add quantifiable benefits to the organization.
    • “Nice to Have” requirements are convenient but do not provide a significant or quantifiable benefit to the organization.
    • Rule of Thumb:  Demonstration scripts for vendor demos should primarily focus on “Must Have” requirements.
  4. Using Pareto to estimate requirements prioritization
    • No every requirement should be marked as “Must Have”.
    • Prioritization should be solution-based, not functional-based.
    • 80% of benefit is generated from 20% of effort (requirements).
    • 20% (138) of the total requirements (688) gathered should be prioritized as “Must Have”.

 

Summary

Prioritizing business requirements for an ERP selection project is both an art and a science.  Sorry to say that there is not a simple formula that can help you magically produce appropriate rankings.  There are heuristics like Pareto’s principle that can provide you “signs” that you are heading down the right path.

About these ads

About Brett Beaubouef
For the past twenty years Brett has helped customers select, implement, and manage ERP solutions across five industries (manufacturing, professional services, staffing, retail, and telecommunications). Business process knowledge and experience includes human resources, benefits, compensation, recruiting, time & attendance, finance, resource scheduling, contract administration, services procurement, sales, billings, project accounting, and project/portfolio management. Software selection experience includes evaluation of both ERP software and proposed implementation services. Brett has recently authored a book on leading ERP/COTS implementation strategies.

One Response to Applying Pareto’s Principle to ERP Selections

  1. Pingback: Applying Pareto’s Principle to ERP Selections | Pardaan.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 4,410 other followers

%d bloggers like this: