Infrastructure Services are definitely undergoing a major transformation. How does one navigate the web of emerging technology trends and stay ahead of the game? Read on to learn more on our Infra Matters blog.

« July 2012 | Main | September 2012 »

August 29, 2012

Lean IT implementation for Service Improvements

These days, organizations are steadily focusing on deriving maximum value from IT services by integrating & implementing Lean methodologies in their IT space. Lean philosophy suggests creating value by eliminating waste, enhancing value in customer eyes and  viewing all services from a customer perspective.

Applying Lean to IT services:

This starts by analyzing and optimizing IT Value Streams to remove non-value added activity or waste. Here, the Value Streams are the applications and services that IT delivers to business, along with management of these applications and services.

 Mapping common Lean tools with IT:

  •  "Kanban" (Visual control system) - In an IT context, this would include project dashboard, business footprints charts, real-time dashboards and communications
  • "Jidoka" (Process automation/ tool usage) -  This would include productivity improvement, usage of reusable components and process optimization
  • "Muda" (Waste Reduction) - Identifying items to arrest waste in IT operations or software delivery
  • "Poka-yoke" (Defect Prevention) - This includes defect prevention activities, prevention of error in next stage and phased entry/ exit criteria

Embedding  'Lean principles' in ITSM operations:
Project and Service Managers can focus their attention on implementing Lean principles in their project and service lines. This can be done in the following way:

  • Analyze the As-Is process: Identify projects/ workstream for lean implementation, shortlist the associated activities in the project streams and how it can be split into sub-activities. Develop a uniform framework that includes identification of inefficiencies, investigating the constraints followed by implementing solutions in a phased manner
  • Identify the areas of improvement:  Based on the applicability of Lean tools in the activities identified above, implement these tools after a thorough due-diligence
  • Measure the Value: Once the Lean tool has been implemented, we need to monitor and track those projects/ services for analysis. Try to measure the improvement in terms of Customer Satisfaction, Revenue Enhancement, Increasing Resource Efficiency etc. 

Following and executing Lean principles can result in measurable business benefits:

Reduction in cycle time: Time taken for resolution of tickets i.e. MTTR / STR is significantly reduced
Automation of server agent: Elimination of manual effort & reduction in operations cost
Automation of vulnerability assessments: Scheduling scans, vulnerability analysis & report generation can be automated resulting in more savings


In my next post, I will be focusing on implementation guidelines for Lean principles.

August 28, 2012

Knowledge Management: Through a Consultant's Prism

Knowledge, as they say, leads up to wisdom. This sounds like an obvious transition at a spiritual level. For an organisation, however, 'knowledge' - if stored, managed, controlled and governed effectively - itself could prove more important to have than wisdom. Simply put, my view is that knowledge for today's organisations is a 'must have', and wisdom is a 'nice to have' entity...

Knowledge, as they say, leads up to wisdom. This sounds like an obvious transition at a spiritual level. For an organisation, however, 'knowledge' - if stored, managed, controlled and governed effectively - itself could prove more important to have than wisdom. Simply put, my view is that knowledge for today's organisations is a 'must have', and wisdom is a 'nice to have' entity.

No wonder then that we hear a humming buzz all around about the art of knowledge management. Books and jargons are being published frequently to suggest it is a serious matter. It had to be only a matter of time before ITIL came up with a set of streamlined best practices for knowledge management.

The bookish way of looking at Knowledge is that it refers to any practical understanding of a subject in relation to service support and delivery. It may include any description, facts, information, or skills acquired through experience. What it suggests is that you need a weapon that knowledge needs to ride on before being stored or deployed somewhere. That is what we call Knowledge Articles which capture knowledge in a consistent and pre-defined format. We just spoke about disciplining the practice of knowledge creation, you see!

Certain business or technology units within your organisation may create sensitive bits of knowledge articles which they - for obvious reasons of confidentiality - would not wish people from outside their groups or units see. There are various ways to restrict the visibility of such knowledge articles in today's business world where multi-tenancy is fast becoming the order of the day. The idea here is to be able to share to the extent possible your perspectives, experiences and information, making optimum use of the knowledge management platform. One of the reasons behind this is the known practical issue of having to re-create or re-discover knowledge which you know is available somewhere but has not been formally documented into the knowledge management system. There is certainly this human thinking of being able to magically 'find' the knowledge we need to apply, rather than volunteering to 'create' a knowledge article and publish it, so others in need may be benefited from the content of the article. It is therefore important to appreciate that knowledge is everyone's and joy is in sharing it.

