The ITSM Review Supplier Directory

Building a worldwide view of ITSM technology, services and expertise

We have just launched a new Supplier Directory.


Our aim is to build the ultimate directory of worldwide business partners who provide ITSM related expertise or technology.

The directory is for ANY company that offers TECHNOLOGY, SERVICES, TRAINING, CONSULTING or any other expertise to this industry.


  • EQUALITY – From one-man-band consultants to the largest software companies in the world – everyone can list.
  • FREE – This is a free service. Free to list your company, free to browse.
  • SELF-SERVICE -The new partner directory is driven by tags and descriptions, which you can change yourself at any time as you see fit.

If you are a consultant, reseller, partner, service provider, tool vendor or have any other expertise or service to share – please take a minute to list your company.


Any questions – please shout. Thanks, Martin

Photo credit

Practitioners versus consultants: what benefits do both roles offer?

Duran Duran
ITSM practitioners may not get to be seen as “rock-star saviors” in the same way as consultants, but may be the actual "rocks" through which change takes place

Ever wondered what the difference is between being an ITSM practitioner and a consultant?

Here, Tobias Nyberg shares his experiences of how being an ITSM practitioner compares with being a consultant on a day-to-day basis

I call myself an ITSM practitioner, in the sense that that means I’m not a consultant. ITSM practitioners are there for the long haul, whereas consultants are usually only brought in to consult in the short term or on one-off projects. What this means practically is that being an ITSM practitioner brings additional opportunities and challenges that are not usually within the remit of a consultant.

Being a practitioner requires working in a sustained fashion over a longer term, so in many cases, this means I have to find ways to keep the momentum and energy up when projects end and consultants leave, and the normal business-as-usual work takes over. It can be challenging to feel you are really making a difference when you are in the middle of the daily business and everything is functioning well, whereas consultants have the benefit of being able to make a more recognizable contribution over the short term.

One of the things I really like about not being a consultant is that I have a different kind of responsibility towards my employer, my company and my colleagues, which is to make things work — and to make them work better — without the support of a project or other expert consultant. It means I have the opportunity to drive change from within, and to have the kind of long-term buy-in to make changes become a reality.

It also means I have to work and live the results of my efforts for as long as I stay at my company, which puts a different perspective on working relationships. I’ve worked with consultants that drove change so hard that everyone hated them when the project finished (well, except for management). But that was all right, since they got the work done and could leave after the project was finished.

Between a rock and a rock star

Unfortunately, we practitioners can’t use up all our organizational goodwill and call in all the personal favours we need for a single project, and then expect to have any swag left to cover the rest of the year. I believe this means that there is far less to lose by playing it hard as a consultant — as long as there are some hard-working practitioners left in the building to keep pushing the changes after the consultants have gone.

Of course, it can be a bit of a drag not to be seen as one of the rock-star “savior” consultants who show up and help make ITSM practitioners shine, but I’ve grown to accept that — as the saying goes, prophets can’t really expect to be welcomed in their own home town.

So when your boss runs in to the office, proclaiming that she or he has seen the light and the true path to ITSM goodness through the eyes of the new consultant, you just smile and cheer, and silently thank yourself for the excellent groundwork that led up to this moment of clarity. Never mind the fact that you’ve probably been saying the exact same thing for the past six months, although no one was willing to listen to you back then.

We, the practitioners, need to be there to take care of all the daily business, and gradually identify and implement areas for improvement. We are the ‘rocks’ who get the chance to see the theories and the frameworks, and then put these into practice in reality. We are the ones with the hands-on experience and firsthand knowledge on how to do things, and how it all really works. So, we may not get to be the rock stars, but we do get to be the rocks on which change is built.

It’s good to share

Our experience is something we need to value properly and share with other ITSM professionals so we can help both ourselves and the ITSM community grow.

Unfortunately, the downside of working at one place for a long time is that you automatically don’t get any fresh experience from anywhere else. A consultant can visit many companies and see firsthand how things are done and how it works there. But that breadth of experience can be hard to come by in other ways if you remain in the same company for a long period.

That’s one of the reasons I believe it is good practice for us to share our experience with each other and among the ITSM community. It’s one sure way to grow without switching to consultancy.

I’m currently working with a special-interest group where we are a majority of practitioners. It’s a great group — enthusiastic, and eager to share and learn from each other. There are some consultants who participate there, too, and they often contribute as much as anyone else. It’s always interesting to see the differences in how and what consultants and practitioners share.

But there are good reasons for that. Consultants are obliged to honour confidentiality agreements, so can’t share everything from companies where they have worked, as they can’t mention customer names without consent; also, the intellectual property might not be theirs to share, etc. However, they can share a variety and breadth of experiences from many different organizations, summarizing these with the details hidden or masked.

We practitioners, on the other hand, are able to share more information within our own discretion. We can be more detailed, and can discuss matters of interest with more depth. We also have a more profound and specialized knowledge of what we do at our organizations, but we are not as diversified and broad in our knowledge as consultants.

Best of both

When I set out to write this, it was because I had discussed the good and bad things about being a practitioner versus being a consultant with four different persons within a week.

The results were that three practitioners felt they were made smaller at their companies because of consultants, and that they had nothing to offer the community in terms of experience. Yet one consultant said he felt frustrated that he could never stay long enough to actually see the long-term results of his efforts, and that he could only ever share generalised information about his work.

In my own experience, I have been both a consultant and a practitioner — and I do like both roles, but for different reasons. Together, we tend to make great teams and drive change quite symbiotically. Let’s remember that we are different for good reasons, and strive to use that to grow — both as professional individuals and as a business community.

ITSM and multi-sourcing – taking a joined-up approach

"Multisourcing is the disciplined provisioning and blending of business and IT services from the optimal set of internal and external providers in the pursuit of business goals." ~ Wikipedia

Behind the intricacies of ITIL and the various strategies that can support ITSM, the overall aim is to improve service delivery and make the whole organisation more productive. By making sure that processes and teams are aware of what they have to deliver, ITSM can offer better service to end-users and greater efficiency overall.

Well, this is the theory. However, IT within organisations may not be organised in a way that makes this a simple proposition. The growth in outsourcing and cloud services has led to IT often becoming a fractured estate, with different areas of infrastructure, applications and support being handled by teams both inside and outside the organisation. While this doesn’t stop ITSM programmes from being successful, it does make them more challenging.

This trend – often referred to as multi-sourcing – occurs because CIOs are being asked to reduce costs within IT. Cutting out internal resources and using outside services can be an effective route to achieving this, but it can come at the expense of a joined-up IT approach. ITIL gives guidelines on how to manage this kind of environment, but reflecting theory in practice can be difficult to achieve.

Taking a Joined-Up Approach

To combat this, going back to first principles and establishing where services and responsibilities link together is essential. Knowing where suppliers are responsible for providing service, meeting Service Level Agreements and delivering what is asked of them should be at the bedrock of ITSM projects of this kind, but the reality is that many organisations are not as effective at tracking this as they should be.

This can be due to simple human error – from individual tickets being created in the wrong way and therefore not going to the right team in the first place – through to more systemic issues around holding suppliers accountable and making sure that they are delivering on their promises. Whatever problem is being faced, clearing the lines of communication and establishing that processes are being followed is the first step to take.

This is also critical to getting accurate numbers on support and service requests and how they are being handled. This may also require a back-to-basics approach, so that suppliers and internal teams can be compared properly in an “apples to apples” way. Getting this information from suppliers is essential, as otherwise there is no way to prove that the ITSM programme itself is successful.

Following on from this is looking at processes again – are there ways that these can be more automated from the start? This provides an opportunity to speed up service delivery and support requests, while also potentially reducing costs on both the customer and the supplier side. For the customer, greater productivity and lower bills should be the aim, while suppliers should see benefit from reduced cost to serve each transaction and less opportunity for tickets to be lost or mis-allocated.

In order to achieve this level of automation, there are two things to consider:


The first is how users can log requests for support and these tickets are handled through to the right support team, whether this is internal or external to the organisation. This involves more diagnosis at the beginning so that the problem is tracked properly. Users don’t care if their problem is caused by the application itself, the infrastructure supporting that app or the new upgrade that was not released out to production properly; however, the responsibility for assessing the issue and routing it through to the right support team does have a big impact on service speed and quality.

