ARKIVERING/INFORMATION LIFECYCLE MANAGEMENT (ILM&GDPR)
Af: Henrik Kroos Atronas Aps.
I denne om efterfølgende blogs, vil jeg gå igennem status på Arkivering/ILM I SAP ERP & S/4 HANA.
Denne første del er et op i helikopteren overblik over SAP’s løsning og hvordan du kan opnå forretningsmæssige fordele af dette.
Anden del vil fokusere på standard arkivering, hvordan det sættes op og hvordan det bruges i den daglige drift.
Tredje del vil fokusere på SAP’s ILM løsning, som er bygget oven på (eller ved siden af) arkiveringsløsningen.
Fjerde del vil fokusere på hvordan man implementerer EU’s GDPR krav for forskellige dataobjekter som indeholder personlige data.
Femte del vil være en opsummering af ovenstående, samt hvordan man kan starte sit projekt og hvordan du kan få hjælp.
Det er vigtigt at vi før vi starter nævner hvad vi ikke dækker:
EU GDPR-regler trådte i kraft i maj 2018, efter flere års forvarsler. Siden det nu er mere end to år siden reglerne trådte i kraft, burde alle have implementeret reglerne, uanset hvilke system kunden har.
GDPR er på ingen måde begrænset til dit SAP ERP / SAP S/4 system, men disse blogs dækker kun SAP løsninger, vi dækker ikke data som f.eks. er i Microsoft produkter eller lignende. Jeg vil ikke dække de juridiske aspekter, men nævne nogle af afgørelserne fra de danske myndigheder (datatilsynet). I tilfælde af du er i tvivl har spørgsmål osv. Så se del 5 under afsnittet om hvor du kan få hjælp.
Disse blogs vil tage udgangspunkt i SAP S/4 HANA 1909 SP 01. Andre, nyere eller ældre versioner af SAP-produkter kan være anderledes, men princippet skulle ikke ændre sig.
OK lad mig begynde.
Over tid vil dit SAP-system (f.eks. S/4, ERP, CRM) akkumulere data. Det betyder at dine databaser vil vokse over tid. Årsagen er selvfølgelig at hver dag, indsættes/ændres data f.eks. der bliver lavet nye salgsordre, indtastet finans data osv. Herudover vil interfaces mellem dit system og andre systemer, dit system i sig selv osv., generere logfiler, nye data osv. Selv for et mellemstort firma kan væksten nemt være adskillige GB pr måned, og for større systemer kan vi endda snakke TB (en terabyte er 1024 GB). Denne vækst vil på et tidspunkt føre til dine diske løber tør for plads (out-of-space) og dermed stopper dit SAP-system. Det er dine basisfolk der normalt har ansvaret for at monitorere dette f.eks. via Early Watch Rapporterne, Solution Managers MAI, Focused Insights dashboards eller på anden måde.
Der er to løsninger på dette:
- Udvid disken, altså køb noget mere disk.
- Slet/flyt data der ikke bruges (eller sjældent bruges).
Selvfølgelig kan man ”bare” bruge løsningen med at få mere diskplads. Dette har selvfølgelig omkostninger, samt afledte omkostninger f.eks. skal du også have mere plads til backup, dit system kan få dårligere performance osv. Desuden kan du komme i problemer med GDPR-reglerne, da du så kan risikere at du har persondata som du faktisk burde have slettet. Dette er desværre den løsning, jeg har set brugt mange steder.
Løsningen med at slette/flytte data, kræver i et SAP-system at det gøres konsistent. Sletter man bare data, risikerer man at der opstår manglende sammenhæng mellem dine data. Slette du f.eks. kundedata, uden at slette tilhørende salgsordrer har vi pludseligt forældreløse data, dette kan få SAP systemet til at gøre mærkelige ting, f.eks. lave dumps, give underlige fejl til slutbrugerne, og dermed skabe afbrydelse af dine forretningsprocesser. Afbrydelsen af processerne kan medføre direkte tab, ved at man mister ordrer, forsinkelser osv.
SAP har derfor udviklet en arkiveringsløsning, denne løsning som beskrives nærmere i del to, består af såkaldte arkiveringsobjekter. Et arkiveringsobjekt kender standardsammenhængene i data. F.eks. ved at selektere s objektet SD_VBRK
Kan med ved tryk på Database Table se hvilke tabeller der berøres
Og man kan ved at trykke på Online Space knappen nederst i midten se hvor meget den fylder
Mere om det i et kommende afsnit.
Når man så vil arkivere data, betyder det at data kopieres til et område du har sat op, f.eks. en anden database, når kopieringen er udført, kan man så slette data fra tabellen.
Dermed er der så plads til nye data.
Processen (altså antal actions) man har er forskelligt fra objekt til objekt.
Her er der 4 steps, Preproc, write, delete og read. Samt et step til management. Hver step kræver normalt at man opretter en variant, som angiver hvilke data der skal køres for.
Derefter kan man sætte dem op som baggrundsjobs (batch jobs) og køre dem regelmæssigt. PAS PÅ sørg for du har en god test først, gør du det forkert kan du risikere at slette data der ikke skulle være slettet.
I mange tilfælde kan man også genskabe data fra arkivet, men det afhænger af arkiveringsobjektet.
Skulle du have lavet egne tabeller eller ikke standard ændringer i tabeller, må du også tilpasse arkiveringsobjektet, Mere om dette i en særlig blog om udvikling af arkiveringsobjekter.
I arkiv exploreren (transaktion SARI) kan du se dine arkiverede data.
Selve customizeringen og opsæt af arkiveringen og arkivet, vil blive dækket i del 2.
HVAD ER SÅ SAP’S INFORMATION LIVECYCLE MANAGEMENT (ILM)
Meget kort fortalt er det intelligent arkivering.
Som vi lige har set, skal arkivering køre med varianter. Disse varianter er relativt ufleksible, specielt set i lyset af, at du jo nemt kan have flere firmakoder, flere lande, hvor reglerne kan være forskellige.
Jeg vil komme ind på reglerne i kommende afsnit.
Samtidigt har GDPR nogle yderligere krav f.eks. låsning (locking) af data, som heller ikke er dækket. Se del 3.
Hvad er så dine forretningsfordele?
Efter arkivering og måske også sletning. Får du ryddet op i dine data, dit system vil alt andet lige finde relevante data hurtigere. Databasen bliver mindre, hvilket betyder at du sparer diskplads, hukommelse osv.
Således vil dine brugere have mindre vente tid, og dermed hurtigere kunne besvare f.eks. kundernes henvendelser.
Backup, opgraderinger, rapporter bliver hurtigere, fylder mindre og giver bedre overblik.