Quick guide to SIAM

This article has been contributed by Jan Vromant, Product Manager at Fruition Partners.

Many silo-based IT departments and service providers fail to deliver on their promises of cost savings, service improvements, and innovation. In addition, the finger-pointing among multiple internal and external suppliers and often inflexible contractual constraints render it difficult to address market challenges in an agile way. The complexity and lack of transparency make it hard to understand the necessary action items to achieve the necessary end-to-end service levels and meet the expectations of the service consumers.

Driven by the need to manage the results of typical multi-supplier eco-systems and to accommodate the increasing need for go-to-market speed, organizations are now looking for a multi-supplier sourcing model to address the necessary governance and achieve the expected but hitherto missed opportunities. Service Integration and Management (SIAM) is a sourcing model based on leading practices observed at major global organizations. It is a functional group that provides the governance and a single point of responsibility for the delivery of integrated services to the client, based upon an operating model that focuses on core organizational competencies and delegates or outsources the activities that are deemed non-core or commodity. The granular services, provided by multiple internal or external service providers, are integrated by the SIAM function to ensure end-to-end service levels and transparency. The SIAM function (also called the Guardian Agent or Integration function) is responsible for matters pertaining to interoperability, cross-functional coordination, governance, and end-to-end service levels.

The main goal of SIAM is to coordinate internal and external suppliers and their services in a cost-effective way to achieve the end-to-end service levels needed to support the goals of the business functions. SIAM is a layer between the suppliers and the IT functions that supports and enables the integration of the services offered by multiple (internal and external) service providers.

"The main goal of SIAM is to coordinate internal and external suppliers and their services in a cost-effective way to achieve the end-to-end service levels needed to support the goals of the business functions."
“The main goal of SIAM is to coordinate internal and external suppliers and their services in a cost-effective way to achieve the end-to-end service levels needed to support the goals of the business functions.”

There are two major components to the service integration layer:

  1. A commercial component deals with activities around contracts, procurement, service level penalties, invoicing, etc. One can think of this component as the format, the structure, or the commercial and contractual controls of the SIAM concept.
  2. The integration component is more like the content or the “meat” of the concept. It comprises all activities that focus on the actual coordination of the services provided by the multiple suppliers, and can be split up in three sub-layers: managerial (e.g., vendor analytics, project management), operational (e.g., cross-supplier change management), and infrastructural (e.g., data dictionary management) aspects.

Pain Points

The intention of the multi-supplier sourcing model is to address the following potential pain points:

  • Reluctant collaboration across suppliers, caused by unclear delineation of responsibilities and accountability;
  • Lack of transparency and incomplete understanding of end-to-end service level performance;
  • Contractual compliance without innovation;
  • Impotent governance and multiple costly change orders for minimal efforts;
  • Poor architectural integration with multiple points of failure;
  • Labor-intensive reporting and inadequate data to ensure fact-driven decisions.


The possible benefits of the governance model are to offer:

  • An effective framework for managing supplier performance and improving consistency in service levels;
  • A single point of accountability for end-to-end service delivery to the business;
  • The ability to seize benefits in technology breakthroughs to reduce IT costs;
  • The capability for managing IT risks and compliance across the eco-system;
  • A mechanism to enhance alignment of IT priorities with business objectives.

Enterprise Service Management

The solution architecture of SIAM relies on the characteristics of service management tools. There are several service management tools on the market, but the main attribute is the functionality of tool modules to share data across the various internal departments (legal, IT, procurement, facilities, HR, etc.) that own and enter the data. This concept is what Fruition Partners calls Unified Service Delivery (USD) and is the foundation for managing services within an enterprise – or Enterprise Service Management (ESM) . ESM is what we want to achieve; USD is how we achieve it.

When considering what is needed to enable multiple stakeholders to plug into a common technology, we first look at the basic building blocks of the technology:


Common usage of data eliminates redundancy and makes it easy to update data elements. The data resides in structured tables that are common to all service management tool modules.

Sectioning off certain data elements is enabled by the domain concept in the tool. Pre-defined roles (e.g., an HR employee or an IT system administrator) enable a role-based access management that dictates who can read, write, modify, or delete data.

The most powerful feature of a service management tool should be its workflow engine. The simplicity with which workflows can be configured is instrumental in the success of the tool’s value to its users.

Forms / UX*
Via Content Management System functionality, the client keeps control of the end-user experience and the forms that are or can be used by particular client roles.

The out-of-the-box graphical capabilities and service-aligned reporting of typical service management tools facilitate decision-making to achieve intended results. Reporting functionality provides the visibility and transparency to understand and manage outcomes.

The service management functionality contains the necessary and sufficient elements to support the goals of multiple stakeholders. As such, the technology has the capability to function as an Enterprise Resource Planning (ERP) tool or system. The ERP functionality provides an integrated real-time view of core business processes, using common databases and a powerful workflow engine.

Unified Service Delivery

Unified Service Delivery is the concept of facilitating the information flow between business functions, using the building blocks of the service management tool technology.


A typical example is the effort of onboarding a new employee: Facilities needs to take care of office space; HR will need to determine the role of the new employee and his or her access needs to particular applications; IT needs to provide a laptop and provide access to various applications; Procurement may need to provide a mobile phone; Security needs to provide building access; HR needs data to ensure the employee will get paid; etc. The shared data and workflow rules of the service management tool enable such routine onboarding requests to take on the characteristics of transactions we are now accustomed to on websites such as eBay or Amazon.

The success of the internet-like transactions paradigm in the tool eco-system is based upon multiple factors, such as employee self-service, speed, reduced costs, immediate feedback of request status to the user, consistent graphical user interfaces, and reporting capabilities.

Unified Service Delivery is the effective, efficient, and consistent delivery of services, calling upon intertwined enterprise stakeholders and using common data, powerful workflows, comprehensive security, consistent user experiences, and suitable reporting tools.

SIAM Architecture

Similar to the concept of the Unified Service Delivery explained above, the modules that make up the service management system share the building blocks across the various internal and external groups that provide and use the data.


The system facilitates information flow between the stakeholders. More importantly, it enables the client enterprise to keep control over data, its security and access, the workflows that use the data (e.g., in service requests), the user interface and user experience, and the reporting. The service management tool hence plays the role of a transaction bus, channeling data and activities from one stakeholder to the next, based upon the path in the workflow, and within the security guidelines (e.g., encrypting certain data) and access parameters.

Jan Vromant, Product Manager at Fruition Partners.
Jan Vromant, Product Manager at Fruition Partners.

A good example is the roll-out of a new module for an existing application in the enterprise. The Application Development or commercial off-the-shelf software (COTS) supplier provides the code; the network people ensure that additional bandwidth will be available for the encrypted application data; the internal data center has the servers ready for the application and the data; the HelpDesk prepares for the initial wave of questions by developing frequently asked questions (FAQs); an external disaster recovery supplier ensures backups of the data; the application maintenance group puts the final touches on the user acceptance testing (UAT); the change advisory board (CAB) makes sure that checklists have been checked off and all relevant stakeholders are informed and give their thumbs up. The complexity and number of interactions between the different groups can be difficult to manage if it is done without a centralized ERP tool.

An effective service management tool allows the smooth interaction of stakeholders and enables the seamless transition from one task to the next. Its functionality also allows the auditability and full traceability of approvals and who did (or failed to do) what. The fact that the facilitation happens in the cloud, with a minimal footprint in the internal IT architecture, can be a happy bonus.

The SIAM concepts rests upon this functionality and the tool functionality enables the core value of SIAM to shine. The client controls the data entered by the different stakeholders and achieves a transparency and visibility in the system that is unprecedented.

Outsourcing SIAM

The SIAM layer itself can be outsourced – completely or partially. The decision about outsourcing particular activities within the SIAM layer should be based on (a) the capabilities of the potential internal or external agents that can perform the necessary activities; and (b) the consideration if the activity is a core competency or not. Typically, strategy and architecture are not good candidates for outsourcing as they are key ingredients of the enterprise’s business model.

It is useful to look at a SIAM outsourcing decision from the perspective of process, people, and tools.

Process Considerations

Some of the questions to consider when structuring the SIAM activities are related to the process maturity of the environment and its stakeholders:

  • Are the process activities and cross-supplier coordination efforts well-defined?
  • Is there a comprehensive RACI matrix in place? Do the contracts contain clauses to address changes in the RACI matrix?
  • Do any or some or all of the service providers adhere to ITIL v3 or COBIT?

These questions will guide you in scoping the organizational change and process redesign efforts.

People Considerations

The success of the SIAM model is heavily dependent on the knowledge and experience of the resources that perform the SIAM activities. The combination of IT operational skills and a deep understanding of processes are critical to achieve the SIAM goals. Expertise with the structure of outsourcing contracts and with legal aspects, together with a solid foundation in procurement and supply-chain processes can also strongly influence the success of SIAM initiatives.

Technology Considerations

The focus of the technology considerations should be on the degree of architectural integration. Examples of this integration could be a common data dictionary, federated configuration management databases, discovery tools, orchestration, and automation.

To ensure the multi-sourcing technology is effectively reducing the complexity of the multi-supplier eco-system, it is critical that the architectural structure of the technology aspects is well thought through. Rapid deployment attributes, common data repositories, agreed-upon definitions and workflows, and defined access and identity management are examples of characteristics of an enabling tool and functionality architecture.

Decomposition of the Service Integration Layer

As mentioned earlier, the Service Integration Layer has (1) a commercial component and (2) an integration component. Below is a breakdown of typical sets of activities one can find under these headers. The decomposition is not intended to be exhaustive, but provides a guiding structure or framework and a suggested common taxonomy.

Commercial component

  • Procurement – Procurement is the acquisition of goods, services or works from an outside external source. The Service Integration Layer assists in finding the best possible cost to meet the needs of the client in terms of quality and quantity, time, and location.
  • Auditing – Auditing is defined as a systematic and independent examination of data, statements, records, operations and performance, including operational and service levels, adherence to process directives and legal / compliance requirements. The Integration Layer reports on the audit results, the corrective actions, and the continual improvement efforts of the service provider.
  • Invoicing – Invoicing not only covers the actual matching of the delivery of services with the purchase or service orders, but also covers the auditing of skill sets, hours, and appropriate levels of resources.
  • Contract Management – Contract management is the management of contracts made with customers, vendors, or partners. It includes negotiating the terms and conditions in contracts and ensuring compliance with the terms and conditions, as well as documenting and agreeing on any changes or amendments that may arise during its implementation or execution.
  • Governance, Risk, and Control – The GRC area deals with risk management, refining of cross-supplier procedures, and other aspects that relate to governance.

Integration component

1. Managerial aspects

  • Service Level Management and Service Reporting – The functional area of service level management and service reporting covers the consolidation and coordination of the end-to-end service levels and the related reporting per service. The service levels include run-of-the-mill metrics such as first call resolution (FCR), mean time to restore (MTTR), or number of unauthorized changes, but may also include more complex service levels such as disaster preparedness, recoverability of services, and joint testing.
  • Continual Service Improvement – The SIAM function is expected to manage and coordinate the continual service improvements across the suppliers, and monitor and report the results of the individual suppliers’ improvements.
  • Program and Project Management – The PPM is responsible for the management of projects and programs that span suppliers and should coordinate their input into the project or program.
  • Financial Management – This process deals with all cost, charging, accounting, and budgeting aspects and benchmarks each provided service that is delivered to its value.
  • Vendor Performance and Analytics – These areas cover the analysis and reporting of the individual and end-to-end performance of the suppliers and the eco-system. This is where typically the different individual service levels are broken down to the operational granularity and compared with the contractual indicators.
  • Service Catalog – This process manages the services and their subcomponents, the Service Requests.

2. Operational aspects

  • Operations Center or Operations Bridge – One of the major elements of SIAM is coordinating the monitoring of IT events, together with the cross-supplier management of major incidents and the related root cause analysis efforts. The Operations Center could include such systems as the “single pane of glass” and may also feature a combination of network operating center and security operating center to account for a seamless transition between IT Operations and Network or Security towers.
  • Change Advisory Board – The SIAM function can be charged with managing the Change Advisory Board (CAB), producing an integrated change calendar, coordinating change windows, and generally, communicating aspects related to risk and impact of changes.
  • Major Incident Coordination – This header covers the coordination of major incidents across suppliers, including the oversight of effective cooperation to restore services as quickly as mandated by the end-to-end service levels
  • Problem Management Oversight– This aspect involves ensuring consistent root cause analysis and proactive problem tackling by the multiple suppliers to prevent reoccurrence of incident tickets.
  • Release and Deployment Management – The topic of release and deployment management for SIAM covers the responsibility to coordinate the deployment of major applications and the related integration insofar it relates to multiple service providers.
  • Request Fulfillment – This covers keeping track of service requests, managing the related workflows and interactions, together with the associated user interfaces and choices.

3. Infrastructural aspects

  • Service Asset and Configuration Management– The SIAM responsibility is to understand the landscape of configuration items (CIs) and software and hardware assets as they pertain to end-to-end service levels. This may include software licensing compliance aspects, cross-suppliers CI relationships, the tie between particular CIs and major incidents, etc. In contrast to the typical narrow and deep data repositories that can be found at each supplier, SIAM focuses on a broad and shallow configuration management database (CMDB) containing only the CIs relevant to the end-to-end service levels.
  • Service Management Tool Application Maintenance – This set of activities covers incidents, problems, and changes related to the tool environment. It also includes minor and possibly major enhancements to the service management tool platform.
  • Automation and Platform Management – The need to reduce complexity is best served by a single architecture and data model. The Platform and Automation management focuses on the architectural execution of this mandate with a periodical review and the generation of a set of recommendations.


To achieve the governance that will make multi-sourcing arrangements effective, clients must get internal service providers and external suppliers to work together, both from a commercial and operational standpoint. The integration layer, consisting of elements of process, tools, and people, is critical to the success of these arrangements.

This article has been contributed by Jan Vromant, Product Manager at Fruition Partners.

The Avocado of Knowledge Management

Recently I’ve been talking to many servicedesk managers from different organisations to better understand the service delivery problems they solve with Knowledge Management.

Knowledge Management is a funny old thing – it certainly has a high level of awareness amongst servicedesk managers but isn’t considered as fundamental as Self-Service, Incident, Problem, Change or Config.

Most of the practitioners that I spoke acknowledged that they would like to do more with their implementations of Knowledge Management but – as we all know – sometimes it’s all people can do to keep services running and SLAs met.

We posed what we hoped was a probing question to servicedesk managers. “If we could prove that investing in Knowledge Management resulted in improved service to end users… would you do so”

Towards the end of this article I’ll provide some real life responses to this question.

Effective knowledge management certainly has the potential to both improve service and reduce costs for an IT organisation by encouraging shift left… shift down


This model – defined by Tim Cobben from KPN in the Netherlands – shows how incident resolution time and cost increases as the resolving engineer moves up and to the right, away from the customer.

As issues are escalated from the service desk to 2nd or 3rd line support groups, we are resolving the issue with more expensive engineering resources that are further removed from the customer.

The aim of the IT Manager should be to shift left… shift down. Where possible move the point of resolution towards self-service. How can we do this? With effective knowledge management tools and processes. And of course… content.

The HDI Support Center Practices & Salary report contains some interesting statistics about the costs of different forms of support.

  • Walk-up support costs an average of $20
  • Phone support costs $17
  • Email support costs $14
  • Peer support costs $7
  • Community support costs $2

The Peer support and Community support costs were predictions that we made rather than data from the HDI report.

You can clearly see that the model of shift left… shift down would lead to economic as well as customer satisfaction benefits. As an IT Manager you would want to move to a community support model based on a knowledge management strategy as the most economic way to scale your IT support operations.

Knowing that applying effective Knowledge Management to customer interactions such as incident and self-service, how do you get started?

Slicing up knowledge management

We looked at how customers are using knowledge today and how other products and tools are redefining the knowledge management landscape and defined this model.

We call it the “Avocado of Knowledge Management”


Engineered Knowledge

At the center of the model we have an activity called Engineered Knowledge. This will be familiar with anyone maintaining a knowledge base in their organisation today.

Characteristics of Engineered Knowledge practices are:

  • Structured content, normally in article format
  • Content is written by a small number of contributors, sometimes they are dedicated writers
  • Content has a formal approval and publishing workflow
  • Content is categorised and ordered

There are many examples to hand to demonstrate Engineered Knowledge. All big software vendors have a knowledge base containing many articles. You can imagine that these articles were written and reviewed by technical writers and had many rounds of reviews before being published.

Engineered Knowledge is an interesting case – it requires a formal process and good tooling to support the publishing and approval workflow. It also aims for completeness and accuracy.

Many customers that I have spoken to complained about the overhead involved in getting valuable content into their knowledge base.

Contributed Knowledge

Next in our graphical model we have an activity called Contributed Knowledge that surrounds Engineered Knowledge.

This activity is familiar to those of us that work in IT support today. Those that write contributed knowledge work amongst us on the service desk, network and database teams.

They are people who have a primary role but are able to contribute knowledge as a by-product of that work. For example as a network engineer figures out a gnarly configuration issue with his Cisco VPN router he can document it to help the next engineer that might find the same issue.

Contributed knowledge has a cheaper cost of production as it is created by non-dedicated authors. It also has a lower level of authority as the publishing process won’t have multiple levels of review and approval.

One theme throughout this model is the tradeoff between Cost, Authority and Immediacy of content. Although knowledge written by the network engineer might not have been triple-checked and re-edited for mistakes it did deliver value to its readers in a shorter amount of time.

We traded authority for immediacy.

Social Knowledge

Wrapping the layer of Engineered Knowledge we have a layer referred to as Social Knowledge.

This class of content is typically contributed by end-users, perhaps interacting with technical teams in a forum or Twitter style stream format.


With Social Knowledge our primary characteristic is Immediacy. Users and technical staff can have a real-time conversation, often in a public or quasi-public setting and generate knowledge.

In the case above you can see knowledge being traded about a service impacting event (the WiFi in building 3) or about common application questions.

There is a danger associated with trading the Authority of the content however. We don’t know whether Lee Javens is a peer user that found a solution or someone in the IT department. The tradeoff is apparent.

Why is it called the Avocado of Knowledge??

The idea of the avocado was to highlight the layered nature of the types of knowledge, especially regarding authority.

Engineering Knowledge is like the stone in the middle of the avocado – it’s formal process with review and approval makes it the firmest in terms of authority.

Contributed Knowledge has a lower level of authority. Although written by subject matter experts it won’t have the formal approval processes. Think about your wikis and HOWTO documents written by engineers in your organisation

Social Knowledge has the least authority. It isn’t easy to tell whether an answer is correct or approved. Answers from the peer community of users of a service are inter-mingled with those from technical experts.

A quick crib sheet of the Avocado of Knowledge


Social interactions cut through the Avocado

We mentioned Social Knowledge as a class of knowledge imagining Twitter-style streams of updates and conversations.

There is another dimension to Social that applies to all three classes described above. These are social interactions that are equally as applicable and useful in Engineered or Contributed Knowledge.

There are 6 types of social interactions that can be applied to knowledge

  • Consume: Read the content, digest it and move on
  • Interact: Hit the “Like” button, Thumbs up or +1 to lend your vote of confidence to an article. Perhaps this should increase the Authority of an article
  • Curate: Add categories, tags or other data to improve an article. Making it more useful for others that will read it in the future. Perhaps adding a comment to an article is a form of curation
  • Create: Create new content based on the original work or build on top of existing content
  • Network: Find authors and contributors, follow them and reshare content into that network. Both LinkedIn and Twitter are create examples of content sharing networks
  • Build Reputation: Give thanks for correct answers in the form of points, awards, coins or kudos

There are some very interesting possibilities when you look at how users can interact with knowledge content using these social signals.

For example, we would expect that Engineered Knowledge – formal articles that have been checked and approved – would have an expiry date. All Knowledge must die at some point.

What if an article starts to receive lots of negative interactions in the form of a thumbs down. Should that article suddenly be flagged for review because the instructions it provides no longer works for users?

We consider Social Knowledge to have the least Authority because we can’t validate the solution that is offered. Perhaps the person that documented a solution didn’t properly test it.

Well could we build reputation – another social signal – to measure the authority of the knowledge? When a person has gained reputation through high quality content can we promote their contributed knowledge as a possible correct answer.

Why aren’t organisations diving into Knowledge Management today

Earlier in this article I promised to share some insights from people working in Service Management today.

We asked them a question that directly related to the shift left, shift down model described earlier and if they would use knowledge to deflect incidents and servicedesk calls

The question was “Would it result in an economic change or a change in how the organization is staffed and managed? How would this change your relationship with your users?”

The answers were interesting:

“If knowledge is positioned correctly it can definitely impact the organization. You would need less help desk technicians and users would have less down time thus increasing their productivity. If IT can spend less time reacting to issues they can focus on being strategic partners to the business.”

“IF this successfully reduced volumes of calls into the IT Service Desk and incidents being raised by them as a result of the call volumes then I would image that future growth within the IT Service Desk would be discussed or possibly re-organised into a structure that would be more beneficial to this way of working, perhaps have a small team of “Knowledge Editors” that owned and created the various articles that were publicly available”

“It would free up more time for high impact incidents, improve quality and throughput.”

“I think relationships are created between humans, not between humans and machines. The relationship between the service desk and customer would be minimized, but this would allow resources to be focused in other value-add areas.”

I find it interesting that we gave servicedesk managers an opportunity to think about Knowledge Management as an opportunity to handle the same volume of end-users with a smaller number of staff due to knowledge being used to resolve issues.

Almost all of them saw an opportunity to use Knowledge Management to reclaim engineering capacity to solve harder issues, be more strategic and to spend more time providing value to their users.

Surely this is a good thing! Every good blog post ends with a call to action and here is mine.

What next? Your call to action

Today please examine your self-service and incident management processes and identify where effective use of Knowledge Management could improve resolution times and autonomy amongst your users.

If users had the right solution presented to them could they fix their own issues? Are you doing enough to get knowledge in front of users when they need it.

And if pressures of time and resource are preventing you from building a great knowledge base could the avocado of knowledge help you understand about trading authority for immediacy and cost?

Thanks for reading!

Getting started with social IT (Part 2 of 2)

Following on from Matthew Selheimer’s first installment on social IT, we are pleased to bring you the second and final part of his guide to getting started with social IT

Level 3 Maturity: Social Embedding

The saying, “Context is King!” has never been truer and this is the foundational characteristic for attaining Level 3 social IT maturity; Social Embedding.
This level of social IT maturity is achieved by establishing relevant context for social collaboration through three specific actions:

  1. The creation of a social object model
  2. The construction of a social knowledge management system that is both role-based and user-specific
  3. The enhancement of established IT processes with social collaboration functionality to improve process efficiency and effectiveness

The goal at Level 3 maturity is to leverage social embedding to improve IT key performance indicators (KPIs) such as mean-time-to-restore (MTTR) service or change success rate (additional examples are provided below). It is important that you select KPIs that are most meaningful to your organisation; KPIs that you have already baselined and can use to track progress as you increase your social IT maturity.

While the value of Level 2 maturity can be significant in improving the perception of IT’s responsiveness to users, Level 3 social IT maturity is where the big breakthroughs in IT efficiency and quantifiable business value are created.

Focus on key performance indicators

Focus on the KPIs associated with the processes you are enhancing with social collaboration. An incident management KPI measurement, for example, could be to multiply your current mean-time-to-restore (MTTR) service by your cost per hour of downtime or cost of degraded service per application. This will give you a starting point for benefit projections and value measurement over time.

Focus on the KPIs associated with the processes you are enhancing with social collaboration. This will give you a foundation for benefit projections and value measurement over time.

For change management, you might use the number of outages or service degradations caused by changes and multiply that by your cost per hour of downtime and MTTR to arrive at a true dollars and cents measure that you can use to benchmark social IT impact over time. You might also consider other IT process metrics such as first call resolution rate, percentage of time incidents correctly assigned, change success rates, the percentage of outages caused by changes, the reduced backlog of problems, etc.

The point is to select IT process metrics that are meaningful for your organization and enable you to calculate a quantifiable impact or benefit. Decision makers may be skeptical about the value of social IT, so you will need to make your case that there is real quantifiable benefit to justifying the investment to achieve Level 3 maturity.

Relevant Context and Three Required Actions

Let’s now more fully consider the establishment of relevant context and the three actions characteristic of Level 3 maturity previously described: 1) creation of a social object model, 2) construction of a social knowledge management system, and 3) the enhancement of IT processes with social capabilities. We noted earlier that context is defined in terms of relevance to a specific audience. That audience could be a group of individuals, a role, or even a single individual. The most important thing is that context ensures your audience cares about the information being communicated.

How do you go about ensuring the right context? What is needed is a social foundation that can handle a wide variety of different perspectives based on the roles in IT and their experience. The most effective way to do this is to treat everything managed by IT as a social object.page7image27920 page7image28080

What is meant by a social object? Consider, for example, a Wikipedia entry and how that is kept up-to-date and becomes more complete over time through crowd sourcing of knowledge on the subject. The entry is a page on the Wikipedia website. Now imagine if everything that IT is managing—whether it’s a router, a server, an application, a user, a policy, an incident, a change, etc.—was treated along the same lines as a Wikipedia page. Take that further to assume that all the relationships which existed between those entries—such as the fact that this database runs on this physical server and is used by this application—were also social objects that could be created, modified, and crowd-sourced. In this manner, organizational knowledge about each object and its relationships with other objects can be enriched over time—just like a Wikipedia entry.

FIGURE 2: A Social Object Model as delivered in ITinvolve for Service Management™. Leveraging social collaboration principles

Define a taxonomy for your social objects

Knowledge comes from multiple sources. Existing IT knowledge may be scattered in different places such as Excel spreadsheets, Visio diagrams, Sharepoint sites, Wikis, CMDBs, automated discovery tools, etc. but it also resides in the minds of everyone working in IT, and even among your end users. To effectively capture this knowledge, you will need to define a taxonomy for your social objects. You can then begin to source or federate existing knowledge and associate it with your objects in order to accelerate the creation of your social knowledge management system.

