Daten sind unsere Leidenschaft!

Agiler Ansatz in IT-Projekten – schnell und erfolgreich

Hier soll eine bestimmte Kategorie von IT-Projekten angesprochen werden, wie sie in mittelständischen Unternehmen häufig vorkommt. Das Projekt betrifft mehrere Bereiche, eine Lösungsidee wird auf Abteilungsleiterebene vereinbart und nun geht es an die Umsetzung. Durch die nicht gegebene Vollzeit-Auslastung kann auch kein externer Dienstleister in Vollzeit für das Projekt arbeiten.

its-people verfolgt hier einen agilen Ansatz:

  1. Schnell einen Prototyp bereitstellen, an dem in Workshops die Abteilungen ein „Gefühl“ für das bekommen, was auf sie zukommt. An dem sie dem externen Berater bisher nicht diskutierte Implikationen der Lösungsidee klarmachen können

  1. Anschließend wird die Lösung soweit ausgebaut, dass ein Testbetrieb möglich ist. Zu diesem Zeitpunkt fällt die Entscheidung für die Inbetriebsetzung der Lösung zu einem bestimmten Termin. Dies geschieht in dem Vertrauen, dass Auswirkungen der Lösung, die bis dahin nicht transparent wurden, im laufenden Betrieb bearbeitet werden können, ohne dass dieser nachhaltig beeinträchtigt wird.

  1. Die Lösung wird in Betrieb gesetzt.

  1. Im laufenden Betrieb werden auftretende Probleme und Anforderungen registriert und bearbeitet.

Welche Vorteile bringt nun dieser Ansatz?

  • Durch Umgehung einer Lastenheft-Phase wird der Zeitrahmen erheblich verkürzt. Außerdem wird vermieden, die Mitarbeiter zur Zustimmung zu einer Lösung zu bewegen, deren ganze Tragweite sie zu diesem Zeitpunkt nicht überblicken. In klassischen Projekten wird dieser Unsicherheit dadurch begegnet, dass eine Fülle an Details spezifiziert wird, ohne dass dies sachlich gerechtfertigt ist. In der Rückschau stellt man später fest, dass wichtige Einzelheiten hingegen vergessen wurden.

  • Der Testaufwand wird auf wesentliche Funktionalitäten reduziert und dafür ein „Test im laufenden Betrieb“ für die Details vereinbart. Dadurch ist der zeitliche Aufwand für die Tests insgesamt geringer, da die Testdaten nach Inbetriebnahme im laufenden Betrieb entstehen. Es wird über die Zeit die Sicherheit erreicht, dass alle Auswirkungen berücksichtigt sind.

  • Durch die Inbetriebnahme der noch nicht ganz fertiggestellten Lösung treten die positiven Effekte früher ein. Dafür muss der Test im laufenden Betrieb geleistet werden. Die in dieser Phase von den Praktikern vorgeschlagenen Verbesserungen haben dadurch eine von Beginn an hohe Akzeptanz.

  • Der im Projektverlauf manchmal entstehende Eindruck, „hätten wir das vorher gewusst, dann hätten wir gar nicht erst angefangen“ wird schließlich mit „aber gut dass wir’s gemacht haben“ ergänzt.

Erfolgreich eingesetzt hat its-people diese Vorgehensweise bei einem Reparaturbetrieb für Schienenfahrzeuge mit angegliederter Werkstatt für die Instandsetzung im Zuge der Reparatur ausgebauter Teile.

Ausgangssituation:

Die Disposition der Teile, die je nach Verfügbarkeit neu oder aufgearbeitet sein können, hat nicht zufriedenstellend funktioniert. Der Disposition war die Zahl der ausgebauten, defekten Teile unbekannt und die Bestellpunktdisposition zeigte Neuteilbedarfe an, obwohl noch reparierte Teile am Lager waren.

Lösung:

Die defekten, reparierten und neue Teile unter derselben Teilenummer führen und nur durch ihren Zustand zu unterscheiden. Die defekten Teile sind dabei dispositiv nicht relevant. Zu- und Abgänge defekter Teile werden im Zuge der Entnahme von verfügbaren Teilen automatisch aus- und der Abgabe reparierter Teile ans Lager automatisch zugebucht. Wenn ein Teil während einer Reparatur eingebaut wird, muss ein defektes Teil ausgebaut worden sein. Wenn ein repariertes Teil ans Lager kommt, muss es ein defektes zum Reparieren gegeben haben.

Das Prototyping für den Workshop erforderte keine Software-Entwicklung, da das ERP-System (hier SAP) alle erforderlichen Funktionen beinhaltete. Während des Workshops wurden die später automatisch ablaufenden Buchungen manuell simuliert. Das Ergebnis erwies die Tragfähigkeit des Ansatzes.

Die Werkstatt bestand darauf, dass die bisherige Neuteil-Teilenummer beizubehalten sei, um den Aufwand für Teileauszeichnung zu minimieren. Gleichzeitig wurde ein System mit Anhängern unterschiedlicher Farbe verabschiedet, um den Zustand der Teile (neu, repariert, defekt aber auch „zu verschrotten“) sichtbar zu machen.

Beim Testen fiel auf, dass eine Vielzahl von Bestellpositionen aus der Vergangenheit offen geblieben waren, die vor Änderung der Materialstammdaten zu schließen waren. Einige davon waren auch betriebswirtschaftlich nicht abgeschlossen. Das heißt geliefert aber noch nicht bezahlt, bereits bezahlt aber zurückgeschickt. Diese Fälle würden bis zum Echtbetrieb zu bereinigen sein. Der Aufwand wurde abgeschätzt und die Entscheidung getroffen, 4 Wochen nach dem Test in den Echtbetrieb zu gehen.

Im laufenden Betrieb fielen noch diverse Verbesserungen an, die vornehmlich die Handhabbarkeit der Systeme betrafen

  • manuelle Buchungen mit Fehlermeldung abblocken, wenn sie nur automatisiert erfolgen dürfen
  • Felder in Erfassungsmasken kontextabhängig vorbelegen, um Erfassungsfehler möglichst zu vermeiden
  • Druckbelege anpassen, damit vom Teilezustand abhängige Texte generiert werden können
  • Reports erstellen, die die Situation für Disposition und Arbeitsvorbereitung transparent machen.

Ad hoc entschieden sich die Abteilungen dafür, eine Bedarfsnummer während der Reparatur mitzuführen und bei Abgabe der reparierten Teile ans Lager rückzumelden. Alle diese Entwicklungen wurden aufgrund eines aus der aktuellen Praxis klar definierten Bedarfs und mit klaren Vorgaben der Anwender vorgenommen.

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen: