ERP Software mit Delphi

[jobo]

Ich plädiere auch für kaufen und erweitern. Ein guter Teil der genannten Anforderungen sind Standard.
Bei der Auswahl wäre drauf zu achten, dass das System nicht in erster Linie alle erfüllt, sondern gut erweiterbar ist.
Die Aufgabe ist dann "nur noch", fehlende Bereiche anzugliedern. Wahrscheinlich immer noch genug Arbeit.

Was das "nicht passen" angeht: Ich denke da gibt es eine Menge Befindlichkeiten. Wie geht dieser "Entscheidungsprozess" eigentlich von statten (siehe Beitrag von Bernhard Geyer)? Welche Abteilung ändert freiwillig Ihren Arbeitsablauf, wenn sowieso alles nach dem Motto wünsch Dir was läuft?
Am Ende ist die blöde Software wirklich so smart, dass der eigene Arbeitsplatz in Gefahr ist?
Ok, es gibt auch echte Fehlentscheidungen bei diesen Fragen. Die Firmen müssen dann noch zusätzliche Sachbearbeiter einstellen, aber die Neu-Einführung muss eben ein Erfolg sein.
Und das Thema, wenn wir schon was neues kriegen, dann bitte gleich auch noch 3 extra Wünsche.
Wenn Zahltag ist, sieht es dann ganz schnell wieder anders aus. "ja, brauchen wir eigentlich nicht unbedingt"

[rweinzierl]

Hallo

Wie arbeit die Firma denn bisher. Jede Firma hat irgend ein Vorgängersystem ( die genannten doppelten Artikelnummern) werden ja wohl kaum in Karteikarten verwaltet werden.

Die nächste Frage ist das Budget. Was kann / will die Firma investieren. Wie groß ist der Leidensdruck wirklich etwas zu ändern wenn selbst doppelte Artnr nicht angefasst werden dürfen.

Ich bin ein Delphi Fan aber das größte Plus von Delphi RAD ist gleichzeitig auch das größte Problem. Mit Delphi kann man super gut Entwickeln und sehr schnell Ergebnisse präsentieren, passt das Ergebniss so dem Auftraggeber nicht dann kann mans ebenso schnell wieder ändern. Hat sich der Auftragsgeber erst einmal daran gewöhnt das er im Nachgang entscheiden kann was er will, und das er alles bekommt (z.B. doppelte Artnr) dann wird es echt schwierig ein wirklich sauber strukturiertes Programm zu entwickeln.

Ein ERP System von Grund auf zu entwickeln ist keine leichte Übung, je nach Firmenstruktur ist die Gefahr in einer Sackgasse zu landen sehr hoch, einfach weil man immer versucht ist die aktuelle Anforderung zu Erfüllen. Ein solches System soll / muss ja über Jahre/Jahrzehnte anpassbar und wartbar bleiben, darum hat ja SAP bei großen Firmen fast ein Monopol, obwohl es aus Delphianer Sicht unglaublich schwerfällig / komplex / unanpassbar zu sein scheint.

mfg

Reinhold

[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

[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.

[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.

[IBExpert]

Zitat von Furtbichler:

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

Das führt aber erfahrungsgemäß zu den berühmten Funktionsmonstern, die am Bedarf gerne mal komplett vorbeigehen ....

Ich kenne einige Unternehmen, die seit Jahrzehnten in vielen Bereichen sehr erfolgreich arbeiten und die haben
teilweise etablierte Prozesse, bei denen jeder ERP Softwareanbieter heulend rausläuft, weil der die aufgrund der
Restriktionen der eigenen Softwarelösung nicht umsetzbar sind.

Und genau dieses kleine aber feine Marktsegment bedienen wir gerne mit unserer Lösung, die nach jahrelanger
Beschäftigung mit einem angeblich anpassbaren Funktionsmonster (=AvERP) entstanden ist.

[Bernhard Geyer]

Zitat von IBExpert:

Und genau dieses kleine aber feine Marktsegment bedienen wir gerne mit unserer Lösung, die nach jahrelanger
Beschäftigung mit einem angeblich anpassbaren Funktionsmonster (=AvERP) entstanden ist.

Ihr habt aber auch schon ein (halb)fertiges Produkt und müsste nicht jedesmal eine 100% neuimplementierung anbieten. Und für den Fragesteller wäre es eine Neuimplementierung.

[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