Портал №1 по управлению цифровыми
и информационными технологиями

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

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

  1. Не превращать регламент процесса в книгу о процессе, в которой пространно излагается, что "бывает такая ситуация, а бывает другая ситуация, а правила для определения сроков определить невозможно, а сопоставление бывает выполнить очень сложно, но надо стараться и полагаться на опыт" и прочее (такое описание чаще всего является следствием переписывания книжек ITIL). Регламент процесса должен помогать читателю четко осознать последовательность действий. Лучше всего излагать его языком действий от третьего лица по отношению к роли процесса. Например: получив сообщение по e-mail, оператор выпоняет следующие действия (список).
  2. Не превращать регламент процесса в описание машинного алгоритма, в котором длинные и сложные логические схемы только затрудняют восприятие, все равно не обеспечивая полноту картины (ибо реальная жизнь всегда сложнее модели процесса). Люди не работают по алгоритмам. Хороший регламент процесса всегда уделяет внимание контролю исполнения, а не только детальному описанию мыслей автора "как должен был бы исполняться процесс". Поэтому в регламенте процесса всегда необходимо определять не только последовательность исполнения, но и порядок контроля. Процесс, на мой взгляд, вообще больше не про алгоритм работы – ее специалисты и так делают – а про взаимодействие, контроль, оценку и совершенствование.
  3. Писать как можно короче. Определить себе целевое значение по максимальному количеству страниц в регламенте. Помнить – каждая лишняя страница отнимает несколько читателей. На протяжении последних лет из проекта в проект мы сознательно сокращали объем документации. Сейчас средний регламент процесса занимает 30-40 страниц. А не 70. И не 130. И мы продолжаем сокращать.
  4. Наличие метрик и слова о том, что менеджер обязан готовить отчеты – это не венец развития процесса. Необходимо ответить себе на вопрос: зачем формируются отчеты, что, кем, как и когда будет делаться на их основании? Зачем нужны такие метрики в процессе? О чем говорят их значения, какую роль они меряют, какому управленцу предназначены? Например, метрика "процент инцидентов, принятых второй линией в работу с нарушением времени реакции" является показателем качества работы старших функциональных групп второй линии и может / должна быть использована как часть системы их мотивации.
  5. Разрабатывая регламент процесса, думать: какую ценность для заказчика он несет? На чем должен быть основной акцент? Процессы не должны стремиться к идеалу, потому что идеал – это очень дорого. Поясню: на самом деле задача коммерческой компании быть немного лучше конкурентов. И все. "Немного" потому, что "много" – нерентабельно. "Лучше" потому, что иначе – погибнет. Документация, определяющая порядок исполнения, контроля, оценки и совершенствования деятельности, должна разрабатываться с учетом реальных потребностей и уровня зрелости заказчиков, а не повторять кем-то прекрасно придуманный (но, к сожалению, не совсем осознанный консультантом) процесс.

Точка.

«Управление проектами на основе PRINCE2»
Трёхдневный аккредитованный учебный курс

Комментариев: 12

  • Андрей

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

    • Андрей, на мой взгляд: описание процесса, рабочая инструкция, регламент, положение и т.д. – это всё совершенно не важно как назвать. И не так уж важно как структурировать.

      Конечно, стройная картина документирования процессной деятельности только поможет работе, но, я так думаю, это далеко не первый приоритет. Как мы часто любим говорить друг другу, обсуждая очередной проектируемый процесс, “процесс НЕ заработает не из-за этого”. С точки зрения успешного выполнения и улучшения процесса нужно, чтобы документация отвечала на перечисленные чёткие вопросы. А будет ли этот “сборник ответов” называться регламентом, или инструкцией по исполнению – дело десятое.

      (хотя, как и все бывшие технари, мы часто стремимся к системности, в т.ч. в структуре документации :))

      • Introduction to RealITSM:
        “Технари любят полноту и точность, не говоря уж о нежном пристрастии к сложным, умным и изящным решениям, независимо от наличия задачи. В результате мы получаем ETF: стремление делать вещи правильно, независимо от того, будет ли это полезно, рационально, выгодно и разумно – то есть от того, имеет ли это смысл.”
        (c) IT Skeptic

  • Точнее и не скажешь. Готов подписаться под каждым словом.

    • Андрей

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

      • 1. На самом деле в регламенте процесса могут (и во многих случаях должны) присутствовать “общие слова” о процессе. Например, общее описание ролевой структуры, правила иерархической эскалации, взаимодействие с другимии процессами и т.д. НО не надо смешивать эти общие слова с описанием порядка исполнения, чтобы читателю не пришлось самостоятельно отделять мух от котлет. Все общие слова лучше вынести в отдельные разделы регламента. Тогда будет понятно: здесь мы объясняем, что это за процесс, а здесь – как конкретно его исполнять (на основании этого раздела в основном и готовятся ролевые инструкции).
        2. Структурная документация (пирамида документов и прочее) – это прекрасно. НО надо думать не только о проекте, а о том, что будет с процессом потом, когда заказчик останется с ним один на один. Чем сложнее пакет документов, тем больше работы и внимания он потребует при обновлении, т.к. надо обновить не один докумен, а несколько взаимосвязанных. Для многих заказчиков это сложно, и когда жизнь изменится, документация процесса начнет от нее отставать, процесс “поплывет”. Поэтому при выборе степени детализации и структуры документов см. пункт 5 – зрелость заказчика. При прочих равных – чем проще, тем лучше.

  • не нашел “самого главного” 🙂

    Регламент – это живой документ у которого есть владелец (не у нас, консультантов), который обязан его регулярно обновлять и пересматривать …

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

    • Alexander Boyko

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

  • Анна Лобова

    Дима, отличная статья, спасибо!

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

    Спасибо!

  • Александр Кавакин

    Дмитрий,

    с момента написания статьи прошло много времени, изменилось ли в вашей практике что-то? Стал ли регламент еще короче, проще?

    Так же была статья Checklist https://realitsm.ru/2015/03/checklist-reglament-processa/ от ее написания так же прошло некоторое время, если ли изменения?

    • Реальный разброс 30-50 страниц в зависимости от процесса (например, cfg – покороче, slm – подлиннее). В ряде случаев делаем регламенты в виде pptx (правда в основном как дополнение к docx, редко – на замену). Структура, указанная в чеклисте, сохранилась.


Добавить комментарий для Анна ЛобоваОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM