Die Abkündigung der Texterstellungslösung DOPiX schafft vor allem bei Versicherungsunternehmen massive Unruhe. In den Köpfen von betroffenen Betriebs- und IT-Einheiten spielen sich nun technisch geprägte Auswahl- und große Migrationsprojekte ab. Aber ist diese Herangehensweise als IT-Projekt überhaupt richtig? Mit viel Erfahrung im Bereich Customer Communication Management (CCM) wollen wir das ganz gezielt hinterfragen und drei mögliche Aspekte nennen, die aus einem unerwarteten Desaster zu unerwarteten Potentialen führen. Wirklich? Wirklich!

Die unerwartete Abkündigung der Texterstellungslösung DOPiX von Quadient hat die meisten Kunden kalt erwischt und sorgt nachhaltig für Unruhe in der CCM-Branche. Besonders betroffen ist die Versicherungswirtschaft, aus der ca. 75 % der 30 größten deutschen Versicherungen DOPiX-Kunde sind. Und nun in einem Auslaufmodell stecken. Was hier nun als Lösung förmlich wegbricht, ist salopp gesagt „systemrelevant“. Bevor wir aufzeigen, wie betroffene Unternehmen diese Lage statt in ein weiteres, reines IT-Projekt viel besser für eine zeitgemäße Herangehensweise nutzen können – ein nüchterner Status Quo:  Aus Perspektive des Herstellers Quadient ist die getroffene Entscheidung gar nicht so abwegig. Der Hersteller hat zwei Produkte mit vergleichbarem Funktionsumfang im Portfolio, wovon DOPiX als das weniger zeitgemäße Produkt angesehen werden muss. Dass Quadient die bestehenden Ressourcen somit auf ein Produkt bündelt und DOPiX perspektivisch auslaufen lässt, ist nachvollziehbar. Aber Kundenorientierung sollte anders aussehen. Denn wie eine derart weitreichende Entscheidung den eigenen Kunden kommuniziert wurde, und welche Zeitfenster und Rahmenbedingungen geboten werden, erscheint selbst mit einem gewissen Verständnis für angloamerikanische Kommunikations- und Produktpolitik nicht nachvollziehbar. Es ist schlichtweg nicht kompatibel zu deutschen Wertvorstellungen von Zuverlässigkeit und Vertrauen.

Wie eine Redensart in meiner Kölner Heimatregion besagt – „Et kütt wie et kütt“ („Es kommt, wie es kommt“) – muss bei aller Enttäuschung und Emotionalität nun ein kühler Kopf gewahrt werden. Dazu haben wir drei grundlegende Empfehlungen. Und die haben wir aus über 20 Jahren Erfahrung in solchen Situationen und Fachprojekten. Fangen wir an.

1) Nur ein Ersatz für DOPiX ist kein guter Ersatz: Die CCM-Strategie.

Im Rahmen des Customer Communication Managements (CCM) investieren Unternehmen enorm in die zielgerichtete Kommunikation und Interaktion mit dem Kunden. Nutzen Sie die Gelegenheit, Digitalisierung und Kundenzentrierung zeitgemäß und umfassend anzugehen. Denn während die meisten bestehenden DOPiX-Installationen sehr auf die papierbasierte Briefkorrespondenz ausgerichtet sind, bieten moderne CCM-Systeme ein deutlich breiteres Leistungsportfolio für die interaktive Kundenkommunikation.

Es gilt daher in der Anforderungsanalyse neben bestehenden Funktionen, die heute von DOPiX abgedeckt werden, auch die übergeordneten Kommunikationsanforderungen zu betrachten und abzuleiten, welche Potenziale mit einem neuen System erfasst werden können. Sie werden sehen, es entsteht ein ganz neues Projektbild, das im Übrigen nicht komplexer sein muss, als eine reine Ersatzlösung. Dafür aber strategisch wesentlich nachhaltiger.

 2) Vorlagenmigration sollte nicht alter Wein in neuen Schläuchen sein: Fokus auf zentrale Ressourcenverwaltung

Verlassen Sie veraltete Herangehensweisen und bauen Sie technische Schulden ab. Die Vorlagenmigration dürfte im Gesamtprojekt den größten Ressourcen- und Zeitbedarf beanspruchen. Es wird je nach Komplexität der Vorlagen technische Möglichkeiten von teil- und vollautomatisierten Migrationen geben. Es gilt jedoch kritisch zu prüfen, ob dies überhaupt zielführend erscheint. Häufig sind die Vorlagenbestände im Laufe der Jahre stark gewachsen und beinhalten teilweise Fachlogiken bis hin zu Fachdaten innerhalb der Vorlagen. Deshalb sollte heutzutage eher ein zentraler Textservice angestrebt werden, der kommunikationskanalübergreifend Korrespondenzen „bestückt“. Das schafft neue Möglichkeiten und wird kundenzentrierter Kommunikation von heute gerecht.

„Nur ein Ersatz für DOPiX ist kein guter Ersatz. Drei Aspekte sollten berücksichtigt werden, um das Projektvorhaben zeitgemäß und nachhaltig umzusetzen.“

3) Time to Market entscheidet: Moderne CCM-Lösungen für schnellere Prozesse

Viele DOPiX-Kunden verfügen über einen großen Bereich der Vorlagen-Entwicklung. Fachliche Anforderungen, beispielsweise textuelle Änderungen in Testbausteinen, führen oftmals zu hohen Aufwänden. Zum Beispiel im Austausch zwischen Fachbereich mit Vorlagenentwicklung, technischer Umsetzung, Test bis hin zur Produktivstellung. Damit sind zwangsläufig lange Laufzeiten vorprogrammiert. Aber das ist eine langsame, interne Sichtweise, die mit modernen CCM-Lösungen spürbar effizienter gestaltet werden kann. Der Markt bietet hervorragende Lösungen mit zeitgemäßen Steuerungsmöglichkeiten und leicht verständlichen Benutzeroberflächen im Sinne einer No- bzw. Low-Code-Entwicklung. So können Fachbereiche selbst leichte Anpassungen wie bspw. Textänderungen umsetzen. Dies vereinfacht interne Prozesse, verkürzt Bereitstellungszeiten und erhöht die Reaktionsgeschwindigkeit deutlich. Es sollte also vor Projektstart bewertet werden, inwiefern auch organisatorische und prozessuale Potenziale mit der Neueinführung der Texterstellung verbunden werden können.

Im Gesamtfazit: Lassen Sie sich auf Basis der aktuellen Lage nicht in ein reines IT-Projekt treiben. Nutzen Sie übergeordnete Potentiale und die Möglichkeiten des Marktes, die deutlich über eine reine Ersatzlösung hinausgehen. Die DOPiX-Ablösung sollte in erster Linie fachlichen und strategischen Anforderungen der Unternehmen folgen und primär aus diesen Perspektiven geplant werden. So wird aus dem zweifelsfrei großen Projektvorhaben keine reine Notwendigkeit, sondern vor allem die Chance, jetzt die Kundenkommunikation nachhaltig und effizient neu auszurichten.

Viel Erfolg!

Strategien waren lange weitgehend autarke Unternehmens-Entscheidungen. Mit der Digitalisierung, die von nicht wenigen als „die nächste industrielle Revolution“ bezeichnet wird, ändert sich das deutlich. Denn Digitalisierung ist keine rein interne Überlegung – sie findet überall statt, wird von jedem einzelnen Kunden getrieben und mit vielen innovativen Nadelstichen täglich erneuert. Das zieht eine bedeutende Erkenntnis nach sich: Eine Digitalisierungs-Strategie kann heute nichts mehr sein, was auf hoher Managementebene entschieden und dann per Organigramm nach unten diktiert wird. Nur, wenn das ganze Haus organisatorisch, prozesshaft und kulturell erfasst wird, entsteht die Bewegung, die dringend gebraucht wird. Das klingt abstrakt und sehr nach Berater-Talk? Nein, das ist hochpragmatisch, denn es gibt sofort griffige Hebel.

Von ganz oben zuerst nach ganz unten denken

Wie die digitale Transformation in einem Unternehmen genau ablaufen wird, ist von Unternehmen zu Unternehmen unterschiedlich. Hier gibt es leider keine Strategien von der Stange. Was aber immer wieder deutlich wird, ist, dass jede Digitalisierungs-Strategie solange Papier bleibt, bis das Fundament sie überhaupt ermöglicht. Erst, wenn die technologischen und organisatorischen Grundlagen gesetzt sind, werden Ideen, Business Cases und Kundenzentrierung erst möglich. Aber dann auch sehr konkret und schnell. Denn in Zeiten der digitalen Transformation kann man nicht warten, bis alles theoretisch für Jahre durchgeplant ist. Sonst überholt der Markt die Pläne. Ihre Strategie muss robust, aber auch agil sein.

Agile Digitalisierungs-Strategien

Die COVID-19-Pandemie hat vielen Unternehmen drastisch vor Augen geführt, was geschieht, wenn Geschäftsprozesse und ‑modelle nicht digital funktionieren. Die Pandemie war in den vergangenen Jahren jedoch nur eine von vielen kulturellen, wirtschaftlichen, politischen und marktbezogenen Veränderungen, mit denen Unternehmen konfrontiert wurden.

Die Digitalisierungs-Strategie und letztlich die digitale Transformation muss sich an aktuelle Gegebenheiten schnell anpassen und die Reaktionsfähigkeit des Unternehmens sichern. Dazu braucht es Werkzeuge und vorausschauenden Analysen, mit denen Störungen, Marktveränderungen und neue Chancen frühzeitig erkannt werden

Wie wir Strategien wirksam spiegeln und spürbar in Bewegung bringen.

Der Weg zu einer digitalen Strategie ist komplex. Es ist nicht „diese eine Präsentation“, die Sie abhaken und morgen umsetzen. Es ist ein Prozess mit vielen Einflussfaktoren von innen und außen. Die Konsolidierung eines solchen Prozesses in eine eindeutige, klar erfassbare und umsetzbare Strategie ist eine Herausforderung. Zumal diese Strategie auch hin zur nächsten Führungsebene und in Fachabteilungen übersetzt werden muss. An diesem Punkt setzt Pentadoc an. Und zwar nicht als Besserwisser-Berater, der Ihre Strategie noch einmal in Frage stellt, sondern als plakativer Spiegel auf unser Modell des Digitalen Hauses.

Die Vorteile werden mit einem Blick auf unser Modell klar: Ihre Strategie bekommt eine bildhafte Struktur, die sehr direkt und individuell erkennbar macht, welche Ebenen und Säulen berücksichtigt werden müssen – und was genau an diesen Stellen zu tun ist, welche Lücken da sind und wo Potentiale stecken. Dabei dient unser Modell auch längerfristig als Reflektion zu den Entwicklungen Ihres Unternehmens und wird damit zu einem wertvollen Monitoring-Instrument.

Pentadoc übersetzt Strategien in die Praxis:

• Konsolidierung Ihrer Digitalisierungs-Strategieunterlagen
• Übersetzung vorhandener Erkenntnisse, Ziele, Zusammenhänge und Aufgaben der Methodik des Digitalen Hauses
• Plakatives Aufzeigen von Potentialen, konkreten Aufgaben, Notwendigkeiten, Quick Wins und Lücken
• Erste Empfehlung zu Umsetzungsprioritäten mit Fokus auf das digitale Fundament

Eine digitale Strategie braucht einen agilen Fahrplan und die richtigen Stopps für einen aktuellen Marktabgleich

Die Strategie steht – doch wo genau fängt man am besten an? Diese Abwägung ist für Unternehmen schwer. Denn in dieser Frage stecken neben wirtschaftlichen Entscheidungen auch taktische, organisatorische, technische, personelle und „innenpolitische“ Abwägungen. Auch an dieser Stelle bietet das Modell des Digitalen Hauses gute Unterstützung: Digitale Transformation wird für Ihr Unternehmen erst umsetzbar, wenn das digitale Fundament ausgereift ist. Das bedeutet nicht automatisch die allererste Priorität – aber eben auch keine, die weit hinten liegt. Denn sonst laufen andere Projekte in schwarze Löcher: Man will etwas auf den Weg bringen, aber die Voraussetzungen dafür sind nicht geschaffen – Projekte und Ideen kommen zum Stillstand. Wir prüfen und entwickeln verschiedene Umsetzungsszenarien auf Basis der vorliegenden Strategie – sowohl zeitlich, wie auch inhaltlich und bringen Themen in kausale Zusammenhänge. Daraus entwickeln sich Szenarien mit ineinandergreifenden Projekten, die mit Meilensteinen versehen werden. So wird Ihre Strategie ein robuster und agiler Umsetzungsplan.

Selbstverständlich steht bei Business Cases die harte Bewertung des finanziellen Erfolgs an erster Stelle. Das sollte man auch in Digitalisierungsprojekten und Ideen zur Digitalen Transformation nicht in Frage stellen. Aber man sollte unbedingt berücksichtigen, dass die Digitale Transformation ganz neue Währungen zur Beurteilung eines Business Case mit sich bringt. Und die sind nicht weniger wertvoll – denn Innovationen, neue Geschäftsmodelle, Reichweite oder Kundenzufriedenheit sind enorm wichtig für die wirtschaftliche Entwicklung eines Unternehmens. So kann ein Business Case nichts verdienen – aber enorme Reichweite schaffen. Oder die Kundenzufriedenheit steigern, was sich nur indirekt in weitere Käufe hochrechnen lässt. 

Unsere Beratungspraxis zeigt uns immer wieder, das Unternehmen sich im Kontext der Business Cases besonders mit diesen Punkten beschäftigen sollten: 

• Konsequenter Abgleich mit der übergeordneten Digitalisierungsstrategie 
• Strukturierung von Business Cases in gut vergleichbare Raster 
• Bewertung nach wirtschaftlichen Parametern mit einer etablierten Methode 
• Benchmarking mit potentiell bestehenden Modellen oder Ideen des Marktes 
• Bewertung nach weiteren Parametern, die im Rahmen der Gesamtstrategie positive Wirkung entfalten könnten 

„Von der Dach-Strategie aus denken, bewerten und rechnen.“ 

 Die Bewertung eines Business Case sollte ganz grundsätzlich nie isoliert geschehen. Der wichtigste Bewertungsfaktor ist immer zuerst die Passgenauigkeit zur übergeordneten Digitalisierungsstrategie des Unternehmens. Gibt es hier keine der obengenannten Währungen, die der Strategie Momentum verleihen, muss der Business Case zurücktreten. Nur sehr wenige Business Cases haben die Kraft, die zu Strategieanpassungen führen könnte. 

Benchmarking und Best Practices 

Bei Digitalisierungsvorhaben ist wie zuvor beschrieben die Gegenüberstellung von Kosten und Nutzen nicht immer zielführend. Das liegt ganz offensichtlich daran, dass sich bei der Bewertung von Innovationen oder von Kundenzufriedenheit die monetären Erfolge erst später einstellen und es häufig nur einen sehr geringen Erfahrungsschatz gibt, auf den man als Unternehmen zurückgreifen kann. 

Das führt regelmäßig zu Problemen, da in vielen Unternehmen eine Investition in neue Technologien oder Veränderungsmaßnahmen nach wie vor an einen positiven Business Case gekoppelt sind. Was aber tun, wenn eigentlich klar ist, dass ein Business Case für ein Digitale Transformation überwiegend eine Auflistung bestmöglicher Annahmen ist und die Entscheidung einen „Blick in die Glaskugel“ benötigt?  

„Benchmarking, Best Practices oder gar Prototypen bieten die Möglichkeit, mit begrenzten Mitteln eine solide Basis für die Bewertung einer digitalen Idee zu schaffen.“ 

Noch nie war es so einfach und zugleich so unübersichtlich, mit Benchmarking und Best Practice-Beispielen zu arbeiten. Das liegt zum einen daran, dass im Rahmen der Digitalen Transformation sehr viele unterschiedliche Modelle und Vorgehensweisen transparent verfügbar sind und recherchiert werden können. Zum anderen sind es ebenso viele, dass die berühmte Trennung von Spreu und Weizen aufwändig ist. Hier sollten Unternehmen auf die Erfahrungen neutraler Spezialisten vertrauen, die über zahlreiche unterschiedliche Projekte hinweg, auf sehr robuste Best Practices zurückgreifen können. Das ermöglicht dem Unternehmen eine schnelle und sichere Beurteilung ohne die beschriebene, aufwändige Eigenrecherche.  

Eine Zukunftswerkstatt als Umsetzungs-Instrument für aufgeschlossene Unternehmen und Mitarbeiter. 

Im Rahmen der digitalen Transformation kommen in der Umsetzungsphase teils einschneidende Veränderungen auf Unternehmen zu. Mit dem Format der Zukunftswerkstatt beziehen wir Mitarbeiter und Entscheidungsträger anhand von praktischen Prototypen in den Transformationsprozess des Unternehmens mit ein. Wir führen schrittweise und nachvollziehbar vom Status Quo zu zukünftigen Möglichkeiten.  

Die Zukunftswerkstatt umfasst organisatorische, technologische und emotionale Bereiche der digitalen Transformation: 

• Feststellung des Status Quo im eigenen Unternehmen 
• Aufzeigen von Benchmarks der Digitalisierung im direkten Wettbewerbsumfeld 
• Erörterung zukünftiger Lösungsmöglichkeiten 
• Konkrete Auswahl von Lösungen des Marktes und Bewertung im Team 
• Bewertung nach weiteren Parametern, die im Rahmen der Gesamtstrategie positive Wirkung entfalten könnten 

Innerhalb dieses Frameworks werden die strategischen Aufgaben des Unternehmens, der Teams und der Mitarbeiter spezifiziert und die unternehmensinterne Kommunikation durch Transparenz verbessert. Es verknüpft, stets am Leitbild orientiert, die Ziele und Ergebnisse der gesamten Organisation.

Basierend auf dem Fundament starker Führung und gesundem Urteilsvermögen können OKR große Erfolge mit sich bringen, indem sichergestellt wird, dass alle Aktivitäten auf die gleichen und priorisierten Ziele fokussiert werden. OKRs wurden zuerst bei Intel eingeführt, als Intel-Mitgründer Andrew Grove das System in Anlehnung an Managementmethoden wie MBO (Management by Objectives) und SMART (Specific Measurable Accepted Realistic Time Bound) entwickelte. Ende der 90er Jahre gelangte die Methode über John Doerr zu Google, die sich seither erfolgreich mit OKR führen.

Die OKR werden sowohl Top-down – die Managementebene setzt Prioritäten für den kommenden Zyklus – als auch Bottom-up entwickelt. Dabei definieren die Teams und Mitarbeiter OKRs, welche dann auf Unternehmensebene konsolidiert werden.

Die Objectives sind ein richtungsweisendes Ziel mit einer emotionalen und motivierenden Funktion für Teams und Mitarbeiter. Os beschreiben Outcomes, das heißt OKR verändert die Denkweise von Input (Was tun wir?), über Output (Was kommt dabei heraus?) zum Outcome (Was bringt das?). Als Beispiel, man baut eine Bohrmaschine (Input), die ein Loch bohrt (Output), um etwas aufzuhängen (Outcome).

Key Results wiederum geben zu dem Objective passende Maßstäbe vor, wie das Ziel erreicht werden kann und überwachen die Zielerreichung. Key Results sind quantitativ messbar, spezifisch und zeitgebunden. Sobald alle Key Results zu einem Objective erfüllt sind, gilt dieses automatisch als erfüllt. KRs sind Outputs und zerlegen das Objective möglichst in seine logischen Dimensionen.

In der Regel zieht sich ein OKR-Zyklus über den Zeitraum von drei Monaten. In einem solchen Zyklus werden drei bis fünf Objectives betrachtet mit jeweils zwei bis vier Key Results.

