Das alte Programm ist dann am besten, wenn man es den Usern wegnimmt

Letzte Woche war ich in Olten bei der Lernwerkstatt und besuchte die Ausbilder-Akademie 2018. – Für alle Ausbildner übrigens ein sehr empfehlenswerter Anlass. – Während des Seminares „Change Management für Ausbildner_innen“ fiel der Satz: „das alte Programm ist dann am besten, wenn man es den Usern wegnimmt.“

Bei mir hat dieser Satz sofort zu einem Grinsen auf den Stockzähnen geführt. Wie oft ich während ERP Einführungen den Satz „im alten Programm lief das aber anders/besser/schneller/einfacher/etc.“ gehört habe, weiss ich nicht mehr, aber es war mehr als einmal.

Für den Anwender ist ein Wechsel des ERP System ein grosser Eingriff in seine tägliche Arbeit. Arbeitsschritte kommen hinzu oder fallen weg, Knöpfe sind nicht mehr da wo sie waren, Listen haben ein anderes Layout, Daten müssen anders gepflegt werden, eventuell werden die Prozesse auch noch geändert, so dass er nicht nur die Software, sondern auch noch die Abläufe lernen muss. Dies kann es sehr dazu führen, dass das alte System, möge es auch noch so eingeschränkt und fehleranfällig gewesen sein, viel besser scheint als es effektiv ist. Der User wusste genau was wo und wie genau zu tun ist. Jetzt muss er sich umstellen – das bringt ein grosses Frustrationspotential mit sich.

Es geht mir in diesem Beitrag jedoch nicht um den Change Prozess der Anwender. Ich möchte Instrumente aufzeigen die es den Projektleitern erlauben das Frustrationsrisiko bei den Anwendern zu senken kann.

Werbung / Management Support
Wichtig scheint mir, dass die Person, welche das System vorstellt zu 100% von der neuen Lösung überzeugt ist und dies auch vermitteln kann. Gleichzeitig hilft es enorm, wenn das Management hinter der neuen Lösung steht und kräftig Werbung für die neue Lösung macht. – Nichts ist schlimmer als wenn bei einer Schulung der Schulungsleiter sagt: „Ach, ich will die Lösung doch auch nicht, aber wir müssen jetzt halt.“

Trainer müssen sicher sein
Bei einer Schulung der Lösung muss der Ausbildende wissen was er schult, wie es funktioniert und er sollte auf Fragen vorbereitet sein. Viele Firmen setzen bei der Einführung von ERP Lösungen auf das Train-the-Trainer Konzept. Dabei werden die Key-User ausgebildet werden und geben ihr Wissen dann an die User weiter. In solchen Fällen empfehle ich, dass sich die Key-User gegenseitig einmal schulen um Übung im Unterrichten und in der Software zu erhalten. Wenn es möglich ist, so kann man in diesem Testlauf ein einzelnen User hinzuziehen, der so eine Endanwenderperspektive einbringt. – Nichts ist schlimmer als wenn bei einer Schulung der Schulungsleiter sagt: „Ach ich weiss auch nicht wies geht, versucht es doch mal selber.“

Das System muss stabil sein
Bei den Endanwenderschulungen und den Tests durch die User muss das System möglichst fehlerfrei laufen. Wenn zwei Wochen vor der geplanten Einführung eine Schulung gemacht wird und die Hälfte nicht läuft, so kann das zu grosser Verunsicherung bei den Anwendern führen.

Zeit geben und begleiten
Gebt den User Zeit, sich mit dem neuen System und den neuen Prozessen zu befassen. Macht ein paar Tagen nach den Tests oder dem Go-Live nochmals eine Schulung, bei dem die offenen Fragen geklärt werden können. Definiert eine Anlaufstelle, wo sich der User melden kann bei Fragen. Idealerweise hat jede Abteilung einen Key-User der vor Ort ist. Erstellt zusätzlich eine Anwenderdokumentation für die neue Umgebung.

Abschiedsritual fürs alte System durchführen
Nehmt Abschied von den alten Prozessen, dem alten System, der alten Denk- und Arbeitsweise. Das muss nichts Kompliziertes sein: fahrt gemeinsam den alten Server runter, macht einen Apéro, schreibt alle Unzulänglichkeiten des alten Systems auf und verbrennt diese.

Diese Aufzählung ist weder vollständig noch abschliessend noch für jedes Projekt nötig. Vielleicht hilft es dem einen oder anderen jedoch sich schneller in der neuen Situation zurecht zu finden und schneller wieder die gewohnte Leistung zu erbringen.

 

Wieviel Pflichten- / Lastenheften macht Sinn?

Diese Woche hatte ich wieder einmal ein Newsletter vom ERP – Hersteller Oxaion in meiner Inbox. Die folgenden Zeilen daraus führten dazu, dass ich den Newsletter etwas genauer anschaute: 

„Projektstrukturen in Unternehmen werden zunehmend agiler, dementsprechend werden auch Softwareprojekte immer agiler, sprich inkrementell und iterativ umgesetzt. Da erscheint ein starr geführtes Lastenheft erstmal wie ein Relikt aus einer anderen Zeit. Doch gerade für mittelständische Unternehmen ist die Einführung einer Unternehmenslösung nach wie vor ein komplexes Projekt, das Kapital, Zeit und Personal bindet. Da kann sich eine „Ach fangen-wir-einfach-mal-an“-Mentalität
schnell rächen. Deshalb gilt auch in Zeiten des agilen Projektmanagements: Ein gut geführtes Lastenheft erleichtert die Suche nach dem passenden Anbieter und dient später als Grundlage für eine erfolgreiche Zusammenarbeit.“

Das tönt spannend, also hab ich mir den Blogeintrag von Oxiaon im Detail angeschaut.

Wenn ich Oxaion richtig interpretiere, so gehen die davon aus, dass ein Lastenheft für ein Projekt umfangreich definiert sein muss. Auch wenn die Lösung nachher agil oder iterativ umgesetzt wird. Es ist die Rede von schnell einmal 2500 Kriterien die aufgelistet werden und das ein unabhängiger Berater von Nutzen sein kann.

