

GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Die im November 2012 von techconsult im Auftrag von Microsoft erstellte Markterkundung untersucht, inwieweit Arbeitnehmer mit einem PC-Arbeitsplatz bereits private mobile Endgeräte bzw. Anwendungen an ihrem Arbeitsplatz nutzen, welche Treiber es gibt und wie sich die Unternehmen zu diesem Thema derzeit positionieren.
Die wichtigsten Ergebnisse: 69 Prozent der Arbeitnehmer, die an ihrem Arbeitsplatz generell mobile Endgeräte wie Notebooks, Tablets oder Smartphones einsetzen, nutzen derzeit private Geräte im Unternehmen. Dabei dominieren Smartphones mit einem Anteil von 67 Prozent und Laptops mit 52 Prozent. Das Gros der Befragten nutzt private Endgeräte zur Kommunikation via E-Mail und für Webbrowser bzw. Internetdienste.Die Nutzungsintensität privater Anwendungen ist im Vergleich zu privaten Endgeräten derzeit geringer. 26 Prozent der Arbeitnehmer, die an ihrem Arbeitsplatz mobile Endgeräte im Einsatz haben, nutzen private Anwendungen im Unternehmen. Bevorzugte Anwendungen sind Webbrowser bzw. Internetdienste, gefolgt von E-Mail und Office-Programmen.
Noch steht aus Sicht der Mitarbeiter eine deutliche Mehrheit der Unternehmen dem Trend zum „Bring your own“ eher ablehnend bzw. gänzlich ablehnend gegenüber. 60 Prozent der Unternehmen sind gegen die Nutzung privater Endgeräte. Noch deutlich mehr Unternehmen, nämlich 74 Prozent, möchten nicht, dass private Software genutzt wird. In erster Linie wird ein zu großes Sicherheitsrisiko gesehen. Anwender sehen „Bring your own“ wesentlich unkritischer: 30 Prozent der Befragten schätzen den Aufwand für das Management privater Endgeräte bzw. Software am Arbeitsplatz als gering ein.
Die vollständige Consumerization Study CIO Challenges 2012 von Microsoft finden Sie hier.
„Herausforderungen im Umgang mit „Bring your own“ bleibt als zeitbezogene Einordnung erhalten. Die folgende Ergänzung betrachtet den Schwerpunkt mit Blick auf Betriebsmodell aus heutiger Organisations- und Betriebssicht, ohne damalige Zahlen oder Produktversprechen stillschweigend fortzuschreiben; die Bewertung erfolgt hier aus der Perspektive „Herausforderungen im Umgang mit „Bring your own“.
Für die heutige Einordnung von „Herausforderungen im Umgang mit „Bring your own“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, wie Störungen, Rückfragen und Ausnahmen zur Verbesserung genutzt werden. Beim Schwerpunkt „Herausforderungen im Umgang mit „Bring your own“ geht es um Einführung, Akzeptanz und praktische Steuerung von Consumerisation und BYOD sowie um den Bezug zu „Betriebsmodell“; zu entscheiden ist, ob verhindert, geduldet oder innerhalb klarer Leitplanken aktiv ermöglicht werden soll. Die Grenze der Betrachtung bleibt eindeutig: Akzeptanz allein beweist keine sichere oder wirtschaftliche Umsetzung (hier bezogen auf „Nutzungsbedarf“); Ablehnung beseitigt den Bedarf ebenfalls nicht; im vorliegenden Abschnitt wird dies an „Rückbau“ konkretisiert. Im Regelbetrieb wird folgender Punkt verankert: Muster regelmäßig auswerten und Regeln gezielt anpassen. Für Audit und Führung reicht Aktivität nicht aus; „Schatten-IT“ liefert dafür den praktischen Anwendungsfall. Benötigt wird folgender Nachweis: eine Änderung, deren Anlass und erwartete Wirkung dokumentiert sind; bewertet wird außerdem: Nutzungsgrad, Ausnahmen, Umgehungslösungen, Supportaufwand und erreichte Arbeitsergebnisse. Aus den vorhandenen Kommentaren lässt sich besonders der Punkt „die Grenze zwischen privaten und geschäftlichen Interessen“ aufnehmen. Aus der Perspektive „Betriebsmodell“ entsteht daraus eine konkrete Rückfrage an die Umsetzung; im Fokus steht dabei „Nutzungsbedarf“.
Der Beitrag gewinnt beim Aspekt „Betriebsmodell“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, wann eine Abweichung vertretbar ist und wann sie beendet werden muss. Beteiligt sind hier vor allem Geschäftsleitung, Fachbereiche, IT, Informationssicherheit, Personal und Nutzende; ihre Perspektiven treffen beim Aspekt „Supportgrenze“ unmittelbar aufeinander. Die Schwachstelle liegt nicht im Schlagwort selbst, sondern dort, wo die offizielle Regel vom tatsächlichen Arbeitsverhalten abweicht und Schattenlösungen zum Normalfall werden – betrachtet im Kontext „Ausnahmeweg“. Die praktische Konsequenz heißt: Eigentümer, Begründung, Kompensation und Ablaufdatum festlegen; der Belastungstest erfolgt mit Blick auf „Umgehungslösung“. Für Audit und Führung reicht Aktivität nicht aus; der Prüfkontext ist hier „Ausnahmeweg“. Benötigt wird folgender Nachweis: ein befristetes Ausnahmeregister mit Wiedervorlage; bewertet wird außerdem: der Zusammenhang zwischen „Betriebsmodell“ und „Supportgrenze“. Beim Aspekt „Supportgrenze“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Für die heutige Einordnung von „Einführungsmodell“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, welche Erwartung verständlich erklärt und bei Rückfragen erreichbar sein muss. Als belastbare Grundlage dienen Nutzungsfälle, Bedarfsanalyse, Pilotbefunde, Ausnahmen, Supportdaten und dokumentierte Entscheidungen; für den Aspekt „Einführungsmodell“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Umgehungslösung“ sollte deshalb ausdrücklich festhalten, ob verhindert, geduldet oder innerhalb klarer Leitplanken aktiv ermöglicht werden soll. Operativ folgt daraus: Regel, Grund, Alternative und Hilfe zielgruppengerecht verbinden. Überprüfbar wird der Schritt durch folgendes Ergebnis: Rückfragen, Fehlanwendungen und Verständnislücken als Lernsignal; „Nutzungsregel“ liefert dafür den praktischen Anwendungsfall. Relevant bleibt dabei: die beobachtbare Veränderung beim Aspekt „klare Zuständigkeiten und Entscheidungsrechte“; „Nutzungsregel“ liefert dafür den praktischen Anwendungsfall. Die bisherige Diskussion liefert mit „klare Zuständigkeiten und Entscheidungsrechte“ einen zusätzlichen Prüfstein; er sollte mit „Umgehungslösung“ verbunden und nicht isoliert bewertet werden.
Der nächste sinnvolle Schritt für „Rückbau“ trennt Aussage, Voraussetzung und Konsequenz voneinander: Es ist zu klären, wer freigibt, betreibt, kontrolliert und bei Abweichungen entscheidet. Die alltagstaugliche Übersetzung für „Rückbau“ lautet: Reale Arbeitsweisen werden erhoben und in ein abgestuftes, überprüfbares Betriebsmodell überführt. Damit wird zugleich die Grenze beim Aspekt „Skalierung“ sichtbar: Akzeptanz allein beweist keine sichere oder wirtschaftliche Umsetzung (hier bezogen auf „Pilotgruppe“); Ablehnung beseitigt den Bedarf ebenfalls nicht; „Akzeptanz“ liefert dafür den praktischen Anwendungsfall. Statt einer neuen Parallelstruktur genügt zunächst: Entscheidungs-, Ausführungs- und Kontrollrolle auseinanderhalten. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: eine schlanke Zuordnung für Normalfall und Eskalation; bezogen auf „Betriebsmodell“ ist die konkrete Ausprägung separat zu entscheiden. Die Ergebnisbeobachtung richtet sich auf: Nutzungsgrad, Ausnahmen, Umgehungslösungen, Supportaufwand und erreichte Arbeitsergebnisse; im vorliegenden Abschnitt wird dies an „Betriebsmodell“ konkretisiert. Der gewählte Weg sollte sich außerdem umkehren lassen, falls die Annahmen zu „Skalierung“ später nicht mehr tragen; für „Einführungsmodell“ ist das Ergebnis gesondert festzuhalten.
Praktisch relevant wird „Supportgrenze“ dort, wo Verantwortung und Ergebnis zusammenkommen: Es ist zu klären, welcher bestehende Prozess den neuen Prüfschritt sinnvoll aufnehmen kann. Die Schwachstelle liegt nicht im Schlagwort selbst, sondern dort, wo die offizielle Regel vom tatsächlichen Arbeitsverhalten abweicht und Schattenlösungen zum Normalfall werden – betrachtet im Kontext „Nutzungsregel“. Für die beteiligten Rollen – Geschäftsleitung, Fachbereiche, IT, Informationssicherheit, Personal und Nutzende – braucht der Aspekt „Supportgrenze“ daher einen vorab geklärten Entscheidungsweg. Für den nächsten Review wird vereinbart: Beschaffung, Berechtigung, Änderung oder Offboarding gezielt erweitern; die Bewertung erfolgt hier aus der Perspektive „Rückbau“. Für Audit und Führung reicht Aktivität nicht aus; der konkrete Prüfmaßstab wird aus „Supportgrenze“ abgeleitet. Benötigt wird folgender Nachweis: ein eingebetteter Kontrollpunkt ohne parallelen Sonderprozess; bewertet wird außerdem: der Zusammenhang zwischen „Supportgrenze“ und „Herausforderungen im Umgang mit „Bring your own“. Aus den vorhandenen Kommentaren lässt sich besonders der Punkt „Mindestanforderungen und befristete Ausnahmen“ aufnehmen. Aus der Perspektive „Herausforderungen im Umgang mit „Bring your own“ entsteht daraus eine konkrete Rückfrage an die Umsetzung.
Der Beitrag gewinnt beim Aspekt „Schatten-IT“ an Aktualität, sobald sein Kerngedanke in eine heutige Entscheidung übersetzt wird: Es ist zu klären, welche offene Annahme in kleinem Rahmen geprüft werden soll. Folgende Messperspektive zeigt, ob sich der Aspekt „Schatten-IT“ tatsächlich verbessert oder nur formell bearbeitet wurde: Nutzungsgrad, Ausnahmen, Umgehungslösungen, Supportaufwand und erreichte Arbeitsergebnisse. Für „Rückbau“ bleibt dabei verbindlich: Akzeptanz allein beweist keine sichere oder wirtschaftliche Umsetzung (hier bezogen auf „Nutzungsregel“); Ablehnung beseitigt den Bedarf ebenfalls nicht. Statt einer neuen Parallelstruktur genügt zunächst: Erfolg, Abbruch, Beobachtungszeitraum und Übertragungskriterium vorab bestimmen. Der vorgesehene Nachweis lautet: ein Pilotprotokoll mit Ergebnis und bewusster Folgeentscheidung. Als Messperspektive dient: die beobachtbare Veränderung beim Aspekt „die Grenze zwischen privaten und geschäftlichen Interessen“; im Fokus steht dabei „Umgehungslösung“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Schatten-IT“ noch nachvollziehbar wäre.
Für Betriebsmodell sollte am Ende kein umfangreiches Zusatzdokument stehen, sondern eine klare Entscheidung mit Eigentümer, Nachweis und Wiedervorlage für Einführungsmodell. Genau daran lässt sich erkennen, ob die Vertiefung zu Rückbau praktische Wirkung entfaltet.
| 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. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
Wenn Sie den Blog-Beitrag abonnieren, senden wir Ihnen eine E-Mail, sobald es Updates auf dieser Website gibt.

