NextLevel Maturity System (NMS‑Finance)

1. Warum ein neues Reifegradmodell?

Unternehmen investieren Milliarden in ERP‑Projekte und Reporting‑Tools – und verfehlen dennoch die Wirkung. Häufig werden alte Prozesse in neue Systeme kopiert, ohne Regeln, Ownership oder Evidenz aufzubauen. „Digitalisierung“ bleibt dann Form, nicht Funktion.

NMS‑Finance löst dieses Dilemma: Es koppelt Technologie konsequent an Entscheidungsnützlichkeit, physikalische Evidenz und systemische Prüfbarkeit. Der Leitgedanke: „Was können wir sonst noch damit machen?“ – Technologie wird ergebnisoffen genutzt, um neue Wertpotentiale zu erschließen, anstatt nur bestehende Effizienzlücken zu schließen. Das Modell transformiert Finance von einer retrospektiven Dokumentationsstelle zu einem programmierbaren Business-Betriebssystem.

2. Reifegrad‑Leiter (L0–L5) – Die Evolution zur autonomen Steuerung

Level 0 – Vor‑Digital: „Systeme als Schreibmaschine“

• Mindset: Digital kopiert analog. Technologie dient der reinen Ablage.

• Daten & Prozesse: Manuelle Tätigkeiten, Schatten‑Excel, unklare Definitionen, kein Data Ownership.

• OEE 5.0 & CO₂: Nicht vorhanden; keine verlässliche Erfassung.

• Accounting & Audit: Abschlüsse > 10 Tage; JEs unstrukturiert. Audit erfolgt durch mühsames Suchen in Papierbelegen/Files.

• Zielbild: Erstorientierung, Stammdaten‑Hygiene, Einführung einer Prozesslandkarte.

Level 1 – Digital Basics: „Gap‑Schliesser“

• Mindset: Technologie behebt akute Pain Points (Reparatur-Modus).

• Daten & Prozesse: Einzeltools (OCR, DMS, einfache RPA), geringe Integration.

• OEE 5.0 & CO₂: Klassische OEE (Maschinenfokus), grobe CO₂‑Schätzwerte (Scope 1/2).

• Accounting & Audit: Mehr Checklisten; manuelle Reconciliations; Closing 8–10 Tage.

• Zielbild: Von reaktiv zu systematisch; erste definierte KPIs und Rollen (RACI).

Level 2 – Technologie‑getrieben: „ERP neu, Prozesse alt“

• Mindset: Veränderungsscheu; alte Logiken werden digital konserviert („ERP-Kopie“).

• Daten & Prozesse: Neues ERP vorhanden, aber Geschäftslogik bleibt starr; BI verschönert nur alte Berichte.

• OEE 5.0 & CO₂: Erste Scope‑3‑Vokabeln ohne methodische Tiefe.

• Accounting & Audit: Reproduzierbare Abläufe, aber hohe Fehlerquote in Stammdaten; Korrekturen erfolgen „unsichtbar“ im System.

• Zielbild: Process Renewal statt Kopie; Beginn der datenbasierten Governance.

Level 3 – Integration: „Potenzial-Hebel“

• Mindset: Technologie wird zum aktiven Hebel für Wertschöpfung.

• Daten & Prozesse: Einheitliches Datenmodell (ERP/DWH/BI). Einführung von Standardized Data Contract Tags (SDC): Datenströme tragen Metadaten zu Herkunft und Qualität.

• OEE 5.0 & CO₂: OEE inkl. Mensch/Energie/Sicherheit; CO₂‑Wirkungskette fließt in Deckungsbeiträge ein.

• Customholder: NPS × CLV × Cash × CO₂ fest im KPI-Set verankert.

• Accounting & Audit: Closing < 5 Tage. Systematische JE-Vorschläge; Versionierung von Vorlagen sorgt für erste „Audit-Spuren“.

• Zielbild: Prognosefähigkeit und kontrollierte Governance.

Level 4 – Automatisiert & vorausschauend

• Mindset: Technologie erschafft neue Fähigkeiten (New Capabilities).

• Daten & Prozesse: Ausnahmebasierte Abläufe; ML-Forecasts mit aktiver Model-Governance (MLOps).

• OEE 5.0 & CO₂: Investitionen werden gegen CO₂-Schattenpreise gerechnet; CO₂-Deckungsbeiträge je Produktlinie sind Standard.

