Many smaller IT teams are suffering as the tasks they are working become increasingly complex. Only a decade ago, the “IT guys” could manage all network features alone. Today, faced with tasks such as managing the mail server or whole clusters of servers, people become more and more specialists. Many teams have evolved into a unified group of specialists with no one in a position to stand in for others. Simultaneously running IT involves an increasing number of different tasks, which all have to be managed properly. IT staff needs the right strategies to work out ways for the existing team to deliver the right IT services as smoothly and ergonomically as possible. A method called Shift Left involves passing tasks from the key expert to other team members. It is based on documentation and knowledge sharing. The Steinbeis Consulting Center for IT Service Management supported a medium-sized company with the introduction of the method.
Apart from task sharing, communication plays a pivotal role in making IT services easier to use and gaining more acceptance. Malfunctions, updates and new systems have a simultaneous impact within many IT systems simply because of mutual dependencies. So to manage a crisis, good team work is essential. But quick help is not about trying to sidestep an issue or pass the problem on to someone else, clear processes are needed with the right documentation of planned and completed maintenance work.
Looking at the list of alternatives, it is apparent that clearly defined systems are needed and a “clear deck,” even if one alternative would be to outsource the IT service desk to a third party. The medium-size company Steinbeis was working with decided to find a solution within the existing team. This was because the queries and faults users were reporting to IT were some of the most useful indicators of how to manage the IT. Shifting activities to a third-party provider would have meant no longer having direct access to these insights.
Wich one of the existing frameworks – COBIT, ITIL, CMMI or ISO 20000 – is helpful in this respect? And would it be scalable, to any sensible degree, to small teams? In general, if there is “good practice” for small IT teams in companies, what is it? And how can a team acquire the right knowledge, without being overcharged when resources are already tight? The established goals would need a complete overhaul of IT and that could not be achieved by simply installing new software on the service desk. Rather, changes would be needed on several levels. An alignment of the IT strategy with the overall business strategy would only be possible by putting control mechanisms in place. But to do this, day-to-day operations would have to shift from being purely reactive to being a proactive process.
Gerburg Joos-Braun, director of the Steinbeis Consulting Center for IT Service Management, introduced agile methods for the project to involve team members in the process from the outset, with all their different points of view. This was also to gain the necessary acceptance for the changes that would come. A number of key factors were central to securing the long-term and sustainable success of the project:
A team has to work out a commitment to any features that are going to be introduced. The effort invested at this point means that team members have to clearly become more proactive and motivated to share in identified solutions.
The question is: where to start? Once Gerburg Joos-Braun had defined the broad brushstrokes of the solution with her customers, the first step was to map out existing processes with team members. These were specified using a technique caked “business process model and notation” (BPMN). Processes were captured in a uniform format. Meanwhile, there was a dummy run and the kinds of questions that could be expected were evaluated, thus laying the technical foundations for the software selection process.
Irrespective of the actual software system selected, it is crucial to carefully consider how this software is introduced to the company, so the ability of the software to adapt to customization needs is an important criteria. The IT team helps designing the system and make it their own tool. To achieve desired results in terms of knowledge sharing and substitution, the aim should be to integrate all “sub-lists” into the system as well as standardization of communication with users and administration procedures. In practice, many of the adaptations that are needed only arise when systems go live, so it was useful that an SaaS solution based on Web 2.0 was chosen with parallel test entity to allow the system to develop “on the go.”
The centerpiece of a service desk solution is the configuration management database (CMDB), which must make all the information available needed to map out 80% of the most important processes. The setup of the CMDB, with the items in the IT infrastructure and the organizational data of the company, provides a basis for incident management. A clear strategy for availability and procedures for the IT staff serving as single point of contact as well as information on the immanent system change is needed before going live with system.
During the subsequent adaptation stage, the development achievement was done with the team. Questions from the team, as well as errors and requests for further functionalities were captured in “user stories” on cards, pinned up on a project board, which were then checked and worked through. After these had been approved in the test system, they could be adopted in the real system. This made progress transparent and comprehensible for everyone involved. Even during the turbulent stage of change management, during which many features have to be implemented in parallel, this mapping process helped specialists maintain an overview.
During the launch phase, those affected by the integrated design became participants. The support provided by the system related closely to live procedures, something the team members witnessed bit by bit in their everyday work. Validation of the goals was conducted continuously by using the advantages of the flexible architecture to monitor replies from the team during the actual development process. Within 12 weeks, the CMDB had been put in place, complete with automatic data updates, incident management, change management, service requests (including a service catalog) and a new knowledge management system. Several third-party service providers were also integrated into processes as well as their ticket systems. Many routine tasks have now been totally simplified with clear processes underpinned by workflows. The whole team has access to all fault and error information. Data needed for everyday operations helps provide tools for controlling the system and planning strategic IT priorities. Later down the line, the system can be used to develop an internal portal to provide users with online information regarding questions or information from the knowledge database, all on a self-serve basis.