Transforming the IT service experience

Left to right: Lori Krikorian, Dana Swanstrom, and Sally Shane accepted the Project of the Year award in Las Vegas in February.
Left to right: Lori Krikorian, Dana Swanstrom, and Sally Shane accepted the Project of the Year award in Las Vegas in February.

EMC Corporation’s IT organization (EMC IT) has been on a multiyear transformational journey, transitioning to a virtual and private cloud infrastructure and modifying its operating model to be one of a competitive service provider. They have also been working to unlock the capabilities to deliver more agility to its business customer through optimized service delivery and modern application development aligned to IT trends of cloud, mobile, social, and Big Data. But, the company’s IT service management (ITSM) processes lacked agility to meet the evolving needs of its internal customers. Couple this obstacle with unstable, obsolete, and unintegrated technologies that lacked mobility, community, and self-help functionality.  EMC IT launched its UnITy program to address this significant challenge.

UnITy Program

The UnITy program began in July 2012 to optimize ITSM processes, replace its previous ITSM technology platforms, and transform IT into a customer-focused organization committed to consistently delivering collaborative support.

To start, the team conducted more than 100 interviews and numerous workshops to collectively understand the challenges IT faced and secure leadership support for the problem, business drivers, critical success factors, and solutions. From these sessions, the team defined the program’s vision as: “To delight EMC IT’s clients by transforming their IT service experience through optimized service management processes and technologies.”

The program then set out to address four key points in EMC IT.

  1. Enhance the customer experience for EMC’s 60,000 users by evolving IT’s to be service-focused and allow the customer experience to drive prioritization and responsiveness.
  2. Enable IT to operate as a business by optimizing processes and improving transparency through service metrics and better service quality.
  3. Align IT’s resources with customer expectations and improve capabilities such as self-service and the availability of better decision making data.
  4. Optimize IT support so the company will, in time, realize millions in annual savings by reducing the use of in-house production support and managed service providers, decommissioning redundant IT systems, and using self-service to reduce calls to the service desk.

Program Phases

In Phase I, the program released the new ITSM platform along with three processes – incident management, request fulfillment, and knowledge management. In Phase II, the program rolled out an improved configuration management database, a new service taxonomy, and three more processes – problem management, change management and service asset and configuration management.

At the core of UnITy was a mountain of change for EMC IT to adapt. To usher in the necessary cultural changes we created three workstreams – process optimization, technology, and transformation. While the workstreams focused on their respective topics, the entire team worked cohesively to evangelize the program by sharing a common understanding of the capabilities and benefits being delivered by UnITy. Perhaps most importantly, the transformation workstream led the organizational change in EMC IT, providing training, communication, and engagement at all levels in IT to drive the cultural evolution toward one of customer focus.

On the training side, the team built its own custom, instructor-led and computer-based training and enlisted 100 global users who went through week-long training on the new platform, processes, and way of thinking. In turn, these users held day-long training sessions with more than 1,000 users across our global EMC IT sites. As program champions, these individuals evangelized the program and provided support in the field before and after. Additionally, another 1,500+ users received computer-based training.

On the communications side, the UnITy program engaged a multi-channel campaign to provide information in a number of accessible and easily digestible ways. This included:

  • An intranet site that consistently ranked among the most-visited EMC IT sites
  • A regularly published email newsletter
  • Regularly scheduled global town hall meetings
  • A user engagement network that met weekly, championed the program, and provided feedback
  • A series of videos that featured IT leaders and program members delivering key messages

The UnITy team also used its leadership steering committee to validate decisions, in some cases make decisions, clear hurdles, and champion the program throughout IT. This was vital to pushing change through an organization and program sponsors helped communicate expectations to EMC IT through video messages, personal emails, and even shared goals for training and adoption.

So, what did EMC IT learn from this complex and culture-changing program?

  1. Engagement at all levels of the EMC IT organization was vital. Having leadership support made it easier to push changes through, but having employee understanding of why the changes were happening and how they would benefit the individual and organization accelerated adoption.
  2. No customizations! Sticking with the out-of-the-box ITSM functionality kept the program on course using best practices and ITIL processes, instead of bending the technology to match the way IT operated in the past.
  3. Listen to the pros. We brought in experts to guide us in process adoption and tool deployment. When in doubt, we turned to the experts on best practices and moved ahead with their guidance.

EMC IT are currently in Phase III of the UnITy program to expand the service management platform and processes to businesses outside of IT. They remain focused on the metrics and reporting analysis to identify areas for continuous improvement. While it was a tremendous initiative for the whole EMC IT organization, they now have the technology and processes in place to continue to evolve the organization and to continue to provide the highest quality services for the future.

In February this year, EMC IT won the Project of the Year Award at the Pink Elephant Annual Conference in Las Vegas. If you would like to learn more about the UnITy program’s journey, you can read this blog post by program lead Dana Swanstrom.


 

The ITSM Review are holding a series of seminars this year headed by ITSM superstar Barclay Rae. We will be starting in March with Transforming User Experience – Enterprise Service Management & Self Service. For more information click here

Change Management – Surviving Implementation

253914822_f34c961bd6_z
The super power of a change manager is an “invisible shield”, just like Violet from The Incredibles

One of the things I’m getting asked about most this year is about getting the basics right – how to actually do change management in the real world. We all know that having good processes in place protect us all, ensures we meet regulatory guidelines and are generally just common sense, but what about using them so that we can build a better, stronger IT organisation? In this article, I’m going to talk about getting started and surviving the implementation phase. I’ll then follow it up with another article on how to actually run your change management process.

Let’s start from the beginning. change management sits in the transition stage of the service lifecycle. ITIL states that the objective of change management is “to ensure that changes are recorded, evaluated, authorised, prioritised, planned, tested, implemented, documented and reviewed in a controlled manner. In a nutshell, change management is about putting things in, moving things round or taking them out, and doing it safely and without setting anything on fire.

When describing the change process, I call change managers the guardians or protectors of our network. They ensure all changes are sanity checked, tested, reviewed, approved and scheduled at a sensible time. Their super power is an invisible shield (like Violet in “The Incredibles”) that protects the rest of the organisation from the adverse impact of change.

Getting started: Common Excuses and Ways Around Them

Change management is an incredibly important process because it enables you to manage, control and protect your live environment. Since the credit crunch, I’ve had more and more people coming to me saying that their change departments would either have to endure massive cut backs or stop improvement works. Here are some of the most common excuses I’ve come across for this along with some possible ways around them.

Excuse number 1: “We don’t have the time”. Ok, what about all the time wasted dealing with the impact of failed or unmanaged changes, firefighting incidents and dealing with the big angry mob camped outside the IT department waiting to lynch us for yet another mistake? Let’s be sensible, having a strong change process in place will lead to massive efficiency savings and the use of standard changes, models and templates will make the work involved repeatable.

