ERP Software mit Delphi

[Dragon27]

Hallo Union,

danke für deinen Einwand. Sicher hats du recht, dass ich das Ganze sehr allgemein gehalten habe .

Also es geht um einen produzierenden Betrieb und es soll praktisch eine Auftragsverwaltung, Lagerverwaltung, Produktionsplanung
und eine Betriebsdatenerfassung realisiert werden. Der nächste Schritt wäre dann Fakturierung und Controlling.

Problematisch an fertigen Lösungen ist, dass der Betrieb nicht nach einem Standarschema arbeitet und auch verschiedene "Wachstumsprobleme" wie doppelte Artikelnummern (die aber auch nicht abgeändert werden dürfen) vorhanden sind. Da das Unternehmen als Zulieferer für Großhändler tätig ist und somit verschiedeneste Schnittstellen und Wünsche befriedigt werden müssen, ist auch hier ein Standard ERP probelmatisch.

Mir ist bewusst, dass ein ERP keine einfache Sache ist und sehr umfangreich werden kann. Aber nach mehrmonatiger Recherche sind wir in diesem Fall zum Schluss gekommen, dass eine Eigenentwicklung Sinn macht.
Gerade weil mir bewusst ist, wie komplex dieses Projekt werden kann freue ich mich auf Eure Erfahrungen und Tipps.

[Union]

Naja, dann den üblichen Weg. Alle Vorgönge im Betrieb beschreiben, analysieren und dokumentieren. Wenn schon eine ISO Zertifizierung besteht wird's einfacher. Daraus dann Konzepte erstellen, Kosten und Resourcen kalkulieren und los...

[Dragon27]

Zitat von Union:

Naja, dann den üblichen Weg. Alle Vorgönge im Betrieb beschreiben, analysieren und dokumentieren. Wenn schon eine ISO Zertifizierung besteht wird's einfacher. Daraus dann Konzepte erstellen, Kosten und Resourcen kalkulieren und los...

Das ist der Ablauf, der auch sicherlich sinnvoll ist. Nur leider bin ich mir mit der Architektur nicht sicher sprich welche Datenbank bzw. ist Delphi überhaupt das richtige Tool und gibt es vielleicht "Erleichterungen" in Form von Komponenten, Literatur oder Erfahrungen eurerseits.

[sx2008]

Also wenn du das Projekt quasi mit Null startest musst du mit 15 bis 50 Mann(Frau)jahren rechnen.
Dafür bekommst du aber nur eine 2-Tier oder bestenfalls 3-Tier-Lösung.
Für Webanwendungen ist Delphi nicht wirklich das beste Werkzeug.
Du musst auch damit rechnen, dass das neue ERP bestenfalls in 2 Jahren soweit ist, dass es einen Nutzen bringt.

Wenn du sparen möchtest musst du ein existierendes ERP verwenden und an die Gegebenheiten anpassen.
Manchmal bedeutet das aber auch ineffiziente Abläufe in der Firma zu kappen und zu verbessern (gegen den Widerstand von manchen Mitarbeitern und Chefs).

Zitat:

2. SQL oder NoSQL?

Definitiv eine SQL-Datenbank.

[Lemmy]

Zitat von Dragon27:

Nur leider bin ich mir mit der Architektur nicht sicher sprich welche Datenbank bzw. ist Delphi überhaupt das richtige Tool...

das darf aber während der Planung keine Rolle spielen.

Beispiel DB: Wird bei der Planung klar, dass 1000 Anwender gleichzeitig mit der Anwendung arbeiten, sind an die DB (und die Serverhardware) andere Anforderungen zu stellen als bei 10 Anwendern.

Dann sollten grundsätzliche Dinge abgeklärt werden: Welches Betriebssystem ist das Ziel? Sind Mobillösungen notwendig (vielleicht auch nur für Teilaspekte direkt in der Produktion)?

Gibt es schon jetzt definierte Schnittstellen an bestehende Systeme (Bestellsysteme von Partnern, Großhändlern...)?

und letztlich: Welcher Zeitrahmen ist für das Projekt vorgesehen. Bist Du der einzigste Entwickler? Ist ein Team vorhanden oder muss das erst noch aufgebaut werden?

Anhand dieser und vieler weiterer Punkte kann man sich dann überlegen welche Sprache und Datenbank geeignet ist

[relocate]

Zitat von Dragon27:

...
danke für deinen Einwand. Sicher hats du recht, dass ich das Ganze sehr allgemein gehalten habe .

Hallo Dragon,

wir wollen gerade den umgekehrten Weg gehen, eine Delphieigenentwicklung durch ein Standardsystem zu ersetzen, da die Delphilösung an ihre Grenzen stößt.

Zitat von Dragon27:

Also es geht um einen produzierenden Betrieb und es soll praktisch eine Auftragsverwaltung, Lagerverwaltung, Produktionsplanung
und eine Betriebsdatenerfassung realisiert werden. Der nächste Schritt wäre dann Fakturierung und Controlling.

Ist erstmal nichts spektakuläres, was nicht zum Standardrepertoire eines ERP Systems zählen würde.

Zitat von Dragon27:

Problematisch an fertigen Lösungen ist, dass der Betrieb nicht nach einem Standarschema arbeitet und auch verschiedene "Wachstumsprobleme" wie doppelte Artikelnummern (die aber auch nicht abgeändert werden dürfen) vorhanden sind. Da das Unternehmen als Zulieferer für Großhändler tätig ist und somit verschiedeneste Schnittstellen und Wünsche befriedigt werden müssen, ist auch hier ein Standard ERP probelmatisch.

Auch solche "Wachstumsprobleme" sind nicht selten. Oftmals trifft man auf so etwas, wenn Unternehmen von anderen übernommen werden, dann ist es oft schwierig die IT-Systeme von beiden Unternehmen zu vereinheitlichen, aber nicht unmöglich. Fälschlicherweise verstehen Unternehmen ERP Projekte aber immer noch als reine EDV Projekte, ein ERP Projekt sollte aber ein Organisationsprojekt sein. Das bedeutet um ein ERP System sinnvoll nutzen zu können muss die Organisationsstruktur mal überdacht werden, denn mit einem neuen System ohne eine gewisse Reorganisation macht man eigentlich nur da weiter wo man vorher war, vielleicht ein wenig schicker, aber eben immer noch genauso verkorkst wie vorher. Das ist keine Verbesserung. Mit den doppelten Artikelnummern wirst Du in einer selbst programmierten Lösung genauso zu kämpfen haben wie in einer "fertigen" Lösung (die ja eigentlich nicht fertig sind, sondern bis zu einem gewissen Grad immer an das Unternehmen angepasst werden muss, aber auch das Unternehmen sollte vielleicht doch bereit sein die Wachstumsprobleme mal anzugehen). Individuelle Schnittstellen sollten für ein gutes Standard ERP System eigentlich auch kein Problem sein, denn letztlich ist es immer nur eine Umwandlung von bestehenden Daten in ein anderes Format. Auch wir haben dieses Problem und eben da ist die Schwierigkeit mit unserem System Daten von einer Form in die andere zu bringen.

Zitat von Dragon27:

Mir ist bewusst, dass ein ERP keine einfache Sache ist und sehr umfangreich werden kann. Aber nach mehrmonatiger Recherche sind wir in diesem Fall zum Schluss gekommen, dass eine Eigenentwicklung Sinn macht.
Gerade weil mir bewusst ist, wie komplex dieses Projekt werden kann freue ich mich auf Eure Erfahrungen und Tipps.

Selbst die Anpassung eines Standard ERP Systems ist keine einfache Sache, umso mehr gilt dies für eine eigene Entwicklung, also ehrlich, das wird eine echte Mammutaufgabe. Wenn Du magst können wir gerne per PN Erfahrungen austauschen.

Gruß relocate

[Furtbichler]

Ich würde es auch nicht selbst entwickeln, sondern von der Stange kaufen. Der Betrieb muss sich dann eben etwas anpassen, aber das ist ja auch der Sinn der Sache.

Ich habe eine solche Lösung mal entwickelt (Delphi, BDE, Produktionsplanung, Lageverwaltung). Die 15-20 PJ, die hier erwähnt wurden, würde ich auf 10-15 korrigieren, aber da ich die genauen Anforderungen nicht kenne, ist auch 15-20 eine angemessene Schätzung.

Erste Teile werden nach 6-12 Monaten laufen, aber bis das ganze fehlerfrei funktioniert, dauert es eben. Dann doch lieber was Fertiges.

15 PJ entsprechen, nebenbei bemerkt, ca. 700.000 Euro. Dafür bekommt man schon was Nettes. Kleines.

[Hansa]

Zitat von Furtbichler:

Ich würde es auch nicht selbst entwickeln, sondern von der Stange kaufen. Der Betrieb muss sich dann eben etwas anpassen, aber das ist ja auch der Sinn der Sache.

Das ist wie mit dem Anzug von der Stange. Der Massanzug sitzt eben doch einfach besser. "etwas" anpassen, das ist ja auch relativ und heisst eigentlich : Firma umbauen und Betriebsabläufe an die Software anpassen. Ne, das wird nicht passsen.

[DSCHUCH]

Wir entwickeln ja ERP mit Delphi. Das auch sehr spezialisiert für Sondermaschinenbau sowie Zulieferer für Luftfahrt, Automobil und sonstige Spezialprodukte (Spanabhebend). Das ganze auch sehr produktionslastig mit Schwerpunkten Maschinen/Ressourcen/Materialplanung und Kalkulation von Produkten. In letzter Zeit auch vermehrt Projektmanagement. Standardabläufe wie Auftrag, Lieferschein, Rechnung kann jedes System. Aber auch hier gibt es schon wichtige Details: Kundenklassen? Preisklassen? Mehrspraachigkeit? Währungen? Wir haben auch Kunden welche Produktion und Handel betreiben, das sind mit die kompliziertesten Abläufe, gerade hinsichtlich Preisbildung etc.

Ich muß immer wieder schmunzeln, wenn ich dies Aussagen höre "machen wir es selbst". Wir haben mittlerweile 20 Jahre Erfahrung und kranken noch immer an bestimmten Prozessen. Dies liegt aber nicht vorrangig technischen Umsetzungen, sondern sich permanent ändernden Anforderungen, zu komplexen Abläufen was die Bediener nicht verstehen usw. Ohne eine breite Kundenbasis erhälst du nie ein vernünftiges Endprodukt, da es zu wenig Einflüsse hat. Der Teufel liegt im Detail, die Ausrichtung eines ERP, also dessen Schwerpunkte sind Erfolgsentscheidend für ein Unternehmen.

Ich muß klipp und klar sagen: hätten wir kein fertiges Produkt, würde ich selbst mit unserem Kundenstamm nie- und nimmer wieder eine ERP Entwicklung beginnen. Das ist der blanke Wahnsinn und kostet unmengen an Geld. Gerade aus sicht eines Kunden ist es da 1000 mal billiger ein Heer von Sekräterinnen zu beschäftigen, oder eben - was auch unsere Strategie ist - dem Kunden zugang zu den Sourcen zu geben damit diese sich im Zweifel selbst etwas stricken können. Aber auch hier klare Erfahrung: das funktinoiert NIE, gerade im Mittelstand sind die Unternehmen meist nicht in der Lage ihre eigenen Prozesse zu klären. Was da an Geld versenkt wird, weil Dinge nicht durchdacht oder mit zu wenig Erfahrung gebastelt werden, no comment. Es gibt ja auch Lösungen wie OpenERP, wo man selbst dran bauen kann. Hier existiert aber zumindest mal ein funktionierendes und durchdachtes Grundsystem, Bedienstruktur, Hilfe usw.

Wenn ich schon höre das ihr "1 Artikelnummer für mehrere Artikel" habt und dies auch beibehalten wollt, geht mir gleich der Hut hoch. Somit kann man nie eine klare Lagerverwaltung aufbauen. Beschaffungsmanagement wird nie funktionieren, Du kannst nie bestimmte Normen für Etikettenformate einhalten. Inventuren werden eine Katastrophe, etc pp. Wenn ihr da Probleme habt, löst man dies über interne und externe Artikelnummern. Also 1 interner Artikel "Computer", welcher pro Kunde eine Kundenartikelnummer erhält. Diese Art von Problemen ist auch Standard, jedes Unternehmen, welches mit X Insellösungen arbeitet und auf ein Globalsystem wechselt, hat diese Probleme. Scheitern tut das an den Projektleitern und mangelnder Erfahrung wie man damit umgeht und wie es richtig in einer Software abgebildet wird. (Also beibehalten und verändern zugleich )

Ich sage Dir vorraus: wenn Du als IT'ler ohne die notwendigen wirtschaftlichen und organisatorischen Hintergrundkenntnisse, wie man ein ERP in einem Unternehmen einführt und durchsetzt bzw. wie man ein unternehmen umstrukturieren *muß* um ein Zentralsystem zum Laufen zu bekommen (heißt alle Insellösungen abschaffen und auf ein einheitliches System bringen), das auch noch selbst entwickelst, wird Dein Job zur Hölle.

Zu Deiner Frage - wir sind recht zufrieden mit Delphi als GUI-Entwicklung, nehmen aber DevExpress. Standard Delphi - forgett it. Können ja die Grids nichtmal sortieren. Auch unsere Anwender sind sehr zufrieden. Logik bauen wir aber viel in plpgSQL, einfach stabiler, zu viele AV bei Delphi mit komplexen abläufen und Strukturen wenn die Anwendung 24*7 laufen muß. Unser ServiceDienst schmiert auch ca. alle 3-6 Monate ab, aus unerklärlichen Gründen. Machne unserer Kunden starten Ihre Server nur alle 2 Jahre einmal durch, da fällt das dann auf. Wir haben aber so entwickelt, das die Anwendung auch ohne Applicationserver in einem "Abgesicherten Modus" mit Grundfunktionen weiterläuft. Und : UNBEDINGT SQL. Sonst hast Du ja nochmal 5 Mannjahre mehr

[Furtbichler]

Zitat von Hansa:

Zitat von Furtbichler:

Ich würde es auch nicht selbst entwickeln, sondern von der Stange kaufen. Der Betrieb muss sich dann eben etwas anpassen, aber das ist ja auch der Sinn der Sache.

Das ist wie mit dem Anzug von der Stange. Der Massanzug sitzt eben doch einfach besser. "etwas" anpassen, das ist ja auch relativ und heisst eigentlich : Firma umbauen und Betriebsabläufe an die Software anpassen. Ne, das wird nicht passsen.

Eben nicht.

Das ist so, als ob man mit einer sehr schlechten Körperhaltung einen Anzug von der Stange kaufen will und dann vorher zum Orthopäden muss, um seine -sehr ungesunde und auf Dauer kostspielige- Fehlhaltung zu korrigieren. Hier kommt es auf die Systemintegratoren an, um zu unterscheiden, ob die Korrektur zu einer gesunden, aber immer noch individuellen Haltung führt, oder so starr ist, das man hinterher stocksteif im Stechschritt marschiert.

Es ist also kein Manko, das man sich anpassen muss, sondern eher eine Weiterentwicklung.

Die ausgereiften Lösungen 'zwingen' die Betriebe, ihre Prozesse zu überdenken und ggfs. an die etablierten Vorgaben der Software anzupassen. Unterm Strich profitieren die Betriebe und meist amortisiert sich die Software allein durch Prozessoptimierungen, d.h. Fertigungs- und/oder Qualitätssteigerungen von alleine.

Die Profis, die die ERP-Software entwickeln und die Betriebe bei der Integration unterstützen, machen das ja nicht zum ersten Mal. Aber so gut wie jeder Entwickler

Nehmen wir mal als Beispiel eine Norm aus der Halbleiterbranche: SEMI-E10. Sie definiert Maschinenzustände (Up/Downtime, productive, engineering, etc.). Um diese zu implementieren, müssen die Zustände erfasst werden. Und dazu müssen die Einrichter, Inbetriebnehmer, Operatoren und die Werkstatt nach bestimmten Schemata arbeiten. Der Riesenvorteil an SEMI-E10 und den Folgenormen ist, das alle Kennzahlen definiert und reichlich diskutiert wurden, man bekommt also sofort ein Werkzeug, um die Produktivität der Fertigung, aber auch die Güte der Werkstatt zu beurteilen und an entscheidenden Punkten zu verbessern. Das ist alles schon fix und fertig in der Schublade der ERP/BDE-Software.

Man täte also gut daran, die SEMI-Norm zu übernehmen und seinen Betrieb entsprechend anzupassen. Nun ist SEMI im Produktionsprozess nicht verbreitet, aber hier gibt es andere Vorgaben, die man tunlichst übernehmen sollte.

In einer ERP/BDE steckt einfach 10000x mehr Erfahrung als in einem einzelnen Betrieb. Sollte man sich das nicht zu Nutze machen?

Individuell kann man in seiner Freizeit sein, finde ich. Im professionellen Umfeld sollte man *effektiv* sein. Scheiß was auf den Maßanzug.