1 Kommunikationsprozesse und Dokumente des Software-Projektmanagements aus sozio-technischer Perspektive Gabriele Kunau, Natalja Menold, Thomas Herrmann, Kai-Uwe Loser Ruhr-Universität Bochum, Institut für Arbeitswissenschaft, Lehrstuhl für Informations- und Tech- nikmanagement Abstract Die erfolgreiche Entwicklung und Einführung eines Softwaresystems hängt davon ab, dass technische und organisatorische Lösungen integriert entwickelt und umgesetzt werden. Für die Realisierung einer solchen sozio-technischen Per- spektive fehlt es im Projektmanagement an Methoden. Daher wird vorgestellt, wie der sozio-technische Aspekt anhand von Dokumenten verfolgt werden kann, die mit einer semi-strukturierten Modellierungssprache Arbeitsprozesse in Dia- grammen abbilden. Anhand eines Fallbeispiels (mobile Kommunikationssysteme für Speditionen) wird der Einsatz solcher Diagramme für das Projektmanage- ment beschrieben und ihre Vorteile verdeutlicht – etwa im Umgang mit vager In- formation oder hinsichtlich ihrer Verknüpfbarkeit mit anderen Dokumenten. Es wird aufgezeigt, dass die Entwicklung und Nutzung solcher Dokumente in syste- matisch moderierte Kommunikationsprozesse im Rahmen von Workshops einge- bettet sein sollte. Dieser als socio-technical Walkthrough bezeichnete Ansatz wird abschließend anhand der Rückmeldungen aus dem Fallbeispiel reflektiert. 1 Einleitung Die Entwicklung von Software zur Unterstützung kooperativer Arbeitsprozesse bedarf eines interdisziplinären Projektmanagements, weil es nicht nur gilt, die Software als technisches System zu entwickeln, sondern weil gleichzeitig die betroffenen Arbeitspro- zesse neu gestaltet oder angepasst werden müssen. Aus einer „ganzheitlichen“ Betrach- tung folgt, dass in solchen Projekten nicht nur ein technisches, sondern ein sozio- technisches System entsteht. Das Ziel einer sozio-technischen Systementwicklung in diesem Sinne ist es, eine Organisation dabei zu unterstützen, die Nutzung einer neuen Software zu planen und somit deren Einbettung in die Arbeitsprozesse gezielt zu gestal- ten. Auch wenn diese einleitend zusammengefassten Erkenntnisse nicht neu sind, so besteht nach wie vor ein Defizit an Methoden zur Unterstützung eines interdisziplinären Projektmanagements, das seine Aufgabe in der Gestaltung eines sozio-technischen Sys- tems sieht. Das in diesem Beitrag vorgestellte Konzept setzt an den Dokumenten an, welche die Kommunikation im Projektverlauf unterstützen und verstetigen: Um technisch unter- stützte Arbeitsprozesse gezielt gestalten zu können, müssen sie geeignet dokumentiert Gabriele Kunau, Natalja Menold, Thomas Herrmann, Kai-Uwe Loser (2005): Kommunikationsprozesse und Dokumente des Software-Projektmanagements aus sozio-technischer Perspektive. In: Frick, Andreas; Kerber, Gerrit; Marre, Roland (2005):Entrepreneurship im Projektmanagement - Beiträge zur Konferenz “interPM” 2005. S. 257-276.
Transcript
1
Kommunikationsprozesse und Dokumente
des Software-Projektmanagements aus
sozio-technischer Perspektive
Gabriele Kunau, Natalja Menold, Thomas Herrmann, Kai-Uwe Loser Ruhr-Universität Bochum, Institut für Arbeitswissenschaft, Lehrstuhl für Informations- und Tech-
nikmanagement
Abstract
Die erfolgreiche Entwicklung und Einführung eines Softwaresystems hängt
davon ab, dass technische und organisatorische Lösungen integriert entwickelt
und umgesetzt werden. Für die Realisierung einer solchen sozio-technischen Per-
spektive fehlt es im Projektmanagement an Methoden. Daher wird vorgestellt,
wie der sozio-technische Aspekt anhand von Dokumenten verfolgt werden kann,
die mit einer semi-strukturierten Modellierungssprache Arbeitsprozesse in Dia-
grammen abbilden. Anhand eines Fallbeispiels (mobile Kommunikationssysteme
für Speditionen) wird der Einsatz solcher Diagramme für das Projektmanage-
ment beschrieben und ihre Vorteile verdeutlicht – etwa im Umgang mit vager In-
formation oder hinsichtlich ihrer Verknüpfbarkeit mit anderen Dokumenten. Es
wird aufgezeigt, dass die Entwicklung und Nutzung solcher Dokumente in syste-
matisch moderierte Kommunikationsprozesse im Rahmen von Workshops einge-
bettet sein sollte. Dieser als socio-technical Walkthrough bezeichnete Ansatz wird
abschließend anhand der Rückmeldungen aus dem Fallbeispiel reflektiert.
1 Einleitung
Die Entwicklung von Software zur Unterstützung kooperativer Arbeitsprozesse bedarf eines interdisziplinären Projektmanagements, weil es nicht nur gilt, die Software als technisches System zu entwickeln, sondern weil gleichzeitig die betroffenen Arbeitspro-zesse neu gestaltet oder angepasst werden müssen. Aus einer „ganzheitlichen“ Betrach-tung folgt, dass in solchen Projekten nicht nur ein technisches, sondern ein sozio-technisches System entsteht. Das Ziel einer sozio-technischen Systementwicklung in diesem Sinne ist es, eine Organisation dabei zu unterstützen, die Nutzung einer neuen Software zu planen und somit deren Einbettung in die Arbeitsprozesse gezielt zu gestal-ten. Auch wenn diese einleitend zusammengefassten Erkenntnisse nicht neu sind, so besteht nach wie vor ein Defizit an Methoden zur Unterstützung eines interdisziplinären Projektmanagements, das seine Aufgabe in der Gestaltung eines sozio-technischen Sys-tems sieht.
Das in diesem Beitrag vorgestellte Konzept setzt an den Dokumenten an, welche die Kommunikation im Projektverlauf unterstützen und verstetigen: Um technisch unter-stützte Arbeitsprozesse gezielt gestalten zu können, müssen sie geeignet dokumentiert
Gabriele Kunau, Natalja Menold, Thomas Herrmann, Kai-Uwe Loser (2005): Kommunikationsprozesse und Dokumente des Software-Projektmanagements aus sozio-technischer Perspektive.
In: Frick, Andreas; Kerber, Gerrit; Marre, Roland (2005):Entrepreneurship im Projektmanagement - Beiträge zur Konferenz “interPM” 2005. S. 257-276.
2 Kunau, Menold, Herrmann, Loser
und festgehalten werden, insbesondere dann, wenn eine Vielzahl von Personen unter-schiedliche Perspektiven in die Gestaltung einbringen. Für die Darstellung und Gestal-tung sowohl von Softwaresystemen als auch von Geschäftsprozessen sind grafische Modellierungsmethoden akzeptiert und verbreitet. Die Modelltypen der Unified Mode-ling Language (UML) [Jec 04] sowie ARIS [Sch 98] seien hier beispielhaft erwähnt. Sozio-technische Dokumente greifen auf diese Ansätze zurück, um dann in zweierlei Hinsicht darüber hinaus zu gehen: Zum einen durch den Modellierungszweck, der darin liegt, Arbeitsprozesse mit ihren Bezügen zu einem technischen System darzustellen. Zum anderen durch die Einbettung der Modellierung in ein Workshop-Konzept, das den Kontext einer moderierten Kommunikation bildet, der für jede Organisationsentwick-lung unerlässlich ist.
In diesem Beitrag berichten wir von einer Fallstudie , in welcher der Einsatz sozio-technischer Dokumente im Kontext eines Software-Entwicklungsprojektes erprobt wur-de. Unter Rückgriff auf erprobte Methoden der sozio-technischen Modellierung [Her 04a] sowie dem Einsatz von grafischen Modellen zur Moderation von Workshops, wur-de die Methode „socio-technical“ Walkthrough (STWT) ([Her 02], [Her 04b]) in dieser Fallstudie durchgängig zur Unterstützung der Projektleitung bei der Einhaltung einer sozio-technischen Perspektive eingesetzt. Nach der Präsentation der Fallstudie in Ab-schnitt 2 geht Abschnitt 3 auf die Eigenschaften sozio-technischer Dokumente ein. Da-bei werden zentrale Aspekte behandelt und mit Beispielen aus der Fallstudie erläutert, deren systematische Dokumentation ein ganzheitliches Projektmanagement unterstützen kann. Auf die Besonderheiten einer sozio-technischen Modellierung wird ebenfalls ein-gegangen. Abschnitt 4 stellt dar, wie der STWT eingesetzt wurde, um die Dokumente in ein kommunikatives Geschehen einzubetten und so das Ziel der sozio-technischen Sys-temgestaltung zu erreichen. Abschließend werden die Ergebnisse der Evaluation eines STWT-Workshops genutzt, um ein Fazit zu ziehen.
2 Fallstudie
Die Fallstudie1 befasst sich mit einem Unternehmen der Logistikbranche, das anstrebt, die innerbetrieblichen Kommunikationsprozesse durch den Einsatz von Informations-technik zu verbessern. Insbesondere soll die Kommunikation zwischen den auf Tour befindlichen LKW-Fahrern und den im Büro arbeitenden Disponenten durch ein mobiles Kommunikationssystem so unterstützt werden, dass die Geschäftsprozesse effizienter abgewickelt werden können. Der an der Fallstudie beteiligte Teil des Unternehmens wird „Westkreis“ genannt und besteht aus einem Team, in dem ein Team-Leiter, sieben
1 Die Fallstudie war Teil des Projektes SpiW (Mobile Speditionen im Web), das inner-halb des Rahmenkonzeptes „Innovative Arbeitsgestaltung“ vom BMB+F gefördert wur-de. Förderkennzeichen: 01HT0143; Vgl. auch [Erk 05]
... Software-Projektmanagement aus sozio-technischer Perspektive 3
Disponenten an drei Standorten sowie 17 angestellte LKW-Fahrer arbeiteten. Zwei Ma-nager aus der Unternehmenszentrale kommen zur Unterstützung des Projektteams hinzu.
Der "Westkreis" organisiert die komplette Auslieferungslogistik für ein Stahlhan-delsunternehmen, das diese als Projektauftrag ausgelagert hat. Die Aufträge, die das Stahlhandelsunternehmen mit seinen Kunden abgeschlossen hat, gehen an die Disponen-ten, die daraus Auslieferungstouren für die Fahrer zusammenstellen. Diese wiederum beladen die LKW gemäß den ihnen zugeteilten Aufträgen, die sie in Form von Papier-stapeln auf einem Klemmbrett erhalten. Eine Tour dauert zwischen vier und zehn Stun-den, und während dieser Zeit findet eine Kommunikation mit dem Disponenten nur in Ausnahmefällen und per Handy statt. Früh morgens vor und häufig noch abends nach der Tour kommen die Fahrer ins Büro des Disponenten, um die Lieferpapiere ab-zugeben, Abrechnungsformalitäten vorzunehmen, und die Papiere für ihre nächste Tour entgegen zu nehmen. Zur Übergabe von Lieferpapieren sowie für die Erledigung von Abrechnungsformalitäten kommen die Fahrer am frühen Morgen vor oder auch am Abend nach der Tour in das Büro der Disponenten. Bei dieser Gelegenheit werden auch evtl. notwendige zusätzliche Erläuterungen zu den Touren besprochen.
Diese – hier nur grob skizzierten – Arbeitsabläufe soll im Rahmen des Projektes SpiW durch die Einführung eines – neu zu entwickelnden – mobilen Kommunikations-systems umgestaltet werden. Das Management des Logistikunternehmens erwartet da-von insbesondere, dass die Disponenten besser über den Verlauf der Auslieferungsfahr-ten informiert werden, und die Fahrer ihrerseits frühzeitig über die weitere Transport-planung Kenntnis erhalten. Das Projekt SpiW umfasst sowohl die Entwicklung und Implementierung des, SpiW-Com genannten, software-technischen System [Gru 03] als auch die Planung neuer Arbeitsprozesse, um mit den Möglichkeiten der Software die genannten unternehmerischen Ziele zu erreichen.
3 Sozio-technische Diagramme
Um eine integrierte Gestaltung des software-technischen Systems SpiW-Com und der dazu gehörigen Arbeitsprozesse von Disponenten und Fahrern zu unterstützen, wurden im Projekt Diagramme eingesetzt, die schrittweise eine sozio-technische Lösung doku-mentieren.
3.1 Eigenschaften sozio-technischer Diagramme
Sozio-technischer Diagramme stellen Arbeitsprozesse (als aufeinander bezogene Aktivi-täten) im Kontext der sie unterstützenden technischen Systemen (als Entitäten) dar. Die Aspekte „Aktivität“ und „Entität“ können ergänzt werden um Personen, die als Rollen mit Rechten und Pflichten repräsentiert werden. Darüber hinaus ist auch die Repräsenta-tion weiterer Verweise bspw. auf Dokumente oder Formulare wichtig. Das software-technische System sollte so dargestellt werden, dass passive Elemente – wie bspw. Mas-ken, die Informationen darstellen, – von automatisch ablaufenden Prozessen unterschie-den werden können. Die genannten Elemente sind in vielen Notationen der (Geschäfts-
4 Kunau, Menold, Herrmann, Loser
)Prozessmodellierung zu finden. In der Fallstudie „Westkreis“ wurde die Modellie-rungsmethode SeeMe (sozio-technische, semi-strukturierte Modellierungsmethode) verwendet, in der Aktivitäten mit abgerundeten Rechtecken, Entitäten als Rechtecke mit spitzen Ecken, und Rollen als Ellipsen dargestellt werden. Als besondere Unterstützung für die Modellierung sozio-technsicher Systeme stellt SeeMe Notationselemente zur Repräsentation von Unvollständigkeit und Unsicherheit zur Verfügung [Her 04a].
Abb. 1.: Tätigkeiten beim Empfänger
Das in Abbildung 1 dargestellte Diagramm zeigt einen Ausschnitt der geplanten Nut-zung von SpiW-Com bei den Arbeitsschritten, die ein Fahrer bei den Empfängern seiner Transporte durchführt. Um den Aufwand der Dateneingabe für den Fahrer zu reduzie-ren, wurde im Rahmen eines Workshops diskutiert, ob das zu entwickelnde mobile Kommunikationssystem an den Datenbus (ICAN) angeschlossen werden sollte, über den die meisten modernen LKW verfügen. Ein schnell gefundenes Einsatzbeispiel war der Kilometerstand, der bei jeder Ankunft bei einem Empfänger auf einem so genannten Tagesbericht notiert werden muss. Dieser könnte bei Anbindung an den Datenbus auto-matisch ausgelesen werden, womit dem Fahrer eine händische Dateneingabe erspart
... Software-Projektmanagement aus sozio-technischer Perspektive 5
würde. Auf weitere so konkrete Beispiele konnten sich die Beteiligten in der anschlie-ßenden Diskussion aber nicht einigen. Im Diagramm wird nun die Übernahme des Ki-lometerstands als Beispiel einer sinnvollen Anwendung dargestellt. Mit einem Unvoll-ständigkeitssymbol (dem weißen Halbkreis) wird markiert, dass weitere Möglichkeiten denkbar sind.
Symbole, die in Diagrammen Unvollständigkeiten oder Vagheiten repräsentieren, können von der Projektleitung dazu genutzt werden, zu überprüfen wie viel Klärungsbe-darf es zu einem bestimmten Thema noch gibt. In Rahmen von moderierten Sitzungen können notwendige Klärungen dann gezielt herbeigeführt werden (siehe Abschnitt 4). In Programmen zur Unterstützung des Projektmanagements können solcherlei Hinweise in Form von „offenen Punkten“ oder „Action-Lists“ abgelegt und verwaltet werden. Dort könnte sich der Projektleiter notieren, dass er noch zu klären hat, welche Daten über den ICAN-Bus zu übertragen sind. Der Nachteil gegenüber der in die sozio-technischen Diagramme integrierten Darstellung ist, dass der Kontext verloren geht, aus dem heraus die Entscheidung notwendig wird. Möglichkeiten zur Verlinkung unterschiedlicher Do-kumente – wie bspw. Listen und Diagramme – werden im Abschnitt 3.3 dargestellt.
Die Möglichkeit, Kommentare an Diagrammelemente anhängen zu können, hat sich als sehr nützlich erwiesen: Abbildung 1 enthält ein Beispiel, in dem ein Kommentar darauf hinweist, dass sich ein Arbeitsschritt als überflüssig erweisen könnte. Kommenta-re als Freitextfelder können im Verlauf eines Projektes auf unterschiedlichste Weise verwendet werden, um unstrukturierte Informationen mit Diagrammelementen in Ver-bindung zu bringen. So zum Beispiel auch zur Sammlung von Themen, die erst zu ei-nem späteren Zeitpunkt vertieft und im Detail modelliert werden sollen.
Um die sozio-technische Perspektive in allen Phasen eines Software-Entwicklungsprojekt dokumentieren zu können, muss die Modellierungsmethode so flexibel sein, dass sie zu Beginn, wenn Ideen noch sehr vage sind, ebenso eingesetzt werden kann, wie zum Ende, wenn es um die Dokumentation des konkreten Einsatzes der fertigen Software geht.
Eine umfassende Darstellung von Anforderungen an eine sozio-technische Modellie-rungssprache findet sich in [Her 04a].
3.2 Eigenschaften sozio-technischer Dokumente
Sozio-technische Dokumente sollen die späteren Nutzer der Software dabei unterstützen, ihre zukünftigen Arbeitsprozesse gezielt im Hinblick auf den Technikeinsatz zu planen. Das Management von Software-Projekten geht häufig von der Annahme aus, dass sich die Arbeitsprozesse, die zu einer „gut“ – nach professionellen Methoden – entwickelten Software passen, quasi automatisch ergeben. Diese Annahme ist falsch: keine Software kann eindeutig ihren Nutzungskontext determinieren. Dieser bedarf vielmehr der expli-ziten Aushandlung unter den Beteiligten. Im Falle einer Software, die kooperative Ar-beitsprozesse unterstützen soll, ist hier von einem interdisziplinären Projektmanagement neben der Technik-Entwicklung auch Organisationsentwicklung zu leisten.
6 Kunau, Menold, Herrmann, Loser
Use-Cases und Geschäftsprozessmodellierung sind zwei Methoden, die genutzt wer-den, um neben der Technik-Entwicklung auch organisatorische Aspekte zu berücksichti-gen. Bevor in weiteren Abschnitten Beispiele für zentrale Aspekte sozio-technischer Dokumente aus der Fallstudie dargestellt werden, dienen die nächsten beiden Abschnitte der Abgrenzung des Konzeptes sozio-technischer Dokumente.
Abgrenzung zu Use-Cases
Die in der Unified Modelling Language (UML) definierten Use Cases (in deutsch auch Anwendungsfälle) tragen zur Spezifikation von Softwaresystemen bei, indem sie Inter-aktionssequenzen zwischen Nutzern und Software beschreiben [Jec 04]. Die Use-Case Modellierung dient dazu, eine vollständige Beschreibung aller möglichen Interaktionen mit dem software-technischen System zu erstellen, und auf diese Weise die Grenzen des zu entwickelnden Sytems zu definieren [Kru 04]. So gehören Tätigkeiten der Nutzer, die zwar in Verbindung mit dem zu beschreibenden technischen System stehen, aber keine direkte Interaktion mit dem System bewirken, nicht in eine Anwendungsfallbe-schreibung. Die Anwender und Nutzer sowie ihre Arbeitsorganisation werden in Form einer Schnittstelle betrachtet, sind aber auch in der Use-Case Modellierung nicht Gestal-tungsgegenstand. An dieser Stelle geht die sozio-technische Modellierung über Use-Cases hinaus: sie soll ein interdisziplinäres Projektmanagement fördern, indem sie das sozio-technische System zum Gegenstand der Darstellung und zum zu gestaltenden Element macht. Abschnitt 3.3 beschreibt, wie software-technische Dokumente wieder-um in sozio-technische Diagramme eingebunden werden können.
Abgrenzung zu Geschäftsprozessmodellen
Eine Möglichkeit, Geschäftsprozesse zu definieren, ist es, sie als “Folge von inhaltlich-logisch miteinander verknüpften, wertschöpfenden Aktivitäten, die Inputs zu anforde-rungsgerechten Outputs transformieren“ ([PAS 03], S. 41) zu charakterisieren. Im Un-terschied zur sozio-technischen Modellierung, welche die Integration einer technischen Infrastruktur in kooperative Arbeitsabläufe darstellt, haben Geschäftsprozessmodelle betriebswirtschaftliche Abläufe zum Gestaltungsgegenstand. Durch diese besonderen Zielsetzungen ergeben sich besondere Inhalte der Diagramme, die sich von einer sozio-technischen Perspektive unterscheiden. Eine bei der Erstellung von Modellen entschei-dende Frage ist die nach der Granularität der Darstellung; d.h. welche Aktivitäten wer-den noch einzeln dargestellt und welche werden im Sinne einer erwünschten Komplexi-tätsreduktion in zusammenfassende Prozessschritte aufgenommen? Die Beantwortung dieser Frage hängt vom Zweck der Modellierung ab. Während sich Geschäftsprozess-modelle auf Prozessschritte konzentrieren, die für eine betriebswirtschaftliche Diskussi-on relevant sind, kommt es bei sozio-technischen Diagrammen darauf an, die Tätigkei-ten, Rollen und Objekte darzustellen, die für Absprachen hinsichtlich der Nutzung des technischen Systems von Bedeutung sind. Letztere werden dadurch potenziell feingranu-larer, weil sie Arbeitsschritte und ihre Interaktionstätigkeit mit der Technik herausstel-len.
... Software-Projektmanagement aus sozio-technischer Perspektive 7
Beispiel: Festlegung von Verantwortlichkeiten
Anhand der Zusammenarbeit zwischen Disponent und Fahrer bei der Übergabe neuer Touren wird im Folgenden ein Beispiel aus der Fallstudie für die Ausbildung und Do-kumentation organisatorischer Absprachen während eines Software-Entwicklungsprojektes gegeben.
Die Fahrer im „Westkreis“ sollen zukünftig ihre Fahraufträge nicht mehr in Form von Lieferpapieren, sondern als Datensätze in SpiW-Com erhalten. Damit wird sich aber auch die Art der Absprache zwischen Disponenten und Fahrern über die Reihenfolge der Fahraufträge innerhalb einer Tour ändern, die bisher sehr informell von statten geht: Der Disponent stellt die Touren für die Fahrer zusammen, indem er die zu einer Tour gehö-renden Auftragspapiere auf Klemmbrettern ablegt. Die Reihenfolge, in der die Papiere auf dem Klemmbrett liegen, geben die vom Disponenten gewollte Route der Tour wie-der. Formal liegt es aber im Ermessen des Fahrers, in welcher Reihenfolge er die Emp-fänger einer Tour ansteuert. Bevor ein LKW für eine Tour beladen werden kann, kommt der Fahrer in das Büro des Disponenten und sichtet die für ihn vorgesehenen Aufträge auf seinem Klemmbrett; ggfs. verhandelt er in einem eher informellen Gespräch mit dem Disponenten Details der Tour. Dabei können Fahraufträge sowohl umsortiert als auch gänzlich gestrichen werden.
Das Diagramm in Abbildung 2 zeigt, dass diese Aufteilung der Zuständigkeiten auch zukünftig mit SpiW-Com beibehalten werden soll: Dem Disponenten soll es möglich sein, die zu einer Tour gehörenden Datensätze in eine Reihenfolge zu bringen, die seinen Vorstellungen entspricht. Der Fahrer nimmt diese "Wunschreihenfolge" zur Kenntnis, kann sie dann aber noch verändern. Erst danach liegt im System eine festgelegte Route für die Tour vor. Den Bedenken der Fahrer, dass alleine der Disponent mit der Einfüh-rung des neuen Systems die Möglichkeit hat, Routen festzulegen, wurde im Projekt durch explizite Diskussion und Dokumentation begegnet. Währen die technische Doku-mentation von SpiW-Com beschreibt, mit welchen Funktionen Fahrer und Disponenten die Reihenfolge der Empfänger einer Tour bearbeiten können, beinhaltet das sozio-technische Diagramm aus Abbildung 2 darüber hinaus die Vereinbarungen, wie die Verantwortung für die Festlegung einer Route zwischen Fahrer und Disponent aufgeteilt werden. Diese über die technischen Funktionen hinausgehende Dokumentation ist für ein ganzheitliches Projektmanagement wichtig. Sie hält Absprachen zur Nutzung der Software fest, welche die in der Software implementierten Regeln zur Arbeitsteilung ergänzen. Die Tatsache, dass der Fahrer über Funktionen zur Änderung der Tour ver-fügt, besagt noch nichts über die Rahmenbedingungen, unter denen er diese Funktion nutzen soll. Es wäre ebenso denkbar, dass er nur in Ausnahmefällen schreibend auf die Tourdaten zugreifen soll. Im Laufe eines Software-Entwicklungsprojektes kommt es zu vielen Absprachen, die die Spezifikation der Software ergänzen. Sozio-technische Dia-gramme sind eine Möglichkeit, solche Absprachen systematisch zu erfassen und konti-nuierlich zu nutzen.
Mehr noch als bei Use-Case- oder Geschäftsprozessmodellen muss für sozio-technische Diagramme in jedem Projekt neu entschieden werden, welche Aspekte (Rollen, Aktivi-täten, Entitäten) in welchem Detail dokumentiert werden sollen. Anders als bspw. für Use-Cases gibt es für sozio-technische Modelle keine Definition, die ihren Inhalt ein-grenzt oder anhand derer sich ihre Vollständigkeit überprüfen ließe. Die Frage, ob sozio-technische Diagramme hinreichend detailliert und vollständig sind, ergibt sich über ihre „Gebrauchstauglichkeit.
... Software-Projektmanagement aus sozio-technischer Perspektive 9
Das Diagramm in Abbildung 3 enthält die Tätigkeit „Fahrzeug wieder fahrbereit ma-chen“ des Fahrers und ist ein Beispiel für eine Aktivität, die weder im betriebswirt-schaftlichen Sinne Wert schöpfend ist, noch eine Interaktion mit der zu entwickelnden Software enthält. Welchen Sinn die Darstellung solcher Aktivitäten in einem sozio-technischen Diagramm machen kann, zeigt sich wenn, man den Verlauf der Dokumenta-tion im Projekt betrachtet: Die Aktivität wurde nach der Erhebungsphase in die Doku-mentation der Ist-Abläufe aufgenommen, um ein möglichst genaues Bild der Tätigkeiten der Fahrer festzuhalten. Später diente sie dazu, den Arbeitskontext darzustellen, in dem der Fahrer dem Disponenten seine Abfahrt vom Kunden signalisiert.
Eine in den Workshops diskutierte Frage war, woran der Disponent erkennen könnte, dass der Fahrer einen Auftrag bei einem Empfänger erledigt hat. Eine Überlegung war, dass die Kennzeichnung der Lieferscheine als „unterschrieben“ das Signal für den Disponenten sein könnte, dass der Fahrer mit einem Auftrag fertig ist. Diese Lösung hätte aber den Nachteil, dass der Disponent nicht weiß, ob der Fahrer beim Empfänger sofort wieder losfahren kann, oder zunächst noch einige Zeit braucht, um den LKW wieder fahrbereit zu machen. Da es hier zu beachtlichen Verzögerungen kommen kann, einigten sich die Beteiligten darauf, dass eine zusätzliche Information an den Disponen-ten verschickt werden soll, wenn der Fahrer tatsächlich losfahren kann. Die Darstellung der Aktivität "Fahrzeug wieder fahrbereit machen" half in dem Workshop zunächst dazu, allen Beteiligten zu vermitteln, dass zwischen der Unterschrift unter dem Liefer-schein und der tatsächlichen Abfahrt noch Tätigkeiten zu erledigen sind. Somit war die Notwendigkeit der Diskussion auch denen deutlich, die sich mit dem Arbeitsalltag der Fahrer nicht auskannten. Im weiteren Verlauf des Projektes diente diese Darstellung als
10 Kunau, Menold, Herrmann, Loser
Dokumentation der computer-unterstützten Abläufe, die unter anderem in Schulungen eingesetzt wurde.
Beispiel: Absprachen hinsichtlich der Nutzung von SpiW-Com
In einem Qualifizierungsworkshop der Fallstudie „Westkreis“ wurden Fahrer und Disponenten im Umgang mit der Software geschult und anschließend gefragt, ob und welchen weiteren Abstimmungsbedarf die Teilnehmer nun noch hinsichtlich der Nut-zung des mobilen Kommunikationssystem sähen. Diese Sammlung enthält gute Beispie-le für Themen, die im Rahmen eines sozio-technischen Projektansatzes über die eigent-liche Technikentwicklung hinaus zu bedenken sind. Im Folgenden sind einige Themen, die auf Metaplankarten genannt wurden, mit einer ergänzenden Erklärung wiedergege-ben:
- „wann ist das Material „rostig“?“ Die Fahrer sahen den Bedarf zu klären, wann sie das in der Software angebotene Feld „Material ist rostig“ ankreuzen sollen. Sollte dieses Feld dazu genutzt werden, Material zu kennzeichnen, dass wert-reduzierend schadhaft war, oder sollte im Hinblick auf eine interne Qualitätskontrolle bereits kleine Rostflecken gemeldet werden? Verallgemeinernd kann man sagen, dass sich die Beteiligten über die Interpretation der in den Masken verwendeten Begriffe ei-nigen mussten.
- „ab wann benachrichtigt d. F. den D.“ Das mobile Kommunikationssystem sah ei-ne Benachrichtigungsfunktion vor, die der Fahrer nutzen kann, um dem Disponen-ten direkt etwas mitzuteilen. Alle Beteiligten sahen die Notwendigkeit zu klären, unter welchen Umständen diese Funktion genutzt werden musste oder sollte.
- „Wann ist es, ‚zu Handy zu greifen’“ Die Beteiligten diskutierten ausführlich dar-über, unter welchen Umständen das neue mobile Kommunikationssystem die bis-herige Kommunikation via Handy ersetzen sollte, und in welchen Situationen doch noch zum Handy gegriffen werden soll.
Insbesondere der letzte Aspekt wurde ausführlich für den Fall diskutiert, dass ein Prob-lem auftritt, das der Fahrer nicht alleine entscheiden darf. In diesem Fall ist er auf die Weisung des Disponenten angewiesen, die der Fahrer bislang telefonisch erfragt. Zu Zwecken der Dokumentation und damit die Zahl der Telefonate für den Disponenten reduziert werden, wurde vereinbart, dass der Fahrer in der Regel zunächst die Funktio-nen des Systems SpiW-Com nutzen soll, um den Disponenten zu benachrichtigen. Dann kommt es auf die Schwere des Problems, aber auch auf das Ermessen des Fahrers an, ob er seine Tour fortsetzt, oder zunächst die Rückmeldung des Disponenten abwartet. Ab-bildung 4 zeigt das zu dieser Vereinbarung erstellte Diagramm.
... Software-Projektmanagement aus sozio-technischer Perspektive 11
Abb. 4.: Vereinbarung (1) zur Nutzung von SpiW-Com
12 Kunau, Menold, Herrmann, Loser
Abbildung 5 zeigt ein einfaches Beispiel einer Absprache zur Nutzung des Systems: Der Fahrer soll SpiW-Com dazu nutzen, seine Ankunft bei einem Empfänger bekannt zu geben. Es wurde diskutiert, ob er dies auch dann machen soll, wenn er merkt, dass eine Entladung nicht möglich sein wird. Der Beschluss, dass immer dann, wenn der Fahrer bei einem Kunden eintrifft, die Ankunft eingetragen werden soll, wurde in Form eines Modifikators (grünes Sechseck) in das Diagramm eingetragen.
Abb. 5.: Vereinbarung (2) zur Nutzung von SpiW-Com
3.3 Verknüpfung mit anderen Dokumenten
Da in einem Projekt Dokumente unterschiedlichen Typs und unterschiedlicher Zielset-zung erzeugt werden, stellt sich die Frage, wie sozio-technische Dokumente mit solchen anderen Projektdokumenten in Verbindung gebracht werden können.
Im Kontext der Fallstudie „Westkreis“ sind dies neben den Dokumenten aus der Pha-se der Ist-Analyse vor Ort vor allem Dokumente, die im Verlaufe der Software-Entwicklung für das System SpiW-Com entstanden sind: Fotos, Spezifikationen der Software-Entwicklung und Abbildungen des Prototypen der Benutzungsoberfläche. Um diese Dokumente in die sozio-technischen Diagramme zu integrieren, werden Hyper-links genutzt, die auf Textmarken innerhalb von Textdokumente zeigen. Auf diese Wei-se können bspw. Textpassagen, die Anforderungen an das technische System beschrei-ben, aus den Diagrammen heraus adressiert und dargestellt werden. Auf diese Weise werden die Projektbeteiligten dabei unterstützt, technische Anforderungen immer im Kontext der Arbeitsprozesse zu betrachten und zu diskutieren.
... Software-Projektmanagement aus sozio-technischer Perspektive 13
Abb. 6.: Modellausschnitt mit verlinktem Foto
Abb. 7.: Diagrammausschnitt mit Maskenprototyp
14 Kunau, Menold, Herrmann, Loser
Der Diagrammausschnitt in Abbildung 6 stammt aus der Phase der Ist-Erhebung im „Westkreis“. Die Belege, mittels derer ein Fahrer dem Disponenten abends seine Tour dokumentiert sind in Form von Entitäten dargestellt: die Entität „Info über tatsächlichen Tourverlauf“ enthält die Subentitäten „unterschriebene Lieferscheine“ und „ausgefüllter Tagesbericht“. Um die Entität "ausgefüllter Tagesbericht" im Diagramm konkreter zu beschreiben, wurde ein Foto eines ausgefüllten Tagesberichts per Hyperlink mit dem Diagramm verbunden. Man hätte zu diesem Zweck auch die Spalten der Tabelle des Tagesberichts als Subentitäten modellieren können. Die Nutzung eines Fotos hat aber den Vorteil, dass die Abstraktion der Modellierungsnotation durchbrochen, und den Teilnehmern ein konkretes, koordinierendes Artefakt der Arbeitswelt geboten wird.
Abb. 8.: Sozio-technisches Diagramm mit Verweis auf funktionale Beschreibung der
Software
Als die Software-Entwicklung soweit fortgeschritten war, dass Screenshots der Benut-zungsoberfläche zur Verfügung standen, wurden diese ebenfalls durch Hyperlinks in die sozio-technischen Diagramme integriert. Es stellte sich heraus, dass dabei die Komplexi-tät der Diagramme verringert werden konnte, weil viele Aspekte, die zunächst in den SeeMe-Diagrammen dargestellt wurden, nun in den Screenshots der Maskenprototypen beinhaltet waren. Die Diagramme, die in der Validierungsphase des Projektes genutzt wurden, beinhalten jene Rollen, Aktivitäten und Entitäten, die notwendig sind, um die Arbeitsprozesse, die durch SpiW-Com unterstützt werden sollen, als Kontext der in den Masken enthaltenen Abläufe darzustellen.
... Software-Projektmanagement aus sozio-technischer Perspektive 15
Das Diagramm in Abbildung 7 enthält die Aktivität „fahrerbezogene Daten einge-ben“, welche die Entität „PocketPC – FahrerDaten“ nutzt. Der in der Entität markierte Hyperlink verweist auf die Abbildung der entsprechenden Benutzungsoberfläche im Pocket-PC. Die Darstellung der Masken des Pocket-PC im Rahmen eines sozio-technischen Diagramms erlaubt die Dokumentation ergänzender Hinweise. In diesem Beispiel findet sich zum einen der Modifikator „gemäß Vereinbarung“, der dokumen-tiert, dass es zu der Eingabe der fahrerbezogenen Daten noch weitergehende Vereinba-rungen geben muss. Zum anderen gibt es einen später hinzugefügten Kommentar, der darauf verweist, dass im „Westkreis“ nur Pausenzeiten und keine anderen die Person des Fahrers betreffenden Daten einzugeben sind. So dienen die sozio-technischen Diagram-me auch hier dazu, die im Laufe eines Projektes anfallenden Vereinbarungen zur Nut-zung der Software zu dokumentieren.
Das Diagramm in Abbildung 8 nutzt das Beispiel der Signalisierung von Änderungen an einer bereits überspielten Tour, um die Integration des Dokumentes „Funktionale Beschreibung“ in die SeeMe-Diagramme zu zeigen. Die „Funktionale Beschreibung“ dokumentiert die Funktionen der Software sowie die dazugehörigen Benutzungsoberflä-chen, wobei dieselben Funktionen in unterschiedlichen Arbeitssituationen Verwendung finden können. Die sozio-technischen Diagramme hingegen sind entlang der Arbeitspro-zesse organisiert und verweisen per Hyperlink auf das Spezifikationsdokument der Software, das u.a. die unterschiedlichen Prinzipien der Signalisierung erklärt.
4 Socio-Technical Walkthrough (STWT)
4.1 Prinzipien
Nimmt man die Idee eines interdisziplinären Projektmanagements zur Gestaltung eines sozio-technischen Systems ernst, so ist es nicht ausreichend, sozio-technische Aspekte zu dokumentieren. Bereits in den vorangegangenen Abschnitten ist angeklungen, dass sozio-technische Diagramme in einen kommunikativen Kontext eingebracht werden müssen, damit sie zur gezielten Veränderung von Arbeitsprozessen im Sinne einer Or-ganisationsentwicklung beitragen können. Sowohl die Modellierungsmethode SeeMe als auch die Workshop-Methode STWT wurden auf Grund eines systemtheoretischen An-satzes im Sinne Luhmanns entwickelt ([Luh 84], [Wil 94], [Kön 04], [Her 04a]).
Der socio-technical walkthrough (STWT) ist ein Workshop-Konzept, das Diagram-me, die ein zukünftiges sozio-technisches System modellhaft darstellen, nutzt, um den partizipativen Diskurs zur Planung computer-gestützter Arbeitsprozesse zu unterstützen. Die Diagramme werden in den Workshops zum einen eingesetzt, um die Diskussion zu strukturieren und zu leiten, und zum anderen, um Ergebnisse der Diskussion zu doku-mentieren. Dabei können die Modelle entweder durch die Teilnehmer in den Workshops selber erstellt, oder als vorbereitete Diskussionsgrundlage mitgebracht werden.
Für den STWT wurden Workshops als Vorgehensweise zur Einbindung der beteilig-ten Rollen gewählt, weil so alle die Möglichkeit haben, ihre jeweilige Perspektive mitzu-
16 Kunau, Menold, Herrmann, Loser
teilen, mit der von anderen Teilnehmern zu vergleichen und ein konsensfähiges Ergebnis zu erarbeiten. Andere Methoden, wie bspw. Interviews oder Arbeitsplatzbeobachtungen, sind insbesondere in frühen Projektphasen als Ergänzung sinnvoll, können aber partizi-pative Diskurse darüber, wie eine neue Software in Arbeitsprozesse eingebettet werden soll, nicht ersetzen.
So wie in anderen "Walkthrough"-Methoden der Informatik auch, werden in einem STWT-Workshop Artefakte schrittweise gesichtet, diskutiert und angepasst. Im STWT stehen die sozio-technischen Diagramme im Mittelpunkt der Betrachtung, wobei die schrittweise Sichtung von sorgfältig vorbereiteten Moderationsfragen geleitet ist. Im Unterschied zu „Walkthrough“-Methoden wie bspw. dem „cognitive walkthrough“ zur Gestaltung von Mensch-Maschine-Schnittstellen [Pol 92] wird der STWT aber nicht von einem einzelnen Prüfer durchgeführt. Vielmehr sollen alle Beteiligten ein gemeinsames Verständnis der zukünftigen, technisch unterstützten Arbeitsprozesse erlangen.
4.2 Einsatz in unterschiedlichen Phasen eines Projektes
Im Projekt „Westkreis“ wurden in allen Projektphasen sozio-technische Diagramme und STWT-Workshops eingesetzt: zu Beginn zur Unterstützung der Anforderungsanalyse, im Folgenden dann zur Validierung von Systementwürfen und zum Abschluss des Pro-jektes dann zur Qualifizierung der Fahrer und Disponenten. An den STWT-Workshops nahmen Vertreter der Fahrer und Disponenten, die Projektleitung Westkreis, ein Mana-ger der Unternehmenszentrale sowie ein Software-Entwickler teil. Hinzu kamen die Moderatorin, eine wissenschaftliche Protokollantin sowie fallweise eine Person, die die Bedienung des Editors zum Zeichnen der Diagramme übernahm.
Erhebungsphase zur Vorbereitung
Die Methode der teilnehmenden Beobachtung wurde zu Beginn des Projektes eingesetzt, um das Anwendungsfeld kennen zu lernen. Disponenten und Fahrer aus drei Niederlas-sungen wurden an insgesamt neun Arbeitstagen begleitet und beobachtet, um die Details der Arbeitsabläufe aufnehmen zu können. Interviews und Dokumentenanalysen ergänz-ten die Erhebung. Zur Dokumentation wurde unter anderem ein erstes Übersichtsdia-gramm über die Arbeitsprozesse der Fahrer und Disponenten sowie der zwischen ihnen ausgetauschten Informationen erstellt. Abbildung 9 zeigt einen Ausschnitt.
... Software-Projektmanagement aus sozio-technischer Perspektive 17
Abb. 9.: Ausschnitt eines STWT-Diagramms aus der Erhebungsphase
18 Kunau, Menold, Herrmann, Loser
STWT zur Anforderungsanalyse
Als Teil der Anforderungsanalyse wurden STWT-Workshops durchgeführt. Zunächst ging es darum, das Feedback der Beteiligten auf die Darstellung des Status-quo (siehe Abbildung 9) einzuholen. Die Moderationsfrage anhand derer das Diagramm schrittwei-se diskutiert wurde, war „Haben wir [d.h. die Wissenschaftler] das richtig verstanden?“.
Nachdem so ein Diagramm des Ist-Zustands erarbeitet worden war, mit dem alle zu-frieden waren, wurde mit der nächsten Frage die Phase der Anforderungsanalyse begon-nen: „Welche Daten sollen mit der neuen Technik übermittelt werden?“ Diese Frage galt es zu klären, da im Projektmanagement kein klares Bild darüber herrschte, welche In-formation über das neue System zu vermitteln sei.
In einem weiteren STWT-Workshop wurden alle Diagrammelemente unter folgen-den Fragestellungen durchgegangen: Für jede Aufgabe / Aktivität wurde gefragt: Wie kann SpiW-Com diese Aufgabe unterstützen? Für jede Information (dargestellt als Enti-täten) wurde gefragt: Wie kann SpiW-Com diese Information aufnehmen und weiterlei-ten? Im Verlaufe der Projektarbeit entstanden so Modelle, welche die zukünftige Nut-zung des Systems darstellten. Abbildung 2 ist ein Beispiel eines solchen Diagramms.
STWT zur Validierung von Maskenprototypen
Die Validierung von Maskenprototypen des mobilen Kommunikationssystems stand im Mittelpunkt der dritten Projektphase. Die Diskussionen in den STWT-Workshops dien-ten nicht nur dazu, die Masken unter dem Aspekt ihrer Ergonomie und internen Logik, sondern auch hinsichtlich ihrer Sinnhaftigkeit im Kontext der Arbeitsprozesse zu evalu-ieren. Zu diesem Zweck waren die Diagramme mit Screenshots der Maskenprototypen verlinkt worden (vgl. Abbildung 7) und wurden unter folgenden Fragestellungen durch-gegangen: Sind die Masken so gut zu bedienen? Passen die Masken und Funktionen in die Arbeitsabläufe?
STWT im Rahmen von Qualifizierungsmaßnahmen
In der abschließenden Qualifikationsphase wurde zunächst die Nutzung des technischen Systems SpiW-Com geschult bevor ein STWT-Workshop den Beteiligten den Rahmen bot, um Absprachen zur Nutzung von SpiW-Com in ihrem Arbeitsalltag zu treffen. Im Sinne einer integrierenden Gestaltung war es hier wichtig, dass Fahrer und Disponenten die Nutzung ihrer jeweiligen Software-Komponenten nicht getrennt erprobten, sondern in einem gemeinsamen Workshop. Auf diese Weise konnten Probleme bei der Zusam-menarbeit identifiziert und gelöst werden. Die Diagramme mit den neuen, technisch unterstützten Arbeitsprozessen, die zuvor in der Schulung eingesetzt worden waren, wurden genutzt, um weitere Absprachen hinsichtlich der Nutzung von SpiW-Com zu treffen und zu dokumentieren (vgl. Abschnitt in 3.2). Abbildung 5 zeigt ein Ergebnis.
... Software-Projektmanagement aus sozio-technischer Perspektive 19
5 Feedback der Beteiligten und Fazit
Im Anschluss an den letzten STWT im Rahmen der Qualifizierungsmaßnahmen wurden die Teilnehmer zu Evaluationszwecken interviewt. Alle Workshopteilnehmer, darunter auch zwei beteiligten Fahrer fanden es sehr sinnvoll, die zukünftige Nutzung des mobi-len Kommunikationssystems von Disponenten und Fahrern gedanklich durchzugehen und insbesondere Absprachen zwischen Disponenten und Fahrern bezüglich der neuen Kooperationsprozesse zu treffen. Dabei wurde betont, dass die Entwicklung gemeinsa-mer Vorstellungen über die Verwendung des Systems notwendig ist und durch solche Absprachen ermöglicht wird: „Das halte ich für sehr notwendig, weil sonst das System
von jedem anders verstanden und genutzt wird. Daraus resultiert, dass die Nachfragen
per Handy kommen müssen, sonst versteht der eine gar nicht, was der andere ihm
schickt“ (Disponent). Die Visualisierung während des Workshops durch die Verwendung graphischer Mo-
delle wurde von den meisten Teilnehmern als hilfreich empfunden. Dazu äußerten die Workshopteilnehmer beispielsweise: „Man hat auch gemerkt, und in Gesprächen hat es
sich immer wieder ergeben, dass an der einen oder anderer Stelle dort noch was getan
werden muss oder irgendwas neu abgesprochen wurde, speziell genau diese Nachfrage-
Geschichte [gemeint war, dass der Fahrer beim Disponenten bei weisungspflichtigen
Problemen nachfragt], das wurde online, vor Ort dort modelliert“ (Vertreter des Mana-gements). Gerade die Modellierung während des Workshops durch die Moderatorin kann Teilnehmer, die andere Visualisierungstechniken gewöhnt sind, aber auch irritie-ren. So wurde angemerkt, dass der Bezug zwischen der laufenden Diskussion und der (neuen) Symbole im Modell nicht immer hergestellt werden konnte.
Die Modelle wurden als hilfreich empfunden, weil sie die Verwendung des Systems und die Arbeitsprozesse zueinander in eine Verbindung setzen. Es wurde beispielsweise geäußert: „[Die Modelle waren während der Diskussion hilfreich], weil man den Pro-
zess schön durchgehen kann“ (Vertreter des Managements); „… das zählt im Prinzip
zusammen. Die Arbeit und dieses System und dieses Modell der Arbeit, was man da
macht. Das muss ja in sich greifen …Das greift ja auch in sich. Funktioniert doch so
weit“ (ein Fahrer). Die Fahrer hoben diesen Aspekt der Modelle insbesondere in der Rückmeldung zu deren Nutzung als Schulungsunterlagen hervor, wenn es darum ging, den Umgang mit dem Kommunikationssystem zu erlernen: „Ja, klar, man muss ja wis-
sen, mit welchen Gedanken, oder was man jetzt macht, wenn man den nächsten Schritt
im Softwareprogramm macht“. Die Modelle als Projekt-Dokumente könnten in den Augen der Workshopteilnehmer
nicht nur im Rahmen eines STWT-Workshops oder einer Schulung verwendet werden, sondern auch von den Fahrern und Disponenten in deren alltäglichen Arbeit mit dem neuen System. So der beteiligte Disponent: „Ich finde von der Dokumentation, das
heißt, die Art der Modellierung, dass ich es visuell habe und nicht runtergeschrieben -
finde ich eigentlich sehr gut. Einfach aus dem Grunde, wenn ich es dem Fahrer ins
20 Kunau, Menold, Herrmann, Loser
Fahrhaus lege, dann kann er schnell sehen, wie er zu reagieren hat.“ Dabei wurde je-doch an die Modelle eine Anforderung gestellt, dass sie sehr einfach sein sollen und eine weitere, dass in Modellen Hinweistexte auf die Masken des Kommunikationssystems enthalten werden sollten: „Was vielleicht später im Ablauf noch ein kleines Problem ist,
dass zum Beispiel der Fahrer in einer anderen Maske was sendet als der Disponent
empfangen würde oder haben wollte, was hier nicht angegeben ist“ (Disponent). Diese Rückmeldung der Beteiligten zeigt, dass der STWT und die Modelle sinnvoll
für einen Projektschritt wie die Qualifizierung der Nutzer eingesetzt werden können und dass die erarbeiteten Modelle als Dokumente für die Nutzer verwendet werden können. Dabei ermöglicht insbesondere die Darstellung der Systemnutzung bezogen auf die Arbeitsprozesse eine Strukturierung des zukünftigen Kooperationsprozesses im Laufe eines STWT und erleichtert außerdem den Nutzern beim Einsatz des Systems, seine Verwendung für ihre Arbeit zu verstehen und zu erlernen.
In der vorgestellten Fallstudie „Westkreis“ konnte gezeigt werden, dass sozio-technische Dokumente, die in einen kommunikativen Kontext eingebettet werden, zur integrierten Gestaltung von Technik und Organisation beitragen können. Sie bieten sich damit als ein Hilfsmittel für ein interdisziplinäres Projektmanagement von Software-Entwicklungsprojekten an. Die in der Fallstudie gewonnen Erkenntnisse fließen derzeit insbesondere in zwei Forschungsrichtungen ein: Zum einen in die weitere Ausarbeitung des Workshop-Konzepts STWT, wobei insbesondere versucht wird, die Erstellung und Bearbeitung von Modellen innerhalb der Workshops zu optimieren; zum anderen in die noch engere Integration der sozio-technischen Diagramme mit anderen Dokumenten und Werkzeugen des Projektmanagements.
Literatur
[Erk 05] Elmar Erkens; Thomas Herrmann; Malte Hülder; Lothar Schöpe (Hrsg.): Mobile Speditionslogis-
![Tallinna ajaloo lugemik. Dokumente 13.-20. sajandini [Documents from the History of Tallinn, 13th - 20th c.] Koost./Compiled by Tiina Kala, Juhan Kreem, Lea Kõiv, Kalmer Mäeorg,](https://static.documents.pub/doc/80x56/631e17610ff042c6110c2e3e/tallinna-ajaloo-lugemik-dokumente-13-20-sajandini-documents-from-the-history.jpg)