There is a good number of ITSM tools available today, offering impressive process-tool interface capabilities, which could be used as a good foundation for establishing an effective knowledge management practice. In case you are tasked with implementing this process, you will figure out - as is the case with any other ITSM process - that some organisations already have certain standard or non-standard way of managing knowledge, and then there are organisations for whom knowledge management is a virgin territory. It should be comparatively easy to convince - as a consultant - the newbees than dealing with the so-called seasoned champions who naturally are burdened with their own experience!

It helps to go with some homework on an alternate Operating Model that you feel you could sell. It may work wonders in case you could encourage them through your workshops to believe that their existing way of operating knowledge management may have lived beyond its expiry date, and the new model could just be what they must try out. At times though, the current operating model could be good enough with a little bit of tweaking around, for example, the governance layer.

The ITSM tool (e.g. BMC Remedy, Service Now etc.) plays a major role in influencing the thinking of the teams within the organisation that are going to work on knowledge management in some way as part of their day-to-day activities. It is human tendency to relate process or procedural gospel to certain step-by-step tasks before you nod your head to doing things in a new way. And tasks are where the tool comes into the picture.

What could complicate the matter further is the multi-vendor environment a lot of organisations operate in. More often than not, vendors and/or third party suppliers come with their own ITSM toolsets which they use to manage chunks of knowledge they feel are relevant to their area of support or service. If you ask them, they will tell you they do not care if your client wants to onboard a new ITSM tool or upgrade the existing tool for better alignment to the knowledge management process. For example, a vendor that looks after your client's infrastructure may not be excited to know what kind of articles are being published in the non-infrastructure space. A point may come when you must speak about how the vendors' internal knowledge management system shall be integrated with the new or upgraded centralised toolset that is driven by the enterprise knowledge management. The biggest question at this stage is to decide what you want to do with the potentially thousands of knowledge articles stored in the vendors' tool system. If the decision is to sunset their tool and 'migrate' into the enterprise system, it must be coupled with an understanding of how they are going to perform the knowledge content transfer. It is hard to believe for practical reasons that such a transfer procedure can happen automatically, given that every new article coming into the new knowledge system must conform to the enterprise knowledge management standards defined by you. What this means is that there needs to be an onboarding or transition team to look after this critical phase of 'mirroring' only relevant and accurate articles. These articles must also then go through the formal review and approval cycles!

Unlike some of the other more conventional ITSM processes, knowledge management encourages certain roles to wear multiple hats. While it is recommended that you form specialised teams for the review and approval of knowledge articles, everyone has a responsibility of creating articles if there is none available which is relevant, accurate and useful with respect to specific issues, concerns or topics. The knowledge management repository however is not like a library that has one million books most of which are never read or rented by people. Only the articles which are relevant and useful should be retained in the tool system and others formally retired or cancelled.

One trick that generally works for a consultant is to not treat knowledge management as identical twins of processes like Incident or Problem or Change Management. These processes have already stood the test of time, made good friends with organisations, and thereby are better understood by people who are tasked with practicing those modules. Knowledge management is still like a baby everyone wants to adopt, not quite knowing how to. What is difficult to understand - and mind you, this is just one of the many challenges people face - is that everyone has a role to play with respect to contributing to new articles or updates to existing articles. There may never be a dedicated group that only creates articles!

Some may pose a realistic question. At the time of working on the resolution or recovery of an incident or a problem, a technology specialist may look for a relevant article and may not find one. Will the specialist generally feel encouraged to write a knowledge article summarising steps that helped the resolution and then push it through the formal review & approval process? If typical human behaviour is anything to go by, I would be shockingly surprised if all or most of the specialists did that proactively without considering the incentives they could get in return of this otherwise 'generous' act! This mentality of 'more give, less take' cannot become reality in one day. What I am essentially thinking of is the introduction of a structured incentive mechanism linked somehow to employees' performance appraisal system. You got to also factor in the cultural variance quotient for a better understanding of how to devise the incentive pattern, given the diverse geographic spread a lot of units and groups within one single organisation enjoy today.

However daunting it may seem knowing we do not live in an ideal world, it is still possible to have an effectively functional knowledge management practice. One of the secrets of this potential success story is the set of Key Performance Indicators (KPIs) that you would socialise with the process stakeholders. These KPIs lay out the foundation of the reporting competency, enabling an ongoing pit-stop measurement against process performance.