<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Modellierung in Soziotechnischen Systemen</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Christiane Rudlof CSC Ploenzke AG Ubierstr.</institution>
          <addr-line>94 D-53173 Bonn</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Hansjürgen Paul Institut Arbeit und Technik Wissenschaftszentrum NRW Munscheidstr.</institution>
          <addr-line>14 D-45886 Gelsenkirchen</addr-line>
        </aff>
      </contrib-group>
      <abstract>
        <p>IT-Projekte scheitern selten an der Technik und meistens an den Menschen, soll heißen an den sogenannten weichen Faktoren, wie mangelnder Kommunikation, Kooperation, impliziten, d.h. nicht öffentlich transparenten Aspekten, Missachtung informeller Strukturen - und an der hohen Komplexität. Durch die Betrachtung derartiger Projekte als Teil eines soziotechnischen Systems, kann die Anzahl der Projekte, die erfolglos oder nicht zufriedenstellend vorzeitig abgebrochen werden, reduziert werden. Im ersten Teil des Beitrags wird anhand theoretischer Grundlagen der Organisationsentwicklung u.a. dargelegt, warum es um Modellierung in und nicht von soziotechnischen Systemen geht. Im zweiten Teil wird anhand einer ausgewählten Methode (UCD) die praktische Relevanz dieser Modellierungsmethodik dargelegt.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Vorbemerkung</title>
      <p>Allgemein bezeichnet man als System eine gegenüber der „Umwelt“ abgegrenzte
Gesamtheit von Elementen, zwischen denen Beziehungen bestehen. Durch diese Beziehungen
und die Abgrenzung zur Umwelt – aber auch zu anderen Systemen – kann ein System als
Einheit behandelt werden, z.B. eine Maschine, eine Organisation, eine Institution. Eine
(Arbeits-)Organisation wird aufgrund ihrer sozialen und technischen Elemente als
„soziotechnisches System“, eine Maschine aus den gleichen Gründen als „technisches System“
bezeichnet.</p>
      <sec id="sec-1-1">
        <title>2.1 Das technische System</title>
        <p>Technische Systeme sind Systeme, die in erster Linie durch ihren Zweck charakterisiert
sind und zu deren definierenden Elementen keine Menschen, wohl aber von Menschen
geschaffene Artefakte zählen. Technische Systeme können als geschlossene und vollständige
Systeme angesehen werden, können aber auch für die Interaktion mit anderen technischen
Systemen konzipiert sein. Diese Systeme kann man meistens mit einer deterministischen
Input-Output-Relation beschreiben: ein bestimmter Input führt zu einem bestimmten
Output, Veränderungen des Inputs führen zu vorhersehbaren Veränderungen des Outputs. Die
Input-Output-Relation gibt implizit an, was mit dem technischen System möglich ist und
wie es gesteuert bzw. benutzt werden kann. Der Zusammenhang von Input und Output
kann durch eine Funktion beschrieben werden – durch eben jene Funktion, für die das
technische System entwickelt wurde.</p>
        <p>Technische Systeme werden in der Regel nur von ihren Entwicklern bzw. Konstrukteuren
als eine abstrakte Handlungsvorschrift oder als Verhältnis von Input und Output
angesehen, alle anderen erleben sie durch ihre Wirkung – wenn überhaupt. Technische Systeme
sind aus dem menschlichen Alltag kaum wegzudenken, angefangen bei der schiefen Ebene
oder beim Flaschenzug, über das Getriebe eines Autos, den Regelkreislauf eines
Kühlschranks bis hin zu Toaster und Mikrowellen-Herd. Und natürlich findet man technische
Systeme auch in Computersystemen.</p>
        <p>Wahrgenommen werden viele technische Systeme erst, wenn sie nicht mehr die
zugrundeliegende Input-Output-Relation erfüllen – oder wenn ihr Konstrukteur vernachlässigt hat,
dass das technische System von Menschen benutzt werden soll. Technische Systeme, die
von Menschen benutzt werden, stellen aber noch kein soziotechnisches System dar.</p>
      </sec>
      <sec id="sec-1-2">
        <title>2.2 Das soziotechnische System</title>
        <p>Der Begriff „soziotechnisches System“ geht auf den soziotechnischen Gestaltungsansatz
des englischen Tavistock Institutes zurück (vgl. [TB51] und [Tr63]). Dieser Ansatz zielte
auf die gemeinsame Optimierung sozialer und technischer Systeme. Dabei wurde jedes
System als unabhängig begriffen, mit eigenen Regeln und Zwecken, im
Produktionsprozess jedoch als voneinander abhängig. Enid Mumford erweiterte den Begriff um
informationstechnische Systeme; demnach meint soziotechnisches Design den Versuch, die
sozialen und technischen Anforderungen, Fragestellungen, Forderungen etc. bei der Gestaltung
und Entwicklung eines neuen Arbeitssystems aufeinander abzustimmen [MW84].
Der wohl radikalste Versuch, den Begriff des sozialen Systems zu bestimmen, stammt vom
deutschen Soziologen Niklas Luhmann: „…Soziale Systeme bestehen (…) nicht aus
Menschen, auch nicht aus Handlungen, sondern aus Kommunikationen…“ ([Lu86]:269). Alles
andere – auch andere Systeme wie Maschinen, Organismen, psychische Systeme – gehört
zur Umwelt von sozialen Systemen. Luhmanns soziologische Systemtheorie schließt an
die allgemeine Theorie selbstreferentieller Systeme an. Danach hat jedes System einen
eigenen Reproduktionsmechanismus; bei sozialen Systemen ist dies die Selbstbezüglichkeit
der Kommunikation, die das soziale System von der Umwelt abschließt. Luhmann
unterscheidet dabei drei primäre Typen sozialer Systeme: Interaktion, Organisation und
Gesellschaft. Soziale Systeme sind zwar durch die selbstbezügliche Kommunikation autonom,
nicht aber autark – sind allgemein auf Umwelt und speziell auf besondere Systeme in der
Umwelt angewiesen. Die Umwelt kann von sozialen Systemen nur kommunikativ
verarbeitet werden, das gilt auch für Technik.</p>
      </sec>
      <sec id="sec-1-3">
        <title>2.3 Die Organisation</title>
        <p>Systemgestaltung findet typischerweise im Rahmen von Organisationen wie Unternehmen
oder Behörden statt. Organisationen sind besondere soziale Systeme, die einen hohen Grad
an formal definierten Regeln, Rollen und Entscheidungswegen aufweisen und in denen nur
die Kommunikation von Organisationsmitgliedern relevant ist.</p>
        <p>Mit den Regeln der Kommunikation in Organisationen hat sich die Soziologie seit Webers
Untersuchungen zur formalen Rationalität von Organisationen zu Beginn des 20.
Jahrhunderts befasst [We22]. Als wichtiges Charakteristikum von Organisationen ist immer
wieder die Zweckbindung des Organisationshandelns oder eben – mit Luhmann – die
Zweckbindung der Kommunikation herausgestellt worden. Die für die Reproduktion von
Organisationen letztlich wichtige Art der Kommunikation hat nach Luhmann die Form der
Entscheidung [Lu00]. Der Raum der möglichen Entscheidungen wird begrenzt durch
Programme (etwa definierte Organisationszwecke oder Bedingungen, aufgrund deren die
Organisation tätig werden muss), Kommunikationswege (wie Organisationshierarchie) und
dadurch, dass Positionen in Organisationen durch unterschiedliche Personen besetzt
werden (mit unterschiedlichen Kompetenzen und sozialen Beziehungen). Schon Weber hatte
die formale Rationalität der Entscheidungen von bürokratischen Organisationen
hervorgehoben und mit ihrer Programmierbarkeit für beliebige (legitime) Zwecke, ihren
Kommunkationswegen (Zuständigkeit, Hierarchie, Regelgebundenheit) und mit
Entscheidungskompetenzen von fachlich ausgebildeten Positionsinhabern begründet [We22]. Besonders
hob Weber die Verschriftlichung der Kommunikation hervor.</p>
        <p>Aus der Perspektive der Arbeits- und Organisationspsychologie sind Organisationen
soziale Gebilde, die dauerhaft bestimmte Ziele verfolgen und formale und informelle
Strukturen aufweisen, mit deren Hilfe die Ressourcen verteilt, Aktivitäten der
Organisationsmitglieder koordiniert und auf die Zielerreichung ausgerichtet werden. Man definiert die
Organisation als ein strukturiertes soziales System, welches aus Einzelpersonen und Gruppen
besteht. Diese arbeiten zusammen, um gemeinsam bestimmte Ziele zu erreichen.
Während klassische Ansätze der Organisationstheorie vor allem die Zweckgebundenheit
von Aktivitäten als das wesentliche Merkmal für die Unterscheidung zwischen
Organisation und anderen sozialen Systemen hervorheben, betonen aktuelle Organisationstheorien
Kohärenz als wesentliches Merkmal einer Organisation. Da sowohl in der
sozialwissenschaftlichen Spieltheorie, der neuen Institutionentheorie wie der Systemtheorie nicht mehr
davon ausgegangen wird, dass Zielidentität in einer Unternehmung besteht, untersuchen
diese Ansätze wie Kohärenz hergestellt wird. Vor dem Hintergrund zunehmend
zwischenbetrieblich interagierender Organisationen (Netzwerke) oder neueren Organisationsformen
(virtuelle Organisation) wird vor allem das Funktionieren von Interaktionsbeziehungen
und Tauschprozessen untersucht. In diesem Zusammenhang gewinnt auch die Interaktion
zwischen Organisation und Umwelt (Gesellschaft, Markt, Staat) an Bedeutung. Die
folgende Abbildung soll Dynamik, Grenzen und die Bedeutung von Interaktion in
Organisationen verdeutlichen.</p>
        <p>Abb. 1: Dynamik, Grenzen und Interaktion in Organisationen
4 / 10</p>
      </sec>
      <sec id="sec-1-4">
        <title>2.4 Modellierung</title>
        <p>Unter dem Begriff „Modellierung“ (Synonym „Gestaltung“) versteht man im allgemeinen
die Konstruktion eines Ideal- oder Sollmodells aus der zweckbezogenen Sicht eines oder
mehrer Modellierer. Die Gestaltung eines Modells ist eine Abstraktion der Wirklichkeit.
Modelle lassen sich nach logischen Formen (Typen einer Modellform sind z.B. Domänen)
und Arten (Exemplare von Typen, z.B. konkrete Bezugsbereiche) unterscheiden. Formen
der Modellbildung sind ordnungsbildend und wiederverwendbar (z.B. Templates). In
diesem Sinne sind Modelle Werkzeuge, die sowohl Wirklichkeit näherungsweise abbilden,
als auch die Veränderung von Wirklichkeit im Gestaltungsprozess unterstützen. Unser
Verständnis von Modellierung in soziotechnischen Systemen wird im folgenden näher
ausgeführt.</p>
      </sec>
      <sec id="sec-1-5">
        <title>2.5 Vom Entwickeln und Gestalten</title>
        <p>Im Rahmen der Arbeit des Arbeitskreises „Modellierung in soziotechnischen Systemen“
geht es um reale soziotechnische Systeme – und um die Arbeit in diesen Systemen. Es geht
um die Arbeit in existierenden Unternehmungen, nicht um angenommene Fallbeispiele
oder um die Abstraktion von soziotechnischen Systemen. Daraus folgt unmittelbar, dass
man nicht von bestimmten Problemen oder Defiziten abstrahieren kann – es gilt, sich allen
Herausforderungen eines konkreten soziotechnischen Systems zu stellen. Man muss sich
beispielsweise den Problemen von Machtstrukturen in hierarchischen Organisationen
stellen, man muss – trotz begrenzter zeitlicher und monitärer Ressourcen – Ziele erreichen.
Hieraus folgt, dass man in keinem dieser Projekte mit einer Strategie, mit einer einzelnen
Methode und mit einer unveränderlichen Perspektive zum Erfolg gelangt.
Modellierung in soziotechnischen Systemen bedeutet in der Regel zweierlei Prozesstypen
zu moderieren: einen Entwicklungsprozess in einem sozialen System, der auf
Verhaltensänderungen seiner Akteure abzielt, und einen Gestaltungsprozess in einem
soziotechnischen System. Bei nicht wenigen solcher Projekte stellt sich im Verlauf der Arbeit heraus,
dass die eigentlichen Probleme der Unternehmung sozialer Natur sind und dass zunächst
dort Entwicklungsarbeit zu leisten ist – bevor im soziotechnischen System Veränderungen
möglich sind. Gestaltungsprojekte, die nur das technische System zum Gegenstand haben,
sind hier häufig zum Scheitern verurteilt, während soziotechnisch orientierte Vorhaben
eine reelle Chance haben, da sie der Veränderung des sozialen und des technischen
Systems gleiches Gewicht beimessen. Im Weiteren soll die Verabredung gelten, dass ein
Gestaltungsprozess ein soziotechnisches System zum Gegenstand hat, ein
Entwicklungsprozess hingegen ausschließlich Veränderungen im sozialen System unterstützt.
Welches sind nun die Bedingungen, die erfüllt sein müssen, um einen Gestaltungsprozess
initiieren zu können? Die wichtigste Vorbedingung ist, sich die Problemursachen zu
vergegenwärtigen und bei der Lösungsfindung zwischen Problemen sozialer, technischer und
wirtschaftlicher Art zu differenzieren. Beispielsweise ist die Entwicklung von
StandardSoftware kein Gestaltungsprozess eines soziotechnischen Systems, sondern die
Herstellung eines Produkts. Man macht dabei Annahmen über die späteren Benutzer – man
arbeitet aber ausschließlich mit und an einem technischen System. Stellt man im Rahmen der
Systemanalyse eines soziotechnischen Systems jedoch fest, dass die Mitarbeiter nicht
wirklich kooperieren oder dass es Kommunikationsprobleme gibt, so gilt es zunächst,
einen Entwicklungsprozess zu initiieren. In einem Projekt sind hierfür Ressourcen
einzuplanen. Gescheiterte Projektvorhaben resultieren häufig aus einer Vernachlässigung der
Problemanalyse. Eine umfassende Systemanalyse ist für einen erfolgreichen
Gestaltungsprozess in soziotechnischen Systemen jedoch eine der wichtigsten Voraussetzungen.</p>
      </sec>
      <sec id="sec-1-6">
        <title>2.6 Die Sache mit dem „in“</title>
        <p>Gestaltungsprozesse zeichnen sich durch eine scheinbar ungewöhnliche Perspektive aus:
Modellierung in soziotechnischen Systemen – nicht etwa von soziotechnischen Systemen.
Das „in“ ist dabei Methode. Die Grundsituation sieht in der Regel wie folgt aus.
Der Modellierer – unabhängig davon, ob es sich um eine Modelliererin, einen Modellierer
oder eine Gruppe von Modellierern handelt, soll nachfolgend vereinfachend vom
Modellierer die Rede sein – wird damit beauftragt, ein soziotechnisches System zu modellieren.
Ziel ist es dabei in der Regel, das soziotechnische Systeme zu verändern, um bestimmte
Wirkungen zu erzielen, etwa die Produktivität zu erhöhen, die Kosten zu senken, die
Zusammenarbeit zu verbessern und dergleichen mehr.</p>
        <p>Die Informationsbasis des Modellierers ist das soziotechnische System selbst: die
Unternehmung mit den in ihr arbeitenden Menschen, inklusive den Aufgaben,
Arbeitsgegenständen, Zielen, Bedingungen, Regeln, Prozessen, Abläufen, Strukturen – und
Werkzeugen. Zu diesen Werkzeugen sind auch Computer, Computernetze, Applikationen u.ä. –
und deren Nutzung – zu zählen. Der Modellierer kann nicht lediglich von „außen“ das
soziotechnische System bewerten und daraus seine Rückschlüsse ziehen: er muss in das
soziotechnische System hinein gehen, um es wirklich verstehen zu können. Seine Aufgabe
ist es, ein Modell des soziotechnischen Systems zu erarbeiten – dieses darf nicht auf einer
Abbildung des soziotechnischen Systems basieren, es muss aus dem Original heraus
entwickelt werden.</p>
        <p>Für diese Arbeit setzt der Modellierer eine Reihe von Methoden ein, die unterschiedlichen
Wissenschaftsdisziplinen entstammen: teilnehmende Beobachtung, strukturierte und
semistrukturierte Interviews, Zukunftswerkstätten, aber auch „klassische“ Analysemethoden
der Informatik wie z.B. das ER-Modell oder die objektorientierte Analyse.
Einen großen Teil seiner Erkenntnisse kann der Modellierer mit entsprechenden formalen
und semiformalen Notationen festhalten. Auch wenn er die Ergebnisse seiner Arbeit in
„Prosaform“ in Projekttagebüchern festhält, auch wenn die sich zuständig fühlenden
Wissenschaften immer neue Methoden entwickeln, so sind diesen Methoden doch Grenzen
gesetzt: weil nur ein Teil des Wissens, das der Modellierer in einem soziotechnischen System
gewonnen hat, explizierbares Wissen ist. Ein weiterer, mindestens genau so wichtiger Teil
des Wissens ist nicht explizierbar und entzieht sich daher der Notation. Zu diesem Wissen
gehört beispielsweise das „Gefühl für ein Unternehmen“ – also das erarbeitete Gespür
dafür, welche Schritte in welcher Form in einem Unternehmen möglich und produktiv und
welche es nicht sind.</p>
        <p>Das nicht-explizierbare Wissen ist eine sehr schnell verderbliche Ware: zum einen, weil es
nicht-explizierbares Wissen über ein soziales und damit dynamisches System ist, zum
anderen, weil eben nicht explizierbar ist – und vergessen werden kann. Es kann vom
Modellierer nicht protokolliert oder an andere Beteiligte weitergegeben werden, es kann nur vom
Wissensträger ge- und benutzt werden. Daraus folgt unmittelbar, dass der Modellierer für
einen der Analyse nachgelagerten Gestaltungsprozess – also für einen
Veränderungsprozess des soziotechnischen Systems – unverzichtbar ist: er ist der einzige Träger dieses
Wissens, ohne ihn gibt es keinen Zugriff auf dieses Wissen.</p>
        <p>Eine wichtige Bedingung für das Funktionieren des Modellierungsprozesses ist
Akzeptanz. Der Modellierer muss von allen Beteiligten akzeptiert sein: nicht nur von seinem
Auftraggeber – von dem natürlich auch – sondern insbesondere von dem sozialen System
des soziotechnischen Systems. Ist er nicht akzeptiert, werden auch seine Ergebnisse nicht
akzeptiert. Zurecht: sie basieren ohnehin auf falschen Einschätzungen, da das soziale
System ihn mit verfälschten bzw. falschen Informationen „gefüttert“ hat. Eine wesentliche
Aufgabe des Modellierers im Gestaltungsprozess nach der Analyse des soziotechnischen
Systems ist seine Interaktion mit dem soziotechnischen System. Das Ziel des
Gestaltungsprozess ist ein verändertes soziotechnisches System, das bestimmte Eigenschaften und
Qualitäten hat – Eigenschaften und Qualitäten, auf die man sich im Gestaltungsprozess
geeinigt hat. Der Modellierer muss nun innerhalb des zyklisch-evolutionären
Entwicklungsprozesses prüfen, ob sich das soziotechnische System dem anvisierten Ziel nähert und ob
sich die gewünschten Eigenschaften und Qualitäten so positiv wie erhofft auswirken.
Dabei hilft ihm in entscheidender Weise das nicht-explizierbare Wissen über das
soziotechnische System. Das soziotechnische Zielsystem ist nur bezüglich des explizierbaren Wissens
beschreibbar und damit planbar. Diese Eigenschaften müssen sich nicht mit den
nichtexplizierbaren Eigenschaften vertragen, sie können durchaus ein soziotechnisches System
beschreiben, dass zwar die gewünschten Eigenschaften hat, aber nicht mehr lebensfähig
ist.</p>
        <p>Nach der Begriffsklärung soll nun anhand einer ausgewählten Methode die praktische
Relevanz verdeutlicht werden.
3</p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>Usability Engineering – eine prozessorientierte Methode</title>
      <sec id="sec-2-1">
        <title>3.1 Von der Produkt- zur Prozesssicht</title>
        <p>Usability-Engineering vor einigen Jahren noch als Software Ergonomie nur an einigen
