Kernaufgaben und Vorgehensmodelle in der IV-Beratung.

Kernaufgaben und Vorgehensmodelle in der IV-Beratung.

Forschungsberichte zur Unternehmensberatung - Reports on Consulting Research - Herausgegeben von Prof. Dr. Volker Nissen Volker Nissen, Christina Si...

478KB Sizes 0 Downloads 4 Views

Recommend Documents

Zum Begriff der Kernaufgaben des Staates
Kurt Heller. Zum Begriff der Kernaufgaben des Staates. In: Staat und Recht in europäischer Perspektive, Festschrift fü

Informationswirtschaft II Vorgehensmodelle der - Michael Hahsler
Informationswirtschaft 2. Inhaltsverzeichnis. 1. Begriffsdefinition. 2. Nutzen von Vorgehensmodellen. 3. Anwendung und C

BCBS 239 Umsetzung - Status Quo und Vorgehensmodelle - SAS
Unique Function Library. CF. PV. Unique Parameter Library. PD. LGD ..... intelligence/content/landing_pages/bcbs239?utm_

4. Vorgehensmodelle 4.1 Phasen der Software-Entwicklung 4.2
Grobdesign. Feindesign. Implemen- tierung. Test und. Integration. Prototyp .... Kent Beck, Mike Beedle, Arie van Benneku

Klassische und agile Vorgehensmodelle Ein historischer Überblick
B.; Jones, Kevin D.; Lindsay, Peter A.; Moore, Richard: mural. ... [WJR91] Womack, James P.; Jones, Daniel T.; Roos, Dan

Vorgehensmodelle des Product-Service Systems - Semantic Scholar
Marc Gräßle, Oliver Thomas, Michael Fellmann, Julian Krumeich. 2032 erhöhen .... und Kundenakzeptanz sowie auf Ergebn

Der Graupapagei in der Freiheit und in der - Forgotten Books
in MaDeira unD auf Den Ganarifchen. Snfeln D raupapageien für 20 Marf Da? D tücf angeboten wurDen. D ei Der Slnfunft e

Welche Kernaufgaben hat eine Gemeinde zu erfüllen? - Fohnsdorf
29.09.2013 - Erscheinungsort 8753 Fohnsdorf, Ausgabe 2/September 2013 Folge 128. GEMEINDE. ZUHAUSE. Welche Kernaufgaben

Theorie und Praxis der Erwachsenenbildung in der
4 Vgl. Kim, Yung-Jae: Der Protestantismus in Korea und die calvinistische ..... 29 Vgl. Kim, Byung-Seo: Gae-Sin-Kyo-Reul

Antibiotikaeinsatz und Resistenzentwicklung in der Human- und
Smith TC., Gebreyes WA, Abley MJ, Harper AL, Forshey BM, Male, MJ, … Davies .... County-Ebene zu verteilen und die Ver

Forschungsberichte zur Unternehmensberatung - Reports on Consulting Research -

Herausgegeben von Prof. Dr. Volker Nissen

Volker Nissen, Christina Simon Kernaufgaben und Vorgehensmodelle in der IV-Beratung

Forschungsbericht Nr. 2009-01, August 2009

Technische Universität Ilmenau Fakultät für Wirtschaftswissenschaften, Institut für Wirtschaftsinformatik Fachgebiet Wirtschaftsinformatik für Dienstleistungen (WI-2)

Autoren: Volker Nissen, Christina Simon Titel: Kernaufgaben und Vorgehensmodelle in der IV-Beratung. Forschungsberichte zur Unternehmensberatung Nr. 2009-01, 1. Aufl., August 2009 Technische Universität Ilmenau, FG Wirtschaftsinformatik für Dienstleistungen ISSN 1862-1805 ISBN 978-3-938940-23-5 urn:nbn:de:gbv:ilm1-2009200143 © 2009

FG Wirtschaftsinformatik für Dienstleistungen, TU Ilmenau

Dieses Material ist urheberrechtlich geschützt.

Anschrift:

Technische Universität Ilmenau, Fakultät für Wirtschaftswissenschaften, Institut für Wirtschaftsinformatik, PF 100565, D-98684 Ilmenau. http://www.tu-ilmenau.de/fakww/Forschungsberichte_z.1664.0.html

-i-

Inhaltsverzeichnis

Abbildungsverzeichnis ..................................................................................................... 4 Tabellenverzeichnis .......................................................................................................... 5 Abkürzungsverzeichnis .................................................................................................... 5 1

Grundlagen ............................................................................................................... 6 1.1

IV-Beratung als Form der Unternehmensberatung............................................ 6

1.2

Kernaufgaben der IV-Beratung......................................................................... 9

1.2.1

Software-Auswahl ...................................................................................... 9

1.2.2

Software-Einführung ................................................................................ 10

1.2.3

IT-Architektur........................................................................................... 11

1.2.4

IT-Sicherheit............................................................................................. 14

1.2.5

IT-Integration............................................................................................ 15

1.2.6

IT-Strategie............................................................................................... 16

1.2.7

IT-Organisation ........................................................................................ 16

1.2.8

IT-Outsourcing ......................................................................................... 17

1.3 2

3

Vorgehensmodelle ........................................................................................... 18

Empirische Untersuchung....................................................................................... 20 2.1

Ausgangspunkt und Forschungsfragen der Untersuchung .............................. 20

2.2.

Datengrundlage und Methodik der empirischen Untersuchung ..................... 21

2.2.1

Stichprobenauswahl.................................................................................. 21

2.2.2

Interviewdurchführung ............................................................................. 23

2.2.3

Interviewauswertung ................................................................................ 24

Vorgehensmodell der Software-Auswahl............................................................... 25 3.1

Allgemeines zum Vorgehensmodell ................................................................ 25

3.2

Phasen des Vorgehensmodells......................................................................... 31 -1-

4

5

3.2.1

Erste Phase: Projektinitiierung ................................................................. 31

3.2.2

Zweite Phase: Potentialanalyse ................................................................ 34

3.2.3

Dritte Phase: Anforderungsdefinition....................................................... 36

3.2.4

Vierte Phase: Vorauswahl ........................................................................ 36

3.2.5

Fünfte Phase: Ausschreibung ................................................................... 38

3.2.6

Sechste Phase: Angebotsbewertung ......................................................... 39

3.2.7

Siebte Phase: Software-Präsentation ........................................................ 41

3.2.8

Achte Phase: Endauswahl......................................................................... 43

3.2.9

Neunte Phase: Vertrag .............................................................................. 44

Vorgehensmodell der Software-Einführung........................................................... 46 4.1

Allgemeines zum Vorgehensmodell ................................................................ 46

4.2

Phasen des Vorgehensmodells......................................................................... 51

4.2.1

Erste Phase: Projektinitiierung ................................................................. 51

4.2.2

Zweite Phase: Konzeption (einschließlich Anforderungsanalyse)........... 53

4.2.3

Dritte Phase: Realisierung ........................................................................ 55

4.2.4

Vierte Phase: Test..................................................................................... 57

4.2.5

Fünfte Phase: Produktivvorbereitung ....................................................... 59

4.2.6

Sechste Phase: Produktivstart (Go-Live) und Support ............................. 60

Modellentstehung und -handhabung in der Beratungspraxis ................................. 61 5.1

Hintergrund ...................................................................................................... 61

5.2

Entstehung der Vorgehensmodelle ................................................................. 62

5.2.1

Entwicklungszeitpunkt bzw. bisheriger Einsatzzeitraum......................... 62

5.2.2

Ursprung ................................................................................................... 63

5.2.3

Motivation ................................................................................................ 64

5.3

Handhabung der Vorgehensmodelle............................................................... 67

5.3.1

Regeln der Anwendung seitens des Beratungshauses .............................. 67

—2—

6

5.3.2

Einsatz in Beratungsprojekten .................................................................. 68

5.3.3

Dokumentation ......................................................................................... 69

5.3.4

Wissensmanagement ................................................................................ 70

5.3.5

Zertifizierung ............................................................................................ 71

5.3.6

Evaluierung und Weiterentwicklung ........................................................ 73

5.3.7

Relevanz für die Projektgewinnung ......................................................... 74

5.3.8

Publikation der Vorgehensmodelle .......................................................... 78

Fazit ........................................................................................................................ 80

Literaturverzeichnis ........................................................................................................ 81 Anhang: Leitfaden-Fragebogen der empirischen Untersuchung.................................... 87

—3—

Abbildungsverzeichnis

Bild 1: Übersicht IT-Architektur ................................................................................... 12 Bild 2: Tätigkeitsschwerpunkte der betrachteten Beratungsunternehmen ..................... 23 Bild 3: Vorgehensmodell der Software-Auswahl........................................................... 27 Bild 4: Phasen der Software-Auswahl in den Vorgehensmodellen der untersuchten Beratungshäuser ..................................................................................................... 28 Bild 5: Vorgehensmodell der Software-Einführung....................................................... 47 Bild 6: Phasen des Software-Einführungs-Prozesses in den Vorgehensmodellen ......... 48 Bild 7: AcceleratedSAP Roadmap ................................................................................. 49 Bild 8: Anwendungsdauer der Vorgehensmodelle ........................................................ 63 Bild 9: Ursprung der Vorgehensmodelle........................................................................ 63 Bild 10: Motivation für Entwicklung und Einsatz von Vorgehensmodellen ................. 65 Bild 11: Anwendung der Vorgehensmodelle nach Unternehmensgröße ....................... 68 Bild 12: Dokumentation der Vorgehensmodelle nach Unternehmensgröße .................. 69 Bild 13: Zertifizierung der Vorgehensmodelle............................................................... 72 Bild 14: Evaluierung der Vorgehensmodelle ................................................................. 73 Bild 15: Relevanz der Vorgehensmodelle für die Projektgewinnung ............................ 75 Bild 16: Relevanz der Vorgehensmodelle nach ausgewählten Beratungsfeldern ......... 77 Bild 17: Publikation der Vorgehensmodelle nach Unternehmensgröße ........................ 79

—4—

Tabellenverzeichnis

Tabelle 1: Merkmale von Strategieberatung und IV-Beratung ....................................... 8 Tabelle 2: Samplestruktur............................................................................................... 22 Tabelle 3: Übersicht der untersuchten Beratungsfelder je Unternehmen....................... 22

Abkürzungsverzeichnis

ASAP

AcceleratedSAP

BDU

Bundesverband Deutscher Unternehmensberater BDU e.V.

ERP

Enterprise-Resource-Planning

HW

Hardware

IT

Informationstechnologie

ITIL

IT Infrastructure Library

IV

Informationsverarbeitung

PPS-System

Produktionsplanungs- und Steuerungssystem

SOA

Service-orientierte Architektur

UB

Unternehmensberatung

—5—

Zusammenfassung: In der vorliegenden Untersuchung wird auf empirischer Basis zunächst ein Überblick über Kerntätigkeitsfelder der IV-Beratung gegeben. Für zwei dieser Felder, die Auswahl von Unternehmenssoftware und die Einführung von Unternehmenssoftware, werden anschließend verallgemeinerte Vorgehensmodelle dargestellt, welche die tatsächlichen praktischen Schritte in entsprechenden IV-Beratungsprojekten dokumentieren. Auf allgemeinerer Ebene liefert die Untersuchung darüber hinaus folgende Ergebnisse: x Der Einsatz von Vorgehensmodellen ist in der Beratungspraxis zumindest bei den befragten 14 Unternehmen sehr etabliert. x Abgesehen von einigen (auf pragmatische Gründe zurückzuführende) Unterschieden im Modellumgang, verhalten sich auch kleinere Beratungshäuser in dieser Hinsicht nicht anders als große IV-Beratungsunternehmen. x Es kommen ganz überwiegend sequentiell angelegte Vorgehensmodelle zum Einsatz. Eine Orientierung an in der Literatur berreits beschriebenen Referenzmodellen findet statt. Allerdings werden Vorgehensmodelle immer an den Einzelfall des Klienten angepasst. Dieses „Tailoring“ der Vorgehensweise wird als sehr wichtig für die Akzeptanz beim Kunden eingeschätzt. Schlüsselwörter: IV-Unternehmensberatung, Consulting Research, Vorgehensmodell

1

Grundlagen

1.1 IV-Beratung als Form der Unternehmensberatung Unternehmensberatung ist eine professionelle Dienstleistung, die durch eine oder mehrere, im Allgemeinen fachlich dazu befähigte und von den beratenen Klienten hierarchisch unabhängige Person(en) zeitlich befristet sowie meist gegen Entgelt erbracht wird und zum Ziel hat, betriebswirtschaftliche Probleme des beauftragenden Unternehmens interaktiv mit den Klienten zu definieren, zu strukturieren und zu analysieren, sowie Problemlösungen zu erarbeiten, und auf Wunsch ihre Umsetzung gemeinsam mit Vertretern des Klienten zu planen sowie im Unternehmen zu realisieren [Niss07; 3]. Im Jahr 2008 ist der Umsatz der Beratungsbranche in Deutschland um 10,7 Prozent auf 18,2 Mrd. Euro gestiegen [BDU09]. Es geht in der Unternehmensberatung um Unterstützung bei der Bearbeitung betriebswirtschaftlich motivierter Fragestellungen. 1 Dabei können unterschiedliche Aspekte im Klientenunternehmen (kurz: Klient) untersucht werden, wie zum Beispiel Strategiethemen,

—6—

Organisation

und

Geschäftsprozesse,

Informationstechnik

oder

personalbezogene

Fragestellungen. Entsprechend existieren unterschiedliche Beratungsfelder, insbesondere (gemäß Klassifikation des BDU 2): x

Strategieberatung,

x

Organisationsberatung,

x

IT-Beratung,

x

Personal- und HR-Beratung.

In diesem Beitrag soll jedoch anstelle von „IT-Beratung“ von „Informationsverarbeitungsorientierter Unternehmensberatung“ (IV-Beratung) gesprochen werden, da die Verkürzung auf IT (=Informationstechnik) irreführend erscheint. IV-Beratung ist primär operativ ausgerichtet. Im Zentrum der Beratungsthemen stehen Fragen der Informationsverarbeitung von Klienten. Sie schließt organisatorische Aspekte ein, soweit diese stark mit der Informationsverarbeitung zusammenhängen (z.B. die Gestaltung von Geschäftsprozessen). Nicht zum Aufgabenfeld zählen dagegen typische Leistungen von IT Service Providern, also etwa das Hosting von Applikationen oder die Montage von Hardware beim Kunden. Ebenso nicht dazu zählt die Softwareentwicklung, auch wenn diese oft einen nennenswerten Bestandteil der praktischen Geschäftstätigkeit von Beratungsfirmen im ITUmfeld darstellt [NiKi08,90]. Gemäß Mieschke [Mies04, 7-8; erstmals bei Lüne02, 10-11] nehmen die Tätigkeitskomponenten „Analysieren“, „Planen“ und „Konzipieren“ bei IV-Beratungen durchschnittlich weniger als ein Drittel (32 %) – gemessen am Umsatz des Beratungshauses – in Anspruch. Die primären Aufgaben der IV-Berater bilden mit 49 % die Umsetzungs- und Implementierungstätigkeiten. Nissen und Kinne [2008] analysieren in umfassender Weise Unterschiede zwischen IV- und Strategieberatung. Tabelle 1 zeigt hieraus eine Gegenüberstellung der wichtigsten Merkmale der IV-Beratung in Abgrenzung zur Strategieberatung.

1 2

Daneben existieren andere Formen der Beratung, z.B. im technischen Bereich, die hier nicht von Bedeutung sind. BDU = Bund Deutscher Unternehmensberater e.V.

—7—

Kriterium

Strategieberatung

IV-Beratung

Ziele, Aufgabe

dauerhafte Sicherung des Unternehmenserfolges und Wettbewerbsvorteils; Analysieren, Planen und Konzipieren

Verbesserung des Einsatzes von Informationsverarbeitung; Schwerpunkt Umsetzen

Auftraggeber

Top Management; mittlere und große Unternehmen

Fachbereiche, IT-Abteilung; alle Unternehmensgrößen

Enge Branchenspezialisierung

eher selten

häufig

Eigentumsverhältnisse

Partnerschaft

Kapitalgesellschaft

Organisation

Matrix

Matrix

Projekttypen

Brain, Grey Hair

Grey Hair, Procedure

Leverage

gering

hoch

Wissensschwerpunkt

Methodisches Wissen

Branchen- und IT-bezogenes Fachwissen

Tagessätze

hoch

deutlich geringer

Gehälter

hoch

deutlich geringer

Fixpreisprojekte

nein

teilweise

Erfolgsabhängige Projektpreise

nein

teilweise

Marken, Beratungsprodukte

v.a. bei großen Beratungsfirmen seit langer Zeit etabliert

noch eher selten

Möglichkeiten der Standardisierung

eingeschränkt

ja

konjunkturabhängig

nein

ja

Strategische Partner

teils wichtig (Umsetzung)

sehr wichtig (z.B. Hard- /Software)

Bestandskundengeschäftsanteil

sehr hoch

sehr hoch

Anteil Folgeaufträge

hoch

sehr hoch

‡ Dauer Kundenbindung

4,8 Jahre

5,5 Jahre

Image-Fokus

Elite

Spezialist, Dienstleistungsqualität

Vorherrschender Marketingtyp

Publizist

Direktvermarkter

Personalrekrutierung

komplex, aufwendig

einfacher gehalten

Studienfächer

sehr gemischt

v.a. BWL und (Wirtschafts-)Informatik

Karrieresystem

Up-or-Out

Grow-or-Die

Vorstaffing von Projekten

früher nein, inzwischen teilweise erforderlich

oft notwendig

Häufiges Vorgehensmodell im Projekt

Hypothesenbasierter Ansatz

Phasenmodell, Template Approach

WM-Strategie

Personalisierung

Kodifizierung

Tabelle 1: Merkmale von Strategieberatung und IV-Beratung [NiKi08,102]

—8—

1.2

Kernaufgaben der IV-Beratung

Anhand einer umfassenden Analyse der Internetseiten von 30 IV-Beratungsunternehmen konnte ein vielfältiges Angebot an verschiedensten Beratungsleistung identifiziert werden. Die am häufigsten genannten acht Kernaufgaben der IV-Beratung (nachfolgend Beratungsfelder) werden in diesem Kapitel kurz vorgestellt.

1.2.1 Software-Auswahl Das Beratungsfeld der Software-Auswahl umfasst den gesamten Prozess der Auswahl einer für die individuellen Unternehmensziele bestmöglich geeigneten Software – in der Regel Unternehmenssoftware 3. Die Wahl des „richtigen“ Softwareproduktes ist aus Klientenperspektive deshalb so enorm wichtig, weil es zur Unterstützung der verfolgten Wettbewerbsstrategie beitragen und auf lange Sicht im Unternehmen eingesetzt werden soll. Außerdem sind mit der Einführung gewöhnlich hohe und teilweise irreversible Investitionen verbunden [BVWi07, 2]. Vor der Beauftragung eine Beratungsunternehmens hat im allgemeinen eine Abwägung zwischen einer Software-Eigenentwicklung oder dem Kauf einer bereits am Markt etablierten Softwarelösung (die sog. Make-or-Buy Entscheidung) stattgefunden. Die Auswahl des „besten“ Software-Anbieters bzw. Vertriebspartners ist neben der Auswahl des Produktes selbst ebenfalls Bestandteil des Aufgabenfeldes. Dieser Aspekt ist darum von großer Bedeutung, weil sich die dem Auswahlprozess anschließende SoftwareEinführung in der Regel gemeinsam mit diesem Unternehmen durchgeführt wird. Das Vorgehen im Software-Auswahlprozess, und damit auch die Entscheidung für oder gegen einen bestimmten Anbieter, beeinflusst demnach das gesamte Einführungsprojekt [Aren04, 227]. Aus diesem Grund verwenden die Beratungen mitunter integrierte Vorgehensmodelle, in denen sowohl die Software-Auswahl als auch -Einführung enthalten sind. Solche Modelle nutzen sechs der in dieser Arbeit befragten 14 Unternehmen. Jedoch

beauftragen

nicht

alle

Unternehmen

von

Beginn

an

eine

externe

Unternehmensberatung mit der Software-Auswahl. In den zu dieser Arbeit durchgeführten Interviews berichteten fünf Berater, dass viele Firmen versuchen, die Auswahl der

3

Damit sind insbesondere ERP-Systeme oder Warenwirtschaftssysteme gemeint [BVWi07, 2].

—9—

Software ohne externe Beratung durchzuführen. Sie suchen sich auf der Basis von Literaturquellen, Messebesuchen oder auch nur Hörensagen am Markt einige Angebote heraus, ohne eine genaue Anforderungsanalyse durchzuführen und gehen unstrukturiert an den Selektionsprozess heran. Entweder wird ihnen dann im Laufe der Auswahl bewusst, dass keine fundierte Entscheidung getroffen werden kann und das Projekt stoppt – in diesem Fall werden dann neue Projekte aufgesetzt oder Beratungen hinzugezogen. Oder sie wählen trotz der vorhandenen Unsicherheit eine Software aus, weil sie sich ihr mangelhaftes Vorgehen nicht eingestehen wollen – das führt in vielen Fällen jedoch zu erhöhter Unzufriedenheit während des Software-Einsatzes. Diese Szenarien zeigen, dass die Erfahrung und das (branchen-)spezifische Wissen der Berater eine wichtige Rolle für die effektive und effiziente Software-Auswahl spielen kann. Aus Sicht der Beratungshäuser ist die Problemstellung sehr gut bekannt. Es existieren in der Regel ausgereifte Vorgehensmodelle für solche Projekte und die Berater können vielfältiges Erfahrungswissen vorweisen. Von daher sind Projekte aus diesem Beratungsfeld mehrheitlich als Procedure Projekte im Sinne Maisters [Mais03] zu klassifizieren.

1.2.2 Software-Einführung Aus Sicht des Beratungshauses besteht die Aufgabenstellung der Software-Einführung vornehmlich darin, eine Standardsoftware 4 „(..) zielorientiert und toolgestützt unter maßgeblicher Beteiligung des Kunden einzuführen mit dem Ziel, einen optimalen Nutzen langfristig zu ermöglichen“ [GaLo01, 182]. Die Einführung von umfangreichen Softwareprodukten kommt in der Regel relativ selten vor. Von daher besitzen viele Klientenunternehmen nicht die hierfür erforderlichen Kompetenzen und haben keine Erfahrungen in diesem Bereich. Dadurch entsteht Unsicherheit hinsichtlich der optimalen Vorgehensweise in solchen Projekten, die mittels Anleitung durch externe Berater beseitigt werden soll. Außerdem nimmt der Berater eventuell eine Vermittlerrolle zwischen dem Klientenunternehmen und dem Software-Lieferanten bzw. Implementierungspartner ein. Wird die Software-Einführung ohne einen Berater durchgeführt, kann es zu

4

Eine Definition von Standardsoftware findet sich bei Stahlknecht / Hasenkamp: „Dabei handelt es sich um fertige, aus einer Menge von Programmen bestehende Programmpakete, die einen vollständigen Geschäftsprozess oder ein abgeschlossenes betriebliches Anwendungsgebiet abdecken“ [StHa05, 213].

— 10 —

Schwierigkeiten hinsichtlich eines gemeinsamen Verständnisses der umzusetzenden Anforderungen und der generellen Kommunikation kommen. Laut Österle ist die Bezeichnung „Einführung einer Standardsoftware“ jedoch irreführend, weil es sich bei dieser Beratungsaufgabe nicht nur um die Einführung einer Software handelt, sondern um die Reorganisation eines Betriebs [Öste97, 380]. Welches Ausmaß diese Reorganisation des Klientenunternehmens annimmt, ist in der Praxis jedoch von Projekt zu Projekt sehr verschieden. Spätestens zu Beginn jedes Software-EinführungsProjektes – besser bereits im Rahmen der Software-Auswahl – muss die Entscheidung getroffenen werden, wie stark die Software noch an spezielle Bedürfnisse des jeweiligen Klienten angepasst werden soll. Einer der im Rahmen dieser Arbeit interviewten Berater drückte diese Problematik wie folgt aus: „Man muss darüber entscheiden, ob die Prozesse die IT prägen oder die IT die Prozesse prägen soll.“ Im letzteren Fall kann es durchaus zu erheblichen Reorganisationsmaßnahmen bezüglich der bisherigen Abläufe und der Organisationsstruktur im Klientenunternehmen kommen. Die Aufgabe der Berater besteht hierbei darin, den Klienten hinsichtlich dieser beiden Alternativen objektiv zu unterstützen. Für eine aus Kundensicht erfolgreiche Beratung im Rahmen der Software-Einführung benötigen die Berater gute Kenntnisse über die einzuführende Software und unbedingt umfangreiche Erfahrungen in Einführungsprojekten [GaLo01, 189-190]. Aufgrund der zwar generell bekannten Aufgabenstellung, aber der dennoch kundenindividuellen Beratungstätigkeit lässt sich die Software-Einführung, je nach Komplexität und Individualisierungsgrad, in die Kategorie der Procedure oder Grey Hair Projekte nach Maister einordnen.

1.2.3 IT-Architektur Da verschiedene Auffassungen bezüglich des Begriffes IT-Architektur im alltäglichen Sprachgebrauch – und damit demnach auch in der Beratungspraxis – häufig zu Missverständnissen führen 5, wird IT-Architektur hier zunächst definiert. Zum Begriffsverständnis der IT-Architektur existieren in der Literatur zahlreiche Definitionen wie z.B. bei Dern [Dern06, 18-21] und Niemann [Niem05, 22-23]. Heinrich /

5

Diese Erfahrung wurde während der Befragung der Beratungshäuser gemacht.

— 11 —

Heinzl / Roithmayr beziehen den Begriff IT-Architektur nicht auf die Architektur einzelner Komponenten wie Hardware oder Software, sondern auf die Informationsinfrastruktur 6 als Ganzes [HHRo04, 346]. Die verschiedenen darin enthaltenen Architekturbestandteile sind in nachfolgender Grafik (Bild 1) dargestellt. Diese Definition wird im Folgenden zugrunde gelegt.

IT-Architektur

Informationssystemarchitektur

Technologiearchitektur SWArchitektur

Datenarchitektur

NetzArchitektur

HWArchitektur

Anwendungssystemarchitektur

Kommunikationsarchitektur

Informationsarchitektur

Bild 1: Übersicht IT-Architektur (nach [HHRo04]

Die Informationsarchitektur bildet als „das grundlegende logische Modell der Informationsinfrastruktur“ die Basis für die weiteren Architekturkomponenten und ist dabei „das Ergebnis der (...) unternehmensweit erfassten, evaluierten und gegliederten Informationsnachfrage

bzw.

der

zu

ihrer

Befriedigung

erforderlichen

Informationsversorgung (...)“ [HHRo04, 319]. Anhand der Daten, Anwendungssysteme und Kommunikationswege wird die Informationsarchitektur zerlegt und die jeweiligen Teil-Architekturen entworfen. Auf diesen aufbauend wird als Grundlage der physischen Realisierung der logischen Modelle die Technologiearchitektur mit Software-, Hardwareund Netz-Architektur gestaltet [HHRo04, 653-654]. Die Software-Architektur beschreibt dabei die „Gliederung von Software in Komponenten (meist in Module), deren Schnittstellen, Prozesse und Beziehungen sowie die erforderlichen Betriebsmittel“ und

6

„In der Wirtschaftsinformatik meint Informationsinfrastruktur die Gesamtheit der für die Informationsfunktion im Unternehmen vorhandenen ‚Einrichtungen, Maßnahmen und Anlagen’ zur Produktion von Information und für

— 12 —

enthält im weiten Sinne strukturelle und formale Prinzipien und Organisationsformen von Software [HHRo04, 604]. Die Informationssystem-Architektur schließlich beinhaltet „die Methoden zur Planung und Realisierung von Informationssystemen (...), also das ‚Wie?’ im Unterschied zum ‚Was?’ der Anwendungssystem-Architektur“ [HHRo04, 325]. Zusammenfassend kann festgehalten werden, dass die IT-Architektur neben den Grundstrukturen der Informationsnfrastruktur eines Unternehmens auch die Regeln für das dynamische Zusammenspiel aller IT-Komponenten festlegt. Auch wenn sich die grundlegende Informationsarchitektur nicht direkt aus den strategischen Unternehmens- bzw. IT-Zielen ableitet [HeLe05, 52], so fungiert die gesamte IT-Architektur dennoch als Bindeglied zwischen Geschäftsstrategie, IT-Strategie und ITImplementierung. Das übergeordnete Ziel der IT-Architektur ist demnach die Ausrichtung der Informationsverarbeitung an den Geschäftsanforderungen des Unternehmens. Aufgrund der unterschiedlichen Betrachtungsmöglichkeiten von IT-Architektur bezüglich der verschiedenen Teil-Architekturen im Unternehmen werden in diesem Beratungsfeld vielfältige Leistungen angeboten. Sie reichen von der Beratung zur Informationsarchitektur über die Beratung zur Ableitung und Festlegung einheitlicher Architekturregeln bis hin zur Optimierung der Architektur einer Softwarelösung. Aus Klientensicht sind derzeit die Beratungsangebote hinsichtlich Service-orientierter Architekturen (SOA) besonders interessant. 7 SOA repräsentieren jedoch „weder eine Technologie noch einen technologischen Standard“ [PNTr07, 167], sondern entsprechen einem Konzept oder „Strukturparadigma für (betriebliche) Anwendungssysteme, das (...) auf den Aspekt der (Dienst 8-) Verwendung fokussiert“ [OvTu07, 3]. Demzufolge sind die Beratungsvarianten hierzu ebenso zahlreich wie die in der Literatur existierenden Definitionen. Abschließend kann festgestellt werden, dass die Aufgabenstellungen in diesem Beratungsfeld nicht nur sehr vielfältig sind, sondern abhängig von der aktuellen Situation im Klientenunternehmen höchst individuelle Lösungen erfordern. Dies erfordert sowohl Kreativität als auch Erfahrungswissen von Seiten der Berater und lässt auf die überwiegende Durchführung von Grey Hair oder sogar Brain Projekten schließen gemäß Maister [2003] schließen.

7

Kommunikation“ [HHRo04, 15]. „Langfristig setzt ein Viertel der Unternehmen auf Service-orientierte Architekturen“ [Capg07, 23].

— 13 —

1.2.4 IT-Sicherheit Laut der Capgemini-Studie „IT-Trends 2008“ ist und bleibt für viele Unternehmen die ITSicherheit das wichtigste Thema [Capg08, 7; 26]. Dabei werden neben technischen Risiken die wichtigsten Bedrohungsszenarien in dem geringen Sicherheitsbewusstsein der Mitarbeiter und des Managements sowie in dem unberechtigen Zugriff des eigenen Personals auf sensible Daten gesehen. Um diesen Gefahren zu begegnen, ist ein ganzheitliches Informationssicherheitsmanagement durch technische, organisatorische und physische Maßnahmen erforderlich. Die dabei zu verfolgenden IT-Sicherheitsziele betreffen die Integrität, die Verbindlichkeit, die Verfügbarkeit, die Vertraulichkeit, die Anonymität und die Unbeobachtbarkeit [HHRo04, 595]. Die Beratungsaufgaben im Bereich der IT-Sicherheit sind daher vielfältiger Natur. Sie beinhalten zunächst die Durchführung von Risiko- und Sicherheitsanalysen zur Feststellung des Risikopotentials und Bewertung der aktuellen IT-Sicherheitssituation hinsichtlich der Informationssysteme im Klientenunternehmen. Eine mögliche Methode hierfür ist die Durchführung von Penetrationstests, d. h. die Durchführung von Angriffen auf die Netzwerk- oder Softwaresysteme des Klienten zur Identifikation möglicher Sicherheitsschwachstellen.

Aufbauend

auf

den

Analyseergebnissen

erfolgt

die

Entwicklung von geeigneten Konzepten und Sicherungsmaßnahmen. Im Rahmen des Compliance-Managements als ein Teilgebiet der IT-Governance [JoGo06; 10-11] sollten dabei u.a. die Vorgaben des Bundesdatenschutz-Gesetzes, des IT-Grundschutzhandbuches und

des

Signaturgesetzes

eingehalten

werden.

Beispiele

für

mögliche

Sicherungsmaßnahmen bzw. -Konzepte sind die Etablierung eines umfassenden Identityund Access-Managements (Verwaltung der digitalen Identität und Rechte der Nutzer sowie ein gesicherter Zugang zu allen Systemen und Anwendungen) und die Einführung eines Lizenzmanagementkonzeptes (Steuerung des Lizenzeinsatzes im Klientenunternehmen). In diesem Beratungsfeld, in dem die Klientenprobleme sehr gut bekannt sind und unterstützende Methoden existieren, sind größtenteils Procedure und Grey Hair Projekte zu finden.

8

Zur Definition von Diensten siehe bspw. [HaNe05b, 783]

— 14 —

1.2.5 IT-Integration Heutzutage finden sich in den meisten Unternehmen historisch gewachsene und daher stark heterogene IT-Landschaften. So werden bspw. unterschiedliche Basistechnologien eingesetzt, verschiedene Softwareentwicklungsparadigmen angewandt oder / und monolithische Softwaresysteme zur Unterstützung der jeweiligen Funktionsbereiche betrieben. Dies führt zu einer schwierigen Integration der verschiedenen Systeme und verursacht einen enorm hohen Aufwand bezüglich der Entwicklung und Wartung der jeweiligen individuellen Schnittstellen. Dies führt häufig auch zu einer lediglich suboptimalen IT-Unterstützung der Geschäftsprozesse im Unternehmen. An diesen Problemfeldern setzt die Beratung der IT-Integration an, denn sie befasst sich mit allen Aspekten einer integrierte Informationsverarbeitung im Klientenunternehmen. Dies umfasst nach Mertens u.a. die Funktionsintegration auf horizontaler und vertikaler Ebene, die Prozessintegration in Bezug auf die Automatisierung der Geschäftsprozesse, die Herstellung einer einheitlichen Datenbasis im Rahmen der Datenintegration sowie die homogene

Präsentation

verschiedener

Programme

durch

die

Integration

der

Benutzerschnittstellen [Mert97, 208]. Ein typisches Beispiel für ein Integrationsprojekt ist der Aufbau eines Unternehmensportals. Dabei werden nicht nur die autonomen Anwendungssysteme in das Portal integriert, sondern idealerweise auch die dazugehörigen Geschäftsprozesse und Unternehmensstrukturen überprüft. Vogler beschreibt die Aufgaben von sog. Systemintegratoren folgendermaßen: „Sie wählen aus dem am Markt verfügbaren Angebot an Standard- und Spezialsoftware die für das jeweilige Projekt optimale Anwendung aus, berücksichtigen dabei im Unternehmen bereits vorhandene Informationssysteme und integrieren die einzelnen Bestandteile zu einer kundenspezifischen Lösung“ [Vogl97, 392]. Aufgrund des mitunter sehr hohen Anteils an Programmiertätigkeiten innerhalb eines Beratungsprojektes, vereint der BDU die Softwareentwicklung und Systemintegration in einem Beratungsfeld und zählt dieses zu den beratungsnahen Dienstleistungen [BDU08b, 11]. Die grundsätzliche Problematik und die daraus resultierenden Beratungstätigkeiten sind bekannt, aber die jeweils im Klientenunternehmen vorherrschende Situation erfordert einen großen Erfahrungsschatz der Berater. Daher handelt es bei Projekten in diesem Beratungsfeld vornehmlich um Grey Hair Projekte. — 15 —

1.2.6 IT-Strategie Gemäß Heinrich / Heinzl / Roithmayr wird mittels der IT-Strategie die „Art und Richtung der Gestaltung der Informationsinfrastruktur durch das oberste Leitungsorgan des Unternehmens festgelegt (...). Die IT-Strategie bestimmt den Handlungsspielraum, in dem sich die administrativen und operativen Entscheidungen und Maßnahmen zur Gestaltung der Informationsinfrastruktur vollziehen“ [HHRo04, 348]. Die Aufgabe der Unternehmensberatung ist hierbei die umfassende Unterstützung des Klienten bei der Entwicklung und Umsetzung der IT-Strategie. Die Strategieentwicklung ist eine Teilaufgabe der strategischen IT-Planung [HHRo04, 633-634]. Dabei wird die IT-Strategie aus der Unternehmensstrategie abgeleitet bzw. mit dieser abgestimmt. Dieser Abgleich der „Prioritäten, Kompetenzen, Entscheidungen und Aktivitäten der IT auf das Gesamtunternehmen und dessen Ziele und Strategien“[JoGo06, 9] wird als IT-Business-Alignment bezeichnet. Zielsetzung dieser Maßnahme ist die Erhöhung des Wertbeitrages der IT für das Unternehmen und damit die Steigerung der Effektivität sowie der Unternehmensleistung an sich. Gemäß Becker / Vering / Winkelmann müssen bei der IT-Strategie-Entwicklung u.a. folgende Punkte beachtet werden [BVWi07, 18]: die Rolle der IT im Unternehmen, die Bedeutung der IT zur Abgrenzung des Unternehmens im Wettbewerbsumfeld sowie die Relevanz aktueller und zukünftiger Technologien. Aufgrund dieser komplexen Bestimmungsfaktoren müssen die Berater über hochwertiges „methodisch-fachliches Wissen und professionelle Fähigkeiten“ [NiKi07, 7] verfügen. Da bezüglich der Vorgehensweise zur Entwicklung einer IT-Strategie heute in Unternehmen kaum konkrete Vorstellungen existieren [HHRo04, 348], handelt es sich bei der IT-Strategie-Beratung hauptsächlich um Brain oder Grey Hair Projekte.

1.2.7 IT-Organisation Dieses Beratungsfeld ist eng mit dem der IT-Strategie verknüpft. Unter Beachtung der strategischen Vorgaben wird hierbei die IT-spezifische Aufbau- und Ablauforganisation des Klientenunternehmens entwickelt. Die Beratungsaufgaben betreffen demnach die — 16 —

folgenden zwei Aspekte. Zum einen können die Berater dem Klienten eine Anleitung bei der

hierarchischen

Einordnung

und

internen

organisatorischen

Gliederung

der

Organisationseinheit „Informationsverarbeitung“ geben. Und zum anderen beschäftigt sich die Beratung mit den „organisatorisch geregelten Prozesse(n) der Beschaffung, der Erstentwicklung, des Betriebs, der Wartung und der Weiterentwicklung der verschiedenen Arten von Systemen“ [Seib97a, 42]. Von

großer

Bedeutung

sind

hier

Referenzmodelle

und

Methoden

des

IT-

Servicemanagement. „Das IT-Servicemanagement ist vor allem als prozess- und servicegerichtete Vorgehensweise für das Management innerhalb der IT zu verstehen und beschäftigt sich mit der Lieferung und dem Support von IT-Services, welche exakt auf die Bedürfnisse der Organisation zugeschnitten sind“ [KBSt08]. Der Leitfaden „ITIL“ (IT Infrastructure Library) ist heute der weltweite De-facto-Standard im Bereich ITServicemanagement. und auch Grundlage der DIN ISO 20.000 Norm. Aus Sicht der Beratungshäuser sind die zu lösenden Aufgabenstellungen grundsätzlich bekannt bzw. bezüglich der Aufbauorganisation sogar gut bekannt. Für die erfolgreiche Beratungstätigkeit insbesondere im Zusammenhang mit der Ablauforganisation der IT spielen jedoch die Erfahrungen aus vergangenen Projekten eine wichtige Rolle. Demzufolge werden in diesem Beratungsfeld sowohl Procedure als auch Grey Hair Projekte durchgeführt.

1.2.8 IT-Outsourcing Outsourcing (Auslagerung) bezeichnet die teilweise oder komplette Übertragung von Aufgaben und Ressourcen der IV an einen oder mehrere rechtlich unabhängige Dienstleister [Hein97, 304]. Alternativ kann eine Ausgliederung, also eine Verlagerung von Aufgaben auf ein selbstständiges, aber rechtlich (und kapitalmäßig) verbundenes Dienstleistungsunternehmen [StHa05, 451] stattfinden. An dieser Stelle sei noch einmal ausdrücklich darauf hingewiesen, dass die IV- Beratung nicht darin besteht, diese Outsourcing-Dienstleistungen selbst zu erbringen. Die Beratungsaufgaben betreffen vielmehr die Unterstützung der Klientenunternehmen im Rahmen der Vorbereitung und Durchführung eines Outsourcing-Vorhabens. Allein die vielfältigen Outsourcingformen verdeutlichen das komplexe Entscheidungsproblem, bei

— 17 —

dessen Lösung die Berater wertvolle Hilfestellung leisten können. So muss zur Vorbereitung bspw. die Entscheidung hinsichtlich der am besten geeigneten SourcingVariante und des Dienstleisters getroffen werden. In Business-Process-OutsourcingProjekten 9 unterstützen IT-Berater die Klienten darin, Geschäftsprozesse aus den Unternehmen herauszulösen, diese Prozesse neu zu organisieren und die Zusammenarbeit zwischen Auftraggeber und BPO-Dienstleister sicher zu stellen [BDU07, 11]. Trotz des umfassenden Outsourcing-Angebotes ist die Aufgabenstellung der Beratung im Grundsatz bekannt. Hinsichtlich der letztgenannten Beratungsprojekttätigkeiten bedarf es allerdings umfassender Kenntnisse und auch Erfahrungen seitens der Berater. Von daher werden in diesem Beratungsfeld sowohl Procedure als auch Grey Hair Projekte durchgeführt.

1.3 Vorgehensmodelle Wenn im Folgenden Vorgehensmodelle für Beratungsaktivitäten untersucht werden, ist darunter eine Folge aller Aktivitäten, die zur Durchführung eines Projektes erforderlich sind [StHa05, 215] zu verstehen. Die Aktivitäten bzw. Aufgaben werden in gegeneinander abgegrenzten Phasen zusammengefasst. Diese enden jeweils mit definierten Meilensteinen, d.h. Entscheidungs- bzw. Genehmigungspunkten bezüglich der jeweils definierten Zwischenergebnisse [Seib97b, 431-432]. Bilden die in einem Projekt zu bearbeitenden Phasen eine aufeinander aufbauende Abfolge, so bezeichnet man ein solches Vorgehensmodell als Phasenmodell. Es dient grundsätzlich einer besseren Prozesskontrolle, indem die Gesamtkomplexität des Projektes reduziert, die Transparenz des Prozesses verbessert und somit eine Überprüfung der Termin-, Kosten-, Qualitäts- und Leistungsziele ermöglicht wird. Außerdem erleichtert die Anwendung eines Vorgehensmodells die Koordination des Projektteams und die frühzeitige Fehlererkennung. Vorgehensmodelle

können

Allgemeingültigkeitsanspruch

9

den und

Charakter

von

Empfehlungscharakter

Referenzmodellen in

einem

mit

bestimmten

Business Process Outsourcing ist „die Auslagerung bestimmter Geschäftsprozesse (...). Hierbei delegieren Unternehmen notwendige, aber nicht geschäftskritische administrative Funktionen komplett an externe Anbieter – zum Beispiel Routineabläufe aus Personal- und Finanzwesen (...)“ [Eber04, 143].

— 18 —

Anwendungsfeld haben. Nachfolgend werden einige Vorgehensmodelle kurz vorgestellt, die auch in der Unternehmensberatung zum Einsatz kommen können. 10 Sequentielles Phasenmodell Kennzeichnend für diese Art von Vorgehensmodellen ist die streng sequentielle Abfolge der einzelnen in sich abgeschlossenen Phasen. Eine neue Phase wird erst begonnen, wenn die vorhergehende Phase vollständig abgeschlossen ist, d.h. wenn ein entsprechendes Phasenprodukt vorliegt und dokumentiert ist. Die Aktivitäten einer Phase werden nur einmal ausgeführt. Wasserfall-Phasenmodell Abweichend zur strengen Sequentialisierung ist in diesem Modell eine Rückkopplung zwischen zwei aufeinander folgenden Phasen möglich. Am Ende jeder Phase erfolgt eine Validierung der Arbeitsergebnisse hinsichtlich ihrer Korrektheit und Vollständigkeit. Bevor sie für die weitere Bearbeitung in der nächsten Phase zur Verfügung stehen, muss demnach geklärt werden, ob die Phase wiederholt werden muss, die nächste Phase begonnen werden kann oder eine Rückkopplung in eine bereits abgeschlossene Phase notwendig ist. Die

folgenden

Vorgehensmodelle

bzw.

Methoden

sind

typisch

für

die

Softwareentwicklung, können aber auf die IV-Beratung übertragen werden, insbesondere, wenn im Projektrahmen auch Programmierleistungen erbracht werden. V-Form-Phasenmodell (kurz V-Modell) Das

V-Modell

stellt

Konstruktions-

und

Validierungsphasen

als

gleichwertige

Entwicklungsphasen gegenüber. Der linke Ast des >V< erfaßt die Abfolge der konstruktiven Aktivitäten sowie deren Ergebnisse. Der rechte Ast beschreibt die Überprüfungstätigkeiten, deren Resultate und die Auswirkungen der Ergebnisprüfungen auf die konstruktiven Aktivitäten des linken Balkens. Die Spitze des >V< beinhaltet die Implementierung. 11 Spiralmodell

10 11

Siehe zu den Vorgehensmodellen z.B. [BMRu04]. Für eine Übersicht der einzelnen Aktivitäten sowie des Phasenablaufes siehe [HaNe05a, 278]

— 19 —

Das Spiralmodell beschreibt die Systementwicklung als einen evolutionären Prozeß, bei dem die einzelnen Phasen wiederholt durchlaufen werden. Von besonderer Bedeutung ist die Validierungsphase am Ende eines jeden Zyklus. In dieser Phase sollen sich alle Beteiligten über das bisher Geleistete verständigen und sich darüber einigen, was im nächsten Zyklus zu leisten ist. Die kontinuierliche Weiterentwicklung der Software über alle zyklisch auftretenden Phasen hinweg führt dabei zu einer spiralförmigen Modellvorstellung. Prototyping Prototyping ist eine Methode zur Systementwicklung, bei der möglichst früh in einem Pilotprojekt eine erste vereinfachte Version (Prototyp) realisiert wird, um in wichtigen Bereichen Erfahrungen zu sammeln. Gemeinsam mit den Anwendern wird in kurzer Zeit eine vereinfachte, aber ablauffähige Programmversion entwickelt. Diese soll den Benutzern eine Vorstellung bezüglich der Funktionalitäten vermitteln und dient als Grundlage der weiteren inkrementellen Programmentwicklung.

2

Empirische Untersuchung

2.1 Ausgangspunkt und Forschungsfragen der Untersuchung Da die Gewährleistung einer qualitativ hochwertigen Dienstleistung ein zentraler Wettbewerbsfaktor ist [Bruh08,3], sollten laut Mieschke (IV)Beratungsunternehmen Vorgehensmodelle für einzelne Projekttypen bzw. Beratungsthemen mit dem Ziel der Qualitätssteigerung

anwenden

[Mies04,105].

Die

dadurch

erhoffte

höhere

Klientenzufriedenheit stellt die gewünschte externe Wirkung des Einsatzes von Vorgehensmodellen dar. Durch die Standardisierung von Prozessen und der verwendeten Arbeitsvorlagen kann der Einsatz von Vorgehensmodellen jedoch auch innerhalb des Beratungshauses selbst für positive Effekte sorgen. So tragen ein dadurch reduzierter Abstimmungsaufwand und die erhöhte Abwicklungsgeschwindigkeit zur internen Effizienzsteigerung bei [MaVo05, 265-266]. Für viele Tätigkeitsbereiche der IV-Beratung existieren in der Literatur empfohlene Vorgehensmodelle oder Beschreibungen von Arbeitsfolgen. Die Frage der tatsächlichen Nutzung von Vorgehensmodellen in den IT-Beratungshäusern scheint jedoch bislang noch — 20 —

nicht untersucht bzw. beantwortet worden zu sein. Daher sollen hier folgende Fragestellungen im Zusammenhang mit Vorgehensmodellen in der Beratungspraxis untersucht werden: o In welchem Ausmaß werden in der Beratungspraxis überhaupt / tatsächlich Vorgehensmodelle eingesetzt? o Inwiefern lassen sich Unterschiede zwischen kleinen und großen Beratungshäusern beim Einsatz von Vorgehensmodellen feststellen? o Werden in der IV-Beratung, unabhängig vom konkreten Themenschwerpunkt, überwiegend lineare/sequentielle Vorgehensmodelle eingesetzt?

2.2.

Datengrundlage und Methodik der empirischen Untersuchung

2.2.1 Stichprobenauswahl Da eine Vollerhebung aus Aufwandsgründen gar nicht durchzuführen wäre, erfolgte eine Stichprobenauswahl von Beratungsunternehmen. Hierbei wurde, anders als bei quantitativen

Untersuchungen,

nicht

die

statistische,

sondern

eine

inhaltliche

Repräsentativität der Stichprobe angestrebt [Merk05, 291]. Dazu erfolgte im Sinne einer Vorab-Festlegung zunächst die Erstellung einer Samplestruktur, die eine begründete Stichprobenbildung erlaubte [Maye06, 38-39]. Als Schichtungsmerkmale wurden dabei die Beratungsfelder Software-Auswahl und Software-Einführung sowie eine Klassifikation nach der Unternehmensgröße in kleine (< 20 Mitarbeiter), mittelgroße (20 – 500 Mitarbeiter) und große (> 500 Mitarbeiter) Unternehmen verwendet. Die anschließende Auswahl der zu befragenden Firmen nutzte Informationen aus den Internetseiten einzelner Beratungshäuser, der BDU-Beraterdatenbank [BDU07], der zutreffenden

Lünendonk®-Liste

der

IT-Beratungs-Unternehmen

[Lüne07]

und

Fachbeiträgen in der Literatur mit dem Ziel einer gleichmäßigen und ausreichenden Verteilung der Fälle auf die einzelnen Zellen der Samplestruktur. Es erklärten sich Vertreter aus 14 Beratungshäusern zur Teilnahme an der Untersuchung bereit. Die Größe der befragten Unternehmen umfasst dabei das gesamte Spektrum. Die folgende Tabelle 2 zeigt die Samplestruktur sowie die Verteilung der Untersuchungsfälle.

— 21 —

Beratungsfeld

Unternehmensgröße klein mittel groß

SW-Auswahl 4 5 4

SW-Einführung 5 4 4

Summe:

13

13

Tabelle 2: Samplestruktur

Die Untersuchung beinhaltet jeweils 13 Befragungen zur Software-Auswahl und zur Software-Einführung. Die Abweichung der Fallanzahl zu der Anzahl der befragten Unternehmen ergibt sich daraus, dass viele Beratungshäuser zu mehr als einem Thema befragt wurden. Die exakte Aufschlüsselung kann in anonymisierter Form Tabelle 3 entnommen werden. Obgleich sämtliche befragte Unternehmen IV-Beratungsleistungen erbringen, ergab die Befragung, dass einige reine IV-Beratungshäuser sind und andere Beratungsfirmen dagegen die IV-Beratung als Geschäftsbereich bzw. Abteilung betreiben. Im letzteren Fall werden neben der IV-Beratung weitere Dienstleistungen, wie bspw. Wirtschaftsprüfung, Softwareentwicklung, Outsourcing und Hosting Services angeboten. Unternehmen 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Summe:

befragt zu Beratungsfeld SW-Auswahl SW-Einführung x x x x x x x x x x x x x x x x x x x x x x x x x x 13

13

Tabelle 3: Übersicht der untersuchten Beratungsfelder je Unternehmen

— 22 —

Im Zusammenhang mit der Unternehmensgröße ist aus der unten stehenden Grafik (Bild 2) erkennbar, dass vor allem kleine Unternehmen ausschließlich IV-Beratung durchführen, wohingegen mittelgroße bzw. große Beratungshäuser ein breiteres Leistungsspektrum anbieten. Während der Analyse der Internetseiten der Beratungsunternehmen konnte außerdem eine verstärkte Spezialisierung auf bestimmte Beratungsfelder wie die SoftwareEinführung auf Seiten der kleinen Beratungshäuser festgestellt werden. Dagegen bieten insbesondere große Beratungshäuser eine umfassendere, beratungsfeldübergreifende Beratung bezüglich bestimmter Anwendungsfelder, wie bspw. Customer Relationship Management (CRM) oder Supply Chain Management (SCM) an. 5 4 3 2 1 0 kleine Unternehmen

mittlere Unternehmen

reine IV-Beratung

große Unternehmen

IV- und andere Beratungsschwerpunkte

Bild 2: Tätigkeitsschwerpunkte der betrachteten Beratungsunternehmen 2.2.2 Interviewdurchführung Im Hinblick auf die Zielsetzung dieser Arbeit und der damit verbundenen Komplexität des Untersuchungsobjektes

„Vorgehensmodell

in

der

Beratungspraxis“

war

eine

standardisierte, schriftliche Befragung nicht praktikabel. Zur Erhebung der überwiegend qualitativen Daten wurde die empirische Untersuchung von daher mittels strukturierter Leitfadeninterviews [Maye06, 36] mit den Unternehmensberatern durchgeführt. Die Basis der Interviews bildete ein selbst erstellter, in Themenkomplexe gegliederter Fragebogen. 12

Dieser

Leitfaden

beinhaltet

nach

den

allgemeinen

Fragen

zur

Organisationsform und Mitarbeiteranzahl im zweiten Teil Fragestellungen zum Vorgehensmodell selbst. Ohne Vorgaben wurden diese Fragen während der Gespräche

12

Siehe Anhang.

— 23 —

offen durch die befragten Berater beantwortet. Die beiden letzten Teile des Fragebogens, die die Entstehung und Handhabung der Vorgehensmodelle in der Praxis thematisieren, enthalten überwiegend geschlossene Fragen mit vereinzelten Antwortvorgaben. Diese wurden unabhängig vom besprochenen Vorgehensmodell und untersuchten Beratungsfeld allen Interviewpartnern gestellt. Der konsequente Einsatz dieses Fragebogens in allen Interviews ermöglicht den systematischen Vergleich der gewonnenen Daten [Maye06, 36] sowie die statistische Auswertung der Antworten der letzten beiden Fragebogenkomplexe. Insgesamt

wurden

Interviews

mit

15

Vertretern

der

14

teilnehmenden

Unternehmensberatungen durchgeführt. Sie erfolgten bedingt durch örtliche und zeitliche Restriktionen durchweg telefonisch. Dabei waren die Interviews vorwiegend sehr ausführlich. Die Gesprächszeit variierte zwischen 45 Minuten und bis zu zwei Stunden, was in drei Fällen die Durchführung von zwei Gesprächen erforderlich machte. Die Interviewpartner sind alle erfahrene Berater mit mehrjähriger Beratungspraxis. Zum Teil zeichnen sie für die in den Projekten eingesetzten Methoden verantwortlich und waren an der Entwicklung der Vorgehensmodelle beteiligt.

2.2.3 Interviewauswertung Für die anonyme Auswertung wurden die Interviews elektronisch aufgezeichnet und im Anschluss an deren Durchführung transkribiert. Die Transkription erfolgte aufgrund der begrenzten zeitlichen Ressourcen jedoch nicht wortgetreu und unter Aufnahme aller nonverbalen Informationen, sondern überwiegend sinngemäß. Diese Paraphrasierung [Mayr03, 61] wurde im Hinblick auf die Aufwandsoptimierung und die geplante Auswertungsmethode als ausreichend und zweckmäßig angesehen. Im

Anschluss

wurde

die qualitative Auswertung der

Daten

hinsichtlich

der

Vorgehensmodelle in den jeweiligen Beratungsfeldern vorgenommen. Da diese Arbeit auf die inhaltliche Ebene der in der Beratungspraxis angewandten Vorgehensmodelle fokussiert, bot sich für die Auswertung der Interviewmaterialien zunächst eine zusammenfassende Inhaltsanalyse an. Außerdem musste zur Gegenüberstellung der in den Interviews vorgestellten Vorgehensmodelle eine vergleichbare Zusammenstellung der Ergebnisse erfolgen, wofür sich wiederum die strukturierende Inhaltsanalyse [Mayr05, 472-473] eignet. Im Sinne dieser zusammenfassenden und strukturierenden Inhaltsanalyse wurden schließlich – jeweils für ein untersuchtes Beratungsfeld – die Phasen identifiziert, — 24 —

die einen möglichst großen Konsens aus allen Vorgehensmodellen bilden. Für das Beratungsfeld Software-Auswahl wurde ein common-practice-Vorgehensmodell erstellt, im Beratungsfeld der Software-Einführung ermöglichten die Ergebnisse näherungsweise ein best-practice-Vorgehensmodell. Obwohl insbesondere das so gewonnene Modell zur Software-Einführung anderen Unternehmen als Beispiel dienen kann, soll hier nicht von Referenzmodellen mit dem damit

verbundenen Anspruch auf Allgemeingültigkeit und Empfehlungscharakter

[StHa05, 215] gesprochen werden. Es handelt sich vielmehr um eine Darstellung des Vorgehens-Konsens in der Praxis bei einigermaßen repräsentativ ausgewählten Unternehmen. Die Modellierung dieser Vorgehensmodelle orientiert sich an der Methode von Rohloff [Rohl01, 8-9]. Mittels Techniken wie Reduktion, Bündelung und Konstruktion [Mayr03, 62] wurden die Inhalte der jeweiligen Vorgehensmodelle aus den Interviewergebnissen der einzelnen Beratungshäuser in den Phasenbeschreibungen strukturiert und zusammengefasst. Die festgestellten Unterschiede zwischen den Vorgehensweisen der Unternehmensberatungen werden in den jeweiligen Phasen der Modelle aufgezeigt.

3 Vorgehensmodell der Software-Auswahl 3.1 Allgemeines zum Vorgehensmodell Alle 13 befragten Beratungshäuser setzen in ihren Software-Auswahl-Projekten ein Vorgehensmodell ein. Aus den einzelnen Interviewergebnissen entstand das in Bild 3 dargestellte common-practice-Vorgehensmodell. Es bildet den Konsens über alle in der Untersuchung vorgestellten praktischen Vorgehensweisen ab. Das Modell besitzt dahingehend einen gewissen Referenzcharakter, dass die einzelnen Phasen (wie in Bild 4 erkennbar) zu über 80 % von allen Beratungshäusern angewandt werden. Auf die verbleibende Abweichung und die unterschiedlichen Ausprägungen der Tätigkeiten der Beratungsfirmen wird in den einzelnen Phasenbeschreibungen im anschließenden Abschnitt eingegangen. Diese Beschreibungen sind allgemein gehalten, so dass das Vorgehensmodell

den

generellen

Prozess

Softwareprodukt widerspiegelt.

— 25 —

unabhängig

vom

auszuwählenden

Zum einheitlichen Verständnis der grafischen Darstellung wird an dieser Stelle kurz die Modellierungsform nach Rohloff erläutert. Die Phasen sind kausal aneinander gereiht und werden mittels der jeweils darunter liegenden Beschreibungsfelder, auslösenden Ereignisse, Phasenergebnisse und Prozesskennzahlen detailliert. Die oberhalb der Prozesskette befindlichen Graphen stellen ein grobes Rollenkonzept dar. Für jeden Prozessbeteiligten zeigen die unterschiedlichen Aktivitätspunkte auf dem SwimlaneDiagramm die jeweilige Beteiligungsform in den einzelnen Phasen. Die graue Ellipse steht dabei für den Prozess-Verantwortlichen, die weiße zeigt einen Prozess-Beteiligten an und die gestrichelte Umrandung der Ellipse bedeutet eine unterstützende Prozessbeteiligung.

— 26 —

Bild 3: Vorgehensmodell der Software-Auswahl

— 27 —

Festlegen von

Projektinitiierung

Messgrößen

Ergebnis (Deliverables)

Auslösendes Ereignis

scheinlichkeit

x Erfolgswahr-

Projektplanung

Empfehlungen

x Annahme der

x Zeit / Kosten

Dokumente

x Qualität der

der Dokumente

Empfehlungen

x Annahme der

Vorauswahl

x Realitätsnähe

x Qualität der

x Korrektheit und

Long list potentieller SW-Lieferanten

SollAnforderungen verabschiedet

x Vollständigkeit,

SollDokumentation, Gewichteter Kriterienkatalog

IstDokumentation, Empfehlung für Verbesserungen und Projekt-Scope

Projektdefinition (verschiedene Dokumente)

x Realistische

Projekt-Scope festgelegt

Kick-Off Meeting

analyse

mittels K.o.Kriterien

Kriterien x Gewichtung

x Vorauswahl

recherche

x Markt-

Vorauswahl

x Anbieter-

Anforderungen

x Definition Soll-

Anforderungsdefinition

Projektauftrag

x Projektplan

-potential x Machbarkeits-

weise

x Verbesserungs

Strategie, GP, Organisation und IS

x IST-Analyse:

Potentialanalyse

x Budget

x Vorgehens-

sation

x Projektorgani-

Beschreibung x Projektzielen

SoftwareLieferant

Klientenunternehmen

Beratungshaus

mintreue der Angebote

x Anzahl / Ter-

Rücksprachen

x Anzahl nötiger

Eingegangene Angebote

Long list genehmigt

Fragen mit Anbietern

x Klärung offener

Angeboten und Kostenvoranschlägen

x Einholen von

derungskatalog

x Versand Anfor-

Ausschreibung

Angebote

x Qualität der

x Zeit / Kosten

Short list geeigneter SW-Lieferanten

Angebote liegen vor

deckungsgrade (Nutzwertanalyse) und Kosten

x Ermittlung Ab-

Scoring-Modell

x Erstellung

Angebotsbewertung

Terminplanung

x Einhaltung

der Use Cases

x Bewertbarkeit

x Qualität und

Präsentationen, Teststellung und Beauty Contest durchgeführt

Short list genehmigt

besuche

x Referenz-

(Workshops, Testlauf, Pilot)

x Durchführung

(Termine, Use Cases)

x Vorbereitung

Präsentationen

Empfehlungen

x Annahme der

Endauswahl

x Qualität der

Rangliste Anbieter, Auswahlentscheidung

Präsentationen durchgeführt

Empfehlung anhand vollständiger Bewertungsmatrix

x Rangliste und

Präsentationen

x Auswertung

Endauswahl

projekte (SWEinführung)

x Anzahl Folge-

Beteiligung

x Anzahl

Vertrag

„bester“ SW-Lieferant ausgewählt

prüfung

x Vertrags-

handlungen

x Vertragsver-

Vertrag

Ableitung des Vorgehensmodells Die Grafik in Bild 4 verdeutlicht, inwieweit die einzelnen Phasen des Software-AuswahlProzesses in den Vorgehensmodellen der befragten Unternehmensberatungen enthalten sind. Software-Auswahl-Prozess

UB

klein

C

Potentialanalyse

Anforderungsdefinition

Vorauswahl

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Ausschreibung

Angebotsbewertung

Präsentationen

Endauswahl

Vertrag

Größe

A B

Projektinitiierung

x

x

x

E

x

F

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

mittel

D

G H

x

x

x

I J L M

x

groß

K

x

x

x x

x

x

x

x

x

x

x

x

x

x

x

x x

x

Bild 4: Phasen der Software-Auswahl in den Vorgehensmodellen der untersuchten Beratungshäuser (weiß = Phase nicht enthalten)

Die schwarzen Flächen symbolisieren die Durchführung der inhaltlichen Aktivitäten der jeweiligen Phase, wobei in den einzelnen Beratungsfirmen die Phasen selbst durchaus anders benannt sein können. Die weißen Flächen zeigen indessen, dass diese Phasen bzw. deren Inhalte nicht im Vorgehensmodell des jeweiligen Beratungshauses vorgesehen sind. Zur besseren Vergleichbarkeit der Vorgehensweisen im Zusammenhang mit der Unternehmensgröße der Beratungshäuser wurden diese nach aufsteigender Mitarbeiterzahl sortiert. Aus der Übersicht ist erkennbar, dass die Phasen relativ gleichmäßig in allen Vorgehensmodellen der befragten Beratungen vorkommen. Es gibt keine Phase, die nicht mindestens von sechs Beratungshäusern durchgeführt wird. Außerdem ist kein signifikanter Unterschied zwischen den Größenklassen der Beratungshäuser festzustellen. Dies verdeutlicht noch einmal den oben bereits festgestellten Procedure Charakter entsprechender Beratungsprojekte.

— 28 —

Art des Vorgehensmodells Ausnahmslos alle befragten Beratungshäuser setzen für die Software-Auswahl ein linearsequentielles Phasenmodell ein. Die einzelnen Phasen müssen demnach vollständig abgeschlossen sein, damit die nächste Phase begonnen werden

kann. Diese

Vorgehensweise lässt sich mit der grundlegenden Logik einer Auswahl begründen. Diese besteht ja darin, durch schrittweise Eliminierung der Alternativen die bestmögliche Variante zu finden. Im Sinne der Software-Auswahl wäre es demnach kaum sinnvoll, eine bereits begründet ausgeschlossene Software erneut in den Auswahlprozess aufzunehmen. Zwei Berater gaben allerdings an, dass das Modell grundsätzlich die Rückkopplung in vergangene Phasen erlaubt (entspricht dem Charakter eines Wasserfall-Modells). Dies sollte jedoch nur in Ausnahmefällen geschehen, bspw. wenn neue Aspekte oder veränderte Perspektiven im Sinne sich ändernder Rahmenbedingungen zu beachten sind. Außerdem können sich in der Beratungspraxis die einzelnen Phasen überschneiden. Die Soll-Anforderungen werden bspw. in der Regel nicht ausschließlich in der Phase Anforderungsdefinition formuliert, sondern lassen sich im Groben bereits während der Potentialanalyse feststellen.

Rollenkonzept mit Beteiligungsausprägungen Die Akteure in einem Software-Auswahl-Projekt sind das Beratungshaus, das beratene Klientenunternehmen sowie der/die Lieferant(en) der auszuwählenden Software. Innerhalb des Beratungshauses sind in der Regel die auf Software-Auswahl spezialisierten Berater tätig. Für technische Fragestellungen und spezialisierte fachliche Inhalte wie bspw. Steuerrecht, Datenschutz und Unternehmensarchitektur werden zusätzliche Experten aus dem Beratungshaus zum Projekt hinzugezogen. In der Vorauswahlphase wird die Marktrecherche bei einem der mittelgroßen Beratungshäuser durch eine interne ResearchAbteilung unterstützt, die Zugriff auf zum Teil kostenpflichtige Datenbanken hat. In einem anderen mittelgroßen Beratungshaus werden während der Anforderungsdefinition bereits Berater für die spätere Software-Einführung einbezogen, um die Korrektheit der Dokumente für dieses geplante Folgeprojekt sicherzustellen. Aus dem Klientenunternehmen sind einerseits die Auftraggeber als Entscheidungsbefugte am Projekt beteiligt. Andererseits sind Mitarbeiter aus den (von der späteren Software-

— 29 —

Einführung betroffenen) Fachabteilungen und der IT in das Projekt involviert. Sie sind dabei entweder direkt im Projektteam vertreten oder stehen als Informationslieferanten bspw. im Rahmen der Ist-Analyse zur Verfügung. Der Lieferant der auszuwählenden Software kann entweder der eigentliche SoftwareHersteller oder ein Vertriebspartner desselbigen sein. Wichtig für die Auswahl ist hierbei lediglich, dass die geplante Einführung der Software durch bzw. mit diesem Partner vorgenommen wird. In der Mehrheit aller Projekte teilen sich das Beratungshaus und das Klientenunternehmen die Prozessverantwortung. Dabei trägt das Beratungshaus die Verantwortung für die ordnungsgemäße

Durchführung

des

Auswahl-Prozesses

und

die

einzelnen

Phasenergebnisse. Das Klientenunternehmen hingegen hat die Entscheidungsbefugnis hinsichtlich der Abnahme der Arbeitsergebnisse und damit des Abschlusses einer Phase. Der Klient folgt zwar in den meisten Fällen den Empfehlungen der Berater. Mit Blick auf die Akzeptanz der Entscheidungen im weiteren Projektverlauf ist es jedoch von Vorteil, wenn der Berater keine Entscheidungsgewalt besitzt. Dass die gesamte Auswahl ohne personelle Beteiligung des Klientenunternehmens allein durch eine externe Unternehmensberatung durchgeführt wird, kommt nach Angaben der Befragten in der Praxis sehr selten vor. Insbesondere in brisanten Situationen, in denen besonderer Zeitdruck oder Personalmangel seitens des Klientenunternehmens vorherrscht, erteilen die Klienten diese Art von Aufträgen.

Zeitlicher Rahmen des Software-Auswahl-Prozesses Hinsichtlich des zeitlichen Rahmens eines Software-Auswahl-Prozesses oder der Dauer einzelner Phasen konnten die befragten Berater lediglich Schätzwerte in Form von minimalen oder maximalen Zeiträumen angeben. Grundsätzlich ist die Projektlaufzeit stark von den jeweiligen Rahmenbedingungen abhängig. Diese betreffen zum einen den Funktionsumfang der auszuwählenden Software, da z.B. die Auswahl eines vollständigen ERP-Systems längere Zeit in Anspruch nimmt als die Auswahl eines Dokumentenmanagementsystems. Zum anderen sind die eventuell bereits geleisteten Vorarbeiten, die Vorstellungen bezüglich der Detailtiefe der Auswahlkriterien sowie die zur Verfügung stehenden personellen Ressourcen des Klientenunternehmens für die benötigte Zeit ausschlaggebend. — 30 —

Das absolute Minimum für eine Software-Auswahl beträgt dabei ein bis zwei Monate (unter optimalen Bedingungen) und die maximal benötigte Zeit wurde auf sechs Monate geschätzt. Mehrheitlich (von acht Befragten) wurde die durchschnittliche Projektlaufzeit auf drei Monate beziffert. Hinsichtlich der Zeiträume der einzelnen Phasen kann festgehalten werden, dass die Phasen bis zur Verabschiedung der Soll-Anforderungen mehr Zeit in Anspruch nehmen als der sich anschließende „eigentliche“ Auswahlprozess.

Messgrößen im Vorgehensmodell Im Rahmen der Interviews wurden die Berater auch dahingehend befragt, ob sie Messgrößen oder Kennzahlen zum Controlling der einzelnen Projektphasen oder des Gesamtprojektes einsetzen. Hierzu wurden keine inhaltlichen Vorgaben gemacht. Lediglich die zwei kleinsten Beratungen haben diese Frage vollständig verneint. Die anderen Beratungshäuser setzen vor allem klassische, aus dem Projektmanagement etablierte kosten- und zeitbezogene Kennzahlen ein. Dabei werden einerseits die Einhaltung des Gesamtbudgets als auch die Phasen-Aufwände betrachtet. Andererseits erfolgt die Kontrolle bezüglich der Einhaltung des Projektplanes und der Meilensteine. Ein mittelgroßes Beratungshaus setzt in den Phasenübergängen sogenannte „quality gates“ ein, in denen mittels qualitativer (weicher) Kriterien sowohl die Existenz und die Vollständigkeit bzw. der Reifegrad der Dokumente als auch die Verfügbarkeit von Personen im Hinblick auf die jeweils nächste Phase überprüft werden. Zusätzlich zu den genannten Messgrößen beinhaltet das common-practice-Vorgehensmodell weitere von uns vorgeschlagene Messgrößen.

3.2 Phasen des Vorgehensmodells Im Folgenden werden nun die Phasen des Common-Practice-Vorgehensmodells dargestellt. Dabei wird jede Phase mittels der in ihr enthaltenen Aktivitäten, der Phasenergebnisse und der anwendbaren Messgrößen beschrieben. 3.2.1 Erste Phase: Projektinitiierung Zur erfolgreichen Projektdurchführung sind nach der Erteilung des Projektauftrages durch den Klienten zunächst allgemeine vorbereitende Tätigkeiten unerlässlich. Diese finden in

— 31 —

der ersten Phase des Software-Auswahl-Prozesses, der Projektinitiierung statt. Sie ist bei sieben der befragten Unternehmen expliziter Bestandteil des Vorgehensmodells und wird bspw. als Vor-Phase oder Einsatzkonzept bezeichnet. Bei zwei weiteren Beratungshäusern sind einzelne Aktivitäten dieser Phase zum Teil implizit in der Analysephase enthalten. Die verbleibenden vier Beratungshäuser machten keine Aussagen zu einer solchen Prozessphase.

Da

es

sich

bei

diesen

jedoch

um

mittelgroße

und

große

Unternehmensberatungen handelt und die Software-Auswahl generell in Projektform durchgeführt wird, kann davon ausgegangen werden, dass die nachfolgend genannten Tätigkeiten auch ohne explizite Nennung innerhalb der jeweiligen Vorgehensmodelle ausgeführt werden. Wahrscheinlich sind die Tätigkeiten in diesen Fällen eher in einem übergeordneten Modell für die grundsätzliche Durchführung von Beratungsprojekten (einem sog. Meta-Modell) enthalten. Die organisatorischen Vorbereitungen umfassen das Staffing, also die Zusammenstellung des Projektteams sowie die Festlegung der Projektorganisation inklusive der notwendigen Kommunikationswege. Der Personaleinsatz seitens des Beratungshauses wird in der Regel bereits während der Angebotsphase festgelegt. Die Einbindung der Mitarbeiter des Klientenunternehmens in das Projektteam erfolgt jedoch an dieser Stelle. Ein wichtiges Erfolgskriterium für die Projektdurchführung, vor allem hinsichtlich der Termintreue, ist dabei die ausreichende Freistellung der Mitarbeiter von ihren alltäglichen Aufgaben. Neben der konkreten Teamzusammenstellung und der Festlegung der Projektleitung werden außerdem die organisatorischen Entscheidungsgremien bspw. in Form eines Lenkungsausschusses

etabliert

und

ein

entsprechendes

Kommunikationskonzept

ausgearbeitet. Einer der befragten Berater berichtete im Interview, dass in der Beratungspraxis „leider“ überwiegend per e-Mail kommuniziert würde. Für eine verbesserte Kommunikation zwischen allen Projektbeteiligten kann bspw. eine webfähige Projekt-Datenbank eingesetzt werden, in der alle aktuellen Projektdokumente für jeden zugreifbar abgelegt sind. In

diesem

Zusammenhang

definiert

ein

kleines

Beratungshaus

ferner

eine

Projektbeteiligungsstrategie, welche die (indirekte) Einbeziehung aller von der Software betroffenen Mitarbeiter zum Ziel hat. Um diese in regelmäßigen Abständen bspw. über den aktuellen Projektstatus zu informieren, können Kommunikationsmittel wie eine Mitarbeiter-Zeitung oder das Intranet genutzt werden.

— 32 —

Eine weitere wichtige Tätigkeit in dieser Phase ist die Festlegung der Projektziele. Hierbei werden zum einen die strategischen Ziele, welche die auszuwählende Software unterstützen soll, festgelegt. Diese Ziele müssen vor allem mit den grundsätzlichen Unternehmenszielen und -strategien des Klientenunternehmens abgestimmt werden. Zum anderen werden operative Ziele, die durch den späteren Einsatz der Software verfolgt werden sollen, definiert. Diese können bspw. die Steigerung der Effizienz der Geschäftsprozesse und damit verbundene konkrete Kostensenkungen betreffen. Die zeitliche Projektplanung sowie die Festlegung der geplanten Vorgehensweise innerhalb

des

Projektes

ist

ebenfalls

eine

durchzuführende

Aufgabe

in

der

Projektinitiierungsphase. Dabei orientiert sich der Projektplan mit den Meilensteinen in der Regel an den Phasen und Aktivitäten des Vorgehensmodells. In diesem Plan sind neben dem zeitlichen Ablauf des Projektes auch die Festlegung der Verantwortlichkeiten bezüglich der auszuführenden Aufgaben zwischen dem Klienten und dem Beratungshaus enthalten. Zur Erstellung eines solchen Projektplans nutzen sechs der befragten Beratungshäuser entweder das Programm Project von Microsoft oder selbst erstellte ExcelVorlagen. Ferner umfasst die Tätigkeit der Budgetierung zwei wesentliche Aspekte. Im Rahmen einer Projektbudgetplanung erfolgt die Verteilung der finanziellen Ressourcen auf die einzelnen Projektphasen. Im Hinblick auf die auszuwählende Software wird zunächst der maximale Kostenrahmen

abgesteckt,

denn

dieser

beeinflusst

auch

den

Umfang

und

Detaillierungsgrad des Software-Auswahl-Prozesses. Das Ergebnis der Projektinitiierung ist demnach eine umfassende Projektdefinition, die in mehreren Dokumenten schriftlich festgehalten wird und als Basis für ein laufendes Projektcontrolling zur Verfügung steht. Eine mögliche Messgröße für diese einleitende Projektphase kann die qualitative Beurteilung der Adäquanz der Projektplanung sein. Hierzu kann man insbesondere den Projektplan mit Erfahrungen aus bereits durchgeführten Projekten vergleichen und daraus beurteilen, inwieweit eine Planeinhaltung wahrscheinlich ist. Außerdem kann die Beurteilung der Erfolgswahrscheinlichkeit hinsichtlich des Gesamtprojektes auf Basis einer Risikoanalyse erfolgen. In dieser werden organisatorische, technische, terminliche, kapazitive, psychologische und Kosten-/Nutzen-Risiken [Aren04, 298-299] hinsichtlich ihres Gefahrenpotentials untersucht. Die Beurteilung, inwieweit

— 33 —

diese Risiken mittels geeigneter Maßnahmen bewältigt werden könnten, lässt Rückschlüsse auf den zu erwartenden Projekterfolg zu.

3.2.2 Zweite Phase: Potentialanalyse Die Phase der Potentialanalyse stellt, beginnend mit dem Kick-Off Meeting, den offiziellen Anfang des Auswahl-Projektes dar. Das Kick-Off Meeting dient dabei v.a. der Information und Einweisung der Projektteammitglieder bezüglich des kommenden Projektverlaufs. In einem ersten Schritt erfolgt die Aufnahme und Analyse der Ist-Situation im Klientenunternehmen. Diese erfolgt zusammen mit den Mitarbeiten des Klienten und basiert auf Interviews oder Workshops. Dabei werden in erster Linie die vorhandenen Geschäftsprozesse identifiziert, dokumentiert und analysiert. Aber auch die im Unternehmen vorhandene IT-Landschaft wird hinsichtlich ihrer aktuellen Leistungs-, Integrations-, Anpassungs- und Entwicklungsfähigkeit analysiert. Außerdem werden die Organisationsstruktur und das vorhandene Steuerungssystem in Bezug auf ihren derzeitigen Wertbeitrag zur Unterstützung der Unternehmensleistung (im Sinne des ITBusiness-Alignment) bewertet. Da laut Auskunft einiger Interviewpartner in vielen Unternehmen keine ausführliche Dokumentation der vorhandenen Geschäftsprozesse vorliegt, stellt ihre Modellierung ebenfalls eine wichtige Tätigkeit in dieser Projektphase dar. Diese kann durch die Verwendung von anpassbaren Referenzprozessen erheblich vereinfacht werden. Ein Beratungshaus verfügt bspw. über einen solchen Referenzprozesskatalog speziell für die Pharma-Branche. Die am häufigsten für diese Aufgabe verwendeten IT-Werkzeuge sind laut Auskunft der befragten Berater MS Visio und die ARIS™ Suite der IDS Scheer AG. Sollte die Software-Auswahl ein Teilprojekt eines übergeordneten Projektes sein, in dessen Rahmen bereits eine Geschäftsprozessanalyse stattgefunden hat, so ist die Übernahme dieser Dokumente aus Gründen der Konsistenz sinnvoll. Anhand der erarbeiteten Dokumentation des Geschäftsprozess-Modells kann nun festgelegt werden, welche Geschäftsprozesse von der auszuwählenden Software unterstützt werden sollen. Hierzu werden die vorhandenen Prozesse hinsichtlich ihres Optimierungspotentials untersucht. Dabei werden zwar auch die Anforderungen und Wünsche von Mitarbeitern des Klientenunternehmens berücksichtigt. Die Ermittlung möglicher Verbesserungen

— 34 —

erfolgt in der Regel jedoch durch die Berater, da diese eine übergeordnete Sicht auf die Geschäftsprozesse haben und ihr Erfahrungswissen einbringen können. Die Prozesse mit dem dringendsten Verbesserungspotential bzw. dem höchsten Nutzenpotential bestimmen maßgeblich den Umfang der auszuwählenden Software und damit den sog. Projekt-Scope. Basierend auf den ermittelten Verbesserungspotentialen erfolgt im Sinne eines Grobkonzepts eine erste Auflistung der groben Anforderungen an die auszuwählende Software. Anhand

dieses

ersten

Anforderungsprofils

kann

nun

eine

Machbarkeits-

und

Wirtschaftlichkeitsanalyse durchgeführt werden. Hierbei wird festgestellt, ob die aus den geplanten Geschäftsprozessen resultierenden Anforderungen überhaupt mit einer am Markt vorhandenen Software realisierbar sind und inwieweit die bisherige Kostenplanung eingehalten werden kann. Laut Niedereichholz betrifft die Machbarkeitsstudie außerdem die betriebliche Machbarkeit [Nied03, 302]. Dabei wird auch geprüft, ob die geplante Einführung der Software unter den technischen, gesetzlichen und sonstigen betrieblichen Rahmenbedingungen überhaupt in vollem Umfang umsetzbar wäre. Die angestrebten Prozessverbesserungen sowie der daraus resultierende Projekt-Scope hinsichtlich der auszuwählenden Software werden am Ende dieser Phase vom entsprechenden Entscheidungsgremium des Klientenunternehmen verabschiedet. Eine wichtige Messgröße dieser Projektphase ist die Überprüfung der Qualität der erzeugten Dokumente. Dies betrifft vor allem deren Vollständigkeit und Korrektheit, aber auch deren Umsetzbarkeit. Sollten sich die Geschäftsprozesse als zu umfangreich und die damit verbundenen Anforderungen als zu unrealistisch erweisen, müssen die vorherigen Aktivitäten nochmals mit dem Ziel der Reduzierung des Projektumfangs durchgeführt werden. Selbstverständlich erfolgt am Ende der Projektphase die Kontrolle hinsichtlich der Einhaltung der Kosten und der geplanten Zeit im Rahmen des Projektmanagements. Aus Sicht des Beratungshauses ist es außerdem interessant zu prüfen, inwieweit die eigenen Empfehlungen in Bezug auf die anzustrebenden Verbesserungen vom Klienten akzeptiert wurden oder nicht. Diese Messung kann zu Rückschlüssen bezüglich der eigenen Beratungsqualität beitragen.

— 35 —

3.2.3 Dritte Phase: Anforderungsdefinition Im Rahmen der sich anschließenden Anforderungsdefinition werden die konkreten Geschäftsprozesse anhand komplexer Geschäftsvorfälle formuliert. Aus diesen SollProzessen werden im Rahmen von Workshops mit den Fachabteilungen und der ITAbteilung des Klienten Anforderungen an die Software definiert. Nach Stahlknecht / Hasenkamp können diese in folgende Kriteriengruppen gegliedert werden: fachinhaltliche Kriterien (insbesondere die Funktionalitäten der Software), Kriterien zur Hardware und zur Systemsoftware („Plattform“), Kriterien zur Netzfähigkeit sowie benutzerbezogene Kriterien [StHa05, 301]. Außerdem werden eventuell weitere Anforderungen hinsichtlich des Datenschutzes, gesetzlicher Richtlinien und der IT-Sicherheit aufgenommen. Die Kriterienkategorien zur Systemeinführung und zum Systemeinsatz, zur Anschaffung (insbesondere die Kosten betreffend) und bezüglich des Software-Anbieters [StHa05, 302] vervollständigen die Aufzählung der möglichen Anforderungen. Als Entscheidungsgrundlage für die Vorauswahl, die in der nächsten Phase stattfindet, werden vernehmlich die Kriterien bezüglich des Software-Anbieters bzw. -Lieferanten herangezogen. Diese werden auch als K.o.-Kriterien bezeichnet und betreffen bspw. die Unternehmensgröße, die Supportsicherheit, die Marktbeständigkeit, das Ansehen, die Branchenerfahrung, den Innovationsgrad des Anbieters und vor allem die einschlägigen Referenzen. Der aus diesen Anforderungsinhalten entstehende Kriterienkatalog (auch Lastenheft) wird bei zwei Beratungshäusern gesondert in einem Workshop nach Relevanz für den Klienten gewichtet. Die Ergebnisse dieser Projektphase sind demnach einerseits die dokumentierten SollGeschäftsprozesse und andererseits ein gewichteter Kriterienkatalog für die sich anschließende eigentliche Software-Auswahl. Insbesondere am Ende dieser Phase ist die Evaluation der Dokumente von entscheidender Bedeutung. Denn sind diese nicht vollständig oder korrekt, wirkt sich dieser Mangel negativ auf den ganzen nachfolgenden Prozess der Auswahl aus und führt möglicherweise zu falschen Entscheidungen.

3.2.4 Vierte Phase: Vorauswahl Ist die Prüfung der Dokumente der vorigen Phase positiv abgeschlossen und diese vom Entscheidungsgremium genehmigt worden, beginnt die Phase der Vorauswahl potentieller — 36 —

Software-Lieferanten. Dies erfolgt in den meisten Fällen mittels einer Sondierung des am Markt vorhandenen Software-Angebotes. In einem dem Beratungshaus nicht vertrauten Software-Umfeld wird eine Marktrecherche anhand von Internetseiten, Prospekten oder, wie bereits erwähnt, auch unter Beteiligung einer internen Research-Abteilung vorgenommen. In der Regel ist der Klient an dieser Tätigkeit nicht beteiligt und überlässt die Zusammenstellung dieser ersten Anbieterliste dem Beratungshaus. In einem sehr etablierten Software-Umfeld, wie bspw. bei ERP- oder PPS-Systemen, haben drei Viertel der Beratungshäuser eine eigenen Datenbank mit potentiell geeigneten Anbietern erstellt, anhand derer sie eine Vorauswahl vornehmen können. Zwei kleine Beratungshäuser hingegen nehmen die Selektion der potentiellen Anbieter auf Basis ihrer Erfahrungen vor. Und ein selbständiger Berater nutzt für diese Aufgabe die Rechercheplattform ITMatchmaker der Trovarit AG. 13 Da die in der nächsten Phase geplante Ausschreibung mit einem dem Projekt angemessenen Aufwand zu bewältigen sein soll, muss die als Ergebnis der Marktrecherche vorliegende

Anbieterliste

auf

maximal

zehn

potentielle

Software-Lieferanten

eingeschränkt werden. Diese sogenannte „long list“ wird mittels der zuvor definierten K.o.-Kriterien erstellt. Dabei erfolgt eine Prüfung bezüglich der Erfüllung der Mindestanforderungen. Auch diese Selektion wird in der Regel vom Beratungshaus ohne Klientenbeteiligung vorgenommen, wodurch besonderer Wert auf die transparente Dokumentation der Vorauswahl gelegt werden muss, damit die Entscheidungen jederzeit nachvollziehbar sind. Die long list der potentiell geeigneten Software-Lieferanten wird am Phasenende vom Klienten abgenommen. Laut Auskunft eines Beraters kann die gesamte Phase der Vorauswahl im Einzelfall auch vollständig entfallen, wenn diese bereits durch den Klienten vorgenommen wurde, überwiegend politisch motiviert war oder auf anderen klientenspezifischen Präferenzen (wie bspw. der generellen Bevorzugung der jeweils größten Anbieter) basierte. Mögliche Messgröße für diese Phase sollten auf eine Qualitätskontrolle der Vorauswahl zielen. Diese bezieht sich bspw. auf die Nachvollziehbarkeit und Objektivität der getroffenen Entscheidungen. Außerdem ist eine Messung der klientenseitigen Akzeptanz der Beratungsempfehlung zweckmäßig.

13

Für weiterführende Literatur zum Einsatz des IT-Matchmakers siehe [SoTr07].

— 37 —

3.2.5 Fünfte Phase: Ausschreibung Das Ziel der Ausschreibungsphase besteht in der Einholung aussagekräftiger Angebote der zuvor selektierten Software-Lieferanten, die hierfür zum ersten Mal aktiv am Auswahlprozess

beteiligt

werden.

Hierfür

stellten

die

Berater

verschiedene

Vorgehensweisen vor: Zwölf der befragten Beratungshäuser versenden den in der dritten Phase erarbeiteten Anforderungskatalog in seiner ursprünglichen Form an die Anbieter. Ein Beratungsunternehmen mittlerer Größe entwickelt aus dem kundenspezifischen Anforderungsprofil einen anonymisierten Fragebogen, der als Grundlage für die Angebotseinholung dient. Ein kleines Beratungshaus versendet neben dem Anforderungskatalog außerdem eine zuvor mit dem Klienten erarbeitete Sammlung von Geschäftsvorfällen, die als Story Boards für die spätere Software-Präsentation dienen sollen. Dieses und ein weiteres kleines Beratungshaus sehen in ihrem Vorgehensmodell keine Phase der Angebotsbewertung vor und erwarten daher auch keine schriftliche Angebotsabgabe. Sie überprüfen die Eignung der Software und die Fähigkeiten der Anbieter im Rahmen der Präsentationen, die in der übernächsten Phase erläutert werden. Dieses Vorgehen ist jedoch aus Aufwandsgründen nur in solchen Fällen durchführbar, in denen die Zahl der Anbieter bereits in der Vorauswahl auf drei bis maximal fünf eingeschränkt wurde. In den anderen Fällen sind die Software-Lieferanten aufgefordert, innerhalb eines bestimmten Zeitraumes (maximal sechs Wochen) ein erstes Angebot hinsichtlich der Anforderungserfüllung durch ihre Software und der zu erwartenden Kosten abzugeben. Die Form der Angebotsabgabe – schriftliche Ausführungen oder tabellarische Aufstellung – liegt dabei im Ermessen der Anbieter. Die Kostenübersicht sollte allerdings aus den zu erwartenden Einführungskosten, den Lizenzkosten und den laufenden Wartungskosten über einen bestimmten Zeitraum bestehen. Die Leistung der Beratungshäuser beschränkt sich in dieser Phase des Auswahlprozesses hauptsächlich auf die Organisation der Ausschreibung, wobei die Berater zur Klärung offener Fragen als Ansprechpartner für die Software-Lieferanten zur Verfügung stehen. Als mögliche Messgröße bietet sich hierbei die Häufigkeit der Rückfragen durch die Lieferanten an. Ist diese Zahl besonders hoch, so ist das ein Hinweis auf nicht eindeutige und damit unzureichende Ausschreibungsunterlagen.

— 38 —

Um in die anschließende Phase der Angebotsbewertung eintreten zu können, müssen am Ende der Ausschreibungsphase alle Angebotsunterlagen in vollständiger Form vorliegen. Diesbezüglich bieten sich die Anzahl der eingegangenen Angebote sowie die Einhaltung der vorgegebenen Ausarbeitungsfrist durch die Software-Lieferanten als mögliche Messgrößen an. Vor allem letztere Größe bietet einen indirekten Hinweis auf die Projektmanagementfähigkeiten des Beraters.

3.2.6 Sechste Phase: Angebotsbewertung Nachdem die Angebote der Anbieter beim Beratungshaus eingegangen sind, werden sie in eine vergleichbare Form überführt. Hierzu werden die Antworten bezüglich der jeweiligen Anforderungskriterien in eine tabellarische Form gebracht, wofür sieben der befragten Unternehmen explizit eine selbst erstellte Bewertungsmatrix bspw. als Excel-Dokument bereitstellen. In diesem Zusammenhang werden die Kriterien bei vier weiteren Beratungshäusern gemeinsam mit den Klientenmitarbeitern gewichtet bzw. eine mögliche Gewichtung durch die Berater vorgeschlagen. Außerdem stellen die Beratungen in den meisten Fällen ein Scoring-Modell [HHRo04, 465] als Grundlage für die Bewertung bereit oder erarbeiten dieses gemeinsam mit dem Klienten. Sechs Beratungshäuser nutzen hierbei ein entsprechendes Punkteschema bspw. mit 0 als schlechtestem und 5 als bestem Wert. Eine weitere Variante der vergleichenden Bewertung der Angebote wenden zwei andere Beratungen an, indem sie (ähnliche) Ordinalskalen

mit

den

Kategorien

„im

Standard

abbildbar“,

„Anpassungen

/

Parametrisierung“ und „Programmierung notwendig“ nutzen. Dabei spiegeln diese eine absteigende Rangfolge wider. Die daraus entstehende gewichtete Entscheidungsmatrix macht eine übersichtliche und vergleichbare Bewertung der Angebote hinsichtlich ihres Erfüllungsgrades möglich. Im Sinne einer Nutzwertanalyse 14 werden von fünf Beratungen außerdem die abgegebenen Kostenangaben in die Betrachtung einbezogen. Da diese jedoch zu diesem Zeitpunkt der Auswahl lediglich als Richtangebote zu verstehen sind, besitzen sie keine entscheidende Priorität.

14

Zu den einzelnen Schritten der Nutzwertanalyse siehe [StHa05, 303]

— 39 —

Da den Mitarbeitern des Klientenunternehmens häufig die nötigen fachlichen Kenntnisse für

eine

objektive

Beurteilung

der

Antworten

fehlen,

führen

acht

der

Beratungsunternehmen diese eigenständig durch. Lediglich drei Beratungshäuser nehmen die Bewertung gemeinsam mit den Mitarbeitern des Klienten vor bzw. überlassen sie unter Anleitung durch die Berater dem Kunden. Die in der Literatur empfohlenen Sensitivitätsanalysen zur Reduzierung der Subjektivität der Einschätzungen [StHa05, 304] werden dabei allerdings von keinem Beratungshaus durchgeführt. In Abhängigkeit der erreichten Abdeckungsgrade und der zu erwartenden Kosten lässt sich im Ergebnis eine Rangliste der potentiellen Anbieter erstellen. Diese wird nun als Grundlage für die Auswahl der weiter zu betrachtenden Anbieter („short list“) herangezogen. Zusätzlich dazu bieten zwei Beratungshäuser eine qualitative Einschätzung hinsichtlich der Eignung der jeweiligen Anbieter in Form einer SWOT-Analyse 15 bzw. einer Pro-Contra-Aufstellung an. Abschließend geben alle Berater eine Empfehlung für die am besten geeigneten Anbieter ab und schlagen eine short list mit drei bis maximal fünf Anbietern vor, die zur Präsentation in der nächsten Phase des Auswahlprozesses eingeladen werden sollten. Auch hier liegt die endgültige Entscheidung wieder beim Klienten, wobei alle befragten Berater aus ihrer Erfahrung heraus berichteten, dass die Empfehlung des Beratungshauses üblicherweise gutgeheißen und angenommen wird. Interessante Messgrößen dieser Projektphase sind die Beurteilungen hinsichtlich des erbrachten Aufwandes zur Vereinheitlichung und Bewertung der Angebote sowie der Qualität der abgegebenen Angebote. Ergibt die Messung hinsichtlich der Qualität der Angebote und dem Aufwand zu deren Vereinheitlichung bspw. einen ungünstigen Wert, so lässt dies auf unzureichende Ausschreibungsunterlagen schließen. Ist die Beurteilung der Angebote hingegen sehr aufwendig, so sollte eventuell über eine Verbesserung des eingesetzten Scoring-Modells oder der Bewertungsmatrix nachgedacht werden.

15

Profil jedes Software-Lieferanten hinsichtlich Stärken und Schwächen (des Lieferanten selbst) sowie Chancen und Risiken (bezogen auf die mögliche Software-Einführung / Zusammenarbeit).

— 40 —

3.2.7 Siebte Phase: Software-Präsentation Die ausgewählten Anbieter werden nun zu einer praktischen Demonstration ihrer Software aufgefordert. Solche Präsentationen sind in allen Vorgehensmodellen der befragten Unternehmensberatungen vorgesehen, wobei sie jedoch in verschiedenen Ausprägungen stattfinden. So führen neun der befragten Unternehmen jeweils eine Präsentation mit jedem Anbieter durch, drei Beratungen hingegen sehen zwei Präsentationsrunden vor. Und ein großes Beratungshaus lässt die Anbieter eine Testversion ihrer Software installieren. Sind in dieser Phase Software-Präsentationen in Form von Workshops vorgesehen, trifft das Projektteam im ersten Schritt die entsprechenden Vorbereitungen. Dazu werden zunächst einige Use Cases, also Geschäftsszenarien, definiert, anhand derer die Anbieter die Funktionalitäten ihrer Software demonstrieren sollen. Diese können sowohl einfache als auch komplexe Geschäftsvorfälle widerspiegeln und werden mit einheitlichen Echtdaten aus dem Klientenunternehmen hinterlegt. Außerdem muss neben der räumlichen Planung eine Terminplanung bezüglich des Umfangs und der Reihenfolge der jeweiligen Präsentationen vorgenommen werden. In Abhängigkeit von der Gesamtkomplexität der auszuwählenden Software werden in der Praxis Workshops von ½ bis zu zwei Tagen je Anbieter terminiert. Aus Gründen der besseren Vergleichbarkeit sollten diese in einer überschaubaren Zeitspanne aufeinander folgen. Laut Auskunft eines befragten Beraters kommt es in der Realität jedoch häufiger zu terminlichen Verzögerungen, wodurch sich die gesamte Präsentationsphase über mehrere Wochen erstrecken kann. Neben dem zusätzlichen Zeitverlust – die Anbieter bekommen ohnehin einige Woche Vorbereitungszeit – besteht hierbei ein weiterer Nachteil darin, dass die unmittelbaren Erfahrungen der Präsentationen nicht mehr detailliert in die Entscheidungsfindung einfließen können. Von daher ist eine wichtige Aufgabe des Beraters, auf eine straffe Projektdurchführung zu achten. Des Weiteren benennt das Klientenunternehmen die Mitarbeiter, die an den Präsentationen teilnehmen bzw. die eine Bewertung abgeben dürfen. Diese können in der Praxis von den Projektteammitgliedern abweichen, wenn bspw. die Geschäftsführung oder Endbenutzer aus den Fachabteilungen anwesend sind. Als abschließende Vorbereitung für die spätere Beurteilung der Präsentationen bzw. der Software wird ein Bewertungsschema, das sich an den zu zeigenden Use Cases bzw. Funktionalitäten orientiert, erarbeitet. — 41 —

Während der Präsentation hat jeder Anbieter die Möglichkeit, die fachlichen Funktionalitäten und die Handhabung seiner Software zu demonstrieren sowie eventuell offene Fragen oder Probleme zu klären. Neben einer allgemeinen Präsentation der Softwarefunktionalitäten muss außerdem die Umsetzung konkreter klientenspezifischer Anforderungen anhand der zuvor ausgearbeiteten und den Anbietern zur Verfügung gestellten Geschäftsvorfälle erläutert werden. Überdies führt ein Beratungshaus mittlerer Größe eine separate technische Betrachtung der Software („Impact Analyse“) in einem Workshop mit Vertretern der IT-Abteilung des Klienten durch. Sollten zwei Präsentationszyklen durchgeführt werden, so findet nach der ersten Präsentation eine Beurteilung der Ergebnisse und eine erneute Reduzierung auf einen oder zwei favorisierte Anbieter statt. Die erste Softwarepräsentation zielt dann im Schwerpunkt der Bewertung vor allem auf die Funktionsabdeckung durch die unveränderte Standardsoftware. Die Klärung der klientenspezifischen Anforderungen und die Vorführung der Geschäftsszenarien mit Echtdaten des Klienten erfolgt danach für die verbliebenen Anbieter im zweiten Schritt im Rahmen ausführlicher mehrtägiger Workshops. Unabhängig von der Art der Softwarepräsentationen werden die Einführungsstrategie und das geplante Projektmanagement seitens des Anbieters im Hinblick auf die Passfähigkeit zum Klientenunternehmen beurteilt. Bei allen Präsentationen übernimmt üblicherweise ein Berater die Moderation, um sowohl die Einhaltung der zeitlichen Rahmensetzung als auch die Vollständigkeit der Ergebnisse sicherzustellen. Unmittelbar im Anschluss an jede Präsentation wird diese mit Hilfe des Bewertungsbogens von allen Teilnehmern beurteilt, wobei ähnliche Skalen wie in der Angebotsbewertung verwendet werden. Sieben der befragten Beratungsunternehmen überlassen die Bewertung der Präsentationen den Klientenmitarbeitern und leisten dabei lediglich Hilfestellung. Auf Wunsch des Klienten können allerdings auch die Berater Bewertungen abgeben. Diese gemeinsame Bewertung ist bei vier Beratungen das übliche Vorgehen. Die endgültige Auswertung findet jedoch erst in der nächsten Phase statt. Zusätzlich zu den Software-Präsentationen sind bei zwei mittelgroßen und einem kleinen Beratungshaus auf Wunsch Referenzbesuche bei ehemaligen Kunden des SoftwareLieferanten vorgesehen. Hierbei können sich die Klientenvertreter einen unmittelbaren Eindruck vom praktischen Einsatz der Software verschaffen und darüber hinaus Erfahrungswerte bezüglich der Einführung oder des Supports einholen. — 42 —

Eine andere Variante, um die Praktikabilität der auszuwählenden Software zu beurteilen, ist

die

Durchführung

einer

Teststellung

innerhalb

des

Klientenunternehmens.

Voraussetzungen hierfür sind zum einen ausreichend zur Verfügung stehende zeitliche, personelle und technische Ressourcen des Klienten und zum anderen die vorherige Reduzierung der potentiellen Lieferanten auf maximal zwei. Nach der Installation der Software-Testversion werden in einem Zeitraum von bis zu sechs Wochen einige übliche Geschäftsvorfälle mittels der Software bearbeitet, was eine Bewertung der Funktionalität und der Handhabung der Software ermöglicht. Werden zu diesem Zeitpunkt des Auswahlprozesses noch mehrere Anbieter berücksichtigt, findet ein ausführlicher Vergleich – auch hinsichtlich der technischen Anforderungen – statt. Ferner spielt im Rahmen der Präsentationsphase die Sozialkompetenz der Anbieter bzw. deren Mitarbeiter eine bedeutende Rolle. Die weichen Faktoren, wie bspw. Sympathie zwischen den Beteiligten, können die Auswahlentscheidung trotz einer objektiven Vorgehensweise entscheidend beeinflussen. Man spricht daher auch von einem „Beauty Contest“, dem sich die Anbieter unterziehen müssen. Es wurde bereits erwähnt, dass die Einhaltung der Terminplanung in dieser Phase eine wichtige Messgröße hinsichtlich der Projektmanagement-Fähigkeiten der Berater darstellt. Aber auch die Prüfung der Qualität und Bewertbarkeit der von den Anbietern umgesetzten Use Cases stellt eine mögliche Messgröße dar. Ähnlich wie die Qualitätsbewertung der Angebote in der vorigen Phase lassen sich auch hier Rückschlüsse auf eine gute oder schlechte Vorbereitung der Präsentationen ziehen. 3.2.8 Achte Phase: Endauswahl Sind alle Software-Präsentationen durchgeführt und von den Teilnehmern mittels Bewertungsbögen beurteilt worden, findet in der Phase der Endauswahl die Gesamtbewertung auf Basis sämtlicher Ergebnisse des Auswahlprozesses statt. Hierfür werden im ersten Schritt die Bewertungsbögen aus den Software-Präsentationen ausgewertet, woraus sich wiederum eine Rangliste der Anbieter ergibt. Diese Rangfolge kann von derjenigen aus der Angebotsbewertung abweichen, wenn sich bspw. während der Präsentationen ein anderes Bild hinsichtlich der Funktionsabdeckung der Software ergeben hat. Von daher müssen beide Wertungen miteinander abgeglichen werden und in eine endgültige Entscheidungsmatrix überführt werden. Diese Aufgabe übernimmt wiederum das Beratungshaus. — 43 —

Außerdem fordern drei Beratungshäuser ein erneutes, aktualisiertes Kostenangebot von den Software-Anbietern ein. Aus ihrer Erfahrung berichteten die befragten Berater, dass dieses neue Angebot meist deutlich von dem ersten Angebot abweicht. Das liegt insbesondere darin begründet, dass die Anbieter in den Präsentationsworkshops ein besseres Verständnis bezüglich der Anforderungen erlangen und somit den Projektumfang sowie die benötigten Ressourcen konkreter einschätzen können. Anhand der vollständigen Entscheidungsmatrix und der Kostenanalyse erstellt das Beratungshaus eine endgültige Rangliste der potentiellen Anbieter und gibt in einem abschließenden Meeting mit dem Klienten eine finale Empfehlung ab. Auch hier liegt die endgültige Entscheidung für die zu implementierende Software und den entsprechenden Lieferanten selbstverständlich beim Klienten. Laut Auskunft eines Beraters einer mittelgroßen Unternehmensberatung wird den verbleibenden Anbietern jedoch nicht vollständig abgesagt. Sie werden als mögliche Alternativen vorgemerkt, wenn die Vertragsverhandlungen mit dem favorisierten Anbieter scheitern sollten. Hinsichtlich möglicher Messgrößen der Endauswahl können auch hier die Qualität der Auswahl und die Akzeptanz der Empfehlung beim Klienten ein Indiz für gute oder weniger gute Beratungsleistungen sein.

3.2.9 Neunte Phase: Vertrag Ist die Entscheidung für eine Software bzw. einen Lieferanten getroffen, bildet die Vertragsphase den letzten Schritt des Auswahlprozesses. Bevor der Klient mit dem Software-Lieferanten in die abschließenden Preis- und Vertragsverhandlungen eintritt, sehen zwei Beratungshäuser (ein kleines und ein großes) einen weiteren Arbeitsschritt vor, der einen korrekten Vertragsabschluss gewährleisten soll. Dieser betrifft erste Planungen des kommenden Software-Einführungs-Projektes und dient

somit

der

Schaffung

eines

gemeinsamen

Verständnisses

der

künftigen

Zusammenarbeit. Das große Beratungshaus entwickelt hierzu – gemeinsam mit dem Klienten

und

dem

Software-Lieferanten



zunächst

eine

allgemeine

Implementierungsstrategie. Dabei wird ein grober Stufenplan ausgearbeitet, in dem sich zum einen für eine schrittweise Einführung oder alternativ eine sogenannte „Big Bang“ — 44 —

Voll-Einführung entschieden wird und der zum anderen mögliche Risiken sowie notwendige Ressourcen definiert. Außerdem werden Strategien für das Change Management und die Projektteam-Ausbildung entwickelt sowie Standards und Richtlinien für die Implementierung festgelegt. Die kleine Beratung hingegen konkretisiert mit den Parteien die Anforderungen in Form von Grobspezifikationen für die einzelnen Unternehmensbereiche des Klienten. Das dabei entwickelte grobe Pflichtenheft für die Softwareeinführung bildet dann die gemeinsame Basis für die Vertragsverhandlungen. An den konkreten Preis- und Vertragsverhandlungen sind jedoch nur fünf der befragten Unternehmensberatungen beteiligt – und dies auch nur auf Wunsch des Klienten. Die Beteiligung reicht von der Begleitung des Verhandlungsprozesses durch die Berater bis hin zur Prüfung der Vertragsunterlagen. Für die Nicht-Beteiligung der Berater an den Verhandlungen gaben die Interviewpartner unterschiedliche Gründe an. Vor allem in den kleinen Beratungshäusern ist neben den knappen personellen Ressourcen auch oftmals nicht die fachliche (juristische) Kompetenz vorhanden, um eine korrekte Vertragsprüfung durchführen zu können. Auch die Wahrung der Neutralität der Berater wurde als Grund genannt. So gab ein Berater an, dass er grundsätzlich keine Kenntnis von den ausgehandelten Konditionen zwischen Klient und Software-Lieferant erlangen möchte. Sollte dies nämlich der Fall sein und er in späteren Projekten an erneuten Verhandlungen mit dem selben Software-Lieferanten beteiligt sein, könnte er diese durchaus als Druckmittel gegen den Lieferanten einsetzen und würde nicht mehr objektiv handeln. Ebenfalls aus Gründen der Fairness beteiligt sich ein mittelgroßes Beratungshaus, das selbst eigenentwickelte Software vertreibt, nicht an den Verhandlungen. Diese Phase und damit das gesamte Software-Auswahl-Projekt endet mit der Unterzeichnung des Vertrages durch das Klientenunternehmen und den SoftwareLieferanten. Ob nun das Beratungshaus aufgrund seiner Beratungsleistung auch für die folgende Software-Einführung engagiert wird, kann aus Sicht der Berater als Indikator für den Erfolg der Vorgehensweise bei der Software-Auswahl angesehen werden.

— 45 —

4 Vorgehensmodell der Software-Einführung 4.1 Allgemeines zum Vorgehensmodell Zu den Vorgehensmodellen im Beratungsfeld der Software-Einführung konnten in dieser Arbeit die Ergebnisse von 13 befragten Beratungshäusern untersucht werden. Mit Ausnahme eines kleinen Beratungshauses setzen alle befragten Unternehmensberatungen für die Durchführung von Software-Einführungs-Projekten ein eigenes Vorgehensmodell ein. Das Beratungshaus, das kein eigenes Modell nutzt, klärt zu Beginn des Projektes seine Beteiligung hinsichtlich des Projekt- und Krisenmanagements und geht im weiteren Projektverlauf nach der Vorgehensweise des jeweiligen Software-Lieferanten oder Klientenunternehmens vor. Als Begründung hierfür wurde angeführt, dass der Einführungsprozess in den verschiedenen Projekten zu unterschiedlich sei und die Berater daher sehr dynamisch auf die jeweilige Situation reagieren können müssen. Aus den einzelnen Interviewergebnissen der verbleibenden zwölf Beratungshäuser entstand das in Bild 5 dargestellte Vorgehensmodell der Software-Einführung. Im Unterschied zu dem Common-Practice-Vorgehensmodell des anderen untersuchten Beratungsfeldes kann diesem Modell unter Vorbehalt einer noch ausstehenden vertiefenden Untersuchung ein näherungsweiser Best-Practice-Charakter zugeschrieben werden. Diese Differenzierung lässt sich hauptsächlich damit begründen, dass die einzelnen Phasen des Vorgehensmodells zu über 90 % von allen Beratungshäusern 16 angewandt werden (wie in Bild 6 ersichtlich). Außerdem stimmen die jeweiligen Phaseninhalte der einzelnen Modelle der Beratungsunternehmen in höherem Maße überein. Obwohl das Vorgehensmodell aufgrund dieser Tatsache eine hohe Allgemeingültigkeit besitzt, ist es dennoch aktuell nicht als Referenzmodell zu klassifizieren. Hierzu müsste einerseits die der Analyse zugrunde liegende Fallzahl vergrößert, der best practice Charakter des Modells (auch anhand der Literatur) verifiziert sowie der Detaillierungsgrad der Beschreibung weiter verfeinert werden.

16

Das Beratungshaus, das kein eigenes Vorgehensmodell besitzt, wird in diese Betrachtung (und im weiteren Verlauf des Kapitels) nicht einbezogen.

— 46 —

Bild 5: Vorgehensmodell der Software-Einführung

— 47 —

Messgrößen

Ergebnis (Deliverables)

Auslösendes Ereignis

Beschreibung

SoftwareLieferant

Klientenunternehmen

Beratungshaus

Korrektheit Dokumente

x Vollständigkeit und

x Erfolgswahrschein-

lichkeit

Teammitglieder

x Aufgabenerfüllung

„Blueprint“-Dokumente

Kick-Off Meeting

Spezifikation

x Technische

management und Anwenderbedürfnisse

bzgl. Geschäftsprozesse, Informations-

x Anforderungsdefinition

Konzeption

Projektplanung

x Realistische

Projektdefinition

Projektauftrag

x Basisschulungen

und SW-Infrastruktur

x Bereitstellen der HW-

x Einführungsstrategie

organisation, -plan, zielen, -budget

x Festlegen von Projekt-

Projektinitiierung

Anforderungsumsetzg.

x Korrekte u. vollständige

für Anpassungen

x Earnd-Value-Analyse

Angepasste Software (inkl. Dokumentation) freigegeben

„Blueprint“-Dokumente freigegeben

Formulare / Reports

x Schnittstellen und

erweiterungen

x Individuelle Software-

x Customizing

Realisierung

x Testaufwand

x System-Antwortzeit

nahme

x Erfolg der Datenüberx Korrektheit der Daten

x Schulungserfolg x Fehlerklassen

Produktivsystem für Echtstart bereit

Softwaresystem für Produktivbetrieb freigegeben

x Organisation Support

x Datenmigration

Produktivsystem

x SW-Übertragung auf

x Anwenderschulungen

Schulungsmaterial

x Fertigstellung

Produktivvorbereitung

x Anzahl Fehler

Erfolgreiche Testdurchführung (inkl. Dokumentation)

Software für Tests freigegeben

x Systemtest

Acceptance Test

Integrations- und User

x Funktions-, Migrations-,

und Testpläne erstellen

x Testsystem einrichten

Test

bzw. Folgeprojekte

x Anzahl Nachbetreuung

x Anzahl Supportanfrag.

x Klientenzufriedenheit

Abschlussmeeting mit lessons learned

Offizielles „Go“ für Echtstart

Supportorganisation festlegen First Level Support

Inbetriebnahme SW Langfristige

Go Live & Support

Ableitung des Vorgehensmodells Die Grafik in Bild 6 verdeutlicht, dass die befragten Beratungshäuser, bis auf wenige Ausnahmen (weiße Lücken), alle die gleichen Prozessphasen in ihren Vorgehensmodellen vorsehen. Auf die erwähnten Ausnahmen, die in lediglich zwei Phasen des Vorgehensmodells auftreten, wird in den jeweiligen Phasenbeschreibungen näher eingegangen.

Software-Einführungs-Prozess Projektinitiierung

UB

Konzeption

Realisierung

Test

Produktivvorbereitung

Go Live & Support

Größe

x

x

x

x

x

x

B

x

x

x

x

x

x

x

x

x

x

x

D

x

x

x

x

x

E

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

I

x

x

x

x

x

J

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

F G

mittel

C

klein

A

K L

groß

H

x

x

Bild 6: Phasen des Software-Einführungs-Prozesses in den Vorgehensmodellen der untersuchten Beratungshäuser (weiß = Phase nicht enthalten)

Eine naheliegende Erklärung für die hohe Übereinstimmung der Vorgehensmodelle ist die Tatsache, dass mehrheitlich die Einführung von ERP-Software betrieben wird. Die SAP AG, als einer der führenden Anbieter solcher Software, hat eigens für die Einführung ihrer Software das Vorgehensmodell AcceleratedSAP (ASAP) 17 entwickelt. Die darin enthaltende Roadmap (Bild 7) hat sich als Standardvorgehen etabliert, weshalb sich viele Beratungshäuser bei der Entwicklung ihrer Modelle daran orientieren.

17

Diese Roadmap ist inzwischen ein Teil des SAP Solution Managers.

— 48 —

Bild 7: AcceleratedSAP Roadmap [GaLo01, 193] Art des Vorgehensmodells Hinsichtlich der Art des Vorgehensmodells ist zunächst festzuhalten, dass ein SoftwareEinführungs-Projekt in seinen Prozessschritten dem eines Softwareentwicklungsprojektes ähnelt.

Daher

lassen

sich

alle

Vorgehensmodellarten

der

Softwareentwicklung

grundsätzlich in dieses Beratungsumfeld übertragen. Die Vorgehensmodelle von drei Beratungshäusern weisen den Charakter eines WasserfallPhasenmodells auf. Rücksprünge in vorherige Phasen innerhalb des Modells betreffen dabei in erster Linie die Konzeptions- und Realisierungsphase. Sollten sich während der Software-Anpassungen neue Anforderungen ergeben, werden diese in der im Rahmen der Konzeption spezifiziert, um anschließend ebenfalls realisiert zu werden. Neun der befragten Beratungshäuser setzen für die Software-Einführung sequentielle Phasenmodelle ein. Bei drei dieser neun Modelle wird der lineare Ablauf der Phasen zusätzlich in der Realisierungsphase variiert. Innerhalb dieser Phase verläuft die Umsetzung der Software-Anpassungen in einem iterativen Prozess, der sich auf die jeweils betrachteten Geschäftsprozesse bezieht. In den Vorgehensmodellen zweier weiterer Beratungshäuser ist eine Variation des linearen Phasenmodell dahingehend vorgesehen, dass die eventuell notwendigen kundenindividuellen Softwareentwicklungen nach dem Schema des V-Modells vorgenommen werden. Zusammenfassend ist das Vorgehensmodell der Software-Einführung demnach ein im Phasenverlauf sequentielles Modell, das innerhalb der Realisierungsphase einen iterativen oder V-förmigen Verlauf annehmen kann.

Rollenkonzept mit Beteiligungsausprägungen Ebenso wie beim Software-Auswahl-Modell tragen das Beratungshaus und das Klientenunternehmen in der gemeinsamen Projektleitung die Prozess-Verantwortung. Auch hier liegt die Entscheidungsbefugnis beim Klienten. Die inhaltliche Verantwortung — 49 —

für die Phasenergebnisse übernimmt hingegen das Beratungshaus, wobei eine kontinuierliche Abstimmung mit dem Klienten sehr wichtig für den Projekterfolg ist. Ein Berater sagte dazu: „ Der Kunde kauft ja kein Produkt, sondern bekommt eine hoch individuelle Dienstleistung, die zu seinen Vorstellungen passen sollte.“ Von daher sind bspw. die Key User intensiv an der Konzeption und Realisierung beteiligt. Der Software-Lieferant tritt im Rahmen der Projektinitiierung vor allem als ProzessUnterstützer auf. Dabei ist er für die vorbreitenden Tätigkeiten, wie den Kauf und die Konfiguration der notwendigen Hardware sowie die Basisinstallation der Software zuständig. Im weiteren Projektverlauf hat er die Rolle eines Prozess-Beteiligten, denn in den meisten Fällen nimmt er an der Realisierung und dem Testen teil.

Zeitlicher Rahmen des Software-Einführungs-Prozesses Bezüglich

des

Zeitrahmens

eines

Software-Einführungs-Prozesses

konnten

die

Interviewpartner, wie schon bei der Software-Auswahl, lediglich Schätzwerte abgeben. Auch in einem Software-Einführungs-Projekt ist die Gesamtprojektlaufzeit von vielfältigen Rahmenbedingungen abhängig. Diese sind u.a. o die Größe, insbesondere Mitarbeiteranzahl und betroffene Standorte des Klienten, o die Branche des Klienten (reguliertes Umfeld oder nicht), o Umfang der einzuführenden Software (z.B. ein oder mehrere Modul(e) einer ERPSoftware), o die Komplexität hinsichtlich des Funktionsumfangs der Software, o die festgelegte Einführungsstrategie („Big Bang“ oder stufenweise Einführung, Einhaltung des Standards, das Ausmaß notwendiger Anpassungen usw.). Das Minimum einer Software-Einführung liegt dabei zwischen drei und sechs Monaten, die maximale Projektlaufzeit kann dagegen zwei bis fünf Jahre in Anspruch nehmen.

Messgrößen im Vorgehensmodell Da

es

hinsichtlich

der

im

Vorgehensmodell

verwendeten

Messgrößen

große

Übereinstimmungen zum Vorgehensmodell der Software-Auswahl gibt, sei an dieser Stelle auf den entsprechenden Abschnitt in Kapitel 3.1 verwiesen.

— 50 —

Die beiden kleinsten Beratungshäuser verneinten auch zum Modell der Software-Einführung die Frage nach der Verwendung von Messgrößen. Außerdem wurden die bereits erläuterten Kennzahlen des klassischen Projektmanagements hier ebenfalls von allen verbleibenden Beratungshäusern zum Projektcontrolling angewandt. Es wurden jedoch auch weitere Messgrößen von den befragten Beratern genannt. So ist eine qualitative Maßnahme die kontinuierliche projektbegleitende Messung der Klientenzufriedenheit. Aus den Befragungen der Klientenmitarbeiter lassen sich direkte Bewertungen

hinsichtlich

der

Beratungsqualität

ableiten.

Sonstige

von

den

Interviewpartnern genannte Messgrößen und unsere weitergehenden Vorschläge sind in den einzelnen Phasen beschrieben.

4.2 Phasen des Vorgehensmodells 4.2.1 Erste Phase: Projektinitiierung Ein Projekt zur Software-Einführung beginnt nach erteiltem Projektauftrag ebenfalls mit einer

Initialisierungsphase,

in

der

die

notwendigen

Voraussetzungen

für

die

Projektdurchführung geschaffen werden. Bis auf zwei große Unternehmen haben alle Beratungshäuser diese Phase in ihrem Vorgehensmodell vorgesehen. Die beiden erwähnten Beratungsunternehmen gehören auch zu den Firmen, die bereits im Vorgehensmodell der Software-Auswahl keine explizite Projektinitiierung vorsehen. Von daher liegt hier wieder die Vermutung nahe, dass die in dieser Phase enthaltenen Aufgaben grundsätzlich außerhalb von konkreten Vorgehensmodellen festgeschrieben sind. Die Tätigkeiten dieser Phase entsprechen weitestgehend denen, die in einem SoftwareAuswahl-Projekt durchgeführt werden und werden daher bei Übereinstimmung nicht erneut erläutert. Ein kleines Beratungshaus, das keine Projekte zur vorherigen Software-Auswahl durchführt, weil es auf die Einführung von SAP-Software spezialisiert ist, konkretisiert in dieser Phase zunächst den Projektauftrag. Diese Projektdefinition bezieht sich in erster Linie auf Festlegung der einzuführenden Software-Module und die dadurch betroffenen Geschäftsprozesse. Diese Aufgabe kann bei einer zuvor gemeinsam mit dem Klienten durchgeführten Software-Auswahl entfallen, da in diesem Projekt bereits der Scope der Software-Einführung definiert wurde. — 51 —

Im Rahmen der Projektorganisation wird bei einem Software-Einführungs-Projekt zusätzlich zu den bereits erläuterten Maßnahmen des Staffing eine Verantwortlichkeitsmatrix definiert. Diese betrifft, ähnlich wie im Projektplan, die Festlegung, welche Mitarbeiter des Klientenunternehmens, des Software-Lieferanten bzw. des Beratungshauses für die Durchführung einzelner Projektphasen bzw. die Ausführung einzelner Arbeitspakete verantwortlich sind. Diese Maßnahme wird vor allem aus folgenden zwei Gründen durchgeführt: Zum einen erleichtert die Matrix die Kommunikation innerhalb des Projektes, da der richtige Ansprechpartner einfacher identifiziert werden kann. Zum anderen ist die Explizierung der Verantwortlichkeiten ein hilfreiches Instrument zur Einhaltung der Terminplanung. Es stellt ein psychologisches Druckmittel dar, da bei Verzögerungen im Projektverlauf (die keine externen Ursachen haben) die zuständige Person eindeutig festgestellt werden kann. In diesem Zusammenhang werden auch die Key User für die Software-Einführung bestimmt. Diese sind Mitarbeiter der Fachbereiche des Klienten, die z.B. aufgrund ihrer Position oder Erfahrung in der Lage sind, die Interessen ihres Fachgebietes im Projektteam zu vertreten. Sie fungieren daher als Ansprechpartner sowohl für die Kollegen der Abteilung als auch für den Software-Lieferanten und die Berater. Zusätzlich zu den unterstützenden Softwareprogrammen, die bereits im Vorgehensmodell der Software-Auswahl genannt wurden, setzen die Beratungshäuser Rational RoseProdukte von IBM oder Tools von SAP (v.a. den SAP „Solution Manager“) im gesamten Projektverlauf z.B. zu Dokumentationszwecken ein. Bereits in der Charakterisierung des Beratungsfeldes Software-Einführung wurde erwähnt, dass zu Beginn des Projektes die grundsätzliche Herangehensweise, d.h. die Strategie der Einführung, festgelegt werden muss. Diese betrifft einerseits die bereits erläuterte Entscheidung hinsichtlich der Beibehaltung des Software-Standards oder der Abweichung mittels klientenindividueller Anpassungen. Andererseits wird in Projekten, in denen die Software-Einführung

mehrere

Standorte

oder

Unternehmensteile

betrifft,

eine

Einführungskonzeption und ein Roll-out-Plan erstellt. Es ist sowohl eine schrittweise Einführung der Software in den verschiedenen Standorten und Unternehmensbereichen möglich als auch die zeitgleiche, umfassende Einführung für alle Betroffenen („Big Bang“). Außerdem erläuterte ein Berater eines mittelgroßen Beratungshauses, dass im Rahmen der Strategiedefinition bereits zu Beginn des Projektes ein Migrationskonzept für die — 52 —

Überführung der Daten aus den Altsystemen erstellt werden sollte. Obwohl diese Datenmigration erst in der Phase der Produktivvorbereitungen durchgeführt wird, sei es wichtig, bereits frühzeitig vor allem die Behandlung der Bewegungsdaten zu klären. Selbstverständlich

gehört

zu

den

Projekt-vorbereitenden

Tätigkeiten

auch

die

Bereitstellung der für die Software-Einführung notwendigen Infrastruktur. Dies betrifft zum einen die Systemlandschaft mit der entsprechenden Hardware und den Netzwerken und

zum

anderen

die

Software-Basisinstallation.

Schließlich

sind

in

den

Vorgehensmodellen von zwei befragten Beratungshäusern in dieser Phase Basisschulungen für das Projektteam, v.a. für die Key User und die späteren Administratoren der Software vorgesehen. Die als Ergebnis der Projektinitiierungsphase erstellten Dokumente können, genau wie in dem Vorgehensmodell der Software-Auswahl, als mehrteilige Projektdefinition bezeichnet werden. Als mögliche Messgrößen kommen ebenfalls die Qualität der Projektplanung sowie die Erfolgswahrscheinlichkeit des Projektes in Frage. 18

4.2.2 Zweite Phase: Konzeption (einschließlich Anforderungsanalyse) Nach Abschluss der Projektinitiierungstätigkeiten beginnt die Konzeptionsphase mit einem Kick-Off Meeting, in dem insbesondere auch die im weiteren Projektverlauf geplante Vorgehensweise für alle Projektteammitglieder dargelegt wird. Die wichtigsten Tätigkeiten dieser Phase entsprechen in ihrer Art der Grob- und Feinspezifikation eines Softwareentwicklungsprozesses. Mittels der Definition und inhaltlichen Konzeption der von der Software-Einführung betroffenen Geschäftsprozesse werden die grundlegenden Anforderungen an die Software erhoben. Dies erfolgt in der Regel in gemeinsamen Workshops mit den Key Usern der Fachabteilungen, den Beratern und dem Software-Lieferanten. Dabei wird eine Ist-Analyse der vorhandenen Geschäftsprozesse im Klientenunternehmen vorgenommen und die Definition der angestrebten Soll-Prozesse durchgeführt. 19 Die daraus resultierenden Anforderungen werden als Basis für die folgende Phase der Realisierung ausführlich dokumentiert. Dies

18 19

Siehe hierzu die Ausführungen beim Vorgehensmodell zur Software-Auswahl. Dieser Arbeitsschritt kann entfallen, wenn zuvor eine gemeinsam durchgeführten Software-Auswahl stattgefunden hat. Die Definition der Ist- und Soll-Geschäftsprozesse wurde in diesem Projekt bereits in der Potentialanalyse und Anforderungsdefinition durchgeführt und kann übernommen werden.

— 53 —

erfolgt bspw. im SAP „Solution Manager“ durch Kopplung der Dokumente an die verschiedenen Detailebenen der erfassten Geschäftsprozesse. Ein weiterer Bestandteil der Anforderungsdefinition ist die Informationsbedarfserfassung aus Sicht des Informationsmanagements im Klientenunternehmen. Dabei werden (eventuell zusätzliche) Funktionen wie Berichte, Dokumentationsvorlagen oder Formulare definiert und spezifiziert. Außerdem werden die speziellen Anwenderbedürfnisse hinsichtlich Bedienung (Software-Ergonomie) und Individualisierung erfasst und in die Konzeption integriert. Ferner ist die Spezifikation hinsichtlich einer notwendigen Governance unter Beachtung von Richtlinien, Kontrollvorschriften und Berechtigungskonzepten im Sinne der IVCompliance zu prüfen. Aus fachlicher Perspektive werden mittels der Anforderungsdefinition Abweichungen in Bezug auf den Software-Standard aufgedeckt. Aus diesen ergibt sich die Notwendigkeit zur

Durchführung

von

Customizing-Tätigkeiten

oder

der

individuellen

Softwareerweiterung in der nachfolgenden Realisierungsphase des Projektes. Eine weitere Aufgabe in der Konzeptionsphase ist die Durchführung der technischen Spezifikation

hinsichtlich

der

Infrastruktur

inklusive

den

Netzwerken,

der

Systemarchitektur sowie den Schnittstellen der Software zu anderen Systemen. Je nach Heterogenität der Systemlandschaft entfallen circa 5 bis 10 % der Anforderungsdefinition auf die Betrachtung der genannten Schnittstellen. Spätestens in diesem Zusammenhang ist außerdem eine Datenmigrationskonzeption und ein Konvertierungsplan zu erstellen. Die vielfältigen Dokumente, die das Ergebnis dieser Phase darstellen, werden in der Beratungspraxis auch als „Blueprint“-Dokumente bezeichnet. Diese müssen von dem zuständigen Entscheidungsgremium (bspw. dem Lenkungsausschuss) beim Klienten abschließend genehmigt werden. Als mögliche Messgröße bietet sich in der Konzeptionsphase die Kontrolle der Aufgabenerfüllung durch die Projektteammitglieder an. Daraus können eventuell aufgetretene Verzögerungen im Projektplan erklärt werden und das Ansehen des Projektes im Klientenunternehmen beurteilt werden. Das Beratungshaus kann zusätzlich langfristige Erkenntnisse für die Optimierung der Aufgabenverteilung in zukünftigen SoftwareEinführungs-Projekten gewinnen. Eine weitere Messgröße ist die Prüfung der

— 54 —

Vollständigkeit und Korrektheit der erzeugten Dokumente für die Abschätzung des weiteren Projekterfolgs.

4.2.3 Dritte Phase: Realisierung Sind die „Blueprint“-Dokumente genehmigt und für die weitere Verwendung freigegeben worden, startet die Phase der Realisierung. Die hauptsächlichen Aufgaben dieser Phase bestehen in der Anpassung des Software-Standards an die Klientenanforderungen durch Konfiguration von Parametern (dem sog. Customizing), der Umsetzung von individuellen Softwareerweiterungen (Anpassungsprogrammierung) und der Programmierung der benötigten Schnittstellen zu anderen Systemen innerhalb des Klientenunternehmens bzw. vom Kunden gewünschten Listen, Berichten und Formularen. Diese Aufgaben werden bei drei der befragten Beratungshäuser im Rahmen des Aufbaus eines Prototypen realisiert. Wie bereits in der Präsentationsphase des Software-AuswahlModells erwähnt, kann bereits eine Testversion der Software im Rahmen der Auswahl beim Klientenunternehmen installiert werden. Sollte dies der Fall sein, kann diese als Basis für die Realisierung des Prototypen herangezogen werden. Die verbleibenden neun Beratungshäuser sehen in ihrem Vorgehensmodell die Nutzung eines Entwicklungssystems für das Customizing vor. Die Tätigkeit des Customizing besteht in der Einstellung der in der Standard-Software enthaltenen Parameter 20 und wird daher auch als Parametrisierung bezeichnet. Gemäß den meisten Vorgehensmodellen sollte diese Parametrisierung im Verhältnis zur Anpassungsprogrammierung etwa 90 % des Aufwands ausmachen, denn es zeichnet eine Standard-Software als gute Software aus, dass nur geringe Anpassungsprogrammierungen durchzuführen sind. Die befragten Berater gaben jedoch an, dass die Parametrisierung in der Realität lediglich circa 70 % der Arbeiten ausmacht. Während des Customizings wird in der Regel eine iterative Arbeitsweise in Bezug auf die jeweils anzupassenden Geschäftsprozesse beim Klienten angewandt. Die Iterationen beziehen sich aber auch auf die zum Teil bereits an dieser Stelle durchgeführten Testaktivitäten und sich daraus ergebenden weiteren Customizingbedarf. Außerdem sind eventuell Änderungen der

20

Zur näheren Erläuterung von Customizing siehe [Görk97, 101-102].

— 55 —

Konzeption notwendig, wenn der Klient mit den Ergebnissen nicht zufrieden ist. Aus diesem Grund sind die Key User der Fachabteilungen an dieser Phase des Vorgehens sehr intensiv beteiligt. Die Befragung ergab weiterhin, dass sich sechs Beratungshäuser in den meisten Projekten nicht aktiv an den Software-Anpassungstätigkeiten beteiligen, sondern diese Aufgabe dem Software-Lieferanten überlassen. Zum einen wurde dies von kleinen Beratungshäusern durch die knappen personellen Ressourcen begründet, zum anderen gibt es auch SoftwareSysteme, zu denen die Berater kein Detailwissen besitzen. Ein anderer Grund für die Nicht-Beteiligung wurde darin gesehen, dass der Klient eventuell die Objektivität des Beraters in Frage stellen könnte, wenn dieser zuvor die Software-Auswahl stark beeinflusst hatte. Die verbleibenden sechs Beratungshäuser hingegen gaben an, dass sie das Customizing regelmäßig durch eigene Berater ausführen. Die zweite wichtige Tätigkeit in dieser Realisierungsphase besteht in der Durchführung der kundenindividuellen Anpassungsprogrammierung. Für diese Modifikationen werden die notwendigen Programme bzw. Funktionsbausteine programmiert. Laut Auskunft eines Beraters laufen diese Tätigkeiten als „kleine, gekapselte IT-Entwicklungen“ ab und beinhalten bereits die zugehörigen Unit-Tests (isolierte Funktionstests). Außerdem werden als dritte Aufgabe neben den Formularen, Listen und Berichten die notwendigen Schnittstellenausprägungen zu anderen Systemen programmiert. Diese sollten laut der Vorgehensmodelle maximal 10 bis 20 % aller Tätigkeiten dieser Phase ausmachen. Aber auch hier berichteten die Berater aus Erfahrungswerten der Beratungspraxis, dass vielmehr circa 30 % der Tätigkeiten dem Programmieren der Schnittstellen zuzuschreiben ist. Erklärt wurde dieser relativ hohe Arbeitsanteil dadurch, dass die Geschäftsprozesse in den Klientenunternehmen zunehmend komplexer geworden sind. Im Rahmen des Projektmanagements ist es von großer Bedeutung, dass ein Zeitpunkt festgelegt wird, ab dem keine weiteren Änderungen an der Software vorgenommen werden (sog. Entwicklungsstopp / „freeze“). An dieser Stelle startet das offizielle ChangeManagement 21, in dem alle Änderungen beantragt und genehmigt werden müssen. Nach Angaben eines befragten Beratungshauses besteht die letzte Aufgabe dieser Phase in dem Erstellen von Testplänen mit den Testfällen und Daten, die in der Folgephase

21

Zur Definition und Erläuterung des Begriffes Change-Management siehe [Pohl97, 79]

— 56 —

durchgeführt werden sollen. Diese Testszenarien basieren auf den in der Konzeptionsphase erhobenen Geschäftsprozessen bzw. Anforderungen. Nach der erfolgreichen Abnahme der Testpläne wird die angepasste Software für den Übergang in das Testsystem freigegeben. In den sieben Vorgehensmodellen, die eine eigenständige Test-Phase beinhalten, endet an dieser Stelle die Phase der Realisierung. In den verbleibenden fünf Beratungshäusern, die keine explizite Test-Phase in ihrem Vorgehensmodell vorsehen, werden alle notwendigen Tests bereits zu diesem Zeitpunkt durchgeführt. Es handelt sich dabei um die gleichen Testvarianten, die in der nachfolgenden Phase beschrieben werden. In diesen Fällen wird das angepasste und getestete Softwaresystem bereits am Ende der Realisierungsphase für den Betrieb freigegeben. Als Ergänzung zur klassischen Kontrolle der Zeit- und Budgeteinhaltung ist die Durchführung einer Earned-Value-Analyse eine mögliche Messmethode dieser Phase. Sie vergleicht den bisherigen Fertigstellungsgrad mit dem dafür geleisteten Aufwand und gibt damit Auskunft über die Projekteffizienz. Diese Messung kann bei enorm überhöhtem Aufwand auch darauf hindeuten, dass die Software nicht optimal ausgewählt wurde. Außerdem können die Berater Erfahrungswerte bezüglich zu veranschlagender Aufwände für zukünftige Projekte gewinnen. Eine Qualitätsprüfung hinsichtlich der korrekten und vollständigen Anforderungsumsetzung ist ebenfalls eine Möglichkeit der Messung des Phasenerfolges.

4.2.4 Vierte Phase: Test Ist die angepasste Software von den zuständigen Entscheidungsgremien auf die Korrektheit und Vollständigkeit der Anpassungen in Bezug auf die Anforderungen geprüft und freigegeben worden, startet die Test-Phase. Diese beginnt mit der Installation der Software auf dem Testsystem und dem Einpflegen von Echtdaten des Klientenunternehmens als Datenbasis für die durchzuführenden Tests. Außerdem erstellen sechs Beratungshäuser an dieser Stelle die Testpläne mit den darin enthaltenen Szenarien – ein Beratungshaus hatte diese Tätigkeiten bereits in der vorigen Phase durchgeführt. Das Testen der Software und die damit einhergehende Fehlerbehebung beziehen sich in den verschiedenen Testvarianten auf unterschiedliche Ebenen der Software bzw. des — 57 —

Gesamtsystems. Die einzelnen Anpassungen wurden bereits, wie erwähnt, während des Customizings getestet und durchlaufen in dieser Phase keine weiteren, einzelnen Tests. Die Funktionstests werden prozessbezogen durchgeführt. Das heißt, jeder betroffene Geschäftsprozess wird isoliert in der Software durchlaufen und mittels der Klientendaten simuliert. Dabei müssen die Prozesse nicht in einer streng sequentiellen Abfolge getestet werden, sondern können parallel betrachtet werden. Im Rahmen der Migrationstests werden die in der Migrationskonzeption definierten Umsetzungsregeln bezüglich der Datenstrukturen zwischen den Altsystemen und der neuen Software überprüft. Die Altdaten werden dazu mittels Transportaufträgen über einen Migrationsmandanten in das neue System überspielt, wobei die Datenstrukturen angepasst werden („matching“). Anhand von korrekten Echtdaten kann nach dem Hochladen ein Abgleich hinsichtlich der korrekten Datenüberführung gemacht werden. In dem sich anschließenden Integrationstest werden die Geschäftsprozesse unter Beachtung der vorhandenen Abhängigkeiten erneut durchlaufen. Hierbei werden die programmierten Schnittstellen getestet und die geplante Ablauforganisation bezüglich ihrer Konsistenz und Korrektheit überprüft. In

den

abschließenden

Benutzerakzeptanz-Tests

wird

in

einem

strukturierten

„Walkthrough” durch alle Prozesse die Umsetzung der Anwenderanforderungen getestet. Diese Testläufe werden üblicherweise von den Key Usern durchgeführt, da diese die speziellen Arbeitsabläufe ihrer Fachabteilungen am besten beurteilen können. In ähnlicher Weise wird der praktische Umgang mit der Software bei der Realisierung eines Prototyps von den Key Usern getestet. Alle durchgeführten Tests werden dokumentiert. Die Test-Phase endet mit einer Beurteilung der Test-Durchführung und ihrer Ergebnisse. Werden die Tests dabei als erfolgreich bewertet, wird das System für den Produktivbetrieb freigegeben. Mögliche Messgrößen dieser Phase sind u.a. die Anzahl der aufgetretenen Fehler und die jeweiligen Fehlerklassen oder die Korrektheit der Ausgabedaten. Sie dienen in erster Linie der Beurteilung der korrekten Anpassung der Software. Außerdem kann der Gesamtaufwand, der für die Tests benötigt wurde, gemessen werden. Dieser ist abhängig von der festgestellten Softwarequalität und gibt ebenfalls einen Hinweis zur Beurteilung der Leistungen in der Realisierungsphase.

— 58 —

Die gemessenen Werte aus dieser Phase können ferner das Erfahrungswissen der Berater erweitern und in zukünftigen Projektplanungen berücksichtigt werden.

4.2.5 Fünfte Phase: Produktivvorbereitung Nachdem die Software vollständig angepasst, getestet und freigegeben wurde, können die Produktivvorbereitungen getroffen werden. Hierfür wird der Produktivstart (sog. „Go Live“) terminiert und die anfallenden Umstellungsarbeiten für den Echtstart des Systems geplant. Eine wichtige Voraussetzung für den erfolgreichen Produktivstart im Hinblick auf das Tagesgeschäft des Klienten ist die rechtzeitige Durchführung von Endbenutzerschulungen. Hierzu müssen insbesondere vollständige Schulungsmaterialen zur Verfügung stehen. In einem kleinen Beratungshaus werden diese bspw. in Form einer Bedienungsanleitung unter Hilfestellung der Berater durch die Key User selbst formuliert. Damit wird gleichzeitig sichergestellt, dass die Key User als Ansprechpartner für ihre Kollegen fungieren können, weil sie die neue Software hinreichend gut kennen. Die Schulungen selbst werden im Allgemeinen zwischen allen Projektakteuren aufgeteilt. So schult der Software-Lieferant die Mitarbeiter, die nach dem Go Live für die Systemwartung und Administration verantwortlich sind. Die anderen Endbenutzer werden hinsichtlich des Prozessablauf und der Softwarebedienung entweder durch die Key User oder die Berater geschult. Zur Messung des Erfolges der durchgeführten Schulungen könnte man bspw. Abschlusstests anhand von Geschäftsvorfällen vornehmen und die Bedienungsfehler der Nutzer zählen. Dies dient zum einen der Sicherstellung, dass die Anwender in der Praxis tatsächlich mit dem System arbeiten können. Zum anderen gibt eine enorm hohe Fehlerquote eventuell Hinweise auf unzureichende Benutzerfreundlichkeit der Software oder qualitativ minderwertige Schulungsunterlagen. Eine weitere, laut Auskunft eines Interviewpartners umfangreiche und anstrengende Tätigkeit in dieser Phase ist das „Befüllen des Produktivsystems“. Dieser Vorgang betrifft einerseits das Überspielen aller technischen Inhalte, d.h. der vollständigen Software, sowie die endgültige Datenübernahme aus den Altsystemen in das Produktivsystem. Bezüglich dieser Vorbereitungstätigkeit könnte der Erfolg der Datenübernahme anhand der Anzahl der Fehlläufe gemessen werden. Hierzu berichtete ein befragter Berater, dass die notwendige Download-Upload-Prozedur nicht immer sofort fehlerfrei durchlaufen wird. — 59 —

Um das Softwaresystem unter realistischen Bedingungen abschließend zu prüfen, wird nach bereits erfolgter Datenmigration ein System-, Abnahme- oder Lasttest durchgeführt. Dieser wird nach erfolgreicher Durchführung vom Klienten bestätigt, in welchem Zusammenhang die offizielle Freigabe für den Produktivstart erteilt wird. Ein wichtiges Kriterium zur Freigabe des gesamtes Systems stellt die gemessene Antwortzeit (Performance) während des Tests dar. Sollte deren Wert ungewöhnlich hoch ausfallen, kann das die Verschiebung des Produktivstarts bewirken. Die letzte, insbesondere für die ersten Tage nach dem Produktivstart entscheidende Vorbereitung ist die Festlegung der Organisation des Supports beim Klienten. Dies betrifft bspw. die Frage, wer als Ansprechpartner für den First Level Support zuständig ist.

4.2.6 Sechste Phase: Produktivstart (Go-Live) und Support Wie die Bezeichnung Produktivstart bereits erkennen lässt, handelt es sich bei dieser Aktivität weniger um eine zu verrichtende Tätigkeit als um einen bestimmten Zeitpunkt. Zu einem bestimmten Stichtag und einer festgelegter Uhrzeit wird das alte System bzw. die alten Anwendungen vollständig „abgeschaltet“. Ab diesem Moment werden alle betroffenen Geschäftsprozesse ausschließlich unter Verwendung der neuen Software durchgeführt. Es besteht hierbei, trotz der zuvor durchgeführten Tests, immer ein Risiko, dass es zu gravierenden Fehlern in der Prozessabwicklung kommt. Aus diesem Grund wird von einem Beratungshaus nach dem Go Live nochmals ein „Notfalltest“ durchgeführt, so dass man beim Auftreten solcher Probleme den Produktivstart doch noch einmal verschieben könnte. Falls noch nicht in der vorigen Phase geschehen, wird in dieser Phase außerdem die langfristige Support-Organisation im Klientenunternehmen sowie die Verantwortlichkeiten bezüglich des Managements und der Wartung der Software festgelegt. Die Befragung der Berater ergab, dass acht Beratungshäuser eigene Supportleistungen für die Anlaufschwierigkeiten der Software bereitstellen. Diese betreffen das Beseitigen von Fehlfunktionen und Hilfestellung bezüglich Fragen zur Bedienung der Software. Diese Support-Tätigkeiten werden in der Regel in einem Zeitraum zwischen vier Wochen und drei Monaten angeboten. Bei zwei weiteren Beratungshäusern leistet ausschließlich der

— 60 —

Software-Lieferant die Supporttätigkeiten gegenüber dem Klienten. Die anderen beiden Berater machten hierzu keine Angaben. Den Projektabschluss und damit das letzte Phasenergebnis im Vorgehensmodell der Software-Einführung bildet ein Abschlussmeeting mit allen Projektbeteiligten. Im Sprachgebrauch der Beratungspraxis sind die aus diesem Gespräch hervorgehenden Erkenntnisse bezüglich positiver oder negativer Begebenheiten während des Projektes die „lessons learned“. In diesem Zusammenhand ist die direkte Ermittlung der Klientenzufriedenheit bspw. durch mündliche Nachfrage oder mittels eines Fragebogens eine mögliche Messgröße. Eine andere Messgröße in dieser Phase ist, bezogen auf die Software-Einführung an sich, die Anzahl der in der Support Organisation eingehenden Anfragen in einem bestimmten Zeitraum nach dem Produktivstart. Erste Anlaufschwierigkeiten und Unsicherheiten seitens der Klientenmitarbeiter sind zu Beginn der Softwarenutzung nicht ungewöhnlich. Sollten die Anfragen aber über längere Zeit hoch bleiben, muss über erneute Schulungsmaßnahmen oder die weitere Optimierung der Software nachgedacht werden. Diese Leistung der Nachbetreuung eines Software-Einführungs-Projektes wird von fünf der befragten Beratungshäuser angeboten. Von daher kommen als weitere interessante Messgrößen die Anzahl und der Umfang der vom Klienten erteilten Folgeaufträge in Betracht, da sich hierin die Klientenzufriedenheit mit der Beratungsleistung ausdrückt.

5 Modellentstehung und -handhabung in der Beratungspraxis 5.1 Hintergrund Dieses Kapitel befasst sich mit verschiedenen Aspekten der Entstehung und der praktischen Handhabung der Vorgehensmodelle in den befragten Beratungshäusern. In den vorigen Kapiteln wurde dargestellt, dass die Unternehmensberatungen in den jeweiligen Beratungsfeldern ähnliche Vorgehensmodelle anwenden. Hinsichtlich der Entstehung und Handhabung lassen sich jedoch durchaus einige Unterschiede feststellen, die teilweise von der Unternehmensgröße abhängen. Dieser Bestandteil der Untersuchung basiert auf den Fragen der letzten beiden Teile des Fragebogens, wobei der überwiegend geschlossene Fragecharakter eine statistische

— 61 —

Auswertung der Antworten ermöglicht. Hierzu wurden die Ergebnisse aller 14 befragten Beratungshäuser – unabhängig von den untersuchten Beratungsfeldern – erfasst und zusammen ausgewertet. Dieses Vorgehen wurde insofern als sinnvoll erachtet, als nach dem Eindruck aus den Interviews der praktische Umgang mit den Vorgehensmodellen von der Unternehmenskultur des jeweiligen Beratungshauses abhängt. Sollten dennoch Besonderheiten in Bezug auf die verschiedenen Beratungsfelder auftreten, so werden diese explizit ausgeführt. Es sei außerdem an dieser Stelle darauf hingewiesen, dass die gewonnenen Erkenntnisse aufgrund der kleinen Stichprobe keine Allgemeingültigkeit beanspruchen.

5.2

Entstehung der Vorgehensmodelle

5.2.1 Entwicklungszeitpunkt bzw. bisheriger Einsatzzeitraum Aus den bisherigen Ausführungen wurde deutlich, dass alle Beratungshäuser in mindestens einem Beratungsfeld ein Vorgehensmodell einsetzen. Es stellt sich jedoch die Frage, wann diese Vorgehensmodelle entwickelt wurden bzw. seit wann sie in der Beratungspraxis zum Einsatz kommen. Mit einer Ausnahme konnten die Berater hierzu das jeweilige Entstehungsjahr

benennen

Anwendungszeitraum

oder

abgeben.

zumindest Es

traten

Schätzungen keine

über

Unterschiede

den

bisherigen

hinsichtlich

der

Unternehmensgrößen auf. Da die jeweiligen Angaben bezüglich der Vorgehensmodelle zur Software-Auswahl und Einführung bis auf eine Ausnahme bei allen zu diesen Beratungsfeldern befragten Beratungshäusern übereinstimmen, werden diese im Folgenden zusammen ausgewertet. Auch wenn sich die exakten Jahresangaben im Detail unterscheiden, ist eine gewisse Clusterung der Einsatzzeiträume möglich (Bild 8). So gibt es drei Beratungshäuser, die ihre Vorgehensmodelle bereits seit mindestens 15 Jahren anwenden. In sechs Beratungshäusern werden die Modelle seit 10 - 15 Jahren angewandt und vier Berater gaben an, dass das jeweilige Vorgehensmodell seit 5 - 9 Jahren im Einsatz ist. Ein Unternehmen machte hierzu keine Angaben. Diese im Durchschnitt recht langen Anwendungszeiträume belegen, dass die Beratungsfelder der Software-Auswahl und -Einführung zu den klassischen Kernaufgaben der IV-Beratung zählen.

— 62 —

7 6 5 4 3 2 1 0 5 - 9 Jahre

10 - 15 Jahre

> 15 Jahre

Bild 8: Anwendungsdauer der Vorgehensmodelle (bei einem Unternehmen unbekannt) 5.2.2 Ursprung Zur Entwicklung von Vorgehensmodellen stehen den Unternehmen hauptsächlich zwei Methoden zur Verfügung. Entweder werden die in den durchgeführten Projekten gewonnenen Erfahrungen und Erkenntnisse erfasst und in einem einheitlichen Modell zusammenfassend aufbereitet. Oder die Methodenverantwortlichen bedienen sich externer Quellen und adaptieren diese in einem eigenen Vorgehensmodell. Dabei kann es sich um bereits etablierte Vorgehensweisen, internationale Standards oder wissenschaftliche Literatur handeln. Welche dieser Möglichkeiten die befragten Beratungshäuser für die Entwicklung der Vorgehensmodelle nutzten, zeigt Bild 9.

unbekannt 1 [7%] Erfahrung 5 [36%] Erfahrung und externe Quellen 6 [43%] externe Quellen 2 [14%]

Bild 9: Ursprung der Vorgehensmodelle

— 63 —

In fünf Fällen entstanden die Vorgehensmodelle ausschließlich durch die Zusammenfassung von Erfahrungen, die Berater in Projekten gesammelt hatten und die nun in Form von

best/common

practices

in

einem

Modell

vereint

wurden.

Bei

sechs

Beratungsunternehmen wurden zur Modellentwicklung neben solchen Projekterfahrungen auch weitere Informationen aus der praktischen und wissenschaftlichen Literatur herangezogen. Zwei Vorgehensmodelle beruhen wiederum ausschließlich auf externen Quellen, wie den offenen Standards TOGAF bzw. COBIT oder der von der SAP AG entwickelten ASAP-Methode zur Einführung von ERP-Software. Ein befragter Berater konnte zur Entstehung des Vorgehensmodells seines Beratungshauses keine Auskunft geben. Aus diesen Ergebnissen lässt sich schlussfolgern, dass das in den Projekten erlangte Wissen eine wertvolle Basis für die Erstellung von internen Vorgehensmodellen darstellt. Bei der Datenauswertung konnte kein Zusammenhang der verschiedenen Antworten zu der jeweiligen Unternehmensgröße der Beratungshäuser festgestellt werden. Dagegen unterscheidet sich

der

Entwicklungsprozess

für Vorgehensmodelle bei

kleinen

Beratungshäusern erheblich von dem in großen Unternehmensberatungen. In einem Beratungshaus mit wenigen Mitarbeitern findet ein weniger formalisierter, aber teils kreativerer Prozess statt, der von einem Berater neben dem Tagesgeschäft geleitet werden kann. Bei mittelgroßen und großen Unternehmensberatungen ist jedoch – allein aus dem Grund

der

höheren

Berateranzahl

und

der

vermutlich

auch

zahlreicheren

Projekterfahrungen, die in das Vorgehensmodell einfließen sollen – eine systematische und formale Entwicklung notwendig. So gibt es bspw. in zwei der hier befragten großen internationalen Beratungshäuser eigene Organisationseinheiten, die sich hauptsächlich mit der Entwicklung und Verbesserung von Vorgehensmodellen befassen.

5.2.3 Motivation Bereits aus der Begriffsdefinition von Vorgehensmodellen wird deutlich, dass deren vornehmlicher Zweck die Anleitung zur Durchführung eines Projektes ist. Es stellt sich jedoch die Frage, welche weitere Motivation die Beratungshäuser zur Erstellung und zum Einsatz von Vorgehensmodellen bewegt(e)? Hierzu wurden im Fragebogen drei Antwortmöglichkeiten vorgeschlagen, die um weitere Argumente ergänzt werden konnten. Da in den meisten Fällen nicht nur ein Motiv ausschlaggebend ist, konnten außerdem

— 64 —

mehrere Antworten gegeben werden. Die aus Sicht der befragten Berater wichtigsten Gründe und die Anzahl ihrer Nennungen können Bild 10 entnommen werden. Auch bezüglich dieser Thematik ergab die Datenauswertung keine Differenzierung der Antworten hinsichtlich der Größenklassen der Unternehmensberatungen, weshalb auf die größenbezogene Aufschlüsselung der Ergebnisse verzichtet wird.

Qualitätssicherung Arbeitsanleitung Standardisierung / Effizienzsteigerung Akquiseinstrument Kundenwunsch 0

2

4

6

8

10

12

14

Bild 10: Motivation für Entwicklung und Einsatz von Vorgehensmodellen Die Sicherung der Beratungsqualität ist nach Meinung der befragten Berater der wichtigste Beweggrund für die Entwicklung und die Nutzung von Vorgehensmodellen. Die Vorgabe der zu leistenden Arbeitsergebnisse – meist in Form von Templates (Dokumentvorlagen) – und die entsprechende Qualitätssicherung im Prozess gewährleisten eine einheitliche Beratungsqualität in allen Projekten. Außerdem erhöht eine strukturierte Vorgehensweise die Transparenz des Beratungsprozesses und trägt bspw. in Software-Auswahl-Projekten durch die Schaffung einer fundierten Informationsbasis zu sichereren Entscheidungen bei. Damit bieten Vorgehensmodelle auch für die Beratungsklienten eine erhöhte Sicherheit. Ferner spielt auch aus Sicht der Geschäftsführung der Beratungshäuser der Aspekt der Beratungsqualität eine wichtige Rolle. So können einerseits Verluste, die durch Strafzahlungen aufgrund mangelhafter Beratungsleistungen oder durch Auftragsrückgang aufgrund schlechter Presse verursacht würden, vermieden werden. Andererseits wird durch die Erbringung qualitativ hochwertiger Beratungsleistungen das Vertrauensverhältnis zwischen

Beratern

und

Klienten

gestärkt,

was

wiederum

zu

langfristigen

Geschäftsbeziehungen und Folgeaufträgen führen kann. Das zweithäufigste Motiv für die Entwicklung und den Einsatz von Vorgehensmodellen ist ihre hervorragende Eignung, den Beratern als Arbeitsanleitung zu dienen. Wenn alle — 65 —

Berater mit der anzuwendenden Methode vertraut sind, wird die Kommunikation durch eine gemeinsame Grundlage erheblich erleichtert. Ein Interviewpartner betonte, dass das gleiche methodische Vorgehen aller Berater eine Grundvoraussetzung für den Projekterfolg darstellt. Auch für die Zusammenarbeit mit den Klientenmitarbeitern ist eine einheitliche Verständnisgrundlage bezüglich des Projektablaufes ein erfolgskritischer Faktor. Ein weiterer Vorteil der Vorgehensmodelle wird außerdem darin gesehen, dass eine einfache und dynamische Teamzusammenstellung ermöglicht wird. Da alle Berater nach dem gleichen Modell arbeiten, können jederzeit neue Berater zum Projekt hinzugezogen werden, ohne dass subjektive Arbeitsweisen abgestimmt werden müssen und lange Teamfindungsphasen von Nöten sind. Dieser Aspekt spielt insbesondere bei internationalen Beratungshäusern eine wichtige Rolle, weil somit globale Teams gebildet werden können und dabei auch der Einfluss von kulturellen Unterschieden reduziert werden kann. Letztlich bilden Vorgehensmodelle zudem die Grundlage für eine einheitliche und, wie bereits beschrieben, qualitativ hochwertige Ausbildung der Berater. Ein weiterer Anreiz zur Anfertigung und Anwendung von Vorgehensmodellen stellt die Standardisierung der Beratung und dadurch zu erzielende Effizienzsteigerung dar. Dichtl beschäftigt sich ausführlich mit möglichen Quellen der Effizienzsteigerung mittels Standardisierung [Dich98, 146-186], von denen einige auch in den Interviews von den Beratern genannt wurden. So ist bspw. eine bessere Projektplanung im Hinblick auf Termine, Aufwände oder benötigte Ressourcen ein Vorteil in der Praxis. Außerdem enthalten viele der besprochenen Vorgehensmodelle standardisierte Templates, best practices und empfohlene Tools zur Unterstützung der Berater. Trotz der wichtigen und notwendigen Anpassungen an die Klientensituation wird dadurch ein schnellerer und damit effizienterer Projektablauf möglich. Ein Interviewpartner sprach offen die damit verbundene Möglichkeit der Erhöhung der Gewinnmargen für das Beratungshaus an. Einige Klienten fordern auch Vorgehensmodelle, was für einige Beratungshäuser ebenfalls ein Beweggrund für die Entwicklung und Nutzung ihres Vorgehensmodells war. Ebenfalls mit nur geringer Häufigkeit wurde zudem das Motiv genannt, ein Vorgehensmodell im Hinblick auf die Projektakquise zu erstellen und einzusetzen. Durch die so gegebene Möglichkeit der Dokumentation eigener Beratungskompetenz kann das Vorgehensmodell im Rahmen der Klientenansprache als Marketinginstrument zum Einsatz kommen. Außerdem gab ein Berater an, dass das Modell speziell mit der Zielstellung entwickelt wurde, ein neues Geschäftsfeld zu erschließen. Auch die Intention, durch ein strukturiertes — 66 —

Vorgehen mit konkreten Zielvorgaben und zu erwartenden Projektergebnissen den Klienten einen Mehrwert zu bieten, war ein in den Interviews genanntes Motiv der Modellerstellung.

5.3

Handhabung der Vorgehensmodelle

Allein die Entwicklung bzw. das Vorhandensein eines Vorgehensmodells ist noch keine Garantie für gute Beratungsleistungen. Wenn die Berater die Methode nicht verinnerlicht haben und sie in der Projektarbeit nicht anwenden, bietet selbst das beste Modell keinen Mehrwert. Entscheidend für den erfolgreichen Einsatz eines Vorgehensmodells sind demzufolge die (unternehmenskulturelle) Verankerung des selbigen sowie verschiedene Aspekte der Modellhandhabung in der Beratungspraxis.

5.3.1 Regeln der Anwendung seitens des Beratungshauses Aus Sicht des Beratungshauses besteht grundsätzlich die Möglichkeit, den Beratern die Verwendung eines bestimmten Vorgehensmodells vorzuschreiben und somit dessen Einsatz sicherzustellen. Im Unterschied dazu kann das Vorgehensmodell auch lediglich als Hilfestellung empfohlen und dessen Anwendung dem freien Ermessen des Beraters überlassen werden. Die Befragung der Berater, mittels welcher Alternative der Modelleinsatz in ihren Beratungshäusern geregelt ist, ergab folgende Verteilung: in neun der befragten Unternehmen (64 %) ist die Anwendung der Vorgehensmodelle vorgeschrieben; in den restlichen fünf Unternehmen (36 %) verlässt man sich auf die freiwillige Modellnutzung durch die Berater. Selbstverständlich bedeutet die Anwendungsvorschrift keinen „sklavischen Zwang“ zum unbedingten Einsatz des Modells. Die Berater sind zwar grundsätzlich angehalten, sich an den vorgegebenen Projektablauf zu halten. Aber zum einen wird das konkrete Vorgehen im Projekt immer an die aktuelle Situation des Klienten angepasst, was zum Beispiel dazu führen kann, dass das Modell nicht vollständig angewandt wird. Zum anderen haben viele Klientenunternehmen eigene Vorgehensmodelle, nach denen sich die Berater richten müssen. In solchen Fällen versucht man, das Vorgehensmodell des Beratungshauses anzupassen oder ergänzend einzusetzen. Sollte auch dies nicht möglich sein, muss die

— 67 —

Nicht-Anwendung des Vorgehensmodells zumindest hinreichend begründet und durch Verantwortliche im Beratungshaus intern genehmigt werden. 5 4 3 2 1 0 kleine Unternehmen

mittlere Unternehmen vorgeschrieben

große Unternehmen

freiwillig

: Bild 11: Anwendung der Vorgehensmodelle nach Unternehmensgröße Inwiefern sich die Befragungsergebnisse unter Beachtung der Unternehmensgröße differenzieren lassen, zeigt Bild 11. Trotz der geringen Stichprobengröße ist eine deutliche Tendenz dahingehend erkennbar, dass größere Beratungshäuser den Einsatz von Vorgehensmodellen vorschreiben. Die kleinen Unternehmensberatungen hingegen scheinen mehrheitlich die freiwillige Nutzung der Modelle vorzuziehen.

5.3.2 Einsatz in Beratungsprojekten In engem Zusammenhang mit der soeben untersuchten Fragestellung wurde in den Interviews auch um eine seriöse Einschätzung hinsichtlich der tatsächlichen Anwendungsquote der Vorgehensmodelle in den Projekten gebeten. Demnach werden die Vorgehensmodelle bei 12 Beratungshäusern in 100 % der Projekte angewandt. Bei zwei Unternehmensberatungen beträgt die Anwendungsquote 60 - 70 % bzw. 80 % (jeweils ein Beratungsfeld betreffend). Eine direkte Abhängigkeit zwischen der Freiwilligkeit der Modellanwendung und den geringeren Prozentwerten der Modellnutzung in der Projekttätigkeit kann nicht belegt werden.

Einer

der

befragten

Berater

nannte

als

Gründe

für

die

geringere

Anwendungsquote, dass einige Kunden auf der Nutzung ihres eigenen Modells bestehen

— 68 —

und dass ein Projekt auch zu klein sein kann, um das komplexe Vorgehensmodell nutzbringend einzusetzen.

5.3.3 Dokumentation Ein weiterer interessanter Aspekt der Modellhabung betrifft die Frage, ob und inwieweit das Vorgehensmodell dokumentiert ist. Hierbei gibt es mehrere Möglichkeiten, die verschiedene Auswirkungen auf die Beratungspraxis haben. Einerseits kann ein Modell vollständig expliziert sein und damit in schriftlicher Form zur Verfügung stehen. In diesem Fall haben die Berater jederzeit die Möglichkeit, die Vorgehensweise nachzulesen, was vor allem für das Ziel der Arbeitsanleitung von Vorteil ist. Andererseits kann das Vorgehensmodell auch „nur“ im impliziten Wissen, d. h. im Kopf einzelner Berater verankert sein. Der Berater muss demnach vollständig mit dem Modell vertraut sein. Hier spielt das Erfahrungswissen jedes einzelnen Beraters für die Projekttätigkeit eine wichtige Rolle, um eine konsistente Beratungsleistung zu gewährleisten. Außerdem ist die Kombination beider Alternativen denkbar, indem bspw. nur der grobe Projektablauf oder nur einzelne Methoden des Vorgehensmodells schriftlich fixiert sind. Welche Form der Dokumentation in den befragten Unternehmensberatungen vorherrscht und inwiefern sich diese zwischen den Größenklassen unterscheidet, ist in Bild 12 dargestellt. 5 4

3 2

1 0 vollständig expliziert

kleine Unternehmen

z. T. expliziert und implizites Wissen

mittlere Unternehmen

große Unternehmen

Bild 12: Dokumentation der Vorgehensmodelle nach Unternehmensgröße

— 69 —

Insgesamt sind die Vorgehensmodelle in neun der befragten Beratungshäusern vollständig expliziert. Aus der Grafik ist zu erkennen, dass in ausnahmslos allen großen Unternehmensberatungen diese Form der Dokumentation vorherrscht. Dabei sind die Modelle bspw. in einer Datenbank oder im Intranet gespeichert, können von jedem Berater eingesehen und bei Bedarf auf den eigenen PC herunter geladen werden. Außerdem ist die Methode in vielen Fällen mit Templates, best practices oder / und Projektberichten hinterlegt. In fünf der befragten Beratungen – darunter hauptsächlich kleine Unternehmen – wurden die Vorgehensmodelle zumindest zum Teil expliziert. Die Formen dieser Dokumentation variieren von einer groben Arbeitsanleitung, über Templates für Arbeitsergebnisse

oder

Projektberichte

in

einer

Datenbank

bis

hin

zu

einer

Musterpräsentation oder der Darstellung des Modells auf der eigenen Internetseite. Der hauptsächliche Grund für diesen geringeren Explizierungsgrad ist insbesondere bei den sehr kleinen Beratungsfirmen darin zu sehen, dass die dortigen Berater durch die Eigenentwicklung ihres Modells und ihr Erfahrungswissen eigentlich keine schriftliche Ausarbeitung benötigen. Die Dokumentation erfolgt hier vor allem aus Gründen der Wiederverwendung und zu Marketingzwecken. Keines der Beratungshäuser gab hingegen an, das Vorgehensmodell gar nicht schriftlich dokumentiert zu haben, also vollständig implizit zu arbeiten.

5.3.4 Wissensmanagement Die Dokumentation des Vorgehensmodells ist auch im Zusammenhang zur verfolgten Wissensmanagement-Strategie des Beratungshauses zu sehen. Grundsätzlich lassen sich zwei Strategien des Wissensmanagements unterscheiden. Bei Verfolgung einer Kodifizierungsstrategie wird die vollständige Explizierung aller Wissensbestandteile (bspw. Vorgehensmodelle) einer Unternehmung angestrebt. Diese in schriftlicher Form vorgehaltene Wissensbasis ist allen Mitabeitern zugänglich, ermöglicht einen einfachen Informationsaustausch und trägt zur erhöhten Wiederverwendung des vorhandenen Wissens bei. Bei der Personalisierungsstrategie hingegen wird überwiegend auf die Explizierung verzichtet, wodurch dem impliziten Wissen der Berater ein höherer Stellenwert in der Beratungspraxis beigemessen wird. Die Weitergabe dieses Wissens erfolgt hierbei in erster Linie mittels persönlicher Kommunikation und Interaktion der Berater bspw. während einer gemeinsamen Projekttätigkeit.

— 70 —

Die Frage, ob das Vorgehensmodell Bestandteil eines explizierenden Wissensmanagements (Kodifizierungsstrategie) des Beratungshauses ist, ergab exakt dieselbe Ergebnisstruktur wie die zuvor behandelte Frage nach der Modell-Dokumentation. 22 Insgesamt nutzen

also

rund

zwei

Drittel

der

befragten

Unternehmensberatungen

ihre

Vorgehensmodelle im Sinne einer Kodifizierungsstrategie. Dieser Wert belegt, dass IVBeratungsunternehmen diese Strategie verfolgen, um aufgrund der wiederholt ähnlichen Aufgabenstellungen die Wiederverwendung bewährten Wissens zu erhöhen [NiKi07, 19]. Die Beratungen, die ihre Vorgehensmodelle vollständig schriftlich dokumentiert haben, nutzen diese auch im Sinne der Wissensvermittlung zur Aus- oder Weiterbildung der Berater.

Fünf

Interviewpartner

(zwei

aus

mittelgroßen

und drei

aus

großen

Beratungshäusern) gaben an, dass zu diesem Zweck Schulungen und Trainings anhand des Vorgehensmodells durchgeführt werden. Außerdem können die Vorgehensmodelle zur Unterstützung weiterer Bausteine des Wissensmanagements eingesetzt werden. So trägt die Speicherung von Projekterfahrungen und best practices sowohl zum Wissensaufbau als auch zur langfristigen Wissensbewahrung bei. Der mögliche Zugriff auf das Modell im Intranet fördert zusätzlich die Wissensverteilung unter den Beratern. In der Beratungspraxis spielt das individuelle, implizite Wissen der einzelnen Berater jedoch weiterhin eine wichtige Rolle für den Beratungserfolg. Diejenigen Beratungshäuser, die ihr Vorgehensmodell nur zum Teil expliziert haben, folgen

eher

einer

Personalisierungsstrategie

im

Wissensmanagement.

Die

Wissensweitergabe und die Ausbildung der Berater erfolgt bei diesen Beratungen direkt während der Projektdurchführung („training on the job“). Ein Interviewpartner eines mittelgroßen Beratungshauses gab außerdem an, dass neue Mitarbeiter oftmals im Projektoffice (Organisationseinheit für Projektmanagement) eingesetzt werden, damit sie alle Teile eines Projektes vermittelt bekommen.

5.3.5 Zertifizierung Die Sicherung der Beratungsqualität wurde von den Interviewpartnern als ein wichtiger Beweggrund zur Erstellung und Nutzung von Vorgehensmodellen genannt. Um die Qualität der eigenen Prozesse und somit indirekt die Beratungsqualität gegenüber den

22

Da die grafische Darstellung der Antworten Bild 12 entspricht, wurde auf eine erneute Abbildung verzichtet.

— 71 —

Klienten nachweisen zu können, bietet sich eine offizielle Zertifizierung bspw. nach DIN EN ISO 9001:2000 an. Sollten die Klienten besonderen Wert auf einen solchen Nachweis legen, stellt die Zertifizierung einen Vorteil in der Projektakquise dar. Die Befragung, ob das Beratungshaus eine solche Zertifizierung besitzt, die auch das Vorgehensmodell einschließt, ergab jedoch folgendes Resultat (Bild 13).

ja 2 [14%]

nein 12 [86%]

Bild 13: Zertifizierung der Vorgehensmodelle

Zwei der befragten Beratungshäuser (ein kleines, ein mittleres) haben eine Zertifizierung durchgeführt, während die Berater der anderen 12 Unternehmen diese Frage verneinten. Auf Nachfrage gaben zwei Berater an, dass eine Zertifizierung auch zukünftig nicht angestrebt wird. Ein Berater berichtete, dass die Zertifizierung wieder aufgegeben wurde. Als Grund gegen eine Zertifizierung wurde ein schlechtes Kosten-Nutzen-Verhältnis angeführt. Der zu betreibende Aufwand zur Erlangung einer Zertifizierung ist aus Sicht der Beratungshäuser im Verhältnis zum zu erzielenden Nutzen bei der Akquise zu hoch. Das könnte eventuell daran liegen, dass aus Klientensicht auch ein offizielles Zertifikat die tatsächliche Beratungsqualität nicht garantieren kann. Sinnvoller scheint daher die Variante zu sein, die eine der großen Beratungen gewählt hat. Die Beratungsfirma selbst besitzen zwar keine Zertifizierung, aber die einzelnen Berater können sich hinsichtlich bestimmter Standards zertifizieren lassen.

— 72 —

5.3.6 Evaluierung und Weiterentwicklung Ein weiterer wichtiger Aspekt zur langfristigen Qualitätssicherung ist die Evaluierung der Vorgehensweise

am

Ende

der

durchgeführten

Projekte

und

die

regelmäßige

Weiterentwicklung des gesamten Modells. Denn nur durch diese Pflege des Vorgehensmodells kann dessen Aktualität aufrechterhalten und somit der erfolgreiche Einsatz in der Beratungspraxis gewährleistet werden.

nein 3 [21%]

ja 11 [79%]

Bild 14: Evaluierung der Vorgehensmodelle

Die oben stehende Grafik (Bild 14) zeigt deutlich, dass bei der Mehrheit der Beratungshäuser (11) eine Evaluierung bezüglich der Vorgehensweise am Ende der jeweiligen Projektdurchführung stattfindet. Die Benennungen dieser Aktivität reichen von „Schlussbilanz“, „Abschlussmeeting“ und „de-briefing“ über „lessons learned“ oder „feedback“ bis hin zu „touch down“. Dabei werden die Projektkennzahlen, wie Zeit- bzw. Termin- und Kosteneinhaltung, überprüft, denn daraus lassen sich auch Rückschlüsse auf die jeweilige Eignung des Vorgehensmodells ziehen. Ein Vorgehensmodell sollte durch die Beschreibung der auszuführenden Aktivitäten bereits vor Projektbeginn eine Einschätzung der benötigten Zeit und des Aufwands ermöglichen. Sind diesbezüglich wiederholt größere Abweichungen zwischen Plan und Ist festzustellen, die nicht auf außergewöhnliche Ereignisse während der Projektdurchführung zurückzuführen sind, kann das ein Anhaltpunkt für ein unzureichendes Vorgehensmodell sein. Neben

dieser

quantitativen

Kontrolle

werden

im

Rahmen

der

inhaltlichen

Auseinandersetzung mit dem Projektablauf Erfahrungen hinsichtlich positiver und — 73 —

negativer Begebenheiten gesammelt. Anhand dieser qualitativen Evaluation können ebenfalls Defizite innerhalb des Vorgehensmodells identifiziert werden. Außerdem führen zwei Beratungshäuser nach Projektende eine Messung der Kundenzufriedenheit mittels Fragebögen bzw. Befragungen durch. Durch Beachtung dieser Sicht von außen können zusätzliche Anregungen zur Verbesserung der Vorgehensweise aufgenommen werden. Obwohl gerade kleinere Beratungshäuser oft keine explizite Evaluation nach Projektabschluss durchführen, gaben alle Befragten an, dass eine regelmäßige Weiterentwicklung ihrer Vorgehensmodelle erfolgt. Gewöhnlich wird an dem groben Phasenschema jedoch kaum etwas verändert. Die Weiterentwicklung bezieht sich vielmehr auf Details wie die Entwicklung neuer best practices, die Standardisierung von Templates oder die Verbesserung einzelner Methoden und Tools. Die Basis dieser Maßnahmen bilden in der Regel die in den Projekten gewonnenen Erfahrungen der Berater. In einem großen internationalen Beratungshaus kann sich außerdem jeder Mitarbeiter an Ideensammlungen (sog. Brainstormings) und Abstimmungen über Verbesserungsvorschläge im Intranet beteiligen. Ferner nutzen alle Berater und Methodenverantwortlichen wissenschaftliche Literatur,

Veröffentlichungen

in

Zeitschriften

oder

Schulungsmaßnahmen

zur

regelmäßigen Weiterbildung. Dadurch kann der Innovationsprozess hinsichtlich neuer technischer und geschäftlicher Entwicklungen in der Beratungsbranche ständig beobachtet bzw. beurteilt werden. Sollten neue Beratungsaufgaben oder Fragestellungen aufkommen, die einen anderen Fokus des vorhandenen Vorgehensmodells erfordern, können diese frühzeitig in den Weiterentwicklungsprozess einfließen.

5.3.7 Relevanz für die Projektgewinnung Eine weitere interessante Fragestellung bei Vorgehensmodellen in der Beratungspraxis ist deren

Bedeutsamkeit

aus

Klientensicht.

Infolge

einer

steigenden

Klienten-

professionalisierung im Sinne einer systematischeren Auswahl und Kontrolle der Berater 23 könnten auch Vorgehensmodelle eine wichtige Rolle bei der Auftragserteilung spielen. Mit diesem Fokus wurden die Berater gefragt, ob sie in der Angebotsphase während der Projektanbahnung von den Klienten auf ihr Vorgehensmodell angesprochen werden.

23

Mohe nennt hierzu als eine mögliche Strategie der Klientenprofessionalisierung den „Aufbau von Konsultationsexpertise“. Das dabei vorgestellte Konzept zeigt verschiedene Möglichkeiten zur objektiven und rationalen Auswahl der Berater durch den Klienten auf [Mohe05, 211-215].

— 74 —

Einzig ein selbstständiger Berater verneinte diese Frage und äußerte die Ansicht, dass die Klientenprofessionalisierung in der Praxis noch nicht „angekommen“ sei, da die Beraterauswahl seitens der Klienten seiner Erfahrung nach sehr unstrukturiert ablaufe. Die anderen Befragten gaben an, dass sie durchaus von den Klienten auf ihr Vorgehensmodell angesprochen werden. Dass die Einschätzungen hinsichtlich der letztendlichen Relevanz im Zusammenhang mit der Auswahlentscheidung für ein Beratungsangebot jedoch sehr unterschiedlich ausfielen, zeigt folgende grafische Aufbereitung der Antworten (Bild 15).

keine Angabe 1 [7%]

hoch 3 [21,5%]

mittel 3 [21,5%]

niedrig 7 [50%]

Bild 15: Relevanz der Vorgehensmodelle für die Projektgewinnung

Die Hälfte der befragten Berater vertraten die Ansicht, dass das Vorgehensmodell als Entscheidungskriterium für die Beraterauswahl eine untergeordnete Rolle spielt. Viele Klienten besitzen relativ wenig Kenntnise über methodisches Vorgehen bezüglich der Aufgabenstellungen und engagieren aus diesem Grund externe Berater, jedoch erwarten sie grundsätzlich von Unternehmensberatungen ein konsistentes Vorgehensmodell. Im Allgemeinen werden hierbei Vorgehensmodelle als grundlegendes Handwerkszeug der Berater betrachtet. Sie bilden lediglich die Basis für gute Beratungsleistungen und stellen aus Sicht der Beratungshäuser kein Alleinstellungsmerkmal oder Differenzierungsfaktor gegenüber Konkurrenten dar. Ein Interviewpartner vertrat sogar die Meinung, dass Vorgehensmodelle an sich überbewertet werden, da sie trotz ihrer mitunter sehr detaillierten Beschreibungen schlussendlich doch nur einer generischen Vorgehensweise entsprechen. Auch wenn dies nur eine einzelne persönliche Auffassung ist, teilten alle Berater die Ansicht, dass Erfahrungen, Referenzen, der Preis sowie die Reputation des Beratungshauses wichtigere Kriterien für die Beraterauswahl darstellen. Außerdem ist die — 75 —

Zusammenarbeit mit externen Unternehmensberatern aus Klientensicht immer eine Vertrauensangelegenheit, so dass gute und langjährige Geschäftsbeziehungen ebenfalls eine wichtige Rolle für die Projektgewinnung spielt. War der Klient mit den bisherigen Beratungsleistungen

zufrieden,

wird

er

diese

positiven

Erfahrungen

als

Entscheidungsgrundlage heranziehen [BaAr04, 68]. Basierte zumindest ein Teil des bisherigen Beratungserfolgs auf dem Einsatz eines Vorgehensmodells, stellt es zumindest einen indirekten Nutzen für das Beratungshaus dar. Ferner werden in vielen, insbesondere großen Klientenunternehmen eigene Modelle angewandt, an denen sich die Beratung orientieren muss. In diesen Fällen erfolgt die Beraterauswahl nicht aufgrund des „besten“ Vorgehensmodells, sondern vielmehr in Abhängigkeit davon, ob das Modell zu den hauseigenen Vorgehensweisen und Vorstellungen des Klienten passt. Berater aus drei Unternehmen hingegen messen den Vorgehensmodellen einen hohen Stellenwert im Rahmen der Projektgewinnung bei. Aus Gründen der Investitions- und Prozesssicherheit fordern die Klienten explizit eine strukturierte und nachvollziehbare Arbeitsweise. Der Nachweis eines bewährten Vorgehensmodells stellt daher aus Sicht dieser Beratungshäuser einen wichtigen „Pluspunkt“ für die Akquisition dar. Diesbezüglich berichtete ein Berater eines großen Unternehmens, dass das Modell schon in mehreren Projekten ausschlaggebendes Entscheidungskriterium war. In Bezug auf den Umfang des zu vergebenen Projektes sagte ein Interviewpartner eines anderen großen Beratungshauses: „Bei größeren Projekten ist es fast schon ein Ausschlusskriterium, wenn man nicht mit einer standardisierten Methode arbeitet.“ Aber auch ein selbstständiger Berater wurde schon mehrfach aufgrund seines Vorgehensmodells engagiert und bestätigte die hohe Relevanz des Modells sowohl aus Sicht der Klienten als auch aus eigener Perspektive. Schließlich trägt ein erfolgreich eingesetztes Vorgehensmodell langfristig zur Steigerung der Reputation des Beratungshauses bei, was wiederum Klienten positiv in ihrer Entscheidung beeinflussen kann. Nach Ansicht der drei Interviewpartner, die den Vorgehensmodellen eine mittlere Relevanz zuschreiben, ist das Vorhandensein eines Modell zwar wichtig, aber kein entscheidender Auswahlgrund. Ein Berater äußerte die Vermutung, dass die Anwendung eines Vorgehensmodells aus Sicht der Klienten mit Sicherheit bedeutsam ist, aber aufgrund der mitunter schwierigen Vergleichbarkeit der Modelle keine Auswahl unter alleiniger Beachtung dieses Kriteriums durchgeführt werden kann.

— 76 —

Die Auswertung der Daten ließ keinen Zusammenhang mit der Unternehmensgröße erkennen. Hinsichtlich der verschiedenen Beratungsfelder lässt sich jedoch eine Tendenz ausmachen (siehe hierzu Bild 16). 8 7 6 5 4 3 2 1 0 Beratungsfeld Software- Beratungsfeld SoftwareAuswahl Einführung hoch

mittel

Beratungsfeld ITArchitektur

niedrig

Bild 16: Relevanz der Vorgehensmodelle nach ausgewählten Beratungsfeldern (erweiterte Stichprobe n = 21)

In den Beratungsfeldern Software-Auswahl und Software-Einführung haben die Vorgehensmodelle – zumindest aus Sicht der hier befragten Berater – überwiegend wenig Relevanz für die Klienten. Dies kann wahrscheinlich damit begründet werden, dass sich die einzelnen Modelle der Beratungshäuser nur wenig voneinander unterscheiden. Mit dem Fokus auf die Vorgehensweise ist es somit aus Klientensicht fast „egal“, welches Beratungshaus das Projekt durchführt. In diesem Umfeld spielen demnach Kriterien wie Erfahrung, Preis oder auch Sympathie der Berater eine wichtigere Rolle. Im hier nicht näher dargestellten Bereich der IT-Architektur zeichnete sich hingegen eine gegenteilige Tendenz ab. Hier wurde die Relevanz eines Vorgehensmodells im Zusammenhang mit der Beraterauswahl überwiegend als hoch eingeschätzt. Aus Sicht eines der befragten Berater spielt ein Modell deshalb eine wichtige Rolle, weil das Beratungsfeld IT-Architektur vielfältige und neue Themen wie bspw. Service-orientierte Architekturen umfasst, zu denen die meisten Klienten keine eigenen Kenntnisse besitzen. Ein anderer Interviewpartner vertritt die Meinung, dass ein Beratungshaus bei unscharfen Themen (wie IT-Architektur) anhand seines Modells die eigenen Erfahrungen sowie das vorhandene Wissen über die notwendige Arbeitsweise demonstrieren muss. — 77 —

5.3.8 Publikation der Vorgehensmodelle Der letzte in dieser Arbeit untersuchte Aspekt der Modellhandhabung in der Beratungspraxis befasst sich mit der Publikation der Vorgehensmodelle durch die Beratungshäuser. Wie im vorigen Abschnitt deutlich wurde, kann das Vorhandensein eines Modells die Beraterauswahl (aus Klientensicht) bzw. die Projektgewinnung (aus Sicht des Beratungshauses) beeinflussen. Auch die Publikation des Vorgehensmodells kann daher zur Förderung der Projektgewinnung bzw. Klientenakquise beitragen. Mögliche Publikationsvarianten sind bspw. indirekte Marketingmaßnahmen wie das Verfassen von Artikeln für Fachzeitschriften oder die Veröffentlichung von Büchern [BaAr04, 70]. Auch die Darstellung des Modells auf der eigenen Internetseite des Beratungshauses könnte das Interesse potentieller Klienten wecken und diese zu Projektanfragen bewegen. Eine weitere Möglichkeit der Publikation besteht in der Erstellung von Broschüren und success stories, in denen durch die Darstellung von durchgeführten Projekten [Nied04, 110] der erfolgreiche Einsatz des Vorgehensmodells aufgezeigt werden kann. Von den insgesamt 14 hier befragten Unternehmensberatungen publizieren neun (64 %) ihre Vorgehensweisen nicht. Die Gründe für diese Entscheidung bzw. gegen die Publikation sind dabei ganz unterschiedlich. So verzichtet ein Beratungshaus deshalb auf Veröffentlichungen, weil der öffentliche Standard, an den sich das Vorgehensmodell anlehnt, bereits von der diesen Standard entwickelnden Organisation publiziert wird. Wie bereits im vorigen Abschnitt erwähnt, sehen manche Beratungshäuser in den Modellen bezüglich der Software-Auswahl und -Einführung kein Alleinstellungsmerkmal und damit auch keinen Mehrwert für die Klientengewinnung. Schließlich ist die Bewahrung des eigenen Wissens und der Erfahrungen, die in das Vorgehen eingeflossen sind, ein häufiger Beweggrund, die Modelle nicht zu publizieren. Insbesondere die best practices, Templates oder auch einzelne Modellteile werden in diesen Fällen als Wettbewerbsvorteil eingeschätzt und sollen vor der Konkurrenz „geheim“ gehalten werden. Bei fünf (36 %) Beratungshäusern hingegen wird das Vorgehensmodell in irgendeiner Variante veröffentlicht. Neben den bereits genannten Möglichkeiten bieten zwei Unternehmensberatungen Software-Tools zum Kauf an, in denen ihre Modelle umgesetzt wurden. Ein selbstständiger Berater veröffentlicht seine Methode in Vorträgen oder auf Kongressen, um so seinen Bekanntheitsgrad zu steigern und neue Klienten zu gewinnen. Die

Verteilung

der

Antworten

auf

die

verschiedenen

Beratungsunternehmen kann Bild 17 entnommen werden. — 78 —

Größenklassen

der

5

4

3

2

1

0 ja kleine Unternehmen

nein mittlere Unternehmen

große Unternehmen

Bild 17: Publikation der Vorgehensmodelle nach Unternehmensgröße

Aus dieser Grafik lässt sich erkennen, dass die mittelgroßen und großen Beratungshäuser eine restriktivere Kommunikationspolitik hinsichtlich ihrer Vorgehensmodelle betreiben als es bei den kleinen Beratungen der Fall ist. Ein Grund könnte darin liegen, dass es für die kleinen Unternehmen von vornherein schwerer ist, neue Kontakte zu potentiellen Klienten herzustellen und die Publikation ihrer Vorgehensmodelle hier eine zusätzliche Chance bietet. Den mittelgroßen und vor allem den großen Beratungshäusern kommt dagegen ihr höherer Bekanntheitsgrad bei der Klientenakquise zugute.

— 79 —

6 Fazit Auf die zu Beginn dieser Arbeit gestellten Fragen hinsichtlich des Einsatzes von Vorgehensmodellen in der IV-Beratung soll an dieser Stelle erneut eingegangen werden. Zunächst kann festgehalten werden, dass alle befragten Unternehmensberatungen in mindestens einem der untersuchten Beratungsfelder Vorgehensmodelle einsetzen. Die statistische Auswertung der Fragen zur Modellhandhabung in der Beratungspraxis ergab ferner, dass die Beratungshäuser die Vorgehensmodelle nicht nur bereitstellen, sondern dass diese von den Beratern auch sehr häufig tatsächlich in den Beratungsprojekten angewandt werden. Die diesbezügliche, zu Beginn der Arbeit geäußerte Vermutung, dass fast alle Beratungen ein Modell im Einsatz haben, wird demnach bestätigt. Bezüglich der Vermutung, dass kleine Beratungen eventuell „unprofessioneller“ arbeiten als große Beratungshäuser kann allgemein festgehalten werden, dass dies nicht der Fall ist. Abgesehen von einigen (auf pragmatische Gründe zurückzuführenden) Unterschieden im Modellumgang, lassen die Untersuchungsergebnisse keine Bestätigung dieser Vermutung zu.

Auch

während

der

Interviewdurchführung

konnten

kaum

diesbezügliche

Besonderheiten festgestellt werden. Die Frage, ob alle Beratungshäuser die gleiche Art von Vorgehensmodellen einsetzen, kann für die hier betrachtette Software-Auswahl und Software-Einführung bestätigt werden. Dabei ist jedoch hervorzuheben, dass ausnahmslos alle befragten Berater zu allen untersuchten Vorgehensmodellen angaben, dass diese jederzeit und unbedingt an die spezifische Klientensituation angepasst werden müssen. Trotz der zahlreichen Vorteile von Vorgehensmodellen ist daher die Balance zwischen festgeschriebenen Methoden und individuellen Beratungsangeboten für den Erfolg entscheidend. Dies lässt sich auch am Beispiel der Software-Auswahl-Beratung belegen, denn diese Beratungsleistung ist eine klassische Kernaufgabe der IV-Beratung, obwohl es zahlreiche Literaturquellen gibt, die Klienten ebenfalls als Hilfestellung heranziehen könnten. Allein die schriftliche Explizierung der Vorgehensweise reicht für eine erfolgreiche Auswahl nicht aus. Aufgrund der relativ kleinen Stichprobe der in dieser Arbeit befragten Beratungshäuser sollten weitere empirische Erhebungen zur Vertiefung und Ergänzung der gewonnenen Erkenntnisse, gerade auch für die hier nicht betrachteten Aufgabenfelder der IV-Beratung durchgeführt werden.

— 80 —

Literaturverzeichnis

[Aren04]

Arens, Thomas: Methodische Auswahl von CRM Software – Ein Referenzmodell zur methodengestützten Beurteilung und Auswahl von Customer Relationship Management Informationssystemen. Cuvillier, Göttingen 2004.

[BaAr04]

Barchewitz, Christoph; Armbrüster, Thomas: Unternehmensberatung – Marktmechanismen, Marketing, Auftragsakquisition. DUV, Wiesbaden 2004.

[BDU07]

Bundesverband

Deutscher

Unternehmensberater

BDU

e.V.:

Beraterdatenbank. http://www.bdu.de/beraterdatenbank.html?, Abruf am 2007-10-01. [BDU08a]

Bundesverband Deutscher Unternehmensberater BDU e.V.: Branche – Unternehmensberatung heute. http://www.bdu.de/t_bran.html, Abruf am 2008-02-10.

[BDU08c]

Bundesverband Deutscher Unternehmensberater BDU e.V.: Informationen für Berufseinsteiger. http://www.bdu.de/karriere.html, Abruf am 2008-02-10.

[BDU09]

Bundesverband Deutscher Unternehmensberater: Facts & Figures zum Beratermarkt 2008/9. Marktstudie, Bonn 2009.

[BMRu04] Biethahn,

Jörg;

Mucksch,

Harry;

Ruf,

Walter:

Ganzheitliches

Informationsmanagment – Band I: Grundlagen. 6. Aufl., Oldenbourg, München 2004. [Bohl04]

Bohlen, Jens: IT-Service-Modelle. In: Gründer, Torsten (Hrsg.): IT-Outsourcing in der Praxis – Strategien, Projektmanagement, Wirtschaftlichkeit. Schmidt, Berlin 2004, S. 45-59.

[Bruh08]

Bruhn, Manfred: Qualitätsmanagement für Dienstleistungen – Grundlagen, Konzepte, Methoden. 7. Aufl., Springer, Berlin Heidelberg 2008.

[BVWi07]

Becker,

Jörg;

Vering,

Unternehmenssoftwareeinführung:

Oliver;

Winkelmann,

Eine strategische

Axel:

Entscheidung.

In:

Becker, Jörg; Vering, Oliver; Winkelmann, Axel (Hrsg.): Softwareauswahl und -einführung in Industrie und Handel – Vorgehen bei und Erfahrungen mit

— 81 —

ERP- und Warenwirtschaftssystemen. Springer, Berlin Heidelberg 2007, S. 130. [Capg07]

Capgemini: Studie IT-Trends 2007 – IT ermöglicht neue Freiheitsgrade. http://www.de.capgemini.com/m/de/tl/IT-Trends_2007.pdf, 2007-02, Abruf am 2007-10-09.

[Capg08]

Capgemini: Studie IT-Trends 2008 – IT-Leiter im Spagat zwischen Dienstleister und Business Partner. http://www.de.capgemini.com/m/de/ tl/IT-Trends_2008.pdf, 2008-03, Abruf am 2008-04-20.

[Dern06]

Dern, Gernot: Management von IT-Architekturen – Richtlinien für die Ausrichtung, Planung und Gestaltung von Informationssystemen. 2. Aufl., Vieweg, Wiesbaden 2006.

[Dich98]

Dichtl, Markus: Standardisierung von Beratungsleistungen. DUV, Wiesbaden 1998.

[Eber04]

Eberhardt, Michael: Business Process Outsourcing (BPO) am Beispiel von HR. In: Gründer, Torsten (Hrsg.): IT-Outsourcing in der Praxis – Strategien, Projektmanagement, Wirtschaftlichkeit. Schmidt, Berlin 2004, S. 141-149.

[GaLo01]

Gabriel, Harald; Lohnert, Stefan: Implementierung von StandardsoftwareLösungen. In: Scheer, August-Wilhelm; Köppen, Alexander (Hrsg.): Consulting – Wissen für die Strategie-, Prozess- und IT-Beratung. 2. Aufl., Springer, Berlin Heidelberg 2001, S. 181-210.

[HaNe05a] Hansen, Hans R.; Neumann, Gustaf: Wirtschaftsinformatik 1 – Grundlagen und Anwendungen. 9. Aufl., Lucius & Lucius, Stuttgart 2005. [HaNe05b] Hansen,

Hans

R.;

Neumann,

Gustaf:

Wirtschaftsinformatik

2



Informationstechnik. 9. Aufl., Lucius & Lucius, Stuttgart 2005. [Hein97]

Heinzl, Armin: Outsourcing der IV. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 304305.

[HeLe05]

Heinrich, Lutz J.; Lehner, Franz: Informationsmanagement – Planung, Überwachung und Steuerung der Informationsinfrastruktur. Oldenbourg, München 2005.

— 82 —

[HHRo04]

Heinrich,

Lutz

J.;

Heinzl,

Armin;

Roithmayr,

Friedrich:

Wirtschaftsinformatik-Lexikon. 7. Aufl., Oldenbourg, München 2004. [JoGo06]

Johannsen, Wolfgang; Goeken, Matthias: IT-Governance – neue Aufgaben des IT-Managements. In: Fröschle, Hans-Peter; Strahringer, Susanne (Hrsg.): HMD – Praxis der Wirtschaftsinformatik, Heft 250 (IT-Governance). dpunkt.verlag, Heidelberg 2006, S. 7-20.

[KBSt08]

Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung / Bundesministerium des Innern: ITServicemanagement. http://www.kbst.bund.de/cln_028/nn_991266/Conte nt/Standards/ITIL/IT__Servicemanagement/it__servicemanegement__nod e.html__nnn=true, Abruf am 2008-03-26.

[Kröb91]

Kröber, H.-W.: Der Beratungsbegriff in der Fachliteratur. In: Hofmann, M. ; von Rosenstiel, L.; Zapotoczky, K. (Hrsg.): Die sozio-kulturellen Rahmenbedingungen für Unternehmensberater. Kohlhammer, Stuttgart 1991, S. 1-37.

[Kval96]

Kvale, Steinar: Interviews – an introduction to qualitative research interviewing. Thousand Oaks, Californien 1996.

[Lüne02]

Lünendonk GmbH: Lünendonk-Studie 2002 „Beratung & Realisierung“ – Presse-Summary, Bad Wörishofen 2002.

[Lüne07]

Lünendonk GmbH: Top 25 der IT-Beratungs- und SystemintegrationsUnternehmen in Deutschland 2006. http://www.luenendonk.de/it_ber atung.php, Abruf am 2007-10-01.

[Mais03]

Maister, David H.: Managing the Professional Service Firm. Schuster & Schuster, London, 2003.

[MaVo05]

Marlière, Andrea; Volk, Ute: Standardisierung als Herausforderung für erfolgreiche Consulting-Unternehmen. In: Stolorz, Christian; Fohmann, Lothar (Hrsg.): Controlling in Consultingunternehmen – Instrumente, Konzepte, Perspektiven. 2. Aufl., Gabler, Wiesbaden 2005, S. 263-269.

[Maye06]

Mayer, Horst O.: Interview und schriftliche Befragung – Entwicklung, Durchführung und Auswertung. 3. Aufl., Oldenbourg, München 2006.

— 83 —

[Mayr03]

Mayring, Philipp: Qualitative Inhaltsanalyse – Grundlagen und Techniken. 8. Aufl., Beltz / DUV, Weinheim 2003.

[Mayr05]

Mayring, Philipp: Qualitative Inhaltsanalyse. In: Flick, Uwe; von Kardorff, Ernst; Steinke, Ines (Hrsg.): Qualitative Forschung – ein Handbuch. 4. Aufl., Rowohlt, Reinbek bei Hamburg 2005, S. 468-475.

[Merk05]

Merkens, Hans: Auswahlverfahren, Sampling, Fallkonstruktion. In: Flick, Uwe; von Kardorff, Ernst; Steinke, Ines (Hrsg.): Qualitative Forschung – ein Handbuch. 4. Aufl., Rowohlt, Reinbek bei Hamburg 2005, S. 286-299.

[Mert97]

Mertens, Peter: Integrierte Informationsverarbeitung. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 208-209.

[Mies04]

Mieschke, Lutz: Strategisches Geschäftsmodell der Informationstechnologieberatung. DUV, Wiesbaden 2004.

[Mohe05]

Mohe,

Michael:

Klientenprofessionalisierung



Strategien

eines

professionellen Umgangs mit Beratung. In: Seidl, David; Linder, Martin; Kirsch,

Werner

(Hrsg.):

Grenzen

der

Strategieberatung:

Eine

Gegenüberstellung der Perspektiven von Wissenschaft, Beratung und Klienten. Haupt Verlag, Bern 2005, S.203-227. MSDK]

