Fragen, die in diesem Kapitel beantwortet werden:
Welche Aufgabenbereiche umfasst das Relationship Management?
Welche speziellen Herausforderungen und kritischen Schnittstellen existieren bezüglich Relationship Management im aktuellen Marktumfeld?
Welche Vorteile und Potenziale lassen sich durch zielgerichtetes Relationship Management erschließen?
Welche Stakeholder können identifiziert werden und wie sind diese in Informationsflüsse und Entscheidungen einzubinden?
Welche Konzepte, Instrumente und Methoden werden im Customer Relationship Management eingesetzt und können auch für die Beziehung von IT-Organisationen zu den Fachbereichen (als Kunden) genutzt werden?
Was sind die Prinzipien eines erfolgreichen Requirement Engineering und wie kann dieses organisiert werden?
Welche Best-Practice-Modelle für das Relationship Management können Anregungen für den Aufbau einer eigenen Relationship-Management-Organisation liefern?
Welche potenziellen Beiträge kann Digitalisierung zur Steigerung der Effektivität und Effizienz des Relationship Management leisten?
| 20.1 | Einordnung und Ausblick |
Relationship Management als ganzheitliches Konzept umfasst alle Arten von Beziehungen eines Unternehmens. Dies sind primär die businessrelevanten Beziehungen zu Kunden, Lieferanten und Wettbewerbern, darüber hinaus auch die Beziehungen zu den Stakeholdern im weiteren Sinne. Dazu zählen alle internen und externen Anspruchsgruppen, die von den Tätigkeiten des Unternehmens gegenwärtig oder in Zukunft direkt oder indirekt betroffen sind.
Oftmals wird Relationship Management ausschließlich im Zusammenhang mit Kundenbeziehungen verwendet. Ein alle Stakeholder umfassendes Beziehungsmanagement fehlt in den meisten IT-Organisationen. Relationship Management ist mehr als nur die Einrichtung einer Account-Manager-Rolle zur besseren Kontaktpflege mit dem Kunden. Für den Aufbau nachhaltiger Kooperationen und Netzwerke ist die Einbeziehung der Supplier (Lieferanten) sowie aller Stakeholder von großer Bedeutung.
Die IT als Serviceorganisation weist hinsichtlich ihrer Kunden- und Lieferantenbeziehungen eine Reihe von Besonderheiten auf. Aufgrund der vielfach hohen technischen und organisatorischen Komplexität von IT-Systemen und -Lösungen besitzt die klare Abstimmung und Definition von Anforderungen (Requirements Engineering) hier besondere Bedeutung.
Wir behandeln deshalb das Relationship Management in einem umfassenden Sinn, unter Einbeziehung von Kunden, Lieferanten und Stakeholdern im Umfeld der Business-IT.
| 20.2 | A spekte eines Relationship Managements |
Relationship Management (dt. Beziehungsmanagement) baut Bindungen zu wesentlichen Kunden, Lieferanten und anderen Stakeholdern auf. Dadurch können Nutzeffekte in unterschiedlicher Hinsicht erreicht werden:
Kundenbindung bringt vor allem Akzeptanzvorteile und führt zu einer höheren Kundenzufriedenheit. Gleichzeitig können Kostenvorteile erzielt werden, da die Kosten für die Erhaltung eines vorhandenen Kundenstamms geringer sind als jene für die Gewinnung neuer Kunden.
Eng verbundene Lieferanten können besser und flexibler auf die Anforderungen des Unternehmens eingehen und Leistungen in besserer Qualität erbringen.
Stakeholder im Umfeld des Unternehmens haben positiven Einfluss auf die öffentliche Wahrnehmung von Aktivitäten und können bei einer entsprechenden Einbeziehung Entscheidungen erleichtern und beschleunigen.
Relationship Management zielt auf einen möglichst guten Ausgleich zwischen der Nähe bzw. Bindung zu Partnern (Kunden, Lieferanten) und der dazu im Konflikt stehenden Anforderung einer weitgehenden Unabhängigkeit. Diese Ziele sowie das Spannungsverhältnis sind im nachfolgenden Bild 20.1 (Zielsystem des Relationship Management) dargestellt.
Bild 20.1 Zielsystem des Relationship Management
Eine engere Kooperation mit Partnern ermöglicht eine bessere Abstimmung, eine effektivere Ausschöpfung von Geschäftspotenzialen sowie die Nutzung gemeinsamer Wachstums- und Erfolgspotenziale.
Beziehungsmanagement dient im Wesentlichen der Erhöhung der Beziehungssicherheit. Durch stabile, langfristig ausgerichtete Beziehungen (etwa zu Lieferanten) reduziert sich der Aufwand für die Suche, Auswahl und Bewertung von Geschäftspartnern. Mit einer entsprechenden Zusammensetzung und Streuung der Partner in einem Netzwerk kann außerdem die Abhängigkeit von bestimmten Partnern reduziert werden.
Durch den Aufbau und die Pflege von effektiven Beziehungen können darüber hinaus Innovationspotenziale erschlossen werden. Die Einbindung von Partnerkompetenzen erschließt potenziell Zugänge zu Technologien und Entwicklungen, die für einen der Partner isoliert nicht vorhanden sind.
Durch Synergieeffekte aus der Zusammenlegung von Ressourcen können Größen- und Erfahrungskurveneffekte genutzt, durch Bündelungen in Beschaffung, Transport und anderen Bereichen eine bessere Verhandlungsposition erreicht und Transaktionskosten bei der Geschäftsabwicklung reduziert werden. Daraus ergeben sich Kosten- bzw. Wirtschaftlichkeitsvorteile. Positive Bündelungseffekte in Form von Kosten- und Zeitersparnis können auch durch Konsolidierung der Lagerbestände, Standardisierung und Normung sowie Entfall von Doppeltätigkeiten erreicht werden.
| 20.3 | A ufgabenfelder des Relationship Management |
Der Zweck des Relationship Management ist allgemein die Gestaltung und Nutzung der Beziehungen zu Kunden, Lieferanten und anderen Stakeholdern im Geschäftsumfeld des Unternehmens. Die Aufgaben umfassen:
Identifikation relevanter, für die eigene Organisation bedeutsamer, Stakeholder,
Bewertung von deren Bedeutung für die Aktivitäten des Unternehmens,
Identifikation der Bedürfnisse/Anforderungen bestehender und potenzieller Kunden,
Sicherstellung der Erfüllung dieser Bedürfnisse durch geeignete Produkte und Services,
Aufbau und Pflege der Beziehungen zu Lieferanten,
Aufbau und Pflege der Beziehungen zu anderen relevanten Stakeholdern (Behörden, Berufsvereinigungen, Anrainern etc.).
Die Aufgabenbereiche des Relationship Management lassen sich in drei Phasen darstellen.
In der ersten Phase gilt es, die möglichen und tatsächlichen Partner zu identifizieren, Informationen über sie zu gewinnen und die relevanten Beziehungsnetzwerke aufzubauen. Ein Partner-Portfolio definiert die Profile geeigneter wählbarer Partner. Diese werden in der Folge aufgrund einer Markt- und Umfeldanalyse identifiziert. Kunden sind vielfach durch den organisatorischen Kontext vorgegeben, die IT hat es vielfach mit internen Kunden zu tun und tritt nicht am freien Markt auf. Lieferanten und weitere Kooperationspartner sind hingegen zu bewerten und auszuwählen. Dazu müssen Informationen über die Marktstellung und organisatorischen Strukturen der jeweiligen Organisationen und deren Potenziale (insbesondere im Hinblick auf mögliche Synergien) gewonnen werden.
Für attraktiv erscheinende Partnerunternehmen werden mögliche Kooperationsformen (von einfachen Transaktionen bis hin zu Entwicklungspartnerschaften) entwickelt und mit diesen abgestimmt. Durch den Aufbau von Netzwerken können über mehrere Partner hinweg Potenziale erschlossen und Wettbewerbsvorteile aufgebaut werden. So können etwa Modullieferanten als „Systemköpfe“ für umfassende Sublieferantennetzwerke eingesetzt werden. Innerhalb der Partner können Klassifikationen vorgenommen werden (Kundengruppen, „Key-Accounts“ oder Lieferantenklassen).
In der zweiten Phase geht es um die Ausgestaltung der Transaktionssysteme für die jeweiligen Geschäftspartner. Hier werden die Strukturen und Prozesse für die Abwicklung der Waren- bzw. Leistungsflüsse, der Informations- und Geldflüsse festgelegt.
Relevante Fragen sind die Ausgestaltung der Warenströme (z. B. Lieferung von Hardware), die Lagerung, die Verpackung sowie die Abwicklung von Retouren (Reklamationen, Verpackungsrückläufer), der Informationslogistik (IT-Vernetzung, elektronische Bestellsysteme, Austausch von Informationen) und der Zahlungsströme (Zahlungsziele, Rechnungs-/Gutschriftverfahren, elektronischer Zahlungsverkehr).
Auch die sozialen Beziehungen sind zu entwickeln, die Art des Umgangs auf persönlicher Ebene, institutionalisiert durch Treffen und Veranstaltungen.
Transaktionen können vertragsrechtlich in unterschiedlicher Weise organisiert werden. Das Spektrum reicht von unverbindlichen Absprachen über Rahmenverträge und Kooperationsvereinbarungen bis hin zu Joint Ventures (Gemeinschaftsunternehmen), in die einzelne Transaktionsprozesse ausgegliedert werden.
Die dritte Phase umfasst das operative Management der Transaktionen im Rahmen der Beziehungen, die kurzfristig anfallenden Aufgaben der Planung und Steuerung, der terminlichen Koordination und Disposition sowie die Behandlung von Sonderfragen, z. B. im Rahmen des Beschwerdemanagements. Auf dieser Ebene sind auch die physischen Transaktionen vorzunehmen, d. h. der Austausch von Gütern und Leistungen.
Wie im Bild 20.2 dargestellt, bestehen zwischen diesen Aufgabenfeldern Zusammenhänge und Feedback-Schleifen. Erkenntnisse und Erfahrungen aus der täglichen Arbeit fließen in die Gestaltung von Systemen, Prozessen und Verträgen ein bzw. beeinflussen die Art der Zusammenarbeit im Netzwerk.
Bild 20.2 Aufgabenfelder des Relationship Management
| 20.4 | R elationship Management – spezifische Anforderungen und Standards |
Beziehungen im Business-IT-Umfeld sind durch eine Reihe von Besonderheiten gekennzeichnet, die spezifische Anforderungen an die Gestaltung von Kooperationsbeziehungen stellen und die sich wie folgt beschreiben lassen:
IT-Vorhaben weisen typischerweise eine hohe Komplexität und Dynamik des Umfelds auf. Es bestehen starke Abhängigkeiten zwischen den Teilaufgaben sowie eine intensive Interaktion mit internen und externen Stellen. Das komplexe Zusammenspiel von betriebswirtschaftlichen, technischen und menschlichen Komponenten erfordert umfangreiche Kompetenzen, die oft nur mit Lieferanten und anderen Partnern gemeinsam bereitgestellt werden können.
Aufbau und Betrieb von IT-Services erfordern die fachübergreifende Zusammenarbeit verschiedener Fachbereiche. Daraus ergibt sich eine hohe Anzahl an Schnittstellen, deren Identifikation und klare Definition maßgeblich sind für eine erfolgreiche Umsetzung von Vorhaben.
Ziele und Anforderungen von Projekten verändern sich während der Umsetzung immer wieder, damit sind laufend Abstimmungen zwischen den beteiligten Partnern erforderlich.
IT hat vielfach neue Technologien zu entwickeln und Projekte mit einem hohen Innovationsgrad durchzuführen. Es entsteht die Notwendigkeit, intern vorhandenes Know-how durch den Zukauf von Leistungen und Wissen zu erweitern.
Aus der ausgeprägten Technologieorientierung ergeben sich hohe Risiken, deren Eintrittswahrscheinlichkeit nur durch genaue Planung, Kontrolle und konsequent durchgeführte Tests reduziert werden kann.
IT-Services sind stark von qualitativen Aspekten bestimmt und damit in ihrem Erfolg oft schwer messbar. Gleichzeitig hat die Einführung meist mittel- und langfristige Konsequenzen. Eine Life-Cycle-Orientierung ist erforderlich, über die Anfangsinvestitionen hinaus sind die zukünftigen Wirkungen zu beachten. Dies bedeutet auch, dass Beziehungen zu Kunden und Lieferanten nicht punktuell mit der Einführung von Lösungen enden, sondern auf eine längerfristige Kooperation hin aufgebaut sein müssen.
Die für das Management von IT-Service-Organisationen relevanten Standards beziehen sich explizit auf das Management der Beziehungen zwischen IT-Organisation und deren Partnern und stellen für dieses Rahmen und Instrumente zur Verfügung. Die aktuelle Fassung der IT Infrastructure Library (ITIL 2011) umfasst die Disziplin Business Relationship Management (BRM) als eigenständigen ITIL-Prozess, in ähnlicher Weise erfolgt dies auch im Kontext des Normenwerks ISO/IEC 20000.
ITIL formalisiert im Rahmen des Prozesses Business Relationship Management (BRM) die Rolle, die Aufgaben und Aktivitäten des Business Relationship Manager als Stimme des Service-Providers zum Kunden und als die des Kunden zum Service-Provider. Die Steuerung des Serviceangebots über deren Lebenszyklus sowie die Verantwortung für Preise und Verrechnungsmodalitäten der Services obliegt nach ITIL dem Service Portfolio Management (SPM). ITIL konzentriert sich damit vor allem auf die Prozesse des Customer Relationship Management (CRM) und geht nur wenig auf die Rolle der Lieferantenbeziehungen ein.
Business Relationship Management im IT-Umfeld zielt darauf, den Servicebedarf des Kunden zu identifizieren und aktiv zu befriedigen. Dazu ist es erforderlich, die Geschäftsabläufe und Anforderungen der Kunden zu verstehen und ein gutes Verhältnis zwischen dem Service-Provider und dem Kunden zu entwickeln und aufrechtzuerhalten. Bedarfe auf Kundenseite sind einem immer schnelleren Wandel unterworfen. Dem sollten sich auch die Services anpassen.
Business Relationship Management sollte an den Service-Lebenszyklus-Phasen ausgerichtet sein, um eine kontinuierliche Abstimmung mit den Kundenbedürfnissen und in weiterer Folge ein hohes Maß an Kundenzufriedenheit sicherzustellen. ITIL gibt dazu einige Hinweise:
Service-Strategie: Diese definiert die längerfristige Ausrichtung der Leistungsangebote und derer Übereinstimmung mit den Zielen und Anforderungen der Kunden.
Service-Design: In Zusammenarbeit zwischen Kunden und Design-Team werden die Inhalte, detaillierte Funktionalitäten und die Bedieneroberfläche des neuen oder zu ändernden Service festgelegt.
Service Transition: Der Kunde ist an Change-, Release- und Deployment-Aktivitäten beteiligt, sein Feedback wird laufend berücksichtigt. Die Kunden- und Anwenderakzeptanz wird im Rahmen des Prozesses Service Validation und Testing erhoben. Die Bereitstellung von geeigneten Testdaten erfolgt durch den Kunden.
Service Operation: In dieser Phase erfolgt die Bereitstellung der Services gemäß Service Level Agreement oder Vertrag. Störungen und Problemen werden erkannt und durch entsprechende Maßnahmen behoben oder verhindert.
Continual Service Improvement: In einem kontinuierlichen Verbesserungsprozess werden systematische oder spontan auftretende Probleme in der Anwendung der Services sowie Beschwerden des Kunden festgestellt und präventiv geeignete Abhilfemaßnahmen mit dem Kunden abgestimmt und umgesetzt.
Zu beachten sind die unterschiedlichen Zielsetzungen und Erwartungshaltungen von Kunden, Anwendern und Anbietern. Der Kunde möchte eine wirtschaftliche Preisgestaltung, er erwartet Profitabilität auf Basis definierter ROI-Kennzahlen, messbare Ergebnisse und neue Geschäftschancen durch innovative Lösungen. Der Anwender erwartet Leistung hinsichtlich Antwort- und Reaktionszeit, Stabilität, Verfügbarkeit, Sicherheit und Verlässlichkeit, eine hohe Anwenderfreundlichkeit von Benutzeroberfläche und Bedienung, außerdem eine stabile Arbeitsweise durch Konsistenz von Funktionen und Arbeitsweisen. Aus diesen oftmals divergenten Erwartungshaltungen können Konflikte entstehen, es müssen Kompromisse zwischen widersprüchlichen Faktoren gefunden werden.
Auf der Basis der angebotenen Services erfolgt die Planung und Kalkulation der benötigten Ressourcen. So können die Kosten der einzelnen Services berechnet und Preise festgelegt werden.
Praxistipp
Klar definierte und abgegrenzte Services fördern die Akzeptanz einer Verrechnung von Service auf der Seite der Kunden. Die Transparenz der Leistungsangebote und Verrechnungsmodalitäten ist zu beachten. Für innerhalb eines Unternehmens erbrachte Leistungen empfiehlt es sich, eine interne Leistungsverrechnung zu etablieren.
Das Service-Portfolio bildet die Schnittstelle zwischen Service-Provider und Kunden. Dieses muss daher aktiv gemanagt und weiterentwickelt werden. Es ist an der Unternehmensstrategie auszurichten und sollte auf seinen Wertbeitrag zum Geschäft bewertet werden. Services müssen – in gleicher Weise wie Produkte – über ihren gesamten Lebenszyklus betrachtet werden, es bedarf laufender Entscheidungen, welche Services betrieben, neu aufgenommen oder nicht mehr angeboten werden.
| 20.5 | Stakeholder Management |
Stakeholder (Relationship) Management umfasst alle Bestrebungen, die Beziehungen eines Unternehmens zu seinen wichtigsten Anspruchsgruppen zu gestalten. Stakeholder sind alle Gruppen, die das Erreichen der Unternehmensziele beeinflussen können, oder solche, die Ansprüche an das Unternehmen haben.
Ausgehend von einer Umfeldanalyse werden unternehmensinterne und -externe Stakeholder identifiziert. Darüber hinaus werden auch weitere Einflussfaktoren analysiert, die für den Erfolg eigener Maßnahmen bestimmend sein könnten. Eine beispielhafte, nicht vollständige Aufstellung zeigt die Tabelle 20.1.
Tabelle 20.1 Inhalte einer Umfeldanalyse
Unternehmensinterne Stakeholder |
Unternehmensexterne Stakeholder |
Sachlich inhaltliche Einflussgrößen |
|
|
|
Das Ergebnis der Umfeldanalyse ist eine Auflistung der betroffenen Umfeldgruppen (Stakeholder) mit einer Analyse der jeweiligen Erwartungen bzw. Befürchtungen. Daraus abgeleitet werden eine Analyse der sachlichen Einflussbereiche bzw. Projekte sowie ein Maßnahmenkatalog für die Bearbeitung der relevanten Umfeldgruppen. Entscheidend ist vor allem eine vollständige Berücksichtigung der betroffenen Bereiche bzw. die Abstimmung mit anderen Bereichen und Maßnahmen.
Bild 20.3 Stakeholder-Portfolio (Beispiel)
| 20.6 | Kundenmanagement und IT-Marketing |
In der Mehrzahl der Unternehmen liegt der Fokus des Relationship Management auf dem Customer Relationship Management (CRM), dem Management der Kundenbeziehungen.
CRM zielt darauf, die Beziehung des Unternehmens zu seinen Kunden aufzubauen und zu entwickeln. Dadurch soll eine bessere Erfüllung von Kundenbedürfnissen erreicht werden und eine stärkere Bindung der Kunden an das Unternehmen.
Über Kundenzufriedenheitsumfragen und die systematische Erfassung und Behandlung von Beschwerden werden die Bedürfnisse bestehender und potenzieller Kunden festgestellt und Problembereiche aufgespürt. Auf diese Ergebnisse aufbauend wird angestrebt, dass Bedürfnisse mit bestehenden oder neu zu entwickelnden Services erfüllt werden.
Customer Relationship Management umfasst neben der Identifikation von Kundenbedürfnissen und der Pflege der Kundenbeziehungen die folgenden weiteren Prozesse:
Pflege des Kundenportfolios (Erfassen und Aktualisieren aller Kunden der IT-Organisation)
Identifikation der Service-Anforderungen (Service-Ergebnisse, Service-Level-Ziele, ausgedrückt in der Sprache des Kunden)
Vorbereitung, Abschluss und Verwaltung von Kundenverträgen (Entwicklungsleistungen, Standard-Services, erweiterte Services)
Durchführen von Kundenzufriedenheitserhebungen (Umfragen planen, durchführen und auswerten)
Bearbeiten von Kundenrückmeldungen (Erfassung und Analyse von Beschwerden und positiven Rückmeldungen)
Überwachen von Kundenbeschwerden (Statusinformation zu Beschwerden, Einleiten von Maßnahmen)
Definition und Ermittlung von Kennzahlen (Key Performance Indicators, KPIs) zu Kundenbeziehungen
Die IT-Organisation sowie die IT-Verantwortlichen haben unternehmensintern oft einen schweren Stand – selbst wenn die Performance stimmt. Deshalb betreiben viele IT-Verantwortliche – das IT-Management sowie weitere Teilbereiche – heute ein aktives Reputationsmanagement. Das Selbstverständnis der IT und die interne sowie externe Kommunikation sind zunehmend ein essenzieller Bestandteil des „IT-Managements“.
Von vielen IT-Lösungen (z. B. neu eingeführte IT-Systeme, vorgenommene Veränderungen an den Applikationen, Möglichkeiten zur Nutzung von Mobile Devices) erfahren in der Praxis die meisten Mitarbeiter der Fachbereiche, das General Management und sogar die Unternehmensführung oft nur wenig oder gar nichts. Das hat vor allem zwei Ursachen: Kaum ein IT-Experte (Mitarbeiter aus dem IT-Bereich) informiert die Fachbereiche so, dass sie auch ohne Kenntnis des Fachchinesischen verstehen, worum es geht und welche Bedeutung die betreffenden IT-Lösungen (IT-Applikationen, Mobile Devices etc.) für das gesamte Unternehmen oder für eine einzelne Fachabteilung haben. Der zweite Grund für die Ahnungslosigkeit folgt direkt aus dem ersten: Wenn Management und Mitarbeiter der Fachbereiche die Bedeutung der IT nicht erkennen können, interessieren sie sich nicht dafür. Und das muss sich gerade im Zeitalter der „Digitalen Transformation“ bzw. des Business-IT-Managements rasch ändern.
An dieser Stelle könnte ein IT-Marketing auch für die IT-Produkte bzw. IT-Systeme und IT-Services direkt ansetzen. Die Dinge, die die IT für das Unternehmen und die Kunden leistet, so zu erklären, dass Kunden dies auch verstehen, ist keine einfache Aufgabe. Da sind zum einen natürlich die vielen technischen Begriffe und Zusammenhänge, die für einen Laien erst einmal übersetzt werden müssen. Die Frage, wie viel IT-Wissen dabei vorausgesetzt werden darf, ohne dass sich Mitarbeiter und Manager dumm vorkommen, bildet einen zusätzlichen Unsicherheitsfaktor.
Zum anderen stellt sich aber auch die Frage, was die IT-Abteilung in letzter Zeit unmittelbar Spürbares für Kunden und Mitarbeiter geschaffen hat. Deshalb sollte sich das IT-Management vor dem „Wie“ und „Wie häufig“ zuallererst die Frage stellen, was für Kunden und Mitarbeiter der Fachbereiche Nutzen stiften kann.
Ein Marketingkonzept zu den IT-Produkten und IT-Services sollte möglichst alle Zielgruppen mit einschließen, um eine hohe Akzeptanz zu erhalten.
Im Kern sind folgende Handlungsfelder im IT-Marketing zu unterscheiden:
Im Bereich der Unternehmensführung gilt es, das gewünschte Produkt entsprechend darzustellen und dem Mentor eine Argumentationshilfe zu geben.
Beim Management der Leistungsabnehmer muss ein Verständnis erzielt und damit die entsprechende Akzeptanz gewonnen werden.
Der Unternehmensöffentlichkeit ist das jeweilige IT-Produkt entsprechend darzustellen, um unkontrollierte Gerüchte zu vermeiden.
Als Ansatz für konkrete Programme eines IT-Marketings kann die Definition des klassischen Marketing-Mix dienen. Im Englischen orientiert man sich hierfür an den 4 Ps: Product, Price, Place, Promotion. Im Deutschen entspricht dies der vergleichsweise sperrigen Formulierung Produkt-/Leistungspolitik, Preis-/Konditionenpolitik, Distributions-/Bereitstellungspolitik und Kommunikationspolitik (Bild 20.4).
Bild 20.4 Der klassische Marketing-Mix, angepasst
Nachfolgend ein Beispiel einer Ideenliste für interne Marketing-Maßnahmen des IT-Bereichs eines Unternehmens in Bezug auf den internen Kunden:
Teilnahme an den wöchentlichen Meetings verschiedener Gremien mit aktiver Präsentation aktueller IT-Themen (Vorstands-, AL-Ebene etc.)
Ein etwa alle vier Monate stattfindendes IT-Informations-Meeting mit der gesamten Belegschaft
Vorortbesuche in den einheimischen Werken (etwa einmal im Jahr) und bei den ausländischen Niederlassungen (zweimal jährlich), dabei Treffen auch mit Schlüsselanwendern
Regelmäßige Beiträge zu Mitarbeiterzeitungen und Intranet-News-Diensten
Regelmäßige Besprechung mit dem Vorstandschef
Etablierung eines IT-Lenkungsausschusses
Aktive Einbindung der Fachbereiche in die Budgetplanung
IT-Helpdesk-Newsletter und -Reporting
Jour-Fixes mit wichtigen Fachbereichen
Business-Dinner zusammen mit Anbietern und Projektmitgliedern aus dem Business
Aktives „Walking-around“, um den Business-Kollegen Gelegenheit zur Kontaktaufnahme zu geben
| 20.7 | Demand Management für IT-Lösungen |
Kundenanforderungen entstehen einerseits im Rahmen des laufenden Betriebs von IT-Systemen, hier geht es um die Unterstützung von betrieblichen Anwendungssystemen, um Helpdesk-Dienste oder E-Mail-Services, andererseits im Zuge von Projekten zur Neuentwicklung oder Verbesserung von bestehenden Lösungen.
Wir behandeln die erste Gruppe unter dem Schwerpunkt „Service Portfolio Management“, die projektbezogenen Anforderungen unter „Requirements Management“. Die Grenze zwischen den Aufgabenbereichen ist eine fließende, auch Projekte erfordern das Angebot von Diensten, während Dienste für die laufende Unterstützung vielfach aus Projekten entwickelt werden.
| 20.7.1 | Service Portfolio Management |
Das Business Relationship Management erhebt die Anforderungen externer und interner Kunden hinsichtlich neuer Services, erweiterter Funktionalitäten oder Performance-Verbesserungen bestehender Services. Das Service Portfolio Management als Organisationseinheit des Service-Providers definiert von der fachlichen Seite die Zusammensetzung der Services, die dem Kunden angeboten werden, und stellt die Schnittstelle zur internen Organisation der IT dar.
Damit soll sichergestellt werden, dass die IT einerseits auf die Anforderungen der Organisation ausgerichtet ist, dass aber gleichzeitig Standards und Wirtschaftlichkeitskriterien eingehalten werden. Das Entstehen von Insellösungen und ein Wildwuchs heterogener, inkompatibler Systeme sollen verhindert werden.
Das definierte Service Portfolio muss gegenüber den Kunden, aber auch in der internen Organisation und hinsichtlich erforderlicher Zulieferungen gemanagt werden. Über entsprechende Serviceverträge werden die Services auf Lieferantenseite gesteuert.
Die Services werden in Service-Katalogen verwaltet und sollen gegenüber den externen und internen Kunden so konsistent und präzise wie möglich beschrieben werden. Für die Klassifikation und Spezifikation von Services haben sich verschiedene architektonische Vorgaben entwickelt, die vielfach aus Best Practices abgeleitet wurden.
Eine Klassifikation von kundenorientierten Services kann nach der Struktur der Geschäftsprozesse des Kunden erfolgen, wohingegen Basis-Services den Arbeitsplatz oder die Kommunikation unterstützen. Ähnlich einer Stückliste in der industriellen Fertigung erfolgt die Dekomposition von Services in einzelne Sub-Services, eine Aufgliederung in einzelne Bausteine, die spezifische Aufgaben erfüllen und wie Module kombiniert werden können.
Das Service Portfolio Management fungiert als Service-Integrator und kombiniert eigene Dienste mit zugekauften standardisierten Infrastruktur-Services. Der hierarchische Aufbau der angebotenen Services fördert die Mehrfachverwendung von Funktionen und ist die Grundlage für deren Planung und Verrechnung. Die Kundenerwartungen (Ansprüche an Umfang, Qualität und Performance der Services) sind in Service Level Agreements (SLA) formuliert.
| 20.7.2 | Requirements Management |
Für das Umsetzen der Kundenorientierung muss ein professionelles Anforderungsmanagement etabliert werden. Für das Finden und sachgerechte Beurteilen der Kundenwünsche ist es dabei wesentlich, den Zweck zu verstehen, mit dem der jeweilige Kunde Anforderungen an die IT bzw. an die IT-Lösungen formuliert:
Was sind die Anlässe, aus denen heraus der Kunde ein neues IT-System bzw. eine neue bzw. veränderte Applikation möchte?
Welche Zielsetzungen verfolgt der IT-Kunde mit der Investition in neue bzw. veränderte IT-Lösung?
Was sind Erfolgskriterien für eine erfolgreiche Zusammenarbeit mit dem Kunden bei der Umsetzung seiner Wünsche und Anforderungen an die IT?
Inwiefern lassen sich die Anforderungen an die vom Kunden gewünschten Systeme und Lösungen konkretisieren?
Sollen IT-Leistungen kundengerecht erbracht werden, dann müssen auch die Leistungen bzw. Produkte der IT genau definiert sein. Ohne ein Leistungsverzeichnis ist auch ein Produktkatalog bzw. ein IT-Produktmarketing nicht möglich. So bietet es sich an, dass der IT-Produktkatalog allen Bedarfsträgern zur Verfügung gestellt wird. Auch dies trägt zur Erhöhung der Kosten- und Leistungstransparenz in der IT bei. Außerdem kann über Schritte zur Standardisierung ein Beitrag zur Kostensenkung geleistet werden.
Anforderungen (Requirements) sind Fähigkeiten, die ein Projektergebnis (Produkt oder Service) aufweisen sollte, um die Kundenanforderungen zu erfüllen. Eigenschaften (Features) sind demgegenüber Gruppen von Anforderungen, die es dem Kunden ermöglichen, Geschäftsziele (Business Goals/Business Needs) zu erreichen. Dies ist somit auf einer höheren Ebene als die Anforderungen. Für die Aufgabenbereiche und Prozesse der Abstimmung von IT-Lösungen auf die Bedürfnisse der Kunden werden jedoch gemeinhin die Begriffe Requirements Management und Requirements Engineering verwendet.
Requirements Management (RM) beschreibt eine Managementaufgabe für die effiziente und fehlerarme Entwicklung nach Kundenspezifikationen. Dies ist vor allem dort von Bedeutung, wo komplexe Produkte bzw. Systeme konzipiert werden und stark arbeitsteilig an deren Entwicklung gearbeitet wird.
Das Anforderungsmanagement zielt darauf ab, zwischen Auftragnehmer und Auftraggeber ein gemeinsames Verständnis über eine zu entwickelnde Lösung zu erreichen. Die gemeinsam definierten Dokumente dienen vielfach auch als vertragliche Basis für die weitere Umsetzung.
Somit umfasst Requirements Management die Prozesse der Analyse, Dokumentation, Verfolgung, Bewertung und Vereinbarung von Anforderungen mit relevanten Stakeholdern und die Kontrolle und Steuerung dieser Anforderungen im Rahmen von Projekten. Requirements Management findet kontinuierlich in allen Phasen eines Projekts statt. An dieser Stelle muss darauf hingewiesen werden, dass die Begriffe Requirements Engineering, Requirements Management, Requirements Analysis etc. in Normenwerken und Literatur teilweise unterschiedlich verwendet werden. Auf diese Diskussion wird hier verzichtet, wir verwenden Requirements Management als den umfassenden Begriff.
Aufgabenbereiche im Rahmen des Requirements Management sind:
Anforderungsdefinition
Anforderungsanalyse (Requirements Elicitation)
Anforderungsdokumentation (Requirements Documentation)
Anforderungsvalidierung (Requirements Validation)
Anforderungsverwaltung
Risikomanagement
Änderungsmanagement
Umsetzungsmanagement
Das Ergebnis der Anforderungsanalyse ist die Dokumentation der funktionalen Anforderungen (Funktionen, Daten, Verarbeitungslogik, Systemverhalten), der Qualitätsanforderungen (Antwortzeiten/Geschwindigkeit, Zuverlässigkeit, System- und Datensicherheit) sowie weiterer Rahmenbedingungen (Systemumgebung, technische und organisatorische Vorgaben, Wiederverwendbarkeit).
Um ein professionelles IT-Anforderungsmanagement in der Praxis zu realisieren, haben sich vielfach in den Unternehmen IT-Koordinatoren als Rollen bzw. Stellen etabliert. Dabei handelt es sich um Stellen/Rollen, die entweder im IT-Bereich angesiedelt sind oder auch dem Fachbereich zugeordnet sein können (synonym finden sich auch Bezeichnungen wie Key User, Power User, IT-Beauftragter, Fachkoordinator oder Business-Analyst). Besondere Merkmale, die der Rolle eines IT-Koordinators zugewiesen werden, sind:
IT-Koordinatoren bilden quasi eine „Drehscheibe zwischen IT-Organisation und Fachbereich“, indem sie die beiden Bereiche zusammenführen und wichtige Vermittlungsfunktionen wahrnehmen.
IT-Koordinatoren gewährleisten effiziente, harmonisierte und ganzheitliche IT-Lösungen.
IT-Koordinatoren sorgen für eine verbesserte Kooperation und Kommunikation von IT und Fachbereich.
IT-Koordinatoren sind vielfach nicht nur Vermittler zwischen den beiden Polen/Fronten, sondern gleichzeitig Innovatoren im technischen Wandel.
| 20.7.3 | Requirements-Management-Prozesse implementieren |
Eine systematische Anforderungsermittlung (englisch „Requirements Elicitation“) schafft die Basis, um eine Dokumentation sämtlicher Anforderungen (bzw. die Ausarbeitung der Anforderungsspezifikation) vornehmen zu können. Die Sammlung kann auch durch den Anwender getrieben sein, der Regelfall ist jedoch die Zusammenführung durch einen IT-Koordinator/Anforderungsmanager oder durch einen zuständigen IT-Systementwickler. Zu entscheiden ist:
Wer führt die Erhebungen verantwortlich durch bzw. welcher Personenkreis wird in die Anforderungserhebung einbezogen? Oft müssen Anforderungen auch kollaborativ über Abteilungs- und Unternehmensgrenzen hinweg gesammelt, kommentiert und erfasst werden. In diesem Fall ist eine geeignete Mischung der Beteiligten aus Vertretern der Fachbereiche und von IT-Experten sinnvoll – ggf. unter Steuerung der IT-Governance-Organisation.
Mit welchen Methoden sollen Erhebungen jeweils erfolgen? Zur Wahl stehen im Wesentlichen eine Dokumentenanalyse, Interviews, Einsatz der Fragebogentechnik, Beobachtungsmethoden sowie Gruppentechniken.
Zur Unterstützung der Anforderungserhebung kann spezielle Software für das Anforderungsmanagement genutzt werden. Auf diese Weise lassen sich
Anforderungen besser strukturieren,
Redundanzen bei der Formulierung von Anforderungen vermeiden sowie
Rückverfolgbarkeit der Anforderungen (wann und von wem?) relativ einfach ermöglichen.
Ergebnis ist vielfach, dass die Software automatisch eine entsprechende Anforderungsspezifikation als Ergebnisdokument erzeugen kann.
Erreicht werden soll damit, dass zwischen den Kunden der IT und den Entwicklern/Projektmitgliedern ein Einverständnis über die Anforderungen besteht, die eine neue bzw. eine modifizierte IT-Applikation erfüllen soll. Nachdem die Anforderungen ermittelt und dokumentiert wurden, werden eine Analyse und Bewertung der Anforderungen vorgenommen. Dieses Ergebnis wird dann entsprechend in einer Vereinbarung bzw. einem Lastenheft fixiert.
Die Phase „Analyse“ dient einmal der Konkretisierung und Priorisierung der Anforderungen an das im Pflichtenheft beschriebene IT-System. Teilergebnisse der Anforderungsanalyse können Sie in den Qualitätssicherungsplan einfließen lassen. Die Phase „Bewertung“ ist dann quasi eine Qualitätssicherung von Anforderungen und bezieht sich auf die Aspekte Verifikation und Validierung.
Die Verifikation gibt Ihnen eine Information, ob die Anforderungen im Kontext auf das zu entwickelnde System richtig spezifiziert wurden.
Die Validierung sagt demgegenüber aus, ob die richtigen Anforderungen an das System spezifiziert wurden. Aufgrund einer Untersuchung wird bestätigt, dass die besonderen Forderungen für einen speziellen beabsichtigten Gebrauch erfüllt werden können.
Mit der Systemspezifikation wird ein Dokument ausgearbeitet, das die Aufgaben, die das IT-System erfüllen soll (das „Was“), möglichst vollständig definiert. Letztlich werden darin fachliche Funktionen detailliert, konsistent, vollständig und nachvollziehbar beschrieben.
Praxistipp
Eine Anforderungsanalyse muss getragen werden vom wirklichen, ehrlichen Interesse der IT an den Bedürfnissen des Fachbereichs. Durch die Einführung und Umsetzung von geeigneten Vorgehensweisen im Anforderungsmanagement (u. a. Positionsbestimmung zu IT-Anforderungsmanagement im Unternehmen, Stakeholder-Analyse und Scope-Definition, Anforderungserhebung, Anforderungsanalyse, Anforderungsspezifikation, Anforderungsmodellierung, Anforderungsreviews) können Sie den Herausforderungen der Praxis nach Kunden- und Serviceorientierung in besonderer Weise Rechnung tragen.
| 20.7.4 | Lastenheft und Pflichtenheft |
Als Grundlagen der Anforderungsdefinition dienen Lastenhefte und Pflichtenhefte. In einer frühen Phase der Systementwicklung wird ein Lastenheft erstellt, in dem die grundlegenden Anforderungen an ein zu entwickelndes oder zu beschaffendes Software-System definiert werden. Vielfach werden hierfür synonym die Begriffe Lastenheft und Pflichtenheft verwendet.
In einer differenzierten Sicht wird ein Lastenheft in einer früheren Phase der Systementwicklung als das Pflichtenheft erstellt. Wir folgen dem Begriffsverständnis von Balzert (2009), der ein Lastenheft als Grob-Pflichtenheft sieht, das entsprechend weniger detailliert ist, in dem eine Konzentration auf fundamentale Eigenschaften des Produkts erfolgt. Lastenhefte dienen der Beurteilung der Machbarkeit eines Systems und der Durchführbarkeit des Vorhabens. Das Lastenheft ist nach Balzert Bestandteil einer Feasibility Study (Durchführbarkeitsstudie, Machbarkeitsstudie), die darüber hinaus auch einen Projektplan sowie eine Projektkalkulation erstellt.
Der Einsatz von Lastenheft und Pflichtenheft sowie die darauf aufbauende Erstellung von Angebot und Vertrag verlaufen nach folgendem Schema:
1. Der Auftraggeber erstellt ein Lastenheft und übermittelt dieses an potenzielle Auftragnehmer.
2. Der Auftragnehmer erhebt Anforderungen und korrigiert ggf. das Lastenheft.
3. Der Auftraggeber bestätigt das korrigierte Lastenheft.
4. Der Auftragnehmer erstellt ein Pflichtenheft (meist gegen Bezahlung).
5. Der Auftragnehmer erstellt eine Aufwandsschätzung aufgrund des Pflichtenhefts.
6. Angebot und Vertrag werden erarbeitet.
Das Lastenheft wird vielfach auch als Anforderungsspezifikation, Anforderungskatalog oder Requirements Specification bezeichnet. Da es sich hier um ein zentrales Dokument für die Spezifikation und Bewertung von technischen Systemen handelt, gibt es exakte Definitionen der Natur und Inhalte. Nach DIN 69901-5[1] (Begriffe der Projektabwicklung) [DI19] ist ein Lastenheft die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags“.
Dieses beschreibt somit, was und wofür etwas gemacht werden soll. Gegenüber einem reinen Fachkonzept (das die Funktionen eines IT-Systems aus Benutzersicht beschreibt) ist es aber um formelle Aspekte erweitert, die für eine Ausschreibung nötig sind.
Praxistipp
Die Übersichtlichkeit und Verständlichkeit der Anforderungsdefinition ist ein wesentliches Kriterium. Diese bildet eine Brücke zwischen (externem oder internem) Auftraggeber und Auftragnehmer.
Es empfiehlt sich eine Kombination aus orientierendem Text und Detaillierungen in tabellarischer Form, mit Ergänzungen durch Zeichnungen und Grafiken. Formale Modellierungssprachen (wie UML oder BPMN) zur Darstellung von Prozessabläufen, Datenstrukturen und Zusammenhängen können eingesetzt werden.
Der Auftraggeber kann das Lastenheft als Grundlage einer Ausschreibung verwenden und an potenzielle Auftragnehmer verschicken. Diese erstellen auf Grundlage des Lastenhefts ein Pflichtenheft.
Das Pflichtenheft beschreibt in konkreterer Form, wie der Auftragnehmer die im Lastenheft definierten Anforderungen umzusetzen plant – mit welchen Konzepten und welchen Mitteln. Andere dafür verwendete Begriffe sind Fachspezifikation, Fachfeinkonzept, Sollkonzept, Funktionelle Spezifikation, Gesamtsystemspezifikation, Implementierungsspezifikation oder Feature Specification.
Das Pflichtenheft wird vom Auftragnehmer formuliert, gehört damit diesem und wird auf dessen Wunsch vom Auftraggeber bestätigt. Nach dieser Bestätigung und der Beauftragung können die eigentlichen Entwicklungs- und Implementierungsarbeiten beginnen.
Nach DIN 69901-5 umfasst das Pflichtenheft die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“. Anforderungen des Lastenhefts sind nun mit technischen Festlegungen der Betriebs- und Wartungsumgebung verknüpft.
Dies deckt sich mit der Definition in VDI-Richtlinie 2519: „Das Pflichtenheft ist die Beschreibung der Realisierung aller Kundenanforderungen, die im Lastenheft gefordert werden.“ [VD01].
Praxistipp
Pflichtenhefte sollten in ihrem Aufbau und ihrer Präzision so formuliert sein, dass sie als Basis eines juristischen Vertrags verwendet werden können. Sie sollten verbindliche Festlegungen enthalten, welche Produkte und Leistungen ein Auftragnehmer zu liefern hat. Damit ist hier auch die Grundlage für die Abnahme der Leistung gegeben. Im Streitfall kann das Pflichtenheft auch für die gerichtliche Klärung herangezogen werden.
Pflichtenhefte haben keine vorgegebene Struktur, es haben sich jedoch Richtlinien und Standards entwickelt, die einen bestimmten Aufbau empfehlen. Damit sollen die Erstellung erleichtert und die Vergleichbarkeit verbessert werden.
Die Recommended Practice for Software Requirements Specifications wurden 1984 als Standard IEEE 830-1984 verabschiedet und zum Standard IEEE 830-1998 weiterentwickelt. Danach wird für das Pflichtenheft eine Gliederung in drei Hauptkapitel vorgeschlagen, die jeweils in weitere Unterkapitel unterteilt sind:
Einleitung (Introduction): Die Einleitung beschreibt den Aufbau des Dokuments und definiert einige Grundlagen, die für das weitere Verständnis wichtig sind, außerdem die Ziele, die durch das Produkt erreicht werden sollen.
Übersichtsbeschreibung (General Description): Die Übersichtsbeschreibung gibt einen Überblick über die Funktionen des Produkts, die Umgebung sowie die künftigen Benutzer und ihre Eigenschaften.
Spezifische Anforderungen (Specific Requirements): Die funktionalen Anforderungen (Functional Requirements) werden mit ihren jeweiligen Anforderungen in eigenen Kapiteln aufgeführt. Die Beschreibung folgt einer Input-Process-Output-Systematik einer anderen Beschreibungssystematik für Funktionen bzw. Geschäftsprozesse. Nichtfunktionale Anforderungen umfassen die Anforderungen an externe Schnittstellen, an das Leistungsvermögen (Performance), Restriktionen für den Systementwurf, Qualitätsmerkmale sowie weitere Anforderungen.
In der Unternehmenspraxis existieren eine Reihe von exemplarischen, detaillierten Gliederungen für Pflichtenhefte, die als Vorlage verwendet und für die eigenen Anforderungen spezifisch angepasst werden können. Anhand der darin gemachten Spezifikationen kann in der Folge eine Aufwandschätzung durchgeführt werden. Eine bewährte Gliederung zeigt die nachfolgende Tabelle 20.2.
Tabelle 20.2 Gliederung Pflichtenheft1
Abschnitt |
Inhalte |
1. |
Zielbestimmung 1. Muss-Kriterien: unabdingbare Leistungen und Funktionalitäten, die in jedem Fall erfüllt sein müssen 2. Soll-Kriterien: Kriterien, deren Erfüllung angestrebt wird 3. Kann-Kriterien: nicht unabdingbar; sollten nur angestrebt werden, falls noch ausreichend personelle und finanzielle Kapazitäten vorhanden sind 4. Abgrenzungskriterien: Kriterien, derer Erreichung bewusst nicht angestrebt ist |
2. |
Produkteinsatz 1. Anwendungsbereiche 2. Zielgruppen 3. Betriebsbedingungen: physikalische Umgebung des Systems, Betriebszeit, Betrieb unter Beobachtung oder unbeaufsichtigt |
3. |
Produktübersicht: kurze Übersicht über das Produkt |
4. |
Produktfunktionen 1. Gliederung in Teilprodukte 2. Beschreibung der Produktfunktionen |
5. |
Produktdaten: langfristig zu speichernde Daten aus Benutzersicht |
6. |
Produktleistungen, Performance-Kriterien (Anforderungen Zeit und Genauigkeit) |
7. |
Qualitätsanforderungen |
8. |
Benutzungsoberfläche 1. Grundlegende Anforderungen 2. Zugriffsrechte |
9. |
Nichtfunktionale Anforderungen 1. Einzuhaltende Gesetze und Normen 2. Sicherheitsanforderungen 3. Plattformabhängigkeiten |
10. |
Technische Produktumgebung 1. Hardware: nach Server und Client getrennt 2. Software: nach Server und Client getrennt 3. Orgware: organisatorische Rahmenbedingungen 4. Schnittstellen (Daten, Funktionen) |
11. |
Spezielle Anforderungen an die Entwicklungsumgebung 1. Software 2. Hardware 3. Entwicklungsschnittstellen |
12. |
Glossar 1. Allgemein verwendete Terminologie 2. Unternehmensspezifische Terminologie 3. Abkürzungen |
| 20.7.5 | Use Cases als Form der Anforderungsspezifikation |
Ein Use Case als Form der Anforderungsspezifikation für IT-Systeme modelliert in semiformaler Sprache die Strukturen und das Verhalten von Software- und anderen Systemen. Er stellt Akteure und Anwendungsfälle mit ihren jeweiligen Abhängigkeiten und Beziehungen dar. Er beschreibt die Interaktionen zwischen Nutzer und System, abstrahiert von technischen Lösungen.
Use Cases stellen das erwartete Verhalten eines Systems dar und werden dafür eingesetzt, die Anforderungen an ein System zu spezifizieren. Sie haben große Verbreitung erlangt, sind aufgrund ihrer einfachen Anwendung beliebt und versprechen effizientere und qualitativ bessere Spezifikationen.
Stakeholder und Benutzer sowie deren Ziele bei der Systembenutzung stehen im Mittelpunkt. Use Cases verankern die Spezifikation im Benutzungskontext und gewährleisten Relevanz und Vollständigkeit der zu entwickelnden Funktionalität.
Die Definition von Use Cases erfolgt in mehreren Schritten:
1. Erstellung des Kontextmodells, das Akteure, Anwendungsfälle und (Teil-)Systemgrenzen definiert und durch tabellarische Definitionen ergänzt
2. Definition der Anwendungsfälle mittels kurzer Prosatexte
3. Ausgebaute und semiformal strukturierte Anwendungsfalldefinition mittels Erfolgs- und Fehlerszenarien, Vor- und Nachbedingungen etc.
Das dargestellte Vorgehen bietet für wichtige Entscheidungen im Projektverlauf (z. B. Schätzung, Architektur, Qualitätssicherung) abgesicherte Informationen über die Anforderungen.
Für die Organisation der Spezifikationsaufgaben wichtig sind eine klare Rollenverteilung, ein reibungsloses Zusammenwirken der Beteiligten und hohe Kompetenz, individuell und im Team. Grundsätzlich können und sollen viele Mitarbeiter eines Projekts und des Auftraggebers bei der Anwendungsfallspezifikation mitwirken. Es ist aber wichtig, dass jede Person hinsichtlich ihrer Stärken und Leistungsfähigkeit optimal eingesetzt wird.
Tabelle 20.3 zeigt die rollenbedingten Stärken und Schwächen ausgewählter Projektbeteiligter. In erster Linie sollte die Erstellung der Anwendungsfälle bei den „Anforderungsingenieuren“ liegen. Anwender und Fachexperten können in einzelnen Bereichen gezielt unterstützen.
Tabelle 20.3 Rollen in der Anwendungsfallspezifikation
Rolle |
Stärken (rollenbedingt) |
Schwächen (rollenbedingt) |
Einsatzbereich |
Anwender |
|
|
|
Fachexperte |
|
|
|
Produktmanager |
|
|
|
Anforderungsingenieur |
|
|
|
Use Cases werden so benannt, wie die Prozesse aus der Sicht der Nutzer heißen, z. B. Bestellung erstellen, Kunden erfassen, Wareneingang verbuchen, Anruf durchführen oder Rechnungsbetrag überweisen. Das nachfolgende Beispiel zeigt ein Anwendungsfalldiagramm, unter Verwendung der Unified Modeling Language (UML) als Spezifikationssprache.
Bild 20.5 Beispiel eines Use Case (Quelle: www.uml-diagrams.org)
| 20.8 | Service Level Management |
Das Service Level Management dient der Definition, Überwachung und Optimierung von IT-Dienstleistungen. Die von der IT angebotenen Leistungen sollen in Einklang mit den Kundenerwartungen gebracht werden, die in Service Level Agreements (SLA) formuliert sind.
In einem Service-Katalog werden jene Services verwaltet, die im Rahmen von Geschäftsprozessen angeboten werden (Business Services). Bestandteil des Service Level Management sind auch das Management der Verträge und das Controlling.
Die Aufgaben des Service Level Managements im Einzelnen sind:
Definition und Verwaltung von Service-Katalogen aufgrund von geschäftlichen Anforderungen
Definition und Verwaltung von Service Level Agreements (SLAs) zwischen IT-Service-Anbieter und Kunden
Definition von Key Performance Indicators (KPIs) als Leistungsmaße für die Einhaltung von SLAs
Überwachung (Monitoring) von SLAs und KPIs, um drohende Verletzungen bzw. Risiken für die Zielerreichung frühzeitig erkennen bzw. ihnen gegensteuern zu können
Reporting: Erstellung und Verteilung der entsprechenden Berichte
Vertragsmanagement: Abschluss, Anpassung und Verwaltung der Kundenverträge
Entwicklung und Verwaltung von unterstützenden Verträgen für intern erbrachte Leistungen (Operational Level Agreement, OLA) oder mit Sub-Dienstleistern und Zuliefern (Underpinning Contracts, UC)
Eine mögliche Variante des Service Level Management ist IT Infrastructure Library (ITIL); diese hat sich in der Praxis als Quasi-Standard durchgesetzt.
| 20.8.1 | Service-Katalog-Management |
Der IT-Service-Katalog repräsentiert das Angebot der IT-Abteilungen, aus dem sich interne und externe Kunden bedienen können.
Der Service-Katalog ist üblicherweise in einer hierarchischen Struktur aufgebaut, untergliedert nach Service-Bereichen wie Business-Services, Kommunikation, Hosting oder Arbeitsplatzservices.
Der IT-Service-Katalog beinhaltet zumindest die folgenden beschreibenden Attribute zu jedem Service:
Eindeutige Bezeichnung des Service (Name, Katalognummer)
Kurzbeschreibung des Service
Detaillierte Beschreibung des Service
Leistungsumfang (Messgrößen)
Verrechnungsart
Preis/Einheit
Einbindung (Verbindung zu Anwendungen und anderen Services)
Business- und technische Services stehen in einer Abhängigkeit. Technische Services wie Datenspeicherung und Netzwerkverbindungen liegen den Business-Services zu Grunde. Business-Services in Verbindung mit Anwendungssystemen (ERP, Auftragsverwaltung etc.) nutzen die technischen Services Datenspeicherung oder Lieferantenanbindung. Diese Services stehen aber gleichzeitig auch anderen Business-Services zur Verfügung. Die Grafik zeigt ein Beispiel für die Hierarchiestruktur von Standard-IT-Services.
Bild 20.6 Hierarchiestruktur IT-Services
Services können alle Nutzer innerhalb des Unternehmens betreffen (z. B. E-Mail- oder Office-Anwendungen), einzelne Abteilungen oder Gruppen von Anwendern ansprechen (z. B. ein bestimmter Workflow) oder arbeitsplatzspezifisch sein (Installation eines Heimarbeitsplatzes).
| 20.8.2 | Service Level Agreements (SLAs) |
Ein Service Level Agreement (SLA), auch Dienstleistungsvereinbarung oder Schnittstellenvereinbarung genannt, bezeichnet eine Vereinbarung zwischen einem Auftraggeber und einem Dienstleister für wiederkehrende Dienstleistungen.
SLAs sind ursprünglich für IT-Dienstleistungen entstanden, werden aber mittlerweile auch für andere Arten von Dienstleistungen (z. B. in der Instandhaltung, Anlagenwirtschaft) verwendet. Durch die IT Infrastructure Library (ITIL) haben SLAs an Bedeutung gewonnen.
SLAs schaffen eine verbesserte Preis-Leistungs-Transparenz für die Vertragspartner und eine Unterstützung in strittigen Fällen. Der Auftraggeber erhält Kontrollmöglichkeiten, indem zugesicherte Leistungen hinsichtlich Leistungsumfang, Reaktionszeit und Schnelligkeit der Bearbeitung genau beschrieben werden. Zentrales Kriterium ist hierbei der Servicelevel, welcher die vereinbarte Leistungsqualität beschreibt. Der Auftragnehmer garantiert die Erfüllung der im SLA definierten Leistungen (Reaktionszeiten des Supports, Wiederherstellung von Daten etc.) zu einem vereinbarten Preis.
In einem SLA bietet der Dienstleister jeden relevanten Dienstleistungsparameter in verschiedenen Gütestufen (Levels) an. Der Auftraggeber kann unter betriebswirtschaftlichen oder anderen Aspekten auswählen.
Die wesentlichen Inhalte eines SLAs sind:
Zweck
Vertragspartner (Leistungserbringer, Leistungsempfänger)
Definitionen
Review-Stand/Änderungshistorie
Beschreibung der Leistung (Service)
Verantwortung Leistungserbringer
Verantwortung Leistungsempfänger
Verfügbarkeit des Services
Verwendete Standards
Service-Level-Kennzahlen (KPIs)
Eskalationsmanagement
Preisgestaltung
Rechtsfolgen bei Nichteinhaltung (Pönale)
Vertragslaufzeit
SLAs sind ein wesentliches Element des Service Level Management. Sie werden laufend verändert und an neue Marktgegebenheiten, Geschäftsanforderungen oder Kundenanforderungen angepasst. Damit wird auch ein konsequentes Versionsmanagement (Review-Stand/Änderungshistorie) erforderlich.
| 20.9 | B est Practices im Business Relationship Management |
Die Ziele, Aufgaben und Rollen des Business Relationship Management werden in den angeführten Standards IT Infrastructure Library (ITIL, 2011 Edition) und ISO/IEC 20000 – Standard for IT Service Management beschrieben. Daraus können Prozesse und Strukturen abgeleitet werden, die sich in der Praxis bewährt haben.
Der Business Relationship Manager stellt eine Brücke zwischen der IT-Organisation und ihren Kunden dar. Gartner prognostiziert, dass der Anteil der Personen in der IT-Organisation, die sich vorrangig mit „Relationship Management und Change Leadership“ beschäftigen, über die nächsten Jahre auf über 20 Prozent steigen wird [Me15a].
Ein Modell der Best Practices im Business Relationship Management muss über diese Standards hinausgehen bzw. eine Weiterentwicklung anstreben. Das nachfolgend dargestellte Business-IT Maturity Model [Me15a] bietet eine Richtlinie, wie sich IT-Organisationen zur Exzellenz im Beziehungsmanagement hin entwickeln können.
Das Modell (Bild 20.7) zeigt eine typische Lernkurve in der Entwicklung von BRM. Es repräsentiert sowohl die Entwicklung der Geschäftsanforderungen (Business Demand, links von der Lernkurve) als auch die Reife der IT-Versorgung (IT Supply, rechts von der Lernkurve). Geschäftsanforderungen und IT-Versorgung entwickeln sich nicht notwendigerweise synchron. Die drei Ebenen der Reifeentwicklung (Reifegrad) werden bezeichnet als:
Ebene 1: Business Efficiency (Geschäftseffizienz)
Ebene 2: Business Effectiveness (Geschäftseffektivität)
Ebene 3: Business Transformation (Geschäftstransformation)
Bild 20.7 Taktisches und strategisches BRM2
Die obere Hälfte beschreibt das Strategische BRM, die untere Hälfte repräsentiert das sog. Taktische BRM, mit einem Fokus auf Business Efficiency und Business Effectiveness. Die obere Hälfte zeigt demgegenüber den Bereich des Strategischen BRM, ausgerichtet auf Business Effectiveness und zunehmend Business Transformation.
Der Übergang liegt dort, wo die Lernkurve ihre Richtung ändert. Dies ist ein Bereich, wo Unternehmen in ihrer Reifeentwicklung stagnieren, wo Erträge aus Investitionen abnehmen, wo Unternehmen in Probleme geraten, ihre Leistung weiter zu steigern. Ab diesem Punkt soll die Nachfrage nach Dienstleistungen, Aktivitäten und Initiativen mit hohem potenziellen „Business Value“ stimuliert werden. In enger Zusammenarbeit zwischen Anbieter und Nutzer von IT-Leistungen werden neue Potenziale und Geschäftsfelder erschlossen, die über eine reine Unterstützung von Prozessen hinausgehen.
Standards und Frameworks wie ITIL, COBIT und TOGAF sind darauf ausgelegt, den taktischen Bereich durch Mechanismen der Kontrolle und gezielten Steuerung zu unterstützen (Ebenen 2 und 3), sie tragen aber wenig zur Schaffung von neuen, innovativen Lösungen bei (Ebene 3). Das Business Relationship Management nimmt eine wichtige Rolle ein, um Innovationen zu fördern und so einen aktiven Beitrag zur Wertschöpfung des Unternehmens zu leisten.
Eine andere Sicht auf die Entwicklung von Beziehungen zwischen IT-Organisation und Kunden stellt das Modell von Gartner dar, das eine Evolution der Enterprise IT in drei Phasen beschreibt.3 Ausgehend von einer „handwerklichen IT, befindet sich heute die IT-Landschaft der meisten Unternehmen im Übergang von der Ära der IT-Industrialisierung, in der der Schwerpunkt auf Prozessen liegt, in die Ära der Digitalisierung, in der der Fokus auf Geschäftsmodellen liegt. Dieser Übergang wird die Verschiebung von technisch kompetenzorientierten Servicefähigkeiten zu geschäftsbereichsorientierten Servicefähigkeiten vorantreiben. Daher muss sich die IT-Marketing- und Vertriebsfunktion weiterentwickeln, um die Möglichkeiten der digitalen Technologien zu kommunizieren, zu bewerten und gezielt einzusetzen (Bild 20.8).
Bild 20.8 Die Phasen der Business IT4
| 20.10 | R elationship Management und die Potenziale der Digitalisierung |
Die Technologien und Konzepte der Digitalisierung, Crowd Sourcing, Künstliche Intelligenz oder Data Analytics sind dabei, die Schnittstellen zwischen Lieferanten und Kunden in der Wertkette sind grundlegend zu verändern (vgl. ausführlich auch Kapitel 3 dieses Handbuchs):
Die Beschaffung wird integrales Element in dynamischen Digital Supply Networks. Es entstehen neue Formen der Zusammenarbeit, eine gesteigerte Markttransparenz und neue Abläufe.
Digitale Einkaufsplattformen ermöglichen eine objektivere Bewertung von Lieferanten sowie eine deutliche Effizienzsteigerung in der Prozessabwicklung.
Werkzeuge der Künstlichen Intelligenz und Predictive Analytics ermöglichen weitgehend automatisierte, von Maschinen autonom angestoßene und gesteuerte Bestellprozesse.
Das Internet of Things und Industrie 4.0 integrieren über Sensordaten und umfassende Vernetzung Informationen von Kunden, Lieferanten und anderen Partnern in der Wertschöpfungskette und tragen zu einer optimierten, zeitgerechten Bereitstellung von Produkten und Services bei.
Um diese Potenziale auszuschöpfen und die Wettbewerbsposition zu stärken, sind Unternehmen gefordert, cross-funktionale strategische Initiativen von Einkauf und Unternehmens-IT zu starten und auch entsprechende Investitionen in die zukünftigen Systeme durchzuführen.
In der Folge betrachten wir einige Ansätze aus dem komplexen Umfeld der Technologien von Digitalisierung und Industrie 4.0. Dabei wird auf jene fokussiert, die für das Beziehungsmanagement hin zu Kunden und Lieferanten besondere Bedeutung haben.
| 20.10.1 | Digitale Unternehmen und Wertschöpfungsketten |
Digitalisierung ist mehr als die Abbildung bestehender Strukturen und Prozesse in neue, computerunterstützte Arbeitsweisen und Produkte. Aufbauend auf den Basistechnologien – wie dem Internet der Dinge, den Cyber-Physical Systems und dem Physical Internet – strukturieren sich Unternehmen und Wertschöpfungsketten neu:
Das Internet der Dinge (IoT) beschreibt die Vernetzung von „intelligenten“, eindeutig identifizierbaren Objekten mit integrierter Sensorik durch Kommunikationsnetze. Diese kommunizieren miteinander, tauschen Informationen über Lokationen und Zustände aus und können mithilfe entsprechender Algorithmen selbststeuernde Systeme bilden.
Cyber-physikalische Systeme (CPS) bilden die reale Umwelt in virtuellen Modellen ab, simulieren diese Umwelt und wirken steuernd auf sie ein. So können reale Zustände und Aktionen vorab im Computermodell erprobt werden, bevor potenziell kostspielige oder risikoreiche Aktionen gesetzt werden. Die reale Welt wird in der Wahrnehmung der (menschlichen) Akteure durch virtuelle Elemente (wie etwa Informationen, Anleitungen) erweitert.
Das Physical Internet (PI) überträgt die Vernetzungskonzepte des Digital Internet auf Transportnetzwerke. Wie Nachrichten in dem uns vertrauten Internet reibungslos und selbstgesteuert fließen, bewegen sich im Physical Internet Produkte in intelligenten Behältern und finden den optimalen Weg zu ihrem Zielort.
Das Industrie-4.0-Framework umfasst vier Säulen: Smart Solutions, Smart Innovation, Smart Supply Chains und Smart Factory. Diese Säulen sind als Faktoren zur Wachstumssteigerung und Effizienzsteigerung eingebettet in ein organisatorisches Framework, bestehend aus einem agilen Betriebsmodell, Personalführung, Change Management, Governance und Prozesse sowie der digitalen Infrastruktur. Daraus ergibt sich das in Bild 20.9 dargestellte Modell.
Bild 20.9 Rahmenmodell digitaler Unternehmen und Wertschöpfungsketten5
Ziel des Einsatzes digitaler Technologien sind die Steigerung von Produktivität, Effizienz, Service Level, Flexibilität, Wettbewerbsfähigkeit und Nachhaltigkeit.
Das Wichtigste zusammengefasst
Relationship Management umfasst alle Arten von Beziehungen eines Unternehmens, also die businessrelevanten Beziehungen zu Kunden, Lieferanten und Wettbewerbern, aber auch die Beziehungen zu den Stakeholdern im weiteren Sinne.
Enge Partnerkooperationen ermöglichen eine bessere Abstimmung, eine effektivere Ausschöpfung von Geschäftspotenzialen sowie die Nutzung gemeinsamer Wachstums- und Erfolgspotenziale. Meist liegt der Fokus ausschließlich auf dem Management der Kundenbeziehungen (Customer Relationship Management), andere Kooperationen und Netzwerke werden häufig vernachlässigt.
Die Aufgabenfelder des Relationship Management umfassen primär die Definition des Beziehungsnetzwerks, die Ausgestaltung der Transaktionssysteme sowie das operative Transaktionsmanagement.
Das Business-IT Relationship Management weist eine Reihe von Besonderheiten auf, die in Normenwerken und Frameworks (ITIL, ISO/IEC 20000) berücksichtigt sind.
Das Management der Kundenbeziehungen umfasst die Aufgabenbereiche
Service Portfolio Management, Requirements Management und Service Level Management.
Anhand eines Reifegradmodells wird ein möglicher Entwicklungsweg zu einem innovativen, für alle beteiligten Partner gewinnbringenden Business-IT Relationship Management aufgezeigt.
Das „Rahmenmodell digitaler Unternehmen und Wertschöpfungsketten“ zeigt die Anwendungspotenziale digitaler Technologien in allen Bereichen des Relationship Management auf.
| 20.11 | Literatur und weiteres Informationsmaterial |
[Ax15] |
Axelos, IT Infrastructure Library (ITIL): https://www.axelos.com/itil, abgerufen am 14. 06. 2015 |
[Ba09] |
Balzert, H.: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering. 3. Auflage. Springer 2009 |
[Be14] |
Bechtold, J.; Lauenstein, C.; Kern, A.; Bernhofer, L.: Industrie 4.0 – Eine Einschätzung von Capgemini Consulting: Der Blick über den Hype hinaus. Capgemini Consulting 2014, https://www.capgemini.com/de-de/wp-content/uploads/sites/5/2017/07/industrie-4.0-de.pdf, abgerufen am 15. 01. 2019 |
[DI19] |
DIN 69901-5[1] (Begriffe der Projektabwicklung) |
[Di95] |
Diller, H.: Beziehungsmanagement. In: Tietz, B.; Köhler, R.; Zentes, J. (Hrsg.): Handwörterbuch des Marketing. 2. Auflage, Stuttgart 1995 |
[Di05] |
Diller, H.; Haas, A.; Ivens, B.: Verkauf und Kundenmanagement: eine prozessorientierte Konzeption. Stuttgart 2005 |
[IS15] |
ISO/IEC 20000-1: 2011 IT Service Management: http://www.iso.org/iso/catalogue_detail?csnumber=51986, abgerufen am 14. 06. 2015 |
[IT14] |
IT Infrastructure Library (ITIL): https://www.axelos.com/itil, abgerufen am 29. 11. 2014 |
[Iv02] |
Ivens, B.: Beziehungsstil im Business-to-Business-Geschäft. Nürnberg 2002 |
[Me15] |
Merlyn, Vaughan: IT-Enabled Business Innovation: A Missing Link? http://vaughanmerlyn.com/, abgerufen am 14. 06. 2015 |
[Me15a] |
Merlyn, Vaughan: ITIL and the Business Relationship Manager: Avoiding the Performance Trap! http://vaughanmerlyn.com/2013/01/15/itil-and-the-business-relationship-manager-pathto-success-or-to-getting-stuck, abgerufen am 30. 08. 2019 |
[Od22] |
Odigitech.com: it Services Marketing, https://odigitech.com/technology-education/it-services-marketing , zuletzt abgerufen am 7. 7. 2022 |
[Pe09] |
Pelkmann, Th.: Die Trends bei E-Procurement und E-Collaboration, 2009, http://www.cio.de/strategien/methoden/884233/index.html, zuletzt abgerufen am 17. 8. 2019 |
[Ro06] |
Robertson, S.; Robertson, J. C.: Mastering the Requirements Process. Second Edition. Addison-Wesley Professional 2006 |
[VD01] |
VDI 2519 Blatt 1 Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften, Erscheinungsdatum 2001-11 |
[Zs12] |
Zsifkovits, H.: Logistik, UVK 2012 |
[Zs19] |
Zsifkovits, H.; Woschank, M.: Smart Logistics – Conceptualization and Empirical Evidence, CMU Journal, Chiang Mai University, Thailand 2019 |
[Zs19a] |
Zsifkovits, H.; Woschank, M.: Smart Logistics – Technologiekonzepte und Potentiale. Berg- und Huettenmaennische Monatshefte. 615. doi:10.1007/s00501-018-0806-9. |
1 adaptiert nach [Ba09]
2 übersetzt und adaptiert nach [Me15a]
3 http://odigitech.com/technology-education/it-services-marketing/
4 übersetzt und adaptiert nach [Od22]
5 übersetzt und adaptiert nach [Zs19], [Zs19a] und [Be14]