• Accounting & Audit: Regelbasierte JEs (IFRS 15/16). Einführung der Blockchain-Schnittstelle: Kritische Buchungen erzeugen unveränderliche Proof-of-Events. „Leichen im Keller“ werden durch Anomaly-Detection im Keim erstickt.

• Zielbild: Continuous Forecasting und präventive Kontrollmechanismen.

Level 5 – Autonomous & Strategic: „NextLevel“

• Mindset: Das Unternehmen als Echtzeit-Datenfluss; „Accounting is Data-Science“.

• Daten & Prozesse: Continuous Accounting & Continuous Assurance. Vollautomatisierte Datenverträge zwischen Systemen.

• OEE 5.0 & CO₂: Operative OEE-Maßnahmen zeigen live Cash- und CO₂-Wirkung.

• Accounting in Bausteinen (Tokenized): * Vertrags- und Risikokomponenten sind als granulare Tokens auf der Blockchain modelliert.

  • Goodwill-Zerlegung: Goodwill wird in Werttreiber-Bausteine (NRR, Tech-Stack, Skills) zerlegt und über Smart Contracts autonom überwacht.

  • Self-Healing Audit: Korrekturen erfolgen über das Inverse-Token-Protokoll (kein Löschen, nur lückenlose Korrekturhistorie).

• Zielbild: Strategische Echtzeit-Steuerung; maximale Assurance bei minimalem Prüfaufwand.

Das IT-Backbone: Die technologische Evolution des NMS‑Finance

Um die Reifegrade L0 bis L5 zu erreichen, muss die IT-Infrastruktur konsequent vom „Datengrab“ zum „Daten-Highway“ transformiert werden. Jedes Level erfordert eine spezifische Architektur-Schicht:

Level 0 & 1 – Die Silo-Architektur (Legacy)

• Struktur: Isolierte On-Premise-Lösungen, lokale Fileserver und unzählige „Schatten-Excels“.

• Datenfluss: Manueller Import/Export via CSV; fehleranfällige „Turnschuh-Schnittstellen“.

• Sicherheit: Keine zentrale Identity-Governance; hohes Risiko für Dateninkonsistenz.

• Audit-Status: Manuelle Belegsuche; keine digitale Traceability.

Level 2 – Die Monolith-Architektur (ERP-zentriert)

• Struktur: Zentrales Cloud-ERP (z. B. SAP S/4HANA oder Microsoft Dynamics) als „Single Source of Truth“.

• Datenfluss: Erste API-Anbindungen (Point-to-Point), aber die Geschäftslogik ist starr im Kern des ERP gefangen.

• IT-Herausforderung: Das ERP wird als Datenbank missbraucht („Customizing-Overload“), was Upgrades erschwert und die Agilität bremst.

Level 3 – Die Data-Lakehouse-Architektur (Integration)

• Struktur: Trennung von Core-ERP (Transaktionen) und einem Data-Intelligence-Layer (z. B. Snowflake, Databricks oder Azure Synapse).

• Datenfluss: Einführung von Event-Driven-Architekturen. Daten werden nicht mehr zeitversetzt abgeholt (Pull), sondern bei Ereignissen in Echtzeit gestreamt (Push via Kafka/RabbitMQ).

• Governance: Implementierung der Standardized Data Contracts (SDC). Daten werden an der Quelle (IoT/Sales) validiert, bevor sie das Finanzsystem erreichen.

Level 4 – Die Distributed-Ledger-Schnittstelle (Automatisierung)

• Struktur: Hybrid-Cloud-Modell mit integriertem Private Ledger (Blockchain) für alle prüfungsrelevanten Transaktionen.

• Technologie: Einsatz von Smart Accounting Contracts, die komplexe Regelwerke (IFRS 15/16) direkt auf dem Datenstrom ausführen.

• Audit-Layer: Ein Auditor-Node ermöglicht externen Prüfern den verschlüsselten Read-only-Zugriff auf die unveränderliche Transaktionshistorie (Real-Time Evidence).

Level 5 – Die Autonomous-Mesh-Architektur (NextLevel)

• Struktur: Data Mesh Ansatz. Jede Business-Domain (Produktion, Sales, Finance) verwaltet ihre Daten als eigenständige, qualitätsgesicherte Produkte („Data as a Service“).

• KI-Integrität: Agentic Workflows (autonome KI-Agenten) überwachen die Einhaltung der Data Contracts und führen das Self-Healing-Audit (Inverse-Token-Logik) bei Diskrepanzen autonom durch.

• Real-Time-Core: Die Architektur ermöglicht Sub-Second-Assurance. Die Bilanz ist kein statisches Dokument mehr, sondern ein kontinuierlicher, verifizierter Live-Stream der Unternehmenswertschöpfung.

