appl-v2 —
Nachfolger der Schenker Access-Appl

02 Navigation & Modulübersicht

Linke Sidebar (aus den Mockups):

Objekthierarchie

grün = neue permanente Stammdatenobjekte (in der Alt-App nicht vorhanden)

04 Modul Anlagen Neu

Eine Anlage ist die physische Maschine/Installation beim Kunden oder im eigenen Betrieb (z.B. «Hydraulische Presse 400t», Prüfstand) — neu gegenüber der Alt-App, die kein Anlagenobjekt kennt. Die Anlage ist das Bindeglied zwischen Kunde und Komponenten: sie «hängt am Kunden» und aggregiert die verbauten Komponenten sowie die Servicehistorie.

4.1 Anlagentypen

• Kundenanlage: steht beim Kunden, Grundlage für Reparatur-/Serviceaufträge
• Interne Anlage: eigene Maschinen (z.B. Prüfstand, Pressen der Werkstatt) — dieselbe Struktur; interne Maschinen sind zugleich Basis der Maschinenplanung (Kap. 8.2)

4.2 Aufbau (Tabs)

Ergänzend auf dem Stammdaten-Tab:

• Medien: Titelbild + Fotogalerie (Slots, «Als Titelbild festlegen») — der Steckbrief soll auf einen Blick zeigen, was die Anlage ist (Presse vs. Zylinder-Prüfstand …)
• Standort & Adresse: Kartenansicht, Adresse, Telefon/E-Mail des Standorts, Button «Route starten» — für Aussendienst/Serviceeinsätze
• Statuswerte im Kundenkontext (Kap. 3.2): In Betrieb Wartung fällig Störung In Installation

4.3 Verwendung im Prozess

• Bei der Auftragsaufnahme (Kap. 6.1) wird die betroffene Anlage referenziert; der Auftrag erbt damit den Kontext (Standort, Team, verbaute Komponenten)
• Ziel laut Workshop: Baumstruktur/Übersicht Kunde → Anlagen → Komponenten als Navigations- und Recherche-Einstieg (z.B. «welche Zylinder stecken in dieser Presse, wann wurden sie zuletzt revidiert»)
• Aussendienst-Szenario (Workshop): der Servicetechniker vor Ort öffnet die Anlage, sieht Komponenten inkl. Artikelnummern und kann einen Aussendienstauftrag gegen die Komponente eröffnen — speist dieselbe Historie

  Der Servicetechniker schaut vor Ort direkt nach, ob der Zylinder schon einmal bei Schenker war, und eröffnet über die Artikelnummer einen Aussendienstauftrag — der Einsatz landet in derselben Historie der Komponente.

  Workshop 02.07.2026

06 Modul Auftrag & Prozess

Der Auftrag ist das Herzstück und prozessorientiert aufgebaut — Tabs entlang des Workflows:

grün = neuer bzw. neu strukturierter Prozessschritt

Statusmodell (durchgängig im Kopfbereich)

Pro Teil eine Fortschrittsspur Material → Bearbeitung → Fertig mit Zieldatum («Fertig: …») — Unterteile klappen unter dem Hauptteil auf (Prozessübersicht-Mockup).

Beteiligte Rollen entlang des Prozesses: Auftragsannahme (Aufnahme, Kommunikation), Logistik (Warenein-/-ausgang), Werkstatt-Mitarbeiter/in (Analyse, Instandsetzung, Zeiterfassung), Teamleitung (Tagesplanung, Prioritäten schieben), Verkauf/Administration (Offerte, AB, Rechnung), Endkontrolle. Jede Handlung wird der Person zugeordnet (Kap. 9).

6.1 Aufnahme

Zweck: den Auftrag vollständig digital eröffnen — bevor die Ware eintrifft (Erfassung und Offerte sind vom physischen Wareneingang entkoppelt; heute wird oft schon offeriert, «bevor die Ware ist da ist»).

Workshop-Anforderungen

• Die Schadensinformation muss früh und digital vorliegen — heute landet sie erst beim Druck des Auftragszettels in der Werkstatt («fast zu spät im Prozess»)

  Heute steht die Schadensinformation erst auf dem gedruckten Auftragszettel — das ist fast zu spät im Prozess.

  Workshop 02.07.2026
• Checklisten pro Teiletyp bei der Aufnahme (z.B. Hydraulikventil) mit optionaler Bemerkung je Checkbox, damit der Ist-Zustand sauber erfasst ist und die Schadensanalyse ihn versteht

  Zu jedem gesetzten Häkchen (z.B. Hydraulikventil undicht) braucht es ein Bemerkungsfeld — nur so weiss die Schadensanalyse später, wie der Ist-Zustand bei der Annahme wirklich war.

  Workshop 02.07.2026
