ITIL

1. Record services, infrastructure and responsibilities according to ITIL

The first step is not just to document individual devices, but to map the IT landscape as ITIL sees it: as services with an underlying infrastructure. In i-doit, services, supporting systems, applications, locations, user groups and suppliers are created as separate objects with clearly defined attributes and linked to each other.
Roles, responsibilities and escalation paths can be assigned directly so that the technology behind each service, who is operationally responsible and what dependencies exist are visible. This creates a CMDB that not only manages inventory data, but also maps the technical view of IT service management.

2. Structure ITIL processes on the basis of the CMDB

In the second step, the central ITIL processes such as Incident Management, Change Management, Request Fulfillment or Problem Management are based on the existing documentation. Processes no longer refer only to tickets or numbers, but to specific services and the assets assigned to them in i-doit.
Faults, changes and service requests can thus be evaluated specifically in context. Effects on dependent systems, locations or user groups are immediately recognizable because the underlying structure is already documented. Decisions in the processes are therefore based on verified information instead of individual knowledge or manual lists.

3. Serive service quality, SLAs and improvements from the documentation

In the third step, the documentation is actively used to control and improve service quality. Recurring faults, high-risk changes or bottlenecks in certain services become visible via histories, links and evaluations. Monitoring and ticket data can be combined with the documented services to identify availability, SLA fulfillment and typical problem areas.
On this basis, measures for stabilization or optimization can be planned and tracked. ITIL is therefore not understood as a theoretical framework, but as a continuous improvement process based on the service and infrastructure mapping created in i-doit.

Record key figures and response times for SLAs and OLAs

IT service catalog

A service catalog clearly defines which services IT provides, to whom they apply and under which conditions they can be used.
Instead of processing loose requests or private workflows, services are standardized: from workstation setup to database access. Departments know what they can order, what costs are incurred, who is responsible and what service is guaranteed.

A structured service catalog prevents shadow IT, reduces queries and creates certainty of expectations.
IT teams no longer work reactively, but deliver traceable services with agreed targets - regardless of whether they are provided internally or purchased externally.

Advantages:

• Clearly defined services instead of individual tickets
• Transparency regarding costs, responsibilities and provision times
• Reduced coordination and clarification processes
• Expectation management between IT and specialist departments
• Basis for SLAs and service improvements

Roles, access and authorizations

Access is not just a technical issue, but also an organizational risk.
A lack of rights stops production processes, too many rights open up security gaps.
Authorizations must therefore not be distributed on the basis of persons, but on the basis of roles, services and responsibilities - with clearly defined handovers for changes, departments or projects.

A structured authorization model makes it possible to delegate responsibilities transparently and, in the event of an audit, to prove without discussion who had access to what and why.
Instead of manually maintaining user lists, a system is created that links rights structures with business processes.

Advantages:

• Risks reduced through role-based access instead of individual decisions
• Traceable changes during onboarding, changes and offboarding
• Clear separation of technical and organizational authorizations
• Audit-proof documentation without loss of knowledge
• Consistent authorization across teams, locations and systems

Asset and service lifecycle

Every IT service has a life cycle: introduction, operation, optimization and shutdown.
Not every service is operated indefinitely, and not every tool is sustainable in the long term.
ITIL therefore treats services like products: They are designed, evaluated, provided, improved and finally decommissioned in a controlled manner.

The service lifecycle prevents systems from "simply continuing to run" until they become a risk.
Planned transitions reduce technical debt, secure operating costs, avoid disruptions and create room for modernization without operational interruptions.

Benefits:

• Planned introduction and controlled shutdown instead of spontaneous migration
• Reduction of technical debt through active further development
• More economical investment decisions over the entire life cycle
• Less operational risk, as outdated services do not "drag on"
• Continuous improvement with measurable results