XML en Organisatie: vijf tegenstellingen

“We’re going through a transition in technology, which I’ll talk about, from
the world of the PC to the graphical user interface to the Internet, and now to
the XML revolution, which I think will actually be as big or bigger as any of
the revolutions which have preceded it.”

Steve Ballmer, Chief Executive Officer Microsoft Corporation
InfoWorld CTO Summit, San Francisco, June 21, 2001

XML en Organisatie: vijf tegenstellingen
Pieter van der Hijden

SGML/XML Users Group Holland

Over de auteur
Pieter van der Hijden is organisatie- en ICT-adviseur met als specialismen
XML, e-government en management games (pvdh@sofos.nl). Hij werkt via zijn
eigen Sofos Consultancy te Amsterdam (www.sofos.nl).

De activiteiten van de Werkgroep Organisatie van de SGML/XML-User Group
vormden de bouwstenen voor de totstandkoming van deze uitgave. De Werk-
groep bestaat uit de volgende leden:
Eduard Bonjer, SolVision
Bea van Ette, Nijgh
John de Gast, Scan Laser
Pieter van der Hijden, Sofos Consultancy
Aad Kamsteeg, Diderot Track (voorzitter)
John Leenen, DCE Consultants
Sam van der Meij, ITM management & informatie
Steven Metz, DCE Consultants
Quirijn Schuurmans, Mitsubishi Motors
Henk Verbeek, Kluwer

Copyright
© Copyright 2002 SGML/XML Users Group Holland, Postbus 20, 1687 ZGþWog-
num.
http://www.sgml-ug.nl

ISBN
90 807527 1 1

Zet- en drukwerk
Grafidata, Deventer, http://www.grafidata.nl

Illustraties
Frank Kamsteeg, Rijswijk

Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgesla-
gen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op
enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen, of enig andere
manier, zonder voorafgaande schriftelijke toestemming van de uitgever.

Inhoud

Voorwoord 7

1 Inleiding 9
1.1 Korte introductie XML ................................................ 9
1.1.1 Definitie .............................................................. 9
1.1.2 Historie ............................................................... 9
1.1.3 Documenten ..................................................... 11
1.1.4 Documentschema's ............................................ 12
1.1.5 XML-familie ..................................................... 13
1.1.6 Toepassingen..................................................... 14
1.2 Leeswijzer .................................................................. 14

2 Kiezen voor XML: technische standaard of
strategische technologie? 17
2.1 Technische standaard ................................................. 17
2.2 Strategische technologie.............................................. 18
2.3 Overweging ................................................................ 20
2.3.1 Statische omgeving ............................................ 20
2.3.2 Dynamische omgeving ....................................... 21
2.3.3 Turbulente omgeving......................................... 22
2.4 Conclusie ................................................................... 23

3 Innoveren met XML: bottom-up of top-down? 25
3.1 Bottom-up ................................................................. 25
3.2 Top-down .................................................................. 26
3.3 Overweging ................................................................ 27
3.4 Conclusie ................................................................... 27

4 Externe relaties: Ketens of netwerken? 29
4.1 Ketens ....................................................................... 29
4.2 Netwerken ................................................................. 31
4.3 Overweging ................................................................ 33
4.4 Conclusie ................................................................... 34

5

5 Focus van XML: Techniek of organisatie? 35
5.1 Techniek .................................................................... 35
5.2 Organisatie ................................................................. 36
5.2.1 Relatie tot de omgeving ...................................... 36
5.2.2 Organisatiestructuur .......................................... 36
5.2.3 Processen .......................................................... 37
5.2.4 Medewerkers ..................................................... 37
5.2.5 Organisatiecultuur ............................................. 37
5.2.6 Infrastructuur .................................................... 38
5.2.7 Huisvesting........................................................ 38
5.2.8 Financiën .......................................................... 38
5.3 Overweging ................................................................ 38
5.4 Conclusie ................................................................... 39

6 Invoeren van XML: Project of proces? 41
6.1 Project ....................................................................... 41
6.1.1 Initiatieffase ....................................................... 42
6.1.2 Definitiefase ...................................................... 42
6.1.3 Ontwerpfase ...................................................... 43
6.1.4 Realisatiefase ..................................................... 43
6.1.5 Implementatiefase.............................................. 43
6.1.6 Gebruik en beheerfase........................................ 43
6.2 Proces ........................................................................ 44
6.2.1 Management ..................................................... 44
6.2.2 Medewerkers ..................................................... 45
6.2.3 ICT-ers ............................................................. 45
6.2.4 Afnemers........................................................... 46
6.2.5 Leveranciers ...................................................... 46
6.2.6 Context ............................................................. 46
6.3 Overweging ................................................................ 46
6.4 Conclusie ................................................................... 47

7 Uitleiding 49

Bijlagen 51

6

Voorwoord

De eXtensible Markup Language (XML) is een open standaard voor
het annoteren van informatie. Documenten gebaseerd op deze stan-
daard zijn door computers te lezen en te interpreteren. Het gebruik van
XML is sterk in opkomst. Alleen al in Nederland zijn naar onze inschat-
ting honderden XML-projecten uitgevoerd.
Informatie over XML en zijn toepassingen is overvloedig beschik-
baar. Academische boekhandels vullen meters schaplengte met XML-
titels en zelfs in warenhuizen en kiosken zijn boeken over XML terug te
vinden. De insteek van al dat moois is echter vooral technisch. De orga-
nisatorische kant van de invoering van XML krijgt nauwelijks aandacht.
Dat is vreemd, omdat vooral op organisatorisch gebied er nogal eens
wat mis gaat bij XML-projecten.
De SGML/XML Users Group Holland is een vereniging gericht
op het creëren, delen en onder de aandacht brengen van voorhoedeken-
nis op het gebied van SGML/XML. Ze heeft het gebrek aan informatie
over de organisatorische aspecten van XML gesignaleerd en een werk-
groep ingesteld om daar wat aan te doen.
De Werkgroep Organisatie had niet de middelen om een groots
onderzoek op te zetten. Ze heeft zich daarom beperkt tot het onderzoe-
ken van een tiental bedrijven met interessante XML-cases. Deze bedrij-
ven behoorden tot de volgende sectoren: productie van transport–
middelen, productie van elektronica, banken, verzekeringen, persagent-
schappen, uitgeverijen, onderwijs, onderzoek, omroep en overheid. Uit
de onderzochte cases heeft de werkgroep meer algemeen bruikbare
inzichten gedestilleerd.
De werkgroep heeft een vijftal vragen geïsoleerd die managers,
adviseurs, ICT-professionals en betrokken medewerkers zouden moeten
afwegen. In het kort gaat het hierbij om:
1. Zien wij XML als een technische standaard of als een strategische
technologie?
2. Innoveren wij met XML bottom-up of kan dat beter top-down?
3. Zien wij onze relaties met de buitenwereld als een keten of als een
netwerk?
4. Draait het bij de invoering van XML om de techniek of om de
organisatie?

7

5. Pakken wij de verandering aan als een project of als een proces?
Over deze vijf afwegingen valt veel te zeggen. De werkgroep heeft dat
gedaan in de vorm van de publicatie die nu voor u ligt.
De vereniging is de onderzochte bedrijven dankbaar voor hun
bereidwillige medewerking aan het onderzoek. Hun namen worden hier
niet vermeld, omdat een deel van de verstrekte informatie daarvoor te
vertrouwelijk was. Onze erkentelijkheid is daar uiteraard niet minder
om.

Met genoegen biedt de vereniging u hierbij de publicatie aan.

Namens het bestuur van SGML/XML Users Group Holland

Gerard te Vaanhold

Voorzitter

8

1 Inleiding

Dit hoofdstuk start speciaal voor nieuwkomers op het terrein van XML met
een ultrakorte behandeling van XML voor beginners. Het geeft een informele
definitie van XML, beschrijft kort zijn historie en gaat in op XML-documen-
ten en XML-documentschema’s, de familie van XML-standaards en de
belangrijkste XML-toepassingen. Het eindigt met een leeswijzer.

1.1 Kor te introductie XML
1.1.1 DEFINITIE
XML staat voor eXtensible Markup Language, ofwel uitbreidbare mar-
keringstaal. Het is een open standaard voor het annoteren van informa-
tie, in principe digitale tekstuele informatie. We noemen XML een taal
omdat het een vocabulaire kent en grammaticaregels. De markering van
informatie gebeurt door middel van labels of “tags”. De gebruiker kan
zelf nieuwe “tags” benoemen en aan het vocabulaire van de taal toevoe-
gen. In die zin is de taal dus uitbreidbaar.

Voorbeeld 1
Om in een tekst aan te geven dat de passage “Lange Poten 4” een
adres betreft, zou je de volgende XML-notatie kunnen gebruiken:
<adres>Lange Poten 4</adres>

In voorgaand voorbeeld geven de tags <adres> en </adres> het begin en
einde aan van een tekstfragment dat als “adres” moet worden opgevat.
De eindtag verschilt van de begintag in het extra “/”-teken (slash). Tags
komen altijd paarsgewijs voor. Het zijn als het ware open- en sluithaak-
jes. De combinatie van begintag, inhoud en eindtag heet “element”. Ele-
menten kunnen ook genest worden (tagpaar binnen tagpaar).

1.1.2 HISTORIE
In 1986 heeft de International Standards Organisation de SGML-stan-
daard vastgesteld (ISO8879). SGML staat voor Standardised General
Markup Language. Dit is een zeer uitgebreide markeringstaal met veel
variatiemogelijkheden. Ze werd en wordt vooral toegepast in bedrijfstak-

9

ken met grote volume’s aan ingewikkelde documenten, zoals de vlieg-
tuigindustrie. Daarnaast is ze vooral bij uitgeverijen in gebruik. Zij
kunnen met behulp van deze standaard hun digitale informatie
medium- en opmaakneutraal opslaan. Dat wil zeggen dat de vormeigen-
schappen van het publicatiemedium geen onderdeel van het bestand
zijn. Het bestand is daardoor gemakkelijk te hergebruiken voor een
ander dan het oorspronkelijke publicatiemedium of format.
In 1989 heeft het CERN in Genève een Hypertext Markup Lan-
guage (HTML) geformuleerd. Daarbij is gebruik gemaakt van een aan-
tal principes uit SGML. HTML is een markeringstaal voor
webpagina’s. Surfen over het Internet komt in feite neer op het elders
ophalen van een HTML-document. De internetbrowser op de eigen PC
maakt daar dan een webpagina van. Het programmeren van webpa-
gina’s is vrij eenvoudig, terwijl ook de internetbrowsers niet al te com-
plex hoeven te zijn.
Ook HTML was oorspronkelijk bedoeld om informatie opmaak-
neutraal te markeren. Het zou dan de taak van de browser zijn om bij
een bepaalde informatie-inhoud een adequate opmaak te genereren. In
de praktijk van het snel groeiende World Wide Web bleek echter dat de
houders van websites zo veel mogelijk zélf wilden bepalen hoe hun web
site op de PC van de ontvangers er uit zou komen te zien. Bouwers van
concurrerende internetbrowsers gingen daarom hun producten van
steeds meer toeters en bellen voorzien en verzonnen eigen uitbreidingen
op HTML. Met moeite heeft het World Wide Web Consortium (W3C)
die ontwikkeling weten te bezweren. Deze organisatie nam de zorg voor
HTML over. Er verschenen nieuwe, meer uitgebreide versies van
HTML met meer mogelijkheden om de uiteindelijke opmaak te beïn-
vloeden.
De oorspronkelijke bedoeling achter HTML was door de werke-
lijkheid ingehaald. Het World Wide Web Consortium besloot daarom
om een nieuwe start te maken. Het ontwikkelde in 1998 XML als een
lichte vorm van SGML. De oorspronkelijke bedoeling hiervan is het
inhoudelijk markeren van webinformatie. Inhoud en opmaak zijn nu te
scheiden. Via een eenvoudige vertaalslag aan de kant van de webserver
of binnen de internetbrowser op de PC wordt deze informatie dan van
een bepaalde opmaak voorzien. De taal is uitbreidbaar met eigen voca-
bulaires, bijvoorbeeld per vakgebied. Bovendien zijn XML-teksten
dankzij de grammaticaregels door een computer op syntactische cor-
rectheid te controleren. Net als HTML-documenten, zijn ook XML-
documenten moeiteloos via het Internet op te vragen en te transporte-
ren.
XML is goed aangeslagen. Als lichte uitgave van SGML blijkt het
niet alleen nuttig voor webpagina’s, maar ook voor allerlei zaken die eer-

10

der met SGML werden aangepakt. Ook uitgeverijen maken daarom in
toenemende mate van XML gebruik. Het is daarnaast het bindmiddel
voor applicatie-integratie en de basis voor het gestandaardiseerd berich-
tenverkeer bij elektronisch zaken doen. De computerindustrie van IBM
via Microsoft tot Sun heeft XML omarmd. XML is daarom zeker geen
hype, maar een blijvende verandering.
De ontwikkeling van HTML is intussen na versie 4 gestopt. Het
World Wide Web Consortium heeft nu XHTML gelanceerd (2000) dat
in eerste instantie identiek is aan HTML 4, maar dan als een volwaar-
dige XML-toepassing. Programmeren blijft relatief eenvoudig, ook de
browsers kunnen relatief eenvoudig zijn. Dankzij de strikte grammatica
kunnen webpagina’s nu gevalideerd worden. Verdere ontwikkelingen
van XHTML vinden plaats. Ook daarbij is de tendens om inhoud en
presentatie uit elkaar te halen.

1.1.3 DOCUMENTEN
Een samenhangende hoeveelheid informatie voorzien van XML-tags
heet een XML-document. In een XML-document geven de tags de
structuur aan en lopende tekst de eigenlijke inhoud. Doordat de inhoud
van een tagpaar weer een ander tagpaar kan bevatten (het nesten van
elementen) heeft vrijwel elk XML-document een hiërarchische indeling
(boomstructuur).
Een XML-document is op te vatten als een lange reeks van tekens
die machinaal leesbaar is. Voor de tekens zijn verschillende coderingen
mogelijk, onder andere Unicode. XML is daarmee geschikt om vrijwel
elke schriftsoort op de wereld vast te leggen. Fysiek gezien is een XML-
document vaak één computerbestand of één databaserecord. Een
XML-document kan echter ook opgesplitst worden in meerdere fysieke
entiteiten. Die fysieke entiteiten kunnen ook een geheel ander format
hebben dan tekst, bijvoorbeeld beeld of geluid. XML is daardoor
geschikt voor het inhoudelijk structureren van multimediaal bronmateri-
aal.
Een van de belangrijkste eisen die aan programmatuur voor het
verwerken van XML-documenten wordt gesteld is dat deze altijd moet
controleren of een XML-document grammaticaal en syntactisch correct
is. In XML-jargon: een XML document moet altijd well formed zijn.
Wanneer een programma vaststelt dat een document niet aan die eis
voldoet, dan stopt de verwerking en zal een foutmelding worden gege-
ven. Als een XML-document niet well formed is dan is het geen XML-
document. Deze strenge regel zorgt ervoor dat XML betrouwbaar ver-
werkt kan worden, omdat elementaire fouten in de structuur zijn uitge-
sloten.

11

1.1.4 DOCUMENTSCHEMA'S
Een documentschema is een voorschrift dat aangeeft hoe de structuur
van een bepaald type XML-document er uit hoort te zien. Het geeft aan
welke elementen in welke volgorde horen voor te komen, welke elemen-
ten verplicht zijn en welke optioneel.
De begintag van een element kan voorzien worden van additionele
gegevens zoals parameterwaarden. Deze gegevens heten attributen. Het
documentschema kan ook voorschrijven of een element attributen heeft,
welke dat zijn (verplicht of optioneel) en welke waarden de attributen
kunnen aannemen.

Voorbeeld 2
De begintag uit voorbeeld 1 is nu van een attribuut voorzien dat
aangeeft dat het om een bezoekadres gaat:
<adres type="bezoek">Lange Poten 4</adres>

Het grote voordeel van het werken met documentschema’s is dat XML-
documenten daarmee automatisch valideerbaar worden. Voor ieder
XML-document kan een computer nagaan hoe het zit met de wellfor-
medness. Voor een XML-document dat naar een documentschema ver-
wijst kan een computer bovendien nagaan of het document voldoet aan
het schema. Documenten zijn daarmee automatisch te controleren. De
uitwisseling van documenten tussen verschillende computersystemen
wordt daarmee een stuk betrouwbaarder omdat nu voorspelbaar is
geworden wat een document mag en kan bevatten. Onaangename ver-
rassingen zijn daarmee uitgesloten.
Binnen XML heten documentschema’s Document Type Definiti-
ons (DTD’s). Deze hebben een beperkte functionaliteit en kunnen bij-
voorbeeld niet aangeven tot welk datatype de inhoud van een bepaald
element behoort en wat minimum en/of maximum waarden zijn. Het
World Wide Web Consortium heeft echter inmiddels een nieuwe en
meer uitgebreide definitie voor documentschema’s opgesteld. Deze
heten kortweg XML-schema’s. Daarnaast hebben enkele andere consor-
tia alternatieven voor XML-schema’s bedacht (bijv. Relax NG van Oasis
en Schematron van het Academia Sinica Computing Center in Taiwan).
Onderstaande tabel geeft enkele voorbeelden van bestaande docu-
mentschema’s.

12

Tabel 1.1: Voorbeelden van documentschema's
Documentschema Toepassingsgebied
DocBook Technische handleidingen
CML Chemische formules
EML Onderwijsmodules
MathML Wiskundige formules
NewsML Nieuwsberichten
SVG Schaalbare vector voorstellingen
XHTML Websites
WML 3 Waptelefoons

1.1.5 XML-FAMILIE
Behalve de eigenlijke XML-aanbeveling (het World Wide Web Consor-
tium spreekt niet van standaards omdat het W3C geen officiële stan-
daardorganisatie is) is inmiddels een hele familie van verwante
aanbevelingen gecreëerd. We noemen hier kort de “namespaces” en
XSL. Een uitgebreider overzicht staat in onderstaande tabel.
Er is een voorziening genaamd “Namespaces” die een methode
geeft om ervoor te zorgen dat bij gebruik van een XML-document dat is
samengesteld uit fragmenten van andere XML-documenten die door
verschillende schema’s zijn gedefinieerd geen conflicten in naamgeving
van elementen of attributen kan ontstaan. Met een namespacedefinitie is
in alle omstandigheden zichtbaar uit welk schema het element afkomstig
is. Dit is vooral van belang bij uitwisseling van XML-gegevens.
XSL (eXtensible Stylesheet Language) bestaat feitelijk uit twee
delen: XSLT (transformaties) is een XML vocabulaire waarmee trans-
formaties van het ene XML-model naar een willekeurig ander XML-
model, HTML of “tekst” kunnen worden uitgevoerd. Het andere deel is
XSLFO (Formatting Objects). XSLFO is een XML-vocabulaire waar-
mee een paginaopmaak kan worden beschreven. XSLFO is een presen-
tatietaal voor in XML. Met behulp van XSLT kan een XML-document
worden getransformeerd in een XSLFO-document. Wanneer gesproken
wordt over XSL worden beide delen bedoeld.

13

Tabel 2: De belangrijkste leden van de XML-familie
Technische standaard Beschrijving Status
EXtensible Markup Language De basisdefinitie voor XML. Versie 1.0 (Tweede Editie).
(XML) 1.0 Aanbeveling sinds 6 oktober
2000.
EXtensible Stylesheet Language Standaard transformatietaal Versie 1.0. Aanbeveling sinds 16
for Transformations (XSLT) voor XML. november 1999.
Extensible Style sheet Language Standaard opmaaktaal (pagina- Versie 1.0. Aanbeveling sinds 15
for Formatting Objects beschrijvingstaal) voor het oktober 2001.
(XSLFO) omzetten van XML naar print-
bare pagina’s.
XML Schema Standaard voor het beschrijven Versie 1.0. Aanbeveling sinds 2
van XML structuren, inhoud en mei 2001.
semantiek van XML documen-
ten. Modelleringstaal.
XML Namespaces Standaard voor het definiëren Aanbeveling sinds 14 januari
van unieke kenmerken om ele- 1999.
menten en attributen met een
zelfde naam afkomstig uit ver-
schillende schema’s te kunnen
onderscheiden.
Document Object Model Generieke methode om dyna- Level 1: aanbeveling sinds 1
(DOM) misch toegang te krijgen tot oktober 1998; Level 2: aanbeve-
XML structuren en deze te kun- ling sinds 13 november 2000.
nen aanpassen in het geheugen
van een computer.
XML Path Language (XPath) Syntax om specifieke posities in Versie 1.0. Aanbeveling sinds 16
een XML structuur te kunnen november 1999.
benoemen en te kunnen bevra-
gen.
XML Linking Language Taal om de relatie tussen XML Versie 1.0. Aanbeveling sinds 27
(XLink) documenten te kunnen beschrij- juni 2001.
ven.
XML-Signature Syntax and Syntax en regels voor het opne- Aanbeveling sinds 12 februari
Processing men van digitale handtekening 2002.
in een XML document en hoe
deze weer te geven.

1.1.6 TOEPASSINGEN
De bekendste toepassingsgebieden voor XML zijn: mediumneutraal
uitgeven, interactieve webportalen, berichtenverkeer binnen en buiten
de organisatiegrenzen. Hiermee zijn zaken mogelijk als digitale duur-
zaamheid, content management als aanvulling op document manage-
ment, applicatie-integratie, keteninformatisering en webservices.

14

1.2 Leeswijzer
In de navolgende hoofdstukken wordt een vijftal vragen rond XML en
organisatie behandeld.
1. Zien wij XML als een technische standaard of als een strategische tech-
nologie?
Organisaties kunnen XML inzetten als een technische standaard
of als een strategische technologie. Waarop de nadruk ligt, hangt
af van de wijze waarop een organisatie wil innoveren. Dat laatste
wordt vooral ingegeven door de aard van de omgeving waarbinnen
die organisatie opereert.
Organisaties blijken vrij spontaan met innovatie bezig te zijn. Dat
gebeurt op initiatief van decentrale managers en zonder veel
bemoeienis van de top (bottom-up). Het kan ook anders, als een
door de top geïnitieerd en gestuurd verandertraject (top-down).
Ook innoveren met XML kan zowel bottom-up als top-down
plaatsvinden. Vaak gaat een periode van spontaniteit vooraf aan
het moment waarop elektronisch zaken doen en het belang van
standaards op de agenda van het topmanagement staat.
3. Zien wij onze relaties met de buitenwereld als een keten of als een net-
werk?
Organisaties zien hun relaties met de buitenwereld soms als een
keten of bedrijfskolom, soms als netwerken. Hun business model
bepaalt hun blik. Voor XML-trajecten is dit onderscheid relevant.
4. Draait het bij de invoering van XML om de techniek of om de organi-
satie?
Afhankelijk van het vertrekpunt en het ambitieniveau is een XML-
traject voor een organisatie vooral een technische of een organisa-
torische uitdaging.
Organisaties kunnen een XML-verandertraject op verschillende
wijzen aanpakken. Globaal gezien valt er te kiezen tussen een aan-
pak als project of een aanpak als proces. De afweging hangt af van
organisatorische condities.
De publicatie eindigt met een “uitleiding” waarin als samenvatting de
twee “extremen” uit bovenstaande vragen met elkaar worden vergele-
ken.

15

2 Kiezen voor XML: technische
standaard of strategische
technologie?

Organisaties kunnen XML inzetten
als een technische standaard of als
een strategische technologie. Waarop
de nadruk ligt, hangt af van de wijze
waarop een organisatie wil innove-
ren. Dat laatste wordt vooral ingege-
ven door de aard van de omgeving
waarbinnen die organisatie opereert.

2.1 Technische
standaard
XML kan worden opgevat als een
louter technische standaard voor het platformneutraal, applicatieneu-
traal en presentatie-/mediumneutraal opslaan van informatie.
Een XML-document is platformneutraal, omdat het gebruikte
platform (Windows/Intel, Macintosh, Sun/Solaris e.d.) er niet toe doet.
Een XML-document bevat geen platformspecifieke coderingen en kan
bovendien probleemloos via Internetprotocollen worden uitgewisseld
tussen verschillende platforms.
Een XML-document is ook applicatieneutraal. De enige eis die
aan applicaties gesteld wordt is dat ze XML kunnen lezen en schrijven.
Steeds meer applicaties die op de markt zijn hebben die eigenschap.
Eigen ontwikkelde applicaties zijn relatief eenvoudig met XML-functio-
naliteit uit te breiden. Veel gebruikte programmeeromgevingen bevatten
daar de hulpmiddelen voor. Verder is allerlei nuttige XML-software, als
afzonderlijke applicatie of als component, in het publieke domein
beschikbaar of tegen relatief lage kosten aan te schaffen.
Een XML-document kan presentatie- of mediumneutraal zijn. Er
staat “kan” omdat het van de ontwikkelaar afhangt of het ook zo is.
Zoals het met een gestructureerde programmeertaal toch mogelijk is om

17

programma’s de inzichtelijkheid van een bord spaghetti te geven, zo is
het ook met XML mogelijk om toch een onleesbaar document op te zet-
ten waarin inhoud en opmaak dwars door elkaar heen staan. Erg gebrui-
kelijk is dat gelukkig niet.
Het inzetten van XML als een technische standaard biedt organi-
saties de volgende mogelijkheden:
• Inhoudelijke informatie hoeft slechts eenmaal opgeslagen en
onderhouden te worden en is telkens weer opnieuw te gebruiken;
• De kwaliteit van informatie verbetert; de informatie moet immers
voldoen aan de voorschriften uit het documentschema (consisten-
tie);
• De overgang naar een nieuwe publicatieopmaak of naar een nieuw
publicatiemedium is gemakkelijker te maken;
• Onderling verschillende applicaties en platforms zijn gemakkelij-
ker te integreren;
• De workflow rond inhoudelijke informatie is beter te stroomlijnen.

2.2 Strategische technologie
XML is ook op te vatten als een strategische technologie. Deze techno-
logie maakt het mogelijk om:
• Gestructureerde informatiecomponenten te creëren, te bewerken,
op te slaan en terug te vinden;
• Gestandaardiseerde berichten uit te wisselen tussen verschillende
applicaties, óók over de grenzen van de eigen organisatie heen.
XML is bedoeld om informatie inhoudelijk te annoteren. Dat kan tot op
een zeer gedetailleerd niveau. Iedere vorm van annotatie is vervolgens te
gebruiken bij het selecteren en filteren van informatie. Het beheer van
informatie speelt zich daardoor niet meer alleen op documentniveau af,
maar op ieder te kiezen deelniveau zo lang als dat correspondeert met
een XML-element.
XML biedt een fraaie oplossing voor gestandaardiseerd berich-
tenverkeer die flexibeler en goedkoper is dan EDI en in potentie een veel
groter bereik heeft. De XML-oplossing is flexibeler omdat een docu-
mentschema gemakkelijk is uit te breiden. Ze is ook goedkoper, omdat
de standaard open is en berichten over de relatief goedkope infrastruc-
tuur van het Internet te versturen zijn. Een bijkomend voordeel is dat
hoewel XML-documenten bedoeld zijn voor computers, ze toch ook
voor niet-ingewijde mensen redelijk leesbaar zijn. EDI-documenten zijn
alleen leesbaar voor ingewijden.

18

Het inzetten van XML als een strategische technologie biedt orga-
nisaties de volgende mogelijkheden:
• Een organisatie die zich gesteld ziet voor een explosie van de hoe-
veelheid technische documentatie, kan die documentenstroom
beter beheersen. Informatiecomponenten kunnen uit verschillende
bronnen afkomstig zijn, bijvoorbeeld productinformatie afkomstig
van verschillende toeleveranciers. Versiebeheer op componentni-
veau is relatief eenvoudig te implementeren. Ook kan productin-
formatie op een gedifferentieerde wijze ingezet worden voor
wereldwijde marketing. Via autorisaties voor bepaalde selecties is
ook daar genuanceerd mee om te gaan.
• Een organisatie die op componentniveau versiebeheer en auteurs-
bevoegdheden weet te regelen, kan daarmee de kwaliteit van haar
informatie en de efficiency van haar beheerprocessen drastisch
verbeteren.
• Een organisatie kan relatief snel nieuwe elektronische diensten via
elektronische media ontwikkelen en daarmee tegemoet komen aan
de wens van nieuwe (typen) klanten en het aanbod van bepaalde
leveranciers (bijvoorbeeld persbureaus die hun materiaal in de
vorm van XML aanbieden).
• Een organisatie kan verschillende bedrijfsonderdelen integreren.
Het uitwisselen van gestructureerde documenten is de lijm die dat
mogelijk maakt. Vooral bij mediabedrijven waar alles draait om
digitaal informatiemateriaal kan zo een integratie ingrijpend zijn.
Bijvoorbeeld bij de omslag van kanaalgeoriënteerde business units
naar een multimediaal bedrijf.
• Een organisatie kan haar core business herdefiniëren, bijvoorbeeld
van uitgever van bepaalde media naar expertisecentrum in
bepaalde kennisdomeinen.
• Een organisatie kan aan ketenintegratie binnen haar bedrijfstak
gaan doen; het applicatieneutraal kunnen uitwisselen van gestan-
daardiseerde berichten is daar namelijk een voorwaarde voor.
• Een organisatie die als eerste relevante en geaccepteerde docu-
mentschema’s voor haar bedrijfstak weet te ontwikkelen heeft de
mogelijkheid om de inrichting van die bedrijfstak te beïnvloeden in
een voor haar gunstige richting. Zo loopt Reuters met zijn
NewsML voorop in de news business.

19

Oude situatie: kanaalgeoriënteerde bussiness units

Nieuwe situatie: geïntegreerd multimediaal bedrijf

2.3 Overweging
Bedrijven en andere organisaties kunnen op verschillende manieren
innoveren. Het hangt van de karakteristiek van de omgeving af welke
manier het meest passend is. We onderscheiden een statische, een dyna-
mische en een turbulente omgeving.

2.3.1 STATISCHE OMGEVING
Voor een organisatie die opereert in een statische en daarmee stabiele
omgeving zal het optimaliseren van de winst en/of het vergroten van de
efficiency de belangrijkste drijfveer voor innoveren zijn. Het innoveren
is dan vooral gericht op het productieproces en minder op de producten
en diensten zelf.
Een organisatie waarbij een productieproces zelf uit informatie-
verwerking bestaat, kan haar kosten verlagen door informatie meer
geschikt te maken voor een tweede leven. Een gegevensbestand dat niet
alleen de tekst van een boek bevat, maar daartussen door eindeloos veel
opmaakinstructies, is nauwelijks opnieuw te gebruiken voor een andere
opmaak. Scheiden van inhoud en presentatie, i.c. de opmaakinstructies,
is dan het recept. Voor het vastleggen van de inhoud is XML een

20

geschikt hulpmiddel. Als in de opmaakinstructies een patroon te ont-
dekken is, kan met hulpmiddelen zoals XSL een XML-document auto-
matisch geconverteerd worden naar een bestand met tekst+opmaak. Als
in de opmaakinstructies geen vast patroon zit, kan het nodig zijn om de
wensen ten aanzien van de presentatie wat bij te stellen zodat dat
patroon er wel is. Automatisch een XML-document converteren naar
tekst+opmaak is namelijk alleen mogelijk als er volgens vaste regels van-
uit de structuur van het XML-document te bepalen valt welke opmaak
gewenst is.
Dit kan betekenen dat de bestaande presentatie voor een product
wat aangepast moet worden. Om automatisch vanuit XML opmaak te
kunnen genereren dient alle opmaak te worden gebaseerd op regels die
door de structuur worden bepaald.
Het scheiden van inhoud en presentatie voorkomt ook kostbare
conversies wanneer oude applicaties of systemen niet langer beschikbaar
zijn. Het omzetten van een multimediatitel van Cd-i naar DVD is bij-
voorbeeld “met de hand” onbegonnen werk. Als het bronmateriaal voor
de Cd-i destijds mediumneutraal was opgeslagen was dat gemakkelijker
geweest. In dat geval was er destijds eenmalig een script nodig voor het
automatisch omzetten van mediumneutraal materiaal naar Cd-i. Recent
zou er opnieuw eenmalig een script nodig zijn geweest voor de omzet-
ting van mediumneutraal bronmateriaal naar DVD. Voor een toekom-
stig en nu nog onbekend medium is dan opnieuw slechts een aangepast
script nodig om mediumneutraal bronmateriaal automatisch te kunnen
converteren.

2.3.2 DYNAMISCHE OMGEVING
Voor veel organisaties zal de omgeving geleidelijk aan veranderen. Een
organisatie zal zichzelf niet uit de markt willen prijzen en moet daarom
mee veranderen. Voor een informatieverwerkend productieproces gaat
het er daarbij om voorwaarden te creëren om op tijd te kunnen innove-
ren: flexibel opslaan van informatie met het oog op hergebruik en/of
nieuwe media.
Zoals al eerder aangegeven is de scheiding tussen inhoud en pre-
sentatie cruciaal. De organisatie hoeft de inhoud dan maar éénmaal te
onderhouden. Die vormt de gemeenschappelijke basis voor verschil-
lende selecties en presentatievormen.
De selectiemogelijkheden die in de toekomst gewenst zijn, zijn nu
nog niet volledig te overzien. Om in de toekomst zo veel mogelijk opties
open te houden, moet nu de juiste balans gevonden worden tussen ener-
zijds gedetailleerd annoteren van het inhoudelijk materiaal en anderzijds
zuinig omgaan met de beschikbaar middelen, i.c. menskracht.

21

Automatisering kan dit proces nog efficiënter maken. Leg de
inhoud vast in XML-documenten. Die zijn namelijk automatisch te vali-
deren en relatief eenvoudig in andere presentatievormen om te zetten.
Een uitgever kan zo relatief eenvoudig de inhoud van een tijdschrift ook
op CD-ROM zetten of de inhoud van een adresboek volgens diverse
ingangen toegankelijk maken en publiceren. In feite legt een organisatie
daarmee de basis voor het later kunnen publiceren van nu vastgelegde
informatie naar op dit moment nog onbekende media.

