Der Batteriepass hat einen QR-Code. Wer pflegt ihn nach dem ersten Service?

Ein deutscher Speicheranbieter hat die Produktdaten gesammelt und eine Passseite veröffentlicht. Nach einer Reparatur liegt der Werkstattbericht in einem anderen System. Eine Komponente wurde getauscht, die Batterie steht beim Kunden wieder im Betrieb, und niemand weiß genau, welcher Datensatz jetzt aktualisiert werden muss. Der sichtbare QR-Code funktioniert weiterhin. Die Informationskette dahinter ist unterbrochen.

Wer Batteriepass-Software beschafft, sollte deshalb eine praktische Frage stellen: Wie erreicht ein späteres Ereignis den richtigen Datensatz, und wer bestätigt seine Bedeutung? Für Hersteller und Serviceorganisationen entsteht hier ein konkretes Integrationsprojekt. Es verbindet bestehende Systeme mit einem nachvollziehbaren Lebenslauf, ohne jede Notiz ungeprüft nach außen zu veröffentlichen.

Beginnen Sie mit dem Lebenslauf einer einzelnen Batterie

Die EU-Batterieverordnung, insbesondere Artikel 77 und 78, unterscheidet Anforderungen an den Pass, Verantwortlichkeiten und technische Eigenschaften. Der konkrete Geltungsbereich muss zur Batteriekategorie und Unternehmensrolle geprüft werden. Die Software sollte diese Prüfung unterstützen und keine pauschale Zusage erzeugen, dass ein bestimmtes Portal sämtliche Pflichten erfüllt.

Modellieren Sie zuerst eine Batterie vom Eingang ihrer Stammdaten bis zu einem späteren Servicefall. Notieren Sie Herstellerkennung, interne Seriennummer und die Kennungen der angeschlossenen Systeme. Wenn ein Gerät im ERP anders bezeichnet wird als im Werkstattbericht, benötigen Sie eine kontrollierte Zuordnung. Ein unscharfer Namensvergleich darf keine Lebensläufe zusammenführen.

Erfassen Sie auch den Unterschied zwischen Modellinformationen und Angaben zu einem konkreten Exemplar. Ein geändertes Datenblatt beschreibt nicht automatisch jede bereits ausgelieferte Batterie. Umgekehrt sollte ein individueller Reparaturvorgang nicht unbemerkt die gesamte Produktserie verändern. Diese Trennung bestimmt Datenmodell, Benutzeroberfläche und spätere Integrationskosten.

Ein Servicebericht ist zunächst eine Quelle

Ein Techniker dokumentiert einen Komponententausch. Daraus entstehen mehrere mögliche Informationen: Der Auftrag wurde ausgeführt, ein Teil wurde verbaut, eine Prüfung wurde vorgenommen. Nicht jede Information gehört unverändert in jede Ansicht. Bewahren Sie den Originalbeleg mit Herkunft und Erfassungszeit auf und leiten Sie daraus ausdrücklich gekennzeichnete Änderungsvorschläge ab.

Die Anwendung sollte sichtbar machen, wer einen Vorschlag eingereicht, geprüft und übernommen hat. Eine spätere Korrektur ersetzt nicht stillschweigend den früheren Stand. Sie ergänzt eine nachvollziehbare Änderung mit Begründung. So kann eine zuständige Person erklären, warum ein Merkmal heute anders lautet als zum Zeitpunkt einer früheren Übergabe.

Verwenden Sie für den Pilot reale, freigegebene Servicefälle mit typischen Unklarheiten. Dazu gehören unlesbare Kennungen, nachgereichte Belege und Aufträge, die mehrere Geräte betreffen. Solche Fälle zeigen schneller als eine perfekte Demonstration, welche manuellen Entscheidungen das System benötigt und welche Informationen beim Partner tatsächlich verfügbar sind.

Vergeben Sie Datenrechte entlang der Zusammenarbeit

Ein Lieferant muss möglicherweise technische Informationen liefern, während eine Werkstatt nur ihre eigenen Aufträge sehen soll. Eine öffentliche Produktseite benötigt nochmals einen anderen Ausschnitt. Die technische Orientierung des Battery Pass-Projekts behandelt die technische Umsetzung des Passes. Sie ist eine Projektquelle und ersetzt keine individuelle rechtliche Einordnung.

Legen Sie Rechte für Lesen, Einreichen, Prüfen und Veröffentlichen getrennt fest. Eine erfolgreiche Anmeldung eines Partners ist noch keine Berechtigung, alle Batterien eines Herstellers zu verändern. Der Zugriff sollte auch dann enden, wenn ein Servicevertrag ausläuft oder eine Person das Partnerunternehmen verlässt. Bereits veröffentlichte Änderungen müssen dabei weiterhin nachvollziehbar bleiben.

