ISO/IEC 20000-1 Как да внимаваме да не би да се скапе IT услугата ?

Като че ли една от основните идеи на 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" (цитиран нататък като "гайдънс"). Сещате се, нали? Копи-пейст от гайдънса! Ама директно! Какво ти редактиране? Без никакво редактиране даже! Нима?!

Че то така е лесно. Излиза, че може да одитираш една система без много да се ангажираш с така трудното търсене на (не)съответствия. По-лесно е да понадушиш някои неща и по тях да напишеш забележки ... пардон, да препишеш нещо най-пряко от гайдънса. Всеки ще го може!

И все пак за какво става дума? Всеки знае - гайдънсите се пишат като изчерпателни и надути документи с всякакви насоки, препоръки и подсказки и това надуване не е случайно, а защото има наистина големи и много големи организации, които биха очаквали да намерят в гайдънс неща, относими към техните мащаби и практики. Това - добре! А как стои въпросът с по-малките, със средните и изобщо с тези може би 99% други организации. Те си знаят, че гайдънса не съдържа изисквания и не ги ангажира с друго освен с това, като го прегледат, да се подсетят за нещо и да видят кое от написаното им подхожда и им "отива", в каква степен, ако не изцяло, че чак тогава да го приложат. Става дума за това, че когато одитор седне и ти напише забележки въз основа на това кое му е харесало на него от гайдънса, то с този израз на "загриженост" пишманът обърква принципно нещата, защото принципът е той да не ти дава акъл (ами, да ... даването на забележки е всъщност даване на акъли! ). И с това те лишава от собствената ти преценка, защото, ако вече си гледал гайдънса, ти си имаш такава.

Разнообразието на организациите според числеността им (от един човек до десетки хиляди) и разнообразието на IT слугите (те пък са стотици, ако не хиляди) ни определят еднозначно как да ползваме гайдънса, а това е само за подсещане и то в процеса, когато вземаме решение за това "Кое при нас и за нашата услуга е CI?" или когато вече имаме решение - да го проверим или да го доразвием. Правилното мислене на тема "Кое за нашата услуга е CI?" се насочва от разбирането, че CI е онова, без което услугата не може и едновременно е това, което, ако го пипнеш да промениш, то се променя и услугата. Разнообразието, посочено по-горе, предопределя разнообразие и на типовете CI. Макар и да се е понапънал гайдънса да изброи много типове, едва ли може да се каже, че изброяването е достатъчно, а още повече и да е изчерпателно... Категорично.

Ето защо изборът и преценката на хората от организацията за това кои са им CI за една услуга и в каква степен на детайли да бъде описвано всяко CI, трябва да се уважават и приемат с внимание. С повече внимание отколкото преценката на човек, който познава системата и услугите само от няколко дена или часа и, понеже е загрижен да не би да се скапе IT услугата, сяда и пише забележки. Пардон ... преписва забележки!

TPM - Total Productive Maintenance ... или на български - Тотална продуктивна поддръжка. Диагностика

Лийн (Lean) диагностика.
Инструмент на Лийн – ТРМ (Total Productive Maintenance)

10 Теми за проучване

1. Наличие на данни за оборудването и за поддръжката преди въвеждане на ТРМ. Експлоатация. Аварии. Настройки. Преоборудване (SMED дейности). Груби ОЕЕ сметки 

2. Обхват на системата ТРМ. Програма за въвеждане на ТРМ

3. Предпоставки за успех на Програмата

4. Автономност в работа на операторите на оборудване. Степени. Ограничения. Тенденции

5. Осигуреност в полза на операторите - техническа, информационна, методическа, вертикален канал

6. Работа на персонала по поддръжка. Вид организация. Видове квалификация. Взаимодействия  

7. Осигуреност в полза на персонала по поддръжка - техническа, информационна, методическа, ремонтни и други документи по оборудването, вертикален канал

8. Съвместни действия на операторите и персонала по поддръжка. Практики. Резултати. Тенденции

9. Информационно и друго ТРМ осигуряване в полза общо на персонала

10. Ефикасност на ТРМ (ОЕЕ показатели). Предпоставки в полза на други Лийн инструменти

FRAMEWORK ... Що за "рамка" е това? Стига вече с тази "рамка" ... или за изгубените в превода

Четем текстовете на стандарти и там откриваме, че става дума за ... някакви си "рамки".

Например, ISO 9001/т. 5.2.1 b), където става дума, че политиката по качеството трябва да "осигурява рамка за създаване на целите по качеството".

Например, ISO/IEC 27001/т. 5.2 b), където пък политиката по сигурност на информацията трябва да "осигурява рамката за поставяне на цели за сигурност на информацията".

Например, ... Не! Няма нужда от повече примери. Рамката се е настанила във всички стандарти. Любимото й местенце е там, където става дума за политики. Но понякога рамката се появява и другаде - също без да е ясно що за рамка е и какво търси тя в стандарта.

Къде е бедата?
Хората, които се занимават с проектиране и внедряване на системи, като стигнат до момента за определяне на цели, следва да внимават да не би някак си целите да изскочат извън някаква си там рамка. Те постигат това успешно, но без да могат да обяснят как са го направили и защо целите им са баш точно вътре в рамката и нито на грам/сантим извън нея. Одиторите от трета страна също внимават за рамката, но им е трудно да кажат дали една цел е вътре в рамката или е извън нея ... и така това се подминава мълчешком.

По-практичните хора пък зарязват размислите върху рамката и само внимават целите да са смислени. И май че имат право!

Отговорът е простичък. Някога, в добрите стари времена, мързелив преводач е видял в оригиналния текст на стандарт думата "framework", отворил е речника на "F" и е намерил значение на английското "framework" като "рамка". Само че "framework" си има и ред други значения. Даже публично осмиваният и все още шампион по загуба на контекст Google Translate, освен рамка, дава и други значения, сред които "структура", "скелет", "кофраж", "шаси"... Всички тези значения по-скоро ни навеждат на мисълта за "основа", върху която има нещо.

С две думи, ако framework-ът е не друго, а просто "основа", то нещата почват да изглеждат друго яче, нали?

Извод - махаме рамките! Слагаме основите! Махаме рамките и "животът продължава", както казват боксьорите и футболистите  (след като са дали "всичко от себе си") ... :)

(Не му е точно тук мястото, но все пак ...) "Индустриално наследство" - има ли то почва?

У нас има не една организация за разкриване, изучаване, опазване и демонстриране на културното, във всичкото му аспекти, наследство. Те са несъмнено полезен за страната ни терен за дейности, чрез които храним и усилваме чувствата си на национална гордост и черпим сили и вдъхновение за развитие и доказване в полето на културните ценности.

Онова, което пропускаме, може би поради забрава и неразбиране, е да обърнем също толкова внимание и грижи за онова, което в света наричат „индустриално наследство“. Като че ли се забравя, дай Боже да не се подценява, това че в редица случаи създаването на нов продукт или нова технология или иновационен пробив става с не по-малко по сила, но с друг вид творческо усилие. Постиженията на учени, инженери и технически специалисти са не по-малко ценни за националната ни съкровищница, макар някои от тях, гледани със сегашните ни разбирания, да сме склонни да осъждаме като наивни и остаряли по неписаните критерии на настоящето. В наши дни е много лесно да видиш като експонат в музей кости от динозавър, но едва ли някой някъде се е погрижил да запази и да покаже на поколенията, например, първият български транзисторен радиоприемник. И още – да се е погрижил имената на хората, които са го проектирали и произвеждали, да бъдат запазени. Това беше само пример, а иначе постиженията на българските учени, инженери и техници са хиляди, а стотици от тях заслужават да бъдат грижливо опазени. Само на места има отделни опити да се съберат и покажат ценни образци на инженерната мисъл, но няма нито един акт на сериозна национално представена институция в полза на нашето индустриално наследство. Оставаме пасивни пред акциите и инициативите на европейско равнище и не е известно какво е отношението ни към Резолюция 1924 (2013) на Съвета на Европа – „Industrial Heritage in Europe“ и към активността на ред национални, европейски и световни организации.

 В наши дни в обществото протичат процеси, който не помагат с нищо, а даже и вредят да се запази памет за индустриалните постижения от миналото. Смяната на собствеността на предприятията, промените в предмета им на дейност, залитането по новите технологии, окопаването на старите технически специалисти в пенсионното поле, криворазбраните грижи за екология, която обявява всичко старо за „опасни отпадъци“ за рециклиране и др.

