Pulse

Das Produkt

Pulse ist das ERP-System, das die Operations-Abteilung bei ecoligo GmbH in ihren täglichen Aktivitäten unterstützt, indem es zur einzigen verlässlichen Datenquelle (Single Source of Truth) wird.

Es bietet die Kernfunktionen, die benötigt werden, um Informationen über den gesamten Lebenszyklus der Solarenergieprojekte des Unternehmens zu erfassen, zu verwalten und zu archivieren. Diese Projekte werden von Teams in 13 Ländern in Südostasien (SEA), Lateinamerika (LATAM) und Subsahara-Afrika (SSA) entwickelt und betrieben.

Durch die Zentralisierung von Kunden- und Partnerdaten ermöglicht es konfigurierbare Geschäftsprozesse bei gleichzeitiger operativer Flexibilität und stellt sicher, dass Prozesse nachvollziehbar sind sowie internen und regulatorischen Anforderungen entsprechen.

Überblick

Ich war für den Wiederaufbau der ERP-Software (Enterprise Resource Planning) von Ecoligo auf Design- und Architekturebene verantwortlich, einschließlich Bereichen wie:

• Onboarding-Erlebnis (Nutzerregistrierung, Authentifizierung, Login, Logout)
• Offboarding-Erlebnis (Nutzer entfernen, Nutzer deaktivieren)
• Datenbankseiten zur Verwaltung des Solarbetriebs, einschließlich Kundenregister, Vertragsmanagement und Erfassung von Solarenergiemessungen
• Kundenrechnungsstellung basierend auf der Solarenergieerfassung
• EPC-Partnerregister, um eine interne Nutzerkonvertierung zu erreichen (d. h. die Nutzung externer Tools einzudämmen).

Das Geschäftsziel, das ich verfolgte, war die Zentralisierung aller Betriebsdaten in einem intern entwickelten Produkt, uum Ungenauigkeiten bei Finanzberechnungen, Konstruktionsspezifikationen usw. zu vermeiden.

Herausforderungen

Wo und wie anfangen? Die Antwort liegt immer bei den Nutzern. Ich habe einige der wichtigsten Probleme zusammengetragen, die Pulse pro Abteilung darstellte.

Plan

Die Abfolge der Schritte zur Neugestaltung von Pulse, die im weiteren Verlauf dieser Fallstudie ausführlich erläutert werden:

Recherche

Erkenntnisse

👉🏻 Abteilungen tauschten sich nicht untereinander aus, wenn es darum ging, ihre Prozesse zu teilen. Dies führte dazu, dass alle diese Abteilungen das frühere Produktteam baten, DB-Felder in Pulse zu implementieren, die letztlich identisch waren, jedoch in unterschiedlichen Tabellen und unter unterschiedlichen Namen. Das Ergebnis war viel Redundanz im System.

👉🏻 Implementierte Felder wurden meist als optional belassen. Selbst wenn sie also im System vorhanden waren, ließen manche Nutzer sie einfach leer.

👉🏻 Das Problem war nicht in erster Linie, dass das System keine Automatisierung bot, sondern dass die Prozesse abteilungsübergreifend nicht standardisiert waren, um überhaupt festzulegen, wie oder was automatisiert werden sollte.

👉🏻 Die Prozesse mussten zunächst innerhalb der Abteilungen standardisiert werden, um sie anschließend in der Implementierung von Pulse abzubilden.

👉🏻 Auf technischer Seite wurde empfohlen, Pulse tatsächlich neu aufzubauen, aufgrund all der Redundanzen in der Datenbank, die das Team entdeckte, sowie weil der Infrastrukturansatz aus ihrer Sicht nicht ideal war. Da dies auch die Endpoints betreffen würde, war der Konsens, dass ein Neuaufbau schneller wäre als eine Reparatur. Und so wechselten wir von einem Java-Monolithen zu einer Python-Microservice-Architektur.

Fazit

Die Rechercephase verschob den Projektfokus vom bloßen Neuaufbau einer UI für dasselbe Backend hin zur Lösung eines umfassenderen Verständnisproblems.

Anstatt die Screens rein kosmetisch zu gestalten, wurde die Herausforderung neu gerahmt und drehte sich um:

• Das Verständnis der von den Abteilungen entwickelten Prozesse, damit diese auf Produktebene umgesetzt werden konnten.

• Die Entwicklung eines leistungsstarken Produkts, das die von allen Abteilungen in verschiedenen Ländern erzeugte Datenlast vorausschauend berücksichtigt.

