DSM heeft zich van steenkool via de petrochemie ontwikkeld naar een bedrijf dat bijvoorbeeld met Dyneema de sterkste kunstvezel ter wereld maakt. De derde generatie van het bedrijf richt zich op zogenoemde Life Sciences, Materials Sciences en de combinatie daarvan. Ook op het gebied van IT is er de nodige dynamiek binnen DSM. De kunst is volgens CIO Aloys Kregting de informatietechnologie te laten aansluiten bij de context, behoeften en volwassenheidsfase.

Stel je voor dat je niets aan architectuur doet, dan merk je daar eigenlijk niks van. Tot het moment dat het fout loopt, zo stelt DSM-CIO Aloys Kregting. "Als je architectuur verkeerd is, dan kun je een veelvoud aan geld moeten uitgeven om uiteindelijk de zaken wél op orde te krijgen. Stel dat je niet goed hebt nagedacht over hoe mensen qua autorisatie bij je applicaties komen, en je dat op een verkeerde laag hebt ingeregeld, dan zou dat kunnen betekenen dat je op een gegeven moment heel veel mensen moet aannemen om ervoor te zorgen dat er voor iedere applicatie autorisatie aangevraagd moet worden. Terwijl als je dit direct op het juiste niveau had gedaan, een pc of een ander apparaat, dan had je daarop kunnen leunen voor de rest. Een ander voorbeeld is dat je als bedrijf één kernel in bijvoorbeeld SAP wilt hebben, maar dat je gaandeweg merkt dat het bedrijf qua processen toch wel divers is. De one kernel approach zet je dan dus eigenlijk terug in de tijd. De businesses moeten per slot van rekening werken met middelen die goed zijn voor het gemiddelde van het bedrijf, maar dat gemiddelde kan blijken niet te bestaan. Dus wanneer je in dat geval te veel standaardiseert, dan voegt het geld dat je stopt in de standaardisatie op een gegeven moment negatieve waarde toe aan de waarde van de individuele businessgroepen."
De IT-strategie bij DSM heeft volgens de CIO een structuur die oorspronkelijk van Gartner komt. Op corporate DSM-niveau is er de Corporate Strategic Dialogue (CSD), terwijl daaronder op businessniveau tien BSD's hangen: Business Group Strategic Dialogues, die de visie vertalen in een aanpak per businessgroep. "Dit jaar hebben we hier als nieuw initiatief voor die groepen het Informatie Plan aan toegevoegd, dat de business-informatiemanager (BIM) schrijft om een vertaling te maken van de BSD naar de informatiemanagement-/ict-aanpak. En daaronder komt de IT-strategie. Die bestaat uit zeven blokken, waarvan de architectuur er één is. De andere zijn support, applicaties, infrastructuur, mensen, finance en sourcing. De input voor de IT moet komen van wat de businessgroepen willen."
De architectuur kan ervoor zorgen dat DSM voor wat betreft IT en informatiebeheer klaar is voor de toekomst. De architect moet de legacy daarbij voor lief nemen. Binnen DSM geldt volgens de CIO een operational-excellencestrategie, dus men wil zo weinig mogelijk veranderen en zoveel mogelijk vasthouden aan de commodities. "Maar je hebt ook businessgroepen die per klant heel specifieke oplossingen willen bieden en dus meer aan de kant zitten van de customer intimacy en product leadership. Dat betekent dat de bijbehorende informatieplannen op een aantal vlakken fundamenteel anders zijn. Dus op sommige punten kun je rücksichtlos standaardiseren, zoals pc's, netwerken, security, internet, intranet, het procurement-to-pay-proces, enzovoorts. Maar er komen elementen, bijvoorbeeld de prospect-to-order, CRM, het introduceren van nieuwe producten (NPI) of de salesforce automation, die per businessgroep kunnen verschillen. Je moet dus eigenlijk een architectuur hebben die dat toestaat. Dat is bij ons nog niet het geval. Je hebt één groep architecten nodig, die de verschillende demands kunnen faciliteren. Zij zouden bijvoorbeeld op het briljante idee moeten komen dat je één kernel hebt voor de utilityfuncties binnen IT en daarbovenop een structuur toelaat waarin flexibiliteit kan plaatsvinden. In die context moet een architect kunnen werken. Hij moet luisteren naar wat er nodig is en dit vervolgens vertalen in de juiste architectuur. Dat zie je niet per definitie gebeuren."

Wijzigingen
De oorspronkelijke benadering van DSM is dat er één SAP-kernel is. Kregting: "Wanneer er iets verandert, dan doe je die aanpassing in die ene kernel. En dat geldt voor alle applicaties. Vanuit het verleden gezien is dat wat mijn voorganger heeft gedaan heel goed geweest. De regelgeving zit bijvoorbeeld meestal in die basisfunctionaliteit. We hebben hier dus één systeem dat we bij veranderende regelgeving alleen in de basis hoeven aan te passen. En dan is het wereldwijd geregeld. Dit was uiteindelijk ook het idee achter de hele SAP-gedachte. Maar hoe verder je gaat met standaardisatie, hoe vaker je bij processen komt die per businessgroep wél specifiek gaan worden."
De afnemer krijgt met het pakket doorgaans een stukje ‘ingebakken' architectuur cadeau. Past deze wel bij de architectuur en bedrijfscultuur van DSM? Of maakt dit het de gebruiker juist gemakkelijk? "We denken hier desondanks heel goed zelf na over architectuur, omdat je het als gebruiker nog steeds goed kunt vernachelen. Ik zie SAP wat dat betreft net als Excel: alles wat je kunt bedenken kun je erin bouwen. De klant kan er bovendien lagen omheen maken, bijvoorbeeld om te kunnen communiceren met andere applicaties. Je hebt de keuze of je de intelligentie gaat bouwen in de middleware, of dat je deze bijvoorbeeld in de businesssystemlaag laat zitten. Daar kun je trouwens heel erg de fout mee in gaan en dat ligt dus niet aan SAP. Wij laten bij change requests de architect daarom een check uitvoeren. Net zo goed dat we de information security officer een test laten uitvoeren om te kijken of iets veilig is. Zo hebben we binnen DSM een aantal kwaliteitscontroles. Onze architecten hebben het hier knap druk mee. Soms kiezen we op basis van het oordeel van de architect voor een andere aanpak."

Informatieplan
Binnen DSM hanteert men nog niet zo lang het zogenoemde ‘informatieplan'. Dit betekent in de praktijk soms nog dat BIM'ers met hun lijstje projecten komen aanzetten, maar op termijn moeten zij toe naar een vertaling van hetgeen ze als businessgroep via de informatievoorziening proberen te bereiken. "Men moet dus aangeven welke richting ze op willen met informatiemanagement. Dus de manier waarop ze de mensen binnen de business denken te kunnen ondersteunen, of nieuwe kanalen denken te kunnen aanboren met IT-middelen. Om pas daarna een aantal projecten op te starten. Wij als IT denken er vervolgens over na hóe we dat kunnen gaan doen. Daar moet een strikte scheiding tussen zitten; het loopt nu nog te veel door elkaar."
De BIM'er heeft daarbij een soort architectuurfunctie. "Hij moet vertalen wat de business nodig heeft, maar als je het heel zuiver wilt doen, dan moet de businessgroep eigenlijk een businessarchitect hebben. Die moet nadenken over hoe hij de zaken wil organiseren, welke kanalen hij wil bespelen en zeggen wat voor type mensen erbij nodig zijn. En natuurlijk ook wat voor type salesforce. In de praktijk vind je dat bijna niet bij bedrijven. We hebben hier overigens business process experts, het zogenoemde Apollo-team. Dat is een staffunctie die nadenkt over de bedrijfsprocessen. Bijvoorbeeld FiCo of procurement-to-pay." De uiteindelijke eigenaar van die businessprocessen is de business process owner (BPO). Zo is de corporate controller de BPO voor het FiCo-proces, die op dit terrein uiteindelijk de beslissingen neemt. "Er zit ook een change advisory board op, die iedere keer beoordeelt of een proces wel aangepast mag worden. Vervolgens worden al die kwaliteitschecks weer gedaan. Er is dus inderdaad bewaking op de standaardisatie."

