INTEGRATING AN OUTSOURCING PARTNER. Ziggo Application Development

INTEGRATING AN OUTSOURCING PARTNER Ziggo Application Development

Auteur Versie Datum

I. Vinkenborg 2.0 31-05-2013

Titel Versie Datum

Integrating an outsourcing partner 2.0 31-05-2013

Auteur Studentnummer Klas

I. Vinkenborg 500611212 4BIM1

Onderwijsinstelling Opleiding Afstudeerperiode Docent begeleider Tweede lezer

Hogeschool van Amsterdam – Hogeschool voor Economische Studies Business, IT & Management 2012 – 2013, semester 2 R.K. van der Meer C.M.J. Hopmans

Opdrachtgever Afdeling Bedrijfsbegeleider

Ziggo BV Application Development JD. Rundervoort

Integrating an outsourcing partner

2/55

VERSIEBEHEER Versie

Datum

Toelichting

2.0

31-05-2013

Laatste feedback en wijzigingen verwerkt

1.3

27-05-2013

Feedback verwerkt

1.2

23-05-2013

Feedback R.K. van der Meer en C.M.J. Hopmans verwerkt

1.1

21-05-2013

Feedback P. Follon verwerkt

1.0

17-05-2013

Feedback JD. Rundervoort verwerkt

0.3

03-05-2013

Feedback JD. Rundervoort verwerkt

0.2

18-04-2013

Feedback JD. Rundervoort en R.K. van der Meer verwerkt

0.1

27-03-2013

Eerste versie opgesteld

Distributiebeheer Persoon

Organisatie

Datum

Toelichting

JD. Rundervoort

Ziggo

31-05-2013

Eindrapport, versie 2.0 toegestuurd

C.M.J. Hopmans

HvA-HES

31-05-2013


R.K. van der Meer

HvA-HES

31-05-2013


C.M.J. Hopmans

HvA-HES

17-05-2013

80% versie toegestuurd

R.K. van der Meer

HvA-HES

17-05-2013

80% versie toegestuurd

JD. Rundervoort

Ziggo

15-05-2013

Voor inhoudelijke feedback v0.3 toegestuurd

P. Follon

Ziggo

15-05-2013


JD. Rundervoort

Ziggo

24-04-2013


R.K. van der Meer

HvA-HES

12-04-2013


R.K. van der Meer

HvA-HES

02-04-2013

Deeldocument huidige situatie toegestuurd

JD. Rundervoort

Ziggo

08-04-2013

Deeldocument huidige situatie toegestuurd


3/55

Managementsamenvatting Ziggo wil zijn klanten het grootst mogelijke gemak en plezier laten ervaren op het gebied van informatie, communicatie en entertainment in een continu veranderende wereld. De visie voor 2016 houdt in dat Ziggo de concurrentie aangaat met beleving en gemak in plaats van infrastructuur en bandbreedte. Dit houdt in dat de marktintroducties elkaar snel opvolgen. Om de snellere marktintroducties te realiseren is Ziggo Application Development een samenwerking aangegaan met Tech Mahindra, een Indiase partij, om de rol als System Integrator op zich te nemen. Een System Integrator heeft als functie om geprogrammeerde applicaties en IT-systemen met elkaar te integreren en daarbij de impact te minimaliseren zodat het geheel als één samenwerkt. Ziggo is op twee manieren de uitbesteding aangegaan. Als eerste om extra capaciteit en expertise van mobiele diensten in/bij te kunnen schakelen. Ten tweede om toegang te verkrijgen tot vergaande technologische innovatie. Scope De marktintroducties bestaan voornamelijk uit IT-innovaties en wordt binnen Ziggo Application Development in projectvorm uitgevoerd. Binnen projecten wordt onderscheid gemaakt tussen twee soorten producten; beheer- en ontwikkelproducten. Beheerproducten geven vorm aan het beheerproces van een project, bijvoorbeeld een Project Brief. Ontwikkelproducten zijn de daadwerkelijke opleveringen, bijvoorbeeld een Global, Functional of Technical Design. De leverende organisatie Tech Mahindra heeft de rol als System Integrator nog niet geheel op zich genomen. Dit heeft als resultaat dat er tijdens de uitvoer onverwachte dingen gebeuren. Ziggo heeft daarbij zichzelf, onbewust, terughoudend opgesteld. Dit komt voort uit het feit dat Tech Mahindra hun eerste sourcingspartner is. De scope van de afstudeeropdracht is de alignment van het vastgestelde voortbrengingsmodel en de daarbij behorende in- en uitgangseisen van de project ontwikkelproducten tussen Ziggo en Tech Mahindra. Buiten scope van de afstudeeropdracht is de verdere uitwerking/ontwikkeling/implementatie van het voortbrengingsmodel, de organisatie en definitie om tot project ontwikkelproducten te komen. Daarnaast ook de aansluiting van andere partijen of leveranciers op het voortbrengingsmodel. Aanpak Om antwoord te geven op het gestelde doel is de volgende hoofdvraag opgesteld. ‘Op welke punten van het standaard voortbrengingsmodel van Tech Mahindra zijn aanpassingen nodig om een integraal onderdeel te worden van het vastgestelde voortbrengingsmodel van Ziggo?’ Vanuit de hoofdvraag zijn vier deelvragen geformuleerd met elk een aanpak om tot bovenstaand resultaat te komen. Om antwoord te geven op deze vragen zijn inhoudelijke interviews afgenomen met de stakeholders (in Nederland en India), bestaande documentatie opgehaald en bestudeerd, literatuuronderzoek uitgevoerd en bevindingen afgestemd. Resultaten Zowel Ziggo als Tech Mahindra is er van overtuigd dat beide dezelfde, positieve, insteek hebben om de samenwerking te laten slagen. Om dit te bewerkstelligen zijn aanpassingen noodzakelijk, stilstand is immers achteruitgang.


4/55

De benodigde aanpassingen in het voortbrengingsmodel zijn uiteenlopend. Ten eerste is verregaande uitwerking en afstemming van het voortbrengingsmodel nodig op het gebied van de gebruikte templates, procesgang en in- en uitgangseisen per ontwikkelproduct. Vervolgens zijn er geconstateerde extra stappen nodig voor de implementatie van de uniforme werkwijze. Ten slotte speelt de managementaansturing, rapportage en regie met betrekking tot de samenwerking een cruciale rol. De vraag en aanbod afstemming heeft daarin een grote factor. Voor de verregaande uitwerking en afstemming van het voortbrengingsmodel is het van belang dat het voortbrengingsmodel wordt herzien en het ontwerpen testgedeelte op hetzelfde detailniveau is uitgewerkt. De overeenstemming met Tech Mahindra wordt gewaarborgd door middel van een SharePoint-portal waar relevante processchema’s, templates, projectgerelateerde high-level reports en handleidingen zijn te vinden. Er zijn een aantal extra stappen nodig voor de implementatie. Naast de relevante documenten beschikbaar hebben, moet de communicatie binnen Ziggo en Tech Mahindra top-down plaatsvinden. Binnen Ziggo is dat nodig om de uniforme werkwijze over de individuen zeker te stellen. Binnen Tech Mahindra is dat nodig vanwege de culturele verschillen omdat de Indische medewerkers erg gevoelig zijn voor autoriteit en hiërarchie. Daarnaast verschilt de aanpak van lopende en nieuwe projecten. Voor de lange termijn geldt een aantal aanbevelingen op het gebied van managementaansturing, rapportage en samenwerking. Het regie-referentiemodel wordt gebruikt om de volwassenheid naar het volgende niveau te brengen. De rapportage van het QA-dashboard wordt uitgebreid met de activiteiten in het testgedeelte. Voor de samenwerking loopt het Partnership 2.0 verbetertraject. De doelstellingen hiervan adresseren alle benodigde aanpassingen in de samenwerking. De mensen in dat verbetertraject moeten bereidt blijven verantwoordelijkheid te nemen en de inspanning te leveren.


5/55

Voorwoord Het was een spannende periode. Een periode waarin het lastig was om de scope beperkt te houden, grensoverschrijdend te communiceren en externe medewerkers aan te sturen om zelf verder te komen. Desalniettemin heb ik mijzelf op meerdere vlakken zien groeien. Onder andere op communicatief, samenwerkend en cultureel gebied heb ik grote sprongen gemaakt. Daarnaast heeft de procesmatige aanpak en bedrijfsvoering mij een breder perspectief gegeven van ondersteunende- en bedrijfsprocessen. Voor een uitgebreide reflectie verwijs ik u naar het reflectieverslag dat is opgenomen in de bijlage. Het onderzoek is tot stand gekomen dankzij de innovatieontwikkelingen en internationale samenwerking van Ziggo. Een grote steun tijdens het onderzoek is JanDirk Rundervoort geweest waarvoor mijn dank groot is. De geboden vrijheid heeft mij geholpen om net een stapje extra te zetten. Daarnaast wil ik Patrick Follon bedanken voor zijn kritische feedback en verhelderende gesprekken die nieuwe perspectieven hebben geboden. Ruben van der Meer en Corry Hopmans wil ik bedanken voor de kritische feedback, begeleiding en sturing gedurende de gehele afstudeerperiode. Ten slotte wil ik de medewerkers van Ziggo, Tech Mahindra en SPNP Consultants bedanken voor hun inzet en samenwerking om tot de gestelde doelen te komen. Als auteur van dit rapport wens ik u veel plezier gedurende het lezen.


6/55

Inhoudsopgave 1

Inleiding ........................................................................................................................................... 9

2

Algemene informatie ..................................................................................................................... 10

3

4

5

6

7

8

2.1

Ziggo .................................................................................................................................. 10

2.2

Aansluiting opleidingsprofiel ............................................................................................. 10

Probleemstelling............................................................................................................................ 11 3.1

Beschrijving........................................................................................................................ 11

3.2

Doel.................................................................................................................................... 11

3.3

Probleembeschrijving ........................................................................................................ 12

3.4

Stakeholders ...................................................................................................................... 12

3.5

Onderzoeksdoelstelling ..................................................................................................... 13

3.6

In scope.............................................................................................................................. 13

3.7

Out of scope ...................................................................................................................... 14

3.8

Randvoorwaarden ............................................................................................................. 14

3.9

Aannames .......................................................................................................................... 14

3.10

Hoofd- en deelvragen ........................................................................................................ 14

Interne organisatie ........................................................................................................................ 15 4.1

Ziggo .................................................................................................................................. 15

4.2

Tech Mahindra................................................................................................................... 19

4.3

Best-practices en visie ....................................................................................................... 20

Voortbrengingsmodellen............................................................................................................... 22 5.1

Ziggo .................................................................................................................................. 22

5.2

Tech Mahindra................................................................................................................... 25

5.3

Confrontatie ...................................................................................................................... 28

Uitwisseling van project ontwikkelproducten ............................................................................... 30 6.1

Ontwikkelproducten .......................................................................................................... 30

6.2

Communicatie, uitwisseling, controle en acceptatie ........................................................ 31

6.3

Gebruikte systemen .......................................................................................................... 32

Gewenste in- en uitgangseisen van project ontwikkelproducten ................................................. 34 7.1

In- en uitgangseisen Ziggo ................................................................................................. 34

7.2

In- en uitgangseisen Tech Mahindra ................................................................................. 38

7.3

Confrontatie ...................................................................................................................... 38

Veranderingen voor een overeengekomen werkwijze ................................................................. 40 8.1

COPAFIJTH ......................................................................................................................... 40


7/55

9

Conclusie ....................................................................................................................................... 43

10 Aanbevelingen ............................................................................................................................... 46 10.1

Vastleggen ......................................................................................................................... 46

10.2

Implementeren .................................................................................................................. 47

10.3

Lange termijn..................................................................................................................... 47

11 Begrippenlijst................................................................................................................................. 49 12 Bijlagen .......................................................................................................................................... 51 12.1

Figuren ............................................................................................................................... 51

12.2

Tabellen ............................................................................................................................. 53

12.3

Documenten ...................................................................................................................... 54

13 Bronnenlijst ................................................................................................................................... 55


8/55

1 INLEIDING Voor u ligt het resultaat van het onderzoek dat plaats heeft gevonden bij Ziggo BV. Het onderzoek is opgezet in samenwerking met Ziggo en docenten van de Hogeschool van Amsterdam. Daarbij is vooraf een centrale hoofdvraag en probleemstelling gedefinieerd. Het onderwerp van het onderzoek betrekt het realisatieproces om van idee of concept tot geaccepteerd eindproduct te komen. Daarbij wordt ingegaan op de outsourcingsrelatie tussen Ziggo en Tech Mahindra. Het rapport geeft een antwoord op de volgende hoofdvraag: ‘Op welke punten van het standaard voortbrengingsmodel van Tech Mahindra zijn aanpassingen nodig om een integraal onderdeel te worden van het vastgestelde voortbrengingsmodel van Ziggo?’ Het antwoord op de hoofdvraag is opgebouwd uit de antwoorden van vier deelvragen en de daar bijhorende aanpak. Deze inleiding biedt een leeswijzer voor de rest van dit rapport. Hoofdstuk twee begint met algemene informatie over Ziggo en de aansluiting van de probleemstelling op de studie Business, IT & Management. Hoofdstuk drie vervolgt met de probleemstelling zelf, de onderzoeksdoelstelling, scope en hoofd- en deelvragen. In hoofdstuk vier wordt er ingegaan op de interne organisaties van Ziggo en Tech Mahindra. In de hoofdstukken vijf tot en met acht worden de gedefinieerde deelvragen onderzocht en beantwoord waarna er in hoofdstuk negen een opsomming en conclusie volgt die antwoord geeft op de hoofdvraag. De daadwerkelijke aanbevelingen en vervolgstappen komen in hoofdstuk tien aan bod. In een aantal paragrafen van deze hoofdstukken is vanuit de ‘ik-vorm’ geschreven om de boodschap te onderscheiden en kracht bij te zetten. De hoofdstukken elf tot en met dertien bevatten respectievelijk de begrippenlijst, bijlagen en bronnenlijst.


9/55

2 ALGEMENE INFORMATIE 2.1

ZIGGO

