Выбор программного обеспечения для реализации системы регламентов: как принять взвешенное решение?

«Успех полностью зависит от проделанной подготовки. Без нее вас неминуемо ждет неудача»

Конфуций

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

Сценарии использования статьи: кому полезна и для чего

Собственникам — понять, чем нужно руководствоваться при выборе программного обеспечения для реализации системы регламентов.

Топ-менеджерам — вспомнить ключевые сценарии владельца процесса и оценить возможность их реализации через то или иное программное обеспечение.

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

Как вы думаете, где применимы регламенты, кроме работы? Можно привести много примеров из обычной жизни.

Начну с себя. Моих детей трудно заставить выполнить что-то в определённой последовательности. Например, они знают, что должны встать утром, пойти в ванную, умыться, вымыть руки, пойти на кухню, позавтракать, собраться на прогулку и т. д. Чтобы контролировать, что они ничего не забыли и не пропустили, нужно буквально стоять у них за спиной.

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

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

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

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

Идти на поводу у мнимых авторитетов в вопросе выбора программного обеспечения для реализации системы регламентов опасно. Если вы неверно выбрали систему на старте, менять её в процессе работы будет больно и дорого:

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

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

Критерии выбора сервисов и систем

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

На рынке есть разные продукты, которые могут выполнить схожий набор функций, чтобы выбрать между ними, нужно их сравнить. Кому-то важнее будет стоимость продукта, кому-то — простота внедрения и освоения. Для метода взвешенных оценок используются таблицы с набором критериев, но это «продвинутый уровень». Я советую начать с базы и составить общий перечень критериев.

Приведу пример с «весом» параметра. Есть компания, которая выполняет оборонный заказ. Первым критерием выбора будет безопасность данных и запрет на размещение их на иностранных серверах и в иностранной IT-инфраструктуре. Учитывая этот критерий из выборки придётся выбросить многие популярные сервисы, какими бы простыми и удобными они не были.

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

2. Количество пользователей системы (распространённость). Этот критерий показывает, легко ли будет найти специалистов для поддержки и доработки системы, есть ли у неё потенциал для развития?

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

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

3. Динамика развития (оценка перспектив). Думать нужно на перспективу 3-5 лет. Динамика развития — это оценка того, как сервис развивается и улучшается. Большие сервисы могут «вымирать как мамонты», если они не инвестируют в развитие и не работают над устранением выявленных недостатков.

4. Стоимость владения (необходимость доработки, поддержка инфраструктуры, риски и т. д.). Нередко собственники решают «изобретать велосипед» и разрабатывать собственную систему силами штатных сотрудников или фрилансеров.

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

   В случае использования готового решения все проблемы, баги, «дыры в безопасности» исправляют разработчики и выпускают обновления, которые достаточно просто установить. Если система самописная внутренняя, то обязанность по её оптимизации, адаптации и поддержке будет внутренним проектом компании, оплачиваемым из её же бюджета.

5. Соответствие сценариям и рискам (важно правильно их оценивать).

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

Сценарии использования систем программного обеспечения

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

1. Пользовательский сценарий. Он описывает, как именно пользователь системы выполняет в ней задачи. Пример пользовательского сценария: мне как пользователю нужно проконтролировать, что из регламента никто ничего не удалил.
2. Функциональный сценарий — набор действий. Пример функционального сценария: я захожу в гугл-документ, открываю историю изменений документа, прохожу по ней и изучаю блоки, которые были изменены, добавлены или удалены.

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

Пользователи системы регламентов

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

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

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

Пользовательские сценарии должны соответствовать бизнес-целям внедрения системы регламентов:

• масштабирование;
• ликвидация незаменимости;
• повышение стандартов качества;
• сокращение издержек;
• внедрение более эффективных методов работы.

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

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

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

Риски при использовании системы регламентов

1. Одновременное редактирование документа и, как следствие, возникновение двух разных версий одного документа. Это пример возможного конфликта версий.
2. Удаление части информации из регламента случайно или преднамеренно.
3. Удаление одного или нескольких документов.
4. Утрата всех регламентов или большей их части из-за технического сбоя.
5. Неудобство работы пользователей, обсуждения документов, внесения дополнений, актуализации. Процесс, который описывает регламент, может меняться очень быстро и часто. Если вносить изменения трудно, нет автоматического сохранения или есть риск потери внесённых изменений, сотрудники будут реже пользоваться этим инструментом.
6. Несанкционированный доступ к регламентам персонала, которому они НЕ предназначались.
7. Выгрузка регламентов сотрудниками с целью их дальнейшего коммерческого использования. В предыдущих статьях я рассказывал, что снизить риски поможет разграничение прав доступа и подписание документов о неразглашении. Рекомендую не пренебрегать этими советами.
8. Санкции. Это объективная реальность. Нужно понимать, что санкции точно не будут сняты в ближайшее время и скорее всего будут только ужесточаться, поэтому нужно снижать зависимость от иностранного программного обеспечения, которое может быть удалено в любой момент.

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

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

Кроме того, есть ещё один базовый сценарий, когда в тексте одного документа ставится ссылка, но не на другой документ, а на блок в этом же документе. В оффлайн-версиях Microsoft Word такой возможности нет, а она необходима.

Представьте, что в регламенте по подбору сотрудников у вас есть общий раздел «правила переговоров», и вы хотите сослаться на него. Без возможности поставить ссылку на раздел в текущем документе вы не сможете это сделать. Сотруднику придётся самому искать в общем регламенте нужный раздел.

Примеры сценариев владельца процесса

Контроль изменений

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

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

Организация совместной работы

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

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

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

Подключение сторонних пользователей

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

Если вы работаете с простыми файлами, то их придётся бесконечно пересылать собеседнику, получать от него комментарии, вносить, отправлять исправленную версию и т. д. Это очень неудобно, и велик риск потерять часть предложений и исправлений.

В гугл-документах это решается по-другому. Можно зарегистрироваться на бесплатной почте и предоставить человеку доступ на редактирование или комментирование конкретного документа.

Сохранение глобальной ссылки на файл

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

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

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

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

Выводы

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

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

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

Тренировка управленческой мышцы

Я рассказал, на что нужно обращать внимание при выборе программного обеспечения для реализации системы регламентов, а также привёл примеры сценариев использования программного обеспечения. Чтобы закрепить материал, предлагаю ответить на несколько вопросов:

1. Если в процессе работы Вы поняли, что неудачно выбрали ПО, что придётся сделать, чтобы изменить его?
2. Назовите ключевые критерии выбора сервисов и систем для реализации системы регламентов.
3. В чём отличия пользовательского и функционального сценариев использования ПО? Приведите один или несколько примеров каждого типа сценариев.
4. Почему выбору программного обеспечения для реализации системы регламентов нужно уделять особое внимание? Чем грозит компании неудачный выбор ПО?
5. Вы хотите поручить кому-то из сотрудников подобрать варианты программного обеспечения для системы регламентов. Как сформулировать задачу? Чем сотрудник должен будет руководствоваться в первую очередь?