Fallstudie: VORMO - Vorgehensmodell

Inhaltsverzeichnis[Verbergen]

Zweck des Vorgehensmodells

Aus dem Phasenschema wird ein Vorgehensmodell, wenn die auszuführenden Tätigkeiten und die aus den Tätigkeiten entstehenden Resultate konkret be­schrieben werden (vgl. Lerneinheit PROMA). In das Vorgehens­modell werden Methoden und Techniken und die sie unterstützenden Werk­zeuge „eingehängt“. Das Vorgehens­modell ist also so­wohl Produk­tions­systematik (Tätigkeiten, Er­geb­nisse, Tätig­keits­folge, Ter­mine, Kosten usw.) als auch Kon­struk­tions­syste­ma­tik (Metho­den, Tech­niken, Werkzeuge). Das Vor­gehens­mo­dell ist universell, wenn es nur eine Grob­struktur der Tätigkeiten, Resultate, Methoden usw. und da­mit des Vor­gehens angibt und dem Anwender die Verfeinerung, die situativ ge­wählt wird (z.B. in Ab­hängig­keit von dessen Qualifikation), überlässt. Anwender, die über ein Vor­ge­hens­mo­dell verfügen, das dem Stand der Tech­nik entspricht und dieses nach­weis­bar auch verwen­den, erfüllen eine wesentliche Vor­aus­setzung der ISO 9000-3 zur Zertifizierung nach ISO 9000 (vgl. Lerneinheit NORMQ). Wegen der Bedeutung der Audits im Vorgehensmodell wird auf Lerneinheit REVAU hin­ge­wiesen.

Ob das im Folgenden gezeigte Vorgehensmodell diesen Ansprüchen gerecht wird, kann nach dem Durcharbeiten dieser Lerneinheit beantwortet werden. Was offen geblieben ist und warum dies so ist, wird bei der Interpretation in den Lehr­ver­anstaltungen diskutiert. Der Autor dankt der Porsche Bank AG Salzburg für die Erlaubnis, das in ihrem Hause entwickelte Vorgehensmodell im Lehr­betrieb ver­wenden zu dürfen. Geringe formale Änderungen wurden vom Autor vorgenom­men. Bei der im Folgenden genannten Porsche Informatik handelt es sich um ein kon­zern­eigenes Systemhaus, mit dem längerfristige Arbeitsvereinbarungen über die Ausla­gerung der Abwicklung von IS-Projekten bestehen.

 

Präambel

Dieses Vorgehensmodell ist ein verbindliches Rahmenmodell für alle IS-Pro­jek­te der Porsche Bank AG. Es regelt die Phasen, die Pro­jekte in der vorgegebenen Rei­henfolge durchlaufen müssen, gibt die wich­tigsten Tätigkeiten innerhalb der Pha­sen an und definiert die Verant­wort­lichen für Durch­führung und Validierung. Es definiert das Mini­mum an Audits, die während der Projektlaufzeit durch­zuführen sind, mit denen sichergestellt wird, dass bei jedem IS-Projekt die Regeln des Vor­gehensmodells beachtet bzw. in Ausnahmefällen begründet nicht beachtet wurden. Wer­den einzelne Pha­sen des Vorgehensmodells bei einem Projekt nicht durch­geführt, ist in der Projektdokumentation eine Begründung dafür anzugeben.

 

Rollen

Die Inhaber folgender Rollen haben im Rahmen des Vorgehensmodells Aufgaben zu übernehmen und Verantwortung wahrzunehmen:

  • Lenkungsausschuss (LA)
  • Projektsteuerungsgremium (SG)
  • Projektleiter (PL)
  • Projektproponenten (PP)
  • Nutzervertreter (NV)
  • Auditor (AU)

Syntax-Darstellung

  • Tätigkeit (Verantwortlicher)
  • Ergebnis; optional wenn in ()
  • (Archiv: Verweis auf Ablage eines Dokuments)

Projektphasen

1 Ideenfindung

Für die Ideenfindung gibt es kein Regelwerk. Wenn jedoch aus einer Projektidee ein Projekt werden soll, müssen folgende Tätigkeiten durchgeführt werden.

  • Projektproponenten aus dem Kreis der Führungskräfte identifizieren (Ideen­liefe­rant)
    • Name Projektproponent (PP)
  • Idee dokumentieren (PP)
    • informelles Dokument
  • Ziele, die mit der Realisierung der Projektidee erreicht werden sollen, so präzis wie möglich bestimmen und dokumentieren (PP)
    • Protokoll Ziele, Kosten-/Nutzenanalyse
  • alle betroffenen Struktureinheiten (Abteilungen und Prozesse) identifizieren und Linienmanagement informieren (PP)
    • Liste Struktureinheiten / Information
  • über die Aufnahme der Projektidee in das Projektportfolio entscheiden (LA)
    • Protokoll / Ergänzung des Projektportfolios

       

2 Initialisierung

Die Initialisierung eines Projekts kann nur durch den LA erfolgen.

  • Planungsziele für das Projekt vorgeben (LA)
    • Planungsziele im Projektauftrag
  • Nutzenpotential validieren (LA)
    • Validiertes Nutzenpotential im Projektportfolio
  • Zeit-/Kostenbudget für Vorstudie vorgeben (LA)
    • Vermerk im Projektauftrag
  • Produktlebenszyklus festlegen (LA)
    • Vermerk im Projektauftrag
  • Projektsteuerungsgremium nominieren (LA)
    • Vermerk im Projektportfolio und im Projektauftrag
  • Projektorganisation festlegen (LA)
    • Vermerk im Projektportfolio und im Projektauftrag
  • Projektleitung bestellen (LA)
    • Vermerk im Projektportfolio und im Projektauftrag
  • Betroffene im Haus und bei Porsche Informatik informieren (LA)
    • informelles Dokument
  • Projekt initialisieren und Projektauftrag zur Vorstudie formulieren (LA)
    • Initialisierungsvermerk im Projektportfolio
  • Audit durchführen (AU)
    • Auditprotokoll
  • Projektauftrag zur Vorstudie erteilen (LA)
    • Projektauftrag zur Vorstudie

3 Vorstudie

  • grobe Istzustandsuntersuchung durchführen (PL)
    • Dokument Istzustandsbeschreibung
  • Sachziele aus Planungszielen ableiten und festlegen; Nicht-Ziele explizit nennen (PL)
    • Kernfunktionen
    • Leistungskriterien
    • Schnittstellen im neuen System und zum Umsystem
  • Formalziele aus Planungszielen ableiten und festlegen (SG)
    • Flexibilitätsziele
    • Portabilitätsziele
    • Sicherheitsziele
    • Kostenziele, Betriebsziele, Wartbarkeitsziele, Wiederverwendbarkeit
    • weitere Formalziele in Abhängigkeit vom Projektgegenstand (insbesondere Umfang und Komplexität)
  • Vollständigkeit & Widerspruchsfreiheit des Zielsystems überprüfen (PL)
    • Prüfungsvermerk
  • Grundkonzeption entwerfen (PL)
    • alternative Konzepte
  • Alternativen evaluieren & Empfehlung erstellen (PL)
    • Evaluierungsverfahren
    • Begründung der Empfehlung
  • Optimale Alternative auswählen und entscheiden (LA)
    • gewählte Alternative
  • Umfang Projektauftrag entscheiden (inkl./exkl. Realisierungsphasen) (LA)
    • Vermerk und Projektauftrag für Phasen 4 und 5 (oder für alle Folgephasen) formulieren
    • Projektauftrag
  • Audit durchführen (AU)
    • Auditprotokoll
  • Projektauftrag erteilen (LA)

4 Feinstudie

  • Istzustandsanalyse durchführen (PL)
    • Stärken/Schwächen-Katalog
  • Grundkonzeption anpassen (PL)
    • Fachkonzept
    • (Prototyp)
  • Fachkonzept abnehmen (NV)
    • Abnahmevermerk
  • Abnahmebedingungen für Endprodukt festlegen (PL/NV)
    • Abnahmevereinbarung
  • Projektplan fortschreiben (PL)
    • aktualisierter Projektplan
  • Einsatzplan erstellen (PL)
    • Zeitplan
    • Ablaufplan
    • Checkpoints bei Datenübernahmen / -initialisierungen
    • Alternativen für Problemsituationen
    • Gesamtabläufe
  • Audit durchführen (AU)
    • Auditprotokoll

5 Systementwurf

  • System in Teilprojekte gliedern (PL)
    • Systemgliederung
  • Datenmodell entwerfen (PL)
    • Datenmodell (Prototyp)
  • Methodensystem konzipieren (PL)
    • Methodensystem (Prototyp)
  • Interaktionsmodell konzipieren (PL)
    • Interaktionsmodell (Prototyp)
  • Sicherungssystem entwerfen (PL)
    • Systemsicherheitskonzept
    • Berechtigungskonzept
  • Teilprojekte integrieren (PL)
    • Integrationskonzept
    • Systemdokumente vervollständigen (wenn erforderlich mit Eignung für Aus­schreibung) (PL)
    • vollständige Entwurfsdokumentation
    • (Kriterienkatalog für Ausschreibung)
  • Schulungskonzept und Testkonzept entwerfen (PL)
    • Schulungskonzept
    • Testkonzept
  • Entscheidung über Ausschreibung fällen (LA)
    • Protokoll
  • Ausschreibung lt.. Prozedur VMOD_AU.SAM durchführen (PL)
    • Ausschreibungsunterlagen
  • Realisierungsauftrag formulieren (PL)
    • Realisierungsauftrag
  • Audit durchführen (AU)
    • Auditprotokoll
  • Realisierungsauftrag erteilen (LA)
    • Vermerk Auftragserteilung

6 Implementierung

6.1 Erstellung Individual-Software

  • Prototyp erstellen (PL)
    • Prototyp
  • Prototyp abnehmen (NV)
    • Abnahmevermerk
  • Programm erstellen (Porsche Informatik)
    • Programm
    • Anwender-, System- und Projektdokumentation
  • Testfälle lt. Prozedur VMOD_TP.SAM definieren und durchführen (PL)
    • Testprotokoll

6.2 Zukauf Standard-Software

  • Adressaten für Ausschreibung identifizieren (PL)
    • Adressliste
  • Ausschreibungszeitplan festlegen (PL)
    • Zeitplan
  • k.o.-Kriterien festlegen (LA)
    • Kriterienkatalog
  • Ausschreibung lt. Prozedur VMOD_AU.SAM durchführen (PL)
    • Angebote
  • Angebote evaluieren und Empfehlung erarbeiten (PL)
    • Evaluierungsergebnisse
    • Begründung der Empfehlung
  • Audit durchführen (AU)
    • Auditprotokoll
  • Auswahl und Entscheidung (LA)
    • Protokoll

7 Installation und Projektabschluss

  • Installations- und Abnahmevoraussetzungen schaffen (PL)
    • Installationsplan
    • Abnahmeplan
    • Serviceebenen-Vereinbarung
  • Installation durchführen (PL)
    • Installationsvermerk
  • Abnahmetest durchführen (PL)
    • Abnahmevermerk
  • Übergabezeitraum definieren (PL)
    • Protokoll
  • System produktiv setzen (PL)
    • Vermerk im Projektportfolio
  • Ex-post-Evaluierung (LA)
    • zusammenfassende Projektdokumentation
    • Kostendarstellung
    • Darstellung der Zielerreichung
  • Audit durchführen (AU)
    • Auditprotokoll
  • Entlastung PL (LA)

Quellenliteratur

Bröhl, A. P. / Dröschel, W. (Hrsg.): Das V-Modell. Der Standard für die Softwareentwicklung mit Praxisleitfaden. 2. A., Oldenbourg, München/Wien 1995

Heinrich, L. J.: Systemplanung 2 Bd. 7. A. (Bd. 1) bzw. 5. A. (Bd. 2), Oldenbourg, Mün­chen/Wien 1996 bzw. 1994

Wiemers, M.: Ein Vorgehen für das Einführen eines Vorgehensmodells. In: Kneuper, R. et al. (Hrsg.): Vorgehensmodelle für die betriebliche Anwendungsentwicklung. Teubner, Stuttgart/ Leipzig 1998, 249 - 263

Fallstudie: QMHB - Qualitätsmanagement-Handbuch

Zweck des Qualitätsmanagement-Handbuchs

Das Qualitätsmanagement­-Hand­buch (QMHB) ist ein Dokument mit Weisungs­cha­rak­ter, das die Qualitätspolitik, das Qualitätsmanagementsystem (QM-System) und alle für Qualität be­deutsamen Vorge­hensweisen im Un­ter­nehmen festhält. Das QMHB ist Grund­lage für die ständige Weiterentwicklung des QM-Sy­stems sowie für seine unter­neh­mens­interne und externe Beurteilung (z.B. die Beur­teilung der Qualitäts­fähigkeit des Unternehmens durch poten­tielle Kunden). Das QMHB ist Teil der for­mellen Anerkennung des QM-Systems (Zer­tifizierung, vgl. Lern­ein­heit NORMQ) und dient in allen Fragen des Qualitäts­mana­gements als Bezugs­do­ku­ment. ISO 9001 Element 5.6.5 Quality Manual fordert den Nachweis eines QMHB mit folgendem Inhalt und dem Hinweis, dass dieses nicht notwendigerweise ein separates Doku­ment sein muss:

  • a description of the elements of the quality management system and their inter­action;
  • the systems level procedures or references thereto.