wenigen Universitäten im Lehrplan hat durch das World Wide Web eine zunehmende
Beachtung erfahren. In den Anfängen – vor dem World Wide Web – gab es einerseits Vertreter
der Disziplin, die sich um „pixelgenaues“ Design bemühten, andererseits jene, die die
aufgabenangemessene Gestaltung einer Software im Fokus hatte. Im Bezug auf
Web-Applikationen weiss man heute, dass beide Aspekte ihre Berechtigung haben.</p>
        <p>
          So lagen denn auch die ersten Bestrebungen Software-Produkte auf „Ergonomie“ zu
prüfen, darin festzustellen, ob sie denn den empirisch begründeten Prinzipien (z.B. „Schwarze
Schrift vor hellem Grund ist besser lesbar“) entsprachen. Die Normenreihe ISO9241
enthält insgesamt über 400 Anforderungen und Empfehlungen hierzu. Aber festzustellen,
dass eine Schriftgröße nicht den Normanforderungen entsprach, war die eine Sache. Eine
ganz andere Sache war es, festzustellen, ob eine Applikation „aufgabenangemessen“ oder
„erwartungskonform“
          <xref ref-type="bibr" rid="ref3">(ISO9241 Teil 10)</xref>
          für die Benutzer ist. Fanden sich zu den „harten“
Kriterien noch hin und wieder entsprechende Formulierungen in
Anforderungsdokumenten, so waren kaum konkretisierte Anforderungen an die Nutzungsqualität der
Dialoggestaltung zu finden. Anscheinend wusste niemand, wie man an diese Anforderungen
„herankommt“. Die Lösung ist die Prozesssicht.
        </p>
        <p>Heute wird Usability mit „Gebrauchstauglichkeit“ übersetzt. Dies klingt zwar etwas
hölzern, macht aber etwas Wichtiges deutlich: es wird nämlich nach Benutzbarkeit und
Gebrauchstauglichkeit unterschieden. Benutzbar ist z.B. eine Kaffeetasse auch ohne Henkel.
Die Nutzung jedoch für einen beabsichtigten Gebrauch, z.B. definiert als Gebrauch zum
komfortablen Halten der Kaffeetasse, ohne sich die Finger an der heißen Tasse zu
verbrennen (Nutzungsqualität!). Gebrauchstauglichkeit setzt Benutzbarkeit voraus.
Wenn eines das andere voraussetzt, hört sich das nach einem Prozess an.
Gebrauchstauglichkeit ist in der ISO9241 Teil 11 definiert als das Ausmass, in dem ein
(Software-)Produkt durch eine bestimmte Nutzergruppe, in einem bestimmten
Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend
zu erreichen [ISO98].</p>
        <p>Benutzer, Arbeitsumgebung und Aufgaben – das hört sich nach soziotechnischem System
an.</p>
        <p>Die Erkenntnis, Benutzer in ihrem konkreten (Arbeits-)Umfeld zu befragen bzw.
Einflussfaktoren daraus zu ermitteln, ist nicht ganz neu. Aus der Ethnologie bekannte
Leitlinien sind:</p>
        <sec id="sec-2-1-1">
          <title>Begegnungen gelten als wichtigste Grundlage zum Verstehen.</title>
          <p>Menschliches Verhalten ist nur unter Betrachtung des Umfeldes zu erklären.</p>
          <p>Untersuchende müssen sich die Sichtweise der Untersuchten aneignen.</p>
          <p>Aus der oben zitierten Definition des Begriffs „Gebrauchstauglichkeit“ ergibt sich, dass
die Kriterien für Nutzungsqualität nicht per se da sind, sondern mit den „richtigen“
Benutzern, in der realen Umgebung und für definierte Arbeitsaufgaben entwickelt werden
müssen. In Persona ist dies die Aufgabe des Usability Engineers. Dazu bedarf es stets einer
Prozessbegleitung und der Auswahl jeweils geeigneter Methoden, um am Ende ein
gebrauchstaugliches Produkt zu erhalten.</p>
        </sec>
      </sec>
      <sec id="sec-2-2">
        <title>3.2 User Centred Design</title>
        <p>In der ISO13407 [ISO99] werden Phasen eines benutzerzentrierten
