Hoog tijd voor revival informatiearchitectuur

Hoog tijd voor revival informatiearchitectuur
In veel opzichten spelen gegevens en informatie een rol die onafhankelijk van IT-systemen en andere technische voorzieningen kunnen worden onderzocht en bepaald. Een pleidooi voor extra aandacht voor een geïntegreerde informatiearchitectuur.
Jan Campschroer en Jan Truijens
Op een huizenwebsite staat een fotootje van een huis, een aantrekkelijk huis. Potentiële kopers willen nu van alles weten. Zijn er voldoende kamers? Is er ruimte rondom? Zijn er scholen in de buurt? Is de tuin te behappen? En: kunnen we dit betalen, moet de bank meehelpen? Hoe hoog is het te verzekeren risico van dat rieten dak? Wat is de staat van die nostalgische dakbedekking en die dakconstructie? Kunnen er straks nog zonnepanelen op? Veiligheidsexperts kunnen het hang- en sluitwerk en de inbraakgevoeligheid beoordelen, makelaars de waarde taxeren (met inachtneming van laan, buurt en dorp), architecten kunnen beoordelen of vergroting en herindeling mogelijk is. En de gemeente kan via het bestemmingsplan vertellen of uitbouw mogelijk is. Het gaat steeds om hetzelfde huis, maar afhankelijk van rol, deskundigheid en verantwoordelijkheden van de betrokkene zijn andere kenmerken van belang en andere omgevingsfactoren bepalend. Zou die inbreker die zich oriënteert op zijn volgende klus trouwens óók van die huizensite gebruik maken? De moraal van dit verhaal? Informatie gaat niet (alleen) over IT. Wat je aan gegevens beschikbaar stelt, levert heel verschillende doelgroepen (ook onverwachte) heel verschillende informatie. En informatie haal je tegenwoordig uit een mix van gestructureerde, ongestructureerde en geogegevens. Zuurstof van de organisatie ‘Informatie is de vierde productiefactor.’ ‘Informatiesystemen zijn onze navelstreng.’ ‘Informatie is de zuurstof van een organisatie.’ Als het over informatie gaat, dan blazen mensen al snel hoog van de toren. Zonder informatie gaat het blijkbaar niet. Er zijn allerlei soorten informatie en ook allerlei verschijningsvormen: informatie over opbrengst en resultaat van processen, over de voortgang, over de (uitvoerings-) kwaliteit, informatie over klanten, producten, receptuur, verantwoordingsregels... Een taxonomie van informatiesoorten kan behoorlijk uitgebreid worden. Goed meten, vastleggen, informeren en afstemmen zijn belangrijke voorwaarden om succesvol te zijn. Als een potentiële klant jouw bedrijf als eerste vindt en je hem (of haar) in de vervolgdialoog kunt helpen met een passend product of een passende dienst, dan is dat natuurlijk goed. Als je vervolgens ook nog bij de levering en het gebruik van dat product of die dienst ondersteuning op maat kunt bieden, dan komt die klant ook weer terug. En dat is natuurlijk nog beter.
Voor een wederzijds profijtelijke relatie moet je echter je klanten begrijpen en informatie hebben over hun vraag, hun behoefte. Wil je dat ook nog eens kosteneffectief en efficiënt doen, dan moeten de productieprocessen goed verlopen. De medewerkers moeten weten wat ze moeten doen en de leveranciers moeten weten wat ze moeten leveren. Als er fouten optreden moet je die snel kunnen localiseren en oplossen.
Om succesvol te zijn, zetten organisaties vaak IT in en worden allerlei voorzieningen in het leven geroepen, zoals internet, websites, social media, administraties, procesautomatisering, workflow... En nog gaat het dan soms mis. Want die IT-systemen zijn gebrekkig gekoppeld, hebben verschillende komaf en werken volgens verschillende principes. Bovendien begrijpen de mensen die ermee moeten werken en degenen die ze moeten realiseren en onderhouden elkaar vaak slecht. De betrokken informatie blijkt vaak niet eenduidig, de behandelingsprocessen wijken af van wat wordt gewenst en de kwaliteit van de resultaten laat te wensen over. Met IT proberen we grip te krijgen op gegevens, informatie en communicatie. Maar uiteindelijk kost het ons heel veel moeite om die IT ‘goed te krijgen’ en verliezen we het doel ‘adequate informatie’ uit het oog. Blijkbaar is IT een onwillige ezel in plaats van een gedreven renpaard. Wat nu?
In onze visie moet je ‘informatie in en om het bedrijf’ zelfstandig aandacht geven. Maar let op! Het informatie-aspect is wel te onderscheiden, maar niet te scheiden in het vormgeven van organisaties, processen, administraties en IT-voorzieningen! De informatie-architectuurbeschrijvingen zijn dan ook views vanuit een informatieviewpoint op het geheel. Informatieprocessen vormen samen – in tegenstelling tot IT-systemen – geen subsysteem van je organisatie die je apart kunt ontwerpen en realiseren. Zie het als het klimaatbeheersysteem in een huis: dat kun je niet los ontwerpen van dat huis. Minstens zo belangrijk als de verwarmingsketel, de buizen en de airco zijn de plek waar het huis staat en het materiaal waarmee het huis, de ruimtes en de verbindingen zijn gebouwd. Je kunt hier zicht op krijgen, los van hoe het precies is ingericht. Dat is lastig, maar levert wel wat op: een kader waaraan je integrale oplossingen (organisatieinrichtingen) kunt toetsen op hun bruikbaarheid voor de organisatie.
In dit artikel stellen we enkele fundamentele vragen over informatie en over de informatiehuishouding, bepleiten we herwaardering van de informatiearchitectuur en trachten we eenvoudige en bruikbare aanwijzingen en tips te geven.
Aftrap en begripsbepaling
Wij denken dat informatiearchitectuur een bijdrage kan leveren bij het honoreren van de informatievragen. We definiëren de term informatiearchitectuur als volgt: ‘De informatiearchitectuur benoemt zowel de relevante informatie als de opzet en de inrichting van de processen die ervoor moeten zorgen dat betrokken partijen de informatie krijgen die nodig is om de organisatie optimaal te laten presteren.’
De verlangde informatie krijgen de partijen voor een groot gedeelte met behulp van IT-systemen, maar de werkelijkheid waarin zij opereren draagt er natuurlijk ook aan bij. Als je bijvoorbeeld wilt weten hoe groot de tevredenheid van je personeel is, dan kun je een rapport opvragen, maar je kunt ook de werkvloer oplopen en het gewoon aan een aantal mensen vragen of je licht opsteken bij een aantal managers. Informatie is de toename aan relevante kennis.
Informatie is het cognitieve effect dat bijvoorbeeld een rapport, een dashboard, een analyse, een praatje of een waarneming heeft op een mens, die daarmee of daardoor vervolgens effectiever of efficiënter kan handelen. IT-systemen (hardware en software) maken het mogelijk om onze kennis over de wereld vast leggen in gestructureerde en ongestructureerde gegevens. Met behulp van IT-systemen maken we van die gegevens informatieproducten. Producten die – mits op het juiste moment, met de juiste inhoud en in de juist vorm – ervoor zorgen dat mensen de informatie krijgen die ze nodig hebben. IT-systemen vormen daarmee een belangrijke component in de processen die ervoor zorgen dat we de informatie krijgen die we nodig hebben. Maar het is duidelijk dat je daarnaast andere zaken – waaronder gegevens én mensen – nodig hebt om de informatieproducten te leveren. En uiteindlijk is het de mens die daar voor hem of haar informatie van maakt. In ons beeld van informatiearchitectuur krijgen al deze onderdelen een plaats. Helaas eisen IT-systemen de meeste managementaandacht op. Om de diverse informatieverwerkende activiteiten en de steeds wisselende informatiebehoeften op waarde te kunnen schatten en te kunnen blijven honoreren, is een architectuuraanpak te verkiezen. Ons pleidooi hiervoor vervatten we in drie vuistregels:
Vuistregel 1 Er zijn geen ‘quick wins’ meer, schep dus de juiste voorwaarden
IT-projecten hebben een slechte naam: ze falen nogal eens1,2,3. Bovendien geldt dat hoe groter het project, hoe groter de kans op falen. Nu zijn er allerlei methoden bedacht om projecten te laten slagen: bijvoorbeeld Prince2, MSP, portfoliomanagement (op het gebied van sturing) en Waterval, Agile en Scrum (op het gebied van ontwerp en bouw). Tot nu toe hebben deze methoden niet echt geholpen. Misschien wordt het tijd voor een fundamenteel andere aanpak? Een andere visie? Zou het niet mooi zin als we een situatie creëren waarin er geen (IT-) projecten meer nodig zijn, of in ieder geval geen gróte projecten? Hoe zou de informatievoorziening eruit moeten zien als iedereen zélf zou kunnen voorzien in zijn of haar informatie? Kunnen we een situatie creëren vergelijkbaar met energie, water of vervoer, waarbij iedereen zelfvoorzienend is?
De aanpak die wij willen voorstellen, is een infrastructurele. Daarbij zorg je er niet meer voor dat de diverse partijen worden voorzien in hun specifieke behoeften, maar creëer je zoveel mogelijk breed te gebruiken nutsvoorzieningen, die ervoor zorgen dat (eventuele) projecten die ervoor moeten zorgen dat de juiste informatieprocessen gaan werken, veel kleiner en dus veel succesvoller zijn. Dat gaat niet vanzelf en er is ook geen methode voor. Maar waar een wil is, is een weg. Daarbij moet wel het volgende in ogenschouw worden genomen:
• Een keuze voor het realiseren van een informatie-infrastructuur (IIS) is een strategische. Ten eerste omdat je zoiets niet van vandaag op morgen voor elkaar krijgt; je hebt er een lange adem voor nodig. Ten tweede omdat je zo’n infrastructuur niet alleen voor je eigen bedrijf maakt. Communicatie en informatie stoppen niet bij de organisatiegrenzen. Het realiseren van een IIS kan daarom alleen als de CEO door heeft wat het inhoudt en ervan overtuigd is dat het een haalbare en gewenste ambitie is. Overtuigen kan niet op basis van een business case, overtuigen moet op andere gronden gebeuren.
• Een keuze voor het realiseren van een informatie-infrastructuur is een keuze die de organisatie, de processen, de administraties én de IT raakt. Het is geen ‘IT-keuze’. Het gaat erom te beseffen dat informatieprocessen en de veranderingen daarin anders gaan werken. Het realiseren van een IIS moet een principe zijn in de businessarchitectuur.
• Het betreft een paradigmaverschuiving die niet makkelijk te maken is voor iedereen. Het is voor sommigen bovendien een aantasting van hun verdienmodel, sommigen kicken op grote projecten. Als zo’n project dan eens een keer lukt, dan is dat natuurlijk een mooie trofee op je CV; en het is natuurlijk niet leuk als dat verdwijnt. Sommigen kunnen niet zonder de kick van de roulettetafel.
• Het creëren van infrastructuur kun je aanpakken als een megaprogramma, met de kans op een megamislukking. Wat meer voor de hand lijkt te liggen, is een weg op basis van grote lijnen, bestemmingsplanachtige architecturen, van (beleids)richtlijn, van (kleine) bijsturing op projecten en ‘oogsten’ van infrastructurele componenten. Je moet dus wel echt sturen naar zo’n vorm van informatievoorziening.
Vuistregel 2: Wees kostenbewust; informatie heeft een waarde en een kostprijs
‘Wat kost een druppel benzine? Niets? O, druppel dan mijn tank maar vol!’ Het lijkt wel of een soortgelijke redenering ook voor gegevens wordt gehanteerd. Administreren kost toch niets, waarom zou ik dan voor informatieproducten moeten betalen? Wat kost trouwens een verkeerde beslissing op basis van onjuiste gegevens? Om informatie te leveren (of eigenlijk: te laten ontstaan bij de gebruiker van informatieproducten) zijn behalve IT – de hardware en de software – ook gegevens (ofwel content) nodig. Dat weten we allemaal. Dus is het vreemd dat er bij projecten die de informatievoorziening moeten verbeteren alleen aandacht is voor de IT. En dan te bedenken dat als er een laptop op straat gevonden wordt niemand zich zorgen maakt over de hardware en software, maar iedereen zich zorgen maakt over de gegevens die erop staan! Dat maakt duidelijk dat gegevens waarde hebben. Soms alleen voor het bedrijf, zoals in het geval van de facturen, soms ook voor de omgeving, zoals de offerteportefeuille. Wat in ieder geval zeker is: als de gegevens verloren of corrupt (dus: foutief) raken, worden de bedrijfsresultaten slechter. Toch krijgen gegevens maar weinig managementaandacht. Hoe komt dat? Mogelijk omdat het verkrijgen van gegevens ‘niks’ kost. Mogelijk omdat in geen enkele managementrapportage zichtbaar wordt welke kosten voor die rapportage zijn gemaakt. Maar mischien ook omdat geen enkele manager erop wordt aangesproken en omdat het op orde houden van de gegevenshuishouding ten behoeve van gegevensbeschikbaarheid en rapportagemogelijkheden nooit wordt verbijzonderd. Inderdaad, een spreadsheet is vaak zó gemaakt, maar kan een stevige kostprijs hebben door het gebruik van (daartoe) beschikbaar gehouden gegevens.
Gegevens zijn nodig voor operationele processen, niet alleen als input maar ook ter managementondersteuning. Zo zijn klantgegevens nodig om bestellingen te kunnen bezorgen en af te rekenen, maar zijn ook (proces-) gegevens nodig om de efficiëntie van de betreffende processen vast te kunnen stellen. De met afname-informatie verrijkte klantgegevens kunnen vervolgens input zijn voor markt- en productanalyses. Zo duiken dezelfde gegevens in verschillende processen op en vertegenwoordigen ze een veelvoud aan waarde – waarde die dus groeit mét het gebruik.
• Regelmatig wordt geroepen dat gegevens ‘het vierde productiemiddel’ zijn. Toch heeft die zienswijze maar weinig aanhang. Blijven roepen dat dat zo is, helpt natuurlijk niet. Maar wat helpt wel? De richting die we voorstellen is die waarbij gegevens zichtbaar op de balans komen. We moeten een model creëren dat niet alleen de waarde van gegevens voor de organisatie duidelijk maakt, maar ook de kosten van IT-systemen verdisconteert. Een model dus waarin de risico’s geëxpliciteerd worden die de organisatie loopt als gegevens niet voldoen of ontbreken. Inzicht in de financiële consequenties helpt daarbij, niet alleen om grillige rapportageverslavingen te kunnen becommentariëren, maar ook om de gegevensbrandstof van de informatiesystemen op waarde te kunnen schatten. Ook dit gaat niet vanzelf en ook hier is nog geen methode voor. Bedenk bij het tot stand brengen het volgende:
• Een keuze voor het realiseren van een informatiekostenmodel (IKM) is een strategische keuze. Mensen zijn niet gewend om te betalen voor gegevens, veelal omdat het registreren van gegevens niet als aparte activiteit wordt benoemd. De trend om steeds meer gegevens van extern te gebruiken cq. te gaan leveren, kan echter gebruikt worden om de kosten en waarde van eigen en vreemde gegevens in beeld te brengen.
• Als het in kaart brengen van de kosten en opbrengsten van gegevens moeilijk wordt, dan is het te overwegen om een risicogerichte benadering te kiezen. Maak daartoe inzichtelijk wat het de organisatie kost als gegevens verloren raken, corrupt worden of gewoon van begin af aan slecht zijn. Hoeveel kost een beslissing die fout is, omdat is uitgegaan van foutieve of onvolledige gegevens?
• Begin klein, om zo een ‘gegevensmarkt’ te creëren. Durf ook geld te vragen voor goede gegevens. Waarom zou goede informatie gratis zijn? Bovendien: als afnemers er niet voor willen betalen, dan hoef je je er ook niet voor in te spannen.
• Dat gebruikers gegevens willen hebben, is voor sommigen nieuwe relevante informatie. Hoe belangrijk ze die gegevens vinden, is dan weer af te leiden uit de prijs die ze ervoor willen betalen.
Vuistregel 3: Creëer geen informatiesteeg
Zonder een blauwe pet op te willen zetten of een knuppeltje aan onze broekriem te hangen, lijkt het aantrekkelijk de basis van politiegerichte gegevens vooraf maar minimaal te structureren. Structurering, nú nog een eigenschap van politiegegevensbanken, gaat immers uit van verwacht gebruik. En dát weet je nog niet. Een soort politie-Google is misschien een beter uitgangspunt.
Bestaande (administratieve) IT-systemen werken voornamelijk met vooraf bepaalde structuren: voor de gegevensopslag, voor de koppelingen, voor de bedieningsschermen. Al die structuren moeten worden ontworpen en gebouwd. De structuren van de verschillende deelsystemen moeten precies op elkaar aansluiten – anders werkt het niet.
Als twee systemen die los van elkaar zijn ontwikkeld met elkaar verbonden moeten worden, geeft dat allerlei problemen. De twee structuren moeten op elkaar worden afgestemd. Omdat die structuur overal in het systeem opduikt en overal wordt gebruikt (zowel impliciet als expliciet) is dat elke keer weer veel werk.
Eigenlijk zijn er twee typen verbanden die hinderlijke beperkingen kunnen opleveren: horizontale verbanden die zichtbaar worden in de gegevensuitwisseling tussen verschillende IT-toepassingen, en verticale verbanden waarbij het om een specifieke stapel van hardware en software gaat. In beide gevallen gaat het om inperking van mogelijkheden en om complexiteitstoename, zij het om verschillende redenen en verschillende uitwerkingen. Een ‘oplossing’ die vaak wordt gepropageerd, is standaardisering. Het probleem verdwijnt daardoor lokaal, maar het heeft ook weer negatieve consequenties. Elke structuur is, hoewel goed doordacht, ook maar één van de vele mogelijke keuzen. Nieuwe situaties vragen om nieuwe structuren, en in het ergste geval om aanpassing van bestaande standaardstructuren. Dan moeten echter al die systemen die werken volgens de oude standaarden worden aangepast. Dus ad-hoc standaarden geven op den duur meer verstarring.
Hoewel IT niet kán werken zonder structuur, zouden we specifieke structuren tot een minimum moeten beperken, met name ten behoeve van uitbreidbaarheid. Voor goede informatie is vaak al die structuur niet nodig. Wat maakt het voor het begrip uit of een straatnaam 20 of 21 posities telt? Natuurlijk kunnen standaarden werken en kunnen we daarmee flexibiliteit en interoperabiliteit vergroten. Maar we moeten ons bewust zijn van de plaatsen in de informatiehuishouding waar we flexibiliteit kunnen gebruiken, waar algemene gebruiksvoorwaarden gelden en waarvoor dus ook algemene maatregelen vereist zijn.
Dit zijn onze tips om ervoor te zorgen dat je zo weinig mogelijk structuren realiseert:
• Beperk standaarden tot die delen waarvan je zeker weet dat er de komende twintig jaar geen veranderingen gaan plaatsvinden.
• We moeten wel structuren gebruiken, maar ook software ontwikkelen die de bestaande data kan interpreteren ondanks die structuur. Software die kan omgaan met ongestructureerde gegevens geeft bedrijven de mogelijkheid om los te komen van verstikkende migratie- en integratietrajecten. De technologie die ingezet wordt voor Big Data-oplossingen kan mogelijk ook op kleinere schaal ingezet worden voor flexibiliteit op dit gebied. Heel kort gezegd: het wordt tijd dat software redactiesommen kan gaan maken en de structuur gebruikt die past bij het vraagstuk dat voorligt.
• Gebruik gegevensmodellen en ontologieën om de data die er zijn te interpreteren in plaats van te structureren voor één specifiek gebruik.
Niet te missen aspect
Vaak worden informatie en IT-systemen samengenomen en als één onderwerp van onderzoek behandeld. We hebben getracht, met enkele voorbeelden en met een drietal kijkrichtingen, te verduidelijken dat informatie het op zichzelf waard is om te beschouwen. Dit wordt des te duidelijker nu steeds meer externe informatiebronnen een rol spelen en ook steeds meer informatierelaties over organisatiegrenzen heen tot stand worden gebracht. Kennelijk spelen ook op operationeel niveau gegevenseigenschappen een rol bij het al dan niet succesvol opereren van organisaties. De strategische aspecten zijn aan de orde geweest in ons pleidooi voor een algemene, voorwaardenscheppende, ‘infrastructurele’ benadering. Tactische aspecten hebben we aangestipt in de voorbeelden over kosten en kostenbewustzijn. Daarmee hebben we de wenselijkheid van een aparte informatiearchitectuur toegelicht: in veel opzichten spelen gegevens en informatie een rol die onafhankelijk van IT-systemen en andere technische voorzieningen kunnen worden onderzocht en bepaald.
 
Dr. Jan Campschroer is managementconsultant bij Ordina. E-mail: jan.campschroer@ordina.nl
 
Dr. Jan Truijens werkt via Digitalis ICT/S Advies en parttime aan de UvA. E-mail: truijens.digit@planet.nl
 
[1] ICT is bij de overheid een groot zwart gat – Niemand weet hoeveel miljard er verloren gaat, Vincent Dekker, Trouw, 12 maart 2008. (www. cs.vu.nl/~x/knipselkrant/ trouw-12.pdf , )
[2] 90 miljard dollar kwijt aan falende IT, Chris Verhoef Automatisering Gids, week 21, 2004 (www.cs.vu.nl/~x/knipselkrant/ag-37.html)
[3] “Re-engineering the Corporation – A manifesto for IT evolution”, Harry Sneed, Chris Verhoef, 2001 (www.cs.vu.nl/~x/br/ br.html)

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag