Echelon 1: IndividuEchelon 2: CZSK
D. Historie MUNBIS
In subparagraaf 5.2.1 wordt verwezen naar een historie van de ontwikkeling van het MUNBIS. De lange historie van het project heeft ertoe geleid dat niet alle eenheden positief over het prograama zijn. Dit wordt in deze bijlage uitgelegd.
De analyse van het project in deze bijlage geeft aan hoe het kan dat de ‘problemen’ in het MUNBIS zijn ontstaan. Ook worden ‘lessons learned’ gegeven voor soortgelijke projecten in de toekomst.
D.1. Historie ontwikkeling MUNBIS
Het doel van de ontwikkeling van MUNBIS was, volgens de nota 2906/562 uit 1995 (MUNBIS, 17-08-1995) het ontwikkelen van een geautomatiseerd programma voor een beheerder van munitiebergplaats bij het Korps Mariniers31. Op 1 januari 1995
was bij het Korps Mariniers een (DOS-) versie van het MUNBIS in gebruik (Notulen eerste vergadering systeembeheergroep MUNBIS, 1995).
Een document waarin deze doelstelling wordt uitgewerkt in specifieke eisen is niet gemaakt of ‘kwijt’. Er is een grote kans dat het eerste geldt: de eerste opzet voor het programma is door een beheerder zelf gemaakt en men heeft dit
programma uitgewerkt zodat het ook door andere beheerders gebruikt kon worden. De werkwijze van lokaal beheer met behulp van de ‘groene-witte’ bladen is
gekopieerd. De evaluatie van logistieke processen was niet nodig, omdat het een stand-alone systeem was: bedoeld voor één fysieke beheerder.
In de eerder genoemde nota van 1995 wordt de noodzaak van
‘managementinformatie’ voor de ondersteunende afdelingen onderschreven, maar dit was van origine niet het doel van het programma. Rapportagemogelijkheden waren er wel, maar werden niet automatisch gegenereerd ten behoeve van bijvoorbeeld budgethouders. Hetzelfde geldt voor het ‘doorsturen’ van ABOM’s en STOBO’s naar coördinatoren (Notulen eerste vergadering systeembeheergroep MUNBIS, 1995).
De ontwikkelingen van het systeem is in gang gezet door een functionaris bij het CZSK, deze is later gaan werken bij een bedrijf die niet als ‘core-business’ het ontwikkelen en implementeren van software had.
De documentatie tussen oktober 1995 en september 1997 is (op korte termijn) niet beschikbaar. In de tussenliggende tijd is besloten om het MUNBIS een Windows- applicatie te maken en is besloten het MUNBIS ook (wanneer de Windows-versie beschikbaar is) te implementeren bij de vloot- en walinrichtingen.
Geleidelijk werd het duidelijk dat er behoefte was aan meer
managementinformatie en de logging van activiteiten. De managementinformatie moest bestaan uit data over aanvragen, stortingen en verbruiken. Men heeft onder andere ook het CVM beheer (wat in weze budgetbeheersing is) geïmplementeerd en ging denken over diverse rapportage-wensen. De logging van activiteiten moest voorkomen dat beheerders fraude konden plegen door ‘ongestoord’ gegevens te veranderen. Om dit tegen te gaan is het ‘historisch overzicht’ geïmplementeerd (Notulen voortgangsbespreking MUNBIS 28, 2001). Dit is een (primitief) soort logging van handelingen, waarbij de beheerder commentaar kan invoeren. Het MUNBIS bleef een stand-alone systeem, maar de data in de computers moest ineens ‘gekoppeld’ worden om managementinformatie te kunnen verkrijgen en de functionaliteiten van fysieke beheerders werden beperkt32. De geplande
implementatie was 1 januari 1998, maar deze is niet uitgevoerd of teruggedraaid. In de notulen voortgangsbespreking MUNBIS 23 (2000) wordt gezegd: “In korte
31 In voor de reorganisatie hoorde hier ook het opleidingscentrum in Rotterdam hierbij en de kazerne in
Texel (huisvesting van het amfibische bataljon).
32 Volgens mij is het niet (tijdig) onderkennen van deze tegenstrijdigheden cruciaal geweest voor het
project. Dit wordt uitgelegd in de volgende sectie. In 2000 is ook voorzichtig gezegd dat het toevoegen van extra functionaliteiten en toepassing op de gehele organisatie meer problemen veroorzaakten dan verwacht (Notulen voortgangsbespreking MUNBIS 17, 2000).
tijd zijn nu alle vertegenwoordigers [van de gebruikers van MUNBIS in de projectgroep] afgelost”.
Na 1998 wordt verder gewerkt aan het oplossen van ‘bugs’ en het implementeren van extra eisen, bijvoorbeeld het genereren rapportages in Excel-format. Ook de logistieke problemen die veroorzaakt worden doordat het MUNBIS de juiste data moet genereren voor het management, komen stapsgewijs bovendrijven en worden opgelost. De volgende geplande implementatiedatum is 1 april 2000 (Notulen voortgangsbespreking MUNBIS 10, 1999).
Op 12 juli 2001 (Notulen voortgangsbespreking MUNBIS 31) wordt de oplevering van (Windows) MUNBIS aangekondigd. De werkgroep voor de ontwikkeling van MUNBIS ‘opgeheven’, maar de leden gaat door als systeembeheergroep MUNBIS (SBG/MUNBIS). In de tijd daarna is de SBG/MUNBIS bezig met de
randvoorwaarden om de implementatie mogelijk te maken en het verzamelen bugs. De opleidingen voor gebruikers worden gestart. Gedurende deze periode is een contract afgesloten met een ander bedrijf voor de technische ondersteuning van het MUNBIS.
Op 19 december 2003 is MUNBIS versie 2.01 aangeboden voor implementatie bij de gebruikers (Nota 2003116503, Ter beschikkingstelling MUNBIS-KM productversie 2.01 op CD-ROM). Deze implementatie is stopgezet bij de vlooteenheden en walinstellingen op 26 juli 2004 (Nota 2004213850,
Opschorting uitrol MUNBIS-KM). Er was een noodzaak het MUNBIS grondig te reviseren. Hiervoor is een plan van aanpak geschreven, de doelstellingen van de revisie waren (Plan van aanpak revisie MUNBIS, 2005):
• Het ontwikkelen van een stabiel en betrouwbaar programma: de programmacode in de huidige versie was onoverzichtelijk en ongestructureerd en het ‘rekenen’ was niet foutloos.
• (Geavanceerde) logging aanbrengen, fouten waren in versie 2.01 moeilijk te traceren.
• Functionaliteit MUNBIS 2.01 behouden33.
De streefdatum voor de volledige implementatie van het gereviseerde MUNBIS is eind 2005. Er volgt nogmaals een volgende periode van het bepalen van
randvoorwaarden voor de implementatie en verzamelen van bugs. De huidige stand van zaken is dat het Korps Mariniers, het Caraïbisch gebied en enkele
walinstellingen beschikking hebben tot het MUNBIS. De planning is dat het MUNBIS voor het eind van 2006 ook bij de vlooteenheden geïmplementeerd is.
D.2. Evaluatie MUNBIS project
In deze sectie wordt de historie van ontwikkeltraject van het MUNBIS geanalyseerd, om uit te leggen welke consequenties dit voor het programma heeft gehad en herhaling van problemen bij de ontwikkeling en implementatie van toekomstige software te voorkomen.
Opeenstapeling van problemen
Wanneer duidelijk werd dat er meer van het programma werd verwacht dan alleen ondersteuning van fysiek beheer, heeft men niet eerst de logistieke processen op papier gezet middels een plan van eisen. Dit houdt in dat vastgelegd wordt welke afdelingen met het MUNBIS willen werken en per afdeling de benodigde
functionaliteiten en informatie beschreven worden. Dit leidde ertoe dat in het vervolgproces problemen stapsgewijs aan het licht kwamen, en bij het ontwerpen van nieuwe functionaliteiten ‘telfouten’ (die in vorige versies er niet waren) ineens opdoken. Er is nooit meer een foutloos programma geweest.
33 Dit is een uitspraak die niet veel waarde heeft, de functionele eisen zijn namelijk nooit duidelijk geweest.
Dubbele doelstelling: budget- en fysiekbeheer
Doordat er geen duidelijkheid was over de eisen van het MUNBIS, werden er niet alleen programmeerfouten gemaakt, maar het zorgde ook voor onduidelijkheid: wat wordt er verwacht van de Beheerders-01 tot en met de Beheerders-04
functionarissen. De Beheerder-01 en Beheerder-02 zijn namelijk geen fysieke beheerders maar (bugdet-) coördinatoren. De Beheerder-03 is in sommige gevallen beheerder en coördinator (bijvoorbeeld bij het Korps Mariniers), in sommige gevallen alleen coördinator (in het geval van de Wapenkamer in Den Helder, hier is geen fysiek beheer), in sommige gevallen alleen beheerder (vlooteenheden). De Beheerder-04 is in sommige gevallen alleen een ‘aanvrager’ voor bijvoorbeeld verbruik op een schietbaan (walinstellingen), in sommige gevallen ook een fysiek beheerder (in sommige gevallen bij het Korps Mariniers wanneer bijvoorbeeld een deel van een eenheid voor langere periode naar een schietkamp gaat).
Als men een programma van eisen had gemaakt had men misschien de tegenstrijdigheid tussen fysiek beheerder en (budget-) coördinator in een eerder stadium onderkend. Doordat dit niet het geval is geweest, is het programma voor fysieke beheerders die te maken hebben met het beheer van verschillende UKC’s34
(inclusief buitenlandse eenheden) geen verbetering van de papieren werkwijze. Implementatie fraudebestrijding
De logging van acties middels het ‘historisch overzicht’ is conform de Aanwijzing SG V/25 een goed idee, in de administratie moet te zien zijn wie de muteerder is. De wijze van implementatie is voor beheerders niet overzichtelijk. Het is altijd mogelijk fraude te plegen, maar fouten maken is menselijk. Het corrigeren van ABOM’s, STOBO’s, afgiftelijsten en voorraden is omslachtig.
Hiermee is een van de doestellingen van het MUNBIS (‘gemak voor de beheerder ten opzichte van de groene-witte bladen’) uit het oog verloren. Later is een betere logging naast het bestaande ‘historisch overzicht’ gaan draaien. Samenstelling en tijdbesteding projectgroep
In 2000 is opgemerkt dat alle vertegenwoordigers van de gebruikers van MUNBIS afgelost waren. In de daarop volgende jaren blijft dit voorkomen. Doordat er geen duidelijk beeld is van de ‘verwachtingen’ van het programma, moeten de nieuwe vertegenwoordigers zelf hierbij een beeld maken.
Een voorbeeld van de gevolgen van ‘wisselende bemanning’ is dat de benodigde rapportage aan het MunMag voor het bijhouden van afnemervoorraden al in 2000 vastgelegd werd (Notulen voortgangsbespreking 21 MUNBIS, 2000) al gemeld: “[Rapportage] MunMag: Per kwartaal: Novcode, NSN, benaming en aantal; per maand: Novcode, NSN, benaming Afn/Ukc, Lotnr en aantal35”). In SBG/MUNBIS
2002-05 (2002) is er weer onduidelijkheid over de informatie die verschillende rapportages dienen te bevatten. In het huidige programma is geen
rapportagemodule voor het MunMag geïmplementeerd.
In een conceptversie van het Plan van aanpak revisie MUNBIS (Plan van aanpak revisie MUNBIS, versie 0.2, 2004) wordt hierover gezegd: “Ervaringen uit het verleden geven de kennis dat overplaatsingen tijdens zo een project de voortgang verstoren. Daarom de werkgroep op persoon (niet op functie) instellen.” Dit is echter niet uitgevoerd, waarschijnlijk heeft de reorganisatie van 2005 hiermee te maken.
Een ander punt is dat wat begon als een lokaal beheersysteem, uitgroeide tot een uitgebreid ondersteuningsprogramma. De werknemers in de projectgroep hebben naast hun dagelijkse werkzaamheden veel tijd gestoken in het MUNBIS, maar misschien was er voor de ontwikkeling van een adequaat programma wel veel meer tijd nodig.
34 Een eenheid wordt, om kosten inzichtelijk te maken, gecodeerd met een UKC (Uniforme Kostendrager
Code)
Verwachtingen ontwikkelaars
In het begin van het project is het programma ontwikkeld door een bedrijf waarvan de ‘core-business’ niet het ontwikkelen en implementeren van software is. De omvang van het project werd steeds groter, er is toen een ander bedrijf
gecontracteerd. Deze is niet erg betrokken geweest bij de implementatie en had problemen met het interpreteren van de gewenste functionaliteiten.
Gevolgen van testtrajecten
In het project zijn verschillende testdagen en implementatiemomenten (met of zonder schaduwdraaien) geweest. Dit leidde tot de constatering knelpunten waarbij telfouten in de programmatuur door eindgebruikers ontdekt werden (zie
bijvoorbeeld Nota 44/1MB/02, Rapportage MUNBIS). Men kan zich voorstellen dat wanneer dit een functionaris, die niet betrokken is in de ontwikkeling van het product, meerdere malen overkomt, deze het vertrouwen in het project enigszins verliest.
Implementatiemoment bij gebruikers
Tijdens testdagen zijn telfouten in het programma in principe niet erg, behalve uit het oogpunt van acceptatie door gebruikers. Bij de werkelijke implementatie zijn er ook nog ‘telfouten’ in het programma ontdekt. Dit is in tegenstrijd met een van de doelstellingen van het MUNBIS (‘minder telfouten’) en is in het kader van
nultolerantie onacceptabel. D.3. Conclusies
De munitiebeheerders zijn op een aantal punten niet zo tevreden over het MUNBIS: • Het beheren van UKC’s van ‘derden’.
• Implementatie van fraudebestrijding.
• Programmafouten bij testmomenten en implementatiemomenten. Het aanpassen van het MUNBIS is echter niet wenselijk, gezien de lange looptijd van het project en het feit dat de software vervangen gaat worden door het ERP- informatiesysteem36 (Plan van aanpak revisie MUNBIS, versie 0.4, 2004, p.9).
In de toekomst zal bij het ontwikkelen en implementeren van software een Plan van Eisen gemaakt moeten worden. Dit had voor het MUNBIS een opeenstapeling van problemen en de tegenstrijdige functionaliteiten van beheerders op kunnen lossen.
De samenstelling van de projectgroep die het MUNBIS had, is meerdere malen gewijzigd. Ook was het MUNBIS voor de leden een ‘bijtaak’. Een dergelijk groot project verdient een projectgroep van het begin tot de acceptatie van het systeem voldoende tijd heeft hierbij betrokken te zijn. Bij een dergelijk project is het raadzaam een gespecialiseerd extern bedrijf in te schakelen die nauw betrokken is bij de ontwikkeling en implementatie van het programma.
D.4. Gebruikte bronnen
Berichten en nota’s
Bureau Organisatie en Informatie Korps Mariniers. MUNBIS. 2906/562 (nota), 17- 08-1995.
Commandant Eerste Mariniersbataljon. Rapportage MUNBIS. 44/1MB/02 (nota), 12- 04-2002.
Hoofd afdeling Wapen- en Communicatiesystemen DMKM. Terbeschikkingstelling MUNBIS-KM productversie 2.01 op CD-ROM. 2003116503 (nota), 19-12-2003.
36 Bij Defensie wordt een Enterprise Resource Planning systeem (ERP-systeem) ingevoerd middels door SAP
geleverde software. ERP heeft als voornaamste doel de processen af te stemmen en informatievoorziening tussen afdelingen te verbeteren. De projectgroep SPEER houdt zich bezig met de (Defensie-brede) invoering hiervan, waarbij de meeste materieellogistieke en financiële IT-systemen vervangen worden (Masterplan SPEER, 2005, p.12).
Hoofd afdeling Wapen- en Communicatiesystemen DMKM. Opschorting uitrol MUNBIS-KM. 2004213850 (nota), 26-07-2004.
Overige bronnen
DMKM/WCS, Plan van Aanpak revisie MUNBIS. Versie 0.4, definitief, 17-03-2005; Versie 0.2, 23-11-2004.
Masterplan SPEER (2005). Intranet
http://intranet.mindef.nl/portaal/bedrijfsvoering/
projecten/SPEER/programma_SPEER/Documentatie/Documentatie.aspx. Versie 2.0.0, definitief, 05-04-2005.
Notulen eerste vergadering systeembeheergroep MUNBIS, 19-05-1995. Notulen voortgangsbespreking MUNBIS. Nummers 10, 13-08-1999; 17, 03-03-
2000; 21, 06-07-2000; 23, 03-10-2000; 28, 03-04-2001; 31, 12-07-2001. Notulen SBG/MUNBIS 2002-05, 14-11-2002.