Het is al te vaak in het nieuws; grote ict-projecten die falen omdat ze niet niet opleveren wat ze beloven. Kan de oorzaak al liggen bij de manier waarop de eisen zijn beschreven in de 'request of proposal' (rfp) of tender welke aan de aanbieder en het project zijn gesteld?
Uit ervaring weten wij dat request of proposals (rfp’s) en tenders vaak bestaan uit een lijst van vooraf gedefinieerde diensten en architecturen waarin in sommige gevallen zelfs de technologie en ontwikkel-tools gedicteerd worden door de aanvrager. Tijdens het beantwoorden van de verzoeken proberen wij uiteraard een match te vinden tussen wat er gevraagd wordt en de producten uit ons standaardportfolio. Niet zelden betreuren wij het dat de klant niet veel eerder met ons in contact is getreden om inzicht maar wellicht ook inspraak te krijgen in onze productstrategie en standaard ontwikkel-tools en -methodieken.
Natuurlijk zijn wij, maar ook onze collega’s in de markt in staat om oplossingen te leveren die niet precies zo in het portfolio zitten en afwijken van wat algemeen wordt gezien als best practise in de industrie. Maar waarom zou je als afnemer van een dergelijk product dat risico nemen?
Vooraf dicteren
We komen regelmatig voorbeelden tegen waarin klanten bepaalde oplossingen of infrastructurele ontwerpen vooraf dicteren die op het eerste gezicht kosteneffectief zijn en de behoeftes lijken af te dekken. Toch kunnen deze oplossingen op de langere termijn een probleem vormen. Dit kan liggen aan de slechte afstemming van operationeel beheer tussen klant en leverancier, gebrek aan flexibiliteit of aan de introductie van een beveiligings- of beschikbaarheidsrisico vanwege de complexiteit. Ook kunnen te ambiteuse aanvragen en lange ontwikkeltrajecten zonder duidelijke en meetbare succescriteria projecten doen falen. Als we dergelijke potentiële problemen opmerken, zullen we altijd een alternatieve en standaardoplossing bieden, zelfs als dat betekent dat de klant aanpassingen moet doen aan de eigen processen of organisatie.
Helaas gaat een alternatieve oplossing vaak tegen de, veelal rigide, regels in die opgesteld zijn in een tender of rfp. Dit betekent dat er een stap terug gezet moet worden in het aanbestedingsproces om het alsnog mee te nemen. Daarbij komt dat het uitgeven van een nieuwe rfp of aanbesteding vaak onmogelijk is vanwege beschikbare tijd, gebrek aan resources en aflopende contracten, wat dus eigenlijk een gemiste kans voor de klant betekent.
We moeten aannemen dat dergelijke rfp’s met een goed doordachte zakelijke strategie in het achterhoofd zijn opgesteld. Helaas zien we maar zelden dat er een structureel ontwikkel framework of methodologie gebruikt wordt zoals TOGAF 9.x, om alle aspecten van een verandering in de zakelijke architectuur in kaart te brengen alvorens een rfp uit te brengen. Het definieren van een zakelijke architectuur behelst niet alleen het ontwerp van een specifiek stukje technische infrastructuur, de keuze voor een bepaalde fabrikant of leverancier van apparatuur, software of een losse dienst. Het gaat veel verder dan dat.
Business architecture framework gaat over het structureel definieren en ontwerpen van de zakelijke it-omgeving in de breedste zin van het woord. Hierbij houdt het bedrijf rekening met de zakelijke strategie, huidige en toekomstige organisatievorm, beheer en technische capaciteiten, informatie en communicatiebehoeftes, risicomanagement en compliance.
Samenwerking aangaan
Het is te begrijpen dat organisaties niet in staat zijn om hun strategie met elk mogelijke aanbieder van it-producten te delen en advies te vragen. Toch is het raadzaam om een soort van samenwerking aan te gaan met de toonaangevende en vertrouwde leveranciers in de markt, zeker als het om langdurige en kostbare contracten gaat die betrekking hebben op een groot deel van de organisatie. Normaal gesproken zijn het productmanagement en de marketingafdelingen van leveranciers zeer geïnteresseerd in de input vanuit de markt. Het stelt hen in staat om productontwikkelingen te starten of te wijzigen.
Goed georganiseerde leveranciers van it-diensten hebben de mogelijkheden en mensen in huis om de zakelijke strategie te onderzoeken en met een oplossing of architectuur te komen die daar perfect op aansluit. De strategie kan zelfs als input dienen om productontwikkelingen bij te sturen en met nieuwe innovatieve producten te komen.
Houd er wel rekening mee dat een vendor lock-in op de loer ligt en blijf altijd in de rondte kijken. Zorg ervoor dat een eventueel gezamenlijke productontwikkeling iets oplevert wat in andere omgevingen opnieuw gebruikt kan worden. Belangrijk hierbij is dat de acceptatiecriteria en testprocessen goed vooraf zijn gedefinieerd en de organisatie niet als testomgeving wordt gebruikt met alle risico’s van dien. Dit werkt twee kanten op. De leverancier kan het product ook elders verkopen – misschien zelfs aan de concurrent. De eerste afnemer krijgt echter een voorsprong in de zakelijke markt. De leverancier kan dan op basis van economische schaal, kosten besparen en kwaliteit verbeteren. Dat werkt op zijn beurt weer ten gunste van de klant.
Om zakelijk succesvol te kunnen zijn, is het essentieel dat er snel wordt gereageerd op veranderingen in de markt. In de huidige wereld verandert de technologie razendsnel en ontwikkeltrajecten voor nieuwe producten zijn veel korter dan een paar jaar geleden.
Strategie bepalen
In tegenstelling tot de aparte productontwikkeling, kan het definiëren, valideren en initiëren van een gezamenlijke productontwikkeling veel tijd kosten en vele obstakels tegenkomen. Dit is de reden dat de leverancier en klant altijd op zoek moeten zijn om strategiebepaling en productdefinitie zoveel mogelijk parallel te laten verlopen. Waar mogelijk moeten zij continu informatie met elkaar delen. Een permanente en nauwe samenwerking tussen de innovatieteams van de leverancier en de mensen die de strategie in de organisatie van de klant bepalen, is onmisbaar in dit proces en zal helpen de behoeftes van de klant en producten van de leverancier beter op elkaar af te laten stemmen.
It-serviceproviders en leveranciers die in een competitieve en snel veranderende markt willen blijven meedoen, zijn genoodzaakt om goede betrekkingen met hun klanten te onderhouden om hun strategieën op elkaar te blijven afstemmen. Zo kunnen zij workshops organiseren waar klanten met elkaar in een non-verkoopsfeer ervaringen en successen delen. Op deze manier krijgen de klanten, zelfs uit verschillende markten, de kans om van elkaar te leren. Dit geeft de leverancier ook de kans om de productontwikkelingsplannen te valideren tegen de behoeftes van de verschillende klanten.
Graag zou ik dan ook willen aanbevelen om bij de bestaande leveranciers eens te polsen of zij een programma hebben dat een strategisch communicatiekanaal kan faciliteren tussen de mensen die binnen het bedrijf de strategie bepalen en de productontwikkelaars bij de leverancier. Het ultieme doel zou moeten zijn om elkaar continu up-to-date van recente ontwikkelingen te houden en oplossingen te vinden die het succes van beide partijen kunnen versterken.
Prettig om te lezen dat je ook de nadruk legt op de communicatie. Niet alleen op het scherpst van de snede tussen “opdrachtgever” en “leverancier”, maar ook op andere niveaus. Wederzijds begrip en vooral het vermogen om overzicht te houden (van de hele oplossing en vanuit de positie van beide partijen) is key.
Een methode kan hierbij behulpzaam zijn. Echter, het risico dient zich dan aan dat deze van hulpmiddel tot doel op zich verwordt. Hoe goed de methode en tools ook zijn, ze mogen het zicht op het doel niet wegnemen.
Wat ik nu een beetje vreemd vind: In dit artikel wordt de opdrachtgever eigenlijk verweten te rigide te zijn in hun eisen. Ze zouden zich eerder moeten laten adviseren door service providers en it-leveranciers.
Dat moge zo zijn, maar er wordt hier blijkbaar voorbij gegaan aan de verantwoordelijkheid van de opdrachtnemer. Uiteindelijk heeft deze toch een opdracht geacepteerd en zich kennelijk geschikt naar de wensen van de opdrachtgever. Je kunt dan niet achteraf als het fout loopt gaan zeggen: jamaar, eigenlijk was het van het begin af aan al mis omdat die opdrachtgever zo rigide is. Dan had je die opdracht meer niet moeten aannemen.
Roland, je hebt daar helemaal gelijk in. Excuus zal vaak zijn dat dit de enige manier was om de opdracht te krijgen… en er moet wel brood op tafel komen.
Het systeem creëert een situatie die voor niemand goed uitwerkt. De opdrachtnemer begint in een achterstandspositie en levert geen kwaliteit en/of zoekt het in changes. De opdrachtgever heeft de laagste prijs (vooraf) maar krijgt geen kwaliteit en/of een veel hogere eindprijs.
Niet de opdrachtgever, niet de opdrachtnemer maar het model zit dus fout.
Guido de Nobel,
dank voor uw reactie!
Je zegt dat noch de opdrachtgever, noch de opdrachtnemer schuld hebben, maar dat het model oorzaak is van de problemen. Ik zie zelf weinig verschil met het model waarop binnen andere branches zaken wordt gedaan. Toch gebeurt het niet vaak dat als er een weg, brug of torenflat gebouwd moet worden het project faliekant faalt – iets wat bij langdurige ICT projecten toch niet echt een zeldzaamheid lijkt te zijn.
Wat is er dan zo anders tussen deze branches?
Het is nogal makkelijk een proces de schuld te geven, immers, een proces zegt niets terug.
De processen worden volgens mij nog steeds gemaakt door mensen, uitgevoerd door mensen en gecontroleerd door mensen.
Ofwel: de mens is de oorzaak van het falen, niet het proces!
@Pa Va Ke
Euh… wat is het doel van een proces?
Ooit eens iets geleerd over herhaling enzo dus als er een fout in het proces zelf zit is dat dus direct al gauw een herhaling van fouten.
Probleem met veel processen is dat deze ‘disconnected’ zijn, in kader van aanbesteding zie je dan ook nog weleens een spagaat tussen wendbaarheid en zoektocht naar zekerheden. Het hele verhaal over rigide processen is een open deur want alleen het genie beheerst de chaos. En als het over grote ICT projecten gaat dan zit de genaliteit meestal dus niet aan de top van de keten, ooit gehoord van ‘sturen op grote lijnen’ wat dit betreft?
Vraag is wie het proces opstelt en wie hierbij geraadpleegt zijn want ik heb ondertussen iets te vaak meegemaakt dat proces en praktijk net zo ver van elkaar af liggen als de aarde tot Orson. Proces manager versus project manager zullen we maar zeggen als ik kijk de prachtige maar nietszeggende communicatie in grote projecten.
Ja, je hebt gelijk maar falen erkennen is politiek gewoon zelfmoord. Zeg maar zoiets als je hoofd verliezen als ik naar het ontkennen van de feiten kijk. Tenslotte hoef je niet zo ver te zoeken om te begrijpen dat auteur het met name over overheidsprojecten heeft. En wat onvermeld blijft is dat de architecturen van leveranciers altijd puntoplossingen zijn.
Toen auteur begon over TOGAF kreeg ik het idee dat hij de klok wel heeft horen luiden maar nog niet weet waar de klepel hangt, innovatie versus commodificatie. Het gaat inderdaad dus om mensen welke in processen echter vaak gewoon een artifact worden omdat Enterprise architecten liever met een model communiceren. Heb ondertussen ‘praatplaten’ genoeg gezien waar in alle abstracties het doel compleet verloren is gegaan.
Kortom, een opinie waar het van A tot Z om veranderingen in technologie gaat terwijl iets simpels als het startpunt vergeten wordt. Ik moet dan ook nog weleens lachen als de top agile wil werken terwijl de organisatie volgens waterval methode is ingericht. Driemaal raden wat dan de uitkomst is van dat soort projecten.
Ja, ja communicatie is belangrijk maar als ik overweeg dat de meeste beslissers zich niet de moeite getroosten om de taal van de techniek eigen te maken dan kun je leuk ‘buzzword bingo’ spelen. Betreffende je controle ben ik benieuwd hoe vaak de boodschapper vermoord wordt omdat deze geheel tegen de verwachting in met een ander bericht komt.
@Ewout: ik heb wel wat ervaring met processen hoor (o.a. ITIL, CMM(i))
Mijn ervaring m.b.t. processen en tools in een notendop:
– Als eerste geven we het tool de schuld. Ook makkelijk, die zegt niets terug. Vaak dwingen tools een bepaalde manier van werken af, die idealiter gedreven is door een onderliggend proces. In zo’n geval verwijs ik graag naar het proces
– Bij het proces aangekomen, krijgen we een vergelijkbare discussie. Om het proces aan te [willen|laten] passen, moet er in overleg getreden worden met bijvoorbeeld een proceseigenaar.
Eeks, da’s een mens, die sputtert tegen, en als ik alles tegenspreek is dat slecht voor mijn imago of carrière (misschien wordt ik wel als een zeur of lastig gezien)
Maar je opmerking over wie geraadpleegd zijn bij het opstellen van de processen is absoluut zeer herkenbaar.
@Pa Va Ke
Ik lees hier inderdaad nog weleens dat ITIL de schuld krijgt, een beschrijvende in plaats van voorschrijvende best practice. En inderdaad wordt nog weleens geprobeerd om processen als product te implementeren, TOGAF met zijn ADM wordt ook vaak op die manier verkocht.
Terugkomend op de communicatie, deze is met alle technologische vooruitgang wel veranderd maar niet verbeterd. Hoe vaak wordt maar een deel van de mail gelezen, hoe vaak wordt er nagelaten om door te vragen en hoe vaak wordt daardoor de eigenlijk boodschap dus verkeerd begrepen?
Auteur lijkt wat mij betreft in zijn verhaal dan ook te hinkelen tussen de traditionele en open innovatie waardoor ik grote twijfels heb aangaande de boodschap die hij brengt. Wat dat betreft is volgende zin van auteur iets om over na te denken: “…leverancier kan het product ook elders verkopen – misschien zelfs aan de concurrent.”
Snelle time-to-market is een kenmerk van de gesloten innovatie en het beter goed gejat dan slecht bedacht doet de vraag bij mij opkomen of deze managing consultant toch niet van de vragende organisatie een testomgeving voor leverancier maakt. Om terug te komen op mijn eerdere reactie lijkt Orange mij dus – net zoals vele andere organisaties – vooral de verbinding met haar klanten kwijt geraakt te zijn.
Maar goed, Cap Gemini is niet het enige bedrijf dat directe communicatie met de mensen die het werk doen afschermt. Want betreffende processen is het dus een publiek geheim dat de eigenaren hiervan hun koninkrijk er op bouwen, de paarse krokodil situaties zijn dan ook systemisch voor de bureaucratische organisaties als het om rigide processen gaat.
Het probleem hierbij is dat dus meestal niet degene geconsulteerd wordt die het uit moet voeren maar een brallende managing consultant die met wat buzzwoorden strooit terwijl hij geen idee heeft waar hij het eigenlijk over heeft. Tenslotte gaat vooraf aan de RfP soms ook nog een RfI, de marktverkenning die zich helaas wel vaak beperkt tot leveranciers die zich kenmerken in de gesloten innovatie.
Ja, ja ik ben weer ‘mister edge case’ ofzo maar na een week soebatten met architecten uit alle continenten (exclusief Afrika) kan ik concluderen dat de non-verkoopsfeer van delen altijd weer verpest wordt als de verkopers zich ermee gaan bemoeien. De angel zit namelijk in ‘productontwikkelingsplannen’ om terug te komen op de verkoop van processen.
TOGAF? Een afkorting langer dan drie of vier letters moet wel belangrijk zijn. Maar ehm als de deadline daar is, dan is het project TOCHAF?
Als het puntje bij paaltje komt dan zijn het de opdrachtgevers die te weinig verstand van techniek hebben om door te hebben dat ze moreel gezien ondergraven worden door hun leveranciers.
Mogelijke oplossing is om onafhankelijke expertise van een derde partij te betrekken die beide kampen scherp houdt en ze op de vingers tikt als dat nodig is. Kost wel tijd en geld maar verkleint de kans op nog een fiasco.