Implementing self-service portals for requests can help here by removing some of the day-to-day issues and automating their fulfilment. For example, a request for a new app to be installed can be automated if the sign-off level of the manager at a certain budget is approved automatically. This does not make the job of diagnosing problems easier for cross-team issues, but it does free up time so that more resource can be dedicated to those more difficult issues in the first place.


The second challenge is how to automate: most organisations will have a mix of systems themselves, while their service providers may have their own service desks and support tools as well. Passing tickets between systems automatically as well as managing approvals is therefore a big potential hurdle. For companies that are yet to make their choice on suppliers, establishing which systems are in place to check compatibility and integration levels is an option. For those with existing relationships in place, this is not an option to consider, so a different approach will be necessary.


Instead of thinking about tools, the emphasis has to be on workflows instead. Orchestrating processes between different platforms so that information is handled in the right way is the ultimate aim here, so that customers and suppliers can carry on using their tools of choice rather than being restricted or having to rely on manual labour to achieve results.

In a multi-sourcing world where cloud services, infrastructure and support can be managed in so many different ways, there is no one strategy that will achieve success. Each company or public body will have its own situation to consider, as well as that of its external suppliers. However, this makes orchestration and analysis of workflows more important – without this, the job of managing and delivering services is more difficult to achieve.

As multi-sourcing gets taken up by more enterprises and public sector organisations in their efforts to reduce costs, so taking a more joined- up and orchestrated approach to managing workflows will be critical to meeting their user needs as well.

Top 10 Social Intranet Trends

Digital Watercooler Moments: The most popular activity inside social intranets are the activity stream, instant messaging, and comments

Some interesting stats have emerged from CMS provider Bitrix who claim demand for Social Intranet is ‘exploding’ among small businesses.

Their data is based on 40,000 signups of their social intranet platform and 5,000 Intranet installations ranging from 2 to 4,000+ users.

Top 10 Social Intranet Trends

  1. Social intranet is small, real small, and that’s good news. The median Bitrix24 intranet size is only 9.7 users. Small businesses are embracing social intranet when it’s offered as affordable SaaS that does not require deployment.
  2. Social intranet isn’t just for business. While 62% of social intranet users are companies, 10% are educational institutions, another 10% are healthcare providers, 9% are religious institutions (churches), 7% are non-profits, and  2% are non-traditional users that can’t be easily classified (kindergarten, musical group, Navy Seals endurance training, tantric sex coach).
  3. Social intranet is a mobile. As of Jan 2013, 18% of Bitrix24 users access corporate portals from smartphones and tablets, not PCs. We expect the trend to continue.
  4. The box is dying, but… While 70% of our clients prefer using cloud-based SaaS, 30% insist on having a box version for security and privacy reasons. Several countries, like Germany, have restrictive privacy and personal data use legislation, forcing companies to store data on their own or approved servers.
  5. Emerging markets are on fire. The top 10 social intranet users by country are as follows: US, Russia, India, Brazil, UK, Philippines, Germany, China, Indonesia, Canada.
  6. Skepticism about the social intranet concept isn’t over yet. While 87% like social intranet idea and believe it will increase employee productivity, the other 13% prefer a classic intranet concept and think that social features will either be misused or won’t add anything of value.
  7. Talk and work. The most popular activities inside social intranets are as follows: 73% – activity stream, instant messaging, and comments; 27% – document storage, sharing or collaboration; 21% – tasks and project management; 15% – scheduling, calendars and meetings; 14% – CRM; 10% – work reports; 4% – business processes.
  8. Social intranet is changing traditional work patterns. For example, 60% of Bitrix24 users access the corporate portal on weekends at least once and 12% of Bitrix24 users accessed their portal on Christmas Day.
  9. Social intranet is addictive – 13% of social intranet users use the extranet to work with clients, freelancers or service-providers, exposing it to a wider audience.
  10. CRM, Project Management and Collaboration software is being absorbed by wider social intranet solutions. Almost 8% of Bitrix24 users have stopped using at least one service or software because a similar tool was already available in their social intranet package. Most frequently dropped were CRM and project management.

Bring Your Own App

Social intranet is frequently adopted on a department level (sales, HR, marketing, IT), meaning it’s used inside one department and not the whole company. In several instances Bitrix24 was used inside a department because the company intranet lacked necessary features.

