adviesrapport florence actief_v1.0

45
2016 Datum: 08-04-2016 Groepsleden: Stefan van ’t Hof (13020250) Corstiaan Mulckhuijse (13078003) Yama Yaghobie (11086211) Xander van Berckel Bik (12086436) Opdrachtgever: dhr. M. Oosterheert Opleiding: Business IT & Management Course: EA/OC Versie: 1.0 Adviesrapport V1.0 Het aanbieden van activiteiten voor vitale ouderen, leidt zowel fysiek als mentaal tot gezondheidswinst en een beter welbevinden. Dit zorgt voor lagere zorgkosten en draagt bij aan de maatschappij. Tevens vergroot dit de kans om voor Florence te kiezen als zorgorganisatie

Upload: rloggen

Post on 20-Feb-2017

118 views

Category:

Education


1 download

TRANSCRIPT

2016

Datum: 08-04-2016 Groepsleden: Stefan van ’t Hof (13020250) Corstiaan Mulckhuijse (13078003) Yama Yaghobie (11086211) Xander van Berckel Bik (12086436) Opdrachtgever: dhr. M. Oosterheert Opleiding: Business IT & Management Course: EA/OC Versie: 1.0

Adviesrapport V1.0

Het aanbieden van activiteiten voor vitale

ouderen, leidt zowel fysiek als mentaal tot

gezondheidswinst en een beter welbevinden.

Dit zorgt voor lagere zorgkosten en draagt bij

aan de maatschappij. Tevens vergroot dit de

kans om voor Florence te kiezen als

zorgorganisatie

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 1

Managementsamenvatting In de afgelopen jaren neemt de vergrijzing steeds meer toe, de kans dat er meer ouderen zijn die lichamelijke en/of psychische problemen hebben neemt ook toe. Hierdoor is het belangrijk om als zorginstelling ook te richten op de capaciteiten van ouderen. Met dit project geven wij Florence advies over de inrichting van het nieuwe label Actief. Het doel is om ouderen te helpen en ondersteunen bij de ontwikkeling van initiatieven. Voor het project hebben wij Agile scrum gebruikt. De methode bleek voor ons effectief te zijn, aangezien wij om de drie weken rond de tafel zaten met de opdrachtgever om de producten en de voortgang te evalueren. Wij hebben gezamenlijk besloten om het project in een aantal fases op te delen, Vooronderzoek; Validatie; Ontwerp; Afronding. Uit de cultuuranalyse van Caluwé kwam voort dat Florence Actief een witte en rode cultuurtypering heeft. De interventies zijn uiteraard ook hierop toegepast. Met de waarom en wie vraag hebben we het project beter in kaart kunnen brengen. Hierin is bij de wie vraag een stakeholderanalyse en stakeholdersupportmatrix opgesteld. De stakeholdersupportmatrix is gemaakt om aan te geven of de stakeholdergroepen de verandering zullen ondersteunen en hoeveel impact de verandering heeft. Hieruit is te zien dat, de “Stakeholders processen pull” belangrijke stakeholders zijn. Met hen werken we nauw samen en de processen die wij voor ze hebben ontwerpen. Voor het project bij Florence, hebben wij ons alleen gericht op het nieuwe label. Alles daarbuiten hoort niet in onze scope. Andere zaken die tevens buiten onze scope zijn:

- In kaart brengen van het “aansturing en evaluatie van het initiatief” proces;

- Marketing van het pull-proces;

- Extra informatie over klanten in het CRM-systeem;

Vervolgens is er met behulp van het STMC-model de huidige en toekomstige situatie in kaart gebracht. Het label Actief is slechts een uitbreiding van de diensten van Florence. De structuur wordt uitgebreid van drie naar vier labels. De medewerkers moeten op de hoogte zijn van het nieuwe label en processen, zoals het proces aanmelden van een klant te kunnen verwerken. De cultuur binnen de organisatie moet ook veranderen van zorg naar gezondheid. Er zijn voor het nieuwe label drie procesontwerpen gemaakt, namelijk:

- Aanmelden initiatief klant (proces 1) - Aanmelden voor activiteit (proces 2) - Organiseren van activiteit (proces 3)

Voor de gewenste situatie zijn er voor het nieuwe CRM-systeem requirements opgesteld. Deze zijn opgesteld vanuit de medewerkers en processen. Deze zijn verdeeld in business-, gebruikers- en softwarerequirements. De requirements zijn opgesteld met traceability en motivatie. Met behulp van de tool ArchiMate is er een architectuurontwerp gemaakt voor het label Actief. Door middel van een architectuurontwerp is er een overzicht van de systemen en processen gecreëerd. Om van AS IS naar TO BE te komen, zijn er verschillende interventies bedacht om dit te verwezenlijken. In het nieuwe label is het belangrijk om te weten wanneer een activiteit zelfstandig is, wanneer het verstandig is om de stekker eruit te trekken en wanneer een activiteit te starten. Om de juiste keuze te maken zijn er een aantal beslisbomen gemaakt die de medewerkers stapsgewijs kunnen volgen. We hopen dat de samenvatting uitnodigt tot het verder lezen van het adviesrapport!

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 2

Voorwoord Dit adviesrapport gaat over de praktijkopdracht die wij voor Florence namens de Haagse

Hogeschool hebben uitgevoerd. Deze opdracht valt onder het label Actief, een van de vier labels

binnen Florence. Vanuit school gezien valt deze opdracht binnen het blok BIM-H Organisational

Change en Enterprise Architectuur. Daarnaast is het onderdeel van het VitalITylab, hier vinden

projecten plaats met affiniteit tot de ontwikkeling binnen de gezondheidszorg. Met de uitvoering

van deze opdracht hebben wij een bijdrage geleverd aan de opzet van een nieuw label binnen

Florence. Concrete producten zijn enkele procesmodellen en procesbeschrijvingen, requirements

voor het CRM-systeem en een advies over de te gebruiken interventies.

Wij willen iedereen bedanken die op welke wijze dan ook geholpen heeft bij de uitvoering van deze

opdracht. Speciaal willen wij onze opdrachtgever Martin Oosterheert van Florence en begeleider

Roeland Loggen van de Haagse Hogeschool bedanken voor het bieden van deze mogelijkheid.

Zoetermeer, 08-04-2016

Xander van Berckel Bik Stefan van ‘t Hof Corstiaan Mulckhuijse Yama Yaghobie

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 3

Inhoudsopgave 1 Inleiding ..................................................................................................................................... 4

1.1 Leeswijzer: ......................................................................................................................... 4

2 Achtergrond ............................................................................................................................... 5

2.1 Beschrijving organisatie ...................................................................................................... 5

2.2 Waarom ............................................................................................................................. 6

2.3 Wie .................................................................................................................................... 6

3 Aanpak ..................................................................................................................................... 10

3.1 Interviews ......................................................................................................................... 11

4 Projectgrenzen ......................................................................................................................... 12

5 AS IS | Huidige situatie .............................................................................................................. 13

5.1.1 Cultuur STMC ............................................................................................................ 13

5.2 Proces ............................................................................................................................... 14

5.2.1 Aanmelden initiatief (Proces 1) .................................................................................. 14

5.2.2 Aanmelden voor activiteit (Proces 2) ......................................................................... 14

5.2.3 Organiseren van activiteit (Proces 3) ......................................................................... 14

6 GAP .......................................................................................................................................... 15

7 TO BE | Gewenste situatie......................................................................................................... 17

7.1 Beschrijving organisatie .................................................................................................... 17

7.1.1 Cultuur STMC ............................................................................................................ 17

7.2 Processen .......................................................................................................................... 18

7.3 Architectuurontwerp .........................................................................................................28

8 Requirements CRM-systeem .................................................................................................... 31

8.1 Business requirements ...................................................................................................... 31

8.2 Gebruikers requirements .................................................................................................. 32

8.3 Software requirements ..................................................................................................... 35

9 Interventies............................................................................................................................... 39

8.1 Beslisbomen per proces ....................................................................................................40

10 Advies ................................................................................................................................... 43

10.1 De processen .................................................................................................................... 43

10.2 CRM en requirements ....................................................................................................... 43

10.3 Interventies toepassen ...................................................................................................... 43

10.4 Cultuur verandering .......................................................................................................... 43

11 Conclusie ............................................................................................................................. 44

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 4

1 Inleiding In dit document zullen wij, als projectgroep voor Florence, een advies geven voor de inrichting van

het nieuwe label Actief.

Aanleiding van dit project is het nieuwe label (Actief) dat Florence wil oprichten. Deze nieuwe dienst

zal zich voornamelijk richten op (gezonde) ouderen. Het doel hierbij is om (gezonde, wellicht

kwetsbare) ouderen te ondersteunen bij het ontplooien van initiatieven. Hierdoor blijven de ouderen

langer vitaal, en leren zij kennismaken met Florence als organisatie.

Dit project is tot stand gekomen tijdens het 3e blok (BIM-H) van ons 3de leerjaar. Voor de courses

Organisational Change en Enterprise Architectuur gaan wij kijken naar de verandering binnen de

organisatie en naar de architectuur die de verandering met zich meebrengt.

Voor het nieuwe label zullen wij kijken naar de volgende zaken:

- De werkprocessen binnen het label “Actief”. Hiervoor zullen wij procesontwerpen opstellen.

Dit zal gebeuren voor de volgende processen:

o Het aanmelden van een initiatief;

o Het inschrijven voor een activiteit;

o Het organiseren van een activiteit.

- Een architectuurontwerp met de informatiebehoefte voor het label “Actief”. Hierin zullen de

koppelingen met het CRM-systeem te zien zijn;

- De requirements voor het CRM-systeem;

- Het advies voor het inrichten van de dienst, hierbij moet gedacht worden aan:

o Het inrichten van de werkprocessen;

o Mogelijke interventies;

o Welke stappen zou Florence nog moeten nemen tot de gewenste situatie.

Het doel van dit project is, het aanleveren van werkprocessen, een architectuurontwerp en

mogelijke interventies voor het label Actief. Wij zullen in dit document ons advies geven over hoe

het label het best opgericht kan worden.

1.1 Leeswijzer: In hoofdstuk 2 zullen wij wat vertellen over de opdracht die wij gekregen hebben en het bedrijf

waarvoor wij deze opdracht uitvoeren. Hoe wij deze opdracht uit zullen gaan voeren is te lezen in

het volgende hoofdstuk, hoofdstuk 3. In hoofdstuk 4 zullen wij de scope van het project bespreken.

In hoofdstuk 5, 6 en 7 worden respectievelijk de huidige situatie, de gap en de gewenste situatie

besproken. Hoofdstuk 8 zal gaan over de requirements voor het nieuwe CRM-systeem. De

interventies om de gap te overbruggen komen in hoofdstuk 9 ter sprake. Ten slotte zullen wij in

hoofdstuk 10 een advies gegeven over de optimale situatie voor het nieuwe label.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 5

2 Achtergrond

2.1 Beschrijving organisatie Florence Florence levert care-diensten in een aantal gemeenten in de randstad (o.a. Delft, Den Haag). Hun

primaire diensten zijn gericht op ouderen (woonzorgcentra, thuiszorg), ouders met kinderen

(kraamzorg, consultatiebureau), specialistische zorg en revalidatie.

Aan het begin van ons onderzoek hebben wij bij Florence Actief een cultuuranalyse uitgevoerd. Uit

deze analyse is naar voren gekomen dat de kleuren rood en wit kenmerkend zijn voor de organisatie.

De rode kleur van Caluwé geeft aan dat de organisatie de sfeer en mate van welbevinden en

motivatie erg belangrijk vindt. binnen Florence Actief zie je deze elementen ook sterk terug.

Daarnaast is het duidelijk geworden dat er doelen worden gesteld in de organisatie. Deze worden

niet stap voor stap beschreven wat veel raakvlakken heeft met de witte kleur van de Caluwé.

Missie: Steeds meer cliënten kiezen voor Florence, omdat hun oprecht betrokken medewerkers en

vrijwilligers graag en vakkundig helpen bij het samen optimaliseren van hun persoonlijk

welbevinden en zelfredzaamheid.

Visie Cliënten kiezen voor Florence omdat:

- Regie, zelfredzaamheid en kwaliteit van leven van hun cliënten op de eerste plaats staat; - Zij samen met de cliënt bepalen hoe zij binnen de mogelijkheden de beste resultaten

kunnen bereiken; - Florence in de wijk, bereikbaar en herkenbaar, is; - Florence een persoonlijke gids voor de (potentiële) cliënten is. Een gids, die zich verbindt

met de cliënten van vandaag en morgen; - Florence vanuit professionaliteit en betrokkenheid goede zorg en aanvullende diensten

levert. Organisatieonderdelen Florence Florence bestaat uit vier verschillende labels, namelijk:

- Thuis; - Expertise; - Allure; - Actief (nog in ontwikkeling).

Het project dat wij bij Florence hebben uitgevoerd, heeft betrekking hebben op het label Actief van

Florence.

Officieel is dit nog geen label van Florence, maar aan het eind van het project zou hier door Florence

meer bekendheid aan worden gegeven. Tot nu toe, tijdens het schrijven van het adviesrapport, is er

nog geen bekendheid aan het nieuwe label gegeven.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 6

De opdrachtgever en zijn rol De opdrachtgever voor dit project is Florence Actief. Binnen Florence hebben wij als contactpersoon

dhr. M. Oosterheert. Hij zal ons ondersteunen bij de uitvoer van het project.

De opdracht kort samengevat: Beschrijf de processen voor het aanmelden voor en van activiteiten en de organisatie hiervan. Dit

voor de pull-strategie van het label Actief en beschrijf de daarbij passende interventies en

requirements.

Aan het einde van het project wil de opdrachtgever (dhr. M. Oosterheert) duidelijk hebben welke

processen er nodig zijn om de pull-strategie toe te passen op het label actief. Daarbij is er door ons

nagedacht over eventuele interventies, die deze processen makkelijker implementeren in de

organisatie. Tenslotte zijn de functionele requirements voor het CRM-systeem beschreven en is er

een architectuurontwerp opgeleverd.

2.2 Waarom Aan de start van het project hebben wij als projectgroep een waarom vraag opgesteld. In overleg

met de opdrachtgever zijn wij gekomen tot de volgende vraag:

Het aanbieden van activiteiten voor vitale ouderen, leidt zowel fysiek als mentaal tot gezondheidswinst

en een beter welbevinden. Dit zorgt voor lagere zorgkosten en draagt bij aan de maatschappij. Tevens

verhoogt dit om voor Florence te kiezen als zorgorganisatie.

Uitleg: Activiteiten organiseren die door de potentiële doelgroep zelf worden aangedragen. Het gaat dan

om gezonden ouderen vanaf 60 jaar. Door deze activiteiten wordt geprobeerd om de ouderen

gezond te houden. Door het gezond houden van ouderen leidt dit zowel fysiek als metaal tot meer

gezonden ouderen. Doordat er meer gezonden ouderen zijn worden de zorgkosten minder en zorgt

dit voor een positieve ontwikkeling in de maatschappij. Florence hoopt door het aanbieden van

activiteiten voor gezonden ouderen dat de ouderen wanneer ze later hulp behoevend worden ook

kiezen voor Florence.

2.3 Wie Voor het achterhalen van de stakeholder hebben wij als projectgroep gekozen om twee methodes

te gebruiken. De standaard stakeholderanalyse en de stakeholdersupportmatrix deze matrix wordt

uitgelegd in het boek van Marco de Witte (De kunst van veranderen).

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 7

Figuur 1 stakeholdermatrix

Hierboven staat de stakeholderanalyse die op 02-03-16 is gemaakt. Tijdens het voortgangsgesprek

met Opdrachtgever Martin Oosterheert is er een brainstormsessie geweest om de stakeholders te

definiëren.

Hieronder zal van elke stakeholder zijn relatie met het label actief verduidelijkt worden en zijn

positie op de stakeholderanalyse.

De stakeholders met een letter hebben wij gesproken en zijn daarom opgenomen in de

stakeholdersupportmatrix. De stakeholders zijn in 4 verschillende groepen opgedeeld, namelijk:

1. Stakeholders van heel Florence (rood)

- Ministerie van Volksgezondheid, Welzijn en Sport

- Verzekeringsmaatschappijen

- Gemeenten

2. Stakeholders van het Label actief (Groen)

a) Medewerkers Florence

b) Managers binnen Florence

- Partners voor uitvoering van initiatieven

- Docenten voor de activiteiten

- Mantelzorgers

c) Ouderen uit de Doelgroep (60-80 jaar)

3. Stakeholders processen pull (oranje)

- Medewerking Fondsenwerving

a) Pr-medewerkers

b) IT-medewerkers

c) Medewerkers FCC

d) Wijkverpleegkundige

- Wijkmanager

4. Stakeholder Martin (oranje)

- Raad van Bestuur

a) Martin Oosterheert (medewerkers actief)

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 8

Om de interventies goed te kunnen implementeren is er ook een stakeholdersupportmatrix

gemaakt. Deze matrix is opgesteld naar aanleiding van de hierboven gedefinieerde groepen. Deze

stakeholdersupportmatrix geeft aan of de stakeholdergroepen de verandering zullen ondersteunen

en hoeveel impact de verandering heeft. Doormiddel van deze matrix kan er rekening worden

gehouden met de gevoelens bij de implementatie van het nieuw pull proces voor de activiteiten.

Figuur 2 stakeholdersupportmatrix

Deze verdeling is elke keer een niveau lager in granulariteit. Dit maakt het voor ons handig om in

kaart te hebben welke groep stakeholders we met een beslissing raken. Bijvoorbeeld: de inrichting

van proces Initiatief aanmelden zal voor een verzekeraar niet interessant zijn, voor een

medewerkers van het FCC juist wel.

Per groep volgt er nu een beschrijving:

De eerste groep bestaat uit de grote financiers van Florence. Doordat zij grotendeels de middelen

verstrekken is Florence afhankelijk van deze partijen. Zij hebben inhoudelijk weinig interesse in het

label Actief maar moeten wel tevreden gehouden worden. Het geld dat zij geven moet op een

verantwoordelijke wijze besteed worden om dit budget te houden.

De tweede groep zijn betrokken zowel direct als indirect bij het label Actief. Zij moeten

geïnformeerd worden over de activiteiten voor hen en verwachtingen die wij van hun hebben. Voor

de medewerkers van Florence betekent dit breder denken, in plaats van enkel gericht op zorg ook

richten op gezondheid. Partners en ouderen worden benaderd of kunnen zelf het initiatief nemen en

op Florence afstappen.

2a

Support

Impa

ct

Achterblijvers Supporters

Potentials

1

3a/b

?

4a

Veranderaars

3c

3d

2b

2c

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 9

De derde groep bestaat uit nauw betrokken stakeholders bij ons project en de processen die wij

