Once you have decided that you want to take control of your IT department, the big question is how to organize this and where to start. Various frameworks such as ITIL and BiSL provide guidance, but none of these frameworks offer a working methodology for everyday practice. How do you translate these principles into a working whole without creating enormous bureaucracy and becoming too rigid?
Organizations often try to capture the jungle of procedures and agreements in process descriptions. Many network drives and SharePoint sites contain dozens of process descriptions that took months to develop. The processes that have been drawn up via ISO9001, for example, are also neatly stored in a folder. But the sad result is that no one reads them, especially when there is an urgent problem to be solved. Work agreements only come to life when you organize and facilitate them. But how do you organize that?
It starts with the rigorous decision to automate all support processes relating to incidents and changes and transfer them to a good call registration system (CRS). All work agreements and procedures are recorded in this system, including all contractual agreements with suppliers. The CRS is the central hub where everything comes together and where incidents, changes, and escalations are processed and monitored. To facilitate this, work is underway to design the right information flows that tell employees in the primary process what is happening with their call. The right management information is also created, enabling the organization to steer the process.
This all sounds reasonably logical, and many IT organizations probably believe they are already doing this. Let me first explain why I used the word "rigorous" above. In practice, we often find that although a CRS is in place, the surrounding work processes are not linked, which means that coherent monitoring is not possible. Calls get stuck and it is unclear what the status is. It is also unclear who is responsible. And if no progress is made, it often goes unnoticed. How do you break through this impasse?
The secret lies in the rollout of the management framework devised by Transitieprofs. This is explained in the figure below.
As mentioned, everything starts with effective call registration and handling. The central core of the control model is therefore the CRS (1). All processes are controlled from here and all agreements are secured.
The CRS manages the connections (2) with the internal management organization and the chain partner. Both functional (5) and technical (6) management are controlled by internal and external SLAs and OLAs (7 + 8). The agreements contained therein are translated into the configuration of the CRS, so that support staff know exactly who is responsible for what and what needs to be done to move calls forward.
Work processes can be modified, or new processes can be added. The innovation body (3) and the change body (4) play an important role in this regard. The innovation body examines how and whether the services provided are in line with the organization's objectives and what conditions must be met to achieve this. The services, architecture, and partner model are the subjects of discussion. The board or management is also represented in this body to ensure that the correct mandate is in place.
The change body assesses operational changes and problems that arise and distills the necessary adjustments to take service provision to a higher level. Within the financial and functional frameworks set by the innovation body, the change body is mandated to implement changes.
The introduction of this model also deals a blow to a new governance model. Everyone knows what they are responsible for and has the right resources to actually resolve calls. What's more, the calls are reports based on services that users recognize, and users are able to assess them on an ongoing basis. The innovation and change bodies often do not yet exist and, once established, make a difference by learning to work strategically on the basis of good management information, ownership, and properly configured tooling. The user experience is always central to this.
This explanation is an introduction to our well-proven model. In practice, there are many more dependencies and details to properly apply and secure this model.
Want to learn more about how our model can help your organization and where to start?
Author: Martijn Stekelenburg
