Unternehmen, die mit dynamischen Wettbewerbsbedingungen konfrontiert sind, entwickeln in der Regel eine flexible und dezentralisierte Arbeitsorganisation, die auf Teams und Projekten basiert. Da die Anforderungen jedoch weiter steigen, Unsicherheit zu bewältigen, auf neue Situationen zügig zu reagieren und komplexe Aufgaben zu lösen, wird eine „collaborative organisation“ (Beyerlein et al. 2003) als Lösung diskutiert, welche durch eine flexible sowie temporäre, oftmals informelle Vernetzung von Personen oder Teams die Reaktionsfähigkeit steigern könne. Tatsächlich lässt sich ein historischer Trend von „konventionellen“ hierarchischen und funktional differenzierten zu stärker virtuell und als Netzwerk gestalteten„neuen“ Organisationsformen verzeichnen (Aroles et al. 2019; Child 2015). Diese Entwicklung wird sehr stark durch die technologischen Möglichkeiten des flexiblen, orts- und zeitunabhängige Arbeitens angetrieben (Warner und Witzel 2004) und nutzt Formen des „temporären Organisierens“ (Braun und Sydow 2017).

Vor diesem Hintergrund werden zunehmend kollaborative Anwendungen eingesetzt, die als Arbeitsplattformen der Zusammenarbeit eine flexible Arbeitsorganisation in den Unternehmen unterstützen soll. Bei Kollaborationsplattformen handelt es sich um integrierte Anwendungen, die vielfältige Funktionen für die raum- und zeitunabhängige virtuelle Zusammenarbeit von Teams, Projekten sowie den firmenweiten Austausch an einem virtuellen Ort im Netz zur Verfügung stellen. Mit dieser übergeordneten technischen Infrastruktur ist auch die flexible Einbindung von Externen möglich. Diese Anwendungen, die unter ganz verschiedenen Begrifflichkeiten diskutiert werden (Hardwig et al. 2020), unterscheiden sich von bisherigen Groupware-Anwendungen, die auf E-Mail basieren, wesentlich (McAfee 2009), indem sie Potenziale für eine teamübergreifende, netzwerkartige Zusammenarbeit bieten (siehe Kap. 10 in diesem Band).

Bisherige Forschungen führen vor Augen, dass eine reine technische Bereitstellung von Software nicht ausreicht: Eine effiziente Nutzung von Kollaborationsplattformen verlangt vielfältige organisationale, räumliche, technische sowie soziale Voraussetzungen zu schaffen (Greeven und Williams 2017). Durch die Möglichkeiten von mehr Selbstorganisation der Teams durch den Einsatz dieser Plattformen werden insbesondere hierarchische Arbeits- und Organisationsstrukturen herausgefordert. Unser Beitrag knüpft hier an. Wir werden an drei Fallbeispielen die vielschichtigen Entwicklungsprozesse in der ArbeitsgestaltungFootnote 1 nachzeichnen, die Unternehmen auf der Suche nach dem digitalen Arbeitsplatz mit Kollaborationsplattformen machen. Die Implementierung passender technischer Infrastruktur für die Organisation und Arbeit lässt sich als ein vielgestaltiger kollektiver Such- und Entwicklungsprozess fassen. Entwicklungsrichtungen werden abgebrochen und Neuanfänge gesucht, Ansätze werden verfolgt, überdacht und in anderer Form weiterverfolgt.

Wir gehen davon aus, dass sich dies nicht alleine mit fehlenden Kompetenzen der an der Arbeitsgestaltung beteiligten Menschen, systematischen Problemen mit der Gestaltung des Einführungsprozesses oder mit Fehlern in der technischen Auslegung der Systeme erklären lässt. Unsere These ist vielmehr, dass die mit den Implementierungsprozessen verbundenen Suchbewegungen unvermeidlicher Ausdruck der Notwendigkeit sind, eine tragfähige Lösung für ein komplexes Problem zu entwickeln. Die Komplexität resultiert aus der Vielzahl sozialer, organisatorischer und technischer Einflussfaktoren, welche die Gestaltung der Nutzung von Kollaborationsplattformen bestimmen, und ihre kaum antizipierbaren Wechselbeziehungen. Damit die betrieblichen Akteure die Bedingungen gestalten können, müssen sie sich auf einen Such-, Lern- und Entwicklungsprozess einlassen, dessen Ergebnis nicht im Voraus geplant werden kann, sondern durch die Akteure gefunden werden muss.

Unser Beitrag gliedert sich wie folgt: Zunächst stellen wir die empirischen Grundlagen unserer Analyse sowie die Unternehmen, die als Fallbeispiele dienen, kurz vor. Im Anschluss daran beschreiben wir, in einer verdichteten Form, wer die Verantwortung für Fragen der Arbeitsgestaltung übernommen hat, wie das Unternehmen die Nutzung der Kollaborationsplattformen gestaltet hat und welche Entwicklungsprozesse sich in den drei Jahren, die wir sie begleitet haben, beobachten ließen. In einem abschließenden Teil reflektieren wir, was wir aus diesen Entwicklungsprozessen für eine systematische Gestaltung der Arbeit mit Kollaborationsplattformen lernen können und kommen zu Empfehlungen für eine prozessorientierte, agile Arbeitsgestaltung.

9.1 Methodische Grundlagen und Datenbasis

Empirische Grundlage für die folgende Ergebnisdarstellung bilden drei Fallstudien aus mittelgroßen Unternehmen. Diese verfügen bereits über mehrjährige Erfahrungen mit kollaborativen Anwendungen und zeichnen sich durch eine avancierte Nutzung von Kollaborationsplattformen aus. Wir beobachten also nicht die erstmalige Einführung, sondern die Weiterentwicklung der Nutzung (verbunden mit der Einführung neuer IT-Werkzeuge). Das Unternehmen „C“ ist ein Consulting-Unternehmen (ca. 90 Beschäftigte), das für Kunden den „digitalen Arbeitsplatz“ implementiert. „S“ ist ein Unternehmen für kundenspezifische Software-Entwicklung (ca. 250 Beschäftigte). Der Sondermaschinenbauer M (ca. 380 Beschäftigte) stellt Automationsanlagen zur Montage und Prüfung mechatronischer Bauteile für unterschiedliche Branchen her. Alle drei stehen vor der Herausforderung, die räumlich verteilte Zusammenarbeit im Unternehmen mit dem Einsatz von Kollaborationsplattformen zu unterstützen (Hardwig 2019).

Die Empirie wurde im Rahmen des Verbundprojektes CollaboTeam in den Jahren 2017 bis 2020 erhoben.Footnote 2 Grundlage der Auswertung bilden 88 leitfadengestützte Interviews von ca. 90 min Dauer und 12 zweistündige Gruppendiskussionen (35 Interviews 2017, acht Interviews 2018, 43 Interviews sowie 12 Gruppendiskussionen 2019 und ein Interview 2020). Befragt wurden Beschäftigte und Personen aus dem Management, die mit kollaborativen Anwendungen arbeiteten und/oder für die Gestaltung des Einsatzes der Kollaborationsplattformen verantwortlich waren. Es handelt sich dabei vor allem um höherqualifizierte Angestellte mit Berufen aus dem Ingenieurswesen, Informatik, Betriebswirtschaft oder den Sozialwissenschaften, die im Bereich der Wissensarbeit tätig sind. Weitere Datenquellen sind Beobachtungen und Gespräche, die im Rahmen der wissenschaftlichen Begleitung entstanden.

9.2 Such- und Entwicklungsprozesse: Drei Fallbeispiele

In den drei im Mittelpunkt stehenden Unternehmensfällen wurden zum Beginn der wissenschaftlichen Begleitung 2017 unterschiedliche Ansätze verfolgt, mit der sie die Arbeit mit einer Kollaborationsplattform weiterentwickeln wollten, wobei sie versuchten, sich der Vision eines „digitalen Arbeitsplatzes“ anzunähern.

Das Maschinenbau-Unternehmen M, hatte sich eine Kollaborationsplattform zum Ziel gesetzt, mit der sich Arbeitsprozesse automatisieren lassen. Dabei stellten sie die Unterstützung der Beschäftigten bei der Erfüllung von Aufgaben ins Zentrum. Sie verfolgten das Ziel, mit einer Plattform Prozesse unterschiedlich komplexer Aufgaben abzubilden, die sie in drei Stufen einteilten und in einem Pyramidenmodell darstellten: Dessen Basis bilden einfache Routineprozesse (z. B. Angebotsprozess einer Anlage), die nächste Schicht vielschichtige Projektprozesse sowie an der Spitze komplexe Managementaufgaben. Die Grundüberlegung der Verantwortlichen war, dass alle Prozesse im Kern aus Aufgaben bestehen und sich daher durch die gleiche Grundstruktur auszeichnen, entsprechend könnten sie mit der gleichen Anwendung abgebildet werden. Während die Routineprozesse stärker durch Vorgaben gesteuert und gezielt mit Formularen, Daten und weiteren Informationen unterstützt werden können, sind die Prozesse der höheren Ebenen offener, weshalb die Nutzerinnen und Nutzer über größere Freiheitsgrade verfügen müssen. Zudem wurde bewusst nicht das Team ins Zentrum gestellt, sondern die Aufgabe, weil Teams zwar eine Aufgabe haben, aber nicht alle Prozesse in einer Organisation durch Teams erfüllt werden.

Das IT-Consulting-Unternehmen C, ein Beratungsdienstleister zur Umsetzung von Digital Workplace-Lösungen, hatte sich aus strategischen Gründen bereits vor Projektbeginn für einen Wechsels in der IT-Ausstattung von einer IBM- zu einer Microsoft-Architektur entschieden. Entsprechend waren die technischen Grundlagen bereits gelegt worden. Für das Projekt wurde als Ziel formuliert, schrittweise den Wechsel im Einsatz der Anwendungen vorzunehmen, um die O 365 Cloudlösung als „digitalen Arbeitsplatz“ zu realisieren. Oberflächlich betrachtet, sollten die Beschäftigten lediglich zu funktional äquivalenten Anwendungen eines anderen Herstellers wechseln. Genau besehen waren die Lotus-Anwendungen jedoch unternehmensspezifisch konfiguriert und mit den Kernprozessen des Unternehmens eng verknüpft. Während die neue Architektur nun durch Standardsoftware gestellt wurde, welche sich durch einen hohen Grad an Integration einer Vielzahl von Einzelanwendungen sowie Cloud-Services auszeichnet. Fraglich war also, wie der Wechsel der Anwendungen in den unterschiedlichen Arbeitsbereichen so umgesetzt werden konnte, dass die Zusammenarbeit mit den neuen Werkzeugen optimal unterstützt werden konnte.

Das Unternehmen S, das kundenspezifische Unternehmenssoftware entwickelt, hatte Jahre vor dem Projekt einen Strategiewechsel vollzogen. Bis dahin waren sie als IT-Dienstleister aufgetreten, dessen Beschäftigte bei den Kunden tätig waren. Dies bedeutete für jene, dass sie in die Kundenteams integriert und vier bis fünf Tage die Woche dort auch tätig waren. Der Strategiewechsel beinhaltete eine Spezialisierung und Neuausrichtung zum Anbieter für Individualsoftware-Entwicklung mit einem agilen Arbeitskonzept (Schwaber und Sutherland 2017). Zudem wurde, um das Unternehmen für Fachkräfte attraktiv zu machen, auf die abnehmende Reisebereitschaft der hochqualifizierten Beschäftigtengruppen reagiert, indem ein Konzept räumlich verteilter Zusammenarbeit realisiert wurde. Dies hatte den Vorteil, dass die Beschäftigten überwiegend an ihrem Heimatstandort eingesetzt werden konnten. Es stellt aber die Anforderung, dass nun die Möglichkeiten geschaffen werden mussten, dass die agilen Software-Entwicklungsteams über mehrere Standorte hinweg arbeiten konnten. Denn in den meisten Fällen wurden die Projekte weiterhin in gemeinsamen Teams mit Mitarbeiterinnen und Mitarbeitern aus den Kundenunternehmen realisiert. Eine räumlich verteilte Zusammenarbeit wird bei agiler Softwareentwicklung zumeist vermieden (Tietz und Mönch 2015), denn für den Erfolg wird eine gemeinsame Vorstellung von allen Facetten des Entwicklungsauftrages sowie ein laufender Wissensaustausch zwischen allen Mitgliedern des interdisziplinären Teams als notwendig angesehen. Dies kann nur durch intensive laufende Kommunikation (z. B. Daily Meetings) sowie eine intensive Reflexion der Zusammenarbeit (z. B. Retrospektiven) (Schwaber und Sutherland 2017) gesichert werden. Diese Intensität der Kollaboration war bis dahin nur in einem Präsenzteam vorstellbar, aber das Unternehmen musste nun damit beginnen, eine räumlich verteile, agile Zusammenarbeit in virtuellen Teamräumen systematisch zu entwickeln. Im Unterschied zu den beiden anderen Unternehmen geht die Entwicklung nicht von einer Veränderung der Technik aus, obwohl kollaborative Anwendungen auch hier einen unverzichtbaren Beitrag für die verteilte Zusammenarbeit leisten.

Soweit die Ausgangsposition, wie stellten sich die Entwicklungsprozesse jeweils dar?

9.2.1 Leitungsgetriebene Entwicklung – das Maschinenbau-Unternehmen M

Die Federführung für die Entwicklung des digitalen Arbeitsplatzes im Maschinenbau-Unternehmen M lag bei dem geschäftsführenden Unternehmer, der dies gemeinsam mit einem Leiter einer Stabstelle realisiert, der quasi die Funktion eines Industrial Engineering wahrnimmt und über Erfahrungen in der Prozessoptierung und der Implementierung sowie Entwicklung von Software verfügt. Beide hatten seit langer Zeit neue Möglichkeiten der Unterstützung des betrieblichen Wissensmanagements und der innerbetrieblichen Kommunikation erprobt und realisiert. In dieser Konstellation wurden Fachabteilungen wie v. a. die IT bedarfsweise hinzugezogen.

Für die Entwicklung einer Plattform zur Prozessautomatisierung wurden auf Basis langjähriger Erprobungen und Erfahrungen, die Anforderungen an eine geeignete Software formuliert und auf dieser Grundlage systematisch die verfügbaren Softwareprodukte bewertet. Im Frühjahr 2017 wurden dann zwei Produkte von BPM Software (Business-Process-Management) identifiziert, die versprachen Workflows, ohne langwieriges Programmieren direkt modellieren zu können. In einem halbjährigen intensiven Prozess erfolgten Auswahl, Investitionsentscheidung und Implementierung und zum Jahresende liefen interne Qualifizierungen und Tests mit zehn ausgewählten Führungs- und Fachkräften, die als Prozessmodellierer von ihnen verantwortete Prozesse exemplarisch modellieren sollten.

Anfang 2018 trat Ernüchterung ein, denn die BPM-Software erfüllte die Anforderungen nicht ausreichend, die Zielgruppe konnte das Programm keineswegs intuitiv bedienen und sie war auch damit überfordert, die von ihr verantworteten Prozesse fachlich angemessen so zu modellieren, dass sie mithilfe des Programms zu gestalten waren. Im Sommer 2018 waren fünf Prozesse (z. B. Rechnungsprüfung, Investitionsantrag, Einstellungsprozess) mit dem BPM Programm abgebildet und nach zahlreichen Versuchen, die Probleme in den Griff zu bekommen, wurde das Projekt abgebrochen.

„Die wichtigste Erfahrung (…) dass wir einen Mega-Fail hingelegt haben… und dass wir aber aus diesem Mega-Fail so viel gelernt haben und zwar in einer Systematik gelernt haben, die wir in dieser Form aus meiner Sicht in Ablauf und der Qualität und in der Tiefe …noch nie gemacht haben.“ (M1997b-12 Führungskraft)

Und zwar hätten sie nicht nur über die Bedingungen für die Gestaltung der Plattform, sondern auch über die Anforderungen durch ihre Arbeitsorganisation sehr viel gelernt.

Die Zielsetzung und das dreistufige Modell der zu unterstützenden Prozesse wurden jedoch bekräftigt und stattdessen beschlossen, eine Anwendung selbst zu programmieren – ein Ansatz, die bereits vor der Anschaffung der Software bestand – welche die Anforderungen besser erfüllen sollte. Dafür wurden sogar Software-Entwickler neu eingestellt. Zudem wurde 2019 eine Innovationsorganisation mit spezialisierten Businessprocess-Consultants aufgebaut, welche die Aufgabe der professionellen Prozessmodellierung an Stelle der Führungskräfte übernehmen sollten. Ende 2019 war der Start der Arbeit mit der Prozessplattform und die ersten Freigaben der optimierten Prozesse vorgesehen, die Planungen verzögerten sich immer wieder. Die konkreten Umsetzungen bezogen sich zunächst auf einfache Prozesse.

Da früh erkennbar wurde, dass eine baldige Unterstützung durch das BPM-System für die Projektplanung (zweite Stufe des Modells) nicht zu erwarten war, wurde bereits Anfang 2018 mit externer Unterstützung ein eigenes Projekt zur Optimierung der Projektplanung gestartet. Ebenfalls 2018 wurde MS Teams getestet, obwohl diese Anwendung nicht mit dem Zielkonzept vereinbar war, da es auf dem Prinzip einer Teamplattform basierte und nicht die Aufgabe ins Zentrum stellte. Aber die Standorte in Übersee sollten digital an den deutschen Standort angebunden werden. Da das Unternehmen Office 365 im Einsatz hatte, stand MS Teams im Unterschied zur BPM-Anwendung zur Verfügung. Aufgrund des wahrgenommenen Handlungsdrucks in der internationalen Zusammenarbeit machte es der dafür zuständige Geschäftsführer zu seiner persönlichen Angelegenheit, MS Teams in diesem Bereich selbst zu erproben. Er bestimmte die ersten Teams und entwickelte die entsprechenden Regeln für die Nutzung der Anwendungen und die künftige Zusammenarbeit in den internationalen Projekten. Dabei beteiligte er fallweise weitere Expertinnen oder Experten aus dem Unternehmen oder Projektmitglieder an der Erprobung und Weiterentwicklung dieser Regularien. Im Zentrum stand ein Verhaltenskodex, in dem die Benutzung der Plattform und die Organisation der Zusammenarbeit geregelt wurden.

„Richtig, wir haben den Kodex aufgeschrieben, wir haben geschult, wir haben gefragt: Ist das okay für euch? Wir haben ihn ausprobiert, wir haben ihn verteidigt, wir haben ihn weiterentwickelt … also wir leben den, wir (…) behandeln Problemfälle, (…) die werden dann angesprochen, (…) und ohne diesen Kodex, der das alles zusammenhält, passiert da gar nichts.“ (M1997a -25 Führungskraft).

Nach einer ersten Pilotphase wurde die Nutzung schnell ausgeweitet und die entwickelten Bedienungshinweise und Nutzungsregeln in halbtägigen Schulungen an weitere Mitarbeiterinnen und Mitarbeiter vermittelt. Diese Schulungen wurden überwiegend durch den Geschäftsführer persönlich geleitet, unterstützt durch seinen Assistenten. Im Hintergrund leistet die IT-Abteilung entsprechende Zuarbeiten, um technischen Funktionalitäten und die Datensicherheit zu gewährleisten.

