Services

Als je op Internet zoekt naar de term Rapport is het aantal hits overweldigend. Wat wij bedoelen is de uitvoer van data, vaak in een bepaald formaat. Dit kan bijvoorbeeld een lijst zijn of een brief.
De meest gangbare formaten zijn Word, Excel, PowerPoint, PDF en meer technische formaten als CSV en XML.

Veel voorkomende rapporten zijn bijvoorbeeld Offertes, Draaiboeken, Evaluatieformulieren, Catering uitvragen en Contracten.

In de software zijn diverse Standaardrapporten beschikbaar en er is een API Feed waarmee je data kunt benaderen in bijvoorbeeld Excel of je BI tool. Vaak zijn er ook maatwerkrapporten, dit zijn rapporten die wij op maat maken specifiek voor jullie.

Er zijn veel maatwerkrapporten ontwikkeld en het is verstandig om met andere gebruikers te spreken om te zien of er rapporten zijn die jij ook kunt gebruiken in je organisatie. Ook kun je ons vragen naar voorbeelden. Wij kunnen deze niet altijd laten zien omdat hiervoor toestemming moet zijn van de gebruikers die het rapport hebben laten ontwikkelen.

Gebruikers vragen bijvoorbeeld naar een weeklijst, een draaiboek of een contract.
Wat ze dan precies bedoelen moet bepaald worden. In elk geval is er een rapportwens. Vaak hebben gebruikers een specifiek idee over de lay-out en de content. Als de standaardrapporten niet voldoen kan er een maatwerkrapport gemaakt worden.

Maar hoe breng je nu in kaart wat de wens echt is?

Dit vergt vaak tijd want een gebruiker geeft je waarschijnlijk wel wat voorbeelden, maar geen details.

Als je in kaart hebt wat de gebruiker wil, kun je een nieuw rapport aanvragen. Uiteraard moet hiervoor een budget zijn maar allereerst moet je weten hoe je een rapport aanvraagt.

Als je een nieuw rapport aanvraagt is het precies alsof je iets nieuws gaat kopen. Het rapport hangt natuurlijk niet in het rek en ligt ook niet op de plank dus je zult ons moeten vertellen wat het rapport moet doen. <ik wil een rode auto komt ongeveer overeen met ik wil een draaiboek>

De wens moet omgezet worden in een specificatie. Een maatwerkrapport is een project.

De aanvraag kan via Teams, Zendesk, mail of bel even en overleg erover. Er is een projectleider of assistent projectleider bij ESB nodig om dit nieuwe rapport te beoordelen en hiervoor een Rapport PID te maken en de specificatie te beoordelen. De projectleider neemt de opdracht aan en gaat er mee aan de slag. Maar allereerst moet er dus een specificatie zijn.

Heel in het kort is een specificatie een beschrijving van wat het rapport onder welke condities moet doen. Dat klinkt eenvoudig maar in de praktijk kun dit je van een gebruiker niet verwachten. Dit is vaak het werk van de applicatiebeheerder of van een consultant. Het is immers maatwerk.

Enkele belangrijke punten die minimaal terug moeten komen in de specificatie zijn:

a. De naamgeving
Zorg ervoor dat het rapport een naam heeft.  De naam moet niet te lang zijn en zeker ook niet te persoonlijk dus niet “Weeklijst voor Pietje” maar wel bijvoorbeeld “Weeklijst afdeling Techniek”

 b. Go live
Wanneer moet het rapport operationeel zijn?

 c. Testen
Wat zijn de testscenario’s?  Wie gaat het rapport testen?  Wat is de start en einddatum van het testproces? Zijn er testevents aanwezig of wie maakt deze aan?

 d. Aanvrager
Wie vraagt het rapport aan – welke afdeling? Is de Specificatie akkoord bevonden door de aanvrager?

Wie gaat het rapport accorderen? Wie gaat het rapport gebruiken?

e. Beschrijving
Wat moet het rapport onder welke condities gaan doen? Een korte volledige beschrijving is nodig.

f. Formaat
In welk formaat moet de uitvoer beschikbaar zijn? Is er een voorbeeld van de gewenste uitvoer?

Is in dit voorbeeld precies vastgelegd ook welke data waar vandaan moet komen?

Is het Rapport in meerdere talen nodig, zo ja welke? Zijn er logo’s of plaatjes of een bepaald lettertype?

g. Frequentie
Hoe vaak wordt het rapport gebruikt?

Moet het rapport automatisch gemaild worden?  En zo ja naar wie en wanneer?

