What lies on the other side of Economic Event Horizon for IT Outsourcing industry?

The economic event of meltdown and slowing growth that we are witnessing today is unprecendeted in its nature in terms of the following:

1. The scope of coverage (includes all the industries)
2. The scale (effects felt globally) unlike the prior Japanese, Argentinian currency crisis, Russian bond market initiated crash or the East Asian BoP crisis
3. The intensity/depth of effect it has had on the industry
4. The speed at which it propogated; virtually in 6-9 months timeframe it had affected the scope and scale


What lies on the other side of the unprecedented economic event horizon...No brownies for guessing it for the Financial industry as almost every one has seen and will see in terms of regulation, infusion and bailouts by governments, recapitalization, more stringent monitoring of risk exposure...read more of it in RGE Monitor an article written by NY Stern school of business. Lets look at our IT outsourcing market alone for a moment. I just happened to come out of a leadership meeting at work and was quiet amazed that every one claiming that the other side of the event horizon will be fundamentally different from what we have witnessed in the past...But no one knew what exactly what it really means :-)...either they thought we may not understand it or they themselves were not so sure.... I for one believe that they might've thought we would not understand it.

The IT outsourcing industry has witnessed just one such downturn in Year 2000 & 2001 (Popularly called DotCom Crash) when the Telecom & Technology industry led downturn had immense impact on us (we will compare and contrast this in a separate post) . Having seen through that downturn and journeying through several organizations and roles, here are my insights:

1. Client will demand more value (one can define it in many ways) to be delivered by Suppliers at lower cost.
2. Client would demand transformation of their IT services/model/organizations leading to higher efficiency and effectiveness of IT support function at lower cost.
3. Client would expect suppliers to bring innovations to life through IT services to businesses earlier, and faster than their competitors at lower cost.
4. Higher performance/productivity levels (enforced through stringent SLAs) for thier businesses than before at lower cost.
5. Better resources (may I call them Super-humans: higher talent, highly flexible, having shorter learning curves, working longer, etc.) at lower cost.

Now if you do not understand whats and how of lower cost, it is immaterial you are best in any other tenet. Remember you still cant get a dime for your organization and find yourself running around amidst headless chickens or Heady humans ;-)...

What has been your experience regarding these heads and your predictions on the other side of this event horizon?

Breaking down the cost-to-serve parameter for service management optimization

The objectives of managing the service (any service Consulting, System Integration, Application Outsourcing, etc.) through application of innovation techniques are to reduce the cost to service. It is critical for one to understand the constituent factors that influence cost to serve goal. The following diagram crisply captures the factor trees that influence the cost to serve goal.



Now we can capture the difference in the estimate/forecasted cost for each of above
parameters, measure the actuals during execution and drive management and control to minimize the differential.

Our transformation intiatives can be focussed on reducing the estimate/forecast cost in the first place...we'll dvelve more on this topic later...

Any thoughts on what factors I might've missed

Illustration of a constraint model for optimal outsourcing decision

Lets assume the client has shared the following volumetric and requested the service provider to bid for the Application maintenance deal:

Guiding factors:

Utilization %	60%
Call Data Period	1 Month

Call Characteristics:

Domain	Technology	Sev 1	Sev 2	Sev 3
Billing Application	Java	3	15	13
Customer Care	.Net	5	10	28

Required SLA:

		in Minutes
	Availability	Response Time	Resolution Time	Actual Resolution time (Billing)	Actual Resolution time (Customer Care)
Sev 1	24/7	5	60	45	60
Sev 2	8/5	15	240	160	173
Sev 3	8/5	120	480	300	390

Based on the above details we can apply the step-wise resolution step to shape the deal:

Step 1: Assuming that the demand is even and the incoming calls has a poisson distribution, the l

Since Sev 1 calls are 24/7 availability we are assuming the pattern is evenly spread over 24 hrs, 30 days and 60 minutes and l for sev 1 is Number of calls/(24*30*60)

	Sev 1	Sev 2	Sev 3
Billing Application	0.0001	0.0016	0.0014
Customer Care	0.0001	0.0010	0.0029

