2016: Is this the Year to “Go Digital?”

When an industrial giant like GE starts to move all your health data into the cloud using their new Predix cloud offering, you sit up and take notice. It’s clear that “digital” has gone well beyond Facebook and Google+. What does this mean for the enterprise?

The consumerization of IT means many of us have been acting and interacting in more digitally sophisticated ways at home and in our social circles than we do at work. In fact, in some cases, enterprise computing has lagged behind personal computing when it comes to the digital revolution. No doubt the scale of any decision to “go digital” is fed by considerable investment apprehension. Many large enterprises believe they can’t possibly act quickly enough to keep up with the steady march of new innovations emerging in the marketplace. This hesitation often translates into lots of talk about technology with little action. Especially when decisions about technology involve a radical change to a company’s way of doing business.

Instead of asking “What are digital technologies?” and “What does digital transformation mean?,” enterprises need to be asking “How can we use advances in technology to create sustainable and market-disrupting value?” Making sense of the dizzying rate of technological change is a matter of looking at it through your own, familiar and trusted business perspective.

In a new white paper, Avoiding the Siren Song of Technology: Focusing your Digital Strategy on Business Outcomes, I explore the ways leading enterprises are taking advantage of emerging technologies and as-a-service solutions to build a “digital fabric” to connect with and influence their customers, employees, partners and providers. By building a digital fabric, organizations can create new digital value in four distinct areas:

  • Digital customer experience
  • Digital products and services
  • Digital supply chain and manufacturing
  • Digital enablement and productivity

Enterprises should only invest in the opportunities that are right for them and on which they can capitalize over the long term. Understanding both the industry and the enterprise-specific market potential of these areas will help individual companies identify the initiatives that lead to the most promising solutions for their unique business objectives. Those that have been successful at traversing this new ground have been so, at least in part, because they have built healthy relationships with partners that bring market insight or help to build capabilities that are designed specifically for their sustained growth.

Read the new white paper or contact me directly to discuss further.

A digital reboot

It is almost two years since I last posted anything on this blog.

A lot happened in these two years. Remember in 2014 when every business conversation was all about Facebook, social and the social enterprise? And before that it was all about having a mobile presence and platform? And then it was all about big data?

2015 brought all these buzzwords together and to the ground. Suddenly we had the technology to carry out these ideas and conversations on how to use these technologies turned into mainstream. It was not just about outsourcing any longer. Nor was it just about technology & IT supporting business – it was much more now.

It was about leapfrogging transformation using the possibilities of technology.

Technology moved in 2015 from the back office to the enterprise front office. Enterprises are more interested in following technology trends in the Silicon Valley than they are in following best practices in the Outsourcing Capitals of Asia. Also the questions they ask themselves have changed – while operational excellence is still important, there is a limit to how much you can grow a business by cost cutting.

Technology can now drive revenues if you leverage it, or can bring down your current business model like a house of cards if you ignore it. And it is not about the individual technologies themselves, it is about how you can orchestrate this along with old & new business process to create new businesses & customers you never thought possible.


And when you are right in the midst of this storm as a consultant, you realise very quickly that what started out as a “digital transformation” is actually a business transformation.

Client conversations are very different today – they are all about how to steer and manage this change. Business Transformation using Technology can be intimidating – triggering more resistance than action.

Multiple topics that I had blogged about have now taken on a new meaning in this situation.  And almost every question that I had asked myself or explored 2 years ago just got challenged. There are new topics to explore.

It is time to reboot my blog.

photo credit: 8 via photopin (license)

Are you using the right measures to control your operation?

In my last post, I dealt with how you can use service levels to demonstrate the IT Value of your services.
Now we get into the engine room – we deal with how you should use service levels and operational level agreements to measure your own delivery operation. Your “delivery landscape” will be a myriad mixture of the services delivered by your own team, adjacent departments and the providers who handle the scope that you outsourced. I will not dive into how to manage each of these components since this is a subject in itself.
Instead I want to deal with the service levels and measurements that you should have in place for these interfaces.  While designing service levels for such interfaces, I have learnt to appreciate the difference in their nature to the ones that you used towards your business services.


