Requirements Engineering als Baustein im ITIL orientierten IT Betrieb

Transkript

1 1 Begrüßung Requirements Engineering als Baustein im ITIL orientierten IT Betrieb Dipl.-Inf. Wildgruber HOOD GmbH Consultant für RM&E, ITIL Dr.-Ing. Baumann Knorr-Bremse Nutzfahrzeuge GmbH Leiter IT-Abteilung T/PI4 11. März 2008 Knorr-Bremse Group Folie 1: Titelfolie kommt glücklich des Weges entlang kommt ebenfalls glücklich des Weges entlang und hat einen HOOD- Arbeitsordner dabei und einen Haufen Zettel! 1 Begrüßung Hallo 2 Hallo - Wie geht es Dir in der Firma? 3 Danke, sehr gut ich bin ganz zuversichtlich! 4 Das freut mich! 5 Ja das stimmt. 6 Kundenzufriedenheit Kundenzufriedenheit durch RM&E Meine Kunden waren damals ständig unzufrieden mit den Leistungen meiner Abteilung. Das war ziemlich unbefriedigend. Als wir uns vor einem Jahr sprachen, warst Du doch eher unglücklich. Damals erzähltest Du, daß Deine Kunden so viel ärger machen!, wenn ich mich recht entsinne, arbeitest Du doch als Manager einer internen IT-Abteilung, und ihr haltet die PLM-Landschaft am Laufen. Da werdet Ihr doch quasi aus der Unternehmenskasse finanziert. Was habt Ihr denn da als Cost Center mit Kundenzufriedenheit zu tun?

2 2 Folie 4: Interne IT Herausforderungen! 7 IT ShS Naja, wir sind sowohl Cost Center als auch Center. Ich bin als Manager dafür verantwortlich, im Rahmen des jährlich festen Budgetrahmens gemäß Businessplan IT- Dienstleistungen anzubieten und weiter zu entwickeln. Wir haben Rechnung zu tragen über unsere Kosten gegenüber der Unternehmensleitung, ohne Profit erwirtschaften zu müssen. Darüber hinaus erbringen wir auch - Leistungen für weitere Kostenstellen auf der Basis interner Leitungsverrechungen. Unsere Kunden entstammen z.b. der Systementwicklung oder dem Vertrieb. Unsere Kunden sind interne Kunden. 8 Aber Deine Kunden waren nicht zufrieden. Was wird denn jetzt anders, dass Du jetzt zuversichtlicher bist? 9 Bier Das ist eine etwas längere Geschichte. Hast Du Lust ein Bier mit mir zu trinken, schau mal, da hinten ist eine nette Umgebung und der Kellner sieht auch so aus, als würde er gern -Leitungen erbringen. 10 Ja gern, da bin ich ja mal gespannt! <In der Bierstube> 11 Guten Tag, wir hätten gern 2 Bier. >> Hier könnte man noch einen netten Dialog zwischen Dir und Colin einwerfen. Kurzszene: Kundenzufriedenheit erreichen durch das Erfüllen von Anforderungen bei der Bierbestellung! 12 Also, nun erzähl mal, wie Du vorhast, die Zufriedenheit deiner Kunden zu steigern.

3 3 Kundenzufriedenheit (Kano-Modell) Knorr-Bremse Group 4 Folie 5: Kundenzufriedenheit (Kano-Modell) 13 Erkenntnis: Kano Dazu muss ich etwas weiter ausholen: Am Anfang stand eine Erkenntnis. Du kennst ja das Kano Modell: >> Erklärung Kano-Modell Kano unterscheidet Kundenanfordungen in drei Gruppen, da eine Erfüllung/Nichterfüllung dieser drei Arten von Anforderungen einen unterschiedlichen Einfluss auf die Kundenzufriedenheit hat. 14 Und an den Leistungsanforderungen habt Ihr dann angefangen zu optimieren, oder? 15 Leistungsanforderungen allein entscheidend für Kundenzufriedenheit? Zunächst wussten wir ja immer nur, daß der Kunde mit unseren entwickelten Lösungen für seine Probleme nicht einverstanden war. Das hat er uns immer deutlich zum Ausdruck gebracht, indem es zu heftigen Diskussionen nach den Release-Wechseln kam. Beispielsweise wurden neu realisierte Funktionen oft genug nach dem Release komplett überarbeitet, Veränderungen an bisherigen Funktionen wurden im Nachhinein nicht akzeptiert. Kosten für die Nacharbeit waren zum Teil sehr hoch. Aus unserer Sicht, waren die Leistungsanforderungen entscheidend für die Kundenzufriedenheit. Sie sollten zumindest den in der Spezifikation vereinbarten Leistungen entsprechen und von uns wie auch vom Kunden als solche empfunden werden. Aber nach Kano ist das eben nur die halbe Miete.