Step 2: Assuming the service rate is an exponential distribution, the m

Service rate = 1/(Actual resolution time in minutes)

	Sev 1	Sev 2	Sev 3
Billing Application	0.0222	0.0063	0.0033
Customer Care	0.0167	0.0058	0.0026

Step 3: The number of resources for each domain, the r

	Sev 1	Sev 2	Sev 3	Total	# of resource
Billing Application	0.0052	0.4167	0.6771	1.0990	2
Customer Care	0.0116	0.3003	1.8958	2.2078	3

Step 4: The deal optimization based on the above characteristics can be illustrated as follows:

Lets’ assume the following assumptions:

1. We consider 2 locations US and India for this deal

2. We assume there are no shift requirements and the support will be on-call basis

3. There is only 2 levels in workforce: Software engineer and System Analyst

4. The cost for onshore-offshore is as identified in the following table:

	All figures in USD per Hour
	India	US
System Analyst	21	65
Software engineer	19	60

5. Lets assume the pyramid definition is as follows:

	India	US	Engagement Pyramid
System Analyst	5%	95%	10%
Software engineer	95%	5%	90%

The objective function can be laid out as follows:

Min X_onshoreC_{onshore, System Analyst}R_{Onshore,System Analyst} + X_onshoreC_{onshore, Software Engineer} R_{Onshore,Software Engineer} +X_OffshoreC_{Offshore, System Analyst}R_{Offshore,System Analyst} + X_offshoreC_{offshore, Software Engineer} R_{Offshore,Software Engineer}

Based on the above equation we can represent it as follows:

Min X_onshore*65*R_{Onshore,System Analyst} + X_onshore*60*R_{Onshore,Software Engineer} +X_Offshore*21*R_{Offshore,System Analyst} + X_offshore*19* R_{Offshore,Software Engineer}

The constraint for this is defined as follows:

R_{Onshore,System Analyst} + R_{Onshore,Software Engineer} <= 5*X_onshore

R_{Offshore,System Analyst} + R_{Offshore,Software Engineer} <= 5*X_offshore

R_{Onshore,System Analyst}+ R_{Offshore,System Analyst} <= 0.5

R_{Onshore,Software Engineer}+ R_{Offshore,Software Engineer} <= 4.5

X_onshore + X_offshore = 1

X_offshore - X_onshore >= 0

Any Optimization engineer will be able to solve the above equation using a tool to arrive at the optimal deal parameters. We did the above and identified the following optimal function.

The above is an approach 1 for constraint model for outsourcing deal.....how do we do this in approach 2? What are the limitations of the above model?

We'll revisit these issues later...any ideas and recommendations....

Cost optimization objective for service management/delivery in an outsourcing engagement - A challenge

As in any optimization problem the goal or objective of a outsourcing function is to minimize the cost of providing the service to the lines of business. Evolving an objective function is riddled with multiple factors making it increasingly difficult for one to establish an objective function. Typical factors of an objective function are:

1. Onshore-Offshore percentage

2. Choice of delivery location to perform the services in an outsourced environment

3. Composition of workforce to perform service delivery (managers, Analysts, Software engineers, etc.) and their cost

4. The number of shifts designed to perform service delivery

