Der Abschluss dauert länger als vor der Einführung
Fast immer ein Architektur- und Prozessbefund, kein Systemfehler — Kontenlogik, Abstimmungsprozess und Verantwortlichkeiten.
Dynamics 365 Business Central: unsere primäre Microsoft-ERP-Praxis.
Business Central ist das Microsoft-ERP, das wir aktiv beraten, architekturieren, einführen, migrieren, optimieren und langfristig betreuen. Es ist für Mid-Market-Organisationen gebaut, die einen sauberen, skalierbaren Kern wollen — und für die Finance nicht der Bereich ist, der am Ende noch irgendwie abgebildet wird.
Der Anspruch
„Ein Business-Central-Projekt ist gelungen, wenn der erste Quartalsabschluss danach langweilig ist. Alles andere ist Nacharbeit, die man schon im Design hätte vermeiden können.“
Microsoft Business Unit · Tech IQ 365 GmbH
Überblick
Wofür Business Central gebaut ist — und wofür nicht.
Business Central ist ein vollständiges Mid-Market-ERP: Finanzbuchhaltung, Einkauf, Verkauf, Bestand, Projekte, leichte Fertigung und Service auf einem Datenmodell, mit einem kontrollierten Erweiterungsmodell über AL und geprüfte ISV-Apps. Es ist bewusst kein Enterprise-Stack — und genau das ist im Mid-Market ein Vorteil, kein Mangel.
Die Frage „passt Business Central“ ist selten mit ja oder nein zu beantworten. Nützlicher ist die Frage, welche Architekturentscheidungen Ihre Gesellschafts-, Prozess- und Finanzstruktur erzwingt — und welche davon in einem Standard-Rollout untergehen. Diese Entscheidungen fallen bei jedem ERP an; sichtbar werden sie meist erst im ersten Abschluss.
Wo die Plattform ihre Stärken ausspielt
- 01
Mid-Market-Struktur
Ein bis rund zwanzig Gesellschaften, überschaubare Länderzahl, klare Konzernberichtslinie.
- 02
Produkt, Handel und Distribution
Bestand, Beschaffung, Multi-Channel-Vertrieb und belastbare Kostendisziplin auf einem Modell.
- 03
Services und Projektgeschäft
Projektstruktur, Ressourcen, Leistungsabgrenzung und Profitabilität ohne Nebensystem.
- 04
Leichte Fertigung
Stücklisten, Arbeitspläne und Produktionsaufträge in einer Tiefe, die zum Mid-Market passt.
- 05
Multi-Entity und Intercompany
Mehrere Gesellschaften mit gemeinsamer Berichtslogik — sauber entworfen statt monatlich in Excel gemappt.
- 06
Integrationsfähigkeit
CRM, Commerce, Payroll, Payments, EDI und Banking über definierte Schnittstellen statt gewachsene Punktlösungen.
Wo die natürliche Grenze liegt
Die Grenze verläuft nicht bei einer Umsatzzahl. Sie verläuft bei Fertigungs- und Planungstiefe, Lagerkomplexität im Volumen, sehr breiter statutarischer Vielfalt über viele Länder — und bei der Frage, wie viel Erweiterung ein Standardkern noch trägt, bevor jedes Update zum Projekt wird. Wenn Ihre Struktur diese Grenze überschreitet, sagen wir das. Wir bewerten dann gruppenweit, welche Architektur trägt: NetSuite, SAP, eine andere Plattform der Gruppe — oder Dynamics 365 F&O dort, wo es sachlich passt. Für eine vollständige F&O-Neueinführung sind wir derzeit bewusst nicht der Umsetzungspartner; unsere F&O-Motion ist auf bestehende Umgebungen ausgerichtet.
Einführung
Eine Einführung, die den Sprung von Design zu Go-live übersteht.
Die meisten Business-Central-Projekte scheitern nicht an der Software. Sie scheitern an Entscheidungen, die niemand getroffen hat: Kontenrahmen kopiert statt entworfen, Dimensionen gewachsen statt geplant, Intercompany als Prozess statt als Architektur, Erweiterungen ohne Regelwerk. Wir drehen die Reihenfolge um.
- 01
Discovery & Zielbild
Operating-Modell, Berichtsanforderungen, Gesellschaftsstruktur, kritische Prozessketten und die Frage, was am Ende messbar besser sein muss.
- 02
Finance-Architektur
Kontenrahmen, Dimensionen, Mandanten- und Konsolidierungslogik, Steuern, Intercompany und das Reporting-Modell — als Entwurf, bevor konfiguriert wird.
- 03
Lösungsarchitektur & Prozessdesign
End-to-End-Prozesse, Rollen und Berechtigungen, Erweiterungsregeln über AL und ISV, Integrationskarte und Datenmodell.
- 04
Konfiguration & Erweiterung
Aufbau im Standard, wo der Standard trägt. Erweiterung nur dort, wo eine Entscheidung sie rechtfertigt — dokumentiert, nicht gewachsen.
- 05
Datenmigration
Stammdaten, offene Posten, Bestände, Historie und Öffnungsbilanzen — mit Abstimmung gegen das Altsystem, nicht mit Hoffnung.
- 06
Test, UAT & Cutover
Testabdeckung entlang der kritischen Prozessketten, ein belastbarer Cutover-Plan und ein definierter Abbruchpunkt.
- 07
Hypercare & Übergabe
Betreuung über den ersten Abschluss hinaus, dokumentierte Übergabe und ein Support-Modell, das ab Tag eins steht.
Wir erfinden dafür keine Methodennamen. Es ist die 4-Schritte-Methode der Business Unit — Architect, Design, Deliver, Operate — angewandt auf Business Central.
Der übliche erste Schritt ist das Fit- und Architektur-Assessment — Ergebnis sofort, ohne Kontaktdaten. Wenn Sie schon weiter sind, sprechen wir direkt über Zielmodell, Migrationsweg oder Support.
Business-Central-Fit prüfen
Finance-Architektur
Der Teil, den die meisten Angebote überspringen.
Der Kontenrahmen ist die einzige Entscheidung im Projekt, die Sie im laufenden Betrieb kaum noch korrigieren können, ohne die Vergleichbarkeit Ihrer Zahlen zu verlieren. Deshalb ist er bei uns Entwurfsarbeit — nicht der Import aus dem Altsystem.
- 01
Kontenrahmen & Dimensionen
Ein gruppenweit lesbares Kontenmodell mit Dimensionen, die eine Frage beantworten — statt einer Dimension je Sonderfall.
- 02
Multi-Entity & Konsolidierung
Mandantenlogik, Konsolidierungspfade und ein Mapping, das nicht jeden Monat in einer Tabelle nachgebaut wird.
- 03
Intercompany
IC als Architektur mit definierten Gegenbuchungen und klaren Führungsregeln — nicht als zweiseitige manuelle Erfassung.
- 04
Steuern & statutarische Anforderungen
Umsatzsteuerlogik, lokale Anforderungen und die Frage, was auf Gesellschafts- und was auf Konzernebene gehört.
- 05
Abschluss & Periodensteuerung
Abschlusskalender, Abgrenzungen, Rückstellungen und Abstimmungslogik als Prozess, nicht als Heldentat.
- 06
Reporting-Fundament
Berichtsstruktur direkt auf dem ERP-Datenmodell. Power BI ist danach Auswertung — kein Ersatz für ein tragfähiges Fundament.
- 07
Banking & Zahlungsverkehr
Zahlläufe, Kontoauszugsverarbeitung und Abstimmung als definierter Prozess mit Vier-Augen-Logik.
- 08
Anlagenbuchhaltung
Anlagenklassen, Abschreibungsregeln und parallele Bewertung, wo HGB und IFRS auseinanderlaufen.
Migration
NAV → Business Central: die Entscheidung vor dem Projekt.
Die Frage ist nicht, ob migriert wird. Die Frage ist, ob Sie Ihr NAV mitnehmen oder Ihr Zielbild aufbauen. Beides ist legitim — aber es sind zwei verschiedene Projekte, mit verschiedenen Kosten, verschiedener Dauer und sehr verschiedenen Ergebnissen im dritten Jahr.
Lift-and-Shift
Das bestehende Modell wird technisch nach Business Central gehoben. Schneller, günstiger, geringeres Änderungsrisiko — und Sie nehmen die gewachsenen Entscheidungen mit, auch die, die niemand mehr begründen kann.
Redesign
Der Kern wird neu entworfen: Kontenrahmen, Dimensionen, Prozesse, Erweiterungslandschaft. Aufwendiger und mit echtem Change-Anteil — aber danach ist das System das, was Sie heute bauen würden.
Was in beiden Fällen zu entscheiden ist
- 01
Welche der bestehenden Anpassungen sind heute noch fachlich begründet — und welche sind Gewohnheit?
- 02
Was davon deckt der Business-Central-Standard inzwischen ab?
- 03
Welche Historie wird migriert, welche archiviert — und wie wird sie prüfungsfest zugänglich gehalten?
- 04
Wie werden Öffnungsbilanzen abgestimmt, und gegen welche Quelle?
- 05
Welche Schnittstellen bleiben, welche entfallen, welche werden neu gebaut?
- 06
Welche Berechtigungs- und Rollenlogik wird übernommen — und welche war ohnehin nie sauber?
Wir beantworten diese Fragen vor dem Migrationsprojekt, nicht darin. Das Business-Central-Fit- und Architektur-Assessment ist dafür der übliche Einstieg — es funktioniert für NAV-Bestandskunden genauso wie für eine Neuauswahl.
Bestehendes Business Central
Wenn Business Central läuft — aber nicht so, wie es sollte.
Ein erheblicher Teil unserer Business-Central-Arbeit beginnt nicht bei null. Das System steht, die Einführung ist Jahre her, und die Symptome sind bekannt: Der Abschluss dauert zu lange, dem Reporting traut niemand ganz, die Erweiterungslandschaft ist gewachsen, und der Support beantwortet Tickets, statt Ursachen zu beheben.
Das Reporting wird nebenher in Excel nachgebaut
Ein Zeichen, dass die Berichtsstruktur nicht auf dem ERP-Datenmodell sitzt, sondern daneben rekonstruiert wird.
Jedes Update wird zum Projekt
Erweiterungen ohne Regelwerk. Die Frage ist, was in den Standard zurück kann und was ein bewusstes Add-on bleibt.
Berechtigungen sind historisch gewachsen
Rollen, die niemand mehr erklären kann, sind ein Prüfungs- und ein Betriebsrisiko zugleich.
Der Partner rotiert Berater
Fachliche Kontinuität ist bei einem ERP kein Komfort, sondern eine Voraussetzung für belastbare Entscheidungen.
Senior Support & Application Management
Wir bauen die Business-Central-Praxis ausdrücklich nicht als Implementierungsgeschäft, das sich nach Go-live verabschiedet. Der laufende Betrieb ist ein eigenes Leistungsversprechen: Incidents, Release- und Update-Begleitung, Change-Management und funktionale Weiterentwicklung — mit senioren Ansprechpartnern, die Ihre Architektur kennen, statt mit einer Warteschlange.
Zu Reaktionszeiten, Servicegraden und Paketzuschnitten machen wir an dieser Stelle bewusst keine Angaben, solange sie nicht freigegeben sind. Was wir zusagen können, klären wir im Gespräch — nicht auf einer Website.
Lizenz & Subscription
Microsoft Cloud Solution Provider — als Teil des Lebenszyklus.
JPS-iQ ist Microsoft Cloud Solution Provider. Das heißt: Wenn Sie es wollen, können wir Lizenzierung und Subscription für Business Central und die zugehörigen Microsoft-Dienste im selben Lebenszyklus abbilden, in dem wir auch die Architektur und die Einführung verantworten — statt sie über einen dritten Vertragspartner zu führen.
Was das ausdrücklich nicht heißt: dass wir ein Lizenzhaus sind. Unser Geschäft ist Architektur, Finance und Umsetzung. Sie können Ihre Lizenzen genauso gut anderswo beziehen — an unserer Arbeit ändert das nichts, und wir machen die Beratung nicht davon abhängig.
Microsoft Cloud Solution Provider und Microsoft Solutions Partner sind zwei verschiedene Dinge. Der CSP-Status betrifft den kommerziellen Lebenszyklus. Aussagen zu Partner-Designationen, Kompetenz- oder Spezialisierungsbereichen machen wir nur dort, wo sie einzeln belegt und nachprüfbar sind.
- 01
Ein Vertragsweg weniger
Lizenz, Einführung und Betreuung müssen nicht über drei Parteien laufen, wenn Sie das nicht wollen.
- 02
Sizing entlang der Architektur
Welche Lizenztypen Sie brauchen, ergibt sich aus dem Rollen- und Prozessmodell — nicht aus einer Standardannahme.
- 03
Sauberer Wechsel
Ein bestehender CSP-Vertrag lässt sich zum Erneuerungszeitpunkt geordnet überführen. Wir sagen Ihnen, wann das sinnvoll ist und wann nicht.
- 04
Getrennt vom Beratungsbudget
Lizenzkosten und Beratungsleistung bleiben getrennt ausgewiesen. Kein Quersubventionsmodell.
Belege
Was für diese Praxis belegbar ist.
Wir zeigen hier keine Business-Central-Kundenzahlen, weil wir keine freigegebene, zuordenbare Business-Central-Referenz haben. Ergebnisse aus Mandaten auf anderen Plattformen als Business-Central-Beleg auszugeben, wäre der einfachere Weg — und der falsche.
Microsoft Cloud Solution Provider
Lizenz- und Subscription-Fähigkeit im Kundenlebenszyklus — verifizierter Status.
Finance-Architektur als Entwurfsarbeit
Kontenrahmen, Multibook, Multi-Entity, Intercompany und Dual-GAAP werden entworfen, bevor konfiguriert wird.
Senior geführt
Architektur- und Finance-Ownership durchgängig auf seniorer Ebene — von der Zielarchitektur bis über den ersten Abschluss hinaus.
Plattform-neutral
Acht Business Units in einer Gruppe. Die Empfehlung gegen Business Central ist strukturell möglich.
Deutsche Finance-Tiefe
HGB und IFRS parallel, statutarische Anforderungen, Umsatzsteuer und Konsolidierung als Kernkompetenz.
Fachliche Substanz öffentlich
Unsere Business-Central- und Finance-Architektur-Positionen stehen als Fachartikel offen nachlesbar.
Sobald eine Business-Central-Referenz freigegeben ist — Kunde, Ausgangslage, Ergebnis und Zeitraum, auch anonymisiert — steht sie an genau dieser Stelle.
Guter Fit
Passt das zu Ihrer Situation?
Guter Fit
- Sie stehen vor einer ERP-Entscheidung oder einer NAV-Migration und wollen die Finance-Anforderungen nicht erst am Ende einbringen.
- Ihre Struktur ist Mid-Market: mehrere Gesellschaften, überschaubare Länderzahl, klare Konzernberichtslinie.
- Sie wollen einen Standardkern mit bewusster Erweiterung — kein System, das sich mit jedem Update neu beweisen muss.
- Sie betreiben Business Central bereits und suchen einen senioreren Partner für Optimierung und laufenden Support.
- Sie erwarten eine ehrliche Antwort, auch wenn sie gegen Business Central ausfällt.
Weniger guter Fit
- Sie suchen eine reine Lizenzquelle ohne Beratungsanteil — dafür sind wir das falsche Haus.
- Sie wollen eine Standard-Einführung in einer einzelnen Gesellschaft ohne Finance-Tiefe — dafür gibt es günstigere Partner, und das sagen wir auch.
- Ihre Fertigungs-, Planungs- oder Lagerkomplexität liegt erkennbar über dem, was ein Mid-Market-Kern trägt.
- Sie brauchen eine vollständige Dynamics-365-F&O-Neueinführung — die bieten wir derzeit bewusst nicht an.
- Die Entscheidung ist bereits gefallen und es geht nur noch um den günstigsten Umsetzer.
Häufige Fragen
Was vor dem ersten Gespräch meistens gefragt wird.
Wie lange dauert eine Business-Central-Einführung?
Das hängt an Gesellschaftsstruktur, Prozesskomplexität, Migrationslast und Integrationsumfang. Eine einzelne Gesellschaft mit sauberen Stammdaten und wenigen Schnittstellen ist etwas ganz anderes als eine Gruppe mit Intercompany, mehreren Ländern und einem gewachsenen NAV im Rücken. Wir nennen eine Dauer erst, wenn das Zielbild steht — vorher wäre es geraten.
Was kostet das?
Aus demselben Grund gilt hier dasselbe. Der übliche Einstieg ist das Fit- und Architektur-Assessment: Es zeigt, welche Architekturentscheidungen Ihre Struktur erzwingt. Auf dieser Basis lässt sich ein Scope beziffern, der auch im dritten Monat noch stimmt.
Übernehmen Sie auch Projekte, die ein anderer Partner begonnen hat?
Ja. Wir steigen in laufende Business-Central-Projekte ein und übernehmen bestehende Umgebungen. In beiden Fällen beginnen wir mit einer nüchternen Bestandsaufnahme statt mit einem Neustart-Vorschlag — ein Neustart ist die teuerste aller Optionen und selten die richtige.
Wie haltet ihr Erweiterungen im Griff?
Über ein Regelwerk statt über Einzelfallentscheidungen: Was im Standard abbildbar ist, bleibt im Standard. Erweiterungen laufen über AL oder geprüfte ISV-Apps, sind begründet und dokumentiert, und jede Erweiterung hat einen benannten fachlichen Eigentümer. Das ist der Unterschied zwischen einem System, das man aktualisieren kann, und einem, das man fürchtet.
Wie verhält sich Business Central zu JPS FinanceOS?
Business Central ist das System of Record — es verbucht die Transaktion. JPS FinanceOS ist unser eigenes, ERP-neutrales Produkt und setzt als Control- und Action-Layer darüber an, wenn die Finanzorganisation trotz sauberem ERP über Excel, Bankportale und E-Mail läuft. FinanceOS ist kein Business-Central-Add-on, und Business Central ist keine Voraussetzung für FinanceOS. Der Business-Central-Pfad in FinanceOS steht auf der Roadmap und ist heute nicht verfügbar.
Und wenn Business Central am Ende nicht passt?
Dann sagen wir das und zeigen die Alternativen — NetSuite, SAP oder eine andere Plattform der Gruppe, gegebenenfalls über unseren plattform-neutralen Einstiegspunkt OPCON. Das ist kein Marketingsatz: Die Alternativen existieren als Schwester-Business-Units, wir müssen Ihnen Microsoft nicht verkaufen.
Kontakt · Business Central
Business Central evaluieren, einführen, migrieren oder besser betreiben?
Der übliche erste Schritt ist das Fit- und Architektur-Assessment — Ergebnis sofort, ohne Kontaktdaten. Wenn Sie schon weiter sind, sprechen wir direkt über Zielmodell, Migrationsweg oder Support.