Vorwort   Warum gibt es diese Internetseite?

Story

Seien Sie ehrlich! Wie oft fragen Sie sich: Wo kommt eigentlich diese ganz bestimmte Entscheidung her, die dafür sorgt gerade dieser eine Pfad in einem Prozess durchlaufen wird und ein anderer nicht. Beziehungsweise, dass eine bestimmte Menge von Pfaden nacheinander durchlaufen werden?

Und genau dieser Mangel an Transparenz, der oft anzutreffen ist, hat mich schon immer umgetrieben.

Die Überbewertung von Programmierarbeit als Lösung für alles, der Hang zur Schaffung mal wieder einer Plattform mehr, die Ignoranz gegenüber dem langfristigen technischen Pflegeaufwand zu Gunsten eines kurzfristigen Erreichens einer scheinbaren Lösung.
Zeit, die für alles mögliche vergeudet wird, aber nicht für das eigentliche, nämlich das fachliche Thema.

Und das lautet: Ist da ein Fehler oder nicht auf Seiten des Betreibers? Und wenn ja, wo liegt er,
geographisch, strukturell, hierarchisch und organisatorisch?
Nutzen wir doch bestehende Business Process Engines und realisieren Sie Diagnosen und Entscheidungen
mit Hilfe von DMN, der Decision Modeling (and) Notation. Transparent und fachlich!

Machen Sie sich bereit für einen Mentalitätswandel: Entscheidungen sind das A und O eines Prozesses, sein Herz und seine Seele.
Nicht diese vielen vielen "Kästchen", die für Aktivitäten stehen, und die so präsent sind in den Prozessentwürfen.
Aber das, was Sie nicht sehen, die Entscheidungsregeln, das ist die eigentliche Kunst!

Übrigens: Mit Betreiber ist bei mir immer ein Telekommunikationsunternehmen (Telecommunications company, Telco) gemeint, welches Triple Play Internetanschlüsse für private Endkunden anbietet.

Tipp

Schauen Sie sich auf der Startseite die Videos in der angebotenen Reihenfolge, also von oben nach unten und von links nach rechts an.
Denn diese Videos bauen aufeinander auf.

Tipp

Weiterführende Informationen über jede Story (ist gleich Video) finden Sie hier auf dieser Seite.

Ein kurzer Abriss der Diagnose- und Entstörungstechnik von Telefonanschlüssen liefert die Leitidee für unseren Musterprozess,
in dem moderne Entscheidungstabellen nach DMN Notation Wunder bewirken sollen.

Reden wir ein wenig über die Geschichte von Entstörungsprozessen bei Telekommunikationsanschlüssen. So ganz früher - da ging es nur um Telefonie -, da war der Entstörungsprozess gut sichtbar. Lebenslaufkärtchen wanderten von einem Diagnoseplatz zum nächsten ähnlich den Stationen eines Fertigungsprozesses. Und vielleicht wurden dann die Pappkarten auch mal durch eine erste Workflow-Engine ersetzt, ok.

Aber der nächst große Schritt kam mit der Einführung von APIs, also softwaretechnisch nutzbaren Zugriffen, auf BSS- und vor allen Dingen OSS-Systeme wie SEPT, DSLAMS, CRM usw. Nur: Was genau macht man jetzt mit den gewonnenen Daten wie dem ohmschen Widerstand der Kupferleitung, dem Synchronstatus der DSL-Verbindung und so weiter?

Hier tauchen zum ersten Mal Computer gestützte Entscheidungen auf. Von Prozess-Designs und Drag-and-drop Tools waren alle noch weit entfernt, und so wurde mehr oder weniger einfach drauf los programmiert. Wer eine Process engine verwendete oder gar ein Expertensystem war schon der König.

Im Fokus standen die APIs, weniger die Entscheidungen. Das war ein großer Fortschritt. Erst sehr individuell, dann immer stärker standardisiert. Mittlerweile kommt man an jede Menge Daten einer Telekom-Infrastruktur ziemlich gut und einfach ran. Das war nicht immer so.

Von daher reichte es auch schon mal aus, den Synchronstatus einer DSL-Leitung anzuschauen.

Story