In meiner beruflichen Laufbahn habe ich auf Anbieterseite sehr viele solcher Lastenhefter beantwortet. Kam es zum Projekt, so konnte man diese Lastenhefter jedoch selten übernehmen. Die Differenz zwischen dem was der Anbieter, und dem was der Nutzer in die einzelnen Punkte interpretierte war schlicht zu gross. Oder das Lastenheft basierte auf Ideen und Ereignissen, welche nicht mehr aktuell waren. Oder die Software hatte im Standard eine bessere Lösung als im Lastenheft definiert. Oder die im Lastenheft dokumentierten Prozesse waren auf einer Flughöhe definiert, dass diese für die Software nicht geeignet sind. Oder, oder, oder…. – Was macht man in solchen Fällen? Die schlechtere, veraltete Lösung umsetzen weil es im Lastenheft steht? Ein Change Request? Mit dem Standard arbeiten und dann schauen wie es läuft? Zuerst ein Einsatzkonzept und danach dieses umsetzen – egal was im Lastenheft stand? Viele Ansätze hab ich schon gesehen, dass ein Pflichten, resp. Lastenheft jedoch 1:1 umgesetzt wurde, hab ich nie erlebt.

Ich begleite aktuell ein Evaluations-Projekt. Wir haben uns dabei für einen neuen vereinfachten Lösungsansatz entschieden, den ich hier gerne etwas ausführen
möchte.

In einem ersten Schritt haben wir Muss-Kriterien definiert. Das waren weniger als zehn Kriterien (z.B. Branchenreferenzen, Referenzprojekte, Anzahl Mitarbeiter) die ein
Anbieter erfüllen muss, um überhaupt in Frage zu kommen.

Danach haben wir einige Prozesse definiert, die wir ihn von diesen Anbietern sehen wollten. Die Prozesse wurden gewichtet und ein Bewertungsraster erstellt.

Jeder Anbieter konnte daraufhin seine Lösung mit den von uns definierten Prozessen in einem halben Tag vorstellen. Aufgrund dieser Vorstellungsrunde sind wir mit den besten drei Anbietern in die Detailworkshops gegangen. Wir definierten unsere Prozesse, die wir von den Anbietern gezeigt haben wollten. Daraufhin konnten die Anbieter vor Ort kommen, um ihre Fragen zu klären, den Betrieb kennenzulernen und anschliessend einen Prototyp zu bauen. – Auch hier wurden Bewertungsbögen wurden erstellt und die Lösungen miteinander verglichen.

Bewusst verzichtet haben wir dabei auf ein detailliertes Lastenheft. Wir wollten die Prozesse sehen um festzustellen, ob der Anbieter den Kunden auch versteht
und wie die Zusammenarbeit zwischen den Parteien funktioniert. Im Blogeintrag von Oxaion wird dann darauf eingegangen, dass das die Einführung mit agilen Schritten vorwärts kommt. Wir sind auch von einem solchen Ansatz ausgegangen und haben uns deshalb auf die Prozesse und das Tagesgeschäft fokussiert.

Die Evaluation läuft noch, aber wir sind zuversichtlich, dass wir so den besten Partner für unser Projekt finden. Ob es die Lösung mit den besten Features ist, weiss ich nicht. Aber mit dem richtigen Partner können die Herausforderung im Projekt umgesetzt werden. Ich unterstütze deshalb ein Punkt aus dem Blogeintrag von Oxaion voll und ganz: „FAZIT: Wichtig ist somit neben einer guten funktionalen Lösung ein vertrauensvolles Verhältnis zum ERP-Anbieter. Das erleichtert nicht nur die Erstellung des Lastenhefts sondern hält auch den Projekt- und Kostenaufwand überschaubar.

Wenn die Zusammenarbeit mit dem Anbieter nicht klappt, so kann das Lastenheft oder die Lösung noch so gut sein. Es wird nicht gut funktionieren.

Um den Bogen zum Newsletter zu machen: Ich sage nicht, dass man ein „fangen-wir-einfach-mal-an“ Projekt starten soll. Ich behaupte aber, dass eine Liste mit unzähligen Kriterien nicht zielführend ist. Und by the way: Eine agile Vorgehensmethodik hat nichts mit „Ach fangen-wir-einfach-mal-an“ zu tun.

Was sind Eure Erfahrungen mit Lastenhefter? Wie detailliert sollen diese sein? Macht es Sinn jede Funktion im Vorfeld zu definieren und festzuhalten?

Testen tun alle – die einen vor, die anderen nach dem Go Live

Bei ERP Einführungen oder neuen Releases wird vom Anbieter oft verlangt, dass die Benutzer testen. Die User fragen sich dann, weshalb man etwas testen muss: „Es ist doch alles im Standard.“ – Aus Sicht der Anwender wurde weder eine firmenspezifische Entwicklung erstellt noch ein Sonderwunsch geäussert. Alles was man haben möchte ist doch der Standard und mit diesem arbeiten ja alle Firmen.

Ich behaupte jetzt mal, dass jeder der mehr als ein System eingeführt hat weiss, dass dies nicht der Fall ist. ERP Systeme sind flexibel und die Konfigurationen werden an den Kunden angepasst. Bei jedem Kunde etwas anders, da nicht alle gleich arbeiten.

Es geht mir in diesem Beitrag nicht um eine vollständige Aufarbeitung von Softwaretests. Dazu gibt es spezielle Lehrgänge. Es geht mir um die Anwender und den Projektleiter in ERP Projekten. Das sind vielfach nicht die Personen mit einer Spezialausbildung im Testing. Ich möchte hier meine Erfahrungen aus der Praxis weitergeben und den einen oder anderen Tipp platzieren, so dass Ihr es im Alltag einfacher habt.

