iftra "Service-Portal" - B2B-Lösung für Kunden

Eines unsere neuesten Projekte, welches unlängst in den Produktiveinsatz gegangen ist, ist das "Service Portal" für das Institut für Transparenz im Gesundheitswesen, kurz iftra. Dabei handelt es sich um ein B2B-Portal zur Datenverwaltung, welches wir gemeinsam mit der internen Entwicklungsabteilung des Kunden auf der Basis von Drupal 9 umgesetzt haben.

Was war die Ausgangssituation?

iftra betreibt unter anderem die Webseite „seniorenportal.de“. Bestimmte dort ausgegebene Daten, wie etwa Informationen zu Einrichtungen, deren Angebot sich an Senioren richtet, wie z.B. Pflegeeinrichtungen oder Einrichtungen für betreutes Wohnen, wurden bisher in einer individuell durch den Kunden selbst entwickelten Datenbank vorgehalten und verwaltet. Einrichtungen konnten sich in diesem Verzeichnis neu listen lassen und auf Anfrage hin ihre Daten ergänzen oder erweitern lassen.

Es existierte jedoch für dieses Einrichtungsverzeichnis bisher kein für Kunden oder Interessenten zugängliches Frontend, um dort Datensätze zu ihren Einrichtungen selbstständig pflegen oder statistische Auswertungen vornehmen zu können. Entsprechend mussten solche Änderungen immer zunächst durch die Kunden bei iftra "bestellt" werden.

Initial sollte auf der Basis von Drupal ein Frontend-System geschaffen werden, welches mittels API an die Datenbank-Eigenentwicklung angeschlossen wird und so eine Benutzeroberfläche bereitstellt, dass die Datenpflege auch Kunden möglich wird.

Was haben wir umgesetzt

Nachdem wir gemeinsam mit iftra mögliche Herangehensweisen an das Projekt eruiert hatten, wurde entgegen der ursprünglichen Planung die Entscheidung getroffen, die bisherige Datenbank-Eigenentwicklung aufzugeben und das komplette Datenmodell in Drupal neu abzubilden. Hinzu kam dann die Konzeption und Durchführung einer Datenmigration.

Was kann das System?

Eine Besonderheit des Datenmodells ist die mehrstufige hierarchische Strukturierung, in welcher sich die Datensätze der Pflegeeinrichtungen oftmals befinden. In der Regel gehört eine konkrete Pflegeeinrichtung zu einem Träger oder einer Kette mit mehreren Standorten, die ggf. ihrerseits übergeordnete Strukturen oder Verwaltungseinheiten angehören. Beispielsweise kann an oberster Stufe ein Bundesverband stehen, darunter mehrere Bezirksverbände, dann wiederum Kreisverbände, und dann die konkrete Einrichtung. Nicht immer gibt es für jede Ebene einen konkreten Ansprechpartner, der die jeweilige Ebene pflegt. Entsprechend musste eine Lösung umgesetzt werden, nach der sich Administrierungsrechte in der Hierarchie nach unten vererben, sodass z.B. der Verwalter auf Bezirksverbandsebene auch alle Kreisverbände und die darunter verorteten Einrichtungen administrieren kann. Abgebildet wurde dieses Datenmodell mit insgesamt vielen tausend Einrichtungen mithilfe von Gruppen und Taxonomien.

Einer Gruppe zugeordnete Nutzer können verschiedene Rolle besitzen. Die mächtigste Rolle ist hierbei der "Kunden-Admin". Dieser kann die jeweilige Gruppe und alle unter ihr hierarchisch angesiedelten Gruppen administrieren. Zudem kann er in diese Gruppen neue Nutzer einladen und ihnen die Rollen "Editor" und "Editor Plus" geben, oder auch vorhandene Nutzer im eigenen Gruppenumfeld blockieren. Editoren können nur auf ihrer jeweiligen Gruppen-Hierarchieebene den Inhalt der zugehörigen Einrichtung editieren und als "Draft" speichern, aber nicht publizieren. Dies erledigen können Nutzer, die mindestens die Rolle "Editor Plus" besitzen. Für den Veröffentlichungsprozess der Inhalte kommt das Drupal-Modul Workflow zum Einsatz.

Da es sich um ein B2B System handelt, war eine gute Benutzerführung wichtig, aber auf ein eigenes Design wurde aus Kostengründen zunächst kein Fokus gesetzt. Zum Einsatz kam daher auch für das Frontend das "Gin Theme".

Was war besonders?

Die Umsetzung des Projekts erfolgte gemeinsam mit der internen Entwicklungsabteilung des Kunden, welche bis dahin die selbst entwickelte Einrichtungsdatenbank konzeptioniert, umgesetzt und weiterentwickelt hatte.

Dies war insofern besonders, dass der zuständige Entwickler zwar mit dem geballten Prozesswissen des Kunden und Kenntnissen über die verwendeten Datenmodelle ins Team kam, aber mit Drupal selbst noch keine Erfahrungen hatte - sich diese aber unbedingt aneignen wollte. Beim erdfisch-Team war es genau umgekehrt. Das versetzte uns in die einmalige Situation, dass

• das gemischte Entwickler-Team aus Kunden-DEV und erdfisch-DEVs  sehr effizient das neue Datenmodell und eine Datenmigration konzipieren konnte
• während der Implementierungsphase der Kunden-DEV durch beständigen Wissenstransfer und gemeinsames Hands-On oder Pair-Programming zunehmend befähigt wurde, selbst Aufgaben innerhalb der Drupal-Entwicklung zu planen und durchzuführen, sodass
• gewissermaßen als Begleiteffekt des Projekts nun auch signifikante Inhouse-Kompetenzen auf Seiten des Kunden in Bezug auf den eigenverantwortlichen Betrieb und die Weiterentwicklung des neuen Drupal-Projekts aufgebaut werden konnten.