Conceptnota bij OMB - EBP



Conceptnota

IT Service Management tool

Leveren en implementeren van een IT Service Management tool ter ondersteuning van de IT dienstverlening van Digipolis en haar klanten

Inhoudsopgave

1 Doelstelling conceptnota 3

1.1 De opdracht 3

1.2 Digipolis 3

2 Opdrachtgevend bestuur, wijze van gunning, motivering, procedure 3

2.1 Opdrachtgevend bestuur 3

2.2 Wijze van gunnen 4

2.3 Motivatie van de procedure 4

2.4 Procedure die zal gevolgd worden 4

3 Omschrijving van de opdracht 5

3.1 Deelnemers 5

3.2 Beschrijving van de opdracht 5

3.3 Duurtijd van de opdracht 6

4 Achtergrondinformatie 6

4.1 Huidige situatie 6

5 Concept en uit te werken oplossing 9

6 Algemene vereisten 10

7 Functionele vereisten 11

8 Technische vereisten 13

9 SLA / Onderhoudscontract 13

10 Implementatie plan 14

Doelstelling conceptnota

Via deze conceptnota wil Digipolis aan de kandidaten voldoende informatie over de opdracht meegeven zodat zij kunnen inschatten of zij zich voor deze opdracht wensen in te schrijven en meer concreet of zij zich in de eerste fase van deze opdracht willen kandidaat stellen.[1]

Deze conceptnota is louter indicatief en kan het opdrachtgevend bestuur niet verbinden. Het uiteindelijke bestek dat aan de geselecteerde kandidaten zal bezorgd worden zal de definitieve bepalingen omtrent deze opdracht bevatten. Tevens bevat deze conceptnota in bijlage een invulformulier ‘verklaring op erewoord’ dat de kandidaat dient te gebruiken bij de kandidaatstelling.

1 De opdracht

Het voorwerp van de opdracht betreft de aanneming van diensten m.b.t. het aangaan van een raamcontract voor de aankoop en implementatie van een IT Service Management tool ter ondersteuning van de IT dienstverlening van Digipolis en haar klanten.

Het gaat om het implementeren (met inbegrip van analyse, opzet en configuratie) en onderhoud van de toepassingssoftware voor het beheren van alle processen in de servicedesk van Digipolis Antwerpen. Bij de keuze van het pakket zal ook rekening worden gehouden met de uitbreidingsmogelijkheden om op later tijdstip ook de servicedesk van Digipolis Gent uit te rusten met deze IT Service Management tool.

De opdracht zal verder gespecificeerd worden in het bestek dat naar de geselecteerde kandidaten gestuurd wordt.

2 Digipolis

De Steden en OCMW's van Antwerpen en Gent werken voor wat betreft hun telematicabehoeften sinds 1 oktober 2003 samen in de opdrachthoudende vereniging Digipolis.

Digipolis levert diensten op het gebied van informatie- en communicatietechnologie. Dit houdt niet enkel hard- en software in, maar ook geïntegreerde totaaloplossingen in verschillende vakgebieden, waarmee de basistaken zo veel mogelijk geautomatiseerd worden.

Digipolis verleent deze diensten aan de Stad Antwerpen en Gent, de lokale politie en het OCMW van de steden Antwerpen en Gent.

Opdrachtgevend bestuur, wijze van gunning, motivering, procedure

1 Opdrachtgevend bestuur

Digipolis (opdrachthoudende vereniging)

Generaal Armstrongweg 1

2020 Antwerpen

Tel. (03) 216 76 11 Fax. (03) 216 79 00

Leidend ambtenaar voor dit bestek:

|Marie-Ange Léonard |Marie-Ange.Leonard@digipolis.be |

| |Tel: +32 (0)3 216 77 71 |

2 Wijze van gunnen

De opdracht is een opdracht voor diensten in de klassieke sector waarvoor de onderhandelingsprocedure met bekendmaking wordt gehanteerd ten behoeve van het opdrachtgevend bestuur Digipolis.

3 Motivatie van de procedure

• De aanbestedende dienst opteert voor het toewijzen van een opdracht van diensten voor de onderhandelingsprocedure met bekendmaking krachtens art. 17, §3,4° van de wet van 24 december 1993

• De aanbestedende overheid is immers van mening dat de gunning van onderhavige opdracht niet mogelijk is door aanbesteding noch door offerteaanvraag omdat de technische specificaties van de opdracht op voorhand niet met voldoende nauwkeurigheid kunnen worden bepaald.

o De technische complexiteit van de opdracht en de functionaliteiten die de aanbestedende overheid vraagt, moeten getoetst worden aan de bereidheid van de potentiële aanbieders om tot een gekozen oplossing te kunnen komen die zo goed als mogelijk moet aansluiten bij de noden van de verschillende gebruikers.

o In het licht van het voorgaande is het belangrijk dat in overleg tot concrete afspraken kan gekomen worden zodat de kostprijs van de ontwikkeling van bepaalde functionaliteiten kan afgewogen worden met het bekomen resultaat. Hierbij is het belangrijk dat de aanbestedende overheid en de aanbieder gezamenlijk vraag en aanbod op elkaar kunnen afstemmen.

o Voor de opzet van de nieuwe applicatie en de onderliggende infrastructuur verwacht Digipolis concrete voorstellen van de inschrijvers. Het is belangrijk om te weten te komen welke mogelijkheden de aanbieders bieden om de nodige diepgang en structuur van het project te garanderen.

o De aanbestedende overheid wil zekerheid over de aangeboden oplossing(en) en vraagt daarom een uitgebreide demonstratie. Via verschillende scenario’s wil men deze demo evalueren en nagaan of de oplossing van de aanbieder voldoet aan de vooropgestelde functionaliteiten in het lastenboek.

o De aanbestedende overheid wil bij de potentiële aanbieders nagaan in welke mate de gevraagde koppelingen voorzien kunnen worden. Inhoud, opzet en taakverdeling zijn voorwerp van de onderhandelingen.

o De aanbestedende overheid wil bij de potentiële aanbieders nagaan in welke mate de gevraagde rapportage voorzien kan worden.

4 Procedure die zal gevolgd worden

• Er is een eerste (openbare) zittingsdag voorzien op 16 oktober 2008 voor de opening van de kandidaatstellingen.

• Na de evaluatie van de inschrijvingen krijgen de weerhouden kandidaten het bestek op 28 november 2008 toegestuurd.

• Voor de opening van de offertes is er een tweede (beperkte) zittingsdag voorzien op 8 januari 2009.

• Na de evaluatie van de offertes volgt er een onderhandelingsfase in één of meerdere onderhandelingsrondes. Tijdens deze onderhandelingsperiode wordt er aan de kandidaten gevraagd om een demo te organiseren. Deze demo’s zijn voorzien in de maanden januari en februari van 2009.

• Na de evaluatie van de onderhandelingen wordt er een gunningsverslag opgesteld tegen eind maart 2009.

De aanbestedende overheid behoudt zich het recht voor om, in het licht van de concrete noden van het onderhandelingsproces, het verloop van deze onderhandelingen te wijzigen.

Omschrijving van de opdracht

1 Deelnemers

De opdracht heeft betrekking op de servicedesk van Digipolis Antwerpen. Deze servicedesk ondersteunt de volledige ICT omgeving van haar klanten.

Mogelijk treedt de servicedesk van Digipolis Gent toe in een latere fase. Het afgesloten contract dient uitbreidbaar te zijn onder dezelfde voorwaarden (aankoop extra licenties).

2 Beschrijving van de opdracht

Volgende onderwerpen maken deel uit van de opdracht:

• De aankoop en gebruiksklaar implementeren van een IT Service Management tool, met een Nederlandstalige gebruikers interface, voor de servicedesk van Digipolis Antwerpen samen met het onderhoud ervan, bijkomende ondersteuning en helpdeskdiensten.

• Een raamcontract (op basis van een dienstencatalogus) dat items bevat, gerelateerd aan een IT Service Management tool

• Opleiding voor de verschillende niveau's van gebruikers

De tool dient ITIL gebaseerd te zijn, i.e. alle gangbare ITIL processen die van toepassing zijn binnen een professionele servicedesk dienen door de tool ondersteund te kunnen worden (ITIL gebaseerd IT Service Management).

