Was verstehen wir unter unternehmensinterner Innovation?

„Wer aufhört besser zu werden, hat aufgehört, gut zu sein.“ Dieses Zitat von Philipp Rosenthal beschreibt die Motivation vieler Unternehmen, in Innovation zu investieren. Die zunehmende Verbreitung von Softwarelösungen führt zu immer schnellerem Wandel bei gleichzeitig sehr individuellen Anforderungen. Dies setzt Unternehmen heutzutage unter Druck, beispielsweise mithilfe von internen Innovationsprogrammen ihre Kernkompetenzen und zukünftige Marktchancen zu entwickeln.

Müller-Prothmann und Dörr beschreiben Innovationen als Resultat dreier Komponenten: Zu Beginn stehen Ideen. Diese werden in neue Produkte, Dienstleistungen oder Verfahren umgesetzt (Invention). Erst die tatsächlich erfolgreiche Anwendung im Markt und die Marktdurchdringung (Diffusion) macht ein Produkt zur Innovation [1].

In diesem Artikel stellen wir 2 Ansätze vor, die wir für die Ideensammlung und Invention im Unternehmenskontext erprobt haben (vgl. Abb. 1). Zudem fassen wir unsere Erfahrungen zusammen, die wir bei der Einführung und Verbreitung der Softwarelösung gewonnen haben (Diffusion).

Abb. 1
figure 1

Das Zusammenspiel von Ideenfindung, Invention und Diffusion

Full size image

Der Problemkontext: Projektgeschäft bei einem Softwareunternehmen

Die iteratec GmbH entwickelt individuelle Softwarelösungen, zukunftssichere Infrastrukturen und innovative Geschäftsmodelle für ihre Kunden. Wie viele unserer Wettbewerber setzen auch wir auf agile Vorgehensmodelle in unseren Entwicklungsprojekten, um diesen Kundenwünschen nachkommen zu können. Ein wesentlicher Bestandteil unserer Herangehensweise sind weitestgehend autonome Teams, die selbstorganisiert Kundenprojekte umsetzen. Dabei hat eine Fragestellung nicht erst seit der Pandemie immer mehr an Bedeutung gewonnen: Wie können unsere verteilten Entwicklungsteams möglichst reibungslos zusammenarbeiten?

Anhand folgender Symptome haben wir gemerkt, dass es einen Verbesserungsbedarf gibt:

  • Fragestellungen tauchen in verschiedenen Projekten unabhängig voneinander auf, werden individuell gelöst, ohne dass die Beteiligten voneinander wissen. Es entstehen Wissenssilos.

  • Es gibt verschiedenste Kommunikationskanäle (E-Mail, Wiki, Forum, Chat usw.) und gewachsene Ablagestrukturen, die ein Ablegen und Auffinden von Informationen erschweren. MitarbeiterInnen nutzen verschiedene Tools für ähnliche Anwendungsfälle und verschiedene Ablageorte für ähnliche Informationen, weil es keine eindeutige, offensichtliche Wahl gibt.

  • Informationen erreichen nicht alle Adressaten, weil diese mit Informationen geflutet werden oder auf anderen Kanälen und zu anderen Zeitpunkten aufmerksam sind.

Wir haben uns mit der Frage nach reibungsloser Zusammenarbeit mit der Entwicklung von Lösungsansätzen anfangs schwergetan. Der Problemraum erschien uns insgesamt komplex. Es gibt keine offensichtliche einfache Lösung. Komplizierte Ansätze, wie beispielsweise ein Regelwerk für die Ablage von Informationen, sind in der Praxis gescheitert.

Die eben beschriebene Problemstellung bedarf einer sehr fokussierten Bearbeitung, welche sich kaum mit unserem hektischen Tagesgeschäft vereinbaren lässt. Aus diesem Grund haben wir uns für mehrere Kooperationen in Form von Projekten und Masterarbeiten mit Studierenden des IT-Management und Consulting-Studiengangs der Universität Hamburg entschieden. Erfreulicherweise konnten wir so mehrere motivierte Studierende gewinnen, die sich als Projektteam auf die Entwicklung von Lösungsansätzen für unsere Fragestellungen konzentrierten.

Aufgrund der Komplexität des Problemraums und dadurch, dass die Lösung das menschliche Verhalten für den nachhaltigen Erfolg berücksichtigen muss, war für uns der Einsatz einer Design-Thinking-Methode naheliegend.

Wir wählten den Google Design Sprint nach Knapp et al. (vgl. [2]). Die Methodik greift wesentliche Design-Thinking-Elemente auf, wie z. B. expliziten Raum zum Problemverständnis, Brainstorming, Prototyping und abschließendes Testen. Sie ergänzt den klassischen Design-Thinking-Prozess um sehr genau beschriebene Regeln, Instruktionen und einen Zeitplan. So können auch Personen ohne bzw. mit nur grundlegenden Design-Thinking-Vorkenntnissen die Methode anwenden. Die kurze Dauer von 5 Tagen pro Sprint vertrug sich ebenfalls gut mit den organisatorischen Rahmenbedingungen der beteiligten Studierenden.

Fallbeispiel: Kommunikation der Nutzungsszenarien für Tools (Google Design Sprint)

Der Google Design Sprint ermöglicht die Entwicklung und den Test neuer Ideen innerhalb von 5 Arbeitstagen. Abb. 2 gibt einen Überblick über die aus unserer Sicht wesentlichen Elemente des Design Sprints.

Abb. 2
figure 2

Überblick über den Google Design Sprint

Full size image

Die Beteiligten am Google Design Sprint agieren in festen Rollen: Entscheider, Moderator und Teilnehmer.

  • Sofern das Team für das weitere Vorankommen eine Entscheidung benötigt, wird diese vom Entscheider getroffen. Der Entscheider muss das Problem in der Tiefe kennen und sollte über eine klare Haltung verfügen.

  • Der Moderator verantwortet die Durchführung des Design Sprints. Er ist verantwortlich für das Zeitmanagement und den strukturierten Ablauf.

  • Die Teilnehmer bringen Fachexpertise und Unternehmenskenntnisse in das Team ein und führen die eigentliche Ideen- und Prototypenentwicklung durch.

Diese Rollen bilden das Sprint Team. In unserem Fall bestand das Team aus 3 Studierenden, einem Geschäftsführer und 2 BetreuerInnen (uns). Der Geschäftsführer hat die Rolle des Entscheiders übernommen und hat zeitweise am Design Sprint teilgenommen. Im Folgenden beschreiben wir den Ablauf des Google Design Sprints anhand unseres Vorgehens.

Am Montag ging es ausschließlich darum, den Problemraum der reibungslosen Zusammenarbeit genau zu verstehen. Am Ende des Tages wählten wir gemeinsam ein entscheidendes Teilproblem zur weiteren Bearbeitung aus. Wir führten eine ganze Reihe an Interviews mit iteratec-Mitarbeitern als Experten durch. Die Interviews halfen uns dabei, die abstrakte Fragestellung in ein übergeordnetes Ziel zu überführen. Dabei war es sehr hilfreich, Herausforderungen in Form von sogenannten Wie-können-wir(WKW)-Fragen zu formulieren. Wichtig war es hierfür, die Verfügbarkeit der Experten im Vorwege sicherzustellen.

Die Studierenden priorisierten anschließend gemeinsam mit uns die WKW-Fragen (vgl. Abb. 3) auf Basis der Beobachtungen aus den Interviews und wählten das Cluster „Tool-Kommunikation“ mit der folgenden Fragestellung als Teilproblem aus:

Abb. 3
figure 3

Teilprobleme im Kontext reibungsloser Zusammenarbeit von Entwicklungsteams

Full size image

Wie können wir vermitteln, wo und wie wir welches Tool nutzen?

Ein entscheidender Faktor bei der Wahl der Fragestellung war, inwiefern schnelle und vorzeigbare Ergebnisse innerhalb der Projektlaufzeit möglich sind. Bei iteratec gab es schon eine Lösung, die diese Frage adressierte, die jedoch nach unserer Einschätzung den gewachsenen Anforderungen der NutzerInnen nicht mehr gerecht wird.

Was genau ist das (Teil‑)Problem?

Viele Jahre hinweg haben wir einen Teil der Kommunikation zu unserer Toollandschaft über eine zentrale, von unserem Infrastrukturteam verwaltete Linksammlung abgebildet. Diese Linksammlung beinhaltete die Adressen für den Zugriff auf Tools (z. B. Web-Mail, HR-System, Telefonkonferenzanlage, Versionskontrolle etc.), aber keine weitergehenden Metadaten, wie beispielsweise Ansprechpartner für Rückfragen. Viele Tools waren zudem gar nicht in der Linksammlung enthalten, da Anpassungen sehr aufwendig waren und nur zentrale Anwendungen unterstützt wurden. Somit war vielen KollegInnen nicht transparent, welche Tools insgesamt in der Firma existieren.

Zurück zum Design Sprint: Am Dienstag skizzierte das Team mögliche Lösungen (siehe Abb. 4). Diese basierten auf den Erkenntnissen der Experteninterviews, aber auch auf einer kurzen Marktrecherche. Für die Ideengenerierung kamen verschiedene Kreativmethoden zum Einsatz.

Abb. 4
figure 4

Lösungsskizzen zur Oberfläche und zum Workflow mit Klebepunkten

Full size image

Am Mittwoch beschrieb jeder Teilnehmer eine konsolidierte Lösung auf einem Blatt Papier. Alle Lösungen wurden an eine große Wand gehängt und ohne weitere mündliche Erläuterungen begutachtet. Dies war eine realistische Bewährungsprobe für die Ideen, denn später haben EntwicklerInnen auch keine Gelegenheit, den NutzerInnen ihrer Lösung ein Konzept zu erklären. Anschließend markierten die Teammitglieder mit einem Stift (rote Punkte) Aspekte der Lösungsideen, die ihnen besonders gut gefielen. In unserem Design Sprint durfte auch der Moderator Klebepunkte vergeben. Der Entscheider erhielt die doppelte Anzahl an Klebepunkten wie die übrigen Teilnehmer. Schließlich wird aus den favorisierten Ansätzen eine gemeinsame Idee erarbeitet.

Am Donnerstag entwickelte das Sprint-Team auf Basis der gemeinsamen Idee einen testbaren Prototyp mittels PowerPoint (Abb. 5). Am Freitag stellte das Sprint-Team den Prototyp mehreren Testpersonen vor und sammelt dabei Feedback von potenziellen NutzerInnen. Am Ende des Sprints konnten wir die Entscheidung treffen, ob es sich lohnt, den verprobten Lösungsansatz im größeren Projektrahmen weiterzuverfolgen.

Abb. 5
figure 5

Klick-Prototyp für unser Portal iteraweb

Full size image

Aufgrund des positiven Feedbacks der Testpersonen haben wir uns dazu entschlossen, den iteraweb-Prototypen als Minimal Viable Product (MVP) zu realisieren (siehe Abb. 6). In unserem Fallbeispiel haben die Studierenden den Prototyp anschließend in rund 10 Wochen als MVP im Rahmen eines agilen Softwareprojekts implementiert.

Abb. 6
figure 6

Dashboard-Ansicht unseres MVP

Full size image

Was haben wir am Design Sprint angepasst?

Wir haben folgende Anpassungen am von Knapp beschriebenen Google Design Sprint vorgenommen, die für uns gut funktioniert haben:

  1. 1.

    Aufgrund der zeitlichen Verfügbarkeit der Studierenden haben wir den Design Sprint ohne negative Auswirkungen auf die Tage von 2 Wochen verteilt.

  2. 2.

    Wir haben noch einen „Samstag“ vorgesehen, an dem wir das Feedback der Testpersonen in den Prototypen integriert haben.

Was haben wir gelernt?

Bei der Durchführung des Design Sprints haben wir mehrere Erkenntnisse gewonnen, die wir an dieser Stelle kurz zusammengefasst teilen möchten:

  1. 1.

    Das Problemverständnis ist wichtig, aber nicht zu wichtig. Uns ist insbesondere die Problemanalyse am Montag aufgrund der recht abstrakten Problemstellung schwergefallen. Der Google Design Sprint hat sich für uns stellenweise nicht zielführend angefühlt. Es hat sich bewährt in einem solchen Fall nicht ins Zweifeln zu geraten, sondern einfach mit dem nächsten Schritt der Methode weiterzumachen.

  2. 2.

    Die Formulierung von Problemen als WKW-Fragen hat die Entstehung vieler Ideen angeregt.

  3. 3.

    Es lohnt sich, Teile des Prototyps schon einmal vorab am Donnerstag mit 1 oder 2 Testpersonen auszuprobieren. Damit muss man nicht bis zum Freitag warten.

