• Vergroot lettergrootte
  • Standaard lettergrootte
  • Verklein lettergrootte
Lifehacking volgens Pearl S. Buck
Gepubliceerd in Citaten: omdenken
E-mail Afdrukken

Go see ask why show respect

Many people lose the small joys in the hope for the big happiness.

Pearl S. Buck

Laatst aangepast op dinsdag, 07 oktober 2014 20:51  
Lifehacking volgens Maria Edgeworth
Gepubliceerd in Citaten: persoonlijke effectiviteit
E-mail Afdrukken

Go see ask why show respect

If we take care of the moments, the years will take care of themselves

Maria Edgeworth

Laatst aangepast op dinsdag, 07 oktober 2014 20:50  
Informatie-architectuur binnen BiSL
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

informatie-architectuur informatie portfoliomanagement bisl proces

In een poging te komen tot een inrichtings-, organisatie-onafhankelijke indeling van de informatievoorziening ('domeinindeling'), was ik me er in eerste instantie niet van bewust dat ik bezig wat met het praktiseren van de strategische BiSL-processen: informatie lifecycle management en informatie portfoliomanagement. Hieronder een selectieve samenvatting van mijn BiSL-samenvatting en een aantal fragmenten uit het boek De functioneel beheerder en BiSL om helder te krijgen hoe een beschrijving van het opdelen van de informatievoorziening in zgn. informatiedomeinen (lees: het opstellen van een informatie-architectuur) past binnen de strategische BiSL-laag.

Binnen de strategische BiSL-processen wordt het procescluster Opstellen informatiestrategie onderscheiden. Dit procescluster heeft als doel het bepalen hoe de toekomstige informatievoorziening er uit gaat zien (waarbij de informatievoorziening op lange(re) termijn de bedrijfsprocessen optimaal blijft ondersteunen) en bestaat uit vijf processen:

  1. Bepalen ketenontwikkelingen: inventariseren ontwikkelingen op het gebied van de informatie-uitwisseling met andere organisaties (keten) + het vertalen naar gevolgen voor eigen informatievoorziening.

  2. Bepalen bedrijfsprocesontwikkelingen: inventariseren ontwikkelingen in de organisatie en de bedrijfs-processen + het vertalen naar gevolgen voor de informatievoorziening.

  3. Bepalen technologie-ontwikkelingen: bepalen welke technische ontwikkelingen interessant kunnen zijn voor de organisatie en informatievoorziening.

  4. Informatie lifecycle management: vaststellen van de hoofdlijnen van de (toekomstige functionaliteit van de) informatievoorziening voor een specifiek informatiedomein.

  5. Informatie portfoliomanagement: zorg dragen voor een, vanuit bedrijfsbrede optiek, optimale inzet van middelen en opzet en invulling van de informatievoorziening.

 

Ad (4) Informatie lifecycle management

Informatie lifecycle management heeft als doel het opstellen van een strategie voor de informatievoorziening voor alle specifieke informatiedomeinen (vaak zijn deze gekoppeld aan specifieke bedrijfsprocessen). Voor elk domein wordt vastgesteld wat de behoeften voor beheer, onderhoud en vernieuwing. Bij het bepalen van de behoeften wordt aan de ene kant rekening gehouden met de ontwikkelingen op langere termijn op het vlak van: (a) de bedrijfsprocessen, (b) met de omgeving van de organisatie, en (c) met de technologie. Daarnaast wordt ook rekening gehouden met de huidige staat van de informatievoorziening per domein en de daarbinnen bestaande structurele knelpunten en problemen en het organisatiebeleid. De concrete output van dit proces bestaat uit: (i) een statusrapport (status informatievoorziening per informatiedomein), en (ii) een informatiestrategie (schetsen van toekomstige informatievoorziening + scenario’s per informatiedomein). Het proces informatie lifecycle management geeft dus invulling aan een onderdeel van het totale informatiebeleid van de organisatie, namelijk de toekomstbepaling voor de afzonderlijke onderdelen van de totale informatievoorziening.

Het proces Informatie portfoliomanagement zorgt voor de overkoepelende afstemming over het geheel van de informatievoorziening + het opstellen van een portfolio van alle IV-objecten op hoofdlijnen. Dit resulteert in drie concrete producten: (i) informatiearchitectuur (indeling/structuur informatievoorziening), (ii) informatiebeleid (beleid voor de informatievoorziening), en (iii) een portfolioplanning (incl. besluitvorming over veranderingsbehoeften).

Hét verschil tussen informatie lifecycle management en informatie portfolionmanagement is dan ook dat informatie lifecycle management zich richt op specifieke informatiedomeinen, terwijl informatie portfoliomanagement gericht is op het bepalen van de strategie voor het geheel van de informatievoorziening. De uiteindelijke output van informatie portfoliomanagement is een informatiestrategie met een beschrijving (schets) hoe de informatievoorziening er op lange termijn uit gaat zien per informatiedomein, welke stappen en activiteiten (scenario’s) nodig zijn, wat de impact is voor andere delen van de informatievoorziening (relaties) en inschatting van de kosten en baten.

De overeenkomst tussen beide processen is dat beide zich bezig houden met het opstellen van informatiebeleid. De relatie tussen deze twee ‘informatiebeleidprocessen’ is dat elke voorgestelde strategie voor de informatievoorziening van betrokken informatiedomeinen moet worden afgestemd met het grotere geheel (en dat gebeurt binnen informatie portfoliomanagement). 


Ad (5) Informatie portfoliomanagement

Het proces informatie portfoliomanagement draagt zorg voor een overkoepelende afstemming en uniformiteit over het geheel van de informatievoorziening. Het gaat hierbij om het geheel en samenhang tussen de verschillende delen van de informatievoorziening. Doel van informatie portfoliomanagement is het – vanuit bedrijfsbrede optiek – zorgen voor een optiek optimale inzet van middelen en opzet van de informatievoorziening en het afstemmen van verschillende (deel)plannen voor de toekomstige ontwikkeling van de informatievoorziening. Belangrijk hulpmiddel hierbij is het opstellen en onderhouden van een portfolio met daarin de objecten van informatievooziening op hoofdlijnen (incl. veranderingsbehoefte). Het werken met een portfolio maakt het mogelijk bedrijfsbrede en bedrijfsbreed gedragen beslissingen genomen over uit te voeren veranderingen.

Binnen informatie portfoliomanagement spelen drie hoofdonderwerpen:

(1) Structuur van de informatievoorziening
Het proces informatie portfoliomanagement houdt zich bezig met de structuur van de informatievoorziening door te bepalen op welke wijze de informatievoorziening wordt opgedeeld (in informatiedomeinen) en wat de samenhang (relaties, koppelvlakken) is tussen de verschillende delen: de zgn. informatiearchitectuur. Een informatiearchitectuur kan worden gedefinieerd als een beschrijving/visualisatie van de gehele informatievoorziening waarbij de informatievoorziening is opgedeeld in zgn. informatiedomeinen.

(2) Portfolio: het geheel aan veranderingen in de informatievoorziening
Het proces informatie portfoliomanagement houdt zich – op een overkoepelend niveau – bezig met het afstemmen van alle gewenste en voorgenomen veranderingen voor de gehele informatievoorziening en het waarborgen dat ook in de toekomst een optimale aansluiting tussen de bedrijfsprocessen en de informatievoorziening bestaat.  De kern van portfoliomanagement is het inzichtelijk krijgen van alle veranderingen en oplossingsmogelijkheden op het geheel van de informatievoorziening en het afstemmen over het gehele domein van informatievoorziening heen, welke veranderingen wel doorgezet gaan worden en welke niet.

(3) De gebruikte middelen van de informatievoorziening: standaardisatie
Het proces informatie portfoliomanagement definieert welke afspraken gemaakt worden over de inzet van ICT-hulpmiddelen. Het gaat dan over het opstellen van de infrastructuurarchitectuur en een ontwikkelarchitectuur.

Informatie portfoliomanagement resulteert - in lijn met de drie hoofdonderwerpen - in drie concrete producten:
-    Informatie-architectuur (indeling op hoofdlijnen van de informatievoorziening)
-    Informatiebeleid (beleid ten aanzien van informatievoorziening)
-    Portfolioplanning (besluitvorming grootschalige veranderingsbehoeften)


richtinggevende processen bisl

De richtinggevende processen houden zich bezig met de (middel)lange termijn: binnen deze processen wordt beschreven hoe de informatievoorziening zich de komende drie tot vijf jaar zal (moeten) ontwikkelen. Er wordt ook bepaald, hoe de organisatie van business informatiemanagement zal worden vormgegeven; dat wil zeggen wat voor ondersteuning wenselijk is en hoe dit kan worden gerealiseerd. De processen worden door de informatiemanager uitgevoerd in nauw overleg met iedereen die daarvoor nodig is: zoals business management, bedrijfs- en procesarchitecten en informatiearchitecten, want informatievoorzieningsplannen zijn afgeleid van het bedrijfsbeleid, maar ook IT-serviceverleners zijn bij het opstellen van de strategie betrokken. Meerjarenplannen worden dus gemaakt voor de informatievoorziening en voor de wijze waarop die zal worden ingericht en ondersteund.

(...)

Informatie-lifecylemanagement

Voor specifieke informatiedomeinen (gekoppeld aan bedrijfsprocessen) worden scenario's ontwikkeld. Deze scenario's geven aan hoe de huidige situatie van de informatievoorziening zich in een aantal stappen zal gaan evolueren tot de gewenste informatievoorziening en de bijbehorende systemen die zo nodig ondersteund worden door applicaties. Vanzelfsprekend zullen een globaal beeld van kosten, baten, sterkten, zwakten en ruwe planning niet mogen ontbreken. Kortom, er ontstaat een rapport voor de informatiestrategie.

Informatie-portfoliomanagement

Dit proces dient ervoor om een overkoepelend beeld te krijgen van de ontwikkelingen van de informatiedomeinen, vastgelegd in scenario's. Het resultaat is een portfolio van het geheel van de veranderingen en hun onderlinge samenhang: de portfolioplanning.

Afstemming van de afzonderlijke scenario's vindt plaats waarbij afspraken worden vastgelegd over standaarden en richtlijnen. Het informatiebeleid bevat een compleet beeld ten aanzien van de kosten en baten en bevat ook een overall-planning. Ook een informatiearchitectuur is een resultaat van dit proces.

Er is overleg tussen functioneel beheerder(s) (het uitvoerende niveau), de systeemeigenaar (het sturende niveau) en de informatiemanager (het richtinggevend niveau) over de te verwachten ontwikkelingen in de organisatie en de producten of diensten, zodat (meer-)jarenplannen voor de portfolio van systemen en onderliggende applicaties kunnen worden gemaakt en bijgesteld. Het zal duidelijk zijn, dat bij het opstellen van van de informatiestrategie overleg met de IT-serviceverleners (IT-servicemangement en Applicatiemanagement) noodzakelijk is. De behoeften van de gebruikersorganisatie zijn primair, maar de IT-serviceverleners zijn bij de realisatie betrokken.

Bron: Samenvatting BiSL (incl. mindmap) en De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers

Laatst aangepast op maandag, 23 oktober 2017 18:51  
Operational excellence (boekentip)
Gepubliceerd in Boeken over management
E-mail Afdrukken

operational excellence marcel assen

Operational Excellence
Van industrie tot dienstverlening
Marcel van Assen

Bij Bol.com | Managementboek


 

Laatst aangepast op zondag, 07 september 2014 07:04  
Leiderschap volgens Simon Sinek
Gepubliceerd in Citaten: leiderschap
E-mail Afdrukken

Go see ask why show respect

When we tell people to do their jobs, we get workers. When we trust people to get the job done, we get leaders.

Simon Sinek

Laatst aangepast op dinsdag, 07 oktober 2014 20:49  
Omdenken met De Dijk: 'Waar geen wil is ben ik weg'
Gepubliceerd in Citaten: dromen, durven doen
E-mail Afdrukken

Waar geen wil is ben ik weg

Voor wie wil gaat niets ten onder
Voor wie wil wordt vroeg nooit laat
worden scherpe kante ronder
raakt de stilte aan de praat

Voor wie wil is niets een wonder
kan het met ook heel goed zonder
Als je maar wil, als je maar wil
Als je maar wil dat het zo gaat

Maar waar geen wil is, kun je het vergeten
Kan je het vergeten, heb je pech
Maar moet je het verder zelf maar weten
Waar geen wil is ben ik weg

Het is durven blijven dromen
Verder kijken dan je ziet
En of er ooit iets van gaat komen
Het is nooit raak, als je niet schiet

Er schuilt goud in het gewone
En het alledaagse schone
Als je maar wil, als je maar wil
Als je maar wil, graag wel of niet

Maar waar geen wil is, kun je het vergeten
Kan je het vergeten, heb je pech
En moet je het verder zelf maar weten
Waar geen wil is ben ik weg

Ik ben overal voor te porren
In voor ieder goed idee
Als de geest er is, de hartstocht
Doe ik niets liever dan mee

Waar geen wil is, kan je het vergeten
Kan je het vergeten, heb je pech
En moet je het verder zelf maar weten
Waar geen wil is ben ik weg

De Dijk (allemansplein)

Laatst aangepast op zaterdag, 11 oktober 2014 05:36  
Motivatie volgens Douglas McGregor
Gepubliceerd in Citaten: motivatie
E-mail Afdrukken

Go see ask why show respect

The answer to the question..'How do you motivate people?' is you don't

Douglas McGregor

Laatst aangepast op dinsdag, 07 oktober 2014 20:47  
Information overload volgens Brian Solis
Gepubliceerd in Citaten: persoonlijke effectiviteit
E-mail Afdrukken

Go see ask why show respect

Information overload is a symptom of our desire to not focus on what's important in the moment. It is a choice.

Brian Solis

Laatst aangepast op dinsdag, 07 oktober 2014 20:46  
Constructief falen volgens George Soros
Gepubliceerd in Citaten: constructief falen
E-mail Afdrukken

Go see ask why show respect

I’m only rich because I know when I’m wrong. [...] there is no shame in being wrong, only in failing to correct our mistakes.

George Soros

Laatst aangepast op dinsdag, 07 oktober 2014 20:45  
Sleutelen aan de informatievoorziening volgens Ruigrok & Bosschers
Gepubliceerd in Informatiemanagement
E-mail Afdrukken

wijzigingenbeheer wijzigingsproces functioneel beheer bim

Volgens Kees Ruigrok en Ernst Bosschers speelt business informatiemanagement een sleutelrol bij het voorbereiden, doorvoeren en verifiëren van wijzigingsvoorstellen. Business informatiemanagement bepaalt samen met de gebruikers de eisen, behoeften (requirements) en de prioriteiten en stelt het budget voor de wijzigingen ter beschikking. De systeemeigenaar beoordeelt samen met de functioneel beheerder de business case op basis van de wijzigings- én onderhoudskosten, baten, neveneffecten en risico's. Hierdoor kan de systeemeigenaar een verantwoorde beslissing nemen over de haalbaarheid van het wijzigingsvoorstel.

Er kunnen allerlei redenen zijn om de bestaande infomratievoorziening te wijzigingen. (Zelfs) vanuit de richtinggevende processen (lees: informatiemanagement) kan er een aanleiding ontstaan voor functionele wijzigingen. Wanneer er om strategische redenen nieuwe functionaliteit wordt voorgesteld, wordt dit via het proces Behoeftemanagement (op sturend niveau) geaccordeerd waarna het wijzigingsproces in gang wordt gezet.

Om wijzigingen van de informatievoorziening goed te laten verlopen is een wijzigingsprocedure nodig: "Door een gestandaardiseerde afhandeling gaat dat over het algemeen sneller, is de kwaliteit van de afhandeling controleerbaar en gebeurt dat efficiënter: het behandelen van wijzigingsvoorstellen is beheersbaar."

Allereerst zal een wijzigingsvoorstel in functionele termen moeten worden beschreven: wat wil de gebruikersorganisatie bereiken. Bovenstaand schema geeft weer via welke procedure een wijzigingsvoorstel wordt afgehandeld.

"De eerste beoordeling en filtering van wijzigingsvoorstellen gebeurt meestal door business informatiemanagement. Een wijzigingsvoorstel wordt bijvoorbeeld als niet-zinvol beschouwd, als deze al eens is afgewezen en de reden daarvoor nog steeds actueel is. Maar ook als bij business informatiemanagement bekend is dat in een toekomstige release het voorstel al wordt ingewilligd of al worden achterhaald. De functioneel beheerder moet dus een overzicht hebben van alle wijzigingsvoorstellen. Zowel van de actuele voorstellen als van die uit het verleden. Business informatiemanagement moet de wijzigingsvoorstellen dus beheren, ook de voorstellen die zijn afgewezen. Een gegevensbestand met alle wijzigingsvoorstellen en hun actuele status is daarbij essentieel."

De functionele beheerder overlegt met de systeemeigenaar over de ingediende wijzigingsvoorstellen. Voor elk wijzigingsvoorstel moet er een eigenaar (sponsor) zijn die de business-verantwoordelijkheid draagt. "Tijdens dit overleg zal een business case op hoofdlijnen vastgesteld worden. Een business case op hoofdlijnen moet voldoende duidelijkheid geven over kosten en baten (financieel en niet-financieel) om te beslissen of het wijzigingsvoorstel realistisch is en/of een nader onderzoek zal worden uitgevoerd.

"Voor een realistisch wijzigingsvoorstel wordt een impactanalyse uitgevoerd. Dit betekent dat zowel de kosten als de baten, waarbij de systeemeigenaar verantwoordelijk is voor de inventarisatie van de baten. De IT-dienstverlener zal onderzoeken wat de impact is voor het geautomatiseerde deel van de informatievoorziening, de applicatie-impact. (...) Het uitvoeren van de impactanalyse betreft activiteiten van het proces Specificeren uit het procescluster Functionaliteitenbeheer. Applicatiemanagement voert dit onderzoek uit. Als er ook gevolgen zijn voor de infrastructuur, zal ook IT-servicemanagement hierbij worden betrokken. In veel gevallen is er sprake van een zogenoemd RfP, een Request for Proposal. Daarmee wordt de serviceverlener(s) verzocht een offerte voor de realisatie te doen.

wijzigingenbeheer applicatiebeheer functioneel beheer specificeren impactanalyse

Een wijziging zal vaak gevolgen hebben voor de gebruikersorganisatie, denk aan veranderde procedures, aan extra opleidingen enzovoort. Ook daarvoor wordt een impactanalyse uitgevoerd, de gebruikersimpact. Dit is de verantwoordelijkheid van business informatiemanagement.

Bij grote veranderingen zal business informatiemanagement die impactanalyse laten uitvoeren door een procesanalist of een informatieanalist, eventueel geassisteerd door een AO-adviseur. Dan worden vaak ook informatiemanagers en architecten bij het project betrokken, want een belangrijk aandachtspunt is het onderzoek naar de gevolgen van de wijziging elders in de keten van applicaties of voor andere bedrijfsprocessen.

De gebruikersimpact betreft veel aspecten: het moet COPAFEITHJ-breed worden uitgevoerd. Dit acroniem bestaat uit de beginletters van de onderwerpen waarvan de impact onderzocht moet worden: Commercie, Organisatie, Personeel, Administratie, Financiën, Ecologie/ergonomie, Informatie, Technologie, Huisvesting en Juridisch."

(...)

"Als de gebruikersimpact en de applicatie-impact bekend zijn, zal de business case op hoofdlijnen worden herzien en zal het mogelijk zijn een aangescherpte business case, de uitgewerkte business case, te maken. Deze is dan de basis voor de definitieve beslissing over het wijzigingsvoorstel door de systeemeigenaar."

"Is het wijzigingsvoorstel haalbaar, dan zal het worden voorgedragen aan het releaseoverleg voor invoering. Er wordt vanaf dat moment niet langer per wijzigingsvoorstel gekeken, maar naar alle wijzigingsvoorstellen van een toekomstige release. In veel organisaties is er sprake van een Change Advisory Board (CAB) conform ITIL. Het belang van de gebruikersorganisatie staat bij de beslissingen steeds voorop.

Welke personen aan het releaseoverleg deelnemen, zal per organisatie anders kunnen zijn, maar in ieder geval komen business informatiemanagement, applicatiemanagement en IT-servicemanagement hier samen. Wanneer de rol en samenstelling van het overleg goed beschreven zijn en bij iedereen bekend, is het doorvoeren van wijzigingen beheersbaar. Het releaseoverleg zal vanuit de sturende processen van BiSL een mandaat hebben gekregen over planningen, budgetten en behoeften. Door de IT-serviceverlener wordt een releasemanager verantwoordelijk gesteld voor de coördinatie van de realisatie."

 

betrokkenheid funtioneel beheerder wijzigingsbeheer functioneel beheer

Gedurende zijn bestaan doorloopt een informatiesysteem een aantal stadia. De meeste informatiesystemen doorlopen de stadia meerdere keren voordat ze buiten gebruik worden gesteld. Bovenstaande figuur geeft de betrokkenheid aan van de functioneel beheerder bij de verschillende fasen van de levenscyclus. In de oriëntatiefase is de centrale vraag: 'Waarom wil de gebruikersorganisatie deze verandering en hoe kan ze dit bereiken? "In dit stadium - ook wel definitiestudie of vooronderzoek genoemd - gaat het om twee zaken. Ten eerste worden de behoeften (problemen en kansen) van de organisatie, of een deel daarvan, in kaart gebracht. Ten tweede worden mogelijke oplossingsrichtingen onderzocht en deze worden beoordeeld op haalbaarheid met betrekking tot de business case en tot de gebruikers- en applicatie-impact. Dat onder meer een analyse van de bedrijfsprocessen essentieel is, zal duidelijk zijn.

(...)

Bij de verandering van de informatievoorziening wordt door ASL het woord impactanalyse gebruikt voor de applicatie-impact. De activiteiten van het vooronderzoek maken deel uit van de BiSL-processen Specificeren en Vormgeven niet geautomatiseerde Informatievoorziening.

(...)

De betrokkenheid van de functioneel beheerder is onontbeerlijk tijdens het oriëntatiestadium. Dit geldt ook tijdens het realisatiestadium, onafhankelijk voor welke oplossingsrichting gekozen is. Immers daar waar het gaat om de gebruikersbehoeften en -wensen kan men de functioneel beheerder niet uitsluiten. De functioneel beheerder spreekt namens de systeemeigenaar en de toekomstige gebruikers met applicatiemanagement (de informatieanalisten respectievelijk de functioneel ontwerpers) en brengt de wensen in. ... De functioneel beheerders zijn nauw betrokken bij de stadia Acceptatietest, Implementatie en Gebruik & Evaluatie. Immers, zij bemiddelen tussen (toekomstige) gebruikers en leverancier over de functionaliteit en kwaliteit van de applicatie en de bijbehorende diensten. Het is mede de verantwoordelijkheid van de functioneel beheerder om het resultaat van de acceptatietest te beoordelen en te adviseren aan de systeemeigenaar of tot ingebruikneming kan worden overgegaan.

Ten slotte wordt de applicatie - als onderdeel van de gewijzigde informatievoorziening - in beheer genomen, waarbij de functioneel beheerder verantwoordelijkheid draagt voor een optimale beschikbaarheid van de functionaliteit van de informatievoorziening."

 

Specificeren

"Het sturende proces Behoeftemanagement zorgt ervoor, dat er voor de informatiebehoeften van de bedrijfsprocessen jaarplannen zijn. Die plannen bevatten nieuwe behoeften, of veranderingen in de bestaande informatievoorziening en applicaties. Die behoeften aan veranderingen zullen leiden tot wijzigingsvoorstellen. Binnen het proces Wijzigingenbeheer worden de wijzigingsvoorstellen gekozen die ingevoerd gaan worden. Behoeftemanagement geeft voor die keuzes de kaders en prioriteiten.

Voor de systeemeigenaar een definitieve beslissing kan nemen over het al dan niet realiseren van een wijzigingsvoorstel moet er een business case op hoofdlijnen zijn. Daarvoor krijgt hij een globaal inzicht in de consequenties (impact) en haalbaarheid van een wijzigingsvoorstel. Voor het bepalen van een business case op hoofdlijnen is een onderzoek nodig. Alle activiteiten van zo'n onderzoek behoren tot het vooronderzoek of de definitiestudie; dat komt overeen met het stadium Oriëntatie. Het proces Specificeren hoort bij dat stadium en dient ervoor om de behoeften te concretiseren, de gewenste doelen duidelijk vast te leggen, de mogelijke oplossingsrichtingen te onderzoeken en de haalbaarheid voor de gebruikersorganisatie te valideren (behoefte, oplossing, validatie).

(...)

De meeste wijzigingsvoorstellen maken een ontwikkeling door, want aanvankelijk zijn ze vaak nog niet duidelijk genoeg geformuleerd. De behoeften (aanleiding, doel en randvoorwaarden) moeten nauwkeurig worden gespecificeerd. Het formuleren van de behoeften moet in functionele termen gebeuren: wat wil de gebruikersorganisatie bereiken? Dat is het eerste doel van het proces Specificeren. Maar er zijn ook randvoorwaarden.

(...)

