ERP für den Handel

Bei allen größeren ERP-Anbietern hat die Notwendigkeit zur Abdeckung von Branchenspezifika (Modeeinzelhandel ist nun einmal etwas komplett anderes als technischer Großhandel) zudem zur Ausprägung eigener oder durch Partner erstellter Branchenlösungen geführt, die das branchenunabhängige ERP-System an die Spezifika bestimmter Branchen anpassen und damit reduzierte Einführungskosten versprechen. Beispiele sind die verschiedenen Branchenlösungen für SAP ERP und SAP Business One, Microsoft Dynamics NAV und Dynamics AX sowie Comarch Semiramis.

Ebenfalls nicht durchgesetzt hat sich in der Praxis – zumindest nicht in der theoretischen Reinform – der Ansatz flexibler Service-orientierter-Architekturen (SOA), bei denen verschiedenste Komponenten und (Web-)Services unterschiedlicher Hersteller zu einer individuellen Gesamtlösung zusammengestellt werden. Wie auch schon bei dem ähnlichen Vorgängerkonzept des „best-of-breed"-Ansatzes, scheitern diese Konzepte in der Praxis daran, dass es vor allem für die Struktur und die Semantik der Daten keine einheitlichen Standards gibt und gerade Handelsunternehmen einen besonderen Wert auf stabile und ausfallsichere Anwendungssysteme legen, für die sie möglichst einen zentralen Ansprechpartner und Verantwortlichen haben wollen. Alleine das Lizenzmanagement und das Release-/Update-Management derartiger IT-Architekturen würden erhebliche Herausforderungen mit sich bringen.

Handelsunternehmen, die Interesse haben, ihre zentralen Warenwirtschaftsfunktionen durch die individuelle Kombination von mehreren hundert Web Services unterschiedlicher Anbieter zu unterstützen, scheint es daher nachvollziehbarer Weise nur selten zu geben. IT-Verantwortliche sollten deshalb Konzepte wie Web Services und SOA nicht per se verneinen, sondern nur als das verstehen, was sie tatsächlich sind: Entwicklungskonzepte für Softwarehersteller, um flexible erweiterbare Standardsoftwarelösungen zu schaffen. Damit liegt der wesentliche Nutzen allerdings intern bei den Herstellern in der Software-Entwicklung und weniger in der individuellen Kombinationsmöglichkeit vieler kleiner Softwarekomponenten beim Handelsunternehmen.

Das Warenwirtschaftssystem wird daher auch mittelfristig das zentrale Anwendungssystem in Handelsunternehmen bleiben. Gemäß der üblichen Definition deckt es alle warenwirtschaftlichen Beschaffungs-, Lager- und Vertriebsprozesse ab und hat somit erhebliche direkte und indirekte Auswirkungen auf alle zentralen Prozesse des Handelsunternehmens sowie Mitarbeiter und Geschäftspartner. Als führendes Stammdatensystem versorgt es zudem typischerweise eine Vielzahl an Spezialsystemen. Ein Ausfall nur für wenige Stunden würde die meisten Handelsunternehmen bereits vor erhebliche Probleme stellen.

Neben der Stabilität und Ausfallsicherheit kommt aber vor allem der adäquaten Unterstützung der Geschäftsprozesse eine hohe Bedeutung zu. Nur mit einem „passenden" WWS lassen sich effiziente Geschäftsprozesse ausgestalten. Dabei ist es wichtig zu sehen, dass der Handel in seiner Ausgestaltung so vielfältig ist, dass es nicht ein universell „bestes" WWS geben kann. Der Markt für standardisierte WWS ist dementsprechend groß, vielfältig und – nicht zuletzt aufgrund einer hohen Marktdynamik – leider oft recht intransparent. Neben den großen Anbietern existieren viele kleinere Branchenspezialisten. Konsolidierungstendenzen bei den Anbietern sind weiterhin gegeben. Zahlreiche, sich oftmals thematisch überschneidende Branchenvarianten der großen ERP-Plattformen wie SAP ERP oder Microsoft Dynamics NAV beziehungsweise Dynamics AX führen zu einer zusätzlichen Herausforderung. Unterschiedliche technologische Ausgestaltungen und Anpassungsmöglichkeiten der WWS erfordern auch eine detaillierte technologische Betrachtung.

Für Handelsunternehmen stellt die WWS-Auswahl eine wichtige IT-Entscheidung mit weitreichenden und langfristigen Auswirkungen dar, für die in der Regel kaum Erfahrungswerte in den Unternehmen existieren. Denn idealerweise beschäftigt sich ein Handelsunternehmen nur circa alle zehn bis zwölf Jahre mit der Auswahl einer neuen WWS-Lösung. Detailkenntnisse zu den aktuellen Stärken und Schwächen der verschiedenen angebotenen WWS sind naturgemäß kaum vorhanden. Die Einzelanforderungen fachlicher, technologischer und strategischer Natur sind aber vielfältig und müssen entsprechend strukturiert und priorisiert werden. Wenngleich die Einzelanforderungen aufgrund der Branchen- und Unternehmensspezifika stets unternehmensindividuell zu betrachten sind, lassen sich aus der langjährigen Analyse des WWS-Marktes und der Durchführung diverser WWS-Auswahlprojekte einige zentrale Kernanforderungen ableiten:

• Fachliche Abdeckung und Brancheneignung

Die fachliche (funktionale) Eignung wird typischerweise recht detailliert in Auswahlprojekten betrachtet. Grundlegend sollte die Abdeckung der geforderten Funktionsbereiche und die jeweils vorhandene Funktionstiefe geprüft werden. Dann sollte der Fokus auf geschäftskritische sowie branchen- beziehungweise unternehmensspezifische Anforderungen gelegt werden. Gerade grundlegende querschnittliche Anforderungen mit Auswirkungen auf diverse betriebliche Aufgaben beziehungweise Prozesse und die zugrunde liegenden Datenstrukturen lassen sich im Nachhinein oft nur mit erheblichem Aufwand realisieren. Beispiele hierfür sind Strukturierte Artikel (Sets, Displays etc.), mehrdimensionale Artikelvarianten beziehungsweise Matrixerfassung, Gewichtsartikel oder die Chargen- beziehungsweise Seriennummernverwaltung. Zusätzliche funktionale Branchenspezifika runden die Betrachtung ab. Dazu gehören zum Beispiel Metallzuschläge, Frischemerkmale im Artikelstamm, uhrzeitabhängige Verkaufspreise, Referenzgrößen und -farben. Ein weiterer Indikator für eine Brancheneignung können entsprechende Referenzen in der jeweiligen Branche sein. Es sollte zumindest eine bewusste Entscheidung sein, als Erster ein WWS in einer bestimmten Branche einzuführen.

• Anpassbarkeit/ Erweiterbarkeit

Es zeigt sich in allen Projekten, dass mittelständische Handelsunternehmen stets so spezifische Anforderungen besitzen, dass eine Anpassung des WWS-Standards im Projekt erforderlich wird. Je nach Umfang der Anpassungen kommt der Art und Weise, wie die Software dies ermöglicht, eine zentrale Bedeutung zu. Grundlegend zu unterscheiden ist die Entwicklungsphilosophie der Anbieter dahingehend, ob sie einen Single-Source-Ansatz verfolgen, also alle Anpassungen werden stets in einer zentralen Programmversion vorgenommen, oder Anpassungen kundenindividuell realisiert werden. Bei der technischen Durchführung der Anpassungen ist zu fordern, dass die Standardsoftware für Anpassungen vorbereitet ist. Dazu zählen beispielsweise User Exits oder Vererbungskonstrukte in objektorientierten Systemen.

• Zukunftssicherheit

Der Zukunftssicherheit des Anbieters und vor allem des Produkts kommt bei einer geplanten Nutzungsdauer von typischerweise mehr als zehn Jahren eine zentrale Bedeutung zu. Als Indikatoren für die Anbietersicherheit können die generelle Marktposition des Anbieters (Installierte Basis in dem für ihn relevanten Markt) sowie klassische Finanzkennzahlen zur wirtschaftlichen Lage dienen. Eine hohe Aussagekraft besitzt auch die Fähigkeit des Anbieters, neue Projekte zu akquirieren und erfolgreich zu realisieren. Bezogen auf das WWS ist der Lebenszyklus des Produktes zu hinterfragen: System mit klarer längerfristiger Weiterentwicklungsperspektive versus veraltetes System mit primärer Ausrichtung auf „Bestandskundenpflege".

• Eignung für die gegebenen Organisationsstrukturen

Eines der Grundgerüste, das projektindividuell nur sehr schwer änderbar ist, sind die Organisationsstrukturen im WWS. Sie entscheiden, ob und wie die konkreten Unternehmensstrukturen wie komplexe Standort- oder Firmenkonstrukte abgebildet werden können. Eng damit verbunden ist die Frage, wie Stammdaten gehalten werden können. Hohe Relevanz besitzt zunehmend die Sicherheit, dass die neue WWS-Lösung auch alle rechtlichen Anforderungen, beispielsweise hinsichtlich der Grundsätze ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS) oder der Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU) abdeckt. Kommen internationale Standorte hinzu, so sollten entsprechende Landesversionen des WWS verfügbar sein, die die dortigen legalen und fiskalischen Landesspezifika abdecken.

• Total-Cost-of-Ownership (TCO)

Bei der Kostenbetrachtung ist eine Gesamtkostenbetrachtung (TCO) für eine Betrachtungsdauer von mindestens fünf bis acht Jahren zu empfehlen, so dass zumindest ein bis zwei Releasewechsel in der Kostenbetrachtung enthalten sind. Zu differenzieren ist zwischen den initialen Projektkosten und den laufenden Folgekosten, bei welchen neben den Wartungs-/Supportkosten auch zwingend die Kosten für Releasewechsel berücksichtigt werden sollten. Aufgrund unterschiedlicher Ansätze der Anbieter können sich hier erhebliche Unterschiede ergeben. So bieten Anbieter, die einen Single-Source-Ansatz verfolgen, pauschalierte Releasewechsel zu einem relativ geringen Festpreis an, während bei individuell realisierten Anpassungen ein großes Releaseprojekt aus Sicht der Kosten durchaus in Bereiche von 50 Prozent der ursprünglichen Entwicklungskosten reichen kann. Praktische Hilfsmittel für Projektanpassungen sind zudem Makrosprachen und flexible grafische GUI-Editoren. Zu empfehlen ist bei allen zentralen funktionalen Anforderungen, die nicht im Standard erfüllt sind, bereits in der Endauswahl des WWS zu hinterfragen, durch welchen Lösungsansatz diese Lücken im Projekt geschlossen werden können.