Die kurze Antwort
Eine NEVARIS-Integration ist dann gelungen, wenn niemand mehr eine Information abtippt, die im ERP bereits steht. Das ist der ehrlichste Prüfstein — konkreter als jede Schnittstellen-Liste.
NEVARIS Finance basiert auf Microsoft Dynamics 365 Business Central und stellt seine Daten über eine OData-REST-Schnittstelle bereit. Damit lassen sich Stammdaten und Belege in beide Richtungen bewegen. Der Aufwand liegt selten in der Technik, sondern in der Entscheidung, welche Daten überhaupt hinausgehen sollen und wer die Hoheit über sie behält.
Das Problem: Die Daten enden an der Systemgrenze
In fast jedem Bauunternehmen, das mit einem Bau-ERP arbeitet, gibt es zwei Sorten von Mitarbeitenden: die wenigen, die im ERP arbeiten — Buchhaltung, operativer Einkauf, Kalkulation — und die vielen, die dessen Daten brauchen, aber nicht darin arbeiten. Bauleiter, Fachabteilungen, Sachbearbeiter, Poliere.
Die zweite Gruppe behilft sich. Mit Excel-Listen, die einmal im Monat aktualisiert werden. Mit Anrufen in die Buchhaltung. Mit ausgedruckten Debitorenlisten im Baucontainer. So entstehen genau die Dateninseln, die das ERP eigentlich verhindern sollte — und jede davon hat einen eigenen Stand.
Das typische Muster: Nicht das ERP ist zu schwach. Es ist zu weit weg von denen, die die Information brauchen.
Das Prinzip: eine Prozessschicht vor dem ERP, kein Ersatz
NEVARIS Finance bleibt das führende System — das System of Record für alle kaufmännischen Daten. Davor entsteht eine Prozess- und Portalschicht, in der die eigentliche Arbeit stattfindet: Anträge, Meldungen, Freigaben, Auskünfte. Beide Seiten sprechen über die OData-Schnittstelle miteinander.
Wir bauen diese Schicht auf der Low-Code-Plattform Intrexx, weil sie beides mitbringt: die Schnittstellenfähigkeit und die Portal-Oberfläche, in der Mitarbeitende ohnehin schon arbeiten.
Wichtig ist die Abgrenzung: Es wird nichts abgelöst und nichts nachgebaut. Buchhaltung und Einkauf arbeiten weiter in NEVARIS. Was sich ändert, ist die Reichweite der Daten.
Die sechs Bausteine einer NEVARIS-Integration
Aus einem realen Integrationsprojekt bei einem mittelständischen Fertighaushersteller. Die Bausteine bauen aufeinander auf, lassen sich aber einzeln einführen.
| Baustein | Was passiert |
|---|---|
| 1. Debitoren-Synchronisation | Debitoren aus NEVARIS stehen in allen internen Prozessen zur Verfügung — ohne dass jemand sie neu anlegt oder eine Liste pflegt. Eine führende Datenhaltung, keine Inseln. |
| 2. Zahlungseingänge | Zahlungseingänge werden ins Portal gezogen und dem jeweiligen Bauvorhaben zugeordnet. Der Bauleiter sieht den Zahlungsstand seiner Baustelle — und kann den Bauherrn direkt ansprechen, statt es zwei Wochen später aus der Buchhaltung zu erfahren. |
| 3. Bautenstand → Rechnungsausgang | Wird ein Bautenstand erreicht und gemeldet, entsteht automatisch ein Datensatz im Rechnungsausgangsbuch. Die Buchhaltung prüft und gibt frei — die Rechnung geht danach innerhalb weniger Stunden raus. |
| 4. Bestellanforderung | Bestellanforderungen werden im Portal erfasst, auf Basis der NEVARIS-Artikelstammdaten, und per OData direkt ins ERP übertragen. Der operative Einkauf prüft und erzeugt daraus die Bestellung. |
| 5. Wareneingang | Die erzeugte Bestellung ist im Portal für Fachabteilung und Baustelle sichtbar. Lieferungen werden dort direkt eingebucht — voll oder teilgeliefert — und laufen per Schnittstelle zurück ins ERP. |
| 6. Automatische Rechnungsprüfung | Trifft die Eingangsrechnung ein, wird sie automatisch verbucht, sofern Bestellung und Lieferung bereits erfasst sind. Klassischer Drei-Wege-Abgleich, ohne manuelles Zusammensuchen. |
Ausführlich beschrieben ist der komplette Beschaffungskreislauf — Baustein 4 bis 6 — in unserem Leitfaden Bestellanforderung digital im Bau.
Was das in der Praxis verändert hat
Zwei Effekte waren bei dem Fertighaushersteller am deutlichsten:
- Über 100 Sachbearbeiter arbeiten in einer Oberfläche statt in zwei Systemen. Kein Wechsel zwischen ERP-Client und Portal, keine doppelte Erfassung, keine Einarbeitung in eine zweite Bedienlogik. Das ist der Effekt, der im Alltag am meisten zählt und der sich am schwersten in einer Zahl ausdrücken lässt.
- Vom erreichten Bautenstand zur versandten Rechnung vergehen wenige Stunden statt Tage. Die Buchhaltung prüft weiterhin jede Rechnung — sie muss die Information nur nicht mehr einsammeln.
Zur Einordnung: Wir nennen hier bewusst keine Einsparungssumme und keine ROI-Zahl. Beides ließe sich leicht behaupten, aber wir haben es in diesem Projekt nicht sauber gemessen — und erfundene Kennzahlen helfen Ihnen bei Ihrer Entscheidung nicht weiter.
Die Lizenzfrage — ehrlich beantwortet
Fast jedes Gespräch zu diesem Thema beginnt mit derselben Hoffnung: Wenn die Leute nicht mehr im ERP arbeiten, sparen wir Lizenzen.
So einfach ist es nicht. Microsoft regelt den indirekten Zugriff über die sogenannte Multiplexing-Klausel: Wer über ein vorgelagertes Portal oder eine API auf Daten aus Business Central zugreift, ist damit nicht automatisch von der Lizenzpflicht befreit. Eine Prozessschicht ist kein Werkzeug, um Lizenzen zu umgehen, und wir verkaufen sie auch nicht so.
Was sie ermöglicht, ist etwas anderes und weniger Spektakuläres, aber Belastbares: einen sauberen Zuschnitt der Lizenzstufen. Der vollwertige ERP-Fachplatz bleibt denen vorbehalten, die tatsächlich im ERP arbeiten. Für Nutzergruppen, die nur definierte Daten sehen oder eng umrissene Vorgänge auslösen, kommt gegebenenfalls ein leichterer Lizenztyp in Betracht. Ohne Prozessschicht stellt sich diese Frage gar nicht erst — dann sitzen alle im ERP-Client.
Wichtig: Welcher Lizenztyp für welche Nutzergruppe der richtige ist, gehört mit NEVARIS beziehungsweise Ihrem Business-Central-Lizenzpartner geklärt. Wir sind Integrationspartner, keine Lizenzberatung — und würden Ihnen an dieser Stelle ungern etwas versprechen, das im Audit nicht hält.
Technische Voraussetzungen
Für eine NEVARIS-Anbindung an ein Intranet oder Portal braucht es auf beiden Seiten wenig, aber Konkretes:
- Auf NEVARIS-/Business-Central-Seite: eine Umgebung mit aktivierten Webdiensten (OData v4) und ein technischer Benutzer mit Web Service Access Key, dessen Berechtigungen auf die tatsächlich benötigten Objekte begrenzt sind.
- Auf Portalseite: eine Plattform, die OData-Dienste lesend und schreibend konsumieren kann. Reines Anzeigen reicht nur für die ersten Bausteine.
- Netzwerk: eine kontrollierte Verbindung zwischen beiden Systemen — bei einer On-Premises-Installation anders zu lösen als in der Cloud-Variante.
- Fachlich: eine Festlegung je Objekt, in welche Richtung synchronisiert wird, in welchem Takt, und welches System im Konfliktfall gewinnt.
Der letzte Punkt ist der einzige, der regelmäßig länger dauert als geplant. Die Technik ist Handwerk.
Sicherheit
Sobald ERP-Daten das ERP verlassen, wird die Berechtigungsfrage neu gestellt. Vier Punkte, die in jedem Projekt geklärt gehören:
- Datenminimierung: Übertragen wird, was fachlich gebraucht wird — nicht der komplette Mandant, „weil es einfacher ist".
- Rechte-Mapping: Wer im Portal welche ERP-Daten sieht, muss dort genauso eng geregelt sein wie im ERP. Sonst verlagert die Integration ein Berechtigungsproblem, statt es zu lösen.
- Technischer Dienstbenutzer: Die Schnittstelle läuft nie über ein persönliches Konto, sondern über einen eigenen Benutzer mit minimalen Rechten.
- Protokollierung: Nachvollziehbar muss sein, welcher Datensatz wann in welche Richtung gelaufen ist — im Fehlerfall ist das der Unterschied zwischen einer Stunde und einem Tag Fehlersuche.
Ablauf eines Integrationsprojekts
- Bestandsaufnahme. Wo werden Daten heute doppelt erfasst, welche Prozesse bleiben an der Systemgrenze hängen? Meist reicht ein halber Tag mit den richtigen Leuten im Raum.
- Schnittstellen-Design. Welche Objekte, welche Richtung, welcher Takt, welches System führt. Das ist die Entscheidung, die später am teuersten zu revidieren ist.
- Erster Baustein, lesend. In der Regel die Stammdaten-Synchronisation — risikoarm, weil nichts ins ERP zurückgeschrieben wird, und sofort sichtbar nützlich.
- Schreibende Prozesse. Bestellanforderung, Wareneingang, Rechnungsausgang. Hier beginnt der eigentliche Effekt.
Eine erste produktiv nutzbare Ausbaustufe ist typischerweise in vier bis sechs Wochen erreichbar. Die weiteren Bausteine kommen schrittweise dazu, ohne dass zwischendurch etwas stillsteht.
Wer das umsetzt
Für NEVARIS selbst — Module, Lizenzen, Updates — sind NEVARIS und dessen Partner die richtigen Ansprechpartner. Wir setzen daneben an: bei der Prozess- und Portalschicht, die aus ERP-Daten nutzbare Abläufe macht.
Was wir mitbringen: 15 Jahre Projektarbeit im Mittelstand, den Status als Intrexx Certified Solution Expert und eine real gebaute NEVARIS-Anbindung bei einem mittelständischen Fertighaushersteller — von der Debitoren-Synchronisation bis zum vollständigen Beschaffungskreislauf mit automatischer Rechnungsprüfung.
Was wir nicht machen: Lizenzberatung, und wir ersetzen kein funktionierendes ERP durch eine Eigenentwicklung. Wenn Ihr Anliegen im NEVARIS-Standard besser aufgehoben ist, sagen wir Ihnen das.
Häufige Fragen zur NEVARIS-Integration
Über die Schnittstelle des kaufmännischen Systems. NEVARIS Finance basiert auf Microsoft Dynamics 365 Business Central und stellt seine Daten über eine OData-REST-Schnittstelle bereit. Darüber lassen sich Stammdaten wie Debitoren und Artikel auslesen und Belege wie Bestellungen oder Wareneingänge zurückschreiben. Die Bauprozesse selbst — Bautenstandsmeldung, Bestellanforderung, Wareneingang — laufen dann in einer vorgelagerten Anwendung, die diese Schnittstelle nutzt, statt dass jeder Beteiligte im ERP-Client arbeiten muss.
NEVARIS Build ist die Linie für Kalkulation, AVA und Baumanagement — also die bautechnische Seite. NEVARIS Finance ist das kaufmännische ERP auf Basis von Microsoft Dynamics 365 Business Central: Finanzbuchhaltung, Debitoren und Kreditoren, Einkauf, Rechnungswesen. Wenn von Schnittstellen zu Debitoren, Zahlungseingängen, Bestellungen oder dem Rechnungsausgang die Rede ist, geht es fast immer um NEVARIS Finance. Wir arbeiten auf der Finance-Seite.
Indem das Intranet die benötigten Daten über die OData-Schnittstelle von NEVARIS Finance liest und schreibt, statt sie zu kopieren oder abzutippen. Praktisch heißt das: Debitoren, Artikelstammdaten oder Zahlungsstände erscheinen als reguläre Inhalte im Portal, und Anforderungen aus dem Portal — etwa eine Bestellanforderung — landen als Beleg im ERP. Entscheidend ist, vorher festzulegen, welche Daten überhaupt hinausgehen und wer sie sehen darf; alles andere ist Handwerk.
Auf NEVARIS-Seite eine Business-Central-Umgebung, in der Webdienste aktiviert sind, sowie ein technischer Benutzer mit Web Service Access Key und eng gesetzten Berechtigungen. Auf Portalseite eine Plattform, die OData-v4-Dienste konsumieren und schreiben kann — bei uns Intrexx. Dazu kommen die Netzwerkfreigabe zwischen beiden Systemen und eine Festlegung, welche Objekte in welcher Richtung und in welchem Takt synchronisiert werden. Der Aufwand liegt erfahrungsgemäß nicht in der Technik, sondern in dieser Festlegung.
Vier Punkte sind entscheidend. Erstens Datenminimierung: Es wird nur übertragen, was fachlich gebraucht wird — nicht der komplette Mandant. Zweitens ein sauberes Rechte-Mapping: Wer im Portal welche ERP-Daten sieht, muss dort genauso eng geregelt sein wie im ERP selbst, sonst verlagert die Integration ein Berechtigungsproblem. Drittens ein technischer Dienstbenutzer mit minimalen Rechten statt eines persönlichen Kontos. Viertens eine Protokollierung, aus der sich nachvollziehen lässt, welcher Datensatz wann in welche Richtung gelaufen ist.
Das ist die meistgestellte Frage — und die Antwort ist differenzierter, als viele hoffen. Microsoft regelt indirekten Zugriff über die sogenannte Multiplexing-Klausel: Wer über ein vorgelagertes Portal oder eine API auf Daten aus Business Central zugreift, ist damit nicht automatisch von der Lizenzpflicht befreit. Eine Prozessschicht ist also kein Mittel, um Lizenzen zu umgehen. Was sie sehr wohl ermöglicht, ist ein sauberer Zuschnitt: Der teure ERP-Fachplatz bleibt denen vorbehalten, die tatsächlich im ERP arbeiten, während für andere Nutzergruppen ein leichterer Lizenztyp in Frage kommt. Welcher das im Einzelfall ist, gehört mit NEVARIS beziehungsweise dem Lizenzpartner geklärt — wir beraten nicht lizenzrechtlich.
In der Praxis sind es vier Richtungen: das Intranet oder Portal, über das die Mehrheit der Mitarbeitenden arbeitet; mobile Baustellenanwendungen für Bautagebuch, Bautenstand und Wareneingang; die Dokumentenablage beziehungsweise das DMS; und die Zeitwirtschaft. Die kaufmännische Kette Bestellanforderung, Bestellung, Lieferung, Rechnung ist dabei der Bereich, in dem sich eine Anbindung am schnellsten bemerkbar macht, weil dort jeder Medienbruch unmittelbar Geld oder Zeit kostet.
In vier Schritten: Erstens eine Bestandsaufnahme, welche Daten heute wo doppelt erfasst werden und welche Prozesse an der Systemgrenze hängen bleiben. Zweitens die Festlegung der Schnittstellenobjekte samt Richtung, Takt und Verantwortlichkeit für die führende Datenhaltung. Drittens der Aufbau der Prozessschicht mit einem ersten, klar abgegrenzten Prozess — meist Stammdaten lesend, weil das risikoarm ist. Viertens die schreibenden Prozesse. Eine erste produktive Ausbaustufe ist typischerweise in vier bis sechs Wochen erreichbar.
Ja. Für die NEVARIS-Seite selbst sind NEVARIS und dessen Partner die richtigen Ansprechpartner. Für die vorgelagerte Prozess- und Portalschicht braucht es jemanden, der sowohl die Schnittstellen als auch die Bauprozesse kennt. Wir haben genau diese Anbindung für einen mittelständischen Fertighaushersteller gebaut — von der Debitoren-Synchronisation bis zum vollständigen Bestellkreislauf mit automatischer Rechnungsprüfung. Ein Erstgespräch dazu ist unverbindlich und kostenfrei.