ERP Software mit Delphi

[Bbommel]

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.

Ich schreibe nachher auch noch was zu deiner eigentlichen Frage, kann aber auch nicht widerstehen, zunächst noch darauf einzugehen: wir (also meine Firma) arbeiten im Bereich der Produktionsplanung und -optimierung. Dazu müssen wir unsere Software eng an vorhandene ERP-Systeme angliedern und dadurch habe ich durchaus ein bisschen Einblick in diese Bereiche. Viele Unternehmen halten ihre Produktion zunächst für etwas sehr Besonderes - die Produkte, die sie herstellen, sind es oftmals ja auch, aber die Produktionsplanung kann fast immer doch auf bestimmte Grundlagen zurückgeführt werden (natürlich mit individuellen "Parametern"). Fast alle mir bekannten ERP-Systeme lassen sich dann für den Kunden auch noch so anpassen oder erweitern, dass auch Spezialfälle mit abgedeckt werden können.

In meiner Arbeit habe ich vor allem ein System kennengelernt, dass ich im Bereich der Produktionsplanung für sehr gut aufgestellt halte. Ich will jetzt hier aber nicht zu viel Werbung machen - falls du aber doch noch etwas recherchieren willst, kannst du dich gerne per PN melden, dann schreibe ich dir dazu noch was.

Zu deiner eigentlichen Frage:
Wenn nicht unbedingt eine Web-Anwendung gefordert ist, dann würde ich Delphi durchaus eine Chance für die Entwicklung geben. Ich habe gerade bei der Arbeit an diversen Nicht-Delphi-Projekten wieder gemerkt, wie gut dieses RAD-Prinzip doch ist und wie schnell man damit auch zu sauberen Lösungen kommt. Als Datenbank würde sich in einem Microsoft-Ökosystem vielleicht SQL Server von Microsoft anbieten.

Bis denn
Bommel

[Hansa]

Zitat von Bbommel:

Fast alle mir bekannten ERP-Systeme lassen sich dann für den Kunden auch noch so anpassen oder erweitern, dass auch Spezialfälle mit abgedeckt werden können.

Das wage ich zu bezweifeln. Wie soll man einen Mercedes-Händler, einen Aldi und einen Orthopäden unter einen Hut bringen ? Meine Erfahrungswerte sagen da : geht nicht ! Da ist schon noch Handarbeit gefordert und das ist auch gut so.

[Furtbichler]

Die Betriebe sollten sich auch ein wenig an die Software anpassen. Viele Prozesse, von denen die Betriebe meinen, das es so und nicht anders ginge, lassen sich sehr gut optimieren. Da eignet sich ein System, das nach 'Schema F' arbeitet ganz gut.

Natürlich lässt sich das alles anpassen, aber ein wenig flexibel sollte man schon sein. Schließlich will man die Prozesse optimieren.

[Bernhard Geyer]

Bevor man jetzt versucht ein eigenes ERP zu entwickeln würde ich ein Firmeninternes Projekt aufsetzen (wie auch bei Entwicklung eines neuen Produktes).
In diesem Projekt definiert man erstmal die Anforderungen, durchläuft 2-3 Auswahlverfahren um die Liste der möglichen existierenden ERP's auf Eignung zu testen.
In der Endrunde kann man dann die 2-3 Top-Systeme im Rahmen einer Teststellungen genauer untersuchen.

Die hier investierten Gelder/Zeiten sind besser aufgehoben als hier eine eigene Lösung zu suchen.

[Bbommel]

Zitat von Hansa:

Zitat von Bbommel:

Fast alle mir bekannten ERP-Systeme lassen sich dann für den Kunden auch noch so anpassen oder erweitern, dass auch Spezialfälle mit abgedeckt werden können.

Das wage ich zu bezweifeln. Wie soll man einen Mercedes-Händler, einen Aldi und einen Orthopäden unter einen Hut bringen ? Meine Erfahrungswerte sagen da : geht nicht ! Da ist schon noch Handarbeit gefordert und das ist auch gut so.

Sorry, wenn ich erst relativ spät noch hierauf antworte - ich war ein paar Tage unterwegs, fühle mich aber etwas missverstanden.

Mir ging es um produzierende klein- bis mittelständische Unternehmen und da ist tatsächlich sehr, sehr vieles vergleichbar. Ein Orthopäde und ein Mercedes-Händler passen aber in dieses Schema tatsächlich nicht rein.

Und natürlich ist bei der Einführung immer Handarbeit gefordert, da sind wir uns doch völlig einig. Aber mit den Kern-Funktionen eines guten ERP-Systems kann man schon mal viel abbilden (und eben mehr als die meisten denken, weil sie sich für sehr individuell halten - darum ging es mir) und der Rest lässt sich dann gut durch Skripte o.ä. anpassen.

Bis denn
Bommel

[Bernhard Geyer]

Zitat von Dragon27:

... wie doppelte Artikelnummern (die aber auch nicht abgeändert werden dürfen) vorhanden sind.

Denke ich nicht das das ein großes Problem. Die Definiton "doppelte Artikelnummern" musst du genauer erklären. Ich denke das ihr keine doppelten Artikelnummern habt sondern das diese Nummern sich schon unterscheiden und es nur nötig ist ein vernünftige Stammdatendefintion zu machen. Oder ruft Kunde 1 an und sagt ich brauche Art-Nr 4711 und ihre schickt ihn dann 50 verschiedene Materialien von denen er 49 zurückschickt?

Zitat von Dragon27:

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.

Denke ich nicht. Genau dieser Fall (verschiedenste Schnittstellen) ist etwas mit dem ERP-System tagtäglich zu tun haben. Die SAP's/Oracle/MS-ERPs dieser Welt laufen nicht auf weiter Flur allein. Und wenn es eine Schnittstelle nicht von Haus aus gibt. APIs haben diese Systeme allemal.

[Hansa]

[QUOTE=Bernhard Geyer;1224081]

Zitat von Dragon27:

... wie doppelte Artikelnummern (die aber auch nicht abgeändert werden dürfen) vorhanden sind.

...

Na ja, "doppelte" Artikelnummern ist ja nun nicht wirklich soo wichtig. Allerdings : eigene Art.-Nr. und EAN-Nr. sind fast Standard. Ich gehe noch darüber hinaus und sage : auch Kunden/Lieferanten-eigene Nummern können verwendet werden. Wenn ich mir aber mal überlege, solche Sachen prophylaktisch in ein Allerwelts-System einzubauen, dann wird mir schlecht.

[p80286]

[QUOTE=Hansa;1224088]

Zitat von Bernhard Geyer:

Zitat von Dragon27:

... wie doppelte Artikelnummern (die aber auch nicht abgeändert werden dürfen) vorhanden sind.

...

Na ja, "doppelte" Artikelnummern ist ja nun nicht wirklich soo wichtig.

Ach ja?
Ich habe mit Artikeln recht wenig am Hut, bei mir sind es Akten. Wenn jeder Dorfhäuptling meint seine Arbeitsweise sei die beste, ist das ineffizent und teuer. Spätestens wenn in einen Zentralsystem die Verwechslungen stattfinden ist das Geschrei groß, wobei natürlich immer die anderen schuld sind. Und um da aufzuräumen und den Blick etwas aufzuweiten, braucht es jemanden mit cojones. Und das ist im allgemeinen nicht der ITler.

Gruß
K-H

[Patito]

Zitat von Dragon27:

Hallo zusammen,

innerhalb eines mittelständischen Betriebes soll ein ERP System entwickelt werden.

Nunja, Marktlösungen sind eben nie so passend wie man es gern hätte.

Speziallösungen haben da viele Vorteile - aber man braucht eben auch Mut und die entsprechende Kompetenz.
Delphi war für solche Anwendungen eigentlich immer perfekt. Es hat einfach die richtige Mischung
- eine geringe Einstiegshöhe und man kann sehr viel daraus machen.

Programmiersprache:
C++ ist für viele Programmierer zu gefährlich (die Leute schießen sich die ganze Zeit selbst in den Fuss).
PHP - Programmiert vermutlich niemand kompetentes auch freiwillig
C# ist ein guter VisualBasic Ersatz, mit Delphi kriegt man aber leichter eine qualitativ bessere Anwendungen hin (Benutzbarkeit...).

Außerdem ist der Compiler von Pascal sehr schnell, daher kann man alles wesentlich schneller testen - was den Entwicklungszyklus entsprechend verkürzt.
Mit Delphi kann man schon weitermachen, wärend die C++-Entwickler noch Kaffee trinken und auf den Linker warten.

Leider ist das Ökosystem von Delphi (seit Microsoft damals die Chef-Entwickler abgeworben hat) nicht mehr so ganz in Ordnung.
Man sollte sich da die Hintertür Richtung Free Pascal offen halten, oder gleich auf Free Pascal setzen (es gibt dann weniger
Komponenten zu kaufen, was entsprechend mehr Aufwand bedeutet).

Datenbank: ERP ist eine klassische SQL-Angelegenheit. Man kann mit vielen Datenbanken glücklich werden, ich würde aber die
Datenbank nehmen, die die besten Administrations-Tools hat.

Insgesamt würde ich sagen, dass sich für kompetente Leute Eigenentwicklungen lohnen.
Der Erfolg von einem Projekt hängt für mich daran, ob es Benutzer gibt, die wissen was sie wollen.

Ich denke man sollte im Mittelstand darauf aus sein konkrete Probleme zu lösen. Eine monatelange Vorplanung
ohne konkrete Software-Prototypen gehört eher ins Reich der planwirtschaftliche Bürokratie - und passt
mehr zu Großkonzernen, Monopolisten oder durchregulierten Behörden.

[Alter Mann]

Hallo,

schau dir mal avERP an.