Standard- oder Individual-Software?

Nicht auf gut Glück implementieren

Im Interview spricht E.Bootis-CEO Dr. Tim Langenstein über die Unterschiede zwischen Standard- und Individual-Software, ERP-Customizing und die Bedeutung von Use Cases.

Dr. Tim Langenstein

Dr. Tim Langenstein, E.Bootis

ITM: Standard- oder Individualsoftware – Vor nahezu jeder ERP-Einführung steht diese Frage. Wie können Mittelständler vorgehen, um für sich die richtige Wahl zu treffen? Welches sind z. B. bei der Entscheidungsfindung gängige Fehler, die vermieden werden könnten?
Dr. Tim Langenstein:
Vor jeder ERP-Einführung muss ein Unternehmen im Rahmen des Auswahlprozesses genau definieren, welche betriebswirtschaftlichen Ziele es mit der Einführung eines neuen ERP-Systems verfolgt. Neben den aktuellen Anforderungen gilt es vor allem auch langfristige Marktveränderungen zu betrachten, für die es einer größtmöglichen Flexibilität in der Prozessgestaltung bedarf. Wer hier „auf gut Glück“ implementiert, ist schnell in einer Kostenfalle, unabhängig von der Art der Lösung.

Bei der Entscheidung zwischen Standard- und Individualsoftware unterliegen viele Unternehmen dem Fehler, ihre Prozesse als äußert individuell und zu weit entfernt vom Standard einzuschätzen. Ein Grund dafür mag sein, dass ein Erfahrungsaustausch zwischen Entscheidern bezüglich konkreter Prozessabläufe eher selten erfolgt. In unserem täglichen Geschäft erleben wir oft, dass Entscheider überrascht sind, mit welch geringen Anpassungen sie ihre Prozesskultur in unsere Standardsoftware etablieren können.

ITM: Welches sind – speziell für mittelständische Unternehmen – mögliche Vor- und Nachteile beider Lösungen?
Langenstein:
Absolute Freiheit in der individuellen Anpassung an die betrieblichen Anforderungen verbindet man auf den ersten Blick mit einer Individualsoftware. Die berühmte „Grüne Wiese“ ermöglicht es, Prozesse und Funktionen passgenau für das Unternehmen zu entwickeln. Werden jedoch die Anforderungen nicht genauestens durchdacht und definiert, zieht sich die Entwicklungs- und damit Einführungszeit erheblich in die Länge.

Davon abgesehen ist man nur Teil des Software-Fortschritts, solange man ihn finanziert. Sowohl auf Technologie- als auch Funktionsebene wird eben nur genau das realisiert, was auch beauftragt wird. Als Unternehmen muss man demnach selbst die Ressourcen aufbringen, um neue Lösungsansätze im Markt zu identifizieren und umzusetzen. Durch den Einsatz einer Standardsoftware wird diese Aufgabe ein Stück weit auf den Softwarehersteller übertragen.

Der Vorteil einer gewachsenen Standardsoftware ist sicherlich die enorme Funktionsbreite, aus der ein Unternehmen Prozesse umsetzen kann. Allerdings sollte man eine Standardsoftware nicht mit Standardprozessen gleichsetzen. Denn mit reinen 08/15-Prozessen lassen sich selten echte Mehrwerte für Kunden bereitstellen. Daher brauchen Unternehmen auch in einer Standardsoftware umfangreiche Möglichkeiten, prozessuale Alleinstellungsmerkmale abzubilden. Wir haben dafür den Ansatz der individualisierbaren Standardsoftware gewählt, der einerseits einen gemeinsamen Fortschritt im Rahmen des Standards gewährleistet, andererseits aber per Konfiguration massive Individualisierungsmöglichkeiten bietet.

ITM: Eine gängige Annahme ist nach wie vor, dass das Aufsetzen einer Standardlösung Kosten einspare. Inwieweit trifft dies zu?
Langenstein:
Kosteneinsparungen müssen immer auf mehreren Ebenen betrachtet werden. Kurzfristig ist die Einführung einer Standardsoftware oft günstiger, weil die Kosten für den Erwerb und eventuelle Anpassungen meistens deutlich niedriger liegen. Auch durch die sofortige Verfügbarkeit der Lösung verkürzt sich die Einführungszeit, da viele Prozesse bereits grundlegend konfiguriert werden können.

Den Kostenvorteil einer Standardlösung spürt ein Unternehmen aber vor allem in der langfristigen Betrachtung. Durch die permanente Weiterentwicklung partizipiert es am Fortschritt der Software, zu dem alle Nutzer beitragen. Das fängt bei der einfachen Einrichtung und Wartung von Schnittstellen zu Fremdsoftwares an und hört auf bei technologischen Trends wie z. B. dem Einsatz von künstlicher Intelligenz im Unternehmensumfeld. 

ITM: Viele Unternehmen setzen zunächst auf den Standard, um später via Customizing weitere Anpassungen vornehmen zu können. Inwieweit ist dieses Vorgehen sinnvoll und wo stößt es an seine Grenzen?
Langenstein:
Wie bereits erwähnt, muss auch eine Standardsoftware anpassbar bleiben. Unter dem Begriff „Customizing“ wird oft der Lösungsansatz versteckt, außerhalb der Standardsoftware-Logik individuelle Anpassungen für einzelne Kunden zu realisieren. Das kann langfristig nur zu einem Kostendesaster führen, da diese Individualprogrammierungen bei Releasewechseln oft erneut erfolgen müssen.

Ich kann nur eindringlich davor warnen, Standardlösungen einzusetzen, die ihre Anpassbarkeit durch nicht Release-fähiges Customizing erlangen. Alle Vorteile einer Partizipation am Fortschritt einer Standardsoftware sind hinfällig, wenn ein Releasewechsel genau so viel kostet wie die Einführung, weil Erweiterungen neu entwickelt werden müssen.

Aus unserem Verständnis muss eine zukunftsfähige Standardlösung die Technologie bieten, individuelle Anforderungen innerhalb der Standardlogik umzusetzen. Alles andere ist nicht mehr zeitgemäß.

ITM: Die Systemanforderungen steigen stetig an – Trends wie Mobility oder I 4.0 geben dabei den Takt an. Wie beeinflusst z.B. das Anbinden von Fremdsystemen die Entscheidung?
Langenstein:
Die Anbindung von Fremdsystemen ist ein wesentlicher Pfeiler der heutigen Unternehmens-IT und wird auch in Zukunft eher zu- als abnehmen. Firmenübergreifende Geschäftsprozesse und deren Digitalisierung sind eine Grundvoraussetzung – oftmals sogar das K.o.-Kriterium bei einer modernen ERP-Auswahl.

Auch hier gibt es Unterschiede in der Umsetzung. Während bei einer Individualsoftware jedes Anbinden eines Fremdsystems ein eigenständiges Projekt ist, bieten Standardsoftwares bereits implementierte Schnittstellen zu vielen gängigen Fremdsystemen. Hier sollte das Augenmerk eher auf dem Aufwand liegen, der mit der Anbindung individueller Systeme einhergeht. Hier bieten moderne Standardlösungen mit offenen Systemstrukturen auf Basis von Web-Services die bestmögliche Investitionssicherheit.

ITM: Welche Nachteile kann es mit sich bringen, die Use Cases nicht genau zu definieren und erst im Nachhinein zu bemerken, dass man sich falsch entschieden hat?
Langenstein:
Speziell bei Individuallösungen resultiert die ungenaue Definition eines Use Cases meistens in ausufernden Kosten, da im schlimmsten Fall erst nach der Fertigstellung erkannt wird, wie weit die Lösung von den realen Anforderungen abweicht. Je grundlegender die Fehlannahme im Code implementiert wurde, desto höher der Korrekturaufwand.

Ungenaue Use Cases können aber auch bei Standardsoftwares zu Kosten führen, weil dadurch die Gefahr im Auswahlprozess steigt, die Eignung der Standardsoftware nicht ausreichend beurteilen zu können. Stellt sich erst während der Implementierung heraus, dass der Use-Case umfangreicher war als angenommen, entsteht auch hier ein Mehraufwand.

ITM: Welche Optionen bleiben Unternehmen, die sich „falsch“ entschieden haben? Welche Handlungsoptionen verbleiben überhaupt?
Langenstein:
Falsch ist erst einmal relativ und kann nicht pauschal beantwortet werden. Es kommt sehr auf den Grund der Erkenntnis und den Status der Einführung an. Generell sollte ein Unternehmen immer das Gesamtpaket „Ziele & Kosten“ im Blick haben. Was würde es kosten, die Software so anzupassen, dass wir die gesteckten Ziele erreichen? Welchen Aufwand bedeutet es für das Unternehmen, die vorhandene Lösung über einen Zeitraum von 10 bis 15 Jahren zu betreiben? Macht es unter diesem Aspekt Sinn, eine Einführung zu stoppen und auf Basis der gewonnenen Erkenntnisse nochmal neu zu starten? Die Antworten darauf sind immer situationsbezogen, unter Abwägung aller Aspekte zu finden.

Bildquelle: E.Bootis

©2021Alle Rechte bei MEDIENHAUS Verlag GmbH

Unsere Website verwendet Cookies, um Ihnen den bestmöglichen Service zu bieten. Durch die weitere Nutzung der Seite stimmen Sie der Verwendung zu. Weitere Infos finden Sie in unserer Datenschutzerklärung.

ok