Blog

A digitalizációs projektek többsége azért bukik el, mert IT-projektként kezeli, holott valójában szervezeti változásról van szó. Három szereplő hiánya okozza a legtöbb kudarcot: az üzleti folyamat gazdája, az üzleti elemző aki fordít az IT és az üzlet között, és a változásmenedzsment felelős. Amíg az üzlet passzív befogadó marad, a legjobb technológia sem hoz valódi változást.

Egy pénzügyi nagyvállalatnál 50-200 digitalizálható folyamat van. Mindenki a saját területét tartja a legfontosabbnak. A sorrend döntés stratégiai — mert ha az első projekt megbukik, a következőhöz már sokkal nehezebb belső támogatást kapni. Ez a cikk egy egyszerű döntési keretrendszert ad: négy tényező - fájdalomintenzitás, megvalósíthatóság, üzleti hatás és láthatóság - alapján meg lehet határozni mivel érdemes kezdeni. Három konkrét példán keresztül: biztosítótól, banktól és lízingcégtől.

A digitális transzformációs projektek többsége nem technológiai okból bukik el, hanem azért, mert hiányzik az üzleti szemlélet, a valódi folyamatértés és a változásmenedzsment. A cikkben 25 év pénzügyi szektorbeli tapasztalatomon keresztül mutatom be azt az 5 leggyakoribb mintát, amely miatt a vállalatok 70%-a nem éri el a kívánt üzleti eredményt. Valós biztosítói, banki és lízinges példákon keresztül látszik: a sikeres transzformáció nem az új rendszerekről, hanem a jól definiált üzleti célokról, a legacy rendszerek őszinte feltérképezéséről és az üzlet–IT együttműködésről szól.

A szoftvertesztelés kiszervezése nem minden esetben a legjobb megoldás - de négy konkrét helyzetben egyértelműen az: projekt csúcsterheléskor amikor toborzással nem ér oda időben a csapat, hiányzó domain tudásnál (különösen pénzügyi szektoros projekteknél), külső fejlesztői partner esetén ahol független szemre van szükség, és ha a QA nem core tevékenység de a minőség üzletileg kritikus. A cikk döntési keretrendszert ad - és azt is megmondja mikor NEM érdemes kiszervezni.

Sok IT projekt nem a technológia miatt csúszik meg, hanem azért, mert nincs, aki valóban gazdája legyen az üzleti igényeknek. A business analyst szerepe nem adminisztratív dokumentáció, hanem a félreértések, scope creep és drága újrafejlesztések megelőzése. A cikk valós projektpéldákon és piaci számokon keresztül mutatja be, hogy egy hiányzó BA költsége gyakran többszöröse annak, mint a bevonásának ára.

A cikk bemutatja, miért nem működik sok követelmény specifikáció és funkcionális specifikáció a gyakorlatban, még akkor sem, ha szakmailag rendben vannak. Egy tapasztalt üzleti elemző nézőpontjából 5 tipikus jelet sorol fel, amikor a specifikációt nem olvassák vagy félreértik. Fő üzenet: a specifikáció nem csak dokumentum, hanem kommunikációs eszköz — minősége közvetlenül befolyásolja az IT projektek sikerét.

A legtöbb legacy modernizációs projekt nem technológiai okokból bukik el, hanem azért, mert rossz problémát próbál megoldani. A scope gyakran a meglévő rendszer logikáját követi, nem az üzleti értéket, miközben az üzlet nincs valódi partnerként bevonva, és az emberi tényező is háttérbe szorul. A siker kulcsa az értékvezérelt megközelítés: gyors, kézzelfogható üzleti eredmények, inkrementális modernizáció (pl. API encapsulation), valamint tudatos szervezeti és működési változáskezelés.

Business analyst vagy product owner amire szüksége van a projektnek? Mikor kell BA és mikor PO, és mikor mindkét pozíció? Miben különbözik a két szerepkör? Ezekre keressük a válaszokat a cikkünkben.

Meddig tart a Business Analyst munkája? Mikor mondhatja el, hogy kész van? Három viselkedési jel, ami megmutatja, hogy a BA valóban hatékonyan dolgozik

A COVI hatalmas változást hozott a szükséges proojektmenedzsment módszerekben. Változó csoportdinamika, új eszközrendszer, változó stakeholder kezelés, és egy kis jövőbe révéedés, hogy mi fog még vátozni. Ezeket a kérdseket járuk körbe....

Mélységesen felháborodnánk, ha a hűtőszekrényünket naponta javítani kellene...A szoftvereinkhez viszont naponta jönnek patch-ek, javítások! 😀 ❓ Tényleg ennyire gyenge a szoftverek minősége? ❓ Véleményünk szerint nem!