ERP Selection Case Study Audio Conference Transcript

Read Comments
J. Dowling - June 22, 2001

Introduction  

This audio conference, based on recent TEC selection engagements makes some presentations hopefully valuable to buyers and sellers of ERP software packages.

What we are going to describe is:

• the demonstration phase
  
  
• leading up to the demonstration phase
  
  
• and the actual execution of ERP package demonstrations clients

The product demonstration phase causes two agenda frequently to come into conflict.

One is the supplier's agenda to present its product in a way that has proven successful for them in the past. But there is also an agenda for the buyer who wants to see it fully demonstrated in a way that they will be using it when it is fully implemented, so they can appreciate its value.

When those two agenda are harmonious the demonstrations run extremely well, and the message gets across very powerfully, but it doesn't always happen that way.

Preparation is essential for both the suppliers and the buyers of an ERP Package.

How Do We Define Success?  

For the supplier a successful demonstration exposes valuable differentiation from competitor products and it demonstrates a seamless flow of business processes and the automation of those processes.

For the customer, success is seeing those differences. Seeing how one package differentiates from the other and appreciating the value of it, whether that value is high or low. Being able to clearly see that there is a difference is considered a successful demonstration.

Comments on Vendor Preparation  

TEC has prepared for and conducted many product demonstrations. Interestingly a number of them of have included the same products being demonstrated by different teams from the same company or by different partners of the company.

It is not unusual for three selection engagements involving the same supplier to appear to involve three different products. The RFI responses are not consistent. We can often see that a proposal will include ratings of features and functions very different from what previous ratings have been and also different from what we have seen demonstrated in the product.

We also see different teams making the presentation and they are not all equally capable of showing their product in the same light.

These demonstrations are for companies with similar process flows, for example, they have all attended the same lean waste chaser manufacturing six sigma type of business improvement courses and they have already fixed with a partner, for example, a consulting firm, on where they are going improve their business. TEC is engaged to execute the selection process.

We provide business scenario scripts that are very similar for the most part. If a supplier's business is providing to the ETO, manufacturing, or areo space defense industry, it is not unlikely the scenarios are very similar - differing only by peculiarities in customer engagement, manufacturing flow, or the specific product, but the for most part they are very similar.

What we do find is that the suppliers rarely share scripts across their organization, and it is even more rare where they do share them, does the team that provided a very good demonstration and if fact won at one location will appear at the client site be used to do the demonstration again, and even improve on it.

We make it very clear to our clients that we provide very similar business scenario scripts to the customers and that we talk to the customers and share the information before we enter into the process, so the customer has the opportunity to vet our scripts.

Our clients are aware that a particular supplier has that same information available to them and it is very obvious to our clients when the vendor hasn't shared the information within its organization. When it isn't shared the customer often says, we feel we are dealing with a local office or a regional outlet or partner and not with the whole company. That can be taken as a slight by our customers.

Leveling the Playing Field  

Well lets start with our Goals and Methods for doing product demonstrations.

In the selection process we provide multiple steps of multiple parts of the selection and implementation and planning process in what is an idealized state, By building a set of business scenarios that represent an ideal future, the "Could Be" process. We map features and functions of an idealized future to a particular business scenario and assign priorities that describe how the company would love to operate in the future, if only they could find the right ERP product. When the supplier demonstrates the products to the scenario, the selection team rates the degree of fit of the features and functions as demonstrated.

As much as 20 to 25% of the overall decision is driven by the results of these demonstrations. This makes it crucial that the demo teams understand both the business scenarios and their own software products. Preparation has proven to make a significant difference.

One supplier, for example, challenged the scripted scenario as a reasonable way of assessing their product. Their statement "We want to be a partner with you, not just a software supplier, we commit to making our product work for you."

The customer responded. Is your company invested in our company? What risks are you willing to take that we deliver anticipated business value after investment in your software product? Discussion ended at that point, but it came back later during the final phase of quotations.

It was brought back as the question. What exactly do you mean by partnership and how does that show up in product pricing and delivery? This ended up going into the decision process and being applied to all the suppliers.

During product evaluation Partnership is not the issue. Validation of claims and process fit is the issue during the selection process phase.

Another supplier spent an enormous amount of time preparing and they presented a number of people to demonstrate the product, however, they scrambled the script elements in a way that prevented the team from scoring them, and the supplier even alienated themselves by challenging the way the company chose to conduct its business.

It is critical to our methodology to separate the product features and functions from what is going to deliver the business value at the end during the business demonstration.

It takes a good deal of discipline on all parties to keep that in mind and keep the playing field level.

The Value of the Process  

But what is the value of a rigorous process? What we have seen is that the process needs to be auditable.

There comes a time when some key stakeholder challenges that the process wasn't done properly, often because they did not really agree with the outcome. By having the data about the selection, what are the criteria, what are the priorities, clearly documented and clearly weighed in terms of driving the decision, the discussion around who really is the winner and who really can provide the best solution becomes an assessment of:

Did we use the right criteria, did we rate properly, and were the products presented in the best light? An auditable process becomes a documentation of the decisions made during the sales process to test the products.

The size and difference of gaps are being accessed and between the software functionality and the product - those are all being recorded on a detailed level.

Very often the decision among various products is not whether the product is capable of delivering something, but how much modification and risk is involved in making it do it exactly the way the client wants it done. It provides some level of insurance to the team that later during the selection process if new criteria come in, the team can go back to suppliers and collect additional data They don't have to start from ground zero, they can put the new requirements into the demonstration or them can validate claims through customer interaction.

What about comparisons?  

When comparing ERP products, it is not comparing apples to apples. They are all different, not completely different, but every package has different strengths and different weaknesses and they accentuate different parts of the process enablement. So we don't need to compare apples to apples. We don't want to create the lowest possible common denominator.

What we want to do is look at the ideal ERP system. What if you took the capabilities of all the ERP packages and combined them into one idealized system, added to them the unique capabilities you find in your business that do not show up in the existing packages, and then you rate every possible supplier against that.

What it says is that a product that has weakness in one area may shine in an area that is of paramount value to the client, and therefore score higher in the rankings. It isn't every factor being rated yes or no, there are shades of gray. These shades of gray are set by the client during the demonstrations and other interactions with the suppliers.

And by having the map, the test engine (the TESS/ERGO model that TEC brings to the party) already set up, those differences can be brought to life. In any case, when the decision is being driven by a small difference that fact causes us to look closely at that area. To see if it is the right criteria that is being applied and if we have really seen what the product can do. So we don't measure one package against the other. All packages are benchmarked against an idealized model in a new business practice.

The customer also wants to validate the information gathered by their interactions with other customers who have been satisfied by the supplier. They want to see if they can be equally satisfied. And that leads to some significant information being revealed during demonstration.

Supposing a customer reference indicated that a particular ERP component, say Serialized Product Control, is very powerful within their organization, and during the demonstration the script shows clearly how to demonstrate that, but the supplier can't do it in a demonstration. Going back to the vendor's original customer reference because that happened and finding out that there is a systems integrator in the mid-west who has solved that problem with a package, certainly can help in driving a decision.

When we apply a rigorous process, what we are trying to do very often is to avoid internal politics and preferences. That is the benefit of coaching both the supplier and the customer, to avoid pitfalls.

We had an engagement a while back where the supplier had won several arguments but kept thinking they were losing them. They repeatedly came back to the fact that their COBOL-based architecture really shouldn't be an issue. Well the client had already dismissed that. It was carrying less than one/one hundredth percent of the decision. And yet by coming back to it over and over again, that it wasn't a weakness, don't consider it a weakness, the client kept raising the amount of the decision that was attributed to that factor. They became fearful that there may be a problem there which they weren't aware of and couldn't reveal.

The data about the product and the demonstration really needs to be qualitative. By using a decision support tool, although you may be rating things on happy face, sad face, or angry face, those all result in numbers and numbers are what quantifies the perceptions of people.

What is going on between the TEC consultant and the suppliers is coaching them on what the customer is looking for without giving any one supplier an advantage over another. Often that coaching comes in conflict with the suppliers predefined method of demonstrating the product and conducting the sale. We will come back to that later.

