.jpg)
Academia Română a fost creată în 1866 pentru a cristaliza cele mai înalte valori intelectuale din provinciile românești într-o societate erudită menită să consolideze identitatea națională pe baza a patru componente esențiale: limbă și literatură, istorie, etnografie și cultură. La...
Selectia aplicatiilor software – intre ciocanul cerintelor si nicovala preturilor (II)
„Cand va fi gata sistemul?”. Ultima intrebare, pusa cu aparent calm, nu prevestea nimic bun... Raspunsul timid, de incepator neconvingator, nu a fost de natura sa arunce lumina asupra situatiei: „Pai, din momentul semnarii, va dura aproximativ doua saptamani pentru a face o analiza a cerintelor dumneavoastra, si apoi...”. Fraza nu a mai putut ajunge pana la sfarsit: „Va bateti joc de mineeee??? Si camioanele mele cum o sa plece pe traseu in doua saptamani???”
Cu observatia ca atat aceasta mica relatare cat si cea din prima parte a articolului sunt absolut veritabile (poate doar putin dramatizate J), vom trece la cel de-al doilea factor pe care ne-am propus sa il analizam cu privire la factorii contextuali in selectia aplicatiilor software pentru managementul afacerilor.
2. Anvergura proiectului dorit.
Termenul „anvergura” este ambiguu, dar intotdeauna se refera la ceea ce se va face versus ceea ce nu se va face in cadrul proiectului. El poate desemna functionalitatile incluse (anvergura functionala – care de altfel este in stransa corelatie cu factorul amintit in prima parte a articolului), activitatile din proiect incluse (celelalte urmand a fi executate de catre client sau de catre alti contractori – anvergura de proiect) sau chiar aria organizationala (sediul central, subsidiarele, anumite directii si departamente etc.).
Si aici exista doua paradigme opuse care aplicate pana la consecintele lor ultime sunt in mod egal daunatoare:
a. „Perspectiva faraonica”: companii/institutii care nu au cunoscut decat creionul si hartia decid sa puna in aplicare proiecte de informatizare a proceselor financiare, logistice, de productie, intretinere si reparatii, resurse umane, gestiunea relatiilor cu clientii etc. – toate in acelasi timp, eventual simultan cu proiectele de retelistica si comunicatii, cu intranetul companiei, toate acestea de la sediul central pana in cel mai neinsemnat punct de lucru.
Inca nu am vazut un astfel de proiect terminandu-se... cu bine (desi am participat la un numar semnificativ de chermeze de mari dimensiuni care sarbatoreau cu fast incheierea fazei II.a a proiectului de informatizare de la...).
b. Perspectiva opusa este cea a „pilotului”: probabil un termen familiar celor care au citit unul din articolele mele precedente (multe multumiri celor care s-au gandit sa infiinteze un fan club, dar si celorlalti, care au petrecut ceva vreme pentru a intelege cine m-a platit sa scriu articolul). In locul proiectului real, se construieste o „macheta” la scara 1:10 (uneori 1:100) care demonstreaza chipurile posibilitatea/fezabilitatea proiectului principal (real).
Desi metoda are meritele si aplicabilitatea ei, problema fundamentala este aceea ca de cele mai multe ori dupa pilot nu mai urmeaza nimic – decat cel mult un nou pilot, actualizat. Dificultatile esentiale ale unui proiect de mari dimensiuni deriva in principal din complexitatea functionala si/sau organizationala si numai intr-o mai mica masura din caracteristicile software.
Este destul de ironic ceea ce se intampla in realitate: companii care promoveaza cu fermitate o perspectiva faraonica sfarsesc prin a fi atrase de catre furnizori cu inalta calificare in furnizarea de piloti (inca o demonstratie, daca mai era nevoie, ca extremele se atrag).
Parerea ta conteaza: 
Informatizare in Tomania