2.3.3 TURBULENTE OMGEVING
De veranderingen in de omgeving van een organisatie kunnen zo heftig
en grillig zijn dat ze haast niet meer te overzien zijn en als chaos overko-
men. Er zijn telkens nieuwe producten en diensten nodig waarover via
steeds weer veranderende communicatiekanalen met zakenrelaties
gecommuniceerd wordt. Intussen treden ook verschuivingen binnen
bedrijfstakken op en is recent een geheel nieuwe bedrijfstak ontstaan: de
internetindustrie.
In zo een turbulente omgeving is het op het juiste moment benut-
ten van nieuwe business opportunities bepalend voor het voortbestaan.
Dit vraagt om een stroom van productinnovaties die elkaar veel sneller
dan voorheen moeten opvolgen. Het assortiment wordt groter, de tijd
dat een product op de markt is wordt kleiner. Bovendien zorgt mass cus-
tomisation, het leveren van op de klant toegesneden producten tegen een
op massaproductie gebaseerde prijs, voor steeds kleinere seriegroottes.
Dit alles geldt zowel voor materiële producten als voor informatiepro-
ducten en diensten. Voor alle complexere producten geldt bovendien
dat de hoeveelheid technische documentatie rond ontwikkeling, produc-
tie, marketing, gebruik en onderhoud van die producten zal exploderen.
Er komen telkens nieuwe interactieve media beschikbaar zoals
chatsessie, elektronisch discussieforum, e-mail, i-mode, netmeeting,
sms, video conference, voice response, wap, webformulier, webpagina.
Zakenrelaties zullen die willen gebruiken. Daarnaast blijven de
bestaande communicatiekanalen als antwoordkaart, balie, billboard,
brief, direct mail, fax, folder, inspectiebezoek, loket, ontmoeting, publi-
catie, radio, telefoon, teletekst, televisie, winkel en workshop ook
bestaan. Organisaties zullen een verantwoorde mediamix proberen
samen te stellen en periodiek gaan aanpassen. Ook wordt de coördinatie
van al die kanalen, het multi channel management, belangrijker. Informa-
tie over nu eens mailende en dan weer telefonerende klanten zal toch
ergens bij elkaar moeten komen.
Het elektronisch zaken doen is in opkomst. Het maakt wereldwijd
zaken doen mogelijk (meer potentiële leveranciers, meer afnemers, meer

22

omzet) en kan intern tot een kostenbesparing leiden. Het vraagt er wel
om dat bepaalde diensten volcontinu beschikbaar zijn.
Van de hele organisatie vraagt dit alles om permanente verande-
ring en voortdurend leren. Wat ICT betreft zullen applicaties meer dan
voorheen met elkaar moeten kunnen samenwerken, óók over de organi-
satiegrenzen heen. Dat betekent standaardiseren, wat haaks kan staan
op het zo nodige flexibiliseren.
Organisaties die al langere tijd elektronische relaties met zaken-
partners onderhouden doen dat veelal via EDI. Dit gestandaardiseerd
berichtenverkeer vormt in een turbulente omgeving een te star keurslijf.
Voor nieuwe, kleine marktpartijen is EDI te duur. Voor zakendoen in
een netwerkeconomie is het te beperkt.
XML kan al deze ontwikkelingen ondersteunen:
• XML is bij uitstek een hulpmiddel om complexe informatie (zowel
informatieproducten als productinformatie) van een voor compu-
ters herkenbare structuur te voorzien;
• XML maakt het mogelijk om digitale communicatiekanalen te
baseren op gemeenschappelijke informatie die maar éénmaal hoeft
te worden gecreëerd;
• XML is een ideale basis voor gestandaardiseerde e-business docu-
menten, omdat XML-documenten moeiteloos via het Internet zijn
op te vragen en te transporteren.

2.4 Conclusie
Voor organisaties die opereren in een statische omgeving hoeft de inzet
van XML niet veel meer consequenties te hebben dan de invoering van
een andere al dan niet in huis ontwikkelde technische standaard. De
organisatie kan snel ervaring opdoen. De effecten van de verandering
zijn lokaal, dus veel risico’s loop je niet. Een nadeel is weliswaar dat je
niet vanuit een heldere toekomstvisie opereert en tamelijk incrementeel
te werk gaat. Na elk project volgt wel weer een volgend project. De uit-
komsten daarvan kunnen weer gevolgen hebben voor eerdere projecten
en een nieuwe conversieslag nodig maken. Het is daarom raadzaam om
bij het opstellen van documentschema’s eerder gebruik te maken van
bestaande schema’s en de daarin “gestolde” kennis en ervaring van
anderen dan zelf weer het wiel te gaan uitvinden.
In een dynamische en zeker in een turbulente omgeving is de inzet
van XML van strategisch belang. Onder deze omstandigheden kan een
uitgebreid XML-traject een organisatie maken of breken. XML biedt de
basis om:
• de informatie-explosie binnen organisaties beheersbaar te maken;
• met meerdere digitale communicatiekanalen te gaan werken;

23

• geheel diverse computerapplicaties via de uitwisseling van gestan-
daardiseerde berichten met elkaar te laten samenwerken.
Het strategisch belang van XML houdt ook in dat de geschetste inzet
van XML strategische risico’s met zich mee kan brengen. De strategi-
sche aanpak staat of valt met een heldere en gedeelde toekomstvisie. Dat
is iets anders dan een snel geformuleerde groeifantasie. Het ontwikkelen
van een heldere en gedeelde toekomstvisie is niet gemakkelijk. Een
andere voorwaarde voor succes is dat de organisatie klaar moet zijn voor
een ingewikkeld en ingrijpend verandertraject. De juiste competenties
moeten ontwikkeld zijn. Ten slotte moet ook de omgeving er klaar voor
zijn. Als de zakenrelaties nog niet zo ver zijn dat zij de juiste aansluiting
kunnen vinden op de nieuwe ontwikkelingen, creëer je als het ware een
hogesnelheidstrein die de eerste jaren over bestaand spoor moet blijven
rijden. Of dat de juiste keuze is, valt hier niet zomaar te zeggen. Belang-
rijk is wel, dat het een bewuste keuze is.

Tabel 2.1: Technische standaard of strategische technologie
Afweging Omgeving Voordelen Nadelen
Technische standaard Statisch Snel ervaring opdoen Incrementeel te werk
gaan, dus later opnieuw
converteren
Strategische technolo- Dynamisch of turbulent Diepte-investering van- Een heldere en
gie uit een heldere toe- gedeelde toekomstvisie
komstvisie is niet gemakkelijk te
formuleren

Eigen competenties zijn
hiervoor misschien nog
onvoldoende ontwik-
keld
Bedrijfsonderdelen en/
of zakenrelaties ver-
schillen sterk in hun
ontwikkeling op dit
gebied

Benodigde standaards
zijn hiervoor misschien
nog onvoldoende ont-
wikkeld

24

3 Innoveren met XML: bottom-up
of top-down?

Organisaties blijken vrij spontaan met
innovatie bezig te zijn. Dat gebeurt op
initiatief van decentrale managers en
zonder veel bemoeienis van de top
(bottom-up). Het kan ook anders, als
een door de top geïnitieerd en gestuurd
verandertraject (top-down). Ook inno-
veren met XML kan zowel bottom-up
als top-down plaatsvinden. Vaak gaat
een periode van spontaniteit vooraf
aan het moment waarop elektronisch
zaken doen en het belang van stan-
daards op de agenda van het topma-
nagement staat.

3.1 Bottom-up
Het is heel gebruikelijk dat in grote organisaties op tal van plaatsen en
vaak zonder dat men het van elkaar weet innovatieve trajecten op ICT-
gebied gestart worden, met inbegrip van XML-trajecten. Decentrale
managers hebben altijd wel wat speelruimte en budget om dit soort
zaken aan te pakken. Veelgehoorde motiveringen zijn: flexibiliteit, snel-
heid, experimenteel karakter, praktijkervaring opdoen, proeftuin en
pilot. Soms nemen ICT -afdelingen in dit stadium het initiatief. Soms
blijven ICT-afdelingen juist geheel buiten spel.
De geschetste tamelijk spontane aanpak heeft een aantal voor- en
nadelen. Als innoveren niet voorbehouden is aan een enkele afdeling,
maar door de hele organisatie plaatsvindt, is dat op zich een goede zaak.
Het ideaal van een lerende organisatie lijkt daarmee bereikt. Een lokale
manager kan zonder veel bureaucratische rompslomp een XML-traject
starten. Het budget is beperkt, de impact ook. Er kan veel geleerd wor-
den en niet zo veel echt misgaan.

25

Toch kleven er aan de bottom-up aanpak ook een aantal nadelen.
Allereerst dreigt er het gevaar van hobbyisme. Het is voor de betrokken
managers soms aantrekkelijker om een aardige website voor de afde-
lingsdatabase plus aanverwante rekenmodulen te (laten) bouwen, dan
een webservice te ontwikkelen die vanuit websites of applicaties van
andere instanties geactiveerd wordt. Vanuit het belang van de organisa-
tie is dat laatste misschien wel harder nodig. Ook als experiment om van
te leren kan die webservice interessanter zijn.
Als meerdere onderdelen van de organisatie extern gerichte initia-
tieven nemen, gaat de eenheid van optreden naar buiten verloren. Ook
het beheer van de innovatie kan beneden de maat zijn. De oorzaak hier-
van kan zijn dat het innoverende onderdeel niet over de kennis van
zaken of de middelen beschikt om het beheer goed aan te pakken, of dit
simpelweg niet als zijn taak ziet.
Het leren van de ervaringen wordt vaak niet systematisch aange-
pakt. Er zijn weinig contacten met andere innoverende onderdelen. De
organisatie heeft ook nauwelijks overzicht over welke initiatieven er alle-
maal lopen. Ongetwijfeld zullen ook af en toe lokale initiatieven een
financiële uitglijder maken.
De tekortkomingen die de bottom-up aanpak kan hebben zijn
enigszins te compenseren door op decentraal niveau voor voldoende
sturing te zorgen:
• bevorderen dat er adequate besluitvorming plaatsvindt vóórdat
een lokaal initiatief start;
• borgen dat er van de ervaringen geleerd wordt en dat ook andere
instanties (binnen de organisatie) van die lessen kunnen profite-
ren;
• bij gebleken succes van de decentrale initiatieven samen met geest-
verwanten de aandacht vragen van de “opinion leaders” van het
topmanagement én van mogelijke veranderingsmanagers zodat
mogelijk besloten wordt tot een top-down benadering.

3.2 Top-down
Innoveren met XML kan ook door het topmanagement geïnitieerd wor-
den. Het kan daarbij om een grote verandering gaan of om een beperkte
verandering.
Voordelen van de top-down gestuurde verandering is dat het top-
management er borg voor kan staan dat de innoverende acties passen
binnen de uitgezette strategische visie en andere beleidskaders van de
organisatie. Het centrale initiatief kan ook leiden tot schaalvoordelen,
bijvoorbeeld door de aanwezige expertise te bundelen.

26

De top-down aanpak heeft ook nadelen. De organisatie kan er nog
niet rijp voor zijn, er zijn teveel onzekerheden om met een blauwdruk te
werken, de financiële risico’s worden te groot. Om de nadelen te com-
penseren kan een organisatie op centraal niveau bekijken hoe decentrale
innovaties het beste opgezet kunnen worden. Ook kan het centrale
niveau stimuleren dat het decentrale niveau innoveert en experimenteert
en dat bij gebleken succes het centrale niveau de resultaten adopteert en
bijvoorbeeld uitbouwt tot een volwaardige nieuwe dienst. Daarnaast kan
het centrale niveau natuurlijk ook zelf het initiatief nemen tot concrete
pilots.

3.3 Overweging
Of innoveren met XML een spontane/decentrale of een gestuurde/cen-
trale aangelegenheid is, hangt vooral af van de agenda van het topma-
nagement. Komen daar zaken aan de orde als een e-businessstrategie en
het belang van standaardisatie, of niet?
Zolang het topmanagement onvoldoende op de hoogte is van
elektronisch zaken doen en het belang van internationale standaardisatie
daarbij, zullen deze zaken geen reguliere agendapunten worden. In dat
stadium is er veel ruimte voor spontane initiatieven en een bottom-up
benadering.
Staat elektronisch zaken doen inmiddels op de agenda, dan bete-
kent dat nog niet meteen groen licht voor een centrale top-down aan-
pak. Het kan zijn dat de nodig geachte aanpak grote organisatorische en
financiële risico’s kent. Een centrale aanpak wordt dan vooralsnog afge-
wezen. Zodra het management overtuigd is van de voordelen van een e-
business strategie en het werken met internationale standaards en bereid
is om eventuele weerstanden in de organisatie te overwinnen, is een cen-
trale aanpak mogelijk. Ongetwijfeld blijft er daarnaast ook ruimte voor
decentrale initiatieven. Die zullen zich dan wel moeten voegen naar de
nieuwe centrale kaders.

3.4 Conclusie
Zolang het topmanagement van een organisatie geen duidelijk stand-
punt over XML heeft ingenomen, zijn spontane initiatieven voor inno-
veren met XML in principe positief te waarderen. De impact en het
budget zijn beperkt en een dergelijk initiatief is doorgaans zonder veel
schade terug te draaien. Eventuele nadelen kan het topmanagement
ondervangen door wat centrale spelregels vast te stellen voor dit soort
experimenten.

27

Zodra elektronisch zaken doen, standaardisatie en daarmee het
belang van XML onderwerpen op de agenda van het topmanagement
zijn geworden, is van een gestuurde aanpak sprake. Het management
kan een duidelijke koers uitzetten voor de hele organisatie, maar ook kie-
zen voor lokale veranderingen. Het kan ook meer afwachtend zijn en de
decentrale managers kraamkamers laten inrichten voor diensten die dan
later door de centrale organisatie geadopteerd gaan worden.

Tabel 3.1: Bottom-up of top-down?
Afweging Agenda Voordelen Nadelen
Bottom-up Geen issue Geen grote risico’s Weinig eenheid van
optreden naar buiten
Flexibel Beheer vaak niet gere-
geld

Experimenteerruimte Leren vaak niet georga-
niseerd
Top-down Wel issue Afgeleid van visie Te vroeg beginnen

Schaalvoordelen Onvoldoende
deskundigheid

Consistent Grote financiële risico’s

28

4 Externe relaties: Ketens of
netwerken?

Organisaties zien hun relaties met de bui-
tenwereld soms als een keten of bedrijfsko-
lom, soms als netwerken. Hun business
model bepaalt hun blik. Voor XML-trajec-
ten is dit onderscheid relevant.

4.1 Ketens
Veel organisaties zien zichzelf als onder-
deel van een keten van aan elkaar leve-
rende bedrijven die samen een bedrijfs-
kolom vormen. Via supply chain mana-
gement of ketenintegratie, proberen zij
de verschillende schakels in die keten
beter op elkaar af te stemmen. Dat levert efficiencyvoordelen op én een
betere dienstverlening aan de uiteindelijke afnemers.
Ketenintegratie is op vier verschillende niveaus te realiseren:
1. Fysieke integratie
Fysieke integratie heeft betrekking op het goederentransport tus-
sen twee organisaties. Hulpmiddelen hierbij zijn bijvoorbeeld rol-
containers die door meerdere organisaties in een keten gebruikt en
aan elkaar uitgeleend worden.
2. Informatie-integratie
Bij informatie-integratie gaat het om het berichtenverkeer tussen
twee organisaties. Als dit goed wordt aangepakt kan dit verkeer
elektronisch verlopen en wel zodanig dat de ontvangende partij de
informatie automatisch kan verwerken en niet opnieuw hoeft in te
voeren.
3. Besturingsintegratie
Besturingsintegratie heeft betrekking op het automatisch uitwisse-
len van besturingsinformatie tussen verschillende organisaties.
Hiermee is het mogelijk om de besturing van de hele keten sneller
te laten verlopen en daarmee de service aan de afnemer te verho-

29

gen. Zo kan een afnemer zijn wisselende magazijnvoorraad aan de
betreffende leverancier laten zien. Het blijft echter de eigen verant-
woordelijkheid van elke organisatie om met deze informatie al dan
niet iets te doen.
4. Organisatorische integratie
Bij organisatorische integratie gaat de ene organisatie de andere
organisatie gedeeltelijk besturen. Een leverancier wordt bijvoor-
beeld zelf verantwoordelijk voor de voorraadhoogte van zijn pro-
ducten in het magazijn van zijn afnemer. In het verlengde hiervan
liggen zaken als Just-in-Time productie en comakership.

De vier niveaus van ketenintegratie

Bij informatie-integratie, besturingsintegratie en organisatorische inte-
gratie levert geautomatiseerd berichtenverkeer een belangrijke bijdrage
aan de te behalen voordelen op het gebied van efficiency en klantenser-
vice. Om automatisch verwerkt te kunnen worden zijn die berichten
gestandaardiseerd. Omdat het om uitwisseling tussen verschillende in
principe autonome partijen betreft gaat het om extern vastgelegde stan-
daards.
Een technische oplossing die al enkele tientallen jaren bestaat is
EDI, Electronic Document Interchange. Organisaties gaan daarbij onder-
ling een overeenkomst aan om hun informatie in de vorm van gestan-

30

daardiseerde EDI-berichten via een value added network provider en
rechtstreekse datacommunicatielijnen daarmee uit te wisselen.
EDI voldoet vooral in het berichtenverkeer tussen vaste zaken-
partners die op een vaste wijze zaken doen. Vooral grote bedrijven
gebruiken EDI. Voor het midden- en kleinbedrijf is EDI nogal duur. De
investeringen in proprietary programmatuur en de diensten van het
rekencentrum dat als schakelpunt functioneert tikken aan. Een nadeel
van EDI is dat het weinig flexibel is. Ook zijn EDI-documenten in hun
oorspronkelijke vorm alleen door ingewijden te lezen.
XML knaagt aan de positie van EDI. Dat gebeurt overigens in alle
openheid. EDI standaardisatieorganen zijn zelf bezig om hun stan-
daards om te zetten naar XML en meteen een grote onderhoudsbeurt te
geven. XML is een open en gratis standaard, XML-documenten zijn
goedkoop en eenvoudig via het Internet te transporteren. Ook is XML
veel flexibeler aan te passen aan gewijzigde omstandigheden. Tenslotte
is XML voor iedereen beschikbaar. Elektronische documentuitwisseling
hoeft daarmee niet meer beperkt te blijven tot een klein gezelschap van
vaste zakenpartners.
Vanwege de hoge investeringen in het verleden zijn grote bedrij-
ven niet al te happig om EDI los te laten en op XML over te schakelen.
Ook interne EDI-experts en in EDI gespecialiseerde dienstverleners
lopen niet te juichen. Toch blijkt bij nieuwe projecten de keuze steeds
meer op XML te vallen. Voor het midden- en kleinbedrijf is XML zon-
der meer een aantrekkelijker optie.

4.2 Netwerken
Haaks op het beeld van de goed gecoördineerde en op vaste relaties
gebaseerde supply chain staat het beeld van de netwerkeconomie. Orga-
nisaties zien zichzelf daarin als een onderdeel van een wereldwijd net-
werk. Dankzij het Internet kan in principe de hele wereld je leverancier
zijn. Ook je afnemers zitten overal en hoeven niet per se een vaste relatie
met je te hebben. Elektronisch zaken doen heeft de toekomst.
Hoe het elektronisch zaken doen gaat functioneren is nog niet
geheel duidelijk. Verschillende business models zijn mogelijk. In onder-
staande figuur staan er vier afgebeeld:
1. één afnemer, één leverancier (kwadrant linksboven);
2. één afnemer, veel leveranciers (kwadrant rechtsboven),
3. veel afnemers, veel leveranciers (kwadrant rechtsonder),
4. veel afnemers, één leverancier (kwadrant linksonder).

31

Vier bedrijfsmodellen voor electronisch zaken doen

In de praktijk zijn voorbeelden van alle vier de modellen te vinden. Het
is zeker niet vanzelfsprekend dat één van deze modellen zal gaan domi-
neren. Het is zelfs denkbaar dat de modellen oplossen en er een alge-
mene variant van de elektronische markt ontstaat die zo groot is als het
hele Internet en geen centrale instantie meer nodig heeft.
Een organisatie die goed wil functioneren in de netwerkeconomie
zal zich moeten voorbereiden op het kunnen functioneren volgens elk
van de vier aangeduide modellen. Dat stelt hoge eisen aan de interne
organisatie.
Het nut dat XML kan hebben als de enabler van gestandaardiseerd
berichtenverkeer via het Internet lijkt ons evident. Maar XML alleen is
niet genoeg. Er is een hele stapel van XML-toepassingen nodig om e-
business mogelijk te maken:
• de filosofie van het elektronisch zaken doen zoals bijvoorbeeld
neergelegd in ebXML;

32

• de wijze van opbouwen van business directories met daarin een
verwijzing naar zogeheten webservices zoals omschreven in de
UDDI-standaard en uitgevoerd door UDDI-servers;
• het beschrijven van de webservices op basis van WSDL;
• het daadwerkelijk aanroepen van webservices op basis van SOAP.
Met deze opsomming is een generieke aanpak gegeven. Per bedrijfstak
zullen vaak specifieke standaards gewenst zijn die voortbouwen op de
generieke. Een consortium of een brancheorganisatie neemt hiertoe
doorgaans het initiatief. Materiedeskundigen bereiden de functionele
kant van de standaard voor: een aantal collectieve noties over het toepas-
singsgebied. Informatiedeskundigen richten zich op de technische kant
ervan: de specificatie van de XML-documentschema’s. Terwijl dat pro-
ces gaande is zullen ook de generieke standaards zich verder ontwikke-
len.

Voorbeeld van een UDDI-transactie

4.3 Overweging
Of een organisatie haar relaties met de buitenwereld ziet als een keten of
als een netwerk hangt van het gehanteerde business model af. Is dat
business model stabiel en gaat het uit van een stabiele bedrijfskolom,
dan verdient de ketenbenadering de voorkeur. Heeft het business model

33

