Managed hosting door True

De kijk van Van Eijk: Het K-woord

 

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).

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5133078). © Jaarbeurs IT Media.

7


Lees meer over


 

Reacties

Peter, leuke aanjager.
De genoemde producten zijn weliswaar complex, maar worden ontworpen, gemaakt en gedistribueerd in een "volwassen" industrie. Als er een industrie is die op al deze vlakken excelleert is het de procesindustrie en auto-industrie. Het onderscheidend vermogen in deze producten zit hem in de ontwerpfase. De bouwfase en basisonderdelen zijn zwaar gestandaardiseerd. Zo ook in de bouwwereld. Het feit dat een van de meest bekende methode om een proces te optimaliseren uit de auto industrie komt (Lean Six Sigma). In de bouw bestaat er een functie die calculator heet. Dat is iemand die op basis van een standaard bestek, tot op de cent nauwkeurig achter de komma kan uitrekenen hoeveel een bouwwerk kost. Niet dat er nooit iets fout gaat in die takken van sport, maar dat heeft niets met de basis werkwijze te maken. Daar komen dan weer menselijke eigenschappen aan de beurt (winstbejag, status etc..)

Concluderend: op dit moment van leven is de ICT industrie niet in staat om standaardisatie af te dwingen, omdat het commercieel speelveld te grillig is. Zowel in de auto-industrie als de procesindustrie is onder een heel eenvoudig economische redenen, standaardisatie afgedwongen: lagere prijzen. De partijen hadden geen keuze. Er moest goedkoper geproduceerd worden. Dat resulteerde in een sterk gespecialiseerde toeleveranciersmarkt en een referentie procesplaat hoe het product te maken.

Klanten moeten gewoon de prijs drukken. Er komt een moment dat de industrie wel moet gaan standaardiseren. Standaardisatie zal leiden tot specialisatie. Dan zullen we nog een hele kluif hebben aan een referentie proces in het vakgebied.

Zeer goed artikel.

Je geeft eigenlijk een beetje tweeledig beeld. IT enerzijds en processen anderzijds. En beiden dansen op één pijler en dat is heel eenvoudig 'Kennis'.

Ik propageer dat waar ik kan. Heb je ergens verstand van dan heb je waarde. Heb je ergens geen verstand van dan ben je een 'Liability'. In eerdere reflecties ben ik altijd helder geweest dat de grote natuurlijk wetten altijd stellen dat je ter zake kundig moet zijn, ongeacht het veld.

Overheid vs Bedrijfsleven
Ik ben het niet helemaal met je eens wat de succesratio is. +75% Bij overheden gaat het fout en +55% in het bedrijfsleven. Beiden kunnen dus nog flinke winst halen. De overheid kampt gewoon met teveel mensen op verkeerde plaatsen waardoor je teveel van de vier Falende pijlers pijnlijk clustert.

Impotentie, Incompetentie, Commercie en Politiek

IT als materie, als vehikel, als carrier is namelijk zeer allergisch voor hier genoemde, en klaarblijkelijk wil men daar maar niet aan. Eigen disciplinaire visie of rechtpraten wat krom is blijft een hele aparte tak van sport.

Proces gerichte inrichting
Je noemde enkele takken van sport die zeer goed begrijpen hoe men IT voor hen kan laten werken en dat gaat feitelijk maar op één gelijkluidende manier. Door die lineair en opvolgend op te zetten en in te richten. Ik zal daar in een later blog nog wel eens op terug komen. Hoe strakker en meer lineair men dit doet, des te hoger succesratio. Vergeet u alstublieft even scrum, dum en bunte illustrierte even.

Certificering
Ik ben daar wel een voorstander van maar....
Je kunt van de luchtvaart nog erg veel leren. Dat betekend overigens voor bedrijfsleven en overheid gelijk. Want wat doet de luchtvaart nu anders dan het bedrijfsleven? Die is eenvoudig. Bij elke controle slag is men verplicht een hele keten te controleren. Eenvoudig voorbeeld. Lekke band? Dan word dat wiel niet alleen verwisseld en uitgelijnd. Met kijkt naar het hele hydraulische systeem, men controleert alle aspecten en onderdelen van de remmen, de as word opnieuw doorgelicht en.... MEN DOCUMENTEERD! (HORROR!!)

Ik weet het. Maar de luchtvaartindustrie heeft een bijna 100% dichte track procedure die vrijwel sluitend is.

Wanneer je iemand certificeert omdat die in een bepaalde IT discipline uit blinkt, dan vergeet je misschien wel twee hele cruciale punten.

1. Kent de betreffende specialist dan ook de basis E2E keten en zijn discipline in het geheel?

2. Word deze specialist ook geleerd dat gat of grijze gebied te allen tijde te sluiten middels een E2E procedure?

Als je alleen al zaak zou maken in de opleidingen van deze twee voorgaanden, dan heb ik er wel geloof in. Maar blijft iemand alleen maar 'hangen' als expert van en in een bepaald vakgebied, is dan geneigd alleen maar te kijken en te denken vanuit die expertise.
Laat dit nu volgens mij nou net niet de bedoeling zijn.

