IT ManagerИТ в бизнесеУправление

Управление процессной документацией

Евгений Шилов | 15.12.2014

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Управление процессной документацией

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

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

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

В некоторых случаях при формировании документации решается еще одна задача: выполнение условий, необходимых для соответствия требованиям определенных стандартов, например, ISO/IEC 20000-1. 

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

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

От ответов на эти вопросы будет зависеть состав документов, их содержание, применяемые методики описания, стиль изложения, подходы к публикации и поддержке в актуальном состоянии.

Процессная документация в теории

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

В частности, в документе Process Assessment Model (PAM): Using COBIT® 5 для процессов второго уровня зрелости1 определяются следующие документы:

Описание процесса, включающее в себя следующие сведения:

  • Название процесса
  • Владелец процесса
  • Охват процесса
  • Роли процесса
  • Общая схема процесса
  • Процедуры процесса
  • Матрица RACI
  • Таблица управления рисками

План управления процессом:

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

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

Как видите, требований к документированию довольно много, но по каждому ли пункту вы готовы сказать, как именно вы будете использовать данную информацию и кто является её потребителем? 

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

Не включайте в документ информацию, потребители и назначение которой вам неизвестны.

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

Пример структуры процессной документации

Для того чтобы удовлетворить потребности в информации о процессе всех заинтересованных лиц обычно достаточно трех видов документов:

  • Регламент процесса
  • Положение о процессе
  • Ролевые инструкции

Дополнительно могут оформляться документы, специфичные для конкретного процесса, например, план управления конфигурациями, правила приема обращений в Service Desk, классификатор изменений и тому подобные.

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

Регламент процесса – документ, устанавливающий детальные правила исполнения процесса, а поэтому наиболее полно описывающий все аспекты выполнения процесса и используемый в основном владельцами, менеджерами процессов и руководителями ИТ-подразделений.

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

Подобная структура позволяет четко разделить документы по потребителям и сократить трудозатраты при их обновлении.

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

img

Регламент процесса

Данный документ содержит в себе самую полную информацию о процессе. Обычно в документе присутствуют разделы, описывающие:

  • Назначение процесса
  • Ключевые принципы построения процесса
  • Детальное описание процедур
  • Ролевую модель
  • Метрики 

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

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

  • Входы/Триггеры
  • Выходы
  • Схема процедуры 
  • Описание действий

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

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

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

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

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

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

Ролевые инструкции

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

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

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

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

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

Один из вариантов структуры ролевой инструкции выглядит следующим образом:

  • Рабочие инструкции по выполнению процедур процесса
  • Требования к участнику процесса
  • Метрики и способы оценки работы участника процесса 

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

Положение о процессе

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

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

Так как большая часть сотрудников, которые будут знакомиться с документом – бизнес-сотрудники, документ создается на языке понятном, бизнес-пользователям. Обычно положение включает в себя, как минимум:
 
  • Назначение и задачи процесса
  • высокоуровневые принципы работы процесса, включая порядок вовлечения бизнес-подразделений в исполнение процесса.

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

Распространение документации

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

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

Поддержка документации в актуальном состоянии

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

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

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

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

Ключевые слова: управление проектами

Об авторах

Евгений Шилов

Евгений Шилов

Заместитель директора по консалтингу компании Cleverics

Мероприятия

23.09.2018 — 25.09.2018
XII Конгресс "Подмосковные вечера"

Москва, Атлас Парк Отель. Домодедово, Судаково, 92,

26.09.2018
Loginom Day 2018: продвинутая аналитика, легкая в приготовлении

Москва, event-холл «Инфопространство»

02.10.2018 — 03.10.2018
Открытая конференция для бизнеса и ИТ «ACCELERATE»

Москва, Краснопресненская набережная, 14 Экспоцентр

02.10.2018
Практики построения современного трейдинга

Москва, Арарат Парк Хаятт, зал Саргсян

04.10.2018 — 05.10.2018
БИТ Санкт-Петербург 2018

Санкт-Петербург, проспект Медиков, дом 3, Конгресс-центр «ЛПМ»