Риски. Как описать?

[Алина Петиченко]

В соответствие с новой версией стандарта ISO 9001, компании необходимо определить, описать и управлять всеми возможными рисками. "Как же правильно составить документ, описывающий процесс управления рисками и что он должен содержать?" - основной вопрос, которым сейчас задаются предприятия. Давайте порассуждаем на эту тему.

[Роман Озеранский]

В соответствие с новой версией стандарта ISO 9001, компании необходимо определить, описать и управлять всеми возможными рисками. "Как же правильно составить документ, описывающий процесс управления рисками и что он должен содержать?" - основной вопрос, которым сейчас задаются предприятия. Давайте порассуждаем на эту тему.

Коллеги консультанты, а что вы делали до ISO 9001:2015? Вы не предлагали своим клиентам управлять рисками ? Получается пока ISO не пнет (ради бумажки), никто не зашевелится .

[Иван Иванов]

Давайте порассуждаем на эту тему.

откройте НАССР или FMEA

[Поденков Андрей]

А что его сочинять то.
они же и раньше были, тока звались ПД.
методик оценки очень много.
и не каждое предприятие готово к этому.
мы пошли простым путем.

критерии процессов----может ли произойти снижение критерия? --- почему? ---- как повлияет на бизнес? --- что надо сделать чтоб этого не произошло?

на 3х- предприятиях проверил. и слово РИСК для них стало ни так страшно.

[Сергей Трофимов]

Считаю поднятый вопрос очень актуальным и полезным. Вот мы в нашей организации, при описании операций процессов сразу прикидывали, чем, как и кому грозит данная неверно выполненная операция и несоответствие результатов работы требованиям и прописывали выполнение операций и достижение необходимых результатов в карте процесса. Понимаю что довольно примитивно, но это помогло выявить и предотвратить косяки во взаимодействиях участников процесса, в выполняемой ими работе. Вот как управление рисками поднять на должный уровень? С чего начать? ПД честно говоря особого внимания никогда не уделялось, типа грянет гром (возникнет несоответствие) мы и КД продумаем и какие ПД нужны сфантазируем.

[Евгений Жуков]

Давайте порассуждаем на эту тему.

откройте НАССР или FMEA

Угу
Для этого FMEA и создано. В НАССР применяется частный случай FMEA - при вероятности обнаружения равной 1. Это на производстве

Ну а в сервисе рулит инструмент управления риском под названием "Предоплата"

[Андрей Козин]

Для этого FMEA и создано. В НАССР применяется частный случай FMEA - при вероятности обнаружения равной 1. Это на производстве

Это все прекрасно. Но.
Хотелось бы рассмотреть отличия рисков для проектов и процессов.
ИМХО FMEA применимо только для проекта. Да и в 9000-2015 сквозит именно проектным подходом, так как в примечаниях фигурирует понятие "событие".
Я делаю свои суждения исходя из своей точки зрения на процесс как на стандартную последовательность действий. А это подразумевает какую ни какую технологию: стандартные методы, стандартные оборудование, стандартные инструмент, стандартные материал, стандартные исполнители. От сюда и прямая зависимость. Чем выше уровень технологичности процесса, тем выше уровень соответствия партии продукции.
И тут надо говорить не о событиях (фактах), а о факторах (действиях). Пример. Изменение компетенции персонала во времени - фактор. Не соответствие компетенции поставленной задаче - событие (факт).
На выходе получаем, что для любого процесса имеется стандартный набор рисков:
*изменение компетентности исполнителей
*износ оборудования
*износ инструментов
*изменение качества материалов
*изменение актуальности нормативных документов
с соответствующим перечнем предупреждающих действиями.

[Евгений Жуков]

Хотелось бы рассмотреть отличия рисков для проектов и процессов

На мой взгляд отличий нет
Потому что с точки зрения рискологии и рискографии между проектом (как процессом с заданными датами начала и окончания) и процессом (как недатированным проектом) различий не усматривается

Теперь послушаем, чего к нашим тезисам добавят резонные люди

[Сергей Трофимов]

для любого процесса имеется стандартный набор рисков:
*изменение компетентности исполнителей
*износ оборудования
*износ инструментов
*изменение качества материалов
*изменение актуальности нормативных документов

А похмельный синдром у станочника Ивана, вызывающий дрожание рук и вполне ведущий к увеличению брака.
А сквозняк в цехе, заставляющий рабочих работать в перчатках, которые снижают точность движений и вполне возможно могут повлиять на увеличение брака.
А старый монитор, заставляющий менеджера каждые 20 минут давать отдых глазам по 5 минут, что ведет к потере рабочего времени.

Просто перечень шире, как минимум производственная среда...

[Поденков Андрей]

А похмельный синдром у станочника Ивана, вызывающий дрожание рук и вполне ведущий к увеличению брака.
А сквозняк в цехе, заставляющий рабочих работать в перчатках, которые снижают точность движений и вполне возможно могут повлиять на увеличение брака.
А старый монитор, заставляющий менеджера каждые 20 минут давать отдых глазам по 5 минут, что ведет к потере рабочего времени.

Просто перечень шире, как минимум производственная среда...

При таком случае - о какой системе идет разговор, тут до рисков далеко

[Андрей Козин]

Потому что с точки зрения рискологии и рискографии между проектом (как процессом с заданными датами начала и окончания) и процессом (как недатированным проектом) различий не усматривается

ИМХО
Для процесса есть возможность провести его валидацию через пробную эксплуатацию, выпустить опытную партию, по результатам пробной эксплуатации провести корректировки.
Для проекта такая возможность не предусмотрена. Как только вы произвели продукт, так тут же завершился проект. Иначе нужно удваивать стоимость проекта: первый выпуск для целей валидации, второй выпуск для нужд потребителя. Чтобы этим не заниматься и реализуют процедуру FMEA.

[Роман Озеранский]

Для процесса есть возможность провести его валидацию через пробную эксплуатацию, выпустить опытную партию, по результатам пробной эксплуатации провести корректировки.
Для проекта такая возможность не предусмотрена. Как только вы произвели продукт, так тут же завершился проект.

А кто мешает изменять проект в процессе его реализации? Абсолютное большинство проектов именно так и живет, изменяясь в процессе реализации, в них вносятся те или иные изменения по ходу дела, от чего они не перестают быть проектами .

[Андрей Козин]

А кто мешает изменять проект в процессе его реализации? Абсолютное большинство проектов именно так и живет, изменяясь в процессе реализации, в них вносятся те или иные изменения по ходу дела, от чего они не перестают быть проектами :D .

Сложно отвечать, так не совсем понятно, что Вы имеете в виду под фразой "изменять проект". Возможно вносить изменения в план реализации проекта? А ведь это влечет за собой изменение сроков, стоимости, финансовой эффективности, удовлетворенность потребителя и проч.

Ответ
Никто.
Но применительно к проекту:
1. это изменение производится по факту реализации риска, значит рисками проекта не управляют
2. результат внесенных изменений можно оценить только после завершения проекта и, в отличие от ПРОЦЕССА, второго шанса заново прокрутить проект от старта до финиша, в случае отрицательных результатов и с учетом анализа причин отрицательных результатов, не будет. Внимательно следим за строительством космодрома Восточный.

ИМХО промежуточное утверждение
Назначение управления рисками проекта - повысить финансовую эффективность проекта
Назначение управления рисками процесса - сохранить стабильность (результативность) процесса

[Роман Озеранский]

1. это изменение производится по факту реализации риска, значит рисками проекта не управляют

С чего вдруг такое мнение? Вы что никогда не было РП, в котором в процессе проекта проводилось моделирование, изменяющее ту же конструкцию (в автомобильной промышленности, где Вы работаете, моделирование в проекте проводится сплошь и рядом). А про управление рисками в проекте я и говорить не буду, отдельная дисциплина, достойная внимания.

результат внесенных изменений можно оценить только после завершения проекта и, в отличие от ПРОЦЕССА, второго шанса заново прокрутить проект от старта до финиша, в случае отрицательных результатов и с учетом анализа причин отрицательных результатов, не будет.

