Managementul capacităţii

Această activitate îmi ocupă foarte mult timp în această perioadă a anului, aşa că m-am gândit să scriu câteva rânduri. Trebuie să ne familiarizăm cu anumiţi termeni specifici, definiţiile le găsim în glosar:
- capacitate
- managmentul capacităţii
- sistem informatic de management al capacităţii
- plan de capacitate
- planificarea capacităţii

Trecem mai departe şi aruncăm o scurtă privire prin materialele unde este tratat subiectul. Intenţionez doar să indic sursele cele mai importante :

COBIT : Capitolul "DS3 Manage Performance and Capacity"
ISO 20000 : Capitolul 6.5 , în ambele cărţi
ITIL v3 : Capitolul 4.3, în cartea de Service Design

Spre final, câteva aspecte din practică:
- o planificare necorespunzătoare a capacităţii are efecte neplăcute asupra business-ului. Lipsa de capacitate duce la incidente, prea multă capacitate înseamnă risipă.
- business-ul este cel care oferă informaţii despre nevoile viitoare, IT-ul face tot posibilul să se alinieze.
- într-o relaţie furnizor-client, clientul este cel care furnizează informaţii din perspectiva business-ului.
- serviciul oferit este semi-transparent, furnizorul nu poate face tot timpul o analiză completă a capacităţii împreună cu clientul
- planul de capacitate trebuie respectat. Incidentele cauzate de nerespectarea planului de capacitate sunt greu de explicat.
- periodicitate : recomandarea este ca elaborarea unui plan de capacitate să fie făcută anual
- nu uitaţi că şi omul este o resursă (foarte importantă), care are anumite limite.

Teoria constrângerilor

Prescurtat, TOC - din Theory of Constraints. Am găsit multe scrise despre acest subiect, aşa că nu intenţionez să reinventez roata - doar intenţionez să il mediatizez. Pe scurt, este o filozofie a managementului, dezvoltată de dl. Goldratt.

Prima resursă de unde puteţi începe lectura este wikipedia : http://en.wikipedia.org/wiki/Theory_of_Constraints

Probabil o să vă întrebaţi ce legătura are cu Service Managementul, cu IT-ul în genereal. Ei bine, are. Vă las să digerati subiectul mai mult timp şi sper ca într-o zi să vin si cu un exemplu din practică.

Vă doresc o zi bună, cu fără prea multe constrângeri.

Servicii

Cred ca a venit vremea să discutăm despre servicii. Din cărţi , despre ceea ce este un serviciu :

"Mijloace de a livra valoarea catre Clienti prin facilitarea acelor Rezultate/Obiective pe care Clientii le doresc sa fie atinse, fara detinerea Costurilor si Riscurilor specifice."

Livrăm valoare către clienţi : un aspect foarte important este acela de a înţelege ceea ce înseamană valoare pentru client. De multe ori trebuie să vedem lucrurile din perspectiva clienţilor pentru a înţelege ceea ce îşi doresc (rezultate/obiective). Comunicarea foarte clară dintre furnizor şi client este esenţială, îmi aduc aminte de o situaţie foarte "deosebită" când am hotărât împreună cu un client să-i ofer un serviciu dimineaţa.

Costuri şi riscuri specifice : aceastea trec din responsabilitatea clientului în responsabilitatea furnizorului. În general cam aşa stau lucrurile, dar există şi excepţii mai ales în zona de conformitate/audit financiar/securitate.

Dacă tot oferim un serviciu, ne interesează satisfacţia clientului (pentru că el este consumatorul de servicii). Ei bine, este subiectivă. Serviciul, neavând prea multe caracteristici tangibile, este greu de evaluat mai ales din punct de vedere calitativ. Din acest motiv furnizorul şi clientul cad de acord asupra unor indicatori de performanţă.

Concurenţă loială ?

Căutam în week-end un examen şi cerinţele pentru examinare. Sunt doi jucători mari pe piată care oferă posibilitatea susţinerii examenelor, sunt foarte cunoscuţi aşa că nu le menţionăm numele. Ei bine, mesajele pe care le-am primit arată cam aşa:

Site-ul nr. 1 :
" SPECIAL NOTICE:This website is scheduled to undergo routine maintenance on 14 November from Saturday, 6:00 p.m. CT–Sunday, 12:00 noon CT. During this time, you will not be able to schedule, reschedule or cancel test appointments. We apologize for this inconvenience and thank you for your patience."

Site-ul nr.2
"The website you are attempting to reach is temporarily unavailable due to scheduled maintenance. We apologize for any inconvenience.
Please check back again later. Thank You"

Apreciez mesajul primului site, care precizează serviciul oferit şi perioada în care acesta nu este accesibil. Trecând peste acest detaliu (important !) în modul de comunicare , este foarte posibil ca în spatele acestei mentenanţe să fie motive tehnice, care-i afectează pe ambii furnizori. Daţi-mi voie să fiu (poate) naiv şi să cred că şi-au planificat împreună mentenanţa, pur şi simplu din motive de etică în afaceri. Până la proba contrarie, tot respectul meu !

CMMI-SVC 1.2

Dacă ne uităm în glosarul pentru ITIL v3, găsim următoarea definiţie pentru CMMI :

"Modelul Integrat de masurare a Maturitatii Capabilitatilor (CMMI) este un proces de imbunatatire dezvoltat de Institutul Software Engineering (SEI) din cadrul Universitatii Carnegie din Mellon. CMMI asigura organizatiilor elementele esentiale ale unui proces efectiv. Poate fi folosit pentru a ghida procesul imbunatatirii de-a lungul unui proiect, al unei divizii sau al unei intregi organizatii. CMMI ajuta integrarea functiilor organizationale, traditional separate, fixeaza obiectivele procesului de imbunatatire si prioritatile, furnizeaza indicatii pentru procese de calitate, si asigura un punct de referinta pentru aprecierea proceselor curente. Pentru mai multe informatii acceseaza http://www.sei.cmu.edu/cmmi/ "

SEI a extins modelul dedicat dezvoltatorilor de software, care era prezent pe piaţă de foarte multă vreme şi din Februarie 2009 avem un model dedicat serviciilor : CMMI-SVC 1.2. Documentaţia este prezentă aici : http://www.sei.cmu.edu/reports/09tr001.pdf

Procese, procese, procese - despre asta este vorba în acest material. Să nu uităm că avem nevoie şi de oameni pentru a furniza un serviciu.

Paradoxul Abilene şi "group thinking"

Pe scurt, decizia luată de un grup este contrară oricărui interes a membrilor grupului. Este o situaţie neplăcută, până în momentul de faţă nu am întâlnit-o. Componenţa echipei este foarte importantă - pentru a asigura existenţa mai multor puncte de vedere, cel care deţine poziţia de lider trebuie să-i "interogheze" (de multe ori individual) pe toţi cei care fac parte din echipă pentru a afla aceste păreri.

http://en.wikipedia.org/wiki/Abilene_paradox

Similar cu paradoxul Abilene (şi mult mai frecvent întâlnit) o să dăm peste "group thinking".

http://en.wikipedia.org/wiki/Groupthink

Nu traduc termenul pentru că nu găsesc cuvintele potrivite. Diferenţă constă în modul de reacţie al echipei - în ultimul caz echipa se orientează în jurul unei idei şi este observată o abordare de grup (de multe ori neargumentată, subiectivă), dar există şi alte idei care sunt prezentate şi evaluate. Este un obicei pe care nu îl apreciez şi îl detectez foarte uşor urmărind fenomenul de "bisericuţe". În Service Management, fenomenul de "group thinking" l-am întâlnit cel mai frecvent în aria de management a problemelor, mai exact la indentificare cauzelor unor probleme - RCA.

Servicii placate cu aur

Să nu credeţi ca am luat-o razna chiar aşa de repede :). E greu de tradus din engleză terminologia de "Gold Plate Services". Nici nu ştiu daca termenul este documentat prin vreun framework sau standard. O sa explic în următoarele rânduri şi sper să înţelegeţi la ce fac referire.

Un serviciu este oferit pe baza unor SLA-uri = Service Level Agreement. Să ne amintim definiţia : "Un Acord între un Furnizor de Servicii IT şi un Client. SLA descrie Serviciul IT, documentează Norma Nivelului de Servicii şi specifică responsabilităţile Furnizorului de Servicii IT şi ale Clientului." La ce mă refer în titlu: situaţia în care furnizorul de servicii oferă clientului o calitate deosebită a serviciului şi de ce nu, în afara ariei de responsabilitate.

De ce ar face un furnizor de servicii acest lucru ? Să vedem :
- creşte satisfacţia clientului. În general un client foarte satisfăcut aduce alţi clienţi
- ambiţii personale. Există situaţii în care vrem neapărat să dovedim că putem face un anumit lucru, chiar dacă nu e în aria noastră de responsabilitate
- orice alt scenariu, prin care urmărim o situaţie de câştig în ambele părţi (furnizor şi client)

Din păcate lucrurile nu merg tot timpul cum trebuie. Ce poate merge prost :
- clientul pur şi simplu nu e interesat de un serviciu care să-i depăşească aşteptările. Tu, ca şi furnizor, o să fii frustrat şi drept pedeapsă o să cauţi o cale să echilibrezi balanţa.
- alţi clienţi o să fie nemulţumiţi, pentru că ei nu primesc acest serviciu şi se simt ignoraţi
- probleme financiare. Efortul pentru oferirea acestor servicii placate cu aur este considerabil şi s-ar putea să nu se justifice financiar.
- când nu o să mai oferiţi acest serviciu, clientul o să se simtă ignorat

Eu vă recomand să fiţi moderaţi şi să vă gândiţi bine atunci când evaluaţi astfel de scenarii. Lucrurile pot merge înspre bine, dar echilibrul este foarte fragil şi situaţia poate degenera uşor.

Simularea unui DRP

DRP - Disaster Recovery Plan
RTO - Recovery Time Objective (în cât timp restaurezi serviciul)
RPO - Recovery Point Objective (care este pierderea de date acceptată)

O să mă opresc pentru câteva momente asupra unui aspect pe care îl consider delicat şi care generează de multe ori discuţii aprinse. Mai jos pun o informaţie extrasă din Cobit 4.1 , mai exact din capitolul DS4 - Ensure Continous Service.

DS4.5 Testing of the IT Continuity Plan
Test the IT continuity plan on a regular basis to ensure that IT systems can be effectively recovered, shortcomings are addressed and the plan remains relevant. This requires careful preparation, documentation, reporting of test results and, according to the results, implementation of an action plan. Consider the extent of testing recovery of single applications to integrated testing scenarios to end-to-end testing and integrated vendor testing.

Subliniez câteva aspecte legate de acest test şi unele erori întâlnite de-a lungul vremii :
- testul trebuie să fie periodic. Dacă astăzi rezultatul a fost pozitiv, nu înseamnă că şi următorul o să fie la fel.
- după orice modificare majoră de arhitectură sau orice schimbare semnificativă asupra componentelor implicate într-o astfel de soluţie un nou test trebuie executat.
- rezultatul testului este pozitiv sau negativ. Am întâlnit foarte multă lume care consideră un test cu rezultat negativ un dezastru. Greşit ! Important este să inveţi din acest test, să documentezi ceea ce a mers rău şi să eviti la următorul test aceleaşi greşeli. Dacă rezultatul este negativ de mai multe ori consecutiv, planul trebuie revizuit complet.
- revizuirea rezultatelor în urma testelor, îmbunătăţirea documentaţiei şi informarea echipei sunt elemente esenţiale care vor creşte şansele de reuşită într-o situaţie reală.
- resurse (oameni) - am avut multe discuţii legate de acest topic. Îmi menţin părerea : pentru primul test (sau testul următor unui rezultat negativ), nivelul de cunoştinţe şi experienţa oamenilor trebuie sa fie mai mare decât media echipei. Acesta este momentul în care se stabilesc paşii ce trebuie urmăriţi, se scrie/corectează documentaţia. Dar, pentru testele recurente eu recomand alocarea unor persoane cu conştinţe medii şi rotirea acestor persoane. De ce ? Pentru că în momentul în care o să ai o situaţie reală ai nevoie de ajutorul echipei şi nu doar a celor mai experimentaţi.
- aveţi mare grijă ca în timpul testului să nu afectaţi mediul de producţie. Având în vedere că se incearcă o simulare cât mai reală, şansele de a afecta mediul de producţie sunt destul de ridicate.
- de cele mai multe ori testul este anunţat şi nu sunt întâmpinate probleme în a respecta RTO/RPO. O situaţie extremă puţin probabil că o să fie planificată. Încercaţi să luaţi prin surprindere echipa şi cereţi o simulare care nu este prevăzută. De obicei există o înţelegere scrisă legată de timpii de reactivitate pentru a activa o astfel de soluţie.

Spre final, un motto : "Pregătiţi-vă pentru ce e mai rău, aşteptaţi-vă la ce e mai bun !"

Glosar ITIL v3 - traducere

Un material util.

http://www.best-management-practice.com/gempdf/ITILV3_Glossary_Romanian.doc

Spaţiu pe disc şi soluţia de BC

Atunci când ai un business mai serios, te gândeşti în mod normal şi la o soluţie de continuitate a business-ului în caz de dezastre. Ei bine, o să dau un exemplu foarte simplu în care o astfel de soluţie (destul de costisitoare) a fost anihilată şi (ce e mai trist) a trecut ceva vreme până a fost reactivată.

Soluţia de DRP este foarte simplă: se bazează pe Oracle Active Stanby Database. Foarte pe scurt, redolog-urile sunt transmise de pe baza de date primară pe o bază de date secundară unde sunt aplicate şi şterse. Din motive tehnice, aplicarea log-urilor pe baza secundară şi ştergerea lor nu a mai decurs corespunzător, acest lucru generând o alertă pentru spaţiu pe disc. Nimic deosebit până acum. Doar că tratarea incidentului a fost defectuoasă. Deşi exista un grad ridicat de urgenţă pentru rezolvarea acestui incident, neexistând nici un impact vizibil asupra mediului de producţie, rezoluţia a fost foarte mult întârziată. Ce se întâmpla dacă în acest interval trebuia activată solutia de BC ? O întrebare fără răspuns.

Ce trebuie învăţat de aici:
- definiţia unui incident nu trebuie uitată: (Service Operation) întreruperea neplanificată a unui serviciu IT sau degradarea calităţii unui serviciu IT. Defectarea unui element de configurare care nu a afectat înca un serviciu reprezintă de asemenea un incident.
- prioritatea incidentului este determinată de urgenţă x impact
- revizuirea periodică a incidentelor (indiferent de prioritate) ajută la detectarea unor astfel de situaţii
- toţi participanţii în oferirea unui serviciu IT trebuie periodic educaţi, o solutie de BC este ultima scăpare în situaţii neplăcute.

Puţin despre ISO/IEC 20000

Se face că zilele acestea citesc tot mai mult despre ISO/IEC 20000. Comparativ cu ITIL, sunt câteva diferenţe notabile, pe care le găsiţi aici :

http://www.best-management-practice.com/gempdf/ITIL_and_ISO_20000_March08.pdf

Un lucru foarte important pe care trebuie să îl ţineţi minte:
- ITIL este un framework
- ISO/IEC 20000 este un standard. Acest lucru îl face auditabil.

Documentaţia pentru ISO/IEC 20000 conţine două volume :
- ISO/IEC 20000-1:2005 Specification
- ISO/IEC 20000-2:2005 Code of Practice

Prima parte este orientată spre standard, detaliază obligativitatea (Shall) implementării conform cerinţelor. A doua parte reprezintă mai mult un ghid de implementare (Should).
Câteva cuvinte despre SHALL şi SHOULD găsiţi aici :
http://adimunteanu.wordpress.com/2009/11/09/should-vs-shall/

Spre final, de unde să incepeţi citirea acestui material ? Personal m-am orientat spre această carte : "ISO/IEC 20000 : An Introduction"

http://www.itsmf.co.uk/Shop/Products/ISO20000introduction.aspx

ITIL v2 - retras de pe piaţă

OGC retrage ITIL V2 de pe piaţă :

V2 Foundation - 30 Iunie 2010
V2 Manager - 31 August 2010
V2 Practitioner - 31 Decembrie 2010
Foundation Bridge - 31 Decembrie 2010

Mai multe informaţii, direct de la sursă :

http://www.ogc.gov.uk/itil_ogc_withdrawal_of_itil_version2.asp

Contract - puterea unui cuvânt

Prin vară am aflat "adevăratul sens" al acestui cuvânt: contract. De ce pun ghilimele ? Pentru că gradul de utilizare al acestui cuvânt în Service Management este destul de mare, dar de multe ori îi uităm sensul. Uitându-mă mai târziu în dicţionar am ajuns la o concluzie simplă: trebuie folosit cu măsură, doar atunci când este neapărat nevoie. Folosirea excesivă a cuvântului "contract" poate anunţa o degradare a relaţiilor de business. Drept înlocuitor recomand folosirea cuvântului "înţelegere" (agreement) - este mult mai lejer şi reflectă o relaţie de bună colaborare.

http://www.dex-online-ro.ro/search.php?cuv=contract

~ convenţie, înţelegere scrisă prin care două sau mai multe părţi se obligă reciproc la ceva.
~ economic = contract între două întreprinderi prin care o parte se obligă să livreze anumite produse, să presteze un serviciu sau să execute o lucrare, iar cealaltă să plătească preţul mărfii sau al lucrării, ori tariful serviciului efectuat.

Termenul (şi explicaţia) în engleză întăresc cele spuse mai sus prin nuanţarea obligaţiilor legale :

http://en.wikipedia.org/wiki/Contract

"In law, a contract is a binding legal agreement that is enforceable in a court of law. [1] That is to say, a contract is an exchange of promises for the breach of which the law will provide a remedy."

De ce acest blog ?

Simplu : în urmă cu vreo două săptămâni terminam un curs de project management şi am găsit destul de multe site-uri din .RO dedicate subiectului. Nu am găsit prea multe informaţii despre IT Service Management scrise în limba română aşa că m-am hotărât să scriu şi eu câte ceva. O să scriu mai mult chestii practice şi când e nevoie o să menţionez şi sursele teoretice.

Părerile exprimate aici sunt personale şi nu reprezintă viziunea companiilor prin care am trecut sau la care activez.

Orice comentariu este binevenit !