Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Dozenschuivers zijn probleemstapelaars

 

Expert

E D
Iets met ICT, nvt. Expert van voor het topic .

De term dozenschuiver is bepaald geen geuzennaam en wordt gebruikt voor bedrijven die vooral techniek leveren. Ze kunnen heel goed concurreren op prijs omdat het personeel vaak ongekwalificeerd, tijdelijk en dus goedkoop is. Maar niet zelden is goedkoop uiteindelijk duurkoop, hetgeen meestal aan het licht komt als bij problemen blijkt dat er enkel service tot aan de voordeur gegeven wordt.

Wie met een dozenschuiver in zee gaat moet dan ook niet verrast zijn dat deze zijn logistiek van stukgoed voort blijft zetten na het winnen van de opdracht. ‘Easy money’ noemen deze bedrijven dat omdat er door contracten niet ten halve gekeerd kan worden en dus, ondanks alle frustratie, doorgegaan wordt op de ingeslagen koers. Maar toch vraag ik me af wie nu wie voor de gek houdt want vaak wordt, ondanks dat er gezegd wordt dat kwaliteit en service belangrijk zijn, toch vooral gekozen op prijs. Afdeling inkoop moet dan ook hele sterke argumenten hebben om te kiezen voor de duurdere of duurste oplossing, het maatwerk dat rekening houdt met de toekomst en dus meer aanbiedt dan er gevraagd wordt.

En dus is het eerder regel dan uitzondering dat na oplevering problemen naar boven komen die opgelost worden met uitbreidingen en vervangingen. En van de winnende oplossing, het uitgedachte ontwerp is dan al snel niet veel meer over en langzaam maar zeker stapelen de problemen zich op door alle alternatieve en tijdelijke oplossingen.

Een goedkope act

Het is natuurlijk makkelijk de dozenschuivers daarvan de schuld te geven omdat ze het adagium ‘U vraagt, wij leveren' hanteren, maar daar ligt de wortel van dit probleem niet. Dat zit eerder in het weggeven van de regie door het ontwerp uit te besteden aan de leveranciers. Want wie voor een dubbeltje op de eerste rij wil zitten moet achteraf niet klagen als de casting van het toneelstuk met goedkope acteurs is ingevuld.

De uitdrukking: ‘dubbel genaaid houdt beter' krijgt op die manier dus een dubbele betekenis want de deur naar dozenschuiven wordt door de vragende partij zelf open gezet. Zo zorgt het gemis aan capaciteits- en kostmanagement ervoor dat er ook veelvuldig met virtuele dozen geschoven wordt. De gedachte is dat dit ook goedkoop is, waardoor het aantal servers explosief stijgt en er uiteindelijk aan de onder- en bovenkant van de architectuur weer groeistuipen ontstaan. Als bij aanvang al aannames op veronderstellingen gestapeld worden dan is het niet verwonderlijk dat dit ook met problemen gedaan wordt.

Toren van Babel

Nu stapelen we niet alleen techniek in complexe ketens met allerlei afhankelijkheden waardoor de problemen toenemen maar doen dat ook organisatorisch. En dus hebben niet alleen architecturen een trechtermodel maar ook vaak de organigrammen. Aan de onderkant hiervan vinden we het beheer welke steeds meer voor minder moet doen omdat de bovenkant vooral gespitst is op de kosten. En daartussen bevindt zich een steeds dikker wordende laag die dit alles probeert te sturen op papier. Helaas wordt in veel architectuurmodellen de techniek aangegeven in blokken, onderverdeeld naar functie, waarbij aantallen en werking onbekend blijven en er dus verspilling blijft in de architectuur door:
1. Toewijzing; teveel, te weinig of gewoon de verkeerde techniek voor applicaties.
2. Slechte response; onjuiste of niet goed geconfigureerde en afgestemde hardware.
3. Geen waarde; toevoeging van redundantie die niets bijdraagt aan de kwaliteit.
4. Ineffectief; slechte Root Cause Analyse en daardoor verkeerde wijzigingen.

De artefacten vanuit de discipline Enterprise Architectuur zijn dan misschien wel artistiek maar niet pragmatisch omdat ze de aansluiting missen met de infrastructuur, de vertaling naar technische parameters die helpen om te sturen.

Kwaliteit door kwantificeren