De opdracht omvat tevens het gebruiksklaar koppelen en integreren met volgende pakketten binnen Digipolis: Altiris, PeopleSoft, Active Directory, Exchange en Navision. Daarnaast moeten koppelingen mogelijk zijn met andere toepassingen.

De op te leveren toepassing moet minimaal dezelfde functionaliteiten bevatten als de huidige toepassing. Ook het ondersteunen van decentrale servicedesks en het voorzien van één (of meerdere) klant- en leverancierportalen moet mogelijk zijn.

Daarnaast moet de toepassing performant en stabiel zijn, rekening houdende met de technische standaarden die door Digipolis voorgeschreven worden. De geselecteerde kandidaten krijgen inzage in deze technische standaarden als voorbereiding op het maken van hun offerte.

Er wordt ook een opleiding van de gebruikers tot het gebruik van het systeem verwacht en de toepassing dient voldoende gedocumenteerd te worden. De op te leveren opleiding en documentatie wordt in het bestek verder in detail beschreven.

3 Duurtijd van de opdracht

De contracttermijn bedraagt 8 jaar met jaarlijkse opzegbaarheid gedurende de laatste 3 jaar (5j + 1j +1j +1j).

De uitvoeringstermijn voor de opdracht is gefaseerd. De uitvoering van fase 1 (de basisopzet van de nieuwe ITSM tool) moet toelaten de eerste meldingen via de nieuwe tool op 1 september 2009 te kunnen inseinen.

Onder basisopzet worden volgende activiteiten verstaan:

• Installatie, configuratie + testfase

• Opzet en invoer basisgegevens

• Modules incident-, probleem-, wijzigings- en configuratiebeheer

• Implementatie van de specifieke Digipolis processen die in de huidige helpdesktoepassing worden ondersteund zoals onder andere beheerstaken, snelle dienstverlening, klachtenbeheer, werkaanvragen, ad hoc- en ontwikkelingsvragen (zie 4.1 huidige situatie voor meer details)

• Opleiding, training en documentatie

Na een positieve evaluatie kan fase 2 (implementatie van resterende modules) volgen.

Er dient geen conversie te gebeuren van de bestaande helpdesktoepassing.

Digipolis hecht bijzonder veel belang aan een snelle en correcte uitvoering van deze opdracht. De eindverantwoordelijkheid voor de tijdige oplevering ligt bij de dienstverlener.

Achtergrondinformatie

1 Huidige situatie

Algemene werking

Tivoli Service Desk (TSD) is de toepassing binnen Digipolis Antwerpen en haar klanten voor het centraal registreren en verwerken van probleem- , vraag- en klachtmeldingen ten behoeve van diverse functionele meldpunten.

Omgeving Antwerpen:

• Aantal potentiële contacten: 10.000+

• Aantal gebruikers: 500+

• Aantal incidenten (exclusief serviceverzoeken): 60.000+ per jaar

• Decentrale ondersteuningsorganisatie

Functionele opbouw

Qua architectuur is TSD op te delen in drie gebieden: communicatie met de gebruikers (via loketten en 32-bit client), de toepassing met al haar functionaliteiten en de koppeling aan externe systemen. Dit wordt in onderstaande figuur schematisch voorgesteld:

[pic]

Loketten

Een ticket wordt aangemaakt bij de helpdesk (klant telefoneert of stuurt een mail) of door de klant rechtstreeks (via een van de loketten). Sommige klanten hebben een lokale helpdesk die de ticketten aanmaken en wanneer zij ze zelf niet kunnen oplossen wordt het ticket doorgezet naar de Digipolis helpdesk. Wanneer de Digipolis Helpdesk een ticket niet kan oplossen wordt het doorgezet naar een interne oplosgroep (2de of 3de lijn) of naar een externe leverancier.

De werking van deze loketten loopt sterk gelijk. Het verschil zit hem in de Registratiecategorie en eventuele automatische toewijzing aan een bepaalde groep.

TSD Meldingsbeheer

