Miért kerül többe egy hiányzó üzleti elemző, mint a jelenléte?

Miért kerül többe egy hiányzó üzleti elemző (BA), mint a jelenléte? Egy mondatban: mert az újrafejlesztés mindig drágább, mint az első, jól megértett fejlesztés. Ez a cikk kutatási adatokkal, egy átlátható számítással és valós projektpéldákkal mutatja meg, mikor térül meg egy BA, mikor nincs rá szükség, és mit változtat ezen az AI.

Röviden

• A PMI felmérése szerint a sikertelen projektek 47 százaléka a pontatlan követelménykezelés miatt nem éri el a céljait.
• Az IAG Consulting kutatásában a gyenge követelménykezelésű cégek akár 60 százalékos idő- és költségtöbbletet fizettek a projektjeikért.
• Egy 4 fős senior fejlesztőcsapat mellett már 20 százalék újrafejlesztés annyiba kerül, mint egy senior BA hat hónapra.
• A nagyobb veszteség nem is a költség: a McKinsey adatai szerint a nagy IT-projektek 56 százalékkal kevesebb értéket hoznak a vártnál.
• A BA nem dokumentumgyártó, hanem az üzleti igény gazdája a projekt teljes életciklusában, agilis környezetben is.
• Az AI gyorsítja a BA munkáját, de nem helyettesíti azt, aki tudja, mit kell megkérdezni.

Egy tipikus helyzet

A projekt elindul. Van határidő, van fejlesztőcsapat, van lelkesedés. Az üzleti igény „nagyjából” tiszta, a részleteket majd menet közben rendezik. Az üzleti elemző bevonása felmerül, de drágának tűnik, és „most nincs idő a toborzásra”.

Három hónappal később a fejlesztés 60 százaléknál tart. Az üzleti terület ekkor adja az első komoly visszajelzést: „ez nem egészen az, amit mi a követelmény alatt értettünk”. Néhány funkciót újra kell tervezni. A határidő csúszik, a keret fogy, a hangulat romlik.

Ez nem kivétel, hanem az egyik leggyakoribb forgatókönyv.

Mit mondanak a kutatások?

A követelménykezelés hatását több nemzetközi kutatás is vizsgálta, és az eredmények egy irányba mutatnak.

• PMI, Pulse of the Profession (2014): a sikertelen projektek 47 százaléka a pontatlan követelménykezelés miatt nem éri el a céljait.
• IAG Consulting, Business Analysis Benchmark (2008): több mint 100 cég, átlagosan 3 millió dolláros projektjeit elemezték. A gyenge követelménykezelésű cégek akár 60 százalékos idő- és költségtöbbletet fizettek, és az IT fejlesztési keretük több mint 41 százaléka ment el a rossz követelményekre a legjobb gyakorlatot követő cégekhez képest. A cégek 68 százaléka a „valószínűtlen siker” kategóriába került.
• Boehm és Basili (IEEE Computer, 2001): a szoftverprojektek erőfeszítésük nagyjából 40-50 százalékát elkerülhető újrafejlesztésre fordítják, és egy hiba kijavítása átadás után gyakran nagyságrendekkel drágább, mint a követelmény- vagy tervezési fázisban.
• McKinsey és Oxfordi Egyetem (2012): több mint 5400 IT-projekt adatai alapján a 15 millió dollár feletti nagy projektek átlagosan 45 százalékkal lépik túl a költségvetést, és 56 százalékkal kevesebb értéket hoznak a vártnál. A költségtúllépések mintegy feléért a stratégia és az érintettek kezelésének, valamint a tartalom és a technológia uralásának hiánya felel.

Ezek nem friss adatok, és nem magyar projektekre vonatkoznak. A mintázat viszont ma is ugyanaz, és a saját projektjeinkben is ezt látjuk: a hibák jelentős része nem a kódban, hanem a meg nem értett vagy meg nem kérdezett igényben keletkezik.

Nem csak a költség: az elmaradt érték

A hiányzó BA-ról szóló viták többnyire a költségtúllépésről szólnak, pedig a McKinsey adatai szerint a nagyobb veszteség máshol van: a projektek a vártnál jóval kevesebb értéket hoznak. Egy rendszer lehet határidőre kész és kereten belül, mégis kudarc, ha nem azt a problémát oldja meg, amiért elindult. Ilyenkor a felhasználók megkerülő megoldásokat találnak ki, Excel-táblák születnek a rendszer mellett, és fél év múlva indul a „2. fázis”, ami valójában az első helyes változat.

Az üzleti elemző egyik legfontosabb kérdése ezért nem az, hogy „mit kér az üzlet?”, hanem az, hogy „milyen problémát akarunk megoldani, és honnan fogjuk tudni, hogy sikerült?”. Ha erre nincs mérhető válasz a projekt elején, a végén sem lesz.

A számok: mennyibe kerül a hiányzó BA?

Számoljunk konkrétan, átlátható feltételezésekkel. A Bluebird 2026-os, valós toborzási adatokon alapuló budapesti IT-fizetési összesítője szerint egy senior üzleti elemző bruttó havi bére 1,5-1,8 millió forint, egy senior Java fejlesztőé 1,6-2,2 millió forint.

Ha a csapat kapacitásának mindössze 20 százaléka megy el arra, hogy félreértett vagy hiányos igény miatt kész funkciókat kell átírni, az már annyiba kerül, mint egy senior BA fél évre. A kutatások ennél nagyobb arányokról szólnak. A táblázat ráadásul csak a bérköltséget mutatja: nem tartalmazza a munkáltatói járulékokat, a csúszás üzleti költségét, és azt sem, hogy a késve élesedő rendszer addig nem termel értéket.

Külső, T&M konstrukcióban a díjak magasabbak, mert a szolgáltató költségeit is tartalmazzák. Ez viszont a fejlesztőkre ugyanúgy igaz, így az arány lényegében nem változik.

A BA költsége egy sor a projektköltségvetésben. A hiányának ára szétterül a fejlesztési körökben, a csúszásban és a tesztelésben, ezért ritkán látja valaki egyben.

Miért nem vonják be mégis?

Három okot látunk rendszeresen.

1. A BA költsége látható, a hiányának ára nem

Amikor projekttervezéskor eldől, hogy nem kell BA, senki nem számolja ki, mennyibe fog ez kerülni. A scope creep fokozatosan, szinte észrevétlenül jelenik meg (erről bővebben: scope creep kezelése agilis projektekben). A plusz fejlesztési köröket a „lassú fejlesztők” vagy a „változó üzleti igény” számlájára írják, nem a hiányzó BA-éra.

2. A BA-t dokumentumgyártónak tekintik

Ha a BA szerepe annyi, hogy megírja a specifikációt és átadja a fejlesztőknek, akkor valóban kérdéses az értéke. Csakhogy ez nem a BA szerepe, hanem a rosszul végzett BA-munka. A jó BA az üzleti igény gazdája a projekt teljes életciklusa alatt, nem egyszeri dokumentum szállítója. Ha a specifikációt senki nem olvassa el, az is jelzés (lásd: 5 jel, hogy a követelményspecifikációdat senki nem olvasta el).

3. „Majd a fejlesztők megkérdezik az üzletet”

Ez a legtöbb projekten nem működik, mert a fejlesztők nem tudják, mit kell megkérdezni. Azt tudják, hogyan kell megvalósítani valamit, de nem feltétlenül látják, milyen kérdések hiányoznak a specifikációból. Az üzleti elemző feladata pontosan az, hogy ezeket a kérdéseket előre felszínre hozza.

Mit csinál valójában egy jó üzleti elemző?

• Feltárja az igényt, nem csak leírja. Kérdez, ellentmondásokat keres, és kimondja, amit mindenki magától értetődőnek gondol.
• Összehangolja az érintetteket. Ha több üzleti terület mást akar, nem a fejlesztőcsapatnak kell eldöntenie, kinek legyen igaza.
• Kezeli a változást. Az új igényt nem tiltja meg, hanem láthatóvá teszi a hatását a határidőre és a költségre.
• Ott van a megvalósítás alatt. Válaszol a fejlesztők kérdéseire, részt vesz a demókon, és segíti a tesztelőket, amikor az első ellentmondás előkerül.
• Átviszi az eredményt az átvételen. Az elfogadási kritériumokból tesztesetek lesznek, a felhasználói átvétel (UAT) pedig nem meglepetés.

Amit a leggyakrabban kihagynak a specifikációból

A félreértések ritkán a fő folyamatnál keletkeznek. Azt mindenki ismeri, és mindenki el tudja mondani. A drága meglepetések tapasztalatunk szerint jellemzően ezekből a területekből jönnek:

• Kivételek és ritka esetek: a „normál” ügymenet mellett a speciális szerződéstípusok, a visszamenőleges módosítások, a stornók.
• Nem funkcionális követelmények: teljesítmény, rendelkezésre állás, naplózás, adatmegőrzés. Ezekre senki nem gondol, amíg az éles terhelés alatt lassú nem lesz a rendszer.
• Jogosultságok és szerepkörök: ki láthat és ki módosíthat mit, és ki hagy jóvá.
• Adatmigráció: a régi adatok minősége, hiányzó mezők, eltérő kódlisták.
• Integrációk és szabályozói elvárások: a környező rendszerek viselkedése, valamint a megfelelőségi és auditkövetelmények, amelyeket szabályozott környezetben dokumentáltan is igazolni kell.

Egy tapasztalt BA ezekre célzottan rákérdez, mert tudja, hogy ezek nem jönnek elő maguktól a workshopokon.

Agilis projektben is kell? Igen, csak máshogy

Gyakori ellenvetés, hogy agilis csapatban „nincs szükség BA-ra, mert a product owner és a csapat együtt dolgozza ki az igényt”. A gyakorlatban az agilis működés nem kiváltja, hanem átalakítja a BA szerepét. Marty Cagan, a termékmenedzsment egyik meghatározó szerzője által népszerűsített „folyamatos feltárás” (continuous discovery) lényege, hogy a feltárás és a fejlesztés párhuzamosan fut: az ötleteket olcsón, még a fejlesztés előtt kell validálni, mert Cagan szerint egy ötlet megépítése és élesítése általában a leglassabb és legdrágább módja annak, hogy kiderüljön, működik-e.

Ebben a modellben a BA nem a projekt elején ír meg egy vastag specifikációt, hanem folyamatosan egy-két sprinttel a fejlesztés előtt jár: tisztázza a következő backlog-elemeket, elfogadási kritériumokat ír, és kiszűri az ellentmondásokat, mielőtt azok kódba kerülnének. Az IIBA 2026-os trendösszefoglalója is ezt az irányt írja le: a statikus, előre rögzített követelményeket felváltja az iteratív, visszajelzésekre épülő feltárás.

Három konkrét eset

Biztosítói Salesforce-projekt: amikor nincs belső BA-kapacitás

Egy nagy biztosítónál a Salesforce CRM bevezetésekor a belső BA-csapatot más projektek kötötték le. A döntés: induljon el a projekt BA nélkül, „az üzlet majd elmondja, amit kell”. Négy hónappal később, a fejlesztés közepén derült ki, hogy a biztosítási folyamatok adatmodellje és a Salesforce standard objektumai között olyan eltérések vannak, amelyeket a fejlesztők és az üzlet egyaránt feltételezések alapján kezeltek, ráadásul egymástól eltérő feltételezések alapján.

A projekt három hónapot csúszott, a fejlesztési keret 40 százalékkal nőtt. Ezután vontuk be a FrontX üzleti elemzőjét, aki a biztosítási folyamatok ismerete miatt két héten belül produktív volt, és a projekt hátralévő része scope-változás nélkül zárult.

Lízingcég, workflow-automatizálás: amikor a specifikáció „kész” volt

Egy operatív lízingcégnél a workflow-automatizálási projekt specifikációja elkészült, mindenki jóváhagyta, a fejlesztés elindult. Az első tesztkörben derült ki, hogy a specifikáció nem tartalmazta a kivételes szerződéstípusok kezelését, amelyek a volumen 30 százalékát adták.

Az újratervezés és az újrafejlesztés két hónapba és a keret 35 százalékába került. Ez nagyjából háromszorosa annak, amennyibe egy BA három hónapos bevonása került volna.

Back-office nyilvántartó rendszer: amikor nincs domain-tudás

Egy induló vállalkozásnál a szoftverfejlesztési oldalon nem volt üzleti tudás. A fejlesztők közvetlenül próbálták értelmezni az ügyfél igényeit, domain-ismeret nélkül. Az eredmény: két teljes sprint munkája vált feleslegessé, mert a belső kalkulációs logikát félreértelmezték. A javítás időben és pénzben is többe került, mint ha a projekt elején bevontak volna egy üzleti elemzőt.

Kiváltja-e az AI az üzleti elemzőt?

Ez ma az egyik leggyakoribb kérdés. Az AI-eszközök valóban sokat gyorsítanak a BA munkáján: összefoglalják a workshopokat, első változatot készítenek a user storykból és az elfogadási kritériumokból, ellentmondásokat keresnek egy hosszú specifikációban, teszteseteket javasolnak, és legacy rendszereknél segítenek kinyerni a kódba temetett üzleti szabályokat (erről bővebben: miért buknak el a legacy modernizációs projektek).

A szakma maga is így látja: az IIBA 2025-ös globális felmérésében a megkérdezett üzleti elemzők 74 százaléka mondta, hogy az AI pozitívan hat a karrierjére (az előző évben 63 százalék), és a felmérés szerint a kommunikációs és problémamegoldó készségek felértékelődnek, ahogy az ismétlődő feladatokat átveszi az AI. Új feladat is megjelent: az AI-t használó rendszereknél valakinek a követelmények közé kell írnia az adatminőségre, az átláthatóságra, a felelősségre és a kockázatkezelésre vonatkozó elvárásokat is. Az EU AI Act alatt álló pénzügyi szolgáltatóknál ez nem elméleti kérdés.

Amit az AI nem tud: nem tudja, mit nem mondtak ki a megbeszélésen. Nem dönt két üzleti terület vitájában, és nem érzi, hogy egy „egyszerű” kérés mögött szabályozói kockázat van. Ráadásul magabiztosan ír le hiányos követelményt is. Tapasztalatunk szerint az AI a jó BA-t gyorsabbá teszi, a hiányzó BA-t viszont nem pótolja: aki nem tudja, mit kell megkérdezni, annak az AI is csak a rossz kérdésre ad gyorsabban választ.

Mikor NEM kell üzleti elemző?

Az objektivitás kedvéért: nem minden projekthez kell dedikált BA. Ha a fejlesztés rövid (egy-két sprint) és jól körülhatárolt, a fejlesztőcsapat ismeri a domaint, és az üzleti igény egyértelmű és stabil, BA nélkül is el lehet indulni. Kis belső fejlesztéseknél, ahol a megrendelő és a felhasználó ugyanaz a személy, szintén nem kell külön üzleti elemzői szerep.

Az igazi kérdés az, hogy van-e valaki, aki gazdája az üzleti igénynek. Ha igen, akár egy fejlesztő, a product owner vagy a projektvezető tölti be ezt a szerepet, a projekt biztonságosabban indul. Ha nincs ilyen ember, a BA bevonása nem luxus, hanem kockázatkezelés.

Ellenőrzőlista: kell-e BA a projektedre?

Ha az alábbiak közül bármelyikre igen a válasz, érdemes üzleti elemzőt bevonni.

• Nincs mérhető válasz arra, honnan fogjuk tudni, hogy a projekt sikeres?
• Több üzleti terület érintett, eltérő érdekekkel?
• Van compliance- vagy szabályozói követelmény (például MNB-ajánlás, DORA, GDPR)?
• A rendszer meglévő legacy rendszerekkel integrálódik?
• A projekt három hónapnál hosszabb, így az igények biztosan változni fognak?
• A fejlesztőcsapat nem ismeri az üzleti területet?
• Nincs egyértelmű gazdája az üzleti igénynek, vagy a válasz az, hogy „mindenki”?

Amit a FrontX-nél másképp csinálunk

• Üzleti elemzőink nem adják át a dokumentumot és lépnek tovább: ott vannak a megvalósítás, a demók és a tesztelés alatt is.
• Pénzügyi szektorbeli projektekre iparági háttérrel rendelkező BA-t vonunk be, így a biztosítói, banki és lízinges folyamatokat nem kell betanítani, és rövid a beilleszkedés.
• Az igényfeltárásban AI-eszközöket is használunk, de a döntéseket és a kérdéseket ember hozza.
• A BA és a tesztelés együtt dolgozik: az elfogadási kritériumokból tesztesetek lesznek.
• Rugalmasan vonható be: projektre vagy csapatkiterjesztésként. Részletek az üzleti elemzői szolgáltatásunk oldalán.

Ha szeretnéd felmérni, igényel-e a projekted üzleti elemzői támogatást, szívesen segítünk: kérj ingyenes konzultációt.

Ha üzleti elemző vagy, és olyan helyen dolgoznál, ahol a szereped valóban számít, nézd meg nyitott pozícióinkat.

Gyakran ismételt kérdések

Miért kerül többe egy hiányzó BA, mint a jelenléte?

Mert az újrafejlesztés drágább, mint az első helyes fejlesztés. Egy senior BA hat hónapra bruttó bérben nagyjából 9-11 millió forint, ugyanennyibe kerül, ha egy 4 fős senior fejlesztőcsapat kapacitásának 20 százaléka félreértett igény miatti újrafejlesztésre megy el. Nemzetközi kutatások szerint a gyenge követelménykezelés akár 60 százalékos idő- és költségtöbbletet okoz.

Mikor szükséges üzleti elemző bevonása egy IT-projektbe?

Ha több üzleti terület érintett, ha van compliance- vagy szabályozói követelmény, ha a rendszer legacy rendszerekkel integrálódik, ha a projekt három hónapnál hosszabb, vagy ha nincs egyértelmű gazdája az üzleti igénynek. Pénzügyi szektorbeli projekteknél ezek a feltételek szinte mindig teljesülnek.

Mennyibe kerül egy üzleti elemző Magyarországon?

A Bluebird 2026-os budapesti összesítője szerint egy junior BA bruttó havi bére 850 ezer és 1,1 millió, egy medior BA-é 1,1 és 1,5 millió, egy senior BA-é 1,5 és 1,8 millió forint között van. Külső, T&M konstrukcióban a díj magasabb, mert a szolgáltató költségeit is tartalmazza.

Kiváltja-e az AI az üzleti elemzőt?

Nem. Az AI gyorsítja a jegyzetelést, a user storyk és tesztesetek első változatának elkészítését és a specifikációk ellenőrzését, de nem tudja, mit nem mondtak ki, és nem dönt az érintettek között. A jó BA-t gyorsabbá teszi, a hiányzót nem pótolja.

Agilis projektben is szükség van üzleti elemzőre?

Igen, de más szerepben. Agilis környezetben a BA nem egyszeri specifikációt ír, hanem a folyamatos feltárásban vesz részt: egy-két sprinttel a fejlesztés előtt tisztázza a következő backlog-elemeket, elfogadási kritériumokat ír, és kiszűri az ellentmondásokat, mielőtt azok kódba kerülnének.

Mi a különbség az üzleti elemző és a product owner között?

Az üzleti elemző az igény feltárásának és pontos leírásának gazdája, a „hogyan működjön pontosan?” kérdésre ad választ. A product owner a fejlesztési prioritások gazdája, azt dönti el, „mit fejlesszünk most”. Egészséges agilis projektben a két szerep kiegészíti egymást. Ha egy ember próbálja mindkettőt betölteni, tapasztalatunk szerint leggyakrabban a mély igényfeltárás marad el.

Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn-profil