Is ICT verstaanbaar voor de modale bedrijfsleider ?

[D4Skunk]

Uit mijn persoonlijke ervaring (enkele jaren als IT-Manager) bleek dat het antwoord op deze vraag meestal nee was.

Zo heb ik verschillende voorbeelden :

Wanneer ik langskwam met een projectplan met ICT-begrippen, werd dit
a ) genegeerd
b ) teruggestuurd, met als opdracht het plan in leken-taal te omschrijven (een onmogelijke opdracht; leg maar eens alle details van een projectplan van 10 manjaar 1 voor 1 uit aan een iemand met enkel outlook- en excel-ervaring ).

Leg eens uit wat het verschil is tussen een access-database, en een MS-SQL of oracle-database ?
Uiteindelijk heb ik dit vergeleken met een bibliotheek :
Bij de ene bibliotheek mocht je slechts 1 naslagwerk per keer uit de rekken halen (Access) en bij de andere verschillende tegelijk (Oracle & SQL-server), zoveel als je op je tafel kon leggen.

Natuurlijk zijn dit maar een paar van de vele anekdotes die ik tegengekomen ben.

Inmiddels werk ik voor een andere baas, nl. mezelf
De kennis die ik in mijn carriere opgedaan heb , kan ik nu ook zeer goed gebruiken voor mijn klanten.

De (weinige) ervaring die ik opgedaan heb in het verleden, wil ik graag met iedereen delen, vandaar deze 2 vragen :
* Waarom vergeet iedereen steeds dat bedrijfsleiders geen ICT-mensen zijn, en waarom denken bedrijfsleiders steeds dat ze alles van ICT moeten weten, tot in de kleinste details ?

* ik ben zelf net met een bescheiden ( ) weblogje begonnen om de kloof tussen ICT en bedrijfsleiders te verkleinen. Denken jullie dat dit iets zou kunnen verhelpen aan dit probleem, en hebben jullie nog nuttige onderwerpen ?

PS : KMO is belgisch voor kleine & middelgrote ondernemingen

[ Voor 5% gewijzigd door D4Skunk op 05-01-2004 03:59 . Reden: blahblah 8) ]

[CookiePower]

Als een bedrijfsleider op een positie zit waarop hij zal moeten beslissen over ICT-zaken, dan ben ik van mening dat hij er ook veel (alles zal wellicht moeilijk gaan) vanaf zal moeten weten.

Aan de andere kant. ICT-ers staan erom bekend dat ze vaak niet over de juiste communicatieve vaardigheden beschikken om hun vakgebied aan derden duidelijk te maken

Je weblog is wel amusant, maar ik denk niet dat het eraan bijdraagt dat niet-ICT geschoolden nader tot wel ICT-geschoolden komen. Het is namelijk voor een ICT-er al moeilijk zat om alles bij te houden, laat staan voor een leek

[D4Skunk]

CookiePower schreef op 05 januari 2004 @ 02:36:
Als een bedrijfsleider op een positie zit waarop hij zal moeten beslissen over ICT-zaken, dan ben ik van mening dat hij er ook veel (alles zal wellicht moeilijk gaan) vanaf zal moeten weten.

Aan de andere kant. ICT-ers staan erom bekend dat ze vaak niet over de juiste communicatieve vaardigheden beschikken om hun vakgebied aan derden duidelijk te maken

Je weblog is wel amusant, maar ik denk niet dat het eraan bijdraagt dat niet-ICT geschoolden nader tot wel ICT-geschoolden komen. Het is namelijk voor een ICT-er al moeilijk zat om alles bij te houden, laat staan voor een leek

Hmmz.. volledig mee akkoord. Bedankt voor het volgende onderwerp
Misschien moet ik maar eens een artikeltje schrijven, waarbij ik een gesprek vanuit beide kanten bekijk; nl. vanuit het standpunt van de bedrijfsleider, en dat van de ICT'er ? Ik denk wel dat dit min of meer de goede richting zou kunnen uitgaan....

[MissingDog]

Mijn ervaring heeft me geleerd om niet met ICT-termen te gooien en ook niet direct met analogieen, maar om de functionaliteit en de achterliggende gedachte te bundelen tot een soort van 'ICT voor dummies' tekst.

vb:
Backend van website/intranet met secure contentmanagementsysteem, adressendatabase en mailingscheduling / nieuwsbriefbeheer

Je kunt 't technisch vertellen ->
De webapplicatie is geprogrammeerd in PHP en wordt benaderd via een SSL verbinding naar de HTTP server. De adres- en contentdatabases zullen draaien op de MySQL engine, voor de nieuwsbrieven wordt gebruik gemaakt van HTML content, welke op de gewenste tijdstippen via crontab aan sendmail doorgegeven wordt voor de versturing.

Je kunt 't met iets meer woorden beter duidelijk maken ->
De nieuwe webpagina zal geplaatst worden op een centrale computer verbonden met het internet. De verschillende onderdelen zijn voor medewerkers toegankelijk met hun eigen gebruikersnaam en wachtwoord. Via deze pagina is het mogelijk om de bedrijfssite bij te werken en contactpersonen op te vragen en te bewerken. Tevens is er de mogelijkheid om de elektronische nieuwsbrieven te lezen, beheren en nieuwe mailings te plannen.

Voor de manager is 't totaal niet van belang hoe de boel technisch in elkaar steekt, het enige wat hij wil weten is:

- Wat is het / wat kan het systeem voor de organisatie betekenen?
- Is het technisch haalbaar / moet er know-how ingekocht worden?
- Wat zijn de kosten / is het haalbaar binnen het huidige budget?
- Wanneer is het klaar?
- Hoe zit 't met onderhoud en opleiding van de gebruikers?

Ik betrap mezelf er nogal vaak op dat ik behoorlijk veel technotalk gebruik als ik iets wil uitleggen aan m'n collega's (allen ICTers, werk op IT afdeling) en dat zelfs zij er geen soep van kunnen koken. Een van de oorzaken is dat de meeste (jonge) ICTers, waaronder ikzelf, op een veel dieper niveau naar de materie kijken; een niveau waar veel mensen wel van gehoord hebben, maar totaal geen interesse in hebben of gewoonweg nooit te maken krijgen met de achterliggende architectuur.

Met het gebruik van analogieen kan je inderdaad wel iets uitrichten, maar dat kan alleen maar wanneer de 'noob' al een beetje achtergrondkennis en associatief vermogen heeft. Ik kom dagelijks gebruikers tegen die al moeite hebben om de principes 'snelkoppeling' en 'harde schijf' te begrijpen....en dan kan je 't vergeten met je analogieen.

Geef mensen niet meer informatie dan nodig is om iets te beschrijven, als ze meer willen weten, dan kan je ze altijd nog iets meer vertellen. Voor projectplannen is 't een goede gewoonte om naast een abstract document met de projectbeschrijving en 't functioneel ontwerp, ook een technisch onderbouwde beschrijving op te stellen, waar wel alles in genoemd wordt, beter bekend als het technisch ontwerp.

[ Voor 10% gewijzigd door MissingDog op 05-01-2004 03:23 ]

[Verwijderd]

Op de Universiteit(Technische Informatica) wordt er serieus veel aandacht aan besteed. We krijgen niet alleen vakken waarmee we in zowel lekentaal als technische taal leren schrijven, maar ook presenteren en dergelijke. Tis een essentieel onderdeel.

Aangezien opdrachtgevers ons betalen om oplossingen voor ze te vinden, vind ik ook wel dat we ons mogen aanpassen aan hen.
Het zijn suffe saaie vakken, maar ik denk dat ik er later wel wat aan ga hebben

[D4Skunk]

MissingDog schreef op 05 januari 2004 @ 03:20:
Mijn ervaring heeft me geleerd om niet met ICT-termen te gooien en ook niet direct met analogieen, maar om de functionaliteit en de achterliggende gedachte te bundelen tot een soort van 'ICT voor dummies' tekst.

Knip

Voor de manager is 't totaal niet van belang hoe de boel technisch in elkaar steekt, het enige wat hij wil weten is:

- Wat is het / wat kan het systeem voor de organisatie betekenen?
- Is het technisch haalbaar / moet er know-how ingekocht worden?
- Wat zijn de kosten / is het haalbaar binnen het huidige budget?
- Wanneer is het klaar?

Tot zover volg ik je volledig, maar er is hier 1 probleem : het management komt af met een voor hun zeer eenvoudig probleem, dat echter heel wat technische implicaties heeft, en dus ook meer kost en/of langer duurt dan zij plannen. Dan moet je uitleggen waarom het zo lang duurt, zij begrijpen de problematiek niet, en dan komt de aap uit de mouw.

Een recent voorbeeld uit de werkelijkheid:
Er is een top van het management waar ze tot het geniale inzicht komen, nl. we hebben 1 grote uniforme db nodig ipv al die versnipperde, en daarrond zou er een CRM-pakket geschreven worden.
Ik wist dat al lang natuurlijk, maar wegens gebrek aan middelen en tijd had ik dit zelfs nog niet aangebracht. Zij hadden in die top beslist dat dit binnen de 3 maand moest gerealiseerd worden, met de huidige middelen : 1 system engineer, 1 IT manager, en 1 in-house developper.
Ik : "Planning volgens mijn projectplan, met de huidige middelen en 2 externen : naar beneden afgerond 3 jaar."
General manager : "Niet correct, dit plan MOET op 1 jaar kunnen"
Ik : "Dit kan niet om technische redenen, zelfs al haal je er 5 personen bij", met de uitleg erbij in verstaanbaar nederlands (requirements & bpm & andere blahblah verstaanbaar uitgelegd)
General manager : "We trekken een extern consultant aan om dit project te begeleiden"
Consultant : "Het platform zal WEL in productie draaien binnen de 11 maanden"
Ik : "Onmogelijk"
General Manager : "Als je niet akkoord bent, mag je vertrekken"
Na een jaar consultant-blahblahblah ben ik vertrokken.

Ze zijn nu 15 maand verder, en ze hebben zelfs nog geen genormaliseerde data

Ik bedoel hiermee dat de meeste bedrijfsleiders het moeilijk hebben om het idee rond ICT te omvatten.

Met het gebruik van analogieen kan je inderdaad wel iets uitrichten, maar dat kan alleen maar wanneer de 'noob' al een beetje achtergrondkennis en associatief vermogen heeft. Ik kom dagelijks gebruikers tegen die al moeite hebben om de principes 'snelkoppeling' en 'harde schijf' te begrijpen....en dan kan je 't vergeten met je analogieen.

harde schijf = groot boek waar je alles in opschrijft.
geheugen = kladpapier
snelkoppeling = post-it die er tussen zit om het betreffende blad snel terug te vinden.

In het zoeken van analogieen ben ik intussen zeer bedreven geworden

Geef mensen niet meer informatie dan nodig is om iets te beschrijven, als ze meer willen weten, dan kan je ze altijd nog iets meer vertellen. Voor projectplannen is 't een goede gewoonte om naast een abstract document met de projectbeschrijving en 't functioneel ontwerp, ook een technisch onderbouwde beschrijving op te stellen, waar wel alles in genoemd wordt, beter bekend als het technisch ontwerp.

Volledig mee eens, maar dit lukt niet altijd, zie voorbeeld.

[MissingDog]

D4Skunk schreef op 05 januari 2004 @ 03:50:
[...]


Tot zover volg ik je volledig, maar er is hier 1 probleem : het management komt af met een voor hun zeer eenvoudig probleem, dat echter heel wat technische implicaties heeft, en dus ook meer kost en/of langer duurt dan zij plannen. Dan moet je uitleggen waarom het zo lang duurt, zij begrijpen de problematiek niet, en dan komt de aap uit de mouw.

