De 'business-partner' is de rol waarin iemand zich bezig houdt...

1. (Meedenken bij) ontwerpen en inrichten van processen

2. (Betrokken bij) proces- en ketensturing.

3. Zicht hebben op de werkelijke informatie- en communicatiepatronen

Bekijk ook mijn artikel met verwijzingen naar de andere rollen binnen het negenvlaksmodel.

Bron:  Toon Abcouwer op http://www.abcouwer.nl, http://www.humanlogic.nl/Resources/Negenvlak-Informatiemanagem.pdf en http://www.humanlogic.nl/bieb/Resources/ToonAbcouwer-HetNegenvlak.pdf

De 'alignment-manager' is de rol waarin iemand zich bezighoudt met...

1. Inrichten van de organisatie

2. Borgen effectieve inzet van de organisatie met de bijbehorende ondersteuning

3. Afstemmen van de organisatie en haar informatievoorziening

Bekijk ook mijn artikel met verwijzingen naar de andere rollen binnen het negenvlaksmodel.

Bron:  Toon Abcouwer op http://www.abcouwer.nl, http://www.humanlogic.nl/Resources/Negenvlak-Informatiemanagem.pdf en http://www.humanlogic.nl/bieb/Resources/ToonAbcouwer-HetNegenvlak.pdf

Binnen het Amsterdamse Informatiemanagement Model (AIM) staat binnen het negenvlak de rol van regisseur voor:

1. Kennen en coördineren van de rollen rond het informeren en communiceren binnen de organisatie

2. Afstemmen tussen de diverse rollen

3. Fungeren als 'de spin in het web

Alle rollen binnen het AIM moeten in samenhang worden beschouwd. In het hart van het negenvlak wordt dan ook een regierol onderkend, met als taak het bijeenbrengen van de verschillende invalshoeken die horen bij de verschillende rollen.

Bekijk ook mijn artikel met verwijzingen naar de andere rollen binnen het negenvlaksmodel.

Bron:  Toon Abcouwer op http://www.abcouwer.nl, http://www.humanlogic.nl/Resources/Negenvlak-Informatiemanagem.pdf en http://www.humanlogic.nl/bieb/Resources/ToonAbcouwer-HetNegenvlak.pdf

Binnen het negenvlak(smodel) worden negen rollen onderscheiden (ook al heeft men het over 'acht rollen, met een regie-rol in het midden'):

1. Informatiepartner in strategie

2. Informatiebeleidsmaker

3. ICT-Trendwatcher

4. Manager ICT-voorzieningen

5. Applicatiebeheerder

6. Gebruikersondersteuner

7. Business-partner

8. Alignment-Manager

9. Regisseur

Bron:  Toon Abcouwer op http://www.abcouwer.nl, http://www.humanlogic.nl/Resources/Negenvlak-Informatiemanagem.pdf en http://www.humanlogic.nl/bieb/Resources/ToonAbcouwer-HetNegenvlak.pdf

Binnen de agile softwareontwikkeling vormen de zgn. user stories de aanbevolen requirementstechniek. User stories staan voor requirements verteld vanuit het gezichtspunt van de gebruikers. Belangrijk hierbij is dat de veranderbehoefte wordt weergegeven in de taal van taal van de business.

Volgens Nicode de Swart voldoen user stories bij voorkeur aan de syntax: "Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>" en geeft hierbij als voorbeeld: "Als student wil ik mijn cijfers online bekijken zodat ik sneller weet of ik het examen heb gehaald." Het gaat hierbij alleen om de korte omschrijving ter aanduiding van de user story. Het is niet de bedoeling om volledige functionaliteit al tot in detail te beschrijven. Hiervoor is een ander onderdeel de user stories bedoeld: mondelinge communicatie. 'Mondeling' omdat het veel effectiever is om detailinformatie mondeling over te dragen.

Zodra de ontwikkelaar een user story gaat implementeren is detailinformatie nodig over de gewenste werking van de user stories. De korte omschrijving is té globaal, zodat het ontwikkelteam de gebruiker (product owner) vragen moet gaan stellen. De antwoorden op de vragen worden - voor zover nodig voor de correcte werking van de te realiseren software - vastgelegd als acceptatiecriteria. Door de samenwerking tussen het ontwikkelteam en de product owner is dus ook geen analist nodig als brugfunctie tussen business en ICT.

