Het gat tussen business en IT: business blijft achter

[defiant]

Aangezien de titel een limiet heeft wil ik beginnen met de stelling iets uitgebreider neer te zetten:
Het gat tussen business en IT: de business blijft tegenwoordig nog steeds achter

Het concept van het z.g.n. gat tussen business en IT in een IT organisatie komt vaak naar boven, d.w.z. de business heeft onvoldoende IT kennis en de IT heeft onvoldoende business kennis, als gevolg daarvan ontstaat er op alle verschillende niveaus (strategisch, tactisch en operationeel) een gat met negatieve gevolgen voor zowel IT als business.

Het scenario wat ik hier voorleg gaat dus IT bedrijven zelf, niet om klant/leverancier relaties. Ik richt me in dit deze post op software ontwikkeling, maar dit kan natuurlijk ook van toepassing zijn op beheer, devops, etc.

De business vraagt zich af waarom bepaalde dingen in IT moeizaam gaan, zoals bijvoorbeeld planning en de implementatie van features. De IT vraagt zich vervolgens af waarom de business niet begrijpt dat bepaalde zaken niet kunnen of niet haalbaar zijn zonder negatieve gevolgen op de lange en korte termijn.

Edit: Ter verduidelijking, ik bedoel dus de business die ICT aanstuurt binnen een bedrijf, dit kan zowel een bedrijf zijn voor wie ICT in het primaire proces zit, maar ook een ondersteunende ICT business unit.

Ik heb het dus niet over interne of externe afnemers/klanten van ICT diensten of producten..

Echter, dit probleem is de afgelopen decennia al uitgebreid onderwerp geweest van onderzoek en diverse bekende boeken zijn al geschreven over dit probleem. Met de bekende werken zoals o.a. The Mythical Man-Month, Peopleware: Productive Projects and Teams, Joel on Software, etc.

Je zou hierdoor zeggen dat het ook voor de business vanuit literatuur, opleiding, etc genoeg materiaal moet zijn om de IT projecten goed te begrijpen.Toch zijn er nog een hoop mensen in de business die geen of onvoldoende kennis hebben en de IT projecten verkeerd aansturen, ondanks bewegingen zoals Agile/Scrum die door deze mensen dan ook vaak verkeerd worden ingezet. Persoonlijk zie ik dat mensen in de business die aan goed IT project management en aansturing kunnen doen vaak zelf een verleden hebben uit de praktijk en hierdoor beter weten waarom de IT zo werkt.

Mijn stelling is dan ook dat als je in een IT organisatie van de business een bepaald niveau, enkele voorbeelden volgen hieronder, van kennis van IT mag verwachten.

Is dit terrecht of onterecht ?

Met IT kennis bedoel ik niet diepgaande technische kennis, maar concepten zoals:

• De gevolgen van team grootte en bijhorende communicatie overhead op het project
• Het concept van technical debt en de gevolgen daarvan voor toekomstig planning en feature ontwikkeling.
• Waar de complexiteit ligt binnen het product domein en welke gevolgen dat heeft.
• Welke gevolgen onzekerheid en veranderende requirements hebben op het project.

Etc etc.

Vanzelfsprekend heb je ook de IT die de business moet begrijpen, maar mijn observatie is dat dit al voldoende onder de aandacht komt o.a. bij IT opleidingen waarin de business qua project management en product ontwikkeling vakken aan bod komen. Als je hier mee oneens bent, is dat ook onderdeel van de stelling.

[ Voor 4% gewijzigd door defiant op 20-06-2019 21:49 ]

[feelthepower]

Wat is voor jou “business”? Alles buiten IT?

Ik erken wel dat het door je genoemde gat bestaat, daarom heb ik als business/IT analyst werk. In de meer traditionele bedrijven rapporteert een CIO aan de CFO. Bijvoorbeeld bij Shell is dat nog steeds zo. Daarmee zou je verwachten dat IT een ondergeschikte / dienstverlenende rol aanneemt. Het primaire proces van een bedrijf is vaak niet IT, maar doorgaand op het voorbeeld van Shell olie/gas oppompen, verwerken, verhandelen en verkopen aan consument. Dat data & digitalisation steeds belangrijker wordt en daarmee de traditionele scheidslijn begint te vervagen betekent niet dat IT het primaire proces is geworden in alle bedrijven. Natuurlijk snap jij IT beter. Jij werkt continu in de IT, draait projecten, interesseert je voor vakinhoudelijke ontwikkelingen, etc. Iemand die dichter bij het primaire proces van een bedrijf staat zal logischerwijs daar beter van op de hoogte zijn. Dat is echt geen kennis die je op je IT opleiding er even bij leert.

[MAX3400]

Oneens met de stelling in de startpost; als ik objectief om me heen kijk de afgelopen jaren dan is het snapt "de IT afdeling" echt een veel groter stuk van "de business" dan je lief is. Daar hebben ze dus allerlei specialisten in dienst die de basis-infra (hardware, software, monitoring, reporting in de breedste zin van het woord) in stand houden. Daarbij zijn IT'ers vaak geconformeerd aan de kantoortijden van de business; support van tijd A tot B en dan pas vaak maintenance / major changes buiten die tijden.

Ik heb zowel outsourcing gedaan, interne IT, "derde lijn ingehuurd" voor allerlei grote en kleine bedrijven. Als ik 1 grote rode bizarre draad zie: de gemiddelde business heeft ook geen idee wat ze zelf aan services afnemen in een organisatie en dienen daarnaast (onterechte) tickets in over van alles en nog wat. Dit staat dan nog los van de budgetten / kostenposten waar bepaalde services uit betaald zouden moeten worden.

De startpost grens aan "wie is technisch beheerder van een applicatie"; zonder exact gedefinieerde stakeholders, DAP, SLA, etc. zie je vaak dat de business vindt dat IT "technisch" is terwijl voor veel applicaties "de IT'er" helemaal geen appliciatie-inhoudelijke logins / kennis / documentatie heeft gekregen van de business.


Allicht wil je je stelling veranderen?

Het gat tussen business en IT: de business blijft tegenwoordig nog steeds achter

In deze stelling; als een gat achterblijft, is het in ieder geval niet groter aan het worden noch belemmert het de primaire processen

[ Voor 23% gewijzigd door MAX3400 op 20-06-2019 07:47 ]

[Pizza_Boom]

Wat ik hierin even mis: Hebben we het hier primair over bedrijven die IT afnemen om hun proces te ondersteunen, waarbij de IT dus van onderschikt belang is aan de business én de productie en primair moet dienen, of over bedrijven die IT verkopen, waarbij de business dus de IT aan de man moet brengen?

[Mawlana]

Dit is toch de reden dat er information/business analysten binnen organisaties zijn die de brug vormen tussen business en IT? In mijn ervaring zijn dit vaak mensen veel kennis (niet specialistisch) van de business met een IT achtergrond (ook niet specialistisch).

defiant schreef op donderdag 20 juni 2019 @ 00:26:
Vanzelfsprekend heb je ook de IT die de business moet begrijpen, maar mijn observatie is dat dit al voldoende onder de aandacht komt o.a. bij IT opleidingen waarin de business qua project management en product ontwikkeling vakken aan bod komen. Als je hier mee oneens bent, is dat ook onderdeel van de stelling.

Bij zo'n opleiding krijg je wel wat mee van project management en productontwikkeling, maar niet van dé business van het bedrijf waar je werkt. Je moet die business begrijpen, niet de "algemene" business. Theorie is leuk, maar komt niet altijd overeen met de praktijk.

[ Voor 56% gewijzigd door Mawlana op 20-06-2019 08:23 ]

[FireDrunk]

Business Analisten? Dat is toch de tweede generatie Architecten?
Van die mensen "blokje -> pijltje -> blokje" tekenen, en dan zeggen, "Ja, dat moet met elkaar interfacen.".

Developers / Ops: "Hoe wil je dat we dat doen? Er is geen standaard interface, dus dat kan niet zomaar."
Architect / Analist: "Ja hoor eens, dat weet ik niet hoor, dat is te technisch, dat is jullie werk"

/rant

[ Voor 7% gewijzigd door FireDrunk op 20-06-2019 08:31 ]

[_vision]

FireDrunk schreef op donderdag 20 juni 2019 @ 08:30:
Business Analisten? Dat is toch de tweede generatie Architecten?
Van die mensen "blokje -> pijltje -> blokje" tekenen, en dan zeggen, "Ja, dat moet met elkaar interfacen.".

Developers / Ops: "Hoe wil je dat we dat doen? Er is geen standaard interface, dus dat kan niet zomaar."
Architect / Analist: "Ja hoor eens, dat weet ik niet hoor, dat is te technisch, dat is jullie werk"

/rant

De rollen kunnen overlap hebben, maar architecten houden zich ook bezig met vraagstukken die business analisten niet raken. Daarbij hangt er vanaf over wat voor soort architecten je het hebt. Er is bijv. een wereld van verschil tussen een infra en een enterprise architect.

Ik heb bijv. werk gedaan zoals applicatie-rationalisatie: hoe kun je 1000 applicaties terugbrengen naar 900? Of het opzetten van Architectuur Governance: welke principes moet je opstellen en handhaven om te zorgen dat het IT-landschap niet een teringzooi wordt.

[Furion2000]

@sylvesterrr

Business -> tussenpersoon (PM, Business Analist) -> IT'er?

Met mijn beperkte ervaring, dus correct me if i'm wrong, zie ik dat eerder zo.

Business zonder IT begrip komt met wens van de klant en heeft vaak stiekem al toegezegd aan de klant -> PM met vooral product kennis, als je geluk hebt ook IT kennis, met enorm veel 'ruis' naar de IT'er -> IT'er gaat aan het werk met de interpretatie van de PM, die een interpretatie van Business krijgt, die weer een wens van de klant krijgt en dat interpreteert. Als gevolg, bouwen zij die schommel met de achtbaan en ze wilde dus die doodnormale schommel (bekenste voorbeeld volgens mij).

Wat ik nu steeds hoor is dat bedrijven soort focus groepen doen, waarbij alle steakholders (e.g. pm, consultant, developer, analist, UX) van binnen het bedrijf in een ruimte komen met een selectie gebruikers en dan die boel gaan neerzetten. Ik vind dat een enorme verbetering.

Haal de tussenpersonen weg en prop de stakeholders in een ruimte, maak een Mockup, verifieer en bouw een MVP. De IT moet dichter bij de klant komen en dat moet business begrijpen is nu mijn mening, alleen die mening kan altijd veranderen door goede tegenargumenten .

Maar ook een gevolg en meer richtend op TS, business kan zo business blijven doen en de IT de IT en kan iedereen zich blijven richten op zijn eigen vakgebied en pakt stiekem veel van elkaar op.

[ Voor 5% gewijzigd door Furion2000 op 20-06-2019 09:01 ]

[Mawlana]

Furion2000 schreef op donderdag 20 juni 2019 @ 08:45:
@sylvesterrr

Business -> tussenpersoon (PM, Business Analist) -> IT'er?

Met mijn beperkte ervaring, dus correct me if i'm wrong, zie ik dat eerder zo.

Business zonder IT begrip komt met wens van de klant en heeft vaak stiekem al toegezegd aan de klant -> PM met vooral product kennis, als je geluk hebt ook IT kennis, met enorm veel 'ruis' naar de IT'er -> IT'er gaat aan het werk met de interpretatie van de PM, die een interpretatie van Business krijgt, die weer een wens van de klant krijgt en dat interpreteert. Als gevolg, bouwen zij die schommel met de achtbaan en ze wilde dus die doodnormale schommel (bekenste voorbeeld volgens mij).

Wat ik nu steeds hoor is dat bedrijven soort focus groepen doen, waarbij alle steakholders (e.g. pm, consultant, developer, analist, UX) van binnen het bedrijf in een ruimte komen met een selectie gebruikers en dan die boel gaan neerzetten. Ik vind dat een enorme verbetering.

Haal de tussenpersonen weg en prop de stakeholders in een ruimte, maak een Mockup, verifieer en bouw een MVP. De IT moet dichter bij de klant komen en dat moet business begrijpen is nu mijn mening, alleen die kan altijd veranderen door goede tegenargumenten .

Maar ook een gevolg en meer richtend op TS, business kan zo business blijven doen en de IT de IT en kan iedereen zich blijven richten op zijn eigen vakgebied en pakt stiekem veel van elkaar op.

Ik beredeneerde het meer vanuit een grote organisatie met eigen IT-afdeling (deels outsourced) en productontwikkeling.

IT heeft 0,0 kaas gegeten van de business en vice versa (uitzonderingen daargelaten). De business komt met high-level plannen, en één of meerdere analisten/architecten werken het verder in detail uit (in samenspraak met de business en IT). De analisten (in dienst bij IT en/of business) en architecten (IT) spreken dezelfde "taal", hebben brede kennis van IT en business. Zoedoende kunnen zij de brug vormen tussen de business en IT, en zelfs met elkaar meedenken.

Gaat het altijd goed? Nee, maar dat komt 9 van de 10 keren door bemoeienis van bovenaf. Altijd leuk om "I told you so" achteraf te kunnen zeggen.

[stijnislike]

sylvesterrr schreef op donderdag 20 juni 2019 @ 09:06:
[...]

Ik beredeneerde het meer vanuit een grote organisatie met eigen IT-afdeling (deels outsourced) en productontwikkeling.

IT heeft 0,0 kaas gegeten van de business en vice versa (uitzonderingen daargelaten). De business komt met high-level plannen, en één of meerdere analisten/architecten werken het verder in detail uit (in samenspraak met de business en IT). De analisten (in dienst bij IT en/of business) en architecten (IT) spreken dezelfde "taal", hebben brede kennis van IT en business. Zoedoende kunnen zij de brug vormen tussen de business en IT, en zelfs met elkaar meedenken.

Gaat het altijd goed? Nee, maar dat komt 9 van de 10 keren door bemoeienis van bovenaf. Altijd leuk om "I told you so" achteraf te kunnen zeggen.

Het probleem geef je zelf al aan. IT heeft 0,0 kaas gegeten van de business. Dat de business geen kaas gegeten heeft van IT ben je als IT afdeling toch zelf bij? Je kan toch een keer uitleggen of een sessie organiseren om wat meer bewustzijn wat IT is in de organisatie te brengen. Als IT 0,0 kaas heeft gegeten van de business gaat er ook zeker wat fout. IT ondersteunt de business, tenzij het een puur IT bedrijf is en het primaire proces IT zaken behelst.

Zowel de business als de IT-ers moeten hard aan de bak om deze kloof te dichten, als dat niet gebeurt ga je inderdaad veel oplossingen aanbieden waar de business niet veel nuttigs mee kan. Zo ingewikkeld is het allemaal niet. Veel traditionele IT-ers geven maar al te graag de business de schuld van van alles.

[Croga]

Ik blijf het grappig vinden dat we nogsteeds praten over "IT" en over "Business".....

Bij veel bedrijven wordt IT nog gezien als een "resource". Vergelijkbaar met een kantine, een lift, een telefoon. IT wordt gezien als "dat moet gewoon werken" en dus is er niemand die zich wil verdiepen in IT, net zo min als dat men zich wil verdiepen in de werking van de lift of hoe je een ei kookt.
Dit is een direct gevolg van een fout in complexiteits-inschatting. Dave Snowden is beroemd geworden met zijn Cynefin framework waarin dit uitgelegd wordt. IT wordt door veel bedrijven gezien als "Simpel" terwijl het toch echt minstens gecompliceerd en veelal complex is. Dave heeft ook uitgelegd wat er bij zo'n verkeerde inschatting gebeurt.

En dus hebben we afgelopen decennia allerlei bruggetjes bedacht. Service Managers, Informatie analisten, Functioneel ontwerpers zijn allemaal lapmiddeltjes om de gevolgen van die verkeerde inschatting te mitigeren.

Één van de bewegingen die ik, hier en daar succesvol, zie gebeuren is het stoppen met het "Business" vs "IT" vraagstuk. Haal al die klassieke lapmiddeltjes er nou eens gewoon tussenuit. Al die bruggetjes gewoon op staande voet ontslaan. Plotseling weet de ITer niets meer en de niet-ITer nog minder. En wat zie je gebeuren? Die mensen gaan met elkaar praten. In plaats van dat de ITer stug volhoudt aan wat de functioneel ontwerper hem verteld, gaat hij bij het realiseren van een stukje functionaliteit praten met degene die die functionaliteit uiteindelijk moet gebruiken. En plots begrijpt die gebruiker de uitdagingen van de ITer en begrijpt de ITer de uitdagingen van de gebruiker.

Als mooiste voorbeeld gebruik ik altijd een project wat ik een jaar of 15 geleden gedaan heb. Een applicatie was meertalig gebouwd. Bij het openen van een formulier werd gekeken naar de taal van de gebruiker en werden alle teksten en veldlabels via een lookup uit een database gehaald. Een database die in Parijs stond en waar de gebruiker via een verbinding langs Antwerpen heen ging. Let wel, een 1Mbit verbinding naar Antwerpen (met 600 gebruikers) en vervolgens een 4Mbit verbinding van Antwerpen naar Parijs (met 3500 gebruikers). Je kunt je voorstellen dat dit niet echt werkte.
Dus met alle goede moed hadden de technsich ontwerpers bedacht dat het een optie zou zijn om alle teksten en labels met 1 lookup op te halen in plaats van allemaal losse queries. Helaas was het platform beperkt in de hoeveelheid data die 1 query kon ophalen.
Ik, als "lowly" programmeur was in mijn eentje hier aan aan het werken en dús zat ik naast de grootste gebruikers van dit systeem. We kwamen aan het praten en ik legde dit dilemma voor. Daarop kwamen de gebruikers met "Ja, er zijn wel 25 talen in de database maar eigenlijk gebruiken we er maar 3". En dus heb ik 3 aparte formulieren gebouwd zonder enige query voor het ophalen van de taal-specifieke onderdelen. En plots was de performance weer meer dan genoeg. Alleen maar omdat er niemand tussen zat.

Zodra de concepten IT en business verworpen worden en we met z'n allen begrijpen dat 80% van de bedrijven in Nederland meer op IT leunen dan wat anders zal deze brug geslecht worden. Dat betekend dus ook géén IT afdeling meer, geen virtuele potjes met geld, geen loskoppeling van ontwikkeling en resultaat, geen proces-kennis-verlies door hele bergen bureaucratie. Gewoon mensen die met elkaar samenwerken om een bedrijfsdoel te realiseren, by whatever means necessary!

[Hydra]

Business en IT zijn geen twee aparte 'groepen'. Als je schuttingen neerzet dan krijg je automatisch problemen met communicatie. Integreer 'business' dus gewoon met je teams. Het is niet voor niets dat het tegenwoordig hardstikke normaal is Customer Journey Experts, Business Analysten, etc. in je team te hebben zitten.

Het is geen kwestie van business IT te 'leren' en ik vind dat eerlijk gezegd een vrij typische arrogante houding van veel developers ("ja al die gebruikers snappen niks van software!", duh, da's jouw werk).

[ Voor 24% gewijzigd door Hydra op 20-06-2019 11:05 ]

[Standeman]

Croga schreef op donderdag 20 juni 2019 @ 10:13:
Ik blijf het grappig vinden dat we nogsteeds praten over "IT" en over "Business".....

Bij veel bedrijven wordt IT nog gezien als een "resource". Vergelijkbaar met een kantine, een lift, een telefoon. IT wordt gezien als "dat moet gewoon werken" en dus is er niemand die zich wil verdiepen in IT, net zo min als dat men zich wil verdiepen in de werking van de lift of hoe je een ei kookt.
Dit is een direct gevolg van een fout in complexiteits-inschatting. Dave Snowden is beroemd geworden met zijn Cynefin framework waarin dit uitgelegd wordt. IT wordt door veel bedrijven gezien als "Simpel" terwijl het toch echt minstens gecompliceerd en veelal complex is. Dave heeft ook uitgelegd wat er bij zo'n verkeerde inschatting gebeurt.

En dus hebben we afgelopen decennia allerlei bruggetjes bedacht. Service Managers, Informatie analisten, Functioneel ontwerpers zijn allemaal lapmiddeltjes om de gevolgen van die verkeerde inschatting te mitigeren.

Één van de bewegingen die ik, hier en daar succesvol, zie gebeuren is het stoppen met het "Business" vs "IT" vraagstuk. Haal al die klassieke lapmiddeltjes er nou eens gewoon tussenuit. Al die bruggetjes gewoon op staande voet ontslaan. Plotseling weet de ITer niets meer en de niet-ITer nog minder. En wat zie je gebeuren? Die mensen gaan met elkaar praten. In plaats van dat de ITer stug volhoudt aan wat de functioneel ontwerper hem verteld, gaat hij bij het realiseren van een stukje functionaliteit praten met degene die die functionaliteit uiteindelijk moet gebruiken. En plots begrijpt die gebruiker de uitdagingen van de ITer en begrijpt de ITer de uitdagingen van de gebruiker.

Als mooiste voorbeeld gebruik ik altijd een project wat ik een jaar of 15 geleden gedaan heb. Een applicatie was meertalig gebouwd. Bij het openen van een formulier werd gekeken naar de taal van de gebruiker en werden alle teksten en veldlabels via een lookup uit een database gehaald. Een database die in Parijs stond en waar de gebruiker via een verbinding langs Antwerpen heen ging. Let wel, een 1Mbit verbinding naar Antwerpen (met 600 gebruikers) en vervolgens een 4Mbit verbinding van Antwerpen naar Parijs (met 3500 gebruikers). Je kunt je voorstellen dat dit niet echt werkte.
Dus met alle goede moed hadden de technsich ontwerpers bedacht dat het een optie zou zijn om alle teksten en labels met 1 lookup op te halen in plaats van allemaal losse queries. Helaas was het platform beperkt in de hoeveelheid data die 1 query kon ophalen.
Ik, als "lowly" programmeur was in mijn eentje hier aan aan het werken en dús zat ik naast de grootste gebruikers van dit systeem. We kwamen aan het praten en ik legde dit dilemma voor. Daarop kwamen de gebruikers met "Ja, er zijn wel 25 talen in de database maar eigenlijk gebruiken we er maar 3". En dus heb ik 3 aparte formulieren gebouwd zonder enige query voor het ophalen van de taal-specifieke onderdelen. En plots was de performance weer meer dan genoeg. Alleen maar omdat er niemand tussen zat.

Zodra de concepten IT en business verworpen worden en we met z'n allen begrijpen dat 80% van de bedrijven in Nederland meer op IT leunen dan wat anders zal deze brug geslecht worden. Dat betekend dus ook géén IT afdeling meer, geen virtuele potjes met geld, geen loskoppeling van ontwikkeling en resultaat, geen proces-kennis-verlies door hele bergen bureaucratie. Gewoon mensen die met elkaar samenwerken om een bedrijfsdoel te realiseren, by whatever means necessary!

Vooral dit ^^

Complexiteit wordt enorm onderschat door de business. Hoe vaak ik managers heb gezien die volkomen flabbergasted (tot zelfs boos) waren omdat in hun ogen een simpele feature veel meer tijd kost om te implementeren dan zij dachten. Bij het onderbouwen van mijn inschatting, wanneer ik die kans kreeg, raakte ze regelmatig de weg kwijt.

Aan de andere kant lijkt IT niet te begrijpen dat de wereld om hun heen niet statisch is en voortdurend veranderd. Iets wat je morgen gaat implementeren kan gisteren al weer achterhaald zijn.

[nextware]

Ik heb je stelling gelezen, maar naar maar mijn idee wordt het "onbegrip" tussen beide onderdelen (IT enerzijds en Business anderzijds) vooral veroorzaakt door het gebrek aan communicatie.

Maar, en andere posters boven mij geven het aan, zien veel bedrijven IT als (onnodige) kostenpost. De "Business" zou IT eigenlijk als strategie moeten zien om hun processen / bedrijfsvoering te optimaliseren.

Wanneer een bedrijf dit zal toepassen, zul je zien dat de IT en Business meer gaan samenwerken. Hierdoor zal de communicatie ook toenemen. Daarnaast moeten er ook gewoon goede afspraken / procedures gedefinieerd worden waarbij input van beide onderdelen nodig is om tot een goede samenwerking te komen. Dan zul je zien dat het "gat" wat je beschrijft (ver) gedicht zal worden.

[Mawlana]

Standeman schreef op donderdag 20 juni 2019 @ 11:20:
[...]
Aan de andere kant lijkt IT niet te begrijpen dat de wereld om hun heen niet statisch is en voortdurend veranderd. Iets wat je morgen gaat implementeren kan gisteren al weer achterhaald zijn.

Dit vooral.

[Lensent]

IT zou meer kennis en inzicht moeten krijgen van de business (de klant van IT) om het bedrijfsproces optimaal te kunnen blijven ondersteunen.
IT is een middel en dus altijd dienstverlenend.

De business heeft logischerwijs alleen maar verstand hebben van hun eigen ding, of dat nou auto's bouwen is, een operatie aan een orgaan utivoeren of het zagen van kozijnen.
IT moet snappen wat de business nodig heeft om mee te blijven doen en concurrerend te blijven, maar business moet op zijn beurt ook helder kunnen maken waar behoefte aan is.

Wisselwerking moet er dus altijd zijn en daar heb je een goede vertrouwensband voor nodig zonder ego's. Je moet met beide 'groepen' 1 front vormen.

En das in de praktijk niet makkelijk. IT'ers vinden zichzelf superieur want zij zullen wel even bepalen wat wel en niet mag, en de business kijkt argwanend naar IT want 'ze snappen ons niet'.

[ Voor 9% gewijzigd door Lensent op 20-06-2019 12:34 ]

[menonv]

Weet je wat al helemaal ernstig is? Als de teamleider / projectleider van het IT team zich in principe op Business vlak bevindt. De rol van Business development & IT manager in 1.
Op het moment dat iets misgaat in het IT team zitten ze in Business, op het moment dat het stroef verloopt vanuit Business om keuzes te maken voor investeringen of kostenbesparingen, zitten ze in het IT Team.
(concreet voorbeeld, boven zitten bij Management, amper bij IT team, enkel en alleen bij problemen, oom agent uithangen bij het team)

Dat verloopt enorm stroef als je hier niet de juiste onderverdeling hebt. Wat (meerdere) business moet inzien is dat IT een draagvlak is binnen je onderneming om alles met elkaar te verbinden. (en werkend te houden in die zin, hoe je het ook wilt vertalen). En dat gaat alleen met de nodige communicatie en juiste procedures.
IT managers gebruiken hiervoor maar al te graag Scrum / Agile methodieken overigens, waarbij sommigen dit inzetten "om de rotte appels eruit te werken en om maar gewoon een term te hebben voor sollicitanten".
Raar maar waar.

Scrum / DEV-OPS i.c.m. Jira werd ingezet op mijn voorgaande werk en dit was een gigantische faal.
Het leek wel problem management, overmanagement. User stories waren problemen die moesten worden opgelost, en vervolgens beloond. Hierin bleef de IT manager gigantisch doordraaien, beloning t.z.t. jou performance stond gelinked aan of je je "problemen" goed kreeg opgelost, en op een tijdsefficiente manier.
(Lees, analyse, onderzoek en oplossing nodig binnen 4 uur voor Onbekend probleem.) IT manager was ook diegene die van het puntje uit zijn duim, nagel, wiv een indicatie maakte hoeveel tijd voor een probleem nodig was.

Je hebt IT managers en IT managers, zodra de verbinding er niet is en juiste vertaling naar Business dan gaat het volledig de verkeerde kant op, doe je alsof je Agile bezig bent, terwijl alles toch op het allerlaatste moment met een gigantische overwerkslag wordt opgeleverd (lees opgezadeld) aan de klant.

Het is maar net hoe je er naar kijkt. Business en IT dienen samen te werken zowel op process en continuiteit, en dan hebben beide partijen het meeste aan elkaar. Als het niet goed of vaag gedefinieerd is, en het "allemaal maar wat doet" en "probleem georienteerd" wordt gedacht, hou maar op.

[ Voor 6% gewijzigd door menonv op 20-06-2019 12:44 . Reden: grammatica, moeilijk ]

[Mugwump]

_vision schreef op donderdag 20 juni 2019 @ 08:43:
[...]


De rollen kunnen overlap hebben, maar architecten houden zich ook bezig met vraagstukken die business analisten niet raken. Daarbij hangt er vanaf over wat voor soort architecten je het hebt. Er is bijv. een wereld van verschil tussen een infra en een enterprise architect.

Ik heb bijv. werk gedaan zoals applicatie-rationalisatie: hoe kun je 1000 applicaties terugbrengen naar 900? Of het opzetten van Architectuur Governance: welke principes moet je opstellen en handhaven om te zorgen dat het IT-landschap niet een teringzooi wordt.

Dat is voor architecten heel simpel. Je vervangt vier blokjes in het oude diagram door één blokje in het nieuwe met een overkoepelendde naam en je hebt 3 applicaties minder.

Croga schreef op donderdag 20 juni 2019 @ 10:13:
I
Één van de bewegingen die ik, hier en daar succesvol, zie gebeuren is het stoppen met het "Business" vs "IT" vraagstuk. Haal al die klassieke lapmiddeltjes er nou eens gewoon tussenuit. Al die bruggetjes gewoon op staande voet ontslaan. Plotseling weet de ITer niets meer en de niet-ITer nog minder. En wat zie je gebeuren? Die mensen gaan met elkaar praten. In plaats van dat de ITer stug volhoudt aan wat de functioneel ontwerper hem verteld, gaat hij bij het realiseren van een stukje functionaliteit praten met degene die die functionaliteit uiteindelijk moet gebruiken. En plots begrijpt die gebruiker de uitdagingen van de ITer en begrijpt de ITer de uitdagingen van de gebruiker.

Als mooiste voorbeeld gebruik ik altijd een project wat ik een jaar of 15 geleden gedaan heb. Een applicatie was meertalig gebouwd. Bij het openen van een formulier werd gekeken naar de taal van de gebruiker en werden alle teksten en veldlabels via een lookup uit een database gehaald. Een database die in Parijs stond en waar de gebruiker via een verbinding langs Antwerpen heen ging. Let wel, een 1Mbit verbinding naar Antwerpen (met 600 gebruikers) en vervolgens een 4Mbit verbinding van Antwerpen naar Parijs (met 3500 gebruikers). Je kunt je voorstellen dat dit niet echt werkte.
Dus met alle goede moed hadden de technsich ontwerpers bedacht dat het een optie zou zijn om alle teksten en labels met 1 lookup op te halen in plaats van allemaal losse queries. Helaas was het platform beperkt in de hoeveelheid data die 1 query kon ophalen.
Ik, als "lowly" programmeur was in mijn eentje hier aan aan het werken en dús zat ik naast de grootste gebruikers van dit systeem. We kwamen aan het praten en ik legde dit dilemma voor. Daarop kwamen de gebruikers met "Ja, er zijn wel 25 talen in de database maar eigenlijk gebruiken we er maar 3". En dus heb ik 3 aparte formulieren gebouwd zonder enige query voor het ophalen van de taal-specifieke onderdelen. En plots was de performance weer meer dan genoeg. Alleen maar omdat er niemand tussen zat.

Zodra de concepten IT en business verworpen worden en we met z'n allen begrijpen dat 80% van de bedrijven in Nederland meer op IT leunen dan wat anders zal deze brug geslecht worden. Dat betekend dus ook géén IT afdeling meer, geen virtuele potjes met geld, geen loskoppeling van ontwikkeling en resultaat, geen proces-kennis-verlies door hele bergen bureaucratie. Gewoon mensen die met elkaar samenwerken om een bedrijfsdoel te realiseren, by whatever means necessary!

De meest ideale projecten die ik heb gedaan zijn inderdaad ook degenen waar ik toegang had tot 'de business'. Zo had ik bijvoorbeeld een project waar maandenlang door vele mensen was gewerkt aan functionele en technische specificaties omtrent de automatisering van wat financiële processen. Daar was echt een gedrocht van een oplossing uitgekomen. Toen heb ik in een maandlang intensief samengewerkt met de financieel procesmanager. Veel tekenen op een whiteboard, een teststructuur opzetten om zijn financiële controles te kunnen toetsen en ga zo maar door en er stond een prima oplossing die veel eenvoudiger, correcter en goedkoper was dan hetgeen men initieel in gedachten had.

De meest slechtlopende projecten waar ik op heb gezeten zijn die waar je volledig afhankelijk bent van business analisten die lang niet altijd even capabel zijn. Zo had ik er bijvoorbeeld een tijdje terug één die alles dacht te moeten vertalen naar 'ik wil CRUD op dit stukje data'. Met heel veel pijn en moeite hier en daar nog wel wat diepgravendere businesswensen kunnen achterhalen waarbij dan bleek dat er hele processen achter dat simpele CRUD-ideetje zaten die veel beter op een andere manier geautomatiseerd konden worden of soms juist helemaal niet geautomatiseerd hoefde te worden. Wat dat betreft hoeft de business in mijn ogen ook het liefst gewoon zo min mogelijk van IT te weten, maar heel veel van hun eigen domein.

-De gevolgen van team grootte en bijhorende communicatie overhead op het project
-Het concept van technical debt en de gevolgen daarvan voor toekomstig planning en feature ontwikkeling.
-Waar de complexiteit ligt binnen het product domein en welke gevolgen dat heeft.
-Welke gevolgen onzekerheid en veranderende requirements hebben op het project.

Kijkend naar deze door TS genoemde aspecten dan zie ik ook absoluut geen zaken die ik van 'de business' zou verwachten. Het is aan de mensen die dit soort wensen moeten realiseren om helder te communiceren wat de impact is van wensen en hoe zij het meest effectief werken. Zij hoeven van mij ook niet te verwachten dat ik bijvoorbeeld exact kan overzien wat de impact is van een bepaalde proceswijziging op het voldoen aan alle wet- en regelgeving op het gebied van compliance of iets dergelijks.

[_vision]

Mugwump schreef op donderdag 20 juni 2019 @ 16:19:
[...]


Dat is voor architecten heel simpel. Je vervangt vier blokjes in het oude diagram door één blokje in het nieuwe met een overkoepelendde naam en je hebt 3 applicaties minder.

Dat is dan geen beste architect als dat alles is.

Waarom deze applicaties en geen andere? Wat is de waarde voor de business en wat bespaart dat in termen van kosten? Heb je überhaupt de functionaliteit van die 3 applicaties nog nodig in de nieuwe ? Ga je die nieuwe applicatie nabouwen of off-the-shelf in kopen? Cloud of on-premise? En ik kan talloze andere vragen verzinnen waarop een developer geen antwoord hoeft te geven, maar een beetje enterprise architect hopelijk wel.

[Tsurany]

Het grootste probleem is het gat tussen management en de werkvloer. Management wilt bijvoorbeeld DevOps en Agile maar wel goedkoop dus met alleen maar Indiërs. Helaas kunnen die enkel met kant en klare opdrachten werken. Wie moet dan de requirements halen? Oh dan nemen we een paar schoolverlaters aan als business analisten want die zijn goedkoop.

Oh en we werken wel Agile maar we hebben wel een fixed scope, fixed deadline en een fixed team. En onze PO's zijn gewoon de projectleiders van vroeger.

En dan verbaasd zijn dat alles moeizaam gaat.

[Bossie]

Tsurany schreef op donderdag 20 juni 2019 @ 16:44:
Het grootste probleem is het gat tussen management en de werkvloer. Management wilt bijvoorbeeld DevOps en Agile maar wel goedkoop dus met alleen maar Indiërs. Helaas kunnen die enkel met kant en klare opdrachten werken. Wie moet dan de requirements halen? Oh dan nemen we een paar schoolverlaters aan als business analisten want die zijn goedkoop.

Oh en we werken wel Agile maar we hebben wel een fixed scope, fixed deadline en een fixed team. En onze PO's zijn gewoon de projectleiders van vroeger.

En dan verbaasd zijn dat alles moeizaam gaat.

Zijn wij collega’s

[Mugwump]

_vision schreef op donderdag 20 juni 2019 @ 16:32:
[...]


Dat is dan geen beste architect als dat alles is.

Waarom deze applicaties en geen andere? Wat is de waarde voor de business en wat bespaart dat in termen van kosten? Heb je überhaupt de functionaliteit van die 3 applicaties nog nodig in de nieuwe ? Ga je die nieuwe applicatie nabouwen of off-the-shelf in kopen? Cloud of on-premise? En ik kan talloze andere vragen verzinnen waarop een developer geen antwoord hoeft te geven, maar een beetje enterprise architect hopelijk wel.

Dat was uiteraard een geintje, maar in de praktijk werkt het nog wel eens zo helaas. Er zijn heel wat organisaties waarin er allerlei abstracte architectuurprincipes worden bedacht die in het gros van de gevallen juist heel onhandig, duur of onwerkbaar blijken.
Dan komt het wel eens voor dat mijn interpretatie wel eens wat creatief kan zijn wanneer een Enterprise architect staat op twee losse blokjes in zijn diagram.

Het soort vragen dat je hier opwerpt zijn overigens vragen waar ik me als lead / senior developer juist wel erg vaak mee bezighoudt. Cloud of on-premise heeft bijvoorbeeld vaak enorm veel impact op het developmentproces. De vragen die je hier schetst vind ik ook meer van het niveau solution architecture. Enterprise architecture houdt zich toch meer bezig met applicatie-overstijgende vraagstukken. Cloud vs on-premise kan best een vraagstuk zijn voor Enterprise architectuur, maar dan meer op het vlak van de overkoepelende strategie.

[Tsurany]

Bossie schreef op donderdag 20 juni 2019 @ 17:19:
[...]


Zijn wij collega’s

Financiële sector toevallig?

Zelfde verhaal hoor ik uit heel veel verschillende hoeken maar met name in de grote, logge organisaties. De constante push naar Agile werken zonder een idee te hebben hoe je dat nu echt aan moet pakken. Het lijkt allemaal zo simpel, gewoon wat zelfsturende teams die samen met de business lekker software gaan bouwen. Maar meetingrooms? We doen gewoon twee stuks per 10 teams, dat moet wel goed komen. Samenwerken met offshore? Brakke Webex/Skype oplossingen met matige audio apparatuur. Competente developers inhuren die met de business kunnen sparren? Sorry, we hebben net die dure architect moeten betalen dus het geld is op.

Het grootste probleem is dat we constant zoeken naar mensen die een brug kunnen slaan tussen business en IT terwijl we moeten kijken hoe we IT zo kunnen ontwikkelen dat er geen brug geslagen hoeft te worden. Dat doe je alleen niet door je developers uit de goedkoopste landen te halen...

Ja, het is echt een persoonlijke frustratie geworden... soms zit ik te denken om echt uit de IT te vertrekken en wat anders te gaan doen vanwege dit constante gezeik met incompetente "collega's".

[ Voor 8% gewijzigd door Tsurany op 20-06-2019 18:03 ]

[flyingdutchboy]

Ik ben al 15 jaar met plezier IT project manager, doe project na project. Mijn counterpart vanuit de business doet vaak maar 1 keer een project. Ik spreek daarom altijd heel duidelijk uit van ik van hem en zijn team verwacht. Activiteiten met owners als wel als de r&r worden vastgelegd. Gedurende het proces stuur ik hem bij als dat nodig is. Inhoudelijk zijn bv hij en zijn team verantwoordelijk voor het aanleveren van de requirement s . Een IT consultant kan hooguit helpen met het denkproces. De IT consultants bedenken echter de oplossing en de leveren die. Dit loopt bijna altijd gesmeerd

[Croga]

flyingdutchboy schreef op donderdag 20 juni 2019 @ 18:11:
Ik ben al 15 jaar met plezier IT project manager, doe project na project. Mijn counterpart vanuit de business doet vaak maar 1 keer een project. Ik spreek daarom altijd heel duidelijk uit van ik van hem en zijn team verwacht. Activiteiten met owners als wel als de r&r worden vastgelegd. Gedurende het proces stuur ik hem bij als dat nodig is. Inhoudelijk zijn bv hij en zijn team verantwoordelijk voor het aanleveren van de requirement s . Een IT consultant kan hooguit helpen met het denkproces. De IT consultants bedenken echter de oplossing en de leveren die. Dit loopt bijna altijd gesmeerd

Dat laatste mag een godswonder heten....\
Je hebt nu dus een gebruiker.
Die praat met een key user.
Die praat met een business analyst
Die praat met een functioneel ontwerper
Die praat met een technisch ontwerper
Die praat met een architect
Die praat met een ontwikkelaar
En dan nog loopt alles gesmeerd? Ik geloof er geen drol van.....

Zolang er nog een IT project manager, een business project manager, een requirements team en ontwerpers aan te pas komen ga je mij niet wijs maken dat jij die ene uitzondering op de regel bent. Dit is wat we 50 jaar lang gedaan hebben en wat al 50 jaar faalt.
Dit valt onder: "Insanity: doing the same thing over and over again and expecting different results."

[_vision]

Mugwump schreef op donderdag 20 juni 2019 @ 17:57:
[...]


Dat was uiteraard een geintje, maar in de praktijk werkt het nog wel eens zo helaas. Er zijn heel wat organisaties waarin er allerlei abstracte architectuurprincipes worden bedacht die in het gros van de gevallen juist heel onhandig, duur of onwerkbaar blijken.
Dan komt het wel eens voor dat mijn interpretatie wel eens wat creatief kan zijn wanneer een Enterprise architect staat op twee losse blokjes in zijn diagram.

Het soort vragen dat je hier opwerpt zijn overigens vragen waar ik me als lead / senior developer juist wel erg vaak mee bezighoudt. Cloud of on-premise heeft bijvoorbeeld vaak enorm veel impact op het developmentproces. De vragen die je hier schetst vind ik ook meer van het niveau solution architecture. Enterprise architecture houdt zich toch meer bezig met applicatie-overstijgende vraagstukken. Cloud vs on-premise kan best een vraagstuk zijn voor Enterprise architectuur, maar dan meer op het vlak van de overkoepelende strategie.

Eens, in veel organisaties heeft architectuur (zeker Enterprise Architectuur) nog eens last van een ivoren toren syndroom.

Vraagstukken als cloud vs on-premise of build vs buy worden over het algemeen gedreven door strategische uitgangspunten en architectuur keuzes, en daar ligt ook een business case aan ter grond slag. Wel is het tijdig betrekken van solution architecten / lead developers handig in dit soort besluiten, maar dat is niet in elke organisatie zo evident merk ik.

[Sissors]

Croga schreef op donderdag 20 juni 2019 @ 10:13:
Ik blijf het grappig vinden dat we nogsteeds praten over "IT" en over "Business".....

Bij veel bedrijven wordt IT nog gezien als een "resource". Vergelijkbaar met een kantine, een lift, een telefoon. IT wordt gezien als "dat moet gewoon werken" en dus is er niemand die zich wil verdiepen in IT, net zo min als dat men zich wil verdiepen in de werking van de lift of hoe je een ei kookt.

Maar dat is toch ook gewoon zo? In de rest van je post zie ik niks wat dit ontkracht. Natuurlijk, het is complex. Er zijn wel meer dingen complex. Dan nog steeds moet het gewoon werken voor de rest van het bedrijf. Net als de lift en de kantine. En net als de lift en de kantine kan daar best weleens wat fout gaan. Maar dat veranderd niet dat bijvoorbeeld werkplekbeheer gewoon een ondersteunende functie is die moet werken.

En natuurlijk, ook bij 'traditionele' bedrijven zal je steeds meer hebben dat ook een gedeelte van de IT meer onderdeel wordt van de business. Maar genoeg ook niet. En daar lijkt mij niks mis mee.

Al die bruggetjes gewoon op staande voet ontslaan. Plotseling weet de ITer niets meer en de niet-ITer nog minder. En wat zie je gebeuren? Die mensen gaan met elkaar praten. In plaats van dat de ITer stug volhoudt aan wat de functioneel ontwerper hem verteld, gaat hij bij het realiseren van een stukje functionaliteit praten met degene die die functionaliteit uiteindelijk moet gebruiken. En plots begrijpt die gebruiker de uitdagingen van de ITer en begrijpt de ITer de uitdagingen van de gebruiker.

Natuurlijk, soms is directe interactie tussen de IT'er en de gebruiker het beste. Al heb je met een hele zooi gebruikers alsnog problemen dat je dan heel veel wensen krijgt, en het de vraag is welke relevant zijn en welke niet.

Maar die bruggetjes die jij graag op staande voet wil ontslaan die kunnen zo verschrikkelijk handig zijn als ze hun werk goed doen. Vooral bij complexere problemen:
Ik -> Bruggetje: Ding doet het niet
Bruggetje: [Reproduceert] - Ding doet het niet
Bruggetje -> IT: Ding doet het niet (En nu denkt iemand, daar zit een zinloze stap in)
IT -> Bruggetje: Probeer plan A
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan B
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan C
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan D
Bruggetje -> IT: Doet het wel
Bruggetje -> Mij: Doe plan D

En zo nog zat andere situaties waarbij dat bruggetje heel veel tijd voor mij heeft bespaard.

Dat betekend dus ook géén IT afdeling meer, geen virtuele potjes met geld, geen loskoppeling van ontwikkeling en resultaat, geen proces-kennis-verlies door hele bergen bureaucratie. Gewoon mensen die met elkaar samenwerken om een bedrijfsdoel te realiseren, by whatever means necessary!

Geen IT afdeling meer? Dus dan moet elke business unit zijn eigen systeembeheerders in dienst gaan nemen? Van de 7 business units hebben 4 een tool nodig, en die gaan allemaal hem apart laten ontwikkelen?

[unezra]

Persoonlijk vind ik dat de business de IT niet hoeft te begrijpen. De business moet doen wat ze doen, business bedrijven. Andersom vind ik veel belangrijker: De ICT, of iig een ICT adviseur, moet begrijpen waar de business behoefte aan heeft en continu naar de business blijven luisteren.

De business doet het goed, als ze én stoppen met in oplossingen te praten (daar hebben ze immers hun adviseurs voor) én beseffen dat ze ICT nodig hebben en in een vroeg stadium aanhaken. Verder heb ik het liefst dat de business denkt dat met ICT alles technisch mogelijk is (is ook zo, als je maar genoeg budget hebt) en zich niet laat beperken door onmogelijkheden die ze zelf hebben bedacht.

[Tsurany]

Sissors schreef op donderdag 20 juni 2019 @ 18:23:
Maar die bruggetjes die jij graag op staande voet wil ontslaan die kunnen zo verschrikkelijk handig zijn als ze hun werk goed doen. Vooral bij complexere problemen:
Ik -> Bruggetje: Ding doet het niet
Bruggetje: [Reproduceert] - Ding doet het niet
Bruggetje -> IT: Ding doet het niet (En nu denkt iemand, daar zit een zinloze stap in)
IT -> Bruggetje: Probeer plan A
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan B
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan C
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan D
Bruggetje -> IT: Doet het wel
Bruggetje -> Mij: Doe plan D

En zo nog zat andere situaties waarbij dat bruggetje heel veel tijd voor mij heeft bespaard.

En daar gaat het dus mis, waar jij denkt dat het bruggetje jou tijd bespaart merk je niet dat je onnodig lang op een oplossing zit te wachten puur omdat bruggetje en IT constant heen en weer zitten te communiceren.

Wat jij als gebruiker nodig hebt is een developer die de functionaliteit snapt, begrijpt waar jouw probleem vandaan komt en het op gaat lossen. Daar hoeft niemand tussen te zitten en daar hoeft helemaal geen pingpong tussen mensen plaats te vinden.

[Mugwump]

_vision schreef op donderdag 20 juni 2019 @ 18:20:
[...]


Eens, in veel organisaties heeft architectuur (zeker Enterprise Architectuur) nog eens last van een ivoren toren syndroom.

Vraagstukken als cloud vs on-premise of build vs buy worden over het algemeen gedreven door strategische uitgangspunten en architectuur keuzes, en daar ligt ook een business case aan ter grond slag. Wel is het tijdig betrekken van solution architecten / lead developers handig in dit soort besluiten, maar dat is niet in elke organisatie zo evident merk ik.

Dat laatste is wel een aardige understatement.
Cloud vs on-premise is uiteraard een overkoepelende overweging binnen grote organisaties, maar daarvoor geldt juist vaak dat het een "cloud tenzij..." strategie is, waarbij specifieke overwegingen voor een project of applicatie er toe kunnen leiden dat een andere keuze wordt gemaakt.

Goede strategie staat in mijn ogen uitzonderingen toe waar nodig. Al heb ik ook wel meegemaakt dat een organisatie duizenden architecturele richtlijnen had, waarbij elk project tientallen waivers kreeg en het gros van de richtlijnen sowieso onder de radar geschonden werd.

Ik zit nu ook weer in een project waar we een beetje overhoop liggen met Enterprise architectuur omdat er voor herbouw van een systeem een jaar of twee geleden een solution design is gemaakt met bijbehorende business case op basis waarvan uiteindelijk recent een project is gestart. Veel keuzes zijn gezien de twee jaar doorontwikkeling op het bestaande systeem en het beschikbaar komen van nieuwe alternatieven redelijk onverstandig. Maar ja, de keuzes zijn gemaakt en er zijn wat schattingen uit de losse pols gemaakt voor de kosten, dus dan zijn die beslissingen zowat heilig.
Dus dat wordt weer eens risico's inventariseren, benoemen en kwantificeren, PoCjes doen en eindeloze meetings om het nodige zendingswerk te verrichten.

[unezra]

Tsurany schreef op donderdag 20 juni 2019 @ 18:44:
[...]
En daar gaat het dus mis, waar jij denkt dat het bruggetje jou tijd bespaart merk je niet dat je onnodig lang op een oplossing zit te wachten puur omdat bruggetje en IT constant heen en weer zitten te communiceren.

Wat jij als gebruiker nodig hebt is een developer die de functionaliteit snapt, begrijpt waar jouw probleem vandaan komt en het op gaat lossen. Daar hoeft niemand tussen te zitten en daar hoeft helemaal geen pingpong tussen mensen plaats te vinden.

Dat werkt alleen, als die developer niet alleen de taal van de gebruiker spreekt, maar ook een goede kennis heeft van alle omliggende systemen, politiek, etc.

Persoonlijk geloof ik d'r niet in. Ik geloof meer in goede vertalers, spinnen in het web, die tussen business en techniek in zitten, alle stakeholders begrijpen en continu bezig zijn met zinvol informatie uitwisseling zodat de hele machine blijft draaien.

[Croga]

unezra schreef op donderdag 20 juni 2019 @ 19:03:
Dat werkt alleen, als die developer niet alleen de taal van de gebruiker spreekt, maar ook een goede kennis heeft van alle omliggende systemen, politiek, etc.

Ofwel: Als die developer onderdeel is van hetzelfde team als die gebruiker.....

Persoonlijk geloof ik d'r niet in. Ik geloof meer in goede vertalers, spinnen in het web, die tussen business en techniek in zitten, alle stakeholders begrijpen en continu bezig zijn met zinvol informatie uitwisseling zodat de hele machine blijft draaien.

Onderzoek wijst uit dat zelfs de beste vertaler informatie verliest. Iedere stap die er zit tussen het gebruik en de realisatie van het systeem zal het model minder nuttig maken. En dus draait de machine niet snel genoeg.

Maar je opmerking over "Alle stakeholders begrijpen" is wel een mooie. Conway's Law zegt

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

Aangezien IT altijd een apart onderdeel van het bedrijf was, is het ontwerp binnen de meeste bedrijven sterk monolitisch en IT gericht. Daarmee heb je dus één systeem wat voor alle stakeholders binnen het bedrijf moet werken. De noodzaak van afstemming met alle stakeholders komt daar vandaan.
Stap 1 zou dus moeten zijn: Organisatie aanpassen zodat mensen die vaak met elkaar samen moeten werken (zoals gebruikers en de mensen die de IT voor die gebruikers verzorgen) eenvoudig met elkaar kunnen communiceren. En voila, geen vertalers meer nodig.....

Onze management en organisatie principes stammen nog uit de jaren 50. Vlak na de tweede wereldoorlog. Toen productie het grootste belang was; nieuwe huizen, nieuwe infrastructuur, nieuwe televisies, alles produceren. En op basis daar van is het samenvoegen van mensen die hetzelfde truukje kennen gekomen. De organisatie structuren die dat oplevert zijn echter volledig zinloos in de tijd van innovatie en vooruitgang. En laat nou net dát de tijd zijn waar we in zitten; En dat kan dus niet meer met de organisatie structuren van toen dus voegen we lapmiddeltjes toe, in de vorm van "vertalers". Geen enkele toegevoegde waarde, wel vernietiging van kennis.

Sissors schreef op donderdag 20 juni 2019 @ 18:23:
Maar dat is toch ook gewoon zo? In de rest van je post zie ik niks wat dit ontkracht. Natuurlijk, het is complex. Er zijn wel meer dingen complex. Dan nog steeds moet het gewoon werken voor de rest van het bedrijf. Net als de lift en de kantine. En net als de lift en de kantine kan daar best weleens wat fout gaan. Maar dat veranderd niet dat bijvoorbeeld werkplekbeheer gewoon een ondersteunende functie is die moet werken.

Het topic gaat over software ontwikkeling. Dat is wat anders dan werkplekbeheer. En ook die laatste opmerking gaat niet meer op als je, bijvoorbeeld, naar het CBS kijkt. Ook werkplekken zijn gewoon programmeerbaar geworden. De meest eenvoudige thin client neer gezet (dat is dus je lift, die moet inderdaad gewoon werken) en alles verder op een virtuele werkplek die gewoon werkt. Werkt ie niet? Kan de gebruiker uitloggen en weer inloggen en er wordt een nieuwe aangemaakt die wel werkt.

Natuurlijk, soms is directe interactie tussen de IT'er en de gebruiker het beste. Al heb je met een hele zooi gebruikers alsnog problemen dat je dan heel veel wensen krijgt, en het de vraag is welke relevant zijn en welke niet.

Maar die bruggetjes die jij graag op staande voet wil ontslaan die kunnen zo verschrikkelijk handig zijn als ze hun werk goed doen. Vooral bij complexere problemen:
Ik -> Bruggetje: Ding doet het niet
Bruggetje: [Reproduceert] - Ding doet het niet
Bruggetje -> IT: Ding doet het niet (En nu denkt iemand, daar zit een zinloze stap in)
IT -> Bruggetje: Probeer plan A
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan B
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan C
Bruggetje -> IT: Doet het niet
IT -> Bruggetje: Probeer plan D
Bruggetje -> IT: Doet het wel
Bruggetje -> Mij: Doe plan D

En zo nog zat andere situaties waarbij dat bruggetje heel veel tijd voor mij heeft bespaard.

Ik vindt dit het meest prachtige voorbeeld wat ik ooit gezien heb. Wat is hier de toegevoegde waarde van het bruggetje? Juist ja, helemaal niets behalve het risico op miscommunicatie. Dit bruggetje moet dus ook onmiddelijk verwijdert worden. Voegt in het geheel niets toe, kan wel wat kosten, heeft een zwaar negatieve ROI. Tijd bespaart? Op geen enkele manier bespaart dit tijd!

Geen IT afdeling meer? Dus dan moet elke business unit zijn eigen systeembeheerders in dienst gaan nemen? Van de 7 business units hebben 4 een tool nodig, en die gaan allemaal hem apart laten ontwikkelen?

Laten we IT Ops even buiten beschouwing. Als 4 BUs allemaal een tool nodig hebben dan kunnen ze twee dingen doen:
- Allemaal apart laten ontwikkelen zodat het exact doet wat ze nodig hebben.
- Allemaal samen laten ontwikkelen. 25% meer tijd kwijt zijn door afstemming, daarboven nog eens 25% extra kosten door overhead, en uiteindelijk hebben ze allemaal exact wat ze net niet nodig hebben.

Zeker bij software ontwikkeling / aanschaf is er een heel groot "One size fits none" probleem. Dat is exact de reden dat software binnen bedrijven op dit moment zo'n enorm zootje is; iedereen dacht schaalvoordeel te halen. Het mooiste voorbeeld wat ik ken is van een holding voor detail handel. 200'000 man wereldwijd verspreid over witgoed, bruingoed, supermarkten van de lokale ergens achteraf in een buitenwijk van Cluj Napoca tot eentje midden in het centrum van London. En allemaal gebruikten ze exact dezelfde logistieke software. Wat een nachtmerrie aan instabiele, slecht geconfigureerd, ondoorzichtige rommel was dat! Maar ja, opsplitsen kon niet meer...... Uiteindelijk heeft de Holding gewoonweg de witgoed tak verkocht en gezegd "Zoek het maar uit kopers...."

[ Voor 44% gewijzigd door Croga op 20-06-2019 19:22 ]

[Croga]

.

[ Voor 99% gewijzigd door Croga op 20-06-2019 19:22 . Reden: oops, dubbelpost.... ]

[Sissors]

Tsurany schreef op donderdag 20 juni 2019 @ 18:44:
[...]

En daar gaat het dus mis, waar jij denkt dat het bruggetje jou tijd bespaart merk je niet dat je onnodig lang op een oplossing zit te wachten puur omdat bruggetje en IT constant heen en weer zitten te communiceren.

Vaak genoeg sta ik dan gewoon in de CC erbij. Bruggetje en IT zitten inderdaad constant heen en weer te communiceren. En dat is precies zijn toegevoegde waarde. Anders ben ik degene die constant met IT heen en weer zit te communiceren. Dan duurt het net zo lang, maar kost het mij veel meer tijd.

Wat jij als gebruiker nodig hebt is een developer die de functionaliteit snapt, begrijpt waar jouw probleem vandaan komt en het op gaat lossen. Daar hoeft niemand tussen te zitten en daar hoeft helemaal geen pingpong tussen mensen plaats te vinden.

Dan moet ik eerst IT gaan uitleggen hoe in hemelsnaam onze specialistische software werkt, zodat ze het zelf kunnen reproduceren. Terwijl ons bruggetje dat weet. Dat zou mij weer een hele hoop extra tijd kosten.

a

Croga schreef op donderdag 20 juni 2019 @ 19:12:


[...]

Het topic gaat over software ontwikkeling. Dat is wat anders dan werkplekbeheer. En ook die laatste opmerking gaat niet meer op als je, bijvoorbeeld, naar het CBS kijkt. Ook werkplekken zijn gewoon programmeerbaar geworden. De meest eenvoudige thin client neer gezet (dat is dus je lift, die moet inderdaad gewoon werken) en alles verder op een virtuele werkplek die gewoon werkt. Werkt ie niet? Kan de gebruiker uitloggen en weer inloggen en er wordt een nieuwe aangemaakt die wel werkt.

Volgens mij over beide. Maar in jouw eigen voorbeeld hier: Waarom moet dan elke business unit in een bedrijf zijn eigen werkplek beheer krijgen? Waarom zou dat niet centraal geregeld kunnen worden?

[...]

Ik vindt dit het meest prachtige voorbeeld wat ik ooit gezien heb. Wat is hier de toegevoegde waarde van het bruggetje? Juist ja, helemaal niets behalve het risico op miscommunicatie. Dit bruggetje moet dus ook onmiddelijk verwijdert worden. Voegt in het geheel niets toe, kan wel wat kosten, heeft een zwaar negatieve ROI. Tijd bespaart? Op geen enkele manier bespaart dit tijd!

Het bespaard mij gigantisch veel tijd. Anders had ik kunnen gaan kloten met IT. Dan had ik IT moeten gaan uitleggen hoe ze het reproduceren, IT die geen flauw idee heeft hoe onze tools werken. En dan had IT mij moeten gaan uitleggen hoe ons serverpark werkt, waar ik weer geen flauw idee van heb. Voor we elkaars taal spreken had ik het waarschijnlijk al in frustratie opgegeven en wel een workaround geaccepteerd.

[...]

Laten we IT Ops even buiten beschouwing. Als 4 BUs allemaal een tool nodig hebben dan kunnen ze twee dingen doen:
- Allemaal apart laten ontwikkelen zodat het exact doet wat ze nodig hebben.
- Allemaal samen laten ontwikkelen. 25% meer tijd kwijt zijn door afstemming, daarboven nog eens 25% extra kosten door overhead, en uiteindelijk hebben ze allemaal exact wat ze net niet nodig hebben.

En als ze gewoon hetzelfde nodig hebben, dan ontwikkelen ze 4x dezelfde software.

[ Voor 49% gewijzigd door Sissors op 20-06-2019 19:28 ]

[Tsurany]

Sissors schreef op donderdag 20 juni 2019 @ 19:24:
[...]

Vaak genoeg sta ik dan gewoon in de CC erbij. Bruggetje en IT zitten inderdaad constant heen en weer te communiceren. En dat is precies zijn toegevoegde waarde. Anders ben ik degene die constant met IT heen en weer zit te communiceren. Dan duurt het net zo lang, maar kost het mij veel meer tijd.

Dat lijkt zijn toegevoegde waarde omdat je IT kennelijk niet weet hoe de applicatie die ze kennelijk in beheer hebben, en waar ze voor ontwikkelen, werkt.

Dan moet ik eerst IT gaan uitleggen hoe in hemelsnaam onze specialistische software werkt, zodat ze het zelf kunnen reproduceren. Terwijl ons bruggetje dat weet. Dat zou mij weer een hele hoop extra tijd kosten.

En zo blijft alles altijd hetzelfde. Een enkele persoon met kennis die altijd de vertaalslag moet maken, requirements moet uitwerken en specs moet schrijven.

unezra schreef op donderdag 20 juni 2019 @ 19:03:
[...]


Dat werkt alleen, als die developer niet alleen de taal van de gebruiker spreekt, maar ook een goede kennis heeft van alle omliggende systemen, politiek, etc.

Persoonlijk geloof ik d'r niet in. Ik geloof meer in goede vertalers, spinnen in het web, die tussen business en techniek in zitten, alle stakeholders begrijpen en continu bezig zijn met zinvol informatie uitwisseling zodat de hele machine blijft draaien.

En dit is precies het probleem. In plaats van een developer een probleem laten oplossen hebben we nu opeens een architect nodig die de systemen kent en de politiek kan bedrijven. En dan maar gek vinden dat er niks zinnigs uit komt. We hebben veel te veel van dat soort mensen, geen enkele nuttige kennis maar wel een mening die geventileerd moet worden.

[De_Bastaard]

We merken bij ons dat die gap steeds minder wordt met de komst van o.a. low code platformen.

Het probleem is echter dat ontzettend veel bedrijven vinden dat wanneer ze een applicatie laten ontwikkelen, dit moet worden gedaan door een IT man. Wij merken dat het veel meer oplevert wanneer je met de gebruikers samen werkt. De gap wordt dan steeds kleiner, maar je moet er ook wel een goede PO bij hebben.... Organisatorisch moet het bedrijf er wel aan toe zijn. Zelf denk ik dat de komende tijd nog wel wat bedrijven het loodje zullen leggen omdat ze niet snel genoeg mee kunnen met de snel veranderende maatschappij.

Wat het meeste oplevert is veel samen zitten met gebruikers, zo weinig mogelijk lagen er tussen.

[ Voor 7% gewijzigd door De_Bastaard op 20-06-2019 19:36 ]

[Sissors]

Tsurany schreef op donderdag 20 juni 2019 @ 19:33:
[...]

Dat lijkt zijn toegevoegde waarde omdat je IT kennelijk niet weet hoe de applicatie die ze kennelijk in beheer hebben, en waar ze voor ontwikkelen, werkt.

Klopt, en daardoor kunnen bijvoorbeeld degene die onze server park beheren zich op hun werk richten, ipv dat ze allerlei programma's die wij als gebruikers hebben op die servers moeten gaan leren hoe die werken. Lijkt mij een prima situatie om dan iemand ertussenin te hebben.

[Tsurany]

Sissors schreef op donderdag 20 juni 2019 @ 19:47:
[...]

Klopt, en daardoor kunnen bijvoorbeeld degene die onze server park beheren zich op hun werk richten, ipv dat ze allerlei programma's die wij als gebruikers hebben op die servers moeten gaan leren hoe die werken. Lijkt mij een prima situatie om dan iemand ertussenin te hebben.

En zo houden we lekker veel mensen aan het werk, duurt alles lekker lang en kost het extra veel

[Sissors]

Zo kunnen mensen hun werk doen, ipv dat ze allerlei software moeten gaan leren hoe die werkt terwijl dat gewoon buiten hun werkgebied valt. Kunnen mensen efficient werken, mooie kosten besparing. En scheelt mij ook nog eens heel veel tijd.

[Mawlana]

Waar ik trouwens wel een hekel aan heb is een IT organisatie die denkt beter dan de business zelf te weten wat de business nodig heeft. En dat zonder de business te kennen. Zie ik ook regelmatig gebeuren.

IT dient in zekere zin de business te faciliteren (uiteraard moeten ze de business behoeden voor domme beslissingen, cruciale fouten etc), niet omgekeerd.

Ik beredeneer dit vanuit een bedrijf dat niet software development of IT dienstverlening als (core) business heeft.

[unezra]

Croga schreef op donderdag 20 juni 2019 @ 19:12:
[...]
Ofwel: Als die developer onderdeel is van hetzelfde team als die gebruiker.....
[...]
Onderzoek wijst uit dat zelfs de beste vertaler informatie verliest. Iedere stap die er zit tussen het gebruik en de realisatie van het systeem zal het model minder nuttig maken. En dus draait de machine niet snel genoeg.

Ik denk niet dat het een probleem is dat er informatie verloren gaat. Sterker nog, het is juist goed als in gevallen informatie verloren gaat. Het hele idee is dat je moet abstraheren tot een bepaald niveau en daarna de details weer gaat uitwerken.

In al die slagen gaat informatie verloren en da's eerder bevorderlijk voor het eindproduct, dan nadelig.

[...]
Het topic gaat over software ontwikkeling. Dat is wat anders dan werkplekbeheer. En ook die laatste opmerking gaat niet meer op als je, bijvoorbeeld, naar het CBS kijkt. Ook werkplekken zijn gewoon programmeerbaar geworden. De meest eenvoudige thin client neer gezet (dat is dus je lift, die moet inderdaad gewoon werken) en alles verder op een virtuele werkplek die gewoon werkt. Werkt ie niet? Kan de gebruiker uitloggen en weer inloggen en er wordt een nieuwe aangemaakt die wel werkt.

Het topic, of in ieder geval de topicstart, gaat over ICT, niet enkel over softwareontwikkeling.

Laten we IT Ops even buiten beschouwing. Als 4 BUs allemaal een tool nodig hebben dan kunnen ze twee dingen doen:
- Allemaal apart laten ontwikkelen zodat het exact doet wat ze nodig hebben.
- Allemaal samen laten ontwikkelen. 25% meer tijd kwijt zijn door afstemming, daarboven nog eens 25% extra kosten door overhead, en uiteindelijk hebben ze allemaal exact wat ze net niet nodig hebben.

Toch is in mijn belevin dat laatste uiteindelijk beter. In het eerste geval krijg je in een beetje bedrijf 100en onbeheersbare en onbeheerbare tools waar niemand verantwoordelijk voor is. Je kunt vaak beter het werkproces en de mens aanpassen dan de software. Er zijn situaties waarin maatwerk nuttig is, maar je moet er ongelooflijk mee oppassen.

Dus nee. Ik zal echt altijd kiezen voor "off-the-shelf tenzij" en nooit voor "maatwerk tenzij". Maatwerk is vrijwel per definitie een heel erg dure oplossing, als je alle factoren mee telt.

Zeker bij software ontwikkeling / aanschaf is er een heel groot "One size fits none" probleem. Dat is exact de reden dat software binnen bedrijven op dit moment zo'n enorm zootje is; iedereen dacht schaalvoordeel te halen. Het mooiste voorbeeld wat ik ken is van een holding voor detail handel. 200'000 man wereldwijd verspreid over witgoed, bruingoed, supermarkten van de lokale ergens achteraf in een buitenwijk van Cluj Napoca tot eentje midden in het centrum van London. En allemaal gebruikten ze exact dezelfde logistieke software. Wat een nachtmerrie aan instabiele, slecht geconfigureerd, ondoorzichtige rommel was dat! Maar ja, opsplitsen kon niet meer...... Uiteindelijk heeft de Holding gewoonweg de witgoed tak verkocht en gezegd "Zoek het maar uit kopers...."

En jij denkt serieus dat maatwerk in dat geval een minder grote en beter te beheersen en beheren teringzooi had opgeleverd?

Tsurany schreef op donderdag 20 juni 2019 @ 19:33:
[...]
En dit is precies het probleem. In plaats van een developer een probleem laten oplossen hebben we nu opeens een architect nodig die de systemen kent en de politiek kan bedrijven. En dan maar gek vinden dat er niks zinnigs uit komt. We hebben veel te veel van dat soort mensen, geen enkele nuttige kennis maar wel een mening die geventileerd moet worden.

Ik denk dat een goede architect, business consultant, ICT adviseur, hoe je het mannetje of vrouwtje ook wil noemen, juist toegevoegde waarde heeft.

Hij/zij maakt de noodzakelijke vertaalslagen, de techneuten en programmeurs krijgen de informatie die zij nodig hebben om een zinvol systeem te bouwen (en verspillen dus geen tijd met input vragen bij de eindgebruikers én de decision makers), de eindgebruikers en de business krijgen het product dat ze willen.

Het kost véél tijd om van een businessvraag te komen tot een oplossing. Ik denk heel eerlijk dat je dat werk beter over kunt laten aan de mensen die dat leuk vinden en er goed in zijn, zodat iedere specialist zijn tijd kan besteden aan hetgeen hij/zij het meest toe voegt aan de organisatie en leuk vind.

Hoe veel hardcore systeembeheerders, programmeurs en andere techneuten zijn er die het serieus leuk vinden om met Excel te vechten, businesscases te schrijven, etc? De meesten die ik ken, willen liever gewoon systemen of netwerken beheren, programmeren, etc. Niets mis mee, ieder zijn vak en interesse. Je hebt elkaar hierin nodig.

Ik denk juist dat je een beter eindproduct krijgt door apart een adviseur, projectleider, etc, aan te stellen die zorgt dat een ICT project (ongeacht hoe dat er uit ziet), slaagt. Techneuten aan stuurt, communicatie met management verzorgt, etc.

[ Voor 21% gewijzigd door unezra op 20-06-2019 20:46 ]

[Tsurany]

unezra schreef op donderdag 20 juni 2019 @ 20:38:
[...]


Ik denk niet dat het een probleem is dat er informatie verloren gaat. Sterker nog, het is juist goed als in gevallen informatie verloren gaat. Het hele idee is dat je moet abstraheren tot een bepaald niveau en daarna de details weer gaat uitwerken.

In al die slagen gaat informatie verloren en da's eerder bevorderlijk voor het eindproduct, dan nadelig.

Zeker nooit software development gedaan? Verlies van informatie is nooit bevorderlijk, dan krijg je namelijk typisch iets dat built to spec is maar niemand weet meer welke specs en waar ze op gebaseerd zijn.

Toch is in mijn belevin dat laatste uiteindelijk beter. In het eerste geval krijg je in een beetje bedrijf 100en onbeheersbare en onbeheerbare tools waar niemand verantwoordelijk voor is. Je kunt vaak beter het werkproces en de mens aanpassen dan de software. Er zijn situaties waarin maatwerk nuttig is, maar je moet er ongelooflijk mee oppassen.

Dus nee. Ik zal echt altijd kiezen voor "off-the-shelf tenzij" en nooit voor "maatwerk tenzij". Maatwerk is vrijwel per definitie een heel erg dure oplossing, als je alle factoren mee telt.

Of the shelf is vaak uiteindelijk ontzettend duur omdat het niet op jouw processen is gebaseerd en je dus ontzettend dure maatwerk moet laten uitvoeren om de software toch juist te "configureren".
Het probleem met honderden slecht ondersteunde applicaties komt niet omdat het maatwerk is, het komt door slecht beleid. De meeste bedrijven waar ik kom (en dan hebben we het over echte multinationals) hebben tientallen "off the shelf" producten die ontzettend duur zijn in licenties, niet doen wat de business wilt en niet meer ondersteund wordt. Upgraden? Helaas, teveel custom werk dat niet meer aan te passen is vanwege kennis gebrek.

Het belangrijkste is dat een bedrijf standaarden hanteert, goed documenteert en zorgt dat je functionaliteiten bouwt in plaats van applicaties. Werk bijvoorbeeld met low code platformen waarbij je juist de focus op de business processen kan richten. Ontwikkel zo veel mogelijk API's in plaats van applicaties.

unezra schreef op donderdag 20 juni 2019 @ 20:38:
Ik denk dat een goede architect, business consultant, ICT adviseur, hoe je het mannetje of vrouwtje ook wil noemen, juist toegevoegde waarde heeft.

Hij/zij maakt de noodzakelijke vertaalslagen, de techneuten en programmeurs krijgen de informatie die zij nodig hebben om een zinvol systeem te bouwen (en verspillen dus geen tijd met input vragen bij de eindgebruikers én de decision makers), de eindgebruikers en de business krijgen het product dat ze willen.

Het kost véél tijd om van een businessvraag te komen tot een oplossing. Ik denk heel eerlijk dat je dat werk beter over kunt laten aan de mensen die dat leuk vinden en er goed in zijn, zodat iedere specialist zijn tijd kan besteden aan hetgeen hij/zij het meest toe voegt aan de organisatie en leuk vind.

Volgens mij ben je echt in tien jaar geleden blijven hangen. Al die vertaalslagen zorgt enkel voor een enorme hoop documentatie, software die gebouwd is naar specificaties in plaats van wensen en een verspilling van iedereen z'n tijd omdat programmeurs iets bouwen wat eigenlijk niet gewenst is en gebruikers met een systeem moeten werken dat ze eigenlijk niet wilden.

Hoe veel hardcore systeembeheerders, programmeurs en andere techneuten zijn er die het serieus leuk vinden om met Excel te vechten, businesscases te schrijven, etc? De meesten die ik ken, willen liever gewoon systemen of netwerken beheren, programmeren, etc. Niets mis mee, ieder zijn vak en interesse. Je hebt elkaar hierin nodig.

Waarom moet je in hemelsnaam met Excel werken? Je wilt toch niet serieus beweren dat je nog project management in Excel doet?

Ik denk juist dat je een beter eindproduct krijgt door apart een adviseur, projectleider, etc, aan te stellen die zorgt dat een ICT project (ongeacht hoe dat er uit ziet), slaagt. Techneuten aan stuurt, communicatie met management verzorgt, etc.

Het verleden wijst wel uit dat dit absoluut niet het geval is. Het enige wat je namelijk krijgt is ruis, niemand weet waar hij echt mee bezig is en niemand neemt verantwoordelijkheid. Constant afschuiven tussen techneuten, business en de personen die daar tussen in zitten.

[defiant]

feelthepower schreef op donderdag 20 juni 2019 @ 07:33:
Wat is voor jou “business”? Alles buiten IT?

Goed punt, ik had het helderder moeten formuleren, ik bedoel dus de business die ICT aanstuurt binnen een bedrijf, dit kan zowel een bedrijf zijn voor wie ICT in het primaire proces zit, maar ook een ondersteunende ICT business unit.

Ik heb het dus niet over interne of externe afnemers/klanten van ICT diensten of producten.

MAX3400 schreef op donderdag 20 juni 2019 @ 07:43:
Allicht wil je je stelling veranderen?

Ik heb het aangepast, sorry voor de onduidelijkheid

[flyingdutchboy]

Croga schreef op donderdag 20 juni 2019 @ 18:19:
[...]

Dat laatste mag een godswonder heten....\
Je hebt nu dus een gebruiker.
Die praat met een key user.
Die praat met een business analyst
Die praat met een functioneel ontwerper
Die praat met een technisch ontwerper
Die praat met een architect
Die praat met een ontwikkelaar
En dan nog loopt alles gesmeerd? Ik geloof er geen drol van.....

Zolang er nog een IT project manager, een business project manager, een requirements team en ontwerpers aan te pas komen ga je mij niet wijs maken dat jij die ene uitzondering op de regel bent. Dit is wat we 50 jaar lang gedaan hebben en wat al 50 jaar faalt.
Dit valt onder: "Insanity: doing the same thing over and over again and expecting different results."

Ik weet niet waar jij al deze rollen vandaan haalt, maar zo werken wij gelukkig niet. In het uiterste geval zal de IT consultant een developer aan moeten haken. Thats it!

[Croga]

Sissors schreef op donderdag 20 juni 2019 @ 19:24:
Vaak genoeg sta ik dan gewoon in de CC erbij. Bruggetje en IT zitten inderdaad constant heen en weer te communiceren. En dat is precies zijn toegevoegde waarde. Anders ben ik degene die constant met IT heen en weer zit te communiceren. Dan duurt het net zo lang, maar kost het mij veel meer tijd.
[...]
Dan moet ik eerst IT gaan uitleggen hoe in hemelsnaam onze specialistische software werkt, zodat ze het zelf kunnen reproduceren. Terwijl ons bruggetje dat weet. Dat zou mij weer een hele hoop extra tijd kosten.

En als die ITer gewoon bij jou op de afdeling zou zitten zou hij de software gewoon begrijpen en je dus, waar je bij zit, kunnen helpen. Onmiddelijk. Ter plekke. Zonder heen en weer gemail en informatie die verloren gaat.... Het probleem zit hem niet in de tijd die jij spendeert, het probleem zit hem in de tijd dat jij aan het wachten bent op de communicatie van anderen.

Volgens mij over beide. Maar in jouw eigen voorbeeld hier: Waarom moet dan elke business unit in een bedrijf zijn eigen werkplek beheer krijgen? Waarom zou dat niet centraal geregeld kunnen worden?

Omdat iedere business unit zijn eigen eisen stelt. Die nu geen van allen goed gedekt zijn. En dus krijg je situaties zoals bij Sogeti, bijvoorbeeld, waar alle consultants een laptop krijgen. Een laptop die de grootste gemene deler dekt waardoor niemand er wat aan heeft behalve om zijn eigen uren te boeken. Resultaat: Iedereen gebruikt de laptop van de zaak een uurtje per maand om zijn uren te boeken en nergens anders voor omdat hij daar niet voor geschikt is.

En als ze gewoon hetzelfde nodig hebben, dan ontwikkelen ze 4x dezelfde software.

Yup. Dit denken we al 50 jaar. En al 50 jaar resulteert dat in systemen die doen wat niemand eigenlijk wil voor anderhalf keer zoveel geld als dat we bereid waren er aan uit te geven.
Ik zeg het nog eens:

Insanity: doing the same thing over and over again and expecting different results.

unezra schreef op donderdag 20 juni 2019 @ 20:38:
Ik denk niet dat het een probleem is dat er informatie verloren gaat. Sterker nog, het is juist goed als in gevallen informatie verloren gaat. Het hele idee is dat je moet abstraheren tot een bepaald niveau en daarna de details weer gaat uitwerken.

Dat is niet de informatie waar het over gaat. En nee, abstraheren is ook niet altijd goed maar laten we dat even in het midden laten. Wanneer een gebruiker knop A nodig heeft en door de verschillende lagen knop B en knop C gebouwd worden heb je een enorme berg tijd verpild en heeft de gebruiker nogsteeds niet wat hij nodig heeft.

Toch is in mijn belevin dat laatste uiteindelijk beter. In het eerste geval krijg je in een beetje bedrijf 100en onbeheersbare en onbeheerbare tools waar niemand verantwoordelijk voor is. Je kunt vaak beter het werkproces en de mens aanpassen dan de software. Er zijn situaties waarin maatwerk nuttig is, maar je moet er ongelooflijk mee oppassen.

Reductio ad absurbum noemen we dat.
Waarom zou je 100en tools krijgen? Waarom zouden die onbeheersbaar en onbeheerbaar zijn? Waarom zou daar niemand voor verantwoordelijk zijn? Dat zijn allemaal reductios die je doet op basis van aannames die helemaal niet hoeven te kloppen.
Ennehhh.... de mens aanpassen aan de software!?!? Really!? De mens aanpassen kost generaties. De software aanpassen minuten. Wat denk je dat beter is?

Lokale IT die lokaal verantwoordelijk is voor lokale tooling zorgt niet voor wildgroei en zeker niet voor gebrek aan verantwoordelijkheid. Juist het omgekeerde. Wie denk je dat er meer verantwoordlijkheid neemt; degene die de tool bouwt voor het proces waar hij verantwoordelijk voor is, of die IT-fipo 3 hoog achter die de gebruiker nog nooit gezien heeft? Verantwoordelijkheid gaat hand in hand met afhankelijkheid. Als je niet ergens van afhankelijk bent is het heel moeilijk om daar verantwoordelijkheid voor te nemen.

Dus nee. Ik zal echt altijd kiezen voor "off-the-shelf tenzij" en nooit voor "maatwerk tenzij". Maatwerk is vrijwel per definitie een heel erg dure oplossing, als je alle factoren mee telt.

Daar valt nog wel een discussie over te voeren. Ja, monolitisch maatwerk is enorm duur. Maar micro-maatwerk is over het algemeen veel goedkoper dan gigantisch off-the-shelve oplossingen waar je 95% niet van gebruikt (maar wat wel in de weg zit tijdens configuratie en waar je wel voor betaald, in gebruiksgemak, performance en meer van dat soort dingen)

En jij denkt serieus dat maatwerk in dat geval een minder grote en beter te beheersen en beheren teringzooi had opgeleverd?

Ik weet zeker dat de juiste organisatie structuur een beter te beheersen en te beheren oplossing geleverd zou hebben.

Ik denk dat een goede architect, business consultant, ICT adviseur, hoe je het mannetje of vrouwtje ook wil noemen, juist toegevoegde waarde heeft.

Hij/zij maakt de noodzakelijke vertaalslagen, de techneuten en programmeurs krijgen de informatie die zij nodig hebben om een zinvol systeem te bouwen (en verspillen dus geen tijd met input vragen bij de eindgebruikers én de decision makers), de eindgebruikers en de business krijgen het product dat ze willen.

Het kost véél tijd om van een businessvraag te komen tot een oplossing. Ik denk heel eerlijk dat je dat werk beter over kunt laten aan de mensen die dat leuk vinden en er goed in zijn, zodat iedere specialist zijn tijd kan besteden aan hetgeen hij/zij het meest toe voegt aan de organisatie en leuk vind.

Het verleden bewijst dat dit niet waar is. Ja, het kost heel veel tijd om van een business vraag te komen tot een oplossing. Zoveel dat in de meeste gevallen de vraag al dusdanig verandert is dat de oplossing geen enkel raakvlak met de werkelijkheid meer heeft. Voor een deel omdat die verschillende consultants allemaal hun eigen interpretatie over het verhaal heen hebben gegooid, voor een deel omdat de wereld nou eenmaal verandert is.

Ik zeg niet dat de skillsets die deze mensen met zich mee brengen niet nodig zijn. Ik zeg wel dat in een VUCA wereld, het geen op zichzelf staande rol meer kan zijn die lekker even met iedereen gaat babbelen en dan zijn mening neerschrijft. Het moet een continue process zijn in een zo eenvoudig mogelijke setting.

Hoe veel hardcore systeembeheerders, programmeurs en andere techneuten zijn er die het serieus leuk vinden om met Excel te vechten, businesscases te schrijven, etc? De meesten die ik ken, willen liever gewoon systemen of netwerken beheren, programmeren, etc. Niets mis mee, ieder zijn vak en interesse. Je hebt elkaar hierin nodig.

Ik denk juist dat je een beter eindproduct krijgt door apart een adviseur, projectleider, etc, aan te stellen die zorgt dat een ICT project (ongeacht hoe dat er uit ziet), slaagt. Techneuten aan stuurt, communicatie met management verzorgt, etc.

En daar heb je het weer......

Insanity: doing the same thing over and over again and expecting different results.

Dit proberen we al 50 jaar met bagger als resultaat. Als je niet bereid bent kritisch naar die bagger te kijken en te denken "Hoe zou dat nou beter kunnen?" dan gaat het ook nooit beter worden.....

[SirLenncelot]

Business begrijpt IT vaak niet goed, en daar wordt door sommige partijen nog flink misbruik van gemaakt ook.

Ik werk als applicatiebeheerder bij een zorginstelling en ik heb het gevoel dat de business 1) te veel van IT verwacht 2) adviezen over inrichting te snel in de wind slaat en 3) hun eigen processen heilig verklaren.

Een voorbeeld is de implementatie van het roosterpakket. Het advies vanuit IT was om het bestaande pakket te upgraden naar een nieuwe versie. Hiermee zouden een aantal taken die handwerk waren automatisch gaan verlopen, updates zouden sneller en beter uitgevoerd kunnen worden en de huidige processen rondom roostering konden grotendeels intact blijven.
Zonder verder veel overleg heeft de business uiteindelijk voor een nieuw pakket gekozen omdat dit pakket de mogelijkheid tot "zelfroosteren" bood. Het gevolg was een slopend langdurig traject waarin de nieuwe applicatie steeds van maatwerk moest worden voorzien om aan te sluiten bij de reeds bestaande processen. Alle maatwerk stukken zorgen voor problemen met elke update, kosten klauwen met geld en werken uiteindelijk ook niet zoals de business verwacht. Bij de meeste stukken maatwerk heb ik geadviseerd om het bedrijfsproces aan te passen, mijn argumenten vonden geen gehoor. En zelfroosteren wordt overigens nog steeds niet ingezet op de afdelingen. De leverancier belooft steeds dat alles mogelijk is - uiteraard, alles is facturabel - en onze business ziet in alles de oplossing voor hun problemen.

Het is maar een voorbeeld van een IT-project waarbij de business uiteindelijk bepaalt. Ik denk dat deze manier van werken echter vaak voorkomt.

[The Eagle]

Imho gaat business over het WAAROM, en IT over het HOE. Daar zit nog het WAT tussen en daar heb je enterprise architecten en wellicht een handjevol andere rollen voor. Dus eigenlijk is het helemaal niet zo gek dat daar een gat tussen zit
Daarbij zijn IT'ers over het algemeen notoir slecht in communicatie En is je communicatie, of die nou mondeling, schriftelijk of non verbaal is, slechts zo goed als dat deze geinterpreteerd wordt. Zit daar een gat qua conceptkennis dan ga je nat ja. Kun je over klagen, kun je ook wat aan doen.
Maar veel IT'er snappen dat (logischerwijs) niet en business snapt niet waarom ze dat niet snappen, want die snappen dat wel - daarom zijn ze IT business (aka IT management).

[vso]

unezra schreef op donderdag 20 juni 2019 @ 18:44:
Persoonlijk vind ik dat de business de IT niet hoeft te begrijpen. De business moet doen wat ze doen, business bedrijven. Andersom vind ik veel belangrijker: De ICT, of iig een ICT adviseur, moet begrijpen waar de business behoefte aan heeft en continu naar de business blijven luisteren.
<snip>

en

SirLenncelot schreef op donderdag 20 juni 2019 @ 22:13:
Business begrijpt IT vaak niet goed, en daar wordt door sommige partijen nog flink misbruik van gemaakt ook.
<snip>
Het is maar een voorbeeld van een IT-project waarbij de business uiteindelijk bepaalt. Ik denk dat deze manier van werken echter vaak voorkomt.

1 van de oorzaken is:
IT, persoon x (kind/neefje) klikt een website in 5 minutren in elkaar.. maar de bedrijfs website kost "tonnen" of 64gb usb stick kost 10,- bij de action maar 1GB kost een ton voor de file server..

En de vertaling tussen "wens"(klant) en "uitvoering/resultaat"(ontwikkelaars/bedrijf) kent iedereen (beroemd plaatje)

MAAR
Aan de klant kant moet iedereen zijn plasje erover doen, project leiders die de geen heldere afspraken hebben onder financiele & opleverings druk staan.. voor hun immers 10 anderen.

En dan hebben we het nog niet over de "extra factoren" zoals aannemers die aannemers aannemen om zonder risico toch geld te vangen (immers verantwoordelijkheid doorschuiven) .


Je lost het meeste op door IT en business eens direct in contact te brengen met elkaar en in de keuken te kijken ..

IT zal het 100% roesten wat de klant doet .. of ze nu koekjes bakken, boeken uitgeven of juridische/administratieve rompslom doen. gevolg = de servers werken perfect probleem opgelost.

de "gebruikers" klagen omdat alles even snel werkt (geen proces optimalisaties door DBA bv)

Het helpt al als een bij een systeem een IT kundig persoon ernaast gaat zitten en het proces v.d gebruiker beschrijft en de key factoren (systeem eisen --> Key Performance Indicators) op papier zet voor de business. hiermee weet IT wat ze moeten veranderen ..

@The Eagle bijna .. ICT communiceert wel .. maar de business zegt 100% uptime, en 100% backup ..
maar vraagt nooit naar "snelle" database .. want dat kost geld en erhm .. ze hebben daar toch hun mannetje(s) voor en die kosten al genoeg ..

beetje zoals "de schoonmaker doet zijn werk" en dus is er geen vervuiling .. maar ze krijgen net genoeg betaald om alles in het zicht schoon te maken .. een grondige reiniging is te duur en wat niet weet wat niet deert .. een keer je airco installatie (lees buizen netwerk) schoonmaken is extra kosten dus dat doen we niet Moet wel maar zit niet in het budget

ik vind het dus bijzonder lomp om ICT de schuld te geven van iets waar ze vaak de kennis en communicatie wel voor hebben / doen ,.. maar de business zelf niet de investering voor wil doen .. goedkoper om dan meer CPU / RAM er tegenaan te kwakken .. (zonder effect)

[ Voor 16% gewijzigd door vso op 20-06-2019 22:42 ]

[Yucon]

Helemaal raar is het niet. Bij softwareontwikkeling wordt aan de business vaak een budget afgegeven voor de kosten. Tegelijkertijd zijn dat dan de ontwikkelkosten en ontbreken er allerlei punten in die de kosten gedurende de levensduur bepalen. Op die manier zie je wel eens situaties waarbij een enorme bak maatwerk in ERP software ervoor zorgt dat het zo lastig te beheren en door onverwachte relaties zo onvoorspelbaar wordt dat het beheer onder de streep drie keer de initiële implementatiekosten vraagt.

Waar IT'ers falen is in dat duidelijk te maken. Het blijft een beetje hangen bij "als je het zo doet wordt het wel een beetje lastig". Tja, dat is nu niet bepaald een argument dat serieus genomen wordt. Het zou eigenlijk wel moeten. Maar door vaag te blijven over wat er nu precies lastig is _{IT is in de ogen van veel mensen sowieso al lastig, dus dat sluit mooi aan} weten mensen uit de business nauwelijks waar ze nu precies ja tegen zeggen als ze iets laten aanpassen. Verderop komt dan de trammelant. Vijf wijzigingen in hetzelfde gebied en drie jaar verder valt er echt redelijkerwijs niet meer te achterhalen wat er gebeurt als de zesde wijziging er aan toegevoegd wordt.

Terwijl de business het beeld heeft dat die eerste vijf wijzigingen al duur zat waren dus die moeten wel prima zijn. Feitelijk waren ze te goedkoop want de extra complexiteit in de zesde wijziging is veroorzaakt door het werk in de eerste vijf.

[ Voor 18% gewijzigd door Yucon op 20-06-2019 22:45 ]

[Tsurany]

The Eagle schreef op donderdag 20 juni 2019 @ 22:28:
Imho gaat business over het WAAROM, en IT over het HOE. Daar zit nog het WAT tussen en daar heb je enterprise architecten en wellicht een handjevol andere rollen voor. Dus eigenlijk is het helemaal niet zo gek dat daar een gat tussen zit

En dat is dus het oude probleem, telkens dat onderscheid willen maken. Mij interesseert de HOE veel minder dan de WAT en de WAAROM. Laten we samen uitvinden wat je precies nodig hebt en waarom je dat nodig hebt, dan draag ik wel zorg voor hoe dat ontwikkeld wordt en gaan we dat samen periodiek reviewen en aanpassen/aanscherpen waar nodig. Maar de hoe is ondergeschikt, we hebben de tools om iets te maken dat bij het proces aansluit.

En natuurlijk zijn de nitty gritty details belangrijk zoals standaarden gebruiken, micro services bouwen, data modelling,... maar dat is al tientallen jaren niet veranderd. Laten we daar de focus niet op leggen.

Daarbij zijn IT'ers over het algemeen notoir slecht in communicatie En is je communicatie, of die nou mondeling, schriftelijk of non verbaal is, slechts zo goed als dat deze geinterpreteerd wordt. Zit daar een gat qua conceptkennis dan ga je nat ja. Kun je over klagen, kun je ook wat aan doen.
Maar veel IT'er snappen dat (logischerwijs) niet en business snapt niet waarom ze dat niet snappen, want die snappen dat wel - daarom zijn ze IT business (aka IT management).

En daarom moet je de juiste type IT'ers opleiden en aannemen. En daarom helpt het om tooling te gebruiken, low code oplossingen waardoor je niet perse die die-hard programmeurs nodig hebt maar juist de wat meer business oriented mensen die je de basis van SOAP/Rest en XML/JSON bij brengt met wat databases en UX/UI design.

Maar het is ook simpelweg geld uitgeven aan goede IT'ers in plaats van constant vrachten Indiërs binnen halen die met meer man minder opleveren.

[ Voor 13% gewijzigd door Tsurany op 20-06-2019 23:29 ]

[Pizza_Boom]

Yucon schreef op donderdag 20 juni 2019 @ 22:41:
Waar IT'ers falen is in dat duidelijk te maken. Het blijft een beetje hangen bij "als je het zo doet wordt het wel een beetje lastig". Tja, dat is nu niet bepaald een argument dat serieus genomen wordt. Het zou eigenlijk wel moeten. Maar door vaag te blijven over wat er nu precies lastig is _{IT is in de ogen van veel mensen sowieso al lastig, dus dat sluit mooi aan} weten mensen uit de business nauwelijks waar ze nu precies ja tegen zeggen als ze iets laten aanpassen. Verderop komt dan de trammelant. Vijf wijzigingen in hetzelfde gebied en drie jaar verder valt er echt redelijkerwijs niet meer te achterhalen wat er gebeurt als de zesde wijziging er aan toegevoegd wordt.

Terwijl de business het beeld heeft dat die eerste vijf wijzigingen al duur zat waren dus die moeten wel prima zijn. Feitelijk waren ze te goedkoop want de extra complexiteit in de zesde wijziging is veroorzaakt door het werk in de eerste vijf.

Maar dat is niet alleen in de IT. Ik zit in de bouw en wij hebben hetzelfde tussen business en productie. Daarbij hebben de techneuten in het algemeen een probleem met het verzenden van de communicatie, waar de business problemen heeft met het effectief ontvangen van communicatie.

[vso]

Tsurany schreef op donderdag 20 juni 2019 @ 23:20:
[...]

En dat is dus het oude probleem, telkens dat onderscheid willen maken. Mij interesseert de HOE veel minder dan de WAT en de WAAROM. Laten we samen uitvinden wat je precies nodig hebt en waarom je dat nodig hebt, dan draag ik wel zorg voor hoe dat ontwikkeld wordt en gaan we dat samen periodiek reviewen en aanpassen/aanscherpen waar nodig. Maar de hoe is ondergeschikt, we hebben de tools om iets te maken dat bij het proces aansluit.

En natuurlijk zijn de nitty gritty details belangrijk zoals standaarden gebruiken, micro services bouwen, data modelling,... maar dat is al tientallen jaren niet veranderd. Laten we daar de focus niet op leggen.

[...]

En daarom moet je de juiste type IT'ers opleiden en aannemen. En daarom helpt het om tooling te gebruiken, low code oplossingen waardoor je niet perse die die-hard programmeurs nodig hebt maar juist de wat meer business oriented mensen die je de basis van SOAP/Rest en XML/JSON bij brengt met wat databases en UX/UI design.

Maar het is ook simpelweg geld uitgeven aan goede IT'ers in plaats van constant vrachten Indiërs binnen halen die met meer man minder opleveren.

"juiste type IT'ers" erhm .. oke defineer die eens ..

99% van het werkend volk zit er om zijn zakken te vullen, en erger nog het is voor de meeste effectiever om te vertragen c.q uit te besteden dan zelf enig aandeel te hebben in enige productie en dat geld voor beide kanten.

Een groot voorbeeld is de (lokaal en nationaal) overheid, miljoenen gaan over de balk heen aan waanzin en een gemiddeld bedrijf is er ook niet vies van.

je moet sterke set mensen hebben die samen het kaf van het koren kan scheiden met genoeg gewicht (mandaat) om woord bij daad te voegen..

[Sissors]

Croga schreef op donderdag 20 juni 2019 @ 22:13:
[...]


En als die ITer gewoon bij jou op de afdeling zou zitten zou hij de software gewoon begrijpen en je dus, waar je bij zit, kunnen helpen. Onmiddelijk. Ter plekke. Zonder heen en weer gemail en informatie die verloren gaat.... Het probleem zit hem niet in de tijd die jij spendeert, het probleem zit hem in de tijd dat jij aan het wachten bent op de communicatie van anderen.

Dan moeten de beheerders van ons server park verdeeld over het hele bedrijf gaan zitten? Ik zie niet in hoe dat fout kan gaan...

Of moet dan ook elke business zijn eigen server park gaan opzetten ipv dat te delen tussen de verschillende afdelingen?

[...]

Omdat iedere business unit zijn eigen eisen stelt. Die nu geen van allen goed gedekt zijn. En dus krijg je situaties zoals bij Sogeti, bijvoorbeeld, waar alle consultants een laptop krijgen. Een laptop die de grootste gemene deler dekt waardoor niemand er wat aan heeft behalve om zijn eigen uren te boeken. Resultaat: Iedereen gebruikt de laptop van de zaak een uurtje per maand om zijn uren te boeken en nergens anders voor omdat hij daar niet voor geschikt is.

Lijkt anders behoorlijk prima te gaan. Laptops zijn wat overgedimensioneerd voor sommige (eg, een secretaresse heeft niet echt 16GB RAM standaard nodig), en iedereen die zwaarder nodig heeft doet dat op het server park.

Maar anders dat je een standaard laptop instelt betekent niet dat er geen tweede optie kan zijn, of uberhaupt uitzonderingen. Als elke business zelf zijn laptops koopt blijf je toch exact hetzelfde probleem hebben? Ook een BU heeft een hele reeks functies, waarbij de één genoeg heeft aan een Chromebook, en de andere veel meer rekenkracht nodig heeft.

[...]

Yup. Dit denken we al 50 jaar. En al 50 jaar resulteert dat in systemen die doen wat niemand eigenlijk wil voor anderhalf keer zoveel geld als dat we bereid waren er aan uit te geven.
Ik zeg het nog eens:
[...]

Maar het werkt prima. Wat idioterie zou zijn is dingen die prima werken veranderen. Al helemaal als je van ver aan ziet komen dat het vreselijk inefficient is.
Laat ik voor mij een specifieker voorbeeld geven: Business A maakt automotive chips. Business B maakt IOT chips. Als die twee een zelfde proces kiezen, waarom zou je bijvoorbeeld dan in hemelsnaam de de IT tools die bijvoorbeeld veroudering van chips uitrekenen twee keer maken?

Misschien ben ik dan ook biased omdat ik juist op een afdeling werk die buiten de businesses staat, en die juist als taak heeft bouwblokken te leveren aan alle businesses zodat ze niet 10x opnieuw het wiel gaan uitvinden.

Maar als je letterlijk alles gaat opsplitsen, waarom ben je dan uberhaupt nog één bedrijf? Splits dan gewoon meteen het hele bedrijf op, zijn ze nog flexibeler.

[ Voor 10% gewijzigd door Sissors op 21-06-2019 07:53 ]

[Reacher]

De stelling zal zonder enige twijfel waar zijn voor veel organisaties en ook voor vele niet.

De mate van volwassenheid van de organisatie speelt een grote rol, de cultuur, externe omgeving, etc.

Organiseren en besturen vraagt om visie. Je kan er niet vanuit dat samenwerken zomaar even ontstaat, zeker niet in een organisatie met history. Zeker als een organisatie groeit kom je deze uitdagingen tegen en blijf je tegen komen. Je het immers voor nu repareren en dan kunnen we even performance. Maar dan gaat er iets in de omgeving veranderen en kom je weer in een fase terecht waarbij het eerst een tijd zal stormen voor je kan gaan performen.

Een vraag die misschien beter helpt is:
Wat moeten bestuurders in dit digitale tijdperk weten om beter te kunnen organiseren en te besturen.

[unezra]

Tsurany schreef op donderdag 20 juni 2019 @ 20:55:
[...]
Zeker nooit software development gedaan? Verlies van informatie is nooit bevorderlijk, dan krijg je namelijk typisch iets dat built to spec is maar niemand weet meer welke specs en waar ze op gebaseerd zijn.

Daar ben ik het dus hardgrondig mee oneens.

Als programmeur wil je niet dat de directie of een (interne of externe) klant gaat bepalen hoe jouw code er uit moet zien. Zij moeten bepalen welke functionaliteit nodig is. Hoe abstracter hoe beter. Uiteindelijk is het het team van programmeurs dat bepaald welke taal, welk framework en welke code daar het resultaat van is.

Same shit met beheer. Zodra de directie zich in mijn organisatie gaat bemoeien met hoe ik als uitvoerend techneut mijn werk moet doen, hoe ik systemen moet inrichten en welke software we nodig hebben, gaat het mis. Zij moeten denken in termen van requirements.

Kortom, hoe verder van de uitvoering je af zit, hoe abstracter het word en dat is alleen maar goed.

[...]
Of the shelf is vaak uiteindelijk ontzettend duur omdat het niet op jouw processen is gebaseerd en je dus ontzettend dure maatwerk moet laten uitvoeren om de software toch juist te "configureren".
Het probleem met honderden slecht ondersteunde applicaties komt niet omdat het maatwerk is, het komt door slecht beleid. De meeste bedrijven waar ik kom (en dan hebben we het over echte multinationals) hebben tientallen "off the shelf" producten die ontzettend duur zijn in licenties, niet doen wat de business wilt en niet meer ondersteund wordt. Upgraden? Helaas, teveel custom werk dat niet meer aan te passen is vanwege kennis gebrek.

Dat is in mijn ogen een kwestie van verkeerde uitvoering, niet van een verkeerd uitgangspunt.

"If all you have is a hammer, every problem looks like a nail." klopt, máár, wanneer je iets moet bevestigen en je bent vooral bekend met een schroef en iemand anders in de organisatie is vooral bekend met een spijker of lijm, zou je kunnen kijken of de oplossing niet ligt in het gebruik van spijkers met lijm. Jij levert je schroef in en gebruikt alleen nog maar spijkers en lijm. Dat verhef je tot standaard.

Zit het minder goed vast? Welnee. Maar je kunt wel opeens én je spijkers, hamers en lijm dusdanig groot inkopen dat je quantum korting krijg. Je hoeft alleen nog maar mensen op te leiden om schroeven en lijm te gebruiken. Je hoeft alleen het proces "hameren en lijmen" te beschrijven in plaats van schroeven en je bent volledig consistent.

Daar zijn uitzonderingen op, dus soms zul je toch een schroef nodig hebben, of een bout. Dat noemen we de uitzondering die de regel bevestigd.

[...]
Volgens mij ben je echt in tien jaar geleden blijven hangen. Al die vertaalslagen zorgt enkel voor een enorme hoop documentatie, software die gebouwd is naar specificaties in plaats van wensen en een verspilling van iedereen z'n tijd omdat programmeurs iets bouwen wat eigenlijk niet gewenst is en gebruikers met een systeem moeten werken dat ze eigenlijk niet wilden.

Ik denk juist dat een van de dingen die op dit moment gruwelijk fout is gegaan in de ICT, is dat programmeren dusdanig laagdrempelig is geworden, dat iedere dilweed die tot hoofdstuk 2 van "C++ for dummies" is gekomen, vind dat zijn of haar code het beste is en dat de beste oplossing is méér code te schrijven. Een van de gevolgen zie je in de Open Source wereld met de 100en Linux distro's die soms niet meer van elkaar verschillen dan een GUI. Forken om het forken, code schrijven omdat er niemand is die zegt "nee, maatwerk is duur, we kopen een standaard pakket, passen dat aan waar nodig, passen bedrijfsprocessen en werkwijzen aan waar nodig en klaar".

Croga schreef op donderdag 20 juni 2019 @ 22:13:
[...]
En als die ITer gewoon bij jou op de afdeling zou zitten zou hij de software gewoon begrijpen en je dus, waar je bij zit, kunnen helpen. Onmiddelijk. Ter plekke. Zonder heen en weer gemail en informatie die verloren gaat.... Het probleem zit hem niet in de tijd die jij spendeert, het probleem zit hem in de tijd dat jij aan het wachten bent op de communicatie van anderen.

Die ITer op de afdeling is ook gruwelijk duur. Het is denk ik financieel onhoudbaar micro-units te creëren.
Je zou dan letterlijk op iedere afdeling, een complete set ICTers moeten hebben die volledig hun ding doen, terwijl je dan iedere vorm van schaalgrootte en de bijbehorende voordelen mist.

Schaalvergroting is niet zaligmakend, er zijn nadelen aan, dus het moet van geval tot geval bekeken worden maar ik denk zéker dat netto, schaalgrootte voordeel oplevert.

[...]
Omdat iedere business unit zijn eigen eisen stelt. Die nu geen van allen goed gedekt zijn. En dus krijg je situaties zoals bij Sogeti, bijvoorbeeld, waar alle consultants een laptop krijgen. Een laptop die de grootste gemene deler dekt waardoor niemand er wat aan heeft behalve om zijn eigen uren te boeken. Resultaat: Iedereen gebruikt de laptop van de zaak een uurtje per maand om zijn uren te boeken en nergens anders voor omdat hij daar niet voor geschikt is.

Wat daar ontbreekt, is iemand die voorkomt dat iedere business unit zijn eigen eisen er doorheen drukt en geen water bij de wijn wil doen.

Unit A wil een mintgroene knop, Unit B wil een geelgroene knop. Waarom dan niet gewoon iemand die zegt "hardstikke leuk, maar jullie leren maar leven met een gifgroene knop, dat is beter en goedkoper dan 2 knoppen ontwikkelen".

[...]
Dat is niet de informatie waar het over gaat. En nee, abstraheren is ook niet altijd goed maar laten we dat even in het midden laten. Wanneer een gebruiker knop A nodig heeft en door de verschillende lagen knop B en knop C gebouwd worden heb je een enorme berg tijd verpild en heeft de gebruiker nogsteeds niet wat hij nodig heeft.

Ik denk dat vaak die gebruiker helemaal geen knop A nodig heeft, maar dat iedereen prima kan leven met een knop B' (B-accent) of zelfs een knop D.

[...]

Reductio ad absurbum noemen we dat.
Waarom zou je 100en tools krijgen? Waarom zouden die onbeheersbaar en onbeheerbaar zijn? Waarom zou daar niemand voor verantwoordelijk zijn? Dat zijn allemaal reductios die je doet op basis van aannames die helemaal niet hoeven te kloppen.
Ennehhh.... de mens aanpassen aan de software!?!? Really!? De mens aanpassen kost generaties. De software aanpassen minuten. Wat denk je dat beter is?

Een proces aanpassen kost soms maar 5 minuten.
"De knop zat links onderin, hij zit nu rechts onderin. HELP!"
"Ok, de nieuwe werkinstructie is dat je op de knop rechts onderin moet klikken."
*klaar* Proces aangepast. Als je in dat geval besluit de knop terug naar links onderin te plaatsen, of erger nog, afdeling A wil 'm links onderin en afdeling B wil 'm rechts onderin, ben je verkeerd bezig.

De mens, haar werkprocessen, aanpassen is in mijn beleving niet zelden goedkoper en efficiënter dan meerdere varianten van dezelfde tool uitbrengen.

Mensen zijn extreem adaptive. Simpel voorbeeld: Auto's. De meeste mensen leren lessen in een auto met handgeschakelde versnellingsbak. Diezelfde mensen, rijden vaak in minder dan 5 minuten meer dan uitstekend in een auto met automatische versnellingsbak. Die omschakeling, is wezenlijk eenvoudiger en goedkoper dan voor iedere bestuurder de versnellingsbak monteren waar diegene aan gewend is.

En ja, je krijgt 100en tools die allemaal nét iets anders doen als je iedereen maar die tools laat aanschaffen en ontwikkelen waar ze denken behoefte aan te hebben.

[...]
Het verleden bewijst dat dit niet waar is. Ja, het kost heel veel tijd om van een business vraag te komen tot een oplossing. Zoveel dat in de meeste gevallen de vraag al dusdanig verandert is dat de oplossing geen enkel raakvlak met de werkelijkheid meer heeft. Voor een deel omdat die verschillende consultants allemaal hun eigen interpretatie over het verhaal heen hebben gegooid, voor een deel omdat de wereld nou eenmaal verandert is.

Ik zeg niet dat de skillsets die deze mensen met zich mee brengen niet nodig zijn. Ik zeg wel dat in een VUCA wereld, het geen op zichzelf staande rol meer kan zijn die lekker even met iedereen gaat babbelen en dan zijn mening neerschrijft. Het moet een continue process zijn in een zo eenvoudig mogelijke setting.

[...]

En daar heb je het weer......

[...]

Dit proberen we al 50 jaar met bagger als resultaat. Als je niet bereid bent kritisch naar die bagger te kijken en te denken "Hoe zou dat nou beter kunnen?" dan gaat het ook nooit beter worden.....

Het moet zeker beter maar ik denk dat de verbetering zit in meer en betere communicatie tussen eindgebruikers en ICT. Via mensen die juist goed zijn in die communicatie en waar nodig ook direct beheerders en developers laat schakelen met de eindgebruikers. Niet continu, niet in ieder geval, alleen waar nodig en nuttig.

Pizza_Boom schreef op donderdag 20 juni 2019 @ 23:48:
[...]
Maar dat is niet alleen in de IT. Ik zit in de bouw en wij hebben hetzelfde tussen business en productie. Daarbij hebben de techneuten in het algemeen een probleem met het verzenden van de communicatie, waar de business problemen heeft met het effectief ontvangen van communicatie.

Precies en daar zet je in mijn ideale wereld dus een goede tussenlaag tussen van mensen die zowel de taal van de techneuten als de business begrijpen en zorgen voor een optimale communicatie. Een vertaler, een soort menselijke babelfish. Vertalers zijn vaak efficiënter dan iedereen elkaars taal laten leren.

Ik geloof zelf heel erg in specialisten, mensen die een flinke verdieping kennen in hun vak. Een directeur die verstand heeft van het leiden van het bedrijf (maar geen reet begrijpt van ICT, prima, houden zo), een ICTer die juist prima weet hoe iets technisch geïmplementeerd moet worden en mensen daar tussen die zorgen dat de ICTer weet wat 'ie moet maken en de directeur tevreden is met het eindresultaat.

vso schreef op vrijdag 21 juni 2019 @ 00:20:
[...]

"juiste type IT'ers" erhm .. oke defineer die eens ..

99% van het werkend volk zit er om zijn zakken te vullen, en erger nog het is voor de meeste effectiever om te vertragen c.q uit te besteden dan zelf enig aandeel te hebben in enige productie en dat geld voor beide kanten.

Een groot voorbeeld is de (lokaal en nationaal) overheid, miljoenen gaan over de balk heen aan waanzin en een gemiddeld bedrijf is er ook niet vies van.

je moet sterke set mensen hebben die samen het kaf van het koren kan scheiden met genoeg gewicht (mandaat) om woord bij daad te voegen..

Grote bedrijven zijn in mijn beleving minstens zo erg als "de overheid". "De overheid" bestaat niet, het is een miljoenen organisatie met allemaal werkmaatschappijen. Absoluut zijn er verschillen tussen "de overheid" en "het bedrijfsleven", maar een van de grote overeenkomsten in mijn beleving is wel dat hoe groter de organisatie, hoe makkelijker projecten té groot worden en hoe makkelijker er word gedacht over een miljoentje meer of minder of een geslaagd project meer of minder.

Aan de andere kant, zou je dat gaan omrekenen naar % van omzet, zou het wel eens niet zo verschrikkelijk kunnen zijn.

Als je omzet een ton per jaar is, doet een geflopt project van €1000 net zo veel pijn als wanneer je omzet een miljoen per jaar is en je hebt een geflopt project van €10.000.
"De Overheid" is een giga organisatie met bijna een miljoen werknemers en honderden of duizenden "werkmaatschappijen". (915.000 in 2015: https://www.hr-kiosk.nl/n...ambtenaren-telt-nederland) Ter vergelijk, Ahold had er in 2016 "maar" 375.000 Wikipedia: Koninklijke Ahold NV

Sissors schreef op vrijdag 21 juni 2019 @ 07:46:
[...]
Dan moeten de beheerders van ons server park verdeeld over het hele bedrijf gaan zitten? Ik zie niet in hoe dat fout kan gaan...

Of moet dan ook elke business zijn eigen server park gaan opzetten ipv dat te delen tussen de verschillende afdelingen?

*lol*
Of zijn eigen code gaan schrijven. Weg met Microsoft Office. Gewoon vanaf scratch je eigen office suite schrijven die beter voldoet aan je wensen.

[...]
Lijkt anders behoorlijk prima te gaan. Laptops zijn wat overgedimensioneerd voor sommige (eg, een secretaresse heeft niet echt 16GB RAM standaard nodig), en iedereen die zwaarder nodig heeft doet dat op het server park.

Maar anders dat je een standaard laptop instelt betekent niet dat er geen tweede optie kan zijn, of uberhaupt uitzonderingen. Als elke business zelf zijn laptops koopt blijf je toch exact hetzelfde probleem hebben? Ook een BU heeft een hele reeks functies, waarbij de één genoeg heeft aan een Chromebook, en de andere veel meer rekenkracht nodig heeft.

Wij zijn een kleine organisatie (40 FTE) met toch een aantal verschillende afdelingen. We hebben één zgn. golden image op onze VDI omgeving en letterlijk iedereen doet daar zijn ding op. Niet altijd naar volle tevredenheid, maar dat ligt niet aan de standaardisatie. De enige uitzondering is ICT (ik en mijn collega), wij hebben om diverse redenen een autonoom draaiende laptop. Alle andere laptops die we hebben, kunnen precies 1 ding: Verbinding maken met de VDI omgeving.

Als ik kijk naar onze moedermaatschappij, daar heeft in principe iedereen een laptop. Iedere afdeling, ieder persoon. De software daarop is per afdeling (maar niet per persoon) verschillend. Het is niet zinvol om hypotheekadvies software op een laptop te zetten van iemand die HR doet. Toch zijn het allemaal dezelfde laptops. (Op generatieverschillen, beeldschermgrootte en voor zover ik weet verder hooguit geheugen en CPU na.) Werkt prima.

[...]
Maar het werkt prima. Wat idioterie zou zijn is dingen die prima werken veranderen. Al helemaal als je van ver aan ziet komen dat het vreselijk inefficient is.
Laat ik voor mij een specifieker voorbeeld geven: Business A maakt automotive chips. Business B maakt IOT chips. Als die twee een zelfde proces kiezen, waarom zou je bijvoorbeeld dan in hemelsnaam de de IT tools die bijvoorbeeld veroudering van chips uitrekenen twee keer maken?

Waarom zou je 2 totaal verschillende productiestraten maken, als uiteindelijk de onderliggende techniek van de chip volkomen gelijk is en de verschillen enkel zitten in de werking van de chip. Je gaat toch niet ieder bedrijf dat chips in zijn eindproducten nodig heeft, voorzien van een complete productiestraat voor chips? Je koopt die dingen bij een chipsfabrikant en die maken voor een groot deel gebruik van dezelfde apparatuur, gebouwd door dezelfde partij.

Misschien ben ik dan ook biased omdat ik juist op een afdeling werk die buiten de businesses staat, en die juist als taak heeft bouwblokken te leveren aan alle businesses zodat ze niet 10x opnieuw het wiel gaan uitvinden.

Maar als je letterlijk alles gaat opsplitsen, waarom ben je dan uberhaupt nog één bedrijf? Splits dan gewoon meteen het hele bedrijf op, zijn ze nog flexibeler.

... en duurder, dus kunnen ze minder goed concurreren ...

Waarom is er een Albert Heijn en waarom heeft niet ieder dorp, iedere wijk nog zijn eigen supermarkt? Juist, schaalgrootte en standaardisering.

Precies dát is een van de dingen die blijkbaar voordelen bied.

Terug naar het onderwerp: Juist door de tussenlaag, de vertalers, zorg je er voor dat er sneller standaardisatie kan ontstaan. In plaats van dat iedereen op zijn eigen eilandje gaat zitten klooien, zit er een tussenlaag tussen die de vertaalslagen maakt. Niet alleen tussen ICT en business, maar ook tussen de diverse ICT en business onderdelen. Zo kan ieder zijn eigen taal blijven spreken, ieder zijn specialisme uit blijven voeren en heb je de overhead van communicatie maar 1x. Een goede tussenlaag, zorgt (in mijn beleving) voor een betere communicatie tussen alle lagen in de organisatie en dus voor een verkleining van het gat tussen business en ICT, niet een vergroting.

[vso]

unezra schreef op vrijdag 21 juni 2019 @ 11:03:

Damm gozer TLDR post .. doe voortaan de HR tag ofzo ... ach ben het van je gewend zoals je weet

Grote bedrijven zijn in mijn beleving minstens zo erg als "de overheid". "De overheid" bestaat niet, het is een miljoenen organisatie met allemaal werkmaatschappijen. Absoluut zijn er verschillen tussen "de overheid" en "het bedrijfsleven", maar een van de grote overeenkomsten in mijn beleving is wel dat hoe groter de organisatie, hoe makkelijker projecten té groot worden en hoe makkelijker er word gedacht over een miljoentje meer of minder of een geslaagd project meer of minder.

Aan de andere kant, zou je dat gaan omrekenen naar % van omzet, zou het wel eens niet zo verschrikkelijk kunnen zijn.

pardon ? overheid werkt met ons belastings geld en de miljoen die het project "kost" en dus wat je in de krant leest is maar een fractie van de werkelijke kosten .. de man-uren die de organisatie daaromheen maakt word vaak vergeten in de calculatie .. zoals incidenten,changes, vergaderingen en alle bijkomende resources ..zoals training of inwerk periode van je kantoor-gepeupel .. (de verborgen kosten dus) en dan heb je het nog niet over de externe(n) die overpriced tickets zitten te schuiven .. en de weken aan selectie en "wachtgeld" omdat ze niet alle accounts hebben ..

kortom je hebt het over een apparaat wat zich zonder moeite al in stand weet te houden zonder iets uit te voeren. en moet ik nog beginnen over "projecten"

Als je omzet een ton per jaar is, doet een geflopt project van €1000 net zo veel pijn als wanneer je omzet een miljoen per jaar is en je hebt een geflopt project van €10.000.
"De Overheid" is een giga organisatie met bijna een miljoen werknemers en honderden of duizenden "werkmaatschappijen". (915.000 in 2015: https://www.hr-kiosk.nl/n...ambtenaren-telt-nederland) Ter vergelijk, Ahold had er in 2016 "maar" 375.000 Wikipedia: Koninklijke Ahold NV

Hoe hoger het bedrag hoe harder de klap .. tik op de vingers tot aan het aftreden v.d minster/directeur .. maar dat zegt niks over "het gat in de business"

De "art of war" schrijver liet zien dat hij met weinig middelen een grote vijand kan verslaan, en het is voor iedereen even gemakkelijk om een groot project te laten falen .. individueel weet iedereen het beter maar het faalt dus in de uitvoering.

[Tsurany]

unezra schreef op vrijdag 21 juni 2019 @ 11:03:
[...]


Daar ben ik het dus hardgrondig mee oneens.

Als programmeur wil je niet dat de directie of een (interne of externe) klant gaat bepalen hoe jouw code er uit moet zien. Zij moeten bepalen welke functionaliteit nodig is. Hoe abstracter hoe beter. Uiteindelijk is het het team van programmeurs dat bepaald welke taal, welk framework en welke code daar het resultaat van is.

Same shit met beheer. Zodra de directie zich in mijn organisatie gaat bemoeien met hoe ik als uitvoerend techneut mijn werk moet doen, hoe ik systemen moet inrichten en welke software we nodig hebben, gaat het mis. Zij moeten denken in termen van requirements.

Kortom, hoe verder van de uitvoering je af zit, hoe abstracter het word en dat is alleen maar goed.

Ben je nu aan het trollen of weiger je het te begrijpen? Dit heeft helemaal niks te maken met invloed hebben op code, het gaat om het vertalen van requirements naar solutions. De gebruiker heeft functionaliteit X nodig dus we gaan samen om tafel zitten om te kijken hoe we dat visueel gaan implementeren, waar dat impact op heeft en hoe we dat gaan aanpakken. Zonder ook maar een seconde naar de code te kijken en zonder dat de gebruiker weet met welke software we werken.

Dat is in mijn ogen een kwestie van verkeerde uitvoering, niet van een verkeerd uitgangspunt.

"If all you have is a hammer, every problem looks like a nail." klopt, máár, wanneer je iets moet bevestigen en je bent vooral bekend met een schroef en iemand anders in de organisatie is vooral bekend met een spijker of lijm, zou je kunnen kijken of de oplossing niet ligt in het gebruik van spijkers met lijm. Jij levert je schroef in en gebruikt alleen nog maar spijkers en lijm. Dat verhef je tot standaard.

Zit het minder goed vast? Welnee. Maar je kunt wel opeens én je spijkers, hamers en lijm dusdanig groot inkopen dat je quantum korting krijg. Je hoeft alleen nog maar mensen op te leiden om schroeven en lijm te gebruiken. Je hoeft alleen het proces "hameren en lijmen" te beschrijven in plaats van schroeven en je bent volledig consistent.

Daar zijn uitzonderingen op, dus soms zul je toch een schroef nodig hebben, of een bout. Dat noemen we de uitzondering die de regel bevestigd.

En uiteindelijk nemen die uitzonderingen de overhand en gebruikt niemand meer de spijker met lijm. En dat is aan de ene kant mooi, het zorgt er namelijk voor dat ik werk heb. Aan de andere kant veranderd elk IT landschap zo in bij elkaar geknutselde zooi.

Ik denk juist dat een van de dingen die op dit moment gruwelijk fout is gegaan in de ICT, is dat programmeren dusdanig laagdrempelig is geworden, dat iedere dilweed die tot hoofdstuk 2 van "C++ for dummies" is gekomen, vind dat zijn of haar code het beste is en dat de beste oplossing is méér code te schrijven. Een van de gevolgen zie je in de Open Source wereld met de 100en Linux distro's die soms niet meer van elkaar verschillen dan een GUI. Forken om het forken, code schrijven omdat er niemand is die zegt "nee, maatwerk is duur, we kopen een standaard pakket, passen dat aan waar nodig, passen bedrijfsprocessen en werkwijzen aan waar nodig en klaar".

Maar volgens mij benader jij dit volledig vanuit je eigen omgeving met een handjevol medewerkers, heb je ooit wel eens meegekeken bij een multinational met tienduizenden medewerkers?

Mijn werk bestaat vrijwel volledig uit het vervangen van standaard applicaties omdat ze uiteindelijk nergens mee interfacen, elke wijziging vele tienduizenden euro's kost en de licentiekosten gigantisch zijn. En dan hebben de meeste bedrijven tientallen van zulke pakketten.

Die ITer op de afdeling is ook gruwelijk duur. Het is denk ik financieel onhoudbaar micro-units te creëren.
Je zou dan letterlijk op iedere afdeling, een complete set ICTers moeten hebben die volledig hun ding doen, terwijl je dan iedere vorm van schaalgrootte en de bijbehorende voordelen mist.

Schaalvergroting is niet zaligmakend, er zijn nadelen aan, dus het moet van geval tot geval bekeken worden maar ik denk zéker dat netto, schaalgrootte voordeel oplevert.

Kijk eens naar Amazon, Netflix,... bedrijven die niet al die legacy systemen hebben en geen last hebben van al die "dead weight". Amazon gelooft heilig in het two pizza team concept en dat heeft ze geen windeieren gelegd.

En dat betekent niet dat er geen standaarden zijn. Maar wel dat elk team vrij is om binnen die standaarden te ontwikkelen wat nodig is zonder dit elke keer te moeten laten goedkeuren door tientallen zogenaamde "vertalers" en "architecten".

Wat daar ontbreekt, is iemand die voorkomt dat iedere business unit zijn eigen eisen er doorheen drukt en geen water bij de wijn wil doen.

Unit A wil een mintgroene knop, Unit B wil een geelgroene knop. Waarom dan niet gewoon iemand die zegt "hardstikke leuk, maar jullie leren maar leven met een gifgroene knop, dat is beter en goedkoper dan 2 knoppen ontwikkelen".

Ik denk dat vaak die gebruiker helemaal geen knop A nodig heeft, maar dat iedereen prima kan leven met een knop B' (B-accent) of zelfs een knop D.

En waarom wil je daar iemand voor inhuren en niet een developer die boodschap laten brengen? Dat is weer typisch die ouderwetse manier van denken, iemand moet een developer vertellen wat hij moet doen want ze kunnen niet zelfstandig nadenken.

In mijn ervaring zijn zulke discussies juist zeer makkelijk te beslechten, je hebt de twee mensen van de business en twee developers en samen kom je tot een oplossing die voor iedereen werkt. Daar hoeft geen dure consultant tussen te zitten.

Sterker nog, de gebruiker krijgt in dit soort gevallen überhaupt geen keuze welke kleur hij wilt, dat bepaald het ontwikkelteam zelf. Daar zijn gewoon standaarden voor, dat hoeft niet elk team zelf af te stemmen.

Precies en daar zet je in mijn ideale wereld dus een goede tussenlaag tussen van mensen die zowel de taal van de techneuten als de business begrijpen en zorgen voor een optimale communicatie. Een vertaler, een soort menselijke babelfish. Vertalers zijn vaak efficiënter dan iedereen elkaars taal laten leren.

Het verleden heeft uitgewezen dat dit dus absoluut niet het geval is. Dit is echt een achterhaalde manier van denken. Zodra iets niet werkt is de neiging heel snel om maar extra mensen in te huren die overal gaan vertalen en managen terwijl in de praktijk juist blijkt dat veel minder schakels zorgt voor veel meer begrip en een veel betere kwaliteit van het eindproduct.

Ik geloof zelf heel erg in specialisten, mensen die een flinke verdieping kennen in hun vak. Een directeur die verstand heeft van het leiden van het bedrijf (maar geen reet begrijpt van ICT, prima, houden zo), een ICTer die juist prima weet hoe iets technisch geïmplementeerd moet worden en mensen daar tussen die zorgen dat de ICTer weet wat 'ie moet maken en de directeur tevreden is met het eindresultaat.

En dat is precies waarom IT zo'n slechte reputatie heeft. Constant excuses verzinnen om maar niet met "de business" te hoeven praten en zoveel mogelijk schakels er tussen willen gooien. Waarom kunnen alle andere afdelingen wel direct met elkaar communiceren maar moet IT weer perse vertaald worden? We hebben toch ook geen consultant tussen HR en marketing zitten die de requirements van marketing vertaald in de taal die HR begrijpt zodat ze een nieuw iemand kunnen inhuren?

Waarom is er een Albert Heijn en waarom heeft niet ieder dorp, iedere wijk nog zijn eigen supermarkt? Juist, schaalgrootte en standaardisering.

Precies dát is een van de dingen die blijkbaar voordelen bied.

En waarom heeft de Albert Heijn dan per product type soms wel tientallen varianten? Omdat er geen one size fits all oplossing is. En waarom zit schuin tegenover de Albert Heijn dan nog een Dirk, Jumbo, Aldi, Lidl,...? Omdat de Albert Heijn ook niet voor iedereen werkt.

Terug naar het onderwerp: Juist door de tussenlaag, de vertalers, zorg je er voor dat er sneller standaardisatie kan ontstaan. In plaats van dat iedereen op zijn eigen eilandje gaat zitten klooien, zit er een tussenlaag tussen die de vertaalslagen maakt. Niet alleen tussen ICT en business, maar ook tussen de diverse ICT en business onderdelen. Zo kan ieder zijn eigen taal blijven spreken, ieder zijn specialisme uit blijven voeren en heb je de overhead van communicatie maar 1x. Een goede tussenlaag, zorgt (in mijn beleving) voor een betere communicatie tussen alle lagen in de organisatie en dus voor een verkleining van het gat tussen business en ICT, niet een vergroting.

No offence maar heb jij hier überhaupt wel ervaring mee? Je zit in een organisatie van 40 man met twee IT'ers, hoe kan je vanuit die organisatie een beleving/ervaring hebben die relevant is?

[unezra]

vso schreef op vrijdag 21 juni 2019 @ 11:40:
[...]
pardon ? overheid werkt met ons belastings geld en de miljoen die het project "kost" en dus wat je in de krant leest is maar een fractie van de werkelijke kosten .. de man-uren die de organisatie daaromheen maakt word vaak vergeten in de calculatie .. zoals incidenten,changes, vergaderingen en alle bijkomende resources ..zoals training of inwerk periode van je kantoor-gepeupel .. (de verborgen kosten dus) en dan heb je het nog niet over de externe(n) die overpriced tickets zitten te schuiven .. en de weken aan selectie en "wachtgeld" omdat ze niet alle accounts hebben ..

kortom je hebt het over een apparaat wat zich zonder moeite al in stand weet te houden zonder iets uit te voeren. en moet ik nog beginnen over "projecten"

In tegenstelling tot het bedrijfsleven, is de overheid in principe transparant.
Iets met WOB.

Natuurlijk, de diverse overheden zouden op momenten wel eens wat commerciëler mogen denken, maar da's een compleet andere discussie...

Tsurany schreef op vrijdag 21 juni 2019 @ 11:41:
[...]
Ben je nu aan het trollen of weiger je het te begrijpen? Dit heeft helemaal niks te maken met invloed hebben op code, het gaat om het vertalen van requirements naar solutions. De gebruiker heeft functionaliteit X nodig dus we gaan samen om tafel zitten om te kijken hoe we dat visueel gaan implementeren, waar dat impact op heeft en hoe we dat gaan aanpakken. Zonder ook maar een seconde naar de code te kijken en zonder dat de gebruiker weet met welke software we werken.

Probleem is dat die gebruiker misschien helemaal niet functionaliteit X nodig heeft maar Y, dat hij ook best kan leven met Z en omdat een andere afdeling of gebruiker een soortgelijk probleem heeft dat ook met Z opgelost kan worden, kun je 2 vliegen in 1 klap slaan.

Ik denk dat voor dát soort slagen, je een ander soort specialisten nodig hebt dan diegenen die uiteindelijk de code schrijven of de systemen beheren.

[...]
Maar volgens mij benader jij dit volledig vanuit je eigen omgeving met een handjevol medewerkers, heb je ooit wel eens meegekeken bij een multinational met tienduizenden medewerkers?

Zeker.
Ik heb er zelfs voor en bij een aantal grotere organisaties gewerkt waarvan de grootste volgens wikipedia 63.000 werknemers heeft.

Dus nee, ik benader dit zeker niet vanuit mijn huidige eigen omgeving met een handjevol medewerkers. (Die ook nog eens een zelfstandige dochter is van een organisatie met meer dan 3500 werknemers, waar ik sinds pak 'm beet 2011 regelmatig over de vloer kom en mee samen werk.)

Los van dat ben ik niet onbekend met andere organisaties zoals de overheid en hoe die werken.

Helaas voor jou, maar je idee dat ik enkel kennis heb van het MKB en/of redeneer vanuit mijn eigen, huidige werkgever en functie, is onterecht.

Mijn werk bestaat vrijwel volledig uit het vervangen van standaard applicaties omdat ze uiteindelijk nergens mee interfacen, elke wijziging vele tienduizenden euro's kost en de licentiekosten gigantisch zijn. En dan hebben de meeste bedrijven tientallen van zulke pakketten.

Ik vecht er juist keihard voor al die ellende van maatwerk omdat het kan de deur uit te werken en meer en meer te standaardiseren. Als je 2 standaard applicaties hebt die niet direct met elkaar praten, bouw je een stuk middleware. Dát is je maatwerk, je gaat vind ik, niet beide applicaties vervangen door maatwerk. Leuk voor het legertje programmeurs dat daar een goede boterham aan verdient, niet goed voor het bedrijf en de uiteindelijke kosten.

[...]
En waarom wil je daar iemand voor inhuren en niet een developer die boodschap laten brengen? Dat is weer typisch die ouderwetse manier van denken, iemand moet een developer vertellen wat hij moet doen want ze kunnen niet zelfstandig nadenken.

In mijn ervaring zijn zulke discussies juist zeer makkelijk te beslechten, je hebt de twee mensen van de business en twee developers en samen kom je tot een oplossing die voor iedereen werkt. Daar hoeft geen dure consultant tussen te zitten.

Sterker nog, de gebruiker krijgt in dit soort gevallen überhaupt geen keuze welke kleur hij wilt, dat bepaald het ontwikkelteam zelf. Daar zijn gewoon standaarden voor, dat hoeft niet elk team zelf af te stemmen.

Ik denk dat developers prima kunnen nadenken maar ik denk dat development een specialisme is en dat het interfacen tussen verschillende afdelingen, bedrijfsonderdelen, etc, weer een ander specialisme is. Ieder zijn vak. Ik verwacht niet van een developer dat 'ie de taal van de eindgebruiker spreekt. Is ook niet nodig. Een developer moet fantastisch kunnen programmeren. Je verwacht van een vrachtwagenchaffeur toch ook niet dat 'ie zijn eigen vrachtwagen kan onderhouden? Een vrachtwagenchauffeur moet goed kunnen rijden, handig als 'ie een paar basisdingen van zijn vrachtwagen begrijpt maar voor onderhoud en reparaties heeft 'ie een monteur.

[...]
Het verleden heeft uitgewezen dat dit dus absoluut niet het geval is. Dit is echt een achterhaalde manier van denken. Zodra iets niet werkt is de neiging heel snel om maar extra mensen in te huren die overal gaan vertalen en managen terwijl in de praktijk juist blijkt dat veel minder schakels zorgt voor veel meer begrip en een veel betere kwaliteit van het eindproduct.

Minder schakels betekent niet, geen schakels.
Trek jij maar eens de ketting van je fiets. Kom je er vrij snel achter, dat een aantal schakels tussen je trapper en achterwiel best handig zijn.

[...]
En dat is precies waarom IT zo'n slechte reputatie heeft. Constant excuses verzinnen om maar niet met "de business" te hoeven praten en zoveel mogelijk schakels er tussen willen gooien. Waarom kunnen alle andere afdelingen wel direct met elkaar communiceren maar moet IT weer perse vertaald worden? We hebben toch ook geen consultant tussen HR en marketing zitten die de requirements van marketing vertaald in de taal die HR begrijpt zodat ze een nieuw iemand kunnen inhuren?

Tussen directeur en de creatieven van een reklamebureau zitten net zo goed schakels.
Natuurlijk heb je dit soort noodzakelijke schakels niet alleen in de ICT. Je hebt ze overal.

[...]
En waarom heeft de Albert Heijn dan per product type soms wel tientallen varianten? Omdat er geen one size fits all oplossing is. En waarom zit schuin tegenover de Albert Heijn dan nog een Dirk, Jumbo, Aldi, Lidl,...? Omdat de Albert Heijn ook niet voor iedereen werkt.

Klopt. Maar je hebt wel maar een hand vol grote supermarkten en die hebben bijna allemaal een vrij behoorlijke omvang.
De tijd van een kleine kruidenier in iedere wijk is redelijk voorbij.

[...]
No offence maar heb jij hier überhaupt wel ervaring mee? Je zit in een organisatie van 40 man met twee IT'ers, hoe kan je vanuit die organisatie een beleving/ervaring hebben die relevant is?

Zie boven.

Je lijkt te vergeten dat ik al een paar jaar mee ga in de ICT en mijn wereld iets groter is dan mijn huidige job en werkgever.
(Daarbij heb ik ook mijn ambities en kan ik die ambities niet verwezenlijken door me enkel te richten op zuiver en alleen mijn huidige dagbesteding.)

[Hydra]

unezra schreef op vrijdag 21 juni 2019 @ 11:03:
Als programmeur wil je niet dat de directie of een (interne of externe) klant gaat bepalen hoe jouw code er uit moet zien. Zij moeten bepalen welke functionaliteit nodig is. Hoe abstracter hoe beter. Uiteindelijk is het het team van programmeurs dat bepaald welke taal, welk framework en welke code daar het resultaat van is.

Wat een kul. Ten eerste wordt niet bedoeld dat de eindklant de code bepaalt, het gaat om de functionaliteit. En wat de gewenste functionaliteit moet zijn, wil je niet abstract hebben. Integendeel; hoe concreter hoe beter. En daar gaan dus redelijk wat iteraties aan design over en weer voordat je uberhaupt aan de implementatie begint. Want ook voor een gebruiker is uitleggen wat 'ie nodig heeft lastig.

Hou eens op te redeneren vanuit ingebeelde ervaring.

Je werkt bij een klein bedrijf dat IT een paar ITers als niet meer dan een cost center heeft. Klaar. Hou nu eens op te doen alsof je weet hoe het bij grote bedrijven werkt, het is duidelijk en meer dan triest dat je dat gewoon niet hebt. Het levert alleen maar irritaties en ontspoorde topics op waar het gaat tussen jou die A beweert en een handvol mensen die je proberen te overtuigen dat je er naast zit. Dit. Gebeurt. Iedere. Keer. Dat je al tig jaar bij dergelijke bedrijfjes werkt, werkt niet voor je. Integendeel; je denkt dat dat wereldje de hele IT is omdat het jouw hele wereld is. Snap nu eens dat je je hele carriere bij een bepaald type bedrijf werkt en daarin een enorme bias hebt in hoe je de wereld van de IT ziet!

[ Voor 10% gewijzigd door Hydra op 21-06-2019 12:50 ]

[Lensent]

Hoe abstracter hoe beter is dus typische de IT instelling zodat je lekker dictatortje over de business kunt blijven spelen.

Samenwerken gaat het over. Hoe specifieker de requirements hoe beter toch? Niks abstractie. Helderheid!

[unezra]

Lensent schreef op vrijdag 21 juni 2019 @ 13:08:
Hoe abstracter hoe beter is dus typische de IT instelling zodat je lekker dictatortje over de business kunt blijven spelen.

Samenwerken gaat het over. Hoe specifieker de requirements hoe beter toch? Niks abstractie. Helderheid!

Abstractie en helderheid kunnen prima samen gaan.

Sterker nog, als ik een niet-ICTer moet uitleggen hoe bepaalde systemen werken of hoe bepaalde zaken geborgd zijn, doe ik dat niet door alle technische details over diegene uit te strooien die ze tóch niet begrijpen, maar door te abstraheren tot een niveau dat voor de toehoorder begrijpelijk is.

Juist door te abstraheren, word het voor de toehoorder een helderder en begrijpelijker verhaal.

Wat betreft requirements, nee. Absoluut niet.

Ik wil niet dat de business naar me toe komt met "ik wil een Excel sheet met daarin alle gegevens van onze klanten, de contactmomenten, etc". Ik wil dat de business omschrijft wat ze zoeken en waarbij in dit geval het antwoord waarschijnlijk is "een CMS" en na een onderzoekstraject en verdere specificering van de wensen- en eisen, een specifiek CMS met specifieke inrichting.

[edie]

unezra schreef op vrijdag 21 juni 2019 @ 13:21:
[...]

Wat betreft requirements, nee. Absoluut niet.

Ik wil niet dat de business naar me toe komt met "ik wil een Excel sheet met daarin alle gegevens van onze klanten, de contactmomenten, etc". Ik wil dat de business omschrijft wat ze zoeken en waarbij in dit geval het antwoord waarschijnlijk is "een CMS" en na een onderzoekstraject en verdere specificering van de wensen- en eisen, een specifiek CMS met specifieke inrichting.

Dat zijn ook geen requirements, maar een oplossing voor een probleem.

Het moeilijkste van dit geheel is duidelijk krijgen wat het probleem is dat opgelost moet worden (dit kan uiteraard door middel van samenwerken). Dan kan IT & business samen gaan brainstormen over mogelijke oplossingen. Kies er een, implementeer deze en kijk of dit daadwerkelijk het probleem oplost. In dien nee, probeer een andere oplossing.

[unezra]

edie schreef op vrijdag 21 juni 2019 @ 13:50:
[...]
Dat zijn ook geen requirements, maar een oplossing voor een probleem.

Klopt en tóch is dat wat ik niet zelden hoor als requirement.
"We hebben tool X nodig."
"Ehm, zullen we beginnen met de vraag welk probleem je wil oplossen?"

Het moeilijkste van dit geheel is duidelijk krijgen wat het probleem is dat opgelost moet worden (dit kan uiteraard door middel van samenwerken). Dan kan IT & business samen gaan brainstormen over mogelijke oplossingen. Kies er een, implementeer deze en kijk of dit daadwerkelijk het probleem oplost. In dien nee, probeer een andere oplossing.

Exact.

Terwijl mijn ervaring is, dat de business niet zelden in de 1e fase véél te gedetailleerd denkt en meteen allerlei zaken in vult. (Bijvoorbeeld over wat er wel en niet technisch kan, wat het kost, etc.)

De business moet leren en begrijpen dat ze veel beter aan kunnen komen met een vaag verhaal, dan met een oplossing. ICT moet vervolgens leren en begrijpen dat het onderdeel van het ICT vak is, de achterliggende wensen en eisen van de business te vertalen naar een technische oplossing.

De business moet niet op de stoel van de ICTer gaan zitten, de ICTer moet enerzijds niet op de stoel van de business gaan zitten, anderzijds wél invloed durven en kunnen uitoefenen op de business. (Om bijvoorbeeld wildgroei en/of maatwerk te voorkomen.)

[Tsjipmanz]

Ik zie wel degelijk de toegevoegde waarde van analisten tussen 'IT' en 'de business', maar komt komt omdat ik er zelf ook één ben. De brugfunctie heeft onder meer als voordeel dat:

- Je beide partijen veel tijd bespaart. Hierdoor kan iemand uit de business zich voornamelijk focussen op zijn eigen werk, en is een ontwikkelaar niet continu bezig met het ophalen van informatie en vragen. Een goeie analist weet genoeg van de business om te begrijpen waarom iemand iets wil en welk probleem ze daarmee proberen op te lossen, en weet genoeg van IT om onzinnige verzoeken te counteren en realistische verwachtingen te scheppen over wat wel en niet kan

- De zaak beter wordt gedocumenteerd. Een vraag van de business is vaak dubbelzinnig en onvolledig. Een analist kan helpen de ambiguïteit weg te halen, door te vragen en de zaak gestructureerd op papier te zetten. Goed gedocumenteerde requirements komen later soms enorm van pas en kunnen 'nieuwe' analyse trajecten overbodig maken

- Er niet onnodig een product wordt ontwikkeld. Bij goed doorvragen van een analist blijkt dat een bepaalde wens soms een stuk eenvoudiger kan worden ingevuld dan gedacht, door bijvoorbeeld werkprocessen aan te passen of bestaande software anders in te richten

- Er iemand kijkt naar het grotere geheel. Wijzigingen in functionaliteit resulteren vaak in wijzigingen in bedrijfsprocessen en werkinstructies, dingen afstemmen met privacy- en securityspecialisten, sparren met enterprise-architecen of de beoogde oplossing in het huidige applicatielandschap past, afstemmen met de beheerorganisatie, etc

Ik snap de weerzin van sommige mensen tegen analisten wel, want er lopen veel figuren rond die zichzelf analist noemen en dat niet zijn of niet kunnen. Maar dat wil niet zeggen dat de functie op zichzelf overbodig is, een goeie analist is er voor bedoeld om het genoemde gat tussen business en IT te overbruggen.

[jan390]

Heerlijk al die aannames over wat "de andere kant wel of niet moet doen" en verwachten dat andere afdelingen anders gaan werken omdat jij (of jouw afdeling dat wilt). Ga er eens van uit dat andere afdelingen/mensen mogelijk een ander belang/belevingswereld hebben dan datgene wat jij hebt. Mogelijk worden zij zelfs op hele andere doelstellingen aangestuurd dan wat jij verwacht.
Er gaat zelden/nooit datgene worden aangeleverd zoals je het zelf wilt. Communicatie, helderheid en duidelijkheid zie ik als key in dit soort afstemmingen: Wat verwacht ik van jou, wat doe ik, wat krijg je van mij (en bespreek dit). In het geval van keuzes: wat zijn de alternatieven, wat zijn de pro's wat zijn de con's: Maak het simpel en zichtbaar.
De Business zou geen IT specialist moeten zijn, zij hebben andere verantwoordelijkheden. Het helpt natuurlijk als ze (analytisch) kunnen meedenken, maar doen ze dat niet dan zal iemand toch iemand de intermediair moeten zijn om de (vage) vragen te vertalen naar requirements/oplossing.

[edie]

Trouwens, dat hele gedoe over 'requirements' is ook iets van de vorige eeuw: "Laten we, de analysten, eerst uitgebreid met de business gaan analyseren en requirements tot in detail opstellen (en de business laten accoderen), voordat IT ook maar een vinger uitsteekt. De requirements kunnen uiteraard niet wijzigen gedurende de ontwikkeling - want de business heeft geaccodeerd."

Dit is de oude manier van werken en hier gaat ernorm veel tijd mee verloren. Het opstellen van de requirements duurt al snel enkele weken tot maanden, en dan moet de ontwikkeling nog plaatsvinden van enkele maanden (waarna het ook nog moet worden getest en akkoord worden bevonden door de business voordat het in productie kan). Zo gaat er al snel een jaar overheen van wens van gebruiker tot oplevering - en in de tussentijd is de werkelijkheid veranderd waardoor het gemaakte niet meer relevant is.

Hiervoor is nu juist het hele Agile ontstaan. Simpele probleemomschrijving, eenvoudige acceptatie criteria, na enkele dagen/weken een versie om te testen, en dan door naar productie. Werkt het toch niet zoals verwacht? Geen probleem, over 3 weken is er een nieuwe versie in productie met een aanpassing.

[Mugwump]

edie schreef op vrijdag 21 juni 2019 @ 15:53:
Trouwens, dat hele gedoe over 'requirements' is ook iets van de vorige eeuw: "Laten we, de analysten, eerst uitgebreid met de business gaan analyseren en requirements tot in detail opstellen (en de business laten accoderen), voordat IT ook maar een vinger uitsteekt. De requirements kunnen uiteraard niet wijzigen gedurende de ontwikkeling - want de business heeft geaccodeerd."

Dit is de oude manier van werken en hier gaat ernorm veel tijd mee verloren. Het opstellen van de requirements duurt al snel enkele weken tot maanden, en dan moet de ontwikkeling nog plaatsvinden van enkele maanden (waarna het ook nog moet worden getest en akkoord worden bevonden door de business voordat het in productie kan). Zo gaat er al snel een jaar overheen van wens van gebruiker tot oplevering - en in de tussentijd is de werkelijkheid veranderd waardoor het gemaakte niet meer relevant is.

Hiervoor is nu juist het hele Agile ontstaan. Simpele probleemomschrijving, eenvoudige acceptatie criteria, na enkele dagen/weken een versie om te testen, en dan door naar productie. Werkt het toch niet zoals verwacht? Geen probleem, over 3 weken is er een nieuwe versie in productie met een aanpassing.

Totdat je in een organisatie zit met minimaal tientallen ontwikkelteams met vele onderlinge raakvlakken waarbij nieuwe wensen vanuit klanten, sales, eindgebruikers en ga zo maar door impact hebben op meerdere teams, op verschillende plekken in de organisatie op vele verschillende wijzen kunnen worden opgelost, waar risk, compliance, legal en andere afdelingen altijd wel weer een mening hebben en ga zo maar door.

[_vision]

edie schreef op vrijdag 21 juni 2019 @ 15:53:
Trouwens, dat hele gedoe over 'requirements' is ook iets van de vorige eeuw: "Laten we, de analysten, eerst uitgebreid met de business gaan analyseren en requirements tot in detail opstellen (en de business laten accoderen), voordat IT ook maar een vinger uitsteekt. De requirements kunnen uiteraard niet wijzigen gedurende de ontwikkeling - want de business heeft geaccodeerd."

Wat jij hier beschrijft is een waterfall approach van requirements gathering. Dat is inderdaad niet heel efficient, maar dat heeft niks te maken met de waarde van requirements, die zijn nog steeds broodnodig. En ja, ook Agile heeft ze maar dan zijn ze hip omgedoopt tot 'user stories'. Agile pakt dit echter kort-cyclisch en multidisciplinair aan. Dat resulteert in een efficienter proces.

[ Voor 7% gewijzigd door _vision op 21-06-2019 16:50 ]

[Tsurany]

Mugwump schreef op vrijdag 21 juni 2019 @ 16:21:
[...]


Totdat je in een organisatie zit met minimaal tientallen ontwikkelteams met vele onderlinge raakvlakken waarbij nieuwe wensen vanuit klanten, sales, eindgebruikers en ga zo maar door impact hebben op meerdere teams, op verschillende plekken in de organisatie op vele verschillende wijzen kunnen worden opgelost, waar risk, compliance, legal en andere afdelingen altijd wel weer een mening hebben en ga zo maar door.

Waarom zou dat daar niet werken? Het is een cultuurverandering, daar moet de hele organisatie in mee. Realiseren dat zulke vertragende processen veel efficiënter kunnen of niet eens nodig zijn.

[Mugwump]

Tsurany schreef op vrijdag 21 juni 2019 @ 17:39:
[...]

Waarom zou dat daar niet werken? Het is een cultuurverandering, daar moet de hele organisatie in mee. Realiseren dat zulke vertragende processen veel efficiënter kunnen of niet eens nodig zijn.

Het is een reactie op de laatste alinea. Daarin zijn slechts twee partijen en geen dwarsverbanden.

Natuurlijk kun je als grote organisatie ook een soort van Agile werken, maar al die scaled Agile aanpakken zijn heel wat complexer dan "even wat werk plannen en na de sprint weer evalueren en wijzigen".

[unezra]

Mugwump schreef op vrijdag 21 juni 2019 @ 16:21:
[...]
Totdat je in een organisatie zit met minimaal tientallen ontwikkelteams met vele onderlinge raakvlakken waarbij nieuwe wensen vanuit klanten, sales, eindgebruikers en ga zo maar door impact hebben op meerdere teams, op verschillende plekken in de organisatie op vele verschillende wijzen kunnen worden opgelost, waar risk, compliance, legal en andere afdelingen altijd wel weer een mening hebben en ga zo maar door.

En terecht. Die afdelingen hebben met reden een mening *en* invloed op het product of dienst die ontwikkeld en/of aangeschaft word.

Dat is ook weer een van de redenen waarom een tussenlaag nodig is. Het is aan die tussenlaag om iets langs de juiste afdelingen te trekken en te zorgen dat alle wensen en eisen bij elkaar komen en vertaald worden naar een voor alle betrokkenen passend eindresultaat.

Waarom zou een eindgebruiker of developer de juiste wegen langs risk, compliance, legal, etc, moeten weten? Laat daar mensen werken die dát interessant vinden.

Ik zie ook niet in waarom een developer of beheerder een complete doorrekening zou moeten doen. Dat is een vak apart én iets waar lang niet iedereen interesse in heeft. (Toevallig ben ik een van die mensen die dat wél heel interessant vinden, maar ik vind de pure uitvoerende techniek dan weer steeds minder interessant. Om mee bezig te zijn en voor betaald te worden that is.)

[_vision]

Mugwump schreef op vrijdag 21 juni 2019 @ 17:52:
[...]


Het is een reactie op de laatste alinea. Daarin zijn slechts twee partijen en geen dwarsverbanden.

Natuurlijk kun je als grote organisatie ook een soort van Agile werken, maar al die scaled Agile aanpakken zijn heel wat complexer dan "even wat werk plannen en na de sprint weer evalueren en wijzigen".

Precies dat.

En...zoals het SAFe framework al aangeeft heb je dus wel die tussenlagen weer nodig met Portfolio Management, Enterprise en Solution Architectuur e.d. anders wordt het een ongecoördineerde teringzooi als tientallen ontwikkelteams op eigen houtje wat bezig zijn. Been there, done that overigens.

[ Voor 11% gewijzigd door _vision op 21-06-2019 18:01 ]

[Mugwump]

_vision schreef op vrijdag 21 juni 2019 @ 17:58:
[...]


Precies dat.

En...zoals het SAFe framework al aangeeft heb je dus wel die tussenlagen weer nodig met Portfolio Management, Enterprise en Solution Architectuur e.d. anders wordt het een ongecoördineerde teringzooi als tientallen ontwikkelteams op eigen houtje wat bezig zijn. Been there, done that overigens.

Klopt, maar dan wel in een actief participerende, faciliterende rol. Een vijftigtal zelfsturende silo's levert een bedrijf niet veel op, maar een boekwerk met duizend geboden waar elk team zich tot op de letter aan dient te conformeren ook niet.
Je kunt ook simpelweg voorschrijven dat compliance akkoord moet gaan met de gekozen oplossing en dit verder aan individuele teams en de compliance afdeling overlaten.
Ik zie ook wel vaak zaken als het binnen de hele organisatie af proberen te dwingen van dezelfde code style / guidelines waarschijnlijk gebaseerd op het idee dat dit ertoe gaat leiden dat je heel makkelijk ontwikkelaars tussen teams kunt verplaatsen. Wat dat soort zaken betreft zie ik liever meer autonomie bij teams zelf.

[fonsoy]

De vraag is of je bij verbeter/aanpastrajecten van interne software wel met agile ontwikkelmethoden wenst te werken. In mijn ervaring verlopen de meeste volgens een watervalaanpak omdat vanuit het MT het belangrijk is om de maximale scope- en kosten vast te kunnen leggen.

Hoe leg je die scope dan vast?
Simpel. Je stelt in het projectplan vast welke gebruikers key-users zijn. Met hen vorm je een programma van eisen. In theorie behoor je deze stap te doen voordat een keuze is gemaakt over de software. Zodat deze lijsten kunnen helpen met het selecteren van de meest geschikte oplossing. In werkelijkheid heeft een bobo allang een systeem gekozen en is deze stap wel noodzakelijk maar niet relevant in de selectie.

Wat vaak een probleem is, is dat deze eisenprogramma's op den duur onder het stof komen. Daardoor is het belangrijk dat de key-users tekenen voor hun programma van eisen als zijnde volledig samengesteld. Hier komt de rol van een analist al bij kijken. Het samenstellen van goede eisen is niet makkelijk. Vooral niet als je later ook nog wil bewijzen dat een bepaalde eis daadwerkelijk is doorgevoerd in de software. De gebruiker, met name de minder technische gebruiker, redeneert vaak vanuit de functionaliteit van het oude systeem.

Borging is essentieel! Hoe vaak is het niet gebeurd dat ik een eis op tafel legde - en de eis kwam er geheel anders uit te zien. Dankzij de in andere reacties genoemde tussenlagen van architecten, product owners, analisten en programmeurs. Regelmatig was de gehele functionaliteit onbruikbaar. Het is dus raadzaam om voor oplevering de key-users de eisen te laten testen en ook daar hen laten tekenen voor akkoord. De 'tussenlaag' zal hier samen met hen de eerder beschreven eis doornemen. Anders komen ze er veelal niet doorheen.

Vastleggen is dus het credo. En hier komt een analist/architect bij kijken. Hoe de zaken gerealiseerd worden heeft een analist weinig mee te maken, buiten dat er naar het ontwerp van de aanpassing gekeken dient te worden door hem en de key-user.

Mijn inziens is de rol van de analist NIET om systeemeisen en programmacode te schrijven. Maar wel om die te beoordelen en met mensen te bespreken waarbij ze pogen het proces zo soepel mogelijk te laten verlopen.

In de klassieke servicegerichte business IT ondersteuning wordt een gebruiker gemoederd. Ze kunnen de meest belachelijke wensen en vragen bij IT indienen waarna er vervolgens naar al die zaken serieus wordt gekeken. Soms wordt er ook te pas en te onpas geimplementeerd. Heden ten dage zijn de middelen vaak anders en moet er kritischer naar de resources worden gekeken. Het is dus niet meer zo dat er sprake is dat er een gebruiker roept en de IT-er gelijk begint te lopen. In veel organisaties kom je echter nog personen tegen die van de dienst verwachten dat ze a-la-minute geholpen worden met niet-urgente problemen. Dit is ook al gemeld, de verwachtingen zijn regelmatig te hoog.

Croga schreef op donderdag 20 juni 2019 @ 22:13:
[...]


Reductio ad absurbum noemen we dat.
Waarom zou je 100en tools krijgen? Waarom zouden die onbeheersbaar en onbeheerbaar zijn? Waarom zou daar niemand voor verantwoordelijk zijn? Dat zijn allemaal reductios die je doet op basis van aannames die helemaal niet hoeven te kloppen.
Ennehhh.... de mens aanpassen aan de software!?!? Really!? De mens aanpassen kost generaties. De software aanpassen minuten. Wat denk je dat beter is?

Lokale IT die lokaal verantwoordelijk is voor lokale tooling zorgt niet voor wildgroei en zeker niet voor gebrek aan verantwoordelijkheid. Juist het omgekeerde. Wie denk je dat er meer verantwoordlijkheid neemt; degene die de tool bouwt voor het proces waar hij verantwoordelijk voor is, of die IT-fipo 3 hoog achter die de gebruiker nog nooit gezien heeft? Verantwoordelijkheid gaat hand in hand met afhankelijkheid. Als je niet ergens van afhankelijk bent is het heel moeilijk om daar verantwoordelijkheid voor te nemen.

In het kader van mijn eerder geschreven stuk wil ik ook even beargumenteren waarom ik het met je geheel oneens ben. Als je de software wil aanpassen, zal je systeemeis hetzij verkeerd geimplementeerd zijn hetzij verkeerd gedocumenteerd. In het eerste geval is er sprake van wat rework/bug, maar in het andere kader wil je je nu gewijzigde systeemeis ook weer vastleggen en laten tekenen door de key-user! Anders is het einde zoek, en ga je bij livegang gegarandeerd de bietenbrug op - waartegen heb je anders zitten testen?

In het kader van lokale tooling gaat het er heel erg om wat voor eisen je aan je systeemlandschap stelt. Stel je eisen op het vlak van corporate security en privacy? Hoe weet je dat deze eisen bij een wildgroei aan tooling geborgd zijn door partners in allerlei landen en allerlei talen? Dat is bij grotere organisaties weldegelijk een uitdaging.

[ Voor 7% gewijzigd door fonsoy op 22-06-2019 10:21 ]

[Sissors]

unezra schreef op vrijdag 21 juni 2019 @ 13:57:
[...]


Klopt en tóch is dat wat ik niet zelden hoor als requirement.
"We hebben tool X nodig."
"Ehm, zullen we beginnen met de vraag welk probleem je wil oplossen?"

Andersom ken ik hem ook hoor

"Hier heb je tool X, gebruik hem".
> "Ehm, waarom hebben we die nodig?"
"Voor reden X"
> "Ja maar daar hebben we al een prima tool voor..."

En tot op de dag van vandaag proberen ze ons tool X door de neus te boren...

[D_Jeff]

Inmiddels durf ik toch wel te zeggen dat IT redelijk serieus genomen wordt. Het is geen "vaag" onderwerp meer.

Wel merk het verschil in generatie + achtergrond: Is de manager dichterbij het pensioen en heeft de persoon in kwestie geen affiniteit met IT, dan is het verkrijgen van budget lastiger. (En vraagt het meer onderbouwing om het geregeld te krijgen).

Tot zover IT algemeen.
Ik wil bij deze eens gebruik maken om een andere deur in de IT "open te trappen": IT Security
Tevaak maak ik het nog mee dat een beheerder/IT-afdeling iets moois wil (firewall / email gateway filter/enz) en gewoon simpelweg te horen krijgt: "Dat gebeurt ons toch niet, dus hebben we het niet nodig."

Zelfs bij bedrijven waarvan de bedrijfsvoering semi-automatisch draait en een defecte server grof geld kost (ik noem geen namen )

Gevolg is dat de beheerder(-s)/IT-afdeling die wil security-minded zijn allerlei kunstjes willen gaan uithalen om alsnog IETS te doen. Vaak nog met onbegrip van management ("Waarom verspil je daar je tijd aan? Er zijn andere zaken die belangrijker zijn!")

[Sissors]

Tja maar ook daar is het een afweging. Het aantal IT security personen (of gewoon systeembeheerders) die compleet doorslaan in security, waardoor het behalve onwerkbaar wordt ook minder veilig, is ook niet op één hand te tellen.

Gisteren zag ik het nog in een ander topic: Eentje die ging mogelijkheid maken van screenshots in applicaties blokkeren. Klinkt goed toch? Kan je niet meer screenshot maken van bijvoorbeeld klant gegevens of andere gevoelige data. Behalve dat 5 minuten nadat die policy in werking treed de eerste werknemer bedenkt dat hij wel gewoon een foto kan maken met zijn telefoon en die door sturen aan zijn collega. Dus in plaats van het veiliger maken, heb je dan alleen gezorgd dat mensen hetzelfde blijven doen maar nu via privé devices en diensten van derde partijen.

Zelfde verhaal natuurlijk met idiote password policies. En dat Dropbox bij mijn werkgever is geblokkeerd uit 'veiligheidsredenen' (inclusief de website) kan ik alleen maar onder gebruikertje pesten scharen gezien Onedrive en Google Drive beide wel toegestaan zijn.

[ Voor 14% gewijzigd door Sissors op 22-06-2019 10:42 ]

[Tsurany]

fonsoy schreef op zaterdag 22 juni 2019 @ 10:17:
De vraag is of je bij verbeter/aanpastrajecten van interne software wel met agile ontwikkelmethoden wenst te werken. In mijn ervaring verlopen de meeste volgens een watervalaanpak omdat vanuit het MT het belangrijk is om de maximale scope- en kosten vast te kunnen leggen.

En daar gaat het dus elke keer weer mis. De verwachting met waterval kosten en scope te kunnen bepalen en vast te leggen waarna deze nooit meer zal wijzigen. Hoe vaak is dat nu echt gelukt?

Wat mij blijft verbazen is dat heel veel innoverende bedrijven van de laatste jaren hebben laten zien dat waterval simpelweg niet werkt. Waarom blijven sommigen daar dan zo krampachtig aan vast houden? En als ze dan Agile doen moet het wel Agile in een waterval jasje omdat het toch tot in detail gemanaged wordt.

fonsoy schreef op zaterdag 22 juni 2019 @ 10:17:
Hoe leg je die scope dan vast?
Simpel. Je stelt in het projectplan vast welke gebruikers key-users zijn. Met hen vorm je een programma van eisen. In theorie behoor je deze stap te doen voordat een keuze is gemaakt over de software. Zodat deze lijsten kunnen helpen met het selecteren van de meest geschikte oplossing. In werkelijkheid heeft een bobo allang een systeem gekozen en is deze stap wel noodzakelijk maar niet relevant in de selectie.

Wat vaak een probleem is, is dat deze eisenprogramma's op den duur onder het stof komen. Daardoor is het belangrijk dat de key-users tekenen voor hun programma van eisen als zijnde volledig samengesteld. Hier komt de rol van een analist al bij kijken. Het samenstellen van goede eisen is niet makkelijk. Vooral niet als je later ook nog wil bewijzen dat een bepaalde eis daadwerkelijk is doorgevoerd in de software. De gebruiker, met name de minder technische gebruiker, redeneert vaak vanuit de functionaliteit van het oude systeem.

En je denkt serieus dat dit een goede oplossing is? De key-users laten tekenen voor eisen zodat je ze er later mee om de oren kan slaan als het niet werkt zoals ze eigenlijk willen?

Borging is essentieel! Hoe vaak is het niet gebeurd dat ik een eis op tafel legde - en de eis kwam er geheel anders uit te zien. Dankzij de in andere reacties genoemde tussenlagen van architecten, product owners, analisten en programmeurs. Regelmatig was de gehele functionaliteit onbruikbaar. Het is dus raadzaam om voor oplevering de key-users de eisen te laten testen en ook daar hen laten tekenen voor akkoord. De 'tussenlaag' zal hier samen met hen de eerder beschreven eis doornemen. Anders komen ze er veelal niet doorheen.

Vastleggen is dus het credo. En hier komt een analist/architect bij kijken. Hoe de zaken gerealiseerd worden heeft een analist weinig mee te maken, buiten dat er naar het ontwerp van de aanpassing gekeken dient te worden door hem en de key-user.

Mijn inziens is de rol van de analist NIET om systeemeisen en programmacode te schrijven. Maar wel om die te beoordelen en met mensen te bespreken waarbij ze pogen het proces zo soepel mogelijk te laten verlopen.

En dit is juist precies waarom je Agile wilt gaan ontwikkelen. Elke twee weken reviewen wat er gebouwd is zodat je tijdig bij kan sturen en aanpassingen door kan voeren. Rechtstreeks contact tussen de key users en het gehele ontwikkelteam, hoe simpel wil je het hebben?

[RobbieB]

D_Jeff schreef op zaterdag 22 juni 2019 @ 10:35:
Tot zover IT algemeen.
Ik wil bij deze eens gebruik maken om een andere deur in de IT "open te trappen": IT Security
Tevaak maak ik het nog mee dat een beheerder/IT-afdeling iets moois wil (firewall / email gateway filter/enz) en gewoon simpelweg te horen krijgt: "Dat gebeurt ons toch niet, dus hebben we het niet nodig."

Zelfs bij bedrijven waarvan de bedrijfsvoering semi-automatisch draait en een defecte server grof geld kost (ik noem geen namen )

Gevolg is dat de beheerder(-s)/IT-afdeling die wil security-minded zijn allerlei kunstjes willen gaan uithalen om alsnog IETS te doen. Vaak nog met onbegrip van management ("Waarom verspil je daar je tijd aan? Er zijn andere zaken die belangrijker zijn!")

Eens, maar als het management zo zeker is van zichzelf, laat ze dat maar bewijzen. De enige manier om echt te testen hoe veilig je bent is door een goede red-teaming exercitie uit te voeren. Minimale betrokkenheid van intern personeel, alleen approval van top management en een externe partij die minimaal een maand de tijd krijgt om binnen te komen.
Geloof mij maar dat als je hier goede partijen voor gebruikt, 99% van de bedrijven nat gaat.

Zo'n exercitie kost geld, maar wel een schijntje van als er een keer echt een partij kwade bedoelingen heeft.
Desnoods haal je het als security manager uit je eigen budget, want daarna krijg je voldoende om een blik mensen aan te nemen om het te corrigeren.

[Mugwump]

Sissors schreef op zaterdag 22 juni 2019 @ 10:41:
Tja maar ook daar is het een afweging. Het aantal IT security personen (of gewoon systeembeheerders) die compleet doorslaan in security, waardoor het behalve onwerkbaar wordt ook minder veilig, is ook niet op één hand te tellen.

Gisteren zag ik het nog in een ander topic: Eentje die ging mogelijkheid maken van screenshots in applicaties blokkeren. Klinkt goed toch? Kan je niet meer screenshot maken van bijvoorbeeld klant gegevens of andere gevoelige data. Behalve dat 5 minuten nadat die policy in werking treed de eerste werknemer bedenkt dat hij wel gewoon een foto kan maken met zijn telefoon en die door sturen aan zijn collega. Dus in plaats van het veiliger maken, heb je dan alleen gezorgd dat mensen hetzelfde blijven doen maar nu via privé devices en diensten van derde partijen.

Zelfde verhaal natuurlijk met idiote password policies. En dat Dropbox bij mijn werkgever is geblokkeerd uit 'veiligheidsredenen' (inclusief de website) kan ik alleen maar onder gebruikertje pesten scharen gezien Onedrive en Google Drive beide wel toegestaan zijn.

Ik denk inderdaad dat je wel kunt stellen dat er bijna nergens zo'n grote gat zit tussen gebruikers en IT als op het gebied van security.

Het aantal keren dat ik aan systemen heb gewerkt waar we ons in allerlei onmogelijke bochten moesten wringen om datatoegang te beperken terwijl gebruikers vervolgens doodleuk dezelfde informatie met klanten of leveranciers deelden in Excel sheets of screenshots die onversleuteld via mail werden verstuurd is niet echt op één hand te tellen.

Vaak is het ook meer een kwestie van voldoen aan de regeltjes dan dat er een echte intentie is om gedegen informatiebeveiliging te hebben.

[D_Jeff]

@Sissors Een beetje Off-topic:
<sub>Dropbox blokkeren is vanwege het verdienmodel van Dropbox en dat beseffen veel mensen niet. Autodesk is zo'n andere club die ook heel agressief is (bijv: een studentlicentie gebruiken op een bedrijfsmachine)

OneDrive (bijv) kent die agressie namelijk (nog niet)</sub>

Het blokkeren van screenshots is wel beetje too much, ja.

[Napo]

D_Jeff schreef op zaterdag 22 juni 2019 @ 12:43:
Dropbox blokkeren is vanwege het verdienmodel van Dropbox en dat beseffen veel mensen niet. Autodesk is zo'n andere club die ook heel agressief is (bijv: een studentlicentie gebruiken op een bedrijfsmachine)

Net zoals het blokkeren van het schrijven naar USB-devices zeker

D_Jeff schreef op zaterdag 22 juni 2019 @ 12:43:
Het blokkeren van screenshots is wel beetje too much, ja.

Je kan niet alles blokkeren en dat moet je ook niet willen. Wat je wel moet realiseren is dat met het blokkeren van het gemakkelijkste lek men bewust daar omheen gaat werken. Iets wat relatief gemakkelijk aantoonbaar tegen het beleid is en derhalve ook het aanspreken van dit gedrag gemakkelijker maakt.

[ Voor 38% gewijzigd door Napo op 22-06-2019 13:57 ]

[unezra]

Sissors schreef op zaterdag 22 juni 2019 @ 10:41:
Tja maar ook daar is het een afweging. Het aantal IT security personen (of gewoon systeembeheerders) die compleet doorslaan in security, waardoor het behalve onwerkbaar wordt ook minder veilig, is ook niet op één hand te tellen.

Gisteren zag ik het nog in een ander topic: Eentje die ging mogelijkheid maken van screenshots in applicaties blokkeren. Klinkt goed toch? Kan je niet meer screenshot maken van bijvoorbeeld klant gegevens of andere gevoelige data. Behalve dat 5 minuten nadat die policy in werking treed de eerste werknemer bedenkt dat hij wel gewoon een foto kan maken met zijn telefoon en die door sturen aan zijn collega. Dus in plaats van het veiliger maken, heb je dan alleen gezorgd dat mensen hetzelfde blijven doen maar nu via privé devices en diensten van derde partijen.

Zelfde verhaal natuurlijk met idiote password policies. En dat Dropbox bij mijn werkgever is geblokkeerd uit 'veiligheidsredenen' (inclusief de website) kan ik alleen maar onder gebruikertje pesten scharen gezien Onedrive en Google Drive beide wel toegestaan zijn.

Da's geen gebruikertje pesten, da's compleet falend beleid.

Ze zouden *alle* filetransfer platformen moeten verbieden, zelf een goed alternatief bieden én en zinvolle sancties zetten op het gebruik van iets anders dan het interne filetransfer platform.

Persoonlijk vind ik dat in een ideale wereld, zoiets niet onmogelijk gemaakt hoeft te worden en iedereen gewoon begrijpt waarom iets niet mag, dus het ook niet doet.

Dit is dus ook wel een punt waarom er tussenlagen nodig zijn. In geval van dit concrete voorbeeld heb ik een aantal rollen, waaronder die van tussenpersoon.

- Ik luister naar de business, zie dat er behoefte is aan iets als een filetransfer platform
- Ik zit op de stoel van security, dus vind ook dat dit *niet* mag met diensten als DropBox
- Ik ben de systeem- en netwerkbeheerder, die er voor zorgt dat enerzijds zaken als DropBox worden afgegrendeld, anderzijds een andere oplossing word geïnstalleerd en onderhouden
- Ik schrijf het businessplan en doe een kostencalculatie, plus een beperkte risico analyse en overtuig de directie van het nut van de aanschaf van een intern platform
- Ik heb het beleid geschreven / de regel bedacht dat we in principe zo min mogelijk in-house ontwikkelen ("off-the-shelf-tenzij")

In een kleine organisatie is dat 1 persoon, in tenminste 5 rollen. Logisch dat in een grotere organisatie, dit tenminste 5 teams of personen zijn.

Waarom?

Als we de eindgebruikers hadden laten beslissen, hadden we gewoon gebruik gemaakt van DropBox of waren alle bestanden per email verstuurd. De directie begrijpt niet dat dat niet kán, de eindgebruikers ook niet. Eindresultaat: Een gigantisch veiligheidsprobleem.

Die rollen zijn dus noodzakelijk en omdat in grotere organisaties de belangen en teams groter zijn, plus je meer specialisatie nodig hebt, zijn hier tussenpersonen voor die er voor zorgen dat én functionaliteit word toegevoegd (de klant, intern of extern, zijn werk kan doen en de tooling krijgt die ze nodig hebben) én er tegelijkertijd word nagedacht over het organisatiebelang (security) én er een pakketkeuze word gemaakt waarbij ook het kostenaspect en beheerbaarheid een rol speelt.

In mijn beleving, haal je die tussenlaag er tussenuit, ga je heel snel, heel erg nat.

Logisch dat je in een kleinere organisatie mensen meerdere rollen hebben maar de rollen moeten er wel zijn én ze moeten ook los van elkaar worden gezien. Het is niet zelden dat ik tegen een eindgebruiker zeg "ik zet nu even de pet op van security officer" en dan DIE mening vertolk, die in gevallen strijdig is met mijn mening als sysadmin of andere rol.

[ZieMaar!]

Mijn ervaring (multinationals) is dat het gat juist kleiner aan het worden is. Als je een goede (geschaalde) Agile aanpak kiest, met goed portfoliomanagement en zowel de business als IT helpt om daar een succes van te maken, dan kunnen er hele mooie dingen gebeuren.

Ik werk nu, als IT manager, binnen een omgeving waar dit behoorlijk goed gaat. We noemen dus geen projectleiders productowners, maar nemen daar andere mensen voor aan. Legacy uitfaseren? Gewoon waterval (dat werkt prima in die gevallen). Ja, we hebben enorm veel compliance, privacy, juridische en weet ik veel wat voor verplichtingen, maar dat is prima te regelen. Het is een groot bedrijf, dus financiën en budgetten zijn belangrijk, maar we hebben het zo voor elkaar gekregen dat het wel de business helpt en niet een loze rapportagelijn is.

Is het dan perfect? Nee, tuurlijk niet. Maar het is veel beter dan het was en het gat is kleiner dan ooit. De business is bijna continu bij onze teams op de vloer en onze teams snappen het businessproces. Strategische plannen maken we samen en besturen we ook samen.

Natuurlijk hebben wij ook IT geneuzel (updates die midden op de dag in callcenters draaien, dat soort dingen), maar we leren daar wel van en zijn met name op ontwikkelvlak al goed op weg.

[LucyLG]

Onder de dienstverleners zoals accountants, juristen, notarissen en trustkantoren is er een enorm gat met de IT. Ik ben zelf jurist en leer hier een hoop, maar kan denk ik wel iets erover zeggen.

Hier is de veiligheid van bestanden een puntje van aandacht. De dropbox etc is niet geblokkeerd maar denk dat alle clouds blokkeren lastig wordt. Je kan weliswaar alleen via een app in de kantoorruimte komen, dus inloggen met een token, maar om die reden kopieert iedereen zn privemail in om zo makkelijk stukken te kunnen lezen als je in de trein zit.

Ze werken met USB sticks althans die kunnen in de computer. En ga nog maar door aan issues die niet worden opgemerkt. Emailen van bestanden met 30 mensen in de CC. Ik denk dat dat een risico is. ookal is de client een risico dan nog wil je je zaken en informatie niet op straat hebben.

[Tsurany]

unezra schreef op zaterdag 22 juni 2019 @ 16:19:

In mijn beleving, haal je die tussenlaag er tussenuit, ga je heel snel, heel erg nat.

Is het daarom bij jou zo'n puinhoop? Omdat je in je eentje alles moet doen en het niet aan kan?

Vind het zo apart dat jij in je eentje de IT doet maar vind dat een grote organisatie gelijk vijf man nodig heeft om jouw rol in te vullen... Dan moet het of gigantisch verkeerd gaan bij jou of je een enorme zelfoverschatting hebben.

[ Voor 28% gewijzigd door Tsurany op 24-06-2019 22:54 ]

[fonsoy]

Tsurany schreef op zaterdag 22 juni 2019 @ 10:51:
[...]

En daar gaat het dus elke keer weer mis. De verwachting met waterval kosten en scope te kunnen bepalen en vast te leggen waarna deze nooit meer zal wijzigen. Hoe vaak is dat nu echt gelukt?

Wat mij blijft verbazen is dat heel veel innoverende bedrijven van de laatste jaren hebben laten zien dat waterval simpelweg niet werkt. Waarom blijven sommigen daar dan zo krampachtig aan vast houden? En als ze dan Agile doen moet het wel Agile in een waterval jasje omdat het toch tot in detail gemanaged wordt.

Wat is er mis met de watervalaanpak? Het is gewoon een goed bruikbare methode die prima werkt voor als je scope vaststaat. En dat is eigenlijk verdacht vaak zo, maar zijn met name kleinere bedrijven niet altijd beducht voor kosten die gepaard gaan met bepaalde implementaties.

Als je je logistieke systeem wil veranderen heb je er weinig aan als het bepaalde kernfuncties niet heeft. Die kun je prima in een watervalaanpak ontwikkelen waarna je vervolgens iteratief (eventueel agile) extra's toevoegt.

[...]

En je denkt serieus dat dit een goede oplossing is? De key-users laten tekenen voor eisen zodat je ze er later mee om de oren kan slaan als het niet werkt zoals ze eigenlijk willen?

Zeker, want daar worden ze ook voor betaald. Omdat ze ook na het testen van de software aftekenen weet je dat de functionaliteit die gevraagd is aantoonbaar werkt. En omdat de eisen vastliggen heb je ook geen last van ongemerkte scopecreep. Natuurlijk weet je ook wel dat je van tevoren niet 100% weet wat je wil hebben, echter werkt dit vastleggen wel goed om te zorgen dat de scope niet onbeperkt toe kan nemen. Als bepaalde kerngebruikers enthousiast zijn loop je anders het risico om een complete kerstboom aan randfunctionaliteit te realiseren die niet waarde toevoegt aan het kernproces.

Bij de watervalaanpak heb je duidelijker in kaart vooraf waar je aan gaat beginnen. En kun je bijvoorbeeld samen gaan strepen in de eisenlijst. Dat is bij deze methode echt transparanter.

[...]

En dit is juist precies waarom je Agile wilt gaan ontwikkelen. Elke twee weken reviewen wat er gebouwd is zodat je tijdig bij kan sturen en aanpassingen door kan voeren. Rechtstreeks contact tussen de key users en het gehele ontwikkelteam, hoe simpel wil je het hebben?

Dat is voor veel grotere projecten enorm ingewikkeld. Je hebt daar namelijk elke kleine wijziging in documentatie en standaardprocedures nodig. Stel dat Albert Heijn de interface van de kassaschermen voor de caissieres elke twee weken verandert. Dat is natuurlijk een zotte gedachte Het personeel zou zich elke twee weken wezenloos zoeken.

Los van het inbakken van aanpassingen en kleine wijzigingen in trainingsdocumentatie.

Het grote probleem is dat een bepaalde ontwikkelmethode in 99% van de gevallen halfslachtig worden doorgevoerd onder druk van een klant die geen idee heeft wat zij wenst. Als gevolg daarvan krijgen figuren als projectmanagers en businessanalisten te pas en te onpas de zwarte piet toegespeeld.

[ Voor 3% gewijzigd door fonsoy op 24-06-2019 23:25 ]

[unezra]

Tsurany schreef op maandag 24 juni 2019 @ 22:39:
[...]
Is het daarom bij jou zo'n puinhoop? Omdat je in je eentje alles moet doen en het niet aan kan?

Ik weet niet waar je vandaan haalt dat het bij mij zo'n puinhoop zou zijn en/of dat ik het niet aan zou kunnen.

Vind het zo apart dat jij in je eentje de IT doet maar vind dat een grote organisatie gelijk vijf man nodig heeft om jouw rol in te vullen... Dan moet het of gigantisch verkeerd gaan bij jou of je een enorme zelfoverschatting hebben.

Sowieso doe ik de IT niet in mijn eentje maar met zijn 2en én werken we nauw samen met de nodige partners / leveranciers.

Volgens mij is er verder niet heel veel fantasie voor nodig waarom in een kleinere organisatie het wel kan (en moet, want er is niet genoeg werk en geld voor al die rollen apart) en in een grotere organisatie het niet werkt.

In een kleine organisatie is het coordinerend werk soms al een dagtaak. Ik ben op momenten 80%-100% bezig met niet-technisch-uitvoerende zaken. Dat kan, omdat ik én een collega heb die een belangrijk deel van de support en techniek doet én we nauw samenwerken met technische leveranciers. (Die dan wel weer moeten worden aangestuurd.)

In een grotere organisatie zijn de belangen diverser. Hoe zie jij het voor je dat een hand vol technische disciplines, een hand vol niet-technische ICT gerelateerde disciplines, een paar handen vol afdelingen, managers, finance, etc, etc, etc, met elkaar zinvol en efficiënt tot een werkende, gezamelijk te gebruiken oplossing komen zonder dat daar iemand de rol van coordinator op zich neemt?

Hoe zie jij het voor je dat in een grotere organisatie, de technisch uitvoerend specialist (beheerders, programmeurs), alle ins en outs weten van bijvoorbeeld de juridische kant van dataveiligheid?

Hoe veel technisch specialisten ken jij die al die randzaken ook echt *leuk* vinden? (En dus de wil hebben daar goed in te worden?)

Heb je in iedere organisatie 5 man nodig? Nee. Kan het nooit gecombineerd worden? Natuurlijk wel.
Maar ik vind het vrij logisch dat hoe groter de organisatie, hoe groter de specialisatismen, hoe ingewikkelder het raderwerk, de politiek, de afstemming en dus hoe belangrijker het is mensen te hebben die de vertaalslagen maken.

EDIT:
Voor de goede orde, mijn beweringen en meningen (hier en op Tweakers en andere media in het algemeen) zijn gebaseerd op ruim 20 jaar ICT ervaring, in bedrijven van 5 tot >60.000 medewerkers, in binnen- als buitenland.

Wat ik vertel is dus niet gebaseerd op enkel een paar jaar systeembeheer ervaring, zoals soms gesuggereerd word. Mijn kennis en ervaring is veel breder dan dat. Kwestie van goed je ogen open houden, praten met mensen uit allerlei disciplines, etc.

[ Voor 9% gewijzigd door unezra op 25-06-2019 10:03 ]

[ZieMaar!]

LucyLG schreef op maandag 24 juni 2019 @ 22:24:
Onder de dienstverleners zoals accountants, juristen, notarissen en trustkantoren is er een enorm gat met de IT. Ik ben zelf jurist en leer hier een hoop, maar kan denk ik wel iets erover zeggen.

Hier is de veiligheid van bestanden een puntje van aandacht. De dropbox etc is niet geblokkeerd maar denk dat alle clouds blokkeren lastig wordt. Je kan weliswaar alleen via een app in de kantoorruimte komen, dus inloggen met een token, maar om die reden kopieert iedereen zn privemail in om zo makkelijk stukken te kunnen lezen als je in de trein zit.

Ze werken met USB sticks althans die kunnen in de computer. En ga nog maar door aan issues die niet worden opgemerkt. Emailen van bestanden met 30 mensen in de CC. Ik denk dat dat een risico is. ookal is de client een risico dan nog wil je je zaken en informatie niet op straat hebben.

Dat is wel een goede toevoeging. Ik ken vooral de corporate wereld, van beide kanten, en daar gaat het echt steeds beter. Ik kan me voorstellen dat het bij kleine(re) bedrijven, waar IT meer gereedschap is (laptops, fileserver, mailboxen) anders werkt.

In kleine bedrijven lijkt het gat misschien kleiner, maar is de IT misschien ook vaak minder volwassen?

[Heroic_Nonsense]

Ik moet het even zo goed mogelijk anonimiseren, maar hier een real life scenario waar mijn team vorig jaar tegenaan liep:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 4% gewijzigd door Heroic_Nonsense op 25-06-2019 09:54 ]

[unezra]

ZieMaar! schreef op dinsdag 25 juni 2019 @ 07:35:
[...]
Dat is wel een goede toevoeging. Ik ken vooral de corporate wereld, van beide kanten, en daar gaat het echt steeds beter. Ik kan me voorstellen dat het bij kleine(re) bedrijven, waar IT meer gereedschap is (laptops, fileserver, mailboxen) anders werkt.

In kleine bedrijven lijkt het gat misschien kleiner, maar is de IT misschien ook vaak minder volwassen?

Helaas vaak wel en dat vind ik geen positief iets.

Ik ben hier (~40 FTE, 2 ICTers) ook al jaren (6,5) aan het vechten om de ICT steeds professioneler te krijgen. Met succes. Het is zeker nog niet perfect, maar als ik kijk naar concullega's en bedrijven waarmee we samen werken, doen we het niet slecht.

Sterker nog, op sommige vlakken lijken we zaken beter voor elkaar te hebben dan organisaties die (veel) groter zijn. Op andere vlakken niet. Mijn budgetten zijn allesbehalve onbeperkt en dat zie je op punten écht terug.

Probleem bij veel kleinere bedrijven is in mijn beleving dat de business amper verstand heeft van ICT (wat een goed ding is), waardoor prutsoplossingen een kans krijgen of zelfs geforceerd worden. Ook hier. Ik moet soms leven met oplossingen waar ik niet achter kan staan, omdat ik een goede, professionele oplossing niet altijd verkocht krijg. (Soms wegens volkomen valide redenen.)

In kleine bedrijven is de afstand tussen alle onderdelen kleiner. In grote bedrijven is de afstand tussen alle onderdelen groter. Dat gaat niet specifiek om ICT en ik zie dat niet altijd als een groot probleem. De afstand tussen de technische uitvoering of leveranciers en business mag best groot zijn, zolang de belangen van beiden maar behartigd worden en er afdoende communicatie en afstemming is. Dat die communicatie en afstemming loopt via een of meerdere tussenlagen zie ik niet als een probleem.

[ Voor 3% gewijzigd door unezra op 25-06-2019 10:21 ]

[Hydra]

fonsoy schreef op maandag 24 juni 2019 @ 23:24:
[...]

Wat is er mis met de watervalaanpak? Het is gewoon een goed bruikbare methode die prima werkt voor als je scope vaststaat.

Yup. Waterval werkt prima als vooraf je scope vaststaat. Dit is waarom het in de echte wereld dus nooit werkt.

Zelfs als je het voor elkaar zou krijgen dat de specs 100% duidelijk zijn op het moment dat je begint, dan nog zijn niet triviale systemen te complex om alles te overzien, en is er ook nog het simpele feit dat met de tijd de markt verandert. Je software moet dus mee veranderen.

Waterval is overigens destijds door Royce gepresenteerd als een niet-proces dat per definitie niet werkt. Ik vind het altijd erg koddig als mensen dan gaan verkondigen dat waterval, nota bene de illustratie van wat niet werkt, prima werkt voor hun organisatie.

De meeste organisatie die waterval claimen te doen, doen over 't algemeen een soort half-slachtig agile. Een paar architecten bedenken alles vooraf wat vervolgens door de developers volkomen genegeerd wordt omdat die gewoon geacht worden hun werk te doen, zo goed als kwaad dat 't kan. Maar door deze disconnect is er te weinig onderlinge afstemming waardoor het een teringzooi wordt. Dit is je standaard "waterval". Of zoals je het noemt; een "hybride".

fonsoy schreef op maandag 24 juni 2019 @ 23:24:
Dat is voor veel grotere projecten enorm ingewikkeld. Je hebt daar namelijk elke kleine wijziging in documentatie en standaardprocedures nodig. Stel dat Albert Heijn de interface van de kassaschermen voor de caissieres elke twee weken verandert. Dat is natuurlijk een zotte gedachte Het personeel zou zich elke twee weken wezenloos zoeken.

Sorry hoor maar ik heb vrijwel m'n hele carriere aan dat soort grote systemen gewerkt. En juist daar is agile, omdat je geen overzicht over alles hebt, zo belangrijk. Agile is niks anders dan een proces waarin verandering ingebakken is, in plaats van dat er weerstand geboden wordt.

Nota bene dat kassasysteem van Albert Heijn wordt gewoon agile gebouwd. Al heel erg lang. Agile betekent niet dat alles ook altijd verandert.

[ Voor 82% gewijzigd door Hydra op 26-06-2019 11:27 ]

[Hankie0412]

LucyLG schreef op maandag 24 juni 2019 @ 22:24:


Hier is de veiligheid van bestanden een puntje van aandacht. De dropbox etc is niet geblokkeerd maar denk dat alle clouds blokkeren lastig wordt. Je kan weliswaar alleen via een app in de kantoorruimte komen, dus inloggen met een token, maar om die reden kopieert iedereen zn privemail in om zo makkelijk stukken te kunnen lezen als je in de trein zit.

Ze werken met USB sticks althans die kunnen in de computer. En ga nog maar door aan issues die niet worden opgemerkt. Emailen van bestanden met 30 mensen in de CC. Ik denk dat dat een risico is. ookal is de client een risico dan nog wil je je zaken en informatie niet op straat hebben.

Daarom de data beveiligen en niet het transportmiddel, hierop wel eventueel een blokkade plaatsen uiteraard. Een goed voorbeeld is Azure Information Protection, hiermee bescherm je de data waar deze ook leeft. Dit kan prima in een Dropbox zijn of een USB en is in Rest en in Motion beveiligd.

Hydra schreef op woensdag 26 juni 2019 @ 11:14:
[...]


De meeste organisatie die waterval claimen te doen, doen over 't algemeen een soort half-slachtig agile. Een paar architecten bedenken alles vooraf wat vervolgens door de developers volkomen genegeerd wordt omdat die gewoon geacht worden hun werk te doen, zo goed als kwaad dat 't kan. Maar door deze disconnect is er te weinig onderlinge afstemming waardoor het een teringzooi wordt. Dit is je standaard "waterval". Of zoals je het noemt; een "hybride".


[...]


Sorry hoor maar ik heb vrijwel m'n hele carriere aan dat soort grote systemen gewerkt. En juist daar is agile, omdat je geen overzicht over alles hebt, zo belangrijk. Agile is niks anders dan een proces waarin verandering ingebakken is, in plaats van dat er weerstand geboden wordt.

Nota bene dat kassasysteem van Albert Heijn wordt gewoon agile gebouwd. Al heel erg lang. Agile betekent niet dat alles ook altijd verandert.

Voor grote maatwerk systemen akkoord voor Agile, voor veel van mijn projecten is dit echt overkill en niet echt werkbaar. Hiervoor kies ik vaak voor een hybride, vooraf zo goed mogelijk bepalen (waterval max 6 weken) en kort cyclisch opleveren (Agile achtig). Als je hierbij kort op de business zit en die goed bij het project betrekt kom je weinig in problemen.

Een ander punt hiervoor is ook dat het vaak ontbreekt aan goede visie en strategie waardoor de business weinig houvast heeft op het eindresultaat. Dit is een rol voor een business analist om het eindresultaat te kunnen schetsen. Ik ben zelf meer van de business consultant om te redeneren uit een bepaalde techniek (bijvoorbeeld opgelegd in de visie/strategie) en hier de business in te begeleiden om de techniek zo goed mogelijk op de processen en de wensen aan te laten sluiten.

[Hydra]

Hankie0412 schreef op woensdag 26 juni 2019 @ 11:45:
Voor grote maatwerk systemen akkoord voor Agile, voor veel van mijn projecten is dit echt overkill en niet echt werkbaar. Hiervoor kies ik vaak voor een hybride, vooraf zo goed mogelijk bepalen (waterval max 6 weken) en kort cyclisch opleveren (Agile achtig). Als je hierbij kort op de business zit en die goed bij het project betrekt kom je weinig in problemen.

Wat voor'n werk doe jij?

[Hankie0412]

Hydra schreef op woensdag 26 juni 2019 @ 12:57:
[...]


Wat voor'n werk doe jij?

O365 consulting, dus volledig anders dan ontwikkeltrajecten.

[Heroic_Nonsense]

Hankie0412 schreef op woensdag 26 juni 2019 @ 11:45:
[...]
Voor grote maatwerk systemen akkoord voor Agile, voor veel van mijn projecten is dit echt overkill en niet echt werkbaar. Hiervoor kies ik vaak voor een hybride, vooraf zo goed mogelijk bepalen (waterval max 6 weken) en kort cyclisch opleveren (Agile achtig). Als je hierbij kort op de business zit en die goed bij het project betrekt kom je weinig in problemen.

"Agile" is ook een relatief vloeibare term; als je waterval"increments" van 6 weken hebt, dan is dat al redelijk "agile". Zo'n 10 jaar geleden werkte mijn werkgever nog volledig "waterval", waarbij projecten soms alleen al 6 weken in het FO-stadium bevonden (er was nog niks technisch uitgewerkt), een week of drie in TO-fase en daarna nog een week of vier aan DEV-tijd kregen. Zaken werden vervolgens gebundeld en als kwartaalrelease naar productie gebracht, waardoor een change soms wel maanden op de acceptatieomgeving stond voordat het in zo'n release naar productie werd gebracht (als je het venster mistte).

Vergeet niet dat SCRUM ook maar een methode op een bierviltje is om "omgangsvormen" tussen business en IT te stroomlijnen en niet zozeer te bepalen hoe je met zaken als ontwerp en documentatie om moet gaan. Dat is er later door allemaal zichzelf-heel-belangrijk-vindende mensen bij verzonnen.

Wij werken hybride DEV-OPS-met-een-sausje-SCRUM: documentatie is daardoor bij sommige teams een ondergeschoven kindje, maar we hebben gelukkig geen releasevensters meer.

Een ander punt hiervoor is ook dat het vaak ontbreekt aan goede visie en strategie waardoor de business weinig houvast heeft op het eindresultaat. Dit is een rol voor een business analist om het eindresultaat te kunnen schetsen. Ik ben zelf meer van de business consultant om te redeneren uit een bepaalde techniek (bijvoorbeeld opgelegd in de visie/strategie) en hier de business in te begeleiden om de techniek zo goed mogelijk op de processen en de wensen aan te laten sluiten.

De BA's hebben bij ons vaak een veel te complexe of juist veel te simpele kijk op zaken. Men gaat ook op de stoel van de DEV zitten door eerst handjeklap te doen met een architect en dan pas naar de uitvoerende teams te stappen (zie ook mijn vorige post). Het gevolg is dat je soms onwerkbare ideeën krijgt (zie wederom mijn vorige post)en soms een enorme omweg om tot het gewenste resultaat te komen.

[Hydra]

Hankie0412 schreef op woensdag 26 juni 2019 @ 13:36:
O365 consulting, dus volledig anders dan ontwikkeltrajecten.

Ja, dat verklaart veel inderdaad. Het kortste project wat ik de afgelopen 6 jaar ofzo gedaan heb was 3 maanden. Ik redeneer vooral vanuit dat wereldje

[Hankie0412]

Heroic_Nonsense schreef op woensdag 26 juni 2019 @ 13:39:


De BA's hebben bij ons vaak een veel te complexe of juist veel te simpele kijk op zaken. Men gaat ook op de stoel van de DEV zitten door eerst handjeklap te doen met een architect en dan pas naar de uitvoerende teams te stappen (zie ook mijn vorige post). Het gevolg is dat je soms onwerkbare ideeën krijgt (zie wederom mijn vorige post)en soms een enorme omweg om tot het gewenste resultaat te komen.

Daarom ben ik van mening dat een goede BA of BC een goede portie technische en functionele kennis heeft om de wensen om te kunnen zetten in reële functionele eisen. Helaas zijn er daar veel te weinig van, het is bijna een sales functie. Wat wil je hebben? Dat kunnen wij en kost zoveel.

[unezra]

Hankie0412 schreef op woensdag 26 juni 2019 @ 13:51:
[...]
Daarom ben ik van mening dat een goede BA of BC een goede portie technische en functionele kennis heeft om de wensen om te kunnen zetten in reële functionele eisen. Helaas zijn er daar veel te weinig van, het is bijna een sales functie. Wat wil je hebben? Dat kunnen wij en kost zoveel.

Misschien dat daar de weerstand tegen BA's en BC's voor een deel ook wel vandaan komt.

Aan de andere kant wil je ook niet dat zo iemand té veel van de techniek weet, of zaken niet kan versimplificeren. Wat ik merk is dat veel techneuten (inclusief ikzelf) snel verdwalen in allerlei technische details, mogelijkheden en onmogelijkheden.

Wat je wil is een abstrahering van zaken. Je moet eerst beginnen met bedenken of je wel een vervoermiddel nodig hebt en zo ja, wat voor eisen dat vervoermiddel aan moet voldoen voordat je gaat bedenken over of dit een vliegtuig moet zijn of een vrachtwagen, hoe veel wielen die vrachtwagen moet hebben, hoe veel Pk de motor nodig heeft en wat zijn TCO mag zijn.

Wat in mijn beleving vaak mis gaat, is dat aan een technisch specialist op een bepaald vakgebied word gevraagd wat de oplossing moet zijn. Vraag je aan een vrachtwagenmonteur wat voor vervoermiddel je nodig hebt, is de kans groot dat 'ie je een vrachtwagen aan gaat raden en geen vliegtuig, laat staan dat het antwoord is dat je helemaal geen vervoermiddel nodig hebt omdat het slimmer is je productie te laten plaats vinden op de plaats waar je grondstof gewonnen word.

In mijn beleving zitten op die positie BA's, BC's, etc, die helpen met het zorgen voor het juiste eindresultaat. Uiteindelijk is dát wat telt. Niet een eventuele afstand van IT tot business. (Al denk ik dat de juiste tussenlaag, de afstand verkleint. Een tolk verkleint ook de afstand tussen 2 mensen die ieder een eigen taal spreken en elkaar zonder tolk niet verstaan.)

[merauder]

In mijn visie dient IT een onderdeel van de Business te zijn, en zijn alle lagen die proberen deze kloof te overbruggen, of dit nu een consultant, analyst, manager, product-owner of scrum-master is, gedoemt om te falen. IT is voor veel bedrijven inmiddels een belangrijke ruggengraat geworden, die ze in plaats van integreren of omarmen in de bedrijfsvoering juist op afstand houden door een 'vertaalslag tussen business en IT' te introduceren.

Uiteindelijk hebben we het ook niet over 'verkoop' en 'De Business', 'boekhouding' en 'De Business' of 'facilitair' en 'De Business'. Een veelgehoord argument zou dan kunnen zijn dat 'IT' weer heel erg complex is, maar in bepaalde sectoren is een primair proces of een facilitaire afdeling technisch minstens zo complex. zoals in het geval van aviation.