15 Jahre OP² produktiv – Eine Erfolgsgeschichte!

Standard

Seit 15 Jahren ist das System OP² nun bei der Continental AG in der Entwicklung von elektronischen Bremssystemen produktiv.

OP² (Optimierte Produktplanung) ist eine Anwendung im Bereich des PLM/PDM Umfelds in der Entwicklung von elektronischen Bremssystemen bei Continental. OP² ist weltweit im Einsatz. Datenbank und Applikation werden in Frankfurt gehostet.

2 grundlegend unterschiedliche Software Generationen sind in dieser Zeit aktiv bzw. aktiv gewesen. Die erste Generation basierend auf Oracle Datenbank  Backbone mit MS Access  und Visual Basic Oberflächen, die 2. Generation mit komplett in C# entwickelter Anwenderlogik und stark verbesserten Datenbankstrukturen auch wieder in Oracle.

Beide OP² Generationen hatten das Projektverständnis und relativ starre Produktstrukturen als Basis . Dies lässt sich in den heutigen äußerst agilen Zeiten nicht mehr durchhalten. Die Variantenvielfalt der Produkte steigt und die Komplexität wird höher. Außerdem ändert sich der Produktbegriff. Es wird nicht mehr ein Kasten zum Einbauen geliefert, nein, es werden richtigerweise Funktionen, die durch Hard- und Software unterstützt werden, zu einem Gesamtsystem des Kunden zugeliefert.

In der geplanten 3. Generation von OP² werden die fest verdrahteten Produkt- und Projektstrukturen aufgelöst werden. Nur dann wird es möglich, die heutige Entwicklungswelt abzubilden. Die Anwenderoberflächen müssen dem Rechnung tragen. Sie müssen den Anwender intuitiv durch die sehr viel komplexere Prozess- und Datenwelt führen. Um dies zu leisten, müssen sich auch die Methoden in der Entwicklung von OP² selbst ändern. Techniken müssen auf den Prüfstand gestellt und evtl. durch geeignetere  ersetzt werden. Jeder einzelne Entwickler ist gefordert, seine Ideen einzubringen, festgetretene Pfade zu verlassen.

Aber erstmal feiern wir ein bisschen den Erfolg von OP².

Advertisements

Nur die übliche Begriffsverwirrung

Standard

Es ist erstaunlich wie sehr in großen Firmen gerade in Entwicklungsabteilungen ein Begriffswirrwarr herrscht. Was in der Produktion in kurzer Zeit zu einem Stillstand führen würde, scheint Entwicklungsabteilungen zu hemmen, aber nicht zum Erliegen zu bringen. Hier wird frei nach dem Motto Glaube und Hoffnung gearbeitet. Hoffnung auf der einen Seite bei den Prozessleuten, dass es einmal besser wird, Glaube in den lokalen Begriffsbrutstätten, dass die eigene Meinung die Richtige ist.

Das fängt bei ganz einfachen Sachen an. Zum Beispiel bei grundlegenden Projektverwaltungsdaten. Da gibt es den eigentlichen Kunden, den Konzern zu dem der Kunde gehört und die Marken, unter denen der Kunde bzw. der Konzern seine Produkte produziert. Man denkt, ganz einfach. Marke, das ist ein Aufkleber.Mehr nicht. Kann man verkaufen, kann morgen zu einem anderen Kunden gehören. Der Kunde, das ist die Firma für die ich etwas tue. Die Firma, mein Kunde, selbst gehört zu einem Konzern. Aber, schon fängt die Verwirrung an: Marke wird zum Kunden oder gar zum Konzern und umgekehrt(seit wann ist PSA, Peugeot Société Anonyme, z.B. eine Marke?) . Über den Namen des Kunden oder gar des übergeordneten Konzerns gibt es verschiedene Meinungen. Diese „Meinungen“ spiegeln sich in den Softwaretools der einzelnen Abteilungen, die sie sich haben entwickeln lassen wieder. Denn jedes dieser Tools hat natürlich eine eigene Datenbasis. Man kommuniziert und versteht sich nicht. Man arbeitet in verschiedenen Tools und überall heißt alles anders. Man baut Schnittstellen und übersetzt die Daten beim Transferieren. Toll!

Hallo! Hat einmal jemand einfach schon mal in dieses neuartige, vielen unbekannte Internet geschaut? Die Seite des Kunden aufgeschlagen und dort nachgesehen wie nennt der sich selbst, für welche Marke(n) produziert er und wie heißen die und wie heißt der Konzern, zu dem der Kunde gehört. Hmm?

Aber jetzt kommt’s. Spätestens mit der Einführung neuer großer Standardtools für Requirementsmanagment, Quellcode- und CAD Verwaltung, PLM und PDM Tools fängt es dann an zu klemmen.

Die Datenbasis muss/sollte vereinheitlicht werden. D.h., einer legt fest wie Dinge heißen und wie sie strukturiert sind. Für einen Bereich, für den er die Kompetenz hat. Für einen anderen Bereich macht das jemand anderes. Daten entstehen an der Stelle an der die Kompetenz dafür liegt. Sie gelten dann für alle. Eigentlich einfach. Die lokalen Tools bleiben, werden für die entsprechenden Daten halt auf die zentrale Datenbasis angepasst. Sicher, ist Aufwand, Arbeit, aber erspart später viel mehr Aufwand und Arbeit.

