The promise of IT service management is to deliver services that make sense to their business users. To do that, though, IT departments must be able to untangle their own internal resources.
IT services must be accessible in one place so that users can find them easily and administrators can manage them. And the back-end applications that support those services must themselves be easy to manage and clearly identifiable.
Sounds simple enough, right? Unfortunately, that is not the situation facing many IT departments today.
Employees can access services via a bewildering array of touchpoints, and admins are grappling with a spaghetti mix of applications at the back end. Both of these layers of complexity makes it difficult to offer the streamlined services that users are looking for.
How did we get here, and how can we change it?
Consolidating front-end services can help an IT department to present a more uniform experience to business users.
Service desks are one example. They can develop independently, sprouting up alongside application projects and IT service lines, having been developed by different teams.
The result can be confusing for end-users and create problems at the IT level. The IT department can haemorrhage budgets as service desks have to spend on extra staff to duplicate functions and multiple software licences.
Fragmented service desks can also hamper a department’s ability to deliver quality services for employees, especially when information about services needs to be shared.
It can also be difficult for service desk staff who don’t have a full view of all the back-end IT systems and processes to understand what may be causing a particular problem.
IT departments may find it more appropriate to consolidate service desks, providing a single one-stop shop across different products and service lines, no matter what business function or IT product they are related to.
Technical teams can contribute to a single knowledge base, rather than forcing users into a lucky dip of help areas
Consolidation means technical teams can contribute to a single, searchable knowledge base, rather than forcing users into a lucky dip of help areas, in which service staff may have created different workarounds for the same issues.
Ostensibly, this might seem to be a simple case of exporting service tickets and knowledge base data into a common repository, and then using only as many employees as necessary to staff it. In practice, though, there are more considerations.
Process consolidation is a case in point. Many processes distributed around the different service desks may duplicate each other and be handled differently. This is the time to rationalise them, producing a single, integrated approach.
Many manual processes can be automated to reduce the workload for staff and produce a consistent, error-free experience for end-users. Many of the steps underpinning a service upgrade, for example, can be handled without human intervention.
Integrating the service desk with other IT processes is crucial. IT departments should integrate service desk software with systems handling change and configuration management so that a series of events can be triggered via a command from the service desk agent.
Run book automation (RBA) can be a useful way to condense process consolidation and automation into a single system. IT staff can code service processes directly into workflows in a RBA system.
All this consolidation of end-user services will get an IT department only so far, though. It will drive efficiencies for sure, but an IT department will experience problems if it tries to layer a service-based culture on top of a pieced-together set of IT systems.
Just like a zipper, the whole infrastructure hangs together more tightly the more you pull it together.
IT departments grow organically over time. Different teams and political regimes implement different applications, and all too often they don't communicate with each other.
These applications can overlap each other's functions and end up running on different hardware and operating system configurations. This leads to several problems.
The obvious one is cost. Maintaining a broad array of back-end systems without standardisation can be a drain on budget, especially as those systems begin to age and support becomes harder to find.
Staff can find themselves spending more time on massaging legacy software to keep it functional than they do working on IT innovations to make the department more efficient.
Legacy hardware and software also tend to be fairly rigid. Older applications may not be customisable and are unlikely to support modern computing concepts such as mobility, open APIs for data exchange and the like.
Those responsible for developing or configuring them may have long since left, making the legacy systems, and the services they support, difficult to improve.
How can you best consolidate these systems to create a more streamlined set of IT resources to support services for your end-users? We can break it into three broad steps: analysis, retirement and rationalisation.
Start by baselining what you already have. Assess your portfolio to understand which category each piece of software is in – whether it is commercial, off the shelf or custom software.
A critical facet of your back-end software is its business value. Describe what the software does by detailing the business processes it supports. Develop categories under which different applications of similar functionality can be grouped.
What is the return on investment from this software today, and what would it be if it were modernised?
On the flip side, consider the cost of the application as it stands, pre-consolidation. How much does it cost to maintain and operate? What are the licensing fees for the application?
How much could be saved it if was replaced with something new, running on modern operating systems and hardware? How much could it contribute to hardware savings if it was virtualised, and is that possible in its current form?
Does the application as it stands prevent you from enhancing a business process in ways that would tangibly benefit the departments that rely upon that process?
During this phase, you can also examine the risk of consolidating the application. If it forms part of a mission-critical set of resources, then aspects such as the size and complexity of the code may be important.
Quantifying the likelihood of service disruptions and their impact on the business can help you when considering the consolidation of particular software assets.
In or out?
Armed with this information, the IT department can make smarter decisions about which applications to retire and which to keep. This is a good time to explore different application categories.
Will all applications in a particular category be replaced by a single, newer one? Will some applications remain and must they be reconfigured in any way?
At this point, it is also worth considering application integration. Which applications should integrate with each other and how? Is there an opportunity to break down silos and share information to make IT services more effective for end-users?
Then comes the consolidation process. Planners can develop a roadmap for each application in each category, so that implementation teams know what will be affected at various stages of the process.
The end result should be a single service desk that can serve different types of users, both internal and external. It should be able to trigger events across a smaller, streamlined portfolio of applications that have been brought together with business-facing IT services in mind.
It all sounds great in HTML format, but naturally it will be harder to do in practice. This is likely to be one of those IT projects that happens incrementally.
But the more resources can be consolidated, the less burdensome the back-end application architecture will be and the more focused the IT services culture can become. ®