Ziggo wil zijn klanten het grootst mogelijke gemak en plezier laten ervaren op het gebied van informatie, communicatie en entertainment in een continu veranderende wereld. Ziggo is een landelijke aanbieder van mediaen communicatiediensten. Producten en diensten voor de klein- en grootzakelijke markt betreffen zaken als telefonie, datacommunicatie en elektronische betalingsmogelijkheden. Ziggo bedient circa 3 miljoen huishoudens, 1,8 miljoen breedband internetklanten, 2,2 miljoen afnemers van digitale televisie en 1,4 miljoen telefonieabonnees. De onderneming is eigenaar van een next-generation-netwerk waarmee het mogelijk is om de bandbreedte te leveren voor alle toekomstige diensten die thans worden verwacht. Het verzorgingsgebied - met sterke regionale bases - strekt zich uit over 56% van Nederland, waarvan 98% bestaat uit glasvezel infrastructuur. De visie voor 2016 houdt in dat Ziggo de concurrentie aangaat met beleving en gemak in plaats van infrastructuur en bandbreedte. Met de focus op media en entertainment heeft Ziggo Europa’s meest geavanceerde entertainmenthal, de Ziggo Dome. Met regelmaat geven internationale artiesten daar een spectaculair optreden.

2.2

AANSLUITING OPLEIDINGSPROFIEL

De afstudeeropdracht sluit aan bij het opleidingsprofiel van Business, IT & Management. De afstudeeropdracht heeft betrekking op de volgende gedefinieerde beroepstaken. Analyseren en vormgeven van Business Processen Het vastgestelde voortbrengingsmodel voor IT-oplossingen en ingericht proces dient met diverse partijen op elkaar afgestemd worden. Managen van een ICT-project De afstudeeropdracht een (kleinschalig) ICT-project binnen een grotere projectorganisatie. Na afloop van de afstudeeropdracht zal de student door middel van een portfolio aantonen dat de, door de Hogeschool van Amsterdam, vastgestelde competenties zijn voltooid. De volgende competenties zullen aangetoond worden: Vakkundigheid (basis) Resultaatgerichtheid (basis) Communiceren (basis) Ontwikkelingsgerichtheid (basis) Besluitvaardigheid Innovatief vermogen Samenwerken Interculturele sensitiviteit De volgende competenties zijn tijdens een eerdere stageperiode afgerond op HBO-niveau: Klantgerichtheid Ondernemend gedrag


10/55

3 PROBLEEMSTELLING 3.1

BESCHRIJVING

Binnen Ziggo Application Development (AD) worden diverse projecten gelijktijdig uitgevoerd. De projecten nemen verschillende varianten aan, bijvoorbeeld interne verbetertrajecten of externe (innovatieve)ontwikkelingsprojecten. Binnen projecten wordt onderscheid gemaakt tussen twee soorten producten; beheer- en ontwikkelproducten. Beheerproducten geven vorm aan het beheerproces van een project, bijvoorbeeld een Project Brief. Ontwikkelproducten zijn de daadwerkelijke opleveringen, bijvoorbeeld een Global, Functional of Technical Design. Binnen Ziggo wordt elk project op een andere manier gedefinieerd, uitgevoerd en aangestuurd. Er bestaat dus geen consistentie tussen bovenstaande documenten en output als projecten met elkaar worden vergeleken. De projecten worden uitgevoerd aan de hand van een voortbrengingsmodel. Dit is een model dat het proces omvat om van idee/concept tot eindproduct te komen. Het voortbrengingsmodel van Ziggo AD is onlangs in een verbetertraject vernieuwd en goedgekeurd door het management team (MT). Dit vastgestelde voortbrengingsmodel dient als uitgangspunt voor de afstudeeropdracht. De directie van Ziggo heeft zich volledig ingezet om innovatieve diensten en producten op de markt te brengen. Om dit te realiseren is het Zumba-programma gestart waarmee er een compleet nieuw applicatielandschap wordt ontworpen. Dit applicatielandschap zal naast de oudere legacy-systemen functioneren. De ontwikkelproducten die gedurende de projecten worden gerealiseerd worden onder andere gedocumenteerd in de tool CaseWise Corporate Modeler. Dit dient als leidraad om één overzicht te creëren waar welke applicatie voor dient, hoe deze werkt, welke bronnen er worden geraadpleegd, wie verantwoordelijk is, en om impactanalyses mogelijk te maken. De bestaande applicatiestructuur wordt in de nabije toekomst in CaseWise Corporate Modeler gezet. Om Ziggo AD bij te staan met applicatieontwikkeling is Tech Mahindra, een Indiase partij, gecontracteerd om de rol als System Integrator op zich te nemen. Een System Integrator heeft als functie om geprogrammeerde applicaties en IT-systemen met elkaar te integreren en daarbij de impact te minimaliseren zodat het geheel als één samenwerkt. Daarnaast heeft een System Integrator een leidende functie ten opzichte van derde partijen en interne Ziggo afdelingen. Het door Ziggo AD ontworpen voortbrengingsmodel is tijdens de contracterende fase door Tech Mahindra opgenomen als het model waaraan zij zich zullen aanpassen. Tech Mahindra heeft deze rol tot op heden nog niet geheel op zich genomen en fungeert als doorsnee leverancier waarbij zij gevraagde bedrijfsapplicaties ontwikkelen. De rol die Tech Mahindra speelt is op sommige punten van het voortbrengingsmodel niet duidelijk, waardoor er onverwachte dingen gebeuren. Daarnaast gebruikt Tech Mahindra niet altijd de toegereikte handvatten. Ziggo heeft daarbij zichzelf, onbewust, terughoudend opgesteld dat voortkomt uit het feit dat Tech Mahindra hun eerste sourcingspartner is. Het leeuwendeel met betrekking tot de gewenste verandering in de samenwerking wordt afgevangen door een lopend verbetertraject Partnership 2.0 waarin de relatie tussen Ziggo en Tech Mahindra centraal staat en gewerkt wordt aan een duurzaam partnership. Het Partnership 2.0 programma heeft zes streams (figuur 1). De afstudeeropdracht ligt in de Processes and Quality Assurance stream en richt zich op procesoptimalisatie en alignment binnen de partnership.

3.2

DOEL

De afstudeeropdracht is onderdeel van een groter doel om een snellere doorlooptijd van projecten te bewerkstelligen en daardoor de time-to-market te verkorten. Het doel is om Tech Mahindra een integraal onderdeel te


11/55

laten zijn van het vastgestelde voortbrengingsmodel van Ziggo; de project ontwikkelproducten zijn daardoor onafhankelijk van de realiserende partij.

3.3

PROBLEEMBESCHRIJVING

Op dit moment is Tech Mahindra geen System Integrator. Tech Mahindra neemt geen leidende rol terwijl dit wel gewenst is. In de huidige situatie is er geen uniforme werkwijze tussen de twee partijen en dit leidt onder andere tot onverwachte producten, miscommunicatie en irritatie. Het duurt onder andere hierdoor onnodig lang om projecten op te starten en af te ronden. De input van Tech Mahindra is daarbij niet zoals gewenst. Het vastgestelde voortbrengingsmodel is uitgewerkt op papier en bevindt zich momenteel, binnen Ziggo, in de implementatiefase. De verwachting is dat de (interne) implementatie medio juni afgerond zal zijn. Bij de samenstelling van het voortbrengingsmodel heeft Tech Mahindra input geleverd en hebben zij geaccordeerd dit model te volgen. Aangezien Tech Mahindra een eigen voortbrengingsmodel volgt zal dit aangepast moeten worden aan de Ziggo standaard. Tech Mahindra kan hierin een voorbeeldrol vervullen voor Ziggo.

3.4

STAKEHOLDERS

De afstudeeropdracht heeft te maken met een impact op stakeholders. Stakeholders zijn als volgt gedefinieerd: Stakeholders zijn groepen of individuen die invloed uit kunnen oefenen op, of gevolgen kunnen ondervinden van beslissingen, strategiekeuzen, doelstellingen en resultaten van de organisatie. Stakeholders kunnen verschilleni de vormen aannemen waaronder aandeelhouders, klanten, leveranciers en personeelsleden. Met betrekking tot de afstudeeropdracht zijn de volgende stakeholders geïdentificeerd. Stakeholder

Omschrijving

1.

Arnoud Klerx

Eindverantwoordelijke alle applicatieontwikkeling binnen Ziggo

2.

Jan-Dirk Rundervoort

Probleemeigenaar en opdrachtgever

3.

Tech Mahindra

-

-

-

-

4.

Architecten Designers Developers Testers

-

-


Chris White o (Eind)verantwoordelijke alle Tech Mahindra werkzaamheden binnen Ziggo Dunja van Pelt o Interim QA-manager en verantwoordelijk voor de procesinrichting binnen Tech Mahindra Ali Asger Rampurawala o Programmanager; verantwoordelijk voor goed verloop van projecten en aansluiting van off-shore activiteiten Anand Satavalekar o Contractuele verplichtingen Ravi Shingote o Lead Architect; werkt aan verschillende projecten en maakt deel uit van de workshops omtrent het vastgestelde voortbrengingsmodel Jeroen Schuuring o Externe architectuur expert CaseWise en ontwikkelproces ontwerper Remko Delsman o Externe CaseWise expert en ontwikkelproces ontwerper 12/55

-

-

Bas van den Berg o Externe CaseWise expert en opsteller QA-dashboard Harro Philip o Externe test manager; inhoudelijk verantwoordelijk voor procesverbetering in het Ziggo brede test/acceptatie proces Patrick Follon o Externe project manager; inhoudelijk verantwoordelijk voor procesverbetering in samenwerking met Tech Mahindra

5.

Victoria Hoogenveen

Performance management, controlling en contractuele verplichtingen

6.

Erik Bouwes Bavinck

Externe programma manager; inhoudelijk verantwoordelijk voor het optimaliseren van de partnership tussen Ziggo en Tech Mahindra (het Partnership 2.0 programma)

7.

Rex van Oss

Procesmanager eigenaar QA dashboard en ontwikkelproces (voor optimalisatie)

Bovenstaande stakeholders zijn in onderstaande power/interest matrix gevisualiseerd.

ii

5 3 4 1

3.5

6

7

2

ONDERZOEKSDOELSTELLING

De onderzoeksdoelstelling luidt: Wat is nodig om de opleveringen van ontwikkelproducten door Tech Mahindra conform de vastgestelde Ziggo standaarden te laten verlopen. Het onderzoek is opgedeeld in verschillende subdoelen en draagt bij aan de overkoepelende doelstelling omschreven in de paragraaf Doel op pagina 11. De subdoelen zijn om aanbevelingen te bieden op het volledig vastleggen en implementeren van de uniforme werkwijze en deze werkwijze op de lange termijn te beheersen en te verbeteren.

3.6

IN SCOPE De alignment van het vastgestelde voortbrengingsmodel en in- en uitgangseisen project ontwikkelproducten tussen Ziggo en Tech Mahindra De belangen van de stakeholders als uitgangspunt nemen


13/55

De signaallijst reviewen op aansluiting project ontwikkelproducten De gestelde adviezen en keuzes onderbouwen met vakliteratuur

3.7

OUT OF SCOPE De verdere uitwerking/ontwikkeling/implementatie van het voortbrengingsmodel De organisatie/definitie om tot project ontwikkelproducten te komen o De focus ligt op de output van ontwikkelproducten in projecten Het onboardingsproces bij aanvang van een nieuw project De aansluiting van andere partijen/leveranciers op het voortbrengingsmodel

3.8

RANDVOORWAARDEN

De volgende randvoorwaarden worden gesteld bij aanvang van het onderzoek. De student heeft beschikking tot de nodige documentatie met betrekking tot de samenwerking De student wordt begeleid en ondersteund waar hij dat nodig acht De bedrijfs-/docent begeleider en stakeholders zijn gedurende het hele traject beschikbaar

3.9

AANNAMES

De volgende aannames doet de student bij aanvang van het onderzoek. Het gestelde doel om Tech Mahindra als System Integrator te laten fungeren met subdoelen wordt door beide partijen nagestreefd De architecten, designers, developers en testers van Ziggo en Tech Mahindra zijn op de hoogte van de implementatie van het vastgestelde voortbrengingsmodel Er bestaan omschreven communicatie- en escalatielijnen met Tech Mahindra

3.10 HOOFD- EN DEELVRAGEN Om antwoord te geven op het gestelde doel is er een hoofdvraag opgesteld en zijn daar vier deelvragen van afgeleid. De hoofdvraag luidt als volgt: ‘Op welke punten van het standaard voortbrengingsmodel van Tech Mahindra zijn aanpassingen nodig om een integraal onderdeel te worden van het vastgestelde voortbrengingsmodel van Ziggo?’ De afgeleide deelvragen luiden: 1.

2. 3. 4.

Wat is de uitgangssituatie met betrekking tot het voortbrengingsmodel en in- en uitgangseisen? a. Voor Ziggo b. Voor Tech Mahindra Hoe verloopt de huidige uitwisseling van ontwikkelproducten in projecten? Wat zijn van het vastgestelde voortbrengingsmodel de gewenste in- en uitgangseisen van project ontwikkelproducten? Welke veranderingen zijn nodig om tot een overeengekomen werkwijze te komen en welke consequenties brengen die met zich mee?


14/55

4 INTERNE ORGANISATIE In dit hoofdstuk worden beide organisaties beschreven aan de hand van verkregen informatie van de stakeholders en interne kennisbanken. De informatie biedt een breder perspectief op de organisaties en daarnaast een kijkje achter de schermen.

4.1

ZIGGO iii

Om Ziggo’s interne organisatie te analyseren wordt het 7S-model van McKinsey gebruikt. Het 7S-model is geschikt om een duidelijk beeld van de organisatie te krijgen. Dit heeft als doel om een beeld van de organisatie te schetsen die is benaderd vanuit verschillende invalshoeken. Met het model wordt enkel ingegaan op de aspecten met betrekking tot de samenwerking tussen Ziggo AD en Tech Mahindra. Het 7S-model kent ‘harde’ en ‘zachte’ factoren. De harde factoren – structure, strategy en systems – zijn organisatorisch vastgelegd, terwijl de zachte factoren – shared values, style, staff en skills – aan verandering onderhevig zijn. Het model is toepasbaar op Ziggo vanwege het verschil tussen de vaste en variabele onderdelen van een organisatie. Ziggo is op dit moment erg in beweging, onder andere vanwege de marktcondities en interne innovaties, terwijl de structuur en interne waarden behouden blijven. Hieronder is het 7S-model weergegeven.

Structure Een vaste structuur is in de operationele afdelingen van Ziggo niet van toepassing. Alles gebeurt telkens op een andere manier. Dit zorgt soms voor veel verwarring, miscommunicaties en onverwachte gebeurtenissen, zowel in de interne organisatie als in de samenwerking met Tech Mahindra. De implementatie van één uniforme werkwijze is onlangs in gang gezet om het partnership met Tech Mahindra naar een hoger niveau te brengen. De organisatie bestaat uit verschillende (management)lagen variërend van de directieboard tot aan de operatiiv onele functies. De interne organisatie is een matrixorganisatie. De medewerkers staan hiërarchisch onder een lijnmanager maar werken voor verschillende projecten. Binnen Ziggo heerst een open cultuur, taakverdeling en coördinatie die ervoor zorgt dat iedereen erg los en flexibel met elkaar omgaat. Er wordt grotendeels met flexplekken gewerkt, elke dag zit je met andere mensen aan tafel. Daarnaast wordt ‘het nieuwe werken’ vanuit huis ook gestimuleerd. De communicatie verloopt voor het overgrote deel via e-mail en telefoon. Daarnaast wordt er veel vergaderd om op democratische wijze tot besluiten te komen. De organisatie van Ziggo wordt in onderstaande organigrammen weergegeven.


15/55

De omcirkelde AD Sourcing afdeling houdt zich binnen Ziggo AD bezig met de aansturing van externe/sourcing partners. Strategy Ziggo AD is verantwoordelijk voor de interne applicatieontwikkeling. Daarbinnen is AD Sourcing verantwoordelijk voor het inrichten van een structuur binnen Ziggo waarin Tech Mahindra maximaal effectief is/kan zijn. De partnership met Tech Mahindra wordt op dit moment niet volledig benut. Mede daarom is het Partnership 2.0 programma opgestart om onder andere de werkwijze en verwachtingen op elkaar af te stemmen. De afspraken die gemaakt worden binnen dat programma hebben invloed op de verantwoordelijkheid en risicodragerschap van de samenwerking. Op dit moment wordt die werkwijze geïmplementeerd binnen de Ziggo organisatie. Tech Mahindra sluit zich hier langzaamaan op aan. Een subdoel van het Partnership 2.0 programma is het implementeren van een ‘Factory model’. In het ‘Factory model’ wordt er vanuit een project input gegeven aan Tech Mahindra waarna de ontwikkeling in een ‘zwart gat’ gebeurt en het product er als gemaakt product uitkomt. De vervolgstap na de ‘Factory’ is om Tech MahinIntegrating an outsourcing partner

16/55

dra in te zetten als de ‘System Integrator’ rol. De ‘System Integrator’ rol bevat een meer leidinggevende en adviserende rol. Systems Binnen Ziggo wordt het applicatielandschap drastisch hervormd en vereenvoudigd. Dit houdt in dat de samenhang en architectuur van bestaande applicaties in kaart wordt gebracht (waar deze nog niet aanwezig was). Deze architectuur wordt bijgehouden in Casewise Corporate Modeler. Met dit softwarepakket kunnen onderlinge afhankelijkheden, samenhang en impact op verschillende manieren opgebouwd en weergegeven worden. De basis van een aantal legacy-systemen worden in de komende periode ook opgenomen in Casewise Corporate Modeler. Dit hangt vaak samen met een lopend project die raakvlak heeft met het legacy-systeem. Als er binnen een project een nieuw systeem wordt opgezet gebeurt dat direct in Casewise Corporate Modeler. Dit wordt afgedwongen door de geïntroduceerde templates. Controle op het opgeleverde werk wordt in de toekomst door een Quality Assurance (QA) dashboard ingevuld. Dit QA-dashboard is ingericht met verschillende ‘Quality Gates’, die controleren of de documenten in orde zijn voordat ze naar de volgende fase kunnen. Er worden onder andere checks uitgevoerd op de taal (Engels), aanwezigheid en versienummer. Naast Casewise wordt JIRA gebruikt als projectmanagementtool waarin de verschillende projectstappen en projetstadia gedefinieerd zijn die momenteel al gevolgd worden. Daarnaast wordt ChangePoint gebruikt voor de administratieve invulling. Voor bestandsuitwisseling wordt SharePoint ingezet. Tech Mahindra heeft op dit moment beperkte toegang tot deze interne Ziggo systemen. Er zijn VPN-accounts uitgegeven, deze worden echter binnen het Indiase netwerk van Tech Mahindra geblokkeerd. De Tech Mahindra medewerkers in India gebruiken ten behoeve van de connectiviteit met Ziggo een externe verbinding (in de vorm van een UMTS-dongle of mobiele telefoon). De systemen die in CaseWise Corporate Modeler worden opgenomen zijn uit verschillende lagen opgebouwd. De lagen vallen over elkaar heen en hebben elk andere functies en interfaces. De structuur per applicatie is in onderstaande afbeelding weergegeven.

Applicatie Module Functie

Service

Functie

Service

Service

Module Functie

Service

Service

Het huidige applicatielandschap van Ziggo is in de bijlage toegevoegd. Style De manier van leidinggeven is erg los. Er zijn gestelde doelen, waar (na optionele discussie) overeenstemming over wordt gesloten. De Ziggo medewerkers (zowel intern als extern) worden vrijgelaten onder de voorwaarde dat hij/zij de toegewezen taken volbrengt. De sturing vindt plaats op output en realisatie.


17/55

In het verleden ging dit anders. Kritische besluiten namen veel tijd in beslag en kwamen veel discussies bij kijken. De verandering in deze aanpak heeft ook te maken met het verkorten van de time-to-market. Het huidige leiderschap maakt het mogelijk om sneller tot besluiten te komen, deze tot uitvoer te brengen en waar nodig gedurende het proces bij te sturen. Er wordt nu meer sturing en richting gegeven vanuit hogere managementlagen. De eerste vruchten van deze aanpassing zijn nu merkbaar. Productopleveringen volgen elkaar sneller op en met het vernieuwde voortbrengingsmodel wordt de manier van werken uniform. Er worden binnen Ziggo veel werkzaamheden parallel uitgevoerd, dit gebeurt voornamelijk in projectvorm. De projectteams bestaan uit diverse disciplines afkomstig uit de relevante bedrijfstakken. De overige processen worden uitgevoerd door HR, KA en ondersteunende afdelingen. Iedereen werkt intensief en afdelingsoverschrijdend samen, dit is één van de kenmerken van een matrixorganisatie. Dit gebeurt ook met de Indiase medewerkers van Tech Mahindra. Waarnodig wordt dit telefonisch gedaan als de medewerker bijvoorbeeld in India is. Staff Op de afdeling Application Development heeft iedere medewerker zijn of haar eigen specialiteit. Daarnaast heeft elke medewerker een adequate opleiding en relevante werkervaring. De medewerkers van Tech Mahindra (werkzaam in Nederland) zijn voornamelijk projectmedewerkers en een aantal leden van het Customer Facing Team. De arbeidsmarkt zit momenteel in een dal vanwege de economische teruggang. Bij Ziggo is daar weinig van te merken. Het personeelsbestand groeit sneller dan het aantal bureaus. Om bijvoorbeeld de werking van het QAdashboard en de procesimplementatie te waarborgen worden er geschikte personen geworven. Binnen het Partnership 2.0 programma zijn diverse professionals aan het werk. De programmamanager heeft veel kennis en ervaring met outsourcingvraagstukken. Skills De meest belangrijkste eigenschap binnen Ziggo is het kunnen omgaan met een veranderde omgeving. Dit houdt ook in dat de medewerkers om moeten kunnen gaan met het afstaan van bepaalde taken, bijvoorbeeld aan Tech Mahindra. Het Partnership 2.0 programma heeft dit ingevuld met concrete stappen. Daarnaast zou er meer regie gevoerd moeten worden in het samenwerkingsverband. Met betrekking tot de werking met Casewise Corporate Modeler en de nieuwe templates zullen de betrokken medewerkers (zowel van Ziggo als Tech Mahindra) een training volgen in het gebruik daarvan. Daarnaast zullen de projectmedewerkers getraind en begeleid worden in hun eerste gebruik van een template. Shared Values Zowel Ziggo als Tech Mahindra willen de time-to-market voor Ziggo producten verkorten. Door middel van het Partnership 2.0 is de goede weg ingeslagen. Zo zijn er afspraken gemaakt waarbij Tech Mahindra meer invloed en zeggenschap krijgt in het voortbrengingsmodel en daarbij ook meer risico draagt. Tot dusver staan de gemaakte afspraken enkel op papier. Geschat wordt dat het komende kwartaal deze afspraken invulling krijgen door de juiste persoon op de juiste plek te positioneren. Daar worden nu de voorbereidingen voor getroffen. De culturele verschillen tussen beide partijen zijn een aandachtspunt. Alhoewel Tech Mahindra veel ervaring heeft met Westerse partners komen er toch cultuurverschillen voor. Deze verschillen komen voor op het operationele niveau. Op een hoger managementniveau is weinig te merken van het verschil in culturele afkomst. Integrating an outsourcing partner

18/55

De betrokken personen zijn ervaren/gewend aan het werken met verschillende culturele achtergronden. Met v betrekking tot het culturele aspect heeft AT Kearney voor Ziggo een onderzoek uitgevoerd. Uit dit onderzoek blijkt dat er binnen Ziggo een grotere focus ligt op de medewerkers en binnen Tech Mahindra de focus ligt op de klant en efficiëntie. In onderstaande afbeelding worden de cultuur van Ziggo met die van Tech Mahindra vergeleken.

Ziggo is op twee manieren de uitbesteding aangegaan: 1. 2.

Extra capaciteit en expertise van mobiele diensten in/bij te kunnen schakelen Toegang te verkrijgen tot vergaande technologische innovatie

Aan de ene kant is dat slecht voor de contractrelatie omdat er met de applicatie uitbesteding een ‘u vraagt, wij draaien’ wordt gevoerd. In tegenstelling tot deze relatie worden er van Tech Mahindra wel innovatieve ideeën vi verwacht die zich niet tot één project beperken.

U vraagt, wij draaien

Innovatieve ideeën en concepten

In een ideale situatie zouden beide vormen in balans moeten zijn. De leverancier zou verantwoordelijkheid nemen voor de keten en denkt mee over de applicatie portfoliosamenstelling. De innovaties zouden daarbij voorgesteld worden door de leverancier in de rol van ‘System Integrator’.

4.2

TECH MAHINDRA

Tech Mahindra is een Indiase organisatie die zich specialiseert op het gebied van applicatieontwikkeling. Zij richten zich volledig op de telecommarkt. Tech Mahindra opereert internationaal en hebben bij elke klant een aantal medewerkers gestationeerd. Het hoofdkantoor is gevestigd te Pune, India. De meeste Tech Mahindra medewerkers, werkzaam voor het Ziggo-account, zijn gestationeerd in India (70% van het totaal). De overige 30% Tech Mahindra medewerkers zijn bij Ziggo in Utrecht gestationeerd. Deze laatste groep bestaat uit projectmedewerkers (met name architecten en designers) en het Customer Facing Team die de overkoepelende communicatie en relatie onderhouden met Ziggo. Een doelstelling op de lange termijn is om de Nederland – India verhouding terug te brengen naar 20-80%.


19/55

In onderstaande organigram is de indeling vanuit Tech Mahindra weergegeven voor de betrokkenen van het Ziggo AD account.

4.3

BEST-PRACTICES EN VISIE

Gedurende de RFI- en RFP-fasen ruim anderhalf jaar geleden zijn er door Tech Mahindra presentaties gegeven met daarin ervaringen en best-practices op de interne/externe omgeving en de te sluiten partnership. Hieronder staan een aantal belangrijke punten die daarbij naar voren zijn gekomen: Tech Mahindra heeft meer dan 25 jaar ervaring met mobiele telefoonoperators o Wereldwijd ervaring met meer dan 110 telefoonoperators Tech Mahindra heeft 375 processcenario’s direct beschikbaar voor een mobiele propositie o Daarvan zijn 75 processcenario’s nodig voor een initiële lancering o De processen zijn direct bruikbaar en te implementeren in bijvoorbeeld TIBCO o Tech Mahindra beheert van de 20 grootste telefoonoperators de gehele infrastructuur Ruime ondersteuning van legacy-systemen Ervaring met mobiele- en glasvezelnetwerken en de uitrol daarvan Grote terugvalbasis van best-practices en standaarden Uit de interviews met de stakeholders van Ziggo en Tech Mahindra komen de volgende ervaringen naar voren: Veel voorgaande klanten en organisaties van de stakeholders waren meer volwassen o Er bestond al procesdocumentatie, templates en uniformiteit over de werkwijze o Er was een duidelijke visie en leiderschap o Vereiste managementfuncties, -lagen en -niveaus waren aanwezig, gedocumenteerd en toegankelijk De verwachtingen waren beter op elkaar afgestemd o Bij Ziggo wordt een deel van het voortbrengingsmodel uitbesteed, Tech Mahindra heeft vaker meegemaakt dat het gehele voortbrengingsmodel werd uitbesteed o Tech Mahindra is gewend om instructies te ontvangen, vanuit Ziggo wordt verwacht dat Tech Mahindra zelf de initiatieven neemt Ziggo laat de ‘oude’ manier van werken niet los o Ziggo wilt geen verantwoording en leiding afstaan aan Tech Mahindra Integrating an outsourcing partner

20/55

o

Binnen Ziggo worden beslissingen snel genomen, deze worden echter achteraf ter discussie gesteld Alle stakeholders zijn het er over eens dat het Partnership 2.0 programma een duidelijke stap is in de goede richting


21/55

5 VOORTBRENGINGSMODELLEN In dit hoofdstuk wordt per organisatie wordt een antwoord op gegeven op de eerste deelvraag. ‘Wat is de uitgangssituatie (zowel vanuit Ziggo als Tech Mahindra) met betrekking tot het voortbrengingsmodel en in- en uitgangseisen?’ Om een applicatie te ontwikkelen kunnen verschillende methoden gebruikt worden. Om achter de gebruikte methode te komen van zowel Ziggo als Tech Mahindra zijn de betreffende stakeholders geïnterviewd. De stakeholders hebben kijk en invloed op de gebruikte processen. Om de informatie te verzamelen is er veel gecommuniceerd met de Indiase partij, meestal telefonisch. Daarnaast werden er in de Partnership 2.0 overleggen belangrijke onderwerpen besproken die van toepassing zijn op deze deelvraag. Een voortbrengingsmodel omvat alle organisatorische aansturing die nodig is om van een idee of concept tot een eindproduct te komen. Een onderdeel daarvan is onderstaande afbeelding waarbij van links naar rechts het idee of concept wordt uitgewerkt, ontwikkeld en getest. In de rest van het rapport wordt onderscheid gemaakt tussen en verwezen naar het linker – ontwerpgedeelte en het rechter – testgedeelte.

5.1

ZIGGO

Tot voor aanvang van het afstudeertraject was er binnen Ziggo geen uniform voortbrengingsmodel. Inmiddels is dit voortbrengingsmodel door middel van externe consultants tot stand gekomen en goedgekeurd door het Ziggo AD MT. De externe partij heeft om tot dit voortbrengingsmodel te komen interviews afgenomen en workshops gehouden met de betreffende personen en afdelingen. Tech Mahindra heeft ook op dit punt input geleverd. Kort na aanvang van het afstudeertraject is dit vernieuwde voortbrengingsmodel door het Ziggo AD MT bij alle medewerkers van de afdeling AD geïntroduceerd als ‘de nieuwe manier van werken’. Het vernieuwde model wordt als uitgangspunt genomen voor het afstudeertraject. Naast het voortbrengingsmodel zijn er ook verschillende ondersteunende templates in gebruik genomen en wordt er parallel gewerkt aan het in kaart brengen van het huidige applicatielandschap. De structuur van het applicatielandschap is aan verandering onderhevig vanwege de innovaties binnen Ziggo. Tijdens de uitvoer van projecten worden binnen Ziggo en Tech Mahindra twee soort documenten/producten opgeleverd. Er bestaat een projectmodel en een applicatie voortbrengingsmodel. 5.1.1 PROJECTMODEL Het projectmodel is organisatiebreed geïmplementeerd binnen Ziggo. Het model bestaat uit de onderdelen pre-project en project. Binnen elk onderdeel zijn er verschillende beheerfasen en het is gebaseerd op PRINvii CE2. De daarvan bekende project beheerproducten worden binnen Ziggo gehanteerd voor de verschillende fasen.


22/55

De project beheerdocumenten zijn onder andere het Planning Request, Mandate, Project Brief en Project Initiation Document. Deze documenten worden binnen Ziggo beheerd in de interne projectmanagement tool JIRA. In JIRA staat elk project (TCB) met een uniek nummer, de status, stakeholders, raakvlakken met andere projecten, beheerdocumenten en onderliggende onderdelen (ITC). Onderstaande afbeelding geeft het project beheerproces weer.

In onderstaande tabel zijn de beheerfasen en –documenten per projectonderdeel gedefinieerd. Onderdeel

Beheerfasen

Beheerdocumenten

Pre-project

Request planning Haalbaarheidanalyse Mandaat fase

Project Request Mandaat

Project

Plan fase PID fase

Project brief Project Initiation Document

5.1.2 APPLICATIE VOORTBRENGINGSMODEL Binnen het projectmodel gebruikt Ziggo AD het vastgestelde voortbrengingsmodel om applicaties te ontwikkelen. Daarbinnen staan ontwikkelproducten centraal. De project ontwikkelproducten zijn daadwerkelijke deliverables van projecten. Deze ontwikkelproducten worden gemaakt in opdracht van een project (TCB). Dit kan bijvoorbeeld een functioneel ontwerp of een (deel)oplevering van een applicatie zijn. Dit voortbrengingsmodel van Ziggo is als document bijgevoegd. De volgende constateringen zijn er op het vastgestelde voortbrengingsmodel: Het diagram geeft enkel een beeld weer van de afdeling Ziggo AD Enkel het ontwerpgedeelte van het voortbrengingsmode is procesmatig in kaart gebracht De gebruikte termen voor fasen komen niet overeen met het projectmodel Het diagram biedt een overzicht van de (informatie)stroom De verschillende rollen zijn duidelijk onderscheiden Het model is onafhankelijk; er is geen directe koppeling met Tech Mahindra of een andere (externe) partij Technische ontwerpen worden niet gemaakt, hier zijn binnen Ziggo AD geen formele afspraken over o Het document staat echter bij de Test fase wel in het voortbrengingsmodel Bepaalde onderdelen zijn niet gedefinieerd o Zo wordt er bij de PID fase gesproken over ‘grote’, ‘middel’ en ‘kleine’ projecten, de criteria waaraan dat wordt afgewogen is niet aanwezig Bepaalde termen (zoals Rough Order of Magnitude, R.O.M.) worden niet toegelicht Integrating an outsourcing partner

23/55

o

Voor een nieuwkomer of zonder vakinhoudelijke kennis kan het lastig zijn om te achterhalen wat daarmee wordt bedoeld

5.1.3 WERKWIJZE Ter verduidelijking van de stappen is hieronder het vastgestelde voortbrengingsmodel weergegeven. Het model is vervolgens met het projectmodel van Ziggo in een confrontatiematrix weergegeven. Dit dient om te verduidelijken in welke beheerfase er een project ontwikkelproduct wordt opgeleverd. In de rechter driehoek worden de afhankelijkheden per fase weergegeven.

V-model/ Projectmodel

Pre-project

PR Requirements RIA

FA

Project

Mandate

Brief

Verantwoordelijke partij

PID

Design

Bouw

Test

X

Ziggo X

IA

Ziggo Ziggo (steeds meer Tech Mahindra**)

X

Global Design

X

Ziggo (steeds meer Tech Mahindra**)

Functional Design

X


Technical Design*

X

Tech Mahindra

Build

X

Tech Mahindra

Unit Test

X

Tech Mahindra

System Test

X

Tech Mahindra

System Integration Test

X


Acceptance Test

X

Ziggo


24/55

* Technical Designs worden (bijna) niet gemaakt. ** Met de deelname aan het Partnership 2.0 programma neemt Tech Mahindra een steeds prominentere rol in het voortbrengingsmodel. Binnen projecten hoeven beheerdocumenten niet gelijktijdig opgeleverd te worden met de project ontwikkelproducten. Zo kan het voorkomen dat er Global of Functional Designs worden gemaakt terwijl het projectmandaat nog niet is goedgekeurd. Deze asynchrone manier van werken is niet zoals het hoort (onder andere volgens PRINCE2), dit zal in een later stadium worden gestandaardiseerd. In de templates van het RIA/IA/Global Design en Functional Design (opgenomen als document in de bijlage) staan de exacte criteria waaraan deze project ontwikkelproducten moeten voldoen. De twee ingevulde templates worden vervolgens ingevuld op een SharePoint-portal gepubliceerd. Zodra de bestanden daar op staan worden er (in de toekomst) een aantal checks op uitgevoerd. Hier volgt een rapportage uit die door het management gebruikt wordt om de voortgang te bewaken. De twee templates zijn als bijlage bijgevoegd. De Quality Assurance (QA) manager is verantwoordelijk voor het voortbrengingsmodel en de processen daaromtrent. Momenteel is de werving voor een nieuwe QA-manager die deze rol op zich neemt in volle gang. De procesmanager zal zorg dragen voor de juiste (continue) werking en implementatie van het voortbrengingsmodel. De QA-manager, procesmanager en de Service Provider Managers (SPM) rapporteren aan de Application Sourcing manager. Vanuit het Ziggo MT wordt er gestreefd naar een werkwijze gebaseerd op het eTOM framework. Dit framework biedt organisaties in de telecommunicatie handvatten waarmee zij hun interne organisatie en (ondersteunende) processen kunnen inrichten. De handvatten kunnen organisatiebreed ingevoerd worden. Tech Mahindra is ook voorstander van het eTOM framework. Onderstaande afbeelding geeft het framework weer.

5.2

TECH MAHINDRA

Een van de eerste taken in het afstudeertraject is het achterhalen van het voortbrengingsmodel van Tech Mahindra (van toepassing op Ziggo) en de verantwoordelijke daarvan. Om achter het voortbrengingsmodel te komen zijn er interviews afgenomen met de stakeholders. Het contact met de stakeholders was lastig op te Integrating an outsourcing partner

25/55

bouwen en de verkregen informatie bleek niet altijd overeen te komen. De verkregen informatie heeft uiteindelijk een goed beeld gegeven van de geschiedenis, werking, cultuur en hiërarchie binnen Tech Mahindra. Daarnaast zijn specifieke rollen en verantwoordelijkheden voor het Ziggo account naar voren gekomen. 5.2.1 QUALITY MANAGEMENT GROUP De afdeling Quality Management Group (QMG) is binnen Tech Mahindra het orgaan dat alle best-practices, (eTOM) frameworks, processen, interne (kwaliteit)standaarden en audits beheert. De afdeling fungeert als een kennisbank om in specifieke situaties bepaalde methoden op te vragen die bewezen effectief zijn bij andere klanten van Tech Mahindra. De meeste documenten die zij beheren zijn intellectueel eigendom van Tech Mahindra. De QMG wordt als volgt omschreven: ‘A full time ‘Quality Management Group’ to address systemic issues across functional boundaries.’ De QMG beheert een framework genaamd MASTER. Het MASTER framework is een verzameling processen, best-practices, richtlijnen, methoden, standaarden, checklists en templates. Dit framework wordt organisatiebreed toegepast. Afgeleid van het MASTER bestaat er een Business Management System (BMS) welke is gebaseerd op de Plan-Do-Check-Act (PDCA) cirkel. Het BMS ondersteunt diverse methoden in de uitvoering, zoals de watervalmethode of Agile. Daarnaast biedt het BMS technieken om projectopleveringen te plannen, monitoren en te volgen. De verantwoordelijke binnen de QMG voor het Ziggo account zijn Madhuri Kenjale en Pallavi Tamhane. Zij hebben toegang tot en invloed op de gebruikte processen binnen Tech Mahindra. Naast de QMG leden zijn Aliasger Rampurawala en Dunja van Pelt betrokken bij de dagelijkse aansturing, kwaliteitseisen en oplevering van ontwikkelproducten. Zij kunnen een rol spelen in het aanpassen van hun werkzaamheden en integreren van Ziggo’s voortbrengingsmodel binnen Tech Mahindra. De QMG fungeert naast kennisbank ook als verantwoordelijke voor het uitvoeren van interne audits op diverse aspecten en niveaus. De interne audits worden eens per kwartaal uitgevoerd. Van deze audits is weinig bekend, onduidelijk is wat de criteria zijn, of er al een audit is uitgevoerd en op welke onderdelen. 5.2.2 PROJECTMODEL Projecten worden binnen Tech Mahindra volgens onderstaand proces uigevoerd. Daarbij wordt onderscheid gemaakt tussen lopende projecten, waarbij een transitie fase nodig kan zijn, en een nieuw te starten project. Het is onbekend of dit is gebaseerd op een PRINCE2 (of vergelijkbare) projectmethode. Gezien de omvang van de organisatie en betrokken afdelingen (de QMG) is dit wel aannemelijk.

Het voortbrengingsmodel begint in ‘Project Monitor & Control’. 5.2.3 APPLICATIE VOORTBRENGINGSMODEL Binnen het projectmodel is het voortbrengingsmodel van Tech Mahindra opgebouwd uit drie factoren: Integrating an outsourcing partner

26/55

1.

2.

3.

Tech Mahindra gebruikt een ‘standaard’ voortbrengingsmodel, het MASTER-proces. Dit proces wordt gebruikt bij klanten die helemaal geen processen of werkstructuur hebben. Daarnaast kan dit een baseline bieden, waarbij klantspecifieke aanpassingen gemaakt kunnen worden. Het MASTER-proces staat voor: o (Tech) Mahindra’s o Analysis o Solution o Transition o Execution o Relationship De eigen ervaring van de Tech Mahindra medewerkers. De persoonlijke ervaring wordt gebruikt om input te geven bij het vormgeven van het proces. o Tijdens de workshops om tot Ziggo’s voortbrengingsmodel en templates te komen is er bruikbare input geleverd vanuit de Tech Mahindra medewerkers. De derde factor is het proces van de klant (indien aanwezig). Elk bedrijf werkt volgens bepaalde standaarden, manieren of procedures (dit kan ook ongedocumenteerd zoals voorheen bij Ziggo). Dit proces kan door Tech Mahindra worden gebruikt om het toegepaste voortbrengingsmodel aan te passen.

Vanuit het MASTER is een aantal processen van toepassing op Ziggo. De standaardwerking van Tech Mahindra in India om project ontwikkelproducten (binnen Tech Mahindra componenten genoemd) op te leveren gaat volgens onderstaand proces. De ontwikkelproducten worden aan de hand van de watervalmethode geproduceerd, weergegeven in onderstaand proces.

De rol van Tech Mahindra, van toepassing op Ziggo, begint vanaf Design. Momenteel worden er nog geen System Test en Acceptance Test uitgevoerd. Daarnaast zijn ze ook (nog) niet betrokken bij het definiëren van requirements. Tijdens de Analyse fase (RIA & IA) worden ze langzaamaan betrokken om hun visie daarin mee te nemen. De volgende constateringen zijn er op het voortbrengingsmodel van Tech Mahindra: Het model is in basis opgesteld en visueel weergegeven De substappen zijn niet duidelijk gespecificeerd o Zo is er niet uit op te maken waar het functioneel en/of technisch ontwerp terugkomen Beide kanten van het voortbrengingsmodel zijn weergegeven Er is geen rekening gehouden met een tijdsaspect Geen duidelijkheid over enige aanpasbaarheid voor klantspecifieke situaties Het procesmodel, documenten, templates en checklists worden vanwege het intellectuele eigendom niet makkelijk gedeeld De verschillende rollen zijn niet beschreven o Tech Mahindra werkt met componenten teams, die komen niet in het model terug o Verschillende afdelingen kunnen er niet uit worden opgemaakt Integrating an outsourcing partner

27/55

De processen voor Agile ontwikkeling, Commercial Of The Shelf (COTS) softwarepakketselectie en Tech Mahindra in de SI-rol zijn in de bijlage als figuur 2, 3 en 4 opgenomen. 5.2.4 WERKWIJZE Ter verduidelijking van de stappen, en om dezelfde (eerdere) standaard aan te houden, is hieronder het voortbrengingsmodel weergegeven en deze is vervolgens met het projectmodel van Tech Mahindra in een confrontatiematrix weergegeven. V-model\Tech Mahindra

Design

Functional Design

X

Ziggo (steeds meer Tech Mahindra)

Technical Design

X

Tech Mahindra

Build

Coding

System Test


X

Unit Test System Test System Integration Test

5.3

Unit Test

Verantwoordelijke partij

Tech Mahindra X

Tech Mahindra X

Tech Mahindra X

Ziggo (steeds meer Tech Mahindra)

CONFRONTATIE