Een euvel dat trouwens ook vaak te zien is bij het opstellen van de service levels die vaak niet goed gekwantificeerd zijn, vertaald naar techniek zodat ze ook meetbaar worden en er objectief over gerapporteerd kan worden. Wat zegt bijvoorbeeld het aantal gebruikers als onbekend blijft hoeveel transacties ze doen, hoeveel bytes ze over het netwerk verplaatsen of opslaan? Opmerkelijk vaak blijken de zogenaamde gekwantificeerde eisen dan ook gebaseerd op natte vingerwerk dat eufemistisch omschreven wordt als intelligente inschatting. Maar dat komt pas aan het licht als de oplossing geïmplementeerd is en het spel van pleisters plakken en zwarte pieten al begonnen is.

Dozenschuiven is dan misschien niet de gewenste oplossing maar de markt hiervoor is wel gemaakt door de wijze waarop it nog steeds aangestuurd wordt. Het ontbreken van inzicht in de prestatie en de waarde van de infrastructuur is dan als autorijden zonder snelheidsmeter. Je bent dan misschien wel sneller op je bestemming maar moet de boetes en ongelukken die achteraf volgen dan wel op de koop toe nemen.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4538645). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Wat een gefrusteerd artikel. Heb wat staaltjes van Unysis gezien de afgelopen jaren. Goedkope margekloppers zijn het die van simpele zaken mistery maken naar klanten en hun zakken leegtrekken.

Dag Ewout,

Voor 20 krentenbollen in een dozijn infrastructuren werkt een dozenschuiver prima. Wanneer werkt het niet: als de 12 genaderd wordt of nog minder krentenbollen in een dozijn; non-commodity infrastructuren dus.

Overigens, zoals gebruikelijk van je: prima verhaal!

Naar mijn mening ligt de verantwoordelijkheid bij de opdrachtgever!

De opdrachtgever wordt in dit geval van twee kanten gemanipuleerd:

1- softwarefabrikant die met hun oplossing mooie dingen beloven maar niet vertellen welke investering je nodig heb dit te kunnen realiseren,
2- dozenschuivers die beweren dit voor je te kunnen realiseren.

Hoe kan je als opdrachtgever dit voorkomen? Een adviseur kan de opdrachtgever in fase0 (RFI/RFP) de juiste informatie geven (door trajectbegeleiding, het maken van de nieuwe architectuur etc) zodat de vraag en de verwachtte kwaliteit van tevoren voor iedereen duidelijk zijn. En als in dit geval een dozenschuiver dit project denkt aan te kunnen, die is ook welkom in de race!
De opdrachtgever dient er van bewust te zijn dat de brug tussen de huidige omgeving en de nieuwe omgeving best lang kan zijn. Daarvoor heb je zeker een architect nodig!

@ Reza,

Ik heb het hier wel vaker over een consumentenbondoverzicht gehad.

Wat biedt de leverancier aan? Wat zit er wel in? Wat zijn de bijkomende kosten? Wat voor onderhoud zit er op ? Wat kosten eventuele uitbreidingen etc. etc.

Als je die punten in een overzicht verwerkt, is de kans op succes groter. En kan je ook echt appels met appels vergelijken.

Ook is een duidelijke en heldere vraagstelling van de klant een noodzakelijke kwaad. Laat dit te wensen over, dan kan iedere leverancier er zijn eigen draai aan geven.

Ruud,
Jouw voorstel is heel simpel en effectief! Naar mijn mening kunnen deze vragen pas beantwoord worden als de opdrachtgever zijn huiswerk al gedaan heeft. Als de opdrachtgever al weet hoe de nieuwe architectuur eruit komt zien, welke effecten de huidige omgeving (b.v. de huidige applicatieset en hun IoPS) en de toekomstige eisen/wensen (b.v. HA, BC/DR, nieuwe CRM etc) op de nieuwe architectuur kunnen hebben, kortom als de opdrachtgever een vertrekpunt heeft dan is het eenvoudig om jouw tabel in te vullen. Als dit terecht is dan zien we dat een (externe) adviseur/architect een belangrijke rol in fase0 voor deze verandering kan spelen.

