Typisch hedendaagse ERP (her) implementatie

 

Een upgrade of herimplementatie van Oracle of SAP naar een hogere versie verloopt in sterke mate als een IT project. Businessinvolvement is nauwelijks aanwezig en IT zelf heeft het moeilijk omdat door outsourcing en uitbesteding veel partijen betrokken zijn. Hieronder een karakterschets.

 

Mate van businessbetrokkenheid

De grotere Nederlandse bedrijven beschouwen hun ERP-systeem weliswaar als kritisch als je er naar vraagt, maar dat gaat niet zo ver dat men er concurrentievoordeel mee wil behalen. Het moet vooral standaard en best practice zijn. De financiele administratie en de inkoopafdeling zijn typische shared service activiteiten. Waar voorheen een bedrijf mogelijk nog meerdere decentrale administraties had, zijn die de laatste jaren samengevoegd en in shared service centra ondergebracht (en in sommige gevallen zelfs buiten het bedrijf gebracht). Het shared  service center moet operationeel excelleren. Dat wil zeggen, de ‘business’  - waar het geld verdiend wordt – wil niet al te veel last hebben van de administratieve processen.

 

Door een dergelijke efficiëntieslag krijgen de operationele processen voorrang boven procesverbetering op tactisch en strategisch niveau. Elke operationeel manager binnen een shared service organisatie zal zijn eigen proces optimaliseren, maar strategische keuzes zijn moeilijk. Strategische keuzes resulteren in een beter proces op bedrijfsniveau, terwijl voor sommige afdelingen het proces mogelijk helemaal niet efficiënter wordt. Het vereist bovendien een gelijkwaardig partnership tussen shared service organisatie en businessonderdelen om overkoepelend het beste resultaat te vinden. Dit vergt initiatief van een sso naar buiten toe,  daar waar de afgelopen tijd juist naar operations binnen sso gekeken is. Dat is lastigomschakelen en het kost tijd om de juiste gelijkgestemde gesprekspartners in de business te vinden. Een ERP heeft betrekking op processen die door het hele bedrijf gaan, het is daarom een noodzaak om die gesprekspartners te vinden en ook nog met de neuzen dezelfde kant op te krijgen.  

 

Als een huidige operationeel proces het leidraad is en er (nog) geen visie is waardoor nieuwe of sterk wijzigende processen in het spel zijn, met andere woorden,  als er moeite is om benefits zichtbaar te maken , dan zal de implementatie van het ERP-systeem door de business en de administratie als een technische exercitie beschouwd worden. Het wordt grotendeels aan IT overgelaten en krijgt onvoldoende aandacht tussen de dagelijkse operationele doelen.

 

 

Mate van IT volwassenheid.

De IT-organisatie is gretig. Een nieuw project, en nog wel een ERP-implementatie. We gaan het hele bedrijf door. Je voelt de honger om grotere invloed van IT ten opzichte van de business. Dit staat los van de mate waarin de business zelf betrokken is.

Waar gaat het mis? Heeft de IT organisatie wel goed naar zichzelf gekeken. Hoe goed zijn ze er eigenlijk voor georganiseerd om een project ‘dat de hele business doorgaat’ te organiseren? Dat gaat langs een aantal dimensies.

- eigen applicatiedeskundigheid

- samenwerking met ingekochte applicatiedeskundigheid

- betrokkenheid leverancier van erp-applicatie

- infra en hardware

- testing en quality assurance

De eerste aangrijpingspunten zitten bij de IT afdeling waar beheer en innovatie van het ERP-platform ligt. Kennen ze de vraag van de business goed? Kennen ze de ontwikkelingen van afgelopen periode goed? Zien ze waar de business naar toe wil? Kan voldoende tegenspel geboden worden tegen de business om prioriteiten te herkennen, om realistische functionaliteiten te scheiden van fantasievolle gedachtenspinsels.

Kan dit vertaald worden naar de functionaliteit van een erp-pakket?, kan voldoende tegenspel geboden worden tegen de leverancier en zijn marketing en salesconsultants?

In de stakeholderlandschap van leverancier en businessrequirements is het al moeilijk om je staande te houden, maar dan moet je toch overgaan tot daadwerkelijk implementeren van een omgeving. Je schakelt de system integrator in. Deze zit in Nederland of deze komt uit India, of deze zit zowel in Nederland als in India en maakt bovendien gebruik van een behoorlijk contigent ZZP-ers en onderaannemers. In theorie vraag je aan 1 persoon om iets in te regelen. In de praktijk is het een bont gezelschap dat op sommige terreinen heel sterk is, maar op andere terreinen inhoudelijk zwak en verbrokkeld georganiseerd. Hoe stuur je dat aan? Je wil er wel voor waken dat je er tussenin gaat staan, maar heb je dat contractueel wel goed afgedekt? Luisteren de applicatieconsultants van de erp-leverancier naar de system integrator, of volgen ze hun eigen pad en moet je als opdrachtgever de samenwerking tussen deze partijen ook nog regelen en bewaken?

Terwijl je de system integrator een ERP-omgeving laat implementeren komen de vragen op over infrastructuur en hardware. Hosting, connectivity en security vraagstukken moeten behandeld worden, maar wie zorgt voor de gezamenlijke communicatie? Er is – in de dagelijkse gang van zaken – betrekkelijk weining interactie tussen applicatie afdelingen en infra afdelingen. De bekendheid met elkaars processen en planningen is minder. Kun je de juiste sparringpartner wel vinden? De system integrator vraagt erom en wijst op de planning, de business verwacht het want dit hoort bij IT, toch gaat hier meer tijd overheen dan voorzien.

Tot zover is het een project waarin al heel wat gecoördineerd moet worden, terwijl we nog niet in de testfase beland zijn. Testers benoemen risico’s. Risico’s kunnen angstaanjagend zijn. Gelukkig kunnen we daar maatregelen tegen inzetten. We benoemen een hele set van testtypen. Sterker nog we benoemen meerdere testpartijen, zodat onafhankelijk vastgesteld kan worden dat de kwaliteit gewaarborgd wordt. We vergeten voor het gemak dat je hier als opdrachtgever weer nieuwe coordinatietaken mee binnen haalt.  Zodanig dat de interne auditor ook wel eens wil weten welke maatregelen je neemt om je projectrisico’s af te dekken.

 

De Cloud

Bovenstaande projectkarakterschets ging in vogelvlucht langs de kritische sucessfactoren van een ERP (her)implementatietraject. De vraag die blijft na deze projectkarakterschets: Kan de cloud een positieve invloed hebben op deze kritische succesfactoren?

We zagen dat bij een hedendaagse typische ERP implementatie bedrijfsdoelen en visie geen grote rol spelen. Dat is eigenlijk een prima uitgangspositie geredeneerd vanuit de cloud. Immers, als de ‘standaard’ aangeboden ERP in de cloud overeenkomt met bedrijfsplan, doelen en visie is er geen issue, en als de ‘standaard’ aangeboden ERP er niet mee overeenkomt, dan is dat eveneens geen probleem. Er zal geen animo zijn om er tegenin te gaan, bij gebrek aan uitgesproken breed gedeelde visie, is elke door derden aangeboden visie welkom.

In de hedendaagse situatie zien we ook dat de IT organisatie veel moeite heeft met het coördineren van de activiteiten van de onderaannemers. Een cloud aangeboden ERP implementatie staat klaar. De aanbieder heeft van te voren de processen om een goed functionerende en beheerde omgeving te laten draaien geoptimaliseerd. Met andere woorden, waar de IT afdeling van bedrijf dit soort activiteiten waarschijnlijk te weinig uitvoert om ervaren in te zijn, zal een cloud erp aanbieder dit goed moeten regelen om goedkoper en/of beter te zijn dan zijn concurrenten.

Waar komen system integrator en cloud-erp-provider elkaar dan tegen in een implementatietraject?

Eigenlijk alleen bij migratie activiteiten en bij training. Lijkt mij wel een goede focus. Het leest bovendien als een verademing ten opzichte van een huidig implementatietraject. 

 

 

 

Difference ERP vs non-ERP

•          Non-ERP: make your use cases etc. Estimate on a use case basis

•          ERP: basic functionality already available, making usecases not seen as useful…

 

ERP: use available components as metric objects

How?

 

 

What is available at the end of Inception phase?

•          Highlevel Business Process

•          Highlevel Business Requirements

•          Global Impact Analysis                

•          Use Case Model

•          Architecture Description

And because you chose ERP

All documentation/experience/knowledge of that ERP

 

 

 

 

Proposal for Metric Objects in ERP projects

Classify business process

–        New: New business process (not implemented in ERP before)