Een melding kan gemaakt worden door 3 categorieën gebruikers: de decentrale helpdesk van een klant (via de ‘Fat’-client), via een loket (klant rechtstreeks) of via de ‘Fat’ client (Digipolis helpdesk of andere Digipolis TSD user). In functie van het loket krijgt de melding een van onderstaande Registratie categorieën:

• Incident: dit is een gebeurtenis (storing) afwijkend van de (verwachte) standaardwerking van de IT-omgeving. Wanneer er een workaround voor handen is, kan een incident afgesloten worden. Mogelijks moet er een probleem worden aangemeld om de echte oorzaak op te zoeken en te verhelpen.

• Beheer: dit zijn vaste of afgesproken taken voor Infrastructuur- of Toepassingsbeheer.

• Beheer ongepland: dit zijn eerder occasionele ad hoc beheerstaken.

• Ontwikkeling: dit zijn functionele aanvragen (tot ontwikkeling) die binnenkomen gedurende lopende projecten of via de klant. Zij hebben betrekking op bestaande of te ontwikkelen toepassingen. Indien er geen lopend project is dan worden deze meldingen bewaard bij de klantcoördinator waaronder de toepassing valt. Op basis van een rapport kan deze de scope bepalen van een volgend (versiebeheer)project. Dergelijke meldingen worden de facto projectmatig behandeld. Dit houdt in dat zij bij voltooiing van het project worden opgenomen in een wijzigingsaanvraag.

• Klachten: zijn meldingen die door de klanten ingeseind worden via het klachtenportaal. Ze hebben een specifieke registratiecategorie en worden toegewezen aan een specifieke groep, maar worden op dezelfde wijze afgehandeld als reguliere meldingen (acceptatie, categorisatie, prioritisering, escalatie, diagnose, oplossing, en sluiting). Het antwoord aan de klant wordt ingescand en als bijlage aan de melding toegevoegd.

• Snelle dienstverlening: de hoofdbedoeling van snelle dienstverlening is snel te kunnen reageren op vragen van klanten. Het gaat om kleine aankopen en installaties die buiten wijzigingsbeheer uitgevoerd worden en beperkt zijn in tijd, budget en resources. Deze meldingen worden via een loket voor ad hoc diensten ingeseind. Op basis van het karakter van de vraag (omvang, doorlooptijd, kost, ...) wordt deze binnen snelle dienstverlening zelf opgelost of doorverwezen naar ad hoc (zie verder) of een andere groep. Mogelijk heeft de vraag één of meerdere werkaanvragen (zie verder) tot gevolg. Deze worden aan de vraag gelinkt door een verwijzing in de actiehistoriek. Snelle dienstverlening dispatcht ook ticketten ivm verlies/diefstal/beschadiging naar administratie. De link met het inkooporder wordt gemaakt (factuurnr) in de atiehistoriek en de PV’s worden als bijlage toegevoegd.

• Ad hoc: dit zijn ad hoc vragen die omwille van hun karakter (omvang, doorlooptijd, kost, ...) projectmatig worden behandeld. Ad hoc staat in voor alle IT-gerelateerde zaken tijdens verhuisbewegingen, verbouw- en nieuwbouwprojecten, kleine opdrachten en kleinere projecten voor de aankoop van software. Het gaat bijvoorbeeld om bekabelingswerken, het voorzien van netwerkverbindingen en telefoonlijnen, het plaatsen van telefooncentrales, netwerkapparatuur, servers, enz. Mogelijk heeft de melding één of meerdere werkaanvragen (zie verder) tot gevolg. Deze worden aan de melding gelinkt door een verwijzing in de actiehistoriek.

• Probleem: dit is een storing waarvan de achterliggende oorzaak nog niet gekend is. Incidenten kunnen hieraan gekoppeld worden, bij het afsluiten van dit probleem worden de onderliggende incidenten ook afgesloten. Meestal is diepgaand onderzoek nodig om dit op te lossen.

TSD Wijzigingsbeheer

• Wijzigingsaanvraag: drie mogelijke categorieën (kalender, noodprocedure, overmacht).

• Werkaanvraag: dit zijn aanvragen voor ad hoc opdrachten waarvoor geen specifieke goedkeuring vereist is. Ook kunnen zij het gevolg zijn van bvb. een kleine aankoop bij snelle dienstverlening. Indien een werkaanvraag na uitvoering wordt afgesloten, betekent dit niet noodzakelijk dat de bovenliggende ad hoc/kleine dienstverlening vraag moet worden afgesloten.

TSD Assetbeheer

De database wordt gevoed uit Navision (Aankoop). Bij Incidenten wordt de link gelegd met een bepaald asset.

• SLA (Service Level Management): deze module is niet geactiveerd.

• Contractbeheer: wordt niet gebruikt.

TSD Diagnosebeheer

Gezien het in TSD niet mogelijk is om een ‘free text search’ te doen, werd TOM (Tivoli OndervragingsModule) ontwikkeld. Je kunt zoeken op Meldingsniveau (“Problemen”) en Wijzigingsniveau (“Werk- en Wijzigingsaanvragen”).

Koppelingen

Dit is een stuk automatisatie die bepaalde data van en naar de TSD database exporteert en importeert. Dit zijn hoofdzakelijk DTS pakketten welke verwerkt worden in CONTROL-M (scheduling software).

• Peoplesoft (HRM): import van TSD gebruikers (Naam- en Adresgegevens, Organisatie en Locatie [boomstructuur]). Dit is de unieke source van gebruikers.

• Active Directory (Exchange): een csv file wordt via een schedule op de TSD server geplaatst. Hieruit worden de gebruikergegevens aangevuld met NT account en email adres.

• HOERA (Electronische wie is wie): deze bron vult verder de gebruikergegevens aan met de telefoonnummers.

• Navision (Aankoop): import van assets.

• Data Warehouse: de database wordt via een schedulingtool integraal gekopieerd.

Rapportering

Gebeurt op basis van het datawarehouse met behulp van Cognos impromptu: tal van trend- en weekrapporten inzake service support, service delivery, meldingsbeheer, wijzigingsbeheer, tijdsregistratie Tivoli, enz.

Concept en uit te werken oplossing

Alle processen die van toepassing zijn binnen een ITIL gebaseerd IT Service Management zijn potentiële kandidaten om in de tool geïmplementeerd te worden, echter volgende domeinen worden als minimum te ondersteunen gesteld:

• Service Desk

• Incidentbeheer (Incident Management)

• Probleembeheer (Problem Management)

• Wijzigingsbeheer (Change Management)

• Configuratiebeheer (Service Asset & Configuration Management)

• Release & Deployment

• Dienstenniveaubeheer (Service Level Management)

• Dienstencatalogus (Service Catalogue Management)

• Service Knowledge Management System (SKMS)

• Kennisbeheer (Knowledge Management)

• Financieel beheer (Financial Management)

• Implementatie van de specifieke Digipolis processen die in de huidige helpdesktoepassing worden ondersteund zoals onder andere beheerstaken, snelle dienstverlening, klachtenbeheer, werkaanvragen, ad hoc- en ontwikkelingsvragen (zie 4.1 huidige situatie voor meer details)

Voor de minimale behoeften dient er te worden voldaan aan de beschreven functionaliteiten en eisen in het bestek dat na de selectie van de kandidaten aan de geselecteerde kandidaten wordt bezorgd. Het gaat hier om de ITIL basisvereisten in een professionele IT Service Management omgeving en enkele specifieke vragen die gesteld worden om de huidige werking van Digipolis te kunnen blijven uitvoeren zoals tot op heden het geval was.

Daarnaast moet het eveneens mogelijk zijn om de gegevens en functionaliteiten zowel centraal als decentraal te benaderen. Dit vereist een aangepast beveiligingsniveau van de toepassing. Bepaalde meldingen en taken worden naar lokale (decentrale) IT-verantwoordelijken en netwerkbeheerders gedelegeerd, maar moeten wel centraal beheerd kunnen worden en omgekeerd.

Algemene vereisten

Korte omschrijving van de algemene vereisten:

• Gebruiksvriendelijkheid: vb. eenmalige input, zoekfunctionaliteit, vrije velden,…

• Flexibiliteit naar setup, parametrisatie versus maatwerk: Voorkeur wordt gegeven aan toepassingen met een hoge mate van parametriseerbaarheid zodat het volume aan maatwerk tot een strikt minimum kan worden beperkt.

• Zelfredzaamheid van de klant: Een grote mate van zelfredzaamheid bij de klant wordt nagestreefd. Nagegaan moet worden of alle handelingen en beheertaken voor de dagdagelijkse werking door eigen medewerkers kan worden ondersteund.

• Onderhoud van de toepassing: Belangrijk is te weten wat het volume aan beheerstaken zal zijn en welke profielen, zowel bij de klant als intern, hiervoor beschikbaar moeten zijn.

• Historiek: Specificeer voor welke gegevens een logging van handelingen moet worden bijgehouden naar traceerbaarheid. Zijn er wettelijke verplichtingen naar traceerbaarheid? Voldoet de toepassing hier aan? Is er een uitgebreidere opvolging binnen de toepassing mogelijk?

• Upgrades

• Workflow

• Ontsluiting / publicatie van gegevens: Op welke manier moeten gegevens verwerkt (scanning, barcode,…) en gepresenteerd/gepubliceerd worden.

• Modulaire opbouw, schaalbaarheid, uitbreidbaarheid van de toepassing

• Portaal, nieuwsbord, dashboards

Gevraagde koppelingen

• Een eerste koppeling is een koppeling met Altiris. Het gaat hier om de koppeling die het mogelijk moet maken om inventarisgegevens van het bestaande pc-park op te laden in de ITSM tool. De inschrijver dient momenteel reeds over een standaard koppeling met Altiris te beschikken en dit voor de verschillende domeinen van de scope van deze opdracht of is bereid om deze standaard koppeling te bekomen tegen het moment van de gunning van deze opdracht. Indien de koppeling op het moment van gunning niet is bekomen, zal dit leiden tot uitsluiting van de inschrijver.

• Een koppeling met PeopleSoft die het mogelijk maakt om de personeelsgegevens op te laden binnen de ITSM tool.

• Een koppeling met Active Directory voor de authenticatie en autorisatie van gebruikers, en het gebruik van alle relevante informatie die beschikbaar is in Active Directory.

• Een koppeling met Exchange voor het versturen en ontvangen van email via de ITSM tool, en het gebruik van alle relevante informatie die beschikbaar is in Exchange.

• Een koppeling met Navision voor het gebruik van alle relevante financiële informatie.

Bovenstaande lijst bevat de koppelingen die de inschrijver minimaal dient op te zetten bij implementatie en roll-out van de nieuwe ITSM tool – deze lijst is niet limitatief en maakt het voorwerp uit van onderhandelingen.

Gevraagde rapportering

Rapportering is één van de belangrijkste bronnen die gebruikt worden om sturing te geven aan de dienstverlening verzorgd door Digipolis. Er wordt verwacht dat de rapporteringfunctionaliteit een waaier van mogelijkheden biedt voor real-time en management rapportering. Rapporten moeten beschikbaar zijn in data en grafische formaten en kunnen ad hoc aangevraagd of periodiek ingepland worden met automatische publicatie op het portaal en nieuwsbord, of verzending via email.

Naast het uitgebreide aanbod aan standaard rapporten, moet er op een eenvoudige en gebruiksvriendelijke wijze aangepaste rapporten kunnen gemaakt worden.

Er zouden verschillende manieren moeten zijn om data te exporteren uit het pakket. Ieder veld in de database is toegankelijk voor queries. Bij de aanbieding wordt een opsomming van de standaard rapporten verwacht. Linken met eventuele rapporteringtools moet ook worden aangegeven.

Functionele vereisten

Korte omschrijving van de vereiste modules:

Huidige processen Digipolis

Alle Digipolis specifieke processen die vandaag door de huidige helpdesktoepassing worden ondersteund, moeten in de nieuwe ITSM tool worden geïmplementeerd. Er wordt van de inschrijver verwacht deze processen een plaats te geven binnen het geijkte ITIL kader.

Service Desk

De service desk is hét aanspreekpunt voor gebruikers bij dienstonderbrekingen, verzoeken of wijzigingsaanvragen. Het voorziet een communicatiekanaal van en naar de gebruikers en verzorgt de coördinatie tussen verschillende groepen en processen.