Я задам неприятный вопрос, а что у процесса нет конца, в отличии от проекта ? Если скажете что есть, то это тот же самый проект, а вы тут строите теоретические изыски, чем управление рисками отличается в процессе и проекте .

Назначение управления рисками проекта
Назначение управления рисками процесса

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

[Иван Иванов]

Назначение управления рисками проекта - повысить финансовую эффективность проекта
Назначение управления рисками процесса - сохранить стабильность (результативность) процесса

назначение управления рисками - снизить неопределенности до приемлемого уровня. А финансовая или еще какая стабильность - дело второе.

[Андрей Козин]

Я задам неприятный вопрос, а что у процесса нет конца, в отличии от проекта :D ? Если скажете что есть, то это тот же самый проект, а вы тут строите теоретические изыски, чем управление рисками отличается в процессе и проекте :D .

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

[Андрей Козин]

назначение управления рисками - снизить неопределенности до приемлемого уровня. А финансовая или еще какая стабильность - дело второе.

Перепишем ИМХО
Назначение управления рисками проекта - снизить неопределенность финансовой эффективности проекта до приемлемого уровня
Назначение управления рисками процесса - снизить неопределенность стабильности (результативности) процесса до приемлемого уровня

[Евгений Жуков]

назначение управления рисками - снизить неопределенности до приемлемого уровня. А финансовая или еще какая стабильность - дело второе.

Назначение управления рисками проекта - снизить неопределенность финансовой эффективности проекта до приемлемого уровня

Подброшу я дровишек в жаркий огонь дискуссии

Вот, к примеру, очевидный проект - приём аккредитационной комиссии. Кто проходил аккредитацию - тот меня понимает
В этом случае бюджет прописан до копейки. Какая же тут финансовая неопределённость?
А вот чтобы комиссионеру-язвеннику готовить яства по 1-му столу - так это таки серьёзная определённость

[Роман Озеранский]

В процессе последовательность действий стандартная, спроектирована на стандартные входы и выходы. В случае нестандартного входа процесс неосуществим.

А что такое стандартные входы и выходы для процесса? При производстве того же автомобиля стандартным по КД считается устанавливать шины Pirelli, изменили КД и устанавливают шины Bridgestone. Что тут из них стандартное, а что нет? А можно в КД прописать и то и другое, и вот уже стандартными входами стали и те и другие шины. В проекте все ровно точно также, можно менять, а можно и не менять. Не катит тут стандартность, как критерий отличия процесса от проекта.

Назначение управления рисками проекта - снизить неопределенность финансовой эффективности проекта до приемлемого уровня

Я не понимаю почему в управлении рисками в проекте подвязаны только финансы, они чем лучше чем остальные атрибуты? Тому же миллиардеру заказавшему себе в изготовление яхту в единственном числе - уникальном и неповторимом, чтобы отличаться от других миллиардеров , на финансовые показатели (стоимость проекта) в принципе плевать .

[Андрей Козин]

А что такое стандартные входы и выходы для процесса? При производстве того же автомобиля стандартным по КД считается устанавливать шины Pirelli, изменили КД и устанавливают шины Bridgestone. Что тут из них стандартное, а что нет? А можно в КД прописать и то и другое, и вот уже стандартными входами стали и те и другие шины. В проекте все ровно точно также, можно менять, а можно и не менять. Не катит тут стандартность, как критерий отличия процесса от проекта.

Вы привели не корректный пример.
Корректный не с шинами связан.
Досмотрим Ваш пример с автомобилестроением. Возьмем не любимый всеми ОАО АВТОВАЗ.
Серийный выпуск модификаций автомобилей - процесс. Под все возможные модификации разработаны и утверждены спецификации и маршруты. Какие бы Вы колеса не прикручивали в границах утвержденных спецификаций, все равно получатся Калины, Гранты, Весты, но ни при каком раскладе Камазы, Боинги и подлодки проекта Борей.
Вот если Вы попробуете у ОАО АВТОВАЗ каждый автомобиль заказывать не похожим на все предыдущие ранее выпущенные, вот тогда вы получите проекты. И производится они будут не на конвейере, а на площадке ОПП. Сроки производства и стоимость автомобилей по проекту будут отличаться в разы от тех же значений процессного производства.