U.-Plan.

EIS Controlling

Einkauf Disposition Wareneingang Rechnungsprfung Kreditorenbuchhaltung Lager

Marketing Verkauf Warenausgang Fakturierung Debitorenbuchhaltung

Haupt- und Anlagenbuchhaltung Kostenrechnung Personalwirtschaft

andelsstudien

Prof. Dr. Jrg Becker (Hrsg.)

Anpassung und Entwicklung von Warenwirtschaftssystemen eine explorative Untersuchung

Axel Winkelmann Ralf Knackstedt Oliver Vering

Anpassung und Entwicklung von Warenwirtschaftssystemen eine explorative Untersuchung

Handelsstudie Nr. 3 Mnster 2007

Dr. Axel Winkelmann

European Research Center for Information Systems (ERCIS) Leonardo-Campus 3 48149 Mnster winkelmann@ercis.uni-muenster.de 0251-8338086

Dr. Ralf Knackstedt

European Research Center for Information Systems (ERCIS) Leonardo-Campus 3 48149 Mnster knackstedt@ercis.uni-muenster.de 0251-8338086

Dr. Oliver Vering

Prof. Becker GmbH Ltke Berg 4-6 48341 Altenberge vering@prof-becker.de 02505-948311

Vorwort des Herausgebers

Durch unsere langjhrige Ttigkeit bei der Auswahl und Einfhrung von Unternehmenssoftware konnten wir zahlreiche Erfahrungen bei der Auseinandersetzung mit Standard- und Individualsoftware machen. Trotz der Mchtigkeit und Flexibilitt moderner Standardsysteme zeigen eigene Erfahrungen und Statistiken, dass die Einfhrung einer neuen Unternehmenssoftware nicht auf die leichte Schulter genommen werden sollte. Das Operieren am offenen Herzen ist fr viele Unternehmen ein groer Schritt, der viele Risiken beinhaltet, aber auch zahlreiche Mglichkeiten erffnet. IT ist heute in vielerlei Hinsicht nicht mehr aus den Unternehmen wegzudenken und viele Unternehmensstrategien, man denke nur an den Multi-KanalVertrieb oder die Just-in-Time-Belieferung, wren ohne moderne IT-Systeme wohl in dieser Form nicht realisierbar. Integrierte Unternehmensoftware leistet einen wichtigen Beitrag zur Wertschpfung von Unternehmen. Ohne diese wren moderne Produktionsfabriken ebenso wie Handelsfilialen mit schnelldrehender Ware kaum denkbar. Auf der einen Seite bedeutet dies, dass Informationen aller Art weltweit zum Abruf zur Verfgung stehen, auf der anderen Seite aber auch, dass die Abhngigkeit der Arbeitswelt gegenber Software zunimmt. Technologisch immer komplexere und betriebswirtschaftlich immer ausgefeiltere Systeme erhhen permanent die Anforderungen an die Software-Industrie. Das einfache Umstellen von alter auf neue Technologie ist nicht ohne weiteres mglich und bedeutet zahlreiche Kompromisse und Einschrnkungen, hufig ein vollstndiges Neuentwickeln von Architekturen oder der Gesamtsoftware. Es ist dabei kaum mglich, das gesteckte Ziel der vollkommenen Fehlerfreiheit und der allumfassenden Flexibilitt mit der Realitt bei der Entwicklung zu vereinbaren. Die Erstellung und Pflege von qualitativ hochwertiger Standardsoftware wird mit zunehmender Komplexitt der Software trotz gestiegener Leistungsfhigkeit der Entwicklungswerkzeuge im letzten Jahrzehnt eine immer grere Herausforderung. Anzeichen fr die zunehmende Heraus- und teilweise berforderung der Entwicklungshuser sind aus Sicht des Kunden mangelhafte Flexibilitt und Wartbarkeit in Bezug auf unterschiedliche Anforderungen, ungengende Integration der Teilmodule, schlechte Performance und ein verbesserbarer Releasezyklus. Hinzu kommen in einigen Projekten ein nur ungenaues Verstndnis von den Wnschen und Erfordernissen des Kunden, unerfahrene Berater oder Implementierer und widersprchliche Projektplanungen in Bezug auf die geforderte Funktionalitt und deren Entwicklungsqualitt.

Seit der Entwicklung der ersten Standardsoftwaresysteme in den 70er-Jahren haben sich Anforderungen, Systemen und Technologien stark weiterentwickelt. Funktions- und Datenintegration ist heute zur Kernanforderung geworden, die alle Unternehmensbereiche auch ber Landesgrenzen hinweg erfasst. Technologisch haben sich die Systeme vor allem in den letzten 10 Jahren stark verndert. Anforderungen durch das verteilte Aufsetzen von Systemen, das Internet und das Jahr2000-Problem haben viele Anbieter veranlasst, sich intensiv mit ihren Softwarearchitekturen auseinander zu setzen. Vor diesem Hintergrund entstand die Idee zu einer Studie zur Softwarequalitt von ERP- und Warenwirtschaftssystemen. Hierbei geht es nicht darum, mit wie auch immer gearteten Algorithmen die Lnge des Quellcodes oder die Anzahl an ffentlichen Klassen o. . zu eruieren. Vielmehr wollten wir einen Eindruck ber die Vielfltigkeit des Marktes und die unterschiedlichen Lsungskonzepte in verschiedenen Bereichen des Entwicklungsprozesses und der Softwarenutzung gewinnen und bieten. Wir wnschen Ihnen interessante Einblicke in und Erkenntnisse ber den State of the Art der Softwarequalitt von Warenwirtschafts- und ERP-Systemen. Bedanken mchten wir uns vor allem bei den zahlreichen Herstellern, die sich die Zeit genommen haben, gemeinsam mit uns die Daten fr diese Studie zusammenzutragen. Darber hinaus gilt unser Dank insbesondere den Studierenden des Instituts fr Wirtschaftsinformatik, namentlich Thorsten Bruns, Christian Halbig, Nils Kelleter, Andreas Krmberg, Oliver Liebsch und Lars Wetterling, die sich im Rahmen der Veranstaltung Empirische Forschung in der Wirtschaftsinformatik intensiv mit den Studieninhalten auseinandergesetzt haben und deren gewonnene empirische Erkenntnisse sich zum Teil in dieser Publikation wieder finden. Mnster, im Mai 2007 Prof. Dr. Jrg Becker

Inhaltsverzeichnis
Vorwort des Herausgebers ......................................................................................................... 4 Management Summary............................................................................................................... 7 1 2 3 Untersuchungsdesign.......................................................................................................... 9 berblick ber die ausgewerteten Systemen.................................................................... 10 Systemanpassung.............................................................................................................. 15 3.1 3.2 3.2.1 3.2.2 3.3 4 4.1 4.2 4.3 4.4 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 5 Allgemeine Erkenntnisse.......................................................................................... 15 Anpassung an individuelle Kundenbedrfnisse ....................................................... 17 Anpassung der Software durch den Hersteller ................................................. 17 Anpassung der Software durch Dritte .............................................................. 19 Messung der Kundenzufriedenheit........................................................................... 21 Entwicklungsaufwand .............................................................................................. 23 Entwicklungsparadigmen ......................................................................................... 24 Anforderungen an die und Probleme bei der System-Weiterentwicklung............... 25 Update- und Releasewechsel.................................................................................... 29 Dokumentation ......................................................................................................... 31 Allgemeines...................................................................................................... 31 Fach- und DV-Konzept .................................................................................... 32 Implementierung .............................................................................................. 34 Benutzerdokumentation.................................................................................... 36 Projektdokumentation ...................................................................................... 40

Systementwicklung .......................................................................................................... 23

Fazit .................................................................................................................................. 41

Management Summary
Integrierte Unternehmenssoftware leistet einen wichtigen Beitrag zur Wertschpfung von Unternehmen. Allerdings erhhen technologisch immer ausgefeiltere und betriebswirtschaftlich immer anspruchsvollere Systeme zunehmend die Erwartungen an die Software-Industrie. Individuelle, komplexe Anforderungen der Kunden an Standardsoftware und nach wie vor eine hohe Anzahl an Projekten, die aus welche Grnden auch immer nur begrenzt zufrieden stellend abgeschlossen werden, zeigen, dass das Potenzial noch nicht vllig ausgeschpft ist. Auf Basis von explorativen Experteninterviews wurden 27 Systemhersteller zu Themen der Softwarequalitt befragt. Knapp 90% der befragten Softwarehersteller entwickeln ihr System selbst, darber hinaus werden Fremdprodukte wie beispielsweise Buchhaltungssysteme ergnzend angeboten. Im Schnitt haben die Systemhersteller etwa 350 Kundeninstallationen, wobei die Spanne von 51.700 Systemen reicht. Die meisten Systeme finden sich vor allem in den Grenklassen 50250 Mitarbeiter. 63% der Hersteller bieten Named User-Preismodelle, 59% Concurrent-UserPreismodelle an. Der geschtzte Entwicklungsaufwand reicht laut Angaben der Hersteller von 12 bis hin zu mehreren tausend Entwickler-Mannjahren. Rund der Hersteller schtzten den Entwicklungsaufwand zwischen 20 und 150 Mannjahren. Technologisch finden sich neben einigen lteren Systemen vor 1995 bereits zahlreiche Neuentwicklungen mit neuen Architekturen. Die Mehrzahl der Systeme wird objektorientiert beispielsweise in Java oder C#, zunehmend auch in .Net entwickelt. Auch 4GL-Sprachen werden zur Entwicklung verwendet. Nur wenige Systeme sind auf einige oder wenige Branchen ausgerichtet. Die meisten Hersteller geben an, das System branchenunabhngig oder mit mittlerer Spezialisierung zu entwickeln. Dabei gehen einige Hersteller etwa mit einem Single-SourceAnsatz auf alle Kundenwnsche ein und realisieren diese im Standard. Alternativ werden einige Kundenmodifikationen, beispielsweise von Referenzkunden, in den Standard aufgenommen, sofern die Hersteller von Kundennderungen erfahren, was in 46% der Flle nicht mglich sein soll. Releasewechsel erfolgen in 56% der Flle in relativ kurzen Abstnden von unter einem Jahr, in 25% der Flle zwischen 1 und 3 Jahren. Dabei erfolgt die Umstellung beim Kunden meist mit Vorabsprache entweder ber einen Remotezugriff oder Vor-Ort, wobei in vielen Fllen nicht alle Releasewechsel vom Kunden akzeptiert werden mssen, ohne die Aktualisierungsmglichkeit des Systems zu gefhrden.