Nach Abschluss des Design Sprints gab es im Team die Befürchtung, dass die Ergebnisse des Projekts, wie häufig bei anderen Studierendenprojekten auch, in einer Schublade verschwinden. Uns wurde dadurch bewusst, dass es von der Entwicklung des MVP bis zum Live-Gang in der eigenen Organisation noch eine weite Wegstrecke zu gehen gibt. Es braucht hierfür ein Mandat und Personen, die den Live-Gang treiben. Der Google Design Sprint unterstützt hierbei nicht. Nach Abschluss des Studierendenprojekts haben wir daher als Betreuer und in der Rolle des Product Owners das MVP bis zur Produktionsreife und darüber hinaus begleitet. Dabei haben wir folgende Taktiken angewandt, die wir an dieser Stelle den LeserInnen zur Inspiration mitgeben möchten:

Wir suchen Product Owner für Prototypen

Wir haben es mehrfach erlebt: Selbst, wenn ein Softwareprototyp bereits nutzbare Funktionen enthält und die Entwicklung abgeschlossen scheint, steht bis zur Inbetriebnahme noch eine Menge (Überzeugungs‑)Arbeit an. Das System muss in Betrieb genommen und beobachtet werden. Wir brauchen oft eine Einschätzung bzgl. Datenschutz und -sicherheit. Bestehende Lösungen sollen zudem zurückgebaut oder abgeschaltet werden. Die Designsprache der Organisation muss sich im Prototyp wiederfinden. Und die neue Lösung muss in der Organisation bekannt gemacht, erklärt und vielleicht sogar verteidigt werden. Diese Arbeit braucht Kontinuität und kann nach unserer Erfahrung nicht in einem Projekt mit definiertem Anfangs- und Endzeitpunkt bearbeitet werden. Wir betrachten unsere Prototypen als Produkte und suchen jemanden als Product Owner, die oder der für den Prototypen brennt.

Wir holen uns Rat und Feedback

Wir haben sehr gute Erfahrungen mit der Beteiligung in Form von Beratung durch Experten aus unserer Organisation gesammelt. Die frühe Einbeziehung der Experten hilft uns, Risiken in Form von „bösen Überraschung“ zu vermeiden und unsere Aktivitäten „absichern“ zu lassen. Da die Anzahl der Experten üblicherweise überschaubar ist, erzielen wir mit diesem Ansatz wenig Breitenbeteiligung. Um eine breitere Beteiligung der KollegInnen zu erzielen, haben wir nicht nur im Rahmen des Design Sprints, sondern auch in der Folgezeit immer wieder gezielt zu unserem Prototyp befragt und so z. B. Default-Einstellungen festgelegt. Auf diese Weise kann das Feedback vieler in unsere Prototypen einfließen und ihre Akzeptanz weiter erhöhen.

Wir erfinden das Rad nicht komplett neu

Eine Beteiligung könnte auch in Form einer einvernehmlichen Wiederverwendung von Arbeitsergebnissen geschehen, z. B. von einem Produktnamen oder auch von Quelltext. Wir haben beobachtet, dass die Berücksichtigung von bereits erreichten Ergebnissen zu einer höheren Akzeptanz der Lösung führt.

Wir danken allen Beteiligten

Wir haben sehr gute Erfahrungen damit gemacht, unsere Entwicklung auf einem offiziellen Kanal unserer Organisation anzukündigen und dabei den Beteiligten explizit zu danken. Das verhilft unserer Lösung zu einer hohen Sichtbarkeit und die erwähnten Personen haben sich über die Wertschätzung gefreut und weiterhin ihre Unterstützung angeboten.

Der Google Design Sprint hat uns letzten Endes dabei geholfen, innerhalb von wenigen Monaten ein neues Übersichtsportal namens „iteraweb“ zu unserer Dienstlandschaft auf den Weg zu bringen.

Fallbeispiel: Kommunikation von Änderungen der Toollandschaft

Nachdem wir unser Fallbeispiel zum Google Design Sprint beschrieben haben, möchten wir im folgenden Abschnitt unsere Erfahrungen mit der Design-Science-Research-Methode nach Sonnenberg und vom Brocke teilen. Die junge wissenschaftliche Disziplin Design Science liefert eine Reihe von Vorgehensmodellen, um Artefakte (das heißt Konstrukte, Modelle, Methoden und Umsetzungen) zu erstellen und zu bewerten, die innovativ und wertschöpfend sind (vgl. [3, S. 253]). Auch diese Fallstudie ist im Kontext von iteraweb entstanden.

Was genau ist das Problem?

Nachdem eine zentrale und einheitliche Übersicht auf die verfügbaren unternehmensinternen Tools geschaffen war, wurde schnell klar, dass dies nicht genügt: Wurden in der alten Linksammlung 30 Tools verlinkt, stieg die Zahl der erfassten Tools nach der Einführung von iteraweb innerhalb eines Jahres auf ca. 80 Einträge an. Jedes dieser Tools erfordert einen gewissen Kommunikationsaufwand durch die dafür verantwortlichen Mitarbeiter. Beispielsweise müssen Nachrichten an Kollegen verschickt werden, wenn die Verfügbarkeit eines Tools wegen Wartungsarbeiten nicht gewährleistet werden kann. Die hohe Anzahl der Nachrichten und die verschiedenen Kommunikationswege (per E‑Mail sowie Forumsbeiträge oder Chat-Nachrichten) führt bei den Mitarbeitern zur Abschottung oder gar zur psychischen Überlastung [4]. Aus diesen Problemen heraus sahen wir uns deshalb mit folgender Fragestellung konfrontiert: Wie können wir dafür sorgen, dass unseren KollegInnen nur die Teilmenge der Tools und Nachrichten angezeigt werden, die für ihre Tätigkeit wirklich relevant sind?

Wie sind wir vorgegangen?

Um die Antwort auf die Fragestellung zu finden, wendeten wir das Design Science Research (DSR) Evaluation Pattern von Sonnenberg und vom Brocke [5] an. Der Vorteil der DSR-Methoden ist, dass diese praktische Ziele (Anwendbarkeit, Nützlichkeit, Relevanz) und wissenschaftliche Ziele (Validität) ausbalancieren [5]. Im Gegensatz dazu ist die Methode des Google Design Sprints eine rein praktische und auch im Sinne der DS-Forschung keine Methode mit wissenschaftlicher Stringenz [6]. Das Evaluation Pattern von Sonnenberg und vom Brocke berücksichtigt, dass Artefakte sich sowohl durch die Interaktion mit dem organisatorischen Kontext als auch durch Designintervention entwickeln und durch Reflexions- und Lernaktivitäten entstehen [5]. Prominientere Ansätze wie der DSR-Prozess von Peffers et al. [7] verfolgen dagegen einen Prozess mit strikt aufeinanderfolgenden Aktivitäten und sehen Evaluierungsaktivitäten nach Erstellung des Artefakts vor. Zusammengefasst ist die stärkere Fokussierung auf Evaluierungsaktivitäten und die Berücksichtigung der sich entwickelnden Natur von DSR-Artefakten der Grund, weshalb wir uns in diesem Fall für den Ansatz von Sonnenberg und vom Brocke entschieden haben.

Wie funktioniert das DSR Evaluation Pattern?

Abb. 7 zeigt den Ablauf des DSR-Prozesses von Sonnenberg und vom Brocke. Dieser beinhaltet 4 Aktivitäten zur Problemidentifikation (Identify Problem), zu Design und Konstruktion (Construct) und zur Nutzung (Use) sowie 4 Evaluierungsaktivitäten. Die Evaluierungsaktivitäten EVAL 1 und EVAL 2 finden vor der Konstruktion eines Artefakts statt (ex ante), die Evaluierungsaktivitäten EVAL 3 und EVAL 4 danach (ex post). Nach jeder DSR-Aktivität folgt eine Evaluierungsaktivität. Allerdings ist über Rückkopplungs- bzw. Feedbackschleifen auch ein entgegengesetzter Ablauf möglich. Beispielsweise könnte die Evaluierungsaktivität EVAL 2 ergeben, dass das Design des Artefakts angepasst werden und noch einmal evaluiert werden muss, bevor zur Aktivität Construct übergegangen werden kann. Je nach Kontext kann bei der Durchführung einer Evaluationsaktivität eine Evaluationsmethode oder zusammengesetzte Evaluationsmethoden, sogenannte Evaluationsmuster (z. B. Action Design Research [8]) genutzt werden. Die Aktivitäten des DSR Evaluation Pattern decken alle Aspekte der Definition des Innovationsbegriffs von Müller-Prothmann und Dörr ab: Die Aktivitäten Problemidentifikation und Design behandeln den Ideenfindungsprozess, die Aktivitäten Design und Konstruktion den Prozess der Invention und die Aktivität Use die Diffusion.

Abb. 7
figure 7

DSR-Prozess von Sonnenberg und vom Brocke [5]

Full size image

Sonnenberg und vom Brocke [5] schlagen je nach Aktivität unterschiedliche Evaluationsmethoden vor. Beispielsweise eignen sich für EVAL 1 alle Methoden, die das Engagement in einem DSR-Projekt rechtfertigen (z. B. Formulierung von Hypothesen oder eine Literaturrecherche). Für EVAL 4 hingegen Methoden, welche die Anwendbarkeit, Effektivität oder Effizienz des Artefakts beweisen (z. B. das Fallbeispiel oder den Feldversuch).

Die Aktivität EVAL 1 soll sicherstellen, dass ein sinnvolles DSR-Problem ausgewählt und formuliert wird, das für die Praxis wichtig und neuartig ist oder aus der Unfähigkeit vorhandener Artefakte resultiert. Bei dieser Aktivität nutzen wir die Evaluationsmethode „Literaturrecherche“. Wir konnten über Online-Recherchedatenbanken Forschungsarbeiten finden, die versuchen, ähnliche Probleme mit Empfehlungssystemen zu lösen. Allerdings fanden wir keine Lösungen zur Problematik, wie Empfehlungen für Nutzer langfristig interessant bleiben, wenn MitarbeiterInnen aufgrund von Zugriffsbeschränkungen nur eine kleine Auswahl (< 100) an Tools empfohlen werden kann. Somit konnten wir darlegen, dass unser Engagement aus der Unfähigkeit bereits vorhandener Artefakte resultiert.

Für die Aktivität „Design“ haben wir verschiedene Gestaltungsmöglichkeiten eines Empfehlungssystems ausgewählt, mehrere UI-Mockups entworfen (siehe Abb. 8) und ihre Tauglichkeit und Eignung diskutiert. Zusätzlich haben wir bereits bestehende Ansätze von kollaborativen, inhaltsbasierten und wissensbasierten Ansätzen verglichen. Die UI-Mockups halfen uns, Designentscheidungen über einen benutzerzentrierten Ansatz zu treffen und uns für eine der Varianten zu entscheiden.

Abb. 8
figure 8

Exemplarisches UI-Mockup für ein kollaboratives Empfehlungssystem. Der Nutzer bewertet Kacheln als relevant oder irrelevant (roter Rahmen) und bekommt entsprechend seiner Interessen Dienstempfehlungen angezeigt (graue Leiste)

Full size image

Ergebnis der Aktivität „Design“ war, dass ein wissensbasiertes Empfehlungssystem die geeignetste Lösung für das DSR-Problem ist. Andere Varianten wie jene in Abb. 8 schlossen wir aus, weil wir es für unwahrscheinlich hielten, dass Nutzer ein kontinuierliches Interesse an Empfehlungen zeigen, würden diese immer wieder mit dem gleichen Wortlaut angezeigt. Bei der gewählten Variante erhalten Benutzer Empfehlungen zu Tools in Form von toolspezifischen Nachrichten (siehe Abb. 9). Die Nachrichten sollen Angestellten relevante Tools empfehlen und dabei gleichzeitig die Informationsflut reduzieren.

Abb. 9
figure 9

UI-Mockup der ausgewählten Lösung (wissensbasiertes Empfehlungssystem)

Full size image

Die Nachrichten werden von Toolverantwortlichen kuratiert und können zum Beispiel zu einem bestimmten Datum an Mitarbeiter versendet werden. Toolverantwortliche müssen zu jeder Nachricht eine Interessensgruppe angeben. Damit ist sichergestellt, dass Mitarbeiter nur Empfehlungen bzw. Nachrichten erhalten, die sie interessieren könnten. Sie bestimmen beispielsweise, ob die Empfehlung nur an Mitarbeiter gehen soll, die Softwareentwickler sind und erst neu im Unternehmen anfangen (siehe Abb. 10).

Abb. 10
figure 10

Erzeugung von Nachrichten und Auswahl der Zielgruppe(n)

Full size image

Die Aktivität EVAL 2 soll sicherstellen, dass der Entwurf eines Artefakts die Lösung des Problems beinhaltet. Bei dieser Aktivität nutzen wir die Evaluationsmethode „Befragung von Experten“. In einem strukturierten Experteninterview haben wir 10 Personen befragt, die insgesamt für 20 Tools zuständig waren. Mit der Befragung wollten wir feststellen, ob Toolverantwortliche überhaupt Kommunikationsbedarfe haben, denen das ausgewählte Empfehlungssystem gerecht werden kann. Bei der Auswertung der Interviews konnten wir zeigen, dass sich unser Ansatz als Lösung eignet, da jeder Proband Beispiele für Kommunikationsbedarfe hatte, die unser Entwurf lösen sollte.

