17
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

7 reasons why configurator projects fail ebook.pdf

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: 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

Page 2: 7 reasons why configurator projects fail ebook.pdf

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

Page 3: 7 reasons why configurator projects fail ebook.pdf

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

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

Consider the ‘60s guitar icon, Jimi Hendrix. During his short career, Jimi wasfrequently seen playing a white Fender Stratocaster guitar. If you happen to knowanything 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 downand restrung with the string positions reversed.

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

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

3Introduction

Page 4: 7 reasons why configurator projects fail ebook.pdf

Reason # 1 – The configurator is notseen as strategic and doesn’t havebacking from senior management.There is a great temptation to look at these projects as a simple technology solutionapplied to the sales transaction process. After all, the sales rep and managers getsome software loaded onto their PCs, the software communicates with assorted back-office systems and “poof” the sales rep is instantly more productive. Seniormanagement will be needed to help “tear down” those silos or walls within theenterprise and to motivate all involved. Without that muscle, the project willcompromise 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 getsstarted, it is best to review the strategic plan to see how this particularconfigurator project will help upper management accomplish their goals. A SWOT(Strengths, Weaknesses, Opportunities and Threats) analysis is a great format thatmany senior managers understand.

1.2 Obtain buy-in from other internal groups. A configurator project touches manyparts of the organization (Sales, IT, Engineering, Operations, etc.), so it is a goodidea to gain allies from different groups before the project begins.

1.3 Show the problem. Senior managers tend to be visually oriented. Simple graphicsshowing the present quote-to-order system and the proposed system will keeptheir interest. Linking the ROI (return on investment) to these diagrams will helpthe executives quickly see how the project is an essential investment.

4Reason 1: Not Strategic

Page 5: 7 reasons why configurator projects fail ebook.pdf

1.4 Conduct an assessment. Low-cost assessments or informal surveys can becreated. Senior management will pay more attention to an internal request that issupported 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-conceivedinternal marketing plan can squash the “rumor mill.” Plan bi-weekly updatemeetings that show the progress of the project.

1.6 Create a project plan so that senior management can see how quickly the projectwill 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 makethese hurdles easier to navigate.

5Reason 1: Not Strategic (continued)

Page 6: 7 reasons why configurator projects fail ebook.pdf

Reason # 2 – The configurator project isregarded as “just another IT project.”The selling process (the configuration process) is spread all over the enterprise andtouches many groups including sales, IT, engineering, finance, distribution and ordermanagement. The planning and development of the whole solution must involve all ofthese organizations and must carefully address the requirements of one group whilesimultaneously 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 expectIT 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 thesystem. Kaizen events are a proven tool to accomplish this.

2.2 Include senior-level managers, users, group managers and professionals on theplanning 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 helpidentify misperceptions, problems and potential conflicts.

2.6 Report on successes, problems and in particular, solutions developed in responseto problems identified by the user community.

6Reason 2: Just Another IT Project

Page 7: 7 reasons why configurator projects fail ebook.pdf

Reason # 3 – The configurator doesn’tintegrate appropriately with existingCRM or ERP Systems.Obviously, any configuration solution is going to have to effectively work with yourfront- and back-office systems in order to work at all. When your project team is in thevendor-selection phase, your initial selection should identify those solutions that donot work with your existing systems.

Some Product Configuration vendors have considerable experience in developingproducts that interface well with Oracle, SAP, MS Dynamics, Salesforce.com and otherproducts. 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 yourorganization.

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 andimplementation phases of your configurator project.

3.3 Obtain technical requirements for integrating the configurator with each CRMand ERP system.

3.4 Require named references from other companies that are currently running thechosen system with your incumbent CRM and ERP systems.

3.5 Evaluate risks associated with integrating the configuration technology with anyuntested CRM and ERP solutions. Be sure these risks are understood andacceptable to your implementation team and management.

7Reason 3: Doesn’t Integrate

Page 8: 7 reasons why configurator projects fail ebook.pdf

Reason #4 – The configurator project isplanned without input from the full usercommunity.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 andimplementation phases of the project. For any configurator project to succeed everydepartment, division and employee affected needs to have a chance to own the outcomesthey will be responsible for.

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

The corporate world is no different. Each of your user groups have specific needs and cansupply unique inputs that will ultimately make the project a success or failure, an okaysystem 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 withinthe Organization

4.1 Publicize the configuration project within the organization. This should be a campaignorganized and directed toward all groups, departments, divisions and functionspotentially touched by the project. This should include everyone in the organization.

4.2 Educate everyone about the importance, scope and reach of the project. Emphasizethe need for input from all.

4.3 Survey all areas in the organization touched by the configuration project. Look for anyspecial needs, potential problem areas and any useful information that might behelpful.

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.

8Reason 4: No Input from Users

Page 9: 7 reasons why configurator projects fail ebook.pdf

