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 ready to deliver your newly signed IT contract?

As this new business year begins, I want to start with a post that sets the note for my study topic in the first quarter of 2014. It is the demand for continuity in every sense – after signing an IT contract – a topic often ignored: SERVICE TRANSITION.

Service Transition has nuances that go beyond what is prescribed in ITIL. Discussing and negotiating large IT contracts requires more effort than one actually thinks it should entail. This often leads to the result that people are singled out for 5-6 months to design and close the contract. On the IT buyers side, this is usually treated as a project with definite goals. The providers put together what is generally known as the pursuit team (with sales, technology experts and solution architects).

The solutioning and contracting process is an effort intensive task and involves the above teams sitting together for 5-6 months – meeting every day and having very detailed discussions on how to set up future operations. Depending on how such discussions go and the amount of value each side finds in the other, these teams either grow apart or get closer to one another. The presence of an advisory party helps to bring balance into the contract in both situations. I have been on all sides of this table – and it has been a 360 degree learning experience. It is amazing how your current viewpoint can affect the way you interpret a situation.

After the contract is signed, the IT buyer team is relieved on having completed the “contracting project”, and the Pursuit team celebrates having won the contract. What both teams often neglect to do is getting their individual organizations ready for the contract.

After seeing many initiatives go through the trough of despair after signing the contract, here is my thought-jogger list:

If you are buying IT services…

Have you thought of:
a) Does your team know the scope of services of the contract?
b) How should your team reorganize themselves to face the new provider – what are the touch points?
c) What are the new roles and responsibilities on your side of the contract? Have you designated a Service Transition Manager?
d) Who should perform the above roles? Are they equipped for these roles (skill & experience)? Are they enabled to perform these roles (time and authority)?

If you are the Provider

Have you thought of:
a) How do you transfer the knowledge gathered during the contract into the delivery organization?
b) How do you ramp up to get the people who you need on the ground asap?
c) How do you continue the relationship that you have just painstakingly built over the last months with new members entering the picture?
d) What should you set up to manage the contract that you have negotiated?
e) How can you transfer the good relationship and rapport that you have built up with your new client to the future delivery team?

Ideally you don’t want to bring in the Delivery organizations on both sides into play only after the contract is signed.

Such discussions and decisions should happen long before. There is great benefit in bringing these parts of the organization earlier into the picture as periphery teams. The core teams should involve the periphery teams gradually into the discussion in the later stages of the contract. This should go through the stages: BRIEF THEM ON SOLUTION, INVOLVE THEM IN THE DISCUSSION, INVOLVE IN DECISION MAKING. Both sides should perform a contract readiness check based on questions such as the above.

I will be spending the first quarter of 2014 exploring the multiple facets of this situation. Stay tuned.

photo credit: qwrrty via photopin cc

How to run your IT like a business using Service Levels

There is growing interest in running IT like a business. Internal IT departments are competing against alternative services (a.k.a. Shadow IT) and are under pressure from growing expectations due to what the industry calls consumerization of IT. IT leaders across organizations are stepping up their act to go from an internal operations to fill the shoes of an IT department that is increasingly becoming part of the overall business.

In this new world, an internal IT department is being forced to cast away its traditional mode of operation, and compete and position itself in this new IT marketplace.

The new role of IT

Positioned between the Business and the Service Providers, IT has the opportunity to carve out a new role for itself – based on an orchestration of internal and external IT services. In doing so, it should be careful not to turn into “just an administrative interface”.  It should rather leverage its position.

Using Service Levels to run IT like a business

Using Service Levels to run IT like a business

IT should now focus on:

Creating Value: The new IT thinks differently – it does not necessarily think “profit” but it thinks business. It seeks to understand the intricacies of the business, and then analyses how IT forms a part of the business delivery chain. In doing so, IT shows the business how its service offerings are relevant. IT tracks technology trends and translates these trends into a concrete service offering that makes sense for business. In doing so, it takes make vs. buy decisions. It chooses to procure commodity services, or even partner with innovative providers for co-creation. The role it always retains is “driving the business relevance of IT”.

Integrating Services: IT goes from operating traditional technology silos to a service integration and orchestration. It converts rigid capital costs into flexible operating costs.. It decides how the regulatory compliance laws and guidelines of the business are translated into its IT hosting strategy (internal and external). In doing so, it translates its understanding of how IT intermeshes with business into a modularization of its service landscape. It fills the nooks and cracks in between the services it procures (esp. external providers) to offer a smooth integration.

Optimizing Operations: IT differentiates between core tasks where it is crucial that IT plays a leading role and commodity tasks and services that can be procured. It shifts its attention from solving incidents and tickets to enterprise strategy. It focuses on measuring the impact of its service integration instead of performing the individual commodity services.

