Fallstudie: Einführung von Microsoft Teams-Telefonie bei der Harry Hase AG

Management Summary

Die Harry Hase AG (tatsächlicher Name auf Anfrage), ein Automobilzulieferer mit 4.000 Mitarbeiterinnen und Mitarbeitern (davon ca. 2.000 Büro-Arbeitsplätze), stand 2025 vor der Ablösung ihrer klassischen Telefonanlage durch Microsoft Teams-Telefonie. Als projektleitender Berater habe ich das Vorhaben von der ersten Vision bis zum Go-Live begleitet. Ausgangslage war eine verteilte On-Premises PBX-Landschaft mit Tischtelefonen, einer separaten Contact-Center-Lösung, DECT-Funktelefonen in der Produktion und gewachsenen Strukturen für Notrufe und Fax. Das Zielbild formulierten wir unter dem Motto „One Client – One Identity – One Dial Plan“: Jeder Informationsarbeiter sollte mit dem Teams-Client unter einheitlicher Identität und Rufnummer arbeiten, während für Produktionsumgebungen und Sonderfälle integrative Lösungen gefunden werden.

Wir wählten ein hybrides Vorgehensmodell mit gründlicher Planung, Pilotierung und gestaffelten Rollouts je Standort. Wesentliche Architekturentscheidungen betrafen die Anbindung ans PSTN (öffentliche Telefonnetz) mittels Direct Routing über einen eigenen Session Border Controller, das Rufnummernkonzept und hochverfügbare Notruf-Routing-Mechanismen. Drei zentrale Nutzen für die Harry Hase AG wurden erreicht:

• Technischer Nutzen: Vereinheitlichung der Kommunikationsplattform, Wegfall proprietärer PBX-Hardware, nahtlose Integration von Telefonie in die bestehende Microsoft 365-Umgebung und verbesserte Betriebsstabilität durch Cloud-Services.
• Organisatorischer Nutzen: Erhöhte Mobilität und Zusammenarbeit – Mitarbeiter können ortsunabhängig unter ihrer Büronummer arbeiten. Zudem vereinfachte Administration und einheitliche Governance durch zentrale Richtlinien.
• Wirtschaftlicher Nutzen: Reduktion von Doppelstrukturen und langfristige Kosteneinsparungen. Trotz zunächst höherer Lizenzkosten zeigte der 3-Jahres-TCO ein ausgeglichenes Bild, da Wartung und Betrieb der Altanlage wegfallen und Produktivitätsgewinne erzielt werden.

Zu den wichtigsten Risiken zählten wir die Sprachqualität (Netzwerkbelastung), Akzeptanz bei Anwendern und Notruffähigkeit. Diese wurden proaktiv mitigiert: Durch Netzwerk-Upgrades und QoS-Konfigurationen konnten wir die erforderliche Sprachqualität sicherstellen. Ein umfassendes Change Management und Schulungskonzept sorgte für hohe Endbenutzer-Akzeptanz bereits zum Produktivstart. Die Notruf-Konzeption wurde eng an gesetzliche Vorgaben angelehnt und mit Backup-Lösungen (z.B. analogen Notfalltelefonen) unterlegt.

Das Ergebnis zum Go-Live (November 2025): Der Produktivbetrieb wurde fristgerecht und ohne kritische Unterbrechungen aufgenommen. Die Akzeptanz war hoch – bereits in den ersten Wochen zeigte sich eine steigende Auslastung der neuen Telefonieplattform bei gleichzeitig geringem Supportaufkommen. Erste KPIs untermauern den Erfolg: z.B. eine durchschnittliche Anrufqualität (MOS) von >4 und kaum Fehlverbindungen. Wirtschaftlich bleibt die Einführung im geplanten Budgetrahmen; etwaige Mehrinvestitionen in Geräte und Netzwerk amortisieren sich voraussichtlich binnen 2,5 Jahren durch konsolidierte Betriebskosten und Effizienzgewinne.

1. Ausgangssituation und Vision

Unternehmens- und Standortstruktur: Die Harry Hase AG verfügt über einen Hauptsitz in Deutschland sowie mehrere Werke und Büros im In- und Ausland. In Summe sind es fünf größere Standorte in Deutschland (darunter der Hauptsitz und vier Produktionswerke) sowie Vertriebsniederlassungen in Europa, USA und Asien. Bereits vor Projektstart arbeiteten viele Informationsarbeiter mobil oder im Homeoffice – unterstützt durch Microsoft 365, das seit zwei Jahren im Einsatz ist. Somit war Remote-Arbeit etabliert, jedoch die Telefonie basierte noch auf klassischen Standorten: Jedes Werk hatte eine lokale TK-Anlage oder Nebenstellenanlage, verbunden über ein zentrales System.

Ist-Analyse der TK-Landschaft: Die vorhandene Telefonie-Infrastruktur bestand aus einer On-Premises PBX (klassische Telefonanlage) mit diversen angeschlossenen Systemen:

• TK-Anlage: Ein konventionelles, hardwarebasiertes Telefonsystem (ca. 10 Jahre im Betrieb, herstellergebunden). Es wurden Tischtelefone (VoIP-Systemtelefone) und teils Softphones am PC genutzt. Die Anlagen unterstützten Standardfunktionen wie Halten/Makeln, Weiterleiten, Voicemail und Besetztlampenfelder. Allerdings stieß die Kapazität an Grenzen und eine teure Upgrade- oder Erweiterungsinvestition wäre mittelfristig nötig gewesen.
• Sprachanschlüsse (Trunks): Die Anbindung ans öffentliche Telefonnetz (PSTN) erfolgte an jedem größeren Standort über SIP-Trunks eines Carriers. Historisch gab es noch einige Primärmultiplexanschlüsse (ISDN PMX) in kleineren Standorten, die jedoch im Rahmen der ISDN-Abkündigung bereits auf VoIP umgestellt wurden. Die Rufnummern waren standortbezogen, d.h. jeder Standort hatte einen eigenen Nummernblock mit entsprechender Ortsvorwahl.
• Rufnummernkonzept: Intern existierten Durchwahlen mit 3- bis 4-stelligen internen Nummern. Extern waren diese Durchwahlnummern Teil der Durchwahlblöcke der jeweiligen Standort-Vorwahl. Ein unternehmensweit einheitlicher Wählplan fehlte – für interne Telefonate zwischen Standorten wurden oft direkte Amtsnummern gewählt oder teure Vernetzung realisiert. Notrufe (112/110) wurden von der PBX jeweils über lokale Amtsleitungen an die zuständige Notruf-Leitstelle geleitet, wodurch der Abgleich der Anschrift durch die Leitstelle gewährleistet war.
• Notruf und Aufzeichnung: Für Notrufe gab es an den Produktionsstandorten feste Notfalltelefone (z.B. in Aufzügen, Werkschutzbüros), teils analog angebunden an die TK-Anlage. Eine automatische Standortübermittlung war in der Altanlage nur rudimentär gelöst (fixe Standortkennung pro Amtsleitung). Gesprächsaufzeichnung wurde nur im geringen Umfang betrieben – in der separaten Contact-Center-Lösung für Kundensupportgespräche. Es gab keine allgemeine Mitschnittfunktion in der PBX für normale Telefone.
• Contact-Center-Insellösung: Der Kundenservice sowie die interne IT-Hotline nutzten ein getrenntes Callcenter-System (eine Softwarelösung eines Drittherstellers), welches zwar an das Telefonnetz angebunden war, aber isoliert von der Haupt-PBX arbeitete. Anrufe an Support-Hotlines liefen direkt über spezielle Amtsleitungen in dieses System. Eine Integration mit Microsoft Teams oder der Haupt-TK-Anlage bestand nicht. Agents arbeiteten dort noch mit einem separaten Softphone.
• DECT in Werksbereichen: In den Produktions- und Lagerhallen war eine DECT-Funktelefonie im Einsatz, um die Erreichbarkeit von Mitarbeitenden auf dem Werksgelände sicherzustellen. Diese DECT-Basisstationen waren an die lokale TK-Anlage angebunden. Insbesondere im Werkschutz und in der Instandhaltung waren DECT-Handsets essentiell (teils auch wegen Ortung auf dem Gelände im Notfall).
• Fax: Faxkommunikation war noch vorhanden für bestimmte Geschäftsbereiche (z.B. Bestellungen, Lieferavis). Hierfür gab es sowohl traditionelle Faxgeräte (über Analogadapter an der PBX) als auch einen zentralen Faxserver, der Faxe in E-Mails umwandelte.

Reifegrad Microsoft 365: Ungeachtet dieser klassischen Telefonie nutzte die Belegschaft bereits intensiv Microsoft 365: Outlook/Exchange Online für E-Mail, SharePoint/OneDrive, und vor allem Microsoft Teams für Chat und interne Meetings. Identitäten waren in Azure AD (heute Entra ID) synchronisiert, und Basis-Sicherheitsfunktionen wie Multi-Faktor-Authentifizierung und Conditional Access Richtlinien waren implementiert. Netzwerktechnisch hatte man für die Einführung von Teams (Meetings) die Internetanbindung an den Standorten erweitert und eine direkte Internet-Cloud-Anbindung (ohne VPN-Tromboning für Teams-Traffic) eingerichtet. Die Security- und Compliance-Grundlagen in Microsoft 365 waren gelegt: Ein Berechtigungskonzept, DLP-Richtlinien und ein Verarbeitungsverzeichnis für Cloud-Dienste existierten. Kurz: Die Kollaborationsplattform war etabliert, nur die Telefonie war noch separat.

Vision: In Gesprächen mit IT-Leitung und Fachbereichen entwickelte ich die Vision „One Client – One Identity – One Dial Plan“. Diese bedeutet:

• One Client: Statt verschiedener Endgeräte und Softphones soll ein Mitarbeiter für alle Kommunikationsbedürfnisse primär Microsoft Teams nutzen – als zentrales Tool für Chat, Meetings und Telefonie. Das Tischtelefon könnte für viele entbehrlich werden. Wo physische Telefone nötig bleiben (z.B. Konferenzräume, Empfang), sollten Teams-kompatible Geräte eingesetzt werden.
• One Identity: Jeder Mitarbeitende nutzt die vorhandene Microsoft 365 Identität (Entra ID Account) für die Telefonie-Anmeldung. Kein separater Telefon-Login oder proprietäre Accounts mehr. Die Telefonnummer wird der Person in Azure AD/Teams zugewiesen, sodass die Durchwahl fest mit dem Benutzerkonto* verknüpft ist – unabhängig vom Standort und Endgerät. Das erleichtert auch Prozesses wie Onboarding/Offboarding: neue Mitarbeitende bekommen automatisiert ihre Nummer zugewiesen, Berechtigungen anhand der Azure AD Gruppen etc.
• One Dial Plan: Das Unternehmen strebt einen einheitlichen Rufnummernplan an. Langfristig sollen interne Anrufe komplett über Teams laufen, ohne separate Standort-Vorwahlen. Die Vision war, dass ein vierstelliger interner Kurzruf (z.B. 1234) von überall im Unternehmen denselben Kollegen erreicht – egal ob man in Dortmund oder in einem Werk in München sitzt, und egal ob man auf dem Handy mit Teams oder am PC ist. Extern sollte weiterhin jeder seine geografische Rufnummer (Ortsvorwahl mit Durchwahl) präsentieren, um für Kunden erkennbar zu bleiben. Im Kern aber soll Teams Phone System die unternehmensweite Vermittlungsstelle* werden, welche alle Standorte und Benutzer verbindet.

Besondere Anforderungen gab es in Produktionsumgebungen, auf dem Shopfloor, im Lager und beim Werkschutz. Hier war uns klar, dass nicht alle bisherigen Lösungen 1:1 durch Teams ersetzt werden können: – In lauten Produktionshallen oder wo Handschuhe getragen werden, sind Headsets oder Smartphones nicht immer praktikabel. Die robusten DECT-Handsets hatten Alarmfunktionen (Totmannschaltung etc.) und waren in die Arbeitssicherheit integriert. Unsere Vision sah daher vor, diese Produktions-Telefonie nicht einfach abzuschalten, sondern zu integrieren. Beispielsweise DECT weiter zu nutzen, aber die DECT-Anlage an das neue System anzubinden, sodass zumindest die Rufnummern identisch bleiben und interne Kommunikation möglich ist. – Im Werkschutz und für Notfallszenarien (z.B. Evakuierungen) mussten Telefone ohne Cloud-Abhängigkeit verfügbar sein. Hier erwogen wir, an strategischen Punkten Notfalltelefone (mit direktem Amtsanschluss) zu belassen oder Mobiltelefone als Backup zu etablieren, falls Teams bei Netzausfall nicht funktioniert. – Für den Shopfloor (Fertigungssteuerer, Schichtleiter) war die Vision, perspektivisch mobile Endgeräte mit Teams-App zu nutzen, sofern WLAN-Abdeckung oder 5G in den Hallen ausreicht. In der Realität würde dies schrittweise erfolgen – zunächst blieben bestehende Anlagen parallel bestehen, während wir die Infrastruktur verbessern.

Zusammengefasst war die Vision ambitioniert: Eine vereinheitlichte Kommunikationslandschaft mit Microsoft Teams als Herzstück, die trotzdem spezielle Anforderungen der Produktion berücksichtigt. Diese Vision wurde vom Vorstand und der IT geleitet, aber auch mit den Fachbereichen und dem Betriebsrat abgestimmt, sodass alle das grobe Zielbild teilten, bevor wir in die Planung gingen.

2. Business Case und Entscheidungsrahmen

Um die Entscheidung für Microsoft Teams-Telefonie fundiert zu treffen, haben wir einen umfassenden Business Case erarbeitet. Darin wurden verschiedene Lösungsvarianten untersucht, eine Kosten-Nutzen-Analyse über 3 Jahre gerechnet (TCO-Betrachtung) und qualitative Mehrwerte bewertet. Zudem flossen Rahmenbedingungen wie Datenschutz, Betrieb und vorhandene Verträge in den Entscheidungsprozess ein.

Varianten der PSTN-Anbindung: Make-or-Buy

Ein zentrales Entscheidungskriterium war, wie Microsoft Teams mit dem öffentlichen Telefonnetz (PSTN) verbunden wird. Grundsätzlich standen drei Optionen – bzw. Mischformen daraus – zur Diskussion:

1. Microsoft Calling Plans (Anrufpläne): Dabei bezieht das Unternehmen seine Telefonnummern und Sprachminuten direkt von Microsoft als Provider. Jeder Benutzer erhält von Microsoft ein Rufnummernkontingent und ein monatliches Minutenpaket. Diese Variante ist am stärksten „Buy“: Minimale eigene Infrastruktur, alles läuft cloudbasiert über Microsoft. Vorteile: sehr schnelle Inbetriebnahme (kein SBC nötig), Microsoft kümmert sich um Carrier-Themen. Nachteile: In Deutschland sind Calling Plans erst seit einiger Zeit verfügbar und vergleichsweise teuer pro Nutzer, insbesondere bei 2.000 Usern. Außerdem gab es funktionale Einschränkungen – spezielle Anforderungen (z.B. DECT-Integration, Sonderrufnummern) lassen sich damit kaum abbilden. Fazit: Calling Plans schieden für die Harry Hase AG aus, da Flexibilität und Kosten bei dieser Unternehmensgröße ungünstig waren.
2. Operator Connect: Hier übernimmt ein zertifizierter Telefonie-Provider (Operator) die Anbindung von Teams ans PSTN. Technisch wird die Verbindung über Microsofts Operator-Connect-Plattform hergestellt. Der Operator stellt Rufnummern bereit oder portiert bestehende, und verwaltet die SIP-Trunks in die Cloud. Für uns war Operator Connect ein attraktiver Mittelweg: Weniger eigene Verantwortung für Infrastruktur als bei Direct Routing, aber trotzdem ein professioneller Telco in der Schleife, der z.B. deutsche Notrufe gut handhaben kann. In Frage kamen große Anbieter, darunter sogar unser bestehender Carrier, der Operator Connect anbot. Vorteile: Weniger Betriebsaufwand (keine eigenen SBC-Server pflegen), Skalierbarkeit, Telco-SLA für PSTN. Nachteile: Einschränkungen bei Sonderlösungen – z.B. konnte der Operator Connect Service keine lokale DECT-Anlage ansteuern oder Faxgeräte integrieren. Zudem hätten wir für bestimmte Integrationen (Türsprechanlage, Alarmserver) doch wieder einen SBC gebraucht. Auch preislich hätten wir uns an die Tarifmodelle des Operators binden müssen, die pro Benutzer teilweise an Calling Plan heranreichen.
3. Direct Routing: Hier betreibt die Harry Hase AG einen eigenen Session Border Controller (SBC), der Microsoft Teams mit einem oder mehreren SIP-Trunks von gewählten Telefonieanbietern verbindet. Das ist die klassischste „Make“-Variante – man behält große Kontrolle. Wir könnten unseren bestehenden Telefonie-Carrier und dessen Tarife weiterhin nutzen und gleichzeitig den SBC nutzen, um zusätzliche Systeme anzubinden (z.B. die alte PBX parallel, Faxserver, Contact-Center). Nachteile: Verantwortung für den SBC liegt bei uns – das heißt Engineering, hochverfügbaren Betrieb, Updates, Security für diese Komponente selbst stemmen oder an einen Partner geben. Es entstehen initiale Investitionskosten (CAPEX) für SBC-Hardware oder -Software und laufende Betriebskosten.

Nach Bewertung der Optionen entschieden wir uns für eine Direct Routing-Lösung als Hauptszenario, kombiniert mit punktuellen Hybrid-Ansätzen: – Der bestehende SIP-Provider sollte behalten werden (aus vertraglichen Gründen und aufgrund guter Tarife). Dies sprach gegen Calling Plans. – Operator Connect wurde zwar geprüft, aber letztlich verworfen, da wir ohnehin für DECT, Fax & Co. einen SBC gebraucht hätten. Es erschien ineffizient, sowohl Operator Connect als auch einen eigenen SBC zu betreiben. Stattdessen fokussierten wir uns darauf, Direct Routing so zu gestalten, dass es ähnlich zuverlässig wie ein Operator Service funktioniert. – Allerdings schlossen wir nicht aus, künftig Hybridmodelle zu nutzen: z.B. für Auslandsstandorte mit wenigen Usern eventuell lokale Operator-Connect-Anbieter zu nutzen, während in Deutschland Direct Routing das Mittel der Wahl ist. Im Kernprojekt lag der Fokus jedoch auf der deutschen Telefonielösung für alle 2.000 Info-Worker, plus Integration der Spezialfälle.

Kostenmodell: 3-Jahres-TCO und Sensitivitätsanalyse

Ein entscheidender Teil des Business Case war die Kostenbetrachtung. Die Frage lautete: Was kostet uns die Microsoft-Teams-Telefonie über 3 Jahre im Vergleich zum Status quo, und wie variabel sind diese Kosten (Sensitivität gegenüber Änderungen wie Nutzeranzahl oder Tarif)?

Wir haben sämtliche Kostenarten aufgelistet, die relevant sind, und zwischen einmaligen Investitionen (CAPEX) und laufenden Betriebskosten (OPEX) unterschieden. Die Tabelle unten zeigt einen TCO-Vergleich zwischen der alten TK-Anlage (Ist) und dem angestrebten Teams-System (Ziel) über einen 3-Jahres-Zeitraum:

(Hinweis: Alle Beträge gerundet und anonymisiert; Tausenderpunkt und Dezimalkomma gemäß deutscher Schreibweise.)

Die TCO-Rechnung zeigt, dass im Drei-Jahres-Summenvergleich die Kosten nahezu pari sind: Einsparungen bei Wartung, Betrieb und Trunkkosten kompensieren die neuen Lizenz- und Investitionskosten weitgehend. Initial sind höhere Einmalkosten zu stemmen (SBC, Endgeräte, Projekt), die aber in der Betrachtung berücksichtigt sind. Kritisch war für den Finanzbereich, dass keine versteckten Folgekosten übersehen werden – daher flossen Puffer für z.B. Lizenzpreissteigerungen und erhöhte Cloud-Bandbreiten in die Kalkulation ein.

Für die Sensitivitätsanalyse haben wir Schlüsselvariablen variiert: – Nutzerzahl: Falls zukünftig deutlich mehr oder weniger als 2.000 Mitarbeiter Telefonie benötigen, skaliert das Modell linear über die Lizenzen. Ein Rückgang um 10% Nutzer würde ~10% Lizenzkosten sparen, umgekehrt ein Wachstum entsprechend mehr kosten. Da M365-Lizenzen flexibel buchbar sind, gibt es hier keine Überprovisionierung – was genutzt wird, wird bezahlt. – Lizenzstaffel: Wir betrachteten ein Szenario, in dem statt E3 mit Add-On auf E5-Lizenzen umgestellt würde. Ergebnis: E5 würde ca. 8 € pro Nutzer/Monat mehrkosten, was für 2.000 Nutzer ~192.000 € p.a. zusätzlich bedeuten würde. Dies lohnte sich nicht alleine für die Telefonie, da E5 Zusatznutzen (Power BI, erweiterte Security) hier nicht bewertet wurden. – SBC/Carrier: Was, wenn wir doch Operator Connect gewählt hätten? Hier hätten die SBC-Kosten (80k €) entfallen, dafür kämen höhere laufende Carrier-Kosten (Operator-Fees ca. 1-2 € pro Nutzer/Monat = ~50k € p.a.) hinzu. Über 3 Jahre wäre das sogar teurer gewesen. Auch wurde durchgerechnet, dass bei einem Carrier-Wechsel (z.B. komplett zu Operator Connect oder Cloud-Anrufplan) etwaige Vertragsstrafen oder parallele Laufzeiten angefallen wären. – Betriebskosten Cloud vs. On-Prem: Interessanterweise zeigte die Analyse, dass rein monetär keine dramatische Kostensenkung durch Cloud-Telefonie eintritt. Die Qualitativen Nutzen (siehe unten) waren mitentscheidend. Der Vorstand sollte also nicht allein aus Kostengründen entscheiden, sondern mit Blick auf Zukunftsfähigkeit und strategische Vorteile.

Der Finanzbereich und CIO akzeptierten den Business Case, da er wirtschaftlich vertretbar war und klare Vorteile aufwies. Wichtig war, transparent zu machen, dass zwar manche Kostenstellen sich verschieben (etwa von CAPEX zu OPEX durch Lizenzen), insgesamt aber die Telefonieausgaben im Rahmen der bisherigen Budgets bleiben würden.

Qualitativer Nutzen und strategische Bewertung

Neben reinen Zahlen war die qualitative Bewertung entscheidend, um das Projekt zu rechtfertigen:

• Verbesserte Kollaboration: Mit Telefonie in Teams haben Mitarbeitende alle Kommunikationswege in einer App. Ein Anruf lässt sich nahtlos in eine Teams-Besprechung mit Bildschirmfreigabe umwandeln. Präsenzstatus (Verfügbar/Im Gespräch) wird einheitlich angezeigt. Dadurch werden Medienbrüche abgebaut – vorher nutzten Kollegen für Telefonkonferenzen teils separate Systeme oder das Tischtelefon am Ohr und parallel den PC. Jetzt läuft alles integriert. Gerade für Projektteams und standortübergreifende Zusammenarbeit ein großer Gewinn.
• Mobilität und Flexibilität: Mitarbeiter sind nicht mehr an den Schreibtischapparat gebunden. Jeder kann unter seiner Büronummer weltweit erreichbar sein, sofern Internet vorhanden ist. Im Homeoffice oder unterwegs nutzen viele das Smartphone mit Teams-App oder einen Laptop. Das erhöht die Erreichbarkeit und vereinfacht flexible Arbeitsmodelle. Auch Rufumleitungen auf Mobiltelefone etc. werden überflüssig, da Teams selbst mobil funktioniert.
• Standardisierung und Modernisierung: Durch die Ablösung diverser Insellösungen (PBX, separater Voicemail-Server, verschiedene Telefonanlagen an Standorten) hin zu einem cloudbasierten System erreichen wir technologische Standardisierung. Updates kommen regelmäßig von Microsoft, neue Features (z.B. gerade wurde Call Park in Teams eingeführt) stehen allen sofort zur Verfügung. Das Unternehmen erhält eine moderne Plattform, was auch im Sinne der IT-Strategie („Cloud First“) ist.
• Transparente Governance: Mit Teams-Telefonie können wir zentral Richtlinien steuern – wer darf international telefonieren, wer darf Aufzeichnungen machen, etc., alles definier- und nachvollziehbar in der Microsoft Admin-Konsole. Im Vergleich zur alten TK, wo manche Einstellungen pro Anlage unterschiedlich und historisch gewachsen waren, vereinheitlicht dies die Governance. Auditing und Reporting wird einfacher (wer hat wann telefoniert – natürlich im Rahmen datenschutzkonformer Regeln, siehe Abschnitt Governance).
• Skalierbarkeit: Bei Übernahmen, neuen Standorten oder auch bei Personalaufstockung ist das System schneller anpassbar. Einen neuen Benutzer anlegen und eine Nummer zuweisen dauert Minuten statt eine Telefonanlage physisch zu erweitern. Ebenso können Büroumzüge leichter bewerkstelligt werden, da Nummern an Personen gebunden sind, nicht an Ports im Telefonverteiler.
• Ausfallsicherheit und Business Continuity: Durch Cloud-Hosting verteilt sich das Risiko. Wenn an einem Standort das Netz ausfällt, können betroffene Mitarbeiter teils über Mobilfunk weiter mit Teams arbeiten. Größere Ausfälle (Microsoft-seitig) sind sehr selten und werden durch SLAs abgedeckt. Wir implementierten zudem Fallbacks für Notfälle (siehe Notruf-Konzept), um die Sicherheit zu erhöhen.
• Zukunftssicherheit: Klassische TK-Anlagen geraten technologisch ins Abseits (kein Hersteller-Support, fehlende Integration APIs etc.). Mit Teams erhalten wir kontinuierlich Weiterentwicklungen und Kompatibilität z.B. zu neuen Devices, zu Kommunikations-Trends (Integration von WhatsApp/Chatbot über Graph API etc. ist möglich). Auch für die jungen Nachwuchskräfte ist eine moderne Kommunikationslösung attraktiver als „Omas Tischtelefon“.

Diese qualitativen Aspekte untermauerten die Entscheidung. Die IT-Leitung wie auch Fachbereiche stimmten überein, dass Teams-Telefonie nicht nur eine technische Umstellung ist, sondern ein Enabler für weitere Digitalisierungsinitiativen: z.B. könnte man das Contact Center später auch in die Cloud bringen oder Analytics über Gesprächsdaten (Kundenanruf-Volumen etc.) einfacher gewinnen.

TCO- und Funktionsvergleich: Teams vs. klassische TK

Neben der Kosten-Tabelle erstellten wir einen Funktionsvergleich, um sicherzustellen, dass keine essentiellen Leistungsmerkmale verloren gehen. Dabei zeigte sich, dass Microsoft Teams viele klassische Telefonie-Funktionen abbildet, jedoch teils mit anderem Bedienkonzept. Die wichtigsten Punkte im Vergleich:

Legende: ✔️ = verfügbar/unterstützt, 🔸 = eingeschränkt/mit Workaround, ❌ = nicht verfügbar.

Der Funktionsvergleich zeigte, dass keine kritische Kernfunktion fehlt, aber einige Bereiche besonderer Beachtung bedürfen: – Besetztlampenfeld: Eine häufige Sorge bei Umstellung auf Teams ist, dass es keine physischen „Lämpchen“ mehr gibt, die anzeigen, ob Kollege X gerade telefoniert. In der Praxis kompensiert Teams das über den Präsenzstatus („Beschäftigt/in einem Anruf“ wird angezeigt) und durch die Möglichkeit, mehrere Teilnehmer in einem Team-Call zu sehen. Für Team-Assistenzen gibt es die Delegationsfunktion und geteilte Anrufgruppen. Wir adressierten das im Change Management, um Usern die neue Arbeitsweise zu erklären. – Contact Center: Da eine hochintegrierte Callcenter-Lösung in Teams noch nicht out-of-the-box enthalten ist, planten wir einen Parallelbetrieb der bewährten Lösung vorerst ein. Über Direct Routing kann man bestimmte Service-Rufnummern weiterhin dorthin leiten. Langfristig wird evaluiert, ob eine Teams-native Contact-Center-Lösung eines Microsoft-Partners eingeführt wird, aber das war außerhalb des Scopes dieses Projekts. – Fax: Hier war klar, dass Fax immer mehr zum Nischenbedarf wird. Wir entschieden uns, Fax nicht über Teams abzuwickeln, sondern den bestehenden Fax-Server weiter zu nutzen bzw. mittelfristig auf einen Cloud-Faxdienst umzustellen. Für den Übergang bleiben einige analoge Leitungen für Fax aktiv, was der SBC ebenfalls bedienen kann. – DECT/Ortung: Eine echte Herausforderung, da sicherheitsrelevant. Unsere Übergangslösung: Die bestehende DECT-Infrastruktur bleibt zunächst autonom im Betrieb (gekoppelt an die alte TK-Anlage in den Werken, die wir fürs erste nicht komplett abschalten). Über eine SIP-Kopplung zwischen SBC und lokaler TK-Anlage leiten wir jedoch Gespräche zwischen Teams und DECT-Basis weiter, sodass z.B. ein Instandhalter auf DECT vom Teams-Apparat eines Ingenieurs angerufen werden kann. Die Ortungsfunktionen (z.B. Notrufknopf auf DECT-Handsets) bleiben in alter Anlage. Parallel prüfen wir neue Lösungen wie Teams-kompatible schnurlose Geräte oder robustere Smartphones mit Push-to-Talk über Teams Walkie-Talkie-Funktion – aber das ist eher Zukunftsmusik.

In Summe untermauerte der Funktionsvergleich, dass Teams Phone System die klassische Telefonie weitgehend gleichwertig ersetzt und teils übertrifft (Analytics). Einige Sonderthemen wurden identifiziert, für die spezielle Lösungen im Projekt umgesetzt oder zumindest eingeplant wurden.

3. Governance, Compliance und rechtliche Rahmenbedingungen

Bei der Einführung von Cloud-Telefonie in einem deutschen Unternehmen sind Governance, Datenschutz und Compliance zentrale Themen. In meiner Rolle habe ich frühzeitig Juristen, Datenschutzbeauftragte und den Betriebsrat eingebunden, um klare Regelungen zu schaffen. Dieser Abschnitt beschreibt, wie wir regulatorische Anforderungen erfüllt und interne Richtlinien definiert haben.

Datenschutz und Auftragsverarbeitung: Die Nutzung von Microsoft Teams für Telefonie bedeutet, dass Anrufsignalisierung und ggf. Inhalte (Voicemails, Aufzeichnungen) über Microsoft-Server laufen. Wir prüften daher den bestehenden Auftragsverarbeitungsvertrag (AVV) mit Microsoft. Glücklicherweise deckte der bestehende Vertrag für Microsoft 365 auch die Telefoniemodule ab – Microsoft agiert als Auftragsverarbeiter gemäß DSGVO. Wichtig war uns, Datenflüsse transparent zu dokumentieren: z.B. dass Anrufprotokolle (wer wen wann angerufen hat, Dauer) in der Microsoft Cloud gespeichert werden. Sensible Inhalte wie Gesprächsmitschnitte würden nur dann anfallen, wenn Nutzer die manuelle Aufnahme nutzen. Hier vereinbarten wir restriktive Vorgaben (siehe Aufzeichnungsrichtlinie unten). Speicherorte: Microsoft betreibt die Teams-Dienste für EU-Tenants in europäischen Rechenzentren (Dublin, Amsterdam u.a.). Wir stellten klar, dass nach Microsoft-Angaben Sprachstreams und Daten innerhalb der EU verbleiben, soweit möglich. Lediglich der Support (im Fehlerfall) oder Telemetriedaten könnten global zugänglich sein, was im AVV geregelt ist. Diese Details hielt unser Datenschutzbeauftragter in einer DSGVO-Folgenabschätzung fest, die für neue Systeme vorgeschrieben war. Ergebnis: Mit den vorhandenen Verträgen und Einstellungsmöglichkeiten sah man keine unüberwindbaren Datenschutzrisiken. Microsoft Teams wurde bereits für Meetings genutzt, die Telefonie ist eine Erweiterung desselben Systems.

Notruf in Deutschland: Ein kritischer Compliance-Aspekt ist die Notruffähigkeit. In Deutschland verlangen Gesetze (z.B. die Notrufverordnung und Technische Richtlinie Notruf), dass jeder Telefonanschluss Notrufe an die zuständige Leitstelle ermöglichen muss und Standortinformationen verfügbar sind. Wir haben hierzu folgendes Konzept umgesetzt: – Standortzuordnung für feste Arbeitsplätze: Für jeden Firmenstandort wurde in Teams ein Notfallstandort (Emergency Address) hinterlegt (Adresse, Gebäude). Über die Netzwerk-Konfiguration von Teams (Network Topology) ordneten wir IP-Bereiche und WLAN-SSIDs diesen Standorten zu. Befindet sich ein Nutzer im Büro und ruft die 112 über Teams, übermittelt Microsoft an den Notruf die zugeordnete Firmenadresse. Das geschieht über unseren SIP-Provider, der diese Adresse als sogenanntes „Location Object“ hinterlegt hat. Wir haben dies im Test mit dem Provider validiert. – Nomadische Nutzer (Home Office/Mobile): Hier ist die Herausforderung, dass Teams den Standort nicht sicher erkennen kann. Für diese Fälle blendet Teams vor einem Notrufversuch einen Hinweis ein („Bitte geben Sie ggf. Ihren Standort an“). Wir haben intern kommuniziert, dass Mitarbeiter, die von zuhause aus einen Notruf mit Teams absetzen, unbedingt ihre Adresse nennen sollen, da der Anruf sonst zur Heimatleitstelle der Rufnummer gehen könnte. Außerdem haben wir es Benutzern ermöglicht, in Teams einen standortbasierten Notfall-Ort manuell zu pflegen (sofern Microsoft diese Funktion bereitstellt – in USA E911 üblich, in Europa optional). – Fallback bei WAN-/Cloud-Ausfall: Was passiert, wenn Teams oder die Internetanbindung ausfällt? Für solche Fälle sieht unsere Betriebsanweisung vor, dass Notrufe über alternative Mittel abgesetzt werden müssen: z.B. Mobiltelefon oder verbleibende analoge Notfallapparate. In Bereichen mit hohem Risiko (Werkschutz, Produktion) belassen wir an zentralen Stellen Notfalltelefone (rote Analogtelefone), die direkt ans PSTN gehen und auch stromunabhängig funktionieren. Zudem haben Werkschutz-Mitarbeiter Firmenhandys als Backup. So stellen wir sicher, dass ein Notruf jederzeit möglich ist, unabhängig von der Cloud. – Betriebsvorschriften: Wir erstellten eine Notrufrichtlinie, die im Unternehmen kommuniziert wird. Darin steht, wie Notrufe mit Teams funktionieren, was die Mitarbeiter beachten müssen (z.B. Standort nennen, falls mobil) und welche Geräte alternativ bereitstehen. Des Weiteren schulten wir die Empfangs- und Sicherheitsleitstellen, da diese intern bei Notfällen alarmiert werden: in der Teams-Lösung erhalten sie z.B. beim Absetzen eines Notrufs automatisch eine Benachrichtigung („User X hat 112 gewählt – Standort Y“), sofern technisch umsetzbar. Diese Funktion testeten wir mit einem Notruf-Test über den SIP-Provider und stellten sicher, dass interne Ersthelfer informiert werden können.

Richtlinien (Policies) in Teams: Um Governance durchzusetzen, haben wir diverse Teams-Richtlinien definiert: – Anrufrichtlinien: Wir setzten in Teams Phone System Einstellungen, wer welche Anrufe tätigen darf. Standardmäßig sind internationale Anrufe für die meisten Mitarbeiter gesperrt (außer Führungskräfte und benötigte Bereiche), um Kosten und Missbrauch zu kontrollieren. Anrufe zu Premium-/Mehrwertnummern (0900er etc.) wurden global unterbunden. Externe Rufumleitungen wurden zunächst deaktiviert, um Sicherheitsrisiken (Callback-Fraud) zu minimieren. Solche Dinge lassen sich über Teams Voice Routing und Dialplan steuern bzw. über Policies wie „Calling Policy“. – Aufzeichnungsrichtlinien: Hier galt: Standard ist keine Aufzeichnung. Wir haben per Richtlinie verhindert, dass Benutzer 1:1-Anrufe ohne Zustimmung aufzeichnen können. Microsoft bietet in Teams eine Einstellung „AllowCloudRecording“. Für Meetings ließen wir es zu (da z.B. für Projektbesprechungen gewünscht), aber für normale Telefonanrufe informierten wir, dass Aufzeichnung tabu ist, außer wo aus Compliance-Gründen erlaubt. Sollte ein Bereich (z.B. Trading-Floor in Finanzbranche, hier eher nicht relevant) Aufzeichnung brauchen, müsste das mit einer speziellen Compliance-Lösung und Betriebsratszustimmung geschehen. Für die Harry Hase AG war der generelle Tenor: Keine aktive Gesprächsaufzeichnung im Alltag. Die einzige Ausnahme: der Kundenservice, der aber seine separate Lösung hat, dort gelten eigene Vereinbarungen. – Aufbewahrung und Abrechnung: Telefoniedaten (Anrufprotokolle) werden in der Cloud typischerweise 90 Tage vorgehalten für Benutzer (Anrufliste im Client) und länger für Admins (CDRs). Wir haben uns entschieden, keine spezielle Löschrichtlinie zu erlassen, sondern die Microsoft-Standards zu nutzen. Gesprächsmetadaten sind nicht super sensitiv, doch aus Datenschutzsicht auch nicht unbegrenzt vorzuhalten. Sollte Microsoft diese länger speichern, vertrauen wir auf den AVV. Für Abrechnungszwecke (z.B. Kostenstellen bei sehr hohen Telefoniekosten) exportieren wir monatlich die Nutzung nach Bedarf – aber es gibt keine personenbezogene Leistungskontrolle. Das wurde mit dem Betriebsrat so festgehalten: Telefoniedaten dürfen nur für technische Qualitätssicherung, Störungsanalyse oder Abrechnung mit Providern verwendet werden, nicht zur Verhaltenskontrolle von Mitarbeitern. – Qualitäts- und Sicherheitsanforderungen: Technische Richtlinien wie zwingende Verschlüsselung aller Anrufe (TLS/SRTP) setzten wir ohnehin via Teams/SBC um – dies war eher eine technische Baseline als Policy. Für Benutzeraccounts gilt: MFA-Pflicht, starke Passwörter und Conditional Access, sodass ein Zugriff nur von vertrauenswürdigen Geräten oder mittels MFA erfolgt. So wollten wir z.B. verhindern, dass ein kompromittiertes Konto zum Telefonieren missbraucht wird. Weiterhin richteten wir Schwellenwerte ein (im Monitoring), etwa wenn ein Account plötzlich hunderte Auslandsgespräche tätigt, dass ein Alarm ausgelöst wird – das ist Teil der Betriebsthemen (Fraud Detection).

Mitbestimmung und Betriebsrat: Früh im Projekt haben wir den Betriebsrat eingebunden, um mögliche Bedenken auszuräumen. Hauptpunkte der Arbeitnehmervertretung waren: – Überwachung/Metriken: Es bestand die Sorge, dass mit dem neuen System die Überwachung der Mitarbeitenden zunimmt, da detaillierte Logs und Analytics verfügbar sind. Wir konnten darlegen, dass wir keine individualisierten Performance-Auswertungen vornehmen. Jegliche Auswertung auf Personenebene (z.B. „Wie viele Anrufe hat Mitarbeiter X getätigt?“) würde nur im Ausnahmefall und mit Mitbestimmung erfolgen (etwa bei Missbrauchsverdacht und dann auch unter Einbeziehung des BR). Stattdessen interessieren uns aggregierte Kennzahlen (Gesamtnutzung, Qualität) für Serviceverbesserungen. – Gesprächsmitschnitte: Der BR wollte sicherstellen, dass keine heimlichen Mitschnitte möglich sind. Wir zeigten die Teams-Funktion, bei der immer ein Hinweis ertönt und alle Teilnehmer informiert werden, falls ein Call aufgenommen wird. Zudem beschlossen wir, die Recording-Funktion in 1:1 Telefonaten standardmäßig technisch zu unterbinden. Der BR begrüßte diese Klarheit. – Arbeitszeit/Erreichbarkeit: Ein anderes Thema war, dass durch Mobilität eventuell die Grenze zwischen Arbeit und Freizeit verwischt („ständig erreichbar auf Handy mit Teams“). Hier haben wir im Projekt nur begrenzt Einfluss (das ist eher Thema Unternehmenskultur), aber wir haben klar kommuniziert: Es gibt keine Pflicht zur ständigen Verfügbarkeit. Einstellungen wie die Voicemail und Anrufweiterleitung kann jeder Nutzer so konfigurieren, dass außerhalb Arbeitszeit Ruhe ist. In Schulungen erwähnten wir die Nicht stören-Funktion und das Einrichten von Arbeitszeiten im Teams-Client. – Schutz persönlicher Daten: Beim Import der Telefonnummern ins Azure AD / Teams hatten wir darauf zu achten, dass z.B. private Handynummern der Mitarbeiter nicht plötzlich für alle sichtbar werden. Das war zum Glück nicht der Fall – wir vergaben dienstliche Rufnummern. Dennoch prüften wir, welche Telefonnummern in Teams angezeigt werden (Standard: nur die Dienstnummer, keine privaten). Außerdem legten wir fest, dass Auswertungen wie die Teams Analytics Reports nur einem kleinen administrativen Kreis zugänglich sind.

Wir hielten alle diese Vereinbarungen in einer Betriebsvereinbarung zur Einführung von Teams-Telefonie fest, die vom Betriebsrat und Arbeitgeber unterzeichnet wurde. Darin geregelt sind u.a. Zweck der Einführung, Umgang mit Gesprächsdaten, Zugriffsrechte auf die Systeme, Schulungszusagen und ein Passus, dass keine Kündigungen aufgrund der Einführung erfolgen (Ängste vor Personalabbau wurden nämlich angesprochen, da vielleicht weniger TK-Administratoren gebraucht würden – man versicherte, dass niemand entlassen, sondern umgeschult wird).

Compliance-Checkliste: Im Projekt erstellten wir eine Checkliste aller relevanten Compliance-Anforderungen und wie wir sie erfüllen. Ausschnitt dieser Checkliste: – ✅ Auftragsverarbeitung: Microsoft AV-Vertrag geprüft, aktuell, umfasst Telefonie. Dokumentation abgelegt. – ✅ Datenschutz-Folgenabschätzung: durchgeführt, keine unvertretbaren Risiken, Zustimmung Datenschutzbeauftragter liegt vor. – ✅ Notruf-Konzept: schriftlich erstellt und von Sicherheitsbeauftragtem freigegeben. Enthält Standorte, Adressen, Notfalltelefone, Testprotokolle. – ✅ Betriebsrat: Information und Konsultation erfolgt, Betriebsvereinbarung abgeschlossen. – ✅ Rufnummernübertragung & Verzeichnis: geklärt, dass nur dienstliche Nummern ausgestrahlt werden; interne Telefonbuchfunktion entspricht bisherigen Gepflogenheiten. – ✅ Security: MFA aktiv für alle, Conditional Access definiert, Admin-Zugriffe abgesichert. SBC-Härtung (Passwort, Zertifikate) geprüft. – ✅ Dokumentation: Richtlinien-Matrix, Notfallpläne, Benutzerrichtlinien final erstellt und im Intranet veröffentlicht. – ✅ Schulung/Unterweisung: Datenschutz und Compliance-Aspekte wurden in Benutzertrainings behandelt (z.B. Hinweis auf kein Recording, Verhalten bei Notruf).

Diese Checkliste half uns, im Go-Live-Review alle wichtigen Punkte abgehakt zu haben.

Richtlinienmatrix: Zum Abschluss der Governance-Phase haben wir eine Matrix aller Richtlinien erstellt, wer sie verantwortet und wo sie gelten. Ein Auszug der Richtlinienmatrix zeigt einige wichtige Policies:

Diese Matrix machte allen Stakeholdern klar, welche Regeln gelten. Gerade bei Ausnahmen definierten wir bewusst hohe Hürden – z.B. internationale Telefonie schalteten wir gezielt nur für definierte Gruppen frei, und nur auf expliziten Managementwunsch. So behält die IT Kontrolle und Transparenz, was vor allem in der Anfangsphase wichtig war, um Missbrauch oder Kostenexplosionen zu vermeiden.

Zusammenfassend haben wir in diesem Kapitel sichergestellt, dass die Teams-Telefonie rechtssicher, compliant und mitgetragen von allen Gremien eingeführt wird. Dieser Grundstein zahlte sich aus, da später im Betrieb kaum Diskussionen mehr zu diesen Themen aufkamen – alles war vorab geregelt.

4. Zielarchitektur Teams-Telefonie

Nach Klärung von Business Case und Strategie haben wir die Zielarchitektur entworfen. In diesem Abschnitt beschreibe ich, wie die künftige Teams-Telefonie technisch aufgebaut ist, welche Entscheidungen wir bei den Varianten trafen, das Rufnummernkonzept, die SBC-Architektur sowie Aspekte zu Netzwerk, Identität und Endgeräten. Die Zielarchitektur bildet das Fundament, auf dem wir die Migration und den Betrieb realisieren.

Variantenentscheidung: Direct Routing mit SBC

Wie bereits im Business Case begründet, entschieden wir uns für die Direct Routing-Variante. Das heißt, die Harry Hase AG betreibt eigene Session Border Controller (SBC), die Microsoft Teams Phone System mit dem Public Switched Telephone Network verbinden. Die Gründe für diese Entscheidung: – Kontrolle und Flexibilität: Mit eigenem SBC können wir verschiedene Verbindungen schalten – etwa gleichzeitig zum Haupt-Carrier für die Büros, zum Contact-Center-System oder eine Anbindung für DECT/Fax. Operator Connect oder Calling Plans hätten diese Flexibilität nicht geboten. – Bestehende Verträge nutzen: Wir hatten bereits günstige SIP-Trunk-Verträge. Durch Direct Routing konnten wir die bestehenden Rufnummern und Tarife weiterverwenden, was wirtschaftlich und organisatorisch einfacher war (keine Massenportierung aller Nummern zu neuem Provider notwendig, nur eine Umkonfiguration). – Lokale Infrastruktur: Da wir Produktionsstandorte mit speziellen Anforderungen haben, war ein On-Premises-Element (der SBC) vorteilhaft. Beispielsweise lässt sich darüber ein analoges Notfalltelefon anschließen, das bei Cloud-Ausfall noch funktioniert – indem der SBC es auf einen lokalen Amtszugang routet. Ohne SBC (rein Cloud) hätte man für solche lokalen Fallbacks separate Lösungen gebraucht. – Erfahrungen und Kompetenzen: Unser internes Team hatte bereits Kenntnisse in VoIP/SIP durch die alte Anlage. Die Lernkurve, einen SBC zu betreiben, schien uns geringer als völlig neue Providermodelle. Zudem konnten wir einen Dienstleister hinzuziehen für Betrieb, falls nötig.

Szenario-Mix: Trotz Fokus auf Direct Routing schlossen wir Hybridansätze nicht aus. Beispielsweise wurde erwogen, Operator Connect als Backup zu nutzen: d.h. falls unser SBC oder Trunk ausfällt, könnten ausgewählte kritische Benutzer auf Operator Connect (OC) umschalten. Microsoft ermöglicht, dass man parallel OC und DR im Tenant hat. Im finalen Design haben wir es aber so gelöst, dass wir zwei unterschiedliche SIP-Trunk-Provider (Primär und Sekundär) via zwei SBCs einsetzen, anstatt OC. Dennoch ist die Architektur zukunftsoffen: Sollte in ein paar Jahren Operator Connect marktlich attraktiver sein, kann die Harry Hase AG ohne grundlegende Architekturänderung dahin wechseln, indem der SBC dann nur noch Sonderaufgaben (Analog/DECT) macht und der Bulk der User über OC läuft. Solche Überlegungen haben wir zumindest angestellt, um nicht in eine Sackgasse zu laufen.

Rufnummernkonzept und Dial Plan

