Es ist wirklich überraschend, wie viele große Firmen von fehlgeschlagenen Softwarevorhaben zurückgehalten, abgelenkt oder gar ruiniert wurden. Oftmals sind Unternehmen letztendlich dazu gezwungen, weit mehr für ihr Projekt auszugeben, als ursprünglich vereinbart worden war. Und es gibt Projekte, die einfach niemals enden wollen. Ungeachtet der jeweiligen Spezifikationen führt das Scheitern von Softwareimplementierungen unweigerlich sowohl für den Kunden als auch den Anbieter zu enormem Stress und wahren Horrorszenarien.
Es geht dabei nicht um eine Schuldzuweisung. Bereits eine schnelle Internetsuche liefert unzählige Beispiele solcher Softwarekatastrophen, die Massenkarambolagen auf der Autobahn gleichkommen.
Dabei reicht es nicht aus, sich den Fallstricken an sich bewusst zu sein. Was man braucht, sind neue Ansätze, neue Implementierungsmethoden und neue Arten der Systemverwaltung, um die jeweiligen Risiken drastisch zu verringern.
Dieser Artikel baut auf den Erfahrungen von RELEX der vergangenen 8 Jahre auf. Wir tun nicht so, als ob wir alle Antworten hätten – jedes Softwareunternehmen, das so tut, als hätte es alle Antworten, hat entweder nicht die richtigen oder nicht genug Fragen gestellt.
Unser Ansatz hat uns und unseren Kunden bisher hingegen stets dabei geholfen, viele typische Probleme groß angelegter Systemimplementierungen zu umgehen.
Was ist also das Geheimnis? Nun, es ist kein wirkliches Geheimnis, es ist eher ein wichtiges Prinzip: Agilität. Unserer Meinung nach sollten Firmen auf agile Prozessentwicklung achten, und im Folgenden erklären wir auch, warum.
Wenn die Softwareimplementierung beschwerlich ist, heißt das dann, dass sie funktioniert?
Mit einem Wort: Nein.
Bei vielen großen Softwareprojekten (ein gutes Beispiel wären hier ERP-Implementierungen) werden bereits ganz zu Anfang Probleme oder gar effektives Versagen mitprogrammiert. Der Begriff Wasserfallmodell gehört zu den Schlagwörtern der traditionellen Strategien der Softwareentwicklung und gilt heutzutage jedoch weitgehend als unzulänglich. Bei diesem Ansatz soll der Kunde gleich von Anfang an alle Ziele und Anforderungen definieren. Sein Grundgedanke entstammt der Maschinenbauindustrie oder auch dem Bauwesen, aber wenn er auf Software angewandt wird, führt dies zu enormen Problemen. Die agile Softwareentwicklung steht mit diesem Ansatz hingegen in klarem Kontrast und wird sehr häufig als bessere Alternative aufgeführt.
Bei RELEX setzen wir den gleichen Gedanken auch für Prozesse um, denn wenn man Lieferkettenverwaltungssysteme implementiert, gilt die Hauptsorge erstmal der Prozessoptimierung und erst anschließend baut man das System um das Modell herum – und nicht umgekehrt.
Während das Wasserfallmodell heutzutage im Bereich der Softwareentwicklung allgemein in Verruf geraten ist, findet es bei der Prozessentwicklung leider immer noch viel zu häufig Anwendung. Daher hält sich dort weiterhin die äußerst fragwürdige Sitte, von Kunden zu verlangen, den Leistungsumfang ihrer Projekte von Anfang an genaustens zu bestimmen, bevor diese das jeweilige System überhaupt verwendet haben. Oftmals kennen sie das System gerade einmal aus Demonstrationen und meistens nicht aus zahlreichen. Diese Vorabbestimmung ist eine fast unmögliche und dazu noch unsinnige Aufgabe, bei der die Probleme sich mit der Größe des Projekts vervielfachen.
Weiterhin kann das Wasserfallmodell dazu führen, dass Personen Entscheidungen treffen sollen, die nicht wirklich über die dafür nötige Expertise verfügen. Beispielsweise sind die Mitarbeiter des Kunden, die an der Spezifikationsphase von Anwendungssoftware für Lieferketten teilnehmen, nicht unbedingt auch IT-Experten. Ihre Kompetenzen decken eher die Lieferkettenverwaltung, Bevorratung oder die Produktverwaltung ab. Üblicherweise bringt es nur wenige Vorteile, sie zu bitten, technische IT-Spezifikationen zu verfassen und dafür umso mehr Nachteile. Dazu kommt, dass es in der Regel sehr schwierig ist, die beste Alternative zu definieren, ohne den jeweiligen Prozess und das System bei der tagtäglichen Arbeit verwendet zu haben.
Was ist also die Antwort?
Vor allem sollten Spezifikationen aus einer Zusammenarbeit und nach effektiver Anwendung entstehen.
Bei diesem Ansatz ist das Ziel der Spezifikationsphase nicht das Definieren aller Details der Software, sondern ein allgemeines Verständnis der Softwareanwendung, was die wichtigsten Verwendungsmöglichkeiten und Prozesse betrifft. Die Spezifikation sollte daher eher als eine Hypothese aufgefasst werden, die sich noch verändern wird, nachdem die Anwender Erfahrungen mit der Software bei routinemäßigen Aufgaben sammeln konnten.
Unserer Erfahrung nach ist es am hilfreichsten, sich auf 3–5 Kernprozesse zu konzentrieren, wie beispielsweise Sortimentsverwaltung, Stammdatenpflege, Bestellungen/Nachbestellungen und der Umgang mit kniffligen Nachfragesituationen (wie bei Produkteinführungen, Werbekampagnen etc.). In den meisten Fällen reicht ein jeweils dreistündiger Workshop zu jedem Thema, um einen Überblick über die aktuelle Situation zu erhalten und die letztendlichen Ziele jedes Prozesses zu ermitteln. Der wichtigste Zweck dieser Phase ist das Identifizieren von Rollen und Verantwortlichkeiten im Rahmen der einzelnen Prozesse, bevor das System schließlich live geht (sogar noch vor der Pilotphase).
Wenn die Spezifikation vollständig ist, müssen nun die Ärmel hochgekrempelt werden, damit das System ins Rollen gebracht wird. Erfahrungsgemäß werden dazu 4 bis 8 Wochen benötigt. Anschließend kann der Kunde das System während der Pilotphase testen. Üblicherweise geschieht dies erst einmal für eine einzige Produktgruppe oder eine kleine Anzahl von Lagergütern. Bei dieser Gelegenheit sieht der Anwender, wie das System eigentlich innerhalb der eigenen betrieblichen Prozesse funktioniert, was es sehr viel einfacher macht, Änderungen vorzuschlagen. Basierend auf diesem Feedback stimmen Anbieter und Kunde das System dann gemeinsam detailliert ab, damit die Kundenbedürfnisse, die sich durch dessen wachsendes Systemverständnis ergeben, auch umgesetzt werden können. Dies kann stufenweise während der Pilotphase geschehen (üblicherweise dauert diese 3 Monate).
Dieser Ansatz wird kaum revolutionär erscheinen, wenn man sich mit dem agilen Ansatz bei Softwareprojekten auskennt. Agile Methoden sind in den letzen 10 Jahren immer beliebter geworden und werden von zahlreichen Softwareunternehmen erfolgreich eingesetzt. RELEX selbst nutzt den agilen Ansatz weitreichend bei der eigenen Softwareentwicklung.
Um die Wichtigkeit der Agilität bei Softwareimplementierungen zu verstehen, ist es unerlässlich, erst einmal zu begreifen, dass diese sich von der agilen Softwareentwicklung unterscheidet. Es gehört zu den Voraussetzungen, dass die Software, die es zu implementieren gilt, von Natur aus agil ist – also leicht konfigurierbar und anpassbar. Die Agilität bei Implementierungen betrifft hauptsächlich die agile Geschäftsprozessentwicklung. In der Praxis heißt das: Wird während der Pilotphase der Bedarf an neuen Geschäftsprozessen erkannt, werden entsprechende Änderungen in der Software vorgenommen, durch die Anpassung der Berechnungslogik. Die Agilität bedeutet, dass solche Änderungen jedoch nicht von Softwareentwicklern vorgenommen werden, sondern von den Beratern des Softwarelieferanten und im Laufe der Implementierung immer häufiger von den Super-Usern des Kunden. Die eigentlichen Prozessexperten sind diejenigen, die das System nutzen, und der Ansatz von RELEX basiert auf dem Glauben, dass diese auch die Möglichkeit haben müssen, gewünschte Änderungen vorzunehmen, sobald und in dem Umfang, in dem Änderungsbedarf anfällt. Nur so wird der Prozess letztendlich seinem Ziel gerecht.
Wenn ich tanzen kann, wieso hat jeder andere dann zwei linke Füße?
Die Idee hinter agiler Geschäftsprozessentwicklung ist einfach: Man beginnt mit dem bestmöglichen Strategieplan, ist aber stets in der Lage, einen anderen Weg einzuschlagen, wenn sich während der Verwendung neue Bedürfnisse ergeben. Der Strategieplan soll als Ausgangspunkt und Richtlinie gelten, aber der endgültige Zweck ist es, schnell, zufrieden und sicher ans Ziel zu gelangen. Was sollte also daran auszusetzen sein, wenn man auf eine solide IT-Unterstützung zurückgreifen kann?
Sprich, die Frage ist eigentlich: „Warum agieren nicht mehr Softwareunternehmen auf diese Weise?“ Die Antwort lautet: „Weil es nicht einfach ist.“ Dieses Betriebsmodell stellt hohe Ansprüche an die Software selbst sowie an das Implementierungsteam und Geschäftsmodell des Kunden.
Die fundamentalste Anforderung dabei ist, dass die für das Projekt verwendete Software oder Plattform flexibel ist. Bei der agilen Prozessentwicklung muss es fortwährend möglich sein, Anpassungen am System vorzunehmen und mehr oder weniger unmittelbares Feedback dazu zu erhalten, damit die Auswirkungen jeder Anpassung analysiert werden können. Wenn die Software bzw. Plattform nicht für schnelle und einfache Anpassungen ausgelegt ist, stellt man schnell fest, dass es entweder gar nicht möglich ist oder dass es weitaus mehr Geld kosten könnte, als man dachte.
In der Praxis wird wohl eines der Hauptmerkmale die In-Memory-Analyse sein, bei der Daten im Arbeitsspeicher gehalten werden und nicht auf einem Festplattenlaufwerk. Dadurch können große Datenflussmengen in Sekunden anstatt in Stunden oder Tagen verarbeitet werden. Dank dieses Merkmals erhält man bei jeder Anpassung unmittelbares Feedback. Verarbeitungsverzögerungen, wie sie typisch für Systeme sind, die auf Festplattenlaufwerken gespeicherte Daten verarbeiten, bedeuten, dass man nur so schnell Anpassungen vornehmen kann, wie das System antwortet. Bei RELEX ist Flexibilität genau die Qualität, nach der wir am meisten streben, und ist daher auch das Ziel, in das unsere Forschungs- und Entwicklungsteams die meiste Zeit investiert haben. Das Ergebnis sind äußerst effiziente spontane Kalkulationen und Datenwürfelberichterstattungen, dank derer alle Produktstammdaten und Bestandsmetriken (sowie andere Daten) als Such- und Berichtkriterien verwendet werden können. Dadurch wird die Implementierung von Änderungen, die im Laufe der Zeit durch vermehrte Erfahrungen und neue Umstände erforderlich wurden, äußerst einfach – beispielsweise für das Bearbeiten von Bestellvorschlägen.
Dazu kommt, dass man wissen muss, welche Fragen man während der Spezifikationsphase zu stellen hat, die sich von Fall zu Fall unterscheiden. Wer definiert den Handelssortiment und wie wird entschieden welche Sortimentsartikel in welchen Niederlassungen aufgestockt werden müssen? Wie soll bei zukünftigen Verkaufskampagnen die Kommunikation mit dem Einkauf stattfinden und was soll der Verkauf mit solchen Informationen tun? Was sind die wichtigsten Leistungskennzahlen (Key Performance Indicators) dieses Projekts? Es ist unvermeidbar, dass einige dieser Fragen in dieser Phase noch unbeantwortet bleiben. Vor allem muss man natürlich den Zielprozess begreifen. Dies ist nicht jedes Mal direkt von Anfang an der Fall und oftmals erhält man das nötige Verständnis durch das Sammeln von Erfahrungen. Die Fachkenntnisse der Berater helfen dabei, für jedes Kundenbedürfnis maßgeschneiderte Lösungen zu finden.
Und letztendlich kommt es auch darauf an, dass der Anbieter und der Kunde die gleichen Ziele haben. Wenn der Anbieter direkt von Anfang an Kosten berechnet und/oder nach oben offenen Beratungsgebühren anfallen, die immer größer werden, je länger das Projekt dauert, werden Anreize geschaffen, Projekte so weit wie möglich in die Länge zu ziehen. Dies steht im völligen Gegensatz zu den besten Interessen des Kunden. Die besten Konditionen sind die, bei denen Anreize dahingegen strukturiert sind, dem Kunden schnell und effizient ein leistungsstarkes System zu bieten, und den Anbieter dafür belohnen, dass er für einen langfristigen und reibungslosen Betrieb gesorgt hat. Wenn ein Anbieter ein System liefern kann, das nicht permanent von ihm oder Drittunternehmen unterstützt werden muss, dann ist auch dies für den Kunden von großem Vorteil und für den Anbieter profitabel.
Fallbeispiel: Vianor – die führende Reifenvertriebskette in Nordeuropa
Als sehr gutes Beispiel für den Arbeitsansatz von RELEX kann das Implementierungsprojekt angeführt werden, das RELEX mit Vianor durchgeführt hat. Schon sehr früh war bei diesem Projekt erkenntlich, dass die größte Herausforderung darin bestehen würde, erstens die Prozesse der Sortimentsverwaltung und Warennachschubplanungssysteme zu definieren und zweitens die Änderungsverwaltung – vor allem innerhalb der Verkaufsstellen von Vianor.
Nehmen wir die Sortimentsverwaltung als Beispiel. Zu Beginn des Projekts waren keine klaren Sortimentsverwaltungsprozesse vorhanden, da die Verantwortung für Bestellungen bei den Verkaufsstellen lag. In Zusammenarbeit mit RELEX erstellte das Entwicklungsteam von Vianor ein Modell, bei dem das saisonale Sortieren für jede Pilotverkaufsstelle durch XYZ-Klassifizierungen definiert wurde und auf Verkaufszahlen basierte. Anstatt vorab zu viel Zeit mit der Definierung des Modells zu verbringen, entschied sich das Team für einen Frühtest des ersten Modells gemeinsam mit dem Verkaufspersonal im Kundenbereich von Vianor, um dieses dann je nach Feedback des Personals zu modifizieren.
Zu Beginn der Pilotphase waren die Verkaufsstellen im Allgemeinen zufrieden, aber man stellte auch schnell fest, dass es bestimmte Kundenanfragen gab, die bestellt werden mussten, obwohl sie nicht zum Sortiment gehörten. Zusammen mit RELEX wurde beschlossen, dass eine Erweiterung des Kauf-nach-Auftragseingang-Modells (Purchase-to-Order model) die beste Lösung darstellen würde. Diese Lösung wurde innerhalb weniger Tage implementiert und zügig mit den Pilotverkaufsstellen getestet. Nach dem das Feedback zu dieser Lösung positiv ausfiel, wurde sie zu einem wesentlichen Bestandteil des neuen Modells.
In der späten Pilotphase verwendeten immer mehr Verkaufsstellen das neue System für Nachbestellungen. Dabei fiel auf, dass das Modell besser zu den größeren Verkaufsstellen passte, die umfangreichere Sortimente empfingen. Andererseits erkannten die kleineren Verkaufsstellen, dass sie ein etwas größeres Sortiment benötigten. Wieder nahmen die Teams einige schnelle Veränderungen an den Systemkalkulationen vor, testeten sie am nächsten Tag und fügten sie anschließend dem Pilotmodell hinzu. Die Änderungen kamen sehr gut an und blieben im Modell.
Diese zwei Herausforderungen, denen sich Vianor gegenübergesehen hatte, kommen bei der Geschäftsprozessentwicklung häufig vor. Man kann die Auswirkung einer Routine erst dann wirklich sehen, wenn sie implementiert wurde. Daher ist es unerlässlich, dass ausreichend inhärente Flexibilität vorhanden ist, um ein Betriebsmodell anpassen zu können, nachdem ein neuer Ansatz vor Ort getestet wurde.
Dank RELEX war Vianor in der Lage, seine Spitzenbestände um 30 % zu verringern, ohne dass dies negative Auswirkungen auf die Verfügbarkeit nach sich gezogen hätte. Der Logistik Manager Markus Huttunen von Vianor hat sich vom agilen Prozessentwicklungsmodell von RELEX überzeugen lassen:
„Das Implementierungsprojekt lief unglaublich glatt ab und alle Hürden, denen wir uns gegenübersahen, wurden praktisch innerhalb von 24 Stunden gelöst – und sogar gänzlich neue Funktionen wurden innerhalb von wenigen Tagen eingeführt. Die größte Herausforderung des Projekts bestand darin, zu definieren, was wir wirklich brauchten. Und dank der Fachkenntnisse von RELEX mit Lieferketten konnte uns deren Team erfolgreich dabei helfen, unsere Ziele effizient zu erreichen.“
Was muss ich nun tun?
Wenn Sie daran denken, ein neues Softwaresystem zu kaufen, gibt es einige Schlüsselpunkte, die Sie beachten sollten. Es ist sehr wahrscheinlich, dass Ihre Prozesse sich im Laufe der Zeit verändern werden. Und es ist so gut wie sicher, dass sich Ihre Meinung über Ihre effektiven Bedürfnisse durch die Verwendung des Systems auch verändern wird. In Anbetracht dessen sollten Sie sich fragen, ob Sie nicht besser mit einem System bedient wären, dass Sie selbst Ihren Bedürfnissen entsprechend konfigurieren können, ohne immer wieder ein neues Softwareprojekt ins Leben rufen zu müssen.
Bei RELEX berechnen wir keinerlei Lizenzgebühren, bis der Kunde nicht die Gelegenheit hatte, im Rahmen einer Pilotphase sicherzustellen, dass die Software wirklich die Zielprozesse unterstützt und eine Wirtschaftlichkeitsberechnung deren Verwendung sinnvoll macht. Da wir nur dann bezahlt werden, wenn diese Ziele auch erreicht wurden, haben wir ein starkes Eigeninteresse daran, alles Erdenkliche zu tun, um die bestmögliche Lösung zu liefern. Daher machen wir die Kundenprobleme zu unseren eigenen Problemen.
Über Vianor
Vianor gehört zur Unternehmensgruppe Nokian Tyres und ist eine globale Reifenvertriebs- und Fahrzeugdienstleistungskette mit Verkaufsstellen sowohl im Private-Equity-Besitz als auch in unternehmerischer Hand. Wir bieten Rundumservice im Reifengeschäft für alle Kundengruppen, Produkte und Fahrzeugdienstleistungen. Vianor ist die größte Reifenvertriebskette Skandinaviens. Ende 2012 zählten 1037 Verkaufsstellen in 26 Ländern zu Vianor. Der Name Vianor entstammt den lateinischen Wörtern „via“ und „nor“ mit der Bedeutung „Weg des Nordens“.“