Bedeutung von Tests
Die Tests der Anwender haben für mich zwei Zwecke. Zum einen wird geprüft ob die Software macht was sie sollte und nicht macht was sie nicht sollte. Zum anderen erhalten die User mit der Durchführung der Testfälle Übung im Umgang mit der neuen Lösung oder der neuen Version. Dies macht den Go Live erheblich einfacher. Zum einen weil man weiss wie es geht und zum anderen weil das System macht was definiert ist. Als schönen Nebeneffekt kann die Anwenderdokumentation gleichzeitig mit den Tests erstellt werden.

Wenn man dies jemandem sagt, so scheint dies eigentlich recht verständlich. Trotzdem wird häufig auf eine intensive Testphase verzichtet.

Hier einige Beispiele aus meinem Arbeitsumfeld weshalb nicht getestet wurde:
– die Konfiguration war noch nicht ganz fertig, der go Live Termin kam näher und diesen wollte man halten. Darum verzichtet man auf einen intensiven Test
– die Mitarbeiter hatten keine Zeit
– die Mitarbeiter wussten nicht was zu testen ist
– die Mitarbeiter wussten nicht wie zu testen ist
– die Mitarbeiter machten ein Klick, es ging nicht wie gewünscht, also hörte man auf

Arten von Tests
Für mich gibt es folgende Testkategorien:

Der Einzeltest
Der User versucht eine bestimmte Transaktion durchzuführen. Zum Beispiel das Erfassen eines neuen Artikels.

Der Integrationstest
In diesem Test wird nicht nur der Einzelschritt angeschaut, sondern der gesamte betroffene Prozess. Wird der erfasste Artikel korrekt gebucht (im Lager, in der Buchhaltung)? Wie erscheint der Artikel auf der Rechnung? Wie entwickelt sich der Einstandspreis, etc.

Der Rückwärts- resp. Seitwärtstest
Was passiert wenn ich etwas Ungewolltes mache? Kommt dann eine Fehlermeldung oder geht der Prozess trotzdem weiter? Was passiert mit den anderen Artikeln? Werden diese weiterhin korrekt gebucht? Welche Querschläger gibt es aus den gemachten Anpassungen?

Um einen kompletten Test durchzuführen, sind immer alle Schritte notwendig. Vor allem, wenn bei einem Test etwas nicht funktioniert hat, es korrigiert wurde und man nochmals testen muss.

Die User
Folgende Testtypen sind mir im Berufsalltag begegnet.

Der Minimalist: „Ich habe ein Fall getestet, es hat alles funktioniert, deshalb hab ich aufgehört.“ – Dies führt dazu, dass im produktiven Betrieb dann halt auch nur der Fall funktioniert der getestet wurde.

Der Ausredensucher: Diese Testperson erhält zehn verschiedene Fälle, hört aber auf, wenn er im ersten Fall nicht das Resultat seiner Wünsche erhält. Die weiteren Fälle werden nicht einmal angeschaut, weil man ja sowieso nochmals testen muss. – Die Durchlaufzeit erhöht sich dadurch massiv, was diese Testperson egal ist, sie sucht nur eine Ausrede, weshalb man NICHT testen kann.

Der „Keine Zeit“ Typ: Diese Person weiss dass sie testen muss, nimmt sich aber die Zeit nicht, weil das Tagesgeschäft den Alltag schon 100% ausfüllt und es irgendwie immer etwas Wichtigeres gibt. – Somit werden die Tests erst nach dem go Live gemacht.

Der Optimist: Diese Person vertraut dem Anbieter, den Consultants, der Software. Es wird schon stimmen. Drum wird einfach nicht getestet. – Murphy lässt grüssen.

Der Gewissenhafte: Diese Person macht alles Test vor- und rückwärts. Das sind diejenigen, welche man im Projekt am liebsten hat.

 

Tipps für den Alltag
Aus meiner Sicht ist es wichtig, dass die Tests genau dokumentiert werden. Und das beginnt bereits beim Auftrag. Der User sollte einen konkreten Auftrag erhalten. Mit allen Elementen eines Auftrages: Wer testet wann was wo und wie meldet er die Ergebnisse und wo meldet man Probleme. Wer steht bei Fragen zur Verfügung?

Am Schluss der Tests sollte es ein Abnahmeprotokoll geben, dass die Person, welche die Tests durchgeführt hat, unterzeichnet.

Idealerweise finden die Tests nicht am eigenen Arbeitsplatz statt, so kann man verhindern, dass die Personen ständig gestört werden. Ein fixes Zeitfenster stellt zudem sicher, dass die Personen sich die Zeit auch reservieren.

Die wichtigsten Tests betreffen das Tagesgeschäft. Testet nicht den Ausnahmefall, der letzte Woche zufällig (und das zum ersten Mal seit 10 Jahren) aufgetreten ist.

Aus Herstellersicht:
Es gibt kein Go Live ohne Testabnahme.

Organisation:
Erstellt eine Testliste mit Testfällen, erweitert diese Testliste mit jedem Release. So hat man mit jedem Update ein Testszenario auf das man zurückgreifen kann. Die User haben einen genauen Leitfaden, an welchen sie sich halten können und die Rückmeldungen sind strukturiert. Versucht dabei auch die User für die Arbeit zu sensibilisieren und setzt wenn möglich die gleichen Personen  ein.

An das Management:
Gebt den Anwendern Zeit für diese Arbeit. Weil alles was während dem Testen nicht entdeckt wird, wird euch im Tagesgeschäft wieder einholen und dort sind die Auswirkungen massiv grösser. Von einfachen Datenkorrekturen bis hin zum Stillstand der Produktion ist vieles möglich.

 

Was sind eure Erfahrungen mit den Tests? Wie habt Ihr die Anwender
sensibilisiert und geschult?

ERP APP – Wer nutzt das eigentlich?

Wer von euch nutzt eigentlich eine APP um auf sein ERP zuzugreifen? So richtig via Smartphone oder Tablet. Nicht via Webclient oder Citrix. Sondern als APP.