Wir lernen den klassischen, eher naiven Links-nach-Rechts (Anfang-zu-Ende) Prozessentwurf kennen sowie den systematischeren retrospektiven Entwurf, der sich an erwartbaren Situationen orientiert, die im Prozess behandelt werden sollen.

Gegenstand ist der allgegenwärtige eingehende Anruf in einem Service-Center eines Telco-Anbieters (Inbound call).
Wesentliche Elemente darin sind der Schnelltest vor der Anrufannahme, die Deutung der Anrufabsicht, die Behandlung des 80% Falls mit einem einzelnen einfachen Fehler, sowie die Weiterleitung an eine Diagnosekraft, sofern der Fehler schwierigerer Natur ist, also der 20% Fall.

Später werde ich hier die einfachste Konstruktion und Anwendung einer Entscheidungstabelle in DMN Notation zeigen.

Tipp

Machen Sie die erwartbaren Situationen des Prozesses explizit, bevor  Sie den Prozess tatsächlich entwickeln ("designen").
Legen Sie passend einfach zu jeder Situation ein spezifisches Prozessende-Symbol an.
So, wie ich es im Video zeige. Dann geht nichts verloren.

Tipp

Jeder daraus resultierende Prozessweg soll seine eigene, volle Transparenz und Persönlichkeit erhalten.
Deshalb empfehle ich, auf Zusammenführung eher und fast immer zu verzichten.
Merke: Es ist nicht das Ziel, alles in ein einziges Prozessende zusammenzuführen.
Und: Auch wenn manches in seinem Fortgang zunächst identisch zu sein scheint, so muss das ja nicht für alle Ewigkeit so sein.

Tipp

Vermeiden Sie Rückschleifen, wirre Einsprünge und ähnliche Konstrukte, nur weil da doch schon einmal genau das gemacht wird, was man gerade braucht. Die Tatsache, dass man in einer Prozess-Sequenz einen Schritt weiter ist, ist eine wichtige und wertvolle Information und Situationsbeschreibung. Entgehen Sie bewusst diesem vom Programmieren her gewohnte Muster!
Beispiel: Ein Fehler wird diagnostiziert, eine Korrektur angewendet und dann im Design einfach an die Stelle zurück verwiesen (Schleife oder Einsprung), wo ursprünglich die Erst-Diagnose herkam. Bitte nicht! Modellieren Sie nach dem Prinzip: Check (1. Durchgang) - Repair - Check (2. Durchgang), auch wenn natürlich hinter jedem Check die identische Diagnose-Prozedur steckt. Aber die Ausgangssituation ist halt anders!

Tipp

Vergessen Sie nie, sich von Anfang an Gedanken über mögliche Fehlersituationen zu machen und diese systematisch abzufangen.
Das sichert einen gewaltigen Vorsprung, wenn es später ans Integrieren und Testen geht.

Story

Einen Prozess ohne Entscheidungen gibt es nicht. Es ist nach meiner Meinung sogar so, dass die Seele des Prozesses in den Entscheidungen liegt und gar nicht so  sehr in den Aktivitäten. Diese sind ja nur deshalb so im Fokus, weil die Kästchen, durch die die Aktivitäten repräsentiert werden, so augenfällig sind. Warum wohl?

Stellen Sie sich doch nur für einen Moment vor, Sie würden beim Prozessentwurf zunächst die Entscheidungswege skizzieren und nicht nur die Aktivitätenkette?

Hier also gebe ich Ihnen einen supereinfachen Einstieg in die Welt der Entscheidungstabellen nach DMN-Notation.

Welche gezeigte Lösung wird am Ende wohl die meiste Transparenz bringen? Ausdrücke an jedem einzelnen Pfad, wie sie ja so einfach auf der Hand liegen und mal schnell dort hinzuschreiben sind? Oder doch die vorgeschaltete Entscheidungstabelle? Schauen Sie selbst!

Super
Tipp

Vermeiden Sie unbedingt komplizierte Entscheidungs-Ausdrücke an Pfaden (Berechnungen, Fallunterscheidungen etc.). Erstellen Sie wenigstens stattdessen einen Berechnungs-Task vor dem Gateway oder (natürlich) noch viel besser: Verwenden Sie immer eine Entscheidungstabelle, auch wenn es eine ganz einfache ist. So, wie ich es in meinem Video zeige.
Der Vorteil ist: Jeder sieht es sofort, dass hier wird was entschieden wird.

