Звонки по России:
Заказать звонок
Комплексное продвижение сайтов
и управленческий консалтинг
Каталог услуг

Система регламентов (часть 1): общие технические требования к программному обеспечению и сервисам для реализации “хранилища регламентов”

Кто хочет много достигнуть, должен ставить высокие требования
Иоганн Вольфганг фон Гёте

кому: собственникам, топ-менеджерам

Система регламентов с технической точки зрения состоит из множества небольших, но важных элементов.Система регламентов с технической точки зрения состоит из множества небольших, но важных элементов.

Большинство руководителей осознают острую необходимость в системе регламентов в своей компании/подразделении. У некоторых она уже есть в зачаточном состоянии. На всякий случай напомню, что система регламентов — это упорядоченный набор должностных и функциональных инструкций (регламентов) для сотрудников, шаблонов документов.

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

Далее я предполагаю, что какие-либо сомнения отсутствуют, и вы сейчас думаете над вариантами технической реализации системы регламентов: разместить документы на сервере в формате MS Word, подключить Office 365 от Microsoft, использовать гугл-документы как часть сервиса Google Apps?

Оглавление статьи

Проблемы, “хоронящие” идею системы регламентов

Моя практика консультирования клиентов по созданию и развёртыванию системы регламентов (в рамках консультаций по регулярному менеджменту) показывает основные проблемы, возникающие при ее внедрении и повседневном использовании:

Проблема №1. С технической точки зрения: тяжело держать регламенты актуализированными

Сотрудники, которые работают с регламентом, не имеют возможности оперативно вносить изменения, а если и вносят, то появляется "проблема версионности" — у разных сотрудников оказываются разные версии документов, да ещё и с разными изменениями.

В итоге вместо системы регламентов получается ворох разрозненных, неактуальных и бесполезных (а порой и крайне вредных!) для дела документов. В такой ситуации собственник или топ-менеджер “плюёт на всё” и ставит крест на системе регламентов. Как сделать так, чтобы система регламентов в компании всегда была актуальной и удобной для развития с технической точки зрения, и пойдёт речь в этой статье.

Проблема №2. С управленческой точки зрения: непросто выстроить систему управления, при которой сотрудники будут развивать регламенты

Как выстроить работу сотрудников так, чтобы они самостоятельно развивали и создавали новые регламенты? Кое-что об этом я рассказал в статье "«Попробуй заставить меня написать регламент!» или Алгоритм по написанию регламентов: как делегировать разработку инструкций своим подчинённым".

Основные риски в системе регламентов

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

  1. Одновременное редактирование документов и, как следствие, возникновение двух разных версий одного документа.
  2. Случайное удаление части информации из регламента.
  3. Удаление одного или нескольких документов (случайное, преднамеренное).
  4. Утеря всех регламентов или большей их части из-за технического сбоя.
  5. Неудобство работы пользователей, обсуждения документов, внесения дополнений, актуализации документов.
  6. Несанкционированный доступ к регламентам со стороны персонала, которым они НЕ предназначались.
  7. Выгрузка регламентов со стороны сотрудников с целью их дальнейшего коммерческого использования (здесь вам поможет отработка юридического аспекта вопроса: заключите с вашими сотрудниками “соглашение о конфиденциальности” + подключите к минимизации этого риска квалифицированного юриста).

Итак, с помощью какого программного обеспечения или сервиса создавать систему регламентов? Как выбирать из разных вариантов? Могу сразу сказать, что один из наиболее подходящих вариантов: “Google Apps для бизнеса” (с гугл-документами). Но что делать, если Вы по какой-либо причине ищете альтернативы?

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

Ключевые “общие требования” к программному обеспечению и сервисам для реализации системы регламентов

1. Функционал для работы с текстовыми файлами и таблицами

Программное обеспечение или сервис для системы регламентов должны предоставлять как минимум возможность работать с текстовыми документами (аналог Microsoft Word) — ведь большинство регламентов создаются именно в текстовом представлении.

Желательно, чтобы была возможность также работать и с табличными данными в виде отдельных файлов (аналог Excel).

2. Экспорт в DOCX и PDF

Иногда возникает необходимость отправить регламенты кому-либо в виде обычных документов. В этом случае программное обеспечение для системы регламентов должно обеспечивать возможность экспорта документов в распространённые текстовые форматы DOCX (MS Word) и PDF (Adobe Acrobat), табличные — XLSX (MS Excel).

При этом крайне важно, чтобы все локальные ссылки на разделы внутри документа, если таковые были созданы в процессе редактирования документа, продолжали работать и в форматах DOCX и PDF.

3. Резервное копирование, защита от удаления

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

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

Лучшая защита от удаления документов — право на удаление только у создателя (“владельца”) документа. При этом все сотрудники, создающие новые документы в системе регламентов, должны назначать “владельцем” не себя, а заранее созданный специально для этих целей аккаунт.

4. Структура папок, иерархия (на примере файловой системы)

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

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

Скриншот показывает структуры папок исполнительного директора (для документа в формате Google Docs)Скриншот показывает структуры папок исполнительного директора (для документа в формате Google Docs)

5. Предоставление доступа: иерархия, наследование, пользователи, группы

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

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

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

На скриншоте доступ к документу предоставлен для двух пользователей и двух групп (на примере сервиса Google Docs)На скриншоте доступ к документу предоставлен для двух пользователей и двух групп (на примере сервиса Google Docs)

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

Должны быть реализованы три ключевых права доступа: чтение, комментирование, запись.

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

Иногда какой-либо регламент необходимо предоставить пользователям, которые не подключены к системе регламентов: сотрудники, не занесённые в неё, внешние подрядчики и т.д. В этом случае возникает дилемма: либо добавлять пользователя в систему (затраты по времени, дополнительные покупки лицензии), либо выгружать файл в DOCX или PDF и отправлять ему по почте.

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

7. Одновременное редактирование документа несколькими пользователями в режиме реального времени

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

Технология одновременного редактирования документа позволяет “отработать” один из самых сильных рисков, который, как было отмечено в начале статьи, зачастую “хоронит” всю систему регламентов — рассогласование версий регламента, конфликты редактирования, наличие разной информации у разных сотрудников.

 Более чем наглядная иллюстрация рассогласования версий документов Более чем наглядная иллюстрация рассогласования версий документов

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

8. Версионность и история изменений документов

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

История изменений (версионность) позволяет посмотреть,  кто, когда и какой конкретно кусок документа дополнял/ корректировал/ изменял, а также “откатить” документ к любой из предыдущих версий. Новая версия документа должна сохраняться после каждого “блока” внесённых в документ изменений.

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

revisions-of-document.pngСкриншот показывает наличие сохранённых предыдущих версий регламента, хранящегося в формате Google Docs (на примере регламента для всех сотрудников)

9. Режим комментирования документа и хранение истории комментариев

Возможность одновременно комментировать и редактировать документ разным пользователям — одно из ключевых требований. Бесценный режим для обсуждения документов многими участниками одновременно или в некий период времени.

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

Функция одновременного комментирования документа так же важна, как и одновременное его редактирование

Крайне желательно, чтобы комментирование документа было доступно в двух режимах: “рецензирование” и “выносные комментарии”. Обязательно, чтобы у каждого комментария стояли дата, автор и присутствовала возможность ответа. Теперь про два режима комментариев.

Режим “рецензирование“— пользователь редактирует текст прямо в документе, и внесенные им правки подсвечивается специальным образом (см. скриншот ниже). Тот, у кого есть право на редактирование документа, может внесённые правки “подтвердить” или “отклонить”. Этот режим позволяет совместно работать над документом, когда один из участников играет роль “модератора”.

Скриншот показывает пример рецензирования в документе (для документа в формате Google Docs)Скриншот показывает пример рецензирования в документе (для документа в формате Google Docs)