Commonalities
Er wordt bij DSM in dit kader bovendien gezocht naar commonalities tussen de verschillende gebieden. "Dáár kun je winst maken. Maar je moet hier zogezegd ook weer niet te ver in gaan. Er hoort dus een stukje governance bij en die houdt in dat je één lijn trekt. Onder de streep spreek je van ‘utilities', die krijgt ieder lid van de DSM-familie standaard mee: datacenters, pc's, werkplekken, internet, intranet, FiCo, de standard chart of accounts (SCOA), enzovoorts. Dat is het water uit de kraan, waar je je economy of scale vandaan moet halen. Daar bovenop heb je een aantal processen die over het algemeen meer businessgroepspecifiek zijn: prospect-to-order, salesforce automation, CRM, KPI-reporting, management information systems en e-business. Je moet businessgroepen de vrijheid geven om zich op dat soort vlakken als entrepreneur te gaan gedragen."
"ERP-leveranciers, maar ook veel consultants, zeggen sinds de jaren negentig evenwel dat je alles zoveel mogelijk moet standaardiseren. Dan zou je je er namelijk niet meer druk over hoeven te maken. Maar niemand heeft zich daarbij de vraag gesteld hoe ver je daarmee door kunt gaan. Op een gegeven moment worden systemen veel te complex, omdat alles, ondanks de verschillen tussen de businessgroepen, er toch in wordt gewurmd. De complexiteit blijft, er zit alleen één logo op."
Bij de vraag hoe je dat vervolgens verandert, spelen de architecten een belangrijke rol. Want je moet de fundamenten van het huis verbouwen, terwijl je erin woont. "Dat is een pittige uitdaging. Qua governance willen wij allereerst regelen dat niet iedereen meer hetzelfde hoeft te hebben. Daar krijg je de business heel snel in mee, want die krijgen de ruimte. Het fundamentele punt is dat we hier op een gegeven moment zullen overstappen op een SOA-variant van SAP. Je zou kunnen zeggen dat we momenteel standaardiseren op Duploblokken en in de SOA-constructie gaan we standaardiseren op de Legoblokjes, die je per businessgroep apart kunt inrichten."

Architecten
Binnen DSM heeft men één lead architect, die ook de applications doet, en één architect op de infrastructuur zitten. "Twee architecten dus, en dat op onze 650 IT'ers, even los van wat we uitbesteed hebben. Dat is inderdaad niet veel, maar deze mensen hebben geen operationele rol. Ze kijken puur hoe iets moet of kan. Een dergelijke staffunctie moet je zo klein mogelijk houden. Des te slimmere mensen je er neerzet, des te slimmere vragen stellen ze en vervolgens gaan ze andere slimme mensen van hun werk zitten houden. Dat moet je proberen te voorkomen. Waar ik overigens echt allergisch voor ben, is dat men komt met de laatste technologie of de laatste variant van een procesmodel, maar daarbij vergeten is in welke context dit moet werken."
Architecten moeten volgens Kregting in maturitymodellen kunnen denken; een strategisch plan kunnen vertalen in realistische acties en daarbij kunnen bepalen wat je op een gegeven moment in de tijd en gezien de volwassenheidsfase wel doet en wat juist niet. "Ze zijn dus pragmatisch, weten het architectuurraamwerk in de context te plaatsen en kunnen de vervolgstappen nemen. De echt goede architecten kunnen hun verhaal bovendien in normale mensentaal uitleggen. Dat soort mensen zijn zéér zeldzaam."
"Maar goed, dan kom ik vanzelf weer bij vaardigheden die ook een CIO moet hebben: goed vakinhoudelijk zijn en daarin met scenario's kunnen spelen. Maar als je voor de managing board staat, dan moet je ook kunnen zeggen: "De processen worden met dit soort technologieën efficiënter, ze geven ons flexibiliteit en het innovatieproces wordt sneller." Alleen je werk goed doen is namelijk niet voldoende, er hoort een stuk sales en marketing bij."