VMI, waarom moet dat?

In de afgelopen jaren ben ik veelvuldig betrokken geweest bij het implementeren van het VMI model in de Food Retail sector. VMI staat voor Vendor Managed Inventory. Dit is een business model waarbij leveranciers zelf verantwoordelijk zijn voor het bijhouden van de juiste voorraden ten behoeve van de (winkel)verkopen van een retailer. De leverancier wordt daarbij, vanuit de retailer, gevoed met informatie over de actuele voorraadstanden in het distributiecentrum en over de verwachte verkopen in de komende periode. Op basis van deze parameters kan de leverancier zelf berekenen hoeveel artikelen hij wanneer moet leveren aan het distributiecentrum. Doelstelling is om daarbij niet te veel voorraad aan te houden, maar ook weer niet te weinig. Te veel voorraad leidt tot hogere kosten en verhoogt het risico op derving omdat producten in de voorraad over de datum (THT/TGT) gaan voordat ze zijn verkocht aan de retailer. Te weinig voorraad leidt tot gemiste (winkel)leveringen en dat betekent omzetverlies en een verslechtering van de relatie met de retailer. Voor een leverancier betekent VMI vooral het continu zoeken naar een juiste balans hierin.

Vanuit de praktijk heb ik gemerkt dat leveranciers zeer wisselend reageren op de overstap naar VMI. Deze overstap wordt hen vaak opgelegd door de retailer. Een groot deel van de leveranciers is niet direct enthousiast. De eerste reactie is vaak: “waarom moet dat?”. Dat is begrijpelijk omdat deze leveranciers gewend zijn aan een overzichtelijke situatie waarbij zij orders ontvangen die geleverd en gefactureerd kunnen worden. Daar hebben deze leveranciers hun processen en systemen op ingericht. VMI vereist dat deze leveranciers ineens zelf moeten berekenen wat er geleverd moet worden. Fouten die daarbij gemaakt worden zijn vaak ook voor hun eigen rekening of zo wordt het in ieder geval gepercipieerd.

Aan de andere kant is er ook altijd een groep leveranciers die het VMI model gelijk omarmt. Vaak zijn dit leveranciers die al geïnvesteerd hebben in en/of willen investeren in processen en systemen die wendbaar zijn en die reageren op actuele informatie. Zij zien de voordelen van VMI en, wellicht nog belangrijker, kunnen dit snel implementeren in hun organisatie. En die voordelen zijn er zeker voor leveranciers. Zo kunnen zij met VMI:

VMI biedt dus zeker voordelen. Maar is het makkelijk? Nou dat is het niet voor iedereen. Vanuit supplybrain hebben we daarom besloten om VMI software te maken om de VMI implementatie te vergemakkelijken voor leveranciers. Natuurlijk doen we dat omdat we daar een business case in zien. Maar we doen dit ook omdat wij geloven dat dergelijke oplossingen bijdragen aan een duurzamere samenleving. De beste manier om dervingen en daarmee voedselverspillingen tegen te gaan is immers door er voor te zorgen dat al het voedsel dat wordt geproduceerd ook daadwerkelijk wordt verkocht (en geconsumeerd). En niet in voorraden blijft liggen om uiteindelijk te worden vernietigd omdat de houdbaarheid is verstreken. VMI levert hier zeker een verbetering in. Dit effect wordt nog groter als de betrouwbaarheid van de informatie over de verwachte verkopen wordt vergroot. Hoe beter en eerder je weet wat er verkocht gaat worden, des te beter je kan bevoorraden. Vandaar dat supplybrain ook een module heeft ontwikkeld voor forecasting. Op die manier hopen we een bijdrage te leveren aan een duurzamere supplychain en daarmee een duurzamere samenleving. Daarnaast vinden wij dit ook gewoon leuk en uitdagend om te doen. Het is een mooi vooruitzicht om hiermee het nieuwe decennium in te gaan!

Jong talent gezocht…en gevonden

Orcado is een bedrijf dat in de afgelopen jaren gestaag is gegroeid. Deze groei kon worden bewerkstelligd door geregeld nieuwe medewerkers te werven. Deze medewerkers kwamen doorgaans uit ons eigen netwerk. Een netwerk dat ons ervaren collega’s opleverde. Omdat we steeds meer zelfstandig projecten gingen uitvoeren met eigen teams ontstond de behoefte aan nog meer medewerkers. Dat was het moment waarop we ervoor kozen om op zoek te gaan naar jongere collega’s om te zorgen voor nieuw elan, nieuwe kennis en mogelijk nieuwe inzichten. Probleem was dat deze mensen slechts in beperkte mate aanwezig waren in ons eigen netwerk. Daarop besloten we om een gespecialiseerde partij in te schakelen om ons te helpen bij het werven van jonge talenten.