gaan ontwerpen. Van hun is het van belang dat wij deze zeer nauw betrekken in de stappen die wij

zetten. Zij zijn straks de sleutel tot succes als de processen live gaan!

Als laatste hebben wij de stakeholders van Martin en hem zelf, hij gaf aan één belangrijke

stakeholder te hebben, namelijk de Raad van Bestuur. Hier moet hij om de zoveel weken

verantwoording afleggen over de voortgang en geboekte resultaten.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 10

3 Aanpak In dit hoofdstuk is beschreven hoe wij het project hebben aangepakt en daarnaast ook

verantwoording voor de keuzes die wij gemaakt hebben. Hiermee wordt dan ook de hoe-vraag

beantwoordt.

Wij hebben ervoor gekozen om de methodiek agile scrum te gebruiken gedurende het project. Het

is een methode die erg handig is voor dit project. Vooral omdat we hiermee een goed inzicht hebben

in de voortgang en dat we elke sprint een product hebben dat we met de opdrachtgever kunnen

evalueren.

Zoals net al beschreven, hebben wij ervoor gekozen om scrum te gebruiken. Een aantal onderdelen

die wij uitgevoerd hebben met de methodiek zijn:

- Sprint van twee weken: dit houdt in dat wij elke twee weken een product hebben, dit kan

bijvoorbeeld zijn een stakeholderanalyse, procesbeschrijving of een rapport.

- Wij hebben twee keer per week een stand-up meeting, waarin elke persoon kort verteld wat

die heeft gedaan, wat die nog gaat doen en of er issues zijn. Dit heeft ons geholpen om kort

en krachtig de voortgang te meten. Wij hebben ervoor gekozen om de rollen te verdelen

elke sprint, dit houdt in dat we rouleren elke twee weken met de rol van scrummaster en

product owner.

- Er is ook een product backlog bijgehouden, waarin beschreven staat wat er nog allemaal

gedaan moet worden voor het project. Dit hebben uiteraard geprioriteerd, dus welk product

wij het belangrijkst vinden, hebben wij bovenaan geplaats. Het heeft ons geholpen om een

goed overzicht te hebben van wat er allemaal op de to-do list staat. De productbacklog

hebben wij uitgevoerd met behulp van een tool genaamd Trello, het is een simpele en

duidelijke tool waarmee de stand-up meeting uitgevoerd kan worden.

- Elke twee weken hebben wij ook een voortgangsverslag naar onze begeleider/docent

gestuurd om hem op de hoogte te houden hoe wij ervoor staan.

- Naast het voortgangsverslag met de begeleider/docent hebben wij ervoor gekozen om elke

drie weken een gesprek te voeren met de opdrachtgever om met hem samen te evalueren

over de producten en of wij de juiste richting in gaan.

Nu het duidelijk is geworden hoe wij agile scrum hebben aangepakt, is het ook van belang om te

weten hoe de indeling is van het project en welke technieken en methoden wij gebruikt hebben

gedurende fases. Agile scrum heeft niet zozeer een bepaalde fasering of indeling, dus hebben wij

zelf een fasering opgesteld. Ons project bestaat uit vier fases, namelijk:

- Vooronderzoek;

- Validatie;

- Ontwerp;

- Afronding.

Vooronderzoek: Tijdens het vooronderzoek hebben wij allereerst een plan van aanpak opgesteld. In

het vooronderzoek proberen wij zoveel mogelijk informatie te krijgen, dit hebben wij gedaan door

middel van interviews. Er is gekozen voor interviewen, omdat het een methode is die helpt om

nieuwe en betrouwbare informatie te verzamelen. Wij hebben meerdere gesprekken gehad met

belanghebbenden van Florence Actief. Naast de interviews hebben wij ook gesprekken gehad met

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 11

de opdrachtgever en onze begeleider. De interviews en gesprekken met de opdrachtgever hebben

ons zeer veel geholpen met het scherp stellen van de opdracht en komen tot nieuwe inzichten.

Validatie: Na het vooronderzoek zijn wij in de fase gekomen waarin we de resultaten van het

vooronderzoek valideren en verbanden leggen. Dit hebben wij gedaan door elke week om de tafel te

zitten en met elkaar te overleggen en brainstormen. Daarnaast is er een power/interest

stakeholdersmatrix gemaakt om de belanghebbenden in kaart te brengen. Tevens is er

support/impact stakeholdersmatrix gemaakt om meer inzicht te krijgen van de stakeholders. Er is in

deze fase ook gebruik gemaakt van het STMC-model van De Witte en Jonker(2013)

Ontwerp: De volgende fase is de ontwerpfase. In deze fase zijn we al redelijk ver met het project en

is de tijd aangekomen om producten te ontwerpen. Hierbij hebben wij gebruik gemaakt van service

blueprint en procesbeschrijving volgens UML. Met behulp van de SBP is een klantreis gemaakt met

daarbij ook de interacties met de systemen. Wij hebben gekozen voor een procesbeschrijving

volgens UML, omdat het een duidelijke en simpele tool is. Iedereen kan het makkelijk begrijpen en

hanteren.

Afronding: In de laatste fase is het tijd om het adviesrapport op te stellen en de puntjes op de i

zetten. In deze fase is ook een eindpresentatie voor alle belanghebbenden van school en Florence

Actief.

3.1 Interviews Om een goed beeld te krijgen van zowel de opdracht als van Florence als organisatie, hebben wij als projectgroep een aantal interviews uitgevoerd. Van onze opdrachtgever, de heer Oosterheert, hebben wij een aantal namen doorgekregen. Na aanleiding hiervan hebben wij contact opgenomen met de betreffende personen. De afspraken zijn per mail met de medewerkers afgestemd en vonden plaats bij Florence. Hieronder is een lijst opgenomen met daarin de namen van de medewerkers waarmee wij gesproken hebben.

Naam: Functie:

Heleen Uijen Huisverpleegkundige

Loes Kwint Marketing

Ronneke Kieboom Manager FCC

Marian van Schie Projectleider

Lieke de Liefde Actief medewerker

Andrea van Gilst Actief medewerker

Cindy Ligtvoet Informatieadviseur

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 12

4 Projectgrenzen Tijdens ons project bij Florence, hebben wij ons alleen bezighouden met de nieuwe dienst rondom

(gezonde) ouderen.

De volgende zaken hebben wij voor Florence in kaart gebracht:

- Binnen het label “Actief” zijn de processen ontworpen die te maken hebben met het aanvragen van initiatieven van toekomstige cliënten/klanten;

- Architectuur ontwerp voor de koppelingen met het CRM systeem (gewenste situatie); - Doelen en requirements opstellen voor het CRM-systeem van het proces aanvragen van

initiatieven; - Informatiebehoefte inventariseren van de medewerkers en cliënten in het proces; - Adviseren over het inrichten van de nieuwe dienst.

o Welke interventies zijn nodig om het clubje (nieuwe medewerkers) de juiste dingen te laten doen?

o Hierbij hoort een opsomming van mogelijke interventies die hierbij helpen/handvaten geven.

o Welke stappen zijn nodig voor Florence om deze dienst succesvol te gaan leveren – in termen van veranderingen in technologie, medewerkers en cultuur?

De detaillering van de processen is één stap hoger dan de werkinstructies, de vereisten zijn

meegenomen. Dit alleen wanneer de stap in het proces hierom vraagt.

Om alle initiatieven in goede banen te leiden, wordt er door Florence nagedacht over een CRM-

systeem. Voor het advies over het CRM-systeem hebben wij ons beperkt tot de requirements.

Daarbij is in gedachte genomen dat het proces leidend is en niet het systeem.

Buiten de scope van het project valt het proces dat zorgt voor de aansturing en evaluatie van het

initiatief. Dus eigenlijk wanneer het initiatief een activiteit is geworden. De vraag “Hoe kan er tijdens

het proces gestuurd worden op het initiatief?” zal dan ook in dit project niet worden beantwoord.

Buiten scope:

- In kaart brengen van het “aansturing en evaluatie van het initiatief” proces;

- Marketing van het pull-proces;

- Extra informatie over klanten in het CRM-systeem;

- Het financiële aspect van de activiteiten. (dit naar aanleiding van de vraag tijdens de advies

presentatie)

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 13

5 AS IS | Huidige situatie

5.1.1 Cultuur STMC

De huidige situatie van Florence kenmerkt zich door het ontbreken van het label Actief. Om

duidelijk te maken wat er in de organisatie veranderd, hebben wij voor de huidige en toekomstige

situatie het STMC-model gemaakt. Voor de het toekomstige STMC-model, zie 7.1.1.

Structuur

Organisatie 3 Labels namelijk: 1. Thuis 2. Expertise 3. Allure

Proces Centraal in de organisatie staat de zorg voor jong en oud. Thuiszorg, verpleegtehuizen en consultatiebureaus

Technologie

IT De IT is ingericht om de zorg zo goed mogelijk te ondersteunen. Klanten volgen etc. is hier niet in meegenomen. Daarnaast zijn er zo’n 8 systemen waar Florence mee werkt.

Kennis Binnen de organisatie is er veel kennis aanwezig op het gebied van zorg. Ruim 90 % van het personeel verricht verpleegtechnische handelingen. Kennis van de cliënten is er bij het personeel en niet in de systemen.

Medewerkers

Competenties De medewerkers zijn nu goed in het geven van zorg aan jong en oud. Al de kennis die zij hebben richt zich op het hoofdproces van Florence, namelijk zorg voor de cliënt.

Cultuur