Reason #5 – The configurator doesn’toffer multiple deployment andtechnology options.Best practices in product configuration strategies are dependent on having systems that canflex and change to meet the changing demands of your business. Deployment options needto flex to support the changing direction your business may take, depending on marketconditions 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, publiccloud, 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 youcould re-configure the thing into six separate outfits. Okay, it didn’t win any designerendorsements, 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 wherepossible; 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 systemsstable 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 mobilesales force? Do you rely on telemarketing? Do you offer web self-service?

9Reason 5: Limited Deployment Options

private cloud

hosted

web enabledon-premise

disconnectedA J AX

. N E T SaaS

PaaS

IaaS

p u b l i c c l o u d

Page 10: 7 reasons why configurator projects fail ebook.pdf

Reason # 6 – The configurator isn’t easyto use.If the solution is difficult to use, cryptic in concept and requires routine memorizationof 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 infunctionality when simplicity is the primary goal. Make sure your configurator isachieving 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 foryour users. If the vendor hasmore knowledge than theuser, a needs-basedarchitecture is best. If the useris very knowledgeable, then aparametric-based configuratoris the best choice.

10

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

Page 11: 7 reasons why configurator projects fail ebook.pdf

6.2 Train all users in all aspects of the new system. Build refresher and ongoingupdate sessions into your training program.

6.3 Survey users 30 to 60 days following implementation to evaluate the effectivenessof 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 forways to optimize that balance.

11Reason 6: Difficult to Navigate (continued)

The world is changing atan accelerating rate andthe strategies that workedfive years ago may nolonger be profitable. Someconfigurators are not usedsimply because they havenot kept up withstrategies, productdirections and content.Additionally, yourcustomers’ needs andbuying habits may bechanging at an increasingrate. Is your configuratoragile enough to map tohow people want to buy?More specifically “Is yourconfigurator relevant toyour customers’ needs?”

Page 12: 7 reasons why configurator projects fail ebook.pdf

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

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

A product configurator must look beyond model numbers and inventory partavailability. A myriad of factors can affect the availability of a product, theinterrelationship between parts and components and assemblies, the final price andspecific delivery requirements. Make sure your chosen configurator can handle thesecomplex 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 selectionthat can virtually eliminate configuration errors. Years of modifications can make a“spaghetti code mix” of business rules difficult to untangle. A robust constraintengine can represent thousands of business rules with a few hundred constraints.

7.2 Examine the need for nested configuration constraints. Companies that deliverengineer-to-order solutions or systems require the ability to define constraints ofsubassemblies as part of a broader project. Check to make sure the vendor hasdelivered this as part of an actual customer implementation.

12Reason 7: No Support for Complex Knowledge

Page 13: 7 reasons why configurator projects fail ebook.pdf

7.3 Determine if your past solutions have been able to show missing knowledge. Themodeling environment should automatically highlight missing knowledge.

Some organizations may use a truth table, but there are limitations to thisapproach. A truth table is a simple, two-dimensional matrix that represents all ofthe possible combinations for a given product, process or service. The first twocolumns 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 truthtables. A skilled person can analyze this truth table and find the errors, but a moreaccurate method is to use the data from the truth table and create a decisiontree. The decision tree in Figure 3 shows the same data from the truth table, butit is displayed in a decision-tree format. Notice how two of the leaves of thedecision tree show up as empty. This induced decision tree shows whereknowledge is missing, and this is the power of a graphical representation ofknowledge.

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

Page 14: 7 reasons why configurator projects fail ebook.pdf

Figure 3: In the decision tree on the right, the leaves titled “empty” reveal missing knowledge. Someone with a deepunderstanding 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 whichknowledge is missing. Since “90% of the work done on an application throughoutits lifetime is maintenance … [these] decision trees are even more valuable in themaintenance process because the graphical representation makes it easy to makechanges 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 ofthe configurator. A graphical display of knowledge is becoming more and moreprevalent, and it allows knowledge users to easily make changes.

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

Page 15: 7 reasons why configurator projects fail ebook.pdf

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

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

Cincom Front-Office Solutions: www.cincomacquire.comPursuing the Perfect OrderSales and Product ConfigurationQuotation and Proposal ManagementPricingEliminating Replication and WasteGuided SellingSales Channel Management

Cincom Back-Office Solutions: www.cincomerp.comOrder ManagementOperationsProcurementAccountingLean Manufacturing

15Suggested Actions

Page 16: 7 reasons why configurator projects fail ebook.pdf

Louis Columbus is a member of the Cincom Complex Manufacturing BusinessSolutions 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, Marketingand Business Development.

Mr. Columbus has published 15 books on a variety of technology and currently servesas a weekly columnist with CRMBuyer.com and Informit.com. Mr. Columbus is alsocurrently a lecturer for graduate-level International Business and Marketing courses atWebster Loyola-Marymount University.

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

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

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

16

Louis Columbus

About the Authors

Lou Washington

Page 17: 7 reasons why configurator projects fail ebook.pdf

References:

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

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

17

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/10Printed in U.S.A.

All Rights Reserved