Supermarkten strijden om de gunst van de klant middels het aanbieden van zaken als voetbalplaatjes, spaarzegels, wuppies en Eftelingspaarkaarten. Ook in de ict is een soort supermarktoorlog losgebarsten tussen de verschillende ict-leveranciers. Want hoe kan een ict-leverancier ten tijde van de crisis nog het verschil maken? Het antwoord is kort maar krachtig: door middel van de prijs. Ondanks het feit dat iedereen roept dat kwaliteit, vertrouwen en goed advies belangrijk zijn, geeft de prijs helaas vaak de doorslag. Op zich een logische tendens in deze zware economische tijden. Maar is de oplossing van de scherpste prijs wel altijd de beste?
Dit is en blijft altijd een lastig punt. Voor een dubbeltje op de eerste rij zitten kan namelijk leiden tot teleurstellingen. De vele rfp's, aanbestedingen en minicompetities die uitgeschreven worden, sturen echter nog te vaak aan op de scherpste prijs, hetgeen de kwaliteit niet altijd ten goede komt.
Het aansturen op de scherpste prijs kan resulteren in het gemis van cruciale functionaliteiten in de aangeboden oplossing. De geleverde oplossing kan beperkt of zelfs nog erger helemaal niet schaalbaar zijn. Ook kunnen er zeer hoge verborgen kosten zijn voor onderhoud of support. Want een leverancier moet uiteindelijk toch weer het geld dat hij misloopt, doordat hij de oplossing aanbiedt tegen een lage prijs, terugverdienen.
Fiasco voorkomen
Al deze zaken kunnen er toe leiden dat het project waar men zeer enthousiast mee is gestart, uitgroeit tot een groot fiasco. Praktijkvoorbeelden waar bijvoorbeeld het onderhoud of de implementatie weg gelaten is kom ik helaas nog te vaak tegen.
Hoe bescherm je jezelf als organisatie nu tegen bovengenoemde zaken? Het antwoord is eenvoudig: laat prijs niet de enige wegings/beslissingsfactor zijn. Een scherpe prijs is gezien de recessie een must maar de eerder genoemde voorbeelden kunnen uiteindelijk leiden tot een veel hogere prijs. Het is daarom goed om rekening te houden met een aantal voorwaarden:
• Schaalbaarheid
Hoe schaalbaar is de aangeboden oplossing? Dekt dit de periode waarover de oplossing afgeschreven moet worden? Schaalbare en modulaire oplossingen kunnen initieel kostbaarder zijn maar zullen uiteindelijk goedkoper zijn.
• Implementatie/migratie
Vaak wordt hier door leveranciers op bespaard of wordt dit helemaal buiten beschouwing gelaten als hier niet specifiek om wordt gevraagd. Een basisimplementatie is vaak relatief snel vergeten maar als er uiteindelijk een datamigratie gedaan moet worden kan het een dure aangelegenheid worden als deze kosten vooraf niet meegenomen zijn.
• Onderhoudskosten
Laat de leverancier de kosten voor onderhoud/support vooraf in kaart brengen. Bij voorkeur voor de gehele periode waarover de oplossing wordt afschreven. Zo maak je het inzichtelijk en kom je niet voor verrassingen te staan.
• Functionaliteit
Laat de leverancier de functionaliteit van de aangeboden oplossing inzichtelijk maken. Wat wordt er standaard bijgeleverd en welke functionaliteit kan er later nog toegevoegd worden? En last but not least wat is het prijskaartje om extra functionaliteit toe te voegen?
• Roadmap aangeboden oplossing
Eén van de belangrijkste punten is de roadmap van de aangeboden oplossing. Hoe lang is oplossing nog leverbaar en uitbreidbaar? Het kan namelijk zijn dat er een oplossing aangeboden wordt tegen een zeer scherpe prijs maar dat deze over een paar maanden uit het assortiment wordt gehaald. Of erger, dat er voor deze oplossing over een x aantal maanden geen uitbreidingen meer te leveren zijn.
• Referenties
De overvloed van al het beschikbare veelal op marketing gebaseerde materiaal maakt dit tot een lastig punt. Vraag de desbetreffende leverancier daarom om enkele referenties. En neem contact op met desbetreffende referentie. Een kort bezoekje of belletje verheldert meer dan een PDF waar alleen maar in staat hoe fantastisch de gekozen oplossing is.
Bovenstaande punten dienen in mijn ogen altijd mee genomen te worden tijdens de selectiefase. Zoals ik hier al vaker heb geroepen, kan een simpel consumentenbondoverzicht een hoop ellende besparen. Stel vooraf een lijst met beslissingscriteria (wensen/eisen/functionaliteit/prijs etc. ) op en verwerk deze in eerder genoemd overzicht. Hiermee kun je appels met appels vergelijken en wordt de kans op onvoorziene kosten een stuk kleiner.
Maarten,
Goed punt over de referenties. Tegenwoordig worden er tig referenties gevraagd met name in aanbestedingsland. Als je daar niet aan voldoet lig je eruit. Het is daarom voor de nieuwere/kleinere partijen lastig om hier aan te voldoen.
Ook ben ik mij er van bewust dat de waarde van een referentie altijd lastig te bepalen valt. Echter is het wel een soort van bewijs dat de leverancier het al een keer succescol heeft gedaan. En het kan altijd even handig en leerzaam zijn om een referentiebezoek of gesprek met desbetreffende eindklant te hebben.
Een POC is natuurlijk de mooiste vorm om te zien of de leverancier ook alles kan uitvoeren wat hij beloofd heeft. Echter is het wel zaak om vooraf duidelijke deliverables op te stellen. Anders kan het nog wel eens zeer tijdrovende aangelegenheid worden.
Ruud dank je voor je zeer heldere toelichting. Ik moet toegeven dat ik nooit zelf direct met een aanbesteding te maken heb gehad maar de problemen die je beschrijft en onderbouwd geven een goed beeld waar we mee te maken hebben.
De reacties van colega’s bevestigen dit slechts.
Nu hebben we het in de ICT altijd over zaken als ‘best practices’ het zou toch mooi zijn als dit al zou beginnen bij de opdrachtgever. Daar zou dus ook best eens aandacht aan besteed mogen worden. maar ik geef toe dat je dat bij een grote opdrachtgever nooit spits krijgt, met de bekende faalprojecten als resultaat.
Jammer ik lees hier zoveel zinnige reacties…. het moet toch mogelijk zijn het tij te keren.
Ik stap wat laat in, maar gedreven door mijn huidige actualiteit wil ik toch wat toevoegen.
Ik doe veel in software trajecten. Als je van te voren realistisch en echt doorrekent wat de softwareontwikkeling en implementatie gaat kosten is er geen opdrachtgever meer die eraan zal beginnen.
een paar duimregels die ik hanteer zijn o.a.:
– Testen kost net zo veel tijd als ontwikkelen
– De tijd die ontwikkelaar(s) nodig hebben om software te maken is gelijk aan het aantal uren dat de opdrachtgever er in moet steken tijdens datzelfde traject.
Zeer, zeer zelden is de opdrachtgever bereid hiertoe. Daardoor worden projecten vaak JSF-en, Betuwelijnen, Noord-zuid lijnen, HSL-len en ga zo maar door.
Als je van te voren weet hoeveel tijd, moeite en geld in kinderen gaat zitten begin je er niet aan, maar achteraf gezien ben je blij dat je het gedaan hebt 🙂
Henri helder ! en ook je laatste zin had ik nooit overwogen.
Helaas strookt dat niet echt met je voorbeelden.
Zaten we echt te wachten op die extra spoorlijntjes en die gekunstelde vliegmachien.
Als we zo graag geld over de balk smijten denk dan ook eens aan mijn bankrekening, daar is nog genoeg plek voor veel geld.
Ruud,
Een herkenbaar stuk maar opstellen van een overzicht, wat feitelijk al een beetje gedaan wordt in veel RfP’s is minder eenvoudig dan gezegd. Het zal Werk in Uitvoering blijven omdat bijvoorbeeld wijziging van firmware in een technisch component al tot hele andere resultaten kan leiden. Gelijke componenten zijn misschien wel te vergelijken maar hun inzet kan heel verschillend zijn en in combinatie met andere bepalen ze vaak de kwaliteitsattributen zoals bechreven in ISO-9126 van een systeem. Opvallend vaak worden trouwens eisen als overdraagbaarheid, onderhoudbaarheid e.d. geëist maar worden ze niet getest, tenminste niet tijdens project.
De praktijk van hoe het echt werkt, waar de aandachtspunten zitten en welke combinaties werken of niet vind je ook niet in referenties maar de ‘knowledgde bases’. Maar die doorzoeken, waarbij meerdere combinaties moeten worden vergeleken kost tijd en omdat vaak een gratis advies verwacht wordt, is dat dus wegbezuinigd. Nu wordt de mening van techneuten soms ook niet gewaardeerd en de zeer valide argumenten worden dan weggejorist als: ‘IT (beheer) zet weer zijn hielen in het zand’ of ze worden wel gemeld maar als ‘boom in het bos’ verstopt. Deze truc wordt trouwens door zowel de aanbesteder als opdrachtnemer uitgehaald waardoor bestekken en contracten steeds dikker worden.
Als later blijkt dat er op ‘bugs’ gebouwd is waardoor updates aan besturingssysteem, wijzigen van drivers of aanpassen van firmware niet kan dan wordt de geplukte kip soms een plofkip. Want hoewel techniek, de bakstenen van een oplossing steeds meer ‘commodity’ zijn geworden en door de vele aanbieders een vechtmarkt waar niet veel brood te verdienen valt zit het verschil in de vlijt, het extra stapje dat nodig is om alles goed in te richten en degelijk te beheren. Dat is nimmer standaard en valt altijd tegen omdat processen afwijkend zijn, incompleet of enkel op papier aanwezig. Ook PoC/PoD of andere ‘sandbox’ technieken besteden hier vaak geen aandacht omdat alle focus op het functionele ligt, het onderhoudbare is een latere zorg die graag uitbesteed wordt.
Zuinigheid met vlijt bouwt huizen als kastelen is een oud gezegde wat ook hier van toepassing is maar wanneer deze op de kennis gedaan wordt zijn het wel luchtkastelen. Techniek is inwisselbaar, de ervaringen niet en dus stoten we ons steeds tegen dezelfde steen waardoor aanbestedingen alleen maar moeilijker worden maar niet beter.
Ewout:
Ik ben het niet met je stelling omtrent “referentie” eens!
Ik heb een aantal trajecten meegemaakt waar ik op de stoel van opdrachtgever zat. Een duidelijke RfP, met gestructureerde informatie over de situatie, de vraag, de eisen en wensen en criteria `s is de eerste stap.
Hoe meer duidelijkheid in deze fase hoe makkelijker in de volgende stap om appels met appels te vergelijken. Wanneer de offerte van een aanbieder gestructureerd en modulair opgebouwd is(zoals je dat in RfP beschreven hebt) dan is het makkelijk om bijna alles qua kosten voor een periode van x jaren zichtbaar te maken.
Een beeld van de betreffende leverancier dat je al op papier gekregen heb, kun je verder verduidelijken wanneer je een bezoek aan de referenties brengt. Een bezoek aan 2-3 referenties, gesprek over wat ze gehad hebben, wat hen beloofd was, hoe dit gerealiseerd is en vooral de vraag “ met de kennis van nu, zou je toen het project aan deze leverancier gegund hebben?” kun je meer over deze leverancier te weten komen.
Mijn project was anders dan die van de referentie, maar er zijn genoeg onderwerpen die in beide projecten terugkomen. Hierdoor had ik een beter beeld van de leverancier.
Ik hecht geen waarde aan PoC! Hoe zou je bijvoorbeeld als leverancier met een PoC kunnen aantonen dat je ervaring hebt met complexe Exchange migratie met veel verwevenheid in het applicatielandschap ? Twee machines neerzetten en Exchange van ene naar andere overzetten zonder productieactiviteiten erop, kan iedereen.
Ik hecht wel waarde aan wat ik van de referentie gehoord heb over hoe hun Exchange door deze leverancier gemigreerd is en welke zaken slecht of goed zijn gegaan.
Terug naar mijn argument eerder, communicatie met leverancier in verschillende offertefase is zeer essentieel voor het vinden van de juiste oplossing. En deze juiste oplossing kan hogere prijs hebben dan andere offerten.
Dag Ruud
als ik naar mijn tak van sport kijk: “ontwikkeling van communicatietoepassingen en communicatie-infrastructuren”, dan wordt er met regelmaat gevraagd naar een identieke omvang in de referentie als de klant zelf zoekt. Dat is m.i. niet terecht, want als je 2000 VoIP of LAN poorten gedaan heb kan je er ook 4000 realiseren met de zelfde kwaliteit, kennis en kunde en eindresultaat. Natuurlijk is het meer werk, maar niet fundamenteel meer of andere kennis.
Natuurlijk maakt het type organisatie ook uit, maar alle ziekenhuizen hebben het zelfde eindproduct: “leven of dood”. Voor de communicatie-infrastructuur is er dan een grote mate van overeenkomst voor dat type organisaties (hoge uptimeproductie etc).
Het is ook, juist voor de markt van belang dat met zorg omgegaan wordt met het vragen van referenties om de goede partij te selecteren, niet om het als “legaal” afval middel te gebruiken.
Organisaties krijgen de antwoorden waar ze naar vragen. Ga je op zoek naar inhuurkrachten middels een elektronische veiling dan kan de kwaliteit van de senior projectleider van 58 Euro per uur tegen vallen.
Zeker de grote IT dienstverleners hebben teams gespecialiseerd in het beantwoorden van tenders. Hierbij is een belangrijke activiteit om te zoeken in de vraagstelling naar manieren om de tender te winnen.
Alleen antwoord geven op de gestelde vraag. Het verschil daarvan met de werkelijk benodigde oplossing is het meerwerk waar de marge later mee terugverdiend wordt. Eerst winnen, dan verdienen.
Er zijn modellen waarbij de beoordeling wel meer kwalitatief plaats vind. In de praktijk worden die echter nog weinig toegepast.
@Reza
Je hebt gelijk, tenminste vanuit jouw referentiekader omdat als ik het zo lees je vooraf een gedegen onderzoek gedaan hebt. In je vlijt heb je waarschijnlijk gezorgd dat je appels met appels kon vergelijken en peren met peren. Waneer het gevraagde/gewenste/vereiste goed helder is dan kan je op basis van het door Ruud geschetste ‘Consumentenbond’ overzicht de beste koop bepalen.
In veel aanbestedingen is dit echter niet helder en voegen referenties niets toe, zeker niet als ze ‘objectief’ zijn gemaakt met eisen over volume, waarde e.d. Maarten chargeert misschien met de ‘leven en dood’ case maar heeft wel gelijk want het gaat om de business van vragende partij en niet om die van de aanbieder. Dit soort ‘zekerheden’ zijn dan ook de doodsteek voor kleine en gespecialiseerde partijen en doet onrecht aan doelstelling aanbesteden.
Ook betreffende je communicatie met de leverancier heb je wederom gelijk, ware het niet dat ik hier het vermoeden heb dat dit vooral ‘peer-to-peer’ is. Je waardeert waarschijnlijk wel de mening van techneuten, spreekt hun taal en begrijpt hun zorgen. Maar vaak is dit niet het geval omdat er een beeld is dat beheer standaard is en dus voor de goedkoopste oplossing gekozen wordt. Dat men hierdoor vaak in een ‘framed’ oplossing komt die later door aanvullende licenties, aanpassingen e.d. duurder blijkt is wat Ruud volgens mij beschrijft in zijn artikel.
Belangrijke oorzaak van de (te zware) focus op de financiele aspecten van de inkoop van IT (en andere) diensten is schaalgrote en regelgeving. Zo gauw overheden of organisaties groter worden of de regelgeving (Europees aanbestedingsrecht) een rol gaat spelen, wordt het correct formuleren van de inkoopvraag belangrijker dan het poplossen van het echte probleem. Niet de IT-er of probleemeigenaar, maar inkoop, externe adviseurs en financiele experts gaan de vorm van de uitvraag bepalen.
Dit zorgt wellicht voor het inperken van de risico’s maar gebrek aan kennis van het probleem en zijn contet maakt dat de aangeboden antwoorden veel verder van de oorspronkelijke vraag staan dan de bedoeling zou moeten zijn.