Режим “выносные комментарии” (см. скриншот ниже) позволяет выделить некий фрагмент текста документа и оставить комментарий, привязанный к этому фрагменту. Как правило, именно в таком режиме обсуждают документ и собирают вопросы от тех, кто будет в дальнейшем работать с регламентом.

Скриншот показывает пример выносных комментариев (для документа в формате Google Docs)Скриншот показывает пример выносных комментариев (для документа в формате Google Docs)

Чтобы не “засорять” регламент неактуальными комментариями, должна присутствовать возможность “закрыть” комментарий, когда вопрос обсуждён и более не актуален.

Часто есть необходимость посмотреть все комментарии, в том числе и “закрытые” ранее, чтобы вспомнить, какие вопросы обсуждались при составлении документа. Отсюда следует, что должен присутствовать функционал, который позволяет скрыть, а затем и “открыть заново” любой ранее “закрытый” комментарий.

Скриншот показывает пример истории комментирования, галочкой отмечены “закрытые” комментарии (для документа в формате Google Docs)Скриншот показывает пример истории комментирования, галочкой отмечены “закрытые” комментарии (для документа в формате Google Docs)

10. Поиск по тексту всех документов, именование регламентов и файлов

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

На скриншоте показана разница между “именем файла” и “названием регламента” (для документа в формате Google Docs)На скриншоте показана разница между “именем файла” и “названием регламента” (для документа в формате Google Docs)

Поиск должен осуществляться по именам файлов и тексту всех документов в системе регламентов. Это позволяет быстро найти нужный регламент.

Например, сотруднику магазина потребовалось в отсутствие директора закрыть и поставить на сигнализацию помещение. Работник вбивает в поисковой строке “поставить на сигнализацию инструкция” и находит нужный регламент. Поиск идет по всем текстовым документам и таблицам.

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

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

Пример названия: “Как поставить на сигнализацию торговое помещение (магазин): Инструкция (регламент)”. В примере используются две пары синонимов: “инструкция - регламент” и “торговое помещение - магазин”.

Скриншот показывает пример поиска и отображения результатов поиска, а также именования файлов на английском (для документа в формате Google Docs)Скриншот показывает пример поиска и отображения результатов поиска, а также именования файлов на английском (для документа в формате Google Docs)

11. Доступ через web-интерфейс (достаточно браузера) к сервису

Серьёзное преимущество, которое позволяет без дополнительных настроек пользоваться базой регламентов на любом компьютере в любой операционной системе. Главное — иметь доступ к системе регламентов и установить браузер (Chrome, Firefox, Яндекс.Браузер).

12. Наличие приложений у сервиса/ПО для iOS и Android

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

13. Наличие своего MarketPlace со сторонними расширениями, которые развивают функционал системы

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

При наличии MarketPlace можно официально и безопасно (не факт, конечно же, что бесплатно!) пользоваться чужими наработками (изобретение своего велосипеда всегда было дорогим занятием). Например, в Google-документах в длинных регламентах крайне неудобно каждый раз при просмотре возвращаться наверх к оглавлению. Некие разработчики написали расширение “Table of contents”, которое постоянно отображает оглавление в левом столбце при прокрутке экрана. В этом и есть преимущество системы MarketPlace, так как сама компания Google, возможно, этот функционал не реализует никогда.

На скриншоте выводится начало списка расширений для Google-документов.На скриншоте выводится начало списка расширений для Google-документов.

Продолжение следует...

На этом завершаю список “общих требований” к программному обеспечению (сервисам) для системы регламентов. В одной из следующих статей я подробно расскажу про требования к “текстовому редактору” для системы регламентов. Как я уже говорил, это архи-важная тема, ибо большинство регламентов создаётся в текстовом виде.

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

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

Заполните форму, чтобы получить ссылки на подборку полезных «засекреченных» видео-записей и материалов от «Открытой Студии» + новые «фишки» на регулярной основе

Ваше имя*
Не заполнено поле
Email*
Не заполнено поле