Vor einigen Jahren war in praktisch allen Pflichtenhefter die ich bearbeitet habe die Anforderung drin, dass das ERP System eine App haben muss. Nach der APP war es dann der Webclient. Jeder Kunde wollte eine APP oder einen Webclient. Noch besser beides,  sonst flog man aus der Evaluation, weil das KO Kriterium nicht erfüllt war.

Jetzt, einige Jahre später, frage ich mich, wer genau solche ERP APP’s einsetzt und für was genau. Im Bereich der Aussendienstmitarbeiter (Servicetechniker) sehe ich durchaus Einsatzmöglichkeiten. Aber bisher habe ich da nur spezifische Individualentwicklungen gesehen und keine Standard-Apps.

Wenn ich im Google Play die Anzahl downloads der ERP Apps anschaue, so wage ich zu bezweifeln, dass eine grosse Nachfrage besteht. Die App zum SAP Business One  hat gerade mal 50.000 – 100.000 Installationen. Die Comarch APP hat etwa 10.000 Installationen.

Gibt es für ERP APPs also gar kein Markt? Oder sind die Unternehmen einfach noch nicht soweit? Was braucht es damit sich die APP’s etablieren? Schaue ich die falschen Zielmärkte an?

Meiner Meinung nach gibt es einzelne Prozesse , welche aus einer APP gestaretet werden können und so den Vorgang im ERP starten oder freigeben. Für Rechnungsfreigaben, Adressabfragen, Lagerbestandesabfragen, Ereignisseinträge, Servicetechnikeinsätze oder Zeiterfassung sehe ich durchaus Möglichkeit welche Sinn machen.

Mit einem Webclient sehe ich diese Punkte aber eigentlich noch besser gelöst als mit einer APP.

Die Schwierigkeit bei den Apps sehe ich bei der Datensynchronisation. Muss die APP Offline funktionieren, so müssen viele Fragen zur Synchronisierung geklärt sein. Holt sich die APP die Daten Online, so muss einen entsprechende Datenverbindung bestehen und der Datenverkehr entsprechend schnell sein.

Mit einem Webclient muss ich zwar ebenfalls eine Datenverbindung haben, aber die Datensynchronisierung benötige ich nicht, da ich direkt im ERP arbeite. Bei einer Citrix/Terminalserververbindung kann ich z.T. nicht über ein Tablet / Smartphone zugreifen, aber ich arbeite ebenfalls von unterwegs auf dem System.

Ich werde Ende August an der nächsten TopSoft Messe die ERP Anbieter fragen. Vielleicht bin ich danach schlauer.

Was sind Eure Erfahrungen? Wo setzt Ihr im Geschäftsleben eine APP ein? Und ist diese APP mit dem ERP verbunden?

 

 

Reine Projektorganisation, Matrix, Linien, Stab-Linien oder „einfach mal zuteilen“?

Im Moment unterrichte ich das Fach Projektmanagement an angehende Wirtschaftsinformatiker mit eidg. Fachausweis.

Ein Thema dabei ist die Organisationsform innerhalb Projekten. Die Theorie geht dabei auf folgende Möglichkeiten ein: die Linie, die Stab-Linie, die Matrix oder die reine Projektorganisation.

Kurz zusammengefasst: In der Linienorganisation bleibt alles beim alten, die Projektmitarbeiter erhalten Zusatzaufgaben für das Projekt. Der Projektleiter macht seine arbeiten neben dem Tagesgeschäft. Dies eignet sich für kleine Projekte.

Bei der Stab-Linienorganisation wird eine Stabsstelle für den Projektleiter aufgebaut. Der Projektleiter greift dann auf die Mitarbeiter der Linie zu, welchem dem Projekt zugeteilt sind. Als Stabsstelle hat er keine Weisungsbefugnis.

Bei der Matrixorganisation erhält der Projektleiter Weisungsbefugnis. Die Mitarbeiter bleiben jedoch ebenfalls in der Linie und haben so für die Projektdauer zwei Vorgesetzte. Der Interessenkonflikt ist vorprogrammiert.

Die reine Projektorganisation bringt den Vorteil, dass die Projektmitarbeiter für die Dauer des Projektes nur dem Projekt unterstellt sind. Sie sind vom Tagesgeschäft entlastet und können sich auf das Projekt konzentrieren.

Von der Theorie zur Praxis

Soweit die Theorie. Welches KMU kann es sich erlauben, eine reine Projektorganisation aufzustellen? Das Tagesgeschäft muss ja irgendwie abgewickelt werden und neue Personen einzustellen für das Tagesgeschäft ist teuer. Mit etwas Glück gibt es ein Projektleiter der zu einem gewissen %-Satz freigestellt wird und so für das Projekt arbeiten kann.

Die Projektmitarbeiter werden definiert und müssen die Projektarbeiten neben dem Tagesgeschäft abwickeln. So werden zu Randzeiten noch schnell Spezifikationen verifiziert, die Daten bereinigt oder 2-3 Tests durchgeführt.

Wenn ich auf die letzten Jahre zurückblicke, so hab ich am häufigsten eine Mischform erlebt. Der Projektleiter ist irgendwie in einer Matrix zwischen Tagesgeschäft und Projekt gefangen. Er wird eventuell noch entlastet für das Projekt. Bei den anderen Mitarbeitern wird das Projekt nebenher abgewickelt. Sie bleiben in der Linie und versuchen es allen recht zu machen und es wird dann alles nur halbbatzig erledigt.

Wie kann man das besser machen?

Ich habe da ein paar Ideen, die ich in ERP Projekten zum Teil auch schon angetroffen habe und die diese Situation entschärfen.

1) Bewusstsein schaffen. – Arbeitspakete erstellen und einplanen

Die Faustregel ist: Anbieterstunden x 2 = Interne Stunden.

Wenn der Anbieter sagt, er müsse ein Tag für etwas arbeiten, so sollten intern mindestens 2 Tage dafür eingeplant werden. Reserviert bewusst die Zeit und plant nichts anderes ein während dieser Zeit.

2) Gebt den Projektmitarbeiter Zeit.

Macht fixe Zuordnungen von Stunden und Tagen für das Projekt. In dieser Zeit sollen die Projektmitarbeiter nur für das Projekt arbeiten. Falls es möglich ist, so macht dies sogar in räumlich getrennten Büros. So können sich die Mitarbeiter zurückziehen und nur für das Projekt arbeiten.

3) Temporäre Anstellungen für die Entlastung des Tagesgeschäft

Stellt Personen ein, welche die Projektmitarbeiter entlasten.

4) Hört auf mit „wir machen das nebenher“

Das funktioniert nicht wirklich. Die Priorität der Mitarbeiter wird sonst nie auf dem Projekt sein.

5) Externe Unterstützung holen für das Projekt

Engagiert ein Projektcoach (mich zum Beispiel 😉 ) der den Projektleiter intern unterstützt, die Methoden mit ihm erarbeitet und bringt so die notwendige Projekterfahrung in Euer Projekt.

6) Auslagerung prüfen

Gewisse Punkte können an den Anbieter ausgelagert werden, andere nicht.  Prüft ob es Punkte gibt, die das Projekt entlasten, wenn es der Anbieter erledigt.

Abschlussbemerkung

Ein ERP Projekt operiert am offenen Herzen einer Firma. Prozesse werden angepasst, Werteflüsse erstellt, das Tagesgeschäft im neuen System abgebildet. – Sind wir ehrlich: läuft die ERP Software nicht oder nicht optimal, so hat dies einen direkten Einfluss auf die Kunden- und Mitarbeiterzufriedenheit, die Liefertermine, den Umsatz. – Ich erachte es deshalb als sehr wichtig, dass man sich in solchen Projekten Gedanken zur Projektorganisationsform macht und den Mitarbeiter die notwendige Zeit wirklich zur Verfügung stellt.

Wenn die Cloud resp. dein ERP System abgestellt wird

Als ich mich vor einigen Monaten selbständig macht, prüfte ich diverse kleine ERP Systeme, welche meine Anforderungen erfüllen (Lohn, Buchhaltung und Rechnungsstellung). Die Lösung musste in der Cloud sein und sollte bezahlbar sein. Ich wollte keine eigene Infrastruktur betreiben.

Meine Wahl fiel auf die Lösung Amanda Online. Ich arbeite jetzt ein halbes Jahr mit der Software von Amanda und war mit dem Produkt zufrieden. Mein erster Jahresabschluss ist gemacht, der Lohnausweis erstellt.

Und dann kommt letzte Woche die Meldung „Ab dem 18. April 2016 wird Amanda nicht mehr erreichbar sein.“  – Danach sind die Daten weg, das System wird nicht mehr erreichbar sein. – Knapp 3 Monate Zeit um zu reagieren.

Was jetzt ? Gehe ich wieder in die Cloud und nehme das Risiko, dass auch die neue Lösung irgendwann nicht mehr betrieben wird? Gehe ich zu einem Anbieter, welcher einen offenen Sourcecode hat und ich die Lösung notfalls selber installieren und betreiben könnte? Oder ist dieses „Selber betreiben“ ein Trugschluss, da mir die Infrastruktur und das Wissen fehlt eine solche Plattform zu betreiben? Wenn dort das Geschäft nicht läuft, weshalb sollte dann ein neuer Anbieter kommen und es betreiben?

Soll ich eine Installation bei mir im Hause machen? Mit den Konsequenzen von Migrationen, Datensicherungen, Infrastruktur, etc. ?

Wahrscheinlich werde ich in der Cloud bleiben, da ich mir den Aufwand einer eigenen Installation nicht leisten will.

Mein Datenverlust hält sich in Grenzen. Die Daten kann ich exportieren, einen neuen Anbieter werde ich finden. Ärgerlich ist der Aufwand für die Einrichtung und die Datenerfassung. Mit dem Einrichten von ERP Systemen verdiene ich als Consultant zwar mein Geld, aber dann mache ich es für die Kunden. Jetzt muss ich es für mich machen und verbrauche Zeit, die ich nirgends fakturieren kann. – Ein Anbieter mit den Modulen Lohn, Auftrag und Buchhaltung zum Preis von Amanda werde ich wohl nicht mehr finden.

Was bleibt?

Gelitten hat jedoch mein Glaube in die „Wolke“. Ist das wirklich das Zukunftsmodell? Oder sind lokale Installationen mit entsprechenden Kosten nicht besser? Ich erlebe jetzt was es heisst, wenn der Anbieter einfach aufhört.

Wenn ich meinen letzten Blog mit meiner Vespa anschaue, die Ausfälle der Internetverbindungen bei Swisscom und UPC von letzter Woche dazu nehme, so komme ich zu folgendem Schluss: Es kommt darauf an, wie dringend man ein System braucht und wie verfügbar es sein muss.

Ich habe mit der Abschaltung von Amanda Aufwand den ich nicht eingeplant habe, kann aber innert wenigen Tagen wieder arbeiten. Wenn ich jedoch Rund um die Uhr auf das System angewiesen bin und eine Abschaltung der Lösung für meine Firma lebensbedrohlich ist, so würde ich mich wohl gegen eine Lösung in der Cloud entscheiden, damit ich die bessere Kontrolle über das System habe.

Ich werde dann zu einem späteren Zeitpunkt meine Erfahrungen mit dem gewählten Produkt und dem neuen Anbieter hier veröffentlichen.

Was sind Eure Erfahrungen mit der Cloud? Ist das die Zukunft?

Was meine Oldtimervespa mit ERP Versionen zu tun hat

Meine Vespa hat Jahrgang 1984. Ich nutze sie 3-4 mal pro Jahr. Meistens im Sommer um an den See oder ins Stadion zu fahren. Letzen Sommer war die Kupplung hinüber. Ich brachte die Vespa zu einem Piaggio-Spezialisten. Die Reparatur dauerte über 8 Wochen. Zuerst wurde das falsche Ersatzteil geliefert, danach konnte die Kupplung nicht richtig eingestellt werden. Der Spezialist für so alte Vespa’s war dann auch noch in den Ferien und so verzögerte sich die Reparatur.  Auch heute läuft die Kupplung noch nicht so rund wie sie sollte. – Das ist nicht weiter tragisch, ich fahre das Gefährt nicht sehr oft und bin weder unter Zeitdruck noch muss ich zuverlässig irgendwo hinkommen wenn ich die Vespa nutze.

Was hat das mit einem ERP System zu tun?

Vor einiger Zeit war ich bei einem Kunden der mit einer ERP Version arbeitet, welche vom Hersteller nicht mehr gewartet wird. Eine Migration wird aktuell nicht ins Auge gefasst, da man lieber noch 2-3 Jahre warten möchte und danach ein neues Projekt für eine Migration oder eine Ablösung starten möchte.

Somit hat der Kunde keine neuen Funktionen des Herstellers zur Verfügung. Swissdec kann nicht genutzt werden. Die neuen Einzahlungsscheine, welche ab 2018 auf den Markt kommen, werden nicht eingesetzt werden können. Die SEPA Normen werden nur zum Teil erfüllt. Und mit jeder Version die der Kunde nicht installiert, gibt es weitere Funktionen für die es Umgehungslösungen braucht.

„Ach wissen Sie, das System läuft ja sehr stabil und so haben wir keinen Grund es zu ändern“ – Diese Aussage ist auf der einen Seite zwar verständlich, aber auf der anderen Seite kann es plötzlich dann so gehen wie bei meiner Vespa. Ein Fehler kommt zu Tage oder eine gesetzliche Anpassung oder die Datenbank gibt den Geist auf. Und dann findet man vielleicht niemanden, der die Version noch kennt. Eventuell muss der Hersteller zuerst eine Umgebung aufbauen um den Fehler überhaupt zu analysieren. – All dies hat teure Folgen.

Wenn meine Vespa einige Wochen ausser Betrieb ist, so ist das nicht weiter schlimm. Ich nehme das Velo oder das Auto oder den Zug.

Was ist aber, wenn das (nicht mehr unter Wartung stehende) ERP System für einige Tage ausfällt? Die Produktion steht still, die Löhne werden nicht mehr bezahlt, die Lieferanten erhalten kein Geld, die Kunden keine Rechnungen. – Kurz: Nicht nur das System sondern auch die Firma steht still.

Ich bin mir bewusst, dass ich eine Oldtimer-Vespa fahre. Ich tue dies mit Genuss und Freude am Fahren.  Eine Panne kann ab und zu vorkommen. Ist sich der Kunde auch bewusst, welches Risiko er eingeht, wenn er mit einer veralteten Version arbeitet?

 

Alles Customizing, Parametrisierung, Standard, Individualisierung oder was?

Bei vielen Einführungen einer ERP Lösung habe ich es erlebt, dass der Kunde fragt: Kann man das anpassen? -> Die Antwort ist meistens, ja kann man. Die Rückfrage an den Kunden: „Sind Sie sich der Konsequenzen der Anpassung bewusst?“ wird leider nicht sehr oft gestellt.

Der Anbieter kann zum einen den Anwender zufriedenstellen, zum anderen kann er damit Geld verdienen (beim Erstellen, beim Unterhalt und bei Migrationen noch einmal).

Was heisst Standard, Customizing, Individualisierung für mich?

Standard
Nutzen der Software ohne Anpassungen. Ich benutze die von der Software vorgegebenen Prozesse, Abfragen und Auswertungen.

Customizing (auch Parametrisierung)
Mit dem Customizing, wird die Software so eingestellt, dass die Bedürfnisse der User abgebildet werden. Für mich sind dies z.B. Prozesse, Suchbefehle, Auswertungen, Felderbezeichnungen, Freigabeprozeduren, Maskenanpassungen, Formulare, etc. Durch solche Anpassung wird die Standard-Software für den User so konfiguriert, dass die Software den Anforderungen der Firma entspricht. ERP Lösungen bieten hier sehr viele Möglichkeiten an.

Vorteile von Customizing: Ich kann meine Bedürfnisse in der Software abbilden. Die Rechnung erscheint in meinen CI. Die nicht genutzten Felder sind ausgeblendet, etc.

Nachteile: Der Support wird schwieriger, da diese Anpassungen kundenspezifisch sind. Die Migrationen werden teurer, da die Funktionen geprüft werden müssen.

Individualisierung:
Für mich sind Individualisierungen das Entwickeln von kompilierbarem Code. Erstellen von Funktionen die nur für einen Kunden, resp. eine Installation geschrieben werden. Dies kann z.B. das Abbilden von speziellen Prozessen sein. Oder das Entwickeln einer Schnittstelle. Oder ein spezielles Programm zum Verwalten von Daten die innerhalb der Standard-Software nicht erfasst werden können.

Solche Individualisierungen haben den Vorteil, dass genau die Kundenbedürfnisse abgebildet werden. Dies kann beim Kunden zu einem Wettbewerbsvorteil werden. Wenn ich durch die Anpassung schneller liefere, meine Kunden besser bewirtschafte, meine Prozesse automatisiere oder weniger Ressourcen für das Abwickeln meiner Prozesse benötige, dann kann ich mich dadurch gegenüber von meinen Mitbewerbern abheben.

Der Nachteil liegt im Unterhalt. Meistens kennen nur wenige Personen diese Entwicklungen. Bei Personalrotationen geht Wissen verloren, bei Updates kann es sogar dazu führen, dass die Individualisierung neu entwickelt werden müssen.