Maak IT nu maar eens meer standaard en overzichtelijk als beginsel voor iedereen die in en met IT werkt. Dan krijgen we eindelijk eens een echt uniform.

Vaak begint het al bij de beschrijving van de opdracht tot het helemaal uitwerken van de opdracht. Dat kun je al helemaal in detail uit (laten) werken en tot op de cent nauwkeurig laten berekenen.
Als dat al niet niet kan dan begin je eigenlijk al met een valse start.

Het leuke, maar ook het veraderlijke, van de ICT sector is dat titels onbeschermd zijn. Daar waar in de bouwsector de term "architect" beschermd is, mag iedere IT-er zch architect noemen. Dit is derhalve dan ook geen enkele garantie voor kwaliteit en kundigheid.

Ik heb hier ooit eens wat woorden aan gespendeerd, met een leuke discussie tot gevolg:
http://www.computable.nl/artikel/opinie/development/4877998/1277180/wil-de-echte-expert-opstaan.html

@NumoQuest, helemaal mee eens, standaardisatie is dus het ei.

@Johan, vraag 10 verschillende ervaren ICT-ers maar eens een zogenaamd gedetailleerd tot op de cent nauwkeurig plant te schrijven. Mijn stelling: je krijgt op een glijdende schaal 10 verschillende plannen die dermate uiteenlopen qua budget, tijd en risico. Het zou een zegen zijn als dat mogelijk zou zijn.

@Pa Va Ke, deels eens met je. Ik heb mensen meegemaakt in ICT (maar ook in andere vakgebieden) die ik weet niet hoeveel (beschermde, door de overheid en het veld zwaar gewaardeerde) titels hadden, maar er in de praktijk geen sikkepit van terecht brengen. Natuurlijk moet je door middel van een opleiding kunnen aantonen dat je een vak beheerst. Maar we moeten uitkijken voor papiertjesfetisjisme. Pak maar eens een beroepen waarbij je wettelijk verplicht academisch geschoold te zijn: de advocatuur/het notariaat en de medische wereld (artsen). Ook in deze takken van sport zitten echt voldoende rotte appels. Natuurlijke zal het gemiddelde niveau van de gehele beroepsgroep wat stijgen, maar het zal in mijn optiek niet bijdragen aan de echt grote stappen, waar we op zitten te wachten. Ethiek, fingerspitzengefühl, aanleg, straatwijsheid kun je niet leren.

Misschien leuk om het WK in Brazilie als metafoor te gebruiken. Niet alleen de spelers in zwaarste competities winnen. Ook geloof, tactiek, inzicht, en de wil om te winnen zijn hele belangrijke aspecten. Overigens komt daar voetbal nog iets als geluk bij.

@atillav ... veel goede individuen maken nog geen team inderdaad, net zoals een papiertje ervoor zorgt dat je kwaliteit levert. Wat dat betreft helemaal met je eens.

Kwaliteit is lastig te meten, kosten des te beter. Veel bedrijven / managers sturen dan ook liever op kosten, wat vervolgens ten koste gaat van de kwaliteit...

Boeiende discussie. Met een achtergrond in de werktuigbouw herken ik de meeste genoemde onvolwassenheden in de ICT direct.

Eerste opmerking: de ICT-branche heeft sterk de neiging tot 'goed nieuws rapportages', wat neerkomt op maandelijks herhalen van tabelletjes met percentages uptimes. Na de derde keer kijk je daar niet eens meer naar. Wat de maak-industrie interesseert is juist wat er fout is gegaan: uitval-percentages. Neem het volgende voorbeeld: uptime van 98% naar 99%. Verschil 1%, verbetering schijnbaar ook ongeveeer 1%. Zelfde infra, andere aanpak: downtime van 2% naar 1%. Verschil 1%, maar de delta is 50%. Ik druk kwaliteit daarom al een tijdje niet meer uit in hoe goed iets was, maar in aantallen en percentages geconstateerde defecten. Dat is ook prima te meten, terwijl niemand een sluitende definitie kan geven voor kwaliteit als 'mate van hoe goed het is'.

Tweede issue is de beperking tot het eigen onderdeeltje van de totale dienst, die direct voortkomt uit de focus op wat er goed ging. De server was up zeggen de systeembeheerders. De database deed het zeggen de DBA's. Ons LAN was ok zegt de netwerkbeheerder. Ja dat de hele locatie niet kon werken lag aan de externe leverancier van de WAN-verbindingen en die zullen we eens ernstig toespreken bij de volgende SLR.
Uiteindelijk maakt dat allemaal geen fluit uit voor de gebruikers, die zaten mooi zonder. Stel je dat eens voor bij een auto: je bent gestrand ergens langs de weg maar de garage meldt je vrolijk dat de motor, de airco en de radio het toch maar mooi goed hebben gedaan. En dat van die versnellingsbak, dat zullen we eens met de leverancier bespreken. Maar de rest was allemaal pico bello....