Hilfe

Story

Was durch Vernetzung von Entscheidungstabellen in einer Kaskade, oder wenn Sie so wollen, in einem Entscheidungsflussdiagramm entstehen kann, das zeige ich Ihnen hier.

Es ist nicht wirklich ein Fluss, denn alles ist hier statisch, wie in einem Rechenwerk. Es macht einfach Klack-klack-klack, und schon ist die Entscheidung da. Genau das ist auch der Unterschied zu einer Entscheidungsverarbeitung in einer Sequenz von Aktivitäten direkt im Prozess. Diese Sequenz verbraucht Zeit, das Klack-klack-klack nicht. Zumindest gedanklich.

Wir lernen die Anwendung einer Landschaft von Entscheidungstabellen zur Regel basierten Implementierung der Anschluss-Diagnostik kennen mit repräsentativen galvanischen Messwerten. Alles richtig, aber sehr vereinfacht natürlich.

Aber das alleine reicht noch nicht. Denn ohne Sinnbezug, Bedeutung und insbesondere Bewertung gibt es keine Entscheidung.
Hier hilft das Schlüsselkonzept "Metrik" entscheidend weiter.

Lernen Sie, Entscheidungen in einer einfachen Art zu treffen, obwohl die Dinge kompliziert sind.

Welche Messwerte sind denn entscheidend? Fragen wir doch ChatGPT. Und warum tun wir das nicht eigentlich immer? Automatisiert und auf jeder Ebene? Also auch für triviale Entscheidungen?

 Story

Mit der vorangegangenen Story haben wir ein Gefühl dafür bekommen, dass Transparenz durch kleinteilige Entscheidungstabellen entsteht, die Metriken abbilden.

Aber was genau sind Metriken überhaupt? Das lernen wir hier anhand der Ikea-Metrik kennen.

Story

Metriken lassen sich also sehr gut in Entscheidungstabellen abbilden. Und Entscheidungstabellen sind großartige Wissensbausteine für unsere Prozesse.

Um hier auch den letzten Skeptiker zu überzeugen, reiße ich in dieser Story exemplarisch drei Implementierungsalternativen an:

1. Ein programmiertes Skript ersetzt die vernetzten Entscheidungstabellen
2. Ausdrücke direkt an den Pfaden hinter dem Gateway bilden die fachliche Logik ab und
3. Eine in BPMN modellierte Kette von Gateways simuliert die Kaskade und Aggregation von kleinen Entscheidungen.

Story

Es gibt neben der Transparenz noch ein weiteres Argument dafür, BPMN und DMN für die Diagnostik von Internetanschlüssen zu verwenden. Das ist die Tatsache, dass die fachlich modellierten Bausteine unmittelbar ausführbar und nutzbar sind.

Dass das geht und wie das geht sehen Sie in dieser Story.

Story

In den vorangehenden Stories habe ich Modellierungstechniken vorgestellt.

Das eigentliche Ziel dieser Webseite ist aber doch folgendes: Ich möchte aufzeigen, dass man zwischen den beiden Extremen von Generativer Künstlicher Intelligenz auf der einen Seite, bei der man scheinbar ohne eigenes Zutun sämtliche Probleme lösen kann, und Salopp gesagt Programmieren bis der Arzt kommt auf der anderen Seite, wo Telco-Experten schnell ins Abseits geraten, mit Hilfe bestehender Prozessmaschinen, die BPMN und DMN verstehen (z.B. Camunda), einen sehr eleganten, effektiven und effizienten Mittelweg gehen kann, der nach meiner Meinung viel zu sehr vernachlässigt wird.

Ein langer Satz, das gebe ich zu. Aber ich denke, diejenigen, die ich damit ansprechen möchte, wissen, was ich meine.

Deshalb beginne ich jetzt die Perspektive zu ändern und zügig auf die Telco-fachliche Ebene zu wechseln.

Im Bereich Start wird es um Metriken und Messwerte rund um DSL-Anschlüsse gehen mit den Ebenen physische Leitung (Galvanik), HF-Medium (Träger, Störungen), Bitstrom (Fehlerraten) und Internet (TCP/IP) sowie der Betriebsfähigkeit des Einzelanschlusses (Stichworte: Umzug, Prozessfehler) als auch der Aggregation (Stichwort: Großräumige Störungen, Geplante Bautätigkeiten). Und das für einen Schnelltest mit Rot/Grün-Ergebnis mit der Betrachtung des Akut-Zustandes als auch - wo angebracht - einer 24 Stunden Historie.

Im Bereich Anwendungen finden sich darüber hinaus Implementierungsbeispiele sowohl für genauere DSL-Diagnostik, als auch für die anderen Anschlusstechnologien HFC (Koaxialkabelnetze) als auch Glasfaseranschlüsse. Darüber hinaus auch Implementierungsbeispiele in Prozesse, insbesondere der Frage: Wie modelliere ich einen einzelnen Check - Repair - Check Zyklus oder sogar eine Superzyklus über einen solchen elementaren Störungsbehebungszyklus, wenn es mehrere Defizite gibt, die es zu beheben gilt.

Doch hier beginne ich noch mit einer Übergangsfrage: Verstehen wir alle das gleiche unter Was sind Messwerte?

Wir lernen noch eine weitere hilfreiche DMN (DRD) Fähigkeit kennen, die uns als "Helferlein" für kleine Vorverarbeitungsschritte nützlich sein wird.

Hilfe

Camunda Videos DMN für Fortgeschrittene (in englischer Sprache)

Story

Jetzt aber! Jetzt endlich möchte ich ein vollständiges Entscheidungsdiagramm (Decision Requirements Diagram, DRD) präsentieren, das sich in möglichst einfacher Form mit elektrischen Messwerten der Doppelkupferader auseinandersetzt.

Alle methodischen Voraussetzungen sind jetzt gegeben! Falls Sie unsicher sind, beschäftigen Sie sich bitte noch einmal mit den vorangehenden Stories.

Der Test läuft in der Telco Industrie unter dem Stichwort MELT (MEtallic Line Test). Das DRD repräsentiert einen Quick check - Ansatz, d.h. wir schauen auf die erhobenen Messwerte sehr grob, also schwarz/weiß und wollen lediglich die Aussage treffen, ob eine galvanische Auffälligkeit besteht oder nicht.

Ein MELT ist heutzutage standardmäßig in MSAN ILTF Chips verfügbar. Er wird heutzutage eher weniger zu Rate gezogen, bietet für uns aber einen einfachen Einstieg in die Materie. Das liegt zum einen an dem passiven Prüfabschluss (PPA), der in modernen Anschlusskonzepten nicht immer verfügbar ist, zum anderen aber auch an den qualitativ interessanteren Aussagen anderer Tests zu Hochfrequenzverhalten und Bitstromqualität, die etwas später noch folgen werden.

Schauen Sie bitte oben nochmal nach (Es war einmal): Früher war das "der Knaller", per Fernmessung galvanische Werte zu holen und automatisiert zu bewerten, heute interessiert das kaum noch.

Hinweis

Ab jetzt ändert sich die Präsentationsmethodik ein wenig: Die Beschäftigung  mit ChatGPT, um Objektivität in der Frage der Auswertung von Messwerte zu erhalten finden Sie jeweils separat auf dieser Seite unter dem Stichwort Chat. Das Hauptvideo verwendet eine Zusammenfassung. Ziel ist es, die fachliche Abbildung auf Entscheidungstabellen im Mittelpunkt zu halten.

Chat
GPT

So antwortet ChatGPT auf meine Fragen zu analogen galvanischen Messewerten einer VDSL-Leitung.
Verfolgen Sie den Dialog, um die Details des DRD MELT-quick-check-metrics genauer zu verstehen:

.

Unter
lagen

Wenn Sie mögen, stöbern Sie hier gerne ein bisschen zu klassischen galvanischen und POTS/ISDN - Messungen.

Die TR183 ist besonders in Kapitel 4.3 relevant.

Story

Aus Sicht der modernen digitalen Welt haben wir mit der Leitung und deren elektrischen Strömen noch nichts gewonnen.
Das ist eher wie ein Flussbett, das ausgetrocknet ist. 

