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: Doesnt 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

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 righthand-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

Reason # 1 The configurator is not seen as strategic and doesnt 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 backoffice 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)

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

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 cant 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: Doesnt Integrate

Reason # 3 The configurator doesnt 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

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

p u b l i c

hosted

on-premise

c l o u d

web enabled
IaaS

. N E T SaaS
private cloud

Reason #5 The configurator doesnt offer multiple deployment and technology options.
Best practices in product configuration strategies are dependent on having systems that can flex and change to meet the changing demands of your business. Deployment options need 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.). Dont 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 didnt 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.

disconnected

PaaS A J A X

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 isnt 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
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

15

About the Authors

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 currently a lecturer for graduate-level International Business and Marketing courses at Webster Loyola-Marymount University.

16

Louis Columbus

Lou Washington started his career in information management with the University of Missouri Systems Office of Records Management. He joined Tab Products Co. in 1980. After being transferred to Tabs then corporate HQ in Palo Alto, CA, he was the first Product Manager for Tabs Tracker systems software products. In addition, he was peripherally involved in Tabs Laser Optics division. In 1990, Lou returned to Cincinnati and joined Cincom Systems.
Lou Washington

Mr. Washingtons present role at Cincom is as senior marketing manager in Cincoms 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 ii iii iv v

Randall, Terwiesch & Ulrich (2003) pg. 268 Randall, Terwiesch & Ulrich (2003) pg. 268 Cincom, 2008 Cincom, 2008 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