|
ERP Software mit Delphi
Hallo zusammen,
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. Nun stehe ich vor dem Problem einen guten "Grundstock" zu bilden und habe einige Fragen: 1. Delphi oder PHP mit Framework? 2. SQL oder NoSQL? 3. Etwaige Tipps? Ein paar Gedankenanstöße und Erfahrungen wären super ;) Danke Euch! |
AW: ERP Software mit Delphi
ERP ist ja nun sehr weit gefasst. Und es gibt für jedes Segment was. Muss dann evtl. noch angepasst werden.
|
AW: ERP Software mit Delphi
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. |
AW: ERP Software mit Delphi
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...
|
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
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:
|
AW: ERP Software mit Delphi
Zitat:
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 |
AW: ERP Software mit Delphi
Zitat:
wir wollen gerade den umgekehrten Weg gehen, eine Delphieigenentwicklung durch ein Standardsystem zu ersetzen, da die Delphilösung an ihre Grenzen stößt. Zitat:
Zitat:
Zitat:
Gruß relocate |
AW: ERP Software mit Delphi
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. |
AW: ERP Software mit Delphi
Zitat:
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. |
AW: ERP Software mit Delphi
|
AW: ERP Software mit Delphi
Zitat:
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 |
AW: ERP Software mit Delphi
Zitat:
nehmen, ich hatte ca. 10 Jahre damit zu tun. AvERP ist ein Funktionsmonster mit teilweise sehr restriktiven Strukturen und nur sehr restriktivem Zugriff auf den Quellcode, ich weiß wovon ich rede ... |
AW: ERP Software mit Delphi
Und wenn man SAP nimmt, dann kann man nicht einmal das Wort "Equipment" umbenennen lassen ohne weitere Kosten, um dem Wort "Equipment" einen eindeutigen Namen zuzuordnen, der in der Realität existiert.:lol:
|
AW: ERP Software mit Delphi
Bei SAP wird ja auch nicht die Software auf das Unternehmen angepasst, sondern das Unternehmen auf die Software ;-)
|
AW: ERP Software mit Delphi
Hi zusammen.
Die Meinungen über SAP scheinen hier ja nicht allzu gut zu sein. Für den hier geschilderten Fall ist SAP sicher aus Kostengründen keine Option. Viele Grüße, Tim |
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
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. |
AW: ERP Software mit Delphi
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. |
AW: ERP Software mit Delphi
Zitat:
Jedoch Deine später genannten Anforderungen: Zitat:
Aus meiner Erfahrung bei einigen Firmen nur ein paar Beispiel: 1. Navision super angepasst (von den Vertriebspartner) auf Kundenbedürfnisse. 2. Ein vom Discounter gekauftes AS 400 System, das auf die Erfordernisse auf ein Spezialitätenhändler umgeschrieben wurde. 3. Ein Super System mit Baal. 4. etc. Aber, das ganze was ich da gesehen habe, selber programmieren :pale: :shock: Und, wie Furtbichler geschrieben hat: Es ist wirklich so, manchmal halten sich die Firmen in Ihren Arbeitsabläufen für die größten... und dann sieht man sowas, wie das eine Kreditoren-Rechnung sage und schreibe 5x in die Hand genommen wird.... In einer gescheiten Software und mit gescheiten Arbeitsabläufen fasse ich die genau 1x an... Gruß Smutje |
AW: ERP Software mit Delphi
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" |
AW: ERP Software mit Delphi
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 |
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
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 ;) |
AW: ERP Software mit Delphi
Zitat:
Zitat:
|
AW: ERP Software mit Delphi
[QUOTE=Bernhard Geyer;1224081]
Zitat:
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.8-) |
AW: ERP Software mit Delphi
Zitat:
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. |
AW: ERP Software mit Delphi
Zitat:
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. |
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
[QUOTE=Hansa;1224088]
Zitat:
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 |
AW: ERP Software mit Delphi
Ausgangspunkt war ein Beitrag, den wir entfernt haben, weil wir ihn übereinstimmend als "Werbung" klassifiziert haben. Die Entscheidung, keine ungefragte Werbung in diesem Forum zuzulassen, habe ich vor vielen Jahren getroffen und die Moderatoren helfen mir, diese Entscheidung in der Praxis umzusetzen. Selbstverständlich gibt es eine große Bandbreite an Werbung: Ein Teil davon nervt, ein anderer Teil davon mag ein willkommener Hinweis auf einen Dienstleister sein. Diese Klassifizierung ist höchst subjektiv und ich behaupte, dass wir mit der Vorgabe, jegliche Werbung im Vorfeld mit mir abzustimmen, grundsätzlich gut gefahren sind.
Ich betreibe dieses Forum auf eigene Rechnung - werbefrei. Und wenn kommerzielle Unternehmen der Meinung sind, hier auf Kundensuche gehen zu wollen, dann ist das Ansinnen dem Grundsatz nach legitim, nur sollen sie das dann vorher mit mir abstimmen. Selbstredend steht es Euch frei, uns bzw. mich für diese Entscheidung zu kritisieren. Aber ich möchte betonen, dass diese gelöschten Beiträge nichts mit Euch zutun haben, sofern Ihr nicht gerade der Werbetreibende selbst seid. In einer Diskussion dann einen weiteren Diskussionszweig über den gelöschten Beitrag zu eröffnen, ist jedoch kein optimaler Weg, das Thema zu erörtern. Im Zweifelsfall erstellt bitte einen neuen Beitrag in der Rubrik "Fragen und Antworten zum Forum" und wir können uns dann dort austauschen. |
AW: ERP Software mit Delphi
[QUOTE=p80286;1224110]
Zitat:
Was für den einen der blanke Horror ist für den anderen Normalität. Ich habe z.B. auch einige Kunden, für die gehören doppelte Artikel-Nummern zur Normalität. Beispielsweise in der Bekleidungsbranche ist das normal und üblich, dass eine Artikelnummer (Bekleidung, Schuhe...) mehrfach vorkommt. Da ist die Größe dann lediglich eine zusätzliche Eigenschaft. Andere wiederum (in derselben Branche) ergänzen die Artikelnummer als Zusatz mit der Größe und stellen so die Eindeutigkeit her. |
AW: ERP Software mit Delphi
Zitat:
Alleine die unterschiedlichen Forderungen zwischen Serienfertigern und Einzelfertigern, Baugruppen oder einstufiger Fertigung, usw. werden gerne unterschätzt. Natürlich kann man auch in Excel Texte schreiben, aber Word ist dafür doch komfortabler, ebenso lässt sich in Word rechnen, in Excel aber besser ... Der ERP Begriff vereint hier im Allgemeinen Systeme, die so gar nicht gleichwertig sind, daher ist die geforderte Betrachtung der Branche schon mal sehr wichtig, um hier potentielle Probleme diskutieren zu können. Es gibt de facto keine Standard Lösung für alles und die wird es auch nie geben, daher ist sicherlich auch noch in 50 Jahren ein Markt für individuelle Software, warum also nicht schon jetzt den Schritt wagen. Viele Unternehmen in Deutschland lassen sich eigene Maschinen anfertigen nach eigenen Vorstellungen und sind damit im Weltmarkt sehr erfolgreich, obwohl es alles mögliche auch von der Stange gibt. Warum sollte das bei Software anders sein .... |
AW: ERP Software mit Delphi
Wenn man sich oft ändernde Abläuf hat würde ich eine Service Orientierte Architektur empfehlen. Derartige Systeme werden oft für J2E oder auch angeblich in C# entwickelt.
Es geht sicher alles auch in Delphi aber die Produktion eines derartigen Systems wird hier meines Wissens nach nicht wirklich unterstützt. Nach "Lehrbuch" bildet man zuerst seine Geschäftsprozesse in einem Modell ab. Es gibt Software die anhand dieses Modells Simulationen durchführen kann um Flaschenhälse schon im Vorfeld zu erkennen und evtl. schon vor der Entwicklung der Software die Geschäftsprozesse umzustellen. Traditionell verwendet man dafür EEPK Diagramme. Besser für die Entwicklung der Software ist aber ein BPEL-kompatibles BPMN Diagramm. BPEL kann direkt als Programm ungesetzt werden. Das spart viel Arbeit und macht das umstellen von Geschäftprozessen leichter für die IT Abteilung. Gibt es BPEL support für Delphi? |
AW: ERP Software mit Delphi
Das Problem an der Vorgehensweise nach Lehrbuch ist das du dafür auf der Gegenseite Leute brauchst, die dir als Ansprechpartner
1. fachkompetent mit dem Prozesswissen zur Seite stehen 2. auch Lust haben an dem Projekt mitzuarbeiten 3. auch die Zeit von der Geschäftsleitung bekommen, das neben Ihres üblichen Aufgaben zu leisten Ich ware einige Jahre in einem Projekt 2-3 Tage pro Woche tätig als externer Softwarearchitekt in einer 1500 Mann Firma, die mit meiner Hilfe eine sehr aufwändige Software für Auftrags-, Kunden und Produktverwaltung auf Basis Delphi/AS400/Firebird realisiert haben. Bei denen lief das nahezu vorbildlich, die im Projekt beteiligten 4-6 festangestellten Mitarbeiter hatten kein (oder sehr wenig) sonstiges Tagesgeschäft zu erledigen, da muss man nicht wochenlang Meetings planen, sondern schliesst die Tür und los gehts. Das ganze System basierte auf der Idee "Datenbankmodell wird durch Quelltextgenerator zu Delphi Quellcode" und die Details werden mit Hilfe der autoamtisch erzeugten Klassen von Hand umgesetzt (kennen sicherlich einige noch von meinen OOP Sessions auf der Ekon). Das wichtigste war aber, das die wirklichen Fortschritte erst mit der Benutzung der realen Software durch Vorschläge aus den Fachabteilungen kamen. Ein Mitarbeiter war nur dafür verantwortlich, die Fachabteilungen zu besuchen und mit denen die Anforderungen zu besprechen, um das hier und da zu hinterfragen, meiste aber um dem Datenbankdesigner ein Modell entwerfen zu lassen, welches schon mal generell für die Speicherung der besprochenen Daten geeignet ist. Das Modell hat sich teilweise x-fach am Tag geändert, aber durch den Quelltextgenerator hatten wir innerhalb weniger Minuten eine an das Datenmodell angepasste Softwareversion, die auch real einsetzbar war, mit denen dann die Fachabteilung oft noch am selben Tag die Lücken erkannte, auf die der DB Designer wieder reagieren konnte. Wenn du das versuchst, theoretisch durchzuspielen, dann wird das aus meiner Sicht niemals erfolgreich sein, weil sich niemand in die Diagramme eindenken kann (oder will), die dann durch Programmierer in Code übersetzt werden, der erst nach Wochen für den Endanwender benutzbar ist. Meistens hat die Fachabteilung dann schon wieder vergessen, was man überhaupt damals gesagt hat und redet sich dann raus: "Das war aber ganz anders gemeint ...". Ich hatte auch schon einen Projektauftrag, den ich durch gute Kontakte zur Geschäftsführung bekam, wo aber der IT Leiter scheinbar gar kein Bock auf das gesamte von der Firmenleitung initiierte Projekt hatte und die zusammengestellte Truppe von Programmierern sich wochenlang mit banalen Reports beschäftigten. Da hab ich denen nach ca. 4 Wochen noch viel Glück für die Zukunft gewünscht, aber ohne mich (trotz guter Bezahlung hat das extrem frustiert). Eine Modellierung kostet viel Zeit und setzt ein sehr kompetentes prozesserfahrenes und auf dieses Thema konzentriertes Team voraus. Ich kenne keinen Mittelständler, der es sich leisten kann, mal eben mehrere Wochen seine besten Mitarbeiter vom Tagesgeschäft abzuziehen, um bunte Bilder zu malen. Blöderweise ist das bei Enterprise Kunden mit zehntausenden Mitarbeitern nicht wirklich anderes, weil da versucht wird, Kompetenz und Prozesserfahrung durch Ausbildung zu ersetzen. Das funktioniert aber nicht. Wa sich da schon als Projektleiter kennengelernt habe spottet jeder Beschreibung. So ist nun mal die Realität. Je mehr Abkürzungen für irgendwelche Verfahren dabei ins Spiel kommen, um so eher bin ich geneigt, mich von solchen Projekten fernzuhalten. Das man aus einem Diagramm irgendwann die komplette Lösung einfach so generieren kann, das versuchen verschiedene Hersteller schon seit Jahrzehnten erfolglos zu verkaufen. Wenn das so wäre, dann würde kein Mensch mehr so programmierern, wie es sicherlich die meisten hier im Forum bevorzugen. Dummerweise sind es halt oft Entscheidungsträger, die sich von dem Kram blenden lassen und dafür schon mal ordentlich Geld aus dem Beutel holen, statt in die Aus- und Weiterbildung des eigenen Teams zu investieren. Ich hatte vor 2 Wochen auf einer Messe zufällig ein Gespräch mit einem mir bislang unbekannten Softwarehersteller, bei dem einer seiner Delphi Programmierer sagte, das deren letzte Programmiererweiterbildung noch im letzten Jahrtausend war. Alles andere hat man sich angelesen und später dann im Internet zusammengesucht. Von denen habe ich aber auch noch nie jemand hier in der Delphi Praxis gesehen, was ich im deutschsprachigen Gebiet für Delphi Programmierer aber schon recht erschreckend finde (Dafür noch mal Danke an Daniel W. und alle anderen, die dieses Forum zu dem gemacht haben, was es heute ist: Meiner Meinung DIE deutschsprachige Referenz zur Pascal Programmiersprache). An deren Produkt habe ich auch schon ohne den Delphi Quellcode je gesehen zu haben, schnell erkannt, was deren Probleme sind und welche Komponenten denen den Umsteig auf neuere Techniken und Versionen nahezu unmöglich macht. Aber zurück zum Thema: Eine komplette ERP Software für die eigene Firma selbst zu entwickeln ist ein sportliches Ziel, insbesondere wenn man bei 0 anfängt, weil sehr viele Prozesse (Basisstammdaten/Angebot/Rechnung/Lieferschein/Gutschrift/...) sich selten wirklich von anderen System unterscheiden. Ein Bedienkonzept zu entwickeln, was auch mäßig begabte Anwender nicht überfordert ist dann der nächste Punkt. Wenn du wie in Averp 20 seitige Pagecontrols mit teilweise noch 3-5 seitigen eigebundenen Pagecontrols und insgesamt ca. 500 Felder im Artikelstamm deinem Anwender zumuten willst, dann unterschätze neben dem Programmieraufwand nicht den Schulungsaufwand und damit auch gleich die Akzeptanz der Anwender. Wenn du aber die langfristige Unterstützung (Geld und Geduld!) durch die Geschäftsführung hast, dann ist so ein Projekt ausgesprochen interessant, weil man dabei auch selbst sehr viel mehr über betriebliche Abläufe und insbesondere auch über Userinterface Design lernst als aus irgendwelchen Büchern. Wenn deine Anwender dein Design und deine Gedankengänge für zu kompliziert halten, kannst du deren Einwände entweder ignorieren oder als Ansporn für Verbesserungen nehmen. Das setzt aber eine flexible Architektur voraus, sonst wirst du dich schon heute in eine Abhängigkeit begeben, die dir die Flexibilität in der Zukunft verbaut und du dich abhängig machst von Komponenten Herstellern, die es vielleicht in 5 Jahren gar nicht mehr gibt *1. Einige Fragen bleiben aber ggf weiterhin im Raum stehen: Welche Branche ist das, Wie groß ist die Firma, Wie groß ist das Team usw. usw. *1 Frag einfach mal IBObjects Anwender, die zu 90 % gerne alles rausschmeißen würden, das aber aufgrund sehr tiefer Verankerung in der gesamten Applikation selten machen. |
AW: ERP Software mit Delphi
Abhängigkeiten geht man als Unternehmen immer ein. Hier IBObjects als Negativbeispiel darzustellen sei dir freigestellt, aber das gleiche könnte dir genau so mit IBDAC, FIBPlus und andere passieren. Wer gibt dir Sicherheit, dass FireDAC in 5 Jahren noch existiert? Oder Firebird? Oder Delphi? Du hast ja Delphi öffentlich mit einer Newsmeldung im Februar 2013 auf der IBExpert Webseite den Rücken gekehrt.
Du hast vollkommen Recht, dass man mit einer flexibleren Architektur die Abhängigkeit zu Drittherstellerkomponenten im Data-Access-layer Geschäft minimieren kann, aber leider machen das die wenigsten bzw. können sie es vielleicht auch nicht, da viele Delphi-Entwickler aus der Learning-by-Doing Klicksi-Klicksi Ecke kommen,wozu Delphi mit dessen RAD Ursprung auch verleitet. Ich weiss nicht,ob man da IBObjects so an den Pranger stellen sollte. :-D Auf AvERP will ich nicht eingehen, da ich es nicht einsetze und nicht kenne, aber da du ein eigenes ERP am Start hast ... |
AW: ERP Software mit Delphi
Zitat:
Das soll jetzt aber nicht heißen, dass die IBO total mies wären :-) Grüße |
AW: ERP Software mit Delphi
Das mit den visuellen Komponenten stimmt natürlich, aber man hat in IBO auch den Weg über die TDataset kompatiblen Zugriffskomponenten gehen können.
Ersetzen im visuellen kann immer schwierig sein. Versuch mal DevExpress, Raize, TMS etc. mit anderen zu ersetzen, falls notwendig. :-D |
AW: ERP Software mit Delphi
Zitat:
Zitat:
|
AW: ERP Software mit Delphi
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 09:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz
