7 reasons why configurator projects fail ebook.pdf'

7 Reasons Why Configurator Projects Fail
A “by the numbers” guide on how to make your project a success
For sales, product, process or workflow configuration projects

Contents

Contents ...............................................................................................................2
1: Not Strategic ...................................................................................................4
2: Just Another IT Project ...................................................................................6
3: Doesn’t Integrate ............................................................................................7
4: No Input from Users .......................................................................................8
5: Limited Deployment Options .........................................................................9
6: Difficult to Use ..............................................................................................10
7: No Support for Complex Knowledge .........................................................12
Suggested Actions ............................................................................................15

Introduction 3

Jimi Hendrix: Are You Experienced?
Without configuration technology, vendors have to rely on creative salespeople to
visualize product solutions that might address needs described by prospects.
Prospects have to learn to make do with solutions that may only partially address a
need.

There are times when this inaccurate process may work, but it is a strategy loaded
with risk, high cost and a high failure rate.

Consider the ‘60s guitar icon, Jimi Hendrix. During his short career, Jimi was
frequently seen playing a white Fender Stratocaster guitar. If you happen to know
anything about guitars, you will likely notice in photos that Jimi is playing a right-
hand-model Strat even though he was a lefty. He played the instrument upside down
and restrung with the string positions reversed.

Was this intentional? Was there some perceived benefit to this configuration? Did a
creative salesperson with no left-hand model guitars in stock sell a right-hand model
to Jimi? There are stories that support either scenario.

It is safe to say that the manufacturer did not offer this as an optional configuration. In
addition, it is not likely that any right-hand guitarist would buy a left-hand model and
restring it as an alternative to buying the right-hand model to begin with.

Reason 1: Not Strategic 4

Reason # 1 – The configurator is not
seen as strategic and doesn’t have
backing from senior management.
There is a great temptation to look at these projects as a simple technology solution
applied to the sales transaction process. After all, the sales rep and managers get
some software loaded onto their PCs, the software communicates with assorted back-
office systems and “poof” the sales rep is instantly more productive. Senior
management will be needed to help “tear down” those silos or walls within the
enterprise and to motivate all involved. Without that muscle, the project will
compromise itself into failure.

By the Numbers – Getting Senior Management Buy-In
1.1 Link the configurator project to the strategic plan. Before the project even gets
started, it is best to review the strategic plan to see how this particular
configurator project will help upper management accomplish their goals. A SWOT
(Strengths, Weaknesses, Opportunities and Threats) analysis is a great format that
many senior managers understand.
1.2 Obtain buy-in from other internal groups. A configurator project touches many
parts of the organization (Sales, IT, Engineering, Operations, etc.), so it is a good
idea to gain allies from different groups before the project begins.
1.3 Show the problem. Senior managers tend to be visually oriented. Simple graphics
showing the present quote-to-order system and the proposed system will keep
their interest. Linking the ROI (return on investment) to these diagrams will help
the executives quickly see how the project is an essential investment.

Reason 1: Not Strategic (continued) 5

1.4 Conduct an assessment. Low-cost assessments or informal surveys can be
created. Senior management will pay more attention to an internal request that is
supported by statements from their customers and prospects.
1.5 Develop an internal marketing plan. To many, this may sound like a waste of time.
However, since problems will occur with any project, having a pre-conceived
internal marketing plan can squash the “rumor mill.” Plan bi-weekly update
meetings that show the progress of the project.
1.6 Create a project plan so that senior management can see how quickly the project
will translate into dollars.
Every project will have problems, and some will exceed the budgeted amount.
Making sure that senior management buys-in to the project before it begins will make
these hurdles easier to navigate.

Reason 2: Just Another IT Project 6

Reason # 2 – The configurator project is
regarded as “just another IT project.”
The selling process (the configuration process) is spread all over the enterprise and
touches many groups including sales, IT, engineering, finance, distribution and order
management. The planning and development of the whole solution must involve all of
these organizations and must carefully address the requirements of one group while
simultaneously fulfilling the expectations of the other groups.

This means involvement from everyone during the planning, system-specification,
vendor-selection, implementation and training phases of the project. You can’t expect
IT to “just know” what the organization needs with regard to configuration.

By the Numbers – Extending the Project beyond IT
2.1 Solicit requirements input from all levels and all functional groups using the
system. Kaizen events are a proven tool to accomplish this.
2.2 Include senior-level managers, users, group managers and professionals on the
planning team as well as the implementation team.
2.3 Establish clear goals and milestones for the project.
2.4 Publish plans and progress reports throughout the implementation project.
2.5 Survey the user community throughout the implementation process to help
identify misperceptions, problems and potential conflicts.
2.6 Report on successes, problems and in particular, solutions developed in response
to problems identified by the user community.

Reason 3: Doesn’t Integrate 7

Reason # 3 – The configurator doesn’t
integrate appropriately with existing
CRM or ERP Systems.
Obviously, any configuration solution is going to have to effectively work with your
front- and back-office systems in order to work at all. When your project team is in the
vendor-selection phase, your initial selection should identify those solutions that do
not work with your existing systems.

Some Product Configuration vendors have considerable experience in developing
products that interface well with Oracle, SAP, MS Dynamics, Salesforce.com and other
products. However, others do not.

This is a good time to ask for references and testimonials.

By the Numbers – Assuring Integration with Existing CRM and ERP
3.1 Inventory existing CRM and ERP systems and identify their footprint within your
organization.
3.2 Identify technical and operational ownership for each installed and legacy system.
These people will need to be actively involved in the planning, selection and
implementation phases of your configurator project.
3.3 Obtain technical requirements for integrating the configurator with each CRM
and ERP system.
3.4 Require named references from other companies that are currently running the
chosen system with your incumbent CRM and ERP systems.
3.5 Evaluate risks associated with integrating the configuration technology with any
untested CRM and ERP solutions. Be sure these risks are understood and
acceptable to your implementation team and management.

Reason 4: No Input from Users 8

Reason #4 – The configurator project is
planned without input from the full user
community.
This is a community-wide project. It touches virtually everyone from supplier to customer.
All of these functional elements must be represented in the planning, development and
implementation phases of the project. For any configurator project to succeed every
department, division and employee affected needs to have a chance to own the outcomes
they will be responsible for.

Growing up, we all experienced that point where clothes Mom and Dad bought for our
back-to-school wardrobe just were not going to work for us anymore. Either through overt
refusal to wear certain clothing items or through negotiation, we gained some level of
input into the clothing selection process.

The corporate world is no different. Each of your user groups have specific needs and can
supply unique inputs that will ultimately make the project a success or failure, an okay
system or an excellent system. Designing a system without this input is an invitation to fail.

By the Numbers – Assuring Input Is Received from All Appropriate Groups within
the Organization
4.1 Publicize the configuration project within the organization. This should be a campaign
organized and directed toward all groups, departments, divisions and functions
potentially touched by the project. This should include everyone in the organization.
4.2 Educate everyone about the importance, scope and reach of the project. Emphasize
the need for input from all.
4.3 Survey all areas in the organization touched by the configuration project. Look for any
special needs, potential problem areas and any useful information that might be
helpful.
4.4 Report the findings to specific areas with special concerns or needs.
4.5 Maintain contact with all affected organizational areas throughout the project.

Reason 5: Limited Deployment Options 9

p u b l i c
hosted
c l o u d
on-premise Reason #5 – The configurator doesn’t
web enabled offer multiple deployment and
IaaS . N E T SaaS technology options.
Best practices in product configuration strategies are dependent on having systems that can
disconnected flex and change to meet the changing demands of your business. Deployment options need

PaaS A J A X private cloud
to flex to support the changing direction your business may take, depending on market
conditions and demand.

Select a vendor or supplier that offers a wide range of deployment and technology options
(hosted, on-premise, web-enabled, disconnected, AJAX, .NET, SaaS, PaaS, IaaS, public
cloud, private cloud, etc.). Don’t lock up your ability to move or change down the road.

To extend the clothing analogy a bit further, consider the Sears Six-Way Suit for men.
This garment featured an extra pair of trousers and a reversible vest. All together you
could re-configure the thing into six separate outfits. Okay, it didn’t win any designer
endorsements, but you have to agree that it does provide flexibility.

The world of IT is ever-changing, so it only makes sense to seek flexible solutions where
possible; particularly with major investments.

By the Numbers – Assuring the Best Deployment Strategy for the Organization
5.1 Evaluate the dynamics of your organizational structure. Is your organization growing,
shrinking, merging, acquiring, consolidating, decentralizing or otherwise changing?
5.2 Obtain input from your IT group. Are there any major environmental changes in the offing?
5.3 Gather input from your systems people. Are your incumbent ERP and CRM systems
stable and likely to remain in place for several years?
5.4 Discuss high-level deployment strategies with IT, management and functional heads.
Are there any strong reasons to go one way versus another? Do you have a mobile
sales force? Do you rely on telemarketing? Do you offer web self-service?

Reason 6: Difficult to Navigate 10

Reason # 6 – The configurator isn’t easy
to use.
If the solution is difficult to use, cryptic in concept and requires routine memorization
of multiple rules and steps, it will fail. Your solution should simplify a complex process,
not replace one complex process with another. There are often tradeoffs in
functionality when simplicity is the primary goal. Make sure your configurator is
achieving a good balance between these two elements.

By the Numbers – Optimizing Navigation Options to Your User Group
6.1 Determine if a needs-based configurator or a parametric configurator is best for
your users. If the vendor has
more knowledge than the
user, a needs-based
architecture is best. If the user
is very knowledgeable, then a
parametric-based configurator
is the best choice.

Figure 1: The parameter-based user interface (UI)i on the left, and the needs-based user interfaceii on the right show two different approaches to a configurator UI. The parameter-based (parametric)
configurator requires that the user specifically know which options they need. The needs-based interface asks for the importance of different criteria, and selects the components for you.

Reason 6: Difficult to Navigate (continued) 11

6.2 Train all users in all aspects of the new system. Build refresher and ongoing
update sessions into your training program.
6.3 Survey users 30 to 60 days following implementation to evaluate the effectiveness
of the configurator. Modify the UI as indicated by your survey responses.
6.4 Review those areas where simplicity and functionality were at odds, and look for
ways to optimize that balance.

The world is changing at
an accelerating rate and
the strategies that worked
five years ago may no
longer be profitable. Some
configurators are not used
simply because they have
not kept up with
strategies, product
directions and content.
Additionally, your
customers’ needs and
buying habits may be
changing at an increasing
rate. Is your configurator
agile enough to map to
how people want to buy?
More specifically “Is your
configurator relevant to
your customers’ needs?”

Reason 7: No Support for Complex Knowledge 12

Reason # 7 – The configurator is not
integrated with a rules or constraint
engine.
The more complex your product and sales process, the more important it is to employ
rules or constraint engine technology in your configuration solution. This is what
differentiates a true configurator from mere order-entry technology.

A fast-food outlet cash register equipped with pictures of food products rather than
numeric keys is not a product configurator.

A product configurator must look beyond model numbers and inventory part
availability. A myriad of factors can affect the availability of a product, the
interrelationship between parts and components and assemblies, the final price and
specific delivery requirements. Make sure your chosen configurator can handle these
complex variables.

By the Numbers – Make Sure Your Configurator Can Handle Complexity
7.1 Re-evaluate how easy it is to change business rules in your current application.
Pre-emptive compatibility rules prevent the user from making an invalid selection
that can virtually eliminate configuration errors. Years of modifications can make a
“spaghetti code mix” of business rules difficult to untangle. A robust constraint
engine can represent thousands of business rules with a few hundred constraints.
7.2 Examine the need for nested configuration constraints. Companies that deliver
engineer-to-order solutions or systems require the ability to define constraints of
subassemblies as part of a broader project. Check to make sure the vendor has
delivered this as part of an actual customer implementation.

Reason 7: No Support for Complex Knowledge (continued) 13

7.3 Determine if your past solutions have been able to show missing knowledge. The
modeling environment should automatically highlight missing knowledge.
Some organizations may use a truth table, but there are limitations to this
approach. A truth table is a simple, two-dimensional matrix that represents all of
the possible combinations for a given product, process or service. The first two
columns in Figure 2 show the inputs, usage and color. The third column
(UsageToColor) shows the result of combining usage and color.

Figure 2: A simple truth table with two inputsiii

At first glance, the truth table above looks complete, but actually data is missing.
Not all possible combinations are represented, and this is a limitation of truth
tables. A skilled person can analyze this truth table and find the errors, but a more
accurate method is to use the data from the truth table and create a decision
tree. The decision tree in Figure 3 shows the same data from the truth table, but
it is displayed in a decision-tree format. Notice how two of the leaves of the
decision tree show up as empty. This induced decision tree shows where
knowledge is missing, and this is the power of a graphical representation of
knowledge.

Reason 7: No Support for Complex Knowledge (continued) 14

Figure 3: In the decision tree on the right, the leaves titled “empty” reveal missing knowledge. Someone with a deep
understanding of truth tables would have to examine the truth table on the left to come to the same conclusion.iv

An unskilled person can look at this format and quickly see specifically which
knowledge is missing. Since “90% of the work done on an application throughout
its lifetime is maintenance … [these] decision trees are even more valuable in the
maintenance process because the graphical representation makes it easy to make
changes by dragging and dropping values into the correct tree branch.v”
As the quote above implies, one must think of the ongoing care and feeding of
the configurator. A graphical display of knowledge is becoming more and more
prevalent, and it allows knowledge users to easily make changes.

Suggested Actions 15

Cincom is pleased to have the opportunity to present these eBooks. We would
suggest that you share this eBook with anyone in your organization touched by the
specific areas discussed. Those people will likely have additional feedback.

In many cases, this will open up a spirited discussion for change. We can help you
with that via our consultation services. We have a superb team of professionals who
are highly experienced in all aspects of CRM, ERP, MRP, sales and product
configuration; quotation and proposal management; bidding and estimating; process
improvement; collaboration and sales automation. We offer two consultative tracks for
our customers. Please visit our websites to sign up or to take a closer look at Cincom.

Cincom Front-Office Solutions: www.cincomacquire.com
Pursuing the Perfect Order
Sales and Product Configuration
Quotation and Proposal Management
Pricing
Eliminating Replication and Waste
Guided Selling
Sales Channel Management

Cincom Back-Office Solutions: www.cincomerp.com
Order Management
Operations
Procurement
Accounting
Lean Manufacturing

About the Authors 16

Louis Columbus is a member of the Cincom Complex Manufacturing Business
Solutions Team and a former Senior Analyst at AMR Research.

Louis Columbus’ career has included senior management positions with Gateway,
Ingram Micro and a software start-up, where he served as Vice President, Marketing
and Business Development.

Mr. Columbus has published 15 books on a variety of technology and currently serves
as a weekly columnist with CRMBuyer.com and Informit.com. Mr. Columbus is also
Louis Columbus
currently a lecturer for graduate-level International Business and Marketing courses at
Webster Loyola-Marymount University.

Lou Washington started his career in information management with the University of
Missouri System’s Office of Records Management.

He joined Tab Products Co. in 1980. After being transferred to Tab’s then corporate
HQ in Palo Alto, CA, he was the first Product Manager for Tab’s Tracker systems
software products. In addition, he was peripherally involved in Tab’s Laser Optics
division. In 1990, Lou returned to Cincinnati and joined Cincom Systems.

Mr. Washington’s present role at Cincom is as senior marketing manager in Cincom’s
Lou Washington
Manufacturing Business Solutions area.

17

References:
Randall, T.; Terwiesch, C.; and Ulrich, K. (2003). User Design of Customized Products
Ely Dahan and John R. Hauser, “The Virtual Customer,”Journal of Product Innovation
Management, 19/5 (September 2002); 332-353; Jerry Wind and Arvind Rangaswamy.
“Customerization: The Next Revolution in Mass Customization,” Journal of Interactive
Marketing, 15/1 (Winter 2001): 13-32

Endnotes:
i
Randall, Terwiesch & Ulrich (2003) pg. 268
ii
Randall, Terwiesch & Ulrich (2003) pg. 268
iii
Cincom, 2008
iv
Cincom, 2008
v
Cincom, 2005, p. 5

Cincom and the Quadrant Logo are registered trademarks of Cincom Systems, Inc.
All other trademarks belong to their respective companies.

© 2010 Cincom Systems, Inc.
FORM CMUS1001013 01/10
Printed in U.S.A.

All Rights Reserved

7 reasons why configurator projects fail ebook.pdf'

More Related Content

What's hot (20)

Similar to 7 reasons why configurator projects fail ebook.pdf' (20)

More from Cincom Systems (13)

Recently uploaded (20)

7 reasons why configurator projects fail ebook.pdf'