- Die Implementierung beginnt mit einem Prototyp, in dem bereits Ketten von Geschäftsprozessen implementiert wurden, die vom Kunden als Ziel akzeptiert werden können. Gleichzeitig kann es Unterschiede geben, die während des Projekts beseitigt werden müssen.
- Um an dem Projekt zu arbeiten, wird ein einziges Team gebildet, das aus Beratern, Kundenvertretern aus dem Geschäft und dem IT-Service besteht. Kundenvertreter werden während des Projekts geschult und testen zusammen mit Beratern Systemprototypen, formulieren Systemanforderungen und akzeptieren deren Implementierung. Der IT-Service nimmt aktiv teil, implementiert einige der Anforderungen und nimmt am Ende des Projekts das System zur Unterstützung.
- Während des Projekts werden mehrere weitere Prototypen eingerichtet, die mit jeder Iteration den Anforderungen des Kunden näher kommen. Im Verlauf des Projekts werden die Anforderungen mehrfach festgelegt und geändert.
Tatsächlich werden in einem großen ERP-Implementierungsprojekt agile Prinzipien angewendet - Menschen und Interaktion sind wichtiger als Prozesse, ein funktionierendes Produkt ist wichtiger als Dokumentation, die Zusammenarbeit mit einem Kunden ist wichtiger als ein Vertrag und die Bereitschaft für Änderungen ist wichtiger als das Befolgen eines ursprünglichen Plans.
Unter den Bedingungen eines unterzeichneten Vertrags mit einem festen Preis, der mit einem großen einheitlichen System arbeitet, müssen diese Grundsätze jedoch landen. Ohne zusätzliche Bedingungen und Einschränkungen wird das Projekt höchstwahrscheinlich nicht abgeschlossen und wird sicherlich über das Budget hinausgehen.
Erstens ist dies keine Systementwicklung, die in Teilen gestartet werden kann, wie dies häufig bei agilen Projekten der Fall ist, wenn jede Iteration mit der Entwicklung eines vollständigen funktionsfertigen Funktionsblocks enden muss. Ein ERP-System kann nur vollständig und nicht in Teilen ausgeführt werden.
Zweitens, wenn Sie die Anforderungen nicht einschränken, sind ihre Klärung und Änderung endlos, das Projekt wird sich ausdehnen und zusätzliche Mittel erfordern.
Das erste Problem besteht also darin, dass das ERP-System aus Teilen besteht, die eng miteinander verbunden sind und von End-to-End-Prozessen durchdrungen sind. Daher brauchen wir bei jeder Iteration ein ganzheitliches System in seinem gesamten Umfang. Die Aufgabe wird dadurch erleichtert, dass das System nicht von Grund auf neu erstellt wird, sondern ein fertiges Produkt ist. Es gibt häufig eine Branchenlösung oder ein vorkonfiguriertes System mit Standardprozessen, die Sie als ersten funktionierenden Prototyp verwenden können.
Die Vorbereitung des nächsten Prototyps braucht Zeit. Das System ist groß, komplex, es gibt viele Projektteilnehmer, daher dauert es mindestens zwei Monate, um einen Prototyp vorzubereiten, zu testen und Kommentare dazu abzugeben. In unserem Fall sind Iterationen nicht zwei Wochen, wie in einem typischen agilen, sondern 2-5 Monate.
Bei jeder Iteration erstellen wir ein vollständiges System, aber es gibt Unterschiede zwischen ihnen. In der ersten Iteration ist dies ein typisches System mit Standard- oder branchenspezifischen Prozessen. Standardprozesse können weit von dem entfernt sein, was der Kunde am Ende erwartet. Die Prozesse auf der obersten Ebene sind die gleichen, aber die Details werden sehr unterschiedlich sein. Wenn ich "Kunde" sage, meine ich Personen, die das System verwenden - unabhängig davon, welche Beziehung ihn mit dem Auftragnehmer verbindet - vertraglich oder es ist ein internes Projekt des Unternehmens, bei dem der Auftragnehmer die IT-Abteilung sein kann.
Nachdem wir die Anforderungen basierend auf den Ergebnissen des Testens des ersten Prototyps gesammelt haben, richten wir den zweiten Prototyp ein, in dem alle Anforderungen implementiert werden, die mit den Einstellungen implementiert werden können, die Testdaten des Kunden geladen werden und alle Fragen, die beim Testen des ersten Prototyps aufgetaucht sind, ausgearbeitet werden. Der Kunde durchläuft die Geschäftsprozesse im System, prüft, inwieweit die aktuelle Implementierung passt, wie effizient das System ist und erfüllt seine Anforderungen.
Bei der zweiten Iteration sehen zukünftige Benutzer des Systems es nicht zum ersten Mal, fühlen sich wohler und stellen neue Anforderungen, die bereits aussagekräftiger und detaillierter sind. Im Idealfall sollten alle wichtigen Probleme in diesem Zeitraum behoben werden, da Änderungen umso teurer werden, je weniger Zeit vor dem Start verbleibt.
Bereits bei der dritten Iteration können wir es uns leisten, mit der Entwicklung von Erweiterungen oder, wie wir es im Jargon nennen, "Anpassungen" des Systems zu beginnen. Dies können Berichte, Verfahren und Formulare sein, die im Standardsystem fehlen, aber sie sind sehr notwendig, da es nicht immer möglich ist, Geschäftsprozesse an den Standard des Systems anzupassen. Die Entscheidung, Erweiterungen zu entwickeln, wird unter Berücksichtigung aller anderen Möglichkeiten getroffen, da Ihre Entwicklung und Unterstützung ist ein ziemlich teures Vergnügen, und dies ist zusätzliches Geld.
Wir bereiten den dritten Prototyp seit mehreren Monaten vor, damit er zu einem vollwertigen System in der Nähe des Zielsystems wird. Normalerweise ist das System vollständig konfiguriert, dort wird eine erhebliche Datenmenge geladen, alle kritischen Erweiterungen werden installiert. Es wird sehr gründlich mit einer großen Anzahl von Benutzern getestet. Dieser Test dauert normalerweise etwa einen Monat.
Nach dem Testen des dritten Prototyps bleiben Kommentare und Fragen übrig, zu denen wir einen Plan für deren Entwicklung erstellen. Und alle kritischen Bemerkungen sollten bis zum Start beseitigt werden.
Das Tempo des Projekts wird zu diesem Zeitpunkt sehr intensiv, die Zeit wird wie während eines Kampfes komprimiert. Es ist notwendig, Anweisungen vorzubereiten, Benutzer zu schulen, Daten zu konvertieren und organisatorische Änderungen vorzunehmen. Zuvor ungelöste Probleme tauchen auf, jemand erinnert sich, dass er vergessen hat, einen wichtigen Umstand anzukündigen ... Vor dem Start werden noch einmal Abnahmetests durchgeführt - und dann der Start eines neuen Systems.
Dies ist natürlich eine sehr oberflächliche Beschreibung des iterativen Ansatzes zur Implementierung eines ERP-Systems. Die Methodik beschreibt detailliert alle Prozesse, einschließlich Dokumentation, Schulung des Projektteams und der Benutzer, Datenkonvertierung, organisatorische Änderungen usw., die sich in der Tat nicht von anderen Ansätzen für das Projektmanagement unterscheiden.
Es stellt sich eine vernünftige Frage: Wie kann der Prozess so organisiert werden, dass nicht zur vierten und dann zur fünften oder sechsten Iteration übergegangen wird? Wie können Sie das Risiko unkontrollierter Änderungen und der Klärung von Anforderungen vermeiden, die sich natürlich entwickeln, wenn Sie sich mit den Details befassen, und manchmal aufgrund von geschäftlichen Änderungen?
Natürlich besteht ein solches Risiko, und es ist sehr bedeutend. Am Eingang des Projekts sind die Anforderungen im Vertrag festgelegt, aber in der Regel werden sie allgemein formuliert, und der Teufel steckt im Detail.
Mit dem "Wasserfall-Ansatz" zu Beginn des Projekts werden die Anforderungen festgelegt, der technische Auftrag wird unterzeichnet, was später zu einer formalen Grundlage wird, um die Änderung der Anforderungen abzulehnen oder zusätzliches Geld für die Änderung anzufordern. In einem iterativen Ansatz ist dieser Trick nicht anwendbar.
Wir verstehen, dass sich die Anforderungen ändern können und sich ohne Zweifel ändern werden. Wir investieren in Zeit und Geld. Die Frage ist das Ausmaß dieser Änderungen. Wir können einen großen Fehler machen und am Ende eine Welle neuer Kommentare erhalten, insbesondere wenn der Kunde zunächst auf die Teilnahme am Projekt "Slipshod" verweist, die falschen Personen für die Teilnahme auswählt, keine klaren Anforderungen formuliert, hofft, dass "alles gut wird". verlässt sich auf Berater - dann haben wir am Ende ernsthafte Probleme.
Daher ist die Einbeziehung der Kunden die wichtigste Komponente zur Reduzierung des Risikos, dass sich die Anforderungen am Ende des Projekts ausbreiten. Dieselbe Umsetzung des Prinzips der agilen Entwicklung, nach der das Team zusammenarbeitet - der Kunde und der Entwickler, die von Beginn des Projekts an in engem Kontakt stehen. Dies hat mehrere wichtige Konsequenzen. Erstens, frühzeitiges Erkennen der tatsächlichen Bedürfnisse und Nichteinhaltung dieser Bedürfnisse des Systems. Zweitens wird der Kunde, der in den Prozess der Vorbereitung des Systems involviert ist, nicht zum Zeitpunkt seiner Übertragung in seiner fertigen Form, sondern schrittweise während des gesamten Projekts Eigentümer. Es wird das Ergebnis seiner Arbeit, und am Ende des Projekts wird es unmöglich, Behauptungen wie „Ihr System funktioniert nicht“ aufzustellen, da dies sein System ist.
Es ist eine gute Praxis, wenn die qualifiziertesten Personen, die in der Lage sind, Entscheidungen zu treffen, zu 100% dem Projekt zugewiesen werden. In unserer Praxis waren dies die Eigentümer von Geschäftsprozessen, ihre Stellvertreter oder Mitarbeiter, die das volle Vertrauen der Servicemanager genießen. Ja, es ist schwierig, ja - es gibt keine zusätzlichen Leute, ja - es ist schwierig, das Beste zu geben. Dies ist jedoch die einzige Möglichkeit, ein Projekt schnell zu erstellen und ein qualitativ hochwertiges System zu erhalten. Die Projektteilnehmer erhalten einen großen Sprung in das Verständnis der Funktionsweise eines Unternehmens, erwerben neues Wissen, lernen, auf neue Weise zu arbeiten, und schaffen in der Regel neue Karrieremöglichkeiten für sie. Sie können das ERP-Implementierungsprojekt als äußerst leistungsfähiges Ereignis zur Personalentwicklung betrachten, als Schaffung einer neuen Personalreserve für Manager.
Das zweite, was zu beachten ist, sind die engen Zeitbeschränkungen des Projekts. Der Projektplan sollte aggressiv sein und das Startdatum sollte sich nicht ändern. Wenn das Projekt gestreckt ist, steigt die Wahrscheinlichkeit, dass sich die Geschäftsanforderungen ändern. Wenn sich das Projektdatum verschiebt, neue Anforderungen angezeigt werden und sich die Situation wiederholt: Auch wenn das System noch nicht bereit ist, verschieben wir den Start. Die Perfektion der Systeme wird auch bei sehr langen Projektlaufzeiten nicht erreicht, und alle Anforderungen werden vor dem Start nie vollständig identifiziert. Nur der echte Betrieb zeigt alle Engpässe und was wirklich wichtig ist. Daher gibt es nach dem Start eine Stabilisierungsphase von mindestens drei Monaten, in der das Projektteam den Benutzern hilft und sie schult, Fehler korrigiert, neue Anforderungen erhält und die erforderlichen Verbesserungen vornimmt.
Um der Versuchung zu widerstehen, Fristen zu verschieben und Anforderungen zu erweitern, muss jeder einen starken Anreiz haben, diese Fristen einzuhalten. Für den Auftragnehmer sind dies natürlich vertragliche Verpflichtungen und ein Budget. Die Motivation des Kunden wird in der Regel von oben, vom Management oder von den Aktionären des Unternehmens gebildet. Zum Beispiel kann ein CEO, der eine Entscheidung über die Startbereitschaft trifft, durch eine Verpflichtung gegenüber den Aktionären gefesselt sein. Der Projektmanager und das Projektteam können vorbehaltlich der Fristen durch einen Bonus am Ende des Projekts motiviert werden. Die Abteilungsleiter werden mit der Notwendigkeit konfrontiert sein, im Auftrag des Unternehmens zu starten.
Es kommt sehr selten vor, dass das System aufgrund der angenehmen Erwartungen an die neuen Möglichkeiten, die es bietet, ernsthaft so schnell wie möglich eingeführt werden soll. Das neue System ist in erster Linie Stress und die Notwendigkeit, von der vertrauten zur anfänglich unbequemen Schnittstelle überzugehen, mehr Kontrolle zu erlangen und mehr Informationen einzugeben. Endbenutzer begrüßen fast nie ein neues System. Es braucht Zeit, bis sie sich zurechtfinden und darin Vorteile finden. Und wenn die interne Motivation zum pünktlichen Start zunächst nicht in das Projekt integriert ist, wird der Start verschoben, da die Systeme niemals zu 100% startbereit sein werden.
Angesichts der engen Startdaten wird es unmöglich, die Anforderungen endlos zu erweitern und zu verfeinern. Das Projektteam, dem Vertreter des Kunden angehören, hört auf, sie zu nominieren, und beginnt, über Prioritäten nachzudenken, über die Möglichkeiten, etwas zu verschieben, angesichts einer unvermeidlich bevorstehenden Frist. Die Aufgabe des Projektmanagers besteht von Anfang an darin, das Gefühl eines bevorstehenden Starts und Zeitmangels zu erzeugen. Die zu ruhige Atmosphäre in der ersten Hälfte des Projekts bedeutet, dass die zweite Hälfte aufgrund des unvermeidlichen Rennens extrem stressig sein wird. Dazu müssen Zwischenziele festgelegt werden, und der Projektplan wird so erstellt, dass die ersten Phasen des Projekts zeitlich komprimiert werden. Aus diesem Grund wird eine Reserve für die letzten Phasen vor dem Start gebildet. Beim Langstreckenlauf gibt es verschiedene Strategien.Aber hier sollte die Strategie dieselbe sein - Sie müssen von Anfang an schnell laufen, möglicherweise haben Sie nicht genug Kraft, um am Ende zu beschleunigen.
Zusammenfassung aller oben genannten Punkte:
- Der iterative Ansatz liefert ein viel besseres Ergebnis in Bezug auf die Nähe des Systems zu den angegebenen und implizierten Kundenanforderungen.
- Die vollständige Einbeziehung des Kunden in das Projekt ist für die Umsetzung dieses Ansatzes unbedingt erforderlich.
- Um die Verbreitung und endlose Verfeinerung von Anforderungen zu vermeiden, müssen die Projektfristen eng begrenzt und die Projektteilnehmer motiviert werden, diese zu erfüllen.
Natürlich sind dies nur die Grundprinzipien, es gibt viel mehr Feinheiten, die von den spezifischen Bedingungen, den Merkmalen des Unternehmens und der Persönlichkeit der Teilnehmer abhängen. In jedem Fall wird alles individuell entschieden.