Aufgrund der sich hinziehenden Umsetzung der BPM-Plattform und der ersten Erfolge der MS Teams Nutzung entwickelte sich Ende 2018 eine Art Wettbewerb, welche der beiden Ansätze die Grundlage für den digitalen Arbeitsplatz bilden könnte. Dies wurde im Management kontrovers diskutiert. Denn weiterhin gingen die Verantwortlichen davon aus, dass eine Anwendung das Zentrum des digitalen Arbeitsplatzes bilden sollte, die jeweils andere könnte darin unter Umständen als App integriert werden.

Die Reaktion aus dem Management und von Beschäftigten beschleunigte dann jedoch die Umsetzung von MS Teams. Durch die O 365 Cloud-Lösung hatte die IT-Abteilung erst einmal den Schock zu verarbeiten gehabt, dass „Microsoft das ermöglicht, dass jeder x-beliebige Mitarbeiter x-beliebige Daten teilen kann mit x-beliebigen Leuten. Und die müssen nicht alle im Unternehmen sein. Das mussten wir erst mal alles verrammeln, weil wir gar nicht das steuern können, wo Daten abfließen.“ (M1878-IT) Diese ersten Erfahrung schlug sich in dem Bild vom „Wildwuchs“ nieder, dass von neun Interviewpartnern unabhängig voneinander gebraucht wurde. Die Konsequenz des Managements war eine starke Reglementierung der Nutzung, welche aber auch auf deutliche Kritik stieß.

„[B4:] Ausschließlich er legt fest und gibt frei, wer ein Team haben darf. (…). Ähm (...) genau um diesen Wildwuchs sozusagen (…) auch ein bischen einzufangen (…) Kollegen haben dann gefragt, wieso können wir denn das nicht nehmen und das nicht nehmen und wir haben hier das mal ausprobiert und puh ja, ne? Unverständnis. Unverständnis. (…) Er hat zu mir gesagt, ich habe es den Kollegen versprochen, jetzt müssen wir liefern, ja? Die wollen arbeiten, die wollen tun, ja? Äh ja und daran sind wir ja jetzt.“ (M1986-447 Gruppendiskussion Manager)

Insbesondere die Frage der Berechtigung der Nutzung wurde heiß diskutiert und ein Umsetzungsdruck entstand, MS Teams breiter zur Verfügung zu stellen.

„[B2:] Also in meinem Team wird schon gefragt, wann kriegen wir denn das endlich. So weil (...) das hat ja schon schöne Funktionen. Also ich würde es gerne auch nutzen, um Aufgaben zu sehen die wir verteilt haben. (…) ist halt derzeit nicht freigegeben und das stößt natürlich auch ein bisschen auf Unmut.“ (M1986-449 Gruppendiskussion Manager). [B3:] „Ich find ja die Regel auch okay, wenn mir jemand sagt, du darfst da kein wildwuchsmäßiges Teams anlegen. Aber wenn ich sage, ich hätte gerne ein Team aus folgenden Gründen und dann krieg ich das nicht, das find ich irgendwie nicht nachvollziehbar“. (M1996-304 Gruppendiskussion Mitarbeiter)

Die Geschäftsführung reagierte darauf, indem sie die Nutzung von MS Teams schrittweise erweiterte. Zum einen wurde die Koordination der wöchentlichen Steuerungsrunde der laufenden Projekte mit MS Teams unterstützt, zum anderen sollten Organisationsbereiche jeweils einen Teamraum bekommen, um die bereichsinterne Zusammenarbeit zu verbessern.

Am Ende des Beobachtungszeitraums Anfang 2020 war folgender Stand erreicht: Die ursprüngliche Zielsetzung des digitalen Arbeitsplatzes wurde weiterverfolgt, jedoch wurde nun davon abgesehen die drei Ebenen des Pyramidenmodells mit einer Kollaborationsplattform abbilden zu wollen. Die Geschäftsführung plante eine parallele Nutzung der digitalen Prozessautomatisierungsplattform, von MS Teams und weiteren Applikationen. Denn auch die selbst entwickelte digitale Prozessautomatisierungplattform hatte sich in den Augen des Geschäftsführers schließlich bewährt. Da die Abbildung von sechs Prozessen (z. B. Zeiterfassung, Auftragsdurchlauf, Einstellungsprozess) erhebliche Wirtschaftlichkeitseffekte (u. a. Wegfall von Suche- und Wartezeiten; geringerer Aufwand der Bearbeitung; Automatisierung von Prozessschritten) sichtbar gemacht hatte, sollte dieser Weg konsequenter Prozessautomatisierung fortgesetzt werden. Beide Anwendungen tragen zur Realisierung des Pyramidenmodells bei, die Prozessautomatisierung gestaltet die routinisierteren Prozesse, MS Teams unterstützt die Koordination der Projektarbeit und die Zusammenarbeit von Teams mit komplexeren Aufgaben. Interessant ist, dass nun auch die Weiterentwicklung eines seit vielen Jahren genutzten Wiki-Systems als eigenständige Anwendung auf die Tagesordnung gesetzt wurde. Es sollte global aufgesetzt und zudem überprüft werden, ob ein besser geeignetes Produkt dafür einsetzbar wäre.

Die Arbeitsgestaltung in diesem Prozess wird durch zwei Akteursgruppen vorangetrieben: Die Industrial Engineering Funktion gestaltet die klassische Prozessoptimierung und übernimmt zunächst Auswahl und Implementierung der Prozessoptimierungsplattform und schließlich die hauseigene Entwicklung der IT-Werkzeuge. Die Geschäftsführung und ihr Stab verantworten die Einführung von MS Teams in Projektbereichen. Dabei beschränkte sie sich auf der Grundlage der technischen Betreuung durch die IT Abteilung zunächst auf die Bildung von Teams, die Entwicklung und Festlegung von Berechtigungskonzepten sowie Nutzungsregeln. Zudem führten sie Schulungen durch. In weiteren Schritten wurde dann die Nutzung von MS Teams auf die wöchentliche Planungsrunde des Managements und die Zusammenarbeit im Top Management ausgeweitet. Dabei haben die Beschäftigten mit ihrer Einforderung einer stärkeren Autonomie bei der Nutzung und Transparenz der Inhalte auf der Projektplattform nicht unwesentlich zu ihrer Verbreitung beigetragen. Es entstand zwar eine größere Diskussion, inwieweit die Kollaborationsplattform geöffnet werden soll, der Modus der Top-down Umsetzung und die strenge Reglementierung der Nutzung blieben jedoch bestehen.

9.2.2 Schrittweises Vorgehen – das IT-Consulting Unternehmen C

Bei der IT-Consulting Firma C zielte das Umsetzungsprojekt darauf, schrittweise auf das Arbeiten mit Office 365 umzustellen. Betreut wurde die Umsetzung durch ein Projektteam aus Expertinnen und Experten unterschiedlicher Bereiche (Technik, Consulting), das für bestimmte Projektaufgaben auf zusätzliche Ressourcen zurückgreifen konnte.

Da die gesamte Firma bereits seit Jahren mit kollaborativen Anwendungen verschiedener Hersteller gearbeitet hatte, war das örtlich flexible und in hohem Maße transparente Arbeiten mit einer Kollaborationsplattform bereits fest etabliert. Bei einer Befragung der wissenschaftlichen Begleitung ergab sich der Durchschnittswert von 33 % der Arbeitszeit im Homeoffice, 14 % auf Reisen oder bei Kunden. Die Transparenz wurde sowohl durch unternehmensweit fungierende Social Media Tools (Messenger, Foren, Wiki-System) als auch durch ein Customer-Relationship-Management-System (CRM) sichergestellt, das Projektmitarbeiterinnen und Projektmitarbeitern vollen Einblick in alle Projektunterlagen ermöglichte. Das Zusammenspiel der verschiedenen Anwendungen wurde sehr stark durch programmierte Workflows unterstützt, wie z. B. die automatisierte Ablage von Emails in Kundenakten des CRM. In der Vergangenheit hatte das Management sehr viel Wert darauf gelegt, die Nutzung der verschiedenen Anwendungen (was wofür) und die Vorgehensweisen der Dokumentation und Ablage von Wissen (wie) mittels Regelungen festzulegen, die auch beim Eintritt neuer Mitarbeiterinnen oder Mitarbeiter intensiv vermittelt und in einem hohem Maße verbindlich gehandhabt worden sind.

Das Projektteam machte keine mehrjährige Umsetzungsplanung, sondern nahm sich nach einer Bestandsaufnahme für eine erste Phase des Wechsels von der IBM- zur Microsoft-Architektur den Austausch von Lotus Notes und Sametimes durch Outlook und Skype vor. Mit dem Anschalten der neuen Anwendungen zum Stichtag, standen die alten nicht mehr zur Verfügung. Es musste daher ein Übergangskonzept erarbeitet werden, das für alle Mitarbeiterinnen und Mitarbeiter in kürzester Zeit den kompletten Wechsel bei voller Arbeitsfähigkeit vorsah. Zwar lag der größte Aufwand sicherlich in der technischen Vorbereitung des Systemwechsels und der Planung der schrittweisen Umstellung der einzelnen Arbeitsplätze, doch als größte Herausforderung wurde vom Management die Kommunikation des Sinns des Wechsels und die konkreten Unterstützung der Beschäftigten in der Situation des Wechsels gesehen:

„Die wichtigsten Schritte aus meiner Sicht war, dass wir rechtzeitig kommuniziert haben, dass wir Unterlagen geschaffen haben, wo die Mitarbeiter nachgucken konnten, und dass wir (…) ich sag mal (…) Plattformen geschaffen haben, also mit Skype-Besprechungen den Mitarbeitern gezeigt haben, was auf sie zukommt. Und dabei präpariert waren, als die Umstellung dann passiert ist, dass wir ne Community hingestellt haben, wo sie dann zeitnah sich (…) melden konnten und Hilfe bekommen haben. Also dass man vom ersten Tag an nen möglichst guten Support hat. Das ist wichtig.“ (C1917-74 Führungskraft).

Da dieser Wechsel ohne größere Probleme bewältigt worden war, einigte man sich nach einer Phase der Klärung des Projektinhaltes für die zweiten Phase auf die Einführung von MS Teams in den Projektbereichen und in der Verwaltung, d. h. sämtliche Projektvorgänge sollten ab diesem Zeitpunkt nur noch über diese Plattform abgewickelt werden. Da im Unterschied zur ersten Phase die bisherigen Anwendungen nicht abgeschaltet werden konnten, musste hier Überzeugungsarbeit geleistet werden. So bedeutete es für einen Teil der Beschäftigten, dass sie sich mit der neuen Kollaborationsplattform erstmals vertraut machen mussten, für den anderen Teil ergab sich keine Veränderung, weil sie halboffiziell zuvor bereits damit gearbeitet hatten. Insbesondere in Bereichen wo die Kunden dieses Werkzeug im Einsatz hatten, war MS Teams schon eineinhalb Jahre früher verfügbar. Gemessen an der Befürchtung des Managements, dass die Bereiche mit einer Präferenz für IBM-Produkte an ihrer bisherigen Anwendung festhalten könnten, gelang der Wechsel aber ziemlich reibungslos. Geholfen hat sicher die Beteiligung der Beschäftigten und gezielte Unterstützung durch das Projektteam:

„Bei Teams geht es so weiter, dass wir eine Umfrage gemacht haben, die sehr detailliert war, mit ganz vielen verschiedenen Fragen. War auch ganz cool, haben irgendwie von 75 Leuten ... 49 teilgenommen immerhin. (…) Dann haben wir ne zweite Umfrage gemacht, wo es darum ging, (…) weil dann haben wir die Ergebnisse der Umfrage vorgestellt und haben noch mal so paar Tipps und Tricks gemacht, also all die Sachen, die angesprochen wurden, was schlecht sind, haben wir dann versucht, in einem Termin aufzuzeigen, wie sie es besser machen können. Dabei ist aber herausgekommen, dass sich die einen oder anderen Kollegen doch noch mehr Dokumentation wünschen beziehungsweise ... unterschiedlichen Bedarf an Unterstützung haben.“ (C1921-95 Projektteam)

Zum anderen lässt es sich damit erklären, dass die Beschäftigten die Entscheidung des Managements letztlich anerkannten, auf die Marktentwicklung zu reagieren und selbst die Anwendungen zu nutzen, die sie Kunden verkaufen:

„Also bei mir war das so, wo ich immer gedacht hab, wieso? Wieso soll ich jetzt eine schlechtere Lösung wählen als die, die ich habe? (…) Das würde doch kein normaler Mensch machen. (…) aber es ist dann eben tatsächlich nicht so einfach, weil man, wenn man alle Aspekte zusammenführt und sagt, unterm Strich können wir gar nichts als diesen Wandel mitmachen und – auch wenn er für uns persönlich – an manchen Ecken eben einen Rückschritt bedeutet, (…) ist es perspektivisch und strategisch dennoch wichtig und richtig, das zu tun. (…) Also das muss in einem reifen und äh bis man sagt: Ja, stimmt, vielleicht ist es tatsächlich so, dass es nicht immer nur nach vorne geht, sondern in manchen Ecken auch nen kleinen Schritt zurück, damit man insgesamt nach vorne geht, sich nach vorne bewegt.“ (C1929-78 Consultant)

Sowohl die individuellen und kollektiven Lernprozesse als auch die Auseinandersetzung mit dem Sinn der Veränderung benötigen eine gewisse Zeit.

Jedoch hatte man im Vorfeld zwei Unternehmensbereiche von der Umsetzung zunächst ausgeklammert, weil deren Nutzungsbedürfnisse sich mit einer Team-Standardsoftware nicht gut genug abbilden ließen; zum einen den Vertrieb, für den ein eigenes Customer-Relationship-Management (CRM) geeigneter erschien; zum anderen einen Service-Bereich, der ein Ticketsystem zur detaillierten Dokumentation von Service-Fällen nutzte. Diese Bereiche sollten in einer dritten Phase (nach Ende des Beobachtungszeitraums) umgestellt werden.

Die gesamte Umsetzungsphase wurde von Diskussionen geprägt, welche der bestehenden und von bestimmten Bereichen benutzten Anwendungen neben O 365 weiterhin zur Verfügung stehen sollte und wie das Zielszenario für die unterschiedlichen Anwendungen aussehen könnte. Zwei Beispiele: Die vollständige Ablösung der IBM Architektur wurde durch das Festhalten an IBM Connections deutlich verzögert. Die darüber betriebenen Foren und Communities hatten viele aktive Gruppen mit einem länger bestehenden Wissensaustausch und zudem galt das Werkzeug auch als sehr gut bedienbar. Selbst das Projektteam setzte beim Wechsel auf MS Teams lieber auf die vertraute Anwendung, um Learning-Communities zu realisieren. MS Teams erschien für diese Zwecke als weniger praktikabel. Nach zwei Jahren konnte sich das Management schließlich durchsetzen und schaltete das Werkzeug vollständig ab. Eine andere Diskussion bezog sich auf die Möglichkeiten, die Plattform für das Projektmanagement Jira durch Planner aus dem Office 365 Paket zu ersetzen. Hier spielte das Management wohl mit dem Gedanken, eine weniger leistungsfähige O 365 Lösung einheitlich für alle durchzusetzen oder für die Beschäftigten aus dem Service (Ticketsystem) sowie denjenigen, die aufwendigere Projekte bearbeiteten, Jira vorzusehen. Am Ende setzte sich hier die zweite Alternative durch und es wurde sogar in die Programmierung einer Schnittstelle zum ERP-System investiert, um den Prozess zu optimieren.

Während es in den Projektteams möglich gewesen war, neue Projekte konsequent in der neuen Anwendung zu starten, war die Verwaltung viel stärker abhängig von der Nutzung älterer Datenbestände. Entsprechend wäre für die Verwaltung ein sehr viel größerer Aufwand entstanden und zudem wurde eine dauerhafte Verschlechterung der Arbeitsprozesse befürchtet. Entsprechend formulierten die Beschäftigten aus dem Verwaltungsbereich deutliche Kritik und es entstand eine spürbare Unruhe, sodass das Management die Verwaltung doch aus der allgemeinen Lösung zunächst ausnahm. Noch zum Zeitpunkt der Verfassung des vorliegenden Beitrags wurde nach einer besseren Lösung gesucht.

Am Ende des Beobachtungszeitraums war festzustellen, dass die Umstellung in den Projektbereichen erfolgreich bewältigt worden war, aber nicht alle der ursprünglich geplanten Bereiche umgestellt waren. Es gab eine Zielplanung für den Wechsel in der Verwaltung und für die Bereiche Vertrieb und Service waren neue Lösungen avisiert. Erneut kann festgehalten werden, dass am Ende eine größere Vielfalt an kollaborativen Anwendungen im Einsatz waren als mit dem Zielszenario „Digitaler Arbeitsplatz“ zwei Jahre zuvor angestrebt worden war. Auch die Abschlussbilanz des Projektverantwortlichen war ambivalent: Zwar wäre ihnen die „Technologie-Ablösung“ gut gelungen, aber sie hätten aus der Umsetzung mehr rausholen können, wenn sie auch das Thema „anders Arbeiten“ und die „Kultur der Selbststeuerung“ intensiver bearbeitet hätten. „Nur weil ein CEO sagt ‚ihr dürft‘ ist noch nicht klar, dass die Leute das wollen, können und tun.“

Welche Aktivitäten der Arbeitsgestaltung steckte hinter dieser „Technologie-Ablösung“? In einer ersten Phase wurden einerseits die Technik und andererseits die künftige Nutzung vorbereitet, indem das Projektteam zusammen mit ausgewählten Beschäftigten sinnvolle Nutzungsfälle („Use-Cases“) identifizierte.

„Also die größte Arbeit war … in der Vorbereitungsphase, weil wir uns da halt schon ein bisschen intensiver hingesetzt haben und diese Usecases halt ausgearbeitet haben (…) Und da war eigentlich wirklich die größte Arbeit, das vorher, was die Kollegen uns alles an Nachrichten geschickt haben, zu analysieren quasi und zu schauen, okay, wie kann man es denn abbilden?“ (C1923-203 Projektteammitglied)

Dann erfolgte eine Phase der Umsetzung, die in erster Linie die Kommunikation des Wechsels und die organisatorische Regelung der weiteren Nutzung beinhaltete. Hinzu kamen noch Programmierleistungen zu Gestaltung von Schnittstellen zu anderen Programmen. Aufwendig war die Kommunikation der Notwendigkeit dieses Wechsels, denn – wie bereits erwähnt – er war hauptsächlich strategisch motiviert (Marktveränderungen) und durchaus auch mit Einschränkungen in der Benutzerfreundlichkeit der Anwendungen verbunden. Das Standardprodukt konnte nicht so stark an den eigenen Workflow angepasst werden wie man es von der alten Lösung gewohnt war. Auf der anderen Seite ergaben sich jedoch auch Vorteile durch z. B. eine bessere Integration der Web-Konferenz Funktion. Bei den organisatorischen Regelungen fiel auf, dass das Management in Folge eines Vorstandswechsels nun bewusst darauf verzichtete, die Nutzung von MS Teams so detailliert zu regeln wie in der Vergangenheit. Die Leitung erklärte, dass das Unternehmen als Organisation agiler werden wolle und die Beschäftigten mehr Spielräume bei der Nutzung der Kollaborationsplattform erhalten sollten. Als verbindliche Richtlinie wurden lediglich fünf Regeln für die Nutzung von MS Teams erlassen, wie z. B., dass für jeden Kunden nur ein MS Teams gebildet werden dürfe und die Projekte jeweils einem Kanal eines MS Teams zugeordnet werden sollten. Ein ganz deutlicher Impuls zu mehr Selbstorganisation. Aber der bloße Verzicht auf detaillierte Regelung scheint – wie die Äußerung des Projektverantwortlichen belegt – eine explizite Gestaltung der neuen Form der Zusammenarbeit nicht ersetzen zu können.

9.2.3 Partizipative Entwicklung – das Software-Entwicklungshaus S

Das Arbeitskonzept und die damit verbundene kollaborative Plattform für die verteilte Software-Entwicklung, das bereits zu Beginn des Förderprojektes für erste Kundenprojekten umgesetzt war, mutete recht spektakulär an: Im Teamraum, indem vier oder fünf Personen tätig sind, sind sehr große Bildschirme angebracht, welche eine laufende Direktübertragung aus einem parallelen Arbeitsraum liefern, der beim Kunden angesiedelt ist und in dem weitere Teammitglieder an ihren Arbeitsplatzrechnern sitzen. Es wird eine Situation der Präsenz simuliert, als ob zwei Räume nur durch eine Glasscheibe getrennt wären. Teammitglieder der verschiedenen Standorte können jederzeit miteinander sprechen, müssen dazu aber den Ton erst anschalten. Daneben ist ein Touch-Bildschirm platziert, der den Stand der Aufgabenbearbeitung an einem Task-Board transparent macht und beim morgendlichen „Stand up“ von beiden Teams bedient werden kann. Die Zusammenarbeit wird mit weiteren kollaborativen Anwendungen unterstützt (u. a. Whiteboard auf Touchbildschirmen zur Anwendung von Kreativitätstechniken; bilaterale Web-Konferenzen; Wissensaustausch im Wiki-System). Die eigentliche Aufgabe, die Software-Programmierung, erfolgt in verteilten Entwicklungsumgebungen.

Dieser enorme Aufwand für den verteilten Teamraum wird als notwendig angesehen, um die hohe Intensität der Zusammenarbeit und des Wissensaustausches im Team auch auf Distanz sicherzustellen. Entstanden ist es auf der Suche nach einer Lösung der verteilten Zusammenarbeit:

„Wir standen vor der Herausforderung, wir haben mehrere Standorte und wie kann man das denn lösen? Ne, und dann kam halt die Idee mit der Video-Konferenz-Anlage und damals mit dem [elektronischen Task]-Board. Naja, und dann hat man das dann halt einfach mal eingesetzt, ausprobiert, also das ist halt immer der pragmatische Ansatz: wir probieren was aus, reflektieren die Arbeit, hat das funktioniert? Und darauf sind Erfahrungswerte entstanden...“ (S1738-320 Mitglied Expertenteam).

Das Förderprojekt sollte nun dazu genutzt werden, das so gefundene Arbeitskonzept für die agile räumlich verteilte Software-Entwicklung systematisch in Iterationen weiterzuentwickeln und im Unternehmen auszurollen.

Zur Umsetzung wurde ein Expertenteam gebildet, das v. a. von Scrum-Mastern (m + w) (Schwaber und Sutherland 2017) besetzt wurde, die in der Weiterentwicklung der Plattform die Coaching-Rolle für die verteilten Teams übernehmen sollten. Als Coach sollten sie die vorhandenen Erfahrungen an die Teams in räumlich verteilten Projekträumen weitergeben und diese bei der Arbeitsgestaltung fachlich unterstützen. Für die Arbeitsgestaltung blieben die Scrum-Master und die Teams selbst mit verantwortlich: Die Teams reflektierten nach jedem Sprint von ca. drei, vier Wochen in einer Retrospektive die Qualität ihrer Zusammenarbeit und die Einflussfaktoren, welche ihre Zusammenarbeit behinderten. Sie waren insofern für die schrittweise Optimierung ihrer Arbeitsbedingungen zuständig – ähnlich wie die ersten Schritte zum hier vorgestellten Bildschirm-Konzept. Für die Umsetzung der Verbesserungen jeglicher Art (organisatorisch, administrativ, technologisch) waren dann die Scrum-Master zuständig. Die aus der großen Autonomie der Teams resultierende Tendenz, dass jedes Software-Entwicklungsteam seine individuellen Lösungen entwickelt, wurde dadurch abgemildert, dass die Scrum-Master sich in Methodenentwicklung, Technikeinsatz und Vorgehensweisen abstimmen sollten.

Desintegrierende Effekte und eine große Herausforderung für die Arbeitsgestaltung ergaben sich aus dem Umstand, dass es sich um gemischte Teams mit Kunden handelt. Zwar hat sich das Konzept der verteilten Zusammenarbeit mit dem sichtbaren Bildschirm in vielen Anbahnungsprozessen auch als ein attraktiver Marketingfaktor erwiesen. Doch wurden i. d. R. eher die von den Kunden präferierten Systeme für die Kollaboration über die Unternehmensgrenzen hinweg (z. B. Entwicklungsumgebungen, Projektsteuerung, Projektdokumentation) genutzt. Damit erhöhte sich die Vielfalt der im Unternehmen S aktiv genutzten Anwendungen.

Zu Beginn des Forschungsprojekts lag bereits eine sehr umfassende schriftliche Dokumentation der bisherigen Erfahrungen mit der Arbeitsgestaltung räumlich verteilter Software-Entwicklung vor. Sie war vom hauptsächlichen Verantwortlichen für das Arbeitsgestaltungskonzept verfasst worden, der das Unternehmen in der Zeit verlassen und den Auftrag der Wissenssicherung erhalten hatte. Dieses Konzept basiert auf vier Säulen.

  • Verteilter Projektraum: Beschreibt wie Projekträume eingerichtet werden können, um die Zusammenarbeit bestmöglich zu unterstützen. Hier gibt es beispielsweise Erfahrungswerte zur optimalen Platzierung des Bildschirms, zur Anordnung der individuellen Arbeitsplätze oder zur Gestaltung der Akustik.

  • Optimierte Prozesse und Rollen: Klärung der bei der agilen Software-Entwicklung vorgesehenen Rollen (Scrum-Master, Product Owner usw.) sowie Arbeits- und Kommunikationsprozessen (z. B. Sprint Planning, Retrospektive).

  • Werkzeuge und Technologien: Ausführungen beziehen sich auf die Eignung und Nutzung von Kollaborationsanwendungen (z. B. Task Board, virtuelle Retrospektive, Whiteboards) und Entwicklungswerkzeugen sowie technischen Lösungen für den Projektraum (Geräte-Setup für die Videoübertragung).

  • Team: Beschreibt vielfältige Handlungsmöglichkeiten und Methoden zur Teamentwicklung. Dabei wird im Anschluss an agile Konzepte davon ausgegangen, dass die Leistungsfähigkeit eines Teams durch gemeinsam geteilte Werte maßgeblich bestimmt wird.

Die vier Dimensionen, die in der betrieblichen Praxis durch die systematische Reflexion der Projekterfahrungen in verteilten agilen Entwicklungsprojekten zusammengetragen worden waren, ergeben im Zusammenspiel ein ganzheitliches Gestaltungskonzept, welches den Konzepten sozio-technischer Systemgestaltung durchaus nahe kommt (Clegg 2000; Ulich 2011), ohne darauf explizit Bezug zu nehmen.

Dieses Konzept wurde nun in den unterschiedlichen Entwicklungsteams angewendet, je nach den spezifischen Bedingungen der jeweiligen Teams (Anzahl der Standorte, Kundensituation, Ausprägung des agilen Vorgehens, Reife des Teams usw.). Aus Interviews wissen wir, dass sich die wesentlichen Umsetzungsaktivitäten in den jeweiligen Teams auf die Schärfung des Rollenkonzepts, die Optimierung der Zusammenarbeit sowie auf die Teamentwicklung bezogen, die sich maßgeblich am Wertekonzept orientierte. Besonders intensiv wurde daran gearbeitet, eine integrierte Arbeitsweise zwischen den Team-Standorten sicherzustellen, d. h. Prozesse der Subgruppen-Bildung, die Spezialisierung einzelner Standorte sowie die Entstehung von „Wissensinseln“ systematisch zu verhindern. Auch die Vorgehensweisen des Aufstartens neuer Kundenprojekte mit gemeinsamen Teams wurde mit Bezug auf ein Gruppenphasenmodell methodisch weiterentwickelt. Zudem gab der Aufbau des ersten Standortes im europäischen Ausland 2018 einen weiteren Entwicklungsimpuls, sich zusätzlich mit kulturellen Differenzen in den Teams zu beschäftigen, um die neuen Mitarbeiterinnen und Mitarbeiter nicht als verlängerte Werkbank, sondern als gleichberechtigte Mitglieder in die Firma zu integrieren.

Im Konzept spielte die permanente Sichtbarkeit zwar eine zentrale Rolle, aber sie wurde nicht in allen Teams, wo dies möglich gewesen wäre, konsequent realisiert. Eine Rolle mag dabei gespielt haben, dass das Konzept offenbar nicht als ein verbindlicher, betrieblicher Standard für gute Projektgestaltung verstanden worden ist, sondern eher als ein Methodenbaukasten, der je nach den Wünschen der Teams benutzt werden konnte: „Die Videoverbindung ist dabei kein Muss, sondern lediglich ein Element aus dem Baukasten des (…) gebräuchlichen Tool-Kits für verteiltes Arbeiten.“ (Interner Blogbeitrag 2020). Eine durch das Unternehmen durchgeführte Befragung im Sommer 2019 von 168 Beschäftigten ergab, dass die dauerhafte Sichtbarkeit zwar ein Diskussionspunkt sei, aber eine deutliche Mehrheit sich dafür ausspreche. Auch in unseren Interviews haben die Befragten eine Vielzahl von positiven Effekten auf die Kommunikation und den Teamzusammenhalt zur Sprache gebracht. Das Konzept wurde in vielen Teams aktiv umgesetzt:

„Also da, wo es Sinn macht und konstant entsprechend viele Leute da sind, versuchen wir das. Ja. [Interviewer2:] Aber daraus kann man schließen, dass Ihnen die Bildübertragung schon wichtig ist, ne? Auch in dieser zersplitterten Situation bringt Ihnen das was? [B1]: Ja. [B2]: Finde ich auch. Ich kenne es nicht anders, muss ich ehrlich sagen. Seit ich hier arbeite habe ich eigentlich permanent immer Videoübertragung mit dabei. Ich kann mir aber gut vorstellen, dass es schon was anderes ist, wenn man sich halt einfach sieht. Halt irgendwie permanent einen Kontakt hat zu den anderen, wenn es auch nur visuell ist und nicht unbedingt nur über …also Ton machen wir aus, dann sieht man sich quasi nur und hört sich jetzt nicht unbedingt immer. Aber wenn man jetzt völlig isoliert ist und quasi auch niemanden mehr sieht, dann ist das schon was anderes beim Arbeiten.“ (Gruppendiskussion S1960G-82f)

Es gab jedoch auch einzelne Befragte, die erklärten, bewusst vermieden zu haben, in einem solchen Team zu arbeiten.

Die interne Befragung löste einen kleinen Schock bei den Verantwortlichen aus: Von den Beschäftigten mit Erfahrungen der verteilten Zusammenarbeit kannten nach 2 Jahren 19 % der Befragten das Konzept gar nicht und nur 26 % benannten ein Mitglied des Experten-Teams oder dieses selbst als Ansprechpartner. Die ausführliche Dokumentation im Wiki-System, in dem das Experten-Team Empfehlungen, Methoden und Werkzeuge geteilt hat, haben nur 42 % aller Befragten schon einmal genutzt. Diese Zahlen haben die Projektverantwortlichen zum Anlass genommen, die Anwendung des Gestaltungskonzeptes in den verteilten Teams noch gezielter zu hinterfragen und zu verbessern.

Insgesamt erweist sich die Projektentwicklung in diesem Unternehmen im Wesentlichen als ein Entwicklungsprozess, bei dem sich die Such- und Lernprozesse der Entwicklung der verteilten Zusammenarbeit dezentral ergeben. Dadurch hängt es vom Expertenteam ab, wieweit die im Unternehmen aufgebaute Kompetenz und Expertise für die Arbeitsgestaltung ausgetauscht und angewendet wird. Auf Anforderung der Geschäftsleitung, das Arbeitskonzept stärker zu integrieren und zu vereinheitlichen, wurde die Befürchtung formuliert, Teams „gleichzuschalten“ (Scrum Master), d. h. die Autonomie der Teams bei der Gestaltung ihrer Zusammenarbeit unnötig einzuschränken und z. B. die durch die Kunden bedingten großen Unterschiede in der Arbeitsweise und der Technikunterstützung nicht genug zu beachten.

Zwei externe Ereignisse haben diesen dezentralen, iterativen Such- und Lernprozess der Arbeitsgestaltung partiell überlagert, indem sie eine firmenweite Gestaltungsaktivität erforderlich machten und weitere Akteure auf den Plan riefen: Das eine war der Markterfolg von MS Teams ab 2017, das andere die Corona Pandemie 2020.

Mit Blick auf die positive Resonanz von MS Teams im Markt erhielt ein Software-Entwicklungsteam des Unternehmens Anfang 2018 den Auftrag, diese Anwendung als Werkzeug zu erproben. Das Team empfahl daraufhin, diese teambezogene Kommunikationslösung zeitnah einzuführen, weil sie viele alltägliche Arbeitsabläufe erleichtere und Lücken im Kommunikationsverlauf schließen könne. Insbesondere wurde auf den Aspekt hingewiesen, dass durch das Teilen von Informationen in zentralen Kanälen die standortübergreifende Einbindung der Teammitglieder und die Transparenz erhöht und die Entstehung von Wissensinseln vermieden werden könnte. Wir wissen nicht genau welchen Einfluss diese Empfehlung auf die weitere Entwicklung genommen hat und was andererseits durch die weitere Zunahme der aktiven Standorte und der Gründung des Auslandsstandortes bedingt war. Zu beobachten war jedenfalls, dass die Frage wie teamübergreifende firmeninterne Kommunikation intensiviert werden könnte, im ersten Jahr noch kein Thema, 2018 dann plötzlich sehr intensiv diskutiert wurde.

Im Sommer 2018 wurde ein internes Projekt („Strategische Initiative“) damit beauftragt, einen digitalen Arbeitsplatz als zentralen Einstieg für die Mitarbeiterinnen und Mitarbeiter in die Community des Unternehmens zu entwickeln. Das Projekt zeichnet sich durch eine beteiligungsorientierte und grundsätzliche Herangehensweise aus. Zum einen wurde allen Beschäftigten die Gelegenheit geboten, sich für dieses Projekt zu bewerben, wobei bei der Besetzung darauf geachtet wurde, dass alle im Unternehmen vertretenen Rollen und Ebenen repräsentiert waren. Zum anderen wurde der Projektauftrag sehr grundlegend formuliert, produktunabhängig den Bedarf zu erheben und dann in mehrmonatigen Sprints iterativ eine Lösung zu entwickeln. Als Kunde fungiert bei diesem strategischen Projekt das Geschäftsleitungsteam, das die im Sprint Null partizipativ entwickelten Zielsetzungen freigab. Die Firmenöffentlichkeit wurde über den Fortgang der Arbeit laufend informiert (u. a. in Strategy Stand-ups).

Ein wesentlicher Grund für dieses Vorhaben war der Wunsch nach stärkerer Intensität und Vernetzung der innerbetrieblichen Zusammenarbeit:

„Wir haben auf allen Ebenen im Unternehmen (…) Teams gebildet, die interdisziplinär bereichsübergreifend miteinander zusammenarbeiten und das eigentlich (…) auch noch standortverteilt (…). Und jetzt kam der Punkt Intranet. Also das Ziel, trotzdem eine (…) Community auszubilden, also dass wir trotzdem, trotz der Standortverteilung als Unternehmen eine Community sind.“ (S1846-17 Führungskraft)

Ein weiterer Grund waren Effizienzprobleme durch die Nutzung einer Vielzahl von funktional äquivalenten Anwendungen, so sollte der „Zoo von Anwendungen“ besser „orchestiert“ werden:

„Unser Intranet hat sich sehr auseinanderdividiert, also wir (…) setzen viele Werkzeuge ein, unter anderem Sharepoint. Mittlerweile haben wir auch Confluence eingeführt als Wiki, haben Yammer, haben Jira, haben so viele verschiedene Tools und Werkzeuge (…), also das war vielleicht auch noch nie orchestriert, aber es ist zumindestens mal nicht dieser zentrale Einstieg mehr für die Mitarbeiter, wie es eigentlich sein sollte. (…) das hat eigentlich dann auch alles nicht mehr so richtig zusammengepasst.“ (S1846-6 Führungskraft)

Das Projekt hat daher in mehreren Sprints nach einer möglichst guten Passung der arbeitsbezogenen Bedürfnisse der Anwenderinnen und Anwender zu einsetzbaren Anwendungen zur Unterstützung der Zusammenarbeit gesucht. Mit der Ende 2019 präsentierten „Zielarchitektur Digitaler Arbeitsplatz“ wurde zwar eine fundierte Systematik und Struktur für die geplante Dienste und Anwendungen entwickelt, eine substanzielle Reduzierung der verschiedenen kollaborativen Anwendungen konnte aber nicht erreicht werden.

Die zweite extern bedingte Herausforderung war die Corona-Pandemie, da schlagartig alle Beschäftigten ins Homeoffice geschickt werden mussten. Das galt zwar für alle drei Fall-Unternehmen, doch für S bedeutete dies, dass das entwickelte Arbeitskonzept der virtuellen Projekträume plötzlich nicht mehr anwendbar war. Stattdessen saß jedes Teammitglied nun allein am Notebook zu Hause und die Teams mussten sich neu finden. Da die Kollaborationsplattform MS Teams diese Arbeitssituation gut unterstützte, hat sich in Abweichung zur geplanten Zielarchitektur deren Nutzung deutlich beschleunigt und intensiviert. Realisiert wurde die Arbeitsgestaltung durch das Expertenteam, dessen Mitglieder in ihrer Rolle als Scrum Master ihre Teams bei der plötzlichen Anpassung des Arbeitsgestaltungskonzeptes unterstützten. Es ist eine offene Frage, wie es nach der Corona-Pandemie mit dem digitalen Projektraum weitergehen wird.

9.3 Diskussion der Ergebnisse: Such- und Entwicklungsprozesse prozessorientiert und agil gestalten

