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

Prijsvechters in de ICT

 

Computable Expert

Ruud Mulder
Advisory Systems Engineer, Dell EMC. Expert van Computable voor de topics Cloud Computing, Infrastructuur en Loopbaan.

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.

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

?


Lees meer over


 

Reacties

Heel goed stukje. Als zelfstandig Project Manager jaren lang allerlei oplossingen geïmplementeerd die door leveranciers scherp qua prijs aangeboden zijn.
Daar zit heel veel bewustwording (soms teleurstelling) in van wat hebben we nu echt gekocht en toch klant aan boord houden. Ruud legt de vinger heel goed op de zere plek.

Ruud, misschien kijk ik er overheen maar ik mis de klant zelf nog.
Een aanbieder voor een oplossing mag een klant er best voor behoeden om onzin specs te vragen en belangrijke items te vergeten.

Je zou b.v. een bakker kunnen afraden een module te bestellen die je adviseert hoe je brood moet bakken. Dat kan die bakker immers zelf veel beter.
Echter je kan hem wellicht wel adviseren een stukje onderhoud op het financiele deel mee te nemen zodat zaken als BTW en andere belastingen keurig bijgehouden worden.

Ik heb wel vaker specs gelezen waar me echt de schoenen van uitvielen en waar ook niemand de achtergrond van kon verklaren. gevolg is dan soms dat aanbieders voor de eer bedanken wat het uiteindelijke product dan niet noodzakelijk ten goede komt.

Pascal,

Zeer valide punt. Er worden soms om de meest rare dingen gevraagd. Vooral tijdens aanbestedingen is dit schering en inslag. En als dit keiharde eisen vanuit de klant zijn dien je hier helaas aan te voldoen.
Doe je dit niet dan is de kans aannemelijk dat je niet wordt geselecteerd. Dat zijn helaas de spelregels van een tender.

De enige mogelijkheid die je hebt is het stellen van slimme vragen waarbij je aangeeft dat dit misschien niet beste oplossing of functionaliteit is. Echter ligt dit politiek wel erg gevoelig en dient de klant wel akkoord te gaan met deze wijzigingen.

Als het niet om een tender gaat dan kan je bijvoorbeeld in een workshop de klant proberen te overtuigen dat dit niet noodzakelijk is. Ook dit is vaak een politiek gevoelige discussie en dient daarom slim en tactisch aangepakt te worden.

Het is van zeer groot belang dat je op het juiste moment met je klant om tafel zit. Kom je te laat in het proces binnen, dan is de kans erg klein dat de klant nog van gedachten gaat veranderen. De juiste timing is ook hier weer essentieel.

Helder verhaal Ruud!

Ik kan niet anders dan beamen dat het zo werkt, helaas.
Alleen een goede relatie met een klant en een verstandhouding die berust op vertrouwen, kan er toe bijdragen dat je wél kwaliteit mag en kan verkopen, waarvoor een beetje meer wordt betaald. Een beetje, dat dan weer wel ...

Het is een prachtig artikel maar we zien dan vandaag ook de resultaten van die prijsvechters aan de andere kant namelijk de bemensing en de salariëring.

We zien dat grootschalige fails en incidenten in de ICT verder toenemen maar ook de calculeerbare schadebedragen van die fails en incidenten. We zien met het verder 'prijsvechten' ook de kwaliteit navenant achteruit hollen.

Het punt van redelijkheid en realiteit is sinds de crisis klaarblijkelijk losgelaten en iedereen heeft het over implementeerbare technische of procesmatige oplossingen die vervolgens meer gaan kosten verder in het proces dan dat zij besparingen opleveren.

Het is prachtig natuurlijk allerlei zaken te benoemen maar wanneer daar verder in de praktijk weinig van terecht komt om dat een paar schakels in de keten incompetent blijkt of domweg niet kan waarmaken wat wordt gepretendeerd, dan is de schaalvergroting wat de schadebedragen betreft helemaal te voorzien te voorspellen.

Helaas zullen we de komende weken/maanden de fails in het bedrijfsleven en overheid zien toenemen door verdere uitfasering van beschikbare kennis en ervaring. De besparingen die men namelijk denkt te bewerkstelligen op die wijze is allang tegen zich gekeerd en ik denk dat het belangrijker is daar oog voor te hebben dan voor een prijzenoorlog in de IT.

Twee wetmatigheden die meer in de IT op gaan als elders is tweeërlei.
1. Goedkoop is duurkoop
2. If you pay peanuts, you'll get monkeys

@ Numo Quest,

Allereerst bedankt voor je feedback. Ik moet toegeven dat ik je mening ook enigzins deel. De komende tijd zullen er nog wel wat meer lijken uit de kast gaan komen.

Vooral in aanbestedingen wordt te vaak op de beste prijs aangestuurd. Hier gaan de aanbieders vaak zeer creatief mee om. Als er niet specifiek om een bepaalde functionaliteit gevraagd wordt, maar deze mischien wel essentieel is wordt deze vaak niet aangeboden. Met onvoorziene kosten en vertraging als logisch gevolg.

Ook heb ik al genoeg trajecten gezien waar in de implementatie vergeten / niet aangeboden was. En zo kan ik nog wel even een tijdje door gaan.

Als prijs het meest belangrijk is, zal dit niet altijd positieve gevolgen hebben voor de geboden kwaliteit van de oplossing.

Ruud,
De punten die je benoemd hebt zijn terecht. Ik denk de voorwaarde van de uitvoering en realisatie van je punten is het mogen (open)communiceren met de opdrachtgever.
Wanneer deze niet bestaat of beperkt is dan heb je als leverancier een uitdaging om je te onderscheiden van andere leveranciers of offerte.

Het wordt nog erger wanneer de (laagste)offerteprijs je score bepaalt zoals bij de aanbestedingen van de overheid. In deze situatie kun je de klant niet toelichten waarom ze onder de streep meer geld kwijt zijn dan bij andere leverancier en tot hoeverre je met hen meegedacht heb over het wegnemen van hun pijn, niet alleen op korte termijn maar ook op lange termijn.

@ Reza,

Helemaal mee eens. Aanbestedingen blijven altijd zeer uitdagend. De enige kans die je daar hebt is om slimme vragen te stellen. Echter is mijn ervaring dat deze vaak ontwijkend worden beantwoord.
Meestal verduidelijkt een NVI niet echt veel.

Ik ben bang dat er in aanbestedingsland voorlopig nog niet veel gaat veranderen. Prijs zal door de huidige recessie de komende tijd hier nog de belangrijkste factor zijn.

@referenties
Een referentie zegt niets of de leverancier ook het pve kan waarmaken en sterker nog het verstart de markt want:
1. een slechte referentie zal een leverancier niet opgeven
2. een referentie is achterhaald in vergelijk met een pve waar op aangeboden wordt,
omdat er dan een tijdverschil van zeker 2 jaar zal zijn. De bezoeker ziet dus iets
ouds, dat ook nog eens niet vergelijkbaar is met wat hij zoekt.
Exit strategie?
3. Referenties worden in een PVE vaak gebruikt als exit strategie: de leverancier moet
net zo iets gedaan hebben en dan graag x keer. Op die manier kan geen enkele
leverancier groeien.

Er zijn betere mechanismen inmiddels, zoals POC/POD, proof of concept of proof of delivery

@onderhoudskosten

Voorspellen is moeilijk als het de toekomst betreft (vrij naar...), maar toch . Prima punt dus, maar er zijn leveranciers (producenten?) die zelfs zo ver gaan dat in het kader van het onderhoud er ook een verplichte (!) upgrade van de hw en sw gedaan moet worden om het onderhoud te kunnen garanderen, (k.k. dus, kosten klant).

Het is interessant om dat in een TCO plaatje te verwerken, omdat het effect er van is dat zo'n upgrade in een latere fase van de levensduur van een infrastructuur de TCO kosten in de praktijk al snel verdubbeld.

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.

In principe zijn er drie dimensies, die inhoudelijk behandeld moeten worden: techniek (functionaliteit), organisatie en financien. De meest praktische weg is eerst T en O, want die bepalen in de meeste situaties F. De focus eerst echter op F betekent dat de inhoud nooit meer leidend gaat worden.

Juist bij communicatie-infrastructuren, die "ongestoord" 6 tot 12 jaar mee moeten gaan, is de inhoud belangrijk, nee essentieel, misschien zelfs wel cruciaal.

Over het algemeen zijn communicatietoepassingen geen commodities en daardoor zou de prijs niet leidinggevend, maar hooguit richtinggevend moeten zijn in een aanbesteding.
Dit bijvoorbeeld in tegenstelling tot de aanbesteding van gebruikersapparaten...... dat is wel weer 20 krentenbollen in een dozijn en dus een commodity.

@ All,

Allereerst bedankt voor alle reacties. Het was zo te zien een hot topic. En ik heb al weer genoeg inspiratie op gedaan voor een nieuw artikel.

Helaas wordt er tegenwoordig te veel als commodity gezien. Complexe storage omgevingen, Cloud platforms, SAP omgevingen etc.etc. alles is tegenwoordig commodity.

Ook bij tenders en RFP's is de laagste prijs 9 van de 10x nog steeds het meest belangrijk. En als dit een keer niet het geval is, dan wordt het voor de kleinere partijen door de hoge eisen op het gebied van referenties nog steeds onmogelijk gemaakt.

Kwaliteit en de juiste oplossing is steeds vaker ondergeschikt ten op zichte van een scherpe prijs.

Maar mijn ervaring is dat een scherpe prijs na afloop van het project vaak een stuk minder scherp is.




@Ruud,

Het is erg jammer dat bij een EU-aanbestedingsprocedure, waarbij eerst op de laagste prijs geselecteerd is, er geen boete op staat wanneer na oplevering er een hogere prijs is ontstaan door:
- meerwerk
- wijzigingen onderweg
- "missertjes" in de rfp tekst, die geld, €€'s kosten
- uitloop van het werk
- meer personele inzet dan vooraf opgegeven (gecalculeerd?)
- te laag inschrijven om de opdracht te "kopen"
- "projectorganisatie- en management"

Deze "puntjes" herinvullen in de financiële evaluatie zal in veel laagste prijs aanbestedingen een andere ranking geven.

Goed punt Maarten!

Op deze manier zullen de prijsvechters die nog wel eens slim trucje uithalen in het nadeel van de klant, zich nog wel even achter de oren krabben.

Echter denk ik dat dit helaas wel een utopie is en nooit zal gaan gebeuren. Maar wie weet......Fingers crossed.

@Ruud,

ik heb ook niet de illusie dat het verleden achteraf te repareren is, maar het is wel zinvol om van het verleden te leren en te zien of de winnaar ook de echte winnaar is, na afloop van de invoering. Op die manier kan het volgende PvE en het selectie- en invoeringstraject weer een stukje scherper zijn.

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

×
×