If you ask what a service desk is you might get any of these responses:
Okay the last one might be over-the-top cynical but the service desk/help desk can struggle to be valued outside of IT operations.
Thankfully, DevOps can help to change and improve this perspective by using the service desk as the pivot point between Dev, Ops, the business, and suppliers. DevOps is the cultural effort of getting Ops to see into the world of development and project teams, while also providing a mechanism for Dev and the project management office (PMO) to better understand the impact of change on production environments and, more importantly, on the customers.
So the service desk can be the lynchpin for how communication, collaboration, and the enhanced use of automation can enable technology to better support business processes and operations.
Think about what the business wants from IT:
So it is a lot more than just the delivery of new or improved technology.
Referring to the book “The Phoenix Project,” by Gene Kim et al, the authors talk of DevOps enablement through three principles or ways.
The First Way ensures the flow of technology (people, suppliers, processes, software, and infrastructure) to the business. In my opinion, many DevOps efforts fail because the concentration is on a flow from “idea” to “provided,” but successful DevOps needs to include a longer flow that includes support and review, in order to enhance future use.
The last thing corporate IT organizations want is a dissatisfied stakeholder or customer who looks elsewhere for technology services. But if companies do not consider the entire value stream, then a suitable analogy would be “The operation was a success, but it is a shame that the patient died.” So the service desk can help IT and the business to be prepared for whatever rate of change is going to occur.
The service desk knows what works and what doesn’t, the sort of issues most end users have, and how best to satisfy a customer. Their input early in the design phase can reduce or remove constraints related to non-development issues, such as having the right equipment available to use the new software, addressing licensing, or helping to train users. The flow is now from “idea” to “valued use” of a new feature, product, or service that retains and attracts customers.
The Phoenix Project’s Second Way is feedback and this is where the service desk can excel – as most of the work performed by the service desk results in feedback:
All of this and more can help IT react to issues and, more importantly, to proactively assess whether a new feature or product is worth the effort and cost.
The Third Way is continuous improvement, which means that we learn from our efforts and try something new. This step is not a report with actions that no one ever addresses, but is performed daily by all members of IT. Imagine if from the beginning of the “idea” to “go-live” lifecycle, the service desk:
Letting the service desk learn, create, and improve their capabilities will let the people, who are first to serve, be fully able to perform that function and, where necessary, gather feedback for improvement of the product.
Ultimately, the service desk is not just the “face of IT” – it is also its eyes, ears, and mouth. Everyone in the organization, even IT, uses it to help solve issues or request equipment or software. The service desk therefore knows the “truth” about IT – the good and the bad, from features and products to customers and suppliers – and can add value by sharing this information early in the design lifecycle.
So DevOps and the service desk should be a perfect fit. How is your organization’s DevOps activities involving and exploiting service desk capabilities?