A mai napig sok ügyfelünknél felmerül problémaként az erőforrásmenedzsment, mint terület. Az erőforrásprobléma a munkaerőhiánnyal és a fluktuációval karöltve nem kevés fejtörést okoz a vállalatoknak. Gyakran szegezik nekünk azt a kérdést a PPMO képzésen, hogyan lehet jól menedzselni az erőforrásokat. 
Sokan készítenek részletes erőforrástervet a következő időszakra (hónapra, negyedévre), és a rendelkezésre álló erőforrás alapon döntenek a folyamatban lévő projektek, feladatok prioritásáról. Bár ez is egy nagy előrelépés, de jellemzően tűzoltás jellegű, és nem a gyökérokot kezeli. Miért?
Mert ha a folyamatban lévő projekteket kell priorizálni (nem esetileg, jó okkal, hanem rendszerszerűen), az annak a jele, hogy több projekt/feladat fut, mint amit a szervezeti kapacitás elbír.
Az erőforrások akkor fognak felszabadulni, ha egy projektet/feladatot befejezünk. Amennyiben egy projekt csúszik, az kihatással lesz a többi, a felszabaduló erőforrásra váró projektre/feladatra.
Tehát a felmerülő problémák kezelése mellett arra is figyelmet kell fordítani, hogy a projektek a tervezett ütemben (és eredménnyel) valósuljanak meg. Ha a projektek rendszeresen csúsznak a vállalt határidőkhöz képest, akkor érdemes beavatkozni a folyamatokba.
A projektek leggyakrabban az alábbi okok miatt csúsznak:
Nyilvánvalóan a projekt csúszást nem lehet 100%-ban kiküszöbölni, de egy jól működő PMO segíthet abban, hogy feltárja, hol vannak a folyamatban a problémák, és hol kell beavatkozni.
A jól működő PMO feladata:
Amennyiben a PMO fejlett projekt kultúrában jól végzi a dolgát, akár a projektek akár 90%-a befejezhető időben, ami jelentősen megkönnyíti az erőforrásmenedzsmentet is.
————————————————————————————————————-
A kétnapos nyílt program során áttekintjük a projekt portfólió menedzsment céljait, lehetőségeit, nehézségeit, valamint azokat az eredményeket, amik bizonyítottan értéket teremtenek a szervezet és a vezetőség számára, illetve azokat, amikre sok energia megy el, de nem teremtenek valódi értéket. Hiánypótló képzés, gyakorlatban bizonyított megoldásokkal, módszerekkel, sablonokkal. – Részletek > > >
“Teljesen gyakorlatias, másnap használható ötletek, tű pontos megértést ad a PMO-t érintő kihívásokkal kapcsolatban” (Bolyó Gábor – PMO vezető, UniCredit Bank)
Szerző: Fodor Andrea
Nemrég, az ITBUSINESS kiváló konferenciáján tartottam előadást arról, hogy mennyi értelmezése van az agilitásnak.
Miért van az, hogy a nagyvállalatok – kevés kivétellel – az agilitást sem lenyelni, sem kiköpni nem tudják? Hogy senkinek az elvárása nem teljesül maradéktalanul? Hogy bár nemes a cél, de a megvalósítás döcög, és sokszor nem is a cél irányába mutat a haladás?
A mellékelt ábrával majdnem minden agilis tréningen találkozhatunk. 
Azt hivatott szemléltetni, hogy a klasszikus waterfall megközelítéssel szemben, amikor a termék üzleti előnyeit csak a leszállítás után lehet realizálni (akkor tudunk eljutni A-ból B-be, ha kész az autó), az agilis termékfejlesztés során a termék üzleti eredményeit jóval korábban (már a gördeszka piacra dobásakor) élvezhetjük.
Ezzel tapasztalatot gyűjthetünk, és tanulhatunk abból, hogyan fogadja a piac az ötletünket. A visszajelzések alapján módosíthatunk a koncepción, simán kiderülhet, hogy nem is autóra, hanem kisrepülőgépre van szükség.
Ez a filozófia életmentő lehet startupok esetén, akiknek a leggyakoribb problémája, hogy túl sokáig dédelgetik az ötletüket, mielőtt piacra dobnák, és túl sok pénzt-időt-energiát invesztálnak valamibe, amit esetleg a piac nem úgy fogad, mint azt eltervezték.
Jó lehet innovációs projektek esetén, amikor egy cég – akár nagyvállalat – új terméket szeretne piacra vinni. Bár ez esetben már rendelkezésre állnak az erőforrások egy rendes piackutatás, vagy fókuszcsoport alkalmazására, amivel konkrét ügyfélkövetelmények és vélemények gyűjthetők, és ez valószínű olcsóbb, mint próbálkozni a különböző megoldásokkal.
Nem jó, de sajnos néha elkerülhetetlen az az eset, amikor IT megoldásszállítók – és ne felejtsük el, hogy az agilis kiáltvány maga ilyen cégektől származik – az ügyféltől zavaros, nem egyértelmű, hiányos követelményeket kapnak, és a stakeholderek nem elérhetők egyeztetésre. Ilyenkor valóban nincs más választásuk, mint minél előbb szállítani valamit, amiről az ügyfél elmondhatja a véleményét. De ettől még a megrendelő nem realizálhatja a fejlesztés üzleti eredményét, csak egy „prototípus”-nak nevezett követelménygyűjtési technikát alkalmaznak, hogy megértsék azt, hogy mire van az ügyfélnek valóban szüksége. De ennél is jobb megoldás, ha felmérjük és elemezzük a követelményeket, egy olyan megoldást kialakítva, amibe beépítettük az üzleti követelményeket, a vonatkozó üzleti és jogszabályokat, meg tudunk felelni a nem funkcionális követelményeknek, és le tudunk kezelni minden előforduló üzleti eseményt.
Ahol a projektek 99%-ánál van előre meghatározott leszállítandó? A megrendelőnél már működik egy autóbusz, csak egy szebbet, nagyobbat, olcsóbban üzemeltethetőt, kényelmesebbet szeretnének? Az ügyfelek mennyire lennének elégedettek, ha egy gördeszkát kapnának? Ha tetszik, ha nem, ilyenkor hibrid megoldásokba kényszerülünk bele.
Ez persze csak akkor jelent problémát, ha ez nem tudatosul, és a tiszta agilis elemeket szeretnénk erőltetni. Tudomásul kell venni, hogy hibrid projektnél:
Ennek a problémának az áthidalására dolgoztuk ki követelménymenedzsment módszertanunkat, amelyben összefésültük, ezért kombinálhatóvá tettük a terméktervezést. Business Analyst képzéseinken is oktatott módszertanunk lényege:
Business analyst képzéseinket itt találod >>>
IT beszállítóknak ezt az üzleti elemző képzést ajánljuk >>>
Tudod, az a fiatal srác a Business Analyst csapatban, afféle digitális polihisztor. Van valami Pí-Em-Áj akkreditációja is, és amúgy mérnökinfós végzettségű. Szóval pár technikai dologhoz is hozzá tud szólni elvileg. Múltkor is segített a Konfluenszbe, vagy mibe, meg a Serpontba is, bár arra már nem emlékszem, mert másnapos voltam. Ja meg azelőtt meghallgatta az igényeinket, kötekedett kicsit, és a végén valami specifikációt is készített. Én nem olvastam, de a Juli megnézte, és neki oké volt. Aztán pár hétre rá kész is lett a fejlesztés (bár nem értem, mit kellett fejleszteni, mert csak egy mezőt kértünk a felületre, nameg a riportot).
Aztán Peti szólt, hogy megtervezte a tesztelést, és jófejségből le is tesztelte, amit kértünk, mert mondtuk, hogy nem érünk rá most erre. Adott valami teszt jegyzőkönyvet is, és Juli jóváhagyása után élesítették a rendszer új verzióját. Végül is, a mező felkerült, meg a riport is. A főnököm tök elégedett volt, ja és meg is köszönte a munkám, szóval egész jó a srác.”
Junior elemzőként bedobtak a mély vízbe, és egy komplex, feszültséggel teli projektet kellett újra sínre tenni, és bevezetni egy új funkciót az egyik hazai nagybank internetbanki alkalmazásába. Ugyan igazi csapatmunka volt, de sikeres lett végül a projekt, és nagyon jó visszajelzéseket kaptam a projektzárást követően, és előléptettek medior elemzővé.
Nincs igazán kedvencem, de előszeretettel vizslatom a stakeholdereket a benefitekkel. „És ez most nekünk miért is éri meg?” 🙂
Szeretném egyszerre a big picture-t is látni, de ugyanakkor a dolgok hátterét is ismerni, valamint rendkívül elismert szakemberré válni, akihez szívesen mennek oda a kollégák tanácsért vagy tudásért.
Business Analystként kedvencem az RTM (Requirements Traceability Matrix)
Például olyan nagyméretű, digitális szolgáltatás bevezetésére törekvő projektnél, ahol több stakeholder igényeinek kellett megfelelni egyszerre, és szükség volt az igények kidolgozottságának státuszolására.
Kifejezetten sikeres volt az RTM használata. A projekt elején egyeztettem az IT-s kollégákkal, hogy ezt a specifikációs formátumot szeretném használni, és meglepődve tapasztaltam, hogy mindenki nyitott volt rá. Amellett, hogy közösen tudtunk dolgozni benne, és a táblázatos elrendezés lehetőséget adott egy moduláris, könnyen szűrhető specifikáció vezetésére. Így Business Analystként folyamatosan tudtam státuszolni az igények kidolgozottságának állapotát.
Ha Te is érdeklődsz a Business Analyst szakma iránt, ellenőrizd, alkalmas lennél-e rá! Tehetségprogramunkban folyamatosan keresünk tehetséges fiatalokat, akik ezen a pályán szeretnének elindulni.
Néhány évvel ezelőtt még nagy divatja volt a folyamatmenedzserek alkalmazásának a vállalatoknál. Sok helyen volt, néhol még most is van folyamatmenedzsment osztály, kollégáik a működési folyamatok monitorolásával, optimalizációjával, hatékonyságjavításával foglalkoztak. De mivel szaktudásuk, end-to-end folyamatszemléletük alkalmassá tették őket, hamar a projektekben találták magukat, üzleti specifikációkat írva.
Jelenleg, az általunk ismert szervezeteknél, ahol megmaradt a folyamatmenedzsment terület, a folyamatszervezők szinte kizárólagosan projektek előkészítésén, döntési anyagok előállításán, illetve üzleti követelményspecifikációk elkészítésén dolgoznak, üzleti elemzői munkát végezve.
A folyamatszervezők, folyamatmenedzserek tehát üzleti elemzői munkát végeznek, akár tudnak róla, akár nem. Sok ügyfelünknél már meg is szűnt a folyamatmenedzsment/folyamatszervező szakterület. A háttérben az alábbi egyszerű okok állnak:
Ugyanakkor a folyamatszemlélet, a folyamatoptimalizáció képessége az egyik legfontosabb kompetencia, amire a vállalatoknak – a szolgáltató szektorban különösen – szüksége van. Ez a kompetencia beépült az üzleti elemzők eszköztárába, annak talán legfontosabb eleme. Mondhatni, hogy minden üzleti elemző végez folyamatszervezői tevékenységet, de nem minden folyamatszervező végez teljeskörű üzleti elemzői tevékenységet.
Ahol nélkülözhetetlen a folyamatszemlélet az üzleti elemzői munkában:
Az alábbi esetekben viszont mégiscsak van létjogosultsága egy olyan csapat működtetésének, akik folyamatosan monitorolják és definiálják a folyamatjavítási intézkedéseket:
Az üzleti elemzőknek ezért javasoljuk a folyamatelemzés és optimalizációs technikák elsajátítását.
Folyamatok ábrázolása, mérése és folyamatmenedzsment – módszerek, eszközök: Lean képzés
Átfogó, módszertani üzleti elemző képzésünket pedig itt találod >>>
Nézd meg, hogy Neked való-e a Business Analyst karrier!
Meghívtuk 2 kollégánkat, akik üzleti elemzőként dolgoznak, hogy egy kerekasztal beszélgetés kereteiben jobban betekintést nyerhessetek az üzleti elemzői munkakör mindennapjaiba.
Velük beszélgetünk, hogy hogyan is élik meg, mit szeretnek a munkájukban és mit is tanácsolnának pályakezdőknek.
A videó eléréséhez kattints ide: Business Analyst – kerekasztal beszélgetés – Projektcoach Consulting
Üzleti elemző karrier,mi szükséges hozzá?- Karrier Trend – Projektcoach Consulting Kft.
Az üzleti elemző segít a megrendelő(k)nek jó megoldásokat találni az üzleti problémáikra. Legtöbbször, de nem kizárólagosan IT megoldásokat. Segít megtervezni, milyen követelményeknek kell megfelelnie a megoldásnak ahhoz, hogy az kielégítse a megrendelő igényét, úgy, hogy az üzleti és stakeholder elvárások teljesüljenek, illetve a vállalati folyamatok továbbra is működjenek.
Változó világunkban nagy igény mutatkozik jól képzett üzleti elemző szakemberekre, akik üzleti szemléletükkel hozzájárulnak ahhoz, hogy üzletileg jó és hatékony informatikai megoldások szülessenek a vállalatoknál. Gondolkozol a karrierváltáson? Tedd meg az első lépéseket, jelentkezz business analyst Tehetségprogramunkba!
Siker = Megfelelő szakmai tudás + képességek + készségfejlesztés
Szükséges képességek és személyiségjegyek:
Szükséges, fejleszthető készségek:
Lehet, hogy Neked való ez a szakma, ha:
Business Analyst állást keresel? Vonz az üzleti elemzői munka? A Projektcoach Consulting több évtizedes releváns szakmai tapasztalattal és nemzetközileg elismert Business Analyst minősítéssel rendelkező szakemberekkel segítenek Neked beindítani üzleti elemzői karriered! Ha érdekelnek a részletek, tájékozódj ezen az oldalon: Business Analyst Tehetségprogram
Projektcoach Consulting: Overview | LinkedIn
IT és Üzlet – Sok helyen még tartja magát az a nézet, hogy a nagyvállalatok IT részlegének szolgáltatnia kell. Úgy, mint egy beszállítónak. Több nagyvállalat döntött úgy, hogy külön cégbe szervezi ki az IT szolgáltatásait, annak érdekében, hogy minőségibb szolgáltatást kapjon. És míg az IT üzemeltetési tevékenységek tökéletesen működőképesek szolgáltatás alapon, addig az IT fejlesztések szolgáltatói szemlélettel való megközelítése szinte mindenhol komoly problémákba ütközik.
A problémák miatt az üzlet és az IT egymásra mutogat – az IT egyre pontosabb specifikációkat kér, mielőtt nekiáll a munkának, az üzlet egyre elégedetlenebb, és nekiáll megkerülni a folyamatokat, vagy alternatív megoldásokat keresni.
Vannak viszont jól működő szervezetek is, ahol az IT és az Üzlet partnerségben működik együtt, az ötlet felmerülésének pillanatától kezdve.
Mi kell ahhoz, hogy ez a partneri viszony kialakuljon? Több ügyfelünket elindítottuk már a partnerré válás rögös útján. A legelső lépés a felismerés: változtatni kell, a jelenlegi működés nem fenntartható. Ha az igény tiszta, a megoldási lehetőségek már adják magukat ?
A Backlog (leánykori nevén várólista, de fordítják még hátraléklistának is) egy projekthez tartozó feladatok listája, mely fontossági sorrendben szedi össze az elvégzendő feladatokat.
Az IT területek üzleti partnerei , illetve az üzleti elemzők részéről gyakran jelentkezik dilemmaként, hogyan mondjanak nemet egy-egy igényre, egy-egy követelményre, amennyiben annak megvalósítására nincs már pénz vagy erőforrás.
Az aggodalom jogos, a nemet mondás gyakran feszültséget szül, pláne, ha az igény egyébként jó, csak a kapacitás hiányzik a megvalósításra. Gyakori jelenség ilyenkor, hogy a nemet mondó szakember/terület megkerülésével az üzlet más úton próbálkozik, ott, ahol kisebb ellenállásba ütközik, sokszor sikerrel.
Ugyanakkor teljesen jogos, hogy nem valósíthatunk meg minden ötletet. Sokszor írtunk már róla, hogy amennyiben több a futó projekt, mint a szervezeti leszállító kapacitás, az projekt csúszáshoz vezet. A projekt csúszás meg mind költségoldalon, mind az elmaradt bevétel oldalon újraírja a business case-t, jelentős veszteséget okozva az eredeti tervekhez képest.
Napjaink kihívása, hogy sokkal több üzleti igény van, mint IT megvalósítási erőforrás. A szervezetek eleinte IT erőforrásbővítésbe kezdtek, de ez egyrészt fenntarthatatlanul költségesnek bizonyult, másrészt a szervezeti kapacitást ugye a szűk keresztmetszetek határozzák meg, és gyakran az üzleti folyamatokat ismerő erőforrások, illetve egyéb üzleti erőforrások is kevésnek bizonyulnak, így az eredmény ugyanaz, csak sokkal drágábban.
Oké, ha az erőforrásbővítés nem vezet eredményre, akkor az igényeket kell szűrni vagy csökkenteni. Kezdjük mindjárt azokkal, amik nem érik meg az erőfeszítést. Alapszabály, hogy ha egy üzleti problémával való együttélés költsége kisebb, mind a probléma megoldásának költsége, nem érdemes vele foglalkozni. Ehhez viszont üzleti elemzés szükséges, hogy feltárjuk mind a probléma nagyságát, mind a megoldás költség és erőforrásigényét.
Na de mit csináljunk, ha miután kiszűrtük a értelmetlen igényeket, még mindig sokkal több üzleti igény maradt, mint költség/erőforrás? Melyikre mondjunk nemet? És miért? Egyáltalán, nemet kell-e mondani?
A nemet mondás helyett a backlog és a priorizálás lehet a megoldás. A felszabadult kapacitás esetén a döntési felelősséget átháríthatjuk az üzlethez azáltal, ha a backlogból ő választhatja ki a számára legfontosabb elemeket. Így transzparens lesz az üzlet számára is a folyamat, és ez általában csökkenti a feszültséget.
Sokakat zavar a várólista hossza. Azonban nagyjából mindegy, hogy 50 vagy 5000 igény várakozik, mindaddig, amíg nem égettünk el túl sok erőforrást az igények megvizsgálására (ott, ahol az IT már kidolgozott specifikációkat vár az igény befogadásához, és azokat állítja sorba, az komoly problémákhoz vezet: egyrészt nagyon sok erőforrást emészt el a specifikációk kidolgozása, ami pazarlás egy olyan igény esetében, ami lehet, hogy meg sem valósul. De ha még meg is valósulnak, annyi változás van egyszerre, hogy az elkészült specifikációk nagyon hamar elévülnek – 2-3 hónap után már jelentős felülvizsgálatra szorulnak). Szóval a várólista hossza nem számít, amíg akkor kezdünk az igényen dolgozni, amikor már látjuk, hogy a megvalósításra van kapacitás.
A priorizálásnak a kiválasztásnál van értelme, azaz, hogy a szabad erőforrások terhére mely igényeket valósítjuk meg. Ha kiválasztottuk, akkor kötelezettséget vállaltunk a leszállításra. Paradox módon, ha a korlátokat figyelembe vesszük, összességében gyorsítható az IT leszállítás.
Sok szervezet folyamatosan küzd azzal, hogy a futó projektjeit priorizálgatja. Ez a biztos jele annak, hogy több projektet indítottunk, mint amennyivel a szervezet meg tud küzdeni. Ezek a cégek jellemzően csak a projekt indításokról döntenek, a kapacitásokkal nem foglalkoznak. Jól menedzselt projektportfóliónál az elindított projektekre megvan az „erőforrásfedezet”, a projektportfólió elemeit csak extrém változás esetén kell átpriorizálni.
Szintén szarvashiba, ha egy projektből/feladatból kieső, egymással összefüggésben lévő fejlesztési igényeket több backlog ban kezeljük, és külön priorizáljuk. Így előfordulhat, hogy az egyik igény top prioritást élvez, míg egy másik, ennek működéséhez szükséges másik fejlesztés 243. prioritás a backlogban. Vajon mikor fog megvalósulni ez az üzleti igény?
A megfelelő üzleti elemzés jelentősen megkönnyíti az üzleti igények priorizálását. Ez azonban csak akkor tud működni, ha a demand management folyamatok ütemezetten és átláthatóan működnek. Gyakorlati képzésünkön a leggyakoribb problémákat vesszük végig a leggyakrabban elkövetett hibákon keresztül, amik a szükségesnél nagyobb megoldásokhoz, lassúbb leszállításhoz, erőforráspazarláshoz és késedelmes projektekhez vezetnek.
Az üzleti igénykezelés leggyakrabban elkövetett hibái workshop
