Datenbankmodell "Lebenszyklus eines Produkts"

[blawen]

Hallo Zusammen

Ich habe eine strategische Frage, die mit unseren Produkten und deren Lebenszyklen zusammen hängt. Der Einfachheit halber fange ich vorne an:

Wir entwickeln und fertigen u.a. Laserschneidsysteme. In diesem Zusammenhang fertigen wir u.a. div. Leiterplatten, Module und PC’s.
Nach der Schlusskontrolle erhält jeder „Baustein“ eine eindeutige Material- und Seriennummer.

Soweit so einfach :-)

Nun, kommen meine Spezial- und somit Problemfälle:

• Aus verschiedenen Gründen kann es geschehen, dass ein fertiger „Baustein A“ umgebaut und nun zum „Baustein B“ wird.

• Im Falle eines Defektes sendet uns der Kunde den fehlerhaften Baustein ein und erhält im Gegenzug einen neuen.
  Handelt es sich um eine kostenpflichtigen Austausch, hat der Kunde die Wahl zwischen einem fabrikneuen und einem aufbereiteten und daher kostengünstigeren Baustein.
  Der Baustein des Kunden wird in unserer Reparaturabteilung kontrolliert, repariert und wieder an das Lager gelegt.
  Um nun den Baustein als aufbereiteten erkennen zu können, erhält die ursprüngliche Materialnummer einen zusätzlichen Index angehängt (-A).
  

Bisher wurden diese Prozesse jeweils in dutzenden von Excel-Tabellen festgehalten und Ihr könnt Euch sicher vorstellen, dass die Nachverfolgung des Lebenszykluses (History) eines Bausteins nicht unbedingt einfach ist.

Um das ganze transparenter und einheitlicher zu machen, habe ich den Auftrag erhalten, eine eigene Software zu erstellen. Noch bin ich ganz am Anfang und vieles habe ich angedacht und Datenbankmässig schon umgesetzt (MySQL).
Über die obengenannte Problematik bin ich mir noch nicht wirklich schlüssig, wie ich sie vom DB-Modell her am besten umsetzen könnte.

Kann mir ev. jemand einen Tipp geben?

Gruss
Blawen

[Perlsau]

Mir ist nicht so recht klar, worin dein Problem tatsächlich besteht. Du bist dir noch nicht schlüssig. Okay, soll vorkommen.

1. Womit kann die Forengemeinde dir helfen?

2. Was für Tips erwartest du, da hier ja niemand außer dir die Vorgaben kennt? Anhand der von dir gelieferten Information könnte ich jetzt keine Datenbankstruktur entwerfen, nicht mal ansatzweise.

3. Was soll die Software alles können? Lagerverwaltung? Artikelverwaltung? Offenbar verwaltet ihr euer Lager bzw. eure Artikel mit Excel-Tabellen. Das ist natürlich völlig obsolet.

[Furtbichler]

Zitat:

Zitat von blawen (Beitrag 1226724)

Kann mir ev. jemand einen Tipp geben?

Mein Tipp: Besorgt euch eine IT-Beratung, die euch eine entsprechende Architektur erstellt.

Wenn in der Firma genügend gute Programmierer herumsitzen, die die nächsten paar Monate nicht ausgelastet sind, könnt ihr euch heranmachen, ein brauchbares System zu entwerfen.

Das Datenbankmodell zu entwerfen ist nicht das Problem. Sobald man die Anforderungen in Gänze definiert hat, baut man sich ein entsprechendes Modell und prüft ggf. noch die Performance hinsichtlich der Reports, die am häufigsten abgerufen werden sollen.

I.a. reicht jedoch eine einfache 3NF, jedenfalls bei diesen Stückzahlen.

Grundsätzlich hast Du eine Tabelle der Produkte und eine Tabelle der Produkthistorie. Weiterhin benötigst eine Teileliste (die könnte mit der Produktliste identisch sein, muss aber nicht), eine Stückliste, Prozessliste, Prozesshistorie, Maschinen, Einstellwerte.

Ach, das Ganze natürlich ISO 9000 konform. Macht Spaß. Viel Spaß. :-)

Wenn ihr Hilfe braucht, meldet euch per PN.

[jobo]

Einerseits würde ich Furtbichler Recht geben, z.B. was den Berater angeht, andererseits war von ISO 9000, Maschinen, Einstellwerten, .. keine Rede.
Anhand der Infos in Deiner Frage kann man Dir jedenfalls keine Tipps zum Datenmodell geben.
Wenn bis jetzt dutzende Exceltabellen zur Abbildung des Prozess' dienen, sehe ich das Problem, dass diese Exceldaten auch anderen Prozessen dienen, die bei der Umstellung vielleicht untergehen.
Wann beginnt der Lebenszyklus der Baugruppe? Schon bei der Produktion? Beim Einbau, Lieferung oder erst bei der Reklamation?
Wenn Du Hinweise zum Modell brauchst, schreib doch mal, was Du minimal abbilden musst.

[Furtbichler]

Zitat:

Zitat von jobo (Beitrag 1226748)

... andererseits war von ISO 9000, Maschinen, Einstellwerten, .. keine Rede.

ISO 9000 ist hier eh ein Muß und ich würde annehmen, das es hier um die lückenlose Protokollierung eines Werkstückes geht, eben wegen Reklamationen, Rework etc.

Wenn man sowas anfängt, dann richtig.

[blawen]

Zitat:

Zitat von Perlsau (Beitrag 1226734)

Mir ist nicht so recht klar, worin dein Problem tatsächlich besteht. Du bist dir noch nicht schlüssig. Okay, soll vorkommen.

1. Womit kann die Forengemeinde dir helfen?

3. Was soll die Software alles können? Lagerverwaltung? Artikelverwaltung? Offenbar verwaltet ihr euer Lager bzw. eure Artikel mit Excel-Tabellen. Das ist natürlich völlig obsolet.

Gedankenansätze reichen mir vollkommen :-)

Grundsätzlich arbeiten wir mit SAP und sind ISO 9001 zertifiziert, von daher machen wir es schon nicht komplett „falsch“, haben aber noch Potential für Optimierungen.
Welche Anlage wo steht, können wir dem System entnehmen, wenn es aber z.B. um die einzelnen Komponenten eines PC’s geht, kann mir das System nur bedingt Auskunft geben.
Wenn z.B. das Mainboard ersetzt wird, sehe ich dies zwar im SAP, kann aber keinen Rückschluss auf dessen Seriennummer nehmen.
Aus diesem Grund wurde in der Vergangenheit die ganze History mittels Excel-Tabellen abgedeckt (nicht die der Maschine, sondern die der Einzelkomponenten).

Um beim PC zu bleiben:
Im Falle der Reparatur bekomme ich z.B. nur den fehlerhaften RAM-Riegel. Aus welchem PC er stammt, ist beim Wareneingang zunächst teilweise unklar (Da wir weltweit operieren ist es schwierig, in jedem Fall sicherzustellen, dass das Retourformular komplett ausgefüllt wird. Insbesondere wenn der Absender nicht eine unserer Niederlassungen, sondern der Kunde selber ist)
Anhand der Exceltabellen kann ich aber meine Rückschlüsse ziehen.

Die restlichen Fälle gehen in eine ähnliche Richtung, hier geht es ebenfalls um die Nachvollziehbarkeit (aus X wurde Y) oder aber um die Statistikführung (die Fehlerquote der RAM's aus der Lieferung XY ist auffällig hoch).

@Furtbichler

• Die ganzen Stücklisten (etc.) sind konsequenterweise im SAP hinterlegt und dies funktioniert soweit tadellos.

• 3NF sollte durchaus ausreichen, nur war ich mir über die Beziehungen nicht eindeutig im Klaren.
  Du hast mich aber mit Deinen Stichworten auf eine Idee gebracht (u.a. die Tabelle mit der Produkthistory).

Ich glaube, ich habe meinen Weg gefunden – Lieben Dank :-)
Eines kann ich Dir bestätigen - es mach Spass, wirklich sehr viel Spass :-)

[Hansa]

SAP und Excel-Tabellen bei denselben Daten ? :shock: Habe schon viel gesehen, so was aber noch nicht. :lol:

[Furtbichler]

Zitat:

Zitat von Hansa (Beitrag 1226796)

SAP und Excel-Tabellen bei denselben Daten ? :shock: Habe schon viel gesehen, so was aber noch nicht. :lol:

Nach er ersten SAP-Anpassung sind die meisten Firmen insolvent bzw. so gut wie und müssen sich erst einmal erholen. In diesen 20-50 Jahren muss man den Rest eben selbst machen.

[blawen]

Zitat:

Zitat von Hansa (Beitrag 1226796)

SAP und Excel-Tabellen bei denselben Daten ? :shock: Habe schon viel gesehen, so was aber noch nicht. :lol:

Es sind nicht nur bedingt dieselben Daten. Im SAP sind viele Daten "anonym" (Seriennummern) und dies reicht den meisten Betrieben durchaus. Geht's aber explizit um Reparaturen ist unser SAP im Moment nur bedingt geeignet.

Im vorletzten Betrieb hatten wir die gleiche Problematik. Dort wurde dieser Teil zuerst durch externe SAP Programmierer und später durch eigene umgesetzt. Dies hat aber zum einen ein Heidengeld gekostet und die Arbeiten haben mehrere Jahre beansprucht.
Der grosse Unterschied dabei ist, dass es dort um rund 250'000 Reparaturen pro Jahr geht und neben der ganzen Reparaturlogistik wird auch die eigene Werkstatt und deren Ersatzteillager über das System abgewickelt.

In diesem Sinne bewegen wir uns Zahlenmässig in einer völlig anderen Liga und kostenmässig macht die angedachte neue Lösung schon Sinn.

[p80286]

OK SAP-bashing ist beinahe so schön wie M$-bashing aber zurück zum Problem.
Wenn ich die Ausgangslage richtig verstehe gibt es Geräte, die aus mehreren Teilen aufgebaut wurden.
Diese Teile werden bei Defekt (vllt. auch das eigentliche "Gerät") ausgetauscht.
Diese Teile können neu oder "repariert" sein.
Die Reparaturen/Fehler sind dokumentiert
Alle Teile und Geräte besitzen eine eineindeutige Kennzeichnung.

Und wo klemmt es da jetzt, das ist doch eine klassische DB-Anwendung. Interessant wäre eine Ankopplung an das SAP-System wobei naturlich in beiden Systemen die gleichen Satznummern/Kennzeichnungen vorhanden sein müssen.

Gruß
K-H

[Hansa]

Zitat:

Zitat von p80286 (Beitrag 1226849)

OK SAP-bashing ist beinahe so schön wie M$-bashing

Da ist was dran 8-), M$ ist im Endeffekt aber zumindest billiger. :lol:

Aber im Ernst :

Zitat:

Zitat von blawen (Beitrag 1226724)

Bisher wurden diese Prozesse jeweils in dutzenden von Excel-Tabellen festgehalten...

SAP rühmt sich doch unter anderem für Prozessoptimierung etc. Es gibt dafür eine eigene Programmiersprache und eine eigene Datenbank. Wozu braucht man denn da noch Excel - Tabellen ? :shock: Ich kann das nicht nachvollziehen. Wenn ich jetzt ein neues Bauteil habe mit Nr. 1000 und das Äquivalent (als Austauschteil) mit der Nr. 1000A, das wären doch in dem Fall lediglich Datenbank-Felder.

Ich will jetzt TSG 1899 Hoffenheim nicht zu sehr schaden, allerdings:

SAP wird angeblich angeschafft zur Kostenreduzierung und dann passiert folgendes (in Weltkonzern !) : 4 Mann müssen "etwas an SAP umbauen". Einen treffe ich nach 6 Wochen und frage, was aus der Geschichte wurde. Es hiess dann sie hätten bis vor einer Woche da rumgebastelt, hätten dann aber doch einen externen Berater hinzuziehen müssen, weil es immer noch nicht so lief, wie gewünscht. Das sind 20 Mann-Wochen ! Mit Urlaub, Krankenschein etc. ist so ein halbes Jahresgehalt quasi vernichtet worden. Das nur, um die SAP-Kosten zu reduzieren.

Und das soll jetzt auch nicht als SAP-Bashing rüberkommen. Die Fa. an sich und solche Sachen wie Betriebsklima, Bezahlung usw. sind schon gut. Nur die, die das Einsetzen, die wissen meistens nicht, auf was sie sich einlassen. Die überschätzen sich und dann passiert so etwas wie das Geschilderte. Chef hat eine irreale Idee, die Abteilung sagt kein Problem und sie erleiden dann Schiffbruch (vorher wurden ja auch Schulungskosten gespart und das Know-How ist zu mickrig), ja und dann kommt eben doch "der teure" von SAP. Haha. :lol:

[p80286]

Zitat:

Zitat von Hansa (Beitrag 1226891)

Chef hat eine irreale Idee, die Abteilung sagt kein Problem und sie erleiden dann Schiffbruch (vorher wurden ja auch Schulungskosten gespart und das Know-How ist zu mickrig), ja und dann kommt eben doch "der teure" von SAP.

Nun, da Chefs im allg. nur in Pfannkuchendiagrammen denken, kein Wunder. Aber im Ernst, Da eigentlich "jeder" Excel auf seinem Rechner hat, und da auch alles selbsterklärend ist, kann ich schon verstehen, daß Excel die DB des kleinen Mannes ist.
Alleine das Normalisieren scheint ja schon viele abzuschrecken.

Gruß
K-H

[Hansa]

Zitat:

Zitat von p80286 (Beitrag 1226900)

...kann ich schon verstehen, daß Excel die DB des kleinen Mannes ist.

Ist sie ja irgendwie auch. Aber doch nur für den Taubenzüchterverein um die Ecke oder den, der sich um die Nebenkosten in 3-Parteien Wohnhaus kümmert. Dass aber ein SAP-Kunde auf Excel-Tabellen zugreifen muss oder will, in denen wichtige Daten gespeichert sind, das ist schon krass. Eventuell ist es aber tatsächlich so, wie ich geschrieben habe : aus Kostengründen wird versucht SAP zu vermeiden, bis es anders gar nicht mehr anders geht und dann wird rumgefriemelt oder, wie in dem Fall hier, es wird notfalls sogar Excel bemüht. :shock:

[Furtbichler]

Ich weiß gar nicht, was Du willst. SAP ist ein riesen Sammelsurium an Tabellen und -wenn man dafür bezahlt hat- individuellen Tools (besser: Add-Ons), die die Tabellen verknüpfen und bestimmte Dinge damit anstellen.

SAP ist *KEIN* fertiges Produkt wie z.B. Word oder Excel oder Delphi. Wenn die Unterstützung für Rework nicht gekauft wurde, ist sie eben nicht da. Das nachzurüsten kosten ein Schweinegeld. Also wird gesagt: "Geld ist nicht da, wir brauchen aber trotzdem eine Verfolgung". Also wird EXCEL genommen. Auch bei Weltfirmen (und ich wette, auch bei SAP selbst).

Erst wenn das überhand nimmt, oder jemand Budget freischaufelt, kommt das ins SAP.

Da muss man sich doch nicht hinstellen und so tun, als ob man sich wundert, das SAP keine eierlegende Wollmilchsau ist. Das ist ja so, als ob Du bei einem Mercedes zeterst:"Wie, fahren muss ich selbst? Und eine Sonnenterrasse hat der auch nicht?" ;-)

Ok, eine Sonnenterrasse mit EXCEL abzubilden ist jetzt nicht soo trivial. :stupid:

[Hansa]

Zitat:

Zitat von Furtbichler (Beitrag 1226912)

... Das ist ja so, als ob Du bei einem Mercedes zeterst:"Wie, fahren muss ich selbst? ...

Polemik ist hier fehl am Platze. 8-) Oder solls mal wieder OT werden ? Fakt ist : egal ob SAP und Co. im Zusammenspiel mit Excel & Co. (oder denke dir eine andere Kombination aus) : es gilt nach wie vor, unnötige Redundanzen tunlichst zu vermeiden. Wie soll das aber vernünftig realisiert werden, wenn wichtige Daten an 2 verschiedenen Stellen vorgehalten werden ? :lol:

[Furtbichler]

Zitat:

Zitat von Hansa (Beitrag 1226938)

Polemik ist hier fehl am Platze.

Sagt der Richtige ;-)
Es geht in den Betrieben leider nicht darum, was vernünftig ist, sondern das es realisiert wird.

Ich habe in meiner Arbeit als Consultant festgestellt, das die Güte der IT-Werkzeuge, mit denen Mitarbeiter die täglichen Probleme lösen, umgekehrt proportional zum Firmengröße ist. Bei Siemens, OSRAM, Bosch & Co (um nur einige zu nennen), sind EXCEL-Listen zur Produktions- und Qualitätskontrolle an der Tagesordnung. Nicht an jedem Platz (das kann ich nicht beurteilen), aber dennoch eigentlich immer dort, wo ich zum Einsatz komme.

Redundanz und Handarbeit sind in der EDV leider die primären Werkzeuge des 21. Jahrhunderts.

Der Gipfel ist eine Firma, die Daten sammelt. Die Datenquellen (Radio- und Fernsehsender) sollen ihre Daten (teilweise) ausdrucken und per LKW zu dieser Firma schicken. Dort werden sie dann von fleißigen Menschen per Hand eingetippt. Oft genug werden die Daten als EXCEL- oder WORD-Datei per EMail verschickt und in der Firma selbst ausgedruckt und abgetippt. Natürlich geht der größere Teil per Text-Datei nach einem 30 Jahre alten Standard per Import in die DB, aber es sind ca. 30 Personen dauerhaft damit beschäftigt, diese schildbürgerhaften Ausdruck-und-wieder-eintippseleien zu vollziehen.

Unsere Aufgabe ist es eigentlich, diesen Quatsch abzustellen. Nur, wenn die Firma nicht mitmacht...?

[mkinzler]

Zitat:

...egal ob SAP und Co. im Zusammenspiel mit Excel & Co. (oder denke dir eine andere Kombination aus) : es gilt nach wie vor, unnötige Redundanzen tunlichst zu vermeiden.

Wie lange glaubst Du braucht es, bis ein Berater im hohen Bogen aus einem Unternehmen fliegt, wenn er den Mitarbeitern "ihr" Excel verbietet? ;)
Theorie vs Praxis. In der Wirtschaft ist die Verwendung(Missbrauch) von Officeprodukte für Dinge, für die diese nicht primär entwickelt wurden, gang und gäbe. Selbst für Dinge, für die man eigentlich passende Tools hat wird dann lieber eine selbstgeschusterste Exceltabelle verwendet, da man "da ja versteht, was passiert" (leider ist das oft nicht so). Vielen ist die Einarbeitung in andere Programme halt lästig und nimmt dann "das Bekannte".

Zitat:

Wie soll das aber vernünftig realisiert werden, wenn wichtige Daten an 2 verschiedenen Stellen vorgehalten werden ?

Oft wäre es ja ein Vortiel die Daten nur einfach redundant ( 2 mal) zu haben. In der Praxis existieren dann noch 5 Versionen der Tabelle, jede mit anderen Änderungen; aber keine vollständig.

[Furtbichler]

Wobei man zugeben muss, das so eine EXCEL-Tabelle in vielen Fällen vollkommen ausreicht. Ich mach fast die ganze Projektplanung und -verfolgung damit. Es ist einfach genial.

Nur eben nicht so richtig mehrbenutzerfähig. Und auch nicht so richtig nachhaltig. Und recherchieren in alten Beständen ist auch blöd. Oder Reporting über die alten Dateien: geht gar nicht.

Aber sonst. :stupid: