vise Data Run · každodenní změny dat
Byznysové týmy připravují hromadné změny v SAP. IT si drží kontrolu.
Hromadné změny materiálů, dodavatelů, cen, dat údržby a obchodních partnerů – validované, ověřené zkušebním během, schválené jmenovitě určenou osobou a zapsané přes standardní rozhraní SAP; auditní stopa vzniká sama. Váš ticketovací systém zůstává, kde je; mění se všechno po ticketu. SAP ECC a S/4HANA; také IBM Maximo.
- V produkci
- u globální pivovarnické skupiny, na SAP
- Každý zápis
- nejdřív zkušební běh přes skutečné rozhraní
- Čtyři oči
- žadatel, vlastník, validátor, vykonavatel – oddělené role

01 · Problém
Většina problémů s daty SAP nevzniká kvůli chybějící transakci.
Vznikají v procesu kolem dat: tabulky, schvalování e-mailem, ruční hromadné aktualizace opakované trh po trhu a více než deset kol oprav mezi byznysem a IT na jeden soubor. Malá skupina specialistů stojí mezi každou regionální aktualizací a produkčním systémem. Nic se nedá znovu použít. Nic se nedá auditovat.
02 · Šest kroků
Zvalidováno před SAP. Řízeno během zápisu. Auditovatelné po něm.
- Krok 01 · RequestŠablona v Excelu, ne ticket s volným textem.Byznysoví uživatelé vyplní standardizovanou šablonu pro daný objekt a scénář – materiál, dodavatel, cena, zařízení, obchodní partner. Rozsah, pravidla, úroveň rizika a okno nasazení putují se souborem. Váš ticketovací systém zůstává, kde je; požadavek dorazí ve formě, kterou mohou další kroky zkontrolovat.
- Krok 02 · ValidateZkontrolováno vůči referenčním datům SAP a vašim pravidlům dřív, než se to k SAP vůbec přiblíží.Povinná pole, typy, povolené hodnoty, závislosti mezi poli, duplicity, reference a byznysová logika. Chyby se vracejí po řádcích s důvodem, takže je žadatel opraví dřív, než se na soubor podívá kdokoli z IT.
- Krok 03 · SimulateZkušební běh přes skutečné rozhraní.Změna se spustí vůči cílovému systému jako testovací volání – stejné BAPI, IDoc nebo OData, jaké použije skutečný zápis, v testovacím režimu bez commitu; u IBM Maximo přes konektor. Odpovídá váš živý customizing a referenční data, ne jejich kopie. Zkušební běh nikdy nezapisuje. Co odmítne, vrátí se po řádcích ještě před zápisem; co propustí, je skutečnému zápisu tak blízko, jak to SAP dovolí, a skutečný zápis stále běží se zpracováním chyb po záznamech.
- Krok 04 · ApproveČtyři oči, podle rolí, se jménem.Žadatel, vlastník dat, validátor, vykonavatel a administrátor jsou oddělené role. Nic se nezapíše bez schválení, u kterého je uveden uživatel a čas.
- Krok 05 · LoadŘízené provedení: dávky, monitoring, fronta oprav.Zápis přes standardní rozhraní podporovaná SAP – nikdy přímý zápis do tabulky – takže vlastní kontroly SAP, číselné intervaly a změnové doklady zůstávají aktivní. Protokoly provedení za každou dávku; neúspěšné záznamy jdou do fronty oprav, zatímco zbytek pokračuje.
- Krok 06 · AuditKdo, kdy, co, nad kterým souborem, s jakým výsledkem.Zdrojový soubor, předkladatel, výsledky validace, schválení, stav provedení a odpovědi systému se uchovávají pro každý běh. Rekonciliace a protokol změn za každý požadavek – balíček, o který žádá auditor, vzniká jako vedlejší produkt.
03 · Co vidí operátor
Jeden soubor, jedna stopa: kdo ho nahrál (check-in), co řekla validace, kdy byl nahrán do systému.
Každá změna je soubor vázaný na objekt. Stránka objektu uvádí rozpracované soubory s jejich stavem a posledním výsledkem; pohled na soubor ukazuje validaci podle listů a nahrání, se jménem a časem u každého kroku. Žádná tabulka v příloze e-mailu, žádné „kdo to spustil?“.
04 · Případová studie · SAP Plant Maintenance
Pět skupin objektů PM, standardizovaných na více než deseti evropských trzích.
Globální pivovarnická skupina – zákazník, se kterým spolupracujeme nejdéle – provozující SAP v 15 zemích v Evropě i mimo ni nahradila tabulky, schvalování e-mailem a ruční hromadné aktualizace nástrojem vise Data Run: centrální řízení, lokální vlastnictví dat, 16 vyškolených expertních uživatelů ve čtyřech regionálních klastrech. Koncoví uživatelé si data připravují a nahrávají sami přes standardizované šablony v Excelu – bez ABAP, bez zakázkového vývoje pro každou změnu. Nové trhy přebírají procesy už nakonfigurované a otestované jinde.
Přečtěte si případovou studii| Skupina objektů | Rozsah |
|---|---|
| Zařízení | Kmenové záznamy, atributy, skupiny plánovačů, pracoviště, konvence pojmenování |
| Kusovník zařízení | Komponenty, data položek, vazby na nadřazené zařízení |
| Technická místa | Hierarchie, strukturní indikátory, organizační data, konvence pojmenování |
| Plány údržby | Parametry termínování, cykly, položky, soulad s centrálními strategiemi |
| Pracovní postupy | Operace, pracoviště, řídicí klíče, doby trvání, sjednoceno napříč trhy |
05 · Pro správce aplikací SAP
Co se děje ve vašem systému SAP.
Otázky, které Basis, bezpečnost a audit kladou před pilotem – a odpovídáme na ně pokaždé stejně.
- 01Připojení a identita
- Data Run zapisuje přes standardní rozhraní SAP pod uživatelem rozhraní, kterého vytvoří a vymezí váš tým Basis – objekty, závody, účetní okruhy – stejně jako se vymezuje každá integrace. Žádný přístup k tabulkám, žádný zakázkový ABAP pro každou změnu. Ve změnových dokladech SAP je uveden tento uživatel; ve stopě Data Run je u každého běhu jmenovitě uveden žadatel, schvalovatel a vykonavatel.
- 02Validace a zkušební běh
- Nejprve pravidla (formát, povinná pole, povolené hodnoty, vazby mezi poli, duplicity), poté testovací volání do SAP stejnými BAPI, bez commitu – váš customizing a referenční data tak, jak v tu chvíli jsou. Během validace se nic nezapisuje. Protože se referenční data mohou mezi validací a zápisem změnit, samotný zápis stále běží se zpracováním chyb po záznamech.
- 03Schvalování a oddělení pravomocí
- Žadatel, vlastník dat, validátor, vykonavatel a administrátor jsou oddělené role, přiřazované pro každou lokalitu. Která osoba smí mít kterou roli – a zda žadatel vůbec kdy smí schvalovat – je vaše konfigurační rozhodnutí, zapsané do nastavení společně s vámi, ne výchozí hodnota, kterou volíme za vás. U každého schválení je uveden uživatel a čas.
- 04Provedení a částečné selhání
- Zápisy běží v dávkách s protokoly provedení. Odmítnutý záznam jde do fronty oprav se zprávou ze SAP; zbytek dávky pokračuje; opravené záznamy se zapíší znovu. Hromadné změny kmenových dat nelze v SAP „vrátit zpět“, proto je modelem režim změn s předchozím souborem uchovaným jako reference – ne příslib rollbacku.
- 05Kde žije historie
- V Data Run: každá verze souboru, kdo ji nahrál (check-in), výsledky validace podle listů, schválení, stav provedení a odpovědi SAP, za každý požadavek. V SAP: změnové doklady, které si SAP zapisuje sám. Doba uchování se řídí nastavením vašeho projektu; stopu lze exportovat pro potřeby auditu.
- 06Kdo udržuje pravidla
- Validační pravidla a seznamy hodnot jsou konfigurací pro každý objekt a lokalitu. Po onboardingu je udržuje váš data steward; nové objekty a nestandardní byznysová pravidla nastavujeme společně – v pilotu uvidíte, kde končí konfigurace a kde začínají implementační práce.
06 · Zapadne do toho, co máte
Nic ve vašem prostředí se nenahrazuje.
07 · Provozní modely
Provozujte ho sami, s námi, nebo to nechte na nás.
Globální pivovarnická skupina – každodenní změny pro provozní společnosti napříč skupinou: údržba, obchodní partneři, FI/CO. Externí provedení se specialistou společnosti Visehub přímo v týmu přes Teams.
08 · Časté otázky
Otázky, které dostáváme.
- 01Už používáme ServiceNow. Musíme ho nahradit?
- Ne. Pro příjem požadavků si necháte ServiceNow, Jiru nebo e-mail; vise Data Run standardizuje to, co se děje po ticketu – šablonu, validaci, zkušební běh, schválení a zápis. Předání zajišťuje šablona připojená k ticketu; přímá integrace ticketu s požadavkem je na roadmapě, v produktu dnes není, a říkáme to dřív, než s ní začnete počítat.
- 02Na hromadné změny už máme skripty.
- Dobrý skript umí validovat a logovat. Málokdy má ale proces kolem: šablonu, kterou vyplní byznys, zkušební běh před každým zápisem, schválení oddělenou rolí a jednu auditní stopu pro každý běh – udržovanou jednou, ne pro každý skript zvlášť, a nezávislou na člověku, který ho napsal. Data Run zachovává rychlost skriptu a zbytek standardizuje.
- 03Které systémy?
- SAP ECC a S/4HANA přes BAPI, IDoc a OData; IBM Maximo přes konektor; Microsoft Dynamics 365 Business Central a Dynamics NAV přes jejich API a webové služby. Jakýkoli jiný systém, který nabízí API nebo webové služby, lze připojit stejným způsobem.
- 04Které objekty jsou připravené k použití?
- Dnes v produkčním provozu: údržba (zařízení, technická místa, plány údržby, pracovní postupy, kusovníky); materiály (hotové výrobky, obaly a suroviny); partneři (odběratel, dodavatel, obchodní partner v systému S/4HANA s CVI); finance a controlling (účty hlavní knihy, nákladová střediska, nákladové druhy, profit centra, druhy výkonů, banky, doklady FI); změny zakázek odběratele. Další objekty se přidávají pomocí šablon, seznamů hodnot a validačních pravidel, beze změn platformy.
- 05Jedna změna, která zasahuje do více systémů?
- Jeden požadavek míří do jednoho systému. Změna, která zasahuje do SAP a dalšího systému, se řeší jako propojené požadavky pod společnou referencí a každý z nich se validuje, schvaluje a zapisuje ve svém systému.
- 06Lze změnu vrátit zpět?
- Jedním tlačítkem ne. SAP hromadné změny kmenových dat zpět nevrací, takže vrácení je nový požadavek na změnu sestavený z předchozího souboru a prochází stejnou validací, zkušebním během, schválením a zápisem. Pole, která SAP uzamyká, jakmile existují pohybová data – například základní měrnou jednotku při zásobě na skladě –, nelze změnit zpět a zkušební běh to ukazuje dřív, než se cokoli zapíše.
- 07Je Data Run obecný engine pro workflow nebo orchestraci?
- Ne a ani ho tak neprezentujeme. Je postaven pro řízené změny dat: byznys popisuje změnu v šabloně, platforma ji validuje, schvalovatel ji uvolňuje, zápis se provádí a protokoluje.
- 08Za jak dlouho to poběží?
- 30denní pilot na jednom případu užití – jeden objekt, jedna země – poté rozšiřování objekt po objektu. Většina času padne na vaše pravidla, ne na instalaci: řešení běží v cloudu a potřebuje prohlížeč a zabezpečené připojení.
- 09Co potřebujeme pro pilot?
- Jeden objekt a jednu zemi – změnu, které se váš tým obává nejvíc. Z vaší strany: vlastník dat, který zná pravidla, testovací systém SAP (nebo Maximo) s uživatelem pro standardní rozhraní a zabezpečené připojení. My připravíme šablonu a pravidla, s vaším týmem provedeme validaci a zkušební běh a první skutečnou změnu zapíšeme podle zásady čtyř očí. Pevná cena za 30 dní. Co měříte: dobu zpracování požadavku před a po, opravy prováděné vašimi specialisty, chyby zachycené validací ještě před SAP a to, zda auditní stopa odpoví na otázky vašeho auditora bez tabulky.
- 10Co určuje cenu po pilotu?
- Lokality a uživatelské účty v rozsahu (administrátorské a běžné) a provozní model – provozuje vaše IT, hybridně, nebo provozuje Visehub podle SLA. Čím více lokalit, tím nižší cena za lokalitu. Požádejte o model odpovídající vašemu objemu; ceník nezveřejňujeme.
- 11Je to totéž co vise DMW?
- Stejná disciplína validace, jiná práce. vise DMW vede migrační programy a kvalitu dat před go-live; Data Run vede opakované změny po go-live. Validační pravidla a seznamy hodnot vytvořené v DMW během migrace se po ní znovu použijí v Data Run.
Jeden případ užití, jedna země, 30 dní.
Vyberte změnu, které se váš tým obává nejvíc. Připravíme pro ni šablonu, zvalidujeme ji, vyzkoušíme nanečisto a zapíšeme podle zásady čtyř očí – a pak se rozhodnete, jak daleko rozšiřovat. Z vaší strany: vlastník dat, testovací systém s uživatelem rozhraní, zabezpečené připojení. Pevná cena za 30 dní; měříte dobu zpracování, opravy specialistů a to, co validace zachytila.