Mapping IT-procedures over projectfasering

De IT-procedures zijn gericht op fysieke handelingen met IT-objecten. Daarbij moet bijvoorbeeld worden gedacht aan het inrichten van een werkplek, de installatie van een module of het toekennen van een autorisatie. M.b.v. deze procedures kunnen ook series worden verwerkt, doch altijd series van gelijksoortige objecten.

Projecten daarentegen bestaan uit meerdere fases waarin d.m.v. verschillende activiteiten naar een bepaald einddoel wordt gewerkt. Dit einddoel is in veelgevallen een samengesteld geheel van infrastructurele objecten, software en AO. Tijdens het project wordt dit geheel opgebouwd en is het noodzakelijk om planmatig IT-procedures te triggeren om dit te bewerkstelligen.

In dit artikel wordt aangegeven op welk moment in welke fase welke IT procedure wordt getriggerd. Tevens wordt aangegeven wie welke verantwoordelijkheid daarin heeft.

Vooraf regelen

  1. De IT-procedures 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.
  2. Alle applicaties binnen de organisatie zijn geclassificeerd op basis van (financieel) belang en beschikbaarheids eisen. Deze classificaties zijn in de SLA vastgelegd. Hieronder kunnen zich applicaties bevinden met de classificatie Zeer Kritisch. Aangezien één homogene technische infrastructuur is voor alle applicaties wordt nagestreefd is er ook slecht één set van procedures geldig. Deze procedures zijn dan gebaseerd op de hoogste classificatie die binnen de organisatie gehanteerd wordt.
  3. In bepaalde gevallen kan van procedures worden afgeweken. Dit zijn:
    a. Spoedeisende correctieve opdrachten.
    b. Technische calamiteiten.
    c. Geïsoleerde pilotprojecten.

Het besluit om af te wijken van de procedure dient door het management te worden genomen en kan alleen plaatsvinden als de reden gedocumentatie wordt. Daarnaast dienen het besluit, de genomen stappen en de rol van de diversie functionarissen te worden vastgelegd.

Project fasering

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

  1. Business Analyse.
  2. Informatie Analyse.
  3. Ontwerp.
  4. Realisatie.
  5. Acceptatietest.
  6. Invoering.
  7. Exploitatie. 

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 nadien andere spoedeisende projecten opdoemen (b.v. naar aanleiding van nieuwe regelgeving) heeft dit gevolgen voor het vastgestelde jaarplan. Deze projecten kunnen deze alleen opgestart worden na een beslissing van het management.

Een project start in de regel met een Informatie Analyse waarin de informatiebehoeften van de gebruikers in kaart worden gebracht. 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 gevat in een procedure. Deze procedures hebben geen ander doel dan de communicatie over de gebeurtenissen en hun gevolgen te stroomlijnen en de afwikkeling vast te leggen.

Door een eenduidige vastlegging wordt het mogelijk om de gang van zaken te herleiden en verantwoording te geven over de afwikkeling van de gebeurtenissen.

Betrokkenen

Organisatie.

Binnen de organisatie dient een duidelijke functiescheiding van IT-taken en een verdeling van verantwoordelijkheden te worden gemaakt. Globaal zijn 3 groepen te onderscheiden.

  1. Functioneel beheer (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 werden deze groepen herkend aan hun specifieke taken.

De Functioneelbeheerder 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 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 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 wensen. Er is 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 de operator die uren bezig met het wisselen van tapes is 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. 

Rollen.

Iedere fase eist van de betrokkenen vaak een andere rol. Daarnaast kan deze rol per project verschillen. Zo treedt men de ene keer op als opdrachtgever en een andere keer als klankbord, tester of reviewer. De ene keer treedt men op als ontwikkelaar van een systeem en de andere keer analyseert men de aansluiting van een standaard pakket op het datamodel. In het ene project geeft men advies over de infrastructuur, in het andere heeft men 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 de rol goed in het Plan Van Aanpak van een project/fase wordt omschreven. Een standaard werkwijze wordt in dit artikel uitgewerkt.

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 men van elkaars plannen en voortgang op de hoogte is. Omdat betrokkenen de werkzaamheden van de anderen vanuit een andere invalshoek zien dient men tevens de eigen inzichten te kunnen uiten zodat de meest optimale situatie voor alle partijen tot stand kan worden gebracht.

Gebeurtenissen

Bedrijfsapplicaties

GebeurtenisInitiatiefActieFaseProcedureOpmerking
1. Nieuwe informatiebehoefte

(n.a.v. jaarplan of regelgeving)

Systeemeigenaar of FunctioneelbeheerderIn plannen werkzaamheden

Consequenties andere werkzaamheden bepalen.

Informatie analyseChange-managementVoor externe partijen geldt een offerte traject.
2. Initiatie nieuwe applicatie in ontwikkelomgevingOntwikkelaar / Technisch ApplicatiebeheerSchriftelijke aanvraag voor nieuw projectInformatie analyseChange-ManagementBij externe ontwikkeling vindt deze gebeurtenis bij de externe partij plaats.
3. Platform migratieSysteembeheerApplicaties veranderen van:

Hardwareplatform,

Ontwikkelomgeving  of

Database zonder functionele aanpassingen

ExploitatieChange-ManagementGebeurtenis waar bij meerdere objecten geraakt worden. Vaak i.s.m. meerdere partijen.
4. Applicatie probleemFunctioneel beheerNa analyse van het probleem wordt de oplossingsvraag bij de ontwikkelaars neergelegd.ExploitatieProblem-

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)

FunctioneelbeheerN.a.v. Autorisatieformulier netwerkgebruiker beschikbaar stellen van de applicatie.ExploitatieBeheren gebruikers 
7. Een gebruiker dient voor een rol geautoriseerd te worden. (of autorisatie moet ingetrokken worden)FunctioneelbeheerN.a.v. Autorisatieformulier toekennen rollen per applicatie beschikbaar stellen van de rol.ExploitatieBeheren gebruikers 

Standaard pakketten

GebeurtenisInitiatiefActieFaseProcedureOpmerking
1. Nieuwe informatiebehoefte

(n.a.v. meerjarenplan of regelgeving)

Systeemeigenaar of FunctioneelbeheerIn plannen werkzaamheden

Consequenties andere werkzaamheden bepalen.

Informatie analyseChange-managementVoor externe partijen geldt een offerte traject.
2. Er moet een standaard bedrijfssysteem pakket geïnstalleerd worden.FunctioneelbeheerInstallatiescripts moeten beoordeeld en gedraaid worden.InvoeringChange-ManagementVoor de invoering van een groot pakket dient een plan gemaakt te worden met o.a. een pilot en training.
3. Er moet een standaard KA pakket geïnstalleerd worden.FunctioneelbeheerInstallatiescripts moeten beoordeeld en gedraaid worden.InvoeringAanvraag installatie KA-applicatieVoor de invoering van een groot pakket dient een plan gemaakt te worden met o.a. een pilot en training.
4. Een gebruiker dient voor een KA-applicatie geautoriseerd te worden.

(of autorisatie moet ingetrokken worden)

FunctioneelbeheerN.a.v. Autorisatieformulier gebruiker KA-omgeving beschikbaar stellen van de applicatie.ExploitatieBeheren gebruikers 

Algemeen

GebeurtenisInitiatiefActieFaseProcedureOpmerking
1. Er doet zich een storingsincident voor.Functioneelbeheer / SysteembeheerAnalyse en oplossen van de storing.ExploitatieIncident-managementStoringen kunnen verschillen in aard en ernst. In het uiterste geval kan tot uitwijk worden besloten.
2. Er doet zich een beveiligingsincident voor.Functioneelbeheer / SysteembeheerAnalyse en oplossen van het beveiligingsincident.ExploitatieBeveiligings-incidenten registerBeveiligingsincidenten kunnen verschillen in aard en ernst. In het uiterste geval kan tot uitwijk worden besloten.

Boeken over dit onderwerp

PMC Compact

Auteur: Jo Bos
Vele malen kwam het verzoek om de belangrijkste principes en werkvormen van de methode Projectmatig Creeëren in een compacte uitgave samen te brengen. In ‘PMC Compact’, een handzame gids voor projectmanagers, opdrachtgevers en teamleden, vindt u de werkvormen van Projectmatig Creëren in overzichtelijke stappen uitgelegd, voorzien van veel tips uit de praktijk.
Europrijs: 18,95
Bestellen

Projectmanagement op basis van PRINCE2, Editie 2009

Auteur: Bert Hedeman
Ten eerste is dit boek bedoeld voor iedereen die zich op een degelijke wijze wil voorbereiden op het PRINCE2 Foundation examen. Ten tweede is het een praktisch gebruikersboek.
Europrijs: 31,75
Bestellen

Meer boeken over projectmatig werken vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Procedures n.a.v. Service-level-agreement 29 vragen.
Organisatie van het systeembeheer 65 vragen.
Werkwijze incidentbeheer 16 vragen.
Storingsafhandeling en registratie 31 vragen.
Sidebar