Buying solutions is increasingly a viable option. It has many advantages over building your own solution and not many of the disadvantages. That said, there are disadvantages and, in the same way as building a solution requires an honest assessment of the risks, so too does buying a solution. With a build solution, while you are able to leverage the ideas of your own workforce to deliver a unique solution, you are at the same time constrained in that you do not have open access to the ideas of others (without paying exorbitant consultancy and research fees). Purchased solutions have some merit because, as part of a third party's business model, it must aggregate market practice and innovation into a package that has attraction to a wide variety of customers with an equally wide variety of needs. In other words they have to be flexible. So any solution that is put forward in a ‘Buy-it' model would naturally be expected (i) to have a high degree of fit to your existing business model and (ii) offer potential improvements to your business model that you would not have otherwise thought of. This is called spread.
Risk is rather a broad term in this context and really it encompasses all the potential downsides of a buy solution. Over 60% of all the software companies in the United Kingdom, for instance, have less than 15 employees. This is because, particularly in financial services, many of the supplier companies are either deliberate or accidental spin-offs from the IT departments and almost without exception single-product companies. Someone there saw an opportunity and figured that there was more money to be made selling it as an outsider or the firm itself spun off part of the department either because it saw it as non-core, a distraction or because it simply wanted to reduce costs. In any event, the technological innovation in most countries does not come from large, slowmoving,conservative firms and financial services is no exception. Equally small-technology companies are at once financially more risky and less able to meet the global needs of financial institutions. If they have good ideas, they will grow too quickly and overextend themselves and be bought out by larger players thus losing their innovative style. If they grow too slowly their solutions will not be viewed as providing enough benefit - that is, not enough aggregation of market practice because not enough clients. There are some excellent third-party providers out there and certainly for most of the late 1990s applications providers were experiencing their hay-day. Following are things to watch out for when bringing in a third-party solution: Financial stability. Will they still be there to support you in a year? Insist on strong due diligence and analysis of their financials. In many countries including the United Kingdom, you can get published records of a supplier's financial history. Analysis of these records can tell you a great deal.
Particularly in the United Kingdom, where lists of the shareholders can also be obtained as well as details of all the officers of the business, most technology purchasers limit their analysis to either the current profit and loss account and/or the balance sheet. In much the same way as financial institutions vary in their performance over time, so do technology suppliers. It is therefore important not just to analyse this year's performance but also previous years to see if there is any pattern that could warrant further investigation. As an implementer or project leader, you aren't going to look very good if you miss the fact that your software supplier has a set of reasonable current financials but a balance sheet that shows it is paying off massive debts from mistakes. History and references. It is important not only to know who some existing clients are but also their rate of replacement. You must obtain a good picture of their historical development in terms of both customers gained and also customers lost.
Business model. The norm is a licensing model formed of a one-time upfront license followed by annual ‘maintenance' fees which are usually around 10%-12% of the up-front license fee. There are other models and if the opportunity is right, some suppliers will engage in a transactional model, particularly if the project has income possibility for the purchaser in which the supplier can share. While this is a lower up-front cost option than licensing, this can cause cash flow problems for some companies. I often come across this model and technology managers need to be aware that there is no basis of science in the fact that maintenance fees are 10%-12% of license fees, just as there is no real science, other than what the market will bear, for the level of any given license fee. On the retail side of banking this model is falling out of favour in preference to the ‘pay per click' methodology. Managers beware that this method may sound very reasonable as it relates to a payment for actual use rather than a notional use; but unless you have very good modelling for usage, this could easily backfire and cost the business a great deal of money. Updates and upgrades. An update is usually either a small change in the code of an application or an update of some market data that is managed by the supplier as part of the solution deployment. An upgrade is usually either a major change in functionality or a change in supported operating system. Corollaries exist for communications and systems-level projects. Either way, these cost money that must be budgeted for as part of the ‘cost of ownership' RFPs. Small companies hate RFPs and rightly so. ‘Requests For Proposal' fall into two categories from a financial services perspective.
Either they are the result of lazy technologists who come out of the woodwork every couple of years to find out what the best and most current ideas are, by getting small innovative companies to do their work for them or they are real projects. The problem is that most application providers cannot tell the difference and have to assume the latter. This is a technology management article, so RFPs deserve some comment in detail here. The biggest issue is that most RFPs are taken as templates by those implementing them. While it is true that any half competent manager should be able to construct the obvious elements of a general RFP, most of the RFPs I have seen have been well short of a quality that would tell the recipient anything substantive about the vendor's actual capabilities. In a build scenario, there are clear stages to a deployment, business specifications, functional specification, technical specification, gap and integration analysis, testing, integration, roll-out etc.
However, in a buy scenario, most of these excellent concepts are dispensed with. A business need is identified, potential suppliers are identified and essentially a toplevel gap analysis decides the winner. The gaps can also be extremely ‘loose' both in definition and interpretation. For example, more weight might be allowed for a vendor with local time zone support than for another whose solution actually has more technical merit. So decisions are made on no rigorous absolute basis, but more on a relative and ‘look and feel basis' with the presumption that if they have other clients that have a similar profile, then their solution will probably work. Of course, these are only the most important examples. When buying a solution there are a range of other issues that need to be considered. The difficulty is that by the time these concepts are being weighed, at least one of the key decisions has already been made - whether to buy at all. It is rare for a financial firm to structure an RFP that would allow for more than one top-level operating model. Most of the templates for RFPs assume in the nature of their language, that the objective is to buy a solution rather than outsource it.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Michael S. Garret at 01112010
1. How to use technology in business
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.