Nog veel meer dan andere specialismen is het vak van it-manager vandaag de dag in beweging. Eén internetloze vakantie en je loopt bij wijze van spreken al achter. Gebruikers ontwikkelen steeds meer eigen voorkeuren met deze software applicaties. Vooral 'select your own tool' (syot) lijkt de volgende uitdaging voor it-managers.
Zo lang geleden is het niet dat automatisering zich vooral afspeelde in grote fabrieken en in goede banen werd geleid door hoogopgeleide specialisten. De ontwikkeling kwam in een stroomversnelling en al snel kwam de pc op de markt, gevolgd door Windows. Dankzij software waar ook leken mee aan de slag konden werd automatisering opeens een algemeen goed. Berekeningen waar vroeger deskundige programmeurs weken voor moesten coderen en testen werden plotseling in luttele seconden voltooid door computerprogramma’s zoals Multiplan die door een gewone burger konden worden bestuurd.
Het leek er lange tijd op dat dit de grootste revolutie zou zijn die we op it-gebied zouden meemaken. Maar in werkelijkheid staat er binnenkort een veel grotere verandering te gebeuren. Deze verandering is dan ook met recht een ‘game changer’ te noemen.
Revolutie
Doordat technologische toepassingen zich steeds sneller ontwikkelen, voltrekt deze nieuwe revolutie zich dan ook sneller dan ooit tevoren. Het verwerken van informatie is een geheel nieuwe uitdaging geworden sinds de komst van smartphones en tablets. Deze apparaten vormen een belangrijk onderdeel van het dagelijks leven van een groot deel van de bevolking. Een steeds groter wordend aandeel van alle informatie die wordt verwerkt wordt via mobiele devices verspreid. En dit aandeel zal alleen maar toenemen naarmate mogelijkheden en toepassingen worden verbeterd.
Daarnaast is het duidelijk dat vooral de ‘screenager’-generatie een voorkeur heeft voor mobiele informatieverwerking. Aangezien deze generatie de toekomst heeft, is het niet meer dan een simpele rekensom om te beseffen dat hier een grote groeimarkt ligt. De meeste it-managers zijn zich al langere tijd bewust van het belang van ontwikkelingen als bring your own device (byod) en spelen hier al op in.
Goed om te vermelden in dit licht zijn de verrassende onderzoeksresultaten van een onderzoek over het nieuwe werken onder het mkb door ErgoDirect International en Veldhoen+Company. Er zijn meer tegenstanders (41 procent) van volledige keuzevrijheid in hardware dan voorstanders (34 procent) onder de ondervraagde it-professionals. Dus vanuit de werkgever zal er beperkte stimulans zijn om je eigen productivity tools mee te nemen. Zijn de it-managers zich bewust van het belang van ontwikkelingen als bring your own device (byod). Of is het voor hen slechts een ‘fad’?
Cloud stimuleert syot
Cloud innovaties vinden plaats bij zowel hardware als software. Tot voor kort waren er vooral toepassingen als crm, erp, workflow of DMS beschikbaar. Deze waren meestal erg duur en alleen als onderdeel van een langdurig project te implementeren. Dankzij de cloud en SaaS zijn oplossingen als bijvoorbeeld Dropbox, Box en iDrive toegankelijk voor de gewone man of vrouw. Inmiddels is er ook een nieuwe generatie oplossingen opgestaan met bijvoorbeeld Salesforce, Yuki of Serenga.
Gebruikers ontwikkelen steeds meer eigen voorkeuren met deze software applicaties. Vooral select your own tool (syot) lijkt de volgende uitdaging voor it-managers. De it-infrastructuur zal dan ook de komende jaren met een flinke verbouwing moeten omgaan. Het is allang geen aanbiedersmarkt meer. De it-manager zal ervoor moeten zorgen dat de it-infrastructuur verandert van een gesloten systeem naar een open platform waar de gebruiker de leiding heeft. Van databeheerder naar dataprovider, een hele uitdaging!
Ik ben benieuwd naar jullie mening en wat het belang zal worden van deze trend en hoe snel dit zal worden opgepikt door de IT professionals.
Ik kan me op zich vinden in de inhoud van het artikel, alleen zie ik de manier waarop iets anders tot stand komen.
Kort door de bocht zie ik ook een aantal dingen gebeuren:
> Werknemers gebruiken cloud tools die niet door de IT geleverd worden (Dropbox, GMail voor grote attachements, Prezi voor een presentatie of bijvoorbeeld MailChimp om nieuwsbrieven te versturen, Yammer om samen te werken)
> Afdelingen hebben vaak ook een eigen budget en kiezen er soms voor zelf cloud diensten (ofwel Tools) af te nemen, met of zonder instemming
van de IT afdeling
IT afdelingen worden zo min of meer gedwongen hun houding (je moet bij ons zijn voor IT) los te laten en wat meer een regie functie op te zoeken waarmee ze in ieder geval kunnen helpen de juiste tools te selecteren, of te zorgen voor een consistent beleid.
CYOT, BYOD en dus ook SYOT vind ik over het algemeen geen goed idee om te gebruiken omdat veel mensen bij het horen van zo’n term al afhaken. Dit is ook volgens mij een reden waarom Cloud hot was bij academici, maar het nu volledig links hebben laten liggen (Van Wijk et al, 2012).
Overigens niet ik nog niet veel verschuivingen “on premise”, eigen tools kunnen dus niet zo maar gekozen worden, het zijn vooral de internet diensten die deze “trend” aanjagen.
Een groot gevaar hierin is dat een bedrijf grote kans maakt wetten te overtreden en daarom is het dus ook belangrijk dat een afdeling (logischer wijs de IT afdeling) actief de regie naar zich toetrekt omdat er anders nog wel eens nare verrassingen kunnen ontstaan, bijvoorbeeld imago schade omdat een gebruikte tool niet veilig blijkt te zijn. Dit valt in het domein “governance”
SYOT … ik had zelf al zitten denken aan BYOT: bring your own tools, iets wat ik steeds meer bespeur in ontwikkelomgevingen.
Bedrijven bieden een standaard ontwikkelomgeving aan, waarin ontwikkelaars geacht worden hun werk te kunnen doen. Maar, ontwikkelaar A komt van bedrijf 1, en is gewend aan een andere editor. Ach, het is toch open source en gratis, dus kan ik dit bij mijn nieuwe werkgever gebruiken. Vervolgen komt ontwikkelaar B, die van bedrijf 2 afkomt, en die weet weer een ander tool.
Na verloop van tijd zie je dus “zoveel mensen, zoveel wensen” op het gebied van gebruikte tools. Maar, zoals een kok niet naar alle monden kan koken, kan een IT afdeling niet voor iedereen op maat een ontwikkelomgeving definiëren.
Alhoewel, kunnen misschien nog wel, maar is dit wenselijk? Immers, niet alle combinaties van tools werken even goed met elkaar samen. En dan kan de ontwikkelaar dit wel willen installeren; als het niet werkt is het toch de systeembeheerder die 9 van de 10 keer het probleem op mag gaan lossen.
Maar ook verderop in het ontwikkeltraject kan deze manier van werken problemen op leveren. Als je eindproduct bestaat uit 10 modules, en iedere module is ontwikkeld met een eigen set van tools, moet degene die het eindproduct moet bouwen dan al deze tools op de bouwmachine beschikbaar hebben? En wie van de ontwikkelteams gaat zich aanpassen als deze tools onderling niet samenwerken op één bouwmachine?
Of wil je dat degene die het product uiteindelijk moet bouwen 10 bouwmachine’s heeft, voor elk van de modules 1? Dat klinkt ook niet echt efficiënt, wel?
Een ander, niet geheel onbelangrijk aspect in sommige sectoren, is het lange termijn onderhoud. Een typische eigenschap van een project is dat ze zich focussen op de ontwikkeling van het product wat ze moeten maken. Dit product kun je in principe maken met allerlei zelf gekozen tools. Aan het eind van het project wordt het projectteam ontbonden, en gaat eenieder zijn (of haar) eigen weg weer. Maar wie is nu verantwoordelijk voor de onderhoud op het product? En, in het verlengde hiervan, wat is geregeld voor het lange termijn onderhoud van de ontwikkel- (en bouw-)omgeving? Immers, al die verschillende tooltjes die gebruikt zijn om het product te maken, krijgen op een bepaald moment een update, of werken niet meer samen met de nieuwe windows patches.
Verwacht men nu van het “onderhouds team” dat ze al die verschillende tooltjes snappen en kunnen beheren die de ontwikkelaars ooit gebruikt hebben in de tijd dat het product ontwikkeld was?
In zo’n geval kan het toch wel heel handig zijn dat iedereen tijdens de ontwikkeling van een product dezelfde tools heeft gebruikt, waardoor onderhoud van de ontwikkelomgeving voor lange termijn onderhoud vele malen eenvoudiger wordt.
Bart,
Wat je hier schrijft is waar maar NIET nieuw en al jaren kiest de business haar eigen applicaties. De IT kiest vervolgens weer de hulpmiddelen om al die oplossingen te beheren. Zie hier een reden waarom het zo moeilijk is om applicatie portfolio’s te rationaliseren. Zou IT namelijk, net als vroeger de applicaties kiezen dan was er vast sprake van een meer consistente architectuur in plaats van de gebruikelijke verzameling aan elkaar geknoopte deeloplossingen.
En dus krijgen we na de ‘Excel hell’ met alle huisvlijt van gebruikers nu steeds meer moeite met de ongestructureerde data. Want al die applicaties zijn bijzaak, het gaat om de data die er in opgeslagen ligt. Opmerkelijk dan ook dat je niet Enterprise Content Management noemt in dit artikel. Mate van succes van de Cloud ligt tenslotte meer in het convergeren van verschillende oplossingen, welke dus ook bedrijfsoverschrijdend kunnen zijn, dan een deeloplossing. Daar hebben meeste bedrijven dan ook al meer dan honderden van.
PaVake : Grappig, we schreven onze reactie parallel aan elkaar en komen met twee verschillende aspecten, leuk!
Bij jouw voorbeelden speelt ook heel sterk de licentie problematiek! En ook daar heb je weer een stukje governance nodig.
@Henri
idd leuk, maar het leukste is dat het elkaar ook nog eens mooi aanvult 🙂
Bart,
Bij een overheidsinstelling met 4 verschillende organen, 2600 gebruikers die samen een organisatie vormden heb ik een project meegemaakt om de omgeving te consolideren. IT-afdeling had de taak om de business(lees de 4 organen) te faciliteren en elk orgaan had eigen budget en kon zelf bepalen welke applicaties ze gebruiken wilden (binnen gezamenlijke LAN en back-end omgeving)
Hierdoor was er een oerwoud van applicaties, licenties, contracten, externe diensten etc ontstaan. Efficiëntie, besparing en slimme inzet van IT was ver te zoeken. Dat leek op het concept SYOT/BYOT.
Na het project was de rol van IT anders geworden dan voorheen!
Wanneer je opzoek gaat naar een applicatie dan zou je eerst een PvE (Programma/Pakket van Eisen) moeten opstellen waar de applicatie aan moet voldoen (gezamenlijke eisen van business en IT-afdeling) Door de samenwerking tussen business en IT creëer je een brede visie en grondige aanpak.
Je zou misschien voor een tool kiezen die als Cloud-dienst aangeboden wordt. Maar wat wel belangrijk is is dat je door deze aanpak het oerwoud, geldverspilling en inefficiëntie die SYOT/BYOT met zich meebrengt heb kunnen voorkomen.
Beste allemaal
Bedankt voor jullie reacties, ik zie dat er meer mensen nadenken over deze ontwikkelingen. Ik ben ook blij te lezen dat jullie grosso modo dit gedachte goed ondersteunen. Bijgaand een reactie op jullie reacties. Wat mij betreft gaan we nog even door met de discussie.
@Henri Koppen
Ik ben ook niet zo’n voorstander van dit termen als BYOD, SYOT en BYOT, echter je hebt ze af en toe nodig om een goede discussie te starten en mensen te laten nadenken over bepaalde zaken.
Wat betreft de trage verschuiving van On-premise naar cloud, deze vertraging wordt enerzijds ingegeven door de wat traditionele houding van IT afdelingen, maar misschine nog wel in belangrijkere maten het Saas (of beter nog het gebrek aan Saas) gehalte van de huidige cloud oplossingen. We staan nog aan het begin van deze ontwikkeling.
De opmerking over het overtreden van wetten is mij niet duidelijk? Wellicht ook het begin van een leuke discussie.
@PaVake
Ik geloof niet dat SYOT voor alle bedrijfsprocessen een oplossing is. Zeker daar waar gestructureerde processen plaats vinden zullen bestaande oplossingen (voorlopig nog) de boventoon voeren. Echter in de dynamische omgevingen, zoals kantoren zal SYOT een belangrijke rol gaan spelen. Het blijft een tool …
@Ewout Dekkinga
Ik ben het met je eens, ik herken de “Excel hell”. Maar zoals in de reactie naar PaVake kunt lezen zal SYOT niet voor alle processen gelden. Misschien bedoel ik met “het platform” wel juist ECM. Wellicht zal IT zich moeten bezig houden met het beheer van data ipv infrastructuur.
@Reza Sarshar
Uiteraard moet je een PvE opstellen. Echter in een commoditizing wereld hoeft een PvE geen academische studie te zijn, ik denk niet dat er veel dropbox gebruikers zijn die een uitgebreid PvE hebben gemaakt voor het gebruik. Handig, makkelijk, “does de Job”, en goede ervaringen is voor een tool vaak genoeg. Over automatiseren in de overheid wil ik nog wel eens een aparte discussie voeren.
Het is kennelijk een tendens om enerzijds in diverse artikelen de mogelijkheden van een dynamische omgeving te benadrukken, terwijl in andere artikelen wordt gewaarschuwd voor te veel vrijheid en het loslaten van standaardisatie.
De waarheid zal ongetwijfeld ergens in het midden liggen, maar over het algemeen denk ik toch dat de risico’s die je als organisatie neemt door ‘alles maar toe te laten’ te groot zijn in verhouding met de eventuele voordelen daarvan.
Zeker in een omgeving die is “uitgespreid” in de Cloud, is het naar mijn idee nauwelijks een optie die keuzevrijheid te vergroten zolang niet kan worden aangetoond dat er grip is op die omgeving en het beheer ervan in control is.
Ik begrijp dan ook niet zoveel van opinies die nieuwe trends neerzetten welke zijn gericht op die grote(re) keuzevrijheid van gebruikers en daarbij de suggestie wekken dat ‘er niets aan te doen is’.
Daar waar de verantwoordelijkheid van ICT beheer vooral ligt op het vlak van het zo efficiënt en effectief mogelijk leveren van functionerende functionaliteit, heeft zij een minstens zo grote verantwoordelijkheid om ICT transparant en begrijpbaar te maken voor de business en haar te helpen verantwoord beleid te formuleren, gericht op de realisatie van de business doelstellingen. En dat zoveel als mogelijk met uitsluiting van risico’s.
Volgens mij ligt daar de echte uitdaging van IT managers
Concreet betekent dit dat gebruikers dienen te worden voorzien van ICT die geen ander doel heeft het bedrijfsproces zo goed mogelijk te ondersteunen. Dat vraagt eerder om standaardisatie dan om verruiming van keuzemogelijkheden.
Elk verzoek tot uitbreiding of wijziging van bestaande functionaliteit dient daarom gestructureerd te worden behandeld. Er zou een sluitende BC voor moeten zijn die voldoet aan de business doelstellingen en onder andere is gebaseerd op een impactanalyse en getoetst aan aansluitvoorwaarden.
Als dat de nieuwe trend wordt, zijn we een stuk gezonder bezig.