Kern van agile-werken is omgaan met onzekerheid, onderling vertrouwen en samenwerking. Helaas passen de inkoopprocessen van veel organisaties nog niet bij deze uitgangspunten. Veel organisaties kopen hun software volgens hetzelfde proces als waarmee ze hardware, kantoormeubelen of paperclips aanschaffen. Dus: duidelijke specificaties, een vaste prijs en alle risico’s voor de leverancier.
Inkoop doet dit naar beste eer en geweten en is volledig verantwoord bezig: 'Het proces is succesvol doorlopen dus zal de uitkomst wel goed zijn'. Dit is zekerheid afleiden uit een voor-gedefinieerd proces. Inkoop weet al jaren hoe ze softwareprojecten op deze manier moeten inkopen én ze weten ook dat deze projecten hierin mislukken. Dat is op dit moment de enige zekerheid die ze kunnen bieden.
Kern van de misvatting is het traditionele inkoopmodel voor complexe producten waarin inhoudelijk de experts de specificaties van het product vaststellen en inkoop hiermee de markt ingaat om op basis van de specificaties de beste prijs te verkrijgen. In het geval van (maatwerk)software is het succes van het ingekochte product sterk afhankelijk van de competenties van de medewerkers van de leverancier en de vaardigheid in het uitvoeren van een softwareproductieproces. Dit wordt in veel gevallen niet meegewogen in de inkoopcriteria. De factoren competentie, proces en team zijn juist vanuit agile-projecten bepalend voor het succes.
Daarnaast is de potentieel te creëren business-value ook geen scoringsfactor in de inkoop. Er wordt gestuurd op zo laag mogelijke kosten van aanschaf en niet op een zo hoog mogelijk gecreëerde waarde. Dat is logisch als de specificaties al vast staan.
Dit is een dubbele diskwalificatie voor agile-projecten. Ten eerste geeft agile zeker geen 100 procent garantie voor wat betreft het voldoen aan de specificaties. Op het gebied van kosten legt een goed op elkaar ingespeeld agile-team het altijd af tegen een op low-costs samengesteld team.
Agile inkopen
Inkoop van agile-softwaretrajecten moet voldoen aan alternatieve selectiecriteria. In dit proces moet ervaring in agile-processen én te creëren waarde zwaar meewegen. Inkopers werken in deze trajecten nauw samen met de inhoudelijke experts van de inkopende organisatie. Deze criteria en deze wijze van selectie meet in feite de mate van vertrouwen van de inkopende organisatie in de leverancier. Dit zijn wel wat zachtere factoren maar zeker meer effectief. Een traject dat start met een sterk onderling vertrouwen is vrijwel garantie voor projectsucces.
Ik heb het artikel 3 keer gelezen, en mij ontgaat helaas volledig het agile aspect van het artikel.
Zelf werk ik in een niet agile organisatie, maar ook bij ons werken de inkopers samen met de inhoudelijke experts van onze eigen kant. Daar is in mijn ogen niets “agile” aan, maar is een kwestie van gezond boerenverstand. De inkopers hebben immers niet de know-how om offertes inhoudelijk op techniek te beoordelen.
Onderling vertrouwen / samenwerking is ook iets voor de hand liggends. Vooral als je plannen hebt om meerdere exemplaren van je eindproduct te verkopen moet je wel vertrouwen hebben in een vruchtbare samenwerking. Voor software heb je wellicht maar 1 levering nodig die je telkens weer kunt hergebruiken, maar op het moment dat er ook hardware of mechanica bij komt kijken dan wil je er wel van op aan kunnen dat de leverancier aan zijn verplichtingen kan voldoen. Ook hier weer, gezond boerenverstand, niets agiles
Als laatste het omgaan met onzekerheden bij leveringen van derden. Ook dit is niets vreemds, maar meestal noemen we dit het leveren van prototypen. Ook zonder agile kunnen we hier heel goed mee overweg
Wel ben ik het er mee eens dat het inkopen van complex maatwerk een ander proces vergt dan het inkopen van een standaard paperclip of kladblok. Echter, dit staat mijns inziens helemaal los van al dan niet agile werken.
In een groter artikel over PRINCE2 en hoe deze aanpak vaak met voeten wordt getreden, heb ik het volgende stukje geschreven over afseren en aanbesteden.
“Er is dus veel voor te zeggen om een project op te delen in voor de klant logische stukken. Het faseren wordt gebaseerd op risico’s en business producten en heeft daarmee een sterke relatie met de vorige principes. Wederom is de klant leidend met de zakelijke rechtvaardiging (Business Case) en zakelijke producten in de hand. Faseren is de belangrijkste vorm van risicobeheersing en gaat ervan uit dat een substantieel project niet volledig in detail te plannen is; er is sprake van een “planningshorizon”.
Het principe van beheersing door fasering wordt helaas ook vaak met voeten getreden, met negatieve gevolgen voor besturing en effectiviteit. Denk eens aan aanbestedingen. Vaak wordt een project volledig aanbesteed terwijl eisen en wensen onvoldoende bekend (kunnen) zijn. De uiterst kostbare gevolgen van deze praktijk kunnen aanzienlijk beperkt worden door fasering en aanbesteding per fase op zakelijk gronden, op basis van onzekerheid/risico. Het is cynisch dat de kostbare verspilling die ontstaat uit het onrealistische detailplannen van een volledig project, vaak voortkomt uit denken in budgetten, gericht op financiële beheersing. Zoals zo vaak zijn traditionele financiële structuren (budgetten) erg ineffectief en daardoor verspillend.”
Dit heeft te veel meer betrekking op projectmanagement dan op een ontwikkelaanpak zoals Agile. Maar vanuit een projectmanagement optiek herken ik wel wat de schrijver hierboven aanstipt.
De essentie is het verschil tussen de inkoop van een product en een dienst. Bij traditionele software ontwikkeling is het uitgangpunt dat een product gekocht wordt op basis van specificaties. Bij agile ontwikkeling wordt kennis en kunde ingekocht om een product te realiseren. De schrijver stelt terecht dat in het eerste geval de specificatie het uitgangspunt is en in het tweede geval de competenties en vaardigheden. Het eerste geval is natuurlijk een illusie wat tot de nodige teleurstellingen leidt.
Inkoop wordt in grote organisaties gestuurd om bepaalde doelstellingen te halen. bv
– Het aantal preferred suppliers terugdringen met 20 pct
– Op iedere offerte minimaal 10 pct extra korting bedingen
– alleen op eigen inkoopvoorwaarden inkopen, ipv verkoop voorwaarden van de leveranciers
En het is voor deze mensen een doel geworden, terwijl inkoop natuurlijk een facilitaire afdeling is binnen het bedrijf.
Tuurlijk gaat dit goed voor nietjes, kopieerpapier en pennen.
Maar het slaat totaal de plan mis met agile-projecten die software bevatten. Eigenlijk zou je inkoop voor die trajecten moeten kunnen bypass-en.
@Chris
geldt dat niet voor alle projecten die software bevatten, of ze nu agile of waterval of wat anders zijn?
Agile is helaas tot een mooi buzzword geworden, dat in sommige kringen meteen de aandacht krijgt, maar in de context van dit hele verhaal (zoals ook al in mijn 1e reactie schreef) zie ik gezond boerenverstand, en niets specifiek agile
Een late reactie, omdat een collega me recent pas attent maakte op dit artikel uit 2011. Zelf heb ik 12 jaar in de IT-sector gewerkt, een deel vd tijd als inkoopmanager. De term ‘agile’ zegt me niets, misschien loop ik daarin achter. Ben ook al een tijd niet meer in het veld werkzaam.
Als langjarige inkoper kan ik wat Robbrecht beweert niet in de actuele context plaatsen. Op zich klopt wat hij schrijft inhoudelijk wel, de aannamen mbt inkoop en inkoopmodel zijn echter falikant fout. Het traditionele inkopen dat hij beschrijft past wellicht nog in de bedrijfscultuur van de jaren 60 en 70. Sindsdien heeft het vak zich ontwikkeld en zal het heel moeilijk zijn nog een collega te vinden die denkt dat (niet-standaard)software, complexe producten of ontwikkelingen, kunnen worden ingekocht als eenvoudige / standaardproducten. De wijze van inkoop wordt altijd aangepast aan de materie en aan de markt en is altijd teamwerk met materiedeskundigen samen. De eerste 15 jaar dat ik als inkoper werkte, waaronder interim vanuit een bureau en bij diverse organisaties was alles belangrijk, behalve de prijs. Juist de factoren als betrouwbaarheid, ervaring, goed opgeleverde referentieprojecten, etc etc figureerden altijd in de criteria.
Veeleer kan er sprake zijn van een invloed die Robbrecht vergeet expliciet te noemen: de aanbestedingsplicht die voor veel (semi)overheidsorganisaties geldt en die – o.a. door steeds stringenter jurisprudentie – inkopers vrijwel dwingt om complexe zaken / diensten toch ook in standaardtermen vast te leggen en verplicht op de markt te zetten. De uitdaging voor professionele inkoop is ook hier niet alleen te focussen op het product maar – analoog aan de stelling van Robbrecht – op de selectie van een goede partij, waarbij bijvoorbeeld de kwaliteit van softwareontwikkeling voorop staat. En het eindproduct zoveel mogelijk functioneel wordt beschreven. Ook heeft de inkoper nog de keuze voorafgaand aan de aanbesteding een marktverkenning te doen en zich door diverse partijen (en door interne deskundigen) ‘wijs’ te laten maken om tot de juiste keuzefactoren te komen en zo het beoogde resultaat te realiseren.
Omgekeerd, tenslotte, moet de inkoper er wel voor waken dat de eigen IT-organisatie niet komt met teveel beperkende of richtinggevende specs die leiden tot slechts één aanbieder. Dat kan bv de best bekende aanbieder zijn, maar is niet persé de beste aanbieder. In het goed leiden en begeleiden van dergelijke processen realiseert de inkoper zijn/haar meerwaarde.