Fachartikel

27.10.2015

Alle Mann (und Frau) an Bord!

Planisware mithilfe von Change Management erfolgreich implementieren

Wer Planisware als neue integrierte Software in seinem Unternehmen einführt, hat eine schwierige Aufgabe vor sich. Eine Implementierung bedeutet nicht nur eine technische Herausforderung, sondern immer auch eine politische. Der Verantwortliche der Neueinführung sieht sich verschiedenen Stakeholdern und zukünftigen Nutzern gegenüber, die alle unterschiedliche Bedürfnisse und Wünsche haben.

 

Selbst wenn man mit Planisware über einen vermeintlichen Alleskönner verfügt, heißt das noch lange nicht, dass alle Anwender damit zufrieden sind. Oft dauert es Jahre, bis die neue Lösung im Unternehmen akzeptiert wird – wenn dies überhaupt der Fall ist. Denn werden wichtige Stakeholder in der Implementierungsphase übergangen, entsteht Widerstand in der Organisation, der das Tool politisch zu Fall bringt. Hinzu kommen Faktoren wie Budget und Zeitplan, die einzuhalten sind und die Arbeit nicht leichter machen.

 

Planisware ist zudem ein Tool, das sehr gut angepasst werden kann. Und so neigt man dazu, es jedem recht zu machen, alle unterschiedlichen Anforderungen zu implementieren und alle technischen Möglichkeiten auszuschöpfen. Dies führt letztendlich zu einer ungeahnten Kostenexplosion und oft zu einem verschobenen Roll-out. Beim Upgrade auf das neue Release steigen noch einmal die Kosten, weil die Implementierung sehr weit entfernt vom Planisware-Standard ist.

 

Dabei ist es gar nicht so schwer, alle Mann (und Frau) an Bord zu holen und auf Kurs zu bringen. Supper & Supper begleitet seine Kunden seit 15 Jahren in der Implementierung von Planisware. Unser bewährtes Vorgehensmodell bezieht alle relevanten Stakeholder von Anfang an mit ein. Wir flankieren das Implementierungsprojekt mit geeigneten Change Management-Maßnahmen und erprobtem IT-Projektmanagement. Das alles vor dem Hintergrund fundierter Fachkenntnis darüber, was das Tool Planisware technisch leisten kann und welche Businessanforderung am besten mit welchem technischen Konzept umgesetzt wird. Im Folgenden erläutern wir dieses Vorgehensmodell.

 

Scope festlegen:

In der Scopingphase legen wir gemeinsam mit unseren Kunden verbindlich folgende Punkte für das Projekt fest:

  • Was genau ist Inhalt des Projektes und was nicht?  
  • Was genau soll mit der Software gemacht werden? Wir legen hier Funktionalitäten auf einer groben Ebene fest, ohne allzusehr ins Detail zu gehen.
  • Welche Daten sollen in dem neuen Tool gehalten werden und welche nicht?
  • Welche Benutzer und Benutzergruppen sollen mit der neuen Software arbeiten?
  • Gibt es Vorgängerapplikationen, die abgelöst werden sollen und beinhaltet das Projekt eine Migration von Daten?
  • Ist das Tool schon ausgewählt oder muss ein Softwareauswahlprozess vorgeschaltet werden?
  • Wird es Schnittstellen zu anderen Software Systemen geben? Wenn ja, welche?
  • Wer sind die Stakeholder des Projektes?
  • Wie sieht der Business Case für das Projekt aus?

 

Diese Punkte fließen normalerweise in den Projektantrag und die Genehmigung des Projektes ein. Wir unterstützen unsere Kunden dabei, ein realistisches Bild zu entwerfen, das später auch als Projekt umsetzbar ist, und sorgen dafür, dass keine relevanten Punkte übersehen werden.

 

Wichtig ist schon an diesem Punkt, wirklich alle relevanten Stakeholder zu identifizieren und mit ihnen den Scope des Projektes zu erarbeiten ­– am besten partizipativ in Workshops. Dabei entsteht in der Regel eine Liste von Anforderungen, die so in ihrer Gänze nicht komplett implementiert werden kann. Gemeinsam sorgen wir für eine sinnvolle und vor allem transparente Priorisierung der Anforderungen. Wir unterstützen die Organisation dabei festzulegen, welche Anforderungen eben nicht im Projekt umgesetzt werden und warum das so ist.

 

Business-Prozesse festlegen:

In der so genannten Business Process Engineering-Phase erarbeiten wir wieder mit allen relevanten Stakeholder die Diskrepanz zwischen dem Ist- und dem Soll-Zustand der Prozesse. Wir skizzieren gemeinsam einen Weg, wie wir zum Soll Zustand gelangen wollen. Die Businss Prozess Dokumentation enthält klassicherweise folgende Punkte:

  • Eine Definition einer Prozesslandschaft (High Level)
  • Eine Definition von Verantwortlichkeiten und Rollen (das sind später eventuell auch Benutzerrollen in der Software)
  • Festlegung von detaillierten Business-Prozessen mit Prozessverantwortlichen und genauen Prozessschritten (Wer macht was wann, in welcher Reihenfolge?)
  • Festlegung, welche Prozesse im Tool und welche außerhalb stattfinden.

 

In der Business Process Engineering-Phase versuchen wir Geschäftsprozesse zu verschlanken oder zumindest zu vereinheitlichen. Diese vereinheitlichten Prozesse bilden die verbindliche Grundlage für die spätere Implementierung der Software. Daher ist es nötig, dass schon hier flankierende Change Management-Maßnahmen - wie Informationsveranstaltungen in den verschiedenen Organisationbereichen - stattfinden.

 

Agile Software-Implementierung:

Wir empfehlen ein agiles Vorgehen bei der Implementierung, d.h. die Softwarefunktionen werden in sogenannten Sprints (zeitlich immer gleich lange Arbeitsabschnitte – Bsp.: 4 Wochen -, in dem ein Inkrement einer Produktfunktionalität programmiert wird) entwickelt. Agile Ansätze betonen hierbei die Flexibilität und Anpassung an die Kundenbedürfnisse. Nach jeden Sprint wird ein lauffähiges Stück Software ausgeliefert, das von den Endanwendern direkt getestet wird. Das Feedback der Endanwender wird daraufhin direkt an das Entwicklerteam weitergereicht. So können, im Vergleich zum Wasserfallmodell, sehr frühzeitig lückenhafte oder falsch verstandene Spezifikationen aufgedeckt werden und diese Fehler frühzeitig korrigiert werden. Business Mitarbeiter die Software spezifizieren sollen tun dies so nicht „im luftleeren“, abstrakten Raum sondern haben einen konkreten Prototypen vor sich mit dem sie ihr alltägliches Arbeiten erproben können und so sehr qualifiziert Feedback geben können, was dann wieder in die Produktentwicklung einfließt.

 

Nach jedem Sprint findet außerdem eine (Re-) Priorisierung der zu entwickelnden Funktionalitäten statt. Jedes Projektteam lernt während der Implementierung immer mehr dazu, somit können sich auch die Prioritäten ändern und das findet damit Eingang in die Projektplanung. Außerdem wird gewährleistet, dass das Entwicklungsteam, das zumeist sowieso nicht alle gewünschten Funktionalitäten umsetzen kann immer an den wichtigsten Punkten zuerst arbeitet. Unwichtige Punkte fallen so übrigens ganz natürlich durchs Raster, weil sie der Priorisierung durch das Projektteam auf die Dauer nicht standhalten.

 

Außerdem reflektiert das Team in regelmäßigen Abständen über seine Arbeitsweise und verbessert sich so kontinuierlich. Dieses Vorgehen hat den Vorteil, dass ein Projekt schnell auf neue Businessanforderungen und geänderte Kundenwünsche reagieren kann. Zugleich werden die Anforderungen der Anwender laufend präzisiert und verifiziert. Damit sinkt das Risiko einer Fehlentwicklung. Wir haben bei Supper & Supper ausgesprochen gute Erfahrungen mit einer agilen Software-Implementierung gemacht.

 

Folgende Prinzipien sind essentiell für ein agiles Vorgehen – sind aber gleichzeitig für stark hierarchisch funktionierende Unternehmen gewöhnungsbedürftig:

  • Anwender und Entwickler arbeiten während des ganzen Projekts täglich zusammen.
  • Änderungen sind auch in der späten Phase der Entwicklung willkommen. Sie sind ein entscheidender strategischer Vorteil der späteren Lösung.
  • Die effektivste Form der Kommunikation ist face-to-face (in internationalen Umgebungen geht das sehr gut auch mit Onlinekonferenzen!).
  • Die besten Anforderungen, Designs und Lösungen entstehen in selbstorganisierten Teams: Projekte werden um motivierte Personen aufgebaut. Vertraue ihnen und gib ihnen die nötige Unterstützung, damit sie ihre Arbeit machen können.
  • Laufende Software ist wichtiger als eine umfassende Dokumentation.

 

Usability:

Planisware ist ein relativ komplexes und damit nicht immer das anwenderfreundlichste Tool. Wir haben sehr gute Erfahrungen damit gemacht, uns in unseren Projekten speziell um die Usability der späteren Anwendung zu kümmern. Hierzu setzen wir ungeübte Anwender mit spezifischen Aufgaben vor die neue Anwendung und lassen sie bei der Bearbeitung der Aufgabe „laut denken“. So stellt man sehr schnell fest, welche Buttons schlecht zu finden sind, ob z.B. Dialoge unlogisch aufgebaut oder Filterfunktionalitäten zu komplex sind. Verschiedene Kunden haben unterschiedliche Bedürfnisse und Erwartungen, doch auf Basis dieses einfachen Usability-Tests können wir Anwender mit einfachen Maßnahmen „glücklich“ machen. Bereits simple Maßnahmen sorgen für Verbesserungen, z.B. können wir Standardfunktionalitäten umbenennen. Oder wir setzen farbliche Akzente und sinnvolle
(Um-)Gruppierungen von Funktionalitäten und Attributen ein. Auch mit veränderte Modulsteuerung oder sprachlicher Anpassung der Befehle erzielen wir sehr gute Effekte.

 

Ziel ist es, eine leicht verständliche und schnell benutzbare Software zu erhalten – unter den gebotenen technischen Möglichkeiten. Dabei achten wir auf folgende Punkte:

  • Konsistente Benutzerführung
  • Ständige Verfügbarkeit
  • Unmittelbare Verständlichkeit der Benutzerführung
  • Automatisierung sich wiederholender Aufgaben
  • Selbsterklärungsfähigkeit
  • Anpassbarkeit an individuelle Bedürfnisse
  • Fehlertoleranz
  • Höflichkeit
  • Erwartungskonformität

 

Datenqualität:

Die beste Planisware-Implementierung hilft den Unternehmen nicht, wenn die darin enthaltenen Daten nicht von der Qualität sind, dass auf ihrer Grundlage sinnvolle Entscheidungen gefällt werden können. Hier legen wir zunächst fest, was für den jeweiligen Kunden Datenqualität überhaupt bedeutet: Vollständigkeit, Aktualität, Relevanz, oder Genauigkeit?

 

Anschließend analysieren wir die Ursachen für die mangelnde Datenqualität. Auf dieser Grundlage legen wir geeignete Maßnahmen fest, mit der die Datenqualität verbessert werden kann. Dazu erhöhen wir die Benutzerfreundlichkeit, legen verbindliche Verantwortlichkeiten fest und halten dies auch nach. Außerdem sorgen wir für Transparenz: Wer verwendet welche Daten wofür? Denn niemand gibt gerne Daten ein, deren Zweck ihm nicht eingängig ist. Um Verständnis dafür zu wecken, bringen wir die Anwender, die die Reports ziehen, mit den Anwendern zusammen, die die Daten eingeben. Der Austausch über das tägliche Arbeiten und die jeweiligen Bedürfnisse weckt Verständnis und verringert den Widerstand.

 

Technisches Roll-out-Training & Prozess-Training:

Beim technischen Roll-out-Training genau so wie beim Prozess-Training folgen wir den selben Grundprinzipien. Bei den Trainings hat sich unser Schulungskonzept bewährt, das sich an den Benutzergruppen orientiert. Wir arbeiten mit professionellen Software-Trainern und erfahrenen Ansprechpartnern aus dem Business. Unser ansprechendes und fachlich fundiertes Schulungsmaterial mit hohem Übungsanteil und Schulungsbeispielen aus dem Arbeitsalltag der Kursteilnehmer garantiert einen sehr guten Lerneffekt. Idealerweise findet das Roll-out-Training in zeitlicher Nähe zum eigentlichen Roll-out statt. Auch die Zeit bis zum Prozess-Training und der tatsächlichen Anwendung sollte nicht zu groß bemessen sein, damit das erlernte Wissen auch bald angewendet werden kann. Wir empfehlen außerdem eine Gruppengröße von maximal zehn Teilnehmern und Trainingsräume mit geeigneter Infrastruktur außerhalb des Unternehmens, damit sich die Teilnehmer ganz auf das Neue konzentrieren können.

Das Technisches Roll-out Training und das Prozess-Training sollten idealerweise immer miteinander verknüpft werden oder sinnvoll aufeinander aufbauen. Sämtliche Trainingsmaßnahmen werden bei Supper & Supper mit individuell erstellten Softwaretutorials unterstützt. Damit hat der Anwender die Möglichkeit sich die wichtigsten Schulungsinhalte noch einmal am Arbeitsplatz zu gewünschter Zeit noch einmal anzusehen.

 

