- ein moderner Turmbau zu Babel? Standardsoftware in aufstrebenden Märkten. Prof. Dr. Norbert Ketterer, HS-Fulda, FB Angewandte Informatik

Transkript

1 - ein moderner Turmbau zu Babel? - Standardsoftware in aufstrebenden Märkten Prof. Dr. Norbert Ketterer, HS-Fulda, FB Angewandte Informatik

2 Emerging Markets Anwender Betriebliche Standardsoftware - typische Motivation/ Herausforderungen Wir betrachten den Bereich der ERP-Software (ERP II - inkl. SCM, CRM) Oftmals unzureichende oder unflexible Altsoftware (von Partner oder gar Fremdfirma) Wachstums/ Änderungsprozesse erzeugen starken Änderungsdruck auf IT (Neugründungen, neue Businesskonzepte, etc) Eher Wunsch nach Standardsoftware statt Individuallösungen (Prozess-Know-How, Kosten) Business-User oftmals unreif (Anforderungsdefinitionen) Eigentlich sollte Standardsoftware einen Turmbau verhindern.. aber Standardsoftwarekonzept wird oft nicht wirklich verstanden Dies kann auch hier einen Turmbau zu Babel fördern/ forcieren Seite 1

3 Anwender Automotive OEMs Betrachtete Beispielanwender Anwender 1 (JV) Anwender 2 (neu) Anwender 3 (etabliert) Halbstaatliches Automotive-Joint-Venture Privater JV-Partner ist international führendes Industrieunternehmen Joint-Venture ist etabliert seit >10 Jahren Neu gegründete Automotive-Tochter eines staatlichen Industriekonglomerats Konglomerat ist bereits etabliert seit Jahrzehnten via JVs Automotive-Tochter selbst sehr neu in Industrie Automotive-Tochter eines international bekannten privaten Industriekonglomerats Etabliert seit Jahrzehnten Seite 2

4 Motivation (Haupt-)Motivation für Standardsoftware-Einführung Anwender 1 (JV) Anwender 2 (neu) Anwender 3 (etabliert) Ablösung des Legacy-Systems des Industriepartners für stärkere Unabhängigkeit der IT/ größere Flexibilität, Kostenreduktion (Aufbau eines Templates für lokale Mutter) Neugründung -> keine Standardsoftware vorhanden Entscheidungen sehr kurzfristig -> keine Möglichkeit der Eigenentwicklung & grundsätzlicher Wille zu Standardsoftware auch um Prozess-Know-How zu verbessern Teilablösung des legacybasierten Systems (Teilprozesse) ursprünglich von Mitbewerber Nutzung spezieller Funktionen designed für Automobilindustrie (Bedarfsplanung, JIT, Farben) Seite 3

5 Managementfaktoren Managementfaktoren einer Standardsoftwareeinführung Projekt- Management Change- Management Knowledge- Management Management des Projekt-Portfolios saubere Priorisierung der Vorhaben sowie Einplanung in-sync mit Softwarelieferanten Risk-Management der Projektphasen Kommunikation der Gesamgtvision/ des Nutzens Kontrolle indiv. Auswirkung auf Arbeit der Business-User Umsetzung der Änderung unter gemeinsamer Vision Saubere Kommunikation mit Softwarelieferanten Strukturierte & korrekte Dokumentation der Resultate Wiederverwendung der Resultate für Neueinführungen/ Erweiterungen/ Supportfragen Qualitäts-Management Disziplinierte Einhaltung der Qualitätsvorgaben Seite 4

6 Anforderungen Industriespezifische Supply-Chain Anforderungen an Standardsoftware (Beispiele) Prognose: Planung der Optionen Prognose nach freien Optionen gewinnt an Relevanz Fahrzeugplanung: Optimierung der Auftragsreihenfolge Komponentenhandling: Erreichen eines taktgenauen Bestandsbildes Ersatzteilmanagement: Berücksichtigung des Service-Netzes Performance: Dialog & Batch-Performance Verfügbarkeit: Geschwindigkeit der Einführung Optimierung der Aufträge gemäß Supply-Chain-Restriktionen Taktgenaue Bedarfsermittlung zur Unterstützung von JIT- Prozeduren Taktgenaues Handling der Komponenten Findung eines Optimums zwischen Bestand und Service-Level Spezielle Struktur des Ersatzteilnetzes Performance ausreichend für High-Volume Produktion komplexer Fahrzeuge Buchung innerhalb eines integrierten Systems Oftmals sehr schnelle Verfügbarkeit notwendig Einführungen vor Hintergrund starken Wachstums/ hoher Veränderungsdynamik Seite 5