Ein zentrales Element der Zielarchitektur ist das Rufnummernkonzept. Hier galt es, Altlasten zu bereinigen und gleichzeitig Kontinuität nach außen zu wahren: – Beibehaltung externer Rufnummern: Die öffentlichen Durchwahlnummern (DDIs) für Kundenkontakte, Lieferanten etc. bleiben erhalten. Wir portieren also die Nummernblöcke der Standorte ins neue System (bzw. zum neuen SIP-Trunk). Ein Kunde, der bisher z.B. die Nummer +49 231 9999-500 des Vertriebs wählt, soll dieselbe Nummer auch zukünftig erreichen – nur dass diese dann bei Teams klingelt statt am PBX-Telefon. – Einheitlicher interner Wählplan: Intern führten wir einen vereinheitlichten Dial Plan ein. Wir entschieden uns für 4-stellige Durchwahlen unternehmensweit. Vorher gab es uneinheitlich 3- oder 4-stellige Nummern, die teils standortgleich waren (z.B. hatte jeder Standort eine Durchwahl -0 für Zentrale, was intern zu Konflikten führte). Im neuen Konzept bekam jede Person eine eindeutige 4-stellige Nummer. Da 2000 Info-Mitarbeiter plus einige Hundert weitere Teilnehmer (Konferenzräume, Contact-Center, etc.) abzubilden waren, reichte ein 4-stelliger Nummernplan (bis 9.999 Nummern) gut aus. Wir vergaben einen Block 1000–6999 für Mitarbeiter, 7000–7999 für Funktionsposten (Hotlines, Konferenzräume, etc.), 8000–8999 für Service-Nummern (z.B. Auto Attendant), 9000+ für spezielle Zwecke. Diese interne Nummer ist i.d.R. identisch mit der externen Durchwahl, aber nicht immer – an Standorten mit 3-stelligen alten Durchwahlen hängten wir z.B. eine Ziffer an. – Durchwahlen vs. Einzelrufnummern: Wir entschieden uns, weiterhin ein Durchwahlprinzip zu nutzen, d.h. pro Standort gibt es einen Stamm (Vorwahl + Basisnummer) und Durchwahlen. Der Hauptsitz behielt z.B. +49 231 9999-XXXX. Standorte mit eigener Vorwahl behielten diese, aber intern ordneten wir sie dem 4-stelligen Schema unter. Konkret hieß das: Der Mitarbeiter Müller in Werk B hatte bisher die externe +49 7123 555-123. Intern wählte man früher 123 nur innerhalb von Werk B, aber vom HQ musste man 07123-555-123 gehen. Nun kann jeder intern sein 4-stelliges Kürzel (z.B. 5123) erhalten, das unternehmensweit eindeutig ist. Herr Müller würde intern künftig als 5123 erreichbar sein und extern über die gleiche alte Nummer (weil 5123 auch als Durchwahl nach extern signalisiert wird, falls passend in den Block, oder wir setzen eine Übersetzungstabelle im SBC). – Service- und Sondernummern: Wir migrierten auch Service-Rufnummern ins neue System. Beispielsweise gab es eine allgemeine Zentrale (Empfang) pro Standort – z.B. -0 oder -100. Im neuen System realisierten wir pro Standort oder global eine Auto Attendant unter dieser Nummer (mehr dazu bei Auto Attendants). Zudem gibt es Sondernummern wie 0800-Hotlines oder 0180-Service. Diese liegen oft außerhalb unseres Nummernblocks (z.B. 0800er von extern). Solche behielten wir bei unserem Carrier und ließen sie via SBC auf die entsprechende Call Queue in Teams routen. – Notruf-Routing und Nummern: Wir legten fest, dass 112 und 110 als Notruf gewählt werden können, ohne Präfix. Teams in Deutschland erkennt 112/110 als Notruf automatisch. Wir ergänzten auch interne Kurzwahlen für Werkschutz (z.B. 7777 als interne Notfallnummer, die parallel einen Alarm auslöst). Solche internen Hilfsnummern wurden in Teams als Call Group oder Secondary Ringer auf Sicherheitspersonal abgebildet.

Eine Herausforderung war, den Übergang so zu gestalten, dass interne Erreichbarkeiten nicht leiden: – Während der Migration (siehe Migrationskapitel) existierten PBX und Teams parallel. Wir richteten daher in der PBX Umleitungen/Schaltungen ein, damit ein PBX-User den neuen Teams-User erreichen kann und umgekehrt. Z.B. durch Routing bestimmter Durchwahlbereiche über den SBC. – Letztlich strebten wir an, dass nach vollständiger Migration alle internen Anrufe in Teams verbleiben (keine externe Schleife mehr). Dazu mussten alle auf Teams sein und das gleiche Schema nutzen. Das haben wir erfolgreich umgesetzt.

SBC-Architektur und Hochverfügbarkeit

Der Session Border Controller (SBC) ist das Bindeglied zwischen unserer Teams-Cloud und dem PSTN bzw. lokalen Systemen. Wir haben der SBC-Architektur besondere Aufmerksamkeit geschenkt, da sie für Betriebssicherheit und Sprachqualität maßgeblich ist.

Auswahl des SBC: Wir evaluierten mehrere SBC-Anbieter (Audiocodes, Ribbon, TE-Systems usw.). Wichtig waren Zertifizierung für Microsoft Teams Direct Routing, gute Erfahrungen im Support und die Möglichkeit, redundant zu arbeiten. Wir entschieden uns für zwei virtuelle SBC-Instanzen (Software SBCs) des Herstellers Audiocodes, die wir in unserer bestehenden VMware-Serverumgebung am Hauptrechenzentrum und am Backup-Rechenzentrum betrieben. Damit konnten wir vorhandene Hardware-Ressourcen nutzen, mussten aber auf ausreichende Leistungsfähigkeit (v.a. Echtzeit-CPU, kein Oversubscription) achten.

Hochverfügbarkeit: Die beiden SBCs wurden in einem aktiven Cluster konfiguriert (High Availability). Das heißt, sie synchronisieren die Registrierungen und Leitungen, sodass beim Ausfall eines SBC der andere übernimmt. Außerdem sind beide gleichzeitig aktiv für Lastverteilung. Der SIP-Trunk unseres Carriers ist so konfiguriert, dass eingehende Anrufe auf beide SBC-IP-Adressen geschickt werden können. Ausgehend kann Teams mehrere FQDNs nutzen, die wir eingerichtet haben (sip1.harryhase.de, sip2.harryhase.de). So erreichen wir Redundanz auf System- und Netzwerkebene.

Session-Dimensionierung: Wir dimensionierten die SBCs auf 64 gleichzeitige Sessions (Sprachkanäle) pro SBC, also insgesamt ~128 gleichzeitig mögliche Gespräche mit dem PSTN. Aus der Nutzeranalyse wussten wir, dass im Peak etwa 10% der Info-Mitarbeiter gleichzeitig telefonieren, was bei 2.000 Usern ~200 Gespräche ergibt. Allerdings sind nicht alle diese 200 extern – interne Teams-zu-Teams Gespräche gehen nicht über den SBC. Wir schätzten ca. 50% extern, also 100 PSTN-Gespräche im Peak. Die 128 Kapazität ließ also Reserve und deckt auch Wachstum ab. Bei besonderen Veranstaltungen (Weihnachtsanrufe etc.) kann es mal spitzen, doch unser Carrier erlaubt auch kurzfristiges Burst-Paket (bis 150). Wir haben Logging am SBC aktiviert, um Auslastung zu beobachten. Bislang war die Auslastung max. ~60 gleichzeitige PSTN-Calls, also weit im grünen Bereich.

Media Bypass: Wir konfigurierten Media Bypass auf dem SBC. Das bedeutet, dass, wenn möglich, die Medienströme (Audio RTP) direkt zwischen Teams-Client und SBC laufen, ohne Umweg über Microsofts Transportrelays. Voraussetzung ist meist, dass der Client on-prem im Firmennetz ist und den SBC direkt erreichen kann. Unsere Firewall und SBC ließen dies zu (SBC steht im DMZ mit öffentlicher IP, Clients aus dem LAN gehen übers Internetgateway -> DMZ). Mit Media Bypass sparen wir Latenz und Bandbreite, da das Audio nicht erst nach Amsterdam zu Microsoft und zurück zum SBC geht, sondern lokal bleibt. In Tests hatten wir mit Bypass rund 15-20 ms geringere Latenz als ohne, was spürbar die Qualität verbessern kann. Für externe oder mobile Clients, die den SBC nicht direkt erreichen können, greift automatisch der normal Weg via Microsoft Edge (Transport Relay), was aber ok ist.

Sicherheit (TLS/SRTP): Die SBC-Verbindung zu Teams erfolgte ausschließlich verschlüsselt. Wir installierten ein öffentlich signiertes Zertifikat auf dem SBC (Anforderung: gültiger CA, CN = FQDN des SBC). Alle SIP-Signalisierung läuft über TLS 1.2 auf Port 5061, und alle RTP-Medienströme sind via SRTP verschlüsselt. Somit ist ab SBC Richtung Cloud alles Ende-zu-Ende verschlüsselt. Richtung Carrier war unser SIP-Trunk ebenfalls TLS gesichert (glücklicherweise unterstützte unser Provider SIP-TLS und SRTP auf dem Link). Falls mal ein Carrier nur UDP anböte, hätte man zwischen SBC und Carrier unverschlüsseltes RTP, aber das ist intern in unserer DMZ – dennoch wollten wir bestmögliche Security. Zudem setzten wir Session-Timers und regelmäßige Options-Pings ein, damit Verbindungen nicht unbemerkt hängen bleiben.

PSTN-Failover und Backup-Routing: Wir richteten auf SBC-Ebene mehrere Routen ein: – Wenn der Haupt-SIP-Trunk nicht verfügbar ist, versucht der SBC automatisch den Backup-Trunk. Wir hatten einen kleineren Zweitvertrag bei einem alternativen Anbieter als Notfall-Route. Das kostete geringe Grundgebühr, aber so sind wir auch beim Ausfall des primären Carriers nicht stumm. – In kritischen Fällen könnten wir den SBC so konfigurieren, dass er bestimmte Notrufe auch über einen lokalen Gateway rausschickt (z.B. ISDN oder GSM-Gateway). Wir hatten testweise ein LTE-Gateway, über das man im Blackout-Fall 112 senden könnte. Das ist allerdings manuell, sprich wir müssten im Notfall Routing umstellen, was hoffentlich nie nötig wird. Aber als Plan B hatten wir es dokumentiert. – Innerhalb Teams tenant haben wir natürlich auch Cloud-Voicemail. Falls SBC oder Trunk down ist, eingehende Anrufe landen auf der Mobilbox des Users (in der Cloud), sodass zumindest kein Anruf ins Leere läuft. Das war auch Teil unseres Business Continuity Plans: die Voicemail übernimmt, Nutzer werden per Mail benachrichtigt und könnten zurückrufen über Mobiltelefon falls nötig.

Zusammengefasst wurde die SBC-Landschaft so aufgebaut, dass kein Single Point of Failure besteht: zwei SBC-Instanzen, zwei Internet-Uplinks im Rechenzentrum (für SBC-Traffic), zwei SIP-Trunk-Endpoints. Nach Go-Live testeten wir Failover-Szenarien (z.B. einen SBC offline nehmen) – laufende Gespräche brachen zwar ab, aber neue Verbindungen gingen sofort über den zweiten SBC. Die Umschaltzeiten waren im Sekundenbereich.

Netzwerkanforderungen und -anpassungen

Eine Cloud-Telefonie-Lösung stellt hohe Anforderungen an das Netzwerk, daher haben wir hier investiert und optimiert:

• Quality of Service (QoS): Intern im LAN und WLAN wurden DSCP-Markierungen für Echtzeitverkehr umgesetzt. Teams-Clients markieren Audio mit DSCP 46 (EF). Unsere Switches und Router waren so konfiguriert, dass EF-Traffic Priorität hat. So konnten wir sicherstellen, dass z.B. bei hohem Datenaufkommen (große Downloads) die Sprachpakete bevorzugt übertragen werden und es nicht zu Jitter oder Paketverlust kommt. Insbesondere auf WLAN-Access-Points in den Büros stellten wir sicher, dass die Wi-Fi Multimedia (WMM) Einstellungen Sprachpakete hochpriorisieren, damit die zahlreichen Laptop-Calls nicht unter etwa Videostreaming im Gastnetz leiden.
• Bandbreitenplanung: Wir kalkulierten pro Standort die erforderliche Internet-Bandbreite für Worst-Case gleichzeitige Anrufe. Konservativ rechneten wir ~100 kbit/s pro Anruf und Richtung (G.711 Codec mit Overhead). Für einen Standort mit z.B. 500 Usern und angenommener gleichzeitiger Call-Rate 10% (50 Calls) sind das 5 Mbit/s Up/Down dediziert nur für VoIP. Unsere Standorte hatten bereits mindestens 200 Mbit/s Internet (HQ sogar 1 Gbit). Dennoch reservierten wir logische Bandbreiten: auf der Firewall richteten wir Traffic-Shaping ein, das mindestens 5% der Bandbreite für Echtzeitkommunikation reserviert. Tatsächlich lag die gemessene Sprachlast meist unter 2% der Gesamtbandbreite, aber die Reserven geben uns Sicherheit.
• Lokale Breakouts: Wichtig war, dass Teams-Daten möglichst direkt ins Internet gehen. Unsere Remote-Mitarbeiter werden nicht gezwungen, via VPN in die Zentrale zu gehen für Teams; sie nutzen ihr lokales Internet. Ebenso haben unsere Standorte lokale Internet-Breakouts (SD-WAN Architektur), sodass der Medienverkehr nicht erst über MPLS zum HQ tunnelt. Wir implementierten ein Split-Tunneling für VPN-Nutzer: d.h. Teams-Verkehr (Audio/Video) geht direkt raus, während andere Firmendaten über VPN laufen. Das senkt Latenz massiv und entlastet die zentralen Gateways.
• Redundante Internetanbindung: Am Hauptsitz und in zwei größeren Werken haben wir eine zweite Internet-Leitung von einem alternativen Provider installieren lassen. Diese dient als Hot-Standby (automatisches Failover) für den Fall, dass der Primärprovider ausfällt. Dadurch erhöhen wir die Verfügbarkeit der Clouddienste. Für Telefonie besonders relevant: Sollte ein ganzer Standort offline gehen, können die Mitarbeiter dank Mobilfunk/DSL-Fallback weiterhin über Teams (Notbetrieb mit z.B. LTE-Routern) telefonieren. Dieses Szenario testeten wir in kleinem Rahmen: Im Werk A wurde die Hauptleitung simuliert gekappt – der SD-WAN Router schwenkte auf LTE, und erstaunlicherweise funktionierten 5 gleichzeitige Telefonate noch akzeptabel. Natürlich skaliert LTE nicht für 500 User voll, aber die wichtigsten Calls gingen. Das war ein guter Notnachweis.
• VPN und Remote Work: Wir stellten fest, dass viele Außendienstler mit VPN-Clients arbeiten, was manchmal Voice-Probleme machte (Latenz). Durch das Split-Tunnel und Richtlinien in der VPN-Lösung stellen wir sicher, dass Teams nicht durch den VPN geroutet wird. Außerdem empfehlen wir Mitarbeitern, bei wackliger Heimnetz-Qualität eher das Diensthandy per Teams (LTE) zu nutzen. Für Hotels etc. haben wir Guidelines erstellt (z.B. kein Hotel-WLAN für längere Calls nutzen ohne zu testen). Zwar ist das nicht rein technische Architektur, aber wichtig für Praxis – ein tolles System nützt wenig, wenn letzter Meter schlecht.

Zusammengefasst brauchten wir zwar keine gigantischen Bandbreitenupgrades (dank vorheriger Teams-Meeting-Einführung war viel schon da), aber Feintuning in QoS und Redundanz. Dadurch konnten wir gegenüber Management zusichern, dass das Netz den Ansprüchen genügt. Eine interne Messung nach Einführung zeigte, dass 98% aller Anrufe <100ms Latenz und <5% Packet Loss hatten, was in der Regel gute Qualität bedeutet. Wo Probleme auftraten, lag es meist an Nutzer-Heimnetz, worauf wir separat eingingen (Beratung, Alternativen).

Identität, Provisionierung und Automation

Die Zielarchitektur setzt stark auf die vorhandene Azure AD (Entra ID) Identität. Wir nutzten dies für eine möglichst automatisierte Bereitstellung von Telefonie-Funktionen: – Lizenzierung per Gruppe: Wir richteten in Entra ID eine dynamische Gruppe „Teams-Telefonie-Benutzer“ ein, in der alle Mitarbeiter enthalten sind, die die Phone System Lizenz erhalten sollen. Kriterien waren z.B. die Abteilung oder ein Attribut „Telefonie=Ja“ im AD. Beim Onboarding eines neuen Mitarbeiters muss HR dieses Attribut setzen, dann bekommt der Account automatisch via Azure AD gruppenbasierte Lizenzzuweisung die E3 + Phone System Add-On (sofern nicht ohnehin E5). Das spart viel manuelle Klickarbeit im Admin Center. – Automatische Rufnummernzuteilung: Für die Nummernvergabe entwickelten wir ein PowerShell-Skript, das aus einer gepflegten Nummern-Pool-Liste die nächste freie Durchwahl zieht und dem Benutzer zuweist. Nach unserer Nummernlogik wird abhängig vom Standort oder Abteilung ein passender Nummernblock gewählt. Beispielsweise alle Vertriebsmitarbeiter bekommen Durchwahlen in einem bestimmten Range. Das Skript läuft halb-automatisch: Ein Admin stößt es an, wenn neue Kollegen kommen, es liest den Personendatensatz (Abteilung, Standort) und schlägt eine Nummer vor, die dann per Teams PowerShell dem User zugewiesen wird (Set-CsUser -LineURI …). Wir überlegten auch, dies via Azure Automation komplett „zero-touch“ zu machen, haben aber zunächst den manuellen Review beibehalten, falls Sonderwünsche (Wunschnummern etc.) existieren. – Identitätsabgleich alter vs neuer Nummer: Im Projekt war es wichtig, die Verbindung von Alt-Nummern zu neuen Teams-Accounts herzustellen. Wir extrahierten aus der alten PBX alle Durchwahlen und importierten diese in eine Mapping-Tabelle. So konnten wir jedem Mitarbeitenden im Voraus seine künftige Teams-Rufnummer mitteilen (oft identisch mit alter, aber falls geändert, proaktiv informieren). Identitätstechnisch wird fortan das Azure AD Profil zur einzigen Quelle für Kommunikationsdaten: Die Telefonnummer jedes Mitarbeiters ist dort hinterlegt und erscheint auch im Outlook Adressbuch. Das war früher teils manuell gepflegt – nun kommt es automatisch durch die Teams-Zuweisung. – Rollen & Rechte: In Teams Phone System gibt es Admin-Rollen (z.B. Teams Voice Administrator). Wir bestimmten zwei interne Kollegen, die diese Rolle erhalten, um im Betrieb Nummern zu managen, Policy-Änderungen vorzunehmen etc. Das Prinzip der minimalen Rechte wurde verfolgt: Nur spezifische IT-Mitarbeiter können Telefonieeinstellungen ändern; normale Helpdesk-Mitarbeiter dürfen zwar im Teams Admin Center Benutzer suchen, aber nichts an PSTN-Einstellungen ändern ohne Freigabe. – Monitoring Automation: Wir binden hier auch an: per Skript werden täglich die Call Quality Dashboard Daten extrahiert und in ein internes Monitoring-Tool überführt. Ebenso gibt es Alerts bei z.B. Anomalien (via PowerShell modul). Diese Automation entlastet die kontinuierliche Überwachung.

Azure AD und Identity Security verknüpft mit Architektur: Wir haben Conditional Access so eingestellt, dass nur compliant devices (Intune verwaltet oder Domainjoined) und MFA-gesicherte Sessions Telefonie nutzen dürfen. Das heißt, ein fremder nicht registrierter PC könnte sich nicht so einfach mit einem geklauten Passwort anmelden und telefonieren. Diese Verknüpfung von Identität, Gerät und Telefonie war dem Sicherheitsarchitekten wichtig.

Endgeräte-Strategie

Die schönsten Systeme nützen wenig ohne passende Endgeräte. Daher haben wir festgelegt, welche Gerätearten zum Einsatz kommen: – Headsets (Preferred Device): Für die Mehrheit der 2.000 Informationsarbeiter entschieden wir uns, qualitativ hochwertige USB-Headsets anzuschaffen. Die Erfahrung mit Teams-Meetings zeigte, dass gute Audioqualität stark vom Headset abhängt. Wir wählten ein Teams-zertifiziertes Modell mit Noise-Cancelling-Mikrofon und komfortablem Design, Preis ca. 50 € pro Stück. Viele hatten bereits einfache Headsets, aber wir wollten ein einheitliches Level. Diese Headsets wurden zusammen mit der Einführung verteilt. Vorteil: Die Mitarbeiter können damit am Laptop oder Handy arbeiten, haben die Hände frei und gewöhnen sich schnell dran. – Teams-Tischtelefone: Es gibt dennoch Benutzer, die einen klassischen Hörer bevorzugen (z.B. Empfang, ältere Führungskräfte oder Leute, die ungern Headsets tragen). Für diese Fälle beschafften wir ca. 100 Teams-fähige Telefone. Das sind IP-Geräte, die nativ Microsoft Teams laufen haben (meist ein Touchscreen mit Teams-App oder ein einfacheres mit kleiner Anzeige). Sie melden sich mit dem Azure AD Account des Benutzers an. Diese Telefone platzierten wir insbesondere an Empfangs- und Sekretariatsarbeitsplätzen und auf Wunsch einzelnen anderen Büros. Auch in Besprechungsräumen, wo kein vollwertiges Teams Room System nötig war, stellten wir teils ein Tischtelefon als Konferenztelefon bereit (als Ersatz für die früheren Polycom Spider Phones). – Konferenzsysteme / Meeting Räume: Für größere Konferenzräume investierten wir in drei Microsoft Teams Rooms Systeme (Logitech Rally Sets mit Mini-PC und Touchpanel). Diese waren zwar nicht direkt Teil „Telefonie“, aber ergänzen die UCC-Strategie. Sie haben eigene Lizenzen (Teams Room Pro) und können auch PSTN-Anrufe tätigen/empfangen (z.B. Meeting participants einwählen). Damit decken wir die Konferenztelefonie mit ab. Kleinere Meeting-Ecken bekamen entweder die o.g. Teams-Tischtelefone im Konferenzmodus oder nutzen einfach einen Laptop mit Freisprech-Speaker. – Mobile Geräte / Smartphones: Jeder Mitarbeiter mit entsprechendem Bedarf hatte bereits ein Firmenhandy oder durfte die Teams-App auf dem privaten nutzen (BYOD). Unsere Strategie ist, diese Smartphones verstärkt als Teams-Mobilteil zu verwenden, gerade im Lager/Shopfloor. Einige Tablets wurden auch getestet für Service-Techniker, damit sie mobil im Intranet als auch per Anruf kommunizieren können. Dabei achteten wir auf robuste Hüllen oder spezielle Rugged-Phones mit Android Teams Client in den Werkhallen. Hier läuft noch ein Pilot, aber Tendenz: Smartphone + Teams ersetzen langfristig DECT, wenn Netzabdeckung es erlaubt. – DECT-Integration: Kurzfristig konnten wir DECT nicht eliminieren. Daher setzten wir auf Bridging: Die vorhandenen DECT-Systeme bleiben mit der alten TK-Anlage verbunden, die wiederum via SBC mit Teams spricht. Außerdem prüften wir Lösungen von Drittanbietern: z.B. Spectralink DECT over IP mit Teams SIP Gateway. Diese Lösungen versprechen, DECT-Handsets als SIP-Teilnehmer im Teams-System zu führen. Wir pilotierten ein solches System in einem Werk: Es hat funktioniert, aber die Funktionen (z.B. Alarmknopf) waren eingeschränkt. Daher bleibt DECT vorerst separat. Der Endgeräte-Plan sieht aber vor, in den nächsten 1-2 Jahren entweder komplett auf Mobilfunk (5G campus network) umzustellen oder eine spezielle Funklösung zu integrieren. Hier bleibt Flexibilität. – Analoge Geräte (Tür, Fax, etc.): Für Türsprechstellen und Faxgeräte haben wir Analoge Adapter (ATA) beschafft, die an den SBC registriert sind. Z.B. eine Türsprechanlage am Werkstor hängt jetzt an einem ATA, dieser ist im SBC als SIP-User hinterlegt. Ruft jemand an der Tür, initiiert der ATA einen Anruf an eine definierte Nummer (eine Call Queue in Teams für den Empfang/Werkschutz). Ähnlich mit Fax: Einige Faxe wurden an ATA gehängt und nutzen T.38-Protokoll zum SBC, der leitet ans Fax-Gateway weiter. Das war ein pragmatischer Weg, die alten Geräte nicht sofort austauschen zu müssen.

Die Endgeräte-Strategie war also hybrid: primär Softphone (Headset), wo nötig Hardware. Und immer Teams-zertifizierte Devices für beste Kompatibilität. Wir testeten alle Gerätetypen vorab im Pilot, um sicherzugehen, dass z.B. die Treiber funktionieren, Firmware aktuell ist etc. Im Rollout gab es natürlich kleinere Probleme (einige User hatten lieber ein anderes Headset-Modell aus Komfortgründen – da haben wir Kulanz gezeigt und Alternativen beschafft). Aber insgesamt war das Feedback sehr positiv, vor allem jüngere Mitarbeitende schätzten das Headset+App Konzept.

Logische Architektur – Beschreibung

Die Zielarchitektur lässt sich in einem logischen Diagramm darstellen (hier in Worten beschrieben):

