Grip op IT systeemintegrators

by marc 18. november 2010 23:52

De trend is dat bedrijven steeds verder teruggaan in hun aantal IT-leveranciers. Doel is om de overgebleven leveranciers te prikkelen mee te denken met het bedrijf en en passant standaard uniforme werkwijzes bij de business af te dwingen. Vragen die dan direct opkomen zijn: - hoe bereiken we dat gedrag bij leveranciers? - hoe houden we grip op zulke leveranciers tijdens projectuitvoering?

Hieronder mijn gedachten.
Bij projecten die ik meemaak lijkt de de leverancier met name aangestuurd te worden aan de hand van gewenste opleverdata die op hun beurt zijn afgeleid uit de mengeling van businesswensdatum en door de IT-demandorganisatie verwachte benodigde inspanning.
Dit kan best anders ingevuld worden. Geef de leverancier inzicht in de businesscase van het project en stel de beloning voor de projectuitvoering aan de hand daarvan vast. Laat de leverancier ideeen op tafel leggen voor het maximaliseren van de businessbenefits. Dit moet de leverancier prikkelen tot een efficiente standaard oplossing met de gewenste businessfunctionaliteiten.
 

Toezicht op de zo'n oplossing zit in de aanhoudende monitoring van de deliverables die tussen supply en demand uitgewisseld worden. De uitdaging voor demand zit 'm er niet in om de deliverables op tijd te willen.
De uitdaging ligt in het bereiken van overeenstemming tussen supply en demand dat de inhoud optimaal bijdraagt aan de business benefits. Eenvoudiger gezegd: de deliverable voldoet aan afgesproken criteria.

Het begint dan bij een globale impactanalyse. Omdat standaardprocessen het best met COTS-producten worden uitgevoerd zou een globale impactanalyse een indruk moeten geven van de mate waarin businessprocessen nieuw zijn of reeds uitgevoerd worden. Daarnaast moet een Globale Impact Analyse indruk geven in de mate waarin COTS-componenten ongewijzigd gebruikt kunnen worden of aangepast moeten worden. Uiteindelijk hebben opdrachtgever en leverancier het hetzelfde beeld bij de volgende projectfase die dan van start gaat.

De deliverables detailanalyse tot en met (eventuele) programmacode worden door de leverancier opgesteld. Alle functionele documenten (detailimpactanalyse, solution design, functioneel ontwerp, business rules) zullen door een keyuser, tester en leverancier beoordeeld moeten worden. Dit doen we natuurlijk nu al...Ik denk dat het ook belangrijk is om bij elke beoordeling ook de vraag te stellen: 'wat schatten we nu in als doorlooptijd voor het vervolg?'. De antwoorden op die vraag zouden zelfs tot een andere oplossing kunnen leiden. Immers doordat de betrokkenen al wat gelezen, gezien, geprototyped etc hebben is meer kennis vergaard en ontstaat een beter beeld over de uiteindelijk gewenste oplossing. Elke keuze op dat moment draagt dan bij aan de businesscase.
De technische deliverables lijken we nu vaak in z'n geheel over te laten aan de supplier ('we hoeven toch niet te beoordelen of de leverancier zijn eigen processen efficient uitvoert?'). Door hier wel afspraken over te maken, geven we aan dat we dit serieus nemen en dat het in ons beider belang is dat de supplier zijn eigen processen efficient uitvoert. Het lijkt mij bovendien vanuit het oogpunt van mogelijke overdraagbaarheid naar een andere leverancier in de toekomst verstandig dit in de gaten te houden.
 

Aan het eind nog even ruimte voor een disclaimer. Het kan natuurlijk ook zo zijn dat het beter is om een hele business proces te outsourcen. Dan is bovenstaande niet van toepassing.

Tags: , , , , ,

Mogelijk Interessant