4 4 16 Metriken? 17 Metriken für IT Projekte Maß für die Kundenzufriedenheit 18 Erhebung von Kundenwünschen? Prozess für RME? 19 RM-Prozess JA = Blueprint, entscheidend ist, was d rin steht 20 RD-Prozess? 21 kein RD-Prozess! 22 Nutzung von Standards im IT Betrieb? Schon: Zum Projektabschluss erheben wir, ob das Projekt in Budget, in Time und in Quality ist. Aber das Spiegelt eben nur sehr unzureichend die Erfüllung der Kundenanfoderungen wider. Detaillierte Metriken für die Kundenzufriedenheit im Sinne von Erfüllung aller Wünsche hatten wir keine. Ja, wir haben einen Prozess. Blueprinting heißt das bei uns und beinhaltet die Erhebung von Usecases und die Ableitung notwendiger Toolfunktionen. Allerdings wie gesagt beschränkte sich das Blueprinting unzureichenderweise auf die Leistungsanforderungen. Hier sind wir wieder bei Kano. Auch die Qualität der erhobenen Anforderungen war offenbar nicht gut genug. Nein, den hatten wir nicht, und daher hatten wir auch beispielsweise kein eigenes Qualitätsniveau im Rahmen der Anforderungsentwicklung definiert und sind auch nicht einheitlich unter den Mitarbeitern dabei vorgegangen. Wir konnten letzten Endes (genau wie auch die Kunden) nur schwer sagen, welches die zu erfüllenden Anforderungen in den Spezifikationen waren, auf die man sich geeinigt hatte. Wir hatten keine mit dem Kunden vereinbarte Basis über die zu erfüllenden Anforderungen. Unterstützen Frameworks das Thema RM&E? Und wie seid Ihr aus diesem unglücklichen Kreislauf herausgekommen? Hattet Ihr denn bisher keine Metriken oder Kennzahlen für die Kundenzufriedenheit? Verstehe...Und dann kam am Ende die große Überraschung mit anbahnender Eskalation. Wie habt Ihr denn die Kundenwünsche erhoben? Hattet Ihr denn keinen Prozeß mit Aspekten zum Anforderungsmanagement und Engineering, der die Zielsetzung Erfüllung von Anforderungen betonte? Einen Prozess für die Anforderungserhebung hattet Ihr demnach nicht? Aber Ihr arbeitet doch nach Standard- Prozessen aus Frameworks wie dem V-Modell oder das für das IT Management vordefinierte ITIL. ITIL hat doch den Anspruch IT-Dienstleistungen und s kundenorientiert zu erbringen.

5 5 Standard Frameworks bei T/PI4 ITIL V3 V-Modell Knorr-Bremse Group 6 Folie 6: Standard Frameworks bei T/PI4 23 V-Modell Ja schon, aber was geben denn die Frameworks schon vor. >> V Modell erklären! 24 ITIL Das V-Modell hilft, die Komplexität eines Entwicklungsprojektes beherrschbar zu machen, die Tests und Spezifikationen gemäß Ihrer Abstraktionsebene in Beziehung zu setzen. Vom Umgang mit Kundenzufriedenheit ist da wenig zu entnehmen. Und Verständnis zum Anforderungsmanagement und Engineering und dessen vermittelnde Disziplin zwischen Kunde, Entwicklungs- und Testingenieur steht hier überhaupt nicht im Vordergrund. Ähnlich sieht es doch bei ITIL aus, oder etwa nicht? Na ja, vielleicht nicht ganz! Hier unterscheidet sich doch die Prozeßwelt im Engineering etwas zur Prozeßwelt in der IT. >> ITIL Modell erklären! Gerade ITIL definiert ja alles zu dem einen Zwecke: -Erbringung zur Unterstützung der betrieblichen Geschäftsprozesse. Ich denke, daß hier schon Anätze vorhanden sind, mit Business Anforderungen umzugehen und diese in Anforderungen zu spezifizieren.

