Für wen lohnt sich ein strukturierter Einstieg?
Dieser Leitfaden richtet sich an interne IT-Abteilungen, die einen gewachsenen Bestand aus Active Directory, Entra ID, Virtualisierung, Servern und Cloud-Diensten betreuen. Häufig stehen gute Skripte bereit, während Freigaben, Parameter und Fehlerfälle noch von einzelnen Personen abhängen.
Ein typischer Ausgangspunkt sind IT-Teams mit etwa 5–30 Personen in Unternehmen mit ca. 100–2.000 Mitarbeitenden. Diese Größen beschreiben eine Orientierung für die Zusammenarbeit. Entscheidend sind die wiederkehrenden Aufgaben, die verfügbaren Zugänge und die Bereitschaft, einen Ablauf gemeinsam zu standardisieren.
1. Einen IT-Dienst auswählen, nicht die gesamte Umgebung
Beginnen Sie mit einer überschaubaren Aufgabe, deren Eingang und Ergebnis Sie beschreiben können. Das kann ein genehmigter Gruppenwechsel, ein regelmäßiger Servercheck oder ein festgelegter Housekeeping-Schritt sein. Ein vollständiges Onboarding über alle Anwendungen ist oft schon ein Bündel verschiedener Prozesse.
Für die Priorisierung helfen fünf Fragen:
- Wie häufig kommt die Aufgabe vor und welche manuelle Arbeit fällt an?
- Welche Regeln stehen fest und welche Ausnahmen brauchen eine Entscheidung?
- Welche Systeme müssen lesen oder schreiben können?
- Woran erkennt das Team ein korrektes Ergebnis?
- Wer verantwortet den Ablauf und seine spätere Änderung?
Eine häufige Aufgabe ist nicht automatisch ein guter Pilot. Wenn Eingaben unzuverlässig sind oder niemand über Ausnahmen entscheiden kann, muss zuerst der fachliche Ablauf geklärt werden.
2. Den Ist-Ablauf und die Systemgrenzen sichtbar machen
Notieren Sie den tatsächlichen Weg einer Anfrage: Wer erfasst die Angaben, wer genehmigt, welches System führt welche Änderung aus und wohin geht die Rückmeldung? Trennen Sie dabei die Quelle einer Information vom Ziel einer Aktion. Der Anzeigename eines Mitarbeitenden ist beispielsweise nicht automatisch ein geeigneter technischer Schlüssel.
Bei AD-/Entra-Prozessen gehören Identitäten, Gruppen, Synchronisationsabhängigkeiten und der gewünschte Endzustand auf die Liste. Bei VMware oder Windows-/Linux-Servern sind Objektzuordnung, Wartungsfenster und zulässige Aktionen zu klären. Für Azure und AWS werden die benötigten Dienste, APIs, Rollen und Kontogrenzen je Vorhaben geprüft.
3. Vorhandene Skripte zu überprüfbaren Bausteinen machen
Ein Skript, das interaktiv auf dem Rechner eines Administrators funktioniert, ist noch kein delegierbarer IT-Service. Für einen kontrollierten Aufruf braucht es definierte Parameter, Eingabeprüfungen, nachvollziehbare Rückgaben und eine geeignete Behandlung von Fehlern.
Prüfen Sie unter anderem, was bei einem erneuten Aufruf passiert. Eine bereits bestehende Gruppe oder ein schon gesetzter Zustand sollte bewusst behandelt werden. Legen Sie außerdem fest, welche Informationen protokolliert werden dürfen und welche Zugangsdaten außerhalb des Skripttexts verwaltet werden müssen.
PowerShell kann ein Bestandteil sein. Je nach Zielsystem kommen REST APIs, Microsoft Graph, Shell-Werkzeuge oder vorhandene Automationskomponenten hinzu. Die Auswahl folgt der Aufgabe; nicht jede Umgebung benötigt dieselbe Plattform.
4. Rechte, Freigaben und Fehlerpfade vor dem Pilot festlegen
Die anfragende Person und die ausführende technische Identität haben unterschiedliche Rollen. Definieren Sie, wer einen Service anfordern darf, wer eine Änderung gegebenenfalls genehmigt und mit welchen begrenzten Rechten die Aktion läuft.
Zu einem Pilot gehören auch Fälle, in denen keine Änderung stattfinden darf: fehlende Pflichtangaben, widersprüchliche Zustände, unerreichbare Systeme oder ein bereits bearbeiteter Auftrag. Für teilweise erfolgreiche Abläufe braucht es eine sichtbare Rückmeldung und einen vereinbarten Weg zur Nachbearbeitung. Nicht jeder Prozess lässt sich durch eine automatische Gegenaktion vollständig zurückrollen.
5. Nutzen und Betriebsfähigkeit gemeinsam prüfen
Vergleichen Sie den Pilot mit dem zuvor aufgenommenen Ablauf. Sinnvolle Beobachtungen sind manuelle Bearbeitungsschritte, Durchlaufzeit, Rückfragen, Fehlerfälle und die Zeit für die Nachbearbeitung. Erfassen Sie diese Werte in Ihrer Umgebung, statt fremde Einsparungszahlen zu übernehmen.
Eine Übergabe ist gelungen, wenn das zuständige Team den Ablauf aufrufen, seinen Status beurteilen und typische Fehler behandeln kann. Dazu gehören Dokumentation, Zuständigkeiten, getestete Wiederholungen und ein Verfahren für Änderungen an Skripten und Schnittstellen.
Ein Pilot-Steckbrief für Ihr Team
Für ein erstes Gespräch reicht eine kurze Beschreibung. Die folgenden Angaben helfen, einen umsetzbaren Umfang abzugrenzen:
- IT-Dienst
- Welche wiederkehrende Aufgabe soll einfacher werden?
- Eingang und Ergebnis
- Welche Angaben liegen vor und welcher Zustand soll erreicht werden?
- Umgebung
- Welche AD-/Entra-, VMware-, Windows-/Linux-, Azure-/AWS- oder Fachsysteme sind beteiligt?
- Kontrolle
- Wer darf anfordern, genehmigen und ausführen? Was passiert bei einem Fehler?
- Abnahme
- Mit welchen Normal- und Fehlerfällen weist das Team den Ablauf nach?
Wann kommen KI und AdminsBuddy ins Spiel?
Für bekannte Regeln ist ein deterministischer Workflow häufig der passende Anfang. KI kann freie Anfragen einordnen oder Informationen vorbereiten. Daraus ergibt sich noch keine Berechtigung, Änderungen auszuführen. Den Zusammenhang erklären wir unter Smarte Automatisierung: Regeln und KI.
AdminsBuddy ist eine eigene Plattform für anforderbare Automationen mit Requests, Berechtigungen und protokollierter Ausführung. Sie kann ein möglicher Rahmen sein. Ein Automatisierungsprojekt mit Renners IT setzt ihren Einsatz nicht voraus.
Wenn Sie einen konkreten Ablauf gemeinsam mit Ihrer IT umsetzen möchten, finden Sie Vorgehen und Liefergegenstände auf der Seite IT-Automatisierung für interne IT-Teams.