.svg)
Starte diese Woche mit einem Pilot für Incident Management und Request Fulfilment im Service Desk. Das ist die eine Aktion, die den größten Hebel hat. Alles andere, Servicekatalog, Governance, Reporting, baut darauf auf.
Hier die sechs Schritte im Überblick:
30/90-Tage-Timeline:
Stakeholder, die sofort eingebunden werden müssen: ein Sponsor auf Führungsebene (COO oder IT-Leiter), ein Service Owner pro Pilotservice und Vertreter aus IT und dem Fachbereich, der als erster Anwender fungiert. Ohne diese drei Gruppen im Raum läuft der Pilot ins Leere.
Service Management einführen gelingt am schnellsten mit einem klar abgegrenzten Pilot, namentlich besetzten Rollen und messbaren Erfolgskriterien vor dem ersten Ticket.
ThemaDetailsSofortmaßnahmeStarte diese Woche mit einem Incident- und Request-Pilot im Service Desk.Prozess vor ToolSkizziere den Prozess auf einer Seite, bevor du das Board konfigurierst.Fünf KernprozesseIncident, Request, Change, Problem und Knowledge Management reichen für Phase 1.KPIs von Anfang anMTTR, SLA-Erfüllung und FCR müssen vor dem Pilot definiert sein, nicht danach.NoliamNoliam implementiert den Pilot mit monday.com und Intercom in vier bis sechs Wochen.
Service Management ist der Oberbegriff für die systematische Planung, Erbringung und Steuerung von Dienstleistungen. Der Lebenszyklus umfasst fünf Phasen: Strategie, Service-Design, Transition (Überführung in den Betrieb), Betrieb und Service-Controlling. Ohne Service-Controlling, also ohne die laufende Messung von Qualität und Kosten, lassen sich weder Profitabilität noch Servicequalität wirklich steuern.
ITSM und ESM sind keine Synonyme, auch wenn sie oft so verwendet werden.
MerkmalITSMESMZielgruppeIT-Abteilung und IT-AnwenderAlle Abteilungen (HR, Facility, Legal, Finance usw.)Typische ServicesIncident, Request, Change, ProblemOnboarding, Beschaffung, Genehmigungen, VertragsmanagementKomplexitätMittel, IT-Prozesse sind oft bereits strukturiertHöher, da Nicht-IT-Bereiche weniger Prozesserfahrung mitbringenGovernance-AufwandFokussiert auf IT-SteeringAbteilungsübergreifend, mehr AbstimmungsbedarfReferenzrahmenITILITIL als Basis, ergänzt durch abteilungsspezifische Anforderungen
ITIL ist dabei die meistgenutzte Praxisreferenz im DACH-Raum. Kein Pflichtrahmen, aber ein bewährtes Vokabular, das Missverständnisse zwischen IT und Fachbereichen reduziert.
Wann reicht ITSM, wann lohnt ESM? Wenn der Schmerz klar in der IT liegt, also Tickets gehen verloren, SLAs werden nicht gemessen, Änderungen passieren unkontrolliert, dann ist ITSM der richtige Einstieg. ESM ist in der Praxis komplexer, weil Nicht-IT-Abteilungen oft wenig Erfahrung mit prozessbasierter Arbeit haben. Erfolg hängt dort von klarer Governance und gut nutzbaren Self-Service-Portalen ab. Starte mit ITSM, und erweitere auf ESM, sobald der erste Pilot stabil läuft.
Der häufigste Einwand lautet: „Wir haben das bisher auch ohne strukturiertes Service Management hinbekommen.“ Stimmt. Aber zu welchem Preis?
Konkrete Effekte, die ein strukturierter Ansatz liefert:
Laut Salesforce sind Schulung, ein kleiner Einstieg, einfache Self-Service-Formulare, Systemintegration und der Fokus auf relevante Kennzahlen die zentralen Maßnahmen für eine erfolgreiche Einführung. Tools allein lösen das Problem nicht.
Ein früher Pilot zeigt schnellen Nutzen: Schon nach vier bis sechs Wochen lassen sich erste Kennzahlen vorlegen, die den Sponsor überzeugen und das Budget für Phase 2 sichern. Das ist der eigentliche Wert eines Piloten. Nicht Perfektion, sondern Vertrauen.
Profi-Tipp: Rechne den Time-to-Value schon vor dem Pilot durch. Wenn ein Service Desk Agent täglich 30 Minuten mit dem Suchen von E-Mails verbringt und das Team zehn Personen umfasst, sind das 50 Stunden pro Woche. Dieser Wert ist dein Business Case.
Fang nicht mit allen ITIL-Prozessen an. Das ist der häufigste Fehler. Fünf Prozesse reichen für Phase 1.
Incident Management ist der Einstieg. Störungen erfassen, priorisieren, lösen, dokumentieren. Ohne diesen Prozess gibt es keine Baseline.
Request Fulfilment kommt direkt danach. Standardanfragen (Zugänge, Software, Hardware) über ein Self-Service-Portal abwickeln. Das entlastet den Service Desk sofort und ist für Anwender sichtbar.
Change Enablement verhindert, dass unkontrollierte Änderungen neue Incidents erzeugen. Ein einfaches CAB-Meeting (Change Advisory Board) reicht zu Beginn. Kein bürokratisches Monstrum.
Problem Management ist reaktiv in Phase 1: Wenn derselbe Incident dreimal auftaucht, wird ein Problem-Record angelegt und die Ursache untersucht. Proaktives Problem Management kommt später.
Knowledge Management ist der unterschätzte Prozess. Jede gelöste Störung, die dokumentiert wird, spart beim nächsten Mal Zeit. Eine einfache Wissensdatenbank im Tool reicht.
Profi-Tipp: Wenn Ressourcen knapp sind, darf eine Person mehrere Rollen übernehmen. Wichtig ist, dass die Rollen klar definiert und dokumentiert sind, nicht dass jede Rolle eine eigene Vollzeitstelle hat. Prozess Owner und Service Owner in einer Person ist in mittleren Unternehmen völlig normal.
Ein strukturiertes Vorgehensmodell beginnt mit Zielbild und Governance, gefolgt von Ist-Analyse, Prozessdesign, Pilot und kontinuierlicher Verbesserung. Das reduziert Implementierungsrisiken erheblich.
PhaseZeitfensterKernaktivitätenDeliverableVorbereitungWoche 1–2Sponsor, Scope, ZieleProjektauftragIst-AnalyseWoche 2–4Prozesse, Tools, ReifegradIst-Zustand-BerichtDesignWoche 3–6Servicekatalog, RACI, Tool-SetupServicekatalog, RACIPilotWoche 5–10Pilotbetrieb, KPI-MessungPilot-ErgebnisberichtSkalierungAb Woche 10Rollout, Training, ReportingRollout-Plan, Trainings
Für die Priorisierung im Pilot gilt: Wähle den Service, der den höchsten Ticketanteil hat und gleichzeitig klar abgegrenzt ist. Incident Management im IT-Helpdesk trifft das fast immer. Abteilungsübergreifende Workflows kommen in Phase 2, wenn der Pilot stabil läuft.
Prozess vor Tool. Das ist keine Floskel, sondern die häufigste Lektion aus gescheiterten Einführungen. Wer das Tool zuerst kauft und dann den Prozess drumherum baut, bekommt einen digitalisierten Chaos-Prozess.
Wer von Excel, Trello, Asana oder Jira wechselt, sollte drei Risiken kennen: Datenverlust bei unstrukturierten Exporten, Widerstand der Anwender durch veränderte Gewohnheiten und fehlende Prozessdokumentation, die erst beim Wechsel sichtbar wird. Der schnellste Weg: Daten parallel führen für vier Wochen, dann hart umschalten. Kein langes Parallelbetrieb-Theater. Einen strukturierten Ansatz zur Toolmigration und Change Management haben wir separat beschrieben.
Für Unternehmen in Deutschland, Österreich und der Schweiz gilt: Prüft Hosting-Standort und DSGVO-Konformität des Anbieters vor Vertragsabschluss. Viele Plattformen bieten EU-Hosting an, aber nicht alle haben einen deutschen Serverstandort. Das ist relevant, sobald personenbezogene Daten im Ticketsystem landen.
monday.com eignet sich als flexible Board-Plattform für Service-Prozesse, weil Spaltentypen, Statusfelder und Automatisierungsregeln ohne Entwicklungsaufwand konfigurierbar sind. Typischer Einsatzfall: Incident- und Request-Board mit SLA-Tracking, automatischen Benachrichtigungen und Dashboard-Ansicht für den Service Owner.
Intercom ergänzt das Setup auf der Anwenderseite: Self-Service-Portal, Chatbot für Standardanfragen und Ticket-Routing direkt aus dem Kundenkontakt. Die Integration beider Plattformen über Make.com oder native Konnektoren schließt die Lücke zwischen Anwender-Kommunikation und internem Ticketmanagement.
Startet mit dem einfachsten Board, das den Prozess abbildet. Drei Statusspalten, eine Prioritätsspalte, ein Owner-Feld. Mehr braucht ihr im Pilot nicht. Komplexität könnt ihr immer noch hinzufügen. Rückbauen ist schwerer.
Self-Service-Portale und ein klarer Service-Desk-Betrieb sind die zentralen Hebel, um Anwenderakzeptanz zu steigern und den operativen Betrieb zu stabilisieren.
Governance klingt nach Bürokratie. Ist es aber nicht, wenn man es richtig macht. Es geht darum, wer welche Entscheidungen trifft und wie Änderungen genehmigt werden, bevor sie im Betrieb landen.
Akzeptanz entsteht nicht durch Schulungen allein. Einfache Self-Service-Formulare und sichtbare Quick Wins, also gelöste Tickets, die früher wochenlang offen lagen, erzeugen mehr Vertrauen als jede Präsentation. Zeigt dem Team nach zwei Wochen die ersten Zahlen. Das wirkt.
Wer keine Kennzahlen definiert, kann nicht steuern. Und wer zu viele definiert, verliert sich im Reporting. Fünf operative KPIs reichen für den Start.
Reporting-Rhythmus: Tägliches Dashboard für Service Desk Agents und Service Owner, wöchentliches Kurzreporting für den SMO, monatliches Steering-Reporting für Sponsor und Lenkungsausschuss. Kein wöchentliches Führungskräfte-Meeting mit 40-seitigen Präsentationen.
KPIs werden erst nützlich, wenn sie zu Entscheidungen führen. Wenn die MTTR steigt, wird eskaliert. Wenn die SLA-Erfüllung unter einen definierten Schwellenwert fällt, greift ein Service Improvement Plan (SIP). Diese Eskalationsregeln müssen vor dem Pilot schriftlich festgelegt sein, nicht erst wenn das Problem auftritt.
Die meisten Einführungen scheitern nicht an der Technik. Sie scheitern an Entscheidungen, die zu früh oder zu spät getroffen werden.
Gegenmaßnahmen während des Pilots: Wöchentliche Retrospektive (30 Minuten), klare Definition von „Done“ für jeden Prozessschritt und ein Eskalationsweg für Blockaden, der nicht über drei Hierarchieebenen führt.
Hier ist ein konkretes Setup, wie wir es in Pilotprojekten aufbauen. Kein Wunschkonzert, sondern das Minimum, das funktioniert.
Ein Incident-Board mit folgenden Spalten:
Ansichten: Kanban-Ansicht für den Service Desk, Tabellen-Ansicht für den Service Owner, Dashboard mit MTTR und SLA-Erfüllung für den Sponsor.
Intercom übernimmt den Eingangskanal: Anwender stellen Anfragen über das Self-Service-Portal oder den Chat. Intercom routet automatisch nach Service-Kategorie und legt ein Ticket im monday.com-Board an. Der Agent sieht den vollständigen Kontext, ohne zwischen zwei Systemen zu wechseln. Mehr zur Automatisierung im Support haben wir separat dokumentiert.
RolleAufgabe im PilotZeitaufwand pro WocheSponsorMandat, Eskalation, monatliches Steering1–2 StundenService OwnerKPI-Überwachung, Prozessverantwortung3–5 StundenService Desk AgentTicket-Bearbeitung, Wissensdatenbank pflegenVollzeit oder TeilzeitProcess OwnerProzessdokumentation, Retrospektiven2–3 StundenResolver GroupEskalierte Tickets lösenNach Bedarf
Typische Ergebnisse nach einem sechswöchigen Pilot: Tickets, die vorher per E-Mail verloren gingen, sind jetzt vollständig erfasst. Der Service Owner hat erstmals eine Baseline für MTTR und SLA-Erfüllung. Das Team spart messbar Zeit bei der Suche nach Ticket-Status. Und der Sponsor hat Zahlen, mit denen er den Rollout intern begründen kann. Unsere Projektergebnisse zeigen, wie das in der Praxis aussieht.
Wir sehen in Projekten immer wieder dasselbe Muster: Unternehmen, die mit einem kleinen, klar abgegrenzten Pilot starten, kommen schneller ans Ziel als Teams, die ein großes Programm aufsetzen und dann sechs Monate auf den ersten sichtbaren Fortschritt warten.
Der Grund ist simpel. Ein Pilot erzeugt Zahlen. Zahlen erzeugen Vertrauen. Vertrauen öffnet Budget für Phase 2. Ein großes Programm erzeugt erst mal Präsentationen und Abstimmungsrunden.
Was sich in unseren Projekten bewährt hat: Prozess-first, immer. Wir konfigurieren kein Board, bevor der Prozess auf einer Seite skizziert ist. Wenige, gut gewählte Automatisierungsregeln statt eines Regelwerks, das niemand mehr durchblickt. Und häufige Retrospektiven, mindestens alle zwei Wochen im Pilot. Nicht als Pflichttermin, sondern als echtes Feedback-Format, bei dem auch Kritik am Prozess willkommen ist.
Der häufigste Fehler, den wir sehen: Rollen werden definiert, aber nicht gelebt. Der Service Owner ist nominiert, aber hat keine Zeit und keine Entscheidungsbefugnis. Dann läuft der Prozess ins Leere, egal wie gut das Board konfiguriert ist. Rollen brauchen Mandat, nicht nur einen Namen in einer RACI-Matrix.
Pragmatischer Start schlägt perfekter Plan. Fang diese Woche an, auch wenn noch nicht alles steht.
Ihr habt den Plan. Jetzt geht es darum, ihn umzusetzen, ohne drei Monate in Konzeptpapieren zu verschwinden. Genau da setzen wir an.
Noliam bringt euren Service-Management-Pilot in vier bis sechs Wochen zum Laufen: mit einem konfigurierten monday.com-Board, Intercom als Eingangskanal, fertigen Automatisierungsregeln und einem Trainingspaket für euer Team. Kein generischer Beratungsansatz, sondern direkte Implementierungsarbeit mit Produkt-Expertise in beiden Plattformen.
Unsere Pakete passen zum Projektstand: Clarity Audit für Teams, die zuerst verstehen wollen, wo der Prozess hakt. Fast Foundations für Teams, die direkt starten wollen. Admin as a Service für den laufenden Betrieb, wenn ihr keine interne Kapazität für Tool-Administration habt.
👉 Schaut euch unsere monday.com-Implementierungsleistungen an oder bucht direkt einen Admin-as-a-Service-Einstieg. Wir melden uns innerhalb von 24 Stunden.
%20invert.svg)