Empfehlung für Date nbanksystem Baugrup pen/Geräte?

Hallo Ralph.

Wenn es nur um die Dokumentation geht: Exelsheet.

Ist komplizierter. D=FCrfte aber mit Exelsheets auch noch zu machen sein. Mir fehlt aber die Erfahrung mit Exel, um dazu mehr zu sagen.

Ich habe das f=FCr meinen eigenen Arbeitsplatz f=FCr zwei Baugruppen mit

150-200 Exemplaren per anno f=FCr Dokumentation und Reparaturen gemacht. Das Problem ist, wenn im Feld Modifikationen gemacht werden, werden die meist nicht mitgeteilt. Und wenn doch, hat irgendjemand bestimmt eine Seriennummer falsch gelesen.

Das geht schon Richtung "echte" Datenbank. Datenbanken definieren sich nicht nur durch Gr=F6=DFe, sondern fast noch mehr durch die gegenseitigen Verkn=FCpfungen. Das wird schon bei kleinen Sachen sehr schnell kompliziert. :-)

Ich habe f=FCr private Zwecke auch mal mit Datenbanken angefangen, erst einfach, und dann gesehen, da=DF einfach nicht wirklich geht.....jetzt w=FChle ich mich schon monatelang autodidaktisch in mysql ein. :-(

Fang damit an, auf einem Blatt Papier zu skitzzieren, was f=FCr Daten ben=F6tigt werden, wie die Zusammenh=E4ngen und verkn=FCpft werden sollen. Dann erh=E4ltst du einen =DCberblick, was Du =FCberhaupt brauchst. Die Problematik ist nichtlinear. F=FCr einfache F=E4lle langt Excell oder eine csv-Datei, und dann schwirrt es ab.

Mit freundlichem Gru=DF: Bernd Wiebus alias dl1eic

Codes können von externer Hard- und Software verarbeitet werden. Ordentliche Scanner tun dann so als wäre es eine Tastatureingabe, einfachere Scanner packen den Inhalt einfach in die Zwischenablage.

Dafür reicht eine einfache Textdatei und als Hilfsmittel ein paar automatisierte Befehle (grep usw.) - mit ein paar Zeilen Perl bekommst du da alles zusammen was du brauchst.

Natürlich kannst du auch Excel verwenden. Noch besser wäre z.B. MySQL oder so.

Spricht dafür, das z.B. über ein Web-Interface zu machen.

Ich persönlich verwende für sowas gerne Filemaker oder eben Text-Dateien und Perl.

Schönen Gruß Martin

Hallo, Am Tue, 03 May 2011 09:30:12 +0200 schrieb "Ralph A. Schmid, dk5ras" :

[snip]

Mir kam da spontan OTRS in den Sinn, das ist zwar von Hause aus ein Ticketsystem, aber dort ist ja auch die Nachvollziehbarkeit das Thema und dank Open Source kann man das beliebig anpassen..

Gru=DF Jan

Hallo,

Am 03.05.2011 11:35, schrieb Wiebus:

...[...]...

Korrekt. So habe ich das auch kennen gelernt. Es scheint auch der einfachste und am leichtesten zu vermittelnde Weg zu sein.

Die CVS-Datei wird doch in Excel bearbeitet. Also gleich eine Excel-Datei anlegen. Die kann man notfalls für Migration und Export als CVS rausschreiben. Bei einer Windows-Netzumgebung scheint das mit dem file locking auch zu passen.

Der Aufwand eine db-Lösung mit Webinterface zu implementieren und anzupassen erscheint den Entscheidern vmtl. Overkill. Die Akzeptanz der Lösung ist fraglich, auch wenn sie (IMHO) mit an Sicherheit grenzender Wahrscheinlichkeit eine erheblich bessere Investitionssicherheit bietet. Ein angenehmer Kolateralnutzen wäre die Möglichkeit automatisiert Typenschilder erzeugen und ausdrucken zu können.

MfG

Uwe Borchert

Gibt es in Deiner Gegend Wettbewerber oder Fabrikanten mit ähnlichen Problemen? Dann solltest Du die fragen. Einen Verband?

Wenn Du es selber machen willst oder Dir von einem völlig Unbekannten etwas andienen lassen möchtest, dann mach erst mal alles von Hand auf Papier selber, damit Du *genau* rauskriegst, was Du willst und

*brauchst*. U.U. sind dann auch irgendwelche ISO-Sachen zu bedenken.

Um eine EDV-Lösung hinzukriegen, solltest Du in der Lage sein, die selben Aufgaben nach Deiner Anweisung von einer genügend großen Zahl von Hilfsarbeitern erledigen zu lassen: Was soll wie erfaßt werden, und wer mus was an wen weitergeben. Fertig :-).

Grüße, H.

In meiner letzten Firma haben wir genau solche Sachen gemacht. (Prozeßmodellierung/Track&Trace). Ich habe deshalb erhebliche Erfahrungen, besonders was die Probleme betrifft, die bei sowas auftreten.

Da ist schon der erste Knackpunkt. Wenn das System insgesamt funktionieren soll, muß die individuelle Identifikation für alles und über den gesamten Prozeß hinweg gewährleistet sein. Da ist eine maschinenlesbare ID nicht nur ein schönes Extra, sondern absolut unverzichtbares Übel (weil teuer). Teuer nicht nur in der Anschaffung, sondern auch im Betrieb, denn Teile mit unlesbaren IDs sind zwingend als Ausschuß zu behandeln. Versucht man darauf aus Kostengründen zu verzichten und es ganz oder teilweise durch manuelle Eingaben zu ersetzen, ist das System schon so gut wie tot. Die Fehlerrate bei manueller Erfassung länglicher IDs liegt nach meiner Erfahrung zwischen 2 und 5%. Da die ID aber das einzige ist, was ein RL-Teil mit seinem DB-Pendant verknüpft, führt praktisch jeder Eingabefehler zu massiven Folgeschäden im Datenbestand. Dementsprechend wird eine beliebige Steuerungslogik, die ihre Istwerte aus der DB bezieht, irgendwann falsche Entscheidungen treffen.

Wenn dir nicht klar ist, warum das so schwerwiegende Folgen hat, kann ich dir gerne ein paar einfache Beispiele liefern, die die auftretenden Probleme veranschaulichen.

Die Zahl der Teile oder was auch immer spielt bei dieser Sache eigentlich überhaupt keine Rolle. Die hat bloß Einfluß auf die nötige Speicherkapazität und Geschwindigkeit des DB-Backend. Plattenplatz und Rechenzeit ist heute so billig, daß man daran kaum einen Gedanken verschwenden muß, solange man nicht in den Bereich von Millionen Transaktionen(*)/Jahr kommt.

(*)Transaktion ist hier im Sinne von "Veränderung des Status eines Teiles" gemeint.

SAP ist allerdings sowieso nicht dazu geeignet, Prozesse einzelteilgenau in "Echtzeit" zu verfolgen. Das ist aber unbedingt erforderlich, wenn man prozeßwirksame Steuerungslogik aus dem Datenbestand füttern möchte.

Das ist der nächste Knackpunkt. Eigenkreation von Prozeßmodellen und Prozesslogik geht praktisch immer schief. Die wenigsten Nichtprogrammierer sind in der Lage, die nötigen Abstraktionen zu verstehen und korrekt einzusetzen. Schon scheinbar einfache Prozesse sind bei genauerem Hinsehen nämlich oft sehr kompliziert. Und man muß genau hinsehen, um alle Eventualitäten abzudecken. Tut man das nicht mit genügender Gründlichkeit, droht auch hier wieder die Divergenz zwischen Modell und Realität, wenn so eine unvorhergesehene Eventualität eintritt.

Dazu kommt aber noch ein weiteres Problem. Bei solchen, notwendigerweise sehr detaillierten Prozeßabbildern, wie sie zur Einzelteilverfolgung nötig sind und zusätzlich komplexer Steuerungslogik gibt es kaum noch das, was man als klassische Stammdaten betrachten könnte. Fast alles muß irgendwie "beweglich" sein.

Einen konkreten Hinweis auf eine Software kann ich nicht geben weil zuweit weg wohnend. Hier haben wir Agile verwendet und vorher ein DOS-basiertes MRP System. Ich fand das DOS-basierte besser, aber es erlaubte keine einfachen Links zu CAD.

Abraten wuerde ich von selbstgebauten Loesungen und dergleichen. Es sei denn Ihr stellt mindestens zwei Spezis dafuer ein bei denen garantiert ist dass immer einer da ist, mit ellenlangen Kuendigungsfirsten. Denn wenn Ihr erstmal so ein System eingefuehrt habt geht nach einem Ausfall dessen nix mehr.

Man muss auch aufpassen dass ein gekauftes System von einem selbst konfigurierbar ist und nicht alles ueber Change Orders gegen viel Geld vom Hersteller gemacht werden muss. Einer hier im Thread gab den entscheidenden Tip: Mal bei Betrieben in der Gegend oder am Stammtisch fragen, was aehnliche oder am besten leicht groessere Betriebe in der Gegend so nehmen. Wenn Medizintechnik oder Luftfahrt, umso besser, denn bei denen muessen solchen Systeme vorhanden und voll audit-faehig sein. Die koennen Euch auch sagen wie gut und prompt der Service ist, denn manchmal braucht man den Mann vor Ort, und schnell.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Naja, _das_ Problem ist nun schon länger gelöst ;)

--
Thomas Kindler

Letzlich hat Ralph ja genau das mit dem OP getan.

Gru=C3=9F, Enrik

Nur, wenn genug Platz für hinreichend Redundanz ist. Oft genug ist nichtmal genug Platz für die ID. Der Mann muß das ja auch noch lesen können.

Klar, das ist schon ein sehr guter Anfang. Ich meinte eher in seiner Gegend. Fuer uns war es damals wichtig dass das naechste EDV Team nicht in Suedkalifornien oder etwa an der Ostkueste sass, oder gar in Indien. Es hat Situationen gegeben wo wir sofort jemanden vor Ort brauchten weil was klemmte. Einen Tag vor Ende des Quartals waere das sonst ein ganz grosser Driss. Daher haben wir uns Referenzen geben lassen, damit wir erstmal andere lokale Kunden von denen befragen konnten.

Man sollte auch die beinahe wichtigste aller Fragen mit dem Hersteller des Systems abklopfen: Wie kann man temporaer im "Handbetrieb" weitermachen? Bei uns trat dieser Fall ein als die Gegend ueberflutete. Der dicke LKW kam da durch, aber einige Trafos waren abgesoffen, der Strom war weg und nach 2-3h waren die UPS am Ende. Ohne formale Move Tickets haetten wir den LKW nicht beladen duerfen.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Es wäre halt schön, da ein halbwegs fertiges Produkt zu kriegen. Die Zeit dafür, sowas selber zu schreiben, ist einfach nicht da.

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

So läuft es ja derzeit, das ist eben sehr mühsam :)

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Klingt gut :)

MOmentan ist es eine Mischung aus aufgeklebten numerischen ID-labels von der Rolle, und eben Matrixcodes, die der Bestücker bereits aufklebt. Damit kann man gut leben, auch die manuell draufgepappten Nummern sind eindeutig, und in der manuellen Erfassung funktioniert das derzeit ja bestens. Es ist nur eben lästig, zwei Excel-Tabellen und einen Papierordner zu führen und permanent abzugleichen.

So weit soll es gar nicht gehen, es soll daraus keine Steuerungslogik gefüttert werden, sondern einfach nur der Überblick behalten werden, wo was genau gerade in welchem Zustand ist. Dazu ist alles eh Handarbeit, keine Fließbandproduktion, und wenn eine Baugruppe mal in einer Losgröße von 100 Stück aufgelegt wird, dann ist das schon ziemlich viel :)

Ja, eben, aber ich wollte eben andeuten, daß keine hig performance-Lösung gefragt ist, es geht da sehr gemächlich zu.

Klar.

Das ist schon zu weit gedacht. Es wäre absolut ausreichend, zum Beispiel die 70 neu angelieferten Platinen des Typs 4711 erst mal numerisch zu erfassen, bei deren Inbetriebnahme und Prüfung die Status den einzelnen Platinen zuzuordnen, um im Idealfall am Ende jeder Platine eine grüne Lampe für "kann jetzt verbaut werden" zu haben. Diese "grüne Lampe" ist momentan durch das Typenschild virtuell gegeben - sobald die Baugruppe das Typenschild hat, ist sie geprüft, fertig, dokumentiert und verbaubar. Die geschieht anaolg mit allen Baugruppentypen. Wird dann ein neu zu fertigendes Gerät des Typs abc mit S/N uvw angelegt, dann checkt man darin die Platine 4711 mit Seriennummer 123 ein, die Platine 0815 mit ihrer S/N 456, usw usf. Wird dann irgendwann im Gerät uvw die Platine 4711 repariert oder ersetzt, dann wird das entsprechend umgebucht. Dazu werden noch Revisions- und softzware-Stände mitgezogen, und in einem Texttfeld zu den Geräten wird Verkaufsdatum, Kunde oder Mieter und evtl. Standort geführt.

So in der Art halt...also eher einfaches Zeugs, was bisher mühsam in x parallelen Listen geführt wird. Die notwendigen Verknüpfbarkeiten sind somit seit Jahren bekannt und eingespielt und müssen "nur" elektronisch abgebildet werden. Und da, denke ich, sollte es doch bereits Lösungen geben, die flexibel genug sind...

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Zwingend als Ausschuss? Aeh, wieso das denn? Bei uns kam das in ein separates Koerbchen und es gab einige Leute die befugt waren das zu untersuchen und nach Gutheissung mit neuem Baepperle wieder in den Warenlauf zu geben. Man verschrottet ja auch kein Auto nur weil der Aschenbecher voll ist :-)

Manuelle Erfassung? Uargh. Das hatten wir seit Urzeiten mit Barcodelesern gemacht, die kosten heutzutage echt nicht mehr die Welt. Seid aber vorsichtig, da Ihr HF Entwicklung macht erstmal auf EMV abklopfen. So manches "Schnaeppchen" aus China haelt die EMV nur auf dem Papier ein.

Da reichen doch fast noch Vollzugsmeldungen in eine Datenbank.

M.W. gibt es aus Euren Landen als Beispiel "SAP Business One", habe ich aber noch nicht in Aktion gesehen. Duerfte anfangs vermutlich wie Overkill aussehen und man muss immer ueberlegen wieviel Seats man wirklich braucht (ist teuer). Cheffe, Buchhaltung, Entwicklungsleiter, Produktionsleiter, Wareneingang/Ausgang reicht manchmal fast. Muss man aber gut verhandeln dass sie nicht fuer jeden PC mit Barcode Reader oder zum Eintippen extra wollen.

Ein wenig haengt das vom ganz langfristigen Ziel ab. Wo seht Ihr Euch umsatzmaessig in 20 Jahren? Aus einem MRP System rauszuwachsen habe ich einmal erlebt und das ist alles andere als lustig.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

FileMaker wäre ein fertiges Produkt und es könnte über das Web benutzt werden.

Abgesehen von den einmaligen Lizenzkosten entsteht aber ein weit höherer Aufwand, die Datenstrukturen erst mal zu entwerfen (auf Papier und im Hirn, in der Datenbank geht das sehr flott), wie auch die entsprechenden Bedingungen, Aktionen und Automatismen zu erzeugen (das dauert in der Datenbank schon erheblich länger) und noch die Benutzeroberfläche ansprechend zu gestalten (das dauert viel zu lange im Vergleich zum rein technischen Nutzen, erzeugt aber erst die nötige Akzeptanz und den Spass an der Nutzung).

Beispielsweise ist ein ganz wichtiges Grundprinzip und Schlüsselmerkmal unterschiedlicher Datenbanken der Versionierungsgedanke: Kann man einfach Daten wieder löschen oder kann man dies verbieten und Daten nur als ungültig deklarieren? Kann man die Daten so aufbereiten, dass man alles oder nur das nötige und hilfreiche sieht? Wie leicht geht das? Und wie sichert man die Daten insgesamt?

Schönen Gruß Martin

Für die Matrixcodes wird natürlich bereits so ein Ding verwendet, hat sich auch bewährt.

Eben deswegen lieber kein so krasses Teil wie SAP :)

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/

Am Tue, 03 May 2011 09:30:12 +0200 schrieb Ralph A. Schmid, dk5ras:

[...]

[...]

Du suchst also Software für Product Lifecycle Management (PLM).

Du könntest dich im Umfeld von (Mechanik-)CAD-Programmen umgucken. Da gibt es eiigentlich für die "Großen" bzw. "Beliebten" (AutoCAD, Solidworks, ProEngineer, Catia, ...) immer PLM-Lösungen, meistens von Drittfirmen via API-Propgrammierung. Und Elekro-CAD-Module auch, also sollte da was möglich sein. "Billig" wird es eher nicht.

Freie Software kenne wenig, aber einen Blick wert ist TUTOS [1], wenn man es passend anwendet und ggf. PHP ür Erweiterungen spricht oder ein Budget für kommerzielle Hilfe hat. Um sicher zu gehen würde ich dringend eine Testphase empfehlen. Für kleinere Serien von Geräten eignet es sich relativ gut, um Reparaturen, Softwareupdates, Kunden & Wünsche, Lieferanten, etc. damit zu erfassen.

HTH, Marc

[1]

--
NOBODY EXPECTS THE SPANISH INQUISITION

Excel *kann* zwar wie eine Datenbank genutzt werden, ist es aber nicht. Man darf dem Programm die Unbequemlichkeit daher nicht übelnehmen. Warum versuchst Du nicht MS-Access? (Mir war das immer zu fett. Ich war ein FoxPro-Fan, aber das gibts ja leider nicht mehr). Wenn das auf Papier alles schon läuft, ist der Selbermach-Umstieg vielleicht garnicht so schwer, und Du weißt nachher, was Du hast :-). Ich höre viel Lob für Firebird

Da must Du aber wohl mit dem SQL-Interface auskommen, wenn Du kein zusätzliches Frontend stricken willst.

Die wenigsten Programmierer sind in der Lage, den Bedarf des Auftraggebers zu erfassen, selbst wenn ihnen mit Engelszungen vorgesungen wird. Meist benötigt man mehrere Iterationen, um in etwa zum gewünschten Ziel zu gelangen. Wenigstens "in etwa" :-).

Grüße, H.