Die Grobgliederung des QMHB ist wie folgt:

  • Teil 1 enthält verschiedene Hinweise zur Organisation, Herausgabe und Pflege des QMHB.
  • Teil 2 enthält die Beschreibung der Elemente des QM-Systems (in der Regel QM-Elemente gem. ISO 9001:2000).
  • Teil 3 enthält Anhänge (z.B. ein Glossar der verwendeten Abkürzungen und Be­griffe) und Verweise auf andere Unterlagen, die im Zusammenhang mit dem QMHB von Bedeutung sind.

Im Sinn der hierarchischen Dokumentation ist das QMHB das Dokument der ersten Ebene. Da es auch der Kommunikation nach au­ßen (insbesondere gegenüber Kunden) dient und damit Dritten (z.B. Mitbe­wer­bern) prinzipiell zugänglich ist, enthält es keine Einzelheiten über die Verfahren (und damit über die angewende­ten QM-Maßnahmen), mit denen die Herstellung der Produkte und Dienstleistun­gen geregelt ist, sondern lediglich einen Überblick über die QM-Verfahrensanweisungen (QMVA).

Eine QMVA ist eine dokumentierte Anwei­sung oder Anleitung, die grundsätz­liche Vorgehens­weisen, Prozesse, Abläufe oder einzelne Tätigkeiten zum Inhalt hat und Auskunft darüber gibt, wer was zu machen hat und wie dies erfolgen soll. Die Detailliertheit der Beschrei­bung ist abhängig von der Bedeu­tung, welche die Anweisung oder Anleitung in bezug auf mögliche Fehlerquellen hat. Im Sinn der Dokumentation des QM-Systems ist die QMVA ein Dokument der zweiten Ebene. Dokumente der dritten Ebene sind Arbeits-, Prüf- und Dienstanwei­sungen.

Beispielunternehmen RACON/GRZ

Im folgenden wird der Inhalt des QMHB - im Sprachgebrauch der genannten Unternehmen als Unternehmenshandbuch bezeichnet - der RACON SOFTWARE Ges.m.b.H., Linz, und des Genos­senschafts-Rechen­zentrum (GRZ) Linz Ges.m.b.H. zunächst im Überblick und dann am Beispiel der Darstellung von drei Unter­neh­mensprozessen gezeigt (Stand Jänner 2001). Dies erfolgt mit freundlicher Geneh­migung der Geschäftsführung der beiden Unternehmen (im folgenden mit RACON /GRZ bezeichnet) mit Hinweis auf die ausschließliche Verwendung für Lehrz­wecke.

Die Entwicklung des QM-Systems der RACON/GRZ - im Sprachgebrauch der genannten Unternehmen als Managementsystem bezeichnet - begann im Oktober 1993, die Einführung und Zertifizierung erfolgte im Juni 1995 (erste Re-Zertifi­zierung Oktober 1998, nächste Re-Zertifizierung September 2001). Zertifizierer ist die ÖQS (vgl. Lern­einheit QUAMA). Im Mai 2000 erfolgte die Umstellung auf ein prozessorientiertes Managementsystem mit dem Ziel der Verankerung des Pro­zessdenkens auf allen Unter­nehmensebenen und der transparenten Dar­stellung der Geschäftsprozesse, im Sprachgebrauch der genannten Unternehmen als Unter­neh­mensprozesse bezeichnet. Damit im Zusammenhang sollte die Doku­mentation in Papierform drastisch - „von mehreren Ordnern auf einen Schnellhefter“ - redu­ziert werden (z.B. durch Vermeidung von Redundanz bei der Darstellung der QMVA für unterschiedliche Prozesse und durch Verlagern der Dokumentations­ebenen zwei und drei auf Datenbanken).

Die Institutionalisierung des QM ist wie folgt geregelt: Qualitätsbeauftragter (QB) ist ein Mitglied der Geschäftsführung. Eine mit zwei Personen besetzte QM-Stelle, die an den QB berichtet, koordiniert alle Maßnahmen zur Projekt- und Pro­zess­qualität (PPQ). Die für Projekt- und Prozessqualität zuständigen Instanzen sind die Prozessverantwortlichen (Prozesseigner). Elf Mitarbeiter der beiden Unter­neh­men sind als interne Auditoren tätig. In allen Organisationseinheiten wird min­destens einmal in drei Jahren ein internes Audit durchgeführt. Audit-Aufträge erteilt der QB auf Vorschlag der PPQ. Zweimal jährlich werden Management-Re­views durchgeführt. Vierteljährliche Auditorenver­samm­lungen dienen dem Erfah­rungsaustausch zwi­schen den internen Auditoren; eine jährliche Auditoren­klausur dient insbesondere zur Weiterentwicklung des Managementsystems, aber auch der Weiter­bildung.

Managementsystem RACON/GRZ

Das Managementsystem besteht aus den drei „Säulen“ Unterneh­menspolitik (mit Aussagen zur Unternehmenskultur, Kundenpolitik, Leit­linien zur Qualität usw.), Unternehmensziele (mit Teilzielen für Abteilungen, Teams und Prozesse) und Unternehmensprozesse zur Erreichung der genannten Ziele und damit zur Erfül­lung der Kundenforderungen. Unternehmensprozesse sind wie folgt gruppiert:

  • Managementprozesse schaffen die Rahmenbedingungen für das Management­system. Vier Managementprozesse wurden identifiziert:
    1. Unternehmens­darstel­lung
    2. Managementsystem
    3. Strategie & Planung
    4. Unternehmensver­bes­se­rung
  • Kundenprozesse dienen der Realisierung der vom Kunden geforderten Pro­dukte und Dienstleistungen. Sieben Kundenprozesse wurden identifiziert:
  1. Hardware- und Software-Installation
  2. Hotline/Service
  3. Netzwerkdienste
  4. Rechenzentrumsbetrieb
  5. Schulung
  6. Software-Analyse und -Entwicklung
  7. Systemsoftware
  • Unterstützungsprozesse sind nach Innen orientiert und bilden eine wichtige Basis oder eine Unterstützung für die Management- und Kundenprozesse. Elf Unterstützungsprozesse wurden identi­fi­ziert (z.B. Beschaffung, Nachkalkulation /Controlling, Software Engineering).

Abbildung QMHB-1 zeigt die Vernetzung der drei Arten von Unternehmens­pro­zessen zum Managementsystem analog zur Darstellung der Prozessorientierung in ISO 9001:2000 (vgl. Lerneinheit NORMQ); Beschaffung wird beispielhaft für Unterstützungsprozesse genannt.

alt
Abbildung QMHB-1: Visualisierung des Managementsystems (Quelle: RACON/GRZ)

 

Unternehmenshandbuch RACON/GRZ

Die Dokumentation des Managementsystems RACON/GRZ im Unternehmens­handbuch ist unabhängig von der in der ISO 9001:2000 verwendeten Struktur; im Vordergrund stehen nicht „Elemente“, sondern die Unternehmensprozesse. Diese sind aufgaben- und abteilungsübergreifend organisiert. Folgende Gliederung wird verwendet:

  • Unternehmenspolitik
  • Unternehmensbeschreibung
  • Unternehmensziele
  • Unternehmensprozesse (Untergliederung wie oben angegeben)

Die Dokumentation des Managementsystems ist auf diversen Lotus Notes-Daten­baken und auszugsweise auch auf den Webseiten abgelegt. Auch wird auch das interne Auditing verwaltet (vom Audit-Auftrag bis zum Audit-Bericht einschließ­lich der Maßnahmen für Qualitätsverbesserungen). Bei der Bearbeitung der Maß­nahmen im Sinn einer kontinuierlichen Verbesserung der Unternehmensprozesse werden alle Anregungen koordiniert, unabhängig davon, ob sie aus internen oder externen Audits, von den Prozessverantwortlichen oder von einzelnen Mitarbeitern stam­men. Neben diesen QM-spezifischen Daten­banken gibt es eine Reihe weiterer (z.B. Projektdatenbanken) für verschiedene Nutzungszwecke im Rahmen des Management­systems (z.B. zur Wissensspeicherung und als Ideenbörse). Die Ein­schulung neuer Mitarbeiter in das Managementsystem wird durch ein Web-basiertes Training (WBT), einem multimedialen Lernprogramm mit dem Namen „Q4U“ unterstützt.

Managementprozess „Unternehmensverbesserung“

Dieser Prozess ist wie folgt in Teilprozesse gegliedert (nach der Aufzählung wird die Dokumentation von Teilprozess G - Qualitätsaufzeichnungen wiedergegeben):

A - Kontinuierliche Verbesserung

B - Managment Review

C - Interne und externe Audits

D - Korrektur- und Vorbeugungsmaßnahmen

E - Lenkung von Fehlern

F - Lenkung der Dokumente

G - Qualitätsaufzeichnungen

H - Qualitätsplanung

Prozess

 

Art: Managementprozesse\4. Unternehmensverbesserung
Titel: G - Qualitätsaufzeichnungen
Gültig ab: 31.10.2000
Dokument-ID: MMP4 0-Aufz
Version: 1.1
Verantwortlich: Hans MEIER

 

Beschreibung

Die Qualitätsaufzeichnungen dienen zum Nachweis qualitätsrelevanter Tatsachen bzw. Zustände, die in GRZ/RACON auftreten. Mittels der erstellten Aufzeich­nungen werden auch die von den Kunden geforderten Nachweise über die Eigen­schaften eines Produktes erbracht. Aufzeichnungen beschreiben einen Istzustand zu einem bestimmten Zeitpunkt. Sie werden auch als Nachweisdokumente be­zeichnet. Sie dürfen nach Erstellung nicht mehr geändert werden. Beispiele sind: Berichte (Audit-, Installations-, Service-, Kundenbesuchs-, Testbericht), Fehlerbe­schrei­bungen, Protokolle, Lieferscheine.

Neben Vorgabe- und Nachweisdokumenten gibt es noch Hilfsaufzeichnungen, Checklisten etc. Diese können evtl. zu einem Nachweisdokument werden (z.B. eine ausgefüllte Checkliste als Nachweis für eine erbrachte Tätigkeit).

Lebenszyklus der Qualitätsaufzeichnungen

1. Erstellung

Ein Dokument wird von den dafür zuständigen Personen erstellt. Ersichtlich müs­sen sein:

  • Dokumenten-Identifikation mit Versionskennung: sollte eine Versionsnummer oder eine andere eindeutige Versionskennung sein. Die aktuelle Version muss leicht und eindeutig identifizierbar sein.
  • Zuordnung zu Produkt oder Projekt oder Thema
  • Ersteller und Erstellungsdatum

2. Änderung

Nachweisdokumente dürfen nach der erfolgten Erstellung nicht mehr geändert wer­den. Sie beschreiben einen Istzustand zu einem bestimmten Zeitpunkt.

3. Verteilung

Die Verteilung hat durch den Ersteller oder die zuständige Organisationseinheit zu

erfolgen. Alle vom Dokument Betroffenen oder im Verteiler Genannten müssen von der Ausgabe des Dokuments wirksam verständigt werden.

4. Aufbewahrung

Die Aufbewahrung hat so zu erfolgen, dass die Dokumente leicht wiederauffindbar sind und sicher vor Beschädigung und Veränderungen bewahrt werden. Die Auf­bewahrung kann auch elektronisch erfolgen. Vertrauliche Nachweisdokumente sind so aufzubewahren, dass die Vertraulichkeit gewährleistet bleibt. Als Aufbe­wahrungsdauer für qualitätsrelevante Dokumente gelten 7 Jahre nach Projekt­abschluss, falls nicht eine andere Festlegung erfolgt.

5. Beseitigung

Nach Ablauf der Aufbewahrungsfristen können die Nachweisdokumente - wenn sie nicht mehr benötigt werden - entsorgt werden. Dies hat in angemessener Form zu erfolgen.

Kundenprozess „Software-Analyse und -Entwicklung“

Prozess

 

Art: Kundenprozesse
Titel: Software-Analyse und -Entwicklung
Gültig ab: 28.11.2000
Dokument-ID: KP_SWAE
Version: 1.2
Verantwortlich: Peter MÜLLER

 

Prozessbeschreibung

1. Prüfung der Kundenanfrage

Kundenanfragen werden vom zuständigen Produktverantwortlichen (PV) oder einer von Geschäftsführung bzw. Abteilungsleiter beauftragten Person auf die gene­relle Realisierbarkeit geprüft. Dabei wird beurteilt und festgelegt, ob es sich um eine kostenpflichtige Änderung, laufende Wartung oder einen Neuauftrag han­delt. Falls notwendig, werden für die Beurteilung vom Kunden Detailan­forde­rungen erhoben. Das Ergebnis wird dem Kunden als formlose Stellungnahme retourniert. Im Fall laufender Wartung wird die Anfrage für künftige Releases evi­dent gehalten.

2. Machbarkeitsprüfung

Wünscht der Kunde eine Machbarkeitsprüfung oder Realisierung bzw. entscheidet der PV für eine solche Prüfung, wird die Machbarkeit im Detail geprüft. Dabei prüft der PV (oder ein dafür bestimmter Projektleiter) in Abstimmung mit allen notwendigen Experten (z.B. Organisatoren, SW-Entwicklung, System-SW-Ent­wick­lung, Software-Engineering, Netzwerkdienste, RZ-Betrieb, Sicherheit im LAN) die technischen Voraussetzungen, die Machbarkeit und die Kosten für die Realisierung, sowie mögliche Realisierungstermine unter Berücksichtigung ver­fügbarer Ressourcen.

Falls notwendig, werden vom Kunden Details zu den Anforderungen eingeholt. Gesetzliche Anforderungen sind zu berücksichtigen. Die Ergebnisse dieser Prü­fung gehen an den Kunden zur Entscheidung.

3. Vertragsprüfung

Der erteilte Auftrag wird formal vom PV geprüft. Falls der Kunde Änderungen fordert und diese Einfluss auf Kosten haben, wird ein neues Angebot erstellt.

4. Projektplanung

Spätestens jetzt wird ein Projektleiter (PL) und bei neuen Produkten der künftige Pro­duktverantwortliche nominiert. Der PL entscheidet, ob ein Arbeitsauftrag oder ein Projektplan erstellt wird. Es werden die in der NOTES-Projektdatenbank (oder ver­gleichbaren Systemen) vorhandenen Formularvorlagen verwendet.

Falls Auswirkungen auf Netzwerk- oder HW-Ressourcen oder Systemsoftware zu erwarten oder Kundenschulungen vereinbart sind, werden auch die dafür zustän­digen Stellen in die Planung einbezogen. Sicherheitsrelevante Auswirkungen wer­den in der Sicherheitsinformationsdatenbank dokumentiert. Bei Erstel­lung von Folgereleases werden die evidenten Fehler und Vorbeugungsmaß­nahmen in der Projektplanung mit berücksichtigt.

5. Analyse/Design

Die dokumentierten Forderungen des Kunden werden vom Projektteam analysiert. Es wird das Datenbankdesign, das SW-Design, die Bedieneroberfläche, die Auftei­lung in Funktionen und Module, deren Funktionsweise sowie die Schnittstellen zu anderen Systemen festgelegt. Dazu werden detaillierte Informationen vom Kunden eingeholt.

6. Review der Designergebnisse

Die Ergebnisse von Analyse/Design werden von all jenen Stellen geprüft, die an der Entwicklung beteiligt sind. Geprüft wird, ob die Kundenforderungen erfüllt werden und das Design der gültigen internen Richtlinien für Analyse/Design und SW-Entwicklung entspricht. Die Ergebnisse der Überprüfung werden dokumen­tiert.

7. SW-Entwicklung

Auf der Grundlage des geprüften Designs erfolgt die Umsetzung durch die SW-Entwickler des Projektteams. Berücksichtigt werden dabei die gültigen Richtlinien für SW-Entwicklung. Dann sind auch die notwendigen Vorkehrungen für die Kennzeichnung und Rückverfolgbarkeit der SW-Produkte und für die Siche­rung/Archivierung der Entwicklungsergebnisse festgelegt.

Die Bereitstellung der Infrastruktur für die SW-Entwicklung erfolgt im Rahmen des Supportprozesses „Software-Engineering“. Für die SW-Entwicklung benötigte externe Ressourcen (z.B. Hardware, Software, Leasingpersonal) werden über den Supportprozess „Beschaffung“ bereitgestellt.

Vom Kunden beigestellte Produkte bzw. über den Supportprozess „Beschaffung“ bereitgestellte Produkte (die in der zu entwickelnden Software Eingang finden) werden vom Projektleiter auf ihre Eignung geprüft.

8. Dokumentation

Möglichst parallel zur SW-Entwicklung wird auch die Dokumentation erstellt. Die

programminterne Dokumentation ist entsprechend der gültigen Richtlinien für SW-Entwicklung zu führen. Falls im Projektplan/Arbeitsauftrag vereinbart, wer­den ONLINE-Bedienerhilfe, Produktbeschreibung und/oder Handbuch erstellt. Jedenfalls wird eine Installationsanleitung erstellt. Die erforderlichen Informa­tionen werden den zuständigen Mitarbeitern für „HOTLINE/Service“ und bei ver­einbarten Kundenschulungen auch den dafür zuständigen Mitarbeitern weiter­gegeben.

9. Tests

Die im Projektplan/Arbeitsauftrag definierte Stelle überprüft, ob die Software den Kundenforderungen sowie allgemeinen Anforderungen (Performance, Bedien­bar­keit, Stabilität u.a.) entspricht. Die Ergebnisse der Tests werden in einem Test­be­richt dokumentiert. Erkannte Mängel werden im Teilprozess SW-Entwicklung be­hoben. Die Tests sollen einerseits auf den Erfahrungen früherer ähnlicher Pro­jekte bzw. früherer Releases basieren und andererseits den Funktionsumfang des Pro­jekts (z.B. lt. ORG-Vorschlag) berücksichtigen.

10. Freigabe

Nach erfolgreichen Tests erfolgt die Abnahme durch den Kunden (oder dessen fachlichen Vertreter) und das Produkt wird durch den Projektleiter freigegeben. Die Freigabe wird formlos dokumentiert, alle Projektbeteiligten werden informiert. Eine Freigabe trotz Fehlern oder Mängeln ist mit dem Kunden abzustimmen und als Sonderfreigabe zu dokumentieren. Solche Fehler oder Mängel sind jedenfalls für die laufende Wartung evident zu halten.

11. Projekt-Review

Abhängig von der Größe und Komplexität des Projekts wird ggf. ein Projekt-Review durchgeführt. In diesem Review betrachtet das Projektteam den Projekt­verlauf kritisch und überlegt Verbesserungsmaßnahmen für das Produkt und auch die Prozesse. Maßgebliche Inputs sind: Nachkalkulation der Aufwände (vor allem Arbeitsaufwand), Testberichte, Vergleich Plan-/Isttermine und vor allem Erfah­rungen des Projektteams.

 

12. Produktwartung

Anforderungen für die Produktwartung kommen entweder durch Kundenanfragen, durch Informationen aus HOTLINE/Service, aus aufgetretenen Fehlern oder durch Projekt-Reviews. Der PV sammelt diese Anforderungen und entscheidet, welche Korrekturen oder Verbesserungen als eigene Projekte abgewickelt werden und welche im Zuge von neuen Releases mitgeplant werden. Jedenfalls werden die Kor­rekturen und Verbesserungen gesammelt und evident gehalten. Wartungs­aufträge bzw. Wartungsprojekte werden mittels Arbeitsaufträgen abgewickelt.

Weiters gilt

  • Ziele des Kundenprozesses „Software-Analyse und -Entwicklung“ in der aktu­ellen Fassung
  • Messgrößen für den Kundenprozess „Software-Analyse und Entwicklung“ in der aktuellen Fassung
  • SWE-Richtlinien, die für den Prozess bzw. für die betroffenen Bereiche gültig sind
  • Gesetzliche Anforderungen, soweit für den Prozess oder das Projekt zutreffend

Unterstützungsprozess „Beschaffung“

Prozess

Art: Supportprozesse
Titel: Beschaffung
Gültig ab: 15.05.2000
Dokument-ID: SP_Beschaffung
Version: 1.0
Verantwortlich: Susanne LEHNER

 

Prozessbeschreibung

1. Ermittlung und Genehmigung der Anforderung

nur wenn anfordernde Stelle = INTERN

Die interne Anforderung wird von der anfordernden Stelle ermittelt und doku­mentiert (z.B. die zu beschaffende Software / benötigte Hardware für einen Kun­den, Anforderungen an Leasingpersonal, Anforderungen an zugekaufte Software, ...) und in Form eines Beschaffungsdokumentes an die beschaffende Stelle (z.B. Einkauf) weitergeleitet. Die Anforderung muss bereits von der zuständigen Stelle (GF, Abteilungsleiter, Fachbereichsleiter,...) bewilligt sein.

2. Prüfung der Beschaffungsdokumente

Die Beschaffungsdokumente (von anfordernden internen Stellen oder von externen Kunden) werden von der beschaffenden Stelle formell (auf Vollständigkeit und Angemessenheit) geprüft, ob das zu beschaffende Produkt oder die Dienstleistung ausreichend und klar beschrieben ist (z.B. ist Release bei Software angegeben, ist die Hardwarebestellung vollständig, wurden die Anforderung an Leasingpersonal angeführt). Für den Inhalt der Beschaffungsdokumente ist die anfordernde Stelle verantwortlich (z.B. Anzahl von PC, fachliche Anforderungen an Leasingpersonal, welches Release bei Software,...).

3. Beschaffung von Produkten / Dienstleistungen

Die beschaffende Stelle wählt den Lieferanten aus (z.B. aus Lieferantenkartei, durch Einholen von Angeboten oder ggf. auf Wunsch der anfordernden Stelle) und führt die Bestellung durch. Die Lieferanten werden nach folgenden Kriterien aus­gewählt: Lieferzeit, Preis, bisherige Erfahrungen, bestehende Verträge, .... Darüber hinaus werden neue Lieferanten in die Lieferantenkartei aufgenommen.

4. Verfolgung offener Bestellungen

Der Status der Bestellungen wird von der beschaffenden Stelle verfolgt. Sie urgiert beim Lieferanten wegen nicht termingerechter Lieferungen von Pro­dukten/Dienst­leistungen.

5. Wareneingang / Bereitstellung der Dienstleistung

Die anfordernde Stelle nimmt das bestellte Produkt/die bereitgestellte Dienst­leistung entgegen und prüft diese auf Vollständigkeit, Qualität (z.B. Liefer­schein­kontrolle, Prüfung der erbrachten Leistung vom Leasingpersonal,...) und informiert die beschaffende Stelle über die erfolgte Lieferung bzw. erbrachte Leistung. Diese leitet den Verrechnungsvorgang ein.

6. Bewertung des Lieferanten

Auf Basis der erbrachten Leistung werden die Lieferanten (z.B. Leasing­unter­nehmen) bewertet/beurteilt.

 

Normen

ÖNORM EN ISO 9000: Qualitätsmanagementsysteme - Grundlagen und Begriffe / Quality management systems - Fundamentals and vocabulary (ISO 9000:2000)

ÖNORM ISO 9000-3: Qualitätsmanagement und Qualitäts­siche­rungs­normen; Leitfaden für die Anwendung von ISO 9001 auf die Entwicklung, Lieferung und Wartung von Software

ÖNORM EN ISO 9001: Qualitätsmanagement-Systeme - Anforderungen / Quality management systems - Requirements (ISO 9001:2000)

ÖNORM EN ISO 9004: Qualitätsmanagementsysteme - Leitfaden zur Leistungs­ver­bes­se­rung / Quality management systems - Guidance for performance improvements (ISO 9004:2000)

Fallstudie: PROHB - Projekthandbuch

Zweck des Projekthandbuchs

Ein Projekthandbuch (kurz PROHB oder PHB) soll die Projektarbeit erleichtern, indem alle für ein Projekt wesentlichen Aufgaben und die zur ihrer Durchführung verwendeten Methoden und Werkzeuge sowie einzuhaltende Standards dokumentiert sind. Ein PHB ist einerseits ein allgemeines Dokument, andererseits ein spezielles Dokument. Allgemeines Dokument ist ein PHB im Sinn von Regeln oder im Sinn einer Richtlinie (oder eines Konzepts oder Vorbilds) für das Erstellen eines speziellen Dokuments (oder eines Modells oder Abbilds). Mit anderen Worten gesagt gibt es ein - zweckmäßigerweise elektronisch verfügbares - Standard-Dokument, nach dessen Regeln jedes Projekt abgewickelt und dokumentiert wird. In Abhängigkeit von Art und Umfang der Projektaufgabe werden die Regeln angepasst, insbesondere bezüglich Feinheit der Gliederung und Tiefe der Darstellung je Gliederungspunkt.

Das PHB soll die Projektabwicklung transparent machen, und zwar sowohl im Sinn von Vorschau, als auch im Sinn von Nachschau. Transparent im Sinn von Vorschau meint, dass das PHB die beabsichtigte Art und Weise der Projektabwicklung offen legt. Transparent im Sinn von Nachschau meint, dass das PHB die tatsächliche Projektabwicklung so aktuell wie möglich widerspiegelt. Das PHB ermöglicht daher - was die Projektplanung betrifft - teilweise Vorwärtsdokumentation, und was die Projektabwicklung betrifft (weitgehend) Simultandokumentation ;(vgl. Lerneinheit DOKUM). Dies ist weniger für Projektleitung und Projektmitarbeiter von Bedeutung, als vielmehr für potentielle Auftraggeber, die das PHB als Nachweis über die Qualitätsfähigkeit des Auftragnehmers (vgl. Lerneinheit NORMQ) verwenden, als auch für Kunden, die das PHB als Informationsmittel über den Projektstatus verwenden (falls weitgehend simultan dokumentiert wird). Diese Forderung nach Transparenz der Projektplanung und Projektabwicklung ist umso bedeutsamer, je neuartiger die Projektaufgabe ist; bei sich wiederholenden Projektaufgaben kann Transparenz auch ohne PHB hergestellt werden.