Tijdens Specificeren wordt het wijzigingsvoorstel nader uitgewerkt. De functioneel beheerder begeleidt de gebruikers bij het nauwkeurig formuleren van de behoeften. Business informatiemanagement (meestal de systeemeigenaar, of een door hem gemandateerde functioneel beheerder) geeft de opdracht aan applicatiemanagement en vraagt aan hen te onderzoeken hoe de eisen in de applicatie kunnen worden gerealiseerd; daarvoor zijn duidelijk vastgelegde behoeften nodig: requirements.

(...)

Het onderscheid tussen gebruikersimpact en applicatie-impact is van belang omdat er bij een oplossing meestal een geautomatiseerd deel en altijd een niet-geautomatiseerd deel is. De applicatie-impact is primair een taak van applicatiemanagement, soms samen met IT-servicemanagement. ... Parallel aan de applicatie-impact wordt de gebruikersimpact uitgevoerd en worden de gevolgen voor de gebruikersorganisatie in kaart gebracht. Daarvoor dient het proces Vormgeven niet-geautomatiseerde informatievoorziening.

Door beide impactanalyses ontstaat duidelijkheid over de vraag of een oplossing realistisch is. ... BiSL gebruikt het begrip niet-geautomatiseerde informatievoorziening voor de gevolgen binnen de gebruikersorganisatie. Het is de taak van de business informatiemanagers om die zijde van de oplossingsrichting te (laten) onderzoeken."

 

Requirements

Ruigrok en Bosschers onderscheiden twee soorten requirements: functionele requirements en niet-functionele requirement. "Functionele requirements betreffen de gewenste functionaliteit: wat moet de applicatie kunnen doen voor de gebruikers De applicatie bezit de vastgelegde en vanzelfsprekende (!) functies. Vermeden moet worden dat de gebruikersorganisatie de eisen formuleert in de vorm van (technische) oplossingen. Niet-functionele requirements zijn kwaliteitseisen, de eisen die gesteld worden aan het gebruik, zoals verwerkingssnelheid, frequentie van gebruik, vormgeving van de user interface, enzovoort.

(...)

Bij het formuleren van requirements is het belangrijk het volgende onderscheid te maken: (i) business requirements (beschrijven de behoeften geformuleerd vanuit de businessdoelen), en systeemrequirements (beschrijven wat van een applicatie wordt verwacht).

(...)

Goede business requirements identificeren behoeften van de organisatie en moeten afleidbaar zijn uit de business strategie. De businessstrategie is de manier waarop de organisatie haar doelen wil bereiken. Door het proces Behoeftemanagement ligt er een jaarplan voor de informatievoorziening."

 

Releasematig werken

De frequentie waarmee bedrijfsprocessen moeten worden aangepast aan veranderingen in de omgeving is steeds hoger geworden. Vandaar ook dat de ondersteunende informatievoorziening bijna continu aan verandering onderheving is. (...) Het is belangrijk, dat er een bepaalde rust is in de werkomgeving. Als de stroom van wijzigingen niet wordt beheerd en gereguleerd, worden de gebruikers en beheerders continue met veranderende applicaties en werkinstructies geconfronteerd. Daarom werken de meeste organisaties releasematig.

Een release is een nieuwe of gewijzigde applicaties en/of IT-infrastructuur met bijbehorende documentatie en werkinstructies, die op een beheerste manier als een eenheid wordt ingevoerd in de gebruikersomgeving. Releasematig werken houdt in dat met een vaste frequentie wijzigingen, aanvullingen en verbeteringen worden doorgevoerd in de informatievoorziening. De systeemeigenaar spreekt vooraf een releasekalender af met applicatiemanagement en IT-servicemanagement. Dit betekent voor zowel business informatiemanagement (met name de functioneel beheerder) als voor de gebruikers ene periode van stabiliteit in de informatievoorziening tussen de releasedata.

 

Bron: De functioneel beheerder en BiSL, Kees Ruigrok & Ernst Bosschers

 

Laatst aangepast op maandag, 01 januari 2018 12:57  


JPAGE_CURRENT_OF_TOTAL

 

Don't find fault, find a remedy.

Henry Ford

Banner

Archief

Lean boeken top 5

(maart 2016)
Banner
Banner
Banner
Banner
Banner

We hebben 149 gasten online
Artikelen

continu verbeteren mark twain continuous improvement delayed perfection

Banner
Banner

ik ben een planteneter boele ytsma

Ik ben een planteneter
net als jij
Boele P. Ytsma

Bij Bol.com

Lean boekentips

Banner