GEFASEERDE INVOERING UNIFIED COMMUNICATIONS

G E FA S E E R D E I N V O E R I N G U N I F I E D C O M M U N I C AT I O N S versie 1.0, 15 april 2010

SURFNET BV, RADBOUDKWARTIER 273, POSTBUS 19035, 3501 DA UTRECHT T +31 302 305 305, F +31 302 305 329, WWW.SURFNET.NL

Gefaseerde invoering Unified Communications, versie1.0, 15 april 2010

INHOUD

1.

2.

3.

4.

5.

Inleiding ........................................................................................ 3 1.1

Wat is UC? ............................................................................... 3

1.2

Werkwijze ................................................................................ 4

Visie bepalen .................................................................................. 5 2.1

Inleiding ................................................................................. 5

2.2

Wat levert UC de instelling op? ....................................................... 5

2.3

Voor wie wil de instelling UC implementeren? ...................................... 6

2.4

Welke elementen van UC zijn voor de instelling interessant? ..................... 7

2.5

Wat is het budget? ..................................................................... 7

Architectuur vaststellen ...................................................................... 8 3.1

Inleiding ................................................................................. 8

3.2

Landelijke architectuur ................................................................. 8

3.3

Instellingsarchitectuur ................................................................. 9

3.4

Uitwerking architectuur .............................................................. 12

Implementatiestrategie bepalen ........................................................... 14 4.1

Inleiding ............................................................................... 14

4.2

Onderdelen implementatiestrategie ................................................ 14

Individuele projecten ....................................................................... 17 5.1

Inleiding ............................................................................... 17

5.2

Projectmanagement .................................................................. 18

5.3

Gebruikerswensen .................................................................... 20

5.4

Globaal ontwerp ...................................................................... 20

5.5

Selectie van oplossing................................................................ 21

5.6

Detailontwerp en installatie ......................................................... 22

5.7

Valideren en testen ................................................................... 22

5.8

Awareness en training ............................................................... 23

5.9

Go-live en onderhoud ................................................................ 23

5.10 Status en vervolgacties .............................................................. 24

2


1.

INLEIDING

1.1

Wat is UC?

Unified Communications (UC) heeft de toekomst als het gaat om communicatie tussen medewerkers en studenten binnen instellingen en tussen instellingen. Gebruikers kunnen met elkaar in contact treden via welk medium en via welk apparaat ze willen. In het kort staat UC namelijk voor: de integratie van realtime communicatiemiddelen (zoals messaging, telefonie en videoconferencing) en niet realtime communicatie middelen (zoals voicemail, e-mail en SMS). Unified Communications zorgt ervoor dat de gebruikers al deze communicatiemiddelen via één interface met elkaar kunnen combineren. Een aantal voorbeelden van UC-toepassingen: 

1 on 1 VoIP audiocalls



Presence



Presence-integratie met agenda, te weten



1 on 1 videocalls



Multiparty audiocalls over IP



Presence met autorisatielevels



Onderling bestanden versturen



Chef/secretaresseschakeling



Multiparty chat



One number, Integratie vast/mobiel/softclient, in het netwerk



Videoconferencing met reeds gebruikte systemen



Whiteboard delen



Multiparty videocalls over IP



Applicaties delen



IM&P met Skype



Follow-me adhv agenda



IM&P op PDA/mobiel



Trusted IM&P met andere community's



Geografische presence (wel/niet on campus, wel niet op werkplek)



Web presence: is online op deze pagina

3


1.2

Werkwijze

Omdat UC vooral zijn waarde bewijst bij gebruik tussen instellingen, is het van belang dat alle instellingen UC implementeren op basis van dezelfde set architectuurprincipes. Uit die principes komt voor elke functionaliteit van UC (bijvoorbeeld conferencing, unified messaging) een referentie-architectuur voort. Deze wordt beschikbaar gesteld door SURFnet, via de UC-portal www.ucho.nl. In dit document vindt u een globale werkwijze voor het invoeren van UC in uw instelling. Deze bestaat uit de volgende stappen: 1. Visie op UC ontwikkelen en randvoorwaarden scheppen. 2. Architectuur vaststellen op basis van referentie-architectuur. 3. Implementatiestrategie bepalen. 4. Individuele projecten opzetten. Deze stappen worden in dit handboek verder uitgewerkt.

 Gedeelde Visie  Directie Akkoord

UC Visie

• Wat is UC? • Wat brengt UC ons? • Voor wie is het bedoeld? • Welke elementen zijn belangrijk? • Wanneer en voor hoeveel?

 Blauwdruk  Werkende POC

UC Architectuur

• AS-IS Inf rastrucuur • Gebruikers wensen • Architectuur principes • Ref erentie Architectuur (TO-BE) • POC Centrale Oplossing

 Akkoord Geld  Akkoord Mensen  Akkoord Middelen

UC Implementatie Strategie • Implementatie Strategie • Samenwerkings verband

UC Individuele Projecten

• Project Plannen • Pilot individuele projecten • Gebruikerswensen gedetailleerd • • • • •

Globaal Ontwerp Selectie (RFQ, evaluatie, POC) Detail Ontwerp& Installatie Awareness & Training Go-Live

4


2.

VISIE BEPALEN

2.1

Inleiding

