Home
 > Research and Reports > TEC Blog > Evaluating Enterprise Software-Business Process or Featur...

Evaluating Enterprise Software-Business Process or Feature/Function-Based Approach? All the above, Perhaps? Part Three: Knowledge Bases and User Recommendations

Written By: Predrag Jakovljevic
Published On: October 28 2003

TEC Selection Uses Knowledge Bases

Thus, we beg to differ that certain selection service providers' (including TEC's) methods are archaic but they rather save time and cost, while taking care of the functions and features "inventory management." To that end, TEC released a number of knowledge bases (KBs), accessible through its evaluation centers (e.g., ERP Evaluation Center www.erpevaluation.com, CRM Evaluation Center www.crmevaluation.com, etc.), each of which includes several dozen vendors rated on thousands of functional and technical criteria. The criteria have been isolated as meaningful to best differentiate these enterprise packages, and are based on TEC's past selection experiences. For example, as the discrete ERP functionality scope covers many modes of discrete manufacturing (make-to-order [MTO], engineer-to-order [ETO], make-to-stock [MTS], repetitive manufacturing, etc.) and it goes beyond core ERP functionality as well (e.g., sales force automation [SFA], PLM, etc.). Because the technological questions attempt to cover many technical aspects (e.g., general architecture, degree of integration among modules, interconnectivity, data protection and restoration, security features, tools, etc.), we believe that the number of criteria serves its purpose. A lesser number would likely fail to provide an accurate picture, while a greater number would involve mundane details (e.g., the maximum length of the item description field or the capability of the system to print on an 8" x 11" paper size).

The KBs are powered by the eBestMatch decision making tool (formerly WebTESS). How does all of this work? In a gross simplification, behind the scenes there are databases which maintain functions and features by software component. Correspondingly, there are databases of software vendor capabilities aligned along the same lines. After you have updated the functions and features according to your needs, rankings, and priorities, the two sets of databases are matched to find vendors who best meet your criteria. The algorithms and modeling techniques used to complete this "best match" tend to be sophisticated and rival those used in advanced planning and scheduling (APS). The vendors have submitted responses to the respective request for information (RFI) documents to TEC either through a particular selection project or voluntarily.

This is Part Three of a three-part note.

Part One presented the overview.

Part Two compared business processes to the feature/function approach.

Using a Knowledge Based System

Experience has shown that close to 95 percent of functional and technical requirements show up time and time again, and TEC has attempted to capture these, which provides repeatability and saves everyones time. The remaining 5 percent or so are requirements peculiar to your business and industry, which may happen to be fatal flaws (e.g., Wal-Mart electronic data interchange [EDI] standards in retail, or multiple-children bills of material [BOM] 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' and VARs' effort in filling the new RFIs should only be limited to filling that delta document. Why haven't these been captured beforehand? For two main reasons:

  1. The expertise across over twenty industries is not likely to be found at any selection service provider, despite extensive horizontal knowledge (with a deeper knowledge of a couple of particular industries) of their analysts. The fact that every vendor that is serious about its vertical focus has separate dedicated industry product leaders, special interest groups (SIGs), and so on, speaks volume about how involving the vertical industry product extensions' delivery is; and

  2. Many industry specific functions still cross several industries, for example, lean management practices like kanbans have permeated almost every manufacturing environment. Thus, even the vendors that tend to develop vertical extensions, sometimes referred to as industry service packs, periodically review these individual functions for common use, and then decide to roll them back into the standard horizontal (foundation) solution that is applicable across the board.

This is a continuing, open-ended system where similar solution packs will gradually be added to the above knowledge bases. Vendors and VARs that consider themselves leaders in certain industries, are more than welcome to contribute their suggestions toward building these add-ons, at least for the reason of differentiating themselves from the better rounded "horizontal" competitors.

Once the best product fit is found, it is common that the selected software still cannot meet all the requirements of the business, which calls for a decision to either change the requirement so the package can accommodate the business, modify the software to match the business need, or to design the business processes to work-around or account for the difference. If significant functional gaps exist between the system and the needs of the business, has the right product been selected? Does the right standard product even exist? If these gaps fall within the list of fatal flaws, the system will never be successful.

Even in a hypothetical case of two vendors differing by only a few percentage points of required functionality, it is very likely that each of these differences will carry a significant weight and could signal a requirement for an extensive modification effort and expense. The ramifications of this kind of selection are well-known (see Should You Modify an Application Product?). The cost of modifications will be rolled into the total cost of the proposal and will offset what could be viewed as a vendor's amenability to modifications. The proposal costs to include software, annual maintenance, implementation assistance, and modifications can now be evaluated against the functionality scores. If a vendor has a high functionality score but is also high in terms of total costs, you must determine if the costs justify the functionality.

Beware Software Bloat

On the other hand, functionally richer vendors should not relax and expect a hands-down victory, while less functionally robust vendors should not be dejected or feel inferior. Indeed, despite many vendors' and industry experts' contentions of an inevitable functional parity convergence between products, a one-size-fits-all product is still not quite a viable possibility, and thus, almost every product can still win provided certain sets of requirements. There is always a risk of "as little modification as possible due to a rich standard functions inventory" approach coming with the price of "software bloat" and inflexibility.

Standard application software, for the most part, has been designed to meet the needs of multiple companies in multiple industries. To meet the needs of different industries, vendors have added many industry specific functions. However, normally, no single user company operates in more than one or two different industries. Although the fit is improved in one industry, the cost of this fit is feature bloat, meaning that all other industries must suffer the consequences of these non-essential functions. Bloat, in the form of complex program logic is required not to execute the function but to determine which of many paths the program must take. The cost of bloat is real. Code complexity leads to quality problems. Code complexity means support becomes more difficult. Enhancements and modifications prove more costly and error prone. Implementations are more lengthy and difficult. Upgrades from release to release become more time consuming and error prone.

Application software needs to evolve so that it recognizes the reality that businesses are unique, but not by adding software bloat to existing products. Vendors also need to build lean products that serve specific sets of customers plus allow customers to build in their own, individual needs. It is not enough to be able to "turn off" features with configuration switches (rather than resorting to hard coding), which may help users but only further increases the complexity of the code. For more information, see What's Wrong With Application Software? Businesses Really Are Unique - One Size Can Never Fit All. As a summary, finding the proper balance of modifications versus bloat is subject to many factors, but the knowledge of what functionality is already available is a critical starting point.

On the other hand, given that within a specific client size range and vertical industry, many renowned application packages are slowly but surely, 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.

This is where the process-based part of the selection gig comes to shine. A full list of functions cannot work unless they are organized into a path or business process. For example, if the feature called "available-to-promise (ATP)" is missing or not appropriate for your needs, the business process called "order-to-cash" may be very difficult or impossible in your situation, given the planning step will not work accordingly. To that end, the scripted scenario demonstration phase of an enterprise application selection process is the perfect opportunity to put candidate packages through their paces, and TEC urges users to exercise this prerogative. However, instead of letting vendors take charge of the demo and show you their dog and pony shows, insist on vendors unequivocally showing you how their systems will help you achieve the desired objectives (see Demonstration Post-Mortem: Why Vendors Lose Deals.

RFPs and selection tools typically focus on features and functions. The business process protagonists consider this focus old fashioned. However, users want and need an inventory or check list of the functions to understand if the business process will work. One always has to start from somewhere, and there is no better place to start researching enterprise software than from its functional and technical capabilities. Selecting enterprise software based on a business process approach can be better than a strict feature and function approach only when the user company has gone thorough the legwork ahead of time to determine 1) what functionality is required to enable each business process and 2) how important is each business process to enabling the companies' strategic objectives (i.e. relative importance of business processes) and how important is each item of functionality to enabling each business process (i.e. relative importance of the functional items that fall under each business process).

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 and VARs should research the viability of the opportunity beforehand. Issuing a comprehensive 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, at least when leveraging ready-made repositories, as shown in CRM Selections: When An Ounce Of Prevention Is Worth A Pound Of Cure, Selecting PLM Software Solutions and Facing A Selection? Try A Knowledge-Based Matchmaker.

Should you start at the top (business processes) or the bottom (functions)? You can start at either. If you know certain functions are very critical to your business (fatal flaws) then look at those functions first because without them, business processes are of no use. If you think your needs are covered by most products, start at the key business processes then investigate the key functions within those processes. Still, you must have the ability to unequivocally prove the fact that most of the solutions you are considering are on par regarding your needs. While the business process aspect is indisputably important, challenge the overly "process preaching" vendors to account for the functions inventory that comprises each process step.. Their readiness to accommodate you with both approaches would be a great sign and vice versa, beware of any vendor insisting on only one approach.

As a summary, the following are some of the main mutual benefits of all the parties being on the same page:

  • Upfront identification of issues and negotiation perspectives, which enable more efficient and productive negotiations

  • Enabling the solution implementers to be more 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.

To put vendors on notice that you expect a reasonable, demonstrable response, it helps to include a statement that the vendor's proposal will be an addendum to the signed contract. In case of any dispute (God forbid!), you will have to prove that the vendor did not conform to a list of several hundred functional specs built into the contract. Proving that at the level of certain business processes would be much more difficult owing to the more fluid nature of business processes.

Make no mistake—TEC does not expect anybody to acquire a crucial and costly piece of technology based only on on-line 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 and support. 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 the 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. 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).

But again, technology should not drive the business needs, rather it should be the other way around. 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?


About the Authors

Predrag Jakovljevic is a research director with Technology Evaluation Centers, Inc. (TEC), with a focus on the enterprise applications market. He has over fifteen years of manufacturing industry experience, including several years as a power user of IT/ERP, as well as being a consultant/implementer and market analyst. He holds a bachelor's degree in mechanical engineering from the University of Belgrade, Yugoslavia, and he has also been certified in production and inventory management (CPIM) and in integrated resources management (CIRM) by APICS.

Olin Thompson is a principal of Process ERP Partners. He has over twenty-five years experience as an executive in the software industry. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce, and the impact of technology on industry. He can be reached at Olin@ProcessERP.com.

Joseph J. Strub has extensive experience as a manager and senior consultant in planning and executing ERP projects for manufacturing and distribution systems for large to medium-size companies in the retail, food & beverage, chemical, and CPG process industries. Additionally, Mr. Strub was a consultant and Information Systems Auditor with PricewaterhouseCoopers and an applications development and support manager for Fortune 100 companies.

He can be reached at JoeStrub@writecompanyplus.com.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.