Kommentare 24
Eine Frage zur Umsetzung: woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Welche Beobachtung wäre wichtiger als eine reine Vollständigkeitsquote?
Ein kleiner Pilot erscheint mir sinnvoll. Wichtig wäre nur, vorher festzulegen, welches Ergebnis als Verbesserung gilt und wer es beurteilt.
Ich würde außerdem festhalten, welche Annahmen hinter der Bewertung stehen. Ändern sie sich, sollte nicht einfach derselbe Status fortgeschrieben werden.
Das ist die wesentliche Abgrenzung. Eine Dokumentation zeigt zunächst nur, was vorgesehen oder getan wurde; erst die überprüfte Wirkung macht daraus einen Steuerungsimpuls.
So ergibt die Vorgehensweise Sinn: begrenzter Einstieg, klare Messgröße und eine sichtbare Entscheidung, falls das Ergebnis nicht trägt.
Eine Frage zur Umsetzung: 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.
Dazu eine Rückfrage: Was passiert beim Ausscheiden mit den Firmendaten, wenn das Gerät weiterhin privat benutzt wird? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Daran würde ich anknüpfen. Der Austritt gehört für mich schon in die Planung. Zugriff entziehen und Unternehmensdaten entfernen sind unterschiedliche Aufgaben, die getrennt beschrieben werden sollten. 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 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.
Für mich fehlt dabei noch der Umgang mit Ausnahmen. Wer darf abweichen und wie wird diese Entscheidung später nachvollzogen? Meine Ausgangsfrage bleibt: 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.
Der Ansatz wird aus meiner Sicht durch eine nachvollziehbare und im Alltag tragfähige Umsetzung belastbar. Entscheidend ist auch die dokumentierte Konsequenz aus Abweichungen.
Mich überzeugt besonders der Bezug zu eine nachvollziehbare und im Alltag tragfähige Umsetzung. Ein konkreter Anwendungsfall könnte zeigen, wo der Ansatz noch zu abstrakt ist.
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.
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.
Damit bin ich noch nicht ganz zufrieden. Wie würde man prüfen, ob die vorgeschlagene Lösung im Alltag tatsächlich eingehalten wird?
Für die praktische Anwendung zählt aus meiner Sicht eine nachvollziehbare und im Alltag tragfähige Umsetzung. Sonst wirkt formal alles vollständig, ohne Entscheidungen zu verbessern.
Ich würde eine nachvollziehbare und im Alltag tragfähige Umsetzung zunächst an einem kritischen, aber überschaubaren Fall testen. Dann lassen sich Aufwand und Nutzen vernünftig vergleichen.
Wie würdet ihr bei Trennung privater und dienstlicher Daten die wichtigsten Abhängigkeiten für die Umsetzung sichtbar machen?
Ich würde zunächst die wenigen Abhängigkeiten erfassen, deren Ausfall oder Verzögerung das Ergebnis tatsächlich gefährdet. Die Liste sollte eine Entscheidung ermöglichen und regelmäßig überprüft werden. Für Trennung privater und dienstlicher Daten würde ich den ersten Prüfschritt bewusst klein halten.
Der Gedanke zu eine nachvollziehbare und im Alltag tragfähige Umsetzung ist plausibel. Ich würde früh klären, wer bei einem negativen Ergebnis entscheiden muss.
Wie würdet ihr Trennung privater und dienstlicher Daten konkret prüfen, wenn die Maßnahme bereits auf dem Papier abgeschlossen ist?
Für diesen Fall wäre mein Ansatz: die Umsetzung an einem konkreten Fall nachvollziehen und dabei das tatsächliche Ergebnis prüfen. Damit bleibt sichtbar, was entschieden wurde und was noch offen ist. Bei Trennung privater und dienstlicher Daten sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.