GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
Sofern Arbeitgeber auf den BYOD Trend setzen, war gerade die Erreichbarkeit im Urlaub ein willkommener Benefit. Lange Zeit war das Roaming eine unüberschaubare Kostenfalle für die Arbeitnehmer, die Ihre "Devices" im Urlaub für den Arbeitgeber auf Empfang hatten. Wer im Urlaub telefonierte, mal eben ein paar Fotos vom Strand nach Hause schickte oder gar im Internet surfte wurde oft mit einer horrenden Rechnung konfrontiert. Bereits seit 2007 wurden die preislichen Obergrenzen daher in der EU gesetzlich festgelegt und jährlich gesenkt. Nun ist geplant, die Roaming-Kosten insgesamt innerhalb der EU abzuschaffen.
Sinkende Preise dank EU
Die Preise für Anrufe sanken von 2007 mit 49 Cent pro Minute auf 2014 mit 19 Cent. Die Unsitte, dass man auch für eingehende Anrufe zur Kasse gebeten werden konnte wurde 2007 auf 24 Cent pro Minute beschränkt und sank bis 2014 auf 5 Cent pro Minute. Der Preis für eine SMS wurde 2009 auf 11 Cent festgelegt und sank bis 2014 auf 6 Cent. Und letztlich wurde für das mobile Internet erstmals 2012 der Preis für eine Datenmenge von 1 MB auf 70 Cent begrenzt und bis 2014 auf 20 Cent gesenkt. Hinzu kamen noch die landesüblichen Mehrwertsteuern.
Kostenobergrenze gegen Kostenfallen
Neben den Kostenobergrenzen wurde auch ein so genannter Cut-Off-Mechanismus eingeführt. Werden beim Surfen Kosten von 59,50 Euro fällig, so wird die Internetverbindung gekappt. Will der Kunde das Internet weiterhin nutzen, so geht dies nur durch seine aktive Kontaktaufnahme mit dem Anbieter. In der Praxis hielten sich aber nicht alle Anbieter daran. Nun sollen Ende 2015 jegliche Roaming-Gebühren verboten werden. Aber hierzu bedarf es noch der Zustimmung aller Mitgliedsstaaten.
Anbieter reagieren mit speziellen Angeboten
Die Anbieter (wie z.B. FastSim) bieten schon vorab spezielle Smartphone Tarife für verschiedene Länderzonen an. Flexible Flatrates sind oft dann kostengünstiger, wenn man nur gelegentlich mobiles Internet braucht. Seit 2014 gibt es Angebote, bei denen gegen einen relativ überschaubaren Aufpreis keine weiteren Roaming-Gebühren mehr anfallen. Konkret bedeutet dies, dass sämtliche Konditionen des jeweiligen Vertrags innerhalb der gesamten EU gültig sind. Da man damit aber kontinuierlich mehr bezahlt, lohnt sich ein solcher Vertrag nur für Nutzer, die viel reisen und dabei mobiles Internet benötigen. Auch klagen Kunden immer wieder über versteckte Kostenfallen und einige Anbieter stehen in dem Ruf jedwede Gesetzeslücke auszunutzen. Eine EU-weite Regelung ist daher in jedem Fall zu begrüßen und könnte gerade für kleine und mittlere Unternehmen (KMU) einen erheblichen Vorteil in der Abrechnung bringen..
Mobilfunkkosten als zeitabhängige Vertragsfrage behandeln. Der Beitrag beschreibt die damalige Entwicklung beim Roaming. Für eine heutige Reiseregel sind der konkrete Tarif, das Reiseland und die aktuellen Vertragsbedingungen maßgeblich. Halten Sie fest, welche Kosten die Organisation übernimmt und wie Ausnahmen vor Reisebeginn freigegeben werden.
Regulierung, Verantwortung und Steuerung werden als zusammenhängende Führungsaufgabe betrachtet. Die Managementperspektive stellt die Frage in den Mittelpunkt, wie aus regulatorischen Vorgaben handhabbare Entscheidungen, Zuständigkeiten und Steuerungsprozesse entstehen.
Von Dr. Markus Groß
„Chancen für BYOD? Kostenfalle Roaming soll EU-weit abgeschafft werden“ setzt einen klaren historischen Ausgangspunkt. Die Ergänzung trennt diesen Anlass anhand von Interoperabilität von den Fragen, die für Entscheidungen, Betrieb und Kontrolle weiterhin relevant sind.
Aus dem historischen Befund entsteht für „Chancen für BYOD“ eine praktische Steuerungsfrage: Es ist zu klären, welche offene Annahme in kleinem Rahmen geprüft werden soll. Beim Schwerpunkt „Chancen für BYOD“ geht es um mobile Plattformen, Container, Apps und ihre betriebliche Einbindung sowie um den Bezug zu „Hersteller-Support“; zu entscheiden ist, welche technische Abgrenzung dauerhaft administrierbar und herstellerunabhängig genug ist. Dabei bleibt folgende Grenze maßgeblich: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Ausstiegsweg“), für den sie technisch ausgelegt wurde. Die praktische Konsequenz heißt: Erfolg, Abbruch, Beobachtungszeitraum und Übertragungskriterium vorab bestimmen. Die Dokumentation hält zwei Dinge fest – ein Pilotprotokoll mit Ergebnis und bewusster Folgeentscheidung; zusätzlich sichtbar wird: Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung. Der Diskussionsaspekt „klare Zuständigkeiten und Entscheidungsrechte“ ergänzt die Betrachtung sinnvoll, weil er „Hersteller-Support“ mit der tatsächlichen Anwendung verknüpft.
Eine nüchterne Fortführung trennt bei „Hersteller-Support“ den damaligen Anlass von der bleibenden Organisationsfrage: Es ist zu klären, welcher bestehende Prozess den neuen Prüfschritt sinnvoll aufnehmen kann. Beteiligt sind hier vor allem Architektur, Endgerätebetrieb, Support, Informationssicherheit, Einkauf und Anwendungsverantwortliche; ihre Perspektiven treffen beim Aspekt „Supportmatrix“ unmittelbar aufeinander. Das relevante Negativszenario entsteht, wenn eine Produktfunktion mit einem vollständigen Betriebsmodell verwechselt wird oder nach einem Update ihre Wirkung verliert – betrachtet im Kontext „Schnittstellen“. Für die belastbare Umsetzung gilt als Auftrag: Beschaffung, Berechtigung, Änderung oder Offboarding gezielt erweitern; die Umsetzung wird dabei an „Versionswechsel“ gespiegelt. Für Audit und Führung reicht Aktivität nicht aus; für „Schnittstellen“ ist das Ergebnis gesondert festzuhalten. Benötigt wird folgender Nachweis: ein eingebetteter Kontrollpunkt ohne parallelen Sonderprozess; bewertet wird außerdem: der Zusammenhang zwischen „Hersteller-Support“ und „Supportmatrix“. Im Managementdialog muss beim Aspekt „Hersteller-Support“ erkennbar bleiben, welche Unsicherheit akzeptiert und welche aktiv reduziert wird.
Für die belastbare Anwendung von „Interoperabilität“ muss aus der Beobachtung ein prüfbarer Arbeitsauftrag werden: Es ist zu klären, wie Daten, Rechte, Geräte und Verpflichtungen am Ende bereinigt werden. Als belastbare Grundlage dienen Architekturentscheidung, unterstützte Versionen, Konfigurationsbaseline, Tests, Abhängigkeiten und Ausstiegsweg; für den Aspekt „Interoperabilität“ muss ihre Herkunft nachvollziehbar bleiben. Die Entscheidung über „Versionswechsel“ sollte deshalb ausdrücklich festhalten, welche technische Abgrenzung dauerhaft administrierbar und herstellerunabhängig genug ist. Im Regelbetrieb wird folgender Punkt verankert: Rückgabe, Entzug, Export, Löschung und Bestätigung zusammenführen. Der Prüfpfad endet nicht beim Dokument; bezogen auf „Plattformarchitektur“ ist die konkrete Ausprägung separat zu entscheiden. Als Verbindung zwischen Nachweis und Messung dienen: ein abgeschlossener Austritts- oder Rückbau-Nachweis; die beobachtbare Veränderung beim Aspekt „Mindestanforderungen und befristete Ausnahmen“. Für den Dialog unter dem Beitrag ist „Mindestanforderungen und befristete Ausnahmen“ der passende Belastungstest: Gerade beim Aspekt „Versionswechsel“ muss die Regel im Alltag tragen.
Der nächste sinnvolle Schritt für „Updatepfad“ trennt Aussage, Voraussetzung und Konsequenz voneinander: Es ist zu klären, wie Person, Gerät und Berechtigung vor einem Zugriff zusammen bewertet werden. Die alltagstaugliche Übersetzung für „Updatepfad“ lautet: Plattformwahl, Konfiguration und Betriebsverantwortung werden als zusammenhängende Entscheidung dokumentiert. Damit wird zugleich die Grenze beim Aspekt „Betriebsverantwortung“ sichtbar: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Konfigurationsprofil“), für den sie technisch ausgelegt wurde. Für den nächsten Review wird vereinbart: Zugriff an Identität, Kontext und Gerätezustand koppeln; im vorliegenden Abschnitt wird dies an „Chancen für BYOD“ konkretisiert. Für Audit und Führung reicht Aktivität nicht aus; als Bezugspunkt dient „Hersteller-Support“. Benötigt wird folgender Nachweis: Protokolle über Erteilung, Nutzung, Entzug und Ausnahme; bewertet wird außerdem: Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung. Beim Aspekt „Betriebsverantwortung“ ist nicht die Menge der Aktivitäten entscheidend, sondern die erkennbare Veränderung des Ergebnisses.
Für die heutige Einordnung von „Supportmatrix“ ist zunächst eine Unterscheidung entscheidend: Es ist zu klären, welche Veränderung eine erneute fachliche oder risikobezogene Freigabe auslöst. Ein realistischer Belastungstest betrachtet den Fall, dass eine Produktfunktion mit einem vollständigen Betriebsmodell verwechselt wird oder nach einem Update ihre Wirkung verliert – betrachtet im Kontext „Plattformarchitektur“. Für die beteiligten Rollen – Architektur, Endgerätebetrieb, Support, Informationssicherheit, Einkauf und Anwendungsverantwortliche – braucht der Aspekt „Supportmatrix“ daher einen vorab geklärten Entscheidungsweg. Ein schlanker, aber wirksamer Ansatz lautet: Schwellen für Konfiguration, Zweck, Daten und Nutzerkreis definieren. Ob der Ansatz trägt, wird an folgendem Ergebnis geprüft: eine Änderungsspur mit Entscheidung und neuem Prüfdatum. Die Ergebnisbeobachtung richtet sich auf: der Zusammenhang zwischen „Supportmatrix“ und „Chancen für BYOD“. Die bisherige Diskussion liefert mit „Tests und Lernen aus erkannten Abweichungen“ einen zusätzlichen Prüfstein; er sollte mit „Chancen für BYOD“ verbunden und nicht isoliert bewertet werden.
Im Mittelpunkt von „Containerlösung“ steht weniger das Schlagwort als die damit verbundene Entscheidung: Es ist zu klären, wie Komponenten, Schnittstellen und Vertrauensgrenzen zusammenspielen. Folgende Messperspektive zeigt, ob sich der Aspekt „Containerlösung“ tatsächlich verbessert oder nur formell bearbeitet wurde: Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung. Für „Updatepfad“ bleibt dabei verbindlich: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Plattformarchitektur“), für den sie technisch ausgelegt wurde. Statt einer neuen Parallelstruktur genügt zunächst: Datenweg, Identität, Administration und Ausfallverhalten als Gesamtbild prüfen. Der Prüfpfad endet nicht beim Dokument; im vorliegenden Abschnitt wird dies an „Versionswechsel“ konkretisiert. Als Verbindung zwischen Nachweis und Messung dienen: eine freigegebene Architektur mit getesteten Annahmen; die beobachtbare Veränderung beim Aspekt „klare Zuständigkeiten und Entscheidungsrechte“. Eine brauchbare Gegenprobe ist die Frage, ob dieselbe Entscheidung bei einer Störung rund um „Containerlösung“ noch nachvollziehbar wäre.
Aus dem historischen Befund entsteht für „Ausstiegsweg“ eine praktische Steuerungsfrage: Es ist zu klären, welche Zusage technisch, vertraglich oder nur marketingseitig besteht. Beim Schwerpunkt „Ausstiegsweg“ geht es um mobile Plattformen, Container, Apps und ihre betriebliche Einbindung sowie um den Bezug zu „Ausstiegsweg“; zu entscheiden ist, welche technische Abgrenzung dauerhaft administrierbar und herstellerunabhängig genug ist. Die Gegenprobe lautet deshalb: Eine gute Produktfunktion löst nur den Teil des Problems (hier bezogen auf „Geräteverwaltung“), für den sie technisch ausgelegt wurde. Ein schlanker, aber wirksamer Ansatz lautet: Supportdauer, Updateweg, Export und Wechseloption vor Auswahl bewerten. Der Prüfpfad endet nicht beim Dokument; die Umsetzung wird dabei an „Betriebsverantwortung“ gespiegelt. Als Verbindung zwischen Nachweis und Messung dienen: eine Abhängigkeitsübersicht mit realistischem Ausstiegsszenario; Fehlkonfigurationen, Supportaufwand, Updateverzug, Plattformausnahmen und Zeit bis zur Wiederherstellung. Der Diskussionsaspekt „Kosten, Aufwand und eine faire Verteilung“ ergänzt die Betrachtung sinnvoll, weil er „Ausstiegsweg“ mit der tatsächlichen Anwendung verknüpft.
Als Abschluss für Chancen für BYOD genügen drei verbindliche Antworten zu Hersteller-Support: Wer entscheidet über Interoperabilität, woran wird Wirkung bei Updatepfad erkannt und welcher Auslöser führt zur erneuten Prüfung? Sind diese Punkte geklärt, wird aus dem historischen Impuls zu Supportmatrix eine belastbare Arbeitsgrundlage.
| 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.
Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern. Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.
Kommentare 20
Der Beitrag trifft einen wichtigen Punkt. Mich würde interessieren, woran sich der praktische Nutzen des beschriebenen Vorgehens zuerst erkennen lässt. Welche Mindestinformation sollte dafür immer vorliegen?
Ein kleiner Pilot erscheint mir sinnvoll. Wichtig wäre nur, vorher festzulegen, welches Ergebnis als Verbesserung gilt und wer es beurteilt.
Ein konkreter Fall hilft, aber die Zuständigkeit muss von Anfang an klar sein. Sonst ist zwar das Problem sichtbar, die notwendige Entscheidung bleibt aber liegen.
Genau diese Verbindung ist entscheidend: klein beginnen, aber Wirkung und Entscheidungsfolge vorher festlegen. So bleibt der Aufwand vertretbar und das Ergebnis trotzdem belastbar.
Gerade der feste Termin zur erneuten Bewertung ist wichtig. Andernfalls wird aus einer vorläufigen Annahme schnell ein dauerhafter Status.
Das wirft eine praktische Frage auf. 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.
Für mich gehört bei privaten Geräten auch eine kurze Festlegung dazu, wann der gewählte Weg nicht mehr ausreicht. So entstünde aus der ersten Lösung ein belastbarer Lernschritt. Der Maßstab sollte schon vor dem ersten Fall verständlich sein.
Wer trägt beim privaten Gerät eigentlich die Kosten für Support, Reparatur und einen möglichen Ausfall?
Das ist ein wichtiger Punkt. 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.
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: Wer trägt beim privaten Gerät eigentlich die Kosten für Support, Reparatur und einen möglichen Ausfall?
Was müsste bei Supportgrenzen und Kostenverteilung in einer Übergabe unbedingt verständlich dokumentiert sein?
Zweck, Zuständigkeit und offene Punkte sollten zusammen auffindbar sein. Hilfreich wäre außerdem ein konkretes Beispiel dafür, wie mit einer Abweichung umzugehen ist. Für Supportgrenzen und Kostenverteilung würde ich den ersten Prüfschritt bewusst klein halten.
Bei eine nachvollziehbare und im Alltag tragfähige Umsetzung würde ich neben dem Sollzustand typische Ausnahmen betrachten. Gerade dort zeigt sich die Alltagstauglichkeit.
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.
Ich sehe darin vor allem eine Gestaltungsfrage. 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.
Könnte diese Lösung nicht gerade bei kleinen Teams zu viel Aufwand verursachen? Ich würde die Mindestanforderung deutlicher abgrenzen. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Diese Unterscheidung finde ich beim Thema dieses Beitrags besonders wichtig.
Welche minimale Lösung wäre für Supportgrenzen und Kostenverteilung vertretbar, wenn unter Zeitdruck eine Ausnahme erforderlich wird?
Ich würde die Ausnahme befristen und mit einem benannten Verantwortlichen sowie einer späteren Überprüfung verbinden. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Supportgrenzen und Kostenverteilung sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.