Wenn Sie Nutzung nicht sauber belegen können, können Sie sie auch nicht sauber abrechnen. Genau daran scheitern viele Pay-per-Use-Vorhaben im Maschinenbau.
Der Kern ist schnell umrissen: Bevor es an Preislogik, Vertragsmodelle oder Forecasts geht, müssen drei Dinge stehen – klare Asset-Zuordnung, verlässliche Nutzungsdaten und ein ehrlicher Blick auf die installierte Basis. Erst danach wird aus einer Idee ein Modell, das für Service, Finance und Geschäftsführung im Alltag trägt.
Die entscheidenden Fragen vorab:
- Welche Maschinen sind im Feld?
- Welche davon sind vernetzt?
- Welche Nutzungswerte sind je Asset prüfbar?
- Welche Verträge erlauben welche Abrechnung?
- Wo reichen die Daten schon heute – und wo nicht?
Kurz gesagt: Pay-per-Use folgt der Reihenfolge Digitalisieren → Vernetzen → Entscheiden → Automatisieren. Wer mit Tarifen startet, baut auf Lücken. Wer mit Daten startet, senkt Streitfälle bei Rechnungen und schafft eine Basis für Forecasts, Service und Finanzierung.
Ab dort wird auch die Plattformfrage greifbar: Salesforce als Ort für Vertrags- und Servicekontext, Service Decision Intelligence (SDI) für nachvollziehbare Nutzungswerte mit Quellennachweis und EU-konformer Verarbeitung in der Kundeninfrastruktur, ergänzt um GRAX-gestützten CRM- und Vertragskontext ohne API-Limits.
Warum nutzungsbasierte Abrechnung ohne verlässliche Nutzungsdaten scheitert
Ohne belastbare Nutzungsdaten wird Pay-per-Use zur Schätzerei, nicht zur Abrechnung. Für Finance zählt nicht das Konzept, sondern die saubere Beweisführung der Nutzung.
Das Finanzrisiko hinter schwacher Nutzungsmessung
Für CFOs ist das kein Nebenthema. Wenn sich Nutzungsdaten nicht klar auf eine Quelle zurückführen lassen, fehlt der Abrechnung ihre belastbare Grundlage. Wiederkehrende Erlöse lassen sich nur dann planen, wenn die zugrunde liegenden Nutzungswerte reproduzierbar sind. Dafür braucht es eine automatisierte Übergabe in den Abrechnungsprozess, revisionsfähig und ohne manuelle Zwischenschritte. Alles andere führt zu Rückfragen, Verzögerungen und zusätzlichem Klärungsaufwand.
In der Praxis sehen wir oft das gleiche Muster: Maschinen senden einzelne Werte, aber Zeitstempel, Gerätebezug oder Plausibilisierung fehlen. Dann beginnt die Diskussion nicht beim Preis, sondern bei der Frage, ob die Nutzung überhaupt korrekt erfasst wurde. Genau dort kippt das Modell aus Sicht von Finance.
Noch wichtiger wird das auf Flottenebene. Erst wenn viele Maschinen nach einem einheitlichen Muster Daten liefern, entsteht ein Modell, das sich für Steuerung und Abrechnung nutzen lässt.
Warum vernetzte Flotten wichtiger sind als einzelne Maschinen
Pay-per-Use rechnet sich erst mit einer größeren, vernetzten Flotte gleichartiger Maschinen und messbar unterschiedlicher Auslastung. Eine einzelne Maschine kann einen Ansatz zeigen. Ein belastbares Geschäftsmodell entsteht daraus noch nicht. Ohne IoT-Telemetrie gibt es keine verlässliche Nutzungsmessung und keine Abrechnung, die sich in Serie betreiben lässt.
Genau deshalb gehört Pay-per-Use an das Ende einer Reifefolge: Digitalisieren → Vernetzen → Entscheiden → Automatisieren. Wer bei Tariflogik oder Vertragsmodellen startet, geht am Kern des Problems vorbei. Zuerst müssen Bestände, Nutzungsquellen und Datenqualität stimmen. Danach lässt sich bewerten, welche Abrechnungslogik pro Maschine, Kunde oder Flotte überhaupt tragfähig ist.
Für diesen Schritt ist eine nüchterne Bestandsaufnahme oft sinnvoll, etwa über ein Installed Base Assessment. Wenn Maschinentypen, Konnektivität, Datenpunkte und Auslastungsmuster sauber erfasst sind, lässt sich in Salesforce später auch der kaufmännische Prozess anschließen. Die eigentliche Hürde liegt aber davor: in der Frage, ob die Nutzung technisch und fachlich belastbar nachgewiesen werden kann.
Pay-per-Use im Kopf, aber unklar, ob Ihre Flotte die Daten liefert? In 30 Minuten ordnen wir Ihre installierte Basis ein und zeigen am konkreten Beispiel, welche Maschinen heute schon abrechenbar wären – kein Folientermin. → Erstgespräch vereinbaren
Was Hersteller vor der nutzungsbasierten Abrechnung brauchen
Bevor Pay-per-Use im Alltag funktioniert, müssen drei Dinge geklärt sein: eine saubere Asset-Identität, belastbare Nutzungsdaten und ein realistisches Bild der installierten Basis. Dahinter stehen drei einfache, aber geschäftskritische Fragen: Welche Assets sind überhaupt im Feld, welche Daten liefern sie verlässlich, und bei welchen Maschinen reicht die Datenlage schon für eine belastbare Abrechnung?
Eine saubere installierte Basis und eindeutige Asset-Identität
Nutzungsbasierte Abrechnung scheitert oft nicht am Tarif, sondern an der Zuordnung. Wenn Maschinen doppelt erfasst sind, Seriennummern nicht konsistent gepflegt werden oder der Vertragsbezug fehlt, lässt sich Nutzung später nicht sauber abrechnen.
Die digitale Maschinenakte (IOTAM) schafft hier die Grundlage. Für jedes Asset entsteht ein eindeutiger, strukturierter Datensatz, der Konfiguration, Serviceverlauf und Vertragsbezug zusammenführt. Erst damit werden Nutzungswerte einer konkreten Maschine und dem passenden Vertrag zugeordnet. Für Serviceleiter ist das kein IT-Detail, sondern die Bedingung dafür, dass Rechnungen nachvollziehbar bleiben und Rückfragen nicht in tagelanger Klärung enden.
Telemetrie, ERP-Daten und Vertragsdaten in einem Nutzungsmodell
Nutzung kommt nie aus nur einer Quelle. Die Maschine liefert per IoT-Telemetrie etwa Betriebsstunden, Zyklen oder Auslastung. ERP-Daten zeigen den Verbrauch von Materialien. Serviceereignisse geben den nötigen Kontext: Stillstände, Wartungsfenster oder Ausfälle. Dazu kommen Vertragsdaten, die festlegen, welcher Parameter bei welchem Kunden überhaupt abgerechnet werden darf.
Erst wenn diese Daten automatisiert zusammenlaufen, wird Abrechnung wiederholbar. Genau an diesem Punkt wird Salesforce für viele Hersteller interessant: nicht als Selbstzweck, sondern als Ort, an dem Service-, Vertrags- und Asset-Kontext zusammengeführt werden. Wenn zusätzlich Diagnose- oder Prognosefälle bewertet werden müssen, kann Service Decision Intelligence (SDI) als Entscheidungsschicht dienen. Dabei zählt vor allem, dass Empfehlungen mit Quellennachweis ausgegeben werden und Daten auf Wunsch in der Kundeninfrastruktur EU-konform verarbeitet werden können. Das ist gerade bei Streitfällen über Nutzungswerte oder abrechenbare Ausfallzeiten ein handfester Punkt.
Flotten-Realitätscheck vor dem Tarifdesign
Bevor Tarife entworfen werden, braucht die Flotte einen nüchternen Realitätscheck. Welche Maschinentypen sind schon vernetzt? Wo fehlt Telemetrie? Welche Nutzungsmuster lassen sich sauber messen und damit auch abrechnen?
Ein Installed Base Assessment trennt genau hier zwischen abrechenbaren und nicht abrechenbaren Segmenten. Es zeigt Datenlücken, bewertet die Konnektivitätsabdeckung und macht sichtbar, welche Teile der Flotte sofort für ein nutzungsbasiertes Modell taugen und welche erst nachgerüstet werden müssen. In der Praxis sehen wir oft: Der Pilot mit wenigen gut angebundenen Maschinen läuft ordentlich. Schwieriger wird es, sobald ältere Baureihen, unterschiedliche Steuerungen und lückenhafte Stammdaten dazukommen.
Damit ein nutzungsbasiertes Modell trägt, müssen die Daten so belastbar sein, dass alle Beteiligten – Hersteller, Servicepartner und Kunde – ihnen vertrauen. Ohne dieses Vertrauen bleibt jede Abrechnung strittig. Ein Pilot auf wenigen gut vernetzten Maschinen zeigt, dass das Prinzip trägt. Ein belastbares Modell entsteht aber erst dann, wenn sich diese Datenqualität über die Flotte hinweg wiederholen lässt. Genau deshalb ist der Weg nicht Technologie zuerst, sondern Digitalisieren → Vernetzen → Entscheiden → Automatisieren.
Wie SDI fragmentierte Daten für Abrechnung und Forecasts nutzbar macht
Wenn Asset-Identität und Datenquellen stehen, reicht Datensammlung allein nicht aus. Für Abrechnung und Forecasts braucht es eine Logik, die Telemetrie, ERP-Verbrauch und Vertragskontext sauber zusammenführt. Service Decision Intelligence (SDI) übernimmt genau diese Aufgabe. Erst wenn bei einer Flotte gleichartiger Maschinen aus vielen Einzeldaten eine belastbare Linie wird, entsteht daraus ein skalierbares Abrechnungsmodell.
Nachvollziehbare Nutzungsberechnung statt intransparenter Abrechnung
Sobald ein Kunde eine Rechnung auf Basis von Betriebsstunden oder Zyklen erhält, kommt fast immer dieselbe Frage: „Woher kommt dieser Wert?“ Ohne Quellennachweis wird daraus schnell ein Streitfall.
SDI setzt genau an diesem Punkt an. Jeder berechnete Nutzungswert lässt sich bis zu seinem Ursprung zurückverfolgen, also bis zum jeweiligen Telemetrie- oder ERP-Datenpunkt. Das ist für Pay-per-Use kein Detail, sondern die Grundlage. Abrechnung und Forecast greifen damit auf dieselbe Datenbasis zu. Das senkt Abstimmungsaufwand und macht Rechnungen prüfbar statt streitanfällig.
Gerade im Maschinenbau ist das wichtig. Wenn Nutzungswerte nicht sauber belegt sind, beginnt jede Abweichung zwischen Rechnung, Servicebericht und Vertrag eine eigene Diskussion. SDI schafft hier einen klaren Pfad: Wert, Quelle, Berechnung und Zuordnung bleiben nachvollziehbar. Für Serviceleiter heißt das: weniger Klärung im Nachgang, mehr Sicherheit in der laufenden Abrechnung.
Datenhoheit und Vertragskontext als Skalierungsvoraussetzung
Ob Pay-per-Use im Maschinenbau revisionsfähig skaliert oder im Einzelfall stecken bleibt, hängt an zwei Punkten: Datenhoheit und Vertragskontext.
Für viele Unternehmen ist es keine Option, sensible Maschinendaten in fremde Cloud-Umgebungen zu geben. SDI ist daher so angelegt, dass es auf der Infrastruktur des Kunden betrieben werden kann. Das unterstützt EU-konforme Umsetzungen und hält die Hoheit über Daten dort, wo sie hingehört. Hinzu kommt: SDI ist über MCP/BYOM LLM-agnostisch angelegt. Wer Modelle wechseln oder eigene Modelle einbinden will, bleibt handlungsfähig statt sich früh festzulegen.
Ebenso wichtig ist der Vertragskontext. Ein Nutzungswert allein sagt noch nicht, welcher Tarif gilt, welche Sonderregel vereinbart wurde oder ab wann eine Abrechnung greift. Hier kommt GRAX ins Spiel: GRAX sichert CRM- und Vertragshistorie als strukturierten Datenbestand – ohne die API-Limits, die sonst zum Engpass werden können. So bleibt der Kontext für Abrechnungs- und Abstimmungsprozesse vollständig verfügbar, wenn ein Nutzungswert mit dem vertraglich vereinbarten Tarif abgeglichen werden muss.
In Salesforce entsteht daraus kein loses Nebeneinander von Messwert, Vertrag und Prognose, sondern eine gemeinsame Arbeitsbasis. SDI wird damit zur Brücke zwischen Datenbasis, Tarif und Forecast.
Das Betriebsmodell hinter skalierbarem Equipment-as-a-Service
Wenn Nutzung messbar ist, entscheidet das Betriebsmodell über die Skalierung. Nach Datenbasis und Abrechnungslogik folgt auf Stufe 4 das, was in der Praxis oft den Ausschlag gibt: Automatisieren. Pay-per-Use ist keine andere Preisliste. Es ist ein anderes Betriebsmodell. Genau an diesem Punkt zeigt sich der Unterschied zwischen klassischem Verkauf und einem tragfähigen EaaS-Angebot.
Im Vorgehensmodell Digitalisieren → Vernetzen → Entscheiden → Automatisieren liegt der Engpass meist nicht in der Datenerfassung, sondern in der sauberen Ausführung über viele Maschinen, Standorte und Verträge hinweg. Wer Nutzung abrechnet, braucht feste Abläufe für Service, Finance, IT und Vertrieb. Sonst wird aus einem Pilot schnell Mehrarbeit statt Geschäft.
Klassischer Maschinenverkauf vs. nutzungsbasierte Serviceerlöse
Im klassischen Geschäft ist der Verkauf der Abschluss. Beim Equipment-as-a-Service ist er der Anfang. Der Hersteller bleibt in der Verantwortung: für Verfügbarkeit, Wartung und einen belastbaren Datenfluss, auf dessen Basis jede Rechnung entsteht. Damit verschiebt sich Verantwortung in mehrere Bereiche. Skalierbar wird das Modell aber nur über die Flotte, nicht über die Einzelmaschine. Erst die Monetarisierung der installierten Basis macht aus einem Test ein belastbares Geschäft.
| Merkmal | Klassischer Maschinenverkauf | Pay-per-Use / EaaS |
|---|---|---|
| Erlöslogik | Einmalzahlung bei Lieferung | Wiederkehrend, nutzungsabhängig |
| Datenbedarf | Gering (optional für Garantie) | Laufende, prüfbare Telemetrie |
| Servicemodell | Service auf Abruf | Hersteller steuert Wartung |
| Asset-Eigentümer | Kunde | Hersteller oder Finanzierungspartner |
Bei Pay-per-Use verdient der Hersteller nur, wenn die Maschine läuft. Stillstand trifft beide Seiten. Das ändert Wartungsplanung, Eskalationen und die Formulierung von Serviceverträgen. In Salesforce werden diese Abläufe meist erst dann beherrschbar, wenn Vertragsregeln, Nutzungsdaten und Servicefälle in einem gemeinsamen Prozess zusammenlaufen. Für Diagnose- und KI-nahe Entscheidungen ist Service Decision Intelligence (SDI) dabei oft die Schicht, die Empfehlungen mit Quellennachweis absichert und EU-konform in der Kundeninfrastruktur betrieben werden kann.
Reales Beispiel und ein klar gekennzeichnetes typisches Szenario
Das Beispiel zeigt, wie stark sich der Fokus vom Produkt auf die laufende Nutzung verschiebt. KraussMaffei hat mit flexPay einen solchen Ansatz umgesetzt: Kunden zahlen auf Basis tatsächlicher Betriebsstunden, abgerechnet über einen Finanzierungspartner. Pay-per-Use verlagert die Logik damit vom Verkauf hin zu laufender Verfügbarkeit und prüfbarer Nutzung.
Typisches Szenario (kein realer Referenzfall): Ein Serienfertiger mit einer großen, vernetzten Flotte gleichartiger Verarbeitungsmaschinen führt ein nutzungsbasiertes Modell ein. Die Nutzung schwankt je nach Standort und Schichtmodell stark. Erst die Flottendaten erlauben belastbare Tarife und klare Regeln für Stillstand im Vertrag.
Was funktionierende Modelle gemeinsam haben, ist ziemlich nüchtern:
- Die Abrechnungsregeln sind vor dem Start festgelegt.
- Ausnahmen sind vertraglich geregelt.
- Die Daten sind für alle Beteiligten nachvollziehbar.
Fehlt diese Basis, wird jede Rechnung zum möglichen Streitfall. Genau deshalb reicht es nicht, einzelne Maschinen digital anzubinden. Entscheidend ist, ob Hersteller ihre installierte Basis als steuerbares Portfolio führen können, etwa mit einer digitalen Maschinenakte (IOTAM) für den Maschinenkontext und einem Installed Base Assessment für die Einordnung der Flotte in Salesforce.
Fazit: Die Grundlage in der richtigen Reihenfolge aufbauen
Pay-per-Use ist nicht der Startpunkt. Im Maschinenbau ist es das Ergebnis einer installierten Basis, die sauber erfasst, vernetzt und für die Abrechnung nutzbar gemacht wurde. Die Reihenfolge ist klar: Digitalisieren → Vernetzen → Entscheiden → Automatisieren. Fehlt diese Grundlage, bleibt jede Tariflogik ein Rechenmodell ohne belastbare Belege.
Nutzungsbasierte Abrechnung steht und fällt mit verlässlichen, nachvollziehbaren Nutzungsdaten – über Systemgrenzen hinweg und mit Quellennachweis. Genau hier setzt Service Decision Intelligence (SDI) an: SDI verbindet Telemetrie, ERP-Verbrauch und Vertragskontext zu einer prüfbaren Basis für Abrechnung und Forecast. Für Serviceleiter und Geschäftsführung zählt dabei nicht das Preismodell allein, sondern die Frage, ob sich jede Abrechnungsposition belegen lässt. Vertrauen entsteht durch prüfbare Daten, nicht durch Preislogik.
So wird die installierte Basis über ihren gesamten Lebenszyklus zum Wachstumstreiber – bis hin zu Strategien für das End-of-Life und den späten Lebenszyklus. Der Einstieg ist deshalb kein Tarifmodell, sondern eine Flottenprüfung. Zwei pragmatische Wege:
- Installed Base Assessment – wenn unklar ist, welche Maschinen vernetzt sind und welche Nutzungsdaten belastbar sind. Es trennt abrechenbare von nicht abrechenbaren Segmenten und zeigt, wo nachgerüstet werden muss.
- Erstgespräch – wenn die Datenbasis steht und Sie das Nutzungs- und Abrechnungsmodell für Ihre Flotte konkret durchsprechen wollen.
FAQs
Ab wann lohnt sich Pay-per-Use im Maschinenbau?
Pay-per-Use im Maschinenbau trägt vor allem dann, wenn zuverlässige Nutzungsdaten vorliegen und eine große, vernetzte, gleichartige Maschinenflotte im Feld steht. Nur unter diesen Bedingungen lässt sich Nutzung messbar, nachvollziehbar und abrechnungsfähig machen. Für Serienfertiger mit hohen Stückzahlen und unterschiedlichen Lastprofilen ist das Modell oft besonders interessant: Je ähnlicher die Maschinen aufgebaut sind und je sauberer die Daten erfasst werden, desto eher lässt sich ein nutzungsbasierter Preis ohne Streit über Messwerte umsetzen. Fehlt diese Datenbasis, wird Pay-per-Use schnell zum Risiko. Genau hier beginnt die Arbeit mit der digitalen Maschinenakte (IOTAM) und dem Reifegradmodell Digitalisieren → Vernetzen → Entscheiden → Automatisieren: erst Daten sauber erfassen, dann Maschinen anbinden, darauf Nutzung bewerten und erst danach Abrechnung schrittweise automatisieren.
Welche Daten brauche ich für nutzungsbasierte Abrechnung?
Für nutzungsbasierte Abrechnung im Maschinenbau zählen verlässliche und prüfbare Nutzungsdaten. Ohne diese Basis wird jede Abrechnung angreifbar – intern, beim Kunden und im Service. Meist geht es um Betriebsstunden, produzierte Stückzahlen oder die tatsächliche Maschinenlaufzeit. Hinzu kommen technische Parameter wie Temperatur, Weg, Prozesskräfte oder Verschleißindikatoren. Die Erfassung läuft in der Regel über Telemetrie, doch Sensordaten allein reichen selten: Für eine belastbare Abrechnung müssen auch ERP-Verbrauchsdaten und weitere Quellen einbezogen werden. Service Decision Intelligence (SDI) übernimmt hier die Rolle der Intelligenzschicht und stellt den Bezug zur einzelnen Maschine her. Für Entscheider zentral: Datenhoheit und Quellennachweis – es darf nicht offenbleiben, aus welcher Quelle ein Wert stammt und wie er in die Abrechnung eingeflossen ist.
Wie starte ich mit einer unvollständig vernetzten Flotte?
Starten Sie mit einer Bestandsaufnahme der installierten Basis: Welche Maschinen lassen sich bereits vernetzen, und wie belastbar ist die Datenlage? Auf dieser Grundlage erkennen Sie, wo sich erste Nutzungsdaten sauber und verlässlich erfassen lassen. Gehen Sie anschließend mit dem vernetzbaren Teil der Flotte in die Umsetzung und bauen Sie Datenschnittstellen Schritt für Schritt aus. Entscheidend ist eine klare Quellennachweisbarkeit der Nutzungsdaten. Für die Einordnung hilft ein klarer Reifegradpfad: Digitalisieren → Vernetzen → Entscheiden → Automatisieren. Er verhindert, dass Abrechnungsmodelle zu früh versprochen werden, obwohl Datentiefe, Geräteanbindung oder Nachweisführung noch Lücken haben.
