1) Zusammenfassung
| Firma | ecoligo GmbH |
| Produht | Enterprise Resource Planning (ERP) Web-App |
| Team | Operationenbereich → Produkt-Team |
| Rollen | Senior Produktdesignerin I; Produktleiterin |
| Umfang | UX, UI, Design-System; Produktspezifikationen |
| Tools | Figma, Figjam, Illustrator; Jira |
| Timeline | Sep 2024 - Dez 2025 |
| Übersicht | Ich war verantwortlich für die Neugestaltung des ERP-Systems von Ecoligo auf Design- und Architekturebene. Dazu gehörten die Konzeption und Umsetzung der Onboarding-Prozesse (Benutzerregistrierung, Authentifizierung, An- und Abmeldung), der Offboarding-Prozesse sowie der Verwaltungsoberflächen für den Betrieb der Solaranlagen.
Zu den zentralen Funktionen zählten die Kundenverwaltung, das Vertragsmanagement, die Erfassung und Nachverfolgung von Solarenergie-Messdaten, die darauf basierende Kundenabrechnung sowie die Verwaltung der EPC-Partner. Ziel war es, die Akzeptanz des internen ERP-Systems zu erhöhen und die Nutzung externer Werkzeuge weitgehend überflüssig zu machen, indem eine zentrale Plattform für das operative Management geschaffen wurde. |
2) Produkt- und Businesskontext
Produktübersicht
Pulse ist das ERP-System, für das die Produktabteilung verantwortlich ist. Es wurde entwickelt, um die Operations-Abteilung bei ihren täglichen Aufgaben bei ecoligo GmbH zu unterstützen. Das System stellt die zentralen Funktionen bereit, die für die Erfassung, Verwaltung und Archivierung von Informationen über die Solarenergieprojekte des Unternehmens während ihres gesamten Lebenszyklus erforderlich sind. Diese Projekte werden von Teams in 13 Ländern in Südostasien (SEA), Lateinamerika (LATAM) und Subsahara-Afrika (SSA) betreut.
Pulse dient als zentrale Informationsquelle („Single Source of Truth“) für die Unternehmensabläufe. Es bündelt Kunden- und Partnerdaten, unterstützt flexibel konfigurierbare Geschäftsprozesse und gewährleistet zugleich deren Nachvollziehbarkeit sowie die Einhaltung interner und regulatorischer Anforderungen.
Pulse wird unter Einhaltung der Datenschutz-Grundverordnung (DSGVO) der Europäischen Union entwickelt und betrieben.
Die Herausforderungen
Pulse (Version 1) wurde ursprünglich im Jahr 2018 von einer externen Softwareentwicklungsagentur entwickelt. Das System war als internes Werkzeug gedacht, mit dem Mitarbeitende verschiedener Abteilungen Informationen zu Solarprojekten erfassen konnten. Die zugrunde liegende Datenstruktur wies jedoch kaum Beziehungen zwischen den Datensätzen auf und war nicht auf Skalierbarkeit ausgelegt. Eine Strategie, die erfassten Daten über ihre reine Darstellung hinaus sinnvoll zu nutzen, existierte nicht.
Anders ausgedrückt: Das Unternehmen erhielt eine individuell angepasste Kombination aus Excel und Word – ein System, in dem Daten zwar erfasst werden konnten, das jedoch keine Grundlage für skalierbare Prozesse, Automatisierung oder weiterführende Auswertungen bot.
Das Anzeigen einer Liste von Solarprojekten konnte bis zu 10 Sekunden dauern, obwohl dies die zentrale Übersichtsseite war, die alle Nutzerinnen und Nutzer täglich aufriefen. Die Systemleistung war stark beeinträchtigt. Dieses Problem führte dazu, dass die Mitarbeitenden nach Alternativen zu Pulse v1 suchten, um ihre Daten zu erfassen und zu verwalten: MS Word und Excel wurden für die Erstellung und Verhandlung von Verträgen sowie für Berechnungen und Berichte zur Performance der Solaranlagen genutzt. Zusätzlich spielte Asana eine zentrale Rolle im Aufgabenmanagement.
Das Fehlen von Verknüpfungen zwischen verschiedenen Datenpunkten machte das System wenig nützlich und nicht skalierbar. Wie bereits erwähnt, wurde die ERP-Software hauptsächlich zur Datenerfassung entwickelt, ohne dass mit den gesammelten Informationen über eine ansprechende Darstellung in Dashboards hinaus weitere Funktionen genutzt werden konnten.
Es gab beispielsweise keine Verbindungen zwischen Finanzdaten, Verträgen und operativen Prozessen. Vereinfacht gesagt, war die Nutzung vergleichbar mit dem Erfassen von Informationen in einem Textdokument. Alle Änderungen mussten manuell durchgeführt werden. Auch dies beeinträchtigte erneut die Akzeptanz und Nutzung von Pulse v1.
Pulse v1 wurde so konzipiert, dass Nutzerinnen und Nutzer mehrere Rollen gleichzeitig haben konnten. Dies führte jedoch teilweise zu Konflikten mit den tatsächlich vorgesehenen Zugriffsrechten, insbesondere hinsichtlich der Daten, die sie einsehen oder bearbeiten durften.
Beispielsweise sollten einige Nutzerinnen und Nutzer lediglich Leserechte für Finanzinformationen besitzen. Da sie im System jedoch gleichzeitig als Administratoren hinterlegt waren, konnten sie sensible Daten verwalten und bearbeiten. Dieses Problem musste dringend behoben werden.
Pulse v1 wurde in Java mit einer monolithischen Architektur entwickelt. Laut dem neuen Engineering-Team, mit dem ich zusammenarbeitete, war dieser Ansatz nicht mehr optimal, da die Menge der gespeicherten Daten zu groß geworden war. Es fehlte an einer klaren Übersicht über Tabellen, Endpunkte und Systemstrukturen, wodurch Duplikationen unvermeidbar wurden.
Es gab beispielsweise verschiedene Endpunkte mit unterschiedlichen Bezeichnungen, die dieselbe Funktionalität erfüllten. Zudem existierten mehrere Tabellen, die Daten für denselben Service speicherten und dadurch Redundanzen erzeugten. Insgesamt befand sich das System in einem Zustand, der die Weiterentwicklung erschwerte. Dies führte dazu, dass das Team zögerte, beispielsweise Fehlerbehebungen durchzuführen. Eine verlässliche Dokumentation, auf die zurückgegriffen werden konnte? Fehlanzeige.
Dies stellte selbstverständlich eine große Herausforderung dar. Wir waren ein neu zusammengestelltes Team, das im dritten Quartal 2024 die Verantwortung übernahm, ein Produkt von Grund auf neu zu entwickeln – ohne vorhandene Dokumentation (entweder existierte diese nicht oder sie war stark veraltet).
Nachdem wir alle relevanten Punkte dem Management vorgestellt hatten, stimmte dieses unserem Ansatz zu: Wir sollten das neue Pulse (bezeichnet als Pulse v2) mit Python und React auf Basis einer Microservice-Architektur entwickeln.
Erfolgsmetriken
Für Q4 2024 haben wir folgende Ziele definiert:
• Erfolgreiche Migration der Datenbank von Pulse v1 zu Pulse v2.
• Veröffentlichung der Produktionsumgebung mit den fünf zentralen Microservices: Benutzer, Projekte, Kunden, EPC-Partner und Central (zur Sammlung externer Länderdaten beispielsweise). Selbstverständlich musste diese Veröffentlichung fehlerfrei erfolgen.
• Steigerung der Systemperformance: von Anfragen mit einer Dauer von bis zu 10 Sekunden auf maximal 0,2 Sekunden.
3) Discovery-Prozess und Recherche
Das Hauptziel dieser Phase war es, folgende Aspekte zu verstehen:
• Wer sind die wichtigsten Akteure innerhalb des Solar-Geschäftsprozesses?
• Welche Aufgaben übernehmen sie? Wie umfangreich ist ihr Verantwortungsbereich, ohne sich mit anderen Abteilungen zu überschneiden, und wie arbeiten sie miteinander zusammen?
• Welche Funktionen und Informationen erwarteten sie in der Benutzeroberfläche, um ihre täglichen operativen Aufgaben besser bewältigen zu können?
• Welche Geräte wurden in den einzelnen Phasen des Solar-Geschäftsprozesses genutzt?
Forschungsgrundlagen
| Quelle | Untersuchungsgegenstand | Wichtigste Erkenntnisse |
|---|---|---|
| Nutzerinterviews (15) | • Nutzer-Journeys • Spezifische Nutzerbedürfnisse |
• Jede Nutzergruppe hatte unterschiedliche Anforderungen, abhängig von ihrer Abteilung: •• Vertriebsmitarbeitende benötigten eine Möglichkeit, Verträge mit Kunden zu standardisieren, da die Vorgehensweise je nach Vertriebsmitarbeiter und Land, in dem der Vertrag abgeschlossen wurde, unterschiedlich war. Zudem benötigten sie eine Möglichkeit, Verträge für Nachverhandlungen wieder zu öffnen. All dies wurde bisher über MS Word und Asana abgewickelt. •• Nutzerinnen und Nutzer aus dem Bereich Solar Project Management benötigten eine Möglichkeit, technische Informationen zu den Solaranlagen zu erfassen: geografische Position mit Koordinaten, bebaute Flächen, verwendete Materialien, Bauart usw. Auch diese Informationen wurden bisher über MS Word und Asana verwaltet. •• Asset Manager benötigten eine Möglichkeit, Versicherungsinformationen zu verwalten, die mit den von den Solar Project Managern erfassten technischen Daten verknüpft sind. Außerdem fehlte eine Funktion zur Erfassung von Wartungsbesuchen (geplant und spontan) sowie eine Möglichkeit, die erzeugte Solarenergie mit den entsprechenden Anlagen zu verknüpfen, um Berichte für die Finanzabteilung zu erstellen. Diese Prozesse wurden bisher über MS Excel und Asana verwaltet. •• Nutzerinnen und Nutzer aus dem Finanzbereich benötigten eine Möglichkeit, die Rechnungsstellung auf Basis der Performance der Solaranlagen zu automatisieren. Der Rechnungsprozess wurde über ein externes Tool abgewickelt. • Generell gaben alle Nutzer an, dass die Zugriffsberechtigungen nicht korrekt verwaltet wurden (andere Abteilungen konnten relevante Daten ihrer eigenen Abteilung einsehen oder sogar bearbeiten). |
| Nutzer-Workshops pro Abteilung | • Teammitglieder zusammenbringen, um ein gemeinsames Verständnis zu schaffen |
• Die Abteilungen mussten ihre internen Prozesse neu bewerten und optimieren. • Erst danach konnten die entsprechenden Funktionen in Pulse umgesetzt werden. • Mit Unterstützung einer zentralen Prozessabteilung, die zunächst aufgebaut werden musste, konnte das Produktteam schneller Erkenntnisse darüber gewinnen, welche Funktionen umgesetzt werden sollten. |
Zentrale Erkenntnisse
• Da das vorherige Modell Nutzern mehrere Rollen gleichzeitig zuweisen konnte, entstanden Konflikte bei den Zugriffsrechten. Einige Nutzer sollten bestimmte sensible Informationen im System weder bearbeiten noch überhaupt einsehen können. Daher musste das neue Modell ein eindeutiges Berechtigungsmodell mit genau einer Rolle pro Nutzer vorsehen.
• Es war deutlich, dass jede befragte Abteilung sehr spezifische Anforderungen daran hatte, wofür die Daten genutzt werden sollten, wie sie dargestellt werden sollten usw. Wir haben diese Anforderungen einzeln erfasst, um zu visualisieren, wie verschiedene Datenpunkte zusammengeführt werden können. Ziel war es, einen durchgängigen Datenfluss zu schaffen, Redundanzen zu vermeiden und Abhängigkeiten zu identifizieren, um darauf basierend die Datenbanken zu erstellen.
• Das eigentliche Problem bestand daher nicht primär darin, dass das System keine Automatisierungsmöglichkeiten bot, sondern darin, dass die Prozesse innerhalb der Abteilungen nicht standardisiert waren, um tatsächlich dieselben Daten einheitlich zu erfassen. Dies führte dazu, dass unvollständige oder redundante Daten im System hinterlegt wurden (da die meisten Felder in den verschiedenen Formularen optional waren). Daher mussten zunächst die Prozesse standardisiert werden, bevor sie in Pulse implementiert werden konnten.
Aus der Forschung abgeleitete Designprinzipien
Basierend auf den Erkenntnissen haben wir folgende Prinzipien festgelegt, die als Leitlinien für die Neugestaltung dienten:
• Chunking: Da einige Prozesse innerhalb der Abteilungen sehr komplex waren, wurde gemeinsam mit den Stakeholdern entschieden, arbeitsorientierte Einzelschritte in die bestehenden Arbeitsweisen der Abteilungen zu integrieren. Für das Produktdesign bedeutete dies, komplexe Aufgaben in kleinere, überschaubare Schritte aufzuteilen, um die kognitive Belastung der Nutzerinnen und Nutzer zu reduzieren.
• Die Doherty-Schwelle konsequent umsetzen: Entwicklung eines schlanken und leistungsfähigen Backends, das Systemantworten innerhalb von 400 ms ermöglicht, um Nutzerfrustration und die Wahrnehmung eines langsamen Systems zu reduzieren.
• Ästhetik-Nutzbarkeits-Effekt: Entwicklung eines visuell konsistenten Produkts, das an der Unternehmensmarke ausgerichtet ist, ohne dabei Benutzerfreundlichkeit oder Barrierefreiheit zu beeinträchtigen.
Diese Prinzipien bildeten die Grundlage für die Bewertung von Konzepten und die Priorisierung von Lösungen während der Designphase.
Bedeutung dieser Forschung
Die Discovery-Phase verlagerte den Fokus des Projekts von der reinen Neugestaltung einer Benutzeroberfläche für dasselbe Backend hin zur Lösung eines umfassenderen Verständnissesproblems.
Anstatt die Oberflächen lediglich visuell neu zu gestalten, wurde die Herausforderung neu definiert und auf folgende Aspekte ausgerichtet:
• Verständnis der von den Abteilungen entwickelten Prozesse, damit diese auf Produktebene umgesetzt werden konnten. Dafür wurden neue Personas erstellt und die Nutzerreisen ausgearbeitet.
• Entwicklung eines leistungsstarken Produkts, das die durch alle Abteilungen in verschiedenen Ländern entstehende Datenmenge vorausschauend berücksichtigt.
• Vereinfachung aller Designs, um Nutzerinnen und Nutzern zu ermöglichen, ihre Aufgaben schneller zu erledigen – soweit dies durch die von den Abteilungen vorgegebenen Prozesse möglich war.
4) Designlösungen
In diesem Abschnitt werde ich auf die wichtigsten Funktionen eingehen, die umgesetzt wurden:
4.1) Nutzerverwaltung
• Nutzer hatten sich überschneidende Rollen, da mehrere Rollen gleichzeitig zugewiesen werden konnten. Dadurch verfügten einige Personen effektiv über Lese- und Bearbeitungsrechte für Informationen, auf die sie keinen Zugriff haben sollten.
Backend:
• Das Backend musste als eigenständiger Microservice neu entwickelt werden, um ein Ein-Rollen-Modell zu ermöglichen.
Design und Frontend:
• Keine Einschränkungen.
Für die Administratorrolle wurden verschiedene Layouts entworfen, da ausschließlich Administratoren benutzerbezogene Aktionen wie das Anlegen neuer Nutzerinnen und Nutzer sowie das Deaktivieren oder Löschen von Konten durchführen dürfen.
• Variante A wurde speziell auf die Anforderungen der Administratorrolle zugeschnitten. Sie zeigte eine Tabellenansicht mit Sammelaktionen zum Deaktivieren, Löschen oder Bearbeiten von Benutzerkonten.
• Variante B bot eine kartenbasierte Darstellung. Diese eignete sich zwar weniger für Sammelaktionen, legte jedoch einen stärkeren Fokus auf die Personen hinter den Konten, beispielsweise durch größere Profilbilder. Dadurch konnten Mitarbeitende ihre Kolleginnen und Kollegen – etwa aus anderen Regionen – leichter kennenlernen.
Letztlich bevorzugten die Administratoren Variante A. Die kartenbasierte Ansicht wurde dennoch in den Projektumfang aufgenommen, da sie sich insbesondere für Nicht-Administratorinnen und -Administratoren als nützlich erwies, um Teammitglieder aus anderen Regionen besser kennenzulernen.
Ich arbeitete eng mit der Head of Region (EUR) zusammen, die für die Standardisierung der Prozesse in den übrigen Regionen verantwortlich war, in denen das Unternehmen tätig ist. Darüber hinaus stimmte ich mich mit dem Data Lead und der Operations Lead ab, um die Rollen und Berechtigungen festzulsegen, die den einzelnen Nutzerinnen und Nutzern bei der Einführung des Systems zugewiesen werden sollten.
Hier ist eine kurze Aufzeichnung des Prototyps für Administratoren. Sie zeigt unter anderem den Wechsel zwischen den verschiedenen Ansichten sowie einen ersten Einblick in die Filterfunktionen.
• Variante B wurde mit der ersten Version (MVP) von Pulse v2 🚀 veröffentlicht. Die Umsetzung von Variante A wurde aufgrund der Priorisierung im Produkt-Backlog verschoben, da die Anzahl der Nutzerinnen und Nutzer zu diesem Zeitpunkt noch zu gering war, um Sammelaktionen zu rechtfertigen.
• Die kartenbasierte Ansicht erhielt positives Feedback für ihr modernes und frisches Erscheinungsbild 😊. Obwohl die Tabellenansicht nicht Teil des MVP war, zeigte sich während der Nutzertests, dass Administratoren Benutzeraktionen damit effizienter durchführen konnten. Zudem wurde die Tabelle dank der farbigen Status-Chips und der neu eingeführten runden Avatare als deutlich besser lesbar wahrgenommen.
4.2) Länderdatenverwaltung
• Nutzer erfassten dieselben länderspezifischen Informationen (z. B. Emissionsfaktoren des Stromnetzes, Mehrwertsteuer- und Quellensteuerwerte oder Vertragstypen, die in bestimmten Ländern rechtlich nicht zulässig waren) manuell an verschiedenen Stellen, etwa bei Ländern, Finanzberechnungen oder Projektspezifikationen. Dieser Prozess war aufwendig und erhöhte das Risiko von Datenfehlern. Ein zentraler Service (intern als „Country Service“ bezeichnet), über den all diese Informationen verfügbar gemacht werden konnten, war notwendig, um Automatisierung und Datenzuverlässigkeit zu gewährleisten.
Backend:
• Erstellung einer Reihe von API-Endpunkten, um den Country Service mit spezifischen Datenpunkten in anderen Services, wie beispielsweise Projekten und Rechnungen, zu verbinden.
Design und Frontend:
• Keine.
Verpflichtende Inhaltsblöcke
Für die Erstellung des Layouts mussten verschiedene verpflichtende Inhaltsblöcke berücksichtigt werden.
Layout-Vorschläge
Ausgangssituation:
• Der Zugriff auf diese Ansicht befand sich unter „Einstellungen“, da sie Datenpunkte enthielt, die andere Services beeinflussten.
• Die Länder wurden in der ersten Iteration als Tabelle dargestellt. Anschließend konnten Nutzerinnen und Nutzer auf die jeweilige Zeile klicken, um die spezifischen Informationen des Landes aufzurufen.
• Variante A präsentierte eine Sammlung von Karten mit den verschiedenen Inhaltsblöcken. Dabei wurde der visuelle Aspekt einer Karte stärker hervorgehoben, um das jeweilige Land leichter zu verorten und die Interaktion spielerischer zu gestalten.
• Variante B bot zusätzlich zur Kartenansicht ein vertikales Tab-Layout, bei dem die einzelnen Inhaltsblöcke voneinander getrennt waren und nacheinander betrachtet werden konnten.
• Variante C bot horizontale Tabs mit demselben Prinzip der Inhaltsblöcke wie Variante B sowie den Header, der auch auf den anderen Datenbankseiten verwendet wurde.
Letztendlich wurde für Variante B keine UI-Ausarbeitung erstellt, da aus Designperspektive absehbar war, dass diese Lösung nicht optimal funktionieren würde.
Variante C erwies sich aufgrund ihrer klaren Struktur, ihres aufgeräumten Erscheinungsbilds und ihrer Ähnlichkeit zu den anderen Seiten des Systems als die visuell überzeugendere Lösung. Die Inhaltsblöcke in Variante A wurden als weniger übersichtlich bewertet, da Nutzerinnen und Nutzer keine klare Reihenfolge oder Struktur erkennen konnten, in der sie die Informationen erfassen sollten.
Andere Tabs
Es wurde entschieden, dass der Haupt-Tab den Grid Emission Factor des jeweiligen Landes anzeigen sollte, da sich diese Information für die Mehrheit der Nutzerinnen und Nutzer als besonders relevant erwiesen hatte.
Die anderen Tabs wurden entsprechend ihrer geringeren Relevanz anhand der Anzahl der Nutzerinnen und Nutzer sowie der durchschnittlichen Anzahl an Zugriffen nachrangig behandelt.
• Der Tab Netzstromtarif enthielt eine Übersicht aller vorhandenen Tarife nach Zone, Stadt oder Region, abhängig vom jeweiligen Land. Da die Informationen zwischen den Ländern weder hinsichtlich Format noch Dateityp standardisiert waren (einige verwendeten PDFs, andere Word-Dokumente; im ungünstigsten Fall sogar Screenshots von Excel-Dateien), mussten Sales-Nutzerinnen und -Nutzer alle Daten manuell erfassen. Diese Informationen wurden später in Verträge oder Rechnungen übernommen, während gleichzeitig an einer Lösung zur automatisierten Datenextraktion gearbeitet werden konnte.
• Der Tab Erlaubte Verträge enthielt die Regeln dafür, welche Vertragstypen in einem bestimmten Land angeboten werden durften. Aufgrund unterschiedlicher gesetzlicher Vorgaben und regulatorischer Anforderungen waren nicht alle modellierten Vertragstypen in jedem Land zulässig. Nutzerinnen und Nutzer mit der Rolle Head of Region konnten hier festlegen, welche Vertragstypen unter Berücksichtigung dieser Vorgaben angewendet werden sollten.
• Der Tab Steuer ermöglichte es Nutzern aus dem Finanzbereich, die in den jeweiligen Ländern geltenden Steuern sowie deren Werte und Gültigkeits- bzw. Anwendungszeiträume zu definieren.
• Der Tab Wechselkurse wurde nachträglich eingeführt, nachdem gemeinsam mit den Sales- und Finance-Teams vereinbart worden war, dass eine einheitliche Quelle für Wechselkurse im System standardisiert werden sollte. Über ein Skript wurden die von der Europäischen Kommission veröffentlichten Wechselkurse synchronisiert. Anschließend konnten Nutzerinnen und Nutzer dieser Teams den Tab als Referenz verwenden, anstatt die Website der Europäischen Kommission direkt aufzurufen.
Ich arbeitete eng mit der Head of Region (EUR) zusammen, der für die Standardisierung der Prozesse in den übrigen Regionen verantwortlich war, in denen das Unternehmen tätig ist. Zudem stimmte ich mich mit dem Data Lead und der Operations Lead ab, um sicherzustellen, dass sie über diese strukturellen Änderungen informiert waren und die neuen Namenskonventionen und Bezeichnungen auch in ihren eigenen Systemen und Ausgaben übernehmen 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. Die Nutzer hatten keine Schwierigkeiten zu verstehen, dass diese Datensätze die Grundlage für alle operativen Ergebnisse bildeten, die sie und ihre Teams erstellen mussten. Besonders positiv wurde aufgenommen, dass die Datenpunkte nicht mehr manuell in Verträgen, Rechnungen oder Angeboten aktualisiert werden mussten.
5) Design-System
Ich habe das Design-System für Pulse von Grund auf neu entwickelt und dabei die Material-Design-Richtlinien für eine optimale Benutzerfreundlichkeit berücksichtigt. Dadurch wurde gleichzeitig die Umsetzung in React erleichtert. Alle Komponenten wurden zudem gemäß den WCAG-Anforderungen barrierefrei gestaltet. Mithilfe von Figma-Variablen habe ich Light- und Dark-Themes erstellt.
Das Design-System wurde in vier Bereiche strukturiert: Assets, Styles, Components und Organisms (benutzerdefinierte Komponenten).
Hier ist ein Einblick in einige der erstellten Assets, Styles und Komponenten.
6) Einfluss
Einfluss auf das Geschäft
Aus geschäftlicher Perspektive bestand der klare Mehrwert darin, dass die Daten durch die Einführung einer zentralen und verlässlichen Informationsquelle für alle im Unternehmen benötigten Ausgaben – den sogenannten „Backbone-Daten“ – vollständig vertrauenswürdig wurden.
Nur ausgewählte und geprüfte Datenquellen wurden zur Befüllung des Systems berücksichtigt, wodurch der Zugriff auf unzuverlässige oder inkonsistente Daten aus anderen Quellen verhindert wurde.
| Nutzung | Von 10 Nutzerinnen und Nutzern auf 92 von 95 (nahezu das gesamte Unternehmen) |
| System-Performance | Von ca. 10 Sekunden auf maximal 0,3 Sekunden |
Auch unsere ursprünglichen Erfolgskennzahlen wurden erreicht. ✔
Einfluss auf Nutzer
After the release, users were relieved of entering data that was repetitive by having a centralized repository of that information.
• With that, the task splitting and responsibilities were clear: who should update the backbone data points should not be the same person who is, for example, filling a contract
• Users could finally focus on their own tasks without having to manually update those data points, which implied desk research and time lost, or pasting information that might have not been updated.
7) Reflexion
Was ich gelernt habe
• Aus technischer Perspektive habe ich gelernt, dass gemeinsame Workshops und Abstimmungssitzungen mit dem Engineering-Team von Beginn an einen großen Mehrwert bieten. Dabei sollten auch Product Manager, Designer und Data Analysts einbezogen werden, um besser zu verstehen, wie eine Anwendung strukturiert werden muss, die sich kontinuierlich weiterentwickelt und zahlreiche Abhängigkeiten zwischen Datenpunkten aufweist. Die Erstellung eines übergreifenden Master-Datenflusses erwies sich als der beste Ansatz, um Transparenz für Backend-Entwickler, QA Engineers und gelegentlich auch Frontend-Entwickler zu schaffen.
• Aus der Perspektive des Stakeholder-Alignments habe ich gelernt und schätzen gelernt, dass ein kontinuierlicher, aber nicht übermäßiger Austausch über aktuelle Entwicklungen innerhalb der Abteilung von entscheidender Bedeutung ist. Dies gilt insbesondere dann, wenn sich Prozesse, Richtlinien oder rechtliche Rahmenbedingungen ändern, die direkte Auswirkungen auf unsere Entwicklung haben können. Die Zusammenarbeit mit dem Process Lead, dem Data Lead und dem Head of Region (EUR) hat mir einen umfassenden Einblick in diese verschiedenen Einflussfaktoren ermöglicht und gleichzeitig zu einem tieferen Verständnis der Anwendungsfälle in den einzelnen Regionen und anderen Abteilungen beigetragen.
Was ich verbessern würde
Wenn mehr Zeit zur Verfügung gestanden hätte, hätte ich folgende Themen priorisiert und umfassender bearbeitet:
• Die Funktionalität Projektspezifikationen, da diese auch für Solar Project Manager von großer Bedeutung war, um Änderungen an der Konstruktion der Solaranlagen nachzuverfolgen, die sich direkt auf die Kostenberechnungen auswirkten. Damit wäre das letzte fehlende Element für einen vollständigen Prozess innerhalb einer gesamten Abteilung geschaffen worden.
• Allgemein betrachtet hätte ich möglicherweise auch die Erweiterung des Engineering-Teams um eine DevOps-Position priorisiert. Aufgrund von Budgetbeschränkungen mussten wir auf externe Unterstützung zurückgreifen, um technische Herausforderungen zu lösen. Dies führte häufig zu teilweisen Unterbrechungen der Arbeit des Backend-Teams, während wir auf die Durchführung von Deployments und Änderungen warten mussten.
8) Weitere Screens