Er zijn verschillende (types) service desks die ondersteund moeten worden: lokale, centrale, virtuele en gespecialiseerde (tijdelijke) service desks.

De service desk ontvangt incidenten, verzoeken of wijzigingsaanvragen via verschillende kanalen zoals onder andere telefoon, e-mail, elektronisch loket en monitortools. Integratie met systeembeheer tools en CTI software moet de invulling van alle relevante informatie eenvoudiger maken.

Incidentbeheer

Alle incidenten worden via de geijkte kanalen aan de service desk gemeld (zie service desk). De invoering van een nieuwe ITSM tool moet het inseinen, de controle en toewijzing vereenvoudigen door gebruik te maken van sjablonen, voorstelling van mogelijk in te vullen waarden, verplichte keuzelijsten, verplichte en facultatieve velden, enz.

Het Configuration Management System (dat onderdeel is van het Service Knowledge Management System - SKMS) bevat informatie van klanten en contacten, en de in gebruik zijnde assests zodat een snelle (multi-level) categorisatie kan plaatshebben. Deze categorisatie moet toelaten om vanuit de kennisbank mogelijke oplossingen aan te reiken en om de toewijzing naar de juiste technische doelgroep te automatiseren.

Volgende termen en activiteiten verwachten we minimaal terug te vinden bij de invoeren van het incidentbeheer proces in de ITSM tool: SLA afhankelijke termijnen en tijdslimieten, significante (major) incidenten, incidentmodellen, incidentidentificatie, incidentregistratie, categorisatie, prioriteiten, initiële diagnose, functionele en hiërarchische escalatie, onderzoek en diagnose, incidentoplossing en herstel, incidentsluiting en integratie met andere modules/processen.

Probleembeheer

Het probleembeheer proces probeert problemen en de daaruit resulterende incidenten te voorkomen, weerkerende incidenten te elimineren en de impact van incidenten die niet vermeden kunnen worden te minimaliseren. Gezien de meeste problemen uniek zijn en een verschillende aanpak vereisen is de voornaamste doelstelling van probleembeheer in de ITSM tool de uniformisering van het proces te maximaliseren, door gebruik te maken van probleemmodellen.

Een duidelijke en correcte categorisering van incidenten en problemen, en regelmatige rapportering van patronen en gebieden met hoge weerkerende incidenten (trend analyse) moeten de detectie van problemen vereenvoudigen.

Voor de root cause analyse van problemen bestaan verschillende technieken (chronologische analyse, Kepner en Tregoe analyse, Ishikawa diagrammen, Pareto analyse…). De ITSM tool moet minstens het documenteren van de resultaten van deze analyses op een eenvoudige wijze ondersteunen. Beter is als er standaard analyse technieken in de tool aanwezig zijn

Volgende termen en activiteiten verwachten we minimaal terug te vinden bij de invoeren van het probleembeheer proces in de ITSM tool: probleemmodellen, probleemdetectie, probleemregistratie, categorisatie, prioriteiten, probleemonderzoek en –diagnose, workarounds, known errors, probleemoplossing, probleemsluiting, significant (major) probleem evaluatie, known errors uit de ontwikkelingsomgeving, en integratie met andere modules/processen.

Wijzigingsbeheer

Wijzigingsaanvragen worden door het individu of de groep aangevraagd die de wijziging nodig heeft, of via een andere module/proces bijvoorbeeld probleembeheer.

Wijzigingsbeheer maakt gebruik van de wijzigingsaanvraag om de geassocieerde taken te definiëren, ten einde de wijzigingsaanvraag uit te kunnen voeren.

Complexe wijzigingen kunnen dusdanig worden opgevolgd, geïmplementeerd met een minimalisering van risico en down time, op een procedurele manier. Het wijzigingsbeheer omvat het bijhouden van de aanvragen, planning van de uitvoering, goedkeuring door supervisors, opvolging van de taken en het aansturen van inventarisbeheer.

