ISO 9001/7.3 (във версия 2008) - Кога проектираме и разработваме продукт?

Фирмената функция "Проектиране и разработване" я има и се прилага, ако се налага, дори и рядко да е, за да се създава съвсем нов продукт или ако ще се работи по значително модифициран съществуващ продукт. Продукт, освен по общата дефиниция като "резултат от процес", в ISO 9001 има две важни дефиниционни допълнения.

Само в ISO 9001 продукт е

1) "предназначен за или изискван от клиент" и

2) "всеки очакван изходен елемент от процесите за създаване на продукта".

За случая, който коментираме тук, трябва да припомним още и това, че като се каже "продукт" това включва и "услуга".

В ISO 9001/7.3 се изисква да се планира и управлява проектирането и разработването на новия продукт. Ясно  е - никой не сяда да се занимава с проектиране на съществуващ продукт!

Тук, в стандарта, смисълът е насочен към проектирането и разработването на нов продукт, който се отличава от съществуващите продукти/услуги с това, че наистина е нов - несъздаван, т.е. непроизвеждан, до дадения момент. Може да бъде съвсем нов или да е съществуващ, но със значителни преработки на конструкцията и подобрен - т.е. препроектиран.

Ще стане по-ясно от няколко примера ...

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

Различията и новостите стават още по-драматични и очебийни, ако произвеждаш велосипеди и мотоциклети (като съществуващи продукти в отдавна установени производства) и ти поискат, или ти си наумиш, да произведеш самолети. Картинката е същата, само че е още по-мащабна!

Да видим как е с услугите... И там трябва да се различават ясно съществуващата и усвоена услуга от някаква друга бъдеща нова услуга. Отново е добре да се говори с примери ...

Ако съществуващата и усвоена услуга ти е "спедиция на товари", няма да е нова услуга, ако ти се яви клиент и поиска спедиция в нова точка на дестинация за получател на товара. Но ще е нова услугата "резервация на фериботни билети", ако решиш в някой момент да правиш и това.

Ако услугата ти е "туроператорски дейности" и решаваш да си и "агент по продажби на недвижимо имущество", това ще трябва да го проектираш и разработиш като твоя нова услуга.

Може условно да говорим за три вида (пре)проектиране и разработване:

1. на нов продукт с перспектива за серийно производство, например мотоциклети;
2. на единичен и уникален нов продукт, без никаква перспектива за серийно производство, например уникален космически апарат;
3. на нова услуга - съществено различна от съществуваща и отдавна установена услуга.

Изискванията на ISO 9001/7.3 изцяло са предвидени за случая (1). Приложими са, макар и нетипично, към случая (2). И докато при (1) и (2) може лесно да различим нов от съществуващ материален продукт, в случая (3) може да изпаднем в заблуда и това налага още коментари.

Съществуваща услуга се изпълнява в работна среда, с инфраструктура, работни технологии, ноу-хау и други специфични дадености (ще ги наречем общо "базов инструментариум"), които гарантират това, че множество най-различни клиенти, с най-различни изисквания, ще бъдат удовлетворително обслужени в рамките на дефинираната като състав от дейности услуга.

Пак примери ...

Ако си фризьор (стилист), всеки клиент идва със своите различни и неповторими дадености и изисквания и може рядко да се случи прически да се повтарят. Да направиш нова прическа не изисква проектиране и разработване, а изисква добро владеене на похватите в занаята, иначе казано - добро владеене на базовия инструментариум на стилист.

Ако си ресторантьор, услугата може да е дадена като обхват така - "Посрещане, настаняване, приемане на поръчки, обслужване, представяне на сметка и изпращане на клиента". Новата манджа, която си решил да включиш в менюто на ресторанта, не ти е нов продукт. Всяка една манджа в менюто, включително и нова да е, просто е само атрибут или стока, с която се изпълнява услугата и не е нов продукт. Нова услуга в ресторанта ще е, ако въведеш чайна церемония по японски образец. Там поне един от елементите на съществуващата услуга, напр. "обслужване" ще е абсолютно нов и ще се нуждае от сериозно проектиране и разработване.    

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

Ако си преводач и владееш инструментариума за тази услуга (знаеш перфектно езика!) всеки нов клиент ще ти носи за превод нов документ (такъв, какъвто не си превеждал до момента - дори може да налага ползването на нов терминологичен състав), но услугата си остава същата - съществуващата и отдавна установената. Ако преводачът научи още един нов език, това само разширява прилагания за услугата инструментариум и не налага проектиране и разработване!

От примерите лесно се вижда, че докато при продукти от материални категории е фасулски лесно да се прецени дали имаме работа с нов продукт, то при услугите се налага да се мисли. Лесно е да се сбърка, че новия казус или новата поръчка предизвикват нова услуга (т.е. необходимост от проектиране и разработване). Лесно е да се бърка и с това, че новият атрибут/стока на услугата (например, нова манджа или някакъв нов вид товар за спедиция) водят до нова услуга. Най-лесно е да се сбърка, ако не си даваш труд да помислиш!

И така стигаме до един типичен и разпространен случай...

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

Какво би станало, ако всяка нова поръчка за клиентски софтуер мине по реда за проектиране и разработване, както е зададен чрез изискванията на ISO 9001/т. 7.3? Това няма да е фатална грешка, но ще спъне в значителна степен хода на проекта по създаване на софтуера, чрез излишната работа за дейности и записи, които стандартът изисква. Казано направо - това ще е глупав перфектизъм, с който системата за управление на качеството ще затормози оперативността на бизнеса и, в крайна сметка, ако все пак прежалим проектантите на софтуер и ги оставим да се блъскат, задоволявайки сляпо изискванията на стандарта, ще опрем до това, че ще пострадат клиентите - забавени срокове, неефикасни и изтормозващи съгласувания, водене на записи за преглед, проверка, потвърждаване и тромаво предлагане, преглед и разрешаване за внасяне на изменения. Така цялата история много заприличва на онази популярна приказка за изписване на вежди...

Жалкото е, че има уж опитни специалисти в бранша по консултации и одитиране на системи, но такива, че лесно се подвеждат на тема "проектиране" и стигат до там да налагат догматично техните разбирания по тази тема, без да се интересуват какво би станало с бизнеса на клиента им, ако той реши да ги послуша. Златната истина е една - ако търсиш най-подходяща и вярна интерпретация на изискванията на стандарта за даден бизнес, отправната точка винаги трябва да бъдат реализмът и трезвата преценка за интересите и възможностите на фирмата, която консултираш или одитираш. Просто е и трябва да го правим така!

Допълнение 1 - За педантичния одитор 

Това се случи наистина. Една фирма имаше достатъчен капацитет и ресурси - хора и всичко друго, за да проектира и наистина проектираше. Един хубав ден се разбра, че фирмата следва да има СУК по ISO 9001, за да кандидатства за хубава поръчка с голямо значение за бъдещето. Сроковете притискаха проекта за СУК, но накрая СУК стана. Една част като "голи" документи и записи, а друга част - със солидни доказателства от реално текуща практика. За съжаление, точно проектирането и разработването се оказа на ниво "голи" документи по простата причина, че за времето на създаване на СУК просто нямаше договор, свързан с проектиране. Но за сметка на това документите бяха изпипани и, най-важното, описваха точно живата им практика за провеждане на развойни проекти. одиторът не искаше да дава констатация, свързана с елемента проектиране на ISO 9001. Причината - хората от фирмата нямаше как да му покажат проект, проведен и документиран по нотите на стандарта. Одиторът беше мъдър... Изви ръцете и накара хората да документират стар проект, отпреди СУК, за да може в доклада си да пише, че е видял попълнени записи за проектиране, завършило с изработен нов продукт.

