• No results found

Meten efficiëntie .1 Project Class

In document Appendix A - Requirement Types (pagina 40-47)

Meten Efficiëntie en Effectiviteit Requirement engineering

BIJLAGE C – HANDLEIDING “EXPORT TO ACCESS”

10 Meten efficiëntie .1 Project Class

De project class is de uitkomst van het per project ingevulde formulier “project characteristics”. Dit formulier is een onderdeel van het tailoring proces. De project characteristics zijn opgesteld

doormiddel van een uitgebreide enquête onder projectmanagers om de factoren op papier te krijgen die de zwaarte van het project bepalen.

De project characteristics zijn opgenomen in het werkplan van het betreffende project en is te vinden in de projectmap in Cascade. Uit het werkplan moeten voor de meting de size, complexity en risk assessments worden overgenomen. In Tabel 3 staan de mogelijke waarden die kunnen worden gegeven aan de size, complexity en risk.

Tabel 3

Dominant factor Value

Size Small/Medium/Large

Complexity Low/Medium/High

Risks Low/Medium/High

In de MEER database wordt automatisch de juiste project class geselecteerd op basis van de

ingevoerde waarden bij size, complexity en risk. De mogelijke combinaties met de bijbehorende class zijn weergegeven in Tabel 4.

Tabel 4

Class Size Complexity Risk

0 very small low low

1 small low low

1 small low high

2 small high low

2 small high high

2 medium low low

2 medium low high

3 medium high low

3 medium high high

3 large low low

3 large low high

3 large high Low

3 large high high

Selected projectclass 0/1/2/3 10.2 Urenregistratie

Uit AIMS-ATR moeten de uren worden geselecteerd per project voor de uren behorende bij requirement engineering.

In de nieuwe standaard urenregistratie business moet gebruik worden gemaakt van de methodecode DSB (DSDM-Business). De aanvraag formulieren zijn te vinden op

ms.html). Als deze code wordt gebruikt kunnen de uren gespendeerd aan het werk als solution engineer en requirement engineer uren apart worden geregistreerd. Deze uren staan dan geregistreerd op de activiteitencodes eindigend op een cijfer met daarna de letter S(solution engineering) of een E(requirement engineering).

Voor een overzicht van de uren per activiteit per project kan:

- Business Objects een handmatige selectie worden gemaakt uit AIMS.

- Webintelligence Infoview van een standaard rapportage gebruik worden gemaakt. 10.2.1 Infoview

Voor de handmatige selectie met Business Objects is kennis van Business Objects vereist. De standaard rapportages uit Infoview zijn in vijf eenvoudige stappen op te vragen. Om gebruik te maken van infoview is autorisatie benodigd.

Stap 1: Start de applicatie Webintelligence infoview.

Dit kan via Banknet/Infotheek/Rapportages. Onder het kopje managementinformatie klikken op Webintelligence Infoview.

Stap 2: Log in.

Typ je User-ID (hoofdletters) en SBT-wachtwoord in. Stap 3: Klik het gewenste rapport aan.

Kies de directory waar het bewuste rapport staat en klik op het betreffende rapport.

Dit is in dit geval de rapportage <*******> in de directory <*******>.

Stap 4: Geef de gevraagde inputvariabelen op.

Zodra het rapport is aangeklikt vraagt de applicatie om de voor dat rapport noodzakelijke inputvariabelen. Voor deze rapportage dient bijvoorbeeld de projectcode opgegeven te worden.

Stap 5: Opslaan / Printen

Het opgevraagde rapport wordt zichtbaar op het scherm en kan opgeslagen of geprint worden. 10.2.2 Autorisatie

Om van infoview gebruik te kunnen maken moeten onderstaande zaken zijn geregeld:

1. Uw SBT-beheerder dient uw user-ID te autoriseren voor Business Objects 6 niveau 2 (TSB26) 2. De contactpersoon4 van uw directoraat dient middels een Lotus Notus bericht aan AIMS

Helpdesk te verzoeken uw User-ID toe te voegen aan de Supervisortabel Business Objects op het domein FINS Bij de aanvraag moet worden aangegeven dat de gebruiker rapportages wil opvragen uit AR03 Project, AR04 Subproject en AR05 Time Registration.

