Het belangrijkste probleem met rapportagetools is de complexiteit van de informatiebronnen en het feit dat deze nauwelijks aansluiten op de perceptie die de eindgebruiker van de organisatie heeft.
De eerste vierde-generatietalen zijn voor de eindgebruiker dan ook nooit een succes geworden; voor de automatiseringsafdeling waren ze echter wel nuttig en verkortten ze de oplevertijd van nieuwe applicaties. En zo ontstonden de eerste beslissingsondersteunende systemen, zoals Focus en SAS. Deze hadden hun eigen database, die werd gevuld met productiegegevens en werd geïntegreerd met de vierde-generatietaal. Het formaat van de gegevens werd aangepast aan de eisen van de eindgebruiker.
Het waren de voorlopers van de huidige gegevenspakhuizen; ze worden nog steeds gebruikt als ‘data marts’. Voor de eindgebruiker waren ze feitelijk van beperkte waarde, al was het een enorme verbetering ten opzichte van het programmeren in een vierde-generatietaal.
Vaak werd een compromis bereikt, en werd IT-kennis gebruikt om primitieve ‘queries’ in elkaar te zetten, terwijl de eindgebruiker de taal kon gebruiken om zijn rapporten op maat te snijden. Er is verrassend weinig veranderd. Met eenvoudige applicaties, waarbij de database relatief eenvoudig te begrijpen is, hebben rapportagetools zeker enige waarde. Rapportgeneratoren voor de PC, zoals Crystal Reports of Report Smith, stellen gebruikers in staat hun rapporten samen te stellen op basis van een eenvoudige afdelingsdatabase. Het laden van voorgedefinieerde bestanden in spreadsheets is verfijnd doordat de regels van gegevensextractie zó geconfigureerd kunnen worden, dat de gebruiker betrokken wordt bij zowel de extractie als de bewerking van de gegevens.
Een enkele extractie kan een gegevensverzameling opleveren die, in tegenstelling tot een conventioneel rapport, kan worden bewerkt en verspreid. In plaats van een definitief, afgedrukt spreadsheet kunnen gebruikers nu hun gegevens samen met een spreadsheet-model verspreiden; deze benadering is veel flexibeler.
Wie behoefte aan analytische verwerking heeft, wil ook vergelijkingen, tijdreeksanalyses en complexere queries kunnen uitvoeren. Als rapportagetools voor eindgebruikers te ingewikkeld zijn, dan geldt dat zeker ook voor analytische modellen. De bewerking van het data-extract in een spreadsheet is geen oplossing, omdat hiermee alleen het extract kan worden gemanipuleerd, en niet de bron. Er is maar één antwoord: er moet een semantische laag tussen de gebruikerstools en de ruwe gegevens komen. Hierbij ziet de gebruiker de gegevens altijd in een formaat dat is gemodelleerd naar de bedrijfsprocessen.
De definitie van een semantisch model is niet zo eenvoudig en brengt meestal flink wat samenwerking tussen gebruikers en IT-specialisten met zich mee. Maar als het eenmaal klaar is, dan hebben gebruikers ook toegang tot alle gegevens, on-line, en zonder de beperkingen van een ‘extract’.
Ook al is het mogelijk een semantische ‘engine’ te bouwen om productiegegevens te benutten, de prestatie-problemen zijn immens. Er moet een gegevenspakhuis aan te pas komen om de interactie tussen de semantische laag en de database te vereenvoudigen.
De eerste PC-tools gebruikten een dikke client, waarin zowel het semantische model als de analytische verwerking op de PC draaiden en waarbij SQL-calls op de database werden afgevuurd. Dit was een enorme stap voorwaarts ten opzichte van de rapportagetools, maar bleek niet te kunnen uitgroeien tot een volwaardig hulpmiddel voor bedrijfsanalyse. De oorzaak hiervan was de complexiteit van SQL en de hoeveelheid gegevens die moeten worden getransporteerd, hetgeen weer leidt tot netwerkbelasting en enorme eisen aan de PC-hardware. Om de semantische en analytische modellen te kunnen verwerken zijn Olap en Rolap bedacht. Olap doet het met meerdimensionale gegevens, Rolap maakt gebruik van een gegevenspakhuis. De PC gebruikt nu een dunne client en neemt alleen nog de presentatie en de gebruikersinteractie voor zijn rekening.
Het dunne model is aangepast en ondersteunt nu webbrowsers in combinatie met Java-applets. De Rolap-server is nog steeds hetzelfde. Met deze technologie hoeft er geen code te worden gedistribueerd; de code wordt dynamisch geladen van de webserver die aan de Rolap/Olap-server is gekoppeld. Deze oplossing is toe te passen binnen de grenzen van een intranet, maar kan via het Internet in principe aan iedereen beschikbaar worden gesteld.
Dit is een heel nieuw speelveld. Slechts weinig gebruikers hebben op dit moment behoefte aan krachtige Rolap/Olap-functies. Iets meer gebruikers hebben behoefte aan rapportagetools, maar moet iedereen hierover via het Web kunnen beschikken? Of is het misschien weer een excuus om spelletjes te kunnen spelen? Hoe komen we aan de noodzakelijke extra processor- en netwerkcapaciteit? En welke applicaties hebben nu echt baat bij analytische mogelijkheden voor iedereen? Ik vraag het me af! Eerdere ervaringen met tools voor eindgebruikers zouden ons enig inzicht in de valkuilen van deze aanpak moeten geven – denk bijvoorbeeld eens aan de explosieve toename van de vraag naar IT-support!
