What does “digital” mean to service management? – A trilogy (part 2)

In the 2nd blog of our trilogy, Simon Dorst and Michelle Major-Goldsmith will follow on with the conversation about the impacts of ‘digital’ for service management practitioners.

In our first blog we looked at the impacts of digitisation on businesses and the change in focus, transforming the business of ‘doing business’. We wanted to consider what that means for the future of the best practices we know and love, those emerging and how each is evolving to respond to this changing business landscape.

There are certainly more and more practices and frameworks appearing (a ‘framework frenzy’) and each claims to support service management activities in the digital age. In this part, we will consider some of the widely known and used ‘best practice’ approaches for service management.

You cannot ignore ITIL®

Whether you love it or loathe it, ITIL has arguably been the ‘de-facto’ approach to IT service management for over thirty years. Its popularity has permeated in training and certification requirements, in the structure of service management supporting toolsets and common language used in the industry.

The most recent release comes from 2019 … ITIL 4. Note that the 4 does not stand for the version (so, it’s NOT ITIL v4) but is a direct reference to the 4th industrial revolution. ITIL really had not had much of a shake up since 2007 when ITIL v3 was released, and its popularity and perceived relevance has seen a steady decline since, with the emergence of Agile, DevOps and others (which we will discuss later).

ITIL 4 builds on all the best things from ITIL (the processes) and expands into other, non-IT areas to provide a much broader approach to service management (which is welcomed). It also looks at (and tries to incorporate) other best practices, such as DevOps, SIAM™, Cynefin™, agile practice and contains more on some of the ‘softer skills’ needed by a modern service management practitioner.

There is too, what seems like a superficial, semantic reinvention of existing concepts, like the introduction of the 4 dimensions of service management to replace the 4 Ps (People-Process-Product-Partners). And whilst the alliteration is gone, each of the traditional ‘Ps’ are back.

  • People has become Organisations & people, addressing organisational structures, culture, shared values, leadership and the like
  • Process is now Value streams & processes, with more of a focus on the outcomes and value rather than the documentation and activities involved
  • Partners are Partners & suppliers, and we are happy to see that a lot of the SIAM Bodies of Knowledge has found its way into ITIL 4 here to address the complexity of multi-provider environments needing integration and collaboration beyond just a contract (as well as the inclusion of both external AND internal service providers)
  • And Products can roughly be equated to Information & technology, where concepts around information security and new technology are being introduced, which are so critical to organisations these days.


So, perhaps not a fundamental change, but certainly a renewed and increased focus on these aspects of a service management organisation, which previously perhaps have been somewhat overlooked (… until it was too late and they became an obstacle or blocker for success).

Another change is the ITIL v3 service lifecycle, which was seemingly aligned to the software development lifecycle, or even project management cycles. There was a logical progression from Strategy to Design, via Transition into Operation and with Continual Service Improvement. Each publication in ITIL v3 described one of these lifecycle phases and the processes included within.

However, in practice, this was also the cause of some of the shortcomings, whereby people only focussed on one or some of the stages (mainly Operation and Transition) and then also only on the processes described within those, whilst other processes were neglected or even ignored (for instance service level management, included in Service Design, plays an important role in both Transition and Operation; or change management, mentioned as part of Service Transition, is applicable to every stage of the service lifecycle).

This lifecycle has now been replaced by a more dynamic Service Value Chain (SVC), which describes a number of activities that take place between demand for and the delivery of products & services that create value. And whilst the activities of Plan – Engage – Design & Transition – Obtain/Build – Deliver & Support and Improve have a certain similarity to the old service lifecycle, the new ITIL 4 theory explains that there is no particular order in these activities.  

 

Each activity can happen at any time, or even simultaneously.  When PLANning, you need to ENGAGE with stakeholders, before completing a DESIGN.  But in SUPPORT you would ENGAGE with the users to identify IMPROVEments which can then be PLANned etc.  This way the asynchronous service value chain provides a more flexible structure to work within, and is more aligned to the agile working methods found in digital organisations.

