Performance by design, ik heb het nog nooit iemand horen zeggen, maar het is toch zeker belangrijk. Door de jaren heen heb ik me bedacht dat het een teken kan zijn tussen een echte senior en niet. Iemand die niet alleen een proces kan bouwen, maar dat op zo’n manier doet dat het ook presteert.
Ik zou bij Mexx twee verhalen kunnen vertellen over performance, of de afwezigheid daar van, maar aangezien het ene verhaal begint met “Microsoft heeft een nieuw ERP systeem gebouwd”. Heb ik bedacht om het andere verhaal te vertellen.

Zoals je misschien kan verwachten bij een kledingmerk, is het ook nodig dat artikelen verkocht kunnen worden. Daar is natuurlijk een PoS (Piece of Sh..Point of Sale) systeem voor nodig. Het exacte systeem wat gebruikt werd, weet ik niet meer, maar het deed op bit-niveau informatie doorgeven. PowerCenter vond dat niet zo makkelijk, dus er was besloten om Java in te zetten om dit probleem op te lossen. Java kan in een component gehangen worden binnen PowerCenter, dus het kan alsnog in de standaard workflows meedraaien.
Bij gebrek aan capaciteit werd een extra collega ingezet om dit specifieke project(je) op te pakken. Na een periode had deze collega zijn werk gedaan, en een andere collega had het Java component aangemaakt, zodat het proces draaide.
Al snel werd duidelijk dat dit proces iets langer draaide dan gewenst, het deed er 8 uur over om de PoS acties van de dag te verwerken. En jammer genoeg voor Mexx, zoveel tijd was gewoon niet nodig. Er werd van mij gevraagd of ik er naar kon kijken, om er uit te persen wat er in zat. Na enige analyse had ik het probleem gevonden. De referentiedata die eenmalig ingelezen zou moeten worden, werd voor elk record ingelezen. Enkele duizenden keren 8 duizend records inlezen duurt even. Een kleine wijziging later en het proces was iets sneller. In plaats van 8 uur duurde het nu ongeveer 30 seconden. Succes!
Dit was allemaal ongebruikelijk en niemand kon aangekeken worden dat er niet vanaf het begin rekening mee was gehouden, maar iets in mijn achterhoofd zegt dat het eerder had moeten opvallen.

L.S.,

Het grote Mexx project bestond uit een groot onderdeel en vele kleinere onderdeeltjes. Het grote onderdeel was een data warehouse volgens de data vault methodologie. Met wat externe hulp was een standaard manier van werken gecreëerd om het data warehouse te vullen van de vele verschillende bronnen. Een ontwikkelaar kon met behulp van een handleiding binnen korte tijd de vulling regelen. Nadat ik dit drie had gedaan verveelde me ik al kapot en vroeg of dat ik niet de kleinere onderdelen van het project op mocht pakken.
Het oude gedeelte van Mexx draaide op het rondsturen van bestanden. Duizenden bestanden per dag voor honderden systemen. Ook dit proces moest vervangen worden door iets nieuws. Gelukkig hadden we PowerCenter, in combinatie met B2B Data Transformation en VL-Trader, die dit allemaal voor ons kon regelen. Technisch was dit interessant genoeg, maar aangezien alles zo’n beetje werkte zoals het moest, wil ik het daar niet over hebben.
De uitdaging van dit project was niet de techniek, de uitdaging zat meer in de gebruiker. Deze gebruiker had namelijk iets te veel ervaring. Iets te veel negatieve ervaring. De gebruiker was bang dat dit project zijn leven moeilijker zou maken, in plaats van makkelijker. Om zijn zorgen te verminderen wilde hij ervan overtuigd zijn dat de ‘consultants’ weten wat hij nodig had. De enige manier waarop was door bij elke vraag en elk overleg van begin tot eind alles te vertellen. Alles wat hij weet over het systeem dat er nu draait, alles wat nagemaakt of vervangen moest worden. Ik zie mezelf niet als een erg sociaal persoon, maar ik realiseerde dat ik zijn vertrouwen moest winnen. Dus ik tolereerde zijn verhaal, keer op keer. Ik verzekerde hem er van dat ik begreep wat de bedoeling was. En ik liet hem zien wat ik aan het maken was. Op het einde is alles goed gekomen en hij was tevreden. En ik was trots op een elegant systeem dat de nodige duizenden bestanden in een uur kon verwerken en daar geen hele dag voor nodig had.

Mijn eerste contact met een klant die eigenlijk niet met je wil samenwerken, maar wel moet.

L.S.,

