De automatiseringssector moet nog volwassen worden, vindt directeur Jeroen Versteeg van dienstverlener Sogeti. 'Het werk in deze bedrijfstak gebeurt grotendeels nog ambachtelijk en niet geïndustrialiseerd. De toekomst ligt in herhaalbare, gestandaardiseerde ict-oplossingen.' Volgens de topman mislukken veel ict-projecten doordat ze te groot zijn en te veel interactieve punten hebben.
Te complexe projectvereisten zorgen geregeld voor problemen in de branche. 'Het is vaak te moeilijk om al die functionele requirements te vertalen in technologische oplossingen. Dat geldt zeker als bovendien sprake is van legacy', aldus Versteeg. Dienstverleners moeten hun klanten volgens hem geen gouden bergen beloven, als ze die niet kunnen waarmaken. 'Weet goed wat jezelf wel en wat je niet kunt.'
Gestandaardiseerd
Een gestandaardiseerd aanbod kan daarbij volgens Versteeg helpen. 'Bied standaardcomponenten die je vervolgens uitbouwt om te passen in de organisatie van de klant.' De topman vermoedt dat de mate van standaardisatie die mogelijk is op ict-beheer meer dan 90 procent bedraagt.
Sogeti Nederland heeft standaardisatie begin 2010 nadrukkelijk in zijn strategie opgenomen, met als voornaamste doel om de interne productiviteit te verhogen. 'We nemen het gehele voortbrengingsproces van ict-oplossingen onder de loep en brengen een vergaande industrialisatie op gang', aldus het jaarverslag dat in juni werd gepresenteerd.
Wat Jeroen Versteeg zich onvoldoende realiseert is dat juist uit het ambachtelijke werk, kwaliteit voortkomt. Het is een wijdverbreide misvatting dat je door standaarden en procedures tot kwaliteit kunt komen. Helaas heeft deze misvatting inmiddels geleid tot onverkwikkelijkheden als ‘kwaliteitsfunctionaris’ en ‘kwaliteitmanagementsysteem’
Barts reactie lijkt me te zwart/wit.
Een gestructureerde manier van werken met vastgelegde reviewprocedures en iemand (een kwaliteitsfunctionaris b.v.) die ervoor zorgt dat die reviews ook echt en gedegen gedaan worden, kunnen zeker klwaiteitsverhogend werken. Denk aan (om in ambachtelijke termen te blijven) de controle die door gildebroeders werd gedaan.
Mijn angst geldt veeleer de gestandaardiseerde oplossingen. Ik zou het droevig vinden als maatwerkoplossingen verdwijnen en iedere softwareleverancier een pakkettenboer wordt. Alleen nog maar confectie uit aziatische sweatshops. Wellicht de onvermijdelijke toekomst, net als bij zoveel producten, maar niet iets om blij van te worden.
Ik denk dat de detacheringsbedrijven eerst de hand diep in eigen boezem moeten steken voor ze een tirade afsteken oer volwassenheid. Alle “volwassenheid” (betrouwbaarheid en stabiliteit) onder je medewerkers en dus in het bedrijf komt voort uit op een fatsoenlijke, respectvolle manier met elkaar omgaan. Niet uit uurtje-factuurtje, alle bankzitters op straat zetten als het even weer wat minder gaat en achter elke nieuwe hype aanrennen. Dat creëert alleen maar onrust.
Wat een onzin om het mislukken van (grote complexe)projecten te wijten aan onvolwassenheid van de branche en in standaardisatie de oplossing te zoeken.
Ja, standaardisatie leidt tot complexiteitsreductie, maar ook tot meer van hetzelfde. De net niet fit op de bedrijfsprocessen.
Standaardisatie van interfaces, daar moeten we naartoe.
Als je kijkt hoeveel technologie er in de branche omgaat. Hoeveel innovaties organisaties te verduren krijgen. Het knelpunt zit eerder bij het management. Te veel te snel. Bedenk eens hoeveel van de geleverde functionaliteit uiteindelijk gebruikt wordt.
Nee, de branche is volwassen genoeg. U vraagt, wij draaien. Maar vraag eens eenvoud. Less is more, zeker in tijden van recessie. Krijg je rust in de tent. Houd je meer resources over om in kwaliteit van de organisatie te steken. Kan er mogelijk zelfs gesneden worden in het management en de staforganisatie.
De juiste dingen doen en deze goed doen.
Jeroen Versteeg constateert nog veel ambachtelijk werk. De oorzaak van het falen van veel projecten ziet hij in een te grote complexiteit van deze maatwerk software. De oplossing moet komen van ‘standaard’ pakketten die tot maximaal 75% van de softwarebehoefte van een bedrijf dekt.
Dit rijmt niet met het grote aantal ‘standaard’ pakketten dat de markt al 20 jaar tracht te beheersen. Noch het maatwerk noch de standaard pakketten zijn echter de werkelijke oorzaak van het probleem.
Willen we echt volwassen worden dan moet het roer om. Zie http://www.computable.nl/artikel/ict_topics/overheid/2998823/1277202/architecten-terug-naar-de-blokkendoos.html
Vreemd eigenlijk dat er zo’n sterke scheiding is tussen standaard werk en maatwerk. En hoezo is maatwerk / ambachtelijk werk slechter dan standaard? (of andersom). Is het een echt beter dan het ander? Handgemaakte maatpakken bijvoorbeeld, worden immers als beter (en duurder) gezien dan confectie.
En dan al die technologische vernieuwingen. Voor wie zijn die handig? Voor de klant of de IT leverancier? Ik tik nog steeds hetzelfde briefje op mijn huidige tekstverwerker als die van 10 jaar geleden. Alleen intussen wel tig technologisch verbeterde versies verder. Inderdaad met hier en daar meer functionaliteit en makkelijker in het gebruik, maar het meeste gebruik ik niet of heb ik niks aan.
De oplossing ligt volgens mij in het combineren van standaard en maatwerk. En daarbij de technologie loskoppelen van de functionaliteit. Zoals we de presentatie ook al losgekoppeld hebben van de functionaliteit.
Vergelijk het met de boekenkast gevuld met boeken. Ik vermoed dat er geen twee gelijk zijn op deze wereld. Ze zijn allemaal persoonlijk (lees: maatwerk). Echter bestaan ze voor een groot deel uit standaard componenten. Er zullen weinig mensen zijn met handgemaakte boekenkasten of met boeken met een oplage van een exemplaar. De meeste boekenkasten zijn massaproducten en de meeste boeken ook. Toch is het geheel maatwerk. Daarbij is de techniek (boekenkast) gescheiden van de functionaliteit (boeken).
En als de drukker een nieuw drukprocedé heeft, hoef jij niet hetzelfde boek gemaakt met het nieuwe procedé aan te schaffen (vergelijk herbouwen van dezelfde functionaliteit in een nieuwe technologie). Je kunt relatief eenvoudig een andere boekenkast aanschaffen als de oude “technologisch niet meer voldoet” (nieuwe architectuur of framework). En daar dezelfde boeken weer in stoppen. Ook kun je de boekenkast makkelijk uitbreiden om meer boeken te herbergen. Je kunt makkelijk nieuwe boeken kopen en toevoegen of de volgorde in de boekenkast wijzigen, als de indeling je niet bevalt. En als je er een boek (component) uithaalt is niet meteen de hele boekenkast onbruikbaar (lees: down).
Onderhoud aan de boeken gebeurt door de verschillende schrijvers en/of uitgevers. Een nieuwe druk (versie) kun je al dan niet aanschaffen. Beïnvloed de functionaliteit van de andere boeken niet. Je kunt de oude weggooien of de nieuwe er naast zetten. Je komt hooguit wat te kort, bijvoorbeeld als er een nieuw woord in een net aangeschaft boek staat, wat nog niet in jou woordenboek staat. Je kunt gemakkelijk shoppen voor nieuwe boeken en zit niet aan dezelfde uitgever vast (dat zou al te belachelijk zijn of niet?). En je kunt boeken in allerlei talen door elkaar in de boekenkast zetten. Zo’n boekenkast kan al met al aardig complex worden. Maar ik heb nog nooit iemand horen klagen over de complexiteit van zijn/haar boekenkast. En ook in een bibliotheek, eigenlijk de complexheid ten top, blijven zaken en processen relatief overzichtelijk en simpel.
Trouwens ooit een boekenkast aangeschaft waarbij je meteen een zwik boeken (van dezelfde uitgever) moest kopen? Of een boek gekocht waarbij je meteen een boekenkast (“verplicht”) meegeleverd kreeg?
Wanneer houden we in de IT eens op met die hocus pocus dat IT complex is (zou moeten zijn) en maken we het eens simpel? En stellen daarbij de “maatwerk” wensen van de klant centraal?
Misschien bedoelt hij -en daar is voor te pleiten- dat de ICT als gehele bedrijfstak nog laag scoort op een soort ‘bedrijfstak CMM’ schaal. Gelet op de bewering van ‘ambachtelijk maatwerk’ doelt hij op een schaal 1 (initial) en wenst hij dat ‘we’ naar schaal 2 (repeatable) of 3 (standardized) gaan? Komt 4 (managed) en 5 (optimized) ooit nog binnen bereik?
De vraag die dat bij mij oproept, is hoe het dan met de innovatie moet. Is die te herhalen en te standaardiseren? Of zou dat als “R&D” buiten het CMM model vallen?
Jeroen Versteeg vindt C. van Oranje tegenover zich die juist pleitte voor meer “trial and error” in de ICT (https://www.computable.nl/artikel/ict_topics/overheid/3365259/1277202/eoverheid-mist-leiders.html).
Dit is helaas een opinie-artikel en geen expertartikel. De materie is ook te complex voor zo’n kort artikel zonder verwijzingen. Er wordt geen door feiten gefundeerd onderzoek aangehaald om de beweringen te ondersteunen. Voor een bedrijfskundige is dit een nogal pover artikel.
Kijk je naar andere bedrijfstakken, dan zie je dat ook daar bij snelle ontwikkelingen veel fouten worden gemaakt. Dat was recentelijk nog te zien in de financiële dienstverlening en die kan je beslist niet onvolwassen noemen.
De ICT ontwikkelt zich redelijk snel rond de hypes en juist daar gaat ook vaak mis, of het nu om een concept, methode of een product gaat. Vaak duurt het meer dan vijf jaar voordat het goed loopt en dan heb je de volgende hype. Denk aan SOA, SaaS, Web 2.0 en Cloud.
Standaardisatie is heel vaak handig of vrijwel onmisbaar gebleken. Ik kijk altijd of ze gebruikt kunnen worden. Helaas is het is voor betrokkenen niet altijd (bijtijds) duidelijk wanneer standaardisatie onwenselijk of zelfs onmogelijk is. Standaards worden vaak ook verkeerd gekozen of niet goed opgevolgd.
Simpelweg standaardisatie aanprijzen helpt dan niet. Geef liever handvaten aan beslissers en medewerkers hoe het combineren van standaard en maatwerk beter kan en de juiste standaards gekozen worden.
Aangeven dat meer met standaardpakketten moet worden gewerkt is net zo weinig zinvol. Ze worden meestal niet als handige buidingblocks aangeboden. Dat is één van de redenen waarom BI-, ERP-, CRM-projecten meestal grotendeels tot geheel mislukken. Het komt vaak voor dat standaard BI-, ERP-, CRM pakketten uiteindelijk zo ver aangepast moeten worden dat 80 % van de functionaliteit voor bijna 100 procent van de inspanning moet worden gebouwd.
Een slechte communicatie is daarbij heel vaak de grootste oorzaak en dat komt vaak weer door verborgen agenda’s van zowel opdrachtgever als opdrachtnemer en onderaannemers. Ben benieuwd wat FAILfaire aan nieuwe inzichten gaat opleveren.
Jacco en John.. jullie reactie is langer dan het artikel. Ik kon de reden niet vinden om op dit artikel serieus te reageren 🙂
Dit verhaal horen we al twintig jaar of zo. En verder horen we net te vaak van managers dat technisch werk allemaal maar standaard en simpel is. Dat zegt meer over die managers dan over het werk, wat vaak gewoon ambachtelijk is, omdat software schrijven niet hetzelfde is als stenen leggen. Maar ja, Sogeti is weer in beeld geweest.