Fulfillment, Logistik & Handel
Logistik ist eine Kette – die Software muss es auch sein
Für VL Blum ist der vollständige Entwurf einer Operations-Plattform entstanden: CRM, Angebote und Verträge, Sendungserfassung und Versandübersicht, Abrechnung, Kundenportal, Benachrichtigungen und Protokoll – als durchgängig gebaute Oberfläche auf einem ausgearbeiteten Systementwurf. Die Umsetzung des Backends ist der nächste Schritt.
- Auftraggeber
- VL Blum
- Projekt
- VL Blum System
- Branche
- Fulfillment, Logistik & Handel
- Art
- Operations-Plattform · Systementwurf & Oberfläche
254 Dateien in der Oberfläche
7 Schritte der Prozesskette
3 Kundensegmente nach Versandvolumen
Die Angaben auf dieser Seite sind am Quelltext der Oberfläche, am Systementwurf und an der öffentlich erreichbaren Website geprüft. Ein Backend ist im Projektstand nicht enthalten – das ist unten ausgewiesen.
Ausgangslage
Worum es geht
Ein Fulfillment-Dienstleister verkauft kein Produkt, sondern die Zusage, dass eine Kette zuverlässig funktioniert: Wareneingang, Bestand, Lagerung, Kommissionierung, Versand, Sendungsverfolgung, Retoure – und am Ende eine Abrechnung, die zu all dem passt.
Standardsoftware deckt meist einen Ausschnitt ab. Ein Lagersystem weiß nichts vom Angebot, das CRM nichts vom Versandstatus, die Abrechnung nichts von den tatsächlich erbrachten Leistungen. Die Lücken füllen Tabellenblätter und Zuruf.
Bevor eine Zeile Backend entsteht, muss deshalb feststehen, welche Vorgänge die Plattform führt, welche Zustände sie kennt und wer was sehen darf. Genau das war der Auftrag.
Was XINOO umgesetzt hat
- Den öffentlichen Auftritt mit der Prozesskette vom Wareneingang bis zur Retoure, Kundensegmenten nach Versandvolumen, Kundenübersicht, Neuigkeiten und Anfragestrecke.
- Die Betriebssicht als Oberfläche: CRM mit Kunden und Interessenten, Angebots- und Vertragsverwaltung, Sendungserfassung und Versandübersicht, Abrechnung, Auswertung und Protokoll.
- Das Kundenportal als Oberfläche: Übersicht, Vorgänge, Benachrichtigungen und Nachrichtenverlauf.
- Den Systementwurf darunter: Vorgänge, Zustände, Rollen und Abläufe – als Grundlage der anstehenden Backend-Umsetzung.
Vorgehen
Was vor der ersten Zeile Code stand
Die teuersten Fehler entstehen nicht beim Programmieren, sondern davor – wenn niemand geklärt hat, welche Vorgänge das System eigentlich abbilden soll.
Die Kette als Datenmodell
Ausgangspunkt war der Weg eines Auftrags: von der Anfrage über das Angebot und den Vertrag zur Sendung, zur Verfolgung und zur Abrechnung. Jeder Übergang wurde als Zustandswechsel beschrieben – daraus ergab sich, welche Daten es geben muss.
Nach Volumen sortieren, nicht nach Branche
Die Bestandsaufnahme ergab, dass Interessenten sich über ihr Versandvolumen einordnen, nicht über ihre Branche. Angebot und Tarifierung folgen dieser Gliederung.
Zwei Zugänge von Anfang an
Der Dienstleister braucht eine Betriebssicht, der Kunde eine Auskunftssicht. Beide wurden getrennt entworfen – ein Kundenportal, das nachträglich aus der Verwaltung herausgeschnitten wird, zeigt am Ende zu viel.
Nachweisbarkeit vor Funktion
In der Logistik ist die Frage „wer hat wann was geändert" keine Nebensache. Protokoll, Nachrichtenverlauf und Compliance-Übersicht sind deshalb Teil des Entwurfs und nicht ein späterer Zusatz.
Gestaltung
Die Handschrift des Kunden, nicht die der Agentur
Ablauf sichtbar machen
Die Prozesskette ist der gestalterische Kern – im öffentlichen Auftritt wie in der Anwendung. Sie ist als Abfolge dargestellt, nicht als Aufzählung: Die Reihenfolge ist die Aussage.
Nüchtern statt werblich
Logistik gewinnt über Verlässlichkeit. Der Auftritt bleibt sachlich: klare Typografie, ruhige Flächen, keine Effekte, die eine Genauigkeit vortäuschen, die nur der Betrieb einlösen kann.
Dichte für den Betrieb, Ruhe für den Kunden
Die Betriebssicht ist auf Dichte ausgelegt: Listen, Filter, Zustände auf einen Blick. Das Kundenportal zeigt dieselben Vorgänge in ruhiger, reduzierter Form.
Ein Bausteinsatz für die ganze Plattform
Tabellen, Formulare, Zustandsanzeigen und Benachrichtigungen stammen aus einem gemeinsamen Satz. Neue Bereiche entstehen dadurch ohne neuen Entwurf.
Architektur
Die Entscheidungen dahinter
Nicht der Funktionsumfang entscheidet, ob ein System trägt, sondern wie es geschnitten ist.
Der Ablauf gibt die Gliederung vor
Die Anwendung ist entlang der Prozesskette geschnitten, nicht entlang einer Menüstruktur. Ein neuer Schritt ordnet sich an einer bestehenden Stelle ein, statt eine weitere Kachel zu erzeugen.
Betrieb und Kundenportal getrennt entworfen
Beide Zugänge haben eigene Ansichten auf dieselben Vorgänge. Die Trennung ist im Entwurf angelegt und nicht eine Sichtbarkeitsregel, die man später vergisst.
Zustände statt Häkchen
Angebot, Vertrag, Sendung und Rechnung sind als Vorgänge mit definierten Zuständen und erlaubten Übergängen beschrieben. Das macht später Protokoll und Auswertung möglich, ohne sie nachrüsten zu müssen.
Oberfläche zuerst, Backend danach – bewusst
Der Entwurf wurde an einer vollständig gebauten Oberfläche durchgespielt, bevor Datenbank und Schnittstellen entstehen. Fehler im Ablauf fallen so auf, solange sie noch billig sind.
Systemaufbau
Von außen nach innen
Die Ebenen des Systems in der Reihenfolge, in der eine Anfrage sie durchläuft.
Interessenten und Kunden
Öffentlicher Auftritt mit Prozesskette, Leistungsbild, Kundensegmenten und Anfragestrecke.
Kundenportal
Übersicht über Vorgänge, Benachrichtigungen und Nachrichtenverlauf – als Oberfläche entworfen.
Betriebssicht
CRM, Angebote und Verträge, Sendungen, Abrechnung, Auswertung und Protokoll – als Oberfläche entworfen.
Systementwurf
Vorgänge, Zustände, Übergänge und Rollen – die Grundlage der anstehenden Umsetzung.
Backend
Datenhaltung und Schnittstellen. Dieser Schritt steht an und ist nicht Teil des geprüften Standes.
Funktionen
Was das System kann
Gruppiert nach Bereichen. Die Aufstellung ist die Antwort auf die Frage, wie groß das Vorhaben tatsächlich war.
Öffentlicher Auftritt
- Prozesskette vom Wareneingang bis zur Retoure
- Leistungsbild und Vergleich
- Gliederung nach Versandvolumen
- Kundenübersicht und Fallbeispiele
- Neuigkeiten und Fachbeiträge
- Bereich für Lagerflächen
- Stellenanzeigen und Bewerbung
- Anfragestrecke und Kontakt
Kundenbeziehung (Oberfläche)
- CRM mit Kunden und Interessenten
- Kundenprofil und Detailsicht
- Interessentenverwaltung
- Angebotsverwaltung
- Verträge
- Aktivitätsverlauf
Abwicklung und Abrechnung (Oberfläche)
- Sendungserfassung
- Versandübersicht und Sendungsdetail
- Lagerstruktur
- Abrechnung und Tarife
- Auswertung
- Abläufe und Automatisierung
Kundenportal (Oberfläche)
- Übersicht für den Kunden
- Benachrichtigungen
- Nachrichtenverlauf
- Vorgangsdetails
Nachvollziehbarkeit (Oberfläche)
- Protokoll der Vorgänge
- Ereignisprotokoll
- Nachrichtenprotokoll
- Compliance-Übersicht
- Vorlagen für den Mailversand
Technik
Womit es gebaut ist
Oberfläche
Entwurf
Öffentlicher Auftritt
Integration
Was angebunden ist – und was nicht
Der geprüfte Stand enthält keine Anbindung an Fremdsysteme: Die Oberfläche arbeitet mit hinterlegten Beispieldaten, ein Backend ist noch nicht umgesetzt. Der Entwurf sieht Anbindungen für Versanddienstleister und Abrechnung vor; sie sind beschrieben, aber nicht gebaut.
Sicherheit & Zugriff
Sicherheit ist Teil des Entwurfs
Wer Zugriffsrechte nachträglich einzieht, baut Ausnahmen. Wer sie vorher entwirft, baut eine Struktur.
Zugänge im Entwurf getrennt
Betriebssicht und Kundenportal sind als getrennte Zugänge entworfen, nicht als eine Oberfläche mit ausgeblendeten Bereichen. Diese Trennung ist die Voraussetzung dafür, dass die spätere Rechteprüfung im Backend eine klare Grenze hat.
Nachvollziehbarkeit von Anfang an vorgesehen
Protokoll, Ereignis- und Nachrichtenverlauf sind Teil des Entwurfs. Eine Nachvollziehbarkeit, die erst nachträglich eingezogen wird, kennt die Vorgeschichte nicht.
Keine Kundendaten im öffentlichen Auftritt
Der öffentliche Auftritt hält keine Bestands-, Auftrags- oder Sendungsdaten vor. Angefragt wird über eine Kontaktstrecke.
Was noch nicht geprüft werden kann
Anmeldung, Rechteprüfung, Eingabevalidierung und Datenhaltung entstehen mit dem Backend. Zum geprüften Stand liegen sie nicht vor – und werden hier deshalb auch nicht als vorhanden dargestellt.
Woran sich die Umsetzung orientiert
- Secure by Design – Zugangstrennung und Nachvollziehbarkeit sind im Entwurf angelegt, nicht als spätere Ergänzung geplant
- Datensparsamkeit – der öffentliche Auftritt hält keine operativen Daten vor
Diese Grundsätze beschreiben die Arbeitsweise. Sie sind keine Zertifizierung und werden hier auch nicht als solche dargestellt.
Stand
Was läuft, was noch nicht
Ein Projekt ist selten an einem Stichtag fertig. Der Stand steht hier, weil er zur Sache gehört.
Der öffentliche Auftritt ist umgesetzt und unter eigener Adresse erreichbar: Prozesskette, Leistungsbild, Kundensegmente, Kundenübersicht, Neuigkeiten und Anfragestrecke.
Die Oberfläche der Operations-Plattform ist durchgängig gebaut – CRM, Angebote, Verträge, Sendungen, Abrechnung, Kundenportal, Benachrichtigungen und Protokoll – und der Systementwurf dazu ausgearbeitet.
Die Oberfläche arbeitet im geprüften Stand mit hinterlegten Beispieldaten. Datenhaltung, Schnittstellen, Anmeldung und Rechteprüfung entstehen mit der anstehenden Backend-Umsetzung.
Anbindungen an Versanddienstleister und Abrechnung sind im Entwurf beschrieben und für die Umsetzung vorgesehen.
Öffentlich erreichbar unter vlblum.de (öffnet in neuem Tab).
Verwandte Themen
Weiterlesen
Ein vergleichbares Vorhaben?
Schildern Sie die Ausgangslage. Wir ordnen ein, welche Ebene zuerst dran ist und ob dafür ein Produkt, eine Integration oder eine Entwicklung das richtige Mittel ist.