Thank you for taking the time to report the following comment to the administrator of this site.
Please complete this short form and click the submit button to process your report.
Standaard ISO TR-9007 (1983 en 1986) spreekt over iets dat Universe of Discourse heet. Dat is de wereld waarover wij spreken, en dat kan van alles en nog wat zijn. Het is voor die wereld dat we over een passende informatievoorziening spreken. Dat is dus precies bijvoorbeeld de informatievoorziening gedurende bouwprojecten in de fysieke wereld over partijen heen. De crux is dat je goed vaststelt wat je UoD is, en dat je zo ook kunt vaststellen wat in je informatievoorziening zit die deze UoD ondersteunt. En in feite kan je dat voor alle PIOFAH of COPAFEITH factoren zeggen, dus ook juridisch.
In de wereld waar jij over spreekt leert de architect feitelijk de opdrachtgever kennen op een zodanige manier dat hij/zij weet wat de opdrachtgever wil en dat kan vertalen naar de bouwers. Zeker kunnen architect en aannemer leveranciers zijn, alleen wel nogal verschillende leveranciers die hun rol moeten spelen. De architect als rechterhand van de opdrachtgever en de leverancier als contractpartner met de opdracht om iets te doen. Daarom kan Sogeti ook geen echte architect zijn als IT-leveranciers gekozen worden omdat zij Capgemini zijn. Nog sterker kan dat niet als Capgemini ook nog leverancier kan worden, want wat kunnen de andere leveranciers nog goed doen als de adviseur/architect uit hetzelfde huis komt als de aannemer/leverancier?
Dat een opdrachtgever laat aanhaakt is erg vervelend. Gaat dan een architect aan een opdrachtgever vertellen wat goed voor hen is? Lijkt me erg lastig. Zeker als het niet alleen om IT gaat, zoals je zegt. Of is de feitelijke opdrachtgever in het echt iemand anders, zoals een branchevereniging of een ministerie? Lastig.
Wat je zegt kan je vergelijken met standaardpakketten. Het punt is de vraag waar je de kennis vandaan haalt om echt een goed pakket IT samen te stellen waar men op zit te wachten. De praktijk leert dat IT structuur, functie, schoonheid en harmonie op heel andere manieren ziet en inricht dan dat opdrachtgevers dat doen. De vraag is dan letterlijk: wat is goed, en wat is slecht. In vaktermen spreken we dan gauw over blauwdenkers die moeite hebben met de andere kleuren omdat alleen structuur en functie zelden tot goed passende oplossingen leidt. Een mooi voorbeeld is Exact. Daar hebben ooit administrateurs voor hun collega’s bedacht wat goed voor hen was, en dat heeft ze en grote markt opgeleverd.
Anders gezegd, in lijn met je Engelse tekst: het feit dat een wereld zo slecht ondersteund wordt doet vermoeden dat alles beter is dan dat nu is. Alleen is dat goed genoeg. Is de half lege kop toch een half volle kop? De ervaring leert dat dit meestal niet het geval is, ongeacht hoeveel beter de wereld het al gaat doen.
Heb je nagedacht over waarom opdrachtgevers zo moeilijk te interesseren zijn? Ligt dat aan de slechte naam van IT-leveranciers? Of hebben deze opdrachtgevers andere oplossingen op het oog? Wordt hier, zoals zo vaak gebeurt, verkocht dat het allemaal goed voor deze bouwbedrijven is waar IT mee bezig is, terwijl ze zelf, terecht of onterecht, beter weten? Wensend denken?
Natuurlijk ben ik met je eens dat in projecten weinig verspild moet worden. Daarom zit ik ook zo met kennisontwikkeling, want die kennis is wel de onderbouwing van wat in een opgestart project moet gebeuren. Daarom zie ik business analyse, of hoe het allemaal genoemd mag worden, ook nog nauwelijks als eerste projectfase omdat die kennis er gewoon dient te zijn. En dus gebruikt kan worden door de leveranciers die zo’n project gaan doen. Maar goed weten en onderbouwen wat een leverancier moet gaan doen is echt de enige garantie om effectief en efficiënt projecten te doen, en veranderingen te realiseren. Outsourcing naar India laat dat schitterend zien. CMM 5 in India betekent dat je weet wat je krijgt als je iets in stopt. En wij, als we opdrachtgever zijn, weten niet goed genoeg wat we erin stoppen. Dus krijgen we er vaak garbage uit. Maar nog verder hiermee: stel dat we wel goed of zelfs precies weten wat we willen hebben, waarom zouden we dan (out)sourcen? Dan kan je die kennis immers ook in een software generator stoppen en dan krijg je je programma. Alleen is het ontwikkelen van echte software generatoren nu een jaar of 20 stilgelegd. Jammer, maar helaas: wij zijn die kennis haast helemaal kwijt. Maar, terugkomend op je laatste tekst: als je projecten goed kunt aansturen, dan zou je weinig moeten hoeven verspillen. Maar ik zie het TOGAF of DYA niet doen.