Александр Запорожцев пишет:

Таким образом мы правильно все делаем -

' улучшение' if necessary.

Иначе получите " воронку Деминга "

На всякий случай, хочу напомнить, что на сайте Ассоциации Деминга есть перевод статьи "Beyond ISO 9000" из серии брошюр Британской Ассоциации Деминга
deming.ru/TeorUpr/Quality_Collection/17_Dvigatsa_dalshe_ISO9000.htm
Посмотрите, может оказаться полезным

Георгий Лейбович пишет:

На всякий случай, хочу напомнить, что на сайте Ассоциации Деминга есть перевод статьи "Beyond ISO 9000" из серии брошюр Британской Ассоциации Деминга
deming.ru/TeorUpr/Quality_Collection/17_Dvigatsa_dalshe_ISO9000.htm
Посмотрите, может оказаться полезным

Спасибо. Обязательно обсудим этот материал со студентами.
В эту пятницу на занятии (в ZOOM) обсуждали способ разработки функциональных моделей деятельности в сответствии с требованиями Стандарта. Решили, что по каждому требованию будем разрабатывать отдельную модель. Вот модель требования 4.1 Понимание организации и ее контекста. Организация должна определять внешние и внутренние факторы, которые существенны с точки зрения ее целей и стратегического направления и которые влияют на способность ее системы менеджмента качества достигать ожидаемого результата (ов). Организация должна отслеживать и анализировать информацию об этих внешних и внутренних факторах.
Для разработки функциональной модели проводим анализ требования
Анализ требования
Анализ внешних и внутренних факторов деятельности предприятия производиться в рамках разработки стратегических планов.
Необходимо проверить наличие процесса сбора и анализа информации о внешних и внутренних факторах в модели предприятия.
Необходимо выявить источники информации о внешних и внутренних факторах, а так же методы сбора и анализа такой информации
Источниками информации должны быть определенные процессы поэтому необходимо определить эти процессы
В результате модель включает следующие диаграммы

Здесь указано, что сбор информации о внуренних и внешних факторах проводиться в рамках разработки стратегии.

Здесь конкретизируется как должен быть организован сбор информации

Здесь показаны функции разработки стратегии.
Цикл PDCA присутствует на всех диаграммах в виде обратных связей в виде требований на предоставление дополнительной информации или пересмотра целей компании

Александр Запорожцев пишет:

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

Организация должна определять ...

Организация должна отслеживать...

... анализировать...

Функциональная модель должна была бы состоять из этих пунктов. "Глаголов" : Determine (определять), Monitor (мониторить), Review (анализировать).

Или по другому, в 6 сигм - Define, Measure, Analyse...

Или уж совсем откровенно - Plan, Do, Check...

Вы отклонились сильно в сторону, в пункты, которые не прописаны в 4.1. И их не следует здесь ' фантазировать ' .

Если у вас чего-то не хватает на этом этапе дизайна СМК, - оставьте пустые квадраты на входе - (Purpose, Strategic Direction, Intedended Results...), но незачем заниматься выдумкой того, чего нет в этом пункте. (Eсли вы строите 'функциональную модель' СМК).

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

Важно пояснить студентам, что мелким шрифтом (примечания) - идут пункты "настоятельных рекомендаций", а не "требований". Их можно 'выполнять' и 'не выполнять'. Но если хотим получить хорошую СМК, то причина для невыполнения должна быть существенна (допустим - невозможно).

PS

In this International Standard, the following verbal forms are used:

— “shall” indicates a requirement;
— “should” indicates a recommendation;
— “may” indicates a permission;
— “can” indicates a possibility or a capability.

Information marked as “ NOTE ” is for guidance in understanding or clarifying the associated requirement.

Александр Филонов пишет:

Функциональная модель должна была бы состоять из этих пунктов. "Глаголов" : Determine (определять), Monitor (мониторить), Review (анализировать).
Вы отклонились сильно в сторону, в пункты, которые не прописаны в 4.1. .

Использовать точно эти глаголы можно, но не нужно забывать, что каждое отдельное требование стандарта является требованием к деятельности всей организации Функции деятельности не висят в воздухе - они часть общей функциональной модели. В формулировке требования указано, что " факторы, которые существенны с точки зрения ее целей и стратегического направления" Факторы нужно определять, отслеживать и анализировать в контакте функции постановки целей и разработке стратегии
Таким образом при анализе требований необходимо выявлять тот процесс деятельности, к которому относиться требование.

Александр Филонов пишет:

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

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

Александр Запорожцев пишет:

Использовать точно эти глаголы можно, но не нужно забывать, что каждое отдельное требование стандарта является требованием к деятельности всей организации Функции деятельности не висят в воздухе - они часть общей функциональной модели. В формулировке требования указано, что " факторы, которые существенны с точки зрения ее целей и стратегического направления" Факторы нужно определять, отслеживать и анализировать в контакте функции постановки целей и разработке стратегии
Таким образом при анализе требований необходимо выявлять тот процесс деятельности, к которому относиться требование.

Вы телегу поставили впереди лошади.

Прочитайте, что на Входе.

На входе - Purpose и Strategic decision. Т.е. 'курс' - известен.

Необходимо определить что влияет на следование курсу (волны, ветер, восставший экипаж и т.д.)

А не наоборот.

Не выдумывайте чего там нет.

А если есть - пожалуйста, на стол. Дословно. А "не во время стратегической сессии..."

Александр Запорожцев пишет:

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

Вы еще больше загоняете студентов в тупик. Придумываете то, чего нет. Они этого днем с огнем на предприятии не найдут.

Лучше подставьте - 'кто' будет определять? - В стандарте написано - 'организация'. Who is "организация?" (Кто конкретно в 'организации'?). На Ваших диаграммах - это 'персонал'. Слишком расплывчато. Все? Или никто?

Александр Филонов пишет:

Лучше подставьте - 'кто' будет определять? - В стандарте написано - 'организация'. Who is "организация?" (Кто конкретно в 'организации'?). На Ваших диаграммах - это 'персонал'. Слишком расплывчато. Все? Или никто?

Согласен, я не успел доделать модель в части определения владельцев этих процессов

Александр Запорожцев пишет:

Согласен, я не успел доделать модель в части определения владельцев этих процессов

Вы бы сузили задачу. И просто представили модель СМК в формате SADT. Этого достаточно.

Зачем привязывать сюда неизвестное предприятие?

Получите универсальную модель в SADT, которую можно использовать на любом предприятии (организации).