ath.ai – Datenhoheit & Release & Soft-Governance

Source of Truth (SoT) Hierarchie und Datenfluss-Architektur

Nur als Diskussionsgrundlage zu verstehen

SoT SAP-First Risk-Analyses

📋 Executive Summary

Das SAP-First Prinzip definiert klare Verantwortlichkeiten: SAP ist die einzige Quelle der Wahrheit (SoT) für Artikelstammdaten. Alle anderen Systeme (PIM, Vault, Git, Filesystem) haben spezialisierte SoT-Rollen, während ath.ai als Engineering-Struktur-Koordinator fungiert.

Diese Architektur verhindert Dateninkonsistenzen durch eine unidirektionale Datenfluss-Hierarchie: Stammdaten fließen von SAP → ath.ai (read-only), Produkt-Content von PIM → ath.ai, während Release-Artefakte von ath.ai, Vault und Git → Filesystem exportiert werden.

🎯 System-Übersicht: SoT-Hierarchie

Jedes System hat eine klar definierte Rolle als Source of Truth (SoT) oder Storage:

🤖 ath.ai

SoT – Engineering-Struktur

Koordiniert alle Engineering-Prozesse [CAD, Docs, Soft] (ohne Eingriff), verwaltet BOM, Status,Freigabe, Baselines, CHANGELOG.md, DB-Relationen (depends_on, where_used, derived_from). Die Sof-Governance bedeutet, dass ath.ai keine Schreibrechte in SAP oder PIM hat. Datenfluss ist strikt unidirektional. und die Arbeitsweise in den Originalsystemen bleibt unverändert. Jeder Arbeitet in seinem gewohnten System weiter.

📦 SAP

SoT – Artikelstamm

Einzige Quelle für Artikelnummern, "BOM-Strukturen" Evtl. später (Momentan in ath.ai), Freigabestatus (in ath.ai). Andere Systeme konsumieren read-only.

📄 PIM

SoT – Produkt-Content

Master für Produktbeschreibungen, Marketing-Content, Spezifikationen, related Docs als links. Freigegebene Inhalte fließen zu ath.ai und zur Website. Die Verwaltung in PIM basiert auf die SAP-Artikelnummern, Diese Nummer Garantiert die Konsistenz der Verbindung (SAP-First). Aus PIM werden die Inhalte in die Website und in ath.ai exportiert. Somit ist PIM die SOT für alle Marketing- und ProduktInformationen (VOM IST-ZUSTAND).

🔧 Vault

SoT – CAD-Quellen

Versionskontrolle für CAD-Dateien (.ipt, .iam). Released-Versionen werden als Pack&Go exportiert ohne Umversionierung im Filenames damit referenzen erhalten bleiben. Es muss noch geklärt mit Florin werden welche exporte aus Vault bei unseren Konstruktionen möglich sind, welche Metadata in dem CAD und ob die Versionsnummer in den Dateieigenschaften angepasst wird.

💻 Git

SoT – Software Source

Master für Software-Code (Embedded, HMI, Interfaces). Release-Bundles mit Manifest werden exportiert. Es muss noch geklärt werden mit Alex und Maik ob Binaries/Artefakte im Git-Repository gespeichert werden oder in einem separaten Artefakt-Repository (und voralem wann ).

💾 Filesystem

Storage – nicht SoT

Ablage für Exports, Baselines (read-only), Hash-Manifeste . Keine aktive Versionskontrolle kein OS-Eingriff, nur Speicherung. Hier für müssen wir uns gemeinsam auf eine Engineering-Struktur einigen und dann einen Migrationsplan erstellen. Jede Mitwirkung von den beteiligten ist hier notwendig und Willkommen. Jeder Vorschlag wird gerne entgegengenommen analisiert und besprochen. Wir alle sind für das Endergebnis zuständig.

🌟 Zentrale Rolle: ath.ai als Engineering-Koordinator

ath.ai ist kein isoliertes System, sondern der zentrale Knotenpunkt für Engineering-Sof-Governance , das heisst ohne Eingriff in die Originalsysteme und Arbeitsweise.:

🔑 Regel: ath.ai schreibt niemals zurück zu SAP oder PIM. Datenfluss ist strikt unidirektional. ath.ai ist aber bei Wunsch bestimmte Hilfsmittel zur Verfügung stellen, um Ordnerstruktur zu erstellen, Baselines halbautomatisch über lokale Scripte zu erstellen (Kopien erstellen und zu prüfen).

🔄 Datenflüsse: 5 Hauptverbindungen

Alle Datenströme folgen einer klaren Hierarchie ohne Rückflüsse:

📦 SAP
→
🤖 ath.ai
Stammdaten Pull (read-only)
Artikelnummern, (BOM-Strukturen eventuel Später, Erste Schritt über ath.ai)
📄 PIM
→
🤖 ath.ai
Produkt-Content (freigegeben)
Produktbeschreibungen, Spezifikationen, Marketing-Texte
🤖 ath.ai
→
💾 Filesystem
Baselines/Exports + Hash-Manifest
Immutable Snapshots, CHANGELOG.md, baseline_manifest.json
🔧 Vault
→
💾 Filesystem
CAD Release-Exporte + Pack&Go
Released CAD-Modelle, Zeichnungen (PDF), STEP/IGES Exports
💻 Git
→
💾 Filesystem
Release-Bundle + Manifest
Getaggte Software-Versionen, Binaries, Deployment-Artefakte. Minimale Anforderung Aktuelle Freigegebene Binary im PRD-Folder

📖 Legende: Begriffsdefinitionen

SoT (Source of Truth)

Einzige autoritative Quelle für eine Datendomäne. Andere Systeme konsumieren read-only.

Storage (Ablage)

Speicherort ohne aktive Versionskontrolle. Nur für Exports und Archivierung.

Read-only Spiegel

Konsumiert Daten aus SoT. Keine Schreibrechte auf Original-Quelle.

🔧 Workflow-Szenarien

Szenario 1: Neues Produkt entwickeln

  1. SAP: Artikelnummer anlegen (z.B. PRD-612030) → Freigabestatus "Draft"
  2. ath.ai: Artikelnummer aus SAP pullen (read-only), PRD-Ordner erstellen
  3. Vault: CAD-Assembly entwickeln, Parts referenzieren
  4. ath.ai: BOM-Start aus CAD exportieren (S-PRD-612030.xlsx)
  5. PIM: Produktbeschreibung erstellen, freigeben
  6. ath.ai: PIM-Content pullen → P-PRD-612030.pdf konsolidieren
  7. ath.ai: Baseline erstellen (V1) → Filesystem (immutable Snapshot)
  8. SAP: Freigabestatus ändern "Draft" → "Released"

Szenario 2: Ersatzteil anfragen

  1. SAP: Artikelnummer + Seriennummer identifizieren (z.B. 612016 / S12345)
  2. ath.ai: Baseline öffnen (PRD-612016__V1_2024-03-15)
  3. Filesystem: baseline_manifest.json prüfen → alle Dependencies mit Hash-Werten
  4. Vault: CAD-Dateien aus Baseline öffnen (Säule Typ A, Zylinder 60x1500)
  5. Fertigung: Ersatzteil produzieren mit exaktem Stand von Release V1

Szenario 3: Common Subsystem ändern

  1. ath.ai: Where-Used prüfen (welche Produkte verwenden Zylinder_60x1500?)
  2. ath.ai: Change Request anlegen (CR-2025-042)
  3. ath.ai: Impact definieren: "compatible" oder "breaking"
  4. Vault: Zylinder bearbeiten, Revision in DB hochsetzen (V1 → V2)
  5. ath.ai: Effectivity festlegen: Roll-forward (Draft-Produkte) / Freeze (Released-Produkte)
  6. ath.ai: CHANGELOG.md aktualisieren mit CR-Referenz

⚠️ Regeln & Best Practices

🚫 Niemals: Von ath.ai zurück zu SAP oder PIM schreiben. Datenfluss ist strikt unidirektional.
✅ Immer: SAP-Artikelnummern als read-only behandeln. Änderungen nur in SAP, dann Pull zu ath.ai.
📋 Baseline-Strategie: Vor jedem Major-Release (V1, V2, V3) Baseline erstellen mit vollständigen Dependencies.
⚡ Breaking Changes: Neue Objekt-ID/Nummer vergeben. Alte Revision bleibt in Baseline verfügbar (Ersatzteilsicherheit).

🔗 Integration mit Engineering-Konzept

Das SAP-First Prinzip ergänzt das ATH Engineering-Strukturkonzept:

Aspekt Engineering-Konzept SAP-First Prinzip
Artikelnummern PRD-Ordner: PRD-612016__ATH-Single-Lift__12PL SAP ist SoT für "612016", ath.ai konsumiert read-only
BOM-Start Exportiert aus CAD: S-PRD-612016.xlsx Wird zu ath.ai → (SAP-Artikelnummer aus dem SAP-Import)-Matching (Auto + Manuell)
Produktbeschreibung Konsolidiert aus column_lift/DOC/description/ PIM ist SoT für Marketing-Content → Pull zu ath.ai (Nur XML Inhalt und Links für Rag_system. Keinne physikalische Kopien)
CAD-Dateien Referenziert aus column_lift/CAD/prt/ + common/Subsystems/ Vault ist SoT → Pack&Go Export zu Baseline-Filesystem bei Release
Software In column_lift/Soft/Embedded/ Git ist SoT → Release-Bundle zu Filesystem bei Tag. Frage ist, ob die Software-Release-Bundles (Code & Binary oder Nur Binaries) in das Filesystem exportiert werden sollen.
Baselines Immutable Snapshots in baseline/PRD-612016__V1_2024-03-15/ ath.ai exportiert zu Filesystem mit Hash-Manifest

© 2025 ATH - Workflow: SAP-First