Die Fallbeispiele verdeutlichen, dass Change-Prozesse in den Unternehmen zumeist einen anderen Ausgang nehmen als die Akteure es zu Beginn geplant haben. Viele Einflussfaktoren und Wechselbeziehungen sind im Vorhinein kaum zu antizipieren und es kommt daher zu zahlreichen Brüchen in der Umsetzung und zu Neuausrichtungen. Dabei beeinflussen auch externe Faktoren das Tempo und die Richtung der Entwicklungen, wie etwa der Markterfolg bestimmter Produkte oder die Corona-Pandemie. Im Folgenden möchten wir auf die internen Dynamiken und Einflüsse fokussieren, die sich in den Entwicklungsprozessen durch die spezifischen Herausforderungen in der Nutzung und Gestaltung kollaborativer Anwendungen herauskristallisierten. Um herauszufinden, in welcher Weise den komplexen Anforderungen an die Arbeitsgestaltung begegnet werden kann, systematisieren wir fallübergreifende zentrale Themen der Gestaltung in den Entwicklungsprozessen der Unternehmen, um so Empfehlungen für die Arbeitsgestaltung abzuleiten.

Was waren denn Gründe für Abbrüche oder Neuorientierungen in den Fällen? Im Unternehmen S hat die Unternehmensentwicklung das Thema der übergreifenden Zusammenarbeit gegen die anfänglichen Erwartungen so bedeutsam werden lassen, dass neben dem verteilten Teamraum ein aufwendiges Entwicklungsprojekt zu einem zentralen digitalen Arbeitsplatz aus der Taufe gehoben wurde. Bei M hat sich erst in der Nutzung der Plattform gezeigt, dass die Erwartungen an die technische Leistung und Bedienungsfreundlichkeit der geplanten Plattform nicht erfüllt werden konnten. Zudem offenbarte sich eine Überforderung des Managements bei der Anforderung, professionelle Prozessgestaltung zu leisten. Es kam deshalb zum einen zu einer Schleife in der Entwicklung, weil eine neue Kollaborationsanwendung gesucht bzw. selbst entwickelt, und zum anderen zu einer erheblichen Erweiterung, da eine Innovationsorganisation etabliert werden musste, um die Kompetenz in der Prozessgestaltung aufzubauen. Auch bei C, die ihr Projekt bewusst nicht durchgeplant, sondern in Etappen angelegt haben, wurde in der zweiten Phase die Umsetzung im Bereich der Administration zunächst abgebrochen. Anlass waren die Befürchtungen, dass die Arbeitsaufwände durch den geplanten Wechsel der Plattform immens steigen würden, was zu Protesten der Betroffenen geführt hatte. Es sind also Einflussfaktoren der Unternehmensentwicklung und des Zusammenspiels von Menschen, Technik und Organisation, die eine Rolle gespielt haben.

Entsprechend dem Stand der Diskussion zur Notwendigkeit menschlicher Aneignung von Technologien (Orlikowski 2010) hat sich fallübergreifend als wesentlicher Einflussfaktor das Verhalten der Nutzerinnen und Nutzer und ihrer arbeitsbezogenen Bedürfnisse erwiesen. Es erklärt beispielsweise das Festhalten an der Nutzung von IBM Connections und Jira bei C, die Zurückhaltung bei der Vorgabe bestimmter Anwendungen bei S und die Ausweitung der Nutzung von MS Teams bei M. Insgesamt ist die Umsetzung in allen drei Unternehmen dadurch geprägt, dass das Management die Wirkung der Maßnahmen gezielt bewertet und auch verstärkt versucht, mit Beteiligungsprozessen und Befragungen ihrer Beschäftigten Informationen für die weitere Gestaltung zu erhalten. Insofern wird der Suchprozess nach einer tragfähigen Lösung auch mehr und mehr zu einem (organisationalen) Lernprozess.

Für die Arbeitsgestaltung kann man aus solchen Erfahrungen der Suche nach dem digitalen Arbeitsplatz zweierlei lernen: Eine professionelle Bestandsaufnahme und Analyse hat für die Umsetzung zwar grundsätzlich hohe Bedeutung, um möglichst viele Bedingungen bereits im Vorfeld zu erkennen. Aber die Möglichkeiten antizipierender Analyse findet deutliche Grenzen in der Komplexität des Gegenstandes. Für Digitalisierungsvorhaben wurde kürzlich empfohlen, auf die sozio-technisch fundierte MTO-Analyse (Strohm und Ulich 1997) der 1990er Jahre zurückzugreifen (Paulsen et al. 2020). Für einen Rückgriff auf sozio-technische Methoden spricht, dass die Brüche in den Fallbeispielen auf unerwartete Wechselbeziehungen zwischen Menschen, Organisation und Technik verweisen, die nur mit einer sozio-technischen Gestaltung zu meistern sind. Dies haben auch die Fallbeispiele unterstrichen. Dagegen spricht, dass das Instrument im Original extrem aufwendig ist, weil sieben Analyseschritte von geschulten Expertinnen und Experten durchzuführen sind, um alle Dimensionen systematisch zu analysieren. Selbst Paulsen et al.(2020) haben das Methodenset gegenüber dem Original deutlich abgespeckt, wohl um in einen Umsetzungsmodus zu kommen, bei dem Erkenntnisse in kürzeren Schleifen in der Praxis erprobt und weiterentwickelt werden können, was ein sinnvoller Umgang mit der Komplexität ist, die sich aus dem schwer antizipierbaren Wechselspiel von Menschen, Technik und Organisation ergibt.

Denn Kollaborationsplattformen bauen eine übergeordnete Infrastruktur auf, die in einer Vielfalt von Arbeitssystemen zum Einsatz kommt und über die Unternehmensgrenzen hinweg auch Kundensysteme integrieren kann. Zudem ist die Entwicklung von einer großen Dynamik und permanentem Wandel gekennzeichnet, der bei Software-as-a-service-Produkten nicht unmaßgeblich von den Anbietern der Plattformen getrieben wird. Es kommen also zu den Gestaltungsempfehlungen für räumlich verteilte Teams weitere Anforderungen hinzu. Bei räumlich verteilten Teams standen zumeist die Teamentwicklungsprozesse im Zentrum der Empfehlungen (Konradt und Hertel 2002; Boos et al. 2017; Herrmann et al. 2012), sie wurden nach und nach in Richtung auf die Auswahl geeigneter Medien und eine integrierte Personal- und Organisationsentwicklung erweitert (Boos et al. 2017; Herrmann et al. 2012). Die Aufgabe, integrierte Arbeitsprozesse zu unterstützen und eine übergeordnete Infrastruktur für die Zusammenarbeit im Unternehmen zu schaffen, geht darüber nun jedoch noch hinaus. Diese in unseren Fällen beobachteten Charakteristika machen auch eine Weiterentwicklung der klassischen sozio-technischen Systemgestaltung erforderlich (Pasmore et al. 2019).

Hinsichtlich Kollaborationsplattformen existiert derzeit wenig gesichertes Wissen, sodass die wenigen Akteure mit arbeitswissenschaftlicher Kompetenz in den Unternehmen erst noch Erfahrungen mit der Gestaltung machen müssen. Wir halten es daher für unvermeidlich, dass selbst nach sorgsamer Analyse sich viele Wechselwirkungen und Effekte erst im Umsetzungsprozess herauskristallisieren. Es lässt sich beobachten, dass die Fallunternehmen ob sie wollen oder nicht, eher zu einem „agilen“ Vorgehen übergehen. Sie gehen stärker iterativ vor, nehmen sich also überschaubare Planungszyklen vor. Dabei nehmen sie auch Abbrüche in Kauf, „schmeißen digitale Infrastrukturen weg“, so ein Manager des Maschinenbau-Unternehmens, wenn sie in Sackgassen geraten, und versuchen neue Wege mit anderen kollaborativen Plattformen, mit Veränderungen der Arbeitsorganisation oder passen Lernformate an. Angesichts der Komplexität des Gestaltungsthemas scheint ein agiles, stärker auf Erproben und Reflektieren setzendes Vorgehen für die Anlage der Gestaltungsprozesse empfehlenswert zu sein. Dabei sind angesichts der hohen Bedeutung der Tatsache, dass sich die Nutzerinnen und Nutzer die kollaborativen Technologien aneignen müssen, intensiver Austausch und Beteiligung der unterschiedlichen Nutzungsgruppen zu empfehlen. Die in der Einleitung dieses Buches (siehe 1.3.2) getroffene Einschätzung, dass auch die Gestaltungskompetenzen der Beschäftigten vor Ort gestärkt werden müssen, bestätigt sich.

9.4 Empfehlungen für die Gestaltung des Arbeitens mit Kollaborationsplattformen

Im Rückblick fällt auf, dass im Veränderungsprozess drei zentrale Themen die Unternehmen besonders beschäftigt haben: Die Form der Zusammenarbeit, die Regelung des Einsatzzwecks und der Aufbau von Organisationsstrukturen für die Arbeitsgestaltung. (Weitere Gestaltungsdimensionen des Arbeitens mit Kollaborationsplattformen siehe Kap. 10 in diesem Band). Aus diesen Beobachtungen wollen wir Schlussfolgerungen für die Arbeitsgestaltung ziehen.

Form der Zusammenarbeit: Eine zentrale Gestaltungsfrage bezog sich auf die angestrebte Form der Zusammenarbeit, welche durch eine Kollaborationsplattform unterstützt werden soll, und die Auswahl der passenden Anwendung. Dabei handelt es sich um einen komplexen Abwägungsprozess, bei dem die Interessen der unterschiedlichen Rollen und Beschäftigtengruppen berücksichtigt werden müssen, die sich erst bei Beschäftigung mit den Chancen und Risiken des neuen Arbeitens konkret artikulieren.

