Главная страница » Блог » Регламент взаимодействия. Что нужно знать

Регламент взаимодействия. Что нужно знать

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

Что из себя представляет регламент взаимодействия

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

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

Регламент взаимодействия и регламент бизнес-процесса

Важно помнить: любой регламент, это управляющий документ, который определяет, как должно быть. То есть, если что-то «зарегламентированно», это означает, что компания требует, чтобы это было именно так.

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

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

Зачем нужен регламент взаимодействия

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

  1. То, как на текущий момент осуществляется взаимодействие, является скорее источником проблем, чем решений.
  2. Взаимодействие подразделений снижает эффективность процессов, в рамках которых оно осуществляется.
  3. Необходимо однозначно определить зоны ответственности во взаимодействии.
  4. У взаимодействующих участников постоянно возникают вопросы о порядке взаимодействия.
  5. Каждый из участников взаимодействия преследует собственные интересы, в ущерб интересов компании.
  6. Взаимодействие подразделений является весьма эффективным, а его регламентация позволит получить описание, которое можно было его экстраполировать / масштабировать.
Сам по себе, регламент взаимодействия не решит ни одну из вышеупомянутых ситуаций. Кроме №6. Для их решения необходим комплекс действий. Но ни один комплекс не обойдется без документа, в котором можно найти ответы на все вопросы, касательно взаимодействия. Поэтому, если регламенты бизнес-процессов недостаточны для формализации взаимодействия, все равно придется регламентировать.

Таким образом, регламент взаимодействия необходим для того, чтобы:

  1. Определить требования к взаимодействию, которые будут соответствовать потребностям компании.
  2. Собрать требования в одном документе, который будет являться источником информации для всех заинтересованных сторон.
  3. Формализовать состав, способы и условия взаимодействия, и получить такое описание, которое снимет все текущие вопросы.
  4. Однозначно зафиксировать ответственность участников взаимодействия.
  5. Акцентировать внимание участников не на процессах, а непосредственно на обмене информацией в рамках процессов.

Как обеспечить эффективный охват взаимодействий

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

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

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

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

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

Итак, мы подошли к тому, что все взаимодействия в регламенте должны быть разбиты на 3 типа:

  1. Регулярное взаимодействие
  2. Событийное взаимодействие
  3. Неопределенное взаимодействие

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

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

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

Что должно быть зафиксировано в регламенте взаимодействия, чтобы он был эффективным

Регламент эффективен тогда, когда выполнено 3 условия:

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

Чтобы выполнить первое условие, регламент взаимодействия должен давать ответы на следующие вопросы:

  1. Что является предметом взаимодействия?
  2. К какому процессу относится взаимодействие?
  3. Какое событие / условие инициирует взаимодействие?
  4. Кто является инициатором, отправителем?
  5. Что должен сделать отправитель?
  6. Кто является получателем?
  7. Что должен сделать получатель?
  8. По каким каналам осуществляется взаимодействие или каков его механизм?
  9. Каковы требования к взаимодействию?
  10. Основной результат взаимодействия?
Пример:
  • Предмет взаимодействия: Отчет о проделанной работе
  • Процесс: Еженедельная отчетность
  • События начала: Каждая рабочая пятница
  • Инициатор / исполнитель: Сотрудник отдела «Н»
  • Действия исполнителя: Отправка готового отчета получателю
  • Получатель: Руководитель отдела «М»
  • Действия получателя: Получатель обязан подтвердить получение отчета.
  • Канал: Корпоративная электронная почта
  • Требования: Отчет предоставляется в свободной форме. Должен содержать описание выполненных задач, с указанием времени, потраченного на выполнение.
  • Результат: Получатель подтвердил получение отчета.
Еще пример:
  • Предмет взаимодействия: Обсуждение проекта развития «Х»
  • Процесс: Управление проектами
  • События начала: Дата и время, указанное в приглашении к обсуждению
  • Инициатор / исполнитель: Руководитель проекта
  • Действия исполнителя: Исполнитель должен создать уведомление о планируемом обсуждение и направить общее приглашение всем участникам проекта
  • Получатель: Участники проекта, согласно плана коммуникаций
  • Действия получателя: Получатели должны подтвердить участие в обсуждении в корпоративном календаре
  • Канал/механизм: Очное обсуждение. Для инициации обсуждения, руководитель проекта обязан направить уведомление участникам проекта не менее, чем за 2 дня до планируемой даты. Уведомление отправляется через создание встречи в корпоративном календаре.
  • Требования: Уведомление об обсуждение должно содержать список вопросов, перечень информации, которую должны подготовить участники обсуждения, а также дату, время, длительность и место встречи. Все участники обсуждения, получившие уведомление, обязаны на нем присутствовать. По итогам обсуждения руководитель проекта обязан отправить резюме совещания всем участникам проекта.
  • Результат: Протокол совещания отправлен всем участникам проекта

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

