(Startup- bzw. Prototyp-Entwicklung für nur 40 EUR / h. Weitere Informationen finden Sie hier.)
Im letzten Artikel haben wir alle wichtigen Phasen eines digitalen Projekts vorgestellt. Die Phasen waren:
In diesem Artikel gehen wir nochmals auf die Phasen eines digitalen Projekts ein, um zu zeigen, wie spezifisch sie bei der Einführung eines neuen Systems für bisher noch nicht genutzte Prozesse sind. Zu betonen ist, dass es sich hierbei nicht um einen Ersatz einer bestehenden Lösung durch eine andere handelt.
Die Besonderheiten bei neuen Systemen können als Vor- und Nachteile beschrieben werden.
Vorteile
- Bei neuen Systemen beginnt man immer bei null und das bedeutet: Es müssen weder Altlasten berücksichtigt werden noch gibt es eine Migration von Daten.
- Man kann das System auf die Anforderungen anpassen und einstellen, wie man es benötigt.
- Das operative Business ist bei neuen Systemen noch nicht derart involviert, da keine ständigen System-Updates vonnöten sind.
- Da sich Prozesse nur langsam ändern, bleiben die Rahmenbedingungen für das System länger stabil.
Nachteile
- Der größte Nachteil ist die Tatsache, dass das System neu ist und noch keine Erfahrungen damit gesammelt werden konnten.
- Gerade die fehlende Erfahrung bei neuen Systemen wirft zahlreiche Fragen auf:
- Was sind relevante Punkte, die definiert werden müssen?
- Welche Funktionen sind wichtig, welche nicht?
- Wie ist die User Experience?
- Welche Systeme müssen alle involviert werden?
- Was macht das System kompliziert, was nicht?
- Wie wird es an andere Systeme angedockt?
- Wer ist der Owner?
- Wie verbinde ich es am Ende mit den Prozessen?
- Wie nutzen die User das System und wie werden sie dazu veranlasst, dass sie es tatsächlich nutzen?
1. Projektinitialisierung
Mal angenommen, es handelt sich um ein Projekt über 50.000 €, das durch die Genehmigungsprozesse eines Unternehmens gehen muss.
- Scope-Eingrenzung
Die Phase der Projektinitialisierung beinhaltet auch die Ideengewinnung. Daher muss sie zugleich aufweisen, was das System können soll und welche Prozesse es abdecken soll.
Ist der Scope (Summe aller Anforderungen, die das System abdecken soll) eng, so ist auch das System klein und übersichtlich, aber ggf. ist der Nutzen zu klein, als dass es auf die Agenda kommen würde.
Ist der Scope zu groß, so sind die Kosten ggf. zu hoch und das Projekt wird zu umfangreich.
- Vorgehensweise
Der Auftraggeber muss eine Erklärung über die strategische Bedeutung, das Budget, die Problemlösung und die User erhalten. Es soll ein klares Bild davon entstehen, welche Aufmerksamkeitas System beim Management hat (insbesondere welche Ziele und Umsätze bzw. welcher Benefit sich aus dem Projekt für das Unterfangen ergeben sollen).
Hierbei geht es aber nicht um die genaue Definition des Vorgehens, denn die wird dem Auftraggeber kaum von Nutzen sein. Aus seiner Sicht ist es einfach nur notwendig, dass es erarbeitet wird.
Wichtig ist, dass man eine Vorstellung davon gewinnt, die man dann in Runden abstimmen kann. Dabei ist es ratsam, eher ins Detail zu gehen, auch wenn diese dann in Workshops geändert werden, als mit vagen Ideen zu arbeiten, die in verschiedenen Abteilungen und auf verschiedenen Ebenen unterschiedliche Erwartungen wecken. Detailgenauigkeit ist nämlich eher von Vorteil als von Nachteil.
Die ersten Ressourcen für ein Grobkonzept werden freigegeben und das Grobkonzept wird erstellt. Es werden grobe Anforderungen, Vorteile und Kosten definiert. Stehen der Scope und das grobe Verständnis über den Business-Cases, dann können die strategischen und finanziellen Vorteile abgeleitet werden.
Es folgt die Abschätzung der Kosten durch Gespräche mit der eigenen IT – ggf. auch erste Schätzungen von Firmen und externen Beratern. Der letzte Schritt dieser Phase vor der Managemententscheidung ist die Erstellung eines Business-Cases, der alles zusammenfasst, inkl. dem Projektteam, das es umsetzen würde, und erstem Projektplan.
Nun steht die Entscheidung des Managements über die Weiterführung bevor. Dies bedeutet, eine Entscheidungsvorlage für weitere Schritte zu erarbeiten, Kosten für die Feinkonzeptphase abzuschätzen, das Projektteam und externe Berater zu definieren und ggf. eine Ausschreibung zu erstellen.
Steht der Weiterführung des Projekts nichts im Weg, werden die Mittel für das Feinkonzept freigegeben.
2. Feinkonzept (Projekt-Setup)
- Erstellung des Feinkonzepts
Zuerst wird versucht, das Grobkonzept in Einzelheiten darzulegen, sodass man die Kosten abschätzen kann. Viele Aspekte müssen in dieser Phase bereits definiert werden. Doch genau damit tun sich Fachabteilungen schwer, da sie alle Hände voll zu tun haben.
Oft wird dieser Punkt nicht genau durchdacht, da man für den Detailgrad bereits Entscheidungen für die Lösung treffen muss. So kann z. B. ein Kunde in dem Tool ein oder zehn Bilder hochladen, als Zip-Datei oder alle einzeln. Da man das aus Angst sich festzulegen nicht machen möchte, werden diese Entscheidungen nicht getroffen und das Konzept bleibt weiterhin vage und die Kostenschätzung wenig aussagekräftig.
An dieser Stelle ist es wichtig, eine Lösung zu skizzieren, auch wenn diese später geändert wird. Auf diese Weise werden alle Kostenänderungen transparent. Es ist ratsamer, den Lösungsweg später, aber genauer zu ändern, als ungenau zu bleiben.
Als wichtiger Punkt sollte nicht vergessen werden, dass das Feinkonzept weiterhin eine Business-Spezifizierung ist und keine technische Lösung. Zum Feinkonzept gehören User, Rollen, Beziehungen, Prozesse, Datenfelder, die benötigt werden, Mock-ups und Fehlerszenarien.
- Einschätzung durch die IT
Sobald das Feinkonzept detailliert beschrieben ist, entwirft die IT eine Lösung, die auf den vorhandenen Ressourcen und Kenntnissen basiert. Diese Lösung beinhaltet Vorschläge darüber, welcher Teil der Lösung intern und welcher extern abgewickelt wird. Da dieses Thema für die IT neu ist, erweist sich die Abgabe einer Schätzung als schwierig. Vieles hängt hier vom Typ der Mitarbeiter ab und davon, ob sie die Aufwände als zu hoch einschätzen, ob die IT zu sicherheitsbewusst ist oder zu wenig, und ob sie risikofreudig ist. Das sollte bei der Übernahme in den Business-Case unbedingt beachtet werden.
- Make-or-buy-Entscheidungen
Sobald der Vorschlag kommt, einen Teil der Lösung extern abzuwickeln, muss das Management eine Make-or-buy-Entscheidung treffen. Da es sich hier um eine neue Lösung handelt, können drei unterschiedliche Wege gegangen werden:
- Die Lösung wird komplett neu gekauft.
- Die Lösung wird selber programmiert, da das Know-how vorhanden ist.
- Das Know-how wird aufgebaut und die Lösung selber entwickelt.
Welche von den drei Möglichkeiten gewählt wird, hängt von der strategischen Bedeutung des Themas ab.
- Kostenschätzung und Ausschreibung (auch mit eigener IT)
Ist alles definiert, können die eigentlichen Kosten detailliert geschätzt werden. Für externe Leistungen erfolgt eine Ausschreibung bzw. die Kosteneinschätzungen von zwei Lieferanten müssen eingeholt werden. Hier könnte es sich rächen, wenn das Feinkonzept zu ungenau ist. Die IT wird diese nicht schätzen, sondern für Unsicherheiten Sicherheitsaufschläge bereitstellen. Diese fallen oft sehr hoch aus, sodass die Kosten überproportional steigen. Daher ist es wichtig, dies zu vermeiden.
- Entscheidung für Umsetzung und DL
Sind alle Kosten bekannt, kann eine finale Entscheidungsvorlage für das Management entworfen werden, in der die genauen Kosten enthalten sind.
3. Umsetzung
Sobald die Entscheidung gefallen ist, kann die eigentliche Umsetzung erfolgen.
Ab diesem Zeitpunkt kommen einige Vorteile der Entwicklung einer neuen Software für ein neues Thema zum Vorschein. Das System kann von Beginn an entwickelt und an die bestehenden Anforderungen angepasst werden. Wie die Entwicklung, die Einführung (bei bestehenden Lösungen) oder das Customizing des Systems weiter verlaufen, hängt von der IT und dem DL ab, fällt aber ebenfalls in den Verantwortungsbereich des technischen Projektleiters.
Was bei der Umsetzung eines neuen Systems für den digitalen Projektleiter zu beachten ist (SST zwischen Fachabteilung und IT)
- Planung neuer Projekte Die Planung sollte über mehrere Releases und in kleinen Paketen erfolgen. Es werden immer wieder Stolperfallen auftauchen, die Verschiebungen und Verzögerungen verursachen werden. Bei jedem Release sollte man genügend Zeit für die Tests einplanen. Dazu zählen sowohl die Funktionstests als auch die Überwachungen der Anforderungsumsetzung.
- Stolperfallen Da die Umsetzung des Projekts der wichtigste Teil ist, müssen die drei Faktoren Budget, Zeit und Qualität besonders im Auge behalten werden. Bei neuen Lösungen können Stolperfallen auftreten, d. h. Anforderungen können zu technischen Problemen führen, die dann erst bei der Entwicklung bemerkt werden. Es ist wichtig, solche Stolperfallen zu isolieren und mögliche Fachalternativen zu definieren. Dabei sollte aus Business-Sicht entschieden werden, was wichtiger ist. Es kann ebenfalls von Bedeutung sein, an der Anforderung festzuhalten, auch wenn die Entwicklung mehr Aufwand bedeutet, oder die Anforderungen so anzupassen, dass die Entwicklung schneller vorangeht.
- Parallele Entwicklung mehrerer Systeme
Wenn parallel entwickelt wird, muss auf eine genaue Dokumentenabgleichung geachtet werden. Denn während der Umsetzung ist es notwendig, überall kleine Abweichungen vom System vorzunehmen. Diese müssen festgehalten und an die anderen Systeme kommutiert werden. Oft kommt es zu Fehlern, sodass zwei Entwicklungsstränge auseinanderlaufen und diese nicht kommutiert - Einbeziehung der Anforderer Bei einem neuen System und einer neuen Leistung kann es trotz aller Gründlichkeit in der Spezifikation trotzdem vorkommen, dass sich Vorstellung und Umsetzung nicht decken. Je früher die Anforderer bestimmte Dinge sehen, testen oder prüfen können, desto eher sind sie in der Lage, Änderungen zu definieren. Es sollte tunlichst vermieden werden, ein System über zwei bis drei Monate zu entwickeln und erst dann das Resultat zu präsentieren. Danach werden bestimmst massive Änderungen vorgenommen. Deshalb sollte in welcher Form auch immer ein Abgleich zwischen der Lösung und den Erwartungen der Anforderer im Zwei-Wochen-Takt geschehen.
- Funktions-Testing
Nach der Entwicklung, d. h. vor dem Merger und den Integrationstests, sollten die Funktionen getestet und überprüft werden. Dies kommt in vielen Fällen zu kurz, wodurch sich die anschließenden Integrations- und Abnahmetests blockiert werden und sich verzögern. Zudem entsteht ein schlechtes Image der neuen Software, wenn Basis-Buttons nicht geklickt werden können oder zu offensichtliche Fehler bei den Tests noch vorliegen (z. B. ein Download funktioniert nicht). Außerdem sollte entschieden werden, ob zu viele Fehler mit der Kategorie Blocker ggf. dafür sprechen, mit einem Release später auf eine gemeinsame Testumgebung zu gehen.
4. Testing
- Integrationstests
Wenn der letzte Schritt der Umsetzung getan ist, können die einzelnen Softwarepakete auf eine gemeinsame Umgebung gestellt, verbunden und getestet werden. Jetzt können alle definierten Integrations- und SST-Fälle geprüft und getestet werden. Die Daten und Testfälle wurden bestenfalls bereits in der Umsetzung definiert und müssen nun nur noch umgesetzt werden.
Auch hier ist es wichtig, dass die Schnittstellen und Datenflüsse in allen Varianten getestet wurden. Damit sind nicht nur die Positiv-Fälle gemeint (was funktionieren soll), sondern auch die Negativ-Fälle (was nicht funktionieren sollte).
Ab diesem Moment kann die gesamte Umgebung für die Abnahmetests freigegeben werden. In diesem Zuge sollten Accounts, Zugänge und Daten erzeugt werden, damit diese für die Abnahmetests zur Verfügung stehen.
- Abnahmetests
Die e2e-Tests mit den Daten können geprüft werden. Dabei sollten im besten Falle keine Abweichungen von den Anforderungen mehr festgestellt werden. Sollte dies dennoch vorkommen, kann es massive Auswirkungen auf die gesamte Lösung nach sich ziehen.
Wurde beispielsweise festgestellt, dass die Abhängigkeit von zwei Einstellungen falsch ist, muss bis in die Grundarchitektur der Lösung eingegriffen und damit der gesamte Prozess der Funktions- und Integrationstests wiederholt werden.
Beim Abnahmetest sollten im besten Fall nur Inhaltsfehler auftauchen, Werte ggf. falsch interpretiert werden oder bestimmte Daten nicht angezeigt werden. Am Ende stehen alle festgestellten und nach den Auswirkungen priorisierten Fehler. Auf diese Weise kann das Management entscheiden, ob ein Launch unter den vorliegenden Bedingungen sinnvoll ist oder nicht.
Insbesondere bei neuen Lösungen kann die Liste sehr lang sein. Man sollte dennoch nicht zu restriktiv damit umgehen. Handelt es sich nicht um wirkliche Blocker der Hauptprozesse, ist es oft ratsam, bereits mit der Lösung zu starten und die anderen Fehler im Live-Betrieb zu fixen. Nicht selten stellen sich vermeidbare Fehler als nicht so wichtig heraus und die Aufmerksamkeit für wichtige Fehler ist im Live-Betrieb oft deutlich höher als in der Entwicklungsphase.
5. Betriebsübergang
Die Betriebsübergangsphase beginnt für ein neues System bereits mit dem Testing bzw. schon vor dem Testing, falls diese für das Testing benötigt wird.
Hier werden alle notwendigen Informationen für alle Stakeholder über das System zusammengestellt. Angefangen bei reinen Informationen, wie etwa, dass das Tool live geht als Neuigkeit bis hin zu detaillierten Schulungsunterlagen für alle User-Gruppen.
Insbesondere bei neuen Systemen müssen diese detailliert sein sowie auch Fehlerbeschreibungen beinhalten, damit Funktionen, die gewollt waren, nicht als Fehler reportet werden.
Neben den erklärten Funktionen werden auch Timings verteilt.
- Technischer Betriebsübergang: Hier wird mit der Technik besprochen, welche Daten wann und in welches System eingespielt werden müssen, damit zum Launch alle Daten reibungslos laufen.
Bei neuen Systemen ist dies nicht so wichtig. - Fachlicher Betriebsübergang: Für die neuen Systeme sollte genau ein Timing für alle Stakeholder erstellt werden, mittels dessen beschrieben wird, welche Komponenten für welche User wann vorhanden sein werden.
- Ebenfalls wird geklärt, ob es eine interne Testphase für Mitarbeiter und anschließend einen Softlaunch gibt, ab wann die Vermarktung startet und wann mit höheren Aufkommen gerechnet wird.
6. Projektende und Stabilisierungsphase
Das Projektende sollte bei neuen Lösungen nicht zeitgleich mit dem Live-Gang erfolgen, sondern bis zu drei Monate nach dem Live-Gang eingeplant werden. Damit wird sichergestellt, dass die Projektmitarbeiter, die bis dahin über ein hohes Wissen verfügen, bei der Problemlösung den Mitarbeitern zur Verfügung stehen, die das System zwar ab dem Live-Gang betreuen, aber durch die kurze Zeit noch sehr wenig Erfahrung damit haben. Dies wird oft übersehen. Das Projekt endet nach dem Live-Gang, die Projektmitarbeiter verlassen das Projekt und die Betriebsmitarbeiter sehen sich mit Fragestellungen konfrontiert, die sie nicht beantworten können. Infolgedessen sind die Antwortzeiten zu lange oder die Probleme werden im schlimmsten Fall gar nicht gelöst.
Ist dies alles erledigt, konnte in ein neues digitales Projekt abgeschlossen und eine neue Software mit neuen Prozessen und neuem Know-how gelauncht werden. Somit können die gesteckten Ziele erfüllt werden.
Leave A Comment