Aanbestedingsinformatie

Op basis van alle lessen van dit project hebben we een aantal technische bepalingen gedefinieerd met een kleine handleiding om andere steden en gemeenten dergelijke technologie te laten aanbesteden.

Inleiding

Deze technische bepalingen en de opdracht zijn het resultaat van het City of Things project genaamd ‘Museum of Things for People (MOTFP)’, een Smart City project mogelijk gemaakt dankzij VLAIO. Deze bepalingen moeten steden, gemeenten en dienst musea in Vlaanderen in staat stellen om snel en gericht in te zetten op indoor positioneringstechnologie binnen een museum context. Concreet kan je deze technische bepalingen zien als een bijlage die alle inhoud bevat om te vervatten in een openbare aanbesteding. Onze keuze ging naar een inhoudelijk document dat op een dynamische manier kan gebruikt worden door andere steden en gemeenten die willen inzetten op indoor positionering. Dit omdat de opzet van bestekken en gunningscriteria vaak heel organisatiespecifiek zijn.

We hebben de opzet en het detail van deze technische bepalingen gebaseerd op de benodigde informatie binnen een Vereenvoudigde onderhandelingsprocedure met bekendmaking (VOMB BE).

Let op, lees wel goed de gebruiksinstructies. Gezien de uitrol van deze technologie afhankelijk is van de specifieke vraag en beschikbare infrastructuur, moet je zelf bijkomende informatie voorzien en keuzes maken binnen de behoeften over wat wel en niet verwacht wordt. Bekijk deze bijlage dus als een dynamisch keuzemenu dat je op basis van eigen voorkeuren en beschikbare informatie naar je hand kan zetten.

Gebruiksinstructies

Dit document kan je gebruiken voor de opstelling van een indoor positionerings bestek, het bevat de suggesties, inhoudelijke onderdelen en de definiëring van de functionele en niet-functionele behoeften.

Wat zit vervat in deze bijlage

  • Het voorwerp van de opdracht met het doel en focus van de gevraagde opstelling

  • De verwachtingen die de technologie moet inlossen gekoppeld aan de MosCow-methode

  • De functionele en niet-functionele behoeften in een aparte spreadsheet

  • Duiding over de toe te voegen en organisatie specifieke informatie om de aanbesteding grondig te kunnen inzetten

  • Suggesties over de duurtijd, verloop offerte, onderaanneming en gunningscriteria

Wat zit niet vervat in deze bijlage

Bestek modaliteiten

Het algemene kader van een modelbestek hebben we in deze bijlage bewust achterwege gelaten. Deze informatie is vaak aanwezig bij de beoogde hergebruikers, met specifieke accenten afhankelijk van de organisatiestructuur. Zo zal een technische aanbesteding voor steden met een vaste IT-dienst en een gevestigde architectuur anders opgesteld worden dan kleinere gemeenten die minder op een IT-integratie gefocust zijn en zoveel mogelijk van de overhead willen uitbesteden. De zaken waarvan wij verwachten dat de steden, gemeenten en / of musea dit zelf toevoegen zijn:

  • De algemene en wettelijke bepalingen conform de WOO

  • De finale selectie en gunningscriteria, er is wel een suggestie vervat in deze bijlage

  • Het verloop en de fases van de gunningsprocedure

  • Een schema template voor de IT-infrastructuur. Een schematische voorstelling kan vaak helpen bij het visualiseren van alle componenten die wel of niet onderdeel uitmaken van de voorgestelde oplossing.

  • Bijlage met de opgelegde standaarden op vlak technologie, security en architectuur

  • De SLA bepalingen, ofwel de raamovereenkomst voor support en onderhoud

Specifieke context

Naast de bestek modaliteiten heb je tevens ook context informatie nodig die de potentiële leveranciers kan helpen om een zo correct mogelijk offerte voor te stellen. Dit moet vooral inzicht geven in de ruimte, faciliteiten en de opstelling van het museum. Een algemene regel hierbij is dat hoe meer informatie kan voorzien worden, hoe concreter offertes kunnen opgesteld worden door potentiële leveranciers. We geven kort mee welke informatie relevant is:

  • De beoogde oppervlakte die het indoor positioneringsysteem moet afdekken. Dit zal voornamelijk overeenkomen met de totale oppervlakte van de publieke ruimtes in het museum. Idealiter uitgedrukt in aantal vierkante meters.

  • De oppervlakte en inrichting van de museum ruimtes, dit kan een inschatting geven van hoe de opstelling er moet uitzien. Volgende opdeling kan hierbij helpen:

    • Entree ruimte

    • Ticket-office

    • Praktische ruimten zoals vestiaire en toiletten

    • De gift shop

    • Horeca (café / resto)

    • Tussenruimtes

    • Museumzalen met een vaste collectie

    • Museumzalen met een tijdelijke functie

    • Polyvalente en event ruimtes

  • Een gedetailleerd plan van de publieke ruimte die je wil inzetten in functie van deze technologie. Dit kan via een 3D-file, maar kan evengoed via een architecturaal plan gebeuren.

  • Een overzicht van de netwerkinfrastructuur, positie en opzet om dit indoor positionering netwerk via een gateway te verbinden met het interne netwerk of het internet. Idealiter wordt deze ook aangegeven op het plan om de afstand tussen de infrastructuur en de beoogde ruimtes te bepalen.

  • De specifieke details over welke vaste structuren zich in een ruimte begeven (muren, steunpilaren,...) om correct te bepalen hoeveel vaste sensoren nodig zijn voor een maximale dekking.

  • Eventueel kan dit aangevuld worden met een serie foto’s om de aanbieder een beter beeld te geven.

  • Bovendien kan een contactadres van een medewerker worden opgegeven zodat een aanbieder op voorhand een kijkje kan komen nemen als deel van het offerteproces.

Je zal opmerken dat de eerste items in deze lijst kritische informatie bevatten, hoe verder je gaat, hoe meer dit in detail gaat om een goede inschatting te kunnen maken van de opzet. Hoeveel van deze informatie je in de initiële offerte aanvraag kan toevoegen hangt dus grotendeels af van de beschikbaarheid. Voor oudere gebouwen zullen niet alle details bekend zijn of in een coherent plan verwerkt zijn, voor moderne gebouwen kan je een BIM-model toevoegen aan de offerte om inzicht te bieden in de structuur en noden van het gebouw.

Beschrijving functionele en niet-functionele behoeften