Das moderne Output Management bedient heutzutage Kunden auf verschiedenen Kommunikationskanälen. Im Unternehmen selbst wird die Kundenkommunikation ebenfalls auf verschiedensten Wegen erzeugt. Um die Kundenkommunikationsprozesse auf die zukünftigen Anforderungen hin auszurichten muss die Output Management Wertschöpfungskette, welche von der Erstellung der Kommunikation bis hin zum Kunden reicht, betrachtet werden. In einer dynamischen Digitalisierung ist das Verständnis für vielfältige und wechselnde Kanäle hier eine Schlüsselaufgabe.

Entsprechend der im Unternehmen vorhanden Kundenkommunikationsprozesse und der zukünftigen Anforderungen müssen die in den zentralen Verarbeitungsschritten des Output Managements enthaltenen Ablaufschritte untersucht und hinsichtlich ihrer Zukunftsfähigkeit geprüft werden. Dabei ist es entscheidend das die eingesetzten Komponenten sowohl eine individuelle Kundenansprache ermöglichen, aber gleichzeitig eine größtmögliche Industrialisierung, d.h. eine standardisierte Bearbeitung und Verarbeitung ermöglichen.

Die zentralen Verarbeitungsschritte in der Output Management Wertschöpfungskette sind im Überblick:

Pre-Processing

Im Pre-Processing werden die Daten aus den führenden Applikationen und Kernsystemen gesammelt und für die Folgeverarbeitung(en) einheitlich aufbereitet und geprüft. Dabei gibt es diverse Prüfmechanismen, welche nach einem Durchlauf validierte Datensätze übergeben.

Processing

Die gesammelten Daten können noch mit individuellen Informationen angereichert und entsprechend aufbereitet werden. Nach einer erneuten Validierung erzeugen mehrere Rendering Nodes die druckbaren Dokumente.

Post-Processing

Dieser Verarbeitungsschritt stellt das Herzstück des Output Management Systems dar. Im Post-Processing werden die Kernfunktionalitäten des Output Managements genutzt. Dabei werden die vom Rendering gelieferten Dokumente empfängergerecht zusammengestellt und zu einem Datenstrom aufbereitet, der an den Drucker oder andere Medien versandt werden kann.

Chanel Communication

Channel Communication ermöglicht mit dem Kunden auf unterschiedlichen Wegen zu kommunizieren. Hierbei kann die Kommunikation in Richtung Kunde z.B. via E-Mail, Social Media oder Post erfolgen. Sämtliche Kundenkommunikation wird parallel im Kundenportal dem Kunden zur Verfügung gestellt. Gleichzeitig erfolgt immer die Archivierung sämtlicher Kommunikation.

Scrum hat sich unter den Frameworks für die agile Entwicklung weit verbreitet und viele Unternehmen profitieren von der resultierenden Flexibilität und verkürzter Time-to-Market. In unserer Beratungspraxis nutzen wir Scrum in Projekten und haben das Framework und seine Möglichkeiten für ein grundlegendes Verständnis plakativ aufbereitet. Also was ist und was kann Scrum?

Der Begriff hat seinen Ursprung im Rugby und wurde adaptiert, um die Bedeutung der Einheit des Teams und das kooperative, selbstorganisierte Miteinander hervorzuheben.

Entwickelt wurde Scrum 1995 von den beiden Autoren des Scrum Guides Ken Schwaber und Jeff Sutherland. Zunächst hatte sich die Methodik in der Softwareentwicklung etabliert, aber heutzutage ist Scrum für agile Prozesse und als Vorgehensmodell im Projektmanagement angekommen.

Unternehmen entscheiden sich primär für diese Methoden, da sie höhere Ergebnisqualität, motiviertere Mitarbeiter und eine schnellere Umsetzung der Anforderungen verspricht.

Die Abbildung verdeutlicht die Verknüpfung der Funktionsweise des Frameworks Scrum und den einzelnen Komponenten. Bei Scrum wird ein iterativer, inkrementeller Ansatz verwendet. Hinter inkrementellen Prozessen steckt in der Softwareentwicklung das Liefern von Ergebnissen in Einzelteilen. Jedes Inkrement repräsentiert hierbei eine in sich komplette und verwendbare Funktionalität. Iterative Prozesse bedeuten in diesem Kontext, dass Verbesserungen schrittweise durchgeführt werden, bis das gewünschte Endprodukt erarbeitet ist.

Im Ein- bis Vier-Wochen-Takt finden im Kontext dieser Iterationen sogenannte Sprints statt, in welchen gesetzte Ziele und Aufgaben bearbeitet werden. Diese kurze Taktung erlaubt es, neue Erkenntnisse und veränderte Anforderung schneller in der Umsetzung zu berücksichtigen.

Im Rahmen jedes Sprints spielen vier verschiedene Events eine zentrale Rolle. Zu Beginn jedes Sprints findet ein Sprint Planning durch das gesamte Scrum Team statt. Im Rahmen des Sprint Plannings werden alle Ziele und Aufgaben für den anstehenden Sprint zusammengetragen und die entsprechenden Verantwortungen aufgeteilt. Bei dem Daily Scrum kommt das Scrum Team zusammen und spricht innerhalb von 15 Minuten über den aktuellen Stand der Arbeit auf dem Weg zur Erreichung des jeweils aktuellen Sprintziels. Das Sprint Review findet am Ende eines Sprints statt. Das Team kommt auch hier im Plenum mit seinen Auftraggeber*innen zusammen und überprüft die Aufgabenerreichung des vergangenen Sprints. Im Anschluss bietet die Sprint Retrospektive die Möglichkeit, bisherige Arbeits- und Vorgehensweisen teamintern zu reflektieren und anzupassen.

Die Kombination aus fokussiertem Arbeiten und bewusster Reflektion des eigenen Handelns, die eine bewusste Anpassung des individuellen und gemeinsamen Arbeitens ermöglichen soll, ist eines der essentiellen Merkmale von Scrum.

Im Idealfall sollen alle Ergebnisse, Themen, Ideen, Erkenntnisse oder Anforderungen in angebrachtem Umfang dokumentiert und für die Zukunft festgehalten werden. Alle Fortschritte und Ergebnisse sind für alle Stakeholder transparent.

Das bereits mehrfach erwähnte Scrum Team arbeitet gemeinsam an der Zielerreichung und beinhaltet hierfür verschiedene Verantwortungen. Ein solches Team besteht aus bis zu zehn Mitgliedern, unter welchen die Rollen mit den Bezeichnungen Scrum Master, Product Owner und Developer aufgeteilt werden. Hierarchien oder Teilteams existieren in diesem Kontext nicht.

• Ein Product Owner ist verantwortlich für die Gestaltung und Bestimmung der unterschiedlichen Aufgaben. Er/sie ist fokussiert auf die Wertmaximierung. Darüber hinaus ist er/sie bezüglich der Zielerreichung in ständiger Rücksprache mit den Stakeholdern.
• Der Scrum Master ist für die Effizienz des Teams verantwortlich. Es/sie coacht das Scrum Team und unterstützt sowohl das Team als auch die Organisation dabei die Scrum-Theorie zu verstehen und anzuwenden. Es/sie verantwortet das Rahmenwerk der Zusammenarbeit. Darüber hinaus begleitet er/sie das Team individuell und im Ganzen, hilft bei Konfliktlösung und steuert Feedback bei, um die Entwicklung des Teams beständig anzuregen.
• Die Developer liefern die Produktfunktionalität und die nötige Qualität. Ihre Aufgaben werden abhängig von Fähigkeiten und Anforderungen definiert.

Scrum stellt in Betrachtung der Vorteile und Flexibilität der Handhabung ein ideales Werkzeug dar, um Veränderungen im Unternehmen erfolgreich umzusetzen. Das Risiko des Scheiterns wird durch Anpassungen während des Vorgangs, klare Rollen und Aufgaben und das begleitende Feedback minimiert. Die Qualität des Ergebnisses ist durch andauernde Einbindung des Kunden, Nutzung bereits vorhandener Kompetenzen und den kontinuierlichen Lernprozess gewährleistet. Darüber hinaus ermöglicht die Bündelung von Kapazitäten in einem Zeitplan eine effiziente Erledigung der einzelnen Aufgaben.

Auch Teamfaktoren werden im Rahmen von Scrum nicht vernachlässigt. Die täglichen Abstimmungen und Zusammenarbeit fördern den Zusammenhalt und das Netzwerken maximal.

Insgesamt führt eine agile und zentrale Teamsteuerung zu einer gesteigerten Effektivität, kontinuierlichen Verbesserungen der Ergebnisse und der bestmöglichen Durchführung von Veränderungsprozessen.

Haben Sie schon einmal vergleichbare Aussagen gehört:

• Testen ist nur etwas für Feiglinge
• Wir haben keine Testumgebung, wir entwickeln und testen direkt in Produktion
• Dokumentation und Testfälle gibt es nicht, bei uns ist Frau/Herr Spezialist für das Thema, sie/er testen das schon
• Den Fehler in der Produktion kann ich mir gar nicht erklären
• Der Go-Live ist in der nächsten Woche, wir haben jetzt keine Zeit mehr umfangreich zu testen
• Ein kurzer Antest reicht, den Rest korrigieren wir dann in der Praxis
• In Scrum gibt es ja kein Testmanagement mehr

Diese Aufzählung lässt sich beliebig fortsetzen. Häufig entscheiden sich Projektverantwortliche für den termingerechten Go-Live und verzichten auf qualitative Lösungen am Kunden.

Das Testmanagement ist vergleichbar mit der Planprüfung bei Bauprojekten. So nimmt beispielsweise ein Statiker im Gebäudebau eine wichtige koordinierende und kommunikative Aufgabe ein und unterstützt den Bauherren bei der Abnahme von Bauprojekten.

Um den hohen Anforderungen des Kunden, aber auch der internen Mitarbeiter, an eine neue Lösung in Digitalisierungsprojekten gerecht zu werden und die Akzeptanz für die Lösung frühzeitig auf ein hohes Niveau zu bringen, ist das Testen in jeder Entwicklungsstufe alternativlos – unabhängig davon, nach welchem Vorgehensmodell die Lösungen entwickelt werden.

Agiles Testmanagement

