Methodenwissen ist ein wesentliches Erfolgskriterium für das Gelingen von Planung, Erstellung und Betrieb von IT-Systemen. Während viel Aufwand und Dokumentation in die Beschreibung und den Vergleich der IT-Systeme selber fließt – man denke nur an die vielen internen und öffentlichen Tests und Merkmalvergleiche vor und nach einer neuen Produkteinführung – ist es schwieriger und auch weniger üblich, Methoden zu vergleichen. Das liegt auch daran, dass es nur wenige Ansätze gibt, Methoden systematisch zu vergleichen, die Vor- und Nachteile explizit zu machen und den erzielten Fortschritt bei der Vorstellung einer neuen Methode transparent zu machen. In diesem Artikel wird ein Methodencanvas vorgeschlagen, um diese Defizite zu beseitigen. Der Ansatz ist aus der Wissenschaft zu Designtheorien hergeleitet, macht die Struktur einer Methode deutlich und wann und wo eine Methode eingesetzt werden kann. Methoden werden vergleichbar und ihr Nutzen deutlich.
Methoden in der (Wirtschafts‑)Informatik stellen einen Ansatz dar, um IT-Systeme zu planen, zu entwickeln und zu betreiben. Sie basieren auf einer bestimmten Art zu denken, beinhalten Anweisungen, Aktivitäten, Rollen und Regeln, um ein bestimmtes Ziel zu erreichen. Das Formulieren von Methoden im IT-Kontext hat eine lange Tradition und es hat sich somit eine sehr große Vielfalt in der Art der Dokumentation gebildet. Normierend wirkt hier einerseits zum Beispiel ein an der Universität St. Gallen entwickeltes und vielfach wiederverwendetes Metamodell [1], demgemäß eine Methode durch Aktivitäten, Rollen, Werkzeuge, Arbeitstechniken, Ergebnisse und deren Beziehungen untereinander beschrieben wird. Nach dieser Definition ist ein Prozessmodell, nämlich die sequenzielle Anordnung von Aktivitäten, übrigens Teil einer Methode und das Methodenverständnis dieses Artikels orientiert sich an dieser Sichtweise. Jedoch gibt es keine ausreichende Darstellung zum übersichtlichen Vergleich ausformulierter Methoden, die sich über den Vorschlag solcher Konstrukte hinaus beschäftigt.
Advertisement
Canvas-Mania
Die Konstruktion einer Methode ist ein gestalterischer Akt im Sinne eines ingenieurgemäßen Designs zur Erstellung eines Artefaktes. In letzter Zeit hat sich ein Trend zur übersichtlichen Darstellung von komplexen Designs auf einem Poster oder einer Leinwand durchgesetzt, einem sogenannten Canvas. Der bekannteste Vertreter ist Osterwalders Business Modelling Canvas (BMC) [2], der vertretbarerweise auch als Auslöser einer wahrhaftigen „Canvas-Mania“ zur Erstellung von sinnvollen und oft auch weniger sinnvollen Canvases für allerlei Aufgabenstellungen angesehen werden kann. Genauso wie der BMC, der sich auf eine wissenschaftlich hergeleitete Identifizierung von Ontologien für Geschäftsmodelle bezieht, verweist auch das hier vorgestellte Methodencanvas auf eine gehaltvolle Fundierung aus der Wissenschaft.
Canvases eignen sich einerseits sehr gut für die Analyse und übersichtliche Darstellung bestehender Sachverhalte. Dadurch, dass auf einem Poster nur begrenzt Platz ist, ist es notwendig, die Schlüsselerkenntnisse und -begriffe zu identifizieren und in den zugehörigen Feldern einzutragen. Selbstverständlich muss zu einer vollständigen Beschreibung eines Geschäftsmodells oder einer Methode auf umfangreiche Anlagen und Anhänge verwiesen werden. Jedoch wird durch eine geübte Anwendung von Canvases die Identifizierung und schlagwortartige Benennung der wesentlichen Merkmale geschult und systematisiert.
Andererseits ist ein Canvas für das leichtgewichtige Design, also die Erstellung eines neuen Artefakts, wie z. B. eines Geschäftsmodells oder wie hier eines IT-Artefakts vom Typus einer Methode, äußerst hilfreich. Es können also zunächst die wichtigsten Merkmale auf Überschriftenebene eingegeben werden. In der Folge können diese Merkmale im Rahmen eines iterativen, agilen Ansatzes schnell wieder verändert werden, bevor die aufwendigen Anhänge erst erstellt werden müssen. Diese Möglichkeit des schnellen Pivotings hat sich in der schnelllebigen Zeit des Internets und der einhergehenden Digitalisierung als großer Erfolgsfaktor erwiesen.
Fundierung über Designtheorien: aus der Forschung für die Praxis
Doch wie beschreibt man am besten ein Design? Ein Problem ist, dass Designartefakte so unterschiedlich sein können, dass sie bei herkömmlicher Beschreibung nicht direkt vergleichbar sind und somit deren Vorteile und der genaue Zweck eines bestimmten Methodendesigns nicht ohne Weiteres explizit gemacht werden können. Zudem bleibt zumeist unklar, wie das Methodenartefakt evaluiert werden kann, um den Vorteil zu überprüfen.
Advertisement
In der Wissenschaft wird eine Wissensbasis mit Voraussagen, Modellen und Frameworks mit dem Begriff „Theorie“ zusammengefasst. Gregor und Jones [3] haben sich mit der Beschreibung von Designs anhand solcher Designtheorien befasst und acht generische Komponenten zur Dokumentation identifiziert: Verwendungszweck und Geltungsbereich (Purpose and Scope), Konstrukte (Constructs), Form- und Funktionsprinzipien (Principles of Form and Function), Veränderlichkeit des Artefakts (Artifact Mutability), nachprüfbare Aussagen (Testable Propositions), rechtfertigendes Wissen (Justificatory Knowledge), Umsetzungshinweise (Principles of Implementation) und beispielhafte Instanziierung (Expository Instantiation). Nachdem diese Grundlagenarbeit zunächst abstrakt und artefaktunabhängig geliefert wurde, haben wir uns Gedanken darüber gemacht, wie dieser Vorschlag für konkrete IT-Artefakte weiter verfeinert und praxistauglich gemacht werden kann [4]. Dieser Artikel stellt das Ergebnis für den Artefakt-Typus „Methode“ vor. Der Ansatz hat nicht den Anspruch, eine vollständige Ontologie für Methoden zu erarbeiten. Vielmehr werden die wesentlichen, praxisnahen Ontologiemerkmale anhand der Komponenten der Designtheorien strukturiert und davon abgeleitet. Der Vorteil ist, dass hierdurch systematisch wiederanwendbares Wissen für Methodendesigntheorien aufgebaut wird.
Vorstellung der Canvas-Felder für Methoden
Die Felder des Methodencanvas sind den oben genannten Komponenten zugeordnet. Der eigentliche Innovationshub des Beitrages ist die Anleitung, wie diese Felder zur Beschreibung von Methoden ausgefüllt werden sollen. Im Folgenden werden die einzelnen Felder des Canvas vorgestellt. Zu jedem Feld wird ein Beispiel angegeben. Für dieses Beispiel wurde als Methode die ISSEM (Innovation Service System Engineering Method) gewählt, die auf einer Generalisierung des Innovationsframeworks der Deutsche Telekom Laboratories (T-Labs) in Berlin beruht [5]. Analog lassen sich durch das Canvas typische IT-Methoden beschreiben. Die Beispiele beziehen sich auf mögliche Einträge in den einzelnen Feldern, stellen aber in Summe nicht die finale Beschreibung der Methode im Canvas dar.
Verwendungszweck und Geltungsbereich
Jede Methode wird in Hinsicht auf einen Nutzen konstruiert und diese Komponente spiegelt dies wider. Der Geltungsbereich definiert die Auswahl der Situationen, in welchen das Artefakt zweckgemäß benutzt werden kann, um die angegebenen Ziele zu erreichen. Diese Komponente erlaubt Kategorisierung, Vergleich und Erweiterung der betrachteten Theorie.
Aussagen über den Verwendungszweck von Methoden enthalten drei Elemente: die Art des Ergebnisses, das die Ausführung einer Methodeninstanz produzieren soll, Eigenschaften des Ergebnisses sowie qualitative und quantitative Aussagen über die Methode selbst (z. B. über ihre Effizienz). Bei der Ausgestaltung dieser Komponente müssen die Projektart und der Projektkontext festgelegt sowie die Rollen und Aktivitäten beschrieben werden. Ebenso ist eine Ausführung zur Lebenszyklusabdeckung sinnvoll. Die Lebenszyklusabdeckung beschreibt, für welche allgemeinen Phasen die Methode Richtlinien anbietet. Eine Rollenabdeckung beschreibt die Rollen, die durch die Methode adressiert werden und die Aktivitätsabdeckung listet die Aktivitäten auf, die zur Anwendung in einem auf der Methode basierenden Projekt zur Verfügung stehen.
Ein gut definierter Geltungsbereich verbessert besonders die Vergleichbarkeit von Methoden. Für die Evaluation der Komponente sollte geprüft werden, ob der Verwendungszweck so formuliert ist, dass das zu lösende Problem klar wird und man auch feststellen kann, ob das Problem durch Einsatz der Methode gelöst werden kann. Ebenso muss das Ergebnis geklärt sein, das die Methode liefert. Der Geltungsbereich sollte so beschrieben sein, dass man feststellen kann, dass der Projektkontext hineinfällt. Es sollten Lebenszyklusphasen, Rollen und Aktivitäten spezifiziert sein.
Beispiel
Die Innovationsmethode ISSEM verweist auf den Projekttypus zum Durchführen von Innovationsprojekten unter Erfüllung festgelegter organisatorischer und wirtschaftlicher Qualitätskriterien und ebenso die eingebettete Ermöglichung zum Durchlauf eines Design-Science-Forschungsprozesses. Der Projektkontext ist gegeben durch ein Innovationlab, das Innovationsprototypen entwickelt und zur weiteren Produktisierung an Geschäftseinheiten übergibt. Der durch die Methode abgedeckte Lebenszyklus beginnt mit der Ideengenerierung über Projektstart und Prototypenentwicklung. Die Rollen sind definiert als Innovation Project Manager, Design Science Researcher, Domain Expert und Decision Maker. Die Aktivitäten sind über Projektphasen definiert als Project Identification, Project Scheme, Project Plan, Project Execution und Project Transfer. Eine weitere Detaillierung der Phasen in konkrete Aktivitätenbeschreibungen ist möglich, auf dieser Aggregationsebene jedoch nicht angestrebt.
Konstrukte
Konstrukte sind formale Beschreibungen in Wörtern, mathematischen Symbolen oder Diagrammen. Beispiele sind Metamodelle oder beschreibende Diagramme. Es existieren mehrere Metamodelle für Methoden und in den meisten Fällen ist es am besten und auch am pragmatischsten, eine Methode entsprechend eines existierenden Metamodells aufzubauen. Andere Konstrukte können aus dem Ergebnis oder dem Anwendungsbereich der Methode stammen, zum Beispiel Unified Modeling Language(UML)- oder -Prozessablaufdiagramme. Ebenso sollten Konstrukte des Methodenerzeugnisses oder etwa Konzepte aus dem Anwendungsbereich für diese Komponente aufgeführt werden bzw. auf weitere Dokumentation referenziert werden.
Bei der Aufführung der Konstrukte sollte unter anderem darauf geachtet werden, dass Begriffe und Konzepte präsentiert werden, die die Methode und ihre Erzeugnisse strukturiert beschreiben und systematisch hergeleitet sind.
Die resultierende Beschreibung der Konstrukte erhöht die Vergleichbarkeit auf Symbolebene und somit die Formalisierung der entwickelten Methode.
Beispiel
Die Innovationmethode ISSEM verwendet die Erweiterung des oben schon angesprochenen St. Galler Metamodells für situative Methodenkonstruktion. Die oben unter Verwendungszweck und Geltungsbereich beschriebenen Aktivitäten und Rollen werden durch die Konstrukte des implementierten Idea-to-Launch-Prozessmodells bzw. des gewählten Design-Science-Forschungsprozesses beschrieben und in eine Ablaufreihenfolge gebracht.
Form- und Funktionsprinzipien
Form- und Funktionsprinzipien beschreiben Struktur, Organisation und Funktionsweise einer Methode. Sie stellen eine abstrakte Blaupause oder Architektur (z. B. Unternehmensarchitektur oder Softwarearchitektur) des Methodenartefakts dar.
Die Methode soll hier allgemein beschrieben werden und entsprechend dem spezifischen Bedarf entweder adaptiert oder zusammengesetzt werden. Die allgemeine Methode stellt eine Obermenge an individuellen Lösungen dar, ähnlich der Unterscheidung zwischen Architektur und detailliertem Design. Trotzdem ist es für die Form- und Funktionsprinzipien notwendig, dass jedes Element einer Methode (z. B. Rolle, Aktivität, Phase), wie durch das für die internen Konstrukte gewählte Metamodell definiert, zusammen mit allen Beziehungen zwischen den Elementen beschrieben wird.
Umfassende Beschreibungen von Form- und Funktionsprinzipien einer Methode erstrecken sich oft über viele Seiten. Es muss darauf geachtet werden, dass die Methodenbeschreibung ausführlich genug ist, um sie anwendbar und transferierbar zu machen. Es sollte gemeinsam mit den oben ausgeführten Komponenten für jede Rolle klargestellt sein, welche Aktivitäten sie ausführt.
Beispiel
Die Methode ISSEM wird in [5] skizziert und bezieht sich darüber hinaus auf weitere praxisnahe Beschreibungen in Veröffentlichungen z. B. in Buchform, deren ausführliche Zusammenfassung diese Artikelform nicht zulässt. Es gibt insbesondere Hinweise zur Gestaltung von Abstimmungs-Gates gemäß der Bedarfe in der einführenden Organisation, zur Gewichtung von divergenten vs. konvergenten Durchführungs- und Entscheidungskriterien sowie Ablaufvarianten je nach Projektform.
Veränderlichkeit des Artefakts
Jedes Artefakt ändert sich mit der Zeit und diese Änderungen sollten in einem bestimmten Umfang bereits während der Konstruktion vorweggenommen werden. Dies gilt ebenso für situatives Tailoring auf ein bestimmtes Einsatzgebiet, d. h. nicht die Änderung der Methode selbst, sondern der Ablauf in vorhergesehenen Varianten.
Somit müssen antizipierbare Änderungen beschrieben werden, welcher Teil der Methode wann und in welcher Art geändert ablaufen kann. Im Falle einer Beschreibung eines situativen Methodenartefakts wird die Änderungsunterstützung durch die Methodenspezifikation (z. B. im situativen Metamodell) gleich mitgeliefert.
Die Methode muss hier ausführlich genug beschrieben sein, um das Funktionsprinzips jedes Methodenteils zu verstehen und die Voraussetzung für die Änderung zu erkennen. Dabei muss auch klar sein, welche Methodenteile sich ändern und die Mechanismen der Anpassung müssen aufgeführt sein.
Beispiel
Für die Innovationsmethode ISSEM ist ein situatives Tailoring für Einsätze in der Telekommunikationsbranche vorgesehen und es sind ähnliche Adaptionen für andere Branchen vorgesehen. Ebenso kann die Anzahl und Ausgestaltung der Entscheidungs-Gates im Prozess angepasst werden. Des Weiteren werden Hinweise gegeben, wie der Prozess alternativ z. B. mit neuen disruptiven Geschäftsideen geändert werden kann.
Nachprüfbare Aussagen
Dies sind Aussagen über die Theorie, die nachgewiesen oder falsifiziert werden können. Für umfassende Richtlinien bezüglich nachprüfbarer Aussagen muss geklärt werden, worüber die Aussagen gemacht werden (die Methode selbst oder die erarbeiteten Ergebnisse?) und was durch die Aussage zugesichert wird: „Nutzen“ oder „Korrektheit“ (Letzteres in Bezug auf die Umsetzung der Anforderungen durch das Design).
Besonders wichtig ist die Überprüfung des angenommenen Nutzens: Wenn die vorgeschlagene Lösung das Problem, für das sie entworfen wurde, nicht löst, oder wenn sie nicht besser ist als bekannte Ansätze, ist der Beitrag nicht signifikant. Diesbezüglich müssen nachprüfbare Nutzenaussagen formuliert werden und ggf. auch nachprüfbare Korrektheitsaussagen.
Die nachprüfbaren Aussagen sollten im Wesentlichen vom Autor der Methode kommen, jedoch können diese auch von außerhalb ergänzt werden, da der Autor ggf. nicht all möglichen Aussagen angeben kann und sollte.
Beispiel
Für die ISSEM wurde eine überprüfbare Nützlichkeitsaussage entworfen: Liefert die Methode neuartige Prototypen oder andere IT-Artefakte mit einem positiven Geschäftsmodell oder anders quantifizierbaren Impact? Können diese Artefakte in produktives Geschäft überführt werden? Ebenso kann die Korrektheit des Methodenoutputs überprüft werden, indem getestet wird, ob dieser den Spezifikationen entspricht.
Rechtfertigendes Wissen
Hier können Theorien aus Natur‑, Betriebs‑, Sozial- und Ingenieurwissenschaften als mögliches zusätzliches rechtfertigendes Wissen geschöpft werden. Ebenso bisher kumuliertes und dokumentiertes Wissen aus den Gestaltungswissenschaften über Designtheorien. Jede Form der Rationalisierung auf Basis von bereits bestehender Erkenntnis kann hier aufgeführt werden. Die verschiedenen Aspekte der Designtheorie, d. h. die Methode selbst, das Produkt und der Anwendungsbereich, bieten mögliche Ansatzpunkte für unterstützende Theorien. Die Auswahl von möglichen Theorien ist stark von der Situation abhängig und kann nicht vereinheitlicht werden.
Überprüft werden sollte, ob Theorien für wichtige Methodeneigenschaften dargestellt sind, die nicht durch nachprüfbare Aussagen abgedeckt werden. Und umgekehrt: Sind nur Theorien dargestellt, die die nachprüfbaren Aussagen unterstützen?
Beispiel
Die ISSEM beruft sich auf die Wissensbasis des Innovationsmanagements, ebenso auf Designtheorien. Dazu Best-Practice-Beispiele aus 50 Durchläufen für Innovationsvorhaben.
Umsetzungshinweise
Sie beziehen sich auf den Prozess und die Mittel, die zur Umsetzung des Designs verwendet werden. Die Implementierung einer Methode bedeutet, ein generisches Methodendesign für eine spezifische Situation umzusetzen. Das beinhaltet zwei Aspekte: die Anpassung einer allgemeinen Methode auf eine spezifische Situation und das Einführen einer angepassten Methode in eine Organisation, die mit dieser Methode arbeiten soll.
Der erste Punkt ist eng mit der Anpassung in der situativen Methodenkonstruktion verbunden. Hinweise zum Prozess, wie und wo eine Methode geändert werden kann, können zu den Umsetzungshinweisen hinzugezählt werden. Der zweite Punkt beinhaltet eine Menge an Aspekten, von Schulungen für potenzielle Methodenbenutzer über die Einführung von Werkzeugunterstützung bis hin zur Änderung von organisatorischen Richtlinien. Beide Punkte können optional in Methodendesigntheorien angeboten werden. Im Fall von situativer Methodenkonstruktion sind Hinweise zur Anpassung obligatorisch.
Es muss darauf geachtet werden, dass die Hinweise zur Anpassung ausreichend sind bezüglich der Implementierungsvarianten. Ebenso müssen die Hinweise zur Methodeneinführung die verschiedenen Kontexte innerhalb des Geltungsbereichs beinhalten bzw. muss es klar sein, auf welchen Kontext sich die Hinweise beziehen.
Beispiel
Für die Umsetzung der ISSEM ist die Existenz eines Innovationszentrums notwendig, das Leistungen an abnehmende Produktbereiche oder externe Firmen (Kunden) gibt. Die Schnittstellen und Übergabepunkte der Produkte der Methode sind auf diese Art von Arbeitsteilung ausgelegt.
Beispielhafte Instanziierung
Eine beispielhafte Instanziierung ist eine reale, beispielhafte Anwendung der Methode. Für Methoden bedeutet dies einen Bericht über die Ausführung einer so abgeleiteten spezifischen Methode im Kontext und der Situation, für die die Methode konzipiert wurde.
Beispiel
Die ISSEM wurde ursprünglich für die Deutsche Telekom Innovation Laboratories (T-Labs) eingerichtet und für über 50 Innovationsprojekte angewendet. Ebenso wurde sie unter anderem auch für den deutschen Ableger des European Institute of Innovation and Technology verwendet.
Use Case: Method Factory
Die folgende Übersicht (Tab. 1) zeigt die Erkenntnisse zu den vorgestellten acht Komponenten in einem Canvas-Template in Form von Ausfüllungshinweisen auf Basis von [4]. Die vorgestellte Arbeit wurde im Rahmen des Aufbaus einer „Method Factory“ getätigt. Aufgabe dieser Method Factory ist die Bereitstellung bestmöglicher Methoden zu gegebenen Anforderungen. Der Ursprung liegt im weiter oben beschriebenen Innovationszentrum, das neben ablauffähigen IT-Systemen auch innovative Methodenartefakte erstellt. Vor der Notwendigkeit zur Neuerstellung einer Methode muss zunächst der State of the Art mit verfügbaren Methoden z. B. aus der Literatur festgestellt werden und im Anschluss die Entscheidung bezüglich einer Wiederverwendung oder Weiterentwicklung/Tailoring bestehender Methoden beziehungsweise einer kompletten Neuentwicklung vorgenommen werden. Für das Assessment der Reife und die Übereinstimmung mit Requirements bietet sich das obige Schema in Form eines Canvas an. Die Method Factory muss entsprechend über Kompetenzen in der situativen Methodenkonstruktion und -beschreibung verfügen. Ebenso müssen die Mitarbeiter gängige Ansätze zu Methodenassessment, Tailoring, Evaluierung und Feststellung des Reifegrades von Methoden beherrschen und gegebenenfalls weiterentwickeln können.
Tab. 1
Template mit Ausfüllhinweisen für das Methodencanvas
Methodencanvas: <Name der Methode> | |
Verwendungszweck und Geltungsbereich – Projektart – Projektkontext – Abdeckung des Lebenszyklus, der Rollen, der Aktivitäten Evaluationskriterien: Gegeben ein Problem, ist der Verwendungszweck so beschrieben, dass man feststellen kann, ob das Problem gelöst wird? Ist das Produkt der Methode klar? Gegeben ein Problemkontext, ist der Geltungsbereich in einer Art beschrieben, dass man feststellen kann, ob der Kontext in den Geltungsbereich fällt? Sind für den Geltungsbereich alle relevanten Dimensionen beschrieben? Sind die abgedeckten Lebenszyklusphasen, Rollen und Aktivitäten spezifiziert? | |
Konstrukte – Methodenspezifische Konstrukte (z. B. durch ein Metamodell definiert) – Konstrukte des Methodenerzeugnisses – Konzepte aus dem Anwendungsbereich Evaluationskriterien: Sind Begriffe und Konzepte präsentiert um: … die Methode zu beschreiben? … die erzeugte Struktur zu beschreiben? … den Anwendungsbereich zu beschreiben? … Verwendungszweck und Geltungsbereich zu beschreiben? … nachprüfbare Aussagen aufzustellen? Sind die Konzepte umfassend an einer Stelle eingeführt und systematisch hergeleitet? | Nachprüfbare Aussagen – Angenommener Nutzen der Methode – Optional: Aussage über das Zusammenspiel des Methodendesigns und Anforderungen des Methodenerzeugnisses Evaluationskriterien: Werden nachprüfbare Aussagen bezüglich des Nutzens der Methode angegeben? Sind die Aussagen hinreichend gut operationalisiert, sodass sie von anderen Wissenschaftlern überprüft werden können? |
Form- und Funktionsprinzipien – Beschreibung der Methode (entsprechend des oben ausgewählten Metamodells) Evaluationskriterien: Ist die Methodenbeschreibung ausführlich genug, um sie anwendbar und transferierbar zu machen? Ist für jede mögliche Rolle klar, welche Aktivitäten in welcher Reihenfolge ausgeführt werden müssen? | Rechtfertigendes Wissen – Designtheorien, auf denen diese Methode basiert – Theorien über den Anwendungsbereich – Andere interessante Aspekte Evaluationskriterien: Sind Theorien dargestellt: … für wichtige Methodeneigenschaften, die nicht durch nachprüfbare Aussagen abgedeckt werden? … um die nachprüfbaren Aussagen zu unterstützen? … bezüglich des Methodenerzeugnisses? … bezüglich des Kontexts der Methode? |
Veränderlichkeit des Artefaktes – Vorhersehbare Änderungen (welcher Teil der Methode, Methodenbasis oder Methodeninstanz, Art der Änderung) – Optional: Durch das Methodendesignparadigma bereitgestellte Änderungsunterstützung (z. B. situativ, methodenbegründend) Evaluationskriterien: Ist die Methode ausführlich genug beschrieben, um das Funktionsprinzip jeder Komponente zu verstehen? Sind Voraussetzungen für Änderungen beschrieben? Wird klar, welche Teile sich worin ändern? Sind Mechanismen zur Methodenanpassung definiert? | Umsetzungshinweise – Hinweise zur Anpassung/Zusammenstellung – Hinweise bezüglich der Einführung in einem realen Kontext Evaluationskriterien: Sind die Hinweise zur Anpassung/Zusammenstellung ausreichend bezüglich der kombinatorischen Möglichkeiten? Beinhalten die Hinweise zur Methodeneinführung verschiedene Kontexte innerhalb des Geltungsbereichs, oder ist wenigstens klar auf welchen Kontext sich die Hinweise beziehen? |
Beispielhafte Instanziierung – (Fiktives) Beispiel einer Methodeninstanziierung – Bericht über eine reale Fallstudie, in der eine Methodeninstanz erzeugt wurde Evaluationskriterien: Deckt das Beispiel einen Fall innerhalb des Geltungsbereichs ab und beinhaltet es die wichtigsten Konzepte der Methode? Ist das Beispiel spezifisch genug, um hilfreich zu sein, aber nicht so detailliert, dass es unverständlich wird? | |
Insbesondere ist die Erarbeitung eines übersichtlichen Methodenkatalogs und der Kategorisierung bestehender Methoden durch das vorgestellte Verfahren anhand von Canvases übersichtlich möglich geworden und vereinfacht die Wiederverwendung von Methodenteilen. Durch die nun verbesserte Vergleichbarkeit lässt sich der Match oder der Gap zu den eigenen Bedarfen klarer darstellen. Der Innovationshub durch die eigenen Neuentwicklungen wird transparent dargestellt. Die Erstellung und Fortführung des Methodenkatalogs kann das Wissen der Community durch Fortschreibung von Designtheorien bewerkstelligen und somit sind trotz der grundsätzlich praktischen Ausrichtung nun auch parallel stringente wissenschaftliche Arbeiten zum Thema Methoden möglich geworden.
Beispiele für IT-Methodenartefakte in diesem Zusammenhang waren in der Vergangenheit: Model-based UML Testing, Cloud Service Engineering, IT-Governance and -Management, Enterprise Architecture Management, Architekturentwicklung (SOA-/Microservices-Development), Business Process Management, Infrastructure Management, Virtualized Developing and Testing Environment, Cloud Service Engineering, IT Risk Management, SOA Governance, SOA Lifecycle Management, Agile Software Development, Developer Cloud (Development in the Cloud), Method for Architecture Transformation, Innovation Management Methods, Method Tailoring (TOGAF, RUP, SOA, eTOM, ITIL, SPICE, CMMI, CoBIT …). Interessanterweise sind alle oben aufgelisteten Methodenartefakte ihrerseits Ergebnisse der Innovationsmethode ISSEM.
Aktuelle Themen sind Methoden zur Erstellung von KI-Systemen oder Cloud-Native-Migrationen.
Fazit
Beim vorgestellten Canvas handelt es sich um eine leichtgewichtige und übersichtliche Beschreibung von Methoden.
Es bietet sich an zur strukturierten Dokumentation und Analyse zum Vergleich von bestehenden Methoden. Da die Struktur von Designtheorien hergeleitet ist, kann es in gleicher Weise zum Aufbau von Methodenwissen, z. B. in Form eines Methodenkatalogs, eingesetzt werden.
Ein weiterer wichtiger Aspekt ist, dass die Wiederverwendung oder die komplette Neuerstellung von Methoden durch das Canvas angeleitet werden können und das Canvas somit die Grundlage einer innovativen Method Factory darstellt.
Zusammenfassung
-
Die Vergleichbarkeit von Methoden ist wegen der Vielschichtigkeit und Komplexität der Beschreibung dieses IT-Artefakttyps schwierig.
-
Der hier vorgestellte Canvas-Ansatz verspricht Abhilfe durch eine aus den Designwissenschaften hergeleiteten Struktur zur Analyse und Dokumentation von Methoden. Hierdurch kann der Unterschied einzelner Methoden strukturiert herausgearbeitet und transparent gemacht werden.
-
Durch Anwendung des Canvas wird der Beitrag jeder Methode zum Wissensstand klargestellt und dies dient auch als roter Faden bei der Erstellung innovativer neuer Methoden, bis hin zur Erstellung eines Methodenkatalogs.
Handlungsempfehlungen
-
Methoden strukturiert einordnen. Dadurch wird der Kern der Idee besser sichtbar und vergleichbar.
-
Aufbau eines Methodenkatalogs anhand des vorgestellten Schemas als Wissensbasis.
-
Eigene Methodenentwicklungen anhand des Canvas zunächst leichtgewichtig strukturieren, abändern und iterativ verbessern, bevor die detaillierte Ausformulierung folgt.
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
Weitere Details zur Lizenz entnehmen Sie bitte der Lizenzinformation auf http://creativecommons.org/licenses/by/4.0/deed.de.