Wanneer ik de huidige situatie van Tech Mahindra met die van Ziggo vergelijk komt naar voren dat de visie op de samenwerking grotendeels hetzelfde is. Daar komt bij kijken dat het verwachtingspatroon niet op elkaar is afgestemd wat blijkt uit de interviews met de stakeholders. Vanuit Ziggo is de verwachting dat Tech Mahindra meer leiding op zich neemt en vanuit Tech Mahindra is de ervaring dat Ziggo de ‘eigen’ werkzaamheden niet graag loslaat of wilt overdragen. Ik heb geconstateerd dat het vastgestelde voortbrengingsmodel met templates binnen Ziggo en Tech Mahindra maar mondjesmaat wordt gecommuniceerd. Vanuit verschillende kanten komen signalen met betrekking tot de invulling en betrokkenheid tijdens de creatie van het voortbrengingsmodel en de templates. Ik vind de werkwijze van beide partijen (op papier) goed op elkaar aansluiten. Beide maken ze gebruik van een projectmodel met een daarin opgenomen voortbrengingsmodel. Bij Ziggo is binnen het projectmodel gekozen voor de PRINCE2 methodiek, aannemelijk geldt dit ook voor Tech Mahindra. Het voortbrengingsmodel van Tech Mahindra vind ik visueel erg basaal uitgewerkt. De verschillende substappen zijn bijvoorbeeld niet zichtbaar. Daarnaast zijn de System Test en System Integration Test in volgorde omgedraaid. Het projecten voortbrengingsmodel is beschermd door intellectueel eigendom. Ik denk dat dit een belemmerde factor is voor de communicatie, uitwisseling en eventuele aanpassingen in de werkwijze. Het voortbrengingsmodel van Ziggo sluit op sommige punten niet aan op het projectmodel, de gebruikte termen van fasen komen niet overeen. Het detailniveau van het applicatie voortbrengingsmodel is daarentegen dieper dan dat van Tech Mahindra. Het eigenaarschap van het applicatie voortbrengingsmodel is bij Tech Mahindra beter ingericht. Dit is mede dankzij de QMG. Het eigenaarschap moet bij Ziggo nog vormgegeven worden. Ik neem aan dat dit te maken Integrating an outsourcing partner

28/55

heeft met de volwassenheidsgraad van de interne organisatie. Tech Mahindra heeft op dit gebied meer ervaring en hoger niveau bereikt dan Ziggo op het gebied van proces ontwikkeling/borging. Op een aantal punten zou ik de voortbrengingsmodellen aanpassen: De gebruikte termen van het Ziggo projecten voortbrengingsmodel zou ik op elkaar laten aansluiten De Technical Design verwijzing in het Ziggo voortbrengingsmodel zou ik verwijderen De volgorde van de System Test en System Integration Test tussen Ziggo en Tech Mahindra zou ik op elkaar laten aansluiten De afstemming tussen het ontwerpen testgedeelte van het voortbrengingsmodel van Ziggo zou ik verder uitwerken


29/55

6 UITWISSELING VAN PROJECT ONTWIKKELPRODUCTEN In dit hoofdstuk wordt antwoord gegeven op de tweede deelvraag: ‘Hoe verloopt de huidige uitwisseling van project ontwikkelproducten?’ Tijdens de uitvoer van projecten worden binnen Ziggo en Tech Mahindra twee soort documenten/producten opgeleverd. Er bestaan project beheerdocumenten en project ontwikkelproducten. In dit hoofdstuk wordt omschreven welke project ontwikkelproducten worden opgeleverd, hoe de communicatie, uitwisseling, controle en acceptatie daarvan verloopt en welke systemen daarvoor gebruikt worden.

6.1

ONTWIKKELPRODUCTEN

De requirements is het eerste ontwikkelproduct dat wordt opgeleverd. Deze geven aan welke vraag er wordt gesteld vanuit de bedrijfsvoering en zijn in het stadium om gestandaardiseerd te worden. Onderdeel

Beschrijving

Requirements

Meetbare business en functionele requirements Waar het uiteindelijke ontwikkelproduct aan wordt getoetst

Het daaropvolgende ontwikkelproduct is het RIA/IA/Global Design (beschikbaar als een template). Het RIA/IA/Global Design, door project geïnitieerd, is altijd gekoppeld aan een TCB en bevat onder andere: Onderdeel

Beschrijving

RIA

-

-

Snelle analyse o Welke applicaties worden er geraakt en waarom Hoe de integratie is met andere applicaties o Zoveel mogelijk informatie uit CaseWise Corporate Modeler, om dat als leidende bron te laten fungeren Rough Order of Magnitude (R.O.M.) o Grove schatting qua kosten, doorlooptijd, omvang en impact

IA

-

Indien er te weinig interne informatie beschikbaar is wordt er een uitgebreidere analyse uitgevoerd o Dit kan door middel van contact met leveranciers voor demo’s, etc

Global Design

-

Biedt input voor het Functional Design Geeft de interactie aan tussen de vereiste functionele componenten

De oplevering van het RIA/IA/Global Design is het startpunt voor de Functional Design fase. De eventueel bestaande Functional Designs worden daarbij als uitgangspunt genomen om aan de requirements te voldoen. Het is vaak het geval dat er meerdere Functional Designs nodig zijn voor een requirement. Daarnaast zijn er specifieke teams die gespecialiseerd zijn in bepaalde Functional Designs. Een Functional Design (beschikbaar als template) heeft de volgende eigenschappen: Onderdeel

Beschrijving


30/55

Functional Design

-

Het is een levend document o Het geeft de lifecycle weer van een applicatie(functie) Een nieuwe functie begint met een leeg document Bevat de in- en output schema’s, beheerinformatie en voldoet aan requirements Bij nieuwe projecten worden bestaande ontwerpen aangepast Dit kan gebruikt worden voor een toekomstige (R)IA, bijvoorbeeld voor een nieuw project

Functional Designs worden vaak voorzien van sequentie diagrammen. Hiermee wordt echter een ‘happy flow’ laten zien omdat er geen/weinig beslismomenten in voorkomen. In de vastgestelde templates zijn daarom flowchart diagrammen opgenomen om probleem te voorkomen. Een Functional Design gaat vervolgens naar een developer (van Ziggo, TechM of een andere partij). Die genereert vervolgens de functionele wens en de bijhorende technische documentatie. De technische documentatie is niet hetzelfde als het Technical Design. Er wordt binnen Ziggo weinig tot geen gebruik gemaakt van Technical Designs. Als Technical Designs worden gebruikt, zijn ze willekeurig vastgelegd. Dit kan als bijlage van het Functional Design of in een separaat Word document. Tijdens de daadwerkelijke realisatie van de Functional Designs verdwijnen de documenten in een zogenoemde ‘blackbox’ en komen er, samen met de technische documentatie, als eindproducten uit. De werking daarvan is goed, mits de requirements op orde zijn (o.a. beschreven met meetbare- en acceptatiecriteria). Om dit te waarborgen worden er basisprincipes opgesteld die gelden voor elk functioneel ontwerp, dit is nu nog niet aanwezig. De technische documentatie die wordt opgeleverd worden binnen Ziggo niet centraal beheert. Er zijn hiervoor geen processen of systemen voor ingericht. Elk project heeft zijn eigen initiatieven/eilandjes om deze documenten op te slaan.

Requirements

RIA, IA & Global Design

Functional Design

Realisatie & Oplevering

• Meetbaar • Acceptatie criteria • Basisprincipes

• RIA • IA • Global Design • Referenties naar Functional Designs

•Levend document (lifecycle) •Begint als leegdocument •Bestaande ontwerpen worden aangepast •Technical Design(optioneel)

• Blackbox • Technische documentatie

6.2

COMMUNICATIE , UITWISSELING, CONTROLE EN ACCEPTATIE

Tijdens de uitwisseling van project ontwikkelproducten verloopt de communicatie informeel en de invulling daarvan verschilt per project. De voornaamste communicatiemiddelen zijn e-mail of telefoon. Met bepaalde contactpersonen in India is een videoverbinding mogelijk wat de non-verbale communicatie ten goede komt. De communicatie met betrekking tot de uitwisseling verloopt zowel intern (tussen afdelingen/personen binnen Ziggo) als met externe partners (Tech Mahindra) niet altijd even soepel. Doordat een deel van deze communicatie met Tech Mahindra via India verloopt, loopt dat regelmatig vertraging op en is er kans op uiteenlopende Integrating an outsourcing partner

31/55

antwoorden. Binnen Ziggo is te merken dat de medewerkers zich vasthouden aan ‘hun’ manier van werken waardoor scope, voorwaarden en requirements van projecten regelmatig wijzigen. Daarnaast zijn zij het fysieke contact gewend dat lastig op te bouwen is via een digitale verbinding. Dit kost, in de meeste gevallen, meer tijd dan gepland. Omdat Ziggo in een transitie fase zit om de nieuwe manier van werken te implementeren en accepteren wordt er (nog) niet streng gewezen op de manier van communicatie en hoe deze overeenkomt met de richtlijnen. De achterliggende reden daarvan om dit niet te forceren is dat dit weerstand kan geven bij het implementatieproces van het vastgestelde voortbrengingsmodel. Tech Mahindra richt zich tot nu toe op grote omvangrijke applicaties. Dit is in lijn met een lopend programma om het interne applicatielandschap te vernieuwen/veranderen. Zodra Tech Mahindra een oplevering doet van een ontwikkelproduct gaat dat gepaard met de (technische) documentatie, testinformatie en testcases van de System Test. De ontwikkelproducten worden door Tech Mahindra tot en met de System Test opgeleverd. Het Generic Test Plan (te vinden als document in de bijlage) biedt een framework waarin onder andere de Quality Gates in zijn omschreven die tijdens het testen doorlopen worden. Dit framework is enkel tekstueel beschreven. Zodra Tech Mahindra een ontwikkelproduct gereed heeft tot en met de System Test wordt deze, inclusief alle testinformatie en testcases, opgeleverd. Bij de overdracht van een ontwikkelproduct dient alle documentatie beschikbaar te zijn voor Ziggo. Vervolgens worden de ontwikkelproducten in een testomgeving gezet. De testomgeving wordt gefaciliteerd door Ziggo. De installatie van het ontwikkelproduct in de testomgeving wordt door Tech Mahindra uitgevoerd in het bijzijn van Ziggo’s beheerorganisatie om kennisoverdracht te waarborgen. De controle en acceptatie van het ontwikkelproduct gebeuren door testcases (die eerder in het proces zijn overgedragen aan Ziggo) te selecteren en deze door Tech Mahindra te laten demonstreren in de gefacilliteerde testomgeving. Dit geeft Ziggo de mogelijkheid om een keuze te maken uit de meest kwetsbare/cruciale testen, dit wordt ook wel witness-testing genoemd. Na het accepteren van het ontwikkelproduct tijdens de eerste Quality Gate (de System Test) volgt de tweede Quality Gate (de System Integration Test). Deze test vindt plaats om de samenwerking met de andere applicaties te controleren. De betrokken applicaties staan in dezelfde testomgeving, dit zijn dus geen productieapplicaties. Alle testdocumentatie en uitkomsten worden opgeslagen in JIRA. Geconstateerde afwijkingen worden in categorieën ingedeeld en kunnen ervoor zorgen dat het ontwikkelproduct terug gaat voor doorontwikkeling of worden meegenomen in de volgende (reguliere) business release. De keuze ervan is projectafhankelijk en hangt samen met de projectplanning vanuit de Planning Office. De verschillende afwijkingcategorieën zijn opgenomen in tabel 1 in de bijlage.

6.3

GEBRUIKTE SYSTEMEN

Om een uitwisseling van ontwikkelproducten mogelijk te maken wordt er gebruikt gemaakt van verschillende IT-systemen. In onderstaande tabel staan de gebruikte systemen met de geboden functionaliteiten. Systeem

Omschrijving en toepassing

SharePoint

SharePoint dient als documentbeheer tool. In SharePoint worden alle goedgekeurde documenten (zowel project beheerdocumenten als sommige project ontwikkelproducten) bijgehouden. Dit biedt één centrale ‘waarheid’ die leidend is. Op de bestanden worden in de toekomst controles uitgevoerd. Dit wordt gedaan met behulp van een QA-


32/55

dashboard die rapportages genereert over diverse kwaliteitscriteria (o.a. taal, versie, aanwezigheid). Zowel medewerkers van Ziggo als van Tech Mahindra gebruiken de SharePoint documentbeheer tool. JIRA

JIRA is de projectmanagement tool. In JIRA staan alle projecten (TCB’s) en onderliggende onderdelen daarvan (ITC’s). Van elk project worden er verschillende variabelen bijgehouden waaronder status, voortgang en betrokken medewerkers.

CaseWise Corporate Modeler

In dit softwarepakket wordt het applicatielandschap visueel weergegeven. Daarbij is het mogelijk om de onderlinge samenhang en afhankelijkheden weer te geven. Dit pakket werd voorheen niet tot amper gebruikt. Sinds kort wordt dit pakket vaker ingezet, vanaf het werken met het vastgestelde voortbrengingsmodel worden nieuwe applicaties daar ook in verwerkt. Daarnaast is ook begonnen om de bestaande applicatiearchitectuur in CaseWise Corporate Modeler te zetten.

ChangePoint

ChangePoint wordt gebruikt voor de urenregistratie. Elk project heeft meerdere projectmedewerkers die daar zijn of haar uren daar op moet schrijven. Dit wordt vervolgens gebruikt om de personeelskosten in kaart te brengen en rapportages te genereren.

Project netwerkmappen

Op het interne Ziggo netwerk worden per project een mappenstructuur aangemaakt die als opslag dient voor documenten, agenda’s, notulen, checklists, e.d. Deze eilandjes worden ongestructureerd opgezet.

Project testomgeving

Een door een project ingericht systeem om ontwikkelproducten te kunnen testen, dit kan ook samen met andere (bestaande) applicaties voor de System Integration Test.

In onderstaand figuur wordt de onderlinge samenhang van bovenstaande systemen weergegeven.


33/55

7 GEWENSTE IN- EN UITGANGSEISEN VAN PROJECT ONTWIKKELPRODUCTEN In dit hoofdstuk wordt antwoord gegeven op de derde deelvraag: ‘Wat zijn van het vastgestelde voortbrengingsmodel de gewenste in- en uitgangseisen van project ontwikkelproducten?’ De in- en uitgangseisen zijn vastgelegd in Quality Gates. Per fase in het voortbrengingsmodel is er een Quality Gate gedefinieerd die de eisen per ontwikkelproduct aangeeft. Tijdens het onderzoek zijn verschillende Quality Gates in kaart gebracht. Het antwoord op deze deelvraag wordt geformuleerd met de uitkomst van afgenomen interviews, procesdocumentatie en het procesontwerp en Quality Gates vorm te geven.

