ISO 31000:2018 - Ново издание - нов късмет! С претенции за по-ясен смисъл и по-кратък текст (само 16 листа?)

ISO 31000 вече е освежен, по-ясен и по-кратък, според разпространяваните прес-съобщения.

Без още да сме го виждали, нека се опитаме да познаем как изглежда сега новия...

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

"организационна рамка на управлението на риска - съвкупност от елементи, създаващи основите и ръководните организационни разпоредби за разработването, внедряването, наблюдението, прегледа и непрекъснатото подобряване на управлението на риска 

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

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

А който се е интересувал да разбере що за "съвкупност от елементи" и за какви елементи става дума, четейки т. 4 на стандарта, бързо е разбирал, че това е не само досадна, но и уморително разтеглена надълго и нашироко част на стандарта. Просто хората от технически комитет ISO/TC 262 "Risk management" не са се съобразили, че в 90% от случаите  от ISO 31000 се интересуват организации, които вече имат други някакви стандартизирани системи за управление, т.е. минали са вече по пътя и знаят как се изгражда система. На такива хора е излишно да се говори отново за PDCA, водачество, политика, роли, ресурси, прегледи и прочее вече почти банализирани ISO хватки. 

Не по-малко живописен беше термина ...

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

За нас, българските потребители на стандарта, ще е важно да видим как нашия комитет в БИС ще се справи с превода от английски, където преди английските probability и liklihood бяха подкастрени с универсалното българско "възможност" и това си беше изненада, защото сме очаквали думата да е "вероятност". А защо англосаксите (както взеха напоследък да ги наричат) ползват лукса да имат две различни думи за едно нещо, в контекста на материята на стандарта, това едва ли някой ще разясни, а и си е отделен въпрос. Слава Богу, в новото издание тази амбивалентност май ще изчезне и ще остане само liklihood. Притеснението за превода идва от това, че подмяната на "вероятност" с "възможност" абсолютно сигурно обърква хората, които ползват другите стандарти за управление и в тях четат (в ISO 9001 примерно), че се говори за "рискове и възможности" - т.е. рискове, носещи потенциални вреди и възможности, носещи потенциални ползи. 

Ето с такава цел сме приемали, че функцията РИСК има като минимум два аргумента и те са ВЕРОЯТНОСТ и ПОСЛЕДИЦИ. Думата "вероятност" трябва да се счита запазена за употреба само във връзка с понятието РИСК и за нищо друго, освен РИСК. 

Би могло да се каже, че пътят към формално, половинчато и калпаво прилагане на стандартите е постлан с небрежно и неточно дадени термини. Да стискаме палци за БДС ISO 31000:2018 ... 

  

ISO/IEC 27001/A.6.2.2 - Да работиш от разстояние - предимства и ... още нещо

Предимствата да се работи от разстояние може да са много и очаквано хубави. 

Например, ако пропадне Интернет връзката, може да си легнеш и да подремнеш.

Най-разпространено предимство е, че не ти се налага постоянно да се скатаваш от шефа.

Ако гледаме сериозно, трябва да се каже, че да се работи от разстояние понякога се налага.

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

Целта е да има защита на информацията, която се достъпва, обработва или съхранява на отдалечените места при режими на работа от разстояние. Тези режими следва да са свързани
с изрично зададени условия и ограничения. Механизмът за контрол ISO/IEC 27001/А.6.2.2 изисква да бъде разработена политика и поддържащи я мерки. Отново може и тук да се каже, че политиката и мерките, за които става дума, може да са поставени в един общ документ, който съдържа разработени от нас, за всеки конкретен случай, изисквания.

Какво може да бъде предвидено в такава политика и свързаните с нея мерки?

1. Може да не се допуска отдалечен режим на работа – изобщо или в определени случаи

2. Отдалечените места трябва да са физически добре защитени срещу проникване

3. Средата, в която се намират местата, следва да е сигурна (не се счита за криминогенна)

4. Комуникационният канал за отдалечен режим на работа да е защитен

5. Да не се ползва софуер и методи за отдалечен достъп от типа Teamwork или подобни

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