But what about good customership?  

What is a good customer? What do suppliers tell us is a good customer?

First the methodology is the clear to all parties. That they understand what is going to be rated, and how they are going to be rated, and what they are going to be rated on. Certainly we do not provide the detail of priority during the discovery process, but we do make it very clear to all the suppliers, what is expected.

If the customer sticks to that and commits itself to the work that it takes to set up exactly what they are going to rate and how they are going to rate certain options, as well as how they are going to choose the supplier, then it pays off for both the supplier and customer.

The allocation of people is important. Suppliers tell us that switching people out of teams within companies protracts the sales process, sometimes even exhausting the supplier's commitment of resources who want to work with a particular customer.

A good customer builds a powerful team empowered to make a decision. Again a potential conflict because often the supplier will want to talk to the bosses of the people who are empowered to make those decisions. Those people can only view this as going over their heads and resent the supplier for going over their heads to get a decision made.

Key members must commit the time required to do the project, it cannot be the night job, it must be the day job. Information needs to move very quickly. It needs to be resolved very promptly to eliminate delays, which may prolong the process, particularly delays that may give one supplier extra preparation time versus another. The team must be enabled to address the proper issues and make the proper decisions. By looking at a methodology and spending a good deal of time up front, validating with others who have used the product, is very important to the process of developing good customership.

Where does it start in terms of good customership. Prioritizing business requirements really is the element of driving the selection process.

Prioritizing Drives Success  

If we look at 5, 6, 10 ERP packages, it doesn't take a lot of work to reduce it down to four or five potential candidates, sometimes referred to as the usual suspects. They are the ones that show up pretty much on everyone's radar screens. They can all do the job, the question is how much will it cost and how much time does the client anticipate in terms of closing the gap that clearly exists between the delivered product and one they truly want.

How do they do that?

How are they differentiated? Again we are back to the scripted scenarios. The pictures that describe how the company wants to work in the future. That process alone removes a good deal of the doubt on the client's part about what it is that they want to buy. Getting those issues out of the way and getting those down to a documented set of requirements with the capabilities that have been prioritized, really brings clarity to the where the company is going.

At the same time, asking the questions: How much more business could I do? How much more money could I make? How much money could I save?, provides the return side of the return on investment for any ERP implementation.

So first they identify the processes, then the processes get decomposed into ERP system functionality, that are written for each supplier. A good deal of latititude has to be given. So we are saying, although we are measuring certain features and functions, we really want you to demonstrate these business processes; how our company will function in the future.

That's takes a little bit of work on the part of the client, but the TEC selection consultants, having seen these products over and over again, know pretty much the degree to which the product should be able to be demonstrated to deliver these capabilities.

Another key factor is current press. What happens when the client looks at the cover of Computer World, or Newsweek magazine, or the Wall Street Journal and there is a headline article about another ERP implementation that went bad. Whatever comes up on those lists, especially the web sites that list the recent technology disasters, generally gets higher priority on the initial cut than the features and functions that are really going to deliver business benefits. The consultant needs to take that into consideration.

Also we can find many more successful implementations of each package than we can find disasters. It is hard to find a customer reference list that will give you complete information about the real bumps and disturbances that took place during an ERP deployment, but that data is available and the client and suppliers know about it and they collect it. The matter is how important is it relative to you.

How will suppliers respond? Is it the implementation that was the issue or is it something else? We have done that research and we provide that to the client.

Define What You Want  

If you don't know exactly what you want to do and you go out and pick a product that does that, the chances are you are going to have a rough time in implementation.

If you can clearly define what you expect to the system integrator and what you want the product to do in the end, you take a lot of risk out of the selection and you will be a lot more satisfied in the end.

The buyer needs to buckle down and say, if I prioritize things, am I willing to give up certain things, or am I not willing to give them up but I will prioritize them low. That says that rather than a short list of 100 or 200 criteria, the buyer would like to look at more, hundreds, sometimes thousands of criteria. This kind of demonstration will involve as many as 450 features and functions of an ERP package to be accessed. Sometimes there are redundancies, but more often then not, they are eliminated.