In agilen Frameworks, wie zum Beispiel Scrum oder Kanban, wird das Testmanagement beziehungsweise das Testen nicht explizit adressiert. Es wird vielmehr vorausgesetzt, dass dies durch das Team mit abgedeckt wird. Das Testmanagement ist also untrennbar mit der Entwicklung verwoben und keine eigene Disziplin bzw. Rolle.

Es mag zwar Entwickler geben, welche mit einem hohen Maß an Qualität an die Entwicklung ihrer Lösungen gehen, aber aus eigenen Erfahrungen bleibt es häufig bei kurzen Entwicklertests, bevor die User-Story zur Abgabe an den Product Owner übergeben wird.

Auch in agilen Projekten empfehlen wir dem Product Owner, mindestens einen Spezialisten in seinem Team zu etablieren, welcher seinen Entwicklungsfokus auf die Bereiche Testmanagement, Qualitätssicherung, Fach- und Akzeptanztests sowie die Anforderungsgetriebene Entwicklung legt.

Denken Sie nur an das Beispiel des Bauprojektes: Der Bauherr würde sich doch niemals nur auf die auf die Ratschläge der Handwerker verlassen, was das Thema Statik angeht!

Testgetriebene oder besser: Anforderungsgetriebene Entwicklung

Häufig wird in der Entwicklung neuer Lösungen nach dem Prinzip der testgetriebenen Entwicklung vorgegangen. Bei der testgetriebenen Entwicklung erstellt der Entwickler Software- und funktionale Tests konsequent vor der eigentlichen Entwicklung der zu testenden Software.

Haupteinwand gegen die testgetriebene Entwicklung ist der vermeintlich hohe Aufwand. Die beschriebene Idee macht sich aber zunutze, dass der gedankliche Aufwand, der beim Programmieren in die Beschreibung der Lösung investiert wird und den Hauptteil der Programmierzeit ausmacht, mit geringem Mehraufwand durch die Erstellung weniger Testzeilen ersetzt werden kann. Häufig führt die gedankliche Strukturierung im Vorfeld darüber hinaus zu höherer Codequalität.

Bei dem klassischen Testmanagement werden Tests parallel zur und unabhängig von der zu testenden Lösung entwickelt oder sogar nach ihr. Dies führt oft dazu, dass die gewünschte und erforderliche Test- und Anforderungsabdeckung nicht erzielt wird.

Hier hilft der strategische Umgang mit Anforderungen und verknüpften Testobjekten und die Auswertung der Anforderungsabdeckung vor dem Produktivgang einer neuen Lösung.

Bei der anforderungsgetriebenen Entwicklung ist es notwendig, dass die für den späteren Anwender der Lösung bzw. den Stakeholder relevanten Anforderungen (funktional und nicht-funktional) durch entsprechende Testfälle gemäß der aufgestellten Test-Strategie erfolgreich getestet und dokumentiert wurden. Als Auswertungsmöglichkeit kann dazu ein Anforderungsabdeckungs-Bericht eingesetzt werden.

Zur Verwendung des Anforderungsabdeckungs-Berichts ist es notwendig, die folgenden Objekte für die neue Lösung zu definieren:

• Anforderung: Beschreibt die funktionale und nicht-funktionale Anforderung des Stakeholders.
• Testfall: 1-n Testfälle müssen in der Anforderung verlinkt werden – die Testfälle stellen sicher, dass bei positiven Testergebnissen die Anforderung korrekt entwickelt wurde.
• Testplan: Die Testfälle müssen einem Testplan zugewiesen werden. Über den Testplan kann nach der Testausführung die Auswertung im Anforderungsabdeckungs-Bericht erfolgen.
• Testausführung beziehungsweise der Testnachweis: In der Testausführung bzw. dem Testnachweis wird dokumentiert, wann der Test konkret mit welchem Ergebnis durchgeführt wurde.

Insbesondere bei agilen Projekten spielt ein professionelles Testmanagement eine wichtige Rolle für den erfolgreichen Ablauf des gesamten Produktentwicklungsprozesses. So unterstützt der „Spezialist für das Testmanagement“ aktiv den Product Owner bei der erfolgreichen und wirtschaftlich sinnvollen Umsetzung einer qualitativ hochwertigen Lösung.

Dann werden aus zwei Abteilungen plötzlich eine, damit Schnittstellen reduziert und Synergieeffekte gehoben werden. Manchmal läuft die Gestaltung aber auch genau umgekehrt, damit jede dazugekommene Abteilung einen klareren Fokus hat. Im ersten Fall wird der Effekt eingesparter Führungspositionen sogar als früher Erfolg gesehen.

Auch die Schnittstellen zwischen Fachbereichen und IT ist bereichsübergreifend eine gern genommene Spielwiese für diese Art von Veränderungen. Aufgabenverlagerung von links nach rechts, zum Beispiel bei Testdurchführung oder Customizing, sollen Prozesse optimieren und beschleunigen.

Aber wie wahrscheinlich ist es, dass eine reine Organigramm-Kosmetik zu nachhaltigen Verbesserungen führt?

