70 Znaleziono wyniki wyszukiwania

Szukałeś: "audyt organizacji"
Projekt wykonany – co było robione

Projekt wykonany – co było robione

Powyższe jest zgod­ne z zale­ce­nia­mi OMG​.org (https://​www​.omg​.org/​mda), audyt to etap CIM a pro­jek­to­wa­nie przy­pad­ków uży­ci i mode­lu dzie­dzi­ny to etap PIM.

Wykonanie takiej ana­li­zy jest pra­co­chłon­ne i wyma­ga duże­go doświad­cze­nia, umie­jęt­no­ści ana­liz pro­ce­sów biz­ne­so­wych, pro­jek­to­wa­nia obiek­to­we­go i dobre­go narzę­dzia CASE, jed­nak mode­le te pozwa­la­ją tak­że prze­pro­wa­dzić ana­li­zy wpły­wu (zależ­no­ści pomię­dzy pro­ce­sa­mi, skut­ki i podat­ność na awa­rie opro­gra­mo­wa­nia itp.) oraz zre­du­ko­wać do mini­mum praw­do­po­do­bień­stwo prze­kro­cze­nia ter­mi­nu i kosz­tów (sta­ty­sty­ki wska­zu­ją na śred­nie prze­kro­cze­nie kosz­tów o 60% i ter­mi­nów o 200% pro­jek­tów z niskiej jako­ści spe­cy­fi­ka­cji wyma­gań). Praktyka auto­ra wska­zu­je, że war­to taką ana­li­zę prze­pro­wa­dzić dla pro­jek­tów, któ­rych budżet prze­kra­cza 50 – 70 tys, zł i większych.

Czytaj dalej Projekt wykonany – co było robione
Proces zbierania i analizy wymagań u developera

Proces zbierania i analizy wymagań u developera

Analiza Biznesowa i spe­cy­fi­ka­cja wyma­gań opra­co­wa­na meto­dą opi­sy­wa­ną tu i na stro­nach OMG, jest od tej ostat­niej (gru­pa kon­sul­tan­tów i sesje warsz­ta­to­we) znacz­nie tań­sza. W cza­sie trwa podob­nie, jed­nak robi to z regu­ły jed­na oso­ba (tak! ale przy zało­że­niu ma sto­su­je zaawan­so­wa­ne narzę­dzia CASE nie tyl­ko do two­rze­nia dia­gra­mów ale tak­że do ich wery­fi­ka­cji śla­do­wa­nia zarzą­dza­nia spój­no­ścią mode­li itp.), a efek­tem jest pro­jekt logicz­ny a nie dopie­ro lista wyma­ga­nych cech. Korzyść jest więc podwój­na. Jeżeli zro­bi to Analityk wyna­ję­ty przez Klienta a nie Dostawcy, to wszel­kie pra­wa (know-how) do pro­jek­tu pozo­sta­ją po stro­nie nabywcy.

Można powie­dzieć, że to trud­ne i kosz­tow­ne. Trudne owszem, wyma­ga doświad­cze­nia i wie­dzy zarów­no z zakre­su zarzą­dza­nia jak i inży­nie­rii opro­gra­mo­wa­nia. Per sal­do, wli­cza­jąc w to kosz­ty mody­fi­ka­cji na eta­pie wdra­ża­nia i odkry­wa­nia wyma­gań (wady spe­cy­fi­ka­cji nie pod­da­ją­cej się wery­fi­ka­cji) jest to pro­ces zawsze tań­szy (bada­nia kie­row­ni­ków pro­jek­tów wska­zu­ją, że zła jakość wyma­gań gene­ru­je dodat­ko­we kosz­ty rzę­du 60% war­to­ści pro­jek­tu, koszt takiej ana­li­zy nie prze­kra­cza zaś 20%). Do tego poja­wia­ją się poten­cjal­ne kosz­ty nie­ujaw­nio­ne klien­to­wi: pra­wa autor­skie do pro­jek­tu i apli­ka­cji. Jeżeli fir­ma będą­ca wyko­naw­ca opro­gra­mo­wa­nia robi ana­li­zę swo­je­go klien­ta i potem mu sprze­da­je pra­wa do jej wyni­ków wraz z dostar­cza­nym opro­gra­mo­wa­niem, to jest to kla­sycz­ny przy­pa­dek aneg­do­ty o kon­sul­tan­tach, któ­rzy zapy­ta­ni o to któ­ra jest godzi­na, pro­szą Cie o Twój zega­rek, odpo­wia­da­ją na pyta­nie któ­ra godzi­na i wysta­wia­ją fak­tu­rę za usłu­gę i tak­że za zwra­ca­ny Ci Twój zegarek.

Czytaj dalej Proces zbierania i analizy wymagań u developera
Ach ten opluty wodospad… czyli lessons learned ERP

Ach ten opluty wodospad… czyli lessons learned ERP

Opisane tu podej­ście czę­sto nazy­wa­ne jest ​„kaska­do­wym” (water­fall – wodo­spad). Jest ono dość czę­sto wska­zy­wa­ne jako powód pora­żek pro­jek­tów, ale moim zda­niem jest to pew­na dema­go­gia, gdyż tak na praw­dę przy­czy­ną więk­szo­ści pro­ble­mów jest nie tyle ​„wodo­spa­do­we” podej­ście, ono jak widać z powy­żej opi­sa­ne­go pro­ce­su, ma głę­bo­ki sens, co wzię­cie sobie na bar­ki pro­jek­tu (zawar­cie umo­wy z dostaw­ca na trzy lata to przy­ję­cie w dniu jej zawar­cia har­mo­no­gra­mu łamią­ce­go opi­sa­na powy­żej zasa­dę) na lata zanie­dbu­jąc zupeł­nie fakt, że oto­cze­nie ryn­ko­we obec­nie zmie­nia się nawet co kwartał.

Mamy więc kurio­zal­ne zesta­wie­nie: pod­ję­cie pro­jek­tu od razu od ostat­nie­go eta­pu (wybór dosta­wy, pro­duk­tu i reali­za­cja) i zapla­no­wa­nie go od razu na np. trzy lata. To pro­jekt w rodza­ju ​„nie wiem co tu jest gra­ne ale kupu­je­my [ten sys­tem] i wdra­ża­my go”. To nie ma pra­wa się udać… 

A nasze ​„les­sons lear­ned”? No wła­śnie, zna­ne mi pro­jek­ty zakoń­czo­ne kło­po­ta­mi, to wła­śnie pro­jek­ty na skró­ty. Projektu pro­wa­dzo­ne w myśl powyż­szych zasad (krót­kie i dobrze zapla­no­wa­ne eta­py) są znacz­nie bar­dziej odpor­ne na kłopoty. 

Czytaj dalej Ach ten opluty wodospad… czyli lessons learned ERP
Znajomość branży klienta szkodzi a nie pomaga…

Znajomość branży klienta szkodzi a nie pomaga…

Jakie doświad­cze­nie i gdzie jest potrzebne
I teraz pyta­nie jakie archi­tekt budow­la­ny musi mieć doświad­cze­nie, jeże­li chce zapro­jek­to­wać most? Wypadało by nie był to jego pierw­szy most, ale czy musi znać mia­sto, w któ­rym ten most powsta­nie? Czy musi mieć ​„doświad­cze­nie kole­jo­we” dla­te­go, że to most kole­jo­wy? Raczej nie, powi­nien mieć doświad­cze­nie w pro­jek­to­wa­niu mostów. 

Dlatego ktoś, kto ma rolę ana­li­ty­ka i pro­jek­tan­ta w pro­jek­cie, powi­nien mieć bar­dzo duże doświad­cze­nie w ana­li­zie i pro­jek­to­wa­niu, ale zna­jo­mość kon­kret­nej bran­ży nie wno­si tu żad­nej war­to­ści doda­nej, a bio­rąc pod uwa­gę fakt, że ruty­na zabi­ja, potra­fi być wręcz szkodliwe. 

Jeżeli to zama­wia­ją­cy ocze­ku­je ana­li­ty­ka z doświad­cze­niem w swo­jej bran­ży, nie raz kie­ru­je się on przy­pusz­cze­niem, że to uła­twi komu­ni­ka­cję z nim. Jednak pro­blem tkwi nie w zna­jo­mo­ści bran­ży a w komu­ni­ka­tyw­no­ści ogól­nie. Analityk powi­nien się cecho­wać bar­dzo dobry­mi zdol­no­ścia­mi komu­ni­ka­cyj­ny­mi a nie zna­jo­mo­ścią kon­kret­nej bran­ży (wte­dy raczej ryzy­ku­je popad­nie­cie w slang bran­żo­wy, co raczej prze­szka­dza niż pomaga).

Z per­spek­ty­wy dostaw­cy roz­wią­zań, popu­la­ry­zu­ją­ce­go tezę, że ​„on jest lep­szy bo ma wie­dzę z danej bran­ży”, jest to raczej pró­ba stwo­rze­nia sztucz­nej barie­ry wej­ścia dla kon­ku­ren­tów, bo z wyżej opi­sa­nych powo­dów trud­no o inne uza­sad­nie­nie… Zwróćmy uwa­gę, na to, że fir­ma­mi, poza nie­licz­ny­mi wyjąt­ka­mi, zarzą­dza­ją spe­cja­li­ści od zarzą­dza­nia. Branża ich doświad­czeń ma tu dru­go­rzęd­ne zna­cze­nie bo kon­kret­ny rynek musi znać dyr. mar­ke­tin­gu a nie pre­zes fir­my, ten dru­gi musi się umieć z tym pierw­szym doga­dy­wać. Inżynierowie dzie­dzi­no­wi w roli pre­ze­sów, Ci czę­ściej dopro­wa­dza­ją swo­je fir­my do upadku… 

Czytaj dalej Znajomość branży klienta szkodzi a nie pomaga…
Sprzedam Ci prawa do kodu czyli wielka ściema

Sprzedam Ci prawa do kodu czyli wielka ściema

A może chce­cie pra­wa do kodu źródłowego?

A jasne, może­my chcieć. ​„No to zapłać­cie za to pra­wo”. A prze­pra­szam za co teraz? Kod, któ­ry powstał to utwór zależ­ny, jest więc chro­nio­ny i już mamy na nie­go wyłącz­ność, nie musi­my eks­tra za to pła­cić. Ale nie chce­my tego sami pisać (kodo­wać) jesz­cze raz. No dobrze, patrzy­my na fak­tu­ry, a tam jest kil­ka­set godzin pro­gra­mi­stów. Czyli co? Już zapła­ci­li­śmy za ich pra­cę, za ten kod! Wystarczy!

Kiedy poja­wia się problem?

W więk­szo­ści przy­pad­ków z jaki­mi się nie­ste­ty spo­ty­kam to pro­jek­ty, w któ­rych nie powsta­ła opi­sa­na tu doku­men­ta­cja. Jaki mamy efekt? No jest kod, wszel­kie pra­wa do nie­go i jego logi­ki ma wyko­naw­ca (jest auto­rem cało­ści). Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych pod­le­ga wyłącz­nie ochro­nie jako dzie­ło lite­rac­kie, jed­nak nie­ste­ty to-co-pro­gram-ma-robić to tyl­ko idea, a ta nie pod­le­ga ochro­nie (stwier­dze­nie fak­tu, że wysta­wia­my fak­tu­ry, jako treść, nie sta­no­wi żad­ne­go zdat­ne­go do ochro­ny tajem­ni­cą fir­my know-how). Tak więc wszel­kie pra­wa do kodu ma w takim wypad­ku pro­gra­mi­sta bo sam od zera to napi­sał (kod).

Pada pro­po­zy­cja: za dodat­ko­we pie­nią­dze sprze­da­my pra­wa mająt­ko­we do kodu, będzie­cie się Państwo czu­li bez­piecz­nie. I teraz pyta­nie: jaką war­tość ma nie­udo­ku­men­to­wa­ny kod opro­gra­mo­wa­nia? Tysiące linii kodu pro­gra­mu, nie raz kil­ka milio­nów, pisa­ny bez pro­jek­tu w wie­lu ite­ra­cjach. Mamy któ­rąś tam jego wer­sję, w koń­cu powsta­wał w bólach, wie­lo­krot­nie mody­fi­ko­wa­ny, bez pro­jek­tu. Nakład pra­cy znacz­nie prze­wyż­sza­ją­cy jego prze­pi­sa­nie. Kto i jakim kosz­tem będzie ten kod ana­li­zo­wał by go zro­zu­mieć i roz­wi­jać? Ten kod, bez jego auto­ra, jest BEZWARTOŚCIOWY a My, bez tej opła­ty, nie mamy żad­nych praw do tego za co zapła­ci­li­śmy (poza licen­cją czy­li pra­wem do korzystania).

Tak więc nie­jed­no­krot­nie ofer­ta na sprze­daż praw do kodu to zwy­kła ściema!

Czytaj dalej Sprzedam Ci prawa do kodu czyli wielka ściema
Procesy biznesowe lepiej z regułami biznesowymi i zasobami

Procesy biznesowe lepiej z regułami biznesowymi i zasobami

W wie­lu fir­mach sys­tem zarzą­dza­nia jest tak nie­spój­ny, że jedy­nym spo­so­bem funk­cjo­no­wa­nia tych firm, jest łama­nie zasad przez jej pra­cow­ni­ków. Niestety pierw­sza wpad­ka czę­sto powo­du­je zała­ma­nie się całe­go sys­te­mu (a nie raz i fir­my). Wiele Zarządów firm nie zda­je sobie nawet spra­wy z tego, jak duże jest ryzy­ko cią­gło­ści funk­cjo­no­wa­nia ich firm. 

Tak więc model pro­ce­su to nie algo­rytm dzia­ła­nia fir­my, wyka­za­no nie raz, że algo­ryt­mi­za­cja pra­cy ludzi jest nie­ce­lo­wa (wte­dy sto­su­je­my roboty).

Znaczna część tego co robią ludzie to efekt ich kom­pe­ten­cji, wie­dzy i doświad­cze­nia, a nie dyk­to­wa­nia im jak mają wyko­ny­wać swo­ja pracę.

Jeżeli wybie­rze­my dro­gę mode­lo­wa­nia tego wszyst­kie­go dia­gra­ma­mi, to ilość tych dia­gra­mów szyb­ko prze­kro­czy gra­ni­cę sen­sy całe­go pro­jek­tu: nie będą czy­ta­ne. Ich war­tość będzie żadna.

W pro­ce­sie dobrze przy­go­to­wa­nej ana­li­zy (jakiej­kol­wiek) mode­le two­rzy się by je badać, a nie tyl­ko po to by powsta­ły za pie­nią­dze spon­so­ra projektu.

Należy też nabrać poko­ry: więk­szość orga­ni­za­cji spraw­nie funk­cjo­nu­je nie mając żad­nych mode­li pro­ce­sów, więc teza, że ich brak szko­dzi jest nie do obro­ny. Po co więc te mode­le? Żeby zro­zu­mieć dla­cze­go tak jest i co się sta­nie, gdy zechce­my wpro­wa­dzać zmiany.

Czytaj dalej Procesy biznesowe lepiej z regułami biznesowymi i zasobami
Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

Analiza biz­ne­so­wa obej­mu­je wyłącz­nie obszar stra­te­gii i pro­ce­sów biz­ne­so­wych. Wdrożenie poprze­dza­ne jest ana­li­zą całej orga­ni­za­cji, wydzie­le­nie w niej nie­za­leż­nych obsza­rów dzie­dzi­no­wych (np. rachun­ko­wość, zarzą­dza­nie pro­ce­sa­mi pra­cy, zarzą­dza­nie wie­dzą, por­tal klien­ta, zarzą­dza­nie i ste­ro­wa­nie pro­duk­cją, zarzą­dza­nie pro­ce­sem sprze­da­ży, inne).

Każdy obszar cechu­je się tymi trze­ma pozio­ma­mi: stra­te­gia, pro­ce­sy, reali­za­cja. Na eta­pie ana­li­zy potrzeb pro­wa­dzi­my audyt i mode­lo­wa­nie pro­ce­sów. Zakładamy, że szcze­gó­ły tego ?jak pra­cu­je­my? i tak ule­gną zmia­nie po wdro­że­niu nowe­go narzę­dzia pra­cy, więc pomi­ja­my je na tym eta­pie (zosta­ną okre­ślo­ne pod­czas wdro­że­nia). Jeżeli ana­li­za wyka­że, że ist­nie­je obszar nie­stan­dar­do­wy w orga­ni­za­cji, tyl­ko dla tego obsza­ru pro­wa­dzi się szcze­gó­ło­wą ana­li­zę, gdyż w tym obsza­rze będzie (naj­praw­do­po­dob­niej) wdra­ża­ne roz­wią­za­nie dedykowane.

Tak więc zin­te­gro­wa­ny sys­tem ERP II nie musi ozna­czać ​„jed­no roz­wią­za­nie od jed­ne­go dostaw­cy”. Po pierw­sze trud­no jest szcze­gó­ło­wo wyspe­cy­fi­ko­wać taki sys­tem, po dru­gie nie raz oka­zu­je się, ze ​„sys­te­my od wszyst­kie­go są do niczego”…

Czytaj dalej Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru
Business Rule Concepts – czyli jak <span class="push-double"></span>​<span class="pull-double">„</span>wyłuskać istotę rzeczy”

Business Rule Concepts – czyli jak ​„wyłuskać istotę rzeczy”

Gorąco pole­cam dwie książ­ki autor­stwa Ronalda G. Ross’a, ich okład­ki tu widzi­cie. Wydane zosta­ły przez Business Rule Solutions, LLC. Pierwsza sku­pia się na regu­łach biz­ne­so­wych jako kon­cep­cji. Metody i sys­tem poję­cio­wy w niej opi­sa­ny zna­la­zły się na liście otwar­tych stan­dar­dów OMG jako SBVR. W ubie­głym roku uka­za­ło się już trze­cie wyda­nie tej książki.

Druga to pozy­cja nowa, cało­ścio­wo opi­su­ją­ca podej­ście pole­ga­ją­ca na mode­lo­wa­niu orga­ni­za­cji w ana­li­zie biz­ne­so­wej (zawie­ra część mate­ria­łu pierw­szej) . Zwraca uwa­gę na fakt, że nie cho­dzi w ana­li­zie o two­rze­nie mnó­stwa dia­gra­mów a o to, by zro­zu­mieć jak orga­ni­za­cja funk­cjo­nu­je opi­su­jąc to, oraz stwo­rzyć model, któ­ry pozwo­li na pro­gno­zo­wa­nie zacho­wa­nia orga­ni­za­cji w odpo­wie­dzi na bodź­ce, nawet te któ­re jesz­cze nie zaist­nia­ły. Prognoza? A jak Państwo chce­cie oce­nić ryzy­ko i skut­ki utra­ty człon­ka zarzą­du (np. zła­mał nogę na nar­tach…;)) lub jed­ne­go z klu­czo­wych dyrek­to­rów? Jak chce­cie oce­nić skut­ki i ryzy­ko wdro­że­nia nowe­go sys­te­mu sys­te­mu ERP?

Da się… ale model orga­ni­za­cji to nie traw­nik boiska z wydep­ta­ny­mi ścież­ka­mi, bo trwa rośnie a kolej­ne roz­gryw­ki to nowe ścież­ki, nie nary­su­je­my wszyst­kich moż­li­wych! Model to regu­ły gry w pił­kę noż­ną, umie­jęt­no­ści poszcze­gól­nych pił­ka­rzy, gra­ni­ce boiska, obie poło­wy, pola kar­ne i bram­ki. To decy­du­je o tym ja wyglą­da gra. Co jest waż­ne? Odkryć i jed­no­znacz­nie udo­ku­men­to­wać for­mal­ne zasady.

Czytaj dalej Business Rule Concepts – czyli jak ​„wyłuskać istotę rzeczy”