Наложително е да се направи нещо, да се започне дори с малко, но с настойчивост:

·        за законова уредба в полза на издирване, изучаване и опазване на българското индустриално наследство и паметта за хората, които са го създавали;
·        за национален регистър на техническите постижения и хората, които са ги създали;
·        за създаване на българска широко представена организация;
·        за взаимодействие с европейските и световни структури;
·        за създаване на фирмени, регионални и национални експозиции;
·        за издирване на хора-носители на паметта за индустриалните върхове в страната;
·        за пропагандиране сред обществото на постиженията на българската техническа мисъл и за включване на темата „индустриално наследство“ в техническите учебни заведения.

Да действаме!

ISO/IEC 27001 - Идол на сигурността на информацията или просто най-обикновен стандарт?

ISO/IEC 27001 - Идол на сигурността на информацията или просто най-обикновен стандарт?

Най-обикновен стандарт си е и който си направи система да си пази информацията не може да плесне с ръце и да легне на тази кълка - "Уха! Имам система - край на тревогите за сигурност!"

Но да почнем подред... Защо трябва да приказваме за това? Ами защото последният, далеч не единствен, повод беше съобщението, което чухме тези дни (началото на юни 2016), че хакери гепили данни на хората от американския държавен апарат. Атаката била започната, казват, през декември миналата година, а пазителите на сигурността на американските чиновници се усетили през април тази година. Дано не е вярно, защото е, най-най-меко казано, потресаващо!
Тия чиновници и пазители, вероятно много добре платени, къде са спали цели сто дена?

"И какво от това?" може да каже някой нашенец. Ами това, че по нашите фирми шътат едни специалисти със строги експертни физиономии, които под шапката на одитори на системи за управление на сигурността на информацията, умело маскират некомпетентност и обърканите си представи от позицията на хора, силно загрижени за сигурността на информацията във фирмата, която одитират. Впрочем, всеки одитор се напъва някакси да излъчва компетентност. Какво е това "некомпетентен одитор"? То е нещо като сляп художник или като глух музикант.

Е, може би не всички са такива, но май повечето са... По какво се познават?

Първо, по това, че ... Газят първия принцип на одитирането според ISO 19011, наречен с непреводимата на български език дума "integrity". Подтискат клиенти с груби демонстрации на агресивна компетентност, тръснати на гърба на "некомпетентните" клиенти. А принципът, за който става дума, покрай официалните си обяснения, има едно, което е много важно - "Преди да си станал одитор трябва да си станал човек!" - ей това е "integrity", казано с едно изречение.

Второ, понеже ... Гледат настръхнали от загриженост и подозрение Декларацията за приложимост, за да видят дали има нещо изключено и ако има ... О, ако има!? Ако има, то изведнъж целият одит се свежда до това да се провери дали изключването е правилно и основателно... Но не само това. Не се спират до тук. Те трябва да Ви убедят, че сте прибързали и че сте сбъркали, че трябва да размислите и да включите каквото преди това сте изключили. Иначе казано, "Всичко, каквото сте си мислили и изводите от това мислене са за боклука"! Това ще прочетете в очите им, а те ще ви гледат сериозно и без да мигнат.  

Да си компетентен не значи да назубриш всички изисквания на стандарта и особено онези, които казват какво трябва да е документирано в една система за сигурност на информацията.
Компетентността трябва да стига до там, че да разбираш нещо много просто и очевидно. Че системата е точно такава, каквато трябва на фирмата. И че никоя система, ако ще да е и "най-най-съответстващата" на стандарта ISO/IEC 27001 не спасява организацията от атаки и от пробиви. Въпросът "Че защо тогава ни е да се мъчим да правим система за сигурност?" или "Защо ни искат такъв сертификат в търга (или конкурса)?" има един сигурен отговор. А той е, че системата учи хората на сигурност. Да знаят какво е това "сигурност" и как тя зависи от тях

Нека отговорим на въпроса, поставен тук в заглавието ...  ISO/IEC 27001 си е най-обикновен стандарт, който обаче, за да носи все пак някаква полза, когато го усвоим, трябва да е добре разбран и добре премерен как точно да бъде интерпретиран за фирмата "Хикс"