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.