Business case, CBA, štúdie IT projektov

Tu budem zbierať zaujímavé odkazy ohľadom business cases, CBA a štúdii IT projektov. Ukážka

https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent

https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent/agile-digital-and-it-projects-clarification-of-business-case-guidance

Do pozornosti davam, ze business case sa robi paralelne alebo po discovery & alfa faze. Cize najprv sa zistuje co to ma ± robit a to je vstup pre business case. V nasom svete studia uskutocnitelnosti. Kde asi tak robime chybu? :wink:

…u nas sa vie, co to ma robit, preto sa to preskakuje…a uz sa riesi len, ako to kvalitne, otovrene a lacno naimplementovat…

3 Likes

@peter_k pozor na tieto ironie na internete, neznaly clovek to nemusi dobre pochopit.

1 Like

…priznam sa, ze osobne som sa pred par rokmi na to tak pozeral…minimalne v oblasti definovania biznis poziadaviek…

Ináč teraz, keď sa povinne robí reformný zámer, je dosť priestoru na to, aby v čase písania štúdie boli všetky biznis analýzy už spravené. A teda by nemal byť problém ani poriadne odargumentovať business case, CBA atď. pre IT projekt.

mas znalost o takom RZ? ak ano, nalinkuj pls.

@panda aky je tvoj nazor na to co vsetko by mala posudzovat studia? Napriklad v studii NASESu (rozvoj slovensko.sk) je odhad na “statny messenger”. Ten odhad je vyvoj za ~700tisic eur. Existuju snad stovky krabicovych rieseni, ktore toto poskytuju. Nemala by studia zvazovat nielen vyvoj ale aj nakup sluzby?

Napriklad tu toto pouziva pokial viem financna sprava. Stoji ta licencia ~$35.000 eur (rocne upgrady + support).

Jasne, vendor lock (aj ked data su tvoje), ale pre mna to je stale neporovnatelne. Ved to by sme mohli 25 rokov kupovat stale dookola a stale by to stalo menej. Co si mam mysliet o takychto studiach a expertoch a inych “expertnych odhadoch” ked takato jasna vec tam nie je.


Poznamka pod ciarou. LiveAgent vyraba zhodou okolnosti sponzor SD (quality unit), ale len sa mi nechcelo hladat nic ine.

1 Like

Podla mna by toto studia urcite mala posudzovat, ak to neposudzuje, mala by to zdovodnit, ze preco. To je bez debaty.

2 Likes

neviem ci je to take jasne, studia popisuje biznis ciele, architekturu a pod. konkretny vyber ci bude pouzita licencia alebo vlastny vyvoj by mal navrhnut vo vo uchadzac. podla mna zase chceme od studie viac ako moze dat. nabuduce bude poziadavka aby detailne popisala funkcnu specifikaciu

No práve. Ak štúdia je podklad pre vyhlásenie vo a predmet zákazky, tak keď sa tam napíše, že to bude stáť asi milión ale reálne sa to da kúpiť za 30k a nastavia sa podľa toho zábezpeky, kritériá o tom ako musí mať firma skúsenosť s projektom nad milión za posledných päť rokov a pritom by to v skutočnosti bolo možné kúpiť okamžite od desať chlapovej firmy, tak niečo úplne zlyhalo a taká štúdia je úplne nanič.

1 Like

presne na to su revizne postupy pri vo. bez detailnej analyzy nevies ci sa to da naozaj pouzit ani su naklady na implementaciu a zmeny dalsich casti. tuto znalost ma ten co to ponuka a uz to robil. ak je to sucastou niecoho vacsieho, tak je lepsie to dodat pre niekoho. ak je to samostatne, tak vies namietat urcenie podmienok. dnesny stav ze studia ma urcit vsetko je podla mna kontraproduktivna

cim nechcem obhajovat chatbota, len si myslim ze takychto veci tam je plno. rozhodnutie ako co najlacnejsie dodat riesenie je podla mna uloha dodavatela, studia v lepsom pripade je povinna jazda bez velkeho prinosu, v horsom zabetonuje veci ktore by sa dali spravit inak.

1 Like

Chapem tvoj postoj, ale sucasna situacia je, ze studia sa spravila pomerne detailnou, je tam:

  • navrh architektury,
  • rozdelenie na logicke komponenty,
  • pri tychto komponentoch musis v rozpocte urcit, ci sa jedna o nakup krabicoveho SW alebo custom vyvoj.

Cize tato informacia v studii musi byt a dodavatel rozhoduje az veci na nizsej urovni.
A ak su raz v SU na komponent alokovane mandays, tak uz nikto nebude kupovat krabicove riesenie, lebo jednak tak nebude napisane VO a jednak by to bolo vela administrativy (ziadost o zmenu atd).

presne to sa mi nepaci, studie dnes pisu specialisti na pisanie studii, posudzuju to uradnici. Formalna stranka je to co je obsahom. Na tejto urovni rozhodnut co bude licencia a co bude vlastny vyvoj vyzaduje vo vacisne pripadov znalosti ktore nemaju.
Ciste na ukazku : nakolko je chatbot v sulade s architekturou eGOv, nakolko sa da custmizovat, ake su obmedzenia zo strany nasadenia, je v sulade s bezpecnostou politikou cloudu, GDPR atd. A skutocne to vie odpovedat na otazky automaticky alebo ide len o marketing a je to vlastne len ticketovaci system ? A pripadne ktory je vhodny a ktory nie. Plno otazok a to este nevieme ani detaily ake su okruhy otazok, co vsetko ludia riesia a aka ma byt uroven automatizacie aby to davalo zmysel. Ale uloha znie : daj cenu, tak tam napise 1000 MD a dufa ze za to sa da nieco dobre spravit.
A to este mas znalosti ze to existuje, pri dalsich moduloch to ani suchal netusi.

A to nehovorim ani o realite, v studii sa napise velmi obecne zadanie, ktore uzivatel schvali pretoze tomu nerozumie. Ked pri analyze vzniknu podrobnejsie Use Case, tak sa zisti ze tretinu toho co mu navrhol dodavatel nechce ale potrebuje nieco ine. Taketo zmeny sa deju v projektoch ci uz komercnych alebo statnych bezne. Ale kedze teraz je fixnuta architektura tak je to tazsie a projekt je este menej flexibilny.
Ako obstaravat agilny vyvoj este nikto nevymyslel a zatial sa to len zhorsuje

osobne by som preferoval a by mi aj stacilo, keby studia zodpovedela, ze ci to je vobec potrebne - ano/nie a ak ano, tak aku prioritu to ma z pohladu biznis procesu a z pohladu pridanej hodnoty pre pouzivatela a z pohladu zavislosti s inymi komponentami/inymi projektami…proste keby studia urobila ramcovy prioritizovany backlog, ktoremu rozumie zakaznik, buduci pouzivatel a aj dodavatel a vyselektoval by nice to have poziadavky od must…nemame a nevieme poriadne spravit zakladne veci (podla mojho nazoru to dokazuju 2 programove obdobia), ale uvazujeme a ideme implementovat nepodstatne veci…

…sorry ale konkretne chatbot v tomto pripade mi pride uplne zbytocna cast…aj keby to stalo len tych 35k/rocne, dokonca aj menej a to nebude jediny naklad spojeny s touto funkcionalitou…osobne by ma zaujimalo, ze ci zaradenie takejto funkcionality bolo podlozene nejakym vyskumom na pouzivateloch slovensko.sk a ci sa pozreli na realitu napr. pri o2 a inych sluzbach, kde sa chatbot pouziva…osobne som za svoj zivot pouzil chatbota 3krat (2krat o2, 1x netflix)…chatbota by som implementoval, keby som mal uz cely produkt odladeny, som si isty, ze z hladiska UX, technologie, obsahu uz neviem nic viac spravit a zostali mi este nejake financne zdroje…

1 Like

ano, tak by to malo byt. ale v systeme kde ziadas peniaze na zaciatku to nejde

ano, smola je, ze sa nezmenil nijak sposob financovania/poskytovania NFP…napr. na vyssej urovni, t.j. uroven operacneho programu EK pre toto programove obdobie urobila nasledovny mechanizmus:

  • kazdy OP ma pre prioritnu os alokaciu,
  • kazdy OP ma pre prioritnu os ukazovatele programu,
  • kazdy OP mal moznost si na urovni prioritnej osi z ukazovatel programu identifikovat take, ktore povazuje za klucovy implementacny krok
  • ku konkretnym rokom sa vyhodnocuje, ci dany klucovy implementacny krok dosiahol planovanu hodnotu
  • ak dosiahol, EK uvolni dodatocnu alokaciu ako “odmenu”

-> obdobny princip by mohol byt preneseny aj na uroven eurofondovych projektov - urobil si vsetko, co si mal a dosiahol si vysledky v slubovanom case, tak tu mas odmenu a dorob si kludne tie “kudrlinky/pozlatko”

alebo

existuju nepriame vydavky a tam plati pravidlo, ze sa povoluju len do vysky XY% z rozpoctu priamych vydavkov projektu, cize velkostou hlavnych aktivit projektu je alikvotne definovana vyska nepriamych vydavkov

-> opat obdobny princip mohol byt pouzity aj pre ZoNFP v ramci OPII, ale to by musel niekto, kto pisal studiu alebo v tomto pripade Nases oznacit chatbota ako nie hlavnu aktivitu projektu

alebo

-> priame zadania mali sluzit len na vybudovanie “must” poziadaviek a dopytovo-orientovane vyzvy na dobudovanie takychto “kudrliniek/pozlatka”

atd.