7.1

IN- EN UITGANGSEISEN ZIGGO

Met betrekking tot de Quality Gates in het voortbrengingsmodel van Ziggo wordt er onderscheid gemaakt tussen ontwerpen testgedeelte, de Quality Gates daarvan separaat zijn gedefinieerd en hebben nog geen onderlinge afhankelijkheden. In onderstaande afbeelding staat aangegeven waar de Quality Gates zich bevinden in het voortbrengingsmodel.

In het ontwerpgedeelte van het voortbrengingsmodel zijn per fase de volgende Quality Gates gedefinieerd (zie het document Quality Gate Criteria in de bijlage). Quality Gate

Fase

0

Requirements

1

RIA

Ingangseisen

-

Vereiste requirements: o Functioneel Template RIA/IA/GD beschikbaar in Design Reposority


Uitgangseisen

-

Specificatie volgens ISEB methode o Projectspecifiek:  Functioneel  Niet functioneel o Business (basisprincipes):  Generiek  Technisch

-

V1.0 van RIA geplaatst in Design Repository, inclusief: o Goedkeuring door stakeholders o CaseWise Corporate Modeler diagrammen o Opmerkingen voor de volgende

viii

34/55

fase 2

IA

-

-

3

Global Design

-

-

-

4

Functional Design

-

-

-

Goedgekeurd V1.0 van RIA beschikbaar in Design Repository Vereiste requirements: o Functioneel o Non-functioneel

-

V2.0 van RIA/IA geplaatst in Design Repository, inclusief: o Goedkeuring door stakeholders o CaseWise Corporate Modeler diagrammen o Opmerkingen voor de volgende fase

Alle requirements zijn uniek genummerd, compleet en SMART uitgewerkt volgens ISEB methode De requirements, RIA en IA zijn goedgekeurd door stakeholders (in het document) De Test Manager controleert of de requirements testbaar zijn

-

De Factory gaat akkoord met hun gedeelte van het Global Design V3.0 van RIA/IA/GD geplaatst in Design Repository, inclusief: o Goedkeuring door stakeholders o CaseWise Corporate Modeler diagrammen o Definitieve (vastgelegde) requirements als bijlage o Opmerkingen voor de volgende fase

Goedgekeurd V3.0 van RIA/IA/GD beschikbaar in Design Repository Template Functional Design beschikbaar in Design Repository Master Test Plan is gemaakt en goedgekeurd door de Test Manager

-

-

-

Functional Design is goedgekeurd door stakeholders (in het document) Goedgekeurd V1.0 van Functional Design geplaatst in Design Repository, inclusief: o Delen van het V3.0 RIA/IA/GD o Master Test Plan

In onderstaande afbeelding worden de requirement varianten weergegeven.

ix

De Quality Gates van het ontwerpgedeelte waren op het moment van onderzoek nog in ontwikkeling. Bovenstaande eisen zijn afkomstig van de laatste verbeteriteratie. De beschikbare eisen waren in eerste instantie Integrating an outsourcing partner

35/55

enkel op documentniveau (onder andere op aanwezigheid, taal en goedkeuring). Dit onderzoek heeft bijgedragen aan de doorontwikkeling van de Quality Gates. Zie tabel 2 in de bijlage. In het testgedeelte van het voortbrengingsmodel zijn per fase de volgende Quality Gates gedefinieerd (zie het document Generic Program Test Plan in de bijlage). Quality Gate

Onderdeel

Ingangseisen

Uitgangseisen

0

System Test

-

De testomgeving is beschikbaar Er zijn geen Block afwijkingen Alle data en documenten zijn beschikbaar in de testomgeving Afwijking beheerproces is beschikbaar

-

Alle System Test criteria zijn succesvol afgerond De testomgeving is beschikbaar Er zijn geen Block afwijkingen Alle data en documenten zijn beschikbaar in de testomgeving Er is een lijst met geconstateerde afwijkingen

-

Alle System Intergration Test criteria zijn succesvol afgerond De testomgeving is beschikbaar Er zijn geen Block afwijkingen De goedgekeurde requirements, designs en test data en documenten zijn beschikbaar Er is een lijst met geconstateerde afwijkingen

-

Alle Acceptance Test criteria zijn succesvol afgerond De testomgeving is beschikbaar Er zijn geen Block afwijkingen Er is een lijst met geconstateerde afwijkingen

-

-

1


-

2

Acceptance Test

-

3

Preproduction Test

-

-

-

-

-

De System Test is voltooid volgens opgesteld plan Er zijn geen kritische afwijkingen geconstateerd De data migratie test is succesvol afgerond De interfaces tussen componenten werken De System Integration Test is voltooid volgens opgesteld plan Er zijn geen kritische afwijkingen geconstateerd De componenten zijn gecontroleerd met behulp van de technische documentatie Er is een regressie test set met data aangemaakt De Acceptance Test en Operational Service Test is voltooid volgens opgesteld plan Er zijn geen kritische afwijkingen geconstateerd De rapporten uit alle testfasen zijn gereviewed door de Test Coördinator

De Business Readiness Test en Service Acceptance Test is voltooid volgens opgesteld plan Er zijn geen kritische afwijkingen geconstateerd De rapporten uit alle testfasen zijn gereviewed door de Test Coördinator in samenwerking met de IT Service Management

In onderstaande afbeelding worden de Quality Gates van het testgedeelde weergegeven.


36/55

Acceptors; Business / Operations

Pre-production test

Acceptance test Quality Gate 2

HLD / GD

Integration test Quality Gate 1

LLD / FD

System test Quality Gate 0

TD Supplier; Ziggo Delivery, Tech Mahindra / Third parties

Unit test

Test Management in program's/ projects

Quality Gate 3

Requirements / Acceptance criteria

Development

7.1.1 RAPPORTAGE OP IN- EN UITGANGSEISEN De rapportage op de Quality Gates vindt plaats door middel van een Quality Assurance (QA) dashboard. Het QA-dashboard is een Excel bestand met koppelingen naar de gebruikte systemen. Vanuit JIRA wordt er een export in het QA-dashboard geladen. Vanuit SharePoint wordt een document statuslijst opgehaald. Er is een koppeling met BWise voor procesmanagement en in CaseWise Corporate Modeler wordt de aanwezigheid van de designs gecontroleerd. In het QA-dashboard kunnen de Quality Gates bewaakt worden. Er kan gefilterd worden op TCB’s, ITC’s en in welke fase van het bepaalde projecten (TCB’s/ITC’s) zich bevinden. In onderstaande afbeeldingen is het hoofdmenu van en een rapportage uit het QA-dashboard weergegeven.

De rapportage vanuit het QA-dashboard is vooralsnog niet gebonden aan consequenties als niet de juiste methoden/standaarden worden gevolgd. Dit heeft te maken met de implementatie van de nieuwe manier van werken en de te gebruiken templates waar het QA-dashboard over rapporteert. De QA-manager is de verantwoordelijke voor het QA-proces waar het dashboard onderdeel van is. Het doel van het QA-dashboard is om een governance proces in te richten. Er kunnen bijvoorbeeld audits mee uitgevoerd worden waarna het proces of gebruik kan worden bijgestuurd. Het QA-dashboard is momenteel zo ingericht dat enkel het ontwerpgedeelte van het voortbrengingsmodel wordt gecontroleerd en waarover word gerapporteerd.


37/55

7.2

IN- EN UITGANGSEISEN TECH MAHINDRA

In het voortbrengingsmodel van Tech Mahindra zijn per fase uitgebreide in- en uitgangseisen gedefinieerd (zie het document ZBS Operational Process in de bijlage). De volgende Quality Gates gedefinieerd: Onderdeel

Ingangseisen

Uitgangseisen

Project Planning

-

Een goedgekeurd Global Design (RIA/IA/Global Design) Een goedgekeurde ISOW

-

Goedgekeurd Project Plan, operationele processen en configuratieplan

Requirements Study & Analysis

-

Project Manager en team zijn gealloceerd

-

Een goedgekeurd Functional Design Requirements Matrix is opgesteld

Design & Test Planning

-

Een goedgekeurd Functional Design Requirements Matrix

-

Een goedgekeurd Technical Design, Impact Feasibility Study en System Test Plan

Coding and Unit Testing

-

Een goedgekeurd Technical Design en Impact Feasibility Study Gestandaardiseerde afspraken omtrent programmeercode en reviewtechniek

-

Gereviewde programmacode Doorgelopen Unit Test-cases Test en Defect logboek Een geüpdatet System Test Plan

Programmacode op Unit niveau getest Een goedgekeurd Functional en Technical Design De goedgekeurde System Test is beschikbaar

-

Test en defect logboek System Test resultaten zijn goedgekeurd Geteste programmacode en User Documents zijn vrijgegeven

-

-

Programmacode en User Documents zijn beschikbaar voor levering Project Plan is beschikbaar

-

Levering van programmacode en User Document zijn geleverd Ontvangstbewijs van de klant

Warranty and Support

-

Geïmplementeerd systeem Systeem is in productieomgeving User Documents zijn beschikbaar

-

Verloop van garantietermijn Project signed-off door de klant

Project Closure

-

Project Progress Report Feedback vanuit de klant Opleveringen zijn afgerond Alle facturen zijn in rekening gebracht

-

Signed-off Project Closure Report

-

System Testing

-

Package and Release

7.3

-

CONFRONTATIE

In het voortbrengingsmodel van Ziggo verschilt het ontwerpen testgedeelte omdat deze los van elkaar zijn ontworpen. Ik denk dat deze op elkaar afgestemd moeten worden om het als één geheel te laten functioneren en de afstemming te waarborgen. Ik ben erg positief over de Quality Gates die door Tech Mahindra gebruikt worden. Ze zijn compleet en per fase concreet toegelicht. Daarnaast zijn fasen zoals ‘Package and Release’, ‘Warranty and Support’ en ‘Project Closure’ opgenomen als Quality Gate, dit complementeert het hele proces. Ik denk dat, net zoals bij het voortbrengingsmodel, deze mate van detaillering komt doordat Tech Mahindra meer volwassen is en het eigenaar-


38/55

schap daarvoor is ingericht. Het is daardoor merkbaar dat Tech Mahindra op de processen en in- en uitgangseisen verbeterslagen heeft toegepast in de lifecycle. Als ik de gedefinieerde Quality Gates van beide organisaties vergelijk constateer ik dat die van het ontwerpgedeelte van Ziggo minder specifiek (en meer generiek) zijn dan het testgedeelte van Ziggo en de Quality Gates van Tech Mahindra. Dit uit zich in eisen die op documentniveau zijn geformuleerd in plaats van op de inhoud van de documenten. Gedurende het onderzoek heb ik dit aangekaart en bijgedragen aan het verder definiëren van de Quality Gates in het ontwerpgedeelte.


39/55

8 VERANDERINGEN VOOR EEN OVEREENGEKOMEN WERKWIJZE In dit hoofdstuk wordt een antwoord gegeven op de vierde deelvraag: ‘Welke veranderingen zijn nodig om tot een overeengekomen werkwijze te komen en welke consequenties brengen die met zich mee?’ Dit hoofdstuk biedt inzicht in de veranderingen die nodig zijn voor beide organisaties om de werkwijze op elkaar af te stemmen en te beheersen. Het antwoord is geformuleerd aan de hand van de verkregen informatie x en alle aspecten zijn volgens de COPAFIJTH-methode toegelicht. De keuze voor de COPAFIJTH-methode komt voort uit de geboden handvatten. Dit model biedt een checklist om processen te analyseren en (mogelijke) knelpunten per aspect te benoemen. Het model bevat uiteenlopende aspecten die elk een ander perspectief geven op de situatie.

8.1

COPAFIJTH

8.1.1 COMMERCIE De veranderingen in het voortbrengingsmodel en uniforme werkwijze hebben indirect invloed op de commerciële positie van Ziggo. Mochten innovaties en marktintroducties (te) lang op zich laten wachten dan zou bijvoorbeeld het concurrerend voordeel verloren kunnen gaan of kan er sprake zijn van een overinvestering, waardoor de Return On Investment (ROI) lang op zich laat wachten. De mogelijke risico’s van deze scenario’s kan aanleiding zijn voor nader onderzoek. 8.1.2 ORGANISATIE De afdeling Ziggo AD Sourcing bevat een regieorganisatie die naar een hoger niveau gebracht kan worden. Het management van de afdeling mist regisserende rollen. De rollen die aangesteld moeten worden zijn de procesen kwaliteitsmanager. Met die rollen wordt er invulling gegeven aan de verantwoordelijke en eigenaar van het voortbrengingsmodel. De regieorganisatie van de afdeling wordt daardoor meer volwassen. Voor de lange termijn heeft dat een positief effect omdat de procesen kwaliteitsbeheersing en verbetering zijn gewaarborgd. Binnen Ziggo (als organisatie in het geheel) is er een leider nodig die een duidelijke richting aangeeft en daarbij het voortbrengingsmodel over de individuen zekerstelt. De verschillen tussen de twee voortbrengingsmodellen begint met het detailniveau en de volgorde van bepaalde stappen. Organisatorisch zouden deze modellen op elkaar af te stemmen. Binnen het voortbrengingsmodel van Tech Mahindra is de System Integration Test voor de System Test geplaatst. Het ontwerpen testgedeelte van het voortbrengingsmodel van Ziggo AD is niet in gelijk detail uitgewerkt, daardoor mist de afstemming tussen beide kanten. Naast deze procesafwijkingen verschilt de manier van aansturing. Tech Mahindra is daarin meer volwassen en heeft een verantwoordelijke afdeling. Binnen Ziggo AD is de verantwoordelijke daarvoor niet formeel vastgelegd, beheersing en verbetering blijven daardoor uit. 8.1.3 PERSONEEL Zowel het personeel van Ziggo als van Tech Mahindra zullen veranderingen ondervinden van de implementatie van de uniforme werkwijze. Voor de Ziggo medewerkers houdt het in dat het werken met een andere cultuur de dagelijkse gang van zaken wordt en communicatie veelal via India verloopt. Voor Tech Mahindra houdt het in dat zij meer leiding op zich moeten nemen. Medewerkers van beide organisaties worden getraind om te werken volgens het nieuwe proces en de toegereikte handvatten. De trainingen worden momenteel op locatie in Utrecht gegeven. De Tech Mahindra medeIntegrating an outsourcing partner

