Een bedrijfsanalist inhuren

Wat doet een bedrijfsanalist?

Een bedrijfsanalist vertaalt wat u bedoelt naar een omschrijving waarmee iemand het kan bouwen. Wat u koopt is dus geen advies maar een functioneel ontwerp: het document waarin staat wat het moet doen, voor wie, en wat er bewust niet in komt. Dat document bepaalt de rest van het project.

Het werk begint met doorvragen, en dat is minder vanzelfsprekend dan het klinkt. Bijna niemand beschrijft een oplossing; mensen beschrijven last. “Het offreren duurt te lang” is een klacht. Wat eronder zit — dat drie mensen de korting elk anders bepalen, dat de prijslijst op twee plekken staat, dat niemand ziet of een offerte al is opgevolgd — komt er pas uit als iemand ernaar vraagt op de plek waar het gebeurt.

Wat levert hij op?

Een functioneel ontwerp, en daar hoort meer in te staan dan de meeste mensen krijgen.

Een goed ontwerp beschrijft wat het systeem doet, niet hoe het technisch werkt. U moet het kunnen lezen zonder programmeur te zijn, en u moet er ja of nee tegen kunnen zeggen. Concreet hoort er in te staan:

• Wie het gebruikt, en wat elk van die mensen moet kunnen zien en doen
• Welke stappen er zijn, in welke volgorde, en wat er gebeurt als iemand halverwege stopt
• Welke gegevens erin gaan en eruit komen, en waar die vandaan komen
• Wat er gebeurt als het misgaat — een dubbele invoer, een ontbrekend veld, iemand die twee keer op verzenden drukt
• De uitzonderingen, oftewel de gevallen die uw bedrijf eigen zijn en die in geen enkel pakket zitten
• Wat er niet in komt, met de reden erbij

Die laatste twee zijn waar het meestal misgaat. De uitzonderingen worden vergeten omdat niemand ze opschrijft, en het niet-doen-lijstje ontbreekt omdat het ongezellig staat. Beide komen later terug als meerwerk.

Waarin verschilt hij van een consultant of een projectleider?

In wat er aan het eind op tafel ligt.

Een consultant levert een advies: wat u zou moeten doen en waarom. Waardevol als u nog niet weet welke kant u op wilt, maar er ligt daarna nog geen omschrijving waar iemand mee kan bouwen.

Een projectleider bewaakt of het loopt: planning, budget, wie waarop wacht. Onmisbaar bij een groot traject, maar hij bepaalt niet wat er in het systeem hoort.

Een ontwikkelaar bouwt wat er is beschreven. Is de beschrijving half, dan bouwt hij netjes het verkeerde — en hij merkt het niet, want hij dacht dat hij het begreep.

De bedrijfsanalist zit precies in het gat daartussen: hij is de enige die er verantwoordelijk voor is dat het opgeschreven probleem hetzelfde probleem is als het echte.

Waarom is de overdracht de duurste stap?

Omdat er bij elke overdracht begrip verdwijnt, en juist het begrip was waarvoor u betaalde.

De gangbare gang van zaken is dat de analist analyseert, een document oplevert en vertrekt. Daarna gaat dat document naar een bouwer die er niet bij was toen het gesprek werd gevoerd. Wat die bouwer leest, is wat er staat. Wat hij mist, is alles wat de analist wél weet maar niet heeft opgeschreven — en dat is altijd meer dan iemand denkt.

Bij een klein bedrijf loopt dat op twee manieren mis. Of de bouwer vult zelf in wat er ontbreekt, en dan wijkt het af zonder dat iemand het merkt tot het er staat. Of hij vraagt alles na, en dan betaalt u het uitzoekwerk twee keer.

Daarom houden wij die twee rollen bij dezelfde mensen. Wie uw probleem uitpluist is degene die het daarna bouwt, dus er hoeft niets overgedragen te worden. Dat is ook wat er internationaal met een andere naam wordt aangeduid; dat staat op de internationale naam voor dit vak.

Heet dit ook business analist?

Ja, en de termen worden door elkaar gebruikt zonder dat er een harde grens is.

In de praktijk komt u *bedrijfsanalist*, *business analist*, *functioneel ontwerper*, *informatieanalist* en *business analyst* tegen, en soms wordt er precies hetzelfde mee bedoeld. Waar er onderscheid wordt gemaakt, ligt dat meestal hier: een business analist kijkt breder naar het proces en de organisatie, een functioneel ontwerper werkt dichter op het systeem en schrijft de schermen en velden uit.

Voor een mkb-bedrijf is dat onderscheid vooral academisch. U heeft één iemand nodig die beide doet en die daarna niet verdwijnt.

Wanneer heeft u er een nodig?

Als u weet dát het beter kan maar niet precies wát er moet komen. Dat is de situatie waar dit vak voor bestaat.

U heeft er geen nodig als u het al scherp heeft. Weet u precies welk scherm er moet komen en wat erop staat, koop dan een afgebakende bouwopdracht — dat is goedkoper.

En u heeft er geen nodig als een bestaand pakket het gewoon kan. Die afweging staat op maatwerk of een standaardpakket.

Wél verstandig is het als er meerdere afdelingen bij betrokken zijn en ze het onderling niet eens zijn over hoe iets hoort te lopen. Dan is het opschrijven zelf al de helft van de opbrengst, los van wat er daarna gebouwd wordt.

Hoe pakken wij het aan?

Wij beginnen op de werkvloer en niet aan een vergadertafel, want de mensen die weten waar het vastloopt zitten zelden in de vergadering. Daarna leggen wij het vast in gewone taal, u leest het na, en pas als u zegt dat het klopt gaan wij bouwen. Dat is hoe wij beginnen.

Twee dingen die wij daarbij standaard doen en die u elders moet uitvragen. We schrijven op wat er níét gebouwd wordt, zodat u weet waar de grens ligt. En we betrekken de mensen die ermee moeten werken bij het ontwerp, want een systeem dat naast hun werk komt te staan wordt bij de eerste drukte losgelaten — daar gaat uw mensen meekrijgen over.

Wilt u weten of uw vraag hiervoor in aanmerking komt? Bel 036 52 98 447 of mail info@cloudzicht.nl. Wat er daarna gebouwd wordt, staat bij software laten maken; de vormen waarin u dit kunt inkopen staan op de drie manieren om dit te regelen.