Zeitplan für die Implementierung eines IT-Systems – warum Projekte nicht plötzlich entgleisen

Ein Zeitplan für die Implementierung eines IT-Systems. Meist taucht er im Projekt als PDF-Datei oder als Gantt-Diagramm auf, das jemand beim Kick-off öffnet und dann… erst wieder hervorholt, wenn sich Verzögerungen bemerkbar machen.

Die Wahrheit ist: Wenn jemand sagt, dass sich ein IT-Projekt „plötzlich verzögert hat“, dann hat es sich mit hoher Wahrscheinlichkeit schon lange verschoben. Nur hat es niemand gesehen – oder niemand wollte es sehen. Dabei kann ein Zeitplan helfen zu verstehen, was mit dem Projekt passiert, bevor es zu spät ist.

Dieser Artikel zeigt, wie man in der Praxis an einen Zeitplan für die Implementierung eines IT-Systems herangeht – ohne Idealisierung, aber auch ohne Chaos.

Fangen wir bei den Grundlagen an, denn genau hier entsteht sehr oft begriffliches Chaos. Formulieren wir es provokant als Anti-Definition: Ein Zeitplan ist nicht:

Ein Zeitplan für die Implementierung von IT-Systemen ist – bildlich gesprochen – eine Geschichte des Projekts, eingebettet in einen zeitlichen Rahmen. Anders gesagt: eine Karte, die nicht alles zeigt, was Entwickler oder Automatisierer tun, aber die nächsten Phasen, ihre Reihenfolge, Abhängigkeiten und Kontrollpunkte sichtbar macht. Das alles hilft zu prüfen, ob wir noch in die richtige Richtung unterwegs sind.

Ein Zeitplan für die Implementierung eines IT-Systems wird so erstellt, dass er auch für den Kunden lesbar ist. Der Kunde muss nicht wissen, dass jemand ein Steuerelement baut oder ein Skript schreibt. Der Kunde will wissen, wann er:

Bei der Einführung von IT-Systemen sollte der Zeitplan daher Ergebnisse beschreiben – nicht technische Umsetzungsdetails.

Die Antwort auf diese Frage ist kurz. Ohne einen Zeitplan für die Implementierung eines IT-Systems beginnt das Projekt sehr schnell wie die Umsetzung eines Plans mit dem Titel „wird schon irgendwie klappen“ zu wirken.

Ein Zeitplan, besonders bei IT-Implementierungen:

Wichtig ist, dass diese Funktionen eines Zeitplans für die Implementierung eines IT-Systems im Unternehmen aus Sicht beider Seiten relevant sind: des Kunden und der IT-Firma. Denn der Zeitplan ist weder ein Kontrollinstrument des Kunden gegenüber dem Anbieter noch umgekehrt. Er ähnelt eher einer Karte, dank der beide Seiten wissen, wo sie stehen und wohin sie gehen.

Theoretisch lässt sich alles perfekt planen. Zwar ist jedes Projekt ein wenig anders, aber bestimmte Phasen wiederholen sich trotzdem – wenn auch mit unterschiedlicher Gewichtung und oft in einer anderen Reihenfolge.

Bevor ein sinnvoller Zeitplan entsteht, muss klar sein, was überhaupt implementiert werden soll. Genau dafür dienen Vorab-Analyse und Workshops. Das ist eine der wichtigsten Phasen bei der Implementierung eines IT-Systems im Unternehmen, denn hier werden Entscheidungen getroffen, die später den gesamten Zeitplan beeinflussen. Ohne diesen Schritt wird der Zeitplan zu einem Ratespiel. Genau in dieser Phase zeigt sich, dass:

Ein guter Zeitplan beginnt mit einem Gespräch, nicht mit einem Tool, denn nur Kommunikation ermöglicht es, festzulegen:

Das Design der Lösung ist die Phase, in der die Systemarchitektur aufgebaut wird: Funktionsumfang, Integrationen, Art des Datenflusses. Ein gut designtes System verkürzt die nächsten Projektphasen, ein schlecht designtes – rächt sich bei Tests oder beim Go-Live.

Das ist die Phase, die jeder mit „System bauen“ verbindet. Im Zeitplan lohnt es sich, sie iterativ zu betrachten, weil sich selten alles von Anfang an vorhersagen lässt. Wichtig ist, dass der Zeitplan hier Raum für Korrekturen lässt und keinen perfekten Verlauf voraussetzt.

Integrationen mit anderen Systemen sind ein klassischer Brennpunkt in Projekten. Warten auf Daten, Maschinen, PLCs, Server oder Subunternehmer gehört zum Alltag. In der Praxis findet die Implementierung von IT-Systemen in einer Produktionsumgebung nur sehr selten isoliert von anderen Tools statt. Ein Zeitplan, der das nicht berücksichtigt, ist Wunschdenken. Ein Zeitplan für die Implementierung eines IT-Systems, der Puffer einplant – schafft Spielraum.

Tests sind keine Belohnung am Ende des Projekts. Sie sind ein Teil davon und sollten ihren Platz im Zeitplan haben – zusammen mit Zeit für Korrekturen und Stabilisierung. Keine Tests im Zeitplan zu haben, ist der kürzeste Weg zu Problemen nach dem Start.

Das System kann fertig sein, und das Projekt kann trotzdem scheitern, wenn die Nutzer nicht wissen, wie sie es verwenden sollen. Der Zeitplan sollte Schulungen, Materialien und Zeit berücksichtigen, um sich an die neue Lösung zu „gewöhnen“.

Gut – wenn die Zeitplanung so viele Phasen umfasst, wie viel Zeit kann das Ganze dann benötigen? Das hängt davon ab. Und jede andere Antwort wäre unehrlich.

Die Implementierungsdauer hängt vom Projektumfang, der Anzahl der Integrationen, der organisatorischen Bereitschaft und dem tatsächlichen Engagement auf Kundenseite ab. Deshalb sind die ersten Zeitpläne rein orientierend. Erst nach der Vorab-Analyse bekommen sie konkrete Formen.

Bei IT-Implementierungen gehen Zeitpläne nicht deshalb kaputt, weil jemand die Anzahl der Tage für die Umsetzung falsch berechnet hat, sondern weil die Realität der Organisationsarbeit nicht berücksichtigt wurde.

Die häufigsten Fehler in Zeitplänen sind:

Ein Zeitplan ohne Puffer ist kein Plan. Das ist eine Illusion.

In Projekten, die explitia umsetzt, muss der Zeitplan die Realität der Produktion berücksichtigen. Wir wissen sehr gut, dass ein IT-System nicht losgelöst vom Produktionswerk funktioniert – sondern in der Halle, mit Menschen, vorhandener Software und dem Maschinenpark. Dazu kommen Variablen wie Produktionskontinuität, Sicherheit sowie die Integration von IT und OT.

Kurz gesagt: In Industrieprojekten bedeutet die Implementierung eines IT-Systems im Unternehmen, an einem lebenden Organismus zu arbeiten – und nicht in einer Testumgebung.

Ein guter Zeitplan für die Implementierung eines IT-Systems ist kein Versprechen, dass sicher alles gelingt. Er ähnelt eher der Unterstützung eines Kollegen, der sagt: „Wir wissen, was wir tun, wir wissen, wo die Risiken liegen, und wir wissen, was wir tun, wenn sich etwas ändert“.

Und das reicht völlig aus, damit das Projekt Sinn ergibt.