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

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.

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.

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.

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

Um mal zum Anfang zurückzukommen :

Zitat von Dragon27:

innerhalb eines mittelständischen Betriebes soll ein ERP System entwickelt werden. Es soll erweiterbar und zukunftssicher sein. Leider passen aktuelle Marktlösungen nicht, da das Segment äußerst speziell ist...

Sofern "äußerst" und "speziell" nicht völlig übertrieben ist, dann bin ich sicher, ich baue das schneller und vernünftiger selber, als das von der Stange umzubauen. Letzeres läuft nämlich ziemlich nach diesem Prinzip :

http://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau

Um alles mögliche abzudecken, dann gehts auch kaum anders. Aber ist das gut ? Den AvERP Quelltext (nur die DB), habe ich mir mal angesehen, allerdings vor ca. 3 Jahren. Um da zu wissen, wozu was gebraucht wird (3-stellige Anzahl an Tabellen, SPs usw.), das würde Wochen, eher Monate dauern. In wesentlich kürzerer Zeit (Stunden /Tage) hätte ich (mit Sicherheit auch kleinere) DB selber aufgebaut, die auch zu 100% passen würde.

Hans Du scheinst das Prinzip hinter AvERP nicht verstanden zu haben. Die Datenbank ist ja nicht die Datenbank für das zu entwickelnde System, sondern die des darunterliegenden AvERP. Willst du dieses erweitern, kannst Du die Datenbank verändern ( bei gleichzeitiger Anpassung des Quellcodes) willst Du "nur" ein System damit entwickeln, solltest Du tunlichst die Finger von der DB lassen!

Zitat:

In wesentlich kürzerer Zeit (Stunden /Tage) hätte ich (mit Sicherheit auch kleinere) DB selber aufgebaut, die auch zu 100% passen würde.

Und dann? Wenn

Zitat:

Sofern "äußerst" und "speziell" nicht völlig übertrieben ist

dürfte das auch nicht so schnell gehen. Und selbst wenn die Datenbank aufgesetzt ist, hat man dann noch lange kein fertiges ERP System!

Wenn man Deinen Beitrag so liest könnte man daraus ableiten "15 -20 MJ = wenige Wochen Hansa"

Zitat von mkinzler:

Hans Du scheinst das Prinzip hinter AvERP nicht verstanden zu haben. Die Datenbank ist ja nicht die Datenbank für das zu entwickelnde System, sondern die des darunterliegenden AvERP. Willst du dieses erweitern, kannst Du die Datenbank verändern ( bei gleichzeitiger Anpassung des Quellcodes) willst Du "nur" ein System damit entwickeln, solltest Du tunlichst die Finger von der DB lassen!

Zitat:

In wesentlich kürzerer Zeit (Stunden /Tage) hätte ich (mit Sicherheit auch kleinere) DB selber aufgebaut, die auch zu 100% passen würde.

Und dann? Wenn

Zitat:

Sofern "äußerst" und "speziell" nicht völlig übertrieben ist

dürfte das auch nicht so schnell gehen. Und selbst wenn die Datenbank aufgesetzt ist, hat man dann noch lange kein fertiges ERP System!

Wenn man Deinen Beitrag so liest könnte man daraus ableiten "15 -20 MJ = wenige Wochen Hansa"

Denke ich genauso. Ein Ansatz: Wochen ist vielleicht für einen GUI-Prototypen oder die Aufnahme der Anforderungen oder Use-Cases zu schaffen aber für kein Produktives ERP-System.
Hier werden die Möglichkeiten/Notwendigkeiten selbst der minimalen absolut notwendigen Kernfeatures eines ERP vollkommen unterschätzt.

Zitat von Bbommel:

Ein Orthopäde und ein Mercedes-Händler passen aber in dieses Schema tatsächlich nicht rein.

Ein Enterprise-Resource-Planning-Tool würden beide Betriebe nicht kaufen. Eine WaWi käme hier eher in Betracht.

Zitat von Furtbichler:

Ein Enterprise-Resource-Planning-Tool würden beide Betriebe nicht kaufen. Eine WaWi käme hier eher in Betracht.

Moin Furtbichler,

eben habe ich versucht, den Unterschied zwischen ERP und WaWi zu ermitteln und bei Wikipedia gelesen, daß der Übergang zwischen Warenwirtschaftssystem und ERP-System nicht klar definiert sei: "Die Abgrenzung erfolgt in der Regel anhand des Funktionsumfanges. Sind z. B. Funktionen oder Module im Bereich Controlling und Materialwirtschaft integriert, spricht man eher von einem ERP, als von einem WWS." Nun steht aber am Anfang der Erklärung des WaWi-Begriffs, es sei "ein Modell zur Abbildung der Warenströme im Geschäftsprozess eines Unternehmens".

Worin besteht denn nun der Unterschied zwischen Materialwirtschaft und Warenwirtschaft? Denn wiederum bei Wikipedia werden Materialwirtschaft und Warenwirtschaft als Synonyme behandelt: "Die Materialwirtschaft oder Warenwirtschaft beschäftigt sich mit der Verwaltung sowie der zeitlichen, mengenmäßigen, qualitativen und eventuell auch räumlichen Planung und Steuerung der Materialbewegungen innerhalb eines Unternehmens und zwischen dem Unternehmen und seiner Umwelt. Sie koordiniert den Warenfluss zwischen Lieferanten, Kunden, Bedarfsträgern (zum Beispiel Produktion) und den Lagern. In produzierenden Unternehmen stellt sie die Versorgung der produzierenden Bereiche mit direkten Gütern wie Roh-, Hilfs- und Betriebsstoffen, Zulieferteilen und Halbfabrikaten sowie allgemein die Versorgung mit indirekten Gütern wie Büroartikel, Ersatzteile oder Serviceleistungen sicher."

Der Begriff Controlling, der ebenfalls zur Abgrenzung eines ERP zu einem WaWi verwendet wird, besagt laut Wikipedia doch auch nur, daß die Daten, die das ERP liefert, zur Kontrolle des Betriebs verwendet werden. Ist das denn bei einem WaWi anders? Oder betrifft Controlling nicht bereits das, was bei Wikipedia als Management-Informations-System (MIS) bezeichnet wird?

Meine eigentliche Frage lautet aber: Was bietet ein Enterprise Resource Planning-Systemen (ERP) mehr an Funktionen, das nicht durch ein Warenwirtschafts-System (WaWi) gedeckt ist?