Für die Aktivität Construct haben wir das Design des Softwareartefakts mithilfe der Ergebnisse der Evaluationsaktivität EVAL 2 angepasst und mit der Entwicklung des Prototyps begonnen. Das Experteninterview war auch eine große Hilfe, um den Charakter der Nachrichten zu bestimmen, die Toolverantwortliche über das Empfehlungssystem versenden würden. So konnten wir beispielsweise herausfinden, welche Zielgruppen für Toolverantwortliche relevant waren und dass sie Nachrichten am ehesten dazu verwenden, um den Zustand der betreuten Tools (Tool aktiv; Tool in Wartung) mitzuteilen. Außerdem hatten sie Interesse, die Nutzung eines Tools zu bewerben, welches ganz dem Ziel unserer DSR-Initiative entsprach.

Die Aktivität EVAL 3 soll zeigen, wie gut das Artefakt im Zusammenspiel mit Organisationselementen funktioniert. Bei dieser Aktivität nutzen wir die Evaluationsmethoden „Experiment mit dem Prototyp“ und „Umfrage“. Im ersten Schritt sollten Probanden den Prototyp kennenlernen und mit diesem experimentieren, um in einem zweiten Schritt einen Fragebogen auszufüllen. Den ersten Schritt verbanden wir mit einem Usability-Test bei dem die Probanden mithilfe der Think-Aloud-Methode Usability-Probleme aufdecken sollten. Die Ergebnisse konnten wir nutzen, um den Prototyp vor der nächsten Aktivität noch einmal zu verbessern. Die Auswertung unseres Fragebogens ergab, dass die Akzeptanz des Unternehmensportals und die Zufriedenheit der Nutzer mit dem Portal signifikant hoch sind und es keine signifikante Veränderung hinsichtlich der Ablenkung durch Nachrichten bei den Benutzern gab. Lediglich bei der Erfüllung der Kommunikationsbedarfe für Toolverantwortliche konnten wir keine signifikante Veränderung durch die Implementierung des neuen Softwareartefakts feststellen. Ein Grund dafür könnte eine zu geringe Stichprobengröße gewesen sein.

Die Aktivität EVAL4 soll zeigen, dass ein Artefakt in der Praxis sowohl anwendbar als auch nützlich ist. Da die Umsetzung des Prototyps zum Zeitpunkt der Entstehung dieser Arbeit noch nicht abgeschlossen war, konnten wir diese Aktivität noch nicht umsetzen. Eine längerfristige Fallstudie ist bereits in Planung.

Was haben wir gelernt?

Bei der Anwendung der DSR-Methode haben wir mehrere Erkenntnisse gewonnen, die wir an dieser Stelle ebenfalls kurz zusammengefasst teilen möchten:

  1. 1.

    Die frühe Verfügbarkeit von Erkenntnissen ermöglichte es uns, ungeeignete Gestaltungsmöglichkeiten frühzeitig zu verwerfen. Der sich schnell abwechselnde Zyklus zwischen Aktivität und Evaluation gab uns die Sicherheit, jederzeit das Richtige zu tun.

  2. 2.

    Das DSR Evaluation Pattern brauchte gegenüber anderen Methoden Zeit und Geduld. Es eignet sich deshalb nur bedingt für rein praktische Initiativen. Die Evaluierungsaktivitäten waren sehr aufwendig und beanspruchten mehr Zeit als die eigentliche Entwicklung. Es war auch nicht sinnvoll, eine neue Aktivität zu beginnen, ohne auf die Evaluationsergebnisse der vorherigen Aktivität zu warten. Hier sollten die Interessen der Stakeholder verstanden werden, bevor man sich für diese Methode entscheidet.

Vergleich der Ansätze Google Design Sprint und Design Science

Die Paradigmen Design Thinking und Design Science Research haben viele Gemeinsamkeiten was die Menschenzentriertheit, die Trial-and-Error-Suchprozesse und die Greifbarkeit von Designartefakten angeht [6]. Als Entscheidungshilfe für die Auswahl stellen wir im Folgenden die Unterschiede heraus.

Geschwindigkeit vs. Genauigkeit