• Microsoft 365 Cloud: Im Zentrum steht der Microsoft 365 Cloud-Dienst „Teams Phone System“. Dieser ist weltweit verfügbar und bei uns im EU-Rechenzentrum gehostet. Alle unsere Teams-Clients – sei es auf PCs im Büro, Laptops zuhause, Smartphones unterwegs oder dedizierte Teams-Telefone – verbinden sich übers Internet zu den Microsoft Teams-Services. Die Signalisierung (Aufbau, Abbau von Gesprächen) und die Vermittlungslogik liegen dort.
• Session Border Controller (SBC): In unserem Unternehmensnetz haben wir zwei SBC-Server (im Diagramm als SBC1 und SBC2), die via Firewall mit dem Internet verbunden sind. Diese SBCs registrieren sich als Direct Routing Endpoint beim Teams Phone System. Vereinfacht gesagt: Teams weiß, für Telefonnummern der Harry Hase AG soll es den Weg über unseren SBC nehmen, um ins PSTN zu gelangen, und umgekehrt schickt unser SBC eingehende Anrufe ans Teams System.
• PSTN-Anbindung (Carrier): Von den SBCs gehen eine oder mehrere Verbindungen zu Telefonnetzbetreibern. In unserem Fall führt eine SIP-Trunk-Verbindung zum Hauptcarrier (TeleCoA) und eine zweite zu einem Backup-Carrier (TeleCoB). Diese Trunks laufen über dedizierte VPNs oder über das Internet mit IPsec – wir haben uns für einen Managed SIP-Trunk über Internet entschieden, der durch TLS geschützt ist. Darüber fließen alle Anrufe zu externen Teilnehmern (Kunden, Partner, öffentliche Netze).
• Telefoniegeräte und Clients: Jeder Mitarbeiter hat einen oder mehrere Teams-Clients: z.B. Teams auf dem Laptop und auf dem Smartphone. Diese Clients nutzen primär das Internet (über LAN, WLAN oder Mobilfunk) um die Teams-Cloud zu erreichen. Im Büro gehen sie über die Firmenleitung ins Internet, was QoS-gesichert ist. Von der Cloud aus wird bei PSTN-Anrufen dann der Pfad zum SBC hergestellt. Interne Teams-zu-Teams Gespräche bleiben komplett in der Cloud bzw. verbinden die Clients direkt via Microsofts Medienrelais. Die dedizierten Teams-Tischtelefone fungieren letztlich wie ein weiterer Teams-Client im Netzwerk.
• Legacy-Systeme Integration: Daneben haben wir im Diagramm die Contact-Center-Plattform (CC-System) und die alte PBX/DECT-Systeme noch eingezeichnet. Das Contact-Center ist über einen SIP-Trunk (via SBC) angebunden: d.h. bestimmte Rufnummern (z.B. die IT-Helpdesk-Nummer) leitet der SBC direkt weiter an das CC-System, wo der Call dann an einen Agent geht. Umgekehrt kann das CC-System über den SBC auch Teams-Anschlüsse anrufen oder ins PSTN. So stellen wir sicher, dass das CC parallel weiterläuft. Die alte PBX in den Werken ist über ein Protokoll (SIP/QSIG) an den SBC gekoppelt, sodass DECT-Ext. erreichbar bleiben. Dieses Element soll nach Migration der DECT irgendwann entfallen.
• Notruf und Monitoring: Nicht zu vergessen: Wir haben ein Monitoring-System (z.B. PRTG oder Azure Monitoring), das unsere SBCs pingt, die SIP-Trunks prüft und via Teams-CQD die Callqualität abfragt. Dieses System steht im IT-Netz und alarmiert bei Problemen. Außerdem ist für Notrufe ein Pfad vorgesehen: Sollte Teams ausfallen, haben wir analoge Nottelefone (im Diagramm als separate PSTN-Anschlüsse an Standorten), welche unabhängig funktionieren. In der logischen Architektur sind diese außerhalb von Teams, als direkter PSTN-Pfad vom Standort zum Notruf. Sie bilden die äußerste Backup-Schicht.

Insgesamt zeigt die Architektur, dass Microsoft Teams Phone System als Cloud-PBX fungiert, unser SBC als Gateway zwischen Cloud und realer Telefonwelt, und alle Endpunkte (User-Devices, externe Netze, Subsysteme) dort andocken. Diese Modularität hat sich als sehr praktisch erwiesen: Änderungen können oft isoliert passieren (z.B. anderer Carrier = SBC-Konfig ändern, nicht Clients oder Cloud).

Kapazitäts- und Bandbreitenkalkulation

Zum Abschluss der Architekturplanung führten wir noch eine detaillierte Kapazitäts- und Bandbreitenkalkulation durch, um sicherzustellen, dass alle Komponenten ausreichend dimensioniert sind:

Erläuterungen: – Wir planten mit höchster Qualitätsstufe. Teams kann adaptiv auch niedrigere Bitraten fahren (z.B. SILK Codec bei schlechter Netzqualität bis 36 kbit/s). Unsere Kalkulation mit 100 kbit/s pro Richtung war konservativ, um Puffer zu haben. – Die gleichzeitigen Anrufe wurden je Standort abgeleitet vom Nutzerprofil (Büro vs. Produktion). In der Produktion (Schichtleiter etc.) rechneten wir sogar weniger, da dort seltener telefoniert wird, eher Funk genutzt. – Wichtig: Falls doch mal alle Anrufe extern wären (z.B. große Outbound-Aktion), hätten wir 200 gleichzeitige PSTN-Calls = 20 Mbit/s up/down. Unsere Leitungen sind selbst an kleineren Standorten mindestens 100 Mbit/s symmetrisch, also kein Problem. – Die Firewall wurde geprüft, ob sie die RTP-Menge packt (einige Firewalls haben Sessionlimits, aber 100-200 UDP-Streams sind gering). Wir stellten sicher, dass keine ALG stört (SIP-ALG wurde deaktiviert, da SBC das Handling übernimmt). – Auf Userseite informierten wir: Ein Teams Call verbraucht ~0,1 Mbit – also selbst mobile Daten (4G) reichen für Dutzende Minuten. Das half Bedenken auszuräumen, dass Telefonie übers Internet viel Volumen frisst. Tatsächlich sind Videomeetings viel hungriger, was alle schon gewohnt waren. – For future scaling: Wir können relativ leicht die SIP-Kanäle erweitern (Lizenzupgrade SBC + mehr Bandbreite im Trunk), falls die Firma wächst oder Telefonie stärker genutzt wird. Die Cloud selbst skaliert automatisch.

Mit dieser Planung war das Architektur-Design abgeschlossen und wir konnten in die Migrationsplanung gehen, sicher dass wir auf soliden technischen Füßen stehen.

5. Migrationsstrategie und Roadmap

Die Einführung von Teams-Telefonie bei 4.000 Mitarbeitenden ist ein Großprojekt, das wir mit einer durchdachten Migrationsstrategie in Etappen umgesetzt haben. In diesem Kapitel beschreibe ich die gewählte Vorgehensweise: von Pilotierung über schrittweisen Rollout bis zur Koexistenz mit der alten Anlage, untermauert durch einen konkreten Wellenplan, RACI-Matrix und Risikobetrachtungen.

Brownfield-Ansatz und Koexistenz: Da eine funktionierende TK-Anlage vorhanden war und die Telefonie nicht unterbrochen werden durfte, wählten wir einen Brownfield-Ansatz. Das bedeutet, Teams-Telefonie wurde parallel zur bestehenden PBX eingeführt, mit zeitweiser Koexistenz beider Systeme. Wir vermieden einen „Big Bang“-Umstieg. Die Koexistenzphase erforderte gezielte Maßnahmen: – Nummern-Dualität: Solange ein Standort noch auf PBX lief und ein anderer schon auf Teams, mussten interne Anrufe zwischen ihnen funktionieren. Wir realisierten dies durch temporäre Weiterleitungen und Überschneidungsbereiche. Beispielsweise wurde in der PBX programmierte, dass wenn ein interner Benutzer die Durchwahl eines bereits migrierten Kollegen wählte, der Call über den SIP-Trunk (via SBC) an Teams ging. Umgekehrt konnten Teams-Benutzer noch PBX-Nebenstellen über den SBC erreichen – hierzu definierten wir im SBC sog. „Dial Plan“ Einträge, die Nummern, die (noch) zur alten Anlage gehören, an diese weiterleiten. – Parallelbetrieb Endgeräte: In der kritischen Umstellungsphase hatten manche Mitarbeiter zwei Telefone: Ihr altes Telefon blieb noch aktiv, während sie schon in Teams testeten. Besonders in der Pilotphase war das so. Das verursachte etwas Verwirrung (z.B. welches Telefon klingelt?), weshalb wir das nur sehr kurz hielten. Besser funktionierte unser Plan, ganze Gruppen umzuschalten, sodass innerhalb z.B. der IT-Abteilung dann nur noch das neue Gerät genutzt wurde. – Schrittweise Nummernportierung: Die Rufnummern mussten beim Carrier teils neu geroutet werden (vom alten PBX-Anschluss auf den neuen SIP-Trunk). Dies erfolgte standort- bzw. blockweise. Wir vereinbarten mit dem Provider einen Portierungsplan: z.B. Woche X: alle Nummern des Werks A auf neuen Trunk. Bis dahin leiteten wir eingehende Anrufe vom alten Anschluss zum neuen weiter. Hier half uns, dass wir denselben Provider behielten, der intern die Umstellung reibungsloser gestalten konnte (quasi eine Umbuchung im Netz).

Pilotierung: Wir starteten mit einem Pilotprojekt vor dem eigentlichen Rollout: – Pilotgruppe: Zuerst haben wir die IT-Abteilung (ca. 40 Nutzer) und einige „Tech Enthusiasts“ aus anderen Bereichen ausgewählt. Insgesamt ~100 Personen bildeten den Pilot. Diese bekamen als erste Teams-Telefonie eingerichtet, inklusive aller Funktionen. Sie hatten weiterhin ihre alten Telefone, aber sollten bevorzugt über Teams telefonieren. – Pilotdauer und Ziele: Der Pilot lief 4 Wochen. Ziel war, Kinderkrankheiten zu erkennen, z.B. ob Headsets funktionieren, ob das Wählverfahren verstanden wird, ob Qualitätsprobleme auftreten. Wir definierten messbare Erfolgskriterien: Mindestens 90% der Pilotanrufe sollen erfolgreich und in guter Qualität verlaufen; Supporttickets aus dem Pilot < 10 pro Woche; Pilotnutzer sollen am Ende zu ≥80% zufrieden sein laut Umfrage. – Abbruchkriterien: Hätten wir im Pilot gravierende Probleme festgestellt (z.B. ständige Verbindungsabbrüche, Nichtakzeptanz durch Nutzer), hätten wir den Rollout verschoben und nachgebessert. Konkret sagten wir: Bei einem kritischen Problem, das innerhalb 2 Wochen nicht lösbar ist, Stop and Fix bevor mehr Nutzer migrieren. – Ergebnisse Pilot: Tatsächlich traten ein paar Herausforderungen auf – z.B. Probleme bei der Rufnummernanzeige (an externe wurde zunächst die falsche Nummer gesendet aufgrund einer SBC-Einstellung, was wir korrigierten). Ein anderes Thema: Manche Pilotnutzer vermissten die Funktion „Pickup“ (Anruf heranholen aus Gruppe). Teams hat das so nicht, aber es gibt Gruppenruf und Parallelklingeln – wir schulten entsprechende Workarounds. Nichts davon war ein Showstopper. Die Qualität war überwiegend gut, nur ein Standort hatte LAN-Probleme (falsche Switch-Queue, wurde gefixt). Also konnten wir nach dem Pilot grünes Licht geben.

Standort-Rollout und Wellenplanung: Wir entwickelten einen Rollout-Fahrplan in Wellen. Kriterien für die Reihenfolge: – Zunächst kleinere Standorte migrieren, um die Prozesse einzuspielen, bevor die größte Masse (HQ) drankommt. – Abhängigkeiten beachten: z.B. das Hauptquartier enthielt die zentrale Vermittlungsstelle (Empfang) – diese wollten wir nicht umstellen, bevor nicht alle Außenstellen erreichbar sind. Daher kam HQ eher gegen Ende, damit zwischenzeitlich der Empfang noch alte Anlage bedienen konnte für externe und interne. – Bereitschaft der Infrastruktur: Ein Werk hatte noch alte Netzwerk-Switche, dort wollten wir erst nach einem Upgrade migrieren. Ebenso warteten wir an einem internationalen Standort auf Microsoft Teams Calling Plan (da wir für 5 Leute dort kein SBC local deployen wollten). Solche Dinge flossen ein. – Personelle Ressourcen / Kapazität: Wir konnten pro Woche etwa 200–300 User migrieren (mit Schulung, Support bereitstellen). Also planten wir entsprechend. – Geschäftskalender: Wir vermieden kritische Zeiten wie Monatsabschluss im Finanzbereich oder Produktionshochläufe. Für solche Phasen legten wir Sperrfristen fest, wo keine Migration stattfindet.

Basierend darauf entstand folgender Migrationswellenplan (vereinfacht dargestellt):

(Die Daten sind fiktiv für das Konzept; tatsächlich lag unser Go-Live Ende Oktober 2025, mit einer Nachlaufwoche für Problembehebung.)

Erläuterungen zum Wellenplan: Wir gingen im 2-Wochen-Takt voran. Jede Welle hatte einen klar definierten Umfang und ein testbares Paket: – In den Testfenstern (typisch 1-2 Tage nach Umschaltung) überprüften wir mit Checklisten (siehe nächstes Kapitel Implementation) die Funktion. Bis zum Go (Freigabe) hatten wir die Möglichkeit, im Notfall auf die alte Anlage zurückzuschalten (z.B. durch umstecken der Trunks oder Reaktivieren von Telefonen). – Welle 4 beispielsweise: Teile des HQ schon früh umgestellt, damit wir Learnings in der Zentrale sammeln, aber den Vorstand etc. erst später. – Die Buffer-Woche war Gold wert: Wir brauchten sie tatsächlich, weil in Welle 5 (Werk D) ein Problem mit DECT-Routing auftrat, was wir in der Buffer-Woche behebten, bevor es an HQ ging. So hatten wir keinen Terminverzug beim finalen Go-Live. – Die internationale Umstellung war eher einfach, weil dort nur wenige User waren, teils ohne eigene Anlagen – wir nutzten für z.B. 10 USA-Mitarbeiter Microsoft Calling Plan (die einzige Ausnahme, wo wir doch auf MS as Provider gingen, weil es so wenige waren). Das war parallel in Welle 7 remote handhabbar.

Kommunikation jeder Welle: Vor jeder Migrationswelle bekamen die betroffenen Nutzer ein Informationspaket mit ihrem Umstellungsdatum, was das für sie bedeutet (z.B. „Ihr Telefonapparat wird ab Tag X außer Betrieb gehen, bitte nutzen Sie dann Teams…“). Ebenso richteten wir pro Welle einen lokalen Support ein (Floorwalker, extra Hotline). Das wird im Change-Management-Teil noch ausgeführt.

RACI-Matrix: Ein solches Projekt erfordert klare Rollen. Hier ein Ausschnitt unserer RACI-Matrix für die wichtigsten Aufgabenbereiche (R = Responsible, A = Accountable, C = Consulted, I = Informed):

In Worten: Als Projektleiter war ich für Planung, Koordination, Entscheidungsfindung (A) verantwortlich. Das TK/Netz-Team war für die tatsächliche Umsetzung der Technik (SBC config, Teams setup etc.) verantwortlich und ausführend (R). Security und Datenschutz haben beratend (C) mitgewirkt, insbesondere bei Richtlinien. Einkauf/Provider-Management war federführend (R) bei allen Carrier-Interaktionen (Verträge, Portierung). Der Betriebsrat und HR waren zu informieren und bei relevanten Inhalten zu konsultieren (z.B. Schulungen, BV). Schlüsselanwender in den Fachbereichen wurden informiert oder konsultiert bei Test und Abnahme, damit deren Anforderungen nicht übergangen werden. Hersteller/Partner (z.B. Microsoft Partner fürs SBC-Setup) wurden dort eingesetzt, wo Spezial-Knowhow nötig war, aber nie in alleiniger Verantwortung – wir haben internes Know-how aufgebaut, sodass Partner eher beratend und ausführend unter unserer Anleitung tätig waren.

Diese RACI-Matrix half enorm, Missverständnisse zu vermeiden. Beispielsweise wussten wir, dass für „Nummernportierung“ klar der Einkauf das Zepter hat, also bin ich dem hinterher, statt zu erwarten, dass der Techniker das mal eben macht. Ebenso war geregelt, dass HR die Schulungen organisiert, sodass das nicht zwischen Stühlen fällt.

Risikoregister: Kein Migrationsprojekt ohne Risiken. Wir haben früh ein Risikoregister geführt, in dem wir potenzielle Risiken bewerteten und Gegenmaßnahmen definierten. Hier einige der Top-Risiken aus unserem Register:

Wir bewerteten die Risiken in Skalen von 1 (niedrig) bis 5 (hoch) für Eintritt und Auswirkung. Der Fokus lag natürlich auf den hohen Auswirkungen, insbesondere Notruf und Qualität. Diese blieben aber beherrschbar durch proaktive Maßnahmen. Erfreulicherweise trat keines der kritischen Risiken in gravierender Weise ein – kleine Zwischenfälle gab es (z.B. zwei Stunden Verzögerung bei einer Portierung, was dank Weiterleitung aber keine Auswirkung hatte). Dieses Risikomanagement gab allen Stakeholdern Vertrauen, dass wir uns der möglichen Probleme bewusst waren und vorbereitet in die Umsetzung gingen.

Mit dieser Strategie und Planung konnten wir nun in die Implementierungsphase übergehen, in der die technischen Konfigurationen und Umschaltungen tatsächlich durchgeführt wurden.

6. Implementierung und Konfiguration

In der Implementierungsphase ging es ans Eingemachte: Rufnummern portieren, SBC konfigurieren, Teams-Einstellungen vornehmen, Auto Attendants einrichten, Integrationen umsetzen und jedes Detail testen. Hier berichte ich, wie wir technisch vorgingen, und stelle Checklisten und Konfigurationsübersichten vor, die uns durch die Go-Live-Phase leiteten.

Nummernportierung und Carrier-Onboarding: Ein entscheidender Meilenstein war die Portierung der Rufnummern vom alten System auf das neue SIP-Trunk-Setup. Da wir beim gleichen Carrier blieben, war es eher eine Umkonfiguration: Der Carrier leitete die bestehenden Nummernkreise nun an unsere SBC-IP weiter statt an die alte PBX. Dennoch behandelten wir es formell wie eine Portierung mit festen Terminen. Vorgehen: – Für jede Migrationswelle meldeten wir dem Provider einen Portierungstermin und die Liste der Rufnummern (Hauptnummer und Block) die umgeschaltet werden. Meist war das 2 Wochen Vorlauf, was vertraglich so festgelegt war. – Der Provider führte in der Nacht vor dem Stichtag die Umstellung durch, testete kurz mit uns die Erreichbarkeit der Hauptnummer. – Parallel haben wir neue Rufnummern (wie die 0800-Nummer für Auto Attendant) bei ihm bestellt und im SBC konfiguriert. – Für Operator Connect (bei Auslandsstandorten) gab es ein separates Onboarding: Im Teams Admin Center verknüpften wir unseren Tenant mit dem OC-Anbieter und ordneten Nummern zu. Das war ein kleinerer Teil, aber interessant zu sehen – es ging sehr fix (in Minuten konnte man einer Person eine OC-Nummer zuweisen und anrufen).

SBC-Provisionierung und Zertifikate: Die Installation des SBC (Audiocodes) erfolgte auf zwei bereitgestellten Windows Server VMs (für die Software SBC). Schritte: – Grundinstallation: OS aufgesetzt, SBC-Software installiert, Lizenz eingespielt (für 64 Calls und HA). – Netzwerk & Firewall: Wir vergaben feste IPs in der DMZ, öffneten an der Firewall die nötigen Ports (TCP 5061 für SIP TLS, UDP 1024-65535 für RTP/RTCP zwischen SBC und Internet auf Microsofts IPs; außerdem SIP/TLS zu Carrier-Gateway IPs, und SIP zu interner alter PBX IP für Kopplung). – DNS und Zertifikat: Unsere Domain „harryhase.de“ wurde genutzt, wir legten zwei FQDNs an: sbc1.harryhase.de und sbc2.harryhase.de, beide A-Records auf jeweilige öffentliche IP. Wir bestellten ein Wildcard-Zertifikat für .harryhase.de von DigiCert und teilten es (das war aus Kostengründen einfacher). Jede SBC-Instanz bekam das Zertifikat importiert und als Server-Zertifikat konfiguriert. Microsoft Teams verlangt bestimmte Root CAs – DigiCert ist zum Glück akzeptiert. – Teams Direct Routing Konfig: Per PowerShell auf Office 365 richteten wir eine Online PSTN Gateway für unsere Domain ein (New-CsOnlinePSTNGateway -FQDN sbc1.harryhase.de etc.). Wir setzten Parameter wie SIP Signaling port (5061), MedienBypass $True. Dann erstellten wir Voice Routes: z.B. route „DefaultOutbound“ -> sbc1/haupt trunk für +49\d+ (alle deutschen Nummern) und ein Emergency-Route extra. – Carrier Trunk Config auf SBC: Im SBC GUI legten wir einen SIP Peer für den Carrier an (IP/Port, TLS, using our certificate). Wir passten die Signalisierungs-Header an: z.B. welchen CallerID wir senden (From: User’s DDI, und P-Asserted-Identity ebenfalls). Der Carrier forderte auch eine Registrierung – wir haben unser SBC als registrierend konfiguriert mit Authentifizierung am Carrier. – Dialplan und Manipulationen: Auf dem SBC definierten wir Regelwerke: Anrufe von Teams kommend (die in E.164 Format sind, z.B. +4923199991234) sollen zur Carrier-Route geschickt werden. Umgekehrt eingehend vom Carrier (national Format oder E.164) werden auf die Teams trunk geschickt. Speziell Notrufe: Wenn Patterns 112 oder 110 erkannt wurden, senden wir diese ebenfalls an Carrier, aber z.B. mit Standortkennung im SIP-Header (es gibt das Header-Feld „Geolocation“ oder auch als Calling Party Number). Das konnten wir so einrichten, dass pro Absenderrufnummer der registrierte Standort mitging. Dazu pflegten wir am SBC eine Mapping-Tabelle: Durchwahl 5xxx -> Standort Dortmund Adresse, 7xxx -> Standort Werk B Adresse, etc., und setzen ein SIP-Header „Geolocation-by-reference“ der auf eine URL mit Address-Object beim Provider zeigt. Das war High-End, aber unser Provider unterstützte es. – Failover & HA: Wir testeten den Heartbeat zwischen SBC1 und SBC2 – wenn einer nicht erreichbar war, übernahm der andere. In Teams legten wir zwei separate PSTN Gateways an (sbc1… und sbc2…) aber packten sie in eine SBC-Huntgruppe mittels Voice Route mit zwei FQDNs. So verteilt Teams automatisch oder probiert den zweiten, falls erster nicht geht. – Testing: Bevor Nutzer migrierten, machten wir umfangreiche Tests: Ein Testkonto in Teams mit einer Testnummer wurde angelegt, dann ausgehend angerufen (Handy, Festnetz), eingehend vom Handy auf die Testnummer. Qualitativ hörten wir auf Einweg-Audio etc. Adjustierten jitter buffer, DTMF (stellten auf RFC2833, klappte). Notrufe testeten wir nicht live sofort, aber wir riefen die Testnummer der Feuerwehr* an (es gibt eine spezielle, die man vereinbaren kann – wir fragten an, aber stattdessen machte Provider eine Simulation). Alles sah gut aus nach ein paar Tweaks.

Teams-Routing: Voice Routing Policies, PSTN Usages, Dial Plans, Notrufrouting: Auf der Office365/Teams-Seite war Konfiguration in drei Bereichen nötig: – Voice Routing Policies & PSTN Usage: Wir legten zwei Voice Routing Policies an: „OutboundPolicy_Default“ für normale Benutzer und „OutboundPolicy_Intl“ für jene, die international dürfen. Die Policies enthalten PSTN Usages (im Grunde Gruppen von Dialing-Routen). Default hatte „NationalCalls“ usage, Intl-Policy hatte „NationalCalls“+“InternationalCalls“. Dann definierten wir Voice Routes: „NationalCalls“ => if number starts +49 or + (and length <= 12 digits) then route to sbc-group; „InternationalCalls“ => if number starts + and length >12 (i.e. not Germany) route to sbc-group. Damit können wir steuern, wer international darf: Nur wer die Intl Policy hat, bei dem wird auch diese Route angewendet. Zusätzlich gab es „EmergencyCall“ usage mit eigener Route für 112/110, die ebenfalls auf sbc-group zeigt, aber markiert als emergency (Teams macht da besondere Behandlung). – Dial Plan (Normalization): Wir erstellten einen unternehmensweiten Dial Plan „HarryHaseCorpPlan“. Darin schrieben wir Normalisierungsregeln, damit die Anwender möglichst frei wählen können: – z.B. ^0(\d+)$ -> +$1 (damit ein Anwender, der 0 vorwählt für Amt wie früher, trotzdem rauskommt – das 0 wird entfernt und Nummer als nationaler String genommen, dann +49 davor.) – ^(\d{4})$ -> normalisiert zu +492319999$1 für interne 4-stellige Durchwahlen im HQ-Bereich. Bzw. wir hatten mehrere, je nach führender Ziffer: 1xxx,2xxx HQ, 5xxx Werk B etc., um sie auf die richtige Ortsvorwahl und Stamm zu mappen. Diese Liste war länger, aber wir dokumentierten sie gut. – ^(\d{2})$ -> wir erlaubten 2-stellige Service-Kurzwahlen etwa 11 -> Notruf 112 (für Leute, die evtl. 11 wählen in Panik, wobei das eher unwahrscheinlich war). – Auslandsformat: ^00(\d+)$ -> +$1 (klassisch 00->+). So konnten Mitarbeiter ähnlich wie bisher wählen (wobei wir natürlich aktiv kommunizierten: besser direkt Name oder +49…). Aber gerade ältere Kollegen tippen gerne 0 und dann Nummer. Den Dial Plan weisen wir allen Benutzern zu. – Notrufrouting in Teams: Zusätzlich zur SBC-seitigen Config richteten wir in Teams einen Emergency Address pro Netzwerkstandort ein und eine Emergency Call Routing Policy. In dieser Policy steht: Notrufe leiten an „SBC“ (wählbares target). Für uns war es normaler Weg, aber wir mussten es definieren, weil bei Direct Routing Teams das so verlangt. Hier war ein kleiner Ritt: man kann in Teams pro Standort definieren welche Notrufnummer an welches Ziel geht. Wir sagten 112->Carrier via SBC. Hätten wir verschiedenen Standorte in unterschiedlichen Ländern, könnte man differenzieren (911 in USA anders etc.). Das war eher Setup-Formalität.

Auto Attendants & Call Queues: Ein großer Teil der Konfiguration betraf Automatisierte Telefonzentralen (Auto Attendants) und Anrufwarteschleifen (Call Queues) in Teams, um die alten PBX-Funktionen nachzubilden: – Wir richteten einen Auto Attendant für die Haupt-Hotline des Unternehmens ein: Unter der Durchwahl -0 oder -100 (variiert je Standort) meldet sich jetzt ein Sprachmenü. Text: „Willkommen bei Harry Hase AG. Für Deutsch bitte 1, for English press 2.“ Wir nutzten die zweisprachige Fähigkeit, da wir internationale Anrufe bekommen. Danach Optionen „Vertrieb, Einkauf, Zentrale“. Das Menü leitet je nach Wahl an entsprechende Call Queues. – Geschäftszeiten: Für die Zentrale definierten wir Öffnungszeiten 8-18 Uhr. Außerhalb dieser Zeiten spielt der Auto Attendant eine Ansage („Außerhalb unserer Geschäftszeiten…“) und bietet ggf. Drücken von 1 für eine Notfall-Rufnummer (die dann z.B. an den Werkschutz verbindet) oder hinterlässt eine Voicemail. – Feiertagsregeln: Wir pflegten die deutschen gesetzlichen Feiertage in den Auto Attendant. An diesen wird wie außerhalb Geschäftszeit behandelt. Außerdem schalteten wir am 24.12./31.12. spezielle Ansagen. – Call Queues: Für z.B. Vertrieb richteten wir eine Warteschlange ein „Sales Queue“ mit den Mitarbeitern aus Vertrieb Innendienst. Klingelmodus RingAll (alle parallel) oder in definierter Reihenfolge je nach Wunsch. Wartemusik: Wir luden eine lizenzfreie Melodie hoch (Teams erlaubt Custom Music on Hold pro Queue). Timeout: Falls 30 Sek keiner rangeht, Overflow zum Sekretariat. – Delegation vs. Queue: Für Chef-Sekretär Szenarien nutzten wir die eingebaute Delegationsfunktion: Chefs stellten ihre Assistenten als Delegates ein, so klingelt es bei beiden und die Assistentin kann im Namen annehmen. Für Abteilungen ohne dedizierte Sekretärin verwendeten wir kleine Call Queues mit max 5 Leuten und auch parallel ring. – Voicemail & Ansagen: Teams hat Cloud Voicemail, die wir für individuelle Nutzer belassen haben (jeder hat seine Box). Für die Call Queue definierten wir keine Voicemail, sondern fallback auf eine gemeinsame Mailbox (z.B. „vertrieb@harryhase.de“) die per Exchange/Outlook verteilt wird – realisiert, indem wir als Overflow einer Queue einen Auto Attendant mit Option „Nachricht hinterlassen“ nehmen, die an eine Shared Mailbox geht. War etwas tricky, aber machbar. – Tests: Wir testeten jede erstellte Auto Attendant / Queue-Kombination mit verschiedenen Szenarien: während Geschäftszeit (sollte Queue klingeln), nachhours (sollte Ansage kommen). Feiertagssimulation, Tastendrücke. Ein Problem entdeckten wir: DTMF-Eingaben auf dem Handy wurden anfangs nicht erkannt – lag am Carrier DTMF Setting, wurde korrigiert.

Integration: Contact Center, Fax, Türsprechstellen, Alarmserver: – Contact Center: Wie erwähnt ließen wir die existierende Contact-Center-Lösung (Software XYZ) weiter laufen. Wir integrierten sie so: – Die Contact-Center Agents behielten vorerst ihr Softphone getrennt von Teams. Damit sich interne und externe Gespräche trotzdem verbinden können, richteten wir im SBC eine SIP-Trunk zum CC-Server ein. Alle Anrufe an die Kundenhotline (z.B. 0800-123456) werden vom SBC an das CC geleitet. Interne Weiterleitungen: Ein Agent kann vom CC jemanden in Teams anrufen, indem er in seinem CC-Softphone die volle Durchwahl wählt – der CC-Server sendet an SBC -> Teams. Umgekehrt kann ein Teams-Benutzer einen CC-Agent erreichen indem er dessen interne Nummer wählt, die über SBC ans CC geht. Wir vergaben interne Durchwahlen für die Contact-Center-Agenten (so tun als wären sie interne Nebenstellen, die am SBC registriert sind). – Wir planten, dass in Phase 2 ein neues cloudbasiertes Contact Center eingeführt wird, aber das war außerhalb dieses Projekts. Die getroffene Integration war ein Kompromiss, funktionierte aber. Die Agents merkten von Teams-Einführung kaum was, außer dass sie jetzt die restliche Firma per Kurzwahl direkt erreichen konnten – was sie positiv fanden. – Fax-Strategie: Fax haben wir parallel weiterbetrieben. Der Fax-Server (RightFax) blieb auf einem virtuellen Windows-Server, der über zwei analog/ISDN Leitungen an der alten PBX hing. Diese Leitungen migrierten wir letztlich auf SBC mit ATA: D.h. wir schlossen ein VoIP-Gateway mit 2 analog-Ports an den SBC, der Faxserver bekam virtuelle Modems auf diesen Leitungen. T.38 Protokoll aktivierten wir am SBC. In Tests klappte das Faxen zu 95%. Ein paar exotische Gegenstellen hatten Problem, daher belassen wir noch 1 klassischen Telekomm-Anschluss als Fallback an der Faxlösung (Worst-case). – Langfristig wollen wir Fax durch ein Cloud-Fax ersetzen (was M365 nicht nativ hat, aber es gibt Anbieter), jedoch da einige Kunden der Harry Hase AG beharrlich faxen, musste es weitergehen. – Türsprechstellen: Zwei Werkseingänge hatten SIP-fähige Türsprechstellen (neuere Modelle) und einige ältere analoge. – Die SIP-Modelle konnten wir direkt als SIP-Endpunkt am SBC registrieren. D.h. die Tür wählt intern eine Kurzwahl (z.B. 8010 für Werk1 Eingang), der SBC sieht das und leitet an Teams weiter an eine Call Queue „Werk1-Eingang“, wo das Werkschutz-Team hinterlegt ist. Bei Klingeln poppt dann bei allen Sicherheitsleuten ein Anruf auf „Eingangstor Werk1“. Sie können Audio sprechen, und per DTMF am Telefon den Türöffner steuern (das SIP-Gerät hört auf bestimmte DTMF wie „5“ zum Öffnen – wir testeten das via Teams, es kam durch). – Die analogen Türen hingen an der alten PBX. Für die Übergangszeit ließen wir diese PBX weiterlaufen, nur für die Türen (quasi als ATA-Ersatz). Später wollen wir die auch an ATA hängen, aber diese Modelle waren so alt, dass wir erst Austausch budgetieren (auch Aufgabe nächstes Jahr). – Alarmserver: Es gab einen Alarmserver, der in Notfällen Durchsagen schaltet und Telefone klingeln lässt (Feueralarm-System, das alle Telefone anrufen und Message abspielen konnte). Dieses System war an die alte PBX gekoppelt. In Teams gibt es keine solche Mechanik mit „alle anrufen“. Wir identifizierten das als Problem: Im Notfall möchte man vielleicht eine Durchsage ans ganze Werk per Telefon. – Lösung vorerst: Der Alarmserver bleibt mit der PBX verbunden, und wir lassen die PBX -> SBC -> Teams Integration intakt für diese Funktion. Sprich, wenn Alarmserver „wählt“ alle Durchwahlen, gehen die Signale via PBX->SBC->Teams in die Callqueues der Sicherheitsleute. Realismus: War nicht toll, wir müssen das Konzept überarbeiten. Die Sicherheitsabteilung war aber einverstanden, erstmal die bestehenden analogen Sirenen weiter als Hauptalarm zu nutzen, und das Telefon nur sekundär. Zukünftig denkt man hier an Teams-Automate* (Graph-API, Notification in Teams statt Anruf). Aber das ist ein weiterführendes Thema, das wir offen dokumentiert haben.

Endgeräte-Rollout und Tests: Parallel zur technischen Backend-Implementierung lief der Rollout der Endgeräte an die Nutzer: – Wir verteilten die Headsets etwa 1-2 Wochen vor deren Migrationstermin mit einer kurzen Anleitung „Wie schließe ich es an, wie stelle ich Lautstärke ein“. Viele hatten Teams ja schon genutzt für Meetings, daher war es keine große Sache. – Die Teams-Tischtelefone wurden vom IT-Support in den entsprechenden Büros aufgestellt und per Ethernet angeschlossen. Wir mussten sie im Teams Admin Center als Devices onboarden, oft per generiertem Code: Der Benutzer anmeldet sich mit dem Office 365 Login auf dem Gerät oder scannt einen QR Code via Web. Das machten wir gemeinsam mit den betreffenden Anwendern (z.B. Sekretariat). Auch hier: Firmware-Updates der Geräte spielten wir vorab ein (die Admin Center zeigt ausstehende Updates). – Profile & Zertifikate: Einige Geräte im WLAN (z.B. mobiles Android-Phone) brauchten ein Clientzertifikat für das Enterprise-WLAN. Wir stellten via Intune sicher, dass diese ausgerollt sind, damit Teams-Calls stabil über WLAN gehen ohne ständige Captive-Portals etc. – Für Konferenzraumgeräte richteten wir eigenständige Accounts ein (Raumpostfächer mit Telefonlizenzen) und registrierten die Hardware damit. – Nach Inbetriebnahme machte unser Team stichprobenartige Testanrufe pro Gerät: Insbesondere an der Rezeption testeten wir: kommt ein externer Anruf rein, können wir den auf ein Team-User durchstellen, funktioniert Halten, etc. Bei Konferenztelefone test: Dial-in in ein Meeting, Qualität der Freisprech.

Abnahmetests pro Welle (Checkliste): Für jede Migrationswelle hatten wir eine Test-Checkliste, um vor dem endgültigen Go das System auf Herz und Nieren zu prüfen. Diese Checks wurden von IT-Personal und ausgewählten Key-Usern gemeinsam durchgeführt. Ein typisches Beispiel einer solchen Checkliste:

• Eingehender Anruf (extern -> Teams Nutzer): Ein Testanruf von einem Handy an eine frisch migrierte Durchwahl des Users Mustermann. Erwartet: Teams-App von Herr Mustermann klingelt, er kann abheben, beide Seiten hören sich klar.
• Ausgehender Anruf (Teams Nutzer -> extern): Herr Mustermann ruft eine externe Nummer (z.B. sein Handy) über Teams. Erwartet: Handy klingelt mit Anzeige der richtigen Firmenrufnummer (CLIP). Gespräch kommt zustande.
• Interne Anrufe (Teams -> Teams): Mustermann (migriert) ruft Kollegin Schmitz (ebenfalls migriert) via Kurzwahl oder Teams-Kontakt an. Erwartet: Klingelt bei Schmitz in Teams, Audio okay. Ebenso Test „via Name im Chat anrufen“.
• Interne Alt -> Neu (PBX -> Teams) [nur während Koexistenzphase]: Ein noch nicht migrierter Kollege in einem anderen Werk ruft Herrn Mustermann an, z.B. über alte PBX Telefon mit dessen Durchwahl. Erwartet: Ruf wird über SBC zu Teams geleitet, Mustermanns Teams klingelt. Dieser Test war nur relevant bis alle migriert waren.
• Voicemail-Funktion: Anruf an Mustermann, der nicht abhebt. Nach 20 Sek. sollte die Cloud-Voicemail drangehen. Test Nachricht hinterlassen -> Herr Mustermann erhält in Outlook die Voicemail, Abhören möglich, Transkript optional (wir hatten es aktiviert).
• Weiterleiten und Halten: Herr Mustermann nimmt externes Gespräch an, testet Halten (Gegenstelle hört Wartemusik), dann Weiterleiten an Frau Schmitz. Schmitz soll das Gespräch bekommen. Wir testen sowohl „Blind Transfer“ als auch „Beraten und Weiterleiten“ (Consultative Transfer).
• Anruf parken: (falls wir in dem Bereich es aktivieren) – Einer parkt ein Gespräch, anderer holt es. Dieses Feature nutzten wir nur bei Empfang, dort getestet: Empfang nimmt Anruf an, parkt ihn, kommuniziert Park-Code, anderer wählt Code -> hat Gespräch.
• Gruppenruf / Team Call: Ein Test an eine Nummer, die an eine Call Queue geht (z.B. Vertrieb-Hotline). Wir riefen von extern diese Nummer, alle Mitglieder der Queue sollten Klingeln am PC, jemand nimmt an, funktioniert.
• Delegation/Chef-Sek: Falls in Welle vorhanden, Test: Ein Anruf an Chef geht bei Sekretariat ein, diese nimmt im Namen an, kann an Chef durchstellen. Auch Outgoing call „im Auftrag von“ vom Sekretariat wurde geprobt.
• Notruf (112) Test: Dies ist heikel. Wir haben NICHT tatsächlich 112 angerufen ohne Anlass. Stattdessen haben wir mit der lokalen Leitstelle einen Testanruf abgestimmt: Zu einem bestimmten Termin durften wir testweise 112 wählen und sofort sagen „Testanruf Firma X, alles ok“. Das haben wir einmalig getan vom Teams-Telefon in HQ. Ergebnis: Kam bei der richtigen Leitstelle an, unsere Firmenadresse wurde angezeigt, der Disponent war informiert und zufrieden. Für Standorte wiederholten wir nicht überall, vertrauten aber dem System. Fürs Protokoll notierten wir den erfolgreichen Test. (Hätten wir keine Erlaubnis bekommen, hätten wir es gelassen oder 110 angerufen – aber Vorsicht: Missbrauch Notruf ist strafbar, daher wirklich nur mit Absprache.)
• Fax versenden/empfangen: Falls Teil der Welle (Werk mit Fax), schickten wir ein Fax von extern auf die neue Faxnummer (die über SBC->Faxserver ging) und prüften, ob es ankommt. Und ausgehend ein Fax an ein Testgerät geschickt.
• Tür/Alarm Tests: An einem Standort haben wir die Türsprechanlage gedrückt und geschaut, ob Team-Client klingelt und man Sprechverbindung hat. Alarmserver testeten wir intern (Probealarm um 19 Uhr nach Feierabend – hat geklappt, nur Telefone haben geklingelt und Ansage abgespielt).
• Sondernummern: Test Anrufe an 0800 oder 0180 Nummern, die geroutet werden sollten, Test an 110 (durften wir nicht direkt), Test an interne Kurzwahl (z.B. 7777 Werkschutz – klingelt bei definierter Person).

Jede dieser Checklisten-Punkte wurde abgehakt. Falls etwas nicht funktionierte, No-Go bis gelöst: – In Welle 5 ging z.B. Faxempfang erst nicht – wir entdeckten, dass T.38 auf dem Backup-Trunk deaktiviert war. Fix in Config, dann ging es -> erst dann Welle abgenommen.

Konfigurationsübersicht (Policy/Objekte): In einem so großen Setup half uns eine Tabelle, um Überblick aller erstellten Konfigurationsobjekte und deren Zuständigkeiten zu behalten. Hier ein Auszug:

Dies ist ein Ausschnitt, aber zeigt: Jedes Element (ob in der Cloud oder On-Prem) hat einen Verantwortlichen und definierten Prozess. Wir pflegten diese Übersicht in Confluence, damit auch im Betrieb alle Admins wissen, was wo eingestellt ist und wie es geändert werden darf. Gerade in der hyper-care Phase (ersten Wochen nach Go-Live) war wichtig, dass nicht unkoordiniert an den Settings geschraubt wird, sondern Änderungen gezielt und nachvollziehbar ablaufen.

Nach Abschluss dieser Implementierungsarbeiten und erfolgreichen Tests waren wir bereit, das System in vollem Umfang produktiv zu nehmen. Der nächste Schritt war, die Nutzer darauf zu bringen, sie zu schulen und das System in den Alltag zu überführen, was in den folgenden Kapiteln behandelt wird.

7. Lizenzierung und Kosten

Parallel zur technischen Umsetzung mussten wir sicherstellen, dass alle Lizenzen korrekt bereitgestellt sind und das Kostenmodell wie geplant greift. In diesem Abschnitt erläutere ich die Lizenzmodelle, die wir einsetzen, präsentiere eine Lizenzmatrix nach Nutzerrollen und ziehe eine Kostenbilanz Vorher/Nachher inkl. ROI-Betrachtung über 3 Jahre. Zudem gehe ich auf Verträge mit Carriern und laufende Kosten ein.

Lizenzmodelle Microsoft 365 & Teams Phone: Die Basis für Teams-Telefonie ist die entsprechende Microsoft-Lizenzierung: – Die meisten unserer Mitarbeiter haben Office 365 E3 Lizenzen (oder Microsoft 365 E3 inkl. Windows und EMS). Darin ist Microsoft Teams als Kollaborationsplattform enthalten, jedoch ohne PSTN-Telefonie-Funktion. Um Telefonie freizuschalten, benötigt man entweder eine höhere Suite wie E5 oder ein Add-On. – Wir entschieden uns, den Großteil mit dem Add-On „Teams Phone“ (ehemals Microsoft Phone System Lizenz) zu versorgen. Dieses Add-On kostete etwa 3-4 € pro Nutzer/Monat und ermöglicht den Usern PSTN-Anrufe (in Kombination mit Direct Routing). – Zusätzlich haben wir Audiokonferenz-Lizenzen (Audio Conferencing) für alle Nutzer aktiviert, damit diese auch externe Dial-in-Zugänge zu Teams-Besprechungen nutzen können. Diese waren zu unserem Vorteil inzwischen bei E3/E5 standardmäßig enthalten (Microsoft hatte 2020/21 die Dial-In-Funktion für viele Pläne freigegeben). Sollte das nicht inkludiert sein, hätten wir hier pro User ~1,50 € mtl. kalkulieren müssen. – Einige wenige Power-User (vor allem im Top-Management) hatten bereits Microsoft 365 E5 Lizenzen aus anderen Gründen (Security, Power BI etc.). In E5 ist Teams Phone schon enthalten, d.h. diese benötigten kein Add-On. Wir haben nicht pauschal auf E5 umgestellt, da wie im Business Case gesehen es teurer wäre, nur um Phone zu bekommen. – Für gemeinsam genutzte Telefone (z.B. in Kantinen, Lobbies) gibt es spezielle Lizenzen: die Common Area Phone License. Diese ist günstiger (~6 € monatlich) und beinhaltet nur Telefonie und eine einfache Teams-Funktion für ein Gerät, kein vollwertiges Office. Wir haben etwa 20 solcher Lizenzen für Telefone in Besprechungsräumen und an Empfangsbereichen eingesetzt, statt dort eine volle E3+Phone zu verschwenden. – Für Konferenzraum-Systeme (Teams Rooms) gab es Teams Rooms Pro Lizenzen (~40 € pro Gerät/Monat) oder Basic (für kleine Deployments kostenlos bis 25 Geräte, was bei uns nicht ging da >25). Wir haben 3 Pro-Lizenzen für unsere großen Konferenzräume gekauft. – Drittanbieter-Lizenzen: Der SBC selbst war lizenziert (einmalige Kosten), und unser Contact-Center hat eigene Benutzerlizenzen, die unverändert blieben. Falls wir ein Teams-basiertes Contact Center später nehmen, kämen dort weitere Lizenzkosten, aber im aktuellen Projekt war das out-of-scope.

Lizenzmatrix nach Nutzerrollen: Wir haben die Nutzer in Rollen gruppiert, um passende Lizenzpakete zuzuteilen. Hier eine vereinfachte Darstellung der Lizenzmatrix:

*Anmerkung: Für Empfang haben wir überlegt, ob eine Attendant Console Software sinnvoll ist (ein Tool, das die Vermittlung einfacher macht als der pure Teams-Client). Anbieter wie Landis Attendant oder Luware bieten sowas. Wir entschieden uns zunächst, mit Bordmitteln zu arbeiten (die Empfangsdame hat einen Teams-Telefon mit Seitenwagen oder nutzt die PC-App mit Delegationszugriff). Daher keine Zusatzlizenz im ersten Schritt.

Interpretation der Matrix: – Die meisten Angestellten (Info Worker) nutzen E3 + Phone Addon. Kostenmäßig heißt das pro Person rund 4 € mehr pro Monat als vorher. Da 1800 Personen -> rund 7200 € pro Monat an Microsoft-Kosten neu. (Im Business Case als 96k €/Jahr eingerechnet). – Führungskräfte: Einige hatten E5 schon; wir stockten bewusst ein paar E5 auf (z.B. alle Vorstände). So konnten wir da auf Add-On verzichten, aber E5 ist teurer (ca. +20€ ggü E3). Wir rechnen diese Mehrkosten aber nicht voll dem Telefonieprojekt an, weil E5 aus anderen Budgets kam (Security etc.). – Callcenter-Agenten: Interessant, diese 100 Leute bekamen kein Teams Phone, da sie ja weiterhin die separate Lösung nutzen. Sie behalten E3 nur für Office/Teams-Chat. Somit sparten wir hier Lizenzen. Sollte in Zukunft das Contact Center in Teams integriert werden, müssten wir Phone Lizenzen plus CC-Lizenz für sie einplanen. – Produktion/Werkschutz: Diese 200 Personen haben bisher kein M365, oder nur einen Kiosk/F3 Zugang für z.B. Schichtplanung. Wir haben nicht jedem Produktionsmitarbeiter eine Telefonie-Lizenz gegeben – sie telefonieren ja weiter über DECT/PBX. Einige bekamen aber dennoch Teams-Zugang (F3). Hier war bewusst, dass das Projekt den Umfang an M365-Lizenzen nicht groß erhöht für die Fertigung, um Kosten zu sparen. Etwa Teamleiter hatten E3+Phone, normale Arbeiter nicht. – Devices: Wir trennten Benutzer und Geräte. Für Geräte rechnet man eigen, aber es sind vergleichsweise wenige. Die Common Area Phones für 6 € ersetzen ansonsten eine E3 (kostet ~20€) + Phone (4€), was unwirtschaftlich für ein Gerät ohne Benutzer wäre.

Kostenbilanz Vorher/Nachher pro Nutzer: Um dem Management zu zeigen, dass wir nicht nur Kosten produzieren, haben wir exemplarisch die Kosten pro Nutzer vor und nachher gegenübergestellt: – Vorher (klassische PBX): Hier ist der „pro Nutzer“-Betrag etwas schwer zu greifen, weil viel Infrastruktur geteilt war. Aber wir verteilten die jährlichen PBX-Kosten auf 2000 User: z.B. Wartung 15k + Support 120k + Abschreibung etc. ergibt ~70 €/User/Jahr oder ~5,8 € pro Monat. Plus Gesprächskosten (Durchschnitt vielleicht 3 € pro Nutzer/Monat) -> Summe ~9 € pro Nutzer/Monat. Das ist ein grober Wert. – Nachher (Teams-Telefonie): Pro Nutzer direkt zurechenbar: – Phone System Lizenz 4 €, – Anteilige SBC+Infra: (z.B. 80k über 3 Jahre = 2,2k/Monat /2000 ~1,1 €), – Support/Betrieb 100k/Jahr = 8,3k/Monat /2000 ~4,15 €, – Gesprächskosten 2,8k/Monat /2000 ~1,4 €, -> Summe ~10,7 € pro Nutzer/Monat.

So kam man auf minimal höhere laufende Kosten. Allerdings sind da nun Sachen drin, die vorher nicht pro User gerechnet wurden (etwa Schulung initial, aber langfristig egalisiert). Wir konnten argumentieren, dass in dieser Rechnung mehr Leistungen enthalten sind (z.B. Audio-Conferencing, Cloud PBX Features, die vorher separate Tools erforderten).

Vorher/Nachher Gesamt: Jährlich lagen vorher grob 200k € (inkl. Personal) für die Telefonie an, nachher ca. 230k €. Dieser Delta von ~30k € im Jahr ist im Konzernkontext sehr gering – man kann sagen für ca. 15 € mehr pro User/Jahr erhält man massiv bessere Funktionalität. Zudem sind in der Wirtschaftlichkeitsrechnung die Effizienzgewinne gar nicht monetarisiert: z.B. weniger Aufwand im Moves/Add/Changes, weniger Besprechungsaufwand etc. (Solche Soft-Benefits wurden qualitativ gewürdigt).

Break-Even und ROI (3 Jahre): Durch die initialen Investitionen (Projektkosten, Geräte) war das erste Jahr teurer. Ab Jahr 2 gleichen sich die Kosten, in Jahr 3 sollte es Einsparungen geben, weil keine alte TK-Wartung mehr. Wir rechneten einen Break-Even nach ca. 2,5 Jahren: Bis dahin hat sich die Investition durch eingesparte Wartungsverträge, vermiedene Hardwareerneuerung (die PBX hätte bald Upgrade gebraucht), und leicht niedrigere laufende Personalkosten amortisiert. – ROI-Szenario: In 3 Jahren erwarteten wir rund 100k € kumulierten „Benefit“ (wenn man reduzierte Betriebsaufwände einpreist). ROI = (Ersparnisse – Invest) / Invest. – Invest grob: 270k (150k Projekt + 120k Geräte). – Jährliche Ersparnis ab Jahr 2: ~50k (dank weniger Wartung, Personal). – In 3 Jahren: 50k2 = 100k benefit, ROI = 100/270 ~ 37%. Nicht gigantisch, aber positiv. – Oft fließen qualitative Vorteile in ROI schwer ein. Aber wir zeigten, dass wir zumindest kostendeckend* fahren und strategische Ziele erreichen, was genügte.

Vertrags- und Carrierkosten: – Unser Hauptcarrier bot uns nun einen neuen 3-Jahres-Vertrag für SIP-Trunk an. Darin enthalten: 300 Sprachkanäle (mehr als genug), Rufnummernportierung inkl., Minutenpakete für nationale Flatrate (Festnetz kostenlos, Mobil 0,02€/Min, Ausland je nach Zone). Wir verhandelten, dass dieser Vertrag unterm Strich ähnliche Kosten hat wie vorher die verstreuten Anschlüsse. – Wir bezahlten jetzt allerdings zentral (IT-Budget) für alle Gespräche, während früher teils Standorte eigene Telefonrechnungen hatten. Das Finanzteam wollte deshalb detaillierte Nutzungsreports, um Kosten auf Abteilungen umzulegen falls nötig. Teams bietet Export von Call Records, aber wir entschieden uns, es vorerst nicht umzulegen, da es gering war. Lieber betrachten wir es als Gemeinkosten – auch im Sinne, dass Mitarbeiter nicht mehr auf Minuten schauen sollen, sondern frei kommunizieren (ein Kulturwechsel). – Flatrates vs. Minutenpreise: Wir prüften Flatrate-Angebote. Es gab ein Option: 10€ pro User/Monat für unbegrenzt national + 100 Min mobil. Das wäre für Wenig-Telefonierer teuer. Daher behielten wir Minutenabrechnung. – Für International Calls belassen wir auf Minuten, aber hier hatten wir nur begrenzte berechtigte User, sodass das kontrolliert bleibt. – Redundanzoptionen: Für den Backup-Carrier zahlten wir eine kleine Grundgebühr (z.B. 100€/Monat) plus Minuten falls genutzt. Das ist quasi Versicherung. – Microsoft PSTN Audio Conferencing: ein Punkt der Kosten: Wenn externe Leute sich in eine Telko einwählen via Dial-in, entstehen Einwahlkosten, die Microsoft uns in Rechnung stellt (pro Minute pro Teilnehmer, es sei denn man hat Komflat etc.). In E5/E3 now, es ist teils inkl. Wir richteten die Konferenznummer auf lokal (DE) ein, das war okay. Falls viel genutzt, hätte Microsoft Calling Credits gekauft werden müssen. Aber in unseren Stats war das minimal (die meisten nutzen PC-Audio, weil alle haben Teams-App).

Insgesamt konnten wir mit der neuen Telefonielösung das Kostenbudget einhalten. Während die einzelnen Kostenstellen sich veränderten (mehr an Microsoft, weniger an alte Verträge), blieb die Gesamtlast vergleichbar und eher leicht steigend, aber mit signifikant höherem Gegenwert. Wichtig war, dies im Controlling weiter zu beobachten. Unser Reporting an den CFO nach 6 Monaten soll zeigen, ob unsere Prognosen zutrafen – ich bin aber zuversichtlich, da keine großen Ausreißer erkennbar sind.

Abschließend war es beruhigend festzustellen, dass die wirtschaftliche Betrachtung keine bösen Überraschungen brachte. Damit war der Weg frei, sich auf Betrieb, Qualität und Nutzen zu konzentrieren, statt auf Rechtfertigung der Kosten.

8. Qualität, Betrieb und Monitoring

Nach Inbetriebnahme der Teams-Telefonie stand die Sicherstellung eines stabilen Betriebs und hoher Gesprächsqualität im Fokus. In diesem Kapitel beschreibe ich unser Qualitätsmanagement (Monitoring-Tools, KPIs), das Betriebs- und Supportmodell mit Verantwortlichkeiten, sowie Prozesse für Änderungen und Störungen. Zudem liste ich wichtige KPIs und Schwellenwerte auf, die wir vereinbart haben, um die Servicequalität zu messen und Probleme früh zu erkennen.

Qualitätsmanagement und Monitoring: Um die Sprachqualität und Zuverlässigkeit im Blick zu behalten, nutzen wir eine Kombination aus Microsoft-Tools und eigenen Maßnahmen: – Call Quality Dashboard (CQD): Microsoft bietet das CQD, ein umfangreiches Analytics-Tool speziell für Teams-Anrufe und -Meetings. Wir haben direkt nach Rollout einen Baseline-Report eingerichtet: Er zeigt uns monatlich Kennzahlen wie durchschnittliche MOS (Mean Opinion Score) für alle Anrufe, Prozent der Anrufe mit hoher Jitter/Loss, etc. Unsere Zielvorgabe war ein MOS >= 4,0 (von 5) im Schnitt. Das CQD zeigt z.B., wenn bestimmte Standorte oder Geräte häufig schlechte Werte haben. In den ersten Wochen sahen wir beispielsweise, dass einige Homeoffices sporadisch MOS um 3,0 hatten – das konnten wir auf WLAN-Probleme zurückführen. Insgesamt lag der Durchschnitt bei 4,3, was gut ist (5,0 wäre optimal ohne jegliche Qualitätsbeeinträchtigung). – Realtime Monitoring: Für kritische Dienste haben wir ein eigenes Monitoring (PRTG) angebunden: – Der SBC sendet SNMP-Traps bei Problemen (z.B. Trunk down). Unsere Monitoring-Software generiert dann Alerts per E-Mail/Teams-Nachricht an die Admins. – Wir nutzen auch synthetische Tests: Einmal stündlich initiiert ein Skript einen Testcall über den SBC (von einer Test-DID zu einer anderen, die sofort auf Voicemail geht). Der SBC registriert Erfolg/Misserfolg. So merken wir z.B. wenn ein Trunk nicht funktioniert. – Microsoft hat außerdem den Rate My Call Feedback-Mechanismus (User kann nach Call Daumen hoch/runter geben). Wir ermunterten Nutzer, das bei Problemen zu tun; diese Feedbacks sieht man im CQD qualitativ, aber nicht jeder nutzt es. – Proaktives Monitoring & Alerting: Wir haben Schwellwerte definiert (siehe unten KPIs). Wenn z.B. an einem Tag >5% der Anrufe „Poor“ quality melden, schlägt das Monitoring Alarm, und unser Team untersucht (vielleicht ein Netzwerkproblem?). Ebenso haben wir in SBC Logs Filter, die nach bestimmten Fehlercodes schauen (503 from carrier etc.), wenn da zu viele in kurzer Zeit, Alarm. – Quartalsreviews: Alle paar Monate setzen wir uns mit Netzwerk- und IT-Leitung zusammen, um die Qualitätsreports durchzugehen. Gibt es Trends, z.B. zunehmende Latenz? Das könnte auf wachsende Bandbreitenauslastung hindeuten und wir würden früh gegensteuern (Upgrade Internet oder QoS anpassen). Bisher war aber alles im Lot.

Betriebs- und Supportmodell: Wir definierten klar, wie der Support für die neue Telefonie abläuft: – 1st Level (Helpdesk): Der zentrale IT-Helpdesk fungiert als Single Point of Contact für Anwender. Wir haben die Helpdesk-Mitarbeiter in einer Schulung auf die häufigsten Fragen vorbereitet (wie „ich höre nichts – check Audio-Settings“, „wie setze ich Rufumleitung“ etc.). Der Helpdesk kann einfache Probleme lösen: falsches Gerät ausgewählt im Teams, Passwortreset, oder Usage-Fragen. Sie haben auch ein Skript, um grundlegende Diagnosen zu machen (z.B. „Internet ok? Anderer Teilnehmer betroffen?“). – 2nd Level (UC-Team): Komplexere Fälle oder systemische Probleme landen beim Unified Communications Team (das sind quasi das TK/Netz Team, 2-3 Leute speziell für Telefonie und Meetings). Die UC-Leute haben Admin-Zugriff auf Teams und SBC und schauen sich dann z.B. konkrete Call-IDs im CQD an, prüfen SBC-Logs, etc. Sie können Konfigurationsprobleme beheben (z.B. ein User hat keine Nummer zugewiesen – oft Grund, warum er nicht raustelefonieren kann). – 3rd Level (External): Wenn das Problem tiefer geht, haben wir zwei Pfade: 1. Microsoft Support via Premier Support Ticket – z.B. wenn wir vermuten, es liegt ein Teams-Service-Problem vor (kam zum Glück nicht vor, außer ein globaler Ausfall, wo eh bekannt war). 2. SBC/Carrier Support: Wir haben Wartungsverträge mit dem SBC-Hersteller (Audiocodes) via Partner. Bei SIP-Protokollproblemen oder unklaren Fehlermeldungen können wir dort Tickets einstellen. Ebenso hat unser Carrier einen 24/7 Support; falls Leitungsstörungen sind, ruft das UC-Team dort an. – SLA/OLA: Wir haben interne Service Level Agreements definiert: – Wichtigste: Verfügbarkeit der Telefonie mindestens 99,9% per Monat. Das entspricht max ~45 min Ausfall/Monat. Microsoft Cloud an sich hat 99.99% zugesagt, unser eigenes System hoffentlich auch. Wir tracken echte Ausfälle (gab z.B. mal 10 min Provider-Störung, floss in KPI ein, aber blieb innerhalb Limit). – Reaktionszeit auf Incidents: Helpdesk sofort (Calls werden ja live angenommen bei Störung), 2nd Level innerhalb 30 min engagiert bei P1 Issues. Für normale Tickets: 1 BD Reaktionszeit. – Entstörzeit (MTTR): z.B. kritische Störung (keiner kann telefonieren) < 4 Stunden Ziel, moderate Störung (einzelner Standort Qualitätsprobleme) < 8 Stunden, Einzelfall < 2 Tage. – Obergrenzen: Wir haben mit dem Provider ein OLA, dass er uns bei Ausfall in max 1h zumindest Diagnose gibt, fix <4h (das haben wir nicht in der Hand, aber im Vertrag steht 4h für schwere Fehler). – Diese SLAs wurden in einem internen Service Level Document festgehalten, dem IT-Management und – wichtig – auch dem Betriebsrat (für IT-Bereitschaftszeiten, die haben zugestimmt, dass im Notfall auch mal nach Feierabend jemand eingreifen darf, weil Notruf-sensitiv). – Major Incident Process: Wir haben festgelegt, wie vorzugehen ist, wenn eine großflächige Störung auftritt: – Definition P1 Incident: z.B. „Telefonie am ganzen Standort X tot“ oder „Keine ausgehenden Anrufe weltweit möglich“ oder „Notrufe funktionieren nicht“. – In so einem Fall wird sofort ein Bridge-Call mit allen relevanten aufgemacht (UC-Team, Netzwerk, Security falls betroffen, etc.). Kommunikationswege: IT schickt innerhalb 30 min eine Info an alle Nutzer (z.B. E-Mail oder Teams Post) „Wir haben eine Störung, nutzen Sie solange Handy“. – Der Major Incident Manager (meist aus IT Service Management Team) koordiniert, hält Kontakt zum Provider/Microsoft. – Nach Lösung wird ein Post-Mortem erstellt, um zu lernen. Wir hatten zum Glück noch keinen P1, nur mal P2 (z.B. Anrufe nach extern kurz gestört).

Änderungsmanagement: Nach Projektende ging die Verantwortung ins Betriebsteam über, und damit auch Änderungen am System dem normalen Change Process unterworfen: – Change Requests: Jede Änderung an der Telefonie-Konfiguration (z.B. neue Auto Attendant Ansage, Policy-Änderung, Firmware-Update SBC) wird als Change Request erfasst. Wir kategorisieren nach Impact: – Standard Changes (routinemäßig, keine Ausfallrisiko: z.B. neuer User Nummer zuweisen) – die kann der UC-Admin sofort machen, loggt aber dennoch. – Normal Changes (moderates Risiko: z.B. Teams Policy ändern, SBC Update) – geht durch ein CAB (Change Advisory Board) Meeting, wo Impact geprüft und Zeitfenster genehmigt wird. – Emergency Changes (z.B. Workaround bei Störung: sofort, nachträgliche Genehmigung). – Wartungsfenster: Wir legten ein wöchentliches Wartungsfenster Freitag nachts 22-24 Uhr, in dem planmäßige Arbeiten stattfinden können. Bisher selten genutzt (z.B. Firmware-Update der SBCs haben wir in so einem Fenster gemacht; das ging ohne merkliche Unterbrechung wegen HA). – Dokumentation & Knowledge Management: Alle Konfigurationsänderungen werden im Betriebshandbuch nachgeführt. Wir halten z.B. fest: „24.10.: Dial Plan Rule XY hinzugefügt, genehmigt durch CAB #123“. So kann in zwei Jahren nachvollzogen werden, was modifiziert wurde. – Außerdem pflegt das Team eine FAQ-Liste von gelösten Problemen, um bei Wiederauftreten schnell reagieren zu können. Z.B. „If user cannot be reached from PSTN, check if LineURI has + sign“ (ein typischer Fehler, wenn man vergisst +). Diese Knowledge Base ist intern veröffentlicht.

KPIs (Key Performance Indicators): Wir haben einige Kern-KPIs definiert, um den Service zu messen: – Durchschnittlicher MOS-Wert: Ziel >= 4,0. – Prozent Anrufe mit Qualitätsproblemen: Ziel < 5% der Calls haben irgendein Poor-Flag (hoher Jitter, Packet Loss etc.). – Anrufaufbauzeit (Signalisierungszeit): Wir messen, wie lange es dauert von „Wählen“ bis „Klingeln beim Ziel“. In Teams ist das meist 1-2 Sekunden, wir setzen Schwelle 5 Sekunden. Sollten >95% der Anrufe innerhalb 5s verbinden. – Abbruchrate (Call Drop Rate): Anteil der Verbindungen, die ungewollt abbrechen (nicht vom Nutzer beendet). Ziel < 1%. (In PSTN war traditionell <0,5%. Bisher sehen wir kaum Drops außer wenn Handy-Empfänger im Funkloch). – Erfolgreiche Notruf-Testcalls: 100% (wir führen mind. alle 6 Monate einen Testcall 112 oder interne Notfallübung durch – muss immer klappen). – Ticket-Volumen und MTTR: Wie viele Telefonie-bezogene Tickets/Incidents pro Monat und die Durchschnittliche Lösungszeit. Ziel: z.B. <= 10 Tickets/Monat nach Stabilisierung, und MTTR < 8h für normale Tickets, <4h für P1. – Nutzerzufriedenheit: Via regelmäßige Umfrage in IT-Zufriedenheitsumfrage: „Zufriedenheit mit Telefonie“ sollte besser oder gleich dem alten System sein. Erste Umfrage ergab Note 1,8 (alt war 2,5), also gut. – Verfügbarkeitszeit: gemessen als kein Totalausfall pro Monat >15 Min. Bisher hatten wir Verfügbarkeit ~99.95% (nur kleine Unterbrechung: mal 5 Min Teams Cloud Issue).

Wir erstellten eine Tabelle mit KPIs, Zielwerten, Schwellwerten, Maßnahmen:

Diese KPIs wurden im monatlichen Service Report dokumentiert und bei Überschreitungen haben wir tatsächlich Maßnahmen ergriffen: – Im November gab es z.B. mal eine Call Drop Rate von 1.2%. Wir stellten fest, das hing mit mobilen Teilnehmern zusammen, nichts internes. Trotzdem verstärkten wir Benutzerinfos (z.B. „WLAN im Homeoffice optimieren“). – Ticket-Volumen war am Anfang >30 (im Hypercare normal). Nach 3 Monaten sank es auf ~5/Mo. – Insgesamt blieben wir innerhalb Ziele, sodass keine größeren Eskalationen nötig waren.

Zusammenfassend haben wir ein robustes Betriebsgerüst aufgebaut: Monitoring, klare Prozesse, definierte KPIs. Dies stellt sicher, dass das Telefoniesystem nicht nur eingeführt ist, sondern auch langfristig zuverlässig und in hoher Qualität läuft. Die Vorarbeit in Architektur und Tests zahlte sich hier aus, da wir einen weitgehend störungsfreien Betrieb erleben. Aber wir ruhen uns nicht aus – die Kennzahlen werden weiterhin beobachtet, und das System kontinuierlich nachjustiert, um die Qualität hochzuhalten.

9. Sicherheit

Die Sicherheit der neuen Telefonielösung hatte oberste Priorität, da nun Sprachkommunikation über das Datennetz und die Cloud läuft. In diesem Kapitel erläutere ich die Maßnahmen zur Identitätssicherheit, Gerätesicherheit, SBC-Härtung und weitere Security Controls, die wir implementiert haben. Eine Checkliste fasst die wichtigsten Sicherheitsvorkehrungen zusammen.

Identitätssicherheit (MFA, Conditional Access, risikobasiert): Jeder Benutzer authentifiziert sich in Teams mit seiner Firmenidentität. Deshalb haben wir die Konto-Sicherheit konsequent verstärkt: – Multi-Faktor-Authentifizierung (MFA): Bereits vor der Telefonieeinführung hatten wir für alle Benutzer MFA (per Authenticator-App oder Telefon) verpflichtend. Somit ist die Wahrscheinlichkeit, dass ein Account gehackt wird, deutlich reduziert. Speziell für Telefonie relevant: Ein kompromittierter Account könnte theoretisch genutzt werden, um über unser System teure Anrufe zu tätigen (Toll Fraud) oder auf interne Konferenzen zuzugreifen. MFA schützt davor, da ein Angreifer mit Passwort allein nichts anfangen kann. – Conditional Access (CA) Policies: Wir haben mehrere CA-Richtlinien, die auch Teams/VoIP einschließen: – Nur vertrauenswürdige Geräte dürfen sich mit Teams anmelden. „Vertrauenswürdig“ heißt im unserem Fall entweder Domänenmitglied (Firmen-PC) oder compliant via Intune (Firmen-Handy mit MDM) oder per App Protection (bei BYOD Smartphones). Somit verhindern wir, dass jemand einfach mit irgendeinem privaten PC und geleaktem Passwort auf die Telefonie zugreift. (Ausnahme: Für reine Web-Zugriff ohne VoIP war anders geregelt, aber Telefonie erfordert den vollwertigen Client). – Lokationsbezogene CA: Admin-Logins durften nur aus Deutschland erfolgen (bzw. definierte Länder), aber für normale Benutzer, die ja weltweit reisen, haben wir stattdessen risikobasiert gearbeitet: Wenn ein Log-in aus ungewöhnlichem Ort erfolgt, schlägt Azure AD Risk detection Alarm. In solchen Fällen wird ein Passwort-Reset erzwungen und unser Security-Team informiert. So passiert, als ein Mitarbeiteraccount aus Asien anrief, der eigentlich nie dort war – es stellte sich als legitime Reise heraus, aber wir haben verifiziert. – Least Privilege & Role Separation: Nur sehr wenige Admins haben Zugriff auf Telefonie-Konfiguration. Diese Admin-Accounts sind nochmals per Hardware-MFA geschützt und verwenden Privileged Access Workstation (harter Sicherheitsstandard). So minimieren wir die Gefahr, dass jemand interne Telefondaten manipuliert oder abhört. – Sperren bei Anomalien: Wir haben ein Skript, das bei auffälligem Telefonieverhalten (z.B. ein Account ruft >50 internationale Nummern in 5 Minuten) den Benutzer automatisch temporär blockt und einen Admin alarmiert. Das ist ein Schutz gegen automatisierte Missbrauchsfälle, falls doch ein Account kompromittiert würde.

Gerätesicherheit (Teams-Telefone, Zertifikate, Firmware): Die Endgeräte selbst müssen sicher sein, da sie potenzielle Einfallstore sind: – Teams-Tischtelefone: Diese laufen auf Android oder Windows IoT je nach Modell. Wir registrierten alle im Teams Admin Center, was uns erlaubte, zentral die Firmware-Updates auszurollen und Einstellungen zu verwalten (z.B. kein freier Zugriff auf Einstellungen am Gerät für Benutzer). Jedes Gerät ist per PIN geschützt (so dass ein Fremder nicht einfach das angemeldete Gerät bedienen kann, z.B. wenn im Empfangsbereich keiner da ist). – Intune MDM/MAM: Firmen-Smartphones mit Teams unterliegen den bestehenden MDM-Richtlinien: PIN erzwungen, Gerät verschlüsselt. Für BYOD nutzen wir App Protection (MAM), sodass Teams-App auf privaten Geräten einen PIN erfordert und keine Daten nach außen speichert. So ist sichergestellt, dass z.B. Voicemail-Inhalte oder Adressbuch nicht unkontrolliert abfließen. – Zertifikatsverwaltung: Wir nutzen Zertifikate vor allem für die SBC und WiFi-Zugänge. Auf Geräteebene: Die Konferenzraum-Systeme und Desk Phones haben Zertifikate für 802.1x Netz-Auth. Unsere PKI muss diese Zertifikate verwalten, inkl. Sperrlisten. Das war bereits Standard im Netz, nun zogen wir die Telefone nach. – Geräteinventar und Logging: Alle Geräte loggen in unsere Syslog/Monitoring-Umgebung sicherheitsrelevante Events. Z.B. wenn bei einem Desk Phone 5x falsches Passwort eingegeben wird (was bedeuten könnte, jemand probiert zu entsperren), bekommt SecOps ne Info. Bisher nie passiert, aber wir haben den Mechanismus. – Keine Hintertüren: In der alten PBX-Welt gab es oft generische Admin-Accounts oder Standard-PINs für VoiceMail. Bei Teams entfallen die meisten, aber z.B. jede Voicemail kann via Exchange administriert werden. Wir stellten sicher, dass Standard-PINs initial geändert werden mussten vom User. Auch generische Gast-Accounts fürs Telefonbuch o.ä. gibt es nicht mehr, alles personalisiert – was sicherer ist. – Virus/Malware-Schutz: Auf PCs natürlich vorhanden. Relevanz: Öffnet jemand einen Voicemail-Anhang aus Exchange, wird der ohnehin vom Defender Antivirus geprüft.

SBC-Härtung: Der SBC ist ein kritisches System, er steht teils exponiert im Netz, daher haben wir umfangreiche Hardening-Schritte durchgeführt: – Zugangsbeschränkung: Management-Zugriff auf den SBC (Web-GUI, SSH) ist nur aus dem internen Admin-Netz erlaubt, nicht von außen. Selbst intern ist es IP-Restricted auf Admin-PCs. Standard-Ports wurden teils geändert um Scans zu erschweren. Natürlich sind Admin-Accounts mit starken Passwörtern versehen, und wir loggen Admin-Logins. – Firewalling und ACLs: Auf dem SBC haben wir eine Access Control List konfiguriert: Er akzeptiert SIP Traffic nur von 1) Microsoft Teams Cloud IP-Ranges (haben wir konkret eingetragen, Microsoft veröffentlicht diese Listen), 2) vom Carrier SBC IP 3) vom internen PBX/CC Systeme. Alles andere wird gedroppt. Somit können externe Angreifer nicht einfach SIP-Requests schicken. Unsere Firewall außen blockt das meiste ohnehin, aber defense-in-depth. – TLS und Verschlüsselung: Wir erlaubten nur moderne Cipher Suites, TLS 1.2 (Teams fordert das sowieso) und haben Perfect Forward Secrecy aktiviert. Das Zertifikat hat 2048-bit Schlüssel. Wir überwachen das Ablaufdatum; im Monitoring ist hinterlegt, 30 Tage vor Ablauf Alarm, damit wir es erneuern. SRTP wie erwähnt an, kein Fallback auf RTP. – Updates: Wir halten den SBC immer auf dem aktuellen Patchstand. Das ist wichtig, da SIP-Software gelegentlich Sicherheitslücken (Buffer Overflows etc.) haben kann. Wir haben einen Wartungsvertrag, der uns Security Bulletins schickt. Einmal im Quartal prüfen wir, ob Updates nötig sind. In den ersten 6 Monaten gab es ein Minor Update, das wir eingespielt haben. – DDoS/Flood-Schutz: Wir aktivierten die SBC-interne DOS Protection: Sie erkennt z.B. wenn in sehr kurzer Zeit extrem viele Invite oder Register kommen (pattern typisch für Angriff), und blockt die IP temporär. Zudem Rate-Limiting: ein Endgerät darf nur X Calls/sec initiieren. Das schützt sowohl vor externen Attacken als auch vor Fehlkonfiguration, die Schleifen erzeugt. – Logging: Alle SIP Anmeldungen, Fehler etc. werden vom SBC weggeschrieben und ans zentrale Logging-System weitergeleitet. So könnten wir im Nachhinein nachvollziehen, falls was Komisches passiert (z.B. versuchte Registrierung von unbekannt -> hatten wir mal durch Pentest simuliert).

