Unbundling as a strategy

Abstract

A formal telephonic interview was conducted with Mr. Uday Disley who is a senior consultant with the Innovation Consulting division at Infosys Labs and the questionnaires outlined above were discussed with him. Discussions with him revealed many a facets about RFPs that are generally dominant in market. His experience was that nearly 9 out of 10 requests for services are made for already existing packages. These mainly include developing and maintaining new applications, infrastructure management services and maintenance activities. Irrespective of whether the service request is standard or novel, the service starts with consulting, systems integration and development. In fact, Infosys is organized into these three verticals namely systems consulting, systems integration and maintenance who look after these modules of all the software services that are offered by Infosys. Thus, each team looks independently at different modules or parts of large RFP. This verifies the fact that even if requests made by clients might not be in modular or disaggregated form, there is recognition of modular architecture prevalent in the software industry. Organization structure of Infosys is testimony to this fact. As is the case, a large RFP does usually consist of thousands of related applications which require end-to-end fulfillment from development to maintenance. The usual practice prevalent in the industry is that each of these applications is independently awarded to individual vendors or group of vendors. Thus, we can take a situation where only 2 vendors independently would be looking after set of inter-related applications. This leads us to conclude that there is vertical unbundling of service delivery done by client wherein a complete service scheme which consists of numerous applications is vertically unbundled and assigned end-to-end to independent providers. Similarly, large RFP requests essentially may consist of small portions of application requests which might be awarded to particular vendors. This would require disaggregation or implementation of that portion which has been awarded by the respective vertical team. For instance, a case of logistics software maintenance contract awarded to a company with service level agreement of 99.9% for 5 years would be taken over by the software maintenance department independent of its development and consulting vertical. This clearly is the case of unbundling of maintenance component of larger logistics software architecture in the company. Hence, it can be said that there is modularization done by companies to meet specific requirements of the client. In case of Greenfield projects or new service requests, the assignment does generally begin with consulting playing a major role followed by systems integration and implementation which would in the end be succeeded by maintenance. However, look at the novel service requests from the client’s perspective, it is an altogether different set of process. Usually, the case is there is annual budgetary allocation for IT infrastructure within each company. The annual budget is then accordingly split up by the client across various domains as payments to customary service provided by providers and there is separate pool maintained for discretionary expenses within the budget. This discretionary budget primarily acts as pool of funds to implement any novel project or any modification or improvement that client might want to implement in his current infrastructure. Therefore, in spite of novelty and newness of the project, the usual practice is to have it awarded to pool of vendors so as to mitigate the risks and efficiently utilize this discretionary expenditure. Therefore, it can be said that there is task disaggregation in novel as well as mature products, the reasons for unbundling being totally different in both the cases. An interesting finding was also made with reference to inter dependencies between client and provider in case of standardized or mature products as well as in case of novel products. Although novel or Greenfield projects require higher understanding and consulting effort, the amount of domain expertise required in case of standardized solutions is also equally high. This is to ensure foolproof implementation of your standard solution across diverse sectors and sell its suitability across clients. An interesting example of SAP finance was discussed where the finance software is implemented across various domains maintaining a pre-determined level of service level agreement. To fulfill this performance guarantee, it is essential to have domain expertise sometimes at par with client of his business. Thus, loosely coupled information interchange does not really exist within industry for continuous interchange of knowledge and information is essential. Pricing modules in contracts has a complicated and complex system with most prevalent practice in the industry being charging consumers based on man-hours put in to complete the activity in case of implementation and maintenance while development is charged a fixed price amount. This certainly is in opposition to literature arguments outlined in transaction cost perspective [2] where performance guarantees are usually associated with fixed price contracts and uncertain and highly customized solutions are time and material contracts. The practice usually followed is there is estimation of man efforts made in case of activities that are to be charged at fixed price and there is continuous negotiation and re-negotiation done so as to correct the deviations. Hence, presence of performance of service uncertainty and customization in no way can be associated with lesser task disaggregation. However, the presence of performance guarantees can be taken as an indication of task disaggregation. The brand of the provider, although has a significant impact in the process of project bidding, the usual practice followed by client is to ensure all the final project bidders are at par in brand equity as well as industry reputation in the market. Thus, presence of brand might help in jumping up the queue for particular module proposal, it is certainly not associated with lesser task aggregation. Clients usually de-risk their portfolio by unbundling the service across multiple branded vendors.