Обсуждение. Записи (Теория)

[Андрей Горбунов]

Эта ветка для обсуждения теоретических аспектов управления записями

[Константин Стрюков]

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

Но с чем обязательно столкнется попытка запустить такой "самостоятельно каскадируемый механизм" - это ... как раз конфликт полномочий. Когда исполнителю на нижнем уровне потребуются вдруг захочется заполучить данные, относящиеся к сфере ответственности других подразделений, ему придется несладко. Желающие могут испытать это на себе, например, потребовав у главбуха какой-нибудь нетривиальный отчетик

Не говорю, что эта проблема неразрешима. Но она реальна и осязаема, а, значит, в лекции рано ставить точку

[Андрей Горбунов]

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

[Анастасия Борзенко]

Мне сильно следующее "режет"... - ПРК назначает записи, а владельцы процессов, исходя из этого уже определяют записи, которыми будут управлять.
ПОчему не владельцы процессов сами, основываясь на выходных данных для анализа по спектру своей деятельности не составляют перечень записей, содержащих эти данные, а ПРК уже не координирует и не утверждает общий в рамках СМК по организации?

[Андрей Горбунов]

Анастасия,
потому что именно ПРК отвечает за систему; для того, чтобы снизить риск, о котором писал Константин.

[Константин Стрюков]

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

Я не говорил о риске. Это не риск, а конкретная проблема, которая присуща предложенному Вами решению, и которая имеет место быть на практике.

Эта проблема получается из постановки задачи. Вы наибольшей проблемой называете многообразие и разноплановость записей. Хотя уж Вы-то понимаете, что нет "многообразия записей", а есть неспособность верно определять границы системы при анализе (о синтезе пока не говорю, хотя это не вполне корректно).

Тут никак не спасет предложенный Вами метод. Более того, он может усугубить проблему, поскольку поощряет "перетягивание одеяла"...

Никаноров в предисловии к переводу книги Оптнера когда-то написал примерно следующее: "Глупо ставить штангиста проектировать грузовик только на том основании, что он хорошо поднимает тяжести".

Вот и я думаю: конечно можно "уменьшить разноообразие" записей, просто сознательно "не видя" большей их части, отдав на откуп петям и васям, которые отлично "поднимают тяжести", но которых никогда не учили "проектировать грузовики". Но что будет, если такой петя ошибется? А я скажу что будет. В моей практике один такой вот, разработав сам для себя "аналитический отчет по закупкам", нечаянно завез и положил на склад лишнего товара на триста тысяч долларов. У него были такие полномочия, да вот с фактами "засада" вышла...

Вы уже второй раз выступаете с критикой, не предлагая альтернативы. Почему так?

Позвольте уточнить: альтернативы чему? Переспрашиваю, так как есть вероятность, что неправильно понимаю Ваш вопрос...

[Анастасия Борзенко]

Анастасия,
потому что именно ПРК отвечает за систему; для того, чтобы снизить риск, о котором писал Константин.

ПРК НЕ МОЖЕТ отвечать за систему, он может отвечать за проектирование, поддержание системы, etc. Система существует независимо от ПРК, его задача координировать и обобщать.
У нас все через одну букву...

Из ВАшей лекции получается: ПРК дает перечнь записей владельцам процессов - "мол, вот они, главные бумажки, которые мне дадут полную картину системы, за которую я отвечаю, а вы ужа сами определите, чем вы будете управлять".

Я предлагаю другой вариант, владельцы процессов дают перечни ВСЕХ записей ПРК, а ПРК, исходя из модели системы управления качеством уже определяет, какие их них подлежат управлению. Какие их них могут содержать данные, необходимые для анализа.
За который он отвечает.

Иначе есть вероятность, что все эти нехитрые Ваши решения не отодвинут от формального управления.

[Андрей Горбунов]

Константин,
честно сказать, не совсем понял Ваше последнее сообщение, а потому попробую сформулировать утверждение, которое мы обсуждаем, в несколько ином виде.
Итак, я утверждаю, что записи на предприятии имеют пирамидальную структуру (они отражают структуру данных, которые используются для управления). При этом подразделение менеджмента качества (ПРК) должен контролировать только верхний уровень. Каждый владелец процесса выстраивает свою пирамиду записей, чтобы дать те данные, которые требует от него ПРК. Это совершенно обычная структура, которая существует в управлении и мне непонятно, почему ее применение в СМК не должно быть результативным? Ведь не докладываются же генеральному директору все данные, которые снимают с датчиков, счетчиков и пр. рабочие? Ему ведь поступают интегрированные данные о работе предприятия. Вот и ПРК должен получать интегрированные данные о работе СМК. Но чтобы они сформировались, нужны (на нижнем уровне) показания датчиков, счетчиков и пр. Или Вы предлагается всю пирамиду оставить под контролем подразделения менеджмента качества (ПРК)? Но в том-то и проблема, что такой подход не работает.
Поэтому предлагаю распутывать клубок постепенно.
1. Согласны ли Вы, что структура записей - пирамида: чем выше уровень управления, тем меньше записей? Или Вы полагаете, что структура записей линейна, т.е. все на одном уровне?

PS. Что касается личного замечания, то оно было продиктовано тем, что Вы в первом своем сообщении ограничились указанием, что, по-Вашему мнению, не так, не написав, а как должно быть, какая альтернатива предложенному - но не принимаемому Вами - решению видится.

[Мария Каменская]

Что требует стандарт? Чтобы записи: управлялись. а) велись, б) поддерживались в рабочем состоянии (п. 4.2.4 излагает свойства «рабочего состояния» записей: 1) четкость, 2) легкость идентификации, 3) восстанавливаемость) и в) управлялись, т.е. были установлены правила 1) идентификации, 2) хранения, 3) защиты, 4) восстановления, 5) определения сроков сохранения, 6) изъятия.

Форма записей, какие они, зачем они, определяет не ПРК, это определяется при описании процессов.

Все остальное - читай инструкцию по делопроизводству:
идентификация - номер по номенклатуре дел
определение сроков хранения - тоже прописывается в номенклатуре дел
хранение - в инструкции по делопроизводству, уничтожение там же.

Зачем делить - это относится к СМК, а это нет? Чем определение сроков хранения приказов отличается от определения сроков хранения договоров, журналов, переписки по контракту и т.п.?

[Андрей Горбунов]

Анастасия,
если ПРК не может отвечать за систему, то за что он может? Я не понимаю, как можно проектировать что-то и не отвечать за результат проектирования. А т.к. ПРК проектирует систему, то он за нее и должен отвечать - в смысле правильности конструкции.
И именно ПРК (а кто еще может?) определяет, какие данные ему нужны для оценки результативности системы. А потому именно он и говорит тем, кто отвечает за элементы системы (владельцы процессов), какие ему данные нужны, оставляя в их зоне ответственности формирование этих данных.
"Я предлагаю другой вариант, владельцы процессов дают перечни ВСЕХ записей ПРК" - простите, зачем мне - ПРК - эта информация? И где гарантия, что среди этих записей будут присутствовать те, что мне нужны? И "всех" означает отсутствие границ, т.е. критериев отбора. Попробуйте сформировать список всех записей, которыми сами пользуетесь. Убежден, ничего не получится: будете постоянно этот список пополнять, вспоминая то про одну забытую, то про другую.
Не могут строители определять архитектору, как проектировать, но архитектор дает указания строителям, как строить. А иначе будет хаос.

[Андрей Горбунов]

Мария,
если Вы согласны с тем, что ПРК - архитектор системы и в этом качестве нуждается в данных для оценки результативности этой системы, то в представлении "потребитель - производитель" ПРК будет "потребителем" (данных), а владельцы процессов "производителями" (данных). Но требования устанавливает потребитель и, следовательно, именно ПРК должен определить требования к необходимым ему записям.
"Зачем делить - это относится к СМК, а это нет" - потому, что системный подход включает в себя определение границ системы. Невозможно управлять неопределенным числом объектов (или типов объектов).

[Мария Каменская]

Мария,
если Вы согласны с тем, что ПРК - архитектор системы и в этом качестве нуждается в данных для оценки результативности этой системы, то в представлении "потребитель - производитель" ПРК будет "потребителем" (данных), а владельцы процессов "производителями" (данных). Но требования устанавливает потребитель и, следовательно, именно ПРК должен определить требования к необходимым ему записям.

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

"Зачем делить - это относится к СМК, а это нет" - потому, что системный подход включает в себя определение границ системы. Невозможно управлять неопределенным числом объектов (или типов объектов).

