Enterprise content management wordt vaak als een apart product in de markt gezet. Het beheer van content zou volgens deze producten zoveel mogelijk plaats moeten vinden binnen dit product. Eigenlijk is dit een rare gedachtegang. In principe zou ecm veel meer een visie dan een product moeten zijn. Want content is overal: in de productendatabase, in het crm-pakket, op de website, in Word- en Excel-documenten, in Exchange/Outlook, in de wiki, op het intranet.
Wat een echt overkoepelend ecm-product zou moeten zijn is een grote integratietoepassing: een product dat content overal vandaan haalt, omzet in een uniform geheel, aanpasbaar en beheersbaar maakt, maar ook weer terug wegschrijft in de contentsilo waar het vandaan kwam. Een mapping dus, tussen content in de diverse applicaties en content in het ecm-pakket.
In plaats daarvan wordt de ecm-markt op dit moment vooral gedomineerd door hele grote softwarepakketten die vooral hun best doen om content IN die pakketten te houden. Dat lijkt een simpele oplossing, maar het is een versimpeling van de werkelijkheid en levert op termijn een informatiemanagement-nachtmerrie op. Wat organisaties eigenlijk vooral willen is integratie, aggregate en syndicatie van content.
Het is niet dat er niets gebeurt. Er zijn diverse initiatieven gestart om contentuitwisseling te verbeteren. Zo is vanuit de Java Community Proces, de standaardorganisatie voor Java-technologie, JSR-170 en de opvolger JSR-283 gestart, een Java-standaard om het toegangsprotocol op content te standaardiseren. De OASIS-standaardorganisatie heeft tientallen open standaarden ontwikkeld voor gestructureerde informatie. De Dublin Core-standaard van ISO geeft houvast voor het definieren van metadata. Het World Wide Web Consortium (afgekort W3C) heeft tientallen zeer bekende standaarden zoals XHTML, HTTP, XSLT, CSS en SOAP onder zijn hoede.
Alhoewel sommige van deze initiatieven zeer succesvol zijn, blijft het opvallen hoe de ecm-industrie de makkelijke weg kiest en niet standaarden adopteert maar toch weer eigen, proprietary formats definieert en vooral ook content zoveel mogelijk binnen de eigen informatiesilo houden, in plaats van content zoveel mogelijk te halen uit de bestaande contentsilos. Een gemiste kans?
Hi Martijn,
Volgens mij gebeurt er op het gebied van het integreren van externe bronnen door grote ECM suites meer dan je suggereert. Het ontsluiten van externe (legacy) bronnen en geintegreerd aanbieden van de hierin gelegen content is wel degelijk een belangrijk aandachtspunt, juist ook omdat de markt aan de leveranciers wel duidelijk heeft gemaakt dat het niet haalbaar is alle content IN de ECM oplossing op te slaan. Integratie vindt nu niet alleen plaats via search engines, maar ook via integratiemodules die mogelijkheden bieden tot het delen van metadata en het leggen van relaties. Wat je wel ziet, is dat de beheermogelijkheden van “externe” content minder groot zijn dan van de content die wel in de ECM suite wordt opgeslagen, maar dit lijkt me een logisch gevolg.
Ik denk dat er veel opdrachtgevers zijn die ECM niet alleen willen toepassen als “een grote integratietoepassing”, maar ook als een beheermogelijkheid voor (interne) contentprocessen. Niet voor niets is compliance een belangrijke drijvende kracht achter ECM initiatieven. Hierbij gaat het niet om het integreren van zoveel mogelijk content, maar om het kunnen garanderen van de kwaliteit van content die door het ECM proces is gegaan.
Ook qua standaardenadoptie gebeurt er veel in de ECM markt, bijvoorbeeld ook op het vlak van het geautomatiseerd kunnen implementeren van bedrijfsprocessen. Hiervoor wordt weer gebruik gemaakt van op XML gebaseerde notatietechnieken (ook industrie-standaarden) die implementaties mogelijk maken zonder “programmeerwerk”.
ECM is een breed begrip en ECM suites zijn ook brede producten.
In het kader van integratie lijkt het van belang om te kijken wat je precies van ECM verwacht:
1. Een centraal warehouse met content
2. Een middel om content te creeren
3. Een middel om content te beheren
4. Een middel om content te consumeren.
Bij het warehouse en beheer is verdere integratie met overige systemen noodzakelijk. Bij consumeren kan een zoekmachine de benodigde integratie verzorgen, het hoeft immers pas in de browser bij elkaar te komen.
Het grootste integratieprobleem zit hem m.i. in de creatie. Verschillende bedrijfsprocessen en verschillende toepassingen (business applicaties, email, wiki’s, office) leiden tot verschil in opslag, metadata en beheer van content. Dit integreren zou een enorme bijdrage leveren aan de bereidheid van medewerkers om hun content ook echt te delen. Ten eerste omdat de effectiviteit van de content groter wordt en omdat het delen van content eenvoudiger wordt.
Martijn,
Het kan altijd beter, maar binnen de ECM-wereld is men wel degelijk beter met het beter interoperabel maken van systemen (en daarmee ook de content). Men moet ook wel, want dit is een keiharde eis uit de markt. Binnen AIIM is er zelfs een iECM groep opgericht die zich met interoperabiliteit van ECM-systemen bezig houdt.
De oplossing ligt overigens niet in een “overkoepelend product” dat jij voorstel – Weet je zeker dat je zo’n moloch wilt? – maar in het interoperabel maken van de systemen waarin de content zich bevindt. En het interoperabel maken de content zelf natuurlijk (xml xml xml …).
Mijn pleidooi is niet zozeer dat ECM pakketten geen integratiecomponent in zich hebben, dat hebben ze inderdaad vrijwel allemaal wel. Ik vind dat ECM zo ongeveer integratie zou moeten zijn, of in ieder geval als groter doel zou moeten nastreven. De content zit in allerlei andere systemen, en daar moet het in- en uitgehaald worden. Met het bouwen van maar weer een eigen content silo wordt het probleem van meerdere van die repositories alleen maar versterkt.
Er zijn inderdaad allerlei standaarden, en de standaard organisatie’s doen erg goed werk (wij als WCMS leverancier proberen er zoveel mogelijk van over te nemen), maar ik denk dat de grote, generieke ECM leveranciers best nog wel wat meer hun best zouden mogen doen zich ook aan die standaarden te houden, zodat gebruikers van die producten in ieder geval content kunnen uitwisselen met andere systemen, dat is alvast een goed begin.
Ben het met Paul Ruijgrok en Paul Baan eens dat er allerlei soorten ECM producten zijn, en dat ECM een zeer ruim begrip is. Bij sommige producten is het nogal logisch om een geheel zelfstandige content repository te bouwen, maar bij met name de zeer generieke ECM producten zou ik integratie als veel groter thema verwachten dan ik nu vaak zie.