Was passiert dann aber: Variante 1) diese Vereinheitlichung wird einfach von oben durchgesetzt. Frust und Missmut allenthalben. Nutzungsverweigerung. Kann nicht mehr arbeiten.Finde meine Sachen nicht mehr. Variante 2) Konsens suchen, Besprechungen, Überzeugungsarbeit. Mappinglisten. Migrationsszenarien. Dauer (gefühlt) gegen unendlich . Ergebnis keines, außer Variante 1 wird dann doch in Kraft gesetzt.

Vielleicht hätte man sich das Ganze aber mit etwas Weitsicht ganz am Anfang der Entwicklung der Dinge ersparen können. Leute dazu erziehen, dass Sie andere, die die Kompetenz in einem Bereich haben, fragen, bevor sie etwas für sich selbst definieren. Keine Dateninseln entstehen lassen. Es ist schließlich die Aufgabe der (Fach) IT Informationen zu bündeln und richtig strukturiert abzulegen und keinen Wildwuchs zu erzeugen bzw. zuzulassen. Im Nachhinein bedarf es jeder Menge Anstrengungen, um die vielen gordischen Knoten zu lösen.

25 Jahre ZOZ & PARTNER

Standard

25 Jahre spiegeln die geballte Erfahrung in der Softwareentwicklung für Produktion und Technik wieder.

Von Prozessleitsystemen und Produktionsdatenerfassungen bis hin zu MES Systemen in der Produktion mit Kopplung zu überlagerten ERP Systemen haben wir schon vieles ganz individuell für unsere Kunden entwickelt.

Wir sind stolz darauf, dass wir in dieser Zeit unsere Erfahrungen in so vielen verschiedenen Bereichen und Branchen, seien es Verfahrenstechnik, Stückgutfertigung, Biotechnologie oder die Unterstützung von Produktentwicklungsabteilungen, sammeln durften.

Das hat uns reich an Erfahrungen gemacht.

Und so freuen wir uns auf die kommenden interessanten Herausforderungen.

Produktionskapaplanung auf Basis Entwicklungsplanung

Standard

 

Ausgehend von Forecastplanungen, schon während der Entwicklung von Produkten und Varianten, die Volumendaten in die Kapazitätsplanung bestehender und zukünftiger Produktionslinien bzw. Werke eingehen zu lassen, ist eine interessante Herausforderung.
Arbeitszeiten, OEE Werte und darüber berechnete verfügbare Linienkapazitäten müssen in verschiedenen Szenarien eingeplant werden. Dabei sind die funktionalen Möglichkeiten der Produktionslinien und die Nähe zum Abnahmemarkt zu berücksichtigen. Logistische Faktoren spielen durchaus eine Rolle. Berechnungen und Priorisierungen von Produkt-Linienbelegungen sind zu definieren. All dieses Wissen muss gesammelt und in einer Datenbank als Basis für die Planungsszenarien hinterlegt werden.

Kapaplanung

Szenarien müssen verglichen und bewertet werden können. Basierend auf einem ausgewählten Szenario muss die Weiterentwicklung eines Planungsansatzes erfolgen.
Konsolidierte Planungen werden Jahr für Jahr weitergeführt.

 

 

Ganzheitliche Produktionsinformations- und Leitsysteme mit Bezug zur Produktentwicklung (Teil 2)

Standard

Wie in Teil beschrieben, liefert die Produktentwicklung schon weit vor der Aufnahme der Serienproduktion Daten, die beim Neuanlauf des Produktes, ist es erst einmal fertig entwickelt, helfen.

Die Produktionslinie kann geplant, die erforderlichen Herstellungsschritte können beschrieben werden. Schon weit vor dem Tag des Neuanlaufs stehen die erforderlichen Daten zur Verfügung.

Die Erfassung der für dieses Produkt spezifischen Daten kann vorbereitet werden. So können am Tag X der ersten Testläufe der neuen Produktionslinie bzw. des neuen Produktionsverfahrens die benötigten Kennzahlen, qualitäts- und sicherheitsrelevante Daten sofort erfasst und ausgewertet werden.

Als Ergebnis kann der Neuanlauf eines Produktes schneller durchgeführt werden. Das Shop Floor Management kann greifen und die Wertschöpfung von Anfang an steigern.

ganzheitlich_2

Ganzheitliche Produktionsinformations- und Leitsysteme mit Bezug zur Produktentwicklung (Teil 1)

Standard

Die Entwicklung nicht gescheit voraus planen können, das ist eine Schwäche, die oftmals, auch bei großen Unternehmen, vorkommt. In SAP steht meistens nur der Ist Zustand. Die Softwareverwaltung kennt auch nur das Ist. Workflows bilden meist nur die nahe Zukunft ab.

Für die spätere Produktion des Produktes ist es jedoch wichtig, rechtzeitig planen zu können. Das betrifft die Kapazitätsplanung (Werk), den Einkauf von Bauteilen (Logistik) und, und , und. Hier sollte ein Instrument geschaffen werden, dass am Besten schon in der Angebotsphase eine technische Beschreibung des Produktes ermöglicht und eine Volumenplanung, basierend auf angestrebten Verkaufszahlen in der Zukunft. Wird das Angebot zum Auftrag kann die Planung konsequent weitergeführt werden. Bei einer Vielzahl von parallelen Produktentwicklungen ergeben sich hiermit dann auch Synergien beim Einsatz von Bauteilen. Die Vielfalt läßt sich reduzieren. Die Serienanlauftermine werden auf einem schon festgelegten Ausgabestand des Produktes basierend geplant. Damit können das Werk, der Einkauf und die Logistik gezielt mit ihren eigenen Planungen beginnen.

Um so länger eine Produktentwicklung dauert, um so nötiger ist diese strategische Vorausschau für Produktion und Logistik.

ganzheitlich_1

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