What Have We Learned?  

Customers don't often know what they want and they need some coaching. It is often helpful to have suppliers demonstrate to them what is possible.

For example in a recent engagement each supplier was given the opportunity to make a specific presentation about cost accounting, the capabilities of various systems to address their business.

In another selection, where digital media management was involved, third and fourth party briefings were arranged to explain what digital media management was all about and who are the players the company might want to access for such technology.

But coming back to the TEC method, the business scenarios tell the story, including the challenges and opportunities that the client has identified. Beyond that the style of each presentation is up to the supplier. It is vital to respect the importance of sticking to the script in the order the script is written.

By deviating from and reorganizing the script to make the demonstration easier, the supplier runs the risk of making the product look incapable of doing what was requested or lacking the flexibility to handle the script. A supplier who comes back with a reordered set of scripts in advance and says this is the way they prefer to demonstrate their product, that this makes more logical sense for the way their product is designed and they are am prepared to work with the client, is also valued.

As long as the scripts are presented in the order the observers expect them, they can rate them and they can understand.

Show Versus Tell  

I can't over emphasize the importance of Show versus Tell. It seems to be almost impossible for most product demonstrators to avoid turning around from the screen and lecturing for long periods of time when they should be demonstrating with mouse clicks and key strokes.

Now there are exceptions. Certainly there are occurrences where the execution would be inordinately expensive for the supplier to configure to perform a particular task, for example wiring in a particular time selection system to hooking up to an EDI system.

Clients want to see the product in use on demo data. They don't want to listen to people talk about how the software might work, could work, or will work in the future.

Another critical success factor is a skilled presentation by presenters with a broad understanding of the software. When presenters are stumped or the sales teams brings a large number of people each skilled in only one aspect of the software, it makes the software appear cumbersome and difficult to use.

When a single demonstrator can walk through the entire script process and there are one or two additional people in the room to answer specific questions about how early receipts are handled, how a master production schedule is produced, that becomes a very powerful lesson. And, it doesn't hurt when the demonstrator says they have only worked for the company for about five weeks.

On the other hand when the company brings a cast of thousands that all seem to talk different languages and don't seem to know how to connect to what the previous person demonstrated, the complexity just oozes out of the demonstration.

Another factor that sometimes occurs is what I'll gently refer to it as slamming. Sometimes implicit and sometimes explicit.

All suppliers at a TEC selection know who their competition is throughout the engagement. Our experience is that some suppliers really misunderstand their competitor's strengths and weaknesses and they apply presentation techniques that are often inappropriate to a particular application of their product.

We had one occasion where the supplier in order to demonstrate how easy it was to use their system, had each presenter take some data from the screen, such as an Excel spreadsheet and move the data from an access database to another so the user could work with that data alone, generating reports and augmenting it. All through the demonstration we could see the stomachs churning on the selection team. They had rated the ability to prevent people from downloading data to their own personal systems very highly as a selection criteria.

On another occasion, the supplier continually came back to a strength in the product even though in the end that that was not rated highly as a driver, but it was indeed a differentiator for their product.

Do we get the best product out of every selection?  

Every supplier asks that question, especially every supplier who didn't win the deal. Did the buyer really pick the best product?

Well. What's the best? It's the one that fits the selection criteria. And more importantly, it's the one the team can commit itself to implement to deliver the business value that is on the ROI document they submitted with their capital appropriation request. Really the only question is, Did they have a bad product to select from? Was there a loser in the mix that if they had picked it, if they had fallen onto that as the best product to fill their needs would they fail?

Suppliers do not want implementations to fail and they want easy successes, ones that don't run the budget up, ones that makes it easy to sell the next deal. TEC understands product capabilities. Those two things combined will prevent bad products to ever getting into a selection. It is our strong commitment that any supplier in the final round can do the job.