Wann macht es Sinn, den Standard zu verlassen ?
Die Faustregel für mich ist: Habe ich als User einen Wettbewerbsvorteil mit dieser Anpassung? Wenn ja, so muss eine Umsetzung detailliert geprüft werden.

Wenn nein, so ist es eher eine Komfort-Funktion. In diesem Fall empfehle ich, zuerst mit dem Standard zu arbeiten und einige Monate später den Punkt nochmals aufzugreifen und dann prüfen, ob die Anpassung notwendig ist. –> Dies kann man häufig auch mit vielen Customizing-Punkten machen, nicht nur mit Individualisierungen.

Bin ich wirklich besser als meine Mitbewerber, wenn ich auch nach der Telefonnummer des Kunden suchen kann? Wie oft brauch ich das wirklich? Muss in meine Bilanz im Hochformat sein oder kann ich mit dem Querformat des Anbieters arbeiten?

Ein Beispiel aus der Praxis
Leider hab ich es zu oft erlebt, dass die von den Usern gewünschte Anpassung nicht genutzt wurde. Die teuer entwickelten Funktionen wurden deaktiviert, weil man bei der Definition irgendwas vergessen hatte und es deshalb nicht nutzt.

Ich nenne ein Beispiel, dass ich bei einem Kunden vor einigen Jahren erlebt hatte.
Der Kunde wollte eine Auswertung in dem die Kostenarten nicht nur je Kostenstellen ausgedruckt werden, sondern dass mehrere Kostenstellen gruppiert werden können. Der Standard der Software konnte dies problemlos auf dem Bildschirm darstellen. Das reichte jedoch nicht. Der Wunsch des CFO war eine Liste auf Papier. -> Diese wurde erstellt.
Nach einer Personalrotation wollte der neue CFO dieselbe Auswertung nicht mehr auf Papier, sondern neu auf Excel. Ein Jahr später, nach einer weiteren Personalrotation, wollte der wiederum neue CFO die Auswertung als Pivottabelle in der Software.
Dieselben Zahlen. 3 x individualisiert. Obwohl der Standard der Software die Auswertung auch lieferte. Bei Migrationen wurden jeweils alle 3 neuen Varianten überprüft und auf den aktuellen Stand gebracht. Der darauffolgende CFO nutzte dann keine der Möglichkeiten mehr, sondern arbeitete mit dem Standard.

Fazit
Mit Individualisierungen kann man viel Geld verdienen. Sowohl beim Anbieter (Erbringen von Dienstleistungen), wie auch beim User (z.B. durch Wettbewerbsvorteil gegenüber von Mitbewerbern oder durch Effizienzsteigerung). Aber man muss vor der Umsetzung prüfen, ob sich die Umsetzung lohnt.

Was sind Deine Erfahrungen?

Wie wähle ich die geeigneten Key-User für mein ERP Projekt aus?

Zum Beginn eines Projektes werden (hoffentlich) Key-User definiert.

Was sind die Aufgaben der Key-User?

Gemäss Wikipedia „wird der Begriff Key-User im Zuge der Einführung betriebswirtschaftlicher Software (z. B. ERP-Systeme) genutzt. Der Key-User selbst ist ein Mitarbeiter des Unternehmens, welches die betriebswirtschaftliche Software einführt.

Der Key-User ist jener Anwender, der sich in seinem Bereich auf die dort eingesetzte Software bzw. entsprechende Software-Module spezialisiert. Ein Key-User unterstützt den Ausbau und die Integrationstiefe und vertritt die fachlichen Interessen des Fachbereiches im Projektteam. Er fungiert zudem als Ansprechpartner für die Kollegen in der eigenen Abteilung, den ERP-Anbieter und die Projektleiter. Ein Key-User kann eigenverantwortlich erforderliche Schulungen für seine Kollegen durchführen.“

Meiner Meinung kommt dem Key-User jedoch auch nach der Einführung eine wichtige Rolle zu. Idealerweise ist er die erste Ansprechperson bei Problemen der normalen User in seiner Abteilung. Zu seinen Aufgaben kann es gehören, dass er das System weiter vorantreibt und seine Ideen zu Verbesserungen im laufenden Betrieb anbringt.

Was muss der Mitarbeiter bringen?

Die Aufgaben, Kompetenzen und Verantwortungen sind in jeder Firma anders definiert. Damit man einen Mitarbeiter jedoch als Key-User definieren kann, muss er ein gewisses Flair für IT Systeme mit sich bringen. Er sollte seine Ideen formulieren können. Den Blick fürs Wesentliche haben und Herausforderungen richtig priorisieren. Wichtiges von Wünschen unterscheiden und Dringendes einstufen. Ich würde Mitarbeiter nehmen, welche den Betrieb und die Prozesse kennen und trotzdem offen sind für neue Ideen.

Was muss der Arbeitgeber bringen?

Von Arbeitgeberseite her ist es wichtig, dass der Mitarbeiter für seine Tätigkeiten das Vertrauen erhält und die entsprechende Zeit zur Verfügung steht.

Kritische Erfolgsfaktoren

Und da hab ich es oft erlebt, dass man zwar die fähigsten und besten Leute als Key-User definiert, diese aber im Alltag nicht entlastet. Dies führte zu überlast und am Schluss dazu, dass die Projektaufgaben verzögert oder nur zur Hälfte erledigt wurden.

Wenn Du also Key-User definierst, nimm Dir Zeit um mit diesen Personen zu definieren, welche Aufgaben abgegeben werden können um die Tätigkeiten als Key-User wahrzunehmen.

Und für mich ganz wichtig im Zusammenhang mit den Key-Usern nach dem erfolgten Betrieb mit der Lösung ist ein regelmässiger Austausch unter den Key-User. Was kann man verbessern, welche Anpassungen sind nötig, wo machen weitere Schulungen Sinn, etc. Wird dies nicht kontinuierlich gemacht, so ist der Status „Key-User“ nur eine Zusatzaufgabe für die betroffene Person kein nutzbaren Mehrwert dar.

Der ERP Ausfall – Alle Berichten was es kostet, (fast) niemand sagt wie es verhindert wird

Die GIA Informatik aus Oftringen hat eine gute Studie erstellt, was ein ERP Ausfall kostet. Der ERP Blog von ERP Selection hat das Thema gleich aufgegriffen und seine Sicht dazu dargelegt.

Auf Linkedin empfiehlt ein Marketing Manager eines Schweizer ERP Hersteller den Link zur Studie mit den Worten „Ein wichtiges Argument, mit dem richtige ERP-System und Partner zu arbeiten.

Inside IT greift das Thema ebenfalls auf und berichtet über die Studie.

Die Ergebnisse scheinen also auf grosses Interesse zu stossen.

Das Thema wie man die Ausfälle verhindern kann wird jedoch meistens aussen vor gelassen. Einzig der Blog von ERP Selection geht in einigen Zeilen auf das Thema ein. Mir persönlich gefällt der Blog von ERP Selection zu diesem Thema sehr gut. So zeigt er auf, welche Gedanken man sich machen muss und wo es überall Auswirkung haben könnte.

Wie erlebe ich die Praxis?

In den vergangen Jahren habe ich ab und zu Systemausfälle oder Unterbrüche mitbekommen. Und hier möchte ich ansetzen und aufzeigen, wie es zu solchen Ausfällen gekommen ist. Die Liste ist nicht abschliessend und auch keine Rangliste, es zeigt aber die Fälle auf, welche ich am meisten erlebt habe.

Ausfallgrund 1: Hardware / Infrastruktur

Die Infrastruktur gibt den Geist auf. Sei es eine Harddisk vom Server oder Netzwerkkomponenten. – Dies kann mittels verschiedenen Massnahmen umgangen werden. Von redundanten Serverlandschaften bis zur Auslagerung der Infrastruktur an ein RZ ist hier vieles möglich. Da kann und will ich nicht weiter darauf eingehen, da ich definitiv nicht der Spezialist in diesem Bereich bin.

Ausfallgrund 2: Software / Konfigurationen

Mehr als einmal habe ich erlebt , dass eine Änderung am produktiven System vorgenommen wurde, welche dazu führte, dass das System oder Bereiche vom ERP System nicht mehr funktionierten. Im besten Fall stellt man dies direkt nach der Umstellung fest und kann es sogleich Rückgängig machen. Schlimmer ist es, wenn man erst Tage nach einer solchen Umstellung feststellt, dass etwas falsch läuft und das System nun fehlerhafte Daten hat. Oder wenn eben das System nicht mehr läuft und man Backups zurückspielen muss.

Ausfallgrund 3: Veraltete, nicht mehr gewartete Systeme

Es gibt Firmen die sehr lange mit dem aktualisieren von Systemen warten. Sie betreiben ihre Lösungen auf Plattformen, welche vom Hersteller nicht mehr gewartet werden. Ich hatte noch im Jahr 2014 eine Installation angetroffen, welche auf einem (virtualisierten) Windows NT betrieben wurde. Fällt eine solche Lösung aus, so kann dies zu sehr langer Ausfallzeit führen. – Dies kann man verhindern, in dem man mit aktuellen, gewarteten Lösungen arbeitet.

Was tun?

In meiner Vergangenheit hab ich den Ausfallgrund 2 am häufigsten angetroffen. Vielfach führten „Verschlimmbesserungen“ dazu, dass das System nicht mehr nutzbar war. Die Konfiguration wurde geändert, das System lief nicht mehr wie gewünscht.

Glücklicherweise kommen solche Ausfälle eher selten vor. Wenn sie jedoch vorkommen, so ärgert sich der Anwender, dass man dies nicht vorher getestet hat. So hätte man die Ausfallkosten vermeiden können.

Um diese Art von Ausfällen zu verhindern setzt man sehr häufig auf ein Testsystem. Eine autonome Installation des ERP Systems sorgt dafür, dass man allfällige Änderungen zuerst dort testen kann. Bei grösseren oder komplexen ERP Landschaften kann es auch sinnvoll sein, noch weitere Systeme (z.B. Schulungssystem oder Entwicklungssystem) im Einsatz zu haben.

Dies bringt den grossen Vorteil, dass man die gewünschten Änderungen zuerst testen kann, allfällige Auswirkungen auf Umsysteme und Schnittstellen oder andere Module werden erkannt und können ohne Zeitdruck korrigiert werden. Die Einspielungen in die produktive Umgebung kann man einplanen und die User vorgängig informieren oder schulen.

Es bringt jedoch einen gewissen Mehraufwand mit sich. Die Anpassungen müssen vom Testsystem auf das Produktive übertragen werden. Dadurch erhöht sich die Durchlaufzeit von Änderungen. Gewisse Arbeiten müssen doppelt gemacht werden.

Meiner Meinung nach ist es für KMU’s mindestens bei einem Versionswechsel zwingend notwendig, dass eine Testinstallation gemacht wird. Zu Schulungs- und Testzwecken, um Individualisierungen zu verifizieren, etc.

Ob für den laufenden Betrieb mehrere Systeme (Test-, Schulungs-, Entwicklungssystem) bei KMU notwendig sind, muss man von Fall zu Fall anschauen. Wenn eine Firma einige Tage auf ein System verzichten kann, so kann man über den Sinn dieser Systeme nachdenken.

Ich habe es schon erlebt, dass Kunden sagten, ein Systemausfall von einigen Tagen wäre kein Problem. Im Nachhinein hat sich dann herausgestellt, dass dies doch nicht ganz so einfach war.

Wichtig finde ich, wie auch schon auf dem Blog von ERP Selection zu lesen ist, dass ein Notfallkonzept vorhanden ist. Was tun wir, wenn das System ausfällt? Welche Umsysteme sind davon betroffen? Wie kann man ohne das System arbeiten?

Was hat bei Euch zu Systemausfällen geführt? Wie hätte man diese verhindern können? Habt Ihr ein solches Konzept?