En zo komen we bij het punt waar de kwaliteit werkelijk is te meten: de eindgebruikers. Want als er ergens in de keten dingen mis gaan dat is er altijd wel een groep gebruikers die daar meer of minder last van heeft. Dat is een hele goede maatstaf voor kwaliteit, en hij is zeer goed te meten: kijk naar de call logs van de helpdesk. Dat zijn er natuurlijk vele duizenden, maar daar hebben we oplossingen voor. Big Data is een buzz word toch?

Als kosten worden uitgedrukt in Euro's dan is het logisch kwaliteit uit te drukken in defecten. Het ideale product dan 'kost' 0 euro en vertoon t0 defecten. Perfectie. Hiermee zijn kosten en kwaliteit eindelijk goed op elkaar af te beelden zonder de verwarrende 'lage kosten - hoge kwaliteit' relaties.
Dit is de grondslag voor de methode SMART Quality: de kassa van kwaliteit staat op de helpdesk.
Koning, keizer, admiraal: bellen doen ze allemaal.

Over standaards en certificatie: er was een tijd, niet heel lang geleden, dat bijna elke fiets- en autofabriek zijn eigen schroefdraad bedacht en zijn eigen toleranties hanteerde. De massa-industrie is pas echt van de grond gekomen toen dat werd gestandaardiseerd: DIN, NEN of ISO-normen voor schroefdraad (de Fransen zijn nog een tijdje M7 blijven gebruiken...), voor maattoleranties (H7/g6 voor een glijdende passing, zoek maar op) en normdelen zoals lagers, bouten, oliekeerringen en ga zo maar verder. Uitwisselbaar ongeacht de fabrikant. Het equivalent daarvan in ICT: Open Standaards. Of je leverancier open software maakt is een tweede, zolang hij maar zorgt dat het product volledig voldoet aan de RFC. En dan geen ongedocumenteerde 'verbeteringen' of 'uitbreidingen' aanbrengen he?

Tot slot: ik moet altijd grinniken als er weer een ICT-club aankondigt helemaal 6Sigma te gaan. Dan vraag ik wel eens of iemand in het gezelschap zich realiseert waar dat voor staat. Nou ja iets van een methodiek toch? Net als ITIL of Prince? Nee, 6Sigma staat voor een productielijn die gegarandeerd niet meer dan 13 defecten op 1.000.000 producten geeft. Vertaald naar een ICT-dienst is dat een uitval van 0,000013, of in de klassieke termen een uptime van 99,999987. Heeft iemand dat ooit gecontracteerd of geleverd?
Andersom: een uptime van de magische 5x9; 99,999% dus, zou voor Samsung of VW betekenen dat 1 op de 100.000 van hun producten uitval is. Dat hou je niet lang vol als commerciële onderneming.

In kwaliteit is voor de ICT nog een wereld te veroveren. Het goede nieuws is dat anderen ons zijn voorgegaan en dat we al die wielen dus niet nog een keer hoeven uit te vinden. Kijk maar eens buiten de grenzen van je eigen vakgebied. Het doet echt geen pijn.


groet
Tom Louwrier (Ratio)

A.U.B niet weer certificeren. Voordat instituten dat betrouwbaar van de grond krijgen hebben we een berg scherven van kapotte projekten.

Wat is er mis met referenties? Wie het goed doet, krijgt tevreden klanten en dus goede referenties.

Of willen we internet sites waar ICT bedrijven aan de pranger gesteld worden die alles verprutsen? Dat is een tendens die overal te zien valt.

Dat andere bedrijfstakken wel hogere standaards halen heeft ook te maken met de gevolgen van prutsen, bij farmacie kunnen er dan doden vallen. De doorsnee ICT-projekten die verpruts worden kosten "alleen" en berg geld.
Dat schijnt nog steeds niet erg veel mensen te interesseren.

Onze bedrijfstak is nog steeds tamelijk jong, dat zie je aan dit artikel. Over 100 jaar is alles beter . . .

Ik heb de indruk dat veel mislukkingen te wijten zijn aan het in één keer een gigantisch groot systeem neer te willen zetten. Mijn insteek zou meer zijn: begin met een klein onderdeel, hou rekening met uitbreidbaarheid en zorg ervoor dat dat goed gaat werken. En breid dan de functionaliteit uit.

IT is een kapstok begrip. Ieder bedrijf gebruikt heel veel IT op alle plekken en elke gebruiker is bijna IT-er geworden.

Daarnaast is je IT iets wat veel te veel en te snel wijzigt. Niet alleen de versies van allerlei software en besturingssystemen, maar ook de bedrijfsprocessen er omheen.

Op het moment dat je een statische omgeving hanteert zonder toegang tot internet (incl. virusscanners) kun je best robuuste dingen opzetten... maar daar hebben we vervolgens niets aan.

Een silver-bullet kun je dus wel vergeten.

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 :
http://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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×