• Spracheingabe für alle Bemerkungsfelder (Diktat statt Tippen)

  Jedes Bemerkungsfeld, in dem etwas beschrieben werden muss, soll per Sprachnachricht befüllt werden können.

  Workshop 02.07.2026
• Kunden-Spezifikationen (Kap. 3.4) werden beim Anlegen automatisch übernommen
• Später denkbar: Kunden-Self-Service — der Kunde füllt die Aufnahme über die Website vor (zurückgestellt, Kap. 12)

  Idee: Der Kunde füllt die Aufnahme selbst aus. Aber Kunden melden oft nur «ist kaputt, ist undicht» — für den Start besteht kein Bedarf, später vielleicht (ein Anmeldeformular auf der Website existiert bereits).

  Workshop 02.07.2026

6.2 Komponente / Hauptteil

Zweck: das zu reparierende Teil identifizieren und den auftragsspezifischen Teilbaum aufbauen.

• Hauptteil erfassen: aus dem Komponenten-Katalog übernehmen oder neu anlegen (Modal, Kap. 5.1); mehrere Hauptteile pro Auftrag möglich («+ Hauptteil hinzufügen»)
• Dreistufige Teilehierarchie am Auftrag: Hauptteil → Unterteil → Zubehör («+ Unterteil hinzufügen», «+ Zubehör hinzufügen»). Zubehör deckt mitgelieferte Teile ab, die nicht bearbeitet, aber verwaltet und zurückgeliefert werden müssen
• Technische Angaben: Zusammenfassungs-Chips (DIM, ART, LAGE, GEBIET, BEDINGUNGEN, UMGEBUNG) aus dem Komponenten-Steckbrief; Bearbeitung über das Slide-in-Panel (Kap. 5.2)
• Kundenunterlagen am Teil, drei Ablagen: Bilder · Dokumente · E-Mails — Drag-&-Drop-Upload, eingehende Kunden-E-Mails inkl. Anhängen (z.B. Spezifikations-DOCX) direkt am Teil ablegbar
• Checklisten (Mockup «Hauptteil-2»):
  • Undichtigkeiten / Beschädigungen (Schadensorte): Stangenseitig, Kolbenseitig intern, Kolbenstange, Zylinderrohr, Schweissnaht (Flansch / Bodenseite / Ölanschlüsse), Ölleitungen, Hydraulikventile, Hydraulikschlauch, Wegmesssystem — plus Bemerkungsfeld
  • Spezial-Flags: Minimalreparatur, Prüfen vor Demontage, ohne Garantie, Dichtung wird durch Kunde mitgeliefert, spezielle Normenpflicht, Zeichnung vorhanden; Ja/Nein-Entscheide wie «Lagerbüchse ersetzen?», «Gelenklager ersetzen?» — plus Bemerkungsfeld
• Erfassungs-Stempel (durch/wann) und feldgenaue Änderungshistorie als Tabelle: Datum, Benutzer, Feld, alter Wert → neuer Wert, Bemerkung (z.B. «Anpassung gemäss Kunde»)

6.3 Wareneingang Neuer expliziter Prozessschritt

Zweck: den physischen Eingang der Ware sauber dokumentieren und dem Kunden bestätigen — heute existiert dieser Schritt nicht als eigenes Gate.

• Anlieferungszustand: Fotodokumentation, wie die Ware angeliefert/verpackt ankam (Transportschäden, fehlende Teile), plus Bemerkungsfeld — beweissicher bei späteren Diskussionen
• Fremdarbeiten vor Demontage ankreuzbar (z.B. Sandstrahlen, Reinigung) — löst die vorbereitenden externen Arbeiten aus, bevor die Analyse beginnt
• Lieferschein des Kunden hochladen (PDF/DOCX)
• Empfangsbestätigung: Status (ausstehend → bestätigt), «Empfang bestätigen» mit empfangen durch/am; anschliessend E-Mail-Versand an die Kontaktperson des Kunden (vorbelegt, editierbar)
• Statuswirkung: Warenstatus Nicht eingetroffen → Eingetroffen

Workshop: Die Durchlaufzeit (KPI) beginnt erst hier — «wenn die Ware über die Schwelle kommt», nicht bei der Auftragserfassung. Das ist fair gegenüber dem Kunden (Erfassung/Offerte können Wochen früher passieren) und macht die Kennzahl belastbar.

6.4 Schadensanalyse — «absolut zentral»

Zweck: Zustand, notwendige Arbeiten und benötigtes Material pro Unterteil erfassen — die Datengrundlage für Offerte, Instandsetzung und Rechnung. Kopfbereich mit Komponenten-Kontext (ID, Bezeichnung, Anlage); Aktionen «+ Unterteil hinzufügen», «Foto hinzufügen», «Bearbeitung hinzufügen».