6 6 25 Beim Rollout ist Startpunkt = gelebte Praxis Framework Ja, aber wo sind konkrete RM&E practices 26 Übersetzung in eigene Prozesse und SLA sind entscheidend 27 capture Ja, vielleicht wird das in einem der mittlerweile über 20 ausführlich beschriebenen Framework Prozesse in den 5 ITIL Büchern grob definiert. Dennoch müssen wir jetzt damit arbeiten und müssen vor allem darauf aufbauen, was in unserer Implementierung der ITIL-Prozesse existiert. Da hilft ein Framework allein nicht viel weiter. Außerdem weiß man anhand eines Frameworks auch nicht, inwieweit die -Erbringung zur Unterstützung der betrieblichen Geschäftsprozesse erfolgreich sein wird. Womit wir beim capture Projekt wären: das ist genau der Grund, weshalb wir Euch als Experten hinzugezogen haben. Im wesentlichen sind Eure Themen schon die gleichen, wie sie auch bei ITIL adressiert werden: Anforderungsdefnitionen für Projekte im Blueprint Anforderungsdefnition für s im Incident Management für den Erfolg beim Kunden ist die Übersetzung auf die eigenen Prozesse und Formulierung des SLAs entscheidend.

7 7 Virtuelles Informationsmodell = Basis für strukturiertes RM&E User access via Requirements Management Tool Database Definition: Das Informationsmodell modelliert, welche Arten von Informationen betrachtet werden, welche Eigenschaften sie haben und wie sie miteinander in Beziehung stehen. Das Informationsmodell ist somit die Basis für die Gestaltung von Informations- und Datenflüssen in Projekten und Prozessen und ein wichtiger Baustein zur Unterstützung des RM&E. Knorr-Bremse Group 7 Folie 7: Das Virtuelle Informationsmodell als Basis für strukturiertes RM&E 28 Informationsmodell 29 Das war für die Mitarbeiter allerdings ziemlich befremdlich. Ja und wir haben auch gute Ergebnisse erzielt. >> Eingehen auf die Slide-Darstellung. Wir haben beispielsweise die Struktur Eurer Informationselemente analysiert und erfolgreich ein Mapping auf das V-Modell durchgeführt. 30 Schon, aber mit den RM&E-Prozessen dazu ging es dann schon etwas leichter. 31 Geholfen hat vor allem die Erkenntnis, wo wir überall mit Anforderungen umgehen.

8 8 RM&E Awareness Management of Change bei der RM&E Einführung in der IT Knorr-Bremse Group 8 Folie 8: Management of Change vor dem Fachlichen Hintergrund: RM&E Einführung in der IT 32 Ich weiß noch, wie Deine Mitarbeiter zunächst motiviert und sensibilisiert werden mussten, über die Qualität von Anforderungen überhaupt nachzudenken. 33 Reviews zur RQ- Erhebung 34 Kein zusätzlicher RM&E Prozess Ja das hat sich heute wesentlich verändert. Wenn der Kunde heute auf uns zukommt und unklare Anforderungen formuliert, greift der interne Review-Prozess, der aus dem RM&E Prozess resultiert, und fordert die Überarbeitung der Anforderungen auf Kundenseite. >> Eingehen auf die Slide-Darstellung. Aber diese Hemmschwelle ist uns ja generell aus dem Business Change Management bekannt. Hier war die Diskussion um Kano sicherlich ausschlaggebend. Neben der Frage nach den Inhalten wurde auch auch das Beteiligungsproblem (Kunde fordert ein, beteiligt sich aber nicht an der Spezifikation) offenbar. Es war damals ganz hilfreich, daß wir die RM&E relevanten Prozeßschritte einfach in die bestehenden ITIL-Prozesse integriert haben. Dadurch musste kein zusätzlicher Prozess ausgerollt werden.. >> Eingehen auf die Slide-Darstellung.

9 9 Review-Prozess innerhalb des Change Managements (Auszug) Die Einführung eines expliziten Reviews der Kundenanforderungen mit allen Stakeholdern ist ein essentieller Schritt zum gegenseitigen Verständnis!! Knorr-Bremse Group 9 Folie 9: Review-Prozess innerhalb des Change Managements (Auszug) 35 RM&E ist keine zusätzliche Aufgabe 36 Integration in bestehende Prozesse = Diskussion auf Augenhöhe Ja, wir wollten die Anforderungsarbeit in das bisherige Geschehen integrieren. Die Betonung lag auf das alte besser machen und nicht auf Anforderungsmanagement als zusätzlicher Aufgabe. >> Eingehen auf die Slide-Darstellung. Die Einführung eines separaten RM&E Prozesses war auch gar nicht notwendig. Die bestehenden Prozesse im Lifecycle, wie Design, der Transition und Operation um RM&E Aufgaben anzureichern war viel geschickter. So konnten wir uns mit den Prozessverantwortlichen auf einer Augenhöhe unterhalten. Dennoch war die Diskussion nicht einfach.

10 10 Nützlich beim Einführen von RM&E: Ein dickes Fell Knorr-Bremse Group 11 Folie 10: Nützlich beim Einführen von RM&E: Ein dickes Fell 37 Du meinst, man braucht ein dickes Fell? Dickes Fell Flyer und Poster Ja, das braucht man. Am Ende waren es aber Eure eigenen Experten, die die Ideen mit den Arbeitsmaterialien, wie Flyer und Poster eingebracht haben. Auch das war eine sehr gute Idee. >> HOOD- Ordner auf dem Tisch zeigen, mit dem Flyer wedeln

11 11 Motivation und Kommunikation Flyer und Poster informieren über Grundlagen, neue Prozessschritte und Qualitätskriterien Knorr-Bremse Group Folie 11: Motivation und Kommunikation 38 Ja, das ist wahr. Das war eine gute Taktik, den Mitarbeitern in Form eines Flyers, die ersten Werkzeuge an die Hand zu geben. >> auf Folie 11 eingehen. Hier war auch wieder hilfreich, dass wir die ITIL Welt auf unsere Prozesswelt abgebildet haben. Auf dem nächsten Bild sieht man das deutlicher: 11

12 12 Transistion Prozesse Überblick der ShS-Prozesse angelehnt an ITIL V3 Die grundlegenden Elemente finden sich im angewandten IT Betrieb wieder Design Transition Operation Knorr-Bremse Group 12 Folie 12: Überblick der T/PI4-Prozesse angelehnt an ITIL V3 39 Beispiel Change Management 40 Richtig. Das Change Management ist ein ganz zentraler Prozess. Hier werden angefragte Veränderungen zu bestehenden operativen s beurteilt und eingeschätzt, bevor sie genehmigt und koordiniert umgesetzt werden. >> Auf Bild 12 eingehen Als besonders interessant empfinde ich die positive Einflußnahme auf Euren zentralen Transition Prozesse, also Change- Management und Release & Deployment Management. Assess - Authorize Coordinate das sind z. B. die hauptsächlichen Schwerpunkte im Change Management Prozeß nach ITIL.

13 13 Leitfragen für das Change Management in der IT Assess Request for Change (RFC), Authorize RfC, Coordinate Changes Transition Abstraktionsebenen im RM&E Why? Who or what...? What? To whom...? When? How? Abstraction layer x+1 Abstraction layer x Abstraction layer x-1 7 R s bei ITIL 1. Who Raised the change 2. What is the Reason for the change? 3. What is the Return required? 4. What are the Risks involved? 5. Which Ressources are required? 6. Who is Responsible to Build, test, implement the change 7. What is the Relationship between this change and other changes? Knorr-Bremse Group 13 Folie 13: Change Management - Ein Transition Prozess 41 Gesprächsleitfaden Change Request Single Point of Contact 42 Die W-Fragen und die 7 R s 43 Change ohne nochmalige Rücksprache Damit in diesen Prozessschritten die Kundenanforderungen nicht aus dem Blickwinkel geraten, haben wir einen Leitfaden entwickelt, der sicherstellen soll, dass die relevanten Informationen mit dem Kunden diskutiert werden. Die konsequente Einhaltung des Prinzips Single Point of Contact war ein weiterer Baustein. Beides hat geholfen, bei beiden Seiten den Blick für die Anforderungen zu schärfen. Der Mitarbeiter im First oder Second-Level Support ist nun trainiert, Anforderungen als Eingangsinformation für einen Change Request in der notwendigen Qualität zu erheben. Damit ist es jetzt möglich, einen Change zu beurteilen und freizugeben oder abzulehnen, ohne mit allen Beteiligten noch einmal persönlichen Kontakt aufnehmen zu müssen. Ja hierzu waren sowohl die W-Fragen über die Abstraktionsebenen hilfreich wie auch die 7 R s. >> Folie 13

14 14 44 Benefit = Zeitersparnis + Impact Analysis 45 Benefit = Traceability möglich 45 a Benefit = Synergien für Release Mgmt 46 Release Notes 47 Blueprint in Kundensprache liefert Inhalt für Release Notes 48 Test Management? Das sehe ich auch, daß setzt aber voraus, daß im System ersichtlich ist, welche Changes umgesetzt wurden und welche nicht,...! Verglelich von Lösungen mit alten und neuen Kundenanforderungen... das würde uns in der Zukunft in die Lage versetzen, welche... Voraussetzung dass alles dokumentiert ist... vor allem die Zusammenhänge. Klasse sind auch die Effizienzsteigerungen im Release Management Prozess. Nun dadurch, daß im Rahmen des Blueprinting die Anforderungen bereits so formuliert werden, daß Sie in Kundensprache verständlich sind und durch den Kunden ja auch als verständlich formuliert akzeptiert werden, können wir bereits an dieser Stelle beginnen, die Release-Notes zu generieren. Sie werden natürlich noch ergänzt um Screenshots aus dem Lösungssystem, aber im großen und ganzen werden die Release Notes bereits am Anfang des Projektes dokumentiert. Sie entsprechen einem Teil der Anforderungsspezifikation. Ich denke, das hat auch eine deutliche Zeitersparnis gebracht. Aber ich denke vor allem, daß die Zukunft hier noch einen wesentlichen Erfolgsfaktor hervorbringt nämlich die Risikominimierung durch die Unterstützung von Impact-Analysen; also Analysemöglichkeiten über Auswirkungen neuer geforderter Anforderungen am laufenden System auf bereits umgesetzte Anforderungen. Hier unterscheidet Ihr Euch doch wesentlich von den Prozessen der Systementwicklung, die nicht auf das laufende System aufsetzen, sondern die Erkenntnisse in neue Produkte stecken. Das ist übrigens eine ganz klasisches RM&E Vorgehen und ist auch wieder zu finden bei CMMI oder Spice.. Ach ja davon hast Du noch gar nicht berichtet. Konntet Ihr die Last des Verantwortlichen für die Release Notes, also für die in Kundensprache formulierten.veränderungen am System, reduzieren? Wie macht sich das durch die Einbindung von RM&E bemerkbar? Super, macht Ihr das beim Test Management genau so elegant?

15 15 Release Management verändert sich durch ITIL V3 und RM&E Design Transition = Test Management + Release & Deployment Operation NEU! Knorr-Bremse Group 13 Folie 13: Release Management verändert sich durch ITIL V3 und RM&E 49 Test Management jetzt als eigener Prozess neben Release Mgmt. Abnahmekriterien als Q-Maßnahme Ja, schau mal -. >> Eingehen auf die Slide-Darstellung., wir haben auf Euer Anraten hin den bisherigen Release Management Prozess gemäß ITIL V3 unterteilt: Jetzt ist Test Management und Validierung ( Prüfung) als separater Prozess neben Release und Rollout (Deployment) aufgesetzt worden. Auf diese Weise kann das Test Management früher beginnen und als qualitätssichernde Maßnahme in den Blueprint eingreifen. Die Definition der Abnahmekriterien für die Validierung schafft zusätzliches Verständnis zwischen Kunde und Entwickler.