Zusätzlich haben wir mit unserem Security Operations Center (SOC) besprochen, dass sie auf bestimmte Muster achten: – Z.B. wenn in Firewall-Logs auftaucht, dass von einer internen IP massenhaft externe Telefonnummern angerufen werden, es aber nicht über Teams geht (vielleicht Malware, die VoIP macht), dann Alarm. – Oder wenn ungewöhnliche Zugriffsmuster auf Teams APIs. Hier ist es etwas schwierig, aber Microsoft Cloud App Security hilft, anormales Verhalten zu flaggen.

Security-Checkliste (Telefonie-Workloads): Wir führten eine abschließende Sicherheits-Checkliste, um nichts zu vergessen: – ✅ MFA aktiviert für alle User (überprüft mittels Azure AD report). – ✅ Conditional Access Policy ‚Require Compliant device for Teams‘ aktiv (geprüft). – ✅ Administrative Rollen aufgeteilt und minimal (Team-Admin ohne Global Admin wo möglich, geprüft). – ✅ SBC Zugriffe beschränkt (FW, ACL), getestet mit Portscan – reagiert nicht. – ✅ Signaling und Media verschlüsselt (TLS/SRTP), geprüft via Wireshark (nur Ciphertext erkennbar). – ✅ Notruf-Szenario sicher (Leitstellen erhalten Standort, Notfalltelefone analog vorhanden). – ✅ Backup-PSTN bei Ausfall (Alternate route definieren), eingerichtet. – ✅ Keine Default Credentials (SBC, ATAs, Teams Phones Adminpasswort geändert). – ✅ Logging & Auditing aktiv: Audit-Logs in O365 (z.B. wer ändert Policies) sind eingeschaltet. SBC Syslogs gehen ans SIEM. – ✅ User Awareness: Nutzer geschult, keine sensiblen Gespräche via unsicheres Netz ohne VPN etc. (z.B. falls sie via unsicheren WLAN telefonieren, empfohlen, Firmen-VPN oder mobile Netz). – ✅ Test Pentest/Angriff: Wir ließen einen internen Pentest auf die VoIP-Umgebung durchführen. Ergebnis: keine kritischen Lücken gefunden; lediglich empfohlen, die SIP Options am SBC nicht zu viel Infos preisgeben (haben wir anonymisiert).

Ein Punkt der Sicherheit ist auch Datenschutz (in 3. Kapitel behandelt). Wir greifen z.B. nicht inhaltlich auf Gespräche zu. Abhören ist technisch nur via Drittsoftware möglich, die wir nicht einsetzen. Das war dem Betriebsrat wichtig. Also keine „Lust, mal mitzulauschen“ – selbst Admins können das nicht, außer man würde gezielt eine Compliance-Lösung einsetzen.

Insgesamt haben wir das Sicherheitsniveau der Telefonie damit deutlich höher als beim alten System: – Die alte PBX hatte z.B. viele unverschlüsselte Verbindungen (insb. DECT, analoge Leitungen), jeder mit Zugriff auf die Verkabelung hätte mitschneiden können. Jetzt ist fast alles IP und verschlüsselt. – Das größte Restrisiko bleibt der Benutzer selbst (z.B. jemand schreibt seine PIN ans Telefon). Aber durch MFA und Aufklärung minimieren wir auch hier die Angriffsfläche.

So können wir mit gutem Gewissen sagen, dass die Teams-Telefonie nicht nur funktional, sondern auch sicher und compliant betrieben wird, was für die IT-Sicherheit und das Vertrauen aller Stakeholder essenziell war.

10. Change Management, Kommunikation und Schulung

Eine der wichtigsten Erfolgsfaktoren für das Projekt war das Change Management – die Nutzer auf die Reise mitzunehmen, Ängste abzubauen und sie fit für die neue Technologie zu machen. In diesem Kapitel schildere ich, wie wir die verschiedenen Zielgruppen identifiziert und adressiert haben, welche Schulungsmaßnahmen durchgeführt wurden, und wie wir insgesamt für Akzeptanz gesorgt haben. Zudem beschreibe ich unseren Kommunikationsplan und die Methoden zur Erfolgsmessung in Sachen Nutzeradoption.

Zielgruppen und Lernpfade: In einem Unternehmen mit 4.000 Mitarbeitenden gibt es sehr unterschiedliche Nutzergruppen, die wir jeweils passend ansprechen mussten: – Informationsarbeiter (Office User): Die größte Gruppe (ca. 2.000 Personen) – für sie ändert sich das meiste, da sie vom klassischen Telefon auf Teams umsteigen. Hier lag unser Fokus auf grundlegender Bedienung (Anrufen, Annehmen, Weiterleiten, Voicemail abhören) und dem Nutzen der neuen Möglichkeiten (z.B. per Name suchen statt Nummern, Mobil-App). – Assistenzpersonal (Sekretariate, Teamassistenzen): Diese Gruppe (~30 Personen) hat spezielle Anforderungen wie Chef-Vertretung, mehrere Leitungen managen. Ihr Lernpfad war intensiver im Bereich Delegation, Gruppenanrufe, Besetztanzeige (bzw. Statusanzeige in Teams). Wir boten ihnen separate Schulungen an, da ihre Fragen sehr zielgruppenspezifisch waren. – Hotline/Disposition/Callcenter: Die Agents im formellen Contact Center behielten zwar vorerst ihr altes System, aber wir schulten sie trotzdem in Grundfunktionen von Teams, weil interne Kommunikation mit Kollegen ja nun über Teams-Call gehen kann. Zudem wollten einige neu auch Teams nutzen, z.B. interaktive Besprechungen. Diese Gruppe (ca. 100 Leute) bekam einen eigenen Track „Teams für Service-Agents“, bei dem klar gemacht wurde, was sich für sie ändert und was (noch) nicht. – Empfang/Telefonzentrale: Die Empfangsmitarbeiter (5 Personen) mussten lernen, mit dem Teams-Telefon und Softclient eingehende Anrufe zu verteilen. Für sie erstellten wir einen Leitfaden Telefonvermittlung in Teams, der Dinge abdeckt wie: Anruf parken, Transfers, Nachfragen, Umgang mit dem Auto Attendant Admin-Interface (z.B. Feiertage einstellen). – Management: Die Geschäftsleitung und mittleres Management (~50 Personen) haben oft wenig Zeit und hohe Ansprüche. Wir haben ihnen sehr komprimierte Sessions angeboten (30 Minuten „Executive Briefing“), in denen die Assistenten oft dabei waren. Schwerpunkt: Vorteile der Mobilität (z.B. „Sie können nun mit Ihrem iPad aus dem Ausland mit deutscher Nummer anrufen, Herr Vorstand!“), und wie sie mit ihren Assistenten zusammenarbeiten (Delegation). – Produktion/Werkschutz: Die Mehrheit hier blieb auf der alten Telefonie, aber einige (z.B. Schichtleiter, Werkleiter, Sicherheitschef) bekamen ebenfalls Teams Phone. Außerdem mussten auch jene ohne Teams-Verbindung wissen, dass Kollegen künftig anders telefonieren. Für die Produktion haben wir Flyer und kurze Infoblätter gemacht: „Was ändert sich für Sie? – Ihre Ansprechpartner in Büro sind evtl. nur noch mobil via Teams erreichbar; es gibt neue Notfallhinweise…“. Für Werkschutz gab es separate Unterweisung, da sie mit dem Notrufsystem und Türsprechanlagen in Teams interagieren.

Schulungsformate: Wir haben einen bunten Mix an Trainingsmethoden eingesetzt, um alle zu erreichen: – E-Learning (Video-Tutorials): Wir produzierten mehrere kurze Videos (3-5 Minuten) auf Deutsch, die die Kernfunktionen zeigen: „Mit Teams telefonieren – die Basics“, „Weiterleiten und Halten“, „Voicemail nutzen“, etc. Diese stellten wir im Intranet bereit (viele schauten es an, weil es schön on-demand war). – Zusätzlich verwiesen wir auf Microsofts offizielle Support-Seiten (die sehr gute Artikel/Videos haben), jedoch haben wir eigene Doku bevorzugt, da wir firmeninterne Besonderheiten einbauen konnten (z.B. welche Nummer bei Störung anrufen). – Live-Schulungen (Webinare): Gerade zum Rollout in einer neuen Welle gab es in der Woche vorher Live-Sessions via Teams-Meeting, wo ein Trainer (ich oder ein Kollege) die Funktionen demonstriert hat und Fragen beantwortete. Pro Standort 2 Termine, damit möglichst viele teilnehmen konnten. Diese waren sehr interaktiv – wir bekamen viele Fragen („Wie mache ich Konferenz mit extern?“ etc.), die wir klärten. Wir haben die Webinare aufgezeichnet für Nachzügler. – Präsenz-Workshops: Für Assistenz und Empfangs-MA haben wir kleine Workshops vor Ort gemacht. In einem Schulungsraum mit PCs oder deren eigenen Laptops übten wir praktisch: Chefs haben sich testweise anrufen lassen, Szenarien durchgespielt. Diese persönlichen Sessions (mit 5-10 Teilnehmern) waren zeitaufwändig, aber enorm wertvoll, da genau diese Multiplikatoren dann später im Alltag sehr fit waren. – Floorwalker und Hotlines: In den ersten Tagen nach Umstellung liefen sogenannte Floorwalker (geschulte IT/Champion-Mitarbeiter mit erkennbarem T-Shirt) durch die Büros, sprachen proaktiv Nutzer an („Alles ok mit Teams-Telefonie? Brauchen Sie Hilfe?“). Viele Probleme konnten so unmittelbar gelöst oder abgemildert werden. Wir richteten auch eine spezielle Telefon-Hotline ein (lustigerweise selbst auf Teams), wo Benutzer anrufen konnten bei Fragen. Diese wurde vor allem in Woche 1 gut genutzt. – Champions-Programm: Wir hatten schon für Microsoft 365 an sich ein Champions-Netzwerk – etwa 1-2 tech-affine Nutzer je Abteilung, die Kollegen unterstützen. Diese Champions wurden vorab auf Telefonie geschult (Beta-Tester im Pilot etc.), sodass in jeder Abteilung quasi ein „Local Expert“ verfügbar war. Das hat die Support-Last massiv reduziert und zugleich Akzeptanz gefördert (Kollegen hören oft lieber auf Kollegen als auf IT). – Gamification/Challenges: Wir haben kleine Challenges gemacht wie „Erster Anruf mit Teams – so geht’s: probieren Sie es heute aus, rufen Sie einen Kollegen über Teams an und gewinnen Sie …“. Gewinnspiel-Preise waren z.B. 5 neue High-End-Headsets. Das motivierte vor allem zögerliche Benutzer einfach mal zu probieren.

Kommunikationspaket: Kommunikation begleitete das Projekt von Anfang an: – Early Announcements: Schon nach Freigabe des Business Case haben wir im internen Newsletter einen Vorab-Artikel gebracht: „Telefonie der Zukunft – Harry Hase AG stellt um auf Microsoft Teams“. Darin grob das Warum und Wann, um die Belegschaft einzustimmen und Gerüchte zu reduzieren. – Zielgruppen-spezifische Infos: Kurz vor der Umstellung ihrer Welle bekamen Mitarbeiter eine E-Mail mit allen wichtigen Details („Ab nächster Woche telefonieren Sie mit Teams. Was bedeutet das?“). Diese E-Mail war knapp, bulletpoints: – Ihr neues Gerät: Headset XY, bitte anschließen. – Ihr Teams-Client: sollte aktuell sein; Anleitung anbei. – Ihre Nummer bleibt (oder neue Nummer XY). – Was ändert sich: kein physisches Telefon (sofern entfallen), Telefonieren nun über PC/Handy. – Wo Hilfe: Link zum Intranet und Support-Kontakte. – Nutzenargumentation: In der Kommunikation betonten wir Nutzen: z.B. „Nie mehr Anruf auf dem Tischtelefon verpassen, wenn Sie gerade im Homeoffice sind – Teams klingelt überall bei Ihnen.“ Oder „Einfach per Klick aus einem Chat jemanden anrufen“. Auch: „Weniger Geräte auf dem Schreibtisch, mehr Platz“. – Kurzanleitungen & Guides: Wir haben One-Pager erstellt (mit Screenshots), z.B. „Teams-Telefonie – Die 5 wichtigsten Tipps“. Die verteilten wir per Mail und gedruckt an schwarzen Brettern, insbesondere in Gemeinschaftsbereichen. Im Intranet gab es eine ganze Seite „Projekt Teams Telefonie“ mit FAQ. – Einbeziehen von Führungskräften: Die Bereichsleiter wurden gebrieft und baten wir, das Thema in ihren Teams positiv zu vermitteln. Einige Manager, die es früh hatten, gaben Statements wie „Ich war überrascht, wie gut das funktioniert – selbst unterwegs top Qualität.“ Solche Zitate flossen in Follow-Up Artikel. – Feedback-Kanal: Wir richteten ein Team „Telefonie-Feedback“ in Teams ein, offen für alle. Dort konnten Nutzer Erfahrungen teilen und Fragen posten. Wir (IT) moderierten, aber oft halfen sich die Nutzer gegenseitig („Bei mir half es, den Audio-Treiber neu zu installieren…“). Das war auch Teil der Kommunikationsoffensive, um das Thema präsent zu halten und eine Community entstehen zu lassen.

Schulungsplan (Tabelle): Wir dokumentierten einen Trainingsplan je Zielgruppe. Beispiel-Auszug:

Dieser Plan half uns, nichts zu vergessen und sicherzustellen, dass jeder Mitarbeiter passend abgeholt wird. Insbesondere die Erfolgskriterien waren wichtig: Wir evaluierten z.B., dass tatsächlich ca. 85% der Office-Mitarbeiter entweder live im Webinar waren oder die Aufzeichnung nachher sahen (gemessen durch Aufrufzahlen). Das war sehr gut. Wo wir merkten, eine Gruppe hat Schwierigkeiten (z.B. anfänglich einige Sekretärinnen unsicher), haben wir nachgesteuert mit individueller Betreuung.

Akzeptanzmessung: Um den Erfolg des Change Managements zu prüfen, haben wir verschiedene Methoden eingesetzt: – Umfragen: 4 Wochen nach dem finalen Rollout haben wir eine Online-Umfrage an alle Nutzer geschickt mit Fragen zur Zufriedenheit, empfundenen Qualität, Vergleich alt/neu, etc. Die Teilnahme war ~60%. Ergebnis: 78% fanden die neue Telefonie gut oder sehr gut, 15% neutral, 7% vermissten etwas (v.a. physisches Telefon, BLF). Mit diesem Feedback konnten wir gezielt die letzten Meckerpunkte adressieren (bei BLF z.B. besser erklären wie man Status sieht oder Workarounds). – Nutzungsmetriken: Ein guter Indikator war auch, ob die Leute das System wirklich nutzen. Die Teams Admin Statistik zeigte uns: wie viele Anrufe tätigt ein durchschnittlicher User vs. vorher (Vorher hatten wir CDRs: ~60% machten <5 externe Anrufe/Woche). Nachher sahen wir, dass mehr interne Kommunikation über Anrufe lief, was gut ist. Externe Anrufzahlen blieben ähnlich. Insgesamt war es ein positives Zeichen, dass keine Verlagerung auf private Handys o.ä. stattfand. – Offenes Feedback & Anpassungen: Über den Teams-Feedback-Kanal und Champions bekamen wir kontinuierlich Hinweise. Z.B. meldeten einige, dass es nervig ist, dass Teams am PC und Handy gleichzeitig klingelt. Wir zeigten ihnen die Einstellung „Call answer rules“ (entweder klingeln parallel oder nicht). Solche Kleinigkeiten – nachjustieren – erhöhten die Zufriedenheit. – Führungskräfte-Check-in: Wir befragten auch alle Abteilungsleiter in kurzen Calls, ob ihre Leute klarkommen. Die meisten sagten: nach ein paar Tagen Umgewöhnung läuft es. Wo es hakte (manche Sales-Kollegen hatten Angst, beim Kunden unprofessionell zu wirken ohne Tischtelefon), haben wir im Nachhinein falls gewünscht ein physisches Phone gegeben oder gezeigt, wie man Smartphone + Headset nutzt sodass es professionell ist.

In Summe war das Change & Schulungspaket sehr erfolgreich. Es gab natürlich Einzelpersonen, die nostalgisch an ihrem alten Telefon hingen – aber selbst diese gewöhnten sich nach Wochen um. Ein Schlüsselerlebnis war, als einer der skeptischsten Mitarbeiter (25 Jahre Betriebszugehörigkeit, anfangs „Ich will mein Telefon zurück“) nach zwei Monaten zugab: „Eigentlich ist es doch sehr praktisch, dass ich sogar vom Sofa an Meetings und Calls teilnehmen kann.“ Solche Rückmeldungen zeigen, dass mit dem richtigen Change Management auch kulturelle Hürden überwunden werden können.

11. Ergebnisse, Abnahme und Übergabe in den Produktivbetrieb

Nach Abschluss der Migration standen die Ergebnisbewertung, offizielle Abnahme und die Übergabe in den regulären Betrieb an. In diesem Kapitel fasse ich zusammen, wie wir die Projektergebnisse gemessen haben, welche Kriterien für die Abnahme erfüllt wurden, welche Dokumentation erstellt wurde und wie die Übergabe an das Betriebsteam verlief. Außerdem beschreibe ich die ersten Wochen im Betrieb, inklusive KPI-Trends, Quick Wins und Lessons Learned aus der Anfangsphase.

Abnahmekriterien und UAT: Bereits zu Projektbeginn hatten wir klare Abnahmekriterien definiert, die vor Projektabschluss erfüllt sein müssen. Dazu gehörten: – Funktionale Vollständigkeit: Alle im Pflichtenheft/Anforderungsliste genannten Muss-Funktionen mussten implementiert und getestet sein. Dies reichte von Basis (telefonieren, erreichbar sein) bis zu Spezialthemen (Notruf mit Adressinfo, Chef-Sek-Funktion). – Pilot- und Wellentests bestanden: Jede Migrationswelle war quasi eine Teil-Abnahme, aber final schauten wir, dass kein Standort mit offenen kritischen Fehlern übrig war. – Benutzerakzeptanztest (UAT): Wir führten eine formelle UAT-Phase mit Key Usern aus verschiedenen Bereichen durch. Nach dem Gesamt-Go-Live lud ich Vertreter aus Vertrieb, HR, IT, Produktion, Empfang etc. ein, ihr Feedback zu geben und gegen eine Checkliste letzter Anforderungen abzuhaken. Dinge in der UAT: – „Kann Vertriebsassistenz X alle Aufgaben erledigen wie früher?“ – Ja, sie zeigte es uns im System. – „Erfüllt das System die Anforderungen des Sicherheitsbeauftragten?“ – Ja, z.B. Notruf dokumentiert. Diese UAT-Sitzung war in der Woche nach dem letzten Rollout. Wir dokumentierten kleine Restpunkte. – Erreichung der Kern-KPIs in Startphase: Wir hatten definiert, dass z.B. in den ersten 2 Wochen die Call Erfolgsrate > 98%, keine P1-Incidents etc. Das war erfüllt, es gab nur kleine P3 Tickets. – Zustimmung Betriebsrat: Auch ein Abnahmekriterium war: Der Betriebsrat bestätigt, dass die getroffenen Vereinbarungen umgesetzt sind und keine neuen Bedenken bestehen. Wir gaben ihm Einblick z.B. in Logging-Einstellungen, um zu zeigen, dass nichts Unzulässiges erfasst wird. Er war zufrieden.

Nach Prüfung all dieser Punkte erklärte die Projekt-Steuerungsgruppe (IT-Leiter, Projektleiter – also ich, Vertreter Fachbereiche) das Projekt für erfolgreich abgeschlossen. Wir unterschrieben ein Abnahmeprotokoll, in dem auch Restpunkte festgehalten wurden.

Restpunkte und offene Themen: Natürlich gab es ein paar Restpunkte (Punch List), die jedoch nicht kritisch für Abnahme waren: – Ein paar Benutzer hatten individuelle Wünsche offen, z.B. Polycom-Konferenztelefon in einem Meetingraum hatte noch Registrierungsprobleme – das wurde separat gelöst, ohne das große Projekt weiter laufen zu lassen. – Die Integration des Alarmservers war noch provisorisch – hier vereinbarten wir, im Nachprojekt „Alarm 2026“ eine bessere Lösung zu suchen. – Für das Contact Center war ja klar: vorerst weiter alt, aber Plan für 2026 ein separates Projekt evaluieren, voraussichtlich eine Teams-nahe CC-Lösung. – Dokumentation: Kleinigkeiten wie „Visio-Diagramm der finalen Architektur in Doku noch aktualisieren“ – war in Arbeit, Übergabe aber nicht gehemmt.

Wir legten fest, wer die Verantwortung für die Abarbeitung der Restpunkte hat – meist das Betriebsteam oder ein Folgeprojekt. Ich als Projektleiter habe 2 Monate nach Go-Live noch mal nachverfolgt, ob alles erledigt wurde.

Dokumentation: Ein großer Teil der Abnahme war auch die Übergabe der Dokumentation. Wir haben folgende Dokumente erstellt bzw. aktualisiert: – Betriebshandbuch: Ein ausführliches Dokument (~50 Seiten) für die IT-Betriebsteams, das sämtliche Komponenten beschreibt (Teams Config, SBC config, Monitoring, Backup, Recovery). Es enthält auch Routineaufgaben (z.B. „Wie füge ich einen neuen Nutzer hinzu“, „Wie teste ich Notruf quartalsweise“). Dieses Handbuch wurde in der Wissensdatenbank abgelegt, und relevanten Admins ausgehändigt. – Notfallhandbuch: Separat formuliert: Vorgehen bei größeren Ausfällen. Darin Szenarien und Anweisungen: „Internet ausgefallen – alle Teams Telefone tot -> Interne Notfallkommunikation: ruft Telefonketten via Handy durch“ oder „SBC Hardware defekt -> auf Secondary umschalten, wie Anleitung …“. Dieses Handbuch liegt auch analog bei Werkschutz aus für Notfälle (darin u.a. die Liste der verbliebenen analogen Notfalltelefone). – Architektur- und Konfigurationsdokumente: Dazu zählen: – Netzplan und Rufnummernplan (Visio). – Sicherheitskonzept mit allen Ports und Schnittstellen. – Tabellen aller Zuordnungen (Rufnummer -> User). – Die Richtlinienmatrix etc. die wir erarbeitet hatten. – Dies dient zukünftigen Audits oder falls neue Leute ins Team kommen, dass sie verstehen warum was so ist. – Schulungs- und Kommunikationsmaterial: Wir archivierten alle erstellten Videos, Handouts etc. im Intranet, damit sie für Onboarding neuer Mitarbeiter weiter genutzt werden können. – Vertragsdokumentation: Die neuen Carrier-Verträge, Lizenzerweiterungen etc. wurden dem IT-Vendor-Management übergeben für Verwaltung. – Projektabschlussbericht: Ich habe einen Abschlussbericht verfasst, der Management und Stakeholder über die Ergebnisse, Kosten, Lessons Learned informierte. Dieser hat auch dokumentarischen Wert, falls mal jemand in 2 Jahren fragt „Warum haben wir eigentlich Option X so gemacht?“

Übergabe in Betrieb: Wir haben den Übergang vom Projektmodus in den Normalbetrieb fließend gestaltet: – Bereits während der letzten Rollouts war das zukünftige Betriebsteam (UC-Team) federführend involviert. Sie haben quasi mit uns (Beratern/Projektteam) gemeinsam gearbeitet. So gab es keine Wissenslücke. – Offiziell fand eine Übergabesitzung statt: Ich als Projektleiter, der Leiter IT-Betrieb, Vertreter des Supportdesks, Netzwerkleiter, etc. Wir sind die Dokumentation durchgegangen. Ich habe symbolisch die „Verantwortung“ abgegeben. – Wir vereinbarten eine Hypercare-Phase: 2 Wochen nach dem finalen Go-Live, in der das Projektteam noch verfügbar war für Troubleshooting. Ich und ein Kollege standen quasi Standby, falls gravierendes passiert. Nach diesen 2 Wochen ohne große Vorkommnisse wurden wir „aus der Rufbereitschaft“ entlassen. – Rollen & Prozesse nach Projekt: Im Betrieb war nun klar: – Der „Service Owner“ für Telefonie ist der Leiter des UC-Teams. Er kümmert sich um strategische Weiterentwicklung und ist Ansprechpartner intern. – Das UC-Team (2 Personen) betreibt Technik, schaltet Nummern etc. – Der Helpdesk (8 Leute) übernimmt Tagesfragen. – Und natürlich die Lieferanten-Supports im Hintergrund wie besprochen. – Wissenssicherung: Wir stellten sicher, dass Wissen nicht nur in Köpfen einzelner steckt. Darum hatten wir bspw. den 2nd Level Admin, der neu war, schon im Pilot alles mitgemacht. Außerdem gab es Know-how-Transfer Sessions: Partner hat unserem Team Workshop zu SBC Troubleshooting gegeben; ich habe dem Helpdesk FAQ-Sessions gemacht. – Eventuelle Re-Organisation: Da die klassische TK-Anlage weitgehend wegfällt, brauchten wir weniger dedizierten PBX-Admin. Stattdessen sind die Kollegen jetzt Teams Administratoren. Das war eine Umschulung, die wir im Zuge der Übergabe finalisiert haben (Schulungsvideos Microsoft, evtl. Zertifizierung anstreben).

Erste Betriebswochen – KPI-Trends und Quick Wins: In den ersten 4-8 Wochen nach Abschluss überwachten wir das System besonders eng: – KPI-Trends: Es zeigte sich, dass nach kleinen initialen Schwankungen (hier und da noch mal Quality Issues, viele Supportanfragen) sich die Lage beruhigte. MOS-Wert stieg von W1 4,1 auf W4 4,3 – Indiz, dass Leute Technik im Griff haben (und Netzprobleme identifiziert und bereinigt). – Ticketaufkommen: Hoch in Woche 1-2 (erwartet), dann rapide runter. Nach 6 Wochen war das Volumen etwa halb so hoch wie in alten PBX-Zeiten – weil viele Kleinigkeiten jetzt die Nutzer selber lösen konnten (z.B. Voicemail PIN resets macht man selbst, vorher lief jeder Anrufbeantworter-Reset über TK-Team). – Nutzung: Die Anzahl interner Anrufe stieg, was wir als positive Adoption sehen (Kollegen rufen sich nun eher an, wo sie vorher vielleicht E-Mail geschrieben haben – fördert schnellere Klärungen). Externe Anrufminuten blieben ähnlich, wie erwähnt. – Kosten-Monitoring: Erste Abrechnung vom Carrier war im Rahmen, keine Überraschungen. Wir sahen, dass Mobilfunk-Anrufe etwa 20% des Volumens ausmachen (erstaunlich hoch, vielleicht weil viele auf Handy angerufen haben während Corona-Zeit remote). Das kostete ein bisschen mehr als budgetiert, daher ggf. mal Flatrate nachverhandeln – ein Quick Win identifiziert. – Quick Wins umgesetzt: Einige kleine Verbesserungsideen aus Nutzerfeedback konnten wir schnell umsetzen, z.B.: – Wir richteten in Teams die Besetzt-bei-Besetzt-Funktion ein (eine Policy „Busy on Busy“, damit wenn jemand telefoniert, ein zweiter Anrufer besetztzeichen bekommt statt Warteschleife). Das wünschten einige. War in Cloud easy toggled. – Ein anderer Quick Win: Das Firmenadressbuch in Teams wurde um Abteilungsinfos ergänzt, da nun viele per Suche arbeiten – hilft, den richtigen zu finden, wenn Namen doppelt. – Wir haben gemerkt, manche Außendienstler fanden es top, dass sie keine Rufumleitung mehr beantragen müssen – Quick Win: wir sparten uns bisher übliche Weiterleitungsschaltungen übers Sekretariat – das machen nun Nutzer selbst in Teams, entlastet den Sekretariatsservice. – Positive Nebeneffekte: Z.B. hat sich die Nutzung der Teams-Plattform insgesamt erhöht: Jetzt wo alle ständig Teams offen haben für Anrufe, nutzen viele auch Chat und andere Tools intensiver. Das beschleunigt die digitale Transformation und rechtfertigt die M365-Investitionen noch mehr.

Lessons Learned (nach Go-Live): Schon in den ersten Wochen zogen wir Erkenntnisse: – Unsere gründliche Pilotphase und gestaffelter Rollout hat sich bewährt – es gab keinen großen Flächenbrand, sondern immer nur begrenzte Feuer, die wir löschen konnten. – Training darf man nie genug machen: Manche Probleme resultierten schlicht aus Unwissen (z.B. jemand klagte „mein PC klingelt nicht“ – es war in „Nicht stören“ Status gesetzt). Wir ergänzten also noch eine FAQ an alle: „Top 5 der häufigsten Fragen und Lösungen“. – Der Betriebsrat war mit der Umsetzung zufrieden, was retrospektiv zeigt: frühe Einbindung war richtig, auch wenn es Zeit kostete. Aber dadurch war in Betriebsphase Ruhe. – Das Notrufthema hat uns viel Aufwand gemacht, aber im Nachhinein sind alle froh, denn es funktioniert reibungslos und wir schlafen ruhiger. Andere Firmen hatten hier schon Kritik der Berufsgenossenschaft geerntet, wir nicht. – Eine interessante Lesson: Manche analoge Prozesse fingen an sich zu ändern dank neuer Technik. Z.B. hat die Personalabteilung spontan eingeführt, Erstvorstellungsgespräche nun per Teams-Call statt Telefon zu machen, weil man ja nun auch Video könnte. War gar nicht direkt Projektziel, aber ein Nebeneffekt, der durch unsere Schulungen („man kann auch spontan eine Videokonferenz aus dem Anruf machen“) inspiriert wurde.

Nach ein paar Monaten konnten wir mit Stolz sagen: Die Einführung war erfolgreich abgeschlossen, das System läuft stabil, Nutzer haben es angenommen und alle wichtigen Indikatoren sind positiv. Damit war es an der Zeit, das Projekt offiziell abzuschließen und in die Normalität überzugehen.

12. Häufige Fehler, Fallstricke und Lessons Learned

Kein Projekt dieser Größenordnung verläuft völlig reibungslos – und aus jedem lernen wir dazu. In diesem abschließenden fachlichen Kapitel möchte ich die häufigsten Fehler und Fallstricke beleuchten, auf die man bei solch einem Teams-Telefonie-Projekt achten muss, und wie wir sie (teils erst im Nachhinein) gelöst haben. Zudem formuliere ich generelle Lessons Learned und Best Practices, die sich aus unseren Erfahrungen bei der Harry Hase AG ableiten lassen.

Technische Fallstricke: – Fehlende Netzwerkplanung: Ein typischer Fehler in Cloud-Telefonie-Projekten ist, die Netzwerkvoraussetzungen zu unterschätzen. Wir haben zwar früh QoS etc. adressiert, aber z.B. initial übersehen, dass ein Segment im Lager gar nicht genug WLAN-Abdeckung für stabile Calls hatte. Ein Werkstatt-Büro klagte über Abbrüche – Grund: Das Notebook war im WLAN mit nur 1-2 Balken. Lesson: Vor dem Rollout jeden Standort netzwerktechnisch analysieren. In unserem Fall ein kleiner Aussetzer, fixbar mit einem zusätzlichen Access Point, aber hätte schlimmer sein können. – Nummernverwaltung-Komplexität: Bei uns gab es anfangs leichte Verwirrung mit Rufnummern – ein Mitarbeiter bekam aus Versehen eine Nummer, die noch ein anderer in einem Werk als Fax genutzt hat (doppelt vergeben). Ursache war, dass unsere Nummernliste nicht 100% gepflegt war. Der Fehler fiel auf, als jemand das Fax anrief und bei dem Mitarbeiter landete. Wir korrigierten es (Fax bekam neue Nr.), aber Lesson: Exakte Bestandsaufnahme alter Nummern, Bereinigung und sauberer Zuteilungsprozess sind Gold wert. Ein durcheinander bei Nummern kann Chaos anrichten, vor allem wenn Kunden plötzlich falsch verbunden werden. – Features und Limitations übersehen: Teams Phone entwickelt sich ständig. Einige Limitierungen waren uns teils erst spät klar: z.B. es gibt (Stand 2025) keine echte Funktion für gemeinsames Klingeln auf mehreren Geräten wie ein analoges „Lauthören in Abteilung“. Wir hatten so ein Szenario in einer Werkstatt, wo früher ein Anruf auf einer lauten Klingel rausging, damit jeder es hört. Teams konnte das nur durch Simultanruf an alle oder über einen Lautsprecher mit Bot-Lösung (zu komplex). Wir mussten da improvisieren. Lesson: Kenne die Unterschiede genau. Was die PBX konnte vs. was Teams anders macht, muss vorab kommuniziert und Lösungen/Workarounds geplant werden. – Notruf-Thematik unterschätzt: Ein absoluter Fallstrick ist, Notrufe via VoIP nicht ausreichend zu bedenken. Wir hatten das im Fokus, aber viele Projekte übersehen, dass z.B. ein Laptop im Homeoffice bei Anruf 112 die falsche Leitstelle erreicht oder gar nicht geht. Wäre uns das passiert, wäre es spätestens bei der ersten Prüfung durch den Betriebsarzt aufgeflogen. Unsere gründliche Arbeit hier hat Schlimmes verhindert. Lesson: Bei Telefonie in DE: Notruf immer als eigenes Workstream behandeln. – SBC-Update mitten im Rollout: Ein konkreter Fehler: Wir haben nach Welle 3 ein SBC-Firmwareupdate eingespielt, weil der Hersteller ein Bugfix anbot. Leider änderte das etwas am Dialplan-Verhalten, was in Welle 4 dann Probleme machte (ein bestimmtes Rufnummernformat wurde plötzlich anders behandelt). Wir mussten hektisch patchen. Hätten wir gewartet oder es besser getestet, wäre es vermeidbar gewesen. Lesson: Möglichst freeze kritische Systemversionen während Migration; Updates nur wenn sicherheitsdringend. – DECT-Integration Stolperstein: Wir wussten, DECT ist schwierig. Ein Fallstrick war, dass initial Anrufe von Teams zu DECT immer ohne Audio ankamen. Nach langer Fehlersuche entpuppte sich, dass die alte PBX bei internen VoIP-Kopplung den RTP-Stream nicht durchleitete ohne gewissen Header. Dies war ein proprietäres Problem. Unser Workaround: „schick den Call über PSTN zum DECT“ (also intern via Umweg), was uns Minuten kostete und Qualität litt. Später fanden wir doch noch die PBX-Einstellung. Lesson: Legacy-Systeme verhalten sich teils undokumentiert – man muss experimentierfreudig und kreativ sein. Und vielleicht: Lieber separat neues DECT-Gateway anschaffen statt komische PBX-Kopplung. – Fax übersehen: Fast hätten wir Faxe vernachlässigt, nach Motto „Wer faxt denn noch“. Kurz vor Rollout fiel einem Kollegen ein, dass Finanzbuchhaltung täglich Fax vom Zoll bekommt. Wäre peinlich geworden, wenn wir das abgeklemmt hätten. Zum Glück schnell gelöst mit ATA. Lesson: Immer auch Randbereiche (Fax, Modems, Alarmanlagen, Frankiermaschinen etc.) inventarisieren. In jedem Unternehmen gibts noch irgendwas analoges.

Organisatorische Fallstricke: – Nicht früh genug geschult: Bei uns war Timing okay, aber wir merkten: Manche hätten gerne noch früher geübt. Z.B. Sekretärinnen sagten, ideal wäre 1 Monat vorher ein Testsystem zum Spielen gehabt zu haben. Wir hatten nur ~1 Woche vorher trainiert. Sie lernten es zwar fix, aber ideal: Pilot-User aus allen Gruppen einbeziehen, damit die später als „Lehrer“ fungieren. Wir hatten Champions, das war gut, aber hätten z.B. einen Empfangsmitarbeiter in Pilot nehmen sollen (haben wir verpasst, da wir Pilot nur IT machte). – Change-Übermüdung: In 2 Jahren Office 365 gab es viele Neuerungen, jetzt noch Telefonie – einige Mitarbeiter waren veränderungsmüde. Ein Risiko war, dass sie innerlich blockieren („Schon wieder was Neues“). Unser intensives Change Mgmt hat viel abgefedert. Wo wir Fehler machten: Ein Standort (Werk C) wurde parallel auch mit neuem ERP-System konfrontiert. Die Leute dort waren gestresst. Das haben wir zu spät erkannt – im Nachhinein hätten wir deren Telefonie vielleicht etwas später gemacht oder zusätzliche Supportpower dort hingeschickt. – Betriebsrat-Einbindung Timing: Obwohl wir gut eingebunden haben, gab es einen kleinen Stolperstein: Der BR fühlte sich bei einer Sache zu spät informiert – wir hatten die Policy „Calls aufzeichnen deaktiviert“ erst kurz vor Go-Live formal beschlossen. Er hätte das lieber eher gesehen, auch wenn es genau seine Forderung erfüllte. Daraus lernten wir: Überinformieren ist besser als unterinformieren. Besser dem BR alles Rohkonzept schon vorab geben. Sie sagten aber am Ende, es war okay, nur nächstes Mal früher kommunizieren. – Rollen im Betrieb definieren: Zunächst fühlte sich keiner so richtig zuständig für einige Grenzthemen (z.B. Telefonbuchpflege: früher machte HR das im Intranet, jetzt Teams-Adressbuch zieht aus AD…). Wir hatten nicht klar, wer Änderungen bei Abteilung/namen in Azure AD pflegt. Es entstand kurz Chaos (Leute sagten „mein Titel falsch im Telefonbuch“). Geklärt: HR pflegt weiterhin im AD via Schnittstelle. Lesson: Auch scheinbar kleine Verantwortungen (z.B. wer pflegt Ansagetexte) vorab festlegen. – Expectations Management: Ein Pitfall kann sein, dass zu hohe Erwartungen geweckt werden. Manche dachten, mit Teams Telephony löst sich alles in Luft auf – z.B. hofften Kollegen, dass damit auch die Handykosten entfallen (dachten, sie könnten jetzt global per WLAN telefonieren und bräuchten kein Roaming). Real ist: Handy bleibt wichtig für mobile Absicherung. Wir mussten klarstellen: Teams Phone ist kein Ersatz für Mobiltelefone (schön wär’s gebührenmäßig, aber praktisch brauchen wir beides). So solche Erwartungskorrekturen sollte man früh machen. Wir haben es getan, aber einzelne hatten falsche Vorstellungen.

Rechtliche Fallstricke: – Aufzeichnung & Datenschutz: Ein bekannter Fallstrick: Unklarheit, ob Anrufmitschnitte legal und wie. Wir umschifften das durch generelles Deaktivieren. Aber ich kenne Firmen, die nach Einführung in Trouble kamen, weil Mitarbeiter versehentlich calls recorded und das gegen interne Regeln war. Wir schulten also: „Nicht ohne Erlaubnis aufnehmen, es gibt ja den Hinweiston – ist nicht für heimliches Protokollieren gedacht.“ – Aufbewahrung von Verbindungsdaten: DS-GVO konform muss man klären, wie lange Verbindungsdaten gespeichert. Wir haben uns an Standard gehalten (6 Monate CDR intern). Hätten wir das vergessen, hätte datenschutzrechtlich jemand fragen können: warum speichert ihr alle Anrufe ewig in der Cloud? (auch wenn uninteressant, besser definieren). – Notfallkonzept Dokumentation: Ein potenzieller Fallstrick: Die Berufsgenossenschaft oder Aufsichtsbehörde kann fragen: Zeigen Sie Ihr Notrufkonzept für VoIP. Wäre das nicht schlüssig, drohen Untersagungen. Bei uns war es sauber. Aber ein Hinweis an alle: Das schriftlich fixieren, an offizielle Stellen weiterleiten (Arbeitssicherheit) damit formaler Segen da ist.

Lessons Learned / Best Practices: 1. Stakeholder früh und kontinuierlich einbinden: Unsere Erfahrung zeigt, dass enge Abstimmung mit allen (IT, Fachbereiche, Betriebsrat, Datenschutz, Security) zwar viel Abstimmungsaufwand bedeutet, aber unbezahlbar ist, um späteren Widerstand oder böse Überraschungen zu vermeiden. 2. Pilot und phased Rollout sind lebensrettend: Hätten wir alles an einem Wochenende umgestellt, wären die vielen kleinen Probleme kumuliert zu einem großen Desaster. So konnten wir adaptiv lernen und anpassen. Ich werde künftige Projekte ähnlicher Art immer in Etappen planen, kein Big Bang. 3. Kommunikation ist genauso wichtig wie Technik: Wir investierten fast so viel Zeit in Schulung/Kommunikation wie in pure Technik. Und es hat sich gelohnt – die User sind eher verziehen, wenn mal ein Bug war, weil sie vorbereitet waren und das „Warum machen wir das“ verstanden haben. Transparenz schafft Akzeptanz. 4. Legacy-Interoperabilität großzügig planen: So ein Mischbetrieb alt/neu ist komplex. Besser etwas länger parallel lassen als zu früh abschalten. Z.B. wir haben die alte PBX in Werken noch 2-3 Monate laufen gelassen, bis sicher war, dass alle DECT etc. sauber umgestellt. Dieser Puffer war gold wert (auch psychologisch: Leute wussten, notfalls kann ich noch altes Telefon nutzen, auch wenn kaum einer es brauchte). 5. Testing, Testing, Testing: Insbesondere „Edge Cases“ testen. Wir haben über 50 Testfälle definiert und doch kamen in Produktion noch welche raus, an die keiner dachte. Bei sowas gilt: Wenn möglich, Nutzer mit echtem Verhalten einbeziehen, denn die probieren Dinge, die man im Testskript nicht hat. 6. Keep it simple (wo möglich): Teams bietet viele Optionen (Direct Routing vs OC, etc.). Wir entschieden uns für eine Hauptlinie und zogen die durch. Mischmodelle minimal gehalten. Das half, die Komplexität zu zähmen. Wo wir Komplexität hatten (z.B. Contact Center verbleibt extern), haben wir das isoliert und nicht gleich auch noch umgestellt. Step by step statt alles auf einmal. 7. Dokumentation & Wissen bleiben beim Kunden: Da ich externer Berater war, war mein Ziel immer, das Know-how zu internalisieren. Nichts ist schlimmer als wenn nach Projekt keiner im Unternehmen weiß, wie es funktioniert. Hier haben wir bewusst die Kollegen mitlernen lassen, das zahlt sich jetzt aus – ich bin quasi entbehrlich geworden (so soll es sein). 8. Flexibilität für Zukunft einplanen: Wir haben z.B. mit Direct Routing begonnen, aber schon daran gedacht, dass in 2-3 Jahren vielleicht Operator Connect attraktiver wird. Daher modulare Architektur (zwei Ansätze parallel möglich) bedacht. Auch für Contact Center eine Option offen gelassen. Diese Art „Zukunftssicherheit“ ist wichtig bei Cloud, weil sich Markt schnell ändert. 9. Nutzererfahrung im Fokus: Eine Lesson war, dass am Ende zählt, ob der Mitarbeiter seinen Job besser/schlechter/gleich machen kann. Technische Eleganz ist zweitrangig. Daher war es richtig, z.B. ausnahmsweise ein paar Tischtelefone bereitzustellen, obwohl das Konzept „Headset only“ war – einfach weil der User sich sonst unwohl gefühlt hätte. Manchmal muss man dogmatische IT-Entscheidungen zugunsten Anwendererfahrung aufweichen. 10. Feiern des Erfolgs: Last but not least, wir lernten: Nach so einem Mammutprojekt sollte man den Erfolg auch sichtbar machen. Wir haben intern eine kleine „Telefonie-Go-Live“ Meldung im Newsletter gefeiert mit Dank an alle Beteiligten. Das motiviert die Organisation, und man schafft Akzeptanz für künftige Digitalisierungsprojekte (weil gezeigt: es kann erfolgreich sein).

13. Anhänge

(In diesem Abschlussteil verweise ich auf einige beispielhafte Anhänge und Vorlagen, die im Zuge des Projekts entstanden sind. Diese sind im Rahmen des Artikels beschrieben, aber nicht in Gänze abgedruckt. Im realen Kontext könnten sie als separate Dokumente bereitgestellt werden.)

A. Vorlagen und Musterdokumente: – RACI-Matrix (Projektrollen): Eine tabellarische Übersicht aller Projektaktivitäten mit Zuordnung von Verantwortlichkeiten nach RACI. (Aus Platzgründen im Artikel nur auszugsweise gezeigt, vollständige Tabelle umfasst ~30 Zeilen). – Risiko-Register: Detailliertes Register mit allen identifizierten Risiken, Bewertungsschema, Maßnahmen und Verantwortlichen. Diente als lebendes Dokument im wöchentlichen Projekt-Jourfix. – Abnahmetestprotokoll pro Welle: Vorlage mit Checkliste (wie in Kapitel 6 beschrieben) zum Abhaken der einzelnen Testanrufe und Funktionen. Inkl. Felder für Tester, Datum, Ergebnis, Bemerkungen. Wurde für jede Rollout-Welle geführt und archiviert. – Kommunikationsplan: Zeitplan und Kanalübersicht aller Kommunikationsmaßnahmen (z.B. Datum: 01.09. Townhall-Ankündigung, KW40: Intranet-Post „Teams Telefonie kommt“, 1 Woche vorher Mail an Nutzer, etc.). Dieses Plan-Dokument half dem Projektteam, die Kommunikation konsistent zu halten. – Schulungsagenda & Materialien: Beispielsagenda für eine Schulung (z.B. „Teams-Telefonie Basics“ – Agenda: Einführung 5min, Demo 20min, Übung 20min, FAQ 15min). Plus die Folien/PDFs, die verwendet wurden. Diese sind in der internen Wissensplattform abgelegt.

B. Rechenhilfen und Kalkulationsmodelle: – Bandbreitenkalkulation (Excel): Enthält die Formel: Benötigte Bandbreite = Gleichzeitige Anrufe * (Codec-Bitrate + Overhead). Beispielsweise: Overhead (IP+UDP+RTP Header) ~ 40 Bytes per 20ms, G.711 64kbit => effektiv ~87 kbit/s one-way. In Excel haben wir je Standort die Gleichzeitigkeit angenommen und dann Down/Up Bandbreite berechnet. Plus Reserven 20%. Dieses Tool kann auch „Was-wäre-wenn“ (z.B. 20% mehr User) berechnen. – Lizenz- und TCO-Berechnung: Ein komplexes Spreadsheet mit allen Kostenpositionen über 3 Jahre. Formel-Beispiele: – Lizenzkosten pro Jahr = Anzahl User_X * Preis_Lizenz_X * 12. Summiert über alle Lizenztypen. – Investitions-Amortisation = Investitionssumme / Nutzungsdauer in Jahren, um pro Jahr Werte zu erhalten. – ROI = (Einsparungen_{3J} – Kosten_{3J}) / Kosten_{3J}. – Break-Even-Time = Investitionskosten / jährlicher Netto-Ersparnis. (bei uns ~2.5 Jahre). Diese Excel erlaubt es, an Stellschrauben wie Useranzahl, Provider-Tarife, etc. zu drehen und die Auswirkungen aufs Budget zu sehen (Sensitivitätsanalyse). – QoS Monitoring Template: Ein Diagramm, das zeigt, wie MOS über Zeit ist, mit Markierung des Zielwerts. Hilft beim Reporting an Management.

(Hinweis: In einem tatsächlichen Fachartikel könnten diese Anhänge in Auszügen oder Zusammenfassungen präsentiert werden. Hier im Rahmen des Textes verweisen wir darauf, um Vollständigkeit anzudeuten.)

Schlusswort: Die Einführung von Microsoft Teams-Telefonie bei der Harry Hase AG war ein umfangreiches, aber äußerst lehrreiches Projekt. Von der ersten Vision über Business Case, Umsetzung bis zum Betrieb haben wir nicht nur eine neue Technologie implementiert, sondern auch Wandel im Arbeitsalltag der Mitarbeitenden begleitet. Die hier geteilten Erfahrungen – seien es die strukturierten Ansätze oder die gemachten Fehler – sollen anderen dabei helfen, ähnliche Projekte erfolgreich und mit Weitblick umzusetzen. Insgesamt zeigt unser Ergebnis: Mit sorgfältiger Planung, Einbindung aller Beteiligten und Fokus auf Praxistauglichkeit kann die Cloud-Telefonie ein voller Erfolg werden.

Weitere Beiträge zum Thema SharePoint und Teams