Een rapport geeft al gauw uitvoer maar het is belangrijk dat het maatwerkrapport goed getest wordt met jouw data. Een weeklijst kan prima uitvoer leveren bijvoorbeeld maar als er in een bepaalde week geen events zijn, wat moet het rapport dan printen? Of als je een bepaald veld wilt printen in een brief maar dat veld is niet ingevuld, wat dan?  In de specificatie heb je dit opgenomen maar in het testscenario moet dit wel terugkomen zodat je kunt testen of het onder al deze condities ook nog een goed rapport produceert.

In de specificatie geef je door welke testscenario’s je gemaakt hebt.

Nadat de projectleider de specificatie gezien heeft wordt deze voorgelegd en besproken met het reporting team. Als er nog vragen zijn dan nemen we contact op met de aanvrager en wordt de specificatie bijgewerkt waar nodig.

De ontwikkeling start als de specificatie duidelijk is. Tijdens het ontwikkelen kunnen er toch nog vragen ontstaan, misschien omdat er een technisch probleem is of er toch nog iets is waar geen rekening mee gehouden is bij het maken van de specificatie.

Als er veel vragen zijn dan kan dit de opleverdatum in gevaar brengen maar ook de tester van het rapport zal dan geïnformeerd moeten worden want ook het testproces vertraagd. Ook dan wordt er weer overlegd.

Gemiddeld duurt het ontwikkelen van een rapport 1 dag. Daarna test de reporting afdeling of het rapport geen fouten oplevert, de juiste uitvoer heeft en draagt het daarna over aan de projectleider.

Als het rapport klaar is wordt het beschikbaar gemaakt in de omgeving waarin getest kan worden.
De reporting afdeling enkele tests uit aan de hand van het testscenario.

Als alles volgens plan verloopt kan de tester aan de slag.

Tip: zorg ervoor dat de tester voldoende rechten heeft om het rapport te mogen testen.

Het testscenario wordt doorlopen en de bevindingen worden gerapporteerd aan de Projectleider.

Ervaring leert dat gebruikers soms toch nog iets anders willen. Het is dan zaak een andere procedure te volgen, de RFC (request for change) procedure. Kleine wijzigingen zijn vaak mogelijk maar het is belangrijk dat de specificatie bijgewerkt wordt op dat moment.

Als er fouten zijn bekijken we met de reporting afdeling hoe deze op te lossen en volgt er een versie waarin deze fouten opgelost zijn. Dit kan een iteratief proces zijn en moet gebeuren in de tijd die afgesproken is voor het testproces in de specificatie. Vaak is dit 2 weken. De reporting afdeling is in deze 2 weken gepland om fouten op te lossen. De planning hiervoor wordt door de projectleider bepaald.

De projectleider stuurt bij als dit proces te lang duurt. Nadat de tester akkoord is, is het belangrijk dat de gebruiker, indien deze niet al betrokken was, ook meekijkt. Dit kan ook per organisatie verschillen. Belangrijk is dat de gebruiker geïnformeerd wordt.

Het is belangrijk dat er documentatie is over het rapport en dat deze beheerd wordt.
De specificatie met de testscenario’s en de beschrijving worden beheerd door de klant, de technische info beheren we in Confluence, het systeem waarmee de reporting afdeling rapporten beheert.

Documentatie is belangrijk omdat er wellicht later nog eens vragen zijn over het rapport en of wijzigingen nodig zijn. Zonder documentatie is dit niet efficiënt.

Het accorderen van het rapport is belangrijk. De voorgaande fasen worden daarmee afgesloten.

Als het rapport goedgekeurd is kan het in gebruik genomen worden. Het is een go live.

Tip: vergeet niet de gebruikers te briefen over het feit dat het rapport in gebruik genomen kan worden, eventueel nog uitleg te geven en de rechten in te stellen zodat zij het rapport ook echt kunnen gebruiken.

De garantietermijn voor het rapport is 14 dagen. Mochten er nog fouten zijn of heel kleine wijzigingen nodig zijn dan lossen we deze op in deze termijn.

Na een tijdje blijkt dat er toch wat wijzigingen nodig zijn in het geleverde rapport. Dat kan natuurlijk.

Iedere wijziging verloopt via een RFC, een Request for Change.

De werkwijze is als volgt:

• De specificatie wordt uitgebreid met een wijziging.
• Deze wordt beschreven.
• De wijziging wordt doorgaans weer met de projectleider besproken en de impact wordt bepaald.

Deze procedure heeft ook weer een tester, testscenario, go live datum etc. net als bij de oorspronkelijke aanvraag. De route is gelijk aan die van de aanvraag.

Definitie wat is een koppeling?
Wat verstaan we onder een “koppeling”? In het kort is dit een relatie die gelegd is met een andere applicatie of met externe data of een Service waarbij data uitgewisseld wordt.

Waarom een koppeling?
Redenen om te koppelen zijn o.a.  het opheffen van redundantie, het valideren van data of het doorsluizen of ophalen van (andere) data uit andere systemen.

Technische info over koppelingen
Een koppeling kan gemaakt worden met een API (REST,  SOAP, XML, JSON etc.) of indien er geen API is door uitwisseling van bijvoorbeeld CSV bestanden. We gaan in dit document verder niet in op de techniek.

Standaarden versus op maat ontwikkelde koppelingen
Sommige koppelingen zijn koppelingen die er gewoon moeten zijn: Als je op een e-mail adres klikt in de CRM dan verwacht de gebruiker dat zijn standaard mailprogramma opent, idem voor een hyperlink als je erop klikt opent je browser. Of als je op een adres klikt en Google maps opent!

Andere koppelingen zijn koppelingen waarbij een keuze gemaakt wordt voor een bepaalde leverancier waar je vaak ook abonnement nodig hebt : adresvalidatie waarbij je bijvoorbeeld postcode en huisnummer invoert en de adresvalidatie service een straat en stad ophaalt. Deze koppeling wordt vaak gerealiseerd met een Webservice. Het kan zijn dat een leverancier meerdere koppelingen kan maken voor dezelfde toepassing. (er zijn meerdere adresdata-bibliotheken beschikbaar bijvoorbeeld).

Dan zijn er de koppelingen die op maat gemaakt worden, soms voor 1 klant, maar dikwijls voor meerdere klanten. Denk hierbij aan koppelingen met kaartverkoopsystemen en financiële systemen.

In onze sector zien wij vrijwel overal de volgende systemen waarmee we mogelijk kunnen koppelen:

Eventplanningsysteem
Ticketingsysteem
Horecasysteem
Financiële Administratie
Fondsenwervingsysteem
Gebouwenbeheersysteem
Personeelsplanningsysteem
Centraal CRM systeem
Website/CMS
Mailings/ campagnesysteem
E-mailsysteem
Rapportagesysteem
Filmdatabanken
Betaalsystemen

Vanuit het planningsysteem events uploaden naar het ticketingsysteem.
Voordeel is dat het event maar 1 keer ingevoerd wordt.

Vanuit het kaartverkoopsysteem kaartverkoopstanden ophalen.
Voordeel is dat de standen in de planningsoftware gevisualiseerd kunnen worden en dat er rapporten mee gemaakt kunnen worden, bijvoorbeeld een borderel.

Voorbeelden van deze koppelingen zijn gerealiseerd met SRO, TicketMatic, TicketMaster, Tix, Itix, LVP, Active Tickets.

Vanuit het planningsysteem CRM data en cijfers over zaalhuur en items uploaden.
Vanuit het planningsysteem CRM data en abonnement-data uploaden.
Vanuit het financiële systeem betaalinformatie terug ontvangen.

Voorbeelden van deze koppelingen zijn gerealiseerd met AFAS, Exact, Minox, Decade, AccountView.

Vanuit planningssoftware CRM data en event data (datum, tijd, naam, klant) uploaden.
Vanuit het horecasysteem een totaalpost terugontvangen.
Vaak kan men deze koppeling zelf realiseren middels een geplande taak in de planningssoftware waarbij een xml of een CSV beschikbaar gemaakt wordt. API koppelingen zijn mogelijk waar nodig.

Wordt aan gewerkt…

Vrijwel alle klanten hebben een website waar event info gepubliceerd wordt. Deze info zit vaak ook in het planningssysteem. Hiervoor worden vaak XML koppelingen aangeboden zodat de data maar 1 keer ingevoerd hoeft te worden. In de praktijk is dit vaak een op maat oplossing en sterk afhankelijk van de wensen van de klant en de kunde van de webbouwers.

Er zijn API’s ontwikkeld waarmee iStaff data opgehaald kan worden voor bijvoorbeeld mobile toepassingen of CMS.

SEPA

Het is mogelijk om een SEPA file te genereren voor abonnementen of lidmaatschappen die men verkoopt aan mensen of bedrijven in de CRM database, en deze automatisch te mailen naar de administratie voor verdere verwerking.