ERP Software mit Delphi

[Daniel]

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.

[musicman56]

[QUOTE=p80286;1224110]

Zitat von Hansa:

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

Bevor es eine Diskussion über Sinn und Unsinn doppelter Artikelnummern gibt denke ich es wäre sehr hilfreich, wenn man zumindest die Branche bzw. den Einsatz-Bereich des ERP etwas detaillierter kennen würde!

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.

[IBExpert]

Zitat von musicman56:

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.

Was für die meisten Systeme viel gemeiner ist als doppelte Artikelnummer ist im Bereich der Einzelfertiger gar keine Artikelnummer, das ist im Bereich Metallbearbeitung eine nicht gerade seltene und wenn man die Prozesse kennt auch legitime Forderung, die viele Unternehmen davon abhält, Standardsoftware einzuführen, die nahezu immer Artikelnummer fordert. Ich hatte schon endlos Diskussionen mit Einzelfertigern, die den gefertigten Artikel nie wieder produzieren werden und auch nicht für jede Variante künstliche Nummern haben wollen, die dann bis in alle Ewigkeit den Artikelstamm vollmüllen.

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

[QuickAndDirty]

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?

[IBExpert]

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.

[tsteinmaurer]

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.

Auf AvERP will ich nicht eingehen, da ich es nicht einsetze und nicht kenne, aber da du ein eigenes ERP am Start hast ...

[Lemmy]

Zitat von tsteinmaurer:

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.

Nein: die IBObjects haben lange (in den RAD-Hochzeiten) davon profitiert neben den reinen DB-Zugriffskomponenten (Query,...) auch visuelle Komponenten mit anzubieten die einen großen Leistungsumfang haben, d.h. ohne viel Code eine große Oberflächenfunktionalität. D.h. eine Trennung GUI-Business-DB ist da schlicht nicht möglich, weil einfach alles im Formular passiert. Will man hier von IBO weg, heißt das im Grunde komplette Neuentwicklung.

Das soll jetzt aber nicht heißen, dass die IBO total mies wären

Grüße

[tsteinmaurer]

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.

[Lemmy]

Zitat von tsteinmaurer:

Das mit den visuellen Komponenten stimmt natürlich, aber man hat in IBO auch den Weg über die TDataset kompatiblen Zugriffskomponenten gehen können

LOL... hätte... sicherlich. Man hätte auch ein ORM einsetzen können. Oder wenigstens vernüftige Layer einführen können,....

Zitat von tsteinmaurer:

Ersetzen im visuellen kann immer schwierig sein. Versuch mal DevExpress, Raize, TMS etc. mit anderen zu ersetzen, falls notwendig.

seh ich anders - wenn man es "richtig" macht und Logik von Gui ändert, dann ist selbst das kein Thema. Aufwändig, aber machbar.

[tsteinmaurer]

Zitat:

seh ich anders - wenn man es "richtig" macht und Logik von Gui ändert, dann ist selbst das kein Thema. Aufwändig, aber machbar.

Dachte hier eher an das ersetzen vom z.b. DevExpress Grid mit etwas anderem. Da kannst du GUI von Logik schon getrennt haben.