Что нужно знать

  1. Регламент взаимодействия может регулировать взаимодействие между двумя и более участниками нескольких процессов. Да, регламент может описывать взаимодействие между организационными единицами и между организациями.
  2. Любое взаимодействие осуществляется в рамках бизнес-процесса. И это должно быть указано в регламенте взаимодействия. Если вы не можете определить процесс, это повод для того, чтобы сделать это в ближайшее время.
  3. Чем больше информации о процессах, тем точнее получится регламент взаимодействия. Однако регламент можно подготовить и без описания бизнес-процессов. Регламент взаимодействия не должен содержать детальное описание бизнес-процессов.
  4. Регламент взаимодействия отличается от регламента бизнес-процесса. Взаимодействие является частью процесса, и регламент процесса описывает все его стороны. Регламент взаимодействия рассматривает только одну точку зрения — состав и порядок осуществления обмена информацией между участниками процесса.
  5. Как и процесс, взаимодействие может начинаться по нескольким событиям начала. То есть, одно взаимодействие может осуществляться по нескольким причинам. Время — частный случай условия начала. Если взаимодействие привязано ко времени, то вместо события начала нужно указать время или период.
  6. Инициатор, или исполнитель, несет всю ответственность за взаимодействие. Во взаимодействии нет смысла выделять отдельного ответственного. Это тот случай, когда действие порождает ответственность.
  7. Получателей может быть несколько. Очень важно описать действия получателей, которые они должны выполнить.
  8. В качестве требований может выступать: требования к содержанию и форме, описание используемых форм документов, требования к результатам взаимодействия, требования к процессу взаимодействия и так далее. Описание требований — один из самых важных пунктов, при этом, он может содержать в себе любую информацию, которая имеет значение для обеспечения целей и эффективности взаимодействия.
  9. Описание результата необходимо для того, чтобы можно было точно понять, в каком случае взаимодействие завершено успешно. А также для того, чтобы можно было специфицировать требования к результатам.
  10. Безусловно, вы можете добавить свои составляющие в описание. Например, указать роли участников взаимодействия согласно модели RACI.
  11. Некоторые вещи можно рассматривать как одно, или несколько взаимодействий. Например, согласование бюджета может быть представлено как два (как минимум) взаимодействия, или как одно. Если это два взаимодействия, то одно из них будет связано с отправкой бюджета на согласование, а второе с обратной связью — утверждением.

Структура регламента взаимодействия

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

  1. Область действия регламента — очень короткий раздел, в котором нужно указать, между кем осуществляется взаимодействие, описанное в регламенте, и в рамках каких процессов оно осуществляется. Этого достаточно.
  2. Ответственность за соблюдение регламента — опишите, кто, с каждой стороны, и какую ответственность несет за то, чтобы взаимодействие осуществлялось именно так, как описано в регламенте.
  3. Описание регулярных взаимодействий — опишите регулярные взаимодействия, в соответствии со структурой, описанной выше в статье.
  4. Описание событийных взаимодействий — опишите взаимодействия, имеющие нерегулярный, событийный характер.
  5. Непредвиденные взаимодействия — опишите какие действия должны быть предприняты, если возникает непредвиденное взаимодействие.
  6. Пояснения — термины, расшифровка сокращений, ссылки и прочее.
  7. Приложения – в приложениях будет полезно разместить образцы и формы документов, которые встречаются в описании взаимодействий.

Заключение

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

Отладка бизнес-процессов, это решение, которое всегда дает устойчивый и долгосрочный результат.

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

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

Создание регламента – пол дела. Самое интересное начинается на этапе внедрения. Но это уже другая история.

by Roman Zaytsev

Добавить комментарий

Ваш адрес email не будет опубликован.