3. AV2/Mainframe rechten zijn nodig en kunnen worden aangevraagd bij INSTAP(INtranet Security Aanvraag Procedure). http://eua041.ao.nl.abnamro.com/Applications/S-Z/SAP.nsf

via de link medewerkers autorisaties > persoonlijke autorisaties > mainframe > mainframe overig.

Onder selecteren dient dan het volgende aangevinkt te worden: - BUSINESS OBJECTS VIA AV2 (ABOBJII)

4 Bij de implementatie dient met de AIMS Helpdesk te worden afgestemd welke personen bij welk

Opmerking [A.G.P.1]: Welke rapportage?

Opmerking [A.G.P.2]: Welke rapportage?

- OMVS SEGMENT (OMVS MAINFRAME) - TSO AV2 (ATSOA2U)

Heeft men ooit al gebruik gemaakt van Business Objects dan kan de AIMS Helpdesk het User-ID alleen toevoegen aan de juiste Supervisortabel als het betreffende User-ID zich al in haar domein (FINS) bevindt. Is dat niet het geval dan zal de AIMS Helpdesk namens u een call indienen bij de IBM helpdesk (291900) om uw User-ID beschikbaar te laten maken voor het domein FINS.

10.2.3 Printen

Om een rapport toonbaar op papier te krijgen is het van belang dat de standaard instellingen worden aangepast. Dit kan door op Options te klikken en vervolgens in het tabblad View de optie PDF in Infoview aan te klikken.

10.3 Functiepunten

In het onderzoek “Efficiency and effectivity of the ABN AMRO solution delivery organisation” is de correlatie onderzocht tussen de getelde functiepunten van een project en de uren die zijn besteed in het voortraject(BS en FMI fase). Uitkomst van dit onderzoek was dat er op basis van de huidige gegevens geen significante correlatie kon worden aangetoond.

De gebruikte gegevens voor het onderzoek waren de gegevens van projecten uit 2005. In 2005 werd echter de urenregistratie nog niet volgens de methodecode “DSB” geregistreerd. Om het functiepunten onderzoek te verifieeren met een betrouwbaardere urenregistratie uit 2007 zullen ook de functiepunten verzameld moeten worden.

De functiepunten staan in de universe SPC van AIMS dat is te benaderen via Business Objects. De Functiepunten zijn te vinden in tabel Subproject onder: Subproject > Dashboard > Dashboard events > size measurments.

Voor het uitvoeren van de query in Business objects is een standaard sjabloon gemaakt. Het sjabloon

is te vinden in de cascademap: <*******> met de naam “Functiepunten per project.rep” Opmerking [A.G.P.3]: Welke rapportage?

11 Rapportages

Om uit de MEER database de gewenste managementinformatie op te vragen zijn er een aantal standaard rapportages opgesteld. Deze zijn te benaderen onder het menu “rapportages”.

11.1 Uur/Project Class

Aantal uur delen door de project class. (onderverdelen in size,complexity en risk)

o Op den duur kan inzicht worden verkregen in de benodigde hoeveelheid uren aan de hand van een bepaalde project class.

o Budget aanvragen kunnen worden gecontroleerd op basis van historie.

o Projecten waarvoor wel een juiste projectclass is bepaald maar niet binnen de uren bandbreedte kunnen blijven, leveren waardevolle informatie op over de oorzaak van de afwijking. Bijvoorbeeld een projectteam samenstelling die niet goed is geweest of andere oorzaken die aan het licht kunnen komen door een gesprek met project leiders(doorspreken van de punten uit project class). Het voordeel is dat een gesprek gericht kan worden gehouden met het project dat niet in de bandbreedte qua uren is gebleven.

o Met onderverdeling size, complexity en risk kan worden aangegeven, als projecten afwijken op efficiëntie, waar de oorzaak kan worden gezocht namelijk size, complexity of risk.

Voordelen

Project managers kunnen het inschatten van de benodigde hoeveelheid uren controleren aan de hand van de combinatie uren/projectclass.