Dit is natuurlijk ook een van de dingen waar 't management regelmatig de fout in gaat, zonder advies in te winnen van de mensen die weten hoe 't zit al een termijn bepalen voor 't uitrollen van een project.

Hoger in organisaties gaat 't vaak zo van 'hee, da's een leuk speeltje...het is nieuw...en de concurrent heeft 't ook, dus moeten wij dat ook heel snel hebben'.

Op dat punt loop je inderdaad tegen de genoemde problemen aan, dit is een van de dingen die ik meestal voor probeer te zijn door goed bij te blijven met de ontwikkelingen in technologie en binnen de organisatie...op die manier kan ik 'de baas' een beetje sturen naar wenselijke veranderingen en bij voorbaat al negatief advies uitbrengen, nog voordat er over gesproken wordt in vergaderingen.

knip

Ik weet natuurlijk niet waar de technische problemen lagen, maar ik ben maar zelden tegen problemen aangelopen die echt niet binnen een aanzienbare termijn opgelost/overwonnen konden worden.
Meestal zijn de problemen afkomstig uit exotische soft-/hardware overerving, veelal maatwerktoepassingen, het wiel opnieuw uitvinden is mij niet vreemd meer en vaak sneller dan wachten op de oorspronkelijke leverancier. Hardware-gerelateerde problemen vragen om een andere aanpak, maar zijn vaak met een bescheiden investering (manuren/equipment) op te lossen.

Dat je verzocht werd te vertrekken vind ik wel heel ver gaan, iemand anders op 't project zetten...ok, maar dit getuigt van totaal geen vertrouwen in de eigen medewerkers. Iedereen kan wel eens een fout maken of iemand tegen zich in 't harnas jagen.
Een planning die jij -de specialist- bestempelt als onrealistisch en met argumenten kan weerleggen, zou toch op z'n minst herzien moeten worden op een of andere manier. Maar het blijkt in elk geval dat 't overzicht over de dieper liggende zaken niet aanwezig was bij de machthebbenden.

harde schijf = groot boek waar je alles in opschrijft.
geheugen = kladpapier
snelkoppeling = post-it die er tussen zit om het betreffende blad snel terug te vinden.

In het zoeken van analogieen ben ik intussen zeer bedreven geworden

Zijn voor mij duidelijke analogieen, maar voor 'n gebruiker die z'n systeemkast aanziet voor harde schijf en z'n monitor voor 'de pc'....is 't nog geen ABC. Als 'k de tijd heb maak ik bij zo iemand de pc ff open en laat 'k zien wat er nou in die 'magische doos' zit, met een heldere uitleg. Mensen zijn visueel ingesteld en leren stukken sneller wanneer 't in woord en beeld uitgelegd wordt.

Maar ik dwaal nu weer af naar de gebruikers...terug naar de leidinggevenden...toch weer op 't visuele aspect terug....

Bij een van m'n vorige werkgevers wilde men bezuinigen op de IT uitgaven, omdat 't budget erg ruim was en vanwege 't feit dat er meer met de zusterondernemingen samen gedaan zou worden.
Ik zag de bui al hangen...serverconsolidaties, handhaving van de 10mbit switches ipv nieuwe 100mbit modules in de procurve etc. Ben toen aan 't tekenen gegaan in visio en heb alle hardware in kaart gebracht per afdeling, een overzichtkaart van de infrastructuur en een hoop grafieken & cijfers met betrekking tot de servers en de netwerkload. Een begeleidend document geschreven, voor & tegen argumenten neergezet.
Afspraak met de directeur gemaakt om 't zooitje te presenteren...was 'm ineens duidelijk dat 't toch minder haalbaar was dan hij had gedacht, zonder het document ook maar te lezen. Was er in totaal 3,5 uur mee bezig geweest + uurtje presenteren (goede logging + trafficanalyse hebben ook meegewerkt).

