Die Warenwirtschaftssoftware bildet das zentrale Anwendungssystem in der häufig komplexen IT-Landschaft von Handelsunternehmen.
Die IT-Architekturen mittelständischer Handelsunternehmen weisen häufig eine sehr komplexe IT-Landschaft auf. Neben der Warenwirtschaftssoftware existieren diverse Spezialsysteme: einerseits klassisch in den Bereichen Finanzbuchhaltung, Lohn & Gehalt sowie Auswertungen beispielsweise in Form separater Data-Warehouse-Systeme, andererseits aber auch in warenwirtschaftlichen Bereichen in Form von dedizierten Webshop-, Regalplanungs- oder Bestandsoptimierungssystemen. Typisch für derartige IT-Architekturen ist, dass die Warenwirtschaftssoftware das zentrale Anwendungssystem darstellt und – zumindest für die grundlegenden Stammdaten, wie Artikel, Geschäftspartner, Preise etc. – das führende System ist.
Gemäß der üblichen Definition deckt Warenwirtschaftssoftware 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 sie zudem typischerweise eine Vielzahl an Spezialsystemen. Ein Ausfall für nur 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 einer „passenden" Warenwirtschaftssoftware 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 eine universelle „beste" Warenwirtschaftssoftware geben kann. Der Markt für standardisierte Warenwirtschaftssoftware 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 Warenwirtschaftssoftware erfordern auch eine detaillierte technologische Betrachtung.
Für Handelsunternehmen stellt die Auswahl einer Warenwirtschaftssoftware 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 Warenwirtschaftssoftware. Detailkenntnisse zu den aktuellen Stärken und Schwächen der verschiedenen angebotenen Warenwirtschaftssoftware 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 Marktes für Warenwirtschaftssoftware und der Durchführung diverser Auswahlprojekte für Warenwirtschaftssoftware einige zentrale Kernanforderungen ableiten.
Die fachliche (funktionale) Eignung einer Warenwirtschaftssoftware 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/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- oder 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 der Warenwirtschaftssoftware können entsprechende Referenzen in der jeweiligen Branche sein.
Es zeigt sich in allen Projekten, dass mittelständische Handelsunternehmen stets so spezifische Anforderungen besitzen, dass eine Anpassung des Standards der Warenwirtschaftssoftware 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 der Warenwirtschaftssoftware stets in einer zentralen Programmversion vornehmen, oder ob Anpassungen kundenindividuell realisiert werden. Bei der technischen Durchführung der Anpassungen ist zu fordern, dass die Warenwirtschaftssoftware für Anpassungen vorbereitet ist. Dazu zählen beispielsweise User Exits oder Vererbungskonstrukte in objektorientierten Systemen.
Hier geht's zur kostenlosen Marktübersicht für Warenwirtschaftssoftware
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 die Warenwirtschaftssoftware ist der Lebenszyklus des Produktes zu hinterfragen: System mit klarer längerfristiger Weiterentwicklungsperspektive versus veraltetes System mit primärer Ausrichtung auf „Bestandskundenpflege".
Eines der Grundgerüste, das projektindividuell nur sehr schwer änderbar ist, sind die Organisationsstrukturen in der Warenwirtschaftssoftware. 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 Warenwirtschaftssoftware 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 der Warenwirtschaftssoftware verfügbar sein, die die dortigen legalen und fiskalischen Landesspezifika abdecken.
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 der Warenwirtschaftssoftware 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 der Warenwirtschaftssoftware zu hinterfragen, durch welchen Lösungsansatz diese Lücken im Projekt geschlossen werden können.