Making ITSM the Customer Interface to DevOps

01/11/2017 by: The SunView Team

The average IT service management (ITSM)-espoused corporate IT service desk hopefully has deep expertise in dealing with internal IT customers and the IT they use, plus a reasonable knowledge of the business as a whole. On the back of these it has three roles to play in the all-important communication aspects of DevOps.

Firstly, as the service desk is a fountain of knowledge on how the main corporate systems work, it can contribute to the DevOps "first way" - systems thinking. Secondly, the service desk knows the truth about how internal customers perceive various IT products or services, which contributes to the "second way" - amplified feedback loops. And thirdly, in terms of the DevOps "third way," involving the service desk in continuous improvement through experimentation and learning will free them up from the drudgery of password resets and asking the user "Have you tried turning it off and on again?".

So let's look at each of the following in more detail:

  • The first way - systems thinking with the service desk
  • The second way - the service desk amplifies feedback
  • The third way - continuous improvement through experimentation and learning.

Each of which allows the service desk to act as a customer interface for DevOps.

Systems Thinking with the Service Desk

The first way of DevOps is a culture of "systems thinking," focusing on a collective mission and avoiding local (sub)optimizations that hurt the desired end state: customer success and demonstrable value.

Including the service desk as part of the DevOps "ways" is beneficial in both directions:

  • The service desk has access to insights into how systems are built and released which improves its understanding ability to feedback guidance, inbound to the value stream, as to what is best from the customer perspective.
  • With more insight into the system the service desk will have better outbound interactions with the customer because they will have more useful information to hand rather than waiting for handoffs or meetings to get that information.

In essence, the service desk can extend the systems thinking into the customer realm in a controlled and measured manner for production systems, much like customer feedback meetings happen during agile development.

The Service Desk Amplifies Feedback

With DevOps, the service desk should have a new role working with both developers and IT operations when a product is in production. Through their interactions with customers and the system as a whole, they have a unique perspective and the ability to amplify the feedback they see.

As the front-line interface to customers the service desk can enhance events such as outages and A/B testing by providing human feedback to complement automated metrics. DevOps has a number of leading indicators that are used to ensure quality is built into the product as it moves through the value stream. Lagging indicators are used once the product is live and the service desk should be responsible for amplifying these back into the DevOps loop. Examples include:

  • Failing customer payments
  • Increasing queue sizes
  • Disconnected customers

A useful way for developers and service desk to work together here is to use A/B testing. By only releasing new features to a small subset of end users, or customers, and checking for changes in lagging indicators, then the change if detrimental can be quickly backed out with minimal impact to the overall customer base.

Continuous Improvement Through Experimentation and Learning

The service desk shouldn't be a team that's purely reactive. Things should not only be "done to them," the service desk should instead be proactively involved in the loop of experimentation and learning. Through their contact with customers, and unique perspective of the system and the feedback loop, the service desk potentially has great ideas and opportunities for improving the system. So they should definitely be feeding in ideas to user stories and other development inputs that enrich DevOps.

For instance, using service desk metrics it would be easy to spot that the number one reason for calling the service desk is - universally - changing a password (unless an organization has introduced an automated self-service password reset capability). End users complain about this, it costs the service desk valuable time (which could be better used elsewhere) and the business money, and it's a strange missing feature in the era of cloud and self-service.

Armed with customer feedback and their metrics the service desk should not only push the prioritization of getting a self-service password reset feature added, they should also be involved in its conception, design, testing, and release. This is the best way to ensure that the released feature is "right first time," saving the company money and making customers happier.

So getting the service desk to be a part of DevOps is a crucial organizational strategy for any company wanting to become a high performing organization, especially when measured by customer satisfaction. And thus the unfortunate present-day scenarios where the service desk being staffed by junior people, poorly supported by the rest of the business, and in the firing line of customers' needs to be consigned to the past. It's a real opportunity to create a 21st century service desk as the customer interface to the new DevOps ways.

Ready to try ChangeGear for yourself?

Get Started

| IT Service Management