Като че ли една от основните идеи на ISO/IEC 20000-1 е да бетонира добре работещата IT услуга и така да се реализира принципа, познат на всички българи - "Ако нещо работи добре, не го пипай!". Така се стига до определяне на CI (configuration Items), CMDB (Configuration Management Data Base), до Change Management Process-а и свързани с тях изисквания.
Един мой приятел, мениджър на система за IT услуги, се терзае заради забележки, които одитор му е написал от последния одит. Терзае се за забележките, защото пък иначе несъответствия няма - нито едно! Щом няма несъответствия, много е вероятно системата да е ОК, нали? Казва се "вероятно", защото нали всеки одит съдържа елемент на неопределеност, дължащ се на това че ... и така нататък. Няма значение! Та, човекът се терзае заради забележките, защото пък те били бая много - десет! И никак не се успокоява от уверение, че тези забележки нямат същото значение, както несъответствията. Даже може изобщо да не се реагира на каквито и да било забележки. Те, забележките, някак си са израз на загрижеността на одитора за неща, които е видял, не са му харесали съвсем и ... понеже няма как да бъдат несъответствия (напомняне - "несъответствие" е "неизпълнение на изискване"), то тази му загриженост ражда въпросните забележки. Има и друг вариант - една забележка може да дойде и от това, че одиторът е видял нещо, което тук е така, а при други одити на други места е било по-онака и, според него, по-добре. Та и тук със забележка се казва, че "Това тук дето е така може да е по-онака" или направо "съвсем иначе".
Възникват няколко въпроса ...
Защо някои одитори не "харесват" система, но не пишат несъответствия? Тук подозираме - несъответствие се пише трудно, защото трябва да знаеш добре изискванията, да си видял ясни доказателства за неизпълнение на изисквания, да умееш да напишеш еднозначно ясен израз на установеното и през цялото време да си имаш едно на ум, че едно сбъркано несъответствие би могло да бъде атакувано от клиента и то така, че да се отрази зле на одиторското ти досие.
А лесно ли е да се пишат забележки? И тук е ясно - да, лесно е - даже е съвсем фасулска работа. Това го разбрах, когато човекът ми прати някои забележки. Като ги прочетох и се замислих, защото ми се сториха много, ама много познати. Все едно аз да съм ги писал ...
И тогава се сетих да отворя стандарта с насоките - "Guidance on the application of service management system" (цитиран нататък като "гайдънс"). Сещате се, нали? Копи-пейст от гайдънса! Ама директно! Какво ти редактиране? Без никакво редактиране даже! Нима?!
И тогава се сетих да отворя стандарта с насоките - "Guidance on the application of service management system" (цитиран нататък като "гайдънс"). Сещате се, нали? Копи-пейст от гайдънса! Ама директно! Какво ти редактиране? Без никакво редактиране даже! Нима?!
Че то така е лесно. Излиза, че може да одитираш една система без много да се ангажираш с така трудното търсене на (не)съответствия. По-лесно е да понадушиш някои неща и по тях да напишеш забележки ... пардон, да препишеш нещо най-пряко от гайдънса. Всеки ще го може!
И все пак за какво става дума? Всеки знае - гайдънсите се пишат като изчерпателни и надути документи с всякакви насоки, препоръки и подсказки и това надуване не е случайно, а защото има наистина големи и много големи организации, които биха очаквали да намерят в гайдънс неща, относими към техните мащаби и практики. Това - добре! А как стои въпросът с по-малките, със средните и изобщо с тези може би 99% други организации. Те си знаят, че гайдънса не съдържа изисквания и не ги ангажира с друго освен с това, като го прегледат, да се подсетят за нещо и да видят кое от написаното им подхожда и им "отива", в каква степен, ако не изцяло, че чак тогава да го приложат. Става дума за това, че когато одитор седне и ти напише забележки въз основа на това кое му е харесало на него от гайдънса, то с този израз на "загриженост" пишманът обърква принципно нещата, защото принципът е той да не ти дава акъл (ами, да ... даването на забележки е всъщност даване на акъли! ). И с това те лишава от собствената ти преценка, защото, ако вече си гледал гайдънса, ти си имаш такава.
Разнообразието на организациите според числеността им (от един човек до десетки хиляди) и разнообразието на IT слугите (те пък са стотици, ако не хиляди) ни определят еднозначно как да ползваме гайдънса, а това е само за подсещане и то в процеса, когато вземаме решение за това "Кое при нас и за нашата услуга е CI?" или когато вече имаме решение - да го проверим или да го доразвием. Правилното мислене на тема "Кое за нашата услуга е CI?" се насочва от разбирането, че CI е онова, без което услугата не може и едновременно е това, което, ако го пипнеш да промениш, то се променя и услугата. Разнообразието, посочено по-горе, предопределя разнообразие и на типовете CI. Макар и да се е понапънал гайдънса да изброи много типове, едва ли може да се каже, че изброяването е достатъчно, а още повече и да е изчерпателно... Категорично.
Ето защо изборът и преценката на хората от организацията за това кои са им CI за една услуга и в каква степен на детайли да бъде описвано всяко CI, трябва да се уважават и приемат с внимание. С повече внимание отколкото преценката на човек, който познава системата и услугите само от няколко дена или часа и, понеже е загрижен да не би да се скапе IT услугата, сяда и пише забележки. Пардон ... преписва забележки!