Nicht selten findet man nach einigen Jahren den Ausgangszustand wieder vor und spürbare Veränderungen oder Verbesserungen sind nicht erkennbar. Schlimmstenfalls hat sich sogar eine „informelle Organisation“ mit eigenen Aktivitäten und Prozessen entwickelt, die sich wie Wasser ihren Weg sucht, um das Tagesgeschäft so effizient wie möglich zu erledigen. Eins ist jedoch sicher: Das Vertrauen der Mitarbeiterinnen und Mitarbeiter schwindet zunehmend – die Kultur leidet, die Strategie verwässert, die Prozesse hinken.

Betrachtet werden bei dieser Art von beschriebenen Veränderungen maximal die Aufgaben und Kapazitäten. Oft endet diese Analyse bereits vor der Bewertung der Prozesse. Es reicht ja auch die Botschaft, dass die Prozesse dann in der neuen Struktur optimiert werden müssen. Vielleicht ist sogar die „informelle Ablauforganisation“ ein potenzieller Benchmark. Aber sich damit auseinandersetzen ist viel zu aufwändig, wenn die Lösung doch so einfach erscheint…

Damit sind wir aber genau bei den „blinden Flecken“. Denn in den seltensten Fällen liegt die Ursache für Schwierigkeiten oder Misserfolge tatsächlich an den Kästchen neuer Organigramme.

Daher sollte ein gezielter Blick auf weitere Bestandteile der Organisation eine Selbstverständlichkeit bei einer fundierten Diagnose sein. Neben der bereits erwähnten wichtigen Betrachtung der Prozesse mit ihren Schnittstellen, lohnt es sich genauer hinzusehen: zum Beispiel Rollen und Verantwortlichkeiten, Kommunikationsstrukturen oder Führungs- und Steuerungssysteme. Diese mit gezielten Fragen in eine gesamthafte Betrachtung zu integrieren ist aus unserer Erfahrung ein wichtiges Stück einer mehrdimensionalen Vorgehensweise.

Bestenfalls ergeben sich daraus weitere wichtige Ansatzpunkte, die weniger invasiv sind als Aufgaben und Menschen in neue Strukturen zu pressen, aber schnell Verbesserungen generieren.

Wie wir mit unserem Ansatz diese blinden Flecke frühzeitig identifizieren und mitbetrachten, erklären gerne unsere Expert*innen für Organisationsberatung in einem ersten Interview oder Workshop.

Während ich, im Anschluss an eine lange Lernphase, thematische Ablenkung gesucht habe, fiel mein Auge auf die Ausschreibung der Pentadoc. Schon beim Bewerbungsgespräch waren vor allem mein Studium und meine Interessen Thema, weniger das sonst typische Abfragen allgemeiner Qualifikationen. Außerdem hatte ich Raum über das Thema meiner abgeschlossenen Bachelorarbeit zu diskutieren. Nach dem Arbeitsantritt war ich von der schnellen und umfassenden Aufnahme überrascht: In mehreren Onboarding-Terminen nahmen sich die Mitglieder unseres Werkstudierendenteams, PentaNext, viel Zeit und führten mich geduldig in die Arbeitsweise und die Themenvielfalt ein. Gleich zu Beginn durfte ich schon Aufgaben übernehmen und trotz der kurzen Betriebszugehörigkeit zählte meine Meinung genauso viel wie die von allen anderen. Der Teamgedanke spielt im Scrum Framework, das bei uns Anwendung findet, eine zentrale Rolle. Dementsprechend konnte man sich auch bei Fragen zu seinem Studium stets auf Unterstützungen verlassen.

Trotz Homeoffice in der Corona Zeit immer ein Team im Rücken!

Bereits nach kurzer Einarbeitungszeit konnte ich die Berater*innen bei den Herausforderungen im Beratungsmandat unterstützen. Die Mitarbeit erstreckte sich von Recherche, über das grafische Aufbereiten von Daten bis zur Unterstützung bei der Erstellung eines neuen Beratungspaketes. Dabei wurde ich von Anfang an als vollwertiger Kollege angesehen und konnte im Zuge der Aufträge viele neue Fähigkeiten erlernen. Beim Präsentieren und Vermitteln meiner Erkenntnisse und Arbeitsergebnisse habe ich zum Beispiel einen großen Sprung nach vorn gemacht!

Die Wertschätzung, die einem bei der Pentadoc entgegengebracht wird, war auch an anderer Stelle klar sichtbar. So konnte ich als Werkstudent, wie alle anderen auch, freiwillig beim Quartalsmeeting teilnehmen. Bei diesem Treffen arbeiteten wir in Gruppen an Unternehmensprojekten und konnten uns mit allen Kollegen persönlich austauschen. Auch hier wurden wir bei allen Aktivitäten mit einbezogen und waren auf Augenhöhe mit dabei, egal ob bei Arbeitsthemen oder bei den anschließenden Abendaktivitäten.

Ich verließ die Pentadoc mit vielen neuen Fähigkeiten und gerade die praktischen Scrum-Kenntnisse wurden bereits gerne im Lebenslauf gesehen. Aber das Wichtigste war, das ich bei jeder Aufgabe den Rückhalt eines Teams gespürt habe, sowohl von den Werkstudierenden, als auch den Beraterinnen
und Beratern.