Daarbij kwamen we uit op Procam. Procam werft en begeleidt jonge IT-talenten. Bedrijven als Orcado kunnen deze talenten inhuren, met als beoogd doel om hen uiteindelijk definitief in dienst te nemen. En zo begon een nieuwe fase in het bestaan van Orcado. Een fase waarvan we ons afvroegen hoe dit uit zou gaan pakken. Opeens kwamen er kandidaten die gespecialiseerd zijn in Machine Learning, Data Mining, Robotica en Artificial Intelligence. Zelfs kandidaten die weten hoe je Quantum Dots deponeert op een siliconen oppervlak. Hoe pas je dergelijke personen in in een bedrijf dat, op dat moment, voornamelijk bezig was met het automatiseren van bedrijfsprocessen.

We zijn inmiddels zo’n 4 jaar verder. Terugkijkend op deze periode zijn we door 4 fasen gegaan die ik zou willen samenvatten als de WAUW-fasen:

  1. Wat? Dit gaat vast tijd kosten”. In deze eerste fase dachten veel collega’s, waaronder ikzelf, dat het vast veel tijd zou gaan kosten om de Procammers in te gaan werken. En tijd is schaars als je zelf ook nog bezig bent om jouw eigen projecten goed af te leveren. Deze fase duurt zo’n 2 maanden;
  2. Aha, dat valt ontzettend mee”. En dan kom je tot de ontdekking dat de nieuwe collega’s al zeer zelfstandig zijn. Door het hoge denkniveau worden taken als programmeren en testen al snel zelfstandig op gepakt. En ook in de communicatie naar klanten draaien de Procammers als snel volop mee. De begeleiding vanuit Procam speelt een grote rol bij de snelle manier waarop de jonge talenten zich aanpassen aan en inpassen in ons bedrijf’;
  3. Uh…toch even wat uitleggen”. Maar dan kom je er na verloop van tijd, zeg 6 maanden later, achter dat er toch wat zaken zijn die je moet uitleggen. Zaken die voor ons, als ervaren IT-ers, zo vanzelfsprekend zijn dat we even vergaten dat die voor ons, aan het begin van onze carrière, ook niet zo vanzelfsprekend waren. Denk daarbij aan zaken als hoe een complete infrastructuur werkt, wat (old school) client-server is en wat middleware precies doet tussen applicaties. Maar ook organisatorische zaken als hoe grote project-organisaties werken, hoe ITIL procedures in elkaar steken en hoe project faseringen werken. Daar hebben we dus toch maar even wat tijd in gestoken;
  4. Wacht eens even, er kan veel meer”. Uiteindelijk werden ook die ‘vergeten zaken’ snel bijgeleerd waarbij we ons eveneens beseffen dat je dit soort zaken vooral en alleen kan leren door meters te maken en alles zelf te ervaren. En dan beland je op het punt dat ik zelf de leukste fase vind om mee te maken. En dat is de fase waarin je je beseft dat de (inmiddels iets oudere) talenten ons wat kunnen gaan leren. Yes!

Bij Orcado zijn we druk bezig met nieuwe technologieën en met nieuwe business services en oplossingen die we aan onze klanten willen gaan bieden. Ja, dan gaat het ook over machine learning, AI, simulaties, data science en zelflerende algoritmen. En laten dat nou precies de onderwerpen zijn waarbij onze Procammers en ex-Procammers (die werken inmiddels in dienst van Orcado) ons fantastisch verder kunnen helpen. Zij hebben immers de kennis en de skills om dit te doen. En ze beschikken ook over een sociaal netwerk om nog verder te komen in de verdieping van deze onderwerpen. We gaan dit potentieel nu dus aanboren.

Hoe deze fase verder verloopt? Dat laat ik je weten in een volgende blog ergens volgend jaar of zo. Maar om eerder te weten hoe dit verder uitpakt, kun je natuurlijk ook gewoon in de gaten houden met welke oplossingen en diensten Orcado in de komende maanden gaat komen. Daarin zal je zeker de bijdragen van onze talenten terug zien komen. We zijn hier namelijk al volop mee bezig!

De eeuwige strijd: middleware versus applicatie

Iedereen die te maken heeft gehad met integratie vraagstukken herkent het volgende probleem: plaatsen we de logica van de vertalingen in de middleware of in de applicatie? Ik heb zelf talloze uren gespendeerd aan deze discussie. Hele whiteboards werden dan vol geschreven met de pro’s en con’s van beide keuzes. Wat mij altijd opvalt bij deze discussies is de verbetenheid waarmee deze worden gevoerd. Het mondt vaak uit in een stammenstrijd waarin voor- en tegenstanders hun kampen betrekken en elkaar bestrijden met principes.