16 16 Einflussfaktoren für die Einführung von IT Management Voraussetzung für die Einführung eines neuen IT s, z. B. eines neuen Tools oder einer Toolfunktionalität, ist die Klärung der sechs wesentlichen Einflussfaktoren 1. Management und Mitarbeiter Wie sieht die zugrunde liegende Organisationsstruktur aus? 2. Kunde und Anwender Wer ist der Vertragspartner und für wen ist die Leistung bestimmt? 3. Geschäftsprozesse des Kunden Sind die Szenarien definiert, die in den Geschäftsprozessen durch die IT unterstützt werden müssen? 4. Kultur and Organisation Welche kuturellen und organisatorischen Hintergründe müssen berücksichtigt werden? 5. Processmodell Mit welchem Prozessmodell wird die IT seine leistungen dem Kunden gegenüber erbingen? 6. IT Management Toolset Welche Wekzeuge unterstützen die IT in ihren Prozessen? Knorr-Bremse Group 14 Folie 14: Erfolgsfaktoren für die Einführung von IT Management (ITSM) 50 Einflussfaktoren für IT Mgmt. Tja alles Faktoren, die zu einer geringeren Kundenzufriedenheit führen können. Die Erfolgsfaktoren für ein gesundes Projekt im ITIL Umfeld sind auf verschiedenen Fundamenten aufgebaut. Kennst Du diese Liste, die aus dem ITIL Umfeld stammt.. >> Eingehen auf die Slide-Darstellung. Die gilt doch auch bei Euch! 50 Checkliste für Prozessorientierung Ja, diese Liste dient jetzt als Leitfaden für neue Projekte. Die Punkte 1 bis 4 geben wir dem Kunden als Hausaufgaben für die Projektdefinition mit. Auf diese Weise vermeiden wir es beispielsweise, Lösungen für nicht-existente Geschäftsprozesse zu implementieren. Die Punkte 5 und 6 sind mehr unsere Hausaufgaben 51 Super da ist das Leben doch leichter geworden, oder? 52 Im Umgang mit Kunden mit einem gewissen Prozessbewusstsein schon, ja. An den anderen arbeiten wir noch ;-) 53 RM&E Tool? Habt Ihr mittlerweile auch eine Tool- Unterstützung für RM&E.

17 17 54 Erst einmal Prozesse und RQ Qualität Tool für Traceabilty An dieser Stelle sind wir noch nicht so weit. Momentan fokussieren wir uns auf die neuen Prozesse und auf die Hebung der inhaltlichen Qualität. Die Instrumente haben wir vorerst belassen, um das Team nicht gleich an zwei Fronten zu belasten. Das Tool wird aber spätestens für das Thema Traceability interessant. RM&E-angereicherte IT-Projects Die Blueprint-Vorlage stellt die Verankerung im Lebenszyklus der s von Beginn an sicher. Design Operation Knorr-Bremse Group 15 Folie 15: IT-Projects auch ohne RM-Tool RM&E-hochwertig 55 Im Bereich IT-Projects haben wir ja bereits Tool-unabhängig ein Spezifikationstemplate entworfen. Hier hat der Konzeptionist (Solution-Architekt) bereits mit Hilfe eines Word-Dokuments Gelegenheit, Anforderungen im geforderten Qualitätsniveau zu erreichen. >> Folie 15

18 18 Fortsetzung folgt Über weitere Themen, wie Problem Management und Incident Management, sowie über die Erfahrungen aus dem Rollout soll an anderer Stelle berichtet werden... Design Transition Operation Knorr-Bremse Group 18 Folie 15: IT-Projects auch ohne RM-Tool RM&E-hochwertig 56 Abspann 57 Incident / Problem Mgmt beim nächsten Mal Folie 19: Schlussfolie vielen Dank. Ich freue mich auch bereits auf das nächste Wiedersehen. Vielleicht kann ich dann mit Dir über die Hotline-Themen (also Prozesse Incident und Problem Management) sprechen und wie wir hier Synergien mit dem RM&E aufbauen können. Potential sehe ich jetzt schon einiges., es war wunderbar, Dich wieder getroffen zu haben. Ich bin gespannt, in welchen Einsatzfeldern RM&E noch als Baustein bei Euch integriert wird und ich freue mich, wenn wir uns bald wiedersehen. ENDE