Müller-Stewens, Günter.; Drolshammer, Jens; Kriegmeier, Jochen.: "Professional Service Firms – Branchenmerkmale und Gestaltungsfelder des Managements", in: Müller-Stewens, G.; Drolshammer, J.; Kriegmeier, J. (Hrsg.): "Professional Service Firms: Wie sich multinationale Dienstleister positionieren" FAZ-Verlag, Frankfurt/M. 1999; S. 11 – 153.

[Nied03]

Niedereichholz,

Christel:

Unternehmensberatung

Band

2



Auftragsdurchführung und Qualitätssicherung. 3. Aufl., Oldenbourg, München 2003. [Nied04]

Niedereichholz, Christel: Unternehmensberatung Band 1 – Beratungsmarketing und Auftragsakquisition. 4. Aufl., Oldenbourg, München 2004.

[Niem05]

Niemann, Klaus D.: Von der Unternehmensarchitektur zur IT-Governance – Bausteine für ein wirksames IT-Management. Vieweg, Wiesbaden 2005.

— 84 —

[NiKi08]

Nissen, V.; Kinne. S.: IV- und Strategieberatung – eine Gegenüberstellung. In: Loos, P., Breitner, M.; Deelmann, T. (Hrsg.): Proceedings der Teilkonferenz „IT-Beratung“ der MKWI 2008, Berlin: Logos, S. 89 – 106.

