top of page
Suche
AutorenbildRüdiger W. Schwarz

Wie wird Ihr WMS Pflichtenheft gut?

Prima, Sie haben ein neues Warehouse Management System (WMS) ausgewählt! Nun gilt es die Anforderungen durch den WMS Partner in seiner Lösung spezifizieren zu lassen. Das erfolgt klassisch in einem WMS-Pflichtenheft. Dabei sollen Ihre Anforderungen aus der Auswahl- und Ausschreibungsphase in seine produktspezifische Lösung zur Lagerverwaltung für den Betrieb in Ihren Lagerstandorten überführt werden. Dabei ist zu beachten, dass eine WMS Pflichtenheft-Phase nach folgenden Aspekten ganz anders ablaufen kann und daher sehr gut organisiert werden muss:


  1. Produkt- oder Anwendersicht?

  2. Pflichtenheftstruktur: Nach Funktionen oder nach Geschäftsvorfällen?

  3. Detailtiefe: Wie genau ist genau genug?

  4. Qualitätssicherung: Vor, während und nachher!


Mann wählt mit Hand Pflichtenheft Spezifikation

1. Produkt- oder Anwendersicht?

Von der Software zum Anwendungsfall oder anders rum? Früher war es in monolithischer Software üblich produktzentriert zu beschreiben, was das WMS im Wareneingang, im Wareausgang und in der Administration alles an Funktionen und Dialogen usw. im Standard bietet. Entlang dieser Produktdokumentation hat man früher punktuell ergänzt, was davon wie konfiguriert und ggf. zusätzlich entwickelt werden muss. Inzwischen hat sich wegen mächtiger + guter Konfigurierbarkeit und über agile Ansätze die Erkenntnis durchgesetzt, dass es besser ist, nur die vom jeweiligen Anwender in WE und WA benötigten User Stories zu beschreiben, um so den zu liefernden Umfang des WMS quasi vom Ergebnis her rückwärts zu spezifizieren. Das vermeidet auch gut das Wünsch-Dir-was-Dilemma und verkürzt Pflichtenheftphasen.

Wenn Sie bereits einen Teil des WMS vor-konfiguriert in Form eines Templates nutzen können, dann hilft das noch weiter die WMS-Pflichtenheftphase zu verkürzen. Dann ist das Standard-WMS + Template Objekten Ihr Startpunkt für Pflichtenheftdiskussionen: Am besten am prototypisch aufgesetzten WMS, das gut zur Anschauung dienen kann.


2. Funktions- oder geschäftsvorfallbezogen?

Wegen der früher üblichen Produktsicht hat sich früher ein sehr funktionsbezogener Aufbau in WMS-Pflichtenheften wiedergefunden. Überlegen Sie sich daher besser schon VOR Beginn der Pflichtenheftphase, welche Geschäftsvorfälle Sie mit dem WMS in Ihrer Logistik im Zusammenspiel in mehreren Stufen realisieren wollen. Diese Geschäftsvorfälle des Lagers im WMS wechselwirken mit der Bestandsverwaltung im ERP und können daher anhand ihrer Bestandsänderungen im WMS identifiziert werden. Meist lassen Sie sich auf diese 6 Schnittstellen zwischen ERP und WMS-System zurückführen und stets im ERP beginnen und dort auch wieder enden:

  • Warenzugänge (WE)

  • Warenabgänge (WA)

  • Umlagerungen (UML)

  • Umbuchungen (UMB)

  • Bestandskorrekturen (BK)

  • Bestandsmeldungen (BM)


In unseren Projekten hat sich eine alphanumerische Nummerierung etabliert, die Sie mit Ihrem Prozessmanagement abstimmen sollten und dann im Pflichtenheft, den User Stories, den Entwicklungsobjekten und später den passenden Testfällen als Struktur beibehalten, um eine durchgängige Traceability zu gewährleisten:

  1. Geschäftsvorfall WE01: Wareneingang zur Lieferantenbestellung

  2. Geschäftsvorfall WE02: Wareneingang zu Lieferavis

  3. Geschäftsvorfall WE03: Wareneingang als nachträgliche Teillieferung zur Bestellung

  4. usw.


Übrigens können Sie diese Betrachtung in teil- und hochautomatisierten Lagern mit Materialflussteuerungen auch adäquat auf die Meldepunkte und Transportabschnitte anwenden, um dort User Stories aus Sicht ihrer Paletten oder Behälter zu formulieren:

  1. Geschäftsvorfall PFT01: Transport von Paletten vom I-Punkt zum Übergabeplatz

  2. Geschäftsvorfall PFT02: Transport von Paletten vom I-Punkt zum Ausschleusplatz

  3. Geschäftsvorfall PFT03: Transport von Paletten vom I-Punkt zum QS-Kontrollplatz

  4. usw.

Für rein technischen Aspekte Ihres WMS können Sie diese natürlich weiterhin funktional beschreiben, z.B. wenn es um Service Level, Hardwarespezifika o.ä. Aspekte geht.



3. Detailtiefe: Wie genau ist genau genug?

Im Lastenheft wird das Was beschrieben und im Pflichtenheft das Wie. Soweit klar. Das Wie kann und soll im Pflichtenheft aber auch nicht in aller Detailtiefe beschrieben werden, denn das ist Gegenstand der technischen Design-Spezifikation aus detaillierter Entwicklungssicht, wo die Software bis auf Datenbankfeldebene determiniert wird. Daher reicht es im WMS-Pflichtenheft oft aus, je User Story WRICEFs zu spezifizieren:

  1. Workflow : Zeitlich-logischer Ablauf von Arbeitsschritten und Statusereignissen

  2. Reports: Listen und Labels, Statistiken, Kennzahlen, d.h. alle Ausgaben

  3. Interfaces : Notwendige Integrationen zu Umfeld-Systemen via Schnittstellen

  4. Conversions : Konvertierung von Datenformaten zur Verarbeitung

  5. Enhancements : Programmtechnische Erweiterungen zur Erfüllung der User Story

  6. Forms : Alle Formulare oder Dialoge zur Datenanzeige und Datenmanipulation


Wir empfehlen aus unserer Erfahrung zusätzlich die Ergebnisse des Arbeitsschrittes in Form von Testendekriterien mit aufzuführen, um so dem Entwickler gleich mitzugeben, was getestet wird, um die korrekte Erfüllung der Anforderung via Testfall zu prüfen.


Da oft nicht nur die Software selbst als Liefergegenstand im Vertrag mit dem WMS Partner vereinbart wird, sondern auch dessen Einführung im Lager oder sogar bis hin zum IT-Systembetrieb als projektbegleitende Dienstleistungen, ist den folgenden Punkten in der Pflichtenheftphase ebenso ausreichend Raum einzuräumen:

  • Projektierung (Meilensteine, Phasen, Termine, RACI, Team, usw.)

  • Know-how (Schulungen, Dokumentation, Support)  

  • Hardware (Server, Peripherie, It- und Lagerequipment)

  • Integration (Schnittstellen, Mapping, Security, usw.)

  • Tests (Testkonzept, Testverfahren, Testplan)

  • Migration (Systeme, Bestände, Umzüge)

  • IT-Systembetrieb (Hosting, IT-Betrieb, Wartung)


Erst wenn diese Aspekte spezifiziert sind, wird Ihr WMS Partner Ihnen die gesamten Projektkosten mit einer Schätzgüte +/- 10.000 € zusagen wollen, da dann über das Pflichtenheft alle Folgeschritte und damit deren Kosten hinreichend gut determinieren.


4. Qualität des Pflichtenhefts sicherstellen!

Es braucht schon Erfahrung und Know-how, um die Qualität von Pflichtenheften für Logistik Software zu beurteilen, die of in Unternehmen gar nicht vorhanden ist.

Dazu bieten wir eine externe Qualitätssicherung während der Pflichtenheftphase an, die unsere fachliche Begleitung vor, während und nach den Pflichtenheft-Workshops umfasst. So sorgen wir iterativ dafür, dass die spezifizierte Lösung optimal zu den zuvor im Lastenheft gestellten Anforderungen und zugesicherten Leistungen aus Verträgen und Ihren eigenen Beistellungen und Mitwirkungspflichten passt. Ferner unterstützen wir Sie aktiv mit Vorschlägen zu den Spezifikationen der Schulungen, Tests, Migrationen und der Projektierung der Realisierungs- und Inbetriebnahme selbst mit unserem ausgeprägten Know-how aus zahlreichen Projekten dieser Art.


Nehmen Sie Kontakt auf:


Rüdiger. W. Schwarz


+Benefit Research und Consulting GmbH + Dahlemer Weg 83a + DE 14167 Berlin

T: +49 172 3872 373 + Email: mail@benefitgroup.de + Web: www.benefitgroup.de  


1 Comment

Rated 0 out of 5 stars.
No ratings yet

Add a rating
Guest
Sep 23
Rated 4 out of 5 stars.
Like
bottom of page