12.1 Einleitung

Als direkte Folge der technologischen Entwicklungen der letzten zehn Jahre stellt internes Crowdsourcing (IC) eine neue, digitale Form von innerbetrieblicher Wissensvernetzung und bereichsübergreifender Zusammenarbeit dar. Bei IC erzeugen Beschäftigte eines Unternehmens (die Crowd) im Austausch über eine digitale Plattform Ideen und Lösungen, die zur Verbesserung von bestehenden Produkten, Prozessen und Dienstleistungen oder deren Neuentwicklungen (Innovationen) beitragen. Das macht IC sowohl zu einem Tool für Innovationsmanagement und Mitarbeiterbeteiligung als auch gleichzeitig zu einer Methode dafür.

In verschiedenen Ausprägungen und mit unterschiedlichen Bezeichnungen hat sich das digital vermittelte Verfahren in zahlreichen Unternehmen in Deutschland mittlerweile etabliert (Pohlisch 2019). Unabhängig davon in welcher Form IC im Unternehmen angewendet wird, essenziell für die praktische Umsetzung ist in allen Fällen das Rollenmodell, das neben dem IC-Prozess und der technischen Lösung, der sog. Crowd Technology (CT) – Architektur, den dritten Bestandteil eines IC – Systems ausmacht. Als ausführende Instanz beschreibt es die Aufteilung der Zuständigkeiten für die unterschiedlichen Prozessebenen und verschiedenen Prozesskomponenten sowie den verschiedenen Steuerungsaktivitäten und gibt zudem an, welche Unterstützung aus anderen Unternehmensbereichen für die erfolgreiche Durchführung benötigt wird. Als Teilziel im Forschungsvorhaben „ICU – Internes Crowdsourcing in Unternehmen“ ist ein solches Rollenmodell auf der Grundlage einer prototypischen Praxisanwendung von IC verwirklicht worden.

Ziel von ICU ist die Entwicklung eines branchenübergreifenden Referenzmodells für gute Praxis von internem Crowdsourcing mit Fokus auf die arbeitnehmerfreundliche Ausgestaltung der Anwendung. Das sog. ICU-Modell besteht aus einer Verfahrensstrategie mit den Themenschwerpunkten Innovationsmanagement, Mitarbeiterbeteiligung sowie Mitarbeiterqualifizierung und einer IC-Plattform und wurde bei dem Energiedienstleister GASAG AG als Praxispartner im Unternehmen zur Anwendung gebracht. Die Entwicklung erfolgte stufenweise: zuerst wurde ein Grundmodell realisiert und in einer Pilotphase getestet (1. Iteration), daran anschließend wurde das optimierte Modell zum GASAG Good-Practice-Beispiel überarbeitet (2. Iteration) und von diesem ausgehend zu einem branchenübergreifenden IC-Referenzmodell weiterentwickelt.

Im vorliegenden Artikel soll das aus dem Forschungsprojekt hervorgegangene Rollenmodell in seinen Grundzügen präsentiert werden. Bei der Ausgestaltung des IC – Rollenmodells wurde bewusst auf das Rollenkonzept von Scrum rekurriert. Dahinter steht die praxisbasierte Erkenntnis aus der ICU – Pilotphase, dass Teilaspekte des IC-Prozesses sowie notwendige Aktivitäten der Prozesssteuerung und die darin eingeschriebenen Prinzipien Parallelen zum Vorgehen sowie zu den Prinzipien und den Aufgabenbeschreibungen der agilen Methode Scrum aufweisen. Damit hat Scrum hier einen Vorbildcharakter für die Entwicklung eines funktionalen und differenzierten IC – Rollenmodells. In Vorbereitung auf die Darstellung des Rollenmodells, soll in einem ersten Schritt der IC-Prozess hinsichtlich seiner Beschaffenheit beleuchtet und vor dem Hintergrund der empirischen Projekterfahrung neu definiert werden, um die bestehenden Ähnlichkeiten zwischen IC und Scrum herausarbeiten zu können. Auf dieser Basis wird dann das IC-Rollenmodell in Auseinandersetzung mit den Scrum-Rollenansatz hergeleitet und im Detail beschrieben.

Der hier gemachte Gestaltungsvorschlag deutet auf das größere Ganze eines IC-Systems hin, dessen Komponenten in dem vorliegenden Artikel nicht alle besprochen werden können. An dieser Stelle sei daher auf die entsprechenden Beiträge in dem noch nicht veröffentlichten Sammelband „Internal Crowdsourcing in Companies: Theoretical Basics and Practical Applications“ (Ulbrich/Wedel/Dienel, geplantes Erscheinen 2020) verwiesen, die diese Lücken schließen werden.

12.2 Prozessaufbau von internem Crowdsourcing

Scrum, insbesondere zur agilen Softwareentwicklung genutzt, wird von seinen Entwicklern Ken Schwaber und Jeff Sutherland nicht als ein Prozess beschrieben, sondern als eine Methode bzw. als

„Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, [… das] aus Scrum-Teams und den zu ihnen gehörenden Rollen [Scrum Master, Product Owner, Development Team], Ereignissen [Sprint Planning, Daily Scrum, Sprint Review, Sprint Review, Sprint Retrospcective], Artefakten [Product Backlog] und Regeln [Prinzipien, Werte] [besteht]. Durch die Regeln […] werden Beziehungen und Wechselwirkungen zwischen den Rollen, Ereignissen und Artefakten bestimmt.“ (Schwaber und Sutherland 2017)

Die genannten Elemente des Rahmenwerks strukturieren aber die Arbeitshandlungen auf eine bestimmte Art und Weise und geben so, bei aller inhaltlichen Gestaltungsfreiheit der einzelnen Elemente, einen Arbeitsablauf vor. Zieht man die Definition von Petersen et. al. heran, die einen Prozess als eine Reihe von Aktivitäten beschreibt, die von allen Beteiligten ausgeführt werden, um ein bestimmtes Ergebnis zu erzielen oder ein bestimmtes Problem zu lösen (Pedersen et al. 2013, S. 581), kann man hier durchaus von einem Scrum-Prozess sprechen.

Internes Crowdsourcing als technologiebasiertes Vorgehensmodell hingegen wird, je nachdem, welcher Aspekt in den Vordergrund gestellt wird, entweder als Methode, Prozess oder auch als Tool bezeichnet. Dies hängt mit den unterschiedlichen Komponenten zusammen, die ein IC-System ausmachen. Wie in dem Beitrag von Wedel/Ulbrich in diesem Band ausgeführt, gibt es eine Vielzahl von Systematisierungsangeboten für IC, wobei die postulierten Begrifflichkeiten, die Auswahl der Komponenten sowie deren Positionierung zueinander variieren. Das hier zugrunde liegende Verständnis eines IC- Systems fußt auf der Zusammengehörigkeit von drei Bestandteilen: dem IC-Rollenmodell mit den dazugehörigen Steuerungsaktivitäten, dem IC-Prozess und der CT-Architektur.

Um die hier bewusst hergestellte Ähnlichkeit in der Rollenkonzeption erklären zu können, müssen zunächst einmal die „natürlich“ bestehenden Gemeinsamkeiten in der Prozessbeschaffenheit zwischen internem Crowdsourcing und Scrum identifiziert werden. Dies soll anhand der Beschreibung des in ICU entwickelten IC-Prozesses, d. h. der Prozessphasen, Prozesskomponenten Abschn. 12.2.1, 12.2.2 und Prozessebenen erfolgen Abschn. 12.2.3, die dann mit den Entsprechungen in Scrum in Beziehung gesetzt und das dort gewählte Rollenkonzept erläutert werden Abschn. 12.3. Darauf aufbauend wird dann das ICU-Rollenmodell entwickelt Abschn. 12.4.

12.2.1 IC-Prozessphasen und IC-Komponenten

In der Forschung findet sich eine Fülle an Beiträgen, die sich mit der Beschreibung von Crowdsourcingprozessen beschäftigen. Diese Prozessbeschreibungen, die in erster Linie auf externes Crowdsourcing abzielen, teilen Thuan et.al. in zwei Kategorien ein: Untersuchungen mit Analyseansätzen von hoher Granularität und Untersuchungen mit Analyseansätzen von niedriger Granularität (Thuan et al. 2017, S. 4 f., 2019, S. 27 ff.). Erstere legen den Fokus auf die Konzeptualisierung und bemühen sich darum, den Crowdsourcingprozess im Ganzen zu entwerfen, Ereignisse auf der Makroebene zu erkennen und in eine zeitliche Abfolge zu bringen (Etablierung von Prozessmodellen und Rahmenbedingungen). Zu dieser Gruppe gehören nach Thuan et. al. u. a. die Arbeiten von Brabham (2008), Leimeister et al. (2009), Geiger et al. (2011), und Zogaj et al. (2014, 2015). Im Gegensatz dazu konzentrieren sich die Forschungstätigkeiten mit niedriger Granularität nur auf Teilaspekte des Prozesses und beleuchten spezifische Komponenten mit Schwerpunkt auf die dazugehörigen Workflows auf der Mikroebene (Etablierung von Prozesskomponenten und Definition von Workflows), wie z. B. Studien zu Auswahl- bzw. Matchingmechanismen der geeigneten Zielgruppe für Aufgaben wie z. B. (Erickson et al. 2012), Cullina et al. (2016) und Geiger und Schader (2014) oder Studien zu Teilnahmemotivation und Anreizsystemen, wie z. B. Zhao und Zhu (2014), Machine und Ophoff (2014), Spindeldreher und Schlagwein (2016) und Feng et al. (2018).

Vor diesem Hintergrund ist für die nachfolgende Darstellung des in ICU entwickelten IC-Prozesses mit seinen Prozessphasen und Prozesskomponenten lediglich die hohe Granularitätsperspektive von Relevanz. Für internes Crowdsourcing ist die Anzahl der prozessorientierten Untersuchungen überschaubar. Demgemäß wird als Ausgangsbasis auf Phasenmodelle für externes Crowdsourcing zurückgegriffen, konkret auf das von Gassmann et.al. (2013, 2017), und entsprechend ergänzt. Im Allgemeinen lassen sich bei allen Prozessentwürfen grundlegende Merkmale ausmachen (ausführlicher vgl. Thuan et al. 2017), die sich auch bei Gassmann et. al. wiederfinden. Zuchowski et. al. haben speziell für IC einen Strukturierungsvorschlag gemacht (Zuchowski et al. 2016, S. 169), der dem von Gassmann et. al. ähnelt, allerdings nicht die in ICU erkannten Lücken in Bezug auf IC schließt. Deswegen findet der Vorschlag von Zuchowski et. al. in den weiteren Ausführungen keine Berücksichtigung.

Gassman et. al. teilen den Prozessverlauf in fünf Phasen ein (Gassmann et al. 2017, S. 29 ff.):

  1. 1.

    Vorbereitung: Der Ausgangspunkt stellt ein spezifisches Problem dar, das ein Unternehmen für sich lösen möchte. Der erste Schritt besteht also darin, sich über das gewünschte Ergebnis im Klaren zu werden, d. h. darüber, was erreicht werden und in welcher Form es am Ende vorliegen soll [Prozesskomponente: Zieldefinition].Footnote 1 Auch muss geklärt werden, wer die adäquate Zielgruppe für die zu bearbeitende Aufgabe ist, welche Plattform geeignet ist und ob es sich perspektivisch lohnt, eine eigene Community aufzubauen [Prozesskomponente: Community Management]. Nach Abwägen der genannten Aspekte fällt die grundsätzliche Entscheidung für oder gegen ein Crowdsourcing Projekt.

  2. 2.

    Initiierung: Im nächsten Schritt wird die Aufgabe an die Crowd über die ausgewählte Plattform gestellt und die Ideengenerierung gestartet. Dem vorweg geht die angemessene Aufbereitung der Aufgaben [Prozesskomponente: Aufgabendesign] und die Festlegung der Vergütung [Prozesskomponente: Motivationsmechanismen & Anreizsysteme].

  3. 3.

    Durchführung: Das Crowdsourcing Projekt läuft und die ersten Ideen etc. treffen ein. Diese müssen ins Unternehmen kommunikativ hineingetragen und ggf. aufkommende Widerstände aufgelöst werden [Prozesskomponente: Prozessmonitoring]. Auch müssen die Aktivitäten der Crowd gemanaged werden, um die Dynamiken in die erforderliche Richtung zu lenken.

  4. 4.

    Auswertung: Nach Beendigung der Crowdsourcingaktivitäten auf der Plattform werden die eingereichten Lösungsvorschläge ausgewertet. Hierbei ist zu klären, wer die Auswertung vornimmt und nach welchen Kriterien.

  5. 5.

    Verwertung: Abschließend müssen die Ergebnisse für die Weiterverwendung bzw. Weiterentwicklung aufbereitet und in den übergeordneten Unternehmensprozess etc. integriert werden [Prozesskomponente: Beschluss]. Die Ideengeber sollten über den unternehmensinternen Umgang mit ihren Ideen informiert werden. Das trägt zum Aufbau und Erhalt der Community bei [Prozesskomponente: Community Management].

Wie hier deutlich wird, ist eine Prozessphase die Summe ihrer einzelnen Komponenten, denn es ist nicht möglich die Prozessphasen zu beschreiben, ohne gleichzeitig die Prozesskomponenten zu beschreiben. Diese können auch als Ereignisse begriffen werden, die innerhalb einer Prozessphase auftreten. Im Phasenmodell von Gassmann et. al. wurden Komponenten als solche nicht explizit benannt. Das Herausstellen und Bennen der Prozesskomponenten ist aber wichtig, um später die Verteilung der Zuständigkeiten im Rollenmodell besser vornehmen zu können. Hat man diese nicht klar vor Augen, verlieren sich die Rollenbeschreibungen im Gewirr von einzelnen Steuerungsaktivitäten. Auch als Workflows bezeichnet sind Steuerungsaktivitäten als die handlungsorientierte Ausgestaltung der einzelnen Prozesskomponenten zu verstehen. Diese können von Unternehmen zu Unternehmen, aber auch innerhalb eines Unternehmens über den Zeitverlauf variieren, da sie auf die jeweiligen Rahmenbedingungen hin angepasst werden, im Gegensatz zu den Prozesskomponenten, die über die Zeit und für alle Anwendungskontexte konstant sind.

12.2.2 Prozessphasen im ICU-Modell

Grundsätzlich konnte für das idealtypische ICU-Modell grob auf dem Prozessablauf von Gassmann et. al. aufgebaut werden, allerdings mussten für die spezielle Form des internen Crowdsourcings Prozessphasen und Komponenten ergänzt bzw. stärker ausdifferenziert sowie umarrangiert werden.

Da es im Verständnis von ICU bei internem Crowdsourcing nicht nur um das einseitige Mobilisieren von Wissen und Erfahrungen der Beschäftigten für das Lösen von Problemen des Unternehmens geht, sondern damit auch die interne Zusammenarbeit sowie Mitarbeiterbeteiligung angestrebt werden soll, beginnt der IC-Prozess nicht per se mit einem gesetzten Problem, sondern vielmehr mit einem Vorschlag für ein bestehendes oder perspektivisches Problem bzw. einem Thema. Der IC-Prozess ist dementsprechend folgendermaßen aufgebaut:

  1. 1.

    Impuls: Themenvorschläge werden bei der zuständigen Stelle im Unternehmen, dem sog. Crowd Team, auf digitalem Weg über die IC-Plattform oder per Email oder auch in direkter (analoger) Absprache eingereicht. Mitarbeiter*innen aus allen Bereichen des Unternehmens ebenso wie Führungskräfte, die Geschäftsführung und Arbeitnehmervertretung sind berechtigt, Themen zu benennen. [Prozesskomponente: Themenvorschlag] Die eingehenden Vorschläge werden hinsichtlich der Relevanz für das Unternehmen gefiltert. Die Relevanz ergibt sich aus der vom Unternehmen festgelegten Zielstellung für das interne Crowdsourcing. [Prozesskomponente: Sondierung] Anschließend wird im Team darüber beraten, welcher Fachbereich an einem Thema interessiert sein könnte und Kontakt hergestellt, um sich über das Thema und potenzielles Content Ownership zu verständigen. [Prozesskomponente: Sondierungsgespräche] Tritt ein*e Mitarbeiter*in stellvertretend für einen Unternehmensbereich direkt an das Crowd Team heran, entfallen die Schritte der Sondierung und der Sondierungsgespräche.

  2. 2.

    Entscheidung No/Go: Die Entscheidung ein Thema zu verfolgen und ein Crowdsourcing Projekt, im weiteren Verlauf als Kampagne bezeichnet, aufzusetzen, hängt davon ab, ob es in einem der Unternehmensbereiche Bedarf für die Ergebnisse, die zu dem Thema erarbeitet werden, besteht und dafür sog. Content Ownership übernommen wird. [Prozesskomponente: Content Ownership] Besteht kein Content Ownership, wäre zum einen die Kampagne nicht sinnvoll in laufende Aktivitäten eingebettet und zum anderen das Prinzip der Prozesstransparenz nicht gewährleistet. Prozesstransparenz meint, dass für die teilnehmenden Mitarbeiter*innen zu jedem Zeitpunkt des Prozesses bzw. des für die Crowd sichtbaren Teils des Prozesses (Kampagne) deutlich und nachvollziehbar ist, welches Interesse das Unternehmen/der Bereich an dem Thema hat, welche Ziele mit der speziellen Kampagne verfolgt und wie die Bemühungen der Crowd, d. h. die Ergebnisse verwertet werden.

  3. 3.

    Konzeption: Ist die Entscheidung für eine Kampagne gefallen, muss ein Kampagnenkonzept entwickelt werden, das verschiedene Aspekte zu berücksichtigen hat. Um die Produktivkräfte einer Crowd nutzbar machen zu können, müssen Themen, die von den Mitarbeiter*innen in der Crowd für das Unternehmen bearbeitet werden sollen, strukturiert und zielgerichtet aufbereitet werden, damit die Crowdaktivitäten zu sinnvollen und verwertbaren Ergebnissen führen. Zuerst muss daher Klarheit darüber geschaffen werden, was das Ziel der Kampagne sein soll. Damit einher geht die Definition der Ergebnispräsentation, d. h. dass überlegt muss, in welcher Form das abgerufene Wissen am Ende der Kampagne vorliegen soll, z. B. in Form eines Meinungsbildes oder eines Konzeptentwurfs. [Prozesskomponente: Zieldefinition] In direktem Zusammenhang damit stehen auch die Festlegung der Kriterien, nach denen die gelieferten Ergebnisse ausgewählt werden [Prozesskomponente: Auswahlkriterien], und die Überlegungen, wie die ausgewählten Ergebnisse dann in den Arbeitsbereich des Content Owners integriert werden können. Je komplexer die Zielstellung ist, desto mehr handelt es sich bei letzterem um eine Ideensammlung für Anbindungsmöglichkeiten und nicht um die Bestimmung eines stoischen Verwertungsprozederes. Eine sinnvolle Weiterverwertung kann letztendlich erst anhand der erarbeiteten Ergebnisse ermittelt werden. [Prozesskomponente: Verwertungsintention] Weiterhin muss entschieden werden, welche Anreize für die Mitarbeiter*innen gesetzt werden können, um diese zur Teilnahme zu motivieren. Anders als beim externen Crowdsourcing ist beim internen Crowdsourcing eine Inzentivierung nicht immer notwendig, z. B. wenn es sich um ein Crowdstorming oder Crowdvoting handelt. [Prozesskomponente: Anreizsystem] Die vorangegangenen Prozesskomponenten sind die Voraussetzungen für die Erarbeitung des Aufgabendesigns. Das Aufgabendesign besteht in der Beschreibung der Aufgabenstellung, in der das übergeordnete Interesse, die Zieldefinition, Ergebnisdefinition, ggf. Anreize, Auswahlkriterien, mögliche Ergebnisverwertung und der Zeitplan klar dargelegt werden, und zudem in der Auswahl der Aufgabentypen. In ICU wurden fünf Aufgabentypen etabliert, die sich auch in der Forschung als Standard widerspiegeln (Brabham 2008; Leimeister und Zogaj 2013; Chiu et al. 2014; Zogaj et al. 2015; Jaafar und Dahanayake 2015):

    • Crowdstorming – Die Crowd wird aufgerufen, zu einem gesetzten Thema inhaltliche Facetten aufzuzeigen und konkrete Chancen und Herausforderungen dazu zu formulieren. Die Zielsetzung ist hier Themenexploration.

    • Crowdvoting – Die Crowd wird zu Bewertungen, Abstimmungen, Meinungen oder Empfehlungen von gesetzten Themen aufgerufen. Die Zielsetzung ist hier die Erstellung von Meinungsbildern und Prognosen.

    • Crowdsolving – Die Crowd wird zur Erstellung und Entwicklung von Problemlösungen für bestehende Dienstleistungen, Produkte und Prozesse aufgerufen. Die Zielsetzung ist hier die Optimierung von Bestandsangeboten.

    • Crowdcreation – Die Crowd wird zur Erstellung und Entwicklung von neuen Ideen und Konzepten für Produkte, Dienstleistungen und Prozessen aufgerufen. Die Zielsetzung ist hier Innovationsgenerierung.

    • Crowdtesting – Die Crowd wird zum Testen von Prototypen für Dienstleistungen, Produkte und Prozesse z. B. im Hinblick auf Usability & UX aufgerufen. Die Zielsetzung ist hier das Einholen

Abhängig von der übergeordneten Zielstellung der Kampagne können Aufgabentypen als eigenständig durchgeführte Maßnahme, sog. Stand-Alones, oder, was häufiger der Fall ist, als Kombination nach dem Mix & Match-Prinzip gewählt werden. Diese Verkettung von verschiedenen Aufgabentypen ermöglicht durch die kontinuierliche Steigerung des Komplexitätsgrads in den Tätigkeitsanforderungen an die Crowd eine mehrstufige, iterative Ergebnisentwicklung Abb. 12.1. [Prozesskomponente: Aufgabendesign]

Abb. 12.1
figure 1

Aufgabendesign mit dem Mix & Match-Prinzip. (Eigene Darstellung)

Full size image

Für den Erfolg einer Kampagne ist die Sichtbarkeit im Unternehmen entscheidend. Um auf eine Kampagne aufmerksam zu machen und Beteiligung anzuregen, muss diese intern über alle zur Verfügung stehenden Kommunikationskanäle, sowohl digital, z. B. über Social Media Anwendungen und das Intranet, als auch analog, z. B. durch Informationsveranstaltungen und Poster/Flyer, beworben werden. Welche Kommunikationsmaßnahmen zu welchem Zeitpunkt für eine Kampagne geeignet sind, um die größtmögliche Reichweite im Unternehmen herzustellen, muss strategisch geplant [Prozesskomponente: Marketingstrategie] und mit der Abfolge der gewählten Aufgabentypen und den daraus resultierenden Ereignissen, d. h. mit dem Kampagnenzeitplan, abgestimmt werden. Im Zeitplan ist auch der Beginn, das Ende und die Dauer der einzelnen Phasen der Kampagne festgelegt, z. B. die Dauer für die Beteiligung an einer Kampagne, Ergebnisauswertung und der Ergebnisveröffentlichung. [Prozesskomponente: Zeitplan] Am Ende der Konzeptionsphase steht dann die technische Umsetzung des Kampagnenkonzeptes an. [Prozesskomponente: IT Template]

  1. 4.

    Durchführung: Mit Vorlauf zur Kampagne startet als erstes das Marketing für die Kampagne, indem diese mit konkretem Thema und Rahmeninformationen angekündigt wird (Teaser). [Prozesskomponente: Crowd/Community Management]Footnote 2 Wenn die Kampagne dann angelaufen ist, müssen die anfallenden Prozessaktivitäten im Kampagnen Team koordiniert werden. [Prozesskomponente: Prozesskoordination] Hinzukommend ist ein kontinuierliches Prozessmonitoring hinsichtlich der IT-Funktionalitäten, des Prozessfortschritts und Zeitplans erforderlich sowie eine Form von Reporting dem Content Owner gegenüber. [Prozesskomponente: Prozessmonitoring] Auf technischer Ebene müssen Prozesse für den reibungslosen Kampagnenablauf aufgesetzt, konfiguriert und Support geleistet werden wie auch die eingespeisten Inhalte (z. B. die Aufgabenstellung) verwaltet werden. [Prozesskomponente: IT & Content Management] Einen sehr hohen Stellenwert hat in dieser Phase die Kommunikation mit der Crowd, die durch aktive Interaktion sowohl auf der Plattform in Form von Feedback und Moderation als auch bei analogen Events, die in der Marketingstrategie vorgesehen sind, für ein konstantes Crowd-Engagement sorgen soll. [Prozesskomponente: Crowd/Community Management]

  2. 5.

    Auswertung: Wenn die aktive Arbeitsphase der Crowd beendet ist, müssen die eingetroffenen Ergebnisse ausgewertet werden. Als erstes werden die Ergebnisse hinsichtlich ihrer Relevanz für die eingangs formulierte Zielsetzung der Kampagne anhand der definierten Auswahlkriterien vom Kampagnen Owner und Crowd Master gesichtet. [Prozesskomponente: Auswahl] Anschließend muss diese Vorauswahl für den Content Owner aufbereitet werden [Prozesskomponente: Aufbereitung], der diese dann in Rücksprache mit dem Arbeitsbereich evaluiert. [Prozesskomponente: Evaluation]

  3. 6.

    Verwertung: Bei manchen Kampagnen ist die anfänglich formulierte Verwertungsintention identisch mit der tatsächlichen Endverwertung, z. B. wenn es um Meinungsbilder geht, die mit internen Bereichsaktivitäten abgeglichen werden sollen. Wenn es um anspruchsvollere Zielsetzungen geht, wie bspw. die Erarbeitung eines neuen Businessmodells durch eine Crowdcreation, muss die Frage nach der Ergebnisverwertung an dieser Stelle noch einmal konkret gestellt und beschlossen werden. [Prozesskomponente: Beschluss] Der erarbeitete Output kann selbstverständlich auch die Ausgangsbasis für eine neue Kampagne darstellen.

  4. 7.

    Abschlusskommunikation: Ein wichtiger Erfolgsfaktor für das dauerhafte Gelingen von IC ist beständige und transparente Kommunikation im gesamten Prozessverlauf. Wesentlich hierfür ist die Kommunikation der ausgewählten Ergebnisse, in der Regel mit Begründung, und die Bekanntgabe der Weiterverwendung als Abschluss der Kampagne. Die Ergebnisse sollten auf der Plattform veröffentlicht werden, damit sie von den Kampagnenteilnehmer*innen und allen auf der Plattform angemeldeten Mitarbeiter*innen eingesehen und ggf. noch kommentiert werden können. Um auch Beschäftigte, die nicht Teil der Unternehmenscrowd sind, in den Informationsfluss einzubinden, sollten die Ergebnisse und Beschlüsse auch über die anderen Kommunikationskanäle des Unternehmens gespielt werden. [Prozesskomponente: Ergebniskommunikation] Wenn in der Kampagnenkonzeption Anreize für die Beteiligung gesetzt wurden, z. B. die Verlosung von Preisen, dann müssen diese abschließend eingelöst werden. Bei anspruchsvollen Tätigkeiten, die von der Crowd abverlangt wurden, wie z. B. die Erarbeitung eines Konzeptes, sollten auch die Bemühungen der Teilnehmenden, die nicht als Gewinner*innen gekürt wurden, in Form einer Begründung für die Nicht-Auswahl honoriert werden. [Prozesskomponente: Honorierung]

Wie auch im ICU Forschungsprojekt zu beobachten war, können die Steuerungsaktivitäten innerhalb der einzelnen Prozesskomponenten in der Praxis parallel laufen oder an bestimmten Stellen zusammengefasst werden. Die Prozesskomponenten als solche bleiben aber bestehen.

12.2.3 IC-Prozessebenen

Wie aus den vorangegangenen Schilderungen deutlich wird, ist für die erfolgreiche Umsetzung von IC ein hoher kommunikativer und koordinatorischer Aufwand notwendig, um den Prozess wirksam im Unternehmen zu verankern. Im ICU-Modell wurden drei verschiedene Ebenen identifiziert, auf denen der Prozess hinsichtlich unterschiedlicher Aspekte und Zielgruppen kommuniziert wird:

Makroebene: Gesamtprozess

Auf der Makroebene geht es zum einen darum, den IC-Prozess als solchen im Unternehmen zu repräsentieren und seinen Mehrwert für Geschäftsaktivitäten darzustellen (Prozessmarketing). Zum anderen wird hier der Fokus auf die Betrachtung des Gesamtprozesses gelegt und dafür gesorgt, dass die festgelegten Rahmenbedingungen für IC im Unternehmen mit dem Prozessverlauf im Einklang stehen und die Prozessintegrität gewährleistet ist. Die Zielgruppe der Prozesskommunikation ist dabei das gehobene Management, die Geschäftsführung und der Betriebsrat.

  • Mesoebene: Kampagne

Die IC-Kampagne stellt die operative Umsetzung eines Themas dar und bildet damit das Kernstück des IC-Prozesses. Sie setzt sich aus „sichtbaren“ Prozessphasen mit Kommunikationstätigkeiten, die im Vordergrund laufen, (Durchführung, Abschlusskommunikation) und „nicht sichtbaren“ Prozessphasen mit Kommunikationstätigkeiten, die im Hintergrund laufen, (Konzeption, Auswertung, Verwertung) zusammen. Während die „sichtbaren“ Phasen auf der Mikroebene stattfinden, sind die „nicht sichtbaren“ Prozessphasen auf der Mesoebene angesiedelt und darauf ausgerichtet, den Sinn und Zweck der Kampagne in einem ausgewählten Kreis zu definieren und abzustimmen. Die Prozesskommunikation richtet sich hier an die Unternehmensbereiche, die an der Konzeption und Umsetzung der Kampagne beteiligt sind.

  • Mikroebene: Community/Crowd

Auf der Mikroebene zielt die Prozesskommunikation in den sog. „sichtbaren“ Phasen auf die Beschäftigten ab, d. h. auf die Community und die Crowd. In Form von Kampagnenmarketing dient diese anfangs dazu, den Sinn und Zweck der Kampagne zu vermitteln sowie um Teilnahme zu werben. Im weiteren Verlauf wird dann über den Kampagnenfortschritt informiert, um die Crowdaktivitäten am Laufen zu halten und das Prinzip der Transparenz zu wahren. Zudem kommt es innerhalb der Kampagne auch zu direkter Interaktion, z. B. in Form von Moderation auf der Plattform oder IT-Support.

Die hier vorgenommene Unterscheidung der Prozessebenen ist hilfreich, um später die Verantwortlichkeiten der Rollen besser voneinander abgrenzen und Steuerungsaktivitäten klar zuordnen zu können.

12.3 Parallelen zwischen internem Crowdsourcing und Scrum

In diesem Abschnitt erfolgt zuerst der Vergleich mit den für IC relevanten Komponenten des Scrum Prozesses mit anschließender Darstellung der in Scrum definierten Rollen, um darauf aufbauend in Abschn. 1.4 das ICU-Rollenmodell vorstellen zu können. Es gibt zwei wesentliche Gemeinsamkeiten, die eine Rollenaufteilung für IC nahe legen, die der von Scrum ähnelt:

12.3.1 Vergleich Prozessebenen

Eine grundlegende Übereinstimmung zwischen IC und Scrum besteht in den unterschiedlichen Prozessebenen, auf denen Prozesskommunikation stattfindet. Dieser Umstand kommt in der Scrum-Literatur (vgl. Goll und Hommel 2015; McKenna 2016; Schwaber und Sutherland 2017; Maximini 2018) nur indirekt zum Ausdruck, da Scrum als ein Regelwerk begriffen und nicht aus einer prozessorientierten Perspektive betrachtet wird. Aber ebenso wie weiter oben für IC erläutert, hat auch Scrum eine Makro-, Meso- und Mikroebene, auf denen voneinander getrennte Kommunikationsaktivitäten vollzogen werden.

  • Makroebene: Gesamtprozess

Wie bei IC geht es auf der Makroebene darum, Scrum mit seinen Prinzipien, seinen Praktiken, Regeln und Werten im Unternehmen zu vertreten und allen den Mehrwert des Vorgehensmodells begreiflich zu machen (Prozessmarketing). Ganz konkret befindet sich hier auch das Regelwerk, das den Rahmen für die Teamarbeit auf der Mikroebene stellt.

  • Mesoebene: Produktdefinition

Auf der Mesoebene wird das Produkt entworfen, indem ein Anforderungskatalog, das sog. Product Backlog erstellt wird, der definiert, wie das Produkt aussehen soll, was es leisten soll und welchen Mehrwert es für Kunden darstellen soll.

  • Mikroebene: Produktentwicklung

Die im Product Backlog festgehaltenen Anforderungen werden auf der Mikroebene in einem iterativen Vorgehen, dem sog. Sprint,Footnote 3 umgesetzt. Dafür muss sich darüber verständigt werden, was aus dem Product Backlog genau in einem Sprint verwirklicht werden soll (Erstellen eines Sprint Backlog) und auf welche Weise, d. h. wie die Arbeit an den anstehenden Aufgaben organisiert werden soll.

12.3.2 Vergleich Prinzip der Transparenz

Das Scrum Regelwerk umfasst nicht nur Vorgaben wie Praktiken und Regeln, sondern benennt auch Werte und Prinzipien für die Zusammenarbeit. Eines der drei Prinzipien ist Transparenz. Ken Schwaber und Jeff Sutherland definieren Transparenz in „The Scrum Guide“ (2017) folgendermaßen:

„Die wesentlichen Aspekte des Prozesses müssen für diejenigen sichtbar sein, die für das Ergebnis verantwortlich sind. Transparenz erfordert, dass diese Aspekte nach einem gemeinsamen Standard definiert werden, damit die Betrachter ein gemeinsames Verständnis des Gesehenen teilen.“ (S. 7)

Transparenz bedeutet demnach, dass alle Beteiligten zu jedem Zeitpunkt im Arbeitsprozess wissen, wie der momentane Entwicklungsstand aussieht, an welchen Features und Problemen speziell gearbeitet wird, wer welche Tätigkeiten ausführt und wie die einzelnen Komponenten zu dem Endprodukt beitragen. Hergestellt wird Transparenz u. a. mit Events wie dem Daily Scrum, bei dem sich die Teammitglieder (Prozessbeteiligte auf der Mikroebene) täglich über den Stand ihrer Arbeit austauschen und mit den gesetzten Sprintzielen abgleichen (Schwaber und Sutherland 2017, S. 12). Dadurch dass alle einen Überblick über den Arbeitsprozess und den Fortschritt haben, entsteht Vertrauen in die Teamarbeit und den Prozess, was die Teammitglieder wiederum motiviert (McKenna 2016).

Wie die in ICU durchgeführten Mitarbeiter*innenbefragungen beim Praxispartner ergeben haben, ist Prozesstransparenz auch bei IC die Schlüsselkomponente, die dafür sorgt, dass bei den Beschäftigten (Community & Crowd) Vertrauen in das Verfahren und Motivation aufgebaut sowie die Beteiligung an Kampagnen als sinnhaft empfunden wird. Prozesstransparenz wird hier erreicht, indem, wie oben im ICU-Phasenmodell beschrieben, Kampagnenziele und -hintergrund sowie die Ergebnisverwertung und einzelnen Schritte innerhalb der Kampagne offen und verständlich an die Beschäftigten kommuniziert werden und das Verfahren als solches einen nachvollziehbaren Zweck im Unternehmen erfüllt.

12.3.3 Scrum Rollenmodell

Die eben beschriebenen Prozessebenen verweisen auf bestimmte Verantwortungsbereiche, die es zu managen bzw. zu steuern gilt. Im Scrum sind dafür drei Rollen vorgesehen, die folgende Aufgaben ausführen:

  1. 1.)

    Scrum Master (Makroebene)

Der Scrum Master ist verantwortlich dafür, die grundsätzliche Idee sowie die Praktiken, Regeln und Werte von Scrum im Unternehmen zu vertreten (Botschafterfunktion), diese intern anschlussfähig zu machen (ggf. Unternehmensentwicklung) und zu implementieren. Als Coach und Servant Leader hilft der Scrum Master den Beschäftigten auf unterschiedlichen Ebenen dabei, das agile Regelwerk zu verstehen und anzuwenden. Konkret unterstützt der Scrum Master z. B. das Scrum Team dabei, in ihrer Arbeit die agilen Prinzipien stets einzuhalten und verweist, wenn nötig, auf die korrekte Umsetzung des Regelwerks. Dem Product Owner steht der Scrum Master bei der Erstellung und dem Management des Product Backlogs und der Kommunikation mit dem Scrum Team hilfreich zur Seite. Zudem vermittelt der Scrum Master Beschäftigten außerhalb des Scrum Teams, wie sie mit dem Scrum Team am sinnvollsten interagieren können, um die Produktivität des Scrum Teams zu steigern (Schwaber und Sutherland 2017, S. 7 f.)

  1. 2.)

    Product Owner (Mesoebene)

Der Product Owner (PO) ist die kommunikative Schnittstelle zwischen dem Scrum-Team, den Auftraggebern und dem Unternehmen bzw. allen, die sich für die Arbeit des Scrum Teams interessieren (Stakeholder). Die Kernaufgabe des PO besteht darin, sich mit den Auftraggebern über das gewünschte Produkt auszutauschen und einen Anforderungskatalog, das Product Backlog, für die Produktentwicklung zu erstellen. Anforderungen werden in Form von User Stories gelistet, die der PO entwickelt, und dem Scrum Team präsentiert. Als Repräsentant*in der Auftraggeber*innenperspektive ist der PO der Alleinverantwortliche für das Product Backlog und entscheidet darüber, ob weitere Anforderungen aufgenommen oder fallen gelassen werden. Auch ist der PO die Instanz, die während des Sprints den Verlauf beeinflussen kann oder am Ende die potenziell auslieferbaren Produktinkremente annimmt oder ablehnt, wenn sie nicht dem Product Backlog entsprechen. Daneben muss der PO auch die finanziellen Aspekte verwalten und Key Performance Indicators (KPIs) wie ROI (Return on Investment) im Blick haben (McKenna 2016, S. 39; Schwaber und Sutherland 2017, S. 6).

  1. 3.)

    Scrum Team (Mikroebene)

Das Scrum Team ist ein sog. cross-funktionales Entwicklungsteam, das sich und seine Arbeit selbst organisiert. Die Teammitglieder haben keine definierten Rollen, sondern alle müssen in jedem Sprint in der Lage sein, Software zu schreiben, zu testen, zu dokumentieren und auszuliefern. Das Team entscheidet zusammen, welche Items aus dem Product Backlog in einem Sprint verwirklicht und in den Sprint Backlog aufgenommen werden sollen (Sprint Planning & Sprint Goal). Während des Sprints arbeitet das Team autark, nur beim Daily Scrum, was zur gemeinsamen Überprüfung und Versicherung des Entwicklungsfortschritts dient, sind der Scrum Master und optional auch der PO anwesend. Am Ende des Sprints präsentieren die Teammitglieder dem PO und den Stakeholdern ihr potenziell auslieferbares Produktinkrement (Sprint Review), dass dann abgenommen wird oder nicht. Am Ende nimmt das Team unter Anwesenheit des Scrum Masters eine Sprint Retrospective vor, die der Analyse des abgeschlossenen Sprints dient (Lessons Learned and How to Improve) und auf eine Verbesserung des nächsten Sprintverlaufs abzielt (McKenna 2016, S. 42; Schwaber und Sutherland 2017, S. 7).

Das Prinzip der Transparenz kann als Querschnittsaufgabe verstanden werden, für die alle Rollen gleichermaßen die Verantwortung tragen. Allerdings bedeutet die Umsetzung von Transparenz auf jeder Prozessebene und für jede Rolle etwas anderes:

„All of the team’s success and failure is out in the open for all to see. The team is operating in a transparent manner and sharing information; the product owner is also being transparent and sharing. The Scrum Master posts all relevant team information on information radiators so that stakeholders can easily find out how the Sprint is progressing. […] Instead of hiding information, a Scrum team broadcasts everything about what they are up to.“ (McKenna 2016, S. 36)

12.4 Entwurf des ICU-Rollenmodells

Das im Forschungsprojekt ICU entwickelte Rollenmodell orientiert sich im Kern an der Rollenaufteilung und -gestaltung von Scrum, enthält darüber hinaus aber noch weitere Akteure. Es beschreibt die Aufteilung der Zuständigkeiten für die unterschiedlichen Prozessebenen sowie Prozessabschnitte und den damit einhergehenden Steuerungsaktivitäten. Zudem gibt es an, welche Unterstützungstätigkeiten aus anderen Unternehmensbereichen, in Anlehnung an Porters Prozessmodell (Porter 1985) hier als Sekundäreinheiten bezeichnet, zusätzlich benötigt werden.

Primäre Rollen

In ICU wurden drei Rollen identifiziert, die unabdingbar für die erfolgreiche Umsetzung von IC sind: 1) Crowd Master, 2) Kampagnen Master und 3) Crowd-Technology Manager.Footnote 4 Zusammen bilden sie das sog. Crowd Team, das die Anlaufstelle für das Thema im Unternehmen darstellt und zusammen die Verantwortung für den gesamten Prozess trägt. Konkret erfüllen die drei Rollen folgende Aufgaben:

  1. 1.)

    Crowd Master (Makro-/Mesoebene)

Abb. 12.2
figure 2

ICU-Rollenmodell. (Eigene Darstellung)

Full size image

In Absprache mit dem Vorstand bzw. der oberen Führungsebene und der Arbeitnehmervertretung ist der Crowd Master (CM) für die allgemeine Ausrichtung sowie die Zielumsetzung von IC im Unternehmen verantwortlich. Der CM sorgt dafür, dass die aufgestellten Rahmenbedingungen eingehalten und die Integrität und Qualität des Prozesses gewährleistet (Prozessmonitoring) werden. Die Idee von IC wird vom CM im Unternehmen promotet, um ein Bewusstsein für die Nutzungsmöglichkeiten und den Aufbau bzw. Ablauf von IC-Kampagnen zu schaffen, z. B. durch unvermittelte Ansprachen, Workshops oder Informationsinitiativen, und IC als alltägliche Arbeitsroutine zu etablieren (Botschafterfunktion). Als IC-Repräsentant*in vernetzt sich der CM proaktiv mit den Fachabteilungen und wichtigen Key Playern und baut so Prozessallianzen und Verbindlichkeiten auf, z. B. in Form von Content Ownership (Prozesskomponente: Sondierungsgespräche) oder Multiplikatoren. Bei der Entwicklung und Durchführung von Kampagnen sowie bei der Sichtung der Kampagnenergebnisse steht der CM dem Kampagnen Owner als Sparringpartner zur Seite. Dabei ist die Frage nach der Inzentivierung der Mitarbeiter*innen entscheidend. Der CM trägt die gängigen Inzentivierungsmechanismen im Unternehmen zu einer Art Katalog zusammen bzw. entwickelt das Anreizsystem weiter. Um die Unterstützung im Unternehmen, vor allem das Commitment des Vorstands/oberen Führungsebene für IC zu sichern, muss der CM den Erfolg und Fortschritt anhand von aussagekräftigen Kennzahlen (z. B. Anzahl der Anmeldungen auf der Plattform, Anzahl der Kampagnenteilnehmer*innen, Zufriedenheit der Content Owner etc.) in regelmäßigen Reports dokumentieren.

  1. 2.)

    Kampagnen Owner (Meso-/Mikroebene)

Der Kampagnen Owner (KO) ist der Dreh- und Angelpunkt auf der operativen Ebene und verantwortlich für die Entwicklung sowie Umsetzung von IC-Kampagnen. Für die Zieldefinition, Verwertungsintention und inhaltliche Gestaltung der Kampagne arbeitet der KO mit dem Content Owner zusammen. Auf dem gemeinsamen Austausch aufbauend entwirft der KO das Aufgabendesign (Auswahl der Aufgabentypen, Aufgabenformulierung mit Hintergrundinformationen, Auswahlkriterien) und wählt die passenden Beteiligungsanreize aus dem vom CM erstellten Inzentivierungskatalog für die spezielle Kampagne aus. Hinsichtlich der Planung der Kampagnenkommunikation spricht sich der KO mit den Sekundäreinheiten ab und integriert alle Aktivitäten zu einem übergeordneten Kampagnenzeitplan. Den Kampagnenzeitplan teilt der KO im gesamten Team, damit der Ablauf für die Beteiligten transparent ist. Den Crowd-Technology Manager (CTM) brieft der KO in Bezug auf das Aufgabendesign, so dass dieser die Kampagne technisch aufsetzten kann, und liefert dem CTM die Texte der Aufgabenbeschreibung. Während der Durchführungsphase koordiniert der KO alle Aktivitäten, führt das Kampagnenmonitoring durch und steht im Austausch mit der Crowd, z. B. durch Moderation auf der Plattform oder dem Beantworten von Anfragen (Crowd/Community Management). Nachdem die aktive Arbeitsphase für die Crowd beendet ist, trifft der KO zusammen mit dem CM eine Vorauswahl der Ergebnisse anhand der aufgestellten Kriterien und bereitet diese für die Evaluation durch den Content Owner und einem ausgesuchten Auswahlkomitee auf. Nach dem Beschluss honoriert der KO die Bemühungen der Kampagnenteilnehmer*innen (Feedback, Award Ceremony etc.) und bereitet die Kampagnenergebnisse für die abschließende Kommunikation vor.

  1. 3.)

    Crowd-Technology Manager (Meso-/Mikroebene)