Om UC in uw instelling op een goede, doordachte manier te implementeren, is het belangrijk binnen de instelling een visie op UC te vast te stellen. Een visiestatement zorgt er bijvoorbeeld voor dat u randvoorwaarden kunt vaststellen waarmee bij de implementatie rekening moet worden gehouden. Een fictief voorbeeld van een visiestatement: “Strakke en efficiënte communicatie is voor ons bedrijf van levensbelang voor de toekomst. Wij zien dat ook onze werknemers steeds meer zelf bepalen via welke weg ze met elkaar en onze klanten communiceren (telefoon, e-mail, chat, internetcommunity's). Voor het bedrijf is het essentieel, dat onze medewerkers maximaal worden ondersteund bij hoe zij met elkaar en derden willen communiceren. Daartoe willen we in de komende 2 jaar zorgen dat de medewerkers zowel via e-mail, telefoon, pc, een eventuele smartphone, via chat, via een social network of discussieforum op het intranet, via video en/of audioconferencing kunnen communiceren. Er is 2 miljoen euro beschikbaar gesteld om bovenstaande te realiseren.” De volgende vragen kunnen behulpzaam zijn bij het opstellen van een visiestatement: 

Wat levert UC de instelling op?



Voor wie wil de instelling UC implementeren?



Welke elementen van UC zijn voor de instelling interessant?



Wat is het budget?

Deze vragen worden in de paragrafen hieronder uitgewerkt.

2.2

Wat levert UC de instelling op?

Business case Het gaat bij deze vraag om de business case op het hoogste niveau. In een business case wordt onderbouwd hoe UC een bijdrage aan levert aan de bestaande situatie. Hij verantwoordt investeringen door meetbare doelstellingen te formuleren, die volgens een Return On Investment (ROI) berekening in de tijd kunnen worden geplaatst. Hiermee wordt duidelijk in welke periode de investeringen in UC kunnen worden terugverdiend. De business case voor UC is op hoofdlijnen gericht op: 

verlagen van kosten



efficiëntere en effectievere samenwerking



verhogen van productiviteit

5


'Harde' doelstellingen Deze doelstellingen zijn goed meetbaar. Dit geldt voor de doelstelling kosten te verlagen. Drie voorbeelden hiervan zijn: 

Verminderen van reiskosten door een deel van het reisbudget te investeren in UC (bijvoorbeeld videoconferencing). Het reisbudget wordt lager en het alternatief is videoconferencing. Dit bevordert het gebruik en de investering wordt vanzelf terugverdiend. Daarna levert het winst op, omdat er geen nieuwe investeringen nodig zijn maar het reisbudget wel lager blijft.



Telefoneren over IP, waardoor geen telefoontikken meer hoeven worden betaald.



Beheren van single-platforms, wat leidt tot lagere beheerkosten (telefonie en AD) in plaats van meerdere (PBX, AD).

'Zachte' doelstellingen Deze doelstellingen zijn lastig te meten. Efficiëntere en effectievere samenwerking en verhogen van de productiviteit zijn daar voorbeelden van. Benchmarkcijfers laten productiviteitsstijgingen tot 5% zien, maar er is altijd een groot aantal aannames en manieren van berekenen. Verder zijn dergelijke cijfers situatieafhankelijk. Andere moeilijk meetbare doelstellingen: 

Het gebruik van UC maakt het werk sneller, omdat je sneller mensen bij elkaar kunt brengen en vervolgens sneller besluiten kunnen nemen (in plaats van e-mails die in overvolle e-mailboxen blijven hangen).



De kwaliteit van het werk gaat omhoog, omdat de juiste mensen snel gevonden en aangeschakeld kunnen worden.



De instelling is een aantrekkelijke werkgever, omdat er aantoonbaar gebruik wordt gemaakt van vernieuwende middelen.



‘UC is groen’, een doelstelling gericht op imago.

2.3

Voor wie wil de instelling UC implementeren?

Voor het bepalen van de scope moet de instelling een helder idee vormen voor welke doelgroepen UC zal worden geïmplementeerd. Er moet worden nagedacht over: 

het aantal gebruikers dat wordt voorzien. De oplossingen moeten worden geschaald en schaalbaar zijn voor eventuele groei.



het type gebruiker. Er valt te denken aan studenten, docenten, stafmedewerkers, managers, bestuursleden, buitenlandse onderwijsinstellingen, leveranciers, kennisinstituten, enzovoort. Er kunnen verschillen bestaan in de geboden functionaliteit per gebruikersgroep. Dit heeft weer consequenties voor de te kiezen techniek, training, communicatie en implementatie.

6


2.4

Welke elementen van UC zijn voor de instelling interessant?

Het is belangrijk om te identificeren welke UC-elementen moeten worden geïmplementeerd. Gaat het om specifieke toepassingen, zoals het beschikbaar maken van nieuwe functionaliteit voor de medewerker of student of gaat het om het gehele aanbod van UC, waarbij alle media worden geïntegreerd en aan elkaar gekoppeld? Hoe belangrijk is de rol van telefonie? Welke huidige systemen willen we koppelen aan UC? Een totaalbeeld van wat UC moet kunnen heeft grote impact op de keuze die gemaakt gaat worden voor het product en de implementatie.

2.5

Wat is het budget?

Een high-level budget wordt vastgesteld in de business case, waarbij een grove inschatting wordt gedaan wat de kosten zullen zijn, uitgesplitst over een bepaalde periode. De verdere detaillering van het budget wordt gemaakt tijdens de projectdefinitie.

7


3.

ARCHITECTUUR VASTSTELLEN

3.1

Inleiding

Om grootschalig gebruik van Unified Communications mogelijk te maken, zijn er twee niveaus waarop we een architectuur voorstellen: 

landelijke infrastructuur; wat moet er gebeuren om UC mogelijk te maken tussen instellingen?



instellingsarchitectuur; wat moet er binnen de instelling ingericht worden om UC mogelijk te maken?

De architecturen die we schetsen zijn TO-BE-architecturen: ze moeten een richting aangeven voor de projectmanagers die Unified Communications binnen het hoger onderwijs implementeren.

3.2

Landelijke architectuur

SURFnet heeft in samenwerking met de instellingen gekeken naar verschillende modellen en op basis daarvan een landelijke UC-architectuur opgesteld. Deze is noodzakelijk om te zorgen dat alle 170 aangesloten instellingen probleemloos met elkaar kunnen communiceren via UC.

Fig. 1

Landelijke federatieve architectuur voor Unified Communications

De architectuur wordt organisch opgezet. Dat betekent dat er geen overkoepelende organisatie is via welke alle communicatie moet verlopen: eindgebruikers communiceren direct met elkaar, via decentrale servers. Het voordeel hiervan is dat instellingen UC kunnen gaan implementeren zonder dat de federatieve component van de landelijke infrastructuur al (helemaal) gereed is. De enige voorwaarde is dat de instellingen

8


gebruikmaken van dezelfde standaarden voor unified communications (XMPP, SIP en H.323) en de standaarden op een soortgelijke wijze binnen de instelling inrichten. In de volgende paragraaf zal nader ingegaan worden op de vraag hoe deze standaarden het beste binnen de instelling geïmplementeerd kunnen worden.

3.3

Instellingsarchitectuur

Als we inzoomen op de architectuur binnen de instellingen, dan zien we feitelijk drie standaarden voor realtime communicatie die gezamenlijk alle functionaliteiten voor realtime communicatie afdekken: SIP, H.323 en XMPP.

Fig. 2

Standaarden voor realtime UC

Figuur 2 geeft de standaarden voor realtime communicatie weer als venn-diagrammen. De standaarden bieden namelijk een gedeelte van elkaars functionaliteiten, maar hebben elk een eigen specialiteit (ook in de figuur weergegeven). Alle standaarden beweren overigens alle functionaliteiten af te dekken, of die ambitie te hebben, maar doen dat niet. Figuur 2 laat ook de koppelvlakken zien die de realtime standaarden hebben met de bestaande functionaliteiten zoals storage, e-mail, telefonie en Identity Management (IdM). Om te komen tot een goede keuze welke standaarden ondersteund moeten worden, moet de ICT-architect van een instelling zich de volgende vragen stellen: 

Welke standaarden moet ik binnen mijn instelling ondersteunen?



Als ik meerdere standaarden ondersteun, hoe moeten deze dan met elkaar geïntegreerd worden?



Hoe richt ik de koppelvlakken in tussen niet-realtime en realtime functionaliteiten?

9


Welke standaarden moet ik binnen mijn instelling ondersteunen? Het is niet waarschijnlijk dat binnen uw instelling alle genoemde standaarden (XMPP, SIP, H.323) even belangrijk zijn. Het is raadzaam om bij de implementatie van UC te beginnen vanuit een van de standaarden. Het voordeel hiervan is dat de implementatie goed beheersbaar is. Verder blijkt dat de ontwikkelingen binnen de genoemde callsignalling-protocollen heel snel gaan. De protocollen bieden nu al voor een deel functionaliteiten waar andere standaarden in gespecialiseerd zijn. Bijvoorbeeld: XMPP ondersteunt ook het gebruik van video en audio (denk aan messaging clients als Skype). In de toekomst zal deze overlap alleen maar groter worden. Dat betekent dat met één UC-functionaliteit als uitgangspunt al een vrij breed UC-aanbod kan worden gegenereerd. Welke standaard (XMPP, SIP, H.323) u als uitgangspunt neemt, kan afhangen van een aantal factoren:

G e b r u i k e r s w en s e n Om de gewenste oplossing te kunnen opstellen, moet er een globaal beeld zijn van wat eindgebruikers, zoals studenten en medewerkers, willen en welke UC-functionaliteit(en) deze wensen kan/kunnen vervullen. Deze wensen kunnen in dit stadium beknopt worden beschreven in scenario’s / use cases die de belangrijkste wensen weergeven. Op basis daarvan kunt u besluiten de meest gewenste UC-functionaliteit als eerste te gaan implementeren. Een aantal voorbeelden van use cases zijn: 

chatvragenuur voor studenten



projectsamenwerking tussen studenten



college geven vanuit een ander werelddeel



college volgen in een andere vestiging



deelnemen aan overleg vanuit thuis/verspreid



IM met melding verschuiven college, cijfers zijn bekend



projectinformatie delen met ‘peers’ van andere instellingen of het bedrijfsleven



stagevoortgangsgesprekken via videoconferencing



online onderzoeksdata vergaren, analyseren en bespreken



beschikbaarheid en locatie van dienstdoend staflid (bijv. verpleging) bepalen t.b.v. oproep



beschikbaarheid van agents bepalen in callcenter



ontruiming BHV: waarschuwing via meerdere kanalen; en: is iedereen het gebouw uit?

U i t g ang s s i t u a t i e De bestaande situatie in uw instelling kan een duidelijke richting geven in de keuze voor de eerste UC-functionaliteit die u wilt implementeren. Enkele voorbeeldsituaties:

10




De telefooncentrale in uw instelling gaat binnenkort worden vervangen. In dat geval kan het voor de hand liggen om eerst de audiofunctionaliteit te gaan implementeren, door de nieuwe centrale op het SIP-protocol te baseren.



Uw instelling biedt al videoconferencing aan via H.323. Dan kan de videofunctionaliteit het uitgangspunt zijn vanwaaruit u bijvoorbeeld uitbreidt naar de IM&P-functionaliteit. Er wordt dan presence-informatie bekend over de gebruikers, zodat het van tevoren strak vastleggen van een videoconferencingrooster niet meer nodig is.



Uw instelling gaat Gmail aanbieden, met daarbij het gebruik van Google Talk. De nadruk daarbij ligt op instant messaging, waardoor het logisch is om de UCfunctionaliteit IM&P als eerste te implementeren.

Hoe worden de verschillende standaarden met elkaar geïntegreerd? Als u meerdere standaarden wilt implementeren in uw instelling, moeten deze met elkaar geïntegreerd worden. Dit kan op verschillende manieren: 

Via gateways, dat wil zeggen plug-ins die translatie tussen verschillende protocollen kunnen uitvoeren. Deze gateways kunnen bij de instelling worden geïnstalleerd, of de gatewaydiensten kunnen bij SURFnet worden afgenomen (centrale gateways)



Via de client: clients ondersteunen meerdere standaarden (SIP, H.323) voor realtime communicatie. Nadeel is dat de gebruiker meerdere keren accountgegeven moet invullen per standaard.

Hoe richt ik de koppelvlakken in tussen niet-realtime en realtime UCfunctionaliteiten? Voor de niet-realtime functionaliteiten (telefonie, e-mail, identity management en storage) moeten koppelvlakken ingericht worden om ze aan te sluiten op de UCfunctionaliteiten. Deze integratie kan in verschillende gradaties plaatsvinden, afhankelijk van de gebruikswensen: voor een secretariaat kan het wenselijk zijn telefonie sterk te integreren in UC, voor studenten is het wellicht belangrijker dat e-mail sterk verweven is met UC. Hieronder worden een aantal 'uitersten' weergegeven voor de integratie van niet-realtime functionaliteiten in UC. Een lage integratiegraad betekent dat nietrealtimefunctionaliteiten hun eigen interface behouden; een hoge integratiegraad houdt in dat deze functionaliteiten in de interface van UC zijn geïntegreerd.

Telefonie 

lage integratiegraad: de telefoniefunctionaliteit blijft los staan van de UCfunctionaliteiten.



hoge integratiegraad: er kunnen scenario's toegepast worden waarin bijvoorbeeld een telefoontje doorgezet wordt naar een voicemail die naar de e-mail van de ontvanger wordt gestuurd.

E-mail 

lage integratiegraad: er blijft een eigen interface bestaan voor e-mail, die geen functionele koppeling kent met UC.

11




hoge integratiegraad: als een gebruiker een e-mail krijgt, kan hij bijvoorbeeld meteen zien of de afzender online is, en kan hij indien gewenst vanuit deze interface de afzender bellen op zijn mobiele nummer.

I d e n t it y m a n a g e men t 

lage integratiegraad: er is een aparte accountdatabase voor UC en voor niet-realtime functionaliteiten.



hoge integratiegraad: er is één accountdatabase, zodat bijvoorbeeld voor nieuwe medewerkers naast e-mail ook meteen de presence status beschikbaar is; ook presence-informatie in e-mail wordt zo mogelijk gemaakt.

Storage 

lage integratiegraad: bijvoorbeeld chatsessies worden niet centraal maar lokaal op de computer van de gebruiker opgeslagen.



hoge integratiegraad: de data van alle functionaliteiten worden centraal opgeslagen, zodat makkelijk gezocht kan worden in zowel e-mailconversaties als chatsessies, en eventueel ook audio en video.

3.4

Uitwerking architectuur

Met een keuze voor een standaard, of misschien zelfs wel twee standaarden is de eerste stap gezet naar het inrichten van een UC-oplossing binnen de instelling. Het is echter nog te vroeg om al over te gaan op een pakketselectie of productontwikkeling. Er zijn namelijk een aantal technische randvoorwaarden en principes die een rol spelen bij de implementatie van UC binnen een instelling.

12


Fig. 3 Architectuur voor realtime communicatie

In figuur 3 is schematisch weergegeven welke onderdelen een rol spelen bij het inrichten van een realtime UC-omgeving met koppelvlakken naar e-mail, telefonie, storage en Identity management. Voor elke standaard (XMPP, SIP, H.323) moeten de onderdelen die gegroepeerd zijn onder de kopjes Netwerken & infrastructuur, Security en Standaarden & protocollen verder uitgewerkt worden. De uitwerking per standaard zal door SURFnet uitgevoerd worden. Op dit moment is alleen het document voor XMPP helemaal uitgewerkt. Het document kan gedownload worden via onderstaande link: http://www.surfnet.nl/Documents/SN%20UC%20%20Federatieve%20architectuur%20voor%20UC%201.0.pdf

13


4.

IMPLEMENTATIESTRATEGIE BEPALEN

4.1

Inleiding

Een implementatiestrategie is belangrijk om de invoering van UC goed en gestructureerd te laten verlopen. Daarnaast gaat het bij de implementatiestrategie over de aanpak. Welke eindgebruikers worden betrokken bij het voortraject? Welke fasering wordt gekozen? Wat wordt de projectstructuur? Zijn er gezamenlijke activiteiten tussen de instellingen? Hoe worden keuzes gemaakt voor de techniek? Hoe worden gebruikers getraind? Van groot belang is dat de standaarden zoals genoemd in hoofdstuk 3, toegepast worden. Zo wordt voorkomen dat er problemen ontstaan bij het aansluiten op andere instellingen. het is dus zeer aan te bevelen om de architectuur zoals beschreven, te volgen.

4.2

Onderdelen implementatiestrategie

In dit hoofdstuk wordt behandeld wat belangrijk is bij het bepalen van een implementatiestrategie. In het kort: 

Principe leaders/followers



Top down/bottom up



Roadshows



Eindgebruikers betrekken



Pilots



UC-champion

Principe leaders/followers Het is goed om de bij de implementatie te starten bij een afdeling of faculteit die bereid is een voortrekkersrol te vervullen. Dat zou bijvoorbeeld de ICT-afdeling kunnen zijn, of een faculteit waar men al enthousiast is over het inzetten van UC. Deze situatie is goed te gebruiken voor overige followers om alvast ‘geleerde lessen’ te trekken en methodes voor invoering te leren kennen. Vice versa kan men leren van fouten voor de vervolgstappen. Doordat er al initiatieven zijn ontplooid wordt het gemakkelijker voor andere afdelingen en faculteiten om aan te haken.

Top-down / bottom-up Een volgende belangrijke keuze is de top-down of bottom-up aanpak. De top-down benadering betekent hier een ‘volledige’ projectaanpak, waarbij alle relevante belanghebbenden (bijvoorbeeld CvB-leden, eindgebruikers, IT-afdeling, managers) worden betrokken en vervolgens de oplossing wordt uitgekozen door een comité van bovengenoemde belanghebbenden. In de bottom-up aanpak wordt de oplossing geselecteerd door de IT-afdeling, die de regie voert over de implementatie. Na uitrol zijn de enthousiastelingen of ‘early adopters’ de

14


eerste gebruikers. Men rekent op een olievlekwerking, waarbij het aantal gebruikers toeneemt door mond-tot-mondreclame en verdere stimulering door enthousiastelingen. SURFnet adviseert te kiezen voor de top-down aanpak om te voorkomen dat de gebruikers de oplossing niet accepteren, omdat er geen onderzoek is gedaan naar de wensen en eisen van deze gebruiker. ‘Het luister naar je klant’ principe is belangrijk bij UC, mede omdat de mogelijkheden eindeloos zijn.

Roadshows In veel grote veranderprojecten worden de veranderingen aangekondigd en toegelicht middels ‘Roadshows’. Dit is een soort vooraankondiging met presentaties en eventueel een demonstratie aan de toekomstige gebruikers van hetgeen gaat worden geïmplementeerd. Enkele afgevaardigden van de project teams bezoeken de afdelingen of instellingen om de aankondigingen te doen. Vaak wordt er ook al gepresenteerd hoe het project er in hoofdlijnen uitziet, wat men wil bereiken en grove tijdslijnen. Het is dus zaak dat de visie is gevormd en afgestemd.

Eindgebruikers betrekken De eindgebruikers worden vaak niet voldoende of te laat bij een implementatie betrokken. Het risico dat men loopt is dat er niet de juiste UC-functies worden geïmplementeerd. Men kan kiezen om de eindgebruikers vanaf het begin van het project (zelfs bij de visievorming) te betrekken. In het project betekent dit veel werk maar zal het uiteindelijke succes. De voornaamste reden is, dat de mogelijkheden van UC nog onbekend zijn bij de eindgebruikers. Het is aan te bevelen de gebruikers vanaf het begin bekend te maken met UC, zodat tijdens het proces de juiste keuzes kunnen worden gemaakt voor functionaliteit. Dit zorgt voor een hoge mate van gebruikersadoptie. Een andere mogelijkheid is om de keuzes voor gewoon een UC oplossing te kiezen, te installeren en vervolgens de gebruikers laten ontdekken wat er beschikbaar is gesteld. Dit is een goede mogelijkheid, als er enthousiastelingen zijn die mond-tot-mondreclame maken. Het risico is dat het bij de enthousiastelingen blijft en dat het gros van de gebruikers de nieuwe tools niet adopteert. De olievlekwerking is dan niet gerealiseerd.

Pilots Door pilots te starten voor communicatie tussen instellingen of voor nieuwe functionaliteit, kunnen de eerste kinderziektes worden opgelost, worden gebruikers in een vroeg stadium bekend gemaakt met de functies en is bijsturing nog relatief eenvoudig. Bovendien worden de eerste ‘user experiences’ al opgedaan, zodat men een reëel beeld kan krijgen bij wat men kan verwachten. Het werken met pilots is in deze situatie ten zeerste aan te bevelen.

UC-champion Voor het implementeren van nieuwe tools als UC, is het raadzaam iemand aan te wijzen, die op overkoepelend niveau als ‘UC-champion’ fungeert. Deze persoon helpt de instellingen op weg bij problemen, kent de oplossingen in de markt op zijn duimpje, heeft interfaces met leveranciers en heeft ervaring met grootschalige implementaties. De toegevoegde waarde van de UC-champion, is dat hij de expertise op UC-gebied heeft die weinigen op dit moment hebben, zodat hij van grote waarde kan zijn voor advies en hulp voor de instellingen.

15


De UC Champion kan zijn rol invullen vanuit een instelling, waarin hij als lokale kennisbaak wordt ingezet of op centraal niveau, waarbij hij ten behoeve van alle instellingen zijn kennis kan inbrengen. Het laatste is aan te bevelen, vanwege maximale uitnutting van kennis voor ten bate van alle instellingen.

16


5.

INDIVIDUELE PROJECTEN

5.1

Inleiding

Instellingen kunnen na het vaststellen van hun visie en doelstellingen de individuele UCprojecten uit gaan voeren, uitgaande van de landelijke UC referentie-architectuur. Instellingen die al begonnen met dergelijke trajecten, kunnen de projectstructuur gebruiken om hun UC-oplossing verder vorm te geven. De hier gepresenteerde methode bestaat uit een aantal criteria voor project management en een standaardproces om inhoudelijk tot een UC-implementatie te komen. De methode bestaat uit de volgende stappen:  Acceptatie Functionaliteit  Acceptatie Beheer

 Akkoord Project Start

Regulier Onderhoud

Project Management

Project Definitie - Project Planning & Organisatie - Communicatie - Project Controle

Analyse Gebruikers Wensen • Opstellen Use Cases • Mappen UC features • Prioriteren UC Features

Globaal Ontwerp • Beheers Aspecten • Technische Vereisten • Integratie

Selectie Oplossing • Opstellen RFQ • Evalueren Antwoorden • POC & Selectie Partner(s)

Detail Ontwerp • Software Configuraties • Hardware Configuraties • Interfaces

Installatie & Test • • • • •

Configureren Programmeren Aansluiten Testen Accepteren

Awareness & Training

Communicatie - Demonstratie - Training functioneel & technisch

De toegevoegde waarde voor instellingen van een dergelijk gezamenlijke project aanpak is vooral het delen van kennis en van elkaar leren, waardoor UC implementaties makkelijker en beter kunnen verlopen. Zo kunnen instellingen bijvoorbeeld hun status en voortgang eenduidig communiceren: hoewel bezig met verschillende implementaties in verschillende fases, is de gevolgde methode hetzelfde. Het is aan de onderwijsinstellingen te kiezen voor een passende Project management methode, bijvoorbeeld PRINCE2, of een interne methode. Wij beperken ons in dit document tot de minimale elementen waarvan wij denken dat ze aanwezig moeten zijn om samen effectief projecten te kunnen managen en de status hiervan te kunnen delen (project definitie, project plan, communicatie plan, status rapportage). De hier gepresenteerde methodiek bevat de volgende proces stappen, die in het vervol van dit hoofdstuk nader worden toegelicht: 

Projectmanagement (enkele minimale richtlijnen)



Gebruikerswensen: gedetailleerd (funct. techn. presenteren, workshops, use cases)

17




Globaal ontwerp



Selectie van oplossing (RFQ, evaluatie, POC; afhankelijk v.d. instelling)



Detailontwerp & installatie



Awareness, training en uitrol

5.2 Projectmanagement Om tot goede samenwerking tussen instellingen te komen zijn een aantal elementen van project management essentieel: Projectdefinitie, projectplanning, en organisatieprojectcontrole. Een dilemma is altijd waar voorbereiding ophoudt en een officieel project begint: in dit document gaan we er vanuit dat het project begint met een zeer globaal idee dat vervolgens uitgewerkt moet worden, waarvoor een rechtvaardiging moet worden opgesteld, en een planning voor moet worden gemaakt. Wie

Project Eigenaar & Project Manager

Output

Project Definitie (bijv. als Project Charter) Project Plan (incl. communicatie en risico's) Gevalideerde Business Case Status Rapportage

Projectdefinitie Een goed project begint met een heldere definitie van het project zelf: het doel, de scope, business case en voorzien resultaten. De analyse activiteiten die hieronder vallen zijn helder krijgen gebruikers wensen, identificeren UC functies en detailleren van de Business Case (in volgende secties toegelicht) Een taak van de project eigenaar/manager is dit kernachtig te formuleren als middel voor besluitvorming. Dit blijkt in de praktijk lastiger dan gedacht en in het bijzonder voor UC trajecten. Wij bevelen hierom het gebruik van een project charter aan, die de opsteller dwingt het project samen te vatten op één A4 en is bedoeld om besluitvorming te faciliteren: 

Doelen: wat willen we met het project bereiken, niet te verwarren met de doelen vastgesteld in de visie. Bijvoorbeeld inrichten “het inrichten van 2 videoconferencing ruimtes om hoge kwaliteit videoconferencing te bieden aan vakgroepen en zuster instellingen”



Scope: wat valt binnen het project en wat valt er buiten. Hoewel in theorie niet nodig kan het laatste verhelderend werken. Bijvoorbeeld “ruimte op locatie A en B en volledige apparatuur. Conference booking interface met email en calendar valt buiten het project”



Kosten en baten: hoewel vaak lastig, is het wenselijk baten te kwantificeren waar mogelijk. Kosten voorbeeld: infrastructuur aanpassingen, nieuwe apparatuur, kosten implementatie. Baten voorbeeld reiskosten vermindering en kwaliteitsverbetering van werk

18




Middelen: een inschatting van de bemensing van het project en eventueel de fysieke middelen die hiervoor moeten worden gereserveerd/aangeschaft



Impact / hoofdactiviteiten: de belangrijkste te nemen stappen voor het project. Hier hoeft niet de hele methode te worden herhaald, slechts stappen die aandacht verdienen. Bijvoorbeeld extra aandacht change management gebruikers en POC



Risico’s: het noemen van risico’s helpt vooral bij het later vormgeven van de project controles, kernpunten die in de gaten gehouden moeten worden. Bijvoorbeeld onvoldoende adoptie van de oplossing, onvoldoende aandacht voor goede integratie



Stakeholders: wie hebben baat bij het project, en wie is de eigenaar van het project? Bijvoorbeeld: studenten, onderzoekers, onderwijsmedewerkers, administratieve staf en management.

De Business case Al naar gelang de behoefte van de instelling kunnen zij ervoor kiezen de Business Case voor de duidelijkheid gescheiden op te stellen. Hierin zullen de bovenstaande elementen terugkomen, nu expliciet kijkend naar harde en zachte factoren, zoals reeds vermeld in het Visie hoofdstuk: 

Harde factoren: specifieke factoren die van belang zijn voor de instellingen, zoals bijvoorbeeld reduceren reistijd, reduceren onderhoudskosten telefonie, etc.



Zachte factoren: specifieke factoren die van belang zijn voor de instellingen, zoals betere communicatie met specifieke studenten groepen, op afstand werken voor specifieke medewerkers, mobility-support voor frequent reizende managers etc.

Projectplanning & -organisatie Bij projectplanning wordt vaak eerst gedacht aan traditionele tijdsplanning van activiteiten en medewerkers verstaan (bijv. Gantt charts in mpp). Voor effectieve samenwerking tussen onderwijsinstellingen het plannen van communicatiemomenten en het plannen van maatregelen voor de grootset risico’s echter evenzeer belangrijk: 

Communicatieplan: wie ontvangt welke informatie wanneer en hoe? Het betrekken van de gebruikers wordt geborgd middels dit plan. Dit kan verschillen per communicatiemoment en doelgroep



Statusrapportage: met statusrapportage wordt de reguliere rapportage naar hoger management bedoeld, bijvoorbeeld met stoplichtrapportage over issues, open acties, voortgang en budget. De frequentie en vorm kunnen worden opgenomen in het communicatieplan.



Risicomanagement: hoe gaan we de belangrijkste risico’s ondervangen? De maatregelen kunnen vervolgens worden opgenomen als standaard projectcontroles.

Een heldere projectorganisatie bestaat uit een organisatiechart, rollen en verantwoordelijkheden. Zeker binnen dit soort trajecten met meerdere spelers (SURFnet, instelling, afdelingen en leveranciers) is dit geen overbodige exercitie. Vooral het betrekken van zowel IT als gebruikers is hierin belangrijk: hoewel iedereen beaamt gebruikerswensen mee te zullen nemen, blijken UC-trajecten in de praktijk sterk IT-gedreven. Door expliciet vertegenwoordigers van gebruikersafdelingen /

19


groepen rollen en verantwoordelijkheden te geven, kan dit in grote mate worden voorkomen. Bijkomend voordeel is vroege betrokkenheid van gebruikers en vlottere acceptatie.

5.3 Gebruikerswensen Per instelling moeten worden gekeken wat de specifieke wensen en eisen van haar gebruikers zijn. Het is aan te bevelen om de gebruikerswensen als volgt te verwerken: 

Opstellen use cases: gebruikerswensen kunnen in kaart worden gebracht door identificeren van typische UC-gebruikersscenario’s. De gebruikers moeten de hele organisatie vertegenwoordigen, dit kunnen dus de belangrijkste stakeholders zijn zoals geïdentificeerd tijdens project definitie. Een voorbeeld van een use case is ‘chatvragenuur voor studenten”



Mappen naar UC-functionaliteiten: de use cases zullen in de praktijk raken aan vele UC-functionaliteiten. Bij deze mapping is UC-expertise vereist. Typische UCfunctionaliteiten zijn presence, desktop conferencing, één telefoonnummer voor vast/mobile/softphone etc.



Prioriteren van de UC-functionaliteiten: het prioriteren van de UCfunctionaliteiten is de laatste stap, bijvoorbeeld aan de hand van. MoSCoW. Voorkomen moet worden dat alles bij geringste twijfel als ‘Must Have’ wordt geprioriteerd: soms helpt het de bewijslast om te keren, door aan te tonen waarom een lagere prioriteit niet kan.

Workshops zijn de meest efficiënte methode zijn om met meerdere gebruikers te prioriteren. Omdat er veel verschillende soorten gebruikers zijn met verschillende opvattingen over UC, is het raadzaam voldoende tijd te nemen voor het uitleggen van UC en de relevante functionaliteiten. Aan het einde van deze stap zijn de gebruikerswensen helder en geprioriteerd naar UCfunctionaliteiten. De activiteiten in dit blok moeten de volgende concrete resultaten leveren: Wie

Businessanalist, UC-experts (Vertegenwoordigers van) gebruikers: input en besluiten

Output

Uitgewerkte use cases Geprioriteerde UC-functionaliteiten

5.4 Globaal ontwerp Op basis van gebruikerswensen en UC-functionaliteiten kan nu een globaal ontwerp worden gemaakt van hoe de oplossing er uit komt te zien. Dit ontwerp heeft als doel zo helder mogelijk te kunnen communiceren tijdens het selectieproces. In het algemeen geldt: hoe beter dit ontwerp hoe beter het antwoord van de leveranciers. In deze stappen moet een aantal zaken helder worden:

20




Beheer: welke UC-functies doen we zelf, wat besteden we uit? Bijvoorbeeld ASP, SaaS, Cloud Computing, Eigen Beheer



Technische vereisten: zaken zoals vereiste bandbreedte, piekbelasting, redundantie, back-up en recovery



Integratie: kern van de UC oplossing is de integratie, voorbeelden zijn: -

Landelijke UC-architectuur

-

Verscheidene user directories / telefoonboeken binnen de instelling

-

E-mail en agendaclients

-

Telefonie- en videoapplicaties

-

Zakelijke systemen als CRM, Contact centers

-

Instellingsspecifieke applicaties en middleware

Aan het einde van deze stap is alle informatie aanwezig om het selectie traject te starten, de activiteiten in dit blok moeten de volgende concrete resultaten leveren: Wie

Businessanalist, UC-expert Applicatiebeheerders, IT

Output

Globaal ontwerp

5.5 Selectie van oplossing De kern van het selectieproces is: wees zo helder en specifiek mogelijk; UC is een technologie die volop in beweging is en ook tussen de leveranciers zijn verschillende opvattingen over functionaliteit. In de markt zijn grofweg twee soorten UC-oplossingen te vinden: telefonieleveranciers die hun telefonieplatform uitbreiden naar IP (van PBX met IP boards, of herontwerp naar I-PBX) en de softwareleveranciers die hun collaboratorpakketten uitbreiden met telefonie (bijvoorbeeld Microsoft OCS, IBM Sametime). Dit onderscheid kan van belang bij het kiezen van de kandidaten. Van belang is dus zeker te stellen dat beide categorieën zijn vertegenwoordigd in tijdens de selectie (tenzij er een zeer expliciete voorkeur is) De stappen in het selectie proces beginnen bij het opstellen van een RFQ. Hiervoor bestaan talrijke templates, die echter alle de volgende elementen bevatten, een kwestie van kiezen: 

uitleg gebruikerswensen en ontwerp - uit vorige stap



open vraag naar oplossing leverancier



controlevragen op functionaliteit - uit vorige stap



controlevragen op techniek - uit vorige stap



implementatieaanpak

21




kosten en personeel

Na de evaluatie van de respons, kan normaal gesproken worden gestart met POC en uiteindelijke contract onderhandelingen. Aan het einde van deze stap is de leverancier en de voorgestelde oplossing geselecteerd: Wie

Applicatiebeheerders, IT UC-expert: input

Output

RFQ POC en selectie

5.6 Detailontwerp en installatie In deze stap wordt de UC-oplossing in detail ontworpen, tot op niveau van poortnummer, aansluitbussen, versienummers, etc. Doorgaans is de leverancier leidend tijdens dit traject, vanwege de benodigde expertise. Dit detail ontwerp is nodig omdat dit de stap is voor de fysieke installatie van de benodigde software en apparatuur. Wie

Expert Leverancier (rollen: Ontwerper, Architect, Programmeur en/of Tester) IT: voornamelijk input & review, eventueel gedeelde rollen met hierboven UC Expert: voornamelijk input & review

Output

Detailontwerp Geaccepteerde test Geïnstalleerde software

5.7 Valideren en testen Naast het formeel testen op functionaliteit en techniek, leggen wij in deze stap vooral nadruk op coördinatie, interactie met leveranciers en betrekken gebruikers. 

Interactie leveranciers: UC-trajecten zijn gecompliceerd en raken veelal de hele organisatie. Naast de methodische uitvoer van testen, moet valideren en testen hierom vooral als een iteratief proces van nauwe samenwerking met leveranciers worden gezien, waarin instellingen en leveranciers naar elkaar toegroeien. Hierin kunnen instrumenten als prototyping en proefinstallaties worden gebruikt om verassingen aan het einde van de rit zoveel mogelijk te voorkomen. Methodisch komt het er op neer een balans te vinden tussen klassieke ‘waterfall’ ontwerp trajecten en meer iteratieve methodieken, zoals RAD, of DSDM.



Betrekken gebruikers: valideren en testen is bij uitstek een goede stap om gebruikers actief bij het UC-traject te betrekken: waar requirement analyse nogal abstract kan overkomen, wordt UC in deze stap concreet. Vaak worden gebruikers na requirements analyse pas weer betrokken bij de laatste acceptatie test: voor UC-

22


trajecten kunnen gebruikers beter vroeger worden betrokken bij test activiteiten. Hoewel vrij te maken tijd altijd een probleem zal zijn, zullen gebruikers dit soort actieve betrokkenheid doorgaans als zeer positief ervaren.

5.8 Awareness en training Een van de belangrijkste stappen tijdens dit traject is het creëren van awareness. In de praktijk blijkt dat veel UC functies niet gebruikt worden omdat gebruikers niet op de hoogte zijn van het bestaan en/of deze niet willen gebruiken omdat ze de toepassing niet begrijpen en hier dus de toegevoegde waarde ook niet van zien. Een ander veel gezien obstakel is privacy: vooral Presence en bereikbaarheid kunnen worden gezien als een aanval op privacy. Omdat gebruikers niet bewust zijn van mogelijkheden als opt-out, en do-not-disturb functionaliteit zullen zij neigen tot weigering van de geboden UC features. Middelen die ingezet kunnen worden voor het bevorderen van awareness, instellingsbreed naast de analyse trajecten: 

Periodieke Mailing



Demonstraties en Roadshows; intern en aansluitend op eerder genoemde shows



Betrekken gebruikers (communicatieplan)



Duidelijke uitrol momenten - zodat gebruikers ook zien wat er verandert

Aan het einde van deze ‘stap’ zijn de gebruiker geïnformeerd en getraind in de nieuwe UC-functionaliteit. Wie

Projecteigenaar, als ‘drager’ van het project Projectmanager, als uitvoerder communicatieplan IT-manager, UC-experts en leverancier, voor demonstaties en trainingen

Output

Detailontwerp Geaccepteerde test Geïnstalleerde software

5.9 Go-live en onderhoud Na GO-LIVE van een platform, zal er een korte periode van nazorg ingelast moeten worden om directe problemen met de nieuwe UC-oplossing te verhelpen. Vaak wordt deze taak opgenomen door het project, omdat de benodigde expertise daar nog aanwezig is. Een alternatief is de ICT-helpdeskfunctie tijdig gereed te maken voor deze tijdelijke functie. Normaal gesproken zal na een paar weken of maanden de nazorg overgaan in standaard 1 e en 2 e lijn support van de ICT helpdesk van de instelling.

23


5.10 Status en vervolgacties Acties Vervolgacties zouden kunnen zijn: Wie

Wat

Instelling

Bepaal welke lopende projecten er zijn en bepaal welke projecten er als UC-project kunnen worden aangemerkt. Start UC-implementatie volgens methodiek

Instelling

Indien een UC-implementatie reeds in gang gezet is, bepaal welke stappen van de voorgestelde methodiek er eventueel nog worden toegevoegd c.q. of de implementatie alsnog als geheel volgens de methodiek kan worden vormgegeven

24

GEFASEERDE INVOERING UNIFIED COMMUNICATIONS

Recommend Documents