sogeti seminar supplier performance measurement

Supplier Performance

Measurement

Harold van Heeringen

2

Agenda

• Supplier Performance Measurement (SPM)

• Functiepunten en productiviteit

• Inrichten SPM proces

• Conclusies

3

Agenda




• Conclusies

4

Supplier Performance Measurement

• Organisaties besteden IT ontwikkeling en beheer uit aan 1 leverancier

• Deze ene leverancier wordt gekozen o.b.v. diverse criteria, bijvoorbeeld: − Omvang en schaalbaarheid

− Technische en functionele domeinkennis

− Bereidheid te investeren in verbetering

− Beloften v.w.b. productiviteitsverbetering

− Transparantie en voorspelbaarheid

• Leverancier moet meten en openheid geven

5

SPM – 3 fasen

1. Selectie van de juiste leverancier − Kwalitatieve criteria

− Kwantitatieve criteria

2. Vaststellen baseline productiviteit en prijs per UoM per domein

3. Voortdurend meten van prestaties van leverancier

6

Typische vragen in RFP fase SPM

• Wat is uw productiviteit in Java projecten?

• Wat is het percentage productiviteitswinst dat u de komende x jaar gaat realiseren?

• Hoe gaat u deze productiviteitswinst realiseren?

• Op welke manier stelt u voor om de productiviteit te meten?

7

Hoe word je de ‘chosen one’

• Volwassenheid − Minimum CMMI level 3, liefst hoger

• Hoge en aantoonbare productiviteit en kwaliteit − Kennis en vaardigheden medewerkers

− Efficiënte en effectieve processen, beperkte overhead

• Flexibel en meedenkend − Snel kunnen schakelen is een vereiste

− Inhoudelijk advies wordt verwacht

• Beloftes doen en nakomen − Basis is vertrouwen en transparantie

− Meten en rapporteren van productiviteit en kwaliteit

8

Volwassenheid (CMMI)

• Vanaf CMMI level 3 zijn processen voldoende gedefinieerd en beschreven in standaards, procedures, tools en methodes

9

Agenda




• Conclusies

10

Functiepunten

• In de meeste SPM trajecten komen de volgende zaken terug: − Unit of Measurement (UoM): b.v. functiepunten

− Productiviteit (PDR = uren per functiepunt)

− Kwaliteit (#defects per functiepunt na oplevering)

• Waarom functiepunten? − Functionaliteit is wat gebruiker wil

− Meer functionaliteit mag meer kosten

• Alternatief: regels code (technisch) − Is regels code wat de gebruiker wil?

− Meer regels code betekent niet meer functionaliteit

11

Functiepunten

• Functiepuntanalyse − Objectief (ISO standaard)

− Herhaalbaar

− Verifieerbaar

• Kwantificeert de omvang van de functional user requirements − Onafhankelijk van de technologie

− Onafhankelijk van de implementatie

• Zegt niets over non-functionals

12

Technologie onafhankelijk

• Applicatie A − Omvang = 500 FP

− Technologie: Java

− Architectuur stand alone

• Applicatie B − Omvang = 500 FP

− Technologie: Cobol / .NET

− Architectuur SOA

• Omvang is hetzelfde, maar productiviteit niet!

Applicatie A

Applicatie B

Uren besteed: 3.000

= 6 uur/FP

Uren besteed: 6.000

= 12 uur/FP

13

Productiviteit (uur/FP) – organisatie specifiek

• Kennis en vaardigheden van de mensen − Ervaring

− Certificering in technische omgevingen

− Bijscholingsmogelijkheden

• Volwassenheid van de organisatie − Aanwezigheid kwaliteitssysteem

− Processen, procedures, standaarden

• Overhead − Hoeveel tijd wordt gespendeerd aan activiteiten als

urencodes regelen, boeken van uren, vergaderingen, etc.

• Locatie en facilities − Onshore / offshore (veel video overleg)

− Prettige werkomgeving, goede tools, etc.

14

Productiviteit (uur/FP) – project specifiek

• Afhankelijk van technische requirements − Java, Oracle of MS.NET

− Client/server of SOA architectuur

• Afhankelijk van kwaliteit requirements − Performance eisen

− Security eisen

• Afhankelijk van uit te voeren activiteiten − Wel of geen performance test

− Wel of geen handleiding als deliverable

• Afhankelijk van doorlooptijd − Hoe korter de doorlooptijd, hoe lager de productiviteit

15

Het effect van doorlooptijd

Omvang/productiviteit

= Inspanning1/3 * doorlooptijd4/3

Inspannin

g

Doorlooptijd

Plan A: 6 maanden, 4.500 uur

Plan B: 7 maanden, 2.400 uur

16

Project bij verschillende doorlooptijden In

spannin

g (

ure

n)

Doorlooptijd

A

Doorlooptijd: 6 maanden

Inspanning: 4.500 uur

Max. teamomvang: 5,8 FTE

MTTD: 1,764 dagen

PDR = 9,0 uur/FP

B

Doorlooptijd: 7 maanden

Inspanning: 2.500 uur

Max. teamomvang: 2,7 FTE

MTTD: 2,816 dagen

PDR = 5,0 uur/FP

Omvang = 500 functiepunten

17

Leveranciers vergelijken

PDR (uur/FP)

18

Leveranciers vergelijken

19

Productiviteit (uur/FP) Leverancier A

Normaliseren

data

20

Agenda




• Conclusies

21

Inrichten SPM aan klant zijde

Scope bepaling

Documentatie scan + bepalen UoM

Bepalen performance metrieken

Administratieve implementatie

Organisatorische implementatie

22

Scope bepaling SPM

• Welke domeinen?

• Welke applicaties?

• Welke technologieën?

• Welke activiteiten? − Nieuwbouw

− Adaptief onderhoud

− Correctief onderhoud

• Welke meetmomenten? − Voor handover aan leverancier: reality check

− Voor handover aan klant: performance measurement

• Projectactiviteiten in en uit scope

23

Documentatie scan en UoM

• Documentatie scan − Kwaliteit en meetbaarheid documentatie

− Welke UoM is geschikt

− Moet documentatie worden aangepast om meetbaarheid te vergroten?

• UoM in contracten: − Objectief, herhaalbaar, verifieerbaar

− Maat voor functionaliteit

− Functiepunten, tenzij niet mogelijk n.a.v. documentatie

scan

24

Performance metrieken (voorbeelden)

• Productiviteit: − Project Delivery Rate (Uur/UoM)

− Productivity Index (PI)

− FP per manmaand

• Kwaliteit: − Defects/UoM totaal

− Defects/UoM opgeleverd aan klant (A-test + productie)

− %Defects opgeleverd aan klant

• Snelheid (Time to market) − UoM per kalendermaand

− Schedule conformance

25

Administratieve inrichting

• Standaarden − Work breakdown structure

− Uren- en defectadministratie

• Procesbeschrijving

• Procedures

• Templates

• Database

• Management rapportages

26

Organisatorische inrichting

• Nieuw organisatie onderdeel of rol: metrics desk

• Management commitment

• Proces eigenaarschap

• Training

• Awareness sessies

• Communicatie

27

Proces op hoofdlijnen

Klant

-Feasibility study

-Requirements -analysis

-Requirements -design

-Global functional -design

SOW based on

UoM and

historical data

Performance

measurement

Leverancier

-Detailed -functional design

-Technical design

-Coding + -programmer test

-Systems test

-Delivery to klant

Klant

-System integration -test

-User acceptance -test

-Implementation

28

Start project

Klant –

project voorbereiding

SOW aanvraag

Requirements analyse

Requirements design

Functioneel ontwerp

Leverancier –

SOW voorbereiding

UoM meting

Begroting

Uren, doorlooptijd,

kosten, defects

SOW

Klant –

SOW acceptatie

UoM meting verificatie

Uren, doorlooptijd,

kosten, defects

verificatie

SOW acceptatie

29

Voorbeeld verificatie

B&T Effort (MHR) vs Effective FP

10 100 1.000 10.000

Effective FP

0,1

1

10

100

1.000

B&

T E

ffort (M

HR

) (thousands)

Current Solution Logged Solutions Historical Projects QSM Business Av g. Line Sty le 1 Sigma Line Sty le Project: Project X

Niet realistisch?

30

Na afloop project

Leverancier –

SOW update

UoM meting definitief

Data collectie

Uren, doorlooptijd,

kosten, defects

Performance

Measurement rapport

Klant –

SOW acceptatie

UoM meting verificatie

Uren, doorlooptijd,

kosten, defects

verificatie

Performance

Measurement rapport

acceptatie

31

Benchmark project: intern en extern

• Evaluatie project lerende organisatie! C&T Duration (Months) vs Effective FP

100 200 300 400 500 600 700 800 900 1.000

Effective FP

0,1

1

10

100

C&

T D

ura

tion

(Mo

nth

s)

Project XProject X

Projects being Assessed Special Project QSM Business Avg. Line Sty le 1 Sigma Line Sty le 2 Sigma Line Sty le

32

Benchmark project: intern en extern

C&T Effort (MHR) vs Effective FP

100 200 300 400 500 600 700 800 900 1.000

Effective FP

0,1

1

10

100

1.000

C&

T E

ffort (M

HR

) (tho

us

an

ds

)

Project XProject X


33

Benchmark: intern en extern

Errors (SysInt-Del) vs Effective FP

100 200 300 400 500 600 700 800 900 1.000

Effective FP

10

100

1.000

Erro

rs (S

ys

Int-D

el)

Project XProject X


34

Management rapportages

• Trends in performance

0,4

0,6

0,8

1,0

1,2

1,4

1,6

1,8

2,0

2011Q1 2011Q2 2011Q3 2011Q4 2012Q1

Effic

ienc

y In

dex

Supplier X Efficiency lndex

Supplier X efficiency index Target (baseline +50%)

Baseline Efficiency Lower bound (baseline -40%)

0,4

0,6

0,8

1,0

1,2

1,4

1,6

1,8

2,0

2011Q1 2011Q2 2011Q3 2011Q4 2012Q1

Prod

ucti

vity

Ind

ex

Supplier X Productivity lndex

Supplier X Productivity Index Target (baseline +50%)

Baseline Productiviteit Lower bound (baseline -40%)

0,4

0,6

0,8

1,0

1,2

1,4

1,6

1,8

2,0

2011Q1 2011Q2 2011Q3 2011Q4 2012Q1

Co

st In

de

x

Supplier X Cost lndex

Supplier X Cost index Higher bound(baseline +50%)

Baseline kosten niveau Target (baseline -50%)

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

2011Q1 2011Q2 2011Q3 2011Q4 2012Q1

Qu

alit

y In

de

x

Supplier X Quality Index

Quality index Supplier X Target (baseline +50%)

Baseline Quality Lower bound (baseline -40%)

35

Agenda




• Conclusies

36

Conclusies

• Inrichten SPM is niet eenvoudig en kan alleen bij voldoende volwassenheid

• Meten productiviteit(sverbetering) vergt inspanning van zowel leverancier als klant

• Keuze leverancier gaat verder dan kijken naar prijs en/of totale productiviteit

• Inrichten SPM is omvangrijke operatie die een behoorlijke inspanning en doorlooptijd vergt

37

Supplier Performance

Measurement

Uitbesteden met controle,

houd grip op de prestaties van

de leverancier