Pro Unterteil (z.B. Kolbenstange, Zylinderrohr) fünf Blöcke:

1. Spezifikationen/Messwerte — Metrologie mit Nachvollziehbarkeit:
   • Jeder Messwert mit Messmittel-Auswahl (Messschieber, Bandmass, Innen-Mikrometer, Schichtdickenmessgerät …) und Kürzel-/Datum-Stempel (wer hat wann gemessen)
   • IST-Werte gegen SOLL-Masse mit Toleranzklasse (Welle z.B. Ø 80.05 gemessen vs. SOLL 80.00 h7; Bohrung 120.12 vs. 120.00 H8)
   • Teilspezifische Feldsätze: Kolbenstange (Ø, Länge Chrom, Länge total, Chromschicht µ, Ø nach Schleifen, Soll-Schichtdicke), Zylinderrohr (Innen-Ø, Rohrlänge, Wandstärke) — je Komponententyp definierbar
   • Auto-kalkulierte Felder (z.B. Fläche dm² aus den Massen — Basis für Flächenpreise)
2. Fotodokumentation — Fotos des Schadens, je Foto ein Beschreibungsfeld mit Mikrofon-/Diktatfunktion: die Schadensbeschreibung entsteht am Objekt, gesprochen statt getippt. (Perspektivisch: KI-generierte Beschreibungsvorschläge aus dem Foto — Kap. 12)

   Fotos und die gesprochene Schadensbeschreibung gehören an denselben Punkt — das schafft zugleich die Datengrundlage, damit später eine KI Beschrieb und Bild zusammenbringen kann.

   Workshop 02.07.2026
3. Bemerkung — interne Notizen zur Analyse (mit Stempel)
4. Bearbeitungen — die geplanten Arbeitsschritte (z.B. Honen, Verchromen, Aushonen «+0.1 mm Übermass», Reinigung), je mit Bemerkung: Standard-Bearbeitungen je Komponententyp vorschlagbar oder frei ergänzbar; per Drag & Drop sortierbar — aber mit Vorsicht: die Reihenfolge muss konsistent zur späteren Rechnung bleiben

   Das Umsortieren ist heikel: Die Reihenfolge der Bearbeitungen muss mit der Rechnung korrespondieren, denn alles Erfasste wird später abgerechnet.

   Workshop 02.07.2026
5. Material pro Unterteil: Anzahl, Mengeneinheit, Lieferant, Bezeichnung 1/2 (Suche im Materialstamm), Einkaufspreis × Faktor = Verkaufspreis (auto-berechnet), Status, Warenkontrolle; Material-Dokumente direkt an der Position (Bestellung, Lieferanten-Offerte). Der Materialstatus speist die Fortschrittsspur (Angefragt → Bestellt → Angekommen) — der gesamte Materialfluss ist pro Position verfolgbar

   Typischer Fall heute: Alles ist fertig — bis auf eine Dichtung. Jemand muss sich das merken und dem Lieferanten nachtelefonieren. Genau dafür braucht es den verfolgbaren Materialstatus.

   Workshop 02.07.2026

Terminierung pro Teil/Bearbeitung Grosse Neuerung

Heute gibt es nur einen Termin pro Auftrag. Neu braucht es Termine je Teil und je Bearbeitung mit:

• Abhängigkeiten zwischen Schritten (Verchromen erst nach Schleifen …) — Verzug in einem Schritt schiebt den Endtermin automatisch
• Rückwärtsterminierung vom letzten Prozess (z.B. Lackieren) auf die vorgelagerten Schritte
• Rote Markierung verzögerter Ketten in den Übersichten

6.5 Offerte

Zweck: Offertstellung, Nachverfolgung und Freigabe-Schleife mit dem Kunden — inklusive Auftragsbestätigung. Der Schritt wird nur durchlaufen, wenn die Prozessweiche in der Aufnahme (Kap. 6.1) es verlangt.

• Status & Verlauf: Stepper zu erstellen → erstellt → versendet (je mit Kürzel/Datum); Rückmeldung Freigegeben / Abgelehnt inkl. Ablehnungsgrund und Rückmeldekanal. Workshop-Ergänzungen:
  • Pausieren — Kunde ist z.B. noch in der Budgetphase; die Offerte verschwindet aus der aktiven Nachverfolgung, geht aber nicht verloren

    Offerten müssen pausierbar sein — etwa wenn der Kunde nach Rückfrage noch in der Budgetphase steckt und es länger dauert.

    Workshop 02.07.2026
  • Nachfass-Logik: Tage seit Versand sichtbar («Seit Versand: 5 Tage»), Erinnerungen konfigurierbar (bei dringenden Fällen schon nach 24 Stunden), Arbeitsliste offener Offerten, damit nichts vergessen geht

    Sichtbar sein muss, wie viele Tage seit dem Offertversand vergangen sind — dann wird nachgefasst; bei dringenden Fällen schon nach 24 Stunden.

    Workshop 02.07.2026