IT should go now step beyond just doing the above – the charm lies in being able to demonstrate it quantitatively. This is where Service Levels come in.

Can Service Levels help in positioning?

The art of designing service levels lies in the context of the interface that you are managing – whether this is an interface towards your service providers, or towards your end client.

Start the Value Conversation towards your End Client / Business through a Service Level discussion by following these three steps:

1. First help your client understand the service you offer in terms of Service Levels.
2. Then, together design Service Level Objectives that aid their decision-making,
3. And finally, aid them in fixing service level targets that they can afford.

More about these three steps in “Three Steps to Demonstrate the Value of your IT service“.

Design your service orchestration layer and manage your service provider interfaces by asking very different questions. 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?

More about these three questions in “Are you using the right measures to control your operation?“.

After a detailed appraisal of your operations and strategy using the above, concrete Service Levels will help you as an internal IT department to compete and differentiate yourself in this new IT market place.

Are you facing pressure to demonstrate the value of your IT services internally? Are you facing the constant threat of “Shadow IT”? Have you ever thought of using Service Levels to position yourself?

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

Three Steps to demonstrate the Value of your IT Service

It is Monday morning 09:00 AM – and you are in your monthly IT Service Quality meeting with your “internal client” – the Sales Department of your company. The Head of Regional Sales is pushing you with unrealistic expectations – you have discussions about 99.999% availability where you already know that such a Service Level Objective is either horrendously expensive or probably also not attainable. You are on the defensive.

And you are thinking to yourself: “This is not the discussion I want to have – I want to instead show him the value that my IT department provides”.

Start this Value Conversation through a Service Level discussion by following these three steps:

  1. First help your client understand the service you offer in terms of Service Levels.
  2. Then, together design Service Level Objectives that aid their decision-making,
  3. And finally, aid them in fixing service level targets that they can afford.

Analogue 5426_BW

STEP #1. Does your client really understand the service you offer?

  • Does your business really understand the IT service that you are providing? Do you understand the direct correlation between your IT service and their business? Do they see the impact of what you do or provide on their business?
  • If not, help them first see this relevance. And in the process, you will develop a feeling for the aspects of the business that are important.
  • Feign from asking direct questions about what is important to them – you might not get the correct answer.
  • Instead quiz them more about how your service inter-meshes with what they do.
  • Their answers will bring out aspects that are important to them – is it timing, is it the impact of a downtime, is it availability, is it throughput at certain times of the year? Is it handling large volumes?
  • This constructive dialog will give you not just an understanding of your end-clients business, but also the aspects of your service that are important. Use Service Level Agreement Examples if this helps.
  • Derive your service level objectives from these aspects – this will help you to capture your mutual understanding of this relevance of your service and make this transparent to your client.

STEP #2. Can your client take decisions based on the Service Levels you measure?

  • You have come up with a set of service level objectives which directly measure the aspect of your service that is important to your client – now go to the next stage.
  • Discuss with them about how certain aspects drive business decisions
  • Lets say you are hosting a Sales Application, and the SLA on availability of the application is tantamount for sales closure.
  • Your discussion might show that availability of this application is critical as you approach Christmas. This is when they would want your application availability on full throttle.
  • But what about the rest of the year? Maybe keeping this application on full throttle high availability for the rest of the year is too expensive.
  • How can your SLA Definition help you decide what to do? What if you design a threshold level for your availability – so that falling below a certain level sets off a signal for both your client and you to take this to the next level of availability?
  • Don’t stop at just designing a service level and a target for the same – mutually decide with your end client on what happens when services fall below the minimum level.
  • There is a dual benefit – your client will see directly how to use and tune the service you offer via SLA Management, and you will be prepared beforehand about how to react and what to consider when certain levels are reached.

STEP #3. Help your client manage the Cost of Service.

  • If you have done the above two, you would both have a good mutual understanding about how service levels can be used to manage the service that you are providing.
  • Now steer your discussion towards the Cost of Quality. What is the balance of cost versus the quality of the service you provide?
  • Continuing the example of a hosted Sales Application: Lets say that the high availability of this application is only desired during the Christmas season.
  • You can now suggest that the SLA on availability of the application be reduced during the “idle” months by shutting down a few servers – and you would pass this cost benefit on to your client.
  • When the sales volumes increase, you could kick in the additional computing power.
  • This will help you define two levels of service for the two periods. And you could design the switch between the two levels of service based on a target threshold for your service.

The above three step process will help you have a fact-based quantitative dialog with your end client. You can demonstrate the relevance of your service quantitatively to your client through Service Levels, and also together decide on how this is measured and used.

And with this, you will have quantitatively established the added value that your IT adds to your business.

photo credit: Thorbard via photopin cc

Wordpress SEO Plugin by Wordpress SEO Plugin