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.
SOURCE:-
http://www.technologyevaluation.com/research/articles/evaluating-enterprise-software-business-process-or-feature-function-based-approach-all-the-above-perhaps-part-three-knowledge-bases-and-user-recommendations-17096/
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.
SOURCE:-
http://www.technologyevaluation.com/research/articles/evaluating-enterprise-software-business-process-or-feature-function-based-approach-all-the-above-perhaps-part-three-knowledge-bases-and-user-recommendations-17096/
No comments:
Post a Comment