Een van mijn favoriete uitspraken in de ‘werk-wereld’ is: ‘goed werk wordt beloond met meer werk’. Het voordeel van mijn oplossing in het vorige verhaal was de positieve indruk die ik achterliet, en de tevredenheid van mijn werkgever dat zijn eerste aangenomen junior een resulterende investering was. Het nadeel is natuurlijk dat er steeds meer en hogere verwachtingen zijn.
Ik kreeg mijn eigen mini-projectje binnen het grote project dat Mexx was. Zoals je misschien kan verwachten bij een kledingbedrijf moeten zij kleding maken. Het maken van deze kleding gebeurd in de lage lonen landen van de wereld, zoals eigenlijk al het relatief simpele maak werk in de wereld. Het aansturen van dit fabriceren was een veel belangrijker, groter en complexer project waar een aantal collega’s aan werkten. Als deze kleding gemaakt is moet deze verstuurd worden naar de landen in de wereld waar Mexx haar waren probeerde te verkopen. Het versturen wordt geregistreerd in een ‘Electronic Freight Record (EFR)’. Hier staat in welke dozen, in welke containers, in welke schepen of vliegtuigen, waarheen gaan en wanneer deze daar verwacht worden of aangekomen zijn.
Deze bestanden met de EFRs erin werden regelmatig door fabrikanten naar Mexx toe gemaild, gecontroleerd door mijn proces, daarna de database geüpdatet waar nodig en klaargezet om ingezien te worden door de medewerkers van Mexx. Zij konden met behulp van deze informatie sturing toepassen richting de fabrikant of het transportbedrijf.
Om dit proces te kunnen bouwen was er een klein ontwerp gemaakt. Als een brave junior heb ik dit document van voor tot achter bestudeerd en er voor gezorgd dat elke letter geïmplementeerd is. Nadat ik er van overtuigd was dat alles goed ging is onze architect samen met de gebruiker er bij komen zitten om er doorheen te lopen. Hij was erg ontevreden, er ontbraken allerlei validaties! Met schrik in mijn hart zat ik daar, mijn eerste project en een ontevreden gebruiker! Gelukkig had de architect de tegenwoordigheid van geest om het originele ontwerp erbij te pakken. Het ontwerp geschreven door die gebruiker. Zoals ik al wist kon de klant niet aanwijzen in dit document waar die validaties moesten komen en hij gaf toe dat dit niet onderdeel was van de opdracht. Ik kon weer rustig ademhalen, in ieder geval totdat de klant het document had aangepast en de validaties had toegevoegd.

Mijn eerste les dat een klant soms wat begeleiding nodig heeft in vragen wat die wenst.

L.S.,

Daar zijn we dan, mijn eerste echte project, een project waar ik ‘in het diepe’ gegooid word. Het punt waar ik geïntroduceerd word is het ontsluiten van een webservice via PowerCenter. Voor de mensen die niet bekend zijn met webservices (en helemaal in 2012), deze communiceren vaak in XML. En voor de mensen die niet bekend zijn met PowerCenter (of bijna elke ETL tool), XML is een drama! Dus na mijn 3 dagen PowerCenter training, welke kort samengevat kan worden in: ‘Zo ziet PowerCenter eruit, deze knopjes staan hier. Veel plezier.’, mocht ik meteen aan de bak. Tot iedereens verrassing was het daadwerkelijk verbinding maken met de webservice relatief probleemloos. Het probleem begon pas nadat we de verbinding hadden gemaakt.
Het proces moest op basis van een lijst de webservice aflopen om per item op de lijst wat bijbehorende informatie op te halen. Voor de items die aanwezig waren aan de andere kant van de webservice ging dit vlekkeloos. Als dit item echter niet aanwezig was gebeurde hier wat onverwachts. Ieder normaal systeem zou in dit geval een leeg resultaat terugsturen, ter informatie dat hier geen informatie voor aanwezig is. De ontwikkelaar van dit systeem had het briljante idee om in plaats daar van een HTTP fout code te hergebruiken. PowerCenter is echter niet flexibel genoeg dat je hem kan vertellen foutcodes te negeren. Dus op het moment dat een item niet gevonden werd en de webservice zijn foutcode terugstuurde, deed PowerCenter het enige wat PowerCenter kan doen. Hij knalt eruit op een technische fout en weigert verder te gaan.
Een uitgebreide ‘high-level’ meeting verder zijn we tot de beslissing gekomen dat de uitbater van de webservice dom bezig is geweest. Zij kunnen met liefde een wijziging doorvoeren in de webservice om een daadwerkelijk nuttige boodschap terug te sturen als iets niet gevonden kan worden. Verwacht levertijd: 6 maanden. Gelukkig heeft PowerCenter een wanhoop functie: custom Java componenten. Ik heb dus een stuk code mogen schrijven in Java om de webservice uit te lezen en niet te steigeren op deze specifieke foutmelding. Die vervolgens in PowerCenter kunnen hangen om toch nog onze taken uit te kunnen voeren.
Later zou ik realiseren dat dit de essentie is van IT werk. Er gaat altijd iets gebeuren wat je niet verwacht of wenst en jouw werk is een oplossing vinden om het probleem heen. Gelukkig word het vinden van oplossingen voor onmogelijke problemen erg gewaardeerd door beide werkgevers en klanten.

Goedendag,

Voor sommigen een voordeel en voor anderen een nadeel, maar het gevolg van je studie succesvol afronden is dat er van je verwacht wordt een baan te vinden. Zoals al in een eerder verhaal beschreven is dat als IT-er bijna niet eerlijk. Voordat ik mijn afstuderen geheel had afgerond had ik al een dozijn berichten in mijn inbox van LinkedIn met het verzoek voor een kennismakingsgesprek. Jammer genoeg waren dit allemaal grote bedrijven (a la Capgemini en Accenture) waar mijn angst om een ‘nummertje’ te worden in de ogen van de hoge heren er voor zorgde dat ik deze berichten negeerde of negatief beantwoordde.
Het leek er dus bijna op dat ik daadwerkelijk een vacature moest gaan zoeken, tot mijn moeder op een donderdag avond omhoog kwam lopen met de telefoon en deze aan mij gaf met de melding: ‘Ene Ivo-Paul aan de lijn’. Continue reading Fisher Price, my first (real) job →