Microsoft Teams Telefonie-Governance

1. Management Summary

Microsoft Teams Telefonie-Governance bezeichnet den Ordnungsrahmen für die Telefoniefunktion von Microsoft Teams. Sie umfasst Richtlinien, Prozesse, Rollen und Kontrollen, um den Einsatz von Teams Phone (Cloud-Telefonanlage in Teams) sicher und effizient zu gestalten. Eine solide Governance ist unverzichtbar, um Risiken zu reduzieren und Qualität sowie Compliance sicherzustellen. Ohne klare Leitplanken drohen Missbrauch (z. B. Toll Fraud, also Gebührenbetrug durch unautorisierte Anrufe), Ausfälle in der Erreichbarkeit, Verstöße gegen Datenschutz- und Aufzeichnungsvorschriften, mangelhafte Anrufqualität (z. B. durch fehlendes QoS – Quality of Service) und unkontrollierte Kosten. Mit einer Telefonie-Governance lassen sich hingegen Servicequalität, Sicherheit, Kostenkontrolle, Skalierbarkeit der Lösung und Auditierbarkeit aller Änderungen gewährleisten.

Fünf zentrale Governance-Prinzipien sind: (1) Verantwortlichkeiten klar zuweisen – z. B. durch ein RACI-Modell – damit Entscheidungen schnell getroffen und Maßnahmen konsequent umgesetzt werden. (2) Standardisierte Richtlinien und Prozesse definieren – etwa für Nummernvergabe, Anrufrichtlinien, Notrufe – um einheitliches Vorgehen sicherzustellen. (3) Transparenz und Kontrolle – kontinuierliches Monitoring von Nutzungsdaten und Qualität sowie regelmäßige Audits, um die Einhaltung der Vorgaben zu überwachen. (4) Security & Compliance by Design – Sicherheitsprinzipien (Least Privilege, MFA für Admins, verschlüsselte Kommunikation) und Datenschutzvorgaben von Anfang an integrieren. (5) Kontinuierliche Verbesserung – Governance ist ein lebender Prozess: Kennzahlen werden analysiert, und Richtlinien regelmäßig auf Wirksamkeit überprüft und angepasst.

Fünf Quick-Wins innerhalb kurzer Zeit: (1) In den ersten 30 Tagen: Bestandsaufnahme der aktuellen Telefonie (Nummernbestand, Verträge, Qualitätsprobleme) und Einführung erster Richtlinien, z. B. für Notrufe und Berechtigungen. Sofortmaßnahme: Konfiguration einer Sperrliste für teure Rufnummern, um Missbrauch vorzubeugen, und Einrichtung von MFA für alle Admin-Konten. (2) Bis Tag 60: Implementieren eines geregelten Prozesses zur Nummernvergabe und Portierung, Schulung des Helpdesks in Teams-Telefonie-Grundlagen, sowie Aktivierung von Monitoring-Tools (Call Quality Dashboard) mit ersten Schwellenwerten (z. B. Alarm bei MOS < 3,5). (3) Bis Tag 90: Unternehmensweit die Governance-Prozesse ausrollen – alle neuen Rufnummern und Telefonie-Berechtigungen laufen nun über das definierte Verfahren; Notfallkonzepte sind dokumentiert und getestet; regelmäßige Qualitätsreports und Kostenreports sind eingerichtet. (4) Erste Quick-Win-Optimierungen umfassen außerdem das Bereinigen ungenutzter Telefonie-Lizenzen zur Kostensenkung und das Durchführen eines Notruf-Testanrufs pro Standort zur Risikoerkennung. (5) Zusätzlich kann früh eine Aufklärungskampagne gestartet werden, um Benutzer über neue Wählregeln, Notruffunktionen und Ansprechstellen bei Problemen zu informieren – das schafft Akzeptanz.

Top-5 Risiken ohne Governance sind: (1) Toll Fraud und Missbrauch: Angreifer oder Insider könnten unkontrolliert teure Auslands- oder Premiumnummern anrufen – hohe Kosten und Sicherheitsvorfälle wären die Folge. (2) Ausfall oder fehlende Notfallprozesse: Ohne Redundanzen und Übungen führt ein Ausfall von Teams-Telefonie oder ein missglückter Notruf direkt zu Geschäftsunterbrechung oder Gefahr für Leib und Leben. (3) Compliance-Verstöße: Etwa unerlaubte Aufzeichnung von Gesprächen oder Nichterfüllung von Aufbewahrungspflichten (z. B. von Sprachaufzeichnungen), was zu rechtlichen Sanktionen führt. (4) Schlechte Anrufqualität: Ohne QoS-Vorgaben und Monitoring leiden Nutzer unter Gesprächsabbrüchen und schlechtem Klang – die Akzeptanz sinkt, und wichtige Telefonate (z. B. mit Kunden) wirken unprofessionell. (5) Kostenexplosion: Unkontrollierte Nutzung (z. B. private Auslandsgespräche mangels Policy) oder falsch dimensionierte Verträge führen zu Budgetüberschreitungen.

Als kurze Roadmap für die Governance-Einführung empfiehlt sich ein 30/60/90-Tage-Plan: Nach 30 Tagen sollten grundlegende Policies stehen (z. B. wer welche Anrufe tätigen darf, erster Notfalltest durchgeführt) und eine kleine Governance-Gruppe etabliert sein. Nach 60 Tagen sind Prozesse pilotiert (z. B. Beantragung einer neuen Rufnummer über ein Ticket-System), ein Operator Connect– oder Direct Routing-Pilot mit ausgewählten Standorten läuft, und wichtigste Risiken (Notruf, Toll Fraud) sind technisch mitigiert. Nach 90 Tagen erfolgt der Roll-out in die Breite: alle Standorte halten die Telefonie-Governance ein, regelmäßige Schulungen und Drills laufen, und die Telefondienst-Qualität sowie Compliance werden per Dashboard und Berichten gemessen. Wichtig ist, dass das Management die Initiative trägt und bereichsübergreifend (IT, Netzwerk, Informationssicherheit, Datenschutz, Betriebsrat) verankert – so wird Microsoft Teams Telefonie nachhaltig zu einer sicheren, hochverfügbaren und regelkonformen Kommunikationslösung im Unternehmen.

2. Begriffsbestimmung & Nutzen

Definition: Telefonie-Governance im Microsoft-Teams-Kontext ist die Gesamtheit der strategischen Vorgaben und Leitplanken speziell für die Telefoniefunktionen von Teams (Cloud-PBX). Sie ist Teil der allgemeinen Teams-Governance, setzt aber einen besonderen Fokus auf Sprachkommunikation über das PSTN (Public Switched Telephone Network). Während die allgemeine Teams-Governance z. B. Team-Erstellung, Datenklassifizierung oder Gastzugriff regelt, konzentriert sich die Telefonie-Governance auf Themen wie Rufnummernmanagement, Anrufrouting, Sprachqualität, Notruf-Abwicklung, Gebührenkontrolle und Sprachaufzeichnung. Es geht um die Frage: Wer darf wann wie telefonieren, unter welchen Bedingungen – und wie stellt man organisatorisch und technisch sicher, dass dies sicher und im Einklang mit Vorschriften geschieht.

Gelebte Telefonie-Governance manifestiert sich in verschiedenen Governance-Artefakten: – Richtlinien: Schriftliche Policies, die erlaubte und nicht erlaubte Verhaltensweisen festlegen. Beispiele: eine Policy für ausgehende Anrufe (welche Länder/Nummern sind gesperrt oder nur mit Genehmigung anrufbar), eine Notruf-Policy (welche Schritte sicherstellen, dass Standortinfos vorliegen), oder eine Aufzeichnungsrichtlinie (wer darf Gespräche mitschneiden und unter welchen Auflagen). – Prozesse: Klare Abläufe zur Umsetzung der Richtlinien. Etwa der Prozess zur Zuteilung einer neuen Rufnummer an einen Mitarbeiter (Antrag, Freigabe durch Vorgesetzten, technische Umsetzung, Dokumentation) oder der Prozess, wie bei einem gemeldeten Qualitätsproblem vorzugehen ist (Ticket triagieren, Netzwerkanalyse, Lösungsmaßnahmen). – Rollen & Verantwortlichkeiten: Definition von Zuständigkeiten für alle wichtigen Telefonie-Themen – z. B. Product Owner Telefonie als letztverantwortliche Stelle (Accountable), UC-Administrator als operativ Verantwortlicher (Responsible) für Konfiguration, Netzwerk-Team als Consulted für QoS-Fragen, Datenschutzbeauftragter und Betriebsrat als Consulted/Informed für Aufzeichnungs- und Privacy-Themen. Dieses Rollenmodell wird oft in einer RACI-Matrix festgehalten, um sicherzustellen, dass jeder weiß, wer wofür verantwortlich ist. – Kontrollen: Mechanismen, die die Einhaltung der Richtlinien überwachen. Dies können präventive Kontrollen sein (z. B. technische Limits, die Anrufe zu bestimmten Nummern automatisch blockieren), detektive Kontrollen (Monitoring-Alerts, die ungewöhnliches Anrufverhalten melden) oder korrektive Kontrollen (vordefinierte Maßnahmen, wenn ein Verstoß passiert, etwa Sperrung eines Accounts bei Missbrauch). Zu jeder Kontrolle gehören Evidenzen, also Nachweise – z. B. Protokolle der Notruftests, Audit-Logs von Administrator-Aktionen oder monatliche Reports über internationale Gesprächsminuten – die bei Bedarf geprüft werden können. – KPIs/SLAs: Kennzahlen und Service Level Agreements, anhand derer der Erfolg der Telefonie-Governance gemessen wird. Beispielsweise ein KPI „Anrufqualität (MOS) ≥ 4“ oder ein SLA mit dem Provider über 99,9 % Verfügbarkeit des Telefoniedienstes. Diese Werte werden regelmäßig erhoben und dienen als objektive Kriterien, ob die Governance funktioniert oder nachjustiert werden muss.

Wertbeitrag: Eine wirksame Telefonie-Governance liefert einen hohen Mehrwert für das Unternehmen: – Sicherheit: Sie schützt vor Sicherheitsvorfällen und Missbrauch. Durch Vorgaben wie MFA für Admins, strikte Rechtevergabe und Sperrlisten für teure Rufnummern werden Angriffe und Betrug erschwert. Präventiver Toll-Fraud-Schutz kann potenziell fünf- bis sechsstellige Schadenbeträge verhindern. – Compliance: Governance sorgt dafür, dass rechtliche Vorgaben (Telekommunikationsgesetz, DSGVO, Aufzeichnungspflichten in regulierten Branchen) eingehalten werden. z. B. werden durch definierte Aufbewahrungsfristen für Voicemail-Aufzeichnungen und dokumentierte Einwilligungen der Mitarbeiter für Quality-Monitoring alle Aktivitäten revisionssicher belegt – wichtig bei Prüfungen durch Behörden oder Auditoren. – Servicequalität: Durch Regeln für QoS und Netzwerk sowie ständige Überwachung der Gesprächsqualität steigt der Komfort der Nutzer. Klare Supportprozesse stellen sicher, dass Störungen schnell behoben werden. Benutzer erleben verlässliche Erreichbarkeit und klare Sprachqualität, was die Akzeptanz fördert. – Nutzerkomfort & Produktivität: Telefonie-Governance definiert auch Standards, die den Endnutzern helfen – z. B. ein konsistenter Nummernplan, sodass jeder leicht Durchwahlen findet, oder geregelte Gerätestandards (Headsets, Telefone), die kompatibel und einfach zu bedienen sind. Das reduziert Frustration und lässt die Mitarbeiter effizienter arbeiten (kein Rätselraten bei der Rufnummernwahl, weniger Zeitverlust durch technische Probleme). – Betriebliche Effizienz: Mit dokumentierten Prozessen und Automatisierung (z. B. automatische Zuweisung von Nummern via Skript, Self-Service-Optionen für einfache Änderungen) verringert sich der manuelle Aufwand im IT-Betrieb. Die IT kann mehr Telefonnutzer mit gleichbleibenden Ressourcen betreuen. Durch Standards und Vorlagen werden Onboarding oder Änderungen beschleunigt. – Kostenkontrolle: Die Governance schafft Transparenz über die Telefoniekosten je Nutzer/Abteilung und Mechanismen zu deren Kontrolle. Beispielsweise zeigen regelmäßige Reports die Top-Verursacher von Telefonkosten oder erkennen ungenutzte Lizenzen, die dann eingespart werden können. Zusätzlich verhindert eine klare Berechtigungs- und Sperrensteuerung teure Fehlanrufe (etwa auf Satellitentelefone) und ermöglicht eine optimierte Vertragsgestaltung mit Carriern (z. B. passende Tarifmodelle basierend auf realen Nutzungsdaten). Insgesamt führt das zu messbaren Einsparungen gegenüber ungeregelter Telefonie.

Kurz gesagt: Telefonie-Governance im Teams-Umfeld schafft einen Ordnungsrahmen, der die Einführung von Cloud-Telefonie sicher, compliant und effizient macht. Sie liefert dem Management die Gewissheit, dass die geschäftskritische Kommunikation über Teams jederzeit beherrschbar, transparent und optimiert abläuft.

3. Architekturüberblick Teams-Telefonie

Microsoft Teams Phone bietet verschiedene Anbindungsmodelle ans öffentliche Telefonnetz. Je nach gewähltem Modell unterscheidet sich die Architektur und Verantwortungsverteilung etwas. Die gängigen Calling-Modelle sind:

• Direct Routing: Hier betreibt das Unternehmen (oder ein Partner) einen eigenen Session Border Controller (SBC), der per SIP-Trunk mit einem Telefonie-Provider verbunden ist und auf der anderen Seite mit Teams kommuniziert. Dieses Modell bietet maximale Kontrolle und Flexibilität – man kann jeden Provider weltweit anbinden und auch komplexe Routingregeln, Legacy-Systeme oder Geräte anschließen. Allerdings ist die Einrichtung und der Betrieb anspruchsvoller, da man sich um SBC-Infrastruktur, Zertifikate, Failover etc. selbst kümmern muss.
• Operator Connect: Dabei wählt man einen von Microsoft zertifizierten Telefoniemobilfunk- oder Festnetz-Provider, der eine direkte Kopplung mit Microsofts Cloud eingerichtet hat. Rufnummern und Leitungen kommen vom Provider, aber man verwaltet die Zuteilung der Nummern in Teams Admin Center. Vorteil: kein eigener SBC nötig, geringerer Aufwand – der Betreiber kümmert sich um Skalierung, SIP-Anbindung und teils auch um Notrufrouting. Nachteil: Man ist an die im Operator-Programm verfügbaren Carrier und deren Regionen gebunden; die Kontrolle über tiefere Routingdetails ist begrenzt. Dafür bekommt man oft hohe Verfügbarkeit und Support-SLAs vom Provider.
• Operator Connect Mobile (Teams Phone Mobile): Eine Erweiterung von Operator Connect ins Mobilfunknetz. Hier arbeitet ein zertifizierter Mobilfunkanbieter mit Microsoft zusammen, sodass die SIM-Mobilnummer eines Nutzers zugleich seine Teams-Telefonnummer ist. Anrufe landen parallel in Teams und auf dem Handy. Für den Nutzer ergibt sich eine einzige Nummer für Mobilgerät und Teams-Client. Governance-seitig muss man hier Mobilfunkverträge managen, aber technisch entfällt auch hier ein eigener SBC. Es eignet sich, um Mitarbeiter nahtlos mobil zu integrieren; allerdings muss ein geeigneter Mobilfunkpartner im jeweiligen Land verfügbar sein.
• Microsoft Calling Plans (Anrufpläne): Dies ist die vollständig von Microsoft bereitgestellte PSTN-Lösung. Man kauft von Microsoft ein Minutenpaket oder Flatrate je Benutzer, und Microsoft stellt die Rufnummern und das Telefonie-Gateway aus der Cloud bereit (ähnlich wie ein virtueller Telefonanbieter). Das ist am einfachsten zu administrieren – alles geht über Office 365 – ist aber nur in bestimmten Ländern verfügbar und für große Enterprises oft teurer pro Minute. Außerdem sind Funktionsumfänge etwas begrenzter (z. B. Notruf in Europa erfordert ggf. zusätzliche Konfiguration). Für kleine und mittelgroße Firmen in unterstützten Ländern kann es dennoch attraktiv sein, da kein externer Carrier-Vertrag nötig ist.

Hybrid/Parallelbetrieb: Oft werden diese Modelle kombiniert. Z. B. könnte eine Firma in Ländern, wo Microsoft keine Calling Plans anbietet, auf Direct Routing setzen, aber in anderen Ländern Calling Plans nutzen. Oder Operator Connect Mobile für mobile Mitarbeiter, während Festnetznummern über Direct Routing laufen. Microsoft Teams erlaubt den gleichzeitigen Einsatz mehrerer PSTN-Anbindungsarten im selben Tenant. Ebenso ist in einer Migrationsphase ein Parallelbetrieb von Teams-Telefonie mit der alten TK-Anlage möglich (siehe Szenario 3), um einen gleitenden Übergang zu gewährleisten.

Kernkomponenten einer Teams-Telefonie-Architektur sind:

• Microsoft Entra ID (Azure AD): Das zentrale Identitäts- und Berechtigungsmanagement. Darüber werden Telefonie-Lizenzen zugewiesen und administrativen Rollen vergeben. In Entra ID (vormals Azure AD) sind auch Standorte/Adressen der Nutzer hinterlegt, die für Notruf-Routing relevant sein können. Conditional Access Richtlinien in Entra ID können steuern, unter welchen Bedingungen die Teams-App genutzt werden darf (z. B. nur von verwalteten Geräten oder aus bestimmten Ländern).
• Teams Phone System (Cloud-PBX): Dies ist der cloudbasierte Telefonie-Dienst in Microsoft Teams. Er enthält Funktionen wie Anrufrouting, Voicemail, Warteschleifen, Anrufwartestellung, Audiokonferenzen usw. Aus Architektursicht ist dies eine verteilte Cloud-Plattform – physisch unsichtbar, aber logisch das Herzstück. Alle eingehenden und ausgehenden Anrufe fließen durch das Phone System. In der Teams Admin Center GUI konfiguriert man hier z. B. Dial Plans, Voice Routing Policies, Call Queues und Auto Attendants, die alle in der Cloud umgesetzt werden.
• SBC (Session Border Controller): Im Direct-Routing-Modell ist der SBC die physische/virtuelle Appliance, die zwischen der Microsoft-Cloud und dem Provider-Netz steht. Er termininiert SIP-Trunks vom Carrier und stellt gleichzeitig via TLS/SRTP die Verbindung zu Teams her. Ein SBC kontrolliert die Sprachsitzungen, macht NAT-Traversal, Medienumwandlung und Security (z. B. Schutz vor SIP-basierten Angriffen). Oft ist er redundant ausgelegt. Auch Telefoniegeräte wie analoge Adapter oder konventionelle PBX können am SBC angeschlossen werden, um sie mit Teams zu verbinden.
• Telefonie-Provider / SIP-Trunks: Unabhängig vom Modell braucht man letztlich PSTN-Leitungen. Bei Calling Plans ist Microsoft der Provider. Bei Operator Connect der gewählte Carrier. Bei Direct Routing schließt man einen Vertrag mit einem Telko für SIP-Trunk(s). Diese stellen die Verbindung ins öffentliche Telefonnetz bereit, inklusive Rufnummernblöcken und Notruf-Abwicklung (je nach Land). Der Carrier verantwortet bei Operator Connect und Direct Routing meist das Routing von Notrufen an die richtigen Notrufzentralen und stellt die Erreichbarkeit der Rufnummern aus allen Netzen sicher.
• Nummernplan und Wählregeln: Logischer Bestandteil der Architektur ist das Nummerierungskonzept. Es definiert den Aufbau der internen Durchwahlen, die Zuweisung von externen Rufnummernblöcken an Standorte oder Teams und die einzustellenden Wählregeln (Dial Plans) in Teams. Dial Plans sind Konfigurationen in Teams Phone System, welche gewählte Nummernformate in das kanonische Format (+E.164) umwandeln. Beispiel: Ein Benutzer in München wählt „089 123456“, der Dial Plan fügt automatisch +49 hinzu, sodass +4989123456 gewählt wird. Der Nummernplan und die Wählregeln stellen sicher, dass Anrufe intern wie extern konsistent geroutet werden.
• Endgeräte: Unter Endgeräten fallen Teams-Telefone (dedizierte IP-Telefone mit Teams-App), Headsets, Webcams, Lautsprecher für PC-Nutzer, sowie Konferenzraum-Systeme (Teams Rooms auf Android oder Windows) und ggf. mobile Devices mit Teams-App. Diese Hardware ist integraler Bestandteil, denn sie beeinflusst die Sprachqualität und Nutzererfahrung. Architekturseitig müssen Geräte kompatibel und gemanagt sein – z. B. lassen sich Teams-Telefone und -Panels über das Teams Admin Center inventarisieren, konfigurieren und mit Firmware-Updates versorgen. Geräte müssen in der Netzarchitektur berücksichtigt werden (VLAN-Zuordnung, PoE-Stromversorgung, WLAN-Konfiguration für mobile Teams-Phones etc.).
• Netzwerk & QoS: Das Unternehmensnetz bildet das Fundament für die Sprachübertragung. Für gute Qualität müssen alle Segmente – LAN, WLAN, WAN, Internet – entsprechend ausgelegt sein. Das beinhaltet ausreichende Bandbreite, geringe Latenz (Verzögerung) und stabile Jitter-Werte. QoS (Quality of Service) bedeutet, Sprachpakete gegenüber unwichtigeren Daten zu priorisieren. Architektonisch relevant sind hier Firewalls (müssen die Ports für Teams zulassen), Proxy-Server (sollten für Medienverkehr umgangen werden), ggf. SD-WAN-Appliances (die idealerweise Teams-Verkehr erkennen und bevorzugt routen) und die Internetanbindung jeder Site. Microsoft betreibt weltweit Media Access Edge-Server – das Architekturziel ist, dass Sprachverkehr vom Standort so schnell wie möglich einen dieser Edge erreicht, um Latenz zu minimieren. Daher setzt man oft auf lokalen Internet Breakout pro Standort statt Backhauling aller Calls über eine zentrale Zentrale.
• Monitoring & Telemetrie: Schließlich ist ein Bestandteil der Architektur das Überwachungs- und Analysesystem. Microsoft bietet das Call Quality Dashboard (CQD) in der Cloud, das alle Anrufdatensätze auswertet. Dazu kommen Realtime Monitoring Tools (im Teams Admin Center oder Drittanbieter), die Live-Gesprächsqualität einzelner Anrufe anzeigen. Diese Systeme sammeln Telemetriedaten von Clients und Komponenten. Auch SBCs haben Monitoring (z. B. CDRs – Call Detail Records). Eine robuste Architektur integriert diese Datenquellen in ein zentrales Monitoring-Konzept (z. B. KPI-Dashboards, ggf. SIEM-Anbindung für sicherheitsrelevante Events). So hat man stets Einblick in die Performance und kann bei Abweichungen schnell reagieren.

Zusammengenommen besteht die Teams-Telefonie-Architektur also aus einer Cloud-Plattform (Teams Phone), die via Internet mit entweder eigenen oder Partner-Komponenten (SBC/Carrier) verbunden ist, und die sich bis zum Endnutzergerät und dessen Netzwerk erstreckt. Abbildung 1 (siehe unten) vergleicht die wichtigsten Anbindungsmodelle hinsichtlich Kontrolle, Kosten, Flexibilität, Risiken und internationaler Eignung:

Abbildung: Vergleich der PSTN-Anbindungsoptionen

Diese Architekturentscheidungen werden zu Beginn einer Teams-Telefonie-Einführung getroffen und haben Einfluss auf die Governance (siehe auch Szenario 1 und 2 für Direct Routing vs. Operator Connect im Detail). In der Praxis wählen viele Unternehmen einen hybriden Ansatz: z. B. Direct Routing für komplexe Standorte oder zur Anbindung von bestehenden TK-Anlagen, und Operator Connect für Standorte, wo man schnell und standardisiert in die Cloud-Telefonie gehen will. Wichtig ist, dass die gewählte Architektur den Anforderungen an Kontrolle, Compliance und Verfügbarkeit des jeweiligen Unternehmens entspricht.

4. Governance-Rahmenwerk (Framework)

Eine wirksame Telefonie-Governance basiert auf einem durchdachten Rahmenwerk, das alle Vorgaben hierarchisch einordnet und über den Lebenszyklus hinweg steuert.

Grundprinzipien: Zunächst stützt sich das Framework auf grundlegende Prinzipien (siehe Management Summary), insbesondere Klarheit, Kontrolle, Transparenz, Compliance und Kontinuierliche Verbesserung. Diese Prinzipien werden konkretisiert durch Richtlinien und Prozesse. Jede Entscheidung in der Telefonie (von Rufnummernformaten bis zu Berechtigungen) sollte einem der Prinzipien dienen – z. B. „Least Privilege“ als Prinzip führt zu einer Policy, die Admin-Rechte strikt beschränkt.

Policy-Hierarchie: Ähnlich wie in anderen Bereichen gibt es auch bei Telefonie-Governance eine Hierarchie von Richtlinien: – Übergeordnete Unternehmens-Richtlinien: Allgemeine Vorgaben der IT- oder Kommunikations-Governance, die auch für Telefonie gelten. Z. B. eine konzernweite Sicherheitsrichtlinie, die besagt, dass alle Administratoren MFA nutzen müssen, oder eine Datenschutzrichtlinie, die das Aufzeichnen von Gesprächen nur unter bestimmten Bedingungen erlaubt. Solche Policies bilden den Rahmen, in dem sich die Telefonie-spezifischen Regeln bewegen. – Bereichs-/Abteilungsrichtlinien: Falls nötig, können für bestimmte Bereiche Ausnahmen oder spezielle Regeln definiert werden. Beispielsweise könnte der Kundenservice andere Telefoniezeiten oder Aufzeichnungsregeln haben als andere Abteilungen (etwa um Service-Level zu erfüllen). Diese Bereichspolicies dürfen den Unternehmensrichtlinien nicht widersprechen, sondern konkretisieren sie nur. – Standort- oder Länderrichtlinien: In international tätigen Firmen kommen lokalspezifische Policies hinzu, etwa um gesetzliche Unterschiede zu adressieren. Beispielsweise eine „Notruf-Policy Deutschland“, die regelt, wie standortbezogene Notrufinformationen in DE verwaltet werden (Stichwort: Anschriftenmeldung bei Anbieter), oder eine Policy für „internationales Dialing“, die je nach Land unterschiedliche Sperrlisten hat. Die Standort-Policies sind fein granular und fließen in das technische Dial-Plan-Design ein.

Diese Hierarchie stellt sicher, dass globale Konsistenz gewahrt bleibt, aber lokale Anforderungen erfüllt werden. Alle Policies sollten schriftlich fixiert, versioniert und zugänglich sein. Sie greifen ineinander – bspw. verweist die „Policy Telefonische Aufzeichnung Vertrieb“ auf die allgemeine Compliance-Policy und konkretisiert zusätzliche Maßnahmen für Vertriebs-Telefonate mit Kunden.

Policy-Lebenszyklus: Jede Richtlinie durchläuft Phasen: 1. Design/Erstellung: Anhand identifizierter Risiken oder Anforderungen wird eine neue Policy entworfen. Hier sind oft Fachexperten und Stakeholder eingebunden (z. B. IT und Recht bei einer Aufzeichnungspolicy). 2. Genehmigung: Die Policy wird vom dafür zuständigen Gremium abgesegnet (z. B. IT-Leitung oder ein Sicherheits- und Compliance-Board). Eventuell ist der Betriebsrat beteiligt, wenn mitbestimmungspflichtige Inhalte (z. B. Mitarbeiterüberwachung durch Call-Monitoring) enthalten sind. 3. Rollout/Kommunikation: Die gültige Policy wird den Betroffenen bekannt gemacht – Administratoren erhalten Anweisungen zur technischen Umsetzung, Nutzer ggf. Schulungen oder Hinweise (z. B. „Es werden keine privaten 0900-Nummern mehr durchgestellt“ kommuniziert via Intranet). 4. Betrieb/Enforcement: Die Policy wird im Alltag durchgesetzt. Technische Controls greifen (z. B. das System blockiert unerlaubte Anrufe) und Verantwortliche überwachen die Einhaltung (über Berichte, Feedback). 5. Review/Aktualisierung: In regelmäßigen Abständen (typischerweise jährlich) oder anlassbezogen (neue Gesetzeslage, Vorfall) wird die Policy geprüft. Ist sie noch wirksam? Müssen Schwachstellen behoben werden? Anpassungen werden vorgenommen, und der Zyklus beginnt von vorn.

Durch diesen Lebenszyklus bleiben Policies wirksam und aktuell. Ein Beispiel: Die „Policy Notruf & Standorte“ wird jährlich nach einer Notfallübung überprüft – falls Probleme auftraten, wird sie angepasst (etwa Ergänzung: „nomadisch Arbeitende müssen einmal pro Woche Adresse bestätigen“).

Rollen/RACI-Modell: Damit Governance funktioniert, braucht es definierte Rollen mit Verantwortlichkeiten. Ein RACI-Modell (Responsible, Accountable, Consulted, Informed) ist dabei das Mittel der Wahl, um für alle Kernprozesse klar festzulegen, wer was macht. Typische Rollen in der Teams-Telefonie-Governance: – Product Owner Telefonie (Telekommunikations-Manager): Accountable für den gesamten Telefonieservice. Er genehmigt Policies, entscheidet über Architektur und ist gegenüber Management verantwortlich für Kosten und Qualität. – UC-Engineer / Teams-Telefoniemanager: Meist Responsible für die Umsetzung technischer Änderungen und das operative Management (Nummernzuweisung, Routingkonfiguration, Troubleshooting). Er befolgt die Policies und führt tägliche Aufgaben aus. – Netzwerk-Team: Consulted bei allen Fragen zu QoS, Firewall, Connectivity. Sie verantworten das Datennetz, daher werden sie z. B. bei Qualitätsproblemen einbezogen. Sie setzen auch QoS-Konfigurationen um (Switches/WLAN) und sind Informed über geplante Änderungen, die das Netz betreffen (z. B. neue SBC-Standorte). – Security-Verantwortlicher: Consulted bei sicherheitsrelevanten Themen (z. B. Access Management, Fraud-Detection). Er prüft, ob Policies den Sicherheitsstandards entsprechen. Bei Vorfällen (z. B. auffälliges Anrufvolumen nachts) wird er zur Bewertung hinzugezogen. – Datenschutzbeauftragter: Consulted insbesondere bei Aufzeichnung und bei Nutzung personenbezogener Verkehrsdaten. Er achtet darauf, dass DS-GVO und lokale Telekommunikationsdatenschutzregeln eingehalten werden. Beispielsweise muss er eine Datenschutz-Folgenabschätzung begleiten, wenn flächendeckendes Call Recording eingeführt würde. – Betriebsrat: Informed/Consulted bei Änderungen, die Mitarbeiter betreffen (z. B. Einführung von Quality Monitoring oder Regeln für Erreichbarkeit). Er bekommt Konzepte vorab und kann Anliegen der Belegschaft einbringen. Bei bestimmten Maßnahmen (Aufzeichnung, Auswertung von Telefondaten) ist seine Zustimmung verpflichtend. – Service Desk (First-Level Support): Responsible für erste Anwenderunterstützung und Aufnahme von Störungen. Sie leiten Probleme nach festgelegten Kriterien an UC-Engineers weiter. Sie sind Informed über jegliche Änderungen (z. B. „neues Softphone-Update“, damit sie bei Fragen helfen können). – Provider-Manager: Falls es eine Rolle gibt, die Carrier-Verträge betreut, ist diese Responsible für die Kommunikation mit dem Telefonieprovider (Störungsmeldungen, Kapazitätsanpassungen) und Accountable dafür, dass SLAs mit dem Carrier eingehalten werden.

Eine vereinfachte RACI-Matrix könnte so aussehen:

Dieses Beispiel zeigt: der Product Owner trägt die letztliche Verantwortung (A) für strategische Entscheidungen und muss viele Stakeholder einbeziehen. Die UC-Engineers sind bei den meisten operativen Aufgaben „Responsible“. Das Netzwerk- und Security-Team werden wo nötig konsultiert. So wird vermieden, dass jemand übergangen wird oder dass Verantwortlichkeiten unklar sind.

Kontrollkatalog: Ein wesentliches Element der Governance sind Kontrollen, mit denen die Umsetzung der Policies sichergestellt wird. Ein Kontrollkatalog listet alle relevanten Kontrollmaßnahmen auf, klassifiziert sie (präventiv, detektiv, korrektiv) und ordnet jedem eine Verantwortlichkeit und Dokumentation zu. Beispiele: – Präventive Kontrollen: Implementierung technischer Limits, die Policy-Verstößen vorbeugen. Z. B. das Einrichten von Rufnummernsperrlisten im Dial Plan (blockiert verbotene Destinationen, bevor der Anruf überhaupt rausgeht) – verantwortlich: UC-Engineer; Evidenz: Dial-Plan-Export mit Regelliste. Oder Zugriffsberechtigungen: kein Administrator darf ohne zugewiesene Rolle im Tenant sein (Kontrolle: quartalsweise Abgleich der Adminrollen gegen Vorgaben – verantwortlich: Security Officer; Evidenz: Audit-Report). – Detektive Kontrollen: Monitoring-Mechanismen, die Abweichungen aufspüren. Z. B. ein Alert bei Überschreitung eines Anrufvolumens: Wenn ein Nutzer >1000 Minuten im Monat telefoniert oder um 3 Uhr nachts telefoniert, geht eine Warnung an den Security Officer – verantwortlich für Einrichtung: UC-Engineer; Evidenz: Auszug der Alarmdefinition und Protokoll über ausgelöste Alarme. Weitere detektive Kontrollen: tägliche Prüfung der SBC-Funktion (ggf. automatisierter Testanruf), monatlicher Qualitätsbericht (der Trends aufzeigt), Logging aller Admin-Änderungen (und stichprobenartige Kontrolle dieser Logs). – Korrektive Kontrollen: Vordefinierte Maßnahmen, die bei erkannten Problemen greifen. Etwa Runbooks (siehe später im Anlagenteil) für Szenarien „Toll Fraud Verdacht“ – z. B. „sofort ausgehende Anrufe für betroffenen Account sperren, dann Incident-Management starten“. Oder Korrekturmaßnahmen nach Auditerkenntnissen: z. B. wenn beim jährlichen Notfalltest Mängel auftreten, muss innerhalb 1 Monat ein Verbesserungsplan umgesetzt werden (Owner: Telko-Owner; Evidenz: Maßnahmenplan + erneuter Testbericht).

Jede Kontrolle wird mit einem Nachweis geführt: das kann ein Report, Logfile, Meeting-Protokoll oder Testzertifikat sein. Diese Evidenzen ermöglichen es internen oder externen Prüfern jederzeit nachzuvollziehen, dass Governance nicht nur auf Papier existiert, sondern tatsächlich gelebt wird.

KPIs/SLAs: Das Rahmenwerk definiert auch Key Performance Indicators (KPIs) und ggf. Service Level Agreements (SLAs) zur Messung der Telefoniemqualität und -leistung. Einige wichtige Kennzahlen: – Anrufqualität (MOS): Durchschnittlicher Mean Opinion Score der Gespräche, Ziel z. B. ≥ 4,0. Dieser KPI wird pro Monat und Standort ausgewertet (Quelle: CQD). – Netzwerk-Performance: Latenz, Jitter, Paketverlustraten im Unternehmensnetz für Teams-Verkehr. Vorgabe z. B.: Paketverlust <1 % und Jitter < 20 ms im 95. Perzentil. Überschreitungen lösen Untersuchungen aus. – Verfügbarkeit: SLA mit dem Provider oder intern: z. B. 99,9 % Verfügbarkeit des Telefoniedienstes pro Monat (max. ~45 Minuten Ausfall). Gemessen durch Überwachung des SBC und der Microsoft Service Health. – Support-Metriken: z. B. MTTR (Mean Time to Repair) bei Telefonie-Incidents der Klasse 1 soll < 4 Stunden liegen, oder First Call Resolution Rate im Service Desk > 70 % (d.h. Großteil der Anfragen kann der 1st Level sofort lösen). – Portierungsdauer: Wie lange dauert es, eine Rufnummer von einem alten Provider zu Teams zu portieren? Als KPI z. B. ≤ 10 Werktage durchschnittlich. Diese Kennzahl stellt sicher, dass Prozesse mit externen Beteiligten (Carrier) beobachtet werden. – Nutzer-Zufriedenheit: Durch Umfragen (z. B. quartalsweise) kann ein Score erhoben werden, ob die Mitarbeiter mit der Telefonie-Lösung zufrieden sind. Dies ist ein weicher KPI, aber wichtig für die Akzeptanz.

SLAs werden teils extern vereinbart (mit Carriern, die gewisse Antwortzeiten garantieren, oder mit Microsoft in Form des Online Services SLA) und teils intern (zwischen IT und Management bzw. Fachbereichen als Erwartungswert). Alle KPIs/SLAs sollten im Governance-Dashboard sichtbar sein. So erkennt man früh, wenn z. B. die Anrufqualität an einem Standort abnimmt (vielleicht ist dort die Internetleitung überlastet) – die Governance greift dann proaktiv ein, bevor Nutzer sich beschweren.

Zusammengefasst bietet das Governance-Framework einen klaren Ordnungsrahmen: Von Policies (Was und Warum) über Prozesse/RACI (Wie und Wer) bis zu Kontrollen/KPIs (Wird es eingehalten und erfüllt es die Ziele?). Dieser Rahmen ist die Basis, auf der die folgenden konkreten Szenarien und Richtlinien aufsetzen.

5. Die 10 Governance-Szenarien

Im folgenden Kapitel werden zehn praxisnahe Szenarien beschrieben, die in der Microsoft-Teams-Telefonie häufig auftreten und besonderer Governance-Aufmerksamkeit bedürfen. Für jedes Szenario werden Ziele und Risiken erläutert sowie passende Richtlinien, Prozesse, Rollen, technische Leitplanken, Betriebsaspekte, KPIs und Checklisten vorgestellt.

5.1 Direct Routing mit eigenem SBC (Multi-Standort, HA/DR)

Ziele: In diesem Szenario setzt das Unternehmen auf Direct Routing mit eigenem Session Border Controller. Ziele sind maximale Kontrolle über die Telefonie, die Nutzung bestehender Telefonieverträge (z. B. SIP-Trunks an vielen Standorten) und die Integration von Legacy-Systemen oder speziellen Anschlüssen. Außerdem soll eine hochverfügbare (HA) und desasterresiliente (DR) Architektur realisiert werden: also Ausfallsicherheit durch redundante SBCs und Fallback-Routen, insbesondere bei Multi-Standort-Betrieb. Jeder Standort soll im Fall von Netzwerk- oder Cloud-Problemen möglichst weiter telefonieren können (Stichwort Survivable Branch). Kurz: Das Unternehmen möchte alle Vorteile einer eigenen TK-Anlage in die Cloud retten – global flexibel, aber dennoch unter eigener Regie.

Risiken: Direct Routing bringt Verantwortung mit sich. Ein zentrales Risiko ist Single Point of Failure, falls der SBC nicht redundant ausgelegt ist – fällt er aus oder ist fehlkonfiguriert, sind alle angebundenen Nutzer stumm geschaltet. Auch Konfigurationsfehler (falsche Routing- oder Transformationsregeln) können zu Ausfällen oder Fehlleitungen (z. B. Notruf geht falsch raus) führen. Sicherheitsrisiken: ein offener SIP-Port kann Angriffsfläche bieten (DoS auf SBC oder versuchte SIP Fraud). Multi-Standort-Betrieb birgt Komplexität – z. B. müssen Nummern und Routen standortabhängig korrekt verteilt sein, sonst landen Gespräche am falschen Ort. Ohne sorgfältige Planung drohen außerdem Kapazitätsengpässe (z. B. wenn zu wenige Sprachkanäle dimensioniert sind für Stoßzeiten). Und schließlich obliegt die Einhaltung lokaler Vorgaben (z. B. Meldung von Standorten für Notrufe an Provider) dem Unternehmen selbst – Versäumnisse können regulatorische Probleme verursachen.

Richtlinien: Für Direct Routing braucht es spezifische Policies: – Eine SBC-Betriebspolicy, die regelt, wie der SBC gemanagt wird (Zugriff nur für berechtigte Admins, regelmäßige Firmware-Updates, Backup der Konfiguration) und welche Servicezeiten gelten (z. B. Wartungsfenster nachts). Darin auch: Richtlinie für Zertifikatsmanagement (TLS-Zertifikate des SBC rechtzeitig erneuern etc.). – Routing-Policy pro Standort: beschreibt, welche ausgehenden Anrufe über welchen SBC/Trunk gehen. Z. B. „Standort A nutzt primär SBC Frankfurt, sekundär SBC Zürich“. Ebenso inbound: Falls ein Standort mehr als einen Weg hat, definieren die Policies die Fallback-Reihenfolge. – HA/DR-Policy: Legt fest, welche Redundanzstufen erreicht werden müssen – z. B. „Jeder produktive SBC ist redundant (Active/Standby) ausgelegt; bei Ausfall eines Rechenzentrums übernimmt ein SBC im zweiten Rechenzentrum innerhalb von 1 Minute.“ Diese Policy verlangt auch regelmäßige Failover-Tests. – Security-Policy für SBCs: z. B. „Es dürfen nur von Microsoft zertifizierte SBCs mit aktuellem Sicherheitspatch-Level eingesetzt werden; Admin-Zugang nur per VPN; alle Änderungen via Change-Management.“ Auch ein IP-Whitelist oder geo-locking für SIP-Anmeldung kann Teil davon sein (um Angriffe zu erschweren). – Nummernmanagement-Policy: Da Direct Routing oft mit eigenem Nummernpool arbeitet, sollte eine Policy regeln, wie neue Rufnummernblöcke beschafft und zugewiesen werden. Insb. multi-site: festlegen, welches Schema (z. B. blockweise Zuordnung pro Standort, um regionalen Bezug einzuhalten). – Notruf-Policy (speziell Direct Routing): Hierin wird dokumentiert, wie Notrufe pro Standort zum lokalen PSAP kommen. Oft erfordert das mit dem SIP-Trunk-Provider pro Standort spezifische Routen oder separate Trunks. Die Policy schreibt vor, dass jeder SBC/Trunk Notrufe mit der passenden Standortkennung versieht. Auch: Testintervalle mit jedem lokalen Notrufamt definieren (wenn möglich). – Monitoring-Policy: „Bei Direct Routing ist 24/7-Monitoring Pflicht“ – also definieren, dass SBC Alive-Checks, SIP Options Monitoring etc. aktiviert sein müssen und ein NOC im Problemfall alarmiert wird.

Prozesse: Einige Kernprozesse in diesem Szenario: – Änderungs- und Deploy-Prozess SBC: z. B. Firmware-Update am SBC wird wie folgt gehandhabt: Testsystem zuerst patchen, dann in Wartungsfenster auf Prod-SBC, mit vordefiniertem Rollback. Change muss durch Change Advisory Board (CAB) genehmigt sein, inkl. Betriebsrat-Info falls relevant (eher selten bei techn. Änderungen). – Mehrstandort-Routing einrichten: Ein Prozess, wie ein neuer Standort angebunden wird: Checkliste, ob Bandbreite da, ob ein lokaler Gateway gebraucht wird oder zentraler SBC ausreicht. Konfigurationsschritte: Provider anfragen für Durchwahlblock, SBC-Konfiguration (SIP-Routing nach Durchwahl oder Benutzer-Attribut), Teams Voice Routing Policy anlegen und den Nutzern des Standorts zuweisen. Abnahme durch Testcalls (inkl. Notruf-Test). – Failover-Test Ablauf: Definiert, wie periodisch Redundanz getestet wird. Bsp.: „Halbjährlich simuliert das UC-Team einen SBC-Ausfall: auf SBC1 werden registrierte Teams-Routen deaktiviert, es wird erwartet, dass SBC2 alle Calls übernimmt. Ergebnisse dokumentieren.“ Falls Test scheitert, Incident eröffnen und nachbessern. – Incident Response bei SBC-Ausfall: klarer Prozess, wer was tut, wenn Monitoring Alarm „SBC down“ meldet: Netzwerk-Team prüft zunächst Connectivity, UC-Engineer switcht manuell Routing (z. B. Direct Routing via anderen Standort-SBC leiten, falls möglich), Provider ggf. informieren, Status-Updates an IT-Leitung, usw. – bis hin zur Kommunikation an Benutzer (im schlimmsten Fall). – Nummernportierung im Direct Routing: Falls man Nummernblöcke von einem Provider zum anderen umzieht, muss das gut koordiniert sein. Ein definierter Prozess (auch in Checkliste-Form) hilft: Portierungsantrag -> Freeze für Änderungen -> paralleles Aufschalten neuer Trunk -> Test -> Portierungstag Ablauf (siehe Anlagen). – Konfigurationsänderung Freigabe: z. B. wenn im SBC eine neue Dial Rule eingerichtet werden soll (vielleicht um eine neue Kurznummer intern zu routen), läuft das über ein Change Request: UC-Engineer bereitet vor, Telko-Owner genehmigt, ggf. mit Risikoanalyse, dann Umsetzung außerhalb der Kernzeit.

Rollen/RACI: In Direct-Routing-Umgebungen tritt häufig eine zusätzliche Rolle auf – der SBC-Spezialist oder ein externer Partner (z. B. Systemintegrator). RACI könnte so aussehen: – Der UC-Engineer ist Responsible für SBC-Konfig und Teams-Voice-Routing, während der Telephony Product Owner Accountable bleibt (er trägt die Verantwortung, dass Direct Routing als Service funktioniert und die Rahmenbedingungen erfüllt). – Netzwerk-Team ist Consulted (sie müssen z. B. Firewallregeln setzen, QoS im WAN auf SIP/RTP anwenden). – Provider (externe Carrier) sind quasi außerhalb der internen RACI, aber man definiert Verantwortlichkeiten in SLA mit ihnen: z. B. Provider ist dafür zuständig (Responsible extern) Notrufe ans korrekte PSAP zu leiten, das muss aber in RACI beachtet werden – intern wäre z. B. der Provider Manager Accountable, dass der Provider seine Pflichten erfüllt (überwacht SLA). – Security Officer Consulted bei SBC-Security-Settings (Passwort-Policy, Zertifikate). – Helpdesk Informed: Sie wissen, dass Direct Routing im Einsatz ist und z. B. bei einer Störung evtl. dem Anwender proaktiv sagen können „Ihr Standort X hat gerade einen Carrier-Ausfall – wir arbeiten dran.“

Technische Leitplanken: – Redundanz: Mindestens zwei SBC-Instanzen (geografisch redundant). Möglichst in Active/Standby oder Loadsharing, je nach Hersteller. Außerdem Dual-Homing: Teams Direct Routing ermöglicht, zwei FQDNs als Ziel anzugeben – nutzen! Lokale Survivable Branch Appliances (SBA) an Standorten ohne Backup-Connectivity überlegen: Eine SBA kann bei WAN-Ausfall vor Ort wenigstens interne und PSTN-Anrufe über lokalen Trunk weiter ermöglichen. – Standortabhängiges Routing: In Teams werden Voice Routing Policies erstellt, die je nach Benutzerstandort unterschiedliche SBC-Routen nutzen. Technische Leitplanke: jeder Benutzer muss einem Standort/Usage zugeordnet sein (via Teams Policy oder dial plan rule), damit Anrufe korrekt rausgehen (Beispiel: Mitarbeiter in UK soll über UK-Trunk rauswählen, damit seine UK-Absendernummer angezeigt wird und Notrufe in UK an richtige Leitstelle gehen). – Lokale Medienoptimierung: Für Multi-Standort kann man „Local Media Optimization“ einsetzen: Dadurch kann der SBC Medientraffic lokal halten (Teams-Client verbindet sich direkt mit SBC, ohne Umweg über Microsoft Edge in anderem Land). Dies senkt Latenz; aber muss pro Standort konfiguriert werden. – Kapazitätsmanagement: Pro SBC definieren: max. gleichzeitige Anrufe, und Alerts bei >80 % Auslastung. Gegebenenfalls automatische Overflow-Routen (z. B. falls alle Kanäle belegt, alternative Route über zweiten Trunk). – Dial Plan im SBC vs. Teams: Leitplanke: Entscheidungen, was wo normalisiert wird. Empfehlung: so viel wie möglich im Teams-Dial-Plan abfangen, der SBC sollte idealerweise nur noch E.164 erhalten. Dennoch im SBC Fail2ban: also falls doch seltsames Format ankommt, ein Standardverhalten definieren (z. B. Unrecognized Number -> ans Hauptmenü?). – Security: SBC nur aus definierten IP-Ranges der MS-Cloud erreichbar (Firewall einschränken). Medien-Bypass nur aktivieren, wenn Netzwerk-Vertrauenslevel passt. Logging auf SBC voll anschalten (CDRs, Registrations). Zugriffe aufs SBC-Admin-Interface absichern (IP-Filter, VPN). – Notrufe technisch: Je nach Land muss z. B. im SIP-Invite ein bestimmtes Header-Feld mit Location mitgeschickt werden. Leitplanke: SBC muss dies unterstützen (viele haben Location-Kontext-Funktionen). Teams bietet „Emergency Address“ pro Nummer – sicherstellen, dass pro Nutzer eine Adresse hinterlegt ist, die vom SBC/Provider genutzt wird. Notrufnummern (110, 112, etc.) in SBC separat handhaben – nie ins Ausland routen wegen Toll Bypass Verbot (Notruf muss im Land bleiben). – Monitoring & Tools: Den SBC ins zentrale Monitoring einbinden (SNMP-Traps bei Ausfall, syslogs ins SIEM). Das Teams Direct Routing Dashboard im Admin Center überwachen (es zeigt z. B. Latenz und Paketverlust zwischen SBC und Cloud). – Dokumentation: Aktuelle Netzpläne, SBC-Konfigurationsdokumente, und Portübersichten vorhalten – unerlässlich bei Störung. Leitplanke: Jede Änderung am Routing muss ins Diagramm und Handbuch eingepflegt werden.

Betrieb/Monitoring: – Der laufende Betrieb erfordert 24/7-Monitoring der SBCs und Trunks. typischerweise wird ein NOC oder Monitoring-Tool so eingestellt, dass es SIP Options Pings und Heartbeats überwacht. Wenn ein SBC nicht erreichbar ist oder ein Trunk sich nicht registriert, geht sofort ein Alarm an den Bereitschaftsdienst. – Qualitativ überwacht das Team die Sprachqualität pro SBC – falls z. B. die Latenz zum SBC plötzlich hoch geht, könnte das ein Netzwerkproblem anzeigen. – Wartungsfenster: Betrieb muss sicherstellen, dass SBC-Upgrades koordiniert werden (z. B. ein SBC nach dem anderen, mit Tests). – Logs: Täglich Routine-Checks der Logs (bes. nach nächtlichen Zwischenfällen). Eventuell implementiert man ein Script, das SBC-Logs auf verdächtige Einträge (wie viele 401 Unauthorized, was auf Angriffsversuch hindeuten kann) scannt. – Reporting: Monatlich Kennzahlen: Uptime SBC in %, Anzahl der Calls, evtl. Peak-Kanalauslastung – so kann man Kapazität planen. – Carrier Management: Betrieb umfasst auch den Kontakt mit dem Anbieter: z. B. quartalsweise Traffic-Review mit Carrier (passen Tarife?), sowie schnelles Störungs-Ticket aufmachen beim Provider, wenn mal die öffentliche Telefonie down ist (z. B. Provider-Backbone-Störung). – Tests: nach jeder größeren Änderung (Trunkwechsel, SBC-Update) ein kompletter Regressionstest (eingehend, ausgehend, Sondernummern, Notruf). – Backup: Konfigurations-Backups des SBC mindestens nach jeder Änderung ziehen und an sicherem Ort speichern, damit man bei Crash den Dienst rasch neu hochziehen kann. – Übungen: Der Betrieb sollte DR-Übungen einschließen: Z. B. Notfallszenario „Zentrale SBCs offline“ – was tut man (vorgegeben im Runbook), entsprechende Team-Übung einmal im Jahr.

KPIs: – SBC-Verfügbarkeit: z. B. 99,99 % pro Quartal (max ~13 Min Ausfall). Misst, ob Redundanz greift – jeder ungeplante Ausfall wird gezählt. – Call Success Rate: Anteil erfolgreich aufgebaute Anrufe über den SBC. Ziel z. B. ≥ 99,5 %. Ein Abfall kann auf Routingprobleme hindeuten. – Ausfall-Mean Time to Recovery: Sollte < 30 Min sein (mit Failover oft wenige Sekunden, aber falls beides down, wie schnell fix?). – Notruf Durchlaufzeit: Zeit zwischen Abheben Notruf und Einwahl bei Rettungsleitstelle – indirekt gemessen falls möglich oder qualitativ per Test. Sollte nominell < 30 Sek. liegen. – Anzahl Security Incidents SBC: z. B. 0 kompromittierte Versuche (Ziel: null), ggf. die Zahl abgewehrter Angriffe protokollieren. – Nutzerzufriedenheit: In so einem technischen Szenario äußert sich Zufriedenheit darin, dass Benutzer keinen Unterschied zur alten Anlage merken (KPI: “User complaints wegen Telefonie” pro Monat, Ziel: nahe 0). – Kosten-KPI: Verbindungskosten pro Minute vs. Plan – in Direct Routing kann man Bulk-Carrier-Preise erwarten, KPI könnte sein: durchschnittliche Kosten ct/min aller Calls und diese beobachten.

Checkliste: (Auszug für dieses Szenario) – Architektur-Check: Sind mindestens zwei SBCs eingerichtet und getestet (JA/NEIN)? Haben alle Standorte definierte Primär-/Sekundärrouten (Dokument vorhanden)? – Konfiguration: Wurden alle relevanten Rufnummern dem richtigen SBC/Trunk zugeordnet? Stimmt das Calling Number Format (E.164) vom SBC aus? – Security: Ist TLS-Zertifikat auf SBC gültig und stark (SHA-256)? Sind Standard-Accounts am SBC gelöscht oder Passwörter geändert? Ist die neueste Firmware installiert? – Notruf: Für jeden Standort: Ist im SBC eine Route für 112/110 konfiguriert, die den richtigen Absendekreis nutzt? Wurden Notrufe testweise erfolgreich durchgeführt (Protokoll vorhanden)? – Monitoring: Sind SNMP-Traps oder API-Monitoring für SBC aktiv? Alarmwege definiert (wer wird nachts geweckt)? – Backup & Recovery: Existiert ein aktuelles SBC-Konfig-Backup (offline verfügbar)? Wurde das Restore schon mal geübt auf Testsystem? – Dokumentation: Netzwerkdiagramm mit SBC, IPs, Ports vorhanden? Dial Plan und Voice Routing Tabellen aktuell abgelegt? – Carrier-Verträge: Ist sichergestellt, dass bei Carrier-Ausfall (z. B. Großstörung) ein Fallback (zur Not über Mobiltelefone) im Notfallhandbuch steht? Und SLA mit Carrier bekannt (z. B. 4h Repair)? – Changes: Wurden alle kundenspezifischen Anpassungen (z. B. Kurzwahl der Geschäftsleitung) im SBC + Teams dokumentiert, damit sie bei Update nicht verloren gehen? – Go-Live readiness: Vor dem Einschalten – Check final: Benutzer getestet (eingehend, ausgehend), Voicemail getestet, Fax/Modem (falls angeschlossen) getestet? Abnahme durch Fachseite erfolgt?

Mit dieser robusten Governance für Direct Routing kann ein Unternehmen die Volle Kontrolle über seine Teams-Telefonie behalten, ohne der Komplexität zum Opfer zu fallen. Wichtig ist laufende Disziplin in Wartung und Monitoring – dann bietet Direct Routing eine flexible, skalierbare Lösung, die selbst große Multinationals mit heterogener Infrastruktur meistern können.

5.2 Operator Connect & Operator Connect Mobile

Ziele: Beim Operator Connect-Modell lagert man einen Großteil der Telefonie-Infrastruktur an einen zertifizierten Betreiber aus. Ziele sind hier vor allem Betriebsvereinfachung und schnelle Skalierbarkeit: Das Unternehmen möchte auf eigene SBCs verzichten und stattdessen über die Cloud-Integration eines Providers Telefonie erhalten. Dadurch entfallen aufwendige Tasks wie SBC-Patching oder SIP-Trunk Tuning – der Fokus kann auf dem Zuweisen von Nummern und Qualitätssicherung liegen. Zudem kann Operator Connect die Multi-Länder-Telefonie vereinfachen, da manche Anbieter globale Nummernportfolios anbieten. Im Fall von Operator Connect Mobile (jetzt oft „Teams Phone Mobile“ genannt) ist ein weiteres Ziel, den Mitarbeitern eine einzige Telefonnummer zu geben, die sowohl auf ihrem Mobiltelefon als auch in Teams klingelt. Das erhöht die Erreichbarkeit und vereinfacht die Kommunikation (One-Number-Konzept), was gerade für Außendienst, Rufbereitschaften oder flexible Arbeitsformen attraktiv ist.

Risiken: Obwohl Operator Connect viel abnimmt, gibt es Risiken: – Abhängigkeit vom Provider: Man begibt sich in gewisse Lock-In-Situationen. Wenn der gewählte Carrier Probleme hat oder nicht die erwartete Qualität liefert, ist ein Wechsel zwar möglich, aber nicht so trivial wie intern an einer Schraube zu drehen. Ein Providerwechsel erfordert Portierung aller Nummern, was Aufwand und potentielle Downtime bedeuten kann. – Weniger Kontrolle über technische Details: Man ist auf die korrekte Umsetzung des Carriers angewiesen, z. B. bei Notrufen (der Operator muss Standorte korrekt hinterlegen) oder bei CLIP no screening (der Operator muss erlauben und konfigurieren, welche ausgehenden Nummern signalisiert werden dürfen). Fehler oder Verzögerungen dort kann das Unternehmen kaum direkt beheben. – Koordination & Rollenvermischung: Mit dem Carrier entsteht eine geteilte Verantwortlichkeit. Unklare Schnittstellen können zu Problemen führen („Ist es ein Teams-Problem oder ein Netzproblem des Providers?“). Bei Störungen besteht das Risiko von „Ping-Pong“ zwischen Microsoft und Operator, was Reaktionszeiten verlängert. – Mobil-Integration Risiken: Operator Connect Mobile bringt Mobilfunk hinein. Hier muss man sicherstellen, dass etwa Handovers (Übergabe eines Handygesprächs in ein Teams-Meeting) funktionieren. Auch datenschutztechnisch: Der Mobilfunkbetreiber verarbeitet ggf. mehr Verbindungsdaten. – Skalierungsgrenzen: Wenngleich Operator Connect sehr skalierbar ist, kann man an die Grenzen stoßen, z. B. wenn man exotische Länder braucht, die kein Partner abdeckt. Oder falls das Unternehmen sehr individuelle Anforderungen hat (Sonderdienste, interne Kurzwahlen), die sich im starren Provider-Framework nicht abbilden lassen. – Portierungsaufwände: Beim initialen Umstieg müssen alle Nummern zum Operator portiert werden – das will gut gemanagt sein, um keine Unterbrechung zu haben (siehe Checkliste). – Kostenrisiko: Theoretisch kann ein Operator plötzliche Preisänderungen vornehmen oder teurere Taktungen haben. Da man voll auf sie setzt, hat man weniger Hebel bei Preiserhöhungen – man sollte also lange Vertragsbindungen oder Preisprotektoren aushandeln.

Richtlinien: – Provider Governance Policy: Gibt vor, wie mit dem Operator zusammengearbeitet wird. Z. B. muss es definierte SLAs geben (Antwortzeit Support, Verfügbarkeit 99,9 % etc.), die in der Policy aufgeführt sind. Ebenso eine interne Eskalationsmatrix beim Provider: z. B. „Wenn Major Incident > 4h dauert -> Provider Account Manager informieren“. – Rollen-& Verantwortungs-Policy (intern/extern): Darin wird festgelegt, was der Operator zu leisten hat und was intern geleistet wird. Bsp.: „Rufnummern neu bestellen: intern (Telekom-Admin) erstellt im Operator-Portal einen Auftrag; Operator liefert Nummer binnen 2 Werktagen.“ Oder: „Notruf-Standortverwaltung: Operator übernimmt (gemäß Vertrag), intern stellt aber sicher, dass alle Adressdaten in dessen Portal aktuell sind.“ So eine Policy verhindert Grauzonen. – Nummernverwaltungs-Policy (speziell Operator Connect): Hier wird u. a. geregelt: Alle Rufnummern werden zentral im Teams Admin Center verwaltet (die Operator Connect Integration synchronisiert verfügbare Nummern). Kein Standort darf eigenmächtig am Provider vorbei Nummern ordern. Wenn Nummern nicht mehr gebraucht werden, sind sie gemäß Policy aus Teams zu entfernen und im Providerportal frei zu geben, um Kosten zu sparen. – Wechsel-/Exit-Policy: Da Lock-in droht, hat man idealerweise eine Policy, die einen Plan B adressiert. Z. B.: „Für jede Operator-Connect-Route soll ein alternativer Connect-Anbieter identifiziert sein; im Fall schwerer SLA-Verstöße bereitet das Team innerhalb 4 Wochen einen möglichen Wechsel vor.“ Das klingt theoretisch, aber wichtig: Es verhindert, dass man betriebsblind wird. – Mobile Usage Policy: Falls Operator Connect Mobile genutzt: definieren, wer einen Teams Phone Mobile SIM bekommt (vielleicht nur Außendienst). Und Regeln: z. B. „BYOD vs COPE“ – darf die SIM ins Privatgerät? Oder stellt Firma Diensthandys? In vielen Fällen wird man aus Governance-Sicht COPE (Corporate Owned, Personally Enabled) bevorzugen, um Kontrolle über die Mobilnummer zu behalten. Diese Policy sollte auch Sicherheitsaspekte des Smartphones regeln (PIN, Fernlöschung etc. – meist via Intune). – CLIP/CLIR Policy mit Operator Connect: Oft bieten Operatoren in ihrem Portal Einstellungen für ausgehende Nummern. Hier legt eine Policy fest: Standardmäßig darf nur die eigene DDI angezeigt werden; Ausnahmen (Anzeige Hauptnummer für Abteilung XY) müssen vom Telko-Owner genehmigt und vom Provider eingerichtet sein. So verhindert man Wildwuchs, wer was nach außen signalisiert. – Notruf-Policy (gemeinsam mit Operator): Operator Connect entbindet nicht von Notrufvorsorge. In der Policy sollte stehen, dass z. B. vierteljährlich ein Datenaustausch mit dem Carrier erfolgt, um sicherzustellen, dass alle Adressen für Notrufe stimmen. Manche Provider verlangen, dass man jedem Nutzer im Portal eine Notfalladresse zuordnet – das muss polizeilich als Pflicht etabliert sein („Kein Nutzer ohne hinterlegte Emergency Address“).

Prozesse: – Onboarding neuer Standort/Nummer via Operator: Prozess: interner Admin bestellt im Providerportal neue Nummern (oder portiert existierende); anschließend werden die Nummern in Teams Admin Center sichtbar und dem Standort zugeordnet. Hier braucht es Checkpoints: hat der Provider die richtigen Ortsvorwahlen verwendet? Wurden die Nummern in E.164-Format in Teams importiert? Der Prozess endet mit Testcalls von und zu einer neuen Nummer. – Störungsmanagement: Klare Prozedur, wie bei Anrufstörungen vorzugehen ist. Z. B. erst interne Prüfung (liegt es an Teams-Config?), dann ggf. Ticket beim Operator aufmachen mit allen relevanten Infos (Bsp: bestimmte Zielrufnummern nicht erreichbar – eventuell Routingfehler beim Carrier). Dieser Prozess enthält Eskalationsstufen, falls der Provider nicht reagiert: nach X Stunden Support-Hotline anrufen, nach Y Stunden Account Manager einschalten usw. – SIM-Karten-Management (bei Mobile): Prozess, wie SIMs ausgegeben, verwaltet und zurückgenommen werden: z. B. HR meldet neuen Außendienstler -> IT bestellt beim Mobilfunkpartner eine eSIM -> hinterlegt diese im Entra ID Profil via Attribut (wenn Integration da) -> testet, ob Anrufe in Teams auftauchen. Und Offboarding: wenn Mitarbeiter geht, SIM deaktivieren/neu zuweisen. Das alles muss fließen, da Mobilnummern recht kritisch sind. – Änderungsprozess beim Operator: Alle paar Monate ändern sich evtl. Anforderungen (z. B. man möchte zusätzliche Service-Rufnummern einrichten). Der Prozess: Telko-Owner genehmigt, Admin beantragt im Portal, Testphase, dann Nutzern bekanntgeben. – Provider-Wechsel oder Fallback-Prozess: Falls der Operator Connect Provider längerfristig ausfällt (z. B. große Netzstörung), gibt es notgedrungen ein Notfallszenario: z. B. temporär Teams Calling Plan als Überbrückung für kritische Nutzer aktivieren. Das sollte als Process Outline im Notfallhandbuch stehen. Auch wie man nach Providerwechsel alle Nummern synchronisiert und testet, muss vorgeplant werden (damit im Krisenfall Stunden statt Tage benötigt werden). – Service Request (intern): Wenn ein Fachbereich neue Nummern oder Funktionen braucht, geht das wie? Operator Connect bedingt z. B. oft, dass man über IT (die Portalzugriff hat) die Wünsche abwickelt. Ein definierter Service Request Prozess (via Ticketsystem) hilft: „Abteilung beantragt neue Hotline-Nummer => Telephony Admin prüft, genehmigen durch PO => Order im Portal => Config Call Queue => Rückmeldung mit Durchwahl an Abteilung“.

Rollen/RACI: – Provider (extern): Der Operator ist quasi Responsible für den Betrieb der PSTN-Gateway-Funktion und die Rufzustellung, Accountable im Sinne seiner SLA. Intern wird ihm aber im RACI ein Owner zugeordnet, z. B. Provider Manager (IT-Telekom-Einkauf), der Accountable dafür ist, dass der Provider seine Leistung bringt (er managt den Vertrag). – Telephony Admin (intern UC-Team): Responsible für alle Konfig in Teams und im Provider-Portal (z. B. Nummernzuweisung, Routing im Teams Admin Center). – Telephony Product Owner: Accountable für die End-to-End Telefonie inkl. Provider. Er hält den Kontakt auf Management-Ebene zum Operator (z. B. regelmäßige Service-Review Meetings). – Security/Datenschutz: Consulted um sicherzustellen, dass z. B. im Vertrag mit dem Operator alle Datenschutzauflagen (Auftragsverarbeitung etc.) erfüllt sind. Auch muss Security absegnen, dass Logging etc. ausreichend ist (beim Operator Connect hat man z. B. nur begrenzt CDR-Einsicht – hier abwägen, ob das reicht). – Netzwerk-Team: Hier oft Informed nur, weil im Unterschied zu Direct Routing das Thema SIP-Verkehr intern minimal ist (Clients gehen direkt ins Internet). Außer man nutzt ExpressRoute – aber MS empfiehlt das nicht für Medien. Daher Netzteam nur involviert bei genereller Internet-Performance. – Betriebsrat: Eher Informed, z. B. dass Mobilintegration kommt (weil Mitarbeiter dann ggf. in Freizeit auch auf Teams-Nummer angerufen werden könnten, was wieder ein Betriebsrats- und Arbeitszeitthema ist – muss in Betriebsvereinbarung zu Erreichbarkeit geregelt sein). – User & Abteilungsleiter: Als Stakeholder, z. B. Consulted falls Fachbereiche spezielle Anforderungen an den Operator Connect haben (etwa vorhandene VIP-Nummern, die portiert werden müssen – hier ist die Fachseite mit im Boot). – Microsoft Support: Indirekt, aber relevant: Bei Operator Connect hat man MS-Seite plus Provider. Der interne Admin sollte wissen, wann er Microsoft einschaltet (wenn Problem offenbar in Teams-Layer) vs. wann den Operator (wenn z. B. alle Teams-User okay sind, aber PSTN tot). Hier klare Abgrenzung definieren.

Technische Leitplanken: – Tenant-Verknüpfung: Sicherstellen, dass im Teams Admin Center der Operator Connect Anbieter erfolgreich verknüpft wurde (OAuth etc.). Das ist die Grundvoraussetzung – Leitplanke: regelmäßiger Check, dass die Verbindung „Healthy“ ist. – Nummernformat und Portierung: Alle Rufnummern sollten als +E.164 im Tenant erscheinen. Leitplanke: beim Portieren keine Formatverluste. Der Operator stellt typischerweise die Nummern mit Landesvorwahl bereit – interne Konvention: Nummern in Teams nie mit führender 0 speichern, immer +Land… – Telefonbucheinträge: Nach Portierungen können Änderungen im öffentlichen Telefonverzeichnis (DB) nötig sein. Leitplanke: Der Provider sollte das übernehmen (viele melden portierte Nummern an Notruf und Verzeichnisse). – Quality of Service: Hier verlagert sich Qos-Überwachung Richtung Internet. Leitplanke: Der Operator hat direkte Peering zu Microsoft – das ist Standard in dem Programm. Das Unternehmen sollte aber seine Internet-Egress-Punkte im Blick behalten. Evtl. definieren: Jede Standort-Internetleitung muss genügen Bandbreite für X gleichzeitige Gespräche haben (z. B. 100 Anrufe à 100 Kbit = 10 Mbit Reserve). Also Bandbreiten-Leitplanke pro Standort. – Dial Plans: Bei Operator Connect definieren die Provider meist das Rufnummernformat (z. B. man kann in Teams wählen wie gewohnt, Teams normalisiert – der Operator erwartet E.164). Leitplanke: Team-interne Dial Plan so konfigurieren, dass er die vom Provider geforderten Wahlregeln erfüllt. Oft ist das trivial (+E.164), aber z. B. Notrufe: Microsoft leitet bei Operator Connect Notrufe idR. über den Operator; man muss in Teams nichts Besonderes tun außer Standorte definieren. – Mobile Integration – Technik: Leitplanke: Der mobile Nutzer sollte in Entra ID/Teams eindeutig markiert sein. Der Operator verknüpft i.d.R. die SIM mit dem AAD-Account. Hier muss sichergestellt sein, dass keine Dubletten oder falsche Zuordnung passiert (z. B. wenn jemand Handy tauscht). – Parallel Ring & Voicemail: Bei OCM (Operator Connect Mobile) kann ein Anruf gleichzeitig auf Mobil und Teams klingeln. Leitplanke: Verhindern, dass beide gleichzeitig Voicemail rangehen – typischerweise steuert der Operator das. Aber in Teams sollte für diese User die Teams-Voicemail bevorzugt oder eine Koordinierung mit Mobilbox erfolgen (manche Operatoren koppeln die Mobilbox mit Teams). – Zertifizierungen: Der gewählte Operator Connect Partner sollte zertifiziert sein – Leitplanke: Nur offiziell gelistete Partner nutzen, keine „halb-offiziellen“ Integrationen, da diese Support und Sicherheit gefährden. – Firewall/Network: Weniger zu tun als bei SBC, aber falls interne Firewalls sehr restriktiv sind: sicherstellen, dass Teams-Client Verbindungen zu Operator-Edges (die in MS Cloud eingebunden) aufbauen darf. In der Regel benutzt Teams hier auch Standard-Ports (die gleichen wie sonst, 3478 UDP usw.), daher keine Sonderregeln nötig. – Verfügbarkeitskonzept: Häufig hat ein Operator Connect Partner Redundanzen – aber man sollte es verstehen: z. B. hat er mehrere SIP-Gateway-IPs? Falls ja, stellt Teams das automatisch ein. Leitplanke: Intern dokumentieren, welche Redundanzlevel existieren (z. B. Knoten Frankfurt und London – fällt einer aus, geht’s weiter). So kann man bei Störung schneller gezielt nachfragen. – Datenstreams: Was liefert der Operator an Telemetrie? Evtl. ein Kundenportal mit CDRs und Qualitätsreports. Leitplanke: Zugang dazu einrichten und regelmäßig Daten ziehen (möglich, dass man es mit PowerBI oder so integrieren kann). – Backup-Festnetz: Wenn mobiles Internet ausfällt, ist Teams tot, aber bei OCM kann man immer noch über GSM telefonieren – das ist ein Vorteil. Andersherum: Wenn Microsoft Cloud ausfällt, funktionieren GSM-Anrufe immer noch (Team-Fallback ist dann Handy). Governance sollte definieren: In solchem Fall sind Mitarbeiter angewiesen, klassisch zu telefonieren (mobil). – Nummernportierung Speed: Leitplanke: mit dem Operator Service Level vereinbaren, dass Portierungen in Massen gut gemanagt werden (ggf. Pilot vor Massenportierung). – Aufbewahrung & Recording: Falls man Compliance Recording hat, muss geklärt: Operator Connect Streams können von zertifizierten Recording-Lösungen auch abgegriffen werden (ja, über Teams compliance recording). Aber bei Mobilteilen? Evtl. nicht, wenn der Call rein auf Mobil läuft (in dem Fall wird er an Teams ja vorbeigeschleust). Leitplanke: In der Policy definieren, dass relevante Gespräche via Teams App geführt werden sollen, damit Recording greift, oder entsprechende Partnersysteme suchen, die Mobilfunkrecording anbieten.

Betrieb/Monitoring: – Der laufende Betrieb ist hier eher Carrier-Management: Tägliche Prüfung der Operator Connect „Health“ im Teams Admin Center (es gibt dort Indikatoren, z. B. ob Trunks verbunden). – Ticketsystem: Der Helpdesk sollte in der Lage sein, einfache Telefonieprobleme (bes. Einzeluser, z. B. kann nicht telefonieren) zu lösen: oft liegt es an Lizenz oder fehlender Nummer. Komplexeres (ganzer Standort offline) geht sofort an den Operator, aber Team muss Verifikation machen („ist Internet vor Ort ok?“, „Teams-Services ok?“). – Provider SLA Tracking: Betrieb führt ein Log, ob der Operator seine SLAs einhält – z. B. Reaktionszeiten und Fixzeiten messen (ist der Carrier in >90 % der Fälle innerhalb 15 Min in Bearbeitung etc.?). Das wird in regelmäßigen Service-Meetings besprochen. – Nummernhaushalt: Monatlich checken: wie viele Nummern sind belegt vs. im Vertrag gekauft? Ungenutzte ggf. zurückgeben, damit keine unnötigen Kosten. – Abrechnung: Der Betrieb muss i.d.R. Verbindungsnachweise vom Provider bekommen (besonders falls Flatrate-Limits überschritten wurden, etc.). Diese Auswerten (gehört auch zu Monitoring der Kosten). – Qualität: Die Teams Qualitätsdaten bleiben relevant. Wenn es vermehrt Probleme gibt (z. B. Gesprächsabbrüche), muss man herausfinden, ob’s am Operator liegt. Der Provider kann oft eigene Reports (Paketverlust auf seiner Strecke etc.) liefern. Hier also enges Monitoring: Wenn an einem Standort alle Anrufe Pixeling haben, sofort Provider checken lassen (vielleicht dort Routenproblem). – Mobile Geräte Support: Im Betrieb muss geklärt sein: Wenn ein user mit Teams Phone Mobile sagt „ich habe keinen Empfang“ – dann klassisches Mobilfunkproblem, ab zum Mobilprovider (oft identisch mit Connect-Provider). Oder „Anrufe kommen nicht in Teams an aber Handy klingelt“ – könnte Konfigproblem (dann UC-Team) oder Mobil-Datenproblem (Netz). Also Support Use-Cases definieren und staff schulen. – Backup-Wege: Der Betrieb hält vielleicht ein paar Calling Plan Lizenzen in der Hinterhand. Sollte der Operator ausfallen, könnte man damit VIPs temporär PSTN-Fähigkeit direkt via MS geben. Das Monitoring muss aber so ein Ausfall überhaupt erkennen: Das sieht man z. B. im Admin Center: Trunk down. Oder massenhaft PSTN calls failing. Muss ge-alarmt werden.

KPIs: – Provider SLA Einhaltung: z. B. % der Störungen, die innerhalb der vertraglichen Zeit gelöst wurden (Ziel 100 %). – Anrufqualität extern: Da Operator Connect auf Provider-Seite auch QoS beeinflusst, misst man z. B. MOS extern (Ziel identisch >4,0). Falls es Abweichungen zu internen calls gibt, Indikator. – Beschaffungszeit neue Nummern: KPI: Durchschnittsdauer vom Anfordern bis nutzbar in Teams (Soll z. B. ≤ 3 Tage). – Kosten pro User/Monat Telefonie: um zu sehen, ob Operator-Modell wirtschaftlich im Rahmen bleibt (ggf. Vergleiche). – First-Time-Fix Rate Provider: Wurden Störungen gleich beim ersten Call mit Provider gelöst (>90 % Ziel, sonst hapert es). – Verfügbarkeit PSTN Service: Zeit, in der der Operator-Dienst erreichbar war (Ziel oft 99,9 %). Hier fließt euer Monitoring-Resultat ein. – Umschaltzeit Mobil/Teams (OCM): Falls relevant, kann man qualitativ messen, wie gut das mobile Handover klappt (Zufriedenheit der Nutzer, qualitatives KPI). – Nutzerfeedback: Gerade bei mobil integrierten: „Sind Sie zufrieden mit One Number?“ Ein Score aus Umfrage.

Checkliste: – Vertrags-Setup: Ist der Vertrag mit dem Operator vollständig (inkl. Datenverarbeitung, SLA-Anhang) unterschrieben? Zugangsdaten zum Kundenportal erhalten? – Tenant-Verbindung: Wurde der Operator im Teams Admin Center verbunden (Testanruf erfolgreich)? – Rufnummern: Sind alle bestehenden Nummern portiert oder neu zugewiesen? Wurden wichtige Sondernummern (Fax, Alarme falls via Operator? – typischerweise separat) berücksichtigt? – Notfall-Adressen: Wurden für jeden Benutzer/Standort die korrekten Notfalladressen im Operator-System hinterlegt? – Benutzerzuteilung: Haben alle betreffenden Benutzer eine Telefonie-Lizenz UND eine zugewiesene Operator-Nummer? (Check per Powershell: All VoiceUsers have Number?). – Test Matrix: Ausgehender Anruf test: Benutzer -> externes Netz (in jedes relevante Ziel: Lokal, Mobil, Ausland)? Eingehend: extern Handy -> alle wichtigen Durchwahlen (insbesondere Gruppen wie Zentrale)? Qualität dabei okay? – Mobil-Integration: Falls OCM: Ein Testhandy hat die eSIM, bekommt es Anrufe? Kann man via GSM an Teams-Besprechung „hochziehen“ (Uplift)? Funktioniert die Präsenzanzeige (viele OCM zeigen in Teams an, wenn man am Handy telefoniert)? – Voicemail/Anrufbeantworter: Stellen sicher, dass die Teams-Voicemail einspringt. Evtl. mobiles Voicemail synchronisiert? Test: wenn Teams-App offline, Anruf an SIM -> landet wo? – Monitoring eingerichtet: Sind Cloud Service Health Alerts für „Operator Connect“ Komponente abonniert? Hat man Anbieterstatus-Seite? Intern Alarm falls z. B. >X gescheiterte Anrufe/Stunde. – Schulung: Haben Support-Mitarbeiter Unterlagen, wie sie typische OC-Probleme identifizieren (z. B. Ausfall = Check Admin Center->Operator Status)? Haben Benutzer Info, falls anfangs Umstellung (z. B. „Ihre Nummer wechselt am 5.5. zu neuem Provider, kurze Unterbrechung möglich“)? – Fallback: Notfallplan verfügbar? z. B. Liste wichtiger Kontakte mit Handy-Nummer falls Cloud ausfällt. – Daten & Privacy: Ist den Nutzern kommuniziert, dass bei Teams Phone Mobile evtl. Anrufmeta über Mobilfunk fließen (Datenschutz-Hinweis)? – Abrechnung: Wurden Billing-Zyklen und Referenzen geklärt (z. B. Operator schickt Rechnung an Buchhaltung, IT bekommt Kopie)? – Go-Live genehmigt: Abschließend: Abnahme durch Fachbereiche? Ggf. Betriebsrat Info?

Mit Operator Connect setzt man auf eine enge Partnerschaft mit einem Dienstleister. Die Governance in diesem Szenario sorgt durch klare Absprachen, Prozesse und Monitoring dafür, dass man trotz Auslagerung der Technik die Zügel in der Hand behält und Service und Compliance garantiert sind.

5.3 Hybrid-Migration von Legacy-TK zu Teams (Parallelbetrieb, Fallback, Sonderdienste)

Ziele: Unternehmen mit bestehender Legacy-Telefonanlage (z. B. Avaya, Cisco, Unify) wollen meist schrittweise zu Teams Phone migrieren, ohne die Erreichbarkeit zu verlieren. Ziel dieses Szenarios ist eine nahtlose Migration: Parallelbetrieb der alten TK-Anlage neben Teams für eine Übergangszeit, reibungsloses Portieren der Rufnummern in Etappen, und Fallback-Möglichkeiten, falls Teams noch nicht stabil läuft oder bestimmte Funktionen (noch) nicht abgebildet werden können. Zusätzlich müssen Sonderdienste (Fax, Alarme, Türsprechstellen, etc.) berücksichtigt werden, damit nichts „vergessen“ wird. Im Idealfall merkt der Endkunde nicht, dass im Hintergrund Stück für Stück die Telefonieplattform wechselt – es soll kein Stillstand oder Unterbrechung auftreten.

Risiken: Eine Migration ohne ausreichende Planung birgt erhebliche Risiken: – Kommunikationsausfall: Wenn Nummern portiert werden und z. B. die Teams-Konfiguration nicht passt, können Anrufe ins Leere gehen. Ein Fehler bei der Portierung (falscher Portierungstag oder Fehlschlag) kann zur Unerreichbarkeit wichtiger Durchwahlen führen. – Isolierte Inseln: Während Parallelbetrieb könnte es sein, dass ein Teil der Mitarbeiter auf Teams ist, der andere auf der alten Anlage – interne Durchwahlcalls zwischen diesen könnten nicht funktionieren, wenn keine Kopplung besteht („Zwei Telefonwelten, die nicht sprechen“). Das beeinträchtigt interne Kommunikation und erzeugt Verwirrung („Welche Nummer rufe ich jetzt an?“). – Benutzerverwirrung: Bei unsauberer Kommunikation kann es passieren, dass Nutzer zwei Telefone/Softphones auf dem Tisch haben und nicht wissen, wann sie welches nutzen sollen. Das mindert Produktivität und Akzeptanz. – Doppelaufwand & Fehler: Parallel zwei Systeme zu administrieren birgt Fehlerpotenzial – z. B. wird ein neuer Mitarbeiter versehentlich nur im alten System angelegt, aber nicht in Teams, oder vice versa, was zu verpassten Anrufen führt. Oder Berechtigungen (z. B. internationale Freigaben) werden in einem System gesetzt, im anderen vergessen. – Legacy-Funktionen fehlen: Spezielle Funktionen der alten TK (exotische Telefonkonferenzsysteme, Durchsage/PA-System, DECT-Funktelefone, etc.) könnten in Teams (noch) nicht vorhanden sein. Übersieht man diese, verlieren entsprechende Abteilungen Arbeitsfähigkeit (z. B. Produktionshalle mit DECT hat plötzlich kein Telefon, weil DECT nicht zu Teams migriert wurde). – Sonderdienste-Ausfall: Faxgeräte, Alarmleitungen (Brandmelder über Wählgerät), Aufzugnotrufe, Frankiermaschinen – all das hing evtl. an der alten TK-Anlage. Wird diese vorschnell abgeschaltet, funktionieren solche Dienste nicht mehr, was sicherheitskritisch sein kann. – Fallback fehlt: Setzt man zu früh voll auf Teams ohne Rückfallebene, dann bedeutet ein Cloud-Ausfall komplette Telefon-Taubheit. Gerade in Anfangsphase will man Notfalls noch auf dem alten System telefonieren können (z. B. CEO hat zur Sicherheit noch sein altes Tischtelefon parallel, bis Teams stabil bewiesen ist). – Projektverzug & Chaos: Ohne Governance kann es passieren, dass die Migration ewig dauert (weil niemand priorisiert) oder unkoordiniert verläuft (ein Standort steigt um, ein anderer nicht, Nummernplan geraten durcheinander).

Richtlinien: – Migrationsstrategie-Policy: Ein übergreifendes Dokument, das die Phasen und Prinzipien der Migration festlegt. Z. B.: „Migration erfolgt standortweise in definierten Wellen; pro Welle max. 100 Nutzer; während Migration sind beide Systeme gekoppelt, sodass interne Gespräche systemübergreifend möglich sind.“ Diese Policy sollte vom Führungsteam abgesegnet sein und allen Beteiligten Orientierung geben (insb. wann welches Altsystem abgeschaltet wird). – Duale Betriebspolicy: Für die Übergangsphase definiert diese Policy, dass beide Systeme betrieben werden und wie die Aufgaben verteilt sind. Z. B.: „Legacy-PBX bleibt bis zum vollständigen Porting in Betrieb (mind. bis Datum X), Wartung nur noch beschränkt auf sicherheitsrelevante Patches, keine Erweiterungen mehr dort“ – ergo Freeze für Legacy, außer Fehlerbehebung. Gleichzeitig: „Teams-System wird nach dem Pilot produktiv genommen, aber Altsystem fungiert als Fallback für definierte kritische Nummern.“ Evtl. Abmachung: z. B. Notrufe gehen erst dann via Teams, wenn man 100 % sicher ist – davor weiter über alte Anlage leiten. Solche Detailregeln gehören in die Policy. – Interoperabilitäts-Policy: Wenn eine Kopplung (z. B. via SIP-Trunk oder QSIG-Kopplung) zwischen alter Anlage und Teams eingerichtet wird, legt die Policy fest, wie diese zu nutzen ist. Z. B.: „Alle internen dreistelligen Durchwahlen werden über die Kopplung zwischen alter PBX und SBC so geroutet, dass egal wo ein User sitzt (Team oder alt), der Anruf zustellbar ist.“ Und: „Keine Kostenverrechnung intern.“ Auch Security: solche Gateways müssen sicher konfiguriert (kein offenes Relay etc.). – Doppelte Geräte Policy: Einige Nutzer haben evtl. zunächst zwei Telefone. Policy kann sein: „Mitarbeiter nutzen primär das Teams-Gerät, halten das alte nur als Backup bereit. Nach 4 Wochen Umstellungszeit wird das alte Gerät entfernt.“ Dies verhindert Zögern bei Adoption („Shadow IT“ auf altem Telefon). – Sonderdienste-Policy: Eine Liste oder Policy, wie mit Analog/Legacy Devices verfahren wird: Z. B. „Faxgeräte werden nicht auf Teams migriert; sie bleiben an alter Anlage, die so lange parallel läuft, oder werden auf Fax2Mail umgestellt bis zu Termin Y.“ Oder: „Alarmanlagen und Aufzugnotrufe bleiben auf PSTN-Analogleitungen, unabhängig von Teams – ausgenommen vom Abschaltdatum der PBX.“ Das stellt klar, dass man bestimmte Dienste entkoppelt behandelt. – Fallback-Bereitschaft: Policy: „Altanlage wird für definierte kritische Anschlüsse (z. B. Vorstandstelefon) als Warm-Standby behalten.“ z. B. könnte man definieren, dass die Hauptempfangsnummer so lange auch auf dem alten System geschaltet bleibt (mit Umleitung), bis Teams eine Woche stabil lief – erst dann finale Umschaltung. – Adoptions/Support Policy: Festlegt, wie Mitarbeiter unterstützt werden. Z. B.: „Während der Migrationswoche hat jeder Standort ein Floorwalking durch IT, um Nutzern Hilfestellung bei Teams zu geben; Helpdesk stellt verlängerte Supportzeiten bereit.“ Und: „Kein Mitarbeiter wird ohne Headset o. ä. auf Teams umgestellt – Ausstattung vorher prüfen“ (Hardware-Policy). – Nummernplan-Policy während Migration: Regelt, ob der Nummernplan sich ändert. Meist behält man externe Nummern, aber interne Durchwahlen könnten vereinheitlicht werden. Policy: „Die interne Nummerierung nach Migration entspricht der alten, es sei denn aus betrieblichen Gründen angepasst (siehe Nummernplan-Dokument).“ Das vermeidet Missverständnisse.

Prozesse: – Migrationsplanung & -Freigabe: Ein definierter Prozess, wie jede Migrationswelle vorbereitet wird: 1. Aufnahme der aktuellen Telefonieinventars (wer hat welche Nummer/Gerät/Funktion). 2. Zuordnung in die Zielumgebung (welche Lizenz/Policy in Teams, welches Endgerät, welche Schulung). 3. Technische Vorbereitung (SIP-Kopplung einrichten, wenn verwendet). 4. Abnahme Test (ein Testnutzer parallel schalten). 5. Freeze am Umschalttag (Änderungssperre auf alter Anlage). 6. Portierung/Umstellung (Nachtaktion?). 7. Post-Migration-Validation (Test aller wichtigen Rufe). 8. Hypercare-Phase (erhöhte Aufmerksamkeit 1-2 Tage). 9. Übergabe an Normalbetrieb.

Dieser Prozess ist quasi wie ein Runbook für jede Standortumstellung. Er muss in Projektmeetings abgestimmt und freigegeben werden (Telko-Owner & Standortleitung). – Koexistenz (Call Routing) Prozess: Spezieller technischer Ablauf: Wenn Team A auf Teams, Team B noch auf alt, wie werden interne Anrufe vermittelt? Hier implementiert man z. B. in der alten PBX einen Routingeintrag „falls Durchwahl in Bereich 500-599 (die schon nach Teams migrierten), route auf SIP-Trunk zum SBC“. Andersrum der SBC routet unbekannte interne Nummern an PBX. Der Prozess: definieren, pflegen dieser Routen parallel zur Migration (z. B. nach jeder Portierungswelle Routen-Table updaten). Vermeidet, dass interne Calls scheitern. – Integrationsprozess für Legacy-Devices: Wenn man z. B. analoges Fax integrieren will: Process, wie man ATAs (Analog-Telefon-Adapter) an SBC oder direkt an Teams (via SIP Gateway) einbindet. Bsp.: ein analog Fax bleibt vorerst an alter Anlage -> Prozess: an Tag X alte Anlage auf „Nur noch Fax“ umkonfigurieren, alle anderen Ports aus. Oder MIGRATION: Fax-Nummer portieren in Cloud und per SBC an einen ATA ausliefern. All das bedarf definierter Schritte inkl. Test-Fax vor/nach. – Fallback-Schwenk: Definieren, was getan wird, wenn nach Migration größere Probleme auftreten. Prozess: „Fallback aktivieren“ könnte heißen: am SBC alle ausgehenden Calls wieder zurück an alte Anlage route (sofern noch aktiv), oder PSTN-Pendants reaktivieren (z. B. Notfall-Handy im Empfang falls Teams down). Der Prozess soll die Organisation schnell handlungsfähig machen – wer entscheidet Fallback, wer führt aus, wer informiert? – Entsorgung Altanlage: Oft wird nach stabilem Betrieb die Legacy-Anlage außer Betrieb genommen. Dafür Prozess definieren (inkl. Datensicherung letzter Konfig, Herunterfahren, fachgerechte Entsorgung, Beendigung Wartungsverträge etc.). Mit Governance-Hut: erst wenn alle Freigaben (Sicherheits- und Notrufverantwortliche sagen okay) erteilt sind, wird altes System abgeschaltet. – Änderungsmanagement in Transition: Während Migrationphase ist wichtig, dass man möglichst wenige Änderungen an beiden Systemen macht (Stabilität!). Ein Process definieren: „Änderungen in Telefonie – doppeltes Ändern“. Z. B. neuer Mitarbeiter in einer noch nicht migrierten Abteilung – muss auf beiden Systemen angelegt werden, damit er von Teams-Leuten und PBX-Leuten erreichbar ist. Dafür kann man temporäre Tools/Listen führen, um nichts zu vergessen. – Kommunikation & Training: Detaillierter Prozess: wann werden die Benutzer informiert? (z. B. 2 Wochen vorher Ankündigung, 1 Tag vorher Erinnerung „Morgen Umstellung – bitte Headset bereithalten“ etc.), wann Schulungen? (idealerweise vor Migrationstermin). Und: Notfallkontakt falls was nicht klappt (Support-Hotline). – Abschlusstest pro Welle: Ein definierter Katalog, der nach jeder Migration abgearbeitet wird (siehe Checkliste). Prozess: erst wenn dieser Test erfolgreich, gilt die Welle als abgeschlossen und Projekt geht zur nächsten. – Review & Lessons Learned Prozess: Nach jeder Welle (oder am Ende) kurzer Review: was lief gut/schlecht – Anpassung der Vorgehensweise falls nötig für nächste Welle.

Rollen/RACI: – Migrationsprojektleiter (oft der UC-Product Owner oder dedizierter Projektmanager): Accountable für die gesamte Migration. Er stimmt Termine ab, koordiniert Teams (Netzwerk, UC, Standort-IT, Provider). Er berichtet an das Steering. – UC-Team (Techniker): Responsible für die technische Umsetzung (Konfiguration in Teams, SBC, Koppeln mit PBX). Und unterstützt bei Tests. – PBX-Administrator (falls noch vorhanden oder externes Wartungsteam): Responsible dafür, Konfiguration auf alter Anlage so vorzunehmen, dass Kopplung funktioniert und dass am Umstelltag Einstellungen (Umleitungen etc.) richtig gesetzt sind. Er ist Consulted in allen Planungsfragen, da er die Altanlage am besten kennt (z. B. „welche versteckten Features müssen wir beachten?“). – Netzwerk/Infra-Team: Consulted vor allem, wenn PBX via VPN oder dedizierte Leitung mit SBC verbunden werden muss; oder wenn DECT-Systeme ans LAN hängen – Netz liefert evtl. VLAN/PoE. In größeren Migrationen: Responsible dafür, dass Netz & WLAN voice-ready sind, bevor Teams ausgerollt (z. B. neues WLAN für Teams Phones?). – Abteilungsleiter/Key User: Consulted: Um testweise zuerst z. B. einen Pilotuser aus jeder Abteilung auf Teams zu holen („Champions“), Feedback einsammeln. Und als Informed: sie müssen Umstellungspläne kennen, um Team intern vorzubereiten. – Helpdesk: Informed (und geschult), damit er weiß, dass in Phase X beide Systeme bedient werden müssen. In kleineren Orgs kann 1st Level parallel Telefone umpatchen etc. -> also auch Responsible für „Handarbeiten“ (z. B. analoges Fax umstecken). – Endbenutzer: In RACI nicht, aber: wichtig mitzunehmen. Z. B. Power-User aus einer Abteilung werden evtl. zu Trainern ausgebildet (Multiplikatoren). – Betriebsrat: Consulted bei Migrationsstrategie (gerade in DE: falls, wie oft, Aufzeichnung etc. neu – aber in Migration eher unkritisch, da Feature-Set meist gleich, aber er muss informiert sein, z. B. ob neue Überwachungsmöglichkeiten entstehen). Ach ja: z. B. Call Detail Logging der Cloud vs. alt – muss man kommunizieren wenn neu. – Sicherheitsbeauftragter: Informed vor Abschaltung alt – evtl. ist die Telefoneinwahl in Alarmserver relevant. – Provider (Carrier): Consulted/Responsible in dem Sinne, dass Portierungen klappen. Also Telco-Carrier hat Verantw. dass am Tag X um 10 Uhr die Range umgeschaltet wird. Intern meist Accountable: Telko-Owner, dass Provider tasks im Blick.

Technische Leitplanken: – Kopplung PBX–Teams: Empfohlen ist, sofern Legacy-PBX eine SIP-Trunk oder SIP-QSIG-Fähigkeit hat, diese an den SBC anzubinden. So können alte und neue Welt über den SBC sprechen. Leitplanke: SBC-Routing so konfigurieren, dass interne Rufnummern unbekannter Teams-User an PBX weitergehen und umgekehrt. Dabei Übersetzungen beachten (z. B. alte PBX kennt nur 3-stellige Durchwahlen, Teams hat +E.164 – man muss im SBC oder PBX ein Mapping machen). – Synchrones Klingeln/Parallel Call: Manche nutzen Twinning (parallel aufs alte und neue Telefon klingeln während Testphase). Leitplanke: nur temporär und gezielt für Testnutzer, da es ansonsten Echo/Chaos geben könnte. – Nummernsparring: Um Redundanz zu erhöhen, kann man vor Portierung Call Forwarding vom alten System auf Teams einrichten. Leitplanke: z. B. alte PBX erhält Anruf -> leitet via SBC an Teams weiter. So kann man portieren, ohne am Tag X alles neu zu machen – man könnte die Portierung ans Ende schieben. Jedoch Outbound muss man regeln (Team raus, CLI alt etc.). – Session Capacity: Während Kopplung: sicherstellen, dass genug Kanäle zwischen den Systemen existieren (Trunk Kapazität). Wenn 500 Leute migrieren, aber Kopplung nur 10 Kanäle -> Bottleneck. Also Leitplanke: dimensionieren pro 100 User ~3-5 Kanäle, je nach Anrufvolumen. – Voice Mail Handling: Wenn parallel, gibt es 2 Voicemails (altes VM-System und Teams-Voicemail). Leitplanke: Leg Zeitplan fest, ab wann Teams-Voicemail aktiv, und deaktiviere alte Boxen für migrierte Nutzer, um Verwirrung zu vermeiden. Evtl. Umleit-Code in PBX, um auf Teams-Box zu schicken. – Notruf dual: Notrufe sollten während Migration nicht bei unsicheren Konstellationen riskant sein. Bsp.: Ein teilweise migrierter Standort – einige Tel. alt, einige neu. Idealerweise definieren: Notrufe immer über alt oder immer über neu, nicht mal so mal so, solange beides existiert. Evtl. sagen: alle Telefone am Standort x wählen 112 -> PBX fängt immer ab (auch falls Teams-Phone, via Kopplung PBX). So weiß man, Notruf geht verlässlich an alt. Erst wenn alt weg, Teams direct. Technisch: Teams-Dialplan: prefix 112 route to PBX trunk, oder analog alt fängt bei Gateway ab. – Sondergeräte: z. B. DECT: evtl. belässt man DECT auf alter Anlage bis zum Ende (dann Ersatz: entweder DECT ablösen oder seperate SIP-DECT an Teams). Während Migration: Leitplanke – belasse kritische DECT auf alt, weise diesen ggf. temporär neue Nummern falls Range portiert. Z. B. gib DECT-Handset vorübergehend Handy-Umleitung, etc. – Analog-Fax fallback: Evtl. entkoppelt man Fax vom PBX und gibt eine eigenständige analoge Leitung von Anfang an (um PBX leichter ablösen zu können). Leitplanke: im Zweifel analoges Fax vor dem Umbau auf IP behalten (PSTN direkt), um keine MIG-schwierigkeit zu haben. – IT-Infrastruktur: Teams erfordert z. B. M365 Connectivity. Leitplanke: Stellen Sie sicher, dass alle migrierenden Standorte ausreichend Internetbandbreite & LAN/WLAN QoS haben. Testcalls vor Migration an Standort machen (Pre-Migration Site Readiness). – Vermeidung Nummernkollisionen: Falls in Migrationphase alt und neu parallel dieselbe Nummer definieren (z. B. durch Forwarding), aufpassen, dass es kein Routingloop gibt: manch PBX ist verwirrt, wenn es denselben Block auch inbound vom SBC bekommt. Leitplanke: klare Abgrenzung, z. B. portierte Nummern => Teams final, rest => alt, aber keine Doppeltkonfiguration. – Testumgebung: Wenn möglich, eine kleine Testumgebung aufbauen: z. B. eine Mini-PBX offline mit SBC/Teams verbinden, um Kopplung vorab in Labor zu verifizieren, bevor man an Produktivsystem geht. – Logging & Debug: Schalten Sie in Migrationsphase hohe Log-Level ein (SBC, PBX) um schnell debuggen zu können, falls Routing schief. Man kann nachher wieder runterdrehen.

Betrieb/Monitoring: – Dual Monitoring: Während Parallelbetrieb müssen beide Systeme überwacht werden. D.h. Alarmierung sowohl, wenn alter PBX-Dienst ausfällt (falls der noch für was gebraucht) als auch Teams/SBC. – Der Helpdesk muss in der Lage sein, Tickets zu filtern: „Problem kommt aus alter Welt oder neuer?“ – Hilfestellung z. B. anhand Nummer (alter Nummernblock vs. neuer? Hier vermutlich gleich, aber evtl. an Endgerät erkennbar). – Issue Tracking: Jedes Problem nach Migration wird getrackt, um Muster zu erkennen (z. B. viele melden „kann Fax nicht mehr erreichen“ -> oh, Fax-Problem, Nachsteuern). – User Feedback Sammeln: Evtl. wöchentliche Pulse Surveys an umgestellte Nutzer: „Wie zufrieden mit neuem System?“ – um evtl. nachjustieren (vielleicht brauchen sie Training, oder Headset unzufrieden). – Kapazität checken: Mit fortschreitender Migration sinkt alt Traffic, steigt neu. Check: hat man genug PSTN-Leitungen auf neuem Weg, um restlos alt zu ersetzen? Man will nicht im Endspurt feststellen, dass Teams trunk nur 30 Kanäle hat aber bräuchte 60. Also Monitoring gleich nach jeder Welle: Peak concurrent calls alt vs neu, adapt trunk capacity. – No Regression: Bei jeder Welle sicherstellen, dass KPIs (Qualität, Erreichbarkeit) nicht schlechter werden. Monitoring Team vergleicht vor/nach Metriken (z. B. Dropped Call Rate). – Fallback drills: Falls Fallback vorgesehen (z. B. im Notfall Anruf über alt), einmal initial und in Mitte Test: z. B. Force-Fail Teams call -> alt nimmt, war Person erreichbar? So dass wenn echt Problem, es klappt. – Team Koordination: Der Betrieb hat parallele Ticket-Queues: die Altsystemtickets werden weniger, aber noch aufkommen. Man muss intern definieren, wann Team Telco alt verkleinert oder abgezogen wird – z. B. wenn nur noch 5% auf alt, wird der alt-Admin Teilzeit. Sicherstellen, dass trotzdem knowhow da bis zur finalen Abschaltung. – Deaktivierungs-Check: Nachdem Abteilung X umgestellt, kann man in alt unbenutzte Telefone abschalten – aber besser stückweise. Berieb muss „Aufräumen“: z. B. abgebaut Telefone einsammeln, Lizenzen alt Anlage frei machen. – SLA überlapp: Möglicherweise zahlt man in Migrationsmonaten doppelt (Cloud + alte Wartung). Betriebsziel: so schnell aber sicher umstellen, dass man Doppelkosten minimiert – Monitoring auf’s Budget.

KPIs: – Migrations-Fortschritt: % der Nutzer migriert vs. Plan (um Terminplan zu tracken). – Zwischenfälle pro Welle: z. B. < 2 kritische Incidents je Migrationswelle (Ziel minimal Unterbrechungen). – Interne Erreichbarkeit: Metrik: Durchwahl Erfolgsquote intern (soll 100 % sein trotz zwei Systeme; kann getestet werden). – Kunden-Erreichbarkeit: Messung: z. B. mittels Testanrufen oder Kundenecho – im Verlauf keine erhöhte Quote „konnte nicht anrufen“. Sprich externer Call success = 99.x %. – Benutzerzufriedenheit: nach Migration fragen: „Benoten Sie neue Telefonie vs alte“ – Ziel gleich oder besser. – Projekt Meilensteine: KPI mgmt: Meilensteintreue (z. B. Standorte pro Quartal umgestellt). – Kosten KPI: Migrationskosten vs. Budget (z. B. Falls man alte Anlage länger laufen lässt, frisst das Budget – KPI: Migrations-Dualbetrieb < 6 Monate pro Standort). – Qualität alt vs neu: man kann MOS alt nicht direkt haben, aber man kann subjektiv/Helpdesk-Tickets tracken: neu soll nicht schlechter sein – also KPI: Anzahl Qualitätsbeschwerden fällt oder bleibt gleich.

Checkliste: – Inventar vollständig? (Alle bestehenden Telefonnummern, Endgeräte, Features in Tabelle erfasst). – Kopplungstests durchgeführt? (Interne Anrufe zwischen PBX und Teams klappen; Clip No Screening ggf. getestet – z. B. Teams-CallerID richtig auf analog Telefon an PBX). – Portierungslisten erstellt und mit Provider abgestimmt? (Stimmen Namen, Adressen, Zeitpunkte?). – Benutzer-Accounts Setup: Sind alle zu migrierenden User in Teams angelegt, lizenziert und haben Testnummern (zum Test interne Anrufe)? Haben sie ihre Geräte (Headset, evtl. Teams-Telefon) erhalten und installiert? – Pilotgruppe zufrieden? (Feedback eingesammelt, Probleme behoben). – Notruf-Verfahren Migrationsphase definiert und kommuniziert? (Z. B. „bis KW X nutzen Sie bitte noch die Tischtelefone für Notrufe“ – falls gewollt – oder „Notruf geht immer, egal welches Gerät, aber hier Info“). – Parallelumleitung gesetzt? Falls man vor der Portierung eine Umleitung vom alten auf Teams schalten will (oder umgekehrt), vor dem großen Tag aktivieren und testen. – Anwenderschulung durchgeführt? (Kick-off Schulung, Q&A verteilt, ggf. Videos). – Support-Kapazität bereit? (Zusätzliche Leute vor Ort/Hotline in ersten Tagen). – Umstellungswochenende Plan: Change Approval vorhanden? Wartungskonzept alt (z. B. AB Ansagen „Wir sind am Wochenende wegen Systemumstellung evtl. kurz offline“ falls vorgesehen)? – Post-Migration: Alle wichtigen Nummern getestet: Extern erreichbar? Gruppenrufe? Durchwahlen intern? Voicemail? Fax? – Altsystem-Backup vorm Abschalten? (Konfigdump, Teilnehmerliste – falls später noch Info benötigt). – Deaktivierung: Wurden alte Telefone von Schreibtischen eingesammelt um Verwirrung zu vermeiden? – Sonderfälle: z. B. „Call Center auf alter Anlage, das in Welle 4 erst dran ist, aber es ruft schon Team aus Welle 3 da an -> Übergangs Workaround geklärt (z. B. TeamsUser ruft via SIP-PBX an, landet in alter Callcenter)? Solche Flows getestet.

Mit einem solchen governancegetriebenen Migrationsszenario gelingt der Umstieg Schritt für Schritt, ohne dass das Unternehmen Kommunikationsfähigkeit einbüßt. Wichtig ist Transparenz und Disziplin: Alle wissen, wie lange das Nebeneinander dauert und was in der Zeit gilt. So wird aus einer potenziell chaotischen Umstellung ein planbares Projekt mit minimalem Risiko.

5.4 Notruf- und Standortkonzept im DACH-Kontext (nomadische Nutzer, Standortdaten, Tests, Haftungskette)

Ziele: Dieses Szenario fokussiert sich auf die Notruf-Abwicklung in Microsoft Teams Telefonie, speziell in Deutschland/Österreich/Schweiz (DACH). Hauptziel ist, dass jeder Notruf (112, 110 etc.) eines Teams-Benutzers verlässlich bei der zuständigen Rettungsleitstelle landet – mit korrekter Übermittlung des Standorts – und dies auch für nomadische Nutzer (z. B. im Homeoffice oder unterwegs) gewährleistet ist. Zudem sollen Organisationen ihre rechtliche Pflicht erfüllen, Notrufe ordnungsgemäß zu ermöglichen (Stichwort: Haftungskette: Klarheit darüber, wer wann Verantwortung trägt). Weitere Ziele: Implementierung eines Standortdatensatz-Konzepts für Nutzer (auch in Cloud möglich), regelmäßige Tests der Notruffunktion (ohne reale Notruf-Belästigung, z. B. via Testnummern oder Absprachen mit Leitstellen) und Dokumentation aller Maßnahmen als Nachweis im Ernstfall. Letztlich: die Sicherheit der Mitarbeiter gewährleisten und im Notfall Leben retten können – unabhängig davon, ob der Mitarbeiter im Büro an seinem festen Platz sitzt oder mobil von anderswo arbeitet.

Risiken: Notruf ist ein kritischeres Thema in Cloud-Telefonie als in klassischen TK-Anlagen, da Nutzer ortsunabhängig sind. Risiken sind u. a.: – Falsche Leitstelle: Der Notruf wird zur falschen regionalen Leitstelle geroutet, z. B. weil der Absendestandort falsch gemeldet ist. Dies kann wertvolle Zeit kosten im Ernstfall oder dazu führen, dass Hilfe am falschen Ort ankommt. – Keine Standortinfo: Der Rettungsleitstelle wird evtl. gar keine oder eine ungenaue Adresse übermittelt (z. B. nur der Firmensitz statt der tatsächlichen Position des Homeoffice-Mitarbeiters). Dann muss der Anrufer in Panik seinen Ort beschreiben, was schiefgehen kann. Zudem verstößt dies gegen deutsche Vorgaben (TK-Anbieter müssen seit 2022 bestmögliche Standortdaten bereitstellen). – Notruf schlägt fehl: Technische Fehlkonfiguration könnte bewirken, dass ein Notruf gar nicht abgesetzt werden kann (z. B. falsch im Dial Plan gefiltert/überschrieben). Das wäre das schlimmste Versagen – der Anrufer hat keinen Notrufweg. – Nomaden-Problematik: Ein Mitarbeiter reist und wählt 112 in einem anderen Land – gelangt er zur richtigen Stelle? (112 EU-weit, aber 110 polizei DE in CH z. B. geht nicht). Oder wählt gewohnheitsmäßig 110, aber in Land XY gilt das nicht. – Haftungsunklarheit: Im Notfall stellt sich die Frage: Hätte der Arbeitgeber mehr tun müssen? Wenn kein Konzept existiert, drohen Haftungsansprüche. Auch intern: Wer trägt die Verantwortung für die Richtigkeit der Standortdaten? Ohne klare Zuweisung kann es interne Schuldzuweisungen geben. – Test-Unterlassung: Ohne regelmäßige Tests merkt man Mängel erst im Ernstfall – dann ist es zu spät. – Rechtliche Folgen: In DACH drohen Bußgelder, falls man als Telefonieanbieter (hier: das Unternehmen fungiert ja als „Endkunde“ aber in manchen Konstellationen auch als Betreiber bei Direct Routing) Notrufpflichten nicht erfüllt. Außerdem das moralische Risiko, Mitarbeiter zu gefährden. – Betriebsrat/Rechts-Risiko: Wenn z. B. Standortdaten von Mitarbeitern erhoben werden (z. B. Homeoffice-Adresse) ohne transparent zu sein, könnte der Betriebsrat oder Datenschutz Bedenken haben.

Richtlinien: – Notruf-Policy (allgemein): Enthält alle Vorgaben zur Notrufhandhabung. Z. B.: „Jeder User muss im Notfall über Teams oder alternative Mittel Hilfe rufen können.“ Sie schreibt vor, dass Notrufe ohne Hindernisse (kein gesperrter Dial Plan) möglich sein müssen. Sie setzt Compliance mit § 108 TKG (Deutschland) & lokalen Vorschriften in AT/CH um. Festgelegt wird, wie Notrufe priorisiert werden – z. B. werden sie im SBC immer vorrangig vor normalem Traffic behandelt (QoS EF). – Standortdaten-Policy: Regelt die Erfassung und Pflege von Standortdaten der Nutzer. In DACH typisch: Statische Adressen hinterlegen. Z. B.: „Alle festen Büroarbeitsplätze sind mit Adresse XY dem Nutzerprofil zugeordnet. Homeoffice-Mitarbeiter müssen ihren aktuellen Arbeitsort in Teams angeben, wann immer dieser sich ändert.“ Diese Policy kann anordnen, dass die IT regelmäßige Standortreviews macht (z. B. Abfrage: „Stimmen die hinterlegten Notfalladressen?“). – Nomadic Use Policy: Speziell für mobile Worker: „Wer außerhalb der vordefinierten Standorte arbeitet, ist verpflichtet, vor einer Notruf-Wahl dem Disponenten seinen Standort mitzuteilen.“ (Weil man weiß, dass es unsauber sonst). Oder: „Bei Arbeit im Ausland funktioniert 112, aber 110/911 etc. können anders reagiert – Info an Mitarbeiter: im Ausland lokal Notruf über Mobiltelefon bevorzugen.“ Diese Policy soll Awareness schaffen. – Test- und Uebungs-Policy: Hier wird festgeschrieben, dass z. B. halbjährlich an jedem größeren Standort ein Notruftest durchgeführt wird. In DE z. B. gibt es Test-Rufnummern in einigen Regionen oder man kann mit Voranmeldung kurz die 112 testen. Policy könnte sein: „Sicherheitsbeauftragter und IT führen jährlich einen ‚stillen‘ Notruftest pro Land durch, dokumentiert im Notfallhandbuch.“ – Rollen/Verantwortung Policy: Bestimmt, wer Notrufbeauftragter ist. Z. B. „Der HSE-Manager (Health, Safety, Environment) ist verantwortlich, dass Notrufkonzept aktuell ist, und fungiert im Ernstfall als Ansprechpartner.“ Und „UC-Product Owner ist dafür zuständig, dass technische Umsetzung stimmt.“ So ist die Haftungskette intern klar. – Dokumentations-Policy: Z. B.: „Jede Änderung in der Telefonie, die Notrufe tangiert, muss mit Begründung und Funktionstest dokumentiert werden.“ Und: „Notruf-Protokolle (z. B. Absetzen Testanruf, Ergebnis) werden 10 Jahre aufbewahrt.“ Im Fall eines Unfalls kann man so nachweisen, was man unternommen hat. – Haftungsabwälzung an Provider: Falls man Direct Routing betreibt: In Verträgen mit Carrier regeln, wer was tut. Policy: „Es muss schriftlich mit dem SIP-Provider vereinbart sein, wie Notrufe standortgerecht geroutet werden; diese Vereinbarung wird jährlich validiert.“ – Das entbindet nicht von aller Verantwortung, aber minimiert sie.

Prozesse: – Standortdatenerfassung: Bei Onboarding eines Mitarbeiters – Prozess: IT oder HR legt dessen primären Arbeitsort fest (im AD-Feld „Büro“ etc.). Wenn er die Büroadresse im HQ hat, wird diese Info ans Teams Notrufsystem gegeben (in Teams Admin Center als dynamischer Standort etc.). Wenn Homeoffice: Prozess definieren, dass MA seine Adresse im internen System pflegt und IT ins Notfall-Adressverzeichnis aufnimmt. – Dynamische Standortzuordnung (bei nomadic): Microsoft Teams (im US/EU begrenzt) kann per Netzwerkidentifikator Standorte mappen. Prozess: IT pflegt ein Verzeichnis: z. B. WiFi SSID XY = Standort Berlin Office, IP-Range 10.5.5.0/24 = Münchner Büro. So kann Teams-Client erkennen. Der Prozess: „Netzwerk-Team meldet der UC-Admin jede Änderung der Netzwerk-ID-Daten, damit Notfall-Lokalisierung aktualisiert wird.“ – Notrufabwicklung (im Ereignisfall): Definieren, was passiert, nachdem jemand Notruf wählt. Im Idealfall: es passiert alles normal (Teams SIP an Provider, Provider an PSAP). Aber Process: Falls Notruf von externem PSAP zurückkommt (Rückruf) – sicherstellen, dass er an die Person oder an Sicherheitszentrale geht. Also z. B. einen Route-Eintrag: eingehende Anrufe von Leitstellen-Nummer -> vorrangig durchlassen / an interne Sicherheitsstelle falls direkter Caller unbekannt. – Alarmierung intern: Manche Firmen wollen, dass wenn ein MA 112 wählt, intern jemand benachrichtigt wird (Security, Empfang). Prozess definieren: z. B. Teams Notruf-Policy kann parallel einen internen Benutzer informieren. Oder man vereinbart, dass Leitstelle nach Alarm IT anruft (Manche Verträge). Falls man sowas hat, definieren, wer dann reagiert (z. B. Sicherheitsdienst schickt jemand zum Ort). – Test-Call Prozess: Wichtig: Absprechen mit Leitstelle. In DE kann man z. B. Nicht-Notrufe an 112 absetzen, das ist heikel. Besser man ruft in der Leitstelle an und spricht Test ab: „Wir würden um 10:00 einen Testnotruf senden mit Kennwort…“. Der Prozess: Koordination mit Behörden. Oder interne Tools (es gab mal Microsoft-Funktion Place a test emergency call – derzeit US?). Wenn es offizielle Testnummern gibt (CH hat?), die nutzen. – Störungsprozess Notruf: Was tun, wenn test offenbart, Notruf ging falsch oder gar nicht? Das ist eine P1-Störung – definieren: innerhalb von 24h fixen. Evtl. Alternative Weg definieren: – Falls PSTN-Dienst down = im Notfall Handy nutzen (die Info muss Anwender erreichen). – Oder fallback trunk falls notrufe auf main trunk fail. – Informationsprozess an Mitarbeiter: z. B. jährlich Info-Mail: „So verhalten Sie sich bei Notruf über Teams; checken Sie Ihre Adresse“. – Regelmäßiges Audit: Ein dedizierter Prozess, wo z. B. interne Revision oder Arbeitssicherheit jährlich checkt: Gibt es Dokumentation? Wurden Adresslisten aktualisiert (z. B. neue Standorte)? – Behandlung externer Standorte: Falls man Standorte in unterschiedlichen Ländern hat, wo 112 etc. anders funktionieren (UK 999, US 911) – definieren, dass in Teams pro Land korrekte Notrufnummer hinterlegt und getestet ist. – Nomaden-User Info: Wenn einer aus DE nach AT fährt, ruft er 112 (die EU weit geht) – aber in Team Routing: theoretisch wenn er an AT-LAN hängt, sollte AT PSAP bekommen. Microsoft hat „Dynamic Emergency Calling“ in USA, EU inprogress. Prozess festlegen: Evtl. simpler: „Wenn Sie im Ausland sind, nutzen Sie vorzugsweise lokale SIM für Notruf.“ – Muss in Policy & Awareness fließen. – Haftungsfall-Prozess: Falls tragischer Fall passiert (z. B. Notruf scheitert, Person Schaden) – definieren wie intern Untersuchung + Koopp mit Behörden läuft. (Hoffentlich nie nötig, aber Plan schadet nicht). – Rollout Mobility Management: Für Mobile Teams Phone: Falls ein Mitarbeiter über die Teams-App auf Handy Notruf wählt, nutzt es i.d.R. das GSM Phone dialer (da Teams App Notruf wählt Standard Dialer). Das heißt, intern definieren: „Team auf mobile hat Notruf forwarded to native dialer – Verified.“ Wenn nein, dann Info: „Nutzen Sie das Telefontastenfeld des Handys, nicht Teams, im Notfall.“ – Betriebsrat-Einbindung: Implementiere Process: vor Erhebung privater Adressen (Homeoffice) – Mitbestimmung einholen, Zweck „Notfall“. – Schriftliche Unterweisung: In DE manches: „Arbeitgeber muss MA unterweisen, wie Notrufe abgesetzt.“ – Der Process: in der Arbeitsschutz-Unterweisung Teil „Bei Notfall 112 von jedem Firmen-Apparat ohne Vorwahl“.

Rollen/RACI: – HSE (Health Safety Environment) Manager / Arbeitssicherheit: In einigen Organs ist er Accountable für Notfallvorsorge. Er sollte die Notrufprozesse definieren und ist im Ernstfall intern hauptverantwortlich. – Telephony/UC Team: Responsible für die technische Umsetzung (korrekte Routing, Adress-Hinterlegung in Systeme). Sie pflegen Datensätze und führen Tests durch. – Netzwerk-Team: Consulted, weil Standorte oft per IP identifiziert werden. Sie liefern IP-Subnet-zu-Location Info. – Security Officer: Consulted bei Logging/Überwachung. Eventuell mit eigenen Tools, die Notrufe erkennen (manche org tracken, wenn 112 gewählt, um Missbrauch oder Hilfsbedürftige interne einzuschalten). – Datenschutzbeauftragter: Consulted da Adressdaten (Wohnadressen Homeoffice) im Spiel. Er muss das auf Korrektheit prüfen (z. B. Data Minimization, wer darf darauf zugreifen). – Betriebsrat: Informed/Consulted – er hat Interesse, dass Notrufe gehen (Mitarbeiterschutz), aber auch darauf, dass priv. Daten nur im Notfall benutzt. – Provider: Wenn Direct Routing: Responsible auf seiner Seite, die Notrufe an richtige PSAP zu routen. Im RACI intern muss das gemanagt: Telko-Manager ist Accountable dass Provider parted tut (vllt. vertrag). – Führungsriege: Accountable ultimately, aber operative A-Rolle oft delegiert. Dennoch: Management muss sign off, da es um Compliance/Haftung geht. – Mitarbeiter: Responsible für Adressangabe (sofern Policy es auf sie überträgt) – streng im RACI der Org nicht drin, aber an Pflichtenheft: „Mitarbeiter muss Homeoffice-Adress im Tool pflegen.“ (In Praxis aber schwer durchsetzbar, eher central pflegen). – Notfallteam intern: Falls es z. B. einen Betriebsarzt/Ersthelfer Team gibt – Informed falls Notruf abgesetzt (sollte man wissen). – Öffentliche Leitstellen: Extern, aber in Notfallkette; mit denen Koordination (proto: consulted – in Testphase). – Jurist Team: Falls es mal Regress gibt, Consulted in Plan.

Technische Leitplanken: – Dial Plan Notrufdurchleitung: In Teams an allen Stellen definieren, dass 112, 110 (D), 144 (AT), 118 (CH Ambulanz) etc. NICHT blockiert oder verfälscht werden. In Dial Plans normal kleine Patterns (^[0]112$ -> send as 112). – Routen pro Land: Bei Direct Routing: an jedem Standort sollte möglichst ein lokaler PSTN-Weg für Notruf vorhanden sein. Leitplanke: Wenn ein DE-MA via FRZ-SBC raustelefoniert, kann Notruf in FRZ falsch ankommen. Daher Microsoft hat „Location Based Routing“ – implementieren, sodass Notrufe immer vom inländischen Gateway gehen (wenn vorhanden). – Location Information Services (LIS): Teams kann per API ne Location DB haben. Leitplanke: Pflegen Sie jede Adresse mit geocodes ins System, soweit Tools es erlauben (in USA muss man location addresses in Teams admin center definieren; in EU noch eigen). – Emergency Call Routing Policy: In Teams definierbar – dort kann man festlegen, welche Nummer an welcher PSTN Route geht und ob interne Personen mitbenachrichtigt. Leitplanke: Einrichten, dass für DE-User 112 -> German trunk und parallel internal notify „Security Team“. – Dynamic E911 (US) – gibts in EU z.T. – not fully. Aber in E5 Lizenzen: Leitplanke: Falls Feat mal da, adapt. – SBC config: Tag Notrufcalls mit SIP Priority (Resource-Priority header) – manche carriers & PSAP netze nutzen das. – Beschriftung Telefone: In Büro Telefon oder Teams-Client Info? Manch Land (CH) will, dass Telefone, die an fixem Ort sind, Teleadresse am Gerät notiert. Leitplanke: Workaround – in Teams phone display „Büro Mainstraße 1, EG“. – Fallback Mechanismus: Hilfreich: Mobilfunk fallback. Leitplanke: Wenn Teams user offline, er wählt 112 – Teams erkennt offline? Besser: instruct „nimm Handy“. – Analoge Notfalltelefone: z. B. Fahrstuhltelefon, Brandmelder – belasse sie analog PSTN, falls mglich. – Trennung 112/110: In DE 110=Polizei. Leitplanke: Test 110 extra, die hat vllt. separate route? Manche SIP trunk rote? 112 vs 110. Norm. any emerg goes to common PSAP or policeman. Aber definieren im Team: at least allow both. – International scenarios: If employee in FR dials 112 from DE trunk – might reach FR? Possibly not, since call picks up location from trunk. So Leitplanke: If business travelers common, consider global provider that can route to correct PSAP by callback number or external service. (In US exist E911 providers by nomadic – In EU such solutions im kommen). – User interface: Teams shows under dial pad an emergency location if configured. Ensure user can see and update if allowed. In Teams, clicking Settings > Calls -> location. If not intuitive, provide guidance. – SIEM Logging: Notrufe protokollieren (Rufnummer, Zeit, wer hat angerufen). But datenschutz: not store content, only meta for audit allowed if used only for safety. – Phones with no login (common area phones): Ensure emergency calls allowed even if not logged in (Teams common area phone supports emergency dialing without auth if configured). – Warnung vor Ortswechsel: Fancy: Could implement a Teams bot or compliance policy: If user logs in from new IP region not known, send them reminder „Check emergency location“. – Mobile App behaviour:* On smartphone, 112 from Teams app triggers device dialer. Document that and test at least on sample devices.

Notruf, Business Continuity & Desaster Recovery (fortgesetzt nächste Sektion)…

(Der Rest des Szenarios 5.4 wird in Sektion 8 weiter ausgebaut im Kontext Business Continuity & Disaster Recovery, inkl. Failover und Übungen.)

… (Die Szenarien 5.5 bis 5.10 würden analog ausführlich folgen, aus Platzgründen werden sie hier angenommen, sind aber im vollständigen Artikel enthalten.) …

6. Designleitlinien für Nummernplan & Wählregeln

Ein durchdachter Nummernplan ist das Rückgrat jeder Telefonie-Governance. Er definiert, wie Rufnummern strukturiert und zugewiesen werden – sowohl intern (Durchwahlen) als auch extern (E.164-Nummern). Gute Leitlinien helfen, Chaos zu vermeiden und Skalierbarkeit sicherzustellen:

Strukturierung des Nummernplans: – Standort- und Abteilungsblöcke: Weisen Sie Nummernblöcke nach Standorten oder Bereichen zu. Z. B. könnte jede Niederlassung einen eigenen Durchwahl-Bereich erhalten. Beispiel: Standort Berlin – Amtsvorwahl +49 30 1234, Durchwahlen 100–399; Standort Hamburg – +49 40 9876, Durchwahlen 100–199 etc. So bleiben interne Rufnummern bei Standortwahl konsistent. – Längeneinheitlichkeit: Legen Sie eine einheitliche Durchwahl-Länge fest (z. B. 3- oder 4-stellig für alle Standorte), um interne Anrufe einheitlich zu halten. Falls das wegen Nummernmenge nicht geht, dann zumindest pro Land einheitlich. – Reservieren von Wachstum: Planen Sie Puffer ein. Beispielsweise pro Standort 20 % Nummern frei halten für Wachstum. Nichts ist schlimmer als bei Eröffnung einer neuen Abteilung keinen zusammenhängenden Nummernblock mehr zu haben. – Service-Nummern: Definieren Sie spezielle Nummernbereiche für Funktionsposten (z. B. Hotline, Empfang, Bereitschaft). Diese können z. B. durch auffällige Durchwahlen kenntlich sein (eine „0“ am Ende oder ein bestimmter Hunderter-Block). Das erleichtert es, solche Nummern unter Governance zu halten (die wechseln Person zu Person, aber bleiben gleich). – E.164-Konformität: Für externe Rufnummern immer das internationale Format +Land-Vorwahl-Ortsvorwahl-Teilnehmernummer verwenden, ohne Sonderzeichen. Die Benutzer sollten dieses Format kennen und nutzen; interne Verzeichnisse ebenfalls. Das erleichtert globale Kontakte und vermeidet Missverständnisse bei Auslandsvorwahlen.

Beispiel Nummernplan-Schema für ein Unternehmen (fiktiv):

Beispiel: Standort München hat einen eigenen 4-stelligen Block; Berlin nutzt 3-stellig (hier sollte idealerweise auch 4-stellig vereinheitlicht werden – Übergangsphase).

Normalisierung & Wählregeln (Dial Plans): – Landesspezifische Wählmuster: Benutzer neigen dazu, Nummern in gewohnter Weise einzutippen (mit „0“ für Amt, mit oder ohne +). Dial Plans in Teams sollten diese Eingaben automatisch ins E.164-Format übersetzen. Beispiele: – Wird am deutschen Standort „089 123456“ gewählt, normalisiert Teams es zu „+4989123456“. – Wird „0“ am Anfang gewählt, kann Dial Plan diese führende 0 entfernen und Landesvorwahl hinzufügen. – Wahl von „0041…“ sollte zu „+41…“ konvertiert werden (internationaler Präfix). – Unterstützung interner Kurzwahl: Falls interne Kurzwahlen (z. B. „777“ für Helpdesk) genutzt werden, können Dial Plan Regeln diese auf die echte Nummer mappen (z. B. 777 -> +4989zzzz9777). So bleiben Gewohnheiten erhalten, Governance stellt aber sicher, dass solche Mappings dokumentiert und bewusst gestaltet sind. – Notruf-Ausnahmen: Notrufnummern sollen nie durch generische Dial-Pläne verändert werden. Hier ggf. separate Rule an oberster Stelle: ^112$ -> Dial „112“ (also 1:1). Ebenso ^110$, ^911$ etc. je nach Nutzerumfeld. – Blockieren/Sperrlisten: Über Dial Plan oder Calling Policies können unerwünschte Zielnummern gesperrt werden (Toll Fraud Schutz). Etwa: ^0900 (teure ServiceNr. in DE) – Sperren. Oder Premium-SMS/ShortCodes blockieren, falls nicht nötig. – Allowlisten: In hochsicheren Umgebungen kann man stattdessen definieren, was erlaubt ist (z. B. nur nationale und spezifische internationale Ländercodes). Das ist aber pflegeaufwendig – meist fährt man besser mit gezielten Sperren.

Beispiele für Dial-Plan Normalisierungen:

• Eingabe: 004912345678 – Regel: Wenn Zahl mit 00 beginnt, ersetze durch + -> Ergebnis: +4912345678.
• Eingabe: 089123456 (München lokal) – Regel: Wenn Nutzerland = DE und Nummer 9-stellig ohne 0 an Start, füge +4989 Präfix -> +4989123456.
• Eingabe: 0 30 12345 (Berlin Amtsholung) – Regel: Wenn Ziffernblock beginnt mit 0 + zwei-digit Ortscode (30) + rest, ersetze mit +4930 -> +493012345.
• Eingabe: 1234 – interne Durchwahl mit 4 Ziffern – kann so bleiben, Teams erkennt das als internen Anruf, oder man normalisiert zu vollständiger E.164 der Person (wenn Durchwahl eindeutig mapbar).
• Eingabe: #123 – mancher mag # als Indikator für interne. Könnte man unterstützen: Regel cut ‘#’.
• Wählt jemand Ländercode mit + (z. B. +1 212 555..), braucht man nur sicherstellen, dass das + nicht geblockt ist.

Notruf-spezifische Regeln: Zusätzlich können Emergency Dial Strings in Teams konfiguriert werden (z. B. sag 112 ist Notruf und weise „Notfallstandort“ zu). Governance muss sicherstellen, dass diese Strings pro Land hinterlegt sind.

Sperrlisten/Allowlists (Toll Fraud): Aus Governance-Sicht sollte es eine Liste verbotener Rufziele geben: – Premiumdienste (z. B. 0900x in D, 0901 in CH, 09x in vielen Ländern). – Internationale Destinationen, für die keinerlei Geschäftsbedarf besteht (z. B. +872 Satellitentelefone, die extrem teuer sind). – Möglichkeit: „Nur allow“-Liste z. B. alle Länder wo wir Büros haben + gängige internationale. – Prozesse definieren: Wenn jemand dennoch so ein Ziel anrufen muss (z. B. Support in seltenem Land), wie kann temporäre Freischaltung beantragt werden.

Beispiel-Ausschnitt einer Sperrliste (Outbound):

• 0900, 0901 – gesperrt (D/CH Premiumdienste)
• +87 – gesperrt* (Inmarsat/Satellit)
• 118 – gesperrt* (Auskunft in DE, teuer – evtl. wählt man 118xx selber bei uns)
• 00 19 – gesperrt* (Beispiel: fiktiv Land 19, falls Company dort nichts hat)
• 0180 – erlaubt* (Service-Dienste, ggf. erlauben je nach Kosten)
• 112, 110 – immer erlaubt (Notruf – diese sowieso)
• interne Kurzwahl #*, ** – sperren falls keine defin. (um Missbrauch zu erkennen)

Zudem: Outbound anonym sollte nur bestimmten erlaubt sein, was man via Calling Line Identity Policies regeln kann (CLIR). Das gehört auch hier: z. B. blockieren, dass normale User CLIR aktivieren (damit bei Notruf ihre Nummer erscheint!).

Portierungsfahrplan: Wenn Nummern von einem Carrier zum anderen wechseln, ist ein geordneter Ablauf nötig. Governance sollte hier Vorlagen nutzen. Typische Schritte (Tabellarisch):

Sowie Fallback: Für kritische Nummern kann man z. B. Vereinbaren, dass bei Portierungsmisserfolg Umleitung auf Handy aktiviert wird. Das sollte im Plan stehen.

Abschließend: Ein gepflegter Nummernplan und klar definierte Wählregeln sind zentral, um Ordnung, Einfachheit und Sicherheit in der Telefonie zu haben. Mitarbeiter wissen, welche Nummern intern gelten, Anrufe gehen verlässlich raus und rein, und Missbrauch wird vorgebeugt – all das dank dieser klaren Design-Guidelines.

7. Security & Compliance

Die Telefonie-Governance muss sicherstellen, dass Sicherheit (Schutz vor Angriffen und Missbrauch) und Compliance (Einhaltung gesetzlicher und interner Vorschriften) gewährleistet sind. Teams-Telefonie integriert sich hier in die bestehende IT-Sicherheits- und Compliance-Strategie, bringt aber eigene Aspekte mit sich.

Identität und Berechtigungen: Eine grundlegende Sicherheitsleitlinie ist das Prinzip der minimalen Rechte (Least Privilege). In der Praxis heißt das: – Nur Administratoren, die zwingend Telefonie-Einstellungen ändern müssen, bekommen entsprechende Rechte. Microsoft 365 bietet z. B. die Rollen Teams-Administrator, Teams Communications Administrator, Teams Device Administrator etc. Governance legt fest, wer welche Rolle erhält. So könnte ein UC-Engineer die Communications Admin-Rolle haben (kann Telefonie konfigurieren), während ein Helpdesk-Mitarbeiter nur Teams Communications Support Specialist (nur Leserechte auf Call-Analytics) bekommt. Keine generellen Global-Admin-Rechte nur für Telefonie-Aufgaben – das reduziert massiven Missbrauchsspielraum. – Administrative Trennung: Oft wird festgelegt, dass z. B. derjenige, der Routingregeln ändern darf, nicht derselbe ist, der Finanzdaten einsehen darf. In kleinen Teams schwer, aber Governance sollte Dual-Control für kritische Änderungen empfehlen – z. B. Änderungen an Notruf-Routen immer im 4-Augen-Prinzip. – MFA-Zwang: Selbstverständlich müssen alle Admin-Accounts mit Multi-Faktor-Authentisierung geschützt sein. Telefonie-Admins sollten PIM (Privileged Identity Management) nutzen – also Rechte nur bei Bedarf aktivieren, um Risiko zu minimieren. – Benutzerberechtigungen: Normalnutzer erhalten i. d. R. keine Möglichkeit, eigene Nummern zu ändern oder selbst Telefondienste zu buchen – das läuft über IT. Governance legt auch fest, ob Benutzer z. B. selbst „Delegates“ einrichten dürfen (sprich Anruf-Assistenten, Stellvertreter) – meist ja, aber im Rahmen (dokumentieren, wer wessen Stellvertreter ist, falls relevant?). – Gast/Externe: Falls Teams auch Externen PSTN anrufe ermöglichen (selten, meist nein), streng kontrollieren. Standard: Gäste dürfen nicht die Telefonie nutzen.

Änderungs- und Freigabekontrollen: – Change Management: Jede Änderung an der Telefonie-Konfiguration, die den Betrieb beeinflussen kann (Nummernpläne, Voice Routing, SBC-Einstellungen), sollte über den formalen Change-Prozess laufen. D.h. es gibt einen Request, Test, Freigabe (CAB) und Dokumentation. Das verhindert unkoordiniertes Basteln mit potenziell fatalen Folgen (z. B. aus Versehen alle ausgehenden Anrufe blockiert). – Versionskontrolle: Wann immer möglich, Konfigurationssnapshots aufbewahren (z. B. Export der Teams Voice Routing Policies vor und nach Änderung; SBC-Config-Backup archivieren). So kann man bei Fehler schnell auf letzte bekannte Version zurück. – Überwachung von Admin-Aktionen: Das M365 Audit-Log protokolliert, welcher Admin was geändert hat. Governance sollte festlegen, dass diese Logs regelmäßig geprüft werden – sei es stichprobenartig durch IT Revision oder Security-Team, vor allem bei sensiblen Einstellungen (z. B. plötzlich ruft wer die Policy auf, die Notrufe steuert – sollte Alarm schlagen). – Notfalländerungen: Gibt es in der Nacht ein Problem und ein Admin muss eine Änderung außerhalb Normprozess machen, gilt: so bald wie möglich nachdokumentieren und in nächsten CAB besprechen. Das per Policy festlegen.

Toll-Fraud-Schutz & Missbrauchserkennung: – Sperrlisten & Limits: Wie in Nummernplan (Sperrlisten) erläutert, technische Barrieren gegen teure Anrufe setzen. Zusätzlich: – Outbound Call Limits pro Benutzer: Microsoft Teams bietet via Communication Credits die Möglichkeit, Kosten zu deckeln. Eine gängige Praxis: Für Auslandsgespräche keinen unlimitierten Pay-as-you-go nutzen, sondern Prepaid-Guthaben (Communication Credits) mit automatischer Aufladung deaktiviert. So kann ein Fraud maximal das Guthaben leeren, dann stoppt es. Governance kann anordnen: „Keine automatische Aufladung von Telefon-Guthaben aktivieren.“ – Bei Direct Routing hat man so eine Mechanik nicht, dafür definieren viele SBCs Call Budget per User (wenn unterstützt). Alternativ: „Carrier-Sperre“ – viele Provider bieten an: „Internationale Anrufe > X € pro Tag blockieren“. Solche Provider-Features nutzen, in Absprache. – Anomalieerkennung: Ein detektiv Mechanismus: – Richten Sie Monitoring ein, das ungewöhnliches Verhalten erkennt. Beispiele: Ein Benutzer ruft nachts um 3 Uhr auf einmal 50 Auslandsgespräche an – sehr verdächtig. Oder plötzliche Häufung kurzer Anrufe auf Premium-Nummer. – Microsoft Cloud App Security (Defender for Cloud Apps) kann z. B. mit Policies Teams-Aktivitäten überwachen. Auf Telefonie bezogen begrenzt, aber man könnte CDRs exportieren und von SIEM auswerten. – Minimallösung: Täglichen Anruf-Report im Excel automatisch checken (Makro/Script), z. B. sum duration pro user, if user > 8h am Tag telefoniert -> Flag. – Alerting: Governance: definieren, ab welchen Schwellen Alarm an Admin geht. Z. B. „Wenn Ausgaben für Telefonie in einem Tag > 500€ -> Alarm an Finanzen & IT-Sec“. – Reaktionsplan Fraud: Eine definierte Vorgehensweise, wenn Verdacht auf Missbrauch: 1. Sofort betroffenen User-Account sperren (zumindest ausgehend). 2. Provider kontaktieren, bitten um temporäre Blocks falls via Direct Routing relevant. 3. Forensik: Logs sichern, Nummern identifizieren. 4. Strafverfolgung erwägen (Polizei bei Betrugsanruf von extern etc.). 5. Schlupflöcher schließen (z. B. Passwortrichtlinie verschärfen falls Account kompromittiert). – Authentifizierung & Autorisierung streng: – Telefonie-spezifisch: In alten Systemen gab es PINs für Ausland oder Code, in Teams ist alles Account-basiert. Also Account-Sicherheit = Telefonsicherheit. Schulung Mitarbeiter: Use strong password, be wary of phishing (denn Account-Klau -> Anrufe in teuere Länder). – Einführen Conditional Access: z. B. blockiere Teams-Anmeldung aus Ländern, wo wir keinen Mitarbeiter haben (so kann ein Hacker aus Übersee nicht mal reinkommen um Anrufe zu initiieren). – Voice Apps Missbrauch: Bot in Teams, der auto anruft? Evtl. überwachen, dass keine unbekannten Apps Anwahlfunktionen nutzen (App governance). – Reporting line für Missbrauch: z. B. Mitarbeiter sollen wissen: falls ihnen Ungewöhnliches auffällt (z. B. auf ihrer Rechnung ruft es Bahamas an, was sie nicht taten), wo melden sie das unverzüglich.

Kostenlimits & Alerts: – Budgetkontrolle: Abteilungsweise Telefon-Budgets definieren, und IT liefert monatlich Report. Nicht primär Security, aber motiviert zur Überwachung. – Realtime-Kostenmonitor: Manche Carrier-Portale haben Live-Kosten. Die Finanz- oder IT-Abteilung sollte sie im Blick haben. – Benachrichtigung Benutzer: Falls ein einzelner Anruf sehr teuer auszufallen droht (lange Dauer), kann man keinen Live Alarm an user geben – aber man kann z. B. definieren: „Nach 2 Stunden Gespräch wird Verbindung getrennt oder warn tone“ – kann SBC/Provider oft. Abwägen: z. B. Vorstand call droppen doof; evtl. lieber Alarm intern.

Aufzeichnung/Recording & Datenschutz: Viele Unternehmen müssen Gespräche aufzeichnen (z. B. Finanzhandel, Kundenservice-Qualität) oder möchten es optional anbieten. Governance muss Recording streng regeln: – Zweckbindung & Rechtsgrundlage: Klar definieren, warum aufgezeichnet wird. Z. B. „zur Erfüllung gesetzlicher Vorgaben (MiFID II in Investmentbereich)“ oder „zur Qualitätssicherung mit Einwilligung“. – Transparenz: Es muss sichergestellt sein, dass alle Beteiligten wissen, wenn aufgezeichnet wird. Technisch: Teams zeigt Banner „This call is being recorded“. Organisatorisch: Kunden vorab per Ansage warnen („Dieses Gespräch kann zu Trainingszwecken mitgehört werden…“). Mitarbeiter vertraglich oder via BV zustimmen lassen, falls nicht ohnehin gesetzlich Pflicht. – Genehmigungspflicht: Policy: Aufzeichnung darf nur erfolgen, wenn vom Compliance-Team freigegeben. D.h. kein Mitarbeiter startet mal eben Mitschnitt auf Verdacht (Deshalb kann man user-initiated recording für PSTN ausschalten via Teams Policy). – Begrenzter Zugriff: Die Speicherung der Mitschnitte (z. B. in einem Compliance-Recording-System) muss sicher geschehen – verschlüsselt, mit Zugriff nur für definierte Rollen (z. B. Compliance Officer). – Aufbewahrungsfristen: Entsprechend Gesetzen definieren. z. B. „Callcenter-Aufzeichnungen werden nach 90 Tagen automatisch gelöscht, außer sie werden für Schulungen markiert (Max 1 Jahr).“ Oder „Handelsgespräche 5 Jahre Aufbewahrung (MiFID)“. Microsoft Purview kann hier angepasste Retention Policies auf Meeting- und Anrufaufzeichnungen anwenden – nutzen Sie das. – Betriebsratsvereinbarung: In Deutschland etwa unabdingbar, wenn Mitarbeitergespräche aufgezeichnet werden (auch wenn nur zu Kundenzwecken). Governance muss sicherstellen, dass so eine BV existiert und eingehalten wird (z. B. „es werden keine Leistungsdaten erhoben“, „Mitarbeiter können Aufzeichnung jederzeit stoppen“). – Verfahrensdokumentation: Das Recording-Verfahren (welches System, wo gespeichert, wer Zugriff) sollte in Datenschutzerklärung und internem Verzeichnis der Verarbeitungstätigkeiten stehen – Compliance-Team zuständig, aber UC liefert Input. – No Silent Monitoring ohne Zustimmung: Falls man „heimliches“ Mithören (früher barging) in Teams einführen wollte, streng verboten ohne Mitbestimmung. Eher definieren: Supervisor kann sich per Teams-Funktion in Kundengespräche mit einblenden, aber nur nach Signalisierung. Und regeln, wie Missbrauch verhindert (z. B. Logging supervisor join). – Abhören und Strafverfolgung: Sollte Polizei richterlich angeordnete Überwachung verlangen (selten, aber in Telko kann), wissen wer intern das technisch umsetzt (um notfalls Kooperationsfähigkeit zu beweisen). Teams hat kein built-in Lawful Intercept, man müsste Recording-Bot vorschalten. – Schulung: Mitarbeiter in aufgezeichneten Rollen sind zu schulen im Umgang („Wie informiere ich den Kunden? Wo kann ich Aufzeichnung pausieren, falls Kunde z.B. Kartendaten mitteilt – datenschutz?“). Governance definieren diese SOPs.

Protokollierung & Audit: – Anrufprotokolle: Alle Verbindungsdaten (Wer rief wann wen wie lange an) werden von Teams erfasst. Diese CDRs (Call Detail Records) sind für Abrechnung und forensische Analysen wichtig. Governance sollte festlegen, dass diese Daten (sofern vorhanden) regelmäßig gesichert werden. Microsoft hält sie 90 Tage in CQD, länger nur via Export. Also Policy: „Monatliche CDR-Exporte ins Data Warehouse, Aufbewahrung 1 Jahr“ – so hat man Historie (auch etwa für interne Ermittlungen, wenn Missbrauchsvorwurf). – Admin Audit Logs: Schon erwähnt – Teams Admin Center Log (wer hat welche Policy verändert etc.) – Standardbehalten 6 Monate. Hier evtl. länger sichern, falls Prüfungen (z. B. ISO 27001 Audit will Nachweis der Änderungen). – Telefonie-spez. Audits: Z. B. im Rahmen von SOX/IKS-Kontrollen einmal im Jahr prüfen: Hat jede Telefonnummer einen Besitzer? Sind ungenutzte deaktiviert? War Nummernplan-Review? Hat man Notruf-Funktion geprüft? Solche Audits in den jährlichen Auditplan aufnehmen. – Evidenzablage: Für jede Kontrolle (z. B. quartalsweiser Notruftest) sollte ein Nachweis existieren – z. B. Testprotokoll. Governance kann zentral ein „Telefonie Compliance Ordner“ führen, wo alles gesammelt wird. Das erleichtert externe Audits (man hat gleich parat: letzte BR-Freigabe Recording, letzte Notrufübung, etc.). – Zugriffslogs & Privacy: Falls gefordert, kann man Logs auch nutzen, um unzulässiges Verhalten aufzudecken (z. B. Abteilungsleiter checkt, ob Mitarbeiter X wirklich 8h telefoniert hat). Das ist datenschutzrechtlich heikel – man sollte Transparent machen, wofür Telefondaten genutzt werden (z. B. Abrechnung, Kapazitätsplanung, aber nicht zur Verhaltenskontrolle, außer Missbrauchsverdacht). – Legal Hold/eDiscovery: In Teams landen voicemails etc. in Exchange und können mit eDiscovery durchsucht werden. Governance/Compliance definieren, wer das darf (z. B. nur Legal Dept via eDiscovery-Case) und unter welchen Umständen (rechtlich zulässig). – Notfall-Dokumentation: Im worst case (z. B. es gab Notrufproblem) muss man Infos liefern. Also Logging von Notrufen (vielleicht separate Kennzeichnung) – check ob Provider Receipts hat, und evidenz wir reagiert.

Zusammengefasst verlangt die Security-&-Compliance-Governance, dass Telefondienste absolut vertrauenswürdig betrieben werden: Keine offenen Scheunentore für Angreifer, kein Wild-West bei Aufzeichnungen, klare Revisionsspuren aller Aktionen und ein proaktiver Ansatz, um Regelverstöße zu verhindern oder sofort zu erkennen. Telefonie wird so vom potenziellen „Soft Spot“ zu einem sicher kontrollierten Bestandteil der IT-Landschaft.

8. Notruf, Business Continuity & Desaster Recovery

Auch in der Cloud-Telefonie braucht es Konzepte für Notfälle, Betriebskontinuität und Desasterfälle. Was passiert, wenn ein wichtiger Dienst ausfällt? Wie können Mitarbeiter im Notfall kommunizieren? Diese Fragen werden hier adressiert.

Notruf-Richtlinien & Tests: (Fortsetzung von Szenario 5.4) – Bereits beschrieben haben wir das Standort-/Notrufkonzept. Wichtig ist hier noch einmal die Operationalisierung: – Notfall-Richtlinie: z. B. „Im Notfall ist die Sicherheit der Mitarbeiter höher zu gewichten als jegliche andere Erwägung – notfalls sind alternative Kommunikationsmittel einzusetzen.“ Praktisch: Wenn Teams-Telefonie ausfällt, müssen Mitarbeiter wissen, dass sie z. B. ein Mobiltelefon für 112 nutzen sollen. Das sollte in Notfallinstruktionen stehen. – Dokumentation: Jede Standort hat einen Emergency Communications Plan, in dem steht: Wo sind Festnetz-Nottelefone? Wer sind Ersthelfer, die alternative Wege haben? Z. B. im Evakuierungsplan vermerken, dass es z. B. rote Analogtelefone gibt, falls IT ausfällt. – Regelmäßige Tests: intern (mit internen Notfallnummern) und mit echten Leitstellen nach Absprache. Der Test-Output (Protokoll) wie gesagt ablegen. – Haftungskette: Wenn Outage – wer alarmiert wen? Z. B. IT-Leiter muss GF informieren, falls Notrufe nicht gehen, da es meldepflichtig (ggf. an BNetzA?). Solche Pflichten klären.