Ein PHB „lebt“, da es sich mit der Veränderung der Kundenforderungen, der Projektaufgabe und der Arbeitssituation verändert. Seine Systematik muss laufend an Veränderungen angepasst werden, ohne jedoch Kontinuität und Vergleichbarkeit völlig außer acht zu lassen. Da das PHB nicht eine mögliche Projektabwicklung, sondern die gewollte Projektabwicklung vorgibt bzw. dokumentiert, können Veränderungen am PHB nur den Veränderungen der tatsächlichen Arbeitssituation folgen, nicht aber umgekehrt. Diese Bemerkungen verdeutlichen die Notwendigkeit einer kompetenten Instanz (z.B. ein für das Qualitätsmanagement Beauftragter) für das PHB als Vorbild, die auch für die Schulung der Projektleitung und der Projektmitarbeiter in der Handhabung des PHB als Abbild zuständig ist.

Von besonderer Bedeutung im Zusammenhang mit Qualitätsmanagement sind die Handbuchteile Konfigurationsmanagement und Claim-Management.

  • Konfigurationsmanagement ist die Aufgabe der Verwaltung der vollständigen fachlich-inhaltlichen Definition und Beschreibung eines Produkts, die in Dokumenten niedergelegt sind und die benötigt werden, um das Produkt zu fertigen sowie über seinen gesamten Lebenszyklus hinweg nutzen und warten zu können.
  • Claim-Management ist das Verfahren („die Art und Weise“), in der Ansprüche, Beanstandungen und Mängelrügen des Auftraggebers durch den Auftragnehmer behandelt werden.

Ein PHB definiert in einer für alle Beteiligten auf Auftragnehmer- und Auftraggeberseite nachvollziehbaren Form den Herstellungsprozess für Produkte und Dienstleistungen, mit dem die Qualitätspolitik des Auftragnehmers implementiert ist. Da die Formulierung der Qualitätspolitik Aufgabe des Top-Managements ist, muss das PHB vom Top-Management selbst oder im Auftrag durch Dritte geprüft werden und von ihm bestätigt sein. Das PHB kann mit dem Qualitätsmanagement-Handbuch (kurz QM-Handbuch, vgl. Lerneinheit QMHB) identisch sein. Dies ist der Fall, wenn sich das QM-System nur auf die Unternehmensteile bezieht, deren Aufgaben in Form von Projekten bearbeitet werden bzw. wenn dies für die Unternehmensaufgaben insgesamt zutrifft (z.B. in Software- und Systemhäusern). Diese Bemerkung weist darauf hin, dass Zweck und Inhalt verschiedener Managementbereiche (z.B. Projektmanagement, Qualitätsmanagement, Revision und Controlling) zu einem Managementsystem zusammenwachsen, dessen Regeln dann konsequenterweise auch in einem integrierten Managementhandbuch konsolidiert dokumentiert sind.

So wie das QM-Handbuch, kann das PHB in mehrere Ebenen gegliedert sein, womit den Anforderungen entsprochen wird, Informationsmittel nach außen (insbesondere gegenüber potentiellen Kunden) und nach innen (insbesondere als konstruktive QM-Maßnahme) zu sein. Im folgenden Beispiel werden drei Ebenen verwendet, und zwar:

  • Auf der ersten Ebene sind die Qualitätspolitik, die Verantwortlichkeiten sowie die Abläufe im QM-System einschließlich der QM-Maßnahmen beschrieben; das verwendete Begriffssystem ist erläutert.
  • Auf der zweiten Ebene sind die Verfahrensanweisungen beschrieben, die organisatorische, personelle und technische Details enthalten.
  • Auf der dritten Ebene befinden sich die im Allgemeinen als Arbeitsanweisungen bezeichneten Dokumente.

Auftraggebern und Dritten gegenüber wird mindestens die dritte Ebene, häufig auch schon die zweite Ebene als vertraulich behandelt; sie enthält bzw. sie enthalten das spezifische Know-how des Auftragnehmers im Detail, das ausdrücklich nicht weitergegeben werden soll. Moderne QM-Systeme führen nur noch die erste Ebene in Papierform; die Daten der Ebenen zwei und drei werden auf Datenbanken geführt, auf die die Berechtigten von jedem Arbeitsplatz aus zugreifen können (vgl. das in Lerneinheit QUMHB gezeigte Beispiel).

Gliederung Projekthandbuch

Im Folgenden wird die Systematik eines Projekthandbuchs für Projekte gezeigt, deren Gegenstand Software-Systeme zur Automatisierung von Produktionsanlagen der Verfahrensindustrie (z.B. Chemische Industrie) sind. Sie eignet sich für neuartige Projektaufgaben ebenso wie für Projektaufgaben gleicher oder ähnlicher Art.

  • Allgemeines mit folgenden Gliederungspunkten: Präambel, Projektübersicht, Basisdokumente, Projektpartner, Erstellung und Aktualisierung des PHB, Verteilung und Revision des PHB.
  • Zusammenarbeit mit dem Kunden mit folgenden Gliederungspunkten: Konsultationen und Abstimmungen, gemeinsame Reviews, Vertragsänderungen, Abnahme- und Leistungstests.
  • Organisation mit folgenden Gliederungspunkten: Ansprechpartner, Teammitglieder, Aufgaben der Teammitglieder.
  • Dokumentation mit folgenden Gliederungspunkten: Dokumentation der Standard-Hardware und Standard-Software, der Anwendersoftware, Handbücher (z.B. Bedienerhandbuch und Diagnosehandbuch), Zeichnungsnummernsystem, Motor- und Komponentenliste, Archivierung, Standardformate.
  • Beschaffung, Lieferung und Installation mit den bei „Dokumentation“ genannten Gliederungspunkten, gegebenenfalls untergliedert nach Komponenten (z.B. Rechnersysteme und elektrotechnische Ausrüstungen).
  • Lieferungen und Leistungen des Kunden mit folgenden Gliederungspunkten: Spezifikation, Systemschnittstellen, Überwachung der Herstellung und Abnahmeprozedur.
  • Projektmanagement mit folgenden Gliederungspunkten: Terminplan und Terminverfolgung (Meilensteine und Fortschrittskontrolle), Personaleinsatzplan, Behandlung offener Fragen, Projektende.
  • Konfigurationsmanagement mit folgenden Gliederungspunkten: Kennzeichnung von Dokumenten und Arbeitergebnissen, Übernahme von Elementen und Konfigurationen, Durchführung von Änderungen, Archivierung alter Versionen/Konfigurationen, Datensicherung.
  • Prüfungen mit folgenden Gliederungspunkten: Verantwortlichkeiten, Prüfungsobjekte (Ergebnisse und Tätigkeiten), Prüfungen (Prüfplan, Prüfgegenstände, Prüfspezifikation, Prüfprozedur und Prüfprotokoll).
  • Systementwicklung mit folgenden Gliederungspunkten: Pflichtenheft, Entwurf, Implementierung, Integration, Vergabe an Externe, Werksabnahme.
  • Claim-Management mit folgenden Gliederungspunkten: Kundenforderungen, Mehrleistungen, Mängel.
  • Standards mit folgenden Gliederungspunkten: Standards, Methoden, Werkzeuge, Konventionen, Formulare.
  • Glossar
  • Literaturverzeichnis
 

Fallstudie: FWIMA - Fallstudie Wissensmanagement

Ausgangssituation

Wissen von Organisationen, Teams und Individuen leistet einen wesentlichen Beitrag zur Erreichung der Organisationsziele. Die Nutzung von Technologien und Werkzeugen zur Verbesserung von Geschäftsprozessen, zur internen und externen Kommunikation und zur Speicherung und Bereitstellung von Daten gilt als Selbstverständlichkeit. Trotzdem wird selten bewusst organisationsweit geplant und gesteuert. Nur in wenigen Fällen werden Handlungen am aktuellen und zukünftigen, für die Leistungserstellung relevanten Bedarf und Bedürfnis der Mitarbeiter ausgerichtet. Dem intuitiv oft richtigen Vorgehen beim Umgang mit Wissen kann entgegengehalten werden, dass ein methodisches Vorgehen zu besseren Ergebnissen führt.

Wissensmanagement wird in der Literatur seit den 1990er Jahren große Aufmerksamkeit gewidmet. Diplomarbeiten und Dissertationen haben dieses Thema auf Grundlage unterschiedlicher Disziplinen bearbeitet; im World Wide Web sind die Beiträge zu Wissensmanagement nicht mehr überschaubar. Prozessmanagement ist auch nach dem Hype, den es durch Hammer/Champy erfahren hat, ungebrochen aktuell, vernachlässigt aber häufig die für den Organisationserfolg zentrale Ressource Wissen. Die Beherrschung der Prozesse ist einerseits eine Voraussetzung für Wissensmanagement, andererseits wird durch Wissensmanagement die Beherrschung der Prozesse verbessert.

Die Fokussierung auf die Ressource Wissen und die häufig beschriebene, zunehmende Bedeutung bedingt keine – wie beim Business Reengineering geforderte – Neuausrichtung der Organisation. Die Entwicklung von Wissensmanagement ist mit der des Controllings und des Marketings vergleichbar. Auch hier waren die Grundlagen in den Organisationen bereits vorhanden, aber erst mit der Einführung der Disziplinen an Universitäten und der Einrichtung von Abteilungen in Organisationen wurde ihnen jene Aufmerksamkeit beigemessen, die ihnen aufgrund ihrer Bedeutung für den Organisationserfolg gebührt. Alle Organisationsbereiche, vor allem die Unterstützungsprozesse, sind in ein integriertes Wissensmanagement einzubeziehen. Eine Dominanz der IT-Abteilung oder der HR-Abteilung (HR = Human Relations) führt zu Leistungsverlusten.

Der Bedeutung von Wissensmanagement steht ein Mangel an Methoden zur Einführung von Wissensmanagement gegenüber. Daher wurde 2002/2004 am Institut für Wirtschaftsinformatik – Information Engineering der Universität Linz (www.ie.jku.at) in Kooperation mit dem ipo – Institut für Personal- und Organisationsentwicklung in Wirtschaft und Verwaltung an der Universität Linz (www.ipo.jku.at) eine Methode zur Istzustandserfassung der Wissensorientierung entwickelt und prototypisch erprobt, die als Wissensmanagement-Audit (kurz WM-Audit) bezeichnet wird. Sie wird jetzt vom Institut für Prozessoptimierung und Auditing in Wirtschaft und Verwaltung (www.proaudit.at) verwendet.

Grundlagen WM-Audit

Istzustand ist die Gesamtheit der technischen, organisatorischen, personellen und sozialen Regelungen eines bestehenden Systems. Diese Definition ist im Sinne des Wissensmanagements besonders relevant, da es sich bei Wissensmanagement-Systemen immer um eine Interaktion der Bereiche Mensch, Technik und Organisation handelt.

Grundsätzlich stehen für die Istzustandsanalyse der istzustandsorientierte und der sollzustandsorientierte Ansatz zu Verfügung. Für das WM-Audit wurden beide Ansätze kombiniert, um ihe Nachteile so weit als möglich zu vermeiden. Die Vorgehensweise des istzustandsorientierten Ansatzes, zuerst Istzustandserfassung, dann Istzustandsanalyse und anschließend Systementwurf durchzuführen, wurde beibehalten; der Istzustandserfassung ist allerdings ein grober Systementwurf nach der Struktur des im WM-Audit enthaltenen Referenzmodells vorgelagert. Damit soll der Gefahr der Gegenwarts- oder sogar Vergangenheitsorientierung entgegengewirkt werden. Die Vorgehensweise ist wegen der geringen Kenntnis über den Istzustand – gerade deshalb wird ja auch das WM-Audit durchgeführt) –nicht veränderbar.

Ziel des WM-Audits ist es, Organisationen zu ermöglichen, mit geringem Aufwand die bestehende Wissensorientierung zu erheben, zu analysieren und Maßnahmen zur Verbesserung der Wissensorientierung einzuleiten. Nach Durchführung des WM-Audits

  • kennt die Organisation den Istzustand der Wissensorientierung;
  • hat die Organisation ein Verständnis hinsichtlich eines möglichen Sollzustands der Wissensorientierung;
  • haben die Teilnehmer der Workshops ein verstärktes Problembewusstsein hinsichtlich der Ressource Wissen;
  • verwenden die Teilnehmer der Workshops einheitliche Begriffe im Bereich Wissensmanagement;
  • haben die Teilnehmer der Workshops die Fähigkeit, den Nutzen von Wissensmanagement-Projekte zu beurteilen;
  • haben die Teilnehmer der Workshops die Fähigkeit, Wissensziele zu identifizieren und Maßnahmen zur Erreichung der Wissensziele abzuleiten.

Prinzipien des WM-Audits

  • Als Grundkonzeption werden die Arbeiten von Probst/Raub/Romhardt und Rohmardt verwendet.
  • Als größtmögliche Systemgrenze wird die Gesamtorganisation herangezogen. Die Auditierung von Organisationsteilen ist möglich. Das Umsystem wird, soweit es einen Einfluss auf die Organisation hat, berücksichtigt. Die Festlegung der Systemgrenze erfolgt in Absprache mit dem Auftraggeber.
  • Der Detaillierungsgrad der Istzustandserhebung wird durch die Anzahl der Teilnehmer an den Workshops und die Anzahl der befragten Organisationsmitglieder in Abstimmung mit dem Auftraggeber festgelegt. Dem maximalen Detaillierungsgrad, der Befragung aller Organisationsmitglieder, stehen die hohen Kosten gegenüber.
  • Die Attribute sind durch das Referenzmodell, das auf Grundlage der Grundkonzeption erstellt wurde, vorgegeben. Die Attribute sind, unabhängig von der jeweiligen Organisation, beim WM-Audit immer gleich.
  • Die Attributwerte werden durch strukturierte Interviews unter Zuhilfenahme eines webfähigen Erhebungs- und Auswertungswerkzeugs erhoben.
  • Die Dokumentation erfolgt mit Hilfe des Erhebungs- und Auswertungswerkzeugs sowie der im Workshop 2 identifizierten Korrekturen.
  • Die Analyse des Istzustandes erfolgt im Workshop 2. Die Qualität der Analyse hängt neben den erhobenen Daten und der Motivation der Teilnehmer des Workshops stark von der Erfahrung der Moderatoren ab.
  • Als Vorbereitung für die Istzustandsoptimierung werden auf Grundlage der bei der Istzustandserhebung festgestellten Stärken und Schwächen Ziele für Wissensmanagement identifiziert und Maßnahmen zu deren Erreichung abgeleitet.

Das WM-Audit ermöglicht es, das Ausmaß, in dem das Potenzial von Wissensmanagement zur Sicherung des Organisationserfolgs genutzt wird (Wissensorientierung), zu messen, Problembewusstsein zu schaffen, Begriffe, die unterschiedliche Interpretationen zulassen, zu vereinheitlichen und die Fähigkeit zu erlangen, WM-Projekte beurteilen zu können. Im Folgenden wird das Ergebnis des WM-Audits in der aktuellen Version (Version 3) mit den drei Phasen Workshop 1, Interviews und Workshop 2 dargestellt.

Vorgehensweise beim WM-Audit

Phase A: Workshop 1

Aus folgenden Bereichen sollten Mitarbeiter teilnehmen:

  • Leitung (Vorstand)
  • Organisationsentwicklung
  • Personalabteilung
  • IT-Abteilung
  • 1. Berichtsebene unter der Leitung (Geschäftsbereiche)
  • 2. Berichtsebene unter der Leitung (Mittelmanagement)
  • Sonstige (Mitarbeiter)

Arbeitsschritte des Workshop 1 sind:

  • Arbeitsschritt 1: Die für Wissensmanagement essenziellen Begriffe werden erklärt und deren Verwendung vereinheitlicht, dabei handelt es sich insbesondere um folgende Begriffe: Daten / Information / Wissen; Daten- / Informations- / Wissensverarbeitung; Organisationales Lernen und Wissensmanagement; strategisches Management, Human Ressource Management, IT-Management; implizites und explizites Wissen; Wissensspirale; Wissensmanagement in Projekten; die acht Bausteine des Wissensmanagements.
  • Arbeitsschritt 2: Bei den am Workshop beteiligten Mitarbeitern wird Problembewusstsein für Wissensmanagement geschaffen, um – davon abgeleitet – den Bedarf für die Organisation zu erkennen, insbesondere werden folgende Themen behandelt: Entwicklung Agrar-, Industrie-, Wissensgesellschaft; Ausmaß der Nutzung bereits in der Organisation vorhandenen Wissens; Erfolgsfaktoren für Wissensmanagement; Phasenmodell der Wissensmanagement-Implementierung; Hinderungsgrund Nr. 1: Zeitmangel.
  • Arbeitsschritt 3: Anpassung des Referenzmodells an die Anforderungen der Organisation bzw. an die Einschätzung der Workshop-Teilnehmer (vgl. Abbildung FWIMA-1). Dies erfolgt durch die gemeinsame Bearbeitung der Interviews (siehe Phase B) hinsichtlich der Sollwerte. Das relative Optimum wird in Abbildung FWIMA-1 durch die durchgezogene Linie dargestellt.
  • Arbeitsschritt 4: Den Workshopteilnehmern werden über den Ablauf des WM-Audits, der aus Workshop 1, Interviews und Workshop 2 besteht, und über die Grundlagen des WM-Audits informiert.
  • Arbeitsschritt 5: Festlegen der Interviewpartner und -termine.
fallstudie- fwima - fallstudie wissensmanagement 1
Abb. FWIMA-1: Anpassung Referenzmodell

 

Phase B: Interviews

Für den Aufbau des Fragenkatalogs wurden die Struktur der acht Bausteine von Probst/Raub/Romhardt und der Interventionsquadranten von Romhardt verwendet. Die 40 Interventionsquadranten werden mit je zwei Definitionen erklärt und präzisiert. Die Definitionen stehen dem Interviewer zur Verfügung.

Pro Quadrant werden durchschnittlich drei Fragen gestellt. Insgesamt besteht der Fragebogen aus 133 Fragen. Jede Frage wird an zwei Mitarbeiter aus unterschiedlichen Hierarchieebenen gerichtet. Durch die doppelte Beantwortung der Fragen lassen sich unterschiedliche Sichtweisen verschiedener Hierarchieebenen darstellen. Die Antwortausprägungen sind vorgegeben. Grundsätzlich schließen sich die Antwortausprägungen gegenseitig aus. Nur bei wenigen Fragen sind Mehrfachnennungen erlaubt. Jede Organisation ist wegen seiner Geschichte, seiner Produkte und Dienstleistungen und seines Umfeldes unterschiedlich. Es ist daher nicht möglich, alle denkbaren Antwortausprägungen zu beschreiben. Die Interviewten werden daher gebeten, die am ehesten zutreffende Antwortausprägung auszuwählen.

Jeder Antwortausprägung ist ein nominaler Wert zugeordnet. Die der Definition der positiven Ausprägung des Quadranten am ehesten entsprechende Antwort hat den höchsten Wert. Die der Definition der positiven Ausprägung des Quadranten am wenigsten entsprechende Antwort hat den niedrigsten Wert. Da die Zahl der Fragen je Quadrant und auch die zu erreichenden Werte je Quadrant unterschiedlich sind, werden die Werte durch Multiplikation mit einem Faktor bereinigt.

Abbildung FWIMA-2 zeigt den Aufbau des Fragenkatalogs am Beispiel Erheben der Wissensziele. Darin bedeuten:

  • 1 Baustein
  • 2 Quadrant
  • 3 eine (der zwei) positive(n) Ausprägung(en) des Quadranten – entwertende Übertreibung
  • 4 Kurzbeschreibung des Sollzustandes
  • 5 Funktionen bzw. Abteilungszugehörigkeit der zu Befragenden: Le = Leitung; Oe = Organisationsentwicklung; Pe = Personalabteilung; IT = IT-Abteilung; 1e = 1. Ebene unter der Leitung; 2e = 2. Ebene unter der Leitung; Ma =Mitarbeiter
  • 6 Frage
  • 7 Wert der jeweiligen Antwortausprägung
  • 8 mögliche Antwortausprägungen
  • 9 Ziel der Frage
  • 10 Behauptungen, auf denen die Frage begründet
  • 11 Begründung für die Bewertung
fallstudie- fwima - fallstudie wissensmanagement 2
Abb. FWIMA-2: Aufbau des Fragenkatalogs

 

Die Verwaltung der Fragen, die Durchführung der Interviews und die Auswertung der Antworten werden durch ein Werkzeug unterstützt. Abbildung FWIMA-3 zeigt beispielhaft die administrativen Möglichkeiten vom Bearbeiten ganzer Bausteine bis hin zum Bearbeiten einzelner Fragen. Es besteht auch die Möglichkeit, Antworten mit Dokumenten belegen zu lassen (davon wurde bisher wegen des hohen Aufwands nicht Gebrauch gemacht), Fragen Funktionen zuzuordnen und Interviewpartner zu verwalten.

Phase C: Workshop 2

Am Workshop 2 sollten die gleichen Mitarbeiter teilnehmen wie am Workshop 1, da Teile des im Workshop 1 vermittelten Wissens vorausgesetzt werden. Arbeitsschritte von Workshop 2 sind:

Arbeitschritt 1: Die mit der Datenerhebung gewonnenen und ausgewerteten Daten werden präsentiert und gemeinsam mit den Teilnehmern auf Plausibilität überprüft.

  • Für jeden Baustein wird anhand eines leeren Grafen die Bedeutung der einzelnen Quadranten erklärt. Zusätzlich zur Powerpoint-Präsentation wird ein Handout ausgeteilt.
  • Das Ergebnis der Interviews wird zuerst anhand des Gesamtergebnisses und anschließend anhand der Detailergebnisse (beide Hierarchieebenen) erklärt. (Powerpoint-Präsentation und Handout).
  • Die Ergebnisse werden von den Moderatoren interpretiert. (Powerpoint-Präsentation und Handout).
  • Die Ergebnisse werden von den Teilnehmern diskutiert; die Erkenntnisse daraus auf Flipcharts stichwortartig festgehalten.
  • Die Handouts werden für jede der genannten Aktionen separat ausgeteilt, um die ungeteilte Aufmerksamkeit der Teilnehmer sicherzustellen.

Arbeitsschritt 2: Zu ausgewählten Bausteinen des Wissensmanagements (an die Organisation angepasst) wird ein Theorieinput gegeben. Unter Verwendung von Kreativitätstechniken werden die gemeinsam gewonnenen Erkenntnisse auf die Organisation übertragen.

Abbildung FWIMA-4 zeigt die grafische Auswertung eines Bausteins am Beispiel Wissensziele. Die unterschiedlichen Linien zeigen die verschiedenen Sichtweisen der Hierarchieebenen.

 

fallstudie- fwima - fallstudie wissensmanagement 3
Abb. FWIMA-3: Beispiel Auswertungswerkzeug

 

fallstudie- fwima - fallstudie wissensmanagement 4
Abb. FWIMA-4: Beispiel grafische Auswertung

 

Die Kommentare der Moderatoren zu den Auswertungen sind deren subjektive Sichtweise, die sich aus den Erfahrungen des Workshop 1, den Ergebnissen der Befragung und den Beobachtungen des Interviewers zusammensetzen. Sie stellen neben den Grafen die Grundlage für die Diskussion durch die Teilnehmer dar. Die Ergebnisse der Diskussion werden, sofern diese noch nicht dokumentiert sind, stichwortartig für jeden Baustein auf Flipcharts festgehalten.

Als Abschluss der Ergebnispräsentation wird eine zusammenfassende Tabelle über ein bis drei Stärken und Schwächen je Baustein, die bei der Befragung erkannt wurden, präsentiert. Für den ersten Block sollten nicht mehr als 90 Minuten verbraucht werden. Eine Pause nach diesem Zeitraum ist angebracht und ermöglicht erhöhte Aufmerksamkeit für die Wissenszielplanung.

 

Arbeitsschritt 3: Zielplanung. Trotz Balanced Scorcard und Management by Objectives haben viele Manager Schwierigkeiten, Ziele so zu formulieren, dass die Zielerreichung messbar ist. Bei Wissensmanagement zeigt sich wegen der oft qualitativen Ziele diese Problematik besonders. Verschwommene Zielformulierungen rächen sich, da die Konkretisierung der Ziele auf untere Ebenen verlagert wird. Die Ziele können dann vom Top-Management nicht optimal unterstützt werden.

 

Arbeitsschritt 4: Ableitung von Maßnahmen. Um die identifizierten Ziele bestmöglich zu erreichen, sind möglichst viele Maßnahmen abzuleiten, um dann die am besten geeigneten Maßnahmen auszuwählen. Eine frühzeitige Konzentration auf scheinbar geeignete Maßnahmen versperrt die Sicht auf andere, möglicherweise besser geeignete Wege zum Ziel. Um Maßnahmen beurteilen zu können, ist es erforderlich, Kriterien festzulegen. Für die Vorauswahl sollte die Kompliziertheit der Kriterien möglichst gering gehalten werden, um die Entscheidung zu vereinfachen und nachvollziehbar zu machen.