Management kan de budget aanvragen controleren aan de hand van de combinatie uren/projectclass. Gericht zoeken naar de oorzaak van een afwijking van het gemiddelde.

11.1.1 Analyse

Zoals in paragraaf 8.5 uitgelegd kan de efficiëntie van een project worden getoetst aan een bandbreedte van uren per project class.

Als voldoende informatie is verzameld van verschillende projecten kan een bandbreedte van uren worden aangegeven voor de verschillende projecten.

Bij analyse van de efficiëntie zijn de volgende opties mogelijk:

- Valt een project buiten de bandbreedte voor de betreffende project class dan is er: o Een afwijking van het gemiddelde van projecten met de betreffende project class.

1. Is deze hoger dan de bandbreedte dan is het project minder efficiënt geweest. 2. Is deze lager dan de bandbreedte dan is het project efficiënter geweest. o Een foutieve project class toegekend aan het project

o Het aantal uren is niet correcte bijgehouden

- Valt een project binnen de bandbreedte voor de betreffende project class dan is er: o Geen afwijking van het gemiddelde

o Een kleine afwijking van het gemiddelde

1. Is deze hoger in de bandbreedte dan is het project minder efficiënt geweest dan het gemiddelde.

2. Is deze lager in de bandbreedte dan is het project efficiënter geweest dan het gemiddelde.

o Een foutieve project class toegekend aan het project o Het aantal uren is niet correcte bijgehouden

11.2 Findings/requirements

Aantal findings delen door aantal aangeleverde requirements per type. De effectiviteit is bij een laag aantal findings hoger dan een hoog aantal findings. Het verschil in effectiviteit kan:

o Aangeven welk project hoger of lager zit dan de gemiddelde effectiviteit en bij deze projecten gericht zoeken naar de juiste werkwijzen of niet juiste werkwijzen van dat betreffende project.

o Aangeven of er veel discussie/onenigheid was over de opgestelde requirements(totaal aantal findings / defects) hiermee mogelijke problemen opsporen, nu discussie kan onderwerpen van problemen aangeven die gaan komen.

o Aangeven hoeveel van wat voor severity aan defects er zijn gemaakt. Allemaal minor fouten is misschien gewoon slordigheid, allemaal major defects in een project is een teken dat daar een verbetering kan worden gehaald.

o Aangeven in welk type requirement de meeste fouten voorkomen. Blijkt dat de detailrequirements veel findings bevatten kan het zijn dat aan het licht komt dat de hardwarerequirements niet goed zijn opgesteld en dat dit komt door verkeerde adviezen van de vendor.

Voordelen

Gericht zoeken naar juiste werkwijzen.

Aangeven welke projecten onderdelen hebben die voor veel discussie en onenigheid zorgen. Inzicht geven in wat voor soort fouten er worden gemaakt.

Inzicht geven op wat voor gebied(type requirement) fouten worden gemaakt. 11.2.1 Analyse

Zoals in paragraaf 8.5 uitgelegd kan de effectiviteit van een project worden getoetst ten opzichte van andere projecten.

Als voldoende informatie is verzameld van verschillende projecten kan een gemiddelde effectiviteit van projecten worden aangegeven.

Bij analyse van de effectiviteit zijn de volgende opties mogelijk:

- Een project scoort niet hoger of lager dan de gemiddelde effectiviteit van de projecten. - Een project scoort hoger of lager dan de gemiddelde effectiviteit van de projecten.

o Bij deze projecten kan bijvoorbeeld worden gezocht naar juiste werkwijzen of onjuiste werkwijzen.

o Kan worden gekeken op welk type requirement de findings betrekking hebben. Door gebruik te maken van “testdirector” kan de specifieke requirement worden getraceerd. o De overige punten zoals genoemd bij 11.2.

- Een effectiviteitscore is beïnvloed door het foutieve aantal requirements - Een effectiviteitscore is beïnvloed door het foutieve aantal findings of defects

11.3 Extern/Intern

Aantal uren Externemedewerkers in verhouding tot het aantal uren Internemedewerkers per (deel)project. (Externe efficiëntie en interne efficiëntie)

