Archief - Dolmen
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Cycloon
Legacy Member
Ark'ay zei:
Er zijn genoeg analisten die geen IT-achtergrond hebben. Om wat functionele eisen en/of business processen op papier te zetten heb je dat eigenlijk ook niet nodig. Of je makkelijk binnenraakt is weer iets anders, je zal toch wel wat interesse in het vak moeten hebben.
Mooncat
Legacy Member
Cycloon zei:
Voor een business analyst is geen IT-achtergrond vereist, hoewel het handig is als je daarover beschikt. Hier is domeinkennis erg belangrijk en zonder dat ga je geen business analyst worden. Een functioneel analyst vertolkt juist de brugfunctie tussen het technische aspect en de business van een project, dus moet je zeker en vast over een zekere technische bagage beschikken.
Met een diploma taal- en letterkunde analyst worden is niet evident. Voor business analysten kiezen ze meestal iemand met een economisch getint diploma als die over weinig ervaring beschikt. Voor functioneel analyst vragen de meeste bedrijven een IT-opleiding (als hoofdopleiding of als postgraduaat). Ik weet dat KBC universitairen (zonder IT-opleiding) opleidt tot IT'ers, maar ik denk dat ze daarmee uniek zijn in België.
Cycloon
Legacy Member
Waarom is er technische kennis vereist om een functionele analyse op te stellen? Functionele analyse is niet meer dan naar de gebruiker te gaan luisteren en te bekijken welke eisen ze stellen aan software. Buiten het feit dat je best wel wat ervaring hebt met veel software om mee te denken met de gebruiker heb je daar 0,0 technische IT-kennis voor nodig.
Emerxill
Legacy Member
De beste business analist waarmee ik ooit samen heb gewerkt was ne theoloog van opleiding. Opleiding zegt niet wat ge niet kunt.
Daarnaast krijg ik het vliegend sch**t van analisten die mij komen vertellen hoe ik iets technisch moet oplossen.
Domeinkennis is idd het belangrijkste voor een BA, maar domeinkennis heeft niks met technologie te maken. Daar dienen technische analisten/developers voor.
Daarnaast krijg ik het vliegend sch**t van analisten die mij komen vertellen hoe ik iets technisch moet oplossen.
Domeinkennis is idd het belangrijkste voor een BA, maar domeinkennis heeft niks met technologie te maken. Daar dienen technische analisten/developers voor.
Mooncat
Legacy Member
Cycloon zei:
Dat is een business analyst.
Een fuctioneel analyst moet de business requirements vertalen naar de techniek waarmee wordt gewerkt. Die beschrijft in UML hoe de systemen met elkaar functioneren, uit welke databases gegevens moeten gehaald worden, pseudocode voor bepaalde algoritmen, enzovoort. Functioneel analysten zijn trouwens dikwijls programmeurs met een aantal jaar ervaring die de systemen goed kennen. Dat zorgt voor een paradox, want daardoor haal je veel ervaring en kennis weg bij de programmeurs, maar dat is een andere kwestie.
Mooncat
Legacy Member
Emerxill zei:
Van een business analyst mag toch verwacht worden dat die tenminste een minimale kennis van technologie heeft (al is het zeker niet verplicht). Dat heeft een groot voordeel in die functie omdat die dan meteen weet of een requirement technisch haalbaar is of niet en daar wordt veel, heel veel tijd aan verloren.
Cycloon
Legacy Member
Mooncat zei:
Functionele analyse - Wikipedia
Requirements analysis - Wikipedia, the free encyclopedia
Informatieanalist - Wikipedia
Een businessanalist beschrijft businessprocessen. Een functioneel analist gaat in op specifieke vragen van gebruikers/klanten. Waar jij het over hebt is een technisch analist, dat is al heel wat anders.
Mooncat zei:
Een businessanalist houdt zich technisch gezien niet bezig met requirements. De businessanalyse bestaat eruit om het grote geheel van processen in een bedrijf te beschrijven en te optimaliseren. Een businessanalist kan daarbij "een klant" worden van een functioneel analist wanneer bepaalde processen beter op een andere manier kunnen worden gestructureerd.
Mooncat
Legacy Member
Ik heb geen goesting om over de semantiek te gaan zagen, maar kort gezegd: business analyst houdt zich bezig met de requirements (opstellen, in kaart brengen, achterhalen, schrijven) en behartigt de belangen van de eindgebruiker. Functioneel analyst zit bij de IT en zet de requirements om in een functionele analyse die wordt gebruikt door programmeurs om te coderen. Technische analyse (en bijhorende functionalist) kan ertussen zitten, afhankelijk van de werkomgeving. Komt niet van Wikipedia, maar da's gewoon mijn praktijkervaring.
Deze brave mens zegt wat ik bedoel.
Deze brave mens zegt wat ik bedoel.
Oldskooler
Legacy Member
Iedereen kan wel tekst in een document kloppen en zeggen wat er gebeuren.
Daar komt het vaak op neer.
Pech voor diegene die het uiteindelijk moet maken, als er half gebrabbel in staat.
Of een ze-moeten-het-maar-komen-vragen-analyse van 10 woorden.
Ergerlijk als ze hun eigen werk niet eens een 2de keer doorlopen om de blunders er uit te halen.
Het ergst van al zijn dan pipo's die zich self-made voelen, en zich een echte IT'er wanen.
Programmeren is dan niet meer dan 'wat schermkes maken'.
Een blik van 'moete daar dan zo lang voor naar't school geweest zijn'.
Als er een schone hiërarchie van boven naar onder is, is er geen probleem.
Maar ergens een kink en de onderste lagen voelen het.
En begrip is er dan niet. Zeker als de functionelen zelf geen technische achtergrond hebben, wat heel vaak zo is, of verouderde kennis.
Idd, vaak is dat tussenlaagje er niet.
Daarom is technische kennis bij analysten een stiekeme must.
Anders wordt alles onderschat, worden er onhaalbare beloftes gemaakt en durft de analyst de klant niet meer onder ogen zien. Nadien is het de programmeur zijn schuld.
Owéé als ze u dan 1 keer op het internet bezig gezien hebben, dan hebben ze een excuus waarom het niet werd gehaald.
En al is men 100 keren tegen de lamp gelopen, toch blijft men alles onderschatten.
Daar komt het vaak op neer.
Pech voor diegene die het uiteindelijk moet maken, als er half gebrabbel in staat.
Of een ze-moeten-het-maar-komen-vragen-analyse van 10 woorden.
Ergerlijk als ze hun eigen werk niet eens een 2de keer doorlopen om de blunders er uit te halen.
Het ergst van al zijn dan pipo's die zich self-made voelen, en zich een echte IT'er wanen.
Programmeren is dan niet meer dan 'wat schermkes maken'.
Een blik van 'moete daar dan zo lang voor naar't school geweest zijn'.
Als er een schone hiërarchie van boven naar onder is, is er geen probleem.
Maar ergens een kink en de onderste lagen voelen het.
En begrip is er dan niet. Zeker als de functionelen zelf geen technische achtergrond hebben, wat heel vaak zo is, of verouderde kennis.
Mooncat zei:
Idd, vaak is dat tussenlaagje er niet.
Daarom is technische kennis bij analysten een stiekeme must.
Anders wordt alles onderschat, worden er onhaalbare beloftes gemaakt en durft de analyst de klant niet meer onder ogen zien. Nadien is het de programmeur zijn schuld.
Owéé als ze u dan 1 keer op het internet bezig gezien hebben, dan hebben ze een excuus waarom het niet werd gehaald.
En al is men 100 keren tegen de lamp gelopen, toch blijft men alles onderschatten.
Tomba
Legacy Member
Cycloon zei:
Omdat bij de functionele analyse vaak een kostenraming hoort die de klant te zien krijgt. En iemand die geen enkele technische kennis bezit, zal zelden in staat zijn om correct in te schatten hoe lang iets duurt.
Om nog maar te zwijgen over analisten die de klanten alelrlei onmogelijke zaken beloven want "dat kan toch zo moeilijk niet zijn".
Een analist die enkel maar een schema opmaakt van wat de klant wil, en het daarna nog aan iemand verderschuift die wel enige technische kennis heeft voor een raming, heeft uiteraard niet echt technische kennis nodig. Maar zo'n mensen zijn over het algemeen ook volstrekt nutteloos en overbetaald.
Cycloon
Legacy Member
Mooncat zei:
Semantiek is oh zo belangrijk wanneer je een discussie wil voeren, anders praat je naast elkaar. Wat jij denkt dat een businessanalist is de rol van een functioneel analist. En wat jij denkt dat een functioneel analist is, is een technische analist. Het is vaak zelf triestig om te zien dat men in vacatures niet kan duidelijk maken wat men wenst, net omdat niemand zich de moeite neemt om duidelijk onderscheid te maken tussen de rollen.
En kijk naar de link die je gegeven hebt. Ze zoeken bij telenet functionele analisten die een achtergrond hebben in de facturatie. Ik vermoed niet dat die personen zoveel technische IT kennis hebben. Waarom mensen met achtergrond in facturatie? Omdat een groot deel van de software bij Telenet wel rond facturatie zal draaien. Dan is het handig dat de functioneel analist daar in thuis is. De technische analyse zal toch door iemand anders gebeuren.
Tomba zei:
't Lijkt mij erg straf dat een functioneel analist beslissingen mag nemen (laat staan dat die beloften mag maken aan een klant). Zo'n dingen worden eerst nog besproken met de it-manager, projectleiders, de technische analisten, soms zelf nog de programmeurs. Hell, een functioneel analist die een kostenraming maakt...
Mooncat
Legacy Member
Cycloon zei:
Met semantiek bedoel ik vooral de omschrijving voor technische, functionele, end to end analyst. Ik heb ze in de praktijk allemaal zien passeren voor dezelfde rol. Daarom dat ik een onderscheid maak tussen een business analyst die aan de kant van business werkt en functioneel/technisch/E2E analyst die aan de kant van IT zit. En waarom zouden vacatures niet kloppen?
Op 1.2 vind je een beschrijving van wat business analyse is. IIAB is een overkoepelende organisatie van business analyst en de business analysis body of knowledge (BABOK) wordt gebruikt als bijbel om alles wat met business analyse te maken heeft te beschrijven (en wat je moet kennen voor certificatie).
Cycloon zei:
En waarom vermoed jij dat die personen niet zoveel technische IT-kennis nodig hebben? Hij zegt zelf wat hij doet: "Als functioneel analist zit ik tussen de it'ers en de werknemers die zich bezighouden met de zakelijke kant. Het is mijn taak om de wensen van onze businessmensen te vertalen naar duidelijke instructies voor de technische organisatie."
Als je een paar jaar werkzaam bent in de IT-wereld zie je duidelijk wat het verschil is tussen de twee rollen.
Tomba
Legacy Member
Cycloon zei:
Standaard praktijk hier, en waarschijnlijk nog wel op meer plaatsen ook. Sommige functionele analisten hebben geen enkele technische kennis en komen toch met ramingen af. Het is zelfs al gebeurd dat verkopers gewoon de vraag van de klant op papier gezet hebben en er ineens ook al een prijs op geplakt hebben... Zeker in consulting kan ik me wel inbeelden dat een klant er geen behoefte aan heeft dat zijn vraag door tig mensen behandeld moet worden op zijn kosten...
In grote bureaucratische bedrijven waar ontwikkeling intern gebeurt zal het natuurlijk wel anders werken, kwestie van al dat middle management werk te geven
dobe&daze
Legacy Member
Mooncat zei:
ahum daarom dat ik nog nooit iemand tgngekomen ben die BABOK certified is, laat staan IIBA certified, meestal worden proprietary company methodologieën gebruikt. Die BOKs zijn gewoon een samenraapsel van wat er op de markt beschikbaar is, denk niet dat er veel bedrijven aandacht besteden om daarin compliant te zijn.
Mooncat
Legacy Member
dobe&daze zei:
De kans dat je iemand die gecertificeerd is in CCBA of CBAP is inderdaad heel erg gering. Ten eerste omdat het nog vrij onbekend is in deze contreien en ten tweede omdat de vereisten voor zo'n certificaat (zeker voor CBAP) hoog liggen. BABOK staat voor business analysis body of knowledge, een verzameling van best practices voor business analyse. Net zoals je PMBOK hebt voor project management en ISTQB voor software testing. Dat die dingen niet volledig door bedrijven worden gebruikt, lijkt me logisch, daar zijn ze immers ook niet voor bedoeld. Dat ze daar sommige dingen wel uithalen is ook logisch, aangezien het generiek is. Ik weet niet over welke proprietary company methodologieën je het hebt, dus mij lijkt het heel erg interessant als je eens kan vertellen welke methodologieën er dan wel gebruikt worden voor business analyse.
dobe&daze
Legacy Member
Mooncat zei:
Daar zit net het verschil voor PM heb je Prince2, MSP of PMI, niemand (of zeer weinig) zal gebruik maken van PMBOK als reference. ISTQB wordt het certificaat als requirement opgelegd door de klant, niet het geval voor BA.
K ga niet alle company methodologieën gebruiken, bij CSC gebruiken ze catalyst bv (Catalyst is a set of repeatable processes and techniques for analyzing a business situation and developing and implementing the best solution.).
Als je als experience hire ergens aan de slag gaat wordt je sowieso via paar dagen durende training ondergedompeld in hun specifieke metholodogie.
BABOK...schoon document maar de added value lijkt me zoek.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.