3. Die Transformations-Achse: Warum Technologie allein kein Level-Up garantiert

Ein entscheidender Fehler klassischer Modelle ist die Annahme, dass der Kauf teurer Software automatisch den Reifegrad erhöht. Im NMS-Finance wissen wir: Zwei Unternehmen können exakt denselben Software-Stack (z. B. SAP S/4HANA) nutzen, aber in völlig unterschiedlichen Welten leben. Während das eine Unternehmen nur „alte Formulare in neuen Fenstern“ ausfüllt, nutzt das andere die Daten für autonome Entscheidungen.

Um diesen Unterschied messbar zu machen, führen wir drei strategische Kennzahlen ein, die quer zu den Leveln L0–L5 liegen:

3.1 Der Intent-Index (II): Von der Reparatur zur Innovation

Dieser Index misst die geistige Ausrichtung der Transformation. Ein niedriger Intent-Index bedeutet, dass Technologie nur als „Lückenbüßer“ (Gap-Schließer) dient, um manuelle Fehler zu kaschieren oder gesetzliche Vorgaben gerade so zu erfüllen. Ein hoher Intent-Index (Ziel > 70) zeigt, dass das Unternehmen Technologie ergebnisoffen als „Potenzial-Hebel“ nutzt. Hier wird gefragt: „Welche neuen Geschäftsmodelle oder Preislogiken ermöglicht uns diese Datenqualität?“ 

3.2 Der Process-Renewal-Index (PRI):

Das Ende der „Digitalen Kopie“ Echte Transformation findet nicht im Code statt, sondern im Prozessdesign. Der PRI misst den Anteil der Kernprozesse, die nach dem Zero-Based-Design-Prinzip neu aufgesetzt wurden. Wer einen ineffizienten analogen Prozess digitalisiert, erhält einen schnellen, ineffizienten digitalen Prozess. Ein hohes NMS-Level erfordert einen PRI von mindestens 40 %, was bedeutet, dass fast jeder zweite Prozess grundlegend neu gedacht wurde, um die Möglichkeiten von KI und Blockchain überhaupt nutzen zu können.

3.3 Der Assurance-Reife-Grad (AR): Vertrauen als System-Eigenschaft

In der Endstufe (L5) ist Vertrauen kein Zufall mehr, sondern ein programmiertes Attribut. Der AR misst, wie stark das Unternehmen von der nachträglichen Fehlerkorrektur (Detektion) zur systemischen Fehlervermeidung (Prävention) übergegangen ist. Hier fließen die Standardized Data Contract Tags (SDC) ein: Daten werden nur dann im System akzeptiert, wenn sie ihre „Geburtsurkunde“ (Lineage) und Qualitätsprüfung bereits im Header mitführen.

3.4 Integration der Data Governance in die NMS-Level

Der Data-Governance-Index (DGI): Von der Kontrolle zur Architektur Echte Level-Sprünge im NMS-Finance scheitern oft an „Dirty Data“. Der DGI misst den Grad der Formalisierung von Datenverantwortung. Während L1 lediglich Namen an Tabellen schreibt (Ownership), erzwingt L5 die Datenqualität technisch durch Standardized Data Contracts (SDC). Governance ist im NMS kein bürokratisches Handbuch, sondern ein programmierter Filter, der nur „prüfungsreine“ Daten in den Finanzstrom lässt.

Level 1: Die Disziplin-Basis (Reaktive Governance)

• Fokus: Definition von Data Ownership.

• Massnahme: Einführung einer RACI-Matrix für Finanz-Stammdaten. Es wird festgelegt, wer für die Qualität eines Datensatzes (z.B. CO₂-Faktor oder Zahlungsziel) verantwortlich ist.

• Governance-Typ: „Police-Modus“ – Fehler werden manuell korrigiert, wenn sie auffallen.

Level 2: Die Prozess-Hygiene (Standardisierte Governance)

• Fokus: Stammdaten-Disziplin im ERP.

• Massnahme: Einführung von systemseitigen Validierungsregeln. Ein Prozess kann nur gestartet werden, wenn die Pflichtfelder nach NMS-Standard gefüllt sind.

• Governance-Typ: Regelbasierte Kontrolle im Monolithen.

Level 3: Die Geburtsurkunde der Daten (Präventive Governance) – DER DURCHBRUCH

• Fokus: Standardized Data Contracts (SDC).

• Massnahme: Daten werden an der Quelle (IoT-Sensor, Sales-Eingabe) mit Metadaten versehen. Jedes Datenpaket erhält eine „digitale Geburtsurkunde“ (Lineage).

• Governance-Logik: Das System akzeptiert Daten nur, wenn sie dem SDC entsprechen. Governance rückt vom Ende des Prozesses (Reporting) an den Anfang (Erfassung).

Level 4: Die algorithmische Governance (Automatisierte Assurance)

• Fokus: Model-Governance (MLOps).

• Massnahme: Überwachung der KI-Modelle. Da Level 4 auf ML-Forecasts setzt, muss die Governance sicherstellen, dass die Algorithmen nicht „halluzinieren“.

• Blockchain-Link: Kritische Governance-Entscheidungen (z.B. Änderung einer Buchungslogik) werden als unveränderlicher Hash auf der Chain gespeichert.

Level 5: Data Mesh & Self-Healing Governance (Autonome Governance)

• Fokus: Federated Computational Governance.

• Massnahme: Die Governance ist im Code hinterlegt. Agentic Workflows prüfen in Millisekunden, ob Datenströme zwischen den Domains (Produktion -> Finance) integer sind.

• Governance-Typ: Das System heilt sich selbst durch das Inverse-Token-Protokoll, falls Governance-Verstösse erkannt werden. Datenqualität ist hier eine systemische Eigenschaft, kein menschlicher Aufwand mehr.

4. Operational Linkage: Die Mechanik der Wertschöpfung

Das Operational Linkage ist das Herzstück des NMS-Finance. Es ist die mathematische und logische Brücke, die eine operative Verbesserung auf dem Shopfloor (OEE 5.0) direkt mit der P&L, dem Cashflow und der CO₂-Bilanz verknüpft. Im NMS-Finance wird jede Maßnahme in eine harte monetäre und ökologische Wirkung übersetzt.

4.1 Die Logik der Wirkungsformeln

Wir brechen das Silo-Denken auf. Wenn die Produktion die Rüstzeiten optimiert (OEE-Hebel), sieht der CFO im NMS-Modell sofort drei Effekte:

1. EBIT-Effekt: Höherer Durchsatz bei gleichen Fixkosten steigert den Deckungsbeitrag.

2. Cash-Effekt (Working Capital): Schnellere Durchlaufzeiten reduzieren die Bestände (DIH), was gebundenes Kapital in CHF freisetzt.

3. CO₂-Effekt: Weniger An- und Abfahrprozesse senken die Energieintensität pro produziertes Stück.

4.2 Realitätsnahes Rechenbeispiel (Industrie-Case)

Stellen wir uns einen mittelständischen Hersteller mit CHF 120 Mio. Umsatz vor, der den Sprung von Level 2 auf Level 3 vollzieht:

Durch das Process Renewal gelingt es, die Außenstände (DSO) von 58 auf 45 Tage zu senken. Das ist keine bloße Kosmetik, sondern bedeutet eine Cash-Freisetzung von ca. CHF 4,27 Mio. Bei einem Zinssatz von 4 % spart das Unternehmen allein dadurch CHF 171.000 an Zinskosten pro Jahr. Gleichzeitig führt die Einführung der OEE 5.0 Logik zu einer Reduktion der Energieintensität um 2,5 %. Bei einem angenommenen CO₂-Preis von CHF 100 pro Tonne generiert dies nicht nur einen ökologischen Vorteil, sondern spart messbare Kosten im Bereich von CHF 65.000 bis 90.000.

4.3 Die Blockchain-Schnittstelle als „Wahrheits-Anker“

Ab Level 4 wird dieses Operational Linkage automatisiert. Sobald ein Sensor (IoT) meldet, dass eine Maschine ein fehlerfreies Werkstück produziert hat, löst die NMS-Schnittstelle einen Trigger aus:

• Es wird ein Token auf der Blockchain erzeugt, der die physische Existenz des Produkts bestätigt.

• Dieser Token ist untrennbar mit der CO₂-Wirkungskette verknüpft.

• Falls später eine Korrektur nötig ist (z. B. wegen einer Retoure), löscht das System nichts, sondern erzeugt einen Inverse-Token.

Dadurch entsteht eine „Chain of Trust“. Ein Investor oder Auditor sieht im Dashboard nicht nur eine Zahl („Umsatz X“), sondern er kann bis auf den einzelnen Maschinen-Trigger zurückverfolgen, warum dieser Umsatz berechtigt ist. Manipulationen und „Leichen im Keller“ haben in dieser Architektur keinen Platz mehr, da die physikalische Welt (Sensor) die finanzielle Welt (Token) kontrolliert.

5. Die Assurance-Brücke: Vom mühsamen Suchen zum automatisierten Finden

In der klassischen Welt ist die Wirtschaftsprüfung ein rückwärtsgewandter, stichprobenartiger Prozess. Man wühlt in Belegen der letzten zwölf Monate, um Fehler zu finden, die längst passiert sind. Das NMS‑Finance dreht dieses Prinzip um: Es baut die Prüfung direkt in den Datenfluss ein (Auditable by Design). Höhere Reifegrade bedeuten hier nicht nur „schönere Dashboards“, sondern eine fälschungssichere Datenarchitektur.

5.1 Der „Leichen-Scanner“: Physische vs. Monetäre Evidenz

Echte „Leichen im Keller“ (Luftbuchungen, Scheinumsätze) überleben im NMS-L5 keine Sekunde. Das System gleicht permanent die finanzielle Welt (Token) mit der physischen Welt (Sensoren/IoT) ab.

• Ein praktisches Beispiel: Wenn ein Umsatz-Token für ein Produkt erzeugt wird, prüft der integrierte Audit-Algorithmus, ob im selben Zeitraum die OEE 5.0-Daten eine entsprechende Maschinenlaufzeit und die CO₂-Wirkungskette den passenden Energieverbrauch melden.

• Fehlt diese physische Entsprechung, markiert das System den Datensatz sofort als „Orphan Token“ (verwaister Token). Der Auditor muss nicht mehr suchen; er bekommt eine Liste der Unstimmigkeiten in einer Anomaly-Heatmap serviert.

5.2 Das Inverse-Token-Protokoll: Ehrlichkeit durch Unveränderlichkeit

Ein Kernproblem der digitalen Buchhaltung ist das „stille Löschen“ oder „Überschreiben“ von Fehlern. Auf der NMS-Blockchain-Schnittstelle ist das technisch unmöglich.

• Wenn eine Fehlbuchung erkannt wird, greift das Inverse-Token-Protokoll: Die ursprüngliche Buchung bleibt als historischer Fakt bestehen, und es wird ein fälschungssicherer Korrektur-Token erzeugt, der untrennbar mit dem Fehler verlinkt ist.

• Für den Auditor bedeutet das totale Traceability. Er sieht genau, wer, wann und warum korrigiert hat. Diese Transparenz schafft ein höheres Vertrauenslevel, das den jährlichen Prüfungsaufwand und damit die Kosten senkt.

6. Goodwill in Bausteinen: Die Revolution der Werthaltigkeit

Der Goodwill ist in der traditionellen Bilanzierung oft ein „toter Posten“ – eine riesige Zahl, die erst angefasst wird, wenn es eigentlich schon zu spät ist (Impairment-Test nach IAS 36). Im NMS‑Finance machen wir den Goodwill lebendig, indem wir ihn in operativ messbare Werttreiber-Bausteine zerlegen.

6.1 Die Zerlegung in Value-Driver-Streams

Wir betrachten Goodwill nicht als einen Block, sondern als ein Portfolio aus fünf strategischen Bausteinen, die über Smart Contracts überwacht werden:

1. Customer-Equity-Baustein: Gemessen durch Net Revenue Retention (NRR) und Churn-Raten.

2. Tech- & Plattform-Baustein: Gemessen durch Feature-Adoption und Stabilität der Systeme.

3. Go-to-Market-Baustein: Gemessen durch die Effizienz der Sales-Funnel (LTV/CAC).

4. Workforce-Capability-Baustein: Gemessen durch Skill-Verfügbarkeit und Fluktuation in Schlüsselrollen.

5. Operational-Leverage-Baustein: Gemessen durch OEE-Deltas und Skaleneffekte.

6.2 Echtzeit-Monitoring statt „Impairment-Schock“

Jeder dieser Bausteine ist im System mit automatisierten Triggern hinterlegt.

• Beispiel Tech/SaaS: Sinkt die Net Revenue Retention (NRR) über drei Monate hinweg signifikant, löst der Smart Contract automatisch einen Alarm aus. Das System bewertet den zugehörigen Goodwill-Baustein in Echtzeit neu.

• Der strategische Vorteil: Das Management sieht die Gefahr für den Unternehmenswert Monate bevor der Wirtschaftsprüfer im Jahresabschluss eine Abschreibung fordert. Das ermöglicht proaktives Gegensteuern (z. B. durch gezielte Produkt-Roadmap-Änderungen), anstatt nur den Wertverlust zu dokumentieren.

