{"id":342,"date":"2025-11-10T13:09:21","date_gmt":"2025-11-10T13:09:21","guid":{"rendered":"https:\/\/bjornproost.nl\/?page_id=342"},"modified":"2025-11-10T13:10:17","modified_gmt":"2025-11-10T13:10:17","slug":"7-2-de-business-case-technische-validatie","status":"publish","type":"page","link":"https:\/\/bjornproost.nl\/?page_id=342","title":{"rendered":"7.2 De Business Case & Technische Validatie"},"content":{"rendered":"\n

De Business Case & Technische Validatie<\/strong><\/h2>\n\n\n\n

De fase Business Case & Technical Validation<\/em> is het moment waarop ambitie en realiteit elkaar ontmoeten.
Tot nu toe is de basis gelegd: de Statement of Work<\/strong> is ondertekend, de projectgereedheid<\/strong> is getoetst, en de eerste tools zoals de Access Tracker<\/strong> en Issue Tracker<\/strong> zijn ingericht.
Maar de vraag die nu centraal staat is: \u201cIs dit proces \u00e9cht geschikt voor automatisering, en wat levert het op?\u201d<\/em><\/p>\n\n\n\n

Doel van deze fase<\/strong><\/h3>\n\n\n\n

Het doel van deze fase is om de haalbaarheid, waarde en complexiteit<\/strong> van de geselecteerde processen objectief te beoordelen.
Of het nu gaat om factuurverwerking, dossierbeheer of klantacceptatie \u2014 deze fase bepaalt of de inspanning opweegt tegen de verwachte opbrengst.<\/p>\n\n\n\n

De drie belangrijkste rollen in deze fase zijn:<\/p>\n\n\n\n

    \n
  • Automation Business Analyst (ABA)<\/strong> \u2013 voert de opportunity assessment en business case uit.<\/li>\n\n\n\n
  • Solution Architect (SA)<\/strong> \u2013 beoordeelt technische haalbaarheid, afhankelijkheden en systeemeisen.<\/li>\n\n\n\n
  • Project Manager (PM)<\/strong> \u2013 bewaakt scope, planning en stakeholderafstemming.<\/li>\n<\/ul>\n\n\n\n
    \n\n\n\n

    De Opportunity Assessment<\/strong><\/h3>\n\n\n\n

    De Opportunity Assessment is de kernactiviteit.
    De Business Analyst onderzoekt of het proces voldoet aan de criteria voor automatisering:<\/p>\n\n\n\n

    Aspect<\/strong><\/th>Vragen<\/strong><\/th>Wat wordt beoordeeld?<\/strong><\/th><\/tr><\/thead>
    Procesvolume<\/strong><\/td>Hoe vaak komt het proces voor per maand?<\/td>Hoog volume verhoogt waarde van automatisering.<\/td><\/tr>
    Stabiliteit<\/strong><\/td>Verandert de werkwijze regelmatig?<\/td>Stabiele processen zijn beter automatiseerbaar.<\/td><\/tr>
    Regelmatigheid<\/strong><\/td>Volgt het proces vaste regels?<\/td>Hoe meer regelgebaseerd, hoe beter.<\/td><\/tr>
    Datakwaliteit<\/strong><\/td>Is de input digitaal en gestructureerd?<\/td>Onleesbare of onvolledige data verhogen complexiteit.<\/td><\/tr>
    Foutgevoeligheid<\/strong><\/td>Hoe vaak treden menselijke fouten op?<\/td>Hoge foutkans = kansrijke kandidaat.<\/td><\/tr>
    ROI-potentieel<\/strong><\/td>Welke tijd- of kostenbesparing levert automatisering op?<\/td>Maakt businesscase kwantificeerbaar.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    De output van deze beoordeling wordt vastgelegd in een Opportunity Assessment Template<\/strong>, waarin scorepercentages worden berekend op basis van complexiteit, haalbaarheid en verwachte baten.<\/p>\n\n\n\n

    \n\n\n\n

    De Business Case<\/strong><\/h3>\n\n\n\n

    Zodra de potentie is vastgesteld, vertaalt de Business Analyst de resultaten naar een Business Case<\/strong>: het document dat inzicht geeft in de investering, de besparing en de terugverdientijd.<\/p>\n\n\n\n

    Voorbeeld Business Case Template<\/strong><\/h4>\n\n\n\n
    Onderdeel<\/strong><\/th>Toelichting<\/strong><\/th>Voorbeeld (Factuurverwerking)<\/strong><\/th><\/tr><\/thead>
    Procesnaam<\/strong><\/td>Naam van het proces<\/td>Inkomende facturen verwerken<\/td><\/tr>
    Huidige doorlooptijd<\/strong><\/td>Totale verwerkingstijd per factuur<\/td>5 dagen<\/td><\/tr>
    Doelstelling<\/strong><\/td>Gewenste verbetering<\/td>2 dagen<\/td><\/tr>
    Gemiddeld aantal transacties per maand<\/strong><\/td>Volume dat wordt verwerkt<\/td>960 facturen<\/td><\/tr>
    Gemiddelde handmatige tijd per transactie<\/strong><\/td>Tijdsduur zonder automatisering<\/td>5 minuten<\/td><\/tr>
    Verwachte besparing (tijd)<\/strong><\/td>(960 \u00d7 5) \u2013 (960 \u00d7 1) minuten<\/td>3.840 minuten p\/m<\/td><\/tr>
    Investeringskosten<\/strong><\/td>Licenties + implementatie<\/td>\u20ac 8.000<\/td><\/tr>
    Terugverdientijd<\/strong><\/td>In maanden<\/td>5,5 maanden<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Het document eindigt met een samenvatting van de niet-financi\u00eble baten<\/strong>, zoals hogere datakwaliteit, betere compliance en hogere medewerkerstevredenheid.<\/p>\n\n\n\n

    \n\n\n\n

    Technische Validatie<\/strong><\/h3>\n\n\n\n

    Parallel aan de businesscase voert de Solution Architect de technische validatie<\/strong> uit.
    Hierin worden de infrastructuur, applicaties en afhankelijkheden beoordeeld om te bepalen of de oplossing daadwerkelijk uitvoerbaar is.<\/p>\n\n\n\n

    Technisch aspect<\/strong><\/th>Wat wordt geverifieerd?<\/strong><\/th>Voorbeeld<\/strong><\/th><\/tr><\/thead>
    Systeemtoegang<\/strong><\/td>Zijn de juiste rechten aanwezig voor test en productie?<\/td>Toegang tot boekhoudsoftware via API.<\/td><\/tr>
    Applicatiestabiliteit<\/strong><\/td>Hoe vaak wijzigen schermen of workflows?<\/td>Factuurverwerkingssoftware wijzigt maandelijks \u2192 hoog risico.<\/td><\/tr>
    Integraties<\/strong><\/td>Zijn er bestaande API\u2019s of koppelingen beschikbaar?<\/td>REST API aanwezig voor inlezen facturen.<\/td><\/tr>
    Omgevingen<\/strong><\/td>Zijn Dev, Test en Prod gescheiden ingericht?<\/td>Testomgeving actief sinds 01-02-2026.<\/td><\/tr>
    Data Security<\/strong><\/td>Worden gegevens conform AVG verwerkt?<\/td>Beveiligde SFTP voor factuurbestanden.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    De resultaten worden samengevat in een Technical Validation Sheet<\/strong>, onderdeel van het Solution Design Document (SDD).<\/p>\n\n\n\n

    \n\n\n\n

    De Pre-analyse<\/strong><\/h3>\n\n\n\n

    De pre-analyse is de informatiefase<\/em> waarin de Business Analyst inzicht opbouwt in het huidige proces (de \u201cAs-Is\u201d).
    Het doel is: feiten verzamelen v\u00f3\u00f3rdat aannames worden gemaakt.<\/p>\n\n\n\n

    Stap 1 \u2013 Informatie verzamelen (Information Capture)<\/strong><\/h4>\n\n\n\n

    De Business Analyst gebruikt een combinatie van technieken:<\/p>\n\n\n\n

      \n
    • Documentanalyse<\/strong> (handleidingen, SOP\u2019s, mails)<\/li>\n\n\n\n
    • Interviewing<\/strong> (met SME\u2019s of proceseigenaren)<\/li>\n\n\n\n
    • Interfaceanalyse<\/strong> (screenshots of navigatie)<\/li>\n\n\n\n
    • Benchmarking<\/strong> (vergelijkbare processen in andere teams)<\/li>\n\n\n\n
    • Task Capture of Task Mining<\/strong> \u2013 automatische registratie van schermhandelingen.<\/li>\n<\/ul>\n\n\n\n
      Voorbeeld uit de praktijk: Vendor Onboarding<\/strong><\/h5>\n\n\n\n
        \n
      1. De SME ontvangt het onboardingformulier via e-mail.<\/li>\n\n\n\n
      2. Controleert of gegevens compleet zijn.<\/li>\n\n\n\n
      3. Controleert in ERP (ACME System 1) of leverancier al bestaat.<\/li>\n\n\n\n
      4. Controleert in CRM (ACME System 3) of klant al bestaat.<\/li>\n\n\n\n
      5. Voegt leverancier toe in ERP.<\/li>\n\n\n\n
      6. Maakt MIS-rapport op en verstuurt naar support.<\/li>\n<\/ol>\n\n\n\n

        De Business Analyst verzamelt hierbij screenshots van relevante schermen, systeembeschrijvingen en tijdsmetingen per stap.<\/p>\n\n\n\n

        \n\n\n\n

        Stap 2 \u2013 Informatie organiseren (Information Organization)<\/strong><\/h3>\n\n\n\n

        Na het verzamelen wordt de data omgezet in modellen<\/strong> die het proces inzichtelijk maken voor alle stakeholders.<\/p>\n\n\n\n

        a. Flowchart (procesoverzicht)<\/strong><\/h4>\n\n\n\n

        Een eenvoudige flow met symbolen voor handelingen, beslissingen en outputs.
        Bijvoorbeeld:<\/p>\n\n\n\n

        Ontvang formulier \u2192 Controleer volledigheid \u2192 \nBestaat in ERP? \u2192 Nee \u2192 Voeg toe \u2192 Maak rapport \u2192 Verstuur naar Support\n<\/code><\/pre>\n\n\n\n
        b. SIPOC-model<\/strong><\/h4>\n\n\n\n
        Een SIPOC geeft overzicht in vijf kernonderdelen van het proces.<\/p>\n\n\n\n
        Supplier<\/strong><\/th>Input<\/strong><\/th>Process<\/strong><\/th>Output<\/strong><\/th>Customer<\/strong><\/th><\/tr><\/thead>
        Leverancier<\/td>Onboardingformulier<\/td>Controle en invoer in ERP<\/td>Voltooide leveranciersregistratie<\/td>Supportteam<\/td><\/tr>
        Supportteam<\/td>MIS-data<\/td>Rapport opstellen<\/td>MIS-rapport<\/td>Management<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Het SIPOC-model helpt om rollen en grenzen te verduidelijken, vooral bij cross-functionele processen.<\/p>\n\n\n\n
        \n\n\n\n
        De rol van de Business Analyst<\/strong><\/h3>\n\n\n\n
        De Business Analyst is in deze fase de brug tussen strategie en techniek<\/strong>.
        Hij\/zij:<\/p>\n\n\n\n
          \n
        • Valideert het proces op geschiktheid voor automatisering;<\/li>\n\n\n\n
        • Bouwt de businesscase op basis van feiten en data;<\/li>\n\n\n\n
        • Werkt met de Solution Architect aan technische haalbaarheid;<\/li>\n\n\n\n
        • Documenteert de As-Is en To-Be processen;<\/li>\n\n\n\n
        • Zorgt dat alle bevindingen worden goedgekeurd door stakeholders.<\/li>\n<\/ul>\n\n\n\n
          In organisaties met beperkte capaciteit kan de Business Analyst tijdelijk ook de rol van procesontwerper of testco\u00f6rdinator vervullen.<\/p>\n\n\n\n
          \n\n\n\n
          Autonomous Tip<\/strong><\/h3>\n\n\n\n
          \n
          Goede Business Analysts beginnen met luisteren, niet met tekenen.
          Elk project dat mislukt, deed dat omdat men aannam te weten hoe het proces liep \u2014 in plaats van het te bewijzen.<\/p>\n<\/blockquote>\n\n\n\n
          \n\n\n\n
          Belangrijkste leerpunten<\/strong><\/h3>\n\n\n\n
            \n
          • De Business Case & Technical Validation<\/strong>-fase bepaalt of een proces geschikt is voor automatisering.<\/li>\n\n\n\n
          • De Business Analyst<\/strong> voert de opportunity assessment uit en bouwt de businesscase.<\/li>\n\n\n\n
          • De Solution Architect<\/strong> beoordeelt technische haalbaarheid en afhankelijkheden.<\/li>\n\n\n\n
          • De Pre-analyse<\/strong> bestaat uit informatie verzamelen (capture) en structureren (organization).<\/li>\n\n\n\n
          • Gebruik Flowcharts<\/strong> of SIPOC-modellen<\/strong> om processen te visualiseren.<\/li>\n\n\n\n
          • Documenteer aannames, beperkingen en risico\u2019s direct in de SoW en trackers.<\/li>\n<\/ul>\n\n\n\n
            Het Process Overview Document<\/strong><\/h2>\n\n\n\n
            De Process Overview<\/em> is het eerste echte overzicht<\/strong> van hoe een proces in de praktijk werkt \u2014 niet zoals men denkt dat het werkt, maar zoals het daadwerkelijk<\/em> verloopt.
            Het vormt de brug tussen de verkennende fase (Business Case & Technical Validation) en de diepgaande Process Analysis<\/em> waarin de \u201cAs-Is\u201d en \u201cTo-Be\u201d processen worden vastgelegd.<\/p>\n\n\n\n
            Waar de businesscase vooral draait om waarde en haalbaarheid<\/strong>, richt dit document zich op feitelijke werking en context<\/strong>: wanneer, hoe vaak, door wie en met welke hulpmiddelen het proces wordt uitgevoerd.<\/p>\n\n\n\n
            \n\n\n\n
            Doel van het Process Overview Document<\/strong><\/h3>\n\n\n\n
            Het Process Overview Document geeft stakeholders een duidelijk beeld van het proceslandschap<\/strong>.
            Het bevat de functionele grenzen, de betrokken partijen en de technische randvoorwaarden.
            Daarmee vormt het een onmisbare basis voor ontwerp, automatisering en kwaliteitsborging.<\/p>\n\n\n\n
            Het document dient drie doelen:<\/p>\n\n\n\n
              \n
            1. Communicatie:<\/strong> een gedeeld referentiepunt voor alle stakeholders.<\/li>\n\n\n\n
            2. Planning:<\/strong> inzicht in doorlooptijden, piekbelasting en benodigde capaciteit.<\/li>\n\n\n\n
            3. Technische voorbereiding:<\/strong> input voor Solution Architects en ontwikkelaars over systemen, data en afhankelijkheden.<\/li>\n<\/ol>\n\n\n\n
              \n\n\n\n
              Wat moet er worden vastgelegd<\/strong><\/h3>\n\n\n\n
              Afhankelijk van de complexiteit van het proces, kan de Business Analyst meerdere walkthroughs nodig hebben om alle details te verzamelen.
              Tijdens deze sessies worden de volgende elementen geregistreerd:<\/p>\n\n\n\n
              Categorie<\/strong><\/th>Beschrijving<\/strong><\/th>Voorbeeld (Vendor Onboarding)<\/strong><\/th><\/tr><\/thead>
              Procesnaam<\/strong><\/td>Naam van het proces<\/td>Leveranciersregistratie (Vendor Onboarding)<\/td><\/tr>
              Proces-ID \/ Referentie<\/strong><\/td>Interne code of nummer<\/td>PROC-ONB-001<\/td><\/tr>
              Procesverantwoordelijke (PO)<\/strong><\/td>Hoofd van het proces<\/td>Maria van Dongen<\/td><\/tr>
              SME \/ Analist<\/strong><\/td>Kennisdrager binnen het proces<\/td>Ahmed Farah<\/td><\/tr>
              Procesopen- en sluitingstijden<\/strong><\/td>Tijdvensters waarin het proces kan worden uitgevoerd<\/td>Ma\u2013Vr: 08:00\u201318:00 uur<\/td><\/tr>
              Beperkingen (restrictions)<\/strong><\/td>Activiteiten die afhankelijk zijn van tijdsvensters<\/td>Nieuwe leveranciers mogen enkel v\u00f3\u00f3r 17:00 uur worden ingevoerd<\/td><\/tr>
              Verwachte volumestijging<\/strong><\/td>Schatting groei in transacties<\/td>+20% per kwartaal<\/td><\/tr>
              Gemiddeld volume per periode<\/strong><\/td>Transacties per maand\/week\/dag<\/td>960 leveranciers per maand<\/td><\/tr>
              Piekmomenten<\/strong><\/td>Perioden met verhoogd volume<\/td>Eind Q2 en Q4 bij contractverlengingen<\/td><\/tr>
              Gemiddelde afhandeltijd (AHT)<\/strong><\/td>Tijd om \u00e9\u00e9n item te verwerken<\/td>6 minuten per leverancier<\/td><\/tr>
              Betrokken afdelingen<\/strong><\/td>Teams die input leveren of output ontvangen<\/td>Finance, Inkoop, Support<\/td><\/tr>
              Stakeholders & rollen<\/strong><\/td>Wie doet wat in het proces<\/td>SME controleert, Finance valideert, Support archiveert<\/td><\/tr>
              Inputgegevens<\/strong><\/td>Welke data start het proces<\/td>Onboardingformulier (PDF), e-mails met bijlagen<\/td><\/tr>
              Outputgegevens<\/strong><\/td>Resultaten van het proces<\/td>Nieuwe leveranciersrecords, MIS-rapport<\/td><\/tr>
              Gebruikte applicaties<\/strong><\/td>Systemen of software die in het proces voorkomen<\/td>ERP (ACME System 1), CRM (ACME System 3), Outlook<\/td><\/tr>
              Virtuele omgeving<\/strong><\/td>Type clientomgeving<\/td>Thin client via RDP<\/td><\/tr>
              Procesfrequentie<\/strong><\/td>Hoe vaak het proces plaatsvindt<\/td>Dagelijks<\/td><\/tr>
              Aantal FTE\u2019s<\/strong><\/td>Huidige menselijke capaciteit<\/td>2,5 FTE<\/td><\/tr>
              Automatiseringskans<\/strong><\/td>Eerste inschatting van haalbaarheid<\/td>Hoog (stabiele input en regels)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              \n\n\n\n
              Thin vs. Thick Client<\/strong><\/h3>\n\n\n\n
              Bij technische voorbereiding is het belangrijk onderscheid te maken tussen:<\/p>\n\n\n\n
                \n
              • Thin Client:<\/strong> processen die draaien op een virtuele desktop<\/em> of remote omgeving<\/em> (bijv. Citrix, RDP). Deze vragen extra configuratie voor robottoegang en schermherkenning.<\/li>\n\n\n\n
              • Thick Client:<\/strong> lokaal ge\u00efnstalleerde applicaties op desktopniveau (zoals Office of boekhoudsoftware). Deze zijn eenvoudiger te automatiseren.<\/li>\n<\/ul>\n\n\n\n
                De Business Analyst noteert het type client per applicatie in het overzicht, zodat de Solution Architect weet welke testomgeving en infrastructuur nodig zijn.<\/p>\n\n\n\n
                \n\n\n\n
                Samenwerking en Validatie<\/strong><\/h3>\n\n\n\n
                De Business Analyst vult het Process Overview Document in samen met<\/strong>:<\/p>\n\n\n\n
                  \n
                • De Solution Architect:<\/strong> om te toetsen of testomgevingen, softwareversies en licenties beschikbaar zijn.<\/li>\n\n\n\n
                • De Infrastructure Engineer:<\/strong> om hardwarevereisten, beveiligingslagen en netwerktoegang te valideren.<\/li>\n<\/ul>\n\n\n\n
                  Veel informatie is al deels vastgelegd tijdens de Kick-offfase<\/strong> (zoals in de Project Readiness Checklist of Access Tracker).
                  Het is daarom cruciaal om bestaande informatie te verifi\u00ebren en actualiseren<\/strong> \u2014 vooral als de Business Analyst pas later in het traject instapt.<\/p>\n\n\n\n
                  \n\n\n\n
                  Voorbeeldtemplate \u2013 Process Overview Document<\/strong><\/h3>\n\n\n\n
                  Hoofdstuk<\/strong><\/th>Invulvelden \/ Beschrijving<\/strong><\/th><\/tr><\/thead>
                  1. Algemeen<\/strong><\/td>Procesnaam, proces-ID, doel, afdeling, eigenaar, SME, frequentie<\/td><\/tr>
                  2. Operationele details<\/strong><\/td>Open- en sluitingstijden, piekuren, beperkingen, tijdsafhankelijkheden<\/td><\/tr>
                  3. Capaciteit & volume<\/strong><\/td>Gemiddeld volume per periode, verwachte stijging, AHT, FTE<\/td><\/tr>
                  4. Data & informatie<\/strong><\/td>Inputtypes, outputtypes, documentformaten, datastructuur<\/td><\/tr>
                  5. Applicaties<\/strong><\/td>Gebruikte applicaties, versies, omgeving (Thin\/Thick), integraties<\/td><\/tr>
                  6. Stakeholders<\/strong><\/td>Namen, rollen, verantwoordelijkheden<\/td><\/tr>
                  7. Technische randvoorwaarden<\/strong><\/td>Netwerkvereisten, testomgevingen, licentiebehoefte<\/td><\/tr>
                  8. Opmerkingen \/ risico\u2019s<\/strong><\/td>Bijzonderheden of onzekerheden (bv. datakwaliteit of compliance)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  Voorbeeld ingevuld fragment<\/strong><\/h3>\n\n\n\n
                  Onderdeel<\/strong><\/th>Waarde \/ Beschrijving<\/strong><\/th><\/tr><\/thead>
                  Procesnaam<\/strong><\/td>Inkomende factuurverwerking<\/td><\/tr>
                  Doel<\/strong><\/td>Het geautomatiseerd herkennen en boeken van inkomende facturen in het financi\u00eble systeem.<\/td><\/tr>
                  Procesfrequentie<\/strong><\/td>Dagelijks<\/td><\/tr>
                  Input<\/strong><\/td>PDF-facturen, e-mails, XML-uploads<\/td><\/tr>
                  Output<\/strong><\/td>Boeking in financieel systeem, bevestigingsmail naar leverancier<\/td><\/tr>
                  Open\/Sluitingstijden<\/strong><\/td>07:00\u201319:00 uur (werktijd van Finance)<\/td><\/tr>
                  Toename volume<\/strong><\/td>+10% per kwartaal<\/td><\/tr>
                  FTE\u2019s betrokken<\/strong><\/td>3 administratief medewerkers<\/td><\/tr>
                  Applicaties<\/strong><\/td>Factuurverwerkingssoftware (Thin Client), Boekhoudsysteem (Thick Client), SharePoint<\/td><\/tr>
                  Piekmomenten<\/strong><\/td>Eerste week van de maand (veel facturen)<\/td><\/tr>
                  AHT<\/strong><\/td>3 minuten per factuur<\/td><\/tr>
                  Virtuele omgeving<\/strong><\/td>1 RDP-server (Citrix) voor factuurherkenning<\/td><\/tr>
                  Automatiseringspotentieel<\/strong><\/td>Hoog \u2013 gestandaardiseerde input en repeterende logica<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  \n\n\n\n
                  Tip<\/strong><\/h3>\n\n\n\n
                  \n
                  Behandel het Process Overview Document als een levend document<\/em>.
                  Veel antwoorden krijg je niet in de eerste week, maar pas tijdens analyses of testfases.
                  Zorg dat versiebeheer wordt toegepast \u2014 elke wijziging moet traceerbaar blijven.<\/p>\n<\/blockquote>\n\n\n\n
                  \n\n\n\n
                  Belangrijkste leerpunten<\/strong><\/h3>\n\n\n\n
                    \n
                  • Het Process Overview Document<\/strong> geeft een helder overzicht van de processtructuur, tijdsafhankelijkheden en betrokken stakeholders.<\/li>\n\n\n\n
                  • Belangrijke onderdelen zijn: open\/close-tijden, transactiegroei, piekbelasting, input\/output en gebruikte applicaties.<\/li>\n\n\n\n
                  • Het document vormt een levende basis<\/strong> die gedurende de procesanalyse wordt verfijnd.<\/li>\n\n\n\n
                  • De Business Analyst werkt hierin nauw samen met de Solution Architect<\/strong> en Infrastructure Engineer<\/strong>.<\/li>\n\n\n\n
                  • Type client (Thin of Thick) en technische randvoorwaarden moeten vroeg worden vastgelegd om automatiseringsrisico\u2019s te beperken.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"
                    De Business Case & Technische Validatie De fase Business Case & Technical Validation is het moment waarop ambitie en realiteit elkaar ontmoeten.Tot nu toe is de basis gelegd: de Statement of Work is ondertekend, de projectgereedheid is getoetst, en de eerste tools zoals de Access Tracker en Issue Tracker zijn ingericht.Maar de vraag die nu […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"class_list":["post-342","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=342"}],"version-history":[{"count":3,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/342\/revisions"}],"predecessor-version":[{"id":345,"href":"https:\/\/bjornproost.nl\/index.php?rest_route=\/wp\/v2\/pages\/342\/revisions\/345"}],"wp:attachment":[{"href":"https:\/\/bjornproost.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}