Several clients stated that they got introduced to social intranet by another company (Jive, Yammer, Podio, Chatter) but found it either too difficult to use, lacking features or not appropriately sized for their business, meaning there’s a large segment of enterprises that aren’t being serviced by traditional intranet providers. Law offices, health care providers, travel agencies and realtors seem to be particular hungry for industry specific solution.

Information supplied by Dmitry Davydov of Bitrix.

Process Owner, Process Manager or Process Engineer

Process Owner, Process Manager or Process Engineer?
While they might appear much the same at first glance, these roles are actually very different

Many times people who are just getting started with ITIL (or broader speaking ITSM) stumble over what the differences are between a Process Owner and Process Manager and, to a lesser extent, a Process Engineer.

These are different roles, with different skill sets and expectations but there are some overlaps. Often, especially in smaller organizations, these roles are all served by a single person. Even in that case, it is important to know the different objectives of each role so we can ensure we are in the right frame of mind when working to either promote, create, edit, or report on a process.

Process Owner

In general then the Process Owner is the ultimate authority on what the process should help the company accomplish, ensures the process supports company policies, represents and promotes the process to the business, IT leadership and other process owners, continuously verifies the process is still fit for purpose and use and finally, manages any and all exceptions that may occur.

Overall Accountability and Responsibility:

  • Overall design
  • Ensuring the process delivers business value
  • Ensures compliance with any and all related Policies
  • Process role definitions
  • Identification of Critical Success Factors and Key Performance Indicators
  • Process advocacy and ensuring proper training is conducted
  • Process integration with other processes
  • Continual Process Improvement efforts
  • Managing process exceptions

As you can see the Process Owner is really the process champion. Typically the person filling this role is in a higher level in Leadership to help ensure the process gets the protection and attention it deserves.

The Process Owner will be the main driving force for the process creation, any value the process produces, to include acceptance and compliance within the organization and also any improvements. It is therefore crucial that the Process Owner really understands the organization and its goals as well as its own culture. This is not about reading a book and trying to implement a book version of a process but really understanding how to create a process that will deliver the most value for this particular organization.

General Skills and Knowledge needed:

  • Company and IT Department goals and objectives
  • IT Department organizational structure and culture
  • Ability to create a collaborative environment and deliver a consensus agreement with key IT personnel
  • Authority to manage exceptions as required.
  • ITIL Foundation is recommended
  • ITIL Service Design and Continual Service Improvement could be helpful

Level of Authority in the Organization

  • Director
  • Senior Manager

Process Manager

The Process Manager is more operational than the Process Owner. You may have multiple Process Managers but you will only ever have a single Process Owner.

You can have a Process Manager for different regions or different groups within your IT Department. Think of IT Service Continuity with a ITSC Process Manager for each of your different Data Centers or Change Management having a different Change Process Manager for Applications versus Infrastructure. The Process Owner will define the roles as appropriate for the organizational structure and culture (see above). The Process Manager is there to manage the day to day execution of the process. The Process Manager should also serve as the first line for any process escalation, they should be very familiar with the ins and outs of the process and will be able to determine the appropriate path or if he/she needs to involve the ultimate authority – the Process Owner.

Overall Accountability and Responsibility:

  • Ensuring the process is executed appropriately at each described step
  • Ensuring the appropriate inputs/outputs are being produced
  • Guiding process practitioners (those moving through the process) appropriately
  • Producing and monitoring process KPI reports

The Process Manager is key to the day to day operations of the process. Without a good and helpful Process Manager it won’t matter how well a process was designed and promoted by the Process Owner, the process will flounder in the rough seas of IT day to day execution.

General Skills and Knowledge needed:

  • In depth knowledge of the process workflow and process CSF/KPI’s
  • Ability and authority to accept/reject all inputs/outputs related to the process
  • Ability to successful explain and guide people through the process and handle any low level process issues
  • ITIL Foundation is recommended
  • ITIL Intermediate in an area that covers their particular process could be helpful

Level of Authority in the Organization

  • Mid Level Manager
  • First Line Manager
  • Supervisor

Process Engineer

