Dieser Beitrag ist in Kooperation mit e-fellows.net entstanden und wurde im Ratgeber "Perspektiven für Informatiker 2018" veröffentlicht.

Das Thema Digitalisierung steht auch bei Fresenius ganz oben auf der Agenda. Unser Ziel ist es, mit zukunftsfähigen Produkten und Services die Lebensqualität der Patienten signifikant zu verbessern. Im Gesundheitsmarkt stehen wir hier besonderen Herausforderungen gegenüber, denn es gilt, hohe gesetzliche Auflagen zu erfüllen. Auch die Rahmenbedingungen haben sich unter anderem durch den demografischen Wandel und den medizinischen Fortschritt verändert, gleichzeitig sind die Ressourcen limitiert. Mit der Digitalisierung von Geschäftsprozessen begegnen wir diesen Herausforderungen, um langfristig die Wettbewerbsfähigkeit des Konzerns zu sichern. Ich arbeite im IT-Projektmanagement bei Fresenius Netcare, dem IT Service Provider der Fresenius-Gruppe. Zu unserem Angebot gehören Prozess- und Projektmanagement,
Dienstleistungen rund um Systeme und Infrastruktur, die Entwicklung von ITLösungen auf Basis von SAP-Technologie sowie von speziellen Softwarelösungen für die Bereiche Gesundheitswesen und Pharma. Mit unseren IT-Dienstleistungen gestalten und begleiten wir die digitale Transformation der Fresenius-Konzerngesellschaften. Gerade stecke ich mitten in einem komplexen Projekt: Wir entwickeln für eine der Konzerngesellschaften eine App für medizinische Fachkräfte, die Patienten im Pflegeheim oder zu Hause betreuen. Unser Ziel ist es, mithilfe der App die Arbeitsbedingungen der Fachkräfte zu verbessern, indem der administrative Aufwand verringert wird und dadurch mehr Zeit für die Arbeit mit den Patienten bleibt – und das nicht nur für die Mitarbeiter in Deutschland, sondern weltweit. Dadurch und über eine Steigerung der Qualität der therapierelevanten Patientendaten können wir eine noch bessere Versorgung der Patienten ermöglichen. Im Projekt übernehme ich die Rolle des Business Process Architect (BPA). Kern meiner Aufgabe ist es, die Digitalisierung der Geschäftsprozesse bei Fresenius an der Schlüsselposition zwischen Business und IT voranzutreiben.

Mithilfe der neuen App, die auf einem Tablet laufen wird, dokumentieren die medizinischen Fachkräfte in Zukunft ihre Arbeitsschritte und erfassen die Patientendaten unmittelbar und digital. Heute passiert das in zwei Schritten: Vor Ort versorgen die medizinischen Fachkräfte die  Patienten und halten die Daten auf Papier fest, zu Hause müssen sie diese Informationen dann zur Dokumentation ins System eingeben. Zukünftig wird dieser manuelle Arbeitsschritt durch einen digitalisierten Prozess abgelöst und die Dokumentation dadurch vereinfacht. Die App wird vier medizinische Therapiefelder abdecken, die ambulant versorgt werden können. Hinter einer Anwendung im Gesundheitswesen stecken jede Menge regulatorische Anforderungen. Unser Anspruch ist es, die App nicht nur zu validieren – wodurch sichergestellt ist, dass unter gleichen Bedingungen die gleichen Ergebnisse erzielt werden –, sondern sie wird unter strengen Auflagen als Medizinprodukt zertifiziert. Das heißt für meine Arbeit, dass ich abgesehen von den geschäftsrelevanten Vorgaben aus dem Business und den technischen Parametern der IT auch die regulatorischen Rahmenbedingungen kennen und berücksichtigen muss. Als technische Plattform, für die wir diese App entwickeln, nutzen wir Fiori und SAPUI5, eine Webtechnologie von SAP. Ein Container, eine Rumpf-Applikation, läuft auf dem Tablet und ermöglicht den Zugriff auf dessen Hardware, wie die integrierte Kamera, die zu Dokumentationszwecken genutzt wird. Wir haben uns für diese Variante entschieden, um die unterschiedlichen Arbeitsumfelder der medizinischen Fachkräfte nahtlos zu integrieren: Sie können die App morgens zu Hause an ihrem Rechner verwenden, unterwegs und beim Patienten steht die App per Tablet auch mobil zur Verfügung.

