Best-Practice-Referenzmodelle der IT

Transcription

Best-Practice-Referenzmodelle der IT-Governance
Struktur, Anwendung und Methoden
Inauguraldissertation
zur
Erlangung des Grades
Doktor der Wirtschaftswissenschaften
-Dr. rer. pol.an der Frankfurt School of Finance & Management
vorgelegt von
Stefanie Looso, geb. Alter
geb. am 20.01.1982, in Fritzlar
Matrikelnummer: 4661220
Oktober 2011
Die vorliegende Arbeit wurde am IT-Governance-Practice-Network der
Frankfurt School of Finance & Management angefertigt.
Erstgutachter:
Professor Dr. Matthias Goeken (JP)
Management Department
Frankfurt School of Finance & Management
Zweitgutachter:
Professor Dr. Peter Roßbach
Management Department
Drittgutachter:
Professor Dr. Ulrich Hasenkamp
Institut für Wirtschaftsinformatik
Philipps-Universität Marburg
Danksagung
Meinem Doktorvater Professor Dr. Matthias Goeken danke ich für seine von echtem
Interesse zeugende Betreuung und die gute wissenschaftliche und persönliche
Zusammenarbeit. Ich danke ihm für seine Geduld, aber auch für seine Ungeduld, die
gewährte wissenschaftliche Freiheit und die Weitergabe seiner Erfahrung.
Außerdem danke ich meinem Zweitgutachter Professor Dr. Peter Roßbach, der immer
eine offene Tür hatte und mir oft die richtigen Fragen stellte.
Mein Dank gilt ebenfalls meinem Drittgutachter Professor Dr. Ulrich Hasenkamp, der
bereits zu Studienzeiten mein Interesse für die Wirtschaftsinformatik weckte.
Was wäre eine Promotionszeit ohne Mitdoktoranden, jene Mitstreiter, die alle Phasen
des Promotionsprojekts mit Rat und Tat und der ein oder anderen Tasse Kaffee
unterstützen. Mein Dank für so manches gemeinsame Paper, euren fachlichen Rat und
viele schöne Stunden an der Frankfurt School geht hier stellvertretend an René, Jutta,
Marcel, Danijel und Janusch. Meine lieben Kollegen Manuel und Tine möchte ich
gesondert hervorheben. Wir sind miteinander durch so manches Tal gelaufen und haben
am Ende drei Berge bestiegen. Danke für eure Freundschaft.
Meiner besten Freundin Tina danke ich für ihre unbedingte Freundschaft und ihre graue
Jacke.
Mein besonderer Dank gilt meinem Mann Mario. Er hat Erfolge mit mir gefeiert, mich
aufgerichtet und wieder angetrieben, mit mir den inneren Schweinehund bekämpf, mich
immer wieder konstruktiv kritisiert und unterstützt wo er nur konnte. Dafür danke ich
ihm von ganzem Herzen.
Meine Eltern Heike und Jochen Alter und meine Schwester Katharina haben mich seit
Kindertagen in allem unterstützt und immer an mich geglaubt. Gleichzeitig gaben sie
mir das Gefühl jederzeit auch ohne Lorbeeren nach Hause kommen zu können. Diese
bedingungslose Liebe ist mein Fundament. Meinen Eltern widme ich diese Arbeit.
2
Inhaltsverzeichnis
Verzeichnis der Fachbeiträge .................................................................................... iii
Zusammenfassung ..................................................................................................... vi
Teil A: Problemstellung, Terminologie und Forschungsdesign................................ 1
Motivation und Problemstellung ................................................................................ 1
Grundlegende Begriffe ............................................................................................... 3
IT-Governance ........................................................................................................ 3
Best-Practice-Referenzmodell ................................................................................ 9
Methode ................................................................................................................ 15
Forschungsdesign und Aufbau der Arbeit ................................................................ 18
Teilgebiet: Struktur ............................................................................................... 20
Teilgebiet: Anwendung ........................................................................................ 22
Teilgebiet: Methode .............................................................................................. 25
Zwischenfazit ........................................................................................................... 27
Literaturverzeichnis Teil A ...................................................................................... 29
Teil B: Struktur von Best-Practice-Referenzmodellen ............................................ 39
Vorbemerkungen Teil B ........................................................................................... 39
Fachbeitrag 1: Representing IT Governance Frameworks as Metamodels .............. 41
Fachbeitrag 2: Metamodelle von Referenzmodellen am Beispiel ITIL.
Vorgehen, Nutzen, Anwendung. .............................................................................. 49
Fachbeitrag 3: Towards Conceptual Metamodeling of
IT Governance Frameworks Approach - Use – Benefits. ........................................ 65
Zwischenfazit Teil B ................................................................................................ 76
Teil C: Formen der Anwendung von Best-Practice-Referenzmodellen ................. 77
Vorbemerkungen Teil C ........................................................................................... 77
Fachbeitrag 4: Towards an Operationalisation of Governance and Strategy for
Service Identification and Design ............................................................................ 80
Fachbeitrag 5: Application of Best Practice Reference Models
of IT Governance...................................................................................................... 90
Zwischenfazit Teil C .............................................................................................. 107
Teil D: Methode zur Anpassung und Anwendung von Best-PracticeReferenzmodellen ...................................................................................................... 108
Vorbemerkungen Teil D ......................................................................................... 108
Fachbeitrag 6: Methode zur Anpassung und Anwendung von Best-PracticeReferenzmodellen der IT-Governance ................................................................... 109
Fachbeitrag 7: Towards a structured application of IT governance
best practice reference models ............................................................................... 217
Zwischenfazit Teil D .............................................................................................. 232
i
Teil E: Wissenschaftstheoretische Aspekte der Methodenentwicklung............... 233
Vorbemerkungen Teil E ......................................................................................... 233
Fachbeitrag 8: Using Grounded Theory for Method Engineering ......................... 235
Zwischenfazit Teil E .............................................................................................. 245
Teil F: Anwendung von BPRM in einer Multi-Modell-Umgebung ...................... 246
Vorbemerkungen Teil F ......................................................................................... 246
Fachbeitrag 9: Konzeptionelle Metamodelle von IT-Governance
Referenzmodellen als Basis der Kombination und Integration in einer
Multi-Modell-Umgebung. ...................................................................................... 247
Fachbeitrag 10: Multi-Modell-Umgebung IT-Governance:
Einsatz mehrerer Best-Practice-Referenzmodelle .................................................. 263
Zwischenfazit Teil F............................................................................................... 282
Teil G: Fazit, Implikationen für Wissenschaft und Praxis sowie weiterer
Forschungsbedarf...................................................................................................... 283
Anhang A: Lebenslauf ................................................................................................. ix
Anhang B: Vollständiges Publikationsverzeichnis..................................................... x
ii
Verzeichnis der Fachbeiträge
Fachbeitrag 1:
Titel: Representing IT Governance Frameworks as Metamodels
Autoren: Matthias Goeken, Stefanie Alter
Veröffentlicht in: Proceedings of the 2008 International Conference on e-Learning, eBusiness, Enterprise Information Systems, and e-Government (EEE 2008), 14.17.07.2008, Las Vegas, Nevada.
Anzahl der Reviewer: 3
Art des Reviews: doppelt-blind
Dieser Beitrag wurde außerdem in ähnlicher Form in den Proceedings der 10th
International Conference on Enterprise Information Systems (ICEIS 2008) publiziert,
12.-16.06.2008, Barcelona, Spanien. Anzahl der Reviewer: 2; Art des Reviews: doppeltblind.
Fachbeitrag 2:
Titel: Metamodelle von Referenzmodellen am Beispiel ITIL. Vorgehen, Nutzen,
Anwendung
Autoren: Matthias Goeken, Stefanie Alter, Danijel Milicevic, Janusch Patas
Veröffentlicht in: Fischer, Stefan; Maehle, Erik; Reischuk, Rüdiger (Hrsg.) Proceedings
der Informatik 2009, Lecture Notes in Informatics (LNI).
Ranking: 0,1 Punkte (Handelsblatt-Ranking)
Fachbeitrag 3:
Titel: Towards Conceptual Metamodeling of IT Governance Frameworks
Approach - Use – Benefits
Veröffentlicht in: Proceedings of the 42nd Hawaii International Conference on System
Sciences (HICSS 2009), 05.-08.01.2009, Big Island, Hawaii, USA. Washington, DC,
USA: IEEE Computer Society.
Ranking: B-Konferenz (WKWI)
iii
Fachbeitrag 4:
Titel: Towards an Operationalisation of Governance and Strategy for Service
Identification and Design
Autoren: René Börner, Stefanie Looso, Matthias Goeken
Veröffentlicht in: Proceedings of the Thirteenth IEEE International EDOC Conference
09, Auckland, New Zealand, S. 180-188.
Dieser Beitrag wurde in ähnlicher Form veröffentlicht in den Proceedings der
Informatik 2009, Lecture Notes in Informatics (LNI), S. 3660-3674, Fischer, Stefan;
Maehle, Erik; Reischuk, Rüdiger. Anzahl der Reviewer: 3; Art des Reviews: doppeltblind; Ranking: 0,1 Punkte (Handelsblatt-Ranking).
Fachbeitrag 5:
Titel: Application of Best Practice Reference Models of IT Governance
Autoren: Stefanie Looso, Matthias Goeken
Veröffentlicht in: Proceedings of the 18th European Conference on Information
Systems (ECIS 2010), 06.-09.07.2010, Pretoria, South Africa.
Ranking: A-Konferenz (WKWI), 0,2 Punkte (Handelsblatt-Ranking)
Fachbeitrag 6:
Titel: Methode zur Anpassung und
Referenzmodellen der IT-Governance
Autor: Stefanie Looso
unveröffentlicht
Anwendung
von
Best-Practice-
Fachbeitrag 7:
Titel: Towards a structured application of IT governance best practice reference
models
Veröffentlicht in: Proceedings of the 16th Americas Conference on Information
Systems (AMCIS 2010), 12.-15-08.2010, Lima, Peru.
Dieser Beitrag wurde außerdem in ähnlicher Form in den Proceedings der 12th
International Conference on Enterprise Information Systems (ICEIS 2010) publiziert,
08.-12.06.2010, Funchal, Madeira, Portugal. Anzahl der Reviewer: 2; Art des Reviews:
doppelt-blind; C-Konferenz (WKWI).
iv
Fachbeitrag 8:
Titel: Using Grounded Theory for Method Engineering
Autoren: Stefanie Looso, René Börner, Matthias Goeken
Veröffentlicht in: Proceedings of the IEEE International Conference on Research
Challenges in Information Science (RCIS 2011), 19.-21.05.2011, Guadeloupe - French
West Indies, France.
Fachbeitrag 9:
Titel: Konzeptionelle Metamodelle von IT-Governance Referenzmodellen als Basis
der Kombination und Integration in einer Multi-Modell-Umgebung
Autoren: Stefanie Alter, Matthias Goeken
Veröffentlicht in: Hansen, Karagiannis, Fill, (Hrsg.) Business Services: Konzepte,
Technologien, Anwendungen. 9. Internationale Tagung Wirtschaftsinformatik, 25.27.02.2009, Wien, Österreich, Band 1.
Fachbeitrag 10:
Titel: Multi-Modell-Umgebung IT-Governance: Einsatz mehrerer Best-PracticeReferenzmodelle
Veröffentlicht in: Proceedings der Informatik 2010, 27.09.-02.10.2010, Leipzig. Lecture
Notes in Informatics (LNI).
v
Zusammenfassung
Die vorliegende kumulative Dissertation wurde an der Frankfurt School of Finance &
Management bei Professor Dr. Matthias Goeken (JP) angefertigt. Die Dissertation
beschäftigt sich mit der Struktur, der Anwendung und den Methoden von Best-PracticeReferenzmodellen der IT-Governance.
Unter dem Begriff „Best-Practice-Referenzmodell (BPRM) der IT-Governance― werden
zahlreiche Modelle aus dem Bereich IT-Governance subsumiert. Bekannte BPRM sind
bspw. die Control Objectives for Information and related Technology (COBIT), die IT
Infrastructure Library (ITIL) oder das Capability Maturity Model Integrated (CMMI).
Diese und andere BPRM erlangten in den letzten 10 Jahren eine gewisse Bedeutung im
Bereich IT-Governance und angrenzenden Bereichen wie bspw. dem IT-Management
oder dem IT-Servicemanagement. Sie versprechen inhaltliche und methodische
Unterstützung bei den Herausforderungen der IT-Abteilungen in Unternehmen. Ihre
Bedeutung resultiert nicht zuletzt daraus, dass die Wissenschaft sich dem Thema ITGovernance und vor allem der Entwicklung von methodischer Unterstützung für die
Praxis nur sehr zaghaft näherte und es daher an Wissen und etablierten Methoden für
die Praxis mangelte.
Eine wissenschaftliche Auseinandersetzung erscheint daher zweckmäßig, nicht nur weil
BPRM eine intensive Verbreitung in der Praxis gefunden haben, sondern auch weil sie
eine große Menge an konsolidiertem (Erfahrungs-)Wissen beinhalten, welches sich
wissenschaftlich nutzen lässt. Außerdem werden BPRM zumeist fortlaufend durch die
herausgebenden Institutionen weiterentwickelt und verbessert, sodass sie einen hohen
Reifegrad erlangen können. Es stellen sich jedoch die Fragen, wie die in der Praxis
entstandenen BPRM der IT-Governance in den wissenschaftlichen Kontext eingeordnet
werden können und wie sie aus der Sicht der Wissenschaft zu bewerten bzw. zu nutzen
sind.
Ziel dieses Promotionsprojekts ist es, die Wissensbasis der IT-Governance-Forschung
hinsichtlich der verwendeten BPRM zu verbessern und ihre Anwendung methodisch zu
unterstützen. Im Zuge dieser Dissertation werden daher zunächst die Struktur und die
Anwendungsmöglichkeiten von BPRM aufgearbeitet, bevor anschließend eine Methode
zur Unterstützung der Anwendung erarbeitet wird. Bei der vorliegenden Arbeit handelt
es sich um eine kumulative Dissertation. Sie besteht aus zehn Fachbeiträgen, von denen
neun zum Zeitpunkt der Einreichung bereits veröffentlicht waren. Der folgende
Abschnitt gibt einen Überblick über die Forschungsfragen, Methoden und Lösungsansätze der jeweiligen Fachbeiträge.
Aus der Analyse des Forschungsfeldes ergaben sich zu Beginn des
Promotionsvorhabens folgende Forschungsfragen: Wie kann ein in der Praxis
entwickeltes Modell theoretisch fundiert werden und welchen Mehrwert hat eine solche
Fundierung?
vi
Mit diesen grundsätzlichen Forschungsfragen beschäftigen sich die Fachbeiträge 1 und
2. Sie zeigen, wie mithilfe der konzeptionellen Modellierung, insbesondere der
Metamodellierung, die Struktur von BPRM aufgearbeitet werden kann. Dies geschah
unter anderem, da ein konzeptionelles Metamodell grundlegende Strukturen aufzeigt
und es den Untersuchungsgegenstand systematisiert.
Da die Metamodelle im Verlauf der Arbeit mehrfach verwendet werden, ist die Qualität
der erstellten Metamodelle für die nachfolgenden Forschungsfragen und Forschungsergebnisse von entscheidender Bedeutung. Hieraus ergab sich daher die weitergehende
Frage, wie der Erstellungsprozess eines Metamodells verbessert werden kann. Kritisch
ist hierbei insbesondere die Übertragung des Wissens aus dem BPRM in das
Metamodell. Die Fragen nach dem Ablauf und der Qualität des Metaisierungsprozesses
sowie nach dem Einfluss des Modellierers auf das spätere Metamodell motivierten
Fachbeitrag 3.
Fachbeitrag 4 zeigt die Anwendung des konkreten BPRM COBIT im Bereich von
serviceorientierten Architekturen (SOA). COBIT wird in diesem Beitrag zur
Unterstützung der Service-Governance angewendet. Im Verlauf der Forschungsarbeit zu
diesem konkreten Anwendungsfall wurde erneut deutlich, wie vielfältig die
Anwendungsmöglichkeiten von BPRM sind. Daher ergaben sich die weitergehenden
Forschungsfragen: Wie und von wem werden BPRM in der Praxis genutzt und gibt es
bestimmte Anwendungstypen, die gezielt unterstützt werden können? Um diese Fragen
zu beantworten, konnten unter anderem Ergebnisse einer qualitativen Studie genutzt
werden. Dieses qualitativ-empirische Vorgehen wurde durch eine breite
Literaturrecherche flankiert. Forschungsergebnis ist ein Ordnungsrahmen der
Anwendung von BPRM, der in Fachbeitrag 5 vorgestellt wird.
Ein weiteres Ergebnis der durchgeführten qualitativ-empirischen Studie ist die
Erkenntnis, dass die gleichzeitige Anwendung mehrerer BPRM in der Praxis eine große
Herausforderung für Unternehmen darstellt. Daraus ergibt sich die Anforderung, dass
eine Methode zur Unterstützung der Anwendung von BPRM auch für den MultiModell-Fall einsetzbar sein sollte.
Dieser Multi-Modell-Fall wird im letzten inhaltlichen Teil F (Fachbeiträge 9 und 10)
der Dissertation behandelt. Grund hierfür ist die Annahme, dass zunächst der EinModell-Fall systematisch erarbeitet werden muss, bevor dieser dann auf den MultiModell-Fall erweitert werden kann. Da auch die entwickelte Terminologie aus dem EinModell-Fall für den Multi-Modell-Fall angewendet wird, verbessert diese Reihenfolge
außerdem die Lesbarkeit dieser Arbeit.
In Teil D der Dissertation wird daher zunächst die Frage behandelt, wie die Anwendung
eines einzelnen BPRM methodisch unterstützt werden kann. Mithilfe von
Forschungsergebnissen aus dem Methoden-Engineering und der Referenzmodellierung
wurde eine Methode zur Anpassung und Anwendung von BPRM entwickelt. Dieser
sechste Fachbeitrag ist der Hauptteil der vorliegenden Dissertation. Die Anwendbarkeit
vii
der entwickelten Methode konnte im Forschungsprojekt SemGoRiCo1 für das BPRM
COBIT getestet werden (Fachbeitrag 6 und 7).
Im Zuge der Methodenkonstruktion für den Ein-Modell-Fall ergab sich bereits in
Fachbeitrag 6 die Frage, wie die Konstruktion von Methoden erfolgt und ob dieser
Prozess eventuell verbesserungswürdig ist. Die Qualität von Forschungsergebnissen aus
dem Bereich der konstruktionsorientierten Forschung wird in den letzten Jahren
verstärkt im Zuge der „rigor vs. relevance―–Debatte diskutiert. Im Rahmen dieser
Diskussion wird immer häufiger betont, dass Forschungsdesigns sowohl strengen
forschungsmethodischen Ansprüchen (rigor) folgen als auch Problemrelevanz haben
sollten (relevance). Fachbeitrag 8 beschäftigt sich mit der Erweiterung des MethodenEngineering-Ansatzes um eine qualitativ-empirische Komponente. Der entwickelte
Ansatz Grounded Method Engineering zeigt, wie die konzeptionelle
Methodenkonstruktion durch eine empirische Fundierung sowohl der Forderung nach
Relevanz, als auch der nach forschungsmethodischer Strenge gerecht werden kann.
Der anschließende Teil F greift den bereits angesprochenen Multi-Modell-Fall auf. Hier
stellt sich vor allem die Forschungsfrage, was eine Multi-Modell-Umgebung in der ITGovernance ausmacht und wie die bisherigen Forschungsergebnisse genutzt werden
können, um auch diesen in der Praxis häufig vorkommenden Fall zu unterstützen.
Fachbeitrag 9 erläutert daher die grundsätzlichen Probleme der Multi-ModellUmgebung und zeigt, wie mithilfe der in Fachbeitrag 1 und 2 erstellten Metamodelle
Vergleichs- und Kombinationsmöglichkeiten geschaffen werden können. Fachbeitrag
10 thematisiert die Unterstützung des Einsatzes mehrerer BPRM in der Praxis und zeigt
eine Erweiterung der in Fachbeitrag 6 entwickelten Methode.
Zusammengefasst ist es das Ziel dieser Arbeit, zum einen die Wissensbasis des
Forschungsbereichs IT-Governance hinsichtlich der verwendeten Best-PracticeReferenzmodelle zu verbessern. Zum anderen soll die Anwendung der Modelle in der
betrieblichen Praxis unterstützt werden. Durch die vorgestellten Fachbeiträge werden
beide Forschungsziele adressiert. Praktische Relevanz weist die Arbeit auch dadurch
auf, dass die entwickelte Methode bereits im Rahmen des SemGoRiCo-Projekts
verwendet wird. Weitere Implikationen für Wissenschaft und Praxis werden in Teil G
aufgezeigt und diskutiert.
1
Dieses Projekt (HA-Projekt-Nr.: 160/08-22) wird im Rahmen der Innovationsförderung gefördert,
finanziert aus Mitteln der LOEWE-Landes-Offensive zur Entwicklung wissenschaftlich-ökonomischer
Exzellenz, Förderlinie 3: KMU-Verbundvorhaben.
viii
Teil A: Problemstellung, Terminologie und Forschungsdesign
Motivation und Problemstellung
Vor dem Hintergrund von Insolvenzen, Bilanzskandalen, Datenmissbrauch und
mangelnder Transparenz der Unternehmensführung wurde im Jahr 2009 der ―Deutsche
Corporate Governance Kodex― veröffentlicht. Seiner Präambel lässt sich folgendes
Selbstverständnis entnehmen:
„Der vorliegende Deutsche Corporate Governance Kodex (der "Kodex") stellt
wesentliche gesetzliche Vorschriften zur Leitung und Überwachung deutscher
börsennotierter Gesellschaften (Unternehmensführung) dar und enthält
international und national anerkannte Standards guter und verantwortungsvoller
Unternehmensführung. Der Kodex soll das deutsche Corporate Governance
System transparent und nachvollziehbar machen. Er will das Vertrauen der
internationalen und nationalen Anleger, der Kunden, der Mitarbeiter und der
Öffentlichkeit in die Leitung und Überwachung deutscher börsennotierter
Gesellschaften fördern. Der Kodex verdeutlicht die Verpflichtung von Vorstand
und Aufsichtsrat, im Einklang mit den Prinzipien der sozialen Marktwirtschaft für
den Bestand des Unternehmens und seine nachhaltige Wertschöpfung zu sorgen
(Unternehmensinteresse).―2
Ziel ist es also, neben den Interessen der Shareholder auch die Interessen aller
Stakeholder von börsennotierten Unternehmen, wie beispielsweise Arbeitnehmer, Staat
und Gesellschaft, zu schützen. Jedoch hat eine „gute― Corporate Governance (CG)
neben gesellschaftlichen auch rein wirtschaftliche Auswirkungen.3 So sind
beispielsweise Investoren bereit, 20% mehr in Anteile solcher Unternehmen zu
investieren, die eine gute CG vorweisen können.4
Um die Güte der CG im Außenverhältnis nachweisen zu können, wurde es im Zuge von
CG-Initiativen erforderlich, unternehmensübergreifende Leitsätze und Standards zu
entwickeln. Mit Hilfe dieser Leitsätze und Standards erbringen Unternehmen zumeist
durch freiwillige Zertifizierungen den Nachweis einer guten CG.5
Aufgrund der hohen Durchdringung von Unternehmen mit Informationstechnologie
(IT) und der daraus resultierenden kritischen Abhängigkeit vom Funktionieren der IT,
entstand der Bereich IT-Governance als Teilbereich der Corporate Governance. Die IT-
2
Bundesministerium für Justiz 2009, S. 1.
Vgl. Gompers et al. 2003.
4 Vgl. McKinsey & Company Juni 2000.
5 Ersichtlich ist dies vor allem durch die medienwirksame Vermarktung von freiwilligen Zertifikaten oder
Selbstverpflichtungen bezogen auf die Einhaltung des deutschen Corporate-Governance-Kodex.
Aufschlussreich sind hier Geschäftsberichte und Internetauftritte von DAX-Unternehmen.
Wissenschaftliche Quellen beziehen sich zumeist auf die Compliance gegenüber verpflichtenden
Gesetzen und Vorschriften, z.B. Thielemann et al. 2009, oder sie beziehen sich auf den eher qualitativ
erforschten Bereich Corporate Social Responsiblity, z.B. Habisch et al. 2008.
1
3
Governance beschäftigt sich gemäß ihrem Selbstverständnis mit folgenden
grundsätzlichen Fragestellungen:
 Werden die Unternehmensziele von der eingesetzten IT unterstützt?
 Ist die IT in der Lage, sich zu entwickeln und anzupassen?
 Wird den Risiken entsprechend gesteuert?
 Werden Chancen und Möglichkeiten erkannt und wird darauf angemessen
reagiert?6
Aus diesen Fragestellungen und den daraus resultierenden Managementaufgaben ergab
sich auch für den IT-Bereich der Bedarf, die Governance mit generellen Leitsätzen und
Standards zu unterstützen.
Zunächst unabhängig von dem durch die Außenwirkung getriebenen CG-Gedanken
haben sich im IT-Bereich praxisorientierte Leitsätze und De-facto-Standards entwickelt,
die sogenannten Best-Practice-Referenzmodelle (BPRM). Bekannte und etablierte
BPRM sind die Control Objectives for Information and related Technology (COBIT),
die IT Infrastructure Library (ITIL) oder das Capability Maturity Model Integration
(CMMI). Diese BPRM bieten eine methodische Unterstützung für die
Professionalisierung der IT-Organisation eines Unternehmens und werden abhängig von
ihrer Zielsetzung etwa dem IT-Servicemanagement oder der IT-Entwicklung
zugeordnet. Da BPRM wie COBIT, ITIL oder CMMI jedoch auch Einfluss auf die
Außenwirkung der Unternehmens-IT haben, werden sie ebenfalls unter dem Begriff
BPRM der IT-Governance subsumiert.7
BPRM der IT-Governance bieten methodische Unterstützung für die Gestaltung der
Unternehmens-IT, sowie die Möglichkeit, die „gelungene― Gestaltung der
Unternehmens-IT durch Zertifikate o.ä. öffentlich und allgemein vergleichbar
nachzuweisen.
Die existierenden BPRM und deren Bestandteile wurden aus verschiedenen Gründen
entwickelt und haben daher unterschiedliche Zielsetzungen, Schwerpunkte und
Prinzipien. Außerdem sind sie von sehr unterschiedlicher Qualität. Die Ausgestaltung
dieser Modelle reicht bspw. von losen Best-Practice-Sammlungen bis hin zu
ausgereiften und bereits etablierten Referenzmodellen. Allen diesen BPRM ist jedoch
gemein, dass ihnen die Wissenschaft bislang eher wenig Aufmerksamkeit
entgegenbrachte.8
Eine intensive Auseinandersetzung mit BPRM der IT-Governance erscheint jedoch
zweckmäßig, da sie eine nachhaltige Verbreitung in der Praxis gefunden haben9 und
eine große Menge an wissenschaftlich bislang ungenutztem konsolidiertem
6
Vgl. IT Governance Institute 2003, S. 6.
Siehe Kapitel: Grundlegende Begriffe – Best-Practice-Referenzmodelle.
8 Besonders zu Beginn des Promotionsvorhabens war nur sehr wenig Literatur zum Thema BPRM der ITGovernance vorhanden. Außnahmen waren u.a. Brown, Grant 2005; Hochstein, Hunziker 2003; de Haes,
van Grembergen 2006; Böhmann, Krcmar 2004. Gegenwärtig gibt es neben dem IT-GovernancePractice-Network der Frankfurt School of Finance & Management einige wenige Forschungsgruppen, die
sich speziell mit den Modellen der IT-Governance beschäftigen. Beispielhafte Publikationen sind:
Simonsson et al. 2010; Simonsson, Johnson 2008; de Haes, van Grembergen 2008; Wagner, Weitzel
2008; Willson, Pollard 2009.
9 Siehe u.a. KPMG September 2004; Deloitte 2005; PWC 2006 und IT Governance Institute 2006.
2
7
(Erfahrungs-)Wissen enthalten. Im Fokus stehen hierbei die Struktur und die praktische
Anwendung von BPRM. Ihr Entstehungsprozess sowie die Weiterentwicklung durch
Rückkopplung sind nicht Bestandteil dieser Arbeit. Der Fokus liegt allein auf der
Anwendung von Best-Practice-Referenzmodellen in Unternehmen, da insbesondere die
Anwendung in Unternehmen Ineffizienzen bergen kann.10 Diese Ineffizienzen stehen im
klaren Gegensatz zur Zielsetzung von BPRM, denn durch die Konstruktion von
unternehmensspezifischen Modellen auf Basis vorgefertigter Modelle oder
Modellbausteine erhofft man sich positive Effekte hinsichtlich der Effektivität und
Effizienz.11
Um die Anwendung von BPRM methodisch zu unterstützen und sie effizient zu nutzen,
ist es zunächst notwendig, die Struktur und die gegenwärtige Anwendung von BPRM
zu analysieren, bevor eine Methode zur Anwendung von BPRM entwickelt werden
kann. Die detaillierten Forschungsfragen und -ziele dieser Arbeit werden im Kapitel
„Forschungsdesign und Aufbau der Arbeit― erläutert.
Grundlegende Begriffe
Für die vorliegende Arbeit sind insbesondere die Begriffe IT-Governance, BestPractice-Referenzmodell und Methode von Bedeutung. In den folgenden Unterkapiteln
werden diese Begriffe daher einzeln erläutert und auf das Ziel dieser Arbeit bezogen.
IT-Governance
Der Begriff IT-Governance wird in Wissenschaft und Praxis bislang uneinheitlich
definiert. Die verschiedenen gängigen Definitionen beschreiben IT-Governance im
Kern als eine Funktion oder eine Aufgabe im Bereich der Unternehmens-IT. Weiterhin
herrscht weitgehend Einigkeit über den Status der IT-Governance als
Führungsaufgabe.12 Damit ist eine Zuordnung der IT-Governance zum Forschungsgebiet
Informationsmanagement verbunden.13
Begriffsabgrenzung und -ausgestaltung der IT-Governance divergieren allerdings zum
Teil erheblich. In diesem Kapitel wird die IT-Governance daher zunächst in das
Informationsmanagement eingeordnet, bevor verschiedene Definitionen vorgestellt
werden, aus denen das IT-Governance-Verständnis dieser Arbeit abgeleitet wird.
Nach Heinrich & Lehner umfasst Informationsmanagement „[…] das Leitungshandeln
(Management) in einem Unternehmen in Bezug auf Information und Kommunikation
10
Vgl. Alter, Goeken 2009 und Siviy et al. 2008.
Siehe u.a. Fettke, Loos 2002, S. 1; Goeken 2002, S. 1; Becker et al. 2004a, S. 1.
12 Von IT-Governance als Führungsaufgabe sprechen bspw. Meyer et al. 2003; Krcmar 2005; Heinrich,
Lehner 2005.
13 Vgl. Heinrich, Lehner 2005, S. 8.
3
11
[…], folglich alle Führungsaufgaben, die sich mit Information und Kommunikation im
Unternehmen befassen.―14
Ähnlich ist auch die Definition von Krcmar, nach der es die wesentliche Aufgabe des
Informationsmanagements ist, „die benötigten Informationen zur richtigen Zeit im
richtigen Format zum Entscheider zu bringen, und die Informationswerkzeuge einer
Organisation effizient und effektiv einzusetzen.―15
Brenner bezeichnet das Informationsmanagement ebenfalls als Führungsaufgabe, die
sich mit dem Erkennen und Umsetzen von Potenzialen der Informations- und
Kommunikationstechnologie in betrieblichen Lösungen beschäftigt.16 Diese
Definitionen von Informationsmanagement legen eine enge Beziehung von
Informationsmanagement und IT-Governance nahe.
Neben dem Begriff Informationsmanagement wird jedoch zuweilen synonym oder
kaum unterschieden auch der Begriff IT-Management verwendet. Auch im
angloamerikanischen Raum werden die Begriffe information systems management,
information management, technology management oder auch IT management
weitgehend synonym verwendet.17 Eine Abgrenzung von IT-Governance und
Informationsmanagement sollte daher auch eine Abgrenzung gegenüber dem Begriff
IT-Management beinhalten.
Booth & Philip beschreiben das information systems management als Rahmenbegriff
(“umbrella term”) und definieren es als: „the managerial and technical strategies and
competencies that significantly improve or add value to the use of information systems
within an organisation.―18
Ebenso bezeichnen Stahlknecht & Hasenkamp das IT-Management als eine Teilaufgabe
des Informationsmanagements. Das Informationsmanagement unterteilen sie hierfür in
zwei Bereiche:
1. Die Aufgabe, den Produktionsfaktor Information zu beschaffen und in einer
geeigneten Informationsstruktur bereitzustellen.
2. Die Aufgabe, die dafür erforderliche IT-Infrastruktur, d.h. die
informationstechnischen
und
personellen
Ressourcen
für
die
Informationsbereitstellung, langfristig zu planen und mittel- und kurzfristig zu
beschaffen und einzusetzen.19
Das IT-Management entspricht nach dieser Definition der zweiten Aufgabe.
Folgt man diesen Definitionen, sind die IT-Governance und auch das IT-Management
dem Informationsmanagement unterzuordnen, also Bestandteile desselben. Demnach
sind die im Bereich IT-Governance und IT-Management verwendeten BPRM per
Definition dem Informationsmanagement zuzuordnen. Für die vorliegende Arbeit ist es
jedoch von Bedeutung, wann ein BPRM explizit dem Bereich IT-Governance
zuzuordnen ist. Denn die Zuordnung eines Modells zum Themengebiet IT-Governance
14
Heinrich, Lehner 2005, S. 8.
Krcmar 2005, S. 31.
16 Vgl. Brenner 1994.
17 Booth, Philip 2005 zeigen einen guten Überblick.
18 Booth, Philip 2005, S. 289.
19 Vgl. Stahlknecht, Hasenkamp 2005, S. 427.
15
4
macht es für diese Arbeit zum relevanten Forschungsgegenstand. Demnach ist es
notwendig, die dem Informationsmanagement untergeordneten Teilgebiete von einander
zu unterscheiden.
Krcmar betrachtet IT-Governance nicht als Teilgebiet des Informationsmanagements,
sondern bezeichnet die IT-Governance als Meta-Ebene des Informationsmanagements.
Demnach ist es die Aufgabe der IT-Governance „[…] ein Gestaltungs- und
Führungssystem für das IM zu entwickeln, einzuführen und laufend
weiterzuentwickeln. Ein solches IM-Planungssystem stellt einen Bezugsrahmen dar, der
es ermöglicht, die Elemente, Strukturen und Prozesse der Planung des IM zu
beschreiben.―20 Sie gibt also den Rahmen vor, in dem sich das Informationsmanagement
bewegen kann. Die IT-Governance ist eine Meta-Gestaltungsaufgabe für die
Gestaltungsaufgaben des Informationsmanagements. Aus dieser Perspektive ist die ITGovernance also dem Informationsmanagement übergeordnet. Nicht näher thematisiert
wird die Abgrenzung zum IT-Management. Krcmar bemerkt hierzu lediglich, dass
besonders in praxisnaher Literatur der Begriff IT-Management synonym zum Begriff
Informationsmanagement verwendet wird.21 Wenn also nach Krcmar IT-Management
und das Informationsmanagement synonym sind, ist IT-Governance die MetaGestaltungsaufgabe des IT-Managements. Dies würde ebenso mit der Definition von
Stahlknecht & Hasenkamp übereinstimmen. Diese unterscheiden jedoch auch zwischen
IT-Management und Informationsmanagement.22
Heinrich
&
Lehner
schreiben
zur
Abgrenzungsproblematik
zwischen
Informationsmanagement, IT-Management und IT-Governance: „IT-Governance ist ein
Rahmenwerk, in dem Teilaufgaben und Prinzipien des Informationsmanagements
umgesetzt werden. Im Unterschied zu anderen, in der Fachliteratur vorgeschlagenen
Rahmenkonzepten […] ist die IT-Governance auf die Unternehmenspraxis ausgerichtet.
Die Komponenten des Modells sind auf den Bedarf des IT-Managements abgestimmt
und stellen eine Orientierungshilfe für die Implementierung von Funktionen und
Aufgaben dar, die auch im Informationsmanagement-Modell vorgesehen sind.―23 Diese
Abgrenzung zielt auf die Darstellung der IT-Governance als pragmatisches und
minimalistisches Konzept, d.h. eines unklar und unsauber abgegrenzten Teils des
Informationsmanagements, denn Heinrich & Lehner formulieren weiter: „Pragmatisch,
weil eine Bezugnahme auf Theorien fehlt und auch keine empirische Absicherung
bekannt ist. Minimalistisch, weil es sich um die Auswahl einiger Komponenten des
Informationsmanagements handelt.―24
Johannsen & Goeken grenzen IT-Management und IT-Governance zeitlich und
bezüglich des primären Blickwinkels voneinander ab. Sie betrachten IT-Governance als
langfristige und stärker nach außen gerichtete Aufgabe.25 Eine Unterteilung der von
ihnen thematisierten Referenzmodelle, etwa in Modelle der IT-Governance und des IT20
Krcmar 2005, S. 289.
Krcmar 2005, S. 28.
22 Stahlknecht, Hasenkamp 2005, S. 427.
23 Heinrich, Lehner 2005, S. 67.
24 Heinrich, Lehner 2005, S. 67.
25 Vgl. Johannsen, Goeken 2007, S. 22.
21
5
Managements nehmen sie jedoch nicht vor. Sie bedienen sich eines sehr weiten ITGovernance-Begriffs und diskutieren BPRM wie COBIT, ITIL, VAL-IT, CMMI u.ä.
unter dem Begriff IT-Governance.26
Einen weiteren Ansatz für eine Unterteilung des Informationsmanagements liefert das
Modell des integrierten Informationsmanagements von Zarnekow & Brenner. Sie
wenden das aus der Logistik stammende SCOR-Modell27 auf das
Informationsmanagement an, um so dem Bild eines integrierten Informationsmanagements gerecht zu werden. Das Informationsmanagement wird hierfür in die fünf
Teilprozesse Source, Deliver, Make, Plan und Enable aufgeteilt. Diese Teilprozesse
werden für eine Abgrenzung der verschiedenen Begriffe verwendet. Der
Themenkomplex IT-Governance, vertreten durch das BPRM COBIT, ist nach diesem
Konzept dem Teilprozess Plan zuzuordnen, das IT-Managemenent, vertreten durch
ITIL, wird der Phase Make zugeordnet.28
Knolmayer & Loosli definieren den Begriff IT-Governance in einer nach außen und
einer nach innen gerichteten Sichtweise. Die nach außen gerichtete Sichtweise leitet
sich aus dem Konzept der Corporate Governance ab. Die IT-Governance legt demnach
Rahmenbedingungen für das IT-Management fest.29 Eine nach innen gerichtete
Definition von IT-Governance bezieht sich auf die möglichst effiziente und effektive
Gestaltung von IT-Systemen und den damit verbundenen organisatorischen Strukturen
und Prozessen. Dabei stehen die Entscheidungs-, Gestaltungs- und Umsetzungsprozesse
im IT-Bereich im Vordergrund, die auch unter dem Begriff IT-Management subsumiert
werden können.30
Eine solche auf die Corporate Governance ausgerichtete Definition benutzen auch
Meyer et al. Sie bezeichnen die IT-Governance als „IT-bezogene Spezialisierung der
unter dem Begriff Corporate Governance zusammengefassten Vorschläge und
Konzepte.―31
Diese Unterteilung der IT-Governance trägt nach Strecker zu den
Abgrenzungsproblemen der IT-Governance bei.32 Die nach außen gerichtete Sichtweise
korrespondiert mit einem „engen― IT-Governance-Begriff, welcher sich klarer als der
nach innen gerichtete IT-Governance-Begriff von den Zielen und Aufgaben des
Informationsmanagements abgrenzen lässt. Die nach innen gerichtete Sichtweise
subsumiert hingegen Aufgaben unter dem Begriff IT-Governance, die auch dem ITManagement zugerechnet werden. Hierzu gehören etwa das Ressourcenmanagement33
26
Vgl. Johannsen, Goeken 2007.
Supply Chain Operations Reference Model.
28 Vgl. Zarnekow et al. 2006, S. 62.
29 Knolmayer et al. o.J. mit weiteren Verweisen auf Shleifer, Vishny 1997, S. 737 und Weill, Ross 2004,
S. 8.
30 Vgl. Knolmayer et al. o.J.
31 Meyer et al. 2003, S. 445.
32 Vgl. Strecker 2009, S. 2.
33 Vgl. Krcmar 2005.
6
27
oder die Erfolgsmessung.34 Bezüglich der nach innen gerichteten Sichtweise ist eine
Unterscheidung zwischen IT-Governance und IT-Management also bislang unklar.35
Zusammenfassend
ist
die
IT-Governance
also
ein
Bestandteil
des
Informationsmanagements und wird den Führungsaufgaben zugeordnet. Das Verhältnis
zum IT-Management ist im Bezug auf den Begriff Informationsmanagement einerseits
gleichrangig, jedoch legt die IT-Governance den Rahmen für das IT-Management fest,
ist also dessen Meta-Aufgabe.
Es bleibt daher festzuhalten, dass es BPRM für die verschiedenen Bereiche des
Informationsmanagements geben kann. So sind alle BPRM, die die Führungsaufgabe IT
thematisieren, zwar zunächst dem Informationsmanagement zuzuordnen, müssen jedoch
nicht zwangsläufig BPRM der IT-Governance sein. Für eine Zuordnung zu diesem
Bereich und damit zum Forschungsgegenstand dieser Arbeit ist eine inhaltliche
Beurteilung der BPRM notwendig. Der folgende Abschnitt beschäftigt sich daher mit
der inhaltlichen Abgrenzung des Begriffs IT-Governance.
Das IT Governance Institute (ITGI) betont die Verantwortlichkeit der
Unternehmensführung für die IT-Governance und stellt die Unterstützung bei der
Erreichung von Unternehmenszielen in den Mittelpunkt.
„IT governance is the responsibility of the board of directors and executive
management. It is an integral part of enterprise governance and consists of the
leadership and organizational structures and processes that ensure that the
organization‘s IT sustains and extends the organization‘s strategies and
objectives.―36
Inhaltlich betont das ITGI zwei Kernbereiche der IT-Governance. Es stellt das Erzielen
eines Wertbeitrags durch die IT und das IT-Risikomanagement in den Fokus der ITGovernance.
„IT governance is concerned about two responsibilites: IT must deliver value and
enable the business, and IT-related risks must be mitigated. [...] Governance of IT
encompasses several initiatives for board members and executive management.
They must be aware of the role and impact of IT on the enterprise, define
constraints within which IT professionals should operate, measure performance,
understand risk, and obtain assurance.―37
Webb et al. betonen ebenfalls die inhaltlichen Kernbereiche der IT-Governance.
―IT governance is the strategic alignment of IT with the business such that
maximum business value is achieved though the development and maintenance of
effective IT control and accountability, performance management, and risk
management.‖38
34
Vgl. Baumöl 2008.
Einen aktuellen Überblick über die Möglichkeit IT-Governance in Abhängigkeit von der Corporate
Governance zu definieren geben auch Webb et al. 2006.
36 IT Governance Institute 2003, S. 19.
38 Webb et al. 2006, S. 201.
7
35
Die oft zitierte Definition von Weill & Ross stellt hingegen Verantwortlichkeiten und
die damit verbundenen Entscheidungsrechte in den Vordergrund. Außerdem betonen sie
den Unterschied zwischen IT-Governance und dem klassischen Management. Ähnlich
der Unterscheidung von Krcmar sehen sie IT-Governance als Meta-Aufgabe für die
Entscheidungsfindung bspw. im IT-Management.39
„IT governance: Specifying the decision rights and accountability framework to
encourage desirable behavior in the use of IT. IT governance is not about making
specific IT decisions – management does that – but rather determines who
systematically makes and contributes to those decisions.―40
Ähnlich beschreiben auch Simonsson & Ekstedt den Begriff IT-Governance.
„IT governance is about IT decision-making: The preparation for, making of and
implementation of decisions regarding goals, processes, people and technology on
a tactical and strategic level.―41
Abweichend davon stellen De Haes & van Grembergen die wünschenswerten
organisatorischen Fähigkeiten des Managements in den Vordergrund. Sie betrachten ITGovernance als Fähigkeit der Unternehmensführung, ihre Aufgaben bei der
Strategieumsetzung und der Herstellung des Business-IT-Alignments wahrzunehmen.42
„IT governance is the organizational capacity exercised by the Board, executive
management and IT management to control the formulation and implementation of
IT strategy and in this way ensure the fusion of business and IT.―43
Ähnlich zur Definition von De Haes & van Grembergen betont der einschlägige ISOStandard ISO 38500 die Gestaltung und Kontrolle der Zukunftsfähigkeit der
Unternehmens-IT.
―The system by which the current and future use of IT is directed and controlled.
Corporate Governance of IT involves evaluating and directing the use of ICT to
support the organisation and monitoring this use to achieve plans. It includes the
strategy and policies for using IT within an organization.‖44
Für die vorliegende Arbeit sind diese Definitionen von Bedeutung, da ein BPRM,
welches aufgrund einer dieser Definitionen der IT-Governance zuzurechnen ist, zum
Forschungsgegenstand dieser Arbeit gehört. Die bislang vorgestellten Definitionen
beschreiben den Begriff IT-Governance jedoch jeweils aus unterschiedlichen
inhaltlichen Blickwinkeln, was das Begriffsverständnis der IT-Governance sehr vage
und kontextabhängig erscheinen lässt. Für diese Arbeit werden daher die Schwerpunkte
der gängigen IT-Governance-Definitionen als gemeinsame Definition verwendet.
39
Johannsen, Goeken 2007, S. 21.
Weill, Ross 2004, S. 2.
41 Simonsson, Ekstedt 2006, S. 1.
42 Vgl. Johannsen, Goeken 2007, S. 22.
43 van Grembergen 2007.
44 ISO/IEC 38500, S. 3.
40
8
In Anlehnung an die vorhandene Literatur ist IT-Governance in dieser Arbeit definiert
als
 Führungsaufgabe,45
 die den Aufbau von IT-Strukturen und IT-Prozessen thematisiert.46
 Sie definiert die Grenzen des IT-Managements, d.h. die Grenzen innerhalb derer
sich IT-Mitarbeiter und IT-Führungskräfte bewegen können.47
 Sie beinhaltet die Entwicklung und Umsetzung von effektiven IT-Kontrollen48,
Verantwortlichkeiten, Entscheidungsrechten und Entscheidungsprozessen,49
sowie
 die Umsetzung der IT-Strategie und deren Verankerung in der
Geschäftsstrategie.50
 Sie trägt demnach dazu bei, ein Informationssystem aufzubauen, das den
gegenwärtigen und auch den zukünftigen Anforderungen gewachsen ist.51
BPRM, die eine so definierte IT-Governance adressieren, stehen im Fokus dieser
Arbeit.
Best-Practice-Referenzmodell
Forschungsgegenstand dieser Arbeit sind Best-Practice-Referenzmodelle der ITGovernance.52 Im vorangegangenen Kapitel wurde dargestellt, wann ein BPRM dem
Bereich IT-Governance zuzuordnen ist. Ziel dieses Kapitels ist es nun, den Begriff
BPRM zu beschreiben und zu erläutern, warum dieser Begriff in der vorliegenden
Arbeit etablierten Begriffen wie Referenzmodell oder Best-Practice vorgezogen wurde.
Zunächst wird grundlegend auf den Modellbegriff der Wirtschaftsinformatik
eingegangen, da dieser notwendig ist, um den Forschungsgegenstand dieser Arbeit
näher zu spezifizieren. Im zweiten Teil dieses Kapitels wird der Forschungsgegenstand
unter Bezugnahme auf die Begriffe Referenzmodell und Best-Practice erläutert, um eine
Abgrenzung der Begriffe zu ermöglichen.
45
Vgl. Meyer et al. 2003; Krcmar 2005; Heinrich, Lehner 2005.
Vgl. IT Governance Institute 2003, S. 19
47 Vgl. Krcmar 2005, S. 289; Stahlknecht, Hasenkamp 2005, S. 427; IT Governance Institute 2005, S.
167; Simonsson, Johnson 2008; Simonsson, Ekstedt 2006.
48 Im Bereich der Wirtschaftsprüfung wird der Begriff Control verwendet. Nach Fröhlich, Glasner 2007,
S. 57 sind Controls „Maßnahmen, die zur Riskiominimierung in Prozessen aller Art dienen―. Ein Beispiel
für eine Control ist das 4-Augen-Prinzip.
49 Vgl. Weill, Ross 2004, S. 2.
50 Vgl. van Grembergen 2007; Webb et al. 2006.
51 Vgl. ISO/IEC 38500, S. 3.
52 Siehe Teil A - Kapitel: Forschungsdesign und Aufbau der Arbeit.
9
46
Für den Modellbegriff in der Wirtschaftsinformatik gibt es zwei konkurrierende
Verständnisse, zum einen den abbildungsorientierten und zum anderen den
konstruktionsorientierten Modellbegriff.53
Der abbildungsorientierte Modellbegriff stellt das von Stachowiak beschriebene
Abbildungsmerkmal in den Vordergrund. Modelle werden als immaterielle und
abstrakte Abbilder der Realität für Zwecke eines Subjekts interpretiert.54 Laut vom
Brocke ist dieser Modellbegriff als Standard in den Wirtschaftswissenschaften und
weniger deutlich auch in der Wirtschaftsinformatik anzusehen.55 Ein
abbildungsorientiertes Modell bildet Teile der Realwelt vereinfacht in einer Modellwelt
ab, um letztendlich Ziele und Handlungen in der Realwelt zu verstehen und zu
unterstützen. Deshalb ist es notwendig, eine zielgerechte Eingrenzung der Realwelt
vorzunehmen. Diese wird als Diskurswelt bezeichnet.56 Die Diskurswelt wird durch
Interpretation in ein mentales Objektsystem abgebildet, welches zum Modellsystem und
letztlich zum Modell externalisiert wird. Diesem Modellbegriff liegt eine naivrealistische Erkenntnisposition zu Grunde. Diese setzt voraus, dass eine Realwelt
existiert, deren Elemente subjektunabhängig wahrnehmbar sind, d.h. eine objektive
Erkenntnis möglich ist.57 Kritik am abbildungsorientierten Modellbegriff begründet sich
vor allem in dieser naiv-realistischen Erkenntnisposition.58
Demgegenüber beinhaltet der konstruktionsorientierte Modellbegriff die Subjektivität
der Wahrnehmung. Schütte definiert:
„Ein Modell ist das Ergebnis einer Konstruktion eines Modellierers, der für
Modellnutzer eine Repräsentation eines Originals zu einer Zeit als relevant
mithilfe einer Sprache deklariert. Ein Modell setzt sich somit aus der Konstruktion
des Modellierers, dem Modellnutzer, einem Original, der Zeit und der Sprache
zusammen.―59
Die Beziehung zwischen der Erkenntnis und dem Erkenntnisgegenstand wird immer
durch das Subjekt geprägt, d.h. die Erkenntnis ist subjektiv.60 Dies ist für diese Arbeit
von Bedeutung, da die Modelle Vorbild für spezifische Unternehmensmodelle sind. Bei
dem Modellierungsprozess eines unternehmensspezifischen Modells nimmt das BPRM
die Stelle eines Soll-Modells ein. Die Ausgestaltung der Unternehmensmodelle ist
abhängig von der Wahrnehmung des Subjekts (d.h. des anwendenden Unternehmens).
Ginge man hierbei von einem abbildungsorientierten Modellbegriff und somit von
subjektunabhängiger Wahrnehmung aus, müssten alle unternehmensspezifischen
Abbilder des Soll-Modells (d.h. des BPRM) identisch sein. Die Erstellung von
unternehmensspezifischen Modellen unter Verwendung des BPRM als Vorbild ist
jedoch, nach Ansicht der Verfasserin, ein von der Wahrnehmung des erstellenden
53
Einen guten Überblick über die relevante Literatur bietet vom Brocke 2003, S. 10, insbesondere die
Übersicht in den Fußnoten 41-46.
54 Siehe u.a. Stachowiak 1983, S. 118; Stachowiak 1973 oder auch Vossen, Becker 1996, S. 19.
55 Vgl. vom Brocke 2003, S. 10. Einen Überblick bietet auch Schütte 1998, S. 46 ff.
56 Siehe u.a. Goeken 2006; Rautenstrauch, Schulze 2003; Ferstl, Sinz 2008.
57 Vgl. Becker et al. 2004b, S. 5.
58 Siehe zur Kritik u.a. Zelewski 1999, S. 46 und vom Brocke 2003, S. 11.
59 Schütte 1998, S. 59.
60 Vgl. Becker et al. 2004b, S. 4.
10
Subjekts abhängiger Prozess. Für diese Arbeit wird daher der konstruktionsorientierte
Modellbegriff verwendet. Dies begründet sich in der Verwendung von BPRM als
Vorgabe für ein Unternehmensmodell, das subjektabhängig nach den Vorgaben des
BPRM gestaltet wird.
Der konstruktionsorientierte Modellbegriff und insbesondere die Definition von Schütte
sind also für die vorliegende Arbeit bedeutsam.
An dieser Stelle wird deutlich, dass BPRM konstruktionsorientierte Modelle im Sinne
der Wirtschaftsinformatik sind. Ihre Eigenschaften sollten jedoch detaillierter erläutert
werden. Insbesondere die Beziehung von Modellierer und Modellnutzer61 und die Frage,
was ein BPRM beinhaltet, stehen im Fokus des nächsten Abschnittes. Bezüglich ihres
Inhalts werden BPRM im Folgenden unter Bezugnahme auf den Begriff
Referenzmodell diskutiert. Der Beziehung von Modellierer und Modellnutzer wird
durch die Beschreibung des Entstehungsprozesses von BPRM Rechnung getragen.
Informationsmodelle sind innerhalb der Wirtschaftsinformatik ein zentrales Instrument
zur Gestaltung betrieblicher Informationssysteme und haben bereits seit Jahrzehnten
Tradition. Um die Entwicklung von unternehmensspezifischen Modellen zu verbessern,
wird innerhalb der Literatur das Konzept der Referenzmodellierung vorgeschlagen.62
Hars definiert als einer der ersten Autoren den Begriff Referenzmodell folgendermaßen:
„Bei einem Referenzmodell handelt es sich um ein Modell, das für den Entwurf
anderer Modelle herangezogen werden kann.―63
Vom Brocke definiert weiter:
„Ein Referenzmodell ist ein Informationsmodell, das Menschen zur Unterstützung
der Konstruktion von Anwendungsmodellen entwickeln oder nutzen, wobei die
Beziehung zwischen Referenzmodell und Anwendungsmodell dadurch
gekennzeichnet ist, dass Gegenstand oder Inhalt des Referenzmodells bei der
Konstruktion des Gegenstands oder Inhalts des Anwendungsmodells wieder
verwendet werden.―64
Nach diesen Definitionen sind BPRM den Referenzmodellen zuzuordnen, da sie
entwickelt und genutzt werden, um unternehmensspezifische Modelle abzuleiten (siehe
bspw. Fachbeitrag 6).
Becker et al. betonen hingegen den formalen Aspekt von Referenzmodellen, was eine
Zuordnung von BPRM wie ITIL oder COBIT zu den Referenzmodellen erschwert, da
sie den Anforderungen an konzeptionelle Modelle nicht oder nur bedingt genügen.
„Reference models are generic conceptual models that formalize state-of-the-art
or best-practice knowledge of a certain domain. They are of normative nature and
can cover different domains.―65
61
Diese Problematik wird bereits von Schütte 1998 thematisiert.
Siehe u. a. Hars 1994; Becker 1995; Frank 1999; Scheer et al. 2002; Becker et al. 2002b; Goeken 2002;
Becker 2004; Loos, Fettke 2005.
63 Hars 1994, S. 15.
64 vom Brocke 2003, S. 34.
65 Becker et al. 2007, S. 2.
11
62
Dass ein Referenzmodell ein Informationsmodell ist, welches aktuelles Best-PracticeWissen beinhaltet66, in verschiedenen Anwendungskontexten Verwendung finden soll67
und als Vorbild für Unternehmensmodelle gilt68, schließt BPRM hingegen ein. Denn
BPRM enthalten Best-Practice-Wissen, sie werden von Praktikern (mit-)erstellt und
enthalten fundiertes und konsolidiertes Erfahrungswissen aus einem spezifischen
Bereich und haben die Tendenz, sich zu Quasi-Standards zu entwickeln (Beispiele:
COBIT69, ITIL70, CMMI71).
Auch die Definition von Goeken zeigt, dass BPRM grundsätzlich Referenzmodelle
sind.
„Ein Referenzmodell ist eine Empfehlung, die für die Entwicklung konkreter
Modelle nützlich ist. Es stellt allgemein gültige Lösungsvorschläge für eine
(abstrakte) Klasse von Problemen dar und unterstützt die auf konkrete
Aufgabenstellungen bezogene Problemlösung, indem es einen Ausgangspunkt bietet
und als Modellmuster für eine Klasse zu modellierender Sachverhalte herangezogen
werden kann.―72
Weiter unterteilt Goeken die Referenzmodellierung73 nach Fettke und Loos74 in die
Konstruktion eines Referenzmodells und dessen Anwendung. Diese Unterscheidung
leitet zu der in dieser Arbeit verwendeten Abgrenzung von Referenzmodell und BPRM
über.
Wie bereits von Hars beschrieben, herrscht in der Literatur weitgehende Einigkeit über
zwei zentrale Aspekte von Referenzmodellen. Diese Aspekte sind der
Empfehlungscharakter und die Allgemeingültigkeit von Referenzmodellen.75 Aus diesen
Aspekten ergibt sich jedoch ein wesentliches Problem, bei dem die Entstehung von
Referenzmodellen von entscheidender Bedeutung ist. Wird ein Referenzmodell – wie
bei vom Brocke beschrieben – durch Deklaration zum Referenzmodell, ist die Qualität
und damit die Allgemeingültigkeit des Modells nicht gewährleistet.76 Auch Schütte weist
darauf hin, dass mit der Deklaration eines Modells als Referenz die Behauptung
einhergeht, das Modell repräsentiere Best-Practice.77 Diese Behauptung lässt sich aber
nicht prüfen. Schütte leitet daraus die Forderung ab, dass Referenzmodelle streng
begutachtet werden müssen.78 Schwegmann weist darauf hin, dass die Akzeptanz des
66
Vgl. Fettke, Loos 2003; Rosemann, van der Aalst 2007.
Siehe u.a. Becker et al. 2004a; Loos, Fettke 2005; Schütte 1998.
68 Siehe u.a. vom Brocke 2003, S. 31; Fettke, Loos 2002, S. 9; Goeken 2002, S. 1.
69 IT Governance Institute 2007.
70 OGC 2007a, OGC 2007b, OGC 2007c, OGC 2007d, OGC 2007e.
71 Software Engineering Institute 2007.
72 Vgl. Goeken 2002, S. 3.
73 Hier nicht als Konstruktion des Referenzmodells verstanden, sondern in Anlehnung an vom Brocke als
ein spezielles Arbeitsgebiet der Informationsmodellierung, in dem Referenzmodelle betrachtet werden
(vom Brocke 2003, S. 38).
74 Vgl. Fettke, Loos 2002, S. 10.
75 Vgl. Fettke 2006, S. 20.
76 Vgl. Fettke 2006, S. 25.
77 Vgl. Schütte 1998, S. 300.
78 Fettke, Loos 2004 entwickeln einen Bezugsrahmen für die Evaluierung von Referenzmodellen und
bieten einen guten Überblick über die Möglichkeiten der Referenzmodellevaluation.
12
67
Referenzmodells durch den Benutzer ein mögliches Evaluationskriterium für
Referenzmodelle ist.79
Zusammenfassend kann festgehalten werden, dass Referenzmodelle bereits durch
Deklaration zur Referenz werden können. Eine Evaluation und Legitimation werden
zwar weithin gefordert, finden jedoch nicht zwangsläufig statt. Diese Legitimation
grenzt nun die in dieser Arbeit als BPRM bezeichneten Modelle vom allgemeinen
Referenzmodellbegriff ab. BPRM sind nach Ansicht der Verfasserin eine besondere
Form von Referenzmodellen, die sich durch ihre Entstehung und Legitimation
auszeichnen.80 Deutlich wird dies anhand des nachfolgend beschriebenen
Entstehungsprozesses von BPRM.81
Der Begriff Best-Practice wird im deutschsprachigen Raum wörtlich als bestes
Verfahren oder freier mit dem Begriff Erfolgsmethode übersetzt. Im Allgemeinen
bezeichnen die Begriffe folgenden Zusammenhang: Ein Unternehmen, das in einem
bestimmten Bereich bewährte und kostengünstige Verfahren, technische Systeme und
Geschäftsprozesse einsetzt, kann in diesen Bereichen als Muster für andere
Unternehmen gelten.82 Dieses Unternehmen wird dann als Best-Practice-Unternehmen
bezeichnet. Voegele & Zeuch ermittelten 2002, dass im Bereich des Supply Chain
Managements 4% der deutschen Unternehmen zu dieser höchsten Entwicklungsstufe
gehören. Sie ermitteln sechs Entwicklungsstufen, von denen die oberste Best-Practice
ist. Ihre Analyse ergab folgende Verteilung: 15% Non-Performance, 10% LowPerformance, 39% Aufbruch, 23% Basis, 9% Verfolger und 4% Best-Practice.83 BestPractices haben wiederum diese wenigen Unternehmen als Basis. Das Best-PracticeWissen wird geordnet und dem Markt zugänglich gemacht.
Neben Best-Practice wird auch der Begriff Best-Current-Practice (bestes derzeitiges
Verfahren) verwendet, welcher speziell die temporäre Gültigkeit der ausgesprochenen
Empfehlungen betont.84 Davenport spricht von Industrial-Practice und betont damit die
branchenbezogene Gültigkeit von Best-Practices.85 Weiterhin wird in der
Wirtschaftsinformatik, speziell im Bereich der Standardsoftware-Forschung86, der
79
Vgl. Schwegmann 1999, S. 61.
Neben dem in dieser Arbeit verwendeten Begriff BPRM werden in den wenigen vorhandenen
Publikationen auch andere Begriffe verwendet. COBIT wird bspw. von Simonsson et al. als „best practice
based framework― bezeichnet (Simonsson et al. 2010, S. 10). ITIL wird von Hochstein et al. als
„Common-Practice-Referenzmodell― benannt (Hochstein et al. 2004, S. 382).
81 Wagner et al. 2006 betonen, dass die Entstehung von Best-Practices in der wissenschaftlichen Literatur
bislang nur unzureichend thematisiert wird.
82 Siehe u.a. Szulanski 1996; Wagner, Newell 2004; Davenport 2000; Newell et al. 2000; Reijers, Liman
Mansar 2005.
83 Vgl. Voegele 2002, S. 13.
84 Zur Variabilität und Dynamik von Best-Practices siehe u.a. Codling 1997.
85 Vgl. Davenport 2000; siehe hierzu auch Klaus et al. 2000.
86 Siehe u.a. Mertens 1997, der den Stellenwert von Best-Practices kritisch betrachtet oder Wagner,
Newell 2004, die Best-Practices im Umfeld von ERP-Software untersuchen und sich dabei auf das
Machtverhältnis von Anbieter und Käufer beziehen. In einem späteren Artikel thematisieren sie die
Entwicklung von Best-Practice-ERP-Software (Wagner et al. 2006). Lee, Lee 2000 betonen den
Wissenstransfer durch die Anwendung von Best-Practices. Siehe außerdem Chapman, Ward 2004.
13
80
Begriff Common-Practice als betriebswirtschaftlich günstigere Alternative zu BestPractice diskutiert.87
Aus der Aggregation des Wissens einzelner Best-Practice-Unternehmen entsteht ein
BPRM, welches als Muster für andere Unternehmen gelten kann. Nach vom Brocke ist
dies „die Verdichtung von Wahrnehmungen zu Inhalten eines Gegenstandes, um auf
diese Weise einem spezifischen Zweck zu dienen.―88 Ein Beispiel für den Bereich ITGovernance sind die Control Objectives for Information and related Technology
(COBIT), die das konsolidierte Wissen der in der Information Systems Audit and
Control Association (ISACA) organisierten IT-Prüfer, IT-Auditoren, IT-Berater etc.
enthalten. Sie verdichten ihr Wissen mit dem Ziel, allgemein akzeptierbare Methoden,
Prozesse, Eigenschaften etc. zu definieren.
Der Entstehungsprozess von BPRM erinnert an die konsensorientierte
Referenzmodellierung, deren maßgebliche Grundposition die Entstehung von Wahrheit
durch den Konsens einer sachverständigen Sprachgemeinschaft ist.89 Becker betont
hierbei, dass „dieses Verständnis vor allem hinsichtlich der intersubjektiven Gültigkeit
von in Referenzmodellen enthaltenen Aussagen besondere Bedeutung entfaltet.―90 Folgt
man diesem Verständnis, so sind BPRM konsensorientierte Referenzmodelle.
Der Prozess der Konsensbildung ist im Falle der BPRM jedoch nicht zufällig. Er wird
von den herausgebenden Institutionen unterstützt und gefördert.91 Eine solche
Organisation ist beispielsweise der Berufsverband der praxisorientierten InformationSystems-Fachleute (ISACA92) für das BPRM COBIT, das Software Engineering
Institute (SEI), welches seit 1987 CMMI verantwortet oder das Office of Government
Commerce (OGC) und das IT-Servicemanagement-Forum (ITSMF) für ITIL. Nach
Ansicht der Verfasserin ist ein Best-Practice-Referenzmodell folglich nur dann als
solches zu bezeichnen, wenn es einen fortwährenden Prozess der Anwendung und
Verbesserung durchläuft und dieser Prozess durch herausgebende Institutionen und
Verbände unterstützt wird.
Zusammenfassend
kann
festgehalten
werden:
BPRM
folgen
einem
konstruktionsorientierten Modellverständnis, sind durch Konsens legitimiert und ihr
Weiterentwicklungsprozess wird durch eine Organisation unterstützt und verantwortet.
BPRM sind in dieser Arbeit daher folgendermaßen definiert.
Ein Best-Practice-Referenzmodell ist eine Sammlung von konsolidiertem und
legitimiertem Wissen einer Domäne, die durch aktive Konsensbildung der
organisierten relevanten Subjekte entstanden ist.
87
Eine generelle Unterscheidung von Best-Practice und Common-Practice thematisieren bspw. Becker et
al. 2002a; Schwegmann 1999, S. 53 und Scheer 1999, S. 3.
88 vom Brocke 2003, S. 16 betont hierbei, dass Abbildung wie bei Stachowiak 1973 im Wortsinn und
nicht im Sinne des abbildungsorientierten Modellbegriffs der Wirtschaftsinformatik zu sehen ist.
89 Vgl. Becker 2004; Zelewski 1999.
90 Becker et al. 2004b, S. 10.
91 Die ISACA erarbeitet zurzeit die fünfte Version von COBIT. Hierfür wird zunächst ein Entwurf online
zur Diskussion gestellt, gleichzeitig stehen Kommentarfunktionen, Fragebögen usw. zur Verfügung. Ziel
ist es, COBIT 5 durch den Konsens von Sachverständigen zu entwickeln und zu legitimieren.
92 Derzeit hat die ISACA 86.000 Mitglieder in 160 Ländern (Stand 2010).
14
BPRM sind demnach eine spezielle Form von Referenzmodellen, die nicht bereits durch
Deklaration oder Akzeptanz zur Referenz werden,93 sondern erst durch gezielte
Legitimation.
Methode
Die Erstellung von Informationssystemen erfordert ein ingenieurmäßiges und
zielorientiertes Vorgehen. In der Wirtschaftsinformatik-Literatur herrscht weitgehend
Einigkeit darüber, dass die Verwendung von Methoden die Basis für ein solches
ingenieurmäßiges Vorgehen darstellt.94 Da es ein Ziel dieser Arbeit ist, eine Methode zu
entwickeln, die die Anwendung von BPRM in Unternehmen unterstützt, wird in diesem
Abschnitt der Methodenbegriff der Wirtschaftsinformatik vorgestellt.
Ein wesentliches, in der Literatur weitgehend unbestrittenes Merkmal von Methoden ist
die Zielorientierung. Nach Stahlknecht & Hasenkamp, Balzert oder Hesse dient eine
Methode der Erreichung festgelegter Ziele.95 Becker beschreibt eine Methode als das
systematische Vorgehen beim Lösen von Problemen. Ein Problem wiederum ist
charakterisiert als die Diskrepanz zwischen dem Ist- und dem Soll-Zustand.96
Die Erstellung von Methoden steht im Fokus des Forschungsbereichs MethodenEngineering. Das Methoden-Engineering ist ein viel diskutiertes und etabliertes
Konzept in der konstruktionsorientierten Wirtschaftsinformatik. Der Forschungsbereich
Methoden-Engineering beschäftigt sich mit der ingenieurmäßigen Entwicklung von
Methoden. Brinkkemper definiert:
„Method Engineering is the engineering discipline to design, construct and adapt
methods, techniques and tools for the development of information systems.―97
Methoden selbst sind demnach Gegenstand der Entwicklung. Im Methoden-Engineering
wird eine Methode als ein umfassendes Konzept gesehen, welches den gesamten
Entwicklungsprozess strukturiert. Es bezieht sich demnach nicht nur auf Teilaufgaben
oder isolierte Phasen des Entwicklungsprozesses. Eine Methode strukturiert vielmehr
den gesamten Entwicklungsprozess. Ziel des Methoden-Engineerings ist es, Methoden
mittels eines strukturierten Vorgehens zu entwickeln.
Nachdem allgemein anerkannt ist, dass keine universelle Methode existiert98, haben sich
im Forschungsbereich der Methodenkonstruktion Strömungen wie domain specific
method engineering99 und situational method engineering100 entwickelt. Diese
Forschungsbereiche sind zurzeit vor allem durch die Systementwicklung und deren
verwandte Disziplinen geprägt. So beschäftigt sich ein Großteil der vorhandenen
93
Siehe vom Brocke 2003.
Vgl. Braun et al. 2004.
95 Vgl. Stahlknecht, Hasenkamp 2005; Balzert 1998; Hesse et al. 1992.
96 Vgl. Becker et al. 2007, S. 1.
97 Brinkkemper 1996, S. 276.
98 Siehe u.a. Brooks 1987; Fitzgerald et al. 2003.
99 Vgl. Kelly et al. 2005.
100 Vgl. Brinkkemper 1996; Brinkkemper et al. 1999; Harmsen 1997.
94
15
Literatur zum Thema Methodenentwicklung mit der Entwicklung von Software, diese
Konzepte sind aber möglicherweise so generisch, dass sie auch auf eine Methode zur
Anwendung von BPRM angewendet werden können.101
Grundlegend gibt es zwei Wurzeln innerhalb des Methoden-Engineerings. Die Ansätze
der Methodenkonstruktion, die auf der Beschreibung von Aktivitäten aufbauen, stellen
Aspekte des Projektmanagements und der Reihenfolgeplanung von Aktivitäten in den
Vordergrund. Diese Ansätze kommen zumeist aus der Geschäftsprozessmodellierung
und sollen etablierte Techniken dieses Forschungsgebiets, wie etwa die Simulation
verschiedener Anordnungen der Aktivitäten, ermöglichen. Demgegenüber stehen die
aus der Arbeits- und Organisationspsychologie motivierten kommunikationsorientierten
Ansätze.102
In der Wirtschaftsinformatik, vor allem in der europäischen, ist zurzeit das von der
Universität St. Gallen geprägte Methodenverständnis vorherrschend.103 Deren Ansatz
einer sprachkritischen Konstruktion von Methodenkomponenten fokussiert die
Ausgestaltung und Abgrenzung der geschaffenen Artefakte. Ziel hierbei ist es, die
Methoden-Komponenten (etwa Aktivitäten, Ergebnisse oder Techniken) möglichst
redundanzfrei und eindeutig zu beschreiben. Der Ansatz kommt zwar nicht aus dem
Geschäftsprozessmanagement, es ist jedoch anzumerken, dass bestimmte Aspekte (wie
bspw. die Reihenfolgeplanung und die beteiligten Unternehmenseinheiten) ebenfalls
Bestandteil der sprachkritisch ausgelegten Forschungsansätze des MethodenEngineerings sind.104 Das St. Gallener Methodenverständnis ist also eher den
aktivitätsbasierten Ansätzen zuzurechnen.
Eine Methode wird in dieser Arbeit zunächst „als Tupel aus einem Aufgabentyp und
einer Menge von Regeln aufgefasst.―105 Nach Zelewski sind aber nicht alle denkbaren
Tupel automatisch eine Methode. Damit von einer Methode gesprochen werden kann,
muss sichergestellt werden, dass gewisse Qualitätsanforderungen eingehalten werden.106
Zum Beispiel sollen Methodenbestandteile und deren Beziehungen eindeutig
interpretierbar sein. D.h. es sollte eine weitgehend einheitliche Methodendokumentation
verwendet werden. Dies erfordert eine „sprachkritische Rekonstruktion der
Methodenbestandteile―107 und eine formalisierte Dokumentation derselben.
Der St. Gallener Ansatz des Methoden-Engineerings108 beschreibt einen solchen
„systematischen und strukturierten Prozess zur Entwicklung, Modifikation und
Anpassung von Softwareentwicklungsmethoden durch die Beschreibung der
101
So zeigt etwa Börner 2010 eine situationsspezifische Methode für die Identifikation von Services.
Kueng et al. 1996, S. 96 beschreiben activity-oriented approaches welche Aktivitäten, den
Informationsfluss, beteiligte Unternehmenseinheiten und Daten fokussieren. Demgegenüber beschreiben
sie die speech-act approaches, die eine klare und eindeutige Kommunikation der Beteiligten
thematisieren. Siehe auch Kaschek 1999.
103 Vgl. Brinkkemper et al. 1996; Ralyté, Rolland 2001; Karlsson, Wistrand 2006.
104 Bspw. beinhaltet der Ansatz von Heym 1993 die Komponenten Aktivitätshierachiediagramm und
Aktivitätskompostitionsdiagramm, die die Aktivitäten in eine Hierarchie und eine Reihenfolge bringen.
105 Becker et al. 2001, S. 5.
106 Vgl. Zelewski 1999.
107 Becker et al. 2001, S. 6.
108 Basiert auf den Ergebnissen von Heym 1993; Gutzwiller 1994; Becker 1998.
16
102
Methodenkomponenten und ihrer Beziehungen.―109 Das Beschreibungsmodell beinhaltet
die schematische Zusammenstellung der Komponenten Metamodell, Ergebnis,
Aktivität, Technik und Rolle.110
Aktivitäten sind definiert als funktionale Verrichtungseinheiten, die Ergebnisse erstellen
und von Rollen (z.B. Personen, Stellen oder Organisationseinheiten) ausgeführt werden.
Nach Gutzwiller entsteht außerdem ein Vorgehensmodell, wenn Aktivitäten in eine
bestimmte Reihenfolge gebracht werden.111 Ergebnisse haben eine klar definierte Form
und werden in definierten und strukturierten Ergebnisdokumenten erfasst. Das
Metamodell spezifiziert das konzeptionelle Datenmodell der Ergebnisse. Unter
Techniken werden detaillierte Anleitungen zur Erstellung von Ergebnisdokumenten
verstanden. Werkzeuge können dazu verwendet werden, die Anwendung einer Technik
zu unterstützen. Abbildung 1 zeigt das Zusammenspiel der Methodenkomponenten. Im
Verlauf dieser Arbeit stellt sich insbesondere in den Fachbeiträgen 6 und 7 die Frage, ob
die Zuordnung von Technik zu Ergebnis zweckmäßig ist. Diesbezüglich wird diskutiert,
ob Techniken nicht vielmehr mit der Komponente Aktivität verbunden sein müssten.112
Metamodell
Metamodell ist ein
konzeptuelles Modell
der Ergebnisse
Ergebnis
Aktivitäten generieren und
benutzen Ergebnisse
Aktivität
Techniken liefern
Anweisungen für die
Erstellung von Ergebnissen
Rollen führen
Aktivitäten aus und entwerfen sie
Technik
Rolle
Abbildung 1: Methodenkomponenten nach Heym 1993, S. 13
Folgt man dem sprachkritischen Verständnis, so ermöglicht die separate Beschreibung
der Komponenten die systematische Entwicklung einer Methode unabhängig von den
gewählten Verbindungen. D.h. nicht die Verbindung, also die Orchestrierung der
Methodenkomponenten zu einem geschlossenen Ablauf ist das Ziel. Vielmehr sollen die
einzelnen Methodenkomponenten und deren Anforderungen an eine Orchestrierung
beschrieben werden. Ziel ist es, anhand der Komponenten und deren
Kombinationsregeln die Methode flexibel aufgrund der Anforderungen und Fähigkeiten
eines Unternehmens einsetzen zu können.
Diese Arbeit folgt dem sprachkritischen Verständnis der Methodenentwicklung. Ist es,
wie in dieser Forschungsarbeit, das Ziel, eine Methode zu konstruieren, stehen nach
109
Heym 1993, S. 5.
Ein weiterer Ansatz findet sich bei Karlsson 2002. Er präsentiert in seinem Modell neben den bereits in
anderen Ansätzen beschriebenen Komponenten einer Systementwicklungsmethode (Rolle, Aktivität,
Sprache, Artefakt) auch den Geschäftskontext und den Grund (einer Aktivität). Für eine umfassende
Beschreibung siehe Goeken 2006, S. 51.
111 Vgl. Gutzwiller 1994.
112 Eben diesen Schluss zieht Goeken 2006, S. 61 aus der breiten Definition einer Aktivität im Ansatz von
Karlsson 2002. Im weiteren Verlauf seiner Arbeit ordnet Goeken daher die Elemente Aktivität, Rolle und
Technik einander zu (Goeken 2006, S. 66).
17
110
diesem Verständnis die generischen Methodenkomponenten und die Regeln für deren
Beziehungen im Vordergrund. Die verwendeten Erkenntnisse aus dem
Forschungsgebiet Methoden-Engineerings werden in den jeweiligen Fachbeiträgen
detailliert beschrieben und diskutiert. Anzumerken ist, dass es nicht das Ziel dieser
Arbeit ist, das Projektmanagement für den Bereich IT-Governance zu unterstützen. Dies
ist jedoch ein wichtiger Bestandteil zukünftiger Forschung im Bereich BPRM der ITGovernance.
Forschungsdesign und Aufbau der Arbeit
Primärer Erkenntnis- oder Forschungsgegenstand der Wirtschaftsinformatik sind
betriebliche Informationssysteme und die Rahmenbedingungen der Entwicklung,
Einführung und Nutzung derselben. Informationssysteme sind sozio-technische
(„Mensch-Maschine―) Systeme. Sie umfassen Menschen (personelle Aufgabenträger),
Informations- und Kommunikationstechnik (maschinelle Aufgabenträger), Organisation
(Funktionen, Geschäftsprozesse, Strukturen und Management) sowie deren
Beziehungen.113 Als anwendungsorientierte Wissenschaft erstreckt sich der vorhandene
Wissensbestand der Wirtschaftsinformatik von wissenschaftlichen Quellen bis hin zu in
der Wirtschaft verwendeten Informationssystemen, also Software, organisatorische
Lösungen, Methoden, Werkzeugen sowie Erfahrungen mit diesen Komponenten.114
Die vorliegende Arbeit ist primär der gestaltungsorientierten Wirtschaftsinformatik
zuzuordnen. Diese besonders im deutschsprachigen und skandinavischen Raum
vertretene Form der Wirtschaftsinformatik hat das Ziel, innovative Informationssysteme
aktiv zu gestalten. Häufige Forschungsergebnisse sind Konzepte, Terminologien,
Sprachen, Modelle, Methoden sowie deren konkrete Implementierung. Der im
angelsächsischen Raum verbreitete Behaviorismus hingegen fokussiert sowohl die
Beobachtung der Eigenschaften eines Informationssystems als auch das Verhalten von
Benutzern. Ziel hierbei ist zumeist das Auffinden von Ursache-Wirkungsbeziehungen.
Forschungsgegenstand der vorliegenden Arbeit sind in der Praxis entwickelte BestPractice-Referenzmodelle der IT-Governance. Unter Bezugnahme auf den primären
Forschungsgegenstand der Wirtschaftsinformatik (Informationssysteme) werden BPRM
genutzt, um betriebliche Informationssysteme zu entwickeln oder weiterzuentwickeln.
Mithilfe von BPRM werden etwa IT-Prozessmodelle oder interne Kontrollsysteme
einzelner Unternehmen entwickelt.
BPRM sind bislang selten Gegenstand wissenschaftlicher Analyse, insbesondere die
Struktur von BPRM, ihre konkrete Anwendung sowie die Ausgestaltung der
Anwendung sind weitgehend unerforscht.115 Ebenso mangelt es an methodischer
Unterstützung der Anwendung in der Praxis.
Abbildung 2 zeigt die Aufteilung des Forschungsgegenstands in die drei Teilgebiete
Struktur, Anwendung und Methode. Diesen drei Teilgebieten sind die Teile B bis F
113
Vgl. Österle et al. 2010, S. 3; WKWI 1994, S. 80; Krcmar 2005.
Vgl. Österle et al. 2010, S. 3.
115 Siehe Erläuterungen in den jeweiligen Unterkapiteln.
114
18
zugeordnet, sie beinhalten die zehn Fachbeiträge der kumulativen Dissertation. Teil A
ist ein einführendes Kapitel und beinhaltet Motivation und Problemstellung, die
Erläuterung grundlegender Begriffe sowie das Forschungsdesign und den Aufbau der
Arbeit. Die Teilgebiete Struktur und Anwendung werden durch die Teile B und C
repräsentiert. Das Teilgebiet Methode wird der Übersichtlichkeit halber in mehrere
Teile aufgeteilt. Dies ist notwendig, da die Teile D und E zwar grundsätzlich dem
Teilgebiet Methode zuzuordnen sind, sich inhaltlich jedoch unterscheiden. Zwei
Fachbeiträge aus den Teilgebieten Anwendung und Methode sind separat in Teil F
zusammengefasst. Dies liegt darin begründet, dass sie sich beide mit dem Multi-ModellFall beschäftigen und daher eine thematische Einheit bilden. Teil G beinhaltet ein
abschließendes Fazit und Implikationen für Wissenschaft und Praxis. Außerdem
beinhaltet es Ansatzpunkte für weitere Forschung.
Teil A
Motivation und Problemstellung
Grundlegende Begriffe
Forschungsdesign und Aufbau der Arbeit
Forschungsgegenstand: Best-Practice-Referenzmodelle der IT-Governance
Teilgebiet: Struktur
Teilgebiet: Anwendung
Teilgebiet: Methode
Teil B
Fachbeitrag 1, 2, 3
Teil C
Fachbeitrag 4 & 5
Teil D (Methodenentwicklung)
Fachbeitrag 6 & 7
Teil E (Wissenschaftstheoretische
Aspekte der Methodenentwicklung)
Fachbeitrag 8
Teil F (Methodische Unterstützung der Anwendung von BPRM in einer
Multi-Modell-Umgebung) Fachbeitrag 9 & 10
Teil G
Fazit, Implikationen und weiterer Forschungsbedarf
Abbildung 2: Teilgebiete des Forschungsgegenstands und Aufbau der Arbeit
Im Folgenden werden das Forschungsdesign sowie der Aufbau der Arbeit detailliert
erläutert. Hierfür werden die Forschungsziele der jeweiligen Fachbeiträge, die
verwendeten Forschungsmethoden sowie die erzielten Forschungsergebnisse
überblicksartig beschrieben.
Die erstellten Fachbeiträge behandeln jeweils spezifische Forschungsziele des
Forschungsgebiets BPRM der IT-Governance. Die Forschungsziele werden in
Anlehnung an Becker et al. in Erkenntnis- und Gestaltungsziele eingeteilt.116 Beide Ziele
können jeweils aufgrund eines methodischen oder eines inhaltlich-funktionalen
Auftrags verfolgt werden. Ersterer umfasst das Verständnis und die Entwicklung von
116
Vgl. Becker et al. 2003.
19
Methoden und Techniken, während letzterer sich mit dem Verständnis und der
Bereitstellung von Informationssystemen in der betrieblichen Praxis befasst.
Tabelle 1: Forschungsziele der Wirtschaftinformatik (in enger Anlehnung an Becker et al. 2003, S.
12)
Erkenntnisziel
Methodischer Verständnis von Methoden
Auftrag
und Techniken der
Informationssystemgestaltung
Inhaltlichfunktionaler
Auftrag
Verständnis von
betrieblichen
Informationssystemen und
ihrer Anwendungsbereiche
Gestaltungsziel
Entwicklung von
Methoden und
Techniken der
Informationssystemgestaltung
Bereitstellung von ISReferenzmodellen für
einzelne Betriebe oder
Branchen
Der Systematik von Becker et al. folgend, lassen sich die in den Fachbeiträgen
verfolgten Forschungsziele also in Gestaltungs- oder Erkenntnisziele mit methodischem
oder inhaltlich-funktionalem Auftrag einordnen (Tabelle 1).
Teilgebiet: Methode
Erkenntnisziel:
Verständnis der Strukturen von
BPRM
Erkenntnisziel:
Verständnis des praktischen
Einsatzes von BPRM
Gestaltungsziel:
Entwicklung einer Methode zur
Unterstützung der Anwendung von
BPRM
Abbildung 3: Teilgebiete des Forschungsgegenstands und initiale Forschungsziele
Abbildung 3 zeigt die Teilgebiete sowie die zugeordneten initialen Forschungsziele. Die
folgenden drei Unterkapitel greifen jeweils ein Teilgebiet auf und beschreiben dessen
Aufbau anhand der gestellten Forschungsfragen, der verwendeten Methoden und der
erzielten Ergebnisse.
Dieses Teilgebiet beschäftigt sich mit der Struktur von BPRM. Die Verwendung des
Begriffs Struktur erfolgt in Anlehnung an Ferstl & Sinz, die für die
Wirtschaftsinformatik die Untersuchung von Struktur- und Verhaltenseigenschaften von
betrieblichen Informationssystemen unterscheiden.117
117
Vgl. Ferstl, Sinz 2006, S. 1.
20
In Anlehnung an die im Kapitel Best-Practice-Referenzmodelle aufgezeigte Beziehung
zwischen BPRM und unternehmensspezifischen Modellen sind im Rahmen der BPRMForschung zwei Arten von Strukturen relevant. Zum einen beschreiben BPRM normativ
eine idealtypische Struktur für ein unternehmensspezifisches Modell, d.h. ein
betriebliches Informationssystem. Zum anderen haben BPRM selbst eine Struktur.
Insbesondere diese zweite Form der Struktur war bislang kaum Gegenstand
wissenschaftlichen Interesses.118 Nach Ansicht der Verfasserin ist eine exakte Kenntnis
der Strukturen von BPRM für diese Arbeit jedoch von besonderer Bedeutung. Die
Erweiterung der Wissensbasis und das Aufzeigen von Strukturen sind insbesondere für
die Unterstützung einer systematischen Anwendung bedeutsam.
Das Teilgebiet Struktur beinhaltet daher folgende initale Forschungsfragen: Welche
Struktur haben BPRM und wie können sie wissenschaftlich nutzbar gemacht werden?
Hieraus leitet sich ein inhaltlich-funktionales Erkenntnisziel ab. Ziel ist ein besseres
Verständnis der Strukturen von BPRM (Abbildung 4).
TEILGEBIET: STRUKTUR
Erkenntnisziel: Verständnis
der Strukturen von BPRM
Forschungsmethoden:
Konzeptionelle Modellierung
und Metamodellierung
Ergebnis:
Metamodelle von
COBIT,
ITIL,
CMMI
FachFachbeitrag
beitrag
1 2
Ergebnis:
Grundsätze
ordnungsmäßiger
Metamodellierung
Fachbeitrag 3
Abbildung 4: Teilgebiet Struktur
Da BPRM bislang kaum Gegenstand wissenschaftlicher Analysen sind, sind auch
Fragen zu ihrer Struktur weitgehend unbeantwortet.119 Ziel dieses Teils ist es daher, die
Struktur von BPRM so aufzuarbeiten, dass sie im weiteren Verlauf der Arbeit
verwendet werden können. Angestrebt ist außerdem die Erhöhung des
Formalisierungsgrads der BPRM, was eine Nutzung von Forschungsergebnissen aus
dem Bereich der Referenzmodellierung erleichtert. Die Aussicht, Erkenntnisse aus der
Referenzmodell-Forschung nach einer Formalisierung der BPRM verwenden zu
118
Ausnahmen bilden Brown, Grant 2005; Hochstein, Hunziker 2003; Böhmann, Krcmar 2004, die einen
Vergleich der vorhandenen Frameworks durchführen, die Struktur jedoch nur am Rande thematisieren.
119 Eine Ausnahme bilden Moser et al. 2005.
21
können,
ermöglicht
zahlreiche
Erkenntnisse
für
die
Ableitung
von
unternehmensspezifischen Modellen aus dem BPRM. Dies ist ein wichtiger Aspekt des
Teilgebiets Methode (siehe insbesondere Fachbeitrag 6).
Zur Beantwortung der Frage nach der Struktur von BPRM werden in Teil B der
Dissertation hauptsächlich konzeptionelle Forschungsmethoden, wie die konzeptionelle
Modellierung und Metamodellierung verwendet. Zusätzlich dazu sind bestimmte
Forschungsergebnisse aus dem Bereich Referenzmodellierung generisch genug, um
auch vor einer Erhöhung des Formalisierungsgrades im Bereich BPRM Anwendung
finden zu können.120
Forschungsergebnisse dieses Teilgebiets sind Metamodelle der BPRM COBIT, ITIL
und CMMI sowie eine Reihe von Grundsätzen zur Modellierung von Metamodellen.
Die Ergebnisse dieses Teilgebiets sind in den Fachbeiträgen 1 bis 3 veröffentlicht.
Ausgangspunkt dieses Teilgebiets ist Frage nach der praktischen Anwendung von
BPRM. Im Verlauf des Promotionsvorhabens ergab sich zunächst die Möglichkeit
BPRM auf den Forschungsbereich „Serviceorientierte Architekturen (SOA)―
anzuwenden. Fachbeitrag 4 zeigt die Anwendung von COBIT zur Unterstützung der
Service-Governance. Hierfür werden aus den fünf Kernbereichen der IT-Governance,
den sogenannten IT Governance Focus Areas, Dimensionen der Service-Governance
abgeleitet und für eine Verwendung während der Service-Identifikation
operationalisiert. Im Verlauf der Forschungsarbeit zu diesem konkreten
Anwendungsfall wurde deutlich, wie vielfältig die Anwendungsmöglichkeiten von
BPRM sind.
Aus den dort erzielten Erkenntnissen ergab sich daher eine weitere Fragestellung, die
sich außerdem aus dem Ziel dieser Arbeit ableiten lässt. Um die Anwendung von
BPRM methodisch zu unterstützen, sollten neben den im Teilgebiet Struktur
gewonnenen Erkenntnissen auch die in der Literatur bekannten und die in der Praxis
üblichen Anwendungsformen von BPRM bekannt sein. Bislang gibt es jedoch kaum
systematische Forschungserkenntnisse über die möglichen Formen der Anwendung von
BPRM.121 Hieraus ergibt sich das inhaltlich-funktionale Erkenntnisziel, Verständnis des
praktischen Einsatzes von BPRM zu erlangen. Die im Rahmen dieses Erkenntnisziels
durchgeführte qualitative Studie führte zunächst zu zwei zentralen Erkenntnissen:
120
Siehe bspw. Becker et al. 2004b zur Positionierung von BPRM, Fettke, Loos 2002 zum Thema
Wiederverwendung, Schütte 1998 zur Qualität von Referenzmodellen und Becker et al. 2002b zum Stand
der Forschung.
121 Siehe u.a. Simonsson, Johnson 2008; Wagner 2006; Tuttle, Vandervelde 2007; Heier et al. 2007; Heier
et al. 2008; Heier et al. 2009; Larsen et al. 2006; de Haes, van Grembergen 2008; Lunardi et al. 2009;
Debreceny, Gray 2009; de Espindola et al. 2009. Diese Quellen zeigen eine positive Wirkung des BPRMEinsatzes bspw. auf den Business Value of IT. Jedoch erfolgt die Analyse zumeist ceterus paribus und
lässt die Art und Weise der Anwendung offen. Simonsson et al. 2010 zeigen erstmals quantitativempirisch den Effekt des Einsatzes von BPRM.
22
1. Die Anwendung von BPRM kann anhand von Dimensionen unterschieden
werden.
2. Überschneidungen zwischen BPRM sind eine zentrale Herausforderung für die
Praxis.
Wie in Abbildung 5 deutlich wird, führten diese Erkenntnisse zu verschiedenen
Forschungszielen. Ein konkreteres Erkenntnisziel ist das Verständnis der
konstituierenden Dimensionen der Anwendung. Es leitet sich aus der Erkenntnis ab,
dass die befragten Experten unterschiedliche Auffassungen vom Begriff Anwendung
vertraten. Insbesondere war strittig, wann ein BPRM in einem Unternehmen als
angewendet bezeichnet werden kann. Diese Unklarheiten zeigen sich auch in
Praxisstudien.122
Ergebnis dieses Forschungsprozesses ist ein Ordnungsrahmen, der die Anwendung von
BPRM entlang verschiedener Dimensionen systematisiert. Die Ausprägungen dieser
Dimensionen klassifizieren die Formen der Anwendung nach Art eines
morphologischen Kastens. Der Ordnungsrahmen der Anwendung von BPRM wird in
Fachbeitrag 5 vorgestellt.
Aus der Erkenntnis, dass die Überschneidungen zwischen BPRM in der Praxis eine
zentrale Herausforderung darstellen, ergeben sich zwei weitere Forschungsziele.
Zunächst ergibt sich die Forschungsfrage: Was macht eine Multi-Modell-Umgebung
aus? Hieraus leitet sich das inhaltlich-funktionale Erkenntnisziel ‚Verständnis der
Multi-Modell-Umgebung‘ ab. Hierbei ist aus wissenschaftlicher Sicht fraglich, warum
die Modellvielfalt in der Praxis zu Problemen führt. Sind etwa unterschiedliche
Fachbereiche einer Abteilung betroffen, führt auch eine Modell-Überschneidung nicht
zwangsläufig zu Überschneidungen in der alltäglichen Praxis. Jedoch ergaben die
durchgeführten Experteninterviews ein gegenteiliges Bild. Aus dem gemeinsamen
Einsatz mehrerer BPRM ergeben sich zahlreiche Herausforderungen. In Fachbeitrag 9
wird daher ein erstes theoretisches Verständnis der Multi-Modell-Umgebung ITGovernance präsentiert. Durch theoretische Überlegungen, konzeptionelle
Modellierungen und Metamodellvergleiche wird die Multi-Modell-Umgebung
systematisiert, sowie erste Lösungsmöglichkeiten für die auftretenden
Herausforderungen aufgezeigt.
Außerdem leitet sich aus der Erkenntnis, dass die Multi-Modell-Umgebung eine
Herausforderung für die Praxis darstellt, ein weiteres Forschungsziel ab. Die
Entwicklung einer methodischen Unterstützung der Anwendung von BPRM sollte auch
den Multi-Modell-Fall berücksichtigen. Hieraus ergibt sich ein weiteres methodisches
Gestaltungsziel und zwar die Entwicklung einer Methode zur Unterstützung der
Anwendung von mehreren BPRM. Dieses Gestaltungsziel wird in Kombination mit
einem Forschungsergebnis aus dem dritten Teilbereich bearbeitet und daher erst im
nächsten Teilgebiet detailliert beschrieben.
122
Vgl. KPMG International 2009, S. 7; PWC 2006; IT Governance Institute 2008.
23
TEILGEBIET: ANWENDUNG
Gestaltungsziel: Anwendung von BPRM zur Unterstützung
der SOA-Governance
Ergebnis: Konzeptionelle Operationalisierung der ITGovernance-Focus-Areas auf die Service-Governance
Fachbeitrag 4
Erkenntnisziel: Verständnis des praktischen Einsatzes von
BPRM
Forschungsmethoden: Qualitative Experteninterviews und
Literaturanalyse
Erkenntnis: Die Anwendung kann anhand von Dimensionen
unterschieden werden
Erkenntnisziel: Verständnis der konstituierenden
Dimensionen der BPRM-Anwendung
Literaturanalyse
Ergebnis: Ordnungsrahmen der Anwendung von BPRM
Fachbeitrag 5
Erkenntnis: Überschneidungen zwischen BPRM sind eine
zentrale Herausforderung für die Praxis
Erkenntnisziel: Verständnis der Multi-Modell-Umgebung
Forschungsmethoden: Konzeptionelle Modellierung und
Metamodellvergleich
Ergebnis: Theoretisches Verständnis der Multi-ModellUmgebung
Fachbeitrag 9
Abbildung 5: Teilgebiet Anwendung
24
Teilgebiet: Methode
Im Teilgebiet Methode wird das Ziel verfolgt, eine Methode zu entwickeln, die die
Anwendung von BPRM in der Praxis unterstützt. Unter Verwendung von
Forschungsergebnissen aus dem Bereich der konzeptionellen Methodenkonstruktion
entsteht so das in den Fachbeiträgen 6 und 7 vorgestellte Ergebnis. Die entwickelte
Methode unterstützt die Anpassung und die Anwendung von BPRM.
Ein weiteres Ergebnis aus den Fachbeiträgen 6 und 7 ist die Erkenntnis, dass die
konzeptionelle Methoden-Konstruktion gewisse forschungsmethodische Schwächen
aufweist. Eben diese Schwächen der Forschungsmethode sind Bestandteil von
wissenschaftlichen Diskussionen. Aus dieser Erkenntnis ergibt sich das zusätzliche
Gestaltungsziel, die Methoden-Konstruktion weiterzuentwickeln. Das in Fachbeitrag 8
vorgestellte Grounded Method Engineering ist eine Ergänzung des üblichen
Konstruktionsvorgehens bei der Erstellung von Methoden.
Außerdem ist die in Fachbeitrag 6 detaillierter als in Fachbeitrag 7 vorgestellte
generische Methode der Ausgangspunkt zur Umsetzung des bereits im vorherigen
Kapitel aufgezeigten Gestaltungsziels: ‚Entwicklung einer Methode zur Unterstützung
der Anwendung von mehreren BPRM‘. Die hierfür notwendigen Erweiterungen der
generischen Methode werden in Fachbeitrag 10 diskutiert. Abbildung 6 zeigt einen
Überblick über das Teilgebiet Methode.
25
TEILGEBIET: METHODE
Gestaltungsziel: Entwicklung einer Methode zur Unterstützung der
Anwendung von BPRM
Forschungsmethode: Konzeptionelle Methoden-Konstruktion (KMK)
Ergebnis: Methode zur Unterstützung der Anwendung von BPRM
FachFachbeitrag 7
beitrag 6
Erkenntnis: KMK hat Schwächen
Gestaltungsziel: Weiterentwicklung der
Forschungsmethode KMK
Forschungsmethode: Konzeptionelle
Forschungsmethoden-Konstruktion
Ergebnis: „Grounded Method Engineering―
Fachbeitrag 8
Gestaltungsziel: Entwicklung einer Methode zur Unterstützung
der Anwendung von mehreren BPRM
Forschungsmethode: Konzeptionelle Methoden-Konstruktion
Ergebnis: Methode zur Unterstützung der Anwendung von
BPRM im Multi-Modell-Fall
Fachbeitrag 10
Abbildung 6: Teilgebiet Methode
26
Zwischenfazit
In diesem ersten Teil der vorliegenden Dissertation wurden zunächst Motivation und
Problemstellung der Arbeit und ihre grundlegenden Begriffe erläutert. Dieser Teil ist die
Basis der folgenden wissenschaftlichen Publikationen und wurde ihnen daher
vorangestellt. Das ist insbesondere deshalb notwendig, da Definitionen und
Begriffsabgrenzungen in wissenschaftlichen Publikationen aus Platzmangel oft nur
recht knapp vorgestellt werden können.
Weiterhin wurde der Aufbau der Arbeit detailliert vorgestellt. Zusammenfassen ist
festzuhalten, dass der Forschungsgegenstand ―BPRM der IT-Governance― in dieser
Arbeit in den drei Teilgebieten Struktur, Anwendung und Methode untersucht wird.
Abbildung 7 fügt die beschriebenen Teilgebiete zu einem Gesamtbild zusammen und
gibt so einen Überblick über die vorliegende Arbeit. Zwischen den Zielen, Methoden,
Erkenntnissen und Ergebnissen gibt es neben den dargestellten noch weitere
Querverbindungen. Beispielsweise finden die im Teilbereich Struktur gewonnenen
Erkenntnisse in nahezu allen nachfolgenden Forschungsbemühungen Verwendung.
Ebenso gibt es Beziehungen zwischen den generischen Teilbereichen Struktur,
Anwendung und Methode. Diese Verbindungen wurden jedoch der Übersichtlichkeit
halber ausgeblendet. Teile von Abbildung 7 werden im Verlauf der Arbeit verwendet,
um die Fachbeiträge in das Forschungsdesign einzuordnen und um das Gesamtkonzept
der Arbeit zu verdeutlichen.
27
Forschungsmethoden:
Ergebnis:
Metamodelle von
COBIT,
ITIL,
CMMI
FachFachbeitrag 2
beitrag 1
Ergebnis:
Grundsätze
ordnungsmäßiger
Metamodellierung
Fachbeitrag 3
TEILGEBIET: METHODE
der SOA-Governance
Anwendung von BPRM
Fachbeitrag 4
BPRM
FachFachbeitrag 7
beitrag 6
Literaturanalyse
Erkenntnis: KMK hat Schwächen
Literaturanalyse
Fachbeitrag 5
Fachbeitrag 8
Metamodellvergleich
Fachbeitrag 9
Fachbeitrag 10
Abbildung 7 Aufbau der Arbeit anhand der Teilgebiete Struktur, Anwendung und Methode
28
Literaturverzeichnis Teil A
Alter, S.; Goeken, M. (2009): Konzeptionelle Metamodelle von IT-GovernanceReferenzmodellen als Basis der Kombination und Integration in einer Multi-ModelUmgebung. In: Hansen, Karagiannis, Fill (Hg.): Business Services: Konzepte,
Technologien, Anwendungen. 9. Internationale Tagung Wirtschaftsinformatik, Band 1.
Wien.
Balzert, H. (1998): Lehrbuch der Software-Technik. Heidelberg, Berlin: Spektrum
Akademischer Verlag GmbH.
Baumöl, U. (2008): IT-Controlling. Stand und Herausforderungen. In: Controlling, Jg.
20, H. 12, S. 649–654.
Becker, J. (1995): Strukturanalogien in Informationsmodellen – Ihre Definition, ihr
Nutzen und ihr Einfluß auf die Bildung der Grundsätze ordnungsmäßiger Modellierung
(GoM). In: König (Hg.): Wirtschaftsinformatik '95 – Wettbewerbsfähigkeit, Innovation,
Wirtschaftlichkeit. Heidelberg, S. 133–150.
Becker, J. (Hg.) (2004): Referenzmodellierung. Grundlagen, Techniken und
domänenbezogene Anwendung. Heidelberg: Physica-Verlag.
Becker, J.; Algermissen, L.; Delfmann, P. (2002a): Referenzmodellierung. In: Das
Wirtschaftsstudium (WISU), Jg. 31, H. 11, S. 1392–1395.
Becker, J.; Delfmann, P.; Knackstedt, R. (2004a): Konstruktion von
Referenzmodellierungssprachen. Ein Ordnungsrahmen zur Spezifikation von
Adaptionsmechanismen für Informationsmodelle. In: Wirtschaftsinformatik, Jg. 46, H.
4, S. 251–264.
Becker, J.; Holten, R.; Knackstedt, R.; Niehaves, B. (2003): Forschungsmethodische
Positionierung in der Wirtschaftsinformatik. Epistemologische, ontologische und
linguistische Leitfragen. Herausgegeben von Becker, Grob, Klein, Kuchen, MüllerFunk und Vossen. Westfälische Wilhelms-Universität Münster. Arbeitsberichte des
Instituts für Wirtschaftsinformatik, Nr. 93, Münster.
Becker, J.; Knackstedt, R. (Hg.) (2002b): Referenzmodellierung 2002 Methoden –
Modelle – Erfahrungen. Westfälische Wilhelms-Universität Münster. Arbeitsberichte
des Instituts für Wirtschaftsinformatik, Nr. 90, Münster.
Becker, J.; Knackstedt, R.; Holten, R.; Hansmann, H.; Neumann, S. (2001):
Konstruktion von Methodiken. Vorschläge für eine begriffliche Grundlegung und
domänenspezifische Anwendungsbeispiele. Herausgegeben von Becker, Grohmann,
Klein, Kuchen, Müller-Funk und Vossen. Westfälische Wilhelms-Universität Münster.
Münster. Arbeitsberichte des Instituts für Wirtschaftsinformatik, Nr. 77, Münster.
Becker, J.; Knackstedt, R.; Pfeiffer, D.; Janiesch, C. (2007): Configurative Method
Engineering. On the Applicability of Reference Modeling Mechanisms in Method
29
Engineering. In: Proceedings of the 13th Americas Conference on Information Systems.
Keystone, Colorado, 9.-12.August 2007.
Becker, J.; Niehaves, B.; Knackstedt, R. (2004b): Bezugsrahmen zur epistemologischen
Positionierung der Referenzmodellierung. In: Becker, J. (Hg.): Referenzmodellierung.
Grundlagen, Techniken und domänenbezogene Anwendung. Heidelberg: PhysicaVerlag, S. 1–17.
Becker, M. (1998): Umsetzung betrieblicher Prozesse. Methode, Fallbeispiele,
Workflow-Technologie. Dissertation, Universität St.Gallen, St. Gallen, Switzerland.
Böhmann, T.; Krcmar, H. (2004): Grundlagen und Entwicklungstrends im ITServicemanagement. In: HMD - Praxis Wirtschaftsinformatik, H. 237, S. 7-21.
Booth, M. E.; Philip, G. (2005): Information systems management in practice: An
empirical study of UK companies. In: International Journal of Information
Management, Jg. 25, H. 4, S. 287–302.
Börner, R. (2010): Applying Situational Method Engineering to the Development of
Service Identification Methods. Proceedings of the 16th Americas Conference on
Information Systems, Lima, Peru.
Bowen, P. L.; Cheung, M.-Y. D.; Rohde, F. H. (2007): Enhancing IT governance
practices: A model and case study of an organization‘s effort. In: International Journal
of Accounting Information Systems, Jg. 8, H. 3, S. 191–221.
Braun, C.; Hafner, M.; Wortmann, F. (2004): Methodenkonstruktion als
wissenschaftlicher Erkenntnisansatz. Universität St.Gallen. St. Gallen, Switzerland.
Brenner, W. (1994): Grundzüge des Informationsmanagements. Berlin: Springer.
Brinkkemper, S. (1996): Method engineering: engineering of information systems
development methods and tools. In: Information & Software Technology, Jg. 38, H. 4,
S. 275–280.
Brinkkemper, S.; Lyytinen, K.; Welke, R. J. (Hg.) (1996): Method Engineering.
Principles of method construction and tool support ; Proceedings of the IFIP TC8,
WG8.1/8.2 Working Conference on Method Engineering, 26.-28.August 1996, Atlanta,
USA. London: Chapman & Hall.
Brinkkemper, S.; Saeki, M.; Harmsen, F. (1999): Meta-modelling based assembly
techniques for situational method engineering. In: Information Systems, Jg. 24, H. 3, S.
209–228.
Brooks, F. P. (1987): Essence and Accidents of Software Engineering. In: IEEE
Computer, Jg. 20, H. 4, S. 10–19.
Brown, A.; Grant, G. G. (2005): Framing the Frameworks: A Review of IT Governance
Research. In: Communications of the Association for Information Systems, Jg. 15, S.
696-712.
30
Bundesministerium für Justiz (Hg.) (2009): Deutscher Corporate Governance Kodex.
Unter Mitarbeit von Theodor Baums, Hans-Friedrich Gelhausen h. c., Manfred Gentz,
Dietmar Hexel, Ulrich Hocker, Henning Kagermann, Max Dietrich Kley, Christian
Strenger, Peer M. Schatz, Daniela Weber-Rey, Axel Werder v., Klaus-Peter Müller
(Vorsitzender). Online verfügbar unter http://www.corporate-governance-code.de.
Abruf 11.06.2010.
Chapman, C.; Ward, S. (2004): Why risk efficiency is a key aspect of best practice
projects. In: International Journal of Project Management, Jg. 22, S. 619–632.
Codling, B. (1997): Dynamics of best pratice. A multidimensional perspective. In:
Benchmarking for Quality, Management & Technology, Jg. 4, H. 2, S. 96–103.
Cox, J. (2004): Implementing ITIL. In: Network World, Jg. 21, H. 40, S. 60-70.
Davenport, T. H. (2000): Mission Critical. Realizing the Promise of Enterprise Systems.
Boston: Harvard Business Press.
de Espindola, R. S.; Luciano, E. M.; Audy, J. L. N. (2009): An Overview of the
Adoption of IT Governance Models and Software Process Quality Instruments at Brazil
- Preliminary Results of a Survey. In: HICSS 2009 - Proceedings of the 42th Hawaii
International Conference on System Sciences. Washington, DC, USA: IEEE Computer
Society.
Debreceny, R.; Gray, G. L. (2009): IT Governance and Process Maturity: A Field
Study. In: HICSS 2009 - Proceedings of the 42th Hawaii International Conference on
System Sciences. Washington, DC, USA: IEEE Computer Society.
Deloitte (2005): Are you sitting comfortably? 2005 IT governance survey findings.
Online verfügbar unter http://www.deloitte.com /dtt/cda/doc/content/UK_ERS_ITGovernanceSurvey_2005.pdf. Abruf 20.02.2010.
Ferstl, O. K.; Sinz, E. J. (2006): Grundlagen der Wirtschaftsinformatik. 5., überarbeitete
und erweiterte Auflage. München: Oldenbourg.
Ferstl, O. K.; Sinz, E. J. (2008): Grundlagen der Wirtschaftsinformatik. 6., überarbeitete
und erweiterte Auflage. München: Oldenbourg.
Fettke, P. (2006): Referenzmodellevaluation. Konzeption der strukturalistischen
Referenzmodellierung und Entfaltung ontologischer Gütekriterien. Dissertation. Berlin:
Logos-Verlag (Wirtschaftsinformatik - Theorie und Anwendung, 5).
Fettke, P.; Loos, P. (2002): Methoden zur Wiederverwendung von Referenzmodellen –
Übersicht und Taxonomie. In: Becker, Knackstedt (Hg.): Referenzmodellierung 2002
Methoden – Modelle – Erfahrungen. Arbeitsberichte des Instituts für
Wirtschaftsinformatik, Nr. 90, Münster, S. 9–30.
Fettke, P.; Loos, P. (2003): Classification of reference models - a methodology and its
application. In: Information systems and ebusiness management, Jg. 1, H. 1, S. 35–53.
Fettke, P.; Loos, P. (2004): Entwicklung eines Bezugsrahmens zur Evaluierung von
Referenzmodellen. Langfassung eines Beitrags. Johannes Gutenberg Universität.
31
Mainz.
Online
verfügbar
unter
http://www.econbiz.de/archiv/mz/umz/winformatik/bezugrahmen_evaluierung_referenzmodelle.pdf. Abruf: 31.05.2009.
Fitzgerald, B.; Russo, N. L.; O'Kane, T. (2003): Software Development: Method
Tailoring at Motorola. In: Communications of the ACM, Jg. 46, H. 4, S. 65–70.
Frank, U. (1999): Conceptual Modelling as the Core of the Information Systems
Discipline – Perspectives and Epistemological Challenges. In: Haseman, Nazareth
(Hg.): Proceedings of the Fifth Americas Conference on Information Systems (AMCIS
1999), August 13-15, 1999. Milwaukee, Wisconsin, S. 695-697.
Fröhlich, M.; Glasner, K. (2007): IT Governance. Leitfaden für eine praxisgerechte
Implementierung. Wiesbaden: Gabler Verlag / GWV Fachverlage GmbH Wiesbaden.
Goeken, M. (2002): Grundlagen und Ansätze einer Referenzmodellierung für
Führungsinformationssysteme. Philipps-Universität Marburg. Fachbericht des Instituts
für Wirtschaftsinformatik, Nr. 03, Marburg.
Goeken, M. (2006): Entwicklung von Data-Warehouse-Systemen. Anforderungsmanagement, Modellierung und Implementierung. Dissertation. Wiesbaden: Deutscher
Universitäts-Verlag.
Goeken, M.; Alter, S. (2008): IT Governance Frameworks as Methods. In: Proceedings
of the 10th International Conference on Enterprise Information Systems (ICEIS 2008).
June 12-16, Barcelona, Spain 2008.
Gompers, P.; Ishii, J.; Metrick, A. (2003): Corporate Governance and Equity Prices. In:
The Quarterly Journal of Economics, Jg. 118, H. 1, S. 107–155.
Gutzwiller, T. (1994): Das CC RIM-Referenzmodell für den Entwurf von betrieblichen,
transaktionsorientierten Informationssystemen. Heidelberg: Physica-Verlag.
Habisch, A.; Neureiter, M.; Schmidpeter, R. (2008): Handbuch Corporate Citizenship.
Corporate Social Responsibility für Manager. (Springer-11775 /Dig. Serial]).
Haes, S. de; van Grembergen, W. (2006): Information Technology governance best
practices in Belgian organizations. In: HICSS 2006 - Proceedings of the 39th Annual
Hawaii International Conference on System Sciences. Washington, DC, USA: IEEE
Computer Society.
Haes, S. de; van Grembergen, W. (2008): An exploratory Study into the design of an IT
Governance Minimum Baseline through Delphi Research. In: Communications of the
Association for Information Systems, Jg. 22, Article 24, S. 443a.
Hardy, G. (2006): Using IT governance and COBIT to deliver value with IT and
respond to legal, regulatory and compliance challenges. In: Information Security
Technical Report, Jg. 11, H. 1, S. 55–61.
Harmsen, A. F. (1997): Situational Method Engineering. Dissertation. Utrecht.
Hars, A. (1994): Referenzdatenmodelle – Grundlagen effizienter Datenmodellierung.
Wiesbaden, zugleich Dissertation 1993, Saarbrücken.
32
Heier, H.; Borgman, H.; Hoffbauer, T. (2008): Making the most of IT governance
software: understanding implementation processes. In: HICSS 2008 - Proceedings of
the 41st Annual Hawaii International Conference on System Sciences. Washington, DC,
Heier, H.; Borgman, H.; Maistry, M. (2007): Examining the relationship between IT
governance software and business value of IT: evidzence from four case studies. In:
HICSS 2007 - Proceedings of the 40th Annual Hawaii International Conference on
Heier, H.; Borgmann, H.; Mileos, C. (2009): Examining the Relationship between IT
Governance Software, Processes, and Business Value: A Quantitative Research
Approach. In: HICSS 2009 - Proceedings of the 42th Hawaii International Conference
on System Sciences. Washington, DC, USA: IEEE Computer Society.
Heinrich, L. J.; Lehner, F. (2005): Informationsmanagement. München, Wien:
Oldenbourg.
Hesse, W.; Merbeth, G.; Frölich, R. (1992): Software-Entwicklung, Vorgehensmodelle,
Projektführung, Produktverwaltung. Handbuch der Informatik Band 5.3. Wien:
Oldenbourg.
Heym, M. (1993): Methoden-Engineering - Spezifikation und Integration von
Entwicklungsmethoden für Informationssysteme. Dissertation. Hallstadt. Universität St.
Gallen, Institut für Wirtschaftsinformatik.
Hochstein, A.; Hunziker, A. (2003): Serviceorientierte Referenzmodelle des ITManagements. In: HMD - Praxis Wirtschaftsinformatik, H. 232, S. 45-56.
Hochstein, A.; Zarnekow, R.; Brenner, W. (2004): ITIL als Common-PracticeReferenzmodell für das IT-Service-Management. Formale Beurteilung und
Implikationen für die Praxis. In: Wirtschaftsinformatik, Jg. 46, H. 5, S. 382–389.
ISO/IEC 38500 (01.06.2008): Corporate governance of information technology.
IT Governance Institute (2003): Board Briefing on IT Governance.
IT Governance Institute (2005): Governance of the Extended Enterprise Bridging
Business and IT-Strategies.
IT Governance Institute (2006): IT Governance Global Status Report.
IT Governance Institute (2007): COBIT 4.1.
Johannsen, W.; Goeken, M. (2007): Referenzmodelle für IT-Governance. Heidelberg:
dpunkt.verlag.
Kamleiter, J.; Langer, M. (2006): Business IT Alignment mit ITIL, COBIT, RUP. Bad
Homburg: Serview GmbH.
33
Karlsson (2002): Meta-Method for Method Configuration. Dissertation. Linköping,
Faculty of Arts and Sciences.
Karlsson, F.; Wistrand, K. (2006): Combining method engineering with activity theory:
theoretical grounding of the method component concept. In: European Journal of
Information Systems, Jg. 15, H. 1, S. 82–90.
Kaschek, R. (Hg.) (1999): Entwicklungsmethoden für Informationssysteme und deren
Anwendung. In: Proceedings der EMISA '99, Fachtagung der Gesellschaft für
Informatik e. V. (GI). Stuttgart, Leipzig.
Kelly, S.; Rossi, M.; Tolvanen, J. P. (2005): What is Needed in a MetaCASE
Environment? In: Enterprise Modelling and Information Systems Architectures, Jg. 1,
H. 1, S. 25–35.
Klaus, H.; Rosemann, M.; Gable, G. (2000): What is ERP? In: Information Systems
Frontiers, Jg. 2, H. 2, S. 141–162.
Knolmayer, G.; Loosli, G.; Aspiron, A.: IT-Governance. Aus Enzyklopädie der
Wirtschaftsinformatik. Online-Lexikon, Oldenburg-Verlag. Herausgegeben von Kurbel,
Becker, Gronau, Sinz und Suhl.
KPMG (September 2004): Summary of KPMG IS Governance Survey. KPMG LLP.
London.
KPMG International (2009): KMPG‘s 2009 IT Internal Audit Survey. Herausgegeben
von KPMG.
Krcmar, H. (2005): Informationsmanagement. Berlin, Heidelberg u.a.: Springer-Verlag
(4. Auflage).
Kueng, P.; Bichler, P. K. P.; Schreft, M. (1996): How to compose an Object-Oriented
Business Process Modell. In: Brinkkemper, Lyytinen, Welke (Hg.): Method
Engineering. Principles of method construction and tool support. Proceedings of the
IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering, 26.-28.August
1996, Atlanta, USA. London: Chapman & Hall, S. 94–110.
Larsen, M.; Pedersen, M.; Andersen, K. (2006): IT governance: reviewing 17 IT
governance tools and analyzing the case of Novozymes A/S. In: HICSS 2006 Proceedings of the 39th Annual Hawaii International Conference on System Sciences.
Washington, DC, USA: IEEE Computer Society.
Lee, Z.; Lee, J. (2000): An ERP implementation case study from a knowledge transfer
perspective. In: Journal of Information Technology, Jg. 15, S. 281–288.
Loos, P.; Fettke, P. (2005): Referenzmodellierung. Entwicklungsstand
Perspektiven. In: Information Management & Consulting, Jg. 20, Sonderausgabe.
und
Lunardi, G. L.; Becker, J. L.; Macada, A. C. (2009): The Financial Impact of IT
Governance Mechanisms' Adoption: An Empirical Analysis with Brazilian Firms. In:
HICSS 2009 - Proceedings of the 42th Hawaii International Conference on System
Sciences. Washington, DC, USA: IEEE Computer Society.
34
McKinsey & Company (Juni 2000): Investor Opinion Survey.
Mertens, P. (1997): Best practice. In: Wirtschaftsinformatik, Jg. 39, H. 6, S. 641.
Meyer, M.; Zarnekow, R.; Kolbe, L. M. (2003): IT-Governance Begriff, Status quo und
Bedeutung. In: Wirtschaftsinformatik, Jg. 45, H. 4, S. 445–448.
Moser, C.; Bayer, F.; Karagiannis, D. (2005): ITIL: Die modellgestützte Umsetzung mit
ADOit. In: Victor, Günther (Hg.): Optimiertes IT-Management mit ITIL. So steigern
Sie die Leistung Ihrer IT-Organisation; Einführung, Vorgehen, Beispiele. 2.
durchgesehene Auflage, Wiesbaden: Vieweg (Edition CIO), S. 184–195.
Newell, S.; Swan, J.; Galliers, R. (2000): A knowledge-focused perspective on the
diffusion and adoption of complex information technologies. The BPR example. In:
Information Systems Journal, Jg. 10, S. 239–259.
OGC (2007a): ITIL V3. Continual Service Improvement. London.
OGC (2007b): ITIL V3. Service Design. London.
OGC (2007c): ITIL V3. Service Operation. London.
OGC (2007d): ITIL V3. Service Strategy. London.
OGC (2007e): ITIL V3. Service Transition. London.
Österle, H.; Becker, J.; Frank, U.; Hess, T.; Karagiannis, D.; Krcmar, H. et al. (2010):
Memorandum zur gestaltungsorientierten Wirtschaftsinformatik. in: Zeitschrift für
betriebswirtschaftliche Forschung, 6, 2010, Nr. 62, S. 664 – 672.
PWC (2006): IT Governance in Practice - Insight from leading CIOs. Herausgegeben
von Pricewaterhouse Coopers Johannesburg. South Africa, IT Governance Institute
Rolling Meadows, USA.
Ralyté, J.; Rolland, C. (2001): An Assembly Process Model for Method Engineering.
In: 13th International Conference on Advanced Information Systems Engineering
(CAiSE 2001) (Lecture notes in computer science), S. 267–283.
Rautenstrauch, C.; Schulze, T. (2003): Informatik für Wirtschaftswissenschaftler und
Wirtschaftsinformatiker. Berlin: Springer.
Reijers, H. A.; Liman Mansar, S. (2005): Best practices in business process redesign.
An overview and qualitative evaluation of successful redesign heuristics. In: Omega, Jg.
33, S. 283–306.
Rosemann, M.; van der Aalst, W. M. P. (2007): A configurable reference modelling
language. In: Information Systems, Jg. 32, H. 1, S. 1–23.
Scheer, A.-W. (1999): Electronic business engineering. Heidelberg: Physica-Verlag.
Scheer, A.-W.; Seel, C.; Georg, W. (2002): Entwicklungsstand
Referenzmodellierung. In: Industrie Management, Jg. 18, H. 1, S. 9–12.
in
der
35
Schütte, R. (1998): Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion
konfigurationsund anpassungsorientierter Modelle. Wiesbaden: Gabler (Neue
betriebswirtschaftliche Forschung, 233).
Schwegmann, A. (1999): Objektorientierte Referenzmodellierung. Theoretische
Grundlagen und praktische Anwendung. Wiesbaden. Dissertation, Universität Münster.
Shleifer, A.; Vishny, R. W. (1997): A Survey of Corporate Governance. In: The Journal
of Finance, Jg. 52, H. 2, S. 737–783.
Simonsson, M.; Ekstedt, M. (2006): Getting the priorities right: Literature vs. practice
on IT governance. KTH - Royal Institute of Technology. (White Paper). Online
verfügbar unter http://www.ee.kth.se/php/modules/publications/repo. Abruf 31.05.2009
Simonsson, M.; Johnson, P. (2008): The IT Organization Modeling and Assessment
Tool: Correlating IT Governance Maturity with the Effect of IT. In: HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences.
Washington, DC, USA: IEEE Computer Society, S. 431–441.
Simonsson, M.; Johnson, P.; Ekstedt, M. (2010): The Effect of IT Governance Maturity
on IT Governance Performance. In: Information Systems Management, Jg. 27, S. 10–
24.
Siviy, J.; Kirwan, P.; Marino, L.; Morley, J. (2008): The Value of Harmonizing
Multiple Improvement Technologies: A Process Improvement Professional‘s View.
Herausgegeben von Carnegie Mellon. Software Engineering Institute. (White Paper
SEI).
Software Engineering Institute (2007): CMMI. Herausgegeben von Carnegie Mellon,
Software Engineering Institute, Pittsburgh, Pennsylvania, USA.
Sommer, J. (2004): IT-Servicemanagement mit ITIL und MOF. Bonn: Mitp.
Stachowiak, H. (1983): Modelle - Konstruktion der Wirklichkeit. München: Wilhelm
Fink Verlag.
Stachowiak, H. (1973): Allgemeine Modelltheorie. Wien: Springer.
Stahlknecht, P.; Hasenkamp, U. (2005): Einführung in die Wirtschaftsinformatik.
Berlin, Heidelberg, New York: Springer (11. Auflage).
Strecker, S. (2009): Ein Kommentar zur Diskussion um Begriff und Verständnis der ITGovernance. Anregungen zu einer kritischen Reflexion. Universität Duisburg Essen.
(ICB-Report, 36).
Szulanski, G. (1996): Exploring internal stickiness. Impediments to transfer of best
practice within the firm. In: Strategic Management Journal, Jg. 17, S. 11–25.
Teubner, A. (2002): Informationsmanagement: Disziplinärer Kontext, Historie und
Stand der Wissenschaft. Westfälische Wilhelms-Universität Münster. Arbeitsberichte
des Instituts für Wirtschaftsinformatik, Nr. 82, Münster.
36
Thielemann, U.; Ulrich, P.; Kuhn, T. (2009): Standards guter Unternehmensführung.
Zwölf internationale Initiativen und ihr normativer Orientierungsgehalt. Bern: Haupt.
Tuttle, B.; Vandervelde, S. D. (2007): An empirical examination of COBIT as an
internal control framework for information technology. In: International Journal of
Accounting Information Systems, Jg. 8, S. 240–263.
van Grembergen, W. (2007): Introduction to the Minitrack "IT Governance and Its
Mechanisms". In: HICSS 2007 - Proceedings of the 40th Annual Hawaii International
Conference on System Sciences. Washington, DC, USA: IEEE Computer Society .
Victor, F.; Günter, H. (Hg.) (2004): Optimiertes IT-Management mit ITIL. Wiesbaden:
Vieweg-Verlag.
Voegele, A. R. (2002): Supply Network Management. Mit Best Practice der
Konkurrenz voraus. Wiesbaden: Gabler.
vom Brocke, J. (2003): Referenzmodellierung. Gestaltung und Verteilung von
Konstruktionsprozessen. Dissertation, Münster, 2002. Berlin: Logos (Advances in
information systems and management science, 4).
Vossen, G.; Becker, J. (1996): Geschäftsprozeßmodellierung und WorkflowManagement. Modelle, Methoden, Werkzeuge. Bonn: Thomson.
Wagner, E.; Newell, S. (2004): 'Best for whom?: the tension between 'best practice'
ERP packages and diverse epistemic cultures in a university context'. In: Journal of
Strategic Information Systems, Jg. 13, S. 305–328.
Wagner, E.; Scott, S.; Galliers, R. (2006): The creation of 'best practice' software: Myth,
reality and ethics. In: Information and Organization, Jg. 16, S. 251–275.
Wagner, H. T. (2006): Managing the impact of IT on Firm Success. The Link between
the resources-based view and the IT Infrastructure Library. In: HICSS 2006 Proceedings of the 39th Annual Hawaii International Conference on System Sciences.
Wagner, H. T.; Weitzel, T. (2008): IT Business Alignment as Governance Tool for Firm
Internal Relationship Quality: A Longitudinal Case Study. In: HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences.
Webb, P.; Pollard, C.; Ridley, G. (2006): Attempting to Define IT Governance: Wisdom
or Folly? In: HICSS 2006 - Proceedings of the 39th Annual Hawaii International
Conference on System Sciences. Washington, DC, USA: IEEE Computer Society, S.
194–204.
Weill, P.; Ross, J. (2004): IT-Governance. How top performers manage IT decision
rights for superior results. Boston, USA: Harvard Business School Press.
Willson, P.; Pollard, C. (2009): Exploring IT Governance in Theory and Practice in a
Large Multi-National Organisation in Australia. In: Information Systems Management,
Jg. 26, S. 98–109.
37
WKWI (1994): Profil der Wirtschaftsinformatik. Ausführungen der Wissenschaftlichen
Kommission der Wirtschaftsinformatik. In: Wirtschaftsinformatik, Jg. 36, H.1, S. 80-81.
Zarnekow, R.; Brenner, W.; Pilgram, U. (2006): Integrated Informationmanagement.
Berlin: Springer-Verlag.
Zelewski, S. (1999): Grundlagen. In: Corsten, H.; Reiß, M. (Hg.): Betriebswirtschaftslehre. Wien: Oldenbourg, S. 1–125.
38
Teil B: Struktur von Best-Practice-Referenzmodellen
Vorbemerkungen Teil B
Wie in der Einführung bereits erläutert, sind BPRM in der Praxis entstanden und es
mangelt ihnen zumeist an wissenschaftlich verwertbarer Struktur. Das bedeutet bspw.,
dass sie nicht zwangsläufig konsistent oder redundanzfrei sind. BPRM enthalten jedoch
fundiertes und konsolidiertes Erfahrungswissen und haben in der Praxis eine tiefe
Durchdringung erreicht. Eine Entwicklung von rein wissenschaftlichen Modellen als
Alternative zu den vorhandenen BPRM ist nicht zu beobachten. Eine Unterstützung der
IT-Governance-Bemühungen von Unternehmen erfolgt daher zumeist über den Einsatz
von BPRM.
Trotz der breiten Anwendung in der Praxis und den sich hieraus ergebenden
Implikationen für eine anwendungsorientierte Wissenschaft sind BPRM nicht
hinreichend erforscht. Zwar gibt es Untersuchungen, die die generelle Nützlichkeit des
Einsatzes von BPRM aufzeigen; die Art und Weise des Einsatzes oder die Struktur von
BPRM sind jedoch bislang nur vereinzelt Ziel von Forschungsbemühungen.123 Vor
diesem Hintergrund und unter Bezugnahme auf vorhandene Forschungsleistung ergaben
sich für diese Arbeit daher folgende initiale Forschungsfragen:
Wie kann eine in der Praxis entwickelte Sammlung von Best-Practices theoretisch
fundiert werden und welchen Mehrwert hat eine solche Analyse für Wissenschaft
und Praxis?
Das Herausarbeiten und Modellieren der Strukturen von BPRM ist hierbei ein erster
notwendiger Schritt. Insbesondere das Metamodellieren von BPRM schafft den für eine
systematische Anwendung notwendigen Formalisierungsgrad. Ziel dieses Teils ist es
daher, die Wissensbasis der IT-Governance-Forschung zunächst hinsichtlich der
Struktur von BPRM zu verbessern. Die in Fachbeitrag 1, 2 und 3 gewonnenen
Erkenntnisse sind eine wichtige Grundlage der weiteren Arbeit.
Fachbeitrag 1 ist ein erster Schritt hin zu einer Erhöhung des Formalisierungsgrades von
BPRM und einer wissenschaftlichen Fundierung von BPRM. Am Beispiel COBIT wird
demonstriert, wie mithilfe eines Metamodells die dem BPRM innewohnenden logischen
und semantisch reichen Strukturen aufgezeigt und dargestellt werden können. Es wird
gezeigt, dass Metamodelle ein solider Startpunkt sowohl für das systematische
Anwenden eines Modells, als auch für das später thematisierte gleichzeitige Anwenden
mehrerer Modelle sind.
Fachbeitrag 2 beschäftigt sich ebenfalls mit der Struktur von BPRM. Der Fokus dieses
Beitrags liegt allerdings im IT-Servicemanagement und damit auf dem BPRM ITIL.
Zunächst werden hierfür grundlegende Eigenschaften von Best-Practice-Referenzmodellen und Fragestellungen, die sich in der Praxis aus ihrem Einsatz ergeben,
erläutert. Die Metamodellierung ist wiederum die Möglichkeit, auf Herausforderungen
im Umgang mit besagten BPRM zu reagieren.
123
Vgl. die Ausführungen in Teil A der vorliegenden Dissertation.
39
Fachbeitrag 3 beschäftigt sich ebenfalls mit der Nutzung von Techniken und Notationen
der konzeptionellen Modellierung zur Metamodellierung von BPRM. Jedoch steht der
Prozess des Metamodellierens, d.h. der Erstellungsprozess eines Metamodells, im
Mittelpunkt dieses Beitrags. Es werden Richtlinien für „gutes― Metamodellieren
erarbeitet und es wird diskutiert, inwieweit Metamodelle eine Basis für die
Verbesserung und Weiterentwicklung von BPRM sind.
Forschungsmethoden:
Ergebnis:
Metamodelle von
COBIT,
ITIL,
CMMI
FachFachbeitrag
beitrag
1 2
Ergebnis:
Grundsätze
ordnungsmäßiger
Metamodellierung
Fachbeitrag 3
Abbildung 8: Darstellung Teil B: Struktur von BPRM
Ziel dieses Teils ist es, BPRM so aufzuarbeiten, dass sie im weiteren Verlauf der Arbeit
systematisch verwendet werden können. Abbildung 8 zeigt erneut den Aufbau des
Teilbereichs Struktur in Anlehnung an die Ausführungen im Kapitel „Forschungsdesign
und Aufbau der Arbeit―.
40
Fachbeitrag 1:
Representing IT Governance Frameworks as Metamodels
Informationen zum Fachbeitrag:
Veröffentlicht in: Proceedings of the 2008 International Conference on e-Learning, eBusiness, Enterprise Information Systems, and e-Government (EEE 2008), Las Vegas,
Nevada, USA, 14.-17.07.2008.
41
Representing IT Governance Frameworks as Metamodels
M. Goeken and S. Alter
IT-Governance-Practice Network, Frankfurt School of Finance and Management, Frankfurt,
Germany
Abstract - Up to now, there is little academic
support for the challenges of IT management.
As a reaction, various best practice frameworks
were developed, which can be subsumed under
the topic IT governance. These still have no
sound basis or scientific foundation. To
undertake a step in this direction we present a
metamodel of COBIT, the popular IT
governance framework. A major goal of this
paper is to represent the underlying logical and
semantically rich structure of this framework.
This turns out to be fruitful for comparing and
integrating different frameworks. Furthermore,
frameworks can be checked for completeness
and can be integrated on this basis. An
interesting application is the representation of
IT governance frameworks in a tool, which is
demonstrated in the paper as well.
Keywords: Frameworks,
Metamodelling
IT
Governance,
Introduction
W
hile there is little guidance for the management of IT in general and for specific
challenges like business/IT alignment or risk management in particular [3], [4], the majority of computer science research deals with system development and related issues. To offer guidance for
management tasks and governance challenges
seems critical because in enterprises, usually a
higher percentage of expenditure is spent on ‘running IT‘ rather than systems engineering and development of new systems.
Due to the fact that there is a clear need for
methodological support for current tasks and challenges of IT management and IT governance, it is
surprising, that little attention is paid to these questions. [6] and [17] censured researchers for the lack
of effort put into evaluating e. g. how business and
IT can be properly aligned, how IT related risks
can be managed and how IT can contribute to the
overall value of the enterprise.
In recent years, there were some associations
and public institutions like ISACA (Information
Systems Audit and Control Association) and
CCTA (Central Computer and Telecommunication
Agency) /OGC (British Office of Government
Commerce) that developed frameworks (e.g.
COBIT and ITIL) to support management and
governance of IT. These frameworks are well established in practice [10], [15]. However, there is a
lack of theoretical foundation, from a scientific
viewpoint,
This paper undertakes steps towards the theoretical foundation of best practice frameworks by
proposing to model them as metamodels.
In the following section (II) we discuss some
definitions of IT governance which helps to reveal
different viewpoints on the subject. In section III
we discuss the concepts ‗model‘ and ‗metamodel‘
as well as their relationship. After that we present a
metamodel of COBIT, the popular IT governance
framework of the ISACA (section IV). Furthermore, we discuss the advantages and the application of this metamodel and show some research in
progress – e.g. a prototype with which we
represent the COBIT framework in an application.
IT Governance
IT Governance is a relatively new field of research. So it is not surprising that the current definitions of IT governance show many differences.
In the following part we compare three widespread
definitions to explain the different aspects of the
term IT governance.
Weill, Ross [21] focus the responsibilities and
the decisions rights and they follow a static and
structurally oriented viewpoint on IT governance.
They define: ―Specifying the decision rights and
accountability framework to encourage desirable
behaviour in the use of IT. IT governance is not
about making specific IT decision – management
does that – but rather determines who systematically makes and contributes to those decisions.‖
The IT Governance Institute (ITGI) underlines
on the one hand the responsibility of the top management but on the other hand it emphasizes the
meaning of organizational structures and
processes: „IT Governance is the responsibility of
the Board of Directors and executive management.
42
It is an integral part of enterprise governance and
consists of the leadership and organisational
structures and processes that ensure that the
organisations‘ IT sustains and extends the
organisations‘ strategy and objectives.‖[9]
Grembergen et al. [8] define: ―IT governance is
the organizational capacity exercised by the Board,
executive management and IT management to control the formulation and implementation of IT
strategy and in this way ensure the fusion of business and IT.‖ They focus amongst others the Business/IT-Alignment, and more than ITGI, refer to a
dynamic viewpoint of IT governance and the
methodological process oriented support.
The metamodel we present in section IV has to
capture both: the more static and structural
oriented as well as the dynamic methodological
viewpoint.
Models and Metamodels
In IS research we use models to abstract from
real world phenomena and real world objects. The
representation as a model usually is the first step of
developing an application or software system.
If the subjects of research are models, and not
the real world or the universe of discourse, we create models of models. Usually a ―model of a
model‖, which is a higher level abstraction, is
called metamodel.
Going from the instance level (real world, UoD)
to the model level and further to the metamodel
level denotes the application of abstraction mechanisms. The most used mechanism in computer science and information systems seems to be the linguistic abstraction.
In order to describe the abstract syntax of a language, usually linguistic metamodels are applied.
They define the available language elements (modelling constructs) and relationships between them
(e.g. constraints), as well as their meaning and generative rules [7].
The abstract syntax of a modelling language defines rules for structuring the real world (or some
part of it) which it should describe by specifying
the building blocks (phenomena) the world
consists of, according to the respective language.
For example, Chens E/R-model defines that the
world (the universe of discourse) consists of
entities, relationships and attributes. The
representation of the subject is matter to the
concrete syntax which defines the assignment of
abstract syntax elements and their relationships to
representational objects (e.g. symbols). The
representation, e.g. the shape of the symbols used,
is called notation. A modelling language usually
has one abstract syntax but may have several
notations (e.g. see the manifold of E/R-model
notations).
It is necessary to stress that linguistic metamodelling is not the only way to perform metamodelling because various mechanisms of abstraction
can be used for different purpose and applications.
Karagiannis and Höffner [12, 13] e. g. emphasis
the ‗ontological metamodeling‘. Other researchers
also
work
on
‗linguistic
or
physical
metamodeling‘. In contrast to linguistic
metamodelling, the ontological metamodels deal
with the classification of model elements according
to their content [1], [2].
In order to metamodel governance frameworks
we will describe relevant model components. We
do this by abstracting from instances using the
classification abstraction (‗instance-of‘) and we
extract the relevant content.
As metamodels represent the ―deep structures‖
of a model, the language used to formulate the
model (the metalanguage) must be able to
represent the concepts of the model. Here, a dialect
of the E/R-approach (see Chen, 1976), the
extended E/R-model (eERM), is used [18, 19].
Therefore, we focus on the static aspects of the
framework and are not able to capture e.g.
information flows directly.
Best Practice Frameworks
Basics
As mentioned in the introduction, science offers
little guidance to IT management and IT
governance issues. Therefore, in the last ten years a
range of open best practice frameworks (ITIL,
COBIT) as well as proprietary frameworks were
developed (Microsoft Operations Framework
(MOF), IT-Service-Management (ITSM) of
Hewlett-Packard, or the IBM IT Process Model
(ITPM)).
These best practice frameworks which are also
subsumed under the developing topic ―IT
governance‖ describe goals, processes and
organizational aspects of IT management and
control. They are created in practice and are given
to use in practice. One point regarding the
development of best practice models is very
43
interesting: practitioners from the business world
consolidate their knowledge aiming to define
generally accepted rules, processes, and
characteristics. Despite the fact that scientists also
participate in the development of already
mentioned frameworks such as COBIT, especially
practitioners are members of the relevant
committees and boards.
From an academic point of view, these best
practice frameworks can be seen as an interesting
object of research, not only because the models are
widely spread in practice but also because they
incorporate a huge amount of consolidated
knowledge. As mentioned before, a sound
scientific discussion and foundation of these
models is missing but could be fruitful.
COBIT
In the following we solely focus on COBIT
(Control Objectives for Information and Related
Technology). COBIT describes a generic process
model, that defines relevant processes and
activities which one should find – according to the
idea of best practice – in an IT department or
organization. Whereas earlier versions put the
main focus on IT audits, the COBIT framework
meanwhile developed to a full-blown support of IT
management covering most relevant tasks and
areas of this topic. In a macro-perspective the IT
processes are arranged by grouping them into four
so called control areas, which are structured similar
to the well known Deming/life cycle (Plan, Do,
Check, Act) (figure 1).
For each of the 34 IT processes various
components, such as business requirements and IT
goals are defined, which satisfy them, controls and
metrics as well as activities resources,
responsibilities, etc. (figure 2).
Furthermore, there are other components and
specification for one process, e.g. the persons who
should be informed, should be consulted etc. are
defined. These parts will be introduced in 4.3 with
the metamodel.
The Metamodel of COBIT
Mainly, there were two reasons to start with
metamodeling COBIT. First of all, this framework
is well structured in chapters and components, and
therefore closed in itself and self-contained.
Secondly, COBIT is holistic and represents
(nearly) all tasks and processes an IT organization
should carry out.
For example, ITIL [16] is – like COBIT –
holistic, but has a lack of structure. On the other
hand, e.g. CMMI [20] focuses on a specific task
(development), but has a coherent structure.
However, these existing structures primarily
serve the purpose to present the framework
consistently and structured. It supports the
navigation and the usage of the framework but may
not be mixed up with a metamodel. A goal of
metamodelling the framework is to extract and
present the underlying logical and semantically
rich relationships.
Here we use an abstraction mechanism which
extracts the components of the underlying model.
We use the well known extended E/R notation to
represent our version of the COBIT metamodel.
The analysis is stepwise and takes place in
fragments which are in the end combined to one
model. Initial point of the partial analysis is the
entity type ‗process‟ and thus, it is also the later
necessary entity which integrates the fragments.
Control Objectives, Activities and Results
In COBIT, 34 IT processes are presented which
produce one or more outputs which vice versa are
used as inputs in other processes. Input and output
are results. According to this, the entity type result
‗is-a‘ output or input of a process. Typical results
on instance level are documents like reports on
costs, risks or plans on IT-strategy.
Process
contains
Control
Objective
Activity
creates
uses
is
assigned
to
Result
Role
isa
Input
Output
Fig. 2 Control Objectives, Activities and Results
Moreover, a process consists of control
objectives which are statements of desired results
or purposes to be achieved by implementing
control procedures in a particular process. These
control procedures should provide ‗reasonable
assurance‘, that business objectives will be
achieved. Furthermore, a process includes
activities, which give a detailed description of what
44
BUSINESS OBJECTIVES
GOVERNANCE
OBJECTIVES
COBIT 4.1
ME1 Monitor and Evaluate IT Processes
ME2 Monitor and Evaluate Internal Control
ME3 Ensure Regulatory Compliance
ME4 Provide IT Governance
INFORMATION
CRITERIA
MONITOR AND
EVALUATE
PLAN AND
ORGANISE
IT RESOURCES
DS1 Define and Manage Service Levels
DS2 Manage Third-party Services
DS3 Manage Performance and Capacity
DS4 Ensure Continuous Service
DS5 Ensure Systems Security
DS6 Identify and Allocate Costs
DS7 Educate and Train Users
DS8 Manage Service Desk and Incidents
DS9 Manage the Configuration
DS10 Manage Problems
DS11 Manage Data
DS12 Manage the Physical Environment
DS13 Manage Operations
DELIVER AND
SUPPORT
ACQUIRE AND
IMPLEMENT
PO1 Define a Strategic IT Plan
PO2 Define the Information Architecture
PO3 Determine Technological Direction
PO4 Define the IT Processes, Organization
and Relationships
PO5 Manage the IT Investment
PO6 Communicate Management Aims
and Direction
PO7 Manage IT Human Resources
PO8 Manage Quality
PO9 Assess and Manage IT Risks
PO10 Manage Projects
AI1 Identify Automated Solutions
AI2 Acquire and Maintain Application
Software
AI3 Acquire and Maintain Technology
Infrastructure
AI4 Enable Operation and Use
AI5 Procure IT Resources
AI6 Manage Changes
AI7 Install and Accredit Solutions and
Changes
Fig. 1 The COBIT framework – macro perspective [11]
is done. These activities are carried out by specific
persons like the CFO, the CIO, or an architect.
Therefore, we link activities to the concept role (fig.
2).
Goals and Metrics
Each process of the framework has goals, which
can be divided into business goals, IT goals, process
goals and activity goals. The goals again are in
relationship with each other. Thus, IT goals activate
process goals, which in turn end up in activity goals
(e.g. IT goals define what the business expects from
IT; Process goals define what the IT process must
deliver to support IT‘s objectives etc.). Each goal is
measured with the aid of different metrics (key goal
indicators and key performance indicators).
Furthermore, a process contains information
criteria, which are abstract business goals. The
information criteria proposed by COBIT are
effectiveness,
efficiency,
confidentiality,
availability, compliance and reliability. For every
process COBIT states if these criteria are supported.
It is distinguished between a primary and a
secondary relationship.
Goals as well as metrics usually are neither
considered as components in method descriptions
[5] nor in the widespread modelling notations like
EPC ((Event-driven Process Chain) or BPMN
(Business Process Modelling Notation) [14]. From
an IT governance point of view, goals and metrics
are of high importance because in order to control,
govern and manage, you have to quantify the
relevant facts (―You cannot manage without
measuring‖) (fig 3).
IT Goal
Process Goal
Activity Goal
isa
is
measured
by
Goal
Metric
is
supported
by
Process
Level of Support
is
adressed
by
Information
Criteria
Fig. 3 Goals and Metrics
Maturity Model, IT Resource, Domain
Each process is assigned to one of four domains,
which are arranged according to the life cycle.
Further components of COBIT are a maturity model,
45
four domains and IT resources. Each process can be
assessed by a maturity model to determine its level
of maturation. This is the starting point for a
continuous process improvement of the process
maturity and its controls.
In order to achieve any results, a process needs
the entity type IT resource. Implicit components as
the life cycle orientation of COBIT could enter the
metamodel as principles. However, a principle can
not be dedicated to a single entity type. Implicit
basic principles form the framework as a whole and
thus have to be put in another level of the
metamodel.
IT Governance Focus Areas
Finally, each process has the attributes process
code and process description. The process code is a
unique identifier of the process. It consists of the
abbreviation of the domain and a number.
Furthermore, each process supports a specific IT
governance focus area. These IT governance focus
areas ‗describe the topics that executive
management needs to address to govern IT within
their enterprises‘ [10]. For each process there is an
indication if it addresses the focus area. Like above
it is distinguished between a primary and a
secondary relationship. Figure 4 shows the
integrated metamodel. The entity type process is
used for the integration of the partial models
presented above.
To conclude, by building the metamodel of
COBIT, a lot of components could be extracted as
being important for IT governance. A support for IT
governance has to define certain activities (or
processes) which generate specific results. The
process aspect is more closely related to the dynamic
and control oriented view on IT governance. From
the static/structural viewpoint, it is of primary
importance to organize work and to assign
responsibilities that is to relate roles to processes or
activities. For IT governance purpose, the
assignment of roles to results might also be required
sometimes. This aspect is missing until now in fig.
4. For both viewpoints, the assignment of metrics
and goals to processes is of outstanding importance.
Application and Usage of the
Metamodel
Several advantages accrue from representing IT
governance frameworks like COBIT, ITIL or CMMI
as method metamodels. In the following we will
discuss some of the resulting benefits and possible
applications.
First, the representation allows the comparison of
different frameworks on an abstract level. Once the
components are extracted, frameworks can be
examined and analyzed. Thus, other frameworks can
be checked for completeness with the aid of the
metamodel. Accordingly, one can deduce that ITIL –
in contrast to COBIT - does not provide metrics and
other components for assessment to the extent
COBIT does. Another benefit of the metamodel is
the integration of new or existing processes in the
COBIT framework. This becomes apparent in the
following example: The area outsourcing is hardly
represented in the COBIT framework. However,
outsourcing is an essential component of their IT
strategy for some companies. With the aid of the
metamodel a ‗Control of the outsourcing‘-process
can be developed under guidance. In order to
develop this process, the metamodel has to be
instantiated. In addition, the integration of the
process into other existing IT processes can for
example occur by linking the results. When inputs
flow to the process and the output is used elsewhere,
the new process becomes part of the overall IT
process landscape. One step further could be the
metamodel based fusion of frameworks like COBIT,
ITIL and CMMI. This might be of importance if one
framework covers aspects, which are missing in
another one. E.g. the new developments of the SEI
(CMMI for Services; CMMI for Acquisition) can be
a complement for COBIT. A metamodel based
integration will allow a closer fit and can guide the
models amalgamation on lower level.
Besides, the metamodel can be the starting point
for the representation of COBIT in an application
system. The components and the logical and
semantic relationships are necessary, e.g. for the
implementation in a semantic network. We are
currently developing a framework representation
with this technology which allows the flexible
navigation within framework structures and the
implementation of various views over the
components (see Appendix). This can be
demonstrated by the screenshot: In the figure, PO1
(Define a strategic IT plan) is linked to PO 5
(Manage the IT investment) through various results
(tactical IT plan, IT project portfolio, IT project
portfolio). Furthermore, there are metrics which
measure performance and the achievement of goals
(key goal indicators, performance indicators). With a
tool like this, we hope to support the implementation
of governance frameworks in practice significantly.
46
Role
Input
Control
Objective
Activity
assign
uses /
needs
IT-Resource
is
contained
in
belongs to
Domain
Process
adresses
Information
Criteria
supports
fulfils
Maturity Level
Output
isa
is used by
Result
is created
by
IT Goal
Process Goal
isa
Activity Goal
Goal
IT Governance
Focus Area
is
measured
by
Metric
is
determined
by
Maturity Model
Fig 4 The COBIT Framework as a Metamodel
Conclusions and Future
Research
In this paper we discussed and presented a way to
represent the popular IT governance framework
COBIT as a metamodel. The intention was to
demonstrate that metamodelling is a useful
technique to gain a theoretical foundation. From our
point of view, it is possible and fruitful to interpret
IT governance frameworks as metamodels. IT
governance models can learn from a rigid
formalization and a systematic approach.
In the article, we extracted the relevant
components performing some kind of ‗framework
re-engineering‘ on COBIT. The resulting metamodel
brings some benefits for comparing and integrating
different frameworks. Furthermore, frameworks can
be checked for completeness against the model. An
interesting application might be the representation of
IT governance frameworks in a tool which was
demonstrated in the previous section.
To give a widespread and holistic support for IT
governance, it‘s not enough to metamodel one
framework. Instead, it is necessary to complement it
with the knowledge of other frameworks and the
findings of academic research. Therefore, the
representation of COBIT can only be the first step in
the process of building a wider metamodel.
Another interesting area of development is the
situation specific and enterprise specific adaptation
and configuration of governance models, because
frameworks like COBIT and ITIL are seldom
implemented completely and without modification.
Metamodelling is the starting point for a
methodological support for model adaptation. In
further research, the metamodel presented should be
made configurable by introducing and modelling
variability on instance as well as on metamodel
level.
References
[1] Atkinson, Colin; Kühne, Thomas: ModelDriven Development: A Metamodeling Foundation,
IEEE Software, vol. 20, no. 5, pp. 36–41, 2003.
[2] Atkinson, Colin; Kühne, Thomas: Calling a
Spade a Spade- in the MDA Infrastructure,
International Workshop ―Metamodeling for MDA‖,
York, November 2003.
[3] Avison, D., Jones, J., Powell, P., Wilson, D.:
Using and Validating the Strategic Alignment
Model. In Journal of Strategic Information Systems,
2004.
[4] Booth, Marilyn, E., Philip, G.: Information
Systems Management: Role of planning, alignment
and managerial responsibilities. In Behaviour and
information Technology vol.24 no.5, 2005.
47
[5] Braun, Christian; Wortmann, Felix; Hafner,
Martin; Winter, Robert: Method construction - a
core approach to organizational engineering. SAC
2005: 1295-1299.
[6] Chan, Y. E., Huff, S. L., Barclay, D. W.,
Copeland, D. G., 1997. Business Strategy
Orientation, Information Systems Orientation and
Strategic Alignment. In Information Systems
Research 8.
[7] Ferstl O.K., Sinz E.J.: Grundlagen der
Wirtschaftsinformatik. 5., überarb. und erw. Aufl.,
Oldenbourg-Verlag, München 2006.
[8] Grembergen, W.V; De Haes, Steven;
Guldentop, Erik: Structures, Processes and
relational Mechanisms for IT-Governance, Idea
Group, o.O. 2004.
[9] IT Governance Institute: Board Briefing on IT
Governance, ITGI, 2. Edition, 2003.
[10] IT Governance Institute: IT Governance
Global Status Report, 2006. Under: www.isaca.org,
at March 3rd of 2007.
[11] IT Governance Institute, 2007. COBIT 4.1.
[12] Karagiannis, D., & Kühn, H. (2002).
Metamodeling Platforms. In A. Min Tjoa, & G.
Quirchmayer (Eds.), Lecture Notes in Computer
Science: Vol. 2455. Proceedings of the Third
International Conference EC-Web 2002 (pp. 451–
464). Springer.
[13] Karagiannis,
Dimitris;
Höfferer,
P.:
Metamodels in action: An overview. ICSOFT (1)
2006.
[14] Korherr, B.; List, B.: Extending the EPC and
the BPMN with Business Process Goals and
Performance Measures. In: Filipe, J. et al. (Hrsg.):
Proceedings of the 9th International Conference on
Enterprise Information Systems, ICEIS 2007, June
2007 Funchal/Portugal.
[15] KPMG: Summary of KPMG IS Governance
Survey. KPMG LLP, London, September 2004.
[16] OGC, Office of Government Commerce, 2007.
ITIL V3. Service Strategy, London.
[17] Reich, B. H., Benbasat, I., 1996. Measuring
the linkage between business and information
technology objectives. In MIS Quarterly, 20, 1,
1996, 55. MIS-Quarterly 28 (2004) 1, S. 75-105.
[18] Scheer,
A.-W.:
ARIS-ModellierungsMethoden, Metamodelle, Anwendungen. Heidelberg
2001.
[19] Scheer,
A.-W.:
Wirtschaftsinformatik.
Referenzmodelle für industrielle Geschäftsprozesse.
Berlin et al. 1995.
[20] Software Engineering Institue, CMMI, 1999.
[21] Weill, Peter; Ross, Jeanne W.: IT governance:
how top performers manage IT decision rights for
superior results. Harvard Business School Press,
Boston, Massachusetts 2004.
Appendix: COBIT as a Semantic Net
48
Fachbeitrag 2:
Metamodelle von Referenzmodellen am Beispiel ITIL. Vorgehen, Nutzen,
Anwendung.
Anwendung
Autoren: Goeken, Matthias; Alter, Stefanie; Milicevic, Danijel; Patas, Janusch
Veröffentlicht in: Proceedings der Informatik 2009, Lecture Notes in Informatics (LNI),
Fischer, Stefan; Maehle, Erik; Reischuk, Rüdiger
49
Metamodelle von Referenzmodellen am Beispiel
ITIL
Vorgehen, Nutzen, Anwendung
Matthias Goeken, Stefanie Alter, Danijel Milicevic, Janusch Patas
IT-Governance-Practice-Network,
Sonnemannstr. 9-11, 60314 Frankfurt am Main
[m.goeken, s.alter, d.milicevic, j.patas] @ frankfurt-school.de
1 Einleitung
Die Anforderungen an die Unternehmens-IT haben sich über das letzte
Jahrzehnt hinweg drastisch verändert. Erhöhte Flexibilität und Adaptivität
der
IT-Abteilungen
in
ihren
Technologien,
Prozessen
und
Organisationsstrukturen, werden aufgrund neuer Geschäftsmodelle und der
Erschließung neuer Märkte gefordert. Als eine Reaktion darauf hat sich die
Ausrichtung vieler IT-Abteilungen in Richtung Serviceorientierung verlagert
[Be00]. Diese Entwicklungen wurden von der wissenschaftlichen Seite her
nicht hinreichend unterstützt [RB96], so dass die Entstehung sogenannter
Best-Practice-Referenzmodelle aus der Praxis heraus nicht verwundert.
Dennoch ist es überraschend, dass es weiterhin an wissenschaftlichen
Methoden zur Bewältigung dieser Herausforderungen im IT-Management
fehlt.
Der vorliegende Artikel möchte zur Überwindung dieses Mangels beitragen,
indem er an der theoretischen Fundierung von Best-PracticeReferenzmodellen ansetzt. Zunächst werden grundlegende Eigenschaften
von Best-Practice-Referenzmodellen und Fragestellungen, die sich in der
Praxis aus ihrem Einsatz ergeben, erläutert. Dabei wird die
Metamodellierung als eine Möglichkeit, auf Herausforderungen im Umgang
mit besagten Referenzmodellen zu reagieren, erörtert. Metamodelle
erscheinen als ein wichtiger Ansatzpunkt, den Umgang mit
Referenzmodellen wissenschaftlich zu fundieren. Am Beispiel der IT
Infrastructure Library (ITIL) wird das Vorgehen zur Modellierung eines
Metamodells dargestellt.
50
2 Best Practice-Referenzmodelle
2.1 Grundlagen zu Referenzmodellen
In den letzten zehn Jahren entstanden verschiedene Best-PracticeReferenzmodelle und sie finden vermehrt Anwendung in IT-Abteilungen
[IG08]. Darunter befinden sich offene Referenzmodelle, bspw. ITIL,
COBIT, CMMI, VAL-IT oder RISK-IT, sowie proprietäre Referenzmodelle
wie das Microsoft Operations Framework (MOF) oder das HP IT-Service
Management Reference Model (ITSM) von Hewlett-Packard. Diese und
auch weitere Modelle und Standards wie die ISO 2700x, PMBOK und
Prince 2 lassen sich als Referenzmodelle der IT-Governance auffassen
[JG07]. Ein wesentliches Merkmal solcher Referenzmodelle ist, dass ihre
Entwicklung auf der Konsolidierung von Praxiserfahrung beruht. Das so
entstehende Modell besteht aus einer Sammlung von Prozessen, Regeln und
Organisationsstrukturen, die im Konsens gebildeten wurden und insofern
breit akzeptiert sind.
Die unterschiedlichen Referenzmodelle legen ihren Schwerpunkt jeweils auf
unterschiedliche Aspekte. So widmet sich ITIL dem IT-Servicemanagement,
COBIT ist als Modell für IT-Governance positioniert, ohne dabei aber seine
Wurzeln im Auditing zu verbergen. CMMI fokussiert v.a. die
Systementwicklung und die genannten ISO 2700x Standards unterstützen
das Sicherheitsmanagement.
Referenzmodelle sind aufgrund ihrer Entstehung sehr pragmatisch und
vernachlässigen wissenschaftliche Aspekte wie den Gebrauch von
Formalsprachen, eine stringente Methode bei der Entwicklung oder eine
abschließende Validierung. Während diese Aspekte zunächst keinen direkten
Einfluss auf die Anwendbarkeit in der Praxis haben, sind sie jedoch ein
Hindernis beim weiteren Einsatz dieser Modelle, bspw. bei deren
Erweiterung.
2.2 IT Infrastructure Library
Als Beispiel für Best-Practice Referenzmodelle steht ITIL im Mittelpunkt
unserer Untersuchung. Als das bekannteste und am weitesten verbreitete
Referenzmodell im Bereich IT-Governance [IG08] dient ITIL als eine Art
Vorbild für ähnliche Referenzmodelle. ITIL ist ein generisches Modell für
das IT-Servicemanagement und macht Vorgaben, indem es durch die
Beschreibung von Prozessen, Aktivitäten und Metriken, Anregungen für
dessen Implementierung gibt.
51
In der zweiten Version, die maßgeblich für den heutigen Erfolg von ITIL
verantwortlich ist, lag der Fokus hauptsächlich auf den zwei Komponenten
―Service Delivery‖ und ―Service Support‖, neben ―Application
Management‖ und ―ICT Infrastructure Management‖. Die in 2007
veröffentlichte ITIL v3 reflektiert die fortwährende Weiterentwicklung im
Bereich IT-Servicemanagement, die das Hauptaugenmerk weg von einem
primär prozessorientierten Modell in Richtung eines vollwertigen Serviceorientierten Modell gelegt hat. Das Betätigungsfeld wurde um Gebiete wie
IT-Strategie erweitert und die Bestandteile orientieren sich nun am ITService-Lebenszyklus, der dem Deming Cycle ähnelt.
Diese Entwicklung wird auch an den strukturellen Änderungen in ITIL
deutlich. Insbesondere wirken sich solche Änderungen als Herausforderung
für IT-Abteilungen aus, die ihre ITIL-v2-Implementierung nach ITIL v3
erweitern wollen. Während [Ta06] ITIL v3 als ein Add-on zu ITIL v2
beschreibt, zeigen Mappings, dass nicht lediglich eine Erweiterung gegeben
ist, sondern neue Bestandteile und Zuordnungen stattfinden, die nun dem ITService-Lebenszyklus folgen (Tabelle 1). Dadurch ist ein simples Eins-zuEins Mapping nicht mehr möglich [IT08]. Die Prozentzahlen in der linken
Spalte beschreiben jeweils den Überlappungsgrad der sieben ITIL v2 Bücher
zu den fünf ITIL v3 Büchern, während die Prozentangaben in der Zeile den
Anteil neuer Inhalte in ITIL v3 darstellen.
ITIL v2
ITIL v3
SS
SD
ST
SO
CSI
Service
Strategy
Service
Design
Service
Transition
Service
Operation
70% neu
40% neu
40% neu
30% neu
Continuous
Service
Improvement
70% neu
70%
Service Support
●
●
●
●
70%
Service Delivery
●
●
●
●
40%
App Mgmt
●
●
●
30%
Software
Mgmt
●
●
●
20%
Sec Mgmt
●
●
●
40%
Business
Perspective
●
●
40%
ICTIM
●
●
Asset
●
●
Tabelle 1: ITIL v2-nach-v3 Mapping [IT08]
52
2.3 Herausforderungen im Umgang mit Referenzmodellen
In der Praxis sind Bedarfe und Anforderungen erkennbar, die Fragen zur
Handhabung solcher Modelle aufwerfen, und Lösungsansätze erfordern. In
diesem Teil werden einige dieser Anforderungen beschrieben und es wird
skizziert, wie Metamodelle hier als Unterstützung dienen können.
Bereits die Einführung eines Best-Practice-Referenzmodells im
Unternehmen stellt eine Herausforderung dar, da es in der Regel nur selten
vollkommen unverändert zum Einsatz kommt. Vielmehr sind häufig
Anpassungen an unternehmensspezifische Belange nötig, bspw. dadurch,
dass das Modell erweitert oder aber dass Teile weggelassen werden. Die
Erweiterung kann u. a. bedeuten, dass ganze Prozesse hinzu kommen
[KW08] oder dass neue Metriken, Rollen und Ziele für beschriebene
Prozesse definiert werden.
Da in der Praxis oftmals die Referenzmodelle als Ausgangspunkt für die
Entwicklung eigener Modelle genutzt werden [IG08], scheint es ratsam,
diese Anpassungen – im Sinne von unternehmensspezifischen Varianten –
methodisch zu fundieren.
Hierbei können Metamodelle ein erstes unterstützendes Werkzeug sein. Ein
Metamodell bei der Anpassung zugrunde zu legen, kann dabei helfen, die
vorgenommenen Erweiterungen konsistent zu den vorhandenen Strukturen
zu halten. Dies erlaubt bspw., neue Prozesse mit vorhandenen Prozessen
angemessen systematisch und strukturell konsistent zu verbinden.
Darüber hinaus werden verschiedene Referenzmodelle häufig parallel
eingesetzt. Dies ist zum einen deshalb der Fall, weil unterschiedliche
Modelle jeweils der Perspektive unterschiedlicher Stakeholder im
Unternehmen
entsprechen
(CMMI
entspricht
der
Entwickler/Projektleiterperspektive; COBIT v. a. der Perspektive von internen und
externen Auditoren etc.). Zum anderen kann es zweckmäßig sein, die
verschiedenen Referenzmodelle im Sinne eines „Best-of-Breed―-Ansatzes
parallel zu verwenden. Da sie jeweils unterschiedliche inhaltliche
Schwerpunkte haben, können Sie so für einen unternehmensspezifischen
Einsatz gemäß ihren jeweiligen Stärken kombiniert werden.
Dass in der Praxis ein Bedarf besteht, vorhandene Modelle miteinander zu
kombinieren, zeigt sich an einer Reihe von sog. „Mapping-Initiativen―, bei
denen unterschiedliche Referenzmodelle jeweils miteinander in Beziehung
gesetzt werden.1 Dieses In-Beziehung-Setzen geschieht auf der Ebene der
1
In den Mappings der ISACA (vgl. www.isaca.org/mappings), wird angegeben, welche
Komponenten verschiedener Referenzmodelle miteinander korrespondieren bzw. sich
53
konkreten Inhalte, sodass zum einen nicht alle Modellkomponenten
einbezogen werden können; zum anderen sind die „Mappings― sehr
detailliert und umfangreich und ihre Praxistauglichkeit nicht unbedingt
gegeben (zu methodischen Problemen hierbei siehe [JG07]).
Auch an dieser Stelle können Metamodelle eine Unterstützung bieten. Sie
sind eine höhere Abstraktionsebene und so finden Vergleich und
Kombination bzw. Integration unterschiedlicher Referenzmodelle nicht mehr
nur auf Detailebene statt. Mittels Metamodellen können vielmehr auch die
Modellstrukturen systematisch analysiert und verglichen werden und eine
Kombination erfolgt konsistent zu diesen zugrundeliegenden Strukturen.
Darüber hinaus bieten Metamodelle eine Vergleichsgrundlage und einen
Ausgangspunkt für eine Integration, da sie die „einheitliche Darstellung
verschiedener Formalismen erlauben― [St96]. Dies ist hilfreich, da
unterschiedliche Referenzmodelle in jeweils unterschiedlichem Maße
strukturiert sind. COBIT bspw. folgt streng einer Formularstruktur, während
die ITIL-Inhalte im Wesentlichen „prosaisch― und in Fließtext beschrieben
sind.
Um die genannten Anforderungen der Praxis – unternehmensspezifische
Anpassung,
Erweiterung,
Kombination
und
Integration
von
Referenzmodellen – erfüllen zu können, scheint ein methodisch gestützter,
wissenschaftlicher Umgang mit ihnen ratsam.
3 Metamodellierung
3.1 Modell und Metamodell
In der Informatik werden Modelle genutzt, um von Sachverhalten zu
abstrahieren. Die Darstellung eines Sachverhalts als ein Modell ist
gewöhnlich einer der ersten Schritte zur Entwicklung einer Applikation. Im
Folgenden betrachten wir die Modellierung von Modellen. Ziel dabei ist es,
die theoretische Fundierung von IT-Governance-Referenzmodellen zu
stärken, indem eine Abstraktion vorgenommen wird.
Wenn der Sachverhalt bzw. der Untersuchungsgegenstand ein Modell ist –
also selbst bereits eine Abstraktion – dann werden Modelle von Modellen
ergänzen. Hierbei werden jeweils nur Teile und ausgewählte Komponenten der Modelle in
die Betrachtung einbezogen. Gleichzeitig ergibt sich dabei eine enorme Detailtiefe, da die
Betrachtung auf Ebene der Modelle selbst erfolgt. Ein Vergleich der den Modellen
zugrundeliegenden Strukturen findet in der Regel nicht statt.
54
gebildet. Für gewöhnlich wird ein solches Modell eines Modells als
Metamodell bezeichnet. Hieraus ergeben sich dann mehrere Modellebenen
(Abbildung 1). [St96] betrachtet wie diese Hierarchien konstruiert sind und
prägt dabei den Begriff Metaisierungsprinzip für den Vorgang der
Konstruktion, der wiederholt angewendet werden kann: das
Metaisierungsprinzip beschreibt „denjenigen Aspekt eines Modells, der in
der übergeordneten Modellierungsstufe abgebildet wird.― Sie betont, dass
verschiedene Möglichkeiten bestehen, wie man von den Instanzen der
Wirklichkeit zu Modellen und schließlich zu Metamodellen kommt [siehe
auch Kü06].
Das Metaisierungsprinzip definiert demnach in einer Modellhierarchie den
Abstraktionsmechanismus zur Strukturierung der Objekte der jeweils
darunterliegenden Ebene. Der Abstraktionsmechanismus, der in der
Informatik am häufigsten genutzt wird, ist die linguistische Abstraktion.
Daraus entstehen linguistische Metamodelle, die die Sprache der Modelle
auf der tiefer liegenden Ebene beschreiben. Wenn b ein ungerichteter Graph
benutzt (M2) wird, um einen Teil der Wirklichkeit zu repräsentieren (M0),
können auf Modellebene (M1) nur noch Kanten und Knoten genutzt werden.
Dadurch kann kein Kontrollfluss abgebildet werden. Insofern zwingt die
Ebene Mx, die Objekte auf Ebene Mx-2 entsprechend den vordefinierten
Bausteinen zu strukturieren.
Jedoch ist die linguistische Abstraktion nicht die einzige Möglichkeit, die
sich im Rahmen der Modellhierarchie ergibt. [KK02] wie auch [KH06]
beschreiben die „ontologische Metamodellierung―. Andere Autoren
hingegen betreiben Forschung zur sog. „physikalischen Metamodellierung―
[AK03a, GH05]. Für die hier betrachtete Fragestellung ist insbesondere die
ontologische Metamodellierung von Bedeutung: Im Gegensatz zur
linguistischen Metamodellierung behandelt sie die Abstraktion von
Modellelementen gemäß ihres Inhalts [AK03a, AK03b]. Mit der
ontologischen Metamodellierung werden auf der Ebene Mx Metatypen
definiert, welche die auf Mx definierten Metatypen sowie deren
Eigenschaften beschreiben.
Die
Unterschiede
zwischen
ontologischer
und
linguistischer
Metamodellierung sind in Abbildung 1 dargestellt, die auch unseren Ansatz
demonstriert, der im Folgenden weiter konkretisiert wird. In dem Beispiel
befindet sich auf Ebene M0 eine konkrete Aktivität in einem IT-Prozess (ein
spezifisches Ticket im Service Desk # 2009-42). Die ausgeführten
Aktivitäten sind Instanzen des ITIL-Prozessschrittes „Incident
Identification― innerhalb des „Incident Managements― im Buch Service
55
Operation. In ITIL sind die Definitionen der Prozesse und ihrer Aktivitäten
in Prosa beschrieben und somit ist ITIL semi-strukturiert. In Bezugnahme
auf die ontologische Metaisierung kann „Incident Identification― als
Aktivität auf Metamodellebene klassifiziert werden.
M3
Metametamodel
Knoten
repräsentiert
Modellkomponente
linguistische
Metaisierung
M2
Metamodel
ontologische
Metaisierung
Semistrukturiert
natürlichsprachlich
Aktivität
linguistische
Metaisierung
M1
Model
ontologische
Metaisierung
Incident identification
(Service Operation (4.2.5.1))
instance
of
M0
Instance
Service-Desk-Prozess
ticket # 2009-42
Abbildung 1: Ontologische und linguistische Metamodellierung in Anlehnung an
[AK03a]
Die ontologische Metaisierung von M1 (wo sich ITIL befindet) zur
Metaebene M2 (wo sich das hier vorgestellt Metamodell befindet) ist der
Kern der Modellierungsaktivitäten und wird im folgenden Abschnitt
beschrieben.
Zur Modellierung von Ausschnitten der Realität benötigt man eine Sprache
sowie Methoden im Sinne von Vorgehensweisen, die die Identifikation wie
auch die Repräsentation der relevanten Objekte, im Modell unterstützen. Die
Sprache kann man als „way of modelling― und die Vorgehensweisen als
„way of working― bezeichnen [VHW91]. In der Informatikforschung liegt
der Fokus zumeist auf dem „way of modelling―, das heißt auf der Sprache
bzw. Notation, und nicht so sehr auf der Fragestellung wie aus der
Diskurswelt die relevanten Sachverhalte extrahiert werden können, die die
wesentlichen Modellinhalte bilden sollen. Nachfolgend legen wir den Fokus
zunächst auf den „way of thinking―, indem wir Richtlinien und Prinzipien im
Rahmen der Metamodellierung diskutieren. Dies wird als eine
56
Vorbedingung für die Definition des „ways of working― gesehen. Letzterer
wird im darauffolgenden Abschnitt 4 beschrieben und vor dem Hintergrund
der hier betrachteten Problemstellung beleuchtet.
Beim „way of modelling― sind in dieser Arbeit die Freiheitsgrade gering. Da
das Werkzeug Protégé zum Einsatz kommt, wird das Modell als
ungerichteter Graph repräsentiert. Insofern konzentrieren wir uns auf die
statischen Aspekte des Referenzmodells und sind nicht in der Lage,
Steuerungs- und Informationsflüsse direkt einzufangen. An anderer Stelle
wurde von den Verfassern ein Metamodell vorgestellt, dass die E/R-Notation
verwendet [GA09].
3.2 Grundsätze der Metamodellierung
Wie bereits erwähnt, liegt der Schwerpunkt in der Informatik und
Wirtschaftsinformatik
häufig
auf
der
Entwicklung
von
Modellierungssprachen. Die Fragestellung, wie das Wissen der Domäne in
das Modell gelangt, wird häufig nicht weiter betrachtet. Auf der andere Seite
kümmert sich die Disziplin „Requirements Engineering―, die sich mit der
Erfassung des Wissens der Anwender und Benutzer befasst, häufig nur im
geringeren
Maße
um
die
semiformale
Darstellung
mittels
Modellierungssprachen. Zwar weisen die beiden Gebiete „Modellierung―
und „Requirements Engineering― Überlappungen auf [RP00], eine
durchgängige methodische Unterstützung ist nicht gegeben.
Um diese Lücke zu füllen, schlagen einige Forscher eine schrittweise
Methode zur Metamodellierung vor [KW07], während andere eine
epistemologische Beschreibung an den Anfang stellen. [SR98]. Auf letzterer
aufbauend, leiten wir im Folgenden einige Grundsätze für die
Metamodellierung ab.
Da ein Metamodell als „Modell eines Modells― definiert ist, können die
sogenannten „Gründsätze ordungsmäßiger Modellierung― Anwendung
finden. [Sc98] und [SR98] schlagen sechs Grundsätze zur
Qualitätssteigerung von Informationsmodellen vor. Diese Grundsätze sind:
(1) Grundsatz der Richtigkeit
(2) Grundsatz der Relevanz
(3) Grundsatz der Wirtschaftlichkeit
(4) Grundsatz der Klarheit
(5) Grundsatz des systematischen Aufbaus
(6) Grundsatz der Vergleichbarkeit
Die Autoren vertreten die Ansicht, dass für die Metamodellierung eine
Erweiterung dieser sechs Grundsätze notwendig ist. Um den Schritt von
57
einem Modell zu einem Metamodell zu vollziehen, nutzt der Modellierer den
Prozess der Abstraktion. Dieses Prinzip der Metaisierung, z.B. in seinen
Formen der ontologischen oder linguistischen Metaisierung, hat immense
Konsequenzen für das konstruierte Metamodell (siehe folgende Absätze).
Vor allem die ontologische Metamodellierung, welche wir zur Entwicklung
unseres Metamodells nutzen, erfordert eine Vielzahl von Entscheidungen
durch den Modellierer. Der Nutzer des Metamodells benötigt entsprechend
die Information, welches Prinzip der Metaisierung der Modellierer genutzt
hat, um das Metamodell zu entwickeln. Der erste Grundsatz der
Metamodellierung ist dementsprechend: Ein Metamodell muss das ihm
zugrundegelegte Prinzip der Metaisierung darlegen.
Das Ziel der Metamodellierung ist, die oben (2.3) genannten Anforderungen
aus der Praxis, wie unternehmensspezifische Anpassung, Erweiterung,
Kombination und Integration von Referenzmodellen methodisch zu
unterstützen. Aufgrund dieses Anwendungsfeldes, der verschiedenen Nutzer
und dem hohem Abstraktionsgrad, erfordert das Metamodell eine klare
Zuordnung zwischen der Diskurswelt und den Wörtern und Symbolen, die
es benutzt [FS06, RS03]. Dies bedeutet, dass sprachliche Defekte wie
Synonyme und Homonyme minimiert oder entfernt werden. Das folgende
Beispiel zeigt die Relevanz der Metamodellierung: Viele Best-PracticeReferenzmodelle verwenden die Komponente „Ziel“. Allerdings hat jedes
dieser Referenzmodelle seine eigene Definition für das Wort Ziel mit
entsprechend abweichender Semantik. Folglich hat man Komponenten, die
zwar denselben Namen tragen, allerdings verschiedenen Bedeutungen
innehaben. Falls ein Vergleich zwischen den Generic Goals aus dem CMMI
Model mit den Business Objectives aus ITIL erstellt wird, erkennt man, dass
sie die gleiche Bedeutung haben, jedoch unterschiedliche Konzepte
verfolgen. Der zweite Grundsatz der Metamodellierung sollte daher lauten:
Ein Metamodell hat eine eindeutige Zuordnung zwischen seiner Diskurswelt
und den Wörtern und Symbolen, die das Metamodell beschreiben.
Als dritten Grundsatz schlagen die Autoren vor: Ein Metamodell wählt die
jeweils stärkste/reichste semantische Beziehung. Aufgrund der Tatsache,
dass das Modell (Diskurswelt), welches metamodelliert wird, nicht gänzlich
klar und konsistent ist, da es nicht systematisch entworfen wurde, steht der
(Meta-)Modellierer des Öfteren vor der Entscheidung, zwischen
verschiedenen Beziehungen auswählen zu müssen. Es ist evident, dass
Beziehungen wie „ist erzeugt durch― oder „enthält― mehr Informationen
tragen, als ein Beziehungstyp mit einer Konjunktion wie „hat― oder
Beziehungstypen mit ähnlich allgemeinen Bedeutungen. Um allerdings
58
zwischen zwei semantisch angereicherten Beziehungen zu unterscheiden,
werden oft weitere Informationen benötigt und – soweit den Autoren
bekannt ist – gibt es keine Methode, mit der sich das Konstrukt „semantische
Stärke― messen und vergleichen ließe.
4 Metamodellierung von ITIL
In diesem Abschnitt wird gezeigt, wie ein Metamodell von ITIL im Sinne
der oben dargestellten Modellhierarchie und unter Anwendung der
skizzierten Prinzipien und Richtlinien konstruiert werden kann. Das
Metamodell wird unter Verwendung der ontologischen Metaisierung
abgeleitet. Die fünf ITIL-Publikationen bilden den Startpunkt des
Metamodellierungsprozesses. Das ITIL-Referenzmodell umfasst insgesamt
mehr als 1000 Seiten, was als Indikator für die Komplexität und
Schwierigkeit eines detaillierten Vergleichs zwischen ITIL mit anderen
Referenzmodellen dient. Daher kann eine Metamodellierung hier
entscheidende Vorteile bei der Nutzung von Referenzmodellen mit sich
bringen.
Der Modellierungsprozess orientiert sich an dem für das verwendete
Werkzeug vorgeschlagenem Prozessmodell (Vgl. Abbildung 2). Die
Entscheidung fiel auf das frei verfügbare Werkzeug Protégé, welches sowohl
die Modellierung von Ontologien als auch deren Visualisierung unter
Einsatz verschiedener Plug-ins erlaubt.2 Für die Visualisierung wurden
OntoView, Jambalaya und TGViz verwendet. Beim Vorgehen, um eine
Ontologie aus den einzelnen ITIL-Publikationen zu extrahieren, wurde den
Empfehlungen des Stanford Center for Medical Informatics Research gefolgt
[NM01], an dem Protégé entwickelt wird.3 Bei der konkreten Durchführung
des Modellierungsprozesses wurden einige Schritte im Sinne der obigen
Modellhierarchie modifiziert.
Abbildung 2: Prozess zur Entwicklung von Ontologien [NM01]
In dem ebenfalls von den Verfassern durchgeführten Projekt „SemGoRiCo― wird mit dem
professionellen Werkzeug K-Infinity der intelligent views GmbH gearbeitet.
3 Alternative Ansätze der Ontologieentwicklung werden in [DMN09] diskutiert und
gegenüber gestellt.
2
59
Der Entwicklungsprozess ist evolutionär und muss daher wiederholt
durchlaufen werden, um die sich schrittweise entwickelnde Ontologie zu
analysieren, zu bewerten und zu verfeinern. Letztlich kann so eine reife
Ontologie aus dem Untersuchungsgegenstand extrahieren werden. Ein
Durchlauf des Prozesses umfasst insgesamt sieben Einzelschritte.
Zu Beginn erfolgt die Definition des Zwecks, den die Ontologie erfüllen
soll, insbesondere welche Domäne die Ontologie abbilden soll sowie die
Identifikation ihrer Stakeholder. Da hier die Modellierung von ITIL erfolgt,
soll die durch dieses Referenzmodell abgedeckte Domäne des ITServicemanagements mit den entsprechenden Interessensgruppen
repräsentiert werden.
Der nächste Schritt umfasst u. a. die Recherche nach bereits existierenden
Ontologien zur spezifischen Domäne „IT-Servicemanagement―, bspw. in
einschlägiger Literatur oder Ontologiedatenbanken. An dieser Stelle lässt
sich [BW07] finden, das ein „Metamodel for IT services― enthält. Dieses
bezieht sich jedoch auf ITIL V2 und kann daher hier nur eingeschränkt
Eingang in den Modellierungsprozess finden.
Im dritten Schritt werden relevante Objekte erhoben und erfasst. D. h. es
wird danach gefragt, welche Objekte bzw. Begriffe besonders
charakteristisch für das ITIL-Referenzmodell sind und welche Eigenschaften
diese besitzen. Charakteristische Objekte, das sind die M1-Objekte im Sinne
der obigen Modellhierarchie. Diese gilt es in den ITIL-Originaldokumenten
zu identifizieren. So findet sich dort bspw. die erwähnte „Incident
Identification― neben „Incident Logging―, „Incident Categorization― etc.
Darauf aufbauend wird – im nächsten Schritt – die Definition von Klassen
vorgenommen. Die drei genannten M1-Objekte werden nun im Sinne der
Modellhierarchie zu M2-Objekten bzw. Klassen typisiert und als „Activity―
definiert. Auf dieselbe Art und Weise lassen sich u. a. die Klassen „Process―,
„Role―, „Result― usw. identifizieren. Weiter werden in diesem vierten Schritt
semantische und hierarchische Beziehungen zwischen Klassen definiert.
Grundsätzlich kann bottom-up, top-down oder combined vorgegangen
werden. In ITIL wird, bspw. aus der Vogelperspektive gesehen, die Klasse
„Objective― durch die Klassen „Business Objective―, „Activity Objective―
etc. verfeinert (siehe Taxonomy, Abbildung 3).
Im fünften Schritt müssen den Klassen Eigenschaften zugeordnet werden,
um deren Aussagekraft zu erhöhen. Hier werden den Metriken bestimmte
Eigenschaften zugeordnet, wie bspw. die Definition einer Berechnung. Zu
beachten bleibt, dass sich die Schritte vier und fünf unter Umständen stark
überschneiden können und eine Trennung nicht immer möglich ist.
60
Der sechste Schritt umfasst die Definition von Constraints, d. h. ob eine
Eigenschaft bspw. numerisch ist oder aus Zeichen besteht sowie
Kardinalitäten zwischen den Klassen. So umfasst in ITIL die Klasse Metrik
numerische Werte und eine Aktivität eine Zeichenkette. Constraints durch
Kardinalitäten bedeutet hier bspw., dass einer Klasse mehrere Metriken
zugeordnet werden können. Andersherum aber eine 1:n-Beziehung vorliegt.
Schließlich beinhaltet der letzte Schritt das Erzeugen von Instanzen für die
definierten Klassen. An dieser Stelle kann auf die Ergebnisse der BottomUp-Ableitung der Objekte aus den ITIL-Dokumenten in Schritt drei
zurückgegriffen werden. Dieser Schritt wird im Rahmen der
Metamodellierung hier nur punktuell durchgeführt, da das Ziel zunächst
darin besteht, ein Metamodell zu konstruieren, nicht aber alle ITIL-Prozesse
vollständig zu modellieren, d. h. die Ebene M1 wird zunächst nicht in
Protégé abgebildet.
Im Ergebnis liegen so definierte Klassen vor, die zum einen in einem
hierarchischen Verhältnis zueinander stehen. Das Ergebnis ist eine
Taxonomie, die in Abbildung 3 ausschnittsweise dargestellt ist.
Abbildung 3: Taxonomie der ITIL-Klassen in Protégé
Zum anderen findet sich ein semantisches Netz, welches das Metamodell auf
Ebene M2 repräsentiert. Es enthält die semantisch reichen Beziehungen
zwischen den Klassen. In Abbildung 4 ist ein großer Ausschnitt des in
Protégé abgelegten Metamodells zu sehen. Aus Gründen der Lesbarkeit sind
61
die Beziehungen nicht benannt. Abbildung 5 zeigt einen detaillierteren
Ausschnitt und stellt daher auch die Semantik der Beziehungen dar.
Abbildung 4: ITIL-Metamodell als Graph
Jeder Knoten repräsentiert eine Klasse des ITIL-Metamodells. Die Klasse
Prozess kann als die wichtigste Klasse identifiziert werden. Ein starkes Indiz
dafür bildet die Anzahl der Kanten, die an diese Klasse andocken. Dies
erscheint jedoch nicht sehr überraschend, da Prozesse im ITILReferenzmodell bspw. im Gegensatz zu Services besonders umfassend
definiert sind. Prozesse kombinieren dabei als zentrales Objekt sowohl
Ressourcen mit Rollen als sie auch Services und deren Ergebnisse
definieren.
Abbildung 5: Detaillierter Ausschnitt aus dem ITIL-Metamodell
5 Fazit
Die vorgestellte Methode zur Metaisierung von Best-PracticeReferenzemodell, die am Beispiel von ITIL vorgestellt wurde, hat eine Reihe
62
von Anwendungsmöglichkeiten und stiftet Nutzen beim Umgang mit
Referenzmodellen. Dabei werden die Modellstrukturen freigelegt, so dass
von den konkreten Ausprägungen im Modell abstrahiert wird. Dies
unterstützt die Anwendung dadurch, dass sich die Strukturen analysieren,
vergleichen und ggf. kombinieren oder integrieren lassen. Insoweit fügt die
Betrachtung auf Metaebene den in der Praxis vorzufindenden Mappings eine
weitere Sichtweise hinzu.
Weiter sind Metamodelle nötig, um Werkzeuge zur Unterstützung zu bauen.
An dieser Stelle wurde die Abbildung in einem Werkzeug zur
Repräsentation von Ontologien gezeigt. Dies dient an diesem Punkt der
Illustration
und
dem
Experimentieren.
Eine
weitergehende
Werkzeugunterstützung sollte hingegen auf stabileren Plattformen aufsetzen,
um den „Betrieb― von Referenzmodellen im Unternehmensalltag zu
gewährleisten.
Des Weiteren sollte die Methode zur Konstruktion von ontologischen
Metamodellen erweitert und validiert werden. Eine Erweiterung könnte die
Einbeziehung von Verfahren der semantischen Textanalyse (Inhaltsanalyse)
aus der qualitativen Sozialforschung oder Text-Mining-Verfahren umfassen.
Weiteren Forschungsbedarf sehen wir in der Validierung der GoMM.
Literaturverzeichnis
[AK03a] Atkinson, C.; Kühne, T.: Calling a Spade a Spade. The MDA Infrastructure, International
Workshop ―Metamodeling for MDA‖, York, November, 2003.
[AK03b] Atkinson, C.; Kühne, T.: Model-Driven Development: A Metamodeling Foundation. IEEE
Software, 20, 5, 36–41, 2003.
[Be00]
Bernhard, M.: Die IT und ihre neue Kernkompetenz – Vom Verwalter zum
serviceorientierten Dienstleister. In (Bernhard, M., Lewandowski, W., Mann, H. Hrsg.):
Service-Level-Management in der IT, Düsseldorf, Symposion Publishing, 2000, 253-262.
[BW07] Braun, C.; Winter, R.: Integration of IT service management into enterprise architecture. In
Proceedings of the 2007 ACM symposium on Applied computing, 1215-1219.
[DMN09]De Nicola, A.; Missikoff, M.; Navigli, R.: A software engineering approach to ontology
building. In Information Systems 34, 2, 2009, 258 -279.
[FS06]
Ferstl O.K.; Sinz E.J.: Grundlagen der Wirtschaftsinformatik. 5. Aufl., Oldenbourg,
München, 2006.
[GA09] Goeken, M.; Alter, S.: Towards Conceptual Metamodeling of IT Governance Frameworks.
Approach - Use – Benefits. In Proceedings of the 42nd Hawaii International Conference on
System Sciences, 2009.
[GH05] Gitzel, R.; Hildenbrand, T.: A Taxonomy of Metamodel Hierachies. Working paper,
Lehrstuhl für ABWL und Wirtschaftsinformatik, 2005.
63
[IG08]
IT Governance Institute (Ed.): IT Governance Global Status Report, unter www.isaca.org,
Abruf am 03.03.2008.
[IT08]
ITIL.org: ITIL V3-V2 Mapping, unter http://www.itil.org/de/itilv3-servicelifecycle/itilv3v2mapping.php, Abruf am 06.04.2008.
[JG07]
Johannsen, W.; Goeken, M.: Referenzmodelle für IT-Governance. dpunkt-verlag,
Heidelberg, 2007.
[KH06] Karagiannis, D.; Höfferer, P.: Metamodels in action: An overview. ICSOFT, 2006.
[KK02] Karagiannis, D.; Kühn, H.: Metamodeling Platforms. In (Min Tjoa, A.; Quirchmayer, G.
Hrsg.): Lecture Notes in Computer Science, 2455. In Proceedings of the Third International
Conference EC-Web, Springer 2002, 451–464.
[Kü06]
Kühne, T.: Matters of (Meta-) Modelling. In Journal on Software and Systems Modeling, 5,
4, 2006, 369-385.
[KW07] Kurpjuweit, S.; Winter, R.: Viewpoint based Meta Model Engineering. In (Reichert, M.;
Strecker, S.; Turowski, K. Hrsg.): Enterprise Modelling and Information Systems
Architectures - Concepts and Applications. In Proceedings of the 2nd International
Workshop on Enterprise Modelling and Information Systems Architectures, October 8-9,
2007, 143-161.
[KW08] Kurz, E.; Woltering, A.: ITK-Governance bei der Deutschen Bahn – nachhaltige ITKSteuerung im Vorstandsressort Personenverkehr. In IT-Governance, 3, 2008, S. 3-8.
[NM01] Noy, N. F.; McGuiness, D.L.: Ontology Development 101: A Guide to Creating Your First
Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and
Stanford Medical Informatics Technical Report SMI-2001-0880, 2001.
[RB96] Reich, B. H.; Benbasat, I.: Measuring the linkage between business and information
technology objectives. In MIS Quarterly, 20, 1, 1996, 75-10.
[RP00]
Rolland, C.; Prakash, N.: From conceptual modelling to requirements engineering. In Annals
of Software Engineering, 10, 2000, 151–176.
[RS03]
Rautenstrauch, C.; Schulze, T.: Informatik
Wirtschaftsinformatiker. Heidelberg, 2003.
[Sc98]
Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion
konfigurationsund anpassungsorientierter Modelle. Dissertation, Wiesbaden, 1998.
[SR98]
Schütte, R.; Rotthowe, T.: The Guidelines of Modeling - an approach to enhance the quality
in information models. In (Ling, T.W., Ram, S., Lee, M. L. Hrsg.): Conceptual Modeling –
ER 98. Singapore, 16.-19.11.1998, 240-254.
[St96]
Strahringer, S.: Metamodellierung als Instrument des Methodenvergleichs. Shaker, Aachen,
1996.
[Ta06]
Taylor, S.: ITIL Version 3. Presentation at itSMF-USA, Salt Lake City, 9-23-2006.
für
Wirtschaftswissenschaftler
und
[VHW91]Verhoef, T. F.; Hofstede, A. H. M. T.; Wijers, G. M.: Structuring Modelling Knowledge for
CASE Shells. In (Andersen, R. et al. Hrsg.): Proceedings of the third international
Conference CAiSE‘91 on Advanced Information Systems Engineering, 502-524.
64
Fachbeitrag 3:
Towards Conceptual Metamodeling of IT Governance Frameworks Approach Use – Benefits.
Titel: Towards Conceptual Metamodeling of IT Governance Frameworks Approach Use – Benefits
Sciences (HICSS 2009), Big Island, Hawaii, USA, 05.-08.01.2009.
65
Towards Conceptual Metamodeling of
IT Governance Frameworks
Approach - Use – Benefits
Matthias Goeken
Frankfurt School of Finance and Managament
m.goeken@frankfurt-school.de
Abstract
Up to now, there has been little academic support
for the challenges of IT governance/IT management.
As a reaction, various best practice frameworks - like
COBIT or CMMI - were developed. Due to their
origin, these frameworks lack of a sound basis or
scientific foundation. To undertake a step in this
direction, we propose the use of modeling notation and
techniques to represent frameworks as conceptual
metamodels. Accordingly, we present the well-known
framework COBIT metamodeled in a conceptual way
and, thereby, represent the underlying logically and
semantically rich structures. We furthermore discuss
the benefits of using conceptual metamodeling to
analyze frameworks coming from practice. Using the
metamodel, we are also able to demonstrate ways to
improve the frameworks and configure them according
to the specific needs of an enterprise or an industry. To
have a sound basis for any improvement we discuss the
process of metamodeling and derive some requirements for “good” metamodeling.
1. Introduction
While there is little guidance for the management
of IT in general and for specific challenges like
business/IT alignment or risk management in particular
[1, 5], the majority of computer science research deals
with system development and related issues. To offer
guidance for management tasks and governance
challenges seems critical because in enterprises,
usually a higher percentage of expenditure is spent on
‘running IT‘ rather than systems engineering and
development of new systems.
Due to the fact that there is a clear need for
methodological support for current tasks and
challenges of IT management and IT governance, it is
surprising, that little attention is paid to these
questions. [8] and [34] censured researchers for the
lack of effort put into evaluating e. g. how business and
IT can be properly aligned, how IT related risks can be
Stefanie Alter
Frankfurt School of Finance and Managament
s.alter@frankfurt-school.de
managed and how IT can contribute to the overall
value of the enterprise.
In recent years, there were some associations and
public institutions like ISACA (Information Systems
Audit and Control Association) and CCTA (Central
Computer and Telecommunication Agency) /OGC
(British Office of Government Commerce) that
developed frameworks (e.g. COBIT and ITIL) to
support management and governance of IT. These
frameworks are well established in practice [16, 24].
However, there is a lack of theoretical foundation,
from an academic viewpoint.
This paper undertakes steps towards the theoretical
foundation of best practice frameworks by proposing to
model them as conceptual metamodels. We will show
that this theoretical foundation gives rise to various
benefits and improvements also useful for
practitioners. After that we introduce some bestpractice frameworks especially the COBIT framework.
In section 3 we discuss IT governance framework
COBIT as conceptual metamodels. Therefore, we
discuss the concepts ‗model‘ and ‗metamodel‘ as well
as their relationship, and take a look on how
metamodels need to be understood from a linguistic
and an ontological point of view. Hereafter we present
a metamodel of COBIT, the popular IT governance
framework of the ISACA. Further, we discuss the
advantages and the application of this metamodel
(section 4) and show some research in progress.
2. IT Governance Frameworks
As mentioned in the introduction, science offers
little guidance to IT management and IT governance
issues. Therefore, in the last ten years a range of open
best practice models (IT Infrastructure Library (ITIL)
[31], Control Objectives for IT and related technology
(COBIT) [17], Capability Maturity Model Integration
(CMMI) [41]) as well as proprietary models were
developed (Microsoft Operations Framework, ITService-Management of Hewlett-Packard, or the IBM
IT Process Model).
66
These best practice models which are also
subsumed under the developing topic ―IT governance‖
describe goals, processes and organizational aspects of
IT management and control [14, 18]. They are created
in practice and are given to use in practice. One point
regarding the development of best practice models is
very interesting: practitioners from the business world
consolidate their knowledge aiming to define generally
accepted rules, processes, and characteristics. Despite
the fact that scientists also participate in the
development of already mentioned frameworks such as
COBIT or CMMI, especially practitioners are members
of the relevant committees and boards.
From an academic point of view, these best practice
models can be seen as an interesting object of research,
not only because the models are widely spread in
practice but also because they incorporate a huge
amount of consolidated knowledge. As mentioned
before, a sound scientific discussion and foundation of
these models is missing but could be fruitful.
The Capability Maturity Model Integration
(CMMI) published from the Software Engineering
Institute (SEI) is a process improvement approach that
provides organizations with the essential elements of
effective processes. It can be used to guide process
improvement across a project, a division, or an entire
organization. CMMI helps integrate traditionally
separate organizational functions, set process
improvement goals and priorities, provide guidance for
quality processes, and provide a point of reference for
appraising current processes [22, 41].
In the following we focus on COBIT (Control
Objectives for Information and Related Technology)
[17]. Mainly, there were two reasons to start with the
conceptual metamodeling of the COBIT framework.
First of all, this framework is well structured in
domains, processes and other components and,
therefore, closed in itself and self-contained. Secondly,
COBIT is holistic and represents (nearly) all tasks and
processes an IT organization should carry out. For
example, ITIL is – like COBIT – holistic, but has a
lack of structure. On the other hand, e.g. CMMI [41]
focuses on a specific task (i.e. development), but has a
coherent structure.
COBIT describes a generic process model, that
defines relevant processes and activities which one
should find – according to the idea of best practice – in
an IT department or organization. Whereas earlier
versions put the main focus on IT audits, the COBIT
framework meanwhile developed to a full-blown
support of IT management covering most relevant
tasks and areas of this topic.
In a macro-perspective the IT processes are
arranged by grouping them into four so called domains,
which are structured following the well known
Deming/life cycle (Plan, Do, Check, Act). For each of
the 34 IT processes various components, such as
business requirements, IT goals, controls and metrics
as well as activities, resources, responsibilities and so
on are defined. Furthermore, there are other
components and specifications defined for each
process, e.g. the roles that should be informed, should
be consulted and so on. The ―deep structure‖ of
COBIT will be discussed in more detail in chapter 3,
especially in section 3.3.
3. IT Governance Frameworks as
Conceptual Models
3.1
Model and Metamodel
In IS research we use models as design artifacts
[15] to abstract from reality and real world objects. The
representation as a model is usually the first step of
developing an application or software system, because,
according to Lehman, ―any program is a model of a
model within a theory of a model of an abstraction of
some portion of the world or of some universe of
discourse‖ [27]. Our purpose is to strengthen the
theoretical foundation by applying modeling to IT
governance frameworks.
If the objects of research are models, and not the
real world or the universe of discourse (UoD), we
create models of models. Usually a ―model of a
model‖, which is a higher level abstraction, is called
metamodel. Going from the instance level (real world,
UoD), consisting of instances (M0) to the model level
(M1) and further to the metamodel level (M2) means
the application of abstraction mechanisms (fig. 1).
[44] takes a systematic look at how these
hierarchies are constructed and coins the term
―metaization principle‖ for the operation that can
repeatedly be applied. She points out, that there are
different ways to come from real world instances to
models and also from models to metamodels and so
forth (see also [25]).
The metaization principle defines the primary
abstraction mechanism for structuring the objects of
the lower level. In other words, it specifies the relevant
building blocks (phenomenon) the world consists of
according the principle or viewpoint.
The metaization principle most often used in
information systems is the ―linguistic metamodeling‖:
For example, when using Chen‘s E/R-Model-Syntax
(M2) to represent a part of the real world (M0), on
model level (M1) we can only use entities,
relationships and attributes as relevant building blocks.
Therefore, the level Mx makes us to structure the
objects on Mx-2 in accordance to its predefined
67
building blocks (e.g. an ‗order‘ can only be an entity or
a relationship (relating ‗product‘ and ‗customer‘) or an
attribute (which is unlikely)).
The representation of the object is matter of the so
called concrete syntax which defines the assignment of
symbols to a representation. The representation, e.g.
the shape of the symbols used, is called notation. A
modeling language usually has one abstract syntax,
which is the result of linguistic metaization, but may
have several notations (e.g. see the manifold of E/Rmodel notations).
M3 Level
Meta-metamodel
entity
represents
model component
linguistic metaization
M2 Level
Metamodel
ontological metaization
semi-structured
natural language
(form-like)
activity
linguistic metaization
ontological metaization
detect and record
incidents
M1 Level
Model
(in DS 08 - Manage
Service Desk and
Incidents)
instance
of
M0 Level
Instance
Service desk process
ticket # 2009-42
Fig. 1 Ontological and linguistic metamodeling
It is necessary to stress that linguistic
metamodeling is not the only way to perform
metamodeling, because various mechanisms of
abstraction can be used for different purposes and
applications. [20, 21] e. g. emphasis the ‗ontological
metamodeling‘. Other researchers also work on
‗physical metamodeling‘ [2, 10]. For our purpose, the
ontological metamodeling is of primary importance. In
contrast to linguistic metamodeling, the ontological
metamodels deal with the classification of model
elements according to their content [2, 3]. By
ontological metamodeling we define metatypes on MX,
which describe what concepts exist on MX-1 as well as
their properties. Applying this kind of metamodeling
might result in denoting M1 object ‗order‘ as a ‗sales
object‘ on M2, and ‗customer‘ as ‗business partner‘
(together with supplier).
The differences between ontological and linguistic
metamodeling are illustrated in figure 1, which also
illustrates our approach. On M0 there is a concrete
activity within an IT process (a specific help desk
process, ticket # 2009-42). The activities performed are
instances of the COBIT activities ―detect and record
incidents‖ within ―DS 08‖. In COBIT the definition of
processes and their activities are in natural language
but semi structured in a form-like manner (in contrast,
ITIL processes are described more narrative (prose)),
but it contains some process diagrams. Referring to the
ontological metaization, ―detect and record incidents‖
can be classified as an ―activity‖ on metamodel level.
This ontological metaization from M1 (where COBIT
resides) to the meta level M2 (where our model
resides) is the nucleus of our approach and the
modeling activities, described in the following chapter.
In addition to the identification of components like
―activity‖ we further model the relationships between
the identified components. This, for example, reveals,
that an activity is always related to a role.
In order to model some portion of the world (which
might be a model), one needs a language as well as a
method with procedures, which supports the
identification and representation of relevant objects.
The language is often considered as the ―way of
modeling‖, the procedures as the ―way of working‖
[45]. In information systems research, the emphasis is
usually on the way of modeling, the language/notation,
and not much attention is directed towards the problem
of filling the models, that is, instantiating the model
with the knowledge of the UoD. Brinkkemper [7] adds
the ―way of thinking‖, which refers to directions, rules,
principles and guidelines, that are used in the modeling
process. In the following, we focus on the way of
thinking by discussing guidelines and principles for
metamodeling. From our point of view, this is a
prerequisite for defining ways of working. The latter is
not addressed in this paper, but it is an area of future
research.
As metamodels represent the ―deep structures‖ of a
model, the language (way of modeling) used to
formulate the model must be able to represent the
concepts of the model in an appropriate way. Here, a
dialect of the E/R-approach, the extended E/R-model,
eERM) will be used [36]. This means, we focus on the
static aspects of the framework and are not able to
capture e.g. information flows directly. In fig. 1 the
language is depicted because our model is a linguistic
instantiation of the M3 Metamodel.
68
3.2
Guidelines of Metamodeling
In computer science and information systems
various modeling languages have been developed but
only in the recent past the researchers discuss how the
domain knowledge could be transferred into the
models. To fill this lack some researchers propose requirements engineering and a kind of stepwise method
of metamodeling [26], others believe that describing a
metamodel in an epistemological way has to be the
first step in any research activity including a metamodel [38]. We agree both and believe further that a highquality metamodel is a sound basis for the following
steps in research [30]. Hence, we derive some guidelines of ‗good‘ metamodeling in the following.
Because the metamodel is defined as ‗a model of a
model‘ the so called guidelines of modeling probably
can be applied on metamodels as well. [37, 38] propose
six principles to raise the quality of information
modeling. These principles are:
(1) Principle of construction adequacy
(2) Principle of language adequacy
(3) Principle of economic efficiency
(4) Principle of clarity
(5) Principle of systematic design
(6) Principle of comparability
Principle of construction adequacy means a
consensus according to the represented problem and
about the type of construction. But it does not cover the
interrelation between models of different types. This
principle requires a pragmatic way thinking and
modeling and a purpose orientation. The construction
of a model should be adequate to problem and purpose.
Principle of language adequacy means that the
chosen language fits the purpose of the model. For our
research we choose the eERM to metamodel COBIT.
We use the metamodel to compare, map and integrate
different frameworks because of their components but
not their behavior or dynamic structure. Therefore,
eERM is an adequate language because we would not
model behavioral aspects of COBIT. This principle
also includes completeness and consistency between
the model and the metamodel of the chosen language.
That means that a model does not include any symbols
or items which are not specified in the metamodel. In
the context of metamodeling we probably need an
extension of the eERM notation according to
integration and mapping of frameworks.
The principle of economic efficiency formulates the
economic restrictions every activity in an economic
institution is exposed to. There is no need for changes
or extensions in a metamodeling approach.
The principles of clarity and systematic design
deals with the comprehensibility of the model design.
Systematic design requires inter-model consistency.
These principles are important for the integration of
frameworks by using metamodels. For instance, the
principle of systematic design demands a
comprehensive metamodel that includes all
components of the frameworks, which should be
integrated.
In addition the principle of comparability is one of
the major principles in a metamodel environment.
Metamodels are often used to compare and integrate
models on an abstract level. Therefore, comparability
is a critical point if metamodels are focused.
With some restrictions these six principles could
also be used for metamodeling. One reservation is that
the guidelines of modeling often use the comparison
with the reality. However dealing with metamodels
implies that models are the basis of modeling. So it is
unfeasible to validate the semantics of the metamodel
against the reality. But within these restrictions it could
be a first conclusion that the guidelines of modeling
could also be used for metamodeling, because the
metamodel is also ‗just‘ a model.
In our opinion there has to be an extension to these
six principles in order to use them for metamodeling
purposes.
To come from model to metamodel the modeler
chooses a way of abstraction (see section 3.1). This
principle of metaization, for instance the ontological or
the linguistic metaization, has intense consequences for
the metamodel (see the following sections). Especially
the ontological metamodeling which we use in our
metamodel requires many decisions from the modeler.
The user of the metamodel needs the information,
which principle of metaization the modeler has used
for the metamodel. As a result the first guideline of
metamodeling should be: A metamodel has to reveal its
principle of metaization.
We will use our metamodel for the combination
and integration of different frameworks. Due to this
field of application, the different users and the high
level of abstraction the metamodel needs a clear
mapping between the ‗universe of discourse‘ and the
words and symbols which will describe it ([9], [33]).
That means that the linguistic defects like synonyms
and homonyms are minimized or removed. The
following example shows the relevance for
metamodeling: Many IT governance frameworks are
using the component goal. But each framework got its
own definition of what goal means. Here we see items
with the same name but with different meanings. But if
we compare the generic goals of the CMMI standard
with the control objectives of the COBIT standard we
will find out that they have got almost the same
meaning but a completely different concept. The
second guideline for metamodeling should be the clear
69
mapping between a concept and its meaning in the
scope of the metamodel.
By metamodeling existing frameworks the
difficulty is that the differences between notion and
connotation are part of the model. In the following we
present at first a descriptive metamodel of the COBIT
framework. After that we will discuss the effect of the
differences between notion und connotations on the
possible integration with other frameworks. The
importance of this guideline increases when the
metamodel is used by different users or different
models should be integrated.
As guideline three we propose the use of semantically rich connections (the concept depends on the
chosen language; in this paper we use eERM- that
means semantically rich relationship types). Due to the
fact, that the model (UoD) we (meta-)model in the
following is not all over clear, consistent and
systematically designed we often had to choose among
several relationships between two entities. It is evident
that a relationship type like „is created by‟ or
‗contains‟ includes more information than a
relationship type with a conjunction of ‗have‟ or with
other elementary relationship types (For instance the
relationship type „P-MM‟ between the entities
processarea and maturity model in fig 3.). But to
differentiate between two semantically richer
relationships we often need further information.
To summarize this section we could say that the
well known guidelines of modeling could apply on
metamodels if we pay attention to some restrictions.
Besides these six principles a metamodel should
observe the following guidelines:
 A metamodel reveals its principles of metaization.
 A metamodel has an unambiguous mapping
between the universe of discourse and the words
and symbols which name and describe it.
 A metamodel has semantically rich connections.
3.3
Metamodeling the Best Practice
Framework COBIT
In this chapter we present a metamodel of COBIT,
which is developed in more detail in [12, 13] and show
how frameworks of IT governance can be modeled
considering the aforementioned principles and guidelines. Furthermore we extract the main benefits of
metamodeling. Mainly, there were two reasons to start
with the descriptive metamodeling of the COBIT
framework. As mentioned before COBIT is well
structured in processes and other repetitive components
and, therefore, closed in itself and self-contained.
Secondly, COBIT is holistic and represents (nearly) all
tasks and processes an IT organization should carry
out. However, these existing structures primarily serve
the purpose to present the framework consistently and
structured. The COBIT manual supports the navigation
and the usage of the framework but may not be mixed
up with a metamodel. A decisive difference between
the manual and a metamodel is the goal of metamodeling to extract and present the underlying logical and
semantically rich relationships (see guideline 3).
In COBIT 34 IT processes are presented which
produce one or more outputs which vice versa are used
as inputs in other processes. Input and output are
results. According to this, the entity type result ‗isa‘
output or input of a process (see fig. 2). Typical results
on instance level are documents like reports on costs,
risks or plans on IT strategy.
Moreover, a process consists of control objectives
which are statements of desired results or purposes to
be achieved by implementing control procedures in a
particular process. These control procedures should
provide ‗reasonable assurance‘, that business
objectives will be achieved. Furthermore, a process
includes activities, which give a detailed description of
what is done. These activities are carried out by
specific persons like the CFO, the CIO, or an architect.
Therefore, we link activities to the concept role (see
also section 4).
Each process of the framework has goals, which
can be divided into business goals, IT goals, process
goals and activity goals. The goals again are in
relationship with each other. Thus, IT goals activate
process goals, which in turn end up in activity goals
(e.g. IT goals define what the business expects from
IT; Process goals define what the IT process must
deliver to support IT‘s objectives and so on). Each goal
is measured with the aid of different metrics (key goal
indicators and key performance indicators).
Furthermore, a process contains information criteria,
which are abstract business goals. The information
criteria proposed by COBIT are effectiveness,
efficiency, confidentiality, availability, compliance and
reliability. For every process COBIT states if these
criteria are supported. It is distinguished between a
primary and a secondary relationship.
Goals as well as metrics usually are neither
considered as components in method descriptions [6]
nor in the widespread modeling notations like EPC
((Event-driven Process Chain) or BPMN (Business
Process Modeling Notation) [23 extended performance
measures into BMPN].
From an IT governance point of view, goals and
metrics are of high importance because in order to
control, govern and manage, you have to quantify the
relevant facts (―You cannot manage without
measuring‖).Each process is assigned to one of four
70
domains, which are arranged according to the life
cycle. Further components of COBIT are a maturity
model, domains and IT resources. Each process can be
assessed by a maturity model to determine its level of
maturation. This is the starting point for a continuous
process improvement of the process maturity and its
controls. In order to achieve any results, a process
needs the entity type IT resource.
Furthermore, each process supports a specific IT
governance focus area. These IT governance focus
areas describe the topics that executive management
needs to address to govern IT within their enterprises‘
[17]. For each process there is an indication if it
addresses the focus area. Like above it is distinguished
between a primary and a secondary relationship.
Implicit components as the life cycle orientation of
COBIT could enter the metamodel as principles.
However, a principle can not be dedicated to a single
entity type. Implicit basic principles form the
framework as a whole and thus have to be put in
another level of the metamodel.
Finally, each process has the attributes process code
and process description. The process code is a unique
identifier of the process. It consists of the abbreviation
of the domain and a number. Figure 2 shows our
ontological metamodel of COBIT. (For further
information to the model see [12, 13])
In the following we present and discuss how our
approach fulfills the principles of modeling and the
proposed guidelines.
To fulfill the principle of construction adequacy (1)
we had to find a consensus according to the represented problem and about the type of construction. The
construction of our metamodel should be adequate to
problem and purpose. Firstly we will use the metamodel to clarify the components of IT governance
frameworks and after that we use the metamodels to
compare and integrate different frameworks. We find a
consensus that the represented problems are the components of IT governance frameworks and their underlying structure. That is the reason why we use conceptual metamodels as the type of construction.
To fulfill the principle of language adequacy (2)
for our metamodel, we use the well known extended
E/R notation (eERM) to represent our version of the
COBIT metamodel. We only used elements which are
part of this notation and structured the model in a clear
and schematic way. The chosen language fits with the
purpose of our metamodel. For instance eERM – like
our metamodel – has no dynamic components. The
principle also includes completeness and consistency
between the model and the metamodel of the chosen
language. We fulfill this principle because we do not
include any symbol or items which are not specified in
the eERM metamodel. But for using our metamodel in
the context of mapping and integration we might need
an extension of the eERM notation.
The principles (4) und (5) claim clarity and systematic design. We conform to them by using a clear
structural guideline for arranging the components of
the metamodel. Furthermore, we regulated the layout.
The principle of comparability (6) will be critical if
it is applied to metamodels which are used for mapping
and integration of different IT governance frameworks
(see section 4).
The proposed new guidelines of metamodeling are
fulfilled in the following way:
Guideline 1: A metamodel reveals its principles of
metaization.
Our metamodel is an ontological metamodel. The
linguistic metamodel of COBIT would describe the
design of the standard. A linguistic metamodel of
COBIT would describe that each process is presented
on four pages, including a RACI chart on the middle of
page three which has twelve columns and so on. Our
ontological metamodel demands a socialization and an
educational background within the ontology of IT
management. Therefore, it is important for the
metamodel user to know which way of metaization
was used. To follow guideline 1 we have to reveal the
metaization principle we used. We reveal that our
metamodel is an ontological one by naming the figure.
There might be other ways to show the principle of
metaization but to use the caption seems to be
pragmatic and sufficient.
Guideline 2: A metamodel has an unambiguous
mapping between the universe of discourse and the
words and symbols which name and describe it.
We use the COBIT notion for our metamodel. The
concepts of the model are used likewise for the
metamodel. The user of the COBIT framework has
some commitment to the COBIT ―language‖.
Guideline 3: A metamodel has semantically rich
connections.
We did not use any simple relationship types to
connect the entities. If we had the choice between two
or more opportunities we use the semantically richest
relationship type to describe the connection between
the entities. We use the relationship type activity-role
in figure 3 only to illustrate the differences.
Additionally we drop the component "management
guideline" which, therefore, is not part of our metamodel. In the COBIT framework, the "management
guideline" denotes page three of the IT process
description, but in our opinion, is only a structural
component and not semantically rich - which is
claimed by guideline 3.
71
Role
(1,*)
(1,*)
executes
Control
Objective
Activity
(1,*)
(1,1)
Output
is
contained
in
is
contained
in
isa
is used by
(1,1)
(0,*)
(0,*)
(1,*)
(1,1)
Result
(1,*)
(1,*)
(1,*)
supports
(1,*)
isa
(1,5)
IT Governance
Focus Area
Goal
(1,*)
Activity Goal
is
measured
by
belongs to
(1,1)
(1,4)
IT-Resource
Domain
adresses
(1,7)
Information
Criteria
has
(1,1) Maturity Level
(1,*)
IT Goal
Process Goal
uses /
needs
(1,*)
(0,*)
supports
Control Practice
(1,1)
Process
is created
by
(1,*)
(1,*)
(0,*)
Input
is
contained
in
is
determined
by
(1,1)
(1,*)
Metric
Maturity Model
Fig. 2 Ontological metamodel of COBIT
The principles of modeling and the proposed
guidelines for metamodeling support and promote the
quality of (meta) models. [29] describe further
influencing factors of quality in conceptual models.
The examination had shown that our metamodel fulfills
the principles of modeling and the recommended
extensions. In the following section we describe
application and usage of our approach.
4. Applications and Usage of IT
Governance Frameworks as Conceptual
Metamodels
We assume that several advantages accrue from
representing IT governance frameworks like COBIT,
ITIL or CMMI as conceptual metamodels, and that
metamodels can be a helpful support for analysis and
further advancement in the research on IT governance
frameworks. In the following we will discuss some of
the resulting benefits and possible applications.
First, the representation allows the comparison of
different frameworks on an abstract level. Once the
components are extracted, frameworks can be
examined and analyzed. Thus, other frameworks can
be checked for completeness with the aid of the
metamodel. Accordingly, one can deduce that ITIL –
in contrast to COBIT - does not provide metrics and
other components for assessment to the extent COBIT
does. Another benefit of this approach is that the
quality of a metamodel is verifiable by the extent of
fulfilling the guidelines of metamodeling. This
metamodel might be a sound basis for an improvement
of the framework. An analysis of the presented
metamodel of COBIT may e.g. raise questions like:
 Why are activities related to a role, while
control objectives are not assigned to a role or
a person?
 Why are results not measured by metrics?
 Why are activities and control objectives not
directly related?
The following example shows one possibility to
improve the framework. The items activity and control
objective are components of the COBIT framework.
Both are related to Process but are not related to one
another. The control objectives have many substantial
overlappings with activities which complicate using
the framework. The overlapping between control
Objectives and activities can be eliminated by dropping
the relationship between activity and process as shown
in figure 3.
Another example could be the component role. The
unmodified COBIT framework (Fig. 3) could not
support any complex structures of responsibilities. In
reality it might be necessary that the responsibility for
72
an activity is strictly separated from its supervision or
from another activity e.g. cause of a trade-off.
Simonsson and Johnson [39, 40] present another
possibility to use and improve the IT governance
framework COBIT. They show that COBIT does not
support most needs of previously identified concerns of
literature and practitioners, because it lacks in
providing information on how COBIT should be
implemented. Their IT organization modeling and
assessment tool (ITOMAT) firstly includes a modeling
language which provides ―a descriptive representation
of how IT is governed within the assessed company‖
and secondly an analysis framework which ―provides
support for the evaluation of whether the given IT
governance structure is good or bad.‖ [39, p. 3]
Role
Process
contains
Activity
ActivityRole
Control Objective
translated in
has
is
specified
by
Category
Policy/Guideline
Fig. 3 Control objectives, activity and role
Another benefit of the metamodel is the integration
of new or existing processes in the COBIT framework.
The metamodel prescribes the relevant components
which should be implemented in order to fulfill new
tasks of IT management on a solid basis. This becomes
apparent in the following example: The area
outsourcing is hardly represented in the COBIT
framework. However, outsourcing is an essential
component of their IT strategy for some companies.
With the aid of the metamodel a ‗Control of the
outsourcing‘-process can be developed under guidance.
In order to develop this process, the metamodel has to
be instantiated. In addition, the integration of the
process into other existing IT processes can occur for
example by linking the results of the new process to
existing processes (input-output-relationships between
processes).
When inputs flow to the process and the output is
used elsewhere, the new process becomes part of the
overall IT process landscape. One step further could be
the metamodel based fusion of frameworks like
COBIT, ITIL and CMMI. This might be of importance
if one framework covers aspects, which are missing in
another one. E.g. the new developments of the SEI
(CMMI for Services; CMMI for Acquisition) can be a
complement for COBIT, as acquisition, like
outsourcing, is not covered adequately by COBIT. A
metamodel based integration will allow a closer fit and
can guide the models amalgamation on lower level.
CMMI is commonly perceived as a maturity model.
COBIT includes a maturity model as well. Eyeballing
this component might be a point of departure for
mapping the frameworks. But after taking a deeper
look at the metamodels it becomes understandable, that
the CMMI standard includes components like goals or
procedures which are not a part of the maturity model
of COBIT. This shows the difficulties caused by
linguistic defects (homonyms, synonyms, antonyms)
and underlines the advantages of integration by using
metamodels.
To deal with this problem, we hope to gain from
database research, namely from schema integration.
Conrad notes that the ―essential task in integrating
heterogeneous data sources is the construction of a
common and uniform description of the integrated
data‖. As schema integration is a method to develop a
reconciled representation of multiple schemas, we hope
to adopt essential ideas to the challenge of integrating
governance frameworks while using their metamodels.
The core problems in schema integration are [35]:
schema matching, i.e. the identification of
correspondences between schema objects, and schema
merging, i.e. the creation of a unified schema based on
the identified mappings. The first problem refers to the
problem of identifying homonyms, synonyms,
antonyms. The second is how to deal with the
identified correspondences. Literature suggests various
strategies [4, 28].
Another strategy for the discussed topic of
governance frameworks might be the development of a
generic metamodel, into which the frameworks like
COBIT, ITIL or company specific models can be
―plugged in‖.
[11] uses the schema integration taxonomy of
Spaccapietra et al. ([42, 43 and 32]) which gain
currency in database research. This taxonomy might be
a possibility to clarify the conflicts between metamodels of different IT governance frameworks.
The findings from these researchers might be an
enrichment of our research. An example is the need for
keeping the integrated schema to a minimum. That
means that redundant model fragments should not be
part of the integrated schema again. In addition these
findings fulfill the principle of economic efficiency, of
clarity and of systematic design
73
Another corresponding research could be the
Viewpoint based Meta Model Engineering. [26]
present an approach for method engineering applied on
work systems engineering. They presented five steps to
an integrated metamodel which is made up of different
metamodel fragments. These fragments are viewpoint
based and designed and validated by the requirements
of each viewpoint. The relationships between the
viewpoints are mapped in a ‗viewpoint relationship
diagram‘. To transfer these five steps to the integration
of metamodels of IT governance frameworks might be
a further step for a systematic combination of different
best practice framework.
5. Conclusions and Future Research
In this paper we discussed and presented a way to
represent the popular IT governance framework
COBIT as a conceptual metamodel. From our point of
view, it is possible and fruitful to interpret IT
governance frameworks as metamodels. IT governance
models can learn from a rigid formalization and a
systematic approach. The intention was to demonstrate
that metamodeling is a useful technique to gain a
theoretical foundation on the one hand, and to analyze,
compare, and integrate them on the other.
In the article, we extracted the relevant components
performing some kind of ‗framework re-engineering‘
on COBIT.
The resulting metamodel brings some benefits for
comparing and integrating different frameworks.
Furthermore, frameworks can be checked for
completeness against the model.
Besides, the metamodel can be the starting point for
the representation of COBIT in an application system.
The components and the logical and semantic
relationships are necessary, e.g. for the implementation
in a semantic network. We are currently developing a
framework representation with this technology which
allows the flexible navigation within framework
structures and the implementation of various views
over the components. In this respect, other approaches
like [19] choose a process oriented viewpoint. Using
the semantic networks, we prefer a knowledge oriented
approach which might be a helpful contribution.
Another interesting area for further research could
be the situation specific and enterprise specific adaptation and configuration of governance models, because frameworks like COBIT, ITIL or CMMI are seldom
implemented completely and without modification.
Metamodeling can be the starting point for a
methodological support for model adaptation. In
further research, the metamodel presented should be
made configurable by introducing and modeling
variability on the instance as well as on the metamodel
level.
6. References
[1] Avison, D., Jones, J., Powell, P. and Wilson, D., Using
and Validating the Strategic Alignment Model. In Journal of
Strategic Information Systems, 13 (3), (2004), pp. 223-246.
[2] Atkinson, C., and Kühne, T., Model-Driven Development: A Metamodeling Foundation, IEEE Software, vol. 20,
no. 5, (2003), pp. 36–41.
[3] Atkinson, C., and Kühne, T., Calling a Spade a Spade- in
the
MDA
Infrastructure,
International
Workshop
―Metamodeling for MDA‖, York, November (2003).
[4] Batini ,C., Lenzerini, M., and Navathe, S.B., A
Comparative analysis of methodologies for database schema
integration. In ACM Computing Surveys 18, 4, (1986), pp.
323-364.
[5] Booth, M, E., and Philip, G., Information Systems
Management: Role of planning, alignment and managerial
responsibilities. In Behaviour and Information Technology
vol.24 no.5., (2005).
[6] Braun, C., Wortmann, F., Hafner, M., and Winter, R.,
Method construction - a core approach to organizational
engineering, (2005), pp. 1295-1299.
[7] Brinkkemper, S.: Method engineering: engineering of
information systems development methods and tools. In:
Information and Software Technology 38 (1996), pp. 275280.
[8] Chan, Y. E., Huff, S. L., Barclay, D. W., and Copeland,
D. G., Business Strategy Orientation, Information Systems
Orientation and Strategic Alignment. In Information Systems
Research 8, (1997).
[9] Ferstl O.K., and Sinz E.J., Grundlagen der
Wirtschaftsinformatik. 5. überarb. und erw. Aufl.,
Oldenbourg-Verlag, München, (2006). [in german]
[10]
Gitzel, R., and Hildenbrand, T., A Taxonomy of
Metamodel Hierachies, Working papers / Lehrstuhl für
ABWL und Wirtschaftsinformatik; 2005,02.
[11]
Goeken, M., Entwicklung von Data-WarehouseSystemen.
Anforderungsmanagement,
Modellierung,
Implementierung. Wiesbaden, (2006). [in german]
[12]
Goeken, M.; Alter, S., Representing IT Governance
Frameworks as Metamodels, in: Proceedings of the 2008
International Conference on e-Learning, e-Business,
Enterprise Information Systems, and e-Government
(EEE‘08), World Congress in Computer Science
(Worldcomp‘08), July 14-17, Las Vegas Nevada 2008.
[13]
Goeken, M.; Alter, S., IT Governance Frameworks
as Methods, in: Proceedings of the 10th International
Conference on Enterprise Information Systems (ICEIS
2008), June 12-16, Barcelona, Spain 2008.
[14]
Grembergen, W.V., De Haes, S., and Guldentop,
E., Structures, Processes and relational Mechanisms for ITGovernance, Idea Group, o.O. (2004).
[15]
Hevner, A. R., March, S. T., Park, J., and Ram, S.,
Design Science in IS Research. In MIS-Quarterly 28 1,
(2004), pp. 75-105.
74
[16]
IT Governance Institute, ―IT Governance Global
Status Report‖, (2006), Under: www.isaca.org, at March 3rd
of 2007.
[17]
IT Governance Institute, COBIT 4.1, o.O. (2007)
[18]
Johannsen, W., and Goeken, M.: Referenzmodelle
für IT-Governance, Heidelberg, (2007).
[19]
Karagiannis, D., A Business Process-Based
Modelling Extension for Regulatory Compliance. Paper for
MKWI 2008, Track: IT-Risikomanagement, IT-Projekte und
IT-Compliance, München, Feb (2008).
[20]
Karagiannis, D., and Kühn, H., Metamodeling
Platforms. In A. Min Tjoa, & G. Quirchmayer (Eds.), Lecture
Notes in Computer Science: Vol. 2455. Proceedings of the
Third International Conference EC-Web, Springer (2002),
pp. 451–464.
[21]
Karagiannis, D. and Höfferer, P., Metamodels in
action: An overview. ICSOFT (1) (2006).
[22]
Kneuper, R., CMMI, dpunktVerlag, Heidelberg
(2007). [in german]
[23]
Korherr, B., and List, B., Extending the EPC and
the BPMN with Business Process Goals and Performance
Measures. In: Filipe, J. et al. (Hrsg.): Proceedings of the 9th
International Conference on Enterprise Information Systems,,
June 2007 Funchal/Portugal.
[24]
KPMG: Summary of KPMG IS Governance
Survey. KPMG LLP, London, (2004).
[25]
Kühne, T., Matters of (Meta-) Modelling, In
Journal on Software and Systems Modeling, Volume 5,
Number 4, (2006), pp. 369-385.
[26]
Kurpjuweit, S., and Winter, R., Viewpoint based
Meta Model Engineering. EMISA 2007, pp 143-161, In
Manfred Reichert, Stefan Strecker, Klaus Turowski (Eds.):
Enterprise Modelling and Information Systems Architectures
- Concepts and Applications , Proceedings of the 2nd
International Workshop on Enterprise Modelling and
Information Systems Architectures), October 8-9, 2007. LNI
P-119 GI (2007).
[27]
Lehman, M. M., Programs, Life Cycles and Laws
of Software Evolution. In: Proc. IEEE Spec. Issue on
Software Engineering, v. 68, n. 9, (1980), pp. 1060-1076.
[28]
Leite,J.C.S.P. and Franco A.P.M., A strategy for
conceptual model acquisition. In IEEE international
symposium on requirements engineering. IEEE Computer
Society Press, Los Alamitos, CA, (1993), pp 243-246.
[29]
Lindland, O.I., Sindre, G., and Solvberg, A.,
Understanding Quality in conceptual model, IEEE Software,
vol. 11, 1994, pp. 42-49.
[30]
Moody, D.L., Theoretical and practical issues in
evaluating the quality of conceptual models: current state and
future directions, In Data & Knowledge Engineering 55
(2005) , pp. 243–276.
[31]
Office of Government Commerce, ITIL V3,
London, (2007).
[32]
Parent, C., and Spaccapietra, S., Issues and
approaches of database integration. In CACM, 41, 5es,
(1998), pp. 166-178.
[33]
Rautenstrauch, C., and Schulze, T., Informatik für
Wirtschaftswissenschaftler und Wirtschaftsinformatiker.
Heidelberg, (2003).
[34]
Reich, B. H., and Benbasat, I., Measuring the
linkage between business and information technology
objectives. In MIS Quarterly, 20, 1, (1996), pp. 75-10.
[35]
Rizopoulos N., McBrien, P., Magnani, M., and
Montesi, D., Schema Integration based on Uncertain
Semantic Mappings, Conference or Workshop Paper, 24th
International Conference on Conceptual Modeling (ER05),
Klagenfurt, Austria Lecture Notes in Computer Science,
Volume 3716, Oktober (2005), pp.31–46.
[36]
Scheer, A. W., ARIS-Modellierungs-Methoden,
Metamodelle, Anwendungen. Heidelberg, (2001). [in
german]
[37]
Schütte,
R.,
Grundsätze
ordnungsmäßiger
Referenzmodellierung. Konstruktion konfigurationsund
anpassungsorientierter Modelle. Wiesbaden, PhD thesis,
1998.
[38]
Schütte, R., and Rotthowe, T., The Guidelines of
Modeling- an approach to enhance the quality in information
models. In Ling, Ram, Lee (Eds.) Conceptual Modeling – ER
98. Singapore, 16.-19.11.98, (1998), pp. 240-254.
[39]
Simonsson, M. and Johnson, P., The IT
organization modeling and assessment tool: Correlating IT
governance maturity with the effect of IT. Proceedings of the
41st HICSS, 2008.
[40]
Simonsson, M. and Johnson, P., Assessment of IT
Governance – A Prioritization of COBIT, Proceedimgs of the
Conference on Systems Engineering Research, Los Angeles,
USA, 2006.
[41]
Software Engineering Institue, CMMI, (1999).
[42]
Spaccapietra, S., Parent, C., and Dupont, Y., Model
Independent Assertions for Integration of Heterogeneous
Schemas. VLDB Journal 1, 1, (1992), pp. 81–126.
[43]
Spaccapietra, S., and Parent, C., View Integration:
A Step Forward in Solving Structural Conflicts. In: IEEE
Transactions on Knowledge and Data Engineering 2, 6,
(1994), pp. 258-274.
[44]
Strahringer, S., Metamodellierung als Instrument
des Methodenvergleichs, Shaker Verlag, Aachen, (1996). [in
german]
[45]
Verhoef, T.F., Hofstede, A.H.M.T., and Wijers,
G.M., Structuring Modelling Knowledge for CASE Shells. In
Andersen, R. et al. (Eds.): Proceedings of the third
international Conference CAiSE‘91 on Advanced
Information Systems Engineering, (1991), pp. 502-524.
75
Zwischenfazit Teil B
Ziel dieses Teils war es, die Wissensbasis der IT-Governance hinsichtlich der Struktur
von BPRM zu erweitern und zu vertiefen. Hierfür wurde mithilfe konzeptioneller
Forschungsmethoden die Struktur existierender BPRM herausgearbeitet. Die erstellten
Metamodelle von COBIT und ITIL ermöglichen im weiteren Verlauf der Arbeit die
Verwendung von Forschungsergebnissen aus dem Bereich der konzeptionellen
Modellierung, insbesondere der Referenzmodellierung. Denn für eine sinnvolle
Verwendung von Ergebnissen, z.B. aus der Referenzmodellierung, ist ein gewisser
Formalisierungsgrad zuträglich. Eine Steigerung des Formalisierungsgrades kann durch
die Metamodellierung erzielt werden, d.h. die Metamodellierung von BPRM ist ein
erster Schritt hin zu einer wissenschaftlichen Verwertbarkeit von BPRM. Der hierdurch
ermöglichte Einsatz von Erkenntnissen aus etablierten Forschungsbereichen der
gestaltungsorientierten Wirtschaftsinformatik ist maßgeblich für den weiteren Verlauf
dieser Arbeit.
Ergebnis der in diesem Teil präsentierten Forschungsarbeit ist die Erkenntnis, dass
Metamodelle von BPRM eine solide Basis für die theoretische Fundierung von BPRM
sind und somit einen Ausgangspunkt für weitere Forschungsarbeiten bieten. Da die
Metamodelle für nahezu alle folgenden Teile verwendet werden, ist ihre Qualität für
diese Arbeit bedeutsam. Die in Fachbeitrag 2 und 3 erarbeiteten Grundsätze einer
ordnungsmäßigen Metamodellierung verbessern die Qualität des Metamodellierens und
zeigen potentielle Fehlerquellen auf. Sie tragen somit zur Qualität der modellierten und
im Verlauf dieser Arbeit verwendeten Metamodelle bei.
Die Fachbeiträge 1, 2 und 3 erweitern und vertiefen die Wissensbasis der ITGovernance-Forschung bezüglich der Struktur von BPRM. Weiterer Forschungsbedarf
zeigt sich insbesondere bezüglich der Verwertung der hier erzielten
Forschungsergebnisse für die Unterstützung der Anwendung von BPRM.
76
Teil C: Formen der Anwendung von Best-PracticeReferenzmodellen
Vorbemerkungen Teil C
Dieser Teil beinhaltet zwei Fachbeiträge, die sich mit der Anwendung von BPRM
beschäftigen. Fachbeitrag 4 zeigt die Anwendung von COBIT im Bereich von
serviceorientierten Architekturen (SOA). COBIT wird in diesem Beitrag zur
Unterstützung der SOA-Governance angewendet. Im Verlauf der Forschungsarbeit zu
diesem konkreten Anwendungsfall wurde erneut deutlich, dass nur wenige
Forschungsergebnisse über die tatsächliche Anwendung von BPRM der IT-Governance
vorliegen. Um die Wissensbasis diesbezüglich zu erweitern, wurde im Sommer 2009
eine qualitative Studie durchgeführt. Ziel war es, die praktische Anwendung von
mehreren BPRM durch Interviews mit Experten eingehend zu analysieren. Hierfür
wurden 12 qualitative Experteninterviews geführt und ausgewertet. Eine wesentliche
Erkenntnis war, dass der Begriff Anwendung sehr undifferenziert verwendet wird.
Beispielsweise ist häufig unklar, wann ein BPRM als angewandt gilt und welche
Formen der Anwendung zu unterscheiden sind. Auch die aktuelle Forschung spricht
zumeist undifferenziert von Anwendung und vergleicht im besten Fall den Zustand vor
der Anwendung ceteris paribus mit dem Zustand danach. Wie bereits in Teil A erläutert
wird die Anwendung selbst bislang kaum erforscht. Hieraus ergeben sich die
Forschungsfragen: Welche Formen der Anwendung von BPRM existieren und welche
sollten aufgrund besonderer Häufigkeit gezielt unterstützt werden?
Das im Jahr 2009 angestrebte Forschungsvorgehen bezüglich dieser Forschungsfragen
ist in Abbildung 9 dargestellt. Der entwickelte generische Ordnungsrahmen ist die Basis
für eine systematische quantitative Erhebung der in der Praxis vorkommenden
Anwendungsformen, sowie deren Häufigkeiten. Eine solche Erhebung, etwa am
Beispiel von COBIT, hat einen quantitativ-explorativen Charakter.
77
Phase I
Entwicklung des Ordnungsrahmens
Erkenntnis,
dass für eine
methodische
Unterstützung
der Anwendung
von BPRM zu
wenig
Erkenntnisse
vorliegen
Phase II
Definition der
Forschungsfrage
Literaturanalyse
Qualitative
Auswertung
der Experteninterviews
Ableitung des
generischen
Ordnungsrahmens
Ableitung
eines
speziellen
Ordnungsrahmens für
COBIT
Quantitative
Untersuchung
der
Anwendung
von COBIT
Abbildung 9 Übersetzung von Abbildung 1 des folgenden Fachbeitrags
Dieses umfassende Forschungsprogramm wurde jedoch zugunsten anderer
Forschungsfragen dieser Dissertation nicht vollständig durchgeführt. Die
Forschungsarbeit wurde daher auf die Entwicklung des theoretischen Ordnungsrahmens
mithilfe von Experteninterviews und Literaturanalyse ausgerichtet (Phase I). Die
Ableitung eines für ein spezielles BPRM operationalisierten Ordnungsrahmens sowie
dessen empirisches Testen wurden nicht durchgeführt (Phase II). Abbildung 10 zeigt
einen Überblick dieses Teils C.
78
der SOA-Governance
Fachbeitrag 4
BPRM
Literaturanalyse
Literaturanalyse
Fachbeitrag 5
Abbildung 10: Darstellung Teil C: Formen der Anwendung von Best-Practice-Referenzmodellen
79
Fachbeitrag 4:
Towards an Operationalisation of Governance and Strategy for Service
Dieser Beitrag wurde in ähnlicher Form veröffentlicht in den Proceedings der
Informatik 2009, Lecture Notes in Informatics (LNI), S. 3660-3674, Fischer, Stefan;
Maehle, Erik; Reischuk, Rüdiger. Anzahl der Reviewer: 3; Art des Reviews: doppeltblind; Ranking: 0,1 Punkte (Handelsblatt-Ranking).
80
Towards an Operationalisation of Governance and Strategy for
Service Identification and Design
René Börner
Stefanie Looso
Matthias Goeken
ProcessLab
Frankfurt School of Finance &
Management, Germany
r.boerner@frankfurt-school.de
IT-Governance-Practice-Network
Management, Germany
s.looso@frankfurt-school.de
IT-Governance-Practice-Network
Management, Germany
m.goeken@frankfurt-school.de
Keywords - Service-oriented Architecture; SOA Governance;
Service Governance; Service Strategy; Service Identification;
Service Design; Method
I. SUCCESS FACTORS OF SERVICE-ORIENTED
ARCHITECTURES
Only companies with the flexibility to adjust quickly to a
changing environment may survive in the long-run [3]. In
this context, service orientation is a broadly discussed paradigm for business architectures. Frequently mentioned issues
in conjunction with service orientation are a quicker adaptation to changes in business processes through greater
flexibility and agility, greater reusability of services through
loose coupling, which is associated with a high degree of
internal cohesion of services [4]. The reusability of services
prevents the unnecessary provision of redundant functions
and thus reduces development and maintenance costs of the
IT infrastructure. The loose coupling allows an almost virtuosic composition of services and discloses sourcing potentials, for example through the use of web services [5]. But
the implementation of a service-oriented architecture also
Processes
Governance
IT-Infrastructure
IT-Governance
Corporate-Governance
This article focuses on individual services and shows how to
support their identification and design. Therefore, we present
specific deduced dimensions of the generic topics governance
and strategy. In addition, we present roles and techniques in
order to consider these topics already during the early phases
of an SOA implementation, i.e. in the identification and design
process.
IT-Processes
Business-Processes
Abstract—Service orientation is a promising paradigm for
results in a number of challenges. The flexible orchestration
business architectures. Implementing a service-oriented
of services increases the complexity of the whole system
architecture (SOA) promises increasing flexibility as well as
significantly and can even result in a deterioration of
agility and decreasing development and maintenance costs ofIT-Governance-Geschäftsarchitektur
performance [1]. But how to cope with these challenges?
IT landscapes. Simultaneously with these advantages, the
It is commonly accepted that processes should be derived
implementation of an SOA entails some inherent challenges.
from strategy
and thatdietheir
execution needs nachhaltige
some sort of
IT-Governance
bezeichnet
verantwortungsvolle,
und auf
The flexible orchestration of services increases the complexity
infrastructure
[6,
7].
Goeken
and
Johannsen
present
langfristigeder
Wertschöpfung
ausgerichtete Organisation undgovernSteuerung
Herleitung
Geschäftsarchitektur
of the whole system significantly and can even result invon IT-Aktivitäten
IT-Ressourcen.
(IT-Prozessen)
undtheir
ance as an additional
topic in
business architecture as
decreasing performance [1]. A holistic management of technolshown in Fig. 1.
ogy and business processes is therefore necessary [2]. We
IT-Strategy
believe that the essential SOA management tasks include topics
such as strategy, governance, processes as well as infrastrucBusiness-Strategy
ture. These management topics can be addressed on different
Strategy
levels of granularity, e.g. at an SOA governance level or a
single service level.
Business-Infrastructure
Infrastructure
Fig. 1. Business Architecture [21]
35
To deal with the inherent challenges of an SOA the
organization has to consider the same aspects in a complex
environment, namely technical, business, strategic and
governance aspects. These four management topics have to
be at the centre of attention in the process of an SOA implementation.
Furthermore, we believe that these four topics should already play an important role during the identification and
design phases of each individual service. Governance aspects, for example, should influence the service identification process. Fig. 2 illustrates exemplary the differences between SOA governance and service governance. SOA
governance refers to the service-oriented architecture as a
whole and should not be mixed up with service governance
which is concerned with the life cycle (identification, design,…, deletion) of each individual service.
In this paper we present our contribution to the management topics governance and strategy with a focus on individual services. We particularly concentrate on service
81
identification and service design which belong to the early
phases of the SOA lifecycle and are highlighted in Fig. 2.
SOA Governance
Service
Service
Service
Service
Service
Identification
Deletion
Service
Service Governance
Design
Service
Lifecycle
Maintenance
Integration
Operation
Optimization
Fig. 2. Comparison of the properties between SOA and
Service Governance
Service identification is the task of the business process
owner (BPO). Usually, a Business Process Modeling project
precedes such identification. In the following, the result of
this first step is referred to as a ―service candidate‖ (see Fig.
5). Only after the service candidate has been scrutinised by
the Service Excellence Centre (SEC) the design process is
conducted by the Service Design Unit (see section 5 for
details). Finally, this leads to a service that can be implemented subsequently.
For most existing approaches, a concrete operationalisation of the aforementioned management topics at the service
level is unsatisfactory or completely missing. This article
focuses on governance and strategy during the identification
and design phases of services. In order to guarantee an
economically advantageous implementation of an SOA, this
article shows how to support a top-down approach for service identification. This is considered a first step that has to
be complemented by proving the technical feasibility of
identified services [8] which is out the scope of this paper.
Finally, this leads to a hybrid approach for the identification
and design of services which is recommended by many
authors [9; 10].
The remainder of the paper is organised as follows. Section 2 reviews related literature concerning both identification methods and existing approaches to relevant management task of an SOA. Chapter 3 shows how the IT governance focus areas can be applied on services. The utilization
of strategic aspects for the identification and design of services will be discussed in section 4. For both areas section 5
will – in the sense of method engineering – develop roles and
techniques to assist the construction of a method for service
identification. We suppose that service governance und service strategy are essential for the generic management topics
governance and strategy. Addressing both aspects during the
phases of identification and design of services is crucial for a
successful business-oriented SOA implementation. Section 6
will draw conclusions and give an outlook on further research.
II. EXISTING APPROACHES TO SERVICE
IDENTIFICATION AND SERVICE DESIGN
A couple of approaches for service identification and design can be found in related literature. Although common
patterns can be identified among these approaches, they do
differ considerably in detail. This is partly due to their
origination from different industry sectors. A detailed analysis of the five approaches briefly presented in the following
can be found in Börner and Goeken [11].
Klose, Knackstedt and Beverungen [12] emphasise the
importance of the ―business point of view‖. They derive services on the basis of Business Process Modelling and stress
issues such as customer interaction. Their approach stems
from the manufacturing industry. Strategic aspects like
sourcing are not discussed explicitly. The need for IT governance can only be found implicitly in this approach. An
SOA governance in particular is missing entirely. Thus,
governance or strategic aspects are ignored in the identification process.
Böhmann and Krcmar [13] show a distinct commitment
to goal orientation. The goals they identify are, however,
very similar to the general SOA goals [4]. The application of
their modularisation matrix within the IT services industry is
the outstanding feature of this approach. Threats and
opportunities of modular service architectures in general are
discussed. An impact on the identification of single services
is not considered though. An explicit treatment of IT and
SOA governance issues is also missing.
Three more approaches are taken from the financial services industry. Arsanjani et al. [14] as well as Kohlmann and
Alt [15] follow a clearly business oriented identification on
services based on Business Process Modelling. Although
Winkler [16] also grounds her identification of services on
Business Process Modelling, her approach is much more
technical and leads to a more object-oriented than serviceoriented view. Whereas the latter approach does not consider
strategic aspects at all, the others include at least short
discussions on sourcing and reference models. By stressing
the importance of consistently naming services, only
Kohlmann and Alt look at one aspect of SOA governance
that directly affects the identification process.
Kohlborn et al. [43] distinguish between business services and software services. Due to this differentiation (that
is only implicitly addressed in other approaches by hierarchies) they manage to focus on business processes in the first
place. Subsequently, a prioritization phase is used to link the
first three phases of their method with the last three – technically oriented – phases. By building on approaches such as
[12] and overcoming weaknesses of others, strategic aspects
are incorporated fairly well. However, governance issues are
not at the core of their approach.
Many authors describe issues like interface orientation,
interoperability, loose coupling, modularity and reusability
as key characteristics of an SOA [17-20]. Undoubtedly, these
characteristics are typical for an SOA, but they reflect only a
technical point of view. An explicit connection to manage-
82
ment topics is missing in these approaches. Internal policies
are marginally mentioned in [14] and [15]. IT governance in
the broadest sense is implicitly mentioned by other authors
[12; 13; 15]. [21] discuss the relationship between IT
governance and the governance of a service-oriented
architecture.
Following the approach of [21], the next section therefore
describes the implementation of service governance during
the identification and design phases of services. This entails
operationalising the five IT Governance Focus Areas for an
application to services. In other words, the dimensions for
service governance are derived from the five key areas of IT
governance. Section 4 focuses on service strategy. In addition to existing more technical oriented approaches we
deduce and operationalise dimensions of service strategy as
well as dimensions of service governance in the following
sections.
III. IT GOVERNANCE FOCUS AREAS AND THEIR APPLICATION
TO SERVICE LEVEL
The key areas of IT governance comprise the five socalled IT Governance Focus Areas: strategic alignment,
value delivery, risk management, resource management, and
performance measurement [21; 22]. The key areas focus on
aspects which require management‘s attention in order to
appropriately manage and direct IT from a business perspective. In the following, these five key areas will be explained
individually, and their application for services and their relevance within the context of an SOA will be discussed. The
objective of this section is to derive dimensions for service
governance from the established key areas within the COBIT
(Control Objectives for Information and Related Technology) frameworkEase of Use
A. Strategic Alignment
Aligning the business management perspective and IT
represents a multi-layered problem, which encompasses not
only the strategies of these two areas but also processes
architectures, infrastructure, and cultural aspects. A common
assumption is that the alignment starts at the strategic level
[23]. This requires as a first step to align the business and the
IT strategies. In order to accomplish this, the Strategic Alignment Model (SAM) by [6] divides a business into four
domains: business and IT, as well as a strategic (external)
and an infrastructural (internal) domain. [6] regard alignment
as, ―a balance among the choices made across all four
domains.‖ Based on this, [24] describe a relationship
between standard business processes and standard IT
processes [cf. 25]. The authors thus illustrate that the alignment of the business perspective and IT necessitates aligning
levels subsequent to strategy alignment. [26] consider a
mutual understanding of the objective and the pursued avenue for reaching the objectives as a critical success factor for
aligning the business perspective and IT. Key to reaching
such a common understanding is efficient and pro-active
communication between employees in business operations
and IT. Such communication fosters customer integration, as
advocated by [13], since the functional departments can be
viewed as internal customers of the IT department. [27]
emphasises a business management focus as well in order to
secure the financing required for IT development and
maintenance and to deploy the services throughout the
organisation. A consistent and uniform use of terminology
for services, as postulated by [15], serves not only as a prerequisite for a high degree of reusability but reflects the
alignment of the business management perspective and IT as
well.
B. Value Delivery
This key area comprises the stipulation that IT has to
make substantial and verifiable contributions to the success
of the business. This entails as one important aspect the
demand-driven development of IT products in terms of
value-oriented IT services. In order to provide value-oriented
IT services that actually meet customer demand, it is critically important to align customers and IT services suppliers.
Such an alignment represents the main task of the previously
described focus area strategic alignment. [28] establish a
relationship between the degree of strategic alignment and
the value added by IT. Moreover, a study by [5] substantiates
that an SOA indeed enhances the alignment between the
business perspective and IT. However, this holds true only if
such an alignment between the business perspective and IT is
defined within the scope that ―the IT solutions provide a
strong fit with the business‖ [5]. [29] considers the value
generation through an alignment of the business perspective
with IT as the most important task of IT governance.
The reciprocal nature of the relationship between value
delivery and strategic alignment is also visible at the service
level. Aspects such as update frequency and reusability can
only be measured or forecasted in a meaningful way if business knowledge and IT know-how are combined. The
reusability of services and the resulting economic benefits
that may be generated, specifically eliminating redundancies
[15; 27], represent a decisive success factor in the key area
value delivery. An essential pre-requisite for a high reusability rate is the standardised use of terminology for services.
As previously explained, the integration of the customer, as
explicitly advocated by [13], is often a decisive factor in
order to create a benefit for an external or internal customer.
The configuration of the customer interface (also referred to
as ―line of interaction―[30]) has to be considered during the
service design phase. The higher the degree of customer
integration the more likely are changes to the customer interfaces and the service functionality, as customer requirements
may change frequently.
C. Risk Management
The objective of risk management is the identification
and analysis of risks. In addition, a business should possess a
clear understanding of its own risk preferences and attitude.
Finally, risk management considers knowledge of applicable
regulations and laws as well as the division of responsibility
within an organisation [cf. 21]. The most important security
aspects of an SOA [cf. also 31] are discussed in the following.
A specific service often requires authentification, i.e.
users (or other entities) have to be clearly identified, for
83
example, through a user name and password. The authorisation process ensures through the use of role-based access
control that only users with an appropriate authorisation are
able to retrieve or change data. Depending on the sensitivity
of the data and the importance of the process, a determination has to be made concerning which users are entitled to
which type of access. Once the authentification and
authorisation procedures have been implemented, and
provided that an adequate, technological solution, such as
protocols that cannot be compromised, has been developed,
the integrity and confidentiality of the data inherent in the
service can be assured. Service availability plays, on the one
hand, a vital role for customer satisfaction. The resulting
consequences of this will be examined in the discussions of
the focus areas ―resource management‖ and ―performance
management.‖ On the other hand, within the context of
regulatory requirements, service availability also has to be
considered within the focus area ―risk management.‖
Particularly financial services providers have to ensure
service availability in compliance with the requirements in
MARisk or Basel II. Service availability must be ensured
especially for the highly mechanised and automated trading
systems.
D. Resource Management
Resource management aims to achieve the consistent
management of resources within an organisation. This entails
paying particular attention to optimising investments and
managing these appropriately. The IT governance reference
model COBIT [22], identifies software applications,
information, infrastructure, and employees as the fundamental IT resources.
Applied to a service, this requires a determination of the
needed inputs in terms of data, hardware, and personnel, and
whether these inputs always remain constant. It is entirely
possible that a service may be differently utilised, depending
on the input factors. This, in turn, impacts the service output,
which therefore has to be defined in terms of the resource
factors as well. A more precise definition of the service interfaces allows for better and more exact determination of the
required resources. A high degree of autonomy, i.e. as much
inner-service cohesion as possible, combined with loose relationships to other services, supports the resource management activity. A service expansion also impacts resource
management. In such a case, one has to examine whether a
service affects multiple business functions. If this is the case,
i.e. various different functional departments are involved,
then the complexity of resource capacity planning increases.
Moreover, such a service is typically not suited to be outsourced. The involvement of several functional roles would
necessitate outsourcing an entire business process rather than
a single service. The required level of service availability
obviously impacts the quantity of resource reserves. Critical
processes require sufficient resource buffers that guarantee
even during emergency situations flawless and uninterrupted
operation (cf. section ―Risk Management‖).
E. Performance Measurement
The purpose of performance management is to measure
and control the implementation of strategy, projects, processes, and resource utilisation among others. The
operationalisation and measurement of strategic initiatives
and activities verifies and supports the degree of goal attainment. This is accomplished using, for example, a Balanced
Scorecard or any other methodology that provides for the
quantification of strategy in ―measurable units.‖ The
measurement goes beyond the mere accounting requirements, as so-called ―soft― factors are considered as well [32].
COBIT recommends determining objectives and their
measurements at three levels: IT objectives and measurements, which define the expectations the functional departments have of IT; process objectives and measurements,
which define the requirements for the IT process so that IT
objectives can be achieved; and, finally, activity objectives
and corresponding measurements [cf. 25].
In general, performance measurement applies to services
as well, but certain unique aspects have to be considered.
Firstly, applicable metrics or Key Performance Indicators
(KPIs) have to be identified for the particular service. The
complete service delivery time or the response time to the
service request represent suitable KPIs. The latter is closely
correlated to service availability, as response time serves as
the critical measure for service availability. All quality-critical attributes should be determined and measured, regardless
of whether the service is intended for internal or external
customers. In outsourcing arrangements, it is essential to
establish formal measurements through service-level
arrangements. Measuring service performance requires, however, careful and discerning examination, since a service may
comprise more than one activity with relatively limited
scope. Depending on the degree of granularity, a service may
encompass an entire business process or, at least, several
parts of such a process. If, for example, measurements are
conducted at the activity level, one has to determine whether
the individual measurements can be easily aggregated. The
design of services therefore has to take the measurement of
performance into consideration.
Fig. 3 provides a summary of how the dimensions of service governance relate to the IT governance focus areas. The
significance of the depicted dimensions for the service
identification phase has been illustrated in this section.
IT-Governance
Strategic
Alignment
Value Delivery
Risk
Management
Resource
Management
Performance
Measurement
Service Governance
Strategic
Importance
Reusability
Integrity
Autonomy
Granularity
Customer
Integration
Frequency of
Changes
Authorisation
Expansion
Quality
Customer
Integration
Authentification
Availability
Availability
Confidentiality
Availability
Fig. 3. Dimensions of Service Governance
84
IV. SELECTED STRATEGIC ASPECTS AND THEIR
APPLICATION ON SERVICE LEVEL
A consideration of strategic aspects is very important
because implementation of an SOA is not done for its own
sake but seeks tangible benefits for the company. Due to
this, strategic relevance must not be omitted from the early
stages of the SOA lifecycle, i.e. the identification and design
of services. A categorization by Allen [33] therefore
differentiates between three types of services:
Commodity services are stable, sufficiently established
services every market player must have. They are
suitable for outsourcing and standardization.
Territory services are fairly widespread but less stable
and usually represent business rules.
Value-added services constitute the special value of a
company‘s product or service in the market, i.e. a
company‘s core competence. It is this highly innovative service that gives distinction to the company.
Assigning a service candidate correctly to one of these
categories is crucial for subsequent sourcing strategies. A
thorough analysis of all kinds of transaction costs must give
reasons for a make or buy decision for certain services.
Specificity, frequency and uncertainty of transactions (and
the services representing them) determine the suitability and
costs for adequate coordination forms [34]. Commodity
services are more likely to be purchased in the marketplace
whereas value-added services are probably found in
organisational hierarchies.
A. Maintenance and Operation Costs
These costs correlate strongly with the quantity and
heterogeneity of IT systems in an enterprise. Although an
SOA can lead to an increase of complexity due to the need
for coordination of services [1], the number of different systems and applications is generally reduced. Thus, costs for
maintenance are decreased [35; 36]. Moreover, well-defined
functions and interfaces contribute to the robustness of IT
systems which in turn lessens operation costs.
On a service level, this implies that inputs and outputs
(i.e. the interfaces) have to be defined concisely. Taken this
for granted, the functionality of any service can be adapted to
changing customer or legal requirements using the same inputs and delivering equal outputs. Hence, other services are
not influenced by these changes. Testing efforts for the new
functionality can be reduced to a minimum. Subsequently,
overall costs for a new functionality are reduced significantly. Thus, the autonomy of a service is a determining factor for both maintenance and operation costs as well as
resource management described in section 3.
B. Vendor Dependency
Implementation of an SOA decreases vendor dependency
because such architecture is platform independent. Firstly,
this gives a company the opportunity to use open source software. Thus, a necessity of buying licenses would vanish and
lead to immediate savings. However, the total cost of ownership should be taken into account when thinking about open
source products. Secondly, a lock in effect is avoided, i.e. a
decision in favour of software from one vendor does not
necessarily influence future decisions on enterprise IT
systems. Hence, the company is not bound to a vendor
because of prohibitively high swapping costs. In the past,
proprietary standards often led to a high vendor dependency
[37]. Thirdly, web services can flexibly be used and increase
the agility of business processes. These web services can be
purchased ad hoc in the marketplace without long-lasting
contracts. Every time there is a need to buy a service the
cheapest provider at that time can be chosen to deliver it.
Security aspects can be more important for some services
than for others. Generally, an SOA is not more or less secure
than a monolithic application provided by one vendor. Availability and authorisation mechanisms for example can be
guaranteed by service level agreements. However, ensuring
these features will prove much more complex when many
services from different providers are purchased on an ad hoc
basis without permanent contracts.
Thus, if availability is critical to a single service the
flexibility of web services must be weighed against a holistic
application bound to one vendor. Still, decreasing dependency on software suppliers can be an important strategic goal
and can minimize costs considerably. If a service is classified
as commodity service that is not critical to the company‘s
core competences and most distinguishable processes it
should be purchased as cheap as possible on the web. This
clearly reduces vendor dependency. Even if availability is
crucial to a service it might be purchased in the marketplace.
When the failure of one provider can easily be made up by
others the risk of non-availability is neglectable.
Therefore, an analysis concerning attributes like
authorisation, authentification, confidentiality and availability is necessary in the service identification phase. Availability was discussed exemplarily in the previous paragraph being as relevant as the others. Strategic decisions regarding
vendor dependency are closely linked to risk management
aspects derived from the IT governance focus areas in
section 3 and deal with similar service attributes.
C. Demand-Oriented Quality of Service Level
Flexible orchestration of services enables a demand-oriented quality of service level for products. Customers receive
exactly the quality they request. Thus, customer satisfaction
is increased at the same time. This kind of orchestration
allows for an individualization of products in the sense of
mass customization. This individualization does not
necessarily increase operation expenses because the final
product is tailored to a customer‘s demand from standardized
parts, i.e. services.
Since service candidates in their existing design are seldom as standardized as they could be, their standardization
potential has to be examined in the identification phase. If
these candidates have a huge number of potential outputs the
necessity of this variety should be checked and reduced if
possible.
D. Specialisation on Core Competences
Specialisation on core competences plays an ever bigger
role in today‘s competitive environment [38]. The manage-
85
ment has to decide which place a company should take
within a distributed value chain [39]. Depending on that a
service which is a commodity for one company can be a core
competence of another. For investment banks for example
the settlement of trades is a commodity which they take for
granted. The settlement bank on the other hand is only concerned with settling trades from various institutions. They
have to guarantee a high quality and fast clearing of settlements. At the same time they have to control their costs in
order to be able to offer the settlement at a marketable price.
Consequently, identified service candidates can be classified on the basis of their strategic importance. Services that
deliver an exceptional value to customers should be considered valuable to a company and thus not be outsourced. On
one hand this could be services that are crucial for the quality
of a product. On the other hand this could be true for unique
services that cannot be imitated by competitors.
E. Time-to-Market
Product lifecycles are being reduced for many years now
and companies struggle to keep up with the speed to develop
new products. Deployment of services can significantly
reduce the time-to-market of new products [40; 44]. Particularly companies of the service sector need to care about this
because their products are imitated almost immediately by
competitors. Due to its agility and flexibility SOAs can react
quickly to changing customer requirements. This advantage
can be crucial to position new products successfully in the
marketplace.
Single services can be able to reduce the time-to-market
if they are sufficiently standardized and can be fitted into
new developed processes neatly. Thus, service candidates
have to be checked for their degree of standardization during
the identification process.
Fig. 4 summarises the dimensions of strategy and their
operationalisation for services.
Maintenance &
Operation
Costs
Vendor
Dependency
Strategy Aspects
DemandOriented Quality
of Service Level
Specialization
on Core
Competences
Time-to-Market
Reusability
Strategic
Importance
Customer
Integration
Uniqueness
Standardization
Service Strategy
Autonomy
Uniqueness
Reusability
Strategic
Importance
Variety
Confidentiality
Standardization
Security
Customer
Integration
Fig. 4. Dimensions of Service Strategy
Reusability
V. ROLES AND TECHNIQUES TO SUPPORT SERVICE
IDENTIFICATION
In order to operationalise the previously discussed strategic and governance aspects, this article proposes certain
measures that should be included in a company‘s service
identification method. For several years there have been
efforts to guide the development of methods in order to
guarantee a high quality. The task of method engineering is
to give this guidance. Nowadays, the concept of method
engineering is much discussed in the information systems
community. The most popular approaches all identify activities, roles, results, techniques and the sequence of activities
as important components of methods (for a detailed discussion see [41]). Existing approaches hardly address roles and
techniques to support the process of service identification
and service design [11]. Thus, this section presents two
examples that show how roles and techniques support
service identification and incorporate strategic and governance aspects on service level.
As described in section 2 IT governance aspects are
widely ignored so far on service level. Strategic alignment
for example should be further enhanced through alignment at
the subsequent levels. For the purpose of designing services,
this article recommends supporting an alignment
organisationally via the appropriate composition of the
―Design Team.‖ A Service Design Unit (SDU), consisting in
equal numbers of users from the functional departments and
IT employees, should be established for this purpose (see
Fig. 5). One team member assumes the role of Business
Process Owner (BPO), who informs the SOA unit within the
organisation, i.e., the Service Excellence Centre (SEC),
about a potential service (the so called service candidate) that
should be subjected to further analysis. Hence, the BPO and
a member from the SEC, who will later on act as Service
Owner (SO), jointly constitute the SDU. Since the BPO initiates the identification of the service, it is in principle assured
that this service candidate meets business perspective
requirements. The joint effort of the detailed configuration of
the candidate into a service ensures that technological restrictions as well as the criterion of ―strategic relevance― are
taken into consideration. Strategic alignment is therefore
supported by an alignment at the service level.
In order to make sure that both strategic and governance
aspects are already considered during the identification of a
service, the dimensions depicted in Fig. 3&4 have to be
operationalised even further. This entails as a first step the
determination of which attributes meaningfully reflect the
individual dimensions. In addition, the possible characteristics of the attributes have to be described.
86
Service
Candidate
identifies
is responsible for
Process
scrutinises
Business Process
Owner
Service
Excellence
Centre (SEC)
Identified and
scrutinised
Service
Candidate
requests design
Service Design Unit
Service Owner
supports
designs
Service
is responsible for
is part of
belongs to
Service
Repository
administrates
role
artifact
Fig.5. Integration of the Service Design Unit in the Organisational Context
For example, some attributes are binary and therefore
have to be characterised as ―present‖ and ―not present,‖ or as
―yes‖ and ―no.‖ Other attributes occur in gradation on a
continuum and can be classified, for example, on a threegrade Likert-scale. Free text complicates a standardised
analysis and should therefore be avoided. However, it may
be very worthwhile to assess quantities of observations (e.g.
of interfaces). It is possible that some characteristics serve as
―no go‖ criteria or as dominant criteria for the actual service
design.
From an organisational perspective, the responsibility for
the assessment of the dimensions showed in Fig. 3&4 rests
with the SDU, i.e. with the BPO and the ultimate SO. In
order to accomplish their task, they need certain techniques.
A structured questionnaire that is described in the following
can be such a technique. It facilitates an evaluation of
whether or not the service candidate proposed by the process
owner should indeed be implemented as a service. The two
SDU members agree on the characteristics of the different
attributes and are therefore in a position to develop conforming service governance.
Fig. 6 depicts an excerpt from a questionnaire that may
assist the SDU within an organisation in the identification of
services. The questionnaire is divided on the basis of the
derived dimensions (for the methodology, see e.g. [42]), so
that, for example, all questions pertaining to the autonomy of
the service (dimension 4) are contained within one block of
questions. The numbering scheme assigns the questions to
the individual dimensions on the basis of the first digit. For
example, questions 4.1 through 4.3 aim to analyse the
dimension ―autonomy.‖
Such a questionnaire serves as an integral element of a
methodology for the process-oriented identification of
services. When developing such a questionnaire, one should
make an effort to not include questions that are too specific,
so that the tool can be used in different departments or even
organisation-wide. At the same time, however, questions that
are too generic have limited use as well. The challenge is
therefore to find a balance that permits an application of the
questionnaire in many situations while delivering conclusive
results.
VI. SUMMARY AND NEXT STEPS
The paradigm of service-oriented architectures undoubtedly represents a promising concept for the flexible and
dynamic adaptation of organisation‘s IT landscape to new
and changing business requirements. However, such
architecture results in higher complexity and therefore
increasingly calls for making the SOA manageable through
the development of governance structures. Additionally,
strategic goals of a company should explicitly be considered
when an SOA is implemented. Whereas existing publications
examined SOA governance for the entire infrastructure, this
article focuses on governance of individual services. This
involves operationalising the five key areas of IT governance
and highlighting their relevance already during the phases of
identifying and designing services. The same is true for the
so far hardly covered field of strategy. High level goals are
therefore operationalised for single services. Finally, this
article promotes concepts of method engineering, i.e. roles
and techniques, to support the incorporation of strategy and
governance into the identification and design process of
services.
As shown in Fig. 1, strategy and governance are not the
only relevant topics. Covering the remaining fields is
undoubtedly an important further step to improve service
identification and design.
87
A questionnaire as depicted in Fig. 6 is certainly an
important technique but has to be complemented by others to
ensure that all method activities can be performed successfully by the respective roles. Moreover, the SDU members
need guidance in how to interpret the results of this questionnaire. Thus, it is important to create guidelines for drawing
conclusions from the received answers.
REFERENCES
[1] F.A. Rabhi, H. Yu, F.T. Dabous and S.Y. Wu, "A serviceoriented architecture for financial business processes: A case
study in trading strategy simulation," Information Systems
and e-Business Management, vol. 5, no. 2, 2006, 185-200.
[2] R. Berbner, W. Johannsen, J. Eckert, M. Goeken and N.
Repp, "SOA Governance - Management of Opportunities and
Risk," efinance lab quarterly. no. 04, 2006, 4-5.
[3] J. Becker, M. Kugeler and M. Rosemann, Process
Management. A Guide for the Design of Business Processes,
Springer, Berlin: 2004.
[4] M.P. Papazoglou, "Service-Oriented Computing: Concepts,
Characteristics and Directions," in Proceedings of the Fourth
International Conference on Web Information Systems
Engineering, 2003, 3-12.
[5] A. Becker, P. Buxmann and T. Widjaja, "Value Potential and
Challenges of Service-Oriented Architectures - A User and
Vendor Perspective," in Proceedings of the 17th European
Conference on Information Systems (ECIS 2009), 2009.
[6] J.C. Henderson and N. Venkatraman, "Strategic alignment:
leveraging information technology for transforming
organizations", IBM Systems Journal, vol. 32, no. 1, 1993, 416.
[7] H. Krcmar, Informationsmanagement, Springer, Berlin: 2006.
[8] E.G. Nadhan, "Seven Steps to a Service-Oriented Evolution,"
Business Integration Journal, 2004, 41-44.
[9] K. Ivanov and D. Stähler, "Prozessmanagement als
Voraussetzung für SOA," OBJEKTspektrum, vol. 12, no. 6,
2005, 60-64.
[10] R. Zacharias, "Serviceorientierung: Der OO-König ist tot, es
lebe der SOA-König," OBJEKTspektrum, vol. 12, no. 2,
2005, 43-52.
[11] R. Börner and M. Goeken, "Methods for Service
Identification: A Criteria-Based Literature Review," in 7th
International Workshop on Modelling, Simulation,
Verification and Validation of Enterprise Information
Systems (MSVVEIS), 2009, 76-84.
[12] K. Klose, R. Knackstedt and D. Beverungen, "Identification
of Services - A Stakeholder-Based Approach to SOA
Development and Its Application in the Area of Production
Planning," in ECIS'07: Proceedings of the 15th European
Conference on Information Systems, 2007, 1802-1814.
[13] T. Böhmann and H. Krcmar, "Modularisierung: Grundlagen
und Anwendung bei IT-Dienstleistungen", in Konzepte für
das Service Engineering. Modularisierung, Prozessgestaltung
und Produktivitätsmanagement, T. Herrmann, U. Kleinbeck,
and H. Krcmar, Editors, Heidelberg: 2005, 45-83.
[14] A. Arsanjani, S. Ghosh, A. Allam, T. Abdollah, S. Ganapathy
and K. Holley, "SOMA: A method for developing serviceoriented solutions," IBM Systems Journal, vol. 47, no. 3,
2008, 377-396.
[15] F. Kohlmann and R. Alt, "Business-Driven Service Modelling
- A Methodological Approach from the Finance Industry," in
Business Process & Service Computing: First International
Working Conference on Business Process and Services
Computing, 2007, 180-193.
[16] V. Winkler, "Identifikation und Gestaltung von Services.
Vorgehen
und
beispielhafte
Anwendung
im
Finanzdienstleistungsbereich," Wirtschaftsinformatik. vol. 49,
no. 4, 2007, 257-266.
[17] T. Erl, Service-Oriented Architecture - A Field Guide to
Integrating XML and Web Services, Prentice Hall, NJ: 2004.
[18] N. Josuttis, SOA in der Praxis - System-Design für verteilte
Geschäftsprozesse, dpunkt.verlag, Heidelberg: 2008.
[19] N. Bieberstein, S. Bose, L. Walker and A. Lynch, "Impact of
service-oriented architecture on enterprise systems,
organizational structures, and individuals," IBM Systems
Journal. vol. 44, no. 4, 2005, 691-708.
[20] C. Legner and R. Heutschi, "SOA Adoption in Practice Findings From Early SOA Implementations," in 15th
European Conference on Information Systems (ECIS 2007),
2007, 1643-1654.
[21] W. Johannsen and M. Goeken, Referenzmodelle für ITGovernance, dpunkt.verlag, Heidelberg: 2007.
[22] IT Governance Institute, COBIT 4.1, 2007.
[23] V. Lotz, E. Pigout, P.M. Fischer, D. Kossmann, F. Massacci
and A. Pretschner, "Towards Systematic Achievement of
Compliance in Service-Oriented Architectures: The MASTER
Approach," Wirtschaftsinformatik, vol. 50, no. 4, 2008, 383391.
[24] M. Goeken and J.C. Pfeiffer, "Linking IT and Business
Processes for alignment - A meta model based approach," in
Conference on Enterprise Information Systems ICEIS, 2009.
[25] S. Alter and M. Goeken, "Konzeptionelle Metamodelle von
IT-Governance-Referenzmodellen als Basis der Kombination
und Integration in einer Multi-Model-Umgebung," in
Business Services: Konzepte, Technologien, Anwendungen,
H.R. Hansen, D. Karagiannis and H.G. Fill, Editors, 2009.
[26] B.H. Reich and I. Benbasat, "Factors that Influence the Social
Dimension of Alignment between Business and Information
Technology Objectives," in MIS Quarterly, Management
Information Systems Research Center, 2000, vol. 24, no. 1,
2000, 81–113.
[27] S. Simmons, "Don't let the greatest benefits of SOA elude
you," in IBM developerWorks, 2007.
[28] P.P. Tallon and K.L. Kraemer, "Investigating the relationship
between strategic alignment and IT business value: the
discovery of a paradox, " in Creating business value with
information technology challenges and solutions Idea Group,
N. Shin, Editor, Hershey: 2003, 1-22.
[29] W. v. Grembergen, Strategies for information technology
governance, Idea Group Publishing, Hershey: 2004.
[30] G.L. Shostack, "How to Design a Service." in Marketing of
Services, J.H. Donelly and W.K. George, Editors, 1981, 221229.
[31] o.V., SOA-Security-Kompendium, Bonn: 2008.
[32] R.S. Kaplan and D.P. Norton, "Putting the Balances
Scorecard to work," Harvard Business Review, SeptemberOctober, 1993, 134-147
[33] P. Allen, Service Orientation: Winning Strategies and Best
Practices, Cambridge University Press, Cambridge: 2006.
[34] A. Picot, R. Reichwald and R.T. Wigand, Die grenzenlose
Unternehmung, Gabler, Wiesbaden: 2001.
[35] S. Reinheimer, F. Lang, J. Purucker and H. Brügmann, "10
Antworten
zu
SOA,"
HMD
Praxis
der
Wirtschaftsinformatik. vol. 44, no. 253, 2007, 7-17.
[36] M. Koch and M. Rill, "Erfolgsfaktoren zur Einführung
serviceorientierter
Architekturen
bei
Banken,"
in
Innovationen im Retail Banking, D. Bartmann, Editor,
Weinheim: 2005, 383-405.
[37] B. Mueller, G. Viering, F. Ahlemann and G. Riempp,
"Towards Understanding The Sources Of The Economic
88
Potential Of Service-Oriented Architecture: Findings From
The Automotive And Banking Industry," in Proceedings of
the 15th European Conference on Information Systems, 2007,
1608-1619.
[38] C.K. Prahalad and G. Hamel, "The Core Competence of the
Corporation," Harvard Business Review, vol. 68, no. 3, 1990,
79-91.
[39] R. Baskerville, M. Cavallari, K. Hjort-Madsen, J. Pries-Heje,
M. Sorrentino and F. Virili, "Extensible Architectures: The
Strategic Value of Service-oriented Architecture in Banking,"
in European Conference on Information Systems, 2005.
[40] S. Schulte, N. Repp, J. Eckert, R. Steinmetz, R.
Schaarschmidt and K. von Blanckenburg, "Service-oriented
Architectures - Status Quo and Prospects for the German
Banking Industry," International journal of interoperability in
business information systems, vol. 3, no. 2, 2008, 9-31.
[41] M. Goeken, Entwicklung von Data-Warehouse-Systemen.
Anforderungsmanagement, Modellierung, Implementierung,
Deutscher Universitäts-Verlag, Wiesbaden: 2006.
[42] M.
Bühner,
Einführung
in
die
Testund
Fragebogenkonstruktion, Pearson, München: 2006.
[43] T. Kohlborn, A. Korthaus, T. Chan, M. Rosemann,
―Identification and Analysis of Business and Software
Services - A Consolidated Approach,‖ IEEE Transactions on
Services Computing, vol. 2, no. 1, 2009, 50-64.
[44] F.
Kohlmann,
R.
Alt,
―Vernetzung
durch
Serviceorientierung,‖ in Transformation von Banken, R. Alt,
B. Bernet, T. Zerndt, Editors, Berlin Heidelberg, 2009, 99128.
Question 3.1
In your opinion, how important is this service to
distinguish the own company from competitors?
Question 3.2
Would you leave this service to an external provider
without hesitation?
Question 4.1
How many interfaces does the service have?
[number]
Question 4.2
Is the input for the service always the same?
always
sometimes
never
Question 4.3
Does the service always deliver the same output?
always
sometimes
never
Question 5.1
Are customers being integrated in the service?
always
sometimes
never
Question 5.2
Are staff members being integrated in the service?
always
sometimes
never
very important
never
average
not important
possibly
without hesitation
Fig 6. Excerpt from a Questionnaire
89
Fachbeitrag 5:
Application of Best Practice Reference Models of IT Governance
Systems (ECIS 2010), Pretoria, South Africa, 06.-09.07.2010.
Die hier abgedruckte Version des Beitrags unterscheidet sich minimal von der Version,
die in den Konferenz-Proceedings erschienen ist. Die zumeist sprachlichen Änderungen
wurden durch den Vortrag auf der Konferenz angeregt.
90
APPLICATION OF BEST PRACTICE REFERENCE
MODELS OF IT GOVERNANCE
Looso, Stefanie, Frankfurt School of Finance and Management, Sonnemannstraße
9-11, 60314 Frankfurt am Main, Germany, s.looso@frankfurt-school.de
Goeken, Matthias, Frankfurt School of Finance and Management, Sonnemannstraße
9-11, 60314 Frankfurt am Main, Germany, m.goeken@frankfurt-school.de
Abstract
Best practice reference models like COBIT, ITIL, and CMMI offer methodical support for
the various tasks of IT management and IT governance. Observations reveal that the ways
of using these models as well as the motivations and further aspects of their application
differ significantly. The models are used in individual ways due to individual
interpretations. From an academic point of view we can state, that the way these models
are actually used as well as the motivation using them is not well understood. We develop a
framework in order to structure different dimensions and modes of reference model
application in practice. The development is based on expert interviews and a literature
review. Hence we use design oriented and qualitative research methods to develop an
artifact, a „framework of reference model application‟. This framework development is the
first step in a larger research program which combines different methods of research. The
first goal is to deepen insight and improve understanding. In future research, the
framework will be used to survey and analyze reference model application. The authors
assume that typical application patterns exist beyond individual dimensions of application.
The framework developed provides an opportunity for a systematically collection of data
thereon. Furthermore, the so far limited knowledge of reference model application
complicates their implementation as well as their use. Thus, detailed knowledge of different
application patterns is required for effective support of enterprises using reference models.
We assume that the deeper understanding of different patterns will support method
development for implementation and use.
Keywords: IT/IS Governance, Best Practice, Reference Models, Qualitative Research
91
1
Introduction
A number of scientific papers find a positive correlation between a company‘s IT
governance and its IT performance (comp. Weill & Ross, 2004; Hardy, 2006; Heier,
Borgman, & Maistry, 2007; Law & Ngai, 2009; Sujitparapitaya, Janz Brian D., &
Gillenson, 2003). Weill & Ross find that „IT governance becomes even more important
when one consider that companies with better than average governance earn least 20%
higher return on assets than organizations with weaker governance― (2004, p.1).
Already years ago, prominent authors censured researchers for the lack of effort put into
studying e. g. how business and IT can be properly aligned, how IT related risks can be
managed and how IT can contribute to the overall value of the enterprise (Reich &
Benbasat, 2004; Chan, 1997). Furthermore, there is little guidance from research, and
science is failing to answer practical questions too often. It seems likely that this lack of
scientific support for practitioners resulted in the development of best practice reference
models (BPRM) like ITIL (IT Infrastructure Library) and COBIT (Control Objectives for
Information and Related Technology). They contain a big amount of consolidated
knowledge and experience and promise methodological support for day to day governance
practice. For this reason, they seem to be interesting subjects of research, e. g. regarding
their adaptation in practice and their inner structures and models.
However, until now, their acknowledgement in science is little and there is a lack of
knowledge concerning BPRM. Accordingly there is no clear and definite understanding of
the application of BPRM in an enterprise; instead, there seems to be a large variety of
application modes depending on a lot of different factors, like individual enterprises‘
respective goals.
This contribution is therefore dedicated to the development of a framework for the
application of BPRM of IT governance, which is the first step in a larger research program.
We assume the existence of definable application patterns, or application types within the
framework. By identifying patterns, we hope to learn about the application of BPRM in
enterprises. In further works, this knowledge will be used to substantiate methodical
support for the introduction and use of BPRM in enterprises, because we presume, that
diverse application types require specific methodical support respectively due to their
differences.
The remainder of the paper is organised as follows: After a deeper introduction to the
problem and the research program as well as the method used here, section 3 deals with the
construction of the framework. Based on the results of qualitative expert interviews and
literature on this topic, dimensions of the framework will be introduced and discussed step
by step. Section 4 exemplifies the specification of the framework for Control Objectives for
Information and related Technology (COBIT), which are the basis for a quantitative-
92
empirical analysis to be accomplished. Finally, section 5 summarises results, demonstrating
the need for further research.
2
Problem Statement, Research Goals and Methods
In the last decades, associations and (public) institutions from different provenance
developed BPRM for various purposes and several stakeholders. Furthermore, the same
model could be used in enterprises with diverse motivation and in order to accomplish
different goals.
For example there is empirical evidence in literature that the BPRM COBIT was more
frequently used after the Sarbanes-Oxley Act 2002 and the Auditing Standards No. 2 of the
Public Company Accounting Oversight Board 2004 came into effect (on the effects see
Abu-Musa, 2002; Crockcroft, 2002; Damianides, 2004; Mishra & Weistroffer, 2007). In
these cases, there are strong regulatory and supervisory requirements, forcing the
application of the model. The overall purpose is to be compliant with law. This observation
is substantiated by the results of an empirical study performed by Tuttle & Vandervelde
(2007). They show an increasing interest and application in COBIT after the mentioned
regulatory changes in 2002 and 2004. But, it is remarkable that the observed increase refers
to a subset of COBIT only and that not all the processes have been taken into consideration.
Beyond compliance, there are further purposes promoting the application of BPRM and
these are related to different goals and objectives of the model. The overall motivation here
can be termed as ―improvement‖ (Siviy, Kirwan, Marino, & Morley, 2008a; Webb, Pollard,
& Ridley, 2006). COBIT for example is also expected to improve business/IT alignment
and the business value of IT as well as a better controlling and monitoring of IT risks and
resources (see the discussion in Goeken, Pfeiffer, & Johannsen, 2009). The ITIL BPRM
addresses IT service management and has a similar focus but neglects risk and compliance.
CMMI instead is focussing on process improvement for development, acquisition and also
services.
But it has to be noted that improvement is the primary intended purpose of the authors and
editors of the BPRM. Because it stands to reason that there are other not intended and not
foreseen sense making applications of the mentioned BPRM. As such it might be valuable
to use ITIL or CMMI for the auditing of an IT department or a data centre in the context of
an SAS 70 audit. We see this as a strong indication that there are different modes to
discover for the application of frameworks.
In some cases, the BPRM are used as checklists or as inspiration to create a proprietary
model, in other cases they serve as a blueprint for the organisational structures and
processes of the IT. If compliance is the main driver, a full-blown implementation of the
relevant parts of the BPRM might be required.
93
These observations reveal that the modes of application of BPRM as well as the motivations
to use them might vary significantly. But concerning these and other possible applications
of the models, there is little empirical evidence. Only a few case studies reporting
individual experience can be found in literature (i.e. Willson & Pollard, 2009; Lunardi,
Becker, & Macada, 2009). Due to the fact that the reported results are in parts
contradicting, they do not provide a consistent picture.
Rather it is worth mentioning that in studies which could help to clarify the confusing
observations, the basic constructs remain vague and are not properly defined:
 KPMG‘s 2009 IT Internal Audit Survey states that ―standard risk and planning
frameworks such as COBIT are increasingly popular for planning IT audit activity and
are adopted by 75 percent of respondents.‖ (KPMG International, 2009, p.7)
 In ―IT Governance in Practice - Insight from leading CIOs― from 2006 50 CIOs of
leading international companies has been surveyed. The result was that 63% of
respondents used COBIT, 60% used the IT Infrastructure Library (ITIL). In total 95 %
of the respondents used COBIT and/or ITIL while 65% indicated using both BPRM
together (PWC, 2006).
 2007 PricewaterhouseCoopers conducted a study on behalf of IT Governance Institute
(ITGI). It was the third global study on IT governance and the results were published in
the ―IT Governance Global Status Report—2008‖. This study showed an increase of
COBIT users from 9 to 15%, the application of ITIL increases from 13 to 24%. The use
of a proprietary IT governance model which based on ITIL and COBIT increased from
14 to 33% (ITGI, 2008).
This significant difference between the above empirical studies, as well as the strong
variation in different years might point to the different application forms. One reason for
the differences may be that ‗application of best practice reference models‘ could not be
properly operationalised and remained a relatively arbitrary concept. As a consequence, the
answer of the respondents, whether they use a BPRM or not, is a purely subjective one.
Therefore, it can happen that a specific company model, developed by a company on the
basis of a BPRM, could be rated and indicated as an application of a BPRM or as a
proprietary development. The same holds true for the partial use of BPRM and for the
unsystematic ‗cherry picking‘ of ideas.
These studies demonstrate, in addition to the observations above, the research problem and
the focus of this paper. In order to learn about the application of BPRM in practice, it seems
to be necessary to previously develop a framework as an operationalisation of the concept
application of BPRM. Only this preliminary step allows the investigation of the modes of
BPRM application and the detection of deeper structures in further empirical research. We
hope to be able to base e. g. a method for introduction of BPRM in companies on these
findings in later works as well.
Due to the fact that there is little empirical and conceptual work concerning the modes of
BPRM application in literature, we also use the results of a series of expert interviews to
94
develop a comprehensive framework first (see fig. 1). The goal of the research in this phase
I is to identify relevant dimensions and so called ‗parameter-values‘ to characterize BPRM
application in practice. The intention of using literature review/desk research in
combination with qualitative analysis of expert interviews is not to get a representative
statement. The goal is rather to identify the facets of the application of BPRM in terms of
their dimensions and parameter-values.
As the research program depicted in fig. 1 shows, literature review and qualitative analysis
of expert interviews are conducted in an iterative, cyclical manner. In this first phase, we
focused on the construction of a framework by supporting the emergent dimensions,
assigning instances to them, and validating them by iterating from literature to interview
results and back to literature.
Phase I
Development of the Framework
Phase II
Initial
Observation
Definition of
the Research
Problem
Literature
Review
Qualitative
Analysis of
Expert
Interviews
Figure 1.
Derivation of
the
Framework
Derivation of
a special
Framework
for COBIT
Empirical
Testing of the
Hypothesis
Research Program
In phase II, which is future research, we will test derived hypotheses and thereby strengthen
the awareness of BPRM application in enterprises. We believe that the application of
BPRM has to be analyzed separately for each specific model, not for all BPRM in general.
Therefore, we will deduce a special framework for COBIT. An excerpt of this step of our
research program is shown exemplary in section 4.
We think that the combination of different research methods allows us to develop a sound
understanding of the application of IT governance BPRM. Following Mingers (2001) we
assume that „a richer understanding of a research topic will be gained by combining several
methods together in a single piece of research or research program― (p. 241).
95
3
Framework for BPRM Application in IT Governance
The construction of a generic framework for BPRM application using results of a literature
review (3.1) and a qualitative-empirical expert survey (3.2) is shown in the following
section. By using findings of expert interviews and a literature review we combine two
different research methods. These two steps were done iteratively as shown in fig. 1 but for
better traceability of the findings origin they are presented in two separate sections. In
section 3.3 the findings are being discussed and the framework is presented.
3.1
Findings from Literature Review
According to Becker et al., a reference model is an information model that represents a
recommendation and basis for the development of specific models (Becker, Delfmann, &
Knackstedt, 2002). As a general suggestion for the solving of an abstract class of problems,
reference models support a solution for problems in an specific area. As a starting point, it
provides a model pattern for a class of problems to be modeled (Fettke & Loos, 2002, p.9).
Reference modeling is divided into two processes: (1) construction of a reference model,
and (2) its application, i.e. development of specific models or solutions based on this
pattern for a particular case (Fettke & Loos, 2002, p.10). A number of publications is
available on the construction of reference models (i.e. Winter & Schelp, 2006; Becker,
Delfmann, & Knackstedt, 2004; Schütte & Rotthowe, 1998) while little is known about the
application of reference models itself. Those which are relevant for the application of
BPRM in IT governance will be used in the following to derive different dimensions for the
framework.
According to Becker et al. (2002, p. 36), model application is carried out as follows. It can
be divided into different phases; the main phase being adaptation to an enterprise‘s specific
situation. They describe the necessity of several techniques of adaptations before applying a
reference model to a specific modeling situation. Following Fettke & Loos (2002)
adaptation is divided into 2 categories. (1) For configurative adaptations individual areas of
a model are erased, altered, or completed to improve its fit. (2) For generic adaptations,
explicit options of adaptation are described apart from the actual reusable reference model.
Rules are defined to be followed in order to adjust the reference model (p. 13). This is a
clear hint that BPRM can be applied in part as well. Reference models are not necessarily
designed for use as a whole. Apparently, a reference model is also considered as applied if
individual parts are used differently or not at all; complete use of the entire reference model
is not necessary. Regarding this, Bowen, Cheung, & Rohde (2007) show that organisations
intending to introduce models frequently choose a subset of the model as an initial frame to
begin with. In our framework we capture this finding from literature as the dimension
adaptation rate.
96
Further aspects are mentioned in literature. BPRM are used in different degrees of
obligation. Some users choose whole parts of BPRM in order to use them in a liable way
while others use BPRM to obtain ideas and suggestions. A participant of the
aforementioned study ―IT Governance in Practice - Insight from leading CIOs‖ describes
the application as follows: „I use frameworks and standards for inspiration, and we use
what we think is useful and relevant for our organisation. We have no intention to get
ourselves certified or to follow standards to the letter‖ (PWC, 2006, p.18). (Simonsson &
Johnson (2008) and also De Haes & van Grembergen (2008) demonstrate that individual
parts of COBIT (e.g. processes, aims, control objectives) are not considered equal. They
assume that each BPRM has components that are more prominent while others just serve
completion. Gammelgard, Lindstrom, & Simonsson (2006) describe how a certain part of
content can be prominent rather than certain components as according to Simonsson
& Johnson (2008). A partial amount of the COBIT framework, for instance, has been
marked relevant for the requirements of Sarbanes-Oxley Act (SOX). Chosen out of 14
COBIT processes, a subset of the COBIT control objectives were adapted to SOX. In this
case, the subset is used entirely as required by COBIT rather than for mere inspiration (see
Mishra & Weistroffer, 2007). Although similar to the dimension adaptation rate, the
dimension degree of obligation is rather qualitative while adaptation rate has a quantitative
character. Following the main acts of european legislation, we will distinguish the
parameter-values recommendation, directive, and regulation, i. e. whether the board of
directors presents it as a recommendation or an order.
There are some approaches and models in literature for governing IT, some focussing on
the structural aspects like decision rights and committees. Others describe the processes and
methods which should be used in IT (Weill & Ross, 2004; IT Governance Institute, 2007;
De Haes & van Grembergen, 2005). Theses various views on the topic IT governance can
affect the use of BPRM. The understanding of IT governance by Weill & Ross (2004),
clearly differs from ITGI‘s definition COBIT is based on. Weill & Ross (2004) describe IT
governance as ―specifying the decision rights and accountability framework to encourage
desirable behaviour in the use of IT‖. COBIT for instance, has the component ―RACICharts‖ which provides both activities of COBIT processes and roles within the enterprise
with relations, combining decision rights with responsibility. This understanding of
governance appears in Larsen, Pedersen, & Anderson (2006), which presents a
characterisation of BPRM as tools for ―decision making‖. Presenting another perspective
regarding the use of models, Bowen et al. (2007) describe IT governance and its BPRM
from a business point of view. They are referred to as a possibility to support management
in professionalising IT and adjust IT flexibly to market conditions. Cost efficiency, growth,
flexibility, and compliance are stated as the goals when applying BPRM. Likewise, Hardy
(2006) uses them to enhance valuable contributions, though he mentions legal and
monitoring-related challenges as reasons for the application of BPRM such as COBIT. IT
revision and accounting, in contrast, use COBIT in order to make sure that IT processes
meet regulatory requirements (Lainhart, 2000; Damianides, 2004; Fox, 2004). This is also
confirmed by Tuttle & Vandervelde (2007). The context of IT management considers a
97
BPRM as a possibility to establish organisational structures and processes for
professionalised IT. According to Weill & Ross (2004), BPRM are also used for the
creation of decision-making structures. Another possibility within this dimension is the
purpose of auditing, both internal and external, as well as the definition of accountability.
Finally, the creation of a common, generally accepted language is identified as the fourth
extension.
It turns out that there are various types of use with clearly varying motives. To sum up,
there are at least four parameter-values within the dimension types of use.
Another possibility to distinguish different modes of application is offered by the different
levels in organisations. A BPRM or rather the responsibility for the model could have its
place on an single level of the company. Literature often distinguishes between operational,
tactical and strategic level. The dimension organisational level allows interesting
combination with other dimensions.
Reviewing the literature we find evidence for four dimensions which provide a possibility
to distinguish different modes of application of a BPRM. The presented framework will
include these dimensions.
3.2
Findings from Expert Interviews
The following results are taken from a qualitative study on the use of several BPRM of IT
governance which focuses on how enterprises deal with the variety of models in the area of
IT. This so-called multi model environment (Siviy et al., 2008a; Siviy, Kirwan, Marino, &
Morley, 2008b) provides enterprises with specific opportunities (e.g. use of best practice
knowledge from various areas) but also with challenges like complexity, ambiguousity, or
overlaps (Cater-Steel, Tan, & Toleman, 2006). The participants of the interviews are skilled
experts whose experience (average years of experience in the field of IT governance: 7,8)
accounts for their knowledge in the subject matter. Twelve interviews lasting several hours
each have been carried out. Subject matter related and area specific statements have been
generated within the following: (1) motivation and reasons for the use of several BPRM,
(2) organisational and content related issues in parallel application of different BPRM, and
(3) challenges and need for support when using several BPRM of IT governance. The first
part of this qualitative research deals generically with the use of models before proceeding
to the main topic, which is the use of several models. Therefore, the framework aimed at
can be derived from this first part results.
In the following, interview excerpts will be cited in order to derive suggestions for
particular dimensions (Experts are indicated by numbers (e.g. E1) and quotations are in
italics). We extract the excerpts out of the interview transcripts we selected and present
those which indicate the existence of special dimensions of BPRM application.
98
The interviews show that an analysis of the application should include the direction of
derivation within an enterprise. For the interviewees it does make a difference if a BPRM is
introduced top-down by the enterprise‘s top level management, or bottom-up in efforts lead
by departments or users. For E1, it is clear that the management pushes the application:
„Management is clearly the driver. As an internal client of the IT, it gives pressure to the
IT department, in order to improve quality management and to increase the degree of
maturity.” E5, however, considers both the departments and the market a starting point for
the use of BPRM. „’The market’ is the motivation. …Few clients are motivated by
management; it usually comes from below.” The authors suggest that the dimension
direction of derivation ought to be taken into account when systematizing the application,
since certain particularities in the application might have its origins in the direction of
derivation. For instance, a combination with other dimensions may lead to interesting
results, e. g. it might be possible that certain parts of a BPRM can be introduced top-down,
others bottom-up.
Another dimension of distinction is the range of the application. Interviews give the
indication that at least two basic forms should be distinguished. BPRM can be used
personally by individual members of an organisation in order to support their actions
without requiring a decision by the enterprise. This individual application is described by
E7: Lots of things from the models are not directly communicated within the departments of
the organisation, only indirectly with changed processes. We use COBIT rather for
ourselves [the IT], it gives us ideas we do not directly communicate to everyone in the
organisation; rather, we use information individually in order not to burden the
organisation with model content.” E6, in contrast, states that models are applied throughout
the entire organisation. „We have chosen COBIT as a whole model. COBIT is focused on
professionalising our IT. This requires all staff members to know about its use. This choice
was a strategic decision which is now being introduced successively in the entire
company.” After all, it is possible that the two application modes blend. If individual
application exceeds a certain degree, it can be considered as an organization-wide
application. Application by the entire organisation, however, includes their deliberate
decision. This is suggested by certification policy in the area of ITIL, whose certificates are
individually obtained and granted whereas an organisation has to make a separated effort
for certification according to ISO/IEC 20000. This would be required even if all members
were ITIL-certified. Hence, the distinction between individual application and application
by the organisation is to be taken into account when analysing the application of BPRM.
Therefore the dimension range of application should be included in the framework.
The dimension type of use and the adaptation rate were derived from literature but are also
results of the analysis of the interviews. The dimension type of use is expanded by E7, a
consultant in the area of IT governance. He describes a type of use which can be found in
his consultancy practice. He describes models being used by his clients in order to find a
common idea of IT organisation and a common language. Hence, this type helps to provide
a common terminology and understanding by use of models. The adaptation rate was an
99
overall topic of the interviews. The operationalization of this dimension should be done
carefully, because it seems to be very meaningful for the different modes of application of
BPRM. Therefore adaptation rate is the chosen example in section 4.
3.3
Framework Construction
By using the presented findings we derived the framework for the application of BPRM
depicted in table 1. The framework and its dimensions are the basis for the derivation and
design of detailed surveys for specific frameworks. Meant as examples, grounded in
literature or expert interviews, the parameter-values shown at the right in table 1 are to be
specified for each respective model. To obtain clearly operationalized and independent
variables for a survey, the dimensions have to be filled with parameter-values for each
specific framework. Potentially not all dimensions can be operationalized for each
framework; some even might be needless, or unhelpful. I.e. for a BPRM which is never
used completely, the distinction between complete and partial use seems to be needless
because all observations would have the same parameter-value. In this case is could be
useful to refine the parameter-value partial application for further specification. This case
is shown for the COBIT BPRM in the following section.
Dimension
Source
Possible Parameter-Values
Adaptation Rate
Literature/
Interviews
Interviews
Interviews
Literature/
Interviews
Complete Application, Partial Application
Application Range
Degree of Obligation
Type of Use
Objective
Interviews
Direction of Derivation
Literature/
Interviews
Literature
Organisational Level
Table 1
4
Individual Application, Application by Organisation
Recommendation, Directive, Order
Auditing
(internal/external),
Definition
of
Accountability, Desicion-making, Designing, Define
Terminology
Model Compliance, Orientation towards Corporate
Goals
Bottom-Up, Top-Down
Operational, Tactical, Strategic
Framework for the Application of BPRM
Framework for the Application of COBIT
This section deals with the specification of the framework exemplified for COBIT and its
potential operationalization for an empirical survey. For analysis thereof, the dimensions
100
have to be provided with parameter-values particular to COBIT, which have to be
reasonably operationalised for a survey. This is important because the generic framework
can not include best practice model-specific parameter-values which cover all BPRM. The
specification of dimensions by means of model-dependent parameter-values will be
demonstrated in the following, exemplified for the dimension adaptation rate.
It can be concluded from literature that neither COBIT nor other BPRM need to be used in
their entirety, as has also been confirmed by the interviews. If the goal is to systematically
collect data on the application of COBIT, the adaptation rate of the BPRM has to be taken
into account. Two cases occur in the first place, complete and partial use of COBIT.
Because of the authors observation that most companies use only parts of COBIT the
partial use have to be refined. Partial use means to select a subset of COBIT. That means
COBIT > COBIT-Subset. For detailed specification of partial use, further classification
criteria are required. These criteria can be derived by abstraction of the model into a best
practice reference meta model. As shown in figure 2 a model‘s structure is defined by its
meta model components.
Role
(1,*)
executes
(1,*)
Control
Objective
Activity
(1,*)
(1,1)
Output
is
contained
in
is
contained
in
isa
is used by
(0,*)
(1,1)
(1,*)
(1,*)
Process
(1,*)
(1,*)
supports
(1,*)
isa
(1,5)
IT Governance
Focus Area
Goal
(1,*)
is
measured
by
(1,4)
IT-Resource
Domain
adresses
(1,7)
Information
Criteria
has
(1,1) Maturity Level
(1,*)
IT Goal
Activity Goal
belongs to
(1,1)
(1,*)
(0,*)
supports
Process Goal
uses /
needs
(1,1)
is created
by
Control Practice
(1,1)
(0,*)
Result
(1,*)
(1,*)
(0,*)
Input
is
contained
in
is
determined
by
(1,1)
(1,*)
Metric
Maturity Model
Fig. 2 COBIT Meta Model (Goeken & Alter 2009)
101
Basically, COBIT version 4.1 consists of 34 processes (model component) which describe
the content of the reference model. Model components are the instances of meta model
components, e.g. the defined processes of COBIT like ―manage changes‖ etc. Meta model
components are i.e. process, domain, control objective, maturity level etc. (for a description
of all components see Goeken & Alter, 2008, Goeken & Alter, 2009). According to the
inner structure of COBIT the dimension adaptation rate could be refined by two
subordinate dimensions metamodel components and model components.
The use of a selection of meta model components is one case of partial application in the
dimension adaptation rate. In this case, the structure of the meta model is changed by partial
use of meta model components. But the relations shown in the meta model define the
possible changes. A coherent subset does not, for instance, allow the use of metrics of the
COBIT processes unless the goals of the processes are used as well. This is because the
component goal links process with metrics.
The second case to be regarded is defined by reduction of the model‘s scope. Accordingly,
all meta model components are employed but not all model components. Thus the content
is reduced but the model‘s structure is unchanged. The reduction of model components
results in different problems than the reduction of meta model components does. This is
due to interconnections of content, such as predecessor-successor-relations, which can
cause successors to be left without any input or the output of a process to remain unused
even though links within the meta model are intact.
Therefore a survey of the adaptation rate of COBIT should include these findings and
should distinguish between partial use of model components and partial use of meta models
components. As exemplified for adaptation rate all dimensions have to be specialized for
the application of COBIT. The dimensions have to be furthermore operationalised with
parameter-values. The resulting framework for COBIT is the basis for a survey in order to
achieve empirical results on the application of COBIT. A survey on the application of
COBIT should include several parameters, which could be derived from the framework‘s
dimensions. Completeness of model components and meta model components are examples
for parameters derived for the dimension adaptation rate.
We expect that the resulting data would show so-called application patterns within the
application of COBIT. The authors assume certain dependencies, such as certain parametervalues of dimensions appearing more frequently in combination with certain values of other
dimensions. These application modes or patterns are defined as tuple of parameter-values.
The use of a BPRM with the objective ―model compliance‖, for instance, might increase
the probability of ―strategic level‖ and ―complete application‖ of a model‘s content. If
application patterns exist within the data, they will probably be related to certain user
groups. User groups could be determined by the user‘s business, industry, or profession.
According to the example before an ascribable user group might be ―Accounting
Information Systems‖. This user groups could be specifically supported when applying the
model in their specific manner. In case, certain components are not or rarely used within a
102
specific pattern of action, for instance, tools and manuals can be adjusted accordingly.
Thus, the quality of application is improved, which may serve the reduction of complexity.
5
Conclusion and Future Research
BPRM of IT governance offer methodical support for corporate IT organisations.
Developed for various reasons, existing BPRM as well as their individual components have
different stakeholders, focuses, and aims. Caused by these differences and individual
interpretation the application of BPRM differs noticeable. The resulting multitude of
application modes makes it difficult to support their introduction and application in
enterprises reliably. Thus, detailed knowledge about BPRM application is required for
effective support of enterprises using those models.
By combining two different research methods we were able to get a deeper understanding
of the application of IT governance BPRM. Based on observable applications, we
developed several generic dimensions of application. These findings were confirmed by
literature and qualitative expert interviews. The dimensions are combined to a generic
framework. This framework contains the deduced dimensions needed for a distinction of
various application modes. The objective of the herein presented part I of the research
program was to identify facets of the application of BPRM in terms of their dimensions and
instances. The developed framework is the result of this phase. For part II of the research
program the developed framework provides an opportunity to collect data systematically.
This data enables us to derive representative statements by using quantitative empirical
methods. This step will broaden our understanding of the research topic and enrich our
research program by adding a further research method.
Even if individual dimensions themselves contain important conclusions referring to BPRM
application, we also assume that ―typical‖ application patterns exist beyond individual
dimensions. To be aware of these different application patterns will build a basis for further
research e.g. the construction of a method for introduction of BPRM in companies based on
different application patterns.
Literature
Abu-Musa, A. A. (2002). Computer Crimes: How can you protect your computerised
accounting information system? Journal of American Academy of Business, 2(1), 91–
101.
Becker, J., Delfmann, P., & Knackstedt, R. (2002). Eine Modellierungstechnik für die
konfigurative Referenzmodellierung. In J. Becker & R. Knackstedt (Eds.),
Arbeitsberichte des Instituts für Wirtschaftsinformatik: Vol. Nr. 90.
Referenzmodellierung 2002 (pp. 35–76).
103
Becker, J., Delfmann, P., & Knackstedt, R. (2004). Konstruktion von
Referenzmodellierungssprachen: Ein Ordnungsrahmen zur Spezifikation von
Adaptionsmechanismen für Informationsmodelle. Wirtschaftsinformatik, 46(4), 251–
264.
Bowen, P. L., Cheung, M.-Y. Decca, & Rohde, F. H. (2007). Enhancing IT governance
practices: A model and case study of an organization‘s effort. International Journal of
Accounting Information Systems, 8, 191–221.
Cater-Steel, A., Tan, W. G., & Toleman, M. (2006). Challenge of adopting multiple process
improvement frameworks. In Proceedings of the 14th European Conference on
Information Systems .
Chan, Y. E. (1997). IT alignment: an annotated bibliography. Journal of Information
Technology, 22(4), 316–396.
Crockcroft, S. (2002). Gaps between policy and practice in the protection of data privacy.
Journal of Information Technology Theory and Application, 4(3), 1–13.
Damianides, M. (2004). How Does SOX Change IT? The Journal of Corporate Accounting
& Finance, 5(6), 35–41.
De Haes, S., & van Grembergen, W. (2005). IT Governance Structure, Processes and
Relational Mechanisms: Achieving IT/Business Alignment in a Major Belgian Financial
Group. In Proceedings of the Proceedings of the 38st Annual Hawaii International
Conference on System Sciences. HICSS 2005 (pp. 237ff).
Fettke, P., & Loos, P. (2002). Methoden zur Wiederverwendung von Referenzmodellen –
Übersicht und Taxonomie. In J. Becker & R. Knackstedt (Eds.), Arbeitsberichte des
Instituts für Wirtschaftsinformatik WWU: Vol. 90. Referenzmodellierung 2002 Methoden
– Modelle – Erfahrungen (pp. 9–30). Münster.
Fox, C. (2004). Sarbanes-Oxley Considerations for a Framework for IT Financial Reporting
Controls. Information Systems Control Journal, (1), 52–54.
Gammelgard, M., Lindstrom, A., & Simonsson, M. (2006). A reference model for IT
management responsibilities. In EDOCW ‟06: Proceedings of the 10th IEEE on
International Enterprise Distributed Object Computing Conference Workshops (pp. 2626). Washington, DC, USA: IEEE Computer Society.
Goeken, M., & Alter, S. (2008). IT Governance Frameworks as Methods. In Proceedings of
the 10th International Conference on Enterprise Information Systems (ICEIS 2008).
June 12-16, Barcelona, Spain 2008. .
Goeken, M., & Alter, S. (2009). Towards Conceptual Metamodeling of IT Governance
Frameworks Approach - Use – Benefits. In Proceedings of the 42nd Hawaii
International Conference on System Sciences .
Goeken, M., Pfeiffer, J.-C., & Johannsen, W. (2009). Linking IT and Business Processes
for Alignment - A Meta Model based Approach. In Proceedings of the 11th
International Conference on Enterprise Information Systems (ICEIS). Milan.
104
Haes, S. de, & van Grembergen, W. (2008). An exploratory Study into the design of an IT
Governance Minimum Baseline through Delphi Research. Communications of the
Association for Information Systems, 22(Article 24), 443a.
Hardy, G. (2006). Using IT governance and COBIT to deliver value with IT and respond to
legal, reulatory and compliance challenges. In Information Security Technical Report
(pp. 55–61).
Heier, H., Borgman, H., & Maistry, M. (2007). Examining the relationship between IT
governance software and business value of IT: evidzence from four case studies. In
HICSS 2007: Proceedings of the 40th Annual Hawaii International Conference on
IT Governance Institute (2007). COBIT 4.1. London
ITGI (2008). IT Governance Global Status Report. London.
KPMG International (2009). KMPG‟s 2009 IT Internal Audit Survey.
Lainhart, J. W. (2000). COBIT: A Methodology for Managing and Controlling Information
and Information technology Risks and Vulnerabilities. Journal of Information Systems,
(14), 21–25.
Larsen, M. H., Pedersen, M. K., & Anderson, K. V. (2006). IT Governance: Reviewing 17
IT Governance Tools and Analysing the Case of Novozymes A/S. In HICSS 2006:
Proceedings of the 39th Annual Hawaii International Conference on System Sciences.
Law, C. C. H., & Ngai, E. W. T. (2009). IT Infrastructure Capabilities and Business
Process Improvements: Association with IT Governance Characteristics. In G. Kelley
(Ed.), Selected Readings on Information Technology Management: Contemporary
Issues.
Lunardi, G. Lerch, Becker, J. Luiz, & Macada, A. C.G. (2009). The Financial Impact of IT
Governance Mechanisms' Adoption: An Empirical Analysis with Brazilian Firms. In
Sciences.
Mingers, J. (2001). Combining IS Research Methods: Towards a Pluralist Methodology.
Information Systems Research, 12(3), 240–259.
Mishra, S., & Weistroffer, H. R. (2007). A Framework for integrating Sarbanes-Oxley
Compliance into the Systems Development Process. Communications of the Association
for Information Systems, 20, 712–727.
PWC (2006). IT Governance in Practice - Insight from leading CIOs.
PricewaterhouseCoopers Johannesburg, South Africa, IT Governance Institute Rolling
Meadows, USA.
Reich, B. Homer, & Benbasat, I. (2004). Measuring the linkage between business and
information technology objectives. MIS Quarterly, 28(1), 75–105.
105
Schütte, R., & Rotthowe, T. (1998). The Guidelines of Modeling - An Approach to
Enhance the Quality in Information Models. In ER ‟98: Proceedings of the 17th
International Conference on Conceptual Modeling (pp. 240‐ 254). London, UK:
Springer-Verlag.
Simonsson, M., & Johnson, P. (2008). The IT Organization Modeling and Assessment
Tool: Correlating IT Governance Maturity with the Effect of IT. In HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences
(p. 431). Washington, DC, USA: IEEE Computer Society.
Siviy, J., Kirwan, P., Marino, L., & Morley, J. (2008a). Maximizing your Process
Improvement ROI through Harmonization (White Paper SEI). Software Engineering
Institute.
Siviy, J., Kirwan, P., Marino, L., & Morley, J. (2008b). The Value of Harmonizing Multiple
Improvement Technologies: A Process Improvement Professional‟s View (White Paper
SEI). Software Engineering Institute.
Sujitparapitaya, S., Janz Brian D., & Gillenson, M. (2003). The Contribution of IT
Governance Solutions to the Implementation of Data Warehouse Practice. Journal of
Database Management, Apr-Jun2003, Vol. 14 Issue 2, 14(2).
Tuttle, B., & Vandervelde, S. D. (2007). An empirical examination of COBIT as an internal
control framework for information technology. International Journal of Accounting
Information Systems, 8, 240–263.
Webb, P., Pollard, C., & Ridley, G. (2006). Attempting to Define IT Governance: Wisdom
or Folly? In HICSS ‟06: Proceedings of the 39th Annual Hawaii International
Conference on System Sciences (pp. 194.1). Washington, DC, USA: IEEE Computer
Society.
Weill, P., & Ross, J. (2004). IT-Governance-How top performers manage IT decision rights
for superior results. Boston, USA.
Willson, P., & Pollard, C. (2009). Exploring IT Governance in Theory and Practice in a
Large Multi-National Organisation in Australia. Information Systems Management, 26,
98–109.
Winter, R., & Schelp, J. (2006). Reference modelling and method construction: a design
science perspective. In Proceedings of the 2006 ACM symposium on Applied Computing
(pp. 1561–1562). Dijon, France.
106
Zwischenfazit Teil C
Ziel dieses Teils war es, die im Rahmen der Forschungsarbeit für Fachbeitrag 4
aufgeworfenen Fragen bezüglich der Anwendung von BPRM zu beantworten. Hierfür
wurden
Daten
aus
qualitativen
Experteninterviews
mit
vorhandenen
Forschungsergebnissen kombiniert. Dies geschah mit der Absicht, die Anwendung von
BPRM zu systematisieren und die die Anwendung konstituierenden Dimensionen in
einem Ordnungsrahmen darzustellen.
Der in Fachbeitrag 5 vorgestellte Ordnungsrahmen beinhaltet Dimensionen, die jeweils
verschiedene Ausprägungen haben können. Ähnlich einem morphologischen Kasten
ergeben
sich
aus
Tupeln
von
Dimensionsausprägungen
verschiedene
Anwendungsformen. Diese Anwendungsformen sowie die bis dahin gesammelten
Erkenntnisse zur Anwendung von BPRM sind die Grundlage für die nun zu
entwickelnde Methode zur Anwendung von BPRM.
Die in Fachbeitrag 5 verwendeten qualitativen Ergebnisse stammen aus einer Studie mit
12 Experteninterviews. Die Studie hatte ursprünglich zum Ziel den Umgang von
Unternehmen mit der Multi-Modell-Umgebung zu erheben. Im Verlauf der Interviews
wurde jedoch festgestellt, dass die ausgewählte Erhebungsmethode für den MultiModell-Fall ungeeignet war. Obwohl die Erhebungsmethode insbesondere aufgrund
ihres freien Erhebungsdesigns ausgewählt worden war und sich für die Befragung von
Experten unterschiedlichen Erfahrungsniveaus eignet. Für den Multi-Modell-Fall ließen
sich die Ergebnisse jedoch nicht wie geplant durch eine qualitative Inhaltsanalyse
auswerten. Im ersten Teil des leitfadengestützten Experteninterviews wurden jedoch
Fragen zur grundsätzlichen Anwendung von BPRM gestellt. Diese Ergebnisse konnten
für Fachbeitrag 5, in Form der verwendeten Zitate, verwertet werden. Ebenso konnten
die Ergebnisse für die Erweiterung des Methoden-Engineerings verwendet werden, die
im übernächsten Teil präsentiert wird.
107
Teil D: Methode zur Anpassung und Anwendung von BestPractice-Referenzmodellen
Vorbemerkungen Teil D
Die Gründe für das Fehlen einer methodischen Unterstützung der Anwendung und die
Auswirkungen des unsystematischen Einsatzes von BPRM wurden bereits erläutert.
Ziel dieses Teils ist nun die Entwicklung einer Methode für die Anpassung und
Anwendung von BPRM. Bisher existieren keine vergleichbaren wissenschaftlichen
Ansätze, Konzepte oder gar Methoden. Lediglich einige wenige kommerzielle Anbieter
und Unternehmensberatungsgesellschaften bieten Konzepte zur strukturierten
Anwendung einzelner BPRM an. Ziel dieses Teils ist es daher, unter Zuhilfenahme
etablierter Forschungsergebnisse aus dem Methoden-Engineering und der
Referenzmodellierung eine Methode für die Anwendung von BPRM zu entwickeln.
Die entwickelte Methode wird ausführlich in Fachbeitrag 6 erläutert, außerdem zeigt der
Fachbeitrag die Anwendung der Methode für das BPRM COBIT und beinhaltet
Arbeitsergebnisse aus dem bereits erwähnten SemGoRiCo-Projekt. Fachbeitrag 7 ist
eine erste Auskopplung aus dem umfassenderen Fachbeitrag 6. Da Fachbeitrag 6 bei der
Auskopplung von Fachbeitrag 7 noch nicht vollständig abgeschlossen war, gibt es
einige Diskrepanzen zwischen den Fachbeiträgen. Hier sei betont, dass die Erkenntnisse
des sechsten Fachbeitrags aktueller sind.
TEILGEBIET: METHODE
Anwendung von BPRM
FachFachbeitrag 7
beitrag 6
Abbildung 11: Darstellung Teil D: Methode zur Anwendung von Best-Practice-Referenzmodellen
im Ein-Modell-Fall
108
Fachbeitrag 6:
Methode zur Anpassung und Anwendung von Best-Practice-Referenzmodellen der
IT-Governance
Status: unveröffentlicht
Vorbemerkungen zum Layout dieses Fachbeitrags:
Aufgrund seines Umfangs hat der folgende Fachbeitrag ein separates Inhaltsverzeichnis.
Die Seitenzahlen dieses Inhaltsverzeichnisses entsprechen jedoch der Übersichtlichkeit
halber den fortlaufenden Seitenzahlen der Dissertation. Ebenso wurde mit den Fußnoten
verfahren. Dies verhindert Dopplungen und erleichtert die Auffindbarkeit bei
Querverweisen innerhalb der Arbeit.
109
METHODE ZUR ANPASSUNG UND ANWENDUNG VON
BEST-PRACTICE-REFERENZMODELLEN DER IT-GOVERNANCE
1 Problemdefinition und Forschungsmotivation .................................................. 111
2 Forschungsdesign ................................................................................................. 111
3 Anpassung und Anwendung von Best-Practice-Referenzmodellen ................ 114
4 Methodenkonstruktion ........................................................................................ 118
4.1 Der Forschungsbereich Methoden-Engineering ............................................ 118
4.2 Methodenelemente .......................................................................................... 120
5 Entwicklung einer Methode zur Anpassung und Anwendung von BPRM .... 124
5.1 Vorüberlegungen ............................................................................................ 124
5.2 Methodenelemente: Ergebnis und Metamodell .............................................. 124
5.3 Methodenelement: Aktivität ............................................................................ 130
5.3.1 Vorüberlegungen ..................................................................................... 130
5.3.2 Aktivitäten der Modellanpassung ............................................................ 132
5.3.2.1 Aktivität: Modellbereichsauswahl .................................................... 132
5.3.2.2 Aktivität: Modellvariation ................................................................ 139
5.3.2.3 Aktivität: Modellerweiterung ........................................................... 141
5.3.3 Aktivitäten der Modellanwendung ........................................................... 144
5.3.3.1 Aktivität: Vergleich .......................................................................... 144
5.3.3.2 Aktivität: Gestaltung ......................................................................... 147
5.4 Methodenelement: Technik............................................................................. 149
5.5 Methodenkonfiguration .................................................................................. 153
5.6 Zwischenfazit .................................................................................................. 158
6 Methode zur Anpassung und Anwendung des BPRM COBIT ....................... 158
6.1 Vorüberlegungen ............................................................................................ 158
6.2 Ergebnisse der spezifischen Methode für COBIT .......................................... 159
6.3 Aktivitäten der spezifischen Methode für COBIT ........................................... 162
6.3.1 Aktivitäten der COBIT-Anpassung .......................................................... 162
6.3.1.1 COBIT-Modellbereichsauswahl ....................................................... 162
6.3.1.2 COBIT-Modellvariation ................................................................... 172
6.3.1.3 COBIT-Modellerweiterung .............................................................. 177
6.3.2 Aktivitäten der COBIT-Anwendung ......................................................... 181
6.3.2.1 COBIT-Aktivität: Vergleich .............................................................. 181
6.3.2.2 COBIT-Aktivität: Gestaltung ............................................................ 183
6.4 Zwischenfazit .................................................................................................. 183
7 Methode zur Anpassung und Anwendung von CMMI .................................... 184
8 Kritische Würdigung ........................................................................................... 189
9 Fazit ....................................................................................................................... 197
Literaturverzeichnis ................................................................................................ 198
110
1 Problemdefinition und Forschungsmotivation
Die Zahl der Unternehmen, die Best-Practice-Referenzmodelle (BPRM)127 der ITGovernance einsetzen, steigt kontinuierlich an.128 Der steigenden Nutzung in der Praxis
steht eine sehr geringe Anzahl wissenschaftlicher Erkenntnisse gegenüber. Die wenigen
vorhandenen Quellen zur Anwendung von BPRM zeigen zwar die positive Wirkung des
Einsatzes von (angepassten) BPRM in der Praxis auf, die konkrete Ausgestaltung von
Anpassung und Anwendung bleibt jedoch zumeist offen.129 Dies liegt nach Ansicht der
Verfasserin vor allem darin begründet, dass BPRM originär aus der Praxis stammen und
daher theoretische Grundlagenarbeiten fehlen. Aufgrund der fehlenden systematischen
Beschreibung kann die Anpassung und Anwendung von BPRM nur schwer in den
wissenschaftlichen Erkenntnisprozess integriert werden und die Anzahl der verfügbaren
wissenschaftlichen Publikationen steigt unterproportional zur praktischen Relevanz von
BPRM. Die Anpassung an die Unternehmensumstände sowie die Anwendung von
(angepassten) BPRM ist daher zunächst systematisch zu beschreiben. Als Grundlage für
weitere Forschung unterstützt eine solche Beschreibung mittelbar den praktischen
Einsatz von BPRM.
Unmittelbar kann der praktische Einsatz von BPRM durch direkt anwendbare Methoden
unterstützt werden. Solche Methoden bestehen, wie im weiteren Verlauf detailliert
beschrieben, u.a. aus einer Abfolge von Aktivitäten, korrespondierenden Ergebnissen
und Techniken. Da die Entwicklung von Methoden ebenfalls auf Grundlagenarbeiten
basiert, liegen auch hier wenige Erkenntnisse vor.
Da die Unterstützung der Praxis im Fokus einer anwendungsorientierten Wissenschaft
wie der Wirtschaftsinformatik steht, ergibt sich hieraus das Gestaltungsziel dieses
Forschungsvorhabens: Entwicklung einer Methode zur Unterstützung der Anpassung
und Anwendung von BPRM. Dieses Gestaltungsziel ist jedoch zweigeteilt. Zunächst
werden die möglichen Aktivitäten, Ergebnisse und Techniken generisch beschrieben
und so theoretisch aufgearbeitet und systematisiert. Weiterhin wird auf Grundlage der
erzielten generischen Erkenntnisse eine spezielle Methode für das BPRM COBIT
entwickelt. Die für COBIT konkretisierte Methode wird durch die Verwendung von
Forschungsergebnissen aus dem SemGoRiCo-Projekt130 gezielt für die Praxis zugänglich
gemacht.
2 Forschungsdesign
Die Entwicklung einer Methode zur Anpassung und Anwendung von BPRM ist ein
konstruktionsorientiertes Forschungsvorhaben. Konstruktionsorientierte Forschung
sollte ebenso wie empirische Forschung einem möglichst strikten Ablauf folgen. Peffers
et al. beschreiben einen idealtypischen Forschungsablauf auf Grundlage verschiedener
127
Für eine detaillierte Begriffsherleitung siehe Kapitel 2, Looso 2010b und Teil 1 der vorliegenden
Dissertation.
128 KPMG September 2004; Fröhlich, Glasner 2007; IT Governance Institute 2006, IT Governance
Institute 2008.
129 Siehe u.a. Wagner 2006; Tuttle, Vandervelde 2007; Heier et al. 2007, 2008, 2009 oder Larsen et al.
2006.
130 Dieses Projekt (HA-Projekt-Nr.: 160/08-22) wird im Rahmen der Innovationsförderung gefördert,
finanziert aus Mitteln der hessischen LOEWE - Landes-Offensive zur Entwicklung Wissenschaftlichökonomischer Exzellenz, Förderlinie 3: KMU-Verbundvorhaben.
111
wissenschaftstheoretischer Publikationen der Design-Science-Forschung und
extrahieren so den in Abbildung 12 skizzierten Ablauf.131
Ihrem Ansatz folgend beginnt ein Forschungsvorhaben mit der Identifikation eines
Problems und der resultierenden Forschungsmotivation. Im nächsten Schritt werden die
Ziele der angestrebten Lösung abgeleitet. Im Anschluss daran wird das Artefakt
entwickelt, angewendet und evaluiert. Diese drei Schritte stehen jeweils in engem
Zusammenhang zu den vorher definierten Zielen. Am Ende steht die Kommunikation
der Ergebnisse.
Kapitel 1
Problemidentifikation &
Motivation
Kapitel 3 & 4
Ableitung der Ziele der
angestrebten Lösung
Kapitel 5
Entwicklung des
generischen Artefakts
Anwendung des
generischen Artefakts zur
Konstruktion des
spezifischen Artefakts
Kapitel 6
Kapitel 7
Evaluation
Kommunikation
Abbildung 12 Forschungsdesign in Anlehnung an Peffers et al. (2008)
Das hier vorliegende konstruktionsorientierte Forschungsvorhaben folgt diesem
Ablauf.132 Kapitel 1 beinhaltet Problemidentifikation und Motivation. Kapitel 3 und 4
zeigen auf, welche Anforderungen eine Methode zur Anpassung und Anwendung von
BPRM erfüllen soll und welche bereits vorhandenen Forschungsergebnisse verwendet
werden können. Hier wird deutlich, dass das Gestaltungsziel Aspekte verschiedener
Forschungsbereiche beinhaltet. Zunächst sind BPRM zu beschreiben. Hierbei ist
insbesondere der Vergleich mit anderen Referenzmodellen der Wirtschaftsinformatik
relevant, da dies für die Übertragbarkeit von Forschungsergebnissen aus der
Referenzmodellforschung auf BPRM bedeutsam ist (Kapitel 3). Weiterhin ist es für die
131
Peffers et al. 2008 verwenden u.a. die Erkenntnisse von Archer; Takeda et al. 1990; Eekels 1991;
Nunamaker et al. 1990 und Hevner et al. 2004.
132 Peffers et al. 2008.
112
Entwicklung einer Methode notwendig, Erkenntnisse aus dem Forschungsgebiet
Methodenkonstruktion (Kapitel 4) zu verwenden. Ziel des vierten Kapitels ist es daher,
die konstituierenden Elemente einer Methode zu identifizieren. Eine solche
Bezugnahme auf vorhandene Theorie schlagen neben Peffers et al. bspw. auch Hevner
et al.133 vor.
Kapitel 5 und 6 beschreiben die Entwicklung des zweiteiligen Artefakts. Aufgrund der
in Kapitel 3 thematisierten Ähnlichkeiten zwischen den unterschiedlichen BPRM ist es
sinnvoll ein allgemeingültiges Artefakt, d.h. eine für alle BPRM anwendbare Methode
zu entwickeln. Die individuellen Besonderheiten der verschiedenen BPRM wären in
einer solchen Methode jedoch nicht abzubilden. Daher wird in diesem Beitrag zwischen
generischem und spezifischem Artefakt unterschieden. Die generische Methode kann
von Fall zu Fall auf die spezifischen Besonderheiten eines BPRM angepasst werden.
Aus der Anwendung der generischen Methode auf ein konkretes BPRM resultiert also
ein spezifisches Artefakt. Erst die abgeleiteten konkreten Methoden sind zur
Anwendung in der Praxis geeignet.
Abbildung 13 zeigt, dass eine solche Unterteilung auch im Ordnungsrahmen der
konstruktionsorientierten Forschung nach Hevner et al. thematisiert wird. In der
Systematik von Hevner et al. ist die generische Methode ein Beitrag zur Wissensbasis
der IT-Governance-Forschung, wohingegen die spezifische Methode einen Beitrag für
das IT-Governance-Umfeld darstellt.
IT-GovernanceUmfeld
Forschung
Wissensbasis
IT-Governance-Modelle
IT-Ziele
Referenzmodellierung
Praktische
Anforderungen
Methodenkonstruktion
Anwendbares
Wissen
Methodenkonstruktion
Compliance
Modellierung
vorhandene IT-Strukturen
Metamodellierung
...
Spezifische
Methode für ein
konkretes
BPRM
Anwendung im IT-Governance-Umfeld
Instanz von
Generische
Methode
...
Beitrag zur Wissensbasis
Abbildung 13 Einflüsse und Ergebnisse des Forschungsprozesses (In Anlehnung an Hevner et al. 2004).
Kapitel 5 beinhaltet die Entwicklung des generischen Artefakts. Die einzelnen
generischen Methodenelemente werden detailliert hergeleitet und einander zugeordnet.
Die Entwicklung erfolgt unter Bezugnahme auf die konstituierenden Elemente einer
Methode und die Mechanismen der Referenzmodelladaption. Die Aktivitäten und
Ergebnisse der Methode sind eine Anordnung aller logisch möglichen Aktivitäten und
Ergebnisse der Anpassung und Anwendung von BPRM. Die Methodenentwicklung
inkludiert daher in Teilen bereits eine systematische Beschreibung des
133
Hevner et al. 2004.
113
Forschungsgegenstandes. Aus der logisch-deduktiven Ableitung der Methodenelemente
resultiert daher zusätzlich eine Systematik der Anpassung und Anwendung von BPRM.
Kapitel 6 beschäftigt sich mit der Anwendbarkeit des entwickelten Artefakts auf einen
konkreten Fall. Die generische Methode wird auf das konkrete BPRM COBIT
angepasst, so dass eine spezifische COBIT-Methode entsteht. Die aus der generischen
Methode abgeleitete spezifische Methode für das BPRM COBIT wird mit Bezug auf ein
am IT-Governance-Practice-Network durchgeführtes Forschungsprojekt erstellt.
Da das generische Artefakt dem Anspruch der Allgemeingültigkeit genügen soll, ist es
nicht ausreichend dessen Anwendbarkeit nur am Beispiel COBIT zu demonstrieren.
Zusätzlich zur ausführlichen Anwendung auf das BPRM COBIT wird die generische
Methode daher exemplarisch für das BPRM CMMI konkretisiert (Kapitel 7). Die Frage,
inwieweit sich hierdurch die Allgemeingültigkeit des Artefakts nachweisen lässt und
weitere Fragen der Evaluation und kritischen Würdigung werden in Kapitel 8 diskutiert,
bevor in Kapitel 9 ein abschließendes Fazit gezogen wird.
3 Anpassung und Anwendung von Best-Practice-Referenzmodellen
Unabhängig von ihrem originären Zweck werden Modelle wie COBIT, ITIL oder
CMMI verstärkt als Möglichkeit der Unterstützung des IT-Managements betrachtet.134
In einigen Quellen werden diese Modelle daher als Referenzmodelle betrachtet, die
eingesetzt werden können, um unternehmensspezifische Modelle im Rahmen der ITGovernance abzuleiten. Es ist nun fraglich, ob Modelle wie COBIT oder ITIL zu Recht
als Referenzmodelle bezeichnet werden, und ob sich Forschungsergebnisse aus der
Referenzmodellforschung135 auf den hier vorliegenden Forschungsgegenstand
übertragen lassen.
Fettke & Loos nehmen eine umfassende Systematisierung des Forschungsbereichs
Referenzmodellierung vor.136 Für den Bereich Referenzmodelle137 stellen sie fest, dass
zahlreiche Referenzmodelle existieren, die sich unter anderem anhand ihrer
Anwendungsdomäne138, der verwendeten Sprache139, oder ihrer Größe unterscheiden
lassen. Trotz ihrer unterschiedlichen Natur ist ihnen jedoch gemein, als Referenz für
Goeken, Alter 2008, S. 1 sprechen von „frameworks as methods―. Besonders deutlich wird diese
Entwicklung am Beispiel der Control Objectives for Information and related Technology (COBIT),
welche nicht mehr nur ausschließlich von Wirtschaftsprüfern für ex-post-IT-Prüfungen eingesetzt,
sondern immer häufiger zur Unterstützung des Managements verwendet werden. Dies verdeutlicht auch
der momentane Entwurf von COBIT 5. Hier wird das Ziel verfolgt COBIT für das IT-Management zu
nutzen: „[…] align with the latest management practices as well as strengthening areas such as decision
making, organisational structures, skill requirements, human factors, culture and change enablement.―
(COBIT 5, DRAFT, S. 7).
135 Einige Forschungsgruppen, insbesondere die Forschungsgruppe der WWU Münster, verwenden den
Begriff Referenzmodellierungsforschung. In diesem Beitrag wird jedoch der Begriff
Referenzmodellforschung verwendet, da der Fokus der Betrachtung nicht auf den Prozessen der
Referenzmodellierung liegt.
136 Siehe Fettke, Loos 2004.
137 Daneben stehen Referenzmodellierungssprachen, Referenzmodellierungsmethoden und der Kontext
der Referenzmodellierung.
138 Bspw. Industrie: Scholz-Reiter 1990, Mertens, Holzner 1992; Handel: Becker, Schütte 2004,
Gesundheitswesen: Simoneit 1998; Führungsinformationssysteme: Goeken 2002; Finanzdienstleistung:
Bauer 1998; Gerber, Mai 2002; Qualitätsmanagement: Hoffmann 1999; sowie die bei Fettke, Loos 2004,
S. 5 zusätzlich genannten Beispiele.
139 ERM, EPK, Funktionsbäume, UML und andere.
134
114
andere Modelle zu gelten.140 Sie werden als Vorbild für ein Unternehmensmodell
betrachtet, das aktuelles Wissen (state-of-the-art knowledge) und Best-Practice-Wissen
semi-formal darstellt.141
Eben solches Best-Practice-Wissen enthalten die hier im Fokus stehenden Modelle der
IT-Governance.142 Sie werden von Praktikern (mit-)erstellt, enthalten fundiertes und
konsolidiertes Erfahrungswissen des Bereichs IT-Governance und haben die Tendenz,
sich zu Quasi-Standards zu entwickeln.143 Best-Practice-Modelle der IT-Governance
können demnach grundsätzlich als Referenzmodelle verstanden werden und sind im
Folgenden definiert als:
„Eine semi-formale Sammlung von konsolidiertem und legitimiertem Wissen einer
Domäne, die durch aktive Konsensbildung der organisierten relevanten Subjekte
entstanden ist.―144
Wesentlich für ein BPRM ist also die Entstehung durch den Konsens der beteiligten
Subjekte und die Legitimation durch eine Organisation. BPRM sind demnach
Referenzmodelle, die nicht bereits durch Deklaration oder Akzeptanz zur Referenz
werden,145 sondern erst durch die gezielte Legitimation durch eine Organisation.146
Da BPRM also grundsätzlich Referenzmodelle sind, können spezifische Erkenntnisse
bezüglich der Anpassung und Anwendung von Referenzmodellen auch im Kontext von
BPRM Verwendung finden. Ziel des folgenden Abschnitts ist es daher,
Forschungsergebnisse vorzustellen, die im Verlauf dieses Beitrags verwendet werden.
Die Adaption von Referenzmodellen wird in der Referenzmodellforschung zumeist als
Referenzmodellanwendung bezeichnet.147 Für den hier vorliegenden Beitrag ist es
jedoch notwendig, zwischen Referenzmodellanpassung und Referenzmodellanwendung
zu unterscheiden (siehe Kapitel 5.3.1). Eine Möglichkeit hierfür bietet das Verständnis
der Anwendung von Referenzmodellen von Fettke & Loos. Sie unterteilen die
Referenzmodellierung in zwei Prozesse.148 Erstens, die Konstruktion von
Referenzmodellen und zweitens die Konstruktion von unternehmensspezifischen
Informationsmodellen auf Basis von Referenzmodellen, was sie als Anwendung von
Referenzmodellen bezeichnen. Zwischen diesen beiden Prozessen beschreiben Fettke &
Loos das Problem der Wiederverwendung. Dies bezeichnen sie als Schnittstelle
zwischen den zeitlich getrennten Prozessen Referenzmodellkonstruktion und
Referenzmodellanwendung. Die Wiederverwendung wird in die vier Unterprozesse
Hars bemerkt „Bei einem Referenzmodell handelt es sich um ein Modell, das für den Entwurf anderer
Modelle herangezogen werden kann― (Hars 1994, S.15). Siehe außerdem Becker 1995; Frank 1999;
Scheer et al. 2002; Goeken 2002; Becker 2004 oder Loos, Fettke 2005.
141 Siehe Fettke, Loos 2003 und Rosemann, van der Aalst 2007; Schwegmann 1999, S.1.
142 Beispiele für diesen sehr weit gefassten Begriff sind: COBIT IT Governance Institute 2007; CMMI
Software Engineering Institute 2007 oder ITIL OGC 2007a-e.
143 Dies zeigt sich vor allem durch die steigenden Nutzerzahlen in den unterschiedlichsten Branchen,
siehe KPMG September 2004 und KPMG 2009.
144 Für eine ausführliche Herleitung des Begriffs siehe Teil Ader vorliegenden Dissertation.
145 Siehe vom Brocke 2003 oder Schwegmann 1999, S. 61.
146 Eine solche Organisation ist beispielsweise der Berufsverband der praxisorientierten InformationSystems-Fachleute (ISACA) für das BPRM COBIT, das Software Engineering Institute (SEI), welches
seit 1987 CMMI verantwortet oder das Office of Government Commerce (OGC) und das ITServicemanagement-Forum (ITSMF) für ITIL.
147 Siehe u.a. Thomas, Adam 2003, S. 243 und vom Brocke 2003. Es ist jedoch anzumerken, dass der hier
verwendete Begriff „Konsens der beteiligten Subjekte― und der bspw. von vom Brocke verwendete
Begriff Akzeptanz Überschneidungen aufweisen.
148 Siehe Fettke, Loos 2002.
140
115
Wiederverwendbarkeitsentwurf, Wiederauffindung, Anpassung sowie Evaluation
untergliedert (Abbildung 14). Sie unterscheiden demnach auch zwischen Anpassung
(als Teil der Wiederverwendung) und der im dem Begriff „spezifische
Modellkonstruktion― bezeichneten Anwendung von Referenzmodellen.
Abbildung 14 Prozess der Wiederverwendung von Referenzmodellen und sein Kontext
[nach Fettke, Loos 2002, S. 15]
Für die Wiederverwendung vermuten sie unter Verwendung von Ergebnissen aus dem
Software-Engineering, dass die Wiederverwendung von Referenzmodellen dann
besonders erfolgreich ist, wenn sie nicht ad-hoc, sondern systematisch durch Methoden
unterstützt erfolgt.149 Sie betonen, dass zur Verwirklichung des Leitbildes der
Referenzmodellierung Methoden benötigt werden, die die systematische
Wiederverwendung ermöglichen.150 In diesem Zusammenhang betonen Becker et al.:
„der Förderung der Wirtschaftlichkeit der Referenzmodellanwendung durch gezielte
methodische Unterstützung des Adaptionsprozesses kommt eine besondere Bedeutung
zu.―151 Jedoch beinhalten nur wenige Referenzmodelle explizite methodische Hinweise,
wie sie in bestimmten Anwendungsgebieten verwendet werden können.152
Für den hier relevanten Teil der Wiederverwendung, die Anpassung des
Referenzmodells an die unternehmensspezifische Situation, nennen Fettke & Loos zwei
Maßnahmenkategorien, namentlich kompositorische und generische Maßnahmen.
Erstere umfassen Maßnahmen, die einzelne Bereiche des Modells löschen, verändern
oder ergänzen.153 Generische Maßnahmen beschreiben sie hingegen als Maßnahmen, bei
denen explizit beschriebene Möglichkeiten der Anpassung durchgeführt werden. Dazu
gehört etwa das regelgeleitete Anpassen eines Modells auf Basis von
Unternehmensmerkmalen.154 Weiterhin bezeichnen die Autoren auch das Füllen von
vordefinierten Platzhaltern als eine generische Maßnahme.155 Beide Maßnahmenarten
149
Siehe Fettke, Loos 2002, S. 3 sowie die dort genannten Quellen.
Fettke, Loos 2002, S. 1.
151 Becker et al. 2004, S. 252.
152 Siehe Fettke, Loos 2004, S. 5.
153 Schütte spricht ebenfalls von kompositorischen Maßnahmen und charakterisiert sie dadurch, dass diese
Maßnahmen vom Konstrukteur des Modells nicht vorgedacht wurden. Dieser Charakterisierung
widersprechen jedoch Fettke, Loos 2002.
154 Siehe auch Schütte 1998.
155 Hier referenzieren sie auf das Modell von Remme 1997.
150
116
sind für die hier vorliegende Fragestellung relevant und werden daher für BPRM
spezifiziert.
Das Modell von Hars beschreibt u.a. die Anpassung von Referenzmodellen. Er
unterscheidet prinzipiell drei Möglichkeiten der Anpassung: 1. Löschung: Knoten und
Kanten können gelöscht werden. 2. Modifikation: Knoten und Kanten können verändert
werden. 3. Ergänzung: Knoten und Kanten können hinzugefügt werden.156 Diese
Systematik ist generisch genug um auch im Rahmen der Anpassung von BPRM
Verwendung zu finden. Es ist an gegebener Stelle jedoch zu diskutieren, ob diese
Systematik ausreicht, oder ob sie weiter verfeinert werden muss.
Ebenfalls können die Erkenntnisse von Remme Anwendung finden.157 Sein Modell sieht
vor, dass Prozessbausteine durch kompositorische Wiederverwendung angepasst
werden. Hierbei wird etwa deren Reihenfolge verändert. Zusätzlich sieht er vor, dass
Platzhalter zum Zeitpunkt der Anpassung instanziiert werden.
Wolf nennt die Wiederverwendung eine Kommunikationssituation zwischen
menschlichen Akteuren und betont, dass diese nicht ausschließlich durch formalwissenschaftliche Methoden gestaltet werden kann. Die Schwierigkeit liegt
insbesondere darin, dass Referenzmodellanwender und -konstrukteur in der Regel keine
Kenntnis voneinander haben. Wolf schlägt daher vor, Modellzweck, -kontext,
Problemstruktur und Konstruktionsaspekte neben der eigentlichen Modellrepräsentation
zu dokumentieren. Mithilfe dieser Informationen soll die Wiederverwendung erleichtert
werden.158 Wolfs Ansatz setzt also bereits bei der Konstruktion von Referenzmodellen
an und ist im Kontext von bestehenden BPRM nur in Ansätzen zu verwenden.
Weitere Forschungsergebnisse zur Systematisierung der Adaption von Referenzmodellen zeigen Becker et al.159 Ihr Ansatz beschäftigt sich mit der Konstruktion von
Referenzmodellierungssprachen,
ordnet
jedoch
zuvor
die
möglichen
160
Adaptionsmechanismen, da die Anpassung eines Referenzmodells nach ihrer Ansicht
bereits bei dessen Entwicklung berücksichtigt werden sollte.
Der Ordnungsrahmen von Becker et al. beinhaltet drei Dimensionen:
 Modellebenen
 Mechanismen der generierenden Adaption
 Mechanismen der nicht-generierenden Adaption
Die erste Dimension unterscheiden Becker et al. in drei Ebenen. Die Modellebene, die
Metamodellebene und die Meta-Metamodellebene. Die Modelle der jeweils
übergeordneten Ebene beschreiben die Sprache der Modelle der untergeordneten
Ebene.161
Die zweite Dimension des Ordnungsrahmens sind die Mechanismen der generierenden
Adaption:
 Modelltypselektion
 Elementtypselektion
 Elementselektion
156
Fettke, Loos 2002 zitieren Hars 1994, S. 144ff.
Remme 1997.
158 Wolf 2001, S. 107ff.
159 Siehe Becker et al. 2004. Auch vom Brocke 2003 beschreibt diese Mechanismen, charakterisiert und
unterscheidet sie jedoch anhand anderer Dimensionen.
160 Sie sprechen von Anwendung. Aufgrund der Unterscheidung zwischen Anpassung und Anwendung
wird hier von Anpassung gesprochen.
161 Siehe Becker et al. 2004, S. 253.
157
117
 Bezeichnungsvariation
 Darstellungsvariation
Diese Mechanismen lassen sich unter dem Begriff Konfiguration162 zusammenfassen.
Eine Konfiguration ist laut Becker et al. jedoch nur dann möglich, wenn das
Referenzmodell explizite Regeln enthält, die festlegen „wie das Referenzmodell in
Abhängigkeit von aktuellen Konfigurationsparameterausprägungen anzupassen ist―.163
Angewendet auf den hier vorliegenden Fall bedeutet das, dass Adaption durch
Konfiguration nur möglich ist, wenn ein BPRM explizite Regeln für seine Anpassung
an externe Parameter enthält. Im Verlauf dieses Beitrags wird jedoch argumentiert, dass
auch implizite Regeln eine Konfiguration ermöglichen.
Die dritte Dimension des Ordnungsrahmens sind die Mechanismen der nichtgenerierenden Adaption:
 Aggregation
 Instanziierung
 Spezialisierung
 Analogiekonstruktion
Diese vier Adaptionsmechanismen verlangen keine expliziten Regeln im
Referenzmodell und werden im Ordnungsrahmen von Becker et al. orthogonal zu den
Mechanismen der generierenden Adaption dargestellt.164
Der soeben vorgestellte Ansatz von Becker et al. wurde für den vorliegenden Beitrag als
Referenzwerk für die Aspekte der Modellanpassung ausgewählt. Für die Entwicklung
der Methode werden daher immer wieder Analogien des Forschungsgegenstandes zum
Ordnungsrahmen von Becker et al. verwendet. Grund für die Auswahl dieses
Ordnungsrahmens, trotz seines Konstruktionsfokuses, ist sein breiter Ansatz. So wird
auf eine Priorisierung einzelner Adaptionsmechanismen verzichtet. Vielmehr ist es das
Ziel der Autoren, alle Mechanismen der Adaption von Referenzmodellen zu ordnen.165
Daher eignet sich dieser Ordnungsrahmen gut für das hier angestrebte Gestaltungsziel.
Im folgenden Kapitel 4 wird die Methodenkonstruktion thematisiert, denn das
Gestaltungsziel dieses Beitrags, die Entwicklung einer Methode, erfordert die
Benennung der relevanten Methodenelemente.
4 Methodenkonstruktion
4.1 Der Forschungsbereich Methoden-Engineering
Die Erstellung von Informationssystemen erfordert ein ingenieurmäßiges und
zielorientiertes Vorgehen. In der Wirtschaftsinformatik-Literatur herrscht weitgehend
Einigkeit darüber, dass die Verwendung von Methoden die Basis für ein solches
162
Dieser Mechanismus ist ein in der Referenzmodellforschung oft thematisierter Mechanismus. Einen
guten Überblick über die Methoden zur Referenzmodellierung bietet vom Brocke 2003, S. 100.
163 Siehe auch Schütte 1998 und Schwegmann 1999.
164 Andere Modelle der Anwendung von Referenzmodellen sehen die Konfiguration hingegen nicht
orthogonal zu den Mechanismen der nicht-generierenden Adaption. Ein Beispiel ist vom Brocke 2003, er
beschreibt ebenfalls die fünf generellen Möglichkeiten der Referenzmodellanwendung, betrachtet die
Konfiguration jedoch nicht orthogonal zu den anderen vier Adaptionsmechanismen. Er unterscheidet die
Adaptionsmechanismen anhand der Dimensionen Änderbarkeit und Prinzip und unterscheidet dabei drei
Grade der Veränderbarkeit (geplant, begrenzt, frei) und zwei Prinzipien (adaptiv und kompositionell).
118
ingenieurmäßiges Vorgehen darstellt.166 Ein wesentliches, in der Literatur weitgehend
unumstrittenes Merkmal von Methoden ist die Zielorientierung. Nach Stahlknecht &
Hasenkamp, Balzert oder Hesse dient eine Methode der Erreichung festgelegter Ziele.167
Becker beschreibt eine Methode als das systematische Vorgehen beim Lösen von
Problemen. Ein Problem wiederum ist charakterisiert als die Diskrepanz zwischen
einem Ist- und einem Soll-Zustand.168
Die Erstellung von Methoden steht im Fokus des Forschungsbereichs MethodenEngineering. Das Methoden-Engineering ist ein viel diskutiertes und etabliertes
Konzept in der konstruktionsorientierten Wirtschaftsinformatik. Der Forschungsbereich
beschäftigt sich mit der ingenieurmäßigen Entwicklung von Methoden. Brinkkemper
definiert:
„Method Engineering is the engineering discipline to design, construct and adapt
methods, techniques and tools for the development of information systems.“169
Ziel des Forschungsbereichs Methoden-Engineering ist es demnach, Methoden mittels
eines strukturierten Vorgehens zu entwickeln. Methoden selbst sind folglich
Gegenstand der Entwicklung.170
Eine Methode wird dort „als Tupel aus einem Aufgabentyp und einer Menge von
Regeln aufgefasst.―171 Nach Zelewski sind aber nicht alle denkbaren Tupel automatisch
eine Methode. Damit von einer Methode gesprochen werden kann, muss sichergestellt
werden, dass gewisse Qualitätsanforderungen eingehalten werden.172 Zum Beispiel
sollen Methodenelemente und deren Beziehungen eindeutig interpretierbar sein, d.h. es
sollte eine weitgehend einheitliche Methodendokumentation verwendet werden. Eine
solche einheitliche Beschreibung erfordert eine „sprachkritische Rekonstruktion der
Methodenbestandteile―173 und eine formalisierte Dokumentation derselben. Bezüglich
der Methodenelemente ist in der europäischen Wirtschaftsinformatik zurzeit das von der
Universität St. Gallen geprägte Methodenverständnis vorherrschend.174 Deren Ansatz
einer sprachkritischen Konstruktion von Methodenelementen fokussiert die
Ausgestaltung und Abgrenzung der geschaffenen Artefakte. Ziel ist es, die
Methodenelemente möglichst eindeutig und frei von Redundanzen zu beschreiben, um
so eine hohe Qualität der entwickelten Methode zu gewährleisten.
Vor dem Hintergrund des hier verfolgten Gestaltungsziels, einem sprachkritischen
Methodenverständnisses und dem Ziel, eine Methode systematisch nach den
Erkenntnissen des Methoden-Engineerings zu entwickeln, stellt sich daher nun die
Frage, welche Elemente die Methode beinhalten sollte und wie diese entwickelt werden
sollten.175 Die Frage nach den relevanten Methodenelementen ist Teil des folgenden
Unterkapitels.
166
Siehe Braun et al. 2004.
Siehe Stahlknecht, Hasenkamp 2005; Balzert 1998; Hesse et al. 1992.
169 Brinkkemper 1996, S. 276.
170 Für eine Abgrenzung der Begriffe Methode, Vorgehensmodell und Verfahren siehe Goeken 2006, S.
51. Die Begriffe Methode und Prozess unterscheidet Karlsson 2002, S. 48.
171 Becker et al. 2001, S. 5.
172 Siehe Zelewski 1999.
173 Becker et al. 2001, S. 6; im Begriffsverständnis dieser Arbeit sprechen Becker et al. hier von
Methodenelementen (siehe Fußnote 180).
174 Siehe Heym 1993; Gutzwiller 1994; Brinkkemper 1996; Ralyté, Rolland 2001; Karlsson, Wistrand
2006.
175 Welche Forschungsmethoden bislang zur Methodenkonstruktion eingesetzt werden zeigen Becker et
al. 2007.
167
119
Der Entwicklungsprozess ist konstruktionsorientiert, d.h. er basiert nicht auf
empirischen Ergebnissen, sondern folgt dem Prinzip der Design-Science-Forschung.
Die so erzielten Forschungsergebnisse wurden in jüngster Vergangenheit verstärkt
kritisiert.176 Im Zuge der Diskussion um die Wertigkeit von konstruktionsorientierten
Forschungsergebnissen hat sich die Forderung nach deren konsequenter Evaluation
etabliert.177 Die in Kapitel 5 vorgestellten Forschungsergebnisse werden daher im
Verlauf dieses Beitrags kritisch diskutiert und in Teilen evaluiert.
4.2 Methodenelemente
Der für diese Arbeit ausgewählte Ansatz des Methoden-Engineerings ist der bereits
erwähnte St. Gallener Ansatz des Methoden-Engineerings.178 Er beschreibt einen
„systematischen und strukturierten Prozess zur Entwicklung, Modifikation und
Anpassung von Softwareentwicklungsmethoden durch die Beschreibung der
Methodenelemente und ihrer Beziehungen.―179 Das Beschreibungsmodell beinhaltet die
schematische Zusammenstellung der der Methodenelemente Metamodell, Ergebnis,
Aktivität, Technik und Rolle.180 Abbildung 15 zeigt deren Zusammenspiel.
Aktivitäten sind definiert als funktionale Verrichtungseinheiten, die Ergebnisse erstellen
und von Rollen ausgeführt oder verantwortet werden.181 Eine Rolle ist hierbei im St.
Gallener Modell eine Zusammenfassung von Aktivitäten aus der Sicht des
Aufgabenträgers. Nach Gutzwiller entsteht außerdem ein Vorgehensmodell, wenn
Aktivitäten in eine bestimmte Reihenfolge gebracht werden.182 Ergebnisse haben eine
klar definierte Form und werden in definierten und strukturierten Ergebnisdokumenten
erfasst. Das Metamodell spezifiziert das konzeptionelle Datenmodell der Ergebnisse.
Metamodell
Metamodell ist ein
konzeptuelles Modell
der Ergebnisse
Ergebnis
Aktivitäten generieren und
benutzen Ergebnisse
Aktivität
Techniken liefern
Anweisungen für die
Erstellung von Ergebnissen
Rollen führen
Aktivitäten aus und entwerfen sie
Technik
Rolle
Abbildung 15 Methodenbestandteile nach (Heym 1993, S. 13).
Unter Techniken werden detaillierte Anleitungen zur Erstellung von
Ergebnisdokumenten verstanden. Während eine Aktivität ein Ergebnis generiert, liefert
die Technik Anweisungen für die Erstellung eines Ergebnisses. Für die vorliegende
176
Applegate, King 1999; Davenport, Markus 1999; Lee 1999; Lee, Hubona 2009
Siehe Pries-Heje et al. 2008, Hevner et al. 2004 oder in Ansätzen auch Becker, Niehaves 2006 und
Kuechler, Vaishnavi 2007.
178 Basiert auf den Ergebnissen von Heym 1993; Gutzwiller 1994 und Becker 1998.
179 Heym 1993, S. 5.
180 Dieses Beschreibungsmodell erfüllt die Anforderungen eines Metamodells der Methode, die konkreten
Methodenelemente (bspw. eine konkrete Aktivität) ist demnach eine Instanz des Metamodellelements
Aktivität. Im Verlauf dieses Beitrags wird der Begriff Methodenbestandteil für die Elemente des
Beschreibungsmodells verwendet, der Begriff Methodenelement bezeichnet eine konkrete Instanz.
181 Eine solche Beziehung zwischen Aktivitäten und Ergebnissen beschreiben auch Jablonski et al. 1997;
Goeken 2006 oder Baumöl 2006.
182 Siehe Gutzwiller 1994 und Heym 1993, S. 13.
177
120
Arbeit wurde eine Fusion der Elemente Technik und Aktivität erwogen. Eine Fusion ist
aufgrund der fehlenden 1:1-Zuordnung der Elemente jedoch nicht sinnvoll.
Insbesondere die in Kapitel 6 gezeigte Unterstützung der Methode zeigt auf, dass
Aktivitäten und Techniken getrennte Elemente einer Methode sein sollten. Einer
Aktivität wird mittels einer Rolle etwa ein Verantwortlicher zugewiesen und die
Reihenfolge von Aktivitäten wird in einem Anwendungsprojekt mittels
Projektmanagement vom Unternehmen festgelegt. Techniken hingegen ergeben sich aus
dem zu erstellenden Ergebnis. Ebenso können auch mehrerer Techniken notwendig
sein, um ein Ergebnis zu erstellen. Der enge Zusammenhang von Techniken und
Aktivitäten wird aus der häufig verwendeten Darstellung des St. Gallener Modells
(Abbildung 15) jedoch nicht deutlich.183 Hier könnte eine Änderung des Modells
sinnvoll sein, etwa indem eine Technik eine Aktivität unterstützt.184 Für die vorliegende
Arbeit wird jedoch die etablierte Anordnung der Methodenelemente aus dem St.
Gallener Ansatz übernommen.
Das im St. Gallener Ansatz genannte Methodenelement Rolle wird im Verlauf dieses
Beitrags nur am Rande thematisiert.185 Die Entwicklung von Rollen ist ein weites
Teilgebiet des Methoden-Engineerings und steht nicht im Fokus dieses
Forschungsvorhabens. Vielmehr sollen hier Aktivitäten, Techniken und Ergebnisse der
Anpassung und Anwendung von BPRM entwickelt und zueinander in Beziehung
gesetzt werden.
Folgt man dem sprachkritischen Verständnis, so ermöglicht die separate Beschreibung
von Ergebnissen (inklusive Metamodell), Aktivitäten und Techniken die systematische
Entwicklung einer Methode. D.h. auf generischer Ebene ist nicht die Orchestrierung der
Methodenelemente zu einem geschlossenen Ablauf das Ziel, vielmehr sollen die
einzelnen Methodenelemente und deren Anforderungen an einer Orchestrierung
beschrieben werden. Eine solche Entwicklung ermöglicht es, eine generische Methode
flexibel auf den spezifischen Fall anzupassen. Die Elemente der Methode werden unter
Berücksichtigung der Kombinationsregeln, gemäß der Anforderungen und Fähigkeiten
eines Unternehmens, spezifiziert und eingesetzt.186
In der Literatur findet man neben dem St. Gallener Modell weitere Ansätze, die jedoch
zum Teil erhebliche Überschneidungen zum St. Gallener Ansatz aufweisen.187 Braun et
183
Es wird jedoch in einigen Publikationen beschrieben, dass Techniken bei der Durchführung der
einzelnen Transformationsaktivitäten zur Anwendung kommen (bspw. Gutzwiller 1994).
184 Eben diesen Schluss zieht Goeken 2006, S. 61 aus der breiten Definition einer Aktivität im Ansatz von
Karlsson 2002. Im weiteren Verlauf seiner Arbeit ordnet Goeken daher die Methodenbestandteile
Aktivität, Rolle und Technik einander direkt zu (Goeken 2006, S. 66).
185 Anzumerken ist hierbei, dass die Rolle in einem BPRM von einer Rolle innerhalb der hier
vorgestellten Methode zu unterscheiden ist. Das Rollenmodell einer Methode beinhaltet nur solche
Rollen, die mit dem Ablauf der Methode in Beziehung stehen. Ein Rollenmodell eines BPRM beinhaltet
hingegen die in einem BPRM vorkommenden z.B. vorgeschlagenen Rollen. Ein Beispiel: Wenn bei der
Erstellung der unternehmensspezifischen Version eines BPRM die Bezeichnung CIO in IT-Leiter
verändert wird, wird eine Rolle des BPRM umbenannt. In diesem Fall ist die Rolle IT-Leiter Bestandteil
des Rollenmodells des BPRM. Bestandteil des Rollenmodells einer Methode ist der IT-Leiter nur, wenn
er einer Aktivität der Methode zugeordnet ist. Dies kann etwa der Fall sein, wenn der IT-Leiter
verantwortlich für die Anpassung des BPRM ist, und somit einer Gruppe von Aktivitäten der Methode
zugeordnet ist.
186 Siehe u.a. Brooks 1987; Fitzgerald et al. 2003; Kelly et al. 2005, der den Begriff „domain specific
method engineering prägt― sowie Brinkkemper 1996 der den Begriff „situational method engineering―
verwendet.
187 Siehe Baumöl 2006, S. 316.
121
al. vergleichen die konstituierenden Elemente von Methoden auf Basis des Modells von
Gutzwiller (Tabelle 2).188
Ergebnis
Metamodell
Rolle
Technik
Vorgehensmodell X
Werkzeug
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Zelewski 1999
Teubner 1999
Stahlknecht
& Hasenkamp 1999
Scheer 1990
Hesse et al. 1992
Gutzwiller 1994
Greiffenberg 2003
Ferstl & Sinz 2001
Becker 2001
Balzert 1998
Tabelle 2 Vergleich der konstituierenden Methodenelemente in der Literatur nach Braun et al. 2004.
X
X
X
X
X
X
Der Vergleich von Braun et al. weist das St. Gallener Modell als das Umfassendste aus.
Der Vergleich von Goeken zeigt jedoch, dass es noch umfassendere Ansätze gibt.189
Sein Vergleich beinhaltet zusätzlich das Modell von Karlsson190 und den Ansatz von
Brinkkemper.191 Karlsson präsentiert in seinem Modell der Methodenelemente neben
den bereits in anderen Ansätzen beschriebenen Elementen (Rolle, Aktivität, Sprache,
Artefakt) auch den Geschäftskontext, den Grund (einer Aktivität) und die Notation.
Brinkkemper beschreibt zusätzlich Prinzipien als Teil von Methoden (Tabelle 3).192
Damit der Grund als Methodenelement betrachtet werden kann, muss er anderen
Methodenelementen zugeordnet werden. In Karlssons Modell ist das Element Grund
dem Element Aktivität zugeordnet.193 Für den vorliegenden Beitrag ergibt sich daher die
Fragestellung, ob einzelnen Aktivitäten unterschiedlichen Gründen zuordenbar sind. Es
gibt beschriebene indirekte Beziehungen von Gründen zu einzelnen Aktivitäten. Die
Aktivität Vergleich kann bspw. aufgrund einer angestrebten Zertifizierung durchgeführt
werden. Weiterhin können andere Aktivitäten durch diesen Grund eingeschränkt sein.
Die Aktivität Modellbereichsauswahl ist in diesem Fall möglicherweise nur
eingeschränkt durchführbar. Denn wenn die Zertifizierung die vollständige Umsetzung
eines BPRM erfordert, ist die Segmentierung nicht förderlich für eine erfolgreiche
188
Braun et al. 2004, S. 14 vergleichen Balzert 1998; Becker et al. 2001; Ferstl, Sinz 2001; Greiffenberg
2003; Gutzwiller 1994; Hesse et al. 1992; Scheer 1990; Stahlknecht, Hasenkamp 1999; Teubner 1999 und
Zelewski 1999.
189 Siehe Goeken 2006, S. 51-61.
190 Siehe Karlsson 2002.
191 Basiert auf Brinkkemper 1996 und Brinkkemper et al. 1996.
192 Brinkkemper 1996 bezeichnet den „way of thinking― als Methodenbestandteil. Goeken 2006, S. 51
bezeichnet dies als Prinzip.
193 Karlsson 2002, S. 5.
122
Zertifizierung.194 Die Gründe der Anwendung von BPRM sind jedoch noch nicht
ausreichend beschrieben und ihre Beziehungen zu Aktivitäten der Methode sind
wissenschaftlich nicht abgesichert.195 Das Methodenelement Grund wird demnach nicht
als Methodenelement aufgenommen.
Metamodell
Technik
Ergebnis
Rolle
Aktivität
Grund
Konzept
Notation
Prinzipien
Tool
X
X
X
X
X
X
X
Karlsson
Brinkemper
St. Gallener Ansatz
Tabelle 3 Vergleich der konstituierenden Methodenelemente nach Goeken 2006.
(X)
X
X
X
X
X
X
X
X
X
Dieser Überblick zeigt, dass in der Literatur verschiedene Metamodelle von Methoden
betrachtet werden. Die von Goeken verglichenen Ansätze sind die Ansätze mit den
meisten konstituierenden Elementen. Ausgehend vom St. Gallener Modell werden im
Verlauf dieser Arbeit die Elemente Metamodell, Ergebnis, Aktivität und Technik als
konstituierende Methodenelemente betrachtet. Die Elemente Notation und Konzept
werden aufgrund ihrer Nähe zur Softwareentwicklung und des niedrigen
Formalisierungsgrads des Forschungsgegenstands nicht diskutiert. Das Methodenelement Kontext wird für die generische Methode ebenfalls nicht diskutiert. Dieses
Element ist jedoch ein wichtiger Ansatzpunkt für zukünftige Forschung, da es die
Erstellung von situationsspezifischen Methoden der IT-Governance ermöglicht.196
194
Um bspw. einen CMMI-Reifegrad 2 zu bekommen sind einige Process Areas zwingend erforderlich
(siehe u.a Kneuper 2003 oder SEI 2007).
195 Für einen Überblick siehe bspw. Siviy et al. 2008a; Webb et al. 2006; Willson, Pollard 2009; Lunardi
et al. 2009; Tuttle, Vandervelde 2007; Lainhart 2000.
196 Börner 2010, Bucher et al. 2007; Ralyté, Rolland 2001; Harmsen 1997; Ter Hofstede, Verhoef 1997;
Dominguez, Zapata 2007.
123
5 Entwicklung einer Methode zur Anpassung und Anwendung von
BPRM
5.1 Vorüberlegungen
In diesem fünften Teil wird die Methode zur Anpassung und Anwendung von BPRM
vorgestellt. Die verwendeten konstituierenden Methodenelemente aus dem St. Gallener
Modell sind: Metamodell, Ergebnis, Aktivität und Technik.
Alle Methodenelemente werden, wenn möglich, unter Bezugnahme auf die
Erkenntnisse aus der Referenzmodellforschung und anderer Forschungsbereiche
hergeleitet. Ein Beispiel: Die Mechanismen der Referenzmodelladaption von Becker et
al. beziehen sich auf die Erstellung von unternehmensspezifischen Modellen aus einem
Referenzmodell heraus.197 In Analogie zur Methoden-Engineering-Terminologie wird
also ein Ergebnis (Referenzmodell) durch eine Aktivität in ein anderes Ergebnis
(unternehmensspezifische Version des Referenzmodells) transformiert. Hierfür werden
bei Becker et al. verschiedene Adaptionsmechanismen beschrieben. Die Aktivitäten der
Anpassung werden also unter Rückgriff auf die Adaptionsmechanismen von Becker et
al. entwickelt und beschrieben.198
Die Methodenelemente sind zunächst lose und generisch, bevor sie für ein konkretes
BPRM spezifiziert (siehe Kapitel 6) und zu einer anwendbaren Methode orchestriert
werden. Das Zusammensetzen der Methodenelemente hat zwei Dimensionen. Zum
einen gilt es, die Beziehungen zwischen den Elementen zu beschreiben, d.h. welche
Aktivität führt zu welchem Ergebnis, welche Technik wird verwendet um das Ergebnis
zu erstellen, etc. Zum anderen wird neben dieser Zuordnung in der
Methodenentwicklungsliteratur die Entwicklung einer Reihenfolge für die Aktivitäten
vorgeschlagen (siehe Kapitel 5.5).
5.2 Methodenelemente: Ergebnis und Metamodell
Das Methodenelement Ergebnis subsumiert alle Ergebnisse, die bei Anwendung der
Methode verwendet werden oder entstehen können. Die konzeptionellen Beziehungen
der Ergebnisse untereinander werden im St. Gallener Ansatz durch das Metamodell
beschrieben.199
Der Ergebnistyp200 BPRM bezeichnet die existierenden BPRM der IT-Governance.
BPRM sind aus Sicht der Methodenkonstruktion externe Ergebnistypen, d.h. sie
entstehen nicht als Ergebnis einer Aktivität der Methode, sondern sind das Ergebnis
externer Aktivitäten.201 BPRM sind der Ausgangspunkt der zu entwickelnden Methode
und sollen mithilfe der Methode angepasst und angewendet werden.
197
Becker et al. 2004.
Eine solche Verwendung von Adaptionsmechanismen der Referenzmodellforschung im Bereich der
Methodenkonstruktion wurde bereits von mehreren Autoren durchgeführt. Siehe Harmsen 1997 oder
Brinkkemper et al. 1996, die den Mechanismus Aggregation in der Methodenkonstruktion verwenden.
Oder Baskerville, Stage 2001, und Patel et al. 2004, die sich der Spezialisierung bedienen. Einen
Überblick bietet Becker et al. 2007, S. 5.
199 Heym 1993; Gutzwiller 1994.
200 Die Ergebnisse der generischen Methode werden als Ergebnistypen bezeichnet, da sie die Ergebnisse
der speziellen Methoden (z.B. von COBIT) subsumieren.
201 Zum Entstehungsprozess von BPRM siehe Glasner, Looso 2011 oder Teil A der vorliegenden
Dissertation.
198
124
Wie bereits erläutert sind BPRM Referenzmodelle, d.h. sie werden an die spezifischen
Umstände eines Unternehmens angepasst. Aus dieser Anpassung resultiert die
Notwendigkeit des Ergebnistyps angepasstes BPRM.202 Dieser Ergebnistyp hat drei
logisch mögliche Grundformen:203
 BPRM-Ausschnitt:
Der BPRM-Ausschnitt ist ein Teil des BPRM. Für seine Erstellung werden einige
Elemente ausgewählt und andere werden gelöscht.204 Abbildung 16 zeigt die
Beziehung zwischen den Ergebnistypen BPRM und BPRM-Ausschnitt.
BPRM
BPRM-Ausschnitt
Abbildung 16 Ergebnistyp: BPRM-Ausschnitt
 BPRM-Variation:
BPRM-Variation beschreibt einen Ergebnistyp, dessen Elemente variiert wurden.
Die Veränderung bezieht sich nur auf vorhandene Elemente. Abbildung 17 zeigt den
Ergebnistyp BPRM-Variation. Das BPRM wurde, durch die grauen Rechtecke
angedeutet, an zwei Stellen variiert.
BPRM-Variation
Abbildung 17 Ergebnistyp: BPRM-Variation
 Erweitertes BPRM:
Ein erweitertes BPRM ist ein Ergebnistyp, der mehr Elemente enthält als das
BPRM. Abbildung 18 zeigt den Ergebnistyp erweitertes BPRM. Er beinhaltet das
vollständige BPRM und zusätzliche Elemente.
202
Der Ergebnistyp angepasstes BPRM dient auch der Übersichtlichkeit und Lesbarkeit dieses Beitrags.
Er fasst die Ergebnistypen BPRM-Ausschnitt, BPRM-Variation und erweitertes BPRM zusammen und
wird verwendet, wenn alle drei Ergebnistypen zugleich thematisiert werden.
203 Siehe bspw. Hars 1994, S. 144ff.
204 Die Notwendigkeit dieses Ergebnistyps zeigt sich auch in aktueller Forschung. de Haes, van
Grembergen 2008; Tuttle, Vandervelde 2007; de Haes, van Grembergen 2006; Kaarst-Brown, Kelly 2005
zeigen, dass BPRM nicht immer vollständig eingesetzt werden.
125
Erweitertes BPRM
Abbildung 18 Ergebnistyp: Erweitertes BPRM
Neben diesen drei Grundformen existieren alle kombinatorischen Möglichkeiten, d.h.
ein BPRM-Ausschnitt kann variiert und/oder ergänzt werden. Die Bezeichnungen dieser
Ergebnistypen ergeben sich aufgrund der Reihenfolge der Aktivitäten, aus denen sie
resultieren. Der Ergebnistyp variierter BPRM-Ausschnitt ist ein Ergebnis, das zunächst
beschnitten und dann variiert wurde. Ein erweiterter variierter BPRM-Ausschnitt wurde
zunächst beschnitten, danach variiert und schließlich um zusätzliche Elemente ergänzt.
Werden BPRM angepasst oder unangepasst im Unternehmen verwendet, spricht dieser
Beitrag von Anwendung eines BPRM. Hieraus lässt sich ein weiterer externer
Ergebnistyp ableiten. In Unternehmen existieren bereits verschiedenste
Unternehmensmodelle. Auf diese können die beschriebenen Ergebnistypen angewendet
werden.205 Etwa kann ein angepasstes BPRM genutzt werden, um ein
Unternehmensmodell im Sinne des BPRM umzugestalten oder es zu prüfen. Eine
beispielhafte Ausprägung eines Unternehmensmodells ist etwa ein vorhandenes ITProzessmodell oder das Organigramm eines Unternehmens.
In der Referenzmodellforschung wird aber auch ein angepasstes Modell zumeist als
Unternehmensmodell bezeichnet. Für das hier angestrebte Gestaltungsziel ist es jedoch
notwendig, ein angepasstes BPRM von vorhandenen Unternehmensmodellen zu
unterscheiden (siehe Kapitel 5.3.3.2). Dies ist bspw. notwendig, da ein angepasstes
BPRM nur für einen Teil eines umfassenderen Unternehmensmodells als Referenz
gelten kann. Ebenso kann ein angepasstes BPRM das langfristige Ziel (im Sinne eines
Soll-Modells) für ein Unternehmensmodell sein und zunächst nur in Teilen angewendet
werden. Die Ergebnistypen angepasstes BPRM und Unternehmensmodell sind demnach
unternehmensspezifische Ergebnistypen der Methode.
Die beschriebenen Ergebnistypen stehen in einer konzeptionellen Beziehung, d.h. es
gibt ein Metamodell der Ergebnistypen der generischen Methode. Solche Beziehungen
sind notwendig, da sie die Wege der Transformation von einem Ergebnistyp zu einem
anderen aufzeigen. D.h. die Beziehungen zwischen den Ergebnissen sind die Grundlage
der zu entwickelnden Aktivitäten. Abbildung 19 zeigt die konzeptionellen Beziehungen
zwischen den Ergebnistypen der Methode.
205
Siehe Looso, Goeken 2010.
126
Unternehmensspezifisches
Modell
Best-Practice
Referenzmodell
wird angepasst zu
Angepasstes
BPRM
wird
angewendet
auf
Unternehmensmodell
wird
angewendet
auf
BPRMAusschnitt
BPRM-Variation
erweitertes
BPRM
Abbildung 19 Ergebnistypen der Methode
Die bisher vorgestellten Ergebnistypen lassen sich weiterhin unterteilen in
Ergebnistypen der Referenzebene und der Unternehmensebene. Die Referenzebene
beinhaltet Referenzmodelle, die von den spezifischen Unternehmensumständen
abstrahieren. Die Unternehmensebene subsumiert Modelle, die Unternehmensparameter
berücksichtigen.206 Die an das Unternehmen angepassten unternehmensspezifischen
BPRM werden demnach der Unternehmensebene zugeordnet, während ein BPRM der
Referenzebene zuzuordnen ist. Die Ergebnistypen BPRM-Ausschnitt, BPRM-Variation,
erweitertes BPRM und Unternehmensmodell sind also unternehmensspezifische
Modelle (siehe Abbildung 20).
Modell
Best-Practice
Referenzmodell
wird angepasst zu
Angepasstes
BPRM
wird
angewendet
auf
Unternehmensmodell
wird
angewendet
auf
BPRMAusschnitt
Referenzebene
BPRM-Variation
erweitertes
BPRM
Unternehmensebene
Abbildung 20 Metamodell der Ergebnistypen der Methode
Becker et al. verwenden für den Übergang von Referenz- auf Unternehmensebene den
Begriff Adaption. Für die hier entwickelte Methode ist es jedoch notwendig, den
206
Siehe u.a. Becker et al. 2004; Thomas 2006; Thomas, Adam 2003; vom Brocke 2003; Goeken 2002;
Loos, Fettke 2005.
127
Übergang differenzierter zu beschreiben, denn die Mechanismen von Becker et al.
beschreiben lediglich den
Übergang
eines Referenzmodells in eine
unternehmensspezifische Version des Referenzmodells. Wie bereits in Abbildung 19
ersichtlich ist, kann ein BPRM aber auch direkt, ohne Anpassung auf ein
Unternehmensmodell, angewendet werden. Auch dieses wäre ein Übergang von der
Referenzebene auf die unternehmensspezifische Ebene. Ebenso kann ein angepasstes
BPRM auf ein Unternehmensmodell angewendet werden. Die Aktivitäten der
Modellanwendung sind daher unabhängig von einer vorherigen Anpassung. Um diesem
Umstand gerecht zu werden, wird im Folgenden zwischen Modellanpassung und
Modellanwendung unterschieden.
Um den Übergang von der Referenzebene auf die Unternehmensebene näher zu
beschreiben, verwenden Becker et al. ein Ebenenmodell. Eine Anpassung kann nach
ihrem Ordnungsrahmen verschiedene Ebenen betreffen. Für die hier zu entwickelnde
Methode wird ebenfalls ein Ebenenmodell verwendet.207 Dieses unterscheidet auch
zwischen Modellebene und Metamodellebene, verwendet jedoch ein anderes
Metaisierungsprinzip.208 Das Ebenenmodell von Becker et al. unterscheidet verschiedene
Sprachebenen. Die Ebenen stehen zueinander in einer linguistischen Beziehung. D.h.
die höhere Ebene beschreibt die Sprache der Modelle der untergeordneten Ebene. Es
folgt also einem linguistischen Metaisierungsprinzip (Abbildung 21 zeigt den
Unterschied zwischen linguistischer und ontologischer Metaisierung). 209 Übertragen auf
den hier vorliegenden Fall, müsste die Metaebene eines BPRM also die
Sprachkonstrukte des zugehörigen BPRM enthalten. Die hier verwendeten BPRM
sollen im Folgenden jedoch nicht aufgrund ihrer Sprache, sondern aufgrund ihres
Inhalts zu BPRMM metaisiert werden. Die Beziehungen im Ebenenmodell dieses
Beitrags sind also nicht linguistisch, sondern ontologisch.210
Im Folgenden beschreibt die Metamodellebene also die ontologischen Konstrukte der
untergeordneten Modellebene. Die hier thematisierten BPRM der IT-Governance, die
angepassten BPRM und die Unternehmensmodelle werden der Modellebene
zugeordnet. Die ex post entwickelten211 ontologischen Metamodelle der BPRM sind
Modelle
der
Metamodellebene.
Daneben
stehen
Metamodelle
der
unternehmensspezifischen Modelle. Dieser Ergebnistyp ist notwendig, um die
Anpassung oder die Anwendung des BPRM auf höherer Ebene zu beschreiben.
207
Obwohl Becker et al. die Anpassung eines Referenzmodells beschreiben ist ihr Ebenenmodell auch zur
Klassifizierung der Modellanwendung anwendbar, da diese ebenfalls auf den genannten Ebenen erfolgt.
208 Zum Begriff Metaisierungsprinzip siehe u.a. Strahringer 1996.
209 Siehe Goeken et al. 2009; Atkinson, Kühne 2003; Alter, Goeken 2009, Goeken, Alter 2008, Goeken,
Alter 2009.
210 Siehe Goeken et al. 2009; Strahringer 1996.
211 Die nachträgliche Ableitung der Modelle auf Metaebene aus den Modellen der Modellebene ist nicht
die in Becker et al. beschriebene Vorgehensweise. Vielmehr sollte das Referenzmodell (Modellebene)
mithilfe einer konsistenten Referenzmodellierungssprache (Metamodellebene) entwickelt werden.
Aufgrund der praxisgeleiteten Entwicklung der BPRM ist dieser Schritt jedoch nicht erfolgt oder
zumindest ist ein solcher Prozess nicht dokumentiert. Die nachträgliche Entwicklung der Metaebene
zeigen Goeken, Alter 2008, Alter, Goeken 2009, Goeken, Alter 2009.
128
M3
Metametamodel
Knoten
repräsentiert
Modellkomponente
linguistische
Metaisierung
M2
Metamodel
ontologische
Metaisierung
Semistrukturiert
natürlichsprachlich
Aktivität
linguistische
Metaisierung
M1
Model
ontologische
Metaisierung
Incident identification
(Service Operation (4.2.5.1))
instance
of
M0
Instance
Service-Desk-Prozess
ticket # 2009-42
Abbildung 21 Linguistische vs. ontologische Metaisierung nach (Goeken et al. 2009)
Zusammenfassend werden im Ebenenmodell dieses Beitrags zunächst die
Abstraktionsebenen Metamodellebene und Modellebene unterschieden. Die zweite
Dimension ist die Unterscheidung zwischen Referenzebene und Unternehmensebene.
Dieses Ebenenmodell zeigt die Beziehungen zwischen den Ergebnistypen im Sinne
eines Metamodells des Methoden-Engineerings (Abbildung 22) und ist nicht zu
verwechseln mit der Metamodellebene, die das Ebenenmodell beinhaltet (Abbildung
21).
Metamodellebene
Modellebene
wird angepasst zu
BPRMM
Unternehmensspezifisches MM
wird
abgeleitet zu
wird
abgeleitet zu
Best-Practice
Referenzmodell
Unternehmensspezifisches Modell
wird angepasst zu
Angepasstes
BPRM
wird
angewendet
auf
Unternehmensmodell
wird
angewendet
auf
BPRMAusschnitt
Referenzebene
BPRMVariation
erweitertes
BPRM
Unternehmensebene
Abbildung 22 Metamodell der Ergebnistypen der Methode (Ebenenmodell)
129
Mithilfe des eingeführten Ebenenmodells können die Unterschiede zwischen dem
ursprünglichen BPRM und den angepassten BPRM konkret benannt werden. Der
BPRM-Ausschnitt, die BPRM-Variation und das erweiterte BPRM können sich sowohl
auf Modellebene als auch auf Metamodellebene von dem Ausgangs-BPRM
unterscheiden. Dieser Zusammenhang lässt sich für den BPRM-Ausschnitt
folgendermaßen beschreiben, gilt aber für die beiden anderen Ergebnistypen analog:
Der BPRM-Ausschnitt beinhaltet weniger Elemente212 als das BPRM. Die Reduktion
kann sowohl auf Modellebene als auch auf Metamodellebene erfolgen. Die Auswahl
von relevanten Elementen nennen Becker et al. Selektion. Sie unterscheiden zwei
Formen von Selektion, die Elementtypselektion und die Elementselektion. Die
Elementtypselektion bezeichnet, angewendet auf den hier vorliegenden Fall, die
Auswahl von Metamodellelementen, die Elementselektion die Auswahl von
Modellelementen. In Anlehnung an diese Unterscheidung kann der BPRM-Ausschnitt
sich also auf zwei Ebenen vom ursprünglichen BPRM unterscheiden. Der BPRMAusschnitt kann weniger Metamodellelemente (Metamodellelementselektion) haben
oder weniger Modellelemente (Modellelementselektion). Für die Ergebnistypen BPRMVariation und erweitertes BPRM bedeutet diese Unterscheidung, dass sowohl auf
Modell- als auch auf Metamodellebene ein Element oder eine Beziehung variiert oder
zusätzlich hinzugefügt werden kann. Diese Transformation erfolgt durch die Aktivitäten
der Methode, die im nun folgenden Unterkapitel beschrieben werden.
5.3 Methodenelement: Aktivität
5.3.1 Vorüberlegungen
Eine Aktivität ist definiert als Verrichtungseinheit, die ein Ergebnis erzeugt.213
Aktivitäten beschreiben daher „was― ein Ergebnis in ein anderes transformiert,
wohingegen Techniken beschreiben, „wie― der resultierende Ergebnistyp erstellt wird.
Für die hier zu entwickelnde Methode sind verschiedene Modelle als Ergebnisse
beschrieben, die aus anderen Ergebnissen hervorgehen. Folglich werden in diesem
Unterkapitel, in Abhängigkeit von den verwendeten Ergebnissen, Aktivitäten für die
Transformation von Ergebnis zu Ergebnis definiert.
Abbildung 23 zeigt die Auswirkungen der Unterscheidung von Anwendung und
Anpassung auf die Aktivitäten der Methode. Zum einen kann ein BPRM unangepasst
angewendet werden und zum anderen kann es vor der Anwendung an die
Unternehmensumstände angepasst werden. Hier kann es zu sprachlichen Verwirrungen
kommen, da bei einigen Autoren die Anpassung von Referenzmodellen an die
Unternehmensumstände als Anwendung des Referenzmodells bezeichnet wird.214 Dieser
Terminologie liegt nach Ansicht der Verfasserin die Annahme zugrunde, dass ein
Referenzmodell immer an die Unternehmensumstände anzupassen ist, da es lediglich
eine Referenz für eine Klasse von Unternehmensmodellen ist.215 BPRM der ITGovernance werden jedoch nicht nur verwendet, um unternehmensspezifische Modelle
212
Dies betrifft auch die Beziehungen zwischen den Elementen.
Siehe Goeken 2006, S. 56.
214 Siehe u.a. Becker et al. 2004; vom Brocke 2007; Schütte 1998.
215 Siehe u.a. vom Brocke 2003; vom Brocke 2007; Goeken 2002; Fettke, Loos 2004; Becker et al. 2002b.
213
130
abzuleiten, sondern bspw. auch um vorhandene Unternehmensmodelle zu prüfen; etwa
im Rahmen der internen Revision oder um eine Zertifizierung zu erhalten.216
In diesem Beitrag wird daher zwischen der Anpassung des Modells und der Anwendung
des (angepassten) Modells unterschieden. Die Aktivitätstypen der Methode sind deshalb
in zwei Kategorien unterteilt:
 Aktivitätstypen der Modellanpassung
 Aktivitätstypen der Modellanwendung
Modell
Best-Practice
Referenzmodell
wird angepasst zu
Angepasstes
BPRM
wird
angewendet
auf
Unternehmensmodell
Aktivitäten der
Anpassung
BPRMAusschnitt
Aktivitäten der
Anwendung
wird
angewendet
auf
BPRM-Variation
erweitertes
BPRM
Abbildung 23 Anpassung vs. Anwendung
Die Aktivitätstypen der Modellanpassung beschreiben jene Verrichtungseinheiten, die
das BPRM schrittweise in ein unternehmensspezifisches Modell transformieren.
Konkrete Ausprägungen dieses Aktivitätstyps sind die Modellbereichsauswahl, die
Modellvariation und die Modellerweiterung. Sie ergeben sich aus den zuvor
beschriebenen Ergebnistypen des angepassten BPRM.217
Die Aktivitätstypen der Modellanwendung beschreiben hingegen diejenigen
Aktivitäten, bei denen das BPRM in seiner ursprünglichen oder seiner angepassten
Form im Unternehmenskontext verwendet wird. Looso & Goeken haben einen
Ordnungsrahmen entwickelt, der unter anderem die Formen der Anwendung von BPRM
enthält.218 Aus qualitativen Experteninterviews und der einschlägigen Literatur leiten sie
folgende Formen ab: Externe und interne Prüfung219, Definition von
Verantwortlichkeiten220,
Entscheidungsunterstützung221,
Gestaltung
von
222
Unternehmensmodellen und das Herleiten eines gemeinsamen Begriffsverständnisses
(Glossar). Aus diesen Anwendungsformen lassen sich nun notwendige Aktivitätstypen
ableiten.
Für die generische Methode ist es zunächst unerheblich, ob ganze
Unternehmensmodelle oder Entscheidungsstrukturen bzw. Verantwortlichkeiten
216
Siehe u.a. Tuttle, Vandervelde 2007; Hardy 2006; KPMG International 2009.
Siehe auch Hars 1994, S. 144ff, der ebenfalls diese drei Formen der Modellanpassung ableitet.
218 Siehe Looso et al. 2009.
219 Hardy 2006; Tuttle, Vandervelde 2007; Damianides 2004; Fox 2004; Fox, Zonneveld 2006;
Crockcroft 2002; Mishra, Weistroffer 2007.
220 Siehe u.a. Weill, Ross 2004.
221 Siehe u.a. Larsen et al. 2006.
222 Siehe u.a. Victor et al. 2005.
217
131
gestaltet werden. Diesen Formen der Anwendung ist gemein, dass das BPRM als
Vorlage für die Gestaltung von Unternehmensmodellen gilt. Ebenso ist die Entwicklung
eines Glossars auf Basis des BPRM eine gestaltende Aktivität. Demgegenüber stehen
etwa die Prüfung durch einen Wirtschaftsprüfer oder auch die Aktivitäten der internen
IT-Revision. Diese Formen der Anwendung haben einen vergleichenden Charakter, d.h.
zwei Ergebnisse werden miteinander verglichen. Aus einer näheren Betrachtung der
belegten Anwendungsformen lässt sich schließen, dass BPRM vergleichend und
gestaltend eingesetzt werden. Die Anwendung von (angepassten) BPRM wird daher
durch die generischen Aktivitätstypen Vergleich und Gestaltung beschrieben.
5.3.2 Aktivitäten der Modellanpassung
5.3.2.1 Aktivität: Modellbereichsauswahl
Die Aktivität Modellbereichsauswahl transformiert das BPRM in das Auswahlergebnis,
den BPRM-Ausschnitt.223 Hier wird entschieden, welche Elemente des BPRM als
relevant ausgewählt werden und welche nicht. Für eine solche Segmentierung ergeben
sich zunächst zwei Fälle, die vollständige und die teilweise Auswahl. Bei einer
vollständigen Auswahl entspricht das BPRM dem Auswahlergebnis. Werden einige
Modellteile ausgewählt und andere wiederum nicht, gilt:
BPRM-Ausschnitt < BPRM
BPRM
BPRM
Modellbereichs
auswahl
BPRM-Ausschnitt
Abbildung 24 Aktivität: Modellbereichsauswahl
Das Erstellen von Teilmodellen ist für die Anpassung von BPRM von höchster
Relevanz.224 Die Auswahl kann, bspw. durch eine Ausprägung eines Unternehmensmerkmals und dessen Zuordnung zu einem bestimmten BPRM-Ausschnitts, bereits im
BPRM vorgesehen sein. Sind im BPRM keine Ausschnitte vorgesehen, d.h. das BPRM
enthält keine Hilfestellung im Sinne von Auswahlparametern o.ä., kann eine
Modellbereichsauswahl auch, wie im Folgenden beschrieben, durch die
Verantwortlichen im Unternehmen vorgenommen werden.
Die Modellbereichsauswahl erfolgt durch Metamodellelementselektion und/oder
Modellelementselektion, je nachdem auf welcher Ebene Elemente ausgewählt werden.
Da die Mechanismen der Auswahl unabhängig von der Ebene sind, wird im Folgenden
der Begriff Modellbereich verwendet, wenn Modell- und Metamodellelemente
223
Die Transformation eines bereits angepassten Ergebnistyps in z.B. den Ergebnistyp Ausschnitt der
BPRM-Variation erfolgt ebenfalls durch die Aktivität Modellbereichsauswahl.
224 Die Literatur zeigt, dass BPRM zumeist nicht vollständig eingesetzt werden. Siehe bspw. Bowen et al.
2007; Simonsson, Johnson 2008 oder de Haes, van Grembergen 2008.
132
gleichermaßen gemeint sind. Beide Mechanismen sind in Abbildung 25 schematisch
dargestellt.
Metamodellebene
Metamodellelementselektion
Modellebene
Modellelementselektion
Referenzebene
Unternehmensebene
Abbildung 25 Formen der Modellbereichsauswahl
Eine Metamodellelementselektion ermöglicht eine Auswahl der Metamodellelemente,
d.h. ein bestimmtes Metamodellelement wird aufgrund einer Parameterausprägung oder
aufgrund einer Unternehmensentscheidung gewählt oder verworfen. Für die
Modellelementselektion gilt dies analog. Jedoch hat die Metamodellelementselektion
einseitig Auswirkungen auf der Modellebene. Fällt ein Modellelement weg, weil das
abstrahierende Metamodellobjekt gelöscht wird, ist dies per Definition Teil der
Aktivität Metamodellelementselektion.
Ziel der Selektion von Modellbereichen ist die Erstellung des relevanten
Modellausschnitts. Relevant ist in diesem Fall ein höchst subjektiver Begriff. Welche
Modellbereiche relevant sind entscheiden die Unternehmensverantwortlichen. Im
Ordnungsrahmen von Becker et al. werden verschiedene Arten der Selektion
vorgeschlagen. In der vorliegenden Arbeit werden diese drei Arten als Hilfestellung der
Modellbereichsauswahl verwendet. Es bleibt jedoch anzumerken, dass die
Modellbereichsauswahl auch vollkommen frei durch die Unternehmensverantwortlichen
erfolgen kann.225
Modellbereichsauswahl über Typen
Eine Modellbereichsauswahl über Typen erfordert eine Typisierung der
Modellbereiche. Diese Typisierung kann Bestandteil des BPRM sein226 oder durch
das anwendende Unternehmen vorgenommen werden. Diese Typen sind wiederum
bestimmten externen Parametern zugewiesen oder noch zuzuweisen. Angewendet
auf den Forschungsgegenstand bedeutet dies bspw. die Typisierung der COBITElemente COBIT-Prozess in <SOX-relevante-Prozesse> und <nicht SOX-relevantProzesse>. Ergebnis einer Selektion über diesen Typ wäre ein COBIT-Subset
225
Die daraus zu erwartenden Konsequenzen werden im weiteren Verlauf thematisiert.
Eine solche Typisierung kann auch in der Begleitliteratur eines BPRM vorgenommen werden, z.B. die
Veröffentlichungen von Expertengremien der herausgebenden Institutionen. Etwa IT Governance
Institute 2003; Gaulke 2006; Cox 2004; itSMF et al. 2008.
226
133
„COBIT for SOX―227, welches nur die Modellelemente enthält, die als SOX-relevant
typisiert wurden.
Modellbereichsauswahl nach Hierarchiestufen
Hierbei erfolgt eine Zuordnung der Modellelemente zu Hierarchiestufen. Dies
ermöglicht es, bestimmte Modellinhalte in Abhängigkeit von der ihnen
zugewiesenen Hierarchie auszuwählen oder nicht auszuwählen. Beispielhaft hierfür
wäre eine Zuordnung von Unternehmenszielen zum Top-Management und von
Bereichszielen zum mittleren Management.
Modellbereichsauswahl über Attribute
Diese Form der Selektion erfolgt über Eigenschaften von Modellelementen. Becker
et al. verwenden den Automatisierungsgrad eines Modellelements als Beispiel. So
liegen vollständig automatisierte Funktionen häufig nicht im Interesse der
Organisationsgestaltung, während rein manuelle Tätigkeiten bei der
Anwendungssystementwicklung eine untergeordnete Rolle spielen.228 Werden
Modellbereiche eines BPRM also aufgrund einer gemeinsamen Eigenschaft
gelöscht, erfolgt die Modellbereichsauswahl über Attribute.
Becker et al. unterscheiden demnach drei Formen der Gruppierung in Modellbereiche.
Eine Selektion erfolgt in ihrem Ansatz indem eine solche Gruppe aufgrund einer
expliziten Regel entfernt wird, d.h. Typen von Modellelementen, Modellelemente einer
bestimmten Hierarchiestufe oder Modellelemente mit einem bestimmten Attribut
werden aufgrund der Ausprägung eines externen Parameters gelöscht. Um einen
bestimmten Modellbereich aufgrund eines externen Parameters zu löschen, muss also
zusätzlich zu einer vorhandenen Gruppierung zu einem Modellbereichs die explizite
Zuordnung dieser Gruppe zu einem externen Parameter vorliegen. Diese Zuordnung
sollte laut Becker et al. bereits Bestandteil des Referenzmodells sein.229 Ist dies nicht der
Fall, können die Modellbereiche zwar gruppiert sein, ihre Auswahl würde ohne die
explizite Zuordnung trotzdem keiner expliziten, im BPRM vorliegenden, Regel folgen.
Für eine explizite Regel nach Becker et al. ist daher erstens die Gruppierung zu
Modellbereichen und zweitens deren Zuordnung zu externen Parametern notwendig.
Wie im weiteren Verlauf gezeigt wird, liegt eine Gruppierung zu Teilbereichen in
BPRM zumeist vor, jedoch gibt es wenige explizite Zuordnungen zu externen
Parametern. Dies liegt nach Ansicht der Verfasserin hauptsächlich im Charakter eines
BPRM begründet. Best-Practices haben zumeist Vorschlagscharakter und beziehen sich
häufig auf das gegenwärtig beste Verfahren (daher wird auch der Begriff „best current
practice― verwendet).230 Explizite Regeln stehen dazu im Widerspruch. Es war daher zu
prüfen ob die Selektionsarten von Becker et al. trotzdem für BPRM verwendet werden
können. Nach Ansicht der Verfasserin sind explizite Regeln für eine Anwendung der
Selektionsarten nicht notwendig. Sie lassen sich auch aufgrund impliziter Regeln
227
Fox, Zonneveld 2006. Siehe auch die Ausführungen bei Tuttle, Vandervelde 2007 und Looso, Goeken
2010.
228 Siehe auch Becker et al. 2003, S. 58.
229 Dies ist insbesondere dem Umstand geschuldet, dass Becker et al. sich mit der Konstruktion von
Referenzmodellierungssprachen beschäftigen. Die Anwendung von bereits existierenden, eventuell
verbesserungswürdigen Referenzmodellen ist nicht der Hauptfokus.
230 Siehe Glasner, Looso 2011.
134
anwenden. Implizite Regeln der Anpassung von BPRM liegen abhängig vom konkreten
BPRM vermehrt vor. D.h. die Zuordnung eines bestimmten Teils des BPRM zu einem
externen Parameter ist implizit, etwa aufgrund von „common practice― oder auch bereits
in der Sekundärliteratur vorhanden.231
Es ist wichtig erneut zu betonen, dass die Auswahl von Modellbereichen eine
Unternehmensentscheidung ist. Die teilweise vorhandenen Gruppierungen der
Modellbereiche sowie deren implizite Zuordnungen zu externen Parametern sind
lediglich eine Hilfestellung für die Auswahl der relevanten Modellbereiche.232
Die vorgestellte Modellbereichsauswahl hat in bestimmten Fällen erhebliche Folgen.
Begründet ist dies darin, dass das Entfernen von Modellbereichen Auswirkungen auf
andere Modellbereiche hat.233 Zu solchen Auswirkungen kann es kommen, wenn
zwischen Modellbereichen bestimmte Beziehungen vorliegen. Da diese Auswirkungen
auf verbundene Bereiche eventuell nicht erwünscht sind, sollten sie bekannt sein, um
unerwünscht Auswirkungen zu beheben. Die Aktivität Modellbereichsauswahl ist daher
erst abgeschlossen, wenn erneut ein in dieser Form gewünschtes Modell vorliegt.
Um dies detailliert zu beleuchten, werden die Auswirkungen der
Modellbereichsauswahl auf Metamodell- und auf Modellebene nun konkret
beschrieben.
In der Modellierung werden zumeist die folgenden drei Grundformen von Beziehungen
thematisiert:234
 Assoziationsbeziehung
 Generalisierungsbeziehung
 Aggregationsbeziehung235
Diese grundsätzlich möglichen Beziehungen eignen sich, um die Auswirkungen der
(Meta)-Modellelementselektion zu beschreiben.
Zunächst werden die Auswirkungen auf Metamodellebene beschrieben. Hier ist
anzumerken, dass eine Selektion auf Metamodellebene immer erhebliche Auswirkungen
auf die Modellebene hat. Wird ein Metamodellelement gelöscht, entfallen auch deren
Instanzen. Im Folgenden werden jedoch vorrangig die Auswirkungen auf andere
Metamodellelemente (und konsequenterweise auch deren Instanzen) thematisiert.
Im einfachsten Fall stehen zwei Metamodellelemente in einer assoziativen Beziehung,
d.h. es besteht eine beschriebene Beziehung zwischen den Elementen. Wird nun eins
der Elemente durch die Modellbereichsauswahl gelöscht, wird diese Beziehung
231
Siehe bspw. Fox, Zonneveld 2006 als Beispiel einer Sekundärliteratur für COBIT.
Schulze 2001 beschreibt ebenfalls die Bedeutung von implizitem Wissen für die Wiederverwendung.
Er schlägt vor, das in Modellen implizit enthaltene Wissen zu explizieren und auf Basis geeigneter
Methoden zu dokumentieren und so verfügbar zu machen.
233 Kemper, Eickler 2006 sprechen bspw. von sogenannten existenzabhängigen Entitätstypen, wenn die
Existenz eines Entitätstypen von der Existenz eines anderen abhängt, sie werden zumeist durch doppelt
umrandete Kästen angezeigt.
234 Siehe u.a. Kurpjuweit 2009, S. 68; Staud 2010; Kurpjuweit, Aier 2007; Forbrig 2007, S. 81ff; Kemper,
Eickler 2006, S. 48ff; Seemann 1998.
235 Der Begriff Aggregation bezeichnet bei Becker et al. 2004 den Vorgang der Vereinigung von
Modellbereichen. In diesem Abschnitt bezeichnet Aggregationsbeziehung eine zwischen zwei Elementen
vorherrschende Beziehung.
232
135
ebenfalls gelöscht. Die der Beziehung anhaftende Information geht also zusätzlich
verloren. Steht das Element noch mit einem anderen Element in Beziehung, hat sie also
weiterhin eine Verbindung zum restlichen Modell, kommt es neben dem
Informationsverlust nicht zu weiteren Auswirkungen.
Weiterhin können Metamodellelemente in einer Generalisierungsbeziehung stehen. Im
Fall dieser gerichteten Beziehung fallen die speziellen Metamodellelemente weg, wenn
das generelle Metamodellelement entfernt wird. Wird ein spezielles Metamodellelement
entfernt, hat dies keine unmittelbaren Auswirkungen auf das generelle Element. Auf der
untergeordneten Modellebene besteht in diesem Fall jedoch nicht länger die
Möglichkeit, ein Modellelement dieser Spezialisierung zuzuweisen.
Der dritte Fall, die Aggregationsbeziehung, ist eine spezielle Form der Assoziation.
Zumeist wird sie als Teil-Ganzes oder Teil-von-Beziehung bezeichnet. Wobei die TeilGanzes-Beziehung bei einigen Autoren auch als Komposition bezeichnet wird.236 Der
Unterschied zwischen einer normalen Assoziation und einer Aggregation ist fließend
und es liegt in der Hand des Modellierers zu entscheiden, wann ein Sachverhalt als
Assoziation und wann als Aggregation zu modellieren ist. Einige Autoren nennen
Transitivität als Kriterium für eine Aggregation im Gegensatz zu einer Assoziation, d.h.
wenn A Teil von B ist und B Teil von C folgt daraus dass A auch Teil von C ist.237
Im Fall der Aggregationsbeziehung hat das Löschen des einen Metamodellelements
erhebliche Auswirkungen auf das Zweite. Im Folgenden wird zur Verdeutlichung der
Überlegungen ein Beispiel verwendet und sukzessive erweitert. Im beispielhaften
Metamodell stehen die Elemente Prozess und Teilprozess in einer
Aggregationsbeziehung. Im Beispiel besteht folgender Zusammenhang: Wird das
Element Prozess entfernt, wird aufgrund der Teil-Ganzes-Beziehung auch das Element
Teilprozess gelöscht. Dies ist unabhängig davon ob das Element Teilprozess noch mit
anderen Elementen des Metamodells verbunden ist.
Nachdem die Auswirkungen der verschiedenen Beziehungen auf Metamodellebene
beschrieben wurden, ist nun zusätzlich zu beschreiben, welche Auswirkungen auf
Modellebene durch die Modellelementselektion auftreten.
Das Löschen einer Instanz auf Modellebene hätte im Fall assoziativer Beziehungen
dieselben Auswirkungen wie auf Metamodellebene. Zunächst geht die der Beziehung
anhaftende Information verloren. Die durch das Löschen der Instanz betroffene zweite
Instanz bleibt bestehen, solange sie zu anderen Instanzen in Beziehung steht. Wird
bspw. ein konkretes Ziel durch mehrere Aktivitäten unterstützt, verursacht das
Entfernen einer Aktivität noch nicht, dass das Ziel ebenfalls entfernt werden muss.
Eine
Assoziationsbeziehung
kann
auch
zwischen
Instanzen
desselben
Metamodellobjekts herrschen. Kurpjuweit beschreibt diese Form als reflexive
Assoziation zwischen zwei gleichartigen Objekten.238 Stehen Modellelemente etwa in
einer solchen reflexiven Beziehung, hat das Löschen des Modellelements ebenfalls
Auswirkungen auf andere Elemente gleichen Typs. Abbildung 26 zeigt dies graphisch.
236
Abhängig vom Autor wird Komposition auch als Synonym für die Aggregation verwendet (Glinz
2003, S. 11). Teilweise ist Komposition definiert als eine Aggregation mit speziellen Eigenschaften. Die
Komposition beschreibt in diesen Quellen eine Teil-Ganzes-Beziehung, die im Gegensatz zu einer Teilvon-Beziehung (Aggregation) die Existenzabhängigkeit zwischen den Elementen beinhaltet (siehe auch
Rumbaugh et al. 2005, S. 56; Staud 2010 oder Hitz, Bernauer 2005).
237 Kurpjuweit 2009 unterscheidet zusätzlich transitive und nicht transitive Aggregation.
238 Siehe Kurpjuweit 2009 oder Becker et al. 2002a; Becker et al. 2003, S. 48.
136
Das Entfernen von Prozess X führt dazu, dass Ergebnis Ex nicht entsteht, dadurch wird
Prozess Y nicht angestoßen usw. Ebenso führt das Löschen von Prozess X in diesem
Fall dazu, dass sukzessive das gesamte Modell gelöscht würde. Wird jedoch Prozess Z
entfernt, entstehen keine Auswirkungen auf andere Prozesse.
Ergebnis
wird verwendet
produziert
Prozess
Prozess
X
Teilprozess
part-of
part-of
part-of
Teilprozess
X1
Teilprozess
X2
Ergebnis
Ex
Prozess
Y
Teilprozess
Y1
Teilprozess
Y2
part-of
part-of
Ergebnis
Ey
Prozess
Z
part-of
part-of
Teilprozess
Z1
Teilprozess
Z2
Abbildung 26 Auswirkungen der Modellbereichsauswahl I
Im Fall einer Generalisierungsbeziehung hat das Entfernen eines speziellen
Modellelements keine Auswirkungen auf das generelle Modellelement. Im umgekehrten
Fall hingegen entfallen die speziellen Elemente ebenfalls.
In einer Aggregationsbeziehung bilden zwei Elemente aus Sicht der Selektion eine
Einheit. Dies ist etwa möglich wenn ein BPRM in Sachgebiete oder Prozesse unterteilt
oder auch anhand von Zielen strukturiert ist. Ein bestimmtes Sachgebiet X umfasst
bspw. mehrere Instanzen des Metamodellelements Prozess, ist jedoch kein
Metamodellelement, sondern ebenfalls eine Instanz des Metamodellobjektes
Sachgebiet. Abbildung 27 zeigt diese Unterscheidung graphisch. Die zwei
Metamodellobjekte Prozess und Teilprozess sind neunmal instanziiert.239 Diese neun
Instanzen bilden aufgrund der Teil-Ganzes-Beziehung zwischen Teilprozess und
Prozess drei Einheiten.
239
Die Beziehungen zwischen den Metamodellobjekten und ihren Instanzen wurden der Übersichtlichkeit
halber entfernt.
137
Metaebene
Prozess
Prozess
X
part-of
part-of
Teilprozess
Teilprozess
X1
Teilprozess
X2
part-of
Modellebene
Prozess
Y
part-of
Teilprozess
Y1
Teilprozess
Y2
part-of
Prozess
Z
part-of
part-of
Teilprozess
Z1
Teilprozess
Z2
Abbildung 27 Auswirkungen der Modellbereichsauswahl II
Stehen zwei Modellelemente also in einer Aggregationsbeziehung, führt das Entfernen
der einen auch zur Entfernung des zweiten Modellelements. Die Einheit wird also
gelöscht. Im Beispiel: Das Löschen des Prozesses X führt dazu, dass seine Teilprozesse
X1 und X2 ebenfalls gelöscht werden.
Wird also ein Modellbereich (Metamodellelement oder Modellelement) bei der
Modellbereichsauswahl entfernt, sind die Konsequenzen dieser Aktivität zu
berücksichtigen.240 Fraglich ist hierbei erstens, ob dem Anwender alle Konsequenzen
bekannt sind und zweitens, ob sie gewollt sind. Um die Auswirkungen der
Modellbereichsauswahl zu beschreiben, müssen die Beziehungen der Elemente im
konkreten Fall unterschieden werden. Hier wird empfohlen, die herrschenden
Beziehungen anhand der hier gezeigten Beziehungen zu klassifizieren und so die
Auswirkungen der Modellbereichsauswahl zu verdeutlichen.
Soll ein Modellbereich entfernt werden, ist anhand der beschriebenen Beziehungen zu
prüfen, welche Auswirkungen das Löschen hat. Sind die Auswirkungen bekannt und als
gewollt deklariert, ist die Modellbereichsauswahl abgeschlossen. Verursacht das
Löschen eines Elements jedoch unerwünschte Auswirkungen, muss der
Modellanwender darauf reagieren. Hierfür ergeben sich grundsätzlich zwei
Möglichkeiten. Erstens kann die Selektion (in Teilen) rückgängig gemacht werden und
zweitens besteht die Möglichkeit, das Modell bspw. um zusätzliche Beziehungen zu
240
Das Entfernen von Metamodellelementen ist mit dem Entfernen von Elementen aus dem
konzeptionellen Schema einer Datenbank zu vergleichen. Das Löschen von Modellelementen ist
vergleichbar mit dem Löschen eines einzelnen Datensatzes (vergleiche bspw. Golfarelli et al. 1998 oder
Theodoratos et al. 1999).
138
erweitern und so unerwünscht Kettenreaktionen der Selektion zu verhindern.241 Diese
Möglichkeit wird im entsprechenden Unterkapitel 5.3.2.3 thematisiert.
5.3.2.2 Aktivität: Modellvariation
Diese Aktivität beschreibt die Transformation eines Ergebnistyps in den Ergebnistyp
BPRM-Variation. Hierfür wird der Ergebnistyp modifiziert.
BPRM
BPRM-Variation
Modellvariation
Abbildung 28 Aktivität: Modellvariation
Veränderung ist beschränkt auf eine Veränderung der vorhandenen Modellbereiche. Der
Ergebnistyp BPRM-Variation enthält demnach weder zusätzliche (Meta-)
Modellelemente, noch ist es möglich neue Beziehungen zwischen vorhandenen oder
neuen (Meta-)Modellelementen zu ziehen. Sollen zusätzliche Elemente oder
Beziehungen erstellt werden, erfolgt dies durch die Aktivität Modellerweiterung.
Die Variation eines BPRM ist wiederum mit einigen Mechanismen von Becker et al.
vergleichbar. Hier kommen insbesondere die Mechanismen der nicht-generierenden
Adaption in Betracht. Diese sind definiert als Mechanismen der Erzeugung spezifischer
Modellvarianten durch das Füllen von Gestaltungsspielräumen im Referenzmodell.
Becker et al. nennen hier die Mechanismen Aggregation, Instanziierung, Spezialisierung
und Analogiekonstruktion. Hier zu diskutieren sind die Mechanismen Instanziierung
und Spezialisierung. Für die Aggregation242 werden neue Beziehungen zwischen
Modellbereichen gezogen, was per Definition bereits eine Erweiterung ist. Die
Analogiekonstruktion wird als Mechanismus der Modellanpassung beschrieben, die
aufgrund der Ähnlichkeit zwischen zwei Objekten nach folgendem Muster durchgeführt
wird: A hat Ähnlichkeit mit B; B hat die Eigenschaft C; also hat auch A die Eigenschaft
C. Die Analogiekonstruktion wird im Gegensatz zu den drei anderen Mechanismen
nicht formal beschrieben. Becker et al. erwähnen lediglich, dass die Adaption unter
Verwendung von Analogieschlüssen aufgrund von Struktur- und Inhaltsanalogien
erfolgen kann.243 Nach Ansicht der Verfasserin ist Analogieschluss jedoch nicht mit der
Instanziierung und Spezialisierung vergleichbar. Instanziierung und Spezialisierungen
beschreiben Formen der Adaption von einem Ergebnis zu einem anderen, das Ziehen
von Analogien hingegen beschreibt keinen Anpassungsvorgang. Eine festgestellte
Analogie ist vielmehr eine Grundlage für eine Anpassung. Ein auf der Analogie
beruhender Analogieschluss verläuft nach folgendem Muster: Im BPRM wird Prozess
X vorgeschlagen wenn Y vorliegt, im anwendenden Unternehmen liegt Y vor, also ist
Prozess X zu verwenden. Die bereits beschriebene Modellbereichselektion kann daher
241
Eine Variation des Modells ist aufgrund der engen Definition der Variation in diesem Fall nicht
möglich (siehe Kapitel 5.3.2.2).
242 Der Begriff Aggregation im Sinne von Becker et al. ist nicht zu verwechseln mit dem Begriff
Aggregationsbeziehung, der im vorherigen Kapitel thematisiert wurde.
243 Siehe auch Becker, Knackstedt 2003, S. 418.
139
auf Analogieschlüssen basieren. Neben Instanziierung und der Spezialisierung zur
Modellvariation steht außerdem die Variation durch Umbenennen, welche sich in
Anlehnung an die Darstellungs- und Bezeichnungsvariation von Becker et al. ergibt.
Modellvariation durch Instanziierung
„Die Instanziierbarkeit von Attributen durch Attributsausprägungen und von
Modellelementen durch Attribute oder ganze Modelle ist dadurch gekennzeichnet, dass
bei der Konstruktion des Referenzmodells vom konkreten Anwendungskontext insofern
abstrahiert wird, als daß Aspekte zunächst vage formuliert oder frei gelassen werden.―244
Der Referenzmodellanwender muss demnach das Modell bei Anwendung
konkretisieren und an seinen Kontext anpassen (Abbildung 29). Becker et al. sprechen
bei der Instanziierung von Platzhaltern, die vom Anwender entsprechend des Kontextes
zu füllen sind.245
Verändern durch
Instanziieren
Platzhalter
unternehmensspezifische
Modellkomponente
Abbildung 29 Modellvariation durch Instanziierung
Da sich Becker at al. konkret mit der Konstruktion von Referenzmodellierungssprachen
beschäftigen, weisen sie darauf hin, dass der Anwender explizit auf solche zu
konkretisierenden Stellen hingewiesen werden muss. Im Rahmen von BPRM sind diese
zumeist nicht angegeben, es gibt jedoch in manchen BPRM Hinweise auf zu
instanziierende Stellen. Diese Stellen sind von BPRM zu BPRM verschieden und
können daher nicht auf dieser generischen Ebene beschrieben werden.246
Modellvariation durch Spezialisierung
Eine Anpassung des Modells an die Unternehmensumstände durch den Mechanismus
Spezialisierung erfolgt an Stellen des Referenzmodells, deren Detaillierungsgrad
aufgrund seines Referenzcharakters bewusst eingeschränkt ist.247 Die Adaption sieht
dann vor, dass Modellelemente bei der Erstellung eines unternehmensspezifischen
Modells spezifiziert werden. Hier wird im Gegensatz zur Instanziierung kein Platzhalter
gefüllt, sondern ein bereits vorhandenes Element weiter spezialisiert. Beschreibt ein
BPRM zum Beispiel ein Mahnwesen, kann es für ein Unternehmen notwendig sein,
diesen Prozess für Privatkunden und für Firmenkunden unterschiedlich zu gestalten.
Dies wäre eine Spezialisierung des Elements Mahnwesen.
244
Becker et al. 2004, S. 258.
Siehe auch Schütte 1998, S. 257, der von Prozessbausteinen mit generischem Charakter spricht, oder
Schwegmann 1999.
246 Siehe Kapitel 6 und 7.
247 Becker, Knackstedt 2003, S. 418 beschreiben Referenzmodelle (hier Modellbereiche von Referenzmodellen) die mittels Spezialisierung angepasst werden sollen als Modelle mit hohem Abstraktionsgrad
und oft geringer Anzahl an Modellelementen.
245
140
Modellvariation durch Umbenennen
Eine weitere Möglichkeit ein BPRM zu verändern ist das Umbenennen von
Modellbereichen. (Meta-)Modellelement-Bezeichnungen werden hierbei durch
unternehmensspezifische Bezeichnungen ersetzt. Becker et al. nennen hierfür die
Bezeichnungsvariation. Sie beschreiben mit diesem Mechanismus aber variable
Bezeichnungen innerhalb eines Modells für verschiedene Benutzergruppen. D.h. ein
Modellelement kann abhängig von der Benutzerperspektive verschieden bezeichnet
werden. Hierfür sind Synonymlisten zu erstellen, welche bestimmten Benutzergruppen
zuzuordnen sind.248 In diesem Beitrag meint Variation durch Umbenennen jedoch
vielmehr Anpassungen von im Referenzmodell vorgesehenen Bezeichnungen. D.h. es
werden Bezeichnungen durch im Unternehmen gebräuchlichere Bezeichnungen ersetzt.
Von variablen Bezeichnungen in Abhängigkeit von Benutzergruppen wird in diesem
Forschungskontext dringend abgeraten. Dies liegt insbesondere darin begründet, dass
BPRM unter anderem auch dazu eingesetzt werden, um die Terminologie im
Unternehmen zu vereinheitlichen.249
Fraglich ist nun ob die beschriebenen Mechanismen von Becker et al. alle logisch
möglichen Formen der Variationen von BPRM beschreiben und somit dem logischdeduktiven Forschungsvorgehen Genüge getan ist. Instanziierung beschreibt das
inhaltliche Ausgestalten von Platzhaltern, Spezialisierung das weitere inhaltliche
Ausgestalten von vorhandenen Elementen, und das Umbenennen ist selbsterklärend. In
Kombination mit den „Änderungen― durch Mechanismen der Selektion und der
Erweiterung sind alle logisch möglichen Formen der Variation beschrieben.
5.3.2.3 Aktivität: Modellerweiterung
Modellerweiterung ist definiert als das Hinzufügen neuer Elemente oder Beziehungen.
Im Gegensatz zum BPRM-Ausschnitt gilt im Falle der Modellerweiterung:
BPRM-Erweiterung > BPRM
BPRM
BPRM-Erweiterung
Modellerweiterung
Abbildung 30 Aktivität: Modellerweiterung
Erweiterung kann auf Metamodell- und auf Modellebene erfolgen. Wird ein Element
hinzugefügt, so muss dieses Element zu anderen Elementen in Beziehung stehen. Die
Erweiterung um ein Element zieht also wenigstens eine neue Beziehung nach sich.
Da ein Metamodell als Hilfsergebnistyp per Definition nur erweitert wird um das
Modell zu erweitern, hat das Hinzufügen eines Metamodellelements zwingend immer
auch Auswirkungen auf Modellebene. Abbildung 31 zeigt die Erweiterung des
Metamodells um das Metamodellelement Sachgebiet und deren Beziehung zum
Metamodellelement Prozess. Diese Erweiterung der Metamodellebene ist notwendig,
248
249
Becker et al. 2006, S. 82.
Siehe u.a. Looso, Goeken 2010; Looso 2010; Alter, Goeken 2009.
141
um auf Modellebene konkrete Sachgebiete zu etablieren, denen Prozesse zugeordnet
werden können.
Sachgebiet
part-of
part-of
Teilprozess
X1
Teilprozess
X2
part-of
part-of
Prozess
Y
Teilprozess
Y1
Teilprozess
Y2
part-of
part-of
Sachgebiet B
part-of
Prozess
Z
Teilprozess
part-of
Prozess
X
part-of
Sachgebiet A
Prozess
part-of
part-of
Teilprozess
Z1
Teilprozess
Z2
Abbildung 31 Erweitern durch Metamodellerweiterung
Neben der Modellerweiterung, die durch eine Metamodellerweiterung ermöglicht wird,
steht die Modellerweiterung, die sich ausschließlich auf Modellebene ereignet. Diese
erfolgt durch eine neue Instanz eines vorhandenen Metamodellelements. Ist bspw. für
ein Ziel eine Metrik vorgesehen, kann eine weitere Metrik für dieses Ziel hinzugefügt
werden (Abbildung 32).
Modellerweiterung
1
2
Abbildung 32 Modellerweiterung
Diese Aktivität weist Ähnlichkeiten zur Variation durch Instanziieren auf, ist jedoch
von ihr wie folgt zu unterscheiden: Wird eine Metrik als Platzhalter betrachtet, der
durch Instanziierung an die Unternehmensumstände angepasst wird, ist das einmalige
Instanziieren eine Veränderung, das zweimalige Instanziieren bereits eine
Modellerweiterung.
Da diese Erweiterung auf Modellebene eine zusätzliche Instanz eines
Metamodellelements ist, sind für die Ausgestaltung der neuen Beziehungen die
142
Beziehungen des abstrahierenden Metamodellelements maßgeblich. Die Beziehungen
der neuen Instanz sind ebenfalls neue Instanzen der im Metamodell vorgesehenen
Beziehungstypen.
In Anlehnung an die Erläuterungen bei der Modellbereichsauswahl können sich
Beziehungen zwischen Modellbereichen auch auf die Modellerweiterung auswirken.
Wird ein Modellelement hinzugefügt, das laut Metamodell mit anderen
Modellelementen in einer Aggregationsbeziehung steht, müssen diese anderen
Modellelemente ebenfalls neu erstellt werden. Abbildung 33 zeigt diesen
Zusammenhang. Wird beispielsweise ein Prozess Y hinzugefügt, sind auch Teilprozesse
zu etablieren, wenn laut Metamodell die Elemente in einer Teil-Ganzes-Beziehung
stehen. Wird ein neues Sachgebiet hinzugefügt, sind diesem entweder vorhandene
Prozesse zuzuordnen (Modellerweiterung um neue Beziehungen) oder es sind neue
Prozesse zu erstellen (Modellerweiterung um neue Elemente).
Sachgebiet
part-of
part-of
part-of
Prozess
Y
part-of
part-of
Sachgebiet B
part-of
Prozess
Z
Teilprozess
part-of
part-of
Prozess
X
part-of
Sachgebiet A
Prozess
part-of
part-of
Teilprozess
X1
Teilprozess
X2
Teilprozess
Y1
Teilprozess
Y2
Teilprozess
Z1
Teilprozess
Z2
Abbildung 33 Modellerweiterung bei Aggregationsbeziehungen
Die Möglichkeit, neue Beziehungen zwischen den Modellbereichen zu ziehen, d.h. die
Kopplung von Referenzmodellelementen, bezeichnen Becker et al. als Aggregation. Sie
bezeichnet einen Mechanismus, der Modellelemente miteinander verbindet.
Aggregation verwendet die nächsthöhere Ebene als Orientierung. Angewendet auf den
hier vorliegenden Fall bedeutet das, dass die Metaebene Hinweise für die Aggregation
auf Modellebene liefert. Werden also einzelne Teile eines BPRM zur Anwendung
ausgewählt, ermöglicht die Aggregation die Orchestrierung der Modellelemente zu
einem Gesamtmodell.250
250
Siehe auch Lang 1997; Remme 1997; Elfatatry 2007.
143
Dieser Mechanismus kann auch eingesetzt werden, wenn unerwünschte Auswirkungen
im Zuge der Selektion auftreten. Wird etwa ein Sachgebiet gelöscht, ein bestimmter
Prozess des Sachgebiets soll jedoch bestehen bleiben, so kann dieser Prozess bspw.
einem anderen Sachgebiet zugeordnet werden. Abbildung 34 zeigt, dass das Löschen
von Sachgebiet A die Auswirkungen hätte, dass Prozess X und Y ebenfalls wegfielen.
Soll Prozess Y jedoch weiterhin bestehen bleiben könnte dieser Prozess Sachgebiet B
zugeordnet werden.
Auf Metamodellebene wäre ebenso vorzugehen, d.h. würde ein Element gelöscht, so ist
zu prüfen, ob die in Beziehung stehenden Elemente anderen Elementen zugeordnet
werden können. Daher ist die Modellerweiterung eine Möglichkeit, mit den
Auswirkungen der Modellbereichsauswahl umzugehen.
Sachgebiet
Prozess
part-of
Prozess
X
part-of
Sachgebiet A
part-of
part-of
Prozess
Y
part-of
part-of
part-of
Sachgebiet B
part-of
Prozess
Z
Teilprozess
part-of
part-of
part-of
Teilprozess
X1
Teilprozess
X2
Teilprozess
Y1
Teilprozess
Y2
Teilprozess
Z1
Teilprozess
Z2
Abbildung 34 Modellerweiterung durch neue Beziehungen
5.3.3 Aktivitäten der Modellanwendung
5.3.3.1 Aktivität: Vergleich
Die Aktivität Vergleich ist in der Literatur zumeist nur implizit beschrieben und nicht
explizit als Vergleich benannt. Doch es ist unstrittig, dass BPRM vergleichend
eingesetzt werden. So bemerkt etwa Hardy, dass der Vergleich des
Unternehmensmodells mit dem COBIT-Modell hilfreich sei, um aufsichtsrechtliche und
andere prüfungsrelevante Vorschriften zu erfüllen.251 COBIT bieten außerdem die
Möglichkeit, sicher zu stellen, dass die unternehmenseigene IT-Organisation den
251
Hardy 2006.
144
gesetzlichen Anforderungen genügt.252 Tuttle & Vandervelde beschreiben bspw. COBIT
als Werkzeug der IT-Prüfung.253 Weiterhin werden BPRM genutzt, um die ITOrganisation (z.B. das IT-Service-Management) im Unternehmen zu optimieren.254 Die
Grundlage der Optimierung bildet zumeist ein Vergleich der aktuellen Situation mit den
Anforderungen des BPRM.255
Die Literatur zeigt also, dass BPRM vergleichend eingesetzt werden. Ob ein solcher
Vergleich zu internen (z.B. Standortbestimmung) oder externen (z.B. IT-Prüfung durch
einen Wirtschaftsprüfer) Zwecken erfolgt, ist hierbei zweitrangig. Die Beschreibung des
Vergleichs als Aktivität der Methode ist demnach notwendig.
Die Aktivität Vergleich beschreibt grundsätzlich den Vergleich zweier Ergebnisse. Es
ist festzustellen, dass die Aktivität Vergleich nicht die Transformation eines
Ergebnistyps in einen anderen beschreibt, denn die beiden zu vergleichenden
Ergebnistypen bleiben unverändert. Die Überprüfung eines Ergebnistyps im Verhältnis
zu einem anderen (Abbildung 35) resultiert in einem Vergleichsergebnis. Dieses
Vergleichsergebnis ist wiederum eine Variante des Ergebnistyps angepasstes BPRM.
Denn der zu vergleichende Ergebnistyp hat zunächst entweder mehr oder weniger
Elemente, welche möglicherweise außerdem angepasst wurden. Er ist daher ein
Ausschnitt, eine Variation oder eine Erweiterung der Vergleichsbasis.
Ergebnistyp X
Ergebnistyp Y
Vergleich
Vergleichsergebnis:
angepasstes BPRM
Abbildung 35 Aktivität: Vergleich
Die Aktivität Vergleich kann unter erneutem Rückgriff auf das Ebenenmodell
systematisiert werden. So kann sowohl ein Vergleich der Metamodelle als auch ein
Vergleich der Modelle erfolgen. Fraglich ist jedoch, inwieweit dies zwei unabhängige
Vergleichsarten sind. Werden zwei Metamodelle256 verglichen, basiert der Vergleich der
Metamodellelemente zu großen Teilen auf den inkludierten Modellelementen. Dies liegt
darin begründet, dass zwei Metamodellelemente auf Basis ihrer Instanzen verglichen
werden, da eine reine Bezeichnungsgleichheit der Metamodellelemente nicht
ausreichend für einen aussagefähigen Vergleich ist. Die Aktivität Vergleich basiert also
sowohl auf den Metamodellelementen als auch auf den Modellelementen.
252
Lainhart 2000; Damianides 2004; Fox 2004; Fox, Zonneveld 2006.
Tuttle, Vandervelde 2007.
254 Böhmann, Krcmar 2004; Böttcher 2008; Hochstein, Hunziker 2003; Kemper et al. 2004; Sommer
2004.
255 Ebel 2007; Fröschle et al. 2011; Kneuper 2003; Elsässer 2007; Cox 2004; Böttcher 2008; Kamleiter,
Langer 2006.
256 Hier ist anzumerken, dass vom Ergebnistyp Unternehmensmodell nicht notwendigerweise ein
Metamodell vorliegt und dies eventuell erstellt werden muss.
253
145
Begreift man das Metamodell als konzeptionelles Schema eines Modells, lassen sich
Analogien zum Forschungsbereich Datenbankintegration ziehen. Dort werden für einen
Vergleich der konzeptionellen Schemata und den enthaltenen Daten verschiedene
Konfliktarten unterschieden (Extensionale Konflikte, Beschreibungskonflikte,
Heterogenitätskonflikte und strukturelle Konflikte). Heterogenitätskonflikte und
strukturelle Konflikte beschreiben datenbankspezifische Konflikte. Extensionale
Konflikte und Beschreibungskonflikte beschreiben jedoch grundsätzlichere
Unterschiede und können daher nach Ansicht der Verfasserin auch verwendet werden,
um die Ähnlichkeit bzw. die Unterschiede zwischen zwei Ergebnistypen der Methode
zu beschreiben. Im Folgenden werden daher die folgenden Konfliktarten der
Schemaintegration verwendet, um mögliche Vergleichsergebnisse zu unterscheiden:
 Extensionale Konflikte
 Beschreibungskonflikte
Extensionale Konflikte bestehen, wenn zwei unabhängig voneinander entstandene
Schemata den gleichen Weltausschnitt (oder Teile davon) beschreiben und daher
einander entsprechende Metamodellelemente enthalten, jedoch die zugehörigen
Instanzen nicht vollständig übereinstimmen. Die Literatur kennt vier Arten dieses
extensionalen Konflikts (Abbildung 36).257
Eine Äquivalenz zweier Metamodellelemente liegt vor, wenn alle Instanzen identisch
sind. Eine Teilmenge liegt vor, wenn alle Instanzen eines Elements auch Instanzen des
anderen Elements sind. Liegt eine Überlappung vor, bilden die Instanzen beider
Elemente eine nicht leere Schnittmenge. Eine Disjunktheit liegt schließlich vor, wenn
keine Instanz identisch ist.
Meta-Ebene
Modell A
Modell B
MxA
Eine MetamodellKomponente Mx tritt
sowohl in Modell A als
auch in Modell B auf
MxB
Modell-Ebene
Äquivalenz
MxA=MxB
#1 MxA
#2 MxA
Alle Instanzen von
MxA und MxB sind
identisch
#1 MxB
#2 MxB
Teilmenge
MxB schließt
MxA ein
#1 MxA
#2 MxA
Alle Instanzen von
MxA sind auch
Instanzen von MxB
#1 MxB
#2 MxB
#3 MxB
#1 MxA
#3 MxA
Einige Instanzen von
MxA sind auch
Instanzen von MxB
#2 MxB
#3 MxB
#1 MxA
Keine Instanz von
MxA ist auch Instanz
von MxB
#2 MxB
#3 MxB
Überlappung
MxA und MxB
haben eine
nicht leere
Schnittmenge
Disjunktheit
MxA und MxB
haben eine leere
Schnittmenge
Abbildung 36 Extensionale Konflikte in Anlehnung an (Conrad 2002)
257
In Anlehnung an Conrad 2002, S. 103.
146
Soll nun etwa ein angepasstes BPRM mit einem Unternehmensmodell verglichen
werden, so kann die Übereinstimmung der Bestandteile anhand dieser Konfliktarten
klassifiziert werden. Da im Bereich von BPRM zusätzlich zu diesen semantischen
Konflikten häufig zahlreiche Beschreibungskonflikte vorliegen, ist dieser Prozess
jedoch nicht trivial. Beschreibungskonflikte liegen vor, wenn gleiche Elemente
beschrieben werden, sie sich jedoch in ihrer Beschreibung unterscheiden, bspw.
aufgrund von homonymen und synonymen Bezeichnungen. Dies kann Modellelemente
ebenso betreffen wie Metamodellelemente.
Die Aktivität Vergleich erfolgt in mehreren Schritten. Nach der Auswahl der zu
vergleichenden Modelle ist zunächst festzulegen, welches Modell die Basis des
Vergleichs bilden soll und welches Modell zu vergleichen ist.258 Soll etwa festgestellt
werden, inwieweit ein Unternehmensmodell einem BPRM entspricht, ist das BPRM die
Basis des Vergleichs und das Unternehmensmodell der Vergleichskandidat. Im
Anschluss daran ist festzulegen, mit welchem Metamodellelement der Vergleichsbasis
der Vergleich beginnen soll und welche weiteren Modellbereiche in welcher
Reihenfolge verglichen werden sollen. Bei einem vollständigen Vergleich sind bspw.
alle Elemente der Vergleichsbasis mit denen des Vergleichskandidaten zu vergleichen.
Außerdem ist aufzuzeigen inwieweit der Vergleichskandidat zusätzliche Elemente
enthält.
Der Vergleich von Ergebnistypen basiert zu großen Teilen auf den Einschätzungen des
bzw.
der
Vergleichenden.
In
Anlehnung
an
die
konsensorientierte
Referenzmodellierung kann argumentiert werden, dass der Konsens einer
sachverständigen Gruppe einen gewissen Grad an Objektivität aufweist.259 Wird diese
Aktivität also von Techniken unterstützt, die in Gruppen durchgeführt werden (siehe
Kapitel 5.4), kann die Objektivität des Vergleichs gesteigert werden. Ebenso kann bei
steigender fachlicher und methodischer Expertise der Vergleichenden argumentiert
werden.
5.3.3.2 Aktivität: Gestaltung
Die Aktivität Gestaltung vervollständigt die Systematik der Anpassung und Anwendung
von BPRM. Wie im Verlauf dieses Unterkapitels erläutert wird, ist diese Aktivität der
Vollständigkeit halber genannt, wird jedoch nicht in derselben Ausführlichkeit wie die
anderen Aktivitäten beschrieben.
Die Aktivität Gestaltung ergibt sich aus der Unterscheidung zwischen den
Ergebnistypen angepasstes BPRM und Unternehmensmodell (hier sei erneut auf
Abbildung 20 und die dazugehörige Argumentation verwiesen). Wie in den bisherigen
Ausführungen argumentiert, entsteht durch die Anpassung eines Referenzmodells an die
Unternehmensumstände eine unternehmensspezifische Version des Referenzmodells
(Ergebnistyp: angepasstes BPRM).260 Dieses angepasste BPRM beschreibt den
unternehmensspezifischen
Soll-Zustand
bezogen
auf
ein
BPRM.
Ein
258
Das zu vergleichende Modell wird als Vergleichskandidat bezeichnet, das andere Modell als
Vergleichsbasis.
259 Die maßgebliche Grundposition der konsensorientierten Referenzmodellierung ist die Entstehung von
Wahrheit durch den Konsens einer sachverständigen Sprachgemeinschaft (siehe u.a. Becker 2004;
Zelewski 1999).
260 Siehe u.a. auch Becker et al. 2004; vom Brocke 2007; Schütte 1998.
147
Unternehmensmodell
hingegen,
ist
ein
vom
BPRM
unabhängiges,
unternehmensspezifisches Modell. Dieser Ergebnistyp subsumiert verschiedene
Modelle, etwa ein vorhandenes Organigramm oder ein Geschäftsprozessmodell.
Die Aktivität Gestaltung beschreibt nun die Umsetzung von Vorgaben des
(angepassten) BPRM in einem Unternehmensmodell. Wie aus Abbildung 37 deutlich
wird,
können
verschiedene
Ergebnistypen
für
die
Gestaltung
von
Unternehmensmodellen verwendet werden, etwa das Ausgangs-BPRM oder auch alle
Arten des angepassten BPRM (Abbildung 23).
Ergebnistyp X
Unternehmensmodell
Gestaltung
Abbildung 37 Aktivität: Gestaltung
Im Zuge der Gestaltung kann es notwendig sein, den angestrebten Soll-Zustand nur
schrittweise umzusetzen, d.h. zunächst nur Teile des (angepassten) BPRM in das
Unternehmensmodell umzusetzen. In diesem Fall ist mithilfe eines Projektmanagements
festzulegen, welche Teile des (angepassten) BPRM in welcher Reihenfolge in ein
Unternehmensmodell umgesetzt werden. Das Ausmaß und die Geschwindigkeit der
Umsetzung stehen bspw. im Zusammenhang mit den Zielen der Anwendung eines
BPRM.261
Ebenso ist bei der Gestaltung von Unternehmensmodellen aufgrund von Vorgaben aus
einem BPRM darauf zu achten, dass keine Widersprüche zu anderen Vorgaben
auftreten. Dies ist insbesondere im Multi-Modell-Fall von Bedeutung, denn in diesem
Fall können Anforderungen und Gestaltungsvorgaben aus mehreren BPRM abgeleitet
werden.262
Die Gestaltungsaktivitäten müssen unabhängig vom BPRM den Regeln und
Grundsätzen des jeweiligen Unternehmensmodells (bspw. hinsichtlich der
Modellierungssprache) genügen. Hier wird deutlich, dass Gestaltung im Gegensatz zu
allen anderen Aktivitäten abhängig vom Unternehmensmodell ist, d.h. sie ist
unabhängig vom konkreten BPRM. Aus diesem Grund ist die Gestaltung von
Unternehmensmodellen nach den Vorgaben des BPRM sowie deren Umsetzung und
Verankerung
in
der
Unternehmensrealität
nicht
Bestandteil
dieses
Forschungsvorhabens. Hier sei auf die einschlägigen Forschungsbereiche bspw. das
Projektmanagement oder die Geschäftsprozessmodellierung verwiesen.
261
Wird etwa die Zertifizierung des Unternehmens angestrebt, ist eine hohe Übereinstimmung mit dem
BPRM notwendig (siehe u.a. Ebel 2007; Fröschle et al. 2011).
262 Siehe u.a. Siviy et al. 2008b; Krcmar, Walter 2006; Lang 1997; Rohloff 2007; Cox 2004; Hochstein et
al. 2004; Victor et al. 2004; Sommer 2004; Johannsen, Goeken 2010.
148
5.4 Methodenelement: Technik
Im gewählten Method-Engineering-Ansatz ist das Element Technik dem Element
Ergebnis zugeordnet. Techniken sind dort definiert als detaillierte Anleitungen zur
Erstellung von Ergebnissen. Die hier thematisierten Ergebnisdokumente sind Modelle,
daher werden grundsätzlich Techniken zur Erstellung von Modellen benötigt.
Die Modellierung ist ein sehr weit entwickeltes Forschungsfeld. Regeln für das
Erstellen von Modellen und die verschiedenen Modellierungssprachen sind in
zahlreichen Publikationen thematisiert.263 In diesem Beitrag wird aber nicht auf
Modellierung im Allgemeinen eingegangen, sondern es wird ein bestimmter Aspekt der
Modellierung fokussiert. Dieser Aspekt wird im Folgenden unter Rückgriff auf
Goeken264 abgeleitet.
Goeken zitiert hierfür zunächst Dresbach: „Setzt man Modellierung mit Abbildung der
Realität gleich, so würde nicht nur der Modellerstellungsvorgang trivialisiert – man
bräuchte nur noch ein geschultes Auge und eine gewisse Auffassungsgabe für die
Realität –, sondern man ginge von der impliziten Annahme aus, dass die Realität
objektiv erkennbare Strukturen aufweisen würde.―265 Daraus zieht Goeken den Schluss,
dass der Modellersteller, folgte man dem abbildungsorientierten Verständnis, lediglich
ein „Abzeichner― eines Realitätsausschnitts wäre. Daher folgt er dem
konstruktivistischen Modellverständnis266 und schlussfolgert, dass nach diesem
Verständnis die Leistung im Modellerstellungsprozess darin liegt, „ausgehend von einer
fachlichen Problemstellung einen Sachverhalt zu strukturieren und in einer
formalisierten Sprache darzustellen. Hierbei spielen die Erfahrungen und
Deutungsmuster des Modellierers eine wichtige Rolle.―267 Aus diesen Überlegungen
leitet Goeken Folgendes her: „Die Modellerstellung (Modellierung) ist eine
Konstruktion, der eine konstruktive Erkenntnisleistung zugrunde liegt, bei der ein
Sachverhalt strukturiert und konzeptualisiert wird. Da dies i. d. R. nicht durch den
Modellierer alleine geschieht, entsteht ein Modell in einem dialogischen und
diskursiven Prozess (soziale Konstruktion).―268
Wichtig für das Erstellen von Modellen ist demnach neben den darstellenden
Modellierungssprachen auch diese konstruktive Erkenntnisleistung. Leite bemerkt dazu
etwa „recently, several software researchers and research groups have been proposing
meta conceptual models. Although important results have been achieved, not much
attention has been directed to the problem of filling the models, that is, instantiating the
model with knowledge. Very little work has attacked the problem of bridging the gap
from the real world to the conceptual model.‖269 Wie dies durch Techniken unterstützt
werden kann steht im Fokus dieses Abschnittes.
263
Siehe u.a. Aburub et al. 2007; Becker 2004; Becker 1995; Assenova, Johannesson 1996; Becker,
Algermissen 2003; Becker et al. 2002c; Becker et al. 2006; Becker et al. 2002a; Becker et al. 2002d;
Becker, Pfeiffer 2006; Becker et al. 1995; Bühne et al. 2004; Dresbach 1999; Ebert et al. 2000; Hesse,
Mayr 2008; Maier 1998; Mayr et al. 2006; Pohl et al. 1998; Rumpe et al. 2004.
264 Siehe Goeken 2006, S. 85ff.
265 Goeken 2006, S. 98 zitiert Dresbach 1999, S. 74.
266 Siehe auch Teil A der vorliegenden Dissertation.
267 Goeken 2006, S. 89.
268 Goeken 2006, S. 93.
269 Leite, Franco 1993.
149
Fraglich ist zunächst, was diese konstruktive Erkenntnisleistung im Fall der Anpassung
und Anwendung von BPRM auszeichnet. Im Falle der Anpassung werden Modelle in
Modelle überführt, im Falle der Anwendung werden Modelle verglichen und
Unternehmensmodelle auf Basis anderer Modelle gestaltet. Die Erstellung des
resultierenden Ergebnistyps basiert jedoch in jedem Fall auf Entscheidungen des
Unternehmens. Ein Beispiel wäre die Entscheidung, welche Modellbereiche in einen
BPRM-Ausschnitt aufgenommen werden sollen. Diese Entscheidungen basieren auf der
Meinung der am Prozess teilnehmenden Personen. Aus diesem Zusammenhang ergibt
sich zunächst die Frage, wer in welcher Form Anteil an der Entscheidungsfindung hat
und wie deren Meinung erhoben und aggregiert wird.270 Daran anschließend stellt sich
die Frage, wie die Entscheidung getroffen wird.
Techniken unterstützen daher nach Ansicht der Verfasserin Entscheidungen hinsichtlich
der Modellanpassung und -anwendung. Aufgrund der getroffenen Annahme, dass eine
Entscheidung auf Informationen beruht, können Techniken also erstens den
Informationsbeschaffungsprozess oder zweitens die Entscheidungsfindung unterstützen.
Die zu treffenden Anpassungs- und Gestaltungsentscheidungen sind grundsätzlich mit
dem Anforderungsmanagement in der Softwareentwicklung vergleichbar – denn die
Auswahl der Modellbereiche, die eventuell verändert in ein neues Modell eingehen,
oder die (Um-) Gestaltung eines Unternehmensmodells, sollten in den Anforderungen
des anwendenden Unternehmens begründet sein. Für die Auswahl von möglichen
Techniken kann daher auf Erkenntnisse aus diesem Forschungsbereich zurückgegriffen
werden. Goeken unterscheidet für das Anforderungsmanagement in Anlehnung an
einschlägige Literatur271 folgende mögliche Techniken272: Fragebogen, Interview,
Gruppensitzung,
Berichtsmethoden,
Beobachtung,
Dokumentenanalyse,
Aufgabenanalyse, Analogieschluss und die Spiegelbildmethode. Diese Techniken
werden für die Anforderungserhebung und -analyse eingesetzt und sind aufgrund der
Analogie zwischen Informationsbeschaffung für die Modellerstellung und der
Anforderungserhebung der Softwareentwicklung Grundlage für diesen Beitrag. Diese
Auflistung sollte jedoch nach Ansicht der Verfasserin um die Delphi-Methode ergänzt
werden, da sie insbesondere in der qualitativen Forschung als Alternative zu
Fragebogentechniken, Interviews und Gruppendiskussionen betrachtet wird.273
Fraglich ist nun, inwieweit diese Techniken die Informationsbeschaffung und die
Entscheidungsfindung unterstützen. Bezüglich der Informationsbeschaffung ist zu
unterscheiden, ob die Technik von einem Einzelnen oder einer Gruppe durchzuführen
ist, d.h. ob die Information auf der Meinung mehrerer oder eines Einzelnen basiert.
270
Diesbezüglich lassen sich u.a. Anleihen aus der empirischen Sozialforschung ziehen, dieser
Forschungsbereich beschäftigt sich zwar mit der Erforschung menschlichen Handelns, die Techniken der
empirischen Sozialforschung zielen aber zum Teil auf das Erheben und das Zusammenfügen von
Meinung ab.
271 Die Übersicht von Goeken 2006, S. 128f.basiert auf Struckmeier 1996, S. 29ff; Holten 1999, S. 120;
Beiersdorf 1995, S. 71ff; Klimek 1998 und Maiden 1996.
272 Goeken 2006 verwendet für den Begriff Technik die folgende abweichende Definition: Handlungsanweisung, die im Rahmen einer Aktivität und bezogen auf eine Notation/Sprache das Vorgehen
detailliert anleitet und die Erzeugung eines Ergebnisses unterstützt.
273 Siehe Häder 2002, S. 60ff oder auch Bardecki 1984; Brockhaus, Mickelsen 1977; Duffield 1993;
Murry, Hammons 1995; Rauch et al. 1978.
150
Soll nur ein Einzelner die Quelle der Information sein, bestehen folgende Möglichkeiten
der
Informationsgenerierung:
Fragebogen274,
Interview,
Berichtsmethoden,
Beobachtung,
Dokumentenanalyse,
Aufgabenanalyse,
Analogieschluss
und
Spiegelbildmethode. Bei Fragebogen, Interview und Berichtsmethoden wird in diesem
Fall jeweils nur eine Person befragt, bei der Beobachtung wird eine Person beobachtet.
Sollen
Dokumentenanalyse,
Aufgabenanalyse,
Analogieschluss
oder
Spiegelbildmethode eingesetzt werden, bildet sich eine Person eine Meinung bezüglich
der Dokumente, Aufgaben, Ähnlichkeit oder Gleichheit zu anderen Situationen.
Ist dagegen eine Gruppe die Quelle für eine Information, besteht zusätzlich die
Möglichkeit einer Gruppendiskussion oder einer Delphi-Befragung. In diesen beiden
Fällen sind die vorliegenden Informationen auch bereits aggregiert. Die vorher
genannten Techniken führen, auch wenn sie auf mehrere Personen angewendet werden,
nicht zu einer aggregierten Gruppenmeinung. Die Informationen liegen also zunächst
lose vor.275
Auf Grundlage der so erzielten Informationen kommt es zur Entscheidungsfindung.
Diese können unabhängig von den vorliegenden Informationen und deren Entstehung
(von einer Einzelperson oder einer Gruppe) getroffen werden. Grundsätzlich ist es hier
immer möglich, dass ein Einzelner auf Basis der erzielten Informationen entscheidet.
Soll die Entscheidung aber von einer Gruppe getroffen werden, lassen sich Konsensund Mehrheitsentscheidungen unterscheiden. Daher werden die genannten Techniken
auf ihre Eignung bezüglich Konsensfindung und Mehrheitsentscheidung untersucht.
Mithilfe eines Fragebogens276 lassen sich Mehrheitsentscheidungen unterstützen, denn
anhand von konkreten Fragen und deren Antworten lassen sich bei quantitativer
Auswertung prozentuale Mehrheitsmeinungen erheben.277 Ein Konsens wäre aber
lediglich Zufall, daher werden Fragebogentechniken nicht empfohlen, wenn ein
Konsens angestrebt ist. Interviews, Berichte und Beobachtungsergebnisse sind in der
Regel qualitativer Natur, sie unterstützen daher Mehrheitsentscheidungen nur bedingt.
Ein Konsens ist auf Basis dieser Techniken ebenfalls nicht möglich. Fraglich ist hier, ob
Interviews überhaupt die Entscheidungsfindung unterstützen, oder ob sie nur der
Informationsbeschaffung dienen. Denkbar wäre es bspw. Interviews durchzuführen und
die Interviewten in einer Gruppendiskussion entscheiden zu lassen. Die Technik
Gruppendiskussion unterstützt sowohl Mehrheits- als auch Konsensentscheidungen.
Dokumentenanalyse, Aufgabenanalyse, Analogieschluss und Spiegelbildmethode
unterstützen, wenn sie von einer Gruppe gemeinsam durchgeführt werden, ebenfalls
Mehrheits- und Konsensentscheidungen. Bei einem „echten― Delphi kann es nicht zu
einer Mehrheitsentscheidung kommen, da das Ergebnis eines Delphis per Definition der
Konsens ist. Es sind jedoch Abwandlungen in der Delphi-Methodik denkbar.
In einer konkreten Anwendungssituation ist dann zu entscheiden, mithilfe welcher
Technik(en) ein bestimmtes Ergebnis erzielt werden soll. Diese Auswahl ist letztlich
von den Verantwortlichen im Anwenderunternehmen zu treffen.
274
Bei den Techniken Fragebogen und Interview ist eine zusätzliche Person nötig, die Informationen
beruhen jedoch nur auf einer Person.
275 Häder vergleicht Delphi-Befragungen, Gruppendiskussionen und Experteninterviews bezüglich der
Aggregation der erhobenen Informationen (Häder 2002, S. 60).
276 Ein strukturiertes Interview und ein offener Fragebogen weisen erhebliche Ähnlichkeiten auf. Die
Unterscheidung der Techniken in mündliche und schriftliche Befragung ist hier unerheblich. Ein
Fragebogen wird in diesem Beitrag, im Gegensatz zu einem qualitativen Interview, als eher quantitativ
betrachtet.
277 Zur Auswertung von Fragebögen siehe bspw. Raab-Steiner, Benesch 2010 oder Eckstein 2008.
151
Techniken sind also vor dem Hintergrund der jeweiligen Aufgabe oder
Unternehmenssituation auszuwählen.278 Der Einsatz von Techniken ist demnach bedingt
durch die Menge aller möglichen Techniken, die für die Erstellung eines bestimmten
Ergebnistyps anwendbar sind und die konkrete Unternehmenssituation. Die Auswahl
der Technik basiert auf den Eigenschaften der einzelnen Technik. Wie in Tabelle 4 zu
sehen ist, können die möglichen Techniken aufgrund der Art der
Informationsbeschaffung und der möglichen Form der Entscheidungsfindung
klassifiziert werden.
Tabelle 4 Techniken
Basis der
Informationen
Technik
Entscheidungsfindung
in der Gruppe
Gruppe Einzelperson Mehrheit
Konsens
Fragebogen
x
x
x
Interview
x
x
Gruppendiskussion
x
Berichtsmethoden
x
x
(x)
Beobachtung
x
x
(x)
Dokumentenanalyse
x
x
x
x
Aufgabenanalyse
x
x
x
x
Analogieschluss
x
x
x
x
Spiegelbildtechnik
x
x
x
x
Delphi
x
(x)
x
x
x
Durch Auswahl der vom Unternehmen gewünschten Art der Informationsbeschaffung
und Entscheidungsform kann so die Anzahl der in Frage kommenden Techniken
reduziert
werden.279
Neben
diesen
Auswahlkriterien
können
auch
Wirtschaftlichkeitskriterien wie etwa Dauer oder Kosten zur Klassifikation
herangezogen werden. Bezüglich der Wirtschaftlichkeit verschiedener Techniken liegen
zahlreiche Publikationen vor.280
278
Goeken thematisiert für die Auswahl einer Technik in einer konkreten Projektsituation das
Kontingenzmodell nach Davis (Goeken 2006, S. 127; Davis 1982).
279 Hars 1994, S. 143ff beschreibt für die Auswahl von Modellen einen ähnlichen Mechanismus. Sein
Ansatz beinhaltet ein Repositorium in welchem spezifische Modelleigenschaften benannt sind anhand
derer die Auswahl unterstützt wird. Bei diesem Verfahren werden sämtliche Modelle aus dem
Repositorium selektiert, denen bestimmte Eigenschaften zugewiesen worden sind.
280 Siehe u.a. Albers 2009; Prochnow, von Hanxlenden 2008 oder Atteslander, Cromm 2003.
152
5.5 Methodenkonfiguration
Die bisherige Beschreibung der Methodenelemente erfolgte auf der Grundlage eines
sprachkritischen Methodenverständnisses, d.h. die Methodenelemente wurden zunächst
separat beschrieben. Um eine anwendbare Methode zu entwickeln ist allerdings auch
die Zuordnung von Ergebnissen, Aktivitäten und Techniken notwendig.281 Hier ist zu
unterscheiden, ob die Zuordnung von generischen oder abgeleiteten spezifischen
Methodenelementen gemeint ist. Um spezifische Elemente aufeinander zu beziehen, ist
es zunächst notwendig, die generischen Methodenelemente für ein BPRM zu
konkretisieren (siehe Kapitel 6 und 7). Deren Konfiguration kann dann etwa abhängig
von der konkreten Unternehmenssituation282 oder des Anwendungsbereichs283 erfolgen.284
In diesem generischen Teil des Beitrags ist nun fraglich, inwieweit die Konfiguration
bereits auf generischer Ebene erfolgen kann. Da im Falle dieser generischen Methode
sowohl die konkrete Anwendungssituation als auch das anzuwendende BPRM
unbekannt sind, lassen sich lediglich die logisch möglichen Konfigurationen
beschreiben. Fraglich ist also, wie Techniken zu Ergebnissen stehen und wie sich
Aktivitäten und Ergebnisse einander zuordnen lassen.
Die Zuordnung von Techniken zu Ergebnissen ist nach Ansicht der Verfasserin frei
gestaltbar, d.h. alle beschriebenen Techniken eignen sich theoretisch für das Erstellen
aller Ergebnisse.285 Die Zuordnung von Ergebnissen zu Aktivitäten ergibt sich aufgrund
derselben logischen Zusammenhänge, die bei der Konstruktion der Methodenelemente
verwendet wurden. So führt etwa die Modellbereichsauswahl zum Ergebnistyp BPRMAusschnitt oder zu einem seiner Variationen, d.h. wird die Aktivität auf ein bereits
variiertes BPRM angewendet, entsteht ein variierter BPRM-Ausschnitt. Die Zuordnung
an dieser Stelle ist daher trivial.
Weniger trivial ist die Frage der Reihenfolge der Aktivitäten. Im Zuge der Auswahl des
anzuwendenden BPRM286 wird die Frage beantwortet, ob das BPRM für einen Vergleich
oder zur Gestaltung verwendet werden soll. Ist diese Frage beantwortet, erfolgt eine
Eignungsprüfung welche ergibt, ob das BPRM für den Vergleich oder die Gestaltung an
das Unternehmen angepasst werden muss. Dies kann beispielsweise dann der Fall sein,
wenn das Unternehmen nur Teile des BPRM mit dem aktuellen Unternehmensmodell
vergleichen will, oder das BPRM schrittweise angewendet werden soll. Ist keine
Anpassung nötig, kann das BPRM direkt für die Gestaltung oder den Vergleich
verwendet werden. Ist das BPRM anzupassen, ist zunächst zu ermitteln, welche
Aktivitäten der Anpassung durchzuführen sind. Daran anschließend erfolgen die jeweils
notwendigen Aktivitäten der Modellanpassung. Abbildung 38 zeigt diese
Zusammenhänge graphisch. Neben den Aktivitäten sind auch die verwendeten oder
resultierenden Ergebnisse dargestellt. Die gestrichelten Verbindungslinien zeigen, dass
281
Siehe u.a. Brinkkemper 1996; Ralyté, Rolland 2001 oder Karlsson, Wistrand 2006.
Siehe u.a. Brinkkemper 1996; Brinkkemper et al. 1999 oder Harmsen 1997, die den Begriff
„situational method engineering― verwenden.
283 Siehe u.a. Kelly et al. 2005 der den Begriff „domain-specific method engineering― prägt.
284 Agerfalk 2007 betont hier: „A situational method can be constructed by combining a number of
method fragments.‖
285 Dies gilt wie in Kapitel 5.4 beschrieben für die Vorbereitung und das Treffen von Entscheidungen.
286 Diese Aktivität wurde in diesem Beitrag nicht weiter thematisiert, da die Annahme besteht, dass
bereits entschieden wurde, welches BPRM einzusetzen ist. Die Vor- und Nachteile der Anwendung
bestimmter BPRM sind nicht Bestandteil dieses Beitrags.
282
153
ein bestimmtes Ergebnis in Zuge einer Aktivität verwendet wird. Die aus den
Aktivitäten der Modellbereichauswahl resultierenden angepassten BPRM sind jedoch
aus Gründen der Übersichtlichkeit nicht mit den nachfolgenden Aktivitäten verbunden.
Ebenso sind sie auf der rechten Seite der Abbildung nicht erneut aufgeführt. Die
Zusammenhänge sind dort analog zu den Darstellungen im Bereich der Gestaltung.
Weiterhin wurde darauf verzichtet alle Kombinationen des Ergebnistyps angepasstes
BPRM darzustellen.
154
BPRM-Auswahl
BPRM soll
zur Gestaltung
verwendet
werden
BPRM passt
nicht zum
Unternehmen
Eignungsprüfung
Eignungsprüfung
xor
xor
BPRM passt
zum
Unternehmen
BPRM
xor
BPRMAnpassungsAnalyse
BPRM soll
zum Vergleich
verwendet
werden
xor
BPRM passt
zum
Unternehmen
xor
BPRM ist zu
umfangreich
BPRM ist zu
variieren
BPRM ist nicht
ausreichend
Modellbereichsauswahl
Modellvariation
Modellerweiterung
ist erfolgt
Modellvariation
ist erfolgt
Modellerweiterung ist
erfolgt
V
Gestaltung
Vergleich
BPRM ist zu
umfangreich
BPRM ist zu
variieren
BPRM ist nicht
ausreichend
Gestaltung ist
erfolgt
Vergleich ist
erfolgt
Modellvariation
Modellerweiterung
ist erfolgt
Modellvariation
ist erfolgt
erfolgt
V
V
BPRMVariation
BPRMAnpassungsAnalyse
Unternehmens
modell
V
BPRMAusschnitt
BPRM passt
nicht zum
Unternehmen
erweitertes
BPRM
Abbildung 38 Logisch möglichen Abfolge der vorgestellten Aktivitäten
155
Bezüglich der Aktivitäten der Modellanpassung ist nun zu diskutieren, ob jeder logisch
mögliche Ablauf auch praktisch sinnvoll ist. Es ist fraglich, ob eine Modellvariation
oder eine Modellerweiterung vor einer Modellbereichsauswahl erfolgen sollte. In
diesem Fall könnte es dazu kommen, dass Modellbereiche variiert werden, die später
nicht verwendet werden. Ebenso könnte eine Modellerweiterung an Stellen ansetzen,
die später nicht mehr Teil des angepassten Modells sind. Die zur Variation oder
Erweiterung eingesetzten Ressourcen wären daher unwirtschaftlich verwendet. Im Falle
der Erweiterung müsste diese Aktivität sogar erneut durchgeführt werden. Nach Ansicht
der Verfasserin ist daher immer zunächst festzustellen, welche Anpassungsaktivitäten
durchgeführt werden sollen. Werden alle drei Anpassungsaktivitäten durchgeführt,
sollten sie aus wirtschaftlichen Gründen in der Reihenfolge Modellbereichsauswahl,
Modellvariation und Modellerweiterung ausgeführt werden.
Für die Anwendung des BPRM zur Gestaltung ergibt sich folgendes Bild: Soll ein
Modell zur Gestaltung genutzt werden, ist es aus Wirtschaftlichkeitsgründen ratsam,
zunächst eventuelle Anpassungen des BPRM durchzuführen. Auf Grundlage dieses
resultierenden angepassten BPRM erfolgt die Gestaltung des Unternehmensmodells.
Abbildung 39 zeigt einen nach Ansicht der Verfasserin sinnvollen Ablauf. In diesem
Fall wird zunächst entschieden, ob Anpassungen notwendig sind. Bei negativer
Eignungsprüfung sind die Aktivitäten der Anpassung in der Reihenfolge
Modellbereichsauswahl, Modellvariation und Modellerweiterung durchzuführen.
Ebenso könnte auch nach jeder Aktivität eine erneute Eignungsprüfung erfolgen, d.h.
nach der Modellbereichsauswahl erfolgt eine erneute Prüfung. Verläuft diese positiv,
kann das Ergebnis direkt zur Gestaltung verwendet werden, verläuft sie negativ, folgt
die nächste Anpassungsaktivität.
Es wird also deutlich, dass nicht alle logisch möglichen Konfigurationen auch
wirtschaftlich sinnvoll sind. Im Zuge der Methodenkonfiguration auf Ebene der
konkreten Methoden sind die hier erzielten Erkenntnisse zu berücksichtigen.
156
BPRM soll
zur Gestaltung
verwendet
werden
Eignungsprüfung
BPRM
Unternehmens
modell
XOR
BPRMAusschnitt
BPRM ist
anzupassen
BPRM ist nicht
anzupassen
XOR
ist erfolgt
Gestaltung
Gestaltung ist
erfolgt
Modellvariation
variierter
BPRMAusschnitt
Modellvariation
ist erfolgt
erweiterter,
variierter
BPRMAusschnitt
Modellerweiterung
erfolgt
Abbildung 39 Methodenkonfiguration: EPK einer möglichen Methode
157
5.6 Zwischenfazit
Ziel dieses Kapitels war die Entwicklung einer generischen Methode zur Anpassung
und Anwendung von BPRM. Die konstituierenden Methodenelemente wurden dem St.
Gallener Modell des Methoden-Engineerings entnommen. Die Beschreibung erfolgte
auf der Grundlage des sprachkritischen Methodenverständnisses, d.h. die Methodenelemente wurden zunächst separat und redundanzfrei beschrieben. Die Entwicklung der
Methodenelemente basiert in Teilen auf Forschungsergebnissen aus der
Referenzmodellforschung. Weiterhin wurden auf dieser generischen Ebene die logisch
möglichen Zuordnungen der entwickelten Methodenelemente beschrieben sowie deren
praktische Tauglichkeit diskutiert.
In Kapitel 2 wurde beschrieben, dass das Forschungsvorhaben in den Ordnungsrahmen
der konstruktionsorientierten Forschung nach Hevner et al. eingebettet werden kann.
Die bisher beschriebene generische Methode ist demnach ein theoretischer Beitrag zur
Wissensbasis der IT-Governance-Forschung. Im beschriebenen Forschungsablauf nach
Peffers et al. erfolgt nun die Anwendung des generischen Artefakts auf ein konkretes
BPRM. Erst eine solche abgeleitete konkrete Methode ist zur Anwendung im
praktischen IT-Governance-Umfeld geeignet. In den beiden nächsten Kapiteln wird
daher die detaillierte Ableitung einer BPRM-spezifischen Methode am Beispiel COBIT
und die exemplarische Ableitung für das BPRM CMMI demonstriert.
6 Methode zur Anpassung und Anwendung des BPRM COBIT
6.1 Vorüberlegungen
Im folgenden Kapitel wird die vorgestellte generische Methode für das BPRM COBIT
konkretisiert. Hierfür werden die spezifischen Ergebnisse und Aktivitäten der Methode
zur Anwendung von COBIT aus der generischen Methode heraus entwickelt. Die
Techniken, die auf generischer Ebene vorgestellt wurden, lassen sich nicht für COBIT
spezifizieren. Sie sind vielmehr in Abhängigkeit von den Gegebenheiten im
Anwenderunternehmen anzupassen, etwa an die vorhandenen zeitlichen Ressourcen
oder die geographische Verteilung der teilnehmenden Personen.
Die Anpassung und Anwendung von COBIT wird durch Erkenntnisse und
Entwicklungsergebnisse aus dem Forschungsprojekt SemGoRiCo unterstützt.
SemGoRiCo ist das Akronym für „Semantic Governance, Risk Management and
158
Compliance―. Das SemGoRiCo-Projekt287 hat das Ziel, die Anpassung und Anwendung
von BPRM, insbesondere von COBIT, zu unterstützen.288
6.2 Ergebnisse der spezifischen Methode für COBIT
Aus den Ergebnistypen der generischen Methode lassen sich die spezifischen
Ergebnisse für eine Methode zur Anwendung von COBIT ableiten. Das
Ausgangsergebnis ist nun nicht mehr der generische Ergebnistyp BPRM, sondern das
spezifische BPRM COBIT in seiner Version 4.1. Aufgrund der Bezugnahme auf
Projektergebnisse wird das unternehmensspezifische COBIT im Folgenden auch als
MyCOBIT (Ergebnistyp: Angepasstes BPRM) bezeichnet. MyCOBIT kann wiederum
ein Ausschnitt, eine Variante, eine Erweiterung oder eine der möglichen Kombinationen
sein. Diese spezifischen Ergebnisse unterscheiden sich wie in den Ausführungen in
Kapitel 5.2 erläutert. Abbildung 40 zeigt das Metamodell der spezifischen Ergebnisse
der COBIT-Methode.
287
Dieses Projekt (HA-Projekt-Nr.: 160/08-22) wird im Rahmen der Innovationsförderung gefördert,
finanziert aus Mitteln der hessischen LOEWE - Landes-Offensive zur Entwicklung Wissenschaftlichökonomischer Exzellenz, Förderlinie 3: KMU-Verbundvorhaben.
288 Zunächst steht COBIT im Fokus des Projekts. Die Integration weiterer BPRM ist jedoch ebenfalls Ziel
des Projekts. Diese Integration folgt einem Multi-Modell-Gedanken, der in diesem Beitrag nur am Rande
thematisiert wird. Zur Multi-Modell-Umgebung IT-Governance siehe Alter, Goeken 2009 und Looso
2010a.
159
Metamodellebene
Modellebene
COBITMM
wird angepasst zu
wird
abgeleitet zu
wird
abgeleitet zu
COBIT 4.1
wird angepasst zu
wird
angewendet
auf
Unternehmensmodell
MyCOBIT
wird
angewendet
auf
COBITAusschnitt
Referenzebene
COBITVariation
erweitertes
COBIT
Unternehmensebene
Abbildung 40 Ergebnisse der Methode zur Anwendung von COBIT
Da COBIT nicht aus einem Metamodell abgeleitet ist,289 wurde das COBIT-Metamodell
nachträglich erstellt. Die nachträgliche Entwicklung von Metamodellen ist Bestandteil
zahlreicher Publikationen der Forschungsgruppe und wird hier nicht mehr
thematisiert.290
Die Darstellung der COBIT-Ergebnisse wird durch SemGoRiCo unterstützt.
SemGoRiCo bietet die Möglichkeit, sie als semantische Netze zu repräsentieren. Hierfür
wurde im ersten Teilprojekt des SemGoRiCo-Projekts das ontologische Metamodell
von COBIT (Ergebnistyp BPRMM) in ein semantisches Begriffsnetz überführt. Dies
erfolgte mit dem kommerziellen Werkzeug K-Infinity des Projektpartners intelligent
views gmbh. Das Begriffsnetz wurde in einem zweiten Schritt um die Modellelemente,
die sogenannten Individuen ergänzt (Ergebnistyp BPRM).291 Abbildung 41 zeigt
beispielhaft die Individuen, die mit dem Individuum AI6 Manage Changes in
Beziehung stehen. Die jeweiligen Begriffe (Metamodellelemente) sind durch die
hinzugefügten beschrifteten Rechtecke angedeutet.
289
Siehe Glasner, Looso 2011.
Siehe Alter, Goeken 2009, Goeken, Alter 2008, Goeken, Alter 2009; Goeken et al. 2009.
291 In der Projektterminologie werden Metamodellelemente als Begriffe und Modellelemente als
Individuen bezeichnet.
160
290
Role
Activity
Control Objective
IT Resource
Goal
Process
Focus Area
Domain
Information Criteria
Metric
Maturity Model
Abbildung 41 Individuen und Begriffe
Das resultierende semantische Netz bildet COBIT zunächst in seiner Reinform ab. Das
vollständige Abbild des BPRM COBIT in einem semantischen Netz ist das erste
Entwicklungsergebnis des SemGoRiCo-Projekts. In der Methodenterminologie ist
dieses Netz das Ausgangsergebnis für eine Anpassung und Anwendung von COBIT.
Alle weiteren Ergebnisse der Methode können, vom Ausgangsnetz ausgehend, mithilfe
von SemGoRiCo erstellt werden. Für deren Erstellung wird zunächst eine exakte Kopie
des semantischen Netzes angefertigt. Diese Kopie wird dann durch das Durchführen
von Aktivitäten und unter Verwendung von Techniken weiter angepasst oder
angewendet.
161
6.3 Aktivitäten der spezifischen Methode für COBIT
6.3.1 Aktivitäten der COBIT-Anpassung
6.3.1.1 COBIT-Modellbereichsauswahl
Diese Aktivität transformiert in ihrer einfachsten Form COBIT in den COBITAusschnitt. Ebenso kann diese Aktivität auch auf andere, etwa bereits angepasste,
Ergebnisse angewendet werden. Diese Aktivität ist abgeschlossen, wenn der für das
Unternehmen relevante COBIT-Ausschnitt, also eine erste Version von MyCOBIT
vorliegt.
COBIT 4.1
COBIT 4.1
Modellbereichs
auswahl
COBITAusschnitt
Abbildung 42 COBIT-Aktivität: Modellbereichsauswahl
Um die Modellbereichsauswahl für COBIT zu spezifizieren werden im Folgenden
zunächst die Beziehungen zwischen den Modellbereichen thematisiert. Dies ist nötig
um in einem zweiten Schritt die Konsequenzen der Modellbereichsauswahl zu
beschreiben. Abschließend wird in Anlehnung an die Ausführungen in generischen Teil
beschrieben, aufgrund welcher Systematik die COBIT-Modellbereichsauswahl erfolgen
kann. Hierfür werden aus dem COBIT-Modell Typen, Hierarchiestufen und Attribute
herausgearbeitet, welche zur Anpassung von COBIT an die Unternehmensumstände
verwendet werden können.
Beziehungen zwischen den COBIT-Modellbereichen
Um die Auswirkungen der Modellbereichsauswahl zu beschreiben, wurden in Kapitel
5.3.2.1 Beziehungstypen unterschieden (Assoziationsbeziehung, Generalisierungsbeziehung und Aggregationsbeziehung), auf deren Basis im konkreten Fall die
Beziehungen zwischen den Modellbereichen beschrieben werden sollen. Die
Beziehungen zwischen den (Meta)-Modellelementen von COBIT sind nun mithilfe
dieser Beziehungen zu klassifizieren. Dies ermöglicht es die Auswirkungen der
Selektion darzustellen.
Die COBIT-Modellbereichsauswahl erfolgt wie auf generischer Ebene beschrieben
durch Metamodellelementselektion und/oder Modellelementselektion.
162
Erfolgt die Modellbereichsauswahl durch Metamodellelementselektion, werden im
Ergebnis COBIT-Metamodell Elemente gelöscht. Dieses Löschen von
Metamodellelementen hat sowohl Auswirkungen auf andere Metamodellelemente als
auch auf die Instanzen des gelöschten Metamodellelements. Aufgrund der
Aggregationsbeziehung zwischen einem Metamodellelement und seinen Instanzen hat
das Löschen von Metamodellelementen nämlich direkte Auswirkungen auf die
Instanzen dieses Elements. Das Löschen eines Metamodellelements bewirkt das
Löschen der zugehörigen Modellelemente. SemGoRiCo unterstützt dies durch die
semantische
Beziehung
„ist
Individuum
von―
zwischen
Begriffen
(Metamodellelementen) und den dazugehörigen Individuen (Modellelementen). In
Abbildung 43 ist für einige Aktivitäten beispielhaft zu sehen, dass das
Metamodellelement Aktivität (in der Projektterminologie als Activity Prototyp
bezeichnet) und zugehörige konkrete Aktivitäten (Modellelemente) durch die
Beziehung „ist Individuum von“ verbunden sind. Aus dieser Beziehung resultiert das
Löschen aller konkreten Aktivitäten wenn das Metamodellobjekt Aktivität gelöscht
wird.
Abbildung 43 Beziehungen zwischen Metamodell- und Modellelementen
Weiterhin hat das Löschen eines Metamodellelements Auswirkungen auf andere
Metamodellelemente. Die Beziehungen zwischen den COBIT-Metamodellelementen
werden daher im Folgenden anhand der im generischen Teil vorgestellten Systematik
klassifiziert.
Die folgenden COBIT-Metamodellelemente stehen in einer assoziativen Beziehung.
 Prozess und Ziel292
 Prozess und IT-Governance-Focus-Area
 Prozess und IT-Ressource
292
Hier wäre auch das Element Metrik betroffen.
163
 Prozess und Information Criteria
 Rolle und Aktivität
 Ziel und Metrik
 IT-Ziel und Prozessziel
 Prozessziel und Aktivitätsziel
In der UML-Darstellung293 des COBIT-Metamodells ist diese Beziehungsart durch
einfache Kanten dargestellt (Abbildung 45). Wird nun eines der Elemente durch die
COBIT-Modellbereichsauswahl gelöscht, wird diese Beziehung ebenfalls gelöscht. Die
der Beziehung anhaftende Information entfällt demnach zusätzlich. Steht das zweite
Element, wie im Fall von COBIT häufig, mit keinem weiteren Element in Beziehung,
entfällt dieses Element ebenfalls. D.h. das Entfernen des Elements Aktivität führt
ebenfalls dazu, dass das Element Rolle entfernt wird.294
Wird nicht das Metamodellelement, sondern eine Instanz (Modellelement) gelöscht,
kommt es im Falle von assoziativen Beziehungen lediglich zum Informationsverlust.
Das Löschen einer bestimmten Aktivität führt etwa dazu, dass die Verbindungen zu
bestimmten Rollen gelöscht werden. Neben diesem Informationsverlust kommt es
jedoch nicht zu weiteren Auswirkungen.
Weiterhin können Metamodellelemente in einer Generalisierungsbeziehung stehen. Im
Falle dieser gerichteten Beziehung fallen die speziellen Elemente weg, wenn das
generelle Element entfernt wird. Im Falle von COBIT stehen folgende
Metamodellelemente in einer solchen Beziehung:
 Ziel und IT-Ziel
 Ziel und Prozessziel
 Ziel und Aktivitätsziel
 Ergebnis und Input
 Ergebnis und Output
Wird im Metamodell das Element Ziel entfernt, entfallen auch die speziellen
Zielarten.295 Wird ein spezielles Element gelöscht, hat dies keine unmittelbaren
Auswirkungen auf das generelle Element. D.h. wenn im Metamodell eine spezielle
Zielart gelöscht wird, beinhaltet das Element Ziel weiterhin alle Instanzen. In diesem
Fall kann auf Modellebene jedoch kein Ziel mehr als ein solches spezielles Ziel
klassifiziert werden. Die Unterteilung der Ziele ist somit beschränkt.
293
An dieser Stelle wurde die Darstellung mittels UML gewählt, da die Syntax es ermöglicht die
notwendigen unterschiedlichen Relationen darzustellen.
294 Eventuelle Modellerweiterungen, die diese Auswirkung verhindern werden im entsprechenden Kapitel
diskutiert.
295 Spezielle Elemente bezeichnen in diesem Absatz den Gegensatz zu generellen Elementen. Die
Instanzen von Metamodellelementen werden daher in diesem Absatz als konkrete Elemente bezeichnet.
164
Werden durch die Modellelementselektion eine oder mehrere Instanzen des generellen
Elements Ziel gelöscht, d.h. bspw. die Ziele eines Prozesses, betrifft dies alle
Zielformen. Wird ein Aktivitätsziel gelöscht, hat dies keine Auswirkungen auf andere
Instanzen, die durch die Generalisierungsbeziehungen begründet sind.
Die dritte Form der Beziehung ist die Aggregationsbeziehung. Die
Metamodellelementselektion eines aggregierenden Elements führt in diesem Fall dazu,
dass die Teilelemente ebenfalls entfallen, da die Elemente eine Einheit bilden. Stehen
zwei Elemente in einer Aggregationsbeziehung, führt das Löschen eines
Modellelements ebenfalls zum Löschen des verbundenen Modellelements. Folgende
COBIT-Elemente stehen in einer solchen Beziehung und bilden daher aus Sicht der
Selektion eine Einheit:
 Prozess und Control Objective sowie Control Practice
 Prozess und Reifegrad sowie Reifegradmodell
 Prozess und Aktivität (betrifft auch Rolle)
 Prozess und Ergebnis
 Domäne und Prozess
Die COBIT-Metamodellelemente, die in einer Aggregationsbeziehung stehen, werden
in Abbildung 44 gesondert dargestellt. Hier ist zu sehen, dass im Falle der Selektion
eines bestimmten Prozesses auch seine Control Objektives, Control Practices,
Reifegrade, Aktivitäten und Ergebnisse gelöscht werden. Wird eine Domäne entfernt,
werden aufgrund der Aggregationsbeziehung auch die dazugehörigen Prozesse gelöscht.
Im umgekehrten Fall ist jedoch eine bestimmte Domäne nur mittelbar vom Löschen
eines Prozesses betroffen, denn solange weitere Prozesse Teil der Domäne sind, bleibt
die Domäne bestehen.
165
Aktivität
Ergebnis
Control
Objective
Prozess
Control
Practice
Domäne
Reifegrad
Reifegradmodell
Abbildung 44 Aggregationsbeziehungen zwischen COBIT-Elementen
Die Aggregationsbeziehung zwischen den Metamodellelementen Prozess und Ergebnis
führt zu weitreichenden Konsequenzen. Über das Element Ergebnis stehen die COBITProzesse in einer Input-Output-Beziehung (Abbildung 45).296 Der Output eines
Prozesses ist wiederum Input für einen anderen Prozess. Das Löschen eines Prozesses
auf Modellebene führt dann dazu, dass ein Ergebnis nicht entsteht und wenn dieses
Ergebnis Input eines anderen Prozesses ist läuft dieser Prozess nicht ab. Erfolgt also
eine Modellelementselektion eines konkreten Prozesses ist zu prüfen, ob der Output
Input eines weiteren Prozesses ist.
296
Siehe u.a. Becker et al. 2002a; Becker et al. 2003, S. 48; Kurpjuweit 2009 nennt hier die reflexive
Assoziation zwischen zwei gleichartigen Objekten.
166
Rolle
Control
Objective
Aktivität
gebraucht
Ergebnis
Control
Practice
IT-Ressource
Prozess
Domäne
Input
unterstützt
Output
unterstützt
gehört zu
adressiert
Information
Criteria
Reifegrad
IT-Ziel
Ziel
Prozessziel
misst
unterstützt
unterstützt
Aktivitätsziel
Metrik
IT
Governance
Focus Area
Reifegradmodell
Abbildung 45 Beziehungen zwischen den COBIT-Metamodellelementen
Abbildung 45 zeigt die Beziehungen zwischen den Metamodellelementen von COBIT.
Anhand dieser Beziehungen lassen sich, wie beschrieben, die Auswirkungen der
Modellbereichsauswahl nachvollziehen.
Das Aufzeigen der Auswirkungen der Modellbereichsauswahl unterstützt SemGoRiCo
durch Expertensuchen. SemGoRiCo ermöglicht es dem Anwender, die Auswirkungen
der Modellbereichsauswahl für jeden Prozess zu visualisieren. Abbildung 46 zeigt eine
Expertensuche, die aufzeigt, welche Input-Output-Beziehungen durch eine bestimmte
Modellbereichsauswahl betroffen bzw. beschädigt sind. Konkret zeigt diese
Expertensuche, welche anderen COBIT-Prozesse keinen Input mehr erhielten, würde
der COBIT-Prozess AI6 nicht umgesetzt. Wird der Prozess AI6 also im Zuge der
Modellbereichsauswahl gelöscht, erhalten die angezeigten Prozesse nicht den
notwendigen Input und werden demnach nicht oder nur in Teilen ausgeführt. Weiterhin
können durch die graphische Darstellung der Zusammenhänge innerhalb des
semantischen Netzes Konsequenzen verdeutlicht werden. Die Darstellung des COBITModells im sogenannten Net-Navigator unterstützt hier den Anwender. Das
automatische Anzeigen aller Konsequenzen der Selektion ist jedoch bislang noch nicht
umgesetzt.
167
Die aufgezeigten Konsequenzen müssen vom Anwenderunternehmen bedacht werden.
Wie auf generischer Ebene definiert, bestehen im Falle von als untragbar definierten
Konsequenzen folgende Möglichkeiten: Rücknahme der Selektion oder
Modellerweiterung. Die Rücknahme der Selektion unterstützt SemGoRiCo durch die
Möglichkeit, Begriffe und Individuen zunächst nur auszublenden, die Rücknahme der
Selektion, d.h. das Wiedereinblenden ist dadurch stark vereinfacht. Die Möglichkeit
COBIT zu erweitern wird in Unterkapitel 6.3.1.3 beschrieben.
Abbildung 46 Aktivität: Modellbereichsauswahl – Expertensuche
168
Modellbereichauswahl über Typen, Hierarchiestufen und Attribute
In Kapitel 5 wurden verschiedene Arten der Selektion beschrieben. Diese werden nun
für COBIT konkretisiert, indem im COBIT-Modell Typen, Hierarchiestufen oder
Attribute gesucht werden, die eine systematische Modellbereichsauswahl ermöglichen.
Hier ist zunächst fraglich, ob eine Unterscheidung zwischen Typen und Attributen im
Falle von COBIT überhaupt notwendig ist. In diesem Fall erfolgt die Typisierung der
Modellbereiche sowie das Belegen der Modellbereiche mit Attributen durch den
Anwender. Begreift man bspw. die Einteilung der COBIT-Prozess in die vier Domänen
als Typisierung, entstünden vier Typen. Ebenso könnte man die Domäne als Attribut
eines Prozesses begreifen, welches vier Ausprägungen haben kann.297 Für den hier
vorliegenden Fall ist die Unterscheidung jedoch nicht relevant. Relevant ist hingegen,
dass Typen und Attribute Informationsträger sind. Daher sind nach Ansicht der
Verfasserin die assoziativen Beziehungen die Basis für die COBITModellbereichsauswahl nach Typen oder Attributen.298 Für COBIT bedeutet dies, dass
das COBIT-Element Prozess anhand der Information Criteria, der Domäne, der ITGovernance-Focus-Area299 oder IT-Ressource eingeteilt werden kann. Die Zuordnung zu
Information Criteria und den IT-Governance-Focus-Areas ist zusätzlich in primäre oder
sekundäre Zuordnung eingeteilt. Diese vier Einteilungen kann man auch an der COBITNavigation erkennen, sie zeigt, dass die Prozessbeschreibung jedes COBIT-Prozesses
graphisch durch die Informationen der assoziativen Beziehungen angereichert ist
(Abbildung 47).
Bezüglich der Thematik „Entität oder Attribut― sei auf die Diskussion in der Literatur verwiesen,
bspw. Scheer 1997, S.32 oder Thalheim 2003, S.13.
298 In welcher Beziehung die einzelnen COBIT-Elemente stehen wird im folgenden Abschnitt diskutiert.
299 Die Zuordnung von Modellelementen zu den zentralen IT-Governance-Focus-Areas (Wertbeitrag,
Alignment, etc.) verwenden Looso et al. 2009 zur Identifikation von Services.
169
297
Abbildung 47 COBIT Navigation (IT Governance Institute 2007, S. 27)
Eine weitere Möglichkeit ist die Einteilung in die Perspektiven der Balanced Scorecard
(BSC). Hier wird die assoziative Beziehung zwischen Prozess und Ziel genutzt. COBIT
teilt jeder Perspektive mehrere von insgesamt 17 Geschäftszielen zu. Diesen 17
Geschäftszielen werden 28 IT-Zielen zugeordnet, welchen wiederum jeweils COBITProzesse zugewiesen sind. Beispielsweise ist das Geschäftsziel „Acquire and maintain
skilled and motivated people― dem IT-Ziel „Acquire and maintain IT skills that respond
to the IT strategy― zugeordnet. Dieses IT-Ziel wird durch die Prozesse PO7 und AI5
verfolgt. Die Einteilung der Prozesse in von ihnen unterstütze Geschäftsziele oder BSCPerspektiven ist demnach eine weitere Möglichkeit die COBIT-Prozesse zu typisieren
oder mit Attributen zu belegen und so die Modellbereichsauswahl zu unterstützen.
170
Eine weitere beschriebene Möglichkeit der Modellbereichsauswahl ist die Zuordnung
der Modellbereiche zu verschiedenen Hierarchiestufen. COBIT kennt bspw. die
folgenden vier Benutzergruppen:
 Executive Management
 Business Management
 IT Management
 Auditors300
Diese Aufteilung wird jedoch nicht für eine Einteilung des BPRM COBIT genutzt.
Durch diese Unterteilung wird vielmehr verdeutlicht, welche COBIT-Publikationen für
welche Benutzergruppe geeignet sind.301Zum Beispiel ist das „Board Briefing on IT
Governance― dem Executive Management zugewiesen. 302 Zusätzlich zu diesen
Benutzergruppen kennt COBIT die folgenden allgemeinen303 Rollen:
 Chief executive officer (CEO)
 Chief financial officer (CFO)
 Business executives
 Chief information officer (CIO)
 Business process owner
 Head operations
 Chief architect
 Head development
 Head IT administration
 Project management officer (PMO)
 Compliance, audit, risk and security management
Anhand dieser Rollen könnte man die COBIT-Prozesse eventuell hierarchisch einteilen.
Hierfür müssten die Rollen den Hierarchiestufen des konkreten Unternehmens
zugewiesen werden. Liegt eine solche Einteilung COBITS nach Hierarchiestufen vor,
ließe sich eine COBIT-Auswahl auf Basis von Hierarchie durchführen. Jedoch liegen
hierfür gegenwärtig keine gesicherten Erkenntnisse vor.
300
IT Governance Institute 2007, S. 7.
Neben dem BPRM COBIT, welches in der Originalpublikation als COBIT-Framework bezeichnet
wird, existieren weitere, eng mit dem COBIT-Framework verbundene, Publikationen der ISACA vor.
Bspw. das Board Briefing on IT-Governance oder der IT-Assurance Guide (siehe IT Governance Institute
2007, S. 7).
303 Manche Prozesse haben zusätzliche spezifische Rollen, z.B. den service desk/incident manager für den
Prozess DS8.
171
301
Abbildung 48 Aktivität: Modellbereichsauswahl -Semantische Suche
Die Auswahl der relevanten COBIT-Modellbereiche über Typen, Hierarchieebenen und
Attribute wird von SemGoRiCo durch Expertensuchen und eine semantische Suche
unterstützt. Diese Suchen kann der Modellbereichsauswahl-Verantwortliche anwenden,
um die relevanten Modellelemente zu identifizieren. Soll bspw. nur die finanzielle
Perspektive der BSC unterstützt werden, kann mithilfe der vorgegebenen Expertensuche
der relevante COBIT-Ausschnitt angezeigt werden. Ebenso wird in der Ansicht jedes
Prozesses angezeigt, welche BSC-Perspektive betroffen ist. Wird COBIT hingegen
eingesetzt, um die Übereinstimmung der Unternehmensabläufe mit gesetzlichen oder
anderen regulatorischen Anforderungen zu verbessern, sind bspw. die COBIT-Prozesse
besonders relevant, die das Thema Compliance adressieren.304 Um diese Prozesse zu
identifizieren kann die semantische Suchfunktion verwendet werden. Abbildung 48
zeigt, wie die Modellbereichsauswahl durch eine semantische Suche nach dem Begriff
„Compliance― unterstützt werden kann.
6.3.1.2 COBIT-Modellvariation
Neben der Auswahl des relevanten Ausschnitts sind unter Umständen weitere
Anpassungen an die Unternehmensumstände notwendig. Eine mögliche Anpassung
beschreibt die Aktivität Modellvariation. Auf generischer Ebene wurden die
304
Siehe u.a. Hardy 2006; Tuttle, Vandervelde 2007 und Simonsson et al. 2010.
172
Mechanismen Instanziierung, Spezialisierung und Umbenennen vorgestellt. Diese
werden nun für COBIT konkretisiert.
COBIT-Variation durch Instanziierung
Instanziierung erfolgt an Stellen des COBIT-Modells, die aufgrund eines im Modell
enthaltenen Platzhalters Anlass zur Instanziierung bieten. Fraglich ist nun, welche
COBIT-Elemente einen solchen beispielhaften Charakter haben und daher als zu
instanziierende Platzhalter betrachtet werden können.
Nach Ansicht der Verfasserin sind die Elemente Prozess, Control Objective, Control
Practice, IT-Ressource, Domäne, Information Criteria, Reifegrad, IT-GovernanceFocus-Area und Ergebnis sowie deren Beziehungen nicht für eine Instanziierung
geeignet. Die genannten Elemente sind in COBIT eindeutig definiert und haben daher
nicht den beispielhaften Charakter eines Platzhaltes. Die Elemente Aktivität, Rolle, Ziel
und Metrik sind hingegen weniger eindeutig definiert. Die Elemente Aktivität und
Rollen sowie deren Beziehung sind jedoch keine Platzhalter, sondern Elemente die
durch Spezialisierung und Umbenennen an die Unternehmensumstände anzupassen
sind. Die Elemente Ziel und Metrik sowie deren Beziehung sind daher bezüglich ihrer
Instanziierbarkeit zu prüfen.
Die Beziehung zwischen den Elementen IT-Ziel, Prozessziel, Aktivitätsziel und den
jeweiligen Metrik ist eindeutig zu instanziierende Elemente. Abbildung 49 zeigt, dass
mehrere IT-Ziele zu mehreren Prozess-Zielen führen. Diese werden wiederum durch
mehrere Aktivitäts-Ziele unterstützt. Ebenso werden jeweils mehrere Ziele durch
mehrere Metriken gemessen. Die Zuordnung ist dort ebenfalls nicht eindeutig, noch
stimmt die Anzahl überein. Die gezeigten Beziehungen sind nach Ansicht der
Verfasserin Platzhalter und es ist daher notwendig, Ziele und Metriken einander
zuzuweisen, d.h. die Beziehungen zu instanziieren.
173
Goals
Metrics
IT
Process
IT Goal 1
IT Goal 2
...
set
Process Goal 1
Process Goal 2
Process Goal 3
...
set
A. Goal 1
A. Goal 2
...
measure
drive
measure
drive
measure
IT Metric 1
...
Process Metric 1
Process Metric 2
Process Metric 3
Process Metric 4
...
Activities
A. Metric 1
A. Metric 2
A. Metric 3
…
Abbildung 49 Beziehungen der COBIT-Ziele und –Metriken (Darstellung in Anlehnung an IT
Governance Institute 2007, S. 23)
Sollen die von COBIT vorgeschlagenen Ziele und Metriken (bspw. nach einer
Anpassung) im Unternehmen zur Messung verwendet werden, ist es notwendig, die
Beziehungen zu konkretisieren. Dies unterstützt SemGoRiCo dadurch, dass zunächst
alle Ziele und Metriken nach Art eines kartesischen Produkts miteinander verbunden
sind. Um die Zuordnung an die Unternehmensumstände anzupassen, sind die nicht
zutreffenden Beziehungen zu entfernen.
174
Abbildung 50 Ziele und Metriken am Beispiel AI6: Manage Changes
Abbildung 50 zeigt am Beispiel des COBIT-Prozesses „AI6: Manage Changes― wie
dies durch SemGoRiCo unterstützt wird. So kann das IT-Ziel „Reduce solution and
service delivery defects and rework― im angepassten COBIT konkret dem Prozess-Ziel
„Minimise errors due to imcomplete request specifications― zugewiesen werden. Dieses
wiederum wird dem Aktivitäts-Ziel „Defining and communicating change procedures,
including emergeny changes and patches― zugewiesen. Das konkrete Aktivitäts-Ziel des
COBIT-Prozesses AI6 wird durch das Ziehen einer Relation der Metrik „Percent of
changes that follow formal change control processes― zugeordnet, also konkret durch
diese Metrik gemessen.
Um COBIT in einem Unternehmen anzuwenden, ist es nach Ansicht der Verfasserin
außerdem notwendig, Teile der Beschreibung von Zielen und Metriken als Platzhalter
zu betrachten, die ebenfalls instanziiert werden müssen. Abbildung 51 zeigt ein
Beispiel. Die Metrik „Percent of Projects meeting Stakeholders Expectations― des
Prozesses PO 10, enthält den Platzhalter Stakeholder-Anforderungen. Erst durch eine
Instanziierung wird diese Metrik messbar. Möglich ist bspw., dass Stakeholder die
Einhaltung des ISO9000 Standards fordern. Ebenso können die StakeholderAnforderungen auch aufgelistet werden.
175
Process
ReferenceProcess PO 10
Companys
Process PO 10
Manage Projects
supports
Goal
is
measured
by
Metric
supports
Deliver Projects
on Time and on
Budget meeting
Quality
Standards
is
measured
by
Percent of
Projects meeting
Stakeholders
Expectations
supports
Deliver Projects
on Time and on
Budget meeting
Quality
Standards
is
measured
by
Percent of
Projects meeting
ISO9000
requirements
Abbildung 51 Modellvariation durch Instanziierung
Modellvariation durch Spezialisierung
Eine weitere Möglichkeit der Veränderung ist die Spezialisierung. Spezialisierung
erfolgt immer dort, wo Modellbereiche für ein bestimmtes Unternehmen nicht detailliert
genug sind. Wie bereits kurz angedeutet, sind die Aktivitäten sowie die Beziehungen zu
den ihnen zugewiesenen Rollen durch das anwendende Unternehmen zu spezialisieren.
Über die zu spezialisierenden Stellen des COBIT Modells gibt es jedoch keine
eindeutigen Hinweise und keine wissenschaftlichen Erkenntnisse. Auch im Rahmen
dieses Forschungsvorhaben konnten keine gesicherten Erkenntnisse bezüglich der
Spezialisierung von COBIT erzielt werden. SemGoRiCo bietet demnach auch noch
keine Unterstützung zum Auffinden von zu spezialisierenden Stellen, jedoch wird die
Spezialisierung generell durch die editierbare Gestaltung der semantischen Netze
unterstützt.
Variation durch Umbenennen
Das Umbenennen von Modellelementen ist eine weitere Möglichkeit der COBITVariation. Im Zuge dieser Aktivität werden Modellbereiche von COBIT umbenannt und
so an das anwendende Unternehmen angepasst. In SemGoRiCo sind die Bezeichnungen
aller Elemente und Beziehungen frei editierbar. Abbildung 52 zeigt dies an einer Rolle
des RACI-Charts. Das RACI-Chart beinhaltet die Rollen der COBIT-Prozesse. Eine
von COBIT vorgesehene Rolle ist zum Beispiel der Chief Information Officer (CIO).
Diese Rolle kann nun etwa in die, im Unternehmen gebräuchliche, Bezeichnung ITLeiter umbenannt werden.
176
Abbildung 52 Modellvariation durch Umbenennen
6.3.1.3 COBIT-Modellerweiterung
Die Aktivität Modellerweiterung transformiert COBIT in ein erweitertes COBIT. In den
Ausführungen auf generischer Ebene wurde Erweiterung definiert als das Hinzufügen
neuer Elemente oder Beziehungen. Die Erweiterung kann erneut auf Metamodell- und
auf Modellebene erfolgen, wobei das Hinzufügen eines Metamodellelements zwingende
Auswirkungen auf der Modellebene hat.
Abbildung 53 zeigt eine Metamodellerweiterung des COBIT-Modells durch
Hinzufügen des Metamodellelements Teilaktivität. Dies erfordert zusätzlich eine neue
Beziehung. Diese Erweiterung ermöglicht eine erhebliche inhaltliche Erweiterung auf
Modellebene, denn die Aktivitäten aller 34 Prozesse könnten nun in Teilaktivitäten
aufgespalten werden.
177
Sub-Activity
(1,*)
is
contained
in
(1,1)
(1,*)
(1,*)
is related
to
Role
Control
Objective
Activity
(1,*)
(1,1)
(1,*)
Control Practice
(1,*)
(0,*)
Input
is
contained
in
uses /
needs
(1,1)
IT-Resource
Output
is
contained
in
is
contained
in
isa
(1,*)
(1,4)
Domain
belongs to
is used by
(1,1)
(0,*)
(0,*)
(1,*)
(1,1)
Result
(1,1)
(1,*)
Process
(1,*)
is created
by
(1,7)
Information
Criteria
(1,1)
Maturity Level
(1,*)
(0,*)
supports
adresses
has
supports
(1,*)
IT Goal
(1,*)
Process Goal
isa
(1,5)
IT Governance
Focus Area
Goal
is
determined
by
(1,*)
Activity Goal
is
measured
by
(1,1)
(1,*)
Metric
Maturity Model
Abbildung 53 Modellerweiterung durch Hinzufügen eines Metamodellelements
Das Hinzufügen eines neuen Metamodellelements und einer neuen Beziehung erfordert
in SemGoRiCo den Einsatz des Entwicklungswerkzeugs. Dies ist so implementiert
worden, da diese Erweiterungen erhebliche Auswirkungen auf das Modell haben. Eine
solche Erweiterung erfordert einen neuen Begriff im semantischen Begriffsnetz. Dieser
Begriff wird über Beziehungen in das Begriffsnetz eingebunden und kann Individuen
haben.
178
Abbildung 54 Hinzufügen eines Metamodellelements in SemGoRiCo
Daneben kann COBIT auf Modellebene erweitert werden. Dies erfolgt durch eine neue
Instanz eines bereits vorhandenen Metamodellelements. Abbildung 55 zeigt, wie eine
zusätzliche Metrik hinzugefügt wird. Die Beziehung bleibt dieselbe wie im Metamodell
vorgeschrieben.
Process
Companys
Process PO 10
Manage Projects
supports
supports
Goal
Deliver Projects
on Time and on
Budget meeting
Quality
Standards
is
measured
by
is
measured
by
Metric
Percent of Projects meeting 90% of
ISO9000 requirements
Percent of Projects on Time (1,25fold of target duration)
Abbildung 55 Modellerweiterung durch neue Instanzen
In Anlehnung an die Erläuterungen auf generischer Ebene können sich Beziehungen
zwischen COBIT-Modellbereichen auch auf die Erweiterung auswirken. Wird ein
Modellelement hinzugefügt, das laut COBIT-Metamodell mit anderen Modellelementen
in einer Aggregationsbeziehung steht, müssen diese anderen Modellelemente ebenfalls
neu erstellt werden. Abbildung 44 zeigt diesen Zusammenhang im Zuge der Selektion.
Gleiches gilt auch für die Erweiterung. Wird bspw. zu COBIT ein 35. Prozess
hinzugefügt, sind auch dessen Aktivitäten, Control Objectives, Reifegrade und
Ergebnisse zu entwerfen. Wird eine neue Domäne hinzugefügt, sind dieser entweder
179
vorhandene Prozesse zuzuordnen (Modellerweiterung um neue Beziehungen) oder es
sind zusätzliche Prozesse zu erstellen (Modellerweiterung um neue Elemente).
Assoziative Beziehung können ebenfalls neu hinzugefügt werden, im Beispiel könnte
der 35. Prozess einer Domäne oder einer IT-Governance-Focus-Area etc. zugewiesen
werden.
Sollen zwischen Modellelementen Beziehungen gezogen werden, müssen diese
zwischen den korrespondierenden Metamodellelementen ebenfalls existieren. Wird also
bspw. ein neuer Prozess erstellt, stehen die zugehörigen Control Objective mit ihm in
einer Aggregationsbeziehung.
Abbildung 56 Modellerweiterung durch neue Relationen
Das Ziehen neuer Relationen ist eine Möglichkeit, mit unerwünschten Konsequenzen
der Modellbereichsauswahl umzugehen. Abbildung 56 zeigt diese Möglichkeiten auf
Metaebene. Wird das Metamodellelement Control Objective gelöscht, würde aufgrund
der Beziehungen im COBIT-Metamodell auch das Element Control Practice wegfallen.
Durch das Ziehen neuer Relationen ist jedoch die Zuordnung der Control Practices zum
Prozess möglich. Das Ziehen dieser Relation auf Metaebene ermöglicht die Existenz
von Beziehungen zwischen konkreten Prozessen und konkreten Control Practices. Ohne
diese Meta-Relation wären Beziehungen auf Modellebene zwischen diesen Elementen
180
nicht möglich. D.h. durch die eingefügte Beziehung auf Metaebene ist eine Relation
zwischen AI6 „Manage Changes― und der Control Practice „Ensure that all emergency
access arrangements for changes are appropriately authorised, documented and revoked
after the change has been applied― möglich.
6.3.2 Aktivitäten der COBIT-Anwendung
6.3.2.1 COBIT-Aktivität: Vergleich
Diese Aktivität ist für den Einsatz von COBIT von besonderer Bedeutung. Begründet
liegt dies darin, dass die Aktivität dem ursprünglichen prüfungsorientierten
Einsatzzweck des COBIT-Modells entspricht.305 Es gibt verschiedene Möglichkeiten,
COBIT vergleichend einzusetzen. Grundsätzlich können alle Ergebnisse der Methode
miteinander verglichen werden.
Wie in Kapitel 5.3.3.1 beschrieben, sind daher für einen Vergleich zunächst die beiden
relevanten Ergebnistypen auszuwählen, bevor deren Ähnlichkeiten und Unterschiede
klassifiziert werden. Dieser Prozess basiert wie bereits beschrieben in großen Teilen auf
den Beurteilungen der Anwender. Der Grad der Subjektivität dieser Beurteilungen
verändert sich jedoch mit den zu vergleichenden Ergebnissen. Denn ein Vergleich von
COBIT mit einem unstrukturiert vorliegenden Unternehmensmodell erfordert mehr
subjektive Einschätzungen von den Verantwortlichen als der Vergleich von zwei
zumindest semi-strukturierten Modellen. Der Vergleich eines variierten COBITAusschnitts mit COBIT kann bspw. aufgrund der strukturellen Ähnlichkeit der
Ergebnistypen objektiver erfolgen.
Der Vergleich des vorliegenden Unternehmensmodells mit dem unveränderten COBITModell wird bereits durch SemGoRiCo unterstützt. Das sogenannte GovernanceAssessment ermöglicht den Verantwortlichen im Unternehmen einen Vergleich von
COBIT und dem Unternehmensmodell vorzunehmen. Dieser Vergleich basiert auf den
Prozessergebnissen und den Control Objectives. Die Control Objectives wurden
verwendet, da diese aufgrund des originären Zwecks von COBIT besonders im Fokus
des Vergleichs stehen. Diese Aktivität beruht weitestgehend auf Selbsteinschätzungen
der Verantwortlichen. Dies liegt darin begründet, dass ein Unternehmensmodell völlig
unstrukturiert vorliegen kann.
305
Siehe u.a. PWC 2006; Rüter et al. 2006; Trites 2004; Fröhlich, Glasner 2007; Silva 2008 sowie die im
generischen Teil genannten Quellen.
181
Abbildung 57 COBIT-Aktivität: Vergleich – Governance-Assessment
Abbildung 57 zeigt, wie SemGoRiCo den Vergleich unterstützt. Zunächst werden die
Ergebnisse (Inputs und Outputs) der einzelnen COBIT-Prozesse systematisch
aufgelistet. Der Anwender hat jeweils zu entscheiden ob ein solches Dokument im
Unternehmen vorliegt.306 Zusätzlich besteht die Möglichkeit das Dokument direkt
hochzuladen. In einem zweiten Schritt werden alle COBIT-Prozesse anhand ihrer
306
Die in Kapitel 5 gezeigte Unterteilung der Konfliktarten wurde für SemGoRiCo bislang nicht
verwendet.
182
einzelnen Control Objectives aufgeführt, der Anwender muss dann beurteilen,
inwieweit das Unternehmensmodell den genannten Anforderungen entspricht. Um den
Grad der Übereinstimmung anzuzeigen, wird eine Ampel verwendet. Das Ergebnis der
beiden Vergleichsrunden wird graphisch und prozentual angezeigt.
Durch seine Mehrbenutzerfähigkeit ermöglicht SemGoRiCo, dass das GovernanceAssessment von einer Gruppe arbeitsteilig durchgeführt wird, liegen jedoch
verschiedene Einschätzungen zu einem Sachverhalt vor, bietet SemGoRiCo lediglich
die Möglichkeit, diese verschiedenen Einschätzungen anzuzeigen. Wessen
Einschätzung in den Vergleich eingehen soll, ist von den Verantwortlichen zu
entscheiden.
Die Aktivität Governance-Assessment ist ein Vergleich zwischen COBIT und dem
vorhandenen Unternehmensmodell. Bislang unterstützt SemGoRiCo also den Vergleich
von zwei ganz bestimmten COBIT-Ergebnistypen. Die SemGoRiCo-Aktivität
Governance-Assessment ist jedoch sehr generisch angelegt und wird zukünftig auch für
den Vergleich unterschiedlichster COBIT-Ergebnistypen zur Verfügung stehen.
6.3.2.2 COBIT-Aktivität: Gestaltung
Wie im generischen Teil beschrieben, vervollständig die generische Aktivität
Gestaltung die Systematik der Anpassung und Anwendung von BPRM. Die konkreten
Schritte der Umsetzung von COBIT oder einer angepassten Version in einem
Unternehmen basieren jedoch vor allem auf Forschungsergebnissen aus dem
Projektmanagement und der Unternehmensmodellierung und sind nicht Teil dieses
Forschungsvorhabens. Die Umsetzung von COBIT im Unternehmen ist allerdings Teil
des SemGoRiCo-Projekts und damit Bestandteil zukünftiger Forschungsprojekte des
IT-Governance-Practice-Networks.
6.4 Zwischenfazit
In diesem Kapitel wurde die Methode zur Anwendung von COBIT unter
Berücksichtigung der bereits erzielten Ergebnisse des Forschungsprojekts SemGoRiCo
erläutert. Die konkreten Elemente der Methode zur Anwendung von COBIT wurden
hierfür aus der generischen Methode abgeleitet.
Die Methodenelemente der COBIT-Methode, die bereits durch SemGoRiCo unterstützt
werden, wurden unter Rückgriff auf die Projektergebnisse erläutert. Zukünftig soll
SemGoRiCo alle Methodenelemente der COBIT-Methode unterstützen. Im Verlauf des
SemGoRiCo-Projekts wird jedoch auch auf die Methodenelemente der generischen
Methode Bezug genommen, da eine Erweiterung von SemGoRiCo auf andere BPRM
geplant ist. Die generische Beschreibung der Methodenelemente ist also auch für das
praxisnahe Projekt vorteilhaft, da sie eine Erweiterung der Werkzeugunterstützung auf
andere BPRM unterstützt.
183
7 Methode zur Anpassung und Anwendung von CMMI
Das Referenzmodell Capability Maturity Model Integration (CMMI)307 dient der
Verbesserung von Beschaffung, Entwicklung, Betrieb und Wartung von Software. Es
wurde vom Software Engineering Institute (SEI), einem mit Regierungsmitteln
finanzierten Forschungs- und Entwicklungszentrum der Carnegie Mellon Universität in
Pittsburgh, USA, entwickelt.308
Die Anpassung und Anwendung von CMMI mithilfe der vorgestellten Methode wird in
diesem Kapitel exemplarisch demonstriert. Insbesondere wird gezeigt, dass die
Besonderheiten des BPRM durch die generische Methode abzubilden sind. Ziel dieser
erneuten Anwendung ist es, die Allgemeingültigkeit des generischen Artefakts weiter zu
untermauern. Hierfür werden zunächst die CMMI-spezifischen Ergebnistypen
vorgestellt, bevor die spezifischen Aktivitäten der Anpassung und Anwendung von
CMMI beschrieben werden.
Das im generischen Teil vorgestellte Metamodell der Ergebnisse (siehe Abbildung 22)
erweist sich auch für CMMI als anwendbar. Die spezifischen Ergebnisse der Methode
zur Anpassung und Anwendung von CMMI und deren Anordnung zeigt Abbildung 58.
307
Die Ausführungen zu CMMI basieren zum größten Teil auf den primären CMMI-Publikationen des
SEI (siehe Software Engineering Institute 2007).
308 Johannsen, Goeken 2010; Kneuper 2003; Software Engineering Institute 2007.
184
Metamodellebene
Modellebene
CMMIMM
wird angepasst zu
wird
abgeleitet zu
wird
abgeleitet zu
CMMI
wird angepasst zu
wird
angewendet
auf
Unternehmensmodell
MyCMMI
wird
angewendet
auf
CMMIAusschnitt
Referenzebene
CMMIVariation
erweitertes
CMMI
Unternehmensebene
Abbildung 58 Ergebnisse der Methode zur Anwendung von CMMI
Die in Abbildung 58 dargestellten CMMI-Ergebnisse unterscheiden sich synonym zu
den Ausführungen in den vorherigen Kapiteln. D.h. die Ergebnisse CMMI und
MyCMMI unterscheiden sich bspw. dahingehend, dass letzteres an die Besonderheiten
und Bedürfnisse des Unternehmens angepasst wurde. Für die weiteren Ausführungen ist
insbesondere das Ergebnis CMMI-Metamodell maßgeblich (Abbildung 59).
Wie im Metamodell deutlich wird, enthält CMMI Prozessgebiete. Diese sind in
Kategorien unterteilt, d.h. jedes Prozessgebiet gehört zu einer Kategorie. Prozessgebiete
haben spezifische Ziele welche durch spezifische Aktivitäten adressiert werden. Diese
werden wiederum unterteilt in Teilaktivitäten. Der Output dieser Teilaktivitäten sind
sogenannte Arbeitsergebnisse. Neben diesen prozessgebietsspezifischen Elementen sind
jedem Prozessgebiet generische Ziele und Aktivitäten zugeordnet, diese sind jedoch
nicht überschneidungsfrei und kommen innerhalb des BPRM mehrfach vor.
185
Reifegrad
isa
Grad
wird
zugeordn
et
gehört zu
Prozessgebiet
Fähigkeitsgrad
hat
hat
Spezifisches Ziel
Generisches Ziel
wird
adressiert
durch
wird
adressiert
durch
Spezifische
Aktivität
Generische
Aktivität
Kategorie
hat
Teilaktivität
liefert
Arbeitsergebnis
Abbildung 59 Metamodell von CMMI
Weiterhin sind die Prozessgebiete verschiedenen Graden zugeordnet. Hierbei wird
zwischen Maturity und Capability unterschieden. Im deutschsprachigen Raum haben
sich für diese Unterscheidung die Begriffe Reifegrad und Fähigkeitsgrad entwickelt.309
Der Fähigkeitsgrad bezieht sich auf ein einzelnes Prozessgebiet. In diesem sogenannten
kontinuierlichen Ansatz werden die Prozessgebiete einzeln bewertet. Dies bedeutet,
dass die Prozessgebiete einzeln verschiedene Fähigkeitsgrade haben und diese auch
einzeln und unabhängig verbessern können. Durch diese einzelne Betrachtung lassen
sich die Prozessbereiche innerhalb von Organisationen und darüber hinaus vergleichen.
Neben dem Fähigkeitsgrad einzelner Prozessgebiete lässt sich mithilfe von CMMI die
Reife einer ganzen Organisation bewerten. In diesem sogenannten Stufenmodell
repräsentieren die Reifegrade ein definiertes Stadium in der Entwicklung von
vordefinierten Prozessbereichen. Für das Erreichen eines Reifegrades müssen innerhalb
der Organisation bestimmte Prozessgebiete in einer festgelegten Qualität vorliegen.
Bereits durch die exemplarische Anwendung der generischen Erkenntnisse auf CMMI
wird deutlich, dass die vorgestellten Ergebnistypen der generischen Methode auch auf
CMMI anwendbar sind. Das hier vorgestellte Metamodell wird nun im Folgenden als
Ergebnis einer spezifischen CMMI-Methode verwendet.
309
Johannsen, Goeken 2010.
186
Nun ist weiter zu überprüfen ob auch die Aktivitäten der Methode auf CMMI
anwendbar sind. Die generische Methode unterteilt Aktivitäten der Modellanpassung
und Aktivitäten der Modellanwendung. Für diese exemplarische Darstellung werden
stellvertretend für diese beiden Aktivitätsarten die Modellbereichsanpassung und der
Vergleich thematisiert.
Die Zuweisung von Prozessgebieten zu Reifegraden unterstützt die Modellbereichsauswahl, genauer die Modellelementselektion. Eine Selektion erfolgt bei CMMI
zumeist über die Instanzen des Metamodellelements Prozessgebiet. D.h. ein CMMIAusschnitt hat zumeist weniger Prozessgebiete als das Ursprungsmodell. Die Auswahl
von Prozessgebieten aufgrund der Zuordnung zu einem bestimmten Reifegrad ist eine
Modellbereichsauswahl über Typen. Die Typisierung ist im Fall von CMMI sogar
Bestandteil des BPRM.310 Die Modellbereichsauswahl aufgrund des Typs <<Notwendig
für Reifegrad 2>> ergibt den folgenden CMMI-Ausschnitt:
 Configuration Management (CM)
 Measurement and Analysis (MA)
 Project Monitoring and Control (PMC)
 Project Planning (PP)
 Process and Product Quality Assurance (PPQA)
 Requirements Management (REQM)
 Supplier Agreement Management (SAM)
Liegt der Typ „Notwendig für Reifegrad 3― der Modellelementselektion zugrunde
kommen elf weitere Prozessgebiete hinzu.
Bezüglich der Metamodellelementselektion gelten die Ausführungen der generischen
Methode analog. Die Beziehungen zwischen den Metamodellelementen sind exakt zu
beschreiben. Hierfür werden, wie in den generischen Ausführungen erläutert, die drei
Grundformen Assoziationsbeziehung, Generalisierungsbeziehung und Aggregationsbeziehung verwendet.
Zwischen den Metamodellelementen im BPRM CMMI liegen folgende Beziehungen
vor:
Assoziationsbeziehungen
 Prozessgebiet – Grad
Generalisierungsbeziehungen
 Grad – Reifegrad
 Grad – Fähigkeitsgrad
Aggregationsbeziehungen
 Kategorie – Prozessgebiet
 Prozessgebiet – Spezifisches Ziel
310
SEI 2007, S. 8ff.
187





Prozessgebiet – Generisches Ziel
Spezifisches Ziel – Spezifische Aktivität
Spezifische Aktivität – Teilaktivität
Teilaktivität – Arbeitsergebnis
Generisches Ziel – Generische Aktivität
Diese Beziehungen sind während der Modellbereichsauswahl zu berücksichtigen. Dem
anwendenden Unternehmen muss bspw. bewusst sein, dass wenn im Zuge der
Metamodellelementselektion entschieden wird auf die generischen Ziele zu verzichten,
auch die generischen Aktivitäten des CMMI-Modells entfallen. Die Klassifizierung der
Beziehungen zwischen den Metamodellelementen von CMMI ergibt das in Abbildung
60 dargestellte Bild.
Fähigkeitsgrad
Grad
Prozessgebiet
Kategorie
Reifegrad
Generisches
Ziel
Spezifisches
Ziel
Generische
Aktivität
Spezifische
Aktivität
Teilaktivität
Arbeitsergebnis
Abbildung 60 Klassifizierung der Beziehungen im CMMI-Metamodell
Die in der generischen Methode beschriebenen Aktivitäten der Anwendung sind
Vergleich und Gestaltung. Die generische Aktivität Vergleich hat innerhalb von CMMI
einen besonders hohen Stellenwert. Der Vergleich zwischen den Ergebnissen CMMI
und dem vorhandenen Unternehmensmodell wird in CMMI durch ein sogenanntes
SCAMPI unterstützt. SCAMPI steht für Standard CMMI Appraisal Method for Process
188
Improvement. Diese Appraisals gibt es in drei Stufen. Um den Reife- oder
Fähigkeitsgrad eines Unternehmens zu bestimmen erfolgt ein Appraisal der Klasse A.
Diese haben einen hohen Anspruch an Zuverlässigkeit und Genauigkeit, erfordern einen
hohen Aufwand und werden daher üblicherweise nur dann durchgeführt, wenn
Unternehmen nach einem Prozessverbesserungsprozess einen höheren Reifegrad
erreicht haben und dies nachweisen wollen.
Ein SCAMPI der Klasse B und C erhält keine exakte Aussage zum Fähigkeits- oder
Reifegrad einer Organisation. Sie werden aber häufig zur initialen Standortbestimmung
verwendet und eignen sich gut für den internen Gebrauch, etwa zur laufenden
Fortschrittskontrolle.311 Die generischen Ausführungen zur Aktivität Vergleich lassen
sich gut auf die Vergleichsaktivität aus dem CMMI-Umfeld transformieren. So
verwendet sie SCAMPI-Methodik auch einen Vergleich mit verschieden klassifizierten
Unterschieden zwischen dem Unternehmensmodell und den Vorgaben von CMMI. Die
generischen Ausführungen behalten demnach auch für CMMI ihre Gültigkeit.
Anhand der gezeigten exemplarischen Anwendung der generischen Methode auf ein
weiteres BPRM kann die Annahme der Allgemeingültigkeit weiter gestärkt werden. Ob
die Allgemeingültigkeit des Artefakts überhaupt zweifelsfrei nachzuweisen ist und
andere Fragen der Evaluation sind Bestandteil des folgenden Kapitels.
8 Kritische Würdigung
Zur Beurteilung von Artefakten, die in einem konstruktionsorientierten
Forschungsprozess erstellt wurden, haben sich die Kriterien der Design-ScienceForschung von Hevner et al. etabliert.312 Die sieben Richtlinien von Hevner et al.313
werden daher im Verlauf verwendet um die hier erzielten Forschungsergebnisse kritisch
zu beleuchten.
Richtlinie 1:
Die erste Richtlinie besagt, dass konstruktionsorientierte Forschung ein innovatives
Artefakt erschaffen soll, welches der Erfüllung einer Aufgabe der Realität dient und
somit ein vorhandenes Problem löst.
Die Anpassung und Anwendung von BPRM wird bislang nicht durch wissenschaftlich
fundierte Methoden unterstützt. Die systematische Gestaltung des Anwendungs311
Siehe Johannsen, Goeken 2010 oder Kneuper 2003.
Die Richtlinien wurden zunächst als Leitlinien zur Steigerung der Publikationsfähigkeit von
Ergebnissen der Design Science Forschung entwickelt, werden jedoch mittlerweile häufig eingesetzt um
Artefakte systematisch zu bewerten und zu diskutieren, siehe u.a. Arnott, Pervan 2008; Arnott, Pervan;
Haraldsen et al. 2004; Fedorowicz et al. 2009; Remidez, Joslin 2007.
313 Hevner et al. 2004.
189
312
prozesses ist jedoch ein wahrnehmbares Problem der betrieblichen Praxis.314 Die
Konstruktion einer generischen auf verschiedene BPRM anwendbaren Methode löst
somit mittelbar ein vorhandenes Problem der Praxis.315 Um unmittelbar etwas zur
Problemlösung beizutragen, muss jedoch aus der generischen Methode eine konkrete
Methode abgeleitet werden. Die Ableitung einer konkreten Methode erfolgte in Kapitel
6 am Beispiel des BPRM COBIT. Jedoch ist COBIT ein stark strukturiertes BPRM,
daher lassen sich die generischen Ergebnisse und Aktivitäten gut auf COBIT
übertragen. Um die Anwendbarkeit der generischen Methode auf weitere BPRM zu
testen, wurde sie in Kapitel 7 exemplarisch auf CMMI angewendet. Inwieweit sich aus
diesen Erkenntnissen die Allgemeingültigkeit des Forschungsergebnisses herleiten lässt,
wird in Richtlinie 4 ausführlich thematisiert.
Die hier vorgestellten generischen und spezifischen Artefakte strukturieren das Problem
der Anpassung und Anwendung von verschiedenen BPRM bspw. COBIT und CMMI.
Die generische Methode macht dadurch die Thematik für weitere Forschung
zugänglich, während die spezifischen Methoden den Einsatz von COBIT und CMMI in
der Praxis unterstützen. Richtlinie 1 fordert jedoch, dass das geschaffene Artefakt direkt
ein vorhandenes Problem löst. Hier ist kritisch anzumerken, dass auch die spezifische
Methode nicht direkt im betrieblichen Umfeld einsetzbar ist. Beispielsweise fehlt der
Methode das Rollenkonzept, ohne das die praktische Anwendbarkeit erschwert ist.
Ebenso wäre es für die Praxis sinnvoll, die Methode um den Aspekt Projektmanagement
zu ergänzen. Da diese Aspekte nicht Bestandteil dieses Forschungsvorhaben waren, löst
das geschaffene Artefakt nicht -wie gefordert- unmittelbar ein in der Praxis vorhandenes
Problem, es ermöglicht jedoch die zukünftige Lösung des Problems.
Richtlinie 2:
Die Relevanz der wissenschaftlichen Problemstellung bezeichnet die Wichtigkeit des
Problems für die Wissenschaftspraxis. Diese Wichtigkeit kann auf einschlägige
Relevanzurteile oder das offensichtliche Problemempfinden einer jeweils den Ausschlag
gebenden, wissenschaftsnahen Gemeinschaft316 zurückgeführt werden.
Der für dieses Artefakt relevante Forschungsbereich ist die IT-Governance.
Verschiedene Forschungsergebnisse liefern Hinweise für eine Wirkungskette von der
Anwendung von BPRM zur Zielerreichung eines Unternehmensziels. So weisen
Simonsson und Johnson nach, dass die Governance-Maturität einen Einfluss auf den
Beitrag der IT („effect of IT―) im Unternehmen hat. Die Governance-Maturität
wiederum erhöht sich durch den Einsatz von BPRM.317 Wagner zeigt in einer Fallstudie,
314
Siehe u.a Larsen et al. 2006; Cater-Steel et al. 2006; Siviy et al. 2008.
Mittelbar, da die generische Methode erst in eine unmittelbar nützliche Methode überführt werden
muss.
316 Zelewski 2007 bezeichnet dies als „constituent community―.
317 Simonsson, Johnson 2008.
190
315
dass das konkrete BPRM ITIL einen positiven Einfluss auf den Beitrag der IT zum
Firmenerfolg hat.318 Tuttle und Vandervelde legen ihren Untersuchungen einen positiven
Einfluss von COBIT auf das Risikomanagement zugrunde.319 Heier et al. weisen in einer
empirischen Studie den positiven Zusammenhang zwischen Governance-Software,
Governance-Prozessen und IT-Wertbeitrag nach.320 Dass die Umsetzung von
Governance-Prozessen ein kritischer Erfolgsfaktor für die Erreichung von
Unternehmenszielen ist, stellen sie in einer weiteren Fallstudie fest.321 In einer
empirischen Studie ermitteln sie außerdem den messbaren Zusammenhang zwischen
einer IT-Governance-Software und dem IT-Wertbeitrag eines Unternehmens.322 Diesen
Zusammenhang legt auch die Fallstudie von Larsen et al. zugrunde.323 Sie analysieren 17
IT-Governance-Werkzeuge, unter diesen Werkzeugen befinden sich auch die BPRM der
IT-Governance, deren Anwendung hier thematisiert ist. De Haes et al. ermitteln in einer
Delphistudie die 10 wichtigsten COBIT-Prozesse, um die IT-Ziele und mittelbar die
Geschäftsziele zu erreichen. Dies beinhaltet nach Ansicht der Verfasserin implizit die
Annahme, dass die Anwendung von COBIT bzw. einzelner Prozesse zur Erreichung
von bestimmten Zielen führt.324 Debrecency et al. erarbeiten in einer Feldstudie den
Einfluss des BPRM COBIT auf die Prozessreife und auf die IT-Capability.325 Lunardi et
al. untersuchen den finanziellen Einfluss von „IT-Governance-Mechanisms‘ Adaption―
in brasilianischen Firmen. Sie unterteilen die Aktivität „Governance-Adaption― in zwei
Fälle, die Adaption mittels BPRM (ITIL und COBIT) oder ohne BPRM. Das Vorgehen
innerhalb dieser Tätigkeiten wird nicht beschrieben.326 Teile dieser Lücke schließt die
hier vorgestellte Methode. Einige andere Studien lassen ebenfalls den Schluss zu, dass
die methodische Anwendung von BPRM einen positiven Einfluss auf Ziele des
Unternehmens hat. So belegen Espindola et al. in einem Survey, dass die erfolgreiche
Adaption eine BPRM der IT-Governance einen positiven Einfluss auf verschiedene
Unternehmensziele hat.327
Die Literatur des Forschungsbereichs enthält somit eine Vielzahl an Hinweisen, dass die
Anwendung von BPRM zumindest mittelbar einen positiven Einfluss auf die
Erreichung der Unternehmensziele hat. Es konnte weiterhin gezeigt werden, dass die
„constituent community― die BPRM verwendet, ohne diese Anwendung näher zu
thematisieren. Die wissenschaftliche Aufarbeitung der Anpassung und Anwendung fehlt
318
Wagner 2006.
Tuttle, Vandervelde 2007.
320 Heier et al. 2007.
323 Larsen et al. 2006.
324 de Haes, van Grembergen 2008.
325 Debreceny, Gray 2009.
326 Lunardi et al. 2009.
327 de Espindola et al. 2009.
319
191
bislang nahezu vollständig. Daraus lässt sich nach Ansicht der Verfasserin die
wissenschaftliche Relevanz des gewählten Forschungsgebiets ―Anpassung und
Anwendung von BPRM― ableiten.
Richtlinie 3:
Die Evaluation von Forschungsresultaten beinhaltet laut Hevner et al. die Nützlichkeit,
die Qualität und die Effektivität der Artefakte. Diese Evaluation sollte außerdem
mithilfe streng wissenschaftlicher Evaluationsmethoden erfolgen. Dieser Richtlinie
geben Hevner et al. besonderes Gewicht. Sie schlagen eine Reihe von Methoden vor,
etwa zur Aufdeckung von Fehlverhalten des Artefakts oder zum Nachweis der
Nützlichkeit. Diese Methoden sollen wenn möglich sogar in Kombination eingesetzt
werden. Die hier vorgestellten Artefakte werden im Folgenden deskriptiv evaluiert.328
Evaluation der generischen Methode
Die Evaluation der generischen Methode erfolgte in Teilen bereits während der
Entwicklung der Methodenelemente. Da diese auf etablierten Forschungsergebnissen
und logischen Zusammenhängen basiert, wurde die generische Methode bereits
während der Entwicklung einer steten Prüfung unterzogen. Neben dieser logisch
argumentativen Evaluation sollten jedoch laut Hevner et al. möglichst noch weitere
Methoden verwendet werden.329 Viele Verfahren der Evaluation beinhalten die
Anwendung der Methode, d.h. in diesem Fall die Anwendung der generischen Methode
zur Ableitung von spezifischen Methoden. Eine Evaluation basiert in diesen Fällen
zumeist auf den Erfahrungen, die mit dem Artefakt in seinem späteren Umfeld erzielt
werden. Fraglich ist daher, welches das spätere Umfeld der generischen Methode ist.
Soll die generische Methode eingesetzt werden, um in Unternehmen spezielle Methoden
herzuleiten, oder ist die generische Methode vielmehr ein wissenschaftliches Artefakt,
welches notwendig ist um spezifische Entwicklungsergebnisse zu erzielen? Nach
Ansicht der Verfasserin ist davon auszugehen, dass die generische Methode aufgrund
ihrer Komplexität nicht im betrieblichen Umfeld einzusetzen ist. Wie bereits in Kapitel
2 beschrieben, ist die generische Methode vielmehr ein Beitrag zur Wissensbasis der ITGovernance-Forschung und daher primär als Artefakt für den wissenschaftlichen
Einsatz anzusehen.
Um die Qualität des generischen Artefakts zu beurteilen, ist zunächst der
Qualitätsbegriff zu thematisieren. Wie das folgende Zitat von Becker & Algermissen
verdeutlicht, ist die Beurteilung der Qualität von konstruktionsorientierten
Forschungsergebnissen nicht unstrittig.
328
Siehe Hevner et al. 2004, S.84.
Hevner et al. 2004 betonen: „For example, descriptive methods of evaluation should only be used for
especially innovative artifacts for which other forms of evaluation may not be feasible― (S. 84).
192
329
„Ein wichtiger Punkt ist hierbei die Tatsache, dass die Richtigkeit von Modellen nicht
letztendlich nachweisbar ist, sondern sich aus dem Diskurs der Sachkundigen und
Gutwilligen ergibt, die ein Modell als zutreffend erachten.“330
Becker & Algermissen thematisieren die Qualität von Modellen. Begreift man das hier
vorgestellte generische Artefakt jedoch als Modell des Ablaufs der Anpassung und
Anwendung lassen sich Forschungsergebnisse aus dem Bereich Modellqualität
anwenden um die Qualität der generischen Methode zu beurteilen. Insbesondere die
Ergebnisse bezüglich der Qualität von konzeptionellen Modellen lassen sich einsetzen
um die generische Methode zu evaluieren. Die Qualität von konzeptionellen Modellen
nach Maes & Poels (in Anlehnung an DeLone &McLean)331 wird in die syntaktische, die
semantische und die pragmatische Qualität unterteilt. Diese drei Dimensionen werden
nun verwendet um die Qualität der generischen Methode argumentativ zu bewerten.
Die syntaktische Qualität der generischen Methode basiert auf dem sprachkritischen
Ansatz des Methoden-Engineerings. Die Syntax der Methodenbestandteile ist dort
eindeutig definiert und die möglichen Beziehungen sind beschrieben. Von der
definierten Syntax wird im Verlauf dieses Beitrags nicht abgewichen. Für die
Darstellung der Ergebnisse wurden Entity-Relationship-Modelle und UnifiedModelling-Language-Diagramme verwendet. Die Methodenverläufe wurden durch
ereignisgesteuerte Prozessketten dargestellt.
Die semantische Qualität der generischen Methode stützt sich auf die eindeutige und
überschneidungsfreie Definition von Methodenbestandteilen sowie deren konsequente
Herleitung. In Anlehnung an die Erkenntnisse der Referenzmodell-Forschung wurden
die logischen möglichen Bestandteile vollständig beschrieben und systematisiert.
Die pragmatische Qualität der Methode ist schwerer zu beurteilen, da sie nach Ansicht
der Verfasserin imme im Verhältnis zu etwa zu beurteilen ist. D.h. bspw. die
pragmatische Qualität für eine bestimmte Nutzergruppe. Maes & Poels verwenden
bspw. die Benutzerzufriedenheit als Messgröße für die pragmatische Qualität. Wie
bereits erläutert, wird die generische Methode nach Ansicht der Verfasserin eher im
akademischen Bereich Anwendung finden. Die argumentative Beurteilung der
pragmatischen Qualität müsste also aus Sicht der Wissenschaft erfolgen. Hier ist
anzumerken, dass die systematische Beschreibung von Anpassung und Anwendung von
BPRM den Zugang von Wissenschaftlern zum Forschungsgebiet wahrscheinlich
erleichtert. Inwieweit die generische Methode jedoch einen tatsächlichen pragmatischen
Nutzen für andere Wissenschaftler hat wird sich in Zukunft zeigen.
Die insgesamt positive argumentative Evaluation des generischen Artefakts basiert
daher primär auf der positiven Beurteilung der syntaktischen und semantischen Qualität
der generischen Methode.
330
331
Becker, Algermissen 2003.
Vgl. Maes, Poels 2007; Lindland et al. 1994 oder Delone, McLean 2003 und 2005.
193
Evaluation der spezifischen Methoden
Die generische Methode wurde detailliert diskutiert und bewertet. Die positive
Evaluation der Qualität der generischen Methode lässt einen mittelbaren Schluss auf die
Qualität der aus ihr entwickelten spezifischen Methoden zu. Jedoch wurde bereits in
Kapitel 2 beschrieben, dass die spezifischen Methoden einen Nutzen für das ITGovernance-Umfeld stiften sollten. Die Nützlichkeit einer konkreten Methode muss
daher jeweils separat evaluiert werden.332 Hierfür bietet sich eine ex-post-Evaluation
nach Anwendung der Methode an.333 Yang und Padmanabhan beschreiben unter
anderem, dass eine solche Evaluation auf Basis von Befragungen der Anwender
erfolgen sollte.334 Diese Evaluation ist durch die Projektpartner des SemGoRiCoProjekts zukünftig gewährleistet.335
Richtlinie 4:
Konstruktionsorientierte Forschung muss, wie jede Forschung, einen Beitrag zum
Erkenntnisfortschritt
eines
Forschungsfeldes
leisten.
Hierfür
werden
paradigmenübergreifend
drei
Fortschrittsmerkmale
postuliert:
Neuartigkeit,
Allgemeingültigkeit und Bedeutsamkeit. Für die konstruktionsorientierte Forschung
wird zusätzlich empfohlen, ein Artefakt zu erstellen das einen signifikanten Nutzen für
ein nachweislich bis dahin ungelöstes Problem der wissenschaftsnahen Gemeinschaft
stiftet oder das vorhandene Wissen völlig neuartig anwendet. Die vier Dimensionen des
Erkenntnisfortschritts werden ebenfalls für das generische und das spezifische Artefakt
diskutiert.
Neuartigkeit
Bislang existiert keine generische Beschreibung der Anpassung und Anwendung von
BPRM der IT-Governance. Die relevanten existierenden Erkenntnisse zur Anpassung
von Referenzmodellen sind in das generische Artefakt eingegangen. Neben diesen
Erkenntnissen wurde Erfahrungswissen aus dem Bereich BPRM und ihrer Anwendung
in der Unternehmenspraxis integriert und theoretisch aufgearbeitet. Neuartig ist das
generische Artefakt außerdem, da es vorhandenes Wissen aus der
Referenzmodellierungs- und der Methodenkonstruktionsforschung neu kombiniert und
anwendet. Die spezifische Methode für das BPRM COBIT ist ebenfalls neuartig.
Bislang liegen kaum Forschungsergebnisse vor, die die Anpassung von COBIT an die
332
Kuechler W., Vaishnavi 2007.
Kuechler W., Vaishnavi 2007 betonen, dass Artefakte des Design Science Forschung bezüglich ihrer
Anwendbarkeit evaluiert werden müssen.
334 Yang, Padmanabhan 2005 beschreiben vier Formen der ex-post-Evaluation: Experimental Designs,
Historic Data Experiments, User Opinion Studies und Opinions Analysis of Historical Data.
335 Dies ist jedoch nicht mehr Bestandteil dieser Arbeit.
194
333
Unternehmensumstände oder die Anwendung von COBIT im betrieblichen Umfeld
systematisch beschreiben.
Allgemeingültigkeit
Das generische Artefakt wurde mit dem Ziel entwickelt, die Anpassung und
Anwendung von beliebigen BPRM zu unterstützen. Den Unterschieden zwischen
vorhandenen oder auch den erst zukünftig entwickelten BPRM der IT-Governance trägt
die generische Methode durch ihren hohen Abstraktionsgrad Rechnung. Durch die
Anwendung auf zwei BPRM wurde die These der generellen Anwendbarkeit der
Methode gestützt. In diesem Beitrag wurde die Hypothese demnach zweimal getestet
und sie war in beiden Fällen nicht abzulehnen. Durch die logische Herleitung der
Methodenelemente wird diese These zusätzlich gestärkt. Trotzdem wird die
Allgemeingültigkeit der Methode in diesem Beitrag nicht zweifelsfrei nachgewiesen.
Lediglich eine Anwendung auf alle bekannten BPRM würde eine Bestätigung
ermöglichen. Dies würde jedoch zulünftig entwickelte BPRM weiterhin ausschließen.
Bedeutsamkeit
Die Bedeutung der Artefakte für den Forschungsbereich IT-Governance zeigt sich
insbesondere bei den bereits bei Richtlinie 2 beschriebenen Arbeiten. Die Anwendung
eines BPRM wir häufig unreflektiert vorausgesetzt und ist in empirischen Studien ein
subjektives Element, dass der Einschätzung von Studienteilnehmern obliegt. Die
beschriebene generische Methode erlaubt es, die Anpassung und Anwendung von
BPRM systematisch in die wissenschaftliche Praxis aufzunehmen.
Signifikanter Nutzen für ein ungelöstes Problem
Von dem hier vorgestellten generischen Artefakt gehen zwei unterschiedliche Formen
des Nutzens aus. Zum einen systematisiert die generische Methode die Anpassung und
Anwendung von BPRM und macht sie so für weitere Forschung zugänglich. Zum
anderen kann die generische Methode verwendet werden, um spezifische Methoden
abzuleiten, was mittelbar die systematische Anpassung und Anwendung von BPRM
durch Unternehmen unterstützt. Für die Nutzer des BPRM COBIT stellt das spezifische
Artefakt einen zusätzlichen Nutzen dar. Besonders die Umsetzung in SemGoRiCo
unterstützt die praktische Anwendung von COBIT.
Richtlinie 5:
Diese Richtlinie schreibt den strengen („rigor―) Einsatz wissenschaftlicher Methoden
bei der Konstruktion und der Evaluation des Artefakts vor. Diesem Grundsatz folgt
dieser Beitrag durch den aufgezeigten Forschungsablauf nach Peffers et. al. Nach
Ansicht von Hevner et al. wird Erfahrungswissen des Wissenschaftlers benötigt, um
Arbeitstechniken und Abläufe auszuwählen, die zur Bearbeitung einer
wissenschaftlichen Problemstellung angemessen sind („skilled selection of appropriate
195
techniques―).336 Zusätzlich betonen sie, dass wissenschaftliche Strenge auf
durchgängigen Definitionen, Konsistenz innerhalb der Forschungsarbeit und einer
formalsprachlichen Repräsentation des Themas beruht. Die Methoden zur Evaluation
des erstellten Artefakts wurden bereits beschrieben. Der logisch deduktive
Konstruktionsprozess des Artefakts folgt den Kriterien des Methoden-Engineerings. Die
Elemente des Artefakts wurden unter Zuhilfenahme des sprachkritischen Ansatzes des
Methoden-Engineerings ausgewählt. Die Ausgestaltung und das Zusammenspiel der
Methodenelemente erfolgten unter Rückgriff auf die weitreichenden Erkenntnisse des
Forschungsbereichs Referenzmodellierung. Außerdem basieren insbesondere die
Erkenntnisse bezüglich des spezifischen Artefakts auf Beobachtungen der
Forschungsgruppe.
Richtlinie 6:
Die Konstruktion von Artefakten sollte einem konsequenten Suchprozess folgen.
Hierfür ist es nicht notwendig nach der optimalen Problemlösung zu suchen. Hevner et
al. empfehlen die Anwendung heuristischer Prinzipen, um zufriedenstellende
Problemlösungen zu finden. Hevner et al beschreiben einen Kreislauf aus
Ergebnisgeneration und –überprüfung. Ein solcher Kreislauf verbessert die Qualität der
erzielten Forschungsergebnisse. Durch die Projektpartner und insbesondere die
Anwendungspartner des SemGoRiCo-Projektes konnte ein solcher Kreislauf ermöglicht
werden. Die Erkenntnisse aus dem Diskurs mit Projektpartnern ergänzten den in Kapitel
2 beschriebenen logisch deduktiven Forschungsprozess.
Richtlinie 7:
Die Kommunikation von Forschungsergebnissen ermöglicht grundsätzlich deren
kritische Diskussion. Hevner et al. betonen, dass Ergebnisse sowohl in
wissenschaftlichen als auch stärker anwendungsorientierten Medien präsentiert werden
sollten. Die Resultate sollen zielgruppenadäquat aufgearbeitet sein. Eine erfolgreiche
Kommunikation der Ergebnisse ist eine Voraussetzung für einen konstruktiven Diskurs.
Das hier beschriebene Forschungsergebnis wurde in zweierlei Hinsicht einem Diskurs
unterzogen. Zum einen erfolgte eine Vorstellung der Zwischenergebnisse in der
Wissenschafts-Community.337 Die Hinweise aus Gutachten sowie Diskussionen nach
Vorträgen bereicherten den Forschungsprozess. Zum anderen erfolgte und erfolgt
weiterhin ein Diskurs mit der Praxis. Die Erprobung der Methode im Forschungsprojekt
SemGoRiCo ermöglichte einen konstruktiven Diskurs mit der Zielgruppe der konkreten
Methoden. Die zielgruppenadäquate Präsentation der Ergebnisse erfolgte in
regelmäßigen Abständen in Workshops und Projektgesprächen. Die Rückkopplungen
und praktischen Anforderungen der Projektpartner sind ebenfalls in die
Methodenkonstruktion eingegangen.
336
337
Hevner et al. 2004, S. 88.
Siehe Alter, Goeken 2009; Goeken, Alter 2008; Goeken, Alter 2009 oder Goeken, Patas 2009.
196
9 Fazit
Ziel dieses Forschungsvorhabens war es, eine allgemeingültige Methode zur
Unterstützung der Anpassung und Anwendung von BPRM zu entwickeln. Aufgrund der
Verschiedenartigkeit der BPRM ergab sich die Notwendigkeit eine generische Methode
auf hohem Abstraktionsgrad zu entwickeln, die für ein konkretes BPRM jeweils zu
spezifizieren ist. Dieses Forschungsvorhaben hat daher zwei Entwicklungsergebnisse:
ein generisches und ein spezifisches Artefakt.338
Trotz seines hohen Abstraktionsgrades lässt sich die Allgemeingültigkeit des
generischen Artefakts nicht zweifelsfrei nachweisen. Die Erprobung für die BPRM
COBIT und CMMI lässt es jedoch zu, die These der Allgemeingültigkeit nicht zu
verwerfen.
Die Herleitung der generischen Methode wird durch Erkenntnisse des MethodenEngineerings und der Referenzmodellierung unterstützt. Als Metamodell der
generischen Methode wurde das St. Gallener Modell des sprachkritischen MethodenEngineerings verwendet. Die Methodenelemente wurden u.a. auf Basis von
Erkenntnissen der Referenzmodellierungsforschung Münsteraner Prägung entwickelt.
Die Entwicklung der Ergebnisse und Aktivitäten erfolgte logisch argumentativ, d.h. die
generische Methode enthält alle logisch möglichen Ergebnisse und Aktivitäten der
Anpassung und Anwendung von BPRM.
Auf Basis der generischen Methode wurde für das BPRM COBIT eine spezifische
Methode abgeleitet. Der Prozess der Ableitung ist nicht ausführlich beschrieben und
basiert zu großen Teilen auf Analogieschlüssen. Um die Anwendbarkeit der generischen
Methode zu verbessern sollte der Ableitungsprozess in weiteren Forschungsarbeiten
systematisiert und vereinheitlicht werden.
Die spezifische Methode für COBIT ist trotz der Unterstützung durch das SemGoRiCOWerkzeug nicht direkt in der Praxis anwendbar. Die Methode muss um Aspekte des
Projektmanagements ergänzt werden. Insbesondere die Erweiterung des vorgestellten
Artefakts um ein Rollenkonzept ist nach Ansicht der Verfasserin zwingend notwendig
um die Praxis bei der Anpassung und Anwendung zu unterstützen. Das
Projektmanagement für die COBIT-Methode ist daher Bestandteil der weiteren
Forschung im SemGoRiCo-Projekt.
338
Die beispielhafte Erprobung für CMMI wird nicht als vollständiges Entwicklungsergebnis betrachtet,
sie dient vielmehr dem Nachweis der Allgemeingültigkeit.
197
Aburub, F.; Odeh, M.; Beeson, I. (2007): Modelling non-functional requirements of
business processes. In: Information & Software Technology, Jg. 49, H. 11-12, S. 1162–
1171.
Agerfalk, P. J.; Brinkkemper, S.; Gonzalez-Perez, C.; Henderson-Sellers, B.; Karlsson,
F.; Kelly, S.; Ralyté, J. (2007): Modularization Constructs in Method Engineering:
Towards Common Ground? In: Ralyté, Brinkkemper, Henderson-Sellers (Hg.): IFIP
International Federation for Information Processing. Boston: Springer (244), Bd. 244, S.
359–368.
Albers, S. (2009): Methodik der empirischen Forschung. 3., überarbeitete und erweiterte
Auflage, Wiesbaden: Gabler.
Alter, S.; Goeken, M. (2009): Konzeptionelle Metamodelle von IT-GovernanceReferenzmodellen als Basis der Kombination und Integration in einer Multi-ModelUmgebung. In: Hansen, Karagiannis, Fill (Hg.): Business Services: Konzepte,
Technologien, Anwendungen. 9. Internationale Tagung Wirtschaftsinformatik, Band 1.
Wien.
Applegate, L. M.; King, J. L. (1999): Rigor and Relevance: Careers on the Line. In:
MIS Quarterly, Jg. 23, H. 1, S. 17–18.
Arnott, D.; Pervan, G.: An Assessment of DSS Design Science using the Hevner,
March, Park, and Ram Guidelines. In: Information Systems Foundation. Answering the
Unanswered Questions about Design Research. Australasian National University.
Online abrufbar unter: http://www.cbe.anu.edu.au/NCISR/INFS/workshop/documents/ISFDSSDesignSciencePaperV1.1.pdf. Abruf 20.12.2010.
Arnott, D.; Pervan, G. (2008): Eight key issues for the decision support systems
discipline. In: Decision Support Systems, Jg. 44, H. 3, S. 657–672.
Assenova, P.; Johannesson, P. (1996): Improving quality in conceptual modelling by the
use of schema transformations. In: 15th International Conference on Conceptual
Modelling, ER '96, Berlin: Springer.
Atkinson, C.; Kühne, T. (2003): Calling a Spade a Spade. The MDA Infrastructure. In:
Proceedings of the Metamodelling for MDA First International Workshop, York, UK,
November 2003, S. 9-12.
Atteslander, P.; Cromm, J. (2003): Methoden der empirischen Sozialforschung. 10., neu
bearbeitete und erweiterte Auflage, Berlin: de Gruyter (De-Gruyter-Studienbuch).
Archer, L. B.: Systematic method for designers. In: Cross, N. (Hg.): Developments in
Design Methodology. London: John Wiley & Sons LtD, S. 57–82.
198
Balzert, H. (1998): Lehrbuch der Software-Technik. Heidelberg, Berlin: Spektrum
Akademischer Verlag GmbH.
Bardecki, M. J. (1984): Participants' Response to the Delphi Method. An Attitudinal
Perspective. In: Technological Forecasting and Social Change, Jg. 25, S. 281–292.
Bauer, C. (1998): Internet und WWW für Banken – Inhalte, Infrastrukturen und
Erfolgsstrategien. Wiesbaden.
Baskerville, R. L.; Stage, J. (2001): Accommodating Emergent Work Practices:
Ethnographic Choice of Method Fragements. IFIP TC8/WG8.2 Working Conference on
Realigning Research and Practice in IS Development: The Social and Organisational
Perspective, Boise, ID, S. 12-28.
Batini, C.; Lenzerini, M.; Navathe, S. B. (1986): A Comparative analysis of
methodologies for database schema integration. In: ACM Computing Surveys, Jg. 18,
H. 4, S. 323–364.
Baumöl, U. (2006): Methodenkonstruktion für das Business/IT-Alignment. In:
Wirtschaftsinformatik, Jg. 48, H. 5, S. 314–322.
Becker, J. (1995): Strukturanalogien in Informationsmodellen – Ihre Definition, ihr
Nutzen und ihr Einfluß auf die Bildung der Grundsätze ordnungsmäßiger Modellierung
(GoM). In: König, W. (Hg.): Wirtschaftsinformatik '95 – Wettbewerbsfähigkeit,
Innovation, Wirtschaftlichkeit. Heidelberg, S. 133–150.
Becker, J. (2004): Referenzmodellierung. Grundlagen,
domänenbezogene Anwendung. Heidelberg: Physica-Verlag.
Techniken
und
Becker, J.; Algermissen, L. (2003): Grundsätze ordnungsmäßiger Modellierung. Über
Kontruktivisten, Handels-Hs und Referenzmodelle. In: Proceedings of the
Informatiktage. Fachwissenschaftlicher Informatik-Kongress, 7. und 8. November 2003,
Bad Schussenried.
Becker, J.; Delfmann, P.; Knackstedt, R.; Kuropka, D. (2002a): Konfigurative
Referenzmodellierung. In: Becker, Jörg; Knackstedt, Ralf (Hg.): Wissensmanagement
mit
Referenzmodellen.
Konzepte
für
die
Anwendungssystemund
Organisationsgestaltung. Berlin et al.: Physica, S. 25–144.
Becker, J.; Algermissen, L.; Delfmann, P. (2002b): Referenzmodellierung. In: Das
Wirtschaftsstudium (WISU), Jg. 31, H. 11, S. 1392–1395.
Becker, J.; Delfmann, P.; Knackstedt, R. (2002c): Eine Modellierungstechnik für die
konfigurative Referenzmodellierung. In: Becker, Knackstedt (Hg.): Referenzmodellierung 2002. Methoden – Modelle – Erfahrungen. Arbeitsberichte des Instituts
für Wirtschaftsinformatik, Nr. 90, S. 35–76, Münster.
199
Becker, J.; Delfmann, P.; Falk, T.; Knackstedt, R. (2003): Multiperspektivische
ereignisgesteuerte Prozessketten. In: Nüttgens, M.; Rump, F. J. (Hg.): EPK 2003 Geschäftsprozessmanagement mit Ereignisgesteuerten Prozessketten. Proceedings des
2. GI-Workshop EPK 2003. Bamberg, S. 45–60.
Becker, J.; Delfmann, P.; Knackstedt, R. (2004): Konstruktion von
Referenzmodellierungssprachen. Ein Ordnungsrahmen zur Spezifikation von
Adaptionsmechanismen für Informationsmodelle. In: Wirtschaftsinformatik, Jg. 46, H.
4, S. 251–264.
Becker, J.; Janiesch, C.; Knackstedt, R.; Kramer, S.; Seidel, S. (2006): Konfigurative
Referenzmodellierung mit dem H2-Toolset. Herausgegeben von Becker, Grohmann,
Becker, J.; Knackstedt, Ralf (Hg.) (2002d): Referenzmodellierung 2002 Methoden –
Modelle – Erfahrungen. Herausgegeben von Becker, Grohmann, Klein, Kuchen,
Müller-Funk und Vossen. Westfälische Wilhelms-Universität Münster. Münster.
Arbeitsberichte des Instituts für Wirtschaftsinformatik, Nr. 90, Münster.
Becker, J.; Knackstedt, R. (2003): Konstruktion und Anwendung fachkonzeptioneller
Referenzmodelle im Data Warehousing. In: Uhr, Wolfgang; Esswein, Werner; Schoop,
Eric (Hg.): Wirtschaftsinformatik 2003. Medien - Märkte - Mobilität. Heidelberg:
Physica-Verl., S. 415–434.
Becker, J.; Knackstedt, R.; Holten, R.; Hansmann, H.; Neumann, S. (2001):
Konstruktion von Methodiken. Vorschläge für eine begriffliche Grundlegung und
domänenspezifische Anwendungsbeispiele. Herausgegeben von Becker, Grohmann,
Becker, J.; Knackstedt, R.; Pfeiffer, D.; Janiesch, C. (2007): Configurative Method
Engineering. On the Applicability of Reference Modeling Mechanisms in Method
Engineering. In: Proceedings of the 13th Americas Conference on Information Systems
(AMCIS 2007). 10.-12.August 2007, Keystone, Colorado, USA.
Becker, J.; Niehaves, B. (2006): Epistemological Perspectives on Design Science in IS
Research. In: Proceedings of the 12th Americas Conference on Information Systems
(AMCIS 2006). Acapulco, Mexico.
Becker, J.; Pfeiffer, D. (2006): Konzeptionelle Modellierung - ein wissenschaftstheoretischer Forschungsleitfaden. In: Lehner (Hg.): Proceedings of the Multikonferenz
Wirtschaftsinformatik 2006. Berlin (2), S. 3–19.
200
Becker, J.; Rosemann, M.; Schütte, R. (1995): Grundsätze ordnungsmäßiger
Modellierung. In: Wirtschaftsinformatik, Jg. 37, H. 5, S. 435–445.
Becker, J.; Schütte, R. (2004): Handelsinformationssysteme. Domänenorientierte
Einführung in die Wirtschaftsinformatik. München: mi-Wirtschaftsbuch.
Becker, M. (1998): Umsetzung betrieblicher Prozesse. Methode, Fallbeispiele,
Workflow-Technologie. Dissertation. Universität St.Gallen. St. Gallen.
Beiersdorf, H. (1995): Informationsbedarf und Informationsbedarfsermittlung im
Problemlösungsprozess „Strategische Unternehmungsplanung―. München et al.:
Hampp.
Böhmann, T.; Krcmar, H. (2004): Grundlagen und Entwicklungstrends im ITServicemanagement. In: HMD - Praxis Wirtschaftsinformatik, H. 237.
Börner, R. (2010): Applying Situational Method Engineering to the Development of
Service Identification Methods. Proceedings of the 16th Americas Conference on
Böttcher, R. (2008): IT-Servicemanagement mit ITIL V3. Einführung,
Zusammenfassung und Übersicht der elementaren Empfehlungen. Hannover: Heise.
Bowen, P. L.; Cheung, M.-Y. D.; Rohde, F. H. (2007): Enhancing IT governance
practices: A model and case study of an organization‘s effort. In: International Journal
of Accounting Information Systems, Jg. 8, H. 3, S. 191–221.
Braun, C.; Hafner, M.; Wortmann, F. (2004): Methodenkonstruktion als
wissenschaftlicher Erkenntnisansatz. Universität St.Gallen. St. Gallen, Switzerland.
Brinkkemper, S. (1996): Method engineering: engineering of information systems
development methods and tools. In: Information & Software Technology, Jg. 38, H. 4,
S. 275–280.
Brinkkemper, S.; Lyytinen, K.; Welke, R. J. (Hg.) (1996): Method Engineering.
Principles of method construction and tool support; Proceedings of the IFIP TC8,
WG8.1/8.2 Working Conference on Method Engineering, 26.-28.August 1996, Atlanta,
USA. London: Chapman & Hall.
Brinkkemper, S.; Saeki, M.; Harmsen, F. (1999): Meta-modelling based assembly
techniques for situational method engineering. In: Information Systems, Jg. 24, H. 3, S.
209–228.
Brockhaus, W. L.; Mickelsen, J. F. (1977): An Analysis of prior Delphi Applications
and some observations on its future Applicability. In: Technological Forecasting and
Social Change, Jg. 10, S. 103–110.
201
Brockmans, S. (2006): Meta-Modelling and ontologies. Proceedings of the 2nd
International Workshop on Meta-Modelling, 12.-13.10.2006 in Karlsruhe. Bonn:
Gesellschaft für Informatik (GI-EditionProceedings, Nr. 96).
Brooks, F. P. (1987): Essence and Accidents of Software Engineering. In: IEEE
Computer, Jg. 20, H. 4, S. 10–19.
Bucher, T.; Klesse, M.; Kurpjuweit, S.; Winter, R. (2007): Situational Method
Engineering - On the Differentiation of "Context" and "Project Type". In: Ralyté,
Brinkkemper, Henderson-Sellers (Hg.): IFIP International Federation for Information
Processing Working Conference. Boston: Springer, S. 33–48.
Bühne,
S.;
Halmans,
G.;
Pohl,
K.
(2004):
Anforderungsorientierte
Variabilitätsmodellierung für Software-Produktfamilien. In: Rumpe, Hesse (Hg.):
Modellierung 2004. Proceedings zur Tagung, 23.-26.03.2004 Marburg: Köllen
Druck+Verlag (Lecture Notes in Informatics (LNI) - Proceedings, 45), S. 43–57.
Cater-Steel, A.; Tan, W. G.; Toleman, M. (2006): Challenge of adopting multiple
process improvement frameworks. In: Proceedings of the 14th European Conference on
Information Systems, 14.-16.Juni 2004, Turku, Finnland.
Lee, C.H.; Lee, J.H.; Yonsei, J.S.P. (2008): A study of the causal relationship between
IT governance inhibitors and its success in Korea enterprises. In: HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences.
Conrad, S. (2002): Schemaintegration. Integrationskonflikte, Lösungsansätze, aktuelle
Herausforderungen. In: Informatik – Forschung und Entwicklung, Jg. 17, S. 101–111.
Cox, J. (2004): Implementing ITIL. In: Network World, Jg. 21, H. 40, S. 60-70.
Crockcroft, S. (2002): Gaps between policy and practice in the protection of data
privacy. In: Journal of Information Technology Theory and Application, Jg. 4, H. 3, S.
1–13.
Damianides, M. (2004): How Does SOX Change IT? In: The Journal of Corporate
Accounting & Finance, Jg. 5, H. 6, S. 35–41.
Davenport, T. H.; Markus, L. M. (1999): Rigor vs. Relevance Revisited: Response to
Benbasat and Zmud. In: MIS Quarterly, Jg. 23, H. 1, S. 19–23.
Davis, G. (1982): Strategies for Information Requirements Determination. In: IBM
Systems Journal, Jg. 21, H. 1, S. 4–30.
de Espindola, R. S.; Luciano, E. M.; Audy, J. L. N. (2009): An Overview of the
Adoption of IT Governance Models and Software Process Quality Instruments at Brazil
- Preliminary Results of a Survey. In: HICSS 2009 - Proceedings of the 42th Hawaii
202
International Conference on System Sciences. Washington, DC, USA: IEEE Computer
Society.
Debreceny, R.; Gray, G. L. (2009): IT Governance and Process Maturity: A Field
Study. In: HICSS 2009 - Proceedings of the 42th Hawaii International Conference on
Delone, W.H.; McLean, E.R. (2003): The DeLone and McLean Model of Information
Systems Success: A Ten-Year Update. In: Journal of Management Information
Systems, Jg. 19, H. 4, S. 9–30.
Delone, W.H.; McLean, E.R.; Stacie P.(2005): Success of information systems:
measuring the effectiveness of information systems. In: Blackwell Encyclopedic
Dictionary of Management Information Systems, Oxford, UK.
Dresbach, S. (1999): Epistemologische Überlegungen zu Modellen in der
Wirtschaftsinformatik. In: Becker, Schütte, Wendt, Zelewski (Hg.): Wirtschaftsinformatik und Wissenschaftstheorie. Bestandsaufnahmen und Perspektiven.
Wiesbaden, S. 71–94.
Dominguez, E.; Zapata, M. A. (2007): Noesis: Towards a situational method
engineering technique. In: Information Systems, Jg. 32, H. 2, S. 181–222.
Duffield, C. (1993): The Delphi technique: a comparision of results obtaining using two
expert panels. In: International Journal of Nursing Studies, Jg. 30, H. 3, S. 227–237.
Ebel, N. (2007): ITIL Basis-Zertifizierung. München: Addison-Wesley.
Ebert, J,; Frank, U. (Hg.) (2000): Modelle und Modellierungssprachen in Informatik
und Wirtschaftsinformatik. Beiträge des Workshops "Modellierung 2000", St. Goar, 5. 7. April 2000. Koblenz: Fölbach (Koblenzer Schriften zur Informatik, 15).
Eckstein, P. P. (2008): Angewandte Statistik mit SPSS. Praktische Einführung für
Wirtschaftswissenschaftler. 6. überarbeitete Auflage, Wiesbaden: Gabler (Lehrbuch).
Eekels, J. (1991): A methodological comparison of the structures of scientific research
and engineering design: Their similarities and differences. In: Design Studies, Jg. 12, H.
4, S. 197–203.
Elfatatry, A. (2007): Dealing with Change: Components versus Services. In:
Communications of the ACM, Jg. 50, H. 8, S. 35–39.
Elsässer, W. (2007): ITIL einführen und umsetzen. München: Hanser.
Fedorowicz, J.; Dias, M.; Sawyer, S. (2009): Design in digital government research. In:
Digital Government Society of North America (Hg.): Proceedings of the 10th Annual
International Conference on Digital Government Research, S. 293-301.
203
Ferstl, O. K.; Sinz, E. J. (2001): Grundlagen der Wirtschaftsinformatik. München:
Oldenbourg.
Fettke, P.; Loos, P. (2002): Methoden zur Wiederverwendung von Referenzmodellen –
Übersicht und Taxonomie. In: Becker, Knackstedt (Hg.): Referenzmodellierung 2002.
Methoden – Modelle – Erfahrungen. Arbeitsberichte des Instituts für Wirtschaftsinformatik, Nr. 90, Münster, S. 9–30.
Fettke, P.; Loos, P. (2003): Classification of reference models—a methodology and its
application. In: Information systems and ebusiness management, Jg. 1, H. 1, S. 35–53.
Fettke, P.; Loos, P. (2004): Referenzmodellierungsforschung. In: Wirtschaftsinformatik,
Jg. 46, H. 5, S. 331–340.
Fitzgerald, B.; Russo, N. L.; O'Kane, T. (2003): Software Development: Method
Tailoring at Motorola. In: Communications of the ACM, Jg. 46, H. 4, S. 65–70.
Forbrig, P. (2007): Objektorientierte Softwareentwicklung mit UML. Mit 72 Beispielen
und Aufgaben. München: Hanser-Verlag.
Fox, C. (2004): Sarbanes-Oxley Considerations for a Framework for IT Financial
Reporting Controls. In: Information Systems Control Journal, H. 1, S. 52–54.
Fox, C.; Zonneveld, P. (2006): IT Control Objectives for Sarbanes-Oxley. The role of
IT in the design and implementation of internal control over financial reporting. IT
Governance Institute.
Frank, U. (1999): Conceptual Modelling as the Core of the Information Systems
Discipline – Perspectives and Epistemological Challenges. In: Haseman, W. D.;
Nazareth, D. L. (Hg.): Proceedings of the Fifth Americas Conference on Information
Systems (AMCIS 1999), August 13-15, 1999. Milwaukee, Wisconsin.
Fröhlich, M.; Glasner, K. (2007): IT Governance. Leitfaden für eine praxisgerechte
Implementierung. Wiesbaden: Gabler Verlag.
Fröschle, H.P.; Kütz, M. (Hg.) (2011): Lexikon IT-Management: Symposion
Publishing.
Gaulke, M. (2006): COBIT als IT-Governance-Leitfaden. In: HMD - Praxis
Wirtschaftsinformatik, Jg. 250, S. 21–28.
Gerber, S.; Mai, A. (2002): Ein Referenzmodell für das Filialgeschäft von Banken als
betriebliche Wissensplattform. In: Becker, Knackstedt (Hg.): Wissensmanagement mit
Referenzmodellen. Konzepte für die Anwendungssystem- und Organisationsgestaltung.
Springer: Berlin et al., S. 195–206.
Glasner, K.; Looso, S. (2011): Best Practice. In: Fröschle, Kütz (Hg.): Lexikon ITManagement: Symposion Publishing, S. 41–44.
204
Glinz, M. (2003): Abstraktion. Unterlagen zur Vorlesung Informatik II - Modellierung.
Institut für Informatik, Universität Zürich. Zürich.
Goeken, M. (2002): Grundlagen und Ansätze einer Referenzmodellierung für
Führungsinformationssysteme. Philipps-Universität Marburg, Fachbericht des Instituts
für Wirtschaftsinformatik, Nr. 03, Marburg.
Goeken, M. (2006): Entwicklung von Data-Warehouse-Systemen. Anforderungsmanagement, Modellierung und Implementierung. Dissertation. Philipps-Universität
Marburg, Wiesbaden: Deutscher Universitäts-Verlag.
Goeken, M.; Alter, S. (2008): IT Governance Frameworks as Methods. In: Proceedings
of the 10th International Conference on Enterprise Information Systems (ICEIS 2008).
12-16.06.2008, Barcelona, Spain.
Goeken, M.; Alter, S. (2009): Towards Conceptual Metamodeling of IT Governance
Frameworks. Approach - Use - Benefits. In: HICSS 2009 - Proceedings of the 42th
Computer Society.
Goeken, M.; Alter, S.; Milicevic, D.; Patas, J. (2009): Metamodelle von
Referenzmodellen am Beispiel ITIL. Vorgehen, Nutzen, Anwendung. In: Fischer,
Stefan; Maehle, Erik; Reischuk, Rüdiger (Hg.): Proceedings der Informatik 2009
(Lecture Notes in Informatics (LNI) - Proceedings).
Goeken, M.; Patas, J. (2009): Wertbeitrag der IT als Gegenstand der IT-Governance und
des IT-Controllings. In: Controlling - Zeitschrift für Erfolgsorientierte
Unternehmenssteuerung, Jg. 21, H. 12, S. 654–659.
Goeken, M.; Reimann, B. (2007): ITIL v3 - Alles neu macht der Mai? In: ITGovernance - Zeitschrift des ISACA Germany Chapter, Jg. 1, H. 2.
Golfarelli, M.; Maio, D.; Rizzi, S.(1998): Conceptual Design of Data Warehouses from
E/R Schema. In: HICSS 1998 - Proceedings of the 31th Hawaii International
Conference on System Sciences. Washington, DC, USA: IEEE Computer Society.
Greiffenberg, S. (2003): Methoden als Theorien der Wirtschaftsinformatik. In: Uhr
(Hg.): Wirtschaftsinformatik 2003 : Medien, Märkte, Mobilität, S. 947–967.
Gutzwiller, T. (1994): Das CC RIM-Referenzmodell für den Entwurf von betrieblichen,
transaktionsorientierten Informationssystemen. Heidelberg: Physica-Verlag.
Häder, M. (2002): Delphi-Befragungen. Ein Arbeitsbuch. Wiesbaden: Westdeutscher
Verlag.
Haes, S. de; van Grembergen, W. (2006): Information Technology governance best
practices in Belgian organizations. In: HICSS 2006 - Proceedings of the 39th Annual
205
Computer Society.
Haes, S. de; van Grembergen, W. (2008): An exploratory Study into the design of an IT
Governance Minimum Baseline through Delphi Research. In: Communications of the
Association for Information Systems, Jg. 22, Article 24, S. 443ff.
Haraldsen, M.; Stray, T. D.; Päivärinta, T.; Sein, M. K. (2004): Developing eGovernment Portals: From Life-Events through Genres to Requirements. In: Rolland
(Hg.): Proceedings of the 11th Norwegian Conference on Information Systems,
Stavanger, S. 44–70.
Hardy, G. (2006): Using IT governance and COBIT to deliver value with IT and
respond to legal, reulatory and compliance challenges. In: Information Security
Technical Report, S. 55–61.
Harmsen, A. F. (1997): Situational Method Engineering. Dissertation, Utrecht.
Hars, A. (1994): Referenzdatenmodelle – Grundlagen effizienter Datenmodellierung.
Wiesbaden: Dissertation 1993 Saarbrücken.
Harter, D. E.; Mayuram S. K.; Slaughter, S. A. (2000): Effects of Process Maturity on
Quality, Cycle Time, and Effort in Software Product Development. In: Management
Science, Jg. 46, H. 4, S. 451-466.
Heier, H.; Borgman, H.; Hoffbauer, T. (2008): Making the most of IT governance
software: understanding implementation processes. In: HICSS 2008 - Proceedings of
the 41st Annual Hawaii International Conference on System Sciences. Washington, DC,
Heier, H.; Borgman, H.; Maistry, M. (2007): Examining the relationship between IT
governance software and business value of IT: evidzence from four case studies. In:
HICSS 2007: Proceedings of the 40th Annual Hawaii International Conference on
Heier, H.; Borgmann, H.; Mileos, C. (2009): Examining the Relationship between IT
Governance Software, Processes, and Business Value: A Quantitative Research
Approach. In: HICSS 2009 - Proceedings of the 42th Hawaii International Conference
on System Sciences. Washington, DC, USA: IEEE Computer Society.
Hesse, W.; Merbeth, G.; Frölich, R. (1992): Software-Entwicklung, Vorgehensmodelle,
Projektführung, Produktverwaltung. Handbuch der Informatik Band 5.3. Wien:
Oldenbourg.
Hevner, A. R.; March, S. T.; Park, J.; Sudha, R. (2004): Design Science in Information
Systems. In: MIS Quarterly, Jg. 28, H. 1, S. 75–106.
206
Heym, M. (1993): Methoden-Engineering - Spezifikation und Integration von
Entwicklungsmethoden für Informationssysteme. Disseration. Hallstadt. Universität
St.Gallen, Institut für Wirtschaftsinformatik.
Hitz, M.; Bernauer, M. (2005): UML@Work. Objektorientierte Modellierung mit UML
2. In: @UML@Work, objektorientierte Modellierung mit UML 2, Martin Hitz. Online
verfügbar unter http://www.gbv.de/dms/hebis-darmstadt/toc/130093742.pdf.
Hochstein, A.; Hunziker, A. (2003): Serviceorientierte Referenzmodelle des ITManagements. In: HMD - Praxis Wirtschaftsinformatik, 232, S.46-56.
Hochstein, A.; Zarnekow, R.; Brenner, W. (2004): ITIL als Common-PracticeReferenzmodell für das IT-Service-Management. Formale Beurteilung und
Implikationen für die Praxis. In: Wirtschaftsinformatik, Jg. 46, H. 5, S. 382–389.
Hoffmann, W. (1999): Objektorientiertes Qualitätsinformationssystem – Referenzmodell und Realisierungsansätze. Wiesbaden (Zugl.: Dissertation, Saarbrücken, 1998).
Holten, R. (1999): Entwicklung von Führungsinformationssystemen.
methodenorientierter Ansatz. Wiesbaden: Gabler.
Ein
IT Governance Institute (2003): COBIT Implementation Guide.
IT Governance Institute (2007): COBIT 4.1.
itSMF; ISACA (Hg.) (2008): ITIL-COBIT- Mapping. Gemeinsamkeiten und
Unterschiede der IT-Standards, Düsseldorf: Symposion Publishing.
Jablonski, S.; Böhm, M.; Schulze, W. (1997): Workflow-Management. Entwicklung
von Anwendungen und Methoden. Heidelberg: dpunkt.verlag.
Johannsen, W.; Goeken, M. (2010): Referenzmodelle für IT-Governance. 2. Auflage,
Heidelberg: dpunkt.verlag.
Kaarst-Brown, M. L.; Kelly, S. (2005): IT Governance and Sarbanes-Oxley: The latest
sales pitch or real challenges for the IT function? In: Proceedings of the Proceedings of
the 38st Annual Hawaii International Conference on System Sciences. HICSS 2005, S.
238ff. Washington, DC, USA: IEEE Computer Society.
Kamleiter, J.; Langer, M. (2006): Business IT Alignment mit ITIL, COBIT, RUP. Bad
Homburg: Serview GmbH.
Karlsson (2002): Meta-Method for Method Configuration. Dissertation. Linköping,
Faculty of Arts and Sciences.
207
Karlsson, F.; Wistrand, K. (2006): Combining method engineering with activity theory:
theoretical grounding of the method component concept. In: European Journal of
Kelly, S.; Rossi, M.; Tolvanen, J. P. (2005): What is Needed in a MetaCASE
Environment? In: Enterprise Modelling and Information Systems Architectures, Jg. 1,
H. 1, S. 25–35.
Kemper, A.; Eickler, A. (2006): Datenbanksysteme. Eine Einführung. München:
Oldenbourg Verlag.
Kemper, H. G.; Hadjicharalambous, E.; Paschke, J. (2004): IT-Servicemanagement in
deutschen Unternehmen - Ergebnisse einer empirischen Studie zu ITIL. In: HMD Praxis Wirtschaftsinformatik, H. 237, S. 22-31.
Klimek, S. (1998): Entwicklung eines Führungsleitstands als Unterstützungssystem für
das Management unter besonderer Berücksichtigung des FuE-Bereichs. Göttingen:
Unitext-Verlag.
Kneuper, R. (2003): CMMI. Verbesserung von Softwareprozessen mit Capability
Maturity Model Integration. Heidelberg: dpunkt.verlag.
KPMG (September 2004): Summary of KPMG IS Governance Survey. KPMG LLP.
London.
KPMG International (2009): KMPG‘s 2009 IT Internal Audit Survey. Herausgegeben
von KPMG.
Krcmar, H.; Walter, S. M. (2006): Reorganisation der IT-Prozesse auf Basis von
Referenzmodellen. eine kritische Analyse. In: itService Management, Jg. 1, H. 2.
Kuechler W.; Vaishnavi, V. (2007): Design Science in Information Systems. In:
Proceedings of 2nd International Conference on Design Science Research in
Information Systems and Technology (DESRIST '07). May 13-16, 2007, Pasedena, CA.
Kurpjuweit, S. (2009): Stakeholder-orientierte Modellierung und Analyse der
Unternehmensarchitektur unter besonderer Berücksichtigung der Geschäfts- und ITArchitektur. Dissertation Nr. 3634. St. Gallen, Switzerland. Universität St. Gallen.
Kurpjuweit, S.; Aier, S. (2007): Ein allgemeiner Ansatz zur Ableitung von
Abhängigkeitsanalysen auf Unternehmensarchitekturmodellen. In: Tagungsband der 9.
Internationalen Tagung Wirtschaftsinformatik, S. 129–138.
Lainhart, J. W. (2000): COBIT: A Methodology for Managing and Controlling
Information and Information Technology Risks and Vulnerabilities. In: Journal of
Information Systems, H. 14, S. 21–25.
208
Lang, K. (1997): Gestaltung von Geschäftsprozessen mit Referenzprozeßbausteinen.
Nürnberg, Dissertation. Erlangen, 1996. Wiesbaden: Deutscher Universitäts-Verlag.
(Gabler Edition Wissenschaft).
Larsen, M.; Pedersen, M.; Andersen, K. (2006): IT governance: reviewing 17 IT
governance tools and analyzing the case of Novozymes A/S. In: HICSS 2006:
Proceedings of the 39th Annual Hawaii International Conference on System Sciences.
Lee, A. S. (1999): Rigor and Relevance in MIS Research: Beyond the Approach of
Positivism Alone. In: MIS Quarterly, Jg. 23, H. 1, S. 29–33.
Lee, A. S.; Hubona, G. (2009): A Scientific Basis for Rigor in Information Systems
Research. In: MIS Quarterly, Jg. 33, H. 2, S. 237–262.
Leite, J. C. S. P.; Franco, A. P. M. (1993): A strategy for conceptual model acquisition.
In: IEEE International Symposium on Requirements Engineering. Los Alamitos, CA,
USA: IEEE Computer Society, S. 243–246.
Lindland, O.I.; Sindre, G.; Solvberg, A. (1994): Understanding Quality in Conceptual
Modeling. In: IEEE Software, Jg. 11, H. 2, S. 42-49.
Loos, P.; Fettke, P. (2005): Referenzmodellierung. Entwicklungsstand
Perspektiven. In: Information Management & Consulting, Jg. 20, Sonderausgabe.
und
Looso, S. (2010a): Multi-Modell-Umgebung IT-Governance: Einsatz mehrerer BestPractice-Referenzmodelle. In: Proceedings der Informatik 2010 (Lecture Notes in
Informatics (LNI) - Proceedings).
Looso, S. (2010b): Towards a Generic Method for Best Practice Reference Model
Application. In: AMCIS 2010 - Proceedings of the 16th Americas Conference on
Looso, S.; Börner, R.; Goeken, M. (2009): Operationalisierung der IT-GovernanceKernbereiche für die Identifizierung und Gestaltung von Services. In: Fischer, Maehle,
Reischuk (Hg.): Proceedings der Informatik 2009 (Lecture Notes in Informatics (LNI) Proceedings), S. 3660–3674.
Looso, S.; Goeken, M. (2010): IT Governance: Application of Best Practice Reference
Models. In: Proceedings of the 18th European Conference on Information Systems
(ECIS 2010), Pretoria, Südafrika.
Looso, S.; Goeken, M.; Johannsen, W. (2010): Comparison and Integration of IT
Governance Frameworks to support IT Management. In: Praeg, C.-P.; Spath, D. (2010):
Quality management for IT services. Perspectives on business and process performance.
Hershey, PA: IGI Global.
209
Lunardi, G. L.; Becker, J. L.; Macada, A. C. (2009): The Financial Impact of IT
Governance Mechanisms' Adoption: An Empirical Analysis with Brazilian Firms. In:
Sciences. Washington, DC, USA: IEEE Computer Society.
Maes, A.; Poels, G. (2007): Evaluating quality of conceptual modelling scripts based on
user perceptions. In: Data and Knowledge Engineering, Jg. 63, S. 701–724.
Maiden, N. (1996): ACRE: a framework for acquisition of requirements. In: Software
Engineering Journal, Jg. 11, H. 3, S. 183–192.
Maier, R. (1998): Nutzen und Qualität der Datenmodellierung - Ergebnisse einer
empirischen Studie. In: Wirtschaftsinformatik, Jg. 40, H. 2, S. 130–140.
Mayr, H.; Breu, R. (Hg.) (2006): Modellierung 2006. 22. - 24. März 2006, Innsbruck,
Austria. Bonn: Gesellschaft für Informatik (GI-EditionProceedings, 82).
Mertens, P.; Holzner, J. (1992): Eine Gegenüberstellung von Integrationsansätzen der
Wirtschaftsinformatik. In: Wirtschaftsinformatik, Jg. 34, H. 1, S. 5–25.
Mishra, S.; Weistroffer, H. R. (2007): A Framework for integrating Sarbanes-Oxley
Compliance into the Systems Development Process. In: Communications of the
Association for Information Systems, Jg. 20, S. 712–727.
Murry, J. W., JR.; Hammons, J. o. (1995): Delphi: A Versatile Methodology for
Conducting Qualitative Research. In: The Review of Higer Education, Jg. 8, H. 4, S.
424–436.
Nunamaker, J. F.; Chen, M.; and Purdin, T. D. M. (1990): Systems development in
information systems research. In: Journal of Management Information Systems, Jg. 7,
H. 3, S. 89–106.
OGC (2007a): ITIL V3. Continual Service Improvement. London.
OGC (2007b): ITIL V3. Service Design. London.
OGC (2007c): ITIL V3. Service Operation. London.
OGC (2007d): ITIL V3. Service Strategy. London.
OGC (2007e): ITIL V3. Service Transition. London.
Patel, C.; Cesare, S. de; Iacovelli, N.; Merico, A. (2004): A Framework for Method
Tailoring: A Case Study. In: 2nd OOPSLA Workshop on Method Engineering for
Object-Oriented and Component-Based Development. Vancouver.
Peffers, K. T. T.; Rothenberger, M. A.; Chatterjee, S. (2008): A Design Science
Research Methodology for Information Systems Research. In: Journal of Management
210
Pohl, K.; Schürr, A.; Vossen, G. (Hg.) (1998): Modellierung ‘98, Proceedings des GIWorkshops in Münster, 11.-13. März 1998: CEUR-WS.org (CEUR Workshop
Proceedings, 9).
Pries-Heje, J.; Baskerville, R. L.; Venable, J. R. (2008): Strategies for design science
evaluation. In: Proceedings of the 16th European Conference on Information Systems
(ECIS 2008), 9.-11-Juni, Galway, Irland.
Prochnow, S.; Hanxlenden, R. von (2008): Empirische Forschungsmethoden in der
Softwaretechnik. Online verfügbar unter http://rtsys.informatik.uni-kiel.de/teaching/ws07-08/s-ems/proceedings.pdf#page=11, zuletzt geprüft am 24.10.10.
PWC (2006): IT Governance in Practice - Insight from leading CIOs. Herausgegeben
von PricewaterhouseCoopers Johannesburg. South Africa, IT Governance Institute
Rolling Meadows, USA.
Raab-Steiner, E.; Benesch, M. (2010): Der Fragebogen. Von der Forschungsidee zur
SPSS/PASW-Auswertung. 2. aktualisierte Auflage, Wien: Facultas-Verlag (UTB
Schlüsselkompetenzen, 8406).
Ralyté, J.; Rolland, C. (2001): An Assembly Process Model for Method Engineering.
In: 13th International Conference on Advanced Information Systems Engineering
(CAiSE 2001) (Lecture notes in computer science), S. 267–283.
Rauch, W.; Wersig, G. (Hg.) (1978): Delphi-Prognose in Information und
Dokumentation. Untersuchungen über zukünftige Entwicklungen des Bibliotheks-,
Informations- und Dokumentationswesens in der BRD und in Österreich. München.
Remme, M. (1997): Konstruktion von Geschäftsprozessen. Ein modellgestützter Ansatz
durch Montage generischer Prozeßpartikel. Dissertation, Saarbrücken, 1997.
Wiesbaden: Gabler (Schriften zur EDV-orientierten Betriebswirtschaft).
Remidez, H. ; Joslin, C. (2007): Using Prediction Markets to Support IT Project
Management. Research in Progress. In: International Research Workshop on IT Project
Management, Paper 10.
Rizopoulos, N.; McBrien, P.; Magnani, M. (2005): Schema Integration based on
Uncertain Semantic Mappings. In: 24th International Conference on Conceptual
Modeling (ER‘05) (Austria Lecture Notes in Computer Science, 3716), S. 31–46.
Rohloff, M. (2007): Ein Referenzmodell für die Prozesse der IT-Organisation. In: HMD
- Praxis Wirtschaftsinformatik, H. 256. S. 27-36.
Rosemann, M.; van der Aalst, W. M. P. (2007): A configurable reference modelling
language. In: Information Systems, Jg. 32, H. 1, S. 1–23.
211
Rüter, A.; Göldner, A.; Schröder, J. (2006): IT-Governance in der Praxis. Erfolgreiche
Positionierung der IT im Unternehmen. Anleitung zur erfolgreichen Umsetzung
regulatorischer und wettbewerbsbedingter Anforderungen. Springer-11774 /Digital
Serial.
Rumbaugh, J.; Jacobson, I.; Booch, G. (2005): The Unified Modeling Language
Reference Manual. Boston, San Francisco: Addison-Wesley.
Rumpe, B.; Hesse, W. (Hg.) (2004): Modellierung 2004. Proceedings zur Tagung, 23.26.03.2004 Marburg: Köllen Druck+Verlag (Lecture Notes in Informatics (LNI) Proceedings, 45).
Scheer, A.-W. (1990): EDV-orientierte Betriebswirtschaftslehre. Grundlagen für ein
effizientes Informationsmanagement. Berlin: Springer.
Scheer, A.W. (1997): Wirtschaftsinformatik – Referenzmodelle für industrielle
Geschäftsprozesse. 7. Auflage, Berlin: Springer.
Scheer, A.-W.; Seel, C.; Georg, W. (2002): Entwicklungsstand
Referenzmodellierung. In: Industrie Management, Jg. 18, H. 1, S. 9–12.
in
der
Scholz-Reiter, B. (1990): CIM – Informations- und Kommunikationssysteme.
München, Wien: Oldenbourg.
Schulze, D. (2001): Grundlagen der wissensbasierten Konstruktion von Modellen
betrieblicher Systeme. Aachen. Dissertation Bamberg.
Schütte, R. (1998): Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion
konfigurationsund anpassungsorientierter Modelle. Wiesbaden: Gabler (Neue
betriebswirtschaftliche Forschung, 233).
Schwegmann, A. (1999): Objektorientierte Referenzmodellierung. Theoretische
Grundlagen und praktische Anwendung. Wiesbaden. Dissertation Münster.
Seemann, J. (1998): UML- Unified Modeling Language. In: Informatik Spektrum, Jg.
21, H. 2, S. 89–90.
Shanks, G.; Tansley, E.; Weber, R. (2003): Using ontology to validate conceptual
models. In: Communications of the ACM, Jg. 46, H. 10, S. 85-89.
Shavrin, S. (2007): Ontological Multilevel Modeling Language. In: International
Journal "Information Theories & Applications", Jg. 14, S. 30-34.
Silva, E. (2008): IT offshoring risks and governance capabilities. In: HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences.
212
Simoneit, M. (1998): Informationsmanagement in Universitätsklinika – Konzeption und
Implementierung eines objektorientierten Referenzmodells. Wiesbaden: DVU.
Simonsson, M.; Johnson, P. (2008): The IT Organization Modeling and Assessment
Tool: Correlating IT Governance Maturity with the Effect of IT. In: HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences.
Simonsson, M.; Johnson, P.; Ekstedt, M. (2010): The Effect of IT Governance Maturity
on IT Governance Performance. In: Information Systems Management, Jg. 27, S. 10–
24.
Siviy, J.; Kirwan, P.; Marino, L.; Morley, J. (2008a): Maximizing your Process
Improvement ROI through Harmonization. Herausgegeben von Carnegie Mellon.
Software Engineering Institute, White Paper SEI, Pittsburgh, Pennsylvania.
Siviy, J.; Kirwan, P.; Marino, L.; Morley, J. (2008b): The Value of Harmonizing
Multiple Improvement Technologies: A Process Improvement Professional‘s View.
Herausgegeben von Carnegie Mellon. Software Engineering Institute, White Paper SEI,
Pittsburgh, Pennsylvania, USA.
Software Engineering Institute (2007): CMMI. Herausgegeben von Carnegie Mellon.
Software Engineering Institute, Pittsburgh, Pennsylvania.
Sommer, J. (2004): IT-Servicemanagement mit ITIL und MOF. Bonn: Mitp.
Spaccapietra, S.; Parent, C. (1994): View Integration: A Step Forward in Solving
Structural Conflicts. In: IEEE Transactions on Knowledge and Data Engineering, Jg. 6,
H. 2, S. 258–274.
Spaccapietra, S.; Parent, C.; Dupont, Y. (1992): Model Independent Assertions for
Integration of Heterogeneous Schemas. In: VLDB Journal, Jg. 1, H. 1, S. 81–126.
Stahlknecht, P.; Hasenkamp, U. (1999): Einführung in die Wirtschaftsinformatik. Berlin
et al.: Springer.
Stahlknecht, P.; Hasenkamp, U. (2005): Einführung in die Wirtschaftsinformatik. Berlin
et al.: Springer-Verlag (11. Auflage).
Staud, J. L. (2010): Unternehmensmodellierung. Objektorientierte Theorie und Praxis
mit
UML
2.0.
Online
verfügbar
unter
http://www.dandelon.com/intelligentSEARCH.nsf/alldocs/F509000B9971AEF8C12576150052B1CC/.
Abruf
20.10.2010.
Steimann, F.; Nejdl, W. (1999): Modellierung und Ontologie: Arbeitsbericht des
Instituts für Rechnergestützte Wissensverarbeitung. Herausgegeben von Leibniz
213
Universität Hannover. Hannover. Online verfügbar unter http://www.kbs.unihannover.de/Arbeiten/Publikationen/1999/M&O.pdf, Abruf 07.10.2007.
Strahringer, S. (1996): Metamodellierung als Instrument des Methodenvergleichs,
Shaker Verlag, Aachen.
Struckmeier, H. (1996): Gestaltung von Führungsinformationssystemen Betriebswirtschaftliche Konzeption und Softwareanforderungen. Dissertation
Universität Göttingen, Wiesbaden.
Studer, R.; Oppermann, H.; Schnurr, H.-P. (2001): Die Bedeutung von Ontologien für
das Wissensmanagement. Herausgegeben von Ontoprise GmbH. Istitut AIFB.
Karlsruhe.
Sure, Y.; Ehrig, M.; Studer, R. (2006): Automatische Wissensintegration mit
Ontologien. Universität Karlsruhe (TH); Institut AIFB: Ulrich Reimer and Knut
Hinkelmann.
Takeda, H.; Veerkamp, P.; Tomiyama, T.; and Yoshikawam, H. (1990): Modeling
design processes. In: AI Magazine, Jg. 11, H. 4, S. 37–48.
Ter Hofstede, A. H. M.; Verhoef, T. F. (1997): On the feasibility of situational method
engineering. In: Information Systems, Jg. 22, H. 6-7, S. 401–422.
Teubner, A. (1999): Organisations- und Informationssystemgestaltung - Theoretische
Grundlagen und integrierte Methoden. Wiesbaden: DUV/Gabler.
Thalheim, B. (2003): Informationssystem-Entwicklung - Die integrierte Entwicklung
der Strukturierung, Funktionalität, Verteilung und Interaktivität von großen
Informationssystemen Institut für Informatik, Brandenburgische Technische Universität
Cottbus, Preprint BTU Cottbus, Computer Science Institute, I-15-2003.
Theodoratos, D.; Ligoudistianos, S.; Sellis, T. (1999): Designing the global data
warehouse with SPJ views. In: Advanced Information Systems Engineering, Lecture
Notes in Computer Science, Volume 1626, S. 180-194.
Thomas, O. (2006): Das Referenzmodellverständnis in der Wirtschaftsinformatik.
Historie, Literaturanalyse und Begriffsexplikation. Herausgegeben von Peter Loos,
Institut für Wirtschaftsinformatik im Deutschen Forschungszentrum für Künstliche
Intelligenz, Heft 187.
Thomas, O.; Adam, O. H. K. (2003): Adaption von Referenzmodellen unter
Berücksichtigung
unscharfer
Daten.
In:
Dittrich
(Hg.):
Innovative
Informatikanwendungen. Informatik 2003, Beiträge der 33. Jahrestagung der
Gesellschaft für Informatik e.V. (GI), 29. Sept. - 2. Okt. 2003 in Frankfurt am Main;
Bonn: Gesellschaft für Informatik (GI-EditionProceedings, 34), S. 243–248.
214
Trites, G. (2004): Director responsibility for IT governance. In: International Journal of
Accounting Information Systems, Jg. 5, H. 2, S. 89–99.
Tuttle, B.; Vandervelde, S. D. (2007): An empirical examination of COBIT as an
internal control framework for information technology. In: International Journal of
Accounting Information Systems, Jg. 8, S. 240–263.
Victor, F.; Günter, H. (Hg.) (2004): Optimiertes IT-Management mit ITIL: ViewegVerlag.
Victor, F.; Günther, H. (Hg.) (2005): Optimiertes IT-Management mit ITIL. So steigern
Sie die Leistung Ihrer IT-Organisation; Einführung, Vorgehen, Beispiele. 2.,
durchgesehene Auflage, Wiesbaden: Vieweg (Edition CIO).
vom Brocke, J. (2007): Design Principles for Reference Modelling – Reusing
Information Models by Means of Aggregation, Specialisation, Instantiation, and
Analogy. In: Fettke, Loos (Hg.): Reference Modeling for Business Systems Analysis.
Hershey: Idea Group Publishing, S. 47–75.
vom Brocke, J. (2003): Referenzmodellierung. Gestaltung und Verteilung von
Konstruktionsprozessen. Dissertation, Münster, 2002. Berlin: Logos (Advances in
information systems and management science, 4).
Wagner, H. T. (2006): Managing the impact of IT on Firm Success. The Link between
the resources-based view and the IT Infrastructure Library. In: HICSS 2006 Proceedings of the 39th Annual Hawaii International Conference on System Sciences.
Wand, Y. (1996): Ontology as a foundation for meta-modelling and method
engineering. In: Information and Software Technology, Jg. 38, H. 4, S. 281–287.
Webb, P.; Pollard, C.; Ridley, G. (2006): Attempting to Define IT Governance: Wisdom
or Folly? In: HICSS ‘06 - Proceedings of the 39th Annual Hawaii International
Conference on System Sciences. Washington, DC, USA: IEEE Computer Society, S.
194–204.
Weill, P.; Ross, J. (2004): IT-Governance. How top performers manage IT decision
rights for superior results. Boston, USA: Harvard Business School Press.
Willson, P.; Pollard, C. (2009): Exploring IT Governance in Theory and Practice in a
Large Multi-National Organisation in Australia. In: Information Systems Management,
Jg. 26, S. 98–109.
Wolf, S. (2001): Wissenschaftstheoretische und fachmethodische Grundlagen der
Konstruktion von generischen Referenzmodellen betrieblicher Systeme. Dissertation
Universität Bamberg, Bamberg.
215
Yang, Y.; Padmanabhan, B. (2005): Evaluation of Online Personalization Systems. A
Survey of Evaluation Schemes and a Knowledge-Bases Approach. In: Journal of
Electronic Commerce Research, Jg. 6, H. 2, S. 112–122.
Zelewski, S. (1999): Grundlagen. In: Corsten, Reiß (Hg.): Betriebswirtschaftslehre.
München, Wien: Oldenbourg. S. 1–125.
Zelewski, S. (2007): Kann Wissenschaftstheorie behilflich für die Publikationspraxis
sein? Eine kritische Auseinandersetzung mit den Guidelines von Hevner et al. In:
Lehner, F.; Zelewski, S. (Hg.): Wissenschaftstheoretische Fundierung und
wissenschaftliche Orientierung der Wirtschaftsinformatik. Berlin: Gito, S. 71–120.
216
Fachbeitrag 7:
Towards a structured application of IT governance best practice reference models
Titel: Towards a structured application of IT governance best practice reference models
Autoren: Stefanie Looso
Veröffentlicht in: Proceedings of the Sixteenth Americas Conference on Information
Systems, Lima, Peru, 12.-15. August 2010.
217
Towards a structured application of IT
governance best practice reference
models
Stefanie Looso
Frankfurt School of Finance and Management
ABSTRACT
The perceived importance of the topic IT governance increased in the last decade. Best
practice reference models (like ITIL, COBIT, or CMMI) promise support for diverse
challenges IT departments are confronted with. Therefore, the interest in best practice
reference models (BPRM) grows and more and more companies apply BPRM to support
their IT governance. But there is limited knowledge about how BPRM are applied and there
is no structured method to support the application and lift the full potential of BPRM.
Therefore, this paper proposes a structured method for the application of BPRM. Intention
of this research is to reduce the inefficiencies caused by inconsistent and ad-hoc use of
BPRM. The scientific adequacy as well as the practical applicability is critically discussed
by using practical experiences out of an ongoing research project.
Keywords
Method Engineering, Design Science Research, Best Practice, Reference Models, IT
Governance.
INTRODUCTION
As a central instrument for the design of corporate information systems within the field of
information systems research, information models have traditionally been used for decades.
A reference model is defined as a generic model which is useful when developing an
individual information model of a specific class. It formally presents state-of-the-art and
best practice knowledge and is considered as an example for a corporate model (Fettke and
Loos, 2003; Rosemann and van der Aalst, 2007).
Best practice models in the research field IT governance, like COBIT (Control Objectives
for Information and related Technology), ITIL (IT Infrastructure Library) or CMMI
(Capability Maturity Model Integrated), are used to assess, build or manage information
model. (Co-) produced by practitioners these models also contain profound and consolidated
knowledge based on experience in the field of IT governance and tend to become quasistandards (PWC, 2006; Alter and Goeken, 2009). That means that the models of IT
governance focused on herein could be defined as reference model. But these models are
conceived as structured compilations of best practice rather than conceptual reference model
as known in scientific literature. Therefore, in order to avoid misleading terms and
218
misconceptions, reference models of IT governance will be referred to as best practice
reference model (BPRM) in this paper.
Those BPRM have reached a certain degree of commonness in practice. Their application is
still growing, but seems to be inconsistent. The study ―IT Governance in Practice - Insight
from leading CIO‘s‖ quotes one participant on the application: „I use frameworks and
standards for inspiration, and we use what we think is useful and relevant for our
organization― (PWC, 2006, p. 18). Other companies use BPRM even more holistic and with
a higher degree of obligation. The application of BPRM, for instance the derivation of
corporate specific models out of BPRM, is often ad-hoc and individual (see qualitative
empirical research findings presented in Looso and Goeken, 2010). This is clearly opposed
to the nature of reference models since the construction of corporation-specific models
based on reference model promises positive effects on effectiveness and efficiency (see
Fettke and Loos, 2002, p. 9; Becker, Delfmann and Knackstedt, 2004, p. 1). To reduce
inefficiencies and to lift their full potential this paper presents a method for the methodical
and structured application of IT governance BPRM.
This method is a part of a research project. The research project starts with explorative
expert interviews in addition to a literature review to broaden the understanding of BPRM
application (Looso and Goeken, 2010). Figure 1 shows the position of the research project
in the well known conceptual framework of Hevner, March, Park and Sudha (2004).
According to their framework the knowledge base “provides the raw materials from and
through which IS research is accomplished. The knowledge base is composed of
foundations and methodologies“ (Hevner et al., 2004, p. 80). Following this definition the
knowledge base for this research project includes research on reference models and
modeling, method engineering and IT governance but also on research methods like
interview techniques, qualitative analysis etc.
The environment includes the phenomena of interest. „In it are the goals, tasks, problems,
and opportunities that define business needs as they are perceived by people within the
organization―(Hevner et al., 2004, p. 79). For research on the BPRM of IT governance this
environment is composed of IT employees, IT organization, IT goals, processes and the
existing best practices and standards.
219
IT Governance
Environment
IT
Governance
Structures
Compliance
IS
Research
Knowledge
Base
Rigor
Literature
Review and
Semi Structured
Interviews
IT
Governance
Processes
Reference
Modeling
Interview
Techniques
Method
Engineering
Application
of IT
Governance
Reference
Models
IT Goals
Best
Practices
IT
Governance
Models
Relevance
Business Needs
Method
Construction
Applicable
Knowledge
Metamodeling
Method
Evaluation
...
...
Application in the IT Governance Environment
IS Artifact:
Specific Method
Instance of
for the BPRM
COBIT
Evaluation
Theory
Additions to the Knowledge Base
Method:
Generic Method
for BPRM
Application
Fig. 1. Research project (according to Hevner et al., 2004 )
Outcome of this research is a generic method for BPRM presented in section 2. The
construction process of the generic method follows a rigor research design by using the
existing and proved knowledge of IS research. Section 3 shows the application of this
method for the specific BPRM COBIT. The various possible specific methods (for COBIT,
ITIL, CMMI, etc.) are instances of the generic method and represent relevant IS artifacts
which provide support for practical problems. That means the practical application of the
specific method is an application for the IT governance environment whereas the generic
method is a contribution to the knowledge base of IT governance research. Section 4 draws
a conclusion and discusses the research findings.
METHOD CONSTRUCTION
Preliminaries: Method Engineering
Methods describe a systematic approach to the solving of problems. A problem is defined as
a discrepancy between actual and desired state (Becker, Knackstedt, Pfeiffer and Janiesch,
2007). Focused on the creation of methods, the research area of method engineering (ME) is
a commonly accepted and frequently debated concept in construction-oriented IS research.
Brinkkemper (1996, p. 276) defines: “method engineering is the engineering discipline to
design, construct and adapt methods, techniques and tools for the development of
information systems“.
Basically, there are two tendencies within ME. Some approaches of method construction
emphasize aspects of the construction process and project management (Kaschek, 1999). In
contrast, the approach of a language-based construction of method elements focuses on the
artifacts created. In recent years the latter approach has been focused on in the field of
220
methods engineering (Brinkkemper, 1996; Ralyté and Rolland, 2001; Karlsson and
Wistrand, 2006). Language-based ME defines a method primarily as a tupel of a type of
exercise and a number of rules. It requires a formalized documentation of method elements
(Becker, Knackstedt, Holten, Hansmann and Neumann, 2001, p. 6). The St. Gallen
description model of method engineering (Heym, 1993; Gutzwiller, 1994; Becker, 1998)
includes a schematic composition of the elements: meta model, result, activity, technique,
and role (Figure 2). According to its language-based interpretation, the description of these
elements offers a possibility to develop a method systematically.
Meta model
is a conceptual model of
Result
generated and used by
Activity
is supported by
done or planned by
Technique
Role
Fig. 2 St. Gallen model of method elements (Heym, 1993, p. 13)
In contrast to the St. Gallen model this approach understands technique as a supporting
detail for activity. That means the method concept presented herein presumes a relation
between activity and technique. Because of the limited space the presentation of the element
role is not a part of this first paper. Due to the generic character of the method the following
subsections describe generic types of the different method elements instead of concrete
method elements.
Method Element: Result Type
Results of the suggested method are several different models. They belong to certain result
types which can be divided by two dimensions. The first division is between two abstract
levels, the meta level and the model level. The second dimension distinguishes between
reference layer and corporate layer.
The result types are depicted in the meta model shown in Figure 3. Hence, result type best
practice reference model is defined as a model on model level and reference layer. A
possible instantiation of this type would be the BPRM COBIT 4.1. Result type company
model stands for a BPRM that has been adjusted to corporate-specific conditions. An
exemplifying instantiation is a COBIT 4.1 subset which only some parts of the BPRM.
Additionally, the method is familiar with various forms of other company models (i.e.
company‘s IT process models). All of them are associated with the lower right section of the
matrix, but a company specific COBIT could be applied to parts of an existing IT process
model. This relationship is also shown in figure 3. Building a company model it could be
necessary to change the meta model the model is based on. These changes of the best
practice reference meta model result in a company specific best practice meta model. These
two abstract result types complete the result types used for the presented method.
221
Meta Level
Best Practice
Reference Meta
Model
is adjusted to
has high level
abstraction
has high level
abstraction
Model Level
Best Practice
Reference Model
Company Specific Best
Practice Meta Model
is adjusted to
Company Model
is applied to
Reference Layer
Company Specific Layer
Fig. 3. Meta classification of result types of the generic method
Method Element: Technique Type
A technique is defined as “a procedure, possibly with a prescribed notation, to perform a
development activity” (Brinkkemper, 1996, p. 276). Applied on this approach techniques
are used to support activities transforming models to other models. Therefore, techniques
used in this method are defined as mechanisms to support the activities which transform a
reference model step by step to a company model. These techniques could be derived from
available research on reference model application. Conclusions from research on reference
models can be included especially if the methods themselves are formally represented by
models (shown in section 2.2). Thus, the concepts of reference model application provide
important information about the design of techniques within the presented method.
Becker et al. (2004) provide two types of adaptation mechanisms for reference models: The
mechanisms of generative adaptation describe all modes of a reference model‘s
configuration, given the existence of rules which determine how to adjust the reference
model depending on mechanisms of configuration. These rules should be included in the
reference model. As mentioned, best practice reference models of IT governance are
conceived as structured compilations of best practice rather than conceptual models.
Therefore, BPRM do not usually contain explicit rules for model configuration.
Apart from configuration, Becker et al. (2004) describe four mechanisms of non-generative
adaptation. What generally characterizes mechanisms of non-generative adaptation is ―that
while they support the creation of specific model variants, they leave room for variety to be
filled by the user of the reference model‖ (Becker et al., 2007, p. 1). As this matches the
situation in the area of BPRM, the four non-generative adaptation mechanisms will be
concisely described and integrated into the method as technique types. Aggregation requires
the reference model to be divided into its components which are recomposed by aggregation
for new solutions. Combinations can be limited by defined joints. Instantiation ultimately
describes the existence of deliberately vague formulations or blank spaces as placeholders to
be specified by users. In order to develop a BPRM into an explicit model system,
placeholders have to be filled in a corporation-specific way. A BPRM is more freely and
individually adaptable through instantiation than through aggregation. Analogy construction
222
and specialization are very free forms of adaptation in which prescriptions for adjustment
are mostly absent.
The use of these adaptation mechanisms of reference models within the area of method
construction has been accomplished several times. For instance (Harmsen, 1997) or
(Brinkkemper, 1996) use the mechanism aggregation, whereas (Baskerville and Stage) or
(Patel, de Cesare, Iacovelli and Merico, 2004) use specialization. A broad overview is given
from (Becker et al., 2007, p. 5). To sum up, to a certain degree adaptation mechanisms of
reference models could be used for BPRM as well. These techniques support the activities
presented in the following section.
Method Element: Activity Type
A possibility to distinguish activities is presented by Schütte (1998, pp. 316–319). Firstly,
compositional activities mean that individual parts of a model are erased, altered, or added
in order to improve a reference model‘s fit. Secondly, generic adaptation activities means
explicitly described rules of adaptation. These rules are defined explicit within the model to
be observed for adjustment of the reference model. But these generic adaptation activities
are not usually employed since most BPRM do not contain rules for adaptation.
The herein presented activities structure a method by combining techniques, results and
roles. Our generic method has three different activity types: subset selection, adjustment and
application (see figure 4). If a BPRM is not entirely used, it is limited by selecting a BPRM
subset which is relevant for a corporation (Gammelgard, Lindstrom and Simonsson, 2006).
This decision is not necessarily based within the model itself but can be entirely strategic
(Bowen, Cheung and Rohde, 2007). Hence activity type subset selection is take place before
activity type adjustment. During the subsequent adaptation, the chosen subset is
continuously adjusted to the corporation. The activity type application completes the
generic activity types. In the following, all three activity types will be described in detail
jointly with their proposed techniques.
223
BPRM
Selection
BPRM
BPRM is
selected
Subset
Selection
Company
Model: COBIT
Subset
BPRM Subset is
selected
BPRM (Subset)
Adjustment
Company
Model
Explicit BPRM
is modeled
Application
Company
Model
BPRM is applied
in the Company
Fig. 4. Event-driven-chain the proposed method
Activity 1: Subset Selection
By selecting a subset the BPRM is transformed to first company model: the BPRM subset.
The process of selection itself with its internal organizational and communicative aspects is
not addressed in this paper. However, possible categories of this subset are interesting for
this research. The chosen criterion to classify subsets is completeness. Two cases occur in
the first place, complete and partial use. The former makes the result type subset obsolete as
the BPRM and the subset are identical. But if some parts are selected while others are not,
the following applies to the contents described within the model: BPRM subset < BPRM.
For detailed specification, further classification criteria are required. These criteria can be
derived by abstraction of BPRM into a best practice reference meta model. A meta model
224
created by semantic abstraction can show possible sub divisions of the case ―partial
application‖ by means of content and structure (Alter and Goeken, 2009).
A model‘s structure is defined by its meta model components. A limitation of the applied
meta model components is typical for a reduction of a model‘s range, for instance a COBIT
subset which only contains the COBIT meta model component COBIT control objectives
(Simonsson and Johnson, 2008; de Haes and van Grembergen, 2008). It turns out that this
activity changes the structure of the model.
The second case to be regarded is defined by reduction of the model‘s depth. Accordingly,
all meta model components are employed in respect to the BPRM but not all model
components (e.g. not all processes, see Gammelgard et al., 2006 or Tuttle and Vandervelde,
2007). Thus the content is reduced. These subsets leave the model‘s structure unchanged.
The reduction of model components results in different problems than the reduction of meta
model components does. This is due to interconnections of content, such as predecessorsuccessor-relations, which can cause successors to be left without any input or the output of
a process to remain unused. Hence, model components have to be aggregated on a model
level as well.
Models Range
All Meta Model Components
Some Meta Model Components
Models Depth
All Model Components
Subset Type 1
Subset Type 2
Some Model Components
Subset Type 3
Subset Type 4
Table 5: Subset types
Table 1 shows the possible types of the BPRM subset. We believe that most companies use
subsets from type 4, that means structure and content based connections of the models
elements could be broken. In this case the (re)-combination of the chosen elements is an
essential step in this activity. Hence a meta model of a BPRM offers possibilities for the
combination of both meta model components and model components to a coherent BPRM
subset. A coherent COBIT-subset does not, for instance, allow the use of metrics of the
COBIT processes unless the goals of the process are used as well. This is because only the
component goal links the component process with the component metric. Hence, the quality
of meta models in best practice reference models is essential for this research project (Alter
and Goeken, 2009, Goeken and Alter, 2009).
To sum up, the activity subset selection results in a BPRM subset. It includes only these
components of a BPRM which are relevant for a specific company. This result is an
instantiation of the result type company model. In a next step the BPRM subset needs
further adjustment to the corporate conditions.
Activity 2: Adjustment to Corporate Conditions
Once the relevant BPRM subset has been selected, the next step is the transformation into
the explicit model particular to one specific BPRM and one specific corporation. During this
activity the user specifies those model sections which formerly remained deliberately vague.
225
However, it usually remains unclear for BPRM which model sections have remained vague
on purpose and require instantiation. Order and design of the model component “metric of
process x” in the COBIT model allow the assumption that metric is a components which
requires further adjustment.
Exemplary in character, the metrics of a COBIT process should be completed with
individual metrics. Along with the mechanism of adaptation in the presented example,
Figure 5 depicts the instantiation of the metric placeholder for a number of corporatespecific metrics. Other mechanisms are applied during the development of the explicit
model as well. Supporting the instantiation both specialization and analogy construction
should be primarily used in the following third step. This is due to the relation between the
BPRM and the company model. Here, the company model is taken as an altered part of the
BPRM, which should basically remain recognizable in this intermediate result. Control by
IT auditors is thus facilitated in case of COBIT. This can change due to the more variable
mechanisms of model adaptation, which is why too much room for variation in adaptation
mechanisms should be avoided in this activity.
Meta Level
Process
supports
Goal
supports
Deliver Projects on
Time and on Budget
Meeting Quality
Standards
is
measured
by
Metric
is
measured
by
Percent of Projects
Meeting Stakeholder
Expectations
Model Level
Reference Process
PO 10
Instantiations
Company‘s Process
PO 10 Manage
Projects
supports
Deliver Projects on
Time and on Budget
Meeting Quality
Standards
is
measured
by
Percent of Projects Meeting 90% of ISO9000
Requirements
Percent of Projects on Time (1,25-fold of
Target Duration)
Fig. 5 Instantiation of a COBIT metric
Activity 3: Application to the Company
The activity application to the company combines at least two results of the method. The
adjusted company model derived from the BPRM includes the relevant and adjusted
components of the reference model. These components should be applied to a second
company model. Depending on the BPRM this company model can consist of either the
process model of IT processes or a smaller part such as a model of IT project management.
These models will be change with regard to adjusted BPRM subset of the company. For
instance the COBIT process AI6 ―Manage Changes‖ requires a separate change
management procedure for emergency changes (IT Governance Institute, 2007, p. 94). If
this process is chosen during the activity subset selection the process model of the company
possibly needs to be change. But how emergency changes differ from other changes is not
described in COBIT. Thus specialization and analogy construction are important
mechanisms during this activity since BPRM of IT governance usually specify what to do
226
rather than how to do it. Those challenges of establishing have to be fulfilled by means of
analogy construction in which the explicit model serves as a state-to-be and to inspire ideas.
„Analogies can be drawn from any aspect of the reference model which can be indicated by
the annotation of analogy construction advices―(Becker et al., 2007, p. 3).
PRACTICAL APPLICATION OF THE METHOD DURING A RESEARCH PROJECT
The rigorous evaluation of the research results is an important topic in design science
research (DSR). Vaishnavi and Kuechler (2004) state that designed artifacts must be
analyzed as to their use and performance as possible explanations for changes in the
behavior of systems, people, and organizations. Hevner et al. (2004) propose five kinds of
evaluation methods (observational, analytical, experimental, testing, and descriptive) but
they not provide support for choosing a concrete evaluation method. Pries-Heje, Baskerville
and Venable (2008, p. 2) provide concrete strategies for DSR evaluation. Following their
approach 1) an ex ante strategy and 2) an ex post strategy has to be discussed for the
evaluation of our method. Ex ante evaluation means the evaluation of candidate methods
before they are chosen and applied. In our case there are no competitive methods against
which our method could be tested. But companies apply BPRM without using structured
methods. This unstructured, creative process could be a competitor during the ex ante
evaluation. Following Harter, Mayuram S. Krishnan and Slaughter (2000) we believe that
any structure process has advantages against unstructured application of BPRM.
Ex post evaluation means an evaluation after the method is applied. The approach of Yang
and Padmanabhan (2005) suggests four categories for ex post evaluation methods (table 2).
Setting
Computation
of Quality
Measures
Real Setting
Abstract Setting
Automatic
1. Experimental Designs
3. Historic Data Experiments
Human
Subjects
2. User Opinion Studies
4. Opinions Analysis of
Historical Data
Table 6: Categories of ex post evaluation methods (adapted from Yang and Padmanabhan, 2005)
The ex post evaluation of our method includes two steps due to the characteristics of the
artifact. As the method described has a generic character, it is indirectly evaluated in a first
step by application to a specific case, in which its general usability is proven. Therefore a
specific method for the application of COBIT is derived from of the presented generic
method. For this COBIT method we choose user opinion studies to evaluate practical
usefulness. This is part of an ongoing research project and the following paragraphs show a
short insight in our current work.
The research project aims to support the application of BPRM. By using semantic
technologies we are developing a tool named SemGoRiCo. This tool is based on the
presented generic method. SemGoRiCo supports the three generic activities (section 2)
adjusted to the specific characteristic of the COBIT framework. Figure 6 shows the derived
227
COBIT method and some tool components as implementations of the previously described
activities.
Tool Component:
COBIT 4.1
COBIT 4.1
COBIT is
Selected
COBIT Subset
Selection
Part of the Tool
Component COBIT
Subset Selection
My COBIT 1
COBIT
Subset is
Selected
My COBIT 1
Adjustment
My COBIT 2
Tool Component
My COBIT 1
Adjustment
My COBIT 2
is Modeled
Company
Model
Application
My COBIT 2
to Company
Model
Fig. 6: COBIT application method and tool support
Using this tool supports the structured BPRM application according to the presented
method. The associate partners of the research project will test this tool and thereby we
could ex post evaluate the specific applicability of our proposed generic method with a user
opinion study.
CONCLUSION
To conclude we constructed and partly developed a method for BPRM application. This
approach follows the language-based method engineering concept by presenting formally
described static method element types and their instantiations. Furthermore the presentation
includes dynamic aspects by describing processes and procedures concerning the transition
between various instantiations of the method element types. This method aims to be an
addition to the knowledge base of IT governance research and a practical solution for
challenges IT departments are confronted with. To show its practical use we instantiated the
presented generic method to a specific method for COBIT. In an ongoing research process
we refine and extend the specific COBIT method. These research findings should be a
sound basis for the construction of methods for applying BPRM. To prove the general
applicability of our generic method several other specific methods have to be derived (ITIL,
CMMI etc.) and tested ex post by using user opinion studies, but this is future research.
228
Reference List
Alter, S. and Goeken, M. (2009) Konzeptionelle Metamodelle von IT-GovernanceReferenzmodellen als Basis der Kombination und Integration in einer Multi-ModelUmgebung, in Hansen, H.R., Karagiannis, D., Fill, H.G. (Ed.), Business Services:
Konzepte,
Technologien,
Anwendungen.: 9.
Internationale
Tagung
Wirtschaftsinformatik, Band 1, Wien.
Baskerville, R. and Stage, J. Accommodating Emergent Work Practices: Ethnographic
Choice of Method Fragements: IFIP TC8/WG8.2 Working Conference on Realigning
Research and Practice in IS Development: The Social and Organisational Perspective,
Boise, ID, 2001, 12.28.
Becker, J., Delfmann, P. and Knackstedt, R. (2004) Konstruktion von
Referenzmodellierungssprachen: Ein Ordnungsrahmen zur Spezifikation von
Adaptionsmechanismen für Informationsmodelle. Wirtschaftsinformatik, 46(4), 251–
264.
Becker, J., Knackstedt, R., Holten, R., Hansmann, H. and Neumann, S. (2001). Konstruktion
von Methodiken: Vorschläge für eine begriffliche Grundlegung und domänenspezifische
Anwendungsbeispiele.
Westfälische
Wilhelms-Universität
Münster,
from
http://www.wi.uni-muenster.de/inst/arbber/ab77.pdf.
Becker, J., Knackstedt, R., Pfeiffer, D. and Janiesch, C. (2007) Configurative Method
Engineering: On the Applicability of Reference Modeling Mechanisms in Method
Engineering, in Proceedings of the 13th Americas Conference on Information Systems
(AMCIS 2007).
Becker, M. (1998). Umsetzung betrieblicher Prozesse: Methode, Fallbeispiele, WorkflowTechnologie. Dissertation, Universität St.Gallen, St.Gallen.
Bowen, P., Cheung, M.-Y. and Rohde, F. (2007) Enhancing IT governance practices: A
model and case study of an organization‘s effort. International Journal of Accounting
Brinkkemper, S. (1996) Method engineering: engineering of information systems
development methods and tools. Information & Software Technology, 38(4), 275–280.
Fettke, P. and Loos, P. (2002) Methoden zur Wiederverwendung von Referenzmodellen –
Übersicht und Taxonomie, in J. Becker & R. Knackstedt (Eds.), Arbeitsberichte des
Instituts für Wirtschaftsinformatik WWU: Vol. 90. Referenzmodellierung 2002 Methoden
– Modelle – Erfahrungen, 9–30.
Fettke, P. and Loos, P. (2003) Classification of reference models—a methodology and its
application. Information systems and ebusiness management, 1(1), 35–53.
Gammelgard, M., Lindstrom, A. and Simonsson, M. (2006) A reference model for IT
management responsibilities, in . EDOCW ‟06: Proceedings of the 10th IEEE on
International Enterprise Distributed Object Computing Conference Workshops,
Washington, DC, USA: IEEE Computer Society, 26-26.
Goeken, M. and Alter, S. (2009) Towards Conceptual Metamodeling of IT Governance
Frameworks: – Approach – Use- Benefits, in . HICSS 2009 - Proceedings of the 42th
Hawaii International Conference on System Sciences.
229
Gutzwiller, T. (1994). Das CC RIM-Referenzmodell für den Entwurf von betrieblichen,
transaktionsorientierten Informationssystemen. Heidelberg, Physica-Verlag.
Haes, S. de and van Grembergen, W. (2008) An exploratory Study into the design of an IT
Governance Minimum Baseline through Delphi Research. Communications of the
Association for Information Systems, 22(Article 24), 443a.
Harmsen, A. (1997). "Situational Method Engineering. Utrecht.
Harter, D., Mayuram S. Krishnan and Slaughter, S. (2000) Effects of Process Maturity on
Quality, Cycle Time, and Effort in Software Product Development. Management
Science, 46(4), 451‐ 466.
Hevner, A., March, S., Park, J. and Sudha, R. (2004) DESIGN SCIENCE IN
INFORMATION SYSTEMS RESEARCH. MIS Quarterly, 28(1), 75–106.
Heym, M. (1993). Methoden-Engineering - Spezifikation und Integration von
Entwicklungsmethoden für Informationssysteme. Disseration, Universität St.Gallen,
Hallstadt.
IT Governance Institute (2007). COBIT 4.1. o.O.
Karlsson, F. and Wistrand, K. (2006) Combining method engineering with activity theory:
theoretical grounding of the method component concept. European Journal of
Information Systems, 15(1), 82–90.
Kaschek, R. (Ed.). 1999. Entwicklungsmethoden für Informationssysteme und deren
Anwendung: EMISA '99, Fachtagung der Gesellschaft für Informatik e. V. (GI).
Stuttgart, Leipzig.
Looso, S. and Goeken, M. (2010) IT Governance: Application of Best Practice Reference
Models, in Proceedings of the 18th European Conference on Information Systems (ECIS
2010).
Patel, C., Cesare, S. de, Iacovelli, N. and Merico, A. (2004) A Framework for Method
Tailoring: A Case Study, in 2nd OOPSLA Workshop on Method Engineering for
Object-Oriented and Component-Based Development, Vancouver,
Pries-Heje, J., Baskerville, R. and Venable, J. (2008) Strategies for design science
evaluation, in Proceedings of the 16th European Conference on Information Systems
(ECIS 2008).
PWC (2006). IT Governance in Practice - Insight from leading CIOs.
PricewaterhouseCoopers Johannesburg, South Africa, IT Governance Institute Rolling
Meadows, USA.
Ralyté, J. and Rolland, C. (2001) An Assembly Process Model for Method Engineering, in
Lecture notes in computer science: . 13th International Conference on Advanced
Information Systems Engineering (CAiSE 2001) (267–283).
Rosemann, M. and van der Aalst, W. (2007) A configurable reference modelling language.
Information Systems, 32(1), 1–23.
Schütte, R. (1998). Grundsätze ordnungsmäßiger Referenzmodellierung: Konstruktion
konfigurationsund
anpassungsorientierter
Modelle
(Vol.
233),
Neue
betriebswirtschaftliche Forschung, 233, Gabler, Wiesbaden.
Simonsson, M. and Johnson, P. (2008) The IT Organization Modeling and Assessment
230
Tool: Correlating IT Governance Maturity with the Effect of IT, in . HICSS 2008 Proceedings of the 41st Annual Hawaii International Conference on System Sciences,
Washington, DC, USA: IEEE Computer Society, 431.
Tuttle, B. and Vandervelde, S. (2007) An empirical examination of COBIT as an internal
control framework for information technology. International Journal of Accounting
Vaishnavi, V. and Kuechler, W. (2004). Design Science in Information Systems. Retrieved
February 12, 2009, from http://desrist.org/design-research-in-information-systems/.
Yang, Y. and Padmanabhan, B. (2005) Evaluation of Online Personalization Systems: A
Survey of Evaluation Schemes and a Knowledge-Bases Approach. Journal of Electronic
Commerce Research, 6(2), 112–122.
231
Zwischenfazit Teil D
Ziel dieses Teils war die Entwicklung einer Methode zur Unterstützung der
Anpassung und Anwendung von BPRM. Zur Umsetzung dieses Gestaltungsziels
wurden die bis dahin in der Arbeit erzielten Forschungsergebnisse mit bereits
etablierten Forschungsergebnissen der gestaltungsorientierten Wirtschaftsinformatik
kombiniert. Da bislang in der Wissenschaft keine vergleichbaren Methoden zur
Anwendung von BPRM entwickelt wurden, war es zunächst nötig, die theoretische
Basis für die Konstruktion zu schaffen, d.h. die anwendbaren Ergebnisse anderer
Forschungsgebiete zu identifizieren.
Es wurde gezeigt, dass die Anwendung von BPRM Ähnlichkeiten zur Anwendung
von Referenzmodellen aufweist und die Methodenkonstruktion im
Forschungsgebiet Methoden-Engineering thematisiert wird. Forschungsergebnisse
aus der Referenzmodell-Forschung und der Methoden-Konstruktion waren
demnach die notwendige theoretische Basis dieses vierten Teils. Neben etablierten
Forschungsergebnissen wurden auch die bislang in dieser Arbeit erzielten
Ergebnisse verwendet. So wurde die Methode unter Zuhilfenahme der in Teil B
vorgestellten Metamodelle von BPRM und des entwickelten Ordnungsrahmens der
Anwendung von BPRM (Teil C) entwickelt.
Ziel der Methodenentwicklung war es, sowohl theoretischen als auch praktischen
Nutzen zu stiften. Durch die Entwicklung einer generischen Methode konnte ein
Mehrwert für die IT-Governance-Forschung geschaffen werden. Praktischen
Nutzen stiftet die entwickelte Methode durch die mögliche Anpassung auf ein
konkretes BPRM. Dieser praktische Nutzen wurde im Fachbeitrag 6 anhand des
COBIT-Modells illustriert. Fachbeitrag 6 beinhaltet außerdem bereits Teile der
Werkzeugunterstützung für die Anpassung und Anwendung von COBIT, die im
SemGoRiCo-Projekt entwickelt wurde.
232
Teil E: Wissenschaftstheoretische Aspekte der
Methodenentwicklung
Vorbemerkungen Teil E
Dem Memorandum zur gestaltungsorientierten Wirtschaftsinformatik lässt sich
Folgendes entnehmen:
„Die gestaltungsorientierte Wirtschaftsinformatik bedient sich vor allem der
Deduktion. In günstigen Fällen kann sie formal (mathematisch) herleiten,
vielfach benutzt sie semiformale (konzeptionelle) Instrumente, in den meisten
Fällen arbeitet sie mit natürlichsprachlicher (argumentativer) Deduktion mit
Rückgriff auf vorhandene Theorien. Ein wesentlicher Teil ihrer
wissenschaftlichen Leistung liegt in der Strukturierung und Integration von
vorhandenem Wissen. Induktiv arbeitet die gestaltungsorientierte
Wirtschaftsinformatik beispielsweise, wenn sie erfolgreiche Lösungen aus
Fallstudien ableitet.―339
Die sich daraus ergebende fehlende forschungsmethodische Strenge, im Sinne der
„rigor vs. relevance―-Diskussion, führt immer wieder zu Kritik an der
gestaltungsorientierten Wirtschaftsinformatik. Im folgenden Fachbeitrag wird daher
ein Vorschlag präsentiert, der die konzeptionelle Forschung um empirischbehavioritische Aspekte erweitert. Ziel ist es, eine Erweiterung für die Konstruktion
von
Methoden
zu
entwickeln,
welche
praktische
Relevanz
mit
forschungsmethodischer Strenge verbindet. Hintergrund des achten Fachbeitrages
ist also der konzeptionelle Entwicklungsprozess von Methoden, d.h. der
Entwicklungsprozess der in Fachbeitrag 6 und 7 präsentierten Methode. Abbildung
61 zeigt einen Überblick über Teil E.
339
Österle, H.; Becker, J.; Frank, U.; Hess, T.; Karagiannis, D.; Krcmar, H. et al. (2010):
Memorandum zur gestaltungsorientierten Wirtschaftsinformatik, S. 6.
233
Erkenntnis: Konzeptionelle Methodenkonstruktion
(KMK) hat Schwächen
Fachbeitrag 8
Abbildung 61: Darstellung Teil E: Forschungsmethodische Erweiterung der
Methodenentwicklung zur Anwendung von BPRM
234
Fachbeitrag 8:
Using Grounded Theory for Method Engineering
Autoren: Stefanie Looso, René Börner; Matthias Goeken
Challenges in Information Science (RCIS 2011), 19.-21.05.2011, Guadeloupe French West Indies, France.
235
Using Grounded Theory for Method Engineering
Stefanie Looso, René Börner, Matthias Goeken
Frankfurt/Main, Germany
{s.looso;r.boerner;m.goeken}@fs.de
Abstract – Grounded theory is a qualitative research approach
that can be used to build theory from empirical data in an
explorative fashion. Although the field of method engineering is a
relatively mature research area, a lack of empirical grounding
can be attested since method engineering is commonly based on
literature reviews and follows a deductive, construction-oriented
engineering process. Particularly, the constituent elements of
methods (such as activities and techniques) are seldom grounded
in empirical data. In order to enrich method engineering
research and to base methods and their elements on empirical
data, this paper combines features of method engineering and
grounded theory. The result is a methodological support for the
method engineering process that follows techniques acquired
from grounded theory. This new approach to method engineering
shall be called grounded method engineering. It is meant to
improve a method’s quality before an application or
configuration takes place by anchoring its constituent elements in
empirical data. Hence, grounded method engineering will
underpin methods to be developed by extracting domain
knowledge using techniques found in grounded theory.
Keywords-Grounded Theory, Method Engineering, Empirical
Research, Method Elements, Design Science Research
I. INTRODUCTION
As for any applied science, the debate between scientific
rigour and practical relevance also characterises information
systems research (ISR). Especially research areas with strong
relationships to the day to day practice of IS professionals are
often confronted with the rigour vs. relevance discussion [1; 2].
Methods are dedicated to solving existing problems. Therefore,
method engineering focuses the construction of relevant
artefacts that can be used in practice, but researchers have
started to discuss how the method engineering process can be
made more rigorous [3]. But so far method engineering
research largely follows a research process which focuses on
relevance instead of rigour and the transfer of domain
knowledge follows an unstructured and intuitive process [4; 5].
Goal of the approach presented herein is to enrich method
engineering by grounding resulting methods in empirical data.
Therefore, we support method engineering with grounded
theory [6], a research method designed as a behaviouristic
method which gains sociological theory from empirical data.
Although [6] clearly argue that only sociologists can use
grounded theory to generate sociological theory, the concept of
grounded theory has been applied to several other research
areas in recent years. Reference [7] already notices that
grounded theory could be used in various disciplines. They
dedicated their book to researchers that are interested in
inductively building theory through qualitative analysis of data.
We argue that parts of the grounded theory methodology
can improve the construction of methods and thus add rigour to
method engineering approaches. Therefore, we present
grounded method engineering (GME) which aims to produce
relevant methods following a more rigorous process by using
empirically grounded method elements. The basic idea is to
enrich the usual construction-oriented and literature-based
derivation of method elements with grounded information
derived from empirical data.
The paper is organised as follows: Section 2 presents our
research process, while section 3 discusses method engineering
and the concept of grounded theory. The fourth section
theoretically presents grounded method engineering and
exemplarily demonstrates the application in the field of IT
governance. Finally, in section 5 we will discuss our findings,
show limitations of the approach and potential for further
research.
II. RESEARCH DESIGN
On our way to designing grounded method engineering, we
follow the research design proposed by [8] that is depicted in
figure 1. The intriguing question for our research is what
method engineering can learn from grounded theory and its
application in IS research. Therefore, our research process
commences with an analysis of literature from the fields of
method engineering and grounded theory in order to identify
challenges of method engineering and motivate our research.
These analyses yielded two results: First, the engineering of
methods and their constituting elements is rarely based on
empirical evidence but on literature or intuition instead.
Second, procedures from grounded theory such as open coding
and axial coding can be used to complement method
engineering approaches. The definition of a solution‘s
objectives is important to evaluate a newly created artefact.
Along with the identification of the problem and the
motivation, this definition of objectives is part of section 3 of
this paper.
In section 4, design and development of our artefact, i.e.
GME, is the next step. We therefore show how procedures
from grounded theory can be used for an empirical grounding
of method engineering. A central aspect is the transformation
236
of the coding paradigm used for axial coding in grounded
theory to adapt it to method engineering. The second part of
section 4 demonstrates how grounded theory procedures can be
applied in a method engineering context. For this purpose, an
example from the field of IT governance is described.
Section 3
Identify Problem & Motivate
Define Problem
Show importance
Inference
Define Objectives of a
Solution
What would a better artifact
accomplish?
Section 4
Theory
Design & Development
Artifact
Demonstration
How to Knowledge
Find suitable context
Use artifact to solve problem
Metrics,
Analysis Knowledge
Evaluation
Observe how effective,
efficient
Iterative back to design
Communication
Disciplinary Knowledge
Scholarly publications
Professional publications
Figure 1. Research Process (following [8], p. 54)
The evaluation that is demanded not only by [8] but also by
[9] is out of the scope of this paper. Observations concerning
the effectiveness and efficiency of the created artefact can be
fed back into the design process and are left to further research.
III. METHOD ENGINEERING AND GROUNDED THEORY
Since the early 1990s there have been efforts to guide the
development of methods for information systems development
in order to guarantee a high quality of artefacts generated by
them. The task of method engineering is to give this guidance
[10]. Several approaches to method engineering [11; 10; 12]
identify activities, roles, results and techniques as important
elements of methods.
Figure 2 illustrates our understanding of a method and its
engineering process. Method engineering activities that are
conducted by ME roles and supported by ME techniques lead
to ME results, namely methods. The dashed lines show that all
parts of a method (elements and relationships) are a result of
the method engineering process. One example for an ME result
could be the activity ―analyze the company‘s current situation‖
that is supported by the technique ―SWOT analysis‖. The
derivation of elements as well as their configuration rules so far
mostly follow a literature-based and construction-oriented
engineering process [13].
Considering the engineering process of modelling methods,
Siau argues that ―despite the pivotal role of modelling methods
in successful information systems development, most
modelling methods are designed based on common sense and
intuition of the method designers with little or no theoretical
foundation or empirical evidence― [4, p.193]. As far as
theoretical foundations are concerned, we disagree with [4]
view because most of the method engineering literature uses
theories to ground the development of methods. Reference
[14], for instance, combines activity theory and method
engineering as theoretical grounding of the method component
concept, whereas [15] develop a design theory nexus that
connects numerous design theories.
Reference [4]‘s second point, empirical evidence in method
engineering, has to be investigated in more detail since it can
be used for two purposes. It ―includes both empirically based
generation of the method, as well as its justification by using it
in real life projects‖ [16, p.620]. The latter is often included in
method engineering research processes by case studies or
action research that evaluate previously engineered methods
([17; 18]). In contrast, we are focusing the former and argue
that methods can gain empirical evidence ex ante. Therefore,
we need a research procedure which first and foremost
supports the empirical grounding of method elements during
their construction process.
The quality of empirical data used to ground method
elements is crucial for a method‘s quality. For this reason,
relying on one source only is not enough. As a second
requirement, construction of method elements should be based
on multiple sources in order to avoid any biases that might be
introduced by a single source.
Reference [19] differentiates mode 1 knowledge as
―generated in a context of established institutions and
disciplines‖ and mode 2 knowledge as ―generated in a context
of application‖ (p. 91). So far, method engineering is partly
based on mode 1 knowledge. We assume that including
practical experiences by analysing interviews is strongly
relevant for method engineering research. Thus, we argue that
a method for practical application should thirdly consider the
course of action and the experience of its dedicated context.
Hence, an empirical grounded construction of method elements
should be context-oriented.
Summarising the previously explained requirements, we
were looking for research methods that enable an empirical
grounded, multiple sources-based and context-oriented
derivation of method elements. In the following, the
appropriateness of grounded theory [6] will be elaborated in
order to show how it fulfils the requirements stated above.
The concept of grounded theory appeared as „a counter to
the then prevailing practice in social science research of
237
focusing on the testing and verification of existing theories
rather than the generation of new ones― [20, p.5]. According to
[21], grounded theory investigates empirically ―how practice
behaves instead of (…) if practice behaves in a specific way‖
(p. 1). Theories built with grounded theory are empirically
grounded and using it in the field of method engineering will
enrich method construction by increasing empirical evidence of
methods elements ex ante.
A general strength of grounded theory is that it includes
multiple sources of evidence. This is an enrichment for method
engineering because it is often based mainly on literature.
Grounded theory approaches accept a broad variety of data
sources including annotation, internal reports, requirements
engineering specifications, various kinds of manuals, protocols,
videos etc. [21; 22]. For method engineering researchers it
could be helpful to use several sources of the dedicated context,
i.e. process descriptions [23; 24] or observations achieved
through action research techniques etc. [25].
Grounded theory develops context-based theories instead of
universally valid theories [6] and enables method engineering
researchers to investigate the subject of interest in its context
[26]. Reference [27] states that grounded theorising is well
suited for the interpretation of experiences of managers and
developing theoretical propositions from them. Therefore, she
chooses grounded theory procedures to analyse case study
interview transcripts.
*
ME Activity
Although method engineering is not creating descriptive
theories of human behaviour but normative methods to guide it
instead, we argue that the concept of grounded theory is well
adaptable and useful to method engineering. We assume that
descriptive research findings resulting from grounded theory
can be used to support the construction of normative methods
in addition to desk and literature research. Especially if a
certain company is very successful, the elicitation of their as-isprocedure (descriptive) is a solid base for the construction of
the target state of other companies (normative). The
construction of these ―best practice methods‖ should be based
on experiences and knowledge of successful companies.
By using grounded theory, our approach called grounded
method engineering (GME) supports the ME activity
―identifying elements‖ by complementing other ME techniques
such as literature reviews. Grounded theory procedures will be
adapted to method engineering and subsequently support ―ME
activities‖ as depicted in figure 2. With GME, we propose a
symbiosis of method engineering and grounded theory that
enhances the empirical grounding of method elements and
guides the process of engineering a method. GME shall be
established as an addition to conventional method engineering
techniques. Literature reviews and desk research are important
nonetheless.
*
ME Role
Method Engineering
Process
-is done by
-produces
-supports
ME Technique
*
*
ME Result
**
*
*
*
*
*
-is a
* *
Activity
*
*
*
**
-is
*a
-is a
Role
Method
-is a
*
Technique
-supports
*
*
*
*
-is done by
-produces
Result
-is a
*
-is a
-is a
*
Figure 2. Method Engineering Process and Method
238
IV. HOW GROUNDED THEORY CAN SUPPORT METHOD
ENGINEERING
a.
Design and Development of Grounded Method
Engineering
In the following, we investigate concrete grounded theory
techniques in order to utilise them for method engineering.
According to figure 1, this section describes design and
development of grounded method engineering.
Grounded theory techniques are mainly based on the
research of [7]. They extend grounded theory to a more formal
research method including rules, typical activities, techniques,
etc. Earlier research by [6] describes grounded theory as an
unsystematic creative approach. Their research procedure
requires a steady iteration between concept and data. The
different steps of research are mainly supported by three
techniques. Table I sketches these techniques of grounded
theory by [7]. In the following we will discuss how these
techniques can be applied to the field of method engineering.
Table I. Typical GT Techniques (see [20] and [7])
Grounded Theory
Technique
Open Coding
Axial Coding
Selective Coding
Description
Qualitative data is collected,
examined, and put into concepts.
This iterative process is done by
constantly
referring
to
the
substantive area to ‚compare notes‘
and further refine or categorize the
data.
The categories which emerge from
open coding are systematically
related in a causal model to
describe the dynamic relationship
between them using a coding
paradigm
referred
to
as
‚Paradigmatic Model‘. This PM
makes use of the conditions,
contexts, actions, strategy and
consequences to relate identified
categories to each other.
A core category is selected that is
deemed
central.
All
other
categories are integrated and
systematised around the former.
This is the stage where a grounded
theory starts to emerge as a set of
categories that are related to each
other, thus forming theory.
(1) The first step of grounded theory is to open the data for
a free coding [21] and discover concepts from the transcripts.
The corresponding technique named open coding means
breaking down, examining, comparing, conceptualising, and
categorising data. Concepts represent the basic analytic blocks.
They label sections of text (also called ―units of code‖) that
describe or identify certain important aspects of the phenomena
under consideration [7]. Particularly, questions like how, what,
and who are used to break down the text into smaller units.
Because grounded theory does not work with a predefined code
system, first concepts are inspired by the interview texts. In the
open coding process, we continuously compare the original
text and concepts to improve the latter. Finally, categories that
subsume similar concepts emerge, i.e. that, for instance,
synonyms are harmonised and similar concepts are aggregated
to categories. Thus, a certain degree of abstraction is reached
during the open coding already.
In order to identify elements of a method, method
engineering researchers need to discover concepts concerning
their planned method. Concrete examples will be presented in
the following section. The grounded theory technique open
coding can be used for grounded method engineering without
major adjustments.
(2) The second technique is axial coding which formalises a
set of procedures that allows the reformulation of the data
obtained from open coding. Goal of this step is to look for
different meanings in categories and identify connections.
Reference [7] states that categories should be sorted according
to a certain inherent hierarchy. They recommend axial
categories according to the coding paradigm depicted in figure
3 for the classification of categories. Therefore, the identified
categories are grouped to these axial categories. Categories
either describe a phenomenon, its context, its consequences, its
reasons or the strategies to cope with it.
Context
Reason
Phenomenon
Consequence
Strategy
Figure 3. Coding Paradigm by Strauss and Corbin
Turning our back at sociological theories and looking at
method engineering, the coding paradigm has to be adapted to
the particularities of method engineering. In order to apply
grounded theory to the latter, we need an equivalent to the
above paradigm in the field of method engineering. A
sociological theory is represented by several phenomena, their
reasons, specific context etc. having a variety of different
relationships. Since the result of GME is not a theory but a
method, this coding paradigm has to be adapted accordingly. A
method‘s elements (as shown in the lower part of figure 2) thus
can be used as axial categories for method engineering. The
phenomena, reasons, context, consequences and strategies are
replaced by activities, roles, techniques and results. Hence,
figure 4 illustrates the coding paradigm of grounded method
engineering.
239
Activities
Roles
Results
Techniques
Figure 4. Coding Paradigm of Grounded Method Engineering
This a priori definition of certain method elements as a
coding paradigm may be criticised because grounded theory is
generally understood to be an open research method. Thus,
open coding should not be restrained by categories that were
defined in advance. However, axial coding aims to structure
the categories retrieved from open coding.
(3) The third technique is selective coding. Selective coding
models relationships among categories that were classified in
the axial coding phase, i.e., it relates categories to other
categories. Furthermore, these relationships are validated, e.g.
by comparison with existing literature. The relationships
between elements of the coding paradigm, i.e., axial categories,
can support the description of concrete relationships between
identified categories.
Grounded Theory
Context
#Cx1
#Cx2
...
Reason
#R1
#R2
#R3
...
Phenomenon
#P1
#P2
...
Consequence
#Co1
#Co2
#Co3
...
Strategy
#S1
#S2
...
Grounded Method Engineering
Activity
#A1
#A2
#A3
...
Figure 5 shows a schematic result of axial coding.
Generally, the categories identified during the open coding
process are assigned to the axial categories shown in figure 3.
In the case of GME, categories are classified as activities,
results, techniques and roles (axial categories of GME). It is
important to acknowledge that this is only one plausible coding
paradigm for method engineering. Depending on the
underlying method engineering approach, further axial
categories, i.e. elements, could be added to this paradigm.
Reference [12], for instance, includes ―reason‖; [10] uses
―principle‖ in his approach. Hence, the four axial categories
depicted in figure 4 would have to be complemented by one or
more additional axial categories. Before using GME, the
underlying method engineering approach has to be outlined to
adjust the coding paradigm, respectively. The elements shown
in figure 4 are the coding paradigm of grounded method
engineering based on the method engineering approach by
[28].
Role
#Ro1
#Ro2
...
Result
#Re1
#Re2
...
Technique
#T1
#T2
...
Figure 5. Axial Coding in GT and GME
In case of grounded method engineering, the identified and
classified categories (concrete method elements) have to be
arranged and related to each other. A concrete activity, for
instance, is assigned to one or more actual results. The same
way, one or more techniques that can be used to generate
results are determined and related to the latter. Roles are linked
to activities, respectively. As shown above, axial coding was
used to group categories to axial categories. Now, insights
from the open coding phase are used to generate relationships.
In the selective coding phase, usually a core category that is
deemed central is selected. All other categories are integrated
and systematised around this central category. We assume that
for method engineering all categories are of equal importance.
Hence, we do not specify a core category.
Instead, our approach includes a core axial category. We
argue that methods are generally process-oriented and the
sequence of activities plays a significant role. Therefore, the
axial category ―activity‖ will be deemed a core axial category.
―Activity‖ should be used as core axial category because all
method elements are bound to activities in one way or another.
Subsequently, all identified concrete activities have to be
arranged in a sequence using, for instance, an event-driven
chain. Only after this is done, other categories (such as
concrete roles and techniques) are assigned and related to these
activities. A schematic result of the selective coding phase is
illustrated in figure 6. In contrast to general GT approaches, the
categories #A1, #A2 and #A3 are arranged in a sequence in the
case of GME.
All activities identified during the axial coding phase are
considered to be central and all other categories should be
arranged around them. Modelling activities in a certain
sequence is also useful for the illustration of methods as an
240
event-driven chain. The relationships between activities are not
the only ones though. Relationships between other (axial)
categories have to be considered as well. Roles, techniques and
results are commonly linked in more or less complex ways to
one another.
Grounded Theory
#Cx1
#R1
#Cx2
#R2
#P1
#Co1
#R3
#Co3
#Co2
#P2
#S2
#S1
Grounded Method Engineering
#A1
#T1
#Ro1
#Re1
#A2
#T2
#Ro2
#Re2
#A3
Figure 6. Selective Coding in GT and GME
b.
Demonstration and Exemplary Application in the Field of
IT Governance
The exemplary application – or so-called demonstration in
figure 1 – presented in the following is taken from the field of
IT governance. The importance of this topic has increased
during the last decade since IT infrastructures are becoming
ever more complex. Best practice reference models (BPRM)
promise support for manifold challenges IT departments are
confronted with [29; 30]. Therefore, the interest in these best
practice reference models is growing, and more and more
companies apply BPRM to support their IT governance.
However, there is limited knowledge about how BPRM are
applied in practice and there is no structured method to support
the application and lift the full potential of BPRM. The
challenge of creating such a method by using GME is
described in this section.
Following our GME approach, we base our method
engineering process on interviews out of the dedicated context.
These interviews are taken from a qualitative study on the ―use
of multiple reference models of IT governance‖ which focuses
on how enterprises deal with a variety of BPRM (such as
COBIT or ITIL) applied simultaneously in an organisation.
The interviewees are skilled experts whose long-time
experience accounts for their knowledge on the research topic.
Twelve interviews lasting several hours have been carried out.
The interview transcripts are the starting point for GME. Table
II shows examples of interview excerpts referencing the
research topic.
Table II. Interview Excerpts
Interview excerpts
„|The management| is a frequent trigger| for the use of best
practice models|. Being an |internal client|, it puts pressure
on the |IT department.”
“The first step of our consulting process is |position fixing|.
The question is which problem the client has and which
projects fail more often than others. Then we look in the
frameworks and standards and look for gaps and
solutions.”
“By using a |structured SWOT assessment| we analyse the
strengths and weaknesses of the clients‟ processes|. An
outcome of this step is a catalogue of recommendations|.”
“Management look for possibilities to improve their |IT
departments| During this search they often find several
frameworks and standards. And they want only the best
parts of all them.“
“A team discusses what is the best for our purpose,| they
derive requirements| and collect policies and so on.
|Outcome of this process is a big excel sheet.|“
“If there is a problem with a process| the models are used
to improve it.| The models are a supporting tool for Process
Improvement|.”
“Process owners use the frameworks as a blueprint for our
|IT processes.”
…
Step 1: Discovering Concepts with Open Coding
By using the grounded theory technique open coding, we
analyse all interview parts that deal with the application of
BPRM. The bars in table II separate the text into different units
of code that have to be conceptualised.
Coding without limitations is an important principle of
open coding. This could be a problem if the investigator
already has method elements in mind while coding the
concepts. Such a preoccupation can be avoided by leaving the
coding to researchers that are not involved in the actual method
engineering process. Moreover, a stringent use of questions
like ―how‖, ―what‖ and ―who‖ allows for an unrestricted open
coding because the focus is not yet on method elements.
Concepts that emerged from the units of code taken from
the interview transcripts can be categorised, e.g. the concepts
241
―position fixing‖ and ―structured assessment of strengths and
weaknesses‖ can be aggregated to the category ―analyse
current situation‖. Accordingly, all other concepts are
categorised. While analysing the interview excerpts in this
open coding phase, we came to 14 categories. Two of these
categories and respective concepts are exemplarily illustrated
in table III.
Table III. Result of Open Coding
Category
Analyse current
situation
Design Process
…
Concepts
Position
Fixing;
Structured
Assessment
of
Strengths
and
Weaknesses
Process
Improvement,
Process
Redesign, Process Design
…
Step 2: Structuring Categories along Method Elements
with Axial Coding
This technique aims to structure the extracted categories
with regard to the coding paradigm illustrated in figure 4
including the method elements activity, result, role, and
technique.
In order to classify categories according to the coding
paradigm illustrated in figure 3, [7] recommend a detailed
semantic analysis. This includes, for instance, an a priori
definition of signal words that hint at reasons (like ―because‖,
―therefore‖, etc.). If one of these words appears in the text, the
unit of code is likely to be a concept belonging to the axial
category ―reason‖. In our case, whenever a verb occurred in the
text, we investigated if there was an activity related to it.
Hence, the category ―analyse current situation‖, for instance,
emerged from units of code such as ―we analyse the strengths
and weaknesses of the clients‘ process‖ (see table II and III).
Phrases like ―by using‖ or ―applying‖ strongly hint at
techniques. Consequently, the interview quote ―by using a
structured SWOT analysis‖ that can be found in table II led to
the category ―SWOT analysis‖ that is associated with the axial
category technique. Table IV shows a structured list of axial
categories and respective categories as a result of axial coding.
Table IV. Categories Sorted by Method Elements used as Axial Categories
Method
Element
(Axial Category)
Activity
Result
Role
Technique
Category
Step 3: Relating Method Elements by Selective Coding
In the selective coding phase, the identified categories
(concrete method elements such as SWOT analysis) are
related to one another in order to support method engineering.
Therefore, transcripts of interviews are analysed once again to
identify relations between categories. The relations between
axial categories, i.e. between the method elements, used in
GME (figure 4) can support the arrangement of categories
conducted in the selective coding phase. Concrete results are
assigned to activities, techniques to actual results, etc.
In our case depicted in figure 7, the management triggers
the activity ―analyse current situation‖. Results such as ―IT
process model‖ and ―BPRM‖ are necessary inputs for this
activity. Utilized techniques are a GAP analysis, a SWOT
analysis as well as various spreadsheets. The selection of
BPRM subsets is supported by a group discussion. For the
design of processes by the process owner no technique could
be identified in the interview transcripts.
The next step is to find a reasonable sequence for the
identified activities. Since the interview transcripts comprise
only little evidence as far as a sequence is concerned, arranging
the activities in a sensible way poses a major problem. Some
parts of the text indicate that ―analyse current situation‖ should
be the initial activity which seems to be obvious at first sight.
However, some interviews suggest that this activity could be
carried out (again) after ―design process‖. This clearly shows
that – due to insufficient or contradictory evidence gained from
empirical data – some relationships (like the sequence of
activities) have to be modelled with a degree of uncertainty. It
is thus important to keep these flaws in mind and collect
additional data to underpin these relationships. Although the
arrangement is preliminary, other relationships (e.g. between
roles and techniques) can be modelled independently so that a
later re-arrangement of activities will not affect other parts of
the model.
Following steps one to three, a method as partly depicted in
figure 7 can be configured. After conducting these steps once,
the resulting method is likely to be preliminary. Grounded
method engineering is an iterative approach and advises to
move back and forth between collecting and analysing data.
This improves methods in two ways. On the one hand,
concepts, categories and their relationships can be confirmed
by collecting more empirical evidence. On the other hand, new
concepts and categories might occur and enable a refinement.
Moreover, assignments to axial categories might be redefined
or relationships might change.
Analyse Current Situation,
Select Subset, Design Process
BPRM, IT Process Model;
BPRM Subset
Management; Process Owner;
IT Department, Consultant
Spreadsheets, GAP Analysis,
SWOT
Analysis,
Group
Discussion
242
Management
triggers
IT Process
Model
Consultant
supports
Role
Input for
Analyse
current
situation
supports
Input for
BPRM
GAP
Analysis
supports
yields/support
Input for
provide data
SWOTAnalysis
Spreadsheets
Technique
Result
responsible for
Select subset
IT Department
BPRM
Subset
Group
Discussion
Activity
Input for
supports
Input for/yields
IT Process
Model
Process Owner
supports
yields
Design
process
responsible for
Figure 7. Result of Selective Coding
It is important to adhere to the principle of openness at that
point and not to stick to once made definitions. In our concrete
example, we observed the following: After an initial round of
interviews, we assumed that techniques support results (see
figure 4) which is quite plausible considering related literature
on method engineering. In later interviews, an increasing
number of interviewees talked about using techniques for
certain activities. Therefore, relationships of (axial) categories
might have to be changed if further data confirms this.
Furthermore, new categories (such as the technique
―workshop‖) that have not been mentioned earlier might appear
and complement the pool of identified categories. Thus, every
additional iteration contributes to the completeness and
reliability of methods and further research will certainly
improve the method exemplarily presented herein. Particularly,
relationships will be uncovered enabling the method engineer
to use illustrations such as event-driven chains.

CONCLUSION, LIMITATIONS AND FUTURE RESEARCH
In order to proof rigour in design science in general and in
method engineering in particular, many scientists demand an
ex post evaluation of research results. That means that methods
are tested after their development. Our approach to add rigour
to method engineering already begins in the construction
process of methods by grounding method elements in empirical
data. As shown in this paper, GME enriches current research
practices in the field of method engineering. We argue that
grounding method elements in empirical data is a useful
addition to literature-based research and construction-oriented
method engineering. Hence, it should complement research
methods like literature reviews and case studies. GME is an
opportunity to transfer domain knowledge to methods and
bridge the gap between methods and their dedicated context.
Furthermore, our research provides concrete steps that can
be performed in a method engineering process. These steps
have been inspired by grounded theory and are adapted for
method engineering purposes. By following these steps,
constituting parts of methods, i.e. activities, roles, techniques
and results can be extracted from multiple sources of evidence
such as interviews and project documentation. The methods
(and their elements) created by the subsequent engineering
process are properly grounded in domain knowledge. Thus,
they are able to specifically support method engineering in the
respective context.
A limitation to our results is that grounded theory is usually
used to reach ―insights in human behaviour‖. GME aims to
guide human and organisational behaviour instead. However,
we argue that these insights gained by grounded theory
techniques can be used to extract domain knowledge and thus
support method engineering. The example showed that after
acquiring knowledge about the application of BPRM from
experts, this knowledge could be used to engineer a method
guiding the application of BPRM in other companies.
Another limitation is that our results are solely based on
interviews. The quality thus depends heavily on the expertise
of the interviewees. Therefore, additional sources like internal
documents (e.g. company policies) should be analysed as well.
243
REFERENCES
(1) C.H. Lee, J.H. Lee, J.S. Park, K.Y. Jeong, "A study of the causal
relationship between IT governance inhibitors and its success in
Korea enterprises‖ HICSS 2008 - Proceedings of the 41st Annual
Hawaii International Conference on System Sciences.
(2) M. Rosemann, I. Vessey "Toward Improving the Relevance of IS
Research to Practice: The Role of Applicability Checks‖ MIS
Quarterly 32(1), 2008, pp.1-22.
(3) S. Hoppenbrouwers, H. Proper, T. van der Weide "A
Fundamental View on the Process of Conceptual Modeling‖
Proceedings of the Conceptual Modeling - ER 2005. 24th
International Conference on Conceptual Modeling, Klagenfurt,
Austria, October 24-28. Berlin Heidelberg: Springer-Verlag
GmbH, 2005, pp.128-143.
(4) K. Siau, "Information Modeling and Method Engineering‖
Valenti S, (eds). Successful Software Reengineering: IRM Press,
2002, pp.193-209.
(5) M. Markus, "The Qualitative Difference in Information Systems
Research and Practice‖. Lee AS, Liebenau J, Decross JI, (eds).
Proceedings of the IFIP TC8 WG 8.2. London: Chapman & Hall,
1997, pp.11-27.
(6) A. Glaser, A. Strauss "The Discovery of Grounded Theory:
Aldine de Gruyter, New York, USA, 1967.
(7) A. Strauss, J. Corbin "Basics of qualitative research: Grounded
theory procedures and techniques‖, Sage Publications Inc.,
Thousand Oaks, CA, US 1990.
(8) K. Peffers, M. Rothenberger, S. Chatterjee "A Design Science
Research Methodology for Information Systems Research‖
Journal of Management Information Systems 24(3), 2007/2008,
pp.45-77.
(9) A. Hevner, S. March, J. Park, R. Sudha "Design science in
information systems research,‖ MIS Quarterly 28(1), 2004,
pp.75-106.
(10) S. Brinkkemper "Method engineering: engineering of
information systems development methods and tools,‖
Information & Software Technology 38(4), 1996, pp.275-80.
(11) T. Gutzwiller "Das CC-RIM-Referenzmodell für den Entwurf
von
betrieblichen,
transaktionsorientierten
Informationssystemen,‖ Physica, Heidelberg, 1994.
(12) F. Karlsson "Meta-Method for Method Configuration - A
Rational Unified Process Case‖ [Dissertation]: Linköping
University, Faculty of Arts and Sciences, Linköping 2002.
(13) R. Hurrion "A Sequential Method for the Development of Visual
Interactive Meta-Simulation Models Using Neural Networks,‖
The Journal of the Operational Research Society 51(6), 2000,
pp.712-719.
(14) F. Karlsson, K. Wistrand "Combining method engineering with
activity theory: theoretical grounding of the method component
concept.,‖ European Journal of Information Systems 15(1), 2006,
pp.82—90.
(15) J. Pries-Heje, R. Baskerville "The Design Theory Nexus,‖ MIS
Quarterly 32(4), 2008, pp.731-55.
(16) F. Karlsson, P. Agerfalk "Method Configuration - Adapting to
Situational Characteristics while Creating Reusable Assets,‖.
Information & Software Technology 46(9), 2004, pp.619-33.
(17) M. Rossi, B. Ramesh, K. Lyytinen, J.-P. Tolvanen "Managing
Evolutionary Method Engineering by Method Rationale,‖
Journal of the Association for Information Systems 5(9), 2004,
pp.356-391.
(18) M. Leppänen "An Ontological Framework and a Methodical
Skeleton for Method Engineering: A Contextual Approach,‖
Jyväskylä 2005.
(19) D. Partington "Building Grounded Theories of Management
Action,‖. British Journal of Management 11, 2000, pp.91-102.
(20) G. Galal "From contexts to constructs: the use of grounded
theory in operationalising contingent process models,‖ European
Journal of Information Systems 10(1), 2001, pp.2-14.
(21) B. Hansen Hansen, K. Kautz "Grounded Theory Applied Studying Information Systems Development Methodologies in
Practice,‖: Proceedings HICSS 2005., pp.264f.
(22) B. Lings, B. Lundell "On the adaptationof Grounded Theory
procedures: insights from the evolution of the 2G method,‖
Information Technology and People 18(3), 2005, pp.196—211.
(23) J.C. Hood, ―The Sage Handbook of Grounded Theory,‖
Thousand Oaks, CA, US: Sage 2007.
(24) K. Charmaz "Constructing grounded theory: A practical guide
through qualitative analysis,‖ Sage, London 2006.
(25) D. Avison, F. Lau, M. Myers, P. Nielsen "Action Research‖.
Communications of the ACM 42(1), 1999, pp.94-107.
(26) J. Hughes, S. Jones "Reflections on the use of Grounded Theory
in Interpretive Information Systems Research,‖ Electronic
Journal of Information Systems Evaluation 6(1), 2003, pp.61-71.
(27) K. Eisenhardt "Building Theories from Case Study Research,‖.
Academy of Management Review 14(4), 1989, pp.532-550.
(28) R. Debreceny, G. Gray "IT Governance and Process Maturity: A
Field Study‖ HICSS 2009 - Proceedings of the 42th Hawaii
International Conference on System Sciences, Washington, DC,
USA: IEEE Computer Society 2009.
(29) M. Larsen, M. Pedersen, K. Andersen "IT governance: reviewing
17 IT governance tools and analyzing the case of Novozymes
A/S‖ HICSS 2006: Proceedings of the 39th Annual Hawaii
International Conference on System Sciences. Washington, DC,
USA: IEEE Computer Society, 2006.
244
Zwischenfazit Teil E
Die aufgezeigten Schwächen der konzeptionellen Methoden-Konstruktion waren die
Grundlage für die Entwicklung des Grounded-Method-Engineering-Ansatzes. Dieser in
Fachbeitrag 8 präsentierte Ansatz ist eine mögliche forschungsmethodische Erweiterung
des etablierten Methoden-Engineerings. Inhaltliches Ziel ist es, die Ergebnisse des
Konstruktionsprozesses zu verbessern und die entwickelten Methoden durch
systematische Beteiligung von Anwendern stärker am späteren Anwendungskontext
auszurichten.
Dieser Beitrag ist Bestandteil weiterer Forschung und wird gegenwärtig in der
Forschungsgruppe weiterentwickelt. Ein Diskussions- und Ansatzpunkt der aktuellen
Weiterentwicklung ist die Frage, wie aus den Ergebnissen einer qualitativ-deskriptiven
Erhebung normative Empfehlungen in Form einer Methode abgeleitet werden können.
In zukünftigen Veröffentlichungen zum Thema GME wird stärker betont, dass die
Anwendbarkeit von GME auf Best-Practice-Methoden beschränkt ist. Die Entwicklung
von normativen Empfehlungen auf der Basis von Beschreibungen der Ist-Situation
besonders erfolgreicher Unternehmen erscheint im Sinne eines Best-Practice-Ansatzes
plausibel. Ebenfalls werden Aspekte der konsensorientierten Referenzmodellierung
verwendet um die Argumentation an dieser Stelle zu stärken.340
Neben diesen inhaltlichen Ergänzungen zur Methodenkonstruktion leistet der
Fachbeitrag auch einen Beitrag zur „rigor vs. relevance―-Diskussion der
gestaltungsorientierten Wirtschaftsinformatik. Hier wird verstärkt gefordert die erzielten
konstruktionsorientierten Forschungsergebnisse zu evaluieren und/oder ihren
Erstellungsprozess
zu
verbessern.
Die
Ergänzung
der
konzeptionellen
Methodenkonstruktion um eine empirische Komponente adressiert den
Konstruktionsprozess der Methode und leistet einen Beitrag ihn zu verbessern.
340
Siehe Teil A der vorliegenden Dissertation.
245
Teil F: Anwendung von BPRM in einer Multi-ModellUmgebung
Vorbemerkungen Teil F
Wie bereits in Teil C angesprochen, ist der Einsatz von mehreren BPRM der ITGovernance eine zentrale Problemstellung in der Praxis. Diese Erkenntnis lässt sich
sowohl in der Literatur als auch in der durchgeführten qualitativen Studie belegen. Ist es
nun das Ziel die Anwendung von BPRM in der Praxis zu unterstützen, sollte daher auch
der Multi-Modell-Fall thematisiert werden. Hierfür ist es zunächst notwendig, ein
theoretisches Verständnis der Multi-Modell-Umgebung (MMU) zu etablieren.
Metamodellvergleich
Fachbeitrag 9
Fachbeitrag 10
Abbildung 62: Darstellung Teil F: Anwendung von BPRM in einer Multi-Modell-Umgebung
Wie in Abbildung 62 deutlich wird, sind die im Teilbereich Anwendung gewonnen
Erkenntnisse die Grundlage für eine Erweiterung der in Fachbeitrag 6 vorgestellten
Methode auf den Multi-Modell-Fall. Fachbeitrag 9 zeigt zunächst theoretische
Erkenntnisse bezüglich der Multi-Modell-Umgebung. In Kombination mit den
bisherigen theoretischen Erkenntnisse und den aus der qualitativen Studie gewonnenen
praktischen Einsichten, bildet Fachbeitrag 9 so die Basis für Fachbeitrag 10.
246
Fachbeitrag 9:
Konzeptionelle Metamodelle von IT-Governance Referenzmodellen als Basis der
Kombination und Integration in einer Multi-Modell-Umgebung.
Titel: Konzeptionelle Metamodelle von IT-Governance Referenzmodellen als Basis der
Kombination und Integration in einer Multi-Modell-Umgebung
Veröffentlicht in: Tagungsband der 9. Internationalen Tagung Wirtschaftsinformatik
Wien: Business Services: Konzepte, Technologien, Anwendungen, 2009, Band 1, Wien,
25.-27.02.2009.
247
KONZEPTIONELLE METAMODELLE VON
IT-GOVERNANCE-REFERENZMODELLEN
ALS BASIS DER KOMBINATION UND
INTEGRATION IN EINER MULTIMODELL-UMGEBUNG
Stefanie Alter, Matthias Goeken
Kurzfassung
In jüngster Zeit steht zur methodischen Unterstützung der Aufgaben der
Unternehmens-IT eine stetig wachsende Anzahl von Referenzmodellen zur
Verfügung. Aus verschiedenen Gründen können diese Referenzmodelle
immer seltener isoliert voneinander betrachtet und eingesetzt werden.
Vielmehr wird es für die IT-Abteilungen zu einer Herausforderung, das
Zusammenspiel in einer „Multi-Modell-Umgebung― [29] aktiv zu gestalten,
um mit dieser Heterogenität umzugehen, bspw. weil die Modelle in Teilen
redundante Anwendungsbereiche haben, Unterschiede hinsichtlich der
zugrundeliegenden Sprachwelten aufweisen und auf verschiedenen
Prinzipien beruhen. In der Praxis sind Vorschläge entwickelt worden,
Modelle direkt ineinander abzubilden („Mapping―). Dieser Ansatz weist
jedoch verschiedene Probleme auf. Als eine weitergehende und methodisch
fundierte Art, mit den genannten Herausforderungen umzugehen, wird die
Metamodellierung angesehen, durch die die genannten Modelle auch auf
Ebene ihrer Komponenten und Strukturen analysiert, verglichen und
integriert werden können.
1 Einführung
Für Betrieb und Entwicklung von Anwendungssystemen bzw. ITInfrastruktur sowie die damit zusammenhängenden Steuerungs- und
248
Kontrollaufgaben sind gegenwärtig mannigfaltige Referenzmodelle, BestPractice-Modelle und Standards verfügbar (im Folgenden einheitlich
„Referenzmodell“1): Für die IT-Infrastruktur sind insbesondere die IT
Infrastructure Library (ITIL) bzw. ISO 20000 für das Servicemanagement,
die Control Objectives for Information and related Technology (COBIT) für
IT-Governance (i. e. S.) und Audits sowie die verschiedenen
Sicherheitsstandards (ISO 17799 bzw. 2700x sowie BSI-Grundschutz)
maßgeblich. Hinzu kommen u. a. Modelle für Entwicklung (CMMI) und
Projektmanagement (PRINCE 2 und PMBOK) [15].
In der Regel kommen in Unternehmen mehrere Referenzmodelle zum Teil
oder vollständig nebeneinander zum Einsatz, um für die verschiedenen
Anwendungsbereiche jeweils spezifische methodische Unterstützung zu
erhalten. Da die Modelle jedoch zunehmend thematisch-inhaltliche
Überlappungen aufweisen, wird die parallele, aber kontrolliert-kombinierte
Anwendung dieser Referenzmodelle zunehmend wichtiger, damit sie eine
gemeinsame Steuerungswirkung entfalten können und sich nicht
unterschiedliche, nicht kompatible Sprachwelten entwickeln. Daher wird die
Integration oder Kombination der Modelle zu ganzheitlichen
Referenzmodellen vermehrt gefordert [13,18].
In Literatur und Praxis gibt es eine Reihe von Ansätzen und Initiativen, mit
dieser Modellvielfalt umzugehen [vgl. 15, S. 205 ff. und die dort
angegebenen Quellen], was die hohe praktische Relevanz offenbart. Die
Ansätze und Initiativen reichen von merkmalsbasierten Vergleichen, die den
Gegenstandsbereich der Referenzmodelle charakterisieren und abgrenzen,
bis hin zu umfangreichen „Mappings“, in denen jeweils angegeben ist,
welche Bestandteile und Komponenten verschiedener Referenzmodelle
miteinander korrespondieren bzw. sich ergänzen [11] Insbesondere in den
„Mappings“ werden jeweils nur Teile und ausgewählte Komponenten der
Modelle in die Betrachtung einbezogen. Gleichzeitig ergibt sich dabei eine
enorme Detailtiefe, da die Betrachtung auf Ebene der Modelle selbst erfolgt.
Ein Vergleich der den Modellen zugrundeliegenden Strukturen findet in der
Regel nicht statt.
Für diesen Beitrag sind auch solche Referenzmodelle von Bedeutung, die nicht der ITGovernance i. e. S. zugeordnet werden. In Anlehnung an [15, S. 21 ff. sowie die dort
angegebene Literatur] werden jedoch auch solche Modelle als „IT-GovernanceReferenzmodelle“ bezeichnet, die außer Strukturen auch Prozesse und Techniken zur
methodischen Unterstützung der genannten Aufgaben der Unternehmens-IT beschreiben.
1
249
Nach Ansicht der Verfasser fehlt eine methodische Fundierung für einen
systematischen und abstrakten Vergleich sowie die Integration und
Kombination der unterschiedlichen Modelle. Aus diesem Grund wird hier
versucht, einen weitergehenden und ergänzenden Beitrag für den Umgang
mit der Modellvielfalt zu leisten. Dieser stützt sich auf Metamodelle, die
sich in anderen Bereichen der Wirtschaftsinformatik als hilfreich erwiesen
haben, um die höhere Abstraktionsebene für einen Vergleich oder für die
Integration zu nutzen [6, 32]. Sie erlauben aufgrund des abstrakteren
Herangehens die Vernachlässigung von Details bei gleichzeitig
ganzheitlicherer Sicht auf mehr oder alle relevanten Modellkomponenten. In
Abschnitt 3 wird daher die Entwicklung eines Metamodells eines BestPractice-Referenzmodells beschrieben.
In Anlehnung an Ansätze aus dem Bereich der Schemaintegration von
Datenbanken können - in einem weiteren Schritt - Korrespondenzen
zwischen Metamodellkomponenten festgestellt werden, womit sich die
Integration der konzeptionellen Metamodelle weitergehend unterstützen
lässt. Zuvor erfolgt eine Beschreibung der „Multi-Modell-Umgebung“ in der
IT-Governance (Abschnitt 2). Schlussfolgerungen sowie ein Ausblick auf
weitere Forschungsarbeiten in Abschnitt 5 schließen diese Arbeit ab.
2 IT Governance: Eine Multi-Modell-Umgebung
Die verfügbaren Referenzmodelle entsprechen unterschiedlichen
Perspektiven auf die Unternehmens-IT. So wird beispielsweise COBIT [10]
von Wirtschaftsprüfern und Auditoren bevorzugt, während im Bereich
Systementwicklung CMMI [26] Verwendung findet. Der IT-Betrieb
wiederum hat seine Prozesse vielfach an ITIL [24] oder ISO 20000
ausgerichtet [19]. Die verschiedenen verwendeten Referenzmodelle stellen
somit eine sogenannte „Multi-Modell-Umgebung“ dar [29]. Die Gründe für
die Entwicklung dieser Multi-Modell-Umgebung, die daraus resultierenden
Herausforderungen sowie mögliche Lösungsansätze werden in diesem
Abschnitt vorgestellt.
Es ist vermehrt zu beobachten, dass der Gegenstandsbereich der
Referenzmodelle wächst [13, 19], da die jeweils neuen Versionen der
Referenzmodelle im Vergleich zu ihren Vorgängern zumeist größere
fachliche Bereiche abdecken. Beispielhaft sei hier die Veränderung von ITIL
250
V2 zu ITIL V3 genannt: Während ITIL V2 sich primär auf Prozesse
fokussierte, beschäftigt sich ITIL V3 zusätzlich mit Strategie (Service
Strategy) und Optimierung (Continual Service Improvement). V3 nimmt
darüber hinaus stärker als V2 die Integration der IT in das Business in den
Fokus (Alignment) [23, 24]. Ähnliche Entwicklungen lassen sich bei CMMI
und COBIT beobachten. Durch die Ausdehnung der Modelle ergeben sich so
vermehrt Schnittmengen und Redundanzen bei Anwendung von vormals
tendenziell spezialisierten und überschneidungsfreien Modellen.
Ein weiterer Grund ist die Integration von Funktionsbereichen.
Unternehmensbereiche wie beispielsweise die Entwicklung sind angehalten,
mit anderen Unternehmensbereichen zusammenzuarbeiten. Durch
abteilungsübergreifende Projekte müssen sich Mitarbeiter mit
unterschiedlichen Referenzmodellen auseinandersetzen, den verschiedenen
Modellen jeweils die relevanten Teile entnehmen und diese ad hoc
kombinieren.
Abbildung 1 zeigt die Multi-Modell-Umgebung aus dem Blickwinkel eines
Prozessverbesserungsprojektes im IT-Bereich. Zur Realisation des Projektes
werden Kenntnisse sowohl in domänen-spezifischen als auch in domänenneutralen Modellen benötigt. Diese Modelle lassen sich zusätzlich in die
Bereiche Governance und Organisationale Infrastruktur bzw. Bereitschaft
einteilen. Solche übergreifenden Projekte sind ein weiterer Grund für das
Entstehen einer Multi-Modell-Umgebung.
Domänen neutral
Organisationale
Infrastruktur und
Bereitschaft
(einschließlich
Geschäftspraktiken,
Entwicklungsmethoden sowie
Veränderungs- und
Verbesserungsmethoden)
EFQM
Lean
Six Sigma
COBIT
SOX
ISO 9000
CMMI
PRINCE 2
P-CMM
ISO 12207
IT-Grundschutz
SCOR
ITIL
SWEBOK
Steigende Entscheidungsautorität der Verwendergruppe
Governance
(einschließlich externer
Bestimmungen und
Regulationen sowie intern
beschlossener
Governance)
Domänen spezifisch
Steigende Entscheidungsautorität der Verwendergruppe
Abbildung 1 Multi Model Umgebung (In enger Anlehnung an [29])
251
Weiterhin können verschiedene Stakeholder des Unternehmens Promotoren
oder Gegner einzelner Referenzmodelle sein, sodass deren Auswahl nicht
immer streng ökonomisch und sachlich begründet verlaufen muss. Hiermit
verwandt sind regulatorische Anforderungen (Compliance), welche
Empfehlungen oder Verpflichtungen aussprechen, durch die die
Verwendung von bestimmten, unterschiedlichen Modellen obligatorisch
werden kann.
Aus den genannten Gründen resultiert, dass sich die methodische
Unterstützung durch Referenzmodelle als eine „Multi-Modell-Umgebung“
darstellt, woraus sich Unternehmen vor diverse Herausforderungen gestellt
sehen. Bspw. führt die Verwendung von unterschiedlichen
Referenzmodellen dazu, dass getrennte Sprachwelten entstehen.2 Außerdem
können die Anforderungen der verschiedenen Referenzmodelle an denselben
Prozess kollidieren, indem unterschiedliche Schwerpunkte gesetzt oder
Philosophien
vertreten
werden.
Auch
die
Vorschläge
zur
Prozessausgestaltung können sich hinsichtlich der verantwortlichen Rollen
und deren Aufgaben bzw. Rechte und Pflichten unterscheiden. Nennenswert
sind außerdem die Anforderungen hinsichtlich der Compliance bei
länderübergreifend agierenden Unternehmen. Diese und weitere
Herausforderungen führen in den Unternehmen etwa zu Doppelarbeit,
Mehrfachdokumentation oder auch redundanter Prozessmodellierung. Im
Ergebnis erhöht der parallele Einsatz verschiedener Referenzmodelle so die
Komplexität, und sie können keine gemeinsame Steuerungswirkung
entfalten.
Die Kombination oder Integration von Modellen kann eine Möglichkeit sein,
den Herausforderungen der Multi-Modell-Umgebung zu begegnen.
Praxisgeleitet gibt es – wie erwähnt – gegenwärtig mehrere Initiativen mit
dem Ziel, die Referenzmodelle auf Ebene der Modelle aufeinander zu
„mappen“, d. h. am Beispiel COBIT etwa auf Ebene der konkreten Control
Objectives [siehe 15, S. 205 ff]. Ergebnis einer bereits abgeschlossenen
Mapping-Initiative ist das ITIL-COBIT-Mapping des itSMF und der ISACA
Besonders deutlich wird dies im Umfeld von COBIT [10, 11, 12] und CMMI [18, 26]. Ein
Prozess und seine Ziele werden etwa im COBIT-Referenzmodell mit den Begriffen Process
und Control Objective bezeichnet, während CMMI sie als Process Area und Specific Goal
bzw. Specific Practice benennt. Ein COBIT Control Objective findet im CMMI keine
exakte Entsprechung, kann aber im Umfeld der Begriffe Specific Goal und Specific Practice
eingeordnet werden (siehe auch Abschnitt 4).
2
252
[14], welches Gemeinsamkeiten und Unterschiede verschiedener
Modellkomponenten herausarbeitet. Aus der hierbei vorzufindenden
Detailtiefe resultiert ein zum Teil schwer handhabbarer Umfang, bei [14]
bspw. rd. 400 Seiten Mappingtabellen. Für die wissenschaftlich fundierte
und stabile Integration ist es jedoch nach Auffassung der Autoren ratsam, die
Referenzmodelle auch auf einer höheren Abstraktionsebene – der
Metamodellebene – zu vergleichen, um so mögliche Ansatzpunkte für eine
stabilere und handhabbarere Integration und Kombination herauszuarbeiten.
3 Konzeptionelle Metamodelle von IT-GovernanceReferenzmodellen
Der folgende Abschnitt beschäftigt sich mit konzeptionellen Metamodellen
von IT-Governance-Referenzmodellen. In der Wirtschaftsinformatik werden
Modelle genutzt, um von der Realität zu abstrahieren. Sind nun wiederum
Modelle und nicht die reale Welt Gegenstand der Modellbildung, so werden
Modelle von Modellen erstellt, welche als Metamodelle bezeichnet werden
[32]. Da Metamodelle Modelle von Modellen sind, können zur
Unterstützung Erkenntnisse aus der konzeptionellen Modellierung
herangezogen werden.
In Anlehnung an die Arbeiten von Becker, Schütte et al. [3, 27, 28] wird im
folgenden Abschnitt der Erstellungsprozess von Metamodellen betrachtet.
Abbildung 2 zeigt ein Metamodell des COBIT-Referenzmodells, anhand
dessen die Entwicklung beispielhaft erläutert wird. Dieses Modell wird in
Abschnitt 4 zur Illustration des Kombinations- und Integrationsprozesses
verwendet (Zu einer genaueren Herleitung vergleiche [7, 8, 9]).
In der Wirtschaftsinformatik ist die Tendenz zu erkennen, die
Modellierungssprache zu fokussieren und deren Entwicklung zu forcieren
[20, 21, 22, 32], während die Fragen des Vorgehens während des
Modellierens weitgehend vernachlässigt werden. [33] bringen dies zum
Ausdruck indem sie kritisieren, dass zwar der “way of modelling” bearbeitet
wird, der “way of working” jedoch weitaus geringere Beachtung seitens der
Wissenschaft erfährt. [21] bemerkt: „Recently, several software researchers
and research groups have been proposing meta conceptual models. Although
important results have been achieved, not much attention has been directed
253
to the problem of filling the models, that is, instantiating the model with
knowledge. Very little work has attacked the problem of bridging the gap
from the real world to the conceptual model.” Die erste grundlegende Frage
ist daher: Wie kommt der Modellierer zum (Meta-) Modell? Oder anders:
Wie kann das Wissen über das zu modellierende Objekt erlangt werden, das
in das (Meta-)Modell eingehen soll?
Role
(1,*)
is
assigned
to
(1,*)
Control
Objective
Activity
(1,*)
(1,1)
(1,*)
Control Practice
(1,*)
(0,*)
Input
is
contained
in
uses /
needs
(1,1)
IT-Resource
Output
is
contained
in
is
contained
in
isa
(1,*)
(1,4)
Domain
belongs to
is used by
(1,1)
(0,*)
(0,*)
(1,*)
(1,1)
Result
(1,1)
(1,*)
Process
(1,*)
is created
by
has
(1,1)
Maturity Level
(1,*)
(1,*)
isa
(1,5)
IT Governance
Focus Area
Goal
(1,*)
Activity Goal
Information
Criteria
supports
IT Goal
Process Goal
(1,7)
(1,*)
(0,*)
supports
adresses
is
measured
by
is
determined
by
(1,1)
(1,*)
Metric
Maturity Model
Abbildung 2 Ontologisches Metamodell von COBIT
Der Modellierer kann als Brücke und Interpreter zwischen Realität und
Modell bzw. zwischen Modell und Metamodell betrachtet werden. [5, S. 74]
beschreibt die Modellierungssituation folgendermaßen: „Setzt man
Modellierung mit Abbildung der Realität gleich, so würde nicht nur der
Modellerstellungsvorgang trivialisiert - man bräuchte nur noch ein
geschultes Auge und eine gewisse Auffassungsgabe für die Realität - ,
sondern man ginge von der impliziten Annahme aus, daß die Realität
objektiv erkennbare Strukturen aufweisen würde.“
Vor diesem Hintergrund stellt sich die Frage, wie der
Metamodellierungsprozess methodisch fundiert ablaufen kann. Hier ist
kritisch zu analysieren, wie ein mehrere hundert Seiten umfassendes
254
Referenzmodell durch eine strukturierte Vorgehensweise in ein Metamodell
abgebildet
werden
kann.
COBIT
bspw.
erleichtert
den
Metamodellierungsprozess durch die ihm innewohnende Struktur.
Vereinfacht gesagt hat COBIT – im Sinne von [5] – eine „objektiv
erkennbare Struktur“, die die Darstellung der Komponenten in einem
Metamodell erleichtert. Allerdings stellt sich die Frage, ob die „objektiv
erkennbaren Strukturen“ jeweils auch die semantisch gehaltvollsten sind.
Soll jedoch für ein im Vergleich unstrukturierteres Modell wie ITIL ein
Metamodell erstellt werden, ist die methodische Fundierung des
Metaisierungsprozesses eine weitaus größere Herausforderung.
Um von der Instanzebene über die Modellebene zur Ebene der Metamodelle
zu kommen, werden Mechanismen für die Abstraktion benötigt. Im Rahmen
der Metamodellierung abstrahiert der Modellierer ausgehend vom
ursprünglichen
Modell
auf
eine
höhere
Modell-Ebene,
die
Metamodellebene. Diesen Abstraktionsmechanismus nennt Strahringer [32]
Metaisierungsprinzip. Ein in der Wirtschaftsinformatik stark verbreiteter
Mechanismus ist die linguistische Abstraktion. Dieses Metaisierungsprinzip
wird beispielsweise verwendet, um eine Sprache abzubilden. Neben der
sprachlichen Abstraktion gibt es weitere Möglichkeiten des Metaisierens. So
betonen [17] und [1] die Möglichkeiten des ontologischen Metaisierens, das
im Gegensatz zum sprachlichen Metaisieren eine Abbildung der
Modellkomponenten aufgrund ihrer ontologischen Zusammenhänge
darstellt.
Für das COBIT-Metamodell wurde die ontologische Abstraktionsform
verwendet, um die relevanten Komponenten der Referenzmodelle der ITGovernance zu beschreiben. Für den Benutzer des Metamodells kann es von
Bedeutung sein, das Metaisierungsprinzip zu kennen, da insbesondere beim
ontologischen Metaisierungsprinzip der Modellierer diverse subjektive
Modellierungsentscheidungen treffen muss [16]. Hier ist es jedoch
ausreichend, kurz auf das verwendete Metaisierungsprinzip hinzuweisen,
etwa durch den Titel des Metamodells. Bereits eine Deklaration in der
Bildunterschrift erleichtert dem Benutzer das Modellverständnis.
Um Modelle bzw. Metamodelle für die weitere Forschung nutzbar zu
machen, sollte nach Meinung der Verfasser die Qualität des Metamodells
Beachtung finden. Die Bestimmung der Qualität von Modellen ist jedoch
problematisch, wie das folgende Zitat von [3, S. 2] verdeutlicht: „Ein
255
wichtiger Punkt ist … die Tatsache, dass die Richtigkeit von Modellen nicht
letztendlich nachweisbar ist, sondern sich aus dem Diskurs der
Sachkundigen und Gutwilligen ergibt, die ein Modell als zutreffend
erachten“. Darüber hinausgehend wird vermehrt ein höheres Maß an
Transparenz und Nachvollziehbarkeit beim Modellierungsprozess und bei
der Evaluation von Modellierungsergebnissen gefordert. Insbesondere für
letzteres können Erkenntnisse der Evaluation von konzeptionellen Modellen
herangezogen und auf die Metamodellierung angepasst werden. Eine
Möglichkeit zur Evaluation könnte beispielsweise die der pragmatischen
Modellqualität sein. [22] evaluieren die pragmatische Qualität von Modellen
mithilfe
von
Benutzerbefragungen
und
schließen
von
der
Benutzerzufriedenheit auf die Qualität des Modells. Um diese Form der
Evaluation jedoch für Metamodelle von Referenzmodellen der ITGovernance nutzen zu können, sind verschiedene Fragen zu analysieren.
Beispielsweise die Frage, welche Art von Benutzer für eine Evaluation
geeignet ist. Unabhängig von der Art der Evaluation kann jedoch
festgehalten werden, dass erst Metamodelle von ausreichender Qualität zur
Integration eingesetzt werden können.
Zusammenfassend kann festgehalten werden, dass der Erstellungsprozess
von Metamodellen methodisch fundiert erfolgen sollte, dass das
Metaisierungsprinzip eines Modells ersichtlich sein muss und die Modelle
evaluiert werden sollten. In dieser Form erstellte konzeptionelle
Metamodelle von Referenzmodellen können - wie im folgenden Abschnitt
beschrieben - zur Kombination und Integration eingesetzt werden.
4 Kombination und Integration von IT-GovernanceReferenzmodellen mithilfe von Metamodellen
Im Folgenden wird die Eignung von Metamodellen zur Kombination und
Integration von Referenzmodellen erörtert. Die Möglichkeiten und Grenzen
eines Metamodells als Hilfsmittel zur Kombination und Integration werden
am Beispiel der Referenzmodelle COBIT 4.1 und CMMI dargestellt. Hierbei
wird auf Verfahren der Schemaintegration von Datenbanken
zurückgegriffen, deren Anwendung für den hier verfolgten Zweck
zielführend erscheint.
256
Das Ziel der Schemaintegration ist es, mehrere konzeptionelle Schemata in
einem integrierten Schema zusammenzuführen. [2] definieren
Schemaintegration als „… the process of merging several conceptual
schemas into a global conceptual schema… .“ Sie betonen weiter, dass das
alleinige Auffinden gleicher Konstrukte und Konzepte nicht ausreicht.
Vielmehr müssen Ähnlichkeiten und Unterschiede zwischen den InputSchemata festgestellt werden. Da die Konstruktion eines globalen Modells
auch der Zweck der Integration verschiedener (spezialisierter) Modelle sein
kann, liegt eine ähnliche Zielsetzung vor. Darüber hinaus verweisen [2]
darauf, dass Ähnlichkeiten und Unterschiede – auch Korrespondenzen
genannt – in den zu integrierenden Modellen festgestellt werden müssen, um
angemessen entscheiden zu können, ob entsprechende Modellkomponenten
bspw. modifiziert in ein globales Schema eingehen können.
Für das Zusammenführen von Modellfragmenten sind von [30, 31, 25] vier
Aktivitäten vorgesehen, die im Folgenden am Beispiel eines Ausschnitts des
vorgestellten COBIT-Metamodells und CMMI exemplarisch durchgeführt
und diskutiert werden: (1) Vorintegration, (2) Vergleich und
Konfliktidentifikation, (3) Anpassung und Überlagerung und (4)
Restrukturierung- und Optimierungsphase.
Ad (1) Vorintegration Im Rahmen der Vorintegration wird festgelegt, welche
Modellkomponenten in welcher Reihenfolge konsolidiert werden sollen.
Hierbei werden verschiedene Integrationsstrategien unterschieden, bei denen
die zu integrierenden Modelle mit unterschiedlichem Gewicht eingehen.
Wird die Erstellung eines globalen Modells angestrebt, so ist es Ziel, dass
die unterschiedlichen Modelle gleichgewichtig eingehen. Anders wäre es,
wenn ein Modell als Bezugspunkt genommen wird. Übertragen auf den hier
vorliegenden Anwendungsfall bedeutet dies die Identifikation der zu
integrierenden Modelle, des Ausmaßes der Integration und der Reihenfolge.
In unserem Beispiel sollen COBIT 4.1 und CMMI gleichgewichtig integriert
werden. Ausgangspunkt ist das COBIT-Modell ohne jegliche Erweiterungen
[10 bzw. 8]. CMMI wird ebenfalls in seiner elementaren Form verwendet
[27].
Ad (2) Vergleich und Konfliktidentifikation In der nächsten Phase erfolgt der
Schemavergleich, bei dem Beziehungen zwischen den Elementen der
Referenzmodelle identifiziert, analysiert und dokumentiert werden.
257
Insbesondere sollen Konflikte und Inkonsistenzen aufgedeckt werden.
Unterschieden werden in Anlehnung an [4] vier semantische Beziehungen:
 Äquivalenz: Zwei Konstrukte zweier Modelle sind als äquivalent zu
bezeichnen.
 Überlappung: Zwei Konstrukte zweier Modelle bilden eine nichtleere
Schnittmenge.
 Einschluss/Teilmenge: Ein Konstrukt von einem Modell schließt ein
Konstrukt eines anderen Modells vollständig ein.
 Disjunktheit: Zwei Konstrukte zweier Modelle bilden eine leere Menge,
stehen jedoch in einer für die Konsolidierung relevanten Beziehung.
Welche der genannten Beziehungen vorliegt, muss einerseits über die
Benennung der Modellelemente entschieden werden, wobei es gilt, mögliche
semantische Defekte zu identifizieren (Synonyme, Homonyme). Eine tiefer
gehende Integration und Analyse würde auch die Instanzen der jeweiligen
(Meta-)Modellelemente einbeziehen.
Specific Practice und
Sub Practice
(Überlappung)
Sub Practice
(Überlappung)
Activity
Control
Objective
is
contained
in
Sub Practice
(Überlappung)
is
contained
in
Control Practice
belongs to
Domain
Category
(Extensionale
Äquivalenz)
is used by
Result
Work Products
(Extensionale
Äquivalenz)
Process
is created
by
Process Area
(Extensionale
Äquivalenz)
is
measured
by
has
Maturity Level
Capability
(Extensionale
Äquivalenz)
Metric
ohne Entsprechung
(Disjunktheit)
Abbildung 3 Vergleich von COBIT und CMMI
Abbildung 3 zeigt einen Ausschnitt des COBIT-Metamodells aus Abbildung
2. Die einzelnen Konstrukte werden jeweils mit dem CMMI-Referenzmodell
verglichen und gemäß den genannten semantischen Beziehungen
258
gekennzeichnet. Beispielsweise kann die COBIT-Komponente Process als
äquivalent zur CMMI-Komponente Process Area betrachtet werden.
Demgegenüber gibt es in CMMI keine Entsprechung für die COBITKomponente Metric. Beispiele für Überlappungen sind CMMI Specific
Practices, die Überschneidungen zu den COBIT Control Objectives
aufweisen.
Ad (3) Anpassung und Überlagerung Ziel dieser Aktivität ist es, die Modelle
durch Mischen bzw. Überlagern in ein gemeinsames konzeptionelles Modell
zu überführen. Hierbei kommen Integrationsregeln zum Einsatz, die
festlegen, wie Modellelemente, zwischen denen eine Beziehung besteht, in
dem globalen Modell abgebildet werden [4, 30, 31]. Für die verschiedenen
vorliegenden semantischen Beziehungen können Integrationsregeln für die
Bildung eines globalen Modells definiert werden. Bspw. kann bei
Äquivalenz ein gemeinsames Modellelement in das globale Modell
aufgenommen werden; bei Überlappung bietet sich die Bildung eines
integrierenden, gemeinsamen Modellelements (ggf. mit neuem Bezeichner)
an, welches beide Modellelemente semantisch voll umfasst; bei Disjunktheit
kann entschieden werden, ob das Modellelement in dem konkreten
Anwendungsfall Bedeutung hat oder ob es vernachlässigt werden kann.
Letzteres kann bspw. mit Blick auf das Element Metric (Abbildung 2)
erwogen werden. Process (bzw. Process Area) und Result (Work Product)
können - nach entsprechender Entscheidung für die Benennung unverändert in das globale Modell eingehen. Bei Activity und Control
Objective ist ein differenzierteres Vorgehen möglich und die Aufteilung in
mehrere Modellelemente erforderlich.
Ad (4) Restrukturierung- und Optimierungsphase Schließlich können an dem
Endergebnis oder den Zwischenergebnissen Restrukturierungen und/oder
Optimierungen vorgenommen werden. Sind im Anschluss weitere
Referenzmodelle zu integrieren, wird mit der Aktivität 2 fortgefahren.
Im
Ergebnis
sind
so
Korrespondenzen
auf
Ebene
der
Metamodellkomponenten identifiziert, wodurch sich zum einen ein höheres
Maß an Transparenz und Vereinheitlichung der unterschiedlichen
Sprachwelten ergibt. Zum anderen lässt sich auf Grundlage einer solchen
Analyse ein kontrolliert-kombinierter und ggf. ein integrierter Einsatz
verschiedener Referenzmodelle der IT-Governance fundierter gestalten.
259
5 Fazit und Ausblick
Die Metamodellierung von Referenzmodellen stellt nach Meinung der
Verfasser eine Möglichkeit dar, den beschriebenen Herausforderungen
sinnvoll zu begegnen. Bevor jedoch Metamodelle zur Integration genutzt
werden können, muss sicher gestellt sein, dass die Qualität der Modelle
ausreichend ist, d.h. die Modelle müssen zunächst in einem methodisch
gestützten Verfahren erstellt werden. Hinsichtlich der anschließenden
Evaluation ergeben sich neben den bekannten Problemen der Evaluation von
konzeptionellen Modellen spezielle Herausforderungen, die auf die
Metaebene zurückzuführen sind. Ein weiterer notwendiger Schritt ist die
Integration von mehreren heterogenen Referenzmodellen. Die Integration
zweier Referenzmodelle, wie hier für COBIT und CMMI illustriert, ist
lediglich der erste Schritt, um den Herausforderungen einer Multi-ModellUmgebung zu begegnen. Ein generisches Metamodell, - das vergleichbar zu
einer EAI-Applikation - die vorhandenen Modelle integriert und je nach
Standpunkt auch als Metametamodell [32] bezeichnet werden kann, wird
Gegenstand weiterer Forschungsbemühungen sein.
Kritisch zu betrachten ist die Frage nach der Integration der Modelle auf der
Ebene
der
Anwendung
von
Referenzmodellen
(Ebene
der
Prozessbeschreibungen etc.). Die Integration von Modellen auf Metaebene
ist nicht ohne weiteres auch auf der Modellebene anzuwenden. Die
Veröffentlichungen der adressierten Referenzmodelle umfassen zum Teil
mehrere hundert Seiten und beinhalten Prozess- und Rollenbeschreibungen,
Hinweise und vieles weitere. Die Verfasser sind sich bewusst, dass die
Metamodellierung hierfür lediglich einen Startpunkt darstellt. Die
Integration auf der Ebene von Aktivitäten oder gar Teilaktivitäten kann
durch Metamodelle nicht geleistet werden. Jedoch ist die Identifikation von
Konflikten auf der Ebene der konzeptionellen Elemente eines
Referenzmodells ein erster und entscheidender Schritt für eine Integration
auf den nachgelagerten Ebenen. Auf Metaebene können so potentielle
Kombinationspunkte ausfindig gemacht werden, welche eine spätere
Kombination
auf
Modellebene
erst
ermöglichen.
Weitere
Forschungsbemühungen adressieren daher die gemeinsame toolgestützte
Abbildung von Metamodellen und Modellen in einem semantischen Netz.
260
[2] ATKINSON, C., KÜHNE, T., Model-Driven Development: A Metamodeling
Foundation, IEEE Software, vol. 20, no. 5, pp. 36–41, 2003.
[3] BATINI, C., LENZERINI, M.; NAVATHE, S.B., A Comparative analysis of
methodologies for database schema integration. In: ACM Computing Surveys 18
(1986) 4, S. 323-364, 1986.
[4] BECKER, J., ALGERMISSEN, L., Grundsätze ordnungsmäßiger Modellierung - Über
Konstruktivisten, Handels-H's und Referenzmodelle, Arbeitsberichte des Instituts für
Wirtschaftsinformatik,Westfälische Wilhelms-Universität Münster , 1994.
[5] CONRAD, S., Schemaintegration. Integrationskonflikte, Lösungsansätze, aktuelle
Herausforderungen, in: Informatik – Forschung und Entwicklung 17 (2002), pp. 101111, 2002.
[6] DRESBACH, S.: Epistemologische Überlegungen zu Modellen in der
Wirtschaftsinformatik. In Becker, J., Schütte, R., Wendt, O., Zelewski, S. (Eds.):
Wirtschaftsinformatik und Wissenschaftstheorie. Bestandsaufnahmen und
Perspektiven. Wiesbaden, p. 71-94, 1999.
[7] ESSER, M.; Komplexitätsbeherrschung in dynamischen Diskurswelten, Josef Eul
Verlag, Köln 1999.
[8] GOEKEN, M.; ALTER, S. Towards Conceptual Metamodeling of IT Governance
Frameworks – Approach – Use- Benefits. Erscheint in: Proceedings of the Hawaii
International Conference on System Sciences (HICSS’42), Waikoloa, Big Island,
Hawaii 2009.
[9] GOEKEN, M.; ALTER, S., Representing IT Governance Frameworks as Metamodels,
in: Proceedings of the 2008 International Conference on e-Learning, e-Business,
Enterprise Information Systems, and e-Government (EEE’08), World Congress in
Computer Science (Worldcomp’08), July 14-17, Las Vegas Nevada 2008.
[10] GOEKEN, M.; ALTER, S., IT Governance Frameworks as Methods, in: Proceedings of
the 10th International Conference on Enterprise Information Systems (ICEIS 2008),
June 12-16, Barcelona, Spain 2008.
[11] IT GOVERNANCE INSTITUTE, COBIT 4.1, o.O. 2007.
[12] IT GOVERNANCE INSTITUTE, COBIT Mapping, Overview of International IT
Guidance, 2006. Unter: www.isaca.org, Abruf am 10.3.2007.
[13] IT GOVERNANCE INSTITUTE, COBIT 4.0, o.O. 2006.
[14] IT GOVERNANCE INSTITUTE, IT Governance Global Status Report, 2006.
Verfügbar unter www.isaca.org, at; Abruf: 03.04.2007.
[15] ITSMF und ISACA, ITIL-COBIT-Mapping, Gemeinsamkeiten und Unterschiede der
IT-Standards, Symposion, Düsseldorf 2008.
[16] JOHANNSEN, W.; GOEKEN, M., Referenzmodelle für IT-Governance, Heidelberg
2007.
[17] KARAGIANNIS, D., KÜHN, H., Metamodeling Platforms, in: A. Min Tjoa, & G.
Quirchmayer (Eds.), Lecture Notes in Computer Science: Vol. 2455. Proceedings of the
Third International Conference EC-Web (pp. 451–464). Springer, 2002.
[18] KARAGIANNIS, D., HÖFFERER, P., Metamodels in action: An overview. ICSOFT
(1), 2006.
[19] KNEUPER, R., CMMI, dpunktVerlag, Heidelberg 2007.
261
[20] KPMG, Summary of KPMG IS Governance Survey. KPMG LLP, London, September
2004.
[21] KURPJUWEIT, S.; WINTER, R., Viewpoint based Meta Model Engineering. EMISA
2007, pp 143-161, in: Manfred Reichert, Stefan Strecker, Klaus Turowski (Eds.):
Enterprise Modelling and Information Systems Architectures - Concepts and
Applications , Proceedings of the 2nd International Workshop on Enterprise Modelling
and Information Systems Architectures (EMISA'07), October 8-9, 2007. LNI P-119 GI
2007.
[22] LEITE, J.C.S.P.; FRANCO A.P.M., A strategy for conceptual model acquisition. In
IEEE International Symposium on Requirements Engineering. IEEE Computer Society
Press, Los Alamitos, CA, pp 243-246, 1993.
[23] MAES, A., POELS, G., Evaluating quality of conceptual modelling scripts based on
user perceptions, in: Data and Knowledge Engineering 63 (2007), p. 701-724.
[24] OFFICE OF GOVERNMENT COMMERCE, ITIL V2, London 2000.
[25] OFFICE OF GOVERNMENT COMMERCE, ITIL V3, London 2007.
[26] RIZOPOULOS, N., McBRIEN, P., MAGNANI, M., MONTESI, D.: Schema
Integration based on Uncertain Semantic Mappings, Conference or Workshop Paper,
24th International Conference on Conceptual Modeling (ER’05), Klagenfurt, Austria
Lecture Notes in Computer Science,Volume 3716, pp.31–46, October 2005.
[27] SOFTWARE ENGINEERING INSTITUTE, CMMI, 2007.
[28] SCHÜTTE, R., Die neuen Grundsätze ordnungsmäßiger Modellierung, Paper zum
Forschungsforum '97, 16.09.-20.09.1997 Leipzig 1997.
[29] SCHÜTTE, R., ROTTHOWE, T., The Guidelines of Modeling- an approach to enhance
the quality in information models. In Ling, Ram, Lee (Eds.) Conceptual Modeling – ER
98. Singapore, 16.-19.11.98, pp240-254, 1998.
[30] SIVIY, J., KIRWAN, P., MARINO, L., MORLEY, J. Fünfteilige White Paper Serie
zum Thema Multi-Modell-Umwelt, Unter:
www.sei.cmu.edu/publications/pubweb.html, Abruf 10.07.2008.
[31] SPACCAPIETRA, S., PARENT, C.; DUPONT, Y., Model Independent Assertions for
Integration of Heterogeneous Schemas. VLDB Journal 1, 1, S. 81–126, 1992.
[32] SPACCAPIETRA, S., PARENT, C., View Integration: A Step Forward in Solving
Structural Conflicts. In: IEEE Transactions on Knowledge and Data Engineering 2, 6,
S. 258-274, 1994.
[33] STRAHRINGER; S., Metamodellierung als Instrument des Methodenvergleichs,
Shaker Verlag, Aachen 1996.
[34] VERHOEF, T.F., HOFSTEDE, A.H.M.T.; WIJERS; G.M., Structuring Modelling
Knowledge for CASE Shells. In Andersen, R. et al. (Eds.): Proceedings of the third
International Conference CAiSE’91 on Advanced Information Systems Engineering,
pp. 502-524. 1991.
262
Fachbeitrag 10:
Multi-Modell-Umgebung IT-Governance: Einsatz mehrerer Best-PracticeReferenzmodelle
Dieser Fachbeitrag wurde in einer gekürzten Version veröffentlicht in: Proceedings der
Informatik 2010, 27.09.-02.10.2010, Leipzig. Lecture Notes in Informatics (LNI).
263
Multi-Modell-Umgebung IT-Governance:
Einsatz mehrerer Best-Practice-Referenzmodelle
Stefanie Looso
Frankfurt School of Finance and Management
Sonnemannstraße 9-11
60314 Frankfurt
Abstract: Unternehmen setzen zunehmend mehrere Best-Practice-Referenzmodelle
(BPRM) der IT-Governance gleichzeitig ein. Ein unsystematischer Einsatz von
mehreren BPRM kann erhebliche Ineffizienzen bergen, daher ist ein systematischer
kombinierter Einsatz erstrebenswert. Um den kombinierten Einsatz mehrerer Modelle
gezielt zu unterstützen, sind genaue Kenntnisse der Kombination von BPRM in einer
Multi-Modell-Umgebung notwendig. Diese werden in diesem Beitrag zunächst
theoretisch aufgearbeitet, bevor eine Möglichkeit präsentiert wird, die Kombination
von Modellen in einer Multi-Modell-Umgebung gezielt zu unterstützen.
1 Einführung und Problemstellung
Die
für
den
Referenzmodelle
weitgefassten
(BPRM)
Bereich
entsprechen
IT-Governance
verfügbaren
unterschiedlichen
Best-Practice-
Perspektiven
auf
die
Unternehmens-IT. So wird beispielsweise COBIT (IT Governance Institute 2007) von
Wirtschaftsprüfern und Auditoren für die IT-Prüfung bevorzugt, während im Bereich
Systementwicklung verstärkt CMMI (Software Engineering Institute 2007) Verwendung
findet. Der IT-Betrieb wiederum hat seine Prozesse vielfach an ITIL bzw. ISO 20000
ausgerichtet (KPMG 2004). Die Gründe für den Einsatz von mehreren BPRM (oder
Teilbereichen mehrerer BPRM) sind vielfältig. Mögliche Gründe sind etwa: gesetzliche
Vorschriften oder Empfehlungen, Marketingüberlegungen, Branchenvergleiche, persönliche
264
Vorlieben von Entscheidern, Mode, etc. (Looso et al. 2010a; Alter et al. 2009).
Unternehmen stehen daher gegenwärtig vor der Herausforderung, mehrere BPRM (bzw.
deren Teilbereiche) einzusetzen oder selbiges zu planen (Cater-Steel et al. 2006). Verwendet
ein Unternehmen verschiedene, sich überschneidende Modelle, wird dies zumeist als MultiModell-Umgebung (MMU) bezeichnet (Siviy et al. 2008; Looso et al. 2010a).
Für den Einsatz von mehreren BPRM gibt es grundsätzlich zwei Möglichkeiten. Die
Modelle können entweder unabhängig von einander (etwa nacheinander oder parallel) oder
kombiniert eingesetzt werden. Insbesondere bei vorliegenden Überschneidungen ist der
kombinierte Einsatz nach Ansicht der Verfasserin erstrebenswert (siehe Alter et al. 2009).
Solche Überschneidungen liegen im Bereich der hier betrachteten BPRM in der Regel vor.
Ursache
der
zum
Teil
erheblichen
Überschneidungen
ist
bspw.,
dass
der
Gegenstandsbereich der BPRM wächst und die jeweils neuen Versionen von BPRM im
Vergleich zu ihren Vorgängermodellen größere fachliche Bereiche abdecken. Beispielhaft
sei hier die Veränderung von ITIL V2 zu ITIL V3 genannt: Während ITIL V2 sich primär
auf Prozesse fokussierte, beschäftigt sich ITIL V3 zusätzlich mit Strategie (Service
Strategy) und Optimierung (Continual Service Improvement), woraus Überschneidungen zu
den Modellen COBIT und CMMI resultieren. Ähnliche Entwicklungen lassen sich bei
COBIT 5 beobachten. Hier wird das Ziel verfolgt COBIT für das operative IT-Management
zu nutzen: „[…] align with the latest management practices as well as strengthening areas
such as decision making, organisational structures, skill requirements, human factors,
culture and change enablement.― (COBIT 5, DRAFT, S. 7).
Durch die Ausdehnung der BPRM ergeben sich daher fortlaufend neue Schnittmengen und
Redundanzen bei vormals tendenziell spezialisierten und nahezu überschneidungsfreien
Modellen. Diese Überschneidungen können unter anderem zu Ineffizienzen beim
unabgestimmten Einsatz von mehreren BPRM führen. So führt die Verwendung von
unterschiedlichen BPRM bspw. dazu, dass getrennte Sprachwelten entstehen und so bereits
das Erstellen eines unternehmensweiten Glossars erhebliche Herausforderungen birgt (Alter
et al. 2009). Weiterhin können die Anforderungen der verschiedenen BPRM an denselben
Unternehmensbereich kollidieren, indem unterschiedliche Schwerpunkte gesetzt oder
Philosophien vertreten werden. Somit ist festzuhalten, dass der unabgestimmte Einsatz
265
verschiedener BPRM die an sich schon hohe Komplexität von BPRM-Anwendungen
zusätzlich erhöht. Überschneidungen zwischen BPRM führen in Unternehmen daher etwa
zu
Doppeltarbeit,
Mehrfachdokumentation
oder
im
Extremfall
zu
redundanter
Prozessmodellierung. Siviy et al. 2008 weisen nach, dass eine Harmonisierung der Modelle
auch deshalb vermehrt nachgefragt wird, da dort Potenzial für eine Erhöhung des Return on
Investment liegt. Der kombinierte Einsatz von sich überschneidenden BPRM ist demnach
erstrebenswert.
In Praxis und Wissenschaft sind daher in den letzten Jahren Ansätze zum Vergleich und zur
Kombination von BPRM entstanden (siehe bspw. COBIT-Mappings; itSMF 2008 oder
Hochstein et al. 2003). Diese vorhandenen Ansätze enden jedoch zumeist mit einem mehr
oder weniger formalen Vergleichsergebnis und lassen die weiteren Schritte der
Kombination offen (Looso et al. 2010b und Johannsen et al. 2007, S.205 ff geben einen
guten Überblick). Vorhandene BPRM-Mappings aus dem Umfeld der herausgebenden
Organisationen (ISACA, itSMF, SEI etc.) vergleichen bspw. zumeist zwei BPRM direkt
miteinander. Dabei zeigen sie in der Regel in einem 1:1-Vergleich Schnittstellen auf, d.h.
sie suchen die Entsprechung einer Modell-Komponente im anderen Modell (siehe COBITMappings oder itSMF et al. 2008). Die resultierende Fülle an Ähnlichkeitsaussagen ist
einerseits in ihren Ausmaßen sehr umfangreich und andererseits nicht auf die Erstellung
eines kombinierten Modells ausgerichtet (siehe bspw. Hochstein et al. 2003; Böhmann et al.
2004; Johannsen et al. 2007). Ziel dieses Beitrags ist es daher, einen Ansatz zur
Kombination von Modellen vorzustellen.
2 Kombination von BPRM
Fraglich ist zunächst, was Kombination bedeutet und wo sie ansetzen kann. Winter 2009
unterscheidet vier Archetypen der Integration von zwei oder mehreren Artefakten. Er nennt
Alignment, Ableitung, Bindung und Vereinigung. Der vorliegende Beitrag beschränkt sich
auf die Vereinigung von Modellen. Im Multi-Modell-Fall wird demnach angestrebt, die
BPRM zu einem integrierten Modell zu kombinieren.
266
Den Ausführungen von Looso 2011343 ist zu entnehmen, dass die Anpassung und
Anwendung von BPRM durch die Anwendung von Forschungsergebnissen aus der
Referenzmodellierung (siehe insbesondere Becker et al. 2004 und außerdem Fettke et al.
2004; Frank 1999; Scheer et al. 2002; Goeken 2002; Becker 2004 oder Loos et al. 2005)
und dem Methoden-Engineering (siehe Heym 1993; Gutzwiller 1994; Brinkkemper 1996;
Ralyté et al. 2001; Karlsson et al. 2006) systematisiert werden kann. Looso 2011 erarbeitet
verschiedene Methodenbestandteile zur Anpassung und Anwendung von BPRM, etwa
Aktivitäten, resultierende Ergebnisse und unterstützende Techniken. Aus diesem
Blickwinkel betrachtet, ist die Kombination zweier BPRM eine Aktivität und ein
kombiniertes BPRM ist ein Ergebnis. Das von Looso 2011 vorgestellte Ebenenmodell der
Ergebnistypen ist also für den Multi-Modell-Fall anzupassen. Ebenso ist der dort
verwendeten Systematik der Aktivitäten (sie unterscheidet Aktivitäten der Anpassung und
Aktivitäten der Anwendung) die Kombination hinzuzufügen.
2.1 Ergebnistypen im Multi-Modell-Fall
Aus dem Ebenenmodell der Ergebnistypen von Looso 2011 geht hervor, dass die
Ergebnistypen der Anpassung und Anwendung von BPRM anhand von 2x2 Ebenen
unterschieden werden können (Abbildung 1). Die Ergebnistypen lassen sich zunächst in
Modelle der Referenzebene und solche der Unternehmensebene unterscheiden. BPRM, die
an die spezifischen Umstände eines Unternehmens angepasst wurden, sind der
Unternehmensebene zuzuordnen, während das ursprüngliche BPRM der Referenzebene
zugeordnet wird (siehe bspw. Becker et al. 2004; vom Brocke 2003; Goeken 2002).
Beispielsweise sind unternehmensspezifische Modelle in ihren Ausmaßen verringert,
variiert oder erweitert (siehe bspw. Hars 1994, S. 144ff, Looso et al. 2010a und Looso
2011).
343
Looso 2011 meint Fachbeitrag 6 der vorliegenden Dissertation. In der veröffentlichten
Kurzversion ist an den fraglichen Stellen auf Looso 2010 verwiesen.
267
Metamodellebene
Modellebene
wird angepasst zu
BPRMM
wird
abgeleitet zu
wird
abgeleitet zu
Best-Practice
Referenzmodell
wird angepasst zu
Angepasstes
BPRM
wird
angewendet
auf
Unternehmensmodell
wird
angewendet
auf
BPRMAusschnitt
Referenzebene
BPRMVariation
erweitertes
BPRM
Unternehmensebene
Abbildung 1 Metamodell der Ergebnistypen der Methode (Ebenenmodell) [Looso 2011]
Die Erkenntnisse von Looso 2011 werden nun für die Kombination von Ergebnissen in
einer Multi-Modell-Umgebung erweitert. Hierfür werden zunächst nur die Ergebnistypen
der Modellebene in einem Zwei-Modell-Fall betrachtet (unterer Teil von Abbildung 1).
Abbildung 2 zeigt, wie das Modell von Looso 2011 erweitert werden kann, sodass es die
nötigen Ergebnisse einer Kombination beinhaltet.344 Der Modellebene des Ebenenmodells
von Looso 2011 sind also im Multi-Modell-Fall zwei Ergebnistypen hinzuzufügen.
344
Die Aufteilung des Ergebnistyps angepasstes BPRM in seine drei Formen wird der
Übersicht halber entfernt.
268
Best-Practice
Referenzmodell B
wird angepasst zu
Angepasstes BPRM B
wird
angewendet
auf
BPRMKombination
AB
wird angepasst zu
U.-spezifische BPRMKombination
Unternehmensmodell
Best-Practice
Referenzmodell A
wird angepasst zu
Angepasstes BPRM A
wird
angewendet
auf
Unternehmensebene
Referenzebene
Abbildung 2 Anpassung des Metamodells der Ergebnisse auf den Zwei-Modell-Fall
Da die unabgestimmte Anwendung zweier BPRM zu Ineffizienzen führen kann (siehe Siviy
et al. 2008 und Alter et al. 2009), sollte die Aktivität Kombination, nach Ansicht der
Verfasserin, vor den Aktivitäten der Anwendung stehen. Aus diesem Grund sind, wie in
Abbildung 2 ersichtlich, nur die Ergebnistypen der Kombination auf das Unternehmensmodell anzuwenden. Inwieweit es sinnvoll ist, die Aktivitäten der Anpassung vor einer
Kombination durchzuführen, kann nicht allgemeingültig beantwortet werden. Daher sind
beide Formen in Abbildung 2 dargestellt. Eine unternehmensspezifische BPRMKombination kann demnach aus der Kombination der angepassten BPRM entstehen, oder
aber eine Anpassung der BPRM-Kombination auf Referenzebene sein.
Wie das Ebenenmodell zeigt, lassen sich die Ergebnisse weiter in Ergebnisse der Meta- und
der Modellebene unterteilen. Hieraus ergeben sich zwei weitere zusätzliche Ergebnistypen
für den Multi-Modell-Fall. Die Kombination von Metamodellen ergibt die MetamodellKombination
und
die
Kombination
von
Metamodellen
resultiert
in
einer
unternehmensspezifischen Metamodell-Kombination.
Abbildung 3 fasst die notwendigen Veränderungen im Ebenenmodell der Ergebnisse
zusammen. Wie dort dargestellt, wird das Ebenenmodell der Ergebnisse von Looso 2011 im
269
Multi-Modell-Fall um vier Ergebnistypen erweitert. Die Beziehungen zwischen den Ebenen
sind übersichtlichkeitshalber entfernt, sie verlaufen jedoch analog zu den Darstellungen in
Abbildung 1 und 2.
BPRMM A
Metamodellebene
Unternehmensspezifisches MM A
BPRMM B
Unternehmensspezifische
Metamodell-Kombination
AB
Metamodell-Kombination
AB
Best-PracticeReferenzmodell A
Unternehmensspezifisches MM B
Best-PracticeReferenzmodell B
Unternehmensspezifisches Modell A
Unternehmensspezifisches Modell B
Modellebene
Unternehmensspezifische
Kombination AB
BPRM-Kombination AB
Referenzebene
Unternehmensebene
Abbildung 3 Zusätzliche Ergebnistypen im Multi-Modell-Fall
2.2 Aktivitäten im Multi-Modell-Fall
Den Aktivitäten der Anpassung und den Aktivitäten der Anwendung von Looso 2011 sind
im Folgenden die Aktivitäten der Kombination hinzuzufügen. In Anlehnung an bspw.
Becker et al 2004 kann Kombination, neben der Unterteilung in Referenz- und
Unternehmensebene,
zusätzlich
durch
eine
Unterscheidung
in
Modell-
oder
Metamodellebene klassifiziert werden. Aufgrund der Verwendung des Ebenenmodells lässt
sich die Aktivität Kombination daher wie folgt unterteilen:

Kombination der Metamodelle zweier BPRM (Referenzebene)

Kombination zweier unternehmensspezifischer Metamodelle (Unternehmensebene)

Kombination zweier BPRM (Referenzebene)

Kombination zweier angepasster BPRM (Unternehmensebene)
Die Art der Kombination ergibt sich also durch die zu kombinierenden Modelle und die
ausführenden Personen. Es ist jedoch fraglich, ob diese Aktivitäten tatsächlich unabhängig
von einander sind.
270
Für die Kombination von Metamodellen sind die Instanzen auf Modellebene relevant. Alter
et al. 2009 zeigen, dass in Anlehnung an die Datenbankintegration, die Kombination von
Metamodellelementen zumindest einen Vergleich ihrer Instanzen beinhaltet (siehe u.a.
Conrad 2002). Die Kombination von Metamodellen kann demnach aufgrund der
Verbindung von Metamodell und Modell nicht unabhängig von der Modellebene erfolgen.
Ebenfalls ist für eine Kombination von Modellen eine gemeinsame Struktur notwendig. Ein
gemeinsames kombiniertes Metamodell ist demnach die Basis der Modellkombination. Es
ist daher ratsam, die Kombination als eine integrierte Aktivität zu betrachten.
Weiterhin ist fraglich, ob sich die Aktivitäten der Kombination auf Referenzebene und
Unternehmensebene signifikant unterscheiden. Kombination auf Referenzebene würde
definitionsgemäß von den herausgebenden Institutionen der beiden BPRM durchgeführt
bzw. unterstützt werden. Ist dies nicht gegeben hat das resultierende kombinierte Modell
keinen Referenzcharakter und ist daher nicht der Referenzebene zuzuweisen.345 Die
Aktivitäten unterscheiden sich also anhand der ausführenden Personen. Dies kann in einer
Methode durch ein Rollenkonzept abgebildet werden (siehe Gutzwiller 1994; Becker 1998.
Karlsson 2002). Eine Unterscheidung in zwei verschiedene Aktivitäten ist daher nicht
notwendig. Zusammenfassend bedeutet dies, dass die Aktivität Kombination unabhängig
von der jeweiligen Ebene beschrieben werden kann.
Nach Ansicht der Verfasserin lassen sich, unabhängig vom Ebenenmodell, jedoch
grundsätzlich zwei Formen der Kombination unterscheiden. Die Modelle können
gleichberechtigt kombiniert werden, oder die Kombination erfolgt auf Basis eines
dominanten Modells (diese Unterscheidung ist nicht zu verwechseln mit der von Winter
2009 getroffenen Unterscheidung von Vereinigung und Alignment; beide Formen dieses
Beitrags sind dem Archetyp Vereinigung zugeordnet).
Die folgenden Ausführungen beschränken sich auf die Kombination auf Basis eines
dominanten Modells. Die gleichberechtigte Kombination von Modellen ist nicht Bestandteil
dieses Beitrags. Mit der zusatznutzenorientierten Kombination wird eine Aktivität
beschrieben, die zwei Modelle auf Basis eines dominanten Modells kombiniert. Die
345
Siehe Teil A der vorliegenden Dissertation.
271
Aktivität wird im Folgenden detailliert beschrieben und in einem späteren Kapitel anhand
eines Beispiels illustriert.
Aktivität: Zusatznutzenorientierte Kombination
Im Fokus der Aktivität steht der zu erwartende Zusatznutzen eines zweiten Modells
gegenüber dem Nutzen eines einzelnen BPRM. Besonders sinnvoll ist dieses Verfahren,
wenn ein Unternehmen bereits ein BPRM anwendet und sich durch den kombinierten
Einsatz einen zusätzlichen Nutzen verspricht. Natürlich kann das zweite Modell auch
unabhängig vom ersten Modell eingesetzt werden. Im Unterschied zu einem getrennten
Einsatz zweier BPRM, werden durch das hier beschriebene Vorgehen jedoch Redundanzen
und die oben beschriebenen Ineffizienzen der Multi-Modell-Umgebung vermieden. Die
Erstellung des Ergebnistyps BPRM-Kombination ist demnach Ziel dieser Aktivität.
In einem ersten Schritt ist zunächst das Ausgangsmodell festzulegen. Zu diesem
Ausgangsmodell werden in Schritt 3 Modellbereiche346 des zweiten BPRM hinzugefügt. In
einem zweiten Schritt werden die Modelle miteinander verglichen. Der Vergleich erfolgt
sowohl auf Metamodell- als auch auf Modellebene. Hier können erneut Analogien zum
Forschungsbereich Datenbankintegration genutzt werden (Spaccapietra et al. 1994;
Spaccapietra et al. 1992; Rizopoulos et al. 2005). In Anlehnung an die dort übliche
Terminologie ist das Metamodell eines BPRM ein konzeptionelles Schema des BPRM.
Demnach müssen nun zwei konzeptionelle Schemata verglichen werden. In der
Datenbankintegration werden für einen Vergleich der konzeptionellen Schemata und den
enthaltenen Daten die folgenden Konfliktarten unterschieden: Extensionale Konflikte,
Beschreibungskonflikte, Heterogenitätskonflikte und strukturelle Konflikte (siehe bspw.
Conrad 2002, S. 103). Looso 2011 argumentiert, dass Heterogenitätskonflikte und
strukturelle Konflikte datenbankspezifische Konflikte beschreiben. Extensionale Konflikte
und Beschreibungskonflikte beschreiben jedoch grundsätzlichere Unterschiede und können
daher nach Ansicht der Verfasserin auch verwendet werden, um die Ähnlichkeit bzw. die
Unterschiede von BPRMM zu beschreiben.
346
Subsumiert Modellelemente und Metamodellelemente.
272
Extensionale Konflikte bestehen, wenn zwei unabhängig voneinander entstandene Schemata
den gleichen Weltausschnitt (oder Teile davon) beschreiben und daher einander
entsprechende Metamodellelemente enthalten, jedoch die zugehörigen Instanzen nicht
vollständig übereinstimmen. Die Literatur kennt vier Arten dieses extensionalen Konflikts
(Abbildung 4). Beschreibungskonflikte liegen vor, wenn gleiche Elemente beschrieben
werden, sie sich jedoch in ihrer Beschreibung unterscheiden, bspw. aufgrund von
homonymen und synonymen Bezeichnungen (siehe auch Bishr et al. 1999 zur Behebung
solcher Konflikte).
Meta-Ebene
Modell A
Modell B
MxA
Eine MetamodellKomponente Mx tritt
sowohl in Modell A als
auch in Modell B auf
MxB
Modell-Ebene
Äquivalenz
MxA=MxB
#1 MxA
#2 MxA
Alle Instanzen von
MxA und MxB sind
identisch
#1 MxB
#2 MxB
Teilmenge
MxB schließt
MxA ein
#1 MxA
#2 MxA
Alle Instanzen von
MxA sind auch
Instanzen von MxB
#1 MxB
#2 MxB
#3 MxB
#1 MxA
#3 MxA
Einige Instanzen von
MxA sind auch
Instanzen von MxB
#2 MxB
#3 MxB
#1 MxA
Keine Instanz von
MxA ist auch Instanz
von MxB
#2 MxB
#3 MxB
Überlappung
MxA und MxB
haben eine
nicht leere
Schnittmenge
Disjunktheit
MxA und MxB
haben eine leere
Schnittmenge
Abbildung 4 Extensionale Konflikte (in Anlehnung an Conrad 2002, S. 103)
Diese Konfliktarten wurden von Looso 2011 bereits für den Vergleich von Ergebnissen des
Ein-Modell-Falls
verwendet.
Im
Multi-Modell-Fall
werden
nun
Ergebnisse
des
Ergebnistyps BPRMM bzw. BPRM verglichen. Im Verlauf des Vergleichs werden die sich
273
überlappenden Metamodellelemente explizit gekennzeichnet, denn diese Überlappungen
sind Ansatzpunkt für den nächsten Schritt der Aktivität.
Ausgehend vom erstellten Vergleichsergebnis wird, im Falle einer Überlappung, der
zusätzliche Nutzen des zweiten BPRM beurteilt. Im Falle der Überlappung beschreiben
beide Metamodelelemente den gleichen Ausschnitt der Realität (beispielsweise die Prozesse
eines Unternehmens347), die zugehörigen Instanzen hingegen unterscheiden sich. Fraglich ist
daher, ob die Instanzen des Metamodellelements des zweiten BPRM einen Zusatznutzen für
die Instanzen des ersten BPRM bergen. Für jede Instanz des ersten BPRM wird also nach
einer Verbesserung im zweiten BPRM gesucht. Aus dieser Verbesserung resultiert
annahmegemäß ein Zusatznutzen für das Unternehmen.
Die Beurteilung des Zusatznutzens erfolgt aufgrund von Einschätzungen der Anwender.
Hier wird deutlich, dass der zusätzliche Nutzen ein subjektives, schwer zu
operationalisierendes Konstrukt ist. Die Zusammensetzung des Projektteams oder das
Einbeziehen eines erfahrenen Beraters kann jedoch helfen, die Bestimmung des
Zusatznutzens zu objektivieren. Hier sei auf die Erkenntnisse der konsensorientierten
Referenzmodellierung
verwiesen.
Die
maßgebliche
Grundposition
dieser
Forschungsrichtung ist die Entstehung von Wahrheit durch den Konsens einer
sachverständigen Sprachgemeinschaft (Vgl. Becker 2004; Zelewski 1999).
2.3 Techniken im Multi-Modell-Fall
Für die Erstellung von Ergebnissen im Ein-Modell-Fall wurde von Looso 2011 eine
Vielzahl an Techniken beschrieben. Für die Erstellung der, im Multi-Modell-Fall
zusätzlichen,
Ergebnisse
der
Modellebene
(BPRM-Kombination
und
Unternehmensspezifische BPRM-Kombination) können die vorgestellten Techniken
ebenfalls verwendet werden. Im hier vorgestellten Beispiel wurde die Technik
Gruppendiskussion verwendet. Hierbei erfolgt die Entscheidungsfindung durch einen
Konsens oder eine Mehrheitsentscheidung der Teilnehmer. Häder 2002 zeigt diesbezüglich,
347
Von Beschreibungskonflikten sei an dieser Stelle abgesehen.
274
dass Gruppendiskussionen besonders geeignet sind, einen Konsens herbeizuführen.348 Die
Qualität des erzielten Ergebnisses hängt jedoch maßgeblich von den Teilnehmern der
Diskussion ab. Hier sei auf die Literatur zu diesem Thema im Rahmen der qualitativen
Forschung verwiesen (siehe bspw. Steinke 2000 oder Lamnek 2005, S.408ff).
3 Zusatznutzenorientierte Kombination von COBIT und CMMI
Im Rahmen der Fachgruppe „COBITmeetsCMMI― der ISACA wurde zwischen 2007 und
2011 in regelmäßigen Treffen über den Zusatznutzen von CMMI für COBIT diskutiert. Ziel
war es, den Zusatznutzen von CMMI für COBIT durch ein strukturiertes Vorgehen
systematisch zu erheben. Die aktiven Mitglieder der Fachgruppe stammen aus Wissenschaft
(1 Mitglied) und Praxis (3 Mitglieder) und verfügen über Erfahrungen im Bereich BPRM
der IT-Governance.349
Zunächst wurde COBIT als dominantes Modell ausgewählt. Im Anschluss daran erfolgte
der systematische Vergleich der Metamodellelemente und ihrer Instanzen. Die einzelnen
Metamodell-Komponenten werden jeweils mit dem CMMI-Referenzmodell verglichen und
gemäß den genannten Konflikten gekennzeichnet. Abbildung 5 zeigt einen Ausschnitt des
Vergleichs der Metamodelle. Die dargestellten Entitäten stammen aus dem dominanten
COBIT-Modell, die hinzugefügten Begriffe aus CMMI. Die diagnostizierten extensionalen
Konflikte stehen jeweils in Klammern darunter. Beispielsweise kann die COBITKomponente Process als Überlappung zur CMMI-Komponente Process Area betrachtet
werden. Demgegenüber gibt es in CMMI keine Entsprechung für die COBIT-Komponente
Metric.
348
Häder vergleicht Delphi-Befragungen, Gruppendiskussionen und Experteninterviews
bezüglich der Möglichkeit der Konsensfindung (Häder 2002, S. 60).
349 Siehe http://www.isaca.de/images/pdfs/2011-03-11-isaca-fg_bietet_cmmi_einen_mehrwert_zu_cobit.pdf. Abruf 14.04.2011.
275
Generic Practice
(Überlappung)
Control
Objective
is
contained
in
Sub Practice
(Überlappung)
is
contained
in
Control Practice
belongs to
Domain
Category
(Überlappung)
is used by
Result
Work Products
(Überlappung)
Process
is created
by
Process Area
(Überlappung)
is
measured
by
has
Maturity Level
Capability
(Überlappung)
Metric
(Disjunktheit)
Abbildung 5 Vergleich von COBIT und CMMI
Im weiteren Verlauf der Diskussion wurde beschlossen, zunächst die Überlappung zwischen
Control Objective und Specific sowie Generic Practice zu bearbeiten. Ausgangspunkt des
am Zusatznutzen orientierten Vergleichs und der angestrebten Modellkombination sind
demnach die Elemente COBIT Control Objective und CMMI Specific und Generic Practice.
Für die einzelnen Instanzen der Metamodell-Komponente Control Objective wird in den
korrespondierenden Instanzen des CMMI-Modells (Instanzen von Specific oder Generic
Practice) nach Verbesserungen gesucht. Ziel war es also nicht, wie in einem
konventionellen Mapping, eine 1:1-Beziehung herzustellen, denn diese basiert auf
Ähnlichkeit und hat daher einen geringen Zusatznutzen. Ziel war es vielmehr, eine
nutzenstiftende 1:n-Beziehung zu erstellen. Tabelle 1 zeigt einen Ausschnitt des erzielten
Ergebnisses.
276
Tabelle 1: Ausschnitt des Ergebnisses der COBIT-Domäne Plan & Organize
COBIT Domain: Plan and Organize (PO)
PO1.3 Assessment of Current Capability and Performance (Control Objective)
Der Einsatz der spezifischen Praktiken der CMMI Process Area ―Measurement and Analysis‖
ist empfehlenswert. Diese Praktiken fokussieren eine methodischere Vorgehensweise als das
COBIT Control Objective.
PO3.4 Technology Standards (Control Objective)
Hier fordert CMMI den verstärkten Einsatz von Reviews. Durch den Einsatz der CMMI
Process Area Verfication (VER), speziell die spezifische Praktik 2, werden für ausgewählte
Prozessoutputs (Work Products) Partner Reviews durchgeführt. Zusätzlich wird empfohlen
Process and Product Quality Assurance (PPQA) einzusetzen um die Einhaltung, der von
COBIT geforderten Standards zu gewährleisten.
PO4.7 Responsibility for IT Quality Assurance (Control Objective)
Es empfiehlt sich einen PPQA-Prozess, und die Reviews von VER (SG2) gemäß CMMI in die
vorhandene Qualitätssicherung einzugliedern.
PO4.10 Supervision (Control Objective)
COBIT beschäftigt sich hier zunächst mit Supervision einzelner Personen. CMMI thematisiert
zusätzlich das Umfeld der Mitarbeiter. Hier sollten daher die spezifischen Praktiken von
Organisational Training (OT) und PPQA dem PO4.10 hinzugefügt werden. Ebenfalls sollten
die Empfehlungen der generischen Praktik 2.5 „Train the people― bzgl. der Fähigkeiten und
Prozesskenntnissen hinzugefügt werden.
PO4.15 Relationships (Control Objective)
CMMI fordert explizit und kontinuierlich über den gesamten Entwicklungsprozess ein
Stakeholdermanagement (RD und GP2.7).
PO7.4 Personnel Training
Die spezifischen Praktiken von OT sind umfangreicher und systematischer, die Security
Requirements sollten von COBIT übernommen werden.
PO8 Quality Management (Process)
PPQA fordert eine ständige Überwachung der Prozess- und Produktqualität. CMMI schreibt
ein kontinuierliches Prozessverbesserungsprogramm vor (u.a. durch das Generic Goal 3). Bei
ständigen Verbesserungen sollte daher die Vorgehensweise und Infrastruktur von CMMI
genutzt werden
277
Neben der Kombination mit COBIT als dominantem Modell wurde in der Fachgruppe auch
eine Kombination ausgehend von CMMI durchgeführt. Die Ergebnisse werden in den
nächsten Monaten in Zusammenarbeit mit ISACA Germany Chapter e.V. veröffentlicht.
5 Fazit und Ausblick
Überschneidungen zwischen BPRM können in Kombination mit einem unsystematischen
Einsatz von mehreren BPRM Ineffizienzen auslösen, deren Beseitigung ökonomisches
Potential birgt. Ziel sollte es daher sein, BPRM kombiniert einzusetzen. Die notwendigen
Aktivitäten zur Kombination von BPRM in einem Multi-Modell-Fall wurden daher in
diesem Beitrag herausgearbeitet. Die präsentierten Erkenntnisse sind eine Ergänzung für die
von Looso 2011 vorgestellte Methode zur Anpassung und Anwendung von BPRM.
Die Beschreibung der Aktivitäten wurde in diesem Beitrag auf die zusatznutzenorientierte
Kombination beschränkt. Neben dieser Form der Kombination stehen weitere, die im
Rahmen künftiger Forschung entwickelt werden müssen. Die ZNOK wurde ausgewählt,
weil sie von Anwenderunternehmen in der Praxis durchgeführt werden kann. Vorteilhaft ist
diese Aktivität auch aufgrund der Möglichkeit, sie stufenweise anzuwenden. So kann etwa
zunächst nur für einen bestimmten Teil des Ausgangsmodells ein Zusatznutzen im zweiten
Modell gesucht werden.
Der vorgestellt Ansatz kann sowohl auf Ebene der Referenzmodelle, d.h. durch die
herausgebenden Institutionen, als auch auf Ebene der unternehmensspezifischen Versionen
der BPRM angewendet werden. Es gibt jedoch gegenwärtig keine Anzeichen für eine durch
die jeweiligen Institutionen angestrebte Kombination von BPRM. Jedoch gibt es
Fachgruppen und Expertengremien, die unabhängig von einem konkreten Unternehmen,
abstrakte Ergebnisse auf Referenzebene erzielen. Teilergebnisse der Fachgruppe
„COBITmeetsCMMI― der ISACA wurden in diesem Beitrag präsentiert. Ergebnisse dieser
Art gelten in der ISACA als Arbeitsergebnisse ohne Referenzcharakter. Durch die
Veröffentlichung
der
Ergebnisse
werden
sie
jedoch
einem
Diskussions-
und
Verbesserungsprozess zugänglich gemacht.
278
Ziel der Forschung muss es hingegen sein, den Einsatz mehrerer BPRM allgemeingültig zu
beschreiben und objektive Kombinationsverfahren zu etablieren. Weiterer Forschungsbedarf
besteht insbesondere bezüglich der Subjektivität des vorgestellten Ansatzes.
Zusammenfassend ist dieser Beitrag ein erster Schritt hin zu einer solchen allgemeingültigen
Beschreibung der Kombination von BPRM in einer Multi-Modell-Umgebung, er versteht
sich außerdem als Grundlage einer zukünftigen wissenschaftlichen Diskussion.
Alter, S.; Goeken, M.: Konzeptionelle Metamodelle von IT-Governance-Referenzmodellen als Basis
der Kombination und Integration in einer Multi-Model-Umgebung. In: Hansen, H.R.,
Karagiannis, D., Fill, H.G. (Hrsg.): Business Services: Konzepte, Technologien,
Anwendungen. 9. Internationale Tagung Wirtschaftsinformatik, Band 1, Wien, 2009.
Becker, J.; Delfmann, P.; Knackstedt, R.: Konstruktion von Referenzmodellierungssprachen. Ein
Ordnungsrahmen
zur
Spezifikation
von
Adaptionsmechanismen
für
Informationsmodelle. In: Wirtschaftsinformatik, Jg. 46, H. 4, 2004, S. 251–264.
Becker, J.: Referenzmodellierung. Grundlagen, Techniken und domänenbezogene Anwendung.
Heidelberg: Physica-Verlag, 2004.
Becker, M.: Umsetzung betrieblicher Prozesse. Methode, Fallbeispiele, Workflow-Technologie.
Dissertation, Universität St. Gallen, St. Gallen, Switzerland, 1998.
Bishr, Y.A.; Pundt, H.; Kuhn, W.; Radwan, M.: Probing the concept of information communities - a
first step toward semantic interoperability. In: Goodchild, Egenhofer, Fegeas, Kottman
(Hrsg.): Interoperating Geographic Information Systems, S. 55–69: Kluwer Academic,
1999.
Böhmann, T.; Krcmar, H.: Grundlagen und Entwicklungstrends im IT-Servicemanagement. In: HMD
- Praxis Wirtschaftsinformatik, 237, 2004.
Brinkkemper, S.: Method engineering: engineering of information systems development methods and
tools. In: Information & Software Technology, Jg. 38, H. 4, 1996, S. 275–280.
Cater-Steel, A.; Tan, W. G.; Toleman, M.: Challenge of adopting multiple process improvement
frameworks: Proceedings of the 14th European Conference on Information Systems,
2006.
COBIT 5, Draft: Online verfügbar unter: http://www.isaca.org/Knowledge-Center/Research/Documents/COBIT5_Design_Exposure_18Mar2010.pdf. Abruf: 14.04.2011.
279
Conrad, S.: Schemaintegration. Integrationskonflikte, Lösungsansätze, aktuelle Herausforderungen.
In: Informatik – Forschung und Entwicklung, 2002, 17; S. 101–111.
Fettke, P.; Loos, P.: Referenzmodellierungsforschung. In: Wirtschaftsinformatik, Jg. 46, H. 5, 2004, S.
331–340.
Frank, U.: Conceptual Modelling as the Core of the Information Systems Discipline – Perspectives
and Epistemological Challenges. In: Haseman, W. D.; Nazareth, D. L. (Hrsg.):
Proceedings of the Fifth Americas Conference on Information Systems (AMCIS
1999), August 13-15, 1999. Milwaukee, Wisconsin.
Goeken, M.: Grundlagen und Ansätze einer Referenzmodellierung für Führungsinformationssysteme.
Philipps-Universität Marburg. Fachbericht des Instituts für Wirtschaftsinformatik, Nr.
03, 2002.
Gutzwiller,
T.:
Das
CC
RIM-Referenzmodell
für
den
Entwurf
von
betrieblichen,
transaktionsorientierten Informationssystemen. Heidelberg: Physica-Verlag, 1994.
Hars, A.: Referenzdatenmodelle – Grundlagen effizienter Datenmodellierung. Wiesbaden 1994,
(zugleich Dissertation 1993 Saarbrücken).
Heym, M.: Methoden-Engineering - Spezifikation und Integration von Entwicklungsmethoden für
Informationssysteme. Dissertation. Hallstadt. Universität St.Gallen, Institut für
Wirtschaftsinformatik,1993.
Hochstein, A.; Hunziker, A.: Serviceorientierte Referenzmodelle des IT-Managements. In: HMD Praxis Wirtschaftsinformatik, 2003.
IT Governance Institute: COBIT 4.1, 2007.
itSMF; ISACA (Hrsg.): ITIL-COBIT- Mapping. Gemeinsamkeiten und Unterschiede der ITStandards. Symposion Publishing, Düsseldorf, 2008.
Johannsen, W.; Goeken, M.: Referenzmodelle für IT-Governance. dpunkt.verlag, Heidelberg, 2007.
Karlsson, F.: Meta-Method for Method Configuration. Dissertation. Linköping, Faculty of Arts and
Sciences, 2002.
Karlsson, F.; Wistrand, K.: Combining method engineering with activity theory: theoretical grounding
of the method component concept. In: European Journal of Information Systems, Jg.
15, H. 1, 2006, S. 82–90.
KPMG: Summary of KPMG IS Governance Survey, London, 2004.
Lamnek, S.: Qualitative Sozialforschung. 4., vollständig überarbeitete Auflage Beltz Psychologie
Verlags Union, 2005, S.408ff.
Loos, P.; Fettke, P.: Referenzmodellierung. Entwicklungsstand und Perspektiven. In: Information
Management & Consulting, Jg. 20, Sonderausgabe, 2005.
280
Looso, S.: Towards a structured application of IT governance best practice reference models. In:
Proceedings of the 16th Americas Conference on Information Systems (AMCIS 2010),
12.-15-08.2010, Lima, Peru.
Looso, S.; Goeken, M.: IT Governance: Application of Best Practice Reference Models. In:
Proceedings of the 18th European Conference on Information Systems, 2010a.
Looso S.; Goeken, M.; Johannsen, W.: Comparison and Integration of IT Governance Frameworks to
support IT Management. In: Praeg, Späth (Hrsg.) Quality Management for ITServices, IGI Global, 2010b.
Ralyté, J.; Rolland, C.: An Assembly Process Model for Method Engineering. 13th International
Conference on Advanced Information Systems Engineering (CAiSE 2001), Lecture
notes in computer science, 2001, S. 267–283.
Rizopoulos, N.; McBrien, P.; Magnani, M.: Schema Integration based on Uncertain Semantic
Mappings: 24th International Conference on Conceptual Modeling, 2005; S. 31–46.
Scheer, A.-W.; Seel, C.; Georg, W. (2002): Entwicklungsstand in der Referenzmodellierung. In:
Industrie Management, Jg. 18, H. 1, S. 9–12.
Siviy, J. Kirwan, P.; Marino, L.; Morley, J.: The Value of Harmonizing Multiple Improvement
Technologies: A Process Improvement Professional‘s View, SEI, 2008.
Software Engineering Institute: CMMI, 2007.
Spaccapietra, S.; Parent, C.; Dupont, Y.: Model Independent Assertions for Integration of
Heterogeneous Schemas. In VLDB Journal, 1992, 1; S. 81–126.
Spaccapietra, S.; Parent, C.: View Integration: A Step Forward in Solving Structural Conflicts. In
IEEE Transactions on Knowledge and Data Engineering, 1994, 6, S. 258–274.
Steinke, I.: Gütekriterien qualitativer Forschung. In: Flick, U., von Kardorff, Steinke (Hrsg.):
Qualitative Forschung. Ein Handbuch, S. 319-331. Reinbek b. Hamburg: Rowohlt,
2000.
vom Brocke, J.: Referenzmodellierung. Gestaltung und Verteilung von Konstruktionsprozessen.
(zugleich Dissertation, Münster, 2002.) Berlin: Logos (Advances in information
systems and management science, 4), 2003.
Winter, R.: Management von Integrationsprojekten: Konzeptionelle Grundlagen und Fallstudien aus
fachlicher und IT-Sicht (Business Engineering), Berlin: Springer, 2009.
281
Zwischenfazit Teil F
Ergebnis dieses Beitrags ist die Weiterentwicklung der Methode zur Anpassung und
Anwendung von BPRM bezüglich der Anforderungen in einer Multi-ModellUmgebung. Hierfür wurden beinahe alle bislang erzielten Forschungsergebnisse
kombiniert. Verwendete Ergebnisse sind:
o Metamodelle der BPRM aus dem Teilgebiet Struktur
o Theoretisches Verständnis der Multi-Modell-Umgebung aus dem Teilgebiet
Anwendung
o Methode zur Anwendung von BPRM aus dem Teilgebiet Methode
Die erstellten Metamodelle bilden gemeinsam mit dem theoretischen Verständnis der
Multi-Modell-Umgebung die Grundlage für die Weiterentwicklung der Methode.
Besonders in Fachbeitrag 9 wird deutlich, wie wichtig eine detaillierte Kenntnis der
Struktur von BPRM für einen gemeinsamen Einsatz der Modelle in einer Multi-ModellUmgebung ist. Hierfür sind alle zuvor präsentierten Forschungsergebnisse von
fundamentaler Bedeutung. Dieser Teil schließt die vorliegende Arbeit daher inhaltlich
ab und eröffnet gleichzeitig weiteren Forschungsbedarf. Um Redundanzen zu
vermeiden, werden die sich ergebenden Schlussfolgerungen, die Implikationen für
Theorie und Praxis sowie der zukünftiger Forschungsbedarf gesammelt im
abschließenden Teil G beschrieben.
282
Teil G: Fazit, Implikationen für Wissenschaft und Praxis
sowie weiterer Forschungsbedarf
Diese Arbeit ist dem Forschungsgebiet IT-Governance zuzuordnen. Aus diesem noch
sehr jungen Forschungsgebiet wurden zu Beginn des Promotionsprojekts die in der
Praxis entstandenen Best-Practice-Referenzmodelle (BPRM) als Schwerpunkt der
vorliegenden Arbeit ausgewählt. Grund für diese Entscheidung war, dass diese Modelle
bis dahin zwar kaum wissenschaftlich untersucht wurden, aber dennoch – nach Ansicht
der Verfasserin – konsolidiertes Erfahrungswissen enthalten, welches wissenschaftlich
genutzt werden sollte. Zusätzlich zum wissenschaftlichen Nutzen bietet ein
systematischer Einsatz von BPRM in der Praxis die Möglichkeit, Ineffizienzen zu
beseitigen und so ökonomische Potentiale zu realisieren.
Bezogen auf den Ordnungsrahmen nach Hevner et al. 2004 war es Ziel dieser Arbeit,
sowohl die Praxis als auch die Wissenschaft zu unterstützen. Daher wird nachfolgend
kurz auf die wichtigsten Implikationen für Praxis und Wissenschaft eingegangen.
Die im Rahmen der Arbeit entwickelten Metamodelle können in der Praxis den Einstieg
in die Anwendung eines BPRM erleichtern. Unternehmen, die ein bestimmtes BPRM
einsetzen wollen, können die entwickelten Metamodelle nutzen, um allen betroffenen
Mitarbeitern die Struktur des Modells zu verdeutlichen. Auf diese Weise bilden die
Metamodelle außerdem die Grundlage für eine gemeinsame, unternehmensweite
Terminologie (siehe Teil B). Weiterhin kann der entwickelte Ordnungsrahmen
verwendet werden, um das Verständnis der BPRM-Anwendung im Unternehmen zu
vereinheitlichen (siehe Teil C). Zudem ermöglicht eine strukturierte, auf
wissenschaftlichen Erkenntnissen basierende Anpassung und Anwendung von BPRM
(siehe Teil D), Ineffizienzen zu beheben. Die Umsetzung von Methodenkomponenten
im SemGoRiCo-Projekt unterstützt eine solche strukturierte Anwendung zusätzlich
(siehe Teil D).
Aus wissenschaftlicher Perspektive wurde zunächst der Begriff BPRM thematisiert
(siehe Teil A). In einem zweiten Schritt konnte gezeigt werden, dass die in der Praxis
entwickelten BPRM grundsätzlich für die Forschung genutzt werden können. Zuvor
empfiehlt sich jedoch eine Aufarbeitung der Modellstrukturen. Hierfür bietet die
Metamodellierung wichtige Mechanismen und Hinweise (siehe Teil B).
Aufbauend auf den Erkenntnissen aus den Teilen A und B wurden im Folgenden
allgemeingültige Erkenntnisse bezüglich der Anpassung und Anwendung von BPRM
erzielt (siehe Teile C, D und F) sowie generell einsetzbare Methoden entwickelt (siehe
insbesondere Teil D).
Für die Methodenkonstruktion wurden bereits vorhandenen Erkenntnisse aus den
Forschungsgebieten Methoden-Engineering und Referenzmodellierung verwendet
283
(siehe Teil D). Eine Erweiterung der Methodenkonstruktion um eine empirische
Komponente erscheint jedoch sinnvoll (siehe Teil E).
Zusammenfassend kann festgehalten werden, dass das Ziel des Promotionsvorhabens –
die Verbesserung der Wissensbasis der IT-Governance-Forschung für den Teilbereich
Best-Practice-Referenzmodelle – erreicht wurde. Dennoch ergibt sich auf Basis der
erzielten Ergebnisse weiterer Forschungsbedarf.
Für eine anwendungsorientierte Wissenschaft wie die Wirtschaftsinformatik erscheint es
zweckmäßig, ihre Gestaltungsziele an der Praxis auszurichten. Ein erster Ansatzpunkt
für weitere Forschungsbemühungen sollte daher die quantitativ-empirische Erhebung
der realen Anwendungsformen von BPRM sein. Eine solche Untersuchung ermöglicht
eine zielgerichtetere Unterstützung der Praxis. Die Methodenkonstruktion und die
Entwicklung von Werkzeugunterstützung könnten auf der Grundlage dieser empirischen
Daten auf die häufigsten Anwendungsformen fokussiert werden. Die Basis für eine
solche quantitative Studie bietet der in dieser Arbeit entwickelte Ordnungsrahmen der
Anwendung von BPRM.
Weiterhin könnten die Erkenntnisse hinsichtlich der methodischen Unterstützung der
Anpassung und Anwendung von BPRM um Aspekte des Projektmanagements erweitert
werden. Durch eine solche Erweiterung lassen sich die Methoden zur Anpassung und
Anwendung von BPRM besser in der Praxis einsetzen.
Beide Ansatzpunkte für weitere Forschung würden weitere Erkenntnisse im Bereich
Best-Practice-Referenzmodelle der IT-Governance liefern und somit die im Rahmen der
vorliegenden Arbeit gewonnenen Ergebnisse ergänzen.
284
Anhang A: Lebenslauf
Persönliche Daten
Name:
Geboren:
E-Mail:
Stefanie Looso, geb. Alter
20.01.1982
Stefanie_Looso@web.de
Werdegang
05/2007-06/2010:
Wissenschaftliche Mitarbeiterin
an der Frankfurt School of Finance & Management
10/2001-04/2007:
Studium der Betriebswirtschaft
an der Philipps-Universität Marburg
07/1992-07/2001:
Allgemeine Hochschulreife
an der Ursulinenschule Fritzlar
ix
Anhang B: Vollständiges Publikationsverzeichnis
(Eingerahmte Publikationen sind Bestandteil der vorliegenden Dissertation.)
2008
Veröffentlicht in: Proceedings of the 2008 International Conference on
e-Learning, e-Business, Enterprise Information Systems, and e-Government (EEE
2008), Las Vegas, Nevada, 14.-17.07.2008.
Titel: IT Governance Frameworks as Methods
Veröffentlicht in: Proceedings of the 10th International Conference on Enterprise
Information Systems (ICEIS 2008). Barcelona, Spain, 12.- 16.06.2008.
2009
Titel:
Operationalisierung
der
IT-Governance-Kernbereiche
für
die
Identifizierung und Gestaltung von Services
Autoren: Stefanie Alter, René Börner, Matthias Goeken
S. 3660-3674, Fischer, Stefan; Maehle, Erik; Reischuk, Rüdiger.
x
Anwendung
Autoren: Matthias Goeken, Stefanie Alter, Danijel Milicevic, Janusch Patas
Fischer, Stefan; Maehle, Erik; Reischuk, Rüdiger.
Titel: Konzeptionelle Metamodelle von IT-Governance Referenzmodellen als Basis
der Kombination und Integration in einer Multi-Modell-Umgebung
Veröffentlicht in: Hansen, Karagiannis, Fill, (Hrsg.) Business Services: Konzepte,
Technologien, Anwendungen. 9. Internationale Tagung Wirtschaftsinformatik, Band 1,
Wien, Österreich, 25.-27.02.2009.
Titel: Towards Conceptual Metamodeling of IT Governance Frameworks
Approach - Use - Benefits
Sciences (HICSS 2009), Big Island, Hawaii, USA, 05.-08.01.2009.
2010
Systems (ECIS 2010), Pretoria, South Africa, 06.-09.07.2010.
xi
Titel: IT-Management mit Hilfe von Best-Practice-Referenzmodellen
Autor: Stefanie Alter
Veröffentlicht in: GWDG-Bericht 2009, Göttingen, 2010.
Titel: Comparison and Integration of IT Governance Frameworks to support IT
Management
Autoren: Stefanie Looso, Matthias Goeken, Wolfgang Johannsen
Veröffentlicht in: Praeg, Späth (Hrsg.) Quality Quality management for IT services,
Perspectives on business and process performance, Hershey, PA: IGI Global, 2010.
Titel: Towards a structured application of IT governance best practice reference
models
Veröffentlicht in: Proceedings of the 16th Americas Conference on Information
Systems (AMCIS 2010), 12.-15.08.2010, Lima, Peru.
Titel: A generic method for best practice reference model application
Veröffentlicht in: Proceedings of the 12th International Conference on Enterprise
Information Systems (ICEIS 2010), 08.-12.06.2010, Funchal, Madeira, Portugal.
Veröffentlicht in: Proceedings der Informatik 2010, Lecture Notes in Informatics (LNI).
xii
2011
Titel: Best Practice
Autoren: Kurt Glasner, Stefanie Looso
Veröffentlicht in: Fröschle, Kütz (Hg.): Lexikon IT-Management: Symposion
Publishing, S. 41–44.
Autoren: Stefanie Looso, René Börner, Matthias Goeken
Challenges in Information Science (RCIS 2011).
Ranking: B-Konferenz
xiii

Best-Practice-Referenzmodelle der IT

Transcription

Similar documents

IT-Risiken - uDoo-Logo (Link zur uDoo-Startseite)

cooperative learning (Green)

300 KB - Cuvillier Verlag

Bausteine - Koordinierungsstelle Schuldnerberatung in Schleswig

Methodenbewertung mittels Quality Function Deployment

Business Intelligence im Spannungsfeld von - CEUR

25. DV-Treffen der Max-Planck-Institute

Multikonferenz Wirtschaftsinformatik (MKWI) 2016