The Process Engineer is likely to have a lot of Business Analysis and Technical Writer skills and knowledge. This person needs to be able to take the Process Owner’s vision and intent of the process and actually create the process document that will be functionally usable by Process Managers and Process Practitioners. Another useful role of the Process Engineer is help ensure that each process in the enterprise is written in a common manner to ensure consistency in approach and method.

Overall Accountability and Responsibility:

  • Understanding the Process Owner’s vision and intent
  • Documenting the process in a usable and readable manner
    • Organized
    • Simple
    • Unambiguous
    • Ensuring flow charts match text
    • Ensuring processes are documented in a common manner across the enterprise

General Skills and Knowledge needed:

  • Ability to capture process requirements and translate them into a process document
  • Ability to write well
  • Ability to create effective work flow diagrams
  • ITIL Foundation could be helpful

Level of Authority in the Organization

  • Individual Contributor

As you can see a Process Engineer can be quite helpful in ensuring that the vision of the Process Owner is translated into a functional process document.


It is possible that a single person can do all three roles effectively but more likely the person will be more effective at one of these roles and less so at the others. If your organization is such that it is not possible that the three can be filled separately with people possessing the appropriate skills it is still advisable that a separate Process Engineer is utilized across the enterprise. A Process Engineer can work on several processes at once and will always be helpful for any process improvement efforts. A Process Owner can also function as a Process Manager without much issue given an appropriate scope and demand.

Image Credit

Coming Soon: Axios, Biomni, Matrix42 & ServiceNow Showcase Service Catalogue

Axios, Biomni, Matrix42 and ServiceNow - who leads the pack in Service Catalogue?

Axios, Biomni, Matrix42 and ServiceNow are confirmed participants for our upcoming ‘Service Catalogue’ review.

Our assessment criteria at a glance:

  1. Service Design – the ability to create a database of service records, containing a number of business and technical attributes, processes and workflows.
  2. Service Structure – the ability to organise and structure these services into a hierarchy of services and service offerings, ideally useable in a graphical format
  3. User Request Portal – a user-friendly/external facing portal that provides users with an intuitive User Interface to request services
  4. Request Fulfilment – request management workflow functionality that can be easily used and configured by system users
  5. SLA and event management – the ability (in the software or by integration) to define universal and bespoke levels of SLA which are then automated and escalated though an event management process – ideally linking with Incident, Problem and Change Management functionality
  6. Demand Management – the ability to provide real time allocation and monitoring of Service consumption, with financial calculations
  7. Dashboard – real-time user-friendly graphical monitoring and analysis of usage, trends and metrics across services and to various stakeholders
  8. Service Reporting – the ability to present output that summarises individual and bundled service performance, consumption, SLA and event performance, in user-friendly, portable and graphical format

Full details of the assessment criteria can be found here.

Reviewer: Barclay Rae

Confirmed Participants:


All results will be published free of charge without registration on the ITSM Review. You may wish to subscribe to the ITSM Review newsletter (top right of this this page) or follow us on Twitter to receive a notification when it is published.

Image Credit

Power to the People

How Social IT Rebalances the People Process Technology Equation

A remarkable transformation is taking place in the world of information technology today. It reflects a new generation of knowledge workers utilizing social media to improve problem-solving, foster collaboration and spark innovation.

However, despite the continued reference to the traditional triad of success encompassing people, process and technology, the IT world has typically focused more on the process and technology sides rather than emphasizing the ‘people’ component.

This has been particularly true of IT products, consultants, and executives who have emphasized a command and control approach to IT that tends to downplay and minimize the people factor.

While a highly industrialized, mechanistic view of IT over the last five plus years has led to enormous gains in automation and productivity, the IT industry has now reached a point where differentiation around process and technology has become smaller and smaller. At the same time, innovations such as tablets and smartphones have introduced a new era of enterprise IT consumerization that is dramatically changing workplace habits and forms of communication and collaboration within and between organizations worldwide.

Get on board the collaboration economy!

The Kellogg School of Management at Northwestern University, among others, has proclaimed a paradigm shift to a new “collaboration economy” that allows people, teams and companies to effectively organize and focus their activities on creating value and driving profitability. Thus, the traditional IT emphasis on process and technology is giving way to new ways of thinking that recognize the increasing importance of the social or people component in IT in order to unlock new sources of productivity and value through greater knowledge sharing and collaboration.