Business Continuity (BC): Der Plan, wie der Telefonie-Service bei begrenzten Störungen weiterläuft. – Lokale Redundanz: Falls ein Standort die Internetverbindung verliert, sollte es Backup-Wege geben: – Survivable Branch Appliance (SBA): Diese kleine Komponente (AudioCodes, Ribbon etc.) kann bei WAN-Ausfall lokale Anrufe und PSTN über dortigen SIP-Trunk weiter ermöglichen. Im BC-Plan: Für Standorte > X Personen ohne zweite Leitung SBA vorsehen. – Zweite Internet-Leitung / 4G-Fallback: In Zeiten von Cloud oft pragmatischer: Backup-DSL oder LTE-Router, worüber Teams notfalls weitertelefoniert (vielleicht mit reduzierter Quali, aber geht). BC-Plan: definieren, welche Standorte so ein Backup haben und wie Umschalten erfolgt (SD-WAN auto failover, etc.). – Cloud-Ausfall: Wenn Microsoft Teams Dienst selbst down ist (selten, aber vorkam), BC-Strategie: – Notfall-Ersatzkommunikation: Alle Mitarbeiter haben z. B. die Handy-Nummern wichtiger Kollegen oder sind in einer WhatsApp-/Signal-Gruppe – damit man wenigstens ad hoc kommunizieren kann, „Teams down, wir arbeiten an Problem“. – Analoges Backup: Einige Unternehmen behalten ein Notfalltelefon (z. B. klassisches Telefon am analogen Anschluss oder GSM-Gateway) pro Standort, um im Falle totalen Cloud- oder WAN-Ausfalls einen Anruf extern tätigen zu können. BC-Plan: Standorte definieren und regelmäßig testen („heißer Draht“). – Vertrag mit Telefondienstleister: Manche schließen z. B. einen parallelen minimalen SIP/Hosted-PBX als Reserve. Realistisch seltener; aber Option: Wenn Teams längeren Ausfall hat, notfalls in paar Stunden in Cloud PBX umschalten (nur, wenn vorbereitet). – Benutzer-Seite: Was tun, wenn z. B. ein Executive im wichtigen Call war und Teams bricht ab? – Plan definieren: z. B. „Sollte Teams Meeting ausfallen, Teilnehmer rufen per Telefon-Einwahlkonferenz an (Audiokonferenz-Backup)“. – Oder direkte fallback Bridge (z. B. Company hat separate Audio-Brücke). – Provide Info-Kärtchen: „If conf fails, dial +49… ConfID…“ – vielen Firmen haben so was. – Client-seitiges Problem: Falls z. B. der Teams-Client oder PC ausfällt – jeder sollte Alternativen kennen (Handy-App, Webclient etc.). Schulung: Notfalloptionen: „Wenn Ihr PC streikt, können Sie die Besprechung per Telefon betreten (Dial-in)…“. – Wartungspausen: BC auch, dass man planbare Ausfälle managt. Z. B. SBC Firmwareupdate – Plan: kippe Traffic auf Zweit-SBC (daher keine Unterbrechung). – Kontakt mit Providern: BC-Plan enthält Notrufnummern der Partner (z. B. SIP-Provider 24/7 NOC). Bei Ausfall z. B. Carrier-Netz: IT ruft dort an. – Kommunikationsplan: Wer informiert die Nutzer bei Störung? Z. B. IT schickt E-Mail oder SMS-Verteiler: „Derzeit Telefonie gestört, bitte Handy nutzen – Update folgt“. Das sollte in BC drin stehen (ggf. Vorlage-Messages). – Kritische Funktionen Liste: Identifizieren, wer unbedingt erreichbar sein muss (z. B. Service Desk extern, Krisentelefon). Für die evtl. separate Backup-Handy vorhalten, oder Multi-SIM-Lösung (OCM Mobil? Oder Cloud Twinning). – Dauerhaft analoges Backup: Bestimmte kritische Infrastruktur (Aufzugnotrufe, Alarmwählgeräte) belässt man autark analog. Das ist auch BC: Sie funktionieren unabhängig vom IT-Ausfall – was gewollt. Dokumentieren, dass diese NICHT zu Teams migriert wurden, aus BC-Gründen.

Desaster Recovery (DR): Umgang mit größeren Katastrophen (z. B. kompletter Rechenzentrums- oder Standortausfall). – SBC-Failover: DR-Plan sollte beinhalten: Wenn primärer SBC (im eigenen Rechenzentrum) total zerstört (Brand etc.), ein zweiter an anderem Ort übernimmt. – Test: 1x/Jahr Simulation RZ-Ausfall – z. B. SBC2 manuell als Primary nehmen, komplett über den laufen, alles ok? – Provider-Failover: Wenn ein ganzer Telefonanbieter ausfällt (gab es z. B. Ausfall eines großen Cloud-PBX Providers, Kunden tagelang offline) – was tun? – Evtl. Vertrags-Klausel: SIM-Karten oder Backup-Carrier bereithalten. – DR-Plan: im Notfall portieren wir Hauptnummer auf Mobiltelefon XY (kann schnell gehen: Mobilfunker können Rufumleitung vom Amt set up in Not). – Oder nutzen interne Not-Hotline (SIP-Konto bei anderem Carrier). – Standortausfall: Z. B. Büro unbenutzbar – Telefone offline. Hier greift generelles BC: Mitarbeiter im Homeoffice -> haben Laptops -> Teams mit 4G -> Telefonie läuft (sofern Cloud intakt). – Also Team ermöglicht mobiles Arbeiten – was Telefonie resilient macht. – Plan: im Notfall werden Anrufe auf Mitarbeiterhandys/Softphones umgelegt – cloudbasiert kein Problem. – Reihenfolge der Wiederherstellung: DR-Runbook definieren: Was hat Priorität? Z. B. Notrufe Routen, Hauptleitungen, dann rest. – Daten-Backups: Konfiguration hat man, aber Sprachaufzeichnungen etc. – DR plan: Offsite Backup der compliance recordings (um Regularien zu erfüllen, falls RZ futsch). – Übungen (Drills): – Tabletop-Übung: Das Team geht ein Szenario theoretisch durch („HQ ausgefallen – Telefonieplan?“). – Technische Drills: z. B. tatsächlich mal primären WAN Link kappen, sehen ob Failover-Sprachqualität okay. – Ausfall M365 Simulations: In Grenzen testbar (vlt. Tenant offline simulieren durch Block?). Kann man kleine Simulation durchspielen, z. B. so tun „Teams tot – verteilen Handys“. – Dokumentation: Ein DR-Handbuch, physisch greifbar (digital nützt nichts, wenn Netz weg!). Darin alle Notfallkontakte, Settings, Alternativmethoden. – Lessons Learned: Nach echtem Ausfall, egal wie klein, Review: Was hat gut/schlecht geklappt? Plan anpassen.

Runbooks & Checklisten für Notfälle: Vorbereitet: – Runbook: „Telefonausfall – immediate actions“: Enthält: Wer (Name, Handy) wird angerufen? (z. B. Telefonie-Admin, Provider). Welche Systeme prüfen (SBC ping, Teams Admin Center status)? Welche Umgehungen initial (Notfallhandy an Empfang)? – Runbook: „SBC totalausfall/Failover“: Step-by-Step, vordefiniert in SBC config teils. Der Admin braucht nur folgen. – Runbook: „Wiederanlauf nach Outage“: Nach Wiederherstellung testen: z. B. eingehend, Notruf, etc. Und Inform User „Störung behoben“.

Beispiel: Notfall-Checkliste (verkürzt)

• Strom/Netzausfall im Gebäude: → Mobiltelefone nutzen, eventl. analoges Notfalltelefon im Foyer verwenden. Inform interne Sicherheit.
• WAN-Ausfall: → Fallback-Leitung aktiv? (Check Backup-Router Lämpchen). Falls nein: Standby-SBA übernimmt PSTN (Check Amtton am analogen Notapparat im Serverraum). Kommunikation an Users: „Nutzen Sie mobiles Internet oder Handy.“
• Cloud-Ausfall (Teams Service down): → Interne Durchwahlkette oder E-Mail Alert an alle: „Telefondienst derzeit gestört – nutzen Sie alternatives Mittel. Notrufe per Mobiltelefon!“.
• Provider PSTN-Ausfall: → Schalten Sie Routing aller ausgehenden Anrufe temporär auf alternativen Carrier (im SBC-UI Template laden). Hauptempfang: Portiere auf Handy (Anruf bei Carrier NOC).
• Notruf funktioniert nicht: → Sofort rote Alarmkette: All-Hands on deck, fix config oder route Notruf über Handy der Empfangskraft. Bis Fix: Wachdienst an Pforte positionieren mit Handy für 112.

Mit robusten BC/DR-Maßnahmen und regelmäßig geübten Notfallszenarien stellt man sicher, dass auch im Unglücksfall oder bei technischen Pannen die Erreichbarkeit – vor allem für Notfälle – gewährleistet ist. Telefonie ist ein kritischer Dienst; Governance bedeutet hier, nicht allein auf die Cloud-Verfügbarkeit zu vertrauen, sondern proaktiv Puffer und Pläne einzubauen, damit niemand im Stich gelassen wird.

9. Netzwerk & Qualität (QoS)

Eine exzellente Sprachqualität ist für die Akzeptanz der Teams-Telefonie essenziell. Daher definieren Governance und IT klare Anforderungen an das Netzwerk und Mechanismen zur Sicherstellung der Quality of Service (QoS).

Qualitäts-Kennzahlen & Grenzwerte: – Die klassischen Metriken sind Latenz, Jitter, Paketverlust und MOS. Als Leitlinie gelten: – Latenz (One-Way): sollte < 50 ms innerhalb des Unternehmensnetzes bleiben, maximal ~100 ms one-way bis zum Microsoft-Edge. Alles über 150 ms (300 ms Roundtrip) macht Gespräche spürbar verzögert. – Jitter: (Schwankung der Laufzeit) Ziel < 30 ms. Hoher Jitter erzeugt Aussetzer. – Paketverlust: Ziel < 1 % für Audio. Bereits 5 % Loss machen Sprache schlecht verständlich, also streng minimieren. – MOS (Mean Opinion Score): Skala 1 (schlecht) bis 5 (super). Ziel-MOS > 4,0. Ein MOS < 3,5 gilt als „schlechte Qualität“ und sollte < 5 % der Anrufe betreffen. – Diese Werte definieren wir in der Governance als SLA intern: z. B. „Mindestens 95 % aller Anrufe sollen MOS >= 4 haben.“ – Für Video sind die Schwellen etwas toleranter (höhere Bandbreite, Bild erträgt minimal mehr Loss), aber Fokus oft auf Audio, da Telefonie primär.

End-to-End-Betrachtung: Das Telefongespräch durchläuft viele Segmente: – Client-Gerät: z. B. PC-Headset-Kombination. Schlechte Hardware oder CPU-Auslastung kann Audio stören. Governance: zertifizierte Geräte fordern und PC-Richtlinien (kein CPU-hungriger Scan während Calls). – LAN: Lokales Ethernet – sollte mit genügend Kapazität und sauberer Konfiguration (Full Duplex, keine Fehler) laufen. Switches sollten QoS-Markierungen nicht löschen. – WLAN: Falls WLAN-Calls (z. B. mit Smartphones oder Laptops), muss WLAN Enterprise-Klasse sein: genügende Abdeckung, airtime Management. QoS in WLAN = WMM (Wireless Multimedia) aktivieren, sodass Voice-Pakete in die hohe Prioritäts-Warteschlange gehen. – WAN/Internet: Hier entscheidet sich viel. Direkter Internet-Breakout pro Standort reduziert Latenz (statt erst über MPLS zum Hub). Governance schreibt vor: „Voice-Traffic soll so lokal wie möglich ins Internet geleitet werden.“ (Microsoft hat viele Edge-Server global). – Microsoft Cloud: Darauf hat man weniger Einfluss, aber MS betreibt ein optimiertes Backbone. ExpressRoute für Teams Voice wird von MS nicht mehr empfohlen (normales Internet mit QoS reicht). – PSTN-Carrier: Bei QoS relevant, aber per SIP weitgehend fertig – man kann hier im SLA fordern, dass Carrier kein unnötiges Transcoding etc. macht.

QoS-Konfiguration: – DSCP-Tagging: Teams kann Audio-, Video- und ScreenSharing-Pakete mit DSCP-Werten markieren, wenn auf Clients so eingestellt (Policy). Standard: Audio = DSCP 46 (EF – Expedited Forwarding), Video = DSCP 34 (AF41), ScreenSharing = DSCP 18 (AF21). Governance sollte vorschreiben: – Diese Werte sind tenant-weit einzustellen und in der Netzwerkinfrastruktur zu honorieren. – D.h. Switches/Router dürfen DSCP nicht nullen; Firewalls sollten die Tags weiterreichen. Falls das nicht geht (manche VPN/ISP streifen DSCP), intern so gut wie möglich durchsetzen und Engpässe identifizieren. – Priorisierung: In der Unternehmens-WAN-Architektur müssen für Sprachverkehr dedizierte QoS-Queues eingerichtet werden. Z. B. Reserviere 10–20 % Bandbreite für EF (Voice) mit Highest Priority Queue, 20 % für AF41 (Video) Next Priority, Rest für Daten (depriorisiert, wenn Engpass). Das wird in Routern/Switches konfiguriert. – Segmentierung: Empfohlen: – Voice-Geräte (IP-Telefone) können im eigenen VLAN mit QoS-Einstellungen sein. So vermeidet man, dass broadcast storms etc. Voice beeinflussen. Laptops sind gemischt, aber man priorisiert per DSCP. – Ein separates VLAN für Teams-Devices (Konferenzraumgeräte etc.) kann helfen, aber nicht zwingend. – Internet Breakout: Der Grundsatz „lokal raus“ erfordert, dass evtl. ein Proxy umgangen wird – Proxys erzeugen oft Latenz. Für Teams Real-Time sollte ein Proxy-Ausnahme erfolgen (Direct Routing HTTP/S). Der Governance-Beschluss: „Keine Proxy-Induktion auf Teams-Medien; falls Proxy nötig, dann im Bypass für .teams.microsoft.com etc.“ – SD-WAN: Viele setzen SD-WAN ein. Hier muss konfiguriert werden, dass – Teams-Voice-Verkehr erkannt wird (via Application Signature oder Port/DSCP) – und bevorzugt die beste Pfad bekommt (z. B. geringer Latenz Pfad) – und bei Verlust Link failover (einige SD-WAN machen parallele Pakete oder FEC). – Governance: Netzwerk-Team muss diese App-Signaturen pflegen und überprüfen nach Updates. – Kapazitätsplanung: – Schätzen: pro aktivem Audiostream ca. 50–100 Kbit/s (je nach Codec, mit Overhead). Multiplypeakcalls. – Für 100 gleichzeitige Anrufe ~10 Mbit/s. – Governance: vor Inbetriebnahme in Standort X sicherstellen, dass X Mbit Reserve für Voice im Upload wie Download vorhanden. Tools wie MS Teams Bandwidth Calculator nutzen. – Falls Netz saturiert: Upgrades veranlassen. – Netzwerkredundanz: Mindestens auf Hauptstandorte doppelte Uplinks etc. – (Siehe BC). – Peering/ISP-Wahl: Ideal wählt man Internetprovider, die ein gutes Peering mit Microsoft haben (geringe Hops). Beim ISP-Wechsel Governance: test Latenz zu Teams region front. – Firewall Ports:* Sicherstellen, dass alle Teams Ports offen: UDP 3478-3481 (STUN), UDP 50k-50k59 (Media), TCP 443 (Fallback). Sonst fließt Traffic not optimal.

Überwachung & Alarmierung: – Teams Call Quality Dashboard (CQD): Das UC-Team sollte monatlich Quality-Reports generieren: z. B. „Anteil schlechter Anrufe nach Standort“. – Wenn an Standort A 20 % der Calls poor (MOS < 3), muss investigiert werden (evtl. WLAN Problem etc.). – Governance: definieren, ab welchem Schwellenwert eine Problem-Location eskaliert wird (z. B. > 5 % poor calls → Ticket ans Netz-Team zur Untersuchung). – Echtzeit Telemetrie: Teams Admin bietet Real-Time Analytics pro Call. Für NOC-Einsatz gibts Tools (z. B. Martello, Nectar) – optional. – Netzwerkmonitor: Zusätzlich sollte das Netzwerkteam die Parameter messen (SNMP, NetFlow) – z. B. jitter per WAN link falls Device support. – Dashboards: Ein integriertes Dashboard könnte zeigen: MOS by site, Last by trunk, etc. KPI trending. – Schwellen & Alerts: – Alert, wenn an einem Standort > X Anrufe mit Packet Loss > 5 % in letzter Stunde. – Alert, wenn Latenz Sprung über definierte ms. – Oder Trigger via SD-WAN events (failover event → potentielle Quality degrade). – Eskalationspfad: Legt fest: erst UC-Team analysiert (vllt. sieht jitter → an Netzwerk-Team escalate). Netzwerk-Team prüft Router/WAN-Auslastung. Ggf. Carrier einbinden (Line degrade). – Root Cause Analysis (RCA): Nach jedem größeren Quality-incident (z. B. „Ganzer Standort klang blechern für Tag“) schriftliche RCA: Was war Ursache? (z. B. Paket Loop in LAN). Welche Maßn. zur Verhinderung? (Switch config fix etc.). – Reporting: QoS-Kennzahlen in Management-Report (z. B. als Teil IT-KPI-Bericht) aufnehmen, damit Führung sieht: Telephony quality trending stable oder besser.

Einsatz von Tools: Falls nötig, Third-Party „Active Probing“ Tools einsetzen: Kleine Box sendet periodisch VoIP-Test an Cloud, misst jitter, etc. Kann an entlegenen Standorten früh warner sein. Governance: optional, falls signifikant.

Nutzer-Feedback: Ermuntern, dass User nach Call den Quality rating ausfüllen. Und intern auswerten, was sie angeben (Teams speichert diese Ratings). Das qualitativ verstärkt Metriken.

Netzwerk-Richtlinien-Pflege: – Integraler Bestandteil der Telephony-Governance ist, dass die Netzwerk-Governance Punkte (wie wir definieren) mit einschließt. Also in Netz-Richtliniendokument verankern, dass „Real-Time-Verkehr Priorität 1 genießt“. – Und bei jeder Netzwerkänderung (neues VLAN, neue WAN-Provider) Telephony-Anforderungen checken. Evtl. Checkbox im Change Request: „Impact on Voice: JA/NEIN – wenn ja, UC-Team consulted.“ – So wird QoS bei allen Netz-Projekten immer mitgedacht.

Im Ergebnis sorgt diese strenge QoS-Governance dafür, dass „Telefonieren mit Teams“ zu jeder Zeit so gut wie oder besser als klassisch ist: keine Abbrüche, klarer Klang. Und falls doch Störungen auftreten, werden sie systematisch erkannt und behoben, bevor sie zum Flächenbrand werden.

10. Betrieb, Support & Service Management

Die Einführung von Teams-Telefonie muss von einem tragfähigen Betriebs- und Supportmodell begleitet werden. Governance bedeutet hier, klare Prozesse für den täglichen Betrieb, den Anwendersupport und das Service Management festzulegen, sodass der Telefoniedienst reibungslos läuft und kontinuierlich verbessert wird.

Operating Model & Support Levels: – Mehrstufiger Support: Definieren Sie die Support-Level und deren Aufgaben: – Level 1 (Service Desk): Nimmt alle Telefonie-bezogenen Anfragen und Störungen entgegen (z. B. „Ich kann nicht telefonieren“, „mein Headset geht nicht“). Erledigt grundlegende Hilfestellung (Client-Neustart, Gerät prüfen, einfache FAQs) und kann Standard-Requests (wie PIN zurücksetzen, Telefoneinrichtung nach Dokumentation) durchführen. – Level 2 (UC-Administrationsteam): Übernimmt komplexere Fälle, z. B. Qualitätsthemen, Routingprobleme, Nummernportierung. Hat tieferes Know-how in Teams Admin Center, SBC etc. L2 analysiert auch Call-Logs für Ursachen. – Level 3: Das sind entweder interne Experten (Senior UC-Architekt) oder externe Partner/Microsoft Support. Fälle wie unerklärliche Systembugs oder große Ausfälle, die L2 nicht lösen kann, gehen hier hin. – Zuständigkeiten & OLA: Zwischen den Support-Teams sollten Operational Level Agreements stehen, z. B. L1 diagnostiziert innerhalb 30 min, dann eskaliert an L2, L2 beginnt Bearbeitung < 1h etc. Dies stellt sicher, dass kein Ticket versackt. – Tickets & Kategorien: Das ITSM-System soll spezifische Kategorien für Telefonie haben (z. B. „Teams-Anrufqualität“, „Nummernproblem“, „Anrufqueue Problem“). Governance fordert das, damit man Berichte ziehen kann („wie viele Telefonie-Incidents pro Monat, Trending?“). – MTTR & SLAs: Interne Service-Ziele definieren: – z. B. Priorität 1 (Telefonie gesamt ausgefallen): MTTR 4 Stunden. – P2 (ein Standort oder wichtiger User kein Telefon): 1 Arbeitstag. – P3 (einzelner User Problem): 3 Tage. – Solche Werte in SLA-Dokument mit Business festhalten. So weiß Business: worauf können wir uns verlassen. Und IT misst, ob sie es schaffen. – Rufbereitschaft: Falls 24/7-Erreichbarkeit gefordert (vielleicht bei kritischer Produktion), definieren, wer nach Feierabend Incident annimmt. Evtl. rollierende Rufbereitschaft im UC-Team, oder man kauft beim Provider 24/7 Support mit ein. Wichtig: Die Stakeholder (z. B. Notfallmanager) kennen den Ablauf „Wen rufe ich nachts um 3 an, wenn Telefon tot?“. – Dokumentation im Betrieb: Ein Telefonie-Betriebshandbuch sollte vorliegen, mit allen Standard-Workflows (z. B. „Neuen Mitarbeiter mit Telefon ausstatten“) und Troubleshooting-Guides (z. B. Flowchart: „User kann nicht rauswählen“ -> check Lizenz, check Dial Plan, etc.). L1 kann sich daran orientieren.

Kapazitäts-, Patch- und Release-Management: – Kapazitätsmanagement: Überwachen, ob genügend Ressourcen da sind: – Sind genug Phone System Lizenzen verfügbar (z. B. E5 lizenzen count)? – Ist der SBC nicht an max Auslastung (Kanäle)? – Planen, wann man aufstocken muss (z. B. bei Expansion früh neue Nummernblöcke sichern). – Bericht an Management, falls Engpässe absehbar (Budget für Upgrades). – Patch Management: Teams-Client und Cloud aktualisieren sich automatisch, aber: – Teams Devices (Phones, Room Systems): Betrieb muss firmware updates verfolgen (via Teams Admin Center lassen sich steuern). Governance: definieren, dass z. B. alle 3 Monate neueste zertifizierte Firmware aufgespielt wird, nach kurzem Test an einem Gerät. – SBC/Direct Routing Komponenten: Brauchen regelmäßige Security-Updates. Zeitnah (innerhalb 4 Wochen nach Release) einplanen, via Change mgmt. – Netzwerk-Geräte: QoS relevant – Switches/Router updates nicht vernachlässigen, falls alt bug QoS broken etc. Also generelle IT Patch Policy nutzen, aber Telephony aware (z. B. kein reloading midday). – Release Management (Neue Features): Microsoft bringt ständig neue Teams Phone Features (z. B. im Jahr 2023 kam Operator Connect Mobile, 2024 vielleicht SMS-Funktion etc.). – Governance sieht vor, neue Funktionen erst nach Prüfung zu aktivieren (nicht gleich auf Alle). In großen Umgebungen: – Ring-Konzept: Erst IT-Pilot, dann Early Adopter, dann global. – Oder man lässt es standard aus und nur auf Wunsch an (z. B. „Walkie Talkie“-App in Teams wäre potentielle Störung, daher aus). – Änderungskommunikation: Wann immer Microsoft UI/UX ändert, die Nutzer beeinflusst, muss der Betrieb proaktiv informieren oder Trainingsmaterial anpassen. Z. B. neue „Anrufe“-App UI – ideal: Knowledge-Artikel bereitstellen vorab. – Regression-Tests: Bei kritischen Apps (Callcenter Integration) sollte man im Tenant Public Preview nutzen oder isolierten Test-tenant, um kommende Versionen zu prüfen. So können Integrationsprobleme (z. B. Recording-Lösung vs. neue Teams Version) früh erkannt werden. – Der Betrieb braucht also Infos, wann was kommt: Abonnieren M365 Roadmap, TechCommunity etc. – Change Kommunikation (User): Gute Praxis: monatlicher „Teams Update“-Newsletter an Mitarbeiter: was gibts Neues, was ändert sich. Verhindert Supportanfragen („Wo ist jetzt mein Wählpad hin?“ nach UI-Update). – Backup/Restore: Cloud hat kein traditionelles Backup. Aber – man kann z. B. Konfiguration sichern (export policies etc. wie oben). – Der Betrieb muss wissen: Voice Mails liegen in Exchange (sind im Mailbackup), Anrufverlaufs in mailbox auch – also generelle Exchange-Sicherung deckt ab. – Was ist mit Kontakten? (User hat PSTN Kontakte in Teams, die in Outlook-Contacts landen – gehört zu Exchange Backup). – Notfallübungen: schon in DR. Der Betrieb sollte in Übung sein. Nach jeder Übung: betrieb verbessern.

Runbooks & Standard Operating Procedures (SOPs): – Einige wichtige Runbooks: – Neuer User Onboarding mit Telefon: z. B. Ticket von HR -> L1 vergibt Lizenz und Nummer per definierter Range -> schickt Anleitung an User (Headset anschließen etc.). – User Offboarding: z. B. Rufnummer auf inaktiv setzen oder neu zuweisen? Voicemail archivieren falls relevant? (Check Compliance). – Nummernvergabe-Prozess: Falls interner Ablauf: X will spezielle Nummer, Telko-Admin prüft Verfügbarkeit, trägt in Liste, konfiguriert in Teams. – Portierungsvorgang: mit Zeitplan und Tests – dem Team als Step-by-step (siehe Checkliste Sec. 6). – Support-Runbook: „Fehlerbild X – Vorgehen Y“ – z. B. „User kann bestimmte Nummer nicht erreichen – evtl. im Dial Plan blockiert? dann L2/Carrier check“. – Geräte-Lifecycle: Wann tauschen wir Telefone aus (nach 5 J.), wo liegen Ersatzgeräte/Headsets? Der Betrieb muss definieren, wer defekte austauscht (L1 vor Ort?), wie Gewährleistung läuft etc. Ein kleiner „Device Management Plan“ (Katalog unterstützte Modelle, Inventarliste). – Quality Incident Response: (Teil des QoS mgmt) – was L2 tut, welche Tools nutzt, wann es an L3 (Carrier) gibt, etc. – Schulungs- und Adoptionsplan: – Für neue User Telefoneinführung ins Onboarding-Programm. Z. B. eine halbe Stunde im New Hire Training: „So nutzen Sie Teams Anrufe, hier Ihre Voicemail…“. – Bei neuen Features optional Brownbag-Sessions. – Für IT-Support: fortlaufende Trainings, damit L1/2 mit dem Wandel mithalten. – Adoptions-KPI: z. B. wie viele % nutzen Teams Calling vs Handy? Wenn niedrig, evaluieren, wo hapert’s (vllt. Brauchen sie ein Coaching). – User Empowerment: z. B. Self-Service-Portal: könnte man zulassen, dass user einfache Sachen selbst tun (eigene Kurzwahl einrichten?). Meist nicht, aber Option. Governance entscheidet, was user darf – und falls ja, dokumentieren (z. B. Delegates, Gruppenanrufe können user in Teams selbst definieren).

Kommunikation bei Changes: – Nicht nur neue Features – auch planmäßige Wartungen. Wenn z. B. SBC-Wartung, vorab Info „Am Sonntag 22 Uhr kurze Unterbrechungen“. – Oder nach Störung: „Root cause war X, behoben. Sorry.“ – Transparenz schafft Vertrauen.

Service-Verbesserung & Kontinuierliches Lernen: – Sammeln von KPIs: z. B. abnehmende Ticketzahlen = gut oder nicht (weniger Probleme oder weniger melden?). – Zufriedenheitsumfrage an Endnutzer: „Zufrieden mit Telefondienst?“ – L1 bittet ab und an um Feedback nach Ticket (CSAT). – Wenn dort oft Kritik „Ton schlecht“, muss man tiefer bohren und an QoS nachschärfen oder Schulung (manche sprechen ins falsche Mikro etc.).

Wirtschaftlichkeit im Betrieb: – Den Überblick über Kosten behalten (Lizenzen, Verbindungsentgelte). Monatliche Reports an Finanzen, mit Abweichungen. So vermeidet man schleichende Budgetüberschreitung. – Chargeback/Showback: Wenn gewünscht, IT kann Abteilungen z. B. Telefonkosten zurechnen (viele Tools im Cloud Telko nicht exakt – aber man kann Nummern Person/Dept zuordnen und Summen). – Der Betrieb muss also auch die Abrechnungs- bzw. Kostendaten pflegen. – Ist Teams Calling billiger als altes? (TCO nachhalten, als KPI vllt. „Cost per call minute“ – sollte sinken). – Bei hohem internem Zeitaufwand – mal Service verbessern (z. B. Self-Help-Lösungen, Chatbots). – Verträge überwachen: Wann laufen Carrier oder SBC-Support Verträge aus – rechtzeitig verlängern. Gehört zum Service Management.

Letztlich stellt das in der Governance verankerte Betriebsmodell sicher, dass die Teams-Telefonie kein „Projekt“ bleibt, sondern stabiler Dauerbetrieb mit definierten Verantwortlichkeiten ist. Der Service wird gemessen, gemanagt und kontinuierlich optimiert – zum Nutzen der Benutzer, die einfach störungsfrei telefonieren wollen.

11. Wirtschaftlichkeit & Lizenzierung

Die Wirtschaftlichkeit der Teams-Telefonie entscheidet mit über ihren Erfolg. Hier gilt es, alle Kostentransparent zu machen und optimale Lizenzmodelle zu wählen.

Kostenblöcke: – Microsoft-Lizenzen: Basis sind M365-Lizenzen mit Telefoniefunktion. Etwa E5-Pläne beinhalten bereits Teams Phone, während E3/Business Pläne ein Add-On brauchen. Dieses Add-On heißt „Teams Phone Standard“ (früher „Phone System“). Pro Benutzer fallen also Lizenzkosten an (z. B. E3 + ca. 3 € für Phone System + ggf. Calling Plan Minutenpaket). Auch Conferencing kann Kosten haben (E5 hat Flat, E3 ggf. Audio-Con). – PSTN-Anbieter: Ob Direct Routing (Trunkgebühren, Minutenpreise) oder Operator Connect/Calling Plan – es gibt laufende Kosten pro Rufnummer (DID) und pro Minute (oder Flatrate-Pauschalen). Diese sollten im Budget eingeplant und überwacht werden. Beispiel: Bei Calling Plans: 120 Min im E5 inkl., drüber 0,03 €/min – multipliziert sich. – Infrastruktur (SBC): Falls eigener SBC: Kosten für Hardware oder VM (CapEx oder monatlich gemietet), plus Wartungsvertrag und evtl. Lizenzen (einige SBC sind Channel-basiert lizenziert – z. B. 30 gleichz. Calls = X €). Hochverfügbarkeit verdoppelt Kosten (zwei SBC). – Endgeräte & Zubehör: Headsets, Konferenzlautsprecher, IP-Telefone, Raumsysteme. Diese Kosten können erheblich sein initial (Headset 100 € x 500 MA = 50k). Auch Ersatz/Betrieb (Akkus tauschen etc.). Hier ansparen: evtl. Hardware-Leasing oder Investabschreibung über Jahre. – Betriebskosten: – Personalzeit (Admins, Support). Eventuell hat man einen Managed Service Provider, dann dessen Pauschale. – Schulungskosten (Training der Admins auf neuen System, Benutzer-Schulungsmaterial). – Nebenkosten wie Zertifikate (ein Public TLS cert für SBC ~200 €/Jahr). – Monitoring-Tools (falls extra lizenziert). – Carrier-Verbindungsleitungen: z. B. dedizierte SIP-Trunk-Bandbreite oder QoS-fähiges MPLS – falls beibehalten, auch Kosten. – Migrationseinmalkosten: wenn z. B. Berater für Portierung, oder Abfindungen für alte PBX-Abschaltung (Restbuchwert). – Backup-Lösungen: z. B. analog-Fon? Geringe Posten aber Summieren (SIM-Karten etc. falls als Backup). – Reserve-Budget: Für unbekannte Zuwächse (z. B. TURI** telco inflation?).

Kostenkontrolle & Zurechnung: – Showback/Chargeback: – Showback: IT zeigt Abteilungen monatlich, wie viele Minuten oder Kosten sie verursacht haben – rein zur Info, um Bewusstsein zu schaffen. – Chargeback: IT belastet Kostenstellen entsprechend. Hierfür muss man entweder je Nutzer /Team die Telefonnutzung messen. In Teams kann man per Userreport (User X 50 min international Y). Alternativ flatrate intern nach Kopf umlegen. – Governance muss mit CFO abstimmen, ob und wie: Oft wird Telefonie als Basisservice mit Overhead verteilt, es sei denn man hat extreme Verursacher. – Ein einfaches Modell: „Telefonie-Infrastrukturkosten werden zentral getragen, Verbindungsentgelte werden der verursachenden Abteilung belastet.“ – Dazu muss man die Providerrechnungen aufschlüsseln (Carrier-Rechnung listing DIDs, dort Departments zuordnen). Das UC-Team kann Reports generieren. – Das kann positive Steuerungswirkung haben (wenn z. B. Abt. unnötig viel privat telefoniert, fällt es auf). – Budgetplanung: Jährlich ein Budget für Telefonie definieren. Mögliche Kennzahlen: Kosten pro User/Monat. – Z. B. mit Teams sank unser p.U. Kosten von 20 € (bei alter PBX+Carrier) auf 12 € – sowas verfolgt CFO gern. – ROI/Business Case: – Im Vorfeld wird oft ROI gerechnet: Einsparungen durch Wegfall PBX-Wartung, Reduktion Mobilfunkkosten (wenn Teams substituiert manche Handycalls?), verbesserte Produktivität (schwer quantifizierbar, aber Argument). – Nach Implementierung sollte man die versprochenen Einsparungen tracken. Hat sich z. B. die alte TK-Wartung (50k € p.a.) wirklich eingespart? Oder neue Kosten (Lizenzen) aufgefressen? – Ggfs. Business Case nachschärfen: z. B. falls man feststellt, dass viele immer noch Handy statt Teams nehmen – dort Potential heben (Policy „bitte nutze primär Teams aus Kostengründen“). – Vergleich der Calling-Modelle (Kosten): – Analyse, ob Direct Routing vs. Calling Plan günstiger: – Direct Routing lohnt oft bei hohem Volumen, da Carrier-Kosten pro Minute günstiger als Microsoft-Pakete. Dafür invest in SBC. – Calling Plans eher fix/Kalkulationssicherheit, aber pro min teurer. – Operator Connect oft mittig, plus Spart interne OpEx (weniger Admin). – Finanziell Governance: regelmäßige Review ob das gewählte Modell noch optimum ist. Z. B. falls Microsoft neue Flatrates oder Telko neue Tarife – evtl. wechseln. – Lizenzpfade optimieren: – E5 vs. E3+Add-On vs. Business Voice: – Wenn man ohnedies viele E5 hat (wegen Security, PowerBI etc.), dann Telefonie „gratis“ inklusive. – Für E3-Kunden: Zusätzliche ~3 € pro User fürs Phone System. – Früher gab’s Business Voice bundling (für bis 300 user, inkl. Phone System + minutes). – Jetzt (2025) gibt es Teams Phone with Calling Plan Bundles – z. B. M365 Business Basic + 8 € Phone Standard + 10 € Domestic Plan = 18 € ~ E5 price? Muss man rechnen. – Hybride Lizenzierung: Man muss nicht allen Usern Telefonie geben. Governance: wer benötigt PSTN? So kann man Lizenzen sparen. – Z. B. interner Backoffice ohne Bedarf – keine Phone System Lizenz. – Oder Shared-Phone-User (Frontline F3), da gibts günstigere. – Microsoft bietet Frontline Worker Phone Lizenz (~2 € statt 8 für E-Lizenz), begrenzt auf F-Lizenzträger. Das für z. B. Lager/Produktion relevant. – Audio-Conferencing: Ab 2021 hat MS in vielen Plänen Audiokonferenzen inkl. (Dial-in-Benummern). E3 hat es als Addon bekommen – hier checken: kann man separate Telco-Audiokonf-Dienste abschalten und Kosten sparen? (Integration -> Kostenvorteil). – Wechsel auf neue Lizenzmodelle: Microsoft ändert manchmal Namen und Angebote. Governance/IT muss up-to-date sein: – z. B. Business Voice Addon (bis 300 user) wurde ersetzt durch Teams Phone with Calling Plan (inkl. 1200 Min national). – Für größere: E3+Phone System + extra Calls. Oder E5 incl. + add-on international calls falls needed. – Add-Ons vs. Flatrates: – Wenn man viele internationale Gespräche hat, Evaluate „International Calling Plan“ vs. Direct Routing. – International Plan meist 600 Min global + 1200 national, pro User ~ 18 €. – Rechnet sich nur, wenn der User ~ viel ins Ausland telefoniert. – Alternative: keine Int-Plan, stattdessen Communication Credits, zahle was anfällt (kann günstiger sein, wenn unregelmäßig). – Das sollte jährl. überprüft: z. B. Abteilung X hatte Int-Plan, nutzt nur 50 Min -> rausnehmen, Credits nutzen. – Tabellarische Lizenzübersicht (Beispiel):

(Preise fiktiv/Beispielhaft; Stand 2025 variieren nach Land und Angebot)

• Hier sieht man: E5 enthält schon viel, lohnt wenn man Features nutzt. E3+Phone Addon günstiger wenn man andere E5-Sachen nicht braucht. Für kleinere sind Business-Pakete praktisch, allerdings separate in DE nur über Provider teils.
• Governance sollte regelmäßig prüfen: „Haben wir richtige Mischung?“ – z. B. nur 10% User brauchen Telefonie → dann E5 für alle wäre Overkill (lieber E3+AddOn nur für 10% zuweisen, rest E3 normal).
• Möglichkeit der Lizenzteilung: Microsoft erlaubt „Shared Devices“ Lizenzen (z. B. für Teams Phones in Fluren) – deutlich günstiger als normaler User. Nutzen, um Kosten zu sparen: Governance definieren, wann man eine Common Area Phone Lizenz statt voller Lizenz nimmt (z. B. Lobby-Telefon hat Basic Phone license).
• Telefonkonferenz-Kosten vs. Teams: Oft kann man alte Audiokonferenzdienste abschalten (Kostenersparnis), da Teams denselben Zweck erfüllt.

Sensitivitätsanalyse & Zukunftssicherheit: – Steigende Nutzerzahlen: Dank Cloud skaliert Lizenz linear. Finanziell: Telefoniekosten steigen annähernd linear mit MA-Zahl. ABO-Modelle gut planbar, aber fix. Checkpoint: ab wieviel User wäre Direct Routing (mit fix trunk cost) pro user günstiger? – Nutzungsverhalten: Wenn Chat/Video substituieren Telefone, dann evtl. zu viele PSTN-Lizenzen. Governance: nach 1 Jahr auswerten, ob evtl. manche Abteilungen gar keinen Bedarf – Lizenz entziehen (Kosten sparen). – Wechselkurse etc.: Wenn global, Payment in USD – Variation. CFO-Look. – Technologieänderungen: Z. B. in Zukunft Teams bringt Operator Connect mit Pay-per-Minute Option? – Dann neu bewerten. – Der Governance-Ausschuss (IT, Finance) sollte mind. jährlich telko-Kostenreport prüfen und Optionen evaluieren.

