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.
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.