Viele Hersteller beschrnken ihre ausgelieferte Systemdokumentation auf das ntigste und arbeiten mit Online-Hilfen oder Support-Hotlines. Bei ber der Hlfte der ausgelieferten Dokumentationen findet jedoch keine Anpassung auf die Bedrfnisse des Kunden (eingeschrnkter, zur Verfgung stehender Funktionsumfang, Customizing des Standards) statt, obwohl eine generische Hilfe wenig zielfhrend bei der Lsung individueller Fragestellungen sein kann.

Untersuchungsdesign

Die Studie wurde auf Basis von explorativen Experteninterviews durchgefhrt, die zur intensiven Auseinandersetzung mit dem Thema Softwarequalitt bei Softwareherstellern im Warenwirtschaftsumfeld dienten. Dabei wurden standardisierte Fragen auf Basis eines Gesprchsleitfadens gestellt, deren Beantwortung ungesttzt, d. h. ohne Hinweis auf mgliche Antworten seitens des Interviewers, erfolgten. Ziel war es, einen mglichst breiten Eindruck ber die Softwarequalitt und Manahmen zur Sicherstellung der Softwarequalitt zu erhalten. Dabei sind insbesondere drei Einschrnkungen von besonderer Bedeutung. Erstens lsst die pro Interview zur Verfgung stehende Zeit nur einen begrenzten Einblick in die Thematik bei jedem Hersteller zu, zweitens ist die jeweilige Antwort trotz sorgfltiger Sicherstellung eines kompetenten Interviewpartners geprgt von der Funktion und Motivation des Experten. Es steht zu erwarten, dass ein vertrieblich geschulter Mitarbeiter eher geschnt ber sein System antworten wird, whrend ein Softwareentwickler detailliert Auskunft ber seinen Bereich geben kann und wird. Auch die Angst, dass relevante Informationen in die Hnde von Konkurrenten gelangen knnten, spielt sicherlich bei der einen oder anderen Auskunft eine Rolle. Zum Dritten bietet die qualitative, ungesttzte Befragung zwar einerseits durch eine Vielzahl an mglichen Antworten vielfltige Informationen ber die Thematik, behindert aber andererseits auch die Auswertung, da sich Antworten nicht ohne weiteres durch Zusammenzhlen verdichten lassen. Zustzlich enthlt die Studie daher Daten, die auerhalb der Telefoninterviews erhoben wurden. In einigen Fllen wollten aus fachlichen oder Konkurrenz-Grnden nicht alle Probanden eine Auskunft geben. In diesen Fllen wird die Anzahl an Ausknften, z. B. n=18, explizit angegeben. Insgesamt wurden 96 Systemhersteller im Vorwege der Befragung mit der Bitte um StudienTeilnahme und Nennung eines technisch leitenden Ansprechpartners via Email angeschrieben. Die Rcklaufquote betrug 32, wobei innerhalb des eng begrenzten Zeitraums insgesamt 27 Systemhersteller mit 28 Systemen fr Experteninterviews zur Verfgung standen. Die telefonische Befragung der im Vorwege informierten Experten fand innerhalb von zwei Monaten durch Interviewer des European Research Centers for Information Systems statt. Befragt wurde in Hinblick auf die fhrende Handels- bzw. WWS-Lsung, die durch das Unternehmen entwickelt wird.

berblick ber die ausgewerteten Systemen

Whrend in den 80er- und teilweise auch noch 90er-Jahren die Nachfrage nach Unternehmenssoftware sehr gro war und viele Anbieter respektable Einnahmen generieren konnten, findet aktuell eine Konsolidierung des Marktes statt. Schtzungen gehen davon aus, dass derzeit jhrlich in Deutschland etwa 2.000 bis 3.000 mittlere und grere Unternehmenssoftwarelsungen eingefhrt werden. Dagegen stehen mehr als 200-300 Anbieter nennenswerter Gre. Dieses berangebot kann mittelfristig zu einer weiteren Marktbereinigung fhren, zumal grere Anbieter versuchen, ihren Marktanteil durch Zukufe kleinerer Anbieter zu erhhen. Mittelstndische Hersteller positionieren sich daher vermehrt durch Kooperationen mit fhrenden WWS- bzw. ERP-Anbietern. Dabei setzt das mittelstndische Systemhaus mit seiner langjhrigen Domnenkompetenz auf einer marktfhrenden ausgereiften Basislsung auf, um beispielsweise parallel zur Eigenentwicklung eine SAP- oder Microsoft-Branchenlsung anzubieten. Auch die Kooperation zwischen mehreren, sich im Produktportfolio ergnzenden, Softwareherstellern ist ein mglicher Weg, sich erfolgreich am Markt zu positionieren. Einige Anbieter treten mit komplett neuen Lsungen auf, um dem Konsolidierungstrend entgegen zu wirken. Die untersuchten Systeme werden berwiegend von mittelstndischen Unternehmen entwickelt. Die Ausrichtung der Systeme reicht von Lebensmitteleinzelhandelslsung ber technischem Grohandel bis hin zu Anlagenbau und Fertigungsindustrie. Knapp 90% der Anbieter sind originre Softwarehersteller, die das ERP-System selbst entwickeln. Darber hinaus finden sich auch zertifizierte Systemintegratoren, die neben den eigenen Produkten Fremdprodukte mit anbieten, um z. B. das eigene Leistungsspektrum durch eine Finanzbuchhaltungssoftware zu ergnzen. Entsprechende Schnittstellen zwischen den Produkten sind zertifiziert und werden von beiden Systemherstellern bercksichtigt und weiterentwickelt. Andere Hersteller treten als Distributoren beispielsweise auslndischer Produkte auf dem heimischen Markt auf oder agieren als Lizenznehmen oder Vertriebspartner. Hierbei wird ein Groteil des Umsatzes durch den Verkauf und die Implementierung von Hersteller-Software (ggf. inklusive Add-Ons), entsprechende Schulungen und den After-Sales-Support gettigt (vgl. Abb. 1).

10

18 16 14 12 10 8 6 4 2 0 Zertifizierter Systemintegrator (ISV: Independent Software Vendor) Softwarehersteller Distributor Lizenznehmer/Vertriebspartner (VAR: Value Added Reseller)

Abb. 1: Rolle des Systemanbieters (n=18, Mehrfachnennungen mglich)

Unter Umstnden scheint die Einfhrung einer neuen Standardsoftware zu Beginn teurer zu sein als die vollstndige Eigenentwicklung. Allerdings machen sich auf Dauer Skaleneffekte durch die vielfache Nutzung durch mehrere Unternehmen sowie die funktionale Breite des Systems auch in den Entwicklungskosten bemerkbar, so dass eine Eigenentwicklung nur noch in wenigen Ausnahmefllen eine Alternative zur Einfhrung einer Standardsoftware sein sollte. Bei den Preismodellen der Hersteller kann zwischen dem Named User-Modell (14 von 22 Anbietern), bei dem jeder Nutzer bekannt ist und preislich verrechnet wird, und dem Concurrent-User-Modell (13 von 22 Anbietern) unterschieden werden. Hierbei wird nur die Anzahl tatschlich eingeloggter Nutzer berechnet. Lizenzmodelle in Abhngigkeit von Unternehmensgren (Umsatz, Mitarbeiteranzahl, Transaktionsvolumen) oder Mietmodelle auf ASP-Basis1 sind ebenfalls, wenn auch weniger gngige Varianten bei der Berechnung der Lizenzgebhren. Einzig die Verrechnung von ASP-basierter Software auf Transaktionsbasis wird von keinem der befragten Hersteller aktuell angeboten.

ASP = Application Service Providing, bei dem die Programme beim Anbieter zur Verfgung gestellt werden und der Kunde diese meist ber das Internet nutzt.

11

16 14 12 10 8 6 4 2 0 Lizenz in Abhngigkeit von Unternehmenskenngren (z.B. Umsatz, Mitarbeiterzahl, Transaktionsvolumen) ASP- / Transaktionsmodell Lizenz je Named User Lizenz je Concurrent User ASP- / Mietmodell

Abb. 2: Preismodelle der Hersteller (n=22, Mehrfachnennungen mglich)

Alle in der Befragung bercksichtigten Systeme erreichen das Kriterium Standardsoftware, das bei mindestens 3-5 Gesamtinstallationen zu sehen ist. Durchschnittlich sind rund 350 Installationen pro System zu betreuen, wobei die Spanne von 5 bis 1.700 Systemen reicht (vgl. Abb. 3).
Anzahl Kundeninstallationen 1800 1600 1400 1200 1000 800 600 400 200 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27

Abb. 3: Anzahl Kundeninstallationen der betrachteten Systeme (n=28)