7. При работа да няма взаимодействие с други мрежи (вкл. безжични) намиращи се на мястото

8. При работа да не се засягат лични данни и друга чувствителна информация

9. Да не се нарушават лицензи и права, придобити от други страни

10. Може да има изисквания какви оборудване и протоколи да се ползват за работа

11. Може да са определени дни и часове, в които такава работа се допуска/не се допуска

12. Може да се посочва каква информация не може да бъде предмет на работа от разстояние

13. Може да има особености, свързани със сервизната поддръжка на ползваното оборудване

14. Може да се иска прилагане на процедури с изисквания за за backup и непрекъснатост

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

16. Да има правила за връщане на активи и за спиране на работата от разстояние от мястото

В този дух може да се зададат и други изисквания - всяко друго смислено нещо в допъление, или вместо, горните 16 точки, ще е полезно. Стига да е постижимо, да произлиза от реално установени рискове, а не произволно измислено

ISO/IEC 27001/A.6.2.1 - Mobilis in mobili

"Mobilis in mobili" (Подвижен в подвижното) беше девизът на капитан Немо с неговата подводница "Наутилус". Като че ли същия девиз, но в друг контекст, приляга отлично на сигурността, която изисква стандарта в Приложение А/А.6.2.1 при мобилните устройства.

Да оставим настрана въпроса, че няма официална дефиниция за "мобилно устройство"

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

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

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

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

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

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

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

При осигуряване на защити, за да не се изпада в перфектизъм (излишни усилия и разходи), е добре да вникнем в изискванията на стандарта ISO/IEC 27001/Приложение А.1/А.6.2.1 и в указанията на ISO/IEC 27002/точка А.6.2.1.

ISO/IEC 27001/Приложение А.1/ А.6.2.1 не ни дава много – разбираме, че се иска само политика и мерки за сигурност, които да я подкрепят, когато се ползват мобилни устройства.

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

ISO/IEC 27002/точка А.6.2.1 помага да насочим вниманието си по-практично, защото там става дума за „рискове при ползване на мобилни устройства в незащитена среда“. Налага се да си зададем въпрос „Какво е незащитена среда?“ за нормалните условия на бизнеса ни. И втори въпрос – „Конкретен тип незащитена среда какви заплахи генерира?“. Така ще имаме данните, които са ни необходими за оценяване, което ще ни даде рисковете (вероятност и последици).

От отговорите на въпросите и от оценката ще зависи колко и какви мерки ще търсим. Ще се наложи да си помогнем с указанията на ISO/IEC 27002/точка А.6.2.1, но помним, че те не ни задължават с нищо. В сегашното си издание ISO/IEC 27001 ни дава предимството ние само да си „измислим“ най-подходящите за нас, включително с отчитане на нужния ресурс, защити.

Тривиално решение е да се забрани ползването на мобилни устройства в незащитена среда.

Но, ако търсим защити, очаквано ще е да преценим като подходящи някои от тези решения:

• биометрична автентикация - многокомпонентна, ако е особено важно;
• криптиране на съдържание;
• отделен достъп за мобилните устройства при влизане в Интернет среда;
• ползване на софтуер, предотвратяващ/разкриващ проникване;
• антивирусен софтуер;
• блокиране или ограничено внимателно ползване на Bluetooth;
• ползване на пароли за достъп;
• отдалечено изтриване – пълно или частично;
• забрани –

o   забрана или филтър при сваляне и инсталиране на приложения;

o   забрана, ограничение или отделен трафик за устройства, включвани в мрежа;

o   забрана за запис на пароли, ключове за активиране и чувствителни данни;

o   забрана за включване към чуждо зарядно или зарядно на публични места;

На последно място може да приемем, колкото и да е неприятна, мярката за административни наказания по повод на нарушения на политиката и мерките за защита, които я подкрепят 

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 си е най-обикновен стандарт, който обаче, за да носи все пак някаква полза, когато го усвоим, трябва да е добре разбран и добре премерен как точно да бъде интерпретиран за фирмата "Хикс"

TPM - Total Productive Maintenance ... или на български - Тотална продуктивна поддръжка. Що е то? Има ли почва?