Most people will recognise ITIL for the well-known but much maligned processes.  The processes were in ITIL v3 positioned within the service lifecycle phases.  Not only was this restrictive, but often processes were defined to an almost prescriptive level, through flowcharts, procedures and work instructions.  This was never the intention of ITIL, to work at such a prescriptive level, and we have often remonstrated how for instance ITIL and Agile can perfectly work together as both are after the same thing: the best value outcome for the business, but this requires a situational approach, different between different organisation or even between different change ‘types’.

So, to kind of reboot this concept ITIL 4 has now renamed the processes into practices.  On the face of it, this is just another semantic change, but combined with the more flexible service value chain, there is now the option (or intent) to apply any practice, in any activity, in any way … so there is no one way to do incident management, but each team, during each activity can apply this practice to achieve a quick restoration of service.  This is a far more flexible and practical application of the theory.

ITIL 4 has expanded the number of practices to 34 (up from about 26 processes in ITIL v3) divided into 3 categories, including 14 general management practices, which are taken from general practice and adapted for a service management environment.  Here we find some practices that previously were missing, like risk management, workforce management or organisational change management.  And this gives ITIL 4 a much broader relevance, beyond just IT operations.

Kind of new in ITIL 4 are the Guiding Principles, although if you read the ITIL Practitioner guidance they will be familiar.  As the word ‘principles’ implies, these are recommendations that guide an organisation, or an individual, in their actions.  These principles are for instance ‘focus on value’ or ‘start where you are’.  There are somewhat akin to values in organisation’s vision.  And whilst that makes them perhaps ‘motherhood statements’, they are still important principles for staff to know and to apply when doing service management.  And they are now specifically mentioned in ITIL 4.

But just like the 4 Ps, the processes and the lifecycle, these common-sense concepts have been dusted off, updated and now are an integral part of the ITIL 4 best practice guidance, ready for the challenge of service management in a digital age.  As further ITIL 4 publications are made available, ITIL expands the service management practice by incorporating terms and concepts like, safety culture, Toyota Kata, developing at pace, creating resilient operation etc.  So, ITIL has certainly cast the net wide in terms of including many practices and principles, some of which are even older than ITIL itself!

In the most part, we feel it is a welcome change, ITIL has dropped its sometimes restrictive process and lifecycle shackles and replaced them with a framework that offers so much more guidance.  However, the broader scope, more generic guidance and incorporation of many other practices, may for some be a bridge too far.  Some are lamenting the loss of their defined RACI models and process flows, and have concerns that their investments in training, tooling and documentation in the subject no longer provides the more specific information on options for a service desk, prioritisation matrixes, change categories and so on.

I guess, it’s a case of ‘watching this space’ as the ITIL guidance is made fully available (and adopted by organisations).

The C-suite’s favourite – make it agile!

The word on the lips of every C-suiter is ‘agile’ … or is it Agile? Well, there is a difference: upper case Agile is an approach to software development and project management, and thus, something we do. Lower case agile is an adjective about moving quickly and easily, and is more about who we are, an agile organisation for example.

Agile (with a capital), like DevOps, uses and is built on Lean techniques from the manufacturing sector.  In 2001, the Agile Manifesto was published which encapsulates the four values and twelve guiding principles for Agile.

One issue with Agile is that there is no one way of doing Agile. There is Scrum, or DSDM, or even Kanban or Kaizen.  And then there is Agile project management or Agile service management, all governed by different organisations, which means that there is no real common language, or certification, across organisations and tools. Then again, concept like sprints, minimum viable products (MVP) or Work-In-Progress (WIP) boards are now embedded into many working practices (including ITIL 4).

There is no doubt that Agile techniques are immensely helpful, as is a DevOps culture, especially now we can more easily embed them within the structure of the ITIL 4 Service Value Chain and the practices like change enablement.

Remove the ‘waste’