[Niss07]

Nissen, V.: Consulting Research – eine Einführung. In: Nissen, V. (Hrsg.): Consulting

Research.

Unternehmensberatung

aus

wissenschaftlicher

Perspektive, Reihe Gabler Edition Wissenschaft, Wiesbaden: DUV, 2007, S. 3 – 38. [NiWe06]

Nissen, Volker; Wenske, Axel: Qualitätsmanagement in Beratungsunternehmen – Ergebnisse einer empirischen Untersuchung im deutschen Markt für Unternehmensberatung, Forschungsbericht Nr. 2006-01. In: Nissen, Volker

(Hrsg.):

Forschungsberichte

zur

Unternehmensberatung.

http://www.db-thueringen.de/servlets/DerivateServlet/Derivate7969/Fb_z_Ub_2006-01.pdf, Abruf am 2007-07-30. [Öste97]

Österle, Hubert: Standardsoftware – Auswahl und Einführung. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 379-380.

[OvTu07]

Overhage, Sven; Turowski, Klaus: Serviceorientierte Architekturen – Konzept und methodische Herausforderungen. In: Nissen, Volker; Petsch, Mathias; Schorcht, Hagen (Hrsg.): Service-orientierte Architekturen – Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen. DUV, Wiesbaden 2007, S. 3-17.

[PNTr07]

Petsch, Mathias; Nissen, Volker; Traub Timo: Anwendungspotenziale von Intelligenten Agenten in Service-orientierten Architekturen. In: Nissen, Volker; Petsch, Mathias; Schorcht, Hagen (Hrsg.): Service-orientierte Architekturen – Chancen und Herausforderungen bei der Flexibilisierung und Integration von Unternehmensprozessen. DUV, Wiesbaden 2007, S. 167-182.

[Rohl01]

Rohloff, Michael: Prozeßrahmenwerk: Ein Referenzmodell für betriebliche Geschäftsprozesse als Grundlage einer systematischen Bebauung der IuK Landschaft. http://www.wi.uni-muenster.de/is/tagung/Ref2001/ Kurzbeitrag07.pdf, Abruf am 2008-02-01.

[ScSe99]

Schwan, Konrad; Seipel, Kurt G.: Erfolgreich beraten – Grundlagen der Unternehmensberatung. Beck, München 1999. — 85 —

[Seib97a]

Seibt, Dietrich: Aufbau- und Ablaufstrukturen der Informationsverarbeitung. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 42-43.

[Seib97b]

Seibt, Dietrich: Vorgehensmodell. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 431434.

[Sinz97]

Sinz, Elmar: Modellierung. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 271.