Plaatjes doen wonderen voor mensen die geen technische kennis hebben, beetje persoonlijke uitleg erbij en 't is veel duidelijker. Natuurlijk is niet alles in beeld te vangen, maar als je de informatie selectief, geordend en beknopt brengt, kan je een hoop overbrengen zonder vragen naar randverschijnselen en ongewenste alternatieven te hoeven beantwoorden.

[D4Skunk]

MissingDog schreef op 05 januari 2004 @ 05:02:

[...]


Ik weet natuurlijk niet waar de technische problemen lagen, maar ik ben maar zelden tegen problemen aangelopen die echt niet binnen een aanzienbare termijn opgelost/overwonnen konden worden.
Meestal zijn de problemen afkomstig uit exotische soft-/hardware overerving, veelal maatwerktoepassingen, het wiel opnieuw uitvinden is mij niet vreemd meer en vaak sneller dan wachten op de oorspronkelijke leverancier. Hardware-gerelateerde problemen vragen om een andere aanpak, maar zijn vaak met een bescheiden investering (manuren/equipment) op te lossen.

Het grootste probleem was eigenlijk organisatorisch; er was/is nl nooit voor iemand (iets meer dan 100 personen in totaal) een duidelijke functieomschrijving opgemaakt. Dus, het hele bedrijf moest in kaart gebracht worden, de bedrijfsprocessen & verantwoordelijkheden moesten bepaald worden. Wanneer je zo'n dossier opstelt, en door het management laat corrigeren, mag je je verwachten aan een termijn van enkele maanden, vooraleer alle verantwoordelijkheden en processen afgebakend zijn; vooral gezien het feit dat er voor iedere functie uitzonderingen waren, en men alles toch zeer strikt wou beveiligen.

Dat je verzocht werd te vertrekken vind ik wel heel ver gaan, iemand anders op 't project zetten...ok, maar dit getuigt van totaal geen vertrouwen in de eigen medewerkers. Iedereen kan wel eens een fout maken of iemand tegen zich in 't harnas jagen.
Een planning die jij -de specialist- bestempelt als onrealistisch en met argumenten kan weerleggen, zou toch op z'n minst herzien moeten worden op een of andere manier. Maar het blijkt in elk geval dat 't overzicht over de dieper liggende zaken niet aanwezig was bij de machthebbenden.

My point exactly ! nu ja, volgens mij kan je het vergelijken met de loterij : een waterkansje, maar als je wint ...
IMHO heeft hij dus verloren

[...]
Plaatjes doen wonderen voor mensen die geen technische kennis hebben, beetje persoonlijke uitleg erbij en 't is veel duidelijker. Natuurlijk is niet alles in beeld te vangen, maar als je de informatie selectief, geordend en beknopt brengt, kan je een hoop overbrengen zonder vragen naar randverschijnselen en ongewenste alternatieven te hoeven beantwoorden.

Ander (jammergenoeg uit de werkelijkheid) voorbeeldje :
initiatief: Optimalisatie van de telecom-infrastructuur : 5 beste marktspelers laten langskomen na marktstudie , volledig dossier uitgewerkt, zelfs kosten voor aanleg fiber laten bereken (er moesten 3 straten opengebroken worden )
conclusie: lijvig dossier met kosten/opbrengsten... besparing van duizenden euro's per jaar
resultaat : we verhuizen al onze telecom naar vriend van x, dossier vertikaal geklasseerd


Ach ja, doet mij denken aan die verhalen van de BOFH (van the register)

[Verwijderd]

Ik mis in dit topic de wetenschappelijke en/of levensbeschouwelijke aspecten. Het topic zou wel in Stuffis Generalis passen, maar daar kan de topicstarter nog niet in. Daarom sluit ik dit topic

[Confusion]

Huh, ik dacht dat ik dat vanmorgen om 08:00 al had gedaan