Gap-Analyse Access-Appl → appl-v2 · Schenker Hydraulik · Stand 16.07.2026
Gap-Analyse · Entwurf zum Review
Gap-Analyse — Access-Appl → appl-v2-Entwürfe
Abgleich des Feature-Inventars der Legacy-Access-Anwendung mit den appl-v2-Entwürfen. Ziel: sichtbar machen, welche Alt-Funktionen in den Entwürfen noch nicht abgebildet sind — als Checkliste für Feinkonzept und Go-live-Scope.
Abgleich des Feature-Inventars der Legacy-Access-Anwendung (access-appl/docu/) mit den appl-v2-Entwürfen (Mockups Stand 13.07.2026 + Workshop 02.07.2026).
Status
Bedeutung
✅ abgedeckt
in den Entwürfen abgedeckt (ggf. neu gedacht)
🟡 teilweise
teilweise/anders abgedeckt — Detailklärung nötig
❌ fehlt
fehlt in den Entwürfen, kein bewusster Entscheid bekannt
Konditionen-Tab vorgesehen, aber kein Entwurf; Workshop fordert zusätzlich Stundensätze/Rabatte pro Kunde
EUR-Stundensatz-Prozent pro Kunde (HST)
🟡 teilweise
wird heute DB-seitig gepflegt (tmtnProzentStundensatz je Abteilung, SP-gesetzt für HST/EUR-Kunden), nicht in Access — im neuen Konditionen-Modell abbilden oder bei der Stundensatz-Pflege im Dashboard belassen (vgl. Kap. 10)
Auftrag-States (Angemeldet, Eröffnet, In Bearbeitung, Fertig bearbeitet, Archiviert, Reaktivieren)
🟡 teilweise
Neues Statusmodell (Auftrags-/Warenstatus) deckt den Lebenszyklus anders ab — Mapping Alt-States → Neu definieren (u.a. Archivieren/Reaktivieren fehlt sichtbar)
Kontroll-States (Zu kontrollieren / Kontrolliert)
🟡 teilweise
Endkontrolle neu strukturiert; expliziter Kontroll-Workflow-Status klären
Prüfprotokoll-State „Zylinder entsorgen"
❌ fehlt
Entsorgungs-Fall im neuen Prozess nicht abgebildet
Instandsetzung-Tab zeigt Arbeit pro Auftrag; die auftragsübergreifende Arbeitsvorrats-Liste je Team fehlt als Entwurf (Workshop will sie behalten: „pro Abteilung wie heute")
Produktion: MA zuweisen, Position schieben
🟡 teilweise
MA-Zuordnung pro Bearbeitung vorhanden; Priorisieren/Schieben über Aufträge hinweg (Teamleiter-Tagesplanung) ohne Entwurf
Produktionsliste drucken
❌ fehlt
Druck-/Listen-Ausgaben generell offen
Auftragszettel / Teilezettel (Werkstattpapiere)
🟡 teilweise
Prozess wird digital (Tablet-Nutzung heute schon); ob Werkstatt-Druckpapiere noch nötig sind, entscheiden
Grösster zusammenhängender Gap — der Prozessschritt Rechnung hat noch keinen Entwurf, und die nachgelagerte Finanzverwaltung ist in den Entwürfen nicht abgebildet.
Grundsatzentscheid offen — Kopplung an externes Rechnungssystem (Workshop, Transkript ~Z. 2270–2281): Schenker prüft, ob appl-v2 die Rechnungsstellung selbst abdeckt oder die Rechnungsdaten nur an ein bestehendes Rechnungsprogramm übergibt („müssen wir nur übergeben … dann sehe ich ungefähr, wo die Schnittstellen sind"). Ein externes Rechnungsprogramm ist heute bereits im Einsatz (Transkript ~Z. 1127–1139, inkl. Mengen-/Grössenlimiten, die es zu beachten gilt). Die nachgelagerten Finanzthemen (Mahnwesen, Zahlungen, CAMT, Kundenkonto) wurden im Workshop nicht diskutiert.
Daraus zwei Szenarien für die Tabelle unten:
Szenario A — Eigenabdeckung: appl-v2 übernimmt das Belegwesen inkl. Zahlungsverkehr; die ❌-Zeilen sind dann Umsetzungsumfang
Szenario B — Übergabe/Kopplung: appl-v2 erzeugt die Rechnungsdaten (Positions-Baum, Kap. 6.9 Grobkonzept) und übergibt an das externe Rechnungsprogramm; Rechnungsnummern, QR-Rechnung, Mahnwesen, Zahlungen/CAMT und Kundenkonto liegen dann im externen System — aus den ❌-Features werden Schnittstellen-Anforderungen (Übergabeformat, Statusrückmeldung „bezahlt/gemahnt", Mengenlimiten)
„Betriebsnotwendig" in den Bemerkungen heisst: muss zum Go-live irgendwo existieren (appl-v2 oder externes System) — der Parallelbetrieb der Access-App kann sonst nicht enden.
Empfehlung: Den Grundsatzentscheid Szenario A vs. B vor der Umsetzungsplanung fällen — er verändert den Projektumfang massgeblich (eigenes Arbeitspaket Belegwesen/Zahlungsverkehr vs. Schnittstellen-Arbeitspaket). Unabhängig vom Szenario bleiben in appl-v2: Offerte/AB (bereits entworfen), Lieferschein/Empfangsbestätigung, die Rechnungserstellung aus dem Positions-Baum (Vier-Sichten-Modell) und die Rechnungskontrolle als Führungssicht. Bei Szenario B früh klären: Übergabeformat/Volumen-Limiten des Rechnungsprogramms, Rückmeldung von Zahlungs-/Mahnstatus für das Kundenkonto in appl-v2.
07 Dokumente / DMS / PDF / E-Mail
Alt-Feature
Status
Bemerkung
Dokumentablage an Kunde/Auftrag/Teil
✅ abgedeckt
überall vorgesehen, inkl. Fotos und E-Mail-Ablage — konzeptionell stärker als Alt-App
Beleg-PDFs automatisch ablegen (store* bei Druck/Mail)
🟡 teilweise
„Archivierte Dokumente" im Offerte-Tab deutet es an; einheitliche Ablage-Automatik spezifizieren
PDF-Merge (Rechnung + QR-Zahlteil)
❌ fehlt
Teil Belegwesen-Feinkonzept
E-Mail-Versand mit Anhang, BCC-Regeln
🟡 teilweise
Versand vorhanden; BCC (z.B. DRechnungen@) und Vorlagen spezifizieren
Endkontrolle-Prüfungen ersetzen dies vermutlich — bestätigen
Stundenkosten-Dashboard (ecologic-services)
🟡 teilweise
Pflege der kundenspezifischen Stundensätze liegt heute bereits im externen Schenker-Dashboard (Access verlinkt nur, Feld inaktiv — „moved to dashboard"); Zukunft hängt am Dashboard-Plattformentscheid und am Konditionen-Modell (Grobkonzept Kap. 3.6): Pflege dort belassen oder ins neue Konditionen-Modul holen
QR-API (TEC-IT)
❌ fehlt
Teil Belegwesen
SAP-Kompatibilität (Kunden-Artikelnummern)
✅ abgedeckt
Kern-Treiber der permanenten Artikelnummer
11 Admin / Stammdaten
Alt-Feature
Status
Bemerkung
Bearbeitungen-Stamm (Abteilung, Flags „Andere"/„nicht in Rechnung")
🟡 teilweise
Bearbeitungen werden verwendet (Honen, Verchromen …); Pflege-UI ohne Entwurf
Bearbeitung ↔ Teiletyp (M:N)
🟡 teilweise
Workshop: Prüfungen/Standard-Bearbeitungen je Komponententyp — analoges Mapping nötig
Bewusst später: CRM/Aktivitäten, Lagerlogistik, Self-Service, KI, OCR
Bei Alt-Features mit Status ❌ fehlt empfiehlt sich eine explizite Schenker-Entscheidung: übernehmen / ersetzen / streichen — dokumentiert als Ergänzung dieser Tabellen.