Wanneer een documenttype wordt gewijzigd (waneer b.v. een nieuwe kolomnaam wordt toegevoegd), zullen de wijzigingen niet in de hierop gebaseerde SharePoint Designer workflow zichtbaar zijn.
Gelukkig biedt Designer de optie "Copy and Modify" om op basis van de bestaande workflow een nieuwe te maken waarin het aangepaste ContentType weer kan worden geselecteerd. Hierin worden de eigenschappen van de nieuwe versie van het ContentType beschikbaar gesteld.
zaterdag 9 april 2011
donderdag 31 maart 2011
Versie management: primaire en secundaire versies
Weleens een versienummer gezien in de vorm van 1.2?
Hierbij wordt een versienummer aangegeven bestaand uit twee versies:
- Primaire versie, in het bovenstaande voorbeeld: 1
- Secundaire versie, in het bovenstaande voorbeeld: 2
Een primaire versie is een belangrijke versie, bijvoorbeeld een document die gepubliceerd wordt of door meerdere mensen wordt bekeken. Secundaire versies zijn vaak concept versies waar individuele gebruikers mee bezig zijn.
Bijhouden van zowel primaire als secundaire versies draagt bij aan de versiegeschiedenis van een document. In de versiegeschiedenis van een document kunnen de versienummers iets vertellen over het ontstaan en het onderhoud van het betreffende document.
Een document wordt standaard met een nieuw secundair versienummer opgeslagen tenzij dit door de gebruiker anders wordt aangegeven, en het betreffende document wordt gepubliceerd of ingechecked.
Gebruik van versies
Iedere primaire versie kan 511 secundaire versies bevatten. Dit aantal is te beperken door de site beheerder.
Een secundaire versie kan door een andere secundaire versie worden overschreven.
Van een primaire versie kan een secundaire versie worden gemaakt.
Hierbij wordt een versienummer aangegeven bestaand uit twee versies:
- Primaire versie, in het bovenstaande voorbeeld: 1
- Secundaire versie, in het bovenstaande voorbeeld: 2
Een primaire versie is een belangrijke versie, bijvoorbeeld een document die gepubliceerd wordt of door meerdere mensen wordt bekeken. Secundaire versies zijn vaak concept versies waar individuele gebruikers mee bezig zijn.
Bijhouden van zowel primaire als secundaire versies draagt bij aan de versiegeschiedenis van een document. In de versiegeschiedenis van een document kunnen de versienummers iets vertellen over het ontstaan en het onderhoud van het betreffende document.
Een document wordt standaard met een nieuw secundair versienummer opgeslagen tenzij dit door de gebruiker anders wordt aangegeven, en het betreffende document wordt gepubliceerd of ingechecked.
Gebruik van versies
Iedere primaire versie kan 511 secundaire versies bevatten. Dit aantal is te beperken door de site beheerder.
Een secundaire versie kan door een andere secundaire versie worden overschreven.
Van een primaire versie kan een secundaire versie worden gemaakt.
donderdag 24 maart 2011
Praktisch aan de slag met SharePoint: workshops en labs
”Tell me, and I will forget
Show me, and I will remember
Involve me, and I will understand
Let me do it myself and I will truly know how it works”
[Chinees gezegde, aangevuld met modern inzicht]
SharePoint is een kwestie van "doen". Een cursus of training volgen is natuurlijk een eerste stap, maar als het geleerde niet in de praktijk wordt gebracht, is het zonde van het geld en de moeite. SharePoint is ook een kwestie van "samen doen"; samen oefenen, samen leren, samen bedenken hoe SharePoint het beste in de praktijk kan worden toegepast en samen contact houden om in de praktijk elkaar te vinden om kennis en ervaring uit te blijven wisselen.
In de praktijk heeft HansR stevige ervaring met het organiseren en vullen van workshops en handson labs. Voor de eigen organisatie en voor klanten en partners heeft hij diverse workshop reeksen en handson labs georganiseerd.
Interesse om dit binnen uw organisatie te laten organiseren? Neem contact op met HansR, HansRontheWeb@live.com.
donderdag 10 maart 2011
Keuzelijsten in metadata velden: keuzelijsten, externe lijsten of standaard lijsten?
Voor metadata velden in lijsten en bibliotheken kunnen keuzelijsten gebruikt worden. Denk hierbij bijvoorbeeld aan een metadata veld dat vaste waarden als Afdelingsnaam of DocumentStatus bevat.
Hiervoor zijn de volgende mogelijkheden:
- Gebruik maken van vaste lijsten, b.v. gebruikersgegevens
- Gebruik van keuzelijsten die gedefinieerd worden bij het veld zelf (zie bibliotheek of lijst instellingen)
- Gebruik maken van de waarden in een externe lijst
Wanneer meerdere lijsten en/of bibliotheken gebruik maken van dezelfde keuzelijsten, is het verstandig om de waarden hiervan vast te leggen in een aparte centrale lijst en hiervan in een keuzeveld gebruik te maken. Wanneer keuze waarden veranderd moeten worden, kan dat in deze centrale lijst gebeuren.
Zijn er reeds standaard lijsten beschikbaar, zoals gebruikersgegevens, gebruik deze dan en maak niet zelf aparte lijsten of keuzelijsten aan met daarin zelfingevoerde namen. De standaard lijsten, als gebruikersgegevens, kunnen actueel aangenomen worden en zijn dus van grotere waarden dan zelf opgestelde en zelf te onderhouden lijsten.
Let op:
Gebruik van zelf in te vullen waarden bij keuzelijsten is in veel gevallen af te raden. Het kan zorgen voor vervuiling van deze lijsten en vormt daarom een gevaar voor de standaardisatie van meta data.
SharePoint 2010: Taxonomieen:
In SharePoint 2010 kunnen, op organisatieniveau, taxonomieen worden gedefinieerd die als basis kunnen dienen voor keuzevelden.
Wat is een taxonomie? Een boomstructuur waarin een vaste indeling van trefwoorden is gedefinieerd, b.v. regio's, landen, provincies. Zie ook: Wikipedia: Taxonomie.
Hiervoor zijn de volgende mogelijkheden:
- Gebruik maken van vaste lijsten, b.v. gebruikersgegevens
- Gebruik van keuzelijsten die gedefinieerd worden bij het veld zelf (zie bibliotheek of lijst instellingen)
- Gebruik maken van de waarden in een externe lijst
Wanneer meerdere lijsten en/of bibliotheken gebruik maken van dezelfde keuzelijsten, is het verstandig om de waarden hiervan vast te leggen in een aparte centrale lijst en hiervan in een keuzeveld gebruik te maken. Wanneer keuze waarden veranderd moeten worden, kan dat in deze centrale lijst gebeuren.
Zijn er reeds standaard lijsten beschikbaar, zoals gebruikersgegevens, gebruik deze dan en maak niet zelf aparte lijsten of keuzelijsten aan met daarin zelfingevoerde namen. De standaard lijsten, als gebruikersgegevens, kunnen actueel aangenomen worden en zijn dus van grotere waarden dan zelf opgestelde en zelf te onderhouden lijsten.
Let op:
Gebruik van zelf in te vullen waarden bij keuzelijsten is in veel gevallen af te raden. Het kan zorgen voor vervuiling van deze lijsten en vormt daarom een gevaar voor de standaardisatie van meta data.
SharePoint 2010: Taxonomieen:
In SharePoint 2010 kunnen, op organisatieniveau, taxonomieen worden gedefinieerd die als basis kunnen dienen voor keuzevelden.
Wat is een taxonomie? Een boomstructuur waarin een vaste indeling van trefwoorden is gedefinieerd, b.v. regio's, landen, provincies. Zie ook: Wikipedia: Taxonomie.
maandag 7 maart 2011
Motiveren, hoe doe ik dat?
Motiveren doen we al decennia op dezelfde wijze. Dat dit niet altijd even doeltreffend en doelmatig is, blijkt regelmatig. Onderstaande video's geven een alternatieve, verfrissende blik op motivatie. Insprirerend en zeer bruikbaar in SharePoint projecten of collaboration platform projecten in het algemeen. Het gaat daarin vaak mensen die gevraagd wordt het "dagelijks werk" anders te doen, samen te werken zonder daarvoor een directe beloning te krijgen. Er kan zelfs sprake zijn van een ware cultuurverandering. Reden genoeg om eens te kijken of er doeltreffender en doelmatiger manieren zijn om de gebruikerscommunity "in beweging te krijgen".
Daniel Pink on the surprising science of motivation (Engels)
De presentatie van Daniel Pink ligt in lijn met onderzoek dat is gedaan op het gebied van Bloggen: meer vrijheid maakt produktiever.
Bloggen maakt produktiever
Bron: Bloggend personeel is productiever, en het originele artikel: Personal Blogging at Work Increases Productivity.
Vrijheid op het werk motiveert blijkbaar tot het leveren van betere individuele prestaties en verbetert het communiceren hierover, hetgeen samenwerken bevordert, wat weer een positieve invloed heeft op het groepsresultaat (lees: bedrijfsresultaat).
Bovenstaande deed me denken aan de al in 1943 door Abraham Maslow gepubliceerde piramide waarin de hiërarchische ordening van behoeften wordt weergegeven (zie: Piramide van Maslow).
De in de piramide genoemde "Hogere fundamentele behoeften" (bovenste 3):
1. Behoefte aan saamhorigheid, behoefte aan vriendschap, liefde en positief-sociale relaties;
2. Behoefte aan waardering, erkenning en zelfrespect, die de competentie en het aanzien in groepsverband verhogen; het belang hechten aan de status in sociaal verband;
3. Behoefte aan zelfverwerkelijking of zelfactualisatie,
lijken te drivers te zijn van de successen die vrijheid, zelfexpressie en de daaruitvolgende samenwerking.
Stof tot nadenken, lijkt me, (ruim) voordat u aan uw SharePoint implementatie begint.
Daniel Pink on the surprising science of motivation (Engels)
De presentatie van Daniel Pink ligt in lijn met onderzoek dat is gedaan op het gebied van Bloggen: meer vrijheid maakt produktiever.
Bloggen maakt produktiever
"Volgens deze academische studie helpt schrijven op een online bedrijfsblog of forum werknemers dichter bij elkaar te komen en goede relaties op te bouwen. Daarnaast verhoogt het na verloop van tijd zelfs de productiviteit."
Bron: Bloggend personeel is productiever, en het originele artikel: Personal Blogging at Work Increases Productivity.
Vrijheid op het werk motiveert blijkbaar tot het leveren van betere individuele prestaties en verbetert het communiceren hierover, hetgeen samenwerken bevordert, wat weer een positieve invloed heeft op het groepsresultaat (lees: bedrijfsresultaat).
Bovenstaande deed me denken aan de al in 1943 door Abraham Maslow gepubliceerde piramide waarin de hiërarchische ordening van behoeften wordt weergegeven (zie: Piramide van Maslow).
De in de piramide genoemde "Hogere fundamentele behoeften" (bovenste 3):
1. Behoefte aan saamhorigheid, behoefte aan vriendschap, liefde en positief-sociale relaties;
2. Behoefte aan waardering, erkenning en zelfrespect, die de competentie en het aanzien in groepsverband verhogen; het belang hechten aan de status in sociaal verband;
3. Behoefte aan zelfverwerkelijking of zelfactualisatie,
lijken te drivers te zijn van de successen die vrijheid, zelfexpressie en de daaruitvolgende samenwerking.
Stof tot nadenken, lijkt me, (ruim) voordat u aan uw SharePoint implementatie begint.
zondag 6 maart 2011
IS Lite en Open Source Governance als basis voor Enterprise 2.0 governance
Inleiding
De laatste jaren dringen steeds meer webtoepassingen door in bedrijven en organisaties. Toepassingen die onder de paraplu “Enterprise Web 2.0” vallen, vormen het onderwerp van dit artikel.
Enterprise Web 2.0 toepassingen omvatten de software [1]:
1. Enterprise search: vinden van mensen, functionaliteit en informatie;
2. Authoring & sharing: blogs, wikis, collaboration platforms;
3. Social bookmarking, recommendation, tagging, signaling;
4. Delen en verspreiden van informatie en functionaliteit: mashups.
Samengevat kunnen deze toepassingen worden omschreven als software assets voor “Vinden, delen en samenwerken”.
Het alom aanwezige internet, ook binnen organisaties beschikbaar, samen met de ontwikkeling van platforms waarmee dergelijke software assets snel en relatief eenvoudig gemaakt kunnen worden, en de populariteit van deze software assets, maakt dat bedrijven en organisaties niet meer om deze software heen kunnen. Op de een of andere wijze worden organisaties hiermee geconfronteerd.
Stelling: IS Lite + Open Source Governance biedt een goede basis voor Enterprise 2.0 assets
In de onderstaande tekst wil ik de stelling onderbouwen dat IS Lite, aangevuld met Open Source governance concepten, een goede basis biedt voor governance van Enterprise Web 2.0 assets.
Kenmerken en beloften van Enterprise Web 2.0 software assets
Enterprise Web 2.0 software assets bieden, in combinatie met het internet, een aantal grote voordelen, maar ook een aantal risico’s.
Voordelen en nadelen zorgen ervoor dat organisaties in eerste instantie niet
staan te springen om ermee aan de slag te gaan.
De voordelen van dergelijke assets zijn de gemakkelijke verspreidbaarheid, toegankelijkheid en herbruikbaarheid. Een software asset kan in principe door een zeer groot publiek worden gebruikt en hergebruikt, waardoor het aantal klanten (gebruikers) van een organisatie zeer snel toeneemt. Als voorbeeld kunnen RSS feeds genoemd worden waarmee nieuws zeer snel op verschillende sites kan worden verspreid. Ook assets voor e-commerce functionaliteit (software assets, webservices, waarmee online verkoop van artikelen kan worden gerealiseerd, kan zorgen voor een enorme toename van potentiële klanten en daarmee, van verkoop. Assets waarmee communicatie wordt ondersteund (micro blogging, discussie groepen, chatrooms) bieden informele groepen uitstekende mogelijkheden om kennis en ervaring uit te wisselen, zich te organiseren en zodoende invloed uit te oefenen. En deze “informele groepen” kunnen in de toekomst een formele juridische status krijgen waarmee deze invloed alleen nog maar groter wordt [8].
Binnen organisaties belooft toepassing van Enterprise Web 2.0 software assets, vooral van wiki’s, blogs en collaboration platforms, een betere communicatie en samenwerking tussen medewerkers en een betere kennisdeling en –overdracht.
De bovenstaande beloften komen in de praktijk vaak niet uit.
Dit is niet zozeer te wijten aan de technische mogelijkheden, maar aan de
verwachtingen die gesteld worden aan deze nieuwe technologieën.
"Install and expect" is de meest gemaakte fout bij de aanschaf of introductie van Enterprise Web 2.0 software assets. Daarnaast worden van Enterprise Web 2.0 software assets ook gezien als een dreiging, omdat “controle” over communicatie, klanten en eigen medewerkers verloren zou gaan.
Goede governance van de productie, de inzet, het beheer en het gebruik van Enterprise Web 2.0 software assets is van cruciaal belang om optimaal te kunnen profiteren van de technische mogelijkheden en met de risico’s te kunnen omgaan.
Dit vergt een zekere vorm van volwassenheid van de organisatie om met Enterprise Web 2.0 software om te kunnen gaan [10].
Verschillen met klassieke software
Om een beeld te krijgen van wat nodig is voor de governance van Enterprise Web 2.0 software assets kan een vergelijking gemaakt worden van goverance van "klassieke" software en "Enterprise Web 2.0 software". Hierbij wordt onderscheid gemaakt tussen planning, ontwikkeling, beheer, productie en gebruik.
Wat opvalt is dat de grote verschillen tussen governance van klassieke software en Enterprise Web 2.0 software temaken heeft met controle, of liever gezegd, met het verlies van controle over Enterprise Web 2.0 software. Bij klassieke software wordt risicomijdend gepland, worden formele opleveringen gedaan op basis van vantevoren gestelde eisen en wensen. Beheer wordt belegd bij een partij waarmee formele afspraken worden gemaakt over dienstverlening. Klassieke software kan vaak maar op een manier worden gebruikt terwijl en aanpassingen aan software weer via een formele procedure verlopen, waarbij slechts een kleine groep invloed heeft.
Bij Enterprise Web 2.0 software assets, echter, liggen veel zaken niet vast. Sterker nog; veel zaken zijn variabel, flexibel en aan (veel) verandering onderhevig.
Allereerst wordt bij dergelijke software uitgegaan van een flexibele set software assets waarvan de assets los van elkaar, maar ook in combinatie gebruikt kunnen worden. Voorbeelden hiervan zijn: mashups en webonderdelen in collaboration platforms.
Voorts heeft de eindgebruiker (de klant) heel veel invloed op de ontwikkeling van deze applicaties, het beheer ervan en het gebruik ervan.
Vaak kunnen gebruikers zelf applicaties (b.v. sites) samenstellen, configureren, de look and feel veranderen en nemen ze ook een deel van het beheer op zich. Daarmee bepalen ze ook in belangrijke mate hoe er gebruik wordt gemaakt van de software en bepalen ze daarmee ook waarover en hoe gecommuniceerd wordt. En daarmee is (bedoeld of onbedoeld) misbruik van software assets een realiteit [2]
De bovenstaande flexibiteit wordt bovendien nog aangevuld met een belangrijke mate van verandering; software assets kunnen eenvoudig worden vervangen voor andere en op het internet ontstaan voortdurend nieuwe software assets waarvan snel en gemakkelijk gebruik kan worden gemaakt. De snelheid waarmee microblogging aan populariteit heeft gewonnen, zowel buiten als binnen organisaties, is hiervan een goed voorbeeld. Ook de snel rijzende en dalende populariteit van Second Life is hier een goed voorbeeld van. Het lijkt wel alsof software aan modegrillen onderhevig is.
Door deze snelle veranderingen is het lastig goede gerichte investeringen te doen in software waarmee vastgestelde business doelen bereikt moeten worden. Daarnaast is het lastig het succes van software te meten. Van ieder nieuw concept moet immers bepaald worden op welke wijze succes gemeten wordt en wanneer sprake is van succes [3].
Samengevat bestaat het risico dus uit:
1. Verlies van grip op productie, beheer en gebruik;
2. Beperkt aanpassingsvermogen aan de klant zodat de aansluiting van oplossing(en) op de behoefte(n) van de klant verloren gaat.
In de praktijk blijken deze risico’s inderdaad te leiden tot teleurstellingen:
“We hebben geen controle over wat ze over ons zeggen op internet”
“Ons collaboration platform is een grote chaos; iedereen doet maar wat”
“Onze medewerkers worden via LinkedIn bij ons weggelokt”
Globale requirements aan governance van Enterprise Web 2.0 software
Uit de risico’s volgen ook de globale requirements die aan governance van deze software assets gesteld kunnen worden. Het moet de organisatie de mogelijkheid geven om de klant goed te kunnen volgen en doeltreffend en doelmatig te kunnen reageren op de steeds veranderende eisen.
Daarnaast zal er voldoende invloed uitgeoefend moeten kunnen worden op het gebruik van de software assets zodat ze doeltreffend en doelmatig ingezetworden ten behoeven van de business.
IT Lite: een eerste basis
IS Lite [4] lijkt een goede basis te zijn voor governance van Enterprise Web 2.0 software. IS Lite is ontstaan uit een aantal trends:
1. Process-based werken;
2. Outsourcing;
3. Gespecialiseerde Centers of Excellence;
4. IT gedecentraliseerd in business units.
Dit allemaal om snel te kunnen reageren op veranderingen in de markt en ICT goed te kunnen aansluiten op business behoeften.
Voor governance van Enterprise Web 2.0 software zou het zelf ontwikkelen van assets binnen business units ervoor kunnen zorgen dat assets optimaal worden afgestemd op de behoeften van de klant. Daarnaast zou de centrale ICT afdeling ervoor kunnen zorgen dat kennis van en ervaring met assets over de hele organisatie wordt gedeeld en dat hiervan iedere business unit profiteert. Ontwikkelde assets zouden aan de “infrastructuur” (hardware, software, Enterprise Web 2.0 platforms) kunnen worden toegevoegd en worden beheerd door de partij waaraan dit geoutsourced is.
Competence Center (CC) vs Center of Excellence (CoE)
Een Competence Center (CC) wendt Change Management strategieën aan om stabiliteit van systeem en business te (her)bereiken. De werkzaamheden van een Competence Center zijn daarom reactief van aard; er wordt actie ondernomen op basis van vragen / wensen vanuit de business. Een Center of Excellence (CoE, kwaliteitscentrum, kenniscentrum of expertisecentrum) streeft naar samenwerking in en met de business in een bepaald kennisgebied om zo concurrentie voordeel te behalen. Een Center of Excellence is daarom proactief; er wordt actief gezocht naar manieren om technologie en resources toe te passen om waarde proposities en de concurrentiedruk voortdurend het hoofd te bieden.
Een Center of Excellence kan zorg dragen voor een actieve verspreiding van kennis en ervaring en begeleiding van business units bij het ontwikkelen en verspreiden van assets. Daarnaast verzorgt het Center of Excellence voor een centrale roadmap waarin alle huidige en toekomstige ontwikkelingen in de tijd zijn uitgezet. Deze dient als leidraad voor alle decentrale IT units [9].
Kanttekeningen bij IS Lite voor governance van van Enterprise Web 2.0
software
In de realiteit blijkt IS Lite niet geheel te worden uitgerold [4] [7].
Redenen hiervoor zijn:
1. De economische teruggang waardoor ICT eerder gecentraliseerd wordt dan gedecentraliseerd binnen de business units wordt geïmplementeerd (gedecentraliseerde ICT is doorgaans nueenmaal duurder);
2. Een weerstand tegen verandering van ICT omdat IT Lite andere competenties vereist dan de gangbare.
Daarnaast blijkt een verandering naar IT Lite een langdurig traject te zijn dat meerdere jaren doorlooptijd kost.
Bovenstaande belemmeringen kunnen uit de weg worden genomen door niet de gehele organisatie met IS Lite te laten werken, maar dit te beperken tot organisatie eenheden die meteen profijt hebben van de voordelen en waar vanuit gemakkelijk andere organisatieonderdelen kunnen worden geïnspireerd hetzelfde te doen. Voorbeelden hiervan zijn: communicatie, project-office (assets voor interne samenwerking) en HRM.
IS Lite biedt de mogelijkheid om goed te “luisteren” naar de omgeving, de klanten en de partners en hierop gericht te reageren. Alleen luisteren, echter, is niet voldoende, ook invloed moet worden uitgeoefend om ervoor te zorgen dat assets worden gebruikt om de business doelstellingen optimaal te ondersteunen. Daarbij is het van belang dat de verschillende gebruikerscommunities een actieve bijdrage doen aan het succes van de assets. Het Center of Excellence zal daarom een manier moeten vinden om de gebruikerscommunities te activeren.
En dat gebeurt niet zomaar…
Open Source governance: een aanvulling op IT Lite
Het speelveld waarin Enterprise Web 2.0 software wordt geproduceerd, beheerd en (her)gebruikt heeft veel overeenkomsten met Open Source communities. Net zoals bij Enterprise Web 2.0 software wordt Open Source software snel en gemakkelijk verspreid en hergebruikt en brengt dit ook risico’s van verkeerd gebruik en zelfs misbruik met zich mee. En ook hierbij hebben we temaken met communities van relatief onafhankelijke leden die de vrijheid en flexibiliteit in het (her)gebruik optimaal benutten.
Afspraken voor de ontwikkeling en gebruik zijn ook hierbij van groot belang voor het succesvol zijn van de software.
In Open Source communities waarbij een leverancier een rol speelt, draagt de community aan de ene kant bij aan het succes van software van de leverancier en aan de andere kant draagt de leverancier actief bij aan het succesvol gebruiken van software door de community. Daarbij wordt impliciet controle ingebouwd op het gebruik van de software.
Deze controle kan de vorm hebben van:
1. Regelgeving, richtlijnen en begeleiding bij het (her)gebruiken van assets;
2. Ontwikkelen van juridische expertise wanneer het gaat om software assets waarvan het gebruik aan formele regelgeving onderhavig is;
3. Inventariseren, volgen en begeleiden van open source projecten waarbij gelet wordt op gebruik, hergebruik, aanpassingen en distributie van software assets;
4. Een interne Open Source community om richting te geven te geven aan de ontwikkelingen en verspreiding van assets.
Open Source governance toegepast op IS Lite governance van Enterprise Web 2.0 software assets
De bovenstaande ervaringen kunnen toegepast worden op de IS Lite governance van Enterprise Web 2.0 software assets zoals die hiervoor besproken zijn.
Om dit toe te passen kunnen we iets dieper ingaan op de verschillende stakeholders die betrokken zijn bij de ontwikkeling, het (her)gebruik en het beheer van assets, en de relaties tussen deze stakeholders.
De business
De business: bepaalt de functionaliteit van de assets die ontwikkeld moeten worden en bepaalt welke assets toegevoegd moeten worden aan de infrastructuur (platformen en asset bibliotheken die aan de communities beschikbaar worden gesteld). De business is daarmee verantwoordelijk voor de afstemming van ICT op de businessdoelen [9], krijgt richtlijnen en nieuwe ideeën van het Centrale ICT / Enterprise 2.0 Center of Excellence en geeft ideeën vanuit de communities door aan de locale en centrale IT afdeling / Center of Excellence.
Centrale ICT / Enterprise 2.0 Center of Excellence
Centrale ICT / Enterprise 2.0 Center of Excellence bepaalt de overall architectuur en stemt dit af in samenspraak met de business.
Uitgebreid met een Open Source Program Office en een Review Board waarin ook
vertegenwoordigers vanuit de business plaatsnemen, kan het Center of Excellence
zorgen voor een continue stroom van nieuwe assets die vanuit de communities
worden aangeboden.
De lokale ICT afdeling
Ontwikkelt actief assets op basis van de communities binnen hun klanten en partnerkring. Daarnaast worden communities actief begeleid in het (her)gebruiken van assets. Hierbij spelen het beschikbaar stellen van nieuwe assets, prototypes, tools, richtlijnen en advies aan de communities een belangrijke rol. Communityleden worden tevens gemotiveerd om nieuwe ideeën en assets ter review aan het Center of Excellence aan te bieden en daarmee de gezamenlijke infrastructuur te verrijken. Gebruik van de assets wordt geanalyseerd en de doeltreffendheid ervan bepaald om de business houvast te geven assets te specificeren die (nog) beter aansluiten op de behoefte van de communities, die de businessdoelen (nog) beter ondersteunen en die de
organisatie een beter concurrentie voordeel geven.
Outsourcing partner
Beheert de infrastructuur, neemt nieuwe assets op in de infrastructuur en geeft proactief advies over doeltreffender en doelmatiger gebruik van deze infrastructuur.
De communities
(Her)gebruiken assets om hun eigen businessdoelen te ondersteunen. Geven in ruil voor de begeleiding en het beschikbaar stellen van de infrastructuur met gedeelde assets een bijdrage in de vorm van feedback, nieuwe ideeën en eigen ontwikkelde assets die, na review, kunnen worden toegevoegd aan de gezamenlijke infrastructuur.
Op bovenstaande wijze wordt een ecosysteem tot stand gebracht waarin alle stakeholders hun eigen doelen kunnen realiseren en daarbij door de andere stakeholders worden ondersteund. Voor de business kan hiermee het doel worden bereikt om, naast goed te kunnen luisteren en snel en doeltreffend in te kunnen spelen op veranderende eisen vanuit de communities, ook daadwerkelijk invloed word uitgeoefend op het (her)gebruik van assets binnen deze communities.
Kantttekeningen bij IS Lite en Open Source governance toegepast op Enterprise
Web 2.0 assets
Bovenstaande opzet is natuurlijk een grove schets van hoe governance voor Enterprise Web 2.0 assets ingericht kan worden. De werkelijkheid zal verfijning vereisen. Een aantal kanttekeningen kunnen op dit moment algemaakt worden:
1. Inzet van Enterprise Web 2.0 assets binnen de organisatie verschilt van inzet van deze assets erbuiten. Interne communities zijn in het algemeen kleiner en assets worden hier veelal gebruikt om samenwerking en kennisdeling te ondersteunen. Hierbij is een “culture of sharing” noodzakelijk [6]; blindelings vertrouwen in software alleen staat in de praktijk garant voor een teleurstelling (“install and expect” is een veelgemaakte fout).
2. Risico zal nooit geheel uitgesloten zijn. Het is nueenmaal een gegeven dat controle over infrastructuur, beheer en (her)gebruik van assets voor een belangrijk deel buiten de organisatie wordt geplaatst en dit als gevolg heeft dat de organisatie zelf een deel van de controle verliest.
Dit brengt risico met zich mee. Dit risico kan echter opwegen tegen de voordelen die het heeft om met een veel groter publiek “samen te werken” [2].
3. (Her)gebruik van Enterprise Web 2.0 assets is een ontwikkeling die niet meer tegen te houden is. Het is beter dit te accepteren en er gebruik van te maken dan deze ontwikkeling te negeren en de boot te missen.
4. Ofschoon inzet van IS Lite en Open Source governance niet meteen in de gehele organisatie hoeft te worden uitgerold is het wel van belang dat men, vanaf de werkvloer tot en met het topmanagement, hierachter staat. Immers, omdat deze ontwikkelingen niet tegen zijn te houden, daarom risico’s genomen moeten worden, en het Enterprise Web 2.0 concept in een later stadium in de gehele organisatie moet worden uitgerold, zal het management ook in tegenspoed deze ontwikkeling moeten steunen. De CIO zou zich in zekere mate ook meer als netwerker en strateeg moeten gaan gedragen [11].
Bronnen
[1] http://en.wikipedia.org/wiki/Enterprise_social_software
[2] “Managing Risk in Mashup Corporations”, Capgemini, juli 2009, Hofman, Aaldert
[3] "Crafting An Insurance Social Media Strategy, P&C And Life Insurers Are Getting Social With Customers And Agents", Chad Mitchell, 8 juni 2009
[4] “The Reality of IS Lite”, september 2003, Gartner research.
[5] "Open source software governance, Critical business considerations and strategies", September 2007, HP/Oracle, Redwood City, California.
[6] "Elements of succesful collaboration, Baseline study, final report", december 1999, CIA/AAT/Coda, Intelligence Community Collaboration
[7] “Lite at the End of the Tunnel“, Andrew Rowsell-Jones, CIO magazine, 8 juni 2004
[8] "Social Software, Groups and Governance", Year 2005 Paper 24, Michael J. Madison, University of Pittsburgh School of Law
[9] "Seven characteristics of a good purpose for social software", Anthony Bradly, Nikos Drakos, 24 juli 2009, Gartner research
[10] "The Business Impact of Social Computing on
Company Governance", Anthony Bradley, 11 September 2008, Gartner Research
[11] "Information Governance: de nieuwe positie van de
CIO", Michiel Kooper, Compact_KPMG IT Advosory Seminar, 2007
De laatste jaren dringen steeds meer webtoepassingen door in bedrijven en organisaties. Toepassingen die onder de paraplu “Enterprise Web 2.0” vallen, vormen het onderwerp van dit artikel.
Enterprise Web 2.0 toepassingen omvatten de software [1]:
1. Enterprise search: vinden van mensen, functionaliteit en informatie;
2. Authoring & sharing: blogs, wikis, collaboration platforms;
3. Social bookmarking, recommendation, tagging, signaling;
4. Delen en verspreiden van informatie en functionaliteit: mashups.
Samengevat kunnen deze toepassingen worden omschreven als software assets voor “Vinden, delen en samenwerken”.
Het alom aanwezige internet, ook binnen organisaties beschikbaar, samen met de ontwikkeling van platforms waarmee dergelijke software assets snel en relatief eenvoudig gemaakt kunnen worden, en de populariteit van deze software assets, maakt dat bedrijven en organisaties niet meer om deze software heen kunnen. Op de een of andere wijze worden organisaties hiermee geconfronteerd.
Stelling: IS Lite + Open Source Governance biedt een goede basis voor Enterprise 2.0 assets
In de onderstaande tekst wil ik de stelling onderbouwen dat IS Lite, aangevuld met Open Source governance concepten, een goede basis biedt voor governance van Enterprise Web 2.0 assets.
Kenmerken en beloften van Enterprise Web 2.0 software assets
Enterprise Web 2.0 software assets bieden, in combinatie met het internet, een aantal grote voordelen, maar ook een aantal risico’s.
Voordelen en nadelen zorgen ervoor dat organisaties in eerste instantie niet
staan te springen om ermee aan de slag te gaan.
De voordelen van dergelijke assets zijn de gemakkelijke verspreidbaarheid, toegankelijkheid en herbruikbaarheid. Een software asset kan in principe door een zeer groot publiek worden gebruikt en hergebruikt, waardoor het aantal klanten (gebruikers) van een organisatie zeer snel toeneemt. Als voorbeeld kunnen RSS feeds genoemd worden waarmee nieuws zeer snel op verschillende sites kan worden verspreid. Ook assets voor e-commerce functionaliteit (software assets, webservices, waarmee online verkoop van artikelen kan worden gerealiseerd, kan zorgen voor een enorme toename van potentiële klanten en daarmee, van verkoop. Assets waarmee communicatie wordt ondersteund (micro blogging, discussie groepen, chatrooms) bieden informele groepen uitstekende mogelijkheden om kennis en ervaring uit te wisselen, zich te organiseren en zodoende invloed uit te oefenen. En deze “informele groepen” kunnen in de toekomst een formele juridische status krijgen waarmee deze invloed alleen nog maar groter wordt [8].
Binnen organisaties belooft toepassing van Enterprise Web 2.0 software assets, vooral van wiki’s, blogs en collaboration platforms, een betere communicatie en samenwerking tussen medewerkers en een betere kennisdeling en –overdracht.
De bovenstaande beloften komen in de praktijk vaak niet uit.
Dit is niet zozeer te wijten aan de technische mogelijkheden, maar aan de
verwachtingen die gesteld worden aan deze nieuwe technologieën.
"Install and expect" is de meest gemaakte fout bij de aanschaf of introductie van Enterprise Web 2.0 software assets. Daarnaast worden van Enterprise Web 2.0 software assets ook gezien als een dreiging, omdat “controle” over communicatie, klanten en eigen medewerkers verloren zou gaan.
Goede governance van de productie, de inzet, het beheer en het gebruik van Enterprise Web 2.0 software assets is van cruciaal belang om optimaal te kunnen profiteren van de technische mogelijkheden en met de risico’s te kunnen omgaan.
Dit vergt een zekere vorm van volwassenheid van de organisatie om met Enterprise Web 2.0 software om te kunnen gaan [10].
Verschillen met klassieke software
Om een beeld te krijgen van wat nodig is voor de governance van Enterprise Web 2.0 software assets kan een vergelijking gemaakt worden van goverance van "klassieke" software en "Enterprise Web 2.0 software". Hierbij wordt onderscheid gemaakt tussen planning, ontwikkeling, beheer, productie en gebruik.
| Planning: | Ontwikkeling: | Beheer: | Productie/gebruik: | |
| Klassieke software: | Risico mijdend Vaak langlopende projecten | ICT "doet" implementaties op basis van formele requirements en proces Klant eist en wenst | Vaste, formele mogelijkheden voor feedback | Vaste, formele mogelijkheden voor feedback |
| Enterprise Web 2.0 software: | Korte termijn: snelheid van acteren en aanpassen cruciaal Vooral bij externe communities bepaalt klant de richting Risico: niet voldoende aansluiten op wensen vanuit de klant | Minder afhankelijkheid van ICT, "zelf" ontwikkelen Bij externe communities bepaalt de klant de richting: nieuwe tools, nieuwe toepassingen, nieuwe mening. Applicaties evolueren continu (the perpetual beta) Klant ontwikkelt actief mee | Minder afhankelijkheid van ICT, "zelf" (laten) beheren. | Flexibele set (interne en externe) tools Informele communicatie, kennisdeling en samenwerken Klantgedrag verandert naarmate meer actief wordt deelgenomen Klant kan ook kiezen voor alternatieve software van concurrentie Risico: klant gedraagt zich niet in het belang van de business Meten van succes verandert continu |
Wat opvalt is dat de grote verschillen tussen governance van klassieke software en Enterprise Web 2.0 software temaken heeft met controle, of liever gezegd, met het verlies van controle over Enterprise Web 2.0 software. Bij klassieke software wordt risicomijdend gepland, worden formele opleveringen gedaan op basis van vantevoren gestelde eisen en wensen. Beheer wordt belegd bij een partij waarmee formele afspraken worden gemaakt over dienstverlening. Klassieke software kan vaak maar op een manier worden gebruikt terwijl en aanpassingen aan software weer via een formele procedure verlopen, waarbij slechts een kleine groep invloed heeft.
Bij Enterprise Web 2.0 software assets, echter, liggen veel zaken niet vast. Sterker nog; veel zaken zijn variabel, flexibel en aan (veel) verandering onderhevig.
Allereerst wordt bij dergelijke software uitgegaan van een flexibele set software assets waarvan de assets los van elkaar, maar ook in combinatie gebruikt kunnen worden. Voorbeelden hiervan zijn: mashups en webonderdelen in collaboration platforms.
Voorts heeft de eindgebruiker (de klant) heel veel invloed op de ontwikkeling van deze applicaties, het beheer ervan en het gebruik ervan.
Vaak kunnen gebruikers zelf applicaties (b.v. sites) samenstellen, configureren, de look and feel veranderen en nemen ze ook een deel van het beheer op zich. Daarmee bepalen ze ook in belangrijke mate hoe er gebruik wordt gemaakt van de software en bepalen ze daarmee ook waarover en hoe gecommuniceerd wordt. En daarmee is (bedoeld of onbedoeld) misbruik van software assets een realiteit [2]
De bovenstaande flexibiteit wordt bovendien nog aangevuld met een belangrijke mate van verandering; software assets kunnen eenvoudig worden vervangen voor andere en op het internet ontstaan voortdurend nieuwe software assets waarvan snel en gemakkelijk gebruik kan worden gemaakt. De snelheid waarmee microblogging aan populariteit heeft gewonnen, zowel buiten als binnen organisaties, is hiervan een goed voorbeeld. Ook de snel rijzende en dalende populariteit van Second Life is hier een goed voorbeeld van. Het lijkt wel alsof software aan modegrillen onderhevig is.
Door deze snelle veranderingen is het lastig goede gerichte investeringen te doen in software waarmee vastgestelde business doelen bereikt moeten worden. Daarnaast is het lastig het succes van software te meten. Van ieder nieuw concept moet immers bepaald worden op welke wijze succes gemeten wordt en wanneer sprake is van succes [3].
Samengevat bestaat het risico dus uit:
1. Verlies van grip op productie, beheer en gebruik;
2. Beperkt aanpassingsvermogen aan de klant zodat de aansluiting van oplossing(en) op de behoefte(n) van de klant verloren gaat.
In de praktijk blijken deze risico’s inderdaad te leiden tot teleurstellingen:
“We hebben geen controle over wat ze over ons zeggen op internet”
“Ons collaboration platform is een grote chaos; iedereen doet maar wat”
“Onze medewerkers worden via LinkedIn bij ons weggelokt”
Globale requirements aan governance van Enterprise Web 2.0 software
Uit de risico’s volgen ook de globale requirements die aan governance van deze software assets gesteld kunnen worden. Het moet de organisatie de mogelijkheid geven om de klant goed te kunnen volgen en doeltreffend en doelmatig te kunnen reageren op de steeds veranderende eisen.
Daarnaast zal er voldoende invloed uitgeoefend moeten kunnen worden op het gebruik van de software assets zodat ze doeltreffend en doelmatig ingezetworden ten behoeven van de business.
IT Lite: een eerste basis
IS Lite [4] lijkt een goede basis te zijn voor governance van Enterprise Web 2.0 software. IS Lite is ontstaan uit een aantal trends:
1. Process-based werken;
2. Outsourcing;
3. Gespecialiseerde Centers of Excellence;
4. IT gedecentraliseerd in business units.
Dit allemaal om snel te kunnen reageren op veranderingen in de markt en ICT goed te kunnen aansluiten op business behoeften.
Voor governance van Enterprise Web 2.0 software zou het zelf ontwikkelen van assets binnen business units ervoor kunnen zorgen dat assets optimaal worden afgestemd op de behoeften van de klant. Daarnaast zou de centrale ICT afdeling ervoor kunnen zorgen dat kennis van en ervaring met assets over de hele organisatie wordt gedeeld en dat hiervan iedere business unit profiteert. Ontwikkelde assets zouden aan de “infrastructuur” (hardware, software, Enterprise Web 2.0 platforms) kunnen worden toegevoegd en worden beheerd door de partij waaraan dit geoutsourced is.
Competence Center (CC) vs Center of Excellence (CoE)
Een Competence Center (CC) wendt Change Management strategieën aan om stabiliteit van systeem en business te (her)bereiken. De werkzaamheden van een Competence Center zijn daarom reactief van aard; er wordt actie ondernomen op basis van vragen / wensen vanuit de business. Een Center of Excellence (CoE, kwaliteitscentrum, kenniscentrum of expertisecentrum) streeft naar samenwerking in en met de business in een bepaald kennisgebied om zo concurrentie voordeel te behalen. Een Center of Excellence is daarom proactief; er wordt actief gezocht naar manieren om technologie en resources toe te passen om waarde proposities en de concurrentiedruk voortdurend het hoofd te bieden.
Een Center of Excellence kan zorg dragen voor een actieve verspreiding van kennis en ervaring en begeleiding van business units bij het ontwikkelen en verspreiden van assets. Daarnaast verzorgt het Center of Excellence voor een centrale roadmap waarin alle huidige en toekomstige ontwikkelingen in de tijd zijn uitgezet. Deze dient als leidraad voor alle decentrale IT units [9].
Kanttekeningen bij IS Lite voor governance van van Enterprise Web 2.0
software
In de realiteit blijkt IS Lite niet geheel te worden uitgerold [4] [7].
Redenen hiervoor zijn:
1. De economische teruggang waardoor ICT eerder gecentraliseerd wordt dan gedecentraliseerd binnen de business units wordt geïmplementeerd (gedecentraliseerde ICT is doorgaans nueenmaal duurder);
2. Een weerstand tegen verandering van ICT omdat IT Lite andere competenties vereist dan de gangbare.
Daarnaast blijkt een verandering naar IT Lite een langdurig traject te zijn dat meerdere jaren doorlooptijd kost.
Bovenstaande belemmeringen kunnen uit de weg worden genomen door niet de gehele organisatie met IS Lite te laten werken, maar dit te beperken tot organisatie eenheden die meteen profijt hebben van de voordelen en waar vanuit gemakkelijk andere organisatieonderdelen kunnen worden geïnspireerd hetzelfde te doen. Voorbeelden hiervan zijn: communicatie, project-office (assets voor interne samenwerking) en HRM.
IS Lite biedt de mogelijkheid om goed te “luisteren” naar de omgeving, de klanten en de partners en hierop gericht te reageren. Alleen luisteren, echter, is niet voldoende, ook invloed moet worden uitgeoefend om ervoor te zorgen dat assets worden gebruikt om de business doelstellingen optimaal te ondersteunen. Daarbij is het van belang dat de verschillende gebruikerscommunities een actieve bijdrage doen aan het succes van de assets. Het Center of Excellence zal daarom een manier moeten vinden om de gebruikerscommunities te activeren.
En dat gebeurt niet zomaar…
Open Source governance: een aanvulling op IT Lite
Het speelveld waarin Enterprise Web 2.0 software wordt geproduceerd, beheerd en (her)gebruikt heeft veel overeenkomsten met Open Source communities. Net zoals bij Enterprise Web 2.0 software wordt Open Source software snel en gemakkelijk verspreid en hergebruikt en brengt dit ook risico’s van verkeerd gebruik en zelfs misbruik met zich mee. En ook hierbij hebben we temaken met communities van relatief onafhankelijke leden die de vrijheid en flexibiliteit in het (her)gebruik optimaal benutten.
Afspraken voor de ontwikkeling en gebruik zijn ook hierbij van groot belang voor het succesvol zijn van de software.
In Open Source communities waarbij een leverancier een rol speelt, draagt de community aan de ene kant bij aan het succes van software van de leverancier en aan de andere kant draagt de leverancier actief bij aan het succesvol gebruiken van software door de community. Daarbij wordt impliciet controle ingebouwd op het gebruik van de software.
Deze controle kan de vorm hebben van:
1. Regelgeving, richtlijnen en begeleiding bij het (her)gebruiken van assets;
2. Ontwikkelen van juridische expertise wanneer het gaat om software assets waarvan het gebruik aan formele regelgeving onderhavig is;
3. Inventariseren, volgen en begeleiden van open source projecten waarbij gelet wordt op gebruik, hergebruik, aanpassingen en distributie van software assets;
4. Een interne Open Source community om richting te geven te geven aan de ontwikkelingen en verspreiding van assets.
Open Source governance toegepast op IS Lite governance van Enterprise Web 2.0 software assets
De bovenstaande ervaringen kunnen toegepast worden op de IS Lite governance van Enterprise Web 2.0 software assets zoals die hiervoor besproken zijn.
Om dit toe te passen kunnen we iets dieper ingaan op de verschillende stakeholders die betrokken zijn bij de ontwikkeling, het (her)gebruik en het beheer van assets, en de relaties tussen deze stakeholders.
De business
De business: bepaalt de functionaliteit van de assets die ontwikkeld moeten worden en bepaalt welke assets toegevoegd moeten worden aan de infrastructuur (platformen en asset bibliotheken die aan de communities beschikbaar worden gesteld). De business is daarmee verantwoordelijk voor de afstemming van ICT op de businessdoelen [9], krijgt richtlijnen en nieuwe ideeën van het Centrale ICT / Enterprise 2.0 Center of Excellence en geeft ideeën vanuit de communities door aan de locale en centrale IT afdeling / Center of Excellence.
Centrale ICT / Enterprise 2.0 Center of Excellence
Centrale ICT / Enterprise 2.0 Center of Excellence bepaalt de overall architectuur en stemt dit af in samenspraak met de business.
Uitgebreid met een Open Source Program Office en een Review Board waarin ook
vertegenwoordigers vanuit de business plaatsnemen, kan het Center of Excellence
zorgen voor een continue stroom van nieuwe assets die vanuit de communities
worden aangeboden.
De lokale ICT afdeling
Ontwikkelt actief assets op basis van de communities binnen hun klanten en partnerkring. Daarnaast worden communities actief begeleid in het (her)gebruiken van assets. Hierbij spelen het beschikbaar stellen van nieuwe assets, prototypes, tools, richtlijnen en advies aan de communities een belangrijke rol. Communityleden worden tevens gemotiveerd om nieuwe ideeën en assets ter review aan het Center of Excellence aan te bieden en daarmee de gezamenlijke infrastructuur te verrijken. Gebruik van de assets wordt geanalyseerd en de doeltreffendheid ervan bepaald om de business houvast te geven assets te specificeren die (nog) beter aansluiten op de behoefte van de communities, die de businessdoelen (nog) beter ondersteunen en die de
organisatie een beter concurrentie voordeel geven.
Outsourcing partner
Beheert de infrastructuur, neemt nieuwe assets op in de infrastructuur en geeft proactief advies over doeltreffender en doelmatiger gebruik van deze infrastructuur.
De communities
(Her)gebruiken assets om hun eigen businessdoelen te ondersteunen. Geven in ruil voor de begeleiding en het beschikbaar stellen van de infrastructuur met gedeelde assets een bijdrage in de vorm van feedback, nieuwe ideeën en eigen ontwikkelde assets die, na review, kunnen worden toegevoegd aan de gezamenlijke infrastructuur.
Op bovenstaande wijze wordt een ecosysteem tot stand gebracht waarin alle stakeholders hun eigen doelen kunnen realiseren en daarbij door de andere stakeholders worden ondersteund. Voor de business kan hiermee het doel worden bereikt om, naast goed te kunnen luisteren en snel en doeltreffend in te kunnen spelen op veranderende eisen vanuit de communities, ook daadwerkelijk invloed word uitgeoefend op het (her)gebruik van assets binnen deze communities.
Kantttekeningen bij IS Lite en Open Source governance toegepast op Enterprise
Web 2.0 assets
Bovenstaande opzet is natuurlijk een grove schets van hoe governance voor Enterprise Web 2.0 assets ingericht kan worden. De werkelijkheid zal verfijning vereisen. Een aantal kanttekeningen kunnen op dit moment algemaakt worden:
1. Inzet van Enterprise Web 2.0 assets binnen de organisatie verschilt van inzet van deze assets erbuiten. Interne communities zijn in het algemeen kleiner en assets worden hier veelal gebruikt om samenwerking en kennisdeling te ondersteunen. Hierbij is een “culture of sharing” noodzakelijk [6]; blindelings vertrouwen in software alleen staat in de praktijk garant voor een teleurstelling (“install and expect” is een veelgemaakte fout).
2. Risico zal nooit geheel uitgesloten zijn. Het is nueenmaal een gegeven dat controle over infrastructuur, beheer en (her)gebruik van assets voor een belangrijk deel buiten de organisatie wordt geplaatst en dit als gevolg heeft dat de organisatie zelf een deel van de controle verliest.
Dit brengt risico met zich mee. Dit risico kan echter opwegen tegen de voordelen die het heeft om met een veel groter publiek “samen te werken” [2].
3. (Her)gebruik van Enterprise Web 2.0 assets is een ontwikkeling die niet meer tegen te houden is. Het is beter dit te accepteren en er gebruik van te maken dan deze ontwikkeling te negeren en de boot te missen.
4. Ofschoon inzet van IS Lite en Open Source governance niet meteen in de gehele organisatie hoeft te worden uitgerold is het wel van belang dat men, vanaf de werkvloer tot en met het topmanagement, hierachter staat. Immers, omdat deze ontwikkelingen niet tegen zijn te houden, daarom risico’s genomen moeten worden, en het Enterprise Web 2.0 concept in een later stadium in de gehele organisatie moet worden uitgerold, zal het management ook in tegenspoed deze ontwikkeling moeten steunen. De CIO zou zich in zekere mate ook meer als netwerker en strateeg moeten gaan gedragen [11].
Bronnen
[1] http://en.wikipedia.org/wiki/Enterprise_social_software
[2] “Managing Risk in Mashup Corporations”, Capgemini, juli 2009, Hofman, Aaldert
[3] "Crafting An Insurance Social Media Strategy, P&C And Life Insurers Are Getting Social With Customers And Agents", Chad Mitchell, 8 juni 2009
[4] “The Reality of IS Lite”, september 2003, Gartner research.
[5] "Open source software governance, Critical business considerations and strategies", September 2007, HP/Oracle, Redwood City, California.
[6] "Elements of succesful collaboration, Baseline study, final report", december 1999, CIA/AAT/Coda, Intelligence Community Collaboration
[7] “Lite at the End of the Tunnel“, Andrew Rowsell-Jones, CIO magazine, 8 juni 2004
[8] "Social Software, Groups and Governance", Year 2005 Paper 24, Michael J. Madison, University of Pittsburgh School of Law
[9] "Seven characteristics of a good purpose for social software", Anthony Bradly, Nikos Drakos, 24 juli 2009, Gartner research
[10] "The Business Impact of Social Computing on
Company Governance", Anthony Bradley, 11 September 2008, Gartner Research
[11] "Information Governance: de nieuwe positie van de
CIO", Michiel Kooper, Compact_KPMG IT Advosory Seminar, 2007
Wat maakt samenwerken (met SharePoint) succesvol?
Wat maakt samenwerken (met SharePoint) succesvol? Daar is veel over nagedacht en gepubliceerd; lijsten met aandachtspunten, succesfactoren en best practices. Veel van die lijsten tonen overeenkomsten met de lijsten die ik ken uit de eerste jaren van het intranet; soortgelijke problematiek, soortgelijke lijsten. Maar er is toch iets veranderd... tijd dus voor een nieuwe lijst.
Basis: techniek, organisatie en communicatie
Al in de tijd dat intranet een "hot" item was, iedere zichzelf respecterende organisatie er "eentje moest hebben", werd mij al snel duidelijk dat voor een succesvolle implementatie naar meer gekeken moest worden dan techniek alleen. "Install and expect”, vrij vertaald door "installeer en verwacht dat 't je probleem oplost", ging ook toen al niet op.
Wat bleek namelijk in de praktijk?
Als een intranet project werd geinitieerd door de IT afdeling, werd het een stabiel platform dat goed en snel werkte, maar waar niemand gebruik van wilde maken (behalve de jongens van de IT afdeling dan). Werd het intranet geinitieerd door een afdeling als Communicatie of HR, dan werd goed nagedacht over functionaliteit, maar was de stabiliteit en snelheid niet om over naar huis te schrijven. Het leek wel alsof het intranet voor de eigen achterban, en vanuit de eigen visie, werd ontwikkeld.
Om het hogere management van klanten een bredere kijk te geven op de uitvoering van van intranet projecten, introduceerde ik een drietal aandachtsgebieden waaraan voldoende aandacht gegeven moest worden:
1. Techniek;
2. Organisatie;
3. Communicatie.
Ad 1: Techniek
Een stabiel, goed presterend (snel), uitbreidbaar en flexibel platform: natuurlijk een verplichte basis.
Ad 2: Organisatie
Centraal hierin stond de gedachte dat een intranet geen produkt is, maar een proces. Bij veel intranet projecten werd een enorme hoeveelheid tijd en moeite gestoken in het klaar krijgen van de "eerste" versie van het intranet, maar na de feestelijke opening werd relatief weinig tijd meer besteed aan het up to date houden van de informatie, verversen van nieuws en het luisteren naar feedback van gebruikers. Dat zorgde ervoor dat intranetten soms een stille dood stiervan, en vaak minder opbrachten dan gehoopt.
De vraag hierbij is trouwens ook: wat zou een intranet moeten opbrengen? Wat is de business case hierachter?
Wanneer de gehele organisatie actief werd betrokken bij het intranet, en verder gekeken werd dan de eerste editie, werd meer succes geboekt. Die actieve betrokkenheid werd vaak bereikt door een gezamelijk voordeel te bedenken; iets waarin de gehele organisatie (of in ieder geval voldoende medewerkers) in wilde investeren, waarbij de investering relatief klein was. Een eenvoudig voorbeeld hiervan was een online telefoonboek, wat de veelvuldige (ook print!) telefoonlijstjes verving door een altijd up to date telefoonboek. Iedereen deed mee de eigen gegevens up to date te houden, iedereen profiteerde daarvan: kleine moeite, groot plezier dus.
Daarnaast bleek de ontwikkeling van een intranet zich altijd een krachtveld te bevinden tussen de "business" (de gebruikers) enerzijds, en ICT (systeemontwikkeling en beheer) anderzijds: onmogelijke vragen tegenover antwoorden waar niemand op zat te wachten. En binnen ICT was er ook een krachtveld merkbaar tussen systeemontwikkeling en beheer: innovatie, verandering tegenover behoud en stabiliteit. In dat krachtveld moest een compromis bereikt zien te worden.
Ad 3: Communicatie
Om het juiste compromis te vinden in het hierboven genoemde krachtveld is goede communicatie een randvoorwaarde: communicatie tussen alle belangengroepen (stateholders), zowel tussen de "producenten" (ICT, business) als tussen de "producenten" en de gebruikers (medewerkers). Communicatie over belangen, vraag en aanbod en verwachtingen.
Bovenstaande aandachtsgebieden gaven houvast biij intranet implementaties, maar zijn onvoldoende bij implementaties van collaboratie platformen als SharePoint.
Wat is er dan veranderd ten opzichte van intranetten?
Herverdeling van rollen en verantwoordelijkheden van betrokkenen: de gebruiker wordt ontwikkelaar en beheerder
De strikte scheiding tussen gebruik, ontwikkeling en beheer is sterk aan het vervagen. Het hedendaagse collaboratie platforms als SharePoint is de eindgebruiker in staat om, met minimale tussenkomst van ICT (ontwikkeling), eigen websites en collaboratie faciliteiten te ontwikkelen. Daarnaast neemt de eindgebruiker een deel van het beheer over door bijvoorbeeld zorg te dragen voor machtigingen van andere gebruikers. Dat gebruikers een deel van de werkzaamheden van ontwikkelaars en beheerders overnemen wil niet zeggen dat ze de verantwoordelijkheid hiervan ook kunnen dragen. En hier zitten de uitdagingen, en tegelijk de kansen.
Uitdagingen worden gevormd door de gebruikers voldoende mogelijkheden te geven hun wensen te implementeren en tegelijk ervoor zorg te dragen dat de implementaties de stabiliteit en prestaties van het platform niet (te) negatief beinvloeden.
Standaardisatie van oplossingen
Ook zal standaardisatie een extra uitdaging vormen. Reden hiervoor is dat, in tegenstelling tot voorheen, meerdere implementatieteams (namelijk de gebruikers van de verschillende organisatorische eenheden, als afdelingen, projectteams) verantwoordelijk zijn voor implementatie van oplossingen. Neem als voorbeeld een smoelenboek, waar iedere afdeling wel behoefte aan heeft. Doordat iedere afdeling u in staat is om zelf een eigen smoelenboek te implementeren zullen verschillende smoelenboek implementaties naast elkaar worden ontwikkeld en beheerd. Dit in tegenstelling tot vroeger, waarin een smoelenboek zou worden ontwikkeld door de ICT ontwikkel afdeling en, bij meer vraag naar dergelijke smoelenboeken, gebruik gemaakt zou worden van een min of meer gestandaardiseerde smoelenboek oplossing.
Technology push
Daarnaast zullen (nieuwe) technische mogelijkheden op een andere manier aan de business moeten worden voorgesteld, zodat daar gebruik van gemaakt kan worden. Vroeger werd dit gedaan doordat vanuit ICT oplossingen werden aangedragen (Push), proactief of reactief.
Kortom: deze herverdeling van rollen en verantwoordelijkheden eist dat de verschillende belangengroepen intensiever met elkaar samenwerken. Dit is ironisch, gezien het hierbij gaat om collaboratie platformen; "install and expect" gaat in dit geval dus niet op.
IS Lite en Open Source Governance:
In het artikel IS Lite en Open Source Governance als basis voor Enterprise 2.0 governance wordt nader ingegaan op een manier waarop deze samenwerking kan worden gerealiseerd. Doel is een positieve wisselwerking tussen business (en gebruikers) en ICT.
Veranderende doelen
Maar de verschillen met vroegere tijden gaan verder: ook het doel van webplatformen binnen organisaties is sterk veranderd. In vroegere tijden was een inter/intra/extranet voornamelijk voor het publiceren van informatie (eenrichtingsverkeer), tegenwoordig hebben dergelijke platforms meer het karakter van een echte (meerrichtings) communicatie- en samenwerkingsplatforms. Daarbij beperkt communicatie en samenwerking zich niet alleen tot een zone (b.v. alleen intranet, alleen extranet, alleen internet), maar vindt communicatie plaats over alle zones. Voorbeelden hiervan zijn: communicatie en/of samenwerking met klanten tussen internet/extranet en intranet, en inschakelen van externe (internet) diensten (b.v. webservices) voor intern (intranet) gebruik.
Mode gevoeligheid
Een andere relevante trend is de mode gevoeligheid van applicaties, applicatie concepten en platforms. Vooral in de social media volgen de applicaties, applicatie concepten en platforms elkaar de laatste jaren in rap tempo op: Twitter, Google Wave, Hyves, Facebook, diverse Widgets, enz..
Verstandig investeren
Communicatie tussen de verschillende belanghebbenden (gebruikers, klanten, business) vindt dus plaats via meerdere zones en in een sterk wisselend landschap van applicaties, applicatie concepten en platformen. Dit dwingt investeringen in de ontwikkeling van software verstandig te doen; niet teveel investeren en met snel resultaat. Het belang van een degelijke Business Case en een snelle Return On Investment (ROI) wordt daarmee steeds groter. En daarmee wordt ook de vraag hoe het best tussen de verschillende doelgroepen gecommuniceerd en samengewerkt kan worden steeds belangrijker; niet de "coole" technologie, maar de succesfactoren van sociale processen vormen de basis van een succesvolle implementatie.
Op het gebied van succesvol samenwerken is veel onderzoek gedaan. Wat bijvoorbeeld blijkt is dat de succesfactoren voor samenwerking met en zonder behulp van software dezelfde zijn ("Intelligence Community Collaboration, Baseline study").
Deze succesfactoren zijn:
Basis: techniek, organisatie en communicatie
Al in de tijd dat intranet een "hot" item was, iedere zichzelf respecterende organisatie er "eentje moest hebben", werd mij al snel duidelijk dat voor een succesvolle implementatie naar meer gekeken moest worden dan techniek alleen. "Install and expect”, vrij vertaald door "installeer en verwacht dat 't je probleem oplost", ging ook toen al niet op.
Wat bleek namelijk in de praktijk?
Als een intranet project werd geinitieerd door de IT afdeling, werd het een stabiel platform dat goed en snel werkte, maar waar niemand gebruik van wilde maken (behalve de jongens van de IT afdeling dan). Werd het intranet geinitieerd door een afdeling als Communicatie of HR, dan werd goed nagedacht over functionaliteit, maar was de stabiliteit en snelheid niet om over naar huis te schrijven. Het leek wel alsof het intranet voor de eigen achterban, en vanuit de eigen visie, werd ontwikkeld.
Om het hogere management van klanten een bredere kijk te geven op de uitvoering van van intranet projecten, introduceerde ik een drietal aandachtsgebieden waaraan voldoende aandacht gegeven moest worden:
1. Techniek;
2. Organisatie;
3. Communicatie.
Ad 1: Techniek
Een stabiel, goed presterend (snel), uitbreidbaar en flexibel platform: natuurlijk een verplichte basis.
Ad 2: Organisatie
Centraal hierin stond de gedachte dat een intranet geen produkt is, maar een proces. Bij veel intranet projecten werd een enorme hoeveelheid tijd en moeite gestoken in het klaar krijgen van de "eerste" versie van het intranet, maar na de feestelijke opening werd relatief weinig tijd meer besteed aan het up to date houden van de informatie, verversen van nieuws en het luisteren naar feedback van gebruikers. Dat zorgde ervoor dat intranetten soms een stille dood stiervan, en vaak minder opbrachten dan gehoopt.
De vraag hierbij is trouwens ook: wat zou een intranet moeten opbrengen? Wat is de business case hierachter?
Wanneer de gehele organisatie actief werd betrokken bij het intranet, en verder gekeken werd dan de eerste editie, werd meer succes geboekt. Die actieve betrokkenheid werd vaak bereikt door een gezamelijk voordeel te bedenken; iets waarin de gehele organisatie (of in ieder geval voldoende medewerkers) in wilde investeren, waarbij de investering relatief klein was. Een eenvoudig voorbeeld hiervan was een online telefoonboek, wat de veelvuldige (ook print!) telefoonlijstjes verving door een altijd up to date telefoonboek. Iedereen deed mee de eigen gegevens up to date te houden, iedereen profiteerde daarvan: kleine moeite, groot plezier dus.
Daarnaast bleek de ontwikkeling van een intranet zich altijd een krachtveld te bevinden tussen de "business" (de gebruikers) enerzijds, en ICT (systeemontwikkeling en beheer) anderzijds: onmogelijke vragen tegenover antwoorden waar niemand op zat te wachten. En binnen ICT was er ook een krachtveld merkbaar tussen systeemontwikkeling en beheer: innovatie, verandering tegenover behoud en stabiliteit. In dat krachtveld moest een compromis bereikt zien te worden.
Ad 3: Communicatie
Om het juiste compromis te vinden in het hierboven genoemde krachtveld is goede communicatie een randvoorwaarde: communicatie tussen alle belangengroepen (stateholders), zowel tussen de "producenten" (ICT, business) als tussen de "producenten" en de gebruikers (medewerkers). Communicatie over belangen, vraag en aanbod en verwachtingen.
Bovenstaande aandachtsgebieden gaven houvast biij intranet implementaties, maar zijn onvoldoende bij implementaties van collaboratie platformen als SharePoint.
Wat is er dan veranderd ten opzichte van intranetten?
Herverdeling van rollen en verantwoordelijkheden van betrokkenen: de gebruiker wordt ontwikkelaar en beheerder
De strikte scheiding tussen gebruik, ontwikkeling en beheer is sterk aan het vervagen. Het hedendaagse collaboratie platforms als SharePoint is de eindgebruiker in staat om, met minimale tussenkomst van ICT (ontwikkeling), eigen websites en collaboratie faciliteiten te ontwikkelen. Daarnaast neemt de eindgebruiker een deel van het beheer over door bijvoorbeeld zorg te dragen voor machtigingen van andere gebruikers. Dat gebruikers een deel van de werkzaamheden van ontwikkelaars en beheerders overnemen wil niet zeggen dat ze de verantwoordelijkheid hiervan ook kunnen dragen. En hier zitten de uitdagingen, en tegelijk de kansen.
Uitdagingen worden gevormd door de gebruikers voldoende mogelijkheden te geven hun wensen te implementeren en tegelijk ervoor zorg te dragen dat de implementaties de stabiliteit en prestaties van het platform niet (te) negatief beinvloeden.
Standaardisatie van oplossingen
Ook zal standaardisatie een extra uitdaging vormen. Reden hiervoor is dat, in tegenstelling tot voorheen, meerdere implementatieteams (namelijk de gebruikers van de verschillende organisatorische eenheden, als afdelingen, projectteams) verantwoordelijk zijn voor implementatie van oplossingen. Neem als voorbeeld een smoelenboek, waar iedere afdeling wel behoefte aan heeft. Doordat iedere afdeling u in staat is om zelf een eigen smoelenboek te implementeren zullen verschillende smoelenboek implementaties naast elkaar worden ontwikkeld en beheerd. Dit in tegenstelling tot vroeger, waarin een smoelenboek zou worden ontwikkeld door de ICT ontwikkel afdeling en, bij meer vraag naar dergelijke smoelenboeken, gebruik gemaakt zou worden van een min of meer gestandaardiseerde smoelenboek oplossing.
Technology push
Daarnaast zullen (nieuwe) technische mogelijkheden op een andere manier aan de business moeten worden voorgesteld, zodat daar gebruik van gemaakt kan worden. Vroeger werd dit gedaan doordat vanuit ICT oplossingen werden aangedragen (Push), proactief of reactief.
Kortom: deze herverdeling van rollen en verantwoordelijkheden eist dat de verschillende belangengroepen intensiever met elkaar samenwerken. Dit is ironisch, gezien het hierbij gaat om collaboratie platformen; "install and expect" gaat in dit geval dus niet op.
IS Lite en Open Source Governance:
In het artikel IS Lite en Open Source Governance als basis voor Enterprise 2.0 governance wordt nader ingegaan op een manier waarop deze samenwerking kan worden gerealiseerd. Doel is een positieve wisselwerking tussen business (en gebruikers) en ICT.
Veranderende doelen
Maar de verschillen met vroegere tijden gaan verder: ook het doel van webplatformen binnen organisaties is sterk veranderd. In vroegere tijden was een inter/intra/extranet voornamelijk voor het publiceren van informatie (eenrichtingsverkeer), tegenwoordig hebben dergelijke platforms meer het karakter van een echte (meerrichtings) communicatie- en samenwerkingsplatforms. Daarbij beperkt communicatie en samenwerking zich niet alleen tot een zone (b.v. alleen intranet, alleen extranet, alleen internet), maar vindt communicatie plaats over alle zones. Voorbeelden hiervan zijn: communicatie en/of samenwerking met klanten tussen internet/extranet en intranet, en inschakelen van externe (internet) diensten (b.v. webservices) voor intern (intranet) gebruik.
Mode gevoeligheid
Een andere relevante trend is de mode gevoeligheid van applicaties, applicatie concepten en platforms. Vooral in de social media volgen de applicaties, applicatie concepten en platforms elkaar de laatste jaren in rap tempo op: Twitter, Google Wave, Hyves, Facebook, diverse Widgets, enz..
Verstandig investeren
Communicatie tussen de verschillende belanghebbenden (gebruikers, klanten, business) vindt dus plaats via meerdere zones en in een sterk wisselend landschap van applicaties, applicatie concepten en platformen. Dit dwingt investeringen in de ontwikkeling van software verstandig te doen; niet teveel investeren en met snel resultaat. Het belang van een degelijke Business Case en een snelle Return On Investment (ROI) wordt daarmee steeds groter. En daarmee wordt ook de vraag hoe het best tussen de verschillende doelgroepen gecommuniceerd en samengewerkt kan worden steeds belangrijker; niet de "coole" technologie, maar de succesfactoren van sociale processen vormen de basis van een succesvolle implementatie.
Op het gebied van succesvol samenwerken is veel onderzoek gedaan. Wat bijvoorbeeld blijkt is dat de succesfactoren voor samenwerking met en zonder behulp van software dezelfde zijn ("Intelligence Community Collaboration, Baseline study").
Deze succesfactoren zijn:
- Nastreven van een gezamenlijk doel;
- Aandacht voor de onderliggende business processen en workflows; is vanzelfsprekend, maar vaak wordt het aangeschafte informatiesysteem gezien als leidraad terwijl het systeem de bestaande processen en flows zou moeten ondersteunen;
- Vertrouwen; ik stel mijn informatie aan jou beschikbaar en vertrouw erop dat jij daar geen misbruik van maakt;
- Regels voor het gebruik van de ondersteunende middelen, met de bijbehorende training en toezicht op naleving van de regels;
- Gezamenlijk voordeel; ik geef en ik krijg er wat voor terug;
- Management ondersteuning; voor als zaken die met enige mate van dwang opgelegd moeten worden;
- Beloning voor samenwerking;
- Training; altijd noodzakelijk om snel met wijzigingen in aanpak, omgeving of ondersteuning te kunnen omgaan;
- Kritische massa; wanneer het eerste schaap..
Implementatietrajecten van killerapps voldoen aan de meeste van de bovenstaande succesfactoren.
Do not try to boil the ocean
Naast rekening houden met de genoemde succesfactoren is het van belang niet meteen alles in een keer te willen. Leren samenwerken is niet alleen maar het volgen van nieuwe procedures, maar houdt vaak ook een cultuurverandering in. En cultuurveranderingen hebben tijd, investeringen en tact nodig.
Samenwerken
Samenwerking begint met het creeren van bewustzijn; van het nut van samenwerken, maar ook van de (on)mogelijkheden van de ondersteuning ervan. Pas wanneer de organisatie goed is voorbereid, kunnen vervolgstappen starten. Dit kan een cultuur verandering inhouden, hetgeen veel tijd en moeite kan kosten. Het is net als bij e-commerce: eerst de backoffice goed op orde, daarna de e-winkel openen.
Wellicht is het opzetten van een proeftuin of aparte, relatief zelfstandige organisatie, daarvoor de juiste zet.
Conclusie
Ook met moderne platformen voor communicatie en samenwerken, als SharePoint, bieden nog steeds geen "install and expect". Het is, meer dan ooit, van belang om met beide benen op de grond na te denken. Kern hiervan is samenwerking: tussen ICT, de business en gebruikers, en tussen de business en de (internet) klant. De rollen veranderen, de bijbehorende verantwoordelijkheden veranderen, dus de manier waarmee we omgaan met samenwerking zal eveneens moeten veranderen.
Abonneren op:
Posts (Atom)