Simulation based call center optimizer

Transcriptie

1

2 FACULTEIT INGENIEURSWETENSCHAPPEN VAKGROEP TECHNISCHE BEDRIJFSVOERING (tw18) Voorzitter: Prof. dr. ir. Rik Van Landeghem Simulation based call center optimizer door Sofie Pauwels Koen Van Hoe Promotor: Hendrik Vanmaele Begeleider: Peter Willen Scriptie ingediend tot het behalen van de academische graad van burgerlijk werktuigkundig elektrotechnisch ingenieur Academiejaar

3 Toelating tot bruikleen De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie. Sofie Pauwels datum: Koen Van Hoe

4 Dankwoord DANKWOORD: Dit eindwerk heeft ons de kans gegeven om de verzamelde theoretische kennis uit de verschillende vakken van de opleiding op een creatieve manier toe te passen op een praktijkgericht probleem. Bij het verschijnen van ons eindwerk verheugt het ons een aantal mensen te kunnen bedanken voor hun ondersteuning en hulp bij het welslagen van deze opdracht. In de eerste plaats gaat onze dank vanzelfsprekend naar onze promotor, met name Hendrik Vanmaele en onze begeleider Peter Willen. Roel De Haes bedanken we voor zijn hulp bij het programmeren van het model. Verder bedanken we de bedrijven die mee hebben geholpen door de audit in te vullen. Ook wensen we alle nog niet vermelde personen, die toch een bijdrage leverden, te bedanken voor hun hulp en tips. Tenslotte willen we onze dank richten tot onze ouders en vriend(inn)en voor de niet aflatende steun en moed om verder te zetten. De auteurs

5 Overzicht OVERZICHT: Simulatie based call center optimizer door Sofie Pauwels Koen Van Hoe Scriptie ingediend tot het behalen van de academische graad van burgerlijk werktuigkundig elektrotechnisch ingenieur Academiejaar Promotor: Hendrik Vanmaele Begeleider: Peter Willen Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Technische bedrijfsvoering Voorzitter: Prof. dr. ir. Rik Van Landeghem Samenvatting De organisatie en werkwijze in een contact center om de klant zo efficiënt en zo goed mogelijk te helpen is dezelfde in gans de call center industrie. Dit behandelen we in de inleiding. In hoofdstuk 2 bespreken we het doel van de thesis: het ontwikkelen van een simulatietool. Om de tool te ontwikkelen stelden we eerst een vragenlijst op. De antwoorden hierop gaven ons een dieper inzicht in de contact center wereld. Dit wordt in hoofdstuk 3 besproken. De ontwikkeling van de tool leggen we uit in het volgend hoofdstuk. Tevens werkten we enkele case studies uit met de tool. De resultaten hiervan kan men terugvinden in hoofdstuk 5. Trefwoorden: contact center, simulatie, Erlang C

6 Extended abstract Simulation based call centre optimizer Sofie Pauwels Koen Van Hoe Promoter(s): Hendrik Vanmaele, Peter Willen Abstract This article explains the development of a simulation model for call centres that tests and analyses different scenarios to understand their impact on a broader system or provide proof of concept evidence before moving forewords with implementation plans. The problem of minimizing staff costs is also considered, while maintaining an acceptable level of service in multiple time periods. Keywords Call centres, Enterprise Dynamics, Erlang I. INTRODUCTION call centre (also referred to as a contact A centre) is an important component of the operations of many organizations. Simulation modelling will become a more critical and common tool in contact centres as they grow in size, complexity, and diversity of media and transactions. To develop such a tool, we first had to examine thoroughly the contact centre world. Lots of information was found over the internet and in books, but to really empathize with this world we visited two large contact centres (Thomas Cook and Fortis) and put together an audit. II. Model We linked two programmes to make a simulation tool: Excel and Enterprise Dynamics (ED). Underneath you find the structure of the model: The model exists of 4 files (3 Excel files and 1 ED file): Input: The user has to fill in all the necessary information. With the aid of an Add-in in Excel we are able to work with standard Erlang-C calculations to determine the minimum number of agents per group and per time period to ensure satisfactory customer service. Optimization: With the number of agents found above, we select staff shifts that cover these requirements, by minimizing staff costs. The problem is complicated by the fact that staffing levels in one time period can affect service levels in subsequent periods. Moreover, staff schedules typically take the form of shifts covering several periods. Underneath you find the minimization problem. Min S. t. : With: n s pd, g x n T p d S Pd t = 1 s = 1 s, p d, g, t S s = 1 x s, p d, g c S Pd s, p d, g, t n x binair integer s, p d, g, t s, p d, g n s, p d, g s S m t, p d, g s S g G, d D Pd, g G, d D, t T t T, : # agents with shift s of schedule p, in group g. c : the cost of shift s of schedule p S Pd x = 1 if an agent of group g works on day d, in s, pd, g, t time period t; 0 if not m t, pd, g : # agents needed, in group g, in time period t, of day d Pd p d, g G, d D, g G, d D p d Model: With the data in the Input and the Optimization file, the simulation model is automatically build in ED. Figure 1: Simulation model

7 Extended abstract There are 10 teams available. Each team has his own set of skills. Phone Home wants to know how much money they should invest in educating the teams. Should they train the teams in such a way that each team can handle each call, or is it sufficient that the teams are less skilled? 1 SKILL 100% 90% Figure 2: close to reality model. 80% 70% 60% Idle type10 type9 type8 type7 Output: In this file all performance characteristics of all simulations are put together to compare with one another. 50% 40% 30% 20% 10% type6 type5 type4 type3 type2 type1 0% III. Case study A. General Case study Call centre Quest has 6 different call types and 3 different types. Quest currently works with 7 teams. The company wants to investigate if they would have the same performances with less agents if they combine some groups and if they would apply call blending (impr 3). Underneath you find the successive improvements. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 100% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 4 SKILLS groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 10 SKILLS Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 call types Now impr impr impr group BTB info 1 BTC info 2 1 BTB reparation 3 BTC reparation BTB orders 5 BTC orders info orders reparation 2 Figure 3: General case study B. Single versus Multi skilled Phone Home treats 10 different call types. All the call types have the same handling time. 80% 60% 40% 20% 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figure 4: Productivity of the teams when they have 1, 4 or 10 skill(s). It turns out that it is not necessary that the teams are fully flexible (10 skills). One can achieve almost the same results when they have 4 skills. IV. Conclusions This article presents the way a call centre simulation tool is build. With the case studies one can see that it is effective to train the teams so they have different skills (but not full flexibility). In other words, given the fact that total flexibility costs much money, it seems improbable that total flexibility is the best solution from economic perspective. The idle time is the smallest when call blending is used. However, call blending is sometimes not the optimal solution. Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1

8 Inhoudstafel INHOUDSTAFEL HOOFDSTUK 1: INLEIDING ALGEMEEN KLANTENPROFIEL B2B VERSUS B2C CUSTOMERSEGMENTATIE CONTACTPROFIEL PERFORMANTIEKARAKTERISTIEKEN KLANTENTEVREDENHEID SERVICE LEVEL FIRST CONTACT RESOLUTION AVERAGE SPEED OF ANSWER (ASA) ABANDONMENT COMPLEXITEIT WERKING VAN EEN CONTACT CENTER OVERZICHT FORECASTING De uitdagingen van forecasting Het doel van forecasting De standaard forecasting methode Updaten van forecasts STAFFING & SCHEDULING Staffing Shrinkage Scheduling ONDERSTEUNENDE TECHNOLOGIE VAAK TOEGEPASTE TECHNIEKEN CALL BLENDING MULTISKILLED OPERATOREN 15 HOOFDSTUK 2: DOEL VAN DE THESIS 17 HOOFDSTUK 3: AUDIT INLEIDING VERWERKING 19 HOOFDSTUK 4: MODEL WERKWIJZE HET EXCEL BESTAND INPUT DOEL STRUCTUUR 25

9 Inhoudstafel Timing Skill level Naamgeving Bedieningstijd Servicelevel+abandonment Forecast per call type Source #operatoren Call loads Service level Bedieningstijd Het aantal benodigde agenten # operatoren na optimalisatie HET EXCEL BESTAND OPTIMALISATIE DOEL STRUCTUUR timing Schedules, schedules 2 en schedules Optimalisatie Resultaat OPBOUW VAN DE PROGRAMMACODE IN VISUAL BASIC Situatie 1: Indien het een shift is met middagpauze en een kleine pauze voor of na de middag Tijd_1 werkblok_min <= werkblok _max Tijd_1 werkblok_min > werkblok_max Wegschrijven naar Excel Situatie 2: indien het een shift is met middagpauze zonder kleine pauze Situatie 3: indien geen middagpauze HET EXCEL BESTAND OUTPUT INTRO OCCUPATION OUTPUT ED-MODEL ALGEMEEN OPBOUW VAN HET SIMULATIEMODEL Aankomstpatroon van de oproepen Wachtrij (queue) Procentuele bezetting van de telefoonlijnen Abandonment De gemiddelde wachttijd Service level Verwerking van de oproepen Terminatie van de oproep OVERZICHT VAN HET SIMULATIEMODEL AANPASSING VAN DE ATOMEN QUEUE 66

10 Inhoudstafel On entered On exit On reset On OcReady MULTISERVER ATOOM Tabellen Tabel Tabel Events Eventcode Eventcode Eventcode Eventcode On Reset On entered On exited On user Inputstrategie FIFO QUEUE SL On User On 2dDraw LINK TUSSEN EXCEL EN ED OVERZICHT VAN HET MODEL 87 HOOFDSTUK 5: CASE STUDIES SINGLE SKILLED VERSUS MULTI SKILLED SITUATIESCHETS SIMULATIE1: SINGLE SKILLED SIMULATIE 2: 2 SKILLS SIMULATIE 3,4, SIMULATIE 6: 10 SKILLS GEMIDDELDE WACHTTIJDEN BESLUIT ALGEMENE CASE STUDIE GEGEVENS HUIDIGE SITUATIE Optimalisatie van de shifts Resultaten VERBETERINGSVOORSTELLEN Verbetervoorstel 1: BTB samenvoegen met BTC Aantal operatoren Bezettingsgraad Service levels Gemiddelde wachttijd Besluit Verbetering Aantal operatoren Bezettingsgraad 103

11 Inhoudstafel Service levels Gemiddelde wachttijd Aantal behandelde oproepen Abandonments Verbetering Aantal operatoren Bezettingsgraad Service levels Gemiddelde wachttijd Aantal behandelde oproepen Abandonments Besluit UURROOSTER OPTIMALISATIE Shifts van groep 1 voor een weekdag Shifts van groep 2 voor een weekdag Shifts van groep 1 en 2 voor de zaterdag Aantal benodigde telefoonlijnen 113 Bijlages: 114 Bijlage 1: Installatie simulatietool Bijlage 2: Audit Bijlage 3: Creatie van de shifts

12 Gebruikte termen After call work (ACW)/ wrap-up time De tijd die nodig is om het vorige telefoongesprek af te ronden, ofwel alle activiteiten die direct gerelateerd zijn aan het vorige gesprek maar waarvoor het niet nodig is de werkplek te verlaten. Het aannemen van een order van een klant en het daarna updaten van de database is een wrap-up activiteit. Vaak wordt een percentage van 10% van de average talk-time gebruikt om te bepalen of een activiteit wel of niet door de desbetreffende medewerker moet worden gedaan in wrap-up ACD (automatic call distribution) Een speciaal telefoonsysteem dat gebruikt wordt om inkomende gesprekken te behandelen. Het ACD herkent het binnenkomend gesprek en zoekt binnen zijn database naar de juiste zend instructies. Het telefoontje wordt vervolgens naar een IVR of een beschikbare agent gezonden (afhankelijk van de instructies) Agent De persoon die de telefoons afhandelt in een call center AHT (average handle time) De average talk time plus de average wrap-up time vormen samen de average handle time ASA (average speed of answer) De ASA is de gemiddelde snelheid waarin de telefoon wordt opgenomen, bij een service level van 95% binnen 30 seconden is de ASA ongeveer 4 tot 5 seconden Average Talktime De gemiddelde gespreksduur van een telefoongesprek, ofwel van "Hallo" tot "Tot ziens" Bezettingsgraad (occupancy) Call / contact blending Over het algemeen een percentage van geregistreerde tijd dat een operator in actief contact behandelen besteedt Het proces dat inbound / outbound oproepen combineert en andere contacten zoals s of webtransacties. Contact blending kan manueel worden toegepast of kan geautomatiseerd worden door een contact naar een agent te zenden die in staat is deze te behandelen Idle time Inactieve tijd van de operatoren (wanneer ze niets te doen hebben)

13 Gebruikte termen IVR Een apparaat dat het verwerken van informatie automatiseert door gebruik te maken van aanrakingstonen of stemherkenning om toegang te krijgen tot informatie die zich op de server bevindt, om een antwoord te geven. Het antwoord kan door een opgenomen menselijke stem of een samengestelde (geautomatiseerde) stem worden gegeven. IVR's worden vooral gebruikt in phone banking of om controle van een orderstatus uit te voeren Occupancy zie Bezettingsgraad Skill based routing Een methode waarbij de beller omgeleid wordt naar de voor hem meest bekwame operator, i.p.v naar de operator die het eerst vrij was of die al het langst vrij was. Skills Bekwaamheden SLA (service level agreement) Het percentage van de oproepen dat binnen de service level tijd 1 moet beantwoord worden. Meestal is dit 80% in 20 seconden. Wrap-up time zie After call work 1 De tijd die hoort bij het service level noemen we in de tekst: service level tijd. In dit geval is dit 20 seconden.

14 Hoofdstuk 1: Inleiding Hoofdstuk 1: Inleiding 1.1 Algemeen Letterlijk betekent call center een plaats waar vaak gebeld wordt. Meestal is dit een grote ruimte waar werkplaatsen zijn opgesteld met een pc en een telefoon (+ headset) als belangrijkste bureau-items. De laatste jaren is een call center enorm geëvolueerd. Door de voortdurende technologische evolutie moet men in een call center niet enkel telefoonoproepen behandelen; maar ook e- mails, chat berichten en zelfs nog brieven (deze soort oproepen groeperen we in de tekst onder de naam taken ). Hierdoor spreekt men niet langer meer over een call center maar eerder over een contact center. Het toepassingsgebied van call centra is zeer uitgebreid. Men komt ze in ongeveer alle takken van de industrie tegen, zoals bijvoorbeeld de banksector, reissector, nutsbedrijven, Het ene call center is al groter dan het andere. Zo bestaan er call centra met enkele operatoren. Daartegenover staan call centra met honderden werknemers. Contact centra zijn er dus in alle maten en gewichten, waarbij ook nationale verschillen het karakter bepalen. Wie optimaal gebruik wil maken van een call center (of van een contact center via ), moet vooraf de volgende punten realiseren: Het contact center moet voorbereid zijn op de rol als communicatiemiddel en dus over alle relevante informatie beschikken. Besef dat het contact center een 'single point of entry' is en een primair bedrijfsproces dat staat voor de rest van de organisatie. Gaat er daar wat fout, dan werkt dat overal door. Verder moet het contact center-proces aansluiten op het bedrijf en de back office. Vooral marketing- en salesafdelingen gaan hiermee nogal eens de fout in. Het contact center is core business. 1

15 Hoofdstuk 1: Inleiding 1.2 Klantenprofiel B2B versus B2C Klanten van een contact center kunnen meestal in twee grote groepen worden onderverdeeld. Enerzijds zijn er de Business-to-Business (bedrijf bedrijf; B2B) klanten, anderzijds de Business-to-Consumer (bedrijven consumenten; B2C) klanten. Bv. bij reisagentschappen: zijn er de gewone reizigers die een vakantie willen boeken (B2C) en zijn er de reisbureaus die boekingen willen uitvoeren (B2B) Customersegmentatie In vele call centra maakt men gebruik van customersegmentatie. Dit wil zeggen dat men de klanten onderverdeelt in verschillende groepen (segmenten), die dan gerangschikt worden van meest naar minst belangrijke op basis van één of meerdere criteria. B2B en B2C is een mogelijke onderverdeling. Per segment kan er een ander service level (zie verder) gehanteerd worden. Meestal past men segmentatie toe, door het toekennen van prioriteiten aan de verschillende oproepen. Zo zal de oproep (call) met hoogste prioriteit voorrang krijgen op de rest en zal hij eerst worden beantwoord. 1.3 Contactprofiel Men onderscheidt inbound en outbound contact centra. Bij outbound neemt het contact center zelf het initiatief om mensen op te bellen, terwijl bij inbound het de geïnteresseerde consument, de potentiële klant is die productinformatie vraagt of een bestelling wil plaatsen of nog, de verontwaardigde koper die zijn beklag wil doen over het aangeschafte product. Enkele taken gegroepeerd per soort zijn: Inbound contact center Klachtenbehandeling Dienst na verkoop Het opnemen van bestellingen Verkoopsgesprekken Helpdesk / informatiedienst Outbound contact center Nieuwe klanten werven Verloren klanten terugwinnen Marketingdatabase actualiseren Onbetaalde facturen opvolgen 2

16 Hoofdstuk 1: Inleiding Soms hanteert men in een call center beide filosofieën, zowel inbound als outbound oproepen. Dan eindigt de taak niet bij het beantwoorden van binnenkomende telefoontjes. Men belt dan ook zelf: bijvoorbeeld om de promotionele acties van de marketingafdeling te ondersteunen. Marketing weet wanneer de kalme periodes zijn. Zo zitten de operatoren nooit stil. Daarnaast kan men ook onbeantwoorde oproepen recupereren (call back systeem): het systeem geeft de telefoonnummers van de mensen die voortijdig hebben ingehaakt op onverwacht drukke momenten kan de wachttijd wel eens oplopen en men belt ze dan zelf terug. Mensen appreciëren dit enorm, alle irritatie is dan op slag verdwenen. 1.4 Performantiekarakteristieken Klantentevredenheid Klantentevredenheid vloeit voort uit verschillende facetten, zoals bijvoorbeeld: de kwaliteit van het antwoord, de wachttijd van de klant, de kost voor de klant, de vriendelijkheid van de operatoren, enz Service level Het begrip service level is de meest gehanteerde metric wat klantentevredenheid betreft. Het wordt meestal gedefinieerd als het percentage oproepen dat in een bepaald tijdsinterval (meestal 30 minuten) binnen een bepaald aantal seconden wordt beantwoord. Standaard is dat 80% van alle oproepen binnen de 20 seconden moeten beantwoord zijn. (Hoewel er een trend waar te nemen is naar 70% in 30 seconden). Indien het call center verschillende types oproepen behandelt, kan voor ieder type een verschillend service level vooropgesteld worden. Waarbij men typisch hogere eisen stelt bij bijvoorbeeld verkoopoproepen dan bij klachtoproepen First contact resolution Uit studies blijkt dat bereikbaarheid maar een bijrol speelt in klantcontact. Het gaat bij de klant om inhoud en kennis van zaken, niet zozeer om snelheid. Hoe minder men tevreden is met de oplossing (of antwoord), hoe minder tevreden men is over de wachttijd. Als je geen antwoord hebt gekregen, ben je even ontevreden, of je nu kort of lang hebt moeten wachten. Bereikbaarheid gaat maar een rol van enige betekenis spelen wanneer er een bevredigend antwoord is gegeven. Daarom is first contact resolution één van de belangrijkste prestatie- 3

17 Hoofdstuk 1: Inleiding indicatoren. Deze berekent het percentage van klanten die na hun eerste contact met het call center reeds een volledig antwoord gekregen hebben (men moet dus niet meer terugbellen) Average speed of answer (ASA) Dit is de gemiddelde tijd tussen het binnenkomen van een oproep en de opname door een telefonist(e). In feite geeft de ASA de gemiddelde tijd aan die een binnenkomende oproep moet wachten voordat hij wordt beantwoord Abandonment Wanneer de klant te lang moet wachten vooraleer hij/zij iemand aan de lijn krijgt, zal de klant inhaken. Men spreekt van een abandonment. Wanneer er veel abandonments voorkomen, is dit uiteraard nefast voor het imago van het call center. De klant zal naar de concurrentie gaan waar hij/zij wel degelijk geholpen wordt. Het in de hand houden van de abandonment rate vormt een belangrijke taak voor de call center manager. Het aantal abandonments kan gereduceerd worden door een groot aantal operatoren te voorzien. Ook dit is niet goed omdat de productiviteit van het personeel dan veel te laag zal zijn. Het call center betaalt dan arbeiders om met hun vingers te zitten draaien. De call center manager moet voortdurend wikken en wegen tussen enerzijds een hoog service level, een lage ASA en een lage abandonment rate en anderzijds een hoge productiviteit. 1.5 Complexiteit De te behandelen oproepen in een inbound call center komen op willekeurige momenten binnen. Om deze reden heeft de call center manager het moeilijk om een juiste planning op te maken. De manager wordt geconfronteerd met de volgende vragen: Welk service level moet hij/zij vooropstellen? Hoeveel operatoren zijn vereist om het vooropgesteld service level te halen op elk moment? Hoeveel operatoren moet hij/zij inschakelen zodat de operatorkost toch nog aanvaardbaar is? 4

18 Hoofdstuk 1: Inleiding Welke skills moeten op welk moment aanwezig zijn? Het feit dat in een call center naast de telefonische oproepen vaak ook s moeten beantwoord worden, vereenvoudigt de planningstaak van de manager niet. De uitbreiding van het takenpakket heeft ook zijn positieve gevolgen: De operatoren krijgen meer afwisseling, hetgeen bevorderlijk is voor hun motivatie. De productiviteit stijgt. De operatoren kunnen op momenten van overstaffing andere zaken doen zoals bijvoorbeeld s beantwoorden. 1.6 Werking van een contact center Overzicht Forecasting: Staffing: Scheduling: Opvolging: Rapportering: Voorspellen van de call load Bepalen van aantal benodigde operatoren Inroosteren van de operatoren Monitoring Werden de doelen bereikt? De manier waarop de meeste contact centra zichzelf organiseren om de oproepen zo goed en zo efficiënt mogelijk te behandelen, kan je samenvatten in een 5-tal processen: Forecasting Staffing Scheduling Opvolging Rapportering In het forecasting proces maakt men een zo goed mogelijke voorspelling van het aantal oproepen dat er zullen binnenkomen. Op basis van deze voorspelling en op basis van de te bereiken prestatieparameters (service level, ASA,..) berekent men in het staffing proces het aantal benodigde operatoren via de Erlang formule (of via simulatie). 5

19 Hoofdstuk 1: Inleiding Het benodigd aantal operatoren dient dan in shifts onderverdeeld te worden. Dit gebeurt in het scheduling proces. Dit is noodzakelijk omdat je moet voldoen aan de sociale wetgeving: operatoren mogen maar een beperkt aantal uren werken per dag. Tijdens de werking hebben sommige contact centra de mogelijkheid om indien nodig flexibele operatoren in te zetten. Dit is mogelijk door de prestatieparameters op de voet te volgen (monitoring). Door de behaalde resultaten frequent te rapporteren kan men de werking van het contact center verder optimaliseren (rapportering). We leggen hieronder kort uit wat de verschillende processen inhouden Forecasting Vooraleer je het benodigd aantal operatoren kan bepalen moet je eerst een idee hebben van de hoeveelheid oproepen die je zal moeten behandelen. Je moet dus eerst en vooral een forecast maken De uitdagingen van forecasting Forecasting in call centra is niet eenvoudig omwille van een aantal redenen: Forecasts moeten gedetailleerd zijn, om de 15 à 30 minuten moet men een forecast hebben. Forecasts moeten precies zijn. Forecasts hangen af van vele factoren; sommige van deze factoren zijn op voorhand bekend, andere dan weer niet: o Tijdstip van de dag o Dag van de week o Seizoen schommelingen o Vakanties o Omstandigheden van het weer o Er zijn vele relaties tussen het volume oproepen op verschillende ogenblikken. Wanneer het volume oproepen hoog is in het begin van de dag, toont de ervaring aan dat het volume oproepen hoog zal zijn gedurende de ganse dag. Met andere 6

20 Hoofdstuk 1: Inleiding woorden, er heerst dus een positieve correlatie tussen het volume oproepen in verschillende periodes. Relevante data ontbreekt dikwijls Het doel van forecasting Het doel van forecasting bestaat erin om betrouwbare schattingen van de verschillende parameters te berekenen die nodig zijn voor het call center management. De volgende parameters moeten geschat worden voor ieder planningsinterval en voor ieder type oproep: het aantal inbound oproepen de bedieningstijd wrap-up tijd 2 Het aantal inbound oproepen varieeert sterk over de loop van de dag en kent de hoogste variabiliteit. Bedieningstijd en wrap-up tijd kennen een veel kleinere variabiliteit De standaard forecasting methode Het forecasting proces is zowel een kunst als een wetenschap. Kunst omdat je de toekomst voorspelt waarbij de nauwkeurigheid van de forecast afhangt van de ervaring en de oordeelkunde van de manager. Daartegenover is het forecasting proces ook een wetenschap omdat het een stap voor stap mathematisch model hanteert die historische informatie gebruikt om de toekomst te voorspellen Updaten van forecasts Men maakt een forecasting om de paar weken wanneer de nieuwe operator schema s gemaakt worden. Hoewel, dit is niet het enigste moment waarop men oproep volumes beschouwt en waarop men voorspellingen maakt. Zoals alle planning van activiteiten eist het forecasting proces continue opvolging en updating om te kunnen reageren op mogelijke fluctuaties in de belasting. Des te vroeger men de updates uitvoert, des te beter goedkope oplossingen kunnen gevonden worden, bijvoorbeeld het aanpassen van de operator schema s. Dit proces van regelmatige updating heeft plaats tot op de dag zelf. Een recente studie heeft aangetoond wat de meeste 2 Wrap-up tijd: De tijd die nodig is om het vorige telefoongesprek af te ronden, ofwel alle activiteiten die direct gerelateerd zijn aan het vorige gesprek maar waarvoor het niet nodig is de werkplek te verlaten. 7

21 Hoofdstuk 1: Inleiding call centra al reeds wisten: gedurende de dag is de belasting van het ene interval positief gecorreleerd met de belasting van het volgende interval. Dit betekent dat wanneer de belasting hoger dan verwacht is in het begin van de dag, het waarschijnlijk is dat dit zo zal blijven gedurende de rest van de dag. Dit heeft belangrijke gevolgen op de manier waarop men call centra managet Staffing & Scheduling Operator scheduling of staffing koppelt het volume oproepen met operatoren Staffing De meest gehanteerde methode om het aantal benodigde operatoren te berekenen is de Erlang C formule, genoemd naar een Deense ingenieur van het begin van de vorige eeuw. Het Erlang vertragingsmodel houdt rekening met de onvoorspelbaarheid van het aanbod: gesprekken komen op willekeurige tijdstippen binnen, en hebben niet allemaal dezelfde gespreksduur. Als invoer in de formule zijn vier parameters noodzakelijk: Het verwachte aantal aankomsten per uur ( λ ); De verwachte gespreksduur plus het after call work uitgedrukt in seconden ( β ); Service level tijd; Het percentage van de oproepen dat binnen de service level tijd moet beantwoord worden (SLA). Erlang C heeft z n populariteit voornamelijk te danken aan z n eenvoud. Die eenvoud vormt ter gelijkertijd ook het grootste gebrek van deze formule. De formule maakt immers een aantal veronderstellingen die tot een al te sterke vereenvoudiging van de realiteit leiden. Men veronderstelt dat de klant oneindig lang zal wachten totdat hij/zij een operator aan de lijn krijgt. Ook neemt men aan dat de fictieve rij waarin klanten wachten op een antwoord een onbeperkte capaciteit heeft. Er wordt op die manier geen rekening gehouden met abandoning en rejecting wanneer men Erlang C hanteert. Verder veronderstelt men dat er zich geen pieksituaties voordoen in het aankomstpatroon van de oproepen. Het gevolg van dit alles is dat de Erlang C formule meestal tot een overstaffing van het call center zal leiden. 8

22 Hoofdstuk 1: Inleiding Eigenschappen van de Erlang formule: Eén operator meer of minder kan een groot verschil uitmaken in het service level. De Erlang formule is zeer gevoelig voor kleine veranderingen in de input parameters. Deze gevoeligheid kan het de taak van de manager zeer moeilijk maken: kleine onvoorspelbare veranderingen in de hoeveelheid oproepen per tijdseenheid of onverwachte afwezigheid van enkele operatoren kunnen het service level ruïneren. Economies of scale: grote call centra werken efficiënter dan kleine. Dit komt omdat de onvoorspelbare variaties meer uitgesmeerd worden bij een groot call center. Als het aantal operatoren verdubbelt, dan kan λ meer dan verdubbeld worden terwijl hetzelfde service level behouden blijft. Hierbij veronderstellend dat β en de service level tijd constant blijven. Gemiddelde wachttijd ifv. het aantal operatoren. 200 gemiddelde wachttijd (sec) aantal operatoren 2 afzonderlijke call centers pooling van de 2 call centers Figuur 1: Economies of scale. λ = 1, β = 5 voor een afzonderlijk call center. In realiteit wordt een call center geconfronteerd met abandoning en rejecting. Ook dient er rekening gehouden te worden met pieksituaties. In plaats van de Erlang formule gebruikt men dan best simulatie. Een simulatiemodel bootst een call center na en je kan a.d.h.v. verschillende simulatieruns de optimale hoeveelheid operatoren bepalen. In zo n simulatiemodel houdt men rekening met abandoning en rejecting. Men veronderstelt ook dat pieksituaties kunnen voorkomen. 9

23 Hoofdstuk 1: Inleiding Alle kenmerken van een contact center kunnen in een simulatiemodel worden opgenomen. (waaronder bijvoorbeeld IVR, skill based routing, call blending,..) Er is wel een nadeel verbonden aan het bouwen van een simulatiemodel: het kostenplaatje. In tegenstelling tot de eenvoudige Erlang formule die men onmiddellijk kan gebruiken, vergt het ontwikkelen van een model veel tijd Shrinkage Eenmaal het aantal benodigde agenten bepaald, ben je er nog niet: je hebt immers geen zekerheid dat iedere agent die is ingeroosterd ook daadwerkelijk (op tijd) op komt dagen. Hij/zij kan namelijk ziek zijn, in de file staan enz. Ook als de agenten eenmaal aanwezig zijn, zijn ze niet iedere minuut van de dag in staat om klanten te helpen. Zo kan een agent bijvoorbeeld naar het toilet zijn, met collega s overleggen enz. Dit soort verloren tijd wordt ook wel shrinkage genoemd. Andere vormen van shrinkage zijn bijvoorbeeld: (lunch)pauzes vergaderingen afwezigheid (o.a. ziekte) onderzoek Er wordt geen rekening gehouden met het optreden van shrinkage bij het bepalen van het aantal agenten dat nodig is om het gewenste servicelevel te bereiken (de basis staf). Om er toch voor te zorgen dat het servicelevel niet te laag wordt, wordt deze basis staf over het algemeen verhoogd met een vooraf bepaald percentage. Meestal wordt hiervoor een percentage gebruikt van rond de 30 maar uitschieters naar 15% of 50% zijn geen uitzondering Scheduling Het doel is het vinden van het beste schema dat moet voldoen aan bepaalde beperkingen. Onder beste wordt meestal het goedkoopste verstaan, d.w.z. zo weinig mogelijk operatoren gebruiken. Maar je kan het ook formuleren op een andere manier: Hoe bekom je het hoogste service level met een bepaald aantal operatoren? Typische beperkingen zijn bijvoorbeeld: Aantal operatoren dat nodig is om inbound oproepen te behandelen voor een bepaald interval. 10

24 Hoofdstuk 1: Inleiding Welke schema s zijn mogelijk? Men tracht het schema te vinden dat de dagelijkse kosten minimaliseert terwijl aan alle beperkingen voldaan wordt. Dit noemt men een integer programming problem. Het optimalisatie model ziet er als volgt uit: Min T S t= 1 s= 1 c x t st n s S. t. : x S s=1 n st s x st binair n s m integer t s S, t T t T s S met: n s : integer die aangeeft hoeveel operatoren er in shifts s werken. c t : de kost van een operator in het interval t x st = 1 als shift s werkt in het interval t = 0 in andere gevallen m t : het benodigd aantal operatoren in interval t T : verzameling van alle tijdsintervallen S : verzameling van alle shifts Dit model moet toegepast worden per groep operatoren. 1.7 Ondersteunende technologie Veel contact centra beschikken over telecommunicatie technologie die gericht is op grootschalige verwerking van inkomende (inbound) telefoongesprekken. Daardoor ontstaat een belangrijk voordeel: veel klanten kunnen worden geholpen tegen relatief lage kosten. De PABX (Private automate branch exchange = het bedrijfstelecommunicatiesysteem) en de ACD (Automatic Call Distribution) vormen de basis van grootschalige verwerking en worden dan ook in vrijwel alle contact centra toegepast. Gezamenlijk maken deze technologieën het mogelijk om queue s in te richten. Elk binnenkomend gesprek wordt gerouteerd naar een 11

25 Hoofdstuk 1: Inleiding toestel in de kring dat vrij is om het telefoongesprek aan te nemen. Wanneer alle telefoontoestellen bezet zijn, wordt het gesprek in de wachtrij gezet totdat een toestel vrij komt. Dan wordt het wachtende gesprek automatisch doorverbonden naar het vrijgekomen toestel. Op die manier is het mogelijk zeer efficiënt binnenkomende telefoongesprekken af te handelen. Enkele ondersteunende technieken zijn: ANI: Automatic Number Identification CTI: Computer Telephony Integration. De integratie tussen pc en telefoon opent verrassende perspectieven voor een onderneming. Bij een binnenkomende oproep krijgt men bijvoorbeeld meteen de desbetreffende klantenfiche op het scherm. Voordelen: o Klantvriendelijk imago: bij een oproep verschijnt meteen de desbetreffende klantenfiche op het scherm; men kan de klanten steeds op een gepersonaliseerde manier te woord staan; bovendien beschikt men over alle gegevens om kort op de bal te spelen. o Tijdwinst: bij een binnenkomende oproep verschijnt de klantenfiche op het scherm zonder dat men daarvoor een programma of een bestand hoeft te openen. Een andere al langer bestaande telecommunicatie technologie die voor inkomend verkeer wordt toegepast is Interactive Voice Respons (IVR). De term Voice Response betekent dat men kan reageren op een gesproken boodschap. Afhankelijk van het antwoord (interactie met de computer, door bepaalde toetsen in te drukken) wordt men verder geleid naar de service die men wenst. Analoog aan de IVR bestaat er ook al VRU ( Voice Response Unit). Hier heb je het voordeel dat je niet langer toetsen moet indrukken. Je kan gewoon praten en de computer zal daarna de klant verder helpen. Terwijl de ACD het inbound verkeer managet, wordt met de Predictive Dialler de outboundtrafiek geregeld. Het systeem belt meer nummers op dan er operatoren zijn. Op basis van een aantal variabelen ( gemiddelde gespreksduur, aantal operatoren, procent beantwoorde telefoontjes, enz.) berekent de Dialler hoeveel opbelpogingen hij mag ondernemen. De belangrijkste bijdrage van deze technologie is natuurlijk dat de operator niet zelf de nummers moet samenstellen en dat de operator alleen met beantwoorde oproepen 12

26 Hoofdstuk 1: Inleiding geconnecteerd wordt. De operatoren worden dus niet gefrustreerd door bijvoorbeeld bezettonen en antwoordapparaten. Dit betekent een enorme tijdwinst omdat de operatoren alleen geconfronteerd worden met reële contacten. Een nadeel is echter dat het wel eens kan voorkomen dat voor een beantwoorde oproep geen operator vrij is. Want een gesprek tussen een operator en een consument kan bijvoorbeeld onverwacht iets langer duren dan de computer heeft berekend. 13

27 Hoofdstuk 1: Inleiding Indien de klant niet voldoende heeft aan de informatie die de IVR/VRU verschaft, wordt de oproep doorgeschakeld naar een operator. klanten trunk lines PABX IVR/VRU PSTN netwerk Via ANI weet het contact center welke klant er belt. Deze informatie gebruikt de ACD voor de routering van de oproep naar de gepaste operator. ACD Via CTI verschijnen er popups op de schermen van de operators zodat ze direct de basisgegevens van de klant zien. Operators Figuur 2: Overzicht van ondersteunende technologie. 14

28 Hoofdstuk 1: Inleiding 1.8 Vaak toegepaste technieken Call blending De meeste contact centra beschikken over getrainde agenten, gespecialiseerd in ofwel inbound oproepen, outbound oproepen of taken (bv. s). Kleine call centra kunnen het zich niet permitteren om verschillende groepen gespecialiseerde agenten aan te werven. Hier moeten de operatoren zowel inbound - en outbound oproepen als taken,... kunnen afhandelen. Een belangrijke taak voor het management bestaat erin een balans te vinden, zodanig dat er op de piekmomenten genoeg operatoren beschikbaar zijn om binnenkomende gesprekken te beantwoorden en op de rustige momenten de productiviteit hoog genoeg blijft. Hierin speelt call blending een belangrijke rol. Call blending wordt gedefinieerd als outbound agenten die inbound oproepen ontvangen of inbound agenten die outbound oproepen plegen. Dus door het combineren van skills (hier inbound en outbound, maar dit kan ook en dergelijke zijn) wordt de bezettingsgraad (utilization) van de operatoren verhoogd. Call blending kan ook een negatief effect hebben als het blindelings wordt toegepast! Om dit te vermijden moet de manager de juiste manier van blending toepassen, zodat de fluctuaties in de call volumes afvlakken, de productiviteit van de agent maximaliseert en het staffinglevel gedurende de dag stabiliseert Multiskilled operatoren Er komen in een contact center typisch verschillende soorten oproepen (= call types) binnen. Wanneer iedere operator in het contact center opgeleid is om maar 1 type oproep te behandelen, spreekt men van single skilled operatoren. Een klein contact center maakt best geen gebruik van zo n soort operatoren. Voor ieder call type zou er dan tenminste 1 operator moeten voorzien worden. Het kan dan voorkomen dat de operatoren niets te doen hebben omdat er gewoonweg niet voldoende oproepen binnenkomen. In dit geval gebruikt men best multi skilled operatoren Dit zijn operatoren die in staat worden geacht verschillende call types te kunnen behandelen. Men zal in totaal minder operatoren nodig hebben om alle klanten te kunnen helpen dan in het geval van single skilled operatoren. 15

29 Hoofdstuk 1: Inleiding In grotere contact centra deelt men de operatoren in groepen in. Iedere groep bevat mensen die dezelfde skills hebben voor de verschillende call types. Indien de operatoren alle oproepen zouden kunnen beantwoorden (totale flexibiliteit), dan zou de productiviteit het hoogst zijn. Opmerkelijk is het feit dat men hetzelfde resultaat ongeveer bereikt als de operatoren slechts enkele call types kunnen verwerken i.p.v. alle types (dit zullen we later aantonen in hoofdstuk 5). Met andere woorden, gegeven het feit dat totale flexibiliteit veel geld kost, lijkt het onwaarschijnlijk dat totale flexibiliteit de beste oplossing is vanuit economisch perspectief. 16

30 Hoofdstuk 2: Doel van de thesis Hoofdstuk 2: Doel van de thesis Het hoofddoel van deze thesis is het ontwikkelen van een tool die contact centra toelaat verschillende scenario s, op een snelle en eenvoudige manier, met elkaar te vergelijken. Aan de hand van enkele belangrijke contact center karakteristieken ( service level, gemiddelde wachttijd, aantal abandonments, ) kan men dan bepalen welk scenario het beste is voor het contact center. Onder een scenario verstaan we bijvoorbeeld call blending toepassen of niet; multiskilled operatoren inzetten of niet, De tool moet ook gebruiksvriendelijk zijn. Het heeft geen nut om een ingewikkelde tool te creëren waar geen zinnig mens kan mee werken. Het is de bedoeling dat de gebruiker een scenario kiest, de vereiste data ingeeft en dat daarna de verschillende karakteristieken automatisch weergegeven worden; dit alles op een eenvoudige manier. Om deze tool te kunnen ontwikkelen moest er eerst en vooral een grondige studie gemaakt worden van de contact center wereld: Op welke manier organiseert een contact center zich? Hoe bepaalt men het aantal benodigde operatoren? Hoe maakt men een planning en scheduling? Veel informatie betreffende deze vragen kan men op het internet vinden. Maar om een nog beter idee te krijgen van de werking van een contact center stelden we een soort audit op met een aantal vragen. Deze audit moest dan ingevuld worden door enkele contact centra. 17

31 Hoofdstuk 3: Audit Hoofdstuk 3: Audit 3.1 Inleiding Na het bestuderen van vele artikels, gevonden op het internet, hadden we een summier idee hoe een contact center zichzelf organiseert om de klant zo goed en zo efficiënt mogelijk te bedienen, welke technieken er op de markt voorhanden zijn, Maar we hadden nog geen duidelijk inzicht in de manier waarop een contact center bijvoorbeeld zijn personeelsbeleid voert, welke technieken er wel of niet toegepast worden. Om deze reden stelden we een audit 3 op. Aan de hand van een reeks vragen is het de bedoeling om een beter inzicht te krijgen in: de organisatie, de werking van een contact center. de verschillende technieken die men toepast. het personeelsbeleid van een contact center. eventuele gebieden die geoptimaliseerd kunnen worden. De vragen in de audit zijn onderverdeeld in verschillende categorieën: Categorie Bedrijfsprofiel Klantenprofiel Contactprofiel Processen Organisatie People (personeel) ICT Kosten Kengetallen Kenmerk Algemeen profiel van het contact center Wie is de klant? Op welke manieren neemt de klant contact op? Hoe organiseert het contact center zich om de klant zo goed mogelijk te helpen? Hoe zet het contact center zijn personeel in? Personeelsgegevens Welke technieken hanteert men? Wat is het kostenplaatje? Bereikt het contact center de beoogde resultaten? 3 De vragenlijst kan u terugvinden in bijlage2. De elektronische versie bevindt zich in de bijgevoegde CD. 18

32 Hoofdstuk 3: Audit De vragen hebben we zelf opgesteld, met in het achterhoofd de kennis die we dankzij het vele opzoekwerk hadden opgedaan. Ze zijn zodanig opgesteld dat, wanneer je de ingevulde vragenlijst bestudeert, je een goed idee hebt van de globale werking van het contact center. De audit is opgesteld in Excel. Om toe te laten dat de contact centra snel en eenvoudig de vragen kunnen beantwoorden, maken we zoveel mogelijk gebruik van een zogenaamde drop down list waarbij je het juiste antwoord gewoon kan aanklikken. We stuurden de audit op naar verschillende contact centra met de vraag deze in te vullen. 3.2 Verwerking Het is niet eenvoudig om een statistische analyse uit te voeren gezien het feit dat: de contact centra wereld zo uitgebreid en veelzijdig is: o Men vindt contact centra in alle sectoren van de industrie; o Sommige zijn al groter dan de andere; o Sommige hebben andere streefdoelen (profit versus cost center) o we geen 10- tal ingevulde audits hebben. Omdat we moeilijk de data op een statistische wijze kunnen onderzoeken, hebben we het over een andere boeg gegooid. Naast het hoofddoel van de audit nl. inzicht krijgen in de contact centra wereld, gebruiken we de audit om een aantal zaken na te gaan zoals bijvoorbeeld: Wordt call blending toegepast? Om de hoeveel tijd maakt men gemiddeld gezien een nieuwe forecast? Kunnen de contact centra hun vooropgestelde streefdoelen qua service level en abandonment rate behalen? Gebruikt men een shrinkage factor? 19

33 Hoofdstuk 3: Audit De belangrijkste vragen uit de audit hebben we in een tabel gegroepeerd. In die tabel ziet u ook de antwoorden van de contact centra die hun medewerking hebben verleend aan de audit. Wanneer er / staat, betekent dit dat we er geen informatie over gekregen hebben. Uit deze antwoorden kunnen we min of meer enkele algemeenheden halen: De forecast frequentie is meestal maandelijks. Men maakt een forecast van zowel s als telefoonoproepen. De operatoren zijn meestal multiskilled. Men past bij het staffing proces een shrinkage factor toe. Men rapporteert dagelijks de prestatiekarakteristieken. Call blending wordt niet overal toegepast. Men beschikt niet overal over flexibele operatoren. ACD, IVR en CTI worden heel vaak gebruikt. 20

34 Hoofdstuk 3: Audit Bedrijfsprofiel Bedrijf1 Bedrijf2 Bedrijf3 Bedrijf4 Bedrijf5 aantal vaste FTE aantal free operatoren totaal aantal werknemers Klantenprofiel Wordt customersegmentatie toegepast? ja ja neen / neen Contactprofiel totaal aantal afgehandelde inbound gesprekken per FTE per jaar? / (full time equivalent)? totaal aantal afgehandelde inbound s per FTE? > / Processen Forecasting Om de hoeveel tijd maakt men een nieuwe forecast? maandelijks maandelijks maandelijks maandelijks / Is er een forecasting proces aanwezig voor: telefoon ja ja neen, in opbouw ja neen ja ja neen, in opbouw ja neen Staffing Gebruikt men een shrink factor? ja ja ja / / Hoeveel procent van de operatoren zijn multiskilled? 50--> / / Scheduling steeds zelfde aantal trimestrieel wekelijks wekelijks / Voor welke tijdspanne maakt u een planning op? operatoren Opvolging Kan men indien nodig snel ingrijpen door extra agenten in te zetten? neen ja ja / neen Rapportering Wat is de frequentie van rapportering? dagelijks dagelijks dagelijks dagelijks / 21

35 Hoofdstuk 3: Audit Quality Monitoring Wordt de kwaliteit ivm oproepbehandeling gecontroleerd? ja ja ja ja / WFM Is er een ondersteuning door WFM voorzien? ja ja ja / neen Organisatie Hoeveel operatoren zijn er voorzien per toezichter? / / Wordt call blending toegepast? neen ja neen neen ja ICT Zijn de volgende technieken,systemen aanwezig in het call center? PABX (private automated branch exchange) neen ja ja ja neen ACD (automatic call distributor) ja ja ja ja neen IVR/VRU ja ja ja ja neen Voice over IP (VOIP) neen ja ja ja neen CTI (Computer Telephony Integration) ja ja ja ja neen Welke methode hanteert men om de routing in het call center te doen? Routing gebaseerd op de huidige condities in het call center? (bijv aantal beschikbare operatoren) ja ja ja ja neen Routing gebaseerd op geschatte wachttijd? ja ja ja ja neen Routing gebaseerd op IVR informatie? ja ja ja ja neen Routing gebaseerd op operator informatie? (bijv minst bezette agent,skill based routing) ja ja ja ja neen Tabel 1: Analyse van de audit. 22

36 Hoofdstuk 4: Model Hoofdstuk 4: Model 4.1 Werkwijze We gebruiken 2 programma s om de simulatietool te ontwikkelen: Excel en Enterprise Dynamics (ED) 4. Enterprise dynamics is een programma dat men gebruikt om simulaties uit te voeren. Je kan a.d.h.v. standaard bouwblokken een simulatiemodel opbouwen. In die blokken moet je dan telkens de gepaste data intikken om een correcte werking te verkrijgen. Om de tool gebruiksvriendelijk te houden, maakten we het mogelijk dat de gebruiker de noodzakelijke data (aantal teams, aantal call types, forecasts, ) in Excel ( Input ) kan ingeven. Met één druk op een knop wordt het simulatiemodel automatisch gecreëerd. Je moet op deze manier in ED niets meer instellen. Je kan onmiddellijk beginnen met het model te laten lopen. Beide programma s zijn met elkaar gelinkt zodat ze met elkaar gegevens kunnen uitwisselen. Je kan de simulatieresultaten zowel in ED als in Excel bekijken. In Excel hebben we een aparte file ( Output ) voorzien waar de gebruiker de resultaten van verschillende simulaties met elkaar kan vergelijken. Daarnaast hebben we ook een optionele Excel file ( Optimalisatie ) ontworpen die men kan gebruiken om alle mogelijke shifts te creëren, die binnen de vereisten van het call center vallen. Zo kan a.d.h.v. de oplosser in Excel de best passende shifts gekozen worden door minimalisatie van de personeelskosten. De gebruiker kan kiezen of hij/zij deze optimalisatie wil toepassen. In de volgende figuur kan u de structuur van het model zien. 4 Zie bijlage 1 om de simulatietool op een correcte manier te installeren. 23

37 Hoofdstuk 4: Model. 1: Aantal agenten berekend via Erlang 2: Aantal agenten na optimalisatie 3: Starten van simulatie 4: Analyseren van de resultaten. Figuur 3: Structuur van het model. 24

38 4.2 Het Excel bestand Input Doel Hoofdstuk 4: Model Het is de bedoeling dat de gebruiker alle noodzakelijke data in Excel ingeeft vooraleer de simulatie van start kan gaan. Onder data verstaan we o.a. de bedieningstijden, het aantal groepen, het vooropgestelde service level, de forecasts, Pas nadat dit cijfermateriaal ingegeven is, kan je starten met simuleren. Het simulatieprogramma wordt namelijk op basis van deze gegevens opgebouwd Structuur De Excel file bestaat uit verschillende tabbladen: 1. timing 2. skill-level 3. naamgeving 4. bedieningstijd 5. servicelevel+abandonment 6. forecast per call type 7. source 8. # operatoren 9. # operatoren na optimalisatie Enkel in de laatste 3 tabbladen hoeft de gebruiker niets manueel in te voeren. In de overige bladen dient de gebruiker op de voorziene plaatsen de vereiste data te typen. De plaats waar hij/zij iets moet invullen, hebben we steeds aangeduid met een kleur. De kleurcode werkt als volgt: : Deze kleur duidt aan dat de gebruiker hier iets dient in te vullen. : Deze kleur duidt ook aan dat de gebruiken hier iets moet typen. Het enige verschil is het feit dat het hier specifiek over taken handelt. Enkel in de cellen met een paarse of lichtblauwe kleur moet de gebruiker dus iets typen. 25

39 Hoofdstuk 4: Model De waarden in de overige cellen worden automatisch berekend op basis van de data dat de gebruiker ingegeven heeft. Het is uitermate belangrijk dat men de kleurencode respecteert. De data van de taken MOET in de lichtblauwe cellen geschreven worden. Dit omwille van het feit dat de code in Enterprise Dynamics hierop gebaseerd is. In hetgeen nu volgt, leggen we uit waarvoor we ieder tabblad gebruiken en wat de gebruiker dient in te vullen in het betreffende blad Timing In dit blad kan de gebruiker bepalen over welke periode hij/zij wenst te simuleren. We hebben de mogelijkheid voorzien dat er over enkele weken kan gesimuleerd worden. Ook houden we rekening met het feit dat de uurroosters van de weekdagen kunnen verschillen met diegene van de zaterdagen en eventueel ook de zondagen. We voorzien de mogelijkheid om 3 verschillende uurroosters in te geven ( Uurschema 1, Uurschema 2, Uurschema 3 ). Als een contact center maar 1 uurrooster hanteert, moet men enkel Uurschema 1 invullen. De structuur van de drie tabellen is dezelfde. Je vult het start - en eindpunt in van de werkdag (in uren en minuten). Verder moet je de intervalduur ingeven in uren. Als je bijvoorbeeld met een interval van 30 minuten wil werken, dien je 0,5 te typen. Daarna moet je aangeven hoeveel dagen je dit uurrooster wil simuleren. Uurschema 1 Uur startpunt Minuten Uur eindpunt Minuten interval (in uren) aantal dagen Figuur 4: Uurschema 1. 26

40 Hoofdstuk 4: Model Verder voorzien we de mogelijkheid om een aantal weken na elkaar te simuleren. Het aantal weken dient men in te vullen in de cel P9. Indien men 2 verschillende uurroosters wenst te gebruiken, moet men 2 tabellen invullen. (bv 1 voor de weekdagen en 1 voor de zaterdag en de zondag). Voorbeeld: Men wil een simulatie uitvoeren over een periode van 1 week. Tijdens de weekdagen werkt men van 8:00 tot 15:00 uur. In het weekend werkt men van 8:00 tot 12:00 uur. De intervalperiode bedraagt 1 uur. Men dient hier dus 2 Uurschema s in te vullen: Uurschema 1 Startpunt Eindpunt uur 8 minuten 0 uur 15 minuten 0 Interval (in uren) 1 aantal dagen 5 Figuur 5: Voorbeeld Uurschema 1. Uurschema 2 Startpunt Eindpunt uur 8 minuten 0 uur 12 minuten 0 Interval (in uren) 1 aantal dagen 2 Figuur 6: Voorbeeld Uurschema 2. In cel P9 schrijven we 1. 27

41 Hoofdstuk 4: Model Uiteindelijk krijg je dan automatisch de volgende tijdsindeling die zowel in Excel als in ED zal gebruikt worden. week dag 1 1 8:00 9: :00 9: :00 10: :00 10: :00 11: :00 11: :00 12: :00 12: :00 13: :00 13: :00 14: :00 14: :00 15: :00 15: :00 9: :00 9: :00 10: :00 10: :00 11: :00 11: :00 12: :00 12: :00 13: :00 13: :00 14: :00 14: :00 15: :00 15: :00 9: :00 9: :00 10: :00 10: :00 11: :00 11: :00 12: :00 12: :00 13: :00 9: :00 14: :00 10: :00 15: :00 11: :00 12:00 Figuur 7: Voorbeeld: Tijdsindeling Skill level In de eerste rijen moet de gebruiker verschillende zaken aangeven: Hoeveel verschillende call types het contact center behandelt (zowel telefoonoproepen als taken(bv. )). Heb je bijvoorbeeld 3 soorten telefoonoproepen en 2 soorten taken, dan typt je 5 in cel D2. Het aantal verschillende groepen waarover het contact center beschikt (cel D3). Onder een groep verstaan we een verzameling operatoren die dezelfde skill levels hebben voor de call types. Hoeveel verschillende skill levels er zijn. Dit schrijft men in cel D4. In cel D5, moet de gebruiker aangeven over hoeveel telefoonlijnen het contact center beschikt. Tenslotte geeft de gebruiker in cel D6 aan hoeveel van de call types, taken zijn en geen telefonische oproepen. 28

42 Hoofdstuk 4: Model In de tabel beginnende van cel C9, vult men voor elke groep en voor elk call type het skill level in. Alle andere zaken die op dit werkblad staan zijn voor de gebruiker niet van belang Naamgeving Hier kan de gebruiker aan de verschillende call types een naam geven evenals aan de teams Bedieningstijd Hier moet de gebruiker de verschillende bedieningstijden per call type ingeven. Voor ieder skill level (het aantal skill levels werd al eerder ingevuld in het blad skill level ) typt de gebruiker een bepaalde tijd in. De grootste tijd zal logischerwijze bij het kleinste skill level dienen te staan. Bij skill level 0 hebben we op voorhand overal 0 ingevuld Servicelevel+abandonment Op dit blad dient de data voor de verschillende prestatiekarakteristieken te komen: service level: o In rij 10 schrijft men het percentage van de oproepen of de taken die binnen een bepaalde tijd moeten behandeld worden. o De service level tijd komt in rij 11. Abandonment: o In rij 14 komt de tijd die de klant bereid is te wachten vooraleer hij/zij inhaakt; per telefonische oproep wel te verstaan. Verder moet men op dit blad ook de prioriteit van de verschillende oproepen en taken aangeven. De gebruiker kan aan ieder call type een prioriteit schenken gaande van 1 tot en met 50. Hierbij stelt 50 de hoogste prioriteit voor. De prioriteiten dienen in rij 17 ingevuld te worden. In rij 24 tenslotte kan men bepalen hoeveel % van het berekend aantal operatoren via Erlang, men wil toepassen tijdens de simulatie. 29

43 Hoofdstuk 4: Model Forecast per call type Zoals u uit de titel kan afleiden, komt hier de forecast per call type. Voor ieder tijdsinterval dient men in te vullen hoeveel oproepen of taken men verwacht van een bepaald type (vergeet de kleurcode niet te respecteren!) Source Op dit blad hoeft men niets in te vullen. We gebruiken dit blad om data te verzamelen i.v.m. de verschillende call types #operatoren Vooraleer de simulatie in ED van start kan gaan, moet er eerst op de knop simulatie zonder optimalisatie gedrukt worden als de gebruiker geen optimalisatie wil toepassen. Daarna kan de simulatie starten in ED. Indien de gebruiker toch een optimalisatie wil uitvoeren, dient hij op de knop Eerst optimalisatie uitvoeren te drukken. De Excel file Optimalisatie opent dan automatisch. De gebruiker moet dan eerst de optimalisatie verrichten (zie 4.3). Eens dit achter de rug, komt het benodigd aantal operatoren automatisch in het volgende tabblad terecht. Daar moet men eerst op de knop simulatie met optimalisatie klikken voordat men kan beginnen met de simulatie in ED. Verder moet men in het blad #operatoren niets meer doen. Hier berekenen we het aantal benodigde operatoren voor het beantwoorden van de calls per groep via de Erlang formule. Voor de taken gebruiken we de Erlang formule niet (daar de service level tijd van taken te groot is). Het Erlang model gaat ervan uit dat oproepen in één enkele queue toekomen en bediend worden door één groep van operatoren (met identieke skills). In realiteit zijn er meerdere queue s (in ons model voor elk type oproep of taak), elk met hun eigen karakteristieken (service level, abandonment,...), call loads en prioriteiten. Er zijn ook meerdere groepen, met voor elk call type een bepaald skill level. Om het aantal benodigde agenten te berekenen moet daarmee rekening gehouden worden. 30

44 Hoofdstuk 4: Model Call loads Eerst verdelen we de call loads over de groepen die ze behandelen. Voor de verdeling maken we gebruik van het gewogen gemiddelde. Om dit te verwezenlijken houden we rekening met twee factoren: het skill level van de groepen de grootte van de groepen Hieronder ziet u een voorbeeld: Stel dat men 2 call types behandelt en over 3 groepen operatoren beschikt. Eerst berekenen we de call load per groep in plaats van de call load per type oproep. We passen onderstaande formule toe: call load ai i call load groep a = aantal operatoren i skill level x aantal operatoren x skill level xi a Met: skill level ai call load i aantal operatoren a x i = skill level van groep a voor call type i = aantal calls van type i per uur = aantal operatoren in groep a = 1 aantal groepen = 1 aantal call types Stel dat het volgende gegeven is: Skill level call type 1 call type 2 groep groep groep

45 Hoofdstuk 4: Model Aantal operatoren groep 1 50 groep 2 80 groep 3 30 Call load Call type Call type Men krijgt: ( ) call load groep 1: + 0 = 76, (dus 76,9 oproepen van type 1 en 0 van type 2) call load groep 2: 0 + = 210, (dus 210,52 van type 2 en 0 van type 1) call load groep 3: + = 23, ,5 = 62, (dus 23 oproepen van type 1 en 39,5 oproepen van type 2) Bovenstaande berekening voeren we uit voor alle telefonische oproepen en voor alle taken. Op die manier ontstaat er per groep en per tijdsinterval zowel een call load voor oproepen als voor taken Service level Om het gecombineerde service level te bepalen van de groepen mag men niet zomaar het gemiddelde nemen van de individuele service levels (van de oproepen die de groep behandelt). We passen volgende formule toe: service level groep a = service level i call load i i call load met i = 1 aantal telefonische oproepen ai ai, 32

46 Hoofdstuk 4: Model Neem het voorbeeld van hierboven en stel dat de call types volgende service levels hebben: SLA service level time call type 1 80 % 20 s call type 2 70 % 30 s 0,8 76,9 + 0,7 0 service level groep 1 : = 0, 8 76, , = 20 76,9 0, ,7 210,52 service level groep 2 : = 0, 7 210,52 80 % 20 s 70 % ,52 210,52 = s 0,8 23,05 + 0,7 39,5 service level groep 3 : = 0, 74 62,55 74 % 20 23, ,5 = 26,3 26,3 s 62,55 Bovenstaande berekening wordt enkel voor telefonische oproepen toegepast, voor taken is dit niet van toepassing. In dit voorbeeld zijn er geen taken Bedieningstijd De bedieningstijden worden op dezelfde manier als de service levels berekend. Per groep is het skill level per call type gekend en per call type kent men de bedieningstijd per skill level. Daaruit halen we eerst de bedieningstijd per call type en per groep. Het skill level per call type en per groep is reeds gekend (zie tabel hierboven). Stel dat de bedieningstijd per skill level en per call type de volgende is: Bedieningstijd call type 1 (s) call type 2 (s) skill level skill level

47 Hoofdstuk 4: Model We stellen eerst een tabel op met daarin de bedieningstijd per call type en per groep: Bedieningstijd call type 1 (s) call type 2 (s) groep / groep 2 / 400 groep We passen onderstaande formule toe: bedieningstijd groep a = bedieningstijd i call i met i = 1 call types i call load ai load ai Men krijgt: ,9 bedieningstijd groep 1 : = , ,52 bedieningstijd groep 2 : = , s 400 s , ,5 bedieningstijd groep 3 : = 444, ,72 s 62,55 Dit wordt net zoals bij call load zowel voor de taken als voor de telefonische oproepen uitgevoerd Het aantal benodigde agenten Bij de verdeling van de verschillende parameters maken we een onderscheid tussen telefonische oproepen en taken. De service level tijd bij taken bijvoorbeeld is veel groter dan bij telefonische oproepen. Als we dit onderscheid niet zouden maken, zou bij gebruik van het gewogen gemiddelde de bekomen service level tijd veel te groot zijn. Men zou op die manier te weinig operatoren inschakelen. Via een Add-in zijn we in staat om standaard Erlang C berekeningen uit te voeren in Excel. Met behulp van bovenstaande berekeningen wordt via de functie FractionalAgents (van de 34

48 Hoofdstuk 4: Model Add-in) per tijdsinterval en per groep het aantal benodigde agenten bepaald om de telefonische oproepen te behandelen. De input voor deze functie is: SLA: het percentage oproepen die binnen de service level tijd moet beantwoord worden (vb 0,85 ). Service level tijd : de tijd in seconden waarin men wil dat een call beantwoord wordt (vb 30 s). CallsPerUur: het aantal telefoonoproepen die toekomen in 1 uur. AHT: bedieningstijd, inclusief het after call work in seconden. Als resultaat krijgen we het benodigd aantal agenten om de telefonische oproepen te verwerken (aantal operatoren call ). Voor taken gebruiken we de Erlang formule niet. We gaan na hoeveel taken een team moet beantwoorden per uur en wat de AHT is van de taak. Op basis van deze gegevens bepalen we, per groep, het benodigd aantal operatoren om de taken te beantwoorden. aantal operatoren = taak Call load * AHT 3600 Tenslotte maken we de som van het aantal operatoren call en het aantal operatoren taak en ronden deze som naar beneden af. Op die manier bekomen we het aantal benodigde operatoren per groep en per tijdsinterval # operatoren na optimalisatie Indien de gebruiker de optimalisatie hanteert, komt hier het optimaal aantal operatoren terecht. Vooraleer de simulatie van start kan gaan, moet men eerst op de knop simulatie met optimalisatie drukken. Op die manier zal er gesimuleerd worden met het optimaal aantal operatoren i.p.v. het aantal operatoren dat men bekomt via de Erlang formule. 35

49 Hoofdstuk 4: Model 4.3 Het Excel bestand Optimalisatie Doel Met dit Excel bestand wordt per uurschema, de best passende shifts gecreëerd, uitgaande van het benodigd aantal operatoren per interval en per groep, door minimalisatie van de personeelskosten. Het aantal operatoren, gevonden met deze optimalisatie, kan indien gewenst, gebruikt worden als input voor het simulatie model Structuur Opnieuw bestaat de Excel file uit verschillende tabbladen: 1. timing 2. schedules 3. schedules2 4. schedules3 5. optimalisatie 6. resultaat timing Dit is analoog aan het timing blad in de Excel file Input Schedules, schedules 2 en schedules 3 In deze werkbladen worden alle mogelijke shifts gemaakt en dit per uurschema. Uurschema 1 komt in het werkblad schedules, uurschema 2 in het blad schedules2 en uurschema 3 tenslotte in het werkblad schedules3. De openingsuren en intervaltijd worden automatisch ingevuld. We gaan van een verzameling uit waarin alle mogelijke shifts zitten, die voldoen aan de openingsuren en de intervaltijd. Door het opleggen van beperkingen (die de gebruiker bepaalt) wordt deze verzameling steeds kleiner en komen we zo tot alle shifts die voldoen aan de eisen van het call center. Deze beperkingen omvatten onder andere: Wat is het vroegste tijdstip waarop de middagpauze kan starten? Wat is het laatste tijdstip waarop de middagpauze kan starten? Hoelang duurt de middagpauze? Is er ook een kleine pauze rond 10u of rond 16u? o Zo ja, hoelang duurt deze pauze? 36

50 Hoofdstuk 4: Model Zijn er operatoren die later beginnen en bijgevolg geen pauze rond de middag hebben? o Zo ja, vanaf hoe laat kunnen deze operatoren beginnen? o Hoeveel pauzes hebben deze operatoren (max. 3)? o Hoelang duren deze pauzes? Wat is de maximale tijd, dat een operator aan één stuk mag werken? Wat is de minimale tijd, dat een operator aan één stuk moet werken? Hoeveel mogelijke werkuren per dag wil men voorzien (max. 10)? o Wat zijn deze werkuren? Wil men werken met flexibele operatoren? (hieronder verstaan we operatoren die enkele uurtjes komen werken, aan één stuk zonder pauze, bv 3 uur) o Hoeveel uren komen deze flexibele operatoren werken? Hoe groot neemt men de stappen waarop operatoren kunnen beginnen? (bv 1 uur, als men wenst dat de ene operator om 9u begint, de andere om 10u enz.) Hoe groot verkiest men de stappen waarop de middagpauzes kunnen beginnen? Hoe groot verkiest men de stappen waarop de andere pauzes kunnen beginnen? Eens alle beperkingen ingevuld zijn, drukt men op de generate knop en alle mogelijke shifts komen te voorschijn 5. Vervolgens moet de kost per interval voor een gewone operator en voor een flexibele operator ingevuld worden. Dit gebeurt per tijdsinterval, zodat een call center dat 24 op 24 uur bereikbaar is, een meerkost kan geven aan operatoren die s nachts werken. Men herhaalt dit voor alle uurschema s Optimalisatie Via een koppeling met het Excel bestand (Input) wordt het aantal benodigde operatoren per tijdsinterval en per groep ingelezen. Nu is het de bedoeling dat via optimalisatie, per dag en per groep het aantal operatoren bepaald wordt die een bepaalde shift hebben zodat er per groep en per tijdsinterval een juiste hoeveelheid mensen aanwezig is om de calls en/of de taken te behandelen. Het optimale geval doet zich voor indien het aantal gevonden operatoren met optimalisatie identiek gelijk is aan het aantal benodigde operatoren volgens de Erlang formule. Het gebruikte optimalisatie model ziet er als volgt uit: 5 De code van deze macro kan u terugvinden in de bijlage 3. 37

51 Hoofdstuk 4: Model 38 D d G g n x c Min d p d P d d Pd T t S s g p s t g p s S = =, 1 1,,,,, D d G g S s integer n D d G g T t m n x S t T t D d G g S s binair x d d d d d d d d d P g p s p S s g p t g p s t g p s p P t g p s =,,,,.:.,,,,, 1,,,,,,,,,, met: g p s d n,, : een integer, die aangeeft hoeveel operatoren shift s hebben van uurrooster p op werkdag d, in groep g S Pd c : de kost van een shift van uurrooster p, die geldt op dag d t g p s d x,,, = 1 als een operator met shift s van uurschema p op dag d van groep g in het interval t moet werken = 0 in het andere geval g p t d m,, : het benodigd aantal operatoren in interval t op werkdag d van groep g G : de verzameling van alle groepen operatoren D : de verzameling van alle werkdagen (indien er 5 dagen per week zijn en 2 weken is dit de verzameling {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}) P d S : de verzameling van alle shifts s voor werkdag d (die uurschema p d hebben) p d T : de verzameling van alle tijdsintervallen, op werkdag d, waarvoor uurschema p d geldt In bovenstaand model minimaliseren we de personeelskosten van het contact center. Per tijdsinterval moet de kost dus gekend zijn. Daar er per groep en per werkdag een optimalisatie moet worden uitgevoerd, hebben we dit opnieuw via een macro gedaan. Door op de knop Optimaliseer te drukken, start automatisch het optimalisatieproces.

52 Hoofdstuk 4: Model Resultaat Eens de optimalisatie uitgevoerd, kan men in het werkblad resultaat voor een bepaalde groep en voor een bepaalde dag, alle voorkomende shifts en het aantal operatoren die volgens deze shifts werken, bekijken Opbouw van de programmacode in Visual basic De ingegeven waarden, meestal tijdstippen, worden eerst omgezet in minuten en dan gedeclareerd in Visual Basics. Het tijdstip waarop de shift begint (starttime), het begin van de middagpauze (startpauze) en de totale arbeidsduur (totaal_werktijd) laten we variëren, met drie FOR-lussen. De gebruiker kan het aantal iteraties beïnvloeden, via de STEP parameters. Bv. starttime = openingstijd + st * stepbegin, waarbij st achtereenvolgens gelijk is aan 0, 1, 2,... Hoe groter STEPBEGIN, hoe minder verschillende begintijden er zijn en hoe minder shifts er bijgevolg zullen zijn. Ook kan de gebruiker tot tien uiteenlopende arbeidsduurtijden ingeven en het interval definiëren waarin de middagpauze moet starten. We onderscheiden in het programma enkele situaties: Situatie 1: Indien het een shift is met middagpauze en een kleine pauze voor of na de middag. Eerst wordt gekeken of de tijd voor de middagpauze groter of gelijk is aan de tijd na de middagpauze: tijd voor de middagpauze = startpauze starttime = tijd_1 tijd na de middagpauze = totaal_werktijd tijd_1 = tijd_2 Indien tijd_1 > = tijd_2, dan valt de kleine pauze voor de middag, anders na de middag. Hier heeft men dus drie werkperiodes: periode 1: van het begin van de shift tot aan de kleine pauze periode 2: van na de kleine pauze tot de middagpauze periode 3: van na de middagpauze tot het einde van de shift 39

53 Hoofdstuk 4: Model In het geval dat tijd_1 >= tijd_2 krijgt men: tijd_1 = tijd_1 - pauze tijd_2 = totaal_werktijd(tw) - tijd_1 periode_1 = werkblok_min + (a) * steppauze periode_2 = tijd_1 - periode_1 periode_3 = tijd_2 In het geval dat tijd_2 > tijd_1: tijd_2 = tijd_2 - pauze tijd_1 = totaal_werktijd(tw) - tijd_2 periode_1 = tijd_1 periode_2 = werkblok_min + a * steppauze periode_3 = tijd_2 - periode_2 Het maximaal en het minimaal aantal uren dat een operator na elkaar mag werken zonder pauze wordt ook via Excel ingelezen (werkblok_max en werkblok_min). Per starttime, startpauze en totaal_werktijd creëren we alle mogelijke combinaties. Dit gebeurt opnieuw door een FOR-lus. In het geval de kleine pauze voor de middag valt, kunnen er zich voor periode_1 en periode_2 opnieuw twee situaties voordoen: tijd_1 werkblok_min <= werkblok _max tijd_1 werkblok_min > werkblok_max In de situatie waar de kleine pauze na de middag valt, krijgt men identiek dezelfde gebeurtenissen Tijd_1 werkblok_min <= werkblok _max Om de situatie uit te leggen, gaan we uit van een voorbeeld. Gegeven: werkblok_min = 2u werkblok_max = 4u starttijd = 6u startmiddag = 12.15u pauze = 15min steppauze = 30min 40

54 Berekening tijd_1: Hoofdstuk 4: Model tijd_1 = startmiddag starttijd pauze = 12.15u 6u 15min = 6u. Controle voorwaarde (tijd_1 werkblok_min <= werkblok _max): 6u 2u = 4u <= 4u OK Om nu alle mogelijk shifts te creëren met bovenstaande gegevens, voeren we opnieuw een lus in met teller a. Deze teller loopt van nul tot amax. We zoeken alle mogelijke tijdstippen waarop de kleine pauze mag starten. Daar werkblok_min 2u is, kan de pauze ten vroegste om 8u starten en kan hij ten laatste om 10u starten. amax is gelijk aan: tijd _1 2 * werkblok _ min 6 * 60 2 * 2 * 60 ama x = = = 4 steppauze 30 De 5 verschillende starttijden van de pauze zijn: 8u, 8u30, 9u, 9u30 en 10u. Hieronder ziet u een figuur die de mogelijkheden weergeeft. lus 1 lus 2 lus 3 lus 4 lus 5 6:00 6:15 6:15 6:30 6:30 6:45 6:45 7:00 2u 7:00 7:15 2u30 7:15 7:30 3u 7:30 7:45 3u30 7:45 8:00 4u 8:00 8:15 pauze 8:15 8:30 8:30 8:45 pauze 8:45 9:00 9:00 9:15 pauze 9:15 9:30 9:30 9:45 pauze 9:45 10:00 10:00 10:15 4u pauze 10:15 10:30 3u30 10:30 10:45 3u 10:45 11:00 2u30 11:00 11:15 2u 11:15 11:30 11:30 11:45 11:45 12:00 12:00 12:15 Figuur 8: tijd_1 werkblok_min <= werkblok _max 41

55 Hoofdstuk 4: Model Tijd_1 werkblok_min > werkblok_max Om deze situatie uit te leggen gaan we uit van een ander voorbeeld. Gegeven: werkblok_min = 2u werkblok_max = 4u starttijd = 6u startmiddag = 13.15u pauze = 15min steppauze = 30min Berekening tijd_1: tijd_1 = startmiddag starttijd pauze = 13.15u 6u 15min = 7u Nu is niet meer aan de voorwaarde (tijd_1 werkblok_min <= werkblok _max) voldaan. Om alle mogelijke shifts te vinden, voeren we opnieuw een lus in met teller a, maar amax zal een andere waarde aannemen. De teller zal ook maar lopen van de waarde nul tot amax -1. Hier kunnen we niet zeggen dat periode_1 gelijk is aan werkblok_min want dan zou periode_2 de waarde werkblok_max overschrijden. We doen het volgende: In lus 1: periode_1 = werkblok_max In lus 2: periode_1 = werkblok_max steppauze Via grafisch denken en de combinatieleer hebben we voor amax volgende waarde gevonden: am ax 2 * werkblok _ max ( tijd _1+ pauze) = int + 2 * steppauze pauze intervaltime pauze intervaltime + 1 In het voorbeeld vindt men voor amax 3. De teller a zal dus lopen van nul tot twee. De mogelijkheden staan in de figuur hieronder afgebeeld: 42

56 Hoofdstuk 4: Model lus 1 lus 2 lus 3 6:00 6:15 6:15 6:30 6:30 6:45 6:45 7:00 7:00 7:15 7:15 7:30 3u 7:30 7:45 3u30 7:45 8:00 4u 8:00 8:15 8:15 8:30 8:30 8:45 8:45 9:00 9:00 9:15 pauze 9:15 9:30 9:30 9:45 pauze 9:45 10:00 10:00 10:15 pauze 10:15 10:30 10:30 10:45 10:45 11:00 11:00 11:15 4u 11:15 11:30 3u30 11:30 11:45 3u 11:45 12:00 12:00 12:15 12:15 12:30 12:30 12:45 12:45 13:00 13:00 13:15 Figuur 9: tijd_1 werkblok_min > werkblok _max Wegschrijven naar Excel Eens de grootte van periode_1 en periode_2 gekend is door middel van één van bovenstaande mogelijkheden, ligt periode_3 vast (nl. tijd_2). Vervolgens moeten deze shifts nog wegschreven worden naar Excel. Hierbij duiden we per tijdsinterval en per shift aan of de operator werkt (1) of niet (0). De integer intv_periode geeft het aantal intervallen weer dat een bepaalde periode in beslag neemt. Bv. is periode 1 gelijk aan 2 uren en is intervaltime (de grootte van een interval) gelijk aan 15 min, dan zal 2uur 60 min/ uur intv_periode_1 = = 8 zijn. 8 ééntjes zullen weggeschreven worden naar 15min Excel: intv_periode_1 = periode_1 / intervaltime 43

57 Hoofdstuk 4: Model intv_periode_2 = periode_2 / intervaltime intv_periode_3 = periode_3 / intervaltime Om het gemakkelijker te maken, zorgen we er eerst voor dat er per shift overal nullen staan, zo moet er nog enkel het cijfer 1 weggeschreven worden. Het is de bedoeling dat er per periode in de juiste intervallen ééntjes komen. Opnieuw verschaft een FOR-lus de oplossing: For i = 1 To intv_periode_1 ActiveSheet.Cells(startintv + i, startkol + k) = 1 Next i De ééntjes komen in de rij startintv + 1 tot in de rij startintv + intv_periode_1. De kolomindex hangt af van de hoeveelste shift het is, wat we bijhouden via de parameter k. Startintv is voor elke periode en voor elke situatie verschillend: Voor periode_1 is deze steeds gelijk aan: startintv = 3 + (starttime - openingstijd) / intervaltime De intervallen starten pas vanaf rij (3+1). De tweede term bepaalt het aantal intervallen die er zijn vanaf de openingstijd van het call center tot aan de starttijd van de shift. Voor periode_2 en indien er een middagpauze is en een kleine pauze voor de middag: startintv =startintv + intv_periode_1 + pauze / intervaltime Vanaf het vorige startinterval tellen we het aantal intervallen bij dat de eerste periode en de kleine pauze in beslag nemen. Voor periode_3 en indien er een middagpauze is en een kleine pauze voor de middag: startintv =startintv +intv_periode_2 +middagpauze /intervaltime Vanaf het vorige startinterval tellen we het aantal intervallen bij dat de tweede periode en de middagpauze in beslag nemen. 44

58 Hoofdstuk 4: Model Situatie 2: indien het een shift is met middagpauze zonder kleine pauze Deze situatie is een vereenvoudigde versie van situatie 1. Hier heeft men maar te maken met twee periodes, één voor de middag en één na de middag. tijd_1 = startpauze - starttime tijd_2 = totaal_werktijd(tw) - tijd_1 periode_1 = tijd_1 periode_2 = tijd_2 Het wegschrijven van de ééntjes gebeurt op identieke manier Situatie 3: indien geen middagpauze Als er geen middagpauze voorzien wordt, kan de gebruiker opnieuw enkele parameters invullen. Zo kan gekozen worden vanaf welk tijdstip (zonder_middag_start) er shifts kunnen voorkomen; dit zal meestal ergens rond het middaguur zijn. Ook kan geselecteerd worden hoeveel pauzes er zullen zijn (aantal_pauzes) en hoelang deze pauzes duren (pauze_1, pauze_2, pauze_3). Er is een mogelijkheid voorzien tot 3 pauzes, wat meer dan genoeg is. Anders dan in situatie één en twee wordt hier enkel de begintijd van de shift en de totale werktijd gevarieerd met twee FOR- lussen. Afhankelijk van het aantal pauzes creëren we opnieuw alle mogelijke shifts: Als er één pauze is, zullen er twee periodes zijn Als er twee pauzes zijn, zullen er drie periodes zijn Als er drie pauzes zijn, zullen er vier periodes zijn Om dit te verwezenlijken, hanteren we opnieuw FOR-lussen, waarbij het aantal lussen afhankelijk is van het aantal pauzes. Indien er n pauzes voorkomen, zijn er n FOR-lussen. In deze lussen variëren we steeds de (n-1) periodes, die we nu blokken noemen. Dus: Als er één pauze is, zal er één FOR-lus zijn, waarin we de lengte van het eerste werkblok variëren: blok(1) = werkblok_min + b1*steppauze. Waarbij b1 waarden zal aannemen van 0 tot (werkblok_max - werkblok_min) / steppauze, zodanig dat blok (1) de waarde werkblok_max niet overschrijdt. blok(2) = totaal_werktijd blok(1). 45

59 Hoofdstuk 4: Model Als er twee pauzes zijn, gebruiken we twee FOR-lussen. Hier zal zowel de lengte van werkblok(1) als van werkblok(2) gevarieerd worden: blok(1) = werkblok_min + b1*steppauze; blok(2) = werkblok_min + b2*steppauze; Waarbij b1 en b2 nu de waarden 0, 1, 2,... krijgen. blok(3) = totaal_werktijd blok(1) blok (2) Indien er drie pauzes voorzien worden, zullen er drie FOR-lussen zijn, waarin we blok(1), blok(2) en blok (3) zullen variëren. Het wegschrijven van ééntjes en nullen gebeurt op dezelfde manier als in situatie één en twee. Door de beperking van de oplosser in Excel, is het aantal shifts beperkt tot 200. Hieronder ziet u een voorbeeld. 46

60 Hoofdstuk 4: Model Figuur 10: Creatie van de shifts. 47

61 Hoofdstuk 4: Model 4.4 Het Excel bestand Output Om de simulaties met elkaar te kunnen vergelijken, hebben we een apart bestand voorzien. In dit bestand kan de gebruiker de resultaten van iedere simulatie laden. De Excel file bestaat uit 3 tabbladen: Intro Occupation Output Intro Na het beëindigen van de simulatie in ED, moet de gebruiker op de knop Export Results 6 klikken om de resultaten naar dit Excel bestand te exporteren. In deze file kan men maximaal 20 simulaties met elkaar vergelijken. Om de resultaten in de juiste tabbladen te plaatsen, moet men op de knop inladen van resultaten simulatie x drukken. Voor men op deze knop drukt, moet men eerst in de respectievelijke kolommen aangeven hoeveel call types en hoeveel teams er gebruikt werden in simulatie x Occupation In dit komt blad komt de informatie over de tijdbesteding van de operatoren terecht. Door op de knop grafiek te drukken, kan deze data ook op een grafische manier getoond worden Output Hier verzamelen we alle data betreffende de prestatieparameters: Aantal blocked calls Aantal abandonments Aantal oproepen dat behandeld werd binnen de service level tijd Aantal oproepen dat niet werd behandeld binnen deze tijd. Behaald service level Vooropgesteld service level Gemiddelde wachttijd 6 Zie 4.7: Link tussen ED en Excel. 48

62 Hoofdstuk 4: Model 4.5 ED-model Om de werking in een contact center na te bootsen, hebben we een simulatiemodel gebouwd. De gebruiker kan via dit model verschillende scenario s met elkaar vergelijken. Het is niet de bedoeling dat de gebruiker iets moet instellen of wijzigen aan dit model. Het simulatiemodel is gelinkt met Excel. De gebruiker moet in Excel alle noodzakelijke data ingeven, dat van toepassing is op zijn/haar situatie, en op basis daarvan wordt het simulatiemodel automatisch opgesteld. Het software pakket dat we hebben gebruikt om dit simulatiemodel op te bouwen heet Entertrise Dynamics. Hieronder schetsen we de manier waarop we het model hebben samengesteld Algemeen In grote lijnen kan men zeggen dat een oproep in een contact center de volgende stadia doorloopt: aankomst wachten verwerking terminatie Dit kan men eenvoudig simuleren met behulp van standaardatomen die in ED voorhanden zijn: Product atoom: Dit stelt een oproep voor. In onderstaande figuur wordt dit weergegeven met het blauwe bolletje. Source atoom: Met dit atoom kan men het aankomstpatroon van de oproepen beïnvloeden. Queue atoom: Dit stelt een wachtrij voor. Server atoom: In dit atoom gebeurt de eigenlijke verwerking van de oproep. In dit atoom werkt er maar 1 operator. Sink atoom: Hierin komen de behandelde oproepen terecht. 49

63 Hoofdstuk 4: Model Figuur 11: Weg van oproep doorheen een uiterst vereenvoudigd contact center. Dit is natuurlijk een uiterst eenvoudige manier om een contact center na te bootsen. Dit stemt niet overeen met de realiteit: Contact centra moeten verschillende types oproepen behandelen, waaronder telefoonoproepen en taken. Contact centra werken met verschillende operatorgroepen waarin verschillende operatoren met dezelfde skills aanwezig zijn. Oproepen kunnen behandeld worden door verschillende groepen, weliswaar met andere bedieningstijden als de groepen verschillende skill levels hebben voor dat type oproep. Om al deze redenen moet er een ingewikkelder model gemaakt worden. De standaardatomen uit de bibliotheek van ED blijken niet geschikt om een realistisch model te maken. Daarom zijn we verplicht de code in deze atomen drastisch aan te passen. Hierop komen we later in de tekst terug. In het stuk dat nu volgt, leggen we de strategie en de opbouw van het model uit. 50

64 Hoofdstuk 4: Model Opbouw van het simulatiemodel Aankomstpatroon van de oproepen Per telefonische oproep en/of per taak type zijn er automatisch 3 atomen voorzien: een product atoom een source atoom een queue atoom Figuur 12: product + source + queue Het source atoom maakt de juiste hoeveelheid producten aan. In de forecast in Excel wordt aangegeven hoeveel telefonische oproepen/taken er zullen toekomen per intervaltijd. Deze aantallen zijn terug te vinden in de tabel van de source. Per intervaltijd worden vervolgens tijdstippen aangemaakt waarop een product gecreëerd moet worden. We kiezen op uniforme wijze x tijdstippen uit het interval [0, intervaltijd]. Zo verkrijgt men een realistisch aankomstpatroon. Hieronder ziet u een grafiek, die de tijdstippen weergeeft waarop de oproepen gecreëerd worden. We hebben als voorbeeld aangenomen dat er in een intervaltijd van 30 minuten, 25 oproepen toekomen. 51

65 Hoofdstuk 4: Model arrivals seconden call nummer Figuur 13: Creatie van oproepen in één interval. Uit de grafiek zie je dat na 20 seconden, oproep 1 en 2 aankomen. Na 60 seconden komt call 3 toe enz Wachtrij (queue) Eens de klant in het contact center binnengeraakt is, moet hij/zij even wachten, als op dat moment alle operatoren die zijn/haar oproep kunnen behandelen, bezet zijn. Eenmaal een geschikte operator terug beschikbaar, kan de klant uit de wachtrij (=queue) vertrekken Procentuele bezetting van de telefoonlijnen Er is echter een beperking: een contact center beschikt maar over een beperkt aantal telefoonlijnen. Indien alle lijnen bezet zijn, krijgt de beller een bezettoon te horen. Deze situatie doet zich voor als de som van het aantal wachtende klanten in de queue s en het aantal oproepen in behandeling gelijk is aan het aantal beschikbare telefoonlijnen. 52

66 Hoofdstuk 4: Model Om dit te simuleren maken we gebruik van het zogenaamd condition control atoom. In dit atoom kan men een bepaalde voorwaarde definiëren. Men kan dan in hetzelfde atoom schrijven wat er dient te gebeuren wanneer al dan niet aan deze voorwaarde voldaan is. De ingangen van dit atoom verbinden we met de queue s en met de verschillende operatorgroepen. Figuur 14: Simuleren, rekening houdend met aantal beschikbare telefoonlijnen. Als voorwaarde gaan we na of de inhoud van alle queue s en alle operatorgroepen groter is dan het aantal voorziene telefoonlijnen. Is dit het geval, dan mogen er geen nieuwe oproepen binnengelaten worden; in het andere geval wel natuurlijk. Dit kunnen we gemakkelijk simuleren met het standaard condition control atoom. Maar deze oplossing is nog niet volledig correct. Men moet namelijk een onderscheid maken tussen een telefonische oproep en een taak. De taak(bv. een ) gebruikt geen telefoonlijn. Daarom mag men met het aantal onbehandelde taken die zich in het contactcenter bevinden, geen rekening houden in bovenstaande voorwaarde. Om dit te simuleren hebben we het condition control atoom moeten aanpassen. Als besluit kan je zeggen dat we: een beperking leggen op het aantal onbehandelde telefonische oproepen. geen limiet stellen op het aantal taken in het contact center. 53

67 Hoofdstuk 4: Model Wanneer men een oproep niet binnen laat, spreekt men van een blocked call. We gebruiken een extra atoom om het aantal blocked calls te bewaren: een fifo-queue ( fifoqueue block ). We verbinden dit atoom met het 2 e outputkanaal van de verschillende sources. Figuur 15: Gebruik van fifo-queue block. De informatie die we in deze fifo-queue opslaan, gebruiken we om het percentage blocked calls te berekenen voor ieder call type (geen taak). Voor een bepaald call type (geen taak) geldt: aantal klanten die niet binnengeraakt zijn Percentage blocked calls = x 100 % aantal klanten die gebeld hebben Dit percentage wordt op grafische manier voorgesteld in het simulatiemodel: Figuur 16: Grafische voorstelling van de blocked calls. 54

68 Hoofdstuk 4: Model Om de gebruiker van het model te laten zien hoeveel procent van de tijd er x aantal lijnen gebruikt worden, hebben we de layout van het condition control atoom aangepast. Via een staafdiagram ziet men hoeveel procent van de tijd er respectievelijk 1,2,3, telefoonlijnen gebruikt worden. In onderstaande figuur ziet u een voorbeeldje waarin er 5 telefoonlijnen voorzien zijn. De situatie waarbij op het zelfde moment 5 lijnen bezet zijn, komt in dit geval blijkbaar niet voor. Figuur 17:Bezetting telefoonlijnen Abandonment Mensen wachten geen uren om in contact te komen met een operator. Indien het te lang duurt haken ze in. Per call type (geen taak) is er een abondonment tijd gedefinieerd. Overtreft de wachttijd in de queue deze abandonment tijd, dan haakt de klant in. Om dit te simuleren dienen wat atomen aangepast te worden; waaronder het product atoom en de queue. We voegen opnieuw een extra atoom toe om al deze oproepen op te slaan: een fifoqueue ( fifo-queue aban ). De gevolgde strategie is eenvoudig: we kijken of de wachttijd in de queue van een bepaald call type groter is dan de abandonment tijd. Is dit niet het geval, dan blijft de oproep in de queue. Als het daarentegen wel het geval is, dan dient de oproep (= product) uit de queue verwijderd te worden. We sturen deze oproep langs een inputkanaal van de queue naar de fifo-queue, die alle abandonned oproepen verzamelt. 55

69 Hoofdstuk 4: Model Figuur 18: Abandonment strategie. Net zoals bij de bezetting van de lijnen hebben we ervoor gezorgd dat de gebruiker via een grafiek kan zien hoeveel procent van de oproepen ingehaakt hebben. Voor ieder call type (die geen taak is tenminste) voorzien we een staaf in de grafiek. We berekenen het percentage abandonments voor call type i als volgt: aantal abandonments Abandonment(%) call type i = x100% aantal oproepen dat binnengekomen is Een voorbeeld met 3 verschillende call types kunt u hieronder zien. Figuur 19: Grafische voorstelling van de abandonments. 56

70 Hoofdstuk 4: Model De gemiddelde wachttijd Een belangrijke parameter in de contact center wereld is de gemiddelde wachttijd van een klant. In het simulatiemodel komt dit op het volgende neer: Hoeveel tijd spendeert een product gemiddeld in een queue? We gebruiken opnieuw een fifo queue ( Gemiddelde wachttijd ) om alle benodigde data op te slaan om deze tijden te berekenen. Telkens een product een queue verlaat, schrijven we de tijd die het product in de queue heeft doorgebracht naar deze fifo queue. In deze queue worden de wachttijden opgeslagen per call type. De gemiddelde wachttijd voor een bepaald call type i berekenen we in deze queue als volgt: Gemiddelde wachttijd call type i = aantal som van alle wachttijden i oproepen i die vertrokken zijn uit de queue i Opnieuw beelden we deze tijden grafisch af in een staafdiagram: Figuur 20: Grafische voorstelling van de gemiddelde wachttijd Service level De meest bekende en meest gehanteerde performantie parameter in de contact centra wereld is zonder enige twijfel het service level: Hoeveel procent van de binnengekomen oproepen (telefoon of taak) werd beantwoord binnen een bepaalde tijd? Meestal gebruikt men het 80/20 service level: 80% van de oproepen wordt behandeld binnen de 20 seconden. Hierin is echter een trend in de industrie waar te nemen naar 70/30. De klant is met andere woorden bereid om iets langer te wachten als hij/zij daarna een degelijke en efficiënte behandeling krijgt. 57

71 Hoofdstuk 4: Model Om deze parameter ook tijdens de simulatie te berekenen, gebruiken we opnieuw een fifo-queue ( fifo-queue sl ). De vereiste data om het service level te kunnen berekenen komt in een tabel terecht die bij dit atoom hoort: Aantal Aantal oproepen dat oproepen dat Aantal behandeld behandeld Aantal Service level behandelde werd na de werd voor de abandonments (%) oproepen service level service level tijd tijd Call Type Call Type2 Call Type3 Tabel 2: Berekening van het service level. In de eerste kolom komt het aantal oproepen dat behandeld werd door een willekeurige operatorgroep. In kolom 2 komt het aantal oproepen terecht die langer dan de service level tijd hebben moeten wachten om behandeld te worden. Kolom 3 = kolom 1 kolom 2. In kolom 4 schrijven we het aantal abandonments In de 5 e kolom tenslotte, berekenen we het service level: Service level = aantal oproepen dat werd behandeld voor de service level aantal behandelde oproepen + aantal abandonments tijd * 100 % Voorbeeld: Met de getalwaarden uit bovenstaande tabel kunnen we het service level berekenen voor call type1: 80 Service level = 100% = 76.9 % x 58

72 Hoofdstuk 4: Model De fifo-queue (fifo-queue sl) is verbonden met de verschillende queue s die de oproepen bevatten en met de fifo-queue die het aantal abandonments bijhoudt (fifo-queue aban). Figuur 21: Uitgebreid model om het service level te bepalen. Opnieuw kan de gebruiker met één oogopslag de service levels van de verschillende call types zien met behulp van een door ons ontwikkeld staafdiagram: Figuur 22:Grafische voorstelling van de verschillende service levels. 59

73 Hoofdstuk 4: Model Verwerking van de oproepen De gebruiker kan in Excel ingeven hoeveel verschillende soorten operatorgroepen er zijn. Onder een groep verstaan we een verzameling van operatoren die dezelfde skill levels hebben voor de verschillende call types. Operatorgroepen hebben bepaalde skill levels. Hoe hoger het skill level is voor een call type, hoe vlugger de oproep of taak kan beantwoord worden. Als men kan kiezen, stuurt men de oproepen vanuit de queue naar de groepen met de hoogste skill levels voor de respectievelijke oproepen. Indien de groepen met het hoogste skill level allen bezet zijn, laat men de oproepen door groepen behandelen met een iets lager skill level. Bv.: Call type 1 Call type 2 Groep1 2 1 Groep2 1 2 Tabel 3: Skill levels van de operatorgroepen. De oproepen uit queue 1 gaan bij voorkeur naar groep1 en deze uit queue 2 naar groep 2. Bepaalde oproepen zijn belangrijker dan andere. Denk bijvoorbeeld aan klanten die iets wensen te kopen. Deze oproepen moeten voorrang krijgen op minder belangrijke oproepen. Daarom voorzien we de mogelijkheid dat de gebruiker in Excel aan de call types een prioriteit kan geven. Wanneer een team de keuze heeft om verschillende oproepen te beantwoorden, moet het team eerst de oproep behandelen met de hoogste prioriteit. Bv.: Prioriteit Call type 1 5 Call type 2 2 Tabel 4: Prioriteiten van de call types. Call type 1 krijgt altijd voorrang op call type 2. 60

74 Hoofdstuk 4: Model In ED kan men een operatorgroep voorstellen met een multiserver atoom. De outputstrategie van de queue s en de inputstrategie van de multiservers wordt in onderstaande figuur samengevat: Figuur 23: Verwerking van de oproepen door de operatorteams. Een belangrijke parameter betreffende de operatoren is de productiviteit. Hoe hoger deze is, hoe beter. Deze parameter wordt ook met het simulatiemodel berekend. We berekenen per operatorgroep de productiviteit. We kijken hoeveel procent van de beschikbare tijd de operatoren bezig zijn met het behandelen van een bepaalde oproep. Ter gelijkertijd ziet men ook hoeveel procent van de tijd de operatoren gewoonweg met de vingers zitten te draaien ( idle time ). We hebben ervoor gekozen deze data voor te stellen met een cirkeldiagram. Deze grafiek verschijnt wanneer de gebruiker tweemaal klikt op de betreffende operatorgroep (multiserver atoom). 61

75 Hoofdstuk 4: Model Figuur 24: Productiviteit van Team1. Om deze grafiek te maken, hebben we een extra atoom ingevoerd (een fifo-queue, namelijk Occupation ). In dit atoom slaan we alle data op, die nodig zijn om de productiviteit van een team te berekenen. Aan ieder team (multiserver) kennen we een dergelijk atoom toe. Figuur 25: Occupation atoom Terminatie van de oproep Nadat de oproep (telefoongesprek of taak) afgehandeld is door de operator, wordt de oproep naar een sink atoom getransporteerd. Dit atoom vernietigt het product (=oproep). De gebruiker kan in dit atoom nagaan hoeveel oproepen er reeds afgewerkt zijn. Om een onderscheid te kunnen maken tussen de verschillende oproepen, voorzien we evenveel sinks als er call types zijn. 62

76 Hoofdstuk 4: Model Opdat de multiserver de producten naar de juiste sink zou sturen, gebruiken we opnieuw een fifo-queue ( Output ). Dit atoom zorgt dat de verschillende call types op de juiste plaats terecht komen. Aan ieder team(=multiserver atoom) hangen we zo n Output atoom. Figuur 26: Output atoom met 2 call types. Dus aan ieder multiserveratoom hangen er telkens 2 fifo-queue s: Occupation atoom Output atoom Overzicht van het simulatiemodel Op de volgende pagina ziet u een overzicht van het simulatie model met 3 call types (2 taken) en 2 operatorteams. 63

77 Hoofdstuk 4: Model Figuur 27: Algemeen overzicht van het simulatiemodel met 3 verschillende call types (2 taken) en 2 operatorteams. 64

78 Hoofdstuk 4: Model 4.6 Aanpassing van de atomen We hebben de basisatomen in Enterprise Dynamics moeten aanpassen om een correcte werking te verkijgen van het model. We zullen niet alle aangepaste atomen ontleden maar enkel de voornaamste. Achter de basisatomen in ED gaat er veel code schuil. Aan de hand van enkele voorgedefinieerde termen zoals bijvoorbeeld setlabel, setcell, repeat, kan men de code schrijven. Refereren naar een atoom in ED: refereren in ED is zoals het gebruik van een pointer in C++. Referentie naar andere atomen is noodzakelijk om informatie of data te krijgen van dat atoom. Refereren gebeurt altijd relatief. Current c & Involved i o c is het huidige atoom waarop het statement geschreven wordt. o i is het betrokken atoom Men kan in de atomen code schrijven op verschillende plaatsen. Deze plaatsen onderscheiden zich van elkaar door de gebeurtenis die optreedt. Er zijn verschillende mogelijke gebeurtenissen: een atoom die toegekomen is. on entered een atoom die vertrokken is. on excited resetten. on reset outputchannel die klaar is om iets te versturen. on OcReady men kan een event programmeren die vanuit andere on Event andere plaatsen aangeroepen wordt. 65

79 Hoofdstuk 4: Model Figuur 28: Atom Editor Queue On entered Wanneer een product (in dit geval een call type) in een queue binnengekomen is, gebeurt er het volgende: We plakken een label starttijd op het binnengekomen product. Met dit label kan men de verblijftijd van het product in de queue bepalen. Dit doen we als het product uit de queue vertrekt. Op de queue zelf plakken we het label cumtoegekomen. Dit label houdt bij hoeveel calls of taken er binnengekomen zijn. Dit gebruiken we verder om het percentage abandonments te bepalen (in het atoom: fifo-queue-aban). Bijvoorbeeld: setcell(label([type],i),2,label([cumtoegekomen],c),in(4,c) ) o Deze code schrijft cumtoegekomen in de tabel van het atoom fifo-queueaban. Men verwijst naar dit atoom met het statement: in(4,c). Dit statement activeert het atoom dat aan de 4 e inputchannel van de queue hangt. o label([type],i):dit defineërt de rij van de tabel waarop de data moet geschreven worden. In het vorige atoom (source) hebben we het label type op elk call type geplakt. Zo kreeg call type 1 label 1, call type 2 label 2, enz. De tabel bevat evenveel rijen als er call types zijn. 66

80 Hoofdstuk 4: Model o 2: bepaalt de kolom in de tabel Voor iedere telefonische oproep bewaren we de tijd waarop deze toekomt om later de bezetting van de lijnen in het condition control atoom te kunnen berekenen. In het source atoom werd ook het label aban aan iedere telefonische oproep bevestigd. Dit label bevat de AWT van ieder type. Een klant is maar bereid een bepaalde tijd te wachten in de queue, daarna zal hij inhaken (=abandonment). Eens het product in de queue binnengekomen is, roepen we een event op na aban seconden. In dit event kijken we of het product zich nog steeds in de queue bevindt. In het positieve geval sturen we het product vervolgens langs inputchannel 4 naar het atoom fifo-queue-aban. code: do(if(>=(content(c),att(2,c)), do(closeallic(c),setstatus(14,c)), do(closeallic(c),setstatus(15,c),createevent(0,c,2)) ), setrank(att(5,c),i), setlabel([starttijd],time,i), setlabel([timein],time,i), if(not(label([task],i)), do(inc(att(13,in(5,c))), setcell(att(13,in(5,c)),2,time,in(5,c)) ) ), setlabel([cumtoegekomen], +(label([cumtoegekomen],c),1),c), setcell(label([type],i),2,label([cumtoegekomen],c),in(4,c) ), setcell(label([type],i),4,label([aban],i),in(3,c)), att(3,c), if(>(label([aban],i),0), createevent(label([aban],i),i,1,0,c) ), createevent(0,c,1) ) 67

81 Hoofdstuk 4: Model On exit Indien een product uit het queue atoom is vertrokken, doen we het volgende: We controleren hoelang het product in de queue gezeten heeft. Is deze tijd groter dan de service level tijd, dan geven we aan het label telaat de waarde 1 ; in het andere geval 0. Het label wachttijd wordt toegekend in het source atoom en starttijd initialiseren we op het moment dat het product de queue binnenkomt. if (>(-(time, label([starttijd],i)),label([wachttijd],i)), setlabel([telaat],1,i), setlabel([telaat],0,i) ), Verder houden we de maximale wachttijd bij in de queue via het label maxwachttijd. Deze waarde schrijven we in de tabel van het atoom gemiddelde wachttijd (kolom 6). if(>(-(time,label([starttijd],i)),label([maxwachttijd],c)), setlabel([maxwachttijd],-(time,label([starttijd],i)),c) ), setcell(label([type],i),6,label([maxwachttijd],c),in(3,c)), We berekenen de gemiddelde wachttijd die ieder call type in de queue spendeert. Daarvoor definiëren we 2 nieuwe labels: cumtijd en cumvertrokken. cumtijd bevat de cumulatieve wachttijd van ieder product in de queue. cumvertrokken houdt bij hoeveel producten er de queue verlaten hebben, naar de teams of naar het fifo-queue-aban atoom. Deze waarden worden vervolgens in de tabel van het atoom gemiddelde wachttijd geschreven, respectievelijk in kolom 1 en 2. In kolom 3 plaatsen we dan de gemiddelde wachttijd: cumtijd cumvertrokken. 68

82 Hoofdstuk 4: Model setlabel([cumtijd], +(label([cumtijd],c),- (time,label([starttijd],i))),c), setcell(label([type],i),1,label([cumtijd],c),in(3,c)), setlabel([cumvertrokken], +(label([cumvertrokken],c),1),c), setcell(label([type],i),2,label([cumvertrokken],c),in(3,c)), setcell(label([type],i),3,/(cell(label([type],i),1,in(3,c),1),c ell(label([type],i),2,in(3,c),1)),in(3,c)), Vanuit dit atoom berekenen we ook het behaalde service level voor ieder call type. Wanneer een product het queue atoom verlaat langs de outputchannels en niet langs de inputchannel ( = abandonment), dan wil dit zeggen dat het product naar een team gaat en behandeld zal worden. In dit geval zal het label cumbeantwoord met eentje stijgen. Als in dit geval ook het label telaat op 1 staat (de wachttijd was groter dan de service level tijd), dan verhoogt het label cumtelaatbeantwoord ook met 1. De waarden van deze 2 labels worden geschreven in de tabel van het atoom fifo queue sl, respectievelijk in kolom 1 en 2. In kolom 3 komt het verschil van kolom 1 en 2, deze kolom bevat met andere woorden het aantal calls dat beantwoord werd binnen de service level tijd. In kolom 4 komen het aantal abandonned calls (deze komen daar terecht via het atoom fifo-queue-aban ). In kolom 5 tenslotte berekenen we het eigenlijke service level: aantal oproepen dat werd behandeld voor de service level tijd aantal beantwoorde oproepen + aantal abandonments * 100 % setlabel([langsoutput],0,c), repeat( nroc(c), if(=(oc(c),count), setlabel([langsoutput],1,c) ) ), if(=(label([langsoutput],c),1), do( setlabel([cumbeantwoord], +(label([cumbeantwoord],c),1),c), setcell(label([type],i),1,label([cumbeantwoord],c),in(2,c) ) ) ), if(and(=(label([telaat],i),1),=(label([langsoutput],c),1)), 69

83 Hoofdstuk 4: Model do( setlabel([cumtelaatbeantwoord], +(label([cumtelaatbeantwoord],c),1),c), setcell(label([type],i),2,label([cumtelaatbeantwoord],c),in(2,c ) ) ) ), setcell(label([type],i),3,- (label([cumbeantwoord],c),label([cumtelaatbeantwoord],c)),in(2, c)), setcell(label([type],i),5,*(100,/(cell(label([type],i),3,in(2,c ),1),max(1,+(cell(label([type],i),1,in(2,c),1),cell(label([type ],i),4,in(2,c),1))))),in(2,c)), Het service level van ieder call type wordt ook grafisch getoond in het simulatiemodel; hetgeen veel gebruiksvriendelijker is dan een tabel. Dit gebeurt via het atoom: fifo-queue-sl. Figuur 29: Service level. Tenslotte geven we aan het label uitqueue het outputchannelnummer mee waaruit het product de queue verlaat. Dit hebben we nodig om in de teams de correcte bedieningstijd van de oproep te bepalen. setlabel([uitqueue],oc(c),i), On reset Bij het resetten van het simulatiemodel zetten we alle labels op 0. do( setstatus(13,c), traceclear, setlabel([tottime],0,model), setlabel([cumtelaatbeantwoord],0,c), 70

84 Hoofdstuk 4: Model setlabel([cumbeantwoord],0,c), setlabel([cumabandon],0,c), setlabel([cumtoegekomen],0,c), setlabel([maxwachttijd],0,c), setlabel([cum s],0,c), setlabel([cumtijd],0,c), setlabel([cumvertrokken],0,c), closealloc(c) ) On OcReady De teams met het grootste skill level voor een call type hangen aan de eerste outputchannels van de betreffende queue. Bij vertrek uit de queue kijken we eerst of het team aan het eerste outputchannel de oproep kan behandelen. Indien ja, dan sturen we de oproep naar daar door. Indien nee, dan kijken we of het team, verbonden aan het 2 e outputchannel vrij is, enz Hiervoor maken we gebruik van een lus die max nroc(c) keer wordt doorlopen. Nroc(c) is gelijk aan het aantal outputchannels van de queue. code: If(Content( c) > 0, do( setlabel([found],0,c), loopuntil(>(label([found],c),0), if(ocready(count,c), setlabel([found],count,c) ), nroc(c) ), if(>(label([found],c),0), MoveRequest( First( c), label([found],c)) ) ) ) 71

85 Hoofdstuk 4: Model Multiserver atoom Tabellen Tabel 1 Deze tabel is gedefinieerd op het multiserver atoom zelf. Het aantal rijen is gelijk aan het aantal tijdsintervallen dat in Excel werd ingesteld. Per rij (=tijdsinterval) bevat kolom1 de capaciteit van de groep Tabel 2 Deze tabel definiëren we op de tweede uitgang van het multiserver atoom. Er wordt naar verwezen door het commando out(2,c) te gebruiken (in het multiserver atoom). Deze tabel houdt de tijden bij dat de groep bezig is met het verwerken van verschillende call types. In de eerste rij komt steeds de cumulatieve idle time van de groep. De tweede rij heeft als inhoud de cumulatieve tijd dat de groep bezig was met het call type (telefonische oproep of taak) met de hoogste prioriteit, de derde rij de tijd van call type met 2 de hoogste prioriteit, enz. Deze tabel gebruiken we om een cirkeldiagram te tekenen, die aangeeft hoeveel procent van de tijd het team bezig is met een bepaald call type Events Eventcode 1 Deze code wordt uitgevoerd als de behandeling van de oproep teneinde loopt. do( inc(att(4,c)), setrank(att(4,c),i), createevent(0,c,3) ) Attribuut 4 houdt bij hoeveel oproepen er in de server zitten, die klaar zijn om te vertrekken. Dit attribuut verhogen we met 1. Attribuut 4 gebruiken we om de positie van de oproep in het team te bepalen (= setrank). Deze actie is noodzakelijk omdat de volgorde waarin de producten de server verlaten verschillend is van de volgorde waarin de producten de server binnenkomen. De ene oproep heeft een langere bedieningstijd dan de andere. Daarom wordt bijgehouden hoeveel oproepen er klaar zijn om de server te verlaten. 72

86 Hoofdstuk 4: Model Op die manier vermijden we de volgende situatie. Stel dat een oproep later binnenkomt maar een korte bedieningstijd heeft. Dan is het logisch dat deze oproep niet hoeft te wachten om het team te verlaten totdat de behandeling van een oproep (die eerder was toegekomen) klaar is. Event 3 wordt uitgevoerd Eventcode 2 Deze code opent alle input channels en voert de inputstrategie uit. Zie if(<(content(c),att(1,c)), ) att(6,c) Eventcode 3 Alle output channels worden geopend: openalloc(c) Eventcode 4 Per tijdsinterval kan het aantal operatoren in een groep wijzigen (zie Excel). Om de capaciteit van de server dynamisch aan te passen, schreven we de volgende code. Dit event wordt niet op willekeurige momenten aangeroepen. Na ieder tijdsinterval doorlopen we deze code. Het label oldcap zetten we op de waarde van attribuut 1 (de huidige capaciteit). Het label currow, die de huidige rij van de tabel aangeeft, wordt verhoogd met 1. Als dit label groter is dan het totaal aantal rijen, stellen we het rijnummer opnieuw gelijk aan waarde 1. Op die manier doorlopen we de tabel cyclisch. Het label newcap stellen we gelijk aan de nieuwe capaciteit. Deze capaciteit halen we uit de tabel; de rij wordt aangegeven met het label currow. We houden de beschikbare tijd van de operatoren bij, om later hun productiviteit te kunnen berekenen. Het label cumavail verhogen we met een waarde die bepaald wordt door het product van de capaciteit met het verschil van de huidige tijd en het label starttijd van de multiserver. Op die manier houdt cumavail de beschikbare operatortijd bij, rekening houdend met het feit dat de capaciteit dynamisch verandert. Het label starttijd stellen we gelijk aan de huidige tijd. Zodat op die manier bij het volgend tijdsinterval cumavail op een correcte manier berekend wordt. 73

87 Hoofdstuk 4: Model Indien de nieuwe capaciteit groter is dan de oude capaciteit, mogen er opnieuw oproepen toegelaten worden in het multiserveratoom. o Attribuut 1 stellen we gelijk aan de nieuwe capaciteit en de inputstrategie wordt uitgevoerd (attribuut 6). Indien dit niet het geval zou zijn (nieuwe capaciteit < oude) mogen er geen oproepen binnenkomen want er zijn geen operatoren beschikbaar. Stel dat de capaciteit bijvoorbeeld van 8 naar 6 gaat. Op het moment dat deze wijziging doorgevoerd wordt, kan het zijn dat alle 8 operatoren bezig zijn met de behandeling van een oproep. Logisch is dat de operator zijn/haar gesprek eerst afwerkt vooraleer hij/zij inhaakt. Pas als het aantal oproepen, in behandeling, gedaald is naar 6 of lager, zullen we opnieuw toelaten dat nieuwe oproepen mogen binnenkomen. o Attribuut 1 wordt gelijk gesteld aan het maximum tussen enerzijds het aantal oproepen in de multiserver en anderzijds het label newcap. Na de intervaltijd wordt event 4 opnieuw uitgevoerd. Code: do( {case 4: update capacity} setlabel([oldcap],att(1,c),c), setlabel([currow],+(label([currow],c),1),c), if(>(label([currow],c),nrows(c)), setlabel([currow],1,c) ), setlabel([newcap],cell(label([currow],c),1,c),c), setlabel([cumavail], +(label([cumavail],c), *(att(1,c),-(time,label([starttijd],c))) ), c ), setlabel([starttijd],time,c), if(>(label([newcap],c),label([oldcap],c)), {laat opnieuw product binnenkomen} do( setatt(1,label([newcap],c),c), 74

88 Hoofdstuk 4: Model ) att(6,c) ), setatt(1,max(content(c),label([newcap],c)),c) ), createevent(att(11,c),c,4) On Reset Indien gereset wordt, zal het volgende gebeuren: De labels starttijd en cumavail van de server worden gereset (op nul gezet). De cellen van tabel 2 (occupation) krijgen allen 0 als inhoud. Attribuut 1, die de huidige capaciteit bijhoudt, stellen we gelijk aan de eerste waarde uit tabel 1 (dus de capaciteit in het eerste tijdsinterval). De labels old - en newcap krijgen ook deze waarde opgemeten. Na de duur van een interval, zal event 4 verricht worden. Het label currow van de de server zetten we op 1. Tenslotte worden alle ouputchannels gesloten. Code: On entered do(setatt(4,0,c), setlabel([starttijd],0,c), setlabel([ inserver],0,c), setlabel([cumavail],0,c), matrixrepeat(nrows(out(2,c)),ncols(out(2,c)), setcell(mcx,mcy,0,out(2,c)) ), setatt(1,cell(1,1,c),c), setlabel([oldcap],att(1,c),c), setlabel([newcap],att(1,c),c), createevent(att(11,c),c,4), setlabel([currow],1,c), setlabel([cum s],0,c), closealloc(c) ) Wanneer een product in de multiserver binnengekomen is, gebeurt er het volgende: We plakken een label curchan op het binnengekomen product. Dit label houdt bij langs welk inputkanaal het product de server is binnengekomen. Op het binnengekomen product, wordt ook het label starttijd gekleefd, die de begintijd bevat waarop de klant (oproep) door een operator geholpen werd. Dit label hebben we nodig om de productiviteit te berekenen. 75

89 Hoofdstuk 4: Model Vervolgens voeren we attribuut 7 uit. Dit attribuut bevat de code die uitgevoerd wordt als een product binnenkomt in de multiserver (entrytrigger). Bij het verlaten van de queue hebben we het product (de oproep) het label uitqueue meegegeven. Deze bevat het nummer van het outputchannel langs waar de oproep de queue verlaten heeft. In het model is het zo dat outputchannel 1 verbonden is met het team met de grootste skill voor dit type call, outputchannel 2 met het team met de op één na grootste skill, enz. Dus a.d.h.v. het outputchannel kan men het skill level weten. Nu wordt er aan elk product een tabel meegegeven, waarin per skill level de bedieningstijd staat. In kolom 1 van deze tabel staan de skill levels en in kolom 2 de overeenkomstige bedieningstijden. Als een product de queue verlaat langs outputchannel 1, dan kan men de bedieningstijd vinden in de tabel van dit product in kolom 2, rij 1. De waarde van attribuut 3 bevat de juiste bedieningstijd. Om met variatie rekening te houden gebruiken we een negatief exponentiële verdeling voor de bedieningstijden. Wanneer het team een taak (bv. ) moet behandelen, verhogen we het label inserver met 1. Dit label houdt bij hoeveel taken er op dit moment behandeld worden door de verschillende teams. Dit gebruiken we om de bezetting van de lijnen op een correcte manier te berekenen. Het is namelijk zo dat taken geen telefoonlijn in beslag nemen. Het label t-cycle wordt gelijk gesteld aan attribuut 3, de bedieningstijd. Event 1 wordt uitgevoerd na attribuut 3 seconden. Event 2 wordt onmiddellijk uitgevoerd. Code: do(closeallic(c), setlabel([starttijd],time,i), setlabel([timein],time,i), att(7,c), setatt(3,negexp(cell(label([uitqueue],i),1,i)),c), sddb([t-cycle],att(3,c),i), if(>(label([type],i),-(att(3,i),att(4,i))), setlabel([ inserver],+(label([ inserver],c),1),c) ), createevent((att(3,c)),c,1,0,i), createevent(0,c,2) ) 76

90 Hoofdstuk 4: Model On exited Als er een oproep de server verlaat, voeren we volgende code uit: Alle output kanalen van de server worden gesloten. Het label t-cycle, van de oproep die de server verlaat, zetten we op 0. Attribuut 4 wordt met eentje verminderd. Attribuut 4 houdt op iedere tijdstip het aantal oproepen bij die reeds behandeld zijn geweest door de groep en klaar zijn voor vertrek. Attribuut 8 wordt uitgevoerd. Deze bevat de exittriggercode, deze gebruiken we niet. Indien attribuut 4 verschillend is van nul, roepen we event 3 op. Dus indien er nog oproepen in de server zitten, worden alle output kanalen geopend. Met andere woorden, dan wordt de code on OcReady uitgevoerd. Als het gaat over een telefonische oproep, verminderen we attribuut 13 van het condition control atoom met 1. Dit attribuut houdt bij hoeveel telefoonlijnen er bezet zijn. Daarna berekenen we ook de procentuele bezetting van de lijnen, hetgeen men kan bekijken in de grafiek op het condition control atoom. De oproep die de server verlaat, heeft een specifiek type. In tabel 2, die de tijden bijhoudt van alle verschillende activiteiten, moet in de rij overeenkomend met dat specifiek call type, de tijd vermeerderd worden met de bedieningstijd van die oproep. Aan de hand van het verschil tussen de vertrektijd (de huidige tijd) en de aankomsttijd (label starttijd ) weten we de bedieningstijd. Indien het aantal producten in de server groter is dan de nieuwe capaciteit, mogen de inputchannels niet geopend worden. o De capaciteit is veranderd, dus we moeten cumavail bijwerken. o De starttijd stellen we gelijk aan de huidige tijd. o Attribuut 1 wordt gelijk gesteld aan het huidig aantal operatoren zodanig dat er geen nieuwe oproepen de server binnenkomen. Indien het over een taak gaat, verlagen we het label inserver met 1. Eventcode 2 wordt uitgevoerd. Code: do(closealloc(c), sddb([t-cycle],0,i), inc(att(4,c),-1), att(8,c), if(att(4,c)<>0, createevent(0,c,3) ), 77

91 Hoofdstuk 4: Model if(not(label([task],i)), do(setcell(att(13,out(3,c)), 3, +(cell(att(13,out(3,c)),3,out(3,c)), -(time, cell(att(13,out(3,c)),2,out(3,c)) ) ), out(3,c) ), inc(att(13,out(3,c)),-1), if(>(time,0), repeat(att(9,out(3,c)), ), ) ) ) setcell(count,4,*(100,/(cell(count,3,out(3,c)),time)),out(3,c)) setlabel([tottime],+(label([tottime],model),- (time,label([timein],i))),model), setcell(+(label([type],i),1), 1, +(cell(+(label([type],i),1),1,out(2,c)), -(time,label([starttijd],i)) ), out(2,c) ), if(>=(content(c),label([newcap],c)), do(setlabel([cumavail], +(label([cumavail],c), *(att(1,c),-(time,label([starttijd],c))) ), c ), setlabel([starttijd],time,c), setatt(1,content(c),c) ) ), if(>(label([type],i),-(att(3,i),att(4,i))), setlabel([ inserver],- (label([ inserver],c),1),c) ), createevent(0,c,2) ) On user Deze opdracht wordt uitgevoerd als de gebruiker tweemaal klikt op het multiserveratoom. Indien men dit doet verschijnt er een cirkeldiagram. Hierop ziet men hoeveel procent van de 78

92 Hoofdstuk 4: Model tijd de operatoren bezig zijn met het behandelen van een bepaald call type. De gebruiker ziet ook de idle time : de tijd waarin de operatoren geen werk hebben. Figuur 30: Productiviteit van Team 1. setcs(out(2,c)): dit slaat de referentie naar de tweede uitgang van het multiserver atoom op. Er kan gerefereerd worden naar het occupation atoom door cs te schrijven. Het label cumavail verhogen we met een waarde gelijk aan: het product van de capaciteit met het verschil van de huidige tijd en het label starttijd van de multiserver. Op het server atoom plakken we een label busytime en we stellen dit gelijk aan nul. We herhalen volgende lus zoveel keer als er ingangskanalen zijn in het server atoom: o Stel het label curchan gelijk aan het aantal maal de lus al doorlopen is. De eerste maal is dit één, tweede maal twee, enz. o Het label curcontent is ofwel gelijk aan het huidig aantal calls in de server ofwel het huidige aantal calls plus één. Plus één als er juist één door het huidige inputkanaal naar binnen komt. o In tabel 2, kolom 2 en rijnummer afhankelijk van het inputkanaal, wordt de huidige capaciteit ( curcontent ) vermenigvuldigd met de verstreken tijd vanaf de vorige capaciteit en opgeteld bij de huidige waarde in kolom 1. o Het label busytime wordt vermeerderd met de waarde in tabel 2, kolom 3. 79

93 Hoofdstuk 4: Model Code: do( setcs(out(2,c)), setlabel([cumavail], +(label([cumavail],c), *(att(1,c),-(time,label([starttijd],c))) ), c ), setlabel([busytime],0,c), repeat(nric(c), do( setlabel([curchan],count,c), setlabel([curcontent], ) sum(content(c),=(label([curchan],rank(count,c)),lab el([curchan],c))), c ), setcell(+(count,1), 2, +(cell(+(count,1),1,cs), *(label([curcontent],c),- (time,label([starttijd],c))) ), cs ), setlabel([busytime],+(label([busytime],c),cell(+(co unt,1),2,cs)),c) ) ), setcell(1,2,- (label([cumavail],c),label([busytime],c)),cs), setlabel([starttijd],time,c), execonuser(cs) 80

94 Hoofdstuk 4: Model Inputstrategie De inputstrategie van de multiserver bestaat eruit dat de oproepen met hoogste prioriteit voorrang krijgen op diegene met een lagere prioriteit. Het is zo dat inputkanaal 1 van de multiserver verbonden is met de queue van de oproep met hoogste prioriteit, en het laatste inputkanaal met de queue met laagste prioriteit. De multiserver kijkt eerst of er producten aan het wachten zijn in de queue s met hoogste prioriteit, is dit zo dan wordt dit product binnengetrokken in de multiserver. Zo niet gaat de multiserver kijken of er producten aan het wachten zijn in de queue s met de op één na hoogste prioriteit, enz. 81

95 Hoofdstuk 4: Model Fifo queue sl Dit atoom gebruiken we om het service level van alle call types grafisch voor te stellen. ED bezit enkele standaardgrafieken maar deze zijn niet zo geschikt voor ons simulatiemodel. Daarom hebben we zelf onze grafieken geprogrammeerd om het service level op een mooie manier voor te stellen. Dit is mogelijk door de gepaste code te schrijven bij User en 2dDraw On User We hebben als grafiek een staafdiagram gekozen (graphbar). Omdat bepaalde labels soms te lang zijn, kan het gebeuren dat er tekst in de grafiek komt. Om dit te vermijden, hebben we iets extra voorzien. De gebruiker kan zelf bepalen hoeveel plaats hij reserveert voor de labels. Dit kan hij/zij doen door tweemaal te klikken op het desbetreffende atoom en een percentage in te vullen: Figuur 31: Instellen van voorziene plaats voor de labels. Code: Edit ( standardeditstyle, ef([attval],1,[],[labellength (%)],[Sets the label length],0,100,0) ) { initgraph ( setgraphtitles([service levels],[],[]), setgraphtype(graphbar), setgraphdata(1, nrows(c), cell(gp,5,c), cell(gp,0,c) ), displaygraph ) } 82

96 Hoofdstuk 4: Model On 2dDraw Hier schrijven we de code die de layout van de grafiek bepaalt: Welke kleuren die er gebruikt worden voor de tekst, de achtergronden,... Waar de labels zich moeten bevinden. Hoe groot de staven moeten zijn, die de service levels van de verschillende call types weergeven. Hoe groot de rechthoek moet zijn. Welke onderverdeling we maken in de x-as. Opm.: In de code maken we gebruik van volgende termen: dishape: tekenen van een rechthoek ditext: tekst schrijven diline: tekenen van een lijntje De parameters die bij deze termen tussen haakjes staan, hebben te maken met positie, kleur, lettertype, We leggen de code uit a.d.h.v. de paars gemarkeerde tekst. Deze legt uit wat er in dat bepaald deeltje van de code gebeurt. Code: do( Tekenen van omtrek dishape(0,0,xsize,ysize,0,colorblack,color), Grafiektitel ditext(1,0.3,[service Levels:],colorblue,color(c),0.7,[Arial]), Bepalen van het gedeelte van de X-as die de labels innemen setlabel([ydist],/(-(ysize(c),3),max(1,nrows(c))),c), setlabel([label-x],min(-(xsize(c),3),*(xsize(c),/(att(1,c),100))),c), 83

97 Hoofdstuk 4: Model Tekenen van witte rechthoek in de grote waarin de staven zullen afgebeeld worden. dishape(label([label-x],c),1.9,-(xsize(c),+(label([labelx],c),1)),+(*(nrows(c),label([ydist],c)),0.1),0,colorblack,colorwhite ), Tekenen van de staven + afbeelding van de labels Begin-en eindpunt op de X-as afbeelden Een onderverdeling maken van de X-as in 5 gebieden dmv 4 streepjes repeat(nrows(c), do(ditext(1,+(2.3,*(- (count,1),label([ydist],c))),concat(cell(count,0,c),[ (],string(cell(count,5,c)),[%],[ ],[in],[ ],string(cell(count,6,c)),[ ],[sec)]),colorblack,color(c),0.6,[arial]), dishape(label([label-x],c),+(2,*(- (count,1),label([ydist],c))), *(/(-(xsize(c),+(label([label- x],c),1)),100),cell(count,5,c)),- (label([ydist],c),0.1),0,colorblack,colorblue ) ) ), ditext(-(label([label-x],c),0.2),- (ysize(c),0.9),[0],colorblue,color(c),0.5,[arial]), ditext(-(xsize(c),1.7),- (ysize(c),0.9),[100%],colorblue,color(c),0.5,[arial]), diline(+(label([label-x],c),/(-(xsize(c),+(label([label- x],c),1)),5)),- (ysize(c),1.25),0,0.25,colorblue,color(c),0.5,[arial]), diline(+(label([label-x],c),/(-(xsize(c),+(label([label- x],c),1)),2.5)),- (ysize(c),1.25),0,0.25,colorblue,color(c),0.5,[arial]), diline(+(label([label-x],c),/(-(xsize(c),+(label([label- x],c),1)),1.6667)),- (ysize(c),1.25),0,0.25,colorblue,color(c),0.5,[arial]), diline(+(label([label-x],c),/(-(xsize(c),+(label([label- x],c),1)),1.25)),- (ysize(c),1.25),0,0.25,colorblue,color(c),0.5,[arial]), 84

98 Hoofdstuk 4: Model ) Bij deze 4 streepjes schrijven we respectievelijk 20, 40, 60 en 80 ditext(+(label([label-x],c),/(-(xsize(c),+(label([labelx],c),1)),6.5)),-(ysize(c),0.9),[20],colorblue,color(c),0.5,[arial]), ditext(+(label([label-x],c),/(-(xsize(c),+(label([labelx],c),1)),2.8)),-(ysize(c),0.9),[40],colorblue,color(c),0.5,[arial]), ditext(+(label([label-x],c),/(-(xsize(c),+(label([label- x],c),1)),1.80)),- (ysize(c),0.9),[60],colorblue,color(c),0.5,[arial]), ditext(+(label([label-x],c),/(-(xsize(c),+(label([labelx],c),1)),1.32)),-(ysize(c),0.9),[80],colorblue,color(c),0.5,[arial]) Uiteindelijk verkrijgen we het volgende resultaat: Figuur 32: Service level 85

99 Hoofdstuk 4: Model 4.7 Link tussen Excel en ED Enterprise Dynamics (ED) en Excel dienen met elkaar gelinkt te worden om enerzijds een simulatiemodel te maken gebaseerd op gegevens die de gebruiker in Excel invult en anderzijds om simulatieresultaten van ED naar Excel over te kunnen brengen. Daarvoor gebruiken we ODBC. ODBC is een afkorting van Open DataBase Connectivity. ODBC is een standaard programma van Microsoft om toegang te krijgen tot een database, met als doel om elk gegeven te kunnen benaderen via een willekeurige applicatie, onafhankelijk van welk Database Management System (DBMS) de database onderhoudt. ODBC is een programma dat ervoor zorgt dat de aanvraag van gegevens door een applicatie wordt vertaald naar een taal die de DBMS begrijpt. Met een Database management system (DBMS) wordt het programma aangeduid dat in een database de opgeslagen gegevens beheert. Een database bestaat uit drie onderdelen: de opslagen gegevens (in één of meer bestanden), het programma waarmee de gegevens worden onderhouden (DBMS) en een gebruikersinterface die het gebruikers mogelijk maakt om de gegevens te beheren. Standaard gebruikt men in ED als applicatie de logistic suite. Voor het contact center simulatie model hebben we een nieuwe applicatieruimte ontwikkelt: CC Screening Tool. In deze ruimte zal de simulatie plaatsvinden. De gebruiker dient dan ook bij het opstarten van ED deze applicatie te selecteren. Eens ED opgestart, kan de gebruiker het model automatisch inladen via de knop Import Model die men kan terugvinden in de taakbalk onder Model. Nadat de simulatie is afgelopen kan men de resultaten naar Excel overbrengen via de knop Export Results. 86

100 Hoofdstuk 4: Model 4.8 Overzicht van het model In deze sectie maken we een duidelijk overzicht van de ontwikkelde tool. De gebruiker kan een simulatie uitvoeren d.m.v. een 5-tal stappen. In onderstaande figuur zijn deze 5 stappen schematisch voorgesteld. De optimalisatie van de shifts is optioneel. Stap1: Invullen van Excel bestand Input. Stap1bis: Optimalisatie van de shifts ( Optimalisatie ) Stap2: Model inladen in ED via Import Model. Stap3: Simulatie uitvoeren. Stap4: Resultaten van ED naar Excel overbrengen via Export Results. Stap5: Analyse in Excel bestand Output. Figuur 33: Overzicht van het model. 87

101 Hoofdstuk 5 : Case studies Hoofdstuk 5: Case Studies 5.1 Single skilled versus Multi skilled Situatieschets Call center Phone Home behandelt 10 verschillende call types. Het call center beschikt over 10 teams waarbij ieder team verschillende skill levels heeft. De bedieningstijd voor ieder call type bedraagt 200 seconden. De klant haakt in wanneer hij/zij langer moet wachten dan 900 seconden. Phone Home heeft zichzelf als doel gesteld om een servicelevel van 70/30 te halen. Het call center wil onderzoeken wat de invloed is van het aantal skills de verschillende teams hebben op de productiviteit en de gemiddelde wachttijd. Het call center wil te weten komen of het de moeite loont om de operatoren op te leiden zodat ze alle call types kunnen verwerken. Misschien kan men dezelfde prestatiekarakteristieken bekomen als de operatoren maar in staat zijn om een beperkt aantal call types te behandelen. Aan de hand van deze case studie kan Phone Home inschatten hoeveel ze best investeren in de opleiding van de operatoren. We vertrekken van de situatie waarbij alle teams in staat zijn om 1 call type te behandelen: single skilled. In de volgende simulaties voegen we telkens skills toe aan de operatorgroepen. Telkens kijken we hoeveel de productiviteit van de teams bedraagt Simulatie1: single skilled Ieder team kan 1 call type behandelen. In onderstaande figuur wordt telkens de tijdbesteding van de verschillende groepen afgebeeld. Het geel stelt de idle time voor. Men kan uit de figuur besluiten dat in deze situatie de productiviteit niet echt goed is. De single skilled situatie blijkt dus voor Phone Home niet de beste oplossing te zijn: de productiviteit van de operatoren is veel te laag. De gemiddelde wachttijd van een klant is ook groot. Dit kan u zien in de grafieken op het einde van deze sectie. 88

102 Hoofdstuk 5 : Case studies 1 SKILL 100% 90% 80% 70% 60% 50% 40% 30% 20% Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 10% 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figuur 34: Productiviteit van de groepen bij 1 SKILL Simulatie 2: 2 SKILLS Iedere groep kan nu 2 verschillende call types beantwoorden. Team 1 kan bijvoorbeeld zowel call type 1 als 2 verwerken De idle time blijkt al heel wat kleiner dan bij de vorige situatie. 2 SKILLS 100% 90% 80% 70% 60% 50% 40% 30% 20% Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 10% 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figuur 35: Productiviteit van de groepen bij 2 SKILLS Simulatie 3,4,5 In deze 3 simulaties kunnen de groepen achtereenvolgens 3, 4 en 8 verschillende call types verwerken. Men kan duidelijk zien dat de invloed van het aantal skill levels waarover de teams beschikken niet meer zo duidelijk is. Het blijkt niet zo veel uit te halen of de teams nu 4 of 8 verschillende call types kunnen aannemen. 89

103 Hoofdstuk 5 : Case studies 3 SKILLS 100% 90% 80% 70% 60% 50% 40% 30% 20% Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 10% 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figuur 36: Productiviteit van de groepen bij 3 SKILLS. 4 SKILLS 100% 90% 80% 70% 60% 50% 40% 30% 20% Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 10% 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figuur 37: Productiviteit van de groepen bij 4 SKILLS. 8 SKILLS 100% 80% 60% 40% 20% Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figuur 38: Productiviteit van de groepen bij 8 SKILLS. 90

104 Hoofdstuk 5 : Case studies Simulatie 6: 10 SKILLS In deze situatie kunnen de groepen alle binnenkomende call types aannemen. Qua Idle time is er niet veel verschil te merken met de situatie waarbij de operatoren 3, 4 of 8 skills hebben. 10 SKILLS 100% 80% 60% 40% 20% Idle type10 type9 type8 type7 type6 type5 type4 type3 type2 type1 0% groep1 groep2 groep3 groep4 groep5 groep6 groep7 groep8 groep9 groep10 Figuur 39: Productiviteit van de groepen bij 10 SKILLS Gemiddelde wachttijden Voor ieder call type vergelijken we de gemiddelde wachttijden bij de verschillende simulaties. Opvallend is dat men ongeveer dezelfde wachttijd bekomt wanneer de teams over 3 à 4 skills beschikken als in het geval van volledige flexibiliteit (10 skills). Gemiddelde wachttijd type1 Gemiddelde wachttijd type sec sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS 0 1 SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS Gemiddelde wachttijd type3 Gemiddelde wachttijd type sec sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS 0 1 SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS 91

105 Hoofdstuk 5 : Case studies Gemiddelde wachttijd type5 Gemiddelde wachttijd type6 sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS Gemiddelde wachttijd type7 Gemiddelde wachttijd type8 sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS Gemiddelde wachttijd type9 Gemiddelde wachttijd type sec 15 sec SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS 0 1 SKILL 2 SKILLS 3 SKILLS 4 SKILLS 8 SKILLS 10 SKILLS Figuur 40: Vergelijking van de wachttijden Besluit Indien de operatoren alle oproepen zouden kunnen beantwoorden (totale flexibiliteit), dan zou de productiviteit het hoogst en de gemiddelde wachttijd het kleinst zijn. Opmerkelijk is het feit dat men hetzelfde resultaat ongeveer bereikt als de operatoren slechts enkele call types kunnen verwerken i.p.v. alle types. Met andere woorden, gegeven het feit dat totale flexibiliteit veel geld kost, lijkt het onwaarschijnlijk dat totale flexibiliteit de beste oplossing is vanuit economisch perspectief. In plaats dat Phone Home de operatoren een dure opleiding aanbiedt waardoor de operatoren alle call types kunnen behandelen, zou ze best een beperkte opleiding voorzien. Als de operatoren in staat zijn om 4 call types te verwerken dan bekomt Phone Home quasi dezelfde resultaten als bij totale flexibiliteit. 92

106 Hoofdstuk 5 : Case studies 5.2 Algemene case studie Gegevens Een fictief bedrijf bestaat uit drie aparte diensten: een dienst voor verkoop aan andere bedrijven (BTB) een dienst voor verkoop aan consumenten (BTC) een dienst om s te beantwoorden Elke dienst heeft drie verschillende soorten oproepen/ s, namelijk: informatie aanvraag een bestelling een herstelling Hieronder ziet u de verdere gegevens van het contact center: openingsuren: o maandag -vrijdag : 8u 19u o zaterdag: 9u 17u o zondag: gesloten kentallen: BTB BTB BTB BTC BTC BTC info bestelling herstelling info bestelling herstelling info bestelling herstelling service level (%) / / / service level tijd (s) / / / abandonment (s) / / / bedieningstijd (s) Tabel 5: Kentallen van de verschillende types oproepen/ s. 93

107 Hoofdstuk 5 : Case studies Om een forecast te maken zijn volgende gegevens gekend: # bellers per uur in # bellers per uur in piekuren in de week piekuren op zaterdag piekuren daluren BTB info 10u-12u; 15u-17u geen BTB bestelling 10u-12u; 15u-17u geen BTB herstelling 10u-12u; 15u-17u geen BTC info BTC bestelling BTC herstelling 8u-9u; 12u30-14u; 18u-19u geen u-9u; 12u30-14u; 18u-19u geen u-9u; 12u30-14u; 18u-19u geen info geen geen bestelling geen geen herstelling geen geen Tabel 6: Forecast gegevens Met bovenstaande gegevens kan men in Excel een forecast maken; zie figuur hieronder: 94

108 Hoofdstuk 5 : Case studies forecast BTB info (voor één week) aantal calls per interval (30 min) ma 8u ma 10u Huidige situatie ma 12u ma 14u ma 16u ma 18u din 9u din 11u din 13u din 15u din 17u woe 8u woe 10u woe 12u woe 14u woe 16u woe 18u dag+uur Figuur 41: Forecast voor BTB info (1 week). Met behulp van bovenstaande gegevens kunnen we het Excel formulier invullen. dond 9u dond 11u dond 13u dond 15u dond 17u vrij 8u vrij 10u vrij 12u vrij 14u vrij 16u vrij 18u zat 10u zat 12u zat 14u zat 16u De openingsuren zijn gekend en we simuleren over een periode van zes dagen (van maandag tot zaterdag). In de huidige situatie zijn er negen call types, waarvan drie s en er wordt in zeven groepen gewerkt: BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling s De bedieningstijden per call type zijn gekend, net zoals de service levels en de abandonment tijden. Elk call type krijgt de hoogste prioriteit (dit is 50). Eens alles ingevuld is in Excel, wordt het benodigd aantal operatoren automatisch weergegeven. Nu kan men twee situaties onderscheiden: Ofwel wordt er gesimuleerd met het aantal operatoren dat men vindt via Erlang. 95

109 Hoofdstuk 5 : Case studies Ofwel wordt dit aantal benodigde operatoren gebruikt om een shift optimalisatie (die de personeelskosten minimaliseert) uit te voeren. Daardoor wordt een nieuw aantal operatoren gevonden, met bijpassende uurroosters, dat groter of gelijk is aan het benodigd aantal operatoren. Met dit aantal kan dan ook een simulatie uitgevoerd worden Optimalisatie van de shifts Eerst moeten alle mogelijke shifts gevonden worden voor de twee uurschema s, waarbij uurschema 1 geldt van maandag tot vrijdag en uurschema 2 geldt op zaterdag. Daar we de forecast per half uur genomen hebben, moeten we hier als intervaltijd dertig minuten kiezen. Omdat de solver in Excel beperkt is tot 200 variabelen, moet er voor gezorgd worden dat we niet meer dan 200 shifts per uurschema creëren. Hieronder ziet u de gegevens voor uurschema 1: Figuur 42: Gegevens voor Uurschema 1. 96

110 Hoofdstuk 5 : Case studies Dit schema levert 148 verschillende shifts op. Voor uurschema 2 doen we hetzelfde en vinden daarvoor 75 verschillende uurschema s. Vervolgens moeten we nog per interval de kost aangeven van een gewone operator en van een flexibele operator. Hier hebben we aangenomen dat een gewone operator tussen de 5 en de 8 uur werkt per dag en een flexibele operator 4 uur per dag werkt. De kost vindt u hieronder. Kost per interval voor Kost per interval voor gewone werknemer (euro) flexibele werknemer (euro) 8 11 Figuur 43: Kostprijs van de werknemers. Om te vermijden dat na optimalisatie er enkel flexibele werknemers zouden werken, leggen we de kost van een flexibele werkkracht iets hoger. Nu laten we de optimalisatie automatisch runnen. De oplosser moet in totaal 42 optimalisaties uitvoeren (voor 7 groepen 6 werkdagen optimaliseren). Hieronder ziet u een grafiek die het benodigd aantal operatoren weergeeft en het gevonden aantal operatoren door optimalisatie. Zoals u kan zien liggen beide curves dicht bij elkaar. Hoe goed is optimalisatie aantal operatoren 8 6 benodigd aantal operatoren gevonden aantal operatoren interval Figuur 44: Vergelijking van het aantal operatoren via Erlang en via optimalisatie. 97

111 Hoofdstuk 5 : Case studies Resultaten Nu alle gegevens gekend zijn, worden ze geëxporteerd naar ED. We maken 2 simulaties: één keer zonder shift optimalisatie en een keer met optimalisatie. Hieronder ziet u de gevonden resultaten: gemiddeld aantal operatoren per interval (30 min) zonder shift optimalisatie met shift optimalisatie operator BTB info operator BTB bestelling operator BTB herstelling operator BTC info operator BTC bestelling operator BTC herstelling Tabel 7: Vergelijking resultaten met of zonder optimalisatie. Daar er door de optimalisatie meer operatoren zullen worden toegekend is het logisch dat er met optimalisatie: meer idle time zal zijn, de service levels hoger zullen liggen, de gemiddelde wachttijd lager is. service levels (%) % BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling info bestelling herstelling Figuur 45: Behaalde service levels te behalen service level zonder optimalisatie met optimalisatie 98

112 Hoofdstuk 5 : Case studies procentuele idle time van de operatoren operator BTB info operator BTB bestelling operator BTB herstelling operator BTC info type zonder shift optimalisatie operator BTC bestelling met shift optimalisatie operator BTC herstelling Figuur 46: Procentuele idle time van de operatoren Verbeteringsvoorstellen We stellen achtereenvolgens enkele verbetervoorstellen voor en vergelijken telkens de resultaten met elkaar. Op het einde bespreken we de uurroosters voor het beste scenario Verbetervoorstel 1: BTB samenvoegen met BTC We voegen de afdelingen BTB en BTC samen. Dit brengt geen meerkost met zich mee daar er geen nieuwe vaardigheden aangeleerd moeten worden. We maken een onderscheid tussen twee mogelijkheden. 1. BTB en BTC hebben dezelfde prioriteit. 2. BTB heeft een hogere prioriteit dan BTC en zal dus voorrang krijgen. We vergelijken bovenstaande scenario s met de oude situatie. We werken met het aantal operatoren gevonden uit de optimalisatie Aantal operatoren Het aantal operatoren is gedaald ten opzichte van de oude situatie met een goeie 15% per interval. 99

113 Hoofdstuk 5 : Case studies gemiddeld aantal operatoren per interval (30 min) oude situatie verbetering 1 operator info % operator bestelling % operator herstelling % Tabel 8 Gemiddeld aantal operatoren per interval Bezettingsgraad De operator is meer actief met het beantwoorden van gesprekken of s, dit zien we aan de idle time die met 23% gedaald is. % tijdbesteding van alle operatoren samen oude situatie verbetering 1 Idle % BTB info % BTB bestelling % BTB herstelling % BTC info % BTC bestelling % BTC herstelling % info % bestelling % herstelling % Tabel 9: Bezettingsgraad operatoren na verbetering Service levels In de oude situatie wordt het service level voor BTB bestelling en herstelling niet gehaald. Met verbetervoorstel 1, waarbij BTB voorrang krijgt op BTC, wordt dit vooropgesteld service level wel bereikt. Indien BTB en BTC gelijke prioriteiten krijgen, ligt het service level van BTB herstelling te laag. 100

114 Hoofdstuk 5 : Case studies 120 verbetering 1: service level (%) vooropgesteld service level oude situatie verbetering 1 (BTB hogere prioriteit) verbetering 1 (zelfde prioriteiten) 20 0 BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 47: Service level na verbetering Gemiddelde wachttijd Bij verbetering 1 is de gemiddelde wachttijd gedaald voor alle BTB oproepen; voor de BTC oproepen is deze gestegen. verbetering 1: gemiddelde wachttijd (sec) oude situatie verbetering 1 (BTB hogere prioriteit) verbetering 1 (zelfde prioriteit) BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 48: Gemiddelde wachttijd na verbetering

115 Hoofdstuk 5 : Case studies Als we echter alle wachttijden van alle klanten optellen en deze delen door het aantal klanten, vinden we de gemiddelde wachttijd over alle oproepen. Hierbij scoort de verbeterde situatie opnieuw beter. gemiddelde wachttijd over alle oproepen (seconden) oude situatie 22 verbetering 1 (BTB hogere prioriteit) 11,1 verbetering 1 (gelijke prioriteiten) 13, 6 Tabel 10: Gemiddelde wachttijd over alle oproepen Besluit Verbetering 1 geeft de beste resultaten als we BTB een hogere prioriteit geven dan BTC. In de sectie hieronder wordt met verbetering 1 dan ook verwezen naar deze waarbij BTB voorrang heeft Verbetering 2 Daar de operatoren voor info en herstelling dezelfde opleiding genoten hebben, kunnen zij beide oproepen beantwoorden. Deze 2 groepen zullen nu 1 groep vormen. Opnieuw kan er gespeeld worden met prioriteiten. We onderzoeken 3 gevallen: prioriteiten BTB info BTB herstelling BTC info BTC herstelling situatie situatie situatie Tabel 11: Mogelijke gevallen In situatie 1 heeft BTB voorrang op BTC en hebben info en herstelling dezelfde prioriteit. In situatie 2 heeft BTB opnieuw voorrang op BTC maar krijgt een oproep van het type info 102

116 Hoofdstuk 5 : Case studies voorrang op een oproep van het type herstelling. In situatie 3 tenslotte heeft BTB info de hoogste prioriteit, gevolgd door BTB herstelling en BTC info (die dezelfde prioriteit hebben), op zijn beurt gevolgd door BTC herstelling die de laagste prioriteit heeft. Hieronder ziet u opnieuw de resultaten Aantal operatoren Omdat info en herstelling nu door één groep beantwoord worden, vermindert de variantie van de aankomsten en zijn er minder operatoren nodig om eenzelfde service level te bereiken. gemiddeld aantal operatoren per interval (30 min) verbetering 1 verbetering 2 operator info + herstelling % operator bestelling % operator % Tabel 12: Vergelijking van gemiddeld #operatoren per interval bij verbetering 1 en Bezettingsgraad De idle time is opnieuw verminderd en gaat van 21% naar 17,5%. % tijdsbesteding van alle operatoren samen % verbetering 1 verbetering 2 situatie1 verbetering 2 situatie2 verbetering 2 situatie Idle BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling info bestelling herstelling Figuur 49: Tijdsbesteding van de operatoren na verbetering

117 Hoofdstuk 5 : Case studies Service levels De service levels van de oproepen in verband met herstellingen zijn duidelijk gestegen. De andere blijven nagenoeg gelijk. Hierbij scoort verbetering 2 situatie 3 toch het best. verbetering 2: service levels (%) % verbetering 1 verbetering 2 situatie1 verbetering 2 situatie2 verbetering 2 situatie BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 50: Service level na verbetering Gemiddelde wachttijd De gemiddelde wachttijd is voor de meeste call types gedaald t.o.v. de eerste verbetering. Enkel bij BTC info en BTB info nemen we een kleine stijging waar. verbetering 2: gemiddelde wachttijd (sec) sec verbetering 1 verbetering 2 situatie1 verbetering 2 situatie2 verbetering 2 situatie3 5-5 BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 51: Gemiddelde wachttijd na verbetering

118 Hoofdstuk 5 : Case studies Aantal behandelde oproepen Het aantal behandelde oproepen binnen de 30 seconden is globaal gezien over alle call types constant. Hier en daar zien we wel een kleine fluctuatie. aantal oproepen behandeld binnen 30 sec aantal behandeld verbetering 1 verbetering 2 situatie1 verbetering 2 situatie2 verbetering 2 situatie BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 52: Aantal behandelde oproepen binnen de 30 seconden na verbetering Abandonments We merken een serieuze afname op van het aantal abandonments bij BTC herstelling. aantal mensen die ingehaakt hebben verbetering verbetering 2 situatie1 verbetering 2 situatie2 verbetering 2 situatie BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 53: Aantal abandonments na verbetering

119 Hoofdstuk 5 : Case studies Verbetering 3 In verbetering 3 passen we call blending toe. De operatoren zullen zowel oproepen als s beantwoorden waarbij de oproepen uiteraard voorrang krijgen op de s. Er zijn nog 2 teams. Groep 1 behandelt de oproepen en s betreffende info en herstelling en groep 2 de oproepen en s betreffende bestellingen. De simulatie tool is wel zodanig gebouwd dat, indien een operator bezig is met een hij/zij deze eerst afwerkt vooraleer een call kan beantwoord worden. Hieronder ziet u de resultaten Aantal operatoren Het aantal operatoren per interval ligt een heel klein beetje hoger dan in de vorige situatie. gemiddeld aantal operatoren per interval (30 min) verbetering 2 verbetering 3 som voor alle oproepen Tabel 13: Vergelijking van gemiddeld # operatoren per interval bij verbetering 2 en Bezettingsgraad De idle time daalt met 2%. De operatoren zijn m.a.w. productiever. % tijdsbesteding van alle operatoren samen % verbetering 2 verbetering Idle BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling info bestelling herstelling Figuur 54: Tijdsbesteding na verbetering

120 Hoofdstuk 5 : Case studies Service levels Bijna alle service levels stijgen. Enkel bij BTC bestelling daalt het een klein beetje. verbetering 3: service levels (%) verbetering 2 verbetering BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 55: Service level na verbetering Gemiddelde wachttijd Bij BTB info en BTB bestelling zien we een lichte stijging in de gemiddelde wachttijd met nog geen seconde. Alle andere wachttijden worden kleiner. gemiddelde wachttijd sec 8 6 verbetering 2 verbetering BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 56:Gemiddelde wachttijd na verbetering

121 Hoofdstuk 5 : Case studies Aantal behandelde oproepen Het aantal behandelde oproepen binnen de 30 seconden is ongeveer gelijk aan het aantal bij verbetering 2. aantal oproepen behandeld binnen target time aantal behandeld verbetering 2 verbetering BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 57: Aantal behandelde oproepen binnen de 30 seconde na verbetering Abandonments Er zijn nagenoeg geen mensen meer die inhaken. Aantal mensen die inhaken 25 verbetering 2 verbetering BTB info BTB bestelling BTB herstelling BTC info BTC bestelling BTC herstelling Figuur 58: Aantal abandonments na verbetering

122 Hoofdstuk 5 : Case studies Besluit Met call blending vermindert het aantal operatoren niet, maar alle andere prestatiekenmerken verbeteren wel Uurrooster optimalisatie Stel dat het bedrijf kiest voor verbetering 3 en dat het vraagt om het aantal benodigde operatoren te berekenen en te bepalen welke verschillende shifts ze moeten invoeren. Ook zouden ze graag weten hoeveel telefoonlijnen ze best ter beschikking zouden hebben om alle oproepen te kunnen beantwoorden Shifts van groep 1 voor een weekdag shift aantal operatoren die van maandag tot vrijdag deze % % shift hebben som 474 Tabel 14: Shifts van groep 1 voor een weekdag. 109

123 Hoofdstuk 5 : Case studies Voor groep één hebben we aan de hand van de optimalisatie van maandag tot vrijdag alle voorkomende shifts gegroepeerd die het best overeenkomen. We zijn zo tot bovenstaande tabel gekomen. Daarin ziet u per shift in de 2 de kolom het aantal operatoren die deze shift hebben in de loop van de week, in kolom 3 ziet u dit uitgedrukt in %. In kolom 4 tenslotte, kan u zien hoeveel procent van de tijd een bepaald shift type gebruikt wordt. De shifts, gegroepeerd met een bepaalde kleur, zijn gelijkaardig. Zo zijn er 5 groepen terug te vinden: shift van type 1: o start om 11u o eindigt om 18u30 of 19u o middagpauze begint tussen 13u en 14u shift van type 2: o start om 13u o eindigt om of 19u o pauze om 15u of 16u shift van type 3: o bestaat hoofdzakelijk uit shift 46 o start om 8u o eindigt om 14u o middagpauze om 11u o (de andere shifts van dit type eindigen later 14u30, 15u, 15.30, 16.30) shifts type 4: o dit zijn de flexibele operatoren o de ene helft werkt van 8u tot 12u o de andere helft van 15u tot 19u shifts type 5: o start om 10u o eindigt om 18u30 of 19u o middagpauze om 12u of 12u30 Per weekdag (maandag tot vrijdag) zijn er gemiddeld 95 (474 / 5) operatoren nodig van groep 1. Daarvan zullen er 22 een shift hebben van het type 1, 15 van het type 2, 30 van het type 3, 1 van het type 4 en 27 van het type

124 Hoofdstuk 5 : Case studies Shifts van groep 2 voor een weekdag Voor groep 2 doen we identiek hetzelfde als hierboven. shift aantal operatoren die van maandag tot vrijdag deze shift hebben % % som Tabel 15: Shifts van groep 2 voor een weekdag. Dit maal kunnen we 5 verschillende types shifts onderscheiden: shift type 1: o start om 10u o eindigt om 19u o middagpauze tussen 12u en 13u shift type 2: o start om 11u o eindigt om 19u o middagpauze om 13u30 of 14u 111

125 Hoofdstuk 5 : Case studies shift type 3: o start om 13u o half uur pauze om 15u of 16u o eindigt om18u30 of 19u shift type 4: o opnieuw vooral shift 46 o start om 8u o middagpauze tussen 11u en 12u o eindigt vooral tussen 14u en 15u shift type 5: o dit zijn de flexibele operatoren o de ene helft werkt van 8u tot 12u o de andere helft van 15u tot 19u Per weekdag (maandag tot vrijdag) zijn er gemiddeld 59 (293 / 5) operatoren nodig van groep 2. Hiervan zijn er 3 van type 1, 11 van type 2, 4 van type 3, 23 van type 4 en 18 van type Shifts van groep 1 en 2 voor de zaterdag De drie verschillende types shifts voor het weekend, zowel voor groep 1 als 2 zijn: shift type 1: o start om 9u o eindigt om 17u o middagpauze tussen 11u30 en 13u30 shift type 2: o start om 9u o eindigt om 15u of 15u30 o middagpauze om 11u30 of 12u shift type 3: o start om 11u o eindigt om 17u o middagpauze tussen 13u en 14u30 112

126 Hoofdstuk 5 : Case studies In het weekend bedraagt het aantal operatoren van groep 1 ongeveer 58 en van groep 2 ongeveer 38. aantal operatoren van aantal operatoren van shift groep 1 die groep 2 die % % deze shift deze shift % % hebben de zaterdag hebben de zaterdag som 58 som 38 Tabel 16:Shifts van groep 1 en 2 voor de zaterdag Aantal benodigde telefoonlijnen Uit de simulatie kunnen we rechtstreeks de bezettingsgraad aflezen van alle telefoonlijnen. Het maximaal aantal lijnen dat gebruikt wordt bedraagt 76 lijnen. Daaruit kunnen we besluiten dat 80 telefoonlijnen meer dan genoeg zou zijn. 113

127 Bijlages 114

128 Bijlage 1: Installatie simulatietool 115

129 Bijlage 1: Installatie simulatietool Stap1: Eerst moet de Add-in geïnstalleerd worden in Excel. Deze kan u terugvinden in de map erlang97.zip. Stap2:Installeer Enterprise Dynamics 5 onder de C-schijf: Program Files 7. Stap3: Plak de map CC Screening Tool 8 onder Enterprise Dynamics in de C-schijf (Program Files). Stap4: Maak de ODBC-verbinding aan: o Open via het Control Panel Administrative Tools de "Data Sources (ODBC)" ("systeembeheer" als je een Nederlandse versie hebt). o Ga naar de pagina "System DSN". o Klik op "Add", selecteer "Microsoft Excel Driver", en druk op "Finish". o Dan moet je de ODBC-link specifiëren: in het bovenste veldje "Data Source Name", vul in: CC-Screening (exact zo overnemen); dit is de "alias name" van de ODBC-link. o Klik op "Select Workbook", en browse naar de gepaste Excel file: als alles goed gaat, is dat: " \Enterprise Dynamics\CC Screening Tool\input\CC- Input.xls". Selecteer die, en druk op "OK". o Druk op "OK" tot je het scherm van het gegevensbeheer weer verlaat; de ODBC-link is aangemaakt. Stap5: De 3 Excel files 9 bevinden zich op de volgende plaats: o INPUT: C:\Program Files\Enterprise Dynamics\CC Screening Tool\input\CC- Input o OUTPUT: C:\Program Files\Enterprise Dynamics\CC Screening Tool\output o OPTIMALISATIE: C:\Program Files\Enterprise Dynamics\CC Screening Tool\output Stap6: Nu kan je de applicatie draaien: open ED. Normaalgezien vraagt ED naar een applicatie. Indien dit niet zo is: zie stap 7. Selecteer "CC Screening Tool", en open deze applicatie. 7 U dient eerst een licentie aan te vragen om ED te installeren. 8 Deze programma s bevinden zich in de bijgevoegde CD. 9 Input noemt hier CC-input en Optimalisatie noemt scheduling. 116

130 Bijlage 1: Installatie simulatietool Nu zal de CC Screening Tool aangemaakt worden (met aangepaste atomen, menu's, ). Als ED open is, vind je in het menu de opties "Import model" en "Export results". Gebruik de eerste optie om een model te importeren via Excel (de Excel file Input hoeft niet open te staan). Als je het model laat draaien voor een tijdje, kan je het model stoppen, en op "Export results" klikken. De resultaten worden dan weggeschreven naar Excel (Output file). Stap7: Het kan zijn dat ED zich automatisch opent, zonder dat je de kans krijgt om een applicatie file te kiezen. Sluit dan ED weer af, en doe daarna het volgende: o Open de file " \Enterprise Dynamics\ED.app" (open het als een textbestand). o In die file zie je de volgende code staan: {set(t,getfileopen(pdir([apps\*.app]),[e.d. Applications (*.app) *.app])),} t := pdir([apps\logistic suite.app]), o De accolades rond dit eerste stuk code dienen verwijderd te worden, en rond het volgende lijntje code gezet te worden: set(t,getfileopen(pdir([apps\*.app]),[e.d. Applications (*.app) *.app])), {t := pdir([apps\logistic suite.app]),} o Save de textfile, en sluit ze weer. o Nu kan je ED openen, en zal je de keuze krijgen tussen verschillende applicaties. Selecteer de applicatie "CC Screening Tool", en open ze. 117