Vraaggedreven onderzoeksprogrammering Of: Hoe kunnen potentiële gebruikers van onderzoeksresultaten bij het vaststellen van de onderzoeksagenda worden betrokken? Een handleiding voor: Centexbel Flamac Flanders Food Flanders Drive FMTC IBBT IMEC MIP VIL VITO WTCM Geert van der Veen Wieneke Vullings Patries Boekholt Versie februari 2007
SAMENVATTING Bij het opzetten van onderzoeksprogramma s vanuit een algemeen belang, wordt steeds meer waarde gehecht aan economische of maatschappelijke toepassing van de opgedane kennis. Europa is minder goed in dit proces dan andere regio s in de wereld. Om dit proces van onderzoek naar toepassing worden steeds vaker de wensen en belangen van stakeholders betrokken bij het definiëren van onderzoeksprogramma s. Er ontstaat een vraaggedreven onderzoeksprogrammering, waarbij veelal de stakeholders ook daadwerkelijk in het programmeringsproces betrokken worden. Er zijn verschillende motieven voor het gezamenlijk programmeren van onderzoek (hoofdstuk 1.1): het garandeert dat een voor veel partijen relevant probleem wordt onderzocht het stimuleert verdere vraagarticulatie door de marktpartijen het vergroot het draagvlak voor het onderzoek (en het gebruik van de resultaten daarvan) het optimaliseert het strategisch proces het stimuleert duurzame netwerken binnen een sector of in een domein het levert een potentieel groter marktsucces op voor het resultaat van het onderzoek Op verzoek van 11 organisaties in Vlaanderen die zich met (vraaggedreven) onderzoeksprogrammering bezig houden heeft Technopolis deze handleiding opgesteld. Dit handboek geen spoorboekje waarbij niet afgeweken kan worden van het voorschreven traject, maar het is een ideeënbron die theoretische modellen en praktische voorbeelden biedt om onderzoeksprogrammering (meer) vraaggedreven te maken. De basis van de handleiding vormt een cyclisch model van het programmeringsproces met vier fasen (1.2): programma afbakening; programma ontwerp; programma uitvoering; en programma evaluatie en kennisoverdracht. Tijdens de programma afbakening worden globale doelstellingen en randvoorwaarden van het programma vastgesteld, en wordt een programmeringsaanpak opgesteld. Dit gebeurd aan de hand van 5 afbakeningsvragen (2.1): 1. Wat is het probleem/de kans waar het onderzoeksprogramma zich op richt? (Probleemidentificatie) 2. Welke maatschappelijke doelstelling moet het programma bereiken? (Globale doelbepaling) 3. Welke middelen zijn beschikbaar voor het programma? (middelen bepaling) 4. Welke partijen moeten de resultaten van het project gaan gebruiken? (doelgroepbepaling) 5. Wie moet de activiteiten in het programma gaan uitvoeren? (actor-bepaling) Meestal worden deze vragen door een kleine groep initiatiefnemers beantwoord (2.2). Er zijn diverse methoden om het gebruikersperspectief bij de programma afbakening te betrekken (2.3), zoals trendstudies, SWOT analyses of verkennende interviews. 2
De tweede fase in het vraaggedreven programmeringsproces is het programmaontwerp. Het eindresultaat van deze fase is een programma: een samenhangend geheel van activiteiten, projecten met daarbijbehorende projectuitvoerders, die bijdragen aan het bereiken van de programmadoelstellingen. In deze fase wordt de programma logica ontwikkeld: de samenhang tussen doelstellingen en activiteiten in het programma (3.1). Dit is een niet-lineair proces, waarbij na afloop de volgende issues geadresseerd dienen te zijn: Themakeuze; Bepaling van concrete programmadoelstellingen; Vertaling van doelstellingen in de programma activiteiten Indicatoren voor het meten van de voortgang in het bereiken van de programmadoelstellingen; Toedeling van middelen aan de activiteiten; Bepalen van de uitvoerders van activiteiten; Bepalen van de stakeholders/doelgroep bij iedere activiteit. Programma ontwerp start meestal met een stakeholderanalyse (3.2), waarbij de stakeholders en hun belangen in kaart worden gebracht teneinde hen optimaal bij het programma ontwerp te kunnen betrekken (3.2).Hoewel er vele mogelijke routes zijn om een programma samen met stakeholders te ontwerpen, blijken in de praktijk in ontwerpprocessen 5 elementen voor te (kunnen) komen: 1. Themakeuze 2. Idee generatie 3. Idee selectie 4. Project generatie 5. Project selectie (3.3). In dit proces gericht op projectdefinitie en selectie, worden ook uitvoerders van de activiteiten (3.4) en toedeling van de middelen (3.5) bepaald. Ook zouden in deze fase indicatoren vastgesteld moeten worden waarmee de voortgang en het succes van het programma te meten zijn (3.6). Voor het realiseren van de doelen van een programma is het van belang dat alle betrokkenen (financier, programmauitvoerders en veelal ook stakeholders) eenduidige en heldere afspraken hebben gemaakt over hun rol, hun bijdrage en hun revenuen (3.7). Daartoe kunnen algemene voorwaarden gesteld worden op programmaniveau en contractafspraken op projectniveau. Afspraken over financiering en kennisbescherming en kennisexploitatie zijn een essentieel onderdeel. Mogelijke nuttige methodieken voor deze optiegenererende en prioriterende fasen zijn o.a. scenario analyses; delphi studies; stakeholder analyse; focusgroepen; gestructureerde interviews en surveys; roadmapping, en brokerage. Zodra de projecten geselecteerd en gecontracteerd zijn, is de programma ontwerpfase afgerond en gaat het programma over naar de volgende fase van de 3
programmeringcyclus, de programma-uitvoering. Deze fase omvat de opvolging en begeleiding van lopende projecten (4.1) en programmamanagement (4.2), en de activiteiten over de projecten heen, zoals kennisoverdracht gedurende de looptijd van de projecten en monitoring van het programma.in deze fase is een belangrijke rol weggelegd voor o.a. het instellen van stuurgroepen en begeleidingscommissies; brokerage, partnership planning en contractbesprekingen; en management, administratie en monitoring. Het doel van een evaluatie van een programma (5.1; 5.2) is het vaststellen van de mate van het (positieve) verband tussen het gebruik van middelen voor onderzoek en het uiteindelijke economisch en maatschappelijk doel. Een evaluatie kan dienen als verantwoording voor de uitgaven, het biedt de mogelijkheid een programma bij te sturen en het kan voorkomen dat een programma blijft bestaan terwijl de initiële doelen reeds zijn behaald of het programma geen functie meer heeft. Evaluatie vindt plaats, door middel van evaluatie methodieken (programma- en wetenschappelijke evaluaties), klanttevredenheidsaudits en expert reviews. De uitkomsten en verbeterpunten kunnen worden gecommuniceerd via o.a. electronische en schriftelijke communicatiekanalen, in workshops of conferenties. Kennisoverdracht loopt ook door na afloop van het programma (5.3). Dit is een belangrijk element bij het creëren van een zo hoog mogelijke impact. Diverse methoden zijn hiervoor geschikt. Onderstaande figuur geeft op weer welke methodieken wanneer en met welke stakeholders kunnen worden ingezet. De interactieve processen en methoden die in de handleiding worden genoemd, worden nader toegelicht en uitgewerkt in hoofdstuk 6, de toolbox van de handleiding. Per methode wordt een korte omschrijving gegeven, wordt aangegeven wanneer de methode in het programmeringsproces gebruikt kan worden, wat voor- en nadelen van de methode zijn, en waar meer informatie over de methode te vinden is. Visionairen/ experts Verkennende interviews Werkgroepen Delphi-studie Stakeholder-analyse Roadmapping Management Administratie Monitoring Expert review (Externe) evaluatie Selectie/ representatie State of the art-studie Verkenningen Swot-analyse Werkconferenties Scenario-analyse Focusgroepen Gestructureerde interviews Brokerage Stuurgroep Begeleidingscommissie Partnershipplanning Workshops Alle stakeholders Verkennende surveys Gestructureerde surveys Brokerage Klanttevredenheid Audit Conferenties Programma Afbakening Programma Ontwerp 4 Programma Uitvoering Evaluatie & Kennis overdracht
Inhoudsopgave 1 Inleiding 7 1.1 Waarom is gezamenlijke vraaggedreven onderzoeksprogrammering belangrijk? 8 1.2 Het programmeringsproces 9 1.3 Begrippen 11 2 Programma afbakening 13 2.1 Vijf kernvragen om het onderzoeksprogramma af te bakenen 13 2.1.1 Probleemidentificatie 13 2.1.2 Doelbepaling 14 2.1.3 Middelen 14 2.1.4 Doelgroep 14 2.1.5 Uitvoerder 15 2.2 Wie bakenen het programma af? 15 2.3 Hoe wordt het gebruikersperspectief betrokken bij de programma afbakening? 16 3 Programmaontwerp 18 3.1 Ontwerp issues 18 3.2 Stakeholders 19 3.2.1 Stakeholder identificatie en analyse 19 3.2.2 Omgaan met sterk verschillende belangen 20 3.2.3 Overwegingen bij stakeholder betrokkenheid in het programmering proces 23 3.2.3.1 Omvang van de doelgroep 23 3.2.3.2 Absorptiecapaciteit 24 3.2.3.3 Onderling vertrouwen 24 3.3 Invullen van de inhoud van een programma 25 3.3.1 Doelbepaling, themadefinitie 26 3.3.1.1 Themakeuze in de praktijk 26 3.3.2 Ideegeneratie 27 3.3.3 Ideeselectie 27 3.3.4 Projectgeneratie 28 3.3.5 Projectselectie 29 3.3.6 Programmeringsroutes bij de VIS-partners 29 3.4 Uitvoerders van het onderzoek 33 3.5 Middelen 34 3.6 Indicatoren, nulmeting 35 3.7 Afspraken tussen betrokkenen 35 3.7.1 Randvoorwaarden aan indiening, administratieve vereisten 35 3.7.1.1 Randvoorwaarde: welke partijen mogen mee doen? 35 3.7.1.2 Voorwaarden t.a.v. financiering en eigen bijdrage 36 3.7.1.3 Vormvereisten en administratieve randvoorwaarden 36 3.7.2 Randvoorwaarden honorering 37 3.7.2.1 Kennisbescherming en kennisexploitatie 38 5
4 Programma uitvoering 39 4.1 Opvolging projecten 39 4.2 Programmamanagement 40 4.2.1 Kennisoverdracht en netwerkvorming 40 4.2.2 Monitoring 41 5 Evaluatie en kennisoverdracht 42 5.1 Evaluatie van resultaten, effecten en impact 42 5.2 Evaluatie strategie 43 5.3 Kennisoverdracht na afloop van de projecten 44 6 Toolbox voor GVO 46 6.1 Methoden voor vraaggedreven programma afbakening 47 6.1.1 Verkenningen, trendstudies, foresight 47 6.1.2 Stakeholder analyse 50 6.1.3 Technology Assessment 53 6.2 Methoden voor vraaggedreven programma ontwerp 55 6.2.1 Scenario analyse 55 6.2.2 Quality Function Deployment en Technical Market Research 57 6.2.3 Creatieve methoden om algemene behoeften te vertalen in specifieke noden 60 6.2.3.1 Brainstormen 60 6.2.3.2 Visualisatietechnieken 61 6.2.3.3 Future conditioning 61 6.2.4 Delphi studies 62 6.2.5 Logical Framework Analyse 63 6.2.6 Focusgroepen 67 6.2.7 Roadmapping 67 6.3 Methoden voor vraaggedreven programma uitvoering 70 6.3.1 Community of practice 70 6.3.2 Research partnership planning 72 6.4 Programma oproepen 73 6.4.1 Vormen van programma-oproep 74 6.4.1.1 Tenders: beperkt en open 74 6.4.1.2 Continu programma 75 6.4.2 Wijze van indienen 76 6.4.3 Beoordelingsprocedure 78 6.4.3.1 Beoordelingscriteria 78 6.4.3.2 Beoordelaars 79 6.5 Methoden voor vraaggedreven programma evaluatie en kennisoverdracht 81 6.5.1 Evaluatiemethoden 81 6.5.2 Klanttevredenheidaudits 82 6.5.3 Expertpanel en wetenschappelijke peer review 84 6
1 Inleiding In Vlaanderen houden diverse partijen zoals onderzoekscentra, competentiepolen en collectieve centra zich bezig met onderzoeksprogrammering. Vele van deze organisaties hebben een mechanisme opgesteld om hun doelgroep te betrekken bij het ontwerpen en soms ook uitvoeren van haar onderzoeksprogramma. Een goede bevraging van de doelgroep is daarbij essentieel om het onderzoek af te stemmen op de vraag van de bedrijven en zo innovatie te bevorderen. De processen van vraagsturing verlopen echter, naar de mening van een 11-tal van deze organisaties 1, nog niet optimaal. Daarom heeft men gezamenlijk een Vlaams Innovatie Systeem project (VIS-project) opgezet om deze processen en mechanismen te verbeteren. De doelstelling van het project is een handleiding op te stellen voor het bepalen van vraaggedreven gemeenschappelijke onderzoeksprojecten en zo de werkwijzen van de betrokken organisaties te kunnen verbeteren. Voor u ligt deze handleiding. Deze handleiding is geen spoorboekje (dat geen ruimte biedt voor afwijking van het gebaande spoor precies stap voor stap gevolg dient te worden), maar eerder een reisgids die aangeeft wat de mogelijkheden zijn, en hoe van deze mogelijkheden gebruik te maken. De handleiding biedt een (beperkt) theoretisch kader van het programmeringsproces. Daaraan is een groot aantal issues opgehangen die men in de praktijk van het gezamenlijk met gebruikers programmeren van onderzoek, tegen kan komen. In hoofdstuk 1 wordt kort weergegeven waarom gezamenlijke vraaggedreven onderzoeksprogrammering belangrijk is voor de VIS-partners, en wordt een ideaal programmeringsproces beschreven. Ook worden kort de kernbegrippen gedefinieerd en helpt de leeswijzer het handboek interpreteren. De volgende hoofdstukken 2, 3, 4 en 5 vormen de kern van dit handboek en beschrijven stapsgewijs de onderdelen van het onderzoeksprogrammeringsproces. Welke vragen moet je als programmerende organisatie stellen om tot een vraaggedreven onderzoeksprogramma te komen? Welke activiteiten moet je ondernemen en wanneer? Ook wordt beschreven welke actoren het beste bij deze activiteiten betrokken kunnen worden, en wordt advies gegeven over de mogelijke methodieken om dit te doen. Een aantal van de benoemde methodieken wordt beschreven in de toolbox in hoofdstuk 6. Telkens is aangegeven wat de VIS-partners aan deze methodieken kunnen hebben en wat de voor- en nadelen zijn. Dit hoofdstuk kan dus ook op zichzelf gelezen worden, maar dient te ondersteuning van de hoofdstukken 2 t/m 5. Zoals al eerder gezegd is het handboek geen spoorboekje waarbij niet afgeweken kan worden van het voorschreven traject. Het biedt wel richtlijnen om onderzoeksprogrammering (meer) vraaggedreven te maken, en zo efficiënt en effectief mogelijk de noden en behoeften van de markt in kaart te brengen en te integreren in het programmeringsproces. Er wordt regelmatig verwezen naar de huidige praktijk van de VIS-partners en andere (buitenlandse) voorbeelden om de keuzepaden en alternatieven te illustreren. Uiteindelijk is het aan de lezer om zelf te bepalen waar in het 1 CENTEXBEL, Flamac, Flanders Food, Flanders Drive, FMTC, IBBT, IMEC, MIP, VITO, VIL, WTCM 7
onderzoeksprogrammeringsproces behoefte isaan verbetering of aanpassing van de huidige praktijk, en welke opties, voorbeelden en suggesties het beste passen bij zijn context, of wellicht met een kleine individuele aanpassing nog beter passen. Elk commentaar en suggestie voor verbetering van het handboek is uiteraard welkom op het adres van de auteurs. 1.1 Waarom is gezamenlijke vraaggedreven onderzoeksprogrammering belangrijk? Gezamenlijke vraaggedreven onderzoeksprogrammering betekent dat onderzoekers, bedrijven en publieke organisaties niet alleen op projectbasis met elkaar samen werken, maar dat gezamenlijk een programma wordt gedefinieerd waarbij de collectieve noden van de industrie en andere stakeholders de basis vormen voor de richting van het programma. In het verleden was planning en programmering van oorsprong gecentraliseerd, top-down en technocratisch. Het werd vooral door het seniormanagement van bedrijven of onderzoeksinstellingen gedaan en met weinig input van (kern)stakeholders zoals klanten, leveranciers of financiers. Uit ervaring blijkt dat een dergelijk proces niet optimaal is om innovatie te bevorderen, en het succes van de innovaties in de markt te vergroten; een meer vraaggedreven benadering is gewenst. Dit betekent niet per se dat onderzoeksprogramma s ook bottom-up worden gedefinieerd (dus met de toekomstige gebruikers van kennis) maar de programmerende organisatie dient in elk geval wel beter rekening te houden met de (toekomstige) vraag van de markt. In de literatuur worden verschillende motieven gegeven voor het gezamenlijk programmeren van onderzoek: het garandeert dat een voor veel partijen relevant probleem wordt onderzocht het stimuleert verdere vraagarticulatie door de marktpartijen het vergroot het draagvlak voor het onderzoek (en het gebruik van de resultaten daarvan) het optimaliseert het strategisch proces het stimuleert duurzame netwerken binnen een sector of in een domein het levert een potentieel groter marktsucces op voor het resultaat van het onderzoek Belangrijk is deze motieven niet geheel los van elkaar te zien. Het is bijvoorbeeld vanzelfsprekend dat wanneer een relevant probleem onderzocht wordt, de kans op marktsucces groter is dan wanneer een niet relevant probleem wordt onderzocht. De VIS-partners in Vlaanderen hebben naast deze algemene motieven ook specifieke redenen om vraaggedreven onderzoeksprogrammering te willen verbeteren. De partners hebben niet allemaal dezelfde instituutsvorm, en dit heeft invloed op de motieven en vormen van vraaggedreven onderzoeksprogrammering. De VIS-partners zijn ofwel R&D uitvoerders (bijvoorbeeld VITO); competentiepolen en collectieve onderzoekscentra (bijvoorbeeld FMTC en WTCM); en netwerkorganisaties (zoals het MIP). 8
Voor de R&D uitvoerders is onderzoeksprogrammering de core business, maar vaak is de afstand tot de bedrijven in de sector, de vragers, relatief groot en is het voor hen van belang deze afstand te verkleinen. Door nauwer samen te werken met de competentiepolen of collectieve centra zou deze afstand verkleind kunnen worden, maar ook door duidelijk de markt te definiëren en deze te bevragen. Het ontwerpen en uitvoeren van het programma gebeurt meestal intern. De competentiepolen en collectieve centra hebben veelal een gedefinieerde groep leden of stakeholders in hun netwerk waarvoor ze bijvoorbeeld kennis en technologie ontwikkelen of laten ontwikkelen, waarna het door de bedrijven in de praktijk getoetst kan worden. Hoe beter deze centra de vraag van de stakeholders kennen en hieruit gezamenlijke doelen kunnen definiëren, hoe meer partijen ook bediend kunnen worden en gemakkelijker uitvoerders voor de projecten gevonden worden. Voor deze partijen is het de uitdaging ook de kleinere bedrijven (KMO s) in de sector of het domein waar ze werkzaam zijn te betrekken, en hun noden in kaart te brengen. Hoe groter de potentiële groep stakeholders, hoe lastiger het voor deze centra is een collectieve vraag te definiëren en prioriteiten te stellen. Tenslotte hebben de centra die meer gericht zijn op het stimuleren van netwerken, een minder duidelijk gedefinieerde groep stakeholders om hen heen. Het programma is dan ook veelal een set losse projecten die rondom een groep probleemhebbers en probleemoplossers worden gedefinieerd en door hen gezamenlijk, of door een derde partij, worden uitgevoerd. Het is hierbij niet zozeer de uitdaging om de gezamenlijk vraag te articuleren als wel het aan elkaar koppelen van de juiste stakeholders en het verkrijgen van commitment. 1.2 Het programmeringsproces Dit handboek zal stapsgewijs de facetten van het vraaggedreven onderzoeksprogrammeringsproces beschrijven. Het biedt keuzemogelijkheden voor het ontwerp van het programma, voor de te betrekken stakeholders, en voor nuttige methodes om vragen, behoeften en noden te articuleren en in kaart te brengen. Deze keuzemogelijkheden zijn opgehangen aan een programmeringsmodel, een ideale weergave van de stappen die een programmerende organisatie zal moeten ondernemen om een programma te definiëren. Het handboek heeft daarbij voor een logische volgorde gekozen van de te nemen stappen, maar dit is niet perse de enige juiste volgorde. Het programmeren van onderzoek is een cyclisch proces. De volgende fasen zijn in het programmeringsproces te onderscheiden: 1 Programma afbakening; het resultaat is een beschrijving van de scope van het programma 2 Programma ontwerp; het resultaat is een programma bestaande uit projecten 3 Programma uitvoering; het resultaat zijn verschillende uitgevoerde projecten, waarvan de voortgang wordt gemonitord en waarvan de resultaten voor kennisoverdracht gebruikt worden. 4 Programma evaluatie en kennisoverdracht; het resultaat van de programma evaluatie is een evaluatierapport over het programma met heldere feedback naar een 9
eventueel vervolgprogramma, en aanbevelingen voor verbeteringen. Kennisoverdracht gaat door na afloop van het programma. De volgende figuur geeft de onderdelen van het onderzoeksprogrammeringsproces schematisch weer. De gele ruiten benoemen de hoofdprocessen van de programmeringcyclus, de bruine blokken de belangrijkste (tussen)resultaten. Kennisoverdracht valt als activiteit enigszins buiten de programmeringscyclus, maar draagt wel in belangrijke mate bij aan het realiseren van veel van de doelstellingen die de innovatieprogramma s van de VIS-partners hebben. Daarom is deze activiteit met een oranje ruit opgenomen Exhibit 1. Exhibit 1 Programmeringsproces In dit handboek ligt de nadruk ligt op de fasen programma afbakening en programma ontwerp, aangezien de VIS-partners juist in deze fasen de vraagsturing zouden willen vergroten. De andere twee fasen programma uitvoering en programma evaluatie zullen echter ook kort aan bod komen omdat deze logischerwijs verbonden zijn aan de eerder genoemde fasen. 10
1.3 Begrippen Alvorens in te gaan op de bovengenoemde fasen en mogelijkheden voor vraagsturing, volgt hier een korte beschrijving van de belangrijkste begrippen die gebruikt worden in het handboek. Onderzoeksprogramma Een onderzoeksprogramma is een verzameling onderzoeksprojecten die middels programmamanagement worden geïntegreerd en gemanaged met de intentie strategische doelstellingen te realiseren, die niet gerealiseerd zouden worden wanneer projecten afzonderlijk uitgevoerd zouden worden 2. Een programma richt zich op een bepaald probleem of een bepaalde kans, heeft (inhoudelijke) programmadoelen, en wordt gemanaged door een programma manager of programmerende organisatie/programmabureau. Een programma heeft (programma)middelen nodig om uitgevoerd te kunnen worden. De projecten worden uitgevoerd door uitvoerders. Programmalogica De basis voor programmamanagement wordt gevormd door de programmalogica: de relatie tussen het op te lossen probleem, de algemene doelstelling, de inhoudelijke doelstellingen en programma activiteiten van het programma (ook wel: interventielogica of het logical framework van het programma) Programmering(sproces) Het ontwikkelen van de programmalogica vormt een belangrijk onderdeel van het proces van programmering: het geheel van systematische activiteiten rondom het weloverwogen en doelgericht opstellen, respectievelijk tot ontwikkeling brengen van een (onderzoeks)programma. Programmeren is een iteratief proces, zodat regelmatige inventarisatie van resultaten en afstemming met strategische doelstellingen mogelijk is. Programmering beslaat verschillende fasen: programma afbakening, programma ontwerp, programma uitvoering en programma evaluatie. Gebruikers Gebruikers zijn de actoren die gewenst of ongewenst gebruik maken van kennis, technologieën en innovaties zoals bedrijven, onderzoeksinstellingen, overheden, maatschappelijke organisaties, klanten, leveranciers, consumenten, et cetera. Stakeholders Gebruikers en stakeholders zijn termen die vaak door elkaar gebruikt worden. In dit handboek wordt met stakeholders actoren bedoeld wiens belangen kunnen worden beïnvloed door de (onderzoeks)activiteiten van een organisatie of onderneming, of die 2 Hiermee is het verschil met portfolio management geduid, waarin projecten wel onafhankelijk van elkaar uitgevoerd en gemanaged worden. 11
zelf invloed op de belangen van de organisatie uitoefenen. Stakeholders is dus een breder begrip dan gebruikers. Vraaggedreven onderzoeksprogramma Een onderzoeksprogramma is vraaggericht wanneer de gebruikers uitkomsten van het programma ook als nodig en/of nuttig beschouwen. De onderzoeksprojecten zijn gericht op bepaalde doelstellingen en noden van gebruikers in een bepaald domein of sector. Vraaggedreven onderzoeksprogrammering Vraaggedreven onderzoeksprogrammering is een proces dat zoveel mogelijk rekening houdt met de noden van de gebruikers en stakeholders gedurende het programmeringsproces. De betrokkenheid van de gebruikers en stakeholders bij de programmering kan variëren van los en informeel (bijvoorbeeld in workshops) tot formeel en strikt door een financiële bijdrage (in de vorm van een lidmaatschap bijvoorbeeld). Vraaggedreven onderzoeksprogrammering kan variëren van top-down programmering (waarbij de programmerende instantie rekening houdt met de vraag maar zelf de beslissingen in het proces neemt) alswel bottom-up (waarbij de gebruikers, stakeholders en uitvoerders zelf het programma vormgeven gedurende het proces). Absorptiecapaciteit Absorptiecapaciteit is het vermogen van een bedrijf om externe informatie, die nieuw is voor het bedrijf, om te zetten in (innovatieve) producten, processen en diensten. 12
2 Programma afbakening Tijdens de programma afbakening worden globale doelstellingen en randvoorwaarden van het programma vastgesteld, en wordt een programmeringsaanpak opgesteld. Bij nieuwe organisaties valt de afbakening van het programma vaak samen met het bepalen van de missie van de nieuwe organisatie. Bij bestaande organisaties is dit een proces waarbij de ervaringen van bestaande programma s (dus volgend uit fase 4 van de programmeringscyclus: monitoring en evaluatie) worden geanalyseerd, en gekeken wordt of deze ervaringen, en/of veranderde omstandigheden en veranderde opvattingen moeten leiden tot bijstelling van programmadoelstellingen of het opzetten van een nieuw programma. In dit hoofdstuk zal eerst aandacht besteed worden aan de vijf kernvragen die gesteld kunnen worden om het programma af te bakenen. Vervolgens wordt beschreven wie de programma afbakening meestal uitvoeren en welke methoden kunnen worden ingezet om dit te doen. 2.1 Vijf kernvragen om het onderzoeksprogramma af te bakenen Basis voor de programma afbakening vormt het beantwoorden van vijf afbakeningsvragen : 6. Wat is het probleem/de kans waar het onderzoeksprogramma zich op richt? (Probleemidentificatie) 7. Welke maatschappelijke doelstelling moet het programma bereiken? (Globale doelbepaling) 8. Welke middelen zijn beschikbaar voor het programma? (middelen bepaling) 9. Welke partijen moeten de resultaten van het project gaan gebruiken? (doelgroepbepaling) 10. Wie moet de activiteiten in het programma gaan uitvoeren? (actor-bepaling) 2.1.1 Probleemidentificatie De eerste vraag bij de programma afbakening betreft het onderwerp (probleem of kans) waar het programma zich op richt. Dit onderwerp kan meegegeven zijn door een financier/opdrachtgever; het kan voortkomen uit een eerder programma; het kan gebaseerd zijn op voorstudies; et cetera. De keuze van het onderwerp is meestal vrij globaal, bijvoorbeeld: breedbandtechnologie; innovatie in de voedingsmiddelensector; logistiek. De doelstelling kan een economische of een maatschappelijke finaliteit hebben, of een combinatie van beide zijn. Bij de eerste betekent het dat de bedrijven het resultaat zullen vercommercialiseren, terwijl bij de tweede optie geen of zeer beperkte commerciële uitputting van het resultaat plaats vindt. Een voorbeeld van een competentiepool met 13
(ook) een maatschappelijke doelstelling is het MIP, dat mede als doel heeft een bijdrage te leveren aan de duurzaamheid van de Vlaamse economie. 2.1.2 Doelbepaling Een tweede activiteit om het programma af te bakenen is de vertaling van het onderwerp in een globale programma-doelstelling. Hierbij is het van belang aan te geven welk doel men wil bereiken, bijvoorbeeld competitiviteit van de Vlaamse voedingsmiddelenindustrie versterken door het gericht stimuleren en implementeren van innovatie (zoals de missie van Flanders Food luidt). Voor het verder programmeringsproces is de mate van ambitie vervolgens bepalend. Wil men Vlaanderen aan de wereldtop te brengen of heeft men juist versterking van een industriële sector in den brede voor ogen? De mate van ambitie bepaalt ook sterk wie het beste bij de programmering betrokken kunnen worden. 2.1.3 Middelen De mate waarin middelen (financieel, maar ook mankracht en expertise) beschikbaar zijn kan de vorm (en de doelstellingen) van een programma ook sterk beïnvloeden. Wanneer alleen mankracht aanwezig is, ligt het opzetten van een grootschalig onderzoeksprogramma niet in de lijn der verwachtingen. Het is dan vanzelfsprekender een programma op te zetten waarin een visie ontwikkeld wordt, die ofwel kan leiden tot het verkrijgen van middelen, of tot een programma waarin alleen aan advisering en ondersteuning gedaan wordt. De omvang van het beschikbare budget bepaalt ook in sterke mate de mogelijkheid van stakeholder betrokkenheid. Stakeholder betrokkenheid wordt alleen op een goede manier verkregen als duidelijk is wat voor ieder uit het proces te halen is. Stakeholders zullen zich alleen belangeloos inzetten of investeren in een programma/project wanneer zij een duidelijk belang bij de uitkomsten hebben. Indien helemaal geen middelen beschikbaar zijn (ook niet voor het uitvoeren van een programmeringsproces) is het zinloos verder te gaan na de programma afbakening. Het is dan verstandiger met de kleine groep mensen die de programma afbakening heeft gemaakt op zoek te gaan naar middelen bij overheid, het bedrijfsleven of elders, of om het idee voor het programma te verlaten. Beschikbaarheid van middelen voor de uitvoering van het programma kan dienen als een manier om partijen te overtuigen van hun betrokkenheid: de tijd die ze steken in het programmeringsproces kan dan gezien worden als een investering in het verkrijgen van onderzoeksbudget later. Het beschikbaar komen van middelen om het programmeringsproces te ondersteunen (voor het aanstellen van een programmamanager, voor het uitvoeren van studies e.d.) kan ook al voldoende zijn om een aantal partijen over te halen hun bijdrage te leveren, vanuit de overtuiging dat het in gang zetten van een gezamenlijk proces uiteindelijk goed is voor de individuele partijen. 2.1.4 Doelgroep Als vierde dient bij de programma afbakening ook de doelgroep of de gebruikers van het programma bepaald te worden. Wie moet uiteindelijk de resultaten van het programma gaan gebruiken? Zijn dat bijvoorbeeld alle bedrijven in een bepaalde sector; zijn dat de 14
leden van het competentiecentrum; of zijn het alleen de bedrijven uit een bepaalde regio? Al is het in deze fase nog niet noodzakelijk om de doelgroep precies te analyseren, een aantal zaken dient bekend te zijn: 1. Uit hoeveel partijen bestaat de doelgroep? (veel/weinig) 2. Hoe divers is de doelgroep? (homogeen/heterogeen) 3. Hoe hoog is de absorptiecapaciteit van de doelgroep voor innovaties? (hoog/laag) 4. Hoe open is de cultuur van de doelgroep ten aanzien van samenwerking? (open/gesloten) Bij programma s met een economische finaliteit bestaat de doelgroep (gebruikersgroep) veelal uit bedrijven. In sommige gevallen zijn ook andere stakeholders van belang, zoals onderzoeksinstellingen, consumentenorganisaties of milieuorganisaties. Dit laatste geldt zeker voor programma s met een maatschappelijke finaliteit. Hierbij speelt ook de overheid vaak een andere rol dan enkel die van financier of stimulator. 2.1.5 Uitvoerder Tot slot is het al bij de afbakening van belang om vast te stellen welk type partij het beoogde programma mogelijk kan uitvoeren. Is dit de programmerende partij zelf (zoals bij FMTC) of is het de bedoeling dat de kennisinfrastructuur (universiteiten/hogescholen/ onderzoekscentra) de projecten uitvoert? Of worden bedrijven als uitvoerder betrokken (al dan niet in consortia)? Uiteraard kunnen deze partijen ook in combinatie de projecten uitvoeren. 2.2 Wie bakenen het programma af? De programma afbakening geschiedt meestal door een kleine groep mensen met een zeker draagvlak bij de doelgroepen van het programma. Dit kan een formele rechtsvorm hebben (zoals de competentiepolen), maar vaak is er nog geen formele rechtsvorm en betreft het een echte project champion die zich omringt met opinieleiders uit de doelgroep. In een latere fase wordt dan pas de rechtspersoonlijkheid gerealiseerd (veelal als vzw), krijgen de opinieleiders een formele rol binnen Raad van Bestuur of Raad van Advies, en wordt een directeur aangesteld. Deze kan ook van buiten het oorspronkelijke projectteam komen. Concreet zullen de vijf afbakeningsvragen zoals hierboven beschreven door de volgende actoren beantwoord (kunnen) worden: 1. Project champion: bijvoorbeeld de manager/oprichter van een competentiepool, bedrijven die een oplossing voor een probleem zoeken (zoals bij Flamac het geval was), etc. 2. Opinieleiders: senioren uit bijvoorbeeld het bedrijfsleven of brancheorganisaties, leidende wetenschappers of beleidsmakers met een brede blik op kansen en problemen in de sector of het specifieke gebied, maar ook daarbuiten. 3. Consultants: externe onafhankelijke partijen met kennis van en ervaring in de sector of het specifieke veld en het verkennen van strategische kansen in sectoren, technologie- en/of wetenschapsgebieden. 15
2.3 Hoe wordt het gebruikersperspectief betrokken bij de programma afbakening? De programma afbakening is een eerste en cruciale stap voor de verdere invulling van het programma. Om te verzekeren dat de noden en vragen van de toekomstige gebruikers van de uitkomsten van het programma voldoende geïntegreerd worden in het onderzoeksprogramma, kan een aantal methodieken worden toegepast. Om mogelijke onderwerpen te verkennen kunnen state-of-the art studies, trendstudies of verkenningen worden uitgevoerd, of bestaande studies kunnen worden geanalyseerd. Daarnaast kan de programmerende organisatie na een eerste stakeholder analyse verkennende interviews 3 in het veld (laten) uitvoeren, waarbij duidelijk wordt wat de trends, kansen en bedreigingen zijn voor de verschillende stakeholders. Visionairen (uit het bedrijfsleven, onderzoek en maatschappij/beleid) zijn de belangrijkste doelgroep voor deze verkennende interviews. Zij hebben zicht op trends en toekomstige verwachtingen waar het onderzoeksprogramma op in moet spelen, en kunnen veelal ook kansen en bedreigingen benoemen waar rekening mee moet worden gehouden. Hen kan gevraagd worden wat de belangrijkste problemen (bv. in de sector) zijn, wat haalbare en wenselijke doelstellingen zijn (de top bereiken of de sector versterken) en welke partijen behoefte hebben aan een antwoord op de geïdentificeerde problemen. Daarnaast kunnen zij een eerste indicatie geven van de partijen die het meest geschikt zijn om het programma uit te voeren. Wanneer de middelen het toelaten is het aan te raden zoveel mogelijk één op één te spreken met de opinieleiders. Het voordeel van verkennende interviews is dat middels het sneeuwbal effect nieuwe opinieleiders door de interviewees aangewezen kunnen worden, wat de interviewpool vergroot. Het is ook mogelijk om een verkennende survey te doen wanneer weinig middelen beschikbaar zijn, of de lijst namen te lang is om individuele interviews te houden. Het resultaat van de interviews is een lijst met verwachtte trends, kansen, problemen en onderwerpen voor een onderzoeksprogramma. Vervolgens kan in werkgroepen of verkennende workshops gebrainstormd worden over de afbakening en scope van het programma, en dienen prioriteiten gesteld te worden betreffende het probleem waar het programma zich op richt, de maatschappelijke of economische doelstelling, de mogelijke uitvoerende actoren, en de beschikbare middelen. Een veelgebruikte methode om tot dergelijke strategische prioriteiten te komen is bijvoorbeeld het doen van een SWOT-analyse. 3 Zie voor een uitgebreide beschrijving van deze methodieken hoofdstuk 6 16
Exhibit 2 Voorbeeld van verkennende workshops: TNO programma ontwerp Op basis van de kennispositie van TNO heeft de Raad van Bestuur 12 kerngebiedoverschrijdende maatschappelijke thema s benoemd. Rondom elk van deze, top-down gedefinieerde, thema s zou vervolgens een programma geformuleerd moeten worden dat inspeelt op de noden van de maatschappelijke en industriële stakeholders van TNO. Hiervoor heeft TNO een interne adviesunit gevraagd in zogenaamde denkteam workshops verder invulling te geven aan de thema s en deze ook af te bakenen. Per maatschappelijk thema werd een sessie belegd met personen met creatieve denkkracht uit de verschillende kerngebieden van TNO. Zo werd gewaarborgd dat bruikbare kennis van elk kerngebied kon worden ingebracht. Tijdens de denkteamworkshops werd een brainstorm gehouden over de doelen die TNO zich zou moeten stellen, de meerwaarde van TNO voor het maatschappelijke thema (wat zou TNO moeten doen, en voor wie?) en de rollen die TNO daarbij zou moeten vervullen. In deze sessies werden mensen uitgedaagd buiten hun eigen expertisegebied te denken en ontstonden interessante nieuwe inzichten en ideeën. De sessies werden begeleid door een facilitator van het interne adviesteam, en vastgelegd door een rapporteur van datzelfde team. De denkteam sessies duurden elk ruim 4 uur, en werden veelal op het einde van de dag of aan het begin van de avond georganiseerd gevolgd of afgetrapt door een diner. De doorlooptijd van deze oefening was ongeveer zes weken. Het resultaat van deze activiteit om de thema s verder af te bakenen was een rapport met een korte beschrijving per thema van de huidige (technologische en maatschappelijke) ontwikkelingen, de doelen die TNO zich stelt en de meerwaarde die TNO de maatschappij te bieden heeft. Het rapport werd afgesloten met conclusies, die over de sessies heen zijn geformuleerd, en aanbevelingen over het vervolg van het strategieproces. Voor meer informatie zie de uitgebreide beschrijving van de buitenlandse casussen. 17
3 Programma ontwerp 3.1 Ontwerp issues De tweede fase in het vraaggedreven programmeringsproces is het programma ontwerp. Het eindresultaat van deze fase is een programma: een samenhangend geheel van activiteiten (projecten met daarbijbehorende projectuitvoerders), die bijdragen aan het bereiken van de programmadoelstellingen. In deze fase komen in principe dezelfde issues aan de orde als bij de programma afbakening (Exhibit 3), maar ze worden nu concreet uitgewerkt in een samenhangend geheel: De programma logica wordt ontwikkeld. In de toolbox wordt verder inzicht gegeven in het toepassen van een zogenaamde logical framework analyse om een programma te ontwikkelen en de uitkomsten te evalueren. Exhibit 3 Issues bij programma ontwerp Programma afbakening Programma ontwerp Probleem Wat is het probleem/de kans waar Welke thema s kunnen worden onderscheiden? het programma zich op richt? Doel Welke maatschappelijke doelstelling moet het programma bereiken Hoe wordt de algemene maatschappelijke doelstelling waarop het programma zich richt vertaald in concrete programmadoelstellingen? Activiteiten/projecten - Hoe worden de programmadoelstellingen vertaald in programma activiteiten, zo dat het collectief belang gewaarborgd blijft? Middelen Welke middelen zijn beschikbaar Welke middelen worden besteed aan elke Uitvoerder Stakeholderanalyse en betrokkenheid voor het programma? Welk soort partij is beoogd om de activiteiten in het programma te gaan uitvoeren? Welke partijen moeten de resultaten van het programma gaan gebruiken? activiteit? Welke partij gaat elke activiteit uitvoeren? Op welke (sub)doelgroep is iedere activiteit gericht en wat zijn de kenmerken van deze stakeholders? Indicatoren - Op welke wijze is het succes van het programma te meten? Er zijn verschillende wijzen waarop deze issues kunnen worden uitgewerkt. Ook de volgorde ligt niet vast, noch de manier waarop de verschillende stakeholders worden betrokken bij het programma ontwerp. Het proces van programmeren is nu eenmaal niet lineair. In de praktijk blijkt het voor een goed programma wel noodzakelijk dat alle issues worden meegenomen in het programma ontwerp. Onderstaande paragrafen gaan hierop in. Begonnen wordt met een paragraaf over identificatie van de stakeholders, immers, geen gebruikersgerichte programmering zonder gebruikers. De paragraaf die daarop volgt (programma-invulling) had echter ook als eerste beschreven kunnen worden. Het wezen van gebruikersgeoriënteerde programmering is juist dat interactie met gebruikers optreedt in het programmeringsproces. 18
3.2 Stakeholders 3.2.1 Stakeholder identificatie en analyse Het veronderstelde voordeel van het betrekken van stakeholders bij de programmering van een innovatieprogramma is, dat daardoor de resultaten van het programma beter bruikbaar voor de stakeholders worden. Vraaggestuurd programmeren richt het programma op de belangen van de stakeholders. Identificatie van de stakeholders en hun (gezamenlijke) belang is dus een belangrijke stap in de programmering. Wanneer dit gezamenlijk belang bekend is, kunnen de activiteiten/projecten in het programma sterk gefocused worden. Bij de programma afbakening is het gezamenlijke belang meestal nog niet dusdanig concreet dat hierop een programma kan worden gebaseerd. Nadere stakeholderanalyse dient dus ook in de programma ontwerpfase plaats te vinden. Een stakeholderanalyse kan op verschillende manieren en momenten plaats vinden. Het doen van een stakeholderanalyse wordt ook in de toolbox in hoofdstuk 6 beschreven. De analyse van de noden en vragen van stakeholders kan zonder of met de betreffende partijen gedaan worden: 1 Een top-down benadering: zonder de stakeholders direct te betrekken vaststellen wat de behoeften van de doelgroep zijn. Dit kan nog steeds een vraaggedreven programma opleveren, maar de vraag is dan een verwachtte vraag. Dit leidt relatief gemakkelijk tot een samenhangend programma, maar minder tot breed gedragen uitkomsten. 2 Een directe benadering bijvoorbeeld middels een enquête, brokerage, conferentie of een individuele benadering van alle leden van de doelgroep, waarin je de geïnteresseerde partijen benadert en hun visie vraagt. In een iteratief proces kan de programmerende instantie de doelgroep verkleinen en een steeds directere aanpak kiezen met een steeds intensiever contact met de doelgroep. Beide manieren kunnen elkaar ook aanvullen. Voor een programma met als globale doelstelling het behalen van de wereldtop, kunnen alle bedrijven uit die sector direct benaderd worden, maar men kan ook eerst aan een expert vragen welke bedrijven mogelijk die wereld top potentie hebben. Vervolgens kunnen deze bedrijven direct benaderd worden en hun eventuele interesse in het programma aangeven. De vraagstelling aan de stakeholders kan issuegericht zijn en kansen en problemen verkennen. Typische vragen zijn bijvoorbeeld: Welke problemen worden door u ondervonden? Welke ontwikkelingen vindt u belangrijk? De vraagstelling kan ook projectgericht zijn en leiden tot clustering van vergelijkbare projecten. Een typische vraag is bijvoorbeeld: Wat voor ideeën heeft u voor gezamenlijke onderzoeksprojecten?. 19
Het voordeel van een issuegerichte benadering is de grotere diepgang: deze gaat in op problemen, waardoor er meer ruimte ontstaat voor het delen van problemen en het kweken van vertouwen tussen partijen onderling. Bij een projectgerichte benadering komt men vaak sneller tot concrete projecten, maar betaat de kans om (te) snel naar voor de hand liggende oplossingsroutes te springen (jump-to-solutions). Het out-of-the-box denken komt daardoor moeilijker naar voren in de discussie. De verschillen tussen beide benaderingen zijn meestal niet heel groot. Wanneer bedrijven gevraagd is op 1 A4 input te leveren, worden vaak zowel issues als ideeën genoemd. 3.2.2 Omgaan met sterk verschillende belangen Wanneer uit analyse van de stakeholders blijkt dat deze een algemeen gezamenlijk belang delen, is het mogelijk het programmeringsproces met alle stakeholders te doorlopen. Wanneer de belangen erg uiteenlopen is het realiseren van een gezamenlijk programma waar iedereen achter staat moeilijk, en om te voorkomen dat een programma met wenig samenhang of weinig draagvlak ontstaat dient een proces ingezet te worden met de stakeholders. Hiervoor zijn verschillende mogelijkheden: Homogeniseren: middels inhoudelijke exercities (delphi studies, roadmaps, foresight studies, etc.) de doelen van de doelgroep dichter bij elkaar brengen, of bij hen de perceptie doen doorbreken dat ze wel gezamenlijke belangen hebben, waarna collectieve wensen voor een programma makkelijker vastgesteld kunnen worden. Verbreden: De doelstelling van het programma verbreden. Hierdoor betrekt men wel een grotere groep stakeholders maar krijgt men uiteindelijk minder samenhang in het programma. Segmenteren (zie het voorbeeld in Exhibit 4): De doelstelling splitsen in een aantal subdoelstellingen (waarvoor per doelstelling wel gezamenlijke belangen belangen bij de stakeholders te vinden zijn) en in plaats van één integraal programma meerdere subprogramma s ontwikkelen. Selecteren: Het programma richten op de belangen van slechts een gedeelte van de stakeholders met als resultaat een kleinere doelgroep. Wanneer een gezamenlijk belang niet of moeilijk te identificeren is, kan eventueel overgegaan worden tot een open programma oproep. Hierbij wordt aan de stakeholders - hoewel je in zo n geval de vraag kunt stellen wat de stake is- gevraagd om uitgewerkte projecten in te dienen, waaruit dan vervolgens een keuze wordt gemaakt via een beoordelingsprocedure. In dit verband wordt vaak het onderscheid gemaakt tussen generieke en specifieke programma s. Bij een specifiek programma kent de uiteindelijke programma oproep zeer specifiek omschreven programmadoelstellingen (déze projecten gaan wij doen). Bij een generiek programma worden de programmadoelstellingen juist algemeen geformuleerd (projecten moeten liggen op het volgende terrein en/of bijdragen aan het bewerkstelligen van deze veranderingen). Het onderscheid tussen generiek en specifiek is echter niet heel absoluut en vele tussenvormen zijn mogelijk (zie Exhibit 5). 20