Можно не управлять приказами, но приказы - это управленческие решения, при не систематизированном (не налаженном) управлении могут привести к невыполнению этих управленческих решений (например, не всем дали почитать)

[Анастасия Борзенко]

И именно ПРК (а кто еще может?) определяет, какие данные ему нужны для оценки результативности системы. А потому именно он и говорит тем, кто отвечает за элементы системы (владельцы процессов), какие ему данные нужны, оставляя в их зоне ответственности формирование этих данных..

ПРК моделирует систему, назначает элементы системы, назначает ответственных за эти элементы, и назначает данные для анализа - да, но Вы представляете сеье практически, что сидит ПРК и пишет "необходимый перечень записей"? Я нет.
Не на производстве, по крайней мере.
Я понимаю, что система управления качеством в офисе (институте, etc) в одном масштабе, на большом производстве - в другом.
Знаете как получится? Как любят у нас делать - написали стандарт, скинули его в массы, а он не работает! Оказывается..)) потому что в свое время не провели работу с теми подразделениями, работу которых регламентировали. Внутреннего обмена информацией не было.
Напиали одно, потому что "ДУМАЛИ", что так и есть (по логике вещей, а есть по ДРУГОМУ.

Я призываю все таки не вверять документы ПРК, а взять существующие, посмотреть на них, и понять, какие из них необходимы для систематического анализа, либо прогнозирования.

простите, зачем мне - ПРК - эта информация? И где гарантия, что среди этих записей будут присутствовать те, что мне нужны? И "всех" означает отсутствие границ, т.е. критериев отбора. Попробуйте сформировать список всех записей, которыми сами пользуетесь. Убежден, ничего не получится: будете постоянно этот список пополнять, вспоминая то про одну забытую, то про другую...

У меня это список есть. И не только моего подразделения, кстати.

Андрей.... Вы меня удивляете.. "Где гарантия, что ПРК нужны записи?" А где гарантия, что не нужны? Кто лучше исполнителей определит документы - данные по процессу? ПРК может разуметь, что ему угодно, но это все гроша ломанного не стоит, пока не привязано к действительности и не опирается на реально существующую модель.
Был у меня один такой знакомый ПРК с дочки, дел наворотил... ужас. Знаете отчего?
Оттого, что как раз "ДУМАЛ", что как архитектор он отвечает за систему и должен говорить всем как ее строить. Сверху - вниз.
ЗАБЛУЖДЕНИЕ.


НЕ хочу никого обидеть, но по личным наблюдениям, когда ПРК именно так и настроен: разрабатывает он, исполнители "выбирают" в детстве в стратегические игры не наигрался, чтоли...

[Андрей Горбунов]

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

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

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

[Анастасия Борзенко]

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

Роман, в моих ответах не раз фигурировало "анализ системы, прогнозирование", я не беру во внимание стандарт, если есть модель процессов, модель критериев оценки этих процессов, соответственно, есть и документы, содержащие данные по деятельности, которой мы управляем.
Эти данные путьем обсчетов дают нам информацию о текущем состоянии системы и возможность дольнейшего моделирования маршрутов путем назнеачения необходимых мероприятий.

Один человек не может назначать виды этих докуменов с данными, тем более который не занят в процессе непосредственно, его задача ВЫДЕЛИТЬ. а не ПРИДУМАТЬ.

[Фефелов Андрей А.]

ГЫ-ГЫ-ГЫ зубры сцепились!

А действительно зачем нужны записи:
1. Законодательные требования для прослеживаемости
2. Внутренние нормативные требования для прослеживаемости
3. Для сбора информации для последующего анализа (владельцем процесса)

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

ИМХО, нет смысла (не по п.1, не по п.2 не по п.3) ПРК знать (и отслеживать) какие записи ведутся в ведомстве владельца процесса, главное чтобы выполнялись условия их управления.

Т.е. логически рассуждая получаем ту самую "пирамидальную" структуру, предложенную Андреем Горбуновым.
Или спор уже не об этом?

[Мария Каменская]

Т.е. исходя из рассуждений мы должны управлять только теми документами (журналы и т.п.), какие необходимы ПРК. Чудесно. Работаем на себя

[Анастасия Борзенко]

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

[Анастасия Борзенко]

Т.е. исходя из рассуждений мы должны управлять только теми документами (журналы и т.п.), какие необходимы ПРК. Чудесно. Работаем на себя

Маша, 5 +!