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).

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

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

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

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

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

И тогава ...

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

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

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

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

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

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