Die untersuchten Systeme werden nach eigenen Angaben vor allem im Bereich typischer mittelstndischer Unternehmen (20 bis 500 Mitarbeiter) eingesetzt. Whrend fr den 12

Mittelstand relativ viele Systeme auf dem Markt zur Verfgung stehen, finden sich nur wenige ausgereifte Systeme fr Grounternehmen (vgl. Abb. 4).
20 18 16 14 12 10 8 6 4 2 0 1 bis 4 5 bis 9 10 bis 19 20 bis 49 50 bis 99 100 bis 250 bis 500 bis 249 499 999 > 999

Abb. 4: Grenklassen der analysierten Systeme (n=24, Mehrfachnennungen mglich)

Die aktuelle Architektur der berwiegenden Anzahl der Systeme wurde seit dem Jahrtausendwechsel entwickelt (43%). Nur sechs Systeme sind in ihrer grundlegenden Architektur laut Herstellerangaben lter als 10 Jahre (vgl. Abb. 5).
6 5 4 3 2 1 0 1 3 2 3 2 1 3 3 5 5

Abb. 5: Beginn der Entwicklung der jetzigen Architektur

22 Systemhersteller machten Angaben zu den zur Verfgung stehenden Sprachpaketen. Demnach sind alle Systeme in Deutsch verfgbar und knapp dreiviertel der Systeme auch in Englisch. 10 Systeme bieten ebenfalls franzsische Sprachpakete, knapp 5 jeweils auch andere europische Sprachen (vgl. Abb. 6) 13

25 Anzahl Warenwirtschaftssysteme

Deutsch

20

15

Franzsisch

Englisch Niederlndisch Tschechisch

Italienisch

Portugiesisch

Slowakisch

10

Spanisch

Polnisch

Ungarisch

Schwedisch

Norwegisch

Griechisch

Trkisch

Abb. 6: Untersttzte Sprachpakete (n=22 Systeme)

Die zur Verfgung stehenden Ansprechpartner waren im Durchschnitt etwa 10 Jahre im Unternehmen ttig. Nur zwei der Ansprechpartner waren 1-2 Jahre im Unternehmen ttig. Der betriebslteste Interviewpartner konnte auf rund 25 Jahre im Unternehmen zurckblicken. Die Ansprechpartner stammten im Regelfall aus der Geschfts- oder Entwicklungsleitung oder aus dem Produktmanagement mit technischem Hintergrund (vgl. Abb. 7).
10 9 8 7 6 5 4 3 2 1 0
eb ng en t ng g g on su ltin ar ke tin kt ve rt r i le itu it u em pm en t

9 8

5 3 1 1 1

le

it e rC

es ch

uk tm

bz w

Di re

lu

En tw ick

Pr od

eb

Abb. 7: Funktionen der Interviewpartner

14

Le ite

rV

Bu sin

er t ri

es s

Le

ev el o

an ag

fts

ng s

.M

Finnisch

Dnisch

Russisch

Systemanpassung

3.1 Allgemeine Erkenntnisse

Aufgrund des Anspruchs von ERP- und Warenwirtschaftssystemen, (fast) alle Geschftsprozesse im Unternehmen untersttzen zu wollen, stellen sie die Grundlage eines Konzepts zur Integration des gesamten betrieblichen Informationswesens dar. Die Forderung nach Standard impliziert dabei allerdings auch eine permanente, vorausschauende Weiterentwicklung der Software, um zum einen die derzeitigen funktionalen Bedrfnisse verschiedener Kunden abdecken zu knnen und zum anderen Weiterentwicklungen in den Branchen zu antizipieren. Funktionale Erweiterungen knnen entweder vom Hersteller langfristig aus strategischen Abwgungen heraus geplant oder durch Kundenprojekte getrieben werden. Neben den universell einsetzbaren Systemen werden hufig spezielle ERP- und WWS-Systeme auf die Besonderheiten bestimmter Branchen hin entwickelt (vgl. Abb. 8).
Hohe Spezialisierung 8%

Branchenunabhngig 42%

Mittlere Spezialisierung 50%

Abb. 8: Aktueller Spezialisierungsgrad der Systeme

Die meisten Systeme untersttzen mehrere Handelsformen wie den mehrstufigen Handel oder auch den zentral regulierten Handel (Einkaufsverbund) (vgl. Abb. 9).

15

25 22 20 14 13 19 17 15 16

10

0
de l ) nd el el un d el ro h an d Ha n Ex po r ,I m po rt u nd ha nd rb t

nz el ha

uf sv e

eh r

an de l

