Prozesszeichnungen

Datenstruktur Gridware mit ERP Next - ER Modell + Use Cases

drawing-11-1771238007.png

RULES: 

Wer erhält Rechnung: Contractor = Customer (Organisation oder Individuum) /Vertragskunde oder Ad-Hoc-Endkunde
Wer bekommt eine Gutschrift/Auszahlung? = Supplier (CPO) oder Customer (bei Dienstwagen) 
Wer nutzt nur? = End User (muss oft nur für Zuordnung/Reporting existieren)

Geldströme: 

A) Einnahmen (Money-In)

  1. Endkunde / Vertragspartner zahlt für Ladevorgänge
    • via Invoice/SEPA, oder Direct Payment (Payter/Stripe/PayPal), oder Pay-as-you-go
  2. Contract Giver zahlt für Ladepunkte/Service (Miete/Betrieb/Backend/Hardware)

B) Ausgaben (Money-Out)

  1. becharged zahlt Gutschrift an den Contract Giver
    • typischerweise “Energieumsatz / Standortanteil” (Pass-through)
  2. Optional: becharged zahlt Erstattungen 

C) Marge

becharged verdient in der Regel nicht am “reinen Durchlauf” (Energie), sondern an:

Wichtig für ERP: sauber trennen
- Pass-through (durchlaufender Posten → Auszahlung später)
- Eigener Umsatz (Fee)

USE CASES :

USE CASE 1: Laden im Unternehmen/beim Mandanten (Mitarbeiter/Vertragskunde) - Contract "Usage Contract (billable)"

BEISPIEL Unternehmen: https://cloud.becharged.de/backoffice/contracts/251 
BEISPIEL Kunde: 
BEISPIEL Wohngesellschaft/Vermieter: https://cloud.becharged.de/backoffice/contracts/306 

drawing-11-1770797781.png

 

drawing-11-1773221761.png

USE CASE 2: Laden im Unternehmen/beim Mandanten (Besucher/E-Fahrer) - Public Charging - Contract: "Adhoc usage contract"

BEISPIEL: https://cloud.becharged.de/backoffice/contracts/286 

drawing-11-1770793527.png

Use Case 3: Laden im Unternehmen/Kunde (Besucher/E-Fahrer) - Roaming über Hubject EMP-Vertrag
BEISPIEL: ? 

drawing-11-1770793425.png

USE CASE 4: Dienstwagen
BEISPIEL: https://cloud.becharged.de/backoffice/contracts/484 

drawing-11-1770793399.png

TRANSLATE: 

RULES:

Who receives the invoice: Contractor = Customer (organization or individual) / contract customer or ad-hoc end customer
Who receives a credit note / payout: Supplier (CPO) or Customer (in the company car use case)
Who only uses the service: End User (often only needs to exist for assignment/reporting)

Money flows:

A) Revenue (Money-In)

B) Expenses (Money-Out)

C) Margin
BeCharged typically does not earn on the “pure pass-through” (energy), but on:

Important for ERP: separate clearly

USE CASES:

USE CASE 1: Charging at the company / at the client (employee / contract customer) — Contract “Usage Contract (billable)”

Example company: https://cloud.becharged.de/backoffice/contracts/251
Example customer:
Example housing association/landlord: https://cloud.becharged.de/backoffice/contracts/306

drawing-8-1770201371.png

Datastructure Gridware to ERP Next - ER Modell + Use Cases ENG

Old version: 

drawing-11-1773694469.png

New Version 

drawing-11-1782823226.png

drawing-11-1782823144.png

RULES:

Who receives the invoice:
Contractor = Customer (organization or individual) / contractual customer or ad-hoc end customer

Who receives a credit note / payout:
Supplier (CPO) or Customer (in the company car use case)

Who only uses the service:
End User (often exists only for assignment/reporting purposes)

MONEY FLOWS: 

A) Revenue (Money-In)

- End customer / contractual partner pays for charging sessions
via Invoice/SEPA, or Direct Payment (Payter / Stripe / PayPal), or Pay-as-you-go

- Contract Giver pays for charging infrastructure / services
(e.g., rent / operations / backend / hardware)

B) Expenses (Money-Out)

- becharged pays a credit note / payout to the Contract Giver

- Typically: energy revenue / location share (pass-through)

- Optional: becharged pays reimbursements

C) Margin

becharged typically does not earn on pure pass-through energy revenue, but rather on:

- Service / platform fees
Example: M100035 – Operations management fee 10%

- Subscription payments
Example: Charge & Share

- Charging hardware operation fees
Example: M100213 – Operation of charging infrastructure

Important for ERP: clearly separate

USE CASES

USE CASE 1: Charging at a company / tenant location
(Employee / contractual customer)

Contract type: “Usage Contract (billable)”

example Company: https://cloud.becharged.de/backoffice/contracts/251 
example Kunde: 
example landlord: https://cloud.becharged.de/backoffice/contracts/306 

drawing-11-1782821742.png

USE CASE 2: Charging at Company/Mandate (Visitors, E-car drivers) - Public Charging - Contract: "Adhoc usage contract"

Example: https://cloud.becharged.de/backoffice/contracts/286 

drawing-11-1782822409.png

Use Case 3:Charging at Company/Mandate (Besucher/E-Car Driver) - Roaming via Hubject EMP-Contract
example: ? 

drawing-11-1782822005.png

USE CASE 4: Company Car - Employee receives charging box at his home, charges at home - supplies with electricity, company pays for electricty 
Example: https://cloud.becharged.de/backoffice/contracts/484 

drawing-11-1782822074.png

Data Mapping Gridware to ERP Next

Mapping to Party Master DocType for Master Data 

Organisation

Gridware field

API

Ziel-Doctype

Ziel-Feld in ERPNext

Bemerkung

id (Organization ID)

/services/organizations

Master Party

gridware_organization_id

Eindeutige Org-ID

id (Organization ID)

/services/organizations

Master Party

gridware_subject_id

Normalisierte Haupt-ID

“ORGANIZATION" set by API URL

/services/organizations

Master Party

gridware_subject_type

Für einheitliche Importlogik

name

/services/organizations

Master Party

organization_name

Official Name

name

/services/organizations

Master Party

display_name

Display Name

type

/services/organizations

Master Party

is_customer / is_supplier

CUSTOMER → is_customer = 1, is_supplier = 0

SUPPLIER → is_customer = 0, is_supplier = 1

BOTH → is_customer = 1, is_supplier = 1

customerNumber

/services/organizations

Master Party

gridware_customer_number

Falls vorhanden

supplierNumber

/services/organizations

Master Party

gridware_supplier_number

Falls vorhanden

API Payload

/services/organizations

Master Party

raw_payload

Für Debugging/Sync

Import Datetime

/services/organizations

Master Party

last_imported_at

Systemseitig setzen
Person:

Gridware Feld

API

Ziel-Doctype

Ziel-Feld in ERPNext

Bemerkung

ID (Person ID)

/services/persons/export

Master Party

gridware_person_id

Eindeutige Personen-ID

ID (Person ID)

/services/persons/export

Master Party

gridware_subject_id

Normalisierte Haupt-ID

"PERSON" set by API URL

/services/persons/export

Master Party

gridware_subject_type

Für einheitliche Importlogik

Firstname

/services/persons/export

Master Party

first_name

Vorname

Lastname

/services/persons/export

Master Party

last_name

Nachname

Firstname + Lastname

/services/persons/export

Master Party

display_name

Zusammengesetzter Anzeigename

Account.email

/services/persons/export

Master Party

email

Haupt-E-Mail

API Payload komplett

/services/persons/export

Master Party

raw_payload

Für Debugging/Sync

Import-Zeitpunkt

/services/persons/export

Master Party

last_imported_at

Systemseitig setzen
Adress for Organisation or Person

Gridware Feld

API

Ziel-Doctype

Ziel-Feld in ERPNext

Bemerkung

ID (Address)

/services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

external_address_id

Externe Address-ID

Address Type

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

address_type

Postal / Billing / Invoice

Street

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

street

Straße

Streetno

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

street_no

Hausnummer

zipCode

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

zip_code

PLZ

City

/services/addresses/for-organization/{organizationId}/{services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}}

Master Party Address

city

Ort

Country

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

country

Map on ERPNext Country

Telephone

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

telephone

Telefon

Email

services/addresses/for-organization/{organizationId}/{addressType} OR /services/addresses/for-person/{personId}

Master Party Address

email

Falls auf Address-Level vorhanden

Primary Flag

?

Master Party Address

is_primary

Falls Gridware so etwas liefert

erzeugter ERPNext Address Datensatz

Link

Master Party Address

erpnext_address

Optional nachgelagert
Payment Methode:

Gridware Feld

API adress

Ziel-Doctype

Ziel-Feld in ERPNext

Bemerkung

ID (Payment Method)

/services/payment-methods

Master Party Payment Method

external_payment_id

Haupt-ID

Type

/services/payment-methods

Master Party Payment Method

payment_type

z. B. SEPA / Direct Debit

Then: 

Gridware Feld

API adress

Ziel-Doctype

Ziel-Feld in ERPNext

Bemerkung

Iban

/services/payment-methods/ID

Master Party Payment Method

iban

Wichtig für Bankkonto

BankName

/services/payment-methods/ID

Master Party Payment Method

bank_name

Falls Detail-Endpoint das liefert

MandateID

/services/payment-methods/ID

Master Party Payment Method

mandate_id

Wichtig für SEPA Mandate

CreatedAt

/services/payment-methods/ID

Master Party Payment Method

created_at


erzeugtes ERPNext Bank Account

LINK

Master Party Payment Method

erpnext_bank_account

Optional nachgelagert

erzeugtes ERPNext SEPA Mandate

LINK

Master Party Payment Method

erpnext_sepa_mandate

Optional nachgelagert

New DocTypes: Gridware Contract, Gridware Usage

Gridware Contract: 

drawing-11-1776162063.png

Gridware Usage: 

drawing-11-1777469548.png

Arbeitspaket Vorbereitung: Contracts & Batches

drawing-11-1777371127.png

 

 

Contract Types via Contract API:

USAGE_HUBJECT_CPO_ROAMING

USAGE_POSTPAID

USAGE_POSTPAID CC (Company Car)

    * Speciality: 0% VAT 
    * Supplier is the employee that drives the company car, customer is company that pays for electricity, Elsewise same handling as normal Usage_postpaid 

BillingPeriod THONTHLY,.png

AUTHORIZATION

Screenshot 2026-05-07 at 12.14.16.png

USAGE_ADHOC

Screenshot 2026-05-07 at 12.14.50.png

EMP_USAGE_INTERNAL

PantractTya!. EMp USAGE INTERNAL.png

 

MVP Kundenportal

drawing-11-1779793410.png

 

MVP-Konzept: Kundenportal auf Basis von ERPNext für Dienstwagen & Ladestationen

Ziel des MVP

Ziel ist die Entwicklung eines Kundenportals auf Basis des bestehenden ERPNext-Ticketsystems, um aktuell manuelle Prozesse rund um Dienstwagen und Ladestationen zu digitalisieren und zu automatisieren.

Der Fokus des MVP liegt darauf:

Zusammenfassung der aktuellen Prozesse

Prozess 1: Dienstwagenanlage

Aktueller Prozess

  1. Der Fuhrparkmanager meldet sich bzw. kontaktiert BeCharged.

  2. Eine PDF mit den relevanten Informationen wird an Matthias geschickt.

  3. Matthias überträgt die Informationen manuell aus der PDF in Gridware.

  4. Die Daten werden dort über ein bestehendes Webformular eingepflegt.

  5. Erst danach wird der Kundendatensatz in Gridware angelegt.

Probleme im aktuellen Prozess

Zielprozess (Soll-Prozess)

  1. Der Fuhrparkmanager meldet sich im ERPNext-Kundenportal an.

  2. Das Formular „Dienstwagen“ wird direkt online ausgefüllt.

  3. Die Daten werden automatisiert in ERPNext gespeichert.

  4. Automatisch wird ein Kundendatensatz erstellt.

  5. Die Daten werden anschließend automatisiert nach Gridware übertragen.

  6. Gridware wird dadurch zum nachgelagerten System.

Prozess 2: Anlage & Pflege von Ladestationen

Aktueller Prozess

  1. Ein Angebot wird an den Kunden verschickt.

  2. Gemeinsam mit dem Angebot wird eine PDF zur Datenerfassung versendet.

  3. Der Betreiber der Ladestation füllt die PDF aus.

  4. Die Informationen werden manuell in ERPNext übertragen.

  5. Anschließend wird ein Auftrag erstellt.

  6. Danach werden die Daten zusätzlich in Gridware angelegt.

  7. Anschließend wird ein Starter-Kit (SIM-Karten, Ladekarten, Sticker etc.) an den Kunden versendet.

Probleme im aktuellen Prozess

