Tot rumegînd la subiectul din postul precedent am ajuns să mă întreb oare ce îşi doresc organizaţiile?
Clientul: cea mai bună soluţie pentru problema sa.
Operaţionalul: optimizarea costurilor, pentru că i se cere de la nivel tactic/strategic.
Leadearship: să livreze pe piaţă cel mai bun serviciu/produs.
Este posbil ca o firmă să le facă pe toate trei simultan? Nu prea cred. Găsirea echilibrului este dificilă.
Apoi am ajuns cu mintea la un mic scenariu, inspirat din istoria ultimilor 20 de ani:
1. Se naşte un concept nou. Promotorii acestuia încep bombardamentul pe piaţă: studii de caz, materiale promoţionale, poveşti de succes sau dramolete, prezentări, vînzări la preţuri mici şi restul arsenalului.
2. Promotorii continuă să se dezică de trecut şi promovează noul concept în faţa beneficiarilor direcţi ca fiind “the next big thing”. Simplu/complex, plăcut, frumos, salvator. Mult mai bun decît tot ceea ce a fost pînă atunci.
3. Se promovează în continuare implementarea şi valoarea adusă, dar de astă dată în faţa “decisions makers”. Cu multe cifre, ROI, NPV, whitepapers etc.
4. În final promotorii/vînzători de servicii/produse îşi etichetează marfa cu “new big thing”……
Ne-am umplut de acronime: ERP, CRM, SCM, BPR, BPM, BI, ITIL, COBIT, IDS/IPS, SaaS, PaaS, CaaS, Maas, SoA etc. Cam tot ce ţine de tehnologia informaţiilor este vîndut drept panaceu…Next big thing.
Se face vorbire de procese, dar se omite a se spune că procesele înseamnă mai mult decît tehnologie. Procesul nu înseamnă doar (re)modelare. Înainte de implementare, implică multă analiză! Aplicaţiile vor fi eficiente numai cînd vor fi aplicate operaţiilor eficiente!
A fost o vreme cînd se vindeau “cutii”. Pe atunci serviciile erau incluse în preţ….Acele timpuri au trecut. Acum se vînd “servicii”.
Nu contează că avem o problemă cu procesul economic. Se caută o soluţie IT “to fix it”. Şi piaţa oferă o sumedenie. Să automatizăm totul, tovarăşi!
Imaginea de mai sus prezintă, din punctul meu de vedere, Process-People-Technology. E o paradigmă aplicată multor domenii economice, nu doar IT. Include de asemenea şi Process—Procedure-Instruction. Şi resurse, obiective şi leadership. ECHIPĂ! Rezultatul s-a văzut însă abia la finish, cu multă sudoare! Pentru că, înainte de toate au fost obiectivele.
Tehnologia ar trebui să urmeze procesul. Nu invers. Aducere amintere a poveştii lui Taylor cu cronometrarea şi vizualizarea mişcărilor muncitorilor ce încărcau vagoane cu cărbuni, la începutul anilor 1900.
Şi ca să termin tot cu o cîrcoteală ce ţine de consistenţă.
În Service Strategy (ce să fac, e prima carte cu care am început şi tot recitesc la ea de vreo 3 ani), la 2.6.2 Processes scrie negru pe alb: “Functions are often mistaken for processes. For example, there are misconceptions about Capacity Management being a service management process (…) It is a mistake to assume that Capacity Management can only be a process (…) Assuming that is always a process with discrete countable outcomes can be a error” – pg. 26.
Cu toate acestea, în Service Design, la 4.3 Capacity Management scrie “Capacity Management is a process that extend across the service Lifecycle” – pg.79.
La fel de bine aş putea cita definiţia funcţiilor, de la aceeaşi pagină din Service Strategy şi apoi să întreb: cîte procese devin funcţii? Mai rămîne Financial Management proces, de exemplu? Să mă fac mai bine înţeles: incosistenţa mă deranjează mai mult decît rigoarea termenilor folosiţi.
Dar avem în sfîrşit ITIL® based software tools. Spre bucuria unora. Şi constrîngerile altora.
ADRIAN B. MUNTEANU 
bucata care lipseste e:
„Whether or not it is a function or a process depends entirely on organization design.”
In Service Design se face vorbire de proces…
ApreciazăApreciază
Mihai,
Argumentatia e mai lunga. Textul lipsa si adaugat de tine, pentru mine nu schimba datele problemei. Tot inconsistenta este. Revin cu un post sau la berea aia de s-a incalzit.
ApreciazăApreciază
Iata ca am ajuns in fata latopului si pot scrie mai in detaliu. Raspunsul anterior a fost de pe mail.
De dragul argumentatiei si al dialogului as vrea sa stabilim o regula: sa faci abstractie de afacerea in care lucrezi. Pentru ca este un service provider pur, in acceptiunea mea.
Presupune ca joci exact acelasi rol intr-o firma care are o unitate funcţională numită IT.
Cum proiectam procesele IT? Top down sau bottom up? Te intreb asta, pentru ca in urma unui dialog al nostru cu ceva timp in urma, incercarea ta era de a stabili metrici, adica era legata de eficienta unui proces al tau.
ApreciazăApreciază
Well, sunteti asprii, e una din inconsitente, sunt mai multe strecurate mai cu seama intre carti pentru ca autorii, odata intrati in tunel, nu si-au mai vorbit, QA a fost facut tot per manual dar foarte putini oamen au auvut access la mai mult de un manual si de aceia au ramas izolate la nivel de manual. Mai e una celebra ECAB vs CAB/EC (tipiilor din service operation nici prin cel mai negru cosmar nu le-a trecut ca cineva va indrazni sa schimbe un nume atat de popular!!!)
Asta cu Capacity in schimb e particulara, e mostenita din V2, eu personal n-am inteles argumentul, autorul cred ca l-a preluat cu cut si paste si nu l-a mai judecat!!
ApreciazăApreciază
Coco
Daca nu mi-ar fi încăput pe mînă, de la tine, cărţile de la V2, nu aveam cu ce să fac comparatie. După cum spuneam, faptul că există inconsitenţe în V3 nu e un deranj aşa mare. După durerile facerii cu COBIT le înţeleg destul de bine. Mai deranjantă, pentru mine, este lipsa de rigoare în folosirea termenilor. Nu faptul că nu este clar că o funcţie include unul sau mai multe procese. Inclusiv procese IT.
Iată de exemplu un lucru a cărui înţelegere îmi scapă. De ce pentru implementare, pentru proiectarea unui serviciu se scrie că trebuie să se folosească BIA ca „a valuable source of input”. Chiar aşa este? Oare nu este posibil să nu am procese economice care să nu aibă dependeţe critice la momentul la care fac BIA, pentru simplul motiv că nivelul de maturitate al IT este minim?
Nu ar fi mai bine să mă uit la procesul economic ca să ştiu ce pun în Service Portofolio? Răspunsul este dat cîteva pagini mai încolo: „understanding the business requirements and the business priorities and ensuring that these are uppermost in mind when designing the process and the services”.
ApreciazăApreciază
Un motiv ar fi destul de simplu; BIA descopera cei mai important – vital business function VBF si practic optiunile de design tre sa favorizeze pe cat posibil VBF.
BIA in Service Design (SD) cum zici tu pare cam tarziu. Numai ca in Service Strategy (SS) deci in avans, in mod normal tre sa evaluezi destul de serios contributia serviciului la crearea de valoare pentru client, repectiv integrarea (si nu alinierea) cu business. Cei drept, algoritmul e destul de alambicat (sper ca noul SS sa fie totusi mult mai digerabil, sper sa pun mana pe el in Aug) dar ideea e acolo.
ApreciazăApreciază
Din punctul meu de vedere, si nu e ala de service provider: Capacity Management e un proces, si cand se vorbeste de asta, eu la proces ma gandesc. Ca pot linistit sa am in organizatie o functie care sa se mapeze 100% pe procesul asta, asta e alta mancare de peste.
Despre BIA, odata ca e “a valuable source of input” dar nu si only source of input, si a doua oara, Coco are dreptate… despre procesele alea economice trebuia sa vorbim inca din SS, nu sa le astept sa mi le identifice BIA.
ApreciazăApreciază
Nu am contestat faptul ca CM nu ar fi proces.
(ai combinat două întrebări în răspuns :))
Faceam referire la cum se exemplifică.
Da, trebuie să vorbim încă din SS despre procesele economice. Dar procesele IT cum le proiectăm?
Am în minte, pentru că este cald, COBIT PO4 . Procesul despre procese…..
ApreciazăApreciază
citesc PO4 si revin.
ApreciazăApreciază
Detaliile sunt in documentul de mapare CobIT si ITILv3; e de comentat acolo, CobIT vede strict din perspectiva proprie a definirii proceselor se service management, ITIL intra cu mult mai mult si in alte activitati nu numai in procese, prin intermediul Service Models.
Bucata cea mai relevanta e in SD unde unul din aspectele de design e chiar design de procese
ApreciazăApreciază
IT-ul într-o organizaţie este precum camioanele pentru o firmă ce face şi livrări de mărfuri cu propria flotă. Degeaba ai cele mai bune camioane dacă oşferii nu sînt disciplinaţi, dacă nu îţi optimizezi comenzile de la clienţi şi nu ştii/reuşeşti să reduci timpii pînă pui marfa în camion. Şi cum pui marfa în camion.
Şi în final degeaba le faci chiar şi pe astea, dacă nu ai infrastructură rutieră.
Cam aici doream să ajung cu discuţia
(încep să urăsc dialogul în format electronic…..se pierd o mulţime de nuanţe şi de idei….tot la bere e mai bine…)
ApreciazăApreciază