Zeleno projektno vodenje

V knjigi Green Project Management avtorja Richard Maltzman in David Shirley ugotavljata, da so projektni vodje že po naravi svojega dela zeleni, saj se nenehno trudijo zmanjšati stroške, povečati poslovno vrednost in zaščititi dragocene vire. Vse to prispeva k zelenosti. Ker se podjetja vedno bolj zavedajo pomena zelenega poslovanja, je smiselno, da to vključimo tudi v projektno vodenje.

Avtorja uvedeta nov pojem, ki označuje, v kolikšni meri je projekt zelen in sicer temu pravita zelenost (angl. greenality). Ima podoben pomen kakor kakovost (angl. quality), kar pomeni, da jo lahko izmerimo, nanaša pa se na samo izvedbo projekta kakor tudi na končni izdelek projekta. Podobno kakor plan za obvladovanje kakovosti projekta avtorja predlagata, da bi lahko uvedli plan za obvladovanje zelenosti projekta in sta celo predlagala, da bi ga uvedli v naslednji izdaji Vodnika po znanju projektnega vodenja (PMBOK).

Analogijo zelenosti in kakovosti povedeta še dalje tako, da uvedeta pojem strošek zelenosti, ki ima podoben pomen kakor strošek kakovosti. Namreč, zelenost projekta je povezana s stroški, ki so lahko stroški izobraževanja o zavedanju zelenosti vseh vpletenih v projekt, definiciji ciljev povezanih z ohranjenjem okolja in trajnostjo virov, stroški dela pri nadzoru in spremljanju zelenosti projekta, nenazadnje pa tudi stroški, ki nastanejo z nedoseganjem ciljev zelenosti, na primer davek na emisije ogljikovega dioksida ali kazni zaradi neupoštevanja predpisov, povezanih z zelenostjo.

Čeprav naslov knjige obljublja zeleno projektno vodenje, je pravzaprav večina vsebine posvečena razpravi o zelenih izdelkih projektov oziroma o projektih, katerih namen je ustvariti bolj zelene cilje. To je sicer zanimivo branje, a vendarle bi v knjigi pričakovali mnogo več konkretne vsebine, povezane s samim projektnim vodenjem. To avtorja navajata v minimalnem obsegu glede na preostalo vsebino in sicer:

• osveščanje vseh udeležencev projekta o ciljih in zavezanosti zelenosti;
• zmanjšanju količine porabljenega papirja in nadomeščanju z elektronskimi viri;
• bolj zeleno informacijsko središče, na primer z virtualizacijo, kjer so nameščena programska orodja za podporo projektnemu vodenju;
• zmanjšanje števila potovanj članov projektne skupine in nadomestitev komunikacije v obliki osebnih obiskov z orodji za skupinsko delo;
• izbira zelenih dobaviteljev, kjer je to mogoče in kjer ima projektni vodja vpliv.

Morda se v knjigi prevečkrat pojavi teza o zmanjševanju količine porabljenega papirja in zmanjšanju števila potovanj, kar bi na koncu lahko zreducirali kot njeno poglavitno sporočilo.

Sorodni članki

• Green Project Management: How to Get Your Company to Accept the Cost of Going Green (usgreentechnology.com)
• From the Singapore Grand Prix, and Marina Bay Sands Integrated Resort in Singapore; to the Ritz Carlton in Dubai Chairman of Confluence, John Taylor talks about some of the challenges and successes in delivering high profile projects around the globe (thempreport.com.au)
• Green Project Management (amazon.com)

Ali je računalništvo zrelo za zdravstvo?

Ob prebiranju zanimivega članka o tem, kako bi lahko s pomočjo računalniškega modela izbrali ustrezna zdravila za zdravljenje pacientov, sem se najprej vprašala, ali je računalništvo dovolj zrelo in zanesljivo, da bi ga lahko uporabili v zdravstvu?

Moji pomisleki izvirajo iz zgodb o težavah v informacijskih sistemih, recimo tisti, o kateri sem pisala v prejšnjem prispevku, kjer pogrešajo 150 milijonov evrov. Kaj pa, če težave v informacijskem sistemu ne povzročijo izgube velikih količin denarja, ampak odločajo o zdravju oziroma o človeških življenjih? V takem primeru bi bilo težje zamahniti z roko, češ saj z vpeljavo informacijskih sistemov so itak vedno težave.