Volgende termen en activiteiten verwachten we minimaal terug te vinden bij de invoeren van het wijzigingsbeheer proces in de ITSM tool: maken en loggen van wijzigingsaanvragen, wijzigingsaanvragen accepteren, beoordelen en evalueren, wijzingen goedkeuren, standaard wijzigingen, coördinatie wijzigingsimplementatie, wijziging advies raad (Change Advisory Board – CAB), noodprocedure wijzigingen (emergency changes), en integratie met andere modules/processen.

Configuratiebeheer

Configuratiebeheer is het identificeren, controleren, rapporteren en verifiëren van service assets en configuratieobjecten, inclusief versies, baselines, basis componenten, de attributen en verbanden. Het beheert de service assets ter ondersteuning van alle andere service management processen

Het configuratiebeheer binnen de applicatie moet een snelle en gemakkelijke manier bieden om de ICT bedrijfsmiddelen binnen de organisatie te volgen en te beheren.

De functionaliteit van configuratiebeheer betreft onder andere:

• Identificatie van assets en componenten (status, locatie, versie, samenstelling, barcode enzovoort)

• Relaties tussen assets, eindgebruikers en incidenten / wijzigingen

• Relaties tussen assets onderling

• Onderhoud van asset informatie door de aangewezen personeel

• Rapportage en opvolging door management

Volgende termen en activiteiten verwachten we minimaal terug te vinden bij de invoeren van het configuratiebeheer proces in de ITSM tool: configuratiemodellen, configuration management system (CMS), configuratie identificatie en controle, status accounting en rapportering, verificatie en audit, en integratie met andere modules/processen.

Release & Deployment

Kan worden geïmplementeerd in fase 2 en wordt nader beschreven in het bestek.

Dienstenniveaubeheer

Kan worden geïmplementeerd in fase 2 en wordt nader beschreven in het bestek.

Dienstencatalogus

Kan worden geïmplementeerd in fase 2 en wordt nader beschreven in het bestek.

Service Knowledge Management System

Kan worden geïmplementeerd in fase 2 en wordt nader beschreven in het bestek.

Kennisbeheer

Kan worden geïmplementeerd in fase 2 en wordt nader beschreven in het bestek.

Financieel beheer

Kan worden geïmplementeerd in fase 2 en wordt nader beschreven in het bestek.

Technische vereisten

Korte omschrijving van de technische vereisten:

• Algemene technische vereisten

• Implementatie

• Koppelingen

• Beheerstaken

• Technische opleidingen en referentiemateriaal

• Draagbaarheid en uitbreidbaarheid

• Beveiliging

• Staging

• Performantie

• Rapporteringsmogelijkheden

• Back-up, archivering en databeheer

• Printing

SLA / Onderhoudscontract

Er wordt aan de leverancier een voorstel voor Service Level Agreement gevraagd voor de software. Deze voldoet minimaal aan het voorstel dat zal toegevoegd zijn aan het lastenboek.

Implementatie plan

Er wordt van de geselecteerde kandidaten verwacht dat zij een projectplan voorstellen tijdens de onderhandelingen die met hun zullen gevoerd worden.

Bijlage: invulformulier ‘verklaring op erewoord‘ te gebruiken bij de kandidaatstelling.

Invulformulier verklaring op erewoord

Dit invulformulier dient door de kandidaat gebruikt te worden en wordt toegevoegd aan de kandidaatstelling als bijlage.

|Verklaring | |

| |Wij, ondergetekenden, verklaren ons niet in één van de gevallen te bevinden zoals opgegeven in art. 17 (in geval van werken), |

| |art. 43 (in geval van leveringen) en 69 (in geval van diensten) van het Koninklijk Besluit van 8 januari 1996 (B.S. van 26 |

| |januari 1996) betreffende de overheidsopdrachten voor aanneming van werken, leveringen en diensten en de concessies voor |

| |openbare werken. |

| | |

| |Gedaan te op |

| |De inschrijver(s) Naam |

| | |

| |Handtekening |

| | |

| |Naam en handtekening van de gemandateerden die tekenen. Valse verklaringen leiden tot administratieve uitsluiting. |

-----------------------

[1] Voor de voorwaarden waaronder men zich kandidaat kan stellen: zie de gepubliceerde aankondiging in het europees publicatieblad en/of het bulletin der aanbestedingen

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download