Mapping beheerprocessen over projectfasering

In een mapping koppelen we beheerprocessen aan de projectfasering. De IT-beheerprocessen zijn gericht op fysieke handelingen met IT-objecten. Daarbij moet je bijvoorbeeld denken aan het inrichten van een werkplek, de installatie van een module of het toekennen van een autorisatie. Met behulp van deze processen kunnen we ook series verwerken, doch altijd series van gelijksoortige objecten.

Projecten daarentegen bestaan uit meerdere fases of sprints waarin we door middel van verschillende activiteiten naar een bepaald einddoel werken. Dit einddoel is in veel gevallen een samengesteld geheel van infrastructurele objecten, software en de AO (Administratieve Organisatie). Tijdens het project wordt dit geheel opgebouwd en is het al snel noodzakelijk om planmatig IT-beheerprocessen te triggeren om dit te bewerkstelligen.

In dit artikel geven we door middel van een mapping aan op welk moment we in welke fase welk IT beheerproces triggeren. Tevens geven we in de mapping aan wie welke verantwoordelijkheid daarin heeft.

Vooraf regelen

1. De IT-beheerprocessen zijn zo ingericht dat ze aansluiten op de (ontwikkel) methodiek die een organisatie kiest en de richtlijnen die daar van afgeleid zijn. De betrokkenen dienen zich aan deze standaarden te conformeren. Het is aan te bevelen om uit te gaan van een Best Practice aanpak zoals ITIL. Dat zijn standaard processen die jezelf kunt invullen.
2. Alle applicaties binnen de organisatie zijn geclassificeerd op basis van (financieel) belang en beschikbaarheidseisen. Deze classificaties zijn in de SLA vastgelegd. Hieronder kunnen zich applicaties bevinden met de classificatie Zeer Kritisch. Aangezien we één homogene technische infrastructuur is voor alle applicaties nastreven is er ook slechts één set van processen en procedures geldig. Deze processen zijn dan gebaseerd op de hoogste classificatie die we binnen de organisatie hanteren.
3. In bepaalde gevallen kunnen we van procedures afwijken. Dit kan zijn bij:
   a. Spoedeisende correctieve opdrachten.
   b. Technische calamiteiten.
   c. Geïsoleerde pilotprojecten.

Het besluit om af te wijken van de procedure of proces dient het management te nemen en kan alleen plaatsvinden als ze de reden documenteren (Comply or Explain). Daarnaast dienen we het besluit, de genomen stappen en de rol van de diverse functionarissen vast te leggen.

Project fasering en mapping

De projectfasering zoals die er bij een organisatie uit zou kunnen zien bestaat vaak uit de volgende onderdelen:

1. Business Analyse.
2. Informatie of Requirements Analyse.
3. ProgrammaOntwerp.
4. Realisatie.
5. Acceptatietest.
6. Invoering.
7. Exploitatie.

Als sprake is van een Scrum aanpak kun je deze activiteiten per sprint in een micro variant herkennen.

De Business Analyse vindt zijn weerslag vaak in een jaarplan voor de automatisering. Dit plan bevat een opsomming van projecten die door het management zijn vastgesteld. Als er later andere spoedeisende projecten opdoemen (b.v. naar aanleiding van nieuwe regelgeving) heeft dit gevolgen voor het vastgestelde jaarplan. Deze projecten kunnen alleen opgestart worden na een beslissing van het management.

Een project start in de regel met een Informatie of Requirements Analyse waarin we de informatiebehoeften van de gebruikers in kaart brengen. Er wordt dan een keuze gemaakt voor het vervolgtraject (maatwerk of standaardpakket) en voor de te volgen fasering wordt een plan gemaakt.

Gedurende de levensduur van een applicatie kunnen zich een aantal gebeurtenissen voordoen die een samenhang hebben met de beschreven projectfasering. Veel van deze gebeurtenissen zijn al gevat in een beheerproces. Deze beheerprocessen hebben geen ander doel dan de communicatie over de gebeurtenissen en hun gevolgen te stroomlijnen en de afwikkeling vast te leggen.

Een eenduidige vastlegging maakt het bovendien mogelijk om de gang van zaken te herleiden en verantwoording af te geven over de afwikkeling van de gebeurtenissen.

Betrokken IT professionals opnemen in mapping

IT Organisatie

Binnen de organisatie dienen we een duidelijke functiescheiding van IT-taken en een verdeling van verantwoordelijkheden te maken. Globaal zijn 3 groepen te onderscheiden.

1. Functioneelbeheer (vaak onderdeel van de gebruikersorganisatie).
2. Technisch applicatiebeheer (Ontwikkel Organisatie intern of extern).
3. Technisch systeembeheer (Verwerkingsorganisatie, rekencentrum intern of extern).

Accenten

Vanuit het verleden herkenden we deze groepen aan hun specifieke taken.

De Functioneel Applicatiebeheerder hield zich veel bezig met het bijhouden van stambestanden, het aanbieden van batchjobs en de controle op de verwerkingen. Tegenwoordig ligt het accent meer bij het vertalen van gebruikerswensen en requirements naar systeemeisen, het bewaken van de aansluiting tussen de verschillende applicaties en het leiden van projecten en releases.

Het beeld dat in het verleden bij het technisch applicatiebeheer werd opgeroepen was toch vooral die van programmeur die lange tijd bezig was om een programma te maken. In deze functie is echter een duidelijke accentverschuiving geweest in de richting van Informatie-analyse en het beheer van de ontwikkelomgeving/standaard. Doordat ontwikkeltools nu een groot deel van de code genereren is de ontwikkelaar meer gericht op de gebruiker en zijn requirements. Mede dankzij de invoering van SCRUM is er bovendien meer interactie en afstemming.

Het technisch systeembeheer tenslotte heeft ook een verandering doorgemaakt. De helpdeskmedewerker die naar je toe komt om je PC te fiksen of bijvoorbeeld de operator die uren bezig met het wisselen van tapes zijn verleden tijd. Het accent van het bewaken op de juiste verwerking van systemen is verlegd naar de inrichting van de juiste omgeving met de juiste componenten met als insteek om verstoringen zo veel mogelijk (pro-actief) te voorkomen. DevOps slaat echter een brug tussen deze 3 werelden.

Rollen tijdens een project

Iedere fase eist van de betrokkenen vaak een andere rol. Daarnaast kan deze rol per project verschillen. Zo treed je de ene keer op als opdrachtgever en een andere keer als klankbord, tester of reviewer. De ene keer treed je op als ontwikkelaar van een systeem en de andere keer analyseer je de aansluiting van een standaard pakket op het datamodel. In het ene project geef je advies over de infrastructuur, in het andere heb je de lead bij een migratie.

De rollen zijn divers en worden meestal op een natuurlijke wijze opgepakt. Soms leiden ze echter tot verwarring. Daarom is het noodzakelijk dat we de rol goed in het Plan Van Aanpak van een project/fase omschrijven. We werken een standaard werkwijze uit in dit artikel.

In het algemeen geldt dat de verschillende disciplines altijd in de verschillende fases betrokken moeten zijn. Soms als klankbord, soms als uitvoerende. Om de eigen werkzaamheden goed te kunnen plannen is het is namelijk van belang dat je van elkaars plannen en voortgang op de hoogte bent. Omdat je de werkzaamheden van de anderen vanuit een andere invalshoek ziet moet je tevens je eigen inzichten te kunnen uiten zodat de meest optimale situatie voor alle partijen tot stand kan komen.

Mapping van gebeurtenissen

Mapping Bedrijfsapplicaties

Gebeurtenis	Initiatief	Actie	Fase	Proces	Opmerking
1. Nieuwe informatiebehoefte   (n.a.v. jaarplan of regelgeving)	Systeemeigenaar of Functioneelbeheerder	In plannen werkzaamheden   Consequenties andere werkzaamheden bepalen.	Informatie analyse	Change-management	Voor externe partijen geldt een offerte traject.
2. Initiatie nieuwe applicatie in ontwikkelomgeving	Ontwikkelaar / Technisch Applicatiebeheer	Schriftelijke aanvraag voor nieuw project	Informatie analyse	Change-Management	Bij externe ontwikkeling vindt deze gebeurtenis bij de externe partij plaats.
3. Platform migratie	Systeembeheer	Applicaties veranderen van: Hardwareplatform, Ontwikkelomgeving of Database zonder functionele aanpassingen	Exploitatie	Change-Management	Gebeurtenis waar bij meerdere objecten geraakt worden. Vaak i.s.m. meerdere partijen.
4. Applicatie probleem	Functioneelbeheer	Na analyse van het probleem wordt de oplossingsvraag bij de ontwikkelaars neergelegd.	Exploitatie	Incident – Problem Management	Afhankelijk van de aard van het probleem kan systeembeheer worden betrokken.
5. Er moet een object (module/script/menu) naar een andere omgeving worden overgezet.	Functioneelbeheer   (eventueel op aangeven van de ontwikkelaar)	Object wordt overgezet van de ontwikkelomgeving naar de acceptatieomgeving of van acceptatie naar productie. Op aangeven worden scripts gedraaid.	Realisatie/   Invoering / Exploitatie (onderhoud)	Change- of Problem-Management
6. Een gebruiker dient voor een applicatie geautoriseerd te worden. (of autorisatie moet ingetrokken worden)	Functioneelbeheer	N.a.v. Autorisatieformulier netwerkgebruiker beschikbaar stellen van de applicatie.	Exploitatie	Beheren gebruikers
7. Een gebruiker dient voor een rol geautoriseerd te worden. (of autorisatie moet ingetrokken worden)	Functioneelbeheer	N.a.v. Autorisatieformulier toekennen rollen per applicatie beschikbaar stellen van de rol.	Exploitatie	Beheren gebruikers

Mapping Standaard software pakketten en SaaS

Gebeurtenis	Initiatief	Actie	Fase	Proces	Opmerking
1. Nieuwe informatiebehoefte   (n.a.v. meerjarenplan of regelgeving)	Systeemeigenaar of Functioneelbeheer	In plannen werkzaamheden   Consequenties andere werkzaamheden bepalen.	Informatie analyse	Change-management	Voor externe partijen geldt een offerte traject.
2. Er moet een standaard bedrijfssysteem pakket geïnstalleerd worden.	Functioneelbeheer	Installatiescripts moeten beoordeeld en gedraaid worden.	Invoering	Change-Management	Voor de invoering van een groot pakket dient een plan gemaakt te worden met zowel een pilot en training.
3. Er moet een standaard KA pakket geïnstalleerd worden.	Functioneelbeheer	Installatiescripts moeten beoordeeld en gedraaid worden.	Invoering	Aanvraag installatie standaard software	Voor de invoering van een groot pakket dient een plan gemaakt te worden bovendien met o.a. een pilot en training.
4. Een gebruiker dient voor een KA-applicatie geautoriseerd te worden.   (of autorisatie moet ingetrokken worden)	Functioneelbeheer	N.a.v. Autorisatieformulier gebruiker KA-omgeving beschikbaar stellen van de applicatie.	Exploitatie	Beheren gebruikers

Mapping Algemene incidenten

Gebeurtenis	Initiatief	Actie	Fase	Proces	Opmerking
1. Er doet zich een storingsincident voor.	Functioneelbeheer / Systeembeheer	Analyse en oplossen van de storing.	Exploitatie	Incident-management	Storingen kunnen verschillen in aard en ernst. In het uiterste geval besluit men tot uitwijk.
2. Er doet zich een beveiligingsincident voor.	Functioneelbeheer / Systeembeheer	Analyse en oplossen van het beveiligingsincident.	Exploitatie	Beveiligings-incidenten register	Beveiligingsincidenten kunnen verschillen in aard en ernst. In het uiterste geval kan tot uitwijk worden besloten.

Discussieer mee op LinkedIn.