When Y2K was lurking just around the corner, the cry from vendors was for fully integrated software (FIS) such as enterprise resource planning (ERP), supply chain management (SCM), and enterprise asset management (EAM). Why re-write all of your systems when it was easier to replace them and have integration thrown in at no charge? This would be tantamount to replacing your Model T with a supercharged turbo and the salesman throwing in air conditioning and AM/FM stereo for free. Now, with the Y2K hype but a distant memory, companies are starting to look to best of breed (BoB) solutions whereby you are willing to consider isolated software offerings from different software vendors to satisfy systems requirements. What are the merits of each approach?
First, we need to establish a level playing field so that, as best as possible, we can perform an "apples to apples" comparison. To help you decide which approach makes the most sense for your company, we look at the following four factors: time and money, degree of fit, integration issues, and project management/implementation concerns.
If you were replacing one system or satisfying a single user department's needs, the BoB approach to software solutions would appear obvious. However, to ensure an impartial comparison of the BoB and FIS approaches in this article, we will assume that all or, at least, a significant portion of the business applications are to be replaced. We will also assume there are no budget constraints or economic conditions to preclude an organization from replacing its entire portfolio of application software. Again, if a software selection project is faced with budget constraints, looking at FIS solutions may not be economically viable. Other factors, that could influence your decision for either approach, are:
- Key users from certain departments are unavailable. Therefore, there is a need to eliminate certain departments together with their requirements from participating in the software selection and implementation phases.
-
- Current or planned major projects are impacting user departments. Again, all departments cannot equally participate in the current and subsequent project phases.
-
- The information technology (IT) department cannot support a major software implementation.
Accordingly, for the purpose of our discussion it is assumed that the above factors and their associated effects will be sufficiently mitigated as to have no impact on the decision of whether to use a BoB or FIS approach.
Clearly, there may be other factors. But most importantly, in real life it is critical to recognize if you do not have a level field and whether you can level it. Specifically, if all users are not available or the budget is constrained and you cannot change these factors, your decision as to the approach may be easy. Getting your management team to accept this fact or getting them to change it could be another story entirely.
A fact in life is that the more you spend with a vendor, the more leverage you should have with the vendor. Consequently, when purchasing a FIS solution, your purchase represents a significant source of revenue as opposed to buying a single application. Whether the software is priced based on the number of seat licenses or as a total package, the derived revenue to the vendor from your sale can influence several factors. You can expect and demand to receive certain concessions in price, maintenance periods, and consultancy rates otherwise unavailable from a BoB software provider.
A time-honored tradition in negotiating software contracts is trying to get everything for little or nothing. With respect to FIS, since you are talking about software with far more reaching scope than with a single vendor, you can usually exact better discount terms and percentage decreases. On the other hand, with the BoB approach you must approach several vendors individually and these individual vendors have smaller margins to play with. While you could argue that the sum of the individual discounts could equal or exceed the single discount with a FIS vendor, this will take all of the negotiating skills you possess and could draw out the selection process.
As has been stated by numerous experts many times before, modifications are not encouraged but are a fact of life. As a general rule of thumb, good FIS software should facilitate modifications. The rationale is that, if proper data warehousing and housekeeping techniques were employed in developing the FIS software, data constructs and editing logic should be centrally located in the source code. This centralization technique minimizes the number of places where a programmer must investigate in order to make a modification. You could rightfully argue that good programming practices are also employed by BoB vendors. While this is most likely to be true, individual vendors comply with their own standards. Consequently, the number of BoB vendors you are working with can greatly influence the degree of difficulty and corresponding costs of modifications.
Clearly, certain generalizations are being drawn in this limited discussion of modifications. If you are seriously considering significant modifications, this is an area that requires future investigation to determine the maintainability of the software.
Time is money. In the BoB model this time can be represented by the need for more internal personnel resources of your company in the selection process to work with multiple vendors. And for the same reasons, this time can be the additional effort required to make multiple software decisions, thereby delaying the point at which your company can start to realize the benefits of the software. When having to work and negotiate with several vendors as oppose to a single software supplier, you should expect the overall selection process to be extended. If considering the BoB approach, make sure that this is factored into your estimate as to when management can expect to reap the tangible and intangible benefits from the software.
This may be a case when, having more, in terms of vendors, is not necessarily better. Having greater leverage with a single vendor, typically with larger margins, to exact favorable discounts both on the purchased software and potential modification, makes the FIS solution particularly attractive.
By its very definition, you should expect a BoB solution for a particular functional area to have an excellent or a higher degree of fit than FIS software. The reality is that a BoB solution should more closely meet the requirements of users. In a BoB solution, software tends to focus on a smaller frame of reference, thereby concentrating on specific needs in an application area in greater detail. Consequently, the gaps in terms of functions and features between what the software offers and what the user requires are apt to be smaller and more acceptable. The touch points of the BoB applications with the user needs will be greater and more frequent. Overall this could mean greater satisfaction with the userability of the software.
A FIS solution, while perhaps satisfying functional areas as production scheduling or customer service for a specific industry, may fall down in other areas such as back office support. Typically, some users may be forced to accept less in terms of functionality while other users are perceived to be leading parade with increased features and benefits. As the rubber band of FIS solution is stretched to cover a larger area, the weaker the coverage may become on several fronts. For example, when trying to find a single software solution for order entry, production control, and general accounting, there are likely to be application gaps or weaknesses. Some concessions will be needed.
If it is purely a question of meeting the needs of a functional area, you are more likely be satisfied by a BoB solution.
As obvious as to the winner of the degree of fit category, the winner of resolving integration issues is FIS. End of story.
Not really. It is important that you fully understand the difficulty of constructing interfaces between systems and why, as an IT professional, they should not be taken lightly. Some of the questions that must be answered in the integration of two systems are:
- What data are required by the receiving system?
-
- What data can be provided by the sending system?
-
- How do we supply the missing data?
-
- How often must the data be transmitted?
-
- How often can the data be transmitted?
-
- Must the data be transmitted in real time or batch mode?
These are the quick and easy questions. The answers are not nearly as easy. However, the tricky question is how do you tell when the interface is not working? Wait until you are out stock? Wait until you customers tell you? Of course not. Now multiply this degree of difficulty by the number of systems that must communicate with each other. If you can avoid constructing interfaces and can be assured that the interfaces of a FIS solution work, it is hard to look the other way to a BoB solution where it may be difficult to complete the implementation phase of the project in a timely and cost-effective manner. Furthermore, be careful when you think that you are at the end of the implementation. That light at the end of the tunnel may be an oncoming train or another interface needing modification. Both can ruin your day.
Clearly, the high marks for integration go to the FIS model for the benefits to be derived from the interfaces delivered with the software solution.
Project Management/Implementation Concerns
If you are a project manager of a selection project and expect to lead it into the implementation phase, you should be interested in which approach could make your life easier or, at least, place the fewest speed bumps in your path.
As has been stated above, dealing with multiple vendors can be time consuming and counter productive. Consequently, in a BoB scenario determining whose software does not play nice with the other solutions will try your patience and self-control. You'll be playing "Who Shot John?" around the clock with intermediate sessions of finger pointing. In the FIS approach, you are dealing with a dominant vendor, who typically supplies consulting services to support the entire implementation. Your meetings will fewer and shorter in duration. As the project manager, you have more time to spend on critical tasks like designing the "go live" T-shirts. Not to trivialize this issue, inter-vendor disputes can significantly detract from your ability to effectively lead, monitor, and direct the project.
After you have diligently completed your piloting, data conversion, and training, you want your implementation to go smoothly and be uneventful. An implementation approach that supports this objective and lessens the risk is a phased implementation plan, placing modules into production one at a time. Because the modules are more self-contained, stand-alone, a BoB model lends itself to a phased implementation. Typically, you defer the implementation of the next application until the users are comfortable at the controls of the first module. This staggered approach can be repeated with the remaining modules and places less stress on the organization.
A FIS vendor will counter that they not only support the "big bang" method of implementation but also a modified "big bang" to lessen the risk. The "big bang" method is where you go live with all components at the same time. Unlike the explanations for the start of the universe, we can debunk the "big bang" theory fairly easily. First, modified or otherwise, the "big bang" method is not as foolhardy of an approach as you might be led to believe. The value of a FIS solution is its integration. Trying to decouple modules to facilitate a phased implementation is tantamount to unhooking the cars of a train and then wondering why the entire train is not moving. An FIS solution is intended to function in an integrated fashion. Accordingly, the software should be implemented, as best as possible, so that the integration remains intact.
Secondly, as discussed in the article, Software Piloting: How Do You Fly This Plane, you go live with the entire software product. If you do not have the unanimous vote of confidence of the functional leaders, perhaps you are not ready to go live. While this does not imply that you have to turn on the switch for all components at the same time, it also does not mean that you turn on order entry first, a month later production control, and month later purchasing. The elapse time between activating modules is expressed in days, not months. Also, remember, when other modules are not activated, redundant data entry and additional data conversion will be required. And you know how anxious users will line up to support these activities.
The bottom line is that the BoB model can provide better control and management of the implementation process.
To recap the discussion so far, the report card summarized the marks by both models by category.
This article got started by a colleague asking which model, BoB or FIS, was more suitable for medium-sized companies. First, in my opinion the size of the company does not materially enter into the equation or would alter my analysis. If we are operating on the level playing field as described in the beginning of this article, the answer is fairly obvious. Potential dollars to be saved, the time delays to be avoided, and reduction or elimination of integration issues make FIS a good choice when evaluating your entire software application portfolio.
The integration issues involved in BoB solutions are just too overwhelming and costly to be dismissed or mitigated. Like the road network in any region, experience indicates system interfaces and integration are the most difficult bridges to construct, test, and maintain. This being said, a case, though tenuous, can be made for BoB. If a particular user can make a cost justified case for the need of a module other than what is provided by the FIS vendor, then and only then should you consider an alternative BoB solution. Given that the user can prove their case and benefits when matched up against the additional costs and time delays to be incurred, conventional wisdom dictates that you should support them. If the figures and facts are right, a hybrid approach is going to make more money or save more money for the company.
If the playing field is not level and you are looking to plug a couple of application holes, the answer is equally obvious. While the integration issues still exist, there would be little need or reason to disrupt other existing systems and the user departments they serve. Accordingly, the BoB model would be the wise and appropriate course of action.
The bottom line is that the model you choose for your company will depend on the scope and economics of your project. For projects, where you are contemplating the replacement or improvement to large system portfolios, consideration should be given to the FIS model. Projects, whose scopes are narrower and involve isolated functional areas, lend themselves to the BoB approach. As a final caveat, be advised that as difficult economic times are forcing them down the software food chain, larger FIS vendors are marketing their software as BoB as well. Just do your due diligence and homework to confirm that the decoupled modules are truly standalone and do not lose much of their feature-rich functionality when decoupled.
SOURCE :http://www.technologyevaluation.com/research/articles/best-of-breed-versus-fully-integrated-software-the-pro-s-and-con-s-17027/
No comments:
Post a Comment