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.