Deze acceptatiecriteria vormen het derde onderdeel van user stories. De acceptatiecriteria hoeven - omdat er intensief wordt samengewerkt bij het implementeren van de user stories - niet volledig te zijn. De kracht van het werken met user stories is volgens De Swart dan ook dat het detailleren van requirements, het ontwikkelen van de software en het testen ervan hand in hand gaan: "De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden. Aangezien een user stories in enkele dagen tot ruim een week tijd gerealiseerd wordt, is het niet nodig om naast de mondelinge afstemming nog veel te documenteren."

Onderdelen user story

1. Korte beschrijving als aanduiding van de requirement (ivm planning)

2. Mondelinge communicatie om de details te achterhalen (tijdens de realisatie)

3. Acceptatiecriteria om juiste werking vast te stellen

De kracht van user stories zit in het feit dat door de intensieve samenwerking tussen het ontwikkelteam en de product owner en de nadruk op mondelinge communicatie drie voordelen optreden:

1. Eenvoud:"Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook want het is onmogelijk om de requirements (in use cases) voor 100% volledig en eenduidig te specificeren".

2. Flexibiliteit: user stories kunnen beter omgaan met voortschrijdend inzicht: "Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project".

3. Snelheid: een user story moet in maximaal 10 werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, moeten worden opgesplitst. Kom daar maar eens om, bij een volledige use case. Het is niet langer een analist gedetailleerd requirements te laten specificeren. Verder gaat ook geen tijd verloren aan het lezen en begrijpen van gedetailleerde requirements door de ontwikkelaars en testers en is het - omdat detaillering van requirements later en mondeling plaatsvindt - niet nodig om wijzigingen door te voeren in de specificaties.

Bron: Nicole de Swart op http://www.reaco.nl/kenniscentrum/userStories.asp

Op haar website stelt Nicole de Swart dat mooi zou zijn als requirements 'just in time' kunnen worden opgesteld: "Net op tijd om te kunnen plannen en net op tijd om de software te kunnen ontwikkelen. We zouden dan geen last hebben van wijzigende requirements, geen change control board nodig hebben en geen scope creep kennen. Dit scheelt veel tijd, geld en gedoe."

In de goede oude watervaltijdperk was het de gewoonte om alle requirements ver van te voren op te stellen (up front) om vervolgens op basis van de totale set aan requirements een offerte op te stellen, een planning te maken en te kunnen starten met de ontwerp- en bouw-activiteiten. De werkelijkheid blijkt alleen wat minder voorspelbaar dan gehoopt, zodat wijzigingen in de overeengekomen requirements onvermijdelijk zijn (bijv. door veranderingen in de omgeving, voortschrijdend inzicht en/of ontbrekende requirements).

Volgens De Swart laten agile ontwikkelmethoden zien dat 'just in time' requirements mogelijk zijn. Het idee hierbij is het vaststellen (en vooral detailleren) van requirements zo lang mogelijk uit te stellen. In eerste instantie is het alleen nodig een globaal totaalbeeld te hebben dat net genoeg detail geeft om de doorlooptijd van het project in te kunnen schatten. Vervolgens worden alleen de requirements die ook daadwerkelijk moeten worden geïmplementeerd nader uitgewerkt. Ook hier geldt weer dat het detailniveau net genoeg moet zijn om de relatieve ontwikkelinspanning (niet in uren) in te kunnen schatten en een planning op te stellen voor de eerstvolgende iteratie.

"Pas als een ontwikkelaar daadwerkelijk de software voor een bepaalde requirement gaat bouwen, spreekt hij de wensen en de details door met de continue beschikbare (en fysiek aanwezige) vertegenwoordiger van de business. Met deze aanpak zijn de juiste requirements, op het juiste detailniveau, 'just in time' beschikbaar. Omvangrijke producten met uitgebreide specificaties hoeven dan niet opgesteld en niet onderhouden te worden."

Bron: http://www.reaco.nl/kenniscentrum/vanUpFrontNaarJustInTime.asp