Technischer Support:

Für den technischen Support sollte immer eine interne Organisation aufgebaut werden. Kein Unternehmen sollte hier auf lange Sicht von externen Beratern abhängig sein! Das ist teuer und schafft Abhängigkeiten aus denen sich ein Unternehmen nur sehr schwer wieder befreien kann, da es sehr lange dauert das entsprechende Know how aufzubauen. Die interne Mannschaft muss mit entsprechend bereitgestelltem Budget und Manpower in der Lage sein, die Anwender innerhalb einer bestimmten Reaktionszeit, die ebenfalls zu bestimmen ist, effektiv zu unterstützen.

 

Dabei spielen folgende Überlegungen eine Rolle: Soll dieser Support 24 Stunden am Tag, sieben Tage die Woche stattfinden? Oder nur zu den üblichen Bürozeiten? Ist das Unternehmen rund um den Globus aktiv und sitzt der technische Support nur an einem Standort? Dann muss er in Schichten arbeiten. Oder es werden mehrere Support-Teams an mehreren Orten installiert, die zu ihren jeweils üblichen Zeiten tätig sind und in Summe dann 24/7 ergeben. Dieses Team, bzw. diese Teams können natürlich nur dann sinnvolle Arbeit leisten, wenn ihnen die nötige Infrastruktur zur Verfügung steht (Issue System, Telefonnummern, SharePoint o.ä.). Es müssen Strukturen geschaffen und Zuständigkeiten festgelegt werden (1st, 2nd und 3rd Level Support). Last but not least muss das Wissen der Support-Organisation aufgebaut und ständig weiterentwickelt und ihre Arbeit evaluiert werden.

 

Prozessualer Support:

Für den prozessualen Support werden Prozessverantwortliche festgelegt und eine geeignetet Prozessdokumentation erstellt. Sie muss für alle am Prozess Beteiligten verfügbar, gut lesbar, aktuell und vollständig sein.

 

Prozessualer Support heißt einerseits, dass der Prozess unterstützt wird, bedeutet andererseits auch, dass sich der Support selbst im Prozess befindet: er wird durch kontinuierliche Kommunikation und Feedbacks verbessert und verändert sich dadurch. Für die Prozessqualität legen wir gemeinsam mit den Prozessbeteiligten geeignete KPIs fest und verfolgen diese ständig nach. Durch regelmäßige Schulungen, Roadshows und Regelmeetings für Updates für alle am Prozess Involvierten gewährleisten wir kontinuierliche Information und Weiterbildung. Schließlich klären wir die Frage, wie neue Mitarbeiter ausgebildet und in diesen Qualifizierungsprozess eingegliedert werden.

 

Change Management:

Während der gesamten Implementierung unterstützen Change Management-Maßnahmen den Prozess. Dabei ist es für den Erfolg der Implementierung unerlässlich, dass alle Entscheidungen in partizipativen Prozessen gefällt werden. Erprobte Tools dafür sind Workshops, Trainings, Interviews, Umfragen und ähnliche Formate. Jeder, der von der Veränderung betroffen ist, muss als Partner gewonnen werden, und so stehen am Anfang die einfachen, aber wichtigen Fragen: Wer ist betroffen? Wie wird sie oder er miteinbezogen?

 

Nur ein umfassendes Stakeholder Management, das alle miteinbezieht und als kontinuierlicher Prozess verstanden wird, garantiert den Erfolg. Im Mittelpunkt des Changes steht der Mensch, nicht die neue Software. Sie ist für die Anwender da, nicht anders herum. Gemeinsam erarbeiten wir daher Antworten auf die Frage: Was brauchen die Anwender, um die neue Software zu benutzen? Was ist nötig, damit sie sie gerne verwenden und als Hilfe verstehen? Die Antworten stülpen wir aber nicht von außen über, sondern erarbeiten sie gemeinsam. Denn nur wenn wir die Anwender im gesamten Projektprozess permanent miteinbeziehen, werden wir sie für die neue Sache gewinnen können.

 

Implementierungen von Planisware – oder auch von jeder anderen Software – bedeuten Veränderungen. Und Menschen mögen in der Regel keine Veränderungen. Mit unserer Erfahrung aus 15 Jahren Change Management-Projekten jedoch werden wir alle Stakeholder ins Boot holen. Durch bewährte Tools und Maßnahmen gewinnen wir sie für die Neuerung und machen für sie erfahrbar, wie hilfreich eine solche Veränderungen sein kann und wie sehr sie das Arbeitsleben erleichtern wird.