1 Vrijgaveadvies Project SYSQA B.V. Almere Datum : Status : Versie : Opgesteld door :2 Organisatie Project Pagina 2 van 16 Inhoudsopgave 1 Managemen...
1 Management samenvatting Het advies van SYSQA B.V. live te gaan met de opgeleverde en geteste programmatuur per is negatief. De onderbouwing van dit advies komt voort uit de hieronder getoonde risico’s. Alleen de blokkerende en hoge risico’s worden getoond. De lage risico’s worden verderop in het document genoemd. De risico’s staan in volgorde van belangrijkheid: 1. 2. 3. 4. 5. 6. 7. 8.
Vitale applicaties niet beschikbaar Vitale koppelingen niet beschikbaar Performance Productieverstoringen Ontbreken gebruikersbeheer Beperkte gebruikers acceptatie Applicaties beperkt te beheren Applicaties bieden niet de benodigde functionaliteit
Blokkerend risico voor ingebruikname Hoog risico voor ingebruikname
De applicaties kunnen in gebruik worden genomen wanneer: er geen blokkerende en hoge risico’s open staan; er voldaan is aan de acceptatiecriteria (zie bijlage B) Als aan deze voorwaarden wordt voldaan volgt een positief vrijgaveadvies. Hoogachtend, [naam en handtekening]
2 Inleiding Het project heeft tot doel <doel project>. Aan het project wordt deelgenomen door verschillende partijen. Daarnaast wordt een nieuwe locatie in gebruik genomen. De huidige infrastructuur moet verhuisd worden om te komen tot een operationeel werkende nieuwe locatie waarbij de continuïteit van de werkprocessen niet in het gedrang mag komen. Daarnaast zal na verhuizing de bestaande ruimte leeg aan de eigenaar worden opgeleverd. Dit vrijgaveadvies is gebaseerd op de testresultaten welke voortkomen uit het testproject op basis van de teststrategie conform het afgestemde en goedgekeurde Mastertestplan 1v1 van 27 september 2012 (MTP).
3 Vrijgaveadvies 3.1 Onderwerp Het mastertestplan (MTP) geeft inzicht in de wijze waarop de volgende zaken gevalideerd worden: de kwaliteit van de inrichting van het pand; de werking van de systemen en de apparatuur; de werking van de telefonie; de risico’s die het project loopt bij het in gebruik nemen van de nieuwe locatie. De teststrategie uit het MTP is op basis van de product risico analyse vastgesteld om, gebruikmakend van de beschikbare tijd en middelen, maximaal inzicht te verschaffen in de kwaliteit van de nieuwe locatie en applicaties. De kwaliteit is vastgesteld aan de hand van de mate waarin is voldaan aan de acceptatiecriteria en de mate waarin opdrachtgever bij de in gebruik name van de nieuwe locatie het gevaar loopt dat de geïdentificeerde risico’s waarheid worden.
3.2 Advies Op basis van de testresultaten is het vrijgaveadvies negatief voor zowel de kwaliteit van de inrichting, de werking van de systemen, de apparatuur als ook de telefonie.
3.3 Onderbouwing van het advies In het testproject is in de afgesproken periode, conform het MTP, aangetoond dat de inrichting, de werking van de systemen, de apparatuur en telefonie niet de benodigde kwaliteit hebben om de nieuwe locatie in gebruik te nemen. Er zijn meerdere blokkerende en hoge risico’s waartegen maatregelen getroffen moeten worden. Verder is er niet voldaan aan de opgestelde acceptatiecriteria. De belangrijkste reden hiervoor is dat leverancier niet conform planning de benodigde functionaliteit werkend heeft opgeleverd. Door het niet beschikbaar hebben van de benodigde functionaliteit heeft het testproject niet alle voorgenomen en afgesproken testwerkzaamheden kunnen uitvoeren. Deze testwerkzaamheden zijn nodig om te bepalen of aan alle acceptatiecriteria is voldaan en of de kwaliteit is bereikt die noodzakelijk is voor de primaire processen van de organisatie. De nieuwe locatie kan in gebruik worden genomen wanneer: er geen blokkerende en hoge risico’s open staan; er voldaan is aan de acceptatiecriteria (zie bijlage B) Als aan deze voorwaarden wordt voldaan volgt een positief vrijgaveadvies. In de volgende paragraaf worden de risico’s van implementatie inzichtelijk gemaakt.
3.4 Risico’s van implementatie Op basis van het testproject en de resultaten hieruit worden de volgende risico’s onderkend ten aanzien van implementatie. Om bij ingebruikname van de nieuwe locatie deze risico’s tegen te gaan moeten maatregelen worden genomen. Vanuit het oogpunt van meedenken met de opdrachtgever zijn de benoemde risico’s voorzien van mogelijke maatregelen om de risico’s bij implementatie tegen te gaan. Per risico is de zwaarte van het risico aangeduid met één of meerdere rode sterren. Blokkerend risico voor ingebruikname Hoog risico voor ingebruikname Laag risico voor ingebruikname
3.4.1 Vitale applicaties niet beschikbaar De afgesproken minimale benodigde set aan applicaties is niet beschikbaar. De geplande acceptatietesten hebben derhalve niet plaatsgevonden. Er is geen inzicht in de kwaliteit van de nog te leveren applicaties. Het risico is dat de benodigde applicaties niet tijdig worden geleverd of dat deze wel tijdig worden geleverd maar, niet (voldoende) getest in productie gaan. Hierdoor is het risico te groot om in gebruik te worden genomen met ongeteste of niet beschikbare applicaties. (Voor een overzicht van (niet) beschikbare applicaties zie bijlage A) Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot de benodigde applicaties werkend zijn opgeleverd door de leverancier. Verder moet het testteam de betreffende applicaties alsnog onderwerpen aan de acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in gebruik te worden genomen.
3.4.2 Vitale koppelingen niet beschikbaar De afgesproken minimaal benodigde koppelingen zijn niet beschikbaar. De geplande acceptatietesten hebben derhalve niet plaats gehad. Er is geen inzicht in de kwaliteit van de werking van de nog te leveren koppelingen. Het risico is dat de benodigde koppelingen niet tijdig worden geleverd, of dat deze wel tijdig geleverd worden maar niet (voldoende) getest in productie gaan. Gelijk aan paragraaf 3.4.1 geldt hier dat het risico te groot is om in gebruik te worden genomen met ongeteste of niet beschikbare koppelingen. Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot de benodigde koppelingen werkend zijn opgeleverd door de leverancier. Verder moet het testteam de betreffende koppelingen tussen applicaties alsnog onderwerpen aan de acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in gebruik te worden genomen.
hierbij is dat de testscripts die automatisch worden uitgevoerd tijdens deze test in week 6 worden geprogrammeerd. Dit houdt in dat die scripts worden opgesteld met de nu aanwezige beperkte functionaliteit. Het risico hierbij is dat de uitkomst van de LSP-test niet een volledig inzicht geeft in de performance. Mogelijke maatregel: In de eerste plaats moet de leverancier de huidige bevindingen omtrent performance verhelpen. In de tweede plaats wordt er een specifieke performance test ingeregeld in de vorm van een load-, stress en piektest (LSP-test). Deze LSP-test wordt separaat van het in het MTP overeengekomen testproject uitgevoerd. De planning is om deze LSP-test in de week van 11 februari 2013 uit te voeren. Tot slot moeten de performance testen zoals overeengekomen in het MTP worden uitgevoerd.
3.4.4 Productieverstoringen Als de hiervoor genoemde risico’s genegeerd worden en de locatie in gebruik wordt genomen is het risico groot dat zich productieverstoringen voordoen. Dit kan leiden tot ongewenste situaties door het niet functioneren van de locatie en de tijd benodigd om terug te keren naar de oude situatie. Tevens bestaat het risico op imagoschade. Naast de risico’s naar de buitenwereld zijn er risico’s naar de interne organisatie. Zo is er het risico van een lagere acceptatie bij de gebruikers en beheerders waardoor het risico ontstaat dat de motivatie afneemt. Noodvoorzieningen als de no-break installatie zijn bij oplevering door de technische keten getest door de leverancier. De no-break installatie is niet getest door de gehele functionele keten. Het risico bestaat dat de no-break installatie niet (volledig) functioneert en de locatie zonder stroomvoorziening komt te zitten waardoor vitale systemen uitvallen. Onder productieverstoringen vallen tevens werkzaamheden die voor de inrichting nog moeten worden uitgevoerd. Tevens vallen hier herstelwerkzaamheden aan het gebouw onder. Er worden werkzaamheden gepland terwijl de lcatie operationeel is. Dit werkt verstorend voor de medewerkers. Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot alle benodigde functionaliteit werkend is opgeleverd door de leveranciers. Hieronder vallen ook de werkzaamheden in het kader van de inrichting van de nieuwe locatie. Verder moet het testteam de betreffende functionaliteit alsnog onderwerpen aan de acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in gebruik te worden genomen. Tot slot dienen de noodvoorzieningen worden getest in de vorm van een functionele ketentest.
3.4.5 Ontbreken gebruikersbeheer Uit de testresultaten blijkt dat bepaalde gebruikers te weinig rechten hebben en hierdoor geen beschikking hebben over benodigde applicaties. Andersom is het geval waarbij gebruikers teveel rechten hebben en hierdoor toegang hebben tot applicaties waartoe men geen toegang mag hebben. Het risico is groot dat door het ontbreken van gebruikersbeheer deze genoemde situaties ontstaan en medewerkers niet naar behoren de werkzaamheden kunnen uitvoeren. Kanttekening hierbij is dat het proces gebruikersbeheer in de basis aanwezig is maar nog volop aan verandering onderhevig is. Mogelijke maatregel: Er moet structuur en invulling worden gegeven aan gebruikersbeheer. Hierover moeten afspraken worden gemaakt. Gedane bevindingen moeten direct worden verholpen. De betreffende gebruikers moeten direct van de juiste rechten worden voorzien.
3.4.6 Beperkte gebruikers acceptatie Het niet tijdig leveren door de leveranciers en de impact hiervan op de geplande testactiviteiten voor de gebruikers acceptatietesten (GAT) geeft het risico dat de acceptatie bij gebruikers laag is. Alle geplande GAT momenten zijn gecancelled wegens gebrek aan functionaliteit. Vervolgens is onder druk van de naderende deadline de kwaliteit voor een deel losgelaten door te gaan timeboxen om alsnog de belangrijkste minimale functionaliteit met de gebruikers te testen. Hierdoor is niet gedurende een langere periode aangetoond dat de systemen de primaire processen op vereiste wijze ondersteunen. Daarnaast geven de testresultaten vanwege de beperkte functionaliteit onvoldoende inzicht in de kwaliteit van die ondersteuning aan de primaire processen. De gebruikers trainingen hebben plaats gehad. Hierbij geldt ook dat er te weinig functionaliteit werkend aanwezig was. Het effect wat was beoogd met het trainen van de medewerkers is niet bereikt. De gebruikers acceptatie is laag en de medewerkers zijn onvoldoende getraind in de nieuwe werkomgeving. Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot alle benodigde functionaliteit werkend is opgeleverd door de leveranciers. Verder moet het testteam de betreffende functionaliteit alsnog onderwerpen aan de functionele- en de gebruikers acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om de primaire processen op vereiste wijze te ondersteunen.
3.4.7 Applicaties beperkt te beheren Het niet tijdig leveren door de leveranciers en de impact hiervan op de geplande testactiviteiten voor de productie acceptatietesten (PAT) geeft het risico dat applicaties functioneel niet (voldoende) te beheren zijn. De geplande PAT momenten zijn gecancelled of zoveel mogelijk uitgesteld wegens gebrek aan functionaliteit. Er is niet gedurende een langere periode aangetoond dat de applicaties de primaire processen op gewenste wijze ondersteunen en de beheerders de beheerprocessen op gewenste wijze kunnen uitvoeren. Dit risico samen met het risico op productieverstoringen versterkt elkaar en geeft het risico dat productie verstoringen niet (tijdig) worden verholpen doordat applicaties beperkt te beheren zijn. Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot alle benodigde functionaliteit werkend is opgeleverd door de leveranciers. Verder moet het testteam samen met de beheerorganisatie de betreffende functionaliteit alsnog onderwerpen aan de productieacceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in beheer te worden genomen.
Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot alle benodigde functionaliteit werkend is opgeleverd door de leveranciers. Verder moet het testteam de betreffende functionaliteit alsnog onderwerpen aan de functionele acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in gebruik te worden genomen.
3.4.9 Beperkte functionele acceptatie Het niet tijdig leveren door de leveranciers en de impact hiervan op de geplande testactiviteiten voor de functionele acceptatietesten (FAT) bestaat het risico dat de werking van de infrastructuur, applicaties en koppelingen onvoldoende is aangetoond. Hierdoor is niet gedurende langere periode aangetoond dat de functionaliteit van de infrastructuur, applicaties en koppelingen van die kwaliteit is die is vereist. (Voor een overzicht van (niet) beschikbare applicaties zie bijlage A) Mogelijke maatregel: De ingebruikname moet worden uitgesteld tot alle benodigde functionaliteit is opgeleverd door de leveranciers. Verder moet het testteam de betreffende functionaliteit alsnog onderwerpen aan de functionele acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in gebruik te worden genomen.
3.4.10 Beperkt zicht op behoud van functionaliteit Uitgangspunt bij het project is dat de applicaties qua functionaliteit niet wijzigen. De applicaties worden alleen anders getoond aan de gebruikers. In het MTP is een klein deel regressietesten opgenomen om zeker te stellen dat regressie zich niet voordoet door het anders tonen van de applicaties. De regressietest heeft vanwege de beperkt beschikbare functionaliteit niet expliciet plaats gehad, maar is impliciet meegenomen in de gebruikerstrainingen. Vanuit deze gebruikerstrainingen is wederom vanwege de beperkt beschikbare functionaliteit onvoldoende aangetoond dat er geen regressie optreedt. Dit is reden dit aan te merken als een risico. De verwachting is dat dit risico klein zal zijn. Mogelijke maatregel: Op het moment dat de benodigde functionaliteit wordt opgeleverd door de leveranciers moet een regressietest expliciet worden uitgevoerd om aan te tonen dat de functionaliteit binnen de applicaties niet is gewijzigd.
3.4.11 Testresultaten gebaseerd op momentopnamen De behaalde testresultaten geven zijn behaald op basis van momentopnamen. Hiermee wordt bedoeld dat door de late levering er testen zijn uitgevoerd in een omgeving welke nog in ontwikkeling is door de leverancier. De vertraagde oplevering gecombineerd met de naderende deadline voor ingebruikname heeft er toe geleid dat het testproject flexibel is omgegaan met het uitvoeren van de testen. Hierdoor is in het kader van timeboxen gekozen om te testen wat op dat moment beschikbaar was voor test. De uitkomst van die test is dan gebaseerd op de functionaliteit van dat moment. Het risico bestaat dat door verdere ontwikkeling door de leverancier, na het uitvoeren van de test, de functionaliteit verandert. De uitkomst van een hertest kan anders zijn dan de uitkomst van de oorspronkelijke test. De hertest heeft op het moment van dit vrijgaveadvies niet plaats gehad. Mogelijke maatregel: Het testteam moet de betreffende functionaliteit alsnog onderwerpen aan de functionele acceptatietesten om inzicht te geven of de benodigde kwaliteit is bereikt om in gebruik te worden genomen.
3.4.12 Relatief hoge beheerkosten Bij een project wordt 20% van de kosten door het project gedragen en 80% na ingebruikname door beheer. Door tijdens het project de gewenste kwaliteit te leveren is de invloed het grootst op de uiteindelijke kosten bij ingebruikname. Hierdoor blijven de kosten beheersbaar. In de huidige situatie is gedurende het project niet met zekerheid te stellen dat de beoogde kwaliteit is geleverd. De hiervoor bestemde productie acceptatietesten zijn niet (volledig) uitgevoerd door de verlate oplevering van functionaliteit. Het risico bestaat dat deze beheerkosten hoger uitvallen bij ingebruikname zonder het bereiken van de gewenste kwaliteit. Mogelijke maatregel: De PAT moet alsnog volledig worden uitgevoerd vanaf het moment dat de beheerafdeling zijn intrek neemt in het nieuwe pand. Hiermee wordt voldoende inzicht verkregen in de kwaliteit van de uit te voeren beheerprocessen.
4 Gevolgde strategie en aanpak 4.1 Gevolgde teststrategie De teststrategie is uitgevoerd conform de teststrategie zoals bepaald in paragraaf 4.8 in het MTP. Op basis van deze teststrategie is gekozen voor het uitvoeren van een gecombineerde acceptatietest. Voor de apparatuur, systemen en telefonie is gekozen voor de functionele-, gebruikers- en productie- acceptatietest. Geheel conform het MTP en de verschillende detailtestplannen (DTP) zijn de testen in de periode voorafgaand aan de testuitvoering voorbereid en zijn de diverse testscripts gespecificeerd en geschreven. Tijdens deze voorbereidende werkzaamheden is ook de structuur voor de testuitvoering uitgedacht. Schematisch ziet de structuur voor de testuitvoering er als volgt uit:
Figuur 1. Schematische structuur van de testuitvoering
De diverse testscripts die uitgevoerd worden binnen de gedefinieerde testsoorten zijn gekoppeld aan een tweetal dekkingsmatrices. In de ene dekkingsmatrix wordt gecontroleerd dat met de testscripts de achterliggende techniek/koppelingen worden getest. De andere dekkingsmatrix controleert dat met de uitgevoerde testscripts de gestelde acceptatiecriteria worden getoetst. Op basis van dit geheel kan een gedegen en onderbouwd vrijgaveadvies worden afgegeven aan het einde van de testactiviteiten.
4.2 Uitgevoerde testactiviteiten De hiervoor beschreven structuur van de uitvoering heeft geleid tot de volgende daadwerkelijke invulling van de testuitvoering. In onderstaande figuur wordt dit getoond.
Figuur 2. Schematische weergave van de testuitvoering
In het midden van de figuur zijn de testscripts per testsoort zichtbaar. Dit symboliseert de uitvoering van de testscripts die tijdens de diverse testsoorten uitgevoerd moeten worden. De controle op de voortgang van de testuitvoering wordt bereikt door het gebruik van het dashboard boven de testscripts. Enerzijds worden de testscripts gestart vanuit het dashboard. Anderzijds wordt hiermee de voortgang gecontroleerd en wordt gemonitord op welke testscripts nog bevindingen open staan. Dit dashboard wordt gebruikt door de testcoördinator en de testmanager. Het daadwerkelijke bevindingenbeheer wordt uitgevoerd in de daarvoor bestemde bevindingentool. Hierin worden bevindingen vastgelegd, bevindingen toegewezen aan de verantwoordelijke persoon en wordt de voortgang van de bevindingen bewaakt. Hieronder een overzicht van de testuitvoering per deelsysteem.
4.2.1 Deelsysteem systemen/apparatuur/telefonie Deze paragraaf geeft inzage in de voortgang en resultaten van de testuitvoering voor het deelsysteem systemen/apparatuur/telefonie. In onderstaande grafiek is de voortgang zichtbaar per benoemde testsoort per 7 februari 2013.
Hieruit komt duidelijk naar voren dat de FAT en de PAT niet voldoende inzicht geeft in de kwaliteit en de GAT niet testbaar is. Beide veroorzaakt door de beperkt beschikbare functionaliteit.
4.2.2 Deelsysteem inrichting Deze paragraaf geeft inzage in de voortgang en resultaten van de testuitvoering voor het deelsysteem inrichting. In onderstaande grafiek is de voortgang zichtbaar van de testsoort gecombineerde acceptatietesten per 7 februari 2013.
GAT Kantoor
# OK # NOK
GAT ICT/App.
# Niet getest
GAT Meubilair
0%
20%
40%
60%
80%
100%
Figuur 4. Voortgang en resultaten testuitvoering inrichting
# kamers OK # kamers NOK # kamers Niet getest # kamers Totaal
2. Op een aantal etages zijn verhoogde vloeren. In deze vloeren moeten nog vloerdelen worden geplaatst welke voorzien zijn van alle aansluitingen voor elektra en netwerk.
4.3 Actualiteit t.o.v. testplan Het grootste verschil tussen het MTP en de actualiteit is de planning. In het algemeen hebben de leveranciers op diverse vlakken meer tijd nodig dan gepland. Hierdoor is de situatie ontstaan dat het testproject is begonnen terwijl de leveranciers hun producten/diensten nog niet hebben opgeleverd. Er is door het projectteam bewust gekozen de diverse activiteiten parallel plaats te laten vinden. Dit met als doel de geplande einddatum te halen. Dit voornaamste verschil ten opzichte van het MTP heeft tot een aantal wijzigingen geleid. Hieronder worden deze wijzigingen opgesomd:
Uitvoering van gefaseerd naar timeboxen; Geen intake op volledige testbasis; Uitvoeren FAT testscripts zodra functionaliteit beschikbaar is (momentopname); Uitvoeren GAT testscripts op de inrichting per deelleverancier (i.p.v. op het geheel); Uitstellen GAT systemen/apparatuur/telefonie; Uitstellen PAT systemen/apparatuur/telefonie; Inrichten extra load, stress en piek test t.a.v. performance testen; Gebouw opleverpunten toegevoegd aan het bevindingenoverzicht.
De organisatie en het projectteam staan voor de keuze de ingebruikname datum uit te stellen en het testteam aan te houden tot de nieuwe datum. Hiermee wordt een maatregel genomen waarmee genoemde risico’s voor een deel afgedekt worden of worden verlaagd. Dit betekent dat het testteam in staat wordt gesteld de overeengekomen acceptatietesten alsnog uit te voeren. Als voor deze maatregelen wordt gekozen vallen beide maatregelen ook onder de noemer wijziging ten opzichte van het oorspronkelijke testplan.
5 Testresultaten 5.1 Bevindingen In dit document wordt niet in detail ingegaan op de bevindingen. Alle bevindingen zijn toegankelijk voor het projectteam in de bevindingentool. Hieronder een rapportage uit de bevindingentool per categorie (deelsysteem). Op verzoek van het projectteam zijn naast inrichtingszaken ook opleverpunten van het gebouw opgenomen in de bevindingenadministratie.
Figuur 5. Schermprint rapportage bevindingentool per 7 februari 2013
Er zijn relatief weinig bevindingen op het deelsysteem systemen en applicaties. Dit zegt niets over de kwaliteit van dit deelsysteem. Dit heeft te maken met de beperkte levering van functionaliteit en dus de beperkt uitgevoerde testen.
6 Bijlage A – Benodigde functionaliteit Vanuit het projectteam heeft het testteam onderstaande overzicht ontvangen. Het overzicht toont de minimaal benodigde functionaliteit voor het in gebruik nemen van de nieuwe locatie. De inhoud van het overzicht komt voort uit een workshop tussen leverancier, gebruikersorganisatie en projectteam.1
Functies per deelgebied Telefonie
Incident Management
Web
Systemen per deelgebied Telefonie
Incident Management
Web
Aanwezig en werkend Moet 19-2 werken, maar is nog niet (volledig) functioneel Niet aanwezig, maar dat is volgens verwachting
1
Het testteam is niet verantwoordelijkheid voor de volledigheid en juistheid van het overzicht.
7 Bijlage B – Acceptatiecriteria Het in gebruik nemen van de nieuwe locatie is afhankelijk van het voldoen aan de gestelde acceptatiecriteria. Hieronder een overzicht van de acceptatiecriteria: Klanten moeten het bedrijf kunnen bereiken; Als het gesprek goed binnenkomt in de centrale en de centralist het binnenkomende gesprek kan aannemen; Als de centralist in staat is het binnenkomende gesprek door te verbinden naar de juiste medewerker; Centralisten moeten goed kunnen werken; De centralist moet de benodigde applicaties kunnen starten en bedienen; De centralist moet een binnenkomend gesprek kunnen opnemen; De centralist moet een incident kunnen aanmaken in het systeem; De centralist moet voldoende overzicht over alle operationeel noodzakelijk beschikbare informatie hebben; De centralist moet voldoende faciliteiten hebben om geconcentreerd en gemotiveerd te werken; Collega’s moeten het bedrijf kunnen bereiken; Medewerkers van het bedrijf moeten de locatie telefonisch kunnen bereiken; Overige contacten van het bedrijf moeten het bedrijf telefonisch kunnen bereiken;