40/55

werkers die nieuw toe treden zullen ook deze training moeten volgen. Het is een kostbare optie om iedereen naar Utrecht te laten komen. Een e-learning of een videoconference basistraining is daarbij een uitkomst. De medewerkers van de regieorganisatie (onder andere de procesen kwaliteitsmanager) zullen over de volxi xii gende competenties moeten beschikken: Relevante businesskennis Algemene organisatie- en managementcompetenties Business – IT alignment Sourcing competenties o Juridische en financiele kennis o (Strategische) Inkoop o Auditing ervaringen 8.1.4 ADMINISTRATIEVE ORGANISATIE Binnen de administratieve organisatie van Ziggo zullen er wijzigingen plaatsvinden door de aanstelling van een AD Change Board. Deze groep beslist over wijzigingen in het AD proces, templates, aansturing, etc. De leden daarvan kunnen aangesteld worden door de rollen toe te voegen aan bijvoorbeeld de procesen kwaliteitsmanager en stakeholders. Daarnaast biedt een nieuw ingerichte portal met relevante (proces) informatie één waarheid waar iedereen op kan terugvallen in het geval van onduidelijkheden of nieuwe medewekers. 8.1.5 FINANCIËN Veranderingen in de financiële situatie zijn de aanstelling van de procesen kwaliteitsmanager. Dit brengt de relevante arbeidsvoorwaarden met zich mee. De arbeidsvoorwaarden hangen af van verschillende aspecten waaronder het functieniveau en vereiste werkervaring. In dit rapport wordt dat niet verder uitgezocht. De trainingen om het personeel (van zowel Ziggo als Tech Mahindra) op te leiden in het correcte gebruik van de geboden middelen en processen zijn essentieel. Training van de Indiërs (in India) kan erg kostbaar worden als deze allemaal naar Nederland zouden moeten komen. Een e-learning of training door middel van videoconference zou daarbij een uitkomst zijn en veel geld besparen. In het Partnership 2.0 programma zijn financiële aspecten opgenomen in de vorm van een risk and reward systeem. Dit houdt in dat geboekte winsten en/of verliezen tussen beide partijen worden gedeeld. Dit maakt ze beide verantwoordelijk voor de realisatie. Met de opzet van het Partnership 2.0 programma hebben beide organisaties daar ook financieel in geïnvesteerd. 8.1.6 INFORMATIEVOORZIENING De informatievoorziening omtrent het voortbrengingsmodel wordt inzichtelijk gemaakt door middel van het QA-dashboard. Aanpassingen in het voortbrengingsmodel kunnen daar ook mee gemeten worden. De bestaande versie meet enkel op het ontwerpgedeelte. Om over het gehele proces te kunnen rapporteren zal het testgedeelte (en de onderliggende afhankelijkheid) daaraan toegevoegd moeten worden. Het QA-dashboard kan na correcte implementatie voor verschillende doeleinden gebruikt worden. Te denken valt aan de juridische vervolgstappen tijdens een project of de status en doorlooptijd van projecten (intern) te delen. Daarnaast is het QA-dashboard ingericht voor rapportagedoeleinden, met de uitbreidingen kunnen er ook meer KPI’s gemeten worden. 8.1.7 JURIDISCH Op het juridisch aspect is dit onderzoek niet ingegaan. Er zijn wel een aantal punten waarnaar vervolgonderzoek kan plaatsvinden. Integrating an outsourcing partner

41/55

Zo zijn er verschillende contractuele mogelijkheden om werkzaamheden uit te besteden. Dit gebeurt met behulp van een werkorder genaamd Individual Statement Of Work (ISOW). Een ISOW kan bijvoorbeeld worden aangegaan tegen een uurtarief of voor een afgesproken prijs per onderdeel. In de ideale situatie loopt de ISOW gelijk met de betreffende Quality Gate om de controle en regie te behouden. Dit vergt een nader onderzoek om dit correct te implementeren binnen Ziggo AD. Daarnaast dient rekening gehouden worden met de Nederlandse wet bescherming persoonsgegevens. Dit aspect is van toepassing vanwege de te verlenen toegang aan Tech Mahindra op het interne Ziggo netwerk. Daarbij dient worden voldaan aan de voorgeschreven wet. 8.1.8 TECHNOLOGISCH De Indiërs werkten tot voorkort via een onstabiele VPN-verbinding. De volgende stap om de Indiërs een werkbare (digitale) omgeving te bieden is een MPLS-verbinding waarbij de VPN-connectie vooraf is ingebouwd. De verbinding is reeds actief echter de achterliggende diensten, zoals de Citrix omgeving en toegang tot applicaties, nog niet. De vervolgstappen die daarvoor genomen moeten worden zijn: Beschikbaarheid van Ziggo systeemaccounts Accounts voor de systemen: o CaseWise Corporate Modeler o JIRA o SharePoint o ChangePoint o Project netwerkmappen o Project testomgeving Handleidingen voor gebruik van de systemen De bovenstaande technologische toegang moet voldoen aan Nederlandse wetgeving beschreven in het juridische aspect. 8.1.9 HUISVESTING Met betrekking tot dit aspect zijn er geen wijzigingen van toepassing. Een aanvullende actie zou kunnen zijn om de van Ziggo betrekkelijk weinig werkruimte uit te breiden. Dit is niet meegenomen in dit rapport, nader onderzoek is daarvoor vereist. Recentelijk is daar al een actie op genomen met de ingebruikname van een tweede kantoor in Utrecht, bedoeld voor projectteams.


42/55

9 CONCLUSIE Op basis van wat op de voorgaande bladzijden is beschreven kom ik tot het volgende antwoord op de hoofdvraag. ‘Op welke punten van het voortbrengingsmodel van Tech Mahindra zijn aanpassingen nodig om een integraal onderdeel te worden van het vastgestelde voortbrengingsmodel van Ziggo?’ Zowel Ziggo als Tech Mahindra is er van overtuigd dat beide organisaties dezelfde, positieve, insteek hebben om de samenwerking te laten slagen. Dit blijkt uit de visie van de stakeholders die naar voren is gekomen tijdens het onderzoek. Daarnaast beschikt Tech Mahindra over een uitgebreide ervaring en een scala van bestpractices op het gebied waar Ziggo veel profijt van heeft. Om de twee organisaties te integreren in één voortbrengingsmodel zijn aanpassingen noodzakelijk, stilstand is immers achteruitgang. De benodigde aanpassingen in het voortbrengingsmodel zijn uiteenlopend. Ten eerste is vergaande uitwerking en afstemming van het voortbrengingsmodel nodig op het gebied van de gebruikte templates, projectmodel, procesgang en in- en uitgangseisen per ontwikkelproduct. Vervolgens zijn er geconstateerde extra stappen nodig voor de implementatie van de uniforme werkwijze. Ten slotte speelt de managementaansturing, rapportage en regie op de samenwerking een cruciale rol. De vraag en aanbod afstemming heeft daarin een grote factor. De volwassenheidsgraad van de organisatie verschilt tussen Ziggo en Tech Mahindra. Tech Mahindra is in de gerelateerde aspecten meer volwassen. Uit de groei van Ziggo moet blijken of Ziggo dit niveau kan evenaren. Deze conclusie is opgebouwd uit de antwoorden op de verschillende deelvragen. Eerste deelvraag ‘Wat is de uitgangssituatie met betrekking tot het voortbrengingsmodel en in- en uitgangseisen?’ 1. 2.

Voor Ziggo Voor Tech Mahindra

Softwareapplicaties worden veelal gemaakt in projectvorm. Om daar structuur in aan te brengen wordt dit door zowel Ziggo als Tech Mahindra uitgevoerd aan de hand van een projectmodel en een daarvan afgeleid voortbrengingsmodel. Uit het resultaat van het onderzoek maak ik op dat de voortbrengingsmodellen veel van elkaar weg hebben. Van beide organisaties zijn zowel het projectmodel en het voortbrengingsmodel in procesvorm aanwezig. Ik heb de volgende verschillen geconstateerd: Het detailniveau van de voortbrengingsmodellen is niet gelijk In de voortbrengingsmodellen komt de volgorde van de System Test en System Integration Test niet overeen De twee organisaties zijn op het gebied van procesaansturing en -borging niet op een gelijk niveau De visie op de samenwerking van beide organisaties gaat gelijk op De afstemming tussen het ontwerpen testgedeelte van het voortbrengingsmodel van Ziggo AD is niet uitgewerkt De gebruikte termen in fasen van het projectmodel en voortbrengingsmodel van Ziggo komen niet met elkaar overeen Tweede deelvaag


43/55

‘Hoe verloopt de huidige uitwisseling van ontwikkelproducten in projecten?’ Uit het onderzoek heb ik geconstateerd dat opleveringen binnen projecten uit twee varianten bestaan. 1.

Project beheerproducten

De project beheerproducten zijn documenten die worden opgeleverd om een project te kunnen valideren, besturen, etc. Binnen Ziggo zijn beheerproducten de Project Brief, Mandate en PID. Dit is afgeleid van de toegepaste PRINCE2 projectmethode. Tech Mahindra levert dezelfde beheerproducten op en aannemelijk is dat zij ook de PRINCE2 projectmethode gebruiken. 2.

Project ontwikkelproducten

De project ontwikkelproducten worden binnen de looptijd van een project volgens het voortbrengingsmodel opgeleverd. De volgende ontwikkelproducten worden opeenvolgend opgeleverd: Requirements RIA IA Global Design Functional Design De uitwisseling van de ontwikkelproducten verloopt digitaal via onderstaande systemen: SharePoint JIRA CaseWise Corporate Modeler ChangePoint Project netwerkmappen Project testomgeving Door de transitie binnen Ziggo om de ‘nieuwe manier van werken’ te implementeren verloopt de uitwisseling van ontwikkelproducten niet altijd volgens verwachting. Dit heeft onder andere te maken met de interne cultuuromslag waar de Ziggo medewerkers mee geconfronteerd worden. Derde deelvraag ‘Wat zijn van het vastgestelde voortbrengingsmodel de gewenste in- en uitgangseisen van project ontwikkelproducten?’ Elk van de hierboven beschreven project ontwikkelproducten heeft bepaalde kwaliteitseisen,Quality Gates. De Quality Gates zijn zowel bij Ziggo als bij Tech Mahindra (deels) gedefinieerd op de in- en uitgang per fase. Door middel van een QA-dashboard kunnen er rapportages over de Quality Gates gegenereerd worden om voor het management de statussen per project inzichtelijk te maken. Tussen de Quality Gates van Ziggo en Tech Mahindra heb ik de volgende verschillen geconstateerd. Er mist een afstemming tussen de Quality Gates van beide partijen De Quality Gates van Ziggo zijn nog niet definitief vastgelegd (voor zowel het ontwerpen testgedeelte) Van het ontwerpgedeelde van Ziggo vind ik de Quality Gates te generiek (op documentniveau) De Quality Gates van Tech Mahindra vind ik erg concreet en compleet uitgewerkt


44/55

Vierde deelvraag ‘Welke veranderingen zijn nodig om tot een overeengekomen werkwijze te komen en welke consequenties brengen die met zich mee?’ De benodigde veranderingen hebben betrekking op verschillende aspecten van de samenwerking. De veranderingen zijn volgens de COPAFIJTH-methode per aspect in kaart gebracht. De belangrijkste daarvan zijn de verschillen tussen de voortbrengingsmodellen, de aansturing en beheersing daarvan en de technische belemmeringen tijdens de uitvoer van projecten. Tevens komen er Het verschil tussen de voortbrengingsmodellen is reeds aangekaart. De aansturing en beheersing daarvan kan beïnvloedt worden door de aanstelling van een procesen kwaliteitsmanager. Daarmee wordt de verantwoordelijkheid en eigenaarschap formeel vastgelegd en kan er gewerkt worden aan verbeterslagen. De technische belemmeringen omvat de toegang (vanuit India) op het bedrijfsnetwerk van Ziggo en de daarbij behorende systemen. Daarnaast zijn er commerciële, financiële en juridische aspecten die goed uitgewerkt en/of verder onderzocht moeten worden.


45/55

10 AANBEVELINGEN In dit hoofdstuk volgen mijn aanbevelingen waarin ik een gefaseerde aanpak schetst om Tech Mahindra een integraal onderdeel te laten vormen van het voortbrengingsmodel van Ziggo AD. Een gefaseerde aanpak vind ik de beste optie voor de samenwerking tussen Ziggo en Tech Mahindra, om draagvlak te creëren en te waarborgen. De achterliggende gedachte daarbij is dat de interne organisatie van Ziggo AD zich langzaamaan aanpast aan het werken met externen die, in het geval van Tech Mahindra, zich in India bevinden. Tech Mahindra heeft ook profijt van de gefaseerde aanpak omdat ik acht dat Tech Mahindra (als System Integrator) nog een lange weg te gaan heeft om de, gewenste, leidende positie op zich te nemen. De volgende fasen worden toegelicht. 1. 2. 3.

De uniforme werkwijze volledig vastleggen De uniforme werkwijze implementeren Beheersen en verbeteren op de lange termijn

10.1 VASTLEGGEN Mijn eerste advies is om de werkwijze volledig te definiëren en vast te leggen. Daar komen verschillende aspecten bij kijken die ik hieronder toelicht. Als quick-win om de samenwerking te verbeteren adviseer ik om de MPLS-verbinding en benodigde systemen werkend te krijgen en zo deze belemmerende factor weg te nemen. Dit zou tevens nieuwe mogelijkheden kunnen bieden voor een geavanceerdere manier van communicatie en interactie. Daarnaast adviseer ik dat het eigenaarschap wordt geformaliseerd in de vorm van een procesen kwaliteitsmanager met de juiste compexiii xiv tenties. Tech Mahindra adviseer ik dezelfde rollen in te vullen. Per ontwikkelproduct moeten de in- en uitgangseisen overeenkomen en gewaarborgd worden. Dit betekent dat deze eisen binnen Ziggo AD concreter (minder generiek) geformuleerd moeten worden. Daarnaast adviseer ik om het ontwerpen testgedeelte van het voortbrengingsmodel op hetzelfde detailniveau uit te werken. Hiermee bedoel ik dat het testgedeelte visueel wordt weergegeven in procesvorm en dat daar per ontwikkelproduct templates voor ontworpen worden. De tekstuele fouten en verkeerde verwijzingen in het ontwerpgedeelte worden tegelijkertijd herstelt. Tevens moet de samenhang tussen het projectmodel en voortbrengingsmodel meteen aangepakt worden zodat de termen overeenkomen er daar geen onduidelijkheid ontstaat tijdens de vervolgstappen. Om de afstemming met Tech Mahindra te waarborgen adviseer ik een SharePoint-portal op het intranet in te richten. De portal biedt één enkele waarheid. Naast de inrichting van de portal moeten er afspraken gemaakt worden dat zodra iemand van Tech Mahindra begint aan een project op de hoogte wordt gebracht van de manier van werken. Dit kan zijn uiting hebben in een fysiek bezoek aan Ziggo, een minder kostbare off-site elearning of basistraining. De portal zou relevante informatie moeten bevatten, waaronder minimaal: Processchema’s o Met specifieke aanpassingen ten opzichte van Tech Mahindra’s eigen proces Templates van ontwikkelproducten Stakeholders contactenlijst Overzicht van systemen, handleidingen daarvan en FAQ’s High-level reports van lopende projecten/programma’s