Excuse number 2: “We don’t have the resources”. What about all the time spent going cap in hand to the rest of the business explaining why a key service was unceremoniously taken out by a badly executed change? Spin doctoring a major incident report that has to go out to external customers? I’d argue that you’re wasting resources constantly firefighting and if you’re not careful it will lead to stressed out departments and key individuals burning out from the stress of trying to keep it all together. Instead of wasting resources and talent – why not put it to good use and start getting proactive?

Excuse number 3: “We don’t have the money”. What about all the money spent on service credits or fines to disgruntled customers? Then there’s the less tangible side of cost. Reputational damage, being front-page news, and being universally slated across social media – not nice and definitely not nice having to deal with the fall out. Finally, what about compliance and regulatory concerns? Failing an audit could be the difference between staying profitable or losing a key customer.

Excuse number 4: “We can’t afford expensive consultants”. Ok, hands up. I used to be a consultant. I used to work for Pink Elephant UK and for anyone out there looking for an amazing consulting / training company then go with Pink – they rock. That aside, if you can’t afford outside help in the form of consultancy, you still have lots of options. Firstly, you have the itSMF. Again, I’m biased here because I’ve been a member, as well as a speaker for, and chair of, various sub groups and committees, all in an attempt to champion the needs of the IT service management community. Here’s the thing though, it’s useful war stories, articles, white papers and templates written by the members for the members. There’s also ISACA which focus more on the governance and COBIT side of things. There’s the Back2ITSM movement – lots of fantastic help support and information here. There’s the ITSM Review and blog sites from the likes of The IT Skeptic – lots of free resources to help you sort out your change Management process.

Excuse number 5: “I’m probably going to be made redundant anyway so what’s the point?” Yes, I am serious, this is an excuse I’ve come across. There’s no way to sugar coat it, being made redundant or even being put at risk is (to put it mildly) a rubbish experience. In that situation (and believe me, I’ve been there) all you can do is keep doing your best until you are told to do otherwise. Having a strong change management process can be a differentiator on responses to bids. Tenders as SOX compliance, or ISO 20000 accreditation can set you apart from competitors. Bottom line, we have to at least try.

Planning for Change Management

So how do you get started? First things first: you need to get buy in. Most management guides will tell you to focus on the top layer of management as they hold the purse strings, and that’s very true, but you also need buy in from your guys on the front line – the guys who will actually be using your process. Get their buy in and you’re sorted, because without it you’re stuffed.

So, starting with the guys at the top, you need to speak to them in their language and that means one thing – a business case! This doesn’t have to take forever and there are lots of templates out there you can use. The key thing is to explain clearly, in their language, why change management is so important. Things to cover in your business case are introduction, scope, options, deliverables and benefits. Now get your techies on board. There’s no “right” way of doing this. As someone with a few war stories to tell, things that have worked in the past include:

  • sitting down with your techies
  • templating everything
  • using the umbrella argument (more on that later)
157147622_3b79fa7cab_z
Krispy Kremes can help

I’ve also found that bribing support teams with doughnuts can be very effective, as a former techie I can confirm that Krispy Kreme ones work particularly well.

Once you’ve got your buy in, gather and confirm your requirements.  At the risk of playing management bingo here, a good approach is to set up workshops. Engage with both IT and the rest of the business so that there are no surprises. If you have an internal risk or audit department now is the time to befriend them! Using the aforementioned donuts as bribery if necessary, get their input as they will have the most up to date regulatory requirements you need to adhere to such as SOX or Basel 3.

Define the scope otherwise it will creep! Plan what you want to cover carefully. Do you want to cover all production equipment? What about test and DR environments? Whatever scope you agree, make sure it is included in any SLAs, OLAs or underpinning contracts so that you have documented what you are working to.

Keep your end users in mind

When writing your policy, process and procedures, keep your end users in mind. Don’t try to cover everything in red tape or people will find ways to circumvent your process. Let’s start with your policy. This is your statement of intent, your list of “thou shall” and  “thou shall nots”. Make sure it’s clear, concise and is in alignment with existing company standards. I know this might sound counterintuitive but also, prepare for it to be broken. It might sound strange but there will be times where something will need to be fixed in the middle of the night or there will need to be an urgent update to your website. It’s important that changes are raised in enough time for them to be reviewed and authorised, but exceptions will pop up so plan for them now when you’re not under pressure. Examples of when an emergency process could be used are:

  • Something’s broken or on fire (fixing a major incident)
  • Something’s about to be broken (preventing a major incident)
  • Major commercial reasons (in response to a move by a competitor)
  • A major risk to compliance has been identified (e.g. base rate changes, virus patches)

When looking at your process, make sure you have all the bases covered. This will include:

  • Recording and processing the change
  • Change assessment
  • Change Advisory Board (CAB)
  • Build and test
  • Implement
  • Review and close

I’ll talk about these in lots of detail in part two of this article.

Training & Communications

You’re about to go live with your sparkly new change management process and you want it to be a success so tell people about it! First, attend every team meeting, management huddle and town hall that you can get away with! Get people onside so that they know how much help change management can be and to reassure them they won’t have to go through lots of red tape just for the sake of it. Another way of getting your message out is to use posters. They’re bright, cheerful and cheap – here is one that I’ve used often.

2650056763_2a7cd6b746_z
Pelt front line teams with coloured balls if necessary! Not too hard though!

In terms of training you need to think about your change management team and your stakeholders, the people that will be raising changes using your process. For your change management team there are lots of practical courses out there that can help – a few examples could include:

  • ITIL Foundation
  • ITIL – Service Transition
  • ITIL – Release Control and Validation (RCV)
  • COBIT
  • SDI Managers Certificate
  • ISO 20000

Other important considerations include:

  • On the job training
  • Shadowing

But what about your front line teams who will be raising the changes and carry out the work? Again put some training together – make it interactive so that it will be memorable – in the past I have been pelted by brightly coloured balls by a colleague in the name of explaining change management so there really is no excuse for death by PowerPoint!

Things to cover are:

  • The process, its scope and the definition of a change
  • Raising a change record to include things like implementation plans, back out plans, testing, risk categorisation (“no it is not ok to just put medium”) and DR considerations
  • Templates & models
  • Benefits

I’ve done a fair few of these in my time so if you would like some help or examples just ping me on my contact details below.

Go Live

So you’re good to go. You’ve gathered your requirements, confirmed your scope, got buy in and have written up your policy, process & procedures. You’ve socialised it with support teams, ensured everyone has been trained up and have communicated the go live date. So deep breath time, go for it! Trust yourself, this is a starting point, your process will improve over time.

Metrics

I’ve written lots about metrics recently and have spoken about the basics in a previous article on availability, incident and problem management but in short:

You need to have a mission statement. It doesn’t have to be fancy but it does need to be a statement of intent for your team and your process. An example of a change management statement could be “to deliver changes effectively, efficiently and safely so that we put the customer at the heart of everything we do”.

Next come the CSF’s or critical success factors. CSFs look at how you can achieve your mission and some examples for change management could include:

  • To ensure all changes are carried out effectively and safely.
  • To ensure all changes are carried out efficiently, on time and with no out of scope emergency work.
  • To work closely with our customers & stakeholders to ensure we keep improving while continuing to meet their needs

Finally, we have Key Performance Indicators or KPIs. These give you the detail on how you are performing at the day to day level and act as an early warning system so that if things are going wrong, you can act on them quickly. Some example KPIs for change could include:

  • More than 98% changes are implemented successfully
  • Less than 5% of changes are emergency changes
  • Less than 10% of changes are rescheduled more than once
  • Less than 1% of changes are out of process

So you’ve survived your change process implementation – smile,  relax and take a deep breath because now the real work starts! Come back soon for part two of this article which will give you some practical advice on running your new change management process.

Image Credit 1

Image Credit 2

Image Credit 3

Podcast Episode 2: 'Hot tables' at SITS, ITSM Industry News, CSI and Barclay in his onesie?

ManageEngine
Thanks to our friends at ManageEngine for sponsoring this podcast.

Episode 2 of The ITSM Review Podcast!

Hosted by Barclay Rae and Rebecca Beach.

Special Guest: Stuart Rance from Optimal Service Management

ITSM Industry News

CSI

  • Most problem management is CSI
  • CSI – source of the biggest ROI
  • Metrics for change management, Real meaningful metrics for CSI
  • Stuart Rance – Balanced Scorecard Approach
  • 1. What does it look like for the customer?
  • 2. How well are my internal processes running?
  • 3. What do the finances look like?
  • 4. What am I doing to learn and improve?
  • Taking Service Forward

Our next Podcast is scheduled to be recorded at SITS14.

If you have industry news to share ahead of our next podcast please give me a shout.

Thanks to our friends at ManageEngine for sponsoring this podcast.

ITAM Review and ITSM Review Feeds

Stop Blaming Release Management!

When releases fail, we often point a finger at the release manager, expecting that person to make the necessary corrections to prevent similar failures in the future.  In doing so, we miss the real target – the service delivery flow.  This flow, with its many inputs, is in disarray in most organizations and the solution seems daunting.  This article proposes that there is a simple, inexpensive, and self-healing approach to improving the flow of service modification.

When a Release Goes Bad

The scene is too familiar.  The service desk, on the verge of panic, is swamped with increasingly irate calls.  The boss is on a bridge line with a host of managers and technicians trying to restore order.  The business units, demanding action, are banging on the CIO’s door and the echoes reverberate throughout IT.

Last night, IT distributed a major release of a critical business application.  Today, users are converging on IT with torches and pitchforks.  The business application update had an enormous impact on productivity and revenue.  The impact continues as the business owner demands that the changes be “backed out” – a request that IT finds exasperatingly difficult to satisfy.

When the dust settles, it is not uncommon to see root cause analysis identify the numerous mistakes made in the “release”.  The list might include:

Table1
Common Issues and Likely Culprits

Who is to blame?  Release management?  Of the 11 mistakes listed, 9 belong to groups outside release management.  Yet, in many cases, release management will still take the heat.  The purpose of this article is not so much to absolve release management but rather to bring understanding to the larger service lifecycle in hopes that the readers can address the true causes of release failures.

Know the River

Release and deployment management is just one part of a much larger lifecycle.  Think of it as a port along a river.  A business service starts out as an empty barge on the business dock.  In ITIL terms, the manager of that dock, Business requirements management (BRM), loads the barge with service requirements.  In the diagram, this is the “Identify” stage.

Service Flow - Stages, Participants, Output
Service Flow – Stages, Participants, Output

The barge makes a number of stops on its way down the river.  Along the way, the manifest of the barge is equivalent to the seldom referenced (but, in some form, always present) service design package of ITIL.

When the barge, stacked with cargo, finally pulls into the release and deployment dock, the only issue should be how to transport the contents of the barge effectively and safely to the appropriate recipients.  One could think of release and deployment as a trucking company.  The truckers did not design or build the cargo.  Nor are they to blame if the item in the package performs poorly.

I recently ordered a manual online.  The package arrived in the expected time frame and was intact.  As I read the manual, I noticed that an entire section was missing.  Should I blame the trucking company?  Of course not.  Likewise, we should not hold the release management responsible for defects over which it has (by design and best practice) no control.

The following table might help to identify the “river ports” where the service barge might be picking up sub-standard cargo.

Service Lifecycle River
Service Lifecycle River

Look Upstream

In order to effectively manage and improve the delivery of a release, we need to focus on three major points:

  • Transition review
  • Service delivery package
  • Project charter
Feeding the Transition Review
Feeding the Transition Review

Transition Review

The objective of the transition review (post implementation review) is simple: Learn from your mistakes.  When an organization first commits to regular PIRs, they may be a bit disorganized.  As inputs and outputs become better defined, so will the overall process.   The transition review is the spawning ground for improvement of this lifecycle.

Service Design Package

Although few enterprises seem to understand the concept of the SDP, it is, in my opinion, a brilliant addition to ITIL v3 2011.  When organizations address the output of Transition Reviews, they inevitably make adjustments to the SDP because it is the mechanism for improving consistency, governance, and effectiveness for the service modification lifecycle.

Project Charter

In most shops, the service modification lifecycle begins around a table of senior managers.  The beginning of a project needs to be less about hierarchy and more about process because this is not a hand-off; this is a flow.  Four players are critical to the project charter.

  • Business relationship manager – understands business requirements.
  • Service portfolio manager – understands the pipeline and service catalog.
  • Service level manager – understands issues that might impact service levels and process.
  • IT architecture – understands the importance of a consistent framework.
Deming's PDCA Organic Flow
Deming’s PDCA Organic Flow

With these, the organization understands business requirements, process, and infrastructure within the context of service delivery.

Completing the Circle

With the project charter, service design package, and Transition Review, we have completed the deming circle (Plan, Do, Check, Act).

Most shops fall short in planning and checking because these activities are poorly governed and too loosely integrated into the overall flow.  As Yoda would say, “Without plan, no do; without check, no act.”

Start Small but Start Smart

When a release fails (especially when it fails in a spectacular way), the fault generally lies in the process.  If, as I assume, this is common knowledge, why do these broken processes persist?  Because most enterprises perceive that process optimization costs too much money, takes too much time and does not meet more immediate business objectives.This reticence is understandable given the typical consulting approach.  A consulting firm will probably suggest starting with a comprehensive assessment that forms the basis for a massive proposal that drains resources from business-critical initiatives.

Instead, insist that any partner (consultancy) starts simply.

Enable the Flow to Manage the Activities

The degree to which this lifecycle is managed is inversely proportional to the likelihood of failure.  The simplest way to manage a lifecycle is shown above in the Deming diagram.  The idea is to implement the organic lifecycle flow and let the flow improve the subordinate activities.To accomplish this, we need to implement the flow with the associated roles.

Step 1 – Establish and Empower the BRM Role