• Bestell- & Freigabedokumente: Kundenbestellung, Freigabe-E-Mails und -Dokumente direkt an der Offerte ablegen
• Positionsliste: wird aus Bearbeitungen + Material der Schadensanalyse generiert, gruppiert nach Unterteil: Spalten Anzahl, Teile/Leistung, Toggle «Offerte aktiv» (Position offerieren ja/nein), Preis, Einheit (h, m², Stk, km …), Total CHF; Zwischentotal je Unterteil, Gesamttotal; «+ Position hinzufügen» für freie Positionen
• Preislogik (Feinkonzept zusammen mit Konditionen, Kap. 3.6): kundenspezifische Stundensätze (CHF 135/138 …), Rabatte pro Warengruppe (z.B. 20 %/15 % auf Zylinderrohr), Aussendienst-/Kilometersätze. Realität laut Workshop «wie auf dem türkischen Basar»: deshalb Unterscheidung Grund-Offerte vs. verhandelte Offerte — Pauschalen, Rundungen (51'000 → 50'500), «Transport gratis» müssen als annotierte Abweichungen erfasst sein, damit die spätere Verrechnung sie sieht und korrekt anwendet

  Verhandelt wird «wie auf dem türkischen Basar»: Transport gratis, Pauschalen, aus 51'000 werden 50'500. Neben der Grund-Offerte braucht es die angepasste Offerte — und wer später verrechnet, muss diese Abweichungen sofort sehen.

  Workshop 02.07.2026
• Offerte-Versand: Empfänger wählen (Kontaktperson + Offerten-E-Mail aus dem Kundenstamm), Vorschau, Versand; Versandstatus mit Person und Datum
• Auftragsbestätigung (AB): eigener Block mit eigener Empfängeradresse (AB-Adresse aus Kundenstamm), Vorschau/Versand — typischerweise nach der Freigabe
• Archivierte Dokumente: erzeugte PDFs (Offerte, AB) mit Status (versendet / Entwurf) — Grundlage der Beleg-Nachvollziehbarkeit
• Offerte drucken (PDF) als Alternative zum E-Mail-Versand

6.6 Instandsetzung

Zweck: Ausführung und Rückmeldung der geplanten Arbeiten — Zeiterfassung durch die Ausführenden, Materialverfolgung inkl. Eingangskontrolle.

• Kopf pro Hauptteil: Status (In Arbeit), Startdatum und geplante Fertigstellung
• Pro Unterteil (Status-Tag zu erledigen / in Arbeit):
  • Bearbeitungen-Tabelle: Anzahl, Teile & Leistung, Bearbeitungszeit (h), Mitarbeiter/in, Status; «+ Zeile hinzufügen» für ungeplante Zusatzarbeiten (die dann als «nicht offeriert» markiert in die Verrechnung laufen, Kap. 6.9)
  • Material-Tabelle: Material, Lieferant, Lieferstatus (Bestellt / Geliefert), Warenkontrolle (OK / Fehlmenge / defekt) und geprüft durch
• Wareneingangskontrolle Material (Workshop): gelieferte Bestellungen werden mit einer schnellen Aussage geprüft — in Ordnung? falsche Menge? defekt? Die Ergebnisse speisen automatisch die Lieferantenbewertung (Defekte/Verspätungen pro Lieferant, Jahresauswertung als Verhandlungsbasis für Konditionen)

  Bei jeder Lieferung genügt ein schnelles Statement — in Ordnung, falsche Menge, defekt. Daraus entsteht automatisch die Lieferantenbewertung: Ende Jahr ist auswertbar, wie viel bei einem Lieferanten bestellt wurde und wie viele Lieferungen defekt waren.

  Workshop 02.07.2026

  Wer belegen kann, dass Liefertermine wiederholt verpasst wurden oder Material defekt ankam, kann beim Lieferanten bessere Konditionen herausholen.

  Workshop 02.07.2026
• Liefertermin-Kontrolle: offene Bestellungen mit Terminen überwachen — verspätetes Material gefährdet die Teil-Termine (Kap. 6.4)
• Team-/Abteilungssicht wie heute: jede/r Werkstatt-Mitarbeiter/in sieht den Arbeitsvorrat des eigenen Teams («was habe ich zu tun»), erfasst Zeit und Status direkt; RotGrün Produktionsübersicht über alle laufenden Arbeiten
• Tagesplanung durch Teamleitung (Workshop): die Teamleitung schiebt/priorisiert jeden Morgen die Tagestermine — das System unterstützt, ersetzt aber die menschliche Planung nicht

  Für gewisse Teile braucht es ein Enddatum — und die Teamleitung schiebt die Tagesplanung standardmässig jeden Morgen zurecht.

  Workshop 02.07.2026

6.7 Endkontrolle Neu strukturiert

Zweck: dokumentierte Qualitätsfreigabe vor der Auslieferung mit standardisierten, typabhängigen Prüfungen — heute nur als Kontroll-Status vorhanden, künftig strukturiert.

• Prüfung auswählen aus einer Prüfungs-Datenbank, abhängig vom Komponententyp:
  • einfachwirkende / doppeltwirkende / Gleichgang-Zylinder → passende Funktions-/Druckprüfung mit elektronischen Prüfmitteln oder nach Weisung
  • rein mechanische Teile → Sichtprüfung
  • kundenspezifische Protokolle (z.B. «Prüfzeugnis 3.1», SBB-Prüfprotokolle)

  Einfachwirkende, doppeltwirkende und Gleichgang-Zylinder müssen alle unterschiedlich geprüft werden — teils mit elektronischen Prüfmitteln, teils nach Weisung.

  Workshop 02.07.2026
• Die Prüfung läuft digital im Hintergrund und erzeugt ein PDF-Prüfprotokoll (mit Datum) — automatisch am Auftrag abgelegt
• Freigabe-Aussage: «Komponente/Anlage entspricht den Kundenanforderungen und ist bereit zur Auslieferung»
• Fotos des Endzustands (mit Beschriftung, Titelbild-Markierung) und Bemerkungen
• Dokumente-Bereich (Filter Alle / Fotos / Dokumente): Datenblätter, Anleitungen, Prüfprotokolle
• Arbeitsrapport erstellen — Zusammenfassung der geleisteten Arbeiten als Dokument
• Offener Punkt (Kap. 12): die Standard-Prüfkataloge je Komponententyp existieren noch nicht — «muss man erst erfinden» (fachliche Definitionsarbeit durch Schenker)

  Die Prüfprotokoll-Datenbank muss erst «erfunden» werden: Die Standardprüfungen sind im Kopf vorhanden und müssen jetzt aufs Papier gebracht werden.

  Workshop 02.07.2026

6.8 Auslieferung / Warenausgang — Spiegel des Wareneingangs

Zweck: den Versand dokumentiert und für den Kunden nachvollziehbar abschliessen — gleiche Beweislogik wie beim Wareneingang.

• Verpackung & Fotodokumentation: Fotos der verpackten Ware («Palette verpackt und gesichert», «Ladungssicherung Detailansicht») — beweissicher bei Transportschäden
• Status & Abschluss: Auslieferungsstatus als Kette bereit zur Auslieferung → Lieferschein gedruckt → Kunde informiert/telefoniert → versendet (Workshop); Aktionen Lieferschein erstellen, Speichern, Versand abschliessen; Metadaten (erfasst durch, z.B. Logistik, mit Datum/Zeit)
• Versanddetails: Versandart (z.B. Autotransport), Versandpartner (z.B. Galliker), Masse L×B×H, Gewicht, Kosten (CHF) — Gewicht und Kosten sind wichtig, weil Transportkosten-Streitigkeiten heute schwer belegbar sind

  Streitfall aus der Praxis: Ein Kunde bestreitet 600 Franken Transportkosten für einen 100-Kilo-Zylinder, weil bei ihm nur 130 Franken hinterlegt sind. Die Nachvollziehbarkeit ist ein echtes Thema.

  Workshop 02.07.2026
• Kundenavis & Transport: Kontaktinfo, Tracking-Nummer, geplante Abholung; Avis wahlweise per E-Mail oder per Telefon (mit Vermerk); Aktion «Kundenavis senden»
• Statuswirkung: Warenstatus Eingetroffen → Versandbereit → versendet
• Workshop-Idee für später: Barcode/Scan an einer digitalen Waage-Station — Auftragsnummer scannen, Gewicht wird automatisch übernommen (keine manuelle Erfassung, belastbare Transportkosten-Basis)

  Idee digitale Waage-Station: Mit dem Palettrolli auf die Waage fahren, Auftragsnummer scannen — das Gewicht wird automatisch übernommen.

  Workshop 02.07.2026

6.9 Rechnung Noch kein Entwurf

Anforderungen aus Workshop und Alt-App (für das Feinkonzept):

• Zusammenzug aus dem Auftrag; Grundlage ist der Positions-Baum mit vier Sichten auf dieselben Positionen: analysiert → offeriert → tatsächlich gemacht → tatsächlich verrechnet («vier Sichtweisen»). Die Sichten machen Abweichungen sofort sichtbar: was wurde gemacht, aber nicht offeriert? Was offeriert, aber anders verrechnet (verhandelte Pauschale, Kap. 6.5)?

  Es gibt vier Sichten auf denselben Positionsbaum: der Baum, den wir annehmen zu machen — der offerierte — der tatsächlich gemachte — und der tatsächlich verrechnete.

  Workshop 02.07.2026