The questions that you would now ask yourself are very different in nature to those that you use to demonstrate your value. Irrespective of whether you are measuring service levels with your provider, or setting operating level agreements with adjacent departments, the questions that you should ask are:
a) Can you use these measures to control and manage your delivery landscape?
b) Can the levels that you have set for yourself be attained?
c) Are you able to measure these service levels properly?

Can you use these measures to control and manage?

  • Control does not mean measuring each and everything that you can. Seek Emphasis in Service Levels. Sometimes the ease of measuring something serves the propensity to measure and report it.
  • Differentiate between measuring (for the sake of control) and reporting (for the sake of understanding) metrics.
  • Before you delve into finding out what you can measure, rather first concentrate on “what must you measure and why?”
  • previous exercise with your business department would have shown you how the service that you deliver inter-twines and actually affects the business operation
  • This will tell you whether you should look out for critical timelines, large transaction volumes, accuracy,…?
  • Concentrate on the few key measurements that you can actually use to control the key parts of the service components that you are managing. Derive these directly from the understanding of what makes or breaks your business.

Can the levels that you have set for yourself be attained?

  • Defining a Service Level Objective for each of your service components are not enough. You should  set values that are attainable within the costs or boundaries of delivery that you have been given.
  • It is no use to accept a 99.9999% availability target from your end client when you are unable to break this down across your applications and infrastructure or are not able to deliver this to within the budget constraints.
  • This is particularly important when you are getting zealous in managing your provider. In your eagerness to measure and manage your provider, you might be setting target values that are either too expensive.
  • After you have set values that you can attain, find ways to actually control how you attain these values. I have seen some IT managers cleverly build in latency into their system – a latency that can be gradually removed as the load on the system increases. These are many such smart practices one can borrow from system architects.

Are you able to measure these service levels properly?

  • There are miles between the intent to measure something and actually being in the position to do so. And the more holistic the intent (like Business Impact), the more precise you need to be in how you measure it.
  • So as you design your service levels, make sure that you actually know how this can be measured. I once had to convince a client that a particular Service Level Calculation (System Availability) was not fully thought through – it took us two hours to could come up with a formula to measure it.
  • Do the math. Start by very carefully designing the algorithm and formula for the measurement – what goes into the numerator? what goes into the denominator? What is the sample size of measurement? Are you aiming at a %age based measurement, or a number based measurement? What are the implications of both?
  • Then ask yourself: Do you have the service management capacity to measure and follow up all that you have designed?
Best practices from the industry, Service Level Agreement Examples, internet searches, and tool vendors will give you a plethora of choices of what you can measure. Reading about and gathering such measures is the easy part. The tough part is making the choice of what you spend your precious service management capacity on – and the art lies in translating this in summation to your understanding of how you are delivering IT value.

photo credit: Lifelog.it via photopin cc

Why Accuracy SLAs can create or destroy the value of your service

SLA literature in the marketplace waxes eloquent on topics like Availability and Performance. However one of the most ignored topics in an increasingly data-driven world are service levels that deal with Accuracy. Not paying attention to demonstrating accuracy can poke large holes in the value of your cloud and big data solutions. Here is how you can address such gaps.

Connecting to the Interweb Tubes

At first glance, Accuracy sounds soft and qualitative. A recent deep dive into this topic forced me to look the dimensions of Accuracy and I emerged with two aspects: Data Accuracy and Process Accuracy.

How Accurate is Your Data?

Accurate data is the basis of decision-making. In today’s world of big data and cloud enabled applications, where data resides physically in multiple locations, data accuracy is of prime importance. Lets look at two aspects of measuring data accuracy integrity and recency.

