ERP Software mit Delphi

[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

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