And then there is LEAN, which does what it says: it makes things leaner; less of this or eliminate that. The key word in LEAN is ‘waste’, but there is a focus or at least an understanding of quality or value (so that you don’t remove things that are important). This of course fits mostly into the improvement area, or within automation and thus concepts like continuous integration and delivery within DevOps environments (CI/CD).

This means that LEAN is another practice which brings something valuable to a modern service management organisation, almost ‘on top of’ the ITIL structured practices, the DevOps culture and the Agile approaches …

Integrate this mess!

We need to integrate these practice and Service Integration and Management (or SIAM) might be just the way to do this.

When we wrote the AXELOS white paper back in 2015 we coined a phrase we have been using ever since “SIAM is an evolution of how to apply a framework for integrated service management across multiple service providers”. It has developed as organisations have moved away from outsourced contracts with a single supplier to an environment with multiple service providers, who each contribute their own expertise, in their own way. SIAM has evolved from the challenges associated with these more complex operating models.

If we take ITIL as an example, that started, back in the last century, mainly focussed on service management by an internal IT department. And whilst it has added the commercial external provider aspects and things like supplier management in v2 and v3, it never really focussed on the challenges of cross-functional, cross-process, and cross-provider integration, nor the required collaboration and culture needed in a SIAM ecosystem. Of course, ITIL 4 is more aware of this and in fact in the ‘partner & supplier’ dimension and the supplier management practice there is reference to SIAM, and many of the same language as used in the SIAM Bodies of Knowledge has been included.

SIAM adds an organisational structure of necessary functions required to manage the relationships with the various providers and consumers. This structure of roles and responsibilities is mostly missing in other practices, which mainly focus on activities that need to be performed and not necessarily by who (or under whose control).

On the left you can see the basic SIAM structure, the key picture of SIAM … simple but quite telling, showing the three levels of a SIAM environment. In the middle, the service integrator introduces the concept of a single, logical entity held accountable for the end to end delivery of services and the business value that the customer receives. The service integrator is independent from the customer organisation’s retained capabilities

It has been acknowledged in other practices too, but certainly for SIAM, there is a shift in the skillset required in such complex models. There may be less technology in IT (or more ubiquitous), but the ‘I’ for information is more complex and more important than ever. The modern-day IT(SM) professional will be working in an environment with multi-functional teams, multiple providers, horizontal layering, vertical silos, consumers expecting it to ‘just work’ and customers looking for agility and stability.

Working within such an ecosystem, soft skills such as negotiation and influencing are important as too are a commercial awareness. The wish is for the various parties within the model to have a ’one team’ focus and learning that is educated and developed, rather than told and coerced.

It seems all so disparate …

Of course, this potentially leaves us with a bag of things. With all of these practices, how do we navigate them? Each practice has their own techniques, tools, documentation and supporters in an organisation, often with nothing connecting them to help make them work together.

In the final of our blogs in this trilogy, we will offer you some guidance to help tackle this challenge. We will look in more detail at VeriSM™, which was introduced in 2018 with its promise to provide ‘service management for the digital age’.
So, please join us again for the final blog in this series, where we will further reconsider the future of service management and the various new tools available for our toolbox.

About the authors

Michelle Major-Goldsmith
Simon Dorst

With a combined experience of over 50 years in service management, Michelle Major-Goldsmith and Simon Dorst are well known in the industry. They are Lead Architects for the Scopism Service Integration and Management Professional Body of Knowledge (BoK) and founder members of the SIAM Foundation BoK architect team, as well as Subject Matter Experts for both EXIN and BCS in developing the accreditation around this. The team was awarded Thought Leaders of the Year at the Professional Service Management Awards by the itSMF UK (in 2017). Both have been an active committee member of various service management groups and forums for many years, including the itSMF in WA. They shared the award of ITSM Thought Leader of the Year in 2018 and were both the Service Management Champion of the Year (Michelle in 2017, Simon in 2018) from itSMF Australia. Michelle was also awarded HDIs Top 25 Thought Leaders in Technical Support and Service Management for 2020.

Related Posts…

Share this posts…

Share on facebook
Share on twitter
Share on linkedin