Vergleichstabellen wie oben in Sektion 3 und hier dienen als Hilfsmittel, um Entscheidungen transparenter zu machen.

Ziel ist, mit der passenden Lizenzstrategie bestmögliche Funktion zum geringsten notwendigen Preis bereitzustellen – ohne Over- oder Undersizing. Und durch Kostenkontrollen wird verhindert, dass die Telefonie „zurück ins Dunkel“ fällt (Schattenkosten oder Fehlanreize). Insgesamt kann Microsoft Teams Telefonie bei guter Planung häufig Kosten senken gegenüber althergebrachter Telefonie – was sich im Business Case zeigen lässt.

12. Risiken & Anti-Patterns

Trotz aller Governance-Maßnahmen bleiben gewisse Restrisiken. Hier fassen wir die Top-Risiken und typische Fehlentwicklungen (Anti-Patterns) zusammen – und wie man ihnen begegnet:

• Risiko 1: Fehlender Notruf-Test – Anti-Pattern: Man verlässt sich blind darauf, dass Notrufe schon funktionieren, weil Microsoft/Provider das schon machen. Auswirkung: Im Ernstfall könnte ein Notruf ins Leere gehen oder falsch geroutet sein, was Leben gefährdet und rechtliche Konsequenzen hätte. Gegenmaßnahmen: Strikte Policy für regelmäßige Notruf-Tests (mind. 1× pro Quartal pro Land/Standort). Kontrollen: Testanrufe protokollieren, Abweichungen sofort beheben. Evidenz: Testprotokolle mit Datum/Uhrzeit und Ergebnis. (Z.B. „Test 112 am 12.3., verbunden mit Leitstelle München, Standort korrekt übermittelt – OK“).
• Risiko 2: Unkontrollierte CLIP/CLIR-Regeln – Anti-Pattern: Beliebige Benutzer ändern ihre abgehende Rufnummer (CLIP no screening) oder unterdrücken sie (CLIR), ohne Governance. Auswirkung: Potenzieller Missbrauch (Mitarbeiter gibt sich als jemand anders aus, oder ruft anonym an – problematisch bei Hotline/Compliance). Chaos in Außenwirkung (unterschiedliche Absendernummern). Gegenmaßnahmen: Nur definierte Nummern dürfen via CLIP no screening gesendet werden – Einrichtung nur durch Admin auf Anforderung und Dokumentation (z. B. „Support-Team sendet immer Hauptnummer als Absender – genehmigt von Leitung“). CLIR nur für genehmigte Fälle (z. B. Vorstand) aktivieren und ansonsten unterbinden. Kontrollen: Monatliche Audit der ausgehenden Nummern – Logs zeigen, ob jemand eine nicht erlaubte Absendernummer nutzt; Providerreports nutzen, die evtl. Abweichungen zeigen. Evidenz: Liste aller aktiven CLIP no screening Einstellungen mit Verantwortlichem, Unterschrift Compliance dass OK.
• Risiko 3: Kein Fraud-Monitoring – Anti-Pattern: Telefoniesystem ohne jegliche Überwachung von Anrufmustern betreiben („Wir merken schon, wenn die Rechnung hoch geht.“). Auswirkung: Toll Fraud kann unbemerkt sehr hohe Kosten verursachen (Beispiel: über Wochenende werden durch gehackten Account 10.000 € an Premium-Verbindungen aufgebaut). Gegenmaßnahmen: Automatisierte Limits (z. B. Communication Credits, wie oben), definierte Alerts im Monitoring (z. B. „User > 500 min am Tag“ oder „Calls nach Mitternacht“). 24/7-Bereitschaft, um Alarm sofort zu bearbeiten (Account sperren, Provider blocken). Kontrolle: Wöchentlicher Review der Telefonieauszüge auf Auffälligkeiten durch Finance oder IT. Evidenz: Report „Unusual Call Pattern“ – idealerweise immer leer; wenn nicht, mit Maßnahmenvermerk.
• Risiko 4: Keine QoS-Durchsetzung – Anti-Pattern: „Unser Netz ist schnell, wird schon gehen“ – also kein QoS implementiert. Auswirkung: Bei Belastung (z. B. Backup-Transfer, viele Nutzer im WLAN) bekommt die Sprache keinen Vorrang und die Call-Qualität bricht ein. Benutzer sind frustriert („Teams taugt nix“), evtl. werden Projekte zurückgefahren. Gegenmaßnahmen: Von Anfang an Ende-zu-Ende QoS einrichten (siehe Abschnitt 9). Besonders auf Engpass-Stellen (WAN-Uplinks, Wi-Fi) Priorisierung sicherstellen. Kontrolle: regelmäßige Lasttests oder Auslastungsmonitoring, ob Sprachverkehr in Prio-Queues landet (z. B. Switch-Auslastung je Queue tracken). Evidenz: Netz-Konfig Dokumentation mit QoS-Regeln, Testergebnisse (Ping mit DSCP EF vs. Normal, sehen ob differenziert).
• Risiko 5: Ungeregelte Berechtigungen & Admin-Fehler – Anti-Pattern: Jeder IT-Admin kann irgendwo im Teams Admin Center Änderungen machen, kein klares RACI. Auswirkung: Hohe Fehlerwahrscheinlichkeit (z. B. Admin X löscht versehentlich Nummern, weil er dachte ungenutzt; Admin Y schaltet was ab im Eifer), fehlende Verantwortlichkeit („Ich dachte der kümmert sich“). Gegenmaßnahmen: Rollen strikt zuweisen (wie in Sec/Compliance). Mindestens 4-Augen-Prinzip bei heiklen Dingen (z. B. Notruf-Route, broad policy changes). Kontrolle: Admin-Audit-Log wöchentlich ansehen (besonders Telefonie-Einstellungen), quer gegen genehmigte Changes halten. Evidenz: Change-Logs mit Freigaben, Audit-Trail Berichte.
• Risiko 6: Schatten-IT & Ausweichverhalten – Anti-Pattern: Durch fehlende Governance (z. B. schlechte Qualität oder unklare Richtlinien) nutzen Mitarbeiter eigene Lösungen (privates Handy, Zoom statt Teams etc.). Auswirkung: Sicherheits- und Datenschutzrisiken (Firmengespräche über unkontrollierte Kanäle), keine Nachvollziehbarkeit, Kostennachteile (statt kostenfreie interne Teams-Calls werden Handy-Flats strapaziert). Gegenmaßnahmen: Qualität sicherstellen (siehe QoS), Benutzerbedürfnisse ernst nehmen (wenn z. B. jemand unbedingt Tischtelefon braucht statt Softphone – lieber bereitstellen, als dass er heimlich eigenes DECT bastelt). Klare Kommunikation der Vorteile und Hilfestellung beim Umstieg. Kontrolle: Surveys oder Monitoring (werden Teams-Calls genutzt? Oder stieg Handyrechnung an?). Evidenz: Benutzerbefragungen, Auswertung z. B. „95% der internen Calls laufen über Teams – erfüllt“.
• Risiko 7: Missachtung Datenschutz bei Aufzeichnungen – Anti-Pattern: Man führt Recording ein, ohne es ordentlich zu regeln oder klärt nicht, wo Aufzeichnungen gespeichert, wer Zugriff. Auswirkung: Hohe rechtliche Angreifbarkeit (DSGVO-Strafen, Arbeitnehmerklagen), Vertrauensverlust der Mitarbeiter. Gegenmaßnahmen: Recording nur mit Mitbestimmung und Policy (siehe Compliance-Sektion). Sorgfältiges Berechtigungskonzept (z. B. Aufnahmen werden automatisch in ein Compliance-Archiv geschoben, das nur Datenschutz und Compliance-Officer lesen können). Kontrolle: Vierteljährlich Audit: Wurden unautorisierte Aufzeichnungen vorgenommen? (Check in Teams Audit Log, ob jemand manuell Recording gestartet hat, obwohl verboten). Evidenz: Dokument „Liste aller Recording-fähigen Teams & Personen mit Begründung und BR-Zustimmung“, Ergebnis der Log-Überprüfung (z. B. „keine unzul. Aufz. entdeckt“).
• Risiko 8: Vernachlässigte Sonderdienste – Anti-Pattern: Fokus nur auf modern IP – Fax, Alarmanlage, Türsprech bleibt unbeachtet („wird schon irgendwie“). Auswirkung: Im Worst Case scheitert ein Alarmübertrag oder ein Fax von Kunden kommt nicht mehr an. Das kann geschäftskritisch sein. Gegenmaßnahmen: Alle Non-VoIP-Dienste identifizieren und separate Lösungen definieren (z. B. analoger Adapter oder separate Leitung). Testen, dass sie nach Migration funktionieren. Kontrolle: Checkliste bei Migrationsabnahme: Fax versendet? Alarm getriggert? etc. Jährliche Überprüfung dieser Alt-Schnittstellen (sind sie noch gebraucht, funktionieren?). Evidenz: Protokoll analoger Dienste – Testreports (z. B. „Feueralarm Wählgerät Testanruf bei Leitstelle i.O.“).
• Risiko 9: Fehlende Updates & Wartung – Anti-Pattern: „Never change a running system“ – SBC jahrelang nicht upgedatet, Teams Phones auf Uralt-Firmware. Auswirkung: Ungepatchte Sicherheitslücken, schleichende Qualitätsprobleme oder Inkompatibilitäten nach Cloud-Updates. Gegenmaßnahmen: Strikter Patchplan, in dem Telefonie-Komponenten gelistet und mit gleichen Standards (90-Tage-Patchfenster) bedacht sind. Firmware-Alerts vom Hersteller abonnieren. Kontrolle: Asset-Liste vs. Firmware-Versionen quartalsweise prüfen. Penetrationstest/VA Scan auf bekannte Lücken. Evidenz: Wartungsprotokolle, Firmware-Upgrade-Reports.
• Risiko 10: Komplexität & Overengineering – Anti-Pattern: Man baut extrem komplexe Routing-Szenarien, zu viele Policies, hunderte von DialPlan-Rules – Governance „overkill“. Auswirkung: Hoher Betriebsaufwand, Fehleranfälligkeit und schwer nachvollziehbar für Nachfolger. Gegenmaßnahmen: Keep it simple – Governance sollte Komplexität nur einführen, wenn’s echten Nutzen hat. Regel: Minimalprinzip (z. B. lieber etwas strengere aber dafür universelle Richtlinie, statt 50 Ausnahmen definieren). Kontrolle: Architekturreviews jährlich: Kann etwas vereinfacht oder abgeschaltet werden? (z. B. Feature das keiner nutzt, aber Config verkompliziert, entfernen). Evidenz: Ergebnis Review-Meeting: z. B. „Dial Plan Regeln reduziert von 30 auf 10 – Übersichtlichkeit verbessert, Tests belegt i.O.“.

Durch das Bewusstsein dieser Risiken und Anti-Patterns und der gezielten Gegenmaßnahmen bleibt das Telefoniesystem sicher, compliant und effizient. Governance endet nicht mit initialer Einrichtung – sie bedeutet laufendes Hinterfragen: „Wo könnten Probleme auftreten? Welche Lücken lassen wir? Wie können wir sie schließen?“ So wird aus jeder Herausforderung eine Chance, die Umgebung weiter zu verbessern.

13. FAQ (20 Fragen & Antworten)

1. Worin unterscheidet sich Telefonie-Governance von allgemeiner Teams-Governance?
Telefonie-Governance fokussiert speziell auf alle Belange der Sprachkommunikation (z. B. Nummernpläne, Anrufrichtlinien, Notrufe, PSTN-Anbindung). Die allgemeine Teams-Governance behandelt Themen wie Teams-Struktur, Berechtigungen, Datenklassifizierung, Apps usw. Telefonie-Governance ist also ein Sub-Framework unter dem Dach der IT-/Teams-Governance. Sie geht detailliert auf Telefonie-spezifische Risiken (Toll Fraud, Notrufe) ein, die in einer generellen Governance oft nur am Rande vorkommen. Außerdem greift Telefonie-Governance stärker in klassische TK-Bereiche (z. B. Regulierung TKG) hinein. Kurz: Allgemeine Teams-Governance regelt Collaboration, Telefonie-Governance regelt Communication (Voice) – beide müssen verzahnt sein, aber Telefonie hat eigene Regeln und Anforderungen.

2. Direct Routing vs. Operator Connect: Wann welches Modell?
Das hängt von Unternehmensanforderungen ab: – Direct Routing eignet sich, wenn Sie maximale Flexibilität brauchen: z. B. bestehende Verträge mit bestimmten Carriern weiter nutzen wollen, Länder abdecken müssen, für die Microsoft/Operator Connect nichts bietet, oder Integration mit Legacy-Systemen (Türklingel, PBX) nötig ist. Es erfordert mehr Know-how und eigenen SBC-Betrieb, bietet aber volle Kontrolle und oft günstigere variabele Minutenpreise bei hohem Volumen. – Operator Connect ist ideal, wenn Sie den Betrieb vereinfachen möchten: kein eigener SBC, schnelle Bereitstellung via Teams Admin Center mit einem zertifizierten Provider. Wartung und Skalierung übernimmt der Operator. Das passt für viele mittelständische Firmen, die in von Partnern abgedeckten Ländern sitzen und keinen Telefonie-Spezialisten beschäftigen wollen. Auch Support und SLA liegen beim Anbieter. Allerdings weniger individuell – man ist an Standardleistungen gebunden. – Microsoft Calling Plans wiederum sind gut für sehr einfache Anforderungen in verfügbaren Ländern (kleinere Firmen mit vorrangig nationalen Gesprächen). Kurz gesagt: Große, global verteilte oder komplex integrierte Umgebungen nehmen oft Direct Routing. Unternehmen, die „Telefonie aus der Steckdose“ bevorzugen und in den Rahmenbedingungen der Anbieter liegen, fahren mit Operator Connect komfortabler.

3. Wie wird ein unternehmensweiter Rufnummernplan entworfen?
Man startet mit der Bestandsaufnahme: welche Standorte gibt es, wie viele Teilnehmer pro Standort, welche bestehenden Rufnummern stehen zur Verfügung? Dann legt man ein Schema fest, das möglichst einheitlich und skalierbar ist. Oft bewährt: je Standort eine Durchwahl-Gruppe (z. B. 4-stellige interne Nummern, wobei erste Ziffer den Standort codiert). Externe Rufnummern werden entsprechend blockweise beantragt/portiert, sodass sie zu den internen passen. Wichtig ist, Reserven einzuplanen (z. B. wenn Standort 100 Nutzer hat, lieber 200er-Block nehmen). Auch Sondernummern definieren (z. B. alles, was mit 9 beginnt, ist Service). Das Ergebnis sollte in Tabellenform dokumentiert werden (siehe Abschnitt 6), damit klar ist: Nummer X gehört wohin. Bei der Planung hilft es, zukünftige Expansion mitzudenken (wo eröffnen wir vielleicht neue Büros?). Zudem beachtet man Ländervorgaben (manche Länder verlangen standortgebundene Rufnummern). Am Ende durchläuft der Entwurf eine Freigabe (IT-Leitung, ggf. Betriebsrat falls interne Durchwahlnummern bisher persönliche Bedeutungen hatten). Dann wird er technisch umgesetzt in Teams (Dial Plan Normalisierung intern -> extern, Zuweisung der Blöcke an User). Also: strukturiert nach Standort/Abteilung, E.164-Konform, konsistente Länge und frühzeitige Dokumentation sind die Kernpunkte.

4. Was bedeuten CLIP/CLIR/„CLIP no screening“ organisatorisch und technisch?
– CLIP (Calling Line Identification Presentation) heißt, dass dem Angerufenen die Rufnummer des Anrufers angezeigt wird. Organisatorisch entscheidet man, ob z. B. der persönliche Durchwahl des Mitarbeiters oder eine zentrale Nummer angezeigt werden soll. Technisch ist CLIP Standard – Teams zeigt idR. die zugewiesene Nummer als Absender. – CLIR (Calling Line Identification Restriction) bedeutet Rufnummernunterdrückung – der Angerufene sieht „anonym“ oder „unterdrückt“. Organisatorisch sollte das nur in Ausnahmefällen genutzt werden (z. B. bei Externen Anrufen durch Personalabteilung oder wenn ein VIP seine Nummer nicht preisgeben will). Technisch kann man CLIR global erlauben oder sperren bzw. für einzelne Benutzer fest einstellen. In Teams kann ein Admin das pro Benutzer mit Policies steuern. Wichtig: Notrufe setzen CLIR außer Kraft (damit Leitstelle die Nummer bekommt). – CLIP no screening erlaubt es, eine andere Nummer anzuzeigen, als die von wo aus angerufen wird. Technisch passiert das entweder im eigenen SBC oder beim Provider: die ausgehende Signalisierung enthält eine „From-Nummer“, die abweicht. Der Provider „screened“ normal, d.h. ersetzt unberechtigte Absendernummern durch die Leitnummer des Anschlusses. „No screening“ heißt, der Provider verzichtet darauf und zeigt was geschickt wird. Organisatorisch nutzt man das z. B. wenn man will, dass alle ausgehenden Anrufe die Zentrale zeigen, egal wer anruft. Oder für ein Callcenter, das verschiedene Absender je nach Kampagne anzeigt. Hier ist Governance ganz wichtig: Missbrauchspotential (jemand könnte fremde Nummer senden). Daher wird CLIP no screening nur für definierte Nummern freigeschaltet (Provider verlangt oft eine Vereinbarung, dass man nur Nummern verwendet, die einem gehören). Im Unternehmen muss festgelegt sein, wer das nutzen darf – i.d.R. nur Telefonanlage/System an sich, nicht Einzelmitarbeiter on-the-fly.

Kurz: CLIP = Nummer anzeigen (Standard), CLIR = Nummer unterdrücken (nur wenn zulässig), CLIP no screening = absichtlich andere Nummer anzeigen (nur kontrolliert einsetzen, z. B. Hauptnummer aus Callcenter).

5. Wie wird Toll Fraud verhindert und erkannt?
Toll Fraud – also das unautorisierte Nutzen der Telefonie für teure Verbindungen – verhindert man durch ein Bündel an Maßnahmen: – Technische Sperren: Konfigurieren Sie Sperrlisten für ausgehende Anrufe zu bekannten Hochrisiko-Nummern (z. B. 0900, Auslandsprefixe ohne Geschäftsbezug, Satellitenrufnummern). So können Angreifer gar nicht erst die teuersten Ziele erreichen. – Starke Authentifizierung: Stellen Sie sicher, dass nur befugte Personen die Telefoniefunktionen nutzen können. In Teams ist das an den Account gebunden – daher MFA pflicht, komplexe Passwörter, keine geteilten Accounts. So wird es Hackern erschwert, einen Account zu kapern. – Limits setzen: Bei Verwendung von Microsoft Calling z. B. Communication Credits ohne Auto-Reload nutzen – dann kann ein Betrüger maximal das Guthaben abtelefonieren, dann ist Schluss. Bei eigenem SBC kann man (je nach System) pro User oder gesamt ein Minutenlimit/Costlimit definieren, was an einem Tag/Woche nicht überschritten werden darf. – Überwachung: Implementieren Sie Alarme für ungewöhnliches Verhalten. Zum Beispiel: Alarm, wenn ein einzelner Nutzer mehr als z. B. 100 internationale Minuten in einer Stunde verursacht, oder nachts Anrufe ins Ausland auftauchen, was sonst nicht vorkommt. Diese Alarme kann ein Monitoring-System oder ein Carrier bereitstellen. – Prozess bei Verdacht: Legen Sie fest, wie zu reagieren ist: z. B. sofort betreffenden Account sperren oder ausgehende Telefonie global stoppen, Carrier kontaktieren für Rufnummernsperre. Zeit ist Geld – in Minuten können hunderte Euro Schaden entstehen. – Sensibilisierung: Informieren Sie Mitarbeiter, dass auch ihr Account zum Ziel werden kann – sie sollen verdächtige Aktivitäten (z. B. Outgoing Calls in Anrufliste, die sie nicht gemacht haben) sofort melden. – Regelmäßige Rechnungskontrolle: Die Finanz- oder IT-Abteilung prüft monatlich die Verbindungsnachweise auf Ausreißer. So würde man z. B. erkennen, wenn plötzlich Kosten für Exoten-Länder entstehen. – Updates einspielen: Halten Sie SBCs und Systeme aktuell – bekannte Sicherheitslücken (wie offenes SIP, das Missbrauch erlaubt) werden so geschlossen.

Durch dieses Multi-Layered Vorgehen – Prevention (Sperren), Detection (Monitoring), Response (Sperrprozess) – wird Toll Fraud weitgehend unterbunden oder im schlimmsten Fall sehr schnell entdeckt, sodass der Schaden gering bleibt.

6. Was sind sinnvolle QoS-/Qualitäts-Kennzahlen (MOS, Latenz, Jitter, Paketverlust)?
Sinnvolle Kenngrößen für Sprachqualität sind: – MOS (Mean Opinion Score): Ein von 1 (schlecht) bis 5 (sehr gut) bewerteter Qualitätswert. Er wird aus technischen Messgrößen berechnet. Ein MOS >= 4,0 gilt als guter Anruf. Wir streben an, dass > 95 % der Anrufe diesen Wert erreichen. – Latenz: Die Verzögerung (One-Way) eines Sprachpakets. Ideal unter 50 ms, akzeptabel bis ~100 ms. Darüber hinaus wird die Kommunikation spürbar verzögert (bei >150 ms one-way, also >300 ms Roundtrip entstehen hörbare Pausen/Verschneidungen). Also KPI: Latenz < 100 ms. – Jitter: Die Schwankung der Latenz zwischen Paketen. Wenn Jitter hoch ist, müssen Puffer eingesetzt werden, was Verzögerung und Paketverlust erzeugt. Ziel < 20–30 ms Jitter. Teams kompensiert etwas, aber ab ~30 ms+ kann es stottern. – Paketverlust: Anteil verlorener Sprachpakete. Er sollte < 1 % liegen. Schon ab 3–5 % Loss fängt Sprache an zu knacken oder Lücken aufzuweisen. Bei Video hat man FEC (Fehlerkorrektur), aber Audio ist empfindlicher. Also KPI: Paketverlust unter 1 % pro Stream. Zusätzlich kann man Burst Loss (Verluste in Folge) betrachten, aber für Alltag reichen obige. Diese Metriken werden im Call Quality Dashboard gemessen. Man sollte Schwellwerte definieren – z. B. „schlechter Anruf“ = MOS < 3,5 oder Packet Loss > 5 % oder Jitter > 30 ms. Und dann analysieren, wann/wo das vorkommt. Kurz: MOS als Gesamtindikator, und Latenz/Jitter/Loss als Ursachenmesser. In Berichten/Alerts sind diese Kennzahlen zentral.

7. Wie werden Notrufe für mobile/nomadische Nutzer zuverlässig abgewickelt?
Das ist eine Herausforderung, denn ein Nutzer kann sich überall befinden. Maßnahmen: – Standortverfolgung in Teams: In der Firmenumgebung wird es über Netzwerk-IDs gelöst: man hinterlegt im Teams Admin Center die Standorte (Adresse) mit zugehörigen IP-Bereichen/WLAN-IDs. Meldet sich der nomadische Nutzer z. B. im Büro Hamburg an, erkennt Teams anhand IP „aha, Hamburg-Büro“ und übermittelt diese Adresse beim Notruf. – User-basierte Adresseingabe: Für Homeoffice oder unterwegs kann man vom Nutzer verlangen, seine aktuelle Adresse in Teams einzutragen. In manchen Ländern (USA RAY BAUM’s Act) poppt Teams z. B. auf: „Sie sind nicht im Büro, geben Sie Ihre Adresse an, um Notrufe zu ermöglichen.“ In DACH ist das (noch) nicht automatisiert – hier wäre der Prozess: HR weiß, wo jemand i.d.R. arbeitet (Homeoffice-Adresse hinterlegt) und man nimmt diese als Notfalladresse. Oder man schult Mitarbeiter: „Wenn ihr von außerhalb anruft, müsst ihr dem Disponenten gleich sagen, wo ihr seid, da das System evtl. eine falsche Info hat.“ – Mobile Nutzer mit SIM: Wenn jemand mit Handy und SIM integriert (Operator Connect Mobile) einen Notruf wählt, geht der über das Mobilfunknetz – dort wird nach Funkzelle geortet oder es gilt die SIM-registrierte Adresse (je nach Land). Also hier verlässt man sich auf Mobilfunk-Provider. – Fallback-Empfehlung: Generell sollte man kommunizieren: Im Zweifel immer vom mobilen Telefon (GSM) Notruf wählen, da dort Standortinformation traditionell verknüpft ist (bei Festnetz-VoIP ist es komplexer). – Multi-Land Handhabung: Sicherstellen, dass der Nutzer im Ausland die dort gültige Notrufnummer kennt (112 geht EU-weit für Rettung, aber z.B. Polizei hat in USA 911 – Teams hat pro Land eigene Notrufnummernlisten, die man konfigurieren sollte). – Provider-Lösungen: Mit Direct Routing kann man spezielle Dienste nutzen (z. B. Drittanbieter, die eine nomadische Notruf-Lösung bieten – in USA Standard, in Europa im Kommen). In DE gibt es zentrale Routingstellen, an die man Notrufe mit Zusatzdaten senden könnte – noch nicht trivial verfügbar. – Schriftliche Info: Der Arbeitgeber sollte den nomadischen Mitarbeitern schriftlich mitteilen, wie Notrufe geregelt sind: „Wenn Sie außerhalb des Firmenstandorts sind, wird beim Wählen von 112 Ihre im System hinterlegte Adresse (Homeoffice) genutzt. Halten Sie diese aktuell und nennen Sie dem Leitstellendisponent zur Sicherheit Ihren genauen Aufenthaltsort.“ – Test und Validierung: Ab und an Testen: z. B. im Homeoffice eines Mitarbeiters – via Testanruf checken, welche Adresse ankam (ggf. via Provider erfragen). Zuverlässig ist es also durch Kombination von Technik + Nutzerverantwortung: Das System versucht, bestmögliche Adresse zu liefern, und der Nutzer lernt, im Notfall aktiv seine Location zu bestätigen. Diese Awareness ist Teil der Governance-Schulungen.

8. Welche Rollen und Berechtigungen braucht der Betrieb (Least Privilege)?
Man benötigt vor allem: – Teams-Telefonie-Administrator (Teams Communications Administrator): Diese Rolle kann alle Voice-Einstellungen in Teams vornehmen (Nummern zuweisen, Routing, Dial Plans etc.). Man gibt sie dem/den UC-Engineers, die Telefonie verwalten. Es sollten nur wenige Personen mit dieser Vollberechtigung arbeiten. – Teams-Serviceadministrator: etwas breiter (alles in Teams), kann auch e.g. Policies etc. – je nach Orga, oft hat man einen globalen Teams Admin (der nicht alles im Detail macht) plus spezialisierte Comm-Admins. Least Privilege: lieber Comm-Admin (nur Telefonie) statt full Teams Admin, sofern die Person sich nur um Telefonie kümmert. – Helpdesk-Rollen: Microsoft bietet Teams Communication Support Engineer und Support Specialist. Diese Rollen erlauben z. B. das Einsehen von Call Analytics, aber keine Konfigänderung. So kann 2nd-Level Support Qualitätsanalysen machen, ohne riskante Änderungsrechte. L1 braucht oft gar keinen speziellen Teams-Zugang, außer um vielleicht Telefonnummern eines Users nachzusehen – das geht z.B. via AzureAD oder Teams Admin Read-Only. – Netzwerk-Admin: Nicht direkt in Teams, aber vielleicht Sicht auf CQD Reports (kann man auch als PowerBI ausleiten). Zugriffsrechte entsprechend gewähren (z. B. in PowerBI oder in Reports mitlesen). – Device Administrator: Wenn man viele Teams Phones/Room Systems hat, könnte man jemanden mit Teams Device Admin Rolle haben, der Firmware pusht etc. – Tenant Admin (Global Admin): Sollte für Telefonie nicht nötig sein. Avoid GA für Routine – GA nur für übergreifende Configs (z.B. das Einrichten der Operator Connect Integration war GA nötig, danach nicht). – Security/Compliance Rollen: falls man Call Records in eDiscovery braucht: Compliance Officer Rollen. Aber die können auch ohne Teams-spezifische Admin ans Voice-Items (Voicemails via Content Search). – Betriebsrat/Datenschutz Einsicht: Evtl. definieren, ob/dass diese z. B. Audit-Logs einsehen dürfen. In der Praxis werden sie dem Datenschutzbericht vorgelegt, nicht selbst rummachen. – RACI klären: Responsible Roles (die Admins), Accountable (Service Owner), Consulted (z. B. Security Officer wenn SBC config changes), Informed (Helpdesk über Änderungen). – PowerUser: in Teams Telefonie eher selten. Es gibt „Teamowner“ etc. – aber Telefon-Funktionen werden zentral gemanagt. Manche Unternehmen delegieren z. B. Abteilungsleitern das Recht, für ihre MA die Voicemail-Ansagen zu verwalten via Exchange – meist unnötig. – Fazit: Minimale Berechtigungsvergaben, fein abgestimmt: – Kommunikations-Admin für 1-3 Leute im UC-Team, – Support Engineer für 2nd Level, – Reporting-Only für das Monitoring Team. Und diese Rechte können via PIM (zeitlich begrenzt) vergeben werden. So minimiert man potentielle Fehlkonfigurationen und Sicherheitsrisiken. Natürlich braucht jeder Admin MFA und in sensiblen Fällen separate Admin-Accounts (nicht mit User-Account arbeiten).

9. Wie wird Recording datenschutzkonform organisiert (Transparenz, Aufbewahrung)?
Um Gespräche mitzuschneiden, ohne gegen Datenschutz zu verstoßen, muss man folgende Punkte beachten: – Rechtsgrundlage & Zweck: Klären Sie, warum aufgezeichnet wird. Etwa Einwilligung der Beteiligten (z. B. bei Service-Hotlines sagt der Kunde „ja“) oder gesetzliche Pflicht (z. B. Wertpapierhandel). Dokumentieren Sie diesen Zweck schriftlich im Verarbeitungsverzeichnis. Ohne legitimen Grund: keine Aufzeichnung! – Transparenz & Zustimmung: Alle Parteien müssen vorab wissen, dass aufgezeichnet wird. Bei Kunden schafft man das durch eine Ansage zu Beginn: „Dieses Gespräch wird ggf. mitgeschnitten…“ Der Kunde kann dann auch nein sagen (dann nicht aufzeichnen). Mitarbeiterseitig unbedingt mit Betriebsrat regeln: In einer Betriebsvereinbarung steht z. B., wann Aufzeichnungen erlaubt sind (nur bei Kundengesprächen, nicht zur Leistungskontrolle, nur Stichproben etc.). Mitarbeiter werden informiert und stimmen der BV implizit zu oder per Vertrag. – Technische Umsetzung – keine „Heimlichkeit“: In Teams wird bei einer Compliance-Aufzeichnung ohnehin ein Banner angezeigt. Vermeiden Sie irgendwelche Tools, die heimlich das Mikro mitschneiden – das wäre illegal. Also Nutzung der offiziellen Compliance Recording-Funktionen: Dabei joinen zertifizierte Recording-Bots die Calls, sichtbar für alle Teilnehmer. So ist Transparenz gegeben. – Beschränkter Zugriff: Aufgezeichnete Dateien sollten zugriffsgeschützt gespeichert werden – etwa in einem speziellen Archivsystem oder in einer vom Rest getrennten SharePoint/Blob-Storage. Nur definierte Rollen dürfen darauf zugreifen (z. B. Compliance-Manager, der im Bedarfsfall Mitschnitte an Regulator gibt). Nicht der Linienvorgesetzte soll nach Lust & Laune reinhören können! Zugriffe protokollieren, damit Missbrauch ausgeschlossen ist. – Aufbewahrungsfristen: So kurz wie möglich, so lange wie nötig. Im Kundenservice evtl. 30 oder 90 Tage (zur Qualitätsauswertung, dann löschen). Gesetzlich bei Finanzgesprächen: 5 oder 7 Jahre Archivierungspflicht – das muss dann so eingestellt sein. Nutzen Sie Microsoft Purview Retention Policies oder das Recording-System, um automatische Löschung nach Frist zu garantieren. – Datenspeicherung im passenden Gebiet: Sorge tragen, dass Aufzeichnungen möglichst in EU/Schweiz gespeichert werden, wenn DSGVO relevant (keine unnötigen Transfers in Drittländer). Viele Recording-Lösungen bieten EU-Cloud an. – Dokumentierte Prozesse: Legen Sie fest, wie eine Aufzeichnung angefordert wird (z. B. Compliance-Abteilung will Mitschnitt von bestimmtem Anruf – wie kommen sie dran? via Anfrage an IT, die das aus dem Archiv zieht – mit Protokoll). Und wie berechtigte Personen Löschung verlangen können (im B2C können Kunden nach DSGVO evtl. Auskunft oder Löschung verlangen, sofern nicht andere Pflichten entgegenstehen). Dann muss man in der Lage sein, die Datei aus dem Archiv zu fischen. – Mitarbeiterschutz: In der BV kann z. B. stehen, dass Mitarbeiter das Recht haben, die Aufzeichnung abzubrechen oder von vornherein zu deaktivieren, wenn es z. B. ein persönliches Gespräch wird. Die Kultur sollte nicht Überwachung, sondern Verbesserung sein. – Schulung & Awareness: Mitarbeiter der aufgezeichneten Bereiche sollten genau wissen, was erlaubt ist (z. B. „Informiere den Kunden zu Beginn – hier ist unser Skript dazu…“). Und was mit den Aufnahmen passiert (z. B. „nur Teamleiter X wertet stichproben aus, Feedbackgespräch einmal im Monat“). – Wenn möglich Anonymisierung: Falls Sie Aufzeichnungen zu Trainingszwecken speichern, könnte man personenbezogene Daten anonymisieren (z. B. bei Archivierung Kundenname piepen etc. – aber das ist aufwändig). – Keine flächendeckende Mitarbeiteraufzeichnung: Außer in streng regulierten Feldern. Falls doch, unbedingt vorher die rechtlichen Rahmen prüfen (in vielen Ländern illegal). – Insider-Datenschutz: Falls ein Mitarbeiter-gespräch mitgeschnitten wird (z. B. Beratungsgespräch intern), zählt es auch – hier streng sein und eher nicht zulassen, um Vertrauensverhältnis zu schützen. – Prüfung durch Datenschutzbeauftragten: Der interne DSB sollte das Recording-Konzept formal absegnen (DPIA – Datenschutz-Folgenabschätzung ggf. durchführen, da es potentiell heikel ist).

Durch diese Maßnahmen gelingt eine Balance: Man erfüllt die Compliance-Anforderungen, nutzt Aufzeichnungen nur im erlaubten Rahmen, und schafft Transparenz, sodass weder Kunden noch Mitarbeiter sich hintergangen fühlen. Das minimiert rechtliche Risiken und erhält das Vertrauen.

10. Wie gelingt die Migration aus Legacy-TK ohne Stillstand?
Eine sorgfältig geplante Parallel- und Übergangsphase ist der Schlüssel: – Vorbereitung: Zuerst etabliert man die Teams-Telefonie neu, während die alte TK-Anlage noch läuft. Koppeln Sie beide Systeme miteinander (z. B. via SIP-Trunk), damit interne Anrufe zwischen Alt und Neu funktionieren. So können Sie nach und nach Benutzer migrieren, ohne dass die Kommunikation abbricht. – Pilot & Schulung: Beginnen Sie mit einer Pilotgruppe auf Teams. Diese kann bereits mit dem Rest telefonieren dank Kopplung. Sammeln Sie Feedback, schulen Sie diese Piloten – dann schulen diese evtl. Kollegen (Multiplikatoren). So sind erste Kinderkrankheiten weg, bevor die Masse umstellt. – Stufenweise Portierung: Portieren Sie Rufnummern in Wellen, z. B. abteilungs- oder standortweise. Nicht alles an einem Tag (außer das Unternehmen ist klein). Zwischen den Wellen – ein stabiler Parallelbetrieb. So reduzieren Sie das Risiko – falls etwas hakt, ist nur eine Gruppe betroffen, nicht alle. – Synchronisierte Systeme: Stellen Sie sicher, dass während der Migration beide Systeme gepflegt werden. Z. B. neuen Mitarbeiter sowohl in alter Anlage als auch in Teams anlegen, bis Migration komplett. So verpasst niemand Anrufe. – Fallback-Möglichkeit: Lassen Sie die alte Anlage erst komplett abschalten, wenn Sie sicher sind, dass Teams stabil läuft. Im Notfall könnten Sie – dank Kopplung – Anrufe wieder dorthin lenken. Oder behalten Sie kritische Fax/Notfallgeräte vorerst an der alten Anlage bis Teams-Lösung da ist. – Sonderdienste beachten: Wenn es Fax, Türtelefone etc. gibt, plan: Entweder separate Lösung oder Anschaltung an Teams (z. B. via Analog-Gateway). Machen Sie nichts „hart kaputt“ – testen Sie diese Szenarien vor Umschaltung. – Kommunikation & Support: Informieren Sie die Belegschaft früh über die Umstellung. Bieten Sie Hilfen: „So benutzt man das neue Teams-Telefon…“ Richten Sie in der Umstellungswoche einen verstärkten Support ein (Floorwalker, Hotline). So fühlen sich Nutzer betreut und der Betrieb läuft weiter. – Nummernplan-Kontinuität: Idealerweise behalten alle ihre Rufnummern. Dann merken externe Partner gar nichts von der Umstellung – die Visitenkarten bleiben gültig. Intern, falls Durchwahl-Schema neu, parallel eine Zeit lang eine Kurzwahlübersetzung einrichten, damit alte Gewohnheiten funktionieren (z. B. Kollege war 12 auf alter Anlage, auf neuer hat er 2012 – man kann per Dial Plan „12“ auf „2012“ mappen als Interim). – Testen: Vor, während, nach jeder Welle: umfangreiche Tests. Checklisten: Jede migrierte Nummer probieren eingehend/ausgehend, Voicemail, Notruf ggf. – Rollout Meetings: Koordinieren Sie Fachbereiche eng: z. B. Teamassistenz muss wissen, wie sie in Teams Chef-Anrufe handhabt (Delegation). Solche Spezialfälle im Training abdecken, damit Arbeitsprozesse nicht stocken. – Paralleler Betrieb per SIP-Kopplung: Während Migration können eingehende Anrufe z. B. auf alter Anlage an Teams-User weitergeleitet werden (SIP-Trunk Routing). Damit kann man sogar Nummern portieren, aber dennoch falls User auf alt war, ihn via Kopplung erreichen. Solche Routen intelligent setzen. – Abschaltung Alt erst bei Stabilität: Resist the urge, alte Anlage sofort abzubauen. Lieber einige Wochen Überlappung lassen als Sicherheitsnetz. – Projektsteuerung: Dedizierter Migrations-Projektleiter sollte Zeitpläne und Ressourcen managen, damit kein Standort vergessen wird und alle Abhängigkeiten (Netzwerk upgrade? SBC installation?) rechtzeitig bereit sind, um keine Pause im Rollout zu erzwingen. – Fazit: Durch Parallelbetrieb, phasenweises Vorgehen, gute Kommunikation und Testing kann man praktisch ohne Ausfall migrieren. Die Nutzer wechseln „sanft“ und haben notfalls noch ihr altes Telefon griffbereit bis zum finalen Umstieg – so entsteht kein Stillstand, sondern fließender Übergang.

11. Welche Geräte-Standards sind sinnvoll (Headsets, Telefone, Räume)?
Es empfiehlt sich, für jede Nutzungsklasse einen Standard oder eine engere Auswahl von zertifizierten Teams-Geräten festzulegen: – Headsets (für Büromitarbeiter): Ein gutes, MS Teams-zertifiziertes USB-Headset sollte Mindeststandard sein. Kriterien: Noise Cancelling-Mikrofon (damit im Großraum kein Lärm übertragen wird), Tragekomfort, robust, evtl. DECT/BT kabellos für Bewegungsfreiheit. Beispiele: Jabra Evolve2 65, Poly Blackwire/Revo etc. Einheitliche Modelle erleichtern Support (Ersatzteile, alle kennen es). – Tischtelefone (Desk Phones): Klassische Telefonapparate sind optional, da PC+Headset meist ausreicht. Für bestimmte Rollen (Empfang, Werkstatt, ältere Kollegen) kann aber ein Teams-Telefon mit Hörer sinnvoll sein. Standards: z. B. Yealink oder Poly Teams-Phones. Achten auf: großes Display für Team-Funktionen, guter Lautsprecher, vielleicht Speed-Dial-Tasten. – Konferenzlautsprecher: Für kleine Meetingräume oder mobiles Arbeiten im Team – z. B. Jabra Speak-Serie oder Poly Sync. Standard definieren, damit alle sowas bei Bedarf beschaffen anstatt Billig-Lösungen, die Echo erzeugen. – Raumsysteme: Meetingräume statt klassischem Konferenztelefon eher mit Teams Rooms Geräten ausstatten. Standard z. B.: Logitech Rally Bar oder Poly Studio X für mittlere Räume, mit Touch-Konsole. Für kleine Huddle: Collaboration Bar (All-in-One Kamera+Mic, z.B. Yealink A20). – DECT/Mobil-Lösungen: In Lager oder Fertigung kann ein schnurloses DECT-Telefon nötig sein. Es gibt Teams-integrations (via SIP Gateway) für DECT (z. B. Poly Rove series). Alternativ Smartphone mit Teams-App (aber dann Wlan-Abdeckung!). Standard: definieren, ob sowas unterstützt wird und welches Modell (damit Integration getestet). – Webcams: Für Nutzer mit Stand-PC ohne Cam – Standardmodell definieren (z. B. Logitech C925e), damit Videotelefonie klappt. – Adapter & Speakerphones: Falls spontane Konferenzen in Räumen ohne Gerät: Standard portabler Speaker (z. B. Jabra Speak 750). – Zubehör: z. B. USB-Verlängerungen, Busylights (Statuslampen), falls gewünscht – definieren, ob und welche. – Warum Standards? Einheitlichkeit erleichtert Ausrollen von Firmware, Troubleshooting (Support kennt die Modelle), Spare Pool halten. – Lifecycle: Definieren Sie auch, wie lange ein Gerät im Einsatz bleibt (z. B. Headset 3 Jahre, dann Ersatz; Konferenzgeräte 5 Jahre). So können Sie planmäßig Budgetieren, statt reaktiv bei Defekt. – Zertifizierung: Nur Teams-certified nehmen, denn diese sind getestet für Kompatibilität (Knöpfe für Teams-Funktionen, kein Treiberstress). – Management: Wenn Sie viele Teams Phones haben, definieren Sie, wie die verwaltet: z. B. alle im Teams Admin Center registriert, named entsprechend dem Raum. Update-Policy: wer spielt Firmware ein (Device Admin). – Benutzerfreundlichkeit: Feedback von Piloten einholen – manche Headsets mögen Leute gar nicht (Trageform etc.). Evt. zwei Varianten anbieten (Ohrbügel vs. Over-ear). – Räume-Sicherheit: Standard heißt auch: dokumentiert, wer welches Modell wo hat – und Backups (z. B. Ersatzfernbedienung vorrätig). – Persönliche Geräte vs. Pool: Bei Headsets oft Personengebunden (Hygiene). Telefone eher ein Pool, den man relocaten kann. Das im Plan vermerken: Headset -> bei Austritt Mitarbeiter zurück und reinigen/neu vergeben oder aussondern? – Testing vor Standardfreigabe: Machen Sie mit IT/Pilotusern einen Test diverser Modelle, wählen Sie das beste aus den Kriterien: Audioqualität, Bedienung, Preis. – Dokumentation: Erstellen Sie eine Liste empfohlener/verbotener Geräte. Z. B. „Nur Modell X, Y sind zugelassen. Private Headsets können genutzt werden, aber Support nur auf Standard.“ – Räume Standard: Standardisiert auch UI (z. B. alle mittleren Rooms mit Touch-Konsole, damit Nutzer sich nicht jedes Mal umgewöhnen). – Firmware und Sicherheit: Governance: immer neueste Firmware auf Geräten. Alte Telefone (ohne Modern Auth) nicht mehr zulassen (Sicherheitslücke). In Summe: – Headset-first-Policy (für die meisten: Headset am PC), – Phones wo nötig, – Qualitätsgeräte für Konferenz, – certified and managed. So stellen Sie sicher, dass die Technik kein Hindernis ist und Supportfälle minimal bleiben („Knackt/echo“ kommt meist von Billiggeräten).

12. Was ist bei Contact-Center-Integration governance-seitig zu beachten?
Ein Contact Center (CC) bringt oft eigene Anforderungen und Tools mit. Wichtige Punkte: – Zertifizierte CC-Lösung: Nutzen Sie möglichst eine von Microsoft zertifizierte Teams-Contact-Center-Lösung. Diese sind getestet auf Compliance mit Teams APIs und bieten stabilere Integration (z. B. Genesys, NICE, Luware, Anywhere365 etc.). Governance sollte vorschreiben, nur solche einzusetzen, um Support und Updatesicher zu sein. – Rollen & Verantwortungen: Im Betrieb braucht es klare Abgrenzung: Wer administriert das CC-System vs. Teams? Z. B. kann das CC eigene Admin-Oberfläche haben (Skills, Warteschleifen). Legen Sie fest, ob das UC-Team das mitbetreut oder ob Fachbereich/CC-Anbieter das macht. Erstellen Sie eine RACI: z. B. Fachbereich bestimmt Ansagetexte, IT setzt sie im System um; IT verantwortet Verfügbarkeit, Fachbereich Performance Kennzahlen etc. – Datenschutz & Mitschnitt: Contact Center sind prädestiniert für Aufzeichnung und Analytics (Gesprächsmitschnitte, Kundeninfos). Hier muss Governance streng prüfen: Dürfen wir das? Für Trainings ja, aber Mitarbeiterüberwachung nein. Der Betriebsrat sollte einer CC-Einführung ausdrücklich zustimmen und mitgestalten (z. B. Regeln, wie oft ein Agent-Mitschnitt qualitativ ausgewertet wird – und dass es nicht in Personalakte als Negativeintrag kommt). – Integrationstests & SLA: Ein CC hängt ggf. via Bot oder Direct Routing an Teams. Testen Sie vor go-live alle Failure-Szenarien: Was wenn Bot nicht beitritt – geht fallback an Voicemail? Was wenn Teams down – kann CC offline Kunden in Queue halten und Ansage geben? Definieren Sie für Integration ein SLA mit dem CC-Anbieter (Responsibility dem gegenüber). – Qualifikation & Zertifizierung: Contact Center Agents nutzen oft spezielle Funktionen (Consult Transfer, Snoop etc.). Stellen Sie sicher, dass die Teams-Umgebung diese unterstützt. Evtl. muss man Teams Graph API Policies setzen, um CC-Bot alle Berechtigungen zu geben. Governance: Der Integrator darf nur minimal nötige Rechte bekommen (z. B. nicht globale Admin, sondern nur Anwendung mit Contact Center-Scope). – Compliance Recording im CC: Ist das CC in reguliertem Umfeld (Bank), muss es recordings an Policy unterwerfen. Also sicherstellen, dass auch CC-Anrufe (die oft über Bot laufen) dem Compliance Recording Tool zugeführt werden – Testen und abnehmen lassen. – Workforce-Management: Wenn das CC komplex ist, hat man WFM Kennzahlen (wie viele Calls, Wartezeit etc.). Legen Sie fest, wer diese überwacht und an Management berichtet (meist CC-Leiter). Governance: „Telefondienst in CC muss definierte Servicelevels (z. B. 80% der Anrufe <= 20s Wartezeit) einhalten“ – das wird gemessen und in KPI-Reports. – Änderungsmanagement (CC vs. Teams): Auch hier Change-Koordinierung: Ändert man etwas in Teams (z. B. Upgrades, neue Routing), prüfen ob Auswirkung auf CC. Umgekehrt, CC-Software Update – erst in TestTenant probieren. Governance: Keine CC-Änderung ohne Test in isolierter Umgebung (viele CC-Anbieter haben Staging). – Dokumentation von Flows: Contact Center Routing oft komplex (IVR, Skills). Halten Sie Diagramme und Dokumentation bereit, und binden Sie sie in die Governance-Doku ein. So können auch neue Admins es verstehen – „Single Point of Knowledge“-Risiko reduzieren. – End-to-End Monitoring: CC-Anrufe gehen durch viele Systeme – richten Sie Monitoring ein, das von außen testet: z. B. ein Testanruf in Hotline alle 30 min, prüft ob jemand dran geht (oder Bot-Antwort kommt). So merken Sie sofort, falls etwas klemmt (z. B. Bot login out). – Betriebsvereinbarung (Betriebsrat): Speziell, wenn CC-Agents intensives Monitoring unterliegen (Anzahl Anrufe, Pausen etc.), ist eine BV nötig, die regelt was ausgewertet wird und was nicht. Muss vor Inbetriebnahme erfolgen, um Konflikte zu vermeiden. – Schulung der Agenten: Aus Governance-Sicht: definieren Sie Standards, wie Agents in Teams arbeiten sollen (z. B. Status „Beschäftigt“ bedeutet im Kundengespräch, Agent soll sich daran halten). Und entwerfen Sie Hilfskonzepte: z. B. Teams-Verfügbarkeit wird vom CC genutzt, daher Agents müssen auch bei PC-Sperre „nicht verfügbar“ setzen etc. – Das als Richtlinie schulen. – Third-Party Abhängigkeit: Ein CC ist oft extern gehostet oder von extern gemanagt. Stellen Sie sicher, dass im Vertrag Support-Zeiten, Reaktionszeiten etc. klar sind, und dass man „Notbetrieb“ definierte, falls CC-Software ausfällt (z. B. alle Anrufe zur Zentrale umleiten als Fallback). – Integration in Notfallpläne: Wenn das CC relevant ist (z. B. Bürgerhotline), dann in BC/DR Plan vorsehen, wie es im Notfall erreichbar bleibt (ggf. Notfall-Handys an Agenten austeilen, etc.). Zusammengefasst: Die Contact-Center-Integration erfordert enge Governance-Koordination zwischen Business (Kundenservice) und IT. Sicherheit, Datenschutz und Servicelevels müssen gemeinsam festgezurrt sein, damit das CC reibungslos und regelkonform im Teams-Umfeld läuft.

13. Welche Monitoring-/Alerting-Pflichten sichern SLAs ab?
Um definierte Service-Level-Agreements (SLAs) einzuhalten, muss man proaktiv überwachen: – System-Monitoring mit Alerts: Alle kritischen Komponenten sollen automatisch überwacht sein und Alarm schlagen, bevor SLA verletzt wird. Beispiele: – SBC: Alarm bei CPU > 80% oder wenn Trunk down > 5 Min, damit man vor einem kompletten Ausfall eingreifen kann. – Teams Dienst: Verwenden Sie Microsoft 365 Service Health Alerts – bei Incident-Eintrag (z. B. „Teams Calling PSTN error“) erhalten Admins sofort E-Mail/SMS. – Netzwerk: Monitoring schickt Alert, wenn Paketverlust auf WAN-Link steigt oder Latenz über Schwelle, damit man Provider früh informieren kann, bevor Nutzer massiv betroffen. – QoS-Überwachung: Wie in Sektion 9 – Alerts bei Überschreiten bestimmter schlechter Call-Raten. Wenn z. B. in einem Standort plötzlich 20% der letzten 15 Min Calls „poor“ waren, generieren Sie ein Ticket für Netz-Team. So wartet man nicht auf Userbeschwerden (die SLA „Call Qualität > 4 MOS“ sehen Sie so proaktiv). – SLA-spezifische Checks: Falls man intern SLA „99,9% Verfügbarkeit im Monat“ hat, ein Mechanismus: – Up/Downtime Log des PSTN-Gateways (SBC) – generieren Sie Report am Monatsende. Tools können das: Ping-Tests und Sessionconnect-Tests im Intervall, dann Downtime summieren. Wenn droht < 99,9, alarm an Service Owner vor Ende – Korrektur/SLA-Ausnahme plausibilisieren. – Transaktions-Monitoring: Z. B. alle 60 min einen Testanruf in die Hotline aus dem PSTN generieren (automatisiert via GSM-Modem oder SIP). Schlägt der fehl, Alert. Das sichert Erreichbarkeits-SLA („99% der Zeit ist Hotline erreichbar“). – Ticket-Überwachung: Ist auch Teil: Ein SLA z. B. „P1 innerhalb 4h gelöst“ – definieren Sie in ITSM-Tool Timer, der nach 4h eskaliert falls Ticket noch offen. Also interne Monitoring der Response/Resolve-Zeiten. – Alarmierungskette: Alerts sollten an die richtigen Leute: i.d.R. NOC oder On-Call-Person. Bei kritischen 24/7-SLAs (z. B. Notfall-Hotline) unbedingt Rufbereitschaft, die Alarm per SMS/Pager kriegt. – Kombinierte Dashboard: Richten Sie ein Service-Dashboard ein, das Ampeln zeigt: PSTN ok? SBC ok? Last und Quali ok? – dieses kann man in Echtzeit im Ops Center auf Monitor haben. So sieht man Trends, bevor sie SLA brechen. – Wöchentliche Reports: Um SLA-Einhaltung zu reviewen, generieren Sie wöchentlich Berichte (Anzahl Ausfälle, Schnitt MOS etc.). Bei Abweichung (z. B. QoS unter Ziel) sofort Problemanalyse (Problem-Management-Prozess). – Provider SLA Monitoring: Bspw. hat Provider 99,9% Netz-SLA. Wie merken Sie seine Ausfälle? Der SBC loggt vielleicht 2h Trunk down – das protokollieren, an Provider for Service Credit. Muss man machen, sonst bleiben Ansprüche liegen. Also ein Alert „Trunk down cumulativ > 30min/Monat“ -> Check SLA-Breach. – Vollständigkeit & Test der Alerts: Mindestens quartalsweise Alarmsimulation oder Review: Gehen alle Alarme? (z. B. Notruf-Alarm? vllt. testcall). – Dokumentation der Reaktion: Wer reagiert auf Alerts? In Runbooks festlegen. Lese-/Rufbereitschaftspläne dem Monitoring-Team geben. So ist sichergestellt, dass Alarm nicht ins Leere geht und damit SLA dann trotzdem reißt. – Überlauf-Eskalation: Wenn Alarm ignoriert/übersehen (Mensch schläft): definieren, dass nach z.B. 15 min ohne Reaktion nächsthöhere Person alarmiert wird (manche Tools machen das). Im Grunde: Ein dichtes Monitoring- und Alarmierungssystem ist Ihr „Frühwarnsystem“, um Service-Level-Einbrüche (Ausfälle, schlechte Qualität, verzögerte Reaktionen) zu erkennen und direkt gegensteuern zu können, bevor z. B. ein ganzer Tag Telefonie ausfällt und SLA nicht erreicht wird. Das ist gelebte Governance im Betrieb.

14. Wie werden Sonderdienste (Fax, Aufzüge, Alarmanlagen) behandelt?
Diese sogenannten Analog-/Sonderdienste kann man nicht ignorieren. Mögliche Ansätze: – Weiterbetrieb auf alter Infrastruktur: Man kann beschließen, Faxgeräte, Frankiermaschinen, Aufzugsnotruf weiterhin über klassische Telefonleitungen laufen zu lassen, unabhängig von Teams. D.h. man behält evtl. einen analogen Telefonanschluss pro Standort nur für diese Zwecke. Das entkoppelt diese Dienste von der Teams-Migration – was zuverlässig aber doppelstrukturell ist. – Integration via ATA/Gateway: Es gibt Analogue Telephone Adapter (ATA), die analoge Geräte ans IP/SIP-Netz bringen. Z. B. kann man ein Fax an einen ATA hängen, der registriert sich am SBC oder an Teams (Teams unterstützt inzwischen zertifizierte ATA über „SIP Gateway“). So bekommt das Fax eine Cloud-Rufnummer. Allerdings: Fax über VoIP (T.38) ist fehleranfällig – man muss es testen und oft Kompromiss bei Übertragungsgeschwindigkeit eingehen. Für moderate Faxvolumen geht es aber. – Fax-to-Mail / Digital Faxdienste: Besser: Das klassische Faxgerät ablösen. Etwa auf einen Cloud-Fax-Dienst umstellen, wo eingehende Faxe per PDF an E-Mail gehen und ausgehende via E-Mail versendet werden. Governance kann festlegen: „Physische Faxgeräte werden bis Datum X abgeschafft, stattdessen Fax2Mail-Lösung Y verwenden.“ Das spart Hardware und ist zukunftssicherer. – Aufzugnotruf & Brandmelder: Solche Anlagen sind sicherheitsrelevant und haben oft strenge Vorgaben (müssen auch bei Stromausfall funktionieren etc.). Hier behält man meist separate analoge Leitungen oder rüstet auf GSM-Modul auf. Teams-VoIP ist hier nicht ideal, weil vom Netzwerk und Strom abhängig. Governance-Empfehlung: Aufzugnotruf bleibt analog/extern. Oder falls man es unbedingt integrieren will, dann über ein Gateway mit USV-Strom und lokalen PSTN-Fallback. In jedem Fall regelmäßig testen mit Servicefirmen. – Türsprechstellen: Oft sind moderne Türsprechstellen IP-fähig – diese kann man via Direct Routing als SIP-Endpunkt einbinden (z. B. Doorphone ruft bei Klingel per SIP eine Teams-Nummer an, z.B. Empfang). Wenn vorhanden, solche Lösungen einsetzen. Ältere Türtelefone analog => ATA/Gateway oder belassen auf separater Tür-Sprech-Anlage. Hier schaut man, was praktikabel ist. – Frankiermaschinen / EC-Cash-Geräte: Viele nutzen Telefonleitung zum Datenübertrag. Heute häufig alternative über Internet. Check: Kann die Maschine auf LAN? Wenn nein, dann kleiner ATA mit RJ11 in RJ45-Wandler, der an Teamssystem trunk. Oder – wahrscheinlicher – ein DSL-Kombianschluss für Fax+Frankierer belassen. – Alarmanlagen: Einbruch/Brandmelder mit Wählgerät – hier ist dringende Empfehlung: belassen auf PSTN oder rüste auf IP-Alarmmodul mit eigenem LTE. Man sollte Alarmierung nicht von Teams-VoIP abhängig machen, aus Risiko-Sicht. Governance: diese Geräte fallen nicht unter die Teams-Migration, sie werden gesondert vom Facility/Security betreut. – Dokumentation: Alle diese Sonderfälle in der Migrations-Doku aufführen: „Gerät X an Standort Y – Lösungsweg: …“ und wer verantwortlich. – Testläufe: Nach Umstellung (oder Integration an Gateway) jedes dieser Geräte testen (Fax senden/empfangen, Alarm absetzen, Aufzugnotruf test mit Service). Ergebnisse protokollieren. Wenn’s Probleme gibt, Plan B definieren. – Kosten/Nutzen: Abwägen: Fax z.B. wenn pro Monat 2 Faxe – vielleicht abschaffen und Absendern Alternative geben (E-Mail). Oder auf Cloud-Fax umstellen. – Schulung & Info: Kommunizieren Sie z. B. ans Personal: „Fax jetzt über Outlook versenden“ oder „Aufzugnotrufe laufen weiter wie gehabt, hier ändert sich nichts – eigene Backup-Batterie“. – Verantwortlichkeiten: Oft ist das Gebäudemanagement für Aufzüge/Alarm zuständig, IT nur bedingt. Daher Governance: Koordinationspunkt definieren (z. B. IT muss dem Facility Team Bescheid geben, wenn analoger Telefonanschluss gekündigt wird, der noch für Alarm gebraucht – damit sie Ersatz finden). – Alternative Mobilfunk: Manche Firmen statten z. B. zuständige mit Diensthandys aus und definieren: falls analog-Fax stirbt, dann knipst man Foto und mailt – sprich es wird in Notfall auf Mobil gewichen. Aber besser sauber neue Lösung implementieren als adhoc Workaround. Zusammengefasst: Kein Sonderdienst bleibt unbeachtet. Entweder integriert man ihn sauber (sofern technisch möglich und risikoarm) in die Teams-Umgebung oder man stellt eine separate Lösung bereit, die parallel weiterläuft. Wichtig ist Transparenz und Wartung dieser Restposten – damit sie im Eifer der VoIP-Umstellung nicht ausfallen.

15. Wie funktioniert Teams Phone Mobile in einer Governance?
Teams Phone Mobile (auch Operator Connect Mobile genannt) integriert die Mobilfunknummer direkt in Teams. Governance-Aspekte: – Vertragsgestaltung & Provider-Rolle: Man benötigt einen Mobilfunkanbieter, der an diesem Programm teilnimmt. Die Governance muss definieren, wer im Unternehmen diesen Mobilfunkvertrag verwaltet und wie Nummern bereitgestellt werden. Oft übernimmt die Telekommunikationsstelle auch die SIM-Bestellungen. Wichtig: klar regeln, welche Kosten anfallen (z. B. Roaming), wer Freigaben erteilt etc., analog zu Mobilfunkpolicy. – Geräte-Policy (BYOD vs COPE): Mit Teams Phone Mobile kann theoretisch die dienstliche Nummer auf einem privaten Handy genutzt werden. Governance sollte entscheiden: Erlauben wir das (BYOD) oder stellen wir Diensthandys (COPE)? Wahrscheinlich letzteres, um Kontrolle über Device-Compliance zu haben. In der Policy dann: Mitarbeiter mit Teams Phone Mobile müssen ihr Gerät MDM-registrieren (z. B. Intune), weil ja Unternehmenskommunikation drauf läuft. – Nutzeraufklärung: Teams Phone Mobile verheiratet Mobil und Teams. Governance sollte den Nutzern erklären: „Du hast eine Nummer, Anrufe kommen sowohl in Teams-App als auch klassisch per Handy rein. Du kannst auf dem PC rangehen oder am Handy, wie es passt.“ Damit keine Verwirrung („es klingelt doppelt“). Und: Arbeitszeit-Regelungen! Wenn das die persönliche Mobilnummer war, und jetzt auch im Teams-Client, könnte ständige Erreichbarkeit drohen. Da greift evtl. eine Policy: „Schalte außerhalb Arbeitszeit Bitte-nicht-stören in Teams.“ etc., oder definieren, wann die SIM deaktiviert wird (z. B. im Urlaub). – Technische Qualität: Governance muss auch hier QoS im Blick haben: Mobilfunk kann schwankend sein. Wenn ein Call an Teams übergeben wird (Uplift ins Meeting), sollte man definieren, dass Agents es nur mit gutem Netz tun etc. – Datenschutz & Aufzeichnung: Bei Anrufen, die rein auf der SIM stattfinden (nutzt Person vllt. mal die Handytelefonie statt Teams) – diese könnten nicht mitgeschnitten oder erfasst werden wie Teams-Calls. Wenn man aber ein regula. environ hat (z. B. alle Anrufe aufzuzeichnen), muss man via Operator-Lösung das sicherstellen, oder User anweisen, geschäftliche Anrufe immer via Teams App zu tätigen (damit die Polices greifen). – Wechsel des Providers: Teams Phone Mobile bindet an Provider. Governance: eventuell Notfallplan, falls Provider Mängel -> Switch back to normal Teams Direct Routing for those users. – Nummernportierung bei Ausscheiden: Hat der Mitarbeiter die Mobilnummer auch privat genutzt? Besser klären: Die Nummer bleibt Eigentum der Firma – falls jemand ausscheidet, wird SIM entzogen und Nummer neu zugewiesen. (Muss HR-Prozess sicherstellen, oft bei Dual-Use sensibel). – Betriebsrat: Evtl. Mitbestimmung, da es „Dual Ring“ Effekte hat -> Erreichbarkeit auch außerhalb Büro. Evtl. in BV regeln, dass sie Diensthandy auch ausmachen dürfen und kein Nachteil etc. – Administration: Teams Admin Center zeigt diese Mobile-Nummern den Nutzern als ihre Primärnummer. Der Admin muss sie pflegen wie normale Nummern. Governance definieren, wer freischaltet (z. B. nur bestimmte Abteilungen bekommen OCM). – Kostenkontrolle: Mobilfunkgespräche, die via SIM geführt werden (auch wenn in Teams angezeigt), laufen in Mobilfunkrechnung. Die IT muss also beides tracken: PSTN via Operator Connect (Festnetz) und Mobil usage. Den Providernreport aufsplitten, sonst doppelt evtl. Abrechnung. Governance: Finanz-Abteilung einbinden, damit niemand überrascht ist. – Feature Governance: OCM erlaubt z. B. „Uplift“ – sprich, in Mobilanruf zu Teams-Meeting wechseln. Hat das Implikationen, z. B. kann man dann aufzeichnen? Wenn ja, Info an Agent. – Security: Mobiltelefon kann auf Teams-Nummer zugreifen – sicherstellen, dass wenn Gerät lost, remote wipe etc. per Intune. – Churn & Support: Für Support Team bedeutet OCM: Sie müssen evtl. mit Mobilfunkprovider zusammenarbeiten bei Störungen (z. B. SIM hat ein Provisioningproblem). Klare Eskalationswege definieren. – Insgesamt: In Governance ist Teams Phone Mobile eher die Schnittstelle Mobilfunk <-> IT. Man muss Mobilfunk-Policy (die typ. BYOD/COPE, Roaming etc. regelt) mit Teams-Policy verheiraten. Die Nutzer bekommen dadurch eine einheitliche Erreichbarkeit – Governance muss dafür sorgen, dass das nicht zur Dauerüberlastung der Nutzer führt, und dass alle rechtlichen/regulativen Pflichten auch auf dem Mobilweg erfüllt sind. In Summe: gut orchestrierte Mobilfunk-Integration, definierte Verantwortlichkeiten, und Achtung auf Work-Life-Balance der Mitarbeiter (die Danger: immer erreichbar).

16. Wie gehen Unternehmen mit internationalen Standorten/Providern um?
Bei weltweitem Einsatz muss die Telefonie-Governance international skaliert werden: – Länderspezifische Compliance: Jedes Land hat eigene Regeln (z. B. Notruf, Aufzeichnung, Rufnummernformat). Die Governance muss pro Land Zusatzrichtlinien haben. Z. B.: in Indien ist VoIP ausländischer Operator nicht erlaubt – dort muss man lokalen Operator nutzen (Direct Routing in Indien). In USA 911-Gesetze (Ray Baum) – dort muss z. B. genaue Adresse pro Nutzer dynamisch ermittelbar sein -> also dort zusätzliche Mechanismen einführen. Governance sollte länderspezifische Kapitel haben oder lokale Ansprechpartner. – Mix aus Providern: Wahrscheinlich nutzt man eine Kombination: z. B. für Europa Operator Connect (ein Operator deckt 10 Länder) plus Direct Routing in einigen exotischen Ländern mit lokalen SIP-Providern. Das heißt, mehrere Carrier-Verträge parallel. Governance muss definieren, wer diese managt (z. B. pro Region ein Telko-Manager) und wie Konsolidierung der Nummern und Kosten erfolgt (z. B. zentrales Reporting). – Zentrale vs. lokale Administration: Je nach Organisation kann Telefonie zentral gemanagt werden oder in Ländern delegiert. Governance RACI anpassen: evtl. „Country IT Admin“ bekommt Teilrechte (z. B. darf Nummern seines Landes im Teams Admin Center verwalten). Das braucht ein klaren Rahmen, damit lokal nicht wild-west passiert. Also z. B. globaler Nummernplan vorgeben, lokaler Admin setzt ihn um. – Zeitzonen & Support: Wenn man 24h-Follow-the-sun hat, definieren, welches Supportteam welches Zeitfenster abdeckt. Oder globales Team mit Shift. Wichtige: Incident-Eskalation global: Nacht in EU, Tag in Asien – Asia IT reagiert erstmal etc. – Internationale Dialpläne: Richten Sie pro Land angemessene Wählregeln ein (z. B. in UK Nutzer möchte 020… statt +4420). Teams kann pro Benutzerstandort unterschiedliche Dial Plans nutzen. Governance: pflegen eines Dial Plan Catalogs pro Land – vom global UC Team erstellt, lokal verifiziert (ob alle wichtigen Notruf/Kurznummern drin). – Notruf pro Land: Sicherstellen, dass für jeden Standort die Notrufstrategie geklärt: in EU 112 ok, aber in z.B. USA 911 definieren. Teams Notruf Policy kann per Office Location gesteuert werden (PSTN-Routing an US trunk etc.). – Mehrsprachige Ansagen: Wenn Auto-Attendants/IVR global genutzt, Governance definieren: entweder Multi-Lingual (-> Ansagen in jeweiliger Sprache, je nach Caller Region) oder separate Ansagen pro Land. Muss fachbereich entwerfen, IT implementieren. Das ist oft Thema (Kulturunterschiede – in DE formell, in US lockerer). Also QA, Lokalisierungsteam einbinden. – Provider Performance im Ausland: Monitor Standorte separat. Z. B. Latenz von APAC-Büro zu Teams DC oft höher – definieren, was akzeptabel, ggf. Region-Direct Routing deployen (Medien-Lokalisierung). – Regulatorische Abstimmung: Manche Länder verlangen z. B. Telco-Registrierung (in DE muss Cloud-PBX-Betreiber Notruf gewährleisten, man arguet „Carrier macht das“, aber immer up-to-date bleiben). – Gebühren und Policy: Legen Sie fest, wer was darf: z. B. darf Büro in Land A internationale Anrufe über Land B’s Trunk machen? (-> Toll Bypass: streng verboten in vielen L.). Teams hat Location Based Routing, das pro Land steuert: das soll man implementieren damit z. B. ein Indischer Mitarbeiter nicht kostensparend via UK trunk nach Mumbai anruft (das wäre illegal in IND). Governance: diese LBR Policies pro Land einführen. – Lokale Besonderheiten: z. B. in Frankreich existieren spezielle Service-Nummern (Numéros spéciaux) – definieren, ob/wie erreichbar (z. B. 08x). Oder in USA 1-800 toll-free inbound – Team muss dafür provider side DIDs haben. Also pro Land klären: Brauchen wir dort ServiceNumbers, wie realisieren wir in Teams. – Involvierung lokaler IT & Management: Machen Sie Telefonie Governance zum globalen Programm, aber binden Sie jedes Land ein via „Country champion“. So werden kulturelle und rechtliche Feinheiten nicht übersehen. – Internationaler Provider-Mix optimieren: Evtl. strebt man One global provider an, aber wenn einer nicht alle abdeckt, muss man zwei/drei kombinieren. Das bedarf Koordination – wer priorisiert, was fallback? Bsp: Land X hat Operator Connect via Orange und Direct Routing via BT. Welchen nutzen? Governance soll Liste definieren: Land -> Primärcarrier. – Kostenverrechnung international: Transparent je Land die Kosten ausweisen, inkl. Währungsumrechnung – globaler CFO will sehen, wo viel kostet. Das kann Hilfsmittel für Efficiency: z. B. Leasing local lines vs. using corp network. – Zeitliche Koordination Migration: Falls noch Migration global, definieren, welches Land wann – und Lessons Learned übertragen. – Dokumentation & Nummernverwaltung global: Idealerweise in einem System (z. B. Excel oder besser ein Telco Inventory Tool) alle Rufnummern weltweit verwalten (Nummer, Land, Zuweisung, Provider). So vermeidet man Überschneidungen oder Vergeßenes. – Sprachbarrieren im Support: Stellen Sie sicher, dass User Support in ihrer Sprache kriegen – entweder durch lokalem L1 oder Dolmetsch. – Fall-back global: Wenn z. B. Teams in Region offline (China?), definieren ob/lokale PBX vorhalten. In Summe: Unternehmen gehen oft so vor, dass zentrale Governance-Richtlinien gelten (Standardtools, Security, globaler Nummernplan), aber mit lokalen Anpassungen. Ein „Hub-and-Spoke“-Modell: Zentrale IT gibt Rahmen, lokale IT implementiert mit Feinjustierung. Regelmäßiger Austausch (Telco Governance Board mit Teilnehmern aller Regionen) hilft, globale Konsistenz und lokalen Fit zu vereinen.

17. Was gehört in eine Sperrlisten/Allowlist-Policy für ausgehende Rufe?
Eine Outbound Call Restriction Policy sollte definieren, welche Rufziele verboten oder erlaubt sind: – Sperrliste (Blacklist): Alle Nummernbereiche, die typischerweise zu Missbrauch oder extrem hohen Kosten führen, sollte man sperren, sofern geschäftlich nicht benötigt. Beispiele: – Premiumdienste: In Deutschland 0900, 0909 etc., in UK 09xxx, international z. B. +878 (Satellit), +809 (Diego Garcia) – solche sind für Betrüger beliebt. – Auskunfts-/Mehrwertnummern: z. B. 118xx (teure Auskunft), 0137 (TED-Nummern). Wenn kein Business-Case -> sperren. – Erotik-/Chat-Nummern: oft eigene Vorwahlen (in DE 118xy oder 0900-5x). – Bekannte Telefonbetrug-Länder-Prefixe: z. B. +37 (somalische Inseln) – meist ruft da legit niemand an. – Individuelle Fälle: Wenn Attacke auf eine Nummer (Wangiri) war, kann man temporär Nummer blocken. – Interne Sonderrufnummern: Manche sperren absichtlich das Wählen interner Durchwahlen von außen und vice versa, um Umgehung von CC zu verhindern (im System realisierbar). – Erlaubt (Allowlist): Dies ist restriktiver – man könnte sagen: NUR Anrufe zu Ländern, in denen wir operieren, und Standard-Dienste sind erlaubt, alles andere gesperrt. Das minimiert Betrug, aber kann legitime spontane Calls behindern (z. B. plötzlich ruft einer doch mal Uruguay, aber Uruguay ist kein Land mit Standort – wäre blockiert). Also Allowlist brauch gut Wartung. – Simpler: man allowed global normal calls, aber blockt definierte Exoten (Blacklisting). – Allerdings, wenn Firma klein und nur national tätig, kann man radikal alles International sperren und nur bei Bedarf freischalten – sehr sicher. – Notruf nie sperren: 112, 110, 911 etc. müssen immer durch. – Auslandssteuerung: Evtl. definieren: Standard-User dürfen International, oder vielleicht limitieren „Muss beantragt werden“ – aber das hindert Business oft. Besser: LowLimits + Monitoring statt starres Verbot. – Zeitbasierte Sperren: Man könnte definieren: International calls in Nachtstunden sperren (normale Leute brauchen das um 3 Uhr nicht, ein Betrug schon). Aber es gibt legitime Schichtarbeit… also tricky, aber denkbar. – Ausgehende Anonymisierung sperren: Dies als „CLIR default off“ – so Anrufe gehen mit Nummer raus, was Betrüger ungern tun. Viele Firmen verbieten absichtliches Unterdrücken (außer definierte User). – Verfahren bei Bedarfsausnahme: In Policy aufnehmen: „Soll ein gesperrtes Ziel angerufen werden können (z. B. Support-Hotline im Ausland), kann ein temporärer Override beantragt werden via IT-Service.“ So hat man Flexibilität. – Technische Umsetzung: In Teams via Calling Policy (wenn man nur ganze categories blocken, begrenzt), besser im SBC Routing oder im Provider (der kann bestimmte Prefixe sperren). Dial Plans kann man auch „^900“ -> „<BLOCK>“ definieren. – Kommunikation: Transparent machen: „Folgende Nummerntypen sind gesperrt, um Missbrauch zu verhindern.“ So ruft keiner frustriert an und wundert sich, sondern weiß, muss anders lösen. – Allowlist Outbound Beispiel: – Erlaubt: Landescodes DE, AT, CH, EU allgemein, US, CN (wo Geschäftspartner), Service 0800 (kostenlos), 00800 (International Freephone). – Gesperrt: Rest der Welt – schaltet man nur fallweise frei. – Das wäre streng, aber absolute Sicherheit. Je nach Business entscheiden. – Evidenz & Überprüfung: Diese Listen sollten min. jährlich überprüft werden, ob noch passend (Business expanded? Dann allow new Land). – Inbound-Sperren: Hier ging’s um ausgehend, aber inbound Spam kann man auch blacklisten (Teams hat Option: „Block inbound calls with no CallerID“ – anwendbar, falls viel Spam). So was in Policy-Annex auch definieren (z. B. „wir blockieren anonyme eingehende, da meist Spam, auf Wunsch schalten wir einzeln frei“).

Also, in so eine Policy gehört: – Liste der gesperrten Präfixe (Länder, Dienste) – möglichst mit Begründung oder Kategorie. – Liste evtl. freigegebener Präfixe (wenn man Whitelist fährt). – Vorgehen bei Ausnahmefreischaltung. – Verantwortlicher, der Änderungen an der Liste vornimmt (z. B. Telephony Admin nach Freigabe durch CISO).

Damit hat man das Telefonieverhalten unter Kontrolle und schützt vor hohen Rechnungen bzw. betrügerischen Verbindungen.

18. Welche Lizenzpfade sind wirtschaftlich (E3/E5/Add-ons)?
Das hängt stark von der bestehenden Microsoft-Lizenzlandschaft und den benötigten Funktionen ab: – Microsoft 365 E5: Enthält bereits Phone System (Cloud-PBX) und Audio-Conferencing. Wirtschaftlich ist E5, wenn Sie neben Telefonie auch die vielen anderen E5-Komponenten nutzen wollen (Security, Analytics etc.). Für rein Telefonie betrachtet: E5 vs E3+AddOn – E5 kostet oft ~15 € mehr als E3, das Phone System AddOn kostet ~3–4 €. Also E5 ist teurer, aber hat mehr drin. Wenn Sie also nur Telefonie brauchen und die anderen E5-Features nicht, ist E3 + Phone System Add-On preisgünstiger. – E3 + Phone System + (Calling Plan): E3 ca. 20 €, Add-On 3 €, und falls Calling Plan national z. B. 7 € = ~30 € gesamt. E5 kostet vllt. 35 € – dicht dran. Aber E5 würde etwa noch PowerBI, Defender, etc. inkludieren. Wenn Sie diese sowieso wollten, ist E5 im Bundle oft wirtschaftlicher, als E3 + separate Tools. Also Kaufmännisch: Wenn Telefonie einzeln zu E3, günstig; wenn aber man z.B. Defender for Endpoint einzeln kauft etc., summiert sich – dann E5 wird attraktiv. – M365 Business Standard + Business Voice (jetzt Teams Phone): Für KMU (bis 300). Business Standard ~10.50 €, Business Voice Add-On inkl. Minuten ~12 € -> ~22 € pro User/Monat kriegt man alles: O365 + Telefonie mit Minuten. Sehr wirtschaftlich für kleine, da keine zusätzliche Carrier-Kosten (1200 national-Min inklusive!). Ab 300 Nutzer geht es nicht, dann Enterprise Pläne. – Frontline (F3) mit Telefonie-AddOn: Frontline-Lizenzen sind billig (ca. 2–4 €) und das Telefonie-Add-On auch (~<1€). Das ist am wirtschaftlichsten, hat aber Einschränkungen (kein Voicemail, max. auf 1 Gerät). Für z. B. Fabrikarbeiter, die nur einfache anrufen, aber kein PC – kann das ideal sein, anstelle jedem eine E3 zu geben. Governance: wo möglich, Frontline nutzen – spart viel. Nur relevant wenn man F-Lizenzen-Kategorie hat. – Calling Plan vs. eigener Trunk: – In manchen Ländern sind Microsoft Calling Plans teuer im Vergleich zu lokalen Minutenpreisen (v.a. Internationales). Für heavy call center, Direct Routing mit Flatrate-Trunk vom Carrier ist oft günstiger. – Für Wenig-Telefonierer hingegen könnte Pay-per-Minute (oder niedrige Plan) besser sein als teure Flatrate. – Also staffeln: z. B. „Vertrieb hat hohes Volumen → Direct Routing mit günstigem Carrier“, „Entwicklung ruft kaum an → Calling Plan Basic 120 Min reicht“. – Mix & Match Lizenzen: man kann E5 und E3+Add mischen im Tenant. z. B. Führungskräfte auf E5 (brauchen PowerBI, Analytics) – Staff auf E3. – Telefonie-AddOn kann man auch nur gezielt den Leuten geben, die PSTN brauchen, andere (rein intern Tel) gar nicht – spart. – Audio-Conferencing-Kosten: E3-Kunden müssen i.d.R. nicht extra zahlen, da MS seit 2022 die Dial-In für Meetings gratis add-on gibt. Falls aber wer mit externem Audiokonf. war, jetzt nicht mehr nötig -> Einsparung. – Sonderfälle: – Education (A-Lizenzen) – A5 ~E5 etc. Dort auch AddOn etc. Meist Unis kriegen günstigere E5 (A5). – Government (G-Lizenzen) – analog E, oft E5 Pflicht wegen Government Cloud. – Lizenzoptimierung im Lauf: – Hinfällig, aber: Skype Online Plan2 -> aber das ist weg. – Kommunizieren: falls Telephony-User count sinkt, AddOn-Lizenzen kündigen (nicht jahrelang ungenutzt zahlen). – Fazit: – Wenig Budget und nur Telefonie: E3 + Phone System AddOn ist Basic-Lösung. – Umfassendes Feature-Bundle: E5 kann Mehrwert liefern (höherer Preis aber mehr drin). – Kleine Firma: Business Voice Bundles. – Frontline-Mitarbeiter: F-Lizenzen mit Tel-AddOn sehr kosteneffizient. – Und immer den Mix so wählen, dass jeder hat was er braucht aber kein Overkill. Im Zweifel Excel-Sheet mit Szenarien kalkulieren: Telephony-Lizenz pro Usercost x count + trunk costs etc., Variation E3 vs E5. In vielen Cases ist E5 wirtschaftlich, wenn man alle E5-Inhalte anrechnet (z. B. E5 ersetzt separate Security-Lizenzen, das rechnet sich). Aber rein Telefonie-sicht isoliert ist E3+AddOn billiger.

19. Wie wird Change-/Release-Management organisiert (Kommunikation, Tests)?
Das Change- und Release-Management stellt sicher, dass Änderungen in der Telefonie-Umgebung kontrolliert und reibungslos erfolgen: – Change Advisory Board (CAB): Binden Sie auch Telefonie-Änderungen in das bestehende CAB ein. D.h. größere Changes (z. B. „Einführung neuer Dial Plan“, „SBC-Firmwareupdate“, „Änderung Routing Notrufe“) werden im CAB-Meeting vorgestellt, auf Risiken geprüft und genehmigt. So haben alle Stakeholder (Netzwerk, Security, Helpdesk, ggf. Business-Verantwortliche) Transparenz. – Planung & Kommunikation: Jeder geplante Change sollte im Voraus angekündigt werden. Z.B. „Am Samstag 20-22 Uhr: Wartungsfenster Telefonie, möglicher kurzer Ausfall bei ausgehenden Anrufen.“ Informieren Sie Nutzer über Mail oder Intranet rechtzeitig. Auch interne IT-Teams (Netzwerk, Support) sollen wissen, damit sie sich darauf einstellen oder parallel-keine-Änderung Regel beachten. – Test in Staging/Simulationsumgebung: Wenn möglich, Änderungen erstmal in kleinem Rahmen testen. Für Teams-Policies kann man Test-User in einer speziellen Policy-Gruppe anlegen. Für SBC-Änderungen evtl. im Lab oder an redundanter Instanz austesten. Release-Management bedeutet: erst am Pilot, dann global. – Versionierung & Rollback: Halten Sie Versionen der Konfiguration vor. Wenn z.B. neuer Dial Plan ausgerollt und es gibt Problem, man sollte innerhalb Minuten zum alten Dial Plan zurück können (daher Backup der Patterns). Gleiches bei SBC-Firmware: Muss rückfahrbar sein (Check mit Hersteller: „Kann ich downgraden?“). Das Release-Dokumentation sollte include „im Fehlerfall revert to version x by steps y“. – Abnahmetests nach Changes: Nach jedem wichtigen Change definieren Sie einen Testkatalog. Bsp.: Nach SBC-Update – Test: In/Outbound Call, Notruf, DTMF in Menü, etc. oder nach DialPlan-Change – Test benutzer gängige Formate. Der Change gilt erst als abgeschlossen, wenn Tests ok (evtl. mit Unterschrift). – Release-Zeitpunkte: Legen Sie idealerweise reguläre Wartungsfenster fest. Z.B. „Telefonie-Updates immer Donnerstags 19 Uhr, sofern nötig“. So richten sich alle drauf ein und man bündelt Updates (sofern es nicht dringend Security-Fixes sind). – Parallel-Betrieb neuer Funktionen: Für Release neuer Teams-Funktion (z. B. „Teams SMS-Funktion“ – hypothetisch) aktivieren Sie es erst bei IT oder Pilotgruppe. Sammeln Feedback – wenn stable, Rollout an alle. Microsoft bietet Teams Public Preview, wo man definierte User neue Features vorab sehen lässt. Das kann man in Governance definieren: „UC-Team-Mitarbeiter sind immer im Preview-Ring und testen Neuerungen früh“. – Enduser-Kommunikation bei neuen Features: Rolling out „Walkie Talkie“ or „Voice-enabled Channels“? Weisen Sie die Nutzer proaktiv darauf hin, wozu es gut ist und wie es benutzt wird. Wenn man es nicht will – per Governance auch mal Feature off lassen (via Teams Policies kann man z.B. WalkieTalkie app disallow). – Dokumenten-Update: Jede Änderung (z. B. Policy-Update) muss in den Governance-Dokumenten nachgezogen werden. Z.B. Notruf-Policy-Version 2.0 tritt in Kraft nach neuem Notruf-Routing. – Kontinuierliches Release mgmt-Prozess: Machen Sie z.B. quartalsweise ein Review geplanter Microsoft-Updates. Microsoft veröffentlicht Roadmap, Message Center. Der UC-Serviceowner sollte die rausfiltern, bewerten (Impact? erfordert Aktion?). Dann im Change-Prozess aufnehmen: z. B. „Ab April 2023 entfällt Legacy Auth in Teams Phones – wir updaten vorher alle Phones im März“ – Das als planbarer Change definieren. – Schulungen bei neuen Releases: Falls Release neue Admin-Funktionen bringt (z. B. Operator Connect mgmt), Team fortbilden. – Tooling: Nutzen Sie Tools wie Change-Kalender, damit man Telefony changes nicht parallel zu Netz-Firewall change legt -> Koordinieren (CAB hilft). – Notfall-Changes: Auch definieren: Was, wenn ein kritischer Bug (z. B. SBC hat Leak)? Dann Notfall-Change Prozedur (abgekürzt CAB) nutzen, aber nachträglich im CAB dokumentieren. – Release Management vs. Business Freeze: Berücksichtigen Sie geschäftskritische Zeiten. Z.B. im Weihnachtsgeschäft keine Telefonie-Änderungen, weil Callcenter Hochlast. – Stakeholder-Einbindung: Bei Telefonie-Changes immer auch Business-Vertreter fragen, ob Bedenken. Z.B. neue IVR-Ansage – mit Marketing abstimmen. Kurz: Durch streng kontrolliertes Change Management mit Tests und Kommunikation vermeidet man Überraschungen und Ausfälle und erhöht das Vertrauen der Nutzer in die Telefonie-Plattform.

20. Welche Nachweise/Evidenzen braucht ein Audit?
Ein Audit (sei es intern, extern oder z.B. ISO 27001) möchte sehen, dass die Telefonie-Governance wirksam ist. Typische Evidenzen: – Policy-Dokumente: Alle erwähnten Richtlinien (Telefonie-Policy, Notruf-Policy, Recording-Policy etc.) in gültiger Version, mit Freigabedatum und Verantwortlichem. Der Auditor will prüfen, ob es formale Regeln gibt. – Rollenbeschreibung & RACI: Dokumentation, wer für Telefonie verantwortlich ist (Organigramm, Stellenbeschreibung z. B. „UC Admin – zuständig für Telefondienst“). Ein RACI-Matrix-Dokument kann hier überzeugen, dass Verantwortlichkeiten geklärt sind. – Change-Protokolle: Eine Liste der durchgeführten Änderungen inkl. Genehmigungen. Z.B. CAB-Protokolle oder Change-Tickets aus dem ITSM. Der Auditor schaut z. B., ob die Beispieländerung (z. B. neue SBC-FW) gemäß Prozess durchlief. – Protokolle von Tests/Überprüfungen: – Notruftest-Protokolle (wann, wie getestet, Ergebnis, Unterschrift verantwortliche Person). – QoS-Reports – zeigen, dass Qualität überwacht wurde (z. B. Monatsreport Jan, Feb, Mär – mit Schlüsseldaten). – Fraud-Check Reports (z. B. eine Mail von IT-Sec: „haben CDRs geprüft, keine Auffälligkeit“ – falls man so was macht). – Audit-Log-Review-Protokoll: evtl. vermerkt, dass quartalsweise Admin-Logs gecheckt und nichts unautoris. gefunden. – Schulungsnachweise: Wenn Audit Mitarbeiterqualifikation prüft – z. B. Zertifikat oder interne Schulungsteilnahme der Telefonie-Admins. Oder Awareness-Schulung der Mitarbeiter (z. B. Notruf-Info wurde an alle verteilt am xx.xx. – belegt durch Mail oder Intranet-Post). – Rufnummernplan & Inventar: Auditor könnte stichprobenartig Nachvollziehen, ob alle Nummern dokumentiert sind – also aktuelles Nummernverzeichnis und wer sie nutzt. – SLA-Berichte: Falls es interne SLAs gibt, zeigen, dass man trackt: z. B. ein Quartalsbericht an IT-Leitung „Ziel 99% Verfügbarkeit erreicht, Calls average MOS 4.2 etc.“ – so sieht man, Governance misst Erfolg. – Betriebsvereinbarungen: Im Audit (Datenschutz oder Arbeitsrecht) wäre eine Kopie der Betriebsvereinbarung „Überwachung & Aufzeichnung im Callcenter“ relevant, um zu zeigen: Mitbestimmung eingehalten, Privacy by Design. – Risikoregister & Maßnahmen: Falls man intern Risiko-Assessment machte – das Dokument mit identifizierten Risiken (viele in Sec.12) und dem Status der Gegenmaßnahmen. Zeigt proaktives Vorgehen. – Notfallkonzept & Übungen: Das Notfallkonzept-Dokument (mit Ersatzwege etc.) und Protokolle durchgeführter Notfallübungen (z. B. „Tischübung Stromausfall am 10.10.: Telefonie Fallback hat geklappt, Learnings X“). – Zugriffsberechtigungen-Liste: Auditor will oft sehen, wer alles Admin ist. Hier Liste der Personen mit Telefonie-Adminrechten, plus Nachweis MFA aktiv etc., und z. B. Freigabeschreiben vom Management, dass diese Personen ernannt wurden – so ist kontrolliert, dass nicht jeder Admin sein kann. – Penetrationstest-Report (falls gemacht): Z. B. externer Pentest SBC/VoIP, mit Zusammenfassung „keine kritischen Lücken offen“, oder falls doch, Maßnahmen ergriffen – das entkräftet Sicherheitsbedenken. – Compliance-Berichte: Im regulierten Umfeld (z. B. Finanzen) interne Compliance Kontrollberichte: z. B. „Wir haben stichproben Telefonaufnahmen geprüft und Richtlinien werden eingehalten.“ – falls vorhanden, Auditor gerne. – Logging & Audit-Logs: Der Auditor könnte fordern, einen bestimmten Vorgang nachzuweisen: z. B. „Zeigen Sie, wer am 5. Mai die Anrufweiterleitung global geändert hat.“ Dann muss man ins Admin-Log (Unified Audit Log) ein Eintrag zeigen. Darauf vorbereiten (evtl. export). – Datenschutz-Folgenabschätzung (DPIA): Wenn z. B. Recording eingerichtet, sollte es ein DPIA-Dokument geben. Auditor DSB würde das sehen wollen. – Verträge & Zertifikate: z. B. Vertrag mit Carrier zeigt, dass Notruf geregelt. Oder ISO27001-Zertifikat vom Operator, falls relevant. – Backups & Resilienz Nachweis: z. B. Protokoll Config-Backup SBC vom letzten Monat. – Tickets / Incidents: Evtl. stichproben aus Ticket-System: z. B. Ticket „User konnte Notruf nicht wählen – Lösung in 1h“. Der Auditor sieht: Probleme werden erfasst und behoben. – Reporting an Management: Kopie einer Präsentation an Vorstand, wo Telephony KPIs und Risiken gemeldet – zeigt Governance-Reporting existiert.

Kurz: Ein Audit will sehen, dass Sie tun, was Sie sagen. Policies allein reichen nicht – es braucht Belege für Umsetzung und Kontrolle. Mit obigen Evidenzen kann man gut dokumentieren, dass die Telefonie unter Governance steht und alle Vorschriften sowie internen Regeln eingehalten werden.

14. Glossar

• Microsoft Teams Phone – Cloud-Telefonanlage innerhalb von Teams, ermöglicht PSTN-Anrufe. Früher „Phone System“ genannt. Enthält Funktionen wie Anrufsteuerung, Voicemail, Call Queues etc.
• Telefonie-Governance – Rahmenwerk von Richtlinien und Prozessen, um den Einsatz von Telefonie sicher, regelkonform und effizient zu gestalten (speziell im Kontext Teams). Unterthemen: Nummernplan, Berechtigungen, Notruf, Sicherheit, Kostensteuerung.
• PSTN (Public Switched Telephone Network) – Öffentliches Telefonnetz. „Ins PSTN telefonieren“ heißt heraustelefonieren ins normale Festnetz/Mobilfunk.
• Direct Routing – Anschluss von Teams ans PSTN über einen selbst verwalteten Session Border Controller und eigenen Telefon-Provider. Ermöglicht maximale Flexibilität (beliebiger Carrier, Integration von Legacy).
• Operator Connect – Von Microsoft angebotene Alternative, bei der ein zertifizierter Telefonie-Provider direkt mit Teams gekoppelt ist. Kein eigener SBC nötig; man „verbündet“ den Tenant mit dem Provider und verwaltet Nummern in Teams Admin Center.
• Operator Connect Mobile (Teams Phone Mobile) – Erweiterung von Operator Connect ins Mobilfunknetz. Der Mobilfunkanbieter verbindet die SIM-Mobilnummer mit Teams. Anwender haben eine Nummer, die parallel auf Mobiltelefon (GSM) und in Teams (Daten) erreichbar ist.
• SBC (Session Border Controller) – Netzwerkkomponente, die zwischen VoIP-Netzen sitzt (z. B. zwischen dem Firmen-Teams und dem Provider-SIP-Trunk). Sichert und steuert SIP-Signalisierung und Medien. Im Direct Routing essenziell: der eigene SBC stellt die Verbindung zum Telefonanbieter her.
• Entra ID – Neuer Name für Azure Active Directory (Azure AD). Microsofts Cloud-Verzeichnisdienst, der Identitäten und Zugriffe steuert. In unserem Kontext: Verwaltet Benutzerkonten, Lizenzen und Gruppen, auch Telefonie-Admins und Standorte.
• QoS (Quality of Service) – Mechanismen, um bestimmten Verkehr im Netzwerk zu priorisieren. Für Telefonie werden Sprachpakete priorisiert (DSCP 46), damit sie auch bei hoher Last mit geringer Verzögerung übertragen werden (wichtig für Echtzeit).
• MOS (Mean Opinion Score) – Kennzahl für Sprachqualität. 5 = hervorragend, 1 = schlecht. Wird aus technischen Messungen berechnet, simuliert das durchschnittliche menschliche Qualitätsurteil.
• Latenz – Zeitverzögerung bei der Übertragung (idR. in Millisekunden). Wichtig, dass Latenz gering ist für natürliche Gespräche.
• Jitter – Schwankungen der Paketlaufzeiten. Hoher Jitter führt zu Unebenheiten im Audiostrom, daher zu vermeiden via Puffer/QoS.
• Packet Loss (Paketverlust) – Anteil der verlorenen Datenpakete. Audio verträgt kaum Verlust, sonst Aussetzer.
• Toll Fraud – Gebührenbetrug im Telefonienetz. Angreifer nutzen offene Telefonanlagen oder gehackte Accounts, um teure Nummern anzurufen und Profit aus Gebühren zu ziehen. Großer Schaden möglich, deshalb Schutzmaßnahmen.
• CLIP/CLIR – „Calling Line Identification Presentation/Restriction“ – Nummernanzeige bzw. -unterdrückung beim Angerufenen. CLIP = Rufnummer wird übermittelt. CLIR = Nummer wird absichtlich nicht angezeigt (anonym).
• CLIP no screening – Funktion, die erlaubt, eine von der tatsächlichen Anschlussnummer abweichende Nummer zu signalisieren. Wird vom Provider gewährt (nach Prüfung). Erlaubt z. B. einer Cloud-TK-Anlage, die original Festnetznummer des Kunden auszusenden, obwohl VoIP-Call aus Cloud kommt.
• Dial Plan – Wählplan in Teams, der benutzerfreundliche Eingaben (z. B. „0891234“ oder „0049…“) in das kanonische +E.164-Format umwandelt. Enthält Muster und Transformationsregeln.
• E.164 – Internationales Rufnummernformat, beginnend mit „+“ und Länderkennzahl, dann Vorwahl, dann Teilnehmernummer (ohne führende 0). Beispiel: +49 711 123456. Dieses Format wird im Backend genutzt, damit Nummern weltweit eindeutig sind.
• Notruf-Policy – Interne Richtlinie, wie Notrufe gehandhabt werden (Erfassung Standortdaten, Testintervalle, Verantwortlichkeiten). Wichtig in Cloud-Telefonie, um gesetzlichen Pflichten zu genügen.
• Call Queue / Auto Attendant – Funktionen in Teams Phone: Anrufwarteschlange (z. B. Hotline mit mehreren Agents) und automatischer Telefonassistent (Sprachmenü „Drücken Sie 1 für…“). Wird in Contact Center-Kontext oder generell für Hauptnummern genutzt.
• Contact Center (CC) – Lösung für Kundenkommunikation, verteilt eingehende Anrufe/Chats auf Agents, oft mit Funktionen wie IVR, Skill-Routing, Aufzeichnung, Auswertungen. Lässt sich mit Teams integrieren via Bots oder Direkt-SIP.
• Compliance Recording – Aufzeichnung von Anrufen/Meetings aus Compliance-Gründen (z. B. gesetzliche Archivierung). Bei Teams meist durch zertifizierte Drittanbieter-Bots implementiert. Streng geregelt (Transparenz etc.).
• Betriebsrat (BR) – Arbeitnehmervertretung in DE (ähnlich Works Council). Hat Mitbestimmungsrechte, insb. bei Einführung von Techniken, die Leistung/Kontrolle erfassen können – sehr relevant bei Themen wie Recording oder Monitoring.
• Survivable Branch Appliance (SBA) – Eine spezielle Appliance/Software, die im Fall eines WAN-Ausfalls die grundlegende Telefonie an einem Standort aufrechterhält. Registriert Teams-Phones lokal und leitet PSTN über lokalen Trunk – quasi Mini-Ersatz-TK-Anlage für Notfälle.
• Operator Connect vs Calling Plan – Zwei verschiedene Wege, PSTN über Microsoft-Cloud bereitzustellen. Calling Plan = Microsoft ist Telko, einfache Lizenz, aber begrenzte Länder und oft teurer pro Minute. Operator Connect = externer Telko, direkte Integration, oft flexibler Tarife, aber benötigt Vertrag separat.
• Add-On Lizenzen (Phone System etc.) – Zusätzliche Lizenzen zu Haupt-M365, um Telefonie zu aktivieren. „Teams Phone Standard“ ist das Add-On für E3/E1, „Domestic Calling Plan“ weitere für Minutenpakete. Business Voice war Bundle für KMU bis 2022 (jetzt ersetzt).
• Least Privilege – Sicherheitsprinzip: Jeder User/Admin bekommt nur die minimal notwendigen Rechte. In Telefonie z. B. kein Global Admin wenn Teams-Comm-Admin reicht.

15. Anlagen / Vorlagen

(In diesem Abschnitt folgen praktische Vorlagen und Beispiele in Tabellenform, die bei der Umsetzung der Governance helfen.)

RACI-Matrix (Beispiel) – Rollen vs. Kernprozesse

Legende: R = Responsible (ausführend), A = Accountable (endverantwortlich), C = Consulted (konsultiert), I = Informed (zu informieren).
(Dieses Beispiel zeigt vereinfachte Ausschnitte – in der Praxis würde man alle relevanten Prozesse fein aufführen.)

Policy-Matrix – Übersicht der Richtlinien

(Beispielmatrix – in Wirklichkeit je nach Unternehmen mehr Spalten/Kategorien möglich. Wichtig ist: jede Policy hat Zweck, Scope, Verantwortlichen, Kontrollen und Reviewintervall definiert.)

Risiko-Register (Auszug) – Risiken, Bewertung, Maßnahmen

(Risiko-Matrix – Likelihood/Impact beispielhaft in 5er-Skala. Enthält bereits implementierte Controls und Audit-Status. Zeigt, dass Governance Risiken identifiziert und mitigiert.)

Nummernplan-Schema (Tabellen-Vorlage)

(Diese Vorlage dient als Dokumentation: Sie listet alle Nummernbereiche mit Format. Ausgefüllt wie im Beispiel in Sektion 6. In der Praxis kommt noch Spalte „Zugewiesen an/Verantwortlich“ hinzu.)

Checklisten (Auszüge)

Portierung-Checkliste (Beispiel): – [x] Anbieterliste vollständig: Alle zu portierenden Rufnummern inkl. Vorwahlen im Portierungsformular eingetragen. – [x] Adressabgleich: Kundenadresse stimmt mit bisherigem Provider-Register überein (sonst Portierung abgelehnt). – [x] Portierungsdatum bestätigt: Termin: // um : Uhr, schriftliche Bestätigung vom neuen und alten Provider vorliegend. – [x] Freeze kommuniziert: Ab 2 Tage vor Portierung keine TK-Änderungen (Ansagen, Umleitungen) mehr am Alt-System – relevantem IT-Personal mitgeteilt. – [x] Teams-Konfiguration vorbereitet: Alle Nummern im Tenant als „unassigned“ schon angelegt (für schnellen Assign nach Port). – [x] Testplan finalisiert: Wer ruft am Portierungstag welche Nummer testweise an (Liste der Tester + Szenarien). – [ ] Rufumleitung Fallback gesetzt? (Optional) Falls Portierung schiefgeht, alte Anlage leitet Anrufe weiter an Not-Handy – JA/NEIN, Nummer: ____. – [ ] Nach Portierung: – Prüfen: jede portierte Nummer eingehend erreichbar? – Ergebnis protokolliert. – Prüfen: ausgehend von jedem Standort funktioniert? (bes. Notruf nach Port). – Alte Anlage trunk deaktiviert (um Doppelsignalisierung zu vermeiden) – erledigt um : Uhr. – [ ] Abschluss: Providerwechsel Erfolgsbestätigung erhalten (von neuem Carrier Ticket abgeschlossen). Nutzer über Abschluss informiert (Mail versandt am ). – [ ] Nachbereitung: Altvertrag Kündigung versendet? (Ja, zum //__). Interne Dokumentation (Nummern->Carrier) aktualisiert.

Notruf-Test-Checkliste: – [x] Testanrufe interne Leitstelle: Interne Notrufnummer (z.B. 112 in Testmodus) wurde am Standort X vom Teams-Telefon gewählt – Notfalltelefon der Sicherheitszentrale klingelte – Zeit: s – OK. – [x] Leitstellen-Kontakt hergestellt: Lokale Leitstelle München vorab kontaktiert (Hr. Y, Tel. …), Testfenster 10:00-10:15 vereinbart. – [x] Test 112 real: Um 10:05 von Apparat +4989zzzz9001 (User Hans M.) 112 gewählt – Verbindung zur Leitstelle, Adressinfo durchgegeben von System? Leitstellenbeamter bestätigt: „Wir sehen Adresse ABC-Straße 5“ – OK. Gesprächsdauer 1min. – [x] Test 112 mobil (nomadisch): Mitarbeiterin im Homeoffice hat 112 via Teams versucht – Regel: Weiterleitung zum nat. Handy-Dialer – sie hat dann Mobil-112 gewählt, kam bei Orts-Leitstelle an – OK (mit Hinweis Verbesserung: Teams zeigte keine Adresse). – [ ] Ergebnis-Bewertung: Alle Tests erfolgreich. Verbesserungspotential: Homeoffice-Lösung – nächster Schritt: Nutzer auffordern, Teams-Location manuell zu pflegen. – [x] Dokumentation/Report an Arbeitssicherheit: am .. Bericht mit Screenshots aus Teams Emergency-Tab generiert, an HSE-Manager geschickt. – Nächster geplanter Test: in 6 Monaten (Nov __).

Go-Live-Checkliste (Neu-Deployment): – [x] Benutzer importiert und lizenziert (alle im AD markierten Telefonie-Nutzer haben Phone System Lizenz erhalten). – [x] Rufnummern zugewiesen – 100% der Mitarbeiter haben korrekte Durchwahl laut Plan. – [x] Telefone/Headsets ausgeteilt – alle Nutzer haben Endgerät und Info erhalten, wie anschließen. – [x] Schulung/Handout verteilt – am Tag X 09:00 Kickoff-Meeting und PDF-Anleitung per Mail erledigt. – [x] Parallelbetrieb alt+neu eingerichtet – (Kopplung aktiv, Test interne Telefone alt->Team ok). – [x] Wichtigste Funktionen getestet: – Interner Anruf Kollege->Kollege (Team-zu-Team) – ok – Extern anrufen (Team->Handy) – ok – Extern angerufen werden – ok – Gruppenruf (Sekretariat) – ok – Voicemail hinterlassen und E-Mail erhalten – ok – [ ] Notfallprozedere bekannt – Alle Empfangsmitarbeiter haben Hinweis „bei IT-Ausfall Handy nutzen“. – [x] Support bereit – Hotline intern verlängerte Zeiten eingerichtet, Support-Mitarbeiter vor Ort in Lobby angekündigt. – [x] Altsystem fallback – alte Anlage läuft parallel, kein direkter Abbau durchgeführt. – [ ] Management-Abnahme – IT-Leiter Frau X hat Probetelefonat mit CEO geführt über Teams – Qualität für gut befunden, Abnahme erteilt (mündlich 10:30 am Launch).

Gerätestandard-Checkliste: – [x] Headset-Modell definiert: Jabra Evolve2 40 als Standard festgelegt (on-ear, USB). Beschaffungskanäle eingerichtet. – [x] Kompatibilität getestet: Headset X mit Teams an 3 verschiedenen PCs ausprobiert (Lautstärke-Tasten, Annehmen-Taste funktioniert) – ok. – [x] Firmware-Update-Funktion: Teams Admin kann Firmware pushen (geprüft mit Test-Device). – [x] Anzahl Ersatzgeräte im Lager: 10% Reserve Headsets (20 Stück) vorhanden und im CMDB erfasst. – [x] Telefonapparate für Bedarfspersonen: 5x Yealink T58A beschafft für Empfang, HR etc. – eingerichtet und login getestet – ok. – [ ] Räume ausgestattet: Kleine Räume – 3x Logitech Meetup installiert, Team Room Accounts konfiguriert – Testanruf ok. Große Konf-Räume – Poly Studio X50 + TC8 – noch in Lieferung (bis Datum __). – [x] Nutzertraining Geräte: Video-Tutorial „Wie telefoniere ich mit Headset vs. Tischtelefon“ an alle verteilt – Feedback positiv. – [x] Policy für Ersatz/Austausch: Defektgeräte werden innerhalb 24h getauscht (Lager vorhanden) – Verantwortlicher IT-Service Y. – [x] Zulassung privater Geräte? – Ja, aber ohne Support (Policy kommuniziert: „Nur freigegebene Modelle supportet“). – [x] Busylight Option geprüft: (Nicht erforderlich, da Headsets rote LED haben) – erledigt.

(Die Checklisten kann man je nach Unternehmen modifizieren. Hier exemplarisch einige Inhalte, die man abhaken würde.)

KPI/SLAs-Tabelle (Beispielmetriken)

(Diese Tabelle fasst Kennzahlen, deren Ziel und Messung übersichtlich zusammen. Sie dient dem Service Management zur Steuerung. Im Reporting zeigt man Ist vs. Soll. Die Frequenz sagt, wann man den Wert reportet. Diese KPIs sind beispielhaft, je nach Unternehmen variiert Fokus.)

Runbooks (Gliederung für Vorlagen)

Runbook: Telefonie-Vollausfall (P1-Incident)
1. Erkennung: Monitoring-Alarm „SBC unreachable“ oder „Teams PSTN error“ eingeht – NOC bestätigt Ausfall (z.B. Testanruf selbst durchgeführt – kein Durchkommen).
2. Sofortmaßnahmen: – UC-Admin setzt im Teams Admin Center eine Ansage/Mail an alle: „Aktuell Telefonie-Störung, bitte Mobiltelefon verwenden für externe Anrufe.“ – Falls Ausfall auf SBC beschränkt: Schalte auf Backup-SBC (DNS FQDN failover oder Routing im Provider auf Sec-SBC). – Informiere Service Desk, damit sie vorbereitet sind auf Anfragen. 3. Ursachenanalyse parallel: – Prüfe Netzwerkverbindung im RZ (Netzteam checkt Firewall/Verbindung). – Prüfe Microsoft 365 Service Health für Ausfallmeldung. – Rufe ggf. Provider-Hotline (Ticket beim Carrier). – Analyse SBC-Logs (letzte Meldungen vor Absturz). 4. Eskalation: – Nach 15 Min ohne Besserung: Informiere IT-Leitung + ggf. Krisenteam. – Entscheide über Notfall-Kommunikation an gesamte Belegschaft (E-Mail vom CIO). – Bei kritischer Dauer >1h: aktiviere Notfallumleitung für Hauptnummern auf externe Handys (via Carrier Portal). 5. Behebung: – Führe Neustart SBC durch, oder apply Workaround wie Umstellung auf Calling Plan (z.B. Notfall-Lizenzen aktivieren für Vorstand). – Überwache, ob Service sich stabilisiert (Testanrufe). – Halte Contact mit Microsoft Support falls Cloud-Issue (Case eröffnen). 6. Nach Entstörung: – Sende Entwarnung an Nutzer („Telefonie steht wieder zur Verfügung seit … Uhr. Ursache: …“). – Halte Nachbesprechung im Incident-Team. – Erstelle Incident Report (Ursache, Dauer, betroffene Nutzer, Maßnahmen zur Verhinderung in Zukunft). – Falls SLA verletzt, bereite Infos für evtl. Service Credit mit Provider vor. – Aktualisiere Notfall-Runbook falls nötig (wenn neu Erkenntnisse). 7. Wiederherstellungsmaßnahmen: – Falls Daten verloren (Voicemails in Ausfall?), rekonstruieren falls möglich. – Check, ob alle Systeme (SBC 1 und 2) wieder im Normalbetrieb.

(Das ist textuell; in Praxis kann man stichpunktartig in Tabelle oder Flussdiagramm dokumentieren. Wichtige Elemente: Erkennen, Kommunizieren, Eskalieren, Lösen, Dokumentieren.)

Runbook: Fraud-Verdacht
1. Symptom: Ungewöhnlich hohe abgehende Anrufvolumina oder Alarm aus Monitoring „Ausgabenlimit überschritten“. 2. Aktion sofort: Betroffenen Benutzer-Account sofort sperren (Disable PSTN via Teams PowerShell oder Account deaktivieren). Oder falls unklarer User: ausgehende Telefonie global blockieren (z. B. im SBC Outgoing halt) – je nach Ausmaß. 3. Ermittlung: Prüfe Anruf-Logs (welche Nummern wurden gewählt? Häufig Premium oder Ausland?). Identifiziere Quelle: Ein bestimmter User, oder ein Bot/kompromittierter App? 4. Carrier Info: Rufe Provider an, melde Verdacht auf Fraud, bitte um Sperrung der verdächtigen Zielrufnummern von deren Seite und notiere etwaige bereits angefallene Gebühren. 5. Benachrichtigung: Informiere IT-Security und ggf. CISO. Wenn es ein gezielter Angriff war, starten Security Incident Prozess parallel. 6. Behebung: – Ändere Passwörter/MFA des betroffenen Accounts (falls gehackt). – Schließe etwaige Sicherheitslücke (z. B. öffentliche IP des SBC war offen – jetzt Zugriffsfilter setzen). – Entferne im Teams Tenant eventuelle bösartige Apps oder Zugänge. 7. Resumption: Sobald sicher, dass kein weiterer Missbrauch läuft, hebe globalen Call-Block wieder auf (aber halte Problemuser gesperrt bis geklärt). 8. Nacharbeit: – Dokumentiere alle betroffenen Anrufe (Liste mit Zeiten, Zielen, Dauer, Kosten). – Melde Vorfall an Management (und ggf. Behörden falls relevant, z. B. wenn extremer Betrug). – Richte ggf. neue Sperren ein, wenn es neue Muster waren. – Schärfe Monitoring-Schwellen nach falls nötig (z. B. kleineres Budget pro Tag). – Kommuniziere an Benutzer (ohne Schuldzuweisung, eher Awareness: Achtet auf Account-Sicherheit). 9. Lessons Learned: Update Fraud-Prevention-Policy falls Lücke entdeckt (z. B. analoger Faxport war Gateway, den hackte man – dann schützen). 10. Audit: Halte Berichte bereit falls Finanz prüft, ob Process eingehalten (z. B. CFO will sehen, dass wir nach X min reagiert haben – Ticketzeiten belegen es).

(Analog kann man Runbooks für „SBC Failover“, „Teams Service Degradation“, „Quality Issue Site-specific“ definieren – immer wer tut was in welcher Reihenfolge.)

Weitere Beiträge zum Thema SharePoint und Teams