vise Data Run · alltägliche Datenänderungen
Fachbereiche bereiten Massenänderungen in SAP vor. Die IT behält die Kontrolle.
Massenänderungen an Materialien, Lieferanten, Preisen, Instandhaltungs- und Geschäftspartnerdaten – validiert, probeweise durchlaufen, von einer namentlich benannten Person freigegeben und über Standardschnittstellen von SAP eingespielt, der Audit-Trail entsteht automatisch. Ihr Ticketsystem bleibt, wo es ist; was sich ändert, ist alles nach dem Ticket. SAP ECC und S/4HANA; auch IBM Maximo.
- Produktiv
- bei einer globalen Brauereigruppe, auf SAP
- Jedes Einspielen
- erst als Probelauf über die echte Schnittstelle
- Vier Augen
- Anfragender, Data Owner, Validierer, Ausführender – getrennte Rollen
01 · Das Problem
Die meisten SAP-Datenprobleme entstehen nicht durch eine fehlende Transaktion.
Sie entstehen im Prozess um die Daten: Tabellen, Freigaben per E-Mail, manuelle Massenänderungen, Markt für Markt wiederholt, und mehr als zehn Korrekturrunden zwischen Fachbereich und IT je Datei. Eine kleine Gruppe von Spezialisten steht zwischen jeder regionalen Änderung und dem Produktivsystem. Nichts ist wiederverwendbar. Nichts ist prüfbar.
01Keine zentrale TransparenzKein Nachweis, wer was geändert hat; Validierung in jedem Markt anders; ein schwacher Audit-Trail.
02Wiederholter manueller AufwandDieselbe Routine aus Tabelle und E-Mail in jedem Markt, in jedem Zyklus, ohne dass etwas übernommen wird.
03Spezialisten als EngpassWarteschlangen vor einigen wenigen SAP-Experten; der Fachbereich wartet, Experten formatieren Tabellen, statt Daten zu steuern.
02 · Die sechs Schritte
Vor SAP validiert. Währenddessen kontrolliert. Danach prüfbar.
- Schritt 01 · RequestEine Excel-Vorlage, kein Freitext-Ticket.Fachanwender füllen eine standardisierte Vorlage für Objekt und Szenario aus – Material, Lieferant, Preis, Equipment, Geschäftspartner. Scope, Regeln, Risikostufe und Einspielfenster reisen mit der Datei. Ihr Ticketsystem bleibt, wo es ist; die Anfrage kommt in einer Form an, die die nächsten Schritte prüfen können.
- Schritt 02 · ValidateGegen SAP-Referenzdaten und Ihre Regeln geprüft, bevor sie in die Nähe von SAP kommt.Pflichtfelder, Typen, zulässige Werte, feldübergreifende Abhängigkeiten, Dubletten, Referenzen und Geschäftslogik. Fehler kommen je Zeile mit Begründung zurück, sodass der Anfragende sie korrigiert, bevor jemand in der IT die Datei ansieht.
- Schritt 03 · SimulateProbelauf über die echte Schnittstelle.Die Änderung läuft als Testaufruf gegen das Zielsystem – dieselbe BAPI, dasselbe IDoc oder OData wie beim echten Einspielen, im Testmodus ohne Commit; für IBM Maximo der Connector. Es antworten Ihr aktuelles Customizing und Ihre Referenzdaten, keine Kopie davon. Der Probelauf schreibt nie. Was er ablehnt, kommt je Zeile vor dem Einspielen zurück; was er durchlässt, ist so nah am echten Einspielen, wie SAP es zulässt – und das echte Einspielen läuft trotzdem mit Fehlerbehandlung je Datensatz.
- Schritt 04 · ApproveVier Augen, nach Rolle, mit Namen.Anfragender, Data Owner, Validierer, Ausführender und Admin sind getrennte Rollen. Nichts wird eingespielt ohne eine Freigabe mit Benutzer und Zeitpunkt.
- Schritt 05 · LoadKontrollierte Ausführung: Batches, Monitoring, Korrektur-Queue.Einspielen über standardisierte, von SAP unterstützte Schnittstellen – nie direkt in eine Tabelle –, sodass die eigenen Prüfungen von SAP, Nummernkreise und Änderungsbelege aktiv bleiben. Ausführungsprotokolle je Batch; fehlerhafte Datensätze gehen in eine Korrektur-Queue, der Rest läuft weiter.
- Schritt 06 · AuditWer, wann, was, mit welcher Datei, mit welchem Ergebnis.Quelldatei, Einreichender, Validierungsergebnisse, Freigaben, Ausführungsstatus und die Antworten des Systems werden für jeden Lauf aufbewahrt. Abstimmung und Änderungsprotokoll je Anfrage – das Paket, das ein Prüfer verlangt, entsteht als Nebenprodukt.
03 · Was der Bearbeiter sieht
Eine Datei, ein Trail: wer sie eingecheckt hat, was die Validierung ergab, wann sie geladen wurde.
Jede Änderung ist eine Datei zu einem Objekt. Die Objektseite listet die laufenden Dateien mit Status und letztem Ergebnis; die Dateiansicht zeigt die Validierung je Arbeitsblatt und den Ladevorgang, mit Name und Zeitpunkt bei jedem Schritt. Keine Tabelle im E-Mail-Anhang, kein „Wer hat das ausgeführt?“.
04 · Fallstudie · SAP Plant Maintenance
Fünf PM-Objektgruppen, standardisiert über mehr als zehn europäische Märkte.
Eine globale Brauereigruppe – unser langjährigster Kunde –, die SAP in 15 Ländern in Europa und darüber hinaus betreibt, hat Tabellen, Freigaben per E-Mail und manuelle Massenänderungen durch vise Data Run ersetzt: zentrale Governance, lokale Datenverantwortung, 16 geschulte Expert User in vier regionalen Clustern. Endanwender bereiten ihre eigenen Daten über standardisierte Excel-Vorlagen vor und laden sie – kein ABAP, keine Individualentwicklung je Änderung. Neue Märkte übernehmen Prozesse, die anderswo bereits konfiguriert und getestet sind.
Zur Fallstudie| Objektgruppe | Scope |
|---|---|
| Equipment | Stammsätze, Attribute, Planergruppen, Arbeitsplätze, Namenskonventionen |
| Equipment-Stückliste | Komponenten, Positionsdaten, Verknüpfungen zum übergeordneten Equipment |
| Technische Plätze | Hierarchie, Strukturkennzeichen, Organisationsdaten, Namenskonventionen |
| Wartungspläne | Terminierungsparameter, Zyklen, Positionen, Abgleich mit zentralen Strategien |
| Arbeitspläne | Vorgänge, Arbeitsplätze, Steuerschlüssel, Dauern, über Märkte harmonisiert |
05 · Für SAP-Anwendungsverantwortliche
Was in Ihrem SAP-System passiert.
Die Fragen, die Basis, Security und Audit vor einem Pilot stellen – jedes Mal gleich beantwortet.
- 01Verbindung und Identität
- Data Run spielt über die Standardschnittstellen von SAP ein, unter einem Schnittstellenbenutzer, den Ihr Basis-Team anlegt und einschränkt – Objekte, Werke, Buchungskreise –, so wie jede Integration eingeschränkt wird. Kein Tabellenzugriff, kein individuelles ABAP je Änderung. Die SAP-Änderungsbelege tragen diesen Benutzer; der Trail von Data Run trägt den namentlichen Anfragenden, Freigebenden und Ausführenden hinter jedem Lauf.
- 02Validierung und Probelauf
- Zuerst Regeln (Format, Pflichtfelder, zulässige Werte, feldübergreifend, Dubletten), dann ein Testaufruf an SAP mit denselben BAPIs, ohne Commit – Ihr Customizing und Ihre Referenzdaten so, wie sie in diesem Moment sind. Während der Validierung wird nichts geschrieben. Weil sich Referenzdaten zwischen Validierung und Einspielen ändern können, läuft das Einspielen selbst trotzdem mit Fehlerbehandlung je Datensatz.
- 03Freigabe und Funktionstrennung
- Anfragender, Data Owner, Validierer, Ausführender und Admin sind getrennte Rollen, je Standort vergeben. Welche Person welche Rolle haben darf – und ob ein Anfragender jemals freigeben darf –, ist Ihre Konfigurationsentscheidung, die wir mit Ihnen in die Einrichtung schreiben, kein Standard, den wir für Sie wählen. Jede Freigabe trägt Benutzer und Zeitpunkt.
- 04Ausführung und Teilfehler
- Einspielungen laufen in Batches mit Ausführungsprotokollen. Ein abgelehnter Datensatz geht mit der SAP-Meldung in die Korrektur-Queue; der Rest des Batches läuft weiter; korrigierte Datensätze werden erneut eingespielt. Massenänderungen an Stammdaten lassen sich in SAP nicht „rückgängig machen“, daher ist das Modell der Änderungsmodus mit der vorherigen Datei als Referenz – kein Rollback-Versprechen.
- 05Wo die Historie liegt
- In Data Run: jede Dateiversion, wer sie eingecheckt hat, Validierungsergebnisse je Arbeitsblatt, Freigaben, Ausführungsstatus und die Antworten von SAP, je Anfrage. In SAP: die Änderungsbelege, die SAP selbst schreibt. Die Aufbewahrung folgt Ihren Projekteinstellungen; der Trail ist für eine Prüfanfrage exportierbar.
- 06Wer die Regeln pflegt
- Validierungsregeln und Wertelisten sind Konfiguration je Objekt und Standort. Ihr Data Steward pflegt sie nach dem Onboarding; neue Objekte und nicht standardmäßige Geschäftsregeln richten wir gemeinsam ein – im Pilot sehen Sie, wo die Konfiguration endet und die Einrichtungsarbeit beginnt.
06 · Passt zu dem, was Sie haben
Nichts in Ihrer Landschaft wird ersetzt.
EingangIhr Ticketsystem bleibtServiceNow, Jira, E-Mail – die Anfrage wird dort gestellt, wo sie heute gestellt wird. Die Vorlage ist die Übergabe: Sie trägt Scope, Regeln, Risikostufe und Einspielfenster in Data Run.
ZielNur StandardschnittstellenSAP ECC und S/4HANA über BAPI, IDoc und OData; IBM Maximo über den Connector. Die eigenen Prüfungen von SAP, Nummernkreise, Berechtigungen und Änderungsbelege bleiben aktiv – für SAP sieht das Einspielen aus wie jedes andere.
RegelnEinmal geschrieben, wiederverwendetValidierungsregeln und Wertelisten werden je Objekt und Standort ohne Code konfiguriert. Wenn Sie mit vise DMW migriert haben, werden die Regeln und Listen aus der Migration übernommen; vise LoV-MAP hält die Wertelisten aktuell.
07 · Betriebsmodelle
Selbst betreiben, mit uns oder durch uns.
01Ihre IT betreibt esVisehub übernimmt Einrichtung, Vorlagen und Onboarding; Ihr Team betreibt. Support optional.
02HybridIhre IT behält Architektur und Freigaben; Visehub übernimmt Validierung, Ausführung und Lieferung.
03Externe Ausführung + Support im TeamVisehub als Ihr Team für die Datenausführung unter SLA, mit einem Berater in Vollzeit auf Ihrem Teams. Das Modell, das unser langjährigster Kunde seit Jahren nutzt.
Produktiv
Kunden Globale Brauereigruppe – alltägliche Änderungen für Landesgesellschaften der ganzen Gruppe: Instandhaltung, Geschäftspartner, FI/CO. Externe Ausführung mit einem Visehub-Spezialisten im Team auf Teams.
08 · FAQ
Fragen, die wir bekommen.
- 01Wir nutzen bereits ServiceNow. Müssen wir es ersetzen?
- Nein. ServiceNow, Jira oder E-Mail bleiben für den Eingang der Anfragen; vise Data Run standardisiert, was nach dem Ticket passiert – Vorlage, Validierung, Probelauf, Freigabe und Einspielen. Die Übergabe ist die Vorlage am Ticket; eine direkte Integration von Ticket zu Anfrage steht auf der Roadmap, ist heute nicht im Produkt, und das sagen wir, bevor Sie damit planen.
- 02Wir haben schon Skripte für Massenänderungen.
- Ein gutes Skript kann validieren und protokollieren. Was ihm selten fehlt, ist der Prozess drumherum: eine Vorlage, die der Fachbereich ausfüllen kann, ein Probelauf vor jedem Einspielen, eine Freigabe durch eine getrennte Rolle und ein Audit-Trail für jeden Lauf – einmal gepflegt, nicht je Skript, und unabhängig von der Person, die es geschrieben hat. Data Run behält die Geschwindigkeit eines Skripts und standardisiert den Rest.
- 03Welche Systeme?
- SAP ECC und S/4HANA über BAPI, IDoc und OData; IBM Maximo über einen Connector; Microsoft Dynamics 365 Business Central und Dynamics NAV über deren APIs und Webservices. Jedes andere System, das eine API oder Webservices bereitstellt, lässt sich auf dieselbe Weise anbinden.
- 04Welche Objekte sind bereits einsatzbereit?
- Heute produktiv im Einsatz: Instandhaltung (Equipments, Technische Plätze, Wartungspläne, Arbeitspläne, Stücklisten); Material (Fertigerzeugnisse, Verpackungen und Rohstoffe); Partner (Kunde, Lieferant, Geschäftspartner in S/4HANA mit CVI); Finanzwesen und Controlling (Sachkonten, Kostenstellen, Kostenarten, Profit-Center, Leistungsarten, Banken, FI-Belege); Änderungen an Kundenaufträgen. Weitere Objekte kommen über Vorlagen, Wertelisten und Validierungsregeln hinzu, ohne Änderungen an der Plattform.
- 05Eine Änderung über mehrere Systeme?
- Eine Anfrage hat ein Zielsystem. Eine Änderung, die SAP und ein weiteres System betrifft, läuft als verknüpfte Anfragen unter einer gemeinsamen Referenz, jede im eigenen System validiert, freigegeben und eingespielt.
- 06Lässt sich eine Änderung zurücknehmen?
- Nicht per Knopfdruck. SAP macht Massenänderungen an Stammdaten nicht rückgängig, daher ist eine Rücknahme eine neue Änderungsanfrage auf Basis der vorherigen Datei – mit derselben Validierung, demselben Probelauf, derselben Freigabe und demselben Einspielen. Felder, die SAP sperrt, sobald Bewegungsdaten existieren – etwa eine Basismengeneinheit bei vorhandenem Bestand –, lassen sich nicht zurückändern, und der Probelauf zeigt das, bevor etwas geschrieben wird.
- 07Ist Data Run eine allgemeine Workflow- oder Orchestrierungs-Engine?
- Nein, und wir positionieren es auch nicht so. Es ist eigens für gesteuerte Datenänderungen gebaut: Der Fachbereich beschreibt die Änderung in einer Vorlage, die Plattform validiert sie, eine freigebende Person gibt sie frei, das Einspielen wird ausgeführt und protokolliert.
- 08Wie lange, bis es läuft?
- Ein 30-tägiger Pilot an einem Anwendungsfall – ein Objekt, ein Land –, dann Ausbau Objekt für Objekt. Die meiste Zeit fließt in Ihre Regeln, nicht in die Installation: Es läuft in der Cloud und braucht einen Browser und eine sichere Verbindung.
- 09Was brauchen wir für den Pilot?
- Ein Objekt und ein Land – die Änderung, vor der Ihr Team am meisten zurückschreckt. Auf Ihrer Seite: ein Data Owner, der die Regeln kennt, ein SAP- (oder Maximo-)Testsystem mit einem Benutzer für die Standardschnittstelle und eine sichere Verbindung. Wir bauen Vorlage und Regeln, führen Validierung und Probelauf mit Ihrem Team durch und spielen die erste echte Änderung nach dem Vier-Augen-Prinzip ein. Festpreis für die 30 Tage. Was Sie messen: Bearbeitungszeit je Anfrage vorher und nachher, Korrekturen durch Ihre Spezialisten, von der Validierung vor SAP abgefangene Fehler und ob der Audit-Trail die Fragen Ihres Prüfers ohne Tabelle beantwortet.
- 10Was bestimmt die Kosten nach dem Pilot?
- Standorte und Benutzerkonten im Scope (Admin und Standard) sowie das Betriebsmodell – Ihre IT betreibt es, hybrid, oder Visehub betreibt es unter SLA. Je mehr Standorte, desto niedriger der Preis je Standort. Fragen Sie nach dem Modell, das zu Ihrem Volumen passt; wir veröffentlichen keine Preisliste.
- 11Ist das dasselbe wie vise DMW?
- Dieselbe Validierungsdisziplin, eine andere Aufgabe. vise DMW führt Migrationsprogramme und Datenqualität vor dem Go-live; Data Run führt die wiederkehrenden Änderungen nach dem Go-live. Validierungsregeln und Wertelisten, die während der Migration in DMW entstanden sind, werden danach in Data Run wiederverwendet.
Ein Anwendungsfall, ein Land, 30 Tage.
Wählen Sie die Änderung, vor der Ihr Team am meisten zurückschreckt. Wir bauen die Vorlage, validieren, machen den Probelauf und spielen nach dem Vier-Augen-Prinzip ein – dann entscheiden Sie, wie weit skaliert wird. Ihre Seite: ein Data Owner, ein Testsystem mit Schnittstellenbenutzer, eine sichere Verbindung. Festpreis für die 30 Tage; Sie messen Bearbeitungszeit, Korrekturen durch Spezialisten und was die Validierung abgefangen hat.