Wenn wir hier was messen, wissen wir hinterher nur, ob überhaupt Wasser fließen würde oder nicht.

Das Wasser, das dann darin fließt, ist das eigentliche Transportmedium. Die analoge Übertragung von Sprache, Faksimiles und Modemtönen ist dagegen vergleichbar mit ein paar Eimern Wasser, die Signal gebend ins Flussbett geschüttet werden. Und auf der Empfängerseite spürt man den Wassertropfen auf, ob und mit welcher Intensität oder Häufigkeit er eintrifft.

Genauer gesagt ist in modernen Zeiten wiederum nicht das Wasser selbst, das fließt, sondern die Art und Weise wie es fließt, seine Modulation, was nichts anderes ist als die Veränderung in Zeit, Frequenz und Stärke.

Um etwas über das Wasser zu erfahren, gibt es für DSL-Leitungen die so genannte DELT-Messung.
Also lautet die Frage für dieses Kapitel, die es zu beantworten gilt: Kennen Sie DELT?

Chat
GPT

So antwortet ChatGPT auf meine Fragen zu DELT-Messewerten einer VDSL-Leitung. 

Lesen Sie bitte den Dialog entweder vollständig oder in einer Zusammenfassung, um die Details des DRD DELT-quick-check-metrics genauer zu verstehen!

Story

In Kapitel 10 geht es um diese beiden Unterthemen: 

• Synchron-Zustand und Synchron-Qualität,
• Transportleistung insgesamt
  

Dann sind wir mittendrin im Thema und bereit für weitere Kapitel, die folgende Fragen behandeln werden:

• Kapitel 11) Wie ist die Qualität der Träger zu bewerten?
  
• Kapitel 12) Welche Layer-1-Fehlermeldungen sind auffällig in einer ad-hoc Messung?
• Kapitel 13) Sehen wir gestörte Zeiträume in einem 12 Stunden Monitoring-Log?
• Kapitel 14) Was ist eine gute Architektur für das Entscheidungsdiagramm und wie nutze ich es im Prozess?

Story

Tipp

Nutzen Sie die Matrix-Power! Ordnen Sie alle Inputs eines Entscheidungsdiagramms (DRD) am linken Rand untereinander an. Ordnen Sie rechts davon abgehend Literal Expressions und Entscheidungstabellen an. Ordnen Sie die Kaskadierung von Entscheidungstabellen von unten nach oben.

Hier ein Muster!

Tipp

Nutzen Sie Input-Dubletten! Identische Input data dürfen mehrfach im Entscheidungsdiagramm (DRD) auftauchen und werden auch identisch bei der Ausführung gefüllt.
Also brauchen Sie nicht Kreuz-und-Quer Linien, um Inputs an Literal Expressions oder Entscheidungstabellen zuzuführen.

Super
Tipp

Nicht der Bildschirm ist die Grenze, sondern Ihr Kopf!

Verengen Sie Ihr Denken und Ihr Design nicht auf die Größe des Bildschirms, den Sie gerade anstarren!
Genießen Sie stattdessen die unbegrenzte Höhe und Breite des DRD-Zeichenblatts!

Tipp

Entwickeln Sie - gerne auch im Team gemeinsam - auf der freien Fläche eines neuen Entscheidungsdiagramms (DRD) unter Zuhilfenahme der Matrix-Power  und der systematischen von links nach rechts und unten nach oben Kaskadierung auf der gesamten Höhe und Breite des Zeichenblatts, und schreiben dabei ständig gute und ausführliche Kommentare!

Versuchen Sie ähnlich zu arbeiten wie bei Mindmaps.

Story

Wie ist die Qualität der Träger zu bewerten?

Listen "bitloading" und "frequency_notches"

Story

Layer-1-Fehlermeldungen richtig interpretiert.

"errors"

Story

Monitoring Bucket auswerten

Story

Die Tipps von oben hier herunterholen ...

Story

Reserve ...

TM Forum: Reducing time-to-market with BPMN and DMN in telcos

https://inform.tmforum.org/features-and-opinion/reducing-time-to-market-with-bpmn-in-telcos