Strijd tussen ontwikkeling en beheer

17 oktober 2008
Projecten ervaren IT-beheer vaak als belemmering voor vernieuwingen. IT-beheer daarentegen ervaart vernieuwingsprojecten vaak als bedreiging voor de continuïteit van de bestaande IT-dienstverlening. De business echter heeft systemen nodig die voldoen aan de eisen van functionaliteit, beschikbaarheid en betrouwbaarheid, en tegelijkertijd vernieuwingen die snel, flexibel en foutloos worden ingevoerd.

Interne strijd binnen het IT-domein als gevolg van het ogenschijnlijke dilemma tussen ontwikkeling en beheer is ongewenst. Immers: dergelijke controverses zijn meestal non-productief, demotiverend, vertragend, kostenverhogend en leiden niet zelden tot een informatiesysteem dat niet voldoet aan de eisen van performance en beschikbaarheid.
Er zijn praktijkvoorbeelden te over die (deels) het gevolg zijn van deze ‘verzuilingsproblematiek’. Om er enkele te noemen: C2000, de automatisering bij de politie, de Belastingdienst, de frequente onbeschikbaarheid van Postbank.nl.
We kunnen dit beschouwen als ongewenste neveneffecten van wat in de literatuur ‘het natuurlijke krachtenveld tussen beheer en ontwikkeling’ wordt genoemd. Maar is deze tegenstelling tussen projectorganisatie en beheerorganisatie wel nodig?

Iedereen is het erover eens dat de partijen bij elkaar gebracht moeten worden. De vraag is alleen: Hoe breng je de partijen op één lijn, waardoor zowel stabiliteit als flexibiliteit wordt gewaarborgd en vernieuwingsprojecten en beheer samen succesvol kunnen zijn in een wereld van continue verandering?
Er is al veel geschreven over de succesfactoren van IT-projecten: samenwerking tussen business en IT, projectmanagement, opdrachtgeverschap, reduceren van omvang en complexiteit, vastleggen van uitgangspunten, randvoorwaarden en resultaten. Eén belangrijke succesfactor wordt daarbij vaak vergeten: het slechten van de kloof tussen IT-beheer en IT-ontwikkeling.

Er zijn een aantal factoren te onderkennen die bijdragen aan deze kloof: focus (1), methodieken (2) en organisatie (3).
Het lijkt een open deur, maar de sleutel tot het overbruggen van de kloof tussen beheer en ontwikkeling is ‘samenwerking’. Maar als het zo simpel is, waarom bestaat het probleem dan nog? Welnu: ‘dat’ samenwerking gecreëerd moet worden is duidelijk, maar ‘hoe’ doe je dat? De crux zit hem in het moment en de manier waarop die samenwerking wordt vormgegeven.

Doorgaans zijn, behalve klant en gebruikers, vier partijen betrokken bij IT-veranderingsprojecten: de beheerorganisatie, de projectorganisatie, de opdrachtgever en het senior management. Wat moeten zij concreet doen om de kloof tussen beheer en ontwikkeling te dichten?
  • De beheerorganisatie wordt een actieve partner, die meewerkt in het project en tijdig en onderbouwd aangeeft onder welke voorwaarden veranderingen welkom zijn.
  • De projectorganisatie neemt beheer op in het project en levert een product waarvan de beheereisen als onderdeel van het ontwerp al zijn meegenomen.
  • De opdrachtgever ziet toe op de integratie van beheer in het project en neemt beheervertegenwoordiging op in de projectsturing.
  • Senior management dwingt de gelijkwaardige benadering van beheer en ontwikkeling af.
Deze aanpak herstelt de balans tussen beheer en ontwikkeling binnen een projectstructuur. Het zorgt ervoor dat zowel de beschikbaarheid van de bestaande dienstverlening als de benodigde flexibiliteit ten behoeve van nieuwe dienstverlening de aandacht krijgt die ze verdient.
Bijkomend resultaat is een toename van begrip, respect en waardering voor elkaars vakgebied. Waardoor het plezier in het werk zal toenemen. En dat is, zoals we allang weten, goed voor de productiviteit en daarmee voor het bedrijfsresultaat. En daar was het allemaal om begonnen.

Bert Duiverman MBA (duim.interim@tiscali.nl) is als interim-manager en consultant/coach werkzaam via Duim Interim Management BV.

Kloof tussen IT-beheer en IT-ontwikkeling
De beheerorganisatie levert algemene acceptatiecriteria op zodat projecten van tevoren weten waar ze aan toe zijn. Deze dienen concreet genoeg te zijn om als input te kunnen dienen bij de ontwerpfase van veranderingen. Voorbeelden zijn criteria op het gebied van infrastructuur, veiligheid, back-up- en recovery, herstartbaarheid, onderhoudbaarheid, foutafhandeling, opleiding en productiedocumentatie.

Bij de opstart van elk project stelt de beheerorganisatie iemand beschikbaar. Deze beheerder maakt volwaardig deel uit van het project en heeft als specifieke verantwoordelijkheid:
  • inbrengen van beheerexpertise;
  • algemene acceptatiecriteria vertalen naar het specifieke project;
  • in kaart brengen van de effecten van het project op de beheerorganisatie;
  • vanuit de projectverantwoordelijkheid opleveren van de benodigde beheerproducten aan de eigen beheerorganisatie.
Te denken valt hierbij aan productiedocumentatie, testsets voor productieacceptatietests en beheerprocedures. Het opleveren van deze beheerproducten is een go/no go voor de implementatie van het projectresultaat.
Er wordt pas decharge verleend aan het project als het resultaat expliciet is geaccepteerd door IT-beheer, en de veranderingen gedurende een vooraf bepaalde tijdsduur succesvol productie hebben gedraaid.

Het dichten van de kloof
Projecten en beheer bezitten hun eigen methodieken. Deze sluiten in de praktische uitwerking niet expliciet op elkaar aan.
Bij projecten wordt gebruikgemaakt van een standaardfasering, die in stappen leidt van ideevorming tot implementatie (IPMA, Prince 2). De stappen tot aan de invoering in een productieomgeving worden gedetailleerd beschreven. Aan de daadwerkelijke productie-implementatie wordt weinig aandacht besteed. Al te vaak wordt na een geslaagde gebruikerstest het nieuw ontwikkelde systeem overgedragen aan de beheerorganisatie. Die dient dan vervolgens voor de implementatie en de inrichting van het beheer te zorgen.

In Prince2 wordt weliswaar voorzien dat er overdracht naar de beheerorganisatie moet plaatsvinden, maar in welke fase de betrokkenheid van beheer vorm moet krijgen en hoe, wordt in het midden gelaten.
IT-beheer bezit zijn eigen methodieken, zoals ITIL. Deze methodieken zijn vooral gebaseerd op reeds geïmplementeerde informatiesystemen. Weliswaar is er een geformaliseerd wijzigingsproces, maar dat wordt in de praktijk vooral gebruikt voor kleinere wijzigingen die productierijp worden geacht door de aanbieder. In een aangrijpingspunt van beheer naar projecten is niet voorzien.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!