Für sensible Unterlagen ist eine direkte, berechtigte Ansicht oft geeigneter als ein frei weiterleitbarer Downloadlink. Protokollieren Sie wichtige Zugriffe und Änderungen, ohne vertrauliche Inhalte unnötig in technische Logs zu kopieren. Vereinbaren Sie außerdem, wie Belege exportiert und nach den festgelegten Aufbewahrungsregeln behandelt werden.

Planen Sie Synchronisation für den unordentlichen Alltag

ERP und Serviceplattform melden Änderungen nicht immer in derselben Reihenfolge. Ein Werkstattauftrag kann eintreffen, bevor die zugehörige Batterie in der Passanwendung bekannt ist. Speichern Sie diesen Vorgang als zu klärende Zuordnung. Das System darf ihn weder verlieren noch automatisch einer ähnlich benannten Batterie zuweisen.

Wiederholte Übertragungen dürfen keine zusätzlichen Reparaturen erzeugen. Dafür braucht jeder Vorgang eine stabile externe Kennung und einen definierten Umgang mit Korrekturen. Zeigen Sie den Integrationsstatus fachlich verständlich an: angekommen, zugeordnet, prüfbedürftig oder veröffentlicht. Eine grüne API-Verbindung sagt allein wenig darüber aus, ob ein konkreter Servicefall vollständig verarbeitet wurde.

Auch ein Anbieterwechsel gehört in die Architektur. Lassen Sie einen exportierten Lebenslauf einschließlich Kennungen, Quellenverweisen und Änderungshistorie in einer getrennten Testumgebung wieder einlesen. Wenn sich nur die aktuelle Passseite exportieren lässt, fehlt ein erheblicher Teil des betrieblichen Wissens, das Ihr Team zuvor aufgebaut hat.

So wird aus dem Trend ein abnehmbarer erster Auftrag

Ein sinnvoller Start umfasst eine Batteriefamilie, eine Serviceorganisation und einen klar abgegrenzten Ereignistyp. Das Projekt liefert eine Datenzuordnung, eine Partneransicht, eine Prüfliste und einen kontrollierten Veröffentlichungsweg. Weitere Standorte oder Ereignistypen kommen hinzu, wenn dieser Ablauf mit tatsächlichen Belegen funktioniert.

Prüfen Sie bei der Abnahme insbesondere diese Situationen:

• Ein Servicebeleg nennt eine unbekannte Seriennummer und landet in einer Klärungsliste.
• Eine doppelte Übertragung erzeugt keinen zweiten Vorgang.
• Ein Partner sieht ausschließlich die für ihn freigegebenen Batterien.
• Eine Korrektur lässt den zuvor veröffentlichten Stand nachvollziehen.
• Ein ERP-Ausfall verhindert keine sichere Zwischenspeicherung eingegangener Belege.
• Ein Export lässt sich einer Batterie und ihren Quellen eindeutig zuordnen.

Für die Budgetierung zählen Schnittstellenzugang, Datenqualität und Zahl der beteiligten Rollen stärker als die Gestaltung des QR-Codes. Fragen Sie einen Entwicklungspartner nach einem konkreten Ablaufdiagramm und einer Liste offener Datenfragen. Ein realistisches Angebot benennt auch die Stellen, an denen Ihr Fachteam entscheiden oder Informationen bereitstellen muss.

Unser Beitrag zur fachlichen Freigabe von ERP-Daten erklärt ähnliche Kontrollpunkte. Die Übergabe individueller Software an einen neuen Dienstleister ergänzt die langfristige Perspektive. Innovation T verbindet solche Prozesse über seine Softwareleistungen. Besprechen Sie eine Batterie, einen Servicefall und die beteiligten Systeme, damit der erste Projektumfang auf Ihrer tatsächlichen Datenkette beruht.

Häufige Fragen

Reicht eine öffentlich erreichbare QR-Code-Seite für den Batteriepass?

Eine Seite kann Informationen zugänglich machen. Welche Daten, Rechte und technischen Eigenschaften erforderlich sind, ergibt sich aus dem anwendbaren Regelwerk und der jeweiligen Rolle. Ein QR-Code allein organisiert keine laufende Datenpflege.

Muss dafür das bestehende ERP ersetzt werden?

Häufig kann eine ergänzende Anwendung Daten aus ERP, Service und Lieferantensystemen verbinden. Entscheidend sind eindeutige Batteriekennungen, verantwortliche Datenquellen und ein überprüfbarer Änderungsprozess.

Darf jeder Servicepartner alle Angaben im Pass bearbeiten?

Nein. Lese- und Änderungsrechte sollten nach Rolle, Auftrag und Datenart abgegrenzt werden. Ein eingereichter Servicebeleg kann zunächst einen Prüfauftrag erzeugen, statt unmittelbar den veröffentlichten Datenstand zu ändern.