Individuelle ERP-Entwicklung in Berlin: Kosten, Dauer und was Sie von einem Partner verlangen sollten
Ein Berliner Fertigungsunternehmen mit 180 Mitarbeitern plant die Produktion in drei Excel-Arbeitsmappen, fakturiert aus einer 2009 installierten Version eines eingestellten deutschen ERP-Systems und zählt den Lagerbestand auf Papier. Zweimal im Jahr schlägt jemand SAP Business One oder Microsoft Dynamics vor. Zweimal im Jahr kommt das Lizenzangebot, der Finanzchef verstummt, und die Tabellen überleben eine weitere Saison.
Diese Pattsituation steht hinter den meisten Anfragen zu individueller ERP-Entwicklung in Berlin. Es ist selten der Wunsch nach maßgeschneiderter Software an sich. Es ist die Erkenntnis, dass ein Standardprodukt so viel Konfiguration, so viele Workarounds und so viel Lizenzkosten pro Arbeitsplatz erfordern würde, dass es aufhört, die günstige Option zu sein.
Dieser Leitfaden richtet sich an die Person, die die Entscheidung intern verteidigen muss: was ein individuelles ERP kostet, wie lange es dauert, welche Teile man bauen statt kaufen sollte, woran diese Projekte scheitern und was in den Vertrag gehört, bevor jemand Code schreibt.
Was individuelle ERP-Entwicklung tatsächlich bringt
Drei Dinge, und meist ist nur eines davon ausschlaggebend.
Passung zum Workflow. Standard-ERP kodiert einen Referenzprozess. Entweder Sie übernehmen ihn, oder Sie bezahlen Berater dafür, das Produkt in Richtung Ihrer Prozesse zu verbiegen. Für Standardabläufe ist das in Ordnung. Für die zwei oder drei Prozesse, wegen derer Kunden sich für Sie entscheiden, ist das Erzwingen eines generischen Modells ein direkter Treffer auf das, worin Sie gut sind.
Kein Lizenz-Lock-in. Lizenzierung pro Arbeitsplatz und pro Modul skaliert mit der Mitarbeiterzahl, nicht mit dem Nutzen. Verdoppeln Sie Ihr Lagerpersonal, verdoppeln Sie eine Kostenposition, die nichts damit zu tun hat, dass die Software besser wird. Individualentwicklung verlagert die Ausgaben von einer dauerhaften Lizenz zu einem einmaligen Aufbau plus einem Wartungsbudget, das Sie selbst steuern.
Datenhoheit. Ihnen gehören das Schema, die Datenbank und der Exportpfad. Das zählt für Ihre DSGVO-Aufstellung, EU-Hosting und den Tag, an dem Sie den Anbieter wechseln.
Das ehrliche Gegengewicht: Wenn Ihre Prozesse wirklich Standard sind, kaufen Sie Standard. Ein Händler mit schlichtem Ein- und Verkauf ohne ungewöhnliche Preislogik sollte ein konfiguriertes Fertigprodukt betreiben und das gesparte Budget anderswo einsetzen. Individuelle ERP-Entwicklung verdient ihre Kosten, wenn die Prozessdifferenzierung real ist, wenn Lizenzkosten bereits wehtun oder wenn die Integration ohnehin der schwierige Teil ist.
Die vier Module, die deutsche Mittelständler am häufigsten individuell bauen
Niemand sollte ein komplettes ERP selbst bauen. Das realistische Muster ist ein individueller Kern um die differenzierenden Prozesse, integriert mit zugekauften Werkzeugen für alles andere. Vier Module tauchen immer wieder auf.
Lager- und Bestandsverwaltung. Bestände an mehreren Standorten, Chargen- und Seriennummernverfolgung, Kommissionierlogik auf Lagerplatzebene und Reservierungsregeln. Hier greifen Standardprodukte am häufigsten zu kurz, denn in Kommissionierstrategie und Bestandsreservierung steckt die operative Raffinesse.
Auftragsverwaltung. Vom Angebot über den Auftrag bis zur Auslieferung, mit kundenspezifischen Preisen, Rahmenverträgen, Teillieferungen und Retouren. Individuelle Preislogik ist der häufigste Grund, warum eine Standard-ERP-Konfiguration zu einem sechsstelligen Beratungsprojekt wird.
Fakturierung und Finanzintegration. Das Modul mit dem geringsten Spielraum für Kreativität und dem größten Spielraum für Fehler. In Deutschland heißt das: ein sauberer DATEV-Exportpfad für Ihren Steuerberater, strukturierte E-Rechnungen im XRechnung- oder ZUGFeRD-Format nach der Norm EN 16931 und GoBD-konforme Aufzeichnungen: unveränderbare Buchungen, ein lückenloser Prüfpfad und eine schriftliche Verfahrensdokumentation. Aufbewahrungsfristen und E-Rechnungs-Pflichttermine haben sich mehr als einmal verschoben, klären Sie den aktuellen Stand daher mit Ihrem Steuerberater und nicht mit einem Blogbeitrag.
HR- und Ressourcenplanung. Schichtplanung, Kapazitätszuteilung, Skill-Matrizen und Zeiterfassung, die in die Lohnabrechnung einfließt. Oft das beste Preis-Leistungs-Verhältnis, denn die Alternative ist ein Manager, der eine Planungstabelle pflegt, die sonst niemand lesen kann.
Ein vernünftiges erstes Release deckt ein oder zwei dieser Module ab und geht live, bevor die anderen begonnen werden. Alles Breitere ist ein als Projekt getarnter Komplettumbau.
Was individuelle ERP-Entwicklung in Berlin kostet
Die folgenden Spannen sind das, was wir mittelständischen deutschen Kunden zu Senior-EU-Engineering-Sätzen von 2026 anbieten. Sie stammen aus unseren eigenen Projekten, nicht aus Umfragedaten, und die Streuung innerhalb jeder Spanne ist aus gutem Grund breit.
| Umfang | Typische Spanne (EUR) | Was enthalten ist |
|---|---|---|
| Discovery und Prozessaufnahme | 12.000 bis 25.000 | Prozessinterviews, Datenaudit, Integrationsinventar, Architekturvorschlag, kalkuliertes Backlog |
| Ein Kernmodul, produktionsreif | 40.000 bis 90.000 | Umsetzung, Tests, Deployment-Pipeline, eine Integration, Schulungsmaterial |
| Erstes Release, zwei bis drei integrierte Module | 120.000 bis 280.000 | Die übliche Form eines ersten Go-live |
| Vollständige Suite mit vier Modulen und Legacy-Datenmigration | 300.000 bis 600.000 und mehr | Mehrjahresprogramm, phasenweise Lieferung |
| Jährliche Betriebskosten nach Go-live | 15 bis 25 Prozent der Baukosten | Hosting, Wartung, Support, kleine Erweiterungen |
Vier Variablen bewegen ein Projekt innerhalb dieser Spannen.
Anzahl der Integrationen. Jedes externe System, mit dem Ihr ERP sprechen muss (Webshop, DATEV, Versanddienstleister, Maschinensteuerungen, bestehendes CRM), erhöht die Kosten, und Altsysteme ohne dokumentierte API erhöhen sie deutlich stärker. Bei Integrationen sind Schätzungen am wenigsten verlässlich, deshalb gehören sie in einen Time-and-Materials-Rahmen.
Qualität der Datenmigration. Zwanzig Jahre inkonsistenter Artikelnummern und doppelter Kundendatensätze können mehr Bereinigungsaufwand kosten, als das Modul kostet, das sie verarbeitet. Auditieren Sie die Daten während der Discovery, nicht nach Baubeginn.
Regulatorische Fläche. Finanz- und Personaldaten heben die Compliance-Messlatte und damit den Test- und Dokumentationsaufwand.
Entscheidungslatenz. Die günstigsten ERP-Projekte haben einen entscheidungsbefugten Ansprechpartner, der innerhalb eines Tages antwortet. Die teuren leiten jede Frage durch einen monatlichen Lenkungsausschuss.
Unser Beitrag zu Kosten, Zeitplan und ROI individueller Softwareentwicklung behandelt dieselben Abwägungen außerhalb des ERP-Kontexts.
Zeitpläne: Was jede Phase wirklich dauert
| Phase | Dauer | Ergebnis |
|---|---|---|
| Discovery und Prozessaufnahme | 3 bis 6 Wochen | Prozessmodelle, Datenaudit, Architektur, kalkuliertes Backlog |
| Kernaufbau, erstes Modul | 3 bis 5 Monate | Funktionierendes Modul im Staging, automatisierte Tests, CI-Pipeline |
| Integrationen | 6 bis 12 Wochen, weitgehend parallel | Live-Anbindungen an DATEV, Webshop, Versanddienstleister, Altsysteme |
| Datenmigration und Testläufe | 4 bis 8 Wochen | Wiederholbares Migrationsskript, mindestens zwei vollständige Generalproben |
| Rollout und Parallelbetrieb | 4 bis 12 Wochen | Altes und neues System parallel, Abstimmungsberichte |
| Stabilisierung | 4 bis 8 Wochen | Abbau von Defekten, Performance-Tuning, Übergabedokumentation |
Ein erstes nutzbares Release landet typischerweise fünf bis acht Monate nach dem Kickoff. Ein fest verwurzeltes Legacy-ERP komplett zu ersetzen dauert zwölf bis achtzehn Monate und sollte in Scheiben geliefert werden. Das Strangler-Fig-Pattern ist das richtige Denkmodell: Leiten Sie einen Prozess nach dem anderen auf das neue System um, lassen Sie das alte maßgeblich, bis sich das neue bewiesen hat, und planen Sie niemals eine Wochenend-Umstellung in einem Schritt für ein System, das Geld berührt.
Woran ERP-Projekte scheitern
Vier Fehlermodi verursachen den größten Teil der Schäden, und alle sind früh sichtbar.
Scope Creep durch Nachbarschaft. Jemand stellt fest, dass es doch sinnvoll wäre, während das Team die Auftragsverwaltung neu baut, auch gleich das Kundenportal, die CRM-Synchronisation und das Reporting zu reparieren. Jede Ergänzung ist für sich genommen vernünftig. Zusammen schieben sie den Go-live über den Punkt hinaus, an dem die Geduld des Sponsors endet. Die Verteidigung ist vertraglich: feste Modulgrenzen und ein separat budgetierter Änderungstopf, dessen Verwendung eine explizite Entscheidung erfordert.
Change Management als Schulung missverstanden. Der Werksleiter, der durch drei frühere Rollouts eine Schattentabelle gepflegt hat, wird auch durch diesen eine pflegen, wenn niemand die Ursache angeht. ERP-Projekte scheitern weit häufiger an der Akzeptanz als am Code. Benennen Sie pro Modul einen fachlichen Prozessverantwortlichen, beteiligen Sie ihn ab der Discovery und schulen Sie vor dem Go-live statt währenddessen.
Dünne Testabdeckung auf den Geldpfaden. Ein ERP-Bug ist ein Finanzbug: ein falscher Steuersatz, eine doppelte Buchung, eine Reservierung, die Bestand freigibt, den sie hätte halten müssen. Bestehen Sie auf hoher automatisierter Abdeckung für Preise, Steuern, Lagerbewegungen und Buchungen, plus Regressionstests gegen einen goldenen Datensatz historischer Transaktionen mit bekannten korrekten Ergebnissen.
Unterschätzte Datenmigration. Das am häufigsten zu spät entdeckte Terminrisiko. Behandeln Sie die Migration als eigenen Arbeitsstrang mit eigenem Budget und proben Sie sie mindestens zweimal Ende-zu-Ende mit Daten in Produktionsgröße, bevor Sie sich auf einen Go-live-Termin festlegen.
Was Sie von einem Entwicklungspartner verlangen sollten
Schwache Verträge sind der Weg, auf dem gute technische Teams trotzdem schlechte Ergebnisse liefern. Auf diese Bedingungen zu bestehen ist angemessen, und ein Partner, der sich dagegen sträubt, sagt Ihnen damit etwas Nützliches.
Discovery als separater, kündbarer Vertrag. Bezahlen Sie die Discovery für sich. Am Ende sollten Sie Prozessmodelle, ein Datenaudit, einen Architekturvorschlag und ein kalkuliertes Backlog in Händen halten, das Ihnen vollständig gehört und das Sie einem anderen Anbieter übergeben könnten. Zeigt die Discovery, dass ein Fertigprodukt die bessere Antwort ist, wird ein Partner, den es sich zu beauftragen lohnt, das auch sagen.
Quellcode- und Repository-Zugriff ab Tag eins. Ihr Unternehmen besitzt das Repository. Commits landen dort kontinuierlich, nicht als Liefer-Zip am Ende. Das kostet den Anbieter nichts, wenn seine Arbeit solide ist.
Festpreis pro Modul, Time and Materials für Integrationen. Festpreis funktioniert, wo der Umfang bestimmbar ist. Integrationen mit undokumentierten Altsystemen sind es nicht, und ein Anbieter, der sie zum Festpreis anbietet, hat entweder kräftig aufgeschlagen oder wird mit Ihnen über jeden Change Request streiten.
Zahlungsmeilensteine mit Abnahmekriterien. Jeder Meilenstein braucht schriftliche, testbare Kriterien, die vor Arbeitsbeginn vereinbart sind. "Modul fertig" ist kein Abnahmekriterium. "Kommissionierliste wird für die zwölf dokumentierten Lagerszenarien korrekt erzeugt, verifiziert gegen den goldenen Datensatz" ist eines.
Ein definiertes Support-SLA mit Schweregraden. Reaktionszeit und Lösungsziel sind unterschiedliche Zusagen, und Anbieter nennen manchmal die erste, während sie die zweite nur andeuten.
| Schweregrad | Beispiel | Reaktion | Lösungsziel |
|---|---|---|---|
| S1 kritisch | Fakturierung unmöglich, Versand unmöglich, Datenverlust | 1 Geschäftsstunde | 4 Geschäftsstunden oder dokumentierter Workaround |
| S2 schwer | Kernprozess beeinträchtigt, kein Workaround | 4 Geschäftsstunden | 2 Geschäftstage |
| S3 gering | Kosmetischer Defekt mit geringer Auswirkung | 1 Geschäftstag | Nächstes geplantes Release |
Vereinbaren Sie, ob die Uhr in Geschäftszeiten oder rund um die Uhr läuft, und bepreisen Sie den Unterschied vor Ihrer ersten Hochsaison statt währenddessen.
Exit- und Übergaberegelungen. Ein dokumentiertes Runbook, Infrastructure as Code, ein Onboarding-Leitfaden für ein neues Team und eine definierte Übergangsphase. Sie sollten gehen können. Diese Freiheit ist es, die die Beziehung gesund hält, solange Sie bleiben.
Unser Beitrag zu Umfang, SLAs und Nachweisen bei individuellen Software-Dienstleistungen geht tiefer auf diese Klauseln ein, und was deutsche Einkäufer von einem Softwareanbieter erwarten behandelt die Dokumentationserwartungen speziell im DACH-Markt.
Symfony, Laravel oder Java Spring für das Backend
ERP ist transaktional, langlebig und schwer an Geschäftsregeln. Das grenzt das Feld ein.
| Kriterium | Symfony (PHP) | Laravel (PHP) | Spring Boot (Java) |
|---|---|---|---|
| Eignung für komplexe Domänenlogik | Stark: Doctrine ORM, DDD-freundlich, explizite Service-Schicht | Mittel: Eloquents Active-Record-Muster stößt bei reichen Domänenmodellen an Grenzen | Stark: ausgereifte Enterprise-Muster, starke Typisierung |
| Langfristige Wartbarkeit | Hoch: strikter LTS-Rhythmus, konservative Deprecations | Mittel: schnellere Major-Versionen | Hoch: sehr stabil, lange Support-Fenster |
| Entwicklerverfügbarkeit in Berlin | Gut | Sehr gut | Gut, zu höheren Sätzen |
| Gesamtbetriebskosten | Niedriger | Niedriger | Höher: mehr Infrastruktur und teurere Entwickler |
| Ökosystem für ERP-Belange | Gut: API Platform, Messenger, Workflow-Komponente | Ausreichend | Exzellent für sehr große Unternehmen |
Für einen mittelständischen EU-Betrieb lautet unsere Empfehlung Symfony. Nicht weil PHP in Mode wäre, sondern weil Doctrine komplexe relationale Domänenmodelle gut abbildet, weil Symfonys Workflow- und Messenger-Komponenten sauber auf ERP-Zustandsmaschinen und asynchrone Buchungsqueues passen, weil der LTS-Rhythmus vorhersehbar genug ist, um fünf Jahre Wartung darauf zu planen, und weil der Berliner Arbeitsmarkt tief genug ist, dass Sie nicht an einen einzigen Anbieter gebunden sind.
Spring Boot ist die richtige Wahl bei wirklich großem Maßstab oder wo bereits ein Java-Plattformteam existiert. Laravel passt zu einfacheren operativen Werkzeugen, aber sein Active-Record-Muster arbeitet gegen Sie, sobald das Domänenmodell reich wird, was im ERP früh passiert. Unser Überblick über den Berliner Tech-Stack zeigt, was lokale Teams einsetzen.
Häufig gestellte Fragen
Wie viel kostet individuelle ERP-Entwicklung in Berlin? Rechnen Sie mit 12.000 bis 25.000 EUR für die Discovery, 40.000 bis 90.000 EUR pro produktionsreifem Modul und 120.000 bis 280.000 EUR für ein erstes Release mit zwei oder drei integrierten Modulen. Budgetieren Sie zusätzlich jährlich 15 bis 25 Prozent der Baukosten für Hosting, Support und Erweiterungen.
Wie lange dauert ein individuelles ERP-Projekt? Ein erstes nutzbares Release landet üblicherweise fünf bis acht Monate nach dem Kickoff. Ein vollständiger Legacy-Ersatz dauert zwölf bis achtzehn Monate und sollte phasenweise geliefert werden, nicht als einmalige Umstellung.
Ist ein individuelles ERP günstiger als SAP oder Microsoft Dynamics? Nicht zum Kaufzeitpunkt. Es wird über fünf Jahre günstiger, wenn die Lizenzkosten pro Arbeitsplatz erheblich sind, wenn ein Standardprodukt schwere Konfiguration braucht oder wenn die Integration ohnehin die Kosten dominiert. Vergleichen Sie die Gesamtbetriebskosten über fünf Jahre, nicht das Erstangebot.
Müssen wir jedes Modul selbst bauen? Nein. Bauen Sie die Module, die Ihre differenzierenden Prozesse tragen, integrieren Sie zugekaufte oder bestehende Werkzeuge für den Rest und halten Sie die Grenzen explizit.
Was bedeutet GoBD-Konformität für ein individuelles ERP? Buchungen, die nicht stillschweigend geändert werden können, ein nachvollziehbarer Prüfpfad, kontrollierter Zugriff, Aufbewahrung über die gesetzliche Frist und eine schriftliche Verfahrensdokumentation. Lassen Sie Ihren Steuerberater das Design prüfen, bevor das Finanzmodul ausgeliefert wird.
Womit Sie beginnen sollten
Der wertvollste nächste Schritt ist keine Anbieter-Demo. Es ist ein kurzes, bezahltes Discovery-Engagement, das Prozessmodelle, ein Datenqualitätsaudit, ein Integrationsinventar und ein kalkuliertes Backlog liefert, das Ihnen gehört, egal wer das System baut. Das verwandelt ein ERP-Gespräch von einem Vertrauensvorschuss in eine Entscheidung, die Sie vor einem Vorstand verteidigen können.
Wolf-Tech baut und modernisiert operative Software für mittelständische europäische Unternehmen. Unsere Engagements in individueller Softwareentwicklung, Legacy-Code-Optimierung und Tech-Stack-Strategie decken dieses Feld ab, einschließlich der unglamourösen Teile: Datenmigration, DATEV- und E-Rechnungs-Integration und die Testabdeckung, die ein Finanzmodul vertrauenswürdig hält.
Wenn Sie individuelles ERP gegen ein Standardprodukt abwägen und eine unabhängige Einschätzung wollen, welches Ihre Situation verlangt, schreiben Sie an hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Wir sagen Ihnen auch, wenn Kaufen die bessere Antwort ist.