Zersplitterte Prozesslandschaft – Von Herausforderungen im IT-Dienstleister-Wirrwarr

Das Problem

IT-Prozesse werden oft aus der Sicht des jeweiligen Fachbereiches konstruiert, nicht aus der Sicht des Anwenders. Insbesondere bei Anforderungen, die Beistellleistungen aus mehreren Fachbereichen benötigen, kann es dazu kommen, dass der Anwender sich die benötigten Teams selbständig zusammensuchen muss. Dies und auch die einzelnen Prozesse der Fachbereiche verlangen vom Anwender in den meisten Fällen weitreichende Kenntnisse.

Ein Beispiel aus der Praxis

So kann die Platzierung eines Servers kompliziert werden. Gehen wir davon aus, dass ein Server für eine bestimmte betriebliche Tätigkeit benötigt wird. Jetzt kann es vorkommen, dass bei der Bestellung eines (virtuellen) Servers dem Anwender mitgeteilt wird, dass alle neu aufgebauten Server in separate Sicherheitssegmente platziert werden müssen. Aus diesem Grund solle der Anwender bitte zuerst ein Sicherheitssegment bestellen und dann mit entsprechenden Netzwerkparametern eine neue Serverbestellung auslösen. Während der Bestellung eines Sicherheitssegments für den zukünftigen Server wird dann darauf verwiesen, dass der Anwender zusätzlich entsprechende Firewall-Kommunikationen zu beantragen habe. Für diese Bestellung der Firewall-Kommunikation soll der Anwender alle benötigten Kommunikationspartner und die benötigten Ports auflisten inkl. Begründung der Funktion und Notwendigkeit.

Jetzt kann endlich der Server bestellt werden. Nach Bereitstellung stellt der Anwender fest, dass sein Server aus dem normalen Büronetz nicht erreichbar ist. Er steht schließlich in einem dedizierten Sicherheitssegment. Somit stellt er erneut einen Firewall-Kommunikationsantrag, bei dem er Zugriff von seinem Arbeitscomputer auf den Server beantragt. Hier wird ihm mitgeteilt, dass dies nicht möglich sei, da administrative Zugriffe nur noch über Sicherheitsgateways oder Sprungserver durchzuführen sind. Man teilt ihm drei Möglichkeiten mit, nicht aber den genauen Prozess oder die jeweiligen Ansprechpartner. Bevor der ursprüngliche Server also genutzt werden kann, muss noch ein Sprungserver bestellt und bereitgestellt, die Firewall-Regeln konfiguriert und alle Beteiligten für die Zugriffswege berechtigt werden.

Um das Beispiel wieder zu abstrahieren: An einem aus Anwendersicht einzelnen Prozess sind mehrere Anforderungen und Aufgaben verschiedener IT-Sub-Abteilungen beteiligt, die separat beauftragt werden müssen. Stellt man sich als Anwender den Verantwortlichen für das Flottenmanagement einer Firma vor, der eine automatisierte Schlüsselausgabestation verwalten soll und keinen IT-Architekturplanungshintergrund hat, wird schnell offensichtlich, dass der ganze Ablauf zu kompliziert ist. So kann eine einfache Anfrage zu einem riesigen Aufwand werden.

In einigen Unternehmen hat man für solche Fälle eine interne Planungs- oder Beratungsabteilung eingerichtet, auf die gerne verwiesen wird. Falls es eine solche Abteilung überhaupt gibt, sind die Kapazitäten eng bemessen. Und statt einer Person, die diese komplexen Prozesse überblicken und die einzelnen Anforderungen zusammenbringen kann, findet man hier im besten Fall eine Liste mit möglichen Ansprechpartnern.

An dieser Stelle kommen häufig erfahrene Kollegen (intern wie extern) ins Spiel. Teilweise gilt dies auch für Kollegen bei der ComConsult, die bei ihren jeweiligen Kunden so stark vernetzt sind, dass sie im Namen einer Abteilung dann mit den IT-Abteilungen der Unternehmen kommunizieren und die Arbeit eines internen Architekturplaners übernehmen. Dazu gehört jedoch eine Menge Detailwissen der jeweiligen Infrastrukturen und Kenntnisse über die entsprechend zerstreute Prozesslandschaft des Kunden. Dies ist nur möglich, wenn man jahrelange Erfahrung bei dem jeweiligen Kunden gesammelt hat. Ein Anfragender in einem Unternehmen sollte allerdings nicht durch die Unübersichtlichkeit interner IT-Prozesse dazu genötigt werden, externe IT-Berater zu engagieren.

Weitere Beispiele

Die erwähnten Schwierigkeiten gibt es neben dem vorherig beschriebenen Beispiel unter anderem in den folgenden IT-Themenbereichen:

• Firewall
• Benutzeranträge
• Segmentierung
• Serverberechtigungen
• Serverumzüge
• Datenbanken

Oft basieren solche Prozesse auf starren Prinzipien, die keine Abweichungen zulassen. Beispielsweise kann ein Betreiber von Druckern, die aus Gründen der IT-Sicherheit in ein Sicherheitssegment verlagert werden sollen, die Kommunikation zwischen einem Druckserver und dem Sicherheitssegment nicht anfordern, da ihm weder das Objekt des Servers (andere Abteilung) noch das Objekt des Netzsegments (Netzbetrieb) zugeordnet ist. Die eigentlich positive Maßnahme, allen Objekten einen eindeutigen Verantwortlichen zuzuordnen, hat den negativen Seiteneffekt, dass Verantwortliche und Anwender oder Nutzer nicht identisch und letztere nicht handlungsfähig in Bezug auf ihr genutztes Objekt sind. Somit kann der alleinige Nutzer dieser Kommunikation aus obigem Beispiel seine Kommunikation nicht beantragen, da er aus Sicht des Firewall-Prozesses nicht im Besitz der entsprechenden, an der Kommunikation beteiligten Firewall-Objekte ist. Die Kommunikation muss daher vom Betreiber des Druckservers oder vom Netzwerkteam angefordert werden, die beide nichts mit dem eigentlichen Betrieb der Drucker zu tun haben.

Ebenfalls kompliziert kann es beim Onboarding von externen Kollegen zugehen. So braucht ein Mitarbeiter eines Softwareunternehmens, welcher ein System beim Kunden implementieren soll, im schlimmsten Fall alle der folgenden Beantragungen:

• Basisantrag Windowsnutzer für externe Dienstleister (Benutzeraccount / Zweifaktor für Anmeldung / Terminalserver erreichbar aus dem Internet)
• Administrator-Account
• Linux-Berechtigungen für Administrator-Account
• Berechtigung für Sprungserver, um vom Terminalserver auf den eigentlichen Server zu gelangen
• Berechtigung auf den eigentlichen Linux-Server

Starre Prozesse kann es auch in den jeweiligen Betriebsteams geben. So ist es vorgekommen, dass ich im Rahmen meiner Tätigkeiten eine vierstellige Anzahl von Systemen gefunden habe, die nicht konzeptkonform funktionierten. Pflichtbewusst habe ich dies an die zuständige Abteilung weitergeleitet. Die Antwort auf meine detaillierte Information inklusive einer vollständigen Liste der Systeme war: „Jeder Anwender muss einzeln ein entsprechendes Ticket eröffnen.“ Dabei war der angesprochene Konfigurationsfehler an zentraler Stelle zu finden.

Wo liegt der Fehler?

Nicht nur aus Sicht der IT-Sicherheit, sondern auch aus der Vernetzung einzelner IT-Systeme untereinander und nach außen, sind an den Betrieb und die Nutzung dieser Systeme gesteigerte Anforderungen gestellt. Darin scheint jedoch nicht die Ursache der oben geschilderten Probleme zu liegen.

Vielmehr beobachte ich zunehmend, dass zum einen die Notwendigkeit der Zusammenarbeit der verschiedenen IT-Abteilungen und deren Dienstleistern untereinander und zum anderen nicht vorhandene abteilungsübergreifende Prozesse den Anwender vor unlösbare Komplikationen stellen. Dabei sollten IT-Prozesse den Anwender in den Mittelpunkt rücken und die IT als Ganzes berücksichtigen und nicht nur Teile betrachten.

Es hat sich in den vergangenen Jahren etabliert, die Prozesse der einzelnen IT-Abteilungen durch einen externen Dienstleister erledigen zu lassen. Die Abteilung definiert alle Standard-Prozesse, erstellt Dokumentation und Anleitungen und kann diese dann durch einen Dienstleister ausführen lassen. Dieses Vorgehen sollte den meisten bekannt vorkommen. Diese Prozesse können dann direkt über entsprechende Tools ausgelöst werden, wenn man den jeweiligen Link zum Prozess oder einer Ticketzuweisungsgruppe kennt. Oder man kann den Vorgang klassisch über den 1st-Level-Support via Telefon auslösen. Dem 1st-Level-Support wird dann eine Übersicht der möglichen Incidents oder Requests übergeben, die als Ticket die entsprechende Fachgruppe erreichen und in einer angemessenen Zeit bearbeitet werden. Was effizient klingt, hat einen eklatanten Nachteil: Es gibt niemanden, der neue Prozesse definieren oder nicht-Standard-Prozesse auslösen kann. Kommt also ein Anwender mit einer unbekannten Anfrage, kann ihm nicht geholfen werden. Daran kann auch die interne Beratung nichts ändern.

Hinzu kommt, dass bei der Definition von Standard-Prozessen Schnittstellen nur schwierig abzubilden sind. Jede Abteilung prüft nur, ob für die vorliegende Anfrage die Voraussetzungen erfüllt sind. Für Abteilung 1 sind das A, B und C. A kann Abteilung 2 liefern, diese braucht wiederum x, y und z. Eine Übersicht, dass für die Anfrage A, B und C sowie x, y und z nötig sind, hat weder der Anwender noch die beteiligten Abteilungen.

Lösungsmöglichkeit

Komplexere Prozesse müssen auf einer höheren Ebene abteilungsübergreifend definiert werden und optionale Komponenten enthalten. Es braucht übergeordnete Workflows zwischen „Inseln/Gewerken“. So könnte man alle oben gelisteten Beispiele mit jeweils einer Anfrage bestellen, wenn die Prozesse jeweils ineinander verschachtelt werden und dem Antragsteller entsprechende Auswahlmöglichkeiten zur Verfügung stehen.

So sollte zumindest einem 1st-Level-Support einfach dargestellt werden können, für welche Anforderung welcher Prozess angestoßen werden muss. Der Anwender sollte lediglich seine Anforderung stellen können, ohne tiefgehende Kenntnisse über IT-Prozesse zu benötigen. Es darf nicht dazu führen, dass der Anforderer Detailwissen über die IT-Architektur des Unternehmens braucht oder sich Ticketzuweisungsgruppen und ähnliche Strukturen merken muss.

Verweis

Projektinterview: Die Schlüsselrolle des Mittelsmanns zwischen IT und Fachabteilungen, Netzwerk Insider April 2025