De applicatie-aanhangers vinden dat alle business logica tot het applicatie domein behoort. De middleware dient ‘onwetend’ te zijn en alleen te worden gebruikt als (geavanceerde) transportlaag.

De middleware-aanhangers vinden dat alle mogelijkheden van hun tools moeten worden benut. Dat is nou juist de kracht van de middleware. En daar is al veel geld voor betaald. Dus dan moet je het ook goed gebruiken.

Een principe-strijd dus. Al spelen politieke en commerciële belangen natuurlijk ook een grote rol bij het innemen van een standpunt. Het probleem van een dergelijke principe-strijd is dat beide standpunten zeer goed te verdedigen zijn. En dat niemand dus het absolute gelijk aan zijn zijde heeft. Helaas zijn dat precies de omstandigheden waarin mensen niet van hun standpunt willen afwijken. De stellingen zijn betrokken en niemand geeft elkaar een duimbreed toe.

Het zou helpen als er op een andere manier naar dit probleem gekeken zou worden. Voor zowel middleware als applicaties geldt dat deze bestaan omdat ze organisaties moeten faciliteren bij het realiseren van hun IT-processen. Het zijn dus beiden middelen en geen doelen op zich. Principale discussies hierover zijn dus weinig zinvol. Dergelijke discussies zijn relevant als je het hebt over doelen. Maar niet als je het hebt over middelen.

Het is mijn overtuiging dat bij de keuze tussen middleware versus applicatie vooral moet worden gekeken naar waar de organisatie het best in is. Stel dat je allemaal Oracle maatwerk applicaties hebt draaien en je hebt een fantastisch ingerichte IT-organisatie die zeer bedreven is in het bouwen en beheren hiervan. Dan lijkt het mij voor de hand liggen dat je alle logica in de applicaties aanbrengt. Daar ligt immers jouw kracht. En als je juist een heel divers IT-landschap hebt met verschillende technologieën, dan loont het wellicht om de logica in de middleware te leggen. Dan leg je daar jouw focus neer en zorg je ervoor dat je een competente middleware beheer-organisatie inricht. Dan zit daar jouw kracht en organiseer je van daaruit de grip en controle op jouw IT-landschap.

Kiezen tussen middleware versus applicatie? Kijk naar waar je goed in bent. Bedenk vooral wat jij het best en het goedkoopst kan organiseren. Laat je vooral niet verblinden door te veel principes. En als je een keuze hebt gemaakt, houd je daar dan ook aan. Dat houdt het simpel en overzichtelijk. En dat is een groot goed!

 

EDI – de ultieme integratie

Ik ben inmiddels al ruim 13 jaar bezig met EDI. Dat is best lang. Zo lang dat ik bij veel collega’s zelfs bekend sta als “Mister EDI”.

En het is ook alweer zo’n 9 jaar geleden dat ik voor het eerst te maken kreeg met het vakgebied van Integration en Middleware. In mijn geval betreft dat voornamelijk het werken met webMethods.

In al die jaren is mij een aantal zaken opgevallen. Als ik in mijn werk betrokken ben als EDI Architect dan komt heel vaak het volgende voorbij:

  1. EDI? Is dat niet een beetje ouderwets? Die EDI-berichten bestaan al zo’n 20 jaar en zijn nog steeds hetzelfde. Moeten we dat niet eens gaan moderniseren?
  2. Die EDI-berichten zijn wel simpel zeg. Dat is absoluut geen rocket science.
  3. Wisselen we EDI-berichten uit met meer dan 1000 handelspartners? Oh, dat wist ik niet eens.
  4. Hebben we minder dan 10 EDI berichttypen in gebruik om elk jaar miljoenen business transacties uit te wisselen met die handelspartners? Dat is ook niet veel zeg.

In mijn werk als Integration Architect hoor ik vaak heel veel ambities voorbij komen:

  1. We moeten voor onze middleware oplossing goede standaardberichten ontwerpen. Het is belangrijk dat we dit meteen goed doen, want elke aanpassing aan deze berichten brengt, nadat ze zijn geïmplementeerd, grote kosten met zich mee.
  2. Onze standaardberichten moeten generiek worden opgezet zodat verschillende applicaties en/of pakketten hiermee met elkaar kunnen communiceren.
  3. Al onze bedrijfsonderdelen moeten met dezelfde set van standaardberichten kunnen werken.
  4. Dat willen we inderdaad allemaal. Maar we willen dit werk natuurlijk wel allemaal outsourcen en offshoren. Dus houd alles wel enigszins overzichtelijk. We willen geen wildgroei aan berichttypen en versies daarvan.

Tja, dan denk ik soms wel eens: dat ouderwetse EDI, is dat eigenlijk al niet decennia lang de ultieme vorm van Integration?

Hier komt de sidebar

Volg ons op

© Orcado B.V. | 1999 - 2020