[SoTr07]

Sontow,

Karsten;

Treutlein,

Peter:

Einsatz

von

Werkzeugen

zur

Softwareauswahl am Beispiel des IT-Matchmakers. In: Becker, Jörg; Vering, Oliver; Winkelmann, Axel (Hrsg.): Softwareauswahl und -einführung in Industrie und Handel – Vorgehen bei und Erfahrungen mit ERP- und Warenwirtschaftssystemen. Springer, Berlin Heidelberg 2007, S. 109-127. [StHa05]

Stahlknecht,

Peter;

Hasenkamp,

Ulrich:

Einführung

in

die

Wirtschaftsinformatik. 11. Aufl., Springer, Berlin Heidelberg 2005. [Vogl97]

Vogler, Petra: Systemintegrator. In: Mertens, Peter (Haupthrsg.): Lexikon der Wirtschaftsinformatik. 3. Aufl., Springer, Berlin Heidelberg 1997, S. 392.

[Walg95]

Walger, Gerd: Idealtypen der Unternehmensberatung. In: Walger, Gerd (Hrsg.):

Formen

der

Unternehmensberatung



systemische

Unternehmensberatung, Organisationsentwicklung, Expertenberatung und gutachterliche Beratungstätigkeit in Theorie und Praxis. Schmidt, Köln 1995, S. 1-18.

