In wezen is een ‘data warehouse’ of gegevenspakhuis een simpel ding. Bestaande gegevens worden gekopieerd, bijgewerkt, overgezet en in een aparte database opgeslagen. De nieuwe database is bedoeld voor analyse, daarom is hij ontworpen op basis van schema’s die redelijk transparant zijn. Het ontwerp is meestal stervormig en omvat details en historische gegevens.
Als er maar één of twee productie-databases zijn, dan zijn de brongegevens eenvoudiger te definiëren en is het aantal transformaties dat nodig is om een uniform formaat in het warehouse te krijgen beperkt. In veel gevallen zijn de gegevens echter opgeslagen in meerdere databases omdat er verschillende pakketten worden gebruikt voor administratie, personeel, productie en dergelijke. Bij de meeste oudere systemen, of het nu pakketten of zelf ontwikkelde systemen zijn, gebruikt elke applicatie meerdere databases. Dit is historisch zo gegroeid. De eerste databases waren niet geschikt voor grote, geïntegreerde systemen – en bovendien was daar bedrijfsmatig gezien nog helemaal geen behoefte aan. In de loop der tijd zijn er nieuwe functies aan de systemen toegevoegd; veel van deze applicaties zijn in feite afzonderlijke programma’s en databases, waarbij routines op de achtergrond draaien om gegevens van de ene database naar de andere te verplaatsen.
Niet alleen bedrijfsanalisten geven de voorkeur aan één bron. Daarom is de tijd nu rijp om een nieuwe generatie bedrijfsapplicaties rond een centrale database te bouwen, waarbij interactieve applicaties worden uitgebreid met (of zelfs vervangen door) geautomatiseerde processen (workflow management). Dit leidt tot het ‘enterprise resource planning’-concept (erp).
In de praktijk worden niet alle systemen echt geïntegreerd. Denk aan oudere modules en databases, waarbij workflow de integratie hooguit verbetert. Nieuwe pakketten zouden vanaf het begin rond een geïntegreerde database ontworpen moeten zijn. Dit heet ook wel de ‘operational data store’ (ods), een concept dat afstamt van ‘data warehousing’-technieken. Het is bedoeld om het beheer van kopieën (copy management) eenvoudiger te maken, maar vloeit ook voort uit het besef dat operationele systemen én bedrijfsanalisten voordeel hebben van betere query- en rapportagemogelijkheden die het gevolg zijn van een simpele, consistente database.
In alle eerlijkheid, zelfs supergeïntegreerde erp-pakketten zullen de echte problemen niet oplossen. Er zullen altijd meerdere pakketten geïnstalleerd zijn (twee of drie, geen twintig!) en geen enkel pakket biedt alle functies, zodat uitbreidingen onvermijdelijk zijn. Deze kunnen in sommige gevallen worden geïntegreerd met het erp-systeem, maar de leveranciers van zulke pakketten staan meestal niet zo positief tegenover ‘integrators’ die add-on pakketten willen installeren. Merk op dat het component-model hierin verandering kan brengen; Baan heeft al verklaard bereid te zijn proces-objecten beschikbaar te stellen aan andere ontwikkelaars. Samenvattend: erp-pakketten zullen de integratie van operationele en analytische systemen makkelijker maken, maar zij zullen de problemen de komende jaren zeker niet voor 100 procent oplossen.
De meeste erp-pakketten hebben een module voor bedrijfsanalyse. Dit zijn ingewikkelde producten om te benaderen. Het zijn in feite geïntegreerde ‘data marts’, maar ze bieden alleen toegang tot erp-gegevens, terwijl een echt gegevenspakhuis de erp-gegevens als één van de vele bronnen zou beschouwen. Een erp-analysemodule zal het meest efficiënt zijn, maar het is een beperkt concept. Een zorgvuldige evaluatie is noodzakelijk voordat men besluit deze toch wel doodlopende weg te bewandelen.
Query- en rapportagetools die SQL en PC’s gebruiken, zoals Brio, Business Objects, Cognos en dergelijke, kunnen effectief worden gebruikt in combinatie met een productiedatabase. Misschien is dit wel een betere investering dan een erp-analysemodule. Wel moeten zij kunnen beschikken over de database-definities; niet alle leveranciers van erp-pakketten zijn hier voldoende open in. De meesten geven de voorkeur aan een tussenoplossing, waarin een nachtelijke run de gegevens uit het systeem haalt en in lineair formaat aan PC-gebruikers ter beschikking stelt.
Het probleem dat zich voordoet als men de gegevens in verschillende databases wil achterhalen, treedt ook op bij het kopiëren van gegevens naar onafhankelijke gegevenspakhuizen en data marts (copy management). Gegevens kunnen alleen worden gekopieerd uit bekende bronnen. Dit probleem is voor een gegevenspakhuis veel ernstiger dan voor een query tool, omdat de scope veel breder is; hierdoor zijn er veel meer databases bij betrokken. Sommige leveranciers van erp-pakketten werken samen met leveranciers van tools voor bedrijfsanalyse om standaard gegevensdiensten te definiëren die de implementatie van copy management makkelijker maken. Dit wordt een belangrijke functionaliteit van veel erp-pakketten.
Hiermee wordt een andere vraag geraakt, namelijk welke gegevens moeten worden gekopieerd. Het warehouse heeft alleen nieuwe gegevens nodig; alleen gewijzigde gegevens hoeven te worden gekopieerd. Dit kan door gegevens voor en na verwerking te vergelijken of door tijdstempels van transactielogs te analyseren. De diversiteit van deze bronnen verdwijnt als het erp-pakket niet alleen een SQL-interface tot alle gegevens voor de query tools biedt, maar ook een API die toegang geeft tot gewijzigde gegevens.