Abbildung FWIMA-5 zeigt als Ergebnis von Workshop 2 die aufgrund der identifizierten und detailliert ausformulierten Wissensziele abgeleiteten und nach festgelegten Kriterien beurteilten Maßnahmen.

fallstudie- fwima - fallstudie wissensmanagement 5
Abb. FWIMA-5: Beispiel Maßnahmenportfolio

Praxiserfahrungen

Erfahrungen aus der Erprobung des WM-Audits in acht Organisationen sind:

  • Verhalten der Workshopteilnehmer während des WM-Audits: Die beobachtbare Gleichgültigkeit einzelner Teilnehmer zu Beginn von Workshop 1 weicht bis zum Ende des Workshops einer Neugierde hinsichtlich der Befragung und dem folgenden Workshop 2. Im Workshop 2 bestätigten die Teilnehmer einhellig die Plausibilität der Auswertungsergebnisse. Die darauf aufbauende Identifizierung und Formulierung von messbaren Zielen durch die Teilnehmer verursachte jedoch große Probleme. Die Trennung in Wissensziele und Geschäftsprozessziele war für die Teilnehmer nicht immer einfach und bedurfte mehrfach der Intervention durch die Moderatoren. Bei der Maßnahmenplanung traten keine Probleme auf. Es zeigte sich, dass einfache Maßnahmen sehr wirksam sein können, da sie leicht umsetzbar sind und von den Mitarbeitern schnell akzeptiert werden.
  • Allgemeine Erkenntnisse zum WM-Audit: Das WM-Audit ist ein Beitrag zur methodischen Aufarbeitung der Thematik Wissensmanagement in Organisationen und dient primär dem organisationsweiten Einstieg. Organisationen, die WM-Audits durchführten, hatten sich bereits in Teilbereichen mit Wissensmanagement beschäftigt. Trotzdem wurde ausnahmslos großes Potenzial in der Nutzung des in der Organisation vorhandenen Wissens (Baustein Wissensidentifikation) festgestellt. Durch die erstmalige organisationsweite Betrachtung des Themas im Rahmen des WM-Audits wird ein erster und wichtiger Schritt getan. Vor allem die Ausarbeitung konkreter Anwendungsbeispiele ist eine entscheidende Motivation für die Teilnehmer der Workshops.
  • Wissensmanagement-Aktivitäten nach dem WM-Audit: Von acht Organisationen haben sich nur zwei dem Wissensmanagement weiter ausführlich gewidmet. In einer der beiden Organisationen war das WM-Audit der Anstoß für einen verstärkten Einstieg ins Wissensmanagement. Hier zeigte sich auch, dass die wesentliche Voraussetzung für den sinnvollen Einsatz des WM-Audits die Unterstützung durch und die Teilnahme des Top-Managements an den Workshops ist; andernfalls reiht sich das WM-Audit in die Liste der zwar sinnvollen, aber nie umgesetzten Projekte ein. In allen acht Organisationen wurden die Workshop-Teilnehmer für das Thema Wissensmanagement sensibilisiert. Es wurde deutlich, welche Vorteile sich durch einen gezielten Umgang mit Wissen ergeben. Daher kann angenommen werden, dass die Teilnehmer einfache Maßnahmen innerhalb ihres Wirkungsbereiches umsetzen werden. Die Motivation, vorhandenes Wissen in Fachabteilungen und Niederlassungen einer größeren Anzahl von Mitarbeitern zugänglich zu machen, wurde geweckt.

Literatur

Auinger, Th.: Wissensmanagement-Audit – Eine Methode zur Istzustandsanalyse. Dissertation, Johannes Kepler Universität Linz, 2005

Fallstudie: FSEMA - Fallstudie Servicemanagement

Inhaltsverzeichnis[Verbergen]

Ausgangssituation

Das Material dieser Fallstudie stammt aus dem Projekt Erfolgsmessung Benutzer­service, das 1995 in einem Unternehmen der Eisen- und Stahlindustrie durch­geführt wurde. Zunächst wurde ein Modell des Aufgabensystems Benutzerservice entwickelt. Von diesem ausgehend wurden dessen Eigenschaften herausgearbeitet, mit denen der Erfolg unter Verwendung der Erfolgsfaktoren­analyse gemessen werden kann. Untersuchungsmethodisch handelt es sich um eine Forschungs­fallstudie, deren Ergebnis ein Messmodell ist; seine Erprobung und Verwendung war nicht Gegenstand des Projektauftrags. Die Arbeits­gruppe bestand aus fünf Personen, davon zwei auf Seiten des Auftragsnehmers, die drei auf Seiten des Auftraggebers waren Mitarbeiter der Stelle Benutzerservice der IT-Abteilung, einer davon deren Leiter.

Aufgabensystem Benutzerservice

Zweck des Benutzerservice im Sinne von Sachziel ist es, Dienstleistungen für Benutzer zur Verfügung zu stellen, welche die aufgaben­adäquate Nutzung von Informationssystemen ermög­lichen, einschließlich der von ihnen verwende­ten Technologien. Dabei wird von der Vor­aus­setzung ausgegangen, dass der Benutzerservice auf Grundlage vor­hande­ner Betriebsmittel agiert und diese nicht wesentlich verändert. Die vom Benut­zerservice verfolgten Formalziele lassen sich im Sinn des strategischen Con­trol­lings zu den Zielen Wirksamkeit und Wirtschaftlichkeit aggregieren (vgl. Lern­einheit CONTR). Die aufgabenadäquate Nutzung soll bei einer geplanten Wirk­samkeit so wirtschaftlich wie möglich bzw. bei einer geplan­ten Wirt­schaft­lichkeit so wirksam wie möglich erfolgen.

alt
Abb. FSEMA-1: Aufgabensystem Benutzerservice

Aus dem Zweck des Benutzerservice werden dessen Aufgaben abgeleitet. Eine sys­tematische Top-down-Zerlegung ergibt die Aufgaben Pro­blem­management, Bera­tungsmanagement, Schulungsmanagement und Ressour­cen­management; In­stal­lations- und Wartungsmanagement bleiben als nicht zum Zweck des Benut­zer­service gehörend unberücksichtigt; sie sind Aufgabe des Produktions­mana­gements (vgl. Lerneinheit PRODM). Abbildung FSEMA-1 veranschaulicht die Auf­gaben des Benutzerservice und die zwi­schen ihnen bestehenden Beziehungen. Erkenn­bar ist die zentrale Positionierung des Problemmanagements (vgl. Lerneinheit PROBM) über das Art und Umfang des Bera­tungs-, Schulungs- und Ressour­cen­managements gesteu­ert wer­den. Diese Aufgaben werden nachfolgend erläutert.

Problemmanagement: Die Benutzer sind mangels eigener Problemlösungs­kapa­zität nicht in der Lage, eine als Problemempfundene Hand­lungssituation selb­ständig zu bearbeiten; sie sind auf Unterstützung an­ge­wiesen. Problemmana­gement ist daher die Auf­gabe des Benutzerservice, mit der Unter­stützung beim Umgang mit Problemen ange­bo­ten wird. Letztlich soll er­reicht werden, dass sich gleiche Probleme nicht wieder­holen. Problem­ma­na­ge­ment wird in folgende Teilaufgaben, die den Unter­stüt­zungs­bedarf spe­zifi­zieren, zerlegt:

  • Problemerkennung, d.h. Sicherstellen einer schnellen Problementdeckung und Problemidentifikation;
  • Problemdokumentation, d.h. strukturiertes Aufzeichnen von Problemen (z.B. nach Prioritätsstufen);
  • Problembestimmung, d.h. Erkennen der für das Problem verantwortlichen Ursa­chen;
  • Problemumgehung bzw. Problembehebung, d.h. Wiederherstellen des Zustands, der vor dem Problemeintritt bestanden hat;
  • Problemlösung, d.h. Durchführen von Maßnahmen, die zur Beseitigung des Problems führen;
  • Problemprävention, d.h. Durchführen von Maßnahmen, die zur Besei­ti­gung der Ursache(n) für die Problementstehung führen (Änderungs­manage­ment).

Änderungsmanagement ist also in Problemmanagement eingeordnet; eine wei­tere Aufgabe wird darin nicht gesehen. Problemmanagement hat primär die Ver­bes­serung der Wirksamkeit am Benutzerarbeitsplatz zum Ziel (insbesondere durch Wie­derherstellen und durch Steigern der Verfügbarkeit), weniger die Verbes­se­rung der Wirtschaftlichkeit. Problemmanagement ist Angebot und Inan­spruch­nah­me von Problemlösungskapazität, die beim Benutzerservice vorhan­den ist und über die Benutzer selbst nicht verfügen.

Beratungsmanagement: Beratungsmanagement unterstützt die Benutzer durch Beratungsdienstlei­stun­gen darin, vorhandene Betriebsmittel wirksamer und/oder wirt­schaftlicher zu nutzen. Beratungsmanagement hat die Verbesserung der Wirk­sam­keit am Benutzerar­beits­platz zum Ziel (z.B. durch bessere Nutzung einer vorhan­denen Funk­tio­nalität) und/oder die der Wirtschaftlichkeit (z.B. durch Steigerung der Pro­duk­tivi­tät). Beratung schafft spezifische, auf das einzel­ne Beratungs­pro­blem abge­stimmte Pro­blemlösungskapazität bei den Benutzern, so dass die Inten­sivie­rung des Bera­tungsmanagements tendenziell zur Entlastung des Problem­mana­ge­ments führt.

Art und Umfang der Beratungsmaßnahmen werden wesentlich durch das Pro­blem­management beeinflusst, weil aus den Daten der Problemdokumentation Bera­tungs­bedarfe erkannt und in Beratungsmaßnahmen umgesetzt werden. Ob und in wel­chem Ausmaß sowie mit welcher Geschwindigkeit dies erfolgt, sind wesent­liche Eigenschaften des Beratungsmanagements.

Schulungsmanagement: Durch Schulungsmanagement soll die Qualifikation der Benutzer erhalten und bedarfsgerecht weiterentwickelt werden. Dazu gehört die Vermittlung der Kennt­nisse, Fähigkeiten und Fertigkeiten, die für einen sachgerechten Umgang mit Informationssystemen erforderlich sind, sowie auch der Kenntnisse, Fähig­keiten und Fertigkeiten, die Benutzer in die Lage versetzen, Benutzer­beteiligung zu prakti­zieren (vgl. Lerneinheit BEBET). Schulungs­mana­gement hat primär die Ver­besse­rung der Wirksamkeit am Benutzerarbeitsplatz zum Ziel (insbesondere durch bessere Nutzung der Funktionalität), weniger die Verbes­se­rung der Wirtschaft­lichkeit. So wie Beratungsmanagement schafft Schulungs­mana­ge­ment Problemlö­sungs­kapa­zität bei den Benutzern, so dass auch die Inten­sivierung des Schulungs­mana­ge­ments tendenziell zur Entlastung des Pro­blem­managements – wie auch des Bera­tungs­managements – führt. Im Unterschied zum Bera­tungsmanagement geht es beim Schulungsmanagement nicht um eine spezifische, auf das einzelne Bera­tungsproblem abgestimmte, sondern – je nach Schulungsziel und -inhalt – um die Herstellung einer breiteren Problemlösungs­kapazität.

Analog zum Beratungsmanagement werden Art und Umfang der Schulungsmaß­nahmen wesentlich durch das Problemmanagement beeinflusst, weil aus den Daten der Problemdokumentation Schulungsbedarfe erkannt und in Schulungs­maß­nah­men umgesetzt werden. Ob und in welchem Ausmaß sowie mit welcher Ge­schwin­digkeit dies erfolgt, sind wesentliche Eigenschaften des Schulungs­mana­gements.

Ressourcenmanagement: Ressourcenmanagements stellt den Benutzern Hilfs­mittel zur Ver­fügung, mit denen arbeitsplatzspezifische Vorbereitungs­arbeiten (z.B. das Erstellen von Doku­menten für die Textverarbeitung und von Scha­blo­nen) reduziert oder vermieden werden und die Arbeitsdurchführung erleichtert (z.B. durch Bereitstellung von Werkzeugen oder kleinen Anwen­dungs­pro­gram­men) oder koor­diniert wird (z.B. durch Richt­linien und Standards). Res­sour­cen­ma­na­gement hat primär die Ver­besserung der Wirtschaftlichkeit am Benutzer­ar­beits­platz zum Ziel (insbe­son­dere durch Steige­rung der Produktivität), weniger die Ver­bes­serung der Wirksamkeit.

Analog zum Beratungs- und Schulungsmanagement, werden Art und Umfang der Ressourcen wesentlich durch das Problemmanagement beeinflusst, weil aus den Daten der Problemdokumentation Ressourcenbedarfe erkannt und in Res­sourcen umgesetzt werden. Ob und in welchem Ausmaß sowie mit welcher Ge­schwin­dig­keit dies erfolgt, sind wesentliche Eigenschaften des Ressour­cen­ma­nagements.

Gleichgewicht beim Benutzerservice

