The majority of processes are informal with no formal description in place. Every IT employee proceeds ad hoc and results differ based on who executes the task. 

The processes are usually defined by managers. Their main goal is to reduce mistakes of less trained employees. Teams are generally more concentrated on following rules instead of achieving results. Some processes are  overcomplicated to execute. Employees sometimes find it easier to bypass the formal process. 

Processes are not bypassed but they are set up in a way that supports business goals and values. A human centric approach is applied in the sense of UX Happy Path. Employees are keen on suggesting improvements  to existing processes based on their practical experiences.

We rarely follow new practices or approaches. The team is rigid, and people only follow established processes. The most common justification of the above is: “That is what we have always been doing.”   

The board is constantly trying to stabilize our practices. Some members are actively looking for new trends as well as  best practices suitable for us. Subsequently, they try to implement it into the team or at least to their own agenda. Sometimes, we manage to implement a change, but it requires a lot of effort.  

Both management and employees comprehend what areas require strict process management and which allow for more a relaxed approach. The team is aware of the importance of keeping high velocity and so the focus is also on staying agile. Managers and employees aim to follow global trends and ensure its  practical execution in the team via projects (e.g., implementation of Scrum, DevOps, ITIL4).   

Almost everything is done manually or in spreadsheets. However, some of our tasks are automated into batches which update relevant databases and perform certain operations.  

We have several IT systems in operation which makes things a little easier. Some of the routine steps are fully automatedd and robotized. Nevertheless, the actual benefits are far beneath the level we originally aimed for.  

Our IT stack is almost entirely automated with a small staff footprint. This setting helps us to concentrate on what makes our company distinctive. Most of our requests are highly automated with very little human involvement. There are certain tasks requiring human involvement, but the main attention is on customer service and assistance with a self-service portal.   

We do not operate any series of standalone systems such as several diverse Help Desks. It is difficult for users to check a current status of their requests. There is no existing audit trail concerning resolution of past issues, approvals and business decisions. There are not even basic performance reports.

We provide users with a single point of contact for all requests through a basic self-service portal. It is mainly focused on searching through knowledge base and requesting support. It is a form-oriented solution. Solvers and users are not so keen on it due to its overcomplexity. If possible, tasks and requests are solved out of the system because it does not suit our needs. Due to the vendor lock we have no flexibility. 

We have Consumer and Provider systems which cover a catalogue of business and technical services to request management and approval workflow. We understand service utilization costs and we capture user feedback well. Our system fully supports end-to-end operations and service delivery. At the same time, the system is being integrated with strong asset and configuration management, event monitoring, etc. Our up-to-date tool contains the best global practice and automation. Besides, we work on further development according to current trends (e.g., Agile, ITIL4, DevOps etc.).

People generally tend to protect their own knowledge. They do not share experience and knowledge with others, since they believe their knowledge is the main reason why they work in the organization. Each department/office has their own standards and procedures which may or may not be formalized. 

There is a set of standards and procedures for the entire IT organization. However, usage of it varies between users and teams. We have several different places where we store the knowledge: knowledge base, operating Instructions, FAQs, known issues and work arounds which are not regularly reviewed for continued relevance. 

We work with one knowledge base where we save information and resources. Users have an overview on how to look for them. A knowledge item is clearly defined, and the system of knowledge is up to date. Users have easy access to Q&As or Wiki via Self-Service portal. Knowledge is context-aware and is orchestrated, filtered, and sorted based on relevance to the user with possibilities to provide feedback on relevance. Community-based resources such as discussion forums, social media etc. are used in order to support knowledge sharing not only within IT but also among common users across the company.

There is no single person responsible for the maintenance of our data, which results in chaos. Some users create their own records which are usually saved in spreadsheets. Technicians are not capable of effectively solving incidents. Due to all of the above, it is not possible to efficiently plan changes in IT.

We use several systems for making an inventory of our assets (servers, PCs, network elements, apps, phones, etc.). It is difficult to use these resources for planning because it requires a lot of manual effort. Due to missing relationships and dependencies between technologies, it is difficult to assess the impact of a change on the IT service it supports.

We have one single system where we store all our data, their connections and how they are linked to the IT services we provide. Everything is automatically collected from the network or subsystems via API and then provided to relevant users based on their needs and authorization. Data concerning decision-making and planning are easily accessible.

