Bureau is the middle ground in the technology acquisition stakes. Building a solution gives you complete control over your business process. The problem is you may be out of date with your competitors and your build may not be very good and it will be expensive to maintain. Buying a solution gives you the opportunity to get the best of breed but you may be spending money on things you don't need in the vendor's solution, you are always subject to changes in the vendor's product that may have no relevance to your needs, notwithstanding their financial stability. Bureau is often seen as the perfect solution. Define a business process. Select those elements that you are good at and implement them internally. Identify what you are not good at or cannot do and bring in expertise to fill the gap. One of the most successful of these in recent times in the wholesale sector is SEI which has built a ‘backbone' technology solution to which members of the financial intermediary and funds communities can connect to obtain services. One of the values brought to this model by SEI is the provision of ‘best-of-breed' service providers so that a purchasing institution can opt for those elements of the back office service that it either has not already built or bought solutions.
This seems to be a best-fits-all scenario and it is certainly true that if you presume that there is a plethora of solutions available in the market, it is much more likely that you'll find the benefits of those solutions outweigh the build option. The problem is that each of those other options will probably have elements for which you have no need and as such they are overspecified. On the other hand, a best-of-breed bureau solution effectively takes away the time-consuming portion of the project by reducing the available option to those which some trusted entity deems to have the right combination of skills and products. We must beware here of the bureau solution being taken to its logical conclusion and that is not just the segregation of functions for example, a corporate actions function or even a sub-element for example, proxy voting, class actions or tax processing; but the segregation down within a function. Bureau operations work best when the functional element they address can be easily sectioned off and its inputs and outputs easily codified and controlled. A good example in tax processing would be the segregation of form filling from calculation at one end and filing at the other end. At this level, the requirement to know which forms to fill in for any given combination of recipient type, year of income, country of investment and income type would seem to be (i) relatively simple and (ii) easily configured into a bureau system. In reality this is a good example of when not to bureau. A second-level analysis would show that while the type of form required is dependent on a data set that could easily be input, and while the output would have some value, the rest of the process is so manual and requires so much effort that the cost saving accruing to having someone else find and fill the form out is minimal. So, it is important when selecting a solution type that attention is given to the analysis of the whole process and to the relative values of each segment within it.
Most providers of bureau services are small software companies that have a buy solution that contains several elements, some of which can be fragmented into sub-elements and it is these that are often found in bureau form. I make the distinction here, particularly in financial services between a bureau, as described, and the more common ‘service bureau' concept found on such networks as SWIFT. The latter take complete business processes as value propositions and effectively create ‘value nodes'. Where SWIFT is essentially a network administrator, the value nodes are third parties that help SWIFT add value to its membership by creating connectivity to allow members to access services. The services described by this model are (i) usually complete business processes for example, tax recovery, and not sub-elements of a business process and (ii) they are true services as opposed to applications. In this case study, the vendor is a small software company which was created, as is often the case, by a group of back-office workers who spotted an opportunity. The software created was specialist and very niche. As with many such firms, the resource base was very small, essentially one or two people per function - sales, management, development. Each has originally been working in one firm. The firm concerned saw an opportunity to reduce costs while maintaining control by ‘spinning off' the development portion of the company into a separate firm. In this new capacity the original financial firm still represented the largest single customer for the new entity, which gave it the illusion of control The new firm had the illusion of guaranteed revenue from its largest client with the freedom to go and find new clients in non-competitive areas.
The net result is a model that is all too frequent in financial services vendors and must be reviewed carefully for sustainability by larger financial institutions. The company concerned had a management that wanted to prove itself - no point in just keeping one large client that you used to work for; but without significant investment they made the mistake of micro-managing cash flow, that is, the best way to increase customer base when your product is very expensive and the cycle time to sale is very long, is to unbundle the functionality and sell it separately. And so, their software got fragmented into a ‘bureau' offering. For the vendor here that was fairly simple and gave them an apparent immediate increase in product breadth without significant expenditure. The firms approaching this bureau provider were lulled into a false sense of security, mainly by the apparent breadth of offering, that the vendor was very efficient on a cost per employee basis and return on capital employed (ROCE) and that therefore this must be a very good vendor to deal with. The reality was that the firm had overstretched itself by selling what it could not support. It had not structured its initial spin-off at all well, as none of the team had any real management experience. The approach is called ‘fishing' or ‘vapourware' - creating an apparent product based on an existing technology and seeing who decides to buy it before deploying any investment in its real development. Many of these facts were not apparent to the larger financial institutions looking at this company's products. Not only was their due diligence easily subverted by clever responses in Requests For Proposals (RFPs), but no real qualitative analysis was performed on the company, as opposed to the product. Neither was any time-based sensitivity analysis performed to see what the likelihood was that the company would be able to sustain its operations.
The lesson here does apply to the broader categorisation of technology management, but is more appropriate in buy and bureau models. In outsourcing, these concerns are not so relevant because the nature of outsourcing requires as a fundamental a level of trust gained through test (TTT), a methodology that would normally catch such inconsistencies as those described in this case study.
The original company spinning off this smaller business unit is not exempt from problems in managing future technology projects. For a time ,pecially if there's a contract in place, the spin-off may have guaranteed pride of place or most-favoured provider status with its parent. This may not lead to the best solution being deployed and certainly mitigates against any competitive offering.The parent's needs ‘appear' to be best met by the new spin-off, but actually, the new spin-off is spending so much of its effort in figuring out new markets so that it can become truly stand-alone, that the needs of the parent are often reduced. A bureau service offered by a small company is high risk. The benefits of ‘leading-edge' thinking created by smaller business units, particularly spinoffs are often eradicated by the lack of management expertise that is fundamental to the success of deployment.
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: Aaron R. Farmer 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.