Für einen wirksamen und wirtschaftlichen Benutzerservice ist ein ausgewogenes Ver­hältnis zwischen Problemmanagement und Beratungs-, Schulungs- und Res­sour­cenmanagement erforderlich. Weder darf das Problemmanagement die ande­ren Aufgaben dominieren (z.B. gemessen an der Anzahl der Pro­blem­fälle), noch umgekehrt; die Aufgaben müs­sen so im Gleichgewicht sein, dass der Benut­zerservice Dienstleistungen bei gegebener Wirksamkeit so wirtschaftlich wie mög­lich bzw. bei gegebener Wirt­schaftlichkeit so wirksam wie möglich erbringt. Jede Dienstleistung des Benutzerser­vice soll daher mit der Aufgabe wahrge­nommen werden, mit der die Dienstleistung so wirt­schaft­lich bzw. so wirksam wie möglich realisiert werden kann.

In analoger Weise wird die Forderung nach Gleichgewicht zwischen dem Be­nutzerservice mit allen Aufgaben und den Benutzern im Anwendungsumfeld pos­tuliert. Weder soll der Benut­zerservice die Anwender dominieren (kein Zwang zur Inanspruchnahme von Dienstleistungen), noch umgekehrt (keine Eigenerbringung von Dienstleistungen durch die Benutzer, wenn diese vom Benutzerservice ange­boten werden). Eine Dienstleistung soll vom Benutzerservice dann angeboten und von den Benutzern dann beansprucht werden, wenn dies wirksamer und/oder wirt­schaft­licher ist, als wenn die Dienstleistung von den Benutzern selbst erbracht wird, vice versa.

Mit dieser Forderung soll Peer-to-Peer-Support unter Kontrolle gehalten bzw. ver­mieden werden. Empirische Befunde zeigen, dass Peer-to-Peer-Support zumin­dest bezüglich Wirtschaftlichkeit kritisch zu beurteilen ist; ein leistungs­fähiger Benut­zerservice kann Dienstleistungen wirtschaftlicher an­bie­ten. Es ist auch frag­lich, ob Peer-to-Peer-Support bezüglich Wirk­sam­keit mit einem leis­tungs­fä­higen Benut­zerservice konkurrieren kann.

Institutionalisierung Benutzerservice

Die Forderung nach Gleichgewicht zwischen den Aufgaben des Benutzerservice sowie zwischen diesen und den Benutzern bedeutet bezüglich der Struktur­orga­ni­sation, dass Benutzerservice eine zentrale Instanz ist. Bezüglich des Sach­cha­rak­ters der Aufgaben steht Problemmanagement im Vordergrund, Beratungs-, Schu­lungs- und Ressourcenmanagement stehen im Hintergrund. Bezüglich der Kom­pe­tenzebene der Aufgaben (Planen, Durchführen, Koor­di­nie­ren, Kontrollieren usw.) stehen Planen und Koordinieren im Vordergrund, Durch­führen steht im Hin­ter­grund. Daraus folgt, dass die Instanz Benutzerser­vice bei der Aufgabe Pro­blem­management alle Kompetenzebenen umfassen soll­te, bei den anderen Aufgaben sollte sie primär eine Planungs- und Koor­di­nierungs­funktion haben. Beratungs-, Schu­lungs- und Ressourcen­mana­gement sind insbe­son­dere bezüglich Durch­füh­rung verteilt oder ausgelagert. (Vgl. auch Abschnitt „Stellenbildung Benutzer­ser­vice“ in Lerneinheit STRUK.)

Es ist eine strategische Aufgabe des Informationsmanagements, Entscheidungen über die Aufgabenverlagerung von einer zentralen Instanz zu den Auf­gaben­trägern in den Fachabteilungen bzw. Geschäftsprozessen zu treffen bzw. über die Zu­ordnung bisher nicht wahrgenommener Aufgaben auf diese Aufgabenträger zu entscheiden. Dies kommt in der Formu­lierung der IT-Strategie zum Ausdruck (vgl. Lern­einheit STRAT). Für die Beantwortung der Frage, ob Benutzerservice im Wesentlichen zentra­li­siert oder verteilt institutionalisiert sein soll, gibt es eine Reihe von Pro- und Con­tra-Argumenten, die in der Fachliteratur ausführlich disku­tiert werden. Die Pro-Argu­mente der Zentralisierung entsprechen den Con­tra-Argu­menten der Dezentra­lisie­rung, vice versa.

Zentrales Argument ist die Quali­fi­kation des Per­so­nals bezüglich der Fachauf­gaben und der IT-Aufgaben. Einem zen­tralen Benutzerservice wird eine hohe Quali­fi­kation bezüglich der IT-Auf­gaben attestiert, einem dezentralen Benutzerser­vice bezüg­lich der Fachauf­gaben. Diese und ähnliche Argumente sind wenig über­zeu­gend. Entscheidender Einflussfaktor für die Verteilung des Benutzerser­vice ist die Größe der Informations­infra­struk­tur und ihre Gleichartig­keit oder Unterschied­lich­keit (z.B. bezüglich der ver­wendeten Betriebs­mittel). Mit anderen Worten: In klei­nen Unter­neh­men mit homogenen Betriebsmitteln hat ein zentral institutio­nalisierter Benutzerser­vice Vorteile gegen­über einem dezentral bzw. gemischt zen­tral/de­zen­tral institutio­na­lisierten Benutzerser­vice, vice versa (vgl. Abbil­dung INSIM-5). Entscheidend ist in allen Fällen die stän­di­ge Service-Ver­füg­bar­keit (soge­nannte Hot­line).

Erfolgsfaktoren Benutzerservice

Zum Messen des Erfolgs des Benutzerservice wird die Erfolgsfaktorenana­lyse verwendet (vgl. Lerneinheit ERFAN). Dazu ist es er­for­derlich, die für den Benutzerservice relevanten Erfolgsfaktoren zu entwickeln. Da Erfolgs­faktoren wesentliche Eigenschaften der Objekte sind, deren Aus­prägung gemes­sen wird, geht es hier um die Eigenschaften der vier Aufgaben des Benutzerservice. „Wesentlich“ heißt, dass messbare Unter­schiede der Aus­prägung einer Eigenschaft dann vorliegen, wenn die ange­botenen und in An­spruch genommenen Dienst­leis­tungen verändert werden. Erfolgs­­faktoren sind darüber hinaus im Sinn der Erfolgs­faktorenanalyse nur solche Eigen­schaften, die von Benutzern auf Grund ihrer Sachkenntnis aus eigener Arbeits­erfahrung beurteilt werden können.

Im Folgenden werden die in einer Fallstudie identifizierten Erfolgsfaktoren mit geeig­neten Bezeichnungen benannt und im Sinn einer Definition erläutert. Die Definitionen sind nicht zwingend auch für die Durchführung einer Erfolgs­messung geeignet; auf die zweckmäßige Formulierung im Fragebogen wird später einge­gangen (vgl. das Demonstrationsbeispiel). Mit Motivation bezeichnete Ergänzun­gen zur Defini­tion zeigen, von welchen Annahmen bei der Identifikation der Erfolgsfaktoren aus­ge­gangen wurde.

Bei der Identifikation und Definition der Erfolgsfaktoren wird das Ziel verfolgt, den gemeinsamen Schnitt von Eigenschaftsmerkmalen zu minimieren. Dies er­folgt, um die Mehrfachmessung gleicher Eigenschaftsmerkmale gering zu halten; ver­meiden lassen sich Mehrfachmessungen nicht. Dass die Erfolgsfaktoren nicht dis­junkt sind, muss bei der Interpretation der Messergebnisse berücksichtigt wer­den. Diese Forderung ist auch Begründung dafür, dass eine gründliche inhalt­liche Auseinandersetzung mit den Erfolgsfaktoren bei jeder Anwendung der Erfolgs­faktorenanalyse erforderlich ist. Es empfiehlt sich daher, Erfolgs­mes­sungen von externen Experten durchführen zu lassen oder sie zumindest nur mit deren Unter­stützung durchzuführen.

Erfolgsfaktoren Problemmanagement

Erfolgsfaktoren Problemmanagement sind Verfügbarkeit, Abnahmezeit, Be­he­bungs­zeit, Fachqualifikation, Kommunikationsfähigkeit und Anpassungs­fähig­keit. Akzeptanz wird nicht als Erfolgsfaktor verwendet, weil in dieser komplexen und nicht direkt messbaren Eigenschaft besser messbare Eigenschaften enthalten sind. Akzeptanz wird also in präzisere, besser messbare Eigenschaften zerlegt.

  • Verfügbarkeit Problemmanagement bezeichnet das Verhältnis zwischen der Benutzer-Arbeitszeit und der Problemmanagement-Arbeitszeit. Hohe Verfüg­bar­keit wird im Wesentlichen durch große Übereinstimmung zwischen Benutzer-Arbeitszeit und Problemmanagement-Arbeitszeit bestimmt, muss also nicht iden­tisch sein mit langer Problemmanagement-Arbeitszeit (z.B. „7 Tage rund um die Uhr”). Motivation: Die Benutzer erwarten, dass sie ein Problem dann weiter kom­­munizieren können, wenn es von ihnen erkannt wurde.
  • Abnahmezeit Problemmanagement bezeichnet die Zeitdauer zwischen dem Erkennen eines Problems durch den Benutzer und der Abnahme des Problems durch das Problemmanagement so, dass es bearbeitet werden kann. Eine unkla­re Problemformulierung durch den Benutzer, die zu Rückfragen führt, verlän­gert die Abnahmezeit. Motivation: Die Benutzer erwarten, ein Problem so schnell wie möglich an die Abnahmeinstanz kommunizieren zu können („das Problem schnell loswerden“).
  • Behebungszeit Problemmanagement bezeichnet die Zeitdauer zwischen dem Abschluss der Problemabnahme durch das Problemmanagement und dem Vor­liegen der Problembehebung oder Problemumgehung. Mit der Problem­behe­bung bzw. Problemumgehung ist aus Sicht des Benutzers der Zustand wieder hergestellt, der vor dem Erkennen des Problems bestanden hat. Bezüglich der Behebungszeit bestehen Erwartungen der Benutzer, die durch Ser­vice-Ebenen-Vereinbarungen präzisiert, gestützt und teilweise erst stimuliert werden (etwa die Erwartung, dass bestimmte Problemarten in einem bestimm­ten Umfang sofort behoben werden). Motivation: Die Benutzer erwarten, dass die gewohnte Funktionalität und Leistung so schnell wie möglich wieder hergestellt wird.
  • Fachqualifikation Problemmanagement bezeichnet die vom Benutzer erkenn­baren fachlichen Kenntnisse, Fähigkeiten und Fertigkeiten der im Problem­mana­gement tätigen Aufgabenträger. Dabei geht es in erster Linie um die Quali­fika­tion, mit unterschiedlichen und neuen Problemsituationen fertig zu werden, Veränderungsbedarfe zu erkennen und an die zuständigen Aufga­benträger (z.B. Lieferanten, Hersteller, Entwickler) weiterzuleiten sowie Problemumgehungen („work around“) anzubieten. Fachqualifikation erfordert in der Regel auch gute Kenntnisse der Arbeitsplatzsituation beim Benutzer. Motivation: Die Benutzer erwarten einen sachverständigen Gesprächspartner, bei dem das Problem „gut aufgehoben“ ist.
  • Kommunikationsfähigkeit Problemmanagement bezeichnet die vom Benut­zer erkennbaren persönlichen Eigenschaften der im Problemmanagement täti­gen Aufgabenträger, die diese in die Lage versetzen, stressgeplagten Benut­zern schnell das Gefühl zu geben, „aufgehoben“ zu sein. Im Vordergrund steht die Fähigkeit, im Dialog mit den Benutzern die Informationen abzufragen, die zur Problemidentifikation erforderlich sind. Gemeint sind hiermit auch Eigen­schaf­ten, die es Benutzern erlauben, Ärger abzureagieren (Problemmanager als Blitz­ableiter). Aus diesem Grunde setzen manche Unternehmen Problem­manager ein, die eher Psychologen (z.B. ehemalige Lehrer) als Techniker sind. Moti­va­tion: Die Benutzer erwarten einen Gesprächspartner, bei dem sie sich persön­lich „gut aufgehoben“ fühlen.
  • Anpassungsfähigkeit Problemmanagement bezeichnet die Eigenschaft, aus bekannten Problemfällen Schlussfolgerungen zu ziehen, die zur Stimulierung des Beratungs-, Schulungs- und Ressourcenmanagements führen. Problemfälle sollen durch Beratung, Schulungsmaßnahmen und/oder Ressourcen, mit denen Pro­blem­lösungskapazität bei den Benutzern aufgebaut wird, ver­mie­den werden. Motivation: Die Benutzer erwarten, dass Problem­lösungs­kapa­zität auch vor Ort verfügbar ist, statt sie in jedem Problemfall beim Problemmana­gement anzu­fordern; sie wollen Problemfälle vermeiden.

Erfolgsfaktoren Beratungsmanagement

