Digitaler Backbone als Basis für I4.0 am Beispiel Problem- und Fehlermanagement

Transkript

1 Digitaler Backbone als Basis für I4.0 am Beispiel Problem- und Fehlermanagement

2 Vorstellung Schlatter Industries AG Die Schlatter Gruppe ist der weltweit führende Anlagenbauer für Widerstandsschweiss- und Websysteme für branchenspezifische Anwendungen. Fokus auf Kundennutzen Weltweite Präsenz Hohe Innovationskraft Leistungsorientierte Unternehmenskultur Ein zuverlässiger Partner Kerntechnologie Schweiss- und Webtechnik

3 Oliver Martitsch-Kreiner PLM / CAD System-Manager oliver.martitsch-kreiner@schlattergroup.com Schlatter Industries AG Brandstrasse Schlieren 044 /

4 Einleitung «Was hat die Einführung eines integrierten Problem- und Fehlermanagement Systems mit den Wirtschaftlichen Aspekten unter I4.0 zu tun?» Um am Werkplatz Schweiz bestehen zu können und auch für I4.0 Projekte bereit zu sein, ist es absolut notwendig, die eigenen Prozesse basierend auf den relevanten Systemen im Griff zu haben und zu optimieren. Mit meinem Referat möchte ich einen für Schlatter Industries zentralen Prozess herausgreifen und aufzeigen, wie es uns gelungen ist, das Thema Problem- und Fehlermanagement von einem aufwändigen, manuellen Prozess in einer End-to-End Betrachtung über alle Disziplinen und Abteilungen deutlich zu optimieren.

5 Ausgangslage Schlatter Industries nutzte zur Vorfall- und Fehlererfassung ein eigen programmiertes Access-Tool Der Vorteil dieses Tools: - auf Schlatter-Bedürfnisse ausgerichtet - Integriert in Citrix Umgebung - intuitiv - billig, keine weiteren Kosten Der Nachteil dieses Tools: - Programmierer (Vater des Tools) nicht mehr bei Schlatter - Insellösung - Zugriff nur für Mitarbeiter mit Access-Lizenz - keine Anbindung in die T-Abteilungen - Fehleranfällig mit langen Durchlaufzeiten und Mehrfacheingaben - keine Workflow-Unterstützung für gesicherte Prozessabläufe - Kein Bezug zwischen Produktdaten (TC Items) und den Vorfällen/ Fehlern in der externen DB - Schlatter konnte damit die Produktqualität nicht wie gewünscht verbessern

6 Ein erster Integrations-Versuch 2008 gab es den erster Anlauf für eine Teamcenter ChangeManagement Einführung. Grober Umfang: - Ablösen des Accesstool und Integration ins Teamcenter - Bestehende Fehlerdatenbank von Access soll migriert werden - Vorfälle und Fehler sollen ins Tc Change Management integriert werden

7 ...dieser scheiterte jedoch Wir mussten bald einsehen, dass dieser erste Versuch für eine integrierte Lösung so nicht umsetzbar war und stoppten das Vorhaben. Einige Gründe dafür: - Übernahme der Access-DB ins Teamcenter mit allen Funktionen - kein Fokus auf die wesentlichen Prozesse - sehr viel Customizing wäre nötig gewesen, wir haben uns nicht auf Standardlösungen fokussiert. - Hohe Projektkosten zeichneten sich ab - zu viele involvierte Stellen

8 wie Schlatter zu CAPA kam 2013 dann ein neuer Anlauf, nachdem sich unsere Organisation doch sehr verändert hatte und keine Person mehr bei Schlatter das Access-Tool anpassen konnte. Die Gegebenheiten waren ideal: - aktuelle Prozesse für Fehler- und Änderungswesen sind viel zu umständlich - manuelle Schnittstellen und Tätigkeiten - bei komplizierteren Änderungsfällen konnten die Zusammenhänge im isolierten Tool nur unzureichend abgebildet werden, Einfluss-Analysen gestalten sich aufwändig - Q-Bereich war bereit, Access-Tool zu ersetzten (Leidensdruck) - Es soll auf die bestehende Systeme Teamcenter und SAP aufgebaut werden

9 wie Schlatter zu CAPA kam Folgendes konnte festgehalten werden und führte zum Projektantrag bei der GL: Die heutigen Prozesse für das Fehler- und Änderungswesen sind viel zu umständlich, kostenintensiv und beruhen teilweise auf Software (-bausteinen), welche nicht mehr unterstützt sind resp. deren fehlerfreier Fortbestand nicht gewährleistet werden kann Die Vorzüge der bestehenden Systeme Teamcenter und SAP werden für den Fehler- und Änderungsprozess praktisch nicht genutzt Die Folge sind viele manuelle Schnittstellen und Tätigkeiten im Änderungs- Freigabe und Fehlermeldeprozess sowie unnötig redundante Eingaben in der Datenerfassung und pflege. Das zukünftige Änderungswesen sollte möglichst da ansetzen, wo die Daten entstehen, d.h. in Teamcenter

10 Übersicht Teamcenter CM / CAPA Projekt Auf Basis der bestehenden Systeme Teamcenter und SAP wurde ein geeignetes Tool für die durchgängige Vorfall-, Fehler- und Änderungsbearbeitung gesucht. Folgendes soll berücksichtig werden: - Fehler sollen nachhaltig behoben werden - Kürzere Durchlaufzeit da Mehrfacheingaben und überflüssige manuelle Tätigkeiten entfallen - Rückverfolgbarkeit jeder Mutation gewährleisten - einfache (Web-) Oberfläche zur Vorfall- und Fehlererfassung - Zugängigkeit für alle beteiligten Stellen sicherstellen - Out of the box, resp. so wenig wie möglich Customizing - weg vom Papier - Der Anwender muss sich sofort zurecht finden Einfache und bekannte Bedienelemente und klare Prozessschritte

11 Übersicht Teamcenter CM / CAPA Projekt Ausgangslage Projekt «Babel» ist eine End-to-End Prozessverschlankung des Änderungs-, Freigabe- und Fehlermeldeprozesses basierend auf Teamcenter

12 Vorgehen bei der Umsetzung Unter dem Motto «zu viele Köche verderben den Brei» besteht unser Team für die Umsetzung aus 3 Personen - OT Mitarbeiter & Q-Stelle Schlatter - PLM System-Manager Schlatter - Solution-Architect Siemens PLM Projektteam rapportiert direkt dem Auftraggeber: GL Schlatter Industries AG Sehr effiziente Zusammenarbeit möglich Lösungsaufbau auf Basis des Grobkonzepts und initialen Demosystems Keine «Sonderwünsche» von Links und Rechts Blick aufs Wesentliche bleibt Bedürfnis des Anwenders nach Einfachheit nicht vernachlässigen

13 Vorgehen bei der Umsetzung

14 Vorgehen bei der Umsetzung

15 Hauptmerkmale der Systemlösung Jeder Mitarbeiter kann Probleme und Fehler erfassen Probleme und Fehler werden zentral kategorisiert - Operation-Fehler - Lieferanten-Fehler - Technik-Fehler - kein Fehler Massnahmen werden direkt aus Teamcenter ausgelöst Komplette Nachverfolgbarkeit und vollständige Dokumentation

16 Wie werden Probleme erfasst? Unterschiedliche Quellen ein Portal für alle Anwender Montage Ersatzteilwesen Wareneingang / Lager Customer Service / Hotline Projektleiter

17 Nutzen für Schlatter Steigerung Produktqualität bei sinkenden Kosten Durch gezielte Beseitigung von Fehlerquellen und Verringerung von Garantie- und Ausschusskosten Einheitlicher und optimierter Qualitäts-Prozess Reduktion der Komplexität, Beseitigung von Mehrspurigkeiten und mehrfacher Datenhaltung, Verbindung in das Änderungsmanagement. Digitalisierung des Prozesses erlaubt Automation Durch den Wegfall von Papier und dem manuellen Kopieren/Scannen/Austeilen sowie Einsammeln, hin zum Einsatz von Workflows wird die Durchlaufzeit beschleunigt. Darüber hinaus sind neue Dokumentationswege (z.b. Fotos) möglich. Sichtbarkeit und Transparenz Transparenzen «erzwingt» das Lösen von Problemen und das Definieren von Kompetenzen bei Unklarheit. Die Lösungsfindung wird zum späteren Nutzen dokumentiert. Weg von «Custom Systemen» hin zu Standard-Software mit einfacher Wartbarkeit sowie Upgrade-Fähigkeit

18 Nutzen für Schlatter Einfache Oberfläche und integrierte Änderungsbearbeitung Ohne Medienbrüche und Doppelspurigkeiten ist das System intuitiv benutzbar, ohne viel Training und Support Nachverfolgbarkeit Gemeinsame Ablage von Produkt- und Änderungs-Informationen im PLM-System ermöglichen ein direktes Feedback zu einem Bauteil durch das Analysieren der angefallenen Änderungen Unterstützung des Qualitäts-Mgmts nach ISO 9001

19 Fazit nach Projektumsetzung Rückblick nach erfolgreicher Projektumsetzung Durch unsere schlanke Projektumsetzung konnte dieses neue Problem- und Fehlermanagement Werkzeug innerhalb von ca. 7 Monaten erfolgreich umgesetzt und somit produktiv eingesetzt werden Die Einfachheit wurde von den Anwendern gelobt, was sich auf die Akzeptanz und die rege Anwendung des Tools auswirkt Allein dadurch, dass sich der bürokratische Aufwand pro Vorfall um 10 bis 15 Minuten bzw. um ein Viertel reduziert hat und die Meldung ohne Verzögerung und mit vollständigen Informationen an die nächste Stelle weitergeleitet wird, reduziert sich die Durchlaufzeit erheblich!

20 Fazit nach Projektumsetzung Die Digitalisierung und somit die Einführung von I4.0 Projekten wird bei Schlatter fortgesetzt und kann auf einer soliden Basis, unserem digitalen Backbone aufsetzen. Wichtig für uns ist es, dass wir zu jedem Zeitpunkt auf Daten und Dokumente zurückgreifen können ohne lange suchen zu müssen oder erst eine entsprechende Berechtigung zu erhalten. Es lohnt sich allemal Gedanken zu machen, ob es nicht noch weitere Abläufe und Prozesse gibt, dich sich ähnlich automatisieren und vereinfachen lassen.

21 Ausblick Weiterhin werden wir Anstrengungen unternehmen, unsere Daten in zukünftigen Projekten optimal einzusetzen: Vom manuellen Plot-Management und personanabhängiger Datenaufbereitung hin zur automatisierten Dokumentenverteilung an Lieferanten im Auftragsfall bei Bestellauslösung. Wir beobachten die Entwicklungen und überprüfen, wo I4.0 Technologien in unsere Anlagen einfliessen können und so einen erheblichen Kundennutzen generieren, welcher auch einen Wettbewerbsvorteil für Schlatter Industries mit bring.

22 Vielen Dank für Ihre Aufmerksamkeit