Ob predpostavki, da bi bile informacijske rešitve zanesljive in dobro preverjene, bi vsekakor prispevale k učinkovitejšemu zdravstvu. Za začetek bi lahko bolje podprli vse administrativne procese, kar je verjetno manj kritičen del informacijskega sistema, vsaj v smislu vpliva na človeška življenja. Na srečo se v zadnjih letih tu stvari spreminjajo na bolje in s podpisom pogodbe za nadaljevanje projekta eZdravje lahko računamo, da bo informacijska podpora poslovnim procesom v zdravstvu v prihodnosti še boljša.

Drug vidik pa je informacijska podpora samim postopkom zdravljenja. Eden takih primerov je v uvodu omenjen članek, kjer s pomočjo množice podatkov o zdravljenju pacientov z določeno boleznijo izdelajo računalniški model, ki pomaga izbrati ustrezno zdravilo. Če bi tovrstne procese podprli z informacijsko podporo, bi to lahko prineslo več koristi:

• pomagalo bi zdravnikom pri odločitvi o ustreznem zdravljenju, saj si ti verjetno ne zapomnijo vseh podatkov o vseh zdravljenjih iz preteklosti in je zato zapis v informacijskem sistemu njim v pomoč pri osvežitvi spomina;
• na enem mestu bi lahko zbrali izkušnje več zdravnikov in zdravstvenih ustanov, kar bi povečalo nabor podatkov in izboljšalo njihovo kakovost;
• prihranilo bi čas pri zdravljenju, saj bi že informacijska rešitev predlagala ustrezno zdravilo, tako da zdravnikom ne bi bilo treba brskati za informacijami.

Kot računalničar se seveda najbolj bojim, da bi se tovrstnih informacijskih rešitev tudi v zdravstvu lotevali na preveč lagoden način. Recimo tako, kakor ekipa, ki je izvajala projekt, po katerem se je izgubilo 15 milijonov evrov, ker so pač bile težave z informacijskim sistemom. In bi pacientu predpisali napačno zdravilo, saj z uvajanjem informacijskih sistemov so itak vedno težave. Za rešitve v zdravstvu bi računalničarji morali malo bolj pljuniti v roke in predvsem in zlasti rešitve temeljito testirati in preveriti.

Res pa je, da ni izpostavljeno le računalništvo, saj se v zdravstvu lahko dogajajo tudi administrativne napake, spomnimo se primera izpred nekaj let, ko je pred vrati urgence umrl moški, ki ni imel napotnice. Je že tako, da ko gre za človeška življenja, ni opravičila za površnost.

Sorodni članki

• Using Decision Trees in Evidence Based Medicine (datasciencecentral.com)
• The Data Scientist Will Be Replaced By Tools (forbes.com)
• Kam je šlo 150 milijonov evrov (itvcerajdanesjutri.wordpress.com)

Kam je šlo 150 milijonov evrov

Ko sem prebrala naslov članka Vlada menda pogreša 150 milijonov evrov s podnaslovom »V zakladnici manjkajoči znesek naj bi bil zaradi težav z informacijskim sistemom Dursa na računu Zpiza in ZZZS«, sem najprej avtomatično pomislila: seveda, težave z informacijskim sistemom, zakaj se sploh čudijo.

Ker delam na področju IT, me je takoj prešinilo, ali imam res tako malo zaupanja v informacijsko tehnologijo? In sem se dalje spraševala, zakaj je temu tako?

No, dan po omenjenem članku je bilo objavljeno nadaljevanje, v katerem je med drugim citat tiskovnega predstavnika Dursa: »Pri prenovi vsakega, še zlasti pa tako obsežnega sistema so težave, kar je logično.«

Tako torej, vpeljava informacijskega sistema bi naj bila sinonim za težave. Ampak ali res mora biti tako? Ali ne znamo ali zmoremo bolje?

Nikakor ne želim ugibati o podrobnostih izvedbe omenjenega informacijskega sistema, saj o njem prav nič ne vem. Glede na moje izkušnje pri podobnih informacijskih rešitvah, pa lahko ugibam o dejavnikih, ki so morda pripeljali do težav:

Izbira najcenejšega ponudnika, pa naj »stane kolikor hoče«. Zaradi kriterija, da naročnik izbere najcenejšega ponudnika, mora tisti, ki želi biti izbran, ponuditi čim bolj nizko ceno. Mnogokrat se izkaže, da je ta cena prenizka, da bi pokrila kvalitetno izvedbo projekta, zato se potem ta izvaja bolj površno ali z manj izkušenimi (cenejšimi) ljudmi, ali pa se izpuščajo pomembni koraki pri izvedbi (npr. testiranje, uvajanje).

Vztrajanje pri tradicionalnih metodah izvedbe projekta. Naročniki projektov največkrat zahtevajo tradicionalni fazni pristop k izvedbi projekta, pri katerem je najprej treba izdelati podrobne specifikacije, potem izvesti projekt, na koncu testirati in ga vpeljati v obratovanje. Vemo, da so specifikacije odvisne od ljudi, ki jih pripravijo, kar pomeni, da so ti lahko kaj pozabili, izpustili, se zmotili, narobe si predstavljali, kako bo to izgledalo v končni rešitvi in tako dalje. To pa pomeni, da če se izvedba informacijske rešitve nadaljuje na osnovi netočnih specifikacij, končna rešitev seveda ne bo optimalna.

Premalo pozornosti temu, kaj naročnik resnično potrebuje. Preveč projektov informacijskih sistemov poteka po zbirokratiziranih pravilih, kjer se na projektnih sestankih kljukajo opravljene naloge in potrjujejo vmesni cilji. To se dogaja v sejnih sobah, daleč od razvijalcev in morebitnih demonstracij rešitve. Običajno gre na začetku projekta vse odlično. Seveda, saj se pripravlja dokument uporabniških zahtev, v obliki veliko strani nekega papirja in vsi se trepljajo, glej, koliko dokumentacije smo napisali! Kasneje, ko gre projekt v izvedbo, je stanje projekta tudi še kar v redu, saj se pač nekaj programira in tu se tudi lahko lepo kljuka, katere naloge so dokončane. Na koncu, ko gre vse skupaj v izvedbo, se šele pokaže, kaj vse je pomanjkljivo, narobe razumljeno, napačno narejeno, nedokončano ali narejeno preveč mehansko, dobesedno, brez posvečanja pozornosti dejanski uporabnosti rešitve.

Pomanjkanje časa za temeljito testiranje. Po mojih izkušnjah je testiranje tisti korak, ki se največkrat izpusti pri implementaciji informacijskih sistemov. Zakaj? Morda zato, ker se programerjem ne ljubi testirati svojih lastnih programov ali ker verjamejo, da itak niso naredili napak (neverjetno, koliko takih poznam!), ali pa zato, ker vodje projektov ne preverjajo kakovosti končnih izdelkov. Preveč vodij projektov namreč le odkljuka, da je določena naloga dokončana, ne spuščajo pa se v podrobnosti, kako je izvedena. Nenazadnje pa se testiranje izpušča tudi zato, ker informacijski projekti tako radi zamujajo, da na koncu zmanjka časa in denarja za testiranje in se ta korak naredi prepovršno.

Vnaprejšnje prepričanje, da IT sistemi itak ne delajo brez napak. Na žalost smo že vnaprej vdani v usodo, da bo imela uvedba informacijskega sistema kup težav, pa se zato niti ne potrudimo, da bi poskusili težave preprečiti. Jih bomo že odpravili kasneje, ko bo sistem v produkciji, če bo treba.

Zato me sploh ne preseneča, da je nekam izginilo 150 milijonov evrov. In prepričana sem, da jih bodo našli, če se bo le nekdo lotil pregledati informacijski sistem in ugotoviti, kam so se po pomoti preknjižili. Pri tem sploh ni pomembno, ali je pomota nastala zaradi napačnih specifikacij uporabnikov ali zaradi napačnega razumevanja razvijalcev ali zaradi človeške napake. Zavedati se moramo, da so tovrstne napake vedno možne in jih zato moramo znati in hoteti odpraviti prej, preden gre rešitev v produkcijo.

Sorodni članki

• Vlada menda pogreša 150 milijonov evrov (dnevnik.si)
• Milijoni niso izginili, so pa morda na napačnem naslovu (dnevnik.si)
• Informacijski projekti so uspešnejši (itvcerajdanesjutri.wordpress.com)

Z zelenim poslovnim obveščanjem in zelenim projektnim vodenjem do zelenega poslovanja

Kaj pravzaprav pomeni, biti zelen? Ali to, da recikliramo odpadke? Da živimo na okolju prijazen način? Da zmanjšamo porabo papirja v tiskalnikih? Da kupimo avto, ki porabi manj oziroma bolj okolju prijazno gorivo? Da zmanjšamo porabo elektrike v IT? Da podjetje posluje tako, da se zaveda trajnosti zemeljskih virov? Verjetno zeleno pomeni različne stvari različnim ljudem. Ali pa pomeni kar vse zgoraj našteto in še kaj.

Če se osredotočimo na okolju prijazno poslovanje podjetja, se poslovno obveščanje lahko izkoristi na več načinov. Lahko ga uporabimo v prvotnem pomenu in sicer za analizo podatkov, na primer tako, da iščemo možnosti optimizacije procesov, spremljamo količine odpadnih snovi in iščemo načine, da jih zmanjšamo, izboljšamo učinkovitost procesov – vse z namenom, da bi delovali bolj okolju prijazno. Mnogokrat se izkaže, da je bolj učinkovit in okolju prijazen proces tudi cenejši, saj racionalneje izkorišča vire. S poslovnim obveščanjem, ki temelji na ustreznih podatkih, podjetje dobi celovit pregled nad procesi in jih zato lahko podrobno analizira, nadzira, spremlja in prilagaja.

Razen poslovnih procesov podjetja optimizirajo tudi IT centre, da bi ti porabili manj energije in oddali čim manj okolju neprijaznih snovi. Tudi tu lahko izkoristimo poslovno obveščanje za razne analize izkoriščenosti virov, iskanja optimizacije in konsolidacije. Nenazadnje lahko optimiziramo tudi sam sistem za poslovno obveščanje, tako da čim bolj optimalno hranimo podatke, jih učinkoviteje procesiramo in porabimo čim manj virov za delovanje.

In za konec lahko nad vsem tem bdi zeleno projektno vodenje, katerega smisel je izvajati projekte tako, da se ves čas zavedamo trajnosti virov in delujemo na čim bolj okolju prijazen način. Ne le, da je vsebina projekta, ki ga izvajamo, zasnovana zeleno, tudi samo projektno vodenje lahko izvajamo na zelen način, na primer tako, da zmanjšamo število potovanj, uporabimo čim manj papirja, oziroma čim bolj učinkovito izkoristimo čas in sredstva, ki so na voljo.

Sorodni članki

• Business Sustainability and Carbon Footprint Reduction Management via Dashboard-Based Business Intelligence (dashboardinsight.com)
• Sustainability Management (sas.com)
• Poslovni procesi in poslovno obveščanje (itvcerajdanesjutri.com)

Zgodba o uspehu: Skrajšanje sodnih zaostankov s podatkovnim skladiščem

Vedno se razveselim, kadar slišim kakšno resnično zgodbo o uspehu v zvezi s podatkovnim skladiščem in poslovnim obveščanjem. Tokrat je v ospredju Vrhovno sodišče RS, ki jim je uspelo s pomočjo poslovnega obveščanja skrajšati sodne zaostanke. Ozadje projekta in rezultate so objavili v obliki filmčka na omrežju YouTube.

Čeprav gre za izdelavo podatkovnega skladišča, je obseg projekta pravzaprav širši, saj so razen samega zbiranja vseh potrebnih podatkov v podatkovni zbirki tudi poskrbeli za informatizacijo poslovnega procesa. Pred uvedbo podatkovnega skladišča so namreč podatke prepisovali, seštevali in obdelovali ročno, sedaj pa gre vse avtomatizirano, kar seveda pomeni, da proces poročanja poteka mnogo hitreje, podatki pa so na voljo prej.

Razen samega podatkovnega skladišča in rednega statističnega poročanja so naredili tudi nadzorne plošče, ki so namenjene vodstvu in iz katerih je na prvi pogled razvidno, kakšno je stanje zadev, ki se obravnavajo na sodiščih. Tako dobi vodstvo vpogled v podatke, na osnovi katerih lahko ustrezno ukrepa. Na primer, optimizirajo lahko reševanje različnih vrst zadev, tako da prerazporedijo zaposlene ljudi iz sodišč, kjer je določena vrsta zadeve manj zastopana, na druga sodišča, kjer je tovrstnih zadev več, kar seveda pripomore k povečanju števila rešenih zadev in posledično skrajšanju sodnih zaostankov.

Čeprav morda že malo prežvečeno, tokrat lahko resnično ugotovimo, da prave informacije pravim ljudem ob pravem času omogočajo, da sprejemajo ustrezne poslovne odločitve takrat, ko je to najbolj potrebno.

Sorodni članki

• Judicial Data Warehouse and Performance Dashboards – Slovenia (youtube.com)
• Vrhovno sodišče v 2011 za petino zmanjšalo število nerešenih zadev (sodisce.si)
• Ideal o samopostrežnem poslovnem obveščanju (itvcerajdanesjutri.wordpress.com)

Kako zares upravljamo tveganja?

Koliko let že poslušamo o svetovni finančni krizi? Zakaj že je do nje sploh prišlo? Zakaj je ekonomisti niso predvideli, saj vendar toliko pozornosti posvetijo upravljanju tveganj? Govori se sicer, da so nekateri vedeli, kaj se bo zgodilo, ampak iz takih ali drugačnih razlogov tega niso povedali. Ali pa so vedeli, a so preprosto ignorirali oziroma niso hoteli verjeti. Eden možnih scenarijev je prikazan v filmu Margin Call, ki obravnava noč v neki investicijski banki pred izbruhom krize.

No, karkoli že je bilo, zdaj je lahko biti pameten za nazaj. Morda se res ni vedelo, kaj bo, ker ekonomisti niso imeli pravih modelov, s katerimi bi lahko napovedali dogajanja v prihodnosti. Modeli, ki temeljijo na zgodovinskih trendih, ne morejo kar preprosto napovedati prihodnosti. Kaj pa, če se zgodi nekaj nepričakovanega? Zanimiv tak primer, ki ga omenja avtor Nassim Nicholas Taleb v knjigi The Black Swan je pitanje purana, ki se lepo debeli in raste iz dneva v dan … dokler ne pride ameriški praznik Zahvalni dan, ko tega purana naenkrat ni več. Nobena interpolacija v prihodnost ne bo pomagala, puran se ne bo več redil, ko enkrat konča v pečici.

Pa pustimo ekonomijo in finančno krizo ob strani in se vprašajmo, ali smo informatiki kaj boljši pri upravljanju tveganj? No, tudi v informatiki se dogajajo nepričakovane krize, vdori, izpadi in podobno. Med odmevnimi v zadnjem času je bil vdor v družabno omrežje LinkedIn. Kaj se lahko naučimo iz tega? Ali smo poskrbeli za vse potrebno, da se v našem podjetju ne primeri kaj podobnega?

Čeprav se vsi zavedamo, da je treba upravljati tveganja, na primer tako, da poskrbimo za informacijsko varnost, se še vedno prepogosto dogaja, da nanjo malo pozabimo, da nam je odveč ali se nam zdi strošek prevelik. Najbolj banalni primer je verjetno varnostno kopiranje. Kdaj ste nazadnje napravili varnostno kopijo podatkov na svojem računalniku? Ali jo boste? Ali pa se boste zavedali, da jo morate, šele takrat, ko vam bodo ukradli prenosnik ali ko se vam bo pokvaril disk? Razum pa vendarle pravi, da je treba investirati v to, da lahko mirno spimo, da je poskrbljeno za varnost.

Še en primer, na katerega na svojo veliko grozo naletim kar prevečkrat v sodobnem času, je, da se vsi uporabniki prijavijo v sistem kot administrator in potem imajo vsi vse pravice delati karkoli. Da je tako, je morda zato, ker nihče ni postavil pravil uporabe, definiral pravic uporabnikov in ustrezno omejil dostopov,češ, saj je vseeno. Morda pa je ravno nasprotno, in sicer tako, da je nekdo pripravil tako zapleten sistem dodeljevanja pravic dostopov, da ga nihče ne razume, da ga je težko uporabljati, da imajo uporabniki tako omejene pravice, da ne morejo opravljati svojega rednega dela. Potem ti ali ne morejo delati, ali pa jim pač nekdo pove administratorsko geslo, zato da se mu ni treba ukvarjati s tem, zakaj neka pravica ne deluje. In kaj je potemtakem s tako restriktivnim sistemom pravic dosegel, če na koncu vendarle pove administratorsko geslo? Zadeva z delom pod administratorskim računom gre seveda naprej toliko časa, dokler eden od uporabnikov po pomoti ne pokvari ali pobriše nekaj pomembnega, ali zasede kapacitete sistema, kar ima za posledico, da večje število ljudi ne more delat, ali, da onemogoči delo končnim uporabnikom. In to vse samo zato, ker si nekdo zatiska oči pred tem, da je treba imeti red. Žalostno, toda resnično.

Primerov je še več, prepričana sem, da če dobro premislite, lahko najdete kakega tudi v svojem okolju. Tako kakor v začetku omenjena ekonomija, ki ima svoja pravila upravljanja tveganj, in za katera vemo, da ne delujejo vedno, imamo črno piko tudi v informatiki, saj vemo, kako bi morali imeti zadeve urejene, pa tega ne počnemo dosledno.

Sorodni članki

• LinkedIn Breach: Leading CISOs Share 9 Protection Tips (informationweek.com)
• Nassim Nicholas Taleb – What is a “Black Swan?” (youtube.com)
• Risk Mismanagement (nytimes.com)

Kratek pogovor v dvigalu

Skoraj istočasno sta mi prišla pod roke dva različna članka iz različnih vetrov, oba povezana s temo »elevator pitch«. Lepega slovenskega prevoda tega izraza nimamo, nekje v spletu sem našla prevod »kratka predstavitev poslovne ideje«, kar bi lahko bilo to, če govorimo o poslovnih idejah. Sicer pa se taka kratka predstavitev uporablja tudi v drugih kontekstih, na primer pri projektih, ki jih izvajamo, pri prodaji raznih izdelkov in storitev, pri iskanju možnosti za napredovanje v službi in tako naprej. Pri taki kratki predstavitvi gre za to, da moramo imeti vedno pripravljen kratek in jedrnat govor o bistvu in smislu tistega kar delamo oziroma kar ponujamo. To pa zato, da se ne zmedemo, če recimo v dvigalu slučajno srečamo zelo vplivno osebnost, kar nam da priložnost, da ji v kake pol minute, dokler traja vožnja, zrecitiramo tisto, kar jo bo navdušilo. Sicer ni nujno, da mora biti srečanje ravno v dvigalu, situacija se nam lahko ponudi tudi recimo v prostem času ali pa na kakšnem poslovnem dogodku.

Prvi članek, ki mi je prišel pod roke, je bil eden izmed množice tistih, ki nas prepričujejo, da moramo imeti vedno pripravljen tak govor, da z njim sklenemo prodajo ali si zagotovimo sredstva za zagon poslovne ideje ali projekta. Drug članek pa je eden izmed tistih, ki pravijo, da je tak »elevator pitch« le mit. Raziskave so pokazale, da zaradi kratke predstavitve ne sklenemo posla in ne prodamo. Vplivni ljudje se ne odločajo na osnovi nekega kratkega povzetka, ampak se vedno poglobijo v situacijo in raziščejo priložnost.

Vendarle je prav, da imamo vedno pripravljen kratek povzetek, že zato, da pri sebi razčistimo bistvo tistega, kar delamo ali ponujamo, zato da znamo naključnim znancem, ki jih srečamo (in ne nujno le zelo pomembnim ljudem) kratko in jedrnato povedati, kaj delamo in zakaj je to pomembno. Kar se tiče pogovora v dvigalu pa naj bo ta predvsem usmerjen v to, da vplivno osebo pridobimo do te mere, da se bo želela ponovno srečati z nami.

Sorodni članki

• Kratka predstavitev poslovne ideje ali elevator pitch (blazkos.com)
• An Elevator Pitch for your Project (betterprojects.net)
• The myth of the elevator pitch (acm.org)