Nicole de Swart definieert de belanghebbenden (stakeholders) bij een softwareontwikkeltraject als de personen of organisatie(onderdelen) die beïnvloed wordt door of zelf invloed kunnen uitoefenen op de uiteindelijke werking van het systeem en stelt dat belanghebbenden en requirements onlosmakelijk met elkaar verbonden zijn: belanghebbenden zijn de bron voor de requirements en bepalend voor de behoeften en eisen die vanuit de business aan het te ontwikkelen systeem worden gesteld.

De Swart maakt een onderverdeling in drie hoofdgroepen belanghebbenden (op basis van het verschil in belang dat men heeft):

1. Belanghebbenden bij het businessdoel: belang bij het verbeteren van de interne bedrijfsvoering of bij het op de markt brengen van een nieuw softwareproduct. Bijv. opdrachtgever en/of sponsor.

2. Belanghebbenden bij het systeem: belang bij, nadat het geautomatiseerde systeem is ingevoerd, de werking van het systeem, in de zin dat ze voordelen óf nadelen kunnen nadeel ondervinden van de invoering van het nieuwe systeem. Bijv. gebruikers, 'systeemondersteuners' (beheerders, helpdesk), 'autoriteiten' (juridische afdeling, IT-auditoren).

3. Belanghebbenden bij het project: werken vaak mee aan de totstandkoming van het systeem en hebben tijdens het project en vaak ook daarna nog, als het systeem in beheer is genomen, invloed op de werking van het systeem. Bijv. projectteam, ICT-afdeling, gebruikersvoorbereiders (verandermanagers, opleiders, opstellers gebruikershandleiding)

Bron: Handboek Requirements (2010), Nicole de Swart en http://www.reaco.nl/handboekRequirements/praktischeHandvatten/ChecklistBelanghebbenden.pdf

Tom Heisterkamp (Belastingdienst) geeft in zijn presentatie op de themasessie 'Business en IM: Living Apart Together?' (18 jan 2011) aan welke eisen men binnen de Belastingdienst stelt aan de IV-keten. Hij maakt hierbij onderscheid tussen eisen aan de dienstverlening en eisen aan houding en gedrag. Een keurige set aan eisen die feitelijk breder toepasbaar is dan alleen de IV-keten.

Dienstverlening is...

1. Beschikbaar: continuïteit van systemen is op het niveau dat we met de bedrijfsonderdelen hebben afgesproken, ook in geval van 'rampen'.

2. Betrouwbaar: de voorspelbaarheid van onze dienstverlening is groot; we leveren wat we beloven volgens specificaties, op tijd en binnen budget..

3. Bestuurbaar: de aansturing van de IV-keten is gericht op het inzicht geven in en voortdurend verbeteren van prestaties.

4. Betaalbaar: de kosten van onze dienstverlening zijn volledig transparant voor de bedrijfsonderdelen en in lijn met industrie benchmarks.

In houding & gedrag (naast de basiswaarden geloofwaardigheid, zorgvuldigheid en verantwoordelijkheid) tonen van ...

1. Openheid: we zijn open in ons handelen en betrekken de juiste mensen bij besluitvorming. We communiceren tijdig en effectief. We creëren dialoog door actief te luisteren en het stellen vragen.

2. Vertrouwen: we vertrouwen op de professionaliteit van onze collega's en waarderen initiatief en proactief handelen.

3. Resultaat: we meten en waarderen op behaalde resultaten. We creëren focus en stellen prioriteiten. We leveren van onze fouten.

Met de theorie is bij de Belastingdienst is dus niets mis!

Bron: http://www.aslbislfoundation.org/component/option,com_docman/task,doc_download/gid,687/lang,nl/

Tom Heisterkamp (Belastingdienst) geeft in zijn presentatie op de themasessie 'Business en IM: Living Apart Together?' (18 jan 2011) op bovenstaande wijze het negenvlaksmodel van Maes weer. De afkorting BP staat voor bedrijfsprocessen, en IV voor informatievoorziening.

Bron: http://www.aslbislfoundation.org/component/option,com_docman/task,doc_download/gid,687/lang,nl/