6.2 Weitere Anpassungsmöglichkeiten * 233

6.2 Weitere Anpassungsmöglichkeiten * 233 rende Kosten handelt, da jeder spätere»releasewechsel«(s. 363) wegen der Modifikationen zusätzlichen Aufwand verursacht. Hierdurch kann der ursprüngliche Kostenvorteil einer Standardlösung gegenüber einer Individuallösung kompensiert oder sogar ins Gegenteil umgekehrt wird, sodass der Return-on-Investment eines ERP-Projektes sogar gänzlich verhindert werden kann (vgl. /Frisch 03 a/). Modifikationen gefährden ROI 6.2.1 Personalisierung * Die Personalisierung dient der optimalen Anpassung der Bedienung des ERP-Systems an die Anforderungen der Benutzer. Dazu gibt es viele verschiedene Möglichkeiten, die jedoch alle ohne Programmierung ausgeführt werden können. Der Vorteil, der sich durch eine effizientere Bedienung ergibt, stellt sich jedoch nur ein, wenn auch eine gründliche Analyse bei der Einführung des Systems vorgenommen wurde. Deren Aufwand ist i.d.r. jedoch erheblich geringer als der daraus resultierende Nutzen. Bei der Personalisierung (vom Englischen: personalizing) handelt es sich ähnlich wie beim Customizing um Anpassungen, die ohne Programmierung im ERP-System durchgeführt werden können. Der Unterschied besteht jedoch darin, dass diese Art von Anpassungen nicht zwingend notwendig sind, um das System produktiv nutzen zu können. Sie dienen vielmehr dazu, die Bedienung des System an die speziellen Bedürfnisse einzelner Benutzer oder -gruppen anzupassen mit dem Ziel, ihre Arbeit so effizient wie möglich zu gestalten. In diesem Zusammenhang wird oft auch von so genannten Rollen gesprochen. Sie dienen zur Beschreibung der individuellen Anforderungen, Arbeitsweisen, notwendigen Funktionen und Berechtigungen eines Arbeitsplatzes. So unterscheidet z.b. Microsoft in seinem Customer Model über 60 verschiedene Rollen, die für konkrete Stellen im Organigramm der Contoso GmbH 2, dem virtuellen Musterunterneh- Ziel: effiziente Bedienung Rollen 2 Die Contoso GmbH ist die virtuelle Musterfirma von Microsoft anhand derer das Unternehmen die Anpassungsmöglichkeiten ihrer Standardsoftware

234 6 Unternehmensspezifische Anpassungen * men von Microsoft stehen und für die dedizierte Rollenbeschreibungen existieren. Sie bilden die Grundlage für die Entwicklung und optimale Anpassung der Arbeit mit ihrer ERP-Lösungen an die jeweiligen Arbeitsplätze. Arten der Personalisierung In der Praxis wird es wohl nie einen Benutzer geben, der die gesamte Funktionalität eines ERP-Systems für seine tägliche Arbeit nutzen wird. Aus diesem Grund ist es ratsam, die Bedienung des Systems an die konkreten Bedürfnisse spezieller Benutzergruppen in Abhängigkeit ihrer Tätigkeiten anzupassen, um so die Komplexität des Systems zu reduzieren und die Benutzer nicht durch, für sie unnötige Funktionen, zu verwirren. Hierzu gibt es prinzipiell zwei Arten der Personalisierung: 1 Personalisierung des Arbeitsplatzes 2 Personalisierung der Funktionalität Abschließend sei noch erwähnt, dass viele ERP-Systeme den Anwendern auch Möglichkeiten bieten, die Benutzeroberfläche nach ihren persönlichen Vorlieben hinsichtlich Farbgebung, Schriftarten und -größen, Hintergrundbilder und Mauszeiger sowie akustischer Signale zu gestalten. Auf diese Anpassungsmöglichkeiten soll hier jedoch nicht weiter eingegangen werden. Personalisierung des Arbeitsplatzes Das Ziel dieser Personalisierungsmaßnahmen ist es, die Bedienung des ERP-System so effektiv wie möglich auf die Bedürfnisse eines konkreten Arbeitsplatzes zuzuschneiden. Dies kann durch mehrere Möglichkeiten erreicht werden: arbeitsplatzspezifische Menüs Zunächst sollten die Menüs der Benutzeroberfläche konkret auf einen Arbeitsplatz zugeschnitten werden, indem alle nicht benötigten Funktionen oder Untermenüs ausgeblendet werden. für die wichtigsten Geschäftsbereiche von mittelständischen Unternehmen demonstriert. Sie ist jedoch nicht zu verwechseln mit der Cronus AG, die als virtuelles Unternehmen ausschließlich im Mustermandanten von Microsoft Dynamics NAV verwendet wird.

6.2 Weitere Anpassungsmöglichkeiten * 235 Abb. 6.2-3: Einrichtung eines rollenbasierten Menüs für die Debitorenbuchhaltung durch das Ausblenden nicht benötigter Untermenüs und deren Funktionen. Im Zuge der Personalisierung kann beispielsweise der Beispiel Arbeitsplatz eines Debitorenbuchhalters in Microsoft Dynamics NAV so auf seine Bedürfnisse angepasst werden, dass dem Anwender aus dem Standard Finanzmanagement-Menü (linke Seite in Abb. 6.2-4) nur diejenigen Untermenüs und deren Funktionen angezeigt werden, die er benötigt. Alle übrigen Untermenüpunkte (z.b. Kreditoren, Anlagen, Lager, etc.) und deren Funktionen werden hierbei einfach ausgeblendet. So erhält man auf einfache Art ein rollenbasiertes Menü für die Debitorenbuchhaltung (rechte Seite in Abb. 6.2-4). Shortcuts Eine weitere Möglichkeiten zur personalisierten Anpassung des Menüs bieten so genannte Favoriten- oder Shortcut-Menüs, in denen all diejenigen Funktionen unabhängig von ihrer strukturellen Zuordnung an einer Stelle zusammengefasst werden können, die der Anwender bei seiner täglichen Arbeit besonders häufig benötigt (siehe Abb. 6.2-4). Auf ähnliche Weise lassen sich auch ganz einfach Shortcuts zu einzelnen Belegen in Microsoft Dynamics NAV, aber auch zu externen Dokumenten oder Internet- Seiten anlegen.

236 6 Unternehmensspezifische Anpassungen * Abb. 6.2-4: Personalisierung des Arbeitsplatzes durch das Anlegen von Shortcuts zu häufig genutzten Funktionen in Microsoft Dynamics NAV. Beispiel Abb. 6.2-4 zeigt schematisch, wie in Microsoft Dynamics NAV mit einfachen Mausklicks ein so genanntes Shortcut- Menü erstellt werden kann, in dem der Anwender aus verschiedenen Menüs diejenigen Funktionen oder aber auch Untermenüs zusammen stellen kann, die er für seine tägliche Arbeit am häufigsten benötigt. Hierdurch kann er sich den ständigen Wechsel zwischen den drei dargestellten Menüs Finanzmanagement, Einkauf und Logistik sparen und so effizienter am System arbeiten. Ein- bzw. Ausblenden von Feldern Darüber hinaus lassen sich auch in den meisten Masken von Microsoft Dynamics NAV nicht benötigte Felder ausbzw. weitere Felder der zugehörigen Tabelle einblenden oder aber in Bezug auf ihre Spaltenposition in einem Übersichtsfenster von links nach rechts oder umgekehrt verschieben. Beispiel In der Abb. 6.2-5 ist im oberen Bereich die Artikelübersicht einer Einkaufsbestellung in der Standard-Tabellensicht von Microsoft Dynamics NAV dargestellt. Darunter ist die glei-

6.2 Weitere Anpassungsmöglichkeiten * 237 Abb. 6.2-5: Personalisierung von Tabellenansichten durch das Ein- und Ausblenden von Spalten. che Tabelle zu sehen, bei der im Rahmen der Personalisierung die Spalten Reservierung, EK-Preis und Zeilenbetrag ausgeblendet und dafür die Spalte VK-Preis eingeblendet wurde. Zusätzlich wurde die Spalte erwarteter Liefertermin weiter nach links in den sichtbaren Ausschnitt verschoben. Personalisierung der Funktionalität Die zweite Art zur Personalisierung eines ERP-Systems besteht in der Anpassung seiner Funktionen. Dies kann auf unterschiedliche Weise erfolgen, wobei hierzu jedoch nur diejenigen Möglichkeiten zählen, die wiederum ohne Programmierung realisiert werden können. Als Beispiele können in diesem Zusammenhang genannt werden: Vorbelegung von Eingabefeldern Wenn in Abhängigkeit vom jeweiligen Anwender für bestimmte Eingabefelder nur ganz spezielle Werte als zulässige Eingaben infrage kommen, so können diese im Rahmen der Personalisierung bereits vorher festgelegt werden, sodass die Felder in den entsprechenden Masken schon beim Aufruf mit diesen Werten vorbelegt werden können. Hierdurch können dem Anwender lästige Routineeingaben erspart und seine Arbeit somit erleichtert werden.

238 6 Unternehmensspezifische Anpassungen * Beispiel In der Debitorenbuchhaltung der Cronus AG gibt es eine personelle Trennung der Zuständigkeiten hinsichtlich In- und Ausland. In der einheitlichen Erfassungsmaske für entsprechende Rechnungen ist jedoch ein Kennzeichen zu pflegen, welches zur Unterscheidung der beiden Fälle dient. Dies kann je nach Mitarbeiter gemäß seiner Zuständigkeit vorbelegt werden, sodass es nicht bei jedem Auftrag erneut eingegeben, sondern nur in Ausnahmefällen (z.b. bei Urlaubsvertretungen) überschrieben werden muss. Ein konkretes Beispiel aus Microsoft Dynamics NAV wäre hierfür etwa das Feld Verkäufercode in der Abb. 6.2-6. Sperren der Eingabebereitschaft Wenn einzelne Mitarbeiter aufgrund ihrer Zuständigkeiten nicht zur Eingabe bestimmter Felder berechtigt sind, so ist esratsam,diesevonanfanganfürdieeingabedurchdie betreffenden Mitarbeiter zu sperren. Diese Vorgehensweise ist deutlich effektiver, als wenn die Eingabe für jeden zulässig ist und erst danach eine Überprüfungen im System stattfindet. Diese Personalisierungsmaßnahme lässt sich recht einfach realisieren, indem bei den betroffenen Feldern eine fallspezifische Eingabebereitschaft eingestellt wird. Beispiel In der Abb. 6.2-6 ist die Maske zur Verwaltung von Verträgen in Microsoft Dynamics NAV abgebildet. Wie an dem hellgrau hinterlegten Feld Name ersichtlich ist, ist die Eingabebereitschaft für dieses Feld aktuell unterdrückt. Ein Blick auf die Eigenschaften (Properties, rechts oben in Abb. 6.2-6) ergibt, dass die hierfür zuständige Eigenschaft Enabled auf Yes gesetzt ist, d.h. das Feld der Maske generell eingabefähig ist. Ein zweiter Blick zeigt jedoch, dass diese Eigenschaft durch einen so genannten Trigger (C/AL- Code, rechts unten in Abb. 6.2-6) in Abhängigkeit von verschiedenen Bedingungen übersteuert wird. Bei diesem Beispiel handelt es sich zugegebenermaßen um einen Grenzfall, da die hierzu erforderliche Logik des Triggers im C/AL-Quellcode programmiert wird und somit streng genommen keine Personalisierung darstellt. Andererseits hat Microsoft die Trigger in Microsoft Dynamics

6.2 Weitere Anpassungsmöglichkeiten * 239 Abb. 6.2-6: Die Eingabebereitschaft von Feldern kann in Microsoft Dynamics NAV durch Properties oder Trigger geregelt werden. NAV extra zu dem Zweck vorgesehen, damit der Anwender die Eigenschaften sowie das Verhalten von Standardobjekten verändern kann, ohne den Standard zu modifizieren. Insofern könnte dieses Beispiel auch als so genannte Erweiterung betrachtet werden. Ausblenden nicht benötigter Felder Eingabefelder, die in einem Unternehmen überhaupt nicht benutzt werden, sollten hingegen ganz aus den Masken ausgeblendet werden, um die Mitarbeiter nicht unnötig zu verwirren. Über die Eigenschaft Visible (siehe Abb. 6.2-6 rechts oben, direkt über der Eigenschaft Enable) ließe sich im vorherigen Beispiel in Microsoft Dynamics NAV das Feld Name auch ganz aus der Maske ausblenden, in dem sein Wert auf No gesetzt wird. Beispiel Einsatz von Filtertechniken Mit Hilfe des Einsatzes von Filtertechniken lassen sich auch umfangreiche Datenbestände leicht auf die für einen Mitarbeiter relevanten Datensätze reduzieren. Hierdurch

240 6 Unternehmensspezifische Anpassungen * erübrigt sich ein umständliches und zeitaufwändiges Suchen im Gesamtbestand. Abb. 6.2-7: Schematische Darstellung der Definition eines Tabellenfilters für die Debitorenstammdaten in Microsoft Dynamics NAV. Beispiel Microsoft Dynamics NAV stellt eine ganze Reihe von unterschiedlichen Filtertechniken zur Verfügung (vgl. /Diffenderfer, El-Assal jr. 04, S. 27 ff. /), die auch vom Anwender ohne großen Aufwand eingerichtet werden können. In der Abb. 6.2-7 ist schematisch dargestellt, wie ein Tabellenfilter mit Hilfe der Liste aller Felder der Debitorentabelle definiert werden kann, der dem Anwender nur Debitoren aus dem spanischsprachigen Ausland anzeigt, deren Kreditlimit zwischen 10.000 und 50.000 Euro liegt. Fazit Die umfangreichen Möglichkeiten, die die meisten ERP-Systeme zur Personalisierung anbieten, sind bestens geeignet, die Bedienung der Software optimal an die Bedürfnisse bestimmter Benutzergruppen anzupassen. Hiervon sollte auch in jedem Fall Gebrauch gemacht werden, denn die hierdurch vorgenommene Reduktion der Komplexität führt nicht nur zu einem effizienteren Arbeiten mit dem System, sondern erhöht zudem die Akzeptanz bei den Anwendern. Dies setzt allerdings voraus, dass bei der Einführung eine entsprechend ausführliche Analyse der Anforderungen der unterschiedlichen Arbeitsplätze durchgeführt wurde. Dieser einmalige Aufwand macht sich bei der späteren produktiven Nutzung jedoch mehrfach bezahlt.

6.2 Weitere Anpassungsmöglichkeiten * 241 6.2.2 Eigenentwicklungen * Durch Eigenentwicklungen kann der Standard eines ERP-Systems weiter an die Anforderungen eines Unternehmens angepasst werden. Mit Hilfe von integrierten Entwicklungsumgebungen und deren Werkzeugen lassen sich eigene Programme und Objekte schnell und einfach erstellen, die nicht mit dem Standard kollidieren und daher eine unkritische Anpassungsmöglichkeit darstellen. Allerdings sollte aufgrund des hiermit verbundenen Aufwandes der Umfang von Eigenentwicklungen immer auch unter wirtschaftlichen Gesichtspunkten bewertet werden. Bietet ein ERP-System im Standard keine vergleichbare Funktionalität, die sich durch Maßnahmen des Customizings bzw. der Personalisierung an die Anforderungen des Kunden anpassen lässt, so bleibt nur die Möglichkeit, eine entsprechende Funktion selber zu entwickeln. Im Falle des»schlanken Standards«von Microsoft Dynamics NAV sind solche kundenindividuellen Eigenentwicklungen vom Hersteller fest vorgesehen, um die Anforderungen auch zu 100 Prozent abdecken zu können. Um jedoch in einem ERP-System selber entwickeln zu können, ist eine entsprechende Entwicklungsumgebung erforderlich, mit der sich die jeweiligen Applikationen und Objekte erstellen lassen. Die meisten ERP-Systeme verfügen daher über eine integrierte Entwicklungsumgebung. Mit ihrer Hilfe erfolgt sowohl die Entwicklung des Standards beim Hersteller, die Entwicklung von Branchenlösungen oder Add- Ons durch Softwarepartner als auch die Eigenentwicklung beim Kunden (siehe Abb. 6.2-8). vorgesehene Eigenentwicklungen integrierte Entwicklungsumgebung Beim Beispiel des SAP R/3-Systems ist dies etwa die ABAP TM Workbench, die eine Reihe von komfortablen Werkzeugen enthält, mit denen der Anwender auf einfache Art und Weise die unterschiedlichen Entwicklungsobjekte des R/3- Systems erstellen und bearbeiten kann. Zentraler Bestandteil neben dem Repository, in dem alle Programmobjekte verwaltet werden, ist die eigens von der SAP entwickelte Programmiersprache ABAP (Advanced Business App- Beispiele

242 6 Unternehmensspezifische Anpassungen * ERP-System eigenentwickelte Objekte des Kunden Personalwesen Finanzwesen Logistik Produktion Objekte von Softwarepartnern Standardobjekte Bereichsübergreifende Funktionen (z.b. Integrierte Entwicklungsumgebung) Abb. 6.2-8: Die integrierte Entwicklungsumgebung eines ERP-Systems stellt durch eigene Namensräume oder aber Nummernkreise die Abgrenzung von Standardobjekten zu Objekten des Kunden oder aber Partnern sicher. lication Language) /Matzke 99/. Auch Microsoft Dynamics NAV beinhaltet mit C/SIDE eine integrierte Entwicklungsumgebung, die zusammen mit den Applikationsobjekten von Microsoft Dynamics NAV in einem der folgenden Abschnitte noch näher vorgestellt wird (siehe»anpassung von Microsoft Dynamics NAV«(S. 250)). Style Guides Die integrierten Entwicklungsumgebungen sind jedoch nicht nur für individuelle Eigenentwicklungen des Kunden vorgesehen. Meist ist die komplette Anwendungslogik des ERP-Systems vom Hersteller in der gleichen Entwicklungsumgebung erstellt worden. Damit der Gesamteindruck einer integrierten Lösung auch bei Anpassungen durch Kunden oder Partnern erhalten bleibt, sollten sich deren Objekte nicht wesentlich von denen des Herstellers hinsichtlich des Programmierstils und der Oberflächengestaltung unterscheiden. Aus diesem Grund haben viele Hersteller so genannte Style Guides herausgegeben, in denen (verbindliche) Vorgaben für die Kunden (bzw. Partner) aufgeführt werden (sieheabb.6.2-9).inihnenwerdenetwadieimsystemanzuwendenden Namenskonventionen, Beschriftungen, Schriftarten und -größen oder die Ausrichtung von grafischen Objekten der Benutzeroberfläche beschrieben.

