Een min of meer gedwongen opwaardering van een SAP-systeem bij supermarktketen Laurus heeft geleid tot vervanging van het hardwareplatform en modernisering van het softwareplatform. Deze zeer complexe operatie beleefde in een lang weekeinde zijn apotheose.
De onderneming is vooral bekend van de winkels Edah, Konmar en Super De Boer. Laurus is ontstaan in 1998 bij de samenvoeging van De Boer Unigro en Vendex Food Groep. Het concern heeft een marktaandeel van ongeveer 19 procent en telt een kleine dertigduizend werknemers.
Peter Huberts is er manager process management ict. Hij draagt zorg voor technologische oplossingen die de bedrijfsprocessen moeten ondersteunen. Tevens zorgt hij voor projectmatige invoering van die oplossingen. Hij vertelt hoe de beheerkosten van de automatisering zijn gestroomlijnd. Huberts treedt niet in detail over de ict-uitgaven, maar geeft volmondig toe dat de hele operatie heeft geleid tot eenvoudiger beheer, en daardoor tot kostenbesparing.
Domino-effect
Het project is overigens niet begonnen vanuit de wens een makkelijker te beheren automatiseringsplatform te scheppen. “Er was een tamelijk dwingende andere reden”, licht Huberts toe. “De module SAP Retail behoefde een opwaardering. Wij werkten nog met versie 4.0 en SAP had te kennen gegeven dat het zou stoppen met de ondersteuning ervan. Daarom zijn we overgegaan naar versie 4.6.c. Tussen beide release-datums zit ongeveer 3,5 jaar.”
Gedegen aanpak Dat de kost voor de baat uitgaat blijkt uit de monstermigratie die supermarktketeneigenaar Laurus vorig jaar heeft doorgevoerd. Hoewel het terugbrengen van de ict-kosten door een eenvoudiger beheer niet de opzet was, is dit toch een gunstig bijeffect gebleken. De operatie begon met de noodzaak een SAP-omgeving op te waarderen en mondde uit in modernisering van het complete platform (nieuwe database en hardware) en serverconsolidatie. Een extra complicatie was dat de migratie niet langer dan 72 uur in beslag mocht nemen. IBM heeft hiervoor een speciale methode moeten ontwikkelen. Een gedegen aanpak van zowel de opwaardering van het systeem als het proces zelf ligt aan de succesvolle migratie ten grondslag. |
Het was een domino-effect. Toen eenmaal was besloten de module voor de detailhandel te moderniseren, volgde als vanzelf een reeks andere beslissingen. Leo Mallander, consulting ict-specialist bij IBM, mengt zich in het gesprek. Mallander is in eerste instantie vanuit Big Blue projectleider bij Laurus geweest. Later vervulde hij de rol van ’technical lead’. “Een conversie van SAP Retail 4.0 naar 4.6 betekent ruwweg dat je de helft meer aan capaciteit op het hardwareplatform nodig hebt.” Mallander is een SAP-specialist bij uitstek; hij heeft zich al in de software verdiept sinds versie 1.0 op de markt is.
Laurus kende in zijn rekencentra zowel een HP- als een IBM Unix-platform. Het IBM-systeem werd onder meer gebruikt voor het Oracle-datapakhuis. “Om allerlei redenen hebben we gekeken naar de strategie voor de lange termijn op het gebied van hardware”, vervolgt Huberts. “Tactische en strategische overwegingen hebben de doorslag gegeven bij de beslissing om serverconsolidatie door te voeren. Tactisch omdat de nieuwe versie van SAP dit eigenlijk eist en strategisch omdat het niet efficiënt is de automatisering te versnipperen over twee platformen.”
Complexiteit
Hoewel de gekozen oplossing (consolidatie op een zware IBM pSeries p690-server met verscheidene logische partities en gekoppeld aan een IBM Totalstorage bedrijfsopslagserver) uiteindelijk een eenvoudiger platform biedt, maakte de keuze voor serverconsolidatie de weg ernaar toe wel complexer.
“Je doet dan ineens een heleboel dingen tegelijk die het écht ingewikkeld maken”, verklaart Mallander. Want nu ging het niet meer alleen om een SAP-opwaardering, maar ook om vervanging van het hardwareplatform. Bovendien ging de Oracle-database op de schop: van versie 8.17 naar 64-bit versie 9.2. Dan hebben we het niet over zomaar een database; het gaat bij Laurus om een reus van twee terabyte. Nooit eerder ter wereld, voor zover bekend, is een database van zo’n omvang gemigreerd. “Collega’s in de VS vertelden van een klant die 1,2 Tb heeft laten verhuizen. Alleen de migratie duurde daar al langer dan de hier beschikbare 72 uur. In Nederland kenden we een soortgelijke situatie, maar met een dataomvang van ongeveer 70 procent van die van Laurus, en daarbij ging het alleen om een SAP-opwaardering. Dat kostte alleen al zestig uur”, aldus Mallander.
Hij legt de kern van de complexiteit bloot: de beperkende factor tijd. “Onze systemen moeten het hele jaar rond beschikbaar zijn”, stelt Huberts. “Eigenlijk hadden we in 2003 maar één weekeinde waarin we het ons konden veroorloven de systemen plat te leggen. Dat was het pinksterweekend, het eerste weekeinde in juni. De hele operatie mocht dus niet meer dan 72 uur beslaan, en het systeem moest vervolgens foutloos meteen vol in productie draaien.”
Dat ging niet lukken volgens de gangbare methoden, zoveel was Mallander al snel duidelijk geworden. SAP en Oracle bijvoorbeeld stellen tools beschikbaar om migraties vlekkeloos te laten verlopen. “Bij het testen van de SAP-tools kwamen we uit op een doorlooptijd van enkele weken. We moesten dus een eigen methode ontwerpen. Uit een ogenschijnlijke onmogelijk karwei hebben we vervolgens een migratieparel ontwikkeld, en een methode die we bij latere projecten ook kunnen inzetten.
Management summary
|
Paniek
Dankzij medewerking van de Compentence Centers van SAP en Oracle en de eigen ervaring is het Laurus en IBM gelukt de SAP-release opwaardering en de servermigratie binnen de afgesproken 72 uur te volbrengen. De operatie verliep zo vlot dat er nog tijd over bleek te zijn om Websphere MQ te optimaliseren. Er brak enige paniek uit toen bleek dat alle MQ-wachtrijen leeg waren, maar al snel werd duidelijk dat er niks meer in de wachtrij stond, omdat het systeem alle opdrachten al had verwerkt. De snelheid van het nieuwe platform was boven verwachting.
Het bedrijfsbelang is gedurende het gehele proces richtinggevend geweest. Er mocht niets gebeuren dat de bedrijfsprocessen nadelig zou beïnvloeden. “We hadden het grote voordeel dat we het complete HP Unix-platform als backup konden gebruiken, want dat onderdeel ging niet mee over”, vertelt Huberts.
In de aanloop naar de migratie is het zaak zo weinig mogelijk, liefst geen, wijzigingen in het bestaande platform aan te brengen. “Bijna altijd moet het bestaande systeem worden veranderd om de migratie mogelijk te maken. Wij zijn erin geslaagd te migreren zonder wijzigingen nodig te hebben, onder meer door de database te repliceren. Daardoor is synchronisatie mogelijk zonder de gebruikelijke modificaties in de SAP-omgeving door te voeren. Omdat de migratie zo ingewikkeld was, hadden we een testterrein ingericht. Alles is van tevoren getest. Het hebben van het testterrein op zich maakte het mogelijk de datamigratie eerder in te zetten. Zo hebben we de complexiteit eigenlijk in ons voordeel omgezet”, vertelt Mallander. Er is heel wat gepuzzel nodig geweest om de overstap, een welhaast militaire operatie, in goede banen te leiden. “We hebben dan ook een bijzonder strakke uitvoeringsorganisatie neergezet”, zegt Huberts.
Het nieuwe systeem draait inmiddels al ruim een half jaar naar volle tevredenheid. Om de migratie niet nodeloos nog ingewikkelder te maken, is er destijds voor gekozen de uitgebreidere functionaliteit van de nieuwe SAP-versie niet meteen te implementeren. Huberts: “Op dit moment overwegen we hoe we die uitgebreidere mogelijkheden kunnen inzetten.”