The business relationship manager role usually exists in some tainted form.  We need to plug this role into the organic flow.  This role seeks to understand the needs of the business but, just as important, collaborates on those requirements throughout the service lifecycle.  As mentioned above, the BRM is critical to project initiation.

Step 2 – Establish and Empower the Enterprise Design Coordinator Role

The enterprise design coordinator is really the key to success.  There are three main tasks for this role.  Aside from coordinating design and build activities at a high level (not an application development manager), this role also a) ensures that the input from the BRM is adequate and b) ensures that the service design package is complete and accurate.

Step 3 – Establish Policies and Procedures for Transition Review

The release manager (hopefully already in place) will collaborate with the BRM, design coordinator and stakeholders to create policies and procedures for transition review.  The guiding principle for transition review should be that it examines service transition output (incidents, issue logs, metrics) to identify opportunities for process improvement.

Step 4 – Establish SIP Procedures

The output from the transition review will sometimes include a service improvement plan.  The organization needs a standardized procedure for initiating and implementing an SIP.

Step 5 – Do it and Keep Doing it

We have created the organic flow.  We only need to execute it.  Each SIP will improve the effectiveness of the service modification lifecycle.

Note on Change Management

Change management, from an enterprise perspective, plays a significant role in controlling the flow of the service lifecycle.  Most organizations perceive change management from an operational rather than an enterprise perspective – an outgrowth of legacy implementations of IT change requests.  This narrow focus deprives the organization of the true power of this governance process.  I would have enjoyed weaving into this article the benefits that a cohesive and integrated change management process could provide but it deserves a separate piece.

Conclusion

Release and deployment relies, for its success, on a number of upstream processes.  Business relationship management and design coordination, both new to ITIL v3 2011, are key to managing the upstream service lifecycle.  Though they may seem unfamiliar, everyone has implemented these processes to some degree but few have implemented them effectively.  This oversight poses a risk because any enterprise that does not consistently manage the entire lifecycle does not control the operational outcome.  In other words, every release is a roll of the dice.

Feeling lucky?

Pink14 Preview: Advice for making space for ITSM

caqrving
“Carve out some time for service management and make it a priority”

Ahead of his presentation at the 18th Pink Elephant Conference and Exhibition (PINK14), David Mainville, CEO and co-founder at Navvia, gives his advice on ‘making space for service management’.

Conferences like PINK14 are an amazing opportunity to network with your peers, learn new techniques and to re-ignite our passion for service management.

But you know what?  As motivating as conferences can be, the most important question is “what do you do with the passion once you get home”?  That’s the topic of my presentation at PINK14 entitled “Making Space for ITSM”.

So what do I mean by “making space”?

Well, if I’ve learned anything during my 30+ years in service management, I’ve learned that it takes practice and commitment.  Service management needs to become a part of the daily routine, of both the practitioner and of the company.

In fact, anything worth doing in life takes practice – whether it is learning to play an instrument, mastering a sport or getting in-shape – practice makes perfect.  The problem is that for many organizations and practitioners, service management is seen as a project and not as a practice.

Documenting a new change management process because of a recent catastrophic failure, implementing a new service management tool, or tweaking a process because of a bad audit finding, is often confused with a service management practice.   It’s not that these things are bad unto themselves; it’s just that it’s a bit shortsighted.

We come back from our conference all fired up, but all our great intentions are quickly overshadowed by firefighting and the daily demands of the job.  This noise gets in the way of a true practice.

Making space for service management means putting aside the time to do it right, and doing it right means following 5 critical steps.

The steps

  1. Carve out some time for service management and make it a priority.  In other words, there is a human element to the art of service management that can’t be ignored.
  2.  Develop a service management plan along with some short-term goals.  Many ITSM failures stem from either a lack of a plan or an overly grandiose one.  Focus on short term goals with measureable success criteria.
  3.  Build an alliance of co-workers because you can’t do service management alone.  If ITSM tools are the embodiment of a process, then people are the soul.  If you haven’t captured their support, ITSM will never succeed.
  4.  Create a structured and repeatable approach for implementing processes and tools.  You can’t be all over the map; you need something that works consistently for your first process and well as your last.
  5. Establish the discipline and governance to ensure an on-going program.  Building a process and implementing a tool is the easy work.  Accountability and buy-in is much harder – ensure you have management support and governance for your long-term program.

It’s been my experience, both as a practitioner, and as someone who practices service management in his own company, that following these steps is the best way to make real and lasting improvements.

Thanks and I look forward to seeing you at Pink!


David Mainville
David Mainville

To learn more find David at PINK14:

David will also be reprising the presentation for a webinar later in March.

Image credit

Assessment Criteria: Outside IT Product Review

In March of this year, we will be kicking off our product review dedicated to “Outside IT”, which will take a look at the use of ITSM technology outside the IT department.

lego

Overview

The aim of this review is to showcase best of breed ITSM software in use outside the IT department, highlight key competitive differentiators and provide readers of The ITSM Review with impartial market intelligence to enable informed purchasing decisions.

Previously published product reviews include:

Also coming soon: Proactive Problem Management.

Assessment Criteria 

The aim of the review is to support prospective buyers with their selection process by providing features to consider when selecting ITSM systems and highlighting key competitive differentiators between suppliers.

Outside IT – How can service management software, traditionally used to underpin the IT service desk, be applied to other area of the business to streamline operations and deliver more efficient services?

Main topics areas

  • How can new systems be built outside IT?
  • What expertise is required, what templates or processes are required?
  • How do end users / customers interact with the system?
  • How can engagement / interaction with customers be customized?
  • How are systems maintained – especially for non-IT users?

Solutions that do not include all of the criteria above will not necessarily score badly – the criteria simply define the scope of areas will be covered. The goal is to highlight strengths and identify differences, whilst placing every vendor in the best light possible. 

Please note: The assessment criteria are just a starting point; they tend to flux and evolve as we delve into solutions and discover unique features and leading edge innovation. Identifying key competitive differentiators is a higher priority than the assessment criteria.

Confirmed participants

Vendors who wish to participate in this Outside IT product review should contact us directly. We also welcome feedback from readers on their experience with their use of ITSM tools outside IT (although this feedback will not directly impact this review).

Image Credit

Problem management challenges and critical success factors

Following his presentation on “problem management challenges and critical success factors” at the 8th annual itSMF Estonia conference in December, Tõnu Vahtra, Head of Service Operations at Playtech (the world’s largest publicly-traded online gambling software supplier) gives us his advice on understanding problem management, steps to follow when implementing the process, and how to make it successful. 

Tõnu Vahtra
Tõnu Vahtra

Problem management is not a standalone process

Incident management and event management

It cannot exist without the incident management process and there is a strong correlation between incident management maturity and problem management efficiency/results. Incident management needs to ensure that problems are detected and properly documented (e.g. the basic incident management requirement that all requests need to be registered). Incident management works back-to-back with the event management process, if both of these processes are KPI managed then any anomalies in alarm or incident trends can be valuable input to problem management. Incident management also has to ensure that in parallel to restoring service during an incident it has to be ensured that relevant information is collected during or right after resolution (e.g. server memory dump before restart) so that there would be more information available to identify incident root cause(s).

Critical incident management

Problem management at Playtech gains a lot from the critical incident management function, which is carried out by dedicated Critical Incident Managers who have the widest logical understanding of all products and services and years of experience with solving critical incidents. They perform incident post mortem analysis following all major incidents, and they also start with initial root cause analysis (RCA) before handing this task over to problem management. RCA is handed over to Problem Managers within 24 hours from incident end time during which the Critical Incident Manager is collecting and organizing all information available about the incident. Critical Incident Managers usually do not have any problems with allocating support/troubleshooting resources from all support levels as critical incident troubleshooting and initial preventive measures are considered the highest priority within the mandate from highest corporate management. All the above ensures high quality input for problem management on a timely manner.

Change management and knowledge management

In Error Control phase the two most important processes for problem management are change management and knowledge management. Most action items identified during RCA are implemented through change management, the stronger the process the less problem management has to be involved directly in change planning (providing abstract goals VS concrete action plan or task list for implementation) and the smaller the risks of additional incidents during change implementation. Change management also needs to have the capability and documented process flow to implement emergency changes in an organized way with minimum impact to stop reoccurring critical incidents as fast as possible.

Knowledge management is vital for incident management for ensuring that service desk specialists would be able to quickly find and action specific workarounds for known errors until their resolution is still in progress by problem management. Regular input and high attention is needed from problem management to ensure that every stakeholder for known error database (KEDB) would be able to easily locate information relevant to his/her role, all units would be aware of information relevant to them and that all the information in KEDB would be relevant and up to date. In Playtech problem management is also managing process errors identified from root cause analysis and process improvements only last when properly documented, communicated to all relevant stakeholders and additional controls are put in place to detect deflections from optimal process. Local and cross-disciplinary knowledge management for process knowledge has an important role here.

Defect management

Problem management has to go beyond ITSM processes in a software development/services corporation like Playtech and also integrate to software development lifecycle (SDLC). For this purpose in Playtech a separate defect management sub-process has been established under problem management. Defect management is managing the lifecycle of all significant software defects identified from production environments and aligning defect fixing expectations between business and development departments. Defect Managers ensure a consistent prioritized overview of all significant outstanding software defects, which warrants optimal usage of development resources and minimizes overall business impact from defects. They act as a single point of contact for all defect related communication and ensure high transparency of defect fixing process and fix ETA’s. Defect Managers define the defect prioritization framework between business and development key stakeholders and govern the agreed targets.

Software problem management

Problem management is leading the software problem management process through defect management. Under the software problem management process (which is usually being ran by a quality assurance team in relevant development units) development teams are performing root cause analysis for defects highlighted for RCA by problem management or raised internally. Every defect is analyzed from two aspects: firstly why the defect was created by development and secondly if the defect was created then why was it not identified during internal QA and reported from production environment first. Root causes and action items are defined from both questions and tracked with relevant stakeholders. This process ensures that similar defects will not be created or will be identified internally in the future. Even more importantly there is a direct feedback channel from the field to the respective developer or team who created the defect so that they get full understanding of the business implications in relation to their activities.

Important steps to take problem management to the next level

The problem management unit has to become more proactive, to get more involved in service design and service transition phases to identify and eliminate problems before they reach production environments. Problem management needs resources to accommodate contributing to pre-production risk management and even more importantly this involvement has to be valued and enforced by corporate senior management as it may take additional resources and delay time-to-market in some situations.

The Problem Management Team itself can get more resources for proactive tasks by reducing their direct participation in reactive Problem management activities. This has to be done via advocating the Problem management mindset across the entire corporation (encouraging people to think in terms of cause and effect with the desire to understand issue causes and push their resolution for continuous improvement) so each major domain would have their Problem Coordinators and identify root causes/track action items independently and problem management could take more a defining and governing role. To assert the value created from problem management and enlist more people to spread the word about problem management ideas for them to go viral, it is essential to visualize the process and explain the relations between incidents, root causes and action items to all stakeholders for them to understand how their task is contributing to the bigger picture.

There is a high number of operationally independent problem management stakeholders in Playtech and implementing KPI framework that would be fit to measure and achieve problem management goals and be applicable to all major stakeholders individually and cross stakeholders seems almost impossible a task. The saying ”You get what you measure“ is very true in problem management and no stakeholder wants to be measured by problems that involves other stakeholders and are taking actions to remove such problems from their statistics instead of focusing on the problem and its solution. At the same time problem management tends to be most inefficient and difficult for problems spreading across multiple division. A Problem Manager’s role and assertiveness in facilitating a constructive and systematic process towards the resolution of such problems is crucial. And still problem management needs to find a creative approach to reflect such problems in KPI reports to present then as part of the big picture and sell them to executive management to get their sponsorship for major improvement tasks that compete with business development projects for the same resources while the latter has a much clearer ROI.

No problem exists in isolation and the problem records in KEDB can be related to specific categories/ domains and also related hierarchically to each other (there can be major principal problems that consist of smaller problems), also specific action items can contribute to the resolution of more than one problem. Problem categories cannot be restricted to fixed list as it can have multiple triggers and causes, it should be possible to relate a problem record to all interested stakeholders, for this dynamic tagging seems to be a better approach than limited number of categories (for example list of problems that are related to a big project). Instead of looking into each problem in isolation each problem should be approached and prioritized in the right context fully considering its implications and surroundings. No ITSM tool today provides the full capabilities for problem tagging or creating the mentioned relations without development, not to mention the visualization of such relations that would be a powerful tool in trend or WHAT-IF analysis and problem prioritization. Playtech is still looking for the most optimal problem categorization model and the tool that would enable the usage of such model.

Advice to organizations that are planning to start the implementation of the problem management process

For organizations starting the implementation of problem management process  my advice is don’t take all the process activities from the ITIL book and start blindly implementing them, this is not the way to start the implementation of this process or any other. Problem management success depends mostly on a specific mindset and in an already established organization it may take years for the right mindset to be universally accepted. Problem management formal process should be initially mostly invisible to all the stakeholders outside of the Problem Management Team to avoid the natural psychological tendency to resist change.

It is essential to allocate dedicated resources to problem management (Playtech assigned dedicated person to problem management in 2007, and any problem management activities prior to that were ad-hoc and non-consistent). The problem management unit should start from performing root cause analysis and removing the root causes of present major incidents that have the highest financial and reputational impact on the organization. If such incidents are being closely monitored by senior management and key stakeholders, solving them can earn the essential credits for problem management to get attention and resources for solving problems elsewhere. Secondly problem management should look at the most obvious reoccurring alarm and incident trends that result in a high support/maintenance cost. By resolving such problems they gain the trust of support and operational teams whose workload is reduced and they are more willing to contribute and cooperate in future root cause analysis. Problem final review before closure is a task often neglected but to improve the process it is essential to assess if the given problem was handled efficiently and to give feedback about problem solution to all relevant parties. Proactive problem management or KPI’s are not essential to start with and Problem Managers should concentrate on activities with highest exposure and clear value.

In summary

There will definitely be setbacks in problem management and in order to make a real difference with this process and increase the process maturity over time it has to have at least three things. A strong and assertive leader who is persistent in advocating the problem management; a continuous improvement mindset throughout the organization; and the ability to find a way forward from dead-end situations with out of the box thinking. When there is no such leader then involving external problem management experts may also help as a temporary measure to get the focus back on the most important activities. However, this measure is not sufficient in the long-term as the problem management process constantly needs to evolve with its organization and adjust with significant operational changes to be fit for purpose and remain relevant.

You can download Tõnu’s presentation in full here.

Coming Soon: The Battle of Change, Configuration and Release

wrestling
Let the battle begin!

We’re excited to be kicking off our research briefings next week for our competitive analysis on Change, Configuration and Release. Scheduled for publication in May, vendors confirmed to participate so far include:

The research will highlight competitive differentiators; feature key strengths (and weaknesses too of course); and showcase innovation within each product. Once reviewed, we will crown one Vendor “Best in Class” and the “leader” in Change, Configuration and Release.

Our research is based solely on responses to an in-depth questionnaire as well as a series of briefings, but we are always interested in hearing the end-user perspective.

Do you have experience with any of the participating Vendors? Do you have any views on their capabilities when it comes to Change, Configuration and Release? Are there any Vendors that you think are successful in this area who are not currently scheduled to participate in this review?

The review will be conducted by Rebecca Beach. For more information on the assessment view the Group Test criteria here. Vendors can still sign up to be involved up until Friday 31st January.

Subscribe to the ITSM Review newsletter or follow us on Twitter to receive a notification when the research is published.

Image Credit

Assessment Criteria – Change, Config and Release

Today we begin our competitive analysis of Change, Config and Release.  As with previous reviews our goal will be to highlight the key strengths, competitive differentiators and innovation in the industry.

Widely recognised as key to the successful preservation of production systems, the ITSM processes of Change, Config and Release are perceived as pivotal to maintaining the integrity and stability of the IT environment.

Flow diagram showing the five areas of Change, Config and Release.  These will not always be used in order and Auditing and Reporting should be ongoing.
Flow diagram showing the five areas of Change, Config and Release. These will not always be used in order and Auditing and Reporting should be ongoing.

In a nutshell:

Change Management is the process used to track and communicate any changes in service that may impact the customer such as when systems are taken offline for updates.

Configuration Management is the process used to track individual CI’s (Configuration Items) and the way in which they interact with one another.

Release Management is the process of managing software releases from development right through to release.

Each process can be used individually but more often than not you will find these processes intertwined.  When considering either a Change or Release you will need to know the CI’s that will be affected before you begin.

E.g: Your organisation needs to upgrade your in-house software package to all of its desktop pc’s, tablet devices and kiosks.

Release Management is used to track the in-house development of the software in question, Config management is used to scope the number of devices, number of people and types of people affected while Change Management is used to ensure the changes take place on a date that will cause the least disruption and that the why, how and when the changes will take place are communicated to the relevant people.

The criteria we will be using for our assessment is published below.


Identification

  • Ability to maintain a detailed record of each system’s configuration
  • Ability to interface with all internal Management Data Repositories (MDR) allowing the tool to compare reported configuration with actual configuration stored in the MDR
  • Ability to define dependency relationships between CIs
  • Ability to assign maintenance windows to CIs
  • Ability to auto discover CIs
  • Ability to interface with Inventory Control tools (to automate gathering of asset and inventory information) and barcode scanners
  • Ability to create automated alerts when a CI is found to be in an unauthorised state
  • Ability to link Release records to Change records
  • Ability to provide a Change/Release calendar with scheduled change viewing by group, and to customize the sorting and filtering of calendar views and link to existing calendar products

 Assessment/Approval

  • Calculate an objective risk assessment considering business impact and affected services
  • Show logical links between components included in a service in order to carry out business impact analysis
  • Ability to automatically create a Change Request when unauthorised changes are made to CI’s
  • Ability to schedule recurring events and maintenance
  • Ability to create and select pre-approved Change/Release from a pre-defined list
  • Pre-determined fields to auto-populate when Standard Change/Release from list used
  • Ability to capture the Change/Release date and time and who will be responsible for implementation
  • Ability to automatically send approval requests to the appropriate approvers
  • Ability to notify the assignee of the task and due date
  • Ability to link resources/approvers to Changes/Releases
  • Ability to assign tasks to individuals to be accomplished within specific time frames
  • Ability to alert Change/Release managers when approvals are past due
  • Ability to change status of Change/Release approvals
  • Ability to easily identify scheduling conflicts and reschedule appropriately

 Implementation

  • Ability to attach and store documentation with a Change/Release record
  • Ability to authorize and schedule Release deployments in conjunction with Change Management processes
  • Ability to change status of Release and linked Changes
  • Automatic notification for scheduled start/end and when the status of a Change associated with a Release changes
  • Ability to build, bundle and schedule different types of release packages for deployment
  • Ability to change status of Change/Release documentation
  • Ability to create sub activities or tasks for separate assignment to an individual, group or vendor
  • Ability to version release components and packages
  • Ability to assign tasks to teams/resolver groups

Accountability

  • Ability to track the physical location of contracts and agreements, and identify the individuals responsible for them
  • Ability to define Change and Release Windows (including freeze windows)
  • Ability to document back-out procedures
  • Ability to ensure that Release deployments are subject to scheduling and approval requirements managed by the Change management process
  • Ability to provide proactive notification to stakeholders and Change Advisory Board (CAB) members for Changes with critical business impact and provide fully configurable filtered views of scheduled changes to multiple stakeholders
  • Ability to designate back up approvers
  • Ability to set thresholds for automated approval process
  • History of approval requests logged

Auditing/Reporting

  • Ability to easily identify affected CIs whenever a change is made
  • Ability to maintain an audit trail of changes made to a CI
  • Ability to track Asset status and lifecycle management
  • Support of multiple software audit options
  • Ability to perform software license management including automated notification of license expiration and non-compliance
  • Ability to create and publish a Master Release Schedule
  • Ability to associate the Master Release Schedule with Service Level Agreement information
  • Ability to store approver comments with the approval, and store approval history for a Release
  • Ability to track and trace post deployment activities
  • Ability to trace implementation to the authorized version in the Document Management Library (DML)
  • Bulk import of licensing data
  • Ability to track costs of CI’s

General/Other Criteria

  • Alignment with industry frameworks
  • Ability to support a “virtual” CAB (i.e. approvals/issues stored electronically)
  • User-configurable forms, tables, workflows, dashboards
  • Role-based access for approvals, retracting or rescheduling RFC’s/Release
  • Open system for real-time integration with financial management and other monitoring tools
  • Provision of templates and pre-filled forms and structure to act as basic starting point
  • Vendors should provide expertise and guidance in the implementation of the tool and relevant processes

If you would like to comment on the above criteria or if you are a vendor and would like to be included in this review please comment below or contact me via email.

Service Catalogue 2013 Group Test – The Results

This is a review of software products and vendors in the ‘Service Catalogue’ market area.

This is a complex and varied market place and consideration should be given to the Market Overview section.


Download Review

(Free PDF, No Registration Required – 405kb, 8 Pages)


Service Catalogue 2013 Best in Class: Axios Systems
Service Catalogue 2013 Best in Class: Axios Systems

Service Catalogue 2013 Best in Class

  • Axios – scalable to big customized projects as well as nice UI for OOTB implementations. Strategic ITSM focus.

Of the other products reviewed, these areas were of particular note:

Best for MSPs and Small/Medium Organizations: 

Best for Enterprise Organizations:

  • ServiceNow – particularly for large implementations where customization is expected. Good product and corporate fit

Service Catalogue Market Overview

By Barclay Rae

Service Catalogue Approach

large ‘Service Catalogue’ market is a niche sub-set of the IT Service Management (ITSM) Software market, which has seen considerable interest and growth in recent years.

Whilst ‘Service Catalogue” can be given a clear definition, the term can be and often is used to cover a number of functional and strategic approaches that stretch from fairly low-level request fulfilment to strategic Service Design and Strategy.

This approach varies because there are several different components that can be described as ‘Service Catalogue” – from ‘front-end’ portal to ‘back-end’ workflow and high-level business views of services. There are also potentially a number of different inputs and outputs – and types of document – that can be described as part of the ‘Service Catalogue’.

This reflects the developing nature of how the industry has defined and understood what a ‘Service Catalogue’ is, which has led to some fundamental differences and interpretations of how to make this work and what the expectations are from implementation.

In a nutshell the 2 main different approaches are:

Strategic/Top Down

This is where the organisation takes a strategic view of all IT services – including the business services (applications/departmental services, external customer services). Usually this will lead to a definition of an overall service structure of Core IT Services (PCs, Phones, email etc.) and Business Services (departments, business processes, applications).

This can then drive service reporting and service differentiation and is a long-term strategic approach to ‘service’ management and value demonstration. Request fulfilment follows out of this process, once the overall structure has been defined.

Technical/Bottom Up

This tends to be started by technical teams to ‘discover’ services, solve specific configuration management and integration problems and provide a practical user interface for consumption of core services and request fulfilment.

Both approaches are viable and necessary at some point to lead to a successful implementation:

Top Down is useful to ensure that the whole IT organisation is on board and that the wider goals and expectations are defined as part of a customer engagement process. Visualisation is useful for all parties to have a tangible view of the overall goals for IT.

Bottom Up can be a good tactical approach to get moving quickly. Request Management automation usually provides efficiency benefits and can significantly improve service quality to customers. The strategic view will need to be defined at some point so should be considered whenever (and as soon as) possible.

For the purposes of this review both of the above approaches have been considered and the overall key elements for tools defined as follows:

  • General – user friendly and with proven integrations to other tools
  • Service Design – the ability to create a database of service records, containing a number of business and technical attributes, processes and workflows
  • Service Structure – the ability to organise and structure these services into a hierarchy of services and service offerings – ideally in a graphical format
  • User Request Portal – a user friendly portal with an intuitive interface to request and track services
  • Request Fulfilment – request management workflow and functionality that can be easily used and configured by system users
  • SLA and Event Management – the ability to define SLAs that can be linked via Event Management to other ITSM processes
  • Demand Management – the ability to provide real-time allocation and monitoring of service consumption, with e.g. financial calculations
  • Dashboard – real-time user-friendly graphical monitoring and analysis of usage, trends and metrics across services and to various stakeholders
  • 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

See the full list of criteria here

Approach to Implementation

Organisations and their practitioners who are considering buying and implementing Service Catalogue technology should consider the following:

  • As there are a number of potential applications and objectives for Service Catalogue, these must be clearly defined and agreed in advance. This shouldn’t be embarked upon because it is the ‘flavour of the month’ or it ‘looks like a good thing to do’.

Key benefits that can be derived:

    • Improved professionalism and quality of service experience to customers
    • Value demonstration of IT through business and service based reporting
    • Clarity around service differentiation and value – e.g. commodity versus quality, value-add, time to market
    • Improved cost efficiency of request management and administration
    • Improved quality and speed of service for request management and administration
    • Greater visibility of IT costs and service level performance
    • Improvement in Service Desk performance via better central access to information
  • It is vital that all participants not only understand the expected benefits and objectives, but are also clear on the taxonomy of Service Level Management. This saves considerable time during projects, due to the fact that there are often many misconceptions and variances in understanding around basic concepts like SLAs, Service Catalogue etc. Time spent on some explanations and clarification of definitions is time well spent.
  • The big mistake that orgnaisations still make is to try to do Service Level Management (Portfolio Management, Request Management, SLAs and Service Catalogue…) all without engaging with their customers and supported businesses. The process requires engagement (service definition, performance discussion, objective setting, feedback on the customer experience etc.) as a major input to this process. This provides business validation as well as improving the relationship and demonstration of understanding between parties. It also vitally provides clear goals in terms of service provision and performance reporting. Without this the process can completely miss out on customer requirements and expectation, and so is wasteful, arrogant and bad PR.
  • Organisations should define their services in a simple structure – ideally that can be visualised and shown on 1 page or 1 slide for clarity. This can be done in a workshop, where key people are brought together to work through the concepts and definitions (this can begin with some education) and then use this to define the service structure for that organisation. There are always ‘learning curves’ to be overcome (e.g. the distinction between ‘systems’ and ’services’) – however if this is done in a workshop then this build momentum and consensus.
  • The Service Structure is a vital element as it provides the visual key to this process and also then the framework for a repository of information on each service. From this the project can start to create other outputs, documentation and service views as required from the project goals.
  •  Getting started and moving is a vital element to avoid long term prevarication and too much theorising. A lot can be achieved relatively quickly with some workshops and brief customer meetings. It’s essential to produce a simple representation of the service structure that helps to visualise the process for all involved and give them a consistent view of what is being delivered and defined. All this can be done within a few days and weeks based around workshops and a clear set of objectives.
  • Ultimately this is a business-focussed process so it’s important to have people with business and communications skills to work on the project. Technical details and understanding will be needed but should not be the starting point, which tends to be what happens if this is given to technically-focussed people.

Market Products

Products in this area fall into 2 main categories:

  • Existing ITSM Toolsets with Service Catalogue functionality
  • Specific Tools with Service Catalogue and Request Management functionality

Existing ITSM Toolsets

These often will have either modular or intrinsic functionality based around the ‘ITIL’ framework – Incident, Request, Problem and Change Management, plus Asset and Configuration Management and Service Level Management.

The Service Catalogue should be a valuable addition to this with a ‘service layer’ that can be added to the existing task and event management functions, as well as providing customer/user-friendly portals and ‘front-ends’ for requesting and tracking services.

Generally these products will be used by organisations to develop and to implement a ‘service strategy’ – as well as implementing request management – so these will generally follow a more ‘top down’ approach.

Ideally these will be able to leverage work already down defining existing ITSM processes and the Service Catalogue can then easily integrate with these. This is not always the case, as previous configuration structures may need to be revised to meet new Service Structure requirements.

Specific Service Catalogue Tools

These are newer, standalone systems that have come into the market in the last few years – initially as there was little functionality in this area in the existing ITSM tool market.

They will generally follow a more technical ‘bottom up’ approach that provides faster and more agile implementations. So they can deliver high quality user interfaces, discovery and request management workflow in short timeframes and deliver fast Return on Investment (ROI)/Time to Value (TTV) around the automation of a number of manual processes that speed up the customer experience.

Challenges can include how to reverse-engineer these systems for a strategic service structure once in operation, plus the need to integrate with a variety of other tools, including the existing ITSM solution.

These tools all have some level of basic Help-desk/Incident Management and support processes – the level to which these can either be used or integrated depends on the requirements and maturity of the existing systems (and organisations)

Market Observations

  • ‘Service Catalogue’ is a term that can encompass a number of areas – request management, user portal, service strategy and design, SLAs, portfolio management, service reporting, customer, business and technical views. There is no single product or view that is definitive and products that focus on one area only will require some technical and process integration.
  • In key areas of request management, portals and workflow, reporting and SLAs, most products offer very similar functionality. Variations exist in the development of Demand Management, strategic Service Design and Service Visualisation.
  • In particular vendors can be differentiated by their approach – strategic and technical, but also the level to which they can offer support and value added services to help with implementation. This is still a relatively new area and few practitioners and/or organisations have broad experience or even clear requirements for how to make this work – vendor support and guidance is a key asset and differentiator.
  • Implementation support should also be in the form of template and standard configurable data – i.e. to provide sample service ‘bundles’, workflows, reports, dashboards and in general as much practical guidance as possible.
  • Whilst implementation approach and product focus are the key differentiators – i.e. strategic vs technical Bottom Up / Top Down – a key strength is also the ability to show a clear path that encompasses both approaches.
  • Integration experience and proven capability is a key capability (more than just a differentiator) – this will always be required to some extent:
  • For ‘Service Catalogue Specific’ vendors this is essential to get their product working with a variety of monitoring, asset and event management tools, as well as interfacing with other ITSM systems. Usually they will offer a number of existing APIs and proven links as part of their approach. These tools are useful for standalone Service Catalogue implementation at mid-market level and can also be found sold into enterprise organisations at the technical and integration level.
  • For ‘Existing ITSM Vendors’ they will lead on the seamless integration with their own tools. This is a good pitch for their existing customers but a dilemma for the wider market, i.e. whether to buy a standalone Service Catalogue product (from one ITSM Vendor) separately from a new or existing ITSM product from another ITSM vendor. Many of these vendors will have already created links to other systems via their multi-source and managed services clients.
  • In all aspects of this area, consideration should be given to the customer experience in using these systems and the interaction with IT organisations, particularly in terms of how SLAs and service delivery expectations are set.
  • These toolsets can help to improve service quality and experience, as well as improving the value demonstration of IT. However this will not simply be delivered by tool implementation alone and care is required where systems and vendors promise this without some significant process and organisational change.
  • Overall the market has developed significantly in the last 2/3 years although most vendors are still developing their approach to financial and demand management. Some of this functionality is available across the market but generally only as reports and with some development rather than as an integral feature for dynamic business use.  

Market Positioning and Approach

Vendor

Mid-Market

Enterprise

 

Top Down

 

Bottom Up

Axios

question

Matrix42

question

Biomni

question

ServiceNow

question

    – Definitely

question    – Possibly

Top Down / Bottom up?

Vendor

 

Top Down

 

Bottom Up

Axios

  • Approach geared to Business and Tech services
  • Good UI with visualisation of services and structure

question

  • Vendor and product can start from discovery approach
  • Unlikely to be sold as SC only bottom up product

Matrix42

  • Little product or vendor focus Business or Top Down approach
  • May not be relevant for some clients – e.g. MSPs

  • Product and vendor geared to discovery approach
  • Excellent tool for fast implementation of Request and self service for IT products

Biomni

  • Little product or vendor focus on Business or Top Down approach
  • Commercial approach helps for quick start and visualisation

  • Product and vendor geared to discovery approach
  • Excellent tool for fast implementation of Request and self service for IT products

ServiceNow

  • Approach geared to Business and Tech services
  • Good strategic focus in dashboards and Demand Management functions

  • Can start from discovery approach
  • Sales focus on enterprise with Business and Tech capability

    – Definitely

question   – Possibly

Competitive Overview

Vendor

Overview

Strengths

Weaknesses

Axios

  • High-end option for Medium – Enterprise
  • Simple intuitive UI/OOTB
  • Seamless integration with assyst ITSM processes
  • UI
  • Strategic approach
  • Vendor capability
  • Not geared up for standalone SC implementation
  • May be overkill for technical or small implementations

Matrix42

  • Strong request and Catalogue functionality – technical focus
  • Good option for Tech-only implementations (e.g. MSPs)
  • Good Request and Catalogue functionality
  • Speed of implementation – doesn’t need other ITSM processes
  • Service Now integration
  • Lack of US/UK coverage
  • Approach – little strategic implementation focus
  • Functionality gaps

Biomni

  • Good functionality
  • Nice commercial approach
  • Good option for Tech-only implementations (e.g. MSPs)
  • Good intuitive functionality, commercial approach
  • Speed of implementation – doesn’t need other ITSM processes
  • Little Strategic implementation focus
  • Functionality gaps

Service Now

  • High end functionality, enterprise focus
  • Strong corporate backing and growth
  • Extensive functionality
  • Best Demand dashboard functions
  • Flexibility of product
  • UI busy and complicated
  • Flexibility of product
  • Organisation geared towards enterprise clients
  • Needs usability configuration/customisation

Product Deep Dive

Follow the links for a deep dive review of Service Catalogue features:

Further Reading


DISCLAIMER, SCOPE & LIMITATIONS

The information contained in this review is based on sources and information believed to be accurate as of the time it was created. Therefore, the completeness and current accuracy of the information provided cannot be guaranteed. Readers should therefore use the contents of this review as a general guideline and not as the ultimate source of truth.

Similarly, this review is not based on rigorous and exhaustive technical study. The ITSM Review recommends that readers complete a thorough live evaluation before investing in technology.

This is a paid review. That is, the vendors included in this review paid to participate in exchange for all results and analysis being published free of charge without registration. For further information please read the ‘Group Tests’ section on our Disclosure page.