1.3 Was ist ERP-Standardanwendungssoftware? Elemente, Eigenschaften und Gestaltungsmöglichkeiten einer ERP-Softwarebibliothek am Beispiel SAP

Die folgende Darstellung eine ERP-Lösung und ihrer Gestaltungsmöglichkeiten ist ein gekürzte und überarbeitete Fassung das 4. Kapitels im Buch: Thome, R. u. Hufgard, A.: Continuous System Engineering. In Reihe: Integration von Or- ganisation und Information. Würzburg 1996. Was ist ERP-Standardanwendungssoftware Dr. Andreas Hufgard IBIS Prof. Thome AG, www.ibis-thome.de, D-97082 Würzburg, Deutschland E-mail: hufgard@ibis-thome.de - Elemente, Eigenschaften und Gestaltungsmöglichkeiten einer ERP-Softwarebibliothek am Beispiel SAP- 1 Vorurteile bei Entscheidungsträgern ........................................................... 1 2 Organisationsstruktur vor Prozessen.......................................................... 3 2.1 Organisationsänderungen .................................................................... 3 2.2 Rollenänderungen............................................................................... 4 3 Prozessgestaltung muss transparent sein .................................................... 4 4 Daten sind wie ein Goldschatz................................................................... 5 4.1 Organisationssichten im Stammsatz..................................................... 6 4.2 Mehrdimensionale Klassifizierung........................................................ 6 4.3 Stammdaten steuern Prozesse und Funktionen..................................... 6 5 Funktionen müssen beherrscht werden....................................................... 7 6 Berichte sind das Ergebnis ........................................................................ 8 7 Schnittstellen integrieren Fremdsysteme und Geschäftspartner .................... 9 1 Vorurteile bei Entscheidungsträgern Über ERP-Standardsoftware und ihre betriebswirtschaftliche High End-Version in Form der Softwarebibliothek existieren teilweise ausgeprägte Vorurteile, die von naiver Kritiklosigkeit bis zur undifferenzierten Verteufelung reichen. Das Pa- radebeispiel einer betriebswirtschaftlichen Standardanwendungssoftware, die den Kriterien für Softwarebibliotheken entspricht, R/3 bzw. mySAP von SAP soll im folgenden als Fallstudie dienen. Faktum ist, dass dieses marktführende System allen Wettbewerbsprodukten "im Mehrkampf“ betriebswirtschaftlich überlegen ist. Die SAP kann mehr Geld und Know How in die technologische und betriebs- wirtschaftliche Entwicklung investieren als andere. Keine Frage ist auch, dass es ERP-Systeme gibt, die SAP hier und da schlagen, wenn es um spezielle Anforde- rungen geht. Höhepunkt der Kritik waren in den 90er-Jahren Aufsätze, die sich über die Kom- plexität der SAP-Einführung ausließen und technologische Defizite bezüglich Client/Server-Anforderungen und Objektorientierung erkannt zu haben glaubten. Solche Auseinandersetzungen müssen geführt werden, doch um daran ernsthaft teilnehmen zu können und sie zu verstehen, sind eine fundierte theoretische Aus- und Weiterbildung sowie praktische Erfahrung im Umgang mit Softwarebiblio- theken notwendig. So war auch die Reaktion auf diese Kritik in manchen Unter- nehmen bemerkenswert. Nicht sachliche Bewertung über eventuell neu aufgewor- fene Aspekte wurde versucht, sondern Panik brach aus, weil der treue Glaube an SAP massiv wankte. Geschäftsführer und Vorstände zitierten ihre Projekt- und IV-Leiter in Besprechungen, da sie verunsichert waren. Man verlangte Gutachten, Vergleiche und Nutzen-Kosten-Analysen und wollte sich absichern. Die IV- Verantwortlichen holten neutrale Gutachter, Berater und Professoren herbei, um die Geschäftsleitungen zu beruhigen. Das Schlimme daran war und ist, dass diese Gutachten kaum gelesen wurden, weil sich die wilde Diskussion wieder schnell beruhigt hat. Aber die vielen Facetten von Softwarebibliotheken sollten Manager trotzdem nicht davon abhalten, sich einen Überblick zu verschaffen. Hier soll keine übertriebene Euphorie erbreitet werden, sonst folgt auf die Projek- tion von hehren Wünschen auf die Softwarebibliothek zuviel Ernüchterung. Doch der mögliche Fortschritt für die Integration von Organisation und Information macht die Diskussion "ob" oder "ob nicht" unnötig. Auch die Frage, welche Softwarebibliothek zur Auswahl ansteht, kann ein Experte sehr schnell klären. Die aktuelle Herausforderung ist, da ständig neue oder veränderte Anforderungen in der betrieblichen Realität entstehen, müssen auch nach der ordentlichen Erstein- führung einer ERP-Lösung bald neue Zyklen der Überarbeitung im Rahmen der anpassenden Weiterentwicklung möglich sein. Eine Softwarebibliothek muss dann beweisen, das sie änderbar ist, getroffene Einstellungen müssen revidiert werden und ergänzende hinzukommen können. 2 2 Organisationsstruktur vor Prozessen Die erste Aufgabe, die sich bei der SAP-Einführung stellt, ist die Abbildung der spezifischen Organisation des Unternehmens in R/3-Organisationselementen. Vor dieser "Realweltübersetzung" können praktisch keine eigenen Daten, Funktionen und Prozesse bearbeitet werden. Erst wenn SAP die betriebliche Vertriebsstruk- tur oder Geschäftsbereiche kennt, beginnt es als Softwarebibliothek zu leben. Hier kann argumentiert werden, das solche strukturellen Anforderungen einem einfachen Gestalten der Softwarebibliothek im Wege stehen, da zunächst eine aufwendige Organisationsdefinition durchgeführt werden muss. Doch das Ge- genargument verblasst vor den Vorteilen, die sich aus der Strukturbeschreibung ergeben. Denn Prozesse und Funktionen differenzieren meist zwischen unter- schiedlichen Organisationsbereichen, sonst wären diese auch unnötig. Die Festlegung des betrieblichen Aufbaus geschieht durch die Wahl der ge- wünschten oder bereits vorhandenen Struktur für die folgenden Beziehungen von Organisationselementen und ihren Strukturierungsmöglichkeiten. Beispiele: SAP-Elemente Unternehmensstrukturen Pro Werk/Lagerort Eigene Bestandsführung und Disposition Pro Einkaufsorganisation Unterschiedliche Einkaufsabwicklung Pro Verkaufsorganisation Unterschiedliche Vertriebsabwicklung, Preis- findung und Erlöskontierung Pro Werk/Sparte Geschäftsbereichsfindung Pro Vertriebsbereich Eigene Vertriebssichten auf Material, Kunden und eigene Konditionen Pro Versandstelle Versandstellenfindung und Versandterminierung Damit wird für die Standardanwendungssoftware beschrieben, welche Einheiten bei der weiteren, ablauforientierten Darstellung des jeweiligen Unternehmens zu berücksichtigen sind. 2.1 Organisationsänderungen In einem normalen Unternehmen ist praktisch einmal im Jahr eine Reorganisation fällig. Markteinflüsse und interne Gegebenheiten verlangen eine neue Verteilung von Aufgaben und Änderung der Leitungsbeziehungen. Als Fallbeispiel soll hier dargestellt werden, warum und wie ein nach Sparten or- ganisiertes Unternehmen zu einer Matrixorganisation wechselt und wie dies inte- grativ im ERP-System nachvollzogen wird. In der Ausgangssituation agieren zwei Produktsparten eigenständig am Markt. Sie sind in ih- ren logistischen und vertrieblichen Aktivitäten in allen Märkten autonom. Eine Ausnahme bil- det lediglich eine Betriebsstätte im Ausland, die für den fremden Markt beide Produktsparten 3 vertreibt, weil dies kostengünstiger ist. Wird der Markt zum primären Strukturkriterium, wie dies die Situationsänderung im Beispiel unterstellt, dann verlieren die Produktsparten an Be- deutung. Die entstehende, anspruchsvollere Organisationsstruktur führt zu neuen Profitcen- tern, Geschäftsbereichen und Vertriebsbereichen. 2.2 Rollenänderungen Auf personeller Ebene findet eine dynamische Reorganisation fast täglich statt. Aufgrund von Projekterfordernissen werden neue Teams gebildet, und einem Mitarbeiter fällt eine neue Rolle zu. Diese Gruppenstrukturwechsel und Vor- gangsveränderungen liegen auf Ebene der Berechtigungen und Benutzerführung. Sie werden aber durch verbesserte Gestaltungs- und Steuerungswerkzeuge für den Workflow und die Arbeitsplatzgestaltung unterstützt. Die Instrumente der ERP-Lösungen sind hier mit anderen Erfordernisse, z.B. ein Intranet abzustim- men. 3 Prozessgestaltung muss transparent sein In der wissenschaftlichen und praktischen Auseinandersetzung mit ERP-Software wird die - Business Process Reengineering orientierte - Diskussion über die Ges- taltung von Geschäftsprozessen völlig überbewertet. Die dort angestrebte Opti- mierung der Geschäftsprozesse gibt es nicht. Schon die Benennung suggeriert dem Anwender ein unrealistisches Ergebnis, denn ein Optimum als beste Lösung ist für die vagen Zielfunktionen der einzelnen Betriebsabläufe nicht ermittelbar. Die Verbesserung der Ablauforganisation bis hin zu einer möglichst guten Gestal- tung ist jedoch sehr wohl erstrebenswert. Es sollte aber nicht versucht werden, die Umstellung bereits durch die Einführung von R/3 durchzusetzen. Vielmehr sollte der Weg dorthin schrittweise gefunden werden. Das heißt, die flexible Ges- taltungsfreiheit der Softwarebibliothek ist das wichtigere Thema, weil sie die Vor- aussetzung für die schnelle Anpassung von Organisation und Informationsverar- beitung ist. Geniale Einfälle, die Geschäftsprozesse revolutionieren, gibt es leider sehr selten.