Overslaan en naar de inhoud gaan

Audits slachtoffer van misverstanden

In zijn artikel ‘Audits zijn bron van misverstanden’ (Automatisering Gids 11 april 2003) geeft Roeland Stouthart een visie op het optreden van auditors in ‘projectreviews’ en signaleert wat een projectmanager zou moeten doen om de conclusies in zijn voordeel te draaien. Enige correctie en nuancering is geboden, om spraakverwarring te voorkomen.
Maatschappij
Shutterstock
Shutterstock

Om met de deur in huis te vallen: audits zijn inderdaad een bron van misverstanden. Maar zij zijn ook, en nog veel meer, slachtoffer van misverstanden. Misverstand nummer één is dat zij alleen maar lastig zijn. Het gaat er bij audits, reviews en assessments om dat de opdrachtgever een frisse kijk krijgt op de stand van een project of een beheerafdeling, met als einddoel een betere beheersing van de processen in de organisatie. Beheersingsmaatregelen ­ in de hedendaagse managementtaal: ‘controls’ ­ zijn immers wat de interne klanten, de business en/of de projectopdrachtgevers nodig hebben om ‘in control’ te zijn. Oftewel: de bestuurder wil stuur en pedalen plus een dashboard, anders belandt de hele organisatie in de vangrails. En kreukelzones, gordels en een setje airbags zijn ook wel aardig. Daar kijkt de auditor dus naar, als APK­keuring. Want zonder audits zouden onder druk van allerlei externe en interne factoren, zoals tijd, geld, motivatie en bereidheid tot samenwerken, die beheersingsmaatregelen vaak al snel onder een aanvaardbaar niveau zakken. Dat geldt des te meer in tijden van outsourcing, omdat het dan voor de interne klanten steeds minder mogelijk is eventjes bij de IT­manager te buurten om wat zaken informeel recht te zetten. Er zal meer formeel moeten worden vertrouwd op het toezicht dat auditors houden op het servicemanagement en de service delivery die buiten de deur gebeuren. En dan gaan we er voor het gemak vanuit dat het toezicht door auditors in de uitbestedingscontracten goed is geregeld. Strenge oom Misverstand nummer twee is dat de auditor een strenge oom is die geen grijstinten kent, zoals Stouthart stelt. De auditor zoekt helemaal niet naar ‘complete processen’ (‘whatever that may be’), maar is zich er zeer van bewust wat het gevecht van alledag in organisaties betekent voor de beheersingsmaatregelen. Dat is juist waarvoor de beheersingsmaatregelen bestaan ­ in een ideale wereld gaat immers alles vanzelf en zonder bijsturing goed, nietwaar? Een IT­auditor spreekt, zeker als het om projecten gaat, overigens liever van een ‘review’. Bij een ‘audit’, een formele doorlichting, zal namelijk de hele projectorganisatie zo gedetailleerd tegen een norm worden aangehouden dat geen project er goed vanaf zou komen. Als een auditor met een normenverzameling komt, zal dat dan ook eerder een minimum­ dan een maximumset zijn van wat er aan activiteiten en ‘deliverables’ door het project opgeleverd zouden moeten worden. De normen worden ook in principe niet door de auditor vastgesteld, maar door de opdrachtgever, de auditor zal hoogstens bij gebrek daaraan een eigen verzameling aandragen. Van zo’n projectaudit­tot­in­alle­detail wordt een auditor ook niet warm omdat hij dat gevecht van alledag wel ziet. En het exact naleven door een project van alle denkbare procedurebureaucratie is vaak niet nuttig voor het algemeen (organisatie)belang, en dat is de drijfveer van de auditor. Daarom zal hij, ook bij een projectreview, niet alleen kijken naar de opzet en het bestaan maar ook naar de werking van procedures en maatregelen, én naar de werking van de deliverables. Nog steeds zijn er bedrijven en afdelingen die keurig netjes ‘volgens ISO 9000’ vierkante wielen produceren, maar ­ misverstand nummer drie ­ auditors kijken wel degelijk ook naar de uiteindelijke uitkomsten, dus of de procedures en maatregelen wel hebben bereikt waarvoor ze waren ingesteld; vierkante wielen voldoen niet. Als een auditor daar niet op let, dan is dát nou iets om hem op aan te spreken. Daarbij aansluitend zou er sprake zijn van een spanningsveld tussen auditor en manager over ‘evidence’. Evidence verzamelen (bewijsstukken die beweringen van de gecontroleerde partij onderbouwen), doen ook de grootste dorknopers onder de auditors niet voor hun lol. Ook hier geldt dat de waarde die auditors, en anderen, aan evidence hechten, voortkomt uit de noodzakelijke controleerbaarheid van het auditwerk. Die controleerbaarheid is nodig om duidelijke redenen: een ander moet kunnen zien dat de auditor zijn werk naar behoren heeft gedaan, zodat duidelijk is dat zijn bevindingen niet voortkomen uit een onderbuikgevoel of vooroordelen ­ ook hij heeft een paar menselijke trekjes en die moeten worden tegengegaan. Kortom, de auditor doet wat hij doet niet alleen voor zijn eigen plezier. Open kaart De middelen bij uitstek om onaangename verrassingen en frustraties rond reviewuitkomsten te voorkomen, zijn dan ook het (project)­werk goed te doen en open kaart te spelen. Voorbereiding door alvast bij voorbaat geschut in stelling te brengen, is daarin belangrijk, niet om dat tegen de auditor te richten maar tegen de problemen waar de auditor net als ieder ander tegenaan zou kunnen lopen. Een auditor heeft overigens heel goed door wanneer de problemen net een dag voordat hij langskomt, zijn opgeruimd. Maar dat is niet erg, áls de problemen maar worden opgelost en als is gewaarborgd dat niet de volgende dag de beheersingsmaatregelen weer de kast ingaan. Het heeft ook geen zin om de boodschapper aan te vallen. Dat maakt alleen maar duidelijk dat de projectmanager geen verweer heeft tegen de inhoudelijkheid van de bevindingen. Zachte, wollige formuleringen kunnen helpen, maar de goede lezer haalt de boodschap tussen de regels er toch wel uit. Het gaat er dus niet om de eigen wensen voor de uitkomsten openlijk of door verleidingstrucs te dicteren, maar om het afstemmen van de verwachtingen van de plaats van de review in het grotere geheel van projectgovernance of bedrijfsbrede beheersing. De auditor moet daarom de verwachtingen van de projectmanager scherpstellen. En ook moeten de projectmanager én de auditor aan andere partijen duidelijk maken dat de review niet bedoeld is om een cijfer voor vlijt, ijver en netheid te geven of juist het hoofd van de projectmanager op het hakblok te leggen. De auditor kan zelf zien dat de projectmanager roeit met de riemen die hij heeft, en dat het vullen van gaten alleen gaat als ook de auditor, vaak op een hoger organisatieniveau, de lacunes duidt en de tekorten in resources eens te meer onder de aandacht brengt. Afstandelijkheid en onafhankelijkheid van de auditor zijn nodig om op die hogere niveaus erkenning te krijgen van de auditresultaten. De eigenlijke opdrachtgever komt er anders snel genoeg achter dat de auditor zich voor het karretje van de projectmanager heeft laten spannen. Overigens zal er inderdaad in rapporten ruimte moeten zijn voor managementreacties. Het is beter dat die bij de bevindingen staan ­ ook al is het ‘agree to disagree’ ­ dan dat achteraf allerlei ‘ja­maars’ de ronde doen. Negatief signaal Als er een punt is dat tot problemen kan leiden, dan is het wel dat een projectreview nogal eens pas wordt uitgevoerd als het project is vastgelopen ­ of op z’n vroegst als de stuurgroep zenuwachtig is geworden door geruchten of gebrek aan goede informatie van de projectmanager. Het inroepen van een auditor (van buiten) is dan een negatief signaal op zich. Zelfs in zo’n geval is een review tóch op z’n plaats. Soms blijkt er niet eens bijzonder veel mis te zijn, en is het meer het algemene gevoel van onzekerheid over de toekomst dat opspeelde. Een frisse kijk kan ook helpen aan te wijzen wat er anders moet om het project alsnog met enig, of veel, succes af te ronden. En een review kan een extra zet zijn om anderen dan alleen de kerngroep van het projectteam, in actie te krijgen om met het project mee te denken. Communicatiestoornissen (denk aan verwachtingsmanagement) ontstaan juist als er een te sterke wij/zij­cultuur ontstaat tussen projectteam en de ‘stakeholders’, waarvan de gebruikers en het gebruikersmanagement nogal eens in een andere denkwereld leven dan de ontwikkelaars. De auditor kan dan een brug slaan tussen die partijen, maar dan moet hij wel z’n best doen. Toch is het vaak veel handiger om een auditor al eerder bij projecten te betrekken. Hij kan ­ om de on­ afhankelijkheid te bewaren ­ weliswaar geen vervanger zijn van de quality­assurancefunctionaris die namens de projectmanager de kwaliteit van deliverables in de gaten houdt. Maar hij kan wel tijdens het project aanwijzen wat er buiten de band van de normen gaat lopen, waar procedures nog niet voldoende zijn, wat er aan informatiebeveiliging anders moet et cetera. Dan komen er niet pas aan het eind van een project allerlei vervelende konijnen uit de hoge hoed. Bovendien is bijsturen tijdens het project meestal veel minder duur dan achteraf de noodzakelijke verbeteringen doorvoeren. De gebreken moeten toch worden opgelost ­ de auditor signaleert ze niet voor niets. Audits zijn dus niet (noodzakelijkerwijs) hinderlijk, noch overbodig of nutteloos, maar horen er gewoon bij. Al met al is er niks mis mee om een auditor over de vloer te hebben. Ir.drs. J. van der Vlugt RE CISA (JurgenHimself@vdvlugt.com) is IT­auditmanager bij Group Audit van ABN Amro Bank. Dit artikel is geschreven op persoonlijke titel.

Lees dit PRO artikel gratis

Maak een gratis account aan en geniet van alle voordelen:

  • Toegang tot 3 PRO artikelen per maand
  • Inclusief CTO interviews, podcasts, digitale specials en whitepapers
  • Blijf up-to-date over de laatste ontwikkelingen in en rond tech

Bevestig jouw e-mailadres

We hebben de bevestigingsmail naar %email% gestuurd.

Geen bevestigingsmail ontvangen? Controleer je spam folder. Niet in de spam, klik dan hier om een account aan te maken.

Er is iets mis gegaan

Helaas konden we op dit moment geen account voor je aanmaken. Probeer het later nog eens.

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in

Maak een gratis account aan en geniet van alle voordelen:

Heb je al een account? Log in