Каква би трябвало да е констатцията на одитора? Такава, че да изрази поне две или три неща:

1) че е установил наличие на документиран процес на проектиране и разработване

2) че този ред предвижда използването на изискваните от стандарта записи

3) че в момента на одита няма текущ или скоро приключен проект за нов продукт.

Одиторът е длъжен точно да докладва какво е видял и какво е разбрал. А не да отказва да признае очевидното, защото няма напълно завършени резултати. Не се одитира замръзнала в "стоп кадър" система. Одитира се когато трябва и тогава СУК е в някакво състояние, при което някои от фирмените функции може да са в процес на привеждане във "вид удобен за исото".

При тази констатация, по време на първи или втори надзорен одит ще се пита и търси наличие на проект, изпипан според "исото". Ето как нещата са лесни и прости. А нашият човвек беше казал на управителя "Не може да имате проектиране в обхвата, защото нямате доказателства", пропускайки поне две доказателства, според дефиницията за доказателство

1) "излагане на факти" за изпълнени успешни проекти в миналото, преди създаване на СУК

2) наличие на "документирана информация, в т.ч. записи", описващи процеса проектиране.

ISO/IEC 27001 ... Кой? Кой стои зад "организацията"?

Тук, за разлика от политическите страсти, въпросът си има чисто практически смисъл.

ISO/IEC 27001, а вече и не само той, насочват изискванията си към "организацията". 

Ето как възниква въпрос - "А кой тук е организацията?" Отговорът е различен и не е един ...

Нека да бъдем по-точни. Стандартът насочва изрично изискванията само към:

• "организацията" - за точките 4.1, 4.2, 4.3, 4.4, 6.1.1, 6.1.2, 6.1.3, 6.2, 7.1, 7.2, 7.4,               7.5.1, 7.5.2, 7.5.3, 8.1, 8.2, 8.3, 9.1, 9.2, 10.1 и 10.2;
• "висшето ръководство" - за точките 5.1, 5.2, 5.3 и 9.3;
• "лица под контрола на организацията" - за точка 7.3.

Няма други, освен тези по-горе. Явно се налага да дешифрираме кой е "организацията",
че дори може да се наложи да уточним и кой/кои са "висше ръководство".

В малките и много малките фирми въпросът се решава лесно - най-често само един-двама поемат голяма част от изискванията за "организацията."

Затова, нека си представим една средна по големина организация. 

В нея отговорностите може да бъдат разпределени между следните лица ... 

A.      Висше ръководство (само „първият“ ли или той и негови заместници ?)
B.      Представител на висшето ръководство
C.      Лице, което управлява програмата за одити (както препоръчва ISO 19011)
D.      Вътрешни одитори
E.       Мениджър на системата
F.       Ръководители на звена
G.     Сисадмин (или отговорник за IT)
H.     Отговорник обучения
I.        Отговорник за доставчици
J.        Съвет по сигурността или Работна група по сигурността на информацията
K.      Всеки от персонала
L.       Хора, работещи под контрола на организацията
M.    PR (хайде, нека има и черешка ...)

Една възможна схема за разпределение може да изглежда така ...

Ако тя е такава за "средна" организация, лесно е да се окастри, за да стане за малка.

Тази табличка е едно възможно решение и 100% може да има и по-сполучливи решения.

Но тук има нещо, което е толкова очевидно, че дори не прави впечатление - то е, че нито едно изискване не е насочено към външни лица, освен по т. 7.3 и някои контроли от Анекс А, които се отнасят до клиенти, доставчици и др. - т.е. до лица, от които наистина зависи сигурността!

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

Не е морално консултант или одитор да седне и да почне да определя кои са рисковете за една организация или да критикува (а не да съветва!) вече определени от организацията рискове.

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

Има поговорка "В чужд манастир със свой устав не ходи!". Така трябва да бъде!

ISO/IEC 27001 - стандарт за всякакви организации ли? (или Превръща ли се Анекс А в свещенна крава на сигурността?)

"Разгащване на сигурността" ... или "Кой дърпа свещената крава за опашката?"

Наскоро чух - имало колеги, които очаквали в новия ISO/IEC 27001 да отпадне Анекс А.

Не съм бил сред тях, но, ако наистина е имало такива хора, щях да се присъединя и аз към една такава ерес. Ерес, защото май на анекса се гледа като на свещена крава, от която ако падне косъм, т.е. ако си позволиш нещо да бъде изключено от този анекс, то е все едно че си разгащваш сигурността. Така се мисли. И не само мисли, но и действа. Например, в хода на проектиране и внедряване и особено при одита на системата за управление на сигурността. То едва ли не целият одит се фокусира в чоплене и в чесане на анекса и то само там, където има изключвания. Няма спасение - знае се, че ако те сърби, колкото повече се почесваш, толкова повече се настървяваш. От друга страна, трябва да проявим и разбиране - че то какво друго да му одитираш на система по този стандарт освен оценката на рисковете, планът за обработване на рисковете и следващата след това декларация за приложимост. Другото си е почти както при системите за управление на качеството.

Нямам нищо против - нека бъде така! Но не се разбира добре защо ... Да речем, някъде са изключили не съвсем обмислено някаква контрола от анекса. И да допуснем, че стане след това гаф - т.е. инцидент по сигурността на информацията. На чий гръб са негативите? Всеки отговор е верен, но едва ли най-пострадал от всички ще да е одиторът на системата. Един вид, той бил видял изключването, не го е оспорил, не е реагирал и следва сега да го сочим с пръст?!

Дали втренчването на одиторите в изключвания не е своего рода слагане на яка тенекия?

(да ги пази от ритници :) ... )

Е, не е така и не може да бъде! Както в една система по качеството може в ежедневието да има несъответствия (и някои от тях изразени даже като рекламации), така и при системите по сигурността несъответствия и инциденти може да има едва ли не пак като ежедневие. Колкото одитори са "изгоряли" поради несъответствия в качеството, толкова ще "горят" и ако клиентът им е допуснал инцидент поради изключване. На пръстите на ръката се броят такива случаи и то не говорим за България, а, доколкото е известно, и в света. Така че - спокойно!

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

Кое обаче подхранва онази ерес? Просто е. Казва се, че стандартът е за всякакви организации.

Например, както е за добре развита и технически грамотна IT фирма, така и за по-малките - например, малка спедиторска фирма или за адвокатска кантора с четирима души персонал. Случаят да притиснеш една по-малка фирма с цялата тежест на анекса (т.е. ако си си наумил да правиш сигурност с всичко от анекса - без да изключваш) е подобен на преминаването на камила през иглено ухо. И да премине камилата, системата става ужасна и неефикасна! 

На фона на всичко това има две светли петна в текстовете на новата версия на стандарта!

Нека им обърнем внимание...

Първото е текстът

„It is expected that an information security management system implementation will be scaled in accordance with the needs of the organization.“

(цитатът е от ISO/IEC 27001/т. 0.1).

Това изказване има много дълбок и много сериозен смисъл, който се отнася и трябва да засяга не само пряко изискванията на стандарта, но (забележете!) и анекса му. Но не е проблемът в това, че не се търси дълбокия смисъл. Проблемът е, че никой не се спира да чете и да мисли по тези начални точки от стандарта. Дали някой е умувал какво значи за практиката казаното в тази т. 0.1? Как заложената там идея ще се реализира за различни конкретни организации?

Второто е пак текстове ...

"The organization shall define and apply an information security risk treatment process to:

a) ... ;

b) determine all controls that are necessary to implement the information security risk treatment

option(s) chosen;

NOTE Organizations can design controls as required, or identify them from any source.

c) compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted;"

(цитатът е от ISO/IEC 27001/т. 6.1.3).

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

Но какво да правим?

Един адекватно и пълно определен контекст ще ни даде точния обхват и ще ни насочи към действителните за нас заплахи. 

Ще си сметнем точно рисковете, защото ние най-добре си познаваме уязвимостите. 

Ще преценим с какво и как да се защитим точно спрямо тези (не други!) рискове и, едва след като ни се изчерпат идеите за защита, ще си речем "Я сега да видим какво има в анекса ..."

И тогава ...

Как и защо да прилагаш защити за заплахи, които при теб в миналото и в момента ги няма?

Как да прилагаш защити, които по характер са за активи, каквито при теб няма?

Ами защита, която струва в пъти по-скъпо, отколкото евентуалните последици от инцидент?

Сигурно ще има и други главоблъскащи въпроси и, ако търсим верните отговори, лека полека ще стигнем до развенчаване на свещената цялост и комплектност на анекса.

Нека не дерем кожата на свещената крава и нека не си правим от нея пастърма! Може да я оставим да си пасе кротко, да знаем че я има, но да не й козируваме и да не й набиваме крак.

А ако стане нужда - винаги ще може да си я доим ... 

"Носи се!" Тройка стандарти с гарнитура. Не е луд който ги яде ...

ДА РЕАГИРАМЕ СЕГА! ИЛИ ЩЕ ЧАКАМЕ НАТИСК?

Да, натиск за усвояване на някои стандарти ще има и той ще ни дойде, рано или малко по-късно, от няколко различни посоки. По причини, някои от които са много добре известни, натискът идва на вълни. У нас, през последното десетилетие, вече мина първата вълна, която ни помете в посока за постигане на конкурентоспособност. Разбра се, че е доста стресиращо, ако сме в принуда да се мобилизираме притиснати от срокове и императиви. Онези, които предвидиха нещата, успяха да се възползват от предимствата да са първи и с времето пазарът им отвори врати и им се отплати.

Има и такава тактика – на изчакване, за да се види накъде отиват нещата, какво ще стане с първите и изобщо да се разсъждава на тема „има ли това почва у нас“ и „струва ли си ...“. Само че сега, докато чакаме, ще дойде новата вълна и историята ще се повтори. Пределно ясно е, че тук няма какво да се изчакава – трябва само да се погледне какво става по света. Достатъчно е да погледнем в сайта на ISO – http://www.iso.org/iso/benefits_of_standards, а също и материала в http://www.iso.org/iso/home/standards/benefitsofstandards.htm . Там картината е такава пак поради натиск, но основно от едно място – натискат клиентите, изисква пазарът.

Затова, нека поговорим за „втората вълна“ ...

Да поговорим за стандартите и ... още нещо

(по реплика от филма „Оркестър без име“)

Стандартите – пречка или полезен инструмент?

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

За разлика от продуктовите стандарти, онези, които наричаме „стандарти за системи за управление“, са нещо доста по-различно. Те съдържат само изисквания към системата за управление на фирмата (правилно е да се казва „организацията“, а не „фирмата“). Тези стандарти по-трудно „остаряват“, защото съдържат най-общи изисквания към системите, процесите и дейностите по управление. Това, че изискванията са общи, е възможност всяка фирма да ги осмисли, дешифрира и приложи по свой начин и то така, както е най-подходящо. Едно изискване на такъв стандарт може успешно да бъде приложено по много различни начини в различните фирми и с това да се отразяват техните специфики. Няма най-добър единствен модел и няма утъпкани пътища за поголовно и униформено прилагане на стандарт от всички. С това проектирането на всяка една стандартизирана система за управление, за да стане тя адекватна и ефикасна, се превръща в интересно предизвикателство, в чието решаване ограничения и закостенялост няма. Нужни са съобразителност и дори фантазия!

Кои са стандартите за системи и какви ползи има от тяхното усвояване?

Три от тях – ISO 9001, ISO 14001 и BS OHSAS 18001 са банално известни по простата причина, че ги има отдавна и още затова, че в последните години са се превърнали в дежурно условие, ако фирмата кандидатства за конкурс, търг, европроект или изобщо ако трябва, поне формално, да се отсейва читавото от онова другото (това беше „първата вълна“). ISO 9001 изисква от фирмите да прилагат системи за управление на качеството, ISO 14001 – системи за управление на околната среда и BS OHSAS 18001 – за управление на здравето и безопасността при работа. Характерно за ISO 14001 и BS OHSAS 18001 е, че поставят изисквания за управление на рисковете, но в тях става дума за рискове що се отнася до околна среда, съответно – условия на труд. Така, ако фирмата е приложила ISO 14001, тя гарантира, че нейната система за управление познава и отчита рисковете за околната среда, умее да управлява въздействията върху средата, познава и точно прилага съответните нормативни актове. Ако системата е по BS OHSAS 18001 – гарантира почти същите неща, но по отношение на условията на труд. С прилагане на ISO 9001 фирмата гарантира, че е постоянно способна да постига съответствие с изискванията към продукта, който доставя. Освен това такава фирма непрекъснато се стреми да увеличава удовлетвореността на клиентите си. В това е и основната полза от тези стандарти. Но има и други ползи, сред които и чисто вътрешни.

В днешни времена обаче клиентите, а и обществото като цяло, изискват от бизнеса (в най-широкия смисъл на това понятие) нещо в повече – да бъде сигурен и да бъде непрекъснат. Ако говорим за сигурността, тя се гледа в много по-широк хоризонт и обхваща по-богат спектър от рискове. Разглеждат се рискове за сигурността на информацията, за сигурността на доставките в логистиката, сигурност в транспортния трафик, сигурност в енергийното управление, сигурност в банкирането, сигурност при храните и в почти всички „чувствителни“ браншове. По подобен начин излизат на преден план и изискванията за постигане на непрекъснатост – фирмите трябва да са наясно със заплахите за бизнеса, които могат да прекъснат техни процеси и дейности, и да имат план за действие, който предвижда отговорности, ресурси и начини за реакция. Търсят се решения за бързо и с минимални загуби възстановяване, ако се реализира даден неблагоприятен сценарий.

Стандартите за рискове и непрекъснатост на бизнеса не налагат максималистични изисквания за сигурност и усвояването им не може да гарантира абсолютна и пълна защита спрямо рискове или абсолютно непрекъснат бизнес. Знаем, че тези неща са принципно невъзможни. Или по-скоро са възможни, но само в някаква реалистична степен, която клиентите ни, а и ние самите, считаме за приемлива и достатъчна за бизнеса, макар и да е непълна.

Ще расте популярността и може нататък да се окажат „банални“ и други стандарти. Кои са те?

ISO 31000 – управление на рисковете

Представя принципи и общи указания за управление на рискове, но без да се отнася към даден бранш или дейност. Щом, както стана дума по-горе, във всеки бранш навлиза материята „риск“ и „управление на рискове“, логично е да се подхожда по един универсален начин за всички случаи. „Универсалното“ на този подход е изразено достатъчно общо, за да може да се отнася за всеки вид риск и за всякакъв вид фирма/организация. Този стандарт не задължава с изисквания и няма за цел еднообразие в управлението на рисковете. Принципите и общите указания, възприети не буквално и цялостно, а в някаква обоснована от практическите нужди степен, позволяват на конкретната фирма да разработи методически инструменти за управление на рисковете и да ги съобрази и настрои към различните й потребности, специфични цели, обстоятелства, структура, дейности, процеси, функции, проекти, продукти, услуги, активи – или, с две думи – към нейните си реални практики. ISO 31000 помага за осмисляне и усвояване на отделните стандарти с изисквания за управление на рисковете и не е предназначен за целите на сертификацията. Свободата на избор на указания и на обхвата и степента на прилагането им е един от факторите, който прави системите за управление, съобразени с ISO 31000, да бъдат адекватни, действащи и ефикасни.

ISO/IEC 27001 – за сигурност на информацията

Стандартът е с основна насоченост към изграждане на системи за управление на сигурността на информацията и включва основно изисквания за устройството и действието на този тип системи. Под „сигурност на информацията“ стандартът дефинира опазването на поверителност, цялостност (в смисъла на коректност, точност, комплектност) и наличност (в смисъла на достъпност, възможност за ползване) на информацията в обхвата, който системата за сигурност покрива. Изискванията с ключово значение в този стандарт са организацията да определя (първоначално и периодично) рисковете, да ги подлага на оценка и да планира въздействия, променящи определените рискове. В крайна сметка всичко води до съставяне на план (първоначален и впоследствие преглеждан и актуализиран), включващ необходимите въздействия за обработка на онези рискове, които имат стойности над предварително зададени критерии. Стандартът дава свобода сами да си изберем защитни мерки (наречени „механизми за контрол“), но заедно с това предлага и обширен списък от „стандартизирани мерки“, представени в приложение към стандарта. И отново сме свободни да изберем от този списък онези мерки, които са смислени и приложими за нашия конкретен случай, а останалите от списъка да обявим за изключени поради неприложимост. В допълнение към този подход, стандартът подсеща, че борбата с рискове може да не е главното ни занимание. По-хитрото е, особено ако това не пречи на бизнеса, рисковете да бъдат избягвани или да бъдат пренасочвани върху други страни, с които организацията е или може да бъде свързана. Основна полза от прилагане на система по ISO/IEC 27001 е в промяната на отношението и на мисленето за рисковете, плюс създаването и прилагането на отработени действия за реакция на инциденти.

ISO 28000 – за веригите за доставки

Смело е да се предположи, но може да приемем, че прародител на стандарта ISO 28000 е бил известен флорентински търговец – Франческо Пеголоти (1310 - 1347) – който оставя за поколения търговци след него един безценен наръчник – книгата „Пазарни практики“ (Pratica della mercatura), в която грижливо описва многообразието от добри практики, обичаите, особеностите и рисковете, които могат да срещнат търговците по дългия 6000 мили път на коприната. Една от тези практики, без която коприната и другите стоки на далечния изток не биха достигали безпроблемно до Европа е била дългият път да се дели на части. Всяка част е била обслужвана от хора, които много добре познават рисковете на тяхната си територия, знаят как да ги избягват или как да се справят с тях. Всяка отсечка по пътя е била като звено от гигантска за времето си верига за доставки, а всяко от звената – със своите закони срещу лоши практики и със своите защити срещу посегателства.

Пътят на коприната съществува и в днешни времена, но вече носи отпечатъка на съвременните средства за търговия, комуникации и дистрибуция. Други са и рисковете по този легендарен път, а и по много други древни, днешни или новооткриващи се търговски пътища. Други трябва да са и начините за превенция или противодействие на рисковете във веригите за доставки. ISO 28000 изисква да се прави оценяване на рисковете, но тук стандартът посочва „в прав текст“ точно на кои рискове следва да се обърне внимание и това са рискове типични за веригите за доставки. В основата на работата срещу рисковете тук са поставени два акцента – за постоянни подобрения на изпълнението и акцент за точно съответствие с приложими за дейността на организацията нормативни актове. На тази основа стандартът поставя изисквания за полагане на цели, свързани с подобренията, за дефиниране на задачи, осигуряващи постигането на целите, чрез конкретни изпълнения и за управление на програми, които обхващат работата по целите и по задачите. Едно от изискванията е организацията да е наясно с рисковете, породени от свързаността с други звена, ако веригата за доставки е „дълга“. Такава верига включва изпълнители от които организацията „получава“ и има други изпълнители във веригата, на които „предава“. Силен момент в стандарта е създаването на готовност за действия в извънредни ситуации, като действията се основават на предварително създадени планове и процедури, настроени по набелязаните неблагоприятни сценарии. От всичко това, приложено в управлението и в практиките на една логистична фирма, следва безспорно основната полза от усвояването на стандарта – да се създаде и укрепи доверие не само сред клиентите на фирмата, но и сред всяка от свързаните с нея външни страни, участващи в логистични вериги. И още нещо – сигурността и доверието в една верига, които получаваш те ангажират със сигурност и доверие, които ти трябва да даваш на другите.

ISO 28000 е стандарт е за фирми, които са обладани от дух и амбиции за бързина и резултатност – такива, каквито са и у състезателите по щафетно бягане – да предадат щафетната палка от старта до финала най-бързо, най-сигурно и без инциденти.

International Featured Standards - IFS Logistics

ISO 22000 е стандарт, който определя изисквания за производители на храни, на услуги с храни или за храни и на оборудване за храни. Целта му е да се опазва качеството и да се поддържа безопасността на храните по хранителната верига. Понятието „хранителна верига“ е популярно с често употребяваната формула „от полето до масата“ или подобни на нея формули. Съвсем ясно е, че ако има хранителна верига, тя ще съществува и работи добре, само ако е обслужвана от съответна логистична верига. Логистичната верига трябва не само да опазва постигнатото качество на произведени храни, но да запазва и безопасността им. Средата и средствата за логистични дейности (складове, манипулации, транспорт) по правило се считат за източници на рискове за биологично, физическо или химическо замърсяване на храната. Има рискове и поради отклонения на температурни и други технологично определени режими. Първото нещо за логистичните вериги е те да се поставят на основата на добрите дистрибуторски практики – система от базови правила, която трябва да служи като основа-минимум, над която дейностите могат да се надстройват по изискванията на специализираните стандарти. Един от тях - IFS Logistics определя изискванията за одит и за логистично изпълнение. Последното му издание - IFS Logistics version 2.1 - е в сила и е задължително за прилагане от 01.09.2014 г. Разработен е от работна група с представителство на всички страни с отношение към логистиката, в т.ч. и органи за сертифициране.

Какво е характерно за IFS Logistics version 2.1:

·        стандартът е член на фамилия от шест IFS стандарти, основани на IFS Food;

·       обхваща всички видове транспорт, обслужващи транспорта дейности и складове;

·       прилага се за всички видове логистични дейности;

·       обективизира оценяването на системите чрез точкова система;

·       определя шест изисквания като особено важни за логистиката и критични при одит;

·       задава стандартизирана коригираща реакция при несъответствие в критично изискване.

Изглежда най-характерно за IFS Logistics е това, че изискванията за отговорностите на висшето ръководство са определени като критични (Knock Out), докато във всички останали стандарти няма специален фокус точно върху тези изисквания – за политики и цели, и за осигуряване на ресурси.

Интересно е, че цялата информация за фамилията IFS е свободно достъпна чрез специализирания сайт http://www.ifs-certification.com и е добре представена в популярните социални мрежи.

ISО 22301 – за непрекъснатост на дейността

ISO 22301 е стандарт, който поставя изискванията на цялото общество към всеки бизнес, който има претенции или намерения да има обществено значими позиции. За обществото вече не е достатъчно организацията да управлява качеството, да опазва информацията, да влезе в хармония с околната среда или да създаде и поддържа безопасна трудова среда. Направените усилия и постигнати резултати във всяка отделна област на системното управление имат нужда от политики, цели и поведение в посока на защита на вече направените инвестиции за такива системи и за създаване на висока степен на гаранции, че бизнесът ще бъде устойчив в рискова за обществото среда.

Основата за гарантиране на организационна устойчивост е в способността да се предвижда, планира, подготвя и изпълнява адекватен отговор-реакция на всяко най-вероятно събитие, което застрашава бизнеса, като спира или влошава обслужването на клиенти или бизнес връзките с трети страни.

Има ли и други стандарти? Кой или кои от всички тях да усвоим?

Има! А въпросът с избора, поне принципно, е ясен. Тези стандарти, съответно изборът им, са доброволни и се основават на осъзнатата нужда от тях. Ако беше само това, лесно щяхме да отсейваме фирмите по това дали са създали и поддържат съответна система. Заедно с това на пазара действа и добре познат административен механизъм, който е и главната причина за „банализиране“ на стандартите по формулата „тройка стандарти с гарнитура“. Тройката – това са споменатите в началото стандарти. Гарнитурата – това е справка, че фирмата не дължи нищо на НАП, не е в ликвидация и прочее удостоверения. Този механизъм е своеобразна административна тояга, която кара фирмите да скачат, за да се домогнат до участие и класиране по проект, търг, конкурс и др., при което стандартът е по-скоро бариера за преодоляване, а системата – средство за получаване на сертификат. Нека не правим това „у дома си“! А ако го направим, си заслужаваме червена точка, за да не се деморализира обществото!

Време е да отговорим на въпроса, поставен в заглавието.

Имаме два отговора и първият е „Криза е! Да изчакаме натиска, пък тогава ще мислим!“. Като се огледаме ще видим, че и други са решили да чакат. Едни ще чакат първо да решат проблемите си с персонала. Други ще чакат до последно да им се отвори конкурентен пазар. Трети ще чакат на яслата за европарите, ще кандидатстват, ще ги отхвърлят, но те пак ще пишат проекти – тези пари не са са изпускане. Да чакаш е удобна безпреспективна позиция. Така ще чакат всички, които тепърва им предстои да разберат, че проблемите с персонал, пазар, клиенти, ресурси и други подобни могат да се решават попътно с въвеждане на стандартизираните системи за управление.

Вторият отговор е „Действаме сега!“. Каквото и да е основанието за този отговор, то едва ли стига до осъзнаването на фактите, че въвеждането на системите не само стабилизира и дава основа за развитие на фирмата. Твърди се още, че погледнато от по-високи хоризонти, тази практика дава ефект и за развитието на браншовете, а след това и на националната икономика. Такива тези ще открием в цитираните в началото източници от сайта на ISO, но не като голословни твърдения, а като данни от пространни изследвания по строга методика и като case study примери с реални фирми, някои от които са известни и ги познаваме

ISO системите ... Някои "опорни точки" за подбор и оценяване на доставчиците

Има и такъв поглед върху нещата, че ISO стандартите за системи за управление са създадени, за да може да се опазва клиентелата от калпави фирми (т.е. организации). Не е съвсем така, но ако за момент го приемем за вярно, то ще видим, че изискванията на стандарта, дали най-пряко или по-косвено, но всички те са все в интерес на клиента. И ако потърсим дали има изисквания, които са повече в защита на интереса на фирмата, вероятно ще се спрем на тези, които са свързани с доставчиците.

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

От тази гледна точка си мислим, че е добре да се имат предвид някои "опорни точки", чийто източник са реални случаи от практиката. Защото практиката е по-богата на разнообразие отколкото замисълът на стандарта по отношение на подбора и оценяването на доставчиците 

За подбора ...

• Казус "Старите познати"
  нека не се занимаваме с подбор на "исторически утвърдени" към момента на проектиране на системата доставчици. Излишно е. Щом толкова време сме работили с тях, значи поне ги понасяме и търпим, а би могло да са и много добри. Направо ще си ги оценяваме, а в документите на системата ще пише защо за тях няма да има подбор;

• Казус "Да видим какво можеш ..."
  няма нужда от прилагане на голям брой критерии за подбор. Може изобщо да не се работи с критерии, а просто да се дава възможност доставчикът-кандидат да направи първа пробна доставка (или няколко такива), тя да се оцени и да служи като основание за избор;

• Казус "Подбор по време на пожар"
  може да няма време да се прави подборна процедура и да няма време за анализиране на първа доставка. Ако всичко е много спешно и "на пожар", достатъчно основание за избор ще бъде да поискаме и да получим една-две референции за доставчика. Нека това да е като възможност за shortcut на подборната процедура, но само при спешни случаи;

• Казус "Най-важният критерий"
  
  Почти всички критерии за подбор (а после и за оценяване) са обединени от една обща черта - тя е фирменият егоизъм. Фирмата ни иска да получава само такъв продукт, който съответства на изискванията, да бъде кредитирана от доставчика чрез отложено плащане, да няма проблеми с евентуални рекламации, да са къси сроковете на доставка, да е възможна извънредната и спешна доставка и прочее благини. Всяка от тях може да превърнем в критерий и да си имаме чудесен аршин за премерване на фирми-доставчици. На едно място обаче хората казаха "А бе хубави са тези критерии, но няма как да ги приложим. Шефът казва от кого да купуваме и това е цялата ни подборна процедура!" Какво да правим? Ами че нека добавим още един към критериите, които сме измислили, и нека този критерий се нарича "Доставчик, харесан от шефа". Е, нищо че критерият май ще е с бинарни стойности - "харесван"/"нехаресван"... Важното е, че той ще се окаже водещ и най-важен! Някой път това се оказва неочаквано основателно ... 

• Казус "Ще купуваш от когото аз ти кажа!"
  
  Така може да каже клиентът и даже може да ни го наложи като изрично условие в договор. В този случай ще трябва да загърбим нашата си система за подбор, колкото и добра да е, и да се съобразим с искането на клиента. Защото това искане става част от договора и трябва да бъде изпълнено, ако искаме да не изтървем един такъв "особен" клиент. Тази ситуация възниква, когато клиентът прави голяма поръчка, когато поръчката е за особено отговорни продукти и особено ако отговорните продукти са с повишена степен на опасност (съдове под налягане и други ... )

La réalité dépasse l'imagination (Реалността надминава въображението) - казват французите. Ще се съгласим, че в случая с подбор на доставчик животът може да ни срещне със ситуации, които ще ни накарат да гледаме с по-широки разбирания и толеранси спрямо обичайния подход към изискването за подбор. Почти същото може да кажем и за оценяването на доставчиците.

За оценяването ...

• Казус "Твърде много, но различни по обем на доставките доставчици"
  Ако доставчиците са изключително много на брой и доставят един и същ продукт/услуга и то в различни - от много малки до много големи количества - не е зле да въведем "количествена квота", според която "доставчик" от гл.т. на системата е, който за даден период доставя повече от числото ххх (числото за количество трябва да определим, изхождайки от практически съображения). Тогава ще оценяваме не стотици, а само десетки, или десетина доставчици, а това в редица случаи е най-разумен вариант. Това се случва във фирмите, които имат кампании за изкупуване на земеделска продукция, особено ако продукцията се събира за съхранение в огромни общи силози и други подобни хранилища с много големи обеми;
  
  
• Казус "Твърде много, но различни по вид на продуктите/услугите доставчици"
  В този случай ще разсъждаваме на база на това, че не всички доставяни продукти/услуги са еднако важни за нас. Така ще стигнем до определяне на поне три "А, В и С" категории доставчици и за всяка категория ще има различен механизъм за оценяване - различни критерии, различна честота/период на оценяване, различни по характер действия, които следват според стойността на получената оценка. В частност може да стигнем до това, че най-маловажната категория доставчици или няма да подлежи на оценяване, или оценяването им ще става през двугодишен или тригодишен период; 
• 
  
• Казус "Твърде много, но и твърде важни доставчици"
  Тук нямаме избор. Всеки доставчик за всяка доставка трябва да бъде оценяван. А това че са много е проблем, но той не е толкова болезнен, ако се сетим да "качим" оценяването в екселски файл. Още по-добре е да вкараме оценките в работните записи/файлове, които нормално ползваме при заявки към доставчиците;

• Казус "Велики доставчици"
  Ако доставчици имат статут на "доставчици-партньори" (т.е. такива, с които са сключени дългосрочни договори), най-логично е те изобщо да не бъдат оценявани. Тук може да разсъждаваме така - щом имаме договор с такъв "велик" доставчик, значи сме го проучили много внимателно и сме решили, че точно този доставичк е нужен за бизнеса ни. Типичен такъв случай може да е IT фирма, която има договор с Dell или Microsoft или други подобни световноизвестни компании. IT фирмата купува от тях продукти и поема ангажименти за услуги от тяхно име (сервизна поддръжка и други) и, строго погледнато, Dell и Microsoft са нейни доставчици. Ще седнем ли ние - от скромната IT фирмичка - да оценяваме Dell, само защото "исо-то" искало да се оценяват доставчици? С две думи - Може и да не оценяваме наши доставчици-партньори. А "исо-то" ... да си гледа работата!

• Метод "Обратна мишена" 
  Нормалната мишена е от 1 до 10, като да улучиш/получиш 10-ка е най-добре, а 1-ца - зле! При "обратната мишена" пък да имаш "0" е ОК, а 1, 2, 3 - колкото повече, толкова по-зле. Добрите доставчици оценяваме с "0" - т.е. не им пишем никаква оценка. Просто са добри и толкова! Пишем "1", ако нещо сбъркат, но нещо дребно и поправимо, което не се усеща от клиента. Пишем им "2", ако сбъркат повече и то така, че и клиентът ни да усети. И накрая - пишем "3", ако клиентът не само е усетил, но е изразил и силно недоволство. Обратната мишена е подходяща, ако работим интензивно с много доставчици и те, 80% от тях, са си ОК. Така оценяването не ни натоварва, защото реагираме само на гафове и пишем 1, 2, 3 като "предупредителни точки". На едно място обаче казаха "Не е коректно всички добри доставчици да ги зануляваме! Как ще отбележим тези от тях, които са били, по някаква причина, най-добри сред добрите?". Така се наложи скалата за оценяване от (0, 1, 2, 3) да се разшири така - (S, 0, 1, 2, 3). Защо "S"? S = Super!

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

 

ISO/IEC 27001 - т. 6.1 "Actions to address risks and opportunities" - Какво иска от нас стандартът в тази си част?

Не само за ISO/IEC 27001, а и за ISO 9001 и за други стандарти съм чувал съм хора да питат -

"Как да си определим рисковете за сигурността на информацията?" или даже 

"Какви рискове да си измислим, за да си направим системата?".

Има и един друг въпрос, съдържащ силен драматичен заряд - а той е
"Кой трябва да ни определи рисковете?".

Най-драматичен е въпросът
"А какво е риск?"

и този въпрос предизвиква още по-драматични и безизходни, като че ли, спорове. Спорове, защото всеки знае за себе си какво е риск...

(текстът в Italic е актуализация от 18 март 2020 г.)
А трябва да се тръгне от средата (т.е. обстановката) -- вътрешна и външна -- и въздействието й при нас. В MMS стандартите за средата се говори в точка 4. Контекст. Там се изисква контекстът (съвкупността от вътрешни и външни фактори) да бъде установен, изучен, редовно наблюдаван и данните -- ползвани за актуализиране на системата, за да може тя да е в тон със средата, в която съществува.

Към днешна дата, когато тази публикация се актуализира, у нас е въведено извънредно положение във връзка с обявената пандемия от вируса COVID-19. Тази внезапна  промяна в контекста (дали  пък наистина е внезапна?) със сигурност има силно влияние и генерира ред нови заплахи, съответно и рискове. Една система е "жива", когато вижда и реагира при промени. Трябва да се почне от там, че пандемията и извънредното положение са факт и след това да се определят рисковете, да се оценят и да се планират мерки за модифицирането им. Защо "модифициране", а не "намаляване"? Кризи като тази носят със себе си не само рискове, но и възможности и често тези два компонента са смесени...

Ако си пътешественик по света, ти се движиш в рискова среда. Успехът на пътешествието и достигането до целта зависят много от познанията за средата, в която ще се движиш и от точната преценка за собствените ти ресурси, сили и възможности. От ключово значение е познанието за рисковете в дадена среда. Едно е да се стягаш за пътешествие към северния полюс, друго е да се готвиш да оцелееш прекосявайки австралийската пустиня. Може даже да си помислим, че нито един от "рисковете на северния полюс" не съществува като "риск на пустинята"... Но дали наистина е така не се знае и трябва да се помисли добре, за да сме сигурни. Впрочем, знае се, в австралийската пустиня, освен опсности, има и злато.

Трябва да се мисли много за средата и когато се стягаш да си направиш система за управление на сигурността на информацията. Не можеш да създадеш адекватна и ефикасна сигурност, ако не си наясно с рисковете. А те са различни (по вид, експозиция и други характеристики) и зависят от средата, която "заобикаля" организацията и от елементите на средата, "обхваната" от самата организация, която пък наричаме "вътрешна".

Бързите отговори на горните въпроси са...

На първите два въпроса краткият отговор е - "Трябва да си наясно, и то с подробности, за средата - вътрешна и външна - в която се намираш. Едва след това си правиш сметка за рисковете и така те не се "измислят", а всеки от тях има някаква връзка с елемент(и) на средата." Стандартът тук ни казва "Определете контекста!" и смисълът е точно в това.

На въпроса "Кой трябва да ни определи рисковете?" стандартът ясно изисква - Организацията! За какво по-конкретно става дума като се каже "организацията" може да има различни и все правилни отговори, но най-важното е това, че "организацията" - това сме НИЕ. Да го кажем направо - никой ВЪНШЕН, който и да е той, не може да ни натрапва свои виждания за рискове и да коментира критично НАШИТЕ рискове. Нека забраним на този, който е "външен експерт", независимо от каква експертна позиция ни се представя, да не излиза извън рамките на внимателен и доброжелателен съветник. Но не и ментор! Това пък с обратна сила ни ангажира в изключително голяма степен да сме отговорни и компетентни когато се занимаваме с определяне на НАШИТЕ си рискове и, в допълнение към това, да можем категорично да доказваме валидността и адекватността на преценките, които сме направили. С какво да започнем? Първо с типичните за нашия бизнес заплахи. Всеки бизнес има такива и всеки трябва добре да си ги знае. Доброто им познаване води до изграждане на защити по естествен път, без изобщо да говорим за изисквания на стандарти и други подобни "силови схеми" от този род. Пример - банките правят стрес-тестове, банките са поставени в законово регулирана среда, банките са под лупата на независими надзорни органи ... и какво ли не. И в същото време всички знаем, че банките не са "цвете за мирисане". Което естествено ни навежда на идеята, че броя и силата на защитите от рискове не ни освобождават от необходимост да имаме поглед върху ефикасността на тези защити. И много често тази ефикасност страда от разминаване или загърбване на реалностите на контекста. Сега вече е ясно защо първоначалното изясняване на контекста тръгва от популярния PEST анализ, в който "Е" е за най-общата икономическата среда, а "S" - за най-общата социална. Впрочем, и да не си банка, упражнението, наречено PEST анализ, никак не е излишно и никак не е случайно, че това упражнение започва с "P" анализа, свързан с политическата среда. Звучи ли пресилено? Ако да, попитайте днес българските, унгарски, хърватски и други превозвачи какво си мислят за последните инициативи (всъщност - натиск!) на френските управници пред евроструктурите за въвеждане на нови правила в превозваческия бизнес. Тепърва предстоят интересни събития.    

Но какво е "риск" за сигурността на информацията?

Нека, за пример, преди това попитаме "Пожар" риск ли е? Не е! "Пожарът" може да е "събитие", "понятие", "дума", ако щете. "Пожар" не енищо друго, освен вид заплаха.

За да стане заплахата риск, трябва да говорим и гледаме конкретни обстоятелства в конкретна среда. "Пожар в нашето сърверно помещение" вече е риск (той, естествено, ще е различен от риска от пожар в някакво друго сърверно помещение на други хора). Така това обвързва заплахата с конкретен актив на конкретно място, а това ни дава възможност да правим близки до реалността преценки за вероятността от пожар на това място и за последиците от такъв пожар за нас.

Да караме нататък... "Критично прекъсване на дейността в резултат от пожар в сърверното помещение" също е риск и той може да има по-различна стойност от преди преценения риск от пожар в сърверното помещение.

Още по-нататък... "Загуба на управление на обекти след критично прекъсване на дейността поради пожар в сърверното помещение" също е риск.

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

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

В църквата, преди четене на евангелие, попът казва "Да внимаваме!"

Не е зле и ние да внимаваме, когато четем стандартите! И да мислим!

ISO/IEC 27001 - Декапитация или коронясване - т.е. нека сме наясно с рисковете и възможностите (risks and opportunities)

Какво е "декапитация"? Това е рязане на глава (в контекста на бизнеса - тотално съсипване). 

Коронясване - това всички го знаем (пак в същия контекст - възход и благополучия). 

Тези две действия брутално илюстрират замисъла, усвоен и от стандарта за сигурност на информацията, в който централно място заема онази част, в която организацията (т.е. ние или по-скоро онези, на които ще бъде възложено) трябва да се занимава с планиране на действия за справяне с рискове, носещи вреди (съсипване) и реализиране на възможности (благополучия).

Някои казват "Няма такова нещо като възможности. Всичко е рискове!" и донякъде са прави. Но само дотолкова, доколкото може да наричаме всичко "рискове". Реално се налага да гледаме по различен начин на две категории рискове. Едните са рискове, които категорично и еднозначно водят към неприятни и нежелани последици (риск от пожар, риск от кражба и много още други ...), а другите са рискове с амбивалентен (както биха се изразили някои учени хора) заряд. Казано по народному и популярно "Риск печели - риск губи". 

За първата категория рискове гледаме да направим така, че те да не се реализират. За един риск от втората категория, ако установим че имаме такъв, се налага да се замислим и да търсим баланса - "Колко ще спечелим, ако ... и колко ще загубим, ако ...". При това балансът може да излезе такъв, че да ни накара даже да усилваме риска от категорията "възможност", а не да го намаляваме. 

В този смисъл "действия за справяне" (actions to address) с рискове не може да означава единствено ликвидиране или просто намаляване. Такъв смисъл трябва да разчитаме и в термина "въздействие върху риска" (risk treatment), който термин означава "процес на променяне" или преобразуване (process to modify) на риска. Целта при такова променяне или преобразуване е да се стигне до ползата, която носи възможността.

ISO 9001 - Някои неща относно целите по качеството...

Целите по качеството...
В практиката те често са проблем - "Откъде да ги вземем?" или "Как да ги измислим?"

Нека първо да тръгнем от идеята, че всяка фирма/организация си има свои цели и си ги "гони".
Даже и да не са записани, ръководствата си ги знаят или са им постоянно в съзнанието.
Че дори такива цели са твърде близки или почти еднакви в много фирми.

Звучат така ...
  "Увеличаване на пазарния дял ..."
  "Снижаване на разходите ... "
  "Нарастване на печалбата ... "
  "Повече нови клиенти ..."
  "Задържане на съществуващи клиенти ... "

... сами ще се сетите и за още други подобни

"Тук няма "качество" изобщо!" - ще спори някой.
"Не! Всичко е качество!" - ще каже друг... и ще е по-скоро прав, защото не става дума само за качеството на продукта, но най-вече и на управлението.


Да потърсим някои ориентири. Те ще важат и за другите системи, но нека се спрем само на тези в системите по качеството ...

1) Не търсете тези цели непременно да са точно "по качеството", сякаш са някакви строго специфични и отделни, здраво свързани с нещо, което олицетворява "качество". 

2) Не се напъвайте да ги правите измерими непременно с числови стойности, ако характерът на някоя цел е такъв, че не предполага числово изражение. Може да са измерими в стойности на степени (ниско, средно, високо), бинарни стойности (изпълнено, неизпълнено) или даже груби "векторни" показатели (регрес, застой, напредък), които показват само посока на ръст/спад, но без да става дума за някакви стойности - нито числови, нито в степени.

3) (във връзка с горното) В някои случаи вида измерител съответства на неопределеността или на обема и богатството на ноу-хау и като така той би трябвало да се мени. Тръгваме от типа "векторни" измерители, когато не сме сигурни как по-точно да измерваме. След натрупване на реален опит минаваме към измерители от типа "степен". Нататък, ако характерът на целта позволява, ще преминем от "степен" към "числови" измерители. Въпросът с типа "бинарни" измерители е ясен - няма какво да се коментира. 

3) Потърсете целите по качеството най-напред сред фирмените цели - т.е. сред тези цели, които реално ръководството гони и е заинтересувано да се постигат. Почти всяка една фирмена цел може или пряко да се пренесе (1:1) на "територията" на системата по качеството, или се пренася във вид на производна на фирмената цел. Друг въпрос е, че тези фирмени цели, ако ги търсите написани, може и да не ги намерите. Затова - просто поговорете с шефа.

4) Цели по качеството - ако искаме да са максимално близки по съдържание до заложеното в стандартите, ще трябва, преди да посегнем да формулираме цели, да се запознаем по-внимателно с някои дефиниции (вижте постинга "Цели по качеството ли са "търговските цели"?").


Има и друг проблем в практиката - отношението на някои одитори, когато проверяват цели... Критикуват ги!
1) Критикуват безпринципно цели. Казват - "Това не може да Ви бъде цел по качеството!"
2) Критикуват измерители на цели  - "Този измерител не Ви върши никаква работа!"
3) Изискват непременно измерителите да са числови...
4) Не виждат целите като особен вид формулировка на ползи, които фирмата иска да постига. Така някои цели им се струват странни, привличат любопитството им и се налагат разяснения, чийто смисъл често не достига до съзнанието на одиторите, просто защото са външни човеци. Дискусиите по такъв тип цели, подклаждани от одитор, могат силно да изнервят хората и да смъкнат до нула доверието в процеса на одит.

По повод на 1) и 2) ... И друг път е ставало дума, че Политиката по качеството и Целите по качеството са малко по-особена материя в системата по качеството. Материя, зад която стоят идеи, дух, воля и прави тези два елемента на системата "свещена територия", недосегаема за "дълбокомислени" закачки от типа "Каква е тази Ваша Политика... " или "Това не може да Ви е цел... ".

Трябва да се помни добре, че стандартът дава за политиката два вида изисквания - изисквания за управление и изисквания за съдържание. При това тези последните са малко и са достатъчно общи. Така става ясно - една фирма/организация може да си има каквато иска политика. Или с други думи - нека одиторите се занимават само с изискванията за управление

За целите нещата са подобни. За тях пък стандартът дава изисквания само за управление - да са измерими, да се декомпозират по нива и функции и т.н. Какви ще са целите - фирмата сама си решава и каквото си е решила - всеки "козирува" и ги признава.

Политика? Цели? No comments!

Избор на консултант - има ли практически ориентир?

Със сигурност има! Или поне могат да се измислят, така че да са ефикасни - т.е. при прилагането им да няма нежелани отклонения и драматични разлики между избора и реалността...

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

Всеки зъболекар  оправя всички зъби в цялата уста. Те не специализират по кътници, кучешки или други отделни видове зъби. Горе-долу така са и браншовете за консултанта ...

Ако говорим за консултации по стандартизираните системи за управление (ISO системите), то въпросите към кандидат-консултанта трябва да са в други посоки:

- освен с консултиране, занимавате ли се и с друга дейност (върти търговийка, кара такси, DJ)

- от колко години (без прекъсване!) сте консултант (не се става консултант за две-три години)

- по колко от ISO стандартите консултирате (само ISO 9001? Колкото повече, толкова повече :)

- в колко различни бранша сте били консултант (браншовото разнообразие обогатява)

- кои са най-добрите (големи или най-интересни) Ви проекти (има ли с какво да се похвали?)

- какви референции може да представите (има ли кой да го похвали?)

- има ли квалификация на одитор от трета страна (ако има - изпитван е дали знае стандарта)

Ключовият въпрос е "В колко различни бранша сте били консултант?" и той, в известен смисъл, е съвсем обратен на "Имате ли опит в нашия бранш?"

Ако консултантът е работил в повече от десет (примерно!) бранша, това му дава здрава основа да интерпретира гъвкаво изискванията на стандартите към всеки нов бранш.

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

П.С. В момента по радиото са пуснали концерта за цигулка в ре-мажор от Бетовен...

Единственият му концерт за цигулка. Няма друг. Преди да го композира, той не е имал никакъв, съвсем малък дори, опит с концерти за цигулки. Просто си е имал опит да композира!

ISO/IEC 20000-1 ... "Ега ти стандарта, ега ти чудото ..." чух по телефона, след като разказах някои простички основни неща за стандарта

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

На въпроса "Консултантът, който сте ползвали за системите по ISO 9001 и ISO/IEC 27001, защо не го ангажирате него за системата ISO/IEC 20000-1?" отговорът беше "Консултантът не иска да се занимава - казва, че стандартът е смотан... "

Това вече заслужава да се коментира! При това първият коментар може да бъде, че консултантът е по-скоро прав! Само дето не би трябвало да се изразява точно така. Нищо не подхожда по-добре като характеристика на ISO/IEC 20000-1, както нашенската поговорка "Пременил се Илия - пак в тия!". Предишната версия на ISO/IEC 20000-1, май че беше от 2008 година, си заслужи напълно ненавистта на потребителите на стандарта. Господата в JTC 1 на ISO и IEC изглежда са се усетили за това още на другата година, защото "новата версия" на "чудото ISO/IEC 20000-1" се появи скоропостижно през 2011 година. И уж да стане по-ясна и по-човешка, новата версия си е пак "смотана", както казал колегата консултант.

Кои са категоричните недъзи на "чудото ISO/IEC 20000-1"?
- категорично стандартът не е за всякакви организации и всякакви IT услуги. За по-малки фирми и за по-специфични услуги той направо е неадекватен
- задължителните (само за една услуга!) документи, записи, доклади, планове, политики и разни други бумаги са толкова много, че ти идва да кански да изревеш
- някои от изискванията на "чудото ISO/IEC 20000-1" са такива, че за някои услуги те или не може да се приложат по начин близко адекватен на заложения в тях смисъл, или може, но с цената на безумно отвлечени, деформирани и ирационални интерпретации, които, ако се сетиш в един момент за тях, става ти неудобно пред хората
- една част от изискванията на стандарта са толкова далеч от живата и разумна практика, че може да изпиташ срам да убеждаваш хората да правят еди какво си, а в някои случаи изисквания от този род опират и до доставчици и до техните доставчици

Има и някои недомислици, близки до категорията "бисери"...

Ако е вярно, че авторитетната британска ITIL е била "майката" на ISO/IEC 20000-1, то се сещаме и за друга нашенска поговорка - "Напънала се планината и родила ..." само че не мишка, а някакъв Франкенщайн в полето на стандартите. То за това принос сигурно има и бащата... А кой ли е той? В този момент всички погледи се насочват към JTC 1... Особено плодовит баща... "Чудото ISO/IEC 20000-1" е уж подпряно от многобройни патерици (ISO/IEC 20000-2, -3, -4, 5, ...), само че те, вместо да го подпират, го спъват още повече.

Но да се върнем на "единия месец"... То е все едно някоя да се изрепчи на гинеколога и да му иска да си износи детето за един месец.
А на тези, които замислят търговете какво да има кажем? Ами... нека помнят, че имаме и друга една поговорка - "Не е луд, който взема зелник по ISO/IEC 20000-1 за един месец... ". Те са умни - ще намерят начин най-после да спрат това!