6.3 Die Blockchain-Schnittstelle für Assets

Durch die Tokenisierung dieser Bausteine auf der Chain wird der Unternehmenswert granular. Bei M&A-Transaktionen können Käufer exakt sehen, welcher Teil des Aufpreises (Goodwill) durch welche operativen Daten untermauert ist. Dies beendet das Zeitalter der „Blackbox-Bewertungen“ und macht NMS-zertifizierte Firmen zu den sichersten Investments am Markt.

7. Branchen-Adaption: Ein System, viele Welten

Das NMS‑Finance ist so konzipiert, dass die Kernlogik (L0–L5) universell bleibt, die operativen Trigger jedoch branchenspezifisch „atmen“. Ein Standard-Modell scheitert oft an der Komplexität verschiedener Geschäftsmodelle – NMS nutzt diese Komplexität als Datenquelle.

7.1 Industrie & Fertigung: Der „Physical-Twin“

Hier ist die OEE 5.0 das unbestrittene Gravitationszentrum. Ein L4-Industriebetrieb verknüpft Rüstzeiten, Ausschussraten und Energieintensität direkt mit dem Cashflow.

• Der Trigger: Eine ungeplante Downtime an einer Engpassmaschine erzeugt im NMS-System nicht nur eine Wartungsmeldung, sondern berechnet sofort den EBIT-Impact und die Verschiebung der CO₂-Ziele.

• Scope 3 Fokus: Die Materialeffizienz wird zum primären Hebel für die CO₂-Wirkungskette.

7.2 Tech & SaaS: Die „Subscription-Economy“

In der Softwarewelt treten physikalische Maschinen zurück, und Kohorten-Metriken treten vor.

• Der Trigger: Die Schnittstelle überwacht die Feature-Adoption (nutzen die Kunden das Produkt?). Sinkt die Nutzung, sinkt der Wert des „Product-Equity-Tokens“.

• Cloud-CO₂: Der Energieverbrauch der Serverinfrastruktur wird als Scope-3-Echtzeit-Last in die Deckungsbeitragsrechnung je Kunde integriert.

7.3 Health & Healthcare: Qualität als Währung

In Kliniken und Pflegeeinrichtungen wird die OEE 5.0 auf Kapazitäten (Betten, OP-Säle) und Patientensicherheit übersetzt.

Der Trigger: Kodierqualität und Verweildauer-Optimierung werden gegen die Personalfluktuation (Workforce-Token) gerechnet. Ein Level-5-Krankenhaus steuert Ressourcen so, dass medizinische Qualität und finanzielle Stabilität keine Gegenspieler mehr sind.

8. Benchmark-Mechanik: Vom Vergleich zum FOMO-Antrieb

Warum wird NMS-Finance weltweit die Nr. 1? Weil es ein psychologisches Grundbedürfnis nutzt: Den Wunsch, besser zu sein als der Wettbewerb (oder zumindest nicht den Anschluss zu verlieren). Wir nennen das die FOMO-Mechanik (Fear Of Missing Out).

8.1 Der anonymisierte Peer-Vergleich

Jedes Unternehmen, das das NMS-Assessment durchläuft, speist (anonymisiert) seine Daten in den globalen NMS-Pool ein.

• Ein CFO sieht nicht nur seinen Score von 62/100, sondern er sieht: „75 % deiner direkten Wettbewerber im Sektor 'Automotive Mid-Cap' haben bereits Level 3 erreicht und nutzen automatisierte CO₂-Pricing-Modelle.“

• Dieser Vergleich erzeugt einen gesunden Rechtfertigungsdruck gegenüber dem Board und den Investoren.

8.2 Der „Assurance-Discount“ (Die ökonomische Peitsche)

Wir arbeiten darauf hin, dass Banken und Versicherungen den NMS-Score in ihre Rating-Modelle aufnehmen.

• Ein Unternehmen auf Level 4 mit einem hohen Intent-Index hat ein nachweislich geringeres Risiko für „Leichen im Keller“ und operative Blindflüge.

• Die Konsequenz: Niedrigere Kreditzinsen (Interest Rate Spreads) für High-Level-NMS-Firmen. Wer auf L1 bleibt, zahlt am Ende eine „Ineffizienz-Prämie“ an die Bank. Das ist der stärkste Treiber für eine weltweite Adoption.

8.3 Der „Next Best Move“ Algorithmus

Das System lässt den Nutzer nicht mit einem schlechten Score allein. Basierend auf den 24 Fragen des Assessments generiert die NMS-Engine sofort ein 30/60/90-Tage-Playbook.

Statt allgemeiner Ratschläge sagt das System: „Um von L2 auf L3 zu kommen, musst du in den nächsten 30 Tagen deine Stammdaten-Ownership für die CO₂-Faktoren klären (RACI) und die JE-Templates für deine Top-5-Umsatzströme versionieren.“

9. Datenverträge: Das Immunsystem der Finanzarchitektur

Einer der Hauptgründe, warum Transformationen scheitern, ist „Data Silo Chaos“ – jeder versteht unter einem Begriff etwas anderes. Das NMS‑Finance löst dies durch Standardized Data Contracts (SDC). Ein Datenvertrag ist eine bindende Vereinbarung zwischen dem Datenerzeuger (z. B. Sensor/IoT) und dem Datenempfänger (Finanzwesen).

9.1 Das „NMS-L3 Ready“ Zertifikat für Software

Stell dir vor, Softwareanbieter wie SAP, Microsoft oder spezialisierte ESG-Tools lassen ihre Module zertifizieren. Ein Feld „Energieverbrauch“ liefert dann nicht nur eine Zahl, sondern einen Daten-Header mit:

• Semantik: Definition nach NMS-Standard (z. B. kWh pro Netto-Einheit).

• Qualität: Zeitstempel, Sensor-ID und Validierungsstatus.

• Lineage: Der unveränderliche Pfad von der Maschine bis zum Ledger.

• Wirkung: Automatische Verknüpfung mit dem CO₂-Preis und dem EBIT-Impact.

9.2 Der SDC als Filter für „Daten-Müll“

Auf Level 4 und 5 fungiert der Datenvertrag als Gatekeeper. Wenn ein Datenstrom (z. B. eine manuelle Buchung oder ein unsauberer IoT-Feed) nicht den Anforderungen des Vertrags entspricht, wird er vom System abgewiesen, noch bevor er das Accounting erreicht.

Der Effekt: Das System hat ein eingebautes Immunsystem. „Leichen im Keller“ entstehen oft durch schlechte Datenqualität am Anfang der Kette – der SDC verhindert dies systemisch.

10. Playbooks: Die 30/60/90-Tage-Marschroute

Ein Reifegradmodell ohne Umsetzungsplan ist eine Sackgasse. Das NMS‑Finance liefert für jeden Level-Sprung ein konkretes Playbook, das die operative Hektik in eine strategische Choreografie verwandelt.

10.1 Sprung L1 → L2: Die Disziplin-Phase

• 30 Tage: Durchführung des NMS-Assessments (24 Fragen). Identifikation der „Schatten-Excels“. Festlegung der Data Ownership (RACI) – wer ist für welchen Datenpunkt verantwortlich?

• 60 Tage: Bereinigung der Stammdaten (Clean-Up). Einführung einer Prozesslandkarte, die zeigt, wo Daten entstehen und wo sie sterben.

• 90 Tage: Deaktivierung von manuellen „Workarounds“ im ERP. Start der Baseline-Messung für OEE-Klassik und Scope 1/2 CO₂.

10.2 Sprung L2 → L3: Der Wirkungs-Durchbruch (Process Renewal)

• 30 Tage: Durchführung von „What-else?“-Workshops. Wir fragen nicht: „Wie digitalisieren wir den alten Prozess?“, sondern: „Wie sähe der Prozess aus, wenn wir ihn heute auf der grünen Wiese neu bauen würden?“

• 60 Tage: Einführung der ersten Standardized Data Contracts. Verknüpfung von OEE-Daten mit dem Working Capital (DSO/DIH).

• 90 Tage: Integration des Customholder-KPI-Sets (NPS × CLV × Cash × CO₂). Der Abschluss (Closing) muss stabil unter 5 Tagen liegen.

10.3 Sprung L4 → L5: Die autonome Exzellenz

• 30 Tage: Aktivierung der Blockchain-Schnittstelle. Pilotierung der ersten Smart Accounting Contracts für komplexe Leasing- oder Umsatzverträge.

• 60 Tage: Zerlegung des Goodwills in die fünf Value-Driver-Bausteine. Start des kontinuierlichen Monitorings über die Trigger-Engine.

• 90 Tage: Implementierung der Continuous Assurance. Externe Auditoren erhalten Read-only-Zugriff auf die Blockchain-Nodes. Der Inverse-Token-Prozess für Korrekturen wird zum Standard.

11. Die MVA©-Zertifizierung: Ausbildung der „NMS-Architekten“

Weltmarktführerschaft braucht Botschafter. Die MVA© (Minimum viable Audit) Zertifizierung ist der akademische und praktische Unterbau des NMS-Finance.

• Foundation-Level: Fokus auf L0–L2 (Handwerk, Datenhygiene, ERP-Disziplin).

• Professional-Level: Fokus auf L3–L4 (Operational Linkage, CO₂-Wirkungsketten, ML-Forecasting).

• Master-Level (NextLevel): Fokus auf L5 (Tokenisierung, Blockchain-Schnittstellen, Goodwill-Architektur, Continuous Assurance).

Jeder Absolvent ist in der Lage, ein Unternehmen nachweislich und messbar auf der Leiter nach oben zu führen. Wir bilden keine Verwalter aus, sondern Mitunternehmer, die den Wert der Firma aktiv steuern.

Für Fachkräfte, die internationale Standards anstreben, integriert das Studium zum Diplom Betriebswirtschafter HF – Global Finance die weltweit anerkannten Curricula von ACCA und CIMA. Durch den modularen Aufbau pro Semester verzahnen wir die globale Finanzlehre direkt mit der Anwendung des MVA©-Systems. Absolventen werden so zu Experten für hocheffiziente, prüfungssichere Finanzprozesse der nächsten Generation.

Der Master-Case: „SwissPrecision Tech AG“

Szenario: Ein mittelständischer Hersteller von Hochleistungs-Komponenten (Umsatz CHF 150 Mio.). Status Quo (L2): Modernes ERP vorhanden, aber Prozesse sind „digitale Kopien“ der 90er Jahre. Monatsabschluss dauert 12 Tage. Goodwill aus einer Akquisition (CHF 20 Mio.) steht als statischer Block in der Bilanz.

Phase 1: Der OEE 5.0 & CO₂-Hebel (L2 → L3)

Aufgabe: Die Studierenden analysieren die Sensordaten einer Frässtrasse.

• Daten-Input: Die OEE liegt bei 65 %. Die Energieintensität ist hoch, da die Maschinen bei Stillstand nicht runterfahren.

• Die NMS-Lösung: Implementierung eines Standardized Data Contracts (SDC) für Maschinendaten.

• Übungsziel: Berechnung des Operational Linkage.

  • Frage: „Wenn wir die Rüstzeit durch IoT-Steuerung um 15 % senken und den Energieverbrauch pro Stück um 5 % reduzieren – wie verändert das unser Working Capital (DIH) und unseren CO₂-Deckungsbeitrag in CHF?“

Phase 2: Das Minimum Viable Audit© (L3 → L4)

Aufgabe: Simulation einer Umsatzprüfung für einen Grossauftrag.

• Problem: Der Wirtschaftsprüfer zweifelt die Umsatzrealisierung (IFRS 15) an, da die Abnahmedokumente manuell und fehleranfällig sind.

• Die NMS-Lösung: Verknüpfung der physischen Auslieferung (IoT/Logistik-Event) mit einem automatisierten Umsatz-Token.

• Übungsziel: Erstellung eines MVA-Prüfpfads.

  • Frage: „Wie beweisen wir dem Auditor rein digital, dass die Leistung erbracht wurde, ohne einen einzigen Papierbeleg zu zeigen? Nutzen Sie die technische Lineage des Datenvertrags.“

Phase 3: Der Goodwill-Check & die Leichen im Keller (L4 → L5)

Aufgabe: Die SwissPrecision Tech AG hat eine Software-Bude gekauft. Der Goodwill beträgt CHF 10 Mio. Plötzlich kündigen zwei Key-Entwickler und die Churn-Rate der Kunden steigt um 4 %.

• Problem (Klassisch): Man merkt es erst beim nächsten Jahresabschluss -> Hohe Abschreibung, Schock bei den Banken.

• Die NMS-Lösung: Zerlegung des Goodwills in Value-Driver-Bausteine (Workforce & Customer Equity).

• Übungsziel: 1. Trigger-Alarm: Das System erkennt das Sinken der NRR (Net Revenue Retention) automatisch. 2. Inverse-Token: Erstellung einer automatisierten Teil-Wertberichtigung auf der Blockchain. 3. Audit: Der Studierende schlüpft in die Rolle des Auditors und findet über die Anomaly-Heatmap sofort den Korrektur-Token und die operative Ursache (Churn-Event).