Wir wissen aus Interviews, dass die Bereitschaft die Kollaborationsplattform zu nutzen, davon abhängig ist, dass die Beschäftigten erwarten, dass sie bei ihrer Aufgabenerfüllung wirksam unterstützt werden. Dies entspricht im Übrigen auch Erkenntnissen des „Task-technology fit model“ (Teo und Men 2008) und des „Technology acceptance model“ (Schillewaert et al. 2005). Die Software-Produkte sind aber Standardlösungen und auf eine bestimmte Vorstellung von Zusammenarbeit ausgelegt. Beispielsweise zielt MS Teams auf eine Optimierung der Zusammenarbeit in Projektteams. Das gerade sehr in Mode kommende Werkzeug wurde in typischen Projektbereichen in allen drei Unternehmen sehr schnell aufgenommen und von den Beschäftigten genutzt. Bereiche mit einer Form der Zusammenarbeit, die von diesem Werkzeug hingegen nicht optimal unterstützt wurden, und die erwarteten, dass anderen Anwendungen eine höhere Produktivität für ihre Arbeit boten, akzeptierten es hingegen nicht für ihre Kernaufgaben. So konnten zwei Bereiche bei C schon vor der Umsetzung eine eigene Lösung aushandeln, weil erwartet wurde, dass das „Opportunity-Management“ im Vertrieb und das „Ticket-System“ im Service mit anderen Anwendungen besser unterstützt würde. Die Einigung auf ein Werkzeug für alle Bereiche und Tätigkeiten bietet Vorteile, aber bringt auch mit sich, dass Bedürfnisse bestimmter Rollen oder Tätigkeitsgruppen nicht optimal erfüllt werden (siehe die Diskussion zu Jira bei C). Da eine zu große Vielfalt der aktiven Anwendungen ebenfalls mit Nachteilen verbunden ist, muss eine gute Balance gefunden werden zwischen größtmöglicher Einigung auf ein Werkzeug und möglichst guter Passung von Werkzeug und arbeitsbezogenen Bedürfnissen, was zum Teil vorab, aber oftmals erst im Laufe einer praktischen Erprobung möglich wird.

Ergebnis dieser Entwicklungsprozesse war in allen Fällen, dass die Zahl der aktiv im Einsatz befindlichen kollaborativen Anwendungen sich nicht wie geplant deutlich reduzieren ließ. Wir haben dabei den Eindruck gewonnen, dass die technischen Möglichkeiten der Kollaborationsplattformen bei Planungen überschätzt und die organisatorischen Restriktionen (z. B. Uneinheitlichkeit der Unternehmensprozesse; Vielfalt der Nutzungsbedürfnisse; Sicherheits- und Datenschutzinteressen), die einer effektiven Nutzung entgegenstehen, stark unterschätzt werden. Solche Fehleinschätzungen müssen dann bei der Nutzung im Sinne eines aktiven Gestaltungsprozesses korrigiert werden.

Regelungen des Einsatzzwecks: Intensiv bearbeitetes Thema in allen drei Unternehmen war der geplante Einsatzzweck der Anwendung. Hier haben wir zwei gegensätzliche Ansätze beobachtet: Im Unternehmen M wurde darauf geachtet, die Nutzung von MS Teams betrieblich genau zu regeln, d. h. die Berechtigung für die Nutzung einzelner virtueller Teamräume zu definieren und die Regeln der Zusammenarbeit (was wird wie dokumentiert, wo werden Dateien abgelegt) genau vorzugeben. Argument dafür war die Sicherung der Qualität der Zusammenarbeit. Diese strengen Regelungen wurden eher akzeptiert als die fehlende Freiheit, das Werkzeug für selbst definierte (dienstliche) Zwecke zu nutzen. Diejenigen, die einen weitergehenden Nutzen und mehr Autonomie erwarteten, reagierten enttäuscht. In den Unternehmen C und S bestand die Möglichkeit, das Werkzeug neben den durch die Organisation vorgegebene virtuelle Teamräumen (z. B. durch Zugehörigkeit zu einem Kundenprojekt oder Organisationsbereich) auch für eine selbstorganisierte Vernetzung einzusetzen (z. B. für Expertenteams, thematische oder gruppenbezogene Communities). Der rege Gebrauch ermöglichte eine funktions- und gruppenübergreifende Vernetzung. Im Unternehmen C, die in der Vergangenheit noch verbindliche Prozessvorgaben für die Dokumentation bestimmter Inhalte gemacht hatten, bewerteten die einen Nutzerinnen und Nutzer die Aufforderung ehemals geregelte Aspekte nun selbstständig zu entscheiden, als fehlende Unterstützung, andere als Erfüllung von Freiheit und Autonomie.

Alles in allem ist für die Gestaltung der Form der Zusammenarbeit und des Einsatzzwecks die Konsequenz zu ziehen, erstens eine genaue Vorstellung davon zu entwickeln, worin der Nutzen des Einsatzes der Kollaborationsplattform genau liegen soll: Beschränkt er sich auf die konkrete Unterstützung einzelner Teams oder soll es mehr noch um die übergreifende Zusammenarbeit im Netzwerk gehen, um mit den verschiedenen Nutzungsgruppen in den Austausch zu treten? Zweitens geht es darum, organisationale Veränderungen in Richtung einer stärkeren Selbststeuerung der Teams mit weniger Nutzungsvorgaben durch eine begleitende Personal- und Organisationsentwicklung zu unterstützen, welche die neuen Anforderungen an die Zusammenarbeit und Arbeitskultur bearbeitet.

Aufbau von Organisationsstrukturen für die Arbeitsgestaltung: Kollaborationsplattformen werden in Arbeitsbereichen typischer Angestelltenarbeit eingesetzt und dem entsprechend liegt die Verantwortung zunächst bei den Führungskräften, für die Infrastruktur ihrer Beschäftigten zu sorgen und damit auch für die Arbeitsgestaltung. Nur im Industrieunternehmen M finden wir quasi eine Industrial Engineering Zuständigkeit, die sich professionell schon um die Prozessoptimierung gekümmert hat und daher auch die Plattform zur digitalen Prozessautomatisierung gestaltet.

Im Zuge der Nutzung der Kollaborationsplattform lässt sich ein Aufbau von Strukturen für die Arbeitsgestaltung beobachten: Zunächst geschieht dies über eine typische Projektorganisation, also eine temporäre Berufung verschiedener Kompetenzträger in ein Team sowohl bei C als auch bei S. Diese Projektteams holen sich gezielte Unterstützung beispielsweise bei der IT Abteilung oder bei Consultants. Da diese Unternehmen aus dem IT Bereich stammen, haben sie keine Schwierigkeiten im Betrieb Kompetenzträger zu finden, welche die unterschiedlichen Gestaltungsaspekte fachlich abdecken können (z. B. Qualitätsmanagement, Prozessverantwortliche, IT-Spezialisten, „Learning-Experts“; „Collaboration-Experts“). Zudem werden auch dauerhafte Strukturen geschaffen wie die neue Innovationsorganisation bei M oder das Expertenteam für die Konzeptentwicklung und Betreuung der Teams bei S. Im agilen Arbeitskonzept werden Arbeitsgestaltungsaufgaben an die operativen Teams übertragen, koordiniert von einem Scrum Master (Wolf 2015). Nach unseren Ergebnissen scheint der operativen Arbeitsgestaltung eine größere Bedeutung zuzukommen, denn auch bei C wird zunehmend auf firmenweite Regelungen verzichtet und auf die Selbststeuerung der Projekte und Teams bei der operativen Regelung der Zusammenarbeit gesetzt. Worauf hingegen verzichtet wird, ist die Bildung einer speziellen Abteilung für die Betreuung der Kollaborationsplattformen. Man mobilisiert eher eine verteilte Kompetenz im Netzwerk. Die Nutzungsregelungen und das gewonnene Wissen werden über Communities ausgetauscht und in Wiki-Systemen transparent dokumentiert und gemeinsam weiterentwickelt. Dies geschieht in unterschiedlichem Grad in allen Betrieben und auf diese Weise können – wie beim Konzept für den verteilten Projektraum bei S – auch fachlich anspruchsvolle, sozio-technisch begründete Konzepte entstehen. Auf solche Formen des Austausches und der Sicherung von Arbeitsgestaltungswissen sollte viel gezielter gesetzt werden. Zu fragen ist jedoch, wie sichergestellt wird, dass arbeitswissenschaftliche Kompetenz aufgebaut und z. B. Themen des Arbeits- und Gesundheitsschutzes und der Ergonomie in fachlich angemessener Weise zum Tragen kommen.

Wie erwartet hat sich das Vorhaben in den Unternehmen, die Zusammenarbeit von Teams und Projekten durch die Nutzung von Kollaborationsplattformen zu intensivieren, als eine komplexe Gestaltungsherausforderung erwiesen. Die Fallbeispiele unterstreichen die in der Einleitung dieses Buches getroffene Aussagen (siehe 1.3.2) , dass Gestaltungsprozesse „reflexiv, zyklisch und iterativ“ anzulegen sind und unterschiedliche Ebenen der Gestaltung zu integrieren sind. Unternehmen müssen eine sozio-technisch fundierte Arbeitsgestaltungskompetenz aufbauen und systematisch ihren Erfahrungsschatz zum kollaborativen Arbeiten erweitern. Aufgrund der Mehrdimensionalität und fachlichen Vielfalt der Anforderungen sowie des Tempos der Entwicklung empfehlen sich Strukturen verteilter Kompetenz, in der sich die unterschiedlichen Expertinnen und Experten des Unternehmens vernetzen, um die Gestaltungsaufgabe „kollaborativ“ zu lösen. Aus der Komplexität der mit der Nutzung von Kollaborationsplattformen angestoßenen Entwicklung ergibt sich notwendigerweise ein vielgestaltiger Such-, Lern- und Entwicklungsprozess. Dafür eignet sich ein agiler Gestaltungsansatz, der zwar an langfristigen Visionen orientiert ist, aber Gestaltungslösungen in kurzfristigeren Planungszyklen entwirft, testet und auf der Basis breiter Beteiligung der Beschäftigten iterativ weiterentwickelt.