In diesem Blogpost zeigen wir euch, wie wir mit Unsicherheiten in einem Projekt umgehen und dass man auch unter erschwerten Umständen, wie sie gerade während einer Pandemie auftreten können, Produkte umsetzen kann.
Die Gebäudeversicherung Bern ist vor einiger Zeit mit folgender Problemstellung an uns herangetreten: Sie besitzt ein ausgeklügeltes System um zu bestimmen in welcher Form ihre Kundinnen ein Dokument (z.B. eine Rechnung) erhalten. Manche Dokumente sollen elektronisch übermittelt werden, andere auf dem Postweg und wieder andere gar als elektronische Rechnung. Abstrakt wird hier von Ausgabekanälen gesprochen. Beim Betrieb dieses Systems ist die Gebäudeversicherung teilweise im Dunkeln ob alle Dokumente an die richtigen Ausgabekanäle weitergeleitet wurden.
Ein Dokument wandert von der Erzeugung bis zu einem Ausgabekanal durch drei Teilsysteme:
- SAP erzeugt das Dokument
- Das Customer Communication Management System (CCM) bereitet das Dokument auf und leitet es an den entsprechenden Ausgabekanal weiter
- Der Ausgabekanal welcher das Dokument empfängt
Man möchte nun gerne ein Dokument auf dem Weg durch diese drei Teilsysteme verfolgen, diese Daten aggregieren und so ein Dashboard für den Betrieb erstellen, damit auf einen Blick klar wird ob alle Dokumente im richtigen Ausgabekanal gelandet sind.
Leichter gesagt als getan. Hauptschwierigkeiten, die sich bei diesem Vorhaben einstellen, sind technischer Natur und werfen vor allem zwei Fragen auf:
- Bieten diese Teilsysteme Schnittstellen, an denen die Daten abgegriffen werden könnten?
- Können Daten aus unterschiedlichen Quellen korreliert werden?
Stossen wir bei der Ausarbeitung einer Lösung auf solche Fragen, welche die Umsetzbarkeit und ökonomische Sinnhaftigkeit des Vorhabens gefährden, empfehlen wir unseren Kunden vorrangig die Entwicklung eines Prototypen.
Ein Prototyp dient als grundlegende Entscheidungshilfe und klärt Fragen zur Umsetzbarkeit. Ein solcher Prototyp hat also einzig und allein die Funktion des Wissenserwerbs.
Es wurde also entschieden: Ein Prototyp muss her! An der Entwicklung sind drei Firmen beteiligt. Das CCM-System wird von der Firma Ajila betreut, das SAP von der internen Informatikabteilung der Gebäudeversicherung Bern und re:thinc (wir, also) sollen den Effort koordinieren und eine Cockpit Komponente skizzieren, um Daten von den Systemen abzugreifen und zu korrelieren.
Kommunikation ja, Kontakt nein
Ein solches Vorhaben reibungslos über die Bühne zu bringen erfordert prägnante Kommunikation und eine reibungslose Zusammenarbeit. Um eine solche enge Zusammenarbeit zu erreichen, wurden vier Fokustage mit allen Beteiligten in einem gemeinsamen Workspace geplant. Und ja, bis dahin durfte man sich sogar noch treffen. Doch wie könnte es anders sein: Just im geplanten Zeitraum wurde der Lockdown verhängt und zwang uns, auf Alternativen umzusteigen. Nach einigem hin und her wurde entschieden, die geplante Workspace-Zusammenarbeit in Remote-Zusammenarbeit umzuwandeln und so den Prototypen zu entwickeln.
Ein Team, bestehend aus fünf Personen, die aus drei unterschiedlichen Firmen kommen und alle einen anderen Hintergrund und eine differenzierte Spezialisierung und Funktion haben sollen zusammen einen Prototypen bauen - das hört sich wie ein schwieriges Kuchenrezept mit zu vielen Bäckern an. Klare Aufgabenteilung und verständliches Vermitteln der Grundidee schien oberstes Gebot zu sein.
So einfach wie möglich - aber nicht einfacher
Der Umfang des Prototyps wurde festgelegt, der Fokus aus Gründen der Vereinfachung auf einen “Use Case” gelegt: Ein einzelnes Dokument soll auf seinem Weg vom SAP durch das ganze CCM hindurch, bis hin zu einem der Ausgabekanäle verfolgt werden können. Wenn es möglich ist die Datenpunkte eines einzelnen Dokuments in den verschiedenen Teilsystemen abzugreifen und die Punkte zu verbinden, haben wir unseren Beweis. Ist dies realisierbar, kann auf das Gesamtsystem geschlossen werden. Ganz im Sinne von Divide and Conquer.
Dank genau solcher Vereinfachungen kann ein Prototyp effizient erarbeitet werden. Dies bezieht sich indes auf die ganze Organisation und die Ausführung einer solchen Aufgabe. Man arbeitet in vollstem Bewusstsein, dass der produzierte Code lediglich dem Wissenserwerb dient und der Prototyp nicht ein komplett funktionierendes System darzustellen hat. Wichtig ist aber das Verständnis über die Form des zu bauenden Systems und der Konsens des bearbeitenden Teams über die angestrebte Architektur.
Um in regelmässigen Abständen Ziele zu stecken und den Workflow aufrechtzuerhalten wurden zwei Checkpoints pro Tag angelegt. Morgens wurden Arbeiten verteilt, Tagesziele besprochen und Abhängigkeiten zwischen den Teammitgliedern eruiert. Abends wurde rekapituliert, die erreichten Meilensteine kommuniziert, sowie die Ziele für den kommenden Tag gesetzt. Um zeitnah Input zu generieren und etwaige Abhängigkeiten schnell zu beseitigen, waren externe Personen, welche sich für den Prototyp interessierten zu den jeweiligen Checkpoint Sitzungen eingeladen. Diese wurden dann über Google Meets geführt. Allgemein war während der Fokustage das ganze Team in einem Google Meets Raum eingeloggt, um die Koordination und Beantwortung von Fragen zu vereinfachen.
Nach den vier Fokustagen konnten wir dank koordinierter Zusammenarbeit, kurzer Kommunikationswege und dem konstruktiven Mitwirken aller Beteiligten einen funktionierenden Prototypen vorweisen. Ein gutes Gefühl!
