

Auf der anderen Seite gibt es allerdings auch Nachteile für Unternehmen, diese bestehen zum einen aus rechtlichen Vorgaben, aber auch aus erhöhten Kosten.
Die rechtliche Lage für die Einführung von Bring your own Device ist in Deutschland ein großes Thema, schon im Arbeitsschutzgesetz ist verankert, dass der Arbeitgeber dem Arbeitnehmer Arbeitsmittel zu Verfügung stellen muss, Ausnahmen hiervon sind allerdings möglich.
Aber auch aus Datenschutz- und Datensicherheitsrechtlicher Sicht, sowie bei Lizensierungen und Steuerregelungen kann es zu Schwierigkeiten kommen. So muss sowohl auf Softwarelizenzen, insbesondere bei privater, die ebenfalls dienstlich genutzt wird geachtet werden, aber auch auf die Sicherheit von privaten und Unternehmensdaten. Daher ist es besonders wichtig, dass Regelungen für Bring your own Device eingeführt werden, die festlegen, wie die Nutzung von Daten gehandhabt wird, sprich wem welche Daten gehören. Ebenso sollte hier verankert werden was im Falle eines Ein- oder Austritts aus der Firma passiert. Hierzu gehört, dass es möglich sein sollte aus der Ferne Unternehmensdaten auf privaten Endgeräten zu löschen, ebenso wie, was mit schon gezahlter Kompensation für Endgeräte geschieht. Aber auch der Serviceablauf, welcher unter anderem beinhaltet, wer im Falle eines Verlustes oder Beschädigung von Endgeräten für ein Ersatzgerät sorgt, sollte geregelt werden. Wichtig ist hierbei, dass nicht nur der Mitarbeiter den Regelungen zustimmen muss, sondern ebenso der Betriebsrat oder andere Arbeitnehmervertretungen, sofern vorhanden. Auch wenn bei ByoD in der Regel die Selbstverwaltung von Devices gilt, so sollte der Arbeitgeber die Wartung nicht komplett verweigern. Beispielsweise für vom Unternehmen entwickelte Software muss Support gestellt werden, allerdings sind in manchen Fällen die Grenzen zwischen Software- und Hardwareproblemen schwimmend, so dass der Support auch auf in diesen Fällen weiterhelfen können sollte. Dies führt dazu, dass Supportmitarbeiter besser geschult werden müssen, als vor Bring your own Device. Dies wiederum führt zu erhöhten Schulungskosten. Daher ist es schwierig einen vollen Support für sämtliche Endgeräte zu leisten, wenn allerdings gar kein, oder kaum Support zu Verfügung steht, müssen sich die Mitarbeiter selber darum kümmern, was zu Ausfallzeiten und geringerer Motivation führen kann. Bring your own Device kann auch eine Ablenkung für den Mitarbeiter sein, da er so während der Arbeitszeit ständig mit seinem privaten Umfeld in Berührung gerät und es daher dazu kommen kann, dass die privaten Angelegenheiten den beruflichen vorgezogen werden.
Um Bring your own Device einzuführen sind häufig große Änderungen an der Unternehmens-IT notwendig. Daher müssen zunächst die Vor- und Nachteile verschiedener Lösungen, wie VPN-Zugänge, Virtualisierung, aufgelistet und bewertet werden. Ein wichtiger Punkt ist, ob die Lösung vom Arbeitnehmer angenommen und auch tatsächlich genutzt wird. Denn sofern die Anwender nicht mit der Lösung umgehen können, werden sie weiterhin vom Unternehmen fordern, dass es Arbeitsgeräte stellt, und nicht selber ihre privaten Endgeräte mitnehmen.
Auch ist wichtig, dass bewertet und festgelegt wird, welche Software und Softwaregenerationen kompatibel sind sowohl zu Unternehmensanwendungen als auch zur Hardware. Ggf. sollte dies ebenfalls im Regelwerk festgehalten werden. Bring your own Device sollte, wenn es eingeführt wird, nicht in jeder Abteilung unterschiedlich gehandhabt, sondern im gesamten Unternehmen gleich verwendet werden. Dennoch eignet sich das Konzept nicht für jeden Unternehmensbereich. Gerade ältere, oder wenig IT-affine Mitarbeiter können sich überfordert fühlen. Die Einführung in IT-Abteilungen oder für Außendienstmitarbeiter könnte im Gegensatz dazu schnell angenommen werden. Daher sollte vor der Einführung genau abgewägt werden für welche Zielgruppe das Konzept eingeführt wird, ggf. sollte vor Einführung ein kleiner Mitarbeiterkreis in einem zeitlich definiteren Pilotprojekt mitwirken. Anschließend sollte das Projekt inklusive der Kosten für die neuen Rahmenbedingungen, bewertet und eine Lösung für das gesamte Unternehmen gefunden werden.
| 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 19
Danke für die Einordnung. 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 dokumentiert man bei privaten Geräten knapp genug für den Alltag und zugleich so, dass die Entscheidung später nachvollziehbar bleibt? So entstünde aus der ersten Lösung ein belastbarer Lernschritt. Entscheidend wäre eine eindeutige, gemeinsam verstandene Festlegung.
Ich würde gern einen Punkt vertiefen: woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Wie lässt sich das mit überschaubarem Aufwand überprüfen?
Entscheidend wäre für mich, nicht nur die Durchführung zu dokumentieren. Auch die Wirkung und eine mögliche Abweichung sollten später nachvollziehbar sein.
Den Pilotgedanken finde ich gut. Ergänzen würde ich eine klare Schwelle: Ab wann führt das Ergebnis zu einer Entscheidung und wann bleibt es nur eine Beobachtung?
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.
Die Trennung zwischen Durchführung und Wirkung hilft. So könnte man klein anfangen, ohne die spätere Bewertung dem Bauchgefühl zu überlassen.
Wie lässt sich die Trennung zwischen privaten und geschäftlichen Daten praktisch überprüfen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Wie könnte bei Trennung privater und dienstlicher Daten eine Rückmeldung aus der operativen Umsetzung in die Steuerung einfließen?
Ein kurzer Austausch über konkrete Schwierigkeiten wäre aus meiner Sicht hilfreicher als eine reine Fortschrittsabfrage. Aus der Rückmeldung sollte eine benannte Entscheidung oder Maßnahme entstehen. Für Trennung privater und dienstlicher Daten würde ich den ersten Prüfschritt bewusst klein halten.
Welche Entscheidung müsste zu Supportgrenzen und Kostenverteilung zuerst fallen, wenn verschiedene Systeme dieselbe Information unterschiedlich abbilden?
Ich würde zunächst eine maßgebliche Quelle bestimmen und Abweichungen gezielt untersuchen, bevor Kennzahlen daraus abgeleitet werden. Das schafft eine begrenzte, überprüfbare Arbeitsgrundlage für die weitere Umsetzung. Bei Supportgrenzen und Kostenverteilung sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
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.
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. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen?
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. Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Genau an der Übergabe sehe ich ebenfalls die Schwierigkeit. Ohne die nötige Information kann auch eine klar benannte Person wenig entscheiden. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Ich würde bei der Umsetzung mit eine nachvollziehbare und im Alltag tragfähige Umsetzung beginnen. Hilfreich wäre eine vorher festgelegte Schwelle, ab der tatsächlich gehandelt wird.