неделя, 14 февруари 2016 г.

ISO/IEC 20000-1 - Кратко представяне на стандарта и на учебния Модул 11

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

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

Популярната и известна отдавна по света “IT-библия, наречена ITIL e проектирана по подходящ начин в тялото на международния стандарт ISO/IEC 20000-1. Стандартът обхваща всички аспекти и специфики на услугите в IT бранша и гарантира, чрез постигане на изискванията му, че степента на удовлетвореност на клиентите ще е висока. Стандартът има едно решително предимство – в него са заложени и всички ключови изисквания на стандарта за управление на сигурността на информацията – ISO/IEC 27001. Така за IT организациите ще е напълно достатъчно да усвоят само ISO/IEC 20000-1 и да не се занимават с ISO/IEC 27001. Стандартът има и един притеснителен недостатък – изисква твърде много документи и записи, с което той става трудно приложим в две ситуации – ако IT организацията е малка по размер или ако организацията предлага много услуги.


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


Модул 11 - ISO/IEC 20000-1 И СИСТЕМИ ЗА УПРАВЛЕНИЕ НА УСЛУГИТЕ В ICT СЕКТОРА

Аудитория
Собственици на фирми и висши мениджъри от ICT браншa. ICT сервизни специалисти. Системни администратори. Ръководители и специалисти от държавната и общинска администрации. Проектанти на информационни системи, на клиентски софтуер и на обучения по ICT. Оператори на ICT, на специализирани и на публични услуги. Доставчици за ICT сектора

Цели на обучението
Да поясни понятията и процесите, свързани с проектиране или изменение на ICT услуги, както и процесите по доставка, бюджетиране, управление на капацитета, сигурността, решаване на спорове с доставчици и клиенти, управление на конфигурацията, пускане за ползване и разгръщане на ICT услуги. Да представи и коментира изискванията на стандарта ISO/IEC 20000-1.

Ползи
Участниците получават достъпно и ясно изложение, съпроводено с примери и с казуси за обсъждане. Коментират се степените на свобода, заложени в съдържанието на изискванията, и варианти за лесна и ефикасна реализация на система. Идеи за цялостно и достатъчно, но пестеливо документиране

Тематика
Общо представяне на ключовите стандарти от серията ISO/IEC 20000-X
Структура и изисквания на системата за управление на ICT услугите
Обхват и схема за управление на системата по метода PDCA
Документиране на системата и управление на документи и записи
Процеси, свързани с управлението на ICT услугите
      - планиране, проектиране, преход или голямо изменение на услуга;
- доставка на услуга – ниво, непрекъснатост и наличност;
- бюджетиране и отчетност за услуга;
- управление на капацитета;
- управление на сигурността на информацията;
- взаимодействия на доставчика на услуга с други страни;
- управление на инциденти и проблеми;
- процеси на контрол.

ISO/IEC 27001 - Кратко представяне на стандарта и на учебния модул М7

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

Едно е сигурно – занапред това ще продължава и ще се засилва!

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


Ние, партньорите на Алфа Куолити България винаги се стараем системите за управление на сигурността на нашите клиенти да бъдат адекватни и да са оразмерени индивидуално според особеностите на бизнес процесите в организацията и според броя и големината на реални за процесите рискове


Модул 7 - ISO/IEC 27001 И УПРАВЛЕНИЕ НА СИГУРНОСТТА НА ИНФОРМАЦИЯТА

Аудитория
Собственици на фирми и висши мениджъри от всички браншове. Системни администратори. IT сервизни специалисти. Ръководители и специалисти от държавната и общинска администрации. Проектанти на информационни системи и на клиентски софтуер. Оператори на IT, на специализирани и на публични услуги. Доставчици на услуги и продукти за „чувствителни“ сектори

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

Ползи
Участниците получават достъпно и ясно изложение, съпроводено с примери и с казуси за обсъждане. Коментират се степените на свобода, заложени в съдържанието на изискванията, и варианти за лесна и ефикасна реализация на система. Идеи за цялостно и достатъчно, но пестеливо документиране

Тематика
Общо представяне на ключовите стандарти от серията ISO/IEC 2700X
Изясняване и коментар на основни понятия в сферата на сигурността
Връзка на външните и вътрешни фактори с обхвата и рисковете
Планиране, свързано с критерии, оценяване и обработване на рискове
Ресурси в полза на сигурността. Документиране на системата. Примери
Мониторинг, одити и прегледи на системата. Примери
Структура и основно съдържание на „контролите“ от Приложение А
Насочване към информационни източници и към „гуру“ центрове

четвъртък, 11 февруари 2016 г.

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

А обратното е клиентът да поеме управление над консултанта...
Как е възможно това? Просто е - само че може да стане някак неусетно.

Още с първото си посещение при клиента консултантът вижда, че ръководството и хората във фирмата са твърде много заети. Работят яко! Ако пък случайно консултантът е дал вид, че не е разбрал това, все някой от фирмата ще му го каже ясно, категорично и в прав текст, от който се разбира, че "Нямаме никаква възможност сега да се занимаваме с това ISO ..."

Какво следва от това? 
Следват ето такива неща ...

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

2. Консултантът услужливо и с разбиране поема сам да разработи всички необходими за системата документи, при това с минимално или даже при никакво съдействие от клиента.

3. Хората от фирмата, а най-вече ръководството, нямат достатъчно време, за да прегледат предадените проекти на документи. Може даже да нямат никакво време за преглед, а имат време просто да подпишат документите "за да върви работата".

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

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

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

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

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

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

Липсата на съпротивителни сили за спор често поставя фирмите в изнасилено положение да правят неща, които са им казали - макар да не виждат разум и смисъл. "Така каза одитора!"
За съжаление, случват се такива неща. Даже се случва и ръководството рязко и сляпо (безкритично) да смени мнение или решение, върху което изначално е построена системата.
 
2) По-лошо е когато одиторът каже точно каквото трябва. Защо? Защото отсреща хората вече не го слушат с "половин ухо", а го "гледат в устата какво казва". И не само това - те разбират какво им се казва и даже се радват "Я, че то било толкова ясно и просто!"

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

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

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








        

неделя, 30 август 2015 г.

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) наличие на "документирана информация, в т.ч. записи", описващи процеса проектиране.









































понеделник, 26 януари 2015 г.

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 и някои контроли от Анекс А, които се отнасят до клиенти, доставчици и др. - т.е. до лица, от които наистина зависи сигурността!

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

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

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

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

сряда, 21 януари 2015 г.

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

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

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

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

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

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

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

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

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

сряда, 26 ноември 2014 г.

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

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

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

Има и такава тактика – на изчакване, за да се види накъде отиват нещата, какво ще стане с първите и изобщо да се разсъждава на тема „има ли това почва у нас“ и „струва ли си ...“. Само че сега, докато чакаме, ще дойде новата вълна и историята ще се повтори. Пределно ясно е, че тук няма какво да се изчакава – трябва само да се погледне какво става по света. Достатъчно е да погледнем в сайта на 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 примери с реални фирми, някои от които са известни и ги познаваме


сряда, 1 октомври 2014 г.

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!

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