Systeemontwikkeling - Noordhoff Uitgevers

2011, Noordhoff Uitgevers bv
Systeemontwikkeling
1 Het selecteren en implementeren van informatiesystemen
Systeemontwikkelingsprojecten waarbij nieuwe programmatuur en apparatuur ten
behoeve van een informatiesysteem ontwikkeld of geselecteerd moeten worden
brengen de nodige risico’s met zich mee. De belangrijkste risico’s zitten in de kosten,
doorlooptijd en prestaties. Terwijl organisaties in staat zijn om de productieprocessen
in hun fabriek tot in detail te budgetteren en in de greep te krijgen, worden tegelijkertijd
in systeemontwikkelingsprojecten de budgetten bijna als regel dramatisch
overschreden, deadlines niet gehaald en prestatie-eisen naar beneden bijgesteld. In
de Engelstalige literatuur wordt dit fenomeen aangeduid met de term ‘runaway
projects’.
Een mogelijke oplossing voor het probleem van de ‘runaway projects’ is de
systeemontwikkeling zoveel mogelijk te standaardiseren volgens een vaste methodiek,
zoals de ‘Systems Development Life Cycle’ (SDLC) en daarnaast zoveel mogelijk te
streven naar standaardtoepassingen (‘canned software’ of ‘commercial off the shelf’
[COTS] software). Systeemontwikkeling volgens de SDLC is heel gebruikelijk in de
praktijk, maar het zo veel mogelijk streven naar standaardtoepassingen en dus het
afstand nemen van maatwerk is pas de afgelopen tien jaar de tendens geworden.
Daarvoor was het gebruikelijk om bedrijfsspecifieke functies als maatwerk te laten
ontwikkelen, maar tegenwoordig wordt er steeds vaker gesteund op
standaardprogrammatuur al dan niet met een hoge mate van parametriseerbaarheid.
Een typisch voorbeeld van standaardprogrammatuur met een hoge mate van
parametriseerbaarheid vinden we in ERP-pakketten. ERP staat voor Enterprise
Resource Planning. ERP-pakketten zijn veelal lege hulzen die nog moeten worden
gevuld om ze te kunnen gebruiken. Die vulling betreft dan de parameterinstellingen.
Het maken van de juiste parameterinstellingen is een complex en langdurig proces,
waarin het overgrote deel van de doorlooptijd van een ERP-implementatie gaat zitten.
Daarmee zijn ERP-pakketten in feite tussenoplossingen, tussen volledig maatwerk en
volledig standaardwerk.
1.1 Fasering, activiteiten en attentiepunten
Figuur 1 geeft de fasering weer van een systeemontwikkelingsproject. Deze methodiek
wordt ook wel de watervalmethodiek genoemd. Kenmerken van een dergelijke
methodiek zijn:
• Er is een strakke verdeling van activiteiten in een aantal fasen.
• Iedere fase wordt afgesloten met een concreet product en een formele
beslissing: go/no go.
• Het is niet toegestaan om vanuit een fase terug te gaan naar een vorige fase
(een waterval kan immers ook niet terug omhoog). De producten en de daarop
gebaseerde beslissingen in een vorige fase worden als het ware bevroren en
het is slechts bij hoge uitzondering toegestaan deze opnieuw ter discussie te
stellen. Dit uitgangspunt is van groot belang in het kader van de beheersing
van het project. Het is bekend dat automatiseringsprojecten vooral dán uit de
hand lopen als vanuit latere fasen de uitgangspunten en beslissingen van
eerdere fasen telkens opnieuw ter discussie worden gesteld. Het zal duidelijk
zijn dat het strikt vasthouden aan dit uitgangspunt als belangrijk nadeel heeft
dat veranderende omgevingsfactoren onvoldoende in de systeemontwikkeling
worden meegenomen en het uiteindelijke systeem niet meer past bij de
veranderde omstandigheden. Wat begint als een ambitieus maar haalbaar
project, wordt gedurende de uitvoering steeds complexer en ontaardt in een
‘runaway’. Dan blijkt tijdens de programmeerfase, dat enkele essentiële zaken
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
1
Noordhoff Uitgevers bv
over het hoofd zijn gezien, en worden wijzigingsvoorstellen gedaan. Deze
worden gevolgd door nieuwe wijzigingsvoorstellen en correcties op eerdere
wijzigingsvoorstellen. De tijdsdruk (‘er zitten zoveel programmeurs te wachten
op onze beslissing’), het gebrek aan kennis en overzicht bij sommige partijen
en de complexiteit van de materie leiden er soms toe dat het project volstrekt
onbeheersbaar wordt. Het vereist dan nogal wat moed om het project stil te
leggen, rustig adem te halen en te kijken hoe het project opnieuw op een
beheersbare wijze opgezet kan worden.
De ‘moeder van alle watervalmethodieken’ is de ‘Systems Development Methodology’
(SDM), een stapsgewijze aanpak die vooral in de jaren zeventig de standaard vormde
voor automatiseringsprojecten. In systeemontwikkelingsmethodieken die niet zijn
gekoppeld aan een bepaalde commerciële aanbieder, zoals de SDLC, is de fasering
van SDM nog steeds herkenbaar. Figuur 1 volgt in grote lijnen SDM en de SDLC.
Figuur 1 De traditionele fasering van een ontwikkel- en aanschaftraject van een
geautomatiseerd informatiesysteem
1.
Overall informatieplan op (middel)lange termijn
2.
Systeemanalyse
3.
Specifiek informatieplan (projectplan)
4.
Specificatie functionele eisen: wat moet het informatiesysteem kunnen?
5.
Technisch ontwerp (bij zelf ontwikkelen) of marktverkenning, opvragen offertes,
demo’s, selectie en aanschaf van programmatuur (bij aanschaf van
standaardprogrammatuur)
6.
Programmeren (bij zelf ontwikkelen) of parametriseren van het pakket (bij
7.
Acceptatietesten
8.
Implementatie
9.
Gebruik, beheer en onderhoud
aanschaf van standaardprogrammatuur)
Zoals uit figuur 1 blijkt, zijn de trajecten bij zelf ontwikkelen en aanschaffen van
standaardprogrammatuur grotendeels identiek. Op detailniveau is de problematiek
uiteraard vele malen complexer bij zélf ontwikkelen. Dit stelt dan ook veel hogere
eisen aan de competenties van het automatiseringspersoneel in de organisatie.
SDM is erop gericht om het hele, soms zeer omvangrijke traject zoveel mogelijk
centraal te beheersen door toepassing van zeer strikt projectmanagement en
formalisering van alle beslissingen. Vaak blijkt tijdens een dergelijk traject dat zaken in
complexe omgevingen simpelweg minder goed planbaar zijn dan de methode
veronderstelt. Zeker in situaties waarin organisatiebrede systemen worden ontwikkeld,
doet een methode met de rigiditeit van SDM en de SDLC vaak meer kwaad dan goed,
doordat het de aandacht afleidt van de kern van de problemen naar het volgen van de
methodiek en het invullen van formulieren. Een ander punt van kritiek op SDM en
verwante methoden is, dat aan gebruikers bij de specificatie van de functionele eisen
vaak tot in detail wordt gevraagd wat het systeem moet kunnen, zonder dat zij daar
een duidelijk referentiepunt bij hebben. Aan hen wordt functie voor functie, scherm
voor scherm, gevraagd wat zij in de toekomst nodig denken te hebben. Pas als het
systeem voor 100% is beschreven, gaat de programmeur datgene bouwen wat is
afgesproken. De functionele specificaties van sommige systemen zijn soms meerdere
mappen vol met documentatie. In alle redelijkheid is het voor de meeste gebruikers
echter niet mogelijk om alle consequenties van de gemaakte keuzen die in deze
mappen zijn vastgelegd te overzien. Het maken van een functionele specificatie van
een informatiesysteem wordt wel vergeleken met het kopen van een auto. Stel dat een
2
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
2011, Noordhoff Uitgevers bv
koper in een showroom komt, maar in plaats van auto’s staan daar de technische
specificaties en bouwinstructies van alle modellen die de garage verkoopt. De koper
wordt gevraagd om deze door te nemen en, als hij akkoord is, om de lijst met
specificaties te tekenen. De koper kan op basis van de specificaties echter nauwelijks
beoordelen of er niet iets is vergeten, of alle onderdelen goed op elkaar zijn afgestemd
en, uiteindelijk, of het te bouwen model ook echt kan rijden. Daarom vraagt de klant
om een model (een ‘prototype’) voor een proefrit en, als dit bevalt, plaatst hij de order:
‘Doe deze maar, maar dan in het rood.’
Analoog aan dit voorbeeld van de aanschaf van een auto en om tegemoet te komen
aan de kritiek op de rigiditeit van de SDLC zien we steeds vaker een andere wijze van
systeemontwikkeling, ook wel ‘prototyping’ genoemd of een variant daarvan ‘Rapid
Application Development’ (RAD). In deze werkwijze wordt de traditionele aanpak
losgelaten en werken gebruikers en systeemontwerpers samen in workshops,
ondersteund door gespecialiseerde hulpmiddelen om vooral de gebruikersinterfaces
van een systeem te ontwerpen. Dergelijke teams ontwerpen dan de schermen die
gebruikt gaan worden, de print-outs die uit het systeem moeten komen en andere voor
de gebruiker zichtbare kenmerken. Als gebruikers en ontwerpers het over deze
buitenkant eens zijn, en aan de hand daarvan ook de functies aan de binnenkant
hebben besproken, gaan de systeemontwerpers en programmeurs uiteindelijk over tot
het daadwerkelijk bouwen van het systeem. Deze aanpak leidt doorgaans tot minder
misverstanden over de gewenste functionaliteit en een forse versnelling in het gehele
traject.
1.2 Valkuilen
Automatiseringsprojecten brengen grote afbreukrisico’s met zich mee. Er zijn veel
gevallen bekend waarbij een uit de hand gelopen automatiseringsproject leidt tot grote
financiële problemen (zie de voorbeelden van Hershey en Samas).
Hershey
Hershey Foods Corporation uit Hershey, Pennsylvania (Verenigde Staten) is een snoepfabrikant met
een omzet van zo’n $5 miljard. Aangezien de onderneming deze miljardenomzet moet realiseren met
producten die per stuk minder dan een euro kosten, is volume een kritieke succesfactor. Dit stelt hoge
eisen aan de logistieke systemen van de organisatie. In 1996 begon Hershey met het moderniseren
van zijn IT-systemen en noemde dit project Enterprise 21. Dit project zou vier jaar duren, tot begin
2000. De doelen van Enterprise 21 waren:
• upgraden en standaardiseren van de hardware van de organisatie;
• de omschakeling van een mainframeomgeving naar een client-serveromgeving;
• just-in-timeleveringen aan afnemers mogelijk maken;
• het millenniumprobleem oplossen.
Deze doelen zouden kunnen worden gerealiseerd door een organisatiebreed informatiesysteem te
implementeren. De keuze viel op een ERP-oplossing (SAP) aangevuld met software van Manugistics
voor productieplanning, prognoses en vervoersbeheer, en software van Siebel voor relatiebeheer en
marketing. Omdat het millenniumprobleem een implementatie vóór 31 december 1999 noodzakelijk
maakte en de drukke periode voor Hershey – als snoepfabrikant – altijd in de maanden voor de
feestdagen (Halloween, Kerstmis, jaarwisseling) ligt, werd besloten om de implementatie in april 1999 –
de rustige periode – uit te voeren. In principe werd gekozen voor een ‘big bang’ implementatie, waarbij
in één keer van de oude systemen op het nieuwe systeem werd overgestapt. Het project liep echter
achter op schema en het was duidelijk dat een verantwoorde implementatie pas op zijn vroegst in juli
1999 kon plaatsvinden. Vooral de orderverwerkingssystemen van SAP en de koppelingen met de
systemen van Manugistics en Siebel hadden behoorlijke vertraging opgelopen. De conversie van
Hershey’s oude systemen naar het nieuwe systeem liep niet goed met als gevolg dat al vanaf het begin
van de implementatie logistieke problemen ontstonden die ertoe leidden dat de Hershey-producten niet
meer in de schappen van de winkels terechtkwamen en consumenten overstapten op producten van
concurrenten, waaronder Mars. Begin februari 2000 rapporteerde Hershey een 11% omzetdaling in
kwartaal 4 van 1999 ten opzichte van kwartaal 4 in 1998.
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
3
Noordhoff Uitgevers bv
Samas
Samas is een grote kantoorinrichter met een omzet van zo’n 250 miljoen euro. De onderneming heeft
vestigingen in heel Europa, waaronder Nederland, Duitsland, Frankrijk en Zwitserland en levert veel
aan eigen vestigingen. Samas produceert zelf, soms op klantspecificatie, maar levert ook producten
van derden. In juli 2006 ging Samas live met diverse SAP-modules en vulde dat een jaar later aan met
Every Angle, een systeem voor Performance Management op operationeel niveau. Het SAP-systeem
zou de diverse vestigingen aan elkaar moeten koppelen. De implementatie heeft Samas aan de rand
van de afgrond gebracht. In Nederland waren de problemen zo groot dat de onderneming voor 35
miljoen euro nieuwe aandelen moest uitgeven en een deel van haar onroerend goed moest verkopen
om daarmee voldoende werkkapitaal te creëren. Volgens de per 1 september 2007 aangetreden CEO
Coen van der Bijl zijn de verschillen in de organisatie te groot om daar één geïntegreerd
informatiesysteem voor te kunnen ontwikkelen. Als voorbeeld noemt hij dat leveringen in Duitsland
vooral via dealers en in Frankrijk vooral via eigen vestigingen plaatsvinden. Vanuit SAP werd
verklaard dat het niet zozeer het pakket was, maar de weigering van Samas om de adviezen van SAP
op te volgen. De ex-CEO (tot 1 september 2007) Hans van der Ven noemde zélf als oorzaak dat niet
SAP de problemen heeft veroorzaakt maar de timing van de implementatie. Het nieuwe systeem werd
namelijk ingevoerd op een moment dat er meer orders dan gebruikelijk binnenkwamen. De oude
orders moesten ook worden ingevoerd, waardoor een te hoge werkdruk ontstond, ondanks het feit dat
het ERP-implementatieteam uit zo’n 40 personen bestond.
Oorzaken van het mislukken van automatiseringsprojecten zijn onder andere:
1. onduidelijke specificaties;
2. te lange en te grote projecten;
3. onoverzichtelijke bestaande systemen en erfenisproblemen;
4. communicatieproblemen tussen gebruikers en IT-deskundigen;
5. slecht projectmanagement.
Ad 1 Onduidelijke specificaties
De specificaties van het te programmeren of aan te schaffen pakket zijn niet of
onvolledig gedocumenteerd. Alle partijen denken dat iedereen een goed beeld heeft
van wat het eindproduct zou moeten zijn: ‘Dat spreekt toch vanzelf?’. Gaandeweg blijkt
dat partijen heel andere ideeën hebben over wat vanzelfsprekend leek. Bijvoorbeeld,
een handelsbedrijf besluit tot aanschaf van een nieuw pakket. De directeur heeft het
pakket al bij een vriend, die ook een handelsbedrijf heeft, zien draaien en heeft via
deze partij een commercieel zeer aantrekkelijke prijs gekregen. Om redenen van
bezuiniging is er geen analyse gemaakt of het pakket wel aan de specifieke wensen
van de organisatie voldoet. Al op de tweede dag van de invoering worden enkele
serieuze tekortkomingen geconstateerd:
• Het pakket is niet uitgerust om vreemde valuta te registreren.
• Het pakket kan geen deelleveringen registreren of omgaan met
leveringsverschillen, terwijl dit in de branche waarin deze organisatie opereert
wel gebruikelijk is.
• Het pakket werkt zeer traag op de bestaande hardware van de organisatie.
Binnen twee weken besluit het management op zoek te gaan naar een pakket dat wél
aan de specifieke eisen voldoet. Hoewel dit voorbeeld fictief is, komt dit soort situaties
regelmatig voor. Zeker in het MKB is er nog wel eens sprake van misplaatste
zuinigheid.
Ad 2 Te lange en te grote projecten
Soms lijken de ambities van organisaties met betrekking tot hun geautomatiseerde
systemen erg ver te gaan. Er worden dan zeer grootschalige projecten opgezet met
4
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
2011, Noordhoff Uitgevers bv
een geschatte doorlooptijd van meerdere jaren. Omdat organisaties tegenwoordig zeer
snel moeten mee veranderen met hun omgeving, is het haast onontkoombaar dat
gedurende het automatiseringsproject alweer aanpassingen noodzakelijk zijn in
programmatuur die nog niet eens in gebruik is genomen.
Ad 3 Onoverzichtelijke bestaande systemen en erfenisproblemen
Eén van de belangrijkste IT-problemen in grote organisaties is het erfenisprobleem.
Zeker organisaties die als eerste grootschalig hebben geautomatiseerd (waaronder
verzekeraars en banken) hebben last van de wet van de remmende voorsprong. Deze
organisaties kampen vaak met een loden last van systemen die soms nog dateren uit
de jaren zeventig, met daarbij behorende verouderde technologie en verouderde of
ontbrekende systeemdocumentatie. Vaak is er op en rond deze systemen ook nogal
wat aangebouwd en aangepast, waardoor het geheel met behulp van een aantal
schillen en interfaces aan elkaar is geknoopt. Een lappendeken is het gevolg. Een
gouden regel in dit soort omgevingen is: ‘zolang het draait, beslist niet aankomen’.
Organisaties waarvoor dit geldt, zijn vaak bang om hun systemen integraal te
vervangen en schuiven de problemen zo lang mogelijk voor zich uit. Omdat
vervanging op enig moment toch onvermijdelijk wordt, kiezen deze organisaties vaak
voor vervanging per module. Deze oplossing werkt wel, maar brengt relatief veel
kosten met zich mee, omdat van iedere nieuwe module wordt verwacht dat deze ook
blijft communiceren met de oude programmatuur en er dus steeds interfaces moeten
worden meeontwikkeld.
Ad 4 Communicatieproblemen tussen gebruikers en IT-deskundigen
Een klassiek probleem is de moeizame communicatie tussen de gebruikers van
systemen en degenen die deze ontwikkelen of verkopen. De gebruiker spreekt niet de
taal van de informatieanalist en andersom. Hierdoor zijn in het verleden heel wat
projecten misgegaan. Softwarebureaus hebben de afgelopen jaren hard gewerkt om
deze communicatiekloof te dichten. Veel van deze bureaus zijn georganiseerd per
branche (zoals de transportbranche, de handel, of de financiële dienstverlening).
Medewerkers van deze bureaus volgen niet alleen cursussen in programmeren en
andere technische vaardigheden maar ook branchespecifieke opleidingen die hun
klanten volgen. Op deze wijze ontstaat er wel een gemeenschappelijke taal.
Door nieuwe ontwikkelingen dreigen er soms nieuwe varianten van
communicatiestoornissen te ontstaan. Bedrijven gaan steeds vaker over tot het
uitbesteden van programmeeractiviteiten aan het buitenland. Vooral India staat
hiervoor sterk in de belangstelling, vanwege de lage loonkosten en het hoge analytisch
niveau van de desbetreffende medewerkers. Bij het uitbesteden merken bedrijven dat
één van de belangrijkste uitdagingen is het goed organiseren van de communicatie
tussen gebruikers hier en de programmeurs daar. Dit is vaak een combinatie van een
taalprobleem en cultuurverschillen.
Ad 5 Slecht projectmanagement
Ondanks alle hulpmiddelen, boeken en voorgeschreven aanpakken is heel vaak het
slechte of ontbrekende projectmanagement de oorzaak van problemen. Bij een project
draait het om het beheersen van de drie variabelen tijd, kosten en prestaties. In veel
gevallen zien we dat projecten op alle drie de kwaliteitsaspecten niet het gewenste
resultaat opleveren. De oorzaken liggen dan vaak simpelweg in een gebrek aan
managementaandacht voor deze aspecten, dan wel in frequente personele
wisselingen in het projectmanagement, prioriteiten en de wijze van aansturen.
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
5
Noordhoff Uitgevers bv
2 Indirecte en directe effecten van ERP-systemen
Enterprice Resource Planning (ERP) heeft zowel directe als indirecte effecten op de
beheersingssystemen van organisaties. Directe effecten zijn onder andere:
• Meetpunten, zoals de overdracht van informatie via documenten van de ene
persoon aan de andere, zijn geïntegreerd in het informatiesysteem en zijn
daardoor niet meer zichtbaar. Dit is de essentie van ERP, waarbij eenmalige
invoer moet leiden tot datagebruik op verschillende plaatsen in de organisatie.
Door dit principe te volgen worden gebruikerscontroles minder relevant, omdat
deze veelal plaatsvinden door handmatig aansluitingen te maken tussen invoer
en uitvoer. Bijvoorbeeld, het geven van kwijting voor een goederenontvangst
door het zetten van een handtekening op een interne order vindt bij ERP plaats
in het systeem. Alleen als er een geprogrammeerde procedure is die de
ontvanger vraagt zijn elektronische handtekening te zetten (wat
efficiëntieverlagend en in strijd met de ERP-principes werkt), zal er een
meetpunt zijn. Dit is derhalve een negatief effect van IT op control.
• Het gedwongen gebruik van bepaalde programmamodules en het afdwingen
van bepaalde handelingen in een bedrijfsproces waardoor beheersing wordt
weggenomen bij mensen en in handen wordt gelegd van geprogrammeerde
procedures in de computer. Dit is een instrument om beheersingsproblemen te
vermijden en heeft als zodanig een positief effect op control.
• Controls migreren van de uitvoeringsfase naar de implementatiefase van
geautomatiseerde systemen. Bij de ontwikkeling van informatiesystemen zullen
controletechnische functiescheidingen tussen programmeurs, operateurs,
testgebruikers, informatieanalisten en dergelijke in acht moeten worden
genomen en zullen bepaalde controles moeten worden ingebouwd in het te
ontwikkelen systeem. Als het systeem dan in gebruik wordt genomen, hoeven
er niet veel controles nog handmatig te worden geïnitieerd, omdat deze al zijn
geprogrammeerd en omdat er bij de ontwikkeling zorgvuldig te werk is gegaan.
Dit kan zowel positieve als negatieve effecten op de controls van een
organisatie hebben.
Indirecte effecten van ERP op beheersingssystemen zijn een gevolg van de vaak
noodzakelijke herstructurering van organisaties als een ERP-systeem wordt
geïmplementeerd. Als een organisatie ervoor kiest een procesoriëntatie te volgen in
plaats van een functionele, omdat dit beter aansluit bij het te ontwikkelen ERPsysteem (zie hoofdstuk 4), dan kan dit leiden tot een doorbreking van de gewenste
controletechnische functiescheiding. Het gaat hier om de volgende drie principes die
ten grondslag liggen aan een procesoriëntatie:
1. Laat gebruikers van uitkomsten van processen die processen ook zelf
uitvoeren; dit betekent dat een functievermenging optreedt tussen beschikken
en bewaren. Bijvoorbeeld, vanuit een proces worden goederen besteld bij de
leverancier en tevens ontvangen en opgeslagen.
2. Laat diegenen die informatie produceren die informatie ook verwerken; dit
betekent dat een functievermenging optreedt tussen beschikken en registreren.
Bijvoorbeeld, vanuit een proces worden goederen besteld, maar tevens worden
in dat proces de noodzakelijke boekingen in het grootboek gemaakt.
3. Leg beslissingsbevoegdheden laag in de organisatie en maak gebruik van IT
om bepaalde handelingen af te dwingen; dit betekent een functievermenging
tussen beschikken en controleren. Bijvoorbeeld, het vergelijken van de order
van de goederenontvangst met de ontvangen factuur naar aanleiding van een
inkooptransactie zal binnen het proces gebeuren waarin ook de order is
geplaatst en de registratie daarvan is gebeurd.
De functievermenging die ontstaat ten gevolge van de keuze voor een procesoriëntatie
leidt tot een zwakkere interne beheersing. Doordat er functievermenging optreedt, zijn
de mogelijkheden om verbandscontroles uit te voeren ook beperkter. Dit heeft ermee
te maken dat verbandscontroles alleen dán zinvol zijn als de cijfers die met elkaar in
verband worden gebracht uit verschillende bronnen – afdelingen bijvoorbeeld –
6
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
2011, Noordhoff Uitgevers bv
afkomstig zijn. Doordat bij een procesoriëntatie de bronnen van de desbetreffende
cijfers zijn samengevoegd tot één proces, verliezen veel verbandscontroles hun
relevantie. Als cijfers uit een en dezelfde bron afkomstig zijn, dan zal de kans dat ze
aansluiten op elkaar immers vele malen groter zijn dan wanneer deze cijfers uit
verschillende bronnen afkomstig zijn, simpelweg omdat in het proces maatregelen
kunnen worden getroffen om de verbanden sluitend te maken. Er zijn hier twee
mogelijke problemen:
1. Als in deze situatie de oorzaak van het niet-sluitend zijn van een verband wordt
weggenomen, bijvoorbeeld door de voorraadregistratie in overeenstemming te
brengen met de feitelijk aanwezige voorraad en het verschil naar de
resultatenrekening te boeken, dan is dit weliswaar acceptabel, maar de goede
werking van het systeem dat hierachter zit, is hiermee afhankelijk geworden
van de goede wil van de mensen in het proces.
2. Als in deze situatie de cijfers worden gemanipuleerd in plaats van ze in
overeenstemming te brengen met de werkelijkheid, dan is dit fraude. Dit zou
echter niet mogelijk zijn geweest als de interne beheersing adequaat was
geweest. Derhalve is dit een ernstige zwakheid in de interne beheersing.
Ter compensatie zullen in beide gevallen andere beheersingsmaatregelen moeten
worden getroffen.
Hierbij kan worden gedacht aan cultuurbeheersingsmaatregelen gericht op
doelcongruentie, personeelsbeheersingsmaatregelen gericht op motivering van het
personeel en het aannemen van de juiste mensen (zie de case ‘Control in een Internet
startup’), cijferbeoordelingen in plaats van verbandscontroles om te toetsen of
bepaalde cijfers wel kloppen met verwachtingen dienaangaande, meer direct toezicht
door de proceseigenaar (supervisie), en een systeem van prestatiebeloningen waarbij
bonussen en dergelijke binnen elk proces gelijkelijk over de medewerkers worden
verdeeld (groepsgewijze beloningen).
Control in een internet startup
Een internetonderneming, die zeven jaar geleden is opgericht en de ‘shake out’ heeft
overleefd, heeft inmiddels zo’n 100 mensen in dienst. Eén van de medewerkers van het
eerste uur verzucht: ‘We gaan nu eindelijk een positieve cash-flow draaien. Het waren
hectische jaren, maar ik zou ze voor geen goud hebben willen missen. Nu we groter zijn
geworden, zijn wél heel wat dingen veranderd. Niet allemaal ten goede. Wat mij nog het
meest stoort, is dat we vroeger met ons kleine team precies wisten waar we naartoe
wilden. We waren het daarover eens en we hadden enthousiaste en capabele mensen.
Management-controlproblemen waren er eigenlijk niet. We merken nu voor het eerst dat
er serieuze problemen op dit terrein ontstaan. Onze mensen doen niet meer als vanzelf
wat goed is voor de onderneming. Ze moeten veel meer worden geprikkeld door middel
van prestatiebeloning. We doen dat gewoon, want het is een illusie dat je het
enthousiasme van de beginjaren kunt blijven vasthouden.’
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g
7
Noordhoff Uitgevers bv
3 Interorganisationele informatiesystemen
Met het integreren van informatiesystemen binnen organisaties is nog lang niet het
eindpunt van IT-ontwikkelingen bereikt. De laatste jaren zien we steeds vaker dat in de
waardeketen organisaties hun informatiesystemen op elkaar gaan afstemmen om
zodoende efficiëntie- en concurrentievoordelen te behalen. Een voorbeeld is eprocurement, waarbij de productcatalogus van verschillende leveranciers wordt
gedownload in de informatiesystemen van de inkopende organisatie, waarna
bestellingen binnen raamcontracten door de gebruikersafdeling – niet alleen de
inkoopafdeling – elektronisch kunnen worden geplaatst bij de desbetreffende
leveranciers. Iets verder gaat het zogeheten Vendor Managed Inventories (VMI),
waarbij de leverancier in de voorraadadministratie van de inkopende organisatie kan
kijken en de voorraad uit eigen beweging mag aanvullen, waarna de inkopende
organisatie de ontvangen levering betaalt zonder daarvoor eerst een factuur te hebben
ontvangen. De stand van de techniek speelt een grote rol bij dit soort ontwikkelingen.
Door de opkomst van Radio Frequency Identification (RFID-)technologie is het
bijvoorbeeld mogelijk om goederenzendingen van een RFID-chip te voorzien die door
scanapparatuur kan worden herkend, mits binnen een bepaalde afstand, waardoor
logistieke ketens vele malen efficiënter kunnen functioneren. RFID-technologie maakt
gebruik van zogenoemde Near Field Communication (NFC), wat betekent dat er geen
fysiek of visueel contact tussen de chip en de scanner hoeft te zijn om gegevens te
kunnen uitwisselen. Een RFID-chip moet wel een code bevatten. Welke code bij de
betrokken organisaties in de eigen informatiesystemen moet zijn gekoppeld aan de
goederen waaraan de chip is bevestigd. Het is van groot belang dat er op dit terrein in
de waardeketen wordt samengewerkt, want bij elke schakel in de keten die meewerkt
aan een RFID-oplossing, nemen de voordelen van het gebruik van deze technologie
sterk toe. Walmart (een grote Amerikaanse detailhandel) wilde zijn toeleveranciers
verplichten RFID-chips al bij het verzenden van de goederen aan te brengen om aldus
maximaal voordeel te behalen uit deze technologie. Zou Walmart dit alleen binnen de
eigen organisatie hebben uitgerold, dan zouden de kosten per RFID-chip te hoog zijn
geweest. Overigens heeft Walmart op een bepaald moment besloten dat het het RFIDsysteem niet zoals aanvankelijk gepland in alle vestigingen over de hele wereld wilde
implementeren, maar slechts in een beperkt aantal pilotvestigingen. De belangrijkste
redenen hiervoor waren dat de leveranciers nog niet voldoende wilden meewerken
met het aanbrengen van de chips op de door hen te leveren goederen.
8
Addendum H o o f d l ijn e n B e s t uur lijk e In f o r ma t ie v o o r z ie n in g