Семинарите по ТРМ станаха повече от два-три и вероятно ще стават все повече ... Ето справка

ПРОВЕДЕНИ ОБУЧЕНИЯ ПО ТРМ

15.06.2015 – гр. София

14.09.2015 – гр. Търговище - ТРАКИЯ ГЛАС

15.09.2015 – гр. София

28.09.2015 – гр. Търговище - ТРАКИЯ ГЛАС

27.10.2015 – гр. Бургас

11.11.2015 – гр. Търговище - ТРАКИЯ ГЛАС

28.06.2016 – гр. София
28.02.2017 – гр. София
07.11.2017 – гр. Раковски - АВВ
18.07.2018 – гр. София - ФЛЕКСПРИНТ
23.10.2018 – гр. София
20.11.2018 – гр. София

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

Ще отговарям "индивидуално" на който е попитал или коментирал, а ако въпросът е по-важен и интересен, отговорът би могъл да е публикуван пак тук, за да е достъпен и за други колеги

Разбира се, може да се ползват и добре известните данни за контакт с Алфа и с мен ...

ЗА ВЪПРОСИ, ПРЕПОРЪКИ, ИНФОРМАЦИЯ И МНЕНИЯ 

АЛФА КУОЛИТИ БЪЛГАРИЯ

02 8687531

office@alphaquality.org

www.alphaquality.org

БОНЧО АНТОНОВ ПОПТОДОРОВ

boncho@alphaquality.org

boncho.antonov@gmail.com

0888 973292

http://isms-bulgaria.blogspot.com/

ISO 9001:2015... "La norme 2008 est morte! Vive la norme 2015!"

(Новият ISO 9001:2015 - Какво му липсва и кое му е в повече?)

Като тътен от пролетна буря се носи еуфория от появата и започналото прилагане на "новия стандарт". И все повече стават хората, които не крият притесненията си, след като са били опърлени от горещи хвалби за НОВОТО в стандарта. Сещате ли се кои хвалят новия стандарт?

Такова поведение ни е познато. Имаше ли еуфория когато версия 1994 премина в 2000? Имаше, но не толкова еуфория, колкото облекчение и предпазлива радост, че се махнаха досадните двадесет (толкова ли бяха?) задължителни процедури. Имаше ли еуфория, когато версия 2000 премина в 2008? Да имаше. Но сега тази по повод старата 2008 и новата 2015 е връх на всичко.

Истината е, че човек, ако се вгледа, става интересно. Да видим. Най-преди е нямало фигурата на "представител на ръководството". После се появява (2000 - аплодисменти!). След това идва уточнението "Трябва да е действителен член на висшето ръководство" (2008!). А сега (в 2015) - ами, няма го! Стана пак както най-преди (Има колебаещи се - да аплодират или да си траят!)

Тези, които разпалено ни убеждаваха колко е важен представителя, сега, пак разпалено, ни казват защо можело и без него. Така се била засилвала ролята и отговорността на баш-висшето ръководство. Тази история с представителя прилича на състезание по канадска борба. Все едно че в ТС 176/SC2 има хора "за" и други хора "против" представителя. И когато някой победи, в следващата версия победеният си иска реванш и го печели.

Подобна съдба сполетя и резултата от процесите - т.е. продуктите. Този "резултат" най-напред беше "продукт или услуга". После стана само "продукт". Сега - познайте ... Познахте, нали?

А че ролята на висшето ръководство едва ли е толкова засилена виждаме не само по това какви са "новите" изисквания, но и по един важен индикатор. Той е мястото на "стратегическото решение". Преди (2008) то беше забутано в т. 0.1, която надали някой чете, защото там нямало изисквания. Но поне имаше израза "трябва да бъде". Сега (2015), поради голямото засилване на ролята на ръководството, "трябва да бъде" го няма, а на негово място (пак в т. 0.1) има "е". Сякаш се приема за даденост. Казват - "Ако го поставим като изискване, то това няма как да се одитира." Няма ли? Само че е важно да се знае "Одитира се не каквото може, а каквото трябва"

...

...

(ще продължава ... )