–        Modified: Business process implemented in ERP but with modifications

–        Re-use: Business process implemented in ERP without processmodifications

 

Classify Standard & Custom components

–        New: components to be developed because COTS application does not provide for required functionality

–        Modified: components to be modified because COTS application already contains (standard components but these do not entirely meet the requirements

–        Re-use: pre-existing software will be used, but needs to be tested and integrated with new and modified components

 

 

 

 

Detail level

Classification business process

–        Clear link to process-model tool must be used

Classification COTS components

–        ‘Chunk of functionality’ within ERP-module: Receipts, Payments etc

–        Independent functioning customization: 1 Interface, 1 report

 

•      Detail too low: ERP module Accounts Payable

•      Detail too high: Individual form, parameter for report

 

 

Find Agreement on classification

•          Classification done individually by

–        Business keyusers

–        Supplier – application consultants

–        Supplier – customization consultant

–        Testconsultant

 

 

 

•          Together agree on complexity per businessprocess

–        Per businessprocess count

•      Nr of new components

•      Nr of reused components

•      Nr of modified components

–        Result is: estimation points. A number (like function points) which gives:

•      indication of expected effort needed for a businessprocesses

•      Indication of complexity of a businessprocess in relation to the other businessprocess (relative weight).

 

 

How to use the results to refine estimates?

First use own experience on how many hours per point

Then:

Ask supplier to report (weekly) on hours spent per business process in elaboration phase.

This gives an indication of the hours needed in elaboration phase per process identified in the impact analysis.

Supplierdeliverables in elaboration phase can be linked to businessprocesses from the impact analysis. Therefore reporting on hours spent per process should not be a problem.

 

Future projects can be used to refine this.

        

 

Tips

•          Do not treat it as a science

•          Try to find the most suited variable for your situation

•          Use more then one estimating technique

•          Just do it!

 

 

De trend is dat bedrijven steeds verder teruggaan in hun aantal IT-leveranciers. Doel is om de overgebleven leveranciers te prikkelen mee te denken met het bedrijf en en passant standaard uniforme werkwijzes bij de business af te dwingen. Vragen die dan direct opkomen zijn: - hoe bereiken we dat gedrag bij leveranciers? - hoe houden we grip op zulke leveranciers tijdens projectuitvoering?

Hieronder mijn gedachten.
Bij projecten die ik meemaak lijkt de de leverancier met name aangestuurd te worden aan de hand van gewenste opleverdata die op hun beurt zijn afgeleid uit de mengeling van businesswensdatum en door de IT-demandorganisatie verwachte benodigde inspanning.
Dit kan best anders ingevuld worden. Geef de leverancier inzicht in de businesscase van het project en stel de beloning voor de projectuitvoering aan de hand daarvan vast. Laat de leverancier ideeen op tafel leggen voor het maximaliseren van de businessbenefits. Dit moet de leverancier prikkelen tot een efficiente standaard oplossing met de gewenste businessfunctionaliteiten.
 

Toezicht op de zo'n oplossing zit in de aanhoudende monitoring van de deliverables die tussen supply en demand uitgewisseld worden. De uitdaging voor demand zit 'm er niet in om de deliverables op tijd te willen.
De uitdaging ligt in het bereiken van overeenstemming tussen supply en demand dat de inhoud optimaal bijdraagt aan de business benefits. Eenvoudiger gezegd: de deliverable voldoet aan afgesproken criteria.

Het begint dan bij een globale impactanalyse. Omdat standaardprocessen het best met COTS-producten worden uitgevoerd zou een globale impactanalyse een indruk moeten geven van de mate waarin businessprocessen nieuw zijn of reeds uitgevoerd worden. Daarnaast moet een Globale Impact Analyse indruk geven in de mate waarin COTS-componenten ongewijzigd gebruikt kunnen worden of aangepast moeten worden. Uiteindelijk hebben opdrachtgever en leverancier het hetzelfde beeld bij de volgende projectfase die dan van start gaat.

De deliverables detailanalyse tot en met (eventuele) programmacode worden door de leverancier opgesteld. Alle functionele documenten (detailimpactanalyse, solution design, functioneel ontwerp, business rules) zullen door een keyuser, tester en leverancier beoordeeld moeten worden. Dit doen we natuurlijk nu al...Ik denk dat het ook belangrijk is om bij elke beoordeling ook de vraag te stellen: 'wat schatten we nu in als doorlooptijd voor het vervolg?'. De antwoorden op die vraag zouden zelfs tot een andere oplossing kunnen leiden. Immers doordat de betrokkenen al wat gelezen, gezien, geprototyped etc hebben is meer kennis vergaard en ontstaat een beter beeld over de uiteindelijk gewenste oplossing. Elke keuze op dat moment draagt dan bij aan de businesscase.
De technische deliverables lijken we nu vaak in z'n geheel over te laten aan de supplier ('we hoeven toch niet te beoordelen of de leverancier zijn eigen processen efficient uitvoert?'). Door hier wel afspraken over te maken, geven we aan dat we dit serieus nemen en dat het in ons beider belang is dat de supplier zijn eigen processen efficient uitvoert. Het lijkt mij bovendien vanuit het oogpunt van mogelijke overdraagbaarheid naar een andere leverancier in de toekomst verstandig dit in de gaten te houden.
 

Aan het eind nog even ruimte voor een disclaimer. Het kan natuurlijk ook zo zijn dat het beter is om een hele business proces te outsourcen. Dan is bovenstaande niet van toepassing.

Een reuse program introduceren op de IT-afdeling

 

 

Beginnen

 

Even kijken op http://en.wikipedia.org/wiki/Code_reuse

• Opportunistic reuse -  Op het moment dat met een project begonnen wordt, realiseert men zich dat er bestaande componenten zijn die herbruikt kunnen worden.
• Planned reuse – Een team ontwerpt de componenten zodanig dat ze herbruikbaar zijn in toekomstige projecten.

Iedereen gaat ervoor

 

Analysefase: Architecten identificeren processen of applicatieonderdelen die hergebruikt kunnen worden in het project dat gerealiseerd moet gaan worden.

Architecten identificeren vanuit businessrequirements processen die strategisch zijn en bewaken deze zodanig dat deze processen of te ontwikkelen applicaties in toekomstige projecten herbruikbaar zijn.

 

Ontwerpfase: Consultants herkennen dat er bestaande componenten zijn die herbruikbaar zijn. Consultants ontwerpen de componenten zodanig dat ze later herbruikbaar zijn.

 

Bouwfase: programmeur / leverancier toont aan dat software reuse de normaalste zaak van de wereld is. Onafhankelijke review kan evt bevestigen dat programmeurs zich houden aan het principe van ‘Don’t repeat yourself’ of ‘Once and only once’

 

Testfase: Testconsultants ontwikkelen testware die herbruikbaar is binnen een project. Scripts die in de basis geschikt zijn voor verschillende typen tests

Testconsultants ontwikkelen testware die herbruikbaar is binnen de lifecycle van een application.

 

 

Om te overwegen

 

Elke discipline (architecten, consultants, developers, testers) zou jaarlijks moeten aantonen dat er reuse is toegepast (uiteraard gespecificeerd in eigen metrics hoeveel dan wel!)

 

 

 

Elke discipline moet permanent actief beheren wat de herbruikbare processen, modules, scripts, code etc is. Dat is geen taak voor iemand anders, een beheerder ofzo, dat is een taak voor het eigen team.

 

 

Blijf Agile. Herbruikbaarheid naar de toekomst is geen doel op zich. Maar als je weet dat op een bepaald punt de business al 3 keer eerder zijn mening heeft gewijzigd, zorg dan dat je voorbereid bent.

 

 

Reuse before Buy before Build.

Maar ik doe ERP...: Out-of- the-box-processes before Configuration before Customizing.

 

 

 

Voortgangsrapportages tonen vaak hoeveel procent een bepaalde taak al is afgerond.

• Maar heb je wel echt alle activiteiten die nodig zijn voor dat requirement doordacht? Met andere woorden weet je echt wel wat 100% is?
• En is het niet zo dat de laatste 20% altijd 80% van de tijd kost?

Kortom wat heb je aan voortgangspercentages die zeggen dat een bepaalde taak voor 70% gereed is? Helemaal niets.

Hoe komen we wel tot een een rapportage die een beeld geeft en die aanknopingspunten voor bijsturing biedt?

• per taak een verwachte einddatum invullen door degene die de taak uitvoert
• als meer informatie is over een taak, dan deze direct uitsplitsten naar subtaken en per subtaak een verwachte einddatum laten invullen.
• degene die moet bijsturen, gaat niet verwachte einddata ter discussie stellen. Hij heeft immers minder expertise en het getuigt van weinig respect ten opzichte van de professional die de inschatting maakt als hij zegt het beter te weten
• degene die moet bijsturen, gaat wel de volgorde van gelijkwaardige, niet onderling afhankelijke taken ter discussie stellen. Sommige verder naar achter schuiven, waardoor meer tijd vrijkomt om risicovolle taken toch op tijd gereed te hebben.

En dat is mijn mening.

Wat werkt er allemaal niet op de gemiddelde IT afdeling waar we projecten voor de 'business' uitvoeren?

- De organisatie blijf dusdanig veranderen qua koers en bemensing dat iedere keer het wiel weer opnieuw wordt uitgevonden. De lessons learned worden wel opgesteld, maar zijn bij begin van het volgende project al onvindbaar.

- De invoering van nieuwe ontwikkelmethoden (RUP) stokt door de omvang en interdepentie van projecten en door het outsourcingscontracten. Alles blijft waterval.

- Het niet opleveren (van voldoende kwaliteit) lijkt acceptabel, het niet hebben van een planning of zeggen dat je je aan een planning lijkt NIET acceptabel. Dat is raar, want iedereen vindt het dan blijkbaar prima dat er iets (een requirementsdocument, een ontwerp, een systeem) wordt opgeleverd waar iedereen van weet dat er nog een slag overheen moet. Maar de planning blijft heel lang heilig. Op een afgesproken datum krijgen we dus iets wat we onvolledig vinden, of eigenlijk niet willen, terwijl we dan nog steeds niet weten wanneer we wel krijgen wat we willen.

Dat moet worden aangepakt...

Naar mijn overtuiging werkt het (een beetje beter) als we
1. Agile planning toepassen
2. Vertrouwen creeeren tussen klant (business) en leverancier (it)
3. Fouten mogen maken.

 

Agile planning toepassen

Agile planning zegt dat plannen waarschijnlijk snel kunnen veranderen. Het is daarom nuttig om een 'feature'planning te maken. Los inschatten wat de omvang van een stukje functionaliteit is. Oftewel hoeveel tijd zou het kosten om een bepaald requirement te gaan realiseren. Nog even los van andere requirements. Pas nadat we alle inschattingen gemaakt hebben, proberen we de doorlooptijd in te schatten. Voordeel: je denkt elk requirement afzonderlijk door. Ook dat is nuttig bij het zien van de afzonderlijke risico's. Pas daarna voeg je gedeelde functies samen. Doe je het niet in deze volgorde dan zul je zien dat je per requirement minder goed weet wat er mee gemoeid is en tegelijkertijd reken je je rijk in de planning omdat je vermoed dat er gedeelde componenten in zitten.
Wees ook helder over onzekerheid òf in functionaliteit òf in de opleverdatum. Maar niet in allebei!

Vertrouwen creeren

Politiek gezien is de focus van verschillende afdelingen vaak erg uiteenlopend. Gevolg hiervan is dat beide partijen vaak enigszins wantrouwend zijn ten aanzien van de doelen die men met een bepaald programma of project denkt te bereiken.
Vertrouwen ontstaat pas als op meerdere niveau's bij zowel klant als leverancier helder en open gecommuniceerd wordt over korte en lange termijn doelen. Met daarbij uiteraard de kanttekening dat korte en lange termijn consistent moeten zijn en in elkaars verlengde liggen.

Fouten mogen maken

Het vermijden van fouten leidt tot gedrag waarbij risico's en onzekerheid onder de oppervlakte blijven. Dat op zijn beurt is niet goed voor het onderling vertrouwen. Des te eerder wordt overgegaan van planvorming naar uitvoering (van een eerste deelgebied) des te eerder loop je tegen je eigen onwetenheid aan. Dit moet niet afgestraft worden door de omgeving, maar herkend worden als aandachtsgebied.

 

Daar zit je dan met enterprise architectuur framework, je ERP-pakket(ten), je COTS-applicaties, je legacy en je servicebus. Hoe vul je in de dagelijkse praktijk het gat tussen enerzijds een paar enterprise architecten met weliswaar goede bedoelingen maar een theoretisch georiënteerde helicopterview en anderzijds de IT-afdeling (technologie- en knustelgedreven) die voor de business (vanzelfsprekend businessgedreven) projecten uitvoert?

Dit is een korte, nog weing gestructureerde, inleiding in het thema om een enterprise architectuur van strategisch niveau ook naar tactische en operationeel te brengen en in te bedden.  Het operationeel maken van de architectuurprincipes zal van twee kanten moeten komen. Het (1) hanteren (en internaliseren) van architectuurprincipes als toetsingskader waartegen oplossingen gehouden moeten worden door de IT-consultants en (2) architectuurconsultancy vanuit architecten richting IT-consultants.   

Checklist Architect Toetsingscriteria Adaptieve Changes/ & Additieve changes

Doel: ontwerp- en bouwprocessen zoveel mogelijk baseren op architectuurproces. 

Vooraf te stellen vragen: is de doelarchitectuur/roadmap nog wel actueel? Heeft deze wel de status geaccordeerd? Is deze wel breed genoeg gecommuniceerd?  

Te stellen vragen door een IT consultant aan zichzelf als hij een oplossing bedenkt voor een door de business aangedragen wens/probleem/oplossing. De term change wordt hier gebruikt voor zowel een rfc die een minimale wijziging van bestaande functionaliteit betreft als voor een project dat omvangrijke nieuwe functionaliteiten introduceert en/of delen van systemen uitfaseert.

•  Heeft change betrekking op data, setup, of op programmatuur? In geval van setup/parameterinstellingenà wat is de impact van wijziging, welke informatievoorziening/welke processen/welke programmatuur heeft hier mee te maken? In geval van programmatuur à wordt het aantal componenten verminderd, generieker bruikbaar?   
• Heeft change betrekking op applicatie die uitgefaseerd wordt? Zo ja lost het een situatie op die überhaupt nog wel op zal treden, of zo weinig voordeel zal bieden dat het niet tegen de kosten opweegt?         
• Heeft change betrekking op standaard programmatuur van de applicatie?
• Brengt de change de doelsituatie dichterbij?
• Hoever moet een organisatie gaan om standaardpakketten aan te passen vanuit het oogpunt van gebruikersvriendelijkheid? Wat zijn de criteria bij gevalletjes als ‘de gebruiker snapt dat niet.. die verwarrende dingen moeten weg..’

Hoe kun je zo’n gebruikerservaring meten? Hoe kun je meten of de gemiddelde gebruiker in zo’n geval wel zijn werk naar behoren kan doen/of aantoonbaar sneller iets kan vinden etc. Als deze informatie voorhanden is, dan is dat al heel wat en zal het over het algemeen lonen om de aanpassing door te voeren. Als niemand een eenvoudige niet-kostbare methode kan verzinnen om dit meetbaar te maken, dan is het dubieus of de aanpassing wel zinvol is.   

Zijn gebruikersvriendelijkheidseisen in deze zin anders dan functionaliteitseisen? Bij de keuze voor een COTS pakket is – als het goed is -  de eventuele instelbaarheid van gebruikersinterface een criterium geweest. De afweging is toen gemaakt om een bepaald pakket te kiezen, de gebruikersdoelgroep en hun kennis niveau is toen geinventariseerd. Dit zal over het algemeen niet wijzigen. Mag dit dan in een later stadium toch een argument zijn? De grote ERP pakketten zijn inderdaad eenmalig instelbaar, maar daarna juist heel moeilijk bijstelbaar..  

• Zijn de businessparameters ook parameters in de oplossing? Een situatie als het hanteren van een andere basisvaluta in een applicatie (van NLG naar EUR) is niet vooraf in te stellen, als de business nu een product heeft dat ondersteund moet worden, dan zal er binnenkort een vergelijkbaar product op de markt komen, maar dan net wat anders. Is die ‘net anders’ situatie gevangen in instelbare parameters?       
• Is schaalbaarheid geborgd? Kan het proces zowel kleine als grote volumes aan en is de werkwijze dan nog wel behapbaar voor gebruikers en beheerders?     
• Is hergebruik van gelijksoortige bedrijfsfuncties mogelijk, binnen de grenzen van een informatiegebied , centrale, enkelvoudige vastlegging van persoonsgegevens.
• Worden gegevens eenmalig bij de bron vastlgelegd, wordt redundantie voorzien van een reden, wordt elk gegevensitem maar in 1 applicatie beheerd, zijn identificerende gegevens door de hele keten aanwezig?       
• Wordt in transactionele applicatie(modules) voorzien van een herstelfunctie, wordt verder op in de keten de mogelijkheid gecreerd foutieve aanleveringen te weigeren?
• Wordt gebruikgemaakt van Corporate data?         
• Past de toegang tot de applicatie/scherm/bestand in het grotere geheel van security, wordt gebruik gemaakt van de eventuele beschikbaarheid van single-sign-on?  

 

Architectuurconsultancy 

Waar IT-consultants bezig zijn met een concreet businessproject en vanuit dat perspectief richting de doelarchitectuur gekeken wordt, is een blik nodig vanuit de doelarchitectuur richting concrete businessprojecten. Als het goed is kom je elkaar in het midden tegen (na enkele discussies). De hierboven genoemde lijst met vragen is dus ook voor de architect van toepassing. Daarnaast is voor de architect toepassing om juist de kaders blijvend aan te scherpen. Het aanscherpen kan vanuit de volgende invalshoeken 

1.   Het voorkomen van onnodige complexiteit bij nieuwe initiatieven.

·         Innovatieve concepten beoordelen op hun risico’s

·         Selectief zijn bij het toepassen van alternatieve componenten, platforms e.d.,

·         Verspreiding van en toezien op het gebruik van standaarden en het generiek gebruiken van modules en componenten

·         Keuze maken voor lang houdbare oplossingen

·         Inwisselbaarheid van modules

·         Betrouwbaarheid leverancier.

2.   Het verminderen van de complexiteit van de staande IT voorzieningen

·         upgrades/uit- en infaseringeren van applicaties onderbrengen in projecten volgens een architectuurroadmap,

·         indelen naar bedrijfsproces en eigenaar t.b.v. bestuurbaarheid en kostentransparantie,

3.   Het inzichtelijk maken van/informeren over complexiteit in businessflows/procesketens en de uitwerking daarvan met IT-middelen.

·         hanteren van een enterprise architectuur framework

·         landschapplaatjes en beschrijvingen die vanuit verschillende perspectieven relevante kenmerken van (de complexiteit in businessflows/procesketens en de uitwerking daarvan met IT-middelen laten zien.

·         Kwantificeren van de complexiteit (niet alleen overlaten aan business cases in individuele projecten) 

4.  Het (ongevraagd) adviseren over:

·         Het bieden van een enterprise architectuur framework om bedrijfsmatige veranderingen snel te faciliteren ter verbetering van de time-to-market van producten,

·         het vormgeven van oplossingsconcepten voor de termijn die boven projecten uitgaat

·         het consequent aanvullen van oplossingsconcepten met generieke, maar vaak vergeten functionaliteiten zoals systeembeheer, uitwijk en security.

·         het zicht houden op IT initiatieven buiten het eigen domein en de synergievoordelen daaruit destilleren

Eerst was er corporate governance, daarna enterprise en IT governance, en ik heb ook al project governance gehoord. Het zal wel niet lang meer duren voor we project- en programma governors als functie terug zien. Maar wat betekent governance en daarbinnen IT governance nou eigenlijk? Afgaande op mijn kennis van engels zal het wel zoiets als besturing betekenen. Maar wat is dan het nieuwe of specifieke daaraan? IT besturing is toch niet nieuw?

Even een tussendoorzijpaadje: vinden engelssprekenden dit zelf ook een vaag buzzword waar ze van alles onder kunnen laten vallen, of is het - vanwege het gebruik van de eigen taal - beter afgebakend. En is het een kenmerk van nederlandse managers om zo'n term te adopteren en te gebruiken voor eigen doeleinden cq zich er achter te verschuilen?

Toch maar 'ns wat literatuur er op nageslagen. Volgens Hoogervorst (2007) is IT governance:

de organisatorische competentie voor het continu uitoefenen van richtinggevende autoriteit betreffende IT-strategieontwikkeling en het daaropvolgende ontwerp, de implementatie en de operatie van IT-systemen.

Kan ik er nu wat mee? Toegepast op mijn eigen situatie: mijn manager vroeg laatst om hem ideeën aan de hand te doen waarmee hij de business blij kan maken. Nu is dit natuurlijk een logische vraag en ik zie dit ook wel als mijn taak, maar het richtinggevende aspect van de IT governance ontbreekt hier. Als alle medewerkers hun ideeën spuien, wie bewaakt dan de samenhang en hoe dan eigenlijk? Daar zie ik in mijn omgeving weinig van terug. Ben benieuwd welke structuren daar zoal voor bestaan en welke daadwerkelijk  positief functioneren binnen organisaties...