Schnittstelle Produktionsinfosystem zu ERP am Beispiel Eisenbahnräderfertigung Kardemir

Standard

Die Einführung eines Produktionsinformationssystems ist keine Standalone Angelegenheit. Daten sammeln, um die Produktion zu optimieren und die Qualität der produzierten Teile sicher zu stellen und zu dokumentieren ist die eine Sache, die andere ist, ein solches System in den gesamten Geschäftsprozess von der Bestellung des Kunden bis hin zur Fertigstellung der bestellten Produkte einzubetten.

Das von SCHULER und ZOZ & PARTNER entwickelte Produktionsinformationssystem erfasst Daten für die Optimierung der Produktionsanlage (Fehler, Stillstande) und Daten, die belegen, dass die produzierten Teile die Qualitätskriterien und damit die Sicherheitsanforderungen erfüllen. Gleichzeitig geben diese Daten für den Anlagenbetreiber auch Aufschluss darüber, wie der Produktionsprozess für die einzelnen Radtypen optimiert werden kann, um Durchsatz und Qualität zu erhöhen und den Ausschuss zu minimieren.

Im Fall Kardemir kommt SAP als ERP System zum Einsatz. Zwischen beiden Systemen müssen zum Einen die Daten für den Fertigungsauftrag übertragen werden, die Ergebnisse des Auftrages müssen an SAP zurückgegeben werden und zum Anderen muss SAP eine Untermenge der Teiledaten als Ergebnis zurückerhalten. Die Schnittstelle zwischen beiden Systemen wird praktischerweise über Tabellen in der Datenbank des Produktionsinformationssystems definiert.

Kardemir_PIS_ERP

Das Produktionsinformationssystem erhält von SAP eine Liste von Fertigungsaufträgen. Diese enthalten die Nummer des Fertigungsauftrages, eine Referenz auf den Kundenauftrag und Daten zum zu produzierenden Produkt, sowie eine Vorgabe wieviele Räder zu produzieren sind. Wird der Auftrag über das Prozessleitsystem gestartet wird dieser aus der gemeinsamen Schnittstellentabelle in die interne Datenstruktur des Produktionsinformationssystemes übernommen und in der Schnittstellentabelle gelöscht. Nach jeder Schicht werden nun Daten zum aktiven Auftrag an SAP zurückgemeldet. Zum Beispiel, wieviele Teile in der Schicht produziert wurde, wieviele Ausschuss waren und wieviele nachgearbeitet wurden. Ist der Auftrag beendet, werden abschließende Daten an das ERP übermittelt. Begleitend zu den Auftragsrückmeldungen werden eine Auswahl der wichtigsten Qualitätsparameter für jedes Teil zurückgegeben.

SInd weitergehende Auswertungen für ein Teil erforderlich, werden diese direkt auf der Datenbank des Produktionsinformationssystems durchgeführt. Um die Abfragen zu erleichtern stellt das Produktionsinformationssystem zusammenfassende Views auf die Teileverfolgung zur Verfügung.

Advertisements

Anlageninformationen für Hotline zur Verfügung stellen

Standard
Produktionsinformationssysteme an Maschinen, Linien, Anlagen, für ganze Werke sind heute gang und gäbe.

 

Serviceverträge mit Maschinenherstellern werden immer häufiger von den produzierenden Betrieben abgeschlossen. Nun muss sich aber eine Hotline immer noch auf die Fehlerbeschreibung des Kunden verlassen bzw. den Fehlergrund, falls Remotezugriff vorhanden, selbst ergründen. Ein auf die Maschinenspezifika angepasstes Produktionsinformationssystem kann aber auch direkte Hinweise auf die Störungsursache liefern und das Procedere vereinfachen.Um die Informationen zu nutzen, müssen diese direkt der Hotlinedatenbank im Kundencenter zur Verfügung gestellt werden.

Dadurch wird natürlich die Störung schneller behoben.
Direkte Folge: die Kundenzufriedenheit steigt.

Produktplanung – Vom ersten Designentwurf zum Serienprodukt

Standard
Ein wichtiges Element, um einen Produktlebenszyklus nachvollziehbar zu machen, ist es beim Entwurf und der Abklärung der technischen Realisierbarkeit zu beginnen.
Für Hersteller, deren Produkte wiederum als Komponente in das Produkt ihres Kunden integriert werden, ist es von Vorteil, möglichst die, für sie wichtigsten Kenndaten der Kundenprodukte in einer Datenbasis zu hinterlegen, damit das Design Ihrer zuzuliefernden Komponenten auf diesen Daten fußen kann.

 

Der zwischen Kunde, Vertrieb, Entwicklung und Produktion vereinbarte Produktentwurf ist Startpunkt des Entwicklungs- und Lebenszyklus eines Produktes und damit gleichzeitig die Vorgabe für das zu kontrollierende Endziel. Hierbei ist es oftmals ausreichend (80/20 Regel), die generischen Komponenten des Produkts zu betrachten.

 

Basierend auf dem Entwurf können Lieferzahlen lange vor Fertigstellung der Entwicklung geplant werden. Aus den geplanten Lieferzahlen ergibt sich über die Struktur des vereinbarten Produktmodells eine Vorausschau für den Einkauf. Welche Komponenten in welcher Stückzahl werden in der Zukunft für die Fertigung benötigt.

 

Durch die Fortführung der Roadmap für die Angebotsdefinition können neue oder geänderte Vereinbarungen mit dem Kunden einfließen. Diese führen über die Entwicklungsroadmap zu neuen Serienständen, die natürlich auch volumenmäßig beplant werden können.

 

So greifen technischer und kommerzieller Prozess im Lebenszyklus des Produktes ineinander.
Puzzle_mit_Männchen

Softwarequalität – Die Beschreibung und Überprüfung der Anwendungsfälle hilft

Standard
Aus vielen Erfahrungen wissen wir nur zu gut, dass die Qualität der erstellten Software nicht nur von der Ausführung der Programmierung und dem damit verbundenen Know How abhängt, sondern im besonderen Maße von der Ermittlung des eigentlichen Bedarfs und den Wünschen des Endanwenders.

 

 Die kann dieser natürlich ohne Anleitung erst einmal nicht formulieren. Ein gemeinsames Ergründen wird erleichtert, wenn man zumindest dieselbe Sprache spricht. Was oftmals nicht der Fall ist bei IT meets User.

 

Hier scheitern letztendlich auch viele Projekte oder fangen an kostspielig zu werden. Ich denke, diese Erfahrung macht jeder Softwareersteller mindestens einmal in seinem Leben.

 

 Da wir von Zoz & Partner uns meist im technischen Umfeld bewegen und viele von uns selbst Ingenieursausbildungen haben, fällt uns die Kommunikation mit den Anwendern in diesem Bereich leichter. Wir sprechen zumindest eine ähnliche Sprache wie unsere Kunden. Aber auch hier zählt die Erfahrung und das Entwickeln einer Ahnung was das Gegenüber nun gemeint haben könnte.

 

 Das grafische Beschreiben der Anforderungen in allgemein verständlichen Abläufen hat sich bei uns zur gemeinsamen Niederschrift mit dem Kunden bewährt. Ein Tool zur Prozessmodellierung erweist sich dabei sehr hilfreich.

 

Doch, wie es sich immer wieder zeigt, sollten die mit dem Kunden ermittelten Anforderungen an relevanten Meilensteinen des Projekts überprüft und gegebenfalls korrigiert werden. Oftmals fallen dem Kunden, wenn er die bereits entwickelten Module sieht, erst noch wichtige, aber bisher vergessene Anforderungen ein, die das zu entwickelnde Programm abdecken muss, um anwendbar zu sein oder eine genügende Akzeptanz zu entwickeln.

 

Leider sind wir nicht immer so perfekt wie wir gerne sein möchten. Wir lernen täglich dazu. Einmal sich zu sicher gewesen, einmal vergessen nachzuhaken. Schon ist es passiert.
Habe mehr als einmal erlebt, dass trotz Beschreibung und schriftlich bestätigter Agreements die realisierte Funktion nicht in Betrieb ging bzw. die Änderungen zurückgebaut wurden.

 

Zu diesem Thema könnte man ein ganzes Buch schreiben.

 

Kommentare / Meinungen sind gerne willkommen.

Einblicke

Standard

Email hin oder her, es lebe die Postkarte. Oder wer druckt Mailgrüße aus dem Urlaub aus und klebt sie ans Regal?

IMG_20141107_093656

Jede Menge Zeitschriften zum Lesen in der Pause oder für Zwischendurch

IMG_20141107_111306

Wichtig: das Salatanrichtzubehör der Kolleginnen

IMG_20141107_111517