With an initial foundation of knowledge objects in place, your next task is to make the system easy to use and relevant to your IT teams by defining perspectives on the objects. Establishing perspectives is critical to a well- functioning social knowledge management system, otherwise, you will fall into pitfall #2 discussed earlier. For example, you might define a Network Engineer’s perspective that includes network devices and the relationships they have to other objects like servers and policies. You might define a Security Administrator’s perspective that focuses on the policies that are defined and the objects they govern like network devices and servers. Without this perspective-based view, your teams will not have the relevant context necessary to efficiently and effectively leverage the knowledge management system in support of their day-to-day roles.

Enrich your knowledge and keep it current

Once you have initially populated your social objects and defined perspectives, you need to keep knowledge current and enrich it over time to ensure your IT staff finds it valuable. This is why defining your objects as social objects is so critical. Just like you might follow someone on Twitter or “friend” someone on Facebook, your teams can do the same thing with your objects. In fact, when you created your perspectives, you were establishing the initial baseline of what objects your teams would follow. In this manner, whenever anyone updates an object or its relationships, those who are following it will automatically be notified along with a dedicated “news feed” or activity stream for the object.

When you create your perspectives, you establish the initial baseline of what objects your teams will follow. In this manner, whenever anyone updates an object or its relationships, those who are following it will automatically be notified along with a dedicated “news feed” or activity stream for the object.

This does two important things. First, it keeps those who “need to know” current on the knowledge about your environment so that everyone has up-to-date information whenever there is an incident, change, or other activity related to the object. Instead of waiting until a crisis occurs and teams are interacting with out-of-date information, wasting valuable time trying to get each other up to speed, you can start to work on the issue immediately with the right information in the right context.

Provide a point of engagement for subject matter experts

Second, it provides a point of engagement for subject matter experts to collaborate around the object when they see that others are making updates or changes to the object and its relationships. This second point should not be underestimated because it taps into a basic human instinct to engage on things that matter to them and directly contributes to the crowd-sourcing motivation and improvement of knowledge accuracy over time.

Your third action is to embed your social knowledge management system into your core IT processes in order to enhance them. This is not simply an add-on, as described in Level 2 social IT maturity, but rather it is deep embedding of the social knowledge management system into your processes as the most trusted source of information about your environment. For example, imagine creating an incident record or change record, initially associating it with one or more impacted social objects, and then being able to automatically and immediately notify relevant stakeholders who are following any of those objects and then engage them in triaging the incident or planning the change. This is the power of social collaboration and why it can deliver new levels of efficiency and value for your IT organization.page10image25552

Create new knowledge objects

As an incident or change is worked using social IT, collaboration in activity streams creates a permanent and ongoing record of information, which at any point can be promoted to become a new knowledge object associated with any other object. For example, let’s say that a change record was created for a network switch replacement. Each of the individuals responsible for the switch and related objects like the server rack is immediately brought into a collaboration process to provide input on the change and contribute their expertise prior to the change going to the Change Advisory Board (CAB) for formal approval.

FIGURE 4: In-context collaboration and promotion to knowledge as supported by ITinvolve for Service Management™

This is just one example of the power of in-context collaboration. The same principles apply to incidents, problems, releases and other IT management processes.

To exit Level 3 and start to move to Level 4 on the maturity scale, you need to be able to provide your IT staff with in-context collaboration that is grounded in a social object model, utilizes a social knowledge management system that is easy to maintain and provides an up-to-date view of your objects and relationships, and enhances your existing IT management processes. But more importantly, you need to be able to show the quantifiable impact on one or more KPIs that matter to your organization.

Level 4 Maturity: Social-Driven

The final stage of social IT maturity is Level 4, the Social-Driven IT organization. The goal at this level is to leverage social collaboration for Continual Service Improvement (CSI).

The value of Level 4 social IT maturity comes in two forms. First, as your organization becomes more adept at leveraging social collaboration, you should benchmark your IT process KPIs against that of other organizations. Industry groups such as itSMF, the Help Desk Institute (HDI), as well as leading industry analyst firms, provide data that you can use. Getting involved in peer-to-peer networking activities with other organizations via industry groups are a great way to assess how you are doing in comparison to others. At this stage, you should be striving to outperform any organization that is not leveraging social collaboration principles across your KPIs, and you should be performing at or above the level of those organizations that have adopted social collaboration principles.

Measure the size of your community

Second, you should measure value in terms of behavioral change in your organization. At maturity Level 4, you should have established a self-sustaining community that is actively leveraging the social knowledge management system as part of its day-to-day work. Measure the size of your community and set goals for increasing the community size. Metcalf’s law applies directly to social collaboration: The “network effect” increases the value of the social knowledge management system exponentially as you add users to the community.

Measure the size of your community and set goals for increasing the community size. Metcalf’s law applies directly to social collaboration: The “network effect” increases the value of the social knowledge management system exponentially as you add users to the community.

One way to foster a larger and more active community is through recognition and rewards. For example, you might choose to publicly recognize and provide spot bonuses for the top contributors who have added the most to the social knowledge management system. Or, you may reward service desk personnel who consult the social knowledge management system before assigning the incident to level 2 personnel. You might also choose to acknowledge your staff with “levels” of social IT expertise, classifying those who participate occasionally as “junior contributors”, those who participate regularly as “influencers”, and those who are most active as “experts” or “highly involved.”page12image22344 page12image22504

What’s Beyond Level 4 Social IT Maturity?

One of the most exciting things about being engaged in advancing your social IT maturity is that we are all, as an industry, learning about and exploring its potential. In the future, we are likely to see new product enhancements from vendors that employ gamification principles that encourage even greater growth of our social collaboration communities.

We may see the integration of information from biometric devices that help us to more quickly assess end user frustration and initiate collaboration to resolve issues prior to the user even contacting the service desk. There are certainly going to be even more use cases for social collaboration than we can imagine today.

Expanding Customer Service To Twitter

“Providing quick, engaging and valuable support to your customers on Twitter can build a positive brand image and reduce cost. Twitter takes less time, and money and offers your company the ability to resolve issues quickly and efficiently.”

Image originally posted on Zengage, The Zendesk Blog

Getting Started with Social IT (Part 1 of 2)

Today’s post from Matthew Selheimer of ITinvolve is part one of a two-part feature on Social IT maturity, part 2 will follow soon. 

"Most of your customers, employees and stakeholders are actively using social media"

Today, 98 percent of the online population in the USA uses social media sites, and worldwide nearly 6 out of every 10 people use social networks and forums.

From a business perspective, this means a very large percentage of your customers, employees and other stakeholders are already participating in the social media universe where smartphones, tablets, video communication and collaboration are a part of daily life. It almost goes without saying that, if you want to connect with new audiences and marketplaces today, there is no other platform that compares to social media in reach and frequency.

In fact, a recent McKinsey & Company report suggests that the growth businesses of tomorrow will be those that harness the power of social media and its potential benefits not only externally but internally as well:

Most importantly, we find that social technologies, when used within and across enterprises, have the potential to raise the productivity of the high-skill knowledge workers that are critical to the performance and growth in the 21st century by 20 to 25 percent.’

We are social by nature

How might IT departments take advantage of this social media potential? IT organizations are, in fact, quite social by nature. Knowledge and expertise reside in different teams, and specialists must frequently come together and collaborate to plan for changes and resolve issues. These social interactions, however, are typically ad hoc and take place across a wide variety of methods from in-person conversations and meetings, to email, to phone calls, to instant messaging, to wiki sites, and more.

How can IT build upon its existing social culture to deliver new value for the broader organization?

To be considered as more than just a ‘nice to have,’ social media must provide tangible benefits. The good news is that social media principles do provide real benefits when applied to IT – and they do so in a big way. For example, IT organizations that are using social media principles are finding that their staff can interact with users and each other in new and more immediate ways. They are also finding that they can much more easily capture and share the collective knowledge residing across their systems and teams; and then armed with this knowledge, they are able to better understand their IT environment and the complex relationships that exist among their IT assets.

Being social brings risks and rewards

This, in turn, is leading to increases in staff productivity and is making day-to-day tasks like resolving incidents and planning for changes more efficient and more accurate. The results include faster time to restore service when outages or degradations occur, a higher success rate when executing changes, and a greater overall throughput of IT process management activities – just to name a few.

But the adoption of social media principles in IT also has the risk of certain pitfalls. In this article, we will explore a four-level model of social IT maturity, (See Figure 1) including how to avoid the most common pitfalls.

  • At Level 1, organizations begin to explore how social IT can contribute by defining a milestone-based plan with clearly established benefits as their social IT maturity increases.
  • At Level 2, IT takes specific actions to add on social capabilities to existing operations, and begins to realize projected benefits around user intimacy and satisfaction.
  • At Level 3, social IT becomes embedded into and enhances IT operational processes, providing relevant context to improve collaboration among IT professionals thereby making IT teams more efficient and accurate in their daily work.
  • Finally, at Level 4, IT evolves into a socially driven organization with a self-sustaining community, recognition and rewards systems that further incentivize the expansion of the community, and a culture that harnesses the power of social collaboration for continuous process improvement.