Das Design Science Research Pattern legt den Schwerpunkt auf die Evaluation für die Überprüfung von Entscheidungen und ist damit eher langwierig und zeitaufwendig. Der Google Design Sprint arbeitet mit kurzen Zeitrahmen, sodass die experimentelle Erprobung mehrerer Ansätze möglich ist.

Sicherheit vs. Freiheit

Der Google Design Sprint definiert genaue Zielvorgaben für jeden einzelnen Arbeitstag und gibt damit eine große Sicherheit beim methodischen Vorgehen. Das Design Science Research Pattern hingegen ist generisch gehalten. Das genaue Vorgehen innerhalb der Aktivitäten ist relativ frei, solange auch die DSR-Guidelines von Hevner und March berücksichtigt werden [9]. Trotzdem gaben uns die wiederkehrenden Evaluationsaktivitäten eine große Sicherheit, eine Webanwendung zu entwickeln, die unseren Zielen entspricht und von unserer Zielgruppe akzeptiert und genutzt wird.

Pragmatisches vs. wissenschaftliches Vorgehen

Der Google Design Sprint löst als Design-Thinking-Ansatz eher ein spezifisches Problem als eine generische Klasse von Problemen [6]. Dem Ansatz fehlt die Bewertung in Bezug auf die Anwendbarkeit und Verallgemeinerbarkeit des entworfenen Artefakts und die wissenschaftliche Strenge bei der Evaluation [6].

Beide Innovationsmethoden haben uns bei der Entwicklung von Lösungen für 2 Problemstellungen aus der täglichen Praxis geholfen. Der Google Design Sprint bietet sich an für sehr unscharfe Probleme, da er mit wenig Aufwand den Problemraum strukturieren hilft und einen Lösungsweg aufzeigt. Die Einbeziehung von Stakeholdern in der Entscheiderrolle zahlt auf Transparenz und Akzeptanz in der Zielorganisation ein. Das DSR Evaluation Pattern hatte in unserem Beispiel seine Stärke darin, für eine Lösung mit einem gewissen Reifegrad Evidenz und Sicherheit für unbeteiligte Stakeholder bei potenziell teuren Entwurfsentscheidungen zu liefern. Keiner der beiden Ansätze fokussiert auf die Einführung in die Zielorganisationen, was jedoch essenziell für den Erfolg einer Innovation ist. Dafür sind weitere Praktiken erforderlich.

Fazit: Erfolgsfaktoren für unternehmensinterne Innovationen

Wir konnten mithilfe des Google Design Sprints und des DSR Evaluation Patterns Verbesserungen in der Zusammenarbeit unserer verteilten Entwicklungsteams erreichen. Beide Innovationsmethoden haben uns bei der Entwicklung von hochwertigen Ideen geholfen. Sie unterscheiden sich in ihrer Durchführungsdauer und erzeugten Evidenz. Wir empfehlen, bei der Auswahl der Innovationsmethode die Informationsbedürfnisse der Zielorganisation mit zu berücksichtigen. Für den Erfolg unserer Lösungen kam es aber auch auf weitere Aspekte an: Studierende haben methodisches Wissen und einen frischen Blick von außen in die Organisation gebracht. Viele Feedbackzyklen und ein agiles Vorgehen haben uns dabei geholfen, die richtige Lösung zu entwickeln, wobei die Methoden einen guten Rahmen dafür geschaffen haben. Es brauchte aber zusätzlich jemanden, der als Navigator Kontakte in die Organisation vermitteln kann, täglich Impulse gibt und anschließend die Idee mit viel Geduld und Kontinuität „auf die Straße“ bringt. Wir haben beobachtet, dass wir die Akzeptanz durch verschiedene Formen der Beteiligung positiv fördern konnten. So haben wir das Intranetportal „iteraweb“ entwickelt und mehr Transparenz über unsere Toollandschaft geschaffen.

Für die weitere Verbesserung der Zusammenarbeit unserer Teams sehen wir derzeit 2 große Herausforderungen, die wir angehen wollen: Wir glauben, dass es zum einen Verbesserungspotenzial bei der teamübergreifenden Transparenz über Fähigkeiten, Erfahrungen, Tools und Methoden unserer KollegInnen gibt. Zum anderen wollen wir untersuchen, wie wir diese Fähigkeiten und Erfahrungen für andere Teams noch besser nutzbar machen können. Wir wären zu diesen Themen sehr an einem Erfahrungsaustausch mit unserem Leserkreis interessiert.