Het loslaten van ITIL-kaders en het adopteren van Agile-kaders!

Met het huidige ‘geweld’ van Agile development lijkt het er in veel organisaties op dat de aandacht alleen gericht is op de ontwikkeling van nieuwe bedrijfsoplossingen (nieuwe features), veelal in de vorm van ondersteunende informatievoorziening. Natuurlijk moet snel en adequaat ingespeeld worden op veranderende bedrijfsbehoeften, maar dat wil nog niet zeggen dat er geen aandacht meer nodig is voor de wijze waarop bijvoorbeeld het operationele beheer en de dagelijkse ondersteuning plaatsvindt. 

Binnen organisaties is als gevolg van het voorgaande een strijd gaande tussen het loslaten van de ITIL-kaders en het adopteren van de Agile-kaders.

Zijn de processen zoals binnen ITIL gedefinieerd overbodig? Mijns inziens niet. Er dient nog steeds nagedacht te worden welke minimaal noodzakelijke processen uitgevoerd dienen te worden en vervolgens dient gezorgd te worden voor duurzame verbetering (continual improvement). De processen dienen een zo min mogelijke overhead te hebben, oftewel een minimaal levensvatbaar proces respectievelijk een minimaal werkbaar proces dat ‘net voldoende’ gedefinieerd is met ‘net genoeg’ controle en structuur (minimum viable process).

Bij het iteratief en incrementeel ontwikkelen (de kern van Agile development) blijft het nog steeds van belang om aandacht te geven aan allerlei factoren die team-overstijgend zijn, al dan niet als gevolg van compliance- of governance-regels en -structuren, en allerlei geldende security-regels.

Op welke wijze een willekeurig ontwikkelteam (of een aantal teams) gevolg geeft aan bepaalde regels, naast de uitvoerende ontwikkelwerkzaamheden zelf, vraagt de nodige aandacht.

Ter illustratie positioneert ITIL ‘de controle op de ontwikkelwerkzaamheden’ binnen de levenscyclusfase service design. Dit werkt over de hele service-lifecycle heen, inclusief diverse feedback-loops en lessons learned for improvement. Service design gaat over ‘de controle’ op software engineering (development) en niet over de uitvoerende ontwikkelwerkzaamheden zelf. Service design ondersteunt bijvoorbeeld de samenwerking om te komen tot de ‘bouwen of kopen’ beslissingen. Als de beslissing is de oplossing te bouwen, werken de verschillende service-activa (middelen en/of artifacten), met inbegrip van de mensen, samen als leden van het ‘service design’-team. Het doel is de inspanningen te coördineren en een service design package (SDP) of een plan met de servicevereisten. De vorm en omvang is aan het development-team zelf, zolang alle aspecten van de IT-service en de vereisten ervan maar duidelijk zijn (minimum viable design).

Een SDP definieert alle relevante aspecten van een IT-service. Het omvat onder andere applicatie-gerelateerde uitkomsten (outcomes) en natuurlijk de bedrijfsrelevantie, evenals alle onderliggende activiteiten en capaciteiten die nodig zijn voor beheer en ondersteuning.

Een SDP is een groeipad-beschrijving (op hoofdlijnen), mogelijk in de vorm van epics (grote user-stories, vaak in de vorm van een complete workflow) en/of user-stories (een korte beschrijving wat de klant en/of gebruiker wil) of themes (samengestelde user-stories). Het verzamelen, definiëren en prioriteren van servicelevel vereisten (service level requirements) wordt onderdeel van het opstellen van een (user) story. Het geldt ook voor de servicelevel doelen (service level targets), de verplichting waaraan de IT-service moet voldoen om te zorgen dat de service ondersteunend is aan de bedrijfsdoelstellingen. Een SDP geeft de basis voor het iteratief en incrementeel ontwikkelen.

De noodzaak voor het opstellen van een servicelevel overeenkomst (service level agreement) komt deels te vervallen. De nieuwe wijze van werken ‘garandeert’ op zich al dat wat wordt geleverd (het increment) aan de vereisten voldoet. Dit is, als onderdeel van de Agile-werkwijze, gedefinieerd met de Definition of Done. Het opstellen van SLA’s blijft evenwel voor veel organisaties nog steeds belangrijk. Het vastleggen van afspraken tussen de IT-serviceprovider en de Business en het definiëren wat de verantwoordelijkheid is van de IT-serviceprovider, is en blijft houvast geven in de reguliere (en vaak complexe) interne en externe communicatie.

Het ITIL-kader, ondanks dat dit sinds de 2011-release zeer omvangrijk is, geeft nog steeds de nodige handvatten, kaders, checklist en wat dies meer zij, waarmee een organisatie haar wijzigingen in de bedrijfsprocessen kan afstemmen op de rol van IT en waarmee de nieuwe IT-services afgestemd kunnen worden op de bedrijfsvereisten.

Download het ITIL-kader als totaaloverzicht (PDF-formaat): ITIL Detailed Overview

ITIL detailed overview as checklist

The ITIL framework, despite the fact that it is very extensive since the last version, still provides the necessary tools, frameworks, checklist and so on, with which an organization can adapt its changes in the business processes to the role of IT and with which the new IT services can be tailored to the business requirements.

Download the PDF overview here: MCS – ITIL v3 2011 v1.0.2

Design van een IT-service versus de Styling!

Binnen bepaalde marktsegmenten is het begrip ‘styling’ niet weg te denken; denk aan mode-, interieur-, food- retail- & media- en bedrijfsstyling zijn hier voorbeelden van. Ik ben van mening dat binnen het brede vakgebied van IT-management de rol van IT-service stylist niet zou misstaan!

IT-service design

Design van een IT-service versus de StylingService design (ontwerp) wordt beschouwd als de activiteit die de eisen van de IT-service identificeert en vervolgens een oplossing definieert die in staat is aan het totaal van deze eisen te voldoen. Een IT-service is opgebouwd uit een combinatie van technologie, mensen en processen (nodig voor het beheer van het domein informatie). De componenten die hierbij een belangrijke rol spelen zijn het daadwerkelijke informatiesysteem, de kwalificatiespecificaties en de ondersteuning op het informatiesysteem.

In output-termen is een IT-service een set van gerelateerde elementen en de potentiële toegevoegde waarde aan de klant.

Ondanks deze context kom ik in de praktijk nog te vaak tegen dat een IT-service slechts wordt beschouwd als ‘iets’ dat alleen bestaat uit technische componenten. Veel wijzigingen beperken zich dan ook tot deze technische componenten. Er wordt ‘voor het gemak’ geen rekening gehouden met eventuele ‘aanpassingen’ aan de benodigde kennis en kunde van de medewerkers die het operationele beheer en onderhoud uitvoeren en de benodigde procedures en werkinstructies. Per slot wordt ondersteuning verleend volgens procescriteria!

Bij het (her)ontwerpen van een nieuwe of gewijzigde IT-service dient dan ook aandacht te worden besteedt aan het totaal van IT-service aspecten. Het totaal aan aspecten betreft de IT-service zelf, maar ook architectuur (technologie en management), processen, meetmethoden en metrics en de ondersteunende management informatiesystemen en tools.

IT-service design en -development werkzaamheden

Binnen de gegeven context beperk ik me tot de werkzaamheden die met design (ontwerp) en development (ontwikkeling) te maken hebben.

De IT-service designer houdt zich bezig met het ontwerpen van een oplossing. Het doel is zorgen voor de identificatie van de businesseisen en het definiëren van een oplossing die in staat is om aan deze vereisten te voldoen. Vereisten hebben in het bijzonder betrekking op de businesseffecten van de IT-service en de kaders die daaraan worden gesteld. Het is de stip aan de horizon waar de IT-service zich naar toe ontwikkelt.

Het resultaat is een ontwerp dat een groeipad biedt waarlangs alle IT-service verbeteringen op gestructureerde, planmatige en kostenefficiënte wijze worden doorgevoerd en wat de basis voor toekomstige strategische beslissingen vormt. In IT-service terminologie betreft het een bepaalde keuze van wat de IT-service (in de toekomst) dient te doen qua functionaliteit (utility: geschikt voor het doel) en waar de IT-service aan dient te voldoen qua beschikbaarheid, capaciteit, continuïteit en veiligheid (warranty: geschikt voor gebruik).

De IT-service developer houdt zich bezig met het ontwikkelen van een oplossing. Het doel is zorgen voor het vertalen van het ontwerp in een plan om de IT-service en de daaropvolgende uitvoering van de ontwikkelde IT-service te leveren. Vereisten hebben in het bijzonder betrekking op de gebruikerseffecten van de IT-service en de kaders die daaraan worden gesteld.

Het resultaat is een ontwikkelstrategie (een realisatiepad) waarlangs de IT-service zich in de loop van de tijd, op een gestructureerde, planmatige en kostenefficiënte wijze, wordt gerealiseerd en doorgevoerd. In IT-service terminologie betreft het alle gedefinieerde aspecten van een IT-service en de parallelle vereisten. Hierbij dient rekening te worden gehouden met het totaal aan aspecten.

Maar wat doet een IT-service stylist?

Volgens algemeen geldende beschrijvingen is een stylist iemand die stijladvies geeft aan anderen of die spullen uitkiest en rangschikt volgens een bepaalde stijl of ontwerp. Een voedselstylist houdt zich bijvoorbeeld bezig met het uiterlijk (‘het oog wil ook wat’) op basis van afgestemde ingrediënten. Modestylisten staan erom bekend dat ze zich erop richten of het hele plaatje klopt en letten daarbij op ieder detail. Woonstylisten richten zich op een complete make-over, vaak gebaseerd op eenmoodboard.

In lijn met de voorgaande context voert de IT-service stylist dezelfde soort activiteiten uit. De IT-service stylist werpt, tijdens de realisatie van de IT-service, een kritische blik op veelal uiterlijke factoren en ziet snel welke facetten verbeterd kunnen worden ten opzichte van het ontwerp. Over het algemeen kun je stellen dat een stylist een vertaalslag maakt van een trend of een concept, naar een visuele beleving. Maar dan wel een visuele beleving vanuit de optiek van de klant/gebruiker alsook het dagelijkse beheer en onderhoud.

Een IT-service stylist dient blijk te geven de techniek van zijn of haar ‘tak van sport’ tot op de puntjes te beheersen en dient daarnaast een ‘mooie stijl’ te hebben bij het uitoefenen van zijn/haar vak.

De IT-service stylist creëert de juiste IT-service oplossing zodanig dat deze klaar is voor gebruik. Het doel is zorgen voor het concreet uitvoeren van een bepaald IT-service plan, door het realiseren (bouwen, testen en inzetten) van (delen van) een gekozen IT-service oplossing. Vereisten hebben in het bijzonder betrekking op de technische effecten van de IT-service en de kaders die daaraan worden gesteld.

Het resultaat is de realisatieaanpak waarlangs de IT-service daadwerkelijk wordt gerealiseerd en verbeterd, op basis van de omvang en de aard van de IT-service. In IT-service terminologie betreft het een set van afgestemde (configuratie-)items die als een release wordt gebouwd, getest en gezamenlijk wordt geïmplementeerd (al dan niet volgens een agile-aanpak).

Conclusie

De creativiteit van de ideale IT-service stylist is een belangrijke factor. De grote vraag is namelijk: wanneer is de eigen inbreng en de eigen creativiteit gewenst en wanneer dient er volgens een vast patroon gewerkt te worden?

Een belangrijke verspilling (volgens Lean IT) is ‘niet gebruikt talent’ (non-utilized talent). Dit betreft het onvoldoende betrekken en het niet motiveren van medewerkers, waardoor zij onvoldoende verantwoordelijkheid nemen voor hun taak. Het gevolg is dat nieuwe kansen of oplossingen voor bestaande problemen (door het management) niet ‘gehoord en gezien’ worden.

Beste IT-managers, geef de IT-service stylist de ruimte, anders belemmert het de creativiteit en het leren en dus ook de continue verbetering en innovatie!

Procesimplementatie anno 2015; de harde realiteit!

Is de implementatie van processen, op basis van raamwerken zoals BiSL (informatiemanagement),ITIL (IT-servicemanagement) of PRINCE2 (project management) nou echt zo eenvoudig?

Veel medewerkers die mijn trainingen volgen, vanuit verschillende organisaties, geven aan dat de handvatten die ze aangereikt krijgen, in de zin van de concepten, de processen, de modellen, de hulpmiddelen en technieken etc. in hun praktijk vaak niet of nauwelijks, of in ieder geval onvoldoende herkenbaar en gestructureerd zijn! Een voorzichtige conclusie is dat het (praktisch) implementeren in een bedrijfsomgeving (nog steeds) een lastig en moeilijk onderdeel is bij het optimaliseren van de kennis en kunde van medewerkers of van de organisatie zelf.

Iedere organisatie is anders; ze variëren in mensen, bepaalde processen, soort dienstverlening richting klanten en nog veel meer. De organisatie dient ook voldoende ‘gerijpt’ te zijn om bepaalde processen goed te handelen, anders is de kans groot dat het een mission impossible wordt. Ook zullen bepaalde dingen die in de ene organisatie hebben gewerkt niet noodzakelijkerwijs werken voor een andere.

Iedereen weet ondertussen wel dat de raamwerken over ‘best practices’ gaan. Ze geven verschillende geleerde lessen van andere vakgenoten, vanuit de voorgaande jaren. Eigenlijk zijn ze een soort van ‘boodschapper’ die goede en bewezen toepassingen vertelt. Door vervolgens wat verteld is foutief te implementeren, is ofwel het raamwerk (de concepten) of de consultant de gebeten hond!

Een aantal vragen, als het om een proces gaat, dienen dan ook voorafgaand te worden gesteld, zoals:

  • Kan het team omgaan met het betreffende proces?
  • Is het proces een noodzaak of een luxe?
  • Welk voordeel voegt het proces toe?

Een aantal van mijn consulting ervaringen hebben, in lijn hiermee, betrekking op een drietal harde realiteiten.

Het probleem: Mens

Het managen van mensen is zeer ingewikkeld. Het is echter een van de belangrijkste maar ook moeilijkste taken. Wanneer er een verandering wordt doorgevoerd in de werkwijze, en daar hebben we het in de regel over, is het belangrijk om de juiste keuzen te maken welke mensen deze verandering daadwerkelijk gaan door- en invoeren. Het proces dient dan ook op maat te worden ontworpen (in de zin van procedures en werkinstructies) voor de mensen die ermee (gaan) werken, gebaseerd op de kwaliteiten en capaciteiten die zij hebben. Tevens is het kiezen van de juiste proceseigenaar en de juiste procesmanager (inclusief de parallelle (eind)verantwoordelijkheden) cruciaal!

Procesbeschrijvingen dienen niet gebaseerd te zijn op het meest ideale maar op het hoogst haalbare voor dat moment. Vanaf het moment dat de nieuwe werkwijze start volgen de noodzakelijke verbeteringen.

Het probleem: Complexiteit

Het doel van het definiëren van een proces (procedures en werkinstructies) is om ervoor te zorgen dat het proces op een systematische en gestructureerde wijze wordt uitgevoerd maar ook dat het gebruik van hulpmiddelen en technieken bepaalde vrijheidsgraden kent. In sommige gevallen interpreteert een medewerker het echter verkeerd, onder het excuus van het geleverde protocol/procedure. Het proces dat juist wordt verondersteld om de dingen makkelijker te maken en te vereenvoudigen wordt hierdoor steeds complexer en het doel erachter komt volledig in de schaduw te staan.

Situaties dienen met gezond verstand te worden behandeld waardoor het ‘complexe’ proces veranderd in simpele oplossingen.

Het probleem: Timing

Procesimplementatie is als het bakken van een taart. Je dient voor de juiste timing te zorgen en er voor te zorgen dat op het juiste moment het juiste ingrediënt wordt toegevoegd. Deze ingrediënten dienen dan (vaak) wel voorbereidt te zijn. Bij een proces kan, ter vergelijk, een bepaalde werkwijze of en bepaald hulpmiddel niet ‘door de strot worden geduwd’ van het team of van een individuele medewerker. Bepaalde dingen hebben tijd nodig om geaccepteerd te worden en soms dient zelfs overwogen te worden of een bepaald onderdeel (of misschien wel het hele proces) op een bepaald moment nodig is.

Processen dienen ontworpen te worden door en met de medewerker die er dagelijks mee te maken heeft. Dit geldt ook voor de (be)nodigde verbeteringen. Hiervoor ligt het initiatief bij de medewerker.

Het receptuur

Procesimplementatie anno 2015 de harde realiteitHet negeren van de drie genoemde problemen zal tot een definitief falen leiden. Ze zullen dan ook zorgvuldig en permanent gemanaged dienen te worden.

Het implementeren van processen verschilt voor iedere omgeving en de realiteit wordt nog vaak als erg hard en confronterend ervaren, doordat er met heel veel factoren rekening gehouden moet worden. De problemen kunnen overwonnen worden. Voorwaarde is de organisatie, de afdeling of het team (naargelang de verandering er betrekking op heeft) goed te kennen, in de zin van de sterke en zwakke punten van de medewerkers en hun vermogen (kennis en vaardigheden).

Een succesvolle implementatie betekent dat de processen eenvoudiger werken dan voorheen. De processen dienen door iedereen geaccepteerd te worden omdat ze, in tegenstelling tot bijvoorbeeld kou, nooit verdwijnen. En de problemen ontkennen heeft ook geen zin, ze komen als een boemerang even hard terug.

The proof of the pudding is in the eating!

Hoe word je een echte functioneel beheerder?

In een van mijn voorgaande blogs – “De functioneel beheerder als spilfunctie!” – heb ik al de belangrijke kritieke succesfactoren voor een optimaal operationele informatievoorziening belicht. In dit artikel wil ik graag ingaan op de inhoudelijke werkzaamheden van de functioneel beheerder. De professionele functioneel beheerder zorgt er voor dat de werkzaamheden op operationeel niveau daadwerkelijk succesvol zijn.

De werkzaamheden van de functioneel beheerder

De werkzaamheden van de functioneel beheerder is grofweg gericht op drie operationele werkgebieden, namelijk:

Het Gebruiksbeheer

  • Ondersteunen van de gebruikers
  • Aansturen van de IT-leveranciers
  • Beheren van bedrijfsinformatie

Het Functionaliteitenbeheer

  • Bijdragen aan het specificeren van requirements
  • Afstemmen geautomatiseerde en niet-geautomatiseerde informatievoorziening
  • Organiseren van acceptatietesten
  • Beoordelen van de kwaliteit van documenten namens de gebruikersorganisatie (zoals een vooronderzoek, functioneel ontwerp, testdocumenten, et cetera).

Het beheren van wijzigingsvoorstellen en het werkelijk invoeren van de veranderde informatievoorziening.

De echt belangrijke zaken!

Wat zijn nu de echt belangrijke zaken waar de functioneel beheerder aandacht aan besteedt en mee te maken zal krijgen? Het zijn er nogal wat, maar ik heb ze verdeelt in een 7-tal onderwerpen.

  1. Ten aanzien van klantgerichtheid
    • Relatie functioneel beheerder, klanten organisatie
    • Communicatie / Luisteren, de vraag achter de vraag, (be)argumenteren
    • “Nee” kunnen verkopen
    • Adviseren
    • Klantgerichte tweegesprekken
    • Alternatieven kunnen voorstellen
  2. Ten aanzien van de wijzigingsketenHoe word je echt een functioneel beheerder
    • Business Case lezen, begrijpen én beoordelen
    • Kosten inschatten en de baten bepalen
    • Risico’s beoordelen
    • Haalbaarheid beoordelen
    • Een voorstel schrijven
  3. Ten aanzien van het IT Management
    • De rol van de IT dienstverlener en de service organisatie
    • Impact analyse maken
    • Requirements analyse maken
    • De toegevoegde waarde van de IT-infrastructuur & Informatiesystemen
  4. Ten aanzien van het functioneel ontwerp
    • Lezen, beoordelen en opstellen van een functioneel ontwerp
    • Beoordelen van producten en diensten van de IT dienstverlening
    • Relatie met de keten en andere processen
  5. Ten aanzien van het omgaan met veranderingen
    • Voorlichting geven aan de gebruikers
    • Omgaan met weerstanden
    • Rol van de Functioneel Beheerder in een veranderingsproces
  6. Ten aanzien van testen & toetsen
    • Identificeren van testgevallen
    • Maken van plannen (zoals transitieplan, functioneel testplan, implementatieplan)
  7. Ten aanzien van het beheerplan
    • De rol van ‘Governance’
    • Financiële paragraaf
    • Planningsparagraaf
    • Behoefte en kwaliteitsparagraaf
    • Contractenparagraaf

De functioneel beheerder heeft een zeer uitdagend takenpakket en is de contactpersoon tussen de bedrijfskant van de organisatie waar het informatiesysteem in werking is en de IT-serviceorganisatie. De spilfunctie in de organisatie op operationeel niveau!

Meer informatie over of interesse in de rol/functie als Functioneel Beheer?

De functioneel beheerder als spilfunctie!

Er gelden in de dagelijkse praktijk van de functioneel beheerder een aantal kritieke succesfactoren. De rol van ‘functioneel beheerder’ kent binnen verschillende organisaties verschillende namen met een misschien nog wel meer gevarieerde invulling. Ook wordt de rol van super-user/key-user onderkend. Deze rol neemt een deel van de taken van de functioneel beheerder op zich; het onderhouden van de directe contacten met de gebruikers en gebruikersondersteuning.

Het belang en de uitdaging