• Die Auftragskontrolle der Alt-App als Vorbild übernehmen — im Workshop als navigatorisch unschlagbar bewertet; inkl. «Kreuzchen nicht offeriert»: nachträglich ergänzte Positionen (Kap. 6.6) sind für alle sofort erkennbar und gehen bei der Verrechnung nicht unter

  Die heutige Auftragskontrolle lässt sich nicht besser machen: Verglichene Programme schaffen es navigatorisch nicht, alles von einer Seite aus zu erledigen — schneller geht es nicht.

  Workshop 02.07.2026

  Nachträglich Ergänztes trägt beim Abrechnen ein kleines Kreuzchen «nicht offeriert» — simpel, auf einen Blick sichtbar, für alle.

  Workshop 02.07.2026
• Darstellung: Fremdarbeiten separat ausweisbar; Material wahlweise gesammelt in einem Block oder je Einzelteil (umschaltbar — der Einkäufer des Kunden will Material pro Teil sehen, die Verrechnung lieber gesamthaft)

  Wer beim Kunden bestellt, will das Material pro Einzelteil sehen; wer die Rechnung erstellt, lieber alles Material gesammelt in einem Block — beides muss einstellbar sein.

  Workshop 02.07.2026
• Schnittfehler-Masse sichtbar/korrigierbar (z.B. Krummlänge einer Kolbenstange erzwingt mehr Rohmaterial), damit sie verrechnet werden — sonst Umsatzverlust

  Schnittfehler passieren — z.B. bei einer zwei Meter langen Kolbenstange mit Krummlänge. Die korrigierten Masse müssen sichtbar sein und verrechnet werden, sonst fehlt am Ende Geld.

  Workshop 02.07.2026
• Aus der Alt-App zu übernehmen (siehe Gap-Analyse Kap. 6): Rechnungsnummern-Vergabe bei Druck, Swiss-QR-Rechnung/Zahlteil, Gutschrift, EUR/CHF, Detailgrad-Steuerung (wie fein erscheinen Bearbeitungen/Material auf dem Beleg), Konditionen/Skonto/WIR, MWST
• Schnittstelle/Kopplung an die Rechnungsstellung/Buchhaltung: von Schenker zu klären (Workshop); ebenso das Mengengerüst-Limit des heutigen Rechnungsprogramms

  Die Systeme der Rechnungsstellung verkraften nur eine gewisse Datenmenge — Unmengen an Positionen lassen sich nicht durch das heutige Rechnungsprogramm schleusen; die Übergabe muss dazu passen.

  Workshop 02.07.2026

08 Service & Einsatzplanung

Kalenderbasierte Ressourcenplanung auf Basis der erfassten Betriebsmittel (Kap. 7) und internen Anlagen (Kap. 4.1). Im Workshop als «relativ überschaubar» eingestuft — der Entwicklungspartner hat eine analoge Mitarbeiter-Einsatzplanung (Kalender, Teams, Buchung auf Ereignisse) bereits für einen anderen Einsatz gebaut.

8.1 Fahrzeugplanung

Ersetzt die heutige Trello-Lösung für Fahrzeugreservationen (Montage-Einsätze).