19 Begriff Definition Glossar Cost Center Quelle: Wikipedia, der freien Enzyklopädie Ein Cost Center ist eine aus dem Englischen übernommene Bezeichnung für eine eigenständige Unternehmenseinheit (Business Unit), die normalerweise ein Budget zur Verfügung hat, um dessen Ziele zu erreichen. Es hat zwar eine oder mehrere Kostenstellen, ist aber nicht synonym zu verstehen. In einem Cost Center ist der Unternehmensteil nur für die Kosten seines Bereiches verantwortlich, eine Erweiterung ist das Profit Center. Der Leiter eines solchen Cost Centers legt normalerweise einen eigenen Businessplan vor, der mit der Geschäftsleitung (GL) besprochen und genehmigt wird. Das Cost Center agiert dann mehr oder weniger unabhängig. Die Vorgabe aus der GL ist nicht am Gewinn, sondern an den Kosten ausgerichtet. Somit wird keine separate Gewinnermittlung für das Cost Center gemacht, sondern nur die "Kosten" auf dieses gebucht. Denkbar ist beispielsweise die Marketingabteilung eines Unternehmens als Cost Center zu führen, eine Kostenverantwortung ist möglich, eine Zurechnung von Erlösen, wie etwa beim Investment Center oder beim Profit Center, eher schwierig. Ein Cost Center stellt in der Regel einen größeren Verantwortungsbereich dar und umfasst deshalb meistens mehr als eine Kostenstelle. Center V-Modell Quelle: Wikipedia, der freien Enzyklopädie Ein -Center ist ein Dienstleistungsbereich und umfasst eine oder mehrere Kostenstellen, die keine eigenen Erträge mit Kunden erwirtschaftet, sondern Leistungen für andere Kostenstellen (bzw. Unternehmensbereiche) erbringt, die dann auch intern verrechnet werden (Innerbetriebliche Leistungsverrechnung). Ein Beispiel für eine typische Tätigkeit eines -Centers ist Forschung und Entwicklung. Quelle: 1.2/Dokumentation/pdf/V-Modell-XT-Teil1.pdf Das V-Modell ist als Leitfaden zum Planen und Durchführen von Entwicklungsprojekten unter Berücksichtigung des gesamten Systemlebenszyklus konzipiert. Dabei definiert es die in einem Projekt zu erstellenden Ergebnisse und beschreibt die konkreten Vorgehensweisen, mit denen diese Ergebnisse erarbeitet werden. Darüber hinaus legt das V- Modell die Verantwortlichkeiten jedes Projektbeteiligten fest. Das V- Modell regelt also detailliert, "Wer" "Wann" "Was" in einem Projekt zu tun hat. Andere Richtlinien wie ISO-Standards sind zur Zeit in Gebrauch, aber im Vergleich zum V-Modell weniger konkret, da sie beispielsweise keine Produktvorlagen vorgeben.