Figure 1 - A Proposed Social IT Maturity Model

Level 1 Maturity: Social Exploration

The first level of social IT maturity is Social Exploration. The goal of Social Exploration is to learn, and the value delivered comes from defining your plan to improve social IT maturity.

Such a plan must include specific key performance measures that can be tied to financial or other tangible business benefits. Otherwise, your social IT plan is bound to be greeted skeptically by management.

Start by asking yourself simple questions like ‘How can social tools improve my ability to provide better IT service and support?’ and ‘What social IT capabilities are available in the market that I should know about and consider for my organization?’ If you’ve not started asking these types of questions, then you aren’t even on the social IT maturity scale yet. Exploring what social IT could mean for your IT organization is the critical first step.

To exit Level 1 and move to Level 2 on the maturity scale, you must have a documented plan for how you will improve your social IT maturity that incorporates specific key performance measures. The following sections will discuss a variety of elements and performance measures that you should consider.

Social IT Pitfall #1: Ungoverned Broadcasting

In your transition from Level 1 to Level 2 maturity, a common pitfall is to look for a ‘quick win’ such as broadcasting via Twitter or RSS. A number of IT management software vendors include this capability in their products today, so it seems like an easy way to ‘go social.’ However, if you haven’t taken the time to define your communications policies clearly, you could end up doing more harm than good. Posting IT service status to public feeds could leave your organization exposed or embarrassed. You wouldn’t want to see ‘My Company finance application unavailable due to network outage’ re-tweeted and publicly searchable on Google, would you?

You can do more harm than good if you try for a ‘quick win’ approach to social IT by broadcasting via Twitter or RSS. Posting IT service status to public feeds could leave your organization exposed or embarrassed.

Level 2 Maturity: Social Add-ons

The most important thing about getting to Level 2 maturity, Social Add-ons, is that you are now taking specific actions to leverage social capabilities as part of your overall IT management approach.

While some organizations may choose to move directly to Level 3 maturity, because of its greater value, a common next step in increasing social IT maturity is the adoption of one or more social capabilities as add-ons to your existing IT processes. The goals at this stage are typically to leverage social capabilities to improve communications with users and, to a lesser extent, within IT.

The value of Level 2 social IT maturity is defined in terms of metrics such as user satisfaction, the percentage of incidents or requests that have been acted upon within their prescribed SLAs, and the creation of formal social IT communications policies that clarify what should be communicated to whom and when.

A logical place to start is to evaluate the social add-on capabilities of your current IT management software. You may find that your current vendor offers some type of 1:1 chat (instant messaging, video-based, virtual chat agents, etc.), often with the ability to save or record that chat. You may also find support for news feeds and notifications (e.g. Twitter, RSS, Salesforce.com’s Chatter, Yammer, or Facebook integration). You might also consider using these approaches on a standalone basis outside of your current IT management software if your current provider does not offer these capabilities.

Define your communication policies

Remember the first social IT pitfall of broadcasting, though. Before you start communicating, you must define your formal communications policies. Most likely, you already have a policy that pertains to email or Intranet communications to users and employees. If you do, that’ll give you a head start to work from. In any case, here are a few good rules of thumb to follow:

  1. Only communicate externally what you are comfortable with the entire world knowing about. In most cases you will find there are very few things, if any, which fit into this category. For example, you might push out a tweet to a specific user’s twitter account that their incident has now been closed, but without any details about the nature of the incident.
  2. If you do want to communicate using social tools externally in a broader way, consider using private groups that are secure. For example Twitter, Chatter, and Facebook all support private groups, although there is administrative overhead for both users and IT departments to request to join them and to manage members over time.
  3. Make sure what you communicate is focused on a specific audience.Don’t broadcast status updates on every IT service to everyone. If you create too much noise, people will just tune out your communications defeating their entire purpose.

To exit Level 2 and start to move to Level 3 on the maturity scale, you need to shift both your thinking and your plans from social add-ons to how social capabilities can be embedded into the work IT does every day. This means expanding your social scope beyond IT and end user interactions, and working to improve collaboration within IT.

Social IT Pitfall #2: Feeds, Walls, and Noise – Oh My!

One critical success factor for social IT communications is to ensure you are targeting specific audiences. Some vendors offer a Facebook-like wall in addition to the ability to push updates out via Twitter or RSS. In addition to the exposure risk previously discussed, these approaches can also create a tremendous amount of noise, which will make it difficult for both business users and IT to identify useful information in the feed or on the wall.

Relying on a solitary Facebook-like wall for social IT, as well as pushing updates out via Twitter or RSS, can create a tremendous amount of noise, making it difficult for both business users and IT to identify useful information in the feed or on the wall.

There is a simple analogy to illustrate this point. Imagine you are invited to a dinner party and arrive as one of twenty guests. As you enter, you hear many conversations taking place at once, music playing, clinking of glasses behind the bar, the smell of food cooking. What’s the first thing you do? If you’re like most people, you look around the room to find someone else you know, someone who appears interesting, or maybe you head toward the bar or the kitchen. What you’ve just done is to establish context for the party you’re attending. A single IT news feed or wall doesn’t provide useful context. It’s like listening to random sentences from each of the conversations at the party and contains a lot of noise that a business or IT user just doesn’t care about.

While news feeds and walls typically have a keyword search capability, both users and IT users will end up spending too much time trying to locate relevant information. As a result, they will likely over time start avoiding going to the feed or wall because it contains far too much information they don’t care about. What’s more, the feed can grow so long that it needs to be truncated periodically causing useful information that was posted a long time ago to become lost to the organization.

Stay away from one-size fits all walls or feeds. They’re not useful and will hurt the credibility of your social IT project.

This is part one of a two-part feature on Social IT maturity, part 2 will follow soon.

A structured approach to problem solving

Those who have worked in IT Operations have a strong affinity with the skills of problem solving and troubleshooting. Although a huge amount of effort is taken to improve resiliency and redundancy of IT systems the ability to quickly diagnose the root cause of problems has never been more important and relevant.

IT Service Management has gone a long way towards making practices standardised and repeatable. For example you don’t want individual creative input when executing standard changes or fulfilling requests. Standard Operating Procedures and process manuals means that we expect our engineers and practioners to behave in predictable ways. Those reluctant to participate in these newly implemented processes might even complain all the fun has gone out of IT support.

A Home for Creative and Inquiring Minds?

However there is still a place for creative and inquiring minds in ITSM driven organisations. Complex systems are adept at finding new and interesting ways to break and stop functioning. Problem analysis still needs some creative input.

When I recruited infrastructure engineers into my team I was always keen to find good problem solvers. I’d find that some people were more naturally inclined to troubleshooting than others.

Some people would absolutely relish the pursuit of the cause of a difficult network or storage issue… thinking of possible causes, testing theories, hitting dead ends and starting again. They tackled problems with the mindset of a stereotypical criminal detective… finding clues, getting closer to the murder weapon, pulling network cables, tailing through the system log.

These kinds of engineers would rather puzzle over the debug output from their core switch than get stuck into the daily crossword. I’m sure if my HR manager let me medically examine these engineers I’d find that the underlying psychological brain activity and feeling of satisfaction would be very similar to crossword puzzlers and sudoku players. I was paying these guys to do the equivalent of the Guardian crossword 5 days a week.

Others would shy away from troubleshooting sticky problems. They didn’t like the uncertainty of being responsible for fixing a situation they knew little about. Or making decisions based on the loosest of facts.

They felt comfortable in executing routine tasks but lacked the capability to logically think through sets of symptoms and errors and work towards the root cause.

The problem I never solved

Working in a previous organisation I remember a particularly tricky problem. Apple computers running Microsoft PowerPoint would find that on a regular basis their open presentation would lock and stop them saving. Users would have to save a new version and rename the file back to its original name.

It was a typical niggling problem that rumbled on for ages. We investigated different symptoms, spent a huge amount of time running tests and debugging network traces. We rebuilt computers, tried moving data to different storage devices and found the root cause elusive. We even moved affected users between floors to rule out network switch problems.

We dedicated very talented people to resolving the problem and made endless promises of progress to our customers. All of which proved false as we remained unable to find the root cause of the problem.

Our credibility ran thin with that customer and we were alarmed to discover that our previous good record of creatively solving problems in our infrastructure was under threat.

What’s wrong with creative troubleshooting?

The best troubleshooters in your organisation share some common traits.

  • They troubleshoot based on their own experiences
  • They (probably) aren’t able to always rationalise the root cause before attempting to fix it

Making assumptions based on your experiences is a natural thing to do – of course as you learn skills and go through cycles of problem solving you are able to apply your learnings to new situations. This isn’t a negative trait at all.

However it does mean that engineers approach new problems with a potentially limited set of skills and experiences. To network engineers all problems look like a potentially loose cable.

Not being able to rationalise the root cause is a balance between intuition, backed up by evidence and research. Your troubleshooter will work towards the root cause and sometimes have hard evidence to confirm the cause.

“I can see this in the log… this is definitely the cause!”

But in some cases the cause might be suspected, but you aren’t able to prove anything until the fix is deployed.

Wrong decisions can be costly

Attempting the wrong fix is expensive in many ways, not least financially. It’s expensive in terms of time, user patience and most critically the credibility of IT to fix problems quickly.

Expert troubleshooters are able to provide rational evidence that confirm their root cause before a fix is attempted.

A framework is needed

As with a lot of other activities in IT a process or framework can aid troubleshooters to identify the root cause of problems quickly. In addition to providing quick isolation of the root cause, the framework I’m going to discuss can provide evidence as to why we are suggesting this as the root cause.

Using a common framework has other benefits. For example:

  1. To allow collaboration between teams – Complex infrastructure problems can span multiple functional areas. You would expect to find subject matter experts from across the IT organisation working together to resolve problems. Using a common framework in your organisation allows teams to collaborate on problems in a repeatable way. Should the network team have a different methodology for troubleshooting than the application support team?
  2. To bring additional resources into a situation – Often ownership of Problems will be handed between teams in functional or hierarchical escalation. External resources may be brought in to assist with the problem. Having a common framework allows individuals to quickly get an appraisal of the situation and understand the progress that has already been made.
  3. To provide a common language for problem solvers – Structured problem analysis techniques have their own terminology. Having shared understanding of “Problem Area”, “Root cause” and “Probable cause” will prevent mis-understandings and confusion during critical moments

The Kepner Tregoe Problem Analysis process

Kepner-Tregoe is a global management consultancy firm specialising in improving the efficiency of their clients.

The founders, Chuck Kepner and Ben Tregoe, were social scientists living in California in the 1950’s. Chuck and Ben studied the methods of problem solvers and managers and consolidated their research into process definitions.

Their history is an interesting one and a biography of the organisation is outside the scope of this blog post – but definitely worth researching.

One of the processes developed, curated and owned by Kepner-Tregoe, is Structured Problem Analysis, known as KT-PA.

KT-PA is used by hundreds of organisations to isolate problems and discover the root cause. It’s a framework used by problem solvers and troubleshooters to resolve issues and provide rational evidence that the investigation has discovered the correct cause.

Quick overview of the process

1. State the Problem

KT-PA begins with a clear definition of the Problem. A common mistake in problem analysis is a poor description of the problem, often leading to resources dedicated to researching symptoms of the problem rather than the issue itself.

Having a clear and accurate Problem Statement is critical to finding the root cause quickly. KT-PA provides guidance on identifying the correct object and it’s deviation.

A typical Problem Statement might be

Users of MyAccountingApplication are experiencing up to 2 second delays entering ledger information

This problem statement is explicit about the object (“Users of MyAccountingApplication”) and the deviation from normal service (“2 second delays entering ledger information”)

2. Specify the Problem

The process then defines how to specify the problem into Problem Areas. A Problem is specified in 4 dimensions and all should be considered. What, Where, When, Extent:

  1. What object has the deviation
  2. What is the deviation
  3. Where is the deviation on the object
  4. When did the deviation occur
  5. Extent of the deviation (How many deviations are occurring, What is the size of one deviation, Are the number of deviations increasing or decreasing)

The problem owner inspects the issue from these dimensions and documents his results. Results are recorded in the format of IS and IS NOT. Using the IS/IS NOT logical comparison starts to build a profile of the problem. Even at this early stage certain causes might become more apparent or less likely.

Already troubleshooters will be getting benefit from the process. The fact that the 2 second delay in the problem dimension of Where “IS Users in London” but “IS NOT Users in New York” is hugely relevant.

The fact that the delay occurs in entering ledger information but not reading ledger information is also going to help subject matter experts think about possible causes.

3. Distinctions and Changes

Having specified the problem and made logical comparisons as to where the problem IS and IS NOT each problem area the next step is to examine Distinctions and Changes.

Each answer to a specifying question is examined for Distinctions and Changes.

  • What is distinct about users in London when compared to users in New York. What is different about their network, connectivity, workstation build?
  • What has changed for users in London?
  • What is distinct about August 2012 when compared to July?
  • What changed around the 30th July?

As these questions are asked and discussed possible root causes should become apparent. These are logged for testing in the next step.

4. Testing the cause

The stage of testing the cause before confirmation is, for me, the most valuable step in the KT-PA process. It isn’t particularly hard to think of possible root causes to a problem. Thinking back to the “problem I never solved” we had many opinions on what the cause might be from different technical experts.

If we had used KT-PA with that problem we could have tested the cause against the problem specification to see how probable it is.

As an example lets imagine that during the Distinctions and Changes stage with our problem above 3 possible root causes were suggested

  • LAN connection issue with the switch the application server is connected to
  • The new anti-virus installation installed across the company in August is causing issues
  • Internet bandwidth in the London office is saturated

When each possible root cause is evaluated against the problem specification you are able to test it using the following question

“If LAN connection issue with the switch the application server is connected to is the true cause of the problem then how does it explain why Users in London experience the issue. Users in New York do not”

This possible root cause doesn’t sound like a winner. If there were network connectivity issues with the server wouldn’t all users be affected?

“If The new anti-virus installation installed across the company in August is causing issues is the true cause of the problem then how does it explain why Users in London experience the issue. Users in New York do not”

We came to this root cause because of a distinction and change in the WHEN problem dimension. In August a new version of anti-virus was deployed across the company? But this isn’t a probable root cause for the same reason that New York users aren’t affected

If Internet bandwidth in the London office is saturated is the true cause of the problem then how does it explain why Users in London experience the issue. Users in New York do not”

So far this possible root cause sounds most probable. The cause can explain the dimension of WHERE. Does it also prove other dimensions of the problem.

“If Internet bandwidth in the London office is saturated is the true cause of the problem then how does it explain why First noticed in August 2012, not reported before 30th July”

Perhaps now we’d be researching Internet monitoring charts to see if the possible root cause can be confirmed.

The New Rational Manager

You might find my recommendation of a book published in 1965 as one of the most relevant Problem Management books I’ve read to be incredulous.

But I’m recommending it anyway.

The New Rational Manager

The New Rational Manager, written by Charles H Kepner and Benjamin B Tregoe is a must read for anyone that needs to solve problems, be they manufacturing, industrial, business or Information Technology.

It explains the process above in a readable way with great examples. I think the word “Computer” is mentioned once – this is not a book about modern technology – but it teaches the reader a process that can be applied to complex IT problems

In Summary

Problem Management and troubleshooting is a critical skill in ITSM and Infrastructure and Operations roles. Many talented troubleshooters make their reputation by applying creative, technical knowledge to a problem and finding the root cause.

Your challenge is harnessing that creativity into a process to make their success repeatable in your organisation and to reduce the risk of fixing the wrong root cause.

Sudoku Image Credit

Gazing deep into the prISM

prISM: 'Dark side of ITSM?' or genuine professional recognition?

At first glance, the new prISM credential scheme seems to be a qualification too far, as I consider improving my ITSM skills by going for the first of my ITIL Intermediate levels.

The take up so far seems to belong to an select group, much like those who piloted the new ITIL Master scheme, and perhaps it is too early for that all important critical mass to make it the “must-have” credential to have.

What is prISM and why is it different?

The aim of prISM is to provide recognition and a skills development structure in the ITSM industry.

It has defined a measurable framework which takes into account an individual’s qualifications, experience and contributions back to the ITSM industry.

So, if you have the ITIL foundation certificate, and a few years in front line roles under your belt, you can get up and running in prISM as an Associate, and use their structured approach to plan your next steps up the ITSM ladder.

But, you pay for the privilege, so why is this worth investing time in?

Industry maturity

Matthew Burrows, Lead for Global priSM Advisory Committee (GAC) explained:

“The real reason for prSIM is that the IT industry is starting to mature and become a bit more of a profession rather than a job.”

Just take a look sometime, in various ITIL and ITSM related Linked In groups, and you will see pleas from people who seem out of their depth.

Think of it in this way.  How many times do organisations send people onto an ITIL Foundation course, and then expect them to be able to implement major ITSM projects?

Matthew continued:

“Nothing ever works like that with a skill.  You have to practice it and apply it.  You have to learn from the mistakes from yourself and others. You have to learn from your successes as well and you refine it over time, and you get better at it by repetition.”

Part of the issue is the lack of a requirement to refresh ITIL qualifications, once gained.

In prISM, each year you submit a Continual Professional Development forms to demonstrate growth and development in order to re-earn your credential.