— 86 —

Anhang: Leitfaden-Fragebogen der empirischen Untersuchung

Fragebogen „Vorgehensmodelle in der IV-Beratung“ Allgemein: -

Welche Organisationsform liegt vor ? (unabhängige/reine IT-Beratung, Inhouse-Consulting, IT-Beratungs-Abteilung)

-

Wie viele Berater / Mitarbeiter sind im Unternehmen bzw. in der Abteilung beschäftigt?

Vorgehensmodell: -

Bitte beschreiben Sie die Phasen Ihres Vorgehensmodells, d.h. die groben Prozessschritte eines Projektes im Beratungsfeld ... (SW-Auswahl, SW-Einführung oder IT-Architektur / SOA). o Welche einzelnen fachlichen Aktivitäten beinhaltet jede dieser Phasen? o Aufgrund welcher Ereignisse wird der jeweils nächste Prozessschritt ausgelöst? bzw. Welche Voraussetzungen müssen für die jeweilige Phase erfüllt sein? o Was sind die Ergebnisse der einzelnen Phasen? (Dokumente usw.) o Welcher Zeitrahmen ist für das gesamte Projekt vorgesehen und welche Zeiträume sind für die einzelnen Phasen geplant (auch in % der Gesamtzeit)?

-

Welcher Art ist das Modell (Ist der vorgesehene Ablauf linear / sequentiell oder iterativ? Æ Phasenmodell / Wasserfallmodell, Spiralmodell, V-Modell ... )?

-

Wie flexibel ist das Modell im Projekt an die Kundensituation anpassbar? (Weglassungen, Umsortierung, Verzögerungen, Wiederholungen usw.)

-

Wann / In welchen Prozessschritten ist der Kunden aktiv oder passiv beteiligt?

-

Sind innerhalb des Beratungshauses auch andere Organisationseinheiten / Experten (Manager, Fachabteilungen) an dem Prozess beteiligt und wenn ja, wann?

— 87 —

-

Inwieweit wird der Prozess IT-technisch unterstützt? Nutzen Sie in den Phasen bspw. Datenbanken oder andere Software-Tools und wenn ja, welche?

-

Gibt es festgelegte Messgrößen oder Kennzahlen, um eine qualitative oder quantitative Bewertung des Prozesses und der Teilschritte vorzunehmen (bzgl. Projektmanagement, Zielerreichung einzelner Prozessschritte ... ) und wenn ja, welche?

-

Wird

das

Vorgehensmodell

auch

in

Projekten

eingesetzt,

die

andere

Beratungsfelder betreffen – wenn ja, welche – oder ist es nicht übertragbar?

Entstehung: -

Wann wurde das Vorgehensmodell entwickelt? bzw. Seit wann / wie lange wird das Vorgehensmodell bereits angewandt?

-

Was war die Motivation zur Entwicklung dieses Modells (bspw. Kundenwunsch, als Arbeitsanleitung für Mitarbeiter, zur Qualitätssicherung, ... )?

-

Wie entstand das Vorgehensmodell bzw. was war dessen Ursprung (Anlehnung an Literatur / Standards, aus Projekterfahrungen ... )?

Handhabung: -

In wie vielen Projekten (%) wird das Vorgehensmodell angewandt (geschätzt)?

-

Ist die Anwendung von Seiten des Beratungshauses vorgeschrieben oder erfolgt der Einsatz nach freiem Ermessen des Beraters?

-

Ist das Vorgehensmodell explizit in schriftlicher Form dokumentiert und für alle Berater zugänglich? Oder basiert es „nur“ auf implizitem Wissen einiger Berater und wird in Gesprächen weitervermittelt?

-

Ist das Vorgehensmodell Bestandteil Ihres Wissensmanagements und dient somit auch der Ausbildung von (neuen) Beratern?

-

Besitzt Ihr Unternehmen eine Zertifizierung, in der auch das Vorgehensmodell enthalten ist? bzw. Ist das Vorgehensmodell offiziell zertifiziert?

— 88 —

-

Erfolgt an jedem Projektende eine Evaluation bezüglich ihrer angewandten Vorgehensweise (eventuell mit Hilfe von Kennzahlen / Messgrößen)?

-

Erfolgt eine regelmäßige Weiterentwicklung des Modells und wenn ja, in welcher Form?

-

Werden Sie bei der Projektakquisition von Klienten gezielt auf ein / Ihr Vorgehensmodell angesprochen? (Stichwort: Klientenprofessionalisierung)

-

Publizieren Sie Ihre Vorgehensweise (bspw. in Zeitschriften oder auf Ihrer Webseite)? o wenn ja: Haben Sie aufgrund der Verwendung ihres Vorgehensmodells (bzw. dessen Publizierung) vermehrt Klienten / Projekte gewinnen können? o wenn nein: Warum nicht?

— 89 —