6.2 Weitere Anpassungsmöglichkeiten * 243 Abb. 6.2-9: Microsoft stellt seinen Kunden und Partnern in zwei Style Guides (verbindliche) Vorgaben für die Eigenentwicklung in Microsoft Dynamics NAV zur Verfügung. Damit die Eigenentwicklungen jedoch nicht mit dem Standard kollidieren, sind entsprechende Vorsichtsmaßnahmen zur Abgrenzung der unterschiedlichen Objekte zu treffen (siehe Abb. 6.2-9). Viele Hersteller haben dies durch die Definition von eigenen Namensräumen (Beispiel SAP R/3) oder Nummernkreisen (Beispiel Microsoft Dynamics NAV) realisiert, die sie für die Entwicklungsobjekte ihrer Kunden, aber auch ihrer Partner zur Verfügung stellen. Hierduch kann ausgeschlossen werden, dass es zu Konflikten mit den Standardobjekten kommt. Darüber hinaus bieten fast alle ERP-Systeme auch die Möglichkeit, externe Programme über Schnittstellen an den Standard anzubinden. Hierdurch können auch andere als die proprietären Programmiersprachen der Hersteller zum Einsatz kommen, was in Einzelfällen durchaus vorteilhaft sein kann. Allerdings wird hierdurch dem Ansatz einer integrierten Gesamtlösung entgegengewirkt. Die einfachen und komfortablen Möglichkeiten, ein ERP-System mit Hilfe der integrierten Entwicklungsumgebung auf Kundenwunsch zu erweitern, birgt jedoch auch gleichzeitig die Gefahr, dass es hierdurch zu einem»individuellen«standard kommt. Die Verlockung ist groß, bestehende Ab- Abgrenzung zu Standardobjekten Schnittstellen Gefahr:»individueller«Standard

244 6 Unternehmensspezifische Anpassungen * weichungen zwischen den Anforderungen eines Unternehmens und dem Standard eines ERP-Systems durch Anpassungen aufseiten des Programms vorzunehmen anstatt sich am Standard (Stichwort: Best Practice) zu orientieren und die Abläufe im eigenen Unternehmen zu verändern. Durch diese Individualisierung werden viele Vorteile der Standardisierung wieder aufgehoben. Drohen solche individuellen Entwicklungen gar Überhand zu nehmen, ist die generelle Frage der Einführung einer Standardsoftware als Alternative zu einer Individualsoftware (siehe»individual- oder Standardsoftware?«(S. 46)) gegebenenfalls neu zu überdenken! Fazit Da durch entsprechende Schutzmaßnahmen eine Abgrenzung der Eigenentwicklungen vom Standard gegeben ist, kann diese Anpassungsmöglichkeit eines ERP-Systems zunächst als unkritisch bewertet werden. Auch wenn die Werkzeuge der integrierten Entwicklungsumgebungen eine einfache und komfortable Programmierung ermöglichen, so sollte der Aufwand hierfür immer mit berücksichtigt und kritisch bewertet werden. All zu oft werden (kostspielige) Eigenentwicklungen betrieben, obwohl einige dieser Funktionen bereits durch neue Release-Stände im Standard abgedeckt werden (vgl. /Niemann 06/). Eine wohl überlegte Abwägung der jeweiligen Notwendigkeit unter Berücksichtigung der wirtschaftlichen Aspekte sollte daher auch bei Eigenentwicklungen immer erfolgen. 6.2.3 Modifikationen * Bei Modifikationen handelt es sich um programmtechnische Anpassungen, die mit Hilfe der integrierten Entwicklungsumgebung an den Standardobjekten eines ERP-Systems vorgenommen werden. Sie sind jedoch auf Grund der vielen Risiken und wirtschaftlichen Gefahren, die mit ihnen verbunden sind, als äußerst kritisch zu bewerten und nur in unumgänglichen Ausnahmefällen vorzunehmen.