Data Integrity

  • This is a measure of how data is protected against corruption through logical errors, user input errors or hardware errors.
  • If data integrity cannot be ensured, this has a severe backlash on the quality of service that your application is providing.
  • A system which cannot guarantee certain levels of data integrity is of not much use even though it might satisfy high performance and availability SLAs.
  • So while ensuring that your application performance and availability, also ensure the same for your data.
  • So how do you measure data integrity? Data Profiling is a common approach towards measuring data integrity.
  • There are multiple technical solutions (as a Google Search on “measure data integrity” will reveal) which I will not cover in this blog post.
  • Focus on how to demonstrate measures for Data Integrity with your SLA Definition. 

Data Currency:

  • In an information-hungry world that relies on big data and predictive analytics to solve problems, the rate of data gathering and capture is increasing exponentially.
  • Data in such real-life databases can become obsolete rapidly.
  • Capturing data across various dimensions can sometimes led to multiple values of the same entity sitting in a database.
  • What is worse: some of these values would have been one correct – but most may have lost their recency and turned stale.
  • This can skew data-driven decisions badly especially when layers like predictive analytics pre-process data and you rely on the interpretation.
  • Sometimes such interpretations cause automatic algorithms to take actions which worsens the problem.
  • With distributed databases and data-warehouses spanning across different locations, latencies can introduce data currency errors too.
  • Especially in a high volume transaction system, such measures are critical.
  • If this is your world – then your SLA Management should demonstrate how good your application or your service is able to correctly identify the current value of an entity and answer queries with these current values, in the absence of timestamps? 

The Human Side: Process Accuracy

We should not forget the human side of data handling – this is where the second aspect of Accuracy comes in. And this is process accuracy. How accurate is your data assimilation process?

  • A typical data-warehouse system relies on multiple data feeds.
  • The number of such feeds continuously increases as the complexity of the application and data landscape increases.
  • Most organizations have very complex Extract-Transform-Load stages that make logical sense of the conglomerate data out of such feeds.
  • These are often very complex job control algorithms that are built in the form of workflows.
  • As the number of feeds increases, the complexity of such algorithms exponentially rises.
  • This reaches a point that logical errors creep in due to human design. This article talking about ETL architecture will give you a feel of how human intervention and decision making can impact otherwise sound data.

The human impact of your data

  • Performance data is an excellent example to explore the human impact of data.
  • Such data is the basis for financial rewards and career-making decisions.
  • To demonstrate value in such an environment,  you have to be able to demonstrate the accuracy of:
    • people filling forms or data in a database,
    • whether the right and complete data is being extracted for analysis,
    • whether all data is being used for analysis? what analysis algorithms are being used? Are they applied uniformly?
    • How is this analysis being interpreted? How are conclusions being drawn?
  • If your service is a Human Resources Platform as a Service offering, Accuracy measurements and SLAs for each of the above questions is critical to the value that you are able to offer
  • Sometimes this can be more important than the performance and availability of the system that you are running. Stacey Barr in this article raises some important aspects of the human side of data.

Are you creating value with Accuracy?

Depending on how data intensive your service is (large volumes, transactions, data-warehouses etc.), the concept of Accuracy will play a large role in how your service is being perceived.

Formulating an Accuracy SLA Definition is very situation-based. There is no industry standard. The environment that your service serves will show whether you should you be looking at duplication? or consistency and synchronisation? or data coverage?

Just like Performance SLAs, you are on the right track when you study the needs of the business that you are serving, and then look at how these needs depend on the different quality dimensions of data in your service that you offer. Here is your opportunity to demonstrate the value you are creating in numbers.


How data intensive is your service? Have you explored how Accuracy based SLAs can create or destroy the value of your service?

photo credit: nickwheeleroz via photopin cc

The Zen of Service Level Agreement Metrics – Emphasis

A series of my posts over the next weeks will look at the art of designing service level agreement metrics and SLAs. And I will try to distill this art into some key practices that have worked for me over multiple contracts – sitting on both sides of the table. We start with today’s cup of tea: Emphasis.