zijn vorm nog niet gevonden, of gaat de organisatie uit van meerdere
business models dan is een netwerkbenadering vruchtbaarder.
De ketenbenadering heeft als nadeel dat een organisatie relatief
traag zal reageren op nieuwe kansen op het gebied van elektronisch
zaken doen. Daar staat tegenover dat ze haar bricks and mortar proces-
sen op orde kan hebben. Het nadeel valt te compenseren door voor een
gedeelte van de inkoop (en daarmee voor een deel van de leveranciers)
en voor een deel van de verkoop (en daarmee voor een deel van de afne-
mers) tóch van een netwerkbenadering uit te gaan. Terwijl de kracht van
de ketenbenadering optimaal benut wordt, bouwt een organisatie dan
toch de competenties op die in een later stadium onmisbaar kunnen blij-
ken.
De netwerkbenadering heeft als nadeel dat nog onduidelijk is
welke business models op den duur het meest relevant zullen zijn. Een
organisatie moet zich daarom op meerdere modellen prepareren en dus
op meerdere paarden tegelijk wedden. Dat is kostbaar. Het nadeel van
deze kostbare netwerkbenadering valt te compenseren door samen te
werken met organisaties die in hetzelfde schuitje zitten.
Overigens kunnen grote organisaties onze beschouwing over
ketens en netwerken niet alleen toepassen op hun externe relaties, maar
ook op de interne relaties.

4.4 Conclusie
Als een organisatie vooral hecht aan het efficiënter en meer klantgericht
maken van de productie, dan verdient de ketenbenadering de voorkeur.
Om toch te anticiperen op een ongewisse toekomst is het verstandig om
daarbij op kleine schaal een netwerkbenadering toe te passen.
Voor organisaties die vooral op de nieuwe economie gericht zijn, is
de netwerkbenadering het meest adequaat. De hoge kosten bij het anti-
ciperen op meerdere business models kunnen via samenwerkingsver-
banden gedeeld worden.

Tabel 4.1: Ketens of netwerken?
Afweging Business model Voordelen Nadelen
Ketens Vaste relaties Efficiënt Minder flexibel bij
opkomende nieuwe
business models
Klantenservice
Netwerken Wisselende relaties Flexibel Kostbaar standpunt
voor een afzonderlijke
organisatie

34

5 Focus van XML: Techniek of
organisatie?

Afhankelijk van het vertrekpunt en het
ambitieniveau is een XML-traject voor
een organisatie vooral een technische of
een organisatorische uitdaging.

5.1 Techniek
Organisaties die een XML-traject
vooral zien als een technische onder-
neming kunnen doorgaans terug-
vallen op hun kennis en kunde van
reguliere automatisering. Ook voor
het XML-traject heb je dan de keus
uit tientallen ontwikkelmethoden en
bijbehorende geautomatiseerde ge-
reedschappen.
Toch is ook reguliere automa-
tisering niet zonder problemen.
Vooral de stroom aan nieuwe ontwikkelingen op de markt zorgt voor
verwarring. Nauwelijks is een organisatie vertrouwd met een nieuwe
ontwikkelomgeving of de wereldwijde belangstelling daarvoor verflauwt
en richt zich op een nieuwe belofte. Het blijft moeilijk om in een wereld
vol verandering de hypes en de trends te onderscheiden en niet te vroeg,
maar ook niet te laat over te stappen op andere technische oplossingen.
Belangrijke ontwikkelingen op het gebied van systeemontwikke-
ling zijn op dit moment:
• Platformdiscussie .Net versus J2EE;
• Webservices ontwikkeling m.b.v. UDDI, WSDL, SOAP;
• Enterprise application integration.
Bovendien is een XML-traject niet in alle opzichten regulier te noemen.
Afwijkend is in het bijzonder dat de structuur van XML-documenten
veel complexer kan zijn dan die van een relationele database. Verder is
bij relationele databases de wijze waarop de logische structuur van een

35

database wordt vertaald naar de fysieke structuur voor iedere imple-
mentatie vergelijkbaar. Voor de vertaling van de logische structuur van
XML-documenten naar de fysieke structuur van de onderliggende
database is dat niet zo eenduidig. Iedere aanbieder op de markt van
XML-databases heeft daar zo zijn eigen ideeën over. Een ongelukkige
keuze op dit punt kan in een later stadium voor veel problemen zorgen,
m.n. op het gebied van de performance.

5.2 Organisatie
Een XML-traject kan vele niet-technische implicaties hebben, zowel
voor een organisatie intern als voor haar relaties met de buitenwereld.
Voor organisaties kan dat reden zijn om een XML-traject niet zo zeer te
zien als een technische onderneming, maar vooral als een organisatie-
verandertraject. Ter illustratie beschrijven we hier mogelijke organisato-
rische implicaties van een XML-traject.

5.2.1 RELATIE TOT DE OMGEVING
Naar buiten gerichte XML-trajecten kunnen leiden tot een betere
dienstverlening door het toevoegen van extra communicatiekanalen.
Over het algemeen zien organisaties die als aanvulling op en niet als ver-
vanging van bestaande communicatiekanalen. Een aandachtspunt hier-
bij is de digital divide, de digitale tweedeling van burgers, bedrijven,
instellingen en overheidsinstanties mét toegang tot moderne ICT en
zónder dergelijke toegang.
Wat verder van belang is, is de afbakening van de grenzen tussen
organisaties en de zichtbaarheid daarvan voor de buitenwereld. Een
zelfstandige website kan zorgen voor een sterke herkenbaarheid, maar
een bescheidener plek binnen een portal of, nog bescheidener, het op
basis van syndication aanleveren van informatie aan de website van een
ander verleent de afnemer misschien een betere dienst, maar vermindert
de herkenbaarheid van de leverancier. Ook is het denkbaar dat in de
reguliere bedrijfskolom extra intermediairs verschijnen en andere inter-
mediairs verdwijnen.

5.2.2 ORGANISATIESTRUCTUUR
Een organisatie die inzet op een ontwikkeling richting elektronisch
zaken doen zal veel meer procesgeoriënteerd worden. Dat zal doorwer-
ken in de organisatiestructuur. Een populaire aanpak is bijvoorbeeld die
van een frontoffice, midoffice en backoffice. Het frontoffice onderhoudt
alle contacten met de buitenwereld, het backoffice verzorgt de afwikke-
ling waarbij geen rechtstreeks klantcontact nodig is en het midoffice

36

zorgt onder meer voor channel management en werkt als schakelstation
tussen frontoffice en backoffice.
De organisatie wordt transparanter. Informatie voor management
en medewerkers is gemakkelijker te verkrijgen dan voorheen. Managers
hoeven niet meer persoonlijk ervoor te zorgen dat allerlei informatie van
het ene niveau in de organisatie op het andere niveau belandt.
Het kennen van de doelgroepen gaat nog meer nadruk krijgen dan
voorheen. Dat kan een aanpassing van de positie van “marketing &
sales” nodig maken.

5.2.3 PROCESSEN
Omdat de buitenwereld zelf een keuze kan maken uit de aangeboden
communicatiekanalen is multi channel management nodig. Via alle kana-
len moet een organisatie immers identieke informatie verstrekken.
Bovendien moeten handelingen die via het ene kanaal zijn opgestart,
desgewenst via een ander kanaal kunnen worden afgerond.
Een deel van de bedrijfsprocessen zal herontworpen moeten wor-
den om ze geschikter te maken voor elektronisch zaken doen (bijv. ver-
minderen en concentreren van de handmatige bewerkingen).
Stapelgewijs georganiseerde bedrijfsprocessen zullen omgezet
moeten worden in transactiegewijs georganiseerde. Een opdracht wordt
niet meer op een stapel gelegd en met stapel en al naar de volgende
afdeling verplaatst. In plaats daarvan is het streven naar het meteen
afhandelen van een complete transactie ook als daar verschillende afde-
lingen bij betrokken zijn.

5.2.4 MEDEWERKERS
Herschikkingen binnen de bedrijfskolom leiden ook tot herschikkingen
van de bijbehorende werkgelegenheid. Los daarvan zal globaal gezien
het eenvoudige administratieve werk verminderen, terwijl de meer com-
plexe administratieve functies breder en/of rijker worden. Als de organi-
satie voor de buitenwereld transparanter en efficiënter wordt, wordt ze
dat ook voor de eigen medewerkers (vandaar dat zij soms ook tot de bui-
tenwereld gerekend worden). Door (mobiel) telewerken vervaagt de
grens tussen werk en vrije tijd. Aandachtspunt is ook hier de digital
divide: de tweedeling van het personeelsbestand in ICT -vaardigen en de
rest.

5.2.5 ORGANISATIECULTUUR
De buitenwereld komt naar binnen en de binnenwereld wordt transpa-
ranter. Als de organisatie met eigen virtuele loketten werkt, kan de iden-
titeit versterkt worden. Bij het gebruik van de loketten van andere
organisaties word je juist minder zichtbaar.

37

5.2.6 INFRASTRUCTUUR
De capaciteit en continuïteit van de ICT -infrastructuur en de beveiliging
ervan worden nog belangrijker dan ze al zijn. Internettechnologie zal de
ruggengraat worden van intern en extern gegevenstransport. Integratie
van applicaties vindt plaats via standaard berichten. Applicaties worden
vernieuwd en eerder procesgeoriënteerd dan afdelinggeoriënteerd. Ze
gaan transactiegewijs in plaats van batchgewijs te werk.

5.2.7 HUISVESTING
Waar het werk plaats vindt, wordt steeds minder van belang. Telewerken
kan niet alleen thuis, maar in feite overal.

5.2.8 FINANCIËN
Een ontwikkeling richting elektronisch zaken doen vraagt forse investe-
ringen met flinke afbreukrisico’s. In de exploitatiesfeer zijn bij een goede
aanpak efficiencywinsten te boeken. Bij een minder goede aanpak kun-
nen de exploitatiekosten gigantisch oplopen.

5.3 Overweging
De afweging of een XML-traject vooral gezien moet worden als het
oplossen van een technisch probleem of als het uitvoeren van een orga-
nisatieverandering hangt van twee zaken af: de uitgangspositie en het
ambitieniveau.
De huidige situatie binnen de organisatie is het vertrekpunt voor
het XML-traject. Het maakt wat uit of de organisatie al klaar is voor
elektronisch zaken doen of dat er nog een hele weg te gaan is op dat
gebied. Hetzelfde geldt voor de technische infrastructuur. Als die de
vorm heeft van een eilandenrijk vallen er nog heel wat bruggen te bou-
wen. De organisatie kan dus zowel in technisch als in organisatorisch
opzicht voldoende of onvoldoende ontwikkeld zijn.
Behalve de uitgangssituatie is ook het ambitieniveau van het
XML-traject van belang. Streeft de organisatie een eindsituatie na die
organisatorisch op een hoger plan staat of vooral technisch?
In de praktijk blijkt het van belang om een eventuele achterstand
in de huidige situatie in te lopen vóór er aan nieuwe en verder reikende
ambities gewerkt gaat worden. Ook is het niet verstandig om tegelijker-
tijd een sprong voorwaarts te willen maken op technisch én op organisa-
torisch gebied.

38

5.4 Conclusie
Als de huidige situatie een achterstand vertoont op ofwel organisato-
risch, ofwel technisch terrein, krijgt dat terrein als eerste de focus. Is het
op beide terreinen mis, dan worden beide aangepakt, maar niet tegelijk.
Als de huidige situatie voldoende ontwikkeld is, volgt afhankelijk
van de geformuleerde ambitie een traject met de nadruk op organisatie
dan wel met de nadruk op techniek.

Tabel 5.1: Techniek of organisatie
Afweging Ambitie Voordelen Nadelen
Techniek Vooral technisch Stabiele infrastructuur Organisatie weet die
creeren maar gedeeltelijk te
benutten
Organisatie Vooral organisatorisch Lerende en flexibele Techniek blijft achter
organisatie creëren bij wat de organisatie
nodig heeft