Bei der Projektinitiierung nutzen wir Design-Thinking-Methoden – wir stellen also die Anwender und ihren Blick auf die Dinge in den Mittelpunkt –, um nach dem Projekt eine Lösung zu haben, die wirklich dem User nutzt. Konkret haben wir zunächst Workshops mit medizinischen Fachkräften durchgeführt, um zu verstehen, wo die spezifischen Herausforderungen der täglichen Arbeit liegen. Typische Tools, die wir mit dem Design-Thinking-Ansatz nutzen, sind beispielsweise User Journeys und Personas. Wir haben aber auch Mitarbeiter bei ihrer Arbeit begleitet, um uns voll und ganz in sie hineinversetzen zu können. In dieser frühen Phase des Projekts prüfen wir auch, welche Softwareunterstützung bereits vorhanden ist und welche weiteren Rahmenbedingungen zu berücksichtigen sind – in diesem Fall zum Beispiel die unterschiedlichen gesetzlichen Bestimmungen der Länder oder die Abrechnungsmodalitäten der diversen Gesundheitssysteme. Auch diese Ebene muss bei der Planung berücksichtigt werden, um die passenden Schnittstellen anzulegen. Während dieses Projektabschnitts stehe ich permanent mit den Anwendern, aber auch mit den Entwicklern und den Auftraggebern in Kontakt.

Im Projektverlauf gestalte ich auch die Analysephase, in der die Lösung Schritt für Schritt detaillierter betrachtet wird. Ich nehme die Anforderungen und Wünsche der Kunden an das System auf und formuliere daraus Prozessbeschreibungen, sogenannte funktionale Spezifikationen. Dabei arbeiten wir End-to-End, stellen also sicher, dass wir alle zeitlich-logischen Teilprozesse berücksichtigen, die zur Erfüllung der Kundenanforderung notwendig sind. Ich plane Workshop-Formate, um gemeinsam mit Vertretern unseres Auftraggebers und den Usern die  Anforderungen an einen Prozess – zum Beispiel die Aufnahme der Patientendaten in das System – zu evaluieren. Während der Workshops bin ich für die Moderation verantwortlich und kläre alle relevanten Fragen hinsichtlich der späteren Funktionalität. Auch die Nachbereitung und Dokumentation der Workshop-Ergebnisse gehören zu meinen Aufgaben. Um möglichst früh ein konkretes Feedback zu den Funktionalitäten und der Handhabung zu erhalten, arbeiten wir auch in dieser Phase mit Design-Thinking-Methoden: Wir entwickeln Prototypen, die einen Ausblick auf das Screendesign erlauben. Diese Mockups zeigen, wie wir die gewünschten Anforderungen visuell umsetzen können, also beispielsweise, wo welcher Button sitzt und wie sich eine App auf der funktionalen Ebene verhalten kann. Das Look-and-feel der App wird bereits in dieser Projektphase für den Benutzer ersichtlich. Bei diesem Vorgehen ist es ganz normal, dass ich auf verschiedene Interessen stoße. Es kann vorkommen, dass sich die medizinischen Fachkräfte eine zusätzliche Funktionalität wünschen, die wir im Rahmen des eigentlich geplanten Projektumfangs nicht realisieren können. Der Kunde – also die Fresenius-Konzerngesellschaft – kommt auch mit Änderungswünschen auf uns zu. Aus der Entwicklung heißt es dann vielleicht, dass das nicht mit vertretbarem Aufwand umzusetzen sei. Meine Aufgabe ist es an dieser Stelle, die Realisierbarkeit der User-Wünsche zu bewerten und zwischen den Gesprächspartnern zu vermitteln. Häufig lassen sich Mittelwege finden, sodass alle mit der Lösung zufrieden sind.

Im Anschluss an die Prozessevaluation erfolgt die Dokumentation. Für die Erstellung der Prozessbeschreibungen, die häufig über 300 Seiten umfassen, ist es wichtig, den Überblick über das Ganze zu behalten. Wenn ich an einer Stelle etwas definiere, muss ich abschätzen, welche Konsequenzen das im weiteren Verlauf mit sich bringt und welche Verbindungen zwischen verschiedenen Prozessen bestehen. Die Dokumentation erfolgt – wie die gesamte Kommunikation im Projekt – auf Englisch. Das stellt besondere Anforderungen an alle Projektmitglieder, da kaum jemand im Team Muttersprachler ist, doch bisher haben wir diese Herausforderung immer gemeistert.

Die Anwendung selbst wird agil entwickelt. Das heißt, wir starten relativ schnell mit einigen Basisfunktionalitäten, die den kleinsten gemeinsamen Nenner definieren, das sogenannte Minimal Viable Product. Dann holen wir Feedback von Anwendern und Auftraggebern ein und können bis in späte Projektphasen neue oder veränderte Anforderungen integrieren. Wenn es zu Anforderungsänderungen im laufenden Projekt kommt, folgen wir im Rahmen eines Change Requests einer klaren Struktur: Ich nehme die Anforderung in die Projektdokumentation auf, dann  entscheidet ein Change Advisory Board auf höherer Projektebene, ob diese Änderung umgesetzt werden kann oder nicht und welche Konsequenzen dies auf die Timeline und das Budget hat. Die Entwicklung läuft ganz im Sinne von „start small, grow big“. Wir starten mit einem Pilotprojekt in einem Land und entwickeln ein Template, das später weltweit eingesetzt werden kann. Dadurch müssen wir das Rad nicht jedes Mal neu erfinden, sondern können, nach lokalen Anpassungen, sehr schnell in weiteren Ländern live gehen. Dieses iterative Vorgehen ermöglicht es uns, Erfahrungen aus dem laufenden Projekt direkt in den Entwicklungsprozess einzubeziehen. So entwickeln wir effizient – und zwar nur das, was für den Anwender am Ende wirklich von Nutzen ist.

Im Verlauf eines so komplexen Projekts prallen unterschiedliche Interessen aufeinander. Hier auf alle Anforderungen so einzugehen, dass sich alle berücksichtigt sehen und mit dem Ergebnis zufrieden sind, ist eine der größten Herausforderungen für mich. Eine weitere Herausforderung betrifft das klassische Spannungsdreieck des Projektmanagements, das sich aus Abhängigkeiten zwischen Zeit, Budget und Umfang zusammensetzt. Ich muss in einer festgelegten Zeit einen bestimmten Umfang abliefern, und das in einer definiert hohen Qualität. Schon eine kleine Veränderung kann dieses Gefüge durcheinanderbringen, dann passt eine Komponente nicht mehr. Das hat Konsequenzen für das Timing oder die Ausführlichkeit der Beschreibung. Gerade der Qualitätsaspekt ist für uns besonders relevant, denn bei unserer Arbeit steht am Ende
immer das Wohl des Patienten im Mittelpunkt. Bei solchen komplexen Zusammenhängen Fehler zu vermeiden, erfordert enge Zusammenarbeit, permanente Abstimmung und eine intensive Kommunikation. Vor fixen Abgabeterminen kann es im Projekt auch mal stressig werden, hier sind Flexibilität und ein hohes Maß an Motivation gefragt. Im Team arbeiten wir eng zusammen, und umso schöner ist es dann, wenn wir einen Teilschritt erfolgreich abgeschlossen haben.

Zurzeit sind wir rund 150 Mitglieder, das ändert sich aber im Verlauf des Projekts ständig. Eine der Konstanten ist unser Projektbüro in Bad Homburg, dem Standort der Fresenius-Konzernzentrale. Hier laufen alle Fäden zusammen, zum Beispiel von den Entwicklern aus aller Welt, aber auch von externen Partnern. Als BPA habe ich täglich mit Menschen aus unterschiedlichsten Kulturkreisen zu tun, das ist für mich einer der großen Pluspunkte an diesem Job. Dazu kommen die verschiedenen fachlichen Ausrichtungen: Die Auftraggeber aus der Fresenius-Konzerngesellschaft mit Healthcare-Hintergrund, die eigentlichen Anwender, häufig Krankenschwestern und Pflegekräfte, die Entwickler und die Projektmanager von Auftraggeberseite und von Fresenius Netcare. Diese Vielfalt macht den Job für mich extrem spannend.

Das Projekt bestimmt meinen Arbeitstag. In den verschiedenen Projektphasen stehen ganz unterschiedliche Arbeiten an: Während der Analysephase ist die Arbeit eher strukturiert, ich bin dann häufig in Workshops mit unterschiedlichen Projektgruppen und kann das ganz gut planen. Im weiteren Verlauf kann dann jeder Tag ganz anders sein, beispielsweise wenn ein Detail auffällt, das integriert werden muss. Ich mag die Abwechslung und die unterschiedliche Dynamik in den Projektphasen ebenso wie die enge Zusammenarbeit mit Auftraggebern, Anwendern und Entwicklern. Wenn das Projekt in die nächste Phase geht, freue ich schon darauf, wieder ganz neue Aufgaben zu übernehmen und zu sehen, wie die App weiter Form annimmt.