5. And several more (not sure what I'm missing here)

Modelling based on the above factors results in devising an objective function next to impossible. In this context I was considering two approaches for the same:

Approach 1: Why not we consider all the above factors and design one single objective function. For example:

Min ååå X_dC_aR_b

^{d a b}

where X is each location where service delivery is performed and d = {India, US, China…..}

C is the cost per shift per resource pyramid and a ={(Shift A,Cost of Executives in location d), (Shift A, Cost of Managers in location d), ,…..(Shift A, Cost of Software Engineers in location d), (Shift B, Cost of Executives in location d)…. (Shift B, Cost of Software Engineers in location d), (Shift C,Cost of Executives in location d)…. (Shift C, Cost of Software Engineers in location d)}

R is the number of resources per resource pyramid in each shift and b = {(Shift A, # of Executives in location d), (Shift A, # of Managers in location d), ,…..(Shift A, # of Software Engineers in location d), (Shift B, # of Executives in location d)…. (Shift B, # of Software Engineers in location d), (Shift C,# of Executives in location d)…. (Shift C, # of Software Engineers in location d)}

Approach 2: We peel the optimizing functions for each of the key parameters and individually optimize them.

I'm yet to figure out which is the best approach to figuring out a optimizing function. If I choose the former then the function becomes too complex and modelling the constraints equally so. Will such a function be solvable.

If I adopt the Approach 2 then I'm not looking at it from a systemic perspective and hence may inherently end up building a suboptimal objective function while the individual parameters themselves are optimized.

Any thoughts on what could be the right approach?

Service management - Applying simple queue model to address service management challenge

A simple Server queue model can be applied to address some of the challenges identified in the blog http://insightful-journey.blogspot.com/2008/07/service-management-issues-with-using.html:

The following step-wise approach can be adopted on the same:

1. Demand characterization is nothing but the l for a unique combination of the service factors (Service type, service scope, service domain and service category). The best way to represent such a set of demand characterization is defined using the mathematic notation below:

l = l_ijklm

i Î {Incident management, Problem Management, Change requests/enhancement..}

j Î {Level 1, Level 2, Level 3, Level 4}

k Î {Business, Infrastructure, Application…}

l Î {sev 1, sev 2, sev 3, sev 4…)

m Î {Java, .Net, Tibco, Oracle, …)

2. Capacity for providing service can be determined based on the service rate for each combination of service factor.

m = m_ijklm

i Î {Incident management, Problem Management, Change requests/enhancement..}

j Î {Level 1, Level 2, Level 3, Level 4}

k Î {Business, Infrastructure, Application…}

l Î {sev 1, sev 2, sev 3, sev 4…)

m Î {Java, .Net, Tibco, Oracle, …)

3. The optimal service level objective can be set by setting factors:
1. Utilization percentage (as indicated above) 70-90% but not 100%. (Note that a model which is 100% utilized is unstable)
2. Healthy backlog for tickets to smoothen the demand-capacity gaps. This can be determined as the number of request in queue for each combination of service factors
3. Balanced service time for service tickets and a cap on target improvement. Uncapped service improvement target leads to instability in system and disproportionate cost to maintain such a model.
4. Assuming a typical utilization of 90% we can determine the number of resources for each demand:

r _ijklm (number of resources) = l _ijklm /m _ijklm/90%

Total number resources R = å r _ijklm

This is a classical optimization problem where one can apply constraint theory for solving it. (We will cover this in detail later).

4. Designing the optimal demand-supply model can be determined by applying constraint theory for an optimal engagement.
1. Objective function is the minimum resources to manage the engagement (note we are not using a function to minimize the cost due to complexity introduced in the system due to workforce, the levels, delivery center utilized and so on)
2. Constraints are defined by cap on service requests, backlogs and service time for each combination of service factors,
5. Execution and sustenance of the service model requires one to have the right value stream map (a.k.a. service process), waste elimination by continuously eliminating non value added activities (for example reducing the infused management team for transition engagement), improving turn around time for service tickets by measuring and optimizing time for value added activities (one can also apply other engineering techniques such as DSM, concurrent engineering, etc.), using multi-skilling of resources through ongoing training, and so on.
6. Continuous improvement involves driving some transformation initiatives similar to ones identified in point 5 above to reach the ideal state as determined by the server queue modeling in Step 2.

Your comments & thoughts welcome!

Service Management - Triavialzing real-world complexity with a simple model!

The entire service management model can be based on simple Server-queue modeling concepts.

Model Factors
The minimum factors that one needs to understand of the client service management context for an item in the service catalogue are:

1. Service type and the associated processes are activities that contribute to transforming the inputs (a.k.a problem/incident) to a acceptable/predictable outcome (a.k.a resolution/work-arounds)
2. Service scope (Level 1, Level 2, Level 3)
3. Service domain (Business, Application, Infrastructure, Tools, etc.)
4. Service locale (process such as supply chain, HR; functionality such as order management; and technology such as Java, .Net etc.)
5. Severity and Priority within each level (such as Sev 1, Sev 2, Sev 3, etc.)

For the above service context one needs to get the following measures to model the service:

1. Total number of service requests (classified across the above dimension) over an interval of time. (Lets define this as )
2. Number of service request resolved and closed (classified across the above dimension) over the same interval of time as in point 1. (Lets define this as )
3. Number of service request as backlogs (Lets define this as Lq)

Simple Server-Queue Model concepts
Based on the above factors a simple server queue model as identified in the figure can be applied:



The simplistic model is premised on the following:

1. the mean-arrival rate has a passion distribution (established statistically through a goodness of fit test such as Kolmogorov-Smirnov test),
2. the service rate is exponential in nature (established statistically through a goodness of fit test such as Kolmogorov-Smirnov test),
3. All requests are homogenous in nature,
4. All service is homogenous in nature
5. Service is rendered on First Come First Served basis (FCFS)

But note that this is seldom the case and is a gross over simplification of real life scenarios. However, one can best understand the characteristic behavior of a model in its simple form.


What say you?

Service management - Issues with using Analytical model

The service provider often finds it difficult to agree to a SLA right-away due to several constraints:

1. Lack of clear baseline/benchmark for the service prior to outsourcing due to several factors:
a. Absence of management of service through metrics
b. Absence of structure, processes and organizations
c. Absence of system and measurements
d. Absence of right data in the systems (even if it is available)
2. High client expectations on improvement targets during outsourcing. This results in defining the target metrics at a level which the existing service organizations has failed to achieve

If clients’ services are matured and above constraints are not a bottleneck, then the challenge shifts to the following:

1. Characterization of demand (read as service requests)
2. Characterization of service (read as resolved service requests)
3. Planning the right capacity for providing service
4. Defining the optimal service level objectives for the lines of business and hence the service providers
5. Designing the right capacity-demand model to serve the clients
6. Executing and sustaining the performance of the organization to the defined service level objective, and
7. Continuous improvement on services to the clients and their lines of business

Do you agree? What other problems have you faced?

Service management - Do we have all the answers?

Clients often outsource service management to vendors to increase the value without assuming ownership for costs and risks. The value capture for the clients by outsourcing service management can be understood from several perspectives: cost, improved service to lines of business and so on (we would not dvelve into details of value management here). The only way the client can ensure utility and warranty of service (scalability, consistency, reliability, security, accuracy etc.) of the service from an outsourcing supplier is by imposing strict service level measures through the Service Level Agreement (SLA). The non-compliance to the SLA often results in business impacts on the lines of business, and the client often impose strict penalty on non-compliance of the SLA.

The intent of a service provider is to sign-up for a SLA limiting itself to controllable risk and manageable cost while making sustainable margin. But it not as easy as it sounds due to several reasons. To understand these reasons every service provider should start asking itself the following questions:

1. Does the client & service provider understand all the problems faced in operationalzing a SLA?
2. What analytical models/techniques one can use to ensure the SLA problem and the solution is well understood and factored in the overall solution?
3. When, Why and how should such a model be applied and not applied for a SLA?


Any thoughts...

Madness in the methods!

4.3 trillion combinations possible in a rubic cube. If one knows what he/she is doing it can be solved in 25 moves....

Isnt the above a amazing method to solve the Rubics madness.

But you can't apply the same method to winning a chess game, can you?

Methods have their limitations when applied to a problem. Not all problems can be solved through methods. Typical failures can occur under following circumstances:

1. Incorrect definition of problem
2. Applying the wrong methods or methods wrongly
3. Deriving the wrong conclusions of resolution
4. Underestimating the complexity and power of execution
5. Carrying rationality of thoughts too far!
6. Underestimating the intangibles!
7. Many other countless reasons.....that I've not listed

Dont you think a typical undergraduate can apply collection of methods to solve worlds hunger then?

Busting Business complexity: Shannons Entropy, Constraint theory and Game Theory

Business ecosystems are becoming increasingly complex. The ability of an organization to forecast and achieve growth and profitability in the complex business ecosystem is more than an art. Imagine how complex this would become for a new entrant in Hi technology industry. In the previous blogs we've seen how value networks can be used as an effective tool to model businesses, analyze, and define strategy. (We are not even talking about executing them! Will leave it to art for now!!!)

Complexity is not unique to business, several technologists and scientists (I've deliberately chosen to separate them) have traversed down the path and created techniques and tools to bust them. A business therefore isn’t so unique except that the factors are many and the dynamism of the factors themselves is uncontrollable. But if we can model an ideal business (assuming limited factors and controllable state) we can converge on strategies.

In this space one can consider some of the existing techniques/tools that have been used in several disciplines: defining a value network, using Shannon’s entropy to determine complexity of the ecosystem within which the business operates, using constraint theory to maximize revenue and growth KPI for organizations and of course use game theory (Stackleberg/Nash games) to model the dynamism in the business. There are several interesting articles I came across recently in this field and itching to apply them in real-life scenarios!

Is there a strategy problem out there for piloting these ideas?

IT Services Outsourcing Cost saving: Whats are easier then Hows?

Clients outsource IT services (typical run activities) for non-core applications to reduce the (SG&A) cost of providing the services to Line of Business. Off late clients are not just happy with the initial cost savings that may accrue to the business due to outsourcing of these services, they often demand that the service provider come-up with initiatives to reduce the year-on-year cost systematically over the duration of the deal. Service providers embark on such initiatives to reduce y-o-y costs starting right after the services are transitioned to a service provider. Typical questions that one often ask at this juncture are:

1. How much cost savings can be committed to y-o-y?
2. What are the levers one can deploy to reduce the y-o-y cost?
3. How will the initiatives be run around to reach target yo-y savings through each lever?

To answer the 1st part of the question, it has been observed that any the industry wide y-o-y cost saving cannot exceed 25-30%. The reason for that range is that anything at the higher end of the range affects the stability of the engagement to a layer that it makes it unsustainable.

To answer the second part of the question, there are 3 broad areas we can consider:
1. Arbitrage lever: For example Increase the Offshore % citrus-paribus (an economic talk!)
2. Resource Productivity lever: reducing the number of resources required to perform the service. This can be further broken down (reserve my USPs here...you need to pay me for this!)
3. Resource-mix lever: Getting to do more of the activities by junior resources who cost less.

Answering point 3 is the most difficult. The reason the initiatives that are rallied around these levers for y-o-y cost savings are highly subjective to the following:
A. Deal context (the initial engagement beginning parameters for the levers)
B. Organization context (both the client, and service provider dynamics)
C. IT Landscape context (services, applications, technology...etc.)
D. Other extraneous factors (blame it on the economy)

One may claim to achieve y-o-y savings through the jargon galore if the one does not appreciate the factors contributing to the subjectivity: standardized processes, skill development a.k.a ongoing training, lean, six-sigma, server-queue modelling, well i'm running short of those. We will discuss more of these later.

Typical IT/ITES Business Transformation Initiative

Objective

Launch transformation engagement in large IT/ITES projects with team size >=25 and reduce the y-o-y cost of service by 25-30%.

Key challenges

o Ability to maintaining cost competitiveness amidst rupee appreciation and wage increase

o Paradox of resource constraints for new engagements while having resource utilization issues

Benefits to IT/ITES engagements

o Increasing the revenue potential (to be benchmarked or baselined for improvement goal)

o Reduced cost of service for the engagement in the range of 25-30%

o Productivity improvement on the engagement by minimum 30%

o Better utilization of resources within engagement (>90%)

o Better management & control of the engagement (appropriate improvement in realized risks metric)

Key business levers

o Process improvements

o Skill development

o Workforce scheduling & allocation

o Ideal team sizing

o Onshore-Offshore management

o Pyramid management

o Demand-Supply management

Frameworks or technologies

o Work distribution and allocation modelling

o Server & Queue modelling

o Value stream mapping

o Concurrent enginnering

Required support to run the initiative

o Initiative sponsorship by top management and a team of 2-3 people

o Leadership time

o 5% of management time to evangelize the initiative

o 5% of management time to review progress of the initiative

o Management time: Dedication of 20-30% of Project managers time to run the initiative

o Access to systems and metrics to enable running the initiative successfully