o Deze verhouding tezamen met efficiëntie en effectiviteit geeft aan wat de efficiëntie en effectiviteit is van de geleverde externe medewerkers. Of dat er intern opleidingen op bepaalde gebieden nodig zijn.

o Deze data kan aangeven dat domeinkennis wel of niet een belangrijke eigenschap is voor een business analist. (efficiëntie hoger extern dan intern(we verwachten nu dat

domeinkennis een tijdsbesparing oplevert)) het kan ook aantonen dat de efficiëntie juist lager is bij projecten met veel externen omdat de inwerk(leer)tijd moet worden meegenomen(voor domeinkennis).

o Externe benchmark, door intern te vergelijken met extern.

o Effectiviteit + externe en interne uren. Of de effectiviteit hoger is bij een hoger aantal externe uren dan intern, of andersom.

Verhouding requirements per uur + aantal findings per uur.(intern+extern)

o Is sneller werken ook productiever of worden er alleen maar meer fouten gemaakt. o Is dit hetzelfde voor interne en externe medewerkers?

Voordelen

Efficiëntie en effectiviteit van externen. Efficiëntie en effectiviteit van internen.

Verhouding externe efficiëntie en effectiviteit ten opzichte van interne efficiëntie en effectiviteit. Benchmarken door gebruik te maken van deze verhouding intern/extern.

11.4 IT/Business

Door het bijhouden van de uren van IT en van Business in de BS en FMI fase kan:

o Worden bekeken of Business meer of minder efficiënt/effectief is als IT meer of minder meewerkt in de BS en FMI fase.

Voordelen

De verhouding van IT en Business aandeel in de BS en FMI fase kan worden vergeleken.

12 Rollen

Het verzamelen van data is eenvoudig werk maar bij het invullen van de data in de tool moet de afweging worden gemaakt of de data bijdraagt aan de managementinformatie die de tool moet verstrekken. Blijkt dat bij een project geen findings zijn geregistreerd of dat er geen uren zijn geboekt volgens de nieuwe manier van urenverantwoording business is het de taak van degene die de data verzameld om de afweging te maken of het project wel of niet moet worden opgenomen.

Als het gaat om de uren die niet zijn geboekt op de codes Solution engineer en Requirement engineer, kan het ook zijn dat de informatie nog wel kan worden verkregen door de uren uit AIMS te selecteren op persoon. Er is namelijk altijd bekend wie er als business analist hebben gewerkt aan het project. In dit laatste geval kan het project dus wel worden opgenomen, maar is extra werk vereist om tot de juiste data te komen.

Naast het verzamelen van de data moeten er standaard een aantal rapportages worden gemaakt voor het management.

De rol efficiëntie en effectiviteit analist REM (MEERA) wordt vervuld door de Acceptatie

Specialisten van Business Acceptatie. De MEERA’ers werken mee met de projecten en hebben inzicht in de vordering van het project en kunnen inschatten of de benodigde informatie aanwezig is bij het project. De MEERA’er die is toegewezen aan het project is ook degene die belast is met het

zo spoedig mogelijk in de tool te worden ingebracht. Doorgaans zal aan het einde van de FMI of in de DBI fase zeker alle data beschikbaar zijn en dus in de tool moeten worden ingevoerd.

De rol efficiëntie en effectiviteit manager (MEER) wordt vervuld door de BAM’er. De MEER’ers zijn verantwoordelijk voor de verzamelde data en moeten erop toezien dat de data wordt verzameld. De MEER’er maakt 1 maal per kwartaal de rapportages met daarin de nieuwste data en stuurt deze per mail naar de leden van het portfolioteam.

De belanghebbenden kunnen zelf tussentijds ook een rapportage opvragen bij de MEER’er. Overige belanghebbenden kunnen zijn:

- Verantwoordelijke voor inhuur van externen

- Verantwoordelijke voor de opleidingen van business analisten

- Aanspreekpunt dat vragen over van de VC’s beantwoordt over de interne rekeningen - Projectmanagers; inschatten project uren

- VP’s afdelingen development - SVP’s

- ESVP; totale score jaar tot jaar

13 Benchmarken

In document Appendix A - Requirement Types (pagina 40-47)