Manuel Hartmann ITK Dienstleistungen

Projekt

Die Systemlandschaft eines Telekom-Partners

Warenwirtschaft, Shop, Odoo-Anbindung und ein eigener Agenten-Mandant für einen Telekom-Partner mit zwei Standorten.

mediazehe.de
Ausgangslage

Ein Fachhändler, der alles selbst macht

mediazehe ist Telekom-Partner in Haßfurt mit zweitem Standort in Schweinfurt: Mobilfunk und Festnetz, Glasfaser, IT und Netzwerktechnik, Telefonanlagen, Werkstatt. Fünf Leistungsfelder, zwei Ladentheken, ein Außendienst — und Abläufe, für die es kein passendes Werkzeug gab: Vertragsgeschäft mit Laufzeiten und Provisionsabrechnungen, Reparaturannahme, Inventur über Standorte, Kasse und Kundenakte in einem Vorgang.

Hier entstand über anderthalb Jahrzehnte der Vorgänger von mediakiss: 40 Fachbereiche, die zusammenhängen, weil der Betrieb zusammenhängt. Das erste selbstgebaute Werkzeug war eine Prüfung, die fremde Provisionsabrechnungen gegenrechnet und Widersprüche erzeugt.

Heute läuft für mediazehe die zweite Instanz des neuen mediakiss — derselbe Code wie bei TechFluxx, eigene Datenbank, eigene Konfiguration, eigene Farbe. Daneben ein Shop auf Shopware, die Einführung von Odoo als neue Warenwirtschaft mit Anbindung an mediakiss, und ein eigener Mandant in der Agenten-Plattform Olymp.

Was diese Landschaft von der bei TechFluxx unterscheidet, ist nicht der Code, sondern die Grenze: Beide Betriebe teilen keine Datenbank, keinen Tresor, keinen Runner. Die Mandantentrennung ist hier keine Hygiene zwischen Systemen, sondern eine Grenze zwischen Häusern — und wird entsprechend ernst genommen.

Auf einen Blick
Aufbau

Gleiche Plattform, harte Grenze

Links die Systemlandschaft von mediazehe, rechts die von TechFluxx. Was in der Mitte steht, ist derselbe Code — und trotzdem nichts Gemeinsames.

Zwei Mandanten auf derselben Plattform Zwei Spalten: links mediazehe mit Warenwirtschaft, Shop, Odoo-Anbindung und Agenten-Mandant; rechts TechFluxx mit Warenwirtschaft, Shop und Agenten-Mandant. In der Mitte eine gestrichelte Trennlinie. Unten die gemeinsame Grundlage: derselbe Code für mediakiss und Olymp, aber je Mandant eigene Datenbank, eigener Tresor, eigener Runner. mediazehe Warenwirtschaft Shop Odoo-Anbindung Agenten-Mandant EIGENE DATENBANK · EIGENER TRESOR · EIGENER RUNNER HARTE TRENNUNG TechFluxx Warenwirtschaft Shop Marktplätze Agenten-Mandant EIGENE DATENBANK · EIGENER TRESOR · EIGENER RUNNER Gemeinsam ist nur der Code: mediakiss und Olymp — ausgerollt über das Änderungsjournal, nie kopiert
Ein Fehler in einem Mandanten kann den anderen nicht erreichen — das ist die Bauvorschrift, nicht der Wunsch.
  1. 01

    Der Vorgänger

    40 Fachbereiche in einem Programm: Warenwirtschaft, Kasse, Kundenakte, Tickets, Werkstattaufträge, Verträge, Provisionen, Außendienst, Zeiterfassung, Dokumente, Lieferanten-EDI. Anderthalb Jahrzehnte im täglichen Einsatz.

  2. 02

    mediakiss, zweite Instanz

    Derselbe Code wie bei TechFluxx, mit eigener Konfiguration und eigener Farbe. Jede Änderung kommt über das Änderungsjournal an — mit Risikostufe und Anleitung, nicht per Kopie.

  3. 03

    Shop

    Shopware-Shop für das Sortiment des Fachhändlers, mit denselben Bausteinen wie bei vulpano.de — angepasst an ein anderes Sortiment und andere Lieferanten.

  4. 04

    Odoo-Anbindung

    Odoo wird die neue Warenwirtschaft des Betriebs. mediakiss liest die Bestände direkt daraus statt aus Export-Dateien — eine frische Datei ist noch kein gültiger Inhalt, deshalb mit Plausibilitätsprüfung.

  5. 05

    Agenten-Mandant

    5 Agenten in Olymp — Vorstand, Systembetrieb, Produktdaten, Einkauf, Berater — unter eigenem Benutzer mit eigenem Tresor. Der Systembetrieb-Agent erreicht nur die eigenen Hosts.

  6. 06

    Marktplatz-Anbindung über lokale Modelle

    Kaufland-Export mit Preis- und Textpipeline auf demselben Modellrechner wie TechFluxx — aber je Mandant eigene Läufe, eigene Grenzen.

  7. 07

    Infrastruktur

    Virtualisierung, Netzsegmentierung nach Rollen, verschlüsselte Standortkopplung, Firewall-Härtung Schritt für Schritt mit Freigabe je Änderung, zentrale Wissensbasis für den Systembetrieb.

  8. 08

    Zentrale Wissensbasis

    Die Dokumentation des Systembetriebs liegt in einem eigenen Git-Verzeichnis je Mandant, bidirektional mit den Agenten synchronisiert — mit Herkunft, Vertrauensgrad und Datum je Eintrag.

Integrationen

Was angebunden ist

Systeme

  • mediakiss
  • Odoo
  • Shopware
  • Olymp
  • Kaufland

Infrastruktur

  • Proxmox
  • pfSense
  • Omada
  • IPsec
  • Vaultwarden
  • Gitea
  • FritzBox

Leistungsfelder

  • Mobilfunk & Festnetz
  • Glasfaser
  • IT & Netzwerk
  • Telefonanlagen
  • Werkstatt
Was daran schwer war

Drei Vorfälle, die Regeln wurden

  1. 01

    Wissen aus dem falschen Betrieb

    Beim Aufbau des Systembetriebs-Agenten für TechFluxx wurde die Wissensbasis von mediazehe mitkopiert — neun von zehn Dateien beschrieben den falschen Betrieb. Ein Agent, der autonom handelt, hätte auf die falschen Adressen gezielt.

    Lehre: Wissen braucht Herkunft und Mandant als Pflichtfeld — und wird bereinigt, bevor jemand autonom handelt. Vorschlag ist nicht Tatsache →

  2. 02

    Die Firewall, die still Ja sagte

    Beim Härten der Firewall antwortete die Wiederherstellung einer Regelgruppe mit Erfolg — und hatte alles wiederhergestellt statt der einen Gruppe. Der Statuscode war grün, das Ergebnis falsch.

    Lehre: Jede Härtungsstufe wird einzeln freigegeben und am Ergebnis geprüft, nicht an der Antwort des Geräts. Am Artefakt prüfen →

  3. 03

    Erst der zweite Runner beweist die Trennung

    Die Mandantentrennung war entworfen, bevor es den zweiten Mandanten gab. Bewiesen war sie erst, als der Runner von mediazehe die Zugangsdaten von TechFluxx nachweislich nicht lesen konnte — und umgekehrt.

    Lehre: Eine Grenze, die nie von der anderen Seite geprüft wurde, ist eine Behauptung. Eine Schranke, die beim ersten Widerspruch fällt, ist keine →

Woran ich gerade arbeite

Drei Baustellen, nach Priorität

Verweise

Dazu gehört