Введение.
В нашем чате СМК-шников в ТГ как-то зашел разговор о версионности локальных документов и способах их актуализации. Суть вопроса была в том, как в разных организациях устроена система присвоения версий документам и нужна ли она в принципе. Потом, уже в личном разговоре с коллегой из чата мы подискутировали о том, как лучше организовать актуализацию документов.
Поскольку правильных ответов на все эти вопросы все равно нет, я в этой статье постараюсь изложить и обосновать свой подход, может быть, кому-то он будет полезен как есть, а кого-то убедит в том, что он ошибочный и переусложненный, и у него все лучше )) Это нормально ))
Итак!
Версионность.
История.
Когда я только начинал в СМК и пришел на предприятие, про версии документов там никто ничего не слышал. Принцип кодирования документов там был следующим:
Шифр завода - это его четырехбуквенное обозначение. Индекс системы менеджмента - это просто цифра, обозначавшая принадлежность документа к какой-то системе (СМК была под цифрой 4, почему - не спрашивайте, я не знаю).
Номер ЛНД - это просто трехзначное число, порядковый номер документа в системе завода. Ну и год издания - понятно.
Номера изменений к документу никак не отражались в шифре, только заполнялся Лист регистрации изменений, может кто помнит такой? Фотку вставлять лениво - поэтому читайте мануалы ))) Приложение В.
Дальше к нам зашла новая головная организация, у которой были новые требования. Появились такие понятия как "Номер утверждения" (т.е. шифр, под которым документ утвержден - внутренний номер в системе завода) и "Номер регистрации" (шифр, под которым он зарегистрирован в системе ЛНД головной организации).
Для нас внутри завода в общем ничего не изменилось кроме того, что к нашему шифру добавился номер версии, и это стало выглядеть вот так:
Почему номер версии был из двух частей - нам никто не объяснял. Дело в том, что инкремента второй части номера версии при внесении изменений не происходило, просто на титульнике появлялась надпись:
С изменениями, введенными Приказом от... №.....
Десять изменений? Ок. Версия все равно, допустим, 2.00, но на титульнике 10 таких надписей. Гемор полный, но так было.
Потом мы с инженером подумали и он меня убедил избавиться от года в шифре. С приходом версий он стал просто не нужен.
Да и раньше он тоже не нужен был. Представьте ситуацию, если документ разработан в начале 2024 года и имеет шифр АБВГ.4.125-2024. А потом в июне его переработали. Какой шифр он будет иметь, если нет версионности? Верно. АБВГ.4.125-2024. Как отличить первый от второго? А хз как.
С введением версионности все стало логичнее, и номер года отпал как рудимент. Стало так:
Лучше? Конечно, лучше!
Но вот беда. Головная нам так и не объяснила, нафига такой сложный номер версии! При том, что часть номера версии после точки не меняется и всегда равна 00.
Прошло время и головная сама это поняла, после чего пришла к очевидному решению. Выкинуть к .... часть номера версии после точки, а вместо этого учитывать изменения словом ИЗМ в колонтитуле документа. В итоге вышло так:
В общем, если ничего не изменилось, то в такой парадигме мой оборонный завод живет и сейчас. Индекс системы менеджмента остался как рудимент, если бы я работал там дальше, я бы, может, и от него избавился, если честно ))
При этом, при ссылке на ЛНД в тексте номер его версии откидывается и получается компактный шифр типа АБВГ.4.125.
Стодвадцатьпятый - это, кажись, по закупкам )) Пусть старые коллеги поправят, если читают мой блог )))
Если в ту же самую версию документа внесены изменения, то на шифре это не отражается, но номер изменения вносится в колонтитул самого документа.
Вот такой путь мы прошли с коллегами по оборонке за 11 лет моей работы там. Если брать сокращенный шифр без версий, то просто год, получается, убрали ) Но ввели версии - и это стало основой стройного реестра учета документации! Хоть это простому пользователю и не видно особо.
Настоящее время.
Сейчас, придя на новое место работы, я получил основное задание - создать систему классификации ЛНД у нового для меня завода. Специфика тут в том, что все привыкли привязывать шифр документа к подразделению-разработчику данного документа. И, в общем, это классный подход, сейчас он мне очень нравится, поскольку шифр становится не сильно больше, но намного более информативный.
Но завод использовал номер года в шифре, что, естественно, БУЭЭЭ, и от него надо было избавиться.
Кроме того, я решил использовать номер версии из двух частей, как было на старой работе, но вложил в это смысл.
В итоге вышла следующая структура:
Покажу на примере:
Допустим, наша фирма называется "Рога и копыта" (ООО "РИК"), и подразделение "Отдел кадров" ("ОК") разработало Стандарт (С) "с таким-то названием", который имеет порядковый номер среди стандартов данного подразделения "8", при этом это 5-е издание данного документа с 3-мя внесенными изменениями.
Тогда шифр будет выглядеть так: РИК.ОК.С-008 версия 5.03
Естественно, при ссылке на данный документ в тексте, номер версии откидывается и получается вот так: РИК.ОК.С-008.
Итог.
Версионность очень сильно помогает систематизировать базу данных документов. Тем более, что я строю такую базу, в которой сохранены все версии документов. Старые соответствующим образом идентифицированы, и не выдаются в общем поиске по умолчанию. Но при желании - ставим галочку "Показать отмененные" - и вся история и каждая итерация каждого документа как на ладони.
Еще раз повторю. Правильных решений тут не существует. Я поставил себе целью сделать понятную систему кодирования, не ломая устои, к которым привыкли люди на заводе. И, вроде бы, система вышла удобная и логичная.
Актуализация документов
А вот с методами актуализации документов мы с коллегой поломали копья ))
Коллега говорит, что изменения в документы не особо и нужны, ведь документ можно тупо переиздать, увеличив счетчик версии на единицу. Да. Можно, кто спорит? =)
Мой подход чуть другой. Изложу его, напоминая, что правильных решений тут нет.
Так вот. Мой подход заключается в том, что актуализация документа может проходить двумя способами:
- переиздание;
- внесение изменений.
И тут главное - определить, когда надо идти таким путем, а когда эдаким.
Мой подход заключается в следующем.
Из практики следует, что ни один вновь разработанный документ не идеален, в нем всегда будут шероховатости, так или иначе недостаточно работоспособные ветки процессов или процедур, особенно, если документ разрабатывается впервые.
Что-то прописано недостаточно подробно, а что-то избыточно. Заделаны подписи одних должностных лиц, а потом их переименовали.. Да мало ли ситуаций?
Так вот. Если основная суть процесса не меняется, а нужно лишь его подправить, скорректировать - то делаем изменение в документ. При этом основная версия остается той же, инкремент идет на вторую часть номера версии - номер изменения.
Если меняется ход процесса (например, были перераспределены полномочия между участниками процесса - переписаны должностные инструкции и положения о подразделениях) - то переиздаем документ, инкремент идет на первую часть номера версии, вторая часть обнуляется.
Естественно, в моей системе сохраняется каждое изменение, можно всегда вернуться и посмотреть, что изменилось. Причем, не просто в листе изменений будет написано, что "Скорректировано название разделов", а будет перечень изменений типа "Было - стало", всегда, для каждого изменения документа можно открыть этот перечень, прочесть текст в старой редакции и в новой. Как в Консультант+ при сравнении документов.
Ну а при переиздании: новый процесс - новый ЛНД. Все старые изменения предыдущей версии теряют актуальность, поменялся процесс целиком.
Резюмируя.
Как правильно подметили коллеги в чате, вы хоть пятью числами версию обозначайте, хоть вообще не обозначайте, всем пофигу. Пользователям просто нужна база актуальной документации и все.
А вот тем, кто ведет эту базу нужна системность. Потому что без системы не будет и базы.
Наша служба и опасна, и трудна,
И на первый взгляд как будто не видна )))
Но по данной теме правильных ответов на вопросы "Нужен ли год в шифре?" или "Как писать версию?" нет. Вы сами определяете систему для своей Организации.