A pricing model derives its elasticity from the scope of service being offered. The scope of services in turn derives its dimensions from the Application Portfolio for which the Outsourcing Services are designed. So how does one go about building this elasticity into a pricing strategy?
Best Practice #4: Your pricing definition has to be elastic to fit the various combinations of services across your portfolio.
Each Application Portfolio is unique. The service combinations across the usage of an application portfolio should be analysed keeping not only this in mind, but also the needs and spread of the user community.
If I had to summarize my approach to explore the elasticity demands of a service for an Application Portfolio, I would recommend the following steps. These steps are not necessarily sequential but rather iterative.
Step 1: Explore the dimensions of the Application Services
Analyse the dimensions which formulate the service. Typically these are the depth of the service, the hours of the service, the kind of service required, the days in which service is required, the regions of the world that have been supported, the languages being spoken etc.
Step 2: Analyse the parameters that define each dimension
Analyse the parameters that define each service – if you consider service time, check whether service is needed on holidays are not; check if the service distinguishes between regional and national holidays etc.
Step 3: Define the basic mode of service
After the above two steps, define the absolute basic mode of service across all the dimensions using the parameters. Establish this basic mode of service as the minimum scope definition. To continue our example, you might find that the basic mode of service is management of incidents from 9am-5pm on weekdays central European time. Feel free to include the IT Service Company you have or plan as a provider in the discussion.
Step 4: Design the add-on modes of service
Now study the service consumption across the regions, and user communities. Configure the rest of the parameters into add-on modes that make sense. In our example from above, you might find a community of users in Singapore and Thailand using a third of the applications in the portfolio. So you would design an add-on service that covers these working hours. These parameters would be additionally “turned on” for this part of the application portfolio.
Following the above steps would help you define a parameter & dimension system which will represent the elasticity you have in the service today. If these are now baked into the pricing model you have with your service provider, you will have a system that automatically ensures a close linkage between the ebbs and tides of your service and your pricing model. IT Outsourcing trends are also showing a movement away from traditional models into such elastic models.
Elasticity is only one of the areas you need to design into your pricing model. Refer to my previous posts on how to also design for scalability, transparence and encouragement of the right behaviour.
Next Post: Best Practice #5: Balance the risk. Stay in touch.
Is your current pricing model elastic? Have you defined the elasticity in the services that you require? Will your pricing model survive the duration of your contract?