Zen Habit #1: EMPHASIS


Less is more

Bring focus and emphasis into the Service Level Agreement Metrics that you design. Don’t spread yourself thin and define multiple metrics across multiple dimensions. A sea of metrics will only lead to an average mediocre performance across the board.

Picture yourself after you define service level agreements and the ensuing SLA Management:

  • Do you see yourself trying to follow through on all these metrics every month?
  • How will you answer the question “do these metrics depict the true nature of our business?” ?
  • How will you decide which SLA metrics to focus on?

Ask yourself:

  • What happens if your provider is not doing well on one metric but well on the other? Is that good? Is that the behaviour you want?
  • Are you sure that the SLA metrics are not correlated with each other?
  • Which of these metrics will you use to drive your service improvement?

Sometimes the hardest part is not letting go of SLAs, but starting all over

You might have measured reams of metrics every month over the past years. And now you are trying to focus on the few that will drive the performance of your service.

How will you decide which metrics to focus on in your new service definition? Start by studying the business that your IT serves – which measures serve them best? Get to the root of your SLA definition.

  • Is it speed of reaction? Then measure the speed at which your provider implements small development jobs. Measure Function-points / week.
  • Is it predictability of budget? Then measure how accurate your provider can estimate.
  • Is it reliability of service? ……..you get the drift.

Add the above to your Service Level Agreement Checklist. Be extremely picky and choose the SLAs which comprehensively mirror the style of your business. In this way, when you drop the non-essential SLAs, your business client still supports the key ones that you have chosen to keep.

Learn to let go, but stay on top of your SLAs

As you define your new SLAs and move towards a new managed service, move away from measuring the inputs of the service. Start measuring the outputs of the service in your Service Level Agreement. Don’t measure your managed service by the speed at which your service provider onboards a team member. Measure your provider by the speed at which they delivers, and the reliability as per budget planned.

And finally stay on top of what you have decided to measure – if you have chosen your SLA metrics well, your laser focused attention on these metrics can lead to step changes in the service you offer.

photo credit: ecstaticist via photopin cc

The 5 Pillars of a successful Outsourcing Contract Pricing Model

Your organization is demanding more transparency in your Outsourcing operation and contract. The onus lies on your ability to study your operation and define your reasons for outsourcing. Then design a contract with your service provider in a way that you achieve the quality you need while forming a partnership with your service provider.
This post summarizes my last few posts of September and brings it together into the best practices that form the Five Pillars of an Outsourcing Contract Price model. The Five Pillars help you to model your operation into the pricing model – and can form the foundation and definition of your contract.

“STEER”ing your way to a successful Contract

The basis of a successful partnership with your service provider is a well-designed outsourcing contract. A successful contract stands the test of time if its pricing model is designed well. You can judge a pricing model by the way that it satisfies the following five best practices that I summarize with the acronym STEER (Scalable, Transparent, Encourage the Right Behaviour, Elastic, Risk-balanced):

5 Pillars Best Practice Outsourcing Contract

The 5 Pillars of a successful Outsourcing Contract Price Model

  • Scalable to handle Future Scope: the model should scale and accommodate all kinds of changes to the application portfolio over the duration of the service contract.
  • Transparent and Granular: Establishes a price per application and makes the price effect of each service easily calculable and transparent.
  • Encouraging the Right Behavior: the pricing should encourage good intent and reward good behavior from the service provider.
  • Elastic – the model should be flexible and breathe with the business and, at any given point of time, should reflect the effort required to provide the service.
  • Risk-balanced – the model should allocate operational risk to that party (IT Department or Service Provider) that can mitigate the risk best

Has the STEER model helped you?

Are there parts of your existing contract that you want to change after reading these posts? What will you do differently the next time?

Wordpress SEO Plugin by Wordpress SEO Plugin