We do not conceptually assess which services and systems need to be procured. Neither do we determine which of our suppliers are strategic and crucial. 

Our suppliers fulfill their contractual obligations. However, they don't ensure that the quality of the final service delivered to the organization is acceptable. Besides, we try to hire external IT experts who can sometimes slow down implemented innovations and their related projects.

We understand which capabilities we want to retain in-house and what we need to outsource in order to get  access to specialist capabilities. Nowadays, in a rapidly changing world, the set of capabilities which are needed tomorrow will not be the same as today. We aim for increased adaptability and speed of response to business requirements.

We avoid using external suppliers. If we intend to buy a service, we do not establish management and control system of quality and prices. There  isn’t a responsible person  that would oversee it. 

We work with a basic system  to manage our suppliers. Incidents and requests are automatically transferred to our suppliers and do not load the system. SLA is automatically monitored, and therefore we have an overview of what is happening. But we may face issues when individual suppliers shift the blame rather than diagnose and address the root cause of service quality issues. Both, in-house and outsourced teams work autonomously which sometimes leads to lack of coordination. 

We understand the importance of service economics to make right decisions. We measure services end-to-end. The performance of our suppliers is measured and evaluated on a regular basis. Quality and prices are regularly assessed with consideration to our internal needs. Benchmarks are regularly controlled. We also aim to maintain good relationships and collaboration between suppliers. These procedures are incorporated to increase adaptability and speed of response to business requirements.

We have some struggles with our current suppliers. There is  distrust and lack of respect on both sides. We are concerned about possible vendor lock and breach of contractual obligations. Our current aim is to get control over it by defining rules of cooperation.

Over time, we have established certain relations with our suppliers, but we do not intensely work on potential improvements. When we look for more suitable suppliers in order to reduce cost, we often do not realize how much effort and time it takes to build a new relationship from scratch. So far, we have not systematically worked on improving it.

Well-established relationships with suppliers are a key factor going above and beyond the typical “hard factors” like cost alone. We are convinced that our relationships are well maintained. We organize informal meetings to coordinate our strategic plans. We appreciate the best suppliers and their work. This constant effort tremendously improves flexibility, and therefore there is no need for renegotiation of quick and simple changes as peaks in demand are handled.

There is officially no existing IT service in our organization. The IT department has a defined IT catalogue independently of any broader discussion. Services are not approved by business stakeholders. 

We have an existing IT service catalogue with many available services (more than 100 of them). We have an ongoing communication about the services in alignment with the business.  Sometimes we don’t articulate the value well and we lack a common understanding aligned with the business. As a result, critical services needed for the business are not defined. 

We have a good overview of which services are business-critical. SLAs are set up and approved by the business. There is a good connection between IT and business service. Certain data from the service catalogue is provided based on user’s authorization, whether it is an IT technician or a manager. Every service has its description and a responsible person assigned.

We do not operate any IT service desk to support employee experience. Users are not aware of proper channels to contact the IT department. Users can essentially contact anybody. Senior specialists solve trivial requests. We have shared mailbox as a point of contact. Incidents and requests are not recorded, and we don’t even distinguish between them. 

There is one single point of contact (web portal, shared mailbox, phone line, etc.) and we also have a service desk or an assistant via phone. However, the assistant does not collect the exact information about who is calling, which technologies are being used and what software runs on them. Furthermore, the assistant does not have an overview of who should solve the problem (person or team) and does not see users’ current and past requests. 

Employee portal is expanded to cover a catalogue of business and technical services which include not only IT but also HR, Facility, Fleet management, etc.. This includes provisioning, request management and approval workflows. We have automatic routing to the right solvers or teams. Agendas are separated by authorization depending on whether the user is an agent or requester. Each user can only see the services that they are aligned to. SD respects the user’s communication channel: phone, email or Teams.

We do not effectively and timely measure service quality. From time to time, we run a report during our team meetings. 

We measure SLAs but technical outlook still dominates over customer’s perspective. Employees of the service desk do not have an overview of all technologies and their actual status  – Does it work? What is the impact of the technology on the service run?

Each solver can directly see SLA parameters of the given request, for example: time to resolve, time to react. Traditional SLA metrics underpin the business user experience of the delivered service. Regular measurement of customer satisfaction is woven into our tools and processes. We actively respond to customer’s feedback and use it as a basis for further improvement.