The following five key behavioral attributes are necessary to increase people engagement and rebalance the IT operations equation for success:

  1. Divide and Conquer – Overcome limitations of traditional mechanistic approaches to IT information discovery and share the knowledge and expertise of IT staff across the enterprise
  2. Feed and Engage – Facilitate new ways of engagement to break down traditional barriers to communication and collaboration among IT teams and stakeholders
  3. Assign and Trust – Foster accountability for knowledge, so that individuals take on responsibilities that go beyond traditional IT processes and systems and their peers trust in the knowledge captured
  4. Make it Second Nature – Use approaches that feel natural and interact intuitively to increase adoption and value
  5. Reinforce and Reward – Compel executives and IT managers to recognize and reward collaborative behavior among IT staff and stakeholders

Behavior #1: Divide and Conquer

Most IT organizations today conduct operations with a heavy emphasis on machine-driven automated discovery and monolithic configuration management databases (CMDBs) that attempt to capture all information about the IT environment. In many cases, these tools and databases are managed by a specialized team charged with keeping information current. However, these teams often have far less institutional knowledge and expertise than others within the IT organization. Those who do have the most knowledge are either blocked from directly accessing and updating these tools and databases, or they refuse to do so because they are already comfortable with their own personal spreadsheets, wikis, and other tools.

This results in a situation where IT departments all too frequently spend limited budget dollars to staff full- time resources to establish a “single source of truth” that is, in fact, either out of date, not trusted by many in their own organization, or both.

As a consequence, IT departments either do not use these tools and databases for their intended purposes, or IT professionals are forced to rely on inaccurate information to assess issues or problems and make decisions.

In contrast, social knowledge management gives everyone in IT a stake in contributing to and verifying the accuracy of the knowledge about the IT environment. The “burden” of maintenance doesn’t fall on any single person or team, but is the collective responsibility of everyone participating.

This is not to say there isn’t value in machine discovered knowledge. Instead, machine knowledge must be augmented by human knowledge and validated so that the organization can confidently make decisions. Stated another way, rather than trying to eliminate the human factor, as traditional approaches have done, social IT actually encourages all knowledgeable individuals to share their expertise and contribute to the knowledge pool by creating and following a new breed of “social objects” that leverage well-known principles from Wikipedia and Facebook-style news feeds.

Behavior #2: Feed and Engage

IT organizations that emphasize process and technology at the expense of people often tend to erect boundaries between individuals and teams in an effort to strictly manage operations through a hierarchical command and control structure. This approach reinforces the traditional technology silos in IT and exacerbates them by creating new process silos. For example, if the network is up and running, why should the network group worry if an application is slow? “It’s not our problem” is a typical reaction when IT behavior is siloed and not collaborative.

Social IT-based crowdsourcing and peer review of knowledge, on the other hand, taps into the human instinct to fill in the gaps of known and unknown information. Then, when confronting incidents, problems, and changes, the organization can make better decisions by better coordinating team effort where individuals contribute to issues they feel connected to and care about based on their responsibilities, their expertise, or simply their individual interests. This can be accomplished by leveraging familiar social media principles and “following” the objects IT manages (such as servers, network devices, applications, etc.) and by automatically assigning experts to collaboration activities around incidents, problems, and changes. With this approach, individuals can also be alerted and fed new information as social objects are updated leading to an organization that is continually current on the latest IT environment reality.

With such an approach, rather than hoarding knowledge for job security, individuals are encouraged to take ownership of objects in their sphere of influence and responsibility, keep those objects updated with new knowledge, create new objects when performing daily tasks, and then automatically share their activities with others who are affected by or depend on them.

Behavior #3: Assign and Trust

If the people potential of IT is to be fully realized by pooling collective knowledge and continuous engagement via social media types of communication and collaboration, then individuals must be accountable to others for their contribution and actions. In other words, you can crowd source knowledge but all knowledge is not created equal. Even though multiple individuals can contribute knowledge, a single individual or role should have sole ownership of a “social object.” In this manner, the organization can increase its trust of the knowledge about that object, or, if it is not being accurately maintained, replace the individual who is responsible.

Behavior #4: Make it Second Nature

