erste Fassung des Extracts von json files aus den Excel Dateien des Kontrolling geschrieben.
This commit is contained in:
+106
-8
@@ -386,14 +386,112 @@ Ausgabe:
|
||||
|
||||
## Umsetzungsphasen
|
||||
|
||||
| Phase | Beschreibung | Aufwand |
|
||||
|-------|---------------------------------------------------------------|-----------|
|
||||
| 1 | PoC: Ein Modul, ein Kapitel, zwei Sprachen, PDF | 2–3 Tage |
|
||||
| 2 | Base-Repo aufsetzen: Sphinx, Extensions, LaTeX-CI | 3–5 Tage |
|
||||
| 3 | Erste 5–10 Module migrieren, Glossar aufbauen | 1–2 Wochen|
|
||||
| 4 | JSON-Export aus ERP definieren, build.py fertigstellen | 2–3 Tage |
|
||||
| 5 | Pilotprojekt: Erste vollständige Anlagendokumentation | 1 Woche |
|
||||
| 6 | CI/CD: Automatischer Build via Gitea Actions oder n8n | 1–2 Tage |
|
||||
### Methodik (nach Alistair Cockburn)
|
||||
|
||||
Jeder Use Case durchläuft sieben Schritte bis zur Umsetzungsreife:
|
||||
|
||||
| Schritt | Aktivität | Verantwortung |
|
||||
|---------|--------------------------------------------------------|---------------|
|
||||
| 1 | Titel / Teaser, Prosa-Story | C (Kunde/PO) |
|
||||
| 2 | Stakeholder & Interessen / Anwender-Ziele identifizieren | T (Dev Team) |
|
||||
| 3 | Standard-Ablauf entwerfen (primäres Erfolgsszenario) | M (Member) |
|
||||
| 4 | Ausnahmen und Erweiterungen sammeln | T (Dev Team) |
|
||||
| 5 | Ausnahmen detaillieren, Schneiden in User Stories | M (Member) |
|
||||
| 6 | Business Value schätzen / Aufwand schätzen | T (Dev Team) |
|
||||
| 7 | Review: Prüfe alle Interessen, Definition of Ready | C (Kunde/PO) |
|
||||
|
||||
**Legende Verantwortung:**
|
||||
- **C** = Kunde / Product Owner (N.Sch, M.Ro)
|
||||
- **T** = Dev Team (F.Ve, A.Sch, M.St, D.Fe)
|
||||
- **M** = Einzelnes Dev Team Member
|
||||
|
||||
### Personen
|
||||
|
||||
| Kürzel | Rolle | Schwerpunkt |
|
||||
|--------|------------------------|-----------------------|
|
||||
| N.Sch | Stakeholder / PO | Fachliche Anforderungen |
|
||||
| M.Ro | Stakeholder / PO | Fachliche Anforderungen |
|
||||
| F.Ve | Dev Team | IT und KI |
|
||||
| A.Sch | Dev Team | Redaktion / Inhalte |
|
||||
| M.St | Dev Team | IT und KI |
|
||||
| D.Fe | Dev Team | Redaktion / Inhalte |
|
||||
|
||||
### Produktprogramm-Umfang
|
||||
|
||||
Basis für die Aufwandsschätzung: **1388 eindeutige Produktnummern** in 70 Produktgruppen über 5 Produktfamilien (CPC, GERÜST, ILS 2100, OMNIFLO, Trolleyprogramm). 129 Nummern erscheinen in mehreren Kapiteln.
|
||||
|
||||
### Projektplan
|
||||
|
||||
| Phase | Beschreibung | Aufwand | Beteiligte |
|
||||
|-------|--------------|---------|------------|
|
||||
| 0 | **Use-Case-Definition & Anforderungen** | | |
|
||||
| 0.1 | Story & Teaser: Zieldokumentation beschreiben, Prosa-Story je Produktfamilie | 2 Tage | D.Fe, A.Sch, M.St |
|
||||
| 0.2 | Stakeholder-Analyse: Alle Akteure und deren Interessen/Ziele auflisten | 1 Tag | F.Ve, A.Sch, M.St, D.Fe |
|
||||
| 0.3 | Standard-Ablauf entwerfen: Build-Pipeline, Redaktionsworkflow, Freigabeprozess | 2 Tage | M.St |
|
||||
| 0.4 | Ausnahmen sammeln: Sonderfälle (Mehrfachverwendung der 129 Nummern, Varianten, fehlende Übersetzungen) | 1 Tag | F.Ve, A.Sch, M.St, D.Fe |
|
||||
| 0.5 | Ausnahmen detaillieren, in User Stories schneiden | 2 Tage | F.Ve, M.St |
|
||||
| 0.6 | Aufwandsschätzung & Business Value für alle Stories | 1 Tag | F.Ve, A.Sch, M.St, D.Fe |
|
||||
| 0.7 | Review & DOR: Prüfung aller Interessen, Freigabe für Umsetzung | 1 Tag | N.Sch, M.Ro |
|
||||
| | | | |
|
||||
| 1 | **PoC: Proof of Concept** | | |
|
||||
| 1.1 | Ein Modul (z.B. OMNIFLO Weiche), ein Kapitel, zwei Sprachen (DE/EN), PDF-Ausgabe | 3 Tage | M.St, F.Ve |
|
||||
| 1.2 | LaTeX-Template mit Firmen-CI erstellen und validieren | 2 Tage | M.St, F.Ve, A.Sch |
|
||||
| 1.3 | PoC-Review mit Stakeholdern | 0,5 Tage | N.Sch, M.Ro, A.Sch |
|
||||
| | | | |
|
||||
| 2 | **Base-Repo & Infrastruktur** | | |
|
||||
| 2.1 | Repo-Struktur anlegen (transport-docs-base), Sphinx-Projekt initialisieren | 1 Tag | M.St |
|
||||
| 2.2 | Sphinx-Extensions implementieren (anlagen_builder, localized_figure, glossary_loader) | 4 Tage | M.St |
|
||||
| 2.3 | build.py: JSON-Parsing, Abhängigkeitsauflösung, Override-Mechanismus | 3 Tage | F.Ve, M.St |
|
||||
| 2.4 | CI/CD: Gitea Actions für automatischen Build | 2 Tage | M.St |
|
||||
| | | | |
|
||||
| 3 | **Produktprogramm-Strukturierung** | | |
|
||||
| 3.1 | Modulstruktur & meta.yaml-Schema je Produktfamilie definieren (5 Familien) | 3 Tage | A.Sch, M.St, D.Fe |
|
||||
| 3.2 | Nummernkreis-Mapping: 1388 Produkte auf Module abbilden, Gruppierung festlegen | 3 Tage | A.Sch, F.Ve, M.St |
|
||||
| 3.3 | Vorlage-Templates pro Kapiteltyp erstellen (Beschreibung, Wartung, Ersatzteile) | 2 Tage | A.Sch, M.St |
|
||||
| | | | |
|
||||
| 4 | **Content-Migration (Hauptaufwand)** | | |
|
||||
| 4.1 | CPC-Familie: 126 Produkte in 11 Gruppen – rST-Bausteine erstellen | 2 Wochen | A.Sch, F.Ve |
|
||||
| 4.2 | GERÜST-Familie: 263 Produkte in 14 Gruppen – rST-Bausteine erstellen | 1 Wochen | A.Sch, F.Ve |
|
||||
| 4.3 | ILS 2100-Familie: 396 Produkte in 27 Gruppen – rST-Bausteine erstellen | 3 Wochen | A.Sch, F.Ve |
|
||||
| 4.4 | OMNIFLO-Familie: 453 Produkte in 14 Gruppen – rST-Bausteine erstellen | 4 Wochen | A.Sch, F.Ve |
|
||||
| 4.5 | Trolleyprogramm: 191 Produkte in 4 Gruppen – rST-Bausteine erstellen | 2 Wochen | A.Sch, F.Ve |
|
||||
| 4.6 | KI-gestützte Textgenerierung: Vorlagen automatisiert befüllen (Beschreibungen, techn. Daten, Logische Schalter) | parallel | F.Ve, M.St |
|
||||
| 4.7 | Bildmaterial: Fotos/Zeichnungen zuordnen, optimieren, Pfadstruktur aufbauen | parallel | A.Sch, F.Ve |
|
||||
| | | | |
|
||||
| 5 | **Glossar & Mehrsprachigkeit** | | |
|
||||
| 5.1 | Glossar DE aufbauen (Fachbegriffe aus allen 5 Produktfamilien) | 1 Woche | A.Sch, D.Fe, M.St |
|
||||
| 5.2 | Glossar EN übersetzen | 1 Woche | A.Sch, D.Fe, M.St, V.Fe |
|
||||
| 5.3 | Stichproben-Übersetzung: 10% der Module auf EN migrieren | 2 Wochen | A.Sch, D.Fe, F.Ve |
|
||||
| | | | |
|
||||
| 6 | **ERP-Integration & Automatisierung** | | |
|
||||
| 6.1 | JSON-Export-Format mit ERP abstimmen (anlage.json-Schema) | 2 Tage | M.St, A.Jakob |
|
||||
| 6.2 | Validierungsskripte: meta.yaml-Konsistenz, fehlende Dateien/Übersetzungen | 2 Tage | M.St |
|
||||
| 6.3 | Hilfsskripte: dxf2svg, optimize_images | 2 Tage | F.Ve |
|
||||
| | | | |
|
||||
| 7 | **Pilotprojekt** | | |
|
||||
| 7.1 | Erste vollständige Anlagendokumentation (reales Kundenprojekt) generieren | 1 Woche | A.Sch, M.St, F.Ve |
|
||||
| 7.2 | Review mit Stakeholdern, Korrekturrunde | 3 Tage | N.Sch, M.Ro, A.Sch |
|
||||
| 7.3 | Lessons Learned, Backlog-Pflege | 1 Tag | F.Ve, A.Sch, M.St, D.Fe |
|
||||
|
||||
### Aufwandszusammenfassung
|
||||
|
||||
| Phase | Dauer (geschätzt) |
|
||||
|-------|-------------------|
|
||||
| 0 – Use-Case-Definition | ~2 Wochen |
|
||||
| 1 – PoC | ~1 Woche |
|
||||
| 2 – Base-Repo & Infrastruktur | ~2 Wochen |
|
||||
| 3 – Produktprogramm-Strukturierung | ~2 Wochen |
|
||||
| 4 – Content-Migration | ~10-12 Wochen (2 Redakteure parallel + KI-Unterstützung) |
|
||||
| 5 – Glossar & Mehrsprachigkeit | ~4 Wochen |
|
||||
| 6 – ERP-Integration | ~1 Woche |
|
||||
| 7 – Pilotprojekt | ~2 Wochen |
|
||||
| **Gesamt** | **~24 Wochen (6 Monate)** |
|
||||
|
||||
**Anmerkungen:**
|
||||
- Phase 4 ist der Hauptaufwand. Bei 1388 Produkten und 2 Redakteurinnen (A.Sch, F.Ve) parallel ergibt sich ca. 10 Wochen netto für die Content-Erstellung.
|
||||
- KI-gestützte Textgenerierung (F.Ve, M.St) kann den Aufwand in Phase 4 um geschätzt 30–50% reduzieren.
|
||||
- Phasen 4, 5 und 6 können teilweise parallelisiert werden, wodurch die Gesamtlaufzeit auf ca. 5 Monate verkürzt werden kann.
|
||||
- Die Schätzung basiert auf ~20 Produkte/Woche pro Redakteur bei mittlerer Komplexität (Beschreibung, techn. Daten, Wartungshinweise als rST-Bausteine).
|
||||
|
||||
## Coding-Konventionen
|
||||
|
||||
|
||||
@@ -148,3 +148,109 @@ Neues Konzept: Pro Sprache ein kompletter Dokumentenbaum auf Top-Level:
|
||||
- Zukuenftig: `chapters_en/`, `chapters_cz/` etc. als eigenstaendige Kopien
|
||||
|
||||
Fallback-Mechanismus: Fehlt ein Dokument in einer Fremdsprache, wird die deutsche Version verwendet.
|
||||
|
||||
|
||||
## Heutige Checkliste für die nötigen Dokumente aus der Automation
|
||||
|
||||
### 1. Layout Elektrik
|
||||
|
||||
- Elektrolayout
|
||||
- Layout Kabelpritsche und Erdung
|
||||
|
||||
### 2. Schaltplan & Pneumatikplan
|
||||
|
||||
- Schaltplan (WSCAD Elektrisch)
|
||||
- Pneumatikplan (WSCAD Elektrisch)
|
||||
- PDF-Ausgabe
|
||||
- Projektsicherung im WSCAD-Format
|
||||
|
||||
### 3. Layout Pneumatik
|
||||
|
||||
- Verschlauchungsplan
|
||||
|
||||
### 4. Ersatzteilliste Elektrik
|
||||
|
||||
- Ersatzteilliste für elektrische Komponenten als PDF-Dokument
|
||||
|
||||
### 5. Dokumentationen Elektrolieferanten
|
||||
|
||||
- Ablage der Datenblätter
|
||||
- Dokumentationen der Elektrolieferanten
|
||||
|
||||
### 6. Netzwerkstrukturplanung
|
||||
|
||||
- Netzwerkstrukturplanung (ProNetPlan / WSCAD)
|
||||
|
||||
### 7. Betriebsanleitung Steuerung
|
||||
|
||||
- Bedienhandbuch
|
||||
- Steuerungsanleitung
|
||||
|
||||
### 8. Software-Daten SPS
|
||||
|
||||
- SPS-Projektdaten mit Sicherung
|
||||
- PDF-Ausdruck des SPS-Programms
|
||||
|
||||
### 9. Sicherheitsausdruck SPS
|
||||
|
||||
- Sicherheitsausdruck der SPS-Software
|
||||
|
||||
### 10. Prüfprotokoll externe Gewerke
|
||||
|
||||
- Prüfprotokolle für externe Gewerke im eigenen Lieferumfang (z. B. Brandschutztüre)
|
||||
|
||||
### 11. Sistema Sicherheitsbetrachtung
|
||||
|
||||
- Sicherheitsbetrachtung gemäß Sistema als PDF-Dokument
|
||||
|
||||
### 12. Prüfprotokolle Schaltschränke
|
||||
|
||||
- Prüfprotokolle der Schaltschrankprüfung als PDF-Dokument
|
||||
|
||||
### 13. Lizenzen
|
||||
|
||||
- Softwarelizenzen (z. B. Sinamics, TIA Portal, OPC UA)
|
||||
|
||||
### 14. Abschaltmatrix
|
||||
|
||||
- Emergency-Stop-Matrix (Abschaltmatrix) als PDF-Dokument
|
||||
|
||||
### 15. Layout Sicherheitsbereiche
|
||||
|
||||
- Layout der Sicherheitsbereiche zur Abschaltmatrix
|
||||
|
||||
### 16. Validierungsprotokolle
|
||||
|
||||
Unterschriebene Validierungsprotokolle, bestehend aus:
|
||||
|
||||
#### 16.1 Prüfprotokoll ortsfester Arbeitsmittel
|
||||
- Elektrische Prüfung ortsfester Arbeitsmittel
|
||||
|
||||
#### 16.2 Erprobung Wiederanlauf
|
||||
- Schutz gegen automatischen Wiederanlauf
|
||||
|
||||
#### 16.3 Erprobung Drehrichtung Motoren
|
||||
- Test der Drehrichtung der Asynchronmotoren
|
||||
|
||||
#### 16.4 Berechnung Fehlerschleifenimpedanz / Validierung Erdung
|
||||
- Berechnung der Fehlerschleifenimpedanz
|
||||
- Erdungsvalidierung
|
||||
|
||||
#### 16.5 Erprobung Anzeige- und Bediengeräte
|
||||
- Test der Anzeige- und Bediengeräte
|
||||
|
||||
|
||||
# Fragen und TODOs
|
||||
|
||||
- [ ] Wie ist der Standardablauf der Dokumentation bisher?
|
||||
- [ ] Wer ist wann daran bei einem einfach Projekt daran beteiligt?
|
||||
- [ ] Was wäre bei einer Automatisierung der Dokumentations- Erstellung für die wünschenswert?
|
||||
- [ ] Welche Ausnahmen sind üblich, fehlt oft oder ist nicht immer dabei?
|
||||
- [ ] für wen ist die Dokumentation gedacht, bzw. was erwarten diese Leute zu finden?
|
||||
- [ ] Welche Detailierungstiefe bei den Produkten ist nötig oder gewollt?
|
||||
- [ ] soll die aktuelle Kapitelstruktur mit nur 4 Kapiteln beibehalten werden oder könnten wir dies auf ca. 7 - 10 Kapitel erweitern (siehe Vorschlag)?
|
||||
- [ ] in welchem Kapitel sollen die jeweiligen Dokumente aus der Automation landen?
|
||||
- [ ] Wie läuft die Ersatzteilfindung nach der Dokumentation statt?
|
||||
- [ ] Wie die Behandlung einer Anlage bei Fehler oder Störungen?
|
||||
- [ ] Welche Daten des Produktprogrammes sollen in die Dokumentation eingang finden?
|
||||
- [ ] Welche Abteilung liefert normalerweise was in der Dokumentation (Liste Automation ist vorhanden, Was passiert bei Sonderkonstruktionen)?
|
||||
Reference in New Issue
Block a user