Der Crowd-Technology Manager (CTM) ist unter Anleitung des Kampagnen Owners für die technische Umsetzung der Kampagne zuständig und konfiguriert den IT Prozess der Kampagne. Anhand des Aufgabendesigns erstellt der CTM ein IT Template, in das der CTM die vom KO gelieferten Textbausteine zur Aufgabenbeschreibung und später zur Ergebnisveröffentlichung einspeist. Entsprechend den im Kampagnenzeitplan vorgesehenen Events verwaltet der CTM die Kommunikation auf der Crowdsourcing Plattform, d. h. der CTM schaltet die Kampagnen live, also die unterschiedlichen Arbeitsphasen (erst Crowdvoting, dann Crowdstorming etc.), und veröffentlicht Mitteilungen (Content Management). Der CTM sorgt für eine reibungslose User Xperience und kümmert sich darum, dass die Plattform fehlerfrei läuft und erreichbar ist (kontinuierliches Bug Fixing). Bei technischen Problemen mit der Plattform oder Kampagnen stellt der CTM den Anwender-Support.

Sekundäre Rollen

Wie in der Rollenbeschreibung des KO erwähnt, bedarf es für die Planung und Durchführung von Kampagnen die Unterstützung von Beschäftigten aus anderen Abteilungen des Unternehmens, die den sog. Sekundäreinheiten angehören. Um die Zusammenarbeit zu koordinieren wird ein sog. Kampagnen Team gebildet, das zusätzlich zum Kampagnen Owner und dem Crowd-Technology Manager aus dem Content Owner, den einzelne Repräsentanten*innen der Sekundäreinheiten (Sekundäre Counterparts) und den Beschäftigten in der Crowd besteht.

  1. 4.)

    Content Owner (CO)

Der Content Owner (CO) hat die fachliche Expertise für das Kampagnenthema und ist in der Facheinheit der/die Ansprechpartner*in für den KO bei der inhaltlichen Kampagnenkonzeption. Ziel und Zweck der Kampagne wird vom CO so definiert, dass die Fachabteilung anschließend mit den gewonnenen Ergebnissen weiterarbeiten kann. Der CO kann, muss aber nicht identisch mit der Person sein, die den Themenvorschlag beim Crowd Team eingereicht hat. Grundsätzlich können alle Beschäftigte Themen vorschlagen, für die sie Ownership übernehmen können, aber nicht müssen. Wenn kein Ownership besteht, müssen der CM und der KO im Unternehmen eine geeignete Facheinheit anfragen, das Ownership zu übernehmen und einen CO zu stellen. Bei der Evaluation der Ergebnisse ist der CO Teil des Auswahlkomitees.

  1. 5.)

    Sekundäre Counterparts (SC)

Der KO sucht die Unterstützung für die Planung und Durchführung von Kampagnen bei den entsprechenden Experten im Unternehmen. Bei der Entwicklung der Kampagnenkommunikation wendet sich der KO daher z. B. mit einem Entwurf an das interne Marketing bzw. die Stelle für Mitarbeiterkommunikation, mit denen diese ausgereift wird (Internes Marketing Counterpart). Für die Durchführung von Offline-Formaten des Community Managements zur Begleitung der IC-Kampagnen wendet sich der KO für Unterstützung beispielsweise an die Abteilung, die interne Events und partizipative Formate durchführt (Events & Formate Counterpart). Für Weiterbildungsformate oder –initiativen im Zusammenhang mit Kampagnen arbeitet der KO mit der Personalabteilung zusammen (HR Counterpart). Auch der Crowd-Technology Manager steht in regem Kontakt mit der IT Abteilung, um die Plattform konform mit den Richtlinien der IT-Architektur des Unternehmens auszusteuern (IT Counterpart). In welchen Unternehmensbereichen die benötigten Ansprechpartner*innen sitzen, ist von der Struktur des jeweiligen Unternehmens abhängig.

  1. 6.)

    Crowd

Die Crowd wird hier zwar dem Kampagnen Team zugeordnet, doch ist sie kein konventionelles Teammitglied so wie die eben dargestellten, sondern die Bedingung dafür, dass Kampagnen durchgeführt werden können. Es ist die Rolle, die die in der Kampagne gestellten Aufgaben bearbeitet und Ergebnisse hervor bringt. Da die Crowd nur während der Kampagne aktiv in Erscheinung treten kann und dort ein gegenseitiger Austausch mit konventionellen Teammitgliedern und der Crowd entsteht, ist sie eine Komponente im Kampagnen Team.

Tertiäre Rollen

Der Erfolg von IC hängt im Wesentlichen vom Commitment des 7) Vorstands/der Führungsebene und der Unterstützung der 8) Arbeitnehmervertretung ab. Gemeinsam mit dem CM müssen diese zwei Stakeholdergruppen die Rahmenbedingungen für IC im Unternehmen aushandeln und festlegen sowie deutlich vertreten, dass sie hinter dem Prozess und seiner Zielsetzung stehen.

12.5 Fazit

Das hier vorgestellte ICU- Rollenmodell soll Unternehmen als Hilfestellung dienen, die an der Einführung von IC interessiert sind. Es gibt an, wie man planen muss, wenn IC erfolgreich implementiert werden soll. Die angeführte Aufteilung der Rollen ist eine idealtypische und lässt sich entsprechend der Gegebenheiten und vorhandenen Ressourcen im Unternehmen beliebig skalieren. Das heißt, dass einige der beschriebenen Rollen entsprechend des Arbeitsaufkommens in Personalunion ausgeführt werden können, wie z. B. der Crowd Master und der Kampagnen Owner oder der Crowd-Technology Manager und der IT Counterpart.

Das Rollenmodell ist Teil eines übergeordneten IC-Systems, dem sog. ICU-Modell, das sich in erster Linie an Unternehmen richtet, die eine stärkere Orientierung bei ihrem individuellen Transformationsprozess brauchen und interessiert daran sind, über niedrigschwellige, digitale Prozesse intern vorhandenes Wissen und Kompetenzen ihrer Beschäftigten zu mobilisieren, schneller zu vernetzen und produktiv für ihre Geschäftsprozesse nutzbar zu machen.

Gleichzeitig soll damit aber auch ein Weg aufgezeigt werden, wie durch die Anwendung von IC die Beteiligung von Mitarbeiter*innen in Unternehmen erhöht werden und ein direkterer Wissensaustausch über Abteilungsgrenzen hinweg sowie zwischen Führungsebene und operativer Ebene entstehen kann.