• Wochenkalender (KW-Navigation): Zeilen = Fahrzeuge des Fuhrparks (aus Kap. 7.2, mit Kennzeichen), Spalten = Mo–Fr; leere Zeilen zeigen «Keine Buchungen»
• Buchung («+ Fahrzeug buchen»): Fahrzeug, Person oder Team, Zeitfenster (von–bis), Auftrag-Referenz (z.B. «Auftrag #1023») und Kategorie
• Kategorien (farbcodiert): Montage/Einsatz · Service/Wartung · Meister/Leitung
• Nutzen: auf einen Blick sehen, welches Fahrzeug wann frei ist; Buchungen sind mit Aufträgen verknüpft und damit nachvollziehbar (wer war mit welchem Bus auf welchem Einsatz)

8.2 Maschinenplanung

Kapazitätsplanung der eigenen Maschinen (CNC-Fräsen, Drehmaschinen, Pressen …) als Gantt-Ansicht über den Monat.

• KPI-Leiste: Maschinen gesamt, Auslastung heute (%), Aufträge in Bearbeitung, geplante Aufträge, geplante Wartungen
• Gantt: Zeilen = Maschinen, Spalten = Kalendertage; Balken = eingeplante Aufträge mit Kunde (z.B. «Auftrag A-4512 | Müller Industrie AG»), daneben Wartung, Reserviert, Stillstand/Problem
• Balken-Detail (Popover): Kommission/Kunde, Maschine, Start, Ende, Status, zuständiges Team
• Filter: Maschine, Team, Kunde, Status, Monat; Aktionen «+ Auftrag einplanen» / «+ Wartung planen»
• Status-Legende: Geplanter Auftrag In Bearbeitung Reserviert Stillstand/Problem Wartung
• Zusammenspiel: Die Maschinenbelegung hängt mit der Terminierung pro Bearbeitung (Kap. 6.4) zusammen — ein verzögertes Teil blockiert einen Maschinen-Slot; das Feinkonzept Terminierung muss beide Sichten konsistent halten. Eigene Wartungen der Maschinen speisen sich aus den Prüf-/Servicefristen (Kap. 7.1)

10 Fehlende Bausteine (Konzept-Lücken der Entwürfe)

Die Mockups zeigen vor allem Detailansichten und den Auftragsprozess. Für eine lauffähige Software fehlen Bausteine, die in keinem Entwurf auftauchen, aber vorausgesetzt werden — Checkliste für UI-Feinkonzept und Arbeitspakete. Der Abgleich mit Alt-App-Features steht in der Gap-Analyse; hier geht es um die konzeptionelle Vollständigkeit der neuen App selbst.

10.1 Listen & Einstiege

Für Fahrzeug-/Maschinenplanung existieren die Kalender-Einstiege bereits (Kap. 8).

10.2 Anlege-, Bearbeitungs- und Löschflüsse

• Neuanlage-Dialoge für Kunde, Anlage, Komponente (ausserhalb des Auftrags), Kontaktperson, Betriebsmittel — entworfen ist nur das Modal «Hauptteil erfassen» (Kap. 5.1)
• Dublettenprüfung bei Kunde/Kontaktperson (Alt-App prüft Kontakt-Duplikate)
• Deaktivieren statt Löschen: Kunde inaktiv, Komponente verschrottet, Betriebsmittel ausgemustert — Objekte mit Historie dürfen nicht hart gelöscht werden (Kap. 9)
• Auftrag stornieren/abbrechen mit Begründung und definiertem Zielstatus

10.3 Prozessvarianten & Sonderfälle

• Auftragstypen: entworfen ist «Instandsetzung». Weitere Typen definieren — Service/Wartung vor Ort, Aussendienstauftrag (Kap. 4.3), Expertise/Analyse ohne Reparatur, Garantiefall/Nacharbeit — und je Typ die Prozessvariante (welche Tabs/Schritte gelten; ein Aussendienstauftrag hat z.B. keinen Warenein-/-ausgang)
• Prozessweiche «Direkt ausführen» (Kap. 6.1): Verhalten ohne Offerte-Schritt definieren (AB trotzdem? Freigabegrenze?)
• Abbruchpfade: Offerte abgelehnt → Rückversand unrepariert (Analyse-Aufwand verrechnen?) oder Entsorgung (Alt-App-Status «Zylinder entsorgen») — beides im neuen Prozess nicht abgebildet
• Mehrere Hauptteile pro Auftrag (Kap. 6.2): Status-Aggregation, Teillieferungen/Teilrechnungen ja/nein
• Statusübergänge & Validierungen: je Statusachse (Kap. 6) die erlaubten Übergänge, Vorbedingungen (z.B. «Versand abschliessen» erst nach Endkontroll-Freigabe) und Berechtigungen je Übergang — die Zustandsmaschine hinter den Mockup-Badges

10.4 Stammdaten- & Katalogpflege

Der Sidebar-Punkt «Stammdaten & Systemeinstellungen» hat keinen Entwurf — dahinter stecken die Kataloge, die das ganze Konzept steuern:

10.5 Benutzer, Rollen & Rechte

• Login & Benutzerverwaltung — Voraussetzung für «Erfassung pro Mitarbeiter/in» (Kap. 9), Zeiterfassung und Änderungshistorie; kein Entwurf
• Rollenmodell: wer darf Offerten freigeben, Preise/Einkaufspreise sehen (Werkstatt vs. Verkauf), Status übersteuern, Stammdaten pflegen — die Alt-App kennt nur drei stationsgebundene Rollen
• Gerätekontext Werkstatt: geteilte Terminals/Tablets brauchen schnellen Benutzerwechsel (PIN/Badge) statt des Auto-Logout-Modells der Alt-App

10.6 Aufgaben & Benachrichtigungen

Mehrere Konzeptteile versprechen Erinnerungen, ohne dass ein Mechanismus definiert ist: Offerte-Nachfass (Kap. 6.5), Betriebsmittel-Prüftermine/Terminsetzer (Kap. 7.1), Terminverzug (Kap. 6.4), Material-Lieferverzug (Kap. 6.6). Nötig ist ein einheitliches Aufgaben-/Benachrichtigungskonzept: Zustellung (In-App-Inbox pro Person/Team, optional E-Mail), Fälligkeiten, Quittieren — sonst bleiben die Erinnerungen wirkungslos.

10.7 Dashboard & Auswertungen

• Dashboard (erster Sidebar-Punkt, kein Entwurf): Was sieht welche Rolle beim Einstieg (Startseite) — und wie verhält es sich zum bestehenden Führungsinstrument (Plattform-Entscheid, Kap. 12)? Team-Dashboard ist als Neuanforderung genannt

  Das heutige Produktions-Dashboard ist wirklich gut und dient als Führungsinstrument; zusätzlich braucht es künftig ein Team-Dashboard — wie beides zusammenspielt, ist intern zu klären.

  Workshop 02.07.2026
• Auswertungen & Qualität (Sidebar-Punkt, kein Entwurf): Startumfang definieren — mindestens Stunden/Umsätze und die Lieferantenbewertungs-Auswertung (Kap. 6.6); das Konzept Qualitätsmeldungen fehlt ganz; Alt-Reports siehe Gap-Analyse Kap. 8

10.8 Belegerzeugung & E-Mail-Versand

• PDF-Templates: Offerte, AB, Lieferschein, Empfangsbestätigung, Prüfprotokoll, Arbeitsrapport, Kundenavis (+ Rechnung je nach Szenario, Gap-Analyse Kap. 6) — Layout/CI und Sprachen klären (Kunden in CH und DE)
• E-Mail-Versand: Absenderkonten, Vorlagen je Belegart, BCC-/Archivregeln, Versandprotokoll (wer hat wann was an wen geschickt)
• Automatische Ablage aller erzeugten Belege am Auftrag — das «Archivierte Dokumente»-Muster aus Kap. 6.5 verallgemeinern

10.9 Globale Suche

Alle Mockups zeigen ein Header-Suchfeld, der Funktionsumfang ist nirgends definiert. Mindestens: Auftragsnummer, interne + Kunden-Artikelnummer, Kunde, Kommission; Referenz für mehr: die globale Suche der Alt-App (Search_Global: Freitext, Ort, Teileart, Durchmesser).

10.10 Datenmigration

• Kunden, Kontaktpersonen, Konditionen aus der Alt-DB
• Laufende Aufträge: Stichtagsregel oder befristeter Parallelbetrieb definieren
• Komponentenstamm: existiert im Altsystem nicht (Teile sind auftragsgebunden) — Strategie wählen: initial leer und Komponenten bei jedem neuen Auftrag anlegen vs. Vorab-Ableitung aus Alt-Teilen/Gravuren
• DMS-Dokumentbestand (heutige Pfad-/Namenskonvention) in die neue Ablage überführen
• Offene Posten/Rechnungen: abhängig vom Rechnungs-Szenario A/B (Gap-Analyse Kap. 6)

10.11 Technik & nicht-funktionale Anforderungen

• Plattform: Web-App, Mehrbenutzer; Browser-/Geräteanforderungen
• Werkstatt-Endgeräte: Tablet-Tauglichkeit der Prozess-Tabs, Kamera-Integration (Fotos direkt aufnehmen statt Datei-Upload), Mikrofon/Spracherkennung — Dienstauswahl inkl. Umgang mit Schweizerdeutsch
• Speicher-/Mengengerüst: Fotos und Dokumente in grosser Zahl pro Auftrag (Kap. 9) — Ablage, Grössenlimits, Aufbewahrung
• Offline-Verhalten für Aussendienst-Szenarien (Kap. 4.3) klären
• Betrieb: Hosting, Verfügbarkeit, Backup/Restore, Datenschutz (Kundendaten)

12 Scope & Priorisierung

Kern-Scope (Gegenstand der Entwürfe)

Noch zu konzipieren (im Scope, aber ohne Entwurf)

Bewusst später (deferred)

Offene Entscheide

• Prüfmittel: bestehendes Tablet-Tool integrieren oder parallel weiterbetreiben?
• Dashboard/Führungsinstrument: auf neuer Plattform neu bauen oder Bestehendes weiternutzen? (intern zu klären, parallel aufbauen)
• Kopplung Rechnungsstellung/Umsysteme: deckt appl-v2 das Belegwesen selbst ab, oder werden die Rechnungsdaten nur an das bestehende Rechnungsprogramm übergeben (Workshop-Tendenz)? Entscheid bei Schenker; bestimmt, ob Mahnwesen/Zahlungen/Kundenkonto Umsetzungs- oder Schnittstellenthema sind — siehe Gap-Analyse Kap. 6

  Tendenz aus dem Workshop: Die Rechnungsdaten werden voraussichtlich nur ans bestehende Rechnungsprogramm übergeben — dann sind die Schnittstellen absehbar; Schenker klärt das intern.

  Workshop 02.07.2026