Pricing Model for Infosys BPO Limited

Download Pricing Model for Infosys BPO Limited

Post on 28-Oct-2014

111 views

Category:

Documents

4 download

TRANSCRIPT

<p>Pricing Model for Infosys BPO limited. Analysts estimate that while less than 5% of offshore contracts are currently outcomebased, this trend will pick up in 2013. NASSCOM estimates that 10% of total revenue is coming from outcome-based contracts/pricing for the Indian Outsourcing Industry. Nasscom believes that the industry is beginning to move beyond time-and-materials pricing. About 40% of the industry's total transaction value now comes from fixed-price deals (irrespective of the number of man hours spent). Despite the outcome-based model in prominence since last four years, the volume did not pick up in India. This model is best suited for existing clients and for new clients who have a clear understanding of the model and in this models both vendors and clients should ensure that the scope of the engagement and the outcomes are clearly defined. The success of this model lies in the understanding of the customers business model, operations and industry nuances and how to manage risk involved at all stages. Risk is high for the vendors and they charge premium and since they cannot wait for payments till the business outcomes, only apportion of the revenues are being done on the outcome-based pricing. Business outcomes are time consuming. The clients and vendors should have a common basis for future value creation and vendors should be clear as to how much risk he can bear and how well he knows his own processes and business. Other external variables also have to be taken into account and for the model to succeed both the client and vendor should have a strong and open relationship between them so that they can achieve the planned common outcome. Customers prefer such billing models because they can keep their costs entirely variable and dependant on their own revenue growth. Although outcome based contract meant high involvement between clients and vendors for efficient delivery of work. Many incentives could be obtained from price based contract .It also helped in cutting the costs as productivity and efficiency could be achieved through less number of workers. However it cannot be used due to following reasons: Firstly Infosys cannot rely on outcome based contract with every client the reason being simple, sometimes a project may require long term till it can be evaluated and its outcome validated. Clients and vendors have to invest more in understanding each others business in order to determine the proper level of service. This is only possible if they know each other well by terms of requisite and expected level of service.</p> <p>Evaluation of service was directly related to the payment. Any hiccup in work would directly result in losses. Also, it isnt easy to determine whether the resources to be utilised will yield a good ROI.</p> <p>Infosys should lay its concentration on transaction based contract even though FTEs based model has been impressive when the forecast is accurate. Transaction based contract would result in charging for the exact number of processes being handled simultaneously. In transaction based pricing, what and how many resources are involved and how much time is taken to Process the transaction while also meeting quality and service level agreement (SLA) requirements, are the Variables that are typically managed by service provider. This essentially means that variability and risk Associated with customers business activity is transferred to service provider. Service provider manages this Risk by utilizing resources efficiently across multiple customers and by charging an appropriate risk premium in the transaction price. In addition, service provider is motivated to maximize output or number of transactions processed with same or lesser input, which typically leads to innovation and better use of technology resulting in lesser cost for customer in the ultimate analysis. Transaction price is typically quoted as price per transaction unit. For example, for payroll processing, the transaction price may be quoted as x dollars per payslip; or for invoice processing, the transaction price may be quoted as y dollars per invoice. However, since business activity does not remain at a constant level throughout, there needs to be a mechanism which can determine how the transaction price varies for different levels of business activity. To address this, transaction price is generally mentioned as applicable for a specified transaction volume range. Such a volume range is known as dead band which is typically derived by analyzing historical transaction volumes data. For variations in transaction volumes beyond the dead band, a negotiated increase or decrease in price becomes applicable. Usually ARC/RRC (Additional Resource Charge/Reduced Resource Credit) framework is used to arrive at the price outside the dead band. This system of billing can be used in reverse logistics as well. Few advantages to Infosys by adapting transaction based billing are: Improve profit margin by charging more for value created and higher risk owned Better control of service delivery as people ramp up/down and reallocation becomes easy Offer commercial differentiation (higher savings) due to standardization and innovations that result in higher output for lesser input</p> <p> More flexible and scalable pricing model as payment is for consumption only Effective monitoring of costs due to enhanced visibility into consumption pattern Lower per unit cost due to improved efficiency Makes it easy to compare and select service providers by comparing their per transaction price along with SLAs For smooth processing of transaction based billing: Choose the right transaction unit for pricing the deal one that aligns both parties interests. For example, in case of insurance, if the transaction unit is no. of policies issued, then the interest of service provider and customer are aligned - more the number of policies issued, more is the payment to service provider and more is the premium collected by the customer. As against this, if the transaction unit is no. of leads, then the interest of the customer and service provider are not necessarily aligned as more number of leads would definitely translate into more payment for service provider but may not translate into more policies issued and thereby, premium, for customer. Establish a mutually agreeable mechanism to address volume fluctuations. A few such mechanisms could be: Define an ARC/RRC framework to handle volume variations beyond the base volume Adjust the baseline volume periodically using average volume experienced in the past few months thus allowing both parties to share the risk of volume uncertainty and allowing service provider sufficient lead time to absorb volume fluctuations Agree for less stringent service levels for service provider if actual volumes materially exceed those forecasted Agree on defining and measuring SLAs during the initial phases of the engagement and use this data for base lining them for the remaining term of the engagement Plan for a comprehensive change management effort which includes top management support, syndication of key stakeholders and end-user education programs.</p> <p> Exercise high level of transparency in sharing data and details between the parties to develop an environment of trust.</p>

Recommended

View more >