46/55

Afsluitend in fase adviseer ik Ziggo AD om de input van Tech Mahindra’s Quality Management Group op te xv zoeken. Deze keuze onderbouw ik door de volwassenheidsgraad en ervaringen van Tech Mahindra. Daarnaast is de aanpasbaarheid op dit moment makkelijker vanwege het vroege stadium van implementatie. Een belangrijk aspect daarbij is dat de QMG niet gemakkelijk documenten deelt of vrijgeeft in verband met het daarop rustende intellectuele eigendom. Ik adviseer om op hoger managementniveau dit aspect aan te kaarten en hier een passende oplossing voor te vinden.

10.2 IMPLEMENTEREN Tijdens de implementatie van de uniforme werkwijze dient er onderscheid gemaakt te worden tussen lopende en nieuwe projecten. Voor de implementatiefase adviseer ik de volgende extra stappen die hieronder zullen worden besproken. De communicatie binnen Ziggo en Tech Mahindra moet top-down plaatsvinden. Binnen Ziggo is dit nodig om de uniforme werkwijze over de individuen zeker te stellen. Uit de ‘zachte’ factoren van het eerder beschreven 7S-model komt naar voren er vaak discussies ontstaan over implementaties en met de top-down communicatie wordt voorziet in een duidelijke leiderschap. Binnen Tech Mahindra is dit nodig vanwege de culturele verschillen, omdat de Indische medewerkers erg gevoelig zijn voor autoriteit en hiërarchie dat mede uit het AT Kearny onderzoek komt. De implementatiesnelheid moet behouden blijven. Daarnaast moeten wijzigingen, implementaties en voortgang duidelijk en frequent binnen de organisatie gecommuniceerd worden. Een communicatieplan biedt daarvoor een uitkomst. De instructies van de ingerichte SharePoint-portal en MPLS-verbinding behoort ook tot de communicatie. Ik adviseer dat de communicatie afkomstig is van een medewerker van Ziggo, geen externe medewerker. Dit heeft een positief effect op het draagvlak omdat de meeste medewerkers van onder andere het Partnership 2.0 programma externen zijn. Daarnaast komen de ‘zachte’ factoren ook hierin terug. De operationele toepassing van de vastgestelde werkwijze geschiedt in lopende en nieuwe projecten die elk een andere aanpak vereisen. Bij lopende projecten adviseer ik om eerst de status, fase en voortgang van het project te monitoren. Aan de hand daarvan is de volgende fase van dat project bekend waar (andere en/of nieuwe) ingangseisen aan gebonden zijn. Door het lopende project daar op aan te laten sluiten zouden de ontwikkelproducten wellicht aangepast moeten worden. Na aanpassing verloopt het project volgens de geïmplementeerde werkwijze. Hierbij biedt de procesen kwaliteitsmanager een faciliterende rol. Bij aanvang van een nieuw project zou ik adviseren direct de vastgelegde werkwijze te gebruiken. Op die manier raken de medewerkers hier bekend mee en maken ze de werkwijze zich eigen. Ook hierbij biedt de procesen kwaliteitsmanager een faciliterende rol.

10.3 LANGE TERMIJN Het partnership tussen Ziggo en Tech Mahindra zal denk ik veel inspanning vereisen om het gewenste niveau te bereiken dat beide organisaties nastreven. Nadat de voorgaande stappen naar voldoening zijn uitgevoerd kan er begonnen worden aan de beheersing en verbeterslagen in het voortbrengingsmodel en regieorganisatie. Onderstaande onderdelen komen daarbij aan bod. Mijn eerste advies is de regieorganisatie volgens het regie-referentiemodel naar het volgende niveau te brenxvi gen. De procesen kwaliteitsmanager spelen daarin een cruciale rol. Het regie-referentiemodel biedt handvatten om regie passend te maken. Een onderliggend aspect van de regieorganisatie is een balans tussen vraag en aanbod. Integrating an outsourcing partner

47/55

De bestaande regie-organisatie bevindt zich momenteel in 4 – Regie door interne leverancier (de afdeling Application Development). Op de lange termijn zou de regie-organisatie centraal belegt moeten worden, 1 – Centrale regie. Zie de onderstaande figuren. Mijn keuze hiervoor onderbouw vanwege de organisatiebrede sturing en regie op vraag en aanbod. Balans daarin komt de samenwerking ten goede, omdat er dan sprake is van een constante stroom van werkopdrachten richting Tech Mahindra.

Het tweede advies voor de lange termijn is om het volledig vastgestelde voortbrengingsmodel kritisch te herzien. De achterliggende gedachte daarbij is dat het ontwerpen testgedeelte op die manier naadloos met elkaar verweven raken. Op dit moment is dat niet het geval aangezien deze apart van elkaar zijn vormgegeven. Uiteindelijk komt dit de alignment ten goede. Daarnaast kunnen er nieuwe requirements van de eindgebruikers in opgenomen worden. Een mogelijke requirement zou kunnen zijn dat de applicatieontwikkeling een Agile vorm aanneemt (in plaats van de huidige waterval methode). Dit heeft wederom betrekking tot de ‘zachte’ factoren uit het eerder beschreven 7S-model. De medewerkers krijgen hierdoor invloed op hun eigen werkwijze, dit verzekert op de lange termijn de acceptatie en draagvlak. Ik adviseer het QA-dashboard uit te breiden met de vernieuwde versie van het voortbrengingsmodel en wellicht ook met input vanuit Tech Mahindra. De rapportagemogelijkheden worden daardoor uitgebreid met het testgedeelte en het deel van Tech Mahindra. Dit geeft beide organisaties meer inzichten in het verloop van projecten. Samen met de betrokken personen van Tech Mahindra adviseer ik om onderzoek te doen naar de mogelijkheden om de ingerichte SharePoint-portal uit te breiden met functionaliteiten. Daarbij kan gedacht worden aan bestandsdeling en communicatie- of interactiemiddelen. De MPLS-verbinding levert daar belangrijke bijdrage aan, bijvoorbeeld point-to-point videoconferences. De technische vereisten daarvan zijn gezamenlijk met andere afdelingen in te richten. Ook op de lange termijn zou ik intensief contact onderhouden met de QMG om van hun kennis, input en volwassenheid te profiteren. Dit kan als voordeel hebben dat ‘het wiel niet opnieuw uitgevonden hoeft te worden’. Mocht de samenwerking compleet anders uitpakken dan gewenst, is een drastische mogelijkheid het voortbrengingsmodel te transformeren van een V-model naar een W-model. Ik adviseer dit enkel als de samenwerking na een bepaalde tijd (1+ jaar) nog steeds niet naar behoren werkt. In een W-model wordt er een tweede iteratie gevolgd. Het W-model zou een tussenstap of rustpunt bieden om in een later stadium af te bouwen naar het huidige (of verbeterde) V-model. Voordat deze stap gezet wordt raad ik aan dit goed uit te werken in de vorm van procestekeningen, proceseigenaren en communicatie.


48/55

11 BEGRIPPENLIJST Voortbrengingsmodel

Een procesmodel voor de realisatie van software, in de vorm van een V.

Time-to-market

De tijd die het een organisatie kost om van idee tot realisatie te komen.

Scope

De omslag van werkzaamheden binnen een afdeling, project, etc.

System Integrator

Een externe partij die aansturende taken van de opdrachtgever overneemt en leiding en directie geeft aan het Factory Model.

Factory model

Het (blackbox) principe waarbij er uniforme ontwerp naar de developer gaat en er zonder onverwachte tussenstappen zoals verwacht retour komt.

Legacy-systemen

Oude systemen of applicaties die gebruikt worden om bepaalde bedrijfsprocessen te ondersteunen.

Partnership 2.0

Het programma dat Ziggo met Tech Mahindra heeft gestart om de samenwerking te intensifiëren.

Customer Facing Team

Het team vanuit Tech Mahindra die regelmatig contact houdt met de klant (Ziggo).

RFI

Request For Information, een van de eerste stappen in een aanbestedingsfase.

RFP

Request For Proposal, een stap waarbij de gecontacte partij gevraagd wordt hoe zij de kwestie zouden aanpakken.

QMG

Quality Management Group, de afdeling binnen Tech Mahindra die verantwoordelijk is voor het verzamelen van best-practices, processen, kwaliteitsstandaarden, etc. De afdeling is binnen Tech Mahindra organisatiebreed beschikbaar.

PDCA

Plan-Do-Check-Act, de cirkel van Deming.

MASTER

MASTER staat voor: 1. 2. 3. 4. 5. 6.

(Tech) Mahindra’s Analysis Solution Transition Execution Relationship

De QMG beheert dit framework. BMS

Business Management System, het bedrijfsvoeringsysteem dat Tech Mahindra gebruikt voor dagelijkse aansturing van projecten en werkzaamheden.

eTOM framework

Enhanced Telecom Operations Map, een framework met kritische bedrijfsprocessen voor een succesvolle telecom operator.

COTS

Commercial Of The Shelf, een standaard softwarepakket die wordt aangepast naar de eisen en wensen van de klant.

Project ontwikkelpro-

De producten die een project oplevert volgens vastgestelde requirements en specifica-


49/55

ducten

ties.

Project beheerproducten

De producten die het beheer en de controle van een project mogelijk maken.

Deliverable

Een project ontwikkelproduct dat wordt opgeleverd door de uitvoerende partij, bijvoorbeeld Tech Mahindra.

(R)IA

Een korte en uitgebreidere impact analyse, hiermee wordt bekeken welke impact een wijziging heeft op het bestaande en toekomstige applicatielandschap.

Global Design

Een globaal ontwerp van nieuwe functionaliteiten die voortkomen uit business requirements.

Functional Design

Een specifieker ontwerp per functionaliteit die de input en output aangeeft.

ISOW

Individual Statement Of Work, een contract die de voorwaarden, betaling, etc. beschrijft. Wordt vaak per fase opgesteld.

Quality Gates

Een controlepunt voor de in- en uitgangseisen per fase.

ROI

Return-On-Investment, de periode date en investering zich heft terugverdient.

Risk and reward

Een verdeling tussen organisaties om de geboekte winsten en/of verliezen te delen.

Quality Gates

Een controlepunt voor de in- en uitgangseisen per fase.


50/55

12 BIJLAGEN 12.1 FIGUREN

Figuur 1. Partnership 2.0 organisatiestructuur.

Figuur 2. Het Tech Mahindra Agile ontwikkelproces.


51/55

Figuur 3. Het Tech Mahindra proces voor COTS softwarepakketselectie en -implementatie.

Figuur 4. Het Tech Mahindra proces als SI-rol.


52/55

12.2 TABELLEN

Tabel 1. Categorieën van geconstateerde afwijkingen in het testgedeelte.

Tabel 2. De eerste versie van de Quality Gates van het ontwerpgedeelte van het voortbrengingsmodel.


53/55

12.3 DOCUMENTEN 1. 2. 3. 4. 5. 6. 7. 8.

Reflectieverslag afstudeerperiode – I. Vinkenborg Voortbrengingsmodel Ziggo AD Applicatielandschap Ziggo Quality Gate Criteria – left side Generic Program Test Plan Template RIA/IA/Global Design Template Functional Design ZBS Operational Process


54/55

13 BRONNENLIJST i

The Open University (2011). Discovering Management. Verkregen op 14-01-2013 van http://www.open.edu/openlearn/money-management/management/leadership-andmanagement/discovering-management/content-section-0 ii Price, D. (2009). The Principles and Practice of Change. Basingstroke: Palgrave Macmillan iii Kleijn, H., Rorink, F. (2012). Verandermanagement, 9789043023610. Nederland: Pearson Education iv Wikipedia. Matrix management. Verkregen op 14-04-2013 van http://en.wikipedia.org/wiki/Matrix_management v AT Kearney (2012), Assessing Cultural Differences and Resulting Implications vi Platform Outsourcing Nederland (2011). Applicatiesourcing, 9789085482949. Nederland: GigaBoek vii Janssen, P. (2007). PRINCE2 compact, 9789043012843. Nederland: Pearson Education viii Hambling, B., Morgan, P. (2010). Software testing: an ISEB foundation, 9781906124762. United Kingdom: British Computer Society ix Paul, D., Yeates, D., Cadle, J. (2010). Business analysis, 9781906124618. United Kingdom: British Computer Society x Kars, C., Evers, H. (2006). Praktijkboek procesmanagement, 9789059721302. Nederland: Eburon Uitgeverij xi ste Beenakker, J., Van der Valk, R., Wesselman, E. (2008). Regie in de 21 eeuw: een kwestie van kunnen, 9789079272044. Nederland: TIEM xii Quint Wellington Redwood (2007). Sourcing-regie wordt kernactiviteit. xiii ste Beenakker, J., Van der Valk, R., Wesselman, E. (2008). Regie in de 21 eeuw: een kwestie van kunnen, 9789079272044. Nederland: TIEM xiv Quint Wellington Redwood (2007). Sourcing-regie wordt kernactiviteit. xv Pijpers, T., Teunissen, B. (2008). Client, pas u aan uw serviceprovider aan, 9789079272044. Nederland: TIEM xvi Janssen, S., Scheepens, J., Verhoef, D. (2008). Regie als kerncompetentie van iedere klantorganisatie, 9789079272044. Nederland: TIEM


55/55

INTEGRATING AN OUTSOURCING PARTNER. Ziggo Application Development

Recommend Documents