Viergever heeft gelijk, dat een project en ook/juist een ICT project, waarbij meestal de nodige organisatieveranderingen mee gemoeid zijn, geleid moet worden vanuit de business en niet vanuit ICT.

Maar veel van de verdere analyse is volstrekt fout. Bedrijven moeten juist wel standaard SW aanschaffen, als ze geen bijzondere processen hebben die een concurrentie voordeel hebben. Alleen als een bedrijf iets bijzonders heeft in zijn processen dat een wezenlijk concurrentie voordeel oplevert is maatwerk SW te justificeren als een dergelijk proces nog niet ondersteund wordt door SW die op de markt is.

Lees het, overigens vaak verkeerd begrepen, artikel van Carr uit 2003 nog eens heel grondig en laat de verregaande consequenties daarvan nog eens goed tot u doordringen.
https://hbr.org/2003/05/it-doesnt-matter

Er staat helemaal niet dat je bij oude technologie moet blijven of alleen standaard SW mag gebruiken. Maar er staat dat je heel kritisch moet zijn wanneer je maatwerk SW inzet. Voor de overgrote meerderheid van organisaties volstaat “HEMA-software”, oftewel gewoon standaard SW, waarbij de organisatie zich aanpast aan de best practices die in die SW zitten. Wie denkt dat hij een financiële administratie beter op een andere manier kan runnen dan in de SW van Exact is geprogrammeerd, en dus dure aanpassingen doet aan Exact, is in 99,9% van de gevallen niet goed wijs!

De gedachte dat eigen processen heel slim zijn, en dat er daarom geen SW is die dat op precies die manier ondersteunt, is de hoofdoorzaak van de vele mislukkingen bij informatieprojecten in de overheid en bij bedrijven. Omdat er dan maatwerk SW gemaakt wordt, of standaard SW van bijvoorbeeld SAP megalomaan aangepast wordt, om de eigen dommigheden van processen te kunnen implementeren; of, erger nog, de misfit van het gekozen pakket weg te poetsen.

Dat stelde Carr al in 2003 heel scherp aan de kaak; maar de consequenties daarvan zijn nog slecht in de IT-sector doorgedrongen. En de business verantwoordelijken weten logischerwijze niet beter en worden misleid door mooie verkoopverhalen van bijvoorbeeld SAP.

Ik heb geen oordeel over wat bij Speer (Defensie) aan de hand was. Uiteraard zat daar ook de lijnorganisatie te weinig aan de knoppen. Daarnaast zijn er, volgens de filosofie van Carr, 3 mogelijkheden van fundamentele gemaakte fouten:

1. De processen waren onverstandig en ze moesten toch zo nodig precies zo in de aangepaste SAP SW komen. Remedie: de processen hadden eerst opnieuw ontworpen moeten worden en vervolgens had standaard SW prima kunnen passen.
2. De processen waren prima, maar:
a. met SAP is de verkeerde keuze gemaakt, er waren andere pakketten die beter zouden aansluiten bij de bijzonderheden. Remedie: kies een ander pakket dat veel beter aansluit, en waarbij geen of nauwelijks aanpassingen nodig zijn.
b. de bijzonderheden van die processen zijn onvoldoende geïsoleerd, waardoor onnodig grote ingrepen in standaard SAP SW is gedaan. Remedie: isoleer de bijzonderheden en kies daarbij het beste pakket en pas dat zo nodig een beetje aan of maak nieuwe maatwerk SW voor dat onderdeel. Voor de overige procesonderdelen gebruik je standaard SW!

Hieruit blijkt dat er wel degelijk een zeer belangrijke sturende rol van een deskundige CIO/IT-er of architect nodig is in IT-projecten om dergelijke keuzes verantwoord te maken; gebruikers en lijnmanagement kunnen dat i.h.a. echt niet. Maar uiteraard wel in zeer nauwe samenwerking met “de business”, zodat de business doelen voorop blijven staan.

Beste Jan,

"veel van de verdere analyse is volstrekt fout"? Grote woorden. Is dit persoonlijk?

Ik zie bij de rest van jouw reactie geen (directe) relatie met mijn verhaal.