Entwicklungsprozesses beschrieben. Danach beinhalten benutzerzentrierte Entwicklungsprozesse:</p>
        <sec id="sec-2-2-1">
          <title>Projektorganisation in interdisziplinären Designteams,</title>
          <p>Analyse des Nutzungskontextes (Benutzer, Aufgaben, Umgebung),
Spezifikation von ergonomischen Anforderungen an das Produkt basierend auf den
gewonnenen Daten aus der Analyse des Nutzungskontextes,
Entwicklung von Prototypen und
Evaluierung der Prototypen auf Übereinstimmung mit den spezifizierten
ergonomischen Anforderungen unter Einbeziehung von (ggf. repräsentativen) Endbenutzern.
Diese Beschreibung benutzer-orientierter Gestaltungstätigkeiten ist notwendig, da in den
gängigen Vorgehensmodellen dieser Aspekt nicht ausreichend berücksichtigt ist. So gibt es
zwar im V-Modell [Ve00] eine Rubrik „Anwenderanforderungen“, gemeint sind damit
organisatorische Anforderungen, wie sie sich aus den, dem Management vorliegenden
Geschäftsprozesses ergeben. Nutzungsanforderungen jedoch können nur mittels bestimmter
Methoden ermittelt werden und tauchen sowohl als funktionale als auch als nicht
funktionale Anforderungen auf.</p>
          <p>Eine ausreichende Berücksichtigung, d.h. ein nutzergetriebenes Vorgehen bedeutet, dass
im Prozess der Fokus auf der ganzen Lösung liegt und nicht nur einzelne Komponenten
betrachtet werden. Darüber hinaus wird die Außensicht des Produkts genauso gewichtet,
wie die interne Architektur. Es werden Spezialisten im Bereich User Centred Design
beteiligt, bei Web-Applikationen wird auch auf Wettbewerber-Seiten geschaut. Kodiert wird
erst nachdem mit dem Kunden/Benutzer die Anforderungen validiert sind
(Anforderungsvalidierung statt Merkmalsverifikation). Die Nutzer bestimmen die Qualitätskriterien mit
und letztlich geht es beim Test nicht nur um Programmierfehler, sondern auch um
effiziente Aufgabenbearbeitung und subjektive Benutzerzufriedenheit.</p>
          <p>Im Prüfhandbuch „Gebrauchstauglichkeit“ [DAT01] werden Methoden, wie man sie auch
in der soziotechnischen Modellierung allgemein kennt, empfohlen: Aufgabenanalyse,
teilnehmende Beobachtung, Prototyping, Benutzerbefragung, Dokumentenanalyse und
halbstrukturierte Interviews. Der DATech-Prüfbaustein (Usability-Engineering-Prozess) für
die ISO13407 [DAT02] berücksichtigt den Prozessgedanken, indem eine stufenweise
Beurteilung der Veränderung der Prozessqualität möglich ist.</p>
          <p>Angelehnt an den CMM-Ansatz (Capability Maturity Model) [Pa95] kann ein solcher
Prozess nicht per se installiert sein, sondern muss sukzessive verschiedene Reifestufen
erreichen. So kann der Usability Engineer als „Consultant“ zeitweise im Projekt beteiligt sein,
oder als feste Rolle im Design-Team vorkommen (disziplinierter Prozess). Der höchste
Reifegrad ist erreicht, wenn der Usability Engineer alle Design-Entscheidungen, d.h. auch
nach der Produktivsetzung eines Systems koordiniert (sich ständig verbessernder Prozess).
Des Weiteren wird methodisch vor allem die Moderation der Anforderungsentwicklung
und von Designentscheidungen mit dem Ziel der Konsensfindung hervorgehoben. Das
Anforderungsmanagement wird mit zunehmender Komplexität der Systeme ein
erfolgskritischer Faktor.</p>
          <p>Als eine Methode soziotechnischer Modellierung gewinnt das Usability Engineering an
Bedeutung und die Notwendigkeit des Einsatzes entsprechender Methoden wird vor dem
Hintergrund der Medienkonvergenz und neuartiger Software-Systeme (z.B. Knowledge
Managment) noch zunehmen.</p>
          <p>Literaturverzeichnis