(E in

ie r te rH

Abb. 9: Handelsstufe bzw. Handelsform (Mehrfachnennungen mglich)

Auffallend bei den befragten Herstellern ist, dass sich nahezu alle Systeme aus einer Spezialisierung auf eine bestimmte Branche bzw. Funktionalitt heraus entwickelt haben (vgl. Abb. 10). Oftmals findet sich die Begrndung in der besonderen Domnenkompetenz der Firmengrnder. In zahlreichen Fllen wurde die Softwarefunktionalitt mit dem Ausreifen der angebotenen Funktionen auch auf andere Branchen ausgeweitet. Dabei wurde nicht der Sprung von der Lebensmitteleinzelhandelslsung zur Unternehmenslsung fr den Anlagenbau angestrebt, sondern vielfach die Ausweitung des Kundenpotenzials durch das Hinzufgen von Funktionalitt artverwandter Branchen.

16

Ze

nt ra

lr eg ul

Au

ss e

nh an de l

Ve rs an d

st uf ig er

Ei

ka

Abb. 10: Beispiel fr Branchen- bzw. Handelsformspezialisierung (n=17)

3.2 Anpassung an individuelle Kundenbedrfnisse

3.2.1 Anpassung der Software durch den Hersteller
Im Regelfall werden heute in den Anwenderunternehmen alte durch neue Systeme ersetzt, auch wenn gerade bei Kleinunternehmen integrierte Unternehmenssoftware erstmalig eingefhrt wird. Es gilt, Altsysteme, die teilweise ber Jahrzehnte (individuell) entwickelt wurden, abzulsen und effizientere Strukturen entlang der Mglichkeiten eines neuen Systems einzufhren.

17

Tendenziell lsst sich ein Trend zu Single-Source-Lsungen feststellen. Aufgrund der Gre und Komplexitt des Softwarecodes sind Softwarehersteller bemht, Kundenanforderungen nicht in einem eigenen Branch des Codes umzusetzen, sondern diese unmittelbar in den Standard aufzunehmen. Nur zwei der befragten Hersteller lehnen explizit eine unmittelbare Aufnahme von Kundenmodifikationen in den Standard ab, so dass die Kundenmodifikationen zunchst als individuelle Systemerweiterung realisiert werden mssen. 17 Hersteller bieten zumindest an, einige Kundenmodifikationen in den Standard mit aufzunehmen, und 9 Hersteller realisieren Kundenanforderungen direkt im Standard. Der Vorteil fr den Kunden liegt insbesondere in der verlsslichen Wartbarkeit des Systems bei Updates und Upgrades begrndet. Nicht Kunde sondern Hersteller hat im Falle eines neuen Releases dafr Sorge zu tragen, dass die durch Kundenanforderung in den Standard eingeflossene Funktionalitt auch weiterhin reibungslos funktioniert.
18 16 14 12 10 8 6 4 2 0 bernahme aller Kundenanforderungen bernahme einiger Kundenanforderungen Keine bernahme von Kundenanforderungen 2 9 17

Abb. 11: Grad der unmittelbaren bernahme von Kundenanforderungen in den Standard

Rund die Hlfte aller Systemauslieferungen erfolgt ohne Reduzierung des Funktionsumfangs. Der Kunde erhlt somit die Gesamtfunktionalitt zur Verfgung, nur 18% der Befragten gaben an, dass die Systemfunktionalitt immer reduziert wrde (vgl. Abb. 12).

18

14%

18%

4% 4%

Immer 95% 85% 60% Nie Keine Angabe

4%

56%

Abb. 12: In wie viel Prozent der Auslieferungen wird die Gesamtfunktionalitt auf die vom Kunden gewnschte reduziert?

Bei der Beschreibung der technischen Vorgehensweise kamen je nach Systemarchitektur unterschiedliche Methoden zum Einsatz. Einige Anbieter nannten explizit eine Modularisierung der ERP-Architektur, so dass bei der Auslieferung einzelne Systemteile weggelassen werden knnen. Andere Anbieter arbeiten mit Lizenzkeys fr individuelle Module, Konfigurationsdateien oder individuellen Benutzerfreigaben. Auch verschiedene Parametrisierungsanstze und Vorkonfigurationen wurden genannt (vgl. Abb. 13).

Abb. 13: Technische Realisierung der Gesamtfunktionalittsreduktion

3.2.2 Anpassung der Software durch Dritte

Insbesondere bei greren Systemen knnen kundenindividuelle nderungen direkt durch die Kunden oder Dritte vorgenommen werden. Hierzu bieten einige Hersteller an dafr vorgesehenen Stellen User Exits, mit deren Hilfe Anwender in der Lage sind, Funktionalitt hinzuzufgen, ohne die Releasefhigkeit der Kundeninstallation zu gefhrden.

19

Wenn Kunden oder Drittanbieter nderungen an der Software, etwa durch funktionale Erweiterungen, vornehmen, ist es ggf. notwendig, dass der Hersteller von diesen nderungen erfhrt, um einerseits Anregungen der Kunden in die eigene Produktentwicklung aufzunehmen und andererseits die Entwicklungen des Kunden zu bercksichtigen, um auch seine Releasefhigkeit grtmglich sicher zu stellen. Einige Anbieter haben fr das ndern des Codes durch den Kunden Markierungen vorgesehen, die vom Kunden gesetzt und vor einem Update vom Softwarehersteller ausgelesen werden. Andere Anbieter bieten den Kunden die Mglichkeit, eigene Bibliotheken hinzuzufgen. Die Kunden drfen in diesen Fllen aber keine nderungen am Standard vornehmen. Je nach Softwarearchitektur ist es laut einzelnen Anbietern teilweise auch mglich, die Darstellungsschicht zu bearbeiten, ohne den Hersteller informieren zu mssen oder die Releasefhigkeit zu gefhrden. In einigen wenigen Fllen ist die Anpassung nicht mglich bzw. nur ber das Softwarehaus selbst realisierbar.
keine Angabe 11% automat. Auslesen von nderungen nicht mglich 46% formelles Vorgehen 18%

informeller Kontakt 18%

Abb. 14: Wie Softwarehersteller ber Modifikationen durch Kunden oder Fremdanbieter erfahren

Insbesondere Anbieter, die nicht selbst implementieren, sondern dieses durch Vertragspartner durchfhren lassen, haben informelle Kanle etabliert, um ber Vernderungen des Standards informiert zu werden. Ein Anbieter berichtete auch ber eine Extranet-Community-Lsung, in der externe (Lizenz-)Partner ihre Erfahrungen im Customizing und der individuellen Anpassung hinterlegen knnen, so dass allen Beratern und vor allem den Softwareentwicklern eine Wissensplattform zur Verfgung steht. Abb. 14 listet auf, wie Softwarehersteller derzeit ber Modifikationen von Kunden oder Drittanbietern erfahren. 20

3.3 Messung der Kundenzufriedenheit

Die Kundenzufriedenheit ist ein wichtiger Indikator fr die funktionale Erfllung der Vorstellungen des Kunden. Prinzipiell sollten Mae folgende Eigenschaften besitzen, um sinnvoll verwendet werden zu knnen: Einfachheit: Das Ma muss mit geringem Aufwand werden knnen. Eignung: Das Ma muss hinreichend mit der zu messenden Eigenschaft korreliert sein (auch: Validitt). Stabilitt: Das Ma muss gegenber marginalen nderungen stabil sein. Rechtzeitigkeit: Das Ma muss zu einem Zeitpunkt messbar sein, zu dem noch auf Messwerte reagiert werden kann. Reproduzierbarkeit: Das Ma muss przise formuliert sein und nicht auf subjektiven Einschtzungen beruhen. Analysierbarkeit: Das Ma muss einen Skalentypen haben, der es ermglicht, die Messwerte statistisch zu analysieren. Die Definition von Kundenzufriedenheit ist von Hersteller zu Hersteller unterschiedlich. Ingesamt lassen sich sechs Merkmale finden, die in der Literatur auch als Softwarequalittsmerkmale gefhrt werden: Funktionalitt: Dieses Qualittsmerkmal bezeichnet die Erfllung der Anforderungen des Pflichthefts. Als Einzelaspekte werden Richtigkeit, Angemessenheit, Interoperabilitt, Ordnungsmigkeit und Sicherheit genannt. Zuverlssigkeit: Unter diesem Qualittsmerkmal versteht man, dass die Software fr eine bestimmte Zeit auf einem bestimmten System fehlerfrei luft. Als Einzelaspekte werden Reife, Fehlertoleranz und Widerherstellbarkeit bzw. Verfgbarkeit und Korrektheit genannt, wobei sicherlich die Unterscheidung im Rahmen der Kundenzufriedenheit irrelevant ist, solange das System funktioniert. Benutzbarkeit: Damit wird der Aufwand, der zur Benutzung der Software notwendig ist, benannt. Die Einzelaspekte sind Verstndlichkeit, Erlernbarkeit und Bedienbarkeit. Effizienz: Darunter wird die Verwendung von Hardwareressourcen und der Zeitaufwand fr die Ausfhrung der Funktionalitt verstanden.

21

nderbarkeit: Unter diesem Merkmal versteht man die Mglichkeiten, die Software fr Fehlerbehebung oder Anpassungen zu verndern. Einzelne Aspekte dabei sind Analysierbarkeit, Modifizierbarkeit, Stabilitt und Prfbarkeit.

bertragbarkeit: Die Mglichkeit Software fr den Betrieb in verschiedenen Umgebungen anzupassen. Einzelne Aspekte dabei sind Anpassbarkeit, Installierbarkeit, Konformitt (Standardisierung) sowie Austauschbarkeit. Auerdem wird noch Skalierbarkeit angefhrt.

Darber hinaus spielen fr die Kundenzufriedenheit auch Aspekte wie Service und Erreichbarkeit des Softwareunternehmens, Preise oder Flexibilitt bei neuen Anforderungen eine groe Rolle. Leider ist bei den vielen befragten Herstellern derzeit noch kein strukturiertes Vorgehen bei der Messung der Zufriedenheit festzustellen (vgl. Abb. 15). Einige Hersteller nennen jhrliche Besuche vor Ort und Usergroups als Grundlage fr die Qualittsmessung. Andere Unternehmen fhren nach eigenen Angaben jhrlich Kundenzufriedenheitsbefragungen durch.
Explizite Befragung des Kunden Kundenbefragung mittels Fragebogen (zumeist jhrlich) Persnliche Besuche beim Kunden (zumeist jhrlich) Anwendertage Regelmige E-Mail-Befragung (inkl. Nachtelefonieren) Analyse der geschftsmigen Kundenkontakte Auswertungen von Fehlermeldungen, Beschwerden, Reklamationen Beurteilung der Hflichkeit des Kunden Erhebung von Weiterempfehlungen durch den Kunden Beurteilung von Folgeprojekten beim Kunden Heranziehung externer Expertenmeinungen Heranziehung von Marktstudien Analyse externer Rankings

Abb. 15: Manahmen zur Messung der Kundenzufriedenheit

Im Regelfall wird jedoch versucht, die Kundenzufriedenheit indirekt ber die Anzahl an Neuauftrgen, Weiterempfehlungen und von der Service-Abteilung geschilderten Problemfllen abzuleiten. Dabei greift u. E. insbesondere die ausschlieliche Messung der Anzahl an Strungsmeldungen fr das Erfassen der Kundenzufriedenheit zu kurz. Hier besteht bei den meisten Herstellern auch nach deren eigenen Angaben Nachholbedarf. Symptomatisch ist beispielsweise, dass trotz der gern angefhrten Aussage des schnellen Return on Investment der Software-Einfhrung der tatschlich beim Kunden erbrachte Nutzen fast nie systematisch erfasst, sondern nur gefhlt ermittelt wird. 22

Systementwicklung

4.1 Entwicklungsaufwand
Allgemein ist in Literatur und Unternehmenspraxis der Aufwand fr die Entwicklung von Unternehmenssoftware kontrr diskutiert. Nicht nur IT-fremde Personen, beispielsweise aus dem Management, neigen dazu, die Entwicklungsdauer zu unterschtzen. Auch Entwicklungsabteilungen verkennen hufig die Komplexitt von Softwareentwicklungen, was sich auch in zahlreichen Kundenprojekten durch verzgerte Einfhrungen und verschobene Updatetermine bemerkbar macht. Problematisch ist dieses dadurch, dass sich die Softwareentwicklung durch weitere Entwicklungsressourcen nicht beliebig beschleunigen lsst. Der Output bei einer Verdopplung der Entwicklermannschaft ist leider nicht doppelt so hoch und ist im Gegenteil durch die Einarbeitung neuer Kollegen am Anfang hufig sogar kontraproduktiv. Dadurch lassen sich auch die Grenunterschiede in den Entwicklungsmannschaften erklren. Whrend einer der befragten Anbieter als Alleinentwickler (!) ein durchaus konkurrenzfhiges und vielfach eingesetztes System entwickelt hat, knnen groe Anbieter mit einer im Regelfall zwei- oder dreistelligen Anzahl an Entwicklern (in Ausnahmefllen auch fnfstelligen Anzahl) aufwarten. Bei der Schtzung der in die Entwicklung eingeflossenen Entwicklermannjahre reichen die Angaben der befragten Unternehmen von 12 Mannjahren bis hin zu mehreren tausend Mannjahren fr Grosysteme. Genauere Schtzungen machten 18 der 28 befragten Hersteller. Rund 3/4 dieser Systemhersteller gaben etwa 20 bis 150 Mannjahre fr die Entwicklung ihrer derzeitigen Software an, einige sogar Entwicklermannjahre im deutlich drei- oder vierstelligen Bereich (vgl. Abb. 16). Eine genaue Auswertung der Zahlen ist aufgrund der unterschiedlichen Sichtweise in Bezug auf die eingeflossenen Mitarbeiteraufgaben sowie die ein oder andere gezielt geschnte Zahl sicherlich nicht mglich. Dennoch ist der hohe Aufwand an eingeflossenen Mitarbeiterjahren fr Handel und Industrie ein sicherer Beleg fr die betriebswirtschaftliche Fragwrdigkeit von Individualentwicklungen.

23

1200 1100 1000 900 800

Mannjahre

700 600 500 400 300 200 100 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Abb. 16: Schtzung des Entwicklungsaufwands fr das eigene Standardsystem in Mannjahren (n=18)

Zahlreiche Systemhersteller haben inzwischen mit ihren Architekturen auf die Kundenwnsche nach mobilem Zugriff auf Unternehmensdaten reagiert. Rund 60% der Hersteller bieten einen Zugriff auf Daten ber Windows-PDAs, weitaus weniger Hersteller auch ber PDAs mit Palm-OS und andere Gerte (vgl. Abb. 17).
16 14 12 10 8 6 4 2 0 PDA (Windows) Mobiltelefon Symbian-basiertes PDA (Palm-OS) Gert Blackberry

Abb. 17: Untersttzte Gerte fr mobile Anwendungen (n=26, Mehrfachnennungen mglich)

4.2 Entwicklungsparadigmen
Entwicklungsparadigmen sind stets von der Kultur eines Entwicklungshauses und der zu Beginn der Entwicklung bzw. zu Beginn der Definition einer Architektur vorherrschenden Softwareentwicklungsansicht geprgt. Vielfach werden gerade bei mittelstndischen Softwareunternehmen nachfolgende Architekturen und Programmiersprachen nach dem Knnen des vorhandenen Mitarbeiterstamms ausgewhlt. Ein Softwareunternehmen, das seit vielen Jahren 24

mit Microsoft-Technologie arbeitet, wrde vermutlich bei einer Neuentwicklung nicht auf Java-Technologie setzen, sondern auf Microsofts .Net. Bei einigen Softwareunternehmen werden neuere technische Anforderungen durch Aufsetzen von z. B. EAI-Add-Ons auf alten Softwaremodulen realisiert. Dieses bietet die Mglichkeit, moderne Anforderungen auch bei lteren Systemen zumindest eingeschrnkt zu realisieren. Parallel zu diesem Vorgehen entwickeln einige Softwareunternehmen auf der grnen Wiese an einem neuen System, das in einigen Jahren mit gleichem Funktionsumfang die bestehende Lsung abwickeln wird.2 Das lteste in der Studie betrachtete System stammt aus der Mitte der 80er-Jahre. Der berwiegende Anteil wurde seit dem Ende der 90er-Jahre entwickelt und ist damit von der Architektur her auf einem relativ modernen Stand. Ein Hauptteil der betrachteten Systeme wird objektorientiert in Java oder C# bzw. .Net entwickelt, wobei Java gegenber anderen objektorientierten Sprachen aktuell bevorzugt wird.
25 20 15 10 5 0 Objektorientiert (bspw. Java, C#) 4GL (bspw. Gupta, ABAP) Prozedural (bspw. Cobol, C) 10 6

21

Abb. 18: Verwendung von Programmierparadigmen (Mehrfachnennung mglich)

4.3 Anforderungen an die und Probleme bei der SystemWeiterentwicklung

Die Weiterentwicklung des Standards wird bei allen Herstellern auf der einen Seite von den Kunden, auf der anderen Seite vom Markt vorangetrieben. Whrend es zum Ende der 90erJahre architektonisch vor allem einen Weiterentwicklungsdruck durch das Jahr-2000-Problem gab, fordern heute neue technische und architektonische Mglichkeiten wie der Zugriff ber das Internet oder Service Oriented Architectures (SOA) bzw. Web Services die Aufmerksamkeiten der Entwickler. Auch funktional stellen technische Neuerungen und ein Ausweiten des Kundenkreises permanent neue Anforderungen an die Softwareentwicklung.

Diese Aussage bezieht sicht nicht konkret auf die an der Studie teilgenommenen Hersteller, sonder spiegelt unseren Eindruck ber den ERP-/WWS-Gesamtmarkt wider.

25

Der Entscheidungsprozess bei der Weiterentwicklung eines Systems ist laut Angabe der im Experteninterview befragten Hersteller bis auf einige wenige Ausnahmen grundstzlich strukturiert und erfolgt im Regelfall zumindest bei den greren Herstellern nicht ad hoc (vgl. Abb. 19).

Abb. 19: Entscheidung ber Produkterweiterungen

Bei der Entscheidung, welche neuen Funktionalitten und Anforderungen jhrlich in das Standardsystem aufgenommen werden sollen, entstammen in einer Mehrzahl der Unternehmen rund 50% der neuen Funktionalitt direkt aus Kundenanforderungen und 50% aus den allgemeinen, langfristigen Weiterentwicklungszielen. Allerdings zeigt die Untersuchung eine breite Streuung dieses Verhltnisses unter den befragten Unternehmen (vgl. Abb. 20).
8 7 6 5 4 3 2 1 0 0 0-5% 0 2 2 1 0 96100% 2 1 5 5 7

6-15% 16-25% 26-35% 36-45% 46-55% 56-65% 66-75% 76-85% 86-95%

Abb. 20: Prozentualer Anteil der jhrlich in den Systemstandard neu hinzugefgten Funktionalitt, die im Gegensatz zu generellen Weiterentwicklungen auf unmittelbaren Kundenanforderungen zurckzufhren ist (n=25 Systeme)

26

Die befragten Hersteller ziehen neben dem Fachwissen von Anwenderunternehmen vor allem das Wissen der eigenen Mitarbeiter aus Entwicklung, Vertrieb und Helpdesk heran und analysieren den Markt beispielsweise bei Messen und Tagungen. In einigen Fllen stammt ein Groteil des Wissens von sogenannten Referenzkunden, deren Anforderungen in besonderem Mae in das Produkt einflieen und die im Gegenzug sehr stark internes Wissen fr die Softwaregestaltung zur Verfgung stellen. Auch neue Ergebnisse aus der Forschung werden fr die Weiterentwicklung herangezogen. Dabei haben allerdings nur wenige, grere Unternehmen eine eigene Forschungsabteilung, in der sie Ideen im Rahmen von EU- oder Bundesforschungsprojekten vorantreiben.3 Meist wird in Kooperation mit Hochschulen oder anderen Forschungseinrichtungen je nach Themengebiet gemeinsam geforscht, oder es werden relevante Forschungsergebnisse aus Fachbchern und wissenschaftlichen Publikationen fr eigene Zwecke ausgewertet. Nur rund ein Drittel der Softwareunternehmen greift bei der Entwicklung auf Best PracticeCases oder Referenzmodelle zurck, was zum einen an einer mangelnden Awareness zum anderen aber auch an der nur in geringem Umfang zur Verfgung stehenden Anzahl an ffentlichen Modellen liegen mag.
keine Angabe; 11%

ja; 36%

nein; 53%

Abb. 21: Nutzung von Referenzmodellen und Best Practice-Anstzen (n=28)

Generell ist die Wartbarkeit und Weiterentwicklung von komplexer Software immer mit Problemen versehen. Dies kann auf der einen Seite technische Ursachen in Form veralteter Programmiersprachen oder -paradigmen haben, auf der anderen Seite aber auch funktionale Ursachen. Hufig ergeben sich durch neue betriebswirtschaftliche Anforderungen und Funktionen
3

An dieser Stelle sei der Hinweis erlaubt, dass seit Anfang 2007 das 7. Rahmenprogramm der EU zahlreiche attraktive Frderungsmglichkeiten fr innovative, mit hohem Forschungsanteil zu erbringende Software entwicklungen in der Kombination Wirtschaft und Wissenschaft bereithlt. Das European Research Center for Information Systems (ERCIS) steht Ihnen als wissenschaftlicher Partner und Frderungsberater gern bei der Umsetzung Ihrer Ideen zur Seite.

27

Vernderungen in der Datenbankstruktur, die dann wiederum zu technischen nderungen u. a. im Quellcode fhren. Zwar lsst sich generell ein Trend zu einer eigenen Datenhaltungsschicht konstatieren, doch hufig genug verstecken sich Datenbankabfragen auch an verschiedenen Stellen im Quellcode. Probleme bei der funktionalen Erweiterung tauchen laut den befragten Herstellern vor allem bei der Konzepterarbeitung, dem Know-How-Transfer und der Releasefhigkeit der Software auf. Das unterschiedliche Verstndnis von Kunde, Vertriebs- oder Servicemitarbeiter und dem anschlieend realisierenden Anwendungsentwickler fhren dazu, dass Funktionalitt im Standard nicht so abgebildet wird, wie er vom Kunden gewnscht wird. Der hohe Standardisierungsgrad vieler Softwaresysteme fhrt darber hinaus zu einer Vielzahl an Prozessablufen, die konsistent gehalten werden mssen. Tendenziell sind die an die Entwicklung gestellten Anforderungen grer als die dafr zur Verfgung stehenden Ressourcen, so dass funktionale Erweiterungen nicht im gewnschten Umfang oder auf die gewnschte Art und Weise realisiert werden. Ein Hersteller gab die Einarbeitungszeit fr neue Entwickler aufgrund der Komplexitt des Systems und dem notwendigen Verstndnis fr die betriebswirtschaftlichen Prozesse mit bis zu einem halben Jahr an, was die kurzfristige Erweiterung eines Entwicklungsteams sehr erschwert. Auch Altlasten aus altem, nicht mehr wartbaren oder schlecht dokumentiertem Code fhren hufig zu Problemen oder unntigem zustzlichen Entwicklungsaufwand. Weiterhin wnschten sich zahlreiche Hersteller ausgereifte Tools zum automatischen Testen und performantere Entwicklungsumgebungen. Dieses gilt auch fr die Software selbst, denn trotz der Leistungsfhigkeit moderner Computersysteme kmpfen einige Hersteller nach wie vor mit Performanceproblemen in der Entwicklung und der anschlieenden Implementierung bei den Kunden. Diese Performanceprobleme betreffen sowohl Altsysteme, die bereits seit lngerer Zeit weiterentwickelt werden, als auch neue Systeme, die mit modernen Architekturen und Objektorientierung aufwarten. Die groe funktionale Breite der von Kunden an Standardsoftware gestellten Anforderungen stellt nicht nur die Kunden, sondern auch zahlreiche Hersteller vor eine Herausforderung in Bezug auf das dafr notwendige (internationale) betriebswirtschaftliche Know-How. Software-Zertifizierungen nach den Grundstze zum Datenzugriff und zur Prfbarkeit digitaler Unterlagen (GDPdU) und den Grundstzen ordnungsmiger Buchfhrung (GoB bzw. GoBS) ermglichen dem Kunden, sich auf eine HGB-konforme Software verlassen zu

28

knnen. Einige der in von der Prof. Becker GmbH in zahlreichen Beratungsprojekten untersuchten Systeme wiesen auch in Hinblick auf das deutsche Steuerrecht Mngel auf.

4.4 Update- und Releasewechsel

Updates bezeichnen generell eine Versionsaktualisierung, die Programmmngel beseitigt oder kleinere Programmverbesserungen beinhaltet. Ein Upgrade oder ein Releasewechsel bezeichnet hingegen das Anbieten einer neuen Version mit greren funktionalen und ggf. technologischen nderungen. 9 Hersteller gaben an, in relativ kurzen Zyklen von weniger als einem Jahr ein neues Release auf den Markt zu bringen. 4 Hersteller planen eher mit mittleren Zyklen von 1-3 Jahren und 3 Hersteller operieren mittel- bis langfristig, bieten jedoch auch regelmige Patches an (vgl. Abb. 22).
mittlere / lngere Zyklen zzgl. regelmiger Patches 19%

mittlere Zyklen (1-3 Jahre) 25%

kurze Zyklen (< 1 Jahr) 56%

Abb. 22: Lnge der Releasewechselzyklen (n=15)

Bei Update- und Releasewechseln sind prinzipiell Softwareunternehmen im Vorteil, die ihren Kunden keine Modifikationen ermglichen oder diese direkt in den Standard einflieen lassen. Vielfach ist diese Vorgehensweise jedoch nicht mglich, so dass sich die Frage stellt, wie der Versionswechsel am konomischsten vollzogen werden kann. Rund ein Viertel der befragten Softwarehersteller nannte User Exits als gngige Variante, um Kundenanpassungen zu ermglichen, ohne die Releasefhigkeit der eingesetzten Version zu gefhrden. Allerdings stehen User Exits nur an den dafr vorgesehenen Stellen zur Verfgung, so dass unvorhergesehene nderungswnsche des Kunden stets wieder zu einem Eingriff in den Standard fhren. Vor allem nderungen des Datenbankschemas knnen zu hoher Komplexitt fhren, weswegen einige Hersteller Anpassungen in diesem Bereich entweder nicht erlauben oder einen speziellen Tabellenbereich fr nderungen vorgesehen haben.

29

Keiner der befragten Systemhersteller nannte stichtagsbezogene Releasewechsel als Option fr ein Hochziehen des beim Kunden installierten Systems. Stattdessen erfolgen Umstellungen nach Vereinbarungen entweder durch Vor-Ort-Prsenz beim Kunden oder durch einen Remote-Zugriff auf das System des Kundens (vgl. Abb. 23).
12 10 11

10

2 0 Stichtagsumstellung, Remote Umstellung nach Vereinbarung, Umstellung nach Vereinbarung, On-Site Remote

Abb. 23: Wie werden Releasewechsel durchgefhrt (n=15, Mehrfachnennung mglich)

ber 80 Prozent der Softwarehersteller bieten ihren Kunden einen Wartungsvertrag an, der auch das Hochziehen auf eine neue Version sowie entsprechende Patches beinhaltet (vgl. Abb. 24). Da dieses Hochziehen mitunter sehr komplex und somit risikoreich bzw. kostenintensiv sein kann, bietet sich fr Anwender eine Mglichkeit, das Risiko ber diese Vertragsoption abzusichern. Dennoch geben einige Hersteller an, dass zahlreiche Kunden die zustzlichen Kosten fr diese Vertragsoption scheuten.

nein; 5

ja; 23

Abb. 24: Wartungsvertrag bietet auch das Hochziehen auf neuen Releasestand an

30

Hufig hinken Kundeninstallationen der aktuellen Releaseplanung des Softwareherstellers hinterher. Dieses kann zum einen monetre Grnde haben und andererseits auch auf zeitliche Restriktionen oder Softwareindividualisierungen zurckzufhren sein, bei denen ein Releasewechsel zu zeitaufwndigen berprfungen der einzelnen Programmmodule und vor allem der Benutzeroberflche Vor-Ort fhren wrde. Daher ist es aus Kundensicht sinnvoll, Release-Stnde berspringen zu knnen, um z. B. nur bei sicherheitskritischen Updates und neuen Versionsnummern die Software aktualisieren zu mssen. Alle antwortenden Hersteller (n=14) gaben an, dass es mglich wre, Release-Stnde zu berspringen. 57% der Hersteller nannten sogar keine Begrenzungen beim berspringen von Releasestnden (vgl. Abb. 25).

1-2 Release-Stnde 7%

3-4 Release-Stnde 36% keine Begrenzung 57%

Abb. 25: Wie viele Releasestnde knnen beim Releasewechsel bersprungen werden (n=14)

4.5 Dokumentation
4.5.1 Allgemeines
Es gibt eine Reihe von Grnden, die zeigen, warum eine gute Dokumentation wichtig ist: Strukturierungs- und Planungshilfe: Dokumentationen vereinfachen und strukturieren den Prozess der Softwareentwicklung, vor allem knnen jedoch auch Erfahrungswerte aus den Dokumentationen vergangener Projekte gewonnen werden und die Dokumentation des aktuellen Projektes wird den zuknftigen Projekten dienen. Rechtliche Bestimmungen: Der Gesetzgeber sieht mangelnde Dokumentation als Sachmangel an. Somit ist jeder Softwarehersteller verpflichtet eine ausreichende Dokumentation zu liefern. Bei komplexen Softwareprojekten wird die Dokumentation sogar als Hauptleistungspflicht eingestuft. Auch der Gesetzgeber forderthier eine Art 31

Benutzer-, System- und Projektdokumentation. Im Falle einer Insolvenz des Softwareherstellers oder sonstiger Unmglichkeit der Weiterentwicklung des Systems hat der Kunde das Recht auf den Quellcode und eine Dokumentation des Entwicklungsprozesses. Im Grunde bleibt aber das Motto: Wo kein Klger, da kein Richter, es sollte aber nicht auer Acht gelassen werden, dass der Kunde einen rechtlichen Anspruch auf solche Dokumentationen hat. Verkaufsfrderung: Eine gute Dokumentation kann auch ein Marketinginstrument sein, welches man nicht unterschtzen sollte. So vermittelt z. B. ein Benutzerhandbuch oftmals den ersten Eindruck eines Systems, den Anwender oder sogar Kaufentscheidungstrger des Kunden bekommen. Bei groen StandardsoftwareSystemen kann es durchaus vorkommen, dass die Benutzerdokumentation ihren Weg ber Dritte zum potentiellen Kunden gefunden hat, bevor berhaupt ein Mitarbeiter des Softwarehauses Kontakt zu den Kunden hatte. Wartung des Softwaresystems: Unter Wartung eines Softwareproduktes wird die Nachbesserung und die Anpassung an neue Umgebungsbedingungen verstanden. Diese nimmt in der Regel einen groen Teil des Aufwandes des gesamten Projektes in Anspruch. Eine gute Dokumentation vereinfacht diese und senkt somit den Zeit- und Kostenaufwand der Wartung. Fr die (Weiter-)Entwicklung eines Softwaresystems sollte eine ausreichende Systemdokumentation im Rahmen der Konzeption und Implementierung, eine Benutzerdokumentation sowie eine Projektdokumentation des individuellen Projektes erstellt werden.

4.5.2 Fach- und DV-Konzept

Die konzeptionelle Modellierung vor Beginn der eigentlichen Implementierung soll die bewusste Abstraktion von der eigentlichen Implementierung und der Strukturierung der betriebswirtschaftlichen Anforderungen dienen. Wenngleich eine uerst strikte und konsistente Unterteilung nach ARIS in Fachkonzept, DV-Konzept und tatschliche Implementierung in dieser Form wohl nur in den seltensten Fllen angewendet wird, kommt der Modellierung dennoch insbesondere bei greren Projekten eine wichtige Aufgabe zu. Moderne Anstze im Rahmen der Model Driven Architectur versuchen sogar, als Modell spezifizierte Sachverhalte teilautomatisiert in Softwarecode zu berfhren, so dass eine strkere Sicherstellung der Konsistenz von Fachkonzept und Implementierung gegeben ist. Traditionell lsst sich Modellierung unterteilen in Daten-, Funktions- und Prozessmodellierung.

32

Das konzeptionelle Datenmodell beschreibt alle relevanten Objekte des zu betrachtenden Systems und die Beziehungen zwischen diesen, wofr sich das Entity-Relationship-Modell (ERM) ebenso wie die Unified Modeling Laguage (UML) gut eignet. Entsprechende Modelle knnen leicht in ein relationales Datenbankschema berfhrt werden, und es knnen umgekehrt aus den Datenbankschemata auch wieder Modelle generiert werden. Zur Modellierung der Funktionen auf Fachkonzept-Ebene bieten sich die

Funktionsdekompositionsdiagramme an. Hier wird eine Funktion im Baum dargestellt und durch Kindknoten, die Unterfunktionen bilden, genauer spezifiziert. Die Spezifizierung wird so lange fortgefhrt, bis auf unterster Ebene nur noch Elementarfunktionen vorliegen, die sich nicht mehr in Unterfunktionen aufteilen lassen. Ein Vorteil dieser Dokumentationsform ist, dass das Funktionsmodell in den Kontext des DV-Konzeptes berfhrt werden kann. Dazu wird aus jeder Funktion ein Modell erstellt. Zur Prozessmodellierung bieten sich verschiedene Mglichkeiten, die alle auf dem Konstrukt von gerichteten Graphen beruhen. Es gibt z. B. die Mglichkeit der Modellierung mit Ereignisgesteuerten Prozessketten (EPK) oder Petri-Netzen. EPK besitzen den Vorteil der hheren Anschaulichkeit und knnen je nach Fragestellung besser interpretiert werden, weswegen diese auch in groen Einfhrungsprojekten beispielsweise beim SAP-Einfhrungsprojekt der Bundeswehr zum Einsatz kommen. Alle interviewten Hersteller von Warenwirtschaftssystemen dokumentieren in der Designphase in irgendeiner Form die umzusetzenden Anforderungen (vgl. Abb. 26). Hufig genannt wurden Daten- und Prozessmodelle. Die Modellierung von Datenmodellen erfolgt hauptschlich in UML und zu einem geringeren Teil in ERMs. Alle Unternehmen, die konkrete Modellierungssprachen erwhnten (16 Unternehmen), nutzen eine Form von UML fr das Design von Anforderungen. Vier Unternehmen gaben an, auch oder hauptschlich ER-Modelle zu nutzen. Fr die Modellierung werden teilweise recht einfache Tools wie Powerpoint, Excel oder Word genutzt. Eine etwas standardisiertere Variante, die bei rund einem Viertel der befragten Unternehmen eingesetzt wird, ist Microsoft Visio, mit dem sich in kleinerem Umfang sowohl Prozess- als auch Datenmodelle direkt oder mit einem Aufsatz wie Process4Biz erstellen lassen. Einige grere Entwicklungshuser nutzen Tools der Entwicklungsumgebungen oder setzen professionelle Modellierungswerkzeuge wie ARIS oder Rational Rose ein.

33

Abb. 26: Dokumentationsformen

4.5.3 Implementierung
Die Dokumentation der Implementierung besteht erstens aus Programmierrichtlinien, die es dem Entwickler erleichtern sollen, im Sinne der existierenden Software zu entwickeln. Zweitens sollte ber Testflle und Richtlinien zum Testen eine Formalisierung des Testens stattfinden, um Fehler frhzeitig zu erkennen und zu beseitigen. Um die konsistente und effiziente Weiterentwicklung zu gewhrleisten, sollten drittens entsprechende Entwicklungsdokumentationen vorliegen und eine Versionsverwaltung eine Weiterentwicklung aber auch Rckverfolgung von Codeproblemen sowie Wiederherstellung von alten Zustnden ermglichen. Programmierrichtlinien drcken sich zum einen in der Art der Programmierung aus und beschreiben u. a., wo welcher Code abgelegt werden soll. Zum anderen bieten diese Formalisierungen der Benutzerschnittstelle. Sogenannte Styleguides sind wichtige Grundlage fr die konsistente Entwicklung der Benutzschnittstelle durch mehrere Entwickler. Sie vermitteln ergonomische Grundlagen und kommunizieren die Grundidee eines Projekts. Hufig dienen sie den Entwicklern als Nachschlagewerk fr konkrete Gestaltungsfragen.4 Typische Fehler bei der Entwicklung eines Styleguides sind die Nicht-Einbeziehung von Entwicklern und Benut-

Beispiele fr Styleguides finden sich z. B. bei Apple (http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelin es.pdf) oder IBM (http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/1387/$File/IBM_Style.pdf).

34

zern, so dass es zu Akzeptanzproblemen kommt, sowie die zu groe Detaillierung, so dass der Styleguide fr die eigentlichen Zwecke nicht mehr angemessen ist. Testprotokolle beschreiben den funktionalen Softwaretest auf elementarer Ebene. Damit soll die zugesicherte Eigenschaft eines Testobjekts berprft werden. Die Beschreibung von Testfllen enthlt im Regelfall die Bedingungen, die zum Testen erfllt sein mssen, die Vorgehensweise bzw. die Eingaben, die zur Durchfhrung des Testfalls notwendig sind, die erwartete Ausgabe sowie die Nachbedingungen, die als Ergebnis erzielt werden. Ein Testprotokoll umfasst im Idealfall einen Testplan fr den Integrationstest und den Abnahmetest, einen Testplan fr jede Systemkomponente, fr jede separat getestete Systemkomponente eine Dokumentation der Testumgebung, eine Protokollierung der ausgefhrten Testflle sowie eine Protokollierung der ausgefhrten Schwachstellenanalyse. Systemdokumentationen und Versionierungen dienen der Weiterentwicklung des Systems. Diese Dokumentation umfasst alle Einzelheiten des Aufbaus eines Softwaresystems sowie die Struktur der einzelnen Komponenten. Sie sollte alle Informationen enthalten, die zum besseren Verstndnis der Implementierung notwendig sind. Viele, aber nicht alle der befragten Anbieter geben an, mit Formalisierungen fr die Entwicklung zu arbeiten, um die Konsistenzsicherung zu gewhrleisten. Im einfachsten Fall handelt es sich um Testflle, die bei einem neuen Release zu durchlaufen sind. Teilweise sind aufwendige Styleguides bei der Entwicklung zu beachten, die entweder vom Unternehmen selbst oder bei Lizenzierung der Basissoftware von einem Groanbieter von diesem vorgegeben werden. Rund 10% der Hersteller nannten explizit ein eigenes Framework oder entsprechende Templates, die die grafische Konsistenz der GUI sicherstellen. Nur ein Hersteller verwies bei der ungesttzten Frage auf den internationalen Standard ISO 9241, der explizit Hilfestellung bei der Entwicklung der eigenen Softwareergonomie anbietet. Er trifft u. a. bei der Definition der Benutzerschnittstelle Aussagen zur Aufgabenangemessenheit, Selbstbeschreibungsfhigkeit, Steuerbarkeit, Erwartungskonformitt, Fehlertoleranz, Individualisierbarkeit und Lernfrderlichkeit. Die Testflle und Testablufe sind bei einigen Anbietern relativ ausfhrlich ausgearbeitet, whrend andere Anbieter hier unstrukturierte Tests durchfhren. In nahezu jedem Fall sind die Entwickler selbst in die Tests eingebunden. Hinzu wurden bei rund 2/3 der Befragten auch das Qualittsmanagement bzw. hauptberufliche Tester und Consultants hinzugezogen. In etwa der Hlfte der Flle wurden auch Kunden zu den Tests hinzugezogen, wobei hier meist eine

35

Alpha-Phase im Hause durchlaufen wird und vor dem groen Rollout eine Beta-Phase bei einem oder wenigen Kunden erfolgt.
30 25 20 15 10 5 0 ext. Fachexperten Entwickler Consultants Support Kunden QM/haupt. Tester Sonstige

Abb. 27: Beteiligte an systematischen Tests (n=28; Mehrfachnennungen mglich)

Mit Ausnahme von zwei Herstellern nutzen alle befragten Unternehmen zur Codeverwaltung und -archivierung Versionsverwaltungssoftware. Ein Viertel der Hersteller hat berraschenderweise ein selbstentwickeltes Versionssystem im Einsatz. Knapp 20% nutzen ein CVS-Derivat. Die brigen Hersteller setzen u. a. Softwaretools von Microsoft (Visual SourceSafe), SAP (SAP Solution Manager), IBM (Rational Clear Case) oder Perforce ein.

4.5.4 Benutzerdokumentation
Die Benutzerdokumentation steht den Anwendern des Systems als Hilfestellung zur Verfgung. Sie dient nicht nur fr Informationen im laufenden Betrieb, sondern auch zum Einlesen oder Kennenlernen des Programms. Eine gute Benutzerdokumentation sollte folgende Teile umfassen: Die funktionale Beschreibung soll das System charakterisieren. Der Leser soll ber Voraussetzungen, Strken, Schwchen und den Zweck, wozu er das System nutzen kann, informiert werden. Auerdem sollte sie die Struktur und den grundlegenden Aufbau des Systems erklren. Eine Installationsanleitung erklrt, wie das System zu installieren ist und wie es auf die Hardwareumgebung (z. B. Client-Server-System) eingestellt wird. Ein einfhrendes Handbuch dient zum Einarbeiten in das System und sollte zusammen mit der funktionalen Beschreibung dem Leser eine Entscheidungshilfe geben, ob das 36

System fr seine Bedrfnisse geeignet ist. Das Einfhrungshandbuch zeigt die normale Verwendung des Systems durch eine Reihe von illustrierten Beispielen auf. Der Leser sollte auf den Stil des Programms in der Benutzerinteraktion eingestellt werden. Zum Beispiel sollte der grundstzliche Aufbau von Dialogen oder die Menfhrung dargestellt werden. Das Referenzhandbuch ist das wichtigste Dokument der Benutzerverwaltung. Es stellt eine vollstndige Beschreibung aller Funktionen im System dar. Die wichtigsten Eigenschaften des Referenzhandbuches sind die Vollstndigkeit und die Gliederung, die dem Leser ein leichtes Auffinden bestimmter Beschreibungen ermglichen. In der Regel wird das Referenzhandbuch im laufenden Betrieb benutzt, wobei die Funktionsbeschreibungen im Handbuch direkt ausprobiert werden. Die gute Strukturierung geht hierbei vor der Lesbarkeit, da im Referenzhandbuch nur kleine Bereiche ohne Pause gelesen werden. Die Operator/Administrator-Anleitung dient den Administratoren oder Key-Usern als Hilfe bei bestimmten Ttigkeiten, mit denen der normale Anwender nicht in Berhrung kommt. Bei groen Systemen wird es immer solche Funktionen geben. So sind z. B. in der Regel nur einige wenige Personen fr die Benutzerverwaltung verantwortlich. Alle diese Teile der Benutzerdokumentation knnen je nach Gre des Systems in einem Handbuch zusammengefasst oder getrennt ausgeliefert werden. Erwartungsgem stellen alle befragten Hersteller ihren Kunden eine Dokumentation der Funktionalitt in Form eines Benutzerhandbuchs zur Verfgung. Diese wird als gedruckte Version oder aufgrund aktuellerer Informationen, niedrigeren Kosten und dauerhafter Verfgbarkeit online bereitgehalten. Online-Dokumentationen finden sich als PDF-Handbcher, Turnkey-Help (zeigt aus dem Programm das gesamt Hilfesystem), Direkt-Hilfe oder eingebettete Hilfe. So genannte HilfeAgenten wie die Broklammer in Microsoft-Office versuchen interaktiv, die Bedrfnisse des Benutzers zu antizipieren und eine kontextabhngige Hilfe anzubieten. Teilweise gehen die Hersteller dazu ber, die Anleitungen nicht ber die gesetzlichen Anforderungen hinaus mit auszuliefern, sondern die bentigte Funktionsbeschreibung fr den Anwender auf eigenen Servern in der jeweils bentigten Version anzubieten. Einige Hersteller bieten den Kunden direkt Schulungsunterlagen an, hufig werden diese jedoch erst mit Schulungsbedarf individuell fr den Kunden zusammengestellt, oder eine Schulung erfolgt interaktiv durch interne oder

37

externe Consultants. Nur rund ein Drittel der Anbieter liefert laut eigenen Angaben Datenmodelle an die Kunden aus, ein Fnftel auch Prozessmodelle (vgl. Abb. 28).
30 25 20 15 10 5 0 Schulungsunterlagen Handbuch (online und/oder gedruckt) Prozessmodelle, dokumentation Datenmodelle

Abb. 28: An den Kunden weitergegebene Dokumente (n=28, Mehrfachnennungen mglich)

Der berwiegende Teil der Anbieter (knapp 60%) beschrnkt seine Dokumentation nicht auf die vom Kunden gewnschte Funktionalitt. Stattdessen wird hier nicht zuletzt aus Marketinggrnden die vollstndige Funktionalittsbeschreibung ausgeliefert, so dass der Kunde erkennen kann, welche Mglichkeiten das System auerhalb des im eigenen Haus genutzten Spektrums bietet. Ausnahmen bestehen teilweise, wenn modulweise dokumentiert wurde und die Kunden nur einzelne Module erwerben. Nur wenige Anbieter nannten technische Probleme bei der theoretischen Anpassung der Dokumentation. Vor allem kontextsensitive Hilfen wurden in den Vordergrund gerckt.
keine Angabe 21%

keine Einschrnkungen 58% Einschrnkungen 21%

Abb. 29: Individuelle Anpassung der Dokumentation

Im Nachgang unserer ersten Umfrage haben wir nochmals alle 27 Teilnehmer unserer Studie (ein Teilnehmer hatte sein bisheriges Unternehmen verlassen) per E-Mail zu ihrer Meinung 38

hinsichtlich der Abstimmung zwischen Dokumentation und Systemfunktionalitt befragt. Ein Drittel hat unseren kurzen E-Mailfragebogen beantwortet. Die generelle Idee eines Variantenmanagementkonzepts, das die an den Kunden ausgelieferte Dokumentation an die kundenspezifische Systemvariante anpasst, wurde von allen Antwortenden befrwortet. 89% von ihnen konnten sich vorstellen, ein solches Variantenmanagementwerkzeug fr die eigenen Entwicklungsprozesse einzusetzen. Nur ein Antwortender konnte sich den Einsatz eines solches Ansatzes fr die ERP-Systementwicklung seines Unternehmens nicht vorstellen. Wir fragten auch nach der Wahrscheinlichkeit der Anwendung eines Variantenmanagementansatzes fr die Systemdokumentation in Abhngigkeit von dem zustzlichen Aufwand, der damit verbunden sein wrde. Um die Konsistenz zwischen System- und Dokumentationsvarianten zu erhhen, wren die meisten Antwortenden bereit, genauso viel Aufwand zu investieren, wie die Dokumentation gegenwrtig erfordert (vgl. Abb. 30).
Wrden Sie einen Variantenansatz fr die Dokumentation verwenden, wenn es die Stimmigkeit der Dokumentation verbessern und es bedeuten wrde:
deutlich weniger Aufwand (<50% des heutigen Aufwands)

gleich viel Aufwand (100%)

sehr viel mehr Aufwand (>150%) 0% 20% 40% 60% 80% 100%

Abb. 30: Einsatzbereitschaft eines Variantenmangementansatzes fr die Systemdokumentation (n=9)

Wir vermuten, dass der hohe preisliche Wettbewerbsdruck die Akzeptanz einer signifikanten Erhhung des Dokumentationsaufwandes zugunsten einer besser mit den Systemen abgestimmten Dokumentation begrenzt. Die verschiedenen Konsequenzen, die mit Mngeln in der Abstimmung von Softwaresystem und Dokumentation verbunden sind, legen allerdings nahe, neben den Kosten der Dokumentation auch den Nutzen einer erhhten Dokumentationsqualitt in die Analyse mit einzubeziehen (vgl. Abb. 31).

39

Abb. 31: Konsequenzen mangelhafter Abstimmung von Funktionalitt und Dokumentation

4.5.5 Projektdokumentation
Nach DIN 69901 wird unter der zu einem Projekt zugehrigen Projektdokumentation die Zusammenstellung ausgewhlter, wesentlicher Daten ber Konfiguration, Organisation, Mitteleinsatz, Lsungswege, Ablauf und erreichte Ziele des Projektes verstanden. Damit werden Bezugskonfiguration, Pflichtenheft, Projektberichte und Projektabschlussbericht zur Projektdokumentation gezhlt. Existiert ein Projektbuch (Projekthandbuch), kann dieses direkt in die Projektdokumentation berfhrt werden. Viele der befragten Hersteller betreiben in irgendeiner Form eine Dokumentation der einzelnen Projekte, um Informationen ber Kundenmodifikationen zu erhalten. Ein Anbieter erwhnte explizit, dass der Kunde zwar nderungen an der Datenbasis, nicht jedoch am Softwarecode vornehmen knne, er aber im Grunde nichts von den Modifikationen erfhre. Teilweise wird die Dokumentation der Projektmodifikation so denn ein strukturiertes Vorgehen vorhanden ist sehr formalisiert vorgegeben und in Projektabschlussdokumenten vorgehalten.

40

Fazit

Die explorative Studie zeigt, dass der Markt fr WWS und ERP in stndiger Bewegung ist. Der hohe Entwicklungsaufwand fr moderne Unternehmenssoftware ist ein Indikator dafr, dass eine Individualentwicklung heute hufig kein gangbarer Weg fr die meisten Anwendungsunternehmen ist. Stattdessen bieten Standardsysteme viele Individualisierungsmglichkeiten abseits eines starren Standards. Der berraschend aktuelle Systemzustand in Bezug auf verwendete Programmier- und Architekturkonzepte der befragten Systemhersteller zeigt, dass die Hersteller neuen Trends und Anforderungen durchaus positiv gegenber stehen und diese zgig in ihren Systemen realisieren. Allerdings lsst dieses Ergebnis auch vermuten, dass nur Hersteller mit aktuellen Softwarearchitekturen auf unsere Interviewbitte reagiert haben und das Ergebnis somit nur einen Teil des Marktes reprsentiert. Dieses wurde bei der explorativ angelegten Studie bewusst in Kauf genommen, da sie als Einstieg fr weitere Studien des Instituts gesehen wird, die mit grerer Systemanzahl und standardisierter Befragungsmethode einen reprsentativen berblick ber den WWS-Markt liefern sollen. Unser Dank gilt den beteiligten Softwareherstellern, uns bei diesem Einstieg zu untersttzen, indem Sie zu den angesprochenen Themen Auskunft gegeben haben.

41

Buchempfehlung

Jrg Becker, Oliver Vering, Axel Winkelmann

Softwareauswahl und -einfhrung in Industrie und Handel Vorgehen bei und Erfahrungen mit ERP- und Warenwirtschaftssystemen

Die Auswahl und Einfhrung von Unternehmenssoftware in Industrie und Handel ist komplex, und es ist schwierig, die bersicht zu behalten und alle Details zu beachten. Hunderte von Anbietern prsentieren ihre Systeme auf Messen und in Fachzeitschriften, so dass die Auswahl des bestgeeigneten Systems schwer fllt. Die Autoren geben Empfehlungen zum idealen Vorgehen bei der Marktsichtung sowie bei der Auswahl und Einfhrung des Wunschsystems. Dabei gehen sie u. a. auch auf Fragen der Rechtfertigung fr und die Kontrolle bei der Einfhrung neuer Software ein und setzen sich mit der rechtlichen Frage von Gebrauchtlizenzen und der bilanziellen Bewertung von Softwareeinfhrungen auseinander. Die einzelnen Kapitel bauen sachlich aufeinander auf und verschaffen einen hervorragenden Einblick in das Vorgehen bei der Auswahl und Einfhrung der Software. Beispiele aus namhaften Unternehmen runden die Thematik ab. Springer Verlag 2007, 291 Seiten. 44,95 Euro ISBN: 978-3-540-47424-1 42

European Research Center for Information Systems (ERCIS) Leonardo-Campus 3 48149 Mnster Tel.: 0251 / 8338-100 http://www.ercis.uni-muenster.de

Prof. Becker GmbH Ltke Berg 4-6 48341 Altenberge Tel.: 02505 / 9483-0 http://www.prof-becker.de

42