Het gros van de benodigde informatie bestaat uit de functionele en niet-functionele behoeften. Deze zijn opgedeeld in 6 groeperingen die je afhankelijk van je wensen kan toevoegen of weglaten uit het bestek. Alle behoeften kan je terugvinden in het apart bestand onderaan deze opsomming: De functionele en niet functionele behoeften. We lichten toe hoe je deze onderdelen kan inzetten in jouw bestek:

  1. CAPTEER, de effectieve hardware - Dit gaat om de effectieve hardware en alle software of diensten die nodig zijn om deze up and running te houden. Dit vormt de kern van de technische bepalingen die op de behoeften van het MOTFP project zijn gebaseerd. Hier kan je wel nog differentiëren in specifieke eigenschappen. Bv. als je museum een zeer open scenografie heeft zou je kunnen kiezen voor indoor positionerings technologie die nauwkeurig is op 1 meter ipv 50 centimeter. Indien je een heel drukke scenografie hebt kan je zelf 50 centimeter terugdringen naar 20 centimeter of minder.

  2. INSTALLEER, de voorbereiding - Dit gaat over de voorbereiding, planning en fysieke installatie van de vaste hardware in het gebouw. Sommige musea hebben voldoende aan een plaatsingsplan en kunnen de installatie zelf voorzien, sommige werken via een aparte aanbesteding of dienst zoals Facility Management en andere willen dat de leverancier dit volledig zelf voorziet, al dan niet met een onderaannemer. Vandaar dat we deze behoeften meenemen in de technische bepalingen, maar vrij laten of deze al dan niet opgenomen worden in het finale bestek. Je hebt minstens wel een plaatsingsplan nodig (zie I01) om de installatie zelf te ondernemen.

  3. SUGGEREER, de aanbevelings component voor bezoekers - Deze recommendation engine is een op maat gemaakt aanbevelingssysteem dat zoals in MOTFP je in staat stelt om bezoekers hun interesseprofiel te capteren op basis van hun positie en route in het museum om zo door te verwijzen naar andere plekken in de stad. Gezien deze functionaliteit gevalideerd werd tijdens het MOTFP project hebben we hier ook de meest concrete behoeften gedefinieerd. Indien er geen wens is om suggesties te doen naar de eindgebruiker, maar indoor positionering wil gebruiken voor andere doeleinden kan je dit onderdeel weglaten.

  4. ANALYSEER - Analytisch inzicht component voor beheerders - deze interne component maakt het mogelijk om analyses te doen op basis van de geanonimiseerde data van de bezoeker. Dit maakt het mogelijk voor het museum om inzicht te krijgen in waar bezoekers zich in het museum begeven. Musea die dit niet wensen kunnen deze component weglaten. Het kan wel niet de enige component zijn door zijn interne waarde. Zonder een component die ook meerwaarde biedt voor je eindgebruiker, de bezoeker, zal ook deze toepassing niet werken omdat de bezoeker niet zal snappen waarom zij een sensor moeten dragen om het museum te bezoeken. Er moet steeds een voordeel voor de bezoeker aan gekoppeld zijn.

  5. DELEGEER - Wayfinding component - deze maakt het mogelijk om binnen de museale context sneller de weg te vinden binnen het museum aan de hand van indoor positionering. Dit vergt een andere aanpak, met name die van de slimme bewegwijzering. Deze component is vooral interessant voor grote musea, of musea die via bezoeker feedback te horen krijgen dat bepaalde stukken of zalen niet gevonden worden. Deze component vergt extra hardware en software om te integreren en is ook optioneel. De nood van deze component werd tijdens MOTFP wel gecapteerd, maar niet getest.

  6. INFORMEER - Informatie op maat component - deze maakt het mogelijk om de informatievoorziening in het museum dynamisch te maken op basis van de wensen van de bezoeker en hun positie. Aan de hand van de voorkeuren van de bezoeker kunnen zaalteksten en schermen zich dynamisch aanpassen op vlak van vorm en inhoud. Deze component vergt extra hardware en software om te integreren en is ook optioneel. De nood van deze component werd tijdens MOTFP wel gecapteerd, maar niet getest.

Inhoud voor deze opdracht

Onderstaande inhoud, vanaf ‘voorwerp van deze opdracht’ kan gebruikt worden voor de inhoudelijke invulling van het bestek. Dit bevat het voorwerp, de verwachtingen en uitleg bij de functionele en niet-functionele behoeften.

Voorwerp van deze opdracht

[Organisatie of museum X] wenst een overheidsopdracht uit te schrijven voor de aankoop van een indoor positioneringsysteem dat het [X] museum in staat stelt om op basis van de beweging van de bezoekers een persoonlijkere dienstverlening te bieden en beter inzicht te verkrijgen in hun interesses en voorkeur in het museum.

Het doel bestaat erin om op basis van indoor positionering technologie de bezoeker te kunnen volgen in het museum zonder dat hij of zij een persoonlijke smartphone of ander toestel moet ter beschikking hebben. Dit kan dienen een verbeterde dienstverlening op drie niveaus:

  • Toeleiding (SUGGEREER): Op basis van een recommendation engine krijgt de bezoeker inzicht in eigen interesses en de mogelijkheden om na een bezoek de ervaring door te trekken naar andere plekken of ervaringen in de stad.

  • Wayfinding (DELEGEER): Door gebruik te maken van deze technologie kan de bezoeker voor het bezoek inzicht krijgen in de drukte in het museum en kan deze ook tijdens het bezoek begeleid worden naar interessante plekken, specifieke routes aanbieden of duiden welke onderdelen de bezoeker gemist heeft.

  • Informatie op maat (INFORMEER): De bezoeker krijgt kan ook de vorm van de informatiedeling binnen de opzet van het museum aanpassen en ook diepere informatie krijgen over naar zijn of haar voorkeuren. Dit zal vooral de zaalteksten en schermen binnen het museum aansturen.

Op basis van de geaggregeerde en geanonimiseerde verzamelde data krijgt het museum inzicht (ANALYSEER) in de interesses, routes van de bezoekers en de performantie van de opstelling en informatievoorziening.

Verwachtingen

Om de verwachtingen te definiëren gebruiken we de MoSCoW-methode die duidelijk de prioriteiten moet aangeven per behoefte. De letters staan voor:

M - must haves: deze eisen (behoeften) moeten in het eindresultaat terugkomen, zonder deze eisen is het product niet bruikbaar;

S - should haves: deze eisen zijn zeer gewenst, maar zonder is het product wel bruikbaar;

C - could haves: deze eisen zullen alleen aan bod komen als er tijd genoeg is;

W - won't haves: deze eisen zullen waarschijnlijk in dit project niet aan bod komen maar kunnen in de toekomst, bij een vervolgproject, interessant zijn. Ze worden daarom ook wel eens aangeduid als "would haves", maar dit is incorrect.

Functionele behoeften

De opdracht omvat de aankoop van indoor positionering hardware met bijbehorende kalibratie- en beheersoftware incl. service voor installatie, opleiding en onderhoud.

Beschikbaarheid, bruikbaarheid en kwaliteit van het conceptueel voorstel worden afgetoetst tegen de functionele vereisten zoals opgelijst in bijlage 22 (functionele vereisten) onderverdeeld in volgende categorieën.

  1. CAPTEER: De indoor positie hardware en alle software of diensten die nodig zijn om deze up and running te houden.

  2. INSTALLEER - Dit gaat over de voorbereiding, planning en fysieke installatie van de vaste hardware in het gebouw.

  3. SUGGEREER - Deze recommendation engine is een op maat gemaakt aanbevelingssysteem die zoals in MOTFP je in staat om bezoekers hun interesseprofiel te capteren op basis van hun positie en route in het museum om zo door te verwijzen naar andere plekken in de stad.

  4. ANALYSEER - Deze interne back-office maakt het mogelijk om analyses te doen op basis van de geanonimiseerde data van de bezoeker. Dit maakt het mogelijk voor het museum om inzicht te krijgen in waar bezoekers zich in het museum begeven.

  5. DELEGEER - Dit maakt het mogelijk om binnen de museale context sneller de weg te vinden binnen het museum aan de hand van indoor positionering door de inzet van slimme bewegwijzering.

  6. INFORMEER - Dit maakt het mogelijk om de informatievoorziening in het museum dynamisch te maken op basis van de wensen van de bezoeker en hun positie. Aan de hand van de voorkeuren van de bezoeker kunnen zaalteksten en schermen zich dynamisch aanpassen op vlak van vorm en inhoud.

Bovendien zijn er een aantal minimale vereisten opgelegd waaraan de oplossing moet voldoen (MUST HAVES). Het niet voldoen van de voorgestelde oplossing aan één van deze minimale vereisten is een uitsluitingscriterium tijdens de gunning.

Deze minimale vereisten zijn opgenomen in Bijlage 22.

Niet-functionele behoeften

Ook op vlak van de niet functionele behoeften zijn er een aantal minimale vereisten opgelegd waaraan de oplossing moet voldoen. Het niet voldoen van de voorgestelde oplossing aan deze minimale vereisten is een uitsluitingscriterium tijdens de gunning.

Deze minimale vereisten zijn opgenomen in het document "bijlage 22, tab niet-functionele behoeften".

Er wordt aan de inschrijver gevraagd om een technisch schema (of schema’s) aan te leveren waarin alle aangeboden componenten (services), de gelaagdheid (Tiers), de onderlinge verbanden (koppelingen) en de integratie en verbanden met bestaande componenten duidelijk aangetoond wordt.

Operationele afspraken

We verwachten in het voorstel van de inschrijver een concrete beschrijving rond volgende items:

  • Support afspraken:

    • De inschrijver dient een voorstel in dat voorziet in operationele ondersteuning van het live product.

    • Afhankelijk van het architectuurplaatje/technology stack wordt gekozen voor het meest aanbevolen ondersteuningsmodel.

    • Budgettaire implicaties.

  • Infrastructuur:

    • De inschrijver levert een duidelijk plaatsingsplan aan om de maximale dekking van de beoogde oppervlakte te garanderen.

    • De inschrijver omschrijft duidelijk het infrastructuurplatform waarop de oplossing wordt aangeboden

    • On premise of cloud

    • Indicatie minimum infrastructuurcapaciteit: storage, memory, CPU, netwerk, ...

    • Welke operationele activiteiten zijn noodzakelijk?

    • ...

  • Beschikbaarheid van de functionaliteit:

    • De inschrijver geeft aan welke garanties hij biedt voor de beschikbaarheid van het op te leveren resultaat.

    • Is er sprake van Zero downtime deployment?

    • Is de oplossing self healing?

  • Logging en monitoring

    • De inschrijver beschrijft de voorziene ingebouwde logging en monitoring en levert die bruikbaar op voor operations activiteiten.

  • Beveiliging:

    • De inschrijving onderschrijft een verwerkersovereenkomst bij gunning m.b.t. logging van privacygevoelige gegevens

Suggesties randvoorwaarden en opzet aanbesteding

Onderstaande onderdelen zijn suggesties bij het verwerken van de inhoud in het bestek. We geven mee hoe het verloop van de procedure kan verlopen, welke duurtijd gebruikelijk is bij dergelijke projecten, hoe je met onderaanneming kan omgaan en wat mogelijke gunningscriteria zijn. Je kan uiteraard kiezen om hierbij andere keuzes te maken.

Verloop

Hierbij volgt een beknopte suggestie van het verloop van de gunningsprocedure. Dit verloop kan je vervatten en verder uitwerken in het bestek.

  1. Verzending van het bestek aan inschrijvers en uitnodiging voor het indienen van een offerte

  2. Toelichtingsvergadering en bezoek aan het museum

  3. Mogelijkheid tot vraag en antwoord tijdens het bezoek

  4. Indiening offerte

  5. Beoordeling regelmatigheid van de offerte

  6. Eerste gesprek en demo van het voorstel

  7. Bilaterale onderhandelingen

  8. Indiening BAFO

  9. Beoordeling BAFO’s en rangschikking inschrijvers

  10. Gunning en sluiting van de opdracht

Duurtijd

De standaard duurtijd van dergelijke raamovereenkomst bedraagt: 4 jaar. Geef zeker de verwachte go-live mee (wanneer moet de installatie live staan), en of dit in samenloop is met eventueel andere verbouwingswerken. Onderhoud, versiebeheer en SLA definieer je best als contracten van onbepaalde duur die jaarlijks verlengbaar of jaarlijks opzegbaar zijn.

Onderaanneming

Vermeld zeker dat onderaanneming toegestaan is, dergelijke end-to-end toepassingen zijn nog maar in beperkte mate verkrijgbaar op de markt en onderaanneming zal het aanbod door kleine innovatieve spelers versterken. Dergelijke end-to-end oplossing vergt ook expertise in verschillende velden zoals hardware en installatie, data-analyse en software development.

Gunningscriteria en weging

Gezien we veel aandacht leggen op de functionele en niet-functionele behoeften stellen we onderstaande gunningscriteria voor:

Last updated