The great majority of companies with whom we work perform their own software evaluations without the assistance of an independent consultant. While independent consultants bring a variety of benefits to the table during the ERP selection process, a key element that strong consultants offer which is commonly missing when companies perform their own enterprise software evaluations is an onsite scripted software demonstration. Read More…
The Importance of Scripted Software Demonstrations
So, what exactly is a scripted software demonstration? A scripted software demonstration is one in which the company has documented a series of its key business processes that it wants to see all potential ERP vendors demonstrate in a consistent manner.
While the scripted demo would generally touch all functional areas of the business, the most important areas of focus would fall into three main areas:
- Customer-facing (i.e., quote to cash, customer service, customer self-service)
- Operational (i.e., demand to pay on the procurement side, inventory management and warehouse operations, manufacturing planning and execution)
- Compliance and control (i.e., financial management and reporting, lot traceability, quality management, industry compliance)
Sample Data
In addition to the script which describes the specific processes, good scripted software demonstrations will also include sample data and instructions that tie to specific processes to be reviewed during the demo. The sample data should be sufficient while not excessive – 2-3 customers, 2-3 suppliers, 2-3 purchased items, 2-3 manufactured items with associated bills of material or formulations and routings, and sample customer pricing scenarios.
Some companies with whom we’ve worked performing evaluations have merely dumped complete sets of data from their existing legacy database of products, customers, vendors, pricing, etc. In these cases, vendors will cherry pick the data yielding inconsistencies as to which processes show which data or even how much of the data is used, if any.
ERP Scorecards
The script should also have an accompanying ERP scorecard which will be used by the software selection team members to score each of the processes on two scales – one that defines whether or not the vendor showed the specific process performed by the software, and the second defining how easily the process accomplished the desired task. There should also be an explicit scoring scale (i.e. 1, 3, or 5) where exact wording is associated with each of the scores and communicated to all participants during the scripted demo process. That way, there is an attempt to make the scoring processes as homogeneous as possible and allows for a true “apples to apples” comparison.
The facilitator of the demo, usually the internal project leader of the selection process, needs to be sure to nudge the participants to score the process in real time. To use a sports analogy, there are a lot of people who keep score of the top of the first inning of a baseball game, become distracted or bored, and stop. There are very few who keep score of the entire game. Make sure your participants score each process of the demonstration as it occurs.
Scorecard Evaluation & the Software Selection Process
Once a given section of the demo is completed, the finalized scorecards should be collected immediately to help minimize the risk of a misplaced scorecard. When the demonstration as a whole is completed, the scores should be compiled for each software vendor and added to a summary for all of the demonstrations.
Without a scripted demo, many software evaluations become a “beauty contest” where people make decisions strictly on which solution looked the best, or they become a “show and tell” exercise in which the vendor performing the software demonstration merely shows their respective system’s strong points rather than touching on all critical requirements for the business. To avoid falling into this trap, the selection team should make every attempt to dig under the covers and make software vendors show them real transactions being performed in their systems with the sample data provided rather than just showing sample screens with pre-populated data which may or may not work in a production environment.
By following these practices, a scripted software demonstration should yield a quantitative measure as to which manufacturing or distribution software solution would best align with the key business processes and would be easiest to use by a given company. This will help the team narrow down the field to a preferred solution so it can move into a final due diligence process with that vendor. For additional information about the overall ERP software evaluation process including more detail about scripted software demonstrations and a sample scripted software demonstration template, please review TGI’s free ERP Software Selection Tool Kit.
Tags: Scripted Demonstrations, Software Selection, Technology Evaluation
Scripted demonstrations are great for creating structure – but it has a couple of downsides.
The customer only sees what they think they need. In this fast changing environment where there are new technologies and techniques that can be employed by customers – a script is going to force the ERP vendor to show exactly the same things that the customer has right now, and they will remain in the same rut that they are already because they are not allowed to see differentiating features from all of the other vendors.
As a sidenote – if the consulting partner does create the script for the customer, then that’s great – as long as the customer knows why it’s important. There have been many situations where we have been demonstrating (as you’ve probably guessed I work on the other side of the table) and we ask – “Why is this important?” toi gather more information – and the customer has no idea. The selection partyner may, but we just get a blank look, and then all scoring goes out the window.
With scoring, make it simple – either the product works, or it doesn’t. There is no need to have complicated scoring from 0-10 or other wide ranges – because the users that are scoring are not able to judge with great accuracy if that was a 7 out of 10 fit, or a 8 out of 10 fit. This is not neccessarily for the software vendor, but just a mercy ple for the poor people scoring.
Be realistic with the script as well. We have come to demonstrations where we have had a 700 point script (not from you all) that we were asked to do in 4 hours. We can’t even read the script in that amount of time – and rushing through the features is of no benefit to the customer (who really just sees a flurry of screens) or to the vendor (who never feels like they have done a good job).
Also, be flexible with the organization of the script. All software products have an ebb and flow that makes them unique. When you try to divert them, or twist them in ways that are unnatural to the product, then they look clumsy. When you can show the workflow in the way that it was intended (and that the users would use the product), then the education process works much more effectively. A suggestion to all of you that are creating scripts may be to break it up into bite sized chuncks that can be re-arranged to fit the demo. We (the vendors) will get to all the points, just not in an order that is unnatural.
Finally – a plea to the Selection Vendors. Educate all of the users before the demonstration starts. Software vendors hate going first, because they spend all of their time teaching customers what ERP is, or why they need to trace their products through the lifecycle, or why process manufacturing is different from discrete. There is a myth that the first people in the demos loose because people forget about them after 3 other demo’s. I don’t think that’s the case – I think that it’s because they spend all of their time discussing and educating customers on the process that they are about to embark on, and don’t show enough product.
I’ll get off my soap box now 🙂
Relative to Murray’s comments, I absolutely agree that if the customer doesn’t know why an item is important, it shouldn’t be on the script. Don’t just take a script either from a consultant, vendor, or a buddy at another business and assume it to be your script. Tailor the script to be specific to your requirements.
Also, it is fairly common to see “one-day demos” with scripts that could take 2-3 days to perform in an appropriate level of detail. Prioritize the points within the various sections of the script; have the highest priority items demonstrated first, and then go back to secondary and tertiary items in a given section as time permits.
Regarding scoring, a common, granular scoring metric should be created, shared, and used by all participants, not a scale where one can select any whole number from 0-10 at will (i.e., set up a scoring system where 10 means…, 7 means…, 3 means…, etc.). Also, encourage participants to note why they’ve scored items a certain way so they can discuss and support their rationale when the team gets together to debrief.
However, on the point of “a script is going to force the ERP vendor to show exactly the same things that the customer has right now, and they will remain in the same rut that they are already because they are not allowed to see differentiating features from all of the other vendors” – not if the scripting process is done correctly. A company going through the software selection process needs to have a plan of where it wants to be over the next 3-5 years and have the demo script reflect these future business plans and objectives. From there, the organization can select the software solution and associated vendor who can best help them not only today but over the long haul to achieve their long-term business objectives.
Finally, regarding the plea to selection vendors about educating their clients, this is a very good request. Being the first ERP vendor to demonstrate their product offering can be a substantial disadvantage. There is a major advancement by customer participants on the learning curve from the first demo day to the second – both from the standpoints of the demonstration and associated scoring process and their functional knowledge.
The last vendor to demo has four key advantages – first, the customer will have progressed as far along the learning curve as possible by the time the last demo occurs; second, there will be some additional discovery of functional requirements and questions to ask through the demo process and the last participant will be able to address all of these including ones that just surfaced during the last day; third, just like in the Olympics, those who are scoring are less likely to give 10’s to the early participants just because they may see something they like better from ensuing competitors; and finally, people will naturally remember more of the most recent demo than the earlier ones – especially if the demos are spread out over any protracted period of time.
Generally, there will be a pecking order of the 2-3 finalists as to how they are viewed prior to the final demo. We encourage you to have your third choice going into the finals demo first, your second choice go second, and your first choice going into the scripted demo process go third.