Either customer reference, product capability, or previous demonstrations have indicated that the requirements can be met by those products. But the decision does significantly depend on the demonstration. It depends on it to the extent that client makes an assessment that it would be less risky and less costly to close the gap between the optimum solution and any other solution to their desired business processes. The bottom line is: What's the risk and what is the cost? Risk is expressed both in terms of overall success, and in scheduling implications, costing implications, and staffing implications.

When Good Products Collide  

Now I'd like to present the picture of what happens when good processes collide.

One supplier of ERP packages has a very effective and quite extensive process for gathering the information that would help determine what the implementation costs would be for their product.

Our process has prevented that from happening either because our customer would prefer not to deal with the implementation cost during the selection, or because the implemenation cost estimates couldn't really be made until the new process design was done and that wouldn't be until further down the cycle.

That is something that really ought to be fixed and in recent engagements we have included the application of implementation cost by both the suppliers and the customer into the selection process, so that data can be used as well.

Another has a tool for determining where their product will shine but also contains a methodology for computing return on investment for that product in a particular business situation. That's another area where customers have to make the choice.

Do they want each supplier on the short list, and that can be as many as four, to meet with their staff and their company to determine what the ROI is and to make that determination or do they want to do it themselves and not have three or four teams working their way through the company?

That also needs to be addressed. We are also stressing that suppliers of ERP packages and software packages in general know pretty much how to succeed with their product. Making that information available to the client during the process can be very useful to them.

The question goes back to how do you level the playing field?

Other Issues  

The last two issues are things we cannot deal with directly.

One has to do with Geography. What we have ended up with on at least one occasion is the geographic representative for an ERP supplier said, "but you are not in my market, there is no one your SIC in this particular geography so we can't sell to you and we don't know who to connect you with".

The time spent connecting with the supplier was wasted. They did show up, but as a company making a cold call to the client during the selection part of the engagement.

Another one which can be a bit disconcerting is where a local rep for an ERP supplier is not buying the message of their partner. When the partner is saying we are making big moves into the mid-market and scaling back to much more concise representations of out product, etc.

But their local representative is saying "You are too small. you don't fit our profile." And they can't be convinced to participate. There isn't much we can do about that either.

How does TEC handle this? We are committed to working with each software supplier independently to ensure that all options are maintained and accommodated throughout the process. Those options are presented to the client, but the client then needs to make the call to determine whether or not they want to extend their selection engagement or whether they want to pool the options much like the press corps does. That is, have one supplier do the ROI calculation, and another one do the implementation cost estimates, just to set benchmarks for the whole group, but not necessarily share the data.

That is going to be a new area of exploration for us, to be sure the playing field is level with regards to each supplier against the other, but also that the relationship between the potential buyer and the supplier benefits the internal processes for both companies.

JDA Portfolio: For the Retail Industry Part Six: ERP Vendors and User Recommendations | JDA Portfolio: For the Retail Industry -- Part Five: Analysis of Market Impact | JDA Portfolio: For the Retail Industry Part Four: More JDA Portfolio 2004.1 and Microsoft Alliance | JDA Portfolio: For the Retail Industry Part Three: JDA Portfolio 2004.1 Continued | JDA Portfolio: For The Retail Industry Part Two: JDA Portfolio 2004.1 Components | JDA Portfolio: For the Retail Industry Part One: Event Summary | Glossary of Enterprise Applications Terminology Part Two: Just-in-Time to Extensible Markup Language | Glossary of Enterprise Applications Terminology Part One: Accounts Payable Through Internet | Understanding SOA, Web Services, BPM, and BPEL Part Two: BPEL and User Recommendations | Understanding SOA, Web Services, BPM, BPEL, and More Part One: SOA, Web Services, and BPM | Epicor's Mid-Market Pitch Becomes Higher For (One) Scala Part Five: More Challenges & User Recommendations | Epicor's Mid-Market Pitch Becomes Higher For (One) Scala Part Four: Merger Synergies and Challenges | Epicor's Mid-Market Pitch Becomes Higher For (One) Scala Part Three: Market Impact | Epicor's Mid-Market Pitch Becomes Higher For (One) Scala Part Two: How Scala Complements Epicor | Epicor's Mid-Market Pitch Becomes Higher For (One) Scala Part One: Event Summary |