Очень часто слышу от коллег, что создать систему управления документацией на несколько организаций различного профиля невозможно, что получится неуправляемый монстр. Но ведь все зависит от того, как на ситуацию посмотреть. Почему-то ни одно государство не считает, что создало монстра, когда приняли , например, трудовой кодекс, а с ним и многие подзаконные акты, уточняющие различные детали, для «профильных» направлений или объясняя нюансы. Так почему же желание создать свое маленькое государство из нескольких разношерстных предприятий воспринимается в штыки? Особенно, когда все предприятия имеют одного учредителя или собственника. Т.е. речь ведь идет об описании единых правил и подходов для всех компаний независимо от специфики деятельности. А вот как раз ту самую специфику отдаем на откуп организациям. Главный принцип в этом случае «Не навредить!». Ведь все, кого мы хотим охватить уже могут иметь жесткие границы, в которые их поставили проверяющие органы. И если организации продолжают работать, значит все документы уже соответствуют тем требованиям, которые выставляют к ним проверяющие органы, поэтому важно не создать проблемы организациям, влезая со своими правилами, а упростить жизнь, с учетом уже имеющихся у них границ. Т.е. нужно создать систему документации, которую потом просто масштабировать, не прикладывая особых усилий. Поговорим о внутренних стандартах (локально-нормативная документация или еще сокращенно называют ЛНД).
Зачем нужны внутренние стандарты?
Стандарты описывают единые правила игры для всех, на кого распространяется действие документа, т.е. могут быть внутренние стандарты для всех работников организации, могут быть для каких-то подразделений или только для участников каких-то процессов. Все зависит от конечной цели и результата, который вы ожидаете увидеть. Возьмем самый простой пример: мы так устали работать, что хочется отдохнуть. И тут встает вопрос, а как же оформить отпуск? Начинаю звонить в отдел кадров, для этого надо найти номер телефона сотрудников или почтовый адрес или вообще любые контакты. Ведь надо узнать КАК оформить отпуск?
Допустим опросив пару десятков работников (т.е. отвлекли всех кого могли) узнаем контакты и звоним, нам даже отвечают, но просят перезвонить чуть позже, а у нас уже горит и желание начать планировать отпуск переполняет и мы снова звоним и пишем в отдел кадров. Телефон не отвечает, электронная почта тоже молчит. И вот спустя сутки приходит ответ: напишите заявление. Мы радостные несёмся писать, но как написать правильно? Ведь отпуск бывает разный: оплачиваемый/неоплачиваемый, например. Хочу оплачиваемый, но уже с завтрашнего дня. А мне говорят: «фигушки, мы не будем нарушать трудовой кодекс», не позднее, чем за 3 дня до начала отпуска нужно заявление. А еще по-хорошему согласовать с руководителем, вдруг он скажет, что не время и не место и т.д. Как мы поняли нюансов может быть много. А если каждый, кто хочет в отпуск будет всех расспрашивать сначала контакты отдела кадров, потом как оформить, как выглядеть заявление и пр, то скольки времени и сил будет тратиться на элементарную процедуру.
Если один раз утвердить инструкцию с описанием всех деталей: форма заявления в зависимости от типа отпуска, с кем и как согласовать, куда прислать все документы, за сколько до начала отпуска и пр., то работники не будут тратить время на поиски, выдумывание своих подходов, а будут играть по единым и понятным всем правилам. Пошагово выполнят все, что описано в документе, никого не отвлекая, сэкономив кучу времени и сил, причем не только своих.
А если в отделе кадров новый работник?- спросите вы. То он тоже поймёт весь алгоритм действий из этого же стандарта.
Польза стандартизации в приведенном примере очевидна.
С чего начать стандартизацию?
Обратимся к требованиями ИСО 9001.
При создании и актуализации документированной информации организация должна соответствующим образом обеспечить:
а) идентификацию и описание (например название, дата, автор, ссылочный номер);
б) формат (например, язык, версия программного обеспечения, графические средства) и носитель (например, бумажный или электронный);
с) анализ и одобрение с точки зрения пригодности и адекватности.
(Опишем и утвердим правила разработки документов и начнём с идентификации: очевидно, что у каждого документа должно быть название. А что если придется вносить изменения? Как отличить один документ от другого с таким же названием? Тут у нас есть 2 варианта:можно указывать дату ввода в действие и/или версию документа.
Разберем немного подробнее: казалось бы даты вполне достаточно, но тогда сложно будет отслеживать все изменения, которые произошли, и общее количество измененных документов,т.е. количество версий. Если одна из версий «потеряется», то никто даже не заметит. А если будет нумерация: версия 1, версия 2, версия 4, то сразу будет понятно, что куда-то пропала версия 3.
А можно и то и другое. Лишним не будет Нужен еще какой-то идентификатор. Добавим версию документа или издание, кому как больше нравится. И вот уже у нас есть название документа и версия. Может показаться, что этого достаточно, но не совсем. Глядя на документ хотелось бы видеть еще и дату с которой документ действует. Чтобы не искать приказ, которым введен документ и уточнять дату ввода в действие. Исключение составляют те случаи, когда гриф и дата утверждения стоят на титульном листе. Т.е дата ввода в действие в таком случае приравнивается к дате утверждения документа автоматически.
Рекомендую все эти данные дублировать на каждом листе. Самый удобный способ- это печать таких данных в колонтитулах. Даже если по каким-то причинам читая документ отвлекся, то все нужные данные есть на каждой странице. Нет необходимости отлистывать куда-то и искать нужную информацию, все перед глазами. И идеально было бы все это настроить автоматически, чтобы вручную не заносить данные(название, номер, дата введения в действие) во все необходимые поля. Не очень удобно, если вдруг пропадёт дата или версия, документ все равно остаётся управляемым, хоть и сильно усложняется процесс ( ведь все еще есть версия и дата введения в приказе) , но очень критично, если они, версия и дата введения, одновременно «пропадут» по какой-то причине из документа. Рекомендую разделить документы на уровни в зависимости от сложности структуры организации или холдинга, если документы едины для нескольких организаций.
Например: 1 уровень: политики организации (-ий). На этом уровне только основные цели, задачи и необходимая информация по всем направлениям деятельности организации.
2 уровень: документы, которые распространяются на всю организацию или на несколько организаций/подразделений
3 уровень: документы подразделений, такие как регламенты, инструкции, справочники и пр., которые не затрагивают другие подразделения, т.е. не являются сквозными.
4 уровень: записи (по привычке называем так, но согласно ИСО 9001 - это документированная информация, подтверждающая соответствие требованиям). Какие и как -это уже определяет сама организация.
Уровни принято изображать пирамидой.
Обратите внимание, как на картинке один из первого уровня бувально вытекает второй, а из второго третий. Система документации так и должна строиться, каждый следующий уровень детализирует предыдущий и все взаимосвязано. Уровни не существуют в отдельных параллельных плоскостях, они дополняют друг друга и создают единую взаимосвязанную систему документации. Это принципиально важный момент. Но любая попытка дополнить создает ощущение перегруженности. Поэтому выше просто предоставила вам разные, но не идеальные, варианты визуализации уровней, вдруг что-то из этого найдет отклик у вас.
Чуть выше мы уже говорили, что в организации может быть не одна система управления, а много. Речь идет о различных направлениях деятельности: система управления качеством, система организационного управления, система управления рисками, система управления персоналом и т.д
В таком случае очень удобно создать нумерацию документации таким образом, чтобы номер документа содержал не только уровень и порядковый номер, но и сокращение системы управления, например.
например:
СМК1-001 издание 1. Политика в области качества.
ОРГ2-001 издание 1. Правила внутреннего трудового распорядка.
ИБ2-005 издание 3. Положение о персональных данных работников.
ИТ3 - 002 издание 2. Процедура тестирования разработанного ПО и запуска в эксплуатацию.
Сейчас многие базы документов электронные. Проще ставить фильтры и по системе управления и по уровню. Можно сразу увидеть в какой системе управления сколько и каких документов.
Все атрибуты документа могут пригодиться в процессе отслеживания различных метрик процесса стандартизации и верификации документации организации. Да и по опыту могу сказать, что даже между собой работникам иногда проще назвать номер документа, если они используют его часто, а название громоздкое.
И вот наконец-то мы пришли к тому, что проще всего, чтобы требования к разработке документа выполнялись легко и задорно, то можно создать несколько шаблонов (недавно мы уже говорили о некоторых деталях при создании шаблонов), с уже настроенными полями и атрибутами, чтобы каждый раз разработчикам документов не приходилось изобретать велосипед: настраивать поля, указывать всю необходимую информацию, в соответствии с внутренними требованиями, создавать стили заголовков, автоматическую нумерацию, автоматическое оглавление. Для сокращения трудозатрат рекомендую создать и утвердить шаблон, а так же провести внутреннее обучение, чтобы научить пользоваться этим инструментом.
Справедливости ради хочу сказать, что все документы по системам управления должны писать владельцы процессов. Безусловно, это могут делать и СМКашники, но для написания нормального, рабочего документа, они 20 раз отвлекут участников процесса, чтобы те сначала рассказали что и как работает, все детали рассказали, потом прочитали то, что получилось, выдали замечания и снова работа по внесению изменений. Да и испорченный телефон никто не отменял. А если владельцы процесса вдруг "вспомнили", что надо еще добавить или убрать лишнее , т.к. что-то потеряло актуальность. В общем это усложняет процесс разработки документа в разы. Представим еще, что СМКашники заняты, есть более срочные задачи, в таком случае разработка документа затянется на неопределенное время, особенно с учетом того, что всем подразделениям вдруг понадобились документы, а отдел, занимающийся разработкой стандартов не резиновый, там сидит всего пару человек и те уже рвут на себе последние волосы, потому что ничего не успевают разработать, да текучку тоже никто не отменял. В общем только владельцы процесса знают нюансы и что и в каком виде нужно описать, на что обратить внимание в документе и могут быстро внести изменения в документ не дожидаясь никого. Любой документ должен быть рабочим, т.е. меньше воды, больше полезной информации. Не должно быть погони за количеством стандартов. Пусть их будет меньше, но они все используются работниками организации. Нам ведь важно не количество, а качество!
Долой стандартизацию ради стандартизации!
Важно научить владельцев процессов писать документы, а для этого рекомендую проводить внутреннее обучение по направлению «стандартизация» регулярно и включить туда не только обучение по использованию шаблонов и техническую часть разработки, но и основные правила и нюансы в зависимости от вида документа. Мы всегда считаем, что в компаниях работают опытные пользователи ПК (по крайней мере уже у каждого есть эта фраза, даже если это не соответствует действительности. Кто ж проверяет то?), но далеко не все могут учить других и писать правильные документы , пользоваться текстовыми редакторами и таблицами. Внутреннее обучение может исправить и этот нюанс.
О правилах хорошего тона и нюансах содержания внутренних документов в зависимости от вида и цели документа, а может даже и шаблонах, если будет интересно, то мы поговорим далее.