Bei der Identifikation von Erfolgsfaktoren Beratungsmanagement wird von den identifizierten Erfolgsfaktoren Problemmanagement ausgegangen; sie können auf das Beratungsmanagement übertragen werden. Wegen der zentralen Bedeutung des Problemmanagements ist eine Zerlegung der Eigenschaft Zeit (in Abnah­me­zeit und Behebungszeit) sowie der Eigenschaft Qualifikation (in Fach­qua­li­fi­kation und Kom­munikationsfähigkeit) zweckmäßig. Beim Beratungs­mana­gement – wie auch beim Schulungsmanagement und beim Ressourcenmanagement – werden sie zu­sam­mengefasst. Für das Beratungsmanagement werden also vier Erfolgs­faktoren verwendet: Verfügbarkeit, Reak­tionszeit, Qualifikation und Anpassungs­fähigkeit.

  • Verfügbarkeit Beratungsmanagement bezeichnet die Eigenschaft, die vom Benutzer angeforderte Beratung nach Art und Umfang und zum geforderten Zeitpunkt anzubieten. Alle angebotenen Beratungsdienstleistungen müssen so transparent sein, dass die Benutzer bei Bedarf volle Kenntnis davon erlangen und Beratungsanforderungen in einer angemesse­nen Zeit so ablegen können, dass diese aufgenommen und bearbeitet werden können. Motivation: Die Benut­zer erwarten Beratungsdienstleistungen, mit denen sie eigene Problemlösungs­kapa­zität aufbauen können.
  • Reaktionszeit Beratungsmanagement bezeichnet die Zeitdauer zwischen der Anforderung eines Beratungsbedarfs für eine verfügbare Beratungsdienst­leis­tung und dem Abschluss der Durchführung der Beratung. Motivation: Die Benutzer erwar­ten, dass eigene Problemlösungskompetenz in einem angemes­senen Zeit­raum erworben werden kann.
  • Qualifikation Beratungsmanagement bezeichnet die Fachqualifikation und die Kom­mu­ni­kations­fähigkeit der Berater. Stärker als beim Problem­mana­ge­ment wird Fachqualifikation von Benutzern danach beurteilt, ob gute Kennt­nisse über die Arbeitsplatzsituation vorhanden sind. Kommunika­tions­fähigkeit meint ins­be­son­dere didaktische Fähigkeit. Motivation: Die Benutzer erwarten, dass Be­ra­tungs­dienstleistungen von Personen angeboten werden, die fach­kundig und kommu­ni­kationsfähig sind.
  • Anpassungsfähigkeit Beratungsmanagement bezeichnet die Eigenschaft, aus den Beratungsfällen Schlussfolgerungen zu ziehen, die zur Veränderung des Schu­lungs- und Ressourcenmanagements führen. Beratungsfälle sollen durch Schu­lungsmaßnahmen und/oder Ressourcen, mit denen Problem­lösungskapa­zität bei den Benutzern aufgebaut wird, vermieden werden. Motivation: Analog Pro­blem­management.

Erfolgsfaktoren Schulungsmanagement

Erfolgsfaktoren Schulungsmanagement sind Verfügbarkeit, Reaktionszeit, Qua­li­fikation und Anpassungsfähigkeit.

  • Verfügbarkeit Schulungsmanagement bezeichnet die Eigenschaft, Schulungs­maßnahmen dem Schulungsbedarf der Benutzer entsprechend anzubieten. Das Schulungsziel muss primär auf die Nutzung und Verwendung der Informa­tions­syste­me statt auf deren Bedienung ausgerichtet sein (was in der Regel nur mit unternehmensspezifischen Schulungsmaßnahmen zu erreichen ist). Die Schu­­lungsinhalte müssen auch spezifische Bedarfe (z.B. betriebliche Stan­dards und Konventionen) berücksichtigen. Motivation: Die Benutzer erwarten, dass Schu­lungsmaßnahmen in der Häufigkeit, zu den Zeitpunkten und mit den Zeit­dau­ern angeboten werden, die zur Deckung des Schulungsbedarfs erfor­der­lich sind.
  • Reaktionszeit Schulungsmanagement bezeichnet die Eigenschaft, Schu­lungs­maßnahmen so durchzuführen, dass die Schulungsziele in einer angemessenen Zeit erreicht werden. Motivation: Die Benutzer erwarten, dass eigene Problem­lösungskompetenz möglichst schnell erworben werden kann.
  • Qualifikation Schulungsmanagement bezeichnet die Eigenschaft, zur Durch­füh­rung der Schulungsmaßnahmen fachlich und didaktisch geeignete Trainer ein­zu­setzen. Motivation: Die Benutzer erwarten eine hohe Schulungsqualität.
  • Anpassungsfähigkeit Schulungsmanagement bezeichnet die Eigenschaft, aus den Schulungsmaßnahmen Schlussfolgerungen zu ziehen, die zur Veränderung des Beratungs- und Ressourcenmanagements führen. Beratungsdienstleistungen und Ressourcen, mit denen Problem­lösungs­kapazität bei den Benutzern aufge­baut wird, sollen Schulungsmaßnahmen vermeiden helfen. Motivation: Analog Pro­blem­management.

Erfolgsfaktoren Ressourcenmanagement

Erfolgsfaktoren Ressourcenmanagement sind Verfügbarkeit, Reaktionszeit, Qua­li­fikation und Anpassungsfähigkeit.

  • Verfügbarkeit Ressourcenmanagement bezeichnet die Eigenschaft, Ressour­cen den Anforderungen der Benutzer entsprechend so anzubieten, dass das Angebot jederzeit transparent ist und in Anspruch genommen werden kann. Transparenz ist auch bezüglich der Art und Weise gemeint, mit der Bedarfe nach nicht vorhandenen Ressourcen artikuliert und so abgelegt werden können, dass sie bearbeitbar sind. Motivation: Die Benutzer erwarten, dass von ihnen benötigte Ressourcen angeboten werden.
  • Reaktionszeit Ressourcenmanagement bezeichnet den Zeitraum zwischen dem Entstehen eines Bedarfs an Hilfsmitteln bei den Benutzern und deren Nutz­bar­keit. Dabei kann es sich um vorhandene Hilfsmittel und um neue (zu ent­wi­ckelnde oder zu beschaffende) Hilfsmittel handeln. Motivation: Die Benut­zer erwarten, dass ein von ihnen erkannter Ressourcenbedarf in angemes­sener Zeit gedeckt wird.
  • Qualifikation Ressourcenmanagement bezeichnet die Eigenschaft, den Benut­zern Dienstleistungen mit einer geforderten Qualität zur Verfügung zu stellen. Motivation: Die Benutzer erwarten, dass die von ihnen artikulierten Qualitäts­forderungen von den Ressourcen erfüllt werden.
  • Anpassungsfähigkeit Ressourcenmanagement bezeichnet die Eigenschaft, aus der Ressourcennutzung Schlussfolgerungen zu ziehen, die zur Veränderung des Schulungs- und/oder Beratungsmanagements führen. Ressourcen sollen durch Beratungsdienstleistungen und Schulungsmaßnahmen, mit denen Problem­lö­sungs­kapazität bei den Benutzern aufgebaut wird, überflüssig gemacht werden. Motivation: Analog Problemmanagement.

Anwendungsbeispiel

Es wird die Gestaltung des Fragebogens gezeigt, der zur Messung des Erfolgs des Benutzerservice mit Hilfe der Erfolgsfaktorenanalyse (vgl. Lerneinheit ERFAN) verwendet werden kann. Dabei geht es in erster Linie darum, die Erfolgsfaktoren Benutzerservice so zu formulieren, dass eine ausreichend konsistente Beur­teilung durch die Benutzer möglich ist. Im Folgenden werden sie nicht nach den Aufgaben des Benutzerservice (vgl. weiter oben), sondern nach inhalt­lichen Merk­ma­len geordnet, und zwar wie folgt:

  • Erfolgsfaktoren, mit denen Verfügbarkeit erfasst wird;
  • Erfolgsfaktoren, mit denen Reaktionszeit erfasst wird;
  • Erfolgsfaktoren, mit denen Qualifikation erfasst wird;
  • Erfolgsfaktoren, mit denen Anpassungsfähigkeit erfasst wird.

Die 18 Erfolgsfaktoren werden, wie bei der Erfolgsfaktorenanalyse üblich, mit Groß­buchstaben (wegen der Verwechslungsgefahr mit I, aber ohne J) bezeichnet.

Verfügbarkeit

A Verfügbarkeit Problemmanagement

Mit diesem Erfolgsfaktor wird beurteilt, ob ein zuständiger Mitarbeiter des Benutzerservice zu dem Zeitpunkt angesprochen werden kann, zu dem beim Benutzer ein Problem entdeckt wird.

B Verfügbarkeit Beratungsmanagement

Mit diesem Erfolgsfaktor wird beurteilt, ob die Beratungsdienstleistungen vom Benut­zerservice angeboten werden, für die beim Benutzer Bedarf besteht.

C Verfügbarkeit Schulungsmanagement

Mit diesem Erfolgsfaktor wird beurteilt, ob die Schulungsmaßnahmen vom Benutzerservice angeboten werden, für die beim Benutzer ein Bedarf besteht.

D Verfügbarkeit Ressourcenmanagement

Mit diesem Erfolgsfaktor wird beurteilt, ob die Hilfsmittel vom Benutzer- Service angeboten werden, für die beim Benutzer ein Bedarf besteht.

Reaktionszeit

E Abnahmezeit Problemmanagement

Mit diesem Erfolgsfaktor wird der zur Abnahme eines Problems vom Benutzerservice benötigte Zeitbedarf beurteilt.

F Behebungszeit Problemmanagement

Mit diesem Erfolgsfaktor wird der zur Behebung oder Umgehung eines Problems vom Benutzerservice benötigte Zeitbedarf beurteilt.

G Reaktionszeit Beratungsmanagement

Mit diesem Erfolgsfaktor wird der zur Deckung eines Beratungsbedarfs vom Benutzerservice benötigte Zeitbedarf beurteilt.

H Reaktionszeit Schulungsmanagement

Mit diesem Erfolgsfaktor wird der zur Deckung eines Schulungsbedarfs vom Benutzerservice benötigte Zeitbedarf beurteilt.

I Reaktionszeit Ressourcenmanagement

Mit diesem Erfolgsfaktor wird der zur Deckung eines Ressourcenbedarfs vom Benutzerservice benötigte Zeitbedarf beurteilt.

Qualifikation

K Fachqualifikation Problemmanagement

Mit diesem Erfolgsfaktor wird die fachliche Qualifikation der Mitarbeiter des Benutzerservice beurteilt.

L Kommunikationsfähigkeit Problemmanagement

Mit diesem Erfolgsfaktor wird die Fähigkeit der Mitarbeiter des Benut­zerservice, mit den Benutzern gut kommunizieren zu können, beurteilt.

M Qualifikation Beratungsmanagement

Mit diesem Erfolgsfaktor wird die fachliche und didaktische Qualifikation der Personen, die Beratungen durchführen, beurteilt.

N Qualifikation Schulungsmanagement

Mit diesem Erfolgsfaktor wird die fachliche und didaktische Qualifikation der Personen, die Schulungsmaßnahmen durchführen, beurteilt.

O Qualifikation Ressourcenmanagement

Mit diesem Erfolgsfaktor wird die Qualifikation der Personen, die Res­sour­cen entwickeln und beschaffen, sowie die Qualität der Ressourcen beurteilt.

Anpassungsfähigkeit

P Anpassungsfähigkeit Problemmanagement

Mit diesem Erfolgsfaktor wird die Fähigkeit des Benutzerservice beurteilt, durch geeignete Beratungsdienstleistungen, Schulungsmaßnahmen und/oder Ressourcen zukünftige Problemfälle zu vermeiden.

Q Anpassungsfähigkeit Beratungsmanagement

Mit diesem Erfolgsfaktor wird die Fähigkeit des Benutzerservice beur­teilt, durch geeignete Schulungsmaßnahmen und/oder Ressourcen die Inan­spruch­nahme von Beratungsdiensten zu vermeiden.

R Anpassungsfähigkeit Schulungsmanagement

Mit diesem Erfolgsfaktor wird die Fähigkeit des Benutzerservice beur­teilt, durch geeignete Beratungsdienstleistungen und/oder Ressourcen zukünftige Schulungsmaßnahmen zu vermeiden.

S Anpassungsfähigkeit Ressourcenmanagement

Mit diesem Erfolgsfaktor wird die Fähigkeit des Benutzerservice beurteilt, durch geeignete Beratungsdienstleistungen und/oder Schulungs­maßnahmen die Entwicklung und/oder Beschaffung von Ressourcen zu vermei­den.

Literatur

Heinrich, L. J. / Häntschel, I.: Messen des Erfolgs des Benutzerservice. In: HMD – Theorie und Praxis der Wirtschaftsinformatik 189/1996, 75 – 97, in gekürzter Fassung in: Heinrich, L. J. / Häntschel, I.: Evaluation und Evaluationsforschung in der Wirtschaftsinformatik. Oldenbourg, München/Wien 1999, 323 – 337

Seite 1 von 2