

Wie bereits angekündigt, folgen im letzten Teil meiner Blogreihe zu meiner Masterthesis die Phasen Umsetzungsstrategie, Pilotprojekt und Rollout, sowie Anpassung der IT-Strategie.
Umsetzungsstrategie
Wenn sich nach der Analyse herausstellt, dass ein Unternehmen Bring your own Device einsetzen möchte, muss der Umfang eingegrenzt werden. Wie die empirische Umfrage ergeben hat, erlauben viele Unternehmen lediglich die Nutzung von privaten Smartphones. Manche Unternehmen unterstützen sogar nur die eines bestimmten Herstellers, oder mit bestimmtem Betriebssystem. Je weniger Einschränkungen der Arbeitgeber vorgibt, desto zufriedener mögen seine Mitarbeiter sein, desto mehr Sicherheitsvorkehrung sind allerdings auch vorzunehmen. Auch kann der Arbeitgeber die Nutzungsmöglichkeiten einschränken. Entsprechend dem Ergebnis der empirischen Untersuchung wird es am häufigsten erlaubt Kalender, Kontakte und E-Mail Funktionalität zu nutzen. Auch hier gilt, je mehr Anwendungen der Arbeitgeber zulässt umso höher ist das IT Sicherheitsrisiko.
Mögliche Umsetzungsvarianten wären daher folgende:
Einsatz von E-Mail, Kalender und Kontakten auf dem privaten Smartphone
Firmendesktops auf privaten Endgeräten, wie Notebooks
Virtualisierung von Anwendungen zur Ausführung auf privaten Endgeräten
Aufgrund des Sicherheitsrisikos sollte ein Arbeitgeber jedoch niemals eine Arbeitsumgebung zur freien Konfiguration freigeben.
Pilotprojekt und Rollout
Die Umsetzung sollte nicht direkt in der ganzen Firma erfolgen, sondern Schrittweise. Hierbei gibt es verschiedene Möglichkeiten für eine Vorgehensweise.
Bring your own Device sollte schrittweise eingeführt werden, das heißt, zunächst könnte beispielsweise das WLan für private Endgeräte freigeschalten werden. In einem weiteren Schritt wäre es sinnvoll bestimmte Anwendungen, wie Kalender und E-Mail Funktionalität für bestimmte private Endgeräte freizugeben. Dies könnte direkt für alle Mitarbeiter erfolgen, oder aber nur für eine Pilotgruppe. Letzteres würde sich empfehlen, da man einen kleinen Anwenderkreis einfacher „überwachen“ kann, das bedeutet positive Effekte sowie Schwierigkeiten können besser erkannt werden. So können Sicherheitsrisiken entfernt werden, bevor sie Schaden anrichten. Auch können bei einer kleineren Gruppe leichter Umfragen bzgl. der Akzeptanz von IT Consumerization durchgeführt werden. Aufbauend auf den Ergebnissen des Pilotprojektes könnte Bring your own Device weiter ausgebaut werden, beispielsweise auf weitere Endgeräte und/oder Anwendungen oder auf größere Personengruppen. Letzteres birgt weitere Herausforderungen, da der Übergang zum privaten Endgerät reibungslos verlaufen sollte.
Anpassung der IT-Strategie
Bring your own Device bringt der Unternehmens-IT große Veränderungen. Daher sollte das Thema nicht isoliert implementiert werden. Vor der Einführung sollte der Einfluss auf die IT-Strategie, -Architektur und den –Betrieb evaluiert werden. Durch ByoD gibt es in nahezu allen Bereichen neue Anforderungen an die IT, die berücksichtigt werden und mit der Einführung von BoyD geändert sollten.
Die IT-Architektur sollte keinerlei Anforderungen an das Endgerät stellen, sondern standardisierte Benutzerschnittstellen zu Verfügung stellen. So sollten möglichst viele Anwendungen webbasiert sein und die Daten nicht lokal, sondern auf Servern abgelegt werden. Daher bietet sich eine cloudbasierte Architektur bei der Umsetzung von IT Consumerization an. Auch die Sicherheitsstrategie sollte überarbeitet werden. Während vor der Einführung von ByoD Firewalls oder ähnliche Anwendungen an den Unternehmensgrenzen ausgereicht haben, sollte mit der Einführung über eine Absicherung der Daten nachgedacht werden, hierzu bieten sich Zugriffskontrollen und Verschlüsselung an. Auch für den Betrieb gibt es durch die Einführung von ByoD einige Änderungen. Während vorher die meisten Anwender ähnliche Endgeräte hatten und sich der Support so auf diese spezialisieren konnte, gibt es mit Bring your own Device eine Vielzahl von Endgeräten. Je nach Endgerät können sich unterschiedliche Problemstellungen ergeben. Daher sollten die Supportabteilungen dahingehend geschult werden.
Erkennbar an dem Vorgehen für die Einführung von Bring your own Device ist, dass es keine richtige Anleitung gibt nach der man vorgehen kann. Jedes Unternehmen muss für sich selber entscheiden in welchem Rahmen, d.h. welche Endgeräte unterstützt und welche Anwendungen verfügbar gemacht werden, ByoD eingesetzt werden soll. Dabei ist auch auf die Unternehmensstruktur und -Branche zu achten. In Unternehmen im regulierten Umfeld ist es sicherlich schwieriger IT Consumerization umzusetzen, da Daten einem besonderen Schutz und das Unternehmen bestimmten Vorgaben unterliegen. In kleinen Unternehmen ist ByoD schneller umzusetzen, allerdings birgt die Umsetzung auch Gefahren, weshalb kleinere Unternehmen häufig zögerlicher an neue Trends herangehen, als große Unternehmen, bei denen ein Rückschlag nicht zum Konkurs führen kann. Auch wird ByoD eher in Unternehmen mit IT-affineren Mitarbeitern, wie reine IT-Unternehmen, Einzug finden, als in Unternehmen die weniger IT-affin sind.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 30
Spannend finde ich die praktische Seite: woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Reicht dafür zunächst ein kleiner Pilot oder braucht es sofort einen breiteren Ansatz?
Ich würde zunächst einen konkreten Ablauf auswählen und dort Ausgangslage, Entscheidung und Ergebnis gegenüberstellen. Sonst bleibt die Bewertung leicht abstrakt.
Für mich gehört noch ein fester Zeitpunkt zur Nachprüfung dazu. Erst dann lässt sich beurteilen, ob die Maßnahme nur erledigt wurde oder tatsächlich etwas verbessert hat.
Beides gehört zusammen: ein überschaubarer Einstieg und eine klare Konsequenz bei Abweichungen. Ohne diese Konsequenz bleibt auch eine gute Kennzahl letztlich informativ statt steuernd.
Das überzeugt mich. Ein konkreter Fall mit klarer Zuständigkeit und Nachprüfung dürfte mehr zeigen als ein umfangreiches Modell ohne praktische Rückkopplung.
Den Punkt würde ich gern vertiefen. Wie würdest du Zuständigkeiten für private Geräte und betriebliche Anwendungen voneinander abgrenzen?
Ich würde zuerst klären, welche Daten und Anwendungen betroffen sind. Daraus lassen sich Supportgrenzen und Verantwortlichkeiten ableiten.
Wie lässt sich bei Ausscheiden und Verlust des privaten Geräts vermeiden, dass offene Punkte zwischen mehreren Zuständigkeiten liegen bleiben?
Ich würde den offenen Punkt mit einem Verantwortlichen, einem Termin und einem überprüfbaren Ergebnis verbinden. Bei mehreren Beteiligten sollte außerdem klar sein, wer eine Entscheidung herbeiführt. Für Ausscheiden und Verlust des privaten Geräts würde ich den ersten Prüfschritt bewusst klein halten.
Was passiert beim Ausscheiden mit den Firmendaten, wenn das Gerät weiterhin privat benutzt wird? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich würde es so einordnen: Der Austritt gehört für mich schon in die Planung. Zugriff entziehen und Unternehmensdaten entfernen sind unterschiedliche Aufgaben, die getrennt beschrieben werden sollten. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Hier würde ich widersprechen: Ein zusätzlicher Prozess kann auch neue Reibung schaffen. Welche vorhandene Aufgabe könnte man damit zusammenführen? Meine Ausgangsfrage bleibt: Was passiert beim Ausscheiden mit den Firmendaten, wenn das Gerät weiterhin privat benutzt wird?
Der Umfang müsste zur Bedeutung der betroffenen Leistung passen. Weniger Detail kann vernünftig sein, solange die wesentlichen Entscheidungen und Abhängigkeiten nachvollziehbar bleiben. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ja, so wird die Abwägung konkreter. Ich würde vor allem den Prüfanlass festhalten, damit die Lösung nicht unbegrenzt als gesetzt gilt. Die Ausgangsfrage „Was passiert beim Ausscheiden mit den Firmendaten, wenn das Gerät weiterhin privat benutzt wird?“ ist damit für mich noch nicht vollständig beantwortet.
Das ist mir als Maßstab noch etwas zu weich. Welches Ergebnis müsste sich nach der Änderung nachweisbar verbessern? Meine Ausgangsfrage bleibt: Was passiert beim Ausscheiden mit den Firmendaten, wenn das Gerät weiterhin privat benutzt wird?
Wo würdet ihr bei Ausscheiden und Verlust des privaten Geräts anfangen, wenn die Zuständigkeit beim Übergang in den Betrieb unklar bleibt?
Mein Vorschlag wäre, die Übergabe erst mit benanntem Verantwortlichen und nachvollziehbaren Abnahmekriterien abschließen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Ausscheiden und Verlust des privaten Geräts sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Welche Abweichung würde euch bei Ausscheiden und Verlust des privaten Geräts veranlassen, die Entscheidung erneut aufzumachen?
Wenn eine tragende Annahme nicht mehr stimmt, wäre für mich eine neue Bewertung nötig. Dafür sollten Annahme, Auswirkung und Entscheidung zusammen dokumentiert sein; sonst wird die Änderung leicht übersehen. Mit Blick auf Ausscheiden und Verlust des privaten Geräts würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Ist eine freiwillige Teilnahme wirklich freiwillig, wenn das private Gerät im Team faktisch erwartet wird? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Dazu eine Rückfrage: Wie lässt sich die Trennung zwischen privaten und geschäftlichen Daten praktisch überprüfen? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Daran würde ich anknüpfen. Für mich wäre eine klare Grenze beim Zugriff entscheidend. Ein geschäftlicher Container wäre ein Ansatz; die privaten Inhalte sollten nicht einfach zum administrierbaren Unternehmensbestand werden. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen? Meine Ausgangsfrage bleibt: Wie lässt sich die Trennung zwischen privaten und geschäftlichen Daten praktisch überprüfen? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Auf die Ausgangsfrage bezogen: Für mich wäre eine klare Grenze beim Zugriff entscheidend. Ein geschäftlicher Container wäre ein Ansatz; die privaten Inhalte sollten nicht einfach zum administrierbaren Unternehmensbestand werden.
Danke für die Präzisierung. Für mich wäre die Wirkung im Betrieb die interessantere Rückmeldung als die reine Vollständigkeit der Unterlagen. Die Ausgangsfrage „Wie lässt sich die Trennung zwischen privaten und geschäftlichen Daten praktisch überprüfen?“ ist damit für mich noch nicht vollständig beantwortet. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Wer trägt beim privaten Gerät eigentlich die Kosten für Support, Reparatur und einen möglichen Ausfall? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ich würde es so einordnen: Eine BYOD-Regelung müsste diese Fälle ausdrücklich unterscheiden. Der Kaufpreis allein sagt wenig darüber aus, ob das Modell insgesamt wirtschaftlich ist. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Der Grundgedanke passt für mich. Trotzdem: Wie verhindert man, dass die Verantwortung zwischen mehreren Beteiligten hängen bleibt? Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Bei eine nachvollziehbare und im Alltag tragfähige Umsetzung würde ich nicht nur die Durchführung betrachten. Aussagekräftig wird es erst, wenn Wirkung und Abweichungen sichtbar bleiben.
Spannend ist für mich, wie eine nachvollziehbare und im Alltag tragfähige Umsetzung in bestehende Abläufe passt. Eine zusätzliche Parallelstruktur wäre vermutlich schwer dauerhaft zu betreiben.