ImpulsLetter Q2 2019
Abstract
Mit Hilfe von SAP Cloud Anwendungen können Mitarbeitern in Ihrem Unternehmen innovative und intuitiv bedienbare Oberflächen bereitgestellt werden. Mittels Web- und App-Applikationen profitieren Sie von der intelligenten Nutzung Ihrer Daten und der noch effizienteren Darstellung Ihrer internen digitalen Prozesse.
Daten sind das neue Öl, so heißt es. Doch wer kann schon was mit Rohöl anfangen? Unternehmen stehen vermehrt vor der großen Herausforderung ihre Daten benutzerfreundlich, transparent, effizient, effektiv und ortsunabhängig bereitstellen zu können. Von den Herausforderungen in einem solchen Projekt und der grundlegenden Vorgehensweise mittels agilem Projektmanagement, möchten wir Ihnen in unserem ImpulsLetter an Hand eines Beispiels aus der Praxis berichten.
Daten sind das neue Öl, so heißt es. Doch wer kann schon was mit Rohöl anfangen?
„Wie können wir im Unternehmen unsere Daten noch einfacher nutzen und aufbereiten, um auf die Fragen unserer Kunden noch bessere Antworten liefern zu können?“
„Wo und wie können wir bei internen Prozessen Zeit sparen, um diese gesparte Zeit noch besser im Sinne unserer Kunden einsetzen zu können?“
Sollten Sie sich solche oder ähnliche Fragen bereits gestellt haben, sind Sie garantiert in bester Gesellschaft von Top-Entscheidern und aufstrebenden Führungspersönlichkeiten. Doch wie kommt man dem Ziel nun näher, Prozesse zu optimieren, schlanker zu gestalten, dabei den Überblick an der Fülle von vorhandenen Daten nicht zu verlieren und kann man nicht irgendwie diese “Digitalisierung”, von der nun alle reden, dafür einsetzen?
Geschäftsprozesse digital zu gestalten, kann hierfür eine der wesentlichen Antwortmöglichkeiten darstellen. Es ist dabei eine der zentralen Herausforderungen in Unternehmen, die dieses Themengebiet ernsthaft und nachhaltig vorantreiben wollen. Sehr häufig fallen bei ersten Beratungsgesprächen die Schlagworte Benutzerfreundlichkeit, Transparenz, Effizienz, Effektivität und – mittlerweile nun auch vermehrt – die ortsunabhängige Bereitstellung aller Daten. Dabei soll Kollege A mit exakt der gleichen Datenbasis arbeiten können, wie Kollege B. Und das selbstverständlich in Echtzeit, also ohne langwierige Transaktionszeiten.
Soweit so klar. Doch die ersten größeren Herausforderungen entstehen in Unternehmen in der Regel schon dann, wenn sie sich im Rahmen ihrer Digitalisierungsprojekte das Ziel gesetzt haben, Daten und Funktionen aus SAP-Systemen benutzerfreundlich, performant sowie prozessorientiert auf Front Ends wie Mobile Apps, Voice-Interfaces oder Web-Anwendungen bereitstellen zu wollen.
Die neue Zauberformel kann in diesem Kontext ein on-premise-SAP-System sein, mit dessen Hilfe die SAP Cloud Plattform für Digitalisierungsprojekte genutzt werden kann. Sollten Sie bereits bestehende on-premise-Installationen integriert haben, ist dies eine sehr gut geeignete Lösung, um vorhandene Daten intelligent zu nutzen sowie digitale Prozesse abbilden zu können. Die Anwender werden durch innovative und intuitiv bedienbare Oberflächen profitieren, die sowohl für Web-Anwendungen als auch, dem aktuellen Zeitgeist angemessen, für App-Versionen entwickelt werden können.
Nun ist das Themengebiet um die Integration von SAP Cloud Plattform noch relativ neu. Zumindest so neu, dass SAP selbst nach erfolgreich umgesetzten Beispielen aus der Praxis sucht, wie die berühmte Stecknadel im Heuhaufen. Wir haben mit unserem IT-Realisierungspartner DATAGROUP ein solches Projekt erfolgreich umgesetzt.
Faktencheck und Ideensammlung
Unser Kunde, ein Franchisebetrieb aus dem Bereich Retail, plante die Einführung einer neuen Ticketing-Lösung zur Immobilieninstandhaltung auf der Datenbasis von SAP-PM. Die Ansprüche der Franchisepartner und Gebäude-Manager waren klar vorformuliert und gesetzt: Vollumfängliche Transparenz und bessere Übersichtlichkeit des gesamten Vorgangs. Und ‘last but not least‘ wollten die Nutzer endlich wissen, was mit ihren Tickets eigentlich geschieht. Stichwort: Nachverfolgbarkeit.
Das neue Tool musste am Ende das Tages natürlich auch das können, was das bereits bestehende Ticketsystem mit “Teletextcharme” auch konnte – Tickets erfassen und zur Anzeige bringen. Darüber hinaus fanden wir folgende Eckdaten vor:
- Bei 800 bis 900 deutschlandweit verteilten Bauwerken werden p.a. ca. 22.000 Tickets eröffnet
- Davon werden potenziell ca. 14.000 Tickets von einem externen Dienstleiter betreut. Die verlängerte Werkbank des Unternehmens, welche den Inhalt der Tickets aufnehmen und mit zum Teil unter zu Hilfenahme weiterer Dienstleister lösen soll
- Das Front-End des bis dato bestehenden Ticketing-Tools war in puncto Usability, Übersichtlichkeit und Nachverfolgbarkeit nicht optimal. Je größer die Anzahl an offenen Tickets, desto höher die Zeitintensität der Informationsbeschaffung
- Aus der Sicht der Franchisepartner, die hauptsächlich die Erstellung der Tickets vornehmen, resultierten daraus lange Erledigungs- und Wartezeiten
- Die Durchgriffsmöglichkeiten unseres Auftraggebers auf die beauftragten Dienstleistungspartner waren eher gering.
Daraus ergab sich eine eindeutige Zielsetzung: Die Erhöhung der Benutzerfreundlichkeit bei der Erfassung der Tickets, als auch bei der Übersichtsansicht, hatten oberste Priorität. Es sollte Freude bereiten, das Tool zu benutzen (soweit man eben Freude haben kann, wenn man etwas melden muss, was defekt ist). Alle Vorgänge mussten schnell und intuitiv von statten gehen können. Dabei wollte man den Usern nicht nur auf dem gewohnten PC eine neue Anwendung zur Verfügung stellen. Nachdem für alle Standorte Tablets bereitgestellt wurden, sollte ebenfalls eine App entwickelt werden, die mit der gleichen Funktionalität der Webanwendung aufwartet, sich aber passgenau für das Tablet einfügt.
Die Qualität der Tickets sollte ebenfalls signifikant gesteigert werden. Allzu oft hat man doch in jüngerer Vergangenheit bei der Auswertung der bisherigen Tickets feststellen müssen, dass Kommentare wie “Gerät kaputt” nicht im Ansatz den aktuellen Zustand beschreiben können den ein Dritter bräuchte, um zu wissen, wie eine adäquate Hilfe hätte aussehen können.
Nicht zuletzt war die Transparenz im Prozessverlauf ein weiterer wesentlicher Punkt, den es zu verbessern galt. Bisher kam es nicht selten vor, dass der Ticketersteller im Laufe der Zeit nicht so recht wusste, wer sein Ticket gerade in Bearbeitung hat. Er wusste nicht, ob es eventuelle Komplikationen gab, an wen er sich hätte wenden können, oder wann sein Problem in etwa behoben sein würde.
Die Frage der Zuständigkeit, ob Franchisenehmer (also vorzugsweise der Ticketersteller) oder Franchisegeber in der Pflicht standen das Problem zu beheben, war ebenfalls ein ganz zentraler Bestandteil im Lösungsprozess. Bisher konnte es passieren, dass Tickets abgelehnt wurden, weil die Zuständigkeitsfrage meist nicht einfach zu beantworten war und ist. Allein eine Kommunikation, warum ein spezifischer Fall abgelehnt wurde, hätte allen Prozessbeteiligten sehr weiter geholfen. Ein Umstand, den es zu beheben galt.
Wie in einem solchen Projekt nicht gerade unüblich gilt es zunächst, alle Ideen zu sammeln und in eine logische Struktur zu bringen. Diese Sammlung wird im Verlauf des Projektes im Sinne eines sogenannten Product Backlogs weiter angereichert und die einzelnen Inhalte können immer wieder nach Relevanz und Sinnhaftigkeit neu priorisiert werden.
Ein ehrgeiziger Zeitplan für das Entwicklungsprojekt? Mit der richtigen Herangehensweise eine gut zu bewältigende Herausforderung
Die Grundherausforderung sowie die allgemeine Zielsetzung waren schnell definiert. Der Kunde hatte allerdings eine signifikante Herausforderung: alle Spezialisten, egal ob aus dem Fachbereich oder der “heimischen” IT-Abteilung, waren entweder vom Tagesgeschäft mehr als ausgelastet, oder waren bereits in anderen Projekten ausgelastet. Und wie meistens bei solchen Aufgabenstellungen – die Zeit drängte. Innerhalb von nur 7 Monaten, sollte eine fertige Lösung für den Rollout parat stehen. Zu einem feststehenden Termin, bei dem man allen Franchisepartnern die neue Lösung präsentieren wollte. Es war also schnell klar, dass das Projekt von Anfang an unter einem enormen Zeitdruck stand und man zusätzliche Ressourcen einkaufen musste.
Eine lange und ausgedehnte Konzeptionsphase konnte man sich auf dem Zeitstrahl nicht erlauben. So war relativ schnell klar, dass man auf eine agile Methode zurückgreifen musste. Für IT-Realisierungspartner auf dem heutigen Markt keine signifikante Herausforderung mehr, für die Organisation selbst stellte die agile Vorgehensweise völliges Neuland dar. Alle am Projekt beteiligten mussten sich demnach offen für neue Ansätze in der Herangehensweise von Lösungsbeschreibungen zeigen.
Wie agil darf es für Ihre Organisation sein?
Die agilen Ansätze aus der Softwareentwicklung haben auch im Projektmanagement neue Akzente gesetzt und verdienter Maßnahmen bereits einige Erfolge gefeiert. Doch fest steht auch, dass die Spezies derer, denen es weiterhin großes Unbehagen bereitet, wenn man das Wort „agil“ auch nur annährend in einem Konzeptvorschlag liest, noch nicht auf der Liste der bedrohten Arten zu finden ist. Worte wie Requirements, Design oder Engineering müssen und sollten auch keineswegs einfach so über den Haufen geworfen werden. Und selbstverständlich kann auch das Beste von verschiedenen methodischen Ansätzen miteinander vereint werden. Wichtig ist dabei aber vor allem, die Spielregeln vor Projektstart sauber aufgestellt zu haben und sich im Projektverlauf auch daran zu halten.
Der Grund dafür ist relativ simpel. Stellen Sie sich folgendes Szenario vor: Es ist Samstag. 15:30 Uhr. Für Fans der deutschen Fußball-Bundesliga erhält das Leben wieder einen ganz speziellen Sinn. In mehreren Stadien laufen die Spieler zum großen Stelldichein auf den grünen Rasen auf. Der unparteiische Leiter der Partie guckt vor dem Anpfiff in die Runde – alle da, das Spiel kann beginnen. Soweit nichts Unübliches. Doch plötzlich gibt es auf den Tribünen erstes Raunen. Der erste Spieler beginnt den Ball nur noch mit der Hand zu spielen, ein zweiter benutzt sein Trikot, um das runde Leder darin zu verstecken. Und der gegnerische Trainer wechselt derweil sein komplettes Wechselkontingent ein – ohne jedoch einen anderen Spieler dafür vom Feld zu nehmen. Ein großes Durcheinander beginnt. Jeder behauptet von sich, Recht zu haben und versucht sein Interesse durchzudrücken. Alles nur, weil die Spielregeln nicht klar definiert sind. Skurriler Gedanke? Auf jeden Fall! Aber gar nicht so abwegig. Immer wieder müssen wir feststellen, dass es in Projektteams nicht selten vorkommt, dass die Spielregeln nicht immer und nicht für jeden zu 100% bekannt sind oder auch durchaus in Frage gestellt werden. Am Ende des Tages bleiben große Diskussionen und der Erfolg (wie auch immer dieser definiert ist), wird auf der Strecke bleiben.
Sollte die agile Vorgehensweise und die Methodik Scrum noch nicht in Ihrem Unternehmen gelebt werden, ist es für alle Beteiligten eine nicht zu unterschätzende Veränderung der täglichen Arbeitsweise. In solchen Fällen ist es selbstverständlich von großem Vorteil, wenn man Realisierungspartner im Team hat, die aus vorangegangenen Projekten reichlich Erfahrung mit einfließen lassen können.
Eine klare Rollenverteilung am Anfang des Projekts ist dabei elementar. Vielleicht erkennt man diese Notwendigkeit von eindeutig abgesteckten Aufgabengebieten nicht von Beginn an. Doch spätestens bei der ersten etwas größeren Challenge wird einem die Wichtigkeit bewusst. Eine Herausforderung kann wesentlich effektiver gemeinsam bewältigt werden, wenn alle – und wirklich alle – Teammitglieder wissen, welche Rolle für welche Art und Weise der Aufgabenstellung verantwortlich ist. In diesem Praxisfall wurde der SCRUM-Master von unserem IT-Realisierungspartner Datagroup gestellt, der sein eigenes dazugehöriges Projektteam führte. Die Rolle des Product-Owners übernahmen wir als ADVYCE. Dem Kunden kamen die Rollen des Haupt-Auftraggebers (wohlwissend, dass der Product Owner nach Scrum-Definition als Auftraggeber fungiert. So sollte die Theorie an die Praxis angeglichen werden), Lenkungskreismitglieds, Stakeholders, IT Business Partners und Key Users zu. Dieser Personenkreis wurde in einem zweiwöchigen Rhythmus, im sogenannten Planning & Review Meeting permanent auf dem neuesten Stand gehalten.
Der Ablauf eines solches Planning & Reviews ist dabei immer gleich: Zunächst wird berichtet was in den letzten 14 Tagen alles passiert ist. Im Anschluss erfolgt die gemeinsame Priorisierung der nächsten Schritte im Projekt. Durch dieses immer gleiche Vorgehen erreichten wir bei allen Teammitgliedern sehr schnell Verständnis für das jeweilige Aufgabengebiet als auch für die agile Vorgehensweise. Als Resultat ließen sich auch diese Meetings zunehmend schneller und unkomplizierter abhalten.
Frei nach dem Motto “Wie isst man einen Elefanten? – Stück für Stück”, ist auch bei einer Software-Entwicklung unter dem Einfluss von Scrum, eine Entwicklung in mehreren Inkrementen vorgesehen. Dabei sind die Schritte innerhalb einer abgeschlossenen Iteration (Sprint) immer in der gleichen Abfolge zu tätigen:
- Analyse
- Konzeption
- Realisierung
- Evaluierung
- Rollout
Mit dieser Vorgehensweise wird sichergestellt, dass nicht nur Meilensteine in der Entwicklung gesetzt werden, sondern dass die Qualität eines Meilensteins (Inkrements) so definiert ist, dass sein fertiggestelltes Stück Funktionalität in sich abgeschlossen ist, funktioniert und damit zugleich produktiv einsetzbar ist.
In der Phase der Analyse werden im Prinzip die Weichen für einen erfolgreichen Ablauf des Sprints gesetzt. Umso besser die bisherige Welt verstanden wird, desto präziser können neue Lösungsansätze gefunden werden. Mit Stakeholder Interviews stellt man sicher, dass der Fokus klar gesetzt wird und ein einheitliches Verständnis von der zu entwickelnden Lösung gesetzt werden kann.
Während der Konzeptionsphase werden die User Stories formuliert. Dies ist die Hauptaufgabe des Product Owners. Nur wenn die User Story exakt und bis ins kleinste Detail beschrieben worden ist, kann man davon ausgehen, dass man bekommt was man sich vorgestellt hat. Sehr wichtig sind dabei vor allem die Akzeptanzkriterien. Was muss das Entwicklerteam liefern, damit das Inkrement abgenommen werden kann? Umso besser das Verständnis des Product Owners von den zukünftigen Anforderungen an die neue Lösung ist, desto besser wird am Ende das Entwicklungsergebnis sein. Dem Product Owner kommt also eine enorm hohe Wichtigkeit im Projektverlauf zu.
Während der Realisierung werden erste Mockups und Click Dummy’s vom Entwicklerteam erstellt, damit alle Teammitglieder ein schnelles und einfaches Verständnis davon bekommen, wo die Reise hin geht und ob es das ist, was man sich als Auftraggeber zu Beginn vorgestellt hat. Dabei findet der Style Guide selbstverständlich am besten von Anfang an besondere Beachtung, um doppelte Programmierungsarbeiten vermeiden zu können.
Die Evaluierung ist dann immer wieder die Phase der Wahrheit. In Review-Meetings wird bei den künftigen Benutzern abgefragt, ob es das ist was man braucht, um den Prozess effektiver zu machen, ob die Benutzerfreundlichkeit hoch und ob das Produkt intuitiv zu bedienen ist. Sollte sich bei diesen Tests herausstellen, dass einzelne Punkte nicht zur vollen Zufriedenheit umgesetzt wurden, sind die entsprechenden Fragmente zu identifizieren und nachzubessern.
Nach abschließenden funktionalen Tests startet der Rollout. Sobald die neuen Inkremente implementiert sind, kommt dem Issue Tracking eine besondere Bedeutung zu. Um die neuen Herausforderungen nicht nur schnell identifizieren zu können, sondern ebenso zeitnah eine geeignete Lösung zu entwickeln, sollten auch hier die Aufgabengebiete und -pakete klar verteilt und adressiert sein. In dieser Phase ist eine ausreichende Kommunikation an die User mehr als hilfreich. Wir empfehlen dabei, wie auch in diesem Projekt so vollzogen, alle Neuerungen anzukündigen und die Ausbaustufen kurz zu erläutern. Der User fühlt sich auf diese Art gut abgeholt und man erzielt den Nebeneffekt, die Aufmerksamkeit auf die neuen Inkremente zu richten. Eine gesteigerte Aufmerksamkeitsrate verspricht einen qualifizierteren Rücklauf bei der Einholung von Feedbacks, die ebenfalls in regelmäßigen Abständen durchgeführt und bewertet werden sollten.
Der Schlüssel zum Erfolg: Ein starkes Team, ein klar skizziertes Zielbild und eindeutige Spielregeln
Mit der Anwendung einer agilen Methodik im Projektmanagementumfeld haben Sie einen entscheidenden Vorteil auf Ihrer Seite: Zwar stehen am Anfang einige wenige Basisfunktionen fest, doch während des Projektverlaufs können Sie stetig Ergänzungen vornehmen oder diese (idealerweise vor der Realisierung) auch wieder entfernen. So haben Sie die Möglichkeit, völlig flexibel mit Blick auf Zeit und Ressourcen, den Projektrahmen auf Ihre Gegebenheiten anzupassen. Mit dieser Vorgehensweise umgehen Sie ebenfalls ausgedehnte Konzeptphasen, die am Ende womöglich doch nie zur Umsetzung kommen würden. Jedes gemäß Scrum entwickelte Inkrement ist gleichzeitig ein voll funktionsfähiges Fragment. Aber natürlich, Hand aufs Herz: Auch die beste Methodik ist nicht in der Lage, alle zwei Wochen eine komplett neue verkaufsfähige Version eines E-Autos zu präsentieren. Dennoch konnten wir in der praktischen Umsetzung auch in diesem Projekt erneut feststellen, dass die Wahrscheinlichkeit zur Einhaltung eines eng getakteten Zeitplans, mit Hilfe einer agilen Methodik, um ein Vielfaches angestiegen ist.
Ein weiterer elementarer Baustein ist die klare Rollenverteilung für eine beschleunigte Entscheidungsfindung. Nur Scrum Master und Product Owner sollten gemeinsam die Entscheidung treffen und alle wesentlichen Informationen in die Organisation kommunizieren.
Die Position des Product Owners ist hierbei unserer Erfahrung nach, die wichtigste Instanz im Scrum-Team. Selbstverständlich können Sie dieses zentrale Organ in einem Projekt durch externe Ressourcen besetzen. Es ist aber unabdingbar, dass der Product Owner absoluter Experte auf seinem Gebiet ist und die Prozesse innerhalb der Organisation voll verstanden und durchdrungen hat. Nur dann wird diese Rolle in der Lage sein, die Erwartungshaltung an diese Positionen in Gänze erfüllen zu können.
Mögliche Verzögerungen im Projektablauf sind nicht immer vorhersehbar, grundsätzliches lassen sich aber einige Stolpersteine vorher antizipieren. Beginnen Sie wenn möglich schon vor dem eigentlichen Projektstart Werbung für Ihre Zielvorstellung zu machen. Je eher Sie von vornherein Ihre Organisation mit auf die Reise nehmen, desto früher werden Sie Input erhalten, den Sie während des gesamten Projektverlaufs immer wieder neu einholen und bewerten können. Identifizieren Sie von Beginn an Ihre wichtigsten Spezialisten und Stakeholder für das Projekt. Stellen Sie sicher, dass diese so früh wie möglich eingebunden werden und dass sie, sobald es ernst wird, auch zur Verfügung stehen.
Möchten Sie mehr zu den technischen Vorteilen der SAP Cloud Plattform erfahren, melden Sie sich gerne unter folgendem Link für ein kostenfreies Webinar bei unserem IT-Realisierungspartner Datagroup an.
Die erfolgreiche Umsetzung Ihres Projektes ist unser oberster Anspruch
Fazit:
SAP-Projekte erfolgreich „in time“ und „in budget“ umzusetzen, muss nicht zwangsläufig bloße Theorie bleiben. Als erfahrene Projektpartner unterstützen wir Sie gerne von der Analyse bis zum Roll-Out und dem After-Go-Live Support. Wir konzentrieren uns mit der ADVYCE–Stakeholder-Analyse auf die adäquate Einbindung Ihrer Kompetenzträger(innen), um bereits frühzeitig das Buy-in aller wichtigen Instanzen zu erhalten. Mit unserer speziell entwickelten Toolbox unterstützen wir Sie bei der Analyse von Möglichkeiten zur Prozessdigitalisierung. Gerne entwickeln wir gemeinsam mit Ihnen die Kommunikationsstrategie, bereiten Unterlagen für Lenkungsausschüsse oder sonstigen bei Ihnen etablierten Instanzen vor. Unser Ansporn ist es, ein professionelles Projekt-Management, ausgerichtet an Ihren Ansprüchen maßgeschneidert und schnittstellenübergreifend für Sie aufzusetzen. Selbstverständlich profitieren Sie dabei auch von unserem erfahrenen Partnernetzwerk.
Tobias Hörandel