IT is belangrijk en complex, maar de professionaliteit is vaak behoorlijk matig. Kijk maar naar de grote mislukkingen op overheids-it-gebied waar momenteel onderzoek naar wordt gedaan. Het is overigens te simpel om dit alleen aan de overheid toe te schrijven, het lijkt mij dat de mislukkingen bij de overheid vooral zichtbaarder zijn, niet frequenter of groter dan elders.
Dat gepruts kost klauwen met geld, en levert eindeloze frustraties op. Kan dat niet beter?
De luchtvaart, procesindustrie en de farmacie zijn andere industrieën met een hoge complexiteit. Hoe zorgen die voor kwaliteit? En kunnen we daarvan wat leren voor it?
Ik zie een paar manieren. Je kunt naar het product kijken, naar het proces én naar de mensen die in dat proces werken. Bij oplevering van een huis bijvoorbeeld kijk je naar het product, elk huis wordt apart geïnspecteerd. Maar auto’s worden meestal niet individueel getest. Die krijgen een typegoedkeuring op basis van enkele voorbeelden en (vermoedelijk) een beschrijving van het productieproces. Ik weet dat onderhoud van zweefvliegtuigen alleen mag gebeuren in goedgekeurde werkplaatsen door gecertificeerd personeel. En artsen, apothekers, accountants en auditors mogen alleen werken op basis van individuele registraties die gebaseerd zijn op uitgebreide toetsen van kennis en vaardigheden.
Kunnen we dat soort methoden wat meer gebruiken in de it? Hoe zou dat er uit zien?
Moeten we het product of de dienst goedkeuren? Dit zouden we met internet-diensten en hosting kunnen doen. Moeten we het bedrijf goedkeuren? Dat klinkt als een ISO-achtige certificering. Of moeten we personeel goedkeuren? Dat klinkt als individuele certificering.
Maar dan komen we de hobbels tegen. De industrie kan het maar nauwelijks eens worden over de manier waarop we de kwaliteit van internet diensten en hosting kunnen meten, laat staan goedkeuren. ISO-certificeringen zijn hooguit een momentopname, en individuele certificeringen zijn veelal leverancierspecifiek.
Hoe moet het dan wel? Ik ben benieuwd naar de reacties.
Peter van Eijk is onafhankelijk adviseur op het gebied van digitale infrastructuren (www.peterhjvaneijk.nl).
Henri, denk dat op het vlak van de bedrijfsprocessen en de organisaties er te veel en snelle veranderingen zijn. Niet voor niets heeft de continu verander coach een dagtaak. Voor de ondersteunende ICT bijna niet bij te benen maar wel verwacht.
IT is erg breed. Mijn reactie beperkt zich tot het realiseren van maatwerk software.
De opdrachtgever verwacht van de opdrachtnemer dat hij een bruikbaar resultaat oplevert.
Dat betekent dat de opdracht zich feitelijk uit moet strekken tot buiten de grenzen van enkel het realiseren van maatwerk software.
Maatwerk software is een onderdeel van een groter systeem in een organisatie waarvan ook mensen, de doelen, hun processen, besturing en verantwoording deel van uit maken. Samen bepalend zijn voor de ervaren kwaliteit.
Meer aspecten dan enkel het realiseren van de software zijn van belang:
– het doel dat door inzet van o.a. de maatwerksoftware bereikt moet worden;
– de borging van het managen van het systeem (waarvan software een onderdeel is) door mensen in de organisatie van de opdrachtgever. Zij zullen verantwoordelijk zijn voor het systeem en moeten er grip op hebben en verantwoording af kunnen leggen;
– de taken, verantwoordelijkheden en bevoegdheden van de gebruikers van het systeem;
– de cultuur binnen de organisatie, de wil en motivatie om te veranderen en verbeteren;
– de bedrijfsprocessen. Worden businesswensen helder vetaald naar de nodige veranderingen.
IT moet dus meerdere aspecten van een organisatie raken.
Wanneer de balans daarin of de samenhang daartussen niet goed ligt schiet de kwaliteit te kort.
Moet nu het eindproduct (de dienst) of het proces of de uitvoerende individuen op een hoger plan gebracht worden?
Kwaliteit moet afgemeten worden naar de mate waarin het gerealiseerde er voor zorgt dat het beoogde doel bereikt wordt.
De uitvoerenden die veranderingen teweeg brengen op de gebieden van doelen stellen, besturing, bedrijfsprocessen, organisatie-inrichting moeten het doel goed kennen en er samen aan werken.
Sleutel voor een kwalitatief goed eindproduct ligt in eerste instantie bij de ingezette individuen in het veranderproces; dan bij de inhoud van het veranderproces zelf.
Zijn de uitvoerenden van goede kwaliteit dan kan toch iets van kwaliteit bereikt worden ondanks een slecht veranderingstraject.
Is het veranderingstraject ook inzichtelijk voor alle deelnemers dan kan de kwaliteit hoger worden.
Meten aan het eind van het veranderingsproces is zinvol om bijvoorbeeld toekomstige veranderingen bij te kunnen sturen.
De silver bullet is er niet.
Een goede bronzen is volgens mij:
Zet mensen van kwaliteit en ervaring in, zorg voor een helder veranderingsproces, kijk breder dan alleen het IT-vakgebied.
Heren, de meesten hier (en in de rest van de branche) denken bij kwaliteit eigenlijk alleen aan projecten en ontwikkeling. Dat is net zoiets als bij de kwaliteit van een auto alleen kijken naar het ontwerp- en productieproces.
Voor wat het gebruik betreft begint het feest pas daarna: je stapt in, rijdt weg en verwacht dat je dat nog een goed aantal jaren in alle tevredenheid kunt blijven doen. Of het een erg comfortabele rit wordt is een tweede, dat lag al vast in de specs. Maar dat hij blijft functioneren zoals afgeleverd, dat lijkt me niet meer dan normaal.
TC Louwrier, NumoQuest zal het beamen: Maar als software het doet en je verandert niets, zal het ook jarenlang blijven functioneren….
Zijn er functionele nieuwe wensen (changes), dan heb je nog steeds kwaliteiten nodig die je ook tijdens ontwikkeling nodig hebt, alleen vaak zie je dat het projectteam dan niet meer bestaat…
Henri, dat klopt natuurlijk. Daarom maken wij ook onderscheid tussen verschillende soorten defecten:
– technische defecten (de gewone incidenten door falen van de techniek; “hij doet het niet”)
– functionele defecten (de gebruiker wil iets maar dat is (nog) niet mogelijk. Kan een rfc worden of een simpele toekenning van rechten; “hij kan het niet”)
– ergonomische defecten (de gewenste functionaliteit is beschikbaar en ‘up’, maar de gebruiker krijgt het niet voor elkaar. Kan leiden tot een rfc voor aanpassing van de UI of een opleiding voor de gebruiker; “hij weet het niet”).
Deze verdeling sluit keurig aan op diverse test-methodieken en acceptatie-criteria.
In de praktijk vormen technische defecten het overgrote deel van de dagelijkse besognes, daarna kleine functionele -met name autorisaties op software en bestanden- en tot slot de ergonomische. De rfc’s die er verder nog uit komen zijn bijna verwaarloosbaar in aantal (wat niet hetzelfde is als impact!). Toch is dat juist waar het gros van de aandacht wel steeds weer naar uitgaat. Dus als je veel plezier van je investering wilt hebben zou ik aan de hand van dit soort getallen mijn prioriteiten stellen.
gr
Tom Louwrier
Ik moet even grinniken, als software niet veranderd….
Maar wacht eens, had ik hier al niet eens wat over geschreven in ‘De Cloud beheersbaar maar niet beheerbaar’ bijna 2 jaar geleden?
Opmerkelijke column van Peter en ik zou haast gaan denken dat hij een harde landing heeft gemaakt, idee van cloud computing was toch een landingsplatform voor de softwareproducten uit het nieuwe geloof van agile.
Misschien gemist maar als over de kwaliteit niet meer geklaagd wordt dan is het de prijs wel waarover gezeurd wordt. Certificeer eerst de gebruikers maar want dat het allemaal gebuikersvriendelijker is geworden maakt van Tnn Elias nog een IT-er.
Geen nood.
Gewoon 4 dagen bijscholing :
https://www.computable.nl/artikel/producten/datamanagement/5135041/4445906/informatiemanagement-in-de-publieke-sector.html
want
“Na de opleiding weten de cursisten wat er speelt binnen de samenhang it, besturing, informatievoorziening en organisatie en zullen ze als informatiemanager een volwaardig adviseur en sparring partner in de organisatie zijn.”
@Felix: Is wel een leuke grap, maar ik denk dat dit stiekum ook een groot probleem is. Binnen de ICT heb je gewoon de meest eigenaardige om- en bijschooltrajecten.
Je stapt niet in het vliegtuig waar een botanicus achter de stuurknuppel zit, die in 4 dagen zijn brevet gehaald heeft bij een vaag cursusinstituut.
Het verschil tussen de autoindustrie en de ICT is dat de ICT meestal maatwerk moet leveren en de autoindustrie meestal duizenden keer precies hetzelfde product moet maken. En dan is het gemakkelijker om te werken aan standaardisatie en efficientie. Een ICTer moet constant improviseren, zeker in een bedrijfsomgeving waar verschillende systemen met elkaar interactie hebben.
Een groot ICT bedrijf waar ik ooit voor gewerkt heb, had zijn IQ eisen aan sollicanten flink opgeschroeft nadat uit intern onderzoek was gebleken dat bij elke 10 punten hoger IQ van de medewerkers het aantal technische problemen halveerde.
Johan,
Ook jij verwart het productieproces van auto’s met de ontwerp/bouw fase van software. Dat de software-industrie bijna elk product op maat maakt of naar wens configureert heet in de maak-industrie ‘designed to order’ en ‘engineered to order’. Beide varianten vallen onder ‘built to order’.
Auto’s zijn, afhankelijk van het merk en de geografische markt, vrijwel allemaal ‘engineered to order’, wat een sterk modulair concept impliceert.