• Die Vereinfachung aller Designs, um den Nutzern zu helfen, ihre Aufgaben schneller zu erledigen – soweit es die von der Abteilung vorgegebenen Prozesse zuließen.

User Journeys

Die Erstellung dieser User Journeys auf Basis der Recherche half mir und dem Team zu verstehen, in welcher Reihenfolge die Features angegangen werden sollten, da wir dadurch die Ausgangspunkte jeder Phase und deren Anforderungen identifizieren konnten – sowie auch Punkte, die im ursprünglichen Pulse noch nicht einmal erfasst waren.

Data Flows

Ausgehend von den User Journeys erstellte ich eine übergeordnete Karte, die ich Data Flow nannte, mit allen erforderlichen Datenbankfeldern pro Service (entsprechend den Features), und stimmte diese iterativ mit dem Backend-Team ab, um mögliche Probleme frühzeitig zu erkennen. Dies bildete die Grundlage für die Datenbanken der Services. Nachfolgend ein Ausschnitt der Data Flows:

Design Ops

Das neue Design System, das für Pulse v2 erstellt wurde, folgte den WCAG-Standards, den Material-Design-/React-Standards und dem neuen Branding von ecoligo.

Es war in 4 Teile gegliedert: Assets, Styles, Components und Organisms (custom components). Hier ist ein kurzer Einblick in einige Assets, Styles und Components.

Designlösungen (nach Feature)

In diesem Abschnitt fasse ich die UX- und UI-Aspekte zusammen, die im Plan beschrieben wurden, und konzentriere mich ausschließlich auf die Features, die für die Entwicklung des gesamten Systems entscheidend waren: jene, die für alle anderen Abhängigkeiten benötigt wurden, die in sämtlichen Services bestehen würden.

Benutzerverwaltung

Für die Admin-Rolle wurden verschiedene Layouts vorgestellt, da nur Admins nutzerbezogene Aktionen durchführen konnten, wie das Hinzufügen von Nutzern zum System oder das Deaktivieren bzw. Löschen ihrer Konten.

• Variante A sollte die Anforderungen der Admin-Rolle abdecken. Sie zeigte eine Tabelle mit Möglichkeiten für Batch-Aktionen, um Nutzer zu deaktivieren, zu löschen oder zu bearbeiten.

• Variante B bot ein kartenbasiertes Layout, das Batch-Aktionen nicht erleichterte, dafür aber die menschliche Seite der Nutzer betonte, zum Beispiel durch ein größer dargestelltes Foto. Praktisch für Nutzer, die zum Beispiel wissen wollten, wer ihre Kolleginnen und Kollegen sind.

