Přejít k obsahu

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
Pracovní fronta v nástroji vise Data Run: jedenáct objektů SAP se stavem (probíhá, čeká na schválení, dokončeno, vyžadováno), indikátorem spojení se SAP, vlastníkem dat, DM konzultantem, závodem 1710, SLA a šablonou v Excelu pro každý objekt
Pracovní fronta – každý objekt se stavem, spojením se SAP, vlastníkem dat, konzultantem, závodem a SLA. Jedna obrazovka pro data stewarda: co čeká, co čeká na schválení, co selhalo (demo data)Obrazovky z demo prostředí vise Data Run · fiktivní data

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.

01Žádný centrální přehledŽádný záznam o tom, kdo co změnil; validace se na každém trhu uplatňuje jinak; slabá auditní stopa.
02Opakovaná ruční práceStejná rutina s tabulkami a e-maily na každém trhu, v každém cyklu, a nic se nepřenáší dál.
03Specialisté jako úzké hrdloFronty před několika experty na SAP; byznys čeká, experti formátují tabulky, místo aby řídili data.

02 · Šest kroků

Zvalidováno před SAP. Řízeno během zápisu. Auditovatelné po něm.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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?“.

vise Data Run – záložka „Files“ objektu Equipment: pět souborů změn s typem, datem změny, vlastníkem, stavem check-in, posledním během a výsledkem nahrání („Loaded“, „Failed“), s volbami „New version“, „Check out“ a „Download“ u každého souboru
Soubory objektu Equipment – každá verze s vlastníkem, stavem check-in, posledním během a výsledkem nahrání; „New version“, „Check out“ a „Download“ u každého souboru (demo: závod 1710, reorganizace PM)
vise Data Run – „View file“: ID běhu, typ souboru „Gather file“, kdo a kdy validoval, kdy byla data nahrána, a validace podle listů – EQ GENERAL, DATA_INSTALL, DATA SPEC, DATA_FLEET vše „Valid“, 100 % hotovo, nula řádků s problémy
„View file“ – kdo validoval, kdy bylo validováno, kdy byla data nahrána; validace podle listů: čtyři listy, 100 % hotovo, nula řádků s problémy před nahráním
vise Data Run – objekt Equipment: doména „Plant Maintenance“, stav „In progress“, indikátor SAP „Ok“, vlastník dat, DM konzultant, závod 1710, SLA 2 dny, šablona, validace „Passed“, schválení „Approved“, poslední nahrání do SAP, systém SAP S4H klient 100, akce „Change“
Karta objektu – doména, stav, spojení se SAP, vlastník dat a konzultant, závod, SLA, šablona, stav validace a schválení, poslední nahrání do SAP a cílový systém, vše nakonfigurováno pro každou lokalitu bez kódu

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ístaHierarchie, strukturní indikátory, organizační data, konvence pojmenování
Plány údržbyParametry termínování, cykly, položky, soulad s centrálními strategiemi
Pracovní postupyOperace, 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.

Příjem požadavkůVáš ticketovací systém zůstáváServiceNow, Jira, e-mail – požadavek se zakládá tam, kde se zakládá dnes. Předání zajišťuje šablona: přenáší do Data Run rozsah, pravidla, úroveň rizika a okno nasazení.
CílPouze standardní rozhraníSAP ECC a S/4HANA přes BAPI, IDoc a OData; IBM Maximo přes konektor. Vlastní kontroly SAP, číselné intervaly, oprávnění a změnové doklady zůstávají aktivní – zápis vypadá pro SAP jako každý jiný.
PravidlaNapsaná jednou, používaná opakovaněValidační pravidla a seznamy hodnot se konfigurují pro každý objekt a lokalitu, bez kódu. Pokud jste migrovali s nástrojem vise DMW, pravidla a seznamy z migrace se přenesou; vise LoV-MAP udržuje seznamy hodnot aktuální.

07 · Provozní modely

Provozujte ho sami, s námi, nebo to nechte na nás.

01Provozuje vaše ITVisehub zajistí nastavení, šablony a onboarding; provozuje váš tým. Volitelná podpora.
02HybridněVaše IT si ponechává architekturu a schvalování; Visehub zajišťuje validaci, provedení a dodání.
03Externí provedení + podpora přímo v týmuVisehub jako váš tým pro provádění datových změn podle SLA, s konzultantem ve vašich Teams na plný úvazek. Model, který zákazník, se kterým spolupracujeme nejdéle, využívá už roky.
V produkci

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.

Zákazníci

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.