Indrukwekkend taalgebruik, maar had dit niet wat korter en toegankelijker gekund?
Allereerst de dozenschuiver: graag een eenduidige definitie van wat jij hiermee bedoelt. Het leveren van techniek is een container uitdrukking die van alles kan betekenen.
Dan de valkuil en wellicht ook je boodschap: wie niet in control is moet niet verwachten dat een dozenschuiver dat wel gaat komen (hij is hooguit, voor de duur van het contract, in control over je portemonnee).
Wie wel in control is heeft geen dozenschuiver nodig en als je hem al nodig hebt zorg je dat hij met de juiste kwaliteit dozen schuift. Hierbij ben ik overigens van mening dat er ook dozenschuivers zijn die het wel goed doen en waken voor constante kwaliteit binnen de door hen geleverde standaarden – het is overigens een keuze of je gaat voor standaard.
De metafoor met goedkope acteurs is daarom minder geslaagd, want net afgestudeerde acteurs zijn vaak gedreven om zich te bewijzen voor het publiek. Voorwaarde is dat ze goed geregisseerd worden.

Ik heb vaak mijn vraagtekens bij het management van de organisatie die zo graag wil outsourcen. In de meeste gevallen zijn ze gewoon niet in control. En omdat ze niet in control zijn laten ze zich door dozenschuivers verleiden. De ellende wordt dan inderdaad alleen maar groter.
Ik ben het in die zin met Reza eens.
(ook) Mijn stelling is dat dit dus niet altijd aan de dozenschuiver ligt en de kop van dit artikel gaat mij in dat opzicht dan ook veel te ver.

Reza,

Ik ben het helemaal met je eens. De opdrachtgever dient altijd vooronderzoek cq. zijn huiswerk te doen. Het is namelijk van groot belang dat de juiste vraagstelling (wensen/eisen) geformuleerd wordt.

Doet men dat niet, dan blijft het appels met peren vergelijken.En is de kans op succes nihil. En zoals je aangeeft is de hulp van een onafhankelijke consultant/adviseur hierbij geen overbodige luxe.

@Jeroen
Grappig dat je een stuk frustratie in dit stuk ziet terwijl ik bij het schrijven hiervan dat niet voelde. Jammer dat je ongenuanceerd en ongefundamenteerd Unisys aanvalt. Maar uiteindelijk goed dat het een discussie los maakt zodat we er allemaal van kunnen leren.

@Maarten
Zolang er om de 8 extra krentebollen gevraagd is of deze niet betaald worden is het inderdaad prima. Worden deze platgeslagen in een zak gepropt en wordt hiervoor het volle pond betaald dan denk ik dat er wel problemen zijn;-)

@Overigen
Bedankt voor de reacties en ik kom hier, als ik wat meer tijd heb graag op terug.

@Ewout

elk vergelijk heeft zo zijn gevaarlijke kanten, platgeslagen krentenbollen lijken m.i. meer op pannenkoeken (met rozijnen). Maar ja dat is een specificatieverhaal....:

Wat mijn ervaringen met communicatie infrastructuren is dat wanneer het een commodity infrastructuur is, dus iets wat veel voorkomt dan is de laagste prijs mist aan de spec's voldaan wordt best een goede mogelijkheid.

Gaat het om een innovatieve communicatie-infrastructuur, dan is de laagste prijs zeker fataal voor een goede oplossing. In de praktijk blijkt het dan veelal toch goedkoper uit te pakken wanneer de functionaliteit als geheel er voor zorgt dat de infrastructuur een jaar langer dienst kan doen..... TCO.....

@HK
Gebruikte gezegde: Wie voor een dubbeltje op de eerste rang wil zitten..... is met de aanvulling bedoeld als beeldspraak. Type toneelstuk en het talent van acteurs kan je invullen naar gelang je eigen referentiekader. Zo kan de dozenschuiver een externe leverancier zijn maar evengoed de interne beheerorganisatie die elke vraag invult met techniek. Je slaat de spijker dan ook op de kop door het belang van controle/regie aan te geven.

@Reza
Bij de vertaling van de behoeften naar een oplossing kan een architect inderdaad helpen door het opstellen van de juiste vragen en het maken van de goede keuzen. Alleen let op dat er soms een verschil zit tussen de werkelijkheid op papier en die in de praktijk. En dan lijken ontwerpen soms als de tekeningen van M.C. Escher waar het water plotseling naar boven stroomt. Want soms vindt er namelijk ook manipulatie plaats vanuit de organisatie waardoor er vernieuwingen gevraagd worden om de vernieuwingen.

@Maarten
Total Cost of Ownership (TCO) geeft dan ook een interessante wending aan deze discussie. Het gebruik hiervan als selectie criterium is een beetje naar de achtergrond verdwenen maar zou eigenlijk onderdeel moeten zijn van het consumentenbondoverzicht waar Ruud Mulder het over heeft. Amendement van Ziengs & Leegte bij de nieuwe regels voor aanbestedingen stelt ook voor om bij Economische Meest Voordelige Inkoop (EMVI) hierop te sturen.

@Ruud
Zoals hierboven aangegeven is TCO een mogelijk waardevolle toevoeging aan je voorgestelde consumentenbondoverzicht omdat inderdaad vaak alleen gekeken wordt naar de direct meetbare kosten zoals de aanschafkosten. De indirecte en vaak verborgen kosten in onderhoud, beheer e.d. worden dus meestal niet meegenomen in vergelijkingen. Dat zorgt ervoor dat er een keuze tussen appels en peren gemaakt moet worden.

Zonder goede definitie van dozenschuivers, vind ik het ondanks de mooie opbouw en taalgebruik een matig stuk.

Waar je wellicht op reageert zijn de dozenschuivers die zichzlf als zodanig niet herkennen en zich niet als dozenschuiver voordoen. Want iedereen begrijpt en respecteert de dozenschuivers. Dat is hun rol, hun taak, hun businessmodel. Ze leveren een bestelling. één van de beste dozenschuivers ter wereld is Ingram Micro. Die doen dat heel goed en zorgen er dus voor dat klanten zo goedkoop mogelijk hun spullen krijgen.

Het gaat pas mis als er een andere rol word toegekend aan de dozenschuiver. De dozenschuiver is slechts een onderdeel in de keten en dienstverlening.

Wat je ook ziet is dat bedrijven met krachtig advies en oplossingen het dozenschuif stukje ook doen en hier een goede marge op maken of relatief veel voor rekenen omdat ze dat stukje namelijk niet goed in klauw hebben. In dat geval zouden ze een goede dozenschuiver in de arm moeten nemen.... Het gaat erom dat de juiste partijen het stukje doen waar ze goed in zijn.

Simple as that.

Helder artikel van een probleem dat zich niet louter beperkt tot het schuiven van dozen maar breder getrokken zal moeten worden. Je komt dergelijke zaken namelijk tegen als onderdeel van de totale problematiek.

Tendering
In de jacht naar goedkoop, goedkoper, goedkoopst, zie je dat met, gedreven door EU regelgeving vaak, tenders moet gaan uitschrijven waar alleen nog maar grote partijen aan te pas kunnen komen. Hier word dan ook meteen het failliet van dit systeem duidelijk. Immers, als alleen, en louter en alleen, 'grote spelers' kunnen worden betrokken bij dergelijke gang van zaken, treed er wettelijk gezien kartelvorming op, en elke betrouwbare 'kleinere partij', zal dan geen enkele schijn van kans hebben of krijgen op deelname in een dergelijk proces. Een andere discussie dus.

vervolgproblematiek/schade
In tweede, en dat is gewoon gemeengoed, worden er tal van concessies gedaan waarbij het regelmaat is dat het binnenhalen van de tender dat men niet meer kan doen aan prijs/kwaliteit verhoudingen waarna 'de klant' vaak wordt geconfronteerd met additionele kosten na het tekenen van de contracten en overeenkomsten.

Disciplines
Omdat er in dergelijke trajecten verschillende IT disciplines bij elkaar komen, zijn er maar heel weinig specialisten op dat vlak die de 'hiaten' in de aanbiedingen van de leveranciers blijken te kunnen inschatten of ontdekken. Daar heb je namelijk enige kennis van zaken bij nodig van de E2E keten van disciplines die betrokken zijn bij dergelijke processen en CEO's en accountants of juristen hebben die kennis doorgaans niet.

Hoe groter de tender hoe groter de problemen en kosten. Dat die soms kunnen leiden tot bijzonder tragische gang van zaken hebben zeer grote ondernemingen in Nederland inmiddels al mogen ervaren in het voorbije decennium waarbij voortijdig afscheid werd genomen van een IT dienstenleverancier. Het gebeurd in elk geval steeds vaker.

Huidige stand van zaken en de economische schade
We zien in de huidige economische stand van zaken ook hier de schade alleen maar toenemen. Heel begrijpelijk maken grote organisaties een pas op de plaats, in het verlengde daarvan de grote IT dienstenleveranciers, die vervolgens waardevolle professionals dan weer laten afvloeien. De schade word namelijk vergroot door het gegeven dat kleine, zeer goede, IT dienstenleveranciers en zzp-ers, volkomen afhankelijk zijn en blijven van die grote namen, waardoor tarieven volkomen worden uitgekleed dat er van fatsoenlijke en gezonde bedrijfsvoering vaak al niet eens meer kan worden gesproken.

En dat, dat ziet men dan weer terug in de zeer grootschalige incidenten die bij de overheid en bedrijfsleven plaats nemen. Mooi artikel die slechts een onderdeel van de gehele keten beslaat.

Ik vind de term "Dozenschuiver" in het artikel foutief aangezien het in mijn beleving gewoon betekent 0,0 ondersteuning.

Als ik daar leverancier invul en de rest van het stuk bekijk, herken ik wel stukken.

Klant heeft een UNIX server staan die een paar taken doet en 2 keer per week een script draait. Virtualisatie leverancier komt langs en doet een P2V en het draait voortaan leuk in de cloud.

Met geknepen geheugen en geknepen omslag lijkt het allemaal goed te lopen. Maar het script dat 2 keer per week draait, doet er opeens 2 keer zo lang over en loopt vaak ook niet goed uit. Script is geschreven ver voor de tijd van de Cloud met geknepen virtuele hosts en verwacht dat een berg lege ruimte heeft in de /tmp directory.

@Henri
Terecht dat je stelt dat de 'dozenschuiver' een vraag in de markt vult. We zijn nu eenmaal zuinig en kiezen al snel voor de 'kiloknaller' in plaats van het duurzame alternatief. Zoals ik al aangeef in mijn artikel is die keus goed te billijken zolang er niet meer verwacht wordt dan er gevraagd is.

Maar zoals je zelf eigenlijk al aangeeft gaat het niet om de componenten maar de keten, de oplossing die duurzamer moet zijn dan de afschrijving van de techniek. De oplossing is namelijk de som der delen waarbij in de praktijk uit verkeerde zuinigheid de service er nog weleens van afgetrokken wordt.

Dat kan gedaan worden om zo scherp mogelijk aan te kunnen bieden, de klant het zelf denkt te kunnen doen of omdat hier voor de verkoper geen winst of provisie te behalen is. En laatste kan zijn oorzaak hebben in het feit dat er geen eigen service organisatie is, wat volgens mij één van de kenmerken van een dozenschuiver is.

@NumoQuest
Een prachtige en mooi aanvullende reactie waar de redactie helaas maar 3-sterren voor geeft. Want inderdaad kan de problematiek breder getrokken worden waarbij je met genoemde punten hopelijk input geeft voor verdere discussie. Zoals tendering waarmee trucs uitgehaald worden die lijnrecht tegenover de doelstellingen van het aanbesteden staan en 'El Cheapo' keukenmeester wordt in de IT.

@Technicus
Zoals ik al een beetje aangeef in mijn antwoord naar Henri zijn componenten niet zo eenvoudig te vervangen als er afhankelijkheden zijn met bovenliggende applicaties en services. En in artikel geef ik aan dat ook het schuiven met virtuele dozen dan geen oplossing geeft, zeker niet als capaciteitsmanagement afwezig was/is.

Prima artikel gewoon zoals het is. Ik begrijp de reactie van Jeroen dan ook niet helemaal (tenzij hij gewoon al dan niet terecht wil afgeven op Unisys, maar dan kunnen we met zijn allen nog wel een heel lijstje maken)
Wat ik eigenlijk ook niet helemaal begrijp is de stelling dat de opdrachtgever eerst zijn huiswerk moet doen.
Daar heb je toch die specialisten voor ? Als ik zelf weet hoe iets moet dan hoef ik natuurlijk geen deskundige meer in te huren.
Anderzijds, is het welicht niet zo handig om het advies door de zelfde partij te laten geven die ook voor de uiteindelijke implementatie verantwoordelijk is.

@Pascal
Als je zelf exact van de hoed en de rand weet kun je prima profiteren van de laagste prijs van een dozenschuiver. Bijvoorbeeld bij vervangen van een groot aantal lossen componenten. Probleem is echter de stapeling van techniek en wijzigingen die een multidisciplinaire visie vragen. Dat overzien vraagt een 'schaap met vijf poten' welke niet altijd bij vragende partij aanwezig is of gewoon te weinig zeggenschap heeft bij beoordeling.

Want wordt beoordeling gedaan door een kudde 'makke schapen' die al in de hoek gedreven zijn door de druk vanuit de organisatie dan worden belangrijke afwegingen nog weleens vergeten. IT wordt namelijk steeds vaker aangestuurd als kostenpost omdat de waarde niet altijd duidelijk is. En de snelheid van gevraagde wijzigingen zonder rem zorgt dan vroeg of laat voor botsingen.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×