20 Begriff Definition Die standardisierten methodischen Vorgaben des V-Modells ermöglichen es, auch komplexe und umfangreiche Projekte systematisch durchzuführen. Dadurch werden Projekte besser plan- und nachvollziehbar und erzielen zuverlässiger Ergebnisse von hoher Qualität, was sowohl für den Auftraggeber als auch für die Auftragnehmer von Vorteil ist. Die in Projekten erforderliche Kooperation zwischen Auftraggebern und Auftragnehmern wird ebenfalls vom V-Modell geregelt. Dabei werden die Verantwortlichkeiten für beide Seiten festgelegt. Die Vorgaben des V- Modells bilden daher eine wesentliche Grundlage für die Verträge zwischen Auftraggebern und Auftragnehmern. Das V-Modell fördert zudem die Vergleichbarkeit von Angeboten. Auch kleine und mittelständische Unternehmen profitieren vom V-Modell. Es bietet ihnen die Möglichkeit, auf standardisierte und erprobte Vorgaben für Entwicklungs- und Managementprozesse zurückzugreifen. So können auch kleinere Unternehmen mit überschaubarem Aufwand ihre eigenen Vorgehensweisen systematisieren und dadurch zuverlässig hochwertige Entwicklungsergebnisse erzielen. Kundenzufriedenheit Das V-Modell dient somit als Vertragsgrundlage, Arbeitsanleitung und Kommunikationsbasis. Quelle: Wikipedia, der freien Enzyklopädie (... Auszug) Bei der Kundenzufriedenheit spielt unter anderem die Qualität der Produkte oder Dienstleistungen und die Möglichkeit von Alternativen eine Rolle. Die Kundenzufriedenheit ist eine vom Kunde wahrgenommene Erfüllung sowohl seiner selbstverständlichen Erwartungen (Basisanforderungen) wie auch seiner ausdrücklich geäußerten Wünsche (Leistungsanforderungen). Basisanforderungen Zu diesen zählen alle Leistungskomponenten, deren Erfüllung der Kunde einfach voraussetzt und nicht anspricht. Werden sie nicht erfüllt, macht das den Kunden unzufrieden. Grundanforderungen werden vom Kunden für selbstverständlich gehalten. Werden diese übertroffen, so honoriert der Kunde diese Leistung in der Regel nicht. Leistungsanforderungen Dabei handelt es sich um vom Kunden ausgesprochene Erwartungen (Spezifikationen) und messbare Leistungsanforderungen. Entsprechen sie den Erwartungen nicht voll, kommt Unzufriedenheit auf - werden die Erwartungen übertroffen, steigt die Zufriedenheit. Leistungsanforderungen können mit den klassischen Methoden der Marktforschung (mündliche oder schriftliche Befragungen) erfasst

21 Begriff Definition werden. Kano-Modell Die Kano-Analyse stellt eine Methode dar, um Kundenanforderungen zu strukturieren und ihren Einfluss auf die Zufriedenheit der Kunden zu bestimmen. Wer einfach Kundenwünsche erfüllt, hat das Risiko, die verschiedenen Aspekte von Kundenanforderungen zu ignorieren. Ein Unternehmen verfolgt z.b. eine immer höhere Produktqualität, die so von den Kunden gar nicht gewollt ist. Kunden haben Erwartungen an ein Produkt/eine leistung. Erfüllen sich diese nicht nach dem Kauf des Produktes werden die Kunden unzufrieden. Oder sie sind statt begeistert gleichgültig. Kano unterscheidet Kundenanfordungen in drei Gruppen, da eine Erfüllung/Nichterfüllung dieser drei Arten von Anforderungen einen unterschiedlichen Einfluss auf die Kundenzufriedenheit hat. Die drei Kundenanforderungen Das Modell geht von drei verschiedenen Arten der Erwartung aus: 1. Basisanforderungen (expected requirements) Basisanforderungen sind so selbstverständlich, dass sie vom Kunden nicht extra benannt werden. Würde ein Unternehmen diese bewerben, würde es albern wirken. Große Anstrengungen, diese Basisanforderungen zu verbessern, lohnen sich nicht. Erst wenn diese Anforderungen nicht erfüllt werden, fallen sie dem Kunden auf und er ist unzufrieden. Beispiel: das Telefonsignal. Es wird als selbstverständlich erachtet und fällt nur auf, wenn es nicht kommt. 2. Leistungsanforderungen (normal requirements) Dies sind grundlegende Anforderungen, deren Nichterfüllung zu massivem Unmut beim Kunden führt. Erfüllung führt zu Zufriedenheit. Gibt sich ein Unternehmen bei der Erfüllung besondere Mühe, kann es hier Kunden binden. Beispiel: Preis, Lieferservice, Reparaturservice 3. Begeisterungsanforderungen (delightful requirements) Dies sind latent vorhandene Anforderungen, die die Kunden häufig nicht einmal beschreiben können. Kann ein Unternehmen einen unerwarteten Zusatznutzen bieten, sind die Kunden begeistert. Beispiel: Die Post-It von 3M. Bis es sie gab, konnte niemand die konkreten

22 Begriff Definition Anforderungen formulieren, obwohl viele sicherlich gerne etwas ähnliches gekauft hätten. Seit Post-It auf dem Markt ist, ist es ein großer Erfolg.