7 reasons why configurator projects fail ebook.pdf'


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

7 reasons why configurator projects fail ebook.pdf'

  1. 1. 7 Reasons Why Configurator Projects FailA “by the numbers” guide on how to make your project a successFor sales, product, process or workflow configuration projects
  2. 2. 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
  3. 3. 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.
  4. 4. 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.
  5. 5. 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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.
  9. 9. Reason 5: Limited Deployment Options 9p u b l i chosted c l o u d on-premise Reason #5 – The configurator doesn’tweb enabled offer multiple deployment andIaaS . N E T SaaS technology options. Best practices in product configuration strategies are dependent on having systems that candisconnected flex and change to meet the changing demands of your business. Deployment options needPaaS 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?
  10. 10. 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.
  11. 11. 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 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?”
  12. 12. 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.
  13. 13. 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.
  14. 14. 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.
  15. 15. 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
  16. 16. 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 alsoLouis 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’sLou Washington Manufacturing Business Solutions area.
  17. 17. 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. 5Cincom 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