Tag Archives: InformatieProduct

Proces en InformatieProduct

De vorige post vermeldde InformatieProducten op operationeel niveau. Oftewel de informatie die nodig is om je werk te kunnen doen. Wat voor werk dat precies is, laat zich beschrijven als een proces waarin stappen in serie worden uitgevoerd. Daarom zijn procesomschrijvingen altijd een waardevolle onderlegger voor de articulatie van de informatiebehoefte. Als ik wil duiden welke operationele informatie precies nodig is, dan pak ik ze er vaak bij. Dit veronderstelt overigens wel een AO die zijn topische vragen beantwoord heeft.

Visueel zijn InformatieProducten snel terug te vinden in workflow diagrammen. Het zijn de pijlen! Omdat informatie zich dan verplaatst van de ene processtap (waarin iemand met Rol A informatie creëert) en de andere processtap (waarin iemand met rol B informatie ontvangt). Het kan echter ook een technische koppeling zijn tussen 2 systemen die informatie automatisch genereren, verzenden, ontvangen en verwerken.

Vereenvoudigt weergegeven:

 

Het bouwen van een InformatiePortfolio

Vaak bevind ik mij tussen personen die informatie nodig hebben aan de ene kant en die het leveren aan de andere kant. Opzich ligt zo’n brugfunctie mij wel. Tot voor kort hield ik zelf overzicht over de informatiebehoefte en -levering, door lijsten aan te leggen in excel. Hierop kwamen dan de namen van de rapportages, formulieren, data-exports en monitoren. Gedurende een vorig project werd duidelijk dat dat niet meer voldoende is. Dus ben ik een database gaan aanleggen. Het geheel noemen we het InformatiePortfolio (en ja, ik vind CamelCase leuk).

Ik hanteer daarbij de volgende omschrijving:

Het geheel van InformatieProducten die gevraagd of geleverd worden waarbij telkens relaties worden gelegd met kernsystemen, leveranciers, stakeholders, kaders, rollen, definities, publicatiedatums, processen en KPI’s. Aan elk InformatieProduct worden kenmerken toegekend zoals een code, naam, omschrijving, doel, niveau, status en frequentie. 

De basis van dit portfolio is dus een lijst met InformatieProducten. Door bovengenoemde relaties te leggen kan het portfolio het volgende leveren:

  • Productkaarten: Per InformatieProduct een overzicht van alle kenmerken, definities, systemen en leverancier.
  • InformatieKalender: Wat wordt wanneer geleverd?
  • KPI-Register: Welke prestatie-indicatoren zijn er en welke InformatieProducten zijn hiervoor de onderlegger?
  • Overige rapportages: bijvoorbeeld welke afdeling is verantwoordelijk voor welke informatie of welke informatie komt uit welk systeem?

Het aantal items in het portfolio groeit erg snel. Dat vind ik niet erg, zolang ik maar overzicht kan creëren. In een later stadium kan dan weer kritisch gekeken worden welke informatie niet meer nodig is.