39

6 Invoeren van XML: Project of
proces?

Organisaties kunnen een XML-ver-
andertraject op verschillende wijzen
aanpakken. Globaal gezien valt er te
kiezen tussen een aanpak als project
of een aanpak als proces. De afwe-
ging hangt af van organisatorische
condities.

6.1 Project
Bij een projectmatige aanpak van
een XML-verandertraject staat
het realiseren van een concreet
doel in een afgebakende periode
en met vooraf gealloceerde middelen (mensen en geld) centraal. Door-
gaans treedt één van de managers op als opdrachtgever voor een pro-
jectgroep, een tijdelijk werkverband. Zodra de projectgroep haar
opdracht vervuld heeft, draagt ze de resultaten over aan de staande
organisatie. De projectgroep kan dan ophouden te bestaan.
Een gangbare aanpak om projecten overzichtelijk en beheersbaar
te houden is het opsplitsen van de werkzaamheden in fasen. Fasen wor-
den na elkaar uitgevoerd. Elke fase eindigt met de oplevering van een
beslisdocument op basis waarvan de opdrachtgever décharge kan verle-
nen voor de uitgevoerde werkzaamheden en aanvullende beslissingen
kan nemen voor de volgende fasen.
Er bestaan tal van methoden voor systeemontwikkeling die elk een
specifieke projectindeling en aanpak voorstaan. Daarbij wordt voor zo
ver ons bekend geen aandacht besteed aan specifieke XML-aangelegen-
heden zoals:
• een genuanceerde make-or-buy afweging;
• contentanalyse;
• het modulair opzetten van documentschema’s;
• het converteren van bestaande informatie.

41

Wanneer een organisatie uitdrukkelijk één bepaalde ontwikkelmethode
als standaard heeft uitgeroepen, zal die ook voor een XML-traject zo
goed mogelijk gevolgd moeten worden. Wanneer een organisatie niets
voorschrijft op dit gebied, zal de keuze aan de projectgroep zijn. Hoe die
uitpakt, doet er niet zo veel toe. Het is belangrijker dát er een methode
gevolgd wordt, dan wélke methode dat zal zijn.
Op deze plaats volstaan we met een vrij generieke fase-indeling
van projecten. Ze bestaat uit:
1. initiatieffase;
2. definitiefase;
3. ontwerpfase;
4. realisatiefase;
5. implementatiefase;
6. gebruik en beheerfase.
Voor elke fase geven we kort aan wat de bedoeling is en welke zaken spe-
cifiek van belang zijn bij XML-trajecten.

6.1.1 INITIATIEFFASE
De initiatieffase is de aanloopfase tot een project. Feitelijk is er dan nog
geen sprake van een project.
Voor XML-trajecten is het verstandig om in deze fase de afweging
te maken tussen enerzijds een projectmatige aanpak en anderzijds een
procesmatige aanpak. Valt de keuze op een projectmatige aanpak, dan
verdient het aanbeveling om de tekortkomingen daarvan door enkele
aanvullende maatregelen te compenseren (zie later).

6.1.2 DEFINITIEFASE
De definitiefase bestaat uit de analyse van het voorliggende probleem en
het definiëren van wat wél en wat níet de bedoeling van het project is.
Deze activiteit wordt ook wel de haalbaarheidstudie genoemd.
Het resultaat van de definitiestudie is niet alleen dat er een dege-
lijke probleembeschrijving ligt, maar ook dat er verschillende globale
oplossingsrichtingen (systeemconcepten) zijn bedacht en afgewogen.
De architectuur van de oplossing ligt in grote lijnen vast (bijvoorbeeld
een uitgeefstraat, een portal, een content management system).
Bij XML-trajecten is de make-or-buy beslissing belangrijk. Het
inkopen van specifieke expertise werkt doorgaans sneller en goedkoper
dan het gebruik maken van eigen expertise die eerst ontwikkeld moet
worden. Maar ook bij inkopen moet een organisatie tóch over een zekere
expertise in huis beschikken om deze inkoop in goede banen te kunnen
leiden. Naarmate het strategisch belang van het XML-traject voor een
organisatie groter is, is het belangrijker om in huis over eigen expertise
te beschikken.

42

6.1.3 ONTWERPFASE
Tijdens de ontwerpfase worden de concepten voor de uiteindelijke
oplossing ontwikkeld. Het gaat hier niet alleen om technische concep-
ten, maar ook om organisatorische (herontwerpen bedrijfsprocessen,
aanpassen organisatiestructuren).
Bij XML-trajecten is dit de fase waarin een content analysis plaats-
vindt en documentschema’s ontwikkeld worden. Belangrijk is daarbij de
vraag in welke mate de organisatie aansluiting zoekt bij al bestaande
documentschema’s, bijvoorbeeld van de eigen bedrijfstak of op het
gebied van elektronische handel als zodanig. Naarmate het strategisch
belang van het XML-traject voor een organisatie groter is, is het meer
gewenst om aan te sluiten bij bestaande standaards op dit gebied (of nóg
beter: invloed te hebben op het tot stand komen van die standaards).
Het ontwerpen van een XML-oplossing wordt wel vergeleken met
het ontwerpen van een datamodel voor een relationele database. Er zijn
inderdaad overeenkomsten, maar er zijn ook grote verschillen.
De overeenkomst zit in het feit dat een relationele database oplos-
sing vrij eenvoudig in een XML-oplossing is te vertalen. Het omge-
keerde is echter niet het geval. Een XML-documentschema kan
repeterende groepen van elementen bevatten; een relationeel datamodel
niet. Een XML-documentschema kan optionele elementen bevatten,
een relationeel datamodel niet.

6.1.4 REALISATIEFASE
Tijdens de realisatiefase vindt het daadwerkelijk bouwen van de oplos-
sing plaats. Dit kan ook het “verbouwen” van de organisatie inhouden.

6.1.5 IMPLEMENTATIEFASE
De implementatiefase betreft het in gebruik nemen van de oplossing en
het overdragen aan de staande organisatie. In deze fase vinden ook de
eventuele gebruikerstrainingen plaats.
Bij XML-trajecten moet in deze fase vaak een conversie van
bestaand materiaal plaatsvinden. Dat is vaak een project op zichzelf.

6.1.6 GEBRUIK EN BEHEERFASE
Tijdens de gebruik en beheerfase vindt het eigenlijke gebruik van de
oplossing plaats. Dat vraagt ook om beheer en onderhoud. Feitelijk is
het project dan al achter de rug.
Bij een XML-traject is het van belang dat helder is wie de docu-
mentschema’s gaat beheren en wat de procedure is om deze te wijzigen.
Een bruikbaar model is dat de materiedeskundigen adviseren over ver-
nieuwingen, maar niet er zelf over beslissen. Het management neemt de
beslissing en maakt daarbij de afweging tussen het belang van stabiele

43

schema’s en het belang van vernieuwen. De ICT-afdeling kan de aan-
passingen uitvoeren.

6.2 Proces
Bij een procesmatige aanpak van een XML-verandertraject ligt de
nadruk op de vele partijen die bij het traject betrokken zijn. De partijen
verschillen onderling in het belang dat ze bij het XML-traject hebben,
wat ook zijn weerslag heeft op de energie waarmee ze zullen meewerken.
Voor het slagen van een XML-traject is het belangrijk dat er tussen deze
partijen een coalitie tot stand komt en in stand blijft. De initiatiefnemer
levert doorgaans de procesmanager.
Bij een procesmatige aanpak is eerder sprake van een voorgeno-
men ontwikkelrichting dan van een concreet afgebakend en nauwkeurig
in de tijd aangegeven einddoel. Als er al een einddoel geformuleerd is,
dan kan dat tijdens de rit best gaan schuiven. Ook kunnen zich tijdens
de rit nog partijen bij het proces aansluiten of het proces verlaten. Par-
tijen in de vorm van verschillende organisaties zijn autonoom en niet
door een hoger gezag tot de orde te roepen. Zogenaamd “strategisch
gedrag” van partijen is bij een dergelijk proces niet ongewoon.
In het centrum van een procesmatig verandertraject staat de pro-
cesmanager. Deze is minder bezig met feitelijke veranderingen en meer
met de manier waarop die bereikt kunnen worden. De procesmanager
zorgt ervoor dat beslissingen in alle openheid en met ruimte voor ieders
inbreng genomen worden, dat de core values van de partijen gerespec-
teerd worden, dat er voldoende voortgang is en dat uitkomsten van het
traject van voldoende kwaliteit zijn.
Op deze plaats volstaan we met een vrij generieke opsomming van
mogelijke partijen bij een XML-traject:
• management;
• medewerkers;
• ICT-ers;
• partners;
• afnemers;
• leveranciers;
• de omgeving.
Vanuit het perspectief van elk van deze partijen geven we een korte
beschrijving van een mogelijk XML-traject.

6.2.1 MANAGEMENT
Voor het management is de huidige situatie misschien wel stabiel in
organisatorisch en technisch opzicht. Ze is echter niet efficiënt, onder
meer omdat de verschillende geautomatiseerde systemen niet op elkaar

44

aansluiten. Wil de organisatie in een turbulente omgeving kunnen over-
leven, dan zullen in ieder geval alle systemen onderling geïntegreerd
moeten zijn. Aandachtspunten voor het management zijn daarbij:
• het efficiënt laten verlopen van het XML-traject
Het proces moet in balans zijn. De organisatie moet veranderen
door vanuit een stabiel stadium naar een volgend stabiel stadium
te trekken.
• het beleggen van nieuwe functies
Een XML-traject kan een organisatie belasten met nieuwe zaken
die beheerd moeten worden: documentschema’s, multimedia
assets en de rechten daarop. Voor elk daarvan wachten de vol-
gende vragen op een antwoord. Wie gaat straks nieuw beleid voor
deze zaken ontwikkelen? Wie gaat ermee innoveren en experimen-
teren? Wie gaat ontwikkelwerk uitvoeren? Wie doet het beheer?
Wat wordt uitbesteed? Wie neemt de besluiten en wie ziet op de
uitvoering ervan?
• het oog hebben voor het toekomstige business model
• het verrichten van het nodige “zendingswerk”.

6.2.2 MEDEWERKERS
De medewerkers opereren in de huidige situatie wellicht minder effi-
ciënt en met ondermaatse informatie, dubbel werk en ambigue rollen.
Het werk zal na doorlopen van een XML-traject minder administratief
en meer kennisgericht kunnen zijn. Aandachtspunten voor medewer-
kers zijn hierbij:
• het XML-traject impliceert een organisatieverandering; dat brengt
onzekerheid met zich mee, behoefte aan inspraak en aan bijscho-
len voor een nieuwe of veranderende functie;
• het werk wordt minder gericht op het bijdragen aan een enkel pro-
duct en méér op het bijdragen aan herbruikbare content;
• het werk wordt minder gericht op complete documenten en meer
op onderdelen van documenten (componenten);
• een verandering van de organisatiestructuur ligt daarbij in de rede.

6.2.3 ICT-ERS
Een aparte categorie medewerkers wordt gevormd door de ICT-ers.
Informatiesystemen en de bijbehorende ondersteuning zijn nu nog vaak
verticaal georganiseerd. Ieder systeem heeft zijn eigen karakteristiek, de
daarbij behorende ICT-ers eveneens. In de toekomst is veel meer inte-
gratie tussen alle systemen nodig en zijn de systemen meer nog dan
tegenwoordig van vitaal belang voor de organisatie. Voor het tot een
goed einde brengen van een XML-traject is het daarom gewenst dat
ICT-ers zich in twee richtingen ontwikkelen. Ze moeten meer horizon-

45

taal weten te functioneren en ze moeten meer verstand krijgen van het
bedrijf in plaats van alleen van ICT.

6.2.4 AFNEMERS
Voor afnemers is een organisatie in de huidige situatie moeilijk aan te
spreken. Vaak moeten zij meerdere loketten benaderen en dezelfde
informatie meermalen verstrekken. In de toekomst zou dat één loket
moeten zijn dat aangepast is aan de klant en de organisatie transparant
maakt. Dat ene loket is echter wel met verschillende communicatiekana-
len aan te spreken. De afnemer voert nog maar eenmaal zijn gegevens in
en krijgt er een hoogwaardiger product voor terug.

6.2.5 LEVERANCIERS
Leveranciers communiceren in de huidige situatie via een beperkt aantal
verschillende kanalen met de organisatie. Tijdens een XML-traject
komt daar op een gegeven moment een op XML gebaseerd kanaal bij.
Vroeg of laat zullen daardoor een of meer andere kanalen verdwijnen.
De informatie-uitwisseling wordt rijker, vormen van ketenintegratie zijn
mogelijk. Daar staat tegenover dat ook steeds meer andere leveranciers
naar de gunsten van de organisatie kunnen dingen. Uiteindelijk resultaat
is een efficiënte e-commerce oplossing waarbij informatie- en bestu-
ringsinformatie zo veel mogelijk elektronisch worden uitgewisseld. De
externe communicatie is gestandaardiseerd waardoor “iedereen” kan
leveren.

6.2.6 CONTEXT
Een organisatie heeft rechtstreeks te maken met haar zogeheten transac-
tieomgeving (de omgeving waar ze daadwerkelijk zaken mee kan doen).
De rest van de buitenwereld noemen we hier simpelweg “context”.
Daar speelt zich bijvoorbeeld de standaardisatie van documentschema’s
af. De partij die dat regelt hoeft niet per se een nationale standaardorga-
nisatie te zijn. Allerlei brancheorganisaties of consortia kunnen als zo
danig optreden. Het kan voor een organisatie relevant zijn om ook deze
partij bij zijn procesmatige aanpak van een XML-traject te betrekken.
Via die partij is de discussie over de standaards te voeren en kunnen
eventueel aanpassingen worden aangekaart.

6.3 Overweging
Een XML-traject kan op een projectmatige of op een procesmatige
wijze aangepakt worden. De keuze hangt af van de aard van het veran-
dertraject. We zetten in onderstaande tabel twee karakteristieken tegen-
over elkaar.

46

Tabel 6.1: XML-verandertrajecten – twee karakteristieken
Verandertraject Karakteristiek A Karakteristiek B
Scope Klein deel van de organisatie Groot deel van de organisatie
Intern / extern Voornamelijk interne partijen Ook diverse externe partijen
betrokken betrokken
Autonomie Betrokken partijen maken deel Betrokken partijen zijn behoor-
uit van één groter geheel en lijk autonoom en kunnen bij-
hebben daardoor maar beperkte voorbeeld zelf beslissen of ze
autonomie nog langer wensen te participe-
ren.
Integratie Nog niet nodig, nieuwe oplos- Is nodig
sing naast bestaande oplossin-
gen
Snelheid Is belangrijk Is minder belangrijk
Doelstelling Ligt vast gedurende het traject Kan tijdens het traject verande-
ren

Bij XML-verandertrajecten die voldoen aan karakteristiek A ligt een
projectmatige aanpak voor de hand. Trajecten die overeenkomen met
karakteristiek B kunnen beter procesmatig worden aangepakt.
In de praktijk zullen XML-trajecten niet altijd zo mooi in één van
beide categorieën zijn in te delen. Het is dan gewenst om de meest opti-
male aanpak te kiezen en deze ter compensatie aan te vullen met
bepaalde elementen uit de andere aanpak.

6.4 Conclusie
Zolang er voornamelijk interne partijen bij een XML-traject betrokken
zijn die niet te veel autonomie hebben en de doelstelling concreet is, is
projectmatig werken de beste keus. Bij veel externe partijen, en vage of
verschuivende doelstellingen, verdient procesmanagement de voorkeur.
Een organisatie die kiest voor projectmanagement loopt risico’s in
de relatie met vooral externe partijen. Als het XML-traject gevolgen
voor hen heeft en zij onvoldoende betrokken zijn, levert dat vroeg of laat
problemen op. Om dit te voorkomen is het verstandig om in het project-
plan expliciet melding te maken van de betrokken stakeholders. In de
planning komt dan te staan hoe en op welk moment tijdens het project
met hen gecommuniceerd gaat worden en wat de aard is van die com-
municatie. Is het stikken of slikken? Wordt het project aan hen “ver-
kocht”? Worden er wat proefballonnen opgelaten? Worden zij om advies
gevraagd? Kunnen zij op sommige punten meedoen aan de activiteiten?
Ook procesmanagement heeft zijn risico’s. Hierbij kunnen vooral
de voortgang en de inhoudelijke kwaliteit in het gedrang komen. Het is
echter zeker mogelijk om binnen een proces te zoeken naar mogelijkhe-
den om kleine goedafgebakende deelprojecten uit te voeren. Die starten

47

pas als alle betrokkenen het daar over eens zijn, maar leveren vervolgens
wel concrete bijdragen aan de resultaten van het geheel.

Tabel 6.2: Project of proces
Aard van
Afweging Voordelen Nadelen
verandertraject
Project Concreet doel, weinig Snelheid maken Achteraf komen de
externe partijen bezwaren vanuit de
organisatie
Proces Veranderend doel, ver- Commitment staat cen- Risico van tragere
schillende externe par- traal voortgang
tijen
Risico van geringere
kwaliteit oplossing

48

7 Uitleiding

In de voorgaande hoofdstukken stonden vijf vragen of afwegingen cen-
traal:
1. Zien wij XML als een technische standaard of als een strategische
technologie?
3. Zien wij onze relaties met de buitenwereld als een keten of als een
netwerk?
4. Draait het bij de invoering van XML om de techniek of om de
organisatie?
Elke vraag bestaat uit twee schijnbare tegenpolen die we hebben
beschreven en vergeleken en van een conclusie voorzien. Dat gaan we
hier niet herhalen.
Met vijf vragen en telkens twee antwoorden zijn al 32 verschil-
lende combinaties te maken; met de aangebrachte nuanceringen en
compensatie mogelijkheden in de antwoorden zelfs een veelvoud hier-
van. Dat is uiteraard in theorie, in de praktijk bestaan er allerlei afhanke-
lijkheden tussen de vragen waardoor het aantal mogelijke combinaties
weer kleiner wordt.
Als afsluiting zullen we hier nog eenmaal de vijf vragen de revue
laten passeren. We zetten daarbij onze “extremen” nog één keer tegen-
over elkaar:
• Profiel A: technische standaard, bottom-up, ketens, techniek, pro-
ject;
• Profiel B: strategische keuze, top-down, netwerken, organisatie,
proces.

49

Tabel 7.1: Samenvattend overzicht
voordelen (+) voordelen (+)
Profiel A bepalende factor Profiel B
nadelen (-) nadelen (-)
technische + Snel ervaring Omgeving dyna- + Diepte-investe- strategische
standaard opdoen misch of turbulent, ring vanuit een hel- keuze
dan ...> dere toekomstvisie-
- Incrementeel te Een heldere en
werk gaan, dus later gedeelde toekomstvi-
opnieuw converteren sie is niet gemakke-
lijk te formuleren

- Eigen competenties
zijn hiervoor mis-
schien nog onvol-
doende ontwikkeld

- Bedrijfsonderdelen
en/of zakenrelaties
verschillen sterk in
hun ontwikkeling op
dit gebied

- Benodigde stan-
daards zijn hiervoor
misschien nog onvol-
doende ontwikkeld
bottom-up + geen grote risico’s e-business en stan- + afgeleid van visie top-down
daards op agenda
+ flexibel topmanagement, + schaalvoordelen
dan ...>
+ experimenteer- + consistent
ruimte- weinig een-
heid in optreden - te vroeg beginnen
naar buiten
- onvoldoende des-
- beheer vaak niet kundigheid
geregeld
- grote financiële
- leren vaak niet risico’s
georganiseerd
ketens + efficiënt werken met meer- + flexibel netwerken
dere businessmodel-
+ klantenservice len, dan ...> - kostbaar stand-
punt voor een afzon-
- minder flexibel bij derlijke organisatie
opkomende nieuwe
business models
techniek + stabiele infrastruc- ambitie vooral orga- + lerende en flexi- organisatie
tuur creëren nisatorisch, dan ...> bele organisatie creë-
ren
- organisatie weet die
maar gedeeltelijk te - techniek blijft ach-
benutten ter bij wat organisa-
tie nodig heeft
project + snelheid maken conditie van veel + commitment staat proces
partijen en onzeker- centraal
- achteraf komen de heden, dan ...>
bezwaren vanuit de - risico van tragere
organisatie voortgang

- risico van geringere
kwaliteit oplossingen

50

8 Bijlagen

Geraadpleegde literatuur
• H. de Bruijn, E. Ten Heuvelhof, R. in ’t Veld; Procesmanagement;
over procesontwerp en besluitvorming; Academic Service,
Schoonhoven, 2002.
• K. Doppler et al.; Change management: vormgeven aan het ver-
anderingsproces; Addison-Wesley, Amsterdam, 1996.
• Electronic Government; challenges to the effective adoption of the
extensible markup language; United States General Accounting
Office, April 2002.
• Themanummer XML; Informatie, juni 2001.
• Ph. Evans et al.; De nieuwe economie blown to bits: hoe de infor-
matie-economie bedrijfsstrategieën fundamenteel verandert; Busi-
ness Contact, Amsterdam, 2000.
• Ch. Goldfarb; The XML Handbook; 4th edition; Prentice-Hall
PTR, Upper-Saddle River, 2001.
• P. van der Hijden; Drie cases rond XML; Informatie, juni 2001.
• P. van der Hijden; Auteursprocessen; Element, nr.1, 2001.
• P. Noordam et al.; Trends in IT – 2002; Ten Hagen & Stam, Den
Haag, 2002.
• B. Timmer et al.; Elektronisch inkopen op een open markt; NEVI,
Zoetermeer, 2001.
• H. Visser, A. van Goor; Werken met logistiek; Wolters-Noordhoff,
1999.
• G. Wijnen, W. Renes, P. Storm; Projectmatig werken; Het Spec-
trum, Utrecht, 2001.

Nuttige links
• International SGML/XML Users’ Group: www.isgmlug.org
• OASIS: www.oasis-open.org
• SGML/XML User Group Holland: www.sgml-ug.nl
• Startpagina XML: xml.pagina.nl
• The XML Industrial Portal: www.xml.org
• World Wide Web Consortium: www.w3c.org

51

XML en Organisatie: vijf tegenstellingen

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (12)

Destacado

Destacado (7)

Similar a XML en Organisatie: vijf tegenstellingen

Similar a XML en Organisatie: vijf tegenstellingen (20)

Más de Pieter van der Hijden

Más de Pieter van der Hijden (20)

XML en Organisatie: vijf tegenstellingen