Service Level Agreement. Versie oktober 2014

Service Level Agreement Versie 2.1 10 oktober 2014

Pagina 1/36

HR2day Service Level Agreement| 6-10-2014

Wijzigingen

Datum 10-09-2014 10-10-2014

Pagina 2/36

Versie 2.0 2.1

Wijzigingen Volledig nieuwe versie uitgebracht Tekstuele verbeteringen en verduidelijkingen


Inhoudsopgave 1! Inleiding .......................................................................................................... 6! 1.1! Doel van de service level agreement (SLA) ............................................................... 6! 1.2! Wijziging en beheer SLA ..................................................................................... 6! 1.3! Super User ..................................................................................................... 6! 1.4! Kantooruren / tijdsdefinitie .................................................................................. 7! 1.5! Geldigheid van dit document ................................................................................ 7! 1.6! Structuur van het document ................................................................................ 7! 2! Overzicht van services verleend door eMerus ...................................................... 8! 2.1! Services......................................................................................................... 8! 2.2! Onderhoudswindow .......................................................................................... 9! 2.3! Gegarandeerde service niveaus............................................................................. 9! 2.4! Uitsluitingen van de service niveaus ......................................................................10! 2.5! Notificatie procedures voor gepland onderhoud / onderbrekingen ...................................10! 2.6! Beperkingen en grenzen ....................................................................................10! 3! Veiligheid ..................................................................................................... 12! 3.1! Fysieke toegang tot data centrum.........................................................................12! 3.2! Verantwoordelijkheid voor toevoegen/veranderen van gebruikerstoegang .........................12! 3.3! Beveiligingsniveaus voor applicaties, netwerk en platform ............................................13! 3.4! Gebruikersauthenticatie .....................................................................................13! 3.5! Firewalls .......................................................................................................13! 3.6! Virus scanning ................................................................................................13! 3.7! SSL .............................................................................................................13! 3.8! Derde partij testen ...........................................................................................13! 3.9! ISAE3402 Type II ............................................................................................14! 3.10! Security conformering / ISO ..............................................................................14! 4! Tracking en rapportages ..................................................................................... 15! 4.1! Monitoring van services .....................................................................................15! 4.2! Definitie en meting van down-time .......................................................................15! 4.3! Rapportage van service niveau naar de klant ...........................................................15! 5! Probleemoplossingen en sancties ........................................................................... 17! 5.1! Oplossingen ...................................................................................................17! 5.2! Sancties .......................................................................................................18! 6! Releases ........................................................................................................ 19! 6.1! Release procedures ..........................................................................................19! 6.2! Security en systeempatches ................................................................................20! 7! Back-up, redundantie en noodherstel ............................................................... 21! 7.1! Back-ups van data ...........................................................................................21! 7.2! Systeem redundantie ........................................................................................21! 7.3! Herstel parameters (hoe snel kan de data hersteld worden)..........................................21! 7.4! Prioriteit en proces voor noodherstel .....................................................................21! 8! Support en Servicedesk services ............................................................................ 23! 8.1! De Servicedesk ...............................................................................................23! 8.2! Standaard support en Servicedesk beschikbaarheid ....................................................23! 8.3! Methoden van contact ......................................................................................23! 8.4! Call definities en prioriteiten................................................................................24! 8.5! Reactietijd en Oplostijd .....................................................................................24! 8.6! Klachtenprocedure ...........................................................................................25! 8.7! Escalatieprocedure ...........................................................................................25! 8.8! Opleidingsvereisten ..........................................................................................25! 8.9! Rapportage over ondersteuning en Servicedesk services ..............................................25! 8.10! Bespreken service verlening ..............................................................................26! 9! Beëindiging van de diensten ................................................................................. 27! Pagina 3/36


9.1! 9.2! 9.3! 9.4!

Tijdsperiode voor beschikbaar stellen van data .........................................................27! Tijdelijke continuering van de diensten ...................................................................27! Beschikbaar houden van data voor raadpleeg- en conversiedoeleinden ............................27! Procedures voor beëindiging ...............................................................................27!

Pagina 4/36


Definities Super User(s) Gebruiker Diensten of Services

Pagina 5/36

Een of meerdere contactpersonen van Opdrachtgever die meldingen, verstoringen en verzoeken aan de Service Desk van eMerus doorgeven en met wie de Service Desk van eMerus zelf contact opneemt Een medewerker of externe van Opdrachtgever die toegang heeft tot de door eMerus beschikbaar te stellen applicatie onder de Voorwaarden van de Overeenkomst De via het internet beschikbaar te stellen applicatie(s) van eMerus, alsmede de bijbehorende Service Desk.


1

Inleiding

HR2day is een “Software As A Service” (SAAS) oplossing. eMerus exploiteert en beheert de HR2day applicatie die geconfigureerd is op het Force.com platform van Salesforce.com. Salesforce.com is de grootste leverancier ter wereld op CRM en Internet Applicatie Platform gebied. Meer informatie is te vinden op http://www.salesforce.com/nl/company/. De inhoud op deze URL is niet van invloed op de overeenkomst. eMerus verleent doorlopende ondersteuning, onderhoud en upgrades voor de applicaties die geleverd worden aan onze klanten. Het SAAS bedrijfsmodel geeft klanten van eMerus (in deze SLA verder Opdrachtgever) toegang tot IT middelen door middel van een web browser. Voor hen wordt het hierdoor mogelijk om business operations te stroomlijnen en om hun strategische positie te verbeteren. Het geeft hen toegang tot state-of-the-art IT middelen, waarmee zij hun veiligheid, betrouwbaarheid en management mogelijkheden kunnen verhogen. Dit document verleent aan Opdrachtgever een gedetailleerde definitie van de bovenstaande dienstverlening. Het geeft Opdrachtgever tevens inzicht in de service niveaus die gegarandeerd worden door eMerus. 1.1

Doel van de service level agreement (SLA)

Opdrachtgever heeft een contract getekend. Dit contract specificeert de prijs, duur, algemene condities en functionaliteiten van de diensten op het moment van tekenen. Met ‘syste(e)m(en)’, bedoelt eMerus de applicatiesystemen op de productie omgeving (exclusief de ontwikkel, test en acceptatie omgeving) waarop de applicatie toegankelijk is voor de klant. Deze SLA beschrijft de dienstverlening en de diensten die eMerus verleent. Vervolgens omschrijft deze SLA het gegarandeerde niveau van de dienstverlening en de sancties in het geval dat eMerus dit niveau niet haalt. De procedures en infrastructuur, zoals deze in dit document benoemd worden, zijn beschreven in hun huidige status. Natuurlijk zijn deze onderwerp van veranderingen door de tijd. eMerus behoudt zich het eenzijdige recht voor om procedures en configuraties te wijzigen indien de omstandigheden hiertoe aanleiding geven. Daar waar nodig, bijvoorbeeld indien de procedure het werkproces van Opdrachtgever verandert of sprake zal zijn van verminderde beschikbaarheid, wordt met Opdrachtgever voorafgaand gecommuniceerd over deze wijzigingen. Voorafgaand communiceren is de norm, achteraf communiceren zal bijvoorbeeld het geval zijn indien het acute patches betreft. Het gegarandeerde niveau van dienstverlening en functionaliteit is geen onderwerp van verandering. Dit niveau wordt nu gegarandeerd en dit blijft zo tot het einde van de contractperiode. 1.2

Wijziging en beheer SLA

De inhoud van deze Service Level Agreement wordt periodiek door eMerus bijgewerkt om deze in lijn te houden met ontwikkelingen met betrekking tot de diensten en/of de procedures van eMerus. Deze diensten en procedures zijn gestandaardiseerd en worden centraal op een identieke wijze voor alle klanten van eMerus beheerd en onderhouden. Wijzigingen in deze generieke SLA worden vastgelegd en via de release notes aan de contactpersonen per klant gecommuniceerd. Wijzigingen in individuele overeengekomen SLA’s met individuele klanten worden alleen na overleg en wederzijdse instemming aangebracht. 1.3

Super User

eMerus is verantwoordelijk voor het leveren aan Opdrachtgever van software, onderhoud, ondersteuning, gebruikerstraining en consultancy voor de applicatie conform contractafspraak. Een

Pagina 6/36


verantwoordelijke persoon in de Opdrachtgever organisatie, de Super User1, zal het eerste aanspreekpunt zijn voor de dagelijkse vragen van gebruikers. De Super User zal de enige contactpersoon zijn die aan eMerus kan vragen om diensten te verlenen, wanneer gebruik wordt gemaakt van ons dienstverleningsmodel zoals gegarandeerd is in deze SLA. Het is mogelijk om meerdere Super Users te benoemen. De Super User is een HR2day gebruiker die in de online service desk geregistreerd staat als zijnde Super User. Deze Super User is bevoegd tot het accorderen van kosten tot en met 4 uur werk. Het benoemen of wijzigen van een Super User wordt uitgevoerd in opdracht van de oorspronkelijke opdrachtgever. Het verzoek voor het instellen van een Super User is een wijzigingsverzoek wat via een email aan de Account manager van eMerus dient te gebeuren. 1.4

Kantooruren / tijdsdefinitie

Met kantooruren, wanneer deze genoemd worden in deze SLA, refereert eMerus aan werkdagen tussen 08.00 en 18.00 uur CET. 1.5

Geldigheid van dit document

De geldigheid van dit document is ondergeschikt aan de Opdrachtgever overeenkomst voor het gebruik van de eMerus applicatie(s). Indien de Opdrachtgever overeenkomst hierin niet voorziet is dit document leidend. 1.6

Structuur van het document

Hoofdstuk 2 van deze SLA beschrijft de services en service niveaus die geleverd worden door eMerus. Uitsluitingen van de service niveaus en onderhoudsnotificatie procedures zijn ook in dit hoofdstuk beschreven. Hoofdstuk 3 beschrijft de manier waarop eMerus de veiligheid van de applicatie en data zal garanderen. Hoofdstuk 4 beschrijft de manier waarop eMerus de beschikbaarheid van de verschillende services zal bijhouden. Dit hoofdstuk beschrijft tevens de definities van de beschikbaarheid en metingen. Ook zal de manier van (service beschikbaarheid) rapportage hier beschreven worden. Hoofdstuk 5 beschrijft de oplossingen en sancties in het geval dat eMerus de gegarandeerde service niveaus niet haalt. Hoofdstuk 6 beschrijft de procedures van de ontwikkelingen van de applicatie. Ook de procedures inzake updates (kleine veranderingen) en upgrades (grote veranderingen) worden hier beschreven. Hoofdstuk 7 beschrijft de contingency, backup en disaster recovery procedures. Hoofdstuk 8 beschrijft de service desk en ondersteunende services. eMerus zal de applicatie(s) ontwikkelen op basis van input van de klant en marktontwikkelingen. Applicatie ontwikkelprocedures worden hier ook beschreven en de aard van problemen worden hier gedefinieerd. Ondersteuningsprocedures voor klantspecifieke elementen van de applicatie worden hier ook beschreven. Hoofdstuk 9 beschrijft de procedures in het geval van beëindiging van het contract. Data overgang en eenzijdige beëindiging worden ook beschreven.

1

Met de Super User wordt in dit document een persoon in de communicatie matrix bedoeld. Zie bijlage A.

Pagina 7/36


2 2.1

Overzicht van services verleend door eMerus Services

De services van eMerus zijn: 1. Applicatie services 2. Onderhoud van de applicatie 3. Ontwikkeling van de applicatie 4. Service desk services voor gebruikersvragen en problemen/fouten/bugs 5. Onderhoud van de documentatie voor de applicatie

Applicatie services De eerste en belangrijkste service van eMerus is dat eMerus applicatie services verleent aan de gebruikers van Opdrachtgever. Dit betekent dat de gebruikers van Opdrachtgever toegang hebben, informatie kunnen invoeren en updaten in de database via het internet, wanneer er gebruik wordt gemaakt van de ondersteunende web browsers. De applicatie zal werken onder minimaal de volgende Internet browsers (https://login.salesforce.com/help/doc/en/getstart_browser_overview.htm 2): Momenteel zijn dit: • Microsoft Internet Explorer 9 ,10 en 11 • Firefox (meest recente versie) • Chrome (meest recente versie) • Apple Safari versie 5.x en 6.x Bij het beëindigen van browser support houdt Salesforce een termijn van 6 maanden aan tussen het melden en het daadwerkelijk beëindigen. eMerus confirmeert zich aan he browser support beleid van Salesforce.

Hosting faciliteiten Alle servers op onze productie dienst zijn redundant beschikbaar. HR2day draait op het force.com platform. Het force.com platform draait op afgeschermde omgevingen bij top-tier datacenters over de gehele wereld. In deze SLA verlenen wij Opdrachtgever ondersteuning met een productie en een back-up faciliteit op een andere locatie waar een back-up met data is opgeborgen. Het force.com platform herbergt standaard de mogelijkheid van uitwijk. Wanneer een locatie onvoldoende of in zijn geheel niet meer presteert wordt de applicatie met bijbehorende data automatisch op een andere locatie aangeboden. Dit gaat volledig automatisch en zonder dat de gebruiker dit merkt. Er is daardoor geen verlies van beschikbaarheid en data. eMerus beschouwt een gemiddelde page respons time van 1 seconde als onvoldoende.

Monitoring Monitoring software is in gebruik om de beschikbaarheid van onze services te controleren en te meten. Dit instrument checkt automatisch of de hardware, die hierboven genoemd is, operationeel is, zendt waarschuwingen uit wanneer dit niet zo is en logt de downtime per hardware locatie. Het speelt ook een rol in het verlenen van rapporten over actuele uptime en downtime aan de klant. U kunt de beschikbaarheidsstatistieken zien op https://trust.salesforce.com/trust/status/3 Onderhoud van de applicatie(s) Met ‘onderhoud van de applicatie(s)’ refereert eMerus aan alle software die eMerus exploiteert ten behoeve van de in deze SLA bedoelde dienst(en). 2 3

Zie bijlage B voor de inhoud van deze pagina Zie bijlage C voor de inhoud van deze pagina

Pagina 8/36


Ontwikkeling van de applicatie(s) eMerus ontwikkelt de applicatie(s) om te verzekeren dat het een hoogwaardige applicatie blijft. Ontwikkeling van de applicatie(s) kan verdeeld worden in twee delen: Kleine updates voor de applicatie(s) (applicatie ondersteuning) Grote veranderingen aan de applicatie(s) (applicatie ontwikkeling) Klanten dienen (relatief kleine) verzoeken in om de functionaliteiten van de standaard applicatie te verbeteren. eMerus houdt deze verzoeken bij en de Change Advisory Board (CAB) beslist wekelijks of het verzoek waardevol is voor elke klant en of het verzoek in de applicatie aangebracht kan worden zonder dat dit hele grote gevolgen heeft voor het gebruik door andere klanten. Wanneer dit zo is, zal eMerus de applicatie aanpassen en de verandering implementeren in de standaard applicatie in een van de geplande updates (applicatie ondersteuning). eMerus ontwikkelt de applicatie(s) ook om nieuwe functionaliteiten te introduceren en toe te voegen aan de applicatie. Deze ontwikkelingen hebben meestal een grotere impact op het gebruik van de applicatie. Over het algemeen ontwikkelt eMerus, zo mogelijk, de nieuwe functionaliteiten als aparte modules die aan en uit gezet kunnen worden. Deze grotere veranderingen aan de applicatie zullen over het algemeen geïmplementeerd worden tijdens een geplande upgrade van de applicatie. eMerus zal in beide gevallen verzekeren dat de veranderingen voorafgaand aan de implementatie aan Opdrachtgever gecommuniceerd worden, onder voorwaarde dat de veranderingen relevant zijn voor de bedrijfsvoering en het gebruik van de applicatie door Opdrachtgever.

Service desk voor gebruikersvragen en fouten eMerus heeft een service desk voor gebruikersvragen, problemen en fouten. De procedure voor het gebruik van de service desk, zoals daarnaar gerefereerd wordt in dit document, wordt nader beschreven in hoofdstuk 8: Service Desk procedure Onderhoud van de documentatie voor de applicatie Voordat upgrades en updates worden geïmplementeerd geeft eMerus Opdrachtgever door middel van release notes de laatste wijzigingen door. Deze release notes zijn een aanvulling op de in beginsel verstrekte gebruikershandleiding en vertegenwoordigen de laatste status van de applicatieonderdelen die in de upgrade/update betrokken zijn. 2.2

Onderhoudswindow

eMerus maakt gebruik van een geplande onderhoudswindows. Deze worden hier gepubliceerd: https://trust.salesforce.com/trust/maintenance/4 Onderhoud wordt ook weergegeven bij het inloggen op de applicatie. 2.3

Gegarandeerde service niveaus

eMerus garandeert een niveau van beschikbaarheid voor alle services. Beschikbaarheid wordt automatisch gemeten door een controle instrument. U kunt de live up-time statistieken raadplegen op https://trust.salesforce.com/trust/status/5. De exacte definities van de beschikbaarheidscijfers staan in het hoofdstuk Tracking en rapportages.

4 5

Zie bijlage D voor de inhoud van deze pagina Zie bijlage C voor de inhoud van deze pagina

Pagina 9/36


eMerus garandeert dat de gemiddelde up-time voor de complete dienst zoals bedoeld in deze SLA tenminste 99,9% is. Deze up-time heeft betrekking op een maandelijkse periode en voor 24 uur per dag, 7 dagen per week. 2.4

Uitsluitingen van de service niveaus

In de berekening van de beschikbaarheidsstatistieken zoals die hierboven staan, worden sommige down-times niet meegenomen. De volgende zaken worden uitgesloten: • Gepland onderhoud • Force majeure (overmacht) Onderbrekingen door gepland onderhoud worden niet aangemerkt als down-time. Wanneer gepland onderhoud plaatsvindt, zal eMerus dit vooraf aan de gebruikers communiceren. eMerus doet zijn best om gepland onderhoud tot het absolute minimum te beperken. Force majeure (overmacht) is ook uitgesloten. Ook downtime veroorzaakt door ernstige mate van schuld, roekeloosheid of opzet door de klant is uitgesloten. 2.5

Notificatie procedures voor gepland onderhoud / onderbrekingen

eMerus zal Opdrachtgever minimaal vijf werkdagen van tevoren op de hoogte stellen over geplande onderbrekingen. In het geval van een geplande onderbreking zal er een notificatie email gestuurd worden naar de Super User van Opdrachtgever. De Super User is verantwoordelijk voor de communicatie over de onderbreking naar de rest van de gebruikers in de Opdrachtgever organisatie. Tevens zal het aangekondigde onderhoud worden weergegeven bij de login pagina. Ook de niet geplande onderhoudswerkzaamheden en/of onderbrekingen worden zo spoedig mogelijk gemeld bij de Super User. In het geval dat Opdrachtgever minder dan vijf werkdagen van tevoren is geïnformeerd, maar geen bezwaren tegen de onderbreking heeft, zal de onderbreking als gepland behandeld worden. Wanneer de Opdrachtgever wel bezwaren heeft, kan hiervoor contact opgenomen met de eMerus Accountmanager. Op basis van argumenten maakt de Directeur Operations vervolgens een afweging om dit onderhoud alsnog, dan wel op een later moment uit te voeren. Indien Opdrachtgever het niet eens is met deze beslissing kan dit aangegeven worden door een email naar [email protected] te sturen. De klachten procedure staat beschreven in paragraaf 8.6 van deze SLA. 2.6

Beperkingen en grenzen

eMerus bouwt en exploiteert applicaties op basis van het Salesforce platform. Het platform schaalt prima voor wat betreft hoger wordend gebruik van de applicatie(s) door meer users en/of meer transacties op het systeem. Wel heeft de applicatie grenzen ingebouwd. Bijvoorbeeld voor de grootte van bijlagen die in het digitale personeelsdossier kunnen worden toegevoegd. Ook zijn er grenzen aan de maximaal beschikbare ruimte per gebruiker en organisatie. Een uitgebreid overzicht van deze grenzen staat beschreven op: https://login.salesforce.com/help/doc/en/salesforce_app_limits_cheatsheet.pdf6 (versie 31 juli 2014). eMerus is verantwoordelijk voor het binnen deze grenzen gebruik maken door haar applicatie, maar er is een limiet die Opdrachtgever kan beïnvloeden: de hoeveelheid opslagruimte die bijlagen in beslag nemen die worden toegevoegd aan de digitale dossiers van medewerkers. 6

Zie bijlage E voor de inhoudsopgave van dit document

Pagina 10/36


Opdrachtgever krijgt binnen het abonnement de beschikking over het totaal van 2Gb aan gegevensopslag voor dergelijke bijlagen per (volwaardige) gebruiker. Bij een gemiddeld beslag van 100kB per document is dit 20.000 documenten per gebruiker. Extra realtime/online gegevensopslag kan worden aangeschaft tegen een prijs van € 5,00 per Gb per maand (prijspeil september 2014).

Pagina 11/36


3

Veiligheid

Net zo belangrijk als beschikbaarheid is de veiligheid (security) bij de services die verleend worden. Omdat de data van de klant buiten de muren van eMerus en Opdrachtgever is opgeslagen moeten de authenticatie en autorisatie mechanismen correct gedefinieerd worden. Deze mechanismen moeten gedefinieerd worden op twee niveaus: fysieke toegang tot de servers en gebruikers toegang tot de applicatie(s). 3.1

Fysieke toegang tot data centrum

De eerste twee authenticatie en autorisatie mechanismen behoeven correcte controle van de toegang tot de fysieke servers en hun onderliggende netwerk componenten. Deze mechanismen zijn normaal gesproken niet beschikbaar voor de klanten en medewerkers van eMerus, maar in deze context is het belangrijk om een algemeen overzicht van deze mechanismen te geven. Een uitgebreide beschrijving over de beveiliging van het force.com platform is te vinden op: https://trust.salesforce.com/trust/security/7. Dit is het huidige en minimale niveau.

Fysieke toegang Salesforce.com gebruikt co-locatie diensten bij top-tier datacenters. Onderdeel van de dienstverlening is toegangscontrole en fysieke beveiliging. • 24-uurs beveiliging, inclusief patrouilles en fysieke poort controles • biometrische toegangscontroles • dedicated datacenter ruimtes voorzien van betonnen muren. • Video surveillance in en om het datacenter • Aardbeving, storm en overstromingsbestendige gebouwen. • Registreren van het verwijderen van hardware Fysieke toegang tot de servers in de hosting centra is strikt gelimiteerd tot geautoriseerd personeel. 3.2

Verantwoordelijkheid voor toevoegen/veranderen van gebruikerstoegang

De verantwoordelijkheid om een gebruikerstoegang toe te voegen of te veranderen ligt bij de Super User van de klant, waarbij de uitvoering door eMerus kan geschieden. Het is de taak van deze persoon om: • • •

Te verzekeren dat alleen de personen die de autorisatie hebben om de eMerus applicatie te gebruiken een actieve gebruikersnaam en wachtwoord hebben. Te verzekeren dat elk van deze gebruikers de juiste instellingen heeft om toegang te krijgen tot de applicatie. Te verzekeren dat elke actieve gebruiker een veilig wachtwoord heeft (zonder namen of woorden die gevonden kunnen worden in woordenboeken)

Onderstaande link geeft een inzicht hoe de administrator van een omgeving de wachtwoorden en de sterkte daarvan kan beheren: https://trust.salesforce.com/trust/practices/8 In de applicatie zijn de settings voor wachtwoorden hier te vinden: Setup>Beveiligingselementen>Wachtwoordbeleid Standaard levert eMerus de beveiligingsinstellingen voor wachtwoorden als volgt op:

7 8

Zie bijlage F voor de inhoud van deze pagina Zie bijlage G voor de inhoud van deze pagina

Pagina 12/36


3.3

Beveiligingsniveaus voor applicaties, netwerk en platform

eMerus onderscheidt verschillende lagen van beveiliging in de applicatie. Verschillende niveaus van autorisatie kunnen toebedeeld worden per gebruiker of per gebruikersgroep. Dit houdt niet alleen de functionaliteit van de applicatie in toom, maar ook de zichtbaarheid van de data. In het bijzonder voor grotere bedrijven is de controleerbaarheid van de zichtbaarheid van de data een belangrijke functionaliteit in de applicatie. eMerus richt de volgende lagen van beveiliging in: - medewerkers hebben alleen toegang tot hun eigen persoonsgegevens - leidinggevend hebben toegang tot hun eigen persoonsgegevens en kunnen toegang krijgen tot (delen van) de persoonsgegevens van de aan hen rapporterende medewerkers - administratieve medewerkers hebben toegang tot hun eigen persoonsgegevens en kunnen toegang krijgen tot de persoonsgegevens van alle medewerkers van de betreffende werkgever. 3.4

Gebruikersauthenticatie

Voordat gebruikers toegang kunnen krijgen tot de applicatie dienen zij door de Super User bekend te worden gemaakt. De applicatie verzekert dat alleen geautoriseerde personen in kunnen loggen met behulp van twee-factor authenticatie. 3.5

Firewalls

De firewalls rondom het force.com platform zijn onzichtbaar voor de buitenwereld. Zij staan tussen het publieke internet en de applicatie(s) en blokkeren al het onnodige verkeer. Intrusion Detection Systemen bevinden zich op het interne netwerk en deze rapporteren events naar een Security Event Systeem ten behoeve van logging, alerting en rapportages. Een externe service provider monitort het netwerk vanuit de buitenkant en geeft alerts af bij veranderingen in de standaard configuratie. 3.6

Virus scanning

Virus scanning is NIET geïnstalleerd op de force.com infrastructuur. De meeste virus scans worden uitgevoerd op het niveau van het werkstation van de klant. Daar is het efficiënter om een virus op te sporen, omdat virussen platform afhankelijk zijn. Het is de verantwoordelijkheid van Opdrachtgever om een up-to-date virus scan programma op de computers van de gebruikers te installeren. 3.7

SSL

De applicatie is standaard voorzien van beveiliging via SSL 3.0/TLS 1.0. Al het verkeer tussen de server en de browser wordt dan versleuteld. Salesforce.com maakt hiervoor gebruik van servercertificaten die worden uitgegeven door Verisign. De certificaten van Verisign worden geaccepteerd door alle browsers die eMerus ondersteunt. 3.8

Derde partij testen

Salesforce test alle code op security zwakheden voordat de software beschikbaar wordt gesteld. Regelmatig scant Salesforce het netwerk en de systemen op zwakheden (vulnerabilities). Regelmatig worden door derden beveiligingstests uitgevoerd. Op het gebied van:

Pagina 13/36


Applicatie vulnerability threat assessments Netwerk vulnerability threat assessments Verschillende penetratie tests en code review Security control framework review en tests

• • • • 3.9

ISAE3402 Type II

Al het personeel in de eMerus organisatie is zich bewust van het potentiële risico dat hun werk in de applicatie(s) kan toebrengen. Om deze reden laat eMerus haar ontwikkelen exploitatieprocessen IASE3402 Type II jaarlijks certificeren. 3.10 Security conformering / ISO Het onderliggende force.com platform is gecertificeerd op meerdere kwaliteitseisen op het gebied van onder andere informatie beveiliging. Het force.com platform is gecertificeerd op onder andere: • ISO 27001 • ISAE3402 Type II • SysTrust Verder is force.com gelicenseerd op de volgende zaken: • EU Safe Harbor self-certification via het Amerikaanse Ministerie van Economische zaken (U.S. Department of Commerce) • TRUSTe EU Safe Harbor Seal • TRUSTe Certified Privacy Seal • Japan Privacy Seal from the Japan Information Processing Development Corporation (JIPDC) Zie ook: https://trust.salesforce.com/trust/privacy/tools/9 Deze rapportages kunnen ter inzage worden gekregen na het ondertekenen van een Non-Disclosure Agreement door Opdrachtgever.

9

Zie bijlage H voor de inhoud van deze pagina

Pagina 14/36


4

Tracking en rapportages

In het hoofdstuk over services, heeft eMerus de service beschikbaarheid gegarandeerd. In dit hoofdstuk zal een definitie van down-time en up-time gegeven worden. Daarnaast zullen monitoring en rapportage mechanismen, instrumenten en procedures beschreven worden. In dit hoofdstuk is een aantal zaken beschreven in aparte paragrafen: 1. Monitoring van services 2. Definitie en meting van down-time 3. Rapportage van service levels aan Opdrachtgever 4.1

Monitoring van services

eMerus monitort de beschikbaarheid en de performance van het systeem continu. Hierdoor kunnen eventuele verstoringen snel worden gesignaleerd. 4.2

Definitie en meting van down-time

Met betrekking tot down-time, zijn er verschillende componenten die bepalend zijn voor de actuele beschikbaarheid. De volgende definities verduidelijken de componenten die nodig zijn voor iedere service. Web service is gedefinieerd als de mogelijkheid voor een gebruiker om de web interface van HR2day te gebruiken om te kijken of data aan te passen in de database. Voor een operationele web service moeten er drie hardware componenten operationeel zijn (database server, web server en internet verbinding).

Web service beschikbaarheidsmeting Iedere vijftien minuten wordt er een pagina opgevraagd van een server buiten de eMerus infrastructuur. De pagina opvraag wordt gecontroleerd met voor gedefinieerde inhoud en als het deze test doorstaat wordt dat gezien als een succes. Wanneer het niet door de test komt wordt de aanvraag geregistreerd als uitval. De meting wordt altijd uitgevoerd, dus gedurende 24 uur per dag, op alle dagen (24*7). 4.3

Rapportage van service niveau naar de klant

De service niveaus die behaald zijn, worden real-time gerapporteerd aan de klant. Een voorbeeld van dit rapport staat hieronder:

Pagina 15/36


Rapportage omtrent de performance is online en realtime beschikbaar. Zie https://trust.salesforce.com/trust/status/10

10

Zie bijlage C voor de inhoud van deze pagina

Pagina 16/36


5

Probleemoplossingen en sancties

In deze SLA garandeert eMerus een bepaald niveau van beschikbaarheid en performance. Dit hoofdstuk behandelt twee aspecten die een rol spelen in de verzekering dat deze niveaus geleverd worden. Het eerste deel is een beschrijving van de opties die eMerus tot zijn beschikking heeft om de beschikbaarheid te vergroten in het geval dat de gegarandeerde niveaus niet gehaald worden. Het tweede deel beschrijft de sancties die overeengekomen zijn tussen eMerus en Opdrachtgever in het geval dat eMerus de gegarandeerde niveaus niet behaalt. 5.1

Oplossingen

Voor een aantal probleemscenario’s zijn er al oplossingen bekend. Deze oplossingen worden in deze paragraaf beschreven. De oplossingen worden naar het type van het probleem gepresenteerd.

Oplossingen voor problemen met beschikbaarheid 1) Er is een serieus ongeluk (brand etc.) in de hoofd hosting faciliteit, die kritieke hardware, aanwezig in deze faciliteit, vernietigt. De applicatie draait op het force.com platform. Wanneer deze situatie zich voordoet zal de applicatie en alle bijbehorende data automatisch vanuit een ander data center beschikbaar worden gesteld. 2) Veiligheidsinbreuken en hack-pogingen worden zo hevig dat force.com genoodzaakt is om (delen van) de infrastructuur af te sluiten. Wanneer het lek is geanalyseerd en hersteld wordt er een snelle controle uitgevoerd. Na een succesvolle afhandeling worden de services een voor een beschikbaar gemaakt. Onregelmatige downtime kan verwacht worden na zo’n incident door terugkerende hacking pogingen en/of herhaalde denial of service (DOS) aanvallen.

Oplossingen voor problemen in de performance van de standaard applicatie 1) Een groeiend aantal klanten (of aantal medewerkers) resulteert in een ondercapaciteit van de performance. De eMerus applicatie schaalt automatisch met het gebruik. Per periode kunnen in ieder geval 10.000 medewerkers verwerkt worden. De volgende tabel geeft een overzicht van normale performance: Naam scherm/actie Benodigde tijd* Oproepen stamgegeven Maximaal 2 seconden Muteren stamgegevens Maximaal 3 seconden Opzoeken medewerker (bv via achternaam) Maximaal 2 seconden Schermovergangen Maximaal 2 seconden Verwerken ESS aanvraag Maximaal 2 seconden Uitvoeren standaard rapport Tussen de 2 en 30 seconden *Hierbij is uitgegaan van een gemiddelde van 3 aanroepen voor hetzelfde scherm. Tevens wordt hierbij uitgegaan van de pagina generatie tijd. Dit is de tijd die nodig is tussen het ontvangen van het verzoek op de server, tot en met het opleveren van het verzoek op de server. Alle overige tijd is dus dataverkeer en procesverkeer bij de gebruiker.

Afwijkingen op de hierboven genoemde normale performance kunnen door de gebruiker aangemeld worden als incident. Dit incident zal worden meegenomen in het periodieke performance overleg dat plaatsvindt binnen eMerus. Dit kan resulteren in nader onderzoek bij de gebruiker, danwel een verbetering vereisen in de software aan de kant van eMerus.

Pagina 17/36


2) Veiligheidsinbreuken en hack-pogingen worden zo hevig dat het systeem overbelast raakt en erg langzaam wordt. Dit wordt opgelost met dezelfde procedure als wanneer de eMerus omgeving afgesloten wordt door veiligheidsincidenten. 5.2

Sancties

Wanneer eMerus niet het gegarandeerde niveau van beschikbaarheid of functioneren behaald, is er een aantal sancties mogelijk. Sancties gelden voor verminderde beschikbaarheid en voor verminderde performance. Verminderde beschikbaarheid wordt als belangrijker gezien dan verminderde performance, omdat de consequenties voor Opdrachtgever groter zijn wanneer het systeem niet beschikbaar is dan wanneer het systeem langzaam is. Uiteraard zal eMerus iedere verminderde performance melding serieus onderzoeken en indien binnen bereik van eMerus zo spoedig mogelijk verbeteren.

Maandelijks percentage licentie teruggave bij verminderde beschikbaarheid Een service downtime groter dan 1,0 %, gemeten over een gehele kalendermaand, zal tot terugbetaling leiden aan Opdrachtgever. De teruggave wordt berekend op basis van het maandelijkse abonnementsbedrag. Wanneer de werkelijke beschikbaarheid 1% onder het niveau van 99,9% ligt zal 1% van het maandelijkse abonnement bedrag terugbetaald worden aan Opdrachtgever. De terugbetaling dient geclaimd te worden binnen één maand nadat de verminderde beschikbaarheid heeft plaatsgevonden. Recht op contractbeëindiging Contractbeëindiging is mogelijk voor Opdrachtgever wanneer het beschikbaarheidspercentage voor minstens drie opeenvolgende maanden lager is dan 98,9%. Er is een uitzondering, namelijk wanneer er een verminderde beschikbaarheid is van twee maanden als gevolg van een enkelvoudig incident (start van het incident in de eerste maand en eindigend in de tweede maand).

Pagina 18/36


6

Releases

Salesforce komt 3 keer per jaar met een nieuwe release van het force.com platform. Deze releases vergroten de algemene functionaliteit van het platform. Daarnaast ontwikkelt eMerus nieuwe functionaliteit specifiek voor haar applicatie. eMerus stelt meerdere keren per jaar nieuwe releases ter beschikking aan de klanten. Deze releases bevatten zowel nieuwe functionaliteit als bug fixes. Voorafgaand aan een release worden release notes beschikbaar gesteld aan de Super User. Indien de Opdrachtgever over een sandbox (acceptatieomgeving) beschikt, zal de release eerst worden uitgerold op deze sandbox. In overleg met de Super User wordt de release op de productie-omgeving geïnstalleerd. Roadmap Ontwikkeling van nieuwe functionaliteiten gebeurt zowel op basis van wensen en verzoeken van onze (potentiele) klanten alsmede op basis van algemene ontwikkelingen in de markt. De input van klanten komt tot stand doordat klanten wijzigingsverzoeken indienen, richting accountmanager wensen uiten of deelnemen in (nog op te richten) gebruikersgroepen. Ook worden er vanuit de zijde van eMerus thema’s bepaald op basis van ontwikkelingen in de markt die leiden tot nieuwe functionaliteiten in de applicatie. Op verzoek stelt eMerus een overzicht beschikbaar van de verwachte inhoud van de komende release. De inhoud van een komende release is pas definitief nadat de release door de ontwikkelafdeling is gesloten. 6.1

Release procedures

Standaard applicatie De release strategie van eMerus bestaat uit drie delen: 1. Major releases 2. Minor releases 3. Patches Major releases bevatten functionaliteit die significante veranderingen of verbeteringen in de gebruikerservaring betreffen. Deze functionaliteiten zijn tot stand gekomen na te zijn opgenomen in de roadmap, waarna ze zijn besproken en goedgekeurd door de Change Advisory Board (CAB). Minor releases bevatten kleine verbeteringen en aanpassingen in functionaliteit, waaronder nieuwe velden of schermen. Gebruikers kunnen kleine bugs en ideeën aandragen om de applicatie te verbeteren. Beide worden besproken in de Change Advisory Board (CAB). Wanneer de CAB een verandering goedkeurt, zal het meegenomen worden in een minor release, die al op de roadmap stond gepland. Patches bevatten bug fixes of kleine verbeteringen in functionaliteit, maar patches bevatten geen nieuwe velden of schermen. Een patch kan worden geïnitieerd door een gebruiker die een probleem of idee aangeeft aan de eMerus service desk. De service desk procedures worden in hoofdstuk 8 beschreven. Major en minor releases zullen beschreven worden door eMerus en zullen, door middel van een email nieuwsbrief met de release notes, minstens vijf werkdagen van tevoren gecommuniceerd worden naar alle Super Users. Patches die een bug oplossen kunnen dagelijks worden geïnstalleerd en worden persoonlijk teruggekoppeld aan de Super Users die de melding bij de ServiceDesk hebben gedaan volgens de service desk procedure in hoofdstuk 8. Maatwerk Wijzigingen aan het maatwerk met specifieke functionaliteit voor Opdrachtgever zullen altijd ter acceptatie worden opgeleverd aan de Super User op een acceptatieomgeving. Pas na expliciete goedkeuring zal de wijziging worden doorgevoerd op de productie omgeving. Het patchen van maatwerk vindt plaats buiten kantoortijden, tenzij Opdrachtgever aangeeft dat dit niet gewenst is of

Pagina 19/36


als er sprake is van een level 1 incident op het maatwerk. eMerus zal na patchen de basale werking van het maatwerk controleren. 6.2

Security en systeempatches

Op de systemen waar de eMerus applicaties op draait worden de noodzakelijke patches uitgevoerd tijdens het reguliere onderhoudswindow. Indien een security patch wordt uitgebracht waarvoor niet gewacht kan worden tot het reguliere onderhoudswindow zal onmiddellijk worden overgegaan tot installatie. Dit zal normaal gesproken geen gevolgen hebben voor de beschikbaarheid van de applicatie. Mocht dit onverhoopt toch tot verminderde beschikbaarheid leiden, dan wordt dit meegeteld als down-time.

Pagina 20/36


7

Back-up, redundantie en noodherstel

eMerus garandeert de continuïteit van de opgeslagen gegevens in de applicatie, via een gecertificeerd mechanisme van back-up, systeem redundantie en noodherstel. 7.1

Back-ups van data

De volgende back-up procedures bestaan: • Alle data wordt ge-back-upt naar tape op iedere datacenter. Dit gebeurt op een roterend schema van volledige en incrementele back-ups. • De back-ups worden via een beveiligde verbinding gecloned naar een beveiligd tape archief. • Tapes worden NIET offsite gehaald en worden op een veilige manier vernietigd wanneer ze aan het einde van hun levensduur zijn. • Alle verwijderde records/documenten kunnen tot 15 dagen na verwijdering teruggehaald worden middels de Recycle Bin. • Alle verwijderde data die ouder is dan 15 dagen, maar minder oud dan 3 maanden kan via een Data Recovery worden teruggehaald. Klanten kunnen aanvullend ook een wekelijkse export van de data maken. Deze data wordt automatische in gecomprimeerde .csv bestanden geplaatst en hiervan wordt ter bevestiging een mail gestuurd naar de beheerder die de export heeft aangevraagd. De mail bevat een link naar een beveiligde pagina, waar de beheerder de data bestanden kan downloaden. Deze optie is beschikbaar via: Setup | Administration Setup | Data Management | Data Export. De wekelijkse export service is alleen beschikbaar voor klanten met een eigen Salesforce omgeving. 7.2

Systeem redundantie

Het systeem is redundant op meerdere niveaus: 1. Data wordt opgeslagen op redundante disks. De uitval van een disk is niet kritiek en wordt automatisch afgehandeld. 2. Verschillende servers voeren dezelfde taak uit. Uitval van een server is niet kritiek en wordt automatisch afgehandeld. 3. Voorzieningen zoals, (nood)stroom, koeling, Internet toegang, brandpreventie zijn allen minstens dubbel uitgevoerd. 7.3

Herstel parameters (hoe snel kan de data hersteld worden)

Zoals eerder in dit document beschreven is, kan verloren data die korter dan 15 kalenderdagen geleden verwijderd is, hersteld worden via de recycle bin. De data is dan onmiddellijk beschikbaar. Data die langer dan 15 dagen gelden is verwijderd, maar niet langer dan drie maanden kan via een Data Recovery worden hersteld. Hieraan zijn zeer hoge kosten verbonden vanwege het handmatige karakter van de vereiste handelingen (al snel ca € 10.000). De kosten die gepaard gaan met dataherstel komen voor rekening van Opdrachtgever. De periode die nodig is voor een data recovery bedraagt minimaal drie weken. De herstelde data wordt opgeleverd in CSV formaat. 7.4

Prioriteit en proces voor noodherstel

Noodherstel is een automatisch mechanisme en werkt in principe zonder verlies van beschikbaarheid en zonder verlies van data. Het force.com platform heeft dit mechanisme ingebouwd en vormt daarmee een integraal onderdeel van de oplossing die eMerus aanbiedt.

Pagina 21/36


Pagina 22/36


8 8.1

Support en Servicedesk services De Servicedesk

eMerus biedt ondersteuning aan Opdrachtgever door middel van de Servicedesk op de standaard applicatie(s), op klantspecifieke delen van de applicatie en op gebruikersvragen. De Servicedesk is het aanspreekpunt van eMerus voor (geautoriseerde) medewerkers van de Opdrachtgever welke voldoende kennis van HR2day hebben om gerichte en ter zake doende ondersteuningsverzoeken te doen. De taken van de Servicedesk zijn: - het aannemen van ondersteuningsverzoeken (calls) van Opdrachtgever; - het zorg dragen voor het juist registreren van gemelde verstoringen (incidenten) en overige verzoeken om ondersteuning (service requests); - het oplossen van de service request of het routeren van de service requests en gemelde incidenten naar de voor de oplossing verantwoordelijke persoon; - de bewaking op en rapportage over de voortgang en afhandeling van calls; - de terugkoppeling naar de Opdrachtgever en - de publicatie van mededelingen, informatiebulletins en handleidingen. Meldingen (calls) mogen uitsluitend worden ingediend door daartoe geautoriseerde personen. Opdrachtgever kan medewerkers laten autoriseren voor het indienen van calls. De aanmelder van vragen dient, voor zover redelijkerwijs mag worden verwacht, op de hoogte te zijn van de werking van HR2day en over de nodige materiekennis te beschikken. Incidenten en requests kunnen zowel telefonisch of per (bij voorkeur) e-mail worden aangemeld. 8.2

Standaard support en Servicedesk beschikbaarheid

Standaard support, zoals deze beschreven is in het contract tussen Opdrachtgever en eMerus, wordt verleend tijdens Centraal Europese kantooruren (CET). Voor telefonische vragen en meldingen is de ServiceDesk bereikbaar van 08.00 tot 18.00 uur. Voor vragen en meldingen die per e-mail worden ingediend geldt geen sluitingstijd; deze meldingen worden bij de eerstvolgende opening van de ServiceDesk in behandeling genomen. De ServiceDesk registreert calls per call en per aanmelder en voorziet deze (voor interne en rapportage doeleinden) van een callnummer. 8.3

Methoden van contact

Meldingen, vragen en verzoeken om informatie kunnen gestuurd worden naar [email protected] of gemeld worden via telefoon: +31(0)88 0300 911. Meldingen (calls) mogen uitsluitend worden ingediend door daartoe geautoriseerde personen. Opdrachtgever kan medewerkers laten autoriseren voor het indienen van calls. Procedure voor calls 1. Klanten melden incidenten (calls) bij een medewerker via een kanaal. 2. Medewerker legt (eventueel achteraf) de call vast in het service tool, inclusief prioriteit. 3. De call wordt door de medewerker die de call vastlegt gekoppeld aan een eigenaar. Als die eigenaar iemand anders is dan de vastlegger zelf, stelt de vastlegger de eigenaar er van op de hoogte dat de bewuste call op diens naam gezet is 4. De eigenaar van de call is verantwoordelijk voor de call; 5. De eigenaar van de call zorgt er voor dat de klant op de hoogte gehouden wordt van de status van de call, alsmede geïnformeerd wordt over de oplossing of oplossingsrichting

Pagina 23/36


6. Indien de eigenaar niet in staat is de call (tijdig) op te lossen, wordt deze overgedragen aan een collega en/of de klant geïnformeerd dat de oplossing langer duurt. 7. Zodra de klant bevestigt of als de medewerker in kwestie concludeert dat de call is opgelost wordt deze gesloten. 8. Als een verzoek niet direct ingewilligd kan worden omdat het aanpassingen in de software vereist die niet op korte termijn doorgevoerd kunnen worden, dan kan de call gesloten worden zodra het request op de ontwikkelagenda geplaatst is 9. Een call kan nooit gesloten worden als de klant nog geen adequaat inhoudelijk antwoord gekregen heeft. 10. Er is een vaste set aan prioriteiten, waarvan er verplicht een aan de call wordt gekoppeld 11. Het is verplicht om een datum binnenkomst te registreren. Datzelfde geldt voor datum eerste reactie en datum afgehandeld 8.4

Call definities en prioriteiten

Call definities: Gebruikersvraag Een vraag wordt gezien als gebruikersvraag wanneer gebruikers vragen stellen over hoe de eMerus applicaties werken, bijvoorbeeld vragen als ‘Waar kan ik…?’ of ‘Hoe doe ik..?’. In het algemeen gaan gebruikersvragen niet over fouten in de applicatie. Een gebruikersvraag krijgt classificatie niveau 4. Wijzigingsverzoek Een wijzigingsverzoek kan een verzoek zijn voor een verbetering in de bestaande functionaliteit van de standaard applicatie, of een verzoek voor een specifieke aanpassing. Het aanpassen voor klanten, voor bijvoorbeeld het veranderen van een workflow of het maken van export van gegevens, is een specifieke opdracht en dit houdt implementatie en leveringskosten in. Een indicatie van deze kosten zal gecommuniceerd worden en moet goedgekeurd worden voordat het verzoek in behandeling genomen zal worden. Ook een wijzigingsverzoek krijgt classificatie niveau 4. Incident niveau 1 Een urgente fout in de applicatie krijgt als classificatie niveau 1 indien bedrijfskritische functies volledig zijn geblokkeerd. Incident niveau 2 Wanneer een fout wel optreedt in bedrijfskritische functies maar het is wel mogelijk om ondanks de fout, middels een work around, door te werken wordt het niet geclassificeerd als urgent en wordt het gezien als een incident van niveau 2. Incident niveau 3 Een fout met een lage prioriteit is een fout die optreedt in de eMerus applicatie en als storend wordt ervaren, maar geen bedrijfskritische functies omvat. Een dergelijk incident krijgt een prioriteitsclassificatie niveau 3. 8.5

Reactietijd en Oplostijd

De reactietijd is de tijd tussen de melding van de call en de inhoudelijke reactie door eMerus zoals beschreven in de call procedure. Deze reactie kan direct de oplossing van de call betreffen of een mededeling op welke wijze en binnen welke termijn tot oplossing zal worden overgegaan. De reactie tijd verschilt per kanaal langs welke de call wordt aangeleverd Kanaal van call aanleveren Telefoon e-mail

Reactie tijd * Direct Zo snel mogelijk, maar uiterlijk 8 uur

* Kantooruren en werkdagen, waarbij wij streven naar het reageren op minimaal 90% van alle calls binnen de genoemde reactietijd

Pagina 24/36


Oplostijd is gedefinieerd als de tijd tussen tijd waarop de call in behandeling wordt genomen (binnen de reactietijd) en de werkelijke oplossing van de call door de eMerus Servicedesk. Type van call Niveau 1 incident*** Niveau 2 incident Niveau 3 incident Niveau 4 incident

*

Oplostijd * Zo snel mogelijk, maar uiterlijk 8 uur** Zo snel mogelijk, maar uiterlijk 2 dagen Zo snel mogelijk, maar uiterlijk 5 dagen Vragen zo snel als de bezetting op de Service Desk mogelijk maakt Aanpassingen in workflow, inrichting parameters, autorisatiewijzigingen, etc in overleg Wijzigingsverzoeken mogelijk in een volgende release van de applicatie

***

Gemiddelde over 1 kalenderjaar, gerekend in kantooruren en werkdagen. Wij streven ernaar meer dan 80% van alle calls op te lossen binnen de genoemde oplostijden. Indien een individuele case niet binnen de aangegeven oplostijd kan worden opgelost zullen wij voor het verstrijken van de oplostijd in overleg treden met de Super User. Afhankelijk van het tijdstip waarop het issue wordt gemeld en de impact die gepaard gaat met het herstellen wordt getracht de service nog dezelfde dag te herstellen. De genoemde responstijd kan alleen worden gehaald bij het indienen van de call via de telefoon

8.6

Klachtenprocedure

**

Een klacht wordt gezien als een ‘uitdrukking van ontevredenheid bij de klant over de verleende services door eMerus’. Iedere klacht kan gestuurd worden naar het email adres [email protected]. Binnen een werkdag na het ontvangen van de klacht, zal eMerus een ontvangstbevestiging sturen naar de klant, met de naam van de persoon die de klacht in behandeling heeft. Deze persoon zal zo snel mogelijk contact opnemen met de klant, op zijn laatst binnen twee werkdagen. De oplossing/sluiting van een klacht zal in alle gevallen gecommuniceerd worden aan de klant. 8.7

Escalatieprocedure

In geval van nood of in gebreke blijven van eMerus kan de Super User of contracteigenaar een escalatie starten. In Bijlage A is een contact en escalatie matrix opgenomen. De escalatieprocedure kent drie escalatie niveau’s: 1. Manager Service Delivery (bij calls tijdens exploitatie) / consultant (tijdens implementatie) 2. Accountmanager 3. Directie 8.8

Opleidingsvereisten

Opdrachtgever heeft de plicht zeker te stellen dat alle mensen getraind zijn voordat zij beginnen te werken met de applicatie. Alleen gebruikers die op de juiste manier getraind zijn door een eMerus trainer/consultant hebben het recht op ondersteuning van de Servicedesk. De kosten van het oplossen van problemen die veroorzaakt zijn door een ongetraind persoon die werkt met de applicatie kunnen doorberekend worden aan Opdrachtgever. 8.9

Rapportage over ondersteuning en Servicedesk services

Opdrachtgever kan op verzoek maandelijks een rapportage ontvangen over de Servicedesk services.

Aantal service desk calls per type per maand Pagina 25/36


Maand 2014-01

2014-02

Type Niveau Niveau Niveau Niveau Niveau Niveau

1 2 3 4 1 2

incident incident incident incident incident incident

Aantal verstuurd 3 5 12 14 0 1

Aantal open 0 0 0 3 0 0

8.10 Bespreken service verlening Periodiek zal de eMerus Account Manager overleg voeren met de Super User en/of de Contract eigenaar over de dienstverlening.

Pagina 26/36


9

Beëindiging van de diensten

De data is en blijft eigendom van Opdrachtgever. Tot en met de beëindiging van de Diensten om welke reden dan ook, kan Opdrachtgever zelf, zonder tussenkomst van eMerus een kopie maken van alle op de systemen van eMerus aanwezige data en gegevens van Opdrachtgever. Tevens kan eMerus op verzoek van Opdrachtgever, tegen vergoeding van de hiervoor te maken kosten, een kopie verschaffen van de op het moment van beëindiging op de systemen van eMerus aanwezige gegevens van Opdrachtgever. Deze ondersteuning vindt op nacalculatie basis plaats tegen de overeengekomen uurtarieven. Opdrachtgever dient het verzoek daartoe bij opzegging doch uiterlijk binnen 2 maanden voorafgaand aan de werkelijke beëindiging van de Diensten schriftelijk te doen. eMerus zal na beëindiging van de Diensten geen gebruik meer maken van de gegevens van Opdrachtgever. eMerus zal deze gegevens, zoveel als praktisch mogelijk, wissen uit haar systemen binnen een maand na de beëindiging van de Diensten indien Opdrachtgever hier schriftelijk om heeft verzocht. eMerus heeft geen verplichting deze gegevens te vernietigen of te wissen voor zover deze zich op back-up media bevinden. eMerus zal dergelijke gegevens voor geen enkel doel gebruiken en ze gedurende de retentieperiode op dezelfde wijze tegen misbruik beveiligen als operationele data van productieve opdrachtgevers. 9.1

Tijdsperiode voor beschikbaar stellen van data

Data kan tot op de laatste dag van het abonnement geëxporteerd worden met behulp van standaard beschikbare hulpmiddelen in het platform en de applicatie. Alle aanwezige data, ook documenten en plaatjes zijn beschikbaar voor gegevensexport. 9.2

Tijdelijke continuering van de diensten

Na opzegging van de diensten kunnen deze tijdelijk worden gecontinueerd (bijvoorbeeld in geval een nieuwe dienstverlener de dienstverlening niet tijdig operationeel heeft) onder de navolgende voorwaarden: - Eenmalige vergoeding ter hoogte van een maand abonnementstarief - Tarief per medewerker volgens de beëindigde gebruiksovereenkomst - Opzegtermijn van twee maanden 9.3

Beschikbaar houden van data voor raadpleeg- en conversiedoeleinden

eMerus kan op verzoek van de Opdrachtgever de klantomgeving van de applicatie na afloop van de abonnementsperiode beschikbaar houden voor raadpleeg en conversie doeleinden. Hiertoe zal alsdan een nieuwe gebruiksovereenkomst worden afgesloten met beperktere rechten zodat Opdrachtgever geen mutaties meer kan verrichten, doch uitsluitend gegevens en data kan raadplegen en/of exporteren. De vergoeding van deze dienst bedraagt € 1.200 per gebruiker per jaar, met een minimum van twee gebruikers. De opzegtermijn bedraagt twee maanden en kan per jaar worden verlengd. 9.4

Procedures voor beëindiging

Procedures voor beëindiging zijn gespecificeerd in het contract tussen Opdrachtgever en eMerus BV alsmede de Algemene Voorwaarden van eMerus.

Pagina 27/36


Bijlage A Contactpersonen en adresgegevens

eMerus: Naam Marco Boerlage Opdrachtgever: Naam Nog nader te benoemen

Rol

Positie

Manager Service Desk

Directeur Operations

Rol

Positie

Super User

Functioneel beheerder Dienst verantwoordeli jke Wijzigingsbehe erder

Functioneel beheerder Contract eigenaar

Telefoon nummer +31 (0)88 0300 903

Email adres

Telefoon nummer

Email adres

[email protected]

eMerus en Opdrachtgever zullen de andere partij zo snel mogelijk informeren wanneer er een nieuwe contactpersoon wordt aangewezen. Contact en escalatie matrix Hieronder wordt een overzicht getoond van de contactpersonen binnen eMerus en inzake welke issues en op welke wijze deze benaderd kunnen worden. Wie Support Manager Service Delivery Consultant Accountmanager

Directie

Pagina 28/36

Wanneer 1e en direct aanspreekpunt voor de Superusers Escalatiepunt bij calls (CC: naar Accountmanager) Aanspreekpunt uitsluitend tijdens lopende projecten Advies, grotere wijzigingsverzoeken, escalatiepunt voor projecten, relatiebeheer, toekomst, visie etc. Tweede escalatie bij calls en performance van eMerus. Relatiebeheer, toekomst, visie. Laatste escalatie bij calls en performance van eMerus.

Hoe eMerus Service Desk +31 88- 0300 911 [email protected] Per project af te spreken Per klant af te spreken

+31 88 0300 901


Bijlage B https://login.salesforce.com/help/doc/en/getstart_browser_overview.htm (08-09-2014)

Pagina 29/36


Bijlage C https://trust.salesforce.com/trust/status/ (08-09-2014)

Pagina 30/36


Bijlage D https://trust.salesforce.com/trust/maintenance/ (08-09-2014)

Pagina 31/36


Bijlage E Innhoudsopgave Salesforce Limits Quick Reference Guide versie 31 juli 2014.pdf

Overview..........................................................................................................................1 Chapter 1: Salesforce Application Limits ...................................................................2 Salesforce Features and Editions Limits......................................................................................2 Salesforce Features and Editions Limits Table............................................................................2 Increased App Limits with Expansion Pack and Unlimited Apps Pack......................................9 Analytics Limits.........................................................................................................................10 Campaign Limits...........................................................................................................................................11 Chatter Limits...........................................................................................................................................12 Custom Field Limits...........................................................................................................................................14 Email Limits................................................................................................................................14 Salesforce Knowledge Limits.....................................................................................................16 Picklist Limits.............................................................................................................................17 Sites Limits.................................................................................................................................18 Workflow and Approval Limits..................................................................................................19 Data Related Limits.....................................................................................................................21 Dates: Valid Range for Date Fields.............................................................................................21 Import Limits...............................................................................................................................21 Rules Limits.................................................................................................................................22 Search Limits...............................................................................................................................23 Storage Capacity Limits...............................................................................................................24 File Related Limits.......................................................................................................................25 File Size Limits............................................................................................................................25 File Share Limits..........................................................................................................................26 Sandbox Limits............................................................................................................................26

Pagina 32/36


Chapter 2: Force.com Platform Limits.......................................................................27 Apex Limits.................................................................................................................................27 Apex Governor Limits.................................................................................................................27 API Limits....................................................................................................................................32 API Requests Limits.....................................................................................................................32 Bulk API Limits............................................................................................................................34 API Query Cursor Limits..............................................................................................................35 SOAP API Call Limits.............................................................................................................................................35 Streaming API Limits.............................................................................................................................................36 Email Limits.............................................................................................................................................37 Metadata Limits.............................................................................................................................................38 SOQL and SOSL Limits................................................................................................................38 Visualforce Limits..........................................................................................................................40

Index..................................................................................................................................42

Pagina 33/36


Bijlage F https://trust.salesforce.com/trust/security/ (08-09-2014)

Pagina 34/36


Bijlage G https://trust.salesforce.com/trust/practices/ (08-09-2014)

Pagina 35/36


Bijlage H https://trust.salesforce.com/trust/tools/

Pagina 36/36

(08-09-2014)


Service Level Agreement. Versie oktober 2014

Recommend Documents