prISM Credential Levels

  1. Student in Service Management (SSM) – students with an interest in ITSM
  2. Associate (ASM) – entry level professionals
  3. Professional (PSM) – experienced Service Management professionals
  4. Distinguished Professional (DPSM) – senior, well experienced Service Management professionals and leaders
  5. Fellow (FSM) – reserved for those senior professionals who have been recognised for making a significant contribution to the profession and its body of knowledge


I see the benefit of tiering the levels like this, and even though my “rock face” experience gives me a broader perspective than if I had only the ITIL Foundation course, this is where the CPD aspect comes in.

The whole point of the profession maturing means that I need to really focus on further certification, but given the cost of courses, I really need to think carefully as to what to pursue.


I have worked in the area of ITIL/ITSM for 8 years now – I know my stuff. Do I really need to pay for more certification AND a credential to prove it?

Matthew believes that prISM should be a nice to have, rather than a mandatory requirement:

“From an employer’s point-of-view it tells me that they’ve been through the experience and qualifications that they say they’ve got, they’re committed to CPD, they give something back, they take their profession seriously.”

In my opinion, this is hard to prove in the immediate short term, without understanding from recruiters if they put any store in the acronyms above.

The Application Process

1)     Calculator

  • Step One: Education and Experience

The spreadsheet gives you a broad brush stab at the permutations of education and experience.

I tested a couple of elements and opted years of experience, as my degree was a LONG time ago! Recommended Level: PSM

  • Step Two: Required Professional Certifications

Here’s where it started to get confusing.

With an ITIL V3 Foundation Certificate (useful) and a TOGAF Enterprise Architecture L1 and L2 certificate (not at all useful, apparently), recommended level: ASM!

  • Step three: Extra Points

I played about with this out of interest, in terms of ITSM implementation experience, and also in terms of ITSM Review writing – which confused matters even more, because now the summary shows me that I meet DPSM criteria as well!

With the combination of the experience and qualification  I could apply now for Associate Membership but with at least one ITIL Intermediate course, I go up to Professional credentials.

Irritatingly, the comment boxes for the Certification sections stays visible after you have marked an entry, which then obscures the entries below.

2)      Application Form & CV

You also have to fill in the application form and sign the statement to adhere to the profession’s code of ethics, and you will need to cross-reference the handbook as you go for Professional credentials which sounds like a bit of hassle.

There is a bit of repetition here, having to put in the details of your referee, as well as including your reference (with those same details) as part of the package.

You also have to write your own personal statement, demonstrating your interest in the ITSM profession.

If you are serious about going through this process, I think it is worth updating your CV during this process.  It won’t hurt you to pay some attention to your Linked In profile either.

After all, if recruiters are using Linked In more and more, the best way to promote the importance and credibility of this credential is to have it on your online profile.

3)      Reference Statement & Evidence

You will have to get someone to write a supporting statement for you, and also find your supporting evidence to match your calculator entries.

Some issues

  • You need to keep PDFs at 1MB per document, and the whole application cannot be more than 25MB.  Irritatingly my scanned ITIL certificate and itSMF UK invoice are just over 1MB, but everything else is smaller.
  • The pricing is misleading.  The handbook states itSMF membership is preferable (and gives a discount) but not mandatory.  The application form infers the opposite – so those need to be in sync.
  • The handbook encourages you to pay before gathering your references – I would actually get everything together first, then proceed to pay for your appropriate membership, as you then need the proof of payment to zip together to submit.

Ros’s Progress

Matthew very kindly agreed to be my reference, and we decided to let me go through the process (and provide feedback!). so I have sent him a form to fill in and return to me.

I’ll put my (eventual) credential on my LinkedIn Profile, and push out an updated CV to see if there is any immediate change in the type of roles I typically see.

Will it be the prISM credential, or the ITIL Intermediate certification that provides the trigger (if at all!).

Watch this space.

Further Information


Skills Framework for the Information Age (SFIA) Quick Guide

I know, it actually sounds like something they used to show early in the morning when I was growing up as part of an adult learning initiative, long before children’s television schedules took off.

The first I heard of it was at the itSMF Regional Seminar in Staines, as part of the “speed-dating” networking sessions, as Matthew Burrows had just finished writing the pocket book.

Before chatting to him further on the subject, I took a browse through the website, where I spent a while trying to understand just what it actually means.

SFIA in a nutshell

The idea is to give employers a common terminology framework around a set of generic business skills, and seven defined areas of responsibility, starting with entry level (Level 1) and taking you up to Level 7 where you would expect someone to be defining strategy and mobilising organisations to achieve business goals.


Set strategy, Inspire, Mobilise













This approach makes it quite straightforward to understand, as most people can typically follow the concept of an experience curve.

Some surprises

The biggest surprise for me was that this framework has been around for a long time.

Matthew explained:

“I started using it nearly 11 years ago for an organisation redesign project.

“I discovered SFIA, rather than invent something new, and found it really useful.”

He sees himself as a practitioner (indeed, he is one of the SFIA Accredited Consultants) and has been using it ever since.

Going through the material, I began to recognise skill profiles that I used to have to annually update in one of my previous companies, who have representatives on the SFIA Council and have chosen to adapt and adopt the framework.

Access to the materials

As with many things, there are no two ways about it, you have to register, but it is free to do so.

Once you register you are taken immediately to all the materials, without having to wait for a confirmation email.

  • A3 Size Summary Chart
  • Complete Reference Guide
  • Working With SFIA Guide
  • PDF detailing the changes between V4/4G and V5 (latest)
  • Skills Reminder Card
  • Skills in a spreadsheet form

The skills and descriptions in the Reference Guide are the most valuable resource – the generic description of the skills, and the specific descriptions for the various levels.

How it helps professionals & organisations

  • Recruitment/CV Development

Recruiters these days find the few, rather than attract the many, and you might be more likely to see jobs advertised that use the same language.

Matthew said:

“I saw one [job] the other day which mentioned the specific skill and specific level, right in the headline of the job.

“The more recruitment consultants use SFIA, the more intelligent their matching becomes because if they can educate their customer (who is specifying the role), or if the customer is already aware of SFIA, they can list a couple of core skills”

Using the specific descriptions, matched with the skill level in CVs could help professionals become one of the few.

  • Continual Professional Development & Mentoring

The progression through the levels of responsibility can be charted within disciplines (for example Project Management – starting with leading a single project and progressing to managing a number of projects, or managing project managers.

Training companies have started using SFIA to describe their training offerings, showing where the course is designed to provide which skill and which level.

Mentoring works in exactly in the same way – if you want to get to a certain level, use the SFIA framework to find a mentor with a skill at a particular level.

  • Organisational Skills Planning and (Re)Design

From a company point of view, they can baseline their current skills, and forecast what skills are going to be required, and do a gap analysis between the two, using that to define training and recruitment plans.

It can help in providing informed decisions around restricting and reorganisation.  If a couple is looking to outsource some activity, then assessing those skill needs and gaps can help.


SFIA only provides you with definitions of professional skills.

It does not describe behavioural skills or specific technical knowledge.

Think of it as helping you put the self-promotional phrases that are all important in CVs and at appraisal time, backed up with specific technical qualifications and those all important softer skills that make someone a rounded professional.

Matthew warned against putting too much faith in the categories and subcategories:

“The categories and sub-categories are just convenient labels.  Don’t read too much into them.

“Service Management doesn’t include all the skills associates with Service Management, so if you were defining a process ownership role, you would find they would have some of the skills in the Service Management category, and some of the skills in the Strategy and Architecture category, so I find the skill names are really useful.”

Who makes it happen and where to find out more

The SFIA Foundation is a non-profit organisation.

There are five Foundation members who fund the Foundation, produce the material and make it available for people:

  • itSMF UK (The IT Service Management Forum)
  • IET (The Institute of Engineering and Technology)
  • e-skills UK (Sector Skills Council for Business and Information Technology)
  • IMIS (The Institute for the Management of Information Systems)
  • BCS (The Chartered Institute for IT)

Each of these organisations has a member on the SFIA Board, and in addition there is an SFIA council with other members from companies and corporations who use SFIA.

Funding comes in from the Foundation members, and from Accredited SFIA Consultants who pay a percentage of their fee to the central pot.

To register for SFIA materials, and to find out more, visit the SFIA Website.

Rob England: What is a Technical Service Catalogue?

Amtrak 14th Street Coach Yard (Chicago, IL, US): A railway provides other functions: track gangs who maintain the trackwork, dispatchers who control the movement of trains, yard crews who shuffle and shift rolling stock. It is clear that these are not services provided by the railway to its customers. They are internal functions.

We are looking at railways (railroads) as a useful case study for talking about service management.

Last time we looked at the service catalogue of a railway.

We concluded that first and foremost, a service catalogue describes what a service provider does.

How often and what flavour are only options to a service or package of services.

ITIL refers to a technical service catalogue (TSC).  Where does that fit?

One thing everyone agrees on is the audience: a TSC is for the internal staff of the service provider, to provide them with supplementary information about services – technical information – that the customers and users don’t need to see.

But the scope of a TSC – what services go into it – is a source of much debate, which can be crudely categorised into two camps:

  1. TSC is a technical view of the service catalogue
  2. TSC is a catalogue of technical services

Those are two very different things.  Let me declare my position up front: I believe the answer is #1, a technical view of the service catalogue.  ITIL V3 was ambiguous but ITIL 2011 comes down clearly with #2.  This is unfortunate, as we’ll discuss.

Go back to what a service catalogue is: a description of what a service provider provides to their customers (and hence their users).  A good way of thinking of a service in this context is as something that crosses a boundary: we treat the service provider as a black box, and the services are what come out of that box.  A service catalogue is associated with a certain entity, and it describes the services that cross the boundary of that entity.  If they don’t come out, they aren’t a service, for that entity, depending on where we chose to draw the boundary.  To define what the services are, first define the boundary of the service provider.

Think of our railroad example from last time.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Livestock transport
  • Passenger transport
  • etc etc

A railway provides other functions:

  • track gangs who maintain the trackwork
  • dispatchers who control the movement of trains
  • yard crews who shuffle and shift rolling stock within the yard limits
  • hostlers who prepare and park locomotives

It is clear that these are not services provided by the railway to its customers.  They are internal functions.

A railway provides track, rolling stock, tickets and stations, but these aren’t services either: they are equipment to support and enable the services.

A passenger railway provides

  • on train security
  • ticket collectors
  • porters
  • dining car attendants
  • passenger car cleaners

and a freight railway provides

  • container loading
  • consignment tracking
  • customs clearance
  • waybill paperwork

These all touch the user or customer, so are these services?  Not unless the customer pays for them separately as services or options to services.  In general these systems are just components of a service which the customer or user happens to be able to see.

So why then do some IT people insist that a technical service catalogue should list such “services” as networks, security or AV? (ITIL calls these “supporting services”). If the networks team wants to have their own catalogue of the services that only they provide, then they are drawing their own boundary around just their function, in which case it is not part of a technical service catalogue for all of IT, it is a service catalogue specifically for the networking team.  It is not a service provided by IT to the customer.

A technical service catalogue should be a technical view of the same set of services as any other type of service catalogue for the particular entity in question.   The difference is that it provides an internal technical view of the services, with additional information useful to technical staff when providing or supporting the services.  It includes information a customer or user doesn’t want or need to see.

A technical service catalogue for a railway would indeed refer to tickets and porters and stations and yard procedures and waybills, but only as components of the services provided – referred to within the information about those services – not listed as services in their own right.  I’m all for “supporting services” to be described within a service catalogue, but not as services.  They are part of the information about a service.  Supporting services aren’t services: they are component systems – CIs – underpinning the real services we deliver to our customers.

By adopting the concept of “supporting services” and allowing these to be called services within the catalogue of a wider entity that does not provide these services to a customer, ITIL 2011 contradicts its own description of “service”.

Service Design says:

Supporting services IT services that support or ‘underpin’ the customer-facing services.  These are typically invisible to the customer… such as infrastructure services, network services, application services or technical services.

Yet the in the prior section, such IT systems are clearly not a service:

IT staff often confuse a ‘service’ as perceived by the customer with an IT system.  In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…  A good starting point is often to ask customers what IT services they use and how those services map onto and support their business processes

And of course it contradicts the generic ITIL definition of a service as something that delivers value to customers.  This is important because the concept of “supporting service” allows internal units within the service provider to limit their care and concern to focus on the “supporting service” they provide and allows them to become detached from the actual services provided to the customer.  There is no SLA applicable to “their” service, and it quite likely isn’t considered by service level reporting.

A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”.  A yard hostler should make sure he doesn’t obstruct the expeditious handling of rolling stick when moving locomotives, even though rolling stock isn’t part of “his” service.  The idea of “supporting service” allows and encourages an “I’m alright Jack” mentality which goes against everything we are trying to achieve with service management.

It is possible that Lou Hunnebeck and the team writing Service Design agree with me: that they intend there to be a distinction between supporting services and IT systems.  If so, that distinction is opaque.   And they should have thought more about how the “internal” services model would be misused- the problem I’m describing was common before ITIL 2011.

There is the case where the supporting services really are services: provided to us by a third party in support of our services to our customer.  For example, a railway often pays another company:

  • to clean the carriages out
  • to provide food for the bistro car;
  • to repair rolling stock
  • to provide the trucking over “the last mile”

Where we bundle these activities as part of our service to a customer and treat them as an Underpinning Contract, then from the perspective of the services in our service catalogue – i.e from the perspective of our customer – these are not services: they are CIs that should not be catalogued here.  If this – and only this scenario – is what Service Design means by a “supporting service”, I can’t see that called out explicitly anywhere.

Technical service catalogue should be a technical view of the services that we provide to our customers.  I wish ITIL had stuck to that clear simple model of a catalogue and kept IT focused on what we are there for.

Photo Credit

Rob England: What is a Service Catalogue?

"The menu analogies we see all the time when talking about service catalogue are misleading. "
"The menu analogies we see all the time when talking about service catalogue are misleading. "

We are looking at railways (railroads) as a useful case study for talking about service management.

What is the service catalogue of a railway?

If you said the timetable then I beg to differ.  If you said one-trip, return and monthly tickets I don’t agree either.

The menu analogies we see all the time when talking about service catalogue are misleading.

A menu (or timetable) represents the retail consumer case: where the customer and the user are one.  In many scenarios we deal with in business, the one paying is not the one consuming.

The service catalogue describes what the customer can buy.  The request catalogue is what the user can request.  Consider a railroad cook-wagon feeding a track crew out in the wilds: the cook decides with the railroad what to serve; the staff get a choice of two dishes.

The cook’s services are:

  • Buying and delivering and storing ingredients
  • Mobile cooking and eating facilities
  • Cooking food
  • Serving food onsite

That is the service catalogue.  The railway can choose to buy some or all of those services from the caterer, or to go elsewhere for some of them.

The menu is a service package option to the “cooking food” service.  The railroad chooses the options based on cost and staff morale.  The menu gives staff the illusion of choice.

First and foremost, a service catalogue describes what a service provider does. How often and what flavour are only options to a service or package of services.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Dangerous goods transport (the ethanol delusion generates huge revenues for US railroads)
  • Large loads transport (anything oversize or super heavy: huge vehicles, transformers, tanks…)
  • Livestock transport
  • Rolling-stock transport (railways get paid to deliver empty wagons back their owners)
  • Finance (a railway can provide credit services to customers)
  • Ancillary freight services: customs clearance, shipping, security…
  • Passenger transport
  • Luggage
  • Lost luggage
  • Bicycles
  • Pet transport
  • Food and drink services (onboard and in stations)
  • Accommodation (big Indian stations all have dormitories and rooms)
  • Tours and entertainment (party trips, scenic trips, winery trips…)
  • Land cruises (just like a cruise ship but on rails)
  • Travel agency
  • Bulk goods storage (railroads charge companies to hold bulk materials in wagons for them awaiting demand: they provide a buffering service)
  • Rolling stock storage (in the USA railroads make money storing surplus freight wagons for other railroads)
  • Rolling stock repair (railways repair private equipment for the owners)
  • Private carriage transport (in many countries you can own your own railroad carriage and have the railway carry you around; a fantasy of mine)
  • Property rental (many large railways are significant landlords)
  • Land sales

Where’s the timetable or ticket pricing now?  It has such a small part in the true scope of a railway’s services as to be trivial.  More to the point, it is not a service: tickets are request options associated with one of many services.  Users don’t request a service: “I’d like an email please”. No, they make a request for an option associated with a service: provision email, increase mailbox, delete account, retrieve deleted email etc…

People confuse their personal consumer experience with business: they try to apply consumer experience models to business processing.  Most customers don’t want a service catalogue “to look like Amazon”.  They want meaningful business information.  The best vehicle for that is usually a text document.  The users/consumers of a service(s) may want to see the requests associated with that service(s) in an Amazon-like interface.  Sometimes there may even be a valid business case for building them a groovy automated request catalogue, but it is not the service catalogue.

The service catalogue defines what we do.  It is not simply an ordering mechanism for customers.  That is that personal/business thing again.  A service catalogue has multiple functions.

  1. Yes it is a brochure for customers to choose from.
  2. It also provides a structure to frame what we do as a service provider: availability planning, incident reporting, server grouping… Once we have a catalogue we find ourselves bring it up in diverse contexts: “we see the list of services show up in the table of contents”.
  3. It is a reference to compare against when debating a decision
  4. It is a benchmark to compare against when reporting (especially the service levels, but not only the service levels)
  5. It becomes a touchstone, a rallying point, an icon, a banner to follow.  It brings people back to why we are here and what we are for as an organisation.

You don’t get that from Amazon.

Then we come to that endless source of confusion and debate: technical service catalogue.  That deserves a whole discussion of its own, so we will look at it next…