Design Science bei der Schwester der Wirtschaftsinformatik – Teil 1

Leider ist man auch als Forscher oder Wissenschaftler vor falscher Selbsteinschätzung nicht gefeit, was dazu führen kann, dass man sich über- oder unterschätzt. Dies kann wiederum bedeuten, dass man bei Überschätzung etwas als Forschungsbeitrag postuliert, was bestenfalls eine Beratungstätigkeit oder argumentierte Ideefindung oder Ähnliches ist und bei Unterschätzung, dass man etwas nicht publiziert oder bis zum Ende verfolgt, weil man es für trivial hält.

Deshalb ist aus meiner Sicht eine Reflexion an Forschungsmethodik oder -vorgehen hilfreich, um effizienter und effektiver zu forschen und zu publizieren. Aus den oben genannten Grund habe ich mich deshalb mit zwei Artikeln zu Design Science in Information Systems (der anglo-amerikanischen Schwesterdisziplin der Wirtschaftsinformatik) beschäftigt und will nun ein paar Erkenntnisse daraus wiedergeben, die ich für die Einschätzung und Einordnung meiner Forschungsaktivitäten zukünftig nutzen möchte.

Da ich nicht zu dem Thema Design Science forschen will und die Artikel aus einem A-Journal des WKWI-Rankings entnommen sind, habe ich die in den Artikeln zitierten Quellen nicht gesichtet (Asche auf mein Haupt) und werde auch bei meinen Ausführungen nicht die Originalquellen zitieren (noch mehr Asche auf mein Haupt). Wer es also dann genauer wissen will, schaut einfach in die folgenden beiden Artikel:

Da die Ausführungen am Ende doch zu umfangreich wurden, habe ich mich entschlossen sie auf mehrere Artikel aufzuteilen. Aber genug der Vorrede und zum eigentlichen Thema:

In der Information Science (und nicht nur dort) kann man zwischen den zwei Forschungsparadigmen Behavioral Science und Design Science unterscheiden. Behavorial Science will dabei herausfinden, was wahr ist. Dagegen ist in der Design Science von Interesse, was effektiv ist. Dieser Unterschied lässt sich damit erklären, dass es bei der Behavioral Science um das Verstehen von Zusammenhängen geht. Die Fragen (und Erkenntnisse) lauten demnach

  • Was passiert derzeit?
  • Warum passiert es?
  • Vorhersage aufgrund der Erkenntnisse: Was passiert in Folge des vorherigen/aktuellen Zustandes?

Im Gegensatz dazu wird mittels Design Science etwas Künstliches geschaffen. In der Information Systems Disziplin wird ein IT-Artefakt geschaffen und evaluiert, welches

  • die Grenzen bestehender Anwendungen von IT erweitert und
  • ein (bedeutendes) Problem addressiert, welches vorher einer Lösung durch IT nicht zugänglich war.

Design Science hat als Hauptaufgaben die Beschreibung des Design-Problems und die Entwicklung und Evaluation der Lösung. Die Beschreibung des Problems erfolgt, indem (gewünschter) Soll-Zustand, (aktueller) Ist-Zustand und der Unterschied zwischen Ist und Soll beschrieben werden. Dafür können Nutzen- und statistische Entscheidungstheorie („utility and statistical decision theory“???) genutzt werden. Die Entwicklung und Evaluation der Lösung erfolgt, indem Aktionen zur Optimierung durchgeführt werden, um den Unterschied zwischen Ist und Soll zu verringern.

Herausforderung der Design Science in der Information Systems ist nun die Entwicklung und Evaluation von von IT-Artifakten, die es Managern und IT-Professionals ermöglichen,

  1. die Anforderungen an gewünschte organisationale Informationsprozesse und ihre Beziehung zu aktuellen und gewünschten Organisationssituationen zu beschreiben.
  2. Aktionen zu entwickeln, die es ermöglichen, die Anforderungen an die organisationalen Informationsprozesse umzusetzen/zu implementieren, welche zu einer Annäherung der Organisation zur gewünschten Situation führen.

Als IT-Artefakte gelten constructs, models, methods und instantiations.

  • Constructs bilden die Sprache, das Vokabular und die Konzeptualisierung mit der die Beschreibung von und Kommunikation über das Problem, die Lösung(-skomponenten), die Grenzen und Ziele des IT-Artefakts möglich ist.
  • Models benutzen constructs, um den Problem- und Lösungsraum zu beschreiben. Methods sind Algorithmen und Richtlinien, mit denen der Lösungsraum unter- bzw. durchsucht werden kann, um das Problem zu lösen und eine instantiation zu entwickeln.
  • Methods können von formalen, mathematischen Algorithmen bis hin zu informalen, textlichen Best-Practice-Beschreibungen reichen.
  • Instantiations zeigen, dass constructs, models und methods in ein IT-System umgesetzt werden können. Sie zeigen dadurch die Umsetzbarkeit und ermöglichen die Bewertung der Pass-/Einsatzfähigkeit des IT-Artefakts für seinen eigentlichen Zweck sowie in einer realen Umgebung. Jedes dieser 4 IT-Artefakte stellt einen Erweiterung des verfügbaren Wissens im Forschungsgebiet dar.
    Ein Forschungsbeitrag im Sinne des Design Science erfordert:
  1. Identifikation und klare Beschreibung eines relevanten organisationalen IT-Problems.
  2. Nachweis, dass keine adequate Lösung in der bestehenden IT-Wissensbasis existiert.
  3. Entwicklung und Präsentation eines völlig neuen IT-Artefakts, welches das Problem addressiert.
  4. Strenge Evaluation des IT-Artefakts für die Bewertung der Nützlichkeit.
  5. Artikulation des Mehrwertes zur Wissensbasis und zur Praxis.
  6. Erläuterung von Konsequenzen für das IT-Management und für die Praxis.

Soweit erstmal zum ersten Teil. Ich hoffe, ich komme zeitnah zur Fortsetzung…

P.S. Anregungen und Kommentare sind natürlich sehr Willkommen. 😉

Blogged with the Flock Browser
Advertisements

Ein Gedanke zu „Design Science bei der Schwester der Wirtschaftsinformatik – Teil 1“

  1. Um mögliche Irritationen aufgrund der fremdsprachlichen Terminologie auszuräumen:

    Das „gute alte“ Prototyp-basierte Entwicklungsvorgehen in der (deutschsprachigen) Wirtschaftsinformatik erfährt durch die „Design Science“ Diskussion eine späte Würdigung.

    Wenn wir Design Science mit „Gestaltungsorientierung“ und Behavioural Science mit „Erkenntnisorientierung“ übersetzen, dann erscheint es auf einmal wieder „wissenschaftlich legitim“,

    … auch etwas „praktisches“ zu tun (eine Lösung für ein identifiziertes, begründetes Problem zu entwickeln) und über den erzielten Mehrwert (Soll-Ist Evaluation des Ergebnisbeitrags für die Realwelt) zu reflektieren.

    In diesem Sinne ist z. B. ein Pattern Design zur mehr oder weniger natürlichsprachlichen Abbildung von Regeln/Zusammenhängen/Restriktionen bezüglich der Durchführung organisatorischer Ansätze Design Science im besten Sinne und damit als ernstzunehmender Forschungsbeitrag rehabilitiert.

    Dem Autor besten Dank für die Klarstellung.

Antworten

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s