MASTERARBEIT POWERAPPS UND POWERAUTOMATE ALS WERKZEUGE ZUR OPTIMIERUNG VON INNERBETRIEBLICHEN PROZESSEN - UNIPUB
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
MMag. Dr. Thomas Hörzer
PowerApps und PowerAutomate als
Werkzeuge zur Optimierung von
innerbetrieblichen Prozessen
Masterarbeit
zur Erlangung des akademischen Grades
Professional MBA in Change-Management
im Rahmen des Universitätslehrganges
Change-Management
Ao.Univ.-Prof. Mag. Dr. Ing. Otto Krickl
UNI for LIFE Weiterbildungs GmbH und
Karl-Franzens-Universität Graz
Graz, September 2020
Für Patricia, der Liebe meines Lebens
Abstract Abstract Die folgende Arbeit untersucht das Optimierungspotenzial der neuesten Microsoft Produkte PowerApps und PowerAutomate für innerbetriebliche Prozesse. Dabei wird erörtert, wie mit ihnen erstellte Smartphone-Applikationen und Workflows dabei helfen können, die Digitalisierung voranzutreiben, indem sie Abläufe einfacher, transparenter, effizienter und schneller machen. Ziel ist es, einen Leitfaden für die Entwicklung und das Design von firmeninternen Smartphone-Applikationen zu erstellen und festzustellen, welche Vorgehensmodelle am besten geeignet sind. Die Vorstellung von Kreativitätstechniken zur Ideengenerierung, ein Exkurs über die Methoden Requirements Engineering und Design Thinking, sowie eine Einführung in der Erstellung von Fragebögen sollen dem theoretischen Fundament Substanz verleihen. Ein Schwerpunkt wird dabei auf den Change-Prozess gelegt, d.h. welche theoretischen Überlegungen sind von der Idee bis hin zur Umsetzung zu treffen, um eine innerbetriebliche Smartphone-Applikation erfolgreich und nachhaltig zu implementieren und dabei einen Mehrwert für die Mitarbeiter zu schaffen. Unter anderem wird untersucht welches Change-Modell für diesen Anwendungsfall praktikabel ist, welche Stakeholder unter allen Umständen in den Prozess miteinbezogen werden müssen und wie der Prozess mit den Mitarbeitern kommuniziert werden soll. Das in der Theorie generierte Modell wird im Praxisteil mithilfe von drei in PowerApps programmierten Smartphone- bzw. Desktop-Applikationen auf seine Praxistauglichkeit getestet. Am Ende der Arbeit wird ein Resümee gezogen und dargestellt, was bei der Umsetzung gelernt wurde und was beim nächsten Anwendungsfall besser gemacht werden kann. Welche Punkte für eine erfolgreiche Implementierung von mit PowerApps erstellten Applikationen zu beachten sind und welche Change- Management-Maßnahmen getroffen werden müssen, wird am Ende in eine allgemeine Handlungsempfehlung gepackt.
Abstract The following paper examines the advantages and disadvantages of the latest Microsoft products PowerApps and PowerAutomate for the optimization of internal processes. To what extent can smartphone applications and workflows created with them help to advance digitalization by making internal processes simpler, more transparent, more efficient and faster. The goal is to create a guideline for the development and design of in-house smartphone applications and to discuss which process models are applicable. A presentation of creativity techniques for idea generation, a digression on the tools Requirements Engineering and Design Thinking, as well as an introduction to the creation of a questionnaire will give substance to the theoretical foundation. A focus will be put on the change process, i.e. which theoretical considerations have to be made from the idea to the implementation in order to successfully and sustainably implement an in-house smartphone application and thereby create added value for the employees. Among other things, it is discussed which change model is practicable for this use case, which stakeholders must be involved in the process under all circumstances and how the process should be communicated to the employees. The model generated in theory will be tested in the practical part by using three smartphone/desktop applications programmed with PowerApps. At the end of the thesis, the red thread is picked up, a summary is drawn, and it is presented what has been learned during the implementation and what can be done better in the next application. At the end, the points that need to be considered for a successful implementation of smartphone applications created with PowerApps and which change management measures need to be taken are summarized in a general recommendation for action.
Inhaltsverzeichnis
Inhaltsverzeichnis
Abstract ................................................................................................................. 3
Inhaltsverzeichnis ................................................................................................ 5
Abbildungsverzeichnis ........................................................................................ 8
Abkürzungsverzeichnis ....................................................................................... 9
1 Prolog............................................................................................................ 10
1.1 Unternehmensvorstellung ...................................................................... 11
1.2 Ausgangssituation ................................................................................. 11
1.3 Ziele ....................................................................................................... 12
1.4 Aufbau ................................................................................................... 12
2 Smartphones – Rolle in MS Power Plattform ............................................ 13
2.1 Allgemein ............................................................................................... 13
2.2 Microsoft PowerApps ............................................................................. 16
2.3 Microsoft PowerAutomate...................................................................... 18
3 Theoretische Herangehensweise ............................................................... 22
3.1 Projektziel .............................................................................................. 22
3.2 Vorgehensmodelle ................................................................................. 23
3.2.1 Agile Modelle .............................................................................. 24
3.2.1.1 Scrum ........................................................................... 25
3.2.1.2 Extreme Programmierung ............................................. 25
3.2.2 Requirements Engineering .......................................................... 27
3.2.3 Design Thinking .......................................................................... 28
3.3 Change Prozess .................................................................................... 31
3.3.1 Warum ist ein Change Prozess notwendig? ............................... 31
3.3.2 Dringlichkeit erzeugen................................................................. 33
3.3.3 Führungskoalition aufbauen ........................................................ 34
3.3.4 Vision und Strategie entwickeln .................................................. 35
3.3.5 Die Vision des Wandels kommunizieren ..................................... 37
3.3.6 Mitarbeiter befähigen .................................................................. 38
3.3.7 Schnelle Erfolge erzielen ............................................................ 39
3.3.8 Erfolge konsolidieren und weitere Veränderungen einleiten ....... 40
v
Inhaltsverzeichnis
3.3.9 Neue Ansätze in Unternehmenskultur verankern ........................ 40
3.4 Kreativitätstechniken ............................................................................. 42
3.4.1 Brainstorming .............................................................................. 42
3.4.2 World Café .................................................................................. 42
3.5 Fragebogen ........................................................................................... 44
3.5.1 Stichprobe ................................................................................... 44
3.5.2 Fragebogen Design..................................................................... 45
4 Praktische Umsetzung................................................................................. 47
4.1 App zur Evaluierung des persönlichen Arbeitsstellenrisikos .................. 47
4.1.1 Anforderungen ............................................................................ 47
4.1.2 Umsetzung .................................................................................. 50
4.1.3 Requirements Engineering .......................................................... 51
4.1.4 Design Thinking .......................................................................... 52
4.1.5 App-Realisierung ........................................................................ 53
4.1.6 Gamification ................................................................................ 55
4.1.7 Change Prozess ......................................................................... 56
4.1.8 Roadmap .................................................................................... 58
4.1.9 Benutzersupport und Product Life Cycle Management ............... 58
4.2 App für die Organisation des Einarbeiterbedarfs ................................... 61
4.2.1 Anforderungen ............................................................................ 61
4.2.2 Umsetzung .................................................................................. 62
4.2.3 Requirements Engineering .......................................................... 63
4.2.4 Design Thinking .......................................................................... 64
4.2.5 App-Realisierung ........................................................................ 64
4.2.6 Change Prozess ......................................................................... 69
4.2.7 Roadmap .................................................................................... 71
4.2.8 Benutzersupport und Product Life Cycle Management ............... 71
4.3 Planungsanforderungs-Tool .................................................................. 72
4.3.1 Anforderungen ............................................................................ 72
4.3.2 Umsetzung .................................................................................. 72
4.3.3 Requirements Engineering .......................................................... 73
4.3.4 Design Thinking .......................................................................... 74
4.3.5 App-Realisierung ........................................................................ 75
vi
Inhaltsverzeichnis
4.3.6 Change Prozess ......................................................................... 80
4.3.7 Roadmap .................................................................................... 81
4.3.8 Benutzersupport und Product Life Cycle Management ............... 81
4.4 Fragebogen ........................................................................................... 82
4.5 Learnings ............................................................................................... 84
5 Fazit und Ausblick ....................................................................................... 85
6 Handlungsempfehlung ................................................................................ 88
7 Literaturverzeichnis ..................................................................................... 90
7.1 Bücher und Zeitschriften ........................................................................ 90
7.2 Internet .................................................................................................. 93
8 Anhang.......................................................................................................... 95
8.1 Fragebogen ........................................................................................... 95
8.2 Roadmap für die App zur Evaluierung des Arbeitsstellenrisikos............ 98
8.3 Roadmap für die App zur Organisation des Einarbeiterbedarfs............. 99
8.4 Roadmap Planungsanforderungs-Tool ................................................ 100
vii
Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 1: PowerApps Startbildschirm .........................................................................16
Abbildung 2: Homepage von PowerApps .........................................................................17
Abbildung 3: Beispiel eines automatisierten Flows...........................................................19
Abbildung 4: Code Beispiel ..............................................................................................20
Abbildung 5: Schematischer Ablauf der Extremen Programmierung ................................26
Abbildung 6: Design Thinking ..........................................................................................30
Abbildung 7: Golden Circle nach Simon Sinek .................................................................36
Abbildung 8: Auszug aus dem Arbeitsbuch „Risikobewertung vor Arbeitsbeginn“ ............48
Abbildung 9: Evaluierung der Arbeitsstelle .......................................................................49
Abbildung 10: Umwandlung in SharePoint lesbares Format.............................................54
Abbildung 11: Menüführung und Auswahl der erforderlichen Schutzausrüstung ..............54
Abbildung 12: Hinweis vor dem Speichern und Ansicht Eigener Risikobewertungen .......55
Abbildung 13: Display Mode ändern ................................................................................59
Abbildung 14: Einarbeitungsliste im Excel-Format ...........................................................61
Abbildung 15: Termin anlegen .........................................................................................65
Abbildung 16: Anmeldung zum Einarbeiten .....................................................................66
Abbildung 17: Eintrag am SharePoint ..............................................................................67
Abbildung 18: Genehmigungsworkflow mit PowerAutomate ............................................68
Abbildung 19: Einarbeitungstermin genehmigt .................................................................69
Abbildung 20: Eingebettete Applikation in MS-Teams ......................................................75
Abbildung 21: Formular Planungsanforderung anlegen ...................................................76
Abbildung 22: Fehlermeldung ..........................................................................................77
Abbildung 23: Überblick über bereits angelegte Planungsanforderungen ........................78
Abbildung 24: Sicherheits- und Umweltrisiko Checkliste ..................................................78
Abbildung 25: PDF-Ausfüllhilfe ........................................................................................79
Abbildung 26: Genehmigung............................................................................................79
viii
Abkürzungsverzeichnis
Abkürzungsverzeichnis
App Application (dt. Anwendung)
CM Change-Management
DT Design Thinking
FG Finishing (engl. für Papierausrüstung)
MS Microsoft
PoC Proof of Concept
RE Requirements Engineering
TB Technischer Bereich
ix
Kapitel 1 - Prolog
1 Prolog
WhatsApp, Facebook, Twitter und Co. sind aus unserem Alltag nicht mehr
wegzudenken. Sucht man nach dem besten Sushi Rezept, dann wird schnell in die
Hosentasche gegriffen und das Smartphone gezückt. Wird dabei festgestellt, dass
noch eine spezielle Zutat aus einem Asia Laden benötigt wird, lässt man sich vom
Smartphone zum Geschäft navigieren. Ist das letztendlich doch zu viel des Aufwands,
wird das Sushi mit der App des Lieferdienstes und anschließend ggf. ein Sushi-
Kochbuch mit demselben Smartphone auf Amazon bestellt. Ein Gerät, in Verbindung
mit verschiedenen Applikationen, war in der Lage alle diese unterschiedlichen
Vorgänge schnell und einfach zu bewerkstelligen.
In so manchen Industriebetrieben hingegen, kann ein Bestellvorgang nur mittels SAP
von einem PC oder Laptop durchgeführt, Planzeichnungen nur in Papierform zur
Anlage mitgenommen, Überstunden nur auf einem Aushang eingetragen, eine
Risikoevaluierungscheckliste nur in einem Handbuch ausgefüllt und Anlagen im
Werksgelände nur auf eigene Faust mittels einer Karte gesucht werden.
Man könnte vermuten, dass die beiden Absätze von Vorgängen aus unterschiedlichen
Jahrzehnten erzählen, doch dem ist nicht so.
Industrie 4.0, was für die „Verschmelzung von Produktionstechnologien mit
Informations- und Kommunikationstechnologien“ 1 steht, ist zwar in aller Munde, aber
etwa ein Viertel der Unternehmen halten noch Distanz zum Thema, teils aus Skepsis
gegenüber dem Hype der „Digitalisierung“ oder teils, weil kein Einsatzpunkt für den
eigenen Betrieb gesehen wird. Kurz gesagt: viele Firmen wissen nicht, wo sie
überhaupt anfangen sollen.2
Ein erster Schritt hin zur Digitalisierung könnten mobile Apps darstellen, die bekannte
innerbetriebliche Prozesse einfacher, transparenter, effizienter und schneller machen.
Diese Arbeit beschäftigt sich damit, welches Optimierungspotenzial die beiden
neuesten Microsoft Produkte PowerApps und PowerAutomate für innerbetriebliche
Prozesse besitzen.
1 Verein Industrie 4.0 Österreich (2018), S.11.
2 Panné (2019), S.216.
Seite 10Kapitel 1 - Prolog
1.1 Unternehmensvorstellung
In Gratkorn, einige Kilometer nördlich von Graz am Ufer der Mur gelegen, wird seit
mehr als 400 Jahren Papier hergestellt. Andreas Leykam erwarb 1793 die schon seit
1517 bestehende Leuzendorfer Papiermühle und erweiterte die Produktionsstätte hin
zur größten Papierfabrik der Habsburgermonarchie.3 Über die Jahrhunderte änderte
sich nicht nur die Technologie, sondern auch mehrmals der Name: aus Leykam-
Josefsthaler (1870) wurde Leykam-Mürztaler (1974) und später KNP Leykam (1993).
Im Jahr 1997 wurde das Werk schließlich in die global operierenden Gesellschaft
Sappi4, mit südafrikanischem Stammsitz, eingegliedert.5
In der Papierfabrik Gratkorn werden von seinen 1240 Mitarbeitern jährlich über
900.000 Tonnen hochwertiges, mehrfach gestrichenes Papier produziert, dass vor
allem für hochwertige Printpublikationen weltweit verwendet wird; von der
Gesamtmenge des produzierten Papiers werden rund 95% exportiert. Neben Papier
stellt die internen Zellstofffabrik 250.000 Tonnen vollständig chlorfrei gebleichten
Zellstoff her.6
1.2 Ausgangssituation
Trotz der omnipräsenten Begrifflichkeiten Digitalisierung und Cloudanwendungen
werden im Werk Gratkorn nach wie vor unzählige Prozesse, unter anderem diejenigen
für die
• Anmeldung für Überstunden7
• Evaluierung des persönlichen Arbeitsstellenrisikos
• Schmierstellen Wartungspläne u.v.a.
auf Papier ausgedruckt, mit der Hand ausgefüllt und später wiederum manuell in die
jeweilige Systemumgebung eingepflegt. Diese, schon etwas antiquiert erscheinenden,
Methoden führen zu einem hohen administrativen Aufwand, Wartezeiten,
3 Graff (1972), S.178.
4 Akronym für South African Pulp and Paper Industries
5 Leykam AG. In: Aeiou Österreich Lexikon. http://www.aeiou.at/aeiou.encyclop.l/l603333.htm
[eingesehen am 5. Juni 2020]
6 https://www.sappi.com/de/gratkorn-mill [eingesehen am 5. Juni 2020]
7 Je nach Bereich gibt es hier Unterschiede.
Seite 11Kapitel 1 - Prolog
Nachbearbeitung und Intransparenz – sozusagen zu Faktoren die im LEAN-
Management unter die sieben Arten der Verschwendung8 subsummiert werden.
1.3 Ziele
Die folgenden Masterarbeit versucht die oben erwähnten Problemstellungen
aufzugreifen und einen Leitfaden für die Entwicklung und das Design von
innerbetrieblichen Smartphone-Apps zu erstellen, welche die zuvor benannten
Prozesse schneller, effektiver und transparenter machen sollen. Ferner wird erörtert
welche Vorgehensmodelle und -methoden zur Umsetzung geeignet sind und wie ein
optimaler Change-Prozess für die Implementierung aussehen kann.
1.4 Aufbau
Nach der Hinführung zum Thema wird in Kapitel 2 kurz auf Smartphone-Applikation im
Allgemeinen und auf PowerApps und PowerAutomate im Besonderen eingegangen.
Kapitel 3 umreißt den theoretische Rahmen, was ein Softwareprojekt ausmacht und
welche Vorgehensweisen sich für die App-Entwicklung eignen und welche nicht. Des
Weiteren werden Methoden und Werkzeuge präsentiert, die bei der Erstellung des
Anforderungsprofils und des App-Designs nützlich sind und welche
Workshopmethoden bei der Ideenfindung helfen können. Ein großer Teil dieses
Kapitels widmet sich dem theoretischen Aufbau des Change-Prozesses, der für eine
erfolgreiche und nachhaltige Implementierung notwendig ist. Ein Abschnitt des
Kapitels präsentiert den Aufbau eines Fragebogens, mit dem z.B. vor der App-
Erstellung die Kunden nach geeigneten Prozessen gefragt werden bzw. nach
erfolgtem Rollout der Applikation eine Evaluierung vorgenommen werden kann.
Im vierten Kapitel wird, das zuvor aus der Fachliteratur destillierte Fachwissen mittels
drei ausgewählten Prozessbeispielen auf seine Praxistauglichkeit untersucht. Zum
Schluss wird eine Zusammenfassung über den Erkenntnisgewinn und eine allgemeine
Handlungsempfehlung gegeben.
8 Waldron (2009), S.63ff.
Seite 12Kapitel 2 - Smartphones – Rolle in MS Power Plattform
2 Smartphones – Rolle in MS Power Plattform
Das Kapitel gibt einen groben Überblick über Smartphone-Programme und welche
theoretischen Vorüberlegungen durchgeführt werden müssen, um interne Prozesse
mobil abarbeiten zu können. Des Weiteren wird die Microsofts Power Plattform mit
ihren Produktgruppen PowerApps und PowerAutomate vorgestellt und wie diese
Unternehmen dabei helfen kann, einfacher mobile Anwendungen zu erstellen und auf
interne Datenbanken zuzugreifen.
2.1 Allgemein
Smartphones und deren Anwendungsprogramme (engl. Applications – kurz Apps9
genannt) sind aus dem modernen Leben nicht mehr weg zu denken und begleiten uns
durch den ganzen Tag.
Noch vor Jahren war an diese Omnipräsenz von Smartphones, Tablets und Apps nicht
vorstellbar. Durch den Ausbau des Mobilfunknetzes und von Wireless-Router-
Netzwerken finden mobile Internet-Applikationen auch zunehmend ihren Weg in den
Unternehmensalltag. Die großen Unterschiede zwischen den Betriebssystemen
(Apples iOS vs. Googles Android), die Anforderungen an die Cyber-Security10 und das
notwendige Knowhow für das Erstellen einer mobilen Anwendung machen den Weg
zur betriebsinternen mobilen App, mit der beispielsweise der Lagerstand abgefragt
wird, nicht gerade einfach.11
Doch die Vorteile liegen auf der Hand, was bisher der serviceorientierten IT-Architektur
nicht gelang, kann durch die mobilen Anwendungen den Firmenalltag revolutionieren.
Speziell angefertigte Apps können arbeitsplatz- und zeitunabhängig für eine
schnellere, einfachere und transparentere Durchführung von Geschäftsprozessen
sorgen.12
9 Kurzform für Application Software. Der Begriff „App“ ist ein Überbegriff für Problemlösungen mittels
einer Software. vgl. Siepermann (2018). Anwendung. In: Gabler Wirtschaftslexikon.
10 Unter Cyber Security wird der Schutz von Computersystemen und Netzwerken vor Diebstahl oder
Beschädigung der Hard- und Software bzw. der Schutz gegen unerlaubtes Lesen und Kopieren
von Daten verstanden. Bendel (2018). Cybersecurity. In: Gabler Wirtschaftslexikon.
11 Aichele (2016), S.17.
12 Aichele (2016), S.14.
Seite 13Kapitel 2 - Smartphones – Rolle in MS Power Plattform
Es gilt dabei Applikationen für Mitarbeiter, Partner und Kunden zu entwickeln um orts-,
zeit- und endgeräteunabhängig auf firmeninterne Daten zuzugreifen und Prozesse
schneller, einfacher und transparenter zu erledigen.13
Hier fangen die Probleme an: Für welches Betriebssystem entscheidet man sich?
Mittlerweile haben sich Apples iOS und Googles Android als mobile Betriebssysteme
gegenüber der Konkurrenz durchgesetzt. Mit dem Stand von August 2019 hält Android
einen Marktanteil von 87% aller verkauften Smartphones und iOS 13%.14 Obwohl von
den ehemaligen Konkurrenzsystemen (Blackberry, Windows Phone, Symbian) nur
mehr die Betriebssysteme Android und iOS übrig geblieben sind, schafft die
Entwicklung von Business Apps dennoch Probleme, denn in der Regel muss für jedes
Betriebssystem eine eigene Management- und Entwicklungsinfrastruktur geschaffen
werden, was zu hohen Kosten und langen Entwicklungszeiten führt.15
Während es beim Betriebssystem Android einigermaßen unkompliziert möglich ist
erste Apps zu erstellen (zum Beispiel mit dem Programm App Inventor16 des MIT17 für
das keine elaborierten Programmierkenntnisse erforderlich sind, und die Apps auch
ohne einen App-Store Zugang auf dem Smartphone installiert werden können), übt die
Firma Apple strenge Kontrolle über den eigenen App Markt aus. Zuerst ist eine
Mitgliedschaft im Apple Developer Programm zwingend nötig, denn nur registrierte
Benutzer können die verpflichtenden App-Zertifikate erstellen. Zusätzlich ist ein
eigenes Entwicklerzertifikat verpflichtend, um die erstellte App digital zu signieren,
dieser Schritt dient zur Sicherstellung, dass die App von einem offiziellen und
registrierten Programmierer entwickelt wurde. Nur mit diesem Zertifikat kann die App
schließlich im App-Store eingereicht werden. Bevor das Programm im App Store zum
Download freigegeben wird, muss es die App Store Review Guidelines18 bestehen.
Alle eingereichten Apps und deren Updates werden einer ausgiebigen Prüfung
13 Verclas (2012), S.9.
14 Share of global smartphone shipments by operating system from 2014 to 2023. URL:
https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-
systems [eingesehen am 3. Juni 2020]
15 Verclas (2012), S.10.
16 https://appinventor.mit.edu/ [eingesehen am 3. Juni 2020]
17 Massachusetts Institute of Technology
18 https://developer.apple.com/app-store/review/guidelines [eingesehen am 3. Juni 2020]
Seite 14Kapitel 2 - Smartphones – Rolle in MS Power Plattform
unterzogen, welche mehrere Tage bis Wochen dauern kann. Verstößt die Applikation
gegen eine oder mehrere dieser Guidelines wird sie abgelehnt19 und muss
nachgebessert werden, bis alle Kritikpunkte entfernt wurden.20
Somit steht das Unternehmen vor der herausfordernden Entscheidung für welches
mobile Betriebssystem man sich entscheidet - die Kenntnis von unterschiedlichen
Programmiersprachen und Entwicklungsumgebungen vorausgesetzt. Fehlt dieses
Wissen im Unternehmen, ist wohl der einzige Ausweg, die Entwicklung einer mobilen
Applikation an ein externes Softwareunternehmen zu vergeben.21
Will man sich nicht für ein einzelnes mobiles Betriebssystem entscheiden, sondern die
mobilen Apps plattformübergreifend benutzen, legen einem Apple und Google Steine
in den Weg. Die beiden Firmen nutzen schon seit geraumer Zeit ihre Marktmacht, um
„hybride Technologien und Frameworks“22 zu verhindern. Auch bezüglich ihrer
Sicherheit stehen plattformübergreifende Applikation im Schussfeld vieler Entwickler,
die ihnen mangelnde Sicherheit und fehlende Quelloffenheit vorwerfen.23
Für mobile Geschäftsanwendungen kommt, nachdem alle obigen Punkte geklärt
worden sind, die Frage nach den Schnittstellen zur IT-Infrastruktur des Unternehmens
auf; denn ohne Anbindung an Datenbanksystemen wie SharePoint, MySQL oder SAP
machen mobile Apps wenig Sinn. Erschwerend kommt dabei die Vielfalt an
firmeninternen Programmschnittstellen und deren Standards hinzu, sowie, dass die
Prozesse an sich nicht für mobile Nutzung ausgelegt wurden.24
19 Zum Beispiel legt Apple eigene Farbenrichtlinien fest.
Siehe https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/
[eingesehen am 3. Juni 2020]
20 Sillmann (2017), S.753-777
21 Aichele 2016, S.26
22 Ein Framework ist kein fertiges Programm, sondern stellt den Rahmen zur Verfügung, innerhalb
dessen die Anwendung vom Programmierer erstellt wird. Vgl Pree (1997).
23 Aichele 2016, S.68
24 Verclas (2012), S.11.
Seite 15Kapitel 2 - Smartphones – Rolle in MS Power Plattform
2.2 Microsoft PowerApps
Diese bekannten Probleme griff Microsoft 2016 auf und entwickelte ein Programm mit
dem Namen PowerApps, welches die Entwicklung von Business-Apps unterstützt und
für die mobilen Betriebssysteme Android und iOS zur Verfügung steht. In einer Art
Meta-App werden anwendungsspezifische Applikationen erstellt, die später für alle,
oder nur bestimmte Benutzer freigegeben werden. Auf Abbildung 1 sind alle
Smartphone-Applikationen, darunter PowerApps zu sehen. Wird PowerApps geöffnet
sieht der Benutzer am Startbildschirm welche Business-Applikationen für ihn zur
Verfügung stehen – in diesem Fall die Apps für die Risikobewertung und für das
Einarbeiten, auf beide wird später detaillierter eingegangen werden.
Abbildung 1: PowerApps Startbildschirm
Mithilfe von PowerApps und wenigen Programmierkenntnissen können einfache
Business-Anwendungen rasch generiert werden. Das Programm kann sich mithilfe von
so genannten „Connectors“ mit unterschiedlichen Office 36525 Datenquellen (wie
SharePoint, Bower BI usw.) und Programmen (wie Excel, OneDrive und Outlook)
verbinden.26 Gegen Aufpreis stellt Microsoft noch weitere Konnektoren für den Zugriff
auf SAP, MySQL-Datenbanken, Adobe Sign usw. zur Verfügung.27
25 Mit Office 365 stellt die Firma Microsoft ihre Office Produkte, wie z.B. Word, Excel, PowerPoint,
SharePoint usw. in der Cloud zur Verfügung, d.h. Daten können ortsunabhängig und von jedem
Endgerät aus mit einer funktionierenden Internetverbindung abgerufen werden. URL:
https://www.microsoft.com/de-at/microsoft-365 [eingesehen am 9. Juli 2020]
26 Clothier (2016), S.3.
27 Liste von allen derzeit Verfügbaren Konnektoren (Stand Juli 2020) einsehbar unter URL:
https://docs.microsoft.com/en-us/connectors/connector-reference/connector-reference-
powerapps-connectors
Seite 16Kapitel 2 - Smartphones – Rolle in MS Power Plattform
Diese Interkonnektivität bietet dem App-Entwickler die Möglichkeit direkt auf
firmeninterne Datenbanken zuzugreifen, diese in App-Form darzustellen und mit ihnen
zu interagieren. Abbildung 2 beinhaltet einen Ausschnitt der PowerApps Startseite, auf
der auf einfache Art und Weise kleinere Applikationen mithilfe von Vorlagen (engl.
Templates) erstellt werden können. Mit allen geläufigen Internet-Browsern wie
Microsoft Edge, Google Chrome oder Safari (Apple) ist es möglich unter
https://make.powerapps.com Applikationen zu erstellen, sofern eine Lizenz für
Microsofts Power Plattform vorliegt.
Abbildung 2: Homepage von PowerApps
Quelle: https://make.powerapps.com
PowerApps und PowerAutomate sind Teil der Microsoft Power Plattform, die zusätzlich
noch Power BI und das Common Data Service (CDS) umfasst. Ziel der Power
Seite 17Kapitel 2 - Smartphones – Rolle in MS Power Plattform
Plattform ist es, durchgängige Prozesse zu schaffen und manuelles Eintippen der
Daten von einem System in ein anderes überflüssig zu machen.28
Zum Zeitpunkt des Verfassens dieser Arbeit (August 2020) kostet das PowerApps
Paket mit nur einer App pro User € 8,40 pro Monat und das Unlimited Paket € 33,70
pro Monat und User.29
2.3 Microsoft PowerAutomate
Microsoft rundet die Entwicklungsumgebung von PowerApps mit PowerAutomate (vor
2020 unter dem Namen Microsoft Flow bekannt) ab. PowerAutomate reagiert auf
Ereignisse, so genannte Trigger, und führt eine vordefinierte Funktion auf anderen
Systemen aus. Somit ist es möglich auch ohne Vorkenntnisse bzw. elaborierter
Programmierausbildung einfache Lösungen zu entwickeln. Im Zusammenspiel mit
SharePoint und PowerApps entfaltet PowerAutomate sein volles Potenzial.30
Zum Beispiel kann ein Datensatz, der mit einer PowerApps Applikation erstellt wurde,
in einer SharePoint-Bibliothek gespeichert werden. Diese Aktion löst einen Workflow
aus, der zur Folge hat, dass eine bestimmte Person eine E-Mail-Benachrichtigung
erhält (siehe Abbildung 3).
28 Herzog, Tobias (2019). Weshalb man sich die Microsoft Power Plattform genauer anschauen sollte.
https://blog.ioz.ch/weshalb-man-sich-die-microsoft-power-platform-genauer-anschauen-sollte/
[eingesehen am 1. Juli 2020]
29 Vgl. https://powerapps.microsoft.com/de-de/pricing [eingesehen am 16. August 2020]
30 o.A. (2017). Microsoft PaaS-Welt. Komponenten in der Cloud schnell entwickeln. In: Computerwoche
S.38.
Seite 18Kapitel 2 - Smartphones – Rolle in MS Power Plattform
Abbildung 3: Beispiel eines automatisierten Flows
Quelle: https://emea.flow.microsoft.com/
Dieser Flow stammt aus einer Vorlage und kann im Anschluss entsprechend der
eigenen Bedürfnisse angepasst werden. Gegebenenfalls ist es möglich, einen
Genehmigungsworkflow hinzuzufügen, in dem, erst nachdem das File (z.B. vom
Vorgesetzten) genehmigt wurde, es für alle auf dem SharePoint ersichtlich ist.
Die Abarbeitung von innerbetrieblichen Prozessen mittels Smartphone Applikationen
geht mit einigen Schwierigkeiten einher. Unzählige Aspekte wie mobiles
Betriebssystem, Cyber-Security, Schnittstellen zu internen IT-Systemen und
Datenbanken müssen im Vorfeld abgeklärt und evaluiert werden. Kein Wunder, dass
viele Unternehmen davor zurückschrecken, da das mit hohen Kosten verbunden ist.
Microsofts Power Plattform, mit ihren Programmen PowerApps und PowerAutomate,
sollen die Lösung bringen, dass interne Prozesse durchgängig mobil bearbeitbar
werden. Manuelles Eintippen der Daten von einem System in ein anderes soll der
Vergangenheit angehören und mithilfe der unterschiedlichsten Office365 und anderer
Konnektoren soll es für Entwickler möglich sein, passende Apps oder Workflows zu
entwickeln.
Seite 19Kapitel 2 - Smartphones – Rolle in MS Power Plattform
Obwohl Microsoft den Fokus mit PowerApps und PowerAutomate auf „non-Developer“
oder „power User“ gerichtet hat,31 bleiben beide Tools ohne weiterführende
Programmierkenntnisse aus Sicht des Autors ohne großen Nutzen.
Es können zwar schnell mithilfe von Vorlagen, einfache Apps oder Flows kreiert
werden: Kommen später weitere Wünsche des Auftraggebers hinzu, stößt man ohne
ausgeprägtere Programmierkenntnisse schnell an die Grenzen der beiden Systeme.
Vgl. dazu in Abbildung 4 den Code für eine verschachtelte Filterfunktion in einer
Datenbank.
Abbildung 4: Code Beispiel
Quelle: FG-Einarbeitungs-App
31 Hernandez, Pedro (2016). Microsoft to release PowerApps. In: eWeek vom 31.10.2016.
Seite 20Kapitel 2 - Smartphones – Rolle in MS Power Plattform
Mithilfe des abgebildeten Codes32 wird abgefragt, welche Schicht ausgewählt wurde,
der Datensatz nicht in der Vergangenheit liegt bzw. ob sich schon ein Mitarbeiter für
diesen Einarbeitungstermin angemeldet hat. Erst wenn sich noch kein Mitarbeiter für
diesen Termin eingetragen hat, sowie der jeweilige Termin in der Zukunft liegt wird ein
Einarbeitungstermin für die ausgewählte Schicht in der Liste angezeigt.
Welche theoretischen Überlegungen vor der Implementierung von mobilen
Applikationen durchgeführt werden müssen, wird im nächsten Kapitel besprochen. Der
Fokus wird dabei auf den Change Prozess gelegt.
32 Eine detaillierte Ablaufbeschreibung dieser App findet sich in Kapitel 0
Seite 21Kapitel 3 - Theoretische Herangehensweise
3 Theoretische Herangehensweise
In diesem Kapitel wird kurz auf Projektmanagement im Allgemeinen eingegangen und
warum sich klassische Vorgehensmethoden für Softwareprojekte wenig bis gar nicht
eignen. Ferner werden Kreativitätstechniken zur Ideengenerierung und die Werkzeuge
Design Thinking und Requirements Engineering vorgestellt. Einen Schwerpunkt
dieses Kapitels bilden theoretische Überlegungen, wie ein Change Prozess bei der
Implementierung von innerbetrieblichen Apps aussehen kann.
3.1 Projektziel
Organisation und Aufgaben bei der Durchführung eines IT-Projektes (worunter die
Entwicklung und Implementierung einer App fällt) unterscheiden sich nicht
grundlegend von anderen Entwicklungsprojekten (wie z.B. der Errichtung von
Gebäuden und Maschinen), trotzdem gibt es einige signifikante Unterschiede zu
berücksichtigen:33
• Software ist ein immaterielles Produkt
• Softwareprodukte unterliegen keinem Verschleiß
• Software kann ohne Qualitätsverlust kopiert werden
• Software ist schwer zu vermessen usw.
Da sich Softwareprojekte oft der Lösung von neuartigen und innovativen Problemen
widmen, entstehen bei der Projektdurchführung oft Schwierigkeiten hinsichtlich
mangelhafter bzw. unklarer Projektzieldefinitionen.34
33 Aichele (2015), S.18.
34 Aichele (2015), S.18.
Seite 22Kapitel 3 - Theoretische Herangehensweise
Nichtsdestotrotz müssen bei klassischen Projekten, als auch bei der
Softwareentwicklung bestimmte Ziele und Nichtziele vor Projektbeginn definiert
werden. Diese Ziele sind nach einer weitverbreitenden Methode, gemäß des SMART-
Prinzips35 zu definieren und sollen folgenden Punkten entsprechen:
• Spezifisch – Projektziele müssen eindeutig und verständlich sein
• Messbar – Projektziele müssen quantifizierbar sein
• Attraktiv – Der Projektaufwand muss sich lohnen
• Realistisch – Projekte müssen machbar bzw. durchführbar sein
• Terminiert – Projektziele müssen in absehbarer Zeit erreichbar sein
Nachdem die Projektziele definiert worden sind, muss, vor allem bei neuartigen und
noch nie vorher durchgeführten Softwareprojekten, ein so genannter Proof of
Concept (PoC) vorgelegt werden. Ein PoC dient dem Nachweis, dass die
Softwareprojektidee auch praktisch umsetzbar ist und erfolgreich sein wird.36
3.2 Vorgehensmodelle
Vor dem Beginn des eigentlichen Software-Entwicklungsprozesses spielt für den
Projekterfolg die Auswahl des Vorgehensmodells eine entscheidende Rolle. Ein
Vorgehensmodell beschreibt einen Entwicklungsplan zur Konzeption, Herstellung und
Wartung von Softwareprojekten und zeichnet sich durch standardisierte Phasen,
Aktivitäten und Werkzeuge aus, die das generelle Vorgehen bei der
Softwareentwicklung beschreiben. Die Auswahl des Vorgehensmodells hängt davon
ab, ob eine vorausschauende Planung vorausgesetzt werden kann, oder sich eine
anpassbare Planung mit agilen Vorgehensweisen besser eignet.37
Softwareprojekte haben grundsätzlich dieselben Eigenschaften wie klassische
Bauvorhaben - auch hier ist folgendes gegeben: 38
• Die Einmaligkeit des Projekts
• Klare Zielvereinbarungen und Risikoeinschätzungen
35 O’Neill (2006), S.13-16.
36 Bishop (2003), S.486.
37 Aichele (2016), S.90.
38 Vgl. Aichele (2015), S.4.
Seite 23Kapitel 3 - Theoretische Herangehensweise
• Komplexität und Umfang
• Zeitliche Befristung
• Begrenzte Ressourcen
• Interdisziplinarität und bereichsübergreifende Zusammenarbeit
Aufgrund einiger Nachteile des klassischen Projektmanagements, wie zum Beispiel,
dass Planungs- und Entwicklungsfehler oft erst spät erkannt werden können, oder,
dass durch den starren Ablauf etwaige Änderungen an den Projektanforderungen teils
nicht mehr möglich bzw. nur schwer umzusetzen und mit hohen Kosten verbunden
sind, erfordern Softwareprojekte anderer Vorgehensmodelle.39
Um den begrenzten Rahmen dieser Masterarbeit nicht zu sprengen, wird hier nicht
näher auf die verschiedensten modernen Vorgehensmodelle eingegangen. Für
einführende Literatur bezüglich moderner Vorgehensmodelle, wie z.B. des „V-
Modells“ oder des „Rational-Unified-Process-Modells“ sei auf die Werke von
Christian Aichele verwiesen, die sich im Literaturverzeichnis befinden.
3.2.1 Agile Modelle
In der Softwareentwicklung wurden agile Vorgehensmodelle aus der LEAN-
Management-Bewegung40, die ihren Ursprung in der japanischen Autoindustrie hat,
übernommen. Mithilfe agiler Ansätze wird versucht die Bearbeitung eines
Softwareprojektes durch die systematische Vermeidung jedweder
Ressourcenverschwendung zu verbessern und somit zu beschleunigen.
Arbeitsschritte, welche keinen direkten Nutzen für den Kunden haben oder nicht zur
Verbesserung des Projektfortschritts beitragen, sollen vermieden werden. Der Fokus
liegt auf den Nutzen für den Kunden und dem Produktmehrwert.41
Im Unterschied zu klassischen Vorgehensweisen, kennzeichnen agile Modelle die
iterative (d.h. schrittweise, wiederholende) Methodik. Dem Kunden wird dabei in relativ
kurzen Abständen ein greifbares Resultat präsentiert (z.B. ein erstes Look-and-feel der
Menüleiste). Mithilfe dieses iterativen Modells können geänderte
39 Aichele (2015), S.33f.
40 Siehe Voigt (2018). Lean Management. In: Gabler Wirtschaftslexikon
41 Highsmith (2009), S.33.
Seite 24Kapitel 3 - Theoretische Herangehensweise
Kundenanforderungen sofort berücksichtigt, oder nicht gewünschte Funktonen
entfernt werden.42
3.2.1.1 Scrum
Eine dieser agilen Methoden ist Scrum. Der Begriff entstammt dem Rugby Sport und
wurde erstmals 1995 formalisiert43 und in einem Regelwerk beschrieben. In der Scrum-
Philosophie wird davon ausgegangen, dass es unmöglich ist Projekte von Anfang bis
Ende en détail durchzuplanen. Deshalb wird vor dem Projektbeginn lediglich ein grober
Rahmen vereinbart, in dem sich das Projektteam bewegen kann und darin selbst
organisierend das Projekt abarbeitet. Die Scrum-Methode besteht aus einem Satz von
Regeln, Rollen, Werkzeugen und Prozessen, die dem „Agilen Manifest“44 entlehnt sind
und kombiniert inkrementelle und iterative Vorgehensweisen.45
Folgende Punkte sprachen gegen den Einsatz dieser Methodik:
a) die COVID-19-Pandemie46 verunmöglichte eine intensive Gruppenarbeit mit
physischer Anwesenheit
b) der hohe administrative Aufwand und die Charakteristik der Aufgabenstellungen
Aufgrund dessen wurde für die Projektumsetzung das agile Vorgehensmodell der
Extremen Programmierung gewählt.
3.2.1.2 Extreme Programmierung
Die Extreme Programmierung (XP) war eines der ersten agilen Modelle und zeichnet
sich durch eine strikte Arbeitsteilung zwischen Kunde und Entwickler aus. Das von
Kent Beck im Jahr 1999 vorgestellte Modell ordnet Planung und Beschreibung der
Anforderungen dem Kunden zu. Die Aufgabe des Entwicklers ist die Umsetzung, der
vom Kunden beschriebenen Anforderungen, zu einem fertigen Softwareprodukt. Um
das Projektziel zu erreichen, wird das Programm sukzessive erweitert und lauffähige
42 Aichele (2016), S.85f.
43 Auf den Erkenntnissen von Ikujirō Nonaka und Hirotaka Takeuch formalisierte Jeff Sutherland und
Ken Schwaber Anfang der 1990er die Scrum-Grundlagen. 1995 wurde das Scrum-Konzept auf
einer Konferenz vorgestellt. Vgl. Sutherland (2020), S.17ff.
44 Näheres zum agilen Manifest findet sich in Beck, Kent; Grenning, James et al. (2001). Principles
behind the Agile Manifesto http://agilemanifesto.org/principles.html [eingesehen am 13. Juni 2020]
45 Aichele (2015), S.38f.
46 Eine im Jahr 2020 weltweit auftretende virale Pandemie des Coronavirus SARS-CoV-2, die eine
schwere, teils auch letale, Erkrankung der Atemwege verursacht.
Bendel (2020). COVID-19. In: Gabler Wirtschaftslexikon
Seite 25Kapitel 3 - Theoretische Herangehensweise
Prototypen entwickelt. Gemeinsam mit dem Kunden wird die aktuelle Version evaluiert
und danach abgenommen, angepasst oder auch verworfen. Ist der Kunde noch nicht
mit dem Softwareprodukt zufrieden, beginnt ein neuer Iterationsprozess.47
Eine schematische Beschreibung dieses iterativen Prozesses wird in Abbildung 5
dargestellt.
Abbildung 5: Schematischer Ablauf der Extremen Programmierung
Quelle: Angelehnt an Aichele (2015), S.38.
Vorteile dieses Vorgehensmodells liegen im sehr niedrigen Verwaltungsaufwand, der
expliziten Berücksichtigung der Kundenwünsche während der Softwareentwicklung
und der ausführlichen Kommunikation mit dem Kunden. Nachteile werden in der
fehlenden Entwurfsplanung und in der allgemeinen Wirtschaftlichkeit dieser Methode
bei kleinen Softwareprojekten gesehen.48
Dem letzten Punkt kann der Autor nicht zustimmen, da sich dieses Modell trotz des
kleinen Projektumfangs als sehr gewinnbringend erwies.
Vor dem Beginn des eigentlichen Software-Entwicklungsprozesses spielt die
Formulierung der konkreten Anforderungen eine zentrale Rolle. Welcher Zweck und
47 Aichele (2015), S.38f.
48 Vgl. https://blog.seibert-media.net/blog/2005/05/01/extreme-programming-vorgehensmodell-zur-
software-entwicklung-bei-seibertmedia/ [eingesehen am 15. Juni 2020] und Aichele (2016), S. 38.
Seite 26Kapitel 3 - Theoretische Herangehensweise
welches Ziel sollen mit der mobilen Applikation verfolgt werden, bzw. welches Design
ist vom Auftraggeber erwünscht und welcher Benutzerkreis soll angesprochen
werden.49 In der Informatik wird dabei oft vom Requirements Engineering gesprochen.
3.2.2 Requirements Engineering
Unter dem Begriff Requirements Engineering wird „das systematische, disziplinierte
und quantitativ erfassbare Vorgehen beim Spezifizieren“ 50 von Anforderungen an ein
System oder ein Softwareprojekt verstanden. Dabei soll, noch bevor mit dem
Programmieren bzw. dem Designen der App begonnen wurde, festgestellt werden
welche „Muss- Anforderungen“ für den Projekterfolg unverzichtbar sind. Des Weiter
wird erhoben welche „Soll-Anforderungen“ ans Projekt gestellt werden, die zwar
wichtig sind, aber bei hohem Aufwand oder Kosten weggelassen werden können. Und
letztlich wie die „Wunsch-Anforderungen“ an das Projekt lauten, die zwar ein „nice-
to-have“ darstellen aber nicht essenziell für den Projekterfolg sind. Einen guten
Spezifikationsprozess zeichnen eine ausreichende Kundenorientierung und ein
methodisches und zielgerichtetes Vorgehen aus.51
Requirements Engineering ist als Prozess zu verstehen der das gesamte Projekt
begleitet.52 Da der wirtschaftliche Mehrwert des Requirements Engineering immer nur
indirekt zu bestimmen ist und schwer, bis gar nicht gemessen werden kann, wird es
bei vielen Projekten nur als Kostenfaktor gesehen.53
49 Aichele (2016), S.87.
50 Glinz (2006), S.2.
51 Glinz (2006), S.24-28.
52 Karakas (2015), S.4.
53 Glinz (2006), S.11.
Seite 27Kapitel 3 - Theoretische Herangehensweise
Requirements Engineering und die agile Vorgehensweise der Extremen
Programmierung machen die Erstellung eines Lasten54- und Pflichtenheftes55 (wie es
im klassischen Projektmanagement Usus ist) nicht zwingend notwendig.
Im begrenzten Rahmen dieser, im folgenden Kapitel beschriebenen, Softwareprojekte
wurde RE lediglich im begrenzten Maßstab eingesetzt. Bei großen Softwareprojekten
übt Requirements Engineering hingegen eine zentrale Funktion über den ganzen
Lebenszyklus (Entwicklung, Betrieb und Wartung) des Softwareproduktes aus und hat
zudem bei der Definition der rechtlichen und ethischen Rahmenbedingungen eine
wichtige Bedeutung.56
Nachdem die Anforderungen kundenseitig definiert wurden, kann mit der Umsetzung
begonnen werden. Bei der optischen und funktionalen Gestaltung (engl. Design) des
Softwareproduktes unterstützt das Werkzeug Design Thinking den Entwickler.
3.2.3 Design Thinking
Die Kreativtechnik des Design Thinkings ermöglicht eine stärkere
Kundeneinbeziehung und kann als Erweiterung zum Requirements Engineerings
gesehen werden.57
Die Methode wird, als ein auf den Menschen gerichteter Innovationsansatz
beschrieben, der kreative Werkzeuge aus dem Designbereich entnimmt, um die
Bedürfnisse der Menschen an die Technologie besser zu adressieren. Letztendlich soll
durch die Anwendung dieser Methode ein größerer Mehrwert für den Kunden
geschaffen werden.58
54 Beim Lastenheft handelt es sich um eine Zusammenstellung aller Projektanforderungen von
Auftraggeberseite (z.B. interne Anwender oder Kunden), oder, wie im Anwendungsfall dieser
Masterarbeit, um eine mobile Applikation. Alle relevanten Rahmenbedingungen sind darin
enthalten und es wird in der Regel vom Auftraggeber formuliert. Aichele (2014), S.173. Die
normgerechte Definition eines Lastenheftes findet sich u.a. in der ISO-Norm 21500 – Leitlinien
Projektmanagement.
55 Das Pflichtenheft (unter anderem auch Conceptual Design, Soll- oder Feinkonzept genannt) stellt aus
der Sicht des Auftragnehmers die formelle und detaillierte Antwort auf das Lastenheft dar. Die zu
erbringenden Anforderungen an den Auftragnehmer werden in die dafür erforderlichen Pflichten
(Tätigkeiten) übersetzt. Aichele (2014), S.173.
56 Patig, Susanne und Dibbern, Jens (2018). Requirements Engineering. In: Enzyklopädie der
Wirtschaftsinformatik – Online Lexikon.
57 Mehr dazu findet sich im Sammelbandbeitrag „Using Design Thinking for Requirements Engineering
in the Context of Digitalization and Digital Transformation“. Carell (2018), S.107-120.
58 Brown (2008), S.85.
Seite 28Kapitel 3 - Theoretische Herangehensweise
Design Thinking, seit 1996 unter anderem von Terry Winograd und Larry Leifer an der
Universität Stanford (Kalifornien, USA) entwickelt, basiert auf vier Prinzipien und sechs
Phasen:59
1) Prinzip: Die Bedürfnisse der Benutzer (Kunden) stehen im Mittelpunkt
2) Prinzip: Umfassendes Verständnis für den Anwendungsfall
3) Prinzip: Interdisziplinäres Team
4) Prinzip: Klarer Prozessablauf
Das vierte Prinzip, des klaren Prozessablaufs, wird in sechs Phasen unterteilt, an dem
am Ende das Testen der gefunden Lösung steht.
➢ Verstehen des Problems
• Verständnis für die Thematik erarbeiten
• In die „Tiefe“ denken und versuchen alle Bereiche in der
das Thema noch vorkommen könnte zu sehen
➢ Beobachten
• Vorort gehen um das Arbeitsumfeld des Kunden / der
Benutzer kennenzulernen, um deren Bedürfnisse zu sehen
und zu verstehen
• Empathie: die Sichtweise und Probleme des Kunden
verstehen und falls möglich zu antizipieren. Eigene
Interpretationen und Annahmen mit dem Kunden
besprechen, ob diese der Wahrheit entsprechen
➢ Herausforderungen definieren
• Gesammelte Information und Erkenntnisse im Detail
untersuchen, Muster identifizieren und eine
Herausforderung definieren
➢ Ideen finden
• Mit unterschiedlichen Kreativitätstechniken Ideen
generieren
• Vielseitigkeit des Teams nutzen
• Auf bestimmte Ideen fokussieren
59 Carell (2018), S.112-116.
Seite 29Kapitel 3 - Theoretische Herangehensweise
➢ Prototyp(en) entwickeln
• Mittels Prototypen mit den Kunden ins Gespräch kommen
• Ideen werden dadurch greifbarer
➢ Testen
• Herausfinden, ob den Benutzern die Lösung hilft
• Nutzer ausprobieren lassen – neue Vorschläge und Ideen
dokumentieren
• Auf dieser Basis iterativ das Konzept so lange verfeinern
bis die beste Lösung gefunden wurde, oder der Ansatz
überhaupt verworfen werden muss
Diese Schrittfolge kann mehrfach durchlaufen werden, Rücksprünge zu vorherigen
Phasen sind möglich.60
In Abbildung 6 ist das Phasenmodell des Design Thinkings schematisch dargestellt.
Abbildung 6: Design Thinking
Quelle: https://www.praxisfeld.de/de/beratung/agilitaet-innovation-design-thinking/der-design-thinking-
prozess
60 https://www.praxisfeld.de/de/beratung/agilitaet-innovation-design-thinking/der-design-thinking-
prozess [eingesehen am 24. Juni 2020]
Seite 30Kapitel 3 - Theoretische Herangehensweise
Oft passiert in Betrieben folgendes:
Projektziele werden festgelegt, mithilfe des Requirements Engineering das
Anforderungsprofil erstellt und mit dem Phasenmodell des Design Thinkings das
Aussehen und die Funktionalität der Apps erarbeitet. Doch nach dem Rollout wird
plötzlich festgestellt, dass eine Schlüsselfigur im Unternehmen sich durch das
Vorhaben „auf den Schlips getreten“ fühlt und sich als Verhinderer gibt. Alle
Projektteilnehmer sind überrascht, doch das Projekt wird von der Schlüsselfigur so
lange verhindert bis das Vorhaben im Sand verläuft.
Dieses Worst-Case-Szenario kann zum größten Teil vermieden werden, indem schon
vor dem ersten Schritt und während des gesamten Prozesses, auf die Werkzeuge des
Change-Managements zurückgegriffen wird.
3.3 Change Prozess
3.3.1 Warum ist ein Change Prozess notwendig?
Die allgemeine Einführung einer App für die Abarbeitung vorhandener interner
Prozesse entspricht zwar „nur“ einem Change erster Ordnung, sprich der Modifikation
der bisherigen Arbeitsweise.61 Ein elaborierter Change Prozess von Kick-off bis hin
zum Rollout ist trotzdem empfehlenswert, da die bestens designte, programmierte und
mit unzähligen Funktionen bestückte App sich nicht durchsetzen wird, wenn sie nicht
die Probleme der Mitarbeiter adressiert, sie einfach zu bedienen ist und für sie in ihrem
Berufsalltag einen Mehrwert bringt. Des Weiteren kann es (eventuell sogar große)
Probleme geben, wenn Schlüsselpersonen, wie beispielsweise der Betriebsrat, in den
Prozess der App-Entwicklung nicht miteingebunden werden. Dieser kann bei
Miteinbeziehung etwaige Bedenken hinsichtlich des Mitarbeiterdatenschutzes
einbringen und, wenn er mit den Zielen der Applikation übereinstimmt, eine positive
Grundstimmung in der Belegschaft erzeugen.
Ohne durchdachten Change Prozess scheiterten in der Vergangenheit schon die
ausgeklügeltesten Projekte - zumeist am Faktor Mensch. Eine neue Ordnung bzw.
neue Handlungsweisen einzuführen stellt sich immer wieder als schwierige und
herausfordernde Aufgabe heraus. Bis zu zwei Drittel der geplanten Change Projekte
61 Hörstmann (2008), S.6f.
Seite 31Sie können auch lesen