Zielprozess (Soll-Prozess)

  1. Der Kunde erhält Zugriff auf ein digitales Formular im ERPNext-Portal.

  2. Die bisherige PDF wird vollständig durch ein Webformular ersetzt.

  3. Der Kunde trägt alle relevanten Daten direkt online ein.

  4. Die Daten werden automatisiert in ERPNext gespeichert.

  5. Auf Basis der Daten können direkt Angebot und Auftrag erstellt werden.

  6. Die relevanten Informationen werden automatisiert nach Gridware übertragen.

  7. Anschließend wird automatisiert bzw. operativ das Starter-Kit versendet.

Ergänzende Erkenntnisse aus Audioanalyse (Teil 1)

Wichtige fachliche Erkenntnisse

1. ERPNext soll zum führenden System werden

Aus der Audio wird deutlich, dass aktuell viele Stammdaten erst verspätet oder indirekt entstehen. Zielbild ist eindeutig:

Besonders wichtig:

Aktuell entstehen wichtige Stammdaten oft erst im Angebot- oder Auftragsprozess. Dies führt zu redundanten Schritten und Medienbrüchen.

2. Kundenportal als zentraler Einstiegspunkt

Das bestehende Kundenportal soll erweitert werden.

Neue Anforderungen:

Zusätzliche Perspektive:

Langfristig ist eine Single-Sign-On-Logik zwischen Gridware und ERPNext angedacht.

3. Ticketsystem-Integration ist strategisch wichtig

Die Lösung soll nicht nur Formulare abbilden, sondern eng mit dem bestehenden Ticketsystem verknüpft werden.

Dadurch sollen:

Wichtige Erkenntnis:

Die Formulare sind nicht isolierte Eingabemasken, sondern sollen direkt mit Ticket-Workflows verbunden werden.

4. Dienstwagen-Prozess: Erweiterte Anforderungen

Zusätzliche Erkenntnisse

Neue MVP-Anforderungen

5. Ladestationen-Prozess: Erweiterte Anforderungen

Wichtige Prozesslogik

Der Prozess startet aktuell meist über:

  1. Kontaktaufnahme

  2. Angebot

  3. PDF-Versand

  4. Rücksendung ausgefüllter Daten

  5. manuelle Übertragung

  6. Auftragserstellung

  7. Gridware-Anlage

  8. Versand Starter-Kit

Kritischer Pain Point

Die Datenerfassung passiert aktuell zu spät im Prozess.

Viele Informationen werden erst nach Angebot oder Auftrag eingeholt.

Dadurch entstehen:

Neue MVP-Anforderungen

6. Starter-Kit-Prozess muss berücksichtigt werden

Die Audio zeigt, dass der Versand des Starter-Kits operativ relevant ist.

Bestandteile des Starter-Kits

Neue Anforderungen

7. Formulare müssen dynamisch sein

Die Audio deutet darauf hin, dass unterschiedliche Varianten und Ausprägungen existieren.

Daraus ergeben sich folgende Anforderungen:

8. Datenqualität & Automatisierung sind Hauptziel

Das eigentliche strategische Ziel scheint nicht nur Digitalisierung zu sein, sondern:

9. Potenzielle Rollen im MVP

Externe Rollen

Interne Rollen

10. Technische Architektur-Anforderungen

Integrationen

Zukünftige Optionen

11. Offene Fragen für die nächste Workshoprunde

Fachlich

Technisch

Übergeordneter MVP-Anforderungskatalog

1. Benutzer- & Portalmanagement

Muss-Anforderungen

Optional für spätere Phasen

2. Webformulare

Formular 1: Dienstwagen

Anforderungen

Mögliche Formularfelder

Formular 2: Ladestationen

Anforderungen

Mögliche Formularfelder

3. ERPNext Integration

Muss-Anforderungen

4. Gridware Integration

Muss-Anforderungen

Zielarchitektur

ERPNext wird führendes System.

Gridware wird ausschließlich mit relevanten Daten aus ERPNext versorgt.

5. Prozessautomatisierung

MVP-Automatisierungen

6. Ticket- & Statussystem

Anforderungen

Beispielstatus

7. Dokumentenmanagement

Anforderungen

8. Reporting & Administration

Anforderungen

Prozesszeichnungen

Prozess 1 – Dienstwagen

IST-Prozess

Fuhrparkmanager
        ↓
PDF wird an Matthias geschickt
        ↓
Matthias überträgt Daten manuell
        ↓
Manuelle Eingabe in Gridware
        ↓
Kundendatensatz entsteht in Gridware

SOLL-Prozess

Fuhrparkmanager loggt sich im Portal ein
        ↓
Webformular „Dienstwagen“ ausfüllen
        ↓
Daten werden in ERPNext gespeichert
        ↓
Automatische Kundendatensatz-Erstellung
        ↓
Automatische Synchronisation zu Gridware
        ↓
Vorgang abgeschlossen

Prozess 2 – Ladestationen

IST-Prozess

Angebot wird verschickt
        ↓
PDF zur Datenerfassung wird mitgeschickt
        ↓
Kunde füllt PDF aus
        ↓
Manuelle Übertragung in ERPNext
        ↓
Auftrag wird erstellt
        ↓
Daten werden zusätzlich in Gridware angelegt
        ↓
Starter-Kit wird versendet

SOLL-Prozess

Kunde erhält Zugriff auf Webformular
        ↓
Ladestationsdaten werden online eingegeben
        ↓
Daten werden in ERPNext gespeichert
        ↓
Automatische Erstellung von Angebot/Auftrag
        ↓
Automatische Synchronisation nach Gridware
        ↓
Starter-Kit Versandprozess startet
        ↓
Vorgang abgeschlossen

Empfehlung für die MVP-Umsetzung

Phase 1 – MVP

Fokus auf:

Phase 2 – Erweiterungen

Mögliche Erweiterungen:

Ergänzende Erkenntnisse aus Audioanalyse (Teil 2)

12. MVP soll bewusst als Demo-/Proof-of-Concept aufgebaut werden

Aus Teil 2 wird deutlich:

Der erste MVP dient primär dazu, intern zu demonstrieren, wie ERPNext, Kundenportal, Formulare und Automatisierung zusammenspielen können.

Das Ziel des ersten MVPs ist daher nicht Vollständigkeit, sondern:

Wichtige Erkenntnis:

Es reicht zunächst ein kleiner funktionaler Showcase.

13. Strategischer Fokus: Automatisierte Artikel- & SIM-Kartenlogik

Ein zentrales Problem im aktuellen Prozess ist die manuelle Zuordnung von:

Zielbild

Das System soll:

Beispiel:

Wenn ein Kunde einen bestimmten Wallbox-Typ auswählt, sollen automatisch:

bereitgestellt werden.

14. Kundenportal soll operative Fehler reduzieren

Die Audio macht deutlich, dass aktuell viele Fehler entstehen durch:

Das Portal soll diese Risiken eliminieren.

15. Dynamische Verknüpfung von Kundendaten

Wichtige neue Anforderung:

Wenn ein Kunde bereits existiert:

Das reduziert:

16. Formularlogik soll intelligent werden

Die Audio zeigt, dass Formulare nicht statisch gedacht sind.

Anforderungen

Formulare sollen abhängig von:

unterschiedliche Felder und Prozesse anzeigen.

Beispiele

17. QR-Code- & Link-Management ist ein zentraler Bestandteil

Die Audio zeigt einen bisher nicht erkannten wichtigen Prozess:

Aktueller Zustand

Zielzustand

QR-Codes und Aktivierungslinks sollen:

sein.

18. Inbetriebnahme-Prozess der Ladestationen

Ein wichtiger Teilprozess wurde deutlich:

Aktueller Prozess

  1. Starter-Kit wird verschickt

  2. Kunde erhält QR-Codes/Links

  3. Kunde aktiviert Wallbox/Ladepunkt

  4. Teilweise manuelle Eingaben notwendig

  5. Konfiguration wird aktiviert

Probleme

MVP-Ziel

19. Kundenportal soll perspektivisch Wissensplattform werden

Die Audio zeigt, dass aktuell viele Informationen intern als:

geführt werden.

Zielbild

Das Kundenportal soll perspektivisch:

Mögliche Inhalte

20. Portalstruktur / mögliche UX-Struktur

Die Audio deutet bereits eine sinnvolle Struktur an:

Beispielhafte Navigation

Dashboard

Dienstwagen

Ladestationen

Dokumente

Support / Tickets

21. ERPNext soll operative Intelligenz abbilden

Das Ziel ist nicht nur Datenspeicherung.

ERPNext soll operative Regeln kennen:

Damit entsteht:

22. MVP-Umsetzungsempfehlung (technisch)

Empfohlener MVP-Umfang

Phase 1

Phase 2

Phase 3

23. Kritische Erfolgsfaktoren

Fachlich

Technisch

Operativ

24. Wichtigste strategische Erkenntnis

Die Audio zeigt sehr deutlich:

Das eigentliche Ziel ist nicht nur ein Formularsystem.

Das Ziel ist:

ERPNext wird damit perspektivisch zum operativen Kernsystem.

Ergänzende Erkenntnisse aus Audioanalyse (Teil 3)

25. Das eigentliche Problem ist fehlende Zentralisierung

Teil 3 macht sehr deutlich:

Das Kernproblem ist inzwischen weniger die reine Dateneingabe, sondern die fehlende Zentralisierung von:

Die Informationen liegen aktuell verteilt in:

Das erzeugt:

26. Kundenportal soll zentrale Informationsplattform werden

Die Audio bestätigt sehr klar:

Das Kundenportal soll perspektivisch zur zentralen Plattform für Kunden werden.

Kunden sollen dort zukünftig sehen können:

Dadurch entsteht:

27. Vertragsmanagement wird ein wichtiger zukünftiger Bestandteil

Aus der Audio ergibt sich:

Verträge spielen operativ eine deutlich größere Rolle als zunächst angenommen.

Aktuelle Probleme

Relevante Vertragsbestandteile

Neue Anforderungen

28. Ladepunktverwaltung wird ein zentrales Datenmodell

Die Audio zeigt:

Ladepunkte sind eines der wichtigsten Objekte im zukünftigen System.

Pro Ladepunkt relevant

Konsequenz

Die Ladepunktverwaltung sollte perspektivisch als eigenes zentrales Objektmodell aufgebaut werden.

29. ERPNext soll operative Übersicht schaffen

Ein großes Problem aktuell:

Mitarbeitende verlieren den Überblick.

Beispiele aus der Audio:

Zielbild

ERPNext/Kundenportal soll als zentrale Übersicht dienen.

30. Reduktion von Supportaufwand ist ein Kernziel

Die Audio macht deutlich:

Viele Supportanfragen entstehen nur, weil Informationen nicht zentral zugänglich sind.

Typische Probleme

Ziel

Self-Service statt manueller Support.

31. PDF-basierte Prozesse sind strategischer Engpass

Die PDFs sind aktuell:

Dadurch entstehen enorme operative Probleme.

Strategisches Ziel

Ablösung der PDFs durch:

32. MVP soll klein starten, aber skalierbar gedacht werden

Wichtige Erkenntnis:

Es besteht Einigkeit darüber:

MVP-Ziel

Nicht Perfektion.

Sondern:

33. Wichtige zukünftige Ausbaupotenziale

Die Audio deutet viele spätere Ausbaustufen an.

Mögliche Erweiterungen

34. Zukünftige Systemrollen

Kundenrollen

Interne Rollen

35. MVP-Demo soll visuell überzeugen

Die Audio zeigt:

Der MVP dient auch als visuelles Kommunikationsmittel.

Wichtig ist daher:

Die Demo muss zeigen:

„So könnte eure zukünftige Arbeitsweise aussehen.“

36. Strategische Gesamtvision

Nach allen drei Audio-Teilen wird das eigentliche Zielbild deutlich:

Zielbild

Eine zentrale digitale Plattform für:

auf Basis von ERPNext.

37. Wichtigste Erkenntnis aus Teil 3

Das Projekt ist deutlich größer als:

„Wir bauen zwei Formulare.“

Tatsächlich geht es um:

Zielbild der zukünftigen Architektur

Kunde / Fuhrparkmanager / Ladestationsbetreiber
                    ↓
            ERPNext Kundenportal
                    ↓
             Digitale Webformulare
                    ↓
                 ERPNext
     (führendes System / zentrale Datenbasis)
                    ↓
       Automatisierte Synchronisation
                    ↓
                 Gridware

Erwarteter Mehrwert

Operativer Mehrwert

Geschäftlicher Mehrwert

Kundenportal für die EGT

drawing-11-1782119054.png

drawing-11-1782134567.png

Ladekarten-Bestellungen im Kundenportal

drawing-11-1785228901.png

Ticket: "reimbursement"

drawing-11-1786720087.png

New Page

drawing-11-1788877421.png