7 Anforderung an Fahrzeugprognose (1) AC Lenkrad Motor freie Optionen abhängige Optionen Modell 1 + Pakete Modell 2 + Pakete Volumen-Plan -> Markt Prognose von reinen Volumen basierend auf Märkten, Modellen, etc. Options-Mix -> Markt Prognose auf Optionsbasis freie Optionen Prognose auf Farbbasis Seite 6

8 Anforderung an Fahrzeugplanung (2) Getakteter Produktionsfortschritt t Definierte Produktionsaktivität/ Takt (Linienbasiert) Andere Terminierung als bei Werkstattfertigung SC-Restriktionen Aufträge Liniennetz Regel/ Merkmal Kundenaufträge Händeraufträge Prognosen/ Dummies Nivellierung der Ressourcen Nivellierung der Inbound-Supply-Chain Berücksichtigung der Auftragstermine Menge/ Schicht Abstand Aufträge Verteilung Aufträge M von N Aufträge Übergang von Aufträgen (Rot nach..) Seite 7

9 Fahrzeugplanung Standardfunktionen und ihre Beschränkungen Genetic Algorithm Slotting Heuristic Linear Program Equal Distribution % Smoothing MRP Line Single & Multiple Single Single & Multiple Single Single Single Restrictions Supported All All (hard) Qty, K/M, Spacing, Position Qty, K/M, Spacing, Position none none Capacity Finite Finite Finite Finite Finite Infinite Order Size 1 1 (>)1 1 > 1 > 1 Disadvantage (within possibilities) Rule Fulfillment in case of nonperfect situations problematic Only fraction of GA Doesn t work with all linemodels Doesn t consider requirementsdate Causes spikes Causes spikes Seite 8

10 Anforderung an Komponentenplanung (3) ACT 1 Takt 1 ACT 2 C2 ACT 3 Takt 2 ACT 4 Takt 3 ACT 5 Takt 4 Ziel: Taktgenaue Ermittlung der Komponentenbedarfe sichtbar in Komponentenplanung, Komponentenbereitstellung Voraussetzung: Schnelle, taktgenaue Bedarfsermittlung Seite 9

11 Anforderung an Komponentenhandling (4) Teil A Einbauposition!! Teil B Taktgenaue Ermittlung des Bedarfs unterhalb der Auflösung von Signalgebern Komponente Bedarf / Aufrag/ Takt Bedarf / Aufrag/ Takt Teil A + - Teil B + + -> extreme Systembelastung # Varianten * Signalgebern Seite 10 -> Serialisierung mit reduzierter #Signalgebern.. JIS Akkurates Agieren gem. Produktionsfortschr. PUS Kontrolle des WIP Auslösung akkurater JIT-Calls Taktgenaue Bereitstellung, potentiell in Sequenz Gewollt: Integration in ERP-Prozess Teile in Sequenz

12 Anforderung an Service-Parts-Planung (5) SC-Modell Supply-Chainmodell grundsätzlich verschieden zu Fertigwarenprozess (Industrieabhängig) Qualität vs. Kosten Balance-Akt zwischen Kosten und Qualität Fertigwaren Service-Parts Bestand in SC Service-Qualität Fill-Rate (Mengenbasiert) Response-Time (Zeitbasiert) Availability (24x7) Service-Kosten Aftermarket-Inventory Inventory-Obsolescence Normal-/ Emergency Replenishment Forward& Reverse-Logistics Seite 11

13 Anforderung an die Systemperformance (6) Ausreichende Systemperformance für operativen Betrieb Spezielle Systemanforderungen resultierend aus Industriepraxis Komplexität des Produkts (speziell # Komponenten) Komplexität der Outbound-Logistik (speziell Losgrösse 1, Reihenfolgefragen) Komplexität der Bestandsführung (speziell # Reporting-Punkte wegen JIT- Anforderungen) vs. Komplexität einer einzelnen Transaktion innerhalb eines integrierten Systems (speziell einer Materialentnahme) Grenze ca 200k Ausreichende Systemperformance für geplanten Betrieb in 10 (?) Jahren. Projektion zukünftiges Wachstums in Systemdesign Projektion zukünftiger Business-Anforderungen in Design, etwa Detailliertheit des Reportings oder 3-Schicht Betrieb (-> Performance-Auswirkungen) Seite 12

14 SAP-Standard-System (IS-Auto + APO) Standard-System zur Planung von Fertigwaren (Beispiel) SD/ DP ( ) ASNs GRs APO-PP/DS APO-PP/DS

15 Standard-Funktionalitäten SPM Standard-Funktionen für Planung und Management von Ersatzteilen Seite 14

16 SAP-Standard-System (IS-Auto + APO + CRM) Standard-System für Ersatzteilmanagement Seite 15

17 Abbildung Legacy -> SAP (Kd. 1 - JV) Legacy. Design Engineering Live Order Mgmt Dummy Order Mgmt Order Constraint Mgmt Order Scheduling Material Reqd Planning Material Scheduling Order Execution Aktuelle Aufträge Forecast Restriktions- berücksichtigung Einplanung der Fahrzeug Aufträge Restriktions- berücksichtigung Einplanung der Fahrzeug-Aufträge Order Costing SD Live Order Mgmt DP Option Based Constraint PPDS RPM / Heuristics Interface DP Forecasting PPDS Mfg. Based Constraint MM Material Scheduling. Interface IS-Auto + APO PPDS Model Mix Planning MM Inventory Management FICO Costing Seite 16

18 SAP-Erweiterungen (Kd. 1 - JV) Demand Calculation Plant-Allocation OS-Planning SD/ DP Master- Data-Feed UE for Materials, Agreements, Lanes Erweiterungen denn: Fehlende/ unzureichende Funktionen im Standard Beharren auf bestehende Funktionen Demand Transfer CIR Generation SO-Upload Optimizer & MMP Optim. Tuning Spike Elimination TBS & Re-SeQ Line-Fill/ Emtpy S-Order Display Order- BOM-Date RPM for Final-BP Adj. Expl. Date Planning Run Calculation Selection Control Planning File-Entry Propagation Release- Calculation Ship-Based-Agg. PUS-Release F&S Release Schedule- Calculation Ship-Based Scheduling Multi-Source Selection ASNs GRs MES-Interface Broadcast Re-Broadcast Deallocation Allocation Seite 17

19 Job-Übersicht (Kd. 1 - JV) Komplexitätsaspekt Laufzeitaspekt Seite 18

20 Peformance-Anforderung (Kd. 1 - JV) Seite 19

21 Ersatzteil Prozess (Kd. 1 - JV) CRM ERP SPP Implementierung nur eines Aspekts der Ersatzteillogistik Implementierung über Drittsysteme plus Interfaces EWM Seite 20

22 SAP-Erweiterungen (Kd. 2 - neu) SD/ DP MES ASNs GRs MES MES Verlagerung eines Grossteils von komplexen Funktionen in das MES MES ist reine Kundenentwicklung (doch entwickelt durch Drittanbieter) übernimmt teilweise ERP-Aufgaben Keine komplette Integration mit ERP-Lösung, Verlust einer Reihe von Vorteilen der integrierten Lösung Standardsystem ist einfache Variante des KD 1, kein Stress-Test Seite 21

23 SAP-Erweiterungskonzept (Kd. 3 - etabliert) SD/ DP ASNs GRs HOST HOST Belassung eines Grossteils der komplexen Funktionen im Host Nutzung schneller Bedarfsauflösung & JIT-Funktionen in Standardsoftware Integration mit übrigen SAP-Prozessen (z.b. Einkauf, Controlling) Controlling-Konzept inkonsistent zu Logistik-Anforderungen Nicht transparent durch unzureichenden Stress-Test/ kein Fallback-Plan Initiales Vorhaben aufgegeben (Fallback) Initiales Vorhaben hätte (bei Erfolg) zu sehr komplizierter Schnittstellenlandschaft geführt Seite 22

24 Resume Kunde 1 (JV) Turmbau : extreme Komplexität & Heterogenität bei schwacher Dokumentation Faktoren, die zum Turmbau beitrugen Projekt- Management Change- Management Knowledge- Management Projektportfolio nicht in-sync mit Softwarevendor Oftmals Problem des Projekt-Portfolio zu kontrollieren Teilweise Mischung von Vendor-Beziehungsmanagement mit Projektmanagement und Inhalten (Beispiel: Ersatzteilmanagement) Komplexe Lösung langfrsitg, statt kurzfristiger Workaround Nutzen aus Business-Perspektive nicht immer klar Business-User verlangen bestehende Funktionen -> Replikation bestehender Funktionen in Neu-System Änderungen ad-hoc durchgeführt, statt Programm mit Softwarelieferant zu vereinbaren; nach Änderung kein Follow-Up Entwicklungen dokumentiert, aber oftmals keine ausreichende Gesamtprozessdokumentation Unangenehme Ablage und Retrievalprozeduren Mehrfachinstanzen von Programmen aufgrund von Dokumentationsmängeln Qualitäts-Management Duplikate in Customizing/ Programmen Inperfomante Routinen durch Misachtung von Vorgaben Dokumentation oftmals lückenhaft Komplexität führt bereits zu unerwartet hohen laufende Kosten (Wartung, Veränderungen) Seite 23

25 Resume Kunde 2 (neu) Turmbau : unklare Architektur zwischen ERP (SCM) und MES Faktoren, die zum Turmbau beitrugen Projekt- Management Change- Management Knowledge- Management Projekt sehr Zeit-& Budgetgetrieben Integrierte Arbeitsweise/ Restriktionen (zeitlich, funktional, Wille) in Standardsoftware führen zu Funktionsverlagerung in MES Business erkennt nicht den Vorteil eines integrierten Systems Business-Prozess ist oft unklar und wird ad-hoc definiert/ kopiert Nutzen wird hauptsächlich ad-hoc wahrgenommen, da Business- Prozess vage Umsetzung stark unter Massgabe etwas Lauffähiges zu besitzen Dokumentationsmängel (auch bei Dokumentationsanspruch) Qualitäts-Management Systemarchitektur sekundär verglichen mit Zeitaspekt MES wird sich zur Zeitbombe entwickeln -> mittelfristige Neuentwicklung notwendig? Seite 24

26 Resume Kunde 3 (Etabliert) Turmbau : Geplant: Komplexe Architektur zwischen Host und Standardsoftware End-Resultat: Treibende Prozessanforderungen aufgegeben > stark reduzierte Standardsoftware + Host Faktoren, die beinahe zum Turmbau beitrugen Vorteil eines integriertem Systems wurde nicht erkannt nur Fokus auf Einzelfunktionen Kein Budget/ Zeit, mit Softwarehersteller gemeinsam eine langfristige Problemlösung zu erarbeiten Kein Risk-Management für Verfügbarkeit kritischer Funktionen Projekt-Plan sah keinen initialen sauberen Stress-Test vor, obwohl Konzept ad-hoc als kritisch identifiziert Späterer Stress-Test machte Probleme deutlich und führte zu Scope- Änderung Projekt- Management Change- Management Knowledge- Management.. Qualitäts-Management Projekt kann unter ursprünglicher Zielsetzung als gescheitert angesehen werden ( neuer Turmbau wurde vermieden ) -> alter Turm bleibt bestehen Neuer Scope ist unter Qualitätsgesichtspunkten in Ordnung (Business- Anforderungen jedoch nicht erfüllt) Seite 25 Reduktion der Businessanforderungen macht Wachstumspläne fraglich

27 Gesamtresume... speziell für Techniker Die technische Sicht ist nicht Alles Technische Detaillösung mag in Ordnung sein, das Gesamtgebilde ist immer noch ein Turm zu Babel Gesamtgebilde (auch Gesamtprozess) wird oft nicht wahrgenommen auch wenn sehr detaillieters Wissen über Einzelfunktionen besteht Management-Aspekte nicht vernachlässigen Projektmanagement ist nicht nur Abhaken von Milestones Change-Management nicht vernachlässigen Seite 26

28 Vielen Dank Seite 27