De medewerkers hebben het tijdens hun werk veelal over de beperking van de cliënt en hoe deze het best behandeld kan worden. Bij de verpleging richt men zich op de zorg die een cliënt nodig heeft.

Tabel 1 Huidige situatie

Allereerst is de structuur van Florence verdeeld in drie labels, deze zijn voornamelijk gericht op

(extra) zorg. Vanzelfsprekend is dan ook het primaire proces gericht op zorg aan jong en oud. Dit

vindt plaats op de locaties van Florence maar ook op consultatiebureaus en bij cliënten thuis.

De technologie bestaat niet alleen uit de IT-systemen, maar gaat ook over de kennis en

hulpmiddelen zoals bijvoorbeeld een checklist. Binnen Florence zijn er nu twee grote IT-systemen

namelijk CARES en NEDAP. Deze systemen zijn ontwikkeld om de zorg optimaal te ondersteunen.

Denk hierbij aan het opslaan van cliëntgegevens en het medische dossier.

Van de 4000 medewerkers van Florence is 90% bezig met verpleegtechnische handelingen. De

kennis binnen de organisatie bevindt zich vooral op het onderwerp zorg. Deze kennis is er bij de

medewerkers en niet in de systemen. Kennis en ervaring van het personeel is dus heel belangrijk. De

kennis, ervaring en vaardigheden bevinden zich nu dus bij de medewerkers zelf.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 14

5.2 Proces De huidige medewerkers van actief werken in de huidige situatie op hun eigen manier, hierdoor zorgen ze dat er activiteiten voor de ouderen worden georganiseerd. Deze manier is niet vastgelegd in proces beschrijvingen of andere documentatie waarin dit kan worden vastgelegd. De oorzaak dat het proces nog niet is vastgelegd heeft te maken met dat het label Actief nog officieel bekend is gemaakt.

5.2.1 Aanmelden initiatief (Proces 1)

Voor het aanmelden van een activiteit worden door de FCC medewerkers de gegevens van de aanmelder/klant doorgegeven aan de Actief medewerker. De Actief medewerker neemt contact op met de klant en bespreekt het initiatief. Als het initiatief volgens de interpretatie van de Actief medewerkers voldoet, wordt er met de klant afgesproken dat Florence de activiteit verder gaat uitwerken. Tijdens het contact wordt er aan de medewerker gevraagd of hij nog voorkeuren heeft voor tijdstip, duur, frequentie, locatie en kosten.

5.2.2 Aanmelden voor activiteit (Proces 2)

Wanneer de klant het FCC contacteert, worden de gegevens van de klant opgeschreven en doorgezet naar Actief. De FCC-medewerker verbindt de klant door met een medewerker van Actief of geeft aan dat de klant op een later tijdstip zal worden teruggebeld door een Actief medewerker. Wanneer de Actief medewerker contact heeft met de klant wordt de aanmelding geregistreerd in een Excel-document of tijdelijk op een papieren lijst.

5.2.3 Organiseren van activiteit (Proces 3)

Wanneer de Actief medewerker de activiteit verder heeft uitgewerkt, wordt er telefonische contact opgenomen met de klant. Vervolgens wordt er een voorstel gedaan aan de klant en wordt overlegd of tijdstip, duur, frequentie, locatie en kosten voldoen. Wanneer de initiatiefnemer met de activiteit akkoord gaat. Wordt door de Actief medewerker de PR/marketing geregeld voor de betreffende activiteit. Daarnaast wordt het FCC op de hoogte gebracht over de binnenkort beschikbare activiteit en ontvangen ze de informatie die ze nodig hebben. Het komt weleens voor dat een medewerker van Actief contact legt met een klant, die ze de vorige keer niet heeft kunnen helpen aan een activiteit. Deze klantgegevens zoekt zij dan op, dit kan op de computer/mail staan, maar kan ook opgeschreven zijn op een papierenlijst.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 15

6 GAP In dit hoofdstuk wordt beschreven welke grote GAP’s er zijn tussen de AS IS en de TO BE situatie. Deze GAP’s zullen terug te zien zijn in de uitwerking van hoofdstuk 7 TO BE | Gewenste situatie. Het gaat hier om de “grote” verbeterpunten. Achter de GAP staat dik gedrukt waar de GAP het meest voorkomt, staat er Florence Actief dan omvat het alle processen van de huidige situatie.

1. Binnen Florence is Actief nog niet officieel ingeregeld, hierdoor heeft het ook nog geen officiële status naar de buitenwereld. Wel worden er activiteiten aangeboden aan het kennisnetwerk van Florence, hierdoor worden de toekomstige klanten niet benaderd. Florence Actief

2. De huidige medewerkers van actief werken niet volgens een bepaald proces. Gegevens zijn

nu niet geordend en het werk gebeurt op een niet beschreven manier. Voor registratie worden nu overzichten in Excel gebruikt en contactgegevens worden opgeslagen in Outlook. Contact met de klant vindt telefonisch en via e-mail plaats. Florence Actief

3. Florence Actief werkt nog niet met een CRM-systeem, waardoor nu alles wordt opgeslagen

in Outlook, lijstjes van Word en Excel. Florence Actief

4. Daarnaast is er ook niet een duidelijk overzicht van de lopende activiteiten en zijn toekomstige activiteiten niet duidelijk opgeslagen. Proces 3 (Organiseren van activiteit)

5. Checklijsten zijn niet beschikbaar voor het starten van een activiteit. Het opstellen van een

checklist voorkomt dat er taken worden overgeslagen en taken op de juiste wijze worden afgerond. Proces 3 (Organiseren van activiteit)

6. Binnen het Actief team zijn tot nu toe geen verantwoordelijkheden vastgelegd. In

samenspraak worden nu de taken uitgevoerd. Hierdoor bestaat de kans dat zaken dubbel worden gedaan of dat ze niet worden uitgevoerd. Proces 3 (Organiseren van activiteit)

7. De architectuur is niet vastgelegd voor het label Actief. Binnen Florence is wel de gehele

architectuur vastgelegd door een extern bedrijf. Helaas wordt deze door de organisatie niet begrepen. Het systeem wat voor Florence Actief moet worden opgesteld is dus niet opgenomen in de huidige architectuur plaat. Florence Actief

8. Voor de klant en de medewerkers is niet helder welke informatie wanneer nodig is, omdat er

geen duidelijke procesmodellen/werkinstructies beschikbaar zijn. Proces 1 (Aanmelden initiatief klant)

9. Daarnaast zijn er geen richtlijnen opgesteld over wanneer een activiteit zelfstandig is. Nu

moet dus op gevoel en interpretatie worden bepaald wanneer een activiteit zelfstandig is. Proces 3 (Organiseren van activiteit)

10. De planning met activiteiten ontbreekt. Het is niet duidelijk wanneer er activiteiten staan gepland en wie ernaar toe gaat. Proces 2 (Aanmelden voor activiteit)

11. Er is niet vastgelegd wie het contact onderhoudt voor de activiteiten die onder een bepaald thema vallen. Nu gebeurt dit ongestructureerd. Proces 3 (Organiseren van activiteit)

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 16

12. Er is geconstateerd dat de communicatie tussen de FCC en medewerkers Actief niet optimaal verloopt. Florence Actief

13. Richtlijnen voor het goedkeuren van een initiatief ontbreken. Proces 1 (Aanmelden initiatief klant)

14. Geen mogelijkheid voor inschrijving via een ander medium dan de telefoon of mail. Proces 1 (Aanmelden initiatief klant) Proces 2 (Aanmelden voor activiteit)

15. Screenen van activiteiten vindt niet bewust plaats door middel van richtlijnen Proces 3 (Organiseren van activiteit)

Al deze GAP’s veroorzaken dat het werk niet makkelijk door andere personen kan worden overgenomen en dat het label Actief nu afhankelijk is van de huidige medewerkers van Actief. De oplossingen van de GAP’s zijn verwerkt in de processen en interventies.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 17

7 TO BE | Gewenste situatie

7.1 Beschrijving organisatie

7.1.1 Cultuur STMC

Voor de veranderingen die er binnen Florence plaatsvinden hebben wij samen met de

Opdrachtgever Martin het STMC-model ingevuld. Dit model richt zich op de veranderde organisatie

met het uitrollen van het label Actief.

Structuur

Organisatie Extra label binnen Florence.

Proces Er komen werkzaamheden en verantwoordelijkheden bij Voor activiteitenbegeleiders, medewerkers FCC.

Technologie

IT CRM-systeem

Kennis Checklist

Medewerkers

Competenties Er is extra kennis over het label Actief Breder gaan denken Netwerken met partners

Cultuur

Mindset van kwetsbaarheid naar gezondheid Zakelijk omgaan met organiseren activiteiten.

Tabel 2 Veranderingen label Actief

Na de toepassing van het advies is het primaire proces hetzelfde gebleven voor 90 % van de

medewerkers . Het label Actief is enkel een uitbreiding van de diensten die Florence te bieden heeft.

De structuur is uitgebreid, er zijn vier labels, daarnaast zijn er medewerkers in de vorm van

activiteitenbegeleiders. Ten slotte zijn er processen, waarvan wij er drie hebben ontworpen.

Qua technologie haakt het label Actief mooi aan, aan het Florence brede CRM-systeem. Om een

goed functionerend CRM-systeem te hebben voor de hele organisatie zijn hiervoor de requirements

geïmplementeerd. Daarnaast is er een checklist, zodat er eenduidige beslissingen gemaakt worden

en interpretaties of gevoel minder meespelen.

Voor de medewerkers is het van belang dat zij op de hoogte zijn van de werking van het label Actief.

Dit om als front-office te fungeren bij vragen van ouderen. Zo helpen zij bij het aanmelden van een

klant.

De cultuur van Florence staat voor gezondheid en zorg, aan het onderdeel zorg wordt al veel

aandacht en tijd besteedt nu wordt gezondheid aangesproken. Dit zorgt ervoor dat medewerkers

niet alleen meer bezig zijn met de zorg maar ook met de vitaliteit van de ouderen. Wat kunnen zij

nog wel?

Daarnaast beoordeeld de Actief medewerker de activiteit met behulp van de opgestelde

beslisbomen.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 18

7.2 Processen

Voor het nieuwe label actief, hebben wij een drietal processen gedefinieerd, namelijk:

- Aanmelden initiatief klant - Aanmelden voor activiteit - Organiseren van activiteit

Deze processen zullen in dit hoofdstuk behandeld worden. Eerst zal het procesmodel getoond worden. Omdat een procesmodel soms om verduidelijking vraagt, hebben wij de procesmodellen voorzien van een procesbeschrijving. Deze volgt na het model. Een voorbeeld van een procesbeschrijving is hieronder te zien.

Hieronder volgt een toelichting op de verschillende kolommen van de procesbeschrijving: # Dit is het nummer van de processtap die overeenkomt met het

nummer in het procesmodel.

Naam processtap Dit is de naam van de processtap, ook deze komt overeen met de naam in het procesmodel.

A/B/P/S In deze kolom wordt één van de volgende letters neergezet. Deze letters geven aan wat voor processtap het is. De A staat voor activiteit, dit zijn de meeste stappen. De B staat voor beslispunt, deze letter wordt gebruikt wanneer er een beslissing wordt gemaakt. De P staat voor proces, dit betekent dat er wordt verwezen naar een extern proces. De S staat voor een systeemstap.

Input In de kolom input wordt mogelijke input, die van belang is bij de processtap, vermeld.

Handelingen in activiteit

In deze kolom volgt een beschrijving van wat er in de processtap gebeurt. Deze beschrijving dient als verdieping van de stap zelf. Ook kunnen hier andere belangrijke handelingen of informatie staan vermeld.

Output Hier wordt de mogelijke output van de processtap vermeld.

Systeem Hier worden de gebruikte systemen of programma’s, die nodig zijn bij de processtap, neergezet.

# Naam processtap

A/B/P/S Input Handelingen in activiteit / Beslissing

Output Systeem R A S C I Functionaris(sen) Afhandeltijd

1.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 19

R Responsible. Degene die verantwoordelijk is voor de uitvoering.

Verantwoording wordt afgelegd aan de persoon die accountable is.

A Accountable. Degene die (eind)verantwoordelijk, bevoegd, is en goedkeuring geeft aan het resultaat. Als het erom gaat, moet hij/zij het eindoordeel kunnen vellen, vetorecht hebben. Er is slechts één persoon Accountable.

S Supported. Deze persoon is ondersteunend bij de uitvoering van het resultaat.

C Consulted. Deze persoon geeft (mede) richting aan het resultaat, hij/zij wordt voorafgaand aan beslissingen of acties (verplicht) geraadpleegd. Dit is tweerichtingcommunicatie.

I Informed. Iemand die geïnformeerd wordt over de beslissingen, over de voortgang, bereikte resultaten enz. Dit is eenrichtingscommunicatie.

Functionaris(sen) In dit veld wordt de bijbehorende rol genoemd. Zo is te zien welke rol in dit proces responsible of accountable is.

Afhandeltijd De afhandeltijd is een optioneel veld. Dit veld wordt alleen ingevuld wanneer het van belang is.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 20

Procesmodel 1: Aanmelden initiatief klant

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 21

Procesbeschrijving 1: Aanmelden initiatief klant # Naam processtap A/B/P/S Input Handelingen in activiteit / Beslissing Output Systeem R A S C I Functionaris(sen) Afhandeltijd

1. Te woord staan klant

A Initiatief voor activiteit van klant

De medewerker van het FCC (Florence contactcenter) staat de klant/cliënt te woord.

Behoefte registratie klant

Telefoon CRM Actief

x Medewerker FCC

x Coördinator FCC

2. Registeren gegevens

A Niet geregistreerde klant/cliënt

De FCC-medewerker registreert de volgende gegevens van de klant/cliënt:

- Naam + achternaam; - Adresgegevens; - Woonplaats; - Contactgegevens; - Overige benodigde gegevens.

Geregistreerde klant/cliënt Klantgegevens

CRM Actief x Medewerker FCC

x Coördinator FCC

3. Melding van nieuw initiatief

S Geregistreerde klant/cliënt Of Digitaal formulier

Het CRM-systeem van Actief geeft een melding aan een medewerker van Actief.

Melding nieuw initiatief

CRM Actief x Medewerker Actief

4. Contact opnemen klant

A Melding nieuw initiatief

Een medewerker van Actief neemt contact op met de klant/cliënt die een initiatief heeft aangemeld.

Telefoon x Medewerker Actief

x Directeur cliëntprocessen

5. Bespreken initiatief met klant

A Initiatief voor activiteit

Een medewerker van Actief bespreekt het initiatief met de klant/cliënt. Hierbij controleert de medewerker of:

- De activiteit al bestaat; - De activiteit mogelijk is; - De aanvraag compleet is.

Ten slotte deelt de medewerker van Actief de nieuwe activiteit in bij een van de volgende thema’s:

- Sport - Hobby's:

o Binnen o Buiten

- Cultuur - Natuur - Culinair - Digitaal - Erop uit

Telefoon x Medewerker Actief

x Directeur cliëntprocessen

x x Initiatiefnemer

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 22

6. Activiteit goedgekeurd?

B Zo ja: Ga door naar stap 7 (registeren activiteit) Zo nee: Doe de klant/cliënt een voorstel voor een alternatieve activiteit. Het proces van “aanmelden voor activiteit” is in een extern proces uitgewerkt.

CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

x Initiatiefnemer

Extern proces: Aanmelden voor activiteit

P Het proces voor het “aanmelden voor activiteit” is in een ander procesmodel uitgewerkt.

7. Registreren activiteit

A Wanneer de activiteit aan alle voorwaarden van stap 5 voldoet en is goedgekeurd, zal een medewerker van Actief het initiatief definitief in het CRM-systeem registreren.

Activiteit CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

x Initiatiefnemer

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 23

Procesmodel 2: Aanmelden voor activiteit

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 24

Procesbeschrijving 2: Aanmelden voor activiteit

# Naam processtap A/B/P/S Input Handelingen in activiteit / Beslissing Output Systeem R A S C I Functionaris(sen) Afhandeltijd

1. Te woord staan klant

A Klant is geïnteresseerd in activiteit

De FCC medewerker staat de klant/cliënt te woord. Registreren klant

Telefoon CRM Actief

x Medewerker FCC

x Coördinator FCC

2. Registeren gegevens

A Registreren klant

De FCC medewerker registreert, indien niet beschikbaar, de volgende gegevens van de klant/cliënt:

- Naam + achternaam; - Adresgegevens; - Woonplaats; - Contactgegevens.

Geregistreerde klant/cliënt Klantgegevens

CRM Actief x Medewerker FCC

x Coördinator FCC

x Klant/Cliënt

3. Melding van inschrijving

S Geregistreerde klant/cliënt Of Digitaal formulier

Het CRM-systeem geeft een melding aan een medewerker van Actief.

Melding van inschrijving

CRM Actief x Medewerker Actief

4. Digitale inschrijving B Ingeschreven klant

Is de inschrijving digitaal? Zo ja: ga verder met stap 5. Zo nee: ga verder met stap 6.

5. Versturen van bevestiging

S Ingeschreven klant

Het systeem stuurt een bevestigingsmail naar de ingeschreven klant.

Bevestigde inschrijving

CRM Actief x Klant

6. Contacteren klant B Inschrijving Een medewerker van Actief neemt contact op met de klant. Telefoon x Medewerker Actief

x Directeur cliëntprocessen

7. Bevestigen van inschrijving

A

Bevestigde inschrijving Inschrijving

CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

8. Afronden gesprek A De medewerker van Actief rond het gesprek met de klant af.

Telefoon CRM Actief

x Medewerker Actief

x Directeur cliëntprocessen

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 25

Procesmodel 3: Organiseren van activiteit

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 26

Procesbeschrijving 3: Organiseren van activiteit # Naam processtap A/B/P/S Input Handelingen in activiteit / Beslissing Output Systeem R A S C I Functionaris(sen) Afhandeltijd

1. Screenen activiteit A Aangemelde activiteit

De medewerker Actief:

- Controleert of de activiteit bij het juiste thema hoort

- Controleert of de activiteit haalbaar is.

Gescreende activiteit

CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

2. Akkoord? B Gescreende activiteit

De medewerker van Actief bepaalt of de activiteit akkoord is. Is de activiteit akkoord? Zo ja: vervolg met stap 3 Zo nee: de klant wordt op de hoogte gesteld van de afgewezen aanvraag

Activiteit akkoord of afgewezen

CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

x Initiatiefnemer

3. Opstellen planning A Geaccordeerde activiteit

Een medewerker van Actief stelt een planning op voor de nieuwe activiteit. Bij de planning van de activiteit wordt er rekening gehouden met:

- Locatie - Tijd - Randvoorwaarden - Frequentie - Kosten - Capaciteit Florence

Planning voor activiteit

CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

x x Initiatiefnemer

Extern proces: Benadering doelgroep