Am Ende setzte sich Variante A bei den Admins durch, das kartenbasierte Layout wurde jedoch ebenfalls in den Umfang der finalen Lösung aufgenommen, da es für die Nicht-Admin-Rollen als nützlich erachtet wurde (im Wesentlichen für alle anderen, die sich zum Beispiel mit Teammitgliedern aus anderen Regionen „vertraut machen" wollten).

Ich arbeitete mit dem Head of Region EUR zusammen, der für die Überwachung der Standardisierung der Prozesse in den übrigen Regionen verantwortlich war, in denen das Unternehmen tätig war, sowie mit dem Data Lead und dem Operations Lead, um die Rollen zu bestätigen, die bei der Erstellung des Systems jedem zugewiesen werden sollten.

Hier ist eine kurze Aufnahme des Prototyps für Admins, die den Wechsel zwischen den Ansichten sowie einen kleinen Einblick in das Filtererlebnis zeigt.

• Variante B wurde mit der ersten Version (MVP) von Pulse v2 veröffentlicht 🚀. Variante A wurde aufgrund von Produktpriorisierung zurückgestellt – das System hatte nicht genügend Nutzer, um Batch-Aktionen zu rechtfertigen.

• Wir erhielten gutes Feedback zum frischeren Look der Karten-Layout-Seite 😊. Beim Tabellen-Layout ist hervorzuheben, dass Admins es zwar nicht mit dem MVP veröffentlicht bekamen, es jedoch in den Nutzertests als weniger mühsam empfanden, nutzerbezogene Vorgänge auszuführen, und die Tabelle dank der Farbe in den Status-Chips sowie der Einführung runder Avatare als übersichtlicher wahrnahmen.

Länderverwaltung

Verpflichtende Inhaltsblöcke

Für den Aufbau des Layouts mussten verschiedene verpflichtende Inhaltsblöcke berücksichtigt werden.

Layout-Vorschläge

Vorbemerkung:
• Der Zugang zu diesem Screen befand sich unter „Einstellungen", da er Datenpunkte enthielt, die andere Services betrafen.
• Die Länder sollten in der ersten Iteration als Tabelle dargestellt werden; anschließend konnte der Nutzer auf jede Zeile klicken, um auf die länderspezifischen Informationen zuzugreifen.

• Variante A präsentierte eine Kartensammlung mit den verschiedenen Blöcken und legte mehr Gewicht auf den visuellen Aspekt einer Karte (Map), um das jeweilige Land zu verorten – in dem Bemühen, den Ansatz spielerischer zu gestalten.

• Variante B bot die Kartenansicht in Kombination mit einem vertikalen Tab-Layout, das die Blöcke voneinander isolierte, um sie einzeln durchzugehen.

• Variante C bot horizontale Tabs nach demselben Blockprinzip wie Variante B, zusammen mit dem Header, den auch die übrigen Datenbankseiten hatten.

Letztlich wurde für Variante B kein UI erstellt, da aus gestalterischer Sicht bereits absehbar war, dass sie nicht gut funktionieren würde.
Variante C erwies sich durch ihre Übersichtlichkeit und Ähnlichkeit zu anderen Seiten im System als visuell ansprechender. Die Blöcke in Variante A wurden als unübersichtlich empfunden, da die Nutzer keine klare Reihenfolge zum Lesen erkennen konnten.

Weitere Tabs

Es wurde entschieden, dass der Haupt-Tab den Grid Emission Factor des Landes anzeigen sollte, da sich dies als die nützlichste Information für die Mehrheit der Nutzer erwies.

Die übrigen Tabs hatten demnach eine geringere Bedeutung, gemessen an der Anzahl der Nutzer und der durchschnittlichen Anzahl an Abfragen.

• Der Tab Grid Utility Rate enthielt die Zusammenstellung aller vorhandenen Tarife nach Zone, Stadt oder Region, je nach Land. Da die Informationen zwischen den Ländern weder in Format noch Dateityp standardisiert waren (manche nutzten PDFs, andere Word-Dokumente, und im schlimmsten Fall handelte es sich um Screenshots von Excel-Dateien), mussten Sales-Nutzer alles manuell eingeben. Diese Informationen wurden anschließend in Verträge oder Rechnungen übertragen, während parallel an einer extraktionsbasierten Lösung gearbeitet werden konnte.

• Der Tab Allowed Contracts enthielt die Regeln dazu, welche Verträge im jeweiligen Land angeboten werden konnten. Aufgrund unterschiedlicher Gesetze oder Vorschriften waren nicht alle von uns modellierten Vertragstypen in bestimmten Fällen gültig. Hier konnten Nutzer mit der Rolle Head of Region auswählen, welche Vertragstypen unter Berücksichtigung dieser Vorschriften anzuwenden waren.

• Der Tab Taxes ermöglichte es Finance-Nutzern, die in jedem Land anwendbaren Steuern sowie deren Werte und das Datum der Anwendung/Gültigkeit festzulegen.

• Der Tab Exchange Rates wurde zum Schluss eingeführt, nachdem mit den Sales- und Finance-Teams vereinbart wurde, dass eine Wechselkursquelle (ER) im System standardisiert werden musste. Per Skript wurden die von der Europäischen Kommission veröffentlichten Wechselkurse synchronisiert, sodass Nutzer dieser Teams den Tab als Referenz verwenden konnten, anstatt direkt die Website der EU-Kommission zu durchsuchen.

Ich arbeitete mit dem Head of Region EUR zusammen, der für die Überwachung der Standardisierung der Prozesse in den übrigen Regionen verantwortlich war, in denen das Unternehmen tätig war, sowie mit dem Data Lead und dem Operations Lead, um sicherzustellen, dass sie über diese strukturellen Änderungen informiert waren und dadurch auch die Namenskonventionen und Nomenklaturen in ihren eigenen Systemen und Outputs einhalten konnten.

• Variante C wurde mit der ersten Version (MVP) von Pulse v2 veröffentlicht. 🚀

• Das Feedback nach dem Launch und der ersten Nutzung war sehr positiv. Nutzer hatten keine Schwierigkeiten zu verstehen, dass diese Datensätze das Rückgrat jedes operativen Outputs bildeten, den sie und ihre Teams möglicherweise erzeugen mussten. Alle waren froh, dass die Datenpunkte nicht mehr manuell pro Vertrag, Rechnung oder Angebot aktualisiert werden mussten.

Erkenntnisse