[DAT01]
[DAT02]
[ISO98]
[ISO99]
[Lu86]
[Lu00]
[MW84]
[Pa95]
[TB51]
[Tr63]
[Ve00]</p>
        </sec>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <given-names>Deutsche</given-names>
            <surname>Akkreditierungsstelle</surname>
          </string-name>
          <string-name>
            <given-names>Technik e.V.</given-names>
            (Hg.):
            <surname>DATech-Prüfhandbuch Gebrauchstauglichkeit</surname>
          </string-name>
          .
          <article-title>Leitfaden für die software-ergononmische Evaluierung von Software auf der Grundlage von DIN EN ISO 9241</article-title>
          ,
          <string-name>
            <surname>Teile</surname>
            <given-names>10</given-names>
          </string-name>
          <source>und 11, Version</source>
          <volume>3</volume>
          .2. DATech, Frankfurt/Main, 2001
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>Deutsche</given-names>
            <surname>Akkreditierungsstelle</surname>
          </string-name>
          <string-name>
            <given-names>Technik e.V.</given-names>
            (Hg.):
            <surname>DATech-Prüfbaustein UsabilityEngineering-Prozess</surname>
          </string-name>
          .
          <article-title>Leitfaden für die Evaluierung des Usability-Engineering-Prozesses bei der Herstellung und Pflege von Produkten auf der Grundlage von DIN EN ISO13407, Version 1.2</article-title>
          . DATech, Frankfurt/Main, 2002
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <article-title>International Organization for Standardization: ISO 9241-11 - Ergonomic requirements for office work with visual display terminals</article-title>
          .
          <source>Part</source>
          <volume>11</volume>
          : Guidance on Usability. ISO, Genf,
          <year>1998</year>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <article-title>International Organization for Standardization: ISO 13407 - Human-centred design processes for interactive Systems</article-title>
          . ISO, Genf,
          <year>1999</year>
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <string-name>
            <surname>Luhmann</surname>
            ,
            <given-names>N.: Ökologische</given-names>
          </string-name>
          <string-name>
            <surname>Kommunikation</surname>
          </string-name>
          . Westdeutscher Verlag, Opladen, 1986 Luhmann, N.:
          <article-title>Organisation und Entscheidung</article-title>
          . Westdeutscher Verlag, Opladen, 2000 Mumford, E.;
          <string-name>
            <surname>Welter</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>Benutzerbeteiligung bei der Entwicklung von Computersystemen: Verfahren zur Steigerung der Akzeptanz und Effizienz des EDV-Einsatzes</article-title>
          . Schmidt, Berlin,
          <year>1984</year>
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <surname>Paulk</surname>
            ,
            <given-names>C.M.</given-names>
          </string-name>
          et al.:
          <article-title>The Capability Maturity Model: Guidelines for Improving the Software Process</article-title>
          , Addison Wesley, Reading (Mass.),
          <year>1995</year>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <string-name>
            <surname>Trist</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ;
          <string-name>
            <surname>Bamforth</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Some Social and Psychological Consequences of the Longwall Method of Coal Getting</article-title>
          .
          <source>In: Human Relations 4</source>
          ,
          <year>1951</year>
          ; S.
          <fpage>3</fpage>
          -
          <lpage>38</lpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <surname>Trist</surname>
            ,
            <given-names>E.L.</given-names>
          </string-name>
          et al.:
          <article-title>Organizational choice: Capabilities of groups at the coal face under changing technologies. The loss rediscovery and transformation of a work tradition</article-title>
          .
          <source>Tavistock Publ., London</source>
          ,
          <year>1963</year>
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <string-name>
            <surname>Versteegen</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          (
          <string-name>
            <surname>Hg.): Das</surname>
            <given-names>V</given-names>
          </string-name>
          -Modell in der Praxis: Grundlagen, Erfahrungen, Werkzeuge. dpunkt, Heidelberg,
          <year>2000</year>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          <string-name>
            <surname>Weber</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Wirtschaft und Gesellschaft. Grundriß der verstehenden Soziologie (Erstauflage)</article-title>
          . Mohr, Tübingen,
          <year>1922</year>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>