P Activiteit en planning

De PR afdeling van Florence zorgt voor het benaderen van de doelgroep.

x PR marketing

Extern proces 2: Aanmelden voor activiteit

P Proces 2: Aanmelden voor activiteit, is uitgewerkt in een ander procesmodel.

Inschrijvingen CRM Actief

4. Screenen inschrijvingen

A Inschrijvingen De inschrijving worden gescreend op:

- Compleetheid - Locatie - Inschrijfgegevens

Deelnemers CRM Actief x Medewerker Actief

x Directeur cliëntprocessen

5. Deelnemers B Er wordt bepaald hoeveel deelnemers er zijn. Dit levert de volgende drie mogelijkheden op. Te weinig: ga terug naar het benaderen van de doelgroep. Dit gebeurt maximaal 3 keer, echter wanneer er na de eerste keer zeer weinig interesse is, dan wordt de activiteit opgeheven.

x Medewerker Actief

x Directeur cliëntprocessen

x x Deelnemers

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 27

Te veel: er zijn hierbij twee mogelijkheden: 1. Er wordt een selectie* gemaakt van de

aangemelde deelnemers. In dien mogelijk, worden er meerdere groepen opgericht.

2. Deelnemers wordt een voorstel gedaan voor een alternatieve/overeenkomende activiteit.

Genoeg: ga verder met stap 6. *: de initiatiefnemer(s) is/zijn altijd ingedeeld bij hun eigen activiteit.

6. Informeren klant A De klant/cliënt wordt op de hoogte gebracht van zijn of haar

deelname aan de activiteit.

x Medewerker Actief

x Directeur cliëntprocessen

x Deelnemers

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 28

7.3 Architectuurontwerp Om de architectuur voor het label Actief binnen Florence in kaart te brengen, hebben wij gebruik gemaakt van de tool “ArchiMate”. ArchiMate is een modelleertaal voor Enterprise Architectuur (EA), gebaseerd op open standaarden. Hieronder is het model voor het label Actief te zien.

Business layer Bovenin het model is de bedrijfslaag (geel) te zien, in deze laag staan de bedrijfsprocessen en diensten en de onderlinge relatie die deze met elkaar hebben. In de bedrijfslaag zien wij de business processen terug. Een bedrijfsproces beschrijft het interne gedrag van ‘klant tot klant’. De bedrijfsprocessen die in het schema te zien zijn, komen overeen met de processen van hoofdstuk 7.2 , namelijk:

- Registreren van klant - Aanmelden initiatief - Aanmelden voor activiteit

De meest rechter processen hebben betrekking op het beginnen en het afronden van een activiteit. Deze processen zijn niet gekoppeld aan de klant, maar zijn interne processen van het label Actief.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 29

Te zien is, dat deze processen door middel van services gekoppeld worden naar de klant. Een bedrijfsservice is een extern zichtbare functionaliteit die een bedrijfsproces, -functie of -interactie levert aan een klant (intern of extern). In dit model zijn de volgende business services gebruikt:

- Informatieservice - Registratieservice - Service aanmelden van initiatief - Service aanmelden voor activiteit

De processen leveren business objects op. Een bedrijfsobject is een eenheid van informatie die relevant is vanuit het gezichtspunt van een bedrijf. Dit model kent de volgende business objects, namelijk:

- Registratie - Initiatief - Activiteit

Application layer In het midden van het model (blauw) is de applicatielaag beschreven. In de applicatielaag wordt het informatielandschap beschreven, dit bestaat onder meer uit de software en informatieprocessen. Voor de nieuw ingerichte processen, zijn verschillende functies binnen het CRM-systeem vereist. Dit wordt aangegeven door middel van een application function: het interne gedrag, of de functionaliteit, dat door een applicatiecomponent wordt uitgevoerd. De requirements voor deze functies binnen het CRM-systeem zijn opgenomen in hoofdst.

- Registreren - Aanmelden - Organiseren

De applicaties, oftewel functies van het systeem, die wij hierboven hebben besproken zijn gekoppeld aan services. Dit zijn extern zichtbare functionaliteiten, die geleverd worden door een applicatiefunctie, die toegevoegde waarde biedt aan de omgeving.

Een application component is een modulair, zelfstandig inzetbaar en vervangbaar gedeelte van een systeem, dat intern een verzameling functies realiseert en beschikbaar stelt. In dit ontwerp hebben wij twee applicatiecomponenten gedefinieerd, namelijk:

- Website - CRM Actief

- Registratieservice

- Service aanmelden van initiatief

- Service aanmelden voor activiteit

- Service beginnen activiteit

- Service beëindigen activiteit

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 30

Een data object is bijna gelijk aan een business object, echter is een business object fysiek. Een data object is een set van gegevens wat in een systeem of applicatie wordt opgeslagen.

- Klant - Activiteit - Partner - Medewerker

Technology layer Onderaan het model, in het groen, is de technische laag te zien. In deze laag gaat het voornamelijk over de hardware en de communicatie-infrastructuur. Een “Node” (letterlijk: knooppunt) is een systeem of server waarop de gekoppelde applicatiecomponenten draaien. In dit model kennen wij de volgende “Nodes”, namelijk:

- Webserver - CRM - Gemeente

Een infrastructure service kan gebruikt worden voor de koppeling tussen een Node en een applicatie component. Dit is echter niet verplicht, maar wordt vaak ter verduidelijking gedaan.

- Webservice

Een infrastructure interface laat de koppelingen zien tussen infrastructure services en “Nodes”. Echter kunnen ook twee “Nodes” aan elkaar gekoppeld worden. Deze koppelingen zorgen ervoor dat application components informatie vanuit andere systemen of servers kunnen halen.

- Koppeling: Webserver met CRM - Koppeling: CRM met gemeente

Een Device is een apparaat (hardware) waarmee de informatie vanuit de systemen is te benaderen. In dit model hebben wij gekozen voor twee soorten apparaten, namelijk:

- Smartphone - Desktop

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 31

8 Requirements CRM-systeem

Om de ideale situatie te verwezenlijken speelt de inrichting van het nieuwe CRM-systeem een

cruciale rol. Belangrijk is dat het systeem voldoet aan de behoeften die vanuit de medewerkers en

het ontworpen proces naar boven zijn gekomen. Bij de totstandkoming van deze behoeften hebben

wij interviews afgenomen en gebrainstormd met het projectteam. Daarnaast zijn er gedurende het

project requirements bijgekomen vanuit de ontworpen processen en architectuurplaat. Als laatste

zijn er enkele requirements toegevoegd die niet vanuit de medewerkers of het proces komen, dit

zijn enkele aannames die wij doen.

Om de requirements duidelijk gestructureerd te laten weergeven hebben zijn deze verdeeld in:

- Businessrequirements, dit zijn de doelen van zowel de opdrachtgever als van de gebruiker.

Deze bepalen de scope van het systeem. Wanneer een gebruikersrequirement niet onder

een businessrequirement gehangen kan worden valt deze buiten de scope.

- Gebruikersrequirements, dit zijn (sub)processen, taken of activiteiten die de gebruiker met

behulp van het systeem wil uitvoeren.

- Software-requirements, dit is het gedrag/ de actie die het systeem moet uitvoeren om in de

behoefte van de gebruiker te voorzien.

8.1 Business requirements De business requirements bestaan uit de doelen die de opdrachtgever en de gebruiker hebben met

de ontwikkeling van het systeem. Deze requirements tonen op een hoog niveau wat het doel is van

het systeem. Achter elk businessrequirement zal getoond worden waarop de requirement

gebaseerd is en als laatste welke softwarerequirements aan deze businessrequirement invulling

geven.

Nr. B - Requirement omschrijving Traceability Nr. van S-requirements

1 De opdrachtgever wil overzicht krijgen van alle activiteiten binnen het label Actief

Interview Martin Oosterheert

4, 5, 12, 15,

2 De opdrachtgever wil overzicht van de effectiviteit van marketingacties

Interview Martin Oosterheert

5, 9

3 De opdrachtgever wil dat de klanten activiteiten zelf kunnen aanmelden

Interview Martin Oosterheert

2, 6, 7, 14, 17

4 De opdrachtgever wil dat potentiële klanten (deelname aan) activiteiten op verscheidene wijze kunnen aanmelden/annuleren

Interview Martin Oosterheert

1, 2, 3, 6, 7, 11, 16, 17, 18

5 De opdrachtgever wil de deelname aan activiteiten en interesses van de klant volgen om deze optimaal te kunnen faciliteren

Interview Martin Oosterheert

1, 3, 5, 8, 9, 10, 11, 14

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 32

6 De klant wil duidelijkheid over de aanmelding van/voor een activiteit

Interview Martin Oosterheert

17, 19

7 De medewerker Actief wil de gegevens van partners uit het systeem kunnen halen

Interview medewerker Actief

Architectuurmodel

4, 13

8.2 Gebruikers requirements Aansluitend op de businessrequirements volgen de gebruikersrequirements. Deze requirements

tonen de (sub)processen, taken en activiteiten die de gebruikers met behulp van het systeem willen

uitvoeren. Deze gebruikers bestaan uit:

- De opdrachtgever Martin Oosterheert

- Medewerkers Florence Contact Centrum

- Medewerkers Actief

- Medewerkers Pr-marketing

- Klanten voor het label Actief

Van elk requirement wordt weergeven: - Een omschrijving

- Van welke gebruiker deze requirement komt(Traceability)

- In welk proces deze van belang is(Traceability)

- Waarom deze requirement van belang is(Motivatie)

- Welk softwarerequirement hieraan gekoppeld is (Nr. van S-requirements)

Wij hebben drie processen ontworpen namelijk:

1. Aanmelden initiatief hoofdstuk 7.2 (proces 1)

2. Aanmelden voor activiteit hoofdstuk 7.2 (proces 2)

3. Organiseren van activiteit hoofdstuk 7.2 (proces 3)

Bij de traceability hebben wij deze toegevoegd als proces 1, 2 & 3.

Nr. G - Requirement omschrijving Traceability Motivatie Nr. van S-requirements

1 De klant wil zich via de website kunnen aanmelden voor een activiteit

Interview Ronneke Kieboom

Proces 2

Deze manier vraagt het minste tijd van de Florence medewerker

2, 11, 14, 17

2 De klant wil via de website een activiteit kunnen aanmelden.

Interview Ronneke Kieboom

Proces 1

Deze manier vraagt het minste tijd van de Florence medewerker

2, 11, 14, 17

3 De medewerker FCC wil per klant de NAWTE-gegevens kunnen registreren.

Interview Ronneke Kieboom

Proces 1 & 2

Voor de verdere stappen in het proces is het nodig om de gegevens van de klant te hebben.

1, 3, 7

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 33

4 De medewerker Actief wil dat het FCC per klant kan aangeven of hij mentaal of fysiek beperkt is.

Interview Actief medewerkers

Proces 1 & 2

Voor de verdere stappen in het proces is het nodig om deze gegevens van de klant te hebben.

8

5 De medewerker van het FCC wil per klant kunnen registreren binnen welke thema’s zijn interesses vallen.

Interview Ronneke Kieboom

Proces 1 & 2

Voor het maken van rapportages en bereiken van de doelgroep essentieel.

10

6 De medewerker Actief moet zien of de aanmelding via de website of telefoon is gedaan.

Aanname

Proces 2

Dit is nodig omdat er in het proces een verschil in de vervolgstappen zit.

11

7 De medewerker Actief wil in het systeem een planning kunnen maken.

Interview medewerker Actief

Proces 3

In deze planning wil zij een duidelijk overzicht van de activiteiten.

12

8 De medewerker Actief wil in het systeem de gegevens van de partners hebben.

Interview medewerker Actief

Proces 3

Voor de organisatie van nieuwe activiteiten bespaart het veel tijd.

13

9 De Medewerker Actief wil dat de aanmelding voor/van een activiteit alleen kan als alle gegevens ingevuld zijn.

Interview medewerker Actief

Proces 1 & 2

Voor de vervolgstappen in het proces is het nodig om de gegevens van de klant te hebben.

14

10 De medewerker van het FCC wil in het systeem kunnen zien welke activiteiten er openstaan.

Interview Ronneke Kieboom

Proces 1 & 2

Hierdoor kunnen zij vragen van klanten over activiteiten beantwoorden.

15

11 De medewerker Actief wil in de planning de specificaties van een activiteit zien.

Aanname

Proces 3

Hierdoor kan de medewerker snel zien op welke activiteit actie ondernomen moet worden.

4

12 De klant wil dat zijn aanmelding voor een activiteit geannuleerd kan worden.

Aanname

Omdat de activiteiten vrijwillig zijn moet de klant zich ook kunnen uitschrijven voor een activiteit.

16

13 De opdrachtgever wil rapportages over het:

- Aantal deelnemers per thema

Martin Oosterheert

Dit helpt hem bij de ontwikkeling en verdere uitbreiding van het label Actief.

5

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 34

- Aantal activiteiten per thema

- Via welk kanaal de klant bekend is geworden met Actief

14 Klant wil een bevestiging van zijn registratie.

Martin Oosterheert

Proces 1 & 2

De klant wil na zijn aanmelding van/voor een activiteit een bevestiging via de mail.

19

15 De medewerker van het FCC moet kunnen registreren hoe de klant in contact is gekomen met Actief.

Martin Oosterheert

Proces 1 & 2

Martin wil weten welke op welke manier de doelgroep het meest effectief en efficiënt wordt benaderd.

5, 9

16 De medewerkers van Florence moeten gegevens van bestaande klanten kunnen opvragen.

Medewerker Actief

Proces 1, 2 & 3

De medewerkers willen van de klanten kunnen volgen hoe hij/zij betrokken is bij Actief.

1, 2, 3, 7,

17 De medewerkers willen per activiteit zien hoeveel aanmeldingen er zijn.

Aanname De medewerkers van Actief kunnen op basis hiervan beslissen of een activiteit kan starten.

18

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 35

8.3 Software requirements De softwarerequirements komen tot stand uit de behoeftes van zowel de business als de gebruikers van het systeem. Naast de behoeftes van de business en gebruikers zullen ook nuttige aannames worden verwerkt in het systeem. Hierdoor wordt het systeem zo volledig mogelijk. Om te zien of een softwarerequirement tot stand is gekomen uit een business- of gebruikersrequirement of uit beide, zijn twee kolommen toegevoegd. Tevens is onderscheid gemaakt tussen functionele en niet functionele requirements. De functionele requirements beschrijven de capaciteiten van het systeem. De niet functionele requirements beschrijven de kwaliteitseisen waaraan het systeem moet voldoen.

Nr. S - Requirement omschrijving

Traceability Wat wil de opdrachtgever?

Nr. van B requirements

Nr. van G requirement

1 Het systeem moet de NAWTE-gegevens van klanten opslaan.

Interview Actief medewerkers

Proces 1, 2 & 3

Voor de verdere stappen in het proces is het nodig om de gegevens van de klant te hebben.

4, 5 3, 16

2 Het systeem moet aanmeldingen, voor en van activiteiten, via de website binnenkomen kunnen verwerken.

Interview Actief medewerkers

Proces 1 & 2

Deze manier vraagt het minste tijd van de Florence medewerker

3, 4 1, 2, 16

3 Het systeem moet gegevens van bestaande klanten kunnen tonen.

Interview Actief medewerkers

Proces 1, 2 & 3

Voor de verdere stappen in het proces is het nodig om deze gegevens van de klant te hebben.

4, 5 3, 16

4 Het systeem moet per activiteit in de planning tonen:

Naam initiatiefnemer, Max/min groepsgrootte, Kosten Florence, Locatie, Frequentie, Partner, Starttijd en eindtijd

Martin Oosterheert en Ronneke Kieboom

Proces 1, 2 & 3

Hierdoor kan de medewerker snel zien op welke activiteit actie ondernomen moet worden.

1, 7 11

5 Het systeem dient een rapportage te kunnen maken van :

- Aantal deelnemers per thema

- Aantal activiteiten per thema

Martin Oosterheert

Dit helpt hem bij de ontwikkeling en verdere uitbreiding van het label Actief.

Martin wil weten welke op welke manier de doelgroep het

1, 2, 5 13, 15

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 36

- Via welk kanaal de klant bekend is geworden met het label Actief

- Alle openstaande activiteiten

meest effectief en efficiënt wordt benaderd.

6 Het systeem moet mogelijk maken dat klanten een of meerdere initiatieven kunnen registreren.

Proces 1 & 2 Dit is nodig omdat er in het proces een verschil in de vervolgstappen zit.

3, 4 6

7 Initiatieven moeten zowel aan nieuwe als bestaande klanten gekoppeld kunnen worden.

Proces 1 & 2 De medewerkers willen van de klanten kunnen volgen hoe hij/zij betrokken is bij Actief.

3 3, 16

8 Het systeem moet mogelijk maken dat per klant geregistreerd kan worden of hij/zij mentaal/fysieke beperkingen heeft.

Proces 1 & 2 Voor de verdere stappen in het proces is het nodig om deze gegevens van de klant te hebben.

5 4

9 Het systeem moet kunnen registreren op welke manier de klant bekend is geworden met Actief.

Martin Oosterheert

Proces 1 & 2

Martin wil weten welke op welke manier de doelgroep het meest effectief en efficiënt wordt benaderd.

2, 5 15

10 Het systeem moet kunnen registreren binnen welke thema’s de interesses van de klant liggen.

Martin Oosterheert,

Medewerkers actief

Ronneke Kieboom

Proces 1, 2 & 3

Voor het maken van rapportages en bereiken van de doelgroep essentieel.

5 5

11 Het systeem moet kunnen registreren of de aanmelding via de telefoon of de website is

Proces 1, 2 & 3 Dit is nodig omdat er in het proces een verschil in de

4, 5 1, 2, 6

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 37

gedaan. vervolgstappen zit.

12 In het systeem moet de medewerker Actief een planning kunnen maken.

Proces 3 In deze planning wil zij een duidelijk overzicht van de activiteiten.

1 7

13 Het systeem moet de gegevens van de partners op kunnen slaan.

Proces 3 Voor de organisatie van nieuwe activiteiten bespaart het veel tijd.

7 8

14 Het systeem moet de aanmelding pas opslaan als alle gegevens zijn ingevuld.*

Proces 1 & 2 Voor de vervolgstappen in het proces is het nodig om de gegevens van de klant te hebben.

5 1, 2, 9

15 Het systeem moet een overzicht geven van alle aangemelde, openstaande en lopende activiteiten.

Martin Oosterheert

Proces 3

Hierdoor kunnen zij vragen van klanten over activiteiten beantwoorden.

1 10

16 Het systeem moet de mogelijkheid hebben om aanmeldingen te annuleren.

Aanname Omdat de activiteiten vrijwillig zijn moet de klant zich ook kunnen uitschrijven voor een activiteit.

4 12

17 Het systeem moet een bij de medewerker Actief een melding geven bij een aanmelding.

Martin Oosterheert

Proces 3

Deze manier vraagt het minste tijd van de Florence medewerker

3, 4 1, 2

18 Het systeem dient van elke activiteit aan te geven hoeveel deelnemers er zijn.

Proces 1, 2 & 3

De medewerkers van Actief kunnen op basis hiervan beslissen of een activiteit kan starten.

4 17

19 Het systeem dient de klant een bevestiging te sturen wanneer de aanmelding

Martin Oosterheert

De klant wil na zijn aanmelding van/voor een

6 14

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 38

van/voor een activiteit succesvol is afgerond.

Esmee Orta

Proces 1 & 2

activiteit een bevestiging via de mail.

*dit betekend dat minimaal is ingevuld: - Voornaam, achternaam; - Adres, postcode; - Woonplaats; - Telefoon en/of email; - Aanmelden nieuwsbrief ja/nee; - Wilt uw meldingen voor nieuwe activiteiten? Ja/nee; - Fysiek en/of mentaal beperkt ja/nee; - Via welk kanaal is de klant bekent met Actief geworden.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 39

9 Interventies In dit hoofdstuk worden de interventies beschreven van de AS IS naar de TO BE. Florence heeft een witte en rode cultuur volgens de cultuurtypering van Caluwé. Dit betekent dat de

interventies niet op een strakke en gestructureerde wijze uitgevoerd moeten worden, maar juist op

een gezamenlijke speelse manier dat leuk is voor de medewerkers. Hiervoor zijn verschillende

soorten interventies mogelijk, een effectieve interventie is een rollenspel. Om dit uit te voeren zijn

verschillende rollen nodig, namelijk:

- Actief medewerker;

- Klant;

- Coördinator;

- Activiteitenbegeleider;

Voor het proces “aanmelden initiatief klant’’ en “aanmelden voor een activiteit’’ speelt de Actief

medewerker en de klant zijn rol. En voor het proces “organiseren van een activiteit’’ speelt de klant

en activiteitenbegeleider een andere rol.

Hieronder zijn nog een aantal interventies die speciaal gericht zijn op Florence:

- Een aantal informele besprekingen tijdens lunch; tijdens een aantal lunches kort bespreken

hoe de nieuwe verandering in elkaar zit. Er worden ook werkinstructies uitgedeeld om het

thuis na te lezen. Na een aantal besprekingen is iedereen op de hoogte, en kan er door

middel van een rollenspel een beter beeld gecreëerd worden.

- Interactieve workshop; een interactieve workshop is een goede interventie om ervoor te

zorgen dat medewerkers begrijpen hoe de processen in elkaar zitten. Gezamenlijk worden

alle stappen van de processen doorgenomen. Bij de presentatie worden eerst de processen

in kaart gebracht en vervolgens kunnen de medewerkers in teams het proces naspelen.

- Posters; dit is een interventie die gebruikt moet worden in combinatie met andere

interventies. Met een poster zorg je er namelijk voor dat de medewerkers van Florence op

de hoogte zijn van het nieuwe label en dat ze daar aandacht aan moeten besteden.

- Filmpje; een kort filmpje is een andere eenvoudige manier om medewerkers te informeren.

Het is kort en krachtig. Het filmpje kan op allerlei manieren gemaakt worden, het kan

gemaakt worden door een rollenspel te filmen of zelf een simpele film te maken.

- Gamification; gamification is een ander soort methode die gebruikt kan worden. Door het

als een spel op te zetten, is het mogelijk om medewerkers te motiveren en belonen.

- Storytelling; bij storytelling gaat het om de doelgroep (Actief medewerkers) te informeren

en overtuigen door ingrijpende verhalen te vertellen. Dus de drie processen die uitgewerkt

zijn, moeten op een manier beschreven worden die ervoor zorgt dat medewerkers energie

en motivatie uit halen.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 40

8.1 Beslisbomen per proces Er zijn drie processen waar nog geen duidelijk richtlijnen voor zijn opgesteld:

- Wanneer is een activiteit zelfstandig;

- Wanneer starten met een initiatief;

- Wanneer stoppen met een activiteit;

Om dit op te lossen is er voor elk onderdeel een beslisboom gemaakt die gebruikt kan worden door

een Actief medewerker. Met dit hulpmiddel kan de medewerker gemakkelijk een aantal stappen

volgen en vervolgens een beslissing nemen.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 41

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 42

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 43

10 Advies Het advies dat wij willen meegeven voor Florence Actief heeft raakvlakken op vier onderdelen. Het is essentieel dat deze vier onderdelen allemaal worden uitgevoerd, zodat Florence Actief op de juiste wijzen kan functioneren. De vier onderdelen zijn als volgt:

- De processen; - CRM en requirements; - Interventies toepassen; - Cultuurverandering.

10.1 De processen De processen hoofdstuk 7.2; aanmelden initiatief klant, aanmelden voor activiteit en organiseren

van activiteit zijn tijdens het project door ons ontworpen. Deze processen moeten ervoor zorgen dat

er activiteiten worden georganiseerd die door de klanten van Florence zijn aangedragen. Door deze

drie processen te implementeren binnen Actief, zal er een gedocumenteerde werkwijze ontstaan.

Door een gedocumenteerde werkwijze is het werk inzichtelijk en hierdoor makkelijke

overdraagbaar.

10.2 CRM en requirements Wanneer het proces binnen Florence Actief is geïmplementeerd, kan er worden begonnen met het implementeren van het CRM-systeem met de bijbehorende requirements. Deze requirements zijn terug te vinden in hoofdstuk 8. Deze requirements zijn ontworpen vanuit het proces, het is daarom van belang dat deze requirements geïmplementeerd worden in het CRM-systeem. Op deze manier is het de bedoeling dat de medewerkers en het proces centraal staan binnen Actief. Het is niet de bedoeling dat het CRM-systeem leidend is. De implementatie van het proces, en de requirements die in het CRM-systeem moeten worden geïmplementeerd, kunnen in feite niet zonder elkaar. Het is dan ook ons advies om deze twee onderdelen tegelijkertijd te implementeren.

10.3 Interventies toepassen Wanneer het CRM-systeem geconfigureerd is en de requirements in het systeem zijn opgenomen, zal er voor gezorgd moeten worden dat het proces vlekkeloos verloopt. Hierbij kan gebruik gemaakt worden van de interventies die wij hebben voorgesteld in hoofdstuk 9. In dit hoofdstuk staan de interventies die zijn bedacht bij de GAP’s hoofdstuk 6. De GAP’s hebben wij tijdens ons onderzoek bij Florence Actief opgemerkt.

10.4 Cultuur verandering Wanneer alle bovenstaande punten zijn uitgevoerd, is het van belang om ook in de rest van de organisatie van gedachten te veranderen. De bedoeling is dat werknemers binnen Florence gaan denken in wat een cliënt zoal nog kan doen en niet in wat hij of zij juist niet meer kan. Dit vraagt dus een andere manier van denken van de medewerkers. De gedachte zou moeten zijn: ik ben gezond, hoe blijf ik dat! Dit alles moet ervoor zorgen dat Florence Actief een succes wordt, en de ouderen in de samenleving langer gezond blijven. Dit is dat ook de voornaamste doelstelling van Actief.

Adviesrapport V1.0 | De Haagse Hogeschool | Pagina 44

11 Conclusie In dit adviesrapport hebben wij gekeken naar de optimale situatie voor het nieuwe label Actief van Florence. Wij als projectgroep hebben met onze kennis vanuit de opleiding en met een frisse blik gekeken naar wat Florence wil bereiken. Wij zijn begonnen met het houden van interviews met de opdrachtgever en de betrokken medewerkers. Dit hebben wij gedaan om een goed beeld te krijgen van de organisatie en van de opdracht. Daarnaast hebben wij een cultuuranalyse uitgevoerd onder de medewerkers van actief. Deze analyse hebben wij uitgevoerd om een beeld te krijgen van de cultuur binnen het label actief. De uitkomst van deze analyse hebben wij gebruikt bij het bedenken van gepaste interventies. Ten tweede hebben wij een drietal processen voor het label Actief gemodelleerd. Dit hebben wij gedaan voor de volgende processen:

- Aanmelden van initiatief; - Aanmelden voor activiteit; - Organiseren van activiteit.

Deze processen hebben wij uitgewerkt in een procesmodel. Bij alle modellen hebben wij een procesbeschrijving geleverd. In deze beschrijving wordt het proces nader toegelicht, daarnaast zijn in deze beschrijving ook de verantwoordelijkheden per processtap vastgelegd. Bij een nieuw label komt meer kijken dan alleen nieuwe processen. Daarom hebben wij niet alleen naar de proceskant van de verandering gekeken, maar ook naar de verandering op ICT-gebied. De nieuwe infrastructuur voor het label hebben wij vastgelegd in een architectuurontwerp. Hierin is de koppeling tussen de ICT en de (business)processen te zien. Een nieuwe infrastructuur vraag om een nieuw systeem. Voor dit nieuwe (CRM)systeem zijn requirements opgesteld. Dit zijn vereisten waarin het systeem, in ieder geval, moet voldoen. Ten slotte hebben wij gekeken naar de interventies (handelingen) die nodig zijn om de gap (kloof tussen AS IS en TO BE) te overbruggen. Met dit adviesrapport ligt er een goede basis voor het label Actief. Hiermee kan het pull proces worden geactiveerd en kunnen ouderen hun eigen activiteiten aandragen.