8 Implicaties van het uitgevoerde onderzoek voor de praktijk
8.4 Beperkingen van het uitgevoerde onderzoek
Vanuit het onderzoek zijn enkele beperkingen geconstateerd. Bij de invulling van de vragenlijst hebben enkele experts te kennen gegeven dat zij het moeilijk vonden een antwoord te kiezen. De indeling in auditcategorieën zorgde ervoor dat veel keuzemogelijkheden waren gecreëerd. Het is aan te bevelen voor soortgelijk (vervolg)onderzoek in de vragenlijst enkel ‘ja’ en ‘nee’ als antwoorden op te nemen, aangevuld met de mogelijkheid ‘ja, tenzij’. Op deze manier hebben de experts meer keuzevrijheid in hun antwoorden, en hebben zij niet de indruk dat sprake is van auditcategorieën die mogelijk in hun ogen niet bestaan.
In de uitkomsten van het onderzoek zijn elf werkwijzen (‘multidisciplinair team’,
‘stakeholdermapping’, ‘retro met de klant’, ‘persoonlijke kanban’, ‘werkafspraken’, ‘fysiek op een locatie werken’, ‘backlog als auditjaarplan’, ‘fastlane’, ‘onderhanden-werk-limiet’ en ‘heartbeats’) als verrijkend aangenomen enkel op basis van de expertvalidatie. Van deze werkwijzen zijn het effect en resultaat niet bekend, en is niet duidelijk aan welke agile-kenmerken zij een bijdrage leveren. Om deze reden kan geen uitspraak worden gedaan in hoeverre de werkwijzen bijdragen aan de verbetering van de flexibiliteit en het aanpassingsvermogen in een audit.
52 8.5 Aanbevelingen voor vervolgonderzoek
In dit onderzoek is enkel gefocust op de theorie, die vervolgens is gevalideerd door experts.
Vervolgonderzoek is noodzakelijk om na te gaan of de agile-werkwijzen in de praktijk daadwerkelijk een verrijking vormen voor auditmethodologie. In vervolgonderzoek is het mogelijk te
experimenteren met de werkwijzen die als verrijkend zijn aangenomen. Daarmee kan worden onderzocht of daadwerkelijk meer flexibiliteit en aanpassingsvermogen in een audit wordt
gerealiseerd. Het is daarbij van belang na te gaan of de elf werkwijzen aangedragen door de experts daadwerkelijk bijdragen aan deze agile-kenmerken. Vervolgonderzoek zou zich ook kunnen focussen op de toegevoegde waarde die een opdrachtgever ervaart wanneer de voorgestelde werkwijzen worden toegepast. Tot slot kan worden onderzocht of het mogelijk is binnen de IAF meer agile toe te passen, naast de toepassing van werkwijzen binnen audits.
53 Bibliografie
Abrahamsson, P., Conboy, k., & Wang, X. (2009). Lots done, more to do': the current state of agile systems development research. European Journal of Information Systems, 18(4), 281-284.
Abrahamsson, P., Warsta, B., Siponen, M. T., & Ronkainen, j. (2003). New Directions on Agile Methods: A comparative Analysis. 25th International Conference on Software Engineering, (pp. 244-254).
Alqudah, M., & Razali, R. (2017). Key Factors for Selecting an Agile Method: A Systematic Literature Review. International Journal on Advanced Science Engineering Information Technology, 7(2), 526-537.
Al-Zewairi, M., Biltawi, M., Etaiwi, W., & Shaout, A. (2017). Agile Software Development Methodologies:Survey of Surveys. Journal of Computer and Communications, 5, 74-97.
Ayed, H., Vanderose, B., & Habra, N. (2014). Supported Approach for Agile Methods Adaptation:An Adoption Study. Proceedings of the 1st International Workshop on Rapid Continuous Software Engineering, (pp. 36-41). Hyderabad, India.
Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., . . . Thomas, D. (2001).
Manifesto for Agile Software Development. Opgeroepen op juni 20, 2017, van agilemanifesto: http://agilemanifesto.org/
Blom, M. (2010). Is Scrum and XP suitable for CSE Development? Procedia Computer Science, 1(1), 1511-1517.
Bos, P., De Korte, R., & Otten, J. (2017). Management Control Auditing: bijdragen aan doelrealisatie en verbetering. Driebergen, Nederland: Auditing.nl.
Bowers, A., Sangwan, R., & Neill, C. (2007). Adoption of XP Practices in the Industry – A Survey.
Software Process: Improvement and Practice, 12(3), 283-294.
Burch, S. (2011). Building an internal audit function: whether creating or transforming an audit function, CAEs need to understand all of the critical components-from stakeholder support to the audit methodology. Internal Auditor, 68(1), 46-51.
Cervone, H. F. (2011). Understanding agile project management methods using Scrum. OCLC Systems
& Services: International digital library perspectives, 27(1), 18-22.
Chirouze, O., Cleary, D., & Mitchell, G. (2005). A software methodologyfor applied research:eXtreme Researching. Software: Practice and Experience, 35(15), 1441-1454.
Chowdhury, A., & Huda, M. N. (2011). Comparison between Adaptive Software Development and Feature Driven Development. Proceedings of 2011 International Conference on Computer Science and Network Technology,, (pp. 363-367).
Conforto, E. C., Salum, F., Amaral, D. C., Silva, S. L., & Almeida, L. F. (2014). Can agile project management be adopted by industries other than software development. Project Mananagement Journal, 45(3), 21-34.
De Korte, R., & Otten, J. (2003). Operational audit: Van ‘containerbegrip’ naar een methodologisch ondersteunde auditvorm. Opgehaald van Auditing.nl.
Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. The Journal of Systems and Software, 119, 87-108.
Dingsøyr, T., Nerur, S., Balijepally, V., & Moe, N. (2012). A decade of agile methodologies: Towards explaining agile software development. The Journal of Systems and Software, 85, 1213-1221.
Driessen, A., & Molenkamp, A. (2012). Internal auditing : een managementkundige benadering (5e, (herz) ed.). Deventer: Kluwer.
Drury, M., Conboy, K., & Power, K. (2012). Obstacles to decision making in Agile software development teams. The Journal of Systems and Software, 85, 1239-1254.
Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review.
Information and Software Technology(50), 833-859.
54 Fernandes , J., & Almeida, M. (2010). Classification and Comparison of Agile Methods. 2010 Seventh
International Conference on the Quality of Information and Communications Technology (pp.
391-396). IEEE Computer society.
Ghosh, G. (2012). Challenges in Distributed Scrum. 2012 IEEE Seventh International Conference on Global Software Engineering, (pp. 200-220).
Hamed, A., & Abushama, H. (2013). Popular Agile Approaches in Software Development: Review and Analysis. International confrence on computing, electrical an electronic engineering (pp. 160-166). Khartoum, Sudan: University of Khartoum.
Henderson-Sellers, B., & Serour, M. K. (2005). Creating a Dual-Agility Method: The Value of Method Engineering. Journal of Database Management, 16(4), 1-26.
Hoogveld, M. (2016). Agile managen. Culemborg, Nederland: Van Duuren Media.
Hu, Z., Yuan, Q., & Zhang, X. (2009). Research on Agile Project Management with Scrum Method. IITA International Conference on Services Science, Management and Engineering, (pp. 26-29).
Zhangjiajie, China.
Inayat, I., Salim, S., Marczak, S., & Daneva, M. (2015). A systematic Literature review on agile requirements engineering practices and challenges. Computers in Human Behavior, 51, 915-929.
Ionel, N. (2008). Critical analysys of the scrum project. Annals of the University of Orade, 435-441.
Jalali, S., Wohlin, C., & Angelis, L. (2014). Investigating the applicability of Agility assessment surveys:
A case study. The Journal of Systems and Software(98), 172-190.
Koch, A. S. (2005). Agile Software Development, Eveluating the Methods for your Organisation.
Norwood: Artech House.
Kongyai, B., & Edi, E. (2011). Adaptation of Agile Practices: A Systematic Review and
Survey-Adaptation of Agile Practices: A Systematic Review and Survey. Dr. Jürgen Blekinge Tekniska Högskola, Sektionen för datavetenskap och kommunikation.
Lee, G., & Xia, W. (2010). Toward Agile: An integrated analysis ofquantative and qualitive field data on software development agility. MIS Quarterly, 34(1), 87-114.
Llamas, V., Coudert, T., Geneste, L., Romero-Bejarano, J., & de Valroger, A. (2016). Proposition of an agile knowledge-based process model. IFAC PapersOnLine, 49(12), 1092-1097.
Lyytinen, K., & Rose, G. M. (2006). Information System Development Agility as Organizational Learning. European Journal of Information Systems, 15(2), 183-199.
Mahadevan, D. (2017, Januari). ING’s agile transformation. Opgeroepen op februari 13, 2017, van www.mckinsey.com:
http://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation
Mann, C., & Maurer, F. (2005). A Case Study On The Impact of Scrum On OvertimeAnd Customer Satisfaction. Agile 2005 Conference, (pp. 70-79).
Matharu, G., Mishra, A., Singh, H., & Upadhyay, P. (2015). Empirical Study of Agile Software
Development Methodologies: A Comparative Analysis. ACM SIGSOFT Software Engineering Notes, 40(1), 1-6.
Munteanu, V., & Berechet, M. (2016). Challenges of the Audit Profession in the Globalization Era.
Academic Journal of Economic Studies, 2(2), 169-178.
Nuijten, A., Van Twist, M., & Van der Steen, M. (2015). Auditing Interactive Complexity: Challenges for the Internal Audit Profession. International Journal of Auditing, 19, 195-205.
Otten, J., Hartog, P. A., & Babeliowsky, A. (2002, December). Auditmethodologie, meta-tool voor klantgericht auditen. Opgehaald van Docplayer:
http://docplayer.nl/1516917-Auditmethodologie-meta-tool-voor-klantgericht-auditen.html
Overhage, S., & Schlauderer, S. (2012). Investigating the Long-Term Acceptance of Agile
Methodologies:An Empirical Study of Developer Perceptions in Scrum Projects. 45th Hawaii International Conference on System Sciences, (pp. 5453-5461).
Paterson, J. C. (2015). Lean Auditing: Driving Added Value and Efficiency in Internal Audit. Chichester:
John Wiley & Sons.
55 Pino, F., Pedreira, O., García, F., Luaces, M., & Piattini, M. (2010). Using Scrum to guide the execution
of software process improvement. The Journal of Systems and Software, 83, 1662-1677.
Qumer, A., & Henderson-Sellers, B. (2006). Measuring agility and adoptability of agile methods; a 4-dimensional analytical tool. IADIS International Conference Applied Computing, (pp. 503-507).
Qumer, A., & Henderson-Sellers, B. (2008a). An Evaluation of the Degree of Agility in Six Agile
Methods and its Applicability for method engineering. Information and Software Technology, 50(4), 280-295.
Qumer, A., & Henderson-Sellers, B. (2008b). A framework to support the evaluation, adoption and improvement of agile methods in practice. The Journal of Systems & Software, 81(11), 1899-1919.
Qureshi, R., & Hussain, S. (2008). An adaptive software development process model. Advances in Engineering Software, 39(8), 654-658.
Ribeiro, F. L., & Fernandes, M. T. (2009). Exploring agile methods in construction small and medium enterprises: a case study. Journal of Enterprise Information Management, 23(2), 161-180.
Riehle, D. (2000). A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other. SKYVA International.
Rising, L., & Janoff, N. (2000). The SCRUM software development process for small teams. IEEE Software, 26-32.
Sarens, G., & Lamboglia, R. (2014). The (mis)fit between the profile of internal auditors and internal audit activities. Accounting and Business Research, 44(1), 41-62.
Scheffield, J., & Lemétayer, J. (2013). Factors associated with the software development agility of succesful projects. International Journal of Project Management, 31(3), 459-472.
Sherehiy, B., Karwowski, W., & Layer, J. K. (2007). A review of enterprise agility: Concepts, frameworks, and attributes. International Journal of Industrial Ergonomics, 37, 445-460.
Stray, V., Lindsjørn, Y., & Sjøberg, D. (2013). Obstacles to Efficient Daily Meetings in Agile
Development Projects: A Case Study. IEEE International Symposium on Empirical Software Engineering and Measurement, (pp. 95-102).
Sutherland, J. (2014). Scrum, Tweemaal zoveel doen in de helft van de tijd. Amsterdam: Maven Publishing.
Taromirad, M., & Ramsin, R. (2008). CEFAM: Comprehensive Evaluation Framework for Agile Methodologies. 32nd Annual IEEE Software Engineering Workshop, (pp. 195-204).
The institute of Internal Auditors. (2016, 12). Implementation Guide 2200.
The institute of Internal Auditors. (2017). International Standards for the Professional Practice of Internal Auditing (Standards). Opgehaald van The intitute of internal auditors.
Verschuren, P., & Doorewaard, H. (2015). Het ontwerpen van een onderzoek. Amsterdam: Boom.
Wood, S., Michaelides, G., & Thomson, C. (2013). Successful extreme programming: Fidelity to the methodology or good teamworking? Information and Software Technology, 55(4), 660-672.
56 Bijlage 1 Begripsbepaling Agile-werkwijzen
• Backlog per audit: Een backlog is een lijst met ‘brokken’ werk in volgorde van urgentie. De opdrachtgever/ proceseigenaar heeft invloed op het bepalen van de urgentie en de ‘brokken’
werk die op de backlog worden geplaatst (Sutherland, 2014).
• Werken in iteraties (sprints): Een iteratie bestaat uit een vaste periode waarin een gedeelte van het werk wordt opgeleverd. Iedere iteratie heeft een bepaald einddoel, waarbij de opdrachtgever/ proceseigenaar een product (rapport) ontvangt (Hu, Yuan, & Zhang, 2009).
• Dagstart: Een dagelijkse bijeenkomst van het team waarin hulpvragen kunnen worden belegd (Sutherland, 2014).
• Dagstart zoals in krimi’s: Het toepassen van dagstarts als een briefing zoals in ‘Krimi’s. De laatste status van het onderzoek wordt besproken, argumenten worden uitgewisseld en het werk wordt voor de dag verdeeld (Expert 1, bijlage 13).
• Multidisciplinair team: Het team is samengesteld uit medewerkers met verschillende specialismen.
• Meedraaien in agile-businessteams: De auditor draait mee in het agile-businessteam en geeft direct input tijdens de lopende iteratie en waar mogelijk al bij de dagstart (Expert 9, bijlage 13).
• Stakeholdermapping: Het in kaart brengen van alle belanghebbenden voor een audit (Expert 3, bijlage 13).
• Demo/review: Het tussentijds rapporteren van de (audit)resultaten, waarmee een klant (auditee) direct aan de slag kan (Sutherland, 2014).
• Retro met de klant: Een evaluatie van de afgelopen iteratie samen met de klant. De klant krijgt de mogelijkheid om (proces)verbetering aan te dragen voor de komende iteratie (Sutherland, 2014).
• Retro met het team: Na iedere iteratie vindt een evaluatie plaats met het team over het teamproces, wat ging goed en wat kan beter. Dit voor zowel het werkproces als de onderlinge relaties (Overhage & Schlauderer, 2012).
• Planningsspel: Een methode om in te schatten hoeveel effort in een deel van de werkzaamheden wordt gestoken. Door alle teamleden worden de verschillende
deelwerkzaamheden door middel van punten ingeschat, waarbij als referentiekader andere werkzaamheden gelden. De hoogste en laagste toebedeelde punten worden geëvalueerd (Al-Zewairi, Biltawi, Etaiwi, & Shaout, 2017).
57
• Scrummeester: Een scrummeester is een vaste rol binnen het team. Deze faciliteert alle rituelen en bewaakt het proces (Sutherland, 2014).
• Persoonlijke kanban: Per auditor wordt een bord gemaakt met ‘to do’, ‘in progress’ en
‘done’, waarin alle taken voor een dag worden geplot. Gedurende de dag verschuift de auditor de taken over het bord (Expert 2, bijlage 13).
• Fysiek op een locatie werken: Het team werkt samen in een ruimte dicht bij elkaar.
• Backlog als auditjaarplan: Een overzicht met alle gewenste auditopdrachten die na elke opdracht wordt geëvalueerd. Op basis van prioriteit wordt de volgende opdracht gekozen (Expert 3, bijlage 13).
• Fastlane: Wanneer er een incident binnen komt, komt het team bij elkaar. Het incident wordt in de fastlane geplaatst. Een medewerker zet zijn reguliere taken ‘on hold’. Pas als de taak met prioriteit is afgerond, wordt de reguliere taak weer opgepakt (Expert 2, bijlage 13).
• Onderhanden-werk-limiet: Het aantal deelwerkzaamheden waaraan wordt gewerkt is het aantal teamleden gedeeld door 2 (naar boven afgerond). Nieuwe werkzaamheden worden pas gestart als het aantal werkzaamheden onder het onderhanden-werk-limiet is gedaald Expert 2, bijlage 13).
• Heartbeats: Iedere drie tot vier dagen bestaat er contract tussen de auditor en
belanghebbenden voor afstemming over de resultaten die aan het einde van de iteratie worden opgeleverd. Een heartbeat heeft een kortere frequentie dan de iteraties (Expert 2, bijlage 13).
58 Bijlage 2 Overzicht deelnemende experts
De inhoud van deze bijlage is verwijderd i.v.m. de privacy van de respondenten.
59 Bijlage 3 Auditmethodologie geprojecteerd op dimensie 1 van het 4-DAT-model
In het eerste perspectief van het 4-DAT-model worden de scope en toepasbaarheid van de
verschillende methoden in kaart gebracht. Voor de toepasbaarheid van het 4-DAT-model is in deze analyse ervoor gekozen de stijl van coderen en de dataverkrijgingsmethode achterwege te laten.
Deze twee elementen hebben enkel een technisch component en zijn gericht op
IT-ontwikkelmethoden. Voor het analyseren van auditmethodologie bieden deze elementen derhalve geen toegevoegde waarde. De resultaten van de analyse voor perspectief 1 zijn opgenomen in Tabel 1: Scope en toepasbaarheid.
Tabel 1 laat zien dat bij het toepassen auditmethodologie sprake is van een gefaseerde werkwijze waarbij chronologisch in volgorde van tijd wordt gewerkt. Dit in tegenstelling tot de op agile
gebaseerde methoden waarbij iteratief werken gebruikelijk is. Scopeafbakening is cruciaal en leidend voor het uitvoeren van een audit.
Op basis van de verkregen informatie kan worden geconcludeerd dat auditmethodologie toepasbaar is binnen een omgeving waarbij voorafgaand aan de uitvoering opdracht de scope bekend is. Voor het uitvoeren van de opdracht is het van belang dat er zich weinig wijzigingen voordoen in de omgeving. Immers, wanneer scopeafbakening cruciaal is mag verwacht worden dat hier in de loop van de opdracht niet meer van af wordt geweken.
Criterium Auditmethodologie en beheersing 1. Omvang van het
project
Scopeafbakening cruciaal, niet gespecificeerd hoeveel auditobjecten kunnen worden onderzocht of hoe groot een audit mag zijn.
2. Omvang van het team
Niet gespecificeerd.
3. Ontwikkelmethode Clusteren van inhoudelijke activiteiten in logische stappen van tijd, projectfasen.
4. Technologische omgeving
Niet gespecificeerd.
5. Fysieke omgeving Niet gespecificeerd.
6. Organisatiecultuur Niet gespecificeerd.
Tabel 1: Scope en toepasbaarheid
60 Bijlage 4 Auditmethodologie en de belangrijkste kenmerken van agile
Tabel 1 is ingevuld op basis van beschrijving auditmethodologie van Bos e.a. (2017).
Audit methodologie Flexibiliteit Snelheid Mate van lean Leren Reactievermogen Totaal
Fasen
Selectie van het auditobject Er is voor een gedeelte sprake van opgelegde audits en audits op verzoek. Daarnaast wordt gebruik gemaakt van een risicoanalyse om te komen tot een selectie van objecten met als resultaat een globale auditdoelstelling. Derhalve houdt de selectie van het auditobject rekening met zowel verwachte als onverwachte veranderingen (1).
Objectselectie vindt plaats op basis van risicoanalyse en aandragen door
verantwoordelijken.
draagvlaksessies zijn nodig voor goedkeuring. Dit proces kan veel tijd in beslag nemen. Derhalve betreft het geen snel proces. Het levert tevens geen direct bruikbaar resultaat voor de opdrachtgever (0).
Objectselectie vindt plaats op basis van risicoanalyse en aandragen door verantwoordelijken. Draagvlaksessies zijn nodig voor goedkeuring. Dit proces kan veel tijd in beslag nemen. Derhalve kan het selecteren van auditobjecten niet als lean worden gekenmerkt (0).
Door de organisatie uitgevoerde risicoanalyses kunnen als input worden gehanteerd, evenals opgedane kennis uit eerdere audits. Dit leidt ertoe dat wordt geleerd/ gebruik wordt gemaakt van eerdere opgedane kennis (1).
De selectie van auditobjecten resulteert in een auditplanning voor 1 of meerdere jaren.
Hierdoor is het lastiger om gedurende het jaar te reageren op veranderingen. Deze methode kent tevens geen tussentijdse afstemming. Derhalve is het reactievermogen op basis van de selectie van auditobjecten laag (0).
2
Voorbereiding Binnen de context analyse en technische analyse wordt een vaste set aan onderwerpen onderzocht. Doel is om te komen tot een zo voorspelbaar mogelijke situatie. Op basis van een kosten/baten afweging wordt vervolgens invulling gegeven aan de werkwijzen die in de gehele opdracht worden gehanteerd. In de voorbereiding wordt gekozen welke werkwijzen worden gehanteerd, derhalve is er sprake van flexibiliteit (1).
De omvang en de doorlooptijd moeten beperkt blijven omdat meerwaarde van informatie afneemt en je anders voortijdig conclusies trekt. Derhalve ligt de snelheid van de
voorbereiding tot oplevering van een auditontwerp hoog.
De opdrachtgever ontvang snel een concept auditontwerp (1).
Het gebruiken van vaste instrumenten (context en technische analyse) en de kortste doorlooptijd worden gestimuleerd, hieruit blijkt dat lean werken van belang is (1).
Er wordt navraag gedaan naar ervaringen uit eerdere audits, hieruit blijkt leervermogen (1).
In een gedegen voorbereiding wordt de context van de opdracht in kaart gebracht. Op basis van de verwachte en onverwachte veranderingen wordt bepaald welke werkwijzen in de opdracht worden toegepast.
Deze inventarisatie vindt plaats voorafgaand aan de opdracht. Derhalve leidt de voorbereid tot een resultaat waarbij het inspelen op onverwachte verandering wordt beperkt (0).
4
Gegevensverzameling In het technisch ontwerp is vastgelegd van welke methoden gebruik gemaakt wordt en welke bronnen verzameld dienen te worden verzamelen.
Derhalve is er weinig flexibiliteit in de gegevensverzamelingsfase (0).
Er geen sprake van een iteratief proces. De verzameling van gegevens vindt plaats, waarna overgegaan kan worden na de volgende fase. Derhalve levert deze fase levert geen direct resultaat voor de opdrachtgever (0).
Bij de keuzes die worden gemaakt voor gegevensverzameling worden doelmatigheid en betrouwbaarheid als uitgangspunt gehanteerd. Triangulatie wordt als kwaliteitsinstrument gehanteerd. Daarnaast hebben budget en tijd invloed op de keuzes die worden gemaakt. Derhalve kan gesteld worden dat er nagedacht wordt over doorlooptijd en kosten efficiëntie.
Daarom wordt gegevensverzameling als lean aangemerkt (1).
Wanneer een audit vaker wordt uitgevoerd, kan worden gekozen voor een
gestandaardiseerde werkwijze.
Hieruit blijkt het leereffect (1).
Interviews bieden de mogelijkheid om in te spelen op hetgeen er op dat moment speelt bij de auditee. Hoor wederhoor biedt de mogelijkheid te reageren en daardoor werkzaamheden aan te passen. Echter is er sprake van een audit ontwerp waaraan gehouden wordt gedurende de opdracht.
Derhalve is het reactievermogen beperkt (0).
2
61
Gegevensverwerking, analyse, oordeelsvorming
In het technisch ontwerp is vastgelegd hoe gegevens worden geanalyseerd en hoe oordeelsvorming plaats zal vinden. De keuze hierin is reeds bepaald, waardoor geen rekening meer wordt gehouden met verwachte en onverwachte veranderingen (0).
Er is geen sprake van een iteratief proces waarbij oordeelsvorming snel plaats vindt nadat het veldwerk is afgerond. De opdrachtgever ziet pas resultaat bij de rapportage. Derhalve is de snelheid laag (0).
Kwaliteitsinstrumenten als hoor/wederhoor en een bronnenmatrix worden ingezet.
Documentatie wordt vastgelegd zodat ten alle tijden het onderzoek transparant en reproduceerbaar is. Er wordt met meerdere personen gewerkt aan het opstellen van conclusies om interpretatie niet van 1 persoon af te laten hangen. Geen specifieke stimulans van doorlooptijd of gebruik beperkte resources.
Derhalve is de mate van lean beperkt (0).
Wanneer een audit vaker wordt uitgevoerd kan worden gekozen voor een gestandaardiseerde werkwijze die eerder is toegepast. De wijze waarop het team tot een oordeel komt is dan reeds bekend. Hiermee wordt een leereffect behaald.
Leren wordt derhalve toegepast (1).
De verwerking van de gegevens en wijze waarop oordeelsvorming plaats vindt is in het auditontwerp bepaald. Deze methode zorgt ervoor dat de werkwijze niet direct wordt aangepast bij verwachte en onverwachte veranderingen. Derhalve kan worden gesteld dat het reactievermogen in deze fase beperkt is (0).
1
Rapportage In het technisch ontwerp is al
Rapportage In het technisch ontwerp is al