De aandacht voor business informatiemanagement is de laatste jaren fors toegenomen. Gebruikers drukken een steeds duidelijker stempel op de (juiste) informatievoorziening. Dat is een goede ontwikkeling, want er is een grote afhankelijkheid van de geautomatiseerde informatievoorziening. De functioneel beheerder is hierbij belangrijk omdat hij/zij vaak de gesprekspartner is met de IT-serviceorganisatie (IT-service-management en applicatiemanagement) op het uitvoerende niveau. Het onderhouden van contacten is dan ook een belangrijke competentie. Daar zit ook direct de uitdaging: het op proactieve wijze handhaven en – waar nodig – verbeteren van de informatievoorziening.

Verschil met de applicatiebeheerder

Functioneel beheerIn de praktijk blijkt dat de functioneel beheerder nogal eens wordt verward met de applicatiebeheerder. Los van het feit dat in de praktijk een combinatie van deze rollen in één functie mogelijk is, is er verschil in taken en verantwoordelijkheden.

Ter indicatie, de werkzaamheden van de applicatiebeheerder zijn gericht op de applicatie (de informatiesystemen) en hebben betrekking op de dagelijkse ondersteuning en de nieuwe mogelijkheden en ontwikkelingen van de applicaties. De functioneel beheerder richt zich op de informatievoorziening binnen de gebruikersorganisatie op operationeel niveau.

De KSF’en

De belangrijke kritieke succesfactoren voor een optimaal operationele informatievoorziening, zijn:

  • Goede communicatie tussen de gebruikers van de applicaties en business informatiemanagement (gebruikersoverleg e.d.).
  • Adequaat beheren van de bedrijfsinformatie (de gegevens) en de stuurgegevens (btw-percentages en algemene stamgegevens alsook gebruikersautorisatie en bedrijfsspecifieke templates).
  • Maken en onderhouden van een optimaal bedrijfsinformatiemodel; het definiëren van gegevensobjecten (o.a. de entiteittypen), de relaties tussen de gegevensobjecten en bedrijfsregels maar ook het beheren van query’s en het formuleren van wijzigingsvoorstellen.
  • Juiste aansturing van de IT-serviceverlener, veelal op basis van vragen of opmerkingen die ontstaan vanuit de gebruikersondersteuning (het beschikbaar stellen van extra capaciteit, het terugzetten van versies, databaserapportages en ad-hoc query’s).
  • Tijdens het specificeren van requirements (functioneel en niet-functioneel alsook business en systeem requirements) begeleiden van de gebruikers bij het nauwkeurig formuleren van de juiste behoeften (wat is de aanleiding, het doel en de randvoorwaarden).
  • Beoordelen van de business case voor functionele wijzigingen op basis van wijzigings- én onderhoudskosten, baten, neveneffecten en risico’s zodat een verantwoorde beslissing genomen kan worden over de haalbaarheid van een wijzigingsvoorstel.
  • Laten uitvoeren van een impactanalyse door applicatiemanagement en/of IT-infrastructuur-management evenals het verzoeken van een ‘Request for Proposal’ waarmee de serviceverlener(s) wordt verzocht een offerte voor de realisatie te doen. Bij kleine veranderingen kan de functioneel beheerder, indien er voldoende kennis is van de applicatie(s), mogelijk zelf de impactanalyse uitvoeren.
  • Bij grote veranderingen een impactanalyse laten uitvoeren door een procesanalist, of een informatieanalist eventueel geassisteerd door een AO-adviseur en zo nodig het betrekken van informatiemanagers en architecten (i.v.m. ketenintegratie).
  • Tijdige deelname aan het releaseoverleg in samenwerking met applicatiemanagement en IT-infrastructuurmanagement nadat een mandaat is verkregen over planningen, budgetten en behoeften.
  • Tijdig in gereedheid brengen van de organisatie tijdens de realisatie van het vormgeven van geautomatiseerde en niet geautomatiseerde informatievoorziening alsook het beoordelen van een (functioneel) ontwerp (opgesteld door applicatiemanagement) dat tijdens de realisatie ontstaat.
  • Namens de gebruikersorganisatie adequaat bewaken van het hele wijzigingsproces en de gebruikersorganisatie (de indiener van het wijzigingsvoorstel en de systeemeigenaar) tijdig informeren over de voortgang.
  • Voorbereiden van de transitie in de zin van de gebruikersorganisatie gereed maken voor de veranderde informatievoorziening (middels implementatieplannen) en het begeleiden van de uiteindelijke transitie op basis van het transitieplan.

Kortom, de functioneel beheerder heeft een zeer uitdagend takenpakket en is de contactpersoon tussen de bedrijfskant van de organisatie waar het informatiesysteem in werking is en de IT-serviceorganisatie. De spilfunctie in de organisatie op operationeel niveau!