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.
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 Startbereich 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 Anwendungsbereich 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

So antwortet ChatGPT auf meine Fragen zu analogen galvanischen Messewerten einer VDSL-Leitung.
Verfolgen Sie den Dialog, um die Details des DRD MSAN-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