IT organizations and bookshelves are littered with the bones of projects that have tried to enforce processes that individuals pay lip service to and then promptly ignore in their daily operational activities. What’s more, IT professionals are usually some of the busiest employees in the organization, so adding on a new set of activities can easily be met with skepticism.

The real potential and promise of social IT stems from its ability to foster ways of communicating and working that feel natural and intuitive to human beings without adding more to the plates of those who already feel overworked. The fact is, IT organizations are inherently social already. IT teams just haven’t had tools that are designed to support collaboration and the capture of knowledge.

IT teams that use email or instant messaging, conduct daily SCRUM meetings, or hold regular Change Advisory Board reviews, are ripe for the benefits of Social IT. But to leverage social IT requires products that fit naturally into the work IT professionals are already doing, and that augment existing processes and practices without being seen as another thing that must be done in the course of a day.

By taking this approach, IT organizations will find that “offline” communication methods like email and instant messaging will be used less and less in favor of the social knowledge management system. They will also find that SCRUM meetings are more productive and CAB meetings focused more on the changes that have the biggest risk.

Behavior #5: Reinforce and Reward

As human beings, we pay close attention to the kinds of behavior that are actually valued and rewarded in the workplace by management. Therefore, it’s imperative that executive and IT management understand and reward social IT activities that contribute to the knowledge and collaboration necessary to improve problem-solving and decision-making among IT staff members.

IT leadership must create a culture of collaboration that encourages and rewards individuals who participate in social IT by assuming responsibility and ownership of objects in their sphere of influence and actively contributing on a daily basis. One IT organization that I know of set a goal for getting a specific number of social objects into their knowledge management system by a certain day, and then paid a bonus to those who contributed to meeting that objective. You might consider providing incentives through bonuses like this and/or as part of annual performance reviews for those who make decisions by consulting the social IT knowledge management system.

Finally: An unprecedented opportunity to improve IT productivity

The introduction of social technologies into the IT workplace presents an unprecedented opportunity to improve productivity and even job satisfaction of IT professionals. Taking advantage of that opportunity, however, requires that IT leaders rebalance the people, process, technology equation by driving behavioral change and equipping teams with the proper tools and incentives to achieve success.

Image credit

7 golden rules for getting the most from the Service Catalogue

This article has been contributed by Yemsrach Hailemariam, ITSM Consultant at Macro 4.

Implementing IT service management (ITSM) according to ITIL best practice is often seen as a large, complex undertaking which those outside of IT may sometimes struggle to see the true value of.  This can mean the IT department feels some pressure to demonstrate early evidence of practical progress to help win the confidence of the wider business organisation.  But that should not mean they skimp on the all-important first stage of the process – which is the creation of a Service Catalogue.

Here is a list of seven important rules that you need to consider if you are going to squeeze maximum value from the Service Catalogue

Squeeze the most out of your Service Catalogue initiative, but watch out for some of those sour low-hanging fruit!

Rule number one: don’t judge a catalogue by its cover

I have seen organisations that are tempted to speed through the process of defining the services in the Service Catalogue, viewing this as a quick ‘box ticking’ exercise.  After all, they think to themselves, it’s simply creating a list of the services that IT delivers to the business, right?

Wrong. Despite the slightly uninspiring name, the Service Catalogue is much more than just a list of services with some related information.  And in reality that ‘just’ is a loaded word. When you consider that many organisations have never actually gone through the process of clearly defining the services that IT should deliver to the business, you start to realise that ‘just’ getting it written down is actually the catalyst for defining the roles and responsibilities of IT to the business – and getting that right is an essential cornerstone of IT Service management.

Rule number two: bang heads together

To create the Service Catalogue, you will probably have to get IT sitting down in a meeting or workshop with representatives from the business to hammer out the detail of which services the business requires, how significant they are and how they support the business.  There is usually also some discussion about what the priorities are among the services, the required service levels and availability requirements.

If one of the goals for ITSM is to help IT align more tightly with the business, then you can immediately see how the process of creating the Service Catalogue plays a significant role – by getting everyone to review the global picture of the business’s IT requirements.  Without such an impetus of how often would technical and business colleagues meet and discuss the details of what the business actually wants from the IT department, and how it can be delivered?

Rule number three: ask people what they want FIRST – then look at how you can deliver it

A good place to start discussions around defining the contents of Service Catalogue is to run an analysis of the existing service portfolio.  You can ask a number of useful questions.  Is this the optimal range of services for the business?  Is it possible to demonstrate how each IT service supports the key drivers for the business?  Is it possible to tie the service definitions to specific business processes, benchmarks, and KPIs which might also help with tracking and reporting service provided.

Rule number four: resist the temptation of low-hanging fruit – it may leave a sour taste

Too often organisations rush through the development  of the Service Catalogue in order to move on as swiftly as possible to other areas which they feel can provide some initial ‘quick win’ benefits.   Unsurprisingly the area they tend to start with is Incident Management  – which involves developing the processes for restoring normal IT service operations as swiftly and effectively as possible and minimising the impact on business operations ( in the event that normal services have been disrupted for some reason).

The rest of the business can easily appreciate the practical, tangible value of Incident Management.  After all, it is an important area for any business and the whole topic of managing incidents is very familiar to, and resonates well with, the service desk – which is often heavily involved in the rollout of ITSM.

But a well defined Service Catalogue forms the foundation of Incident Management and getting this completed accurately should be the first priority. If you don’t, you might just find that your incident management process falls flat on its face…when there is an unplanned disruption to a service, it is the Service Catalogue that provides the service desk with speedy access to key information – about Service Level Agreements, numbers and types of users of the service and related configuration items (CIs) – that enables it to prioritise effort to restore the service to required levels.

Rule number five: build upwards from solid foundations

As well as helping to ensure that the services that IT delivers are really those that are valued by the business, a comprehensive Service Catalogue is the place to document the fine detail about the specific range of available services, their relative value and associated costs, the configuration items (CIs) – the various parts of the IT infrastructure involved in delivering that service; and service level expectations.

A well-defined Service Catalogue will be the connector between the Incident, Change, Problem and Service Request processes. The relevant CIs associated with delivering services and their inter-relationships are very often recorded within the Service Catalogue. So when a business user calls with an issue or a service request then the service desk can quickly identify the possible CIs affected based on the service.

For example if there is a connectivity problem with the exchange server, the Service Desk will decide that the service affected will be Email – Connection. The affected CI can be easily identified as the Service Desk will have a small number of CIs to select from.  This makes the task of identifying the affected CI, in a vast organisation where the Service Desk might not be familiar with the IT infrastructure, easier – helping the Service Desk to do its job well.  If subsequently a change is required to the CI then a change can be logged against the same Service Catalogue.

Rule number six: use the service catalogue to deliver tangible value to business stakeholders

The other benefit of having an up-to-date Service Catalogue is that different parts of the business can use it to easily identify the services that are available to them, assess whether they need them and how much it will cost their business unit.  It allows the business to make quick, informed decisions about what services they want to use, while taking account of the cost implications to drive an efficient allocation of IT resources. Demonstrating value in this way will incentivise your service deliverers to keep it up-to-date.

Moreover, the documented Service Catalogue information about service priorities, costs, service levels and uptime will help with monitoring the service delivery success.  This in turn can feed through to helping   identify opportunities for making service improvements and identifying where cost reductions might be possible

Rule number seven: one size does not fit all

Of course different organisations’ Service Catalogues can vary greatly in style and format. They can range from the very simple document based formats, or static web based catalogues through to interactive portals and fully interactive tools or ITSM suite based products.  The more sophisticated tools and solutions, which take considerable time to implement and maintain,  have additional advantages such as integration with other support based processes, self service capabilities and the ability to act as the ‘front end’ to all other ITSM process areas.

Each organisation needs to decide on the style and sophistication of Service Catalogue it requires, based on factors such as the specific audiences it needs to cater for, the scope of the aims and objectives and the resource constraints it is working to.  But the Service Catalogue remains the most logical and efficient place to start the ITSM journey.

This article has been contributed by Yemsrach Hailemariam, ITSM Consultant at Macro 4, which runs the UK arm of iET Solutions. Yemsrach has worked as a technical consultant for the past 10 years consulting on many ITSM projects in the US, UK and Germany.  She has a BS in Electrical Engineering from University of Maryland, USA.