Selecting a piece of enterprise application software has never been an exact science. Vendors' hype, consultants' conflict of interest, users' doubts, tediously long selection processes, and unclear decisions rationale are some of the unfortunate watchwords for most selection practices.
It is daunting for corporate IT buyers to discern the true capabilities, strengths and weaknesses of a given enterprise application suite, given the propaganda that pervades vendors' endeavors to differentiate themselves (see Beware of Vendors Bearing Solutions). When making strategic IT acquisitions Buyer's project teams, inundated with an abundance of available products and technologies, have a difficult time translating the content of glitzy marketing slides and grandstanding presentations into the deliverable products.
Still, as a 'one-size-fits-all' product is still not quite a viable possibility, almost every product can win provided certain set of requirements. The Catch 22 for both buyers and vendors/VARs is to pinpoint the right opportunity in this ongoing 'dating game'.
In Part 1 of this article it was suggested that an effective RFI/RFP process can streamline the selection process avoid the pitfalls of past selection processes.
Part 2 proposed a solution, and this part applies the solution to three mid-tier ERP vendors, Epicor, QAD, and Ramco Systems.
Part 3 illustrated how with differing selection criteria any one of the three vendors could win.
Part 1 - Overview of the Problem
Part 2 - Presents a Solution
Part 3 - Presents examples of applying the Solution
Part 4 - Makes User Recommendations
Perhaps the most important take away from this analysis is the significance of buyers researching technology vendors before determining the short list, while vendors/VARs should research the viability of the opportunity beforehand. Issuing a comprehensive Request For Information (RFI) to a number of vendors is an important first step in the selection process. Once the RFIs have been returned, analyze each RFI to determine the strengths and weaknesses of each vendor as well as the relative importance of each item on the RFI. This, proverbially harrowing exercise need not be that dreadful, as shown in Parts 2 and Part 3 of this article.
Experience has shown that more than 95% of functional and technical requirements show up time and time again. These have been captured for the discrete manufacturing field within the TEC's ERP Knowledge Base (the Process Manufacturing Knowledge Base creation has also been under way). The remaining 5% are requirements peculiar to your business and industry (e.g., multiple children bills of material in the electronics industry), which need to be defined from scratch and prioritized appropriately. But, these should only be a small fraction of the entire immense RFI effort. Likewise, vendors'/VARs' effort in filling the new RFIs should only be limited to filling that 'delta' document.
Given that within a specific client size range and vertical industry, many renowned applications packages are reaching a functional parity (convergence), users might be better off by skipping the painstaking process of RFP preparation, staring confusedly at vendors' responses, and trying to figure out who has the most pluses regardless of the individual importance of the functionality criteria. It is better for organizations to focus on the handful of business objectives they need to achieve and the ways to measure their success. They may benefit from turning to an objective third party expert that has an ability of translating these strategic business objectives into tactical functional and technological requirements, and, in almost no time at all, recommend the two or three most suitable candidates that should proceed straight to a software demonstration phase.
TEC's ERP Knowledge Base
TEC's ERP Knowledge Base based on WebTESS® includes a comprehensive set of 21 RFI responses combined with a decision support tool to reduce the time and expense of examining vendors and determining the short list, while vendors/VARs can check out how they stack up against the competition and what the best course of action in every particular situation should be.
As a summary, the following are some of the main mutual benefits that all the parties would benefit from being on 'the same page':
- Upfront identification of issues and negotiation perspectives, enabling more efficient and productive negotiations
- Enabling the solution implementers to be better aware of the challenges
- Enabling vendors to be aware of product gaps with client needs
- Manage expectations of the implementation results to be realistic
- Enable better implementation planning
- Enable future project discussions between the vendor and client to be processed more effectively, since past data is intact and in a form that is reusable and can be updated easily
Make no mistake - TEC does not expect anybody to acquire a crucial and costly piece of technology based only on online research, however thorough it may be. Users are therefore advised to conduct a thorough analysis of vendor strengths and weaknesses in the following major areas: product functionality, product technology, product TOC, corporate strategy, corporate viability, and corporate service & support.
The preceding analysis constitutes a high level evaluation on certain parts of product functionality and technology that should be replicated and expanded upon for the remaining key criteria areas. Only by a diligent process of evaluation that includes a plethora of other factors influencing the decision such as scripted scenario demonstrations, site reference visits/calls outcomes (see Client References - Still A Valuable Part of Vendor Selection?), product flexibility (e.g., customizability, interconnectivity, data conversion, etc.) can users hope to select an enterprise business system that will serve their organizations and deliver expected benefits. These are, however, more of a 'soft', subjective nature, and require an actual encounter with the software; this is where the human side will get the right of way over machine in the above-mentioned human-machine combination. For more information, see An Overview of the Knowledge Based Selection Process.
Research is a Start
However, one has to start from somewhere, and there is no better place to start researching enterprise software than from their functional and technical capabilities. Despite the allegations that these capabilities have been converging across the range of products, and that their importance in selecting enterprise software has been diminishing by the day, that is not exactly the case, as shown in the examples with three vendors in Parts 2 and Part 3.
Even in a hypothetical case of two vendors differing by only a few percentage points of required functionality, it is very likely that these the differences will carry a significant weight and could signal a requirement for an extensive modification effort and expense. Do you really need a sexy piece of technology that has missing functionality and will not cater to your business needs without significant modifications and system tweaking? The ramifications of this kind of selection are well-known (see Should You Modify an Application Product?).
On the other hand, basing a decision only on product functionality may result with buying a system that will soon become obsolete. Advanced technology bolsters product flexibility, and often can provide tools that can circumvent the need for expensive modification (see Great Product: Too Bad The Architecture Doesn't Fit).
The Next Step After Research
At the end of the day, there is some similarity between the intricacies of sourcing enterprise software and seeking a personal partner. While no one sane (or emancipated) enough will get married based on questionnaires' outcomes and/or friends/family recommendations sight unseen, there is however, the better chance that the two people with similar interests and compatibilities will connect personally and emotionally as well.
On the other hand, these initial promising signs will easily fizzle out in a personal interaction if, e.g., someone is too rigid, rough mannered, there is cultural or language barrier, or if, e.g., someone's picture posted on the web site has turned out to be several years old and several dozen pounds lighter than today (the same holds for the truthfulness of the questionnaire answers). Sometimes, the person is nice and beyond reproach, but he/she simply does not do much for you (similar to someone's users being indifferent towards the software that seemingly does what is wanted from it). Nonetheless, it is very unlikely that, an avid opera-lover and artistic person will be a good fit with a couch-potato hooked on incessantly guzzling beer and watching sitcoms or the WWF. If a personal relationship is to work, there needs to be a chemistry that cannot be captured by a questionnaire, but the questionnaire does narrow the field.
To that end, the scripted scenario demonstration phase of an ERP selection process is the perfect opportunity to put candidate ERP packages through their paces, and TEC urges users to exercise this 'blind date' prerogative. However, instead of letting vendors take the charge of the demo and show you their 'dog and pony' shows, insist on vendors unequivocally showing you how their system will help you achieve the desired objectives (see Demonstration Post-Mortem: Why Vendors Lose Deals).
Accessing TEC's ERP Knowledge Base
The list of vendors currently present in TEC's
Discrete Manufacturing ERP Knowledge Base (see it in action) includes:
|Lilly Software Associates
||M2M Enterprise Business System
|Microsoft Great Plains
|Microsoft Great Plains
|| Solomon IV
To accommodate different needs and/or budgets, TEC offers different options for accessing the TEC KB's content at
- To access one selected vendor's data for a week: $250
- To access three selected vendors' data for a week: $600
- To access the entire KB's content for a month: $5,000
This concludes Part 4 of a four-part tutorial on how to effectively streamline the ERP selection process.