# Drei Systeme, ein Bildschirm und eine zuvor von Hand gezeichnete Route > Wie der Vertrieb eines Konnektivitätsanbieters Verfügbarkeit und Preise auf einem Bildschirm erhielt: aus ERP, CRM und einem bislang getrennten GIS-Portal. Source: https://redbumerang.com/de/fallstudien/vertriebsunterstutzung/ Prozess-KI / Telekommunikation Jede Anfrage beginnt gleich: Können Sie diese Adresse versorgen, und welchen Preis sollten wir verlangen? Eine belastbare Antwort erforderte, vier Dinge von Hand zusammenzustellen, aus Systemen, die nicht miteinander kommunizieren. *Kunde anonymisiert. Zahlen am Produktivsystem gemessen, 6. September 2026.* ## Das Problem Ein Vertriebsmitarbeiter konnte die erste Kundenfrage nicht beantworten, ohne drei Systeme und eine Karte zu öffnen. Bei einem Anbieter von Geschäftskunden-Konnektivität beginnt jede Anfrage gleich: Können Sie diese Adresse versorgen, und welchen Preis sollten wir verlangen? Eine belastbare Antwort erforderte, vier getrennte Dinge von Hand zusammenzustellen. Was kauft dieser Kunde bereits, und zu welchem Preis? Das steht im ERP, Microsoft Dynamics NAV: zehn Jahre Rechnungspositionen, mit dem Leistungsort als Freitext. Haben wir für diese Adresse schon ein Angebot erstellt? Das steht im CRM, Intrix. Oft ließ sich die Frage schlicht nicht beantworten: Weniger als zwei Drittel der Angebote enthalten überhaupt eine genaue Leistungsadresse. Deshalb war die Antwort häufig nicht auffindbar, obwohl sie existierte. Welche Infrastruktur liegt tatsächlich in dieser Straße? Das steht in iObčina, dem öffentlichen kommunalen GIS-Portal: eine separate Webanwendung, Abfrage für Abfrage je Adresse. Und wenn der Kunde eine private Verbindung zwischen zwei eigenen Gebäuden wünscht, musste jemand eine physische Glasfasertrasse planen. Kabel verlaufen nicht geradlinig. Sie folgen Leerrohren, Masten und Gräben verschiedener Eigentümer: des Übertragungsnetzbetreibers, der regionalen Stromverteiler, des Telekommunikationsanbieters selbst. Eine Route zu planen bedeutet, diese Netze zu verbinden, die Übergabepunkte zwischen Eigentümern festzulegen und Unterlagen zu erstellen, mit denen man jeden Eigentümer um Genehmigung und Preis anfragen kann. Das wurde von Hand über mehrere Karten hinweg gezeichnet. Von Hand zusammengestellt dauerte das bis zu einen Monat. Ein Monat zwischen der Kostenanfrage des Kunden für eine Verbindung und dem Angebot. Die Zeit floss nicht in Verhandlungen oder technische Planung, sondern in die Recherche in drei Systemen und das Zeichnen einer Linie auf einer Karte. Und ein so langsamer Schritt wird ausgelassen. Ein Angebot, das weder bestehende Kundenpreise noch vorhandene Infrastruktur im Boden berücksichtigt, ist eine Schätzung. ## Was Red Bumerang gebaut hat Ein Bildschirm. Eine Adresse eingeben. Zurück kommt alles, was früher von Hand zusammengestellt wurde: Bestandskunden nahe dieser Adresse mit ihren Leistungen und Monatspreisen, frühere Angebote an diesem Standort, ein Preisvergleich nach Geschwindigkeit und die öffentliche Versorgungsinfrastruktur an diesen Koordinaten. Dargestellt auf einer interaktiven Karte über Luftbildern, mit einem Kunden-PDF im Unternehmensdesign auf einen Klick. Und ein zweiter Modus, der die Route plant. Nach Eingabe zweier Adressen schlägt das System bis zu drei physische Glasfaserrouten zwischen ihnen vor, über die kartierten Netze von acht Infrastruktureigentümern: dem nationalen Übertragungsnetzbetreiber ELES (1.454 km kartiert), den regionalen Verteilern Elektro Ljubljana (1.066 km), Elektro Maribor (847 km), Elektro Celje (267 km), Elektro Gorenjska (98 km) und Elektro Primorska (95 km), dem Stromerzeuger DEM (135 km) sowie der kundeneigenen Glasfaser (587 km). Es bietet die kürzeste Route, die Route über die wenigsten Eigentümer und die mit den wenigsten einzelnen Ausfallpunkten. Jeder Übergang zwischen den Netzen zweier Eigentümer wird markiert, denn in der Realität ist jeder ein Spleiß: ein Kostenpunkt, eine Genehmigung und eine mögliche Unterbrechungsstelle. Die Route wird als Google-Earth-Datei mit einem Ordner je Infrastruktureigentümer exportiert. So schickt der Kunde jedem Eigentümer genau den Abschnitt, der dessen Netz durchquert, und nichts anderes. ## Was dafür nötig war Zehn Jahre Abrechnungshistorie, erstmals nach Standort durchsuchbar. 138.019 Rechnungspositionen aus 51.503 Rechnungen, zurück bis 2016. Die Leistungsadresse war nie ein strukturiertes Feld. Deshalb wurden 165.853 Leistungsendpunkte aus Freitext ausgelesen, der zuvor überhaupt nicht geografisch durchsuchbar war. Verbindungsgeschwindigkeiten wurden aus 77.454 manuell eingegebenen Positionen rekonstruiert. Die Infrastruktur von acht Eigentümern, für die Routenberechnung erschlossen. 20.721 Netzobjekte, darunter 5.644 Leitungen mit insgesamt rund 4.549 km, wurden zu einem einzigen Graphen vereint, den die Routenberechnung durchlaufen kann. ## Was sich geändert hat Von bis zu einem Monat auf Minuten. Die benötigten Daten erreichen den Vertrieb jetzt in Minuten, statt über Wochen zusammengestellt zu werden. Und auch das Angebot geht in Minuten an den Kunden. Aus dem Monat wurde keine Woche. Es wurde die Zeit, die das Eingeben einer Adresse dauert. Das ist der gesamte Ertrag des Projekts. Seine Herkunft sollte präzise benannt werden: nicht dieselbe Arbeit schneller erledigen, sondern sie gar nicht mehr erledigen müssen. Niemand schlägt mehr etwas in drei Systemen nach. Niemand zeichnet eine Route von Hand. Die Abfragen geschehen, weil eine Adresse eingegeben wurde. ## Wo die KI tatsächlich steckt Zur Laufzeit gibt es keine — und das ist die richtige Antwort. Eine Route über 4.549 km fremder Infrastruktur zu finden, ist ein Kürzeste-Wege-Problem auf einem Graphen, kein Ermessensurteil. Welche Kunden nahe einer Adresse liegen, ermittelt ein räumlicher Index. Beides muss exakt, schnell und erklärbar sein. Ein Modell würde alle drei Eigenschaften verschlechtern. KI war der Motor der Entwicklung. Ohne sie würde dieses System nicht existieren. Zwei der drei Systeme boten keinen Zugang. Daten aus Dynamics NAV zu gewinnen, erfordert normalerweise einen NAV-Entwicklungspartner. Das ist der unterstützte Weg. Wer dafür ein Angebot eingeholt hat, kennt Kosten und Dauer. Hier wurde kein Partner beauftragt. Stattdessen wurde eine ausschließlich lesende Brücke gebaut, die auf dem eigenen Windows-Server des Kunden läuft, abgesichert durch einen API-Schlüssel und eine IP-Freigabeliste. iObčina hat überhaupt keine öffentliche API. Es ist eine Browseranwendung, die undokumentierte Endpunkte anspricht. Die entscheidenden Daten, der Versorgungsinfrastrukturbericht für bestimmte Koordinaten, liegen hinter einer Anmeldung. Beide wurden auf dieselbe Weise erschlossen: den tatsächlichen Datenverkehr beobachten, die Schnittstellenverträge ermitteln und als dokumentierte Clients nachbauen. Diese Vertragsdokumente sind nun die maßgebliche Grundlage beider Integrationen. Das ist der Unterschied zwischen einem Skript, das zufällig funktioniert, und einer Integration, die jemand anderes warten kann. Beim dritten System war nichts davon nötig. Intrix bietet eine dokumentierte Exportschnittstelle. Sie wurde einfach wie vorgesehen genutzt. Zwei von drei, nicht drei von drei. Das ist wichtig, denn Reverse Engineering war der letzte Ausweg, nicht der erste Schritt. Das ist die ganze These in einem Projekt. Der schwierige Teil war nie der Algorithmus. Es war, Daten aus Systemen zu gewinnen, die nie dafür vorgesehen waren, sie herauszugeben. ## Der Teil, den der Kunde nicht angefragt hatte Die wertvollsten Ergebnisse waren Berichte über seine eigenen Daten. Zehn Jahre Datensätze für die Routenberechnung nutzbar zu machen, bedeutete, sie alle zu lesen. Dabei kamen Dinge ans Licht, die niemand kannte: - 233 Intrix-Konten mit der NAV-Kundennummer eines anderen Unternehmens, wodurch unbemerkt der falsche Kundendatensatz geöffnet worden war. - 3.001 Lücken in der eigenen Infrastrukturkarte: 264 Stellen, an denen ein Kabel einfach endet, ohne etwas in Spleißreichweite, die größte Lücke 903 Meter lang, sowie 2.737 Stellen, an denen zwei Leitungen desselben Eigentümers in weniger als 60 Metern Abstand verlaufen, ohne verbunden zu sein. Beides wurde als Arbeitsdatei übergeben: eine Tabelle und eine Google-Earth-Ebene. Beides lag außerhalb des Auftrags. Beides könnte ebenso viel wert sein wie die Anwendung. ## Methode Was die Zahlen zählen. Alle Mengen wurden am 6. September 2026 durch direkte Abfrage der Produktivdatenbank gemessen und sind seit der ersten Synchronisierung kumuliert. Die 138.019 Rechnungspositionen decken den Zeitraum vom 01.01.2016 bis zum 31.07.2026 ab, vollständig, nicht als Stichprobe. 4.549 km ist die summierte Länge kartierter Leitungsobjekte von acht Eigentümern. 165.853 Endpunkte und 77.454 Geschwindigkeiten sind die erfolgreich ausgelesenen Angaben. Der Rest bleibt bewusst unausgelesen, weil dasselbe Freitextfeld auch Faserpaarzahlen, Kilowatt und Rackflächen enthält und der Parser nicht rät. Woher der Vorher-nachher-Vergleich stammt. „Bis zu einem Monat“ und „Minuten“ sind die eigenen Angaben von Red Bumerang und dem Kunden zum Vertriebsprozess vor und nach der Umstellung, keine Zeitstudie. Vor der Entwicklung wurde der manuelle Prozess nicht formal gemessen. Das wird offen benannt und nicht als Messung dargestellt. Was nicht behauptet wird. Es werden keine Nutzungszahlen veröffentlicht. Das Suchprotokoll kann tatsächliche Vertriebsaktivität nicht von automatisiertem Testverkehr trennen. Deshalb werden weder Akzeptanz- noch Volumenzahlen genannt. Umfang. Ein Kunde, ein Land, seit Juli 2026 im Produktivbetrieb und in laufender Weiterentwicklung. --- ## Bringen Sie uns einen Prozess oder einen Markt mit. Jedes System hier begann mit einem Gespräch über Arbeit, die bereits stattfand: wie sie tatsächlich abläuft, wo sie am meisten kostet und welche Ordnung ihr zugrunde liegt. Darum geht es im ersten Gespräch.