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

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

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

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

Точка.

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

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

  • Андрей

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

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

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

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

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

      • Introduction to RealITSM:

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

        © IT Skeptic

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

    • Андрей

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

      • 1. На самом деле в регламенте процесса могут (и во многих случаях должны) присутствовать «общие слова» о процессе. Например, общее описание ролевой структуры, правила иерархической эскалации, взаимодействие с другимии процессами и т.д. НО не надо смешивать эти общие слова с описанием порядка исполнения, чтобы читателю не пришлось самостоятельно отделять мух от котлет. Все общие слова лучше вынести в отдельные разделы регламента. Тогда будет понятно: здесь мы объясняем, что это за процесс, а здесь — как конкретно его исполнять (на основании этого раздела в основном и готовятся ролевые инструкции).

        2. Структурная документация (пирамида документов и прочее) — это прекрасно. НО надо думать не только о проекте, а о том, что будет с процессом потом, когда заказчик останется с ним один на один. Чем сложнее пакет документов, тем больше работы и внимания он потребует при обновлении, т.к. надо обновить не один докумен, а несколько взаимосвязанных. Для многих заказчиков это сложно, и когда жизнь изменится, документация процесса начнет от нее отставать, процесс «поплывет». Поэтому при выборе степени детализации и структуры документов см. пункт 5 — зрелость заказчика. При прочих равных — чем проще, тем лучше.

  • не нашел «самого главного» 🙂

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

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

    • Alexander Boyko

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

  • Анна Лобова

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

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

    Спасибо!

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

    Дмитрий,

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
    • 6 худших вещей, которые продакт-менеджеры говорят инженерам
      Каждый хороший продакт-менеджер — полиглот. Он говорит на нескольких языках. Конечно, вы можете не говорить бегло на французском, итальянском или мандаринском. Но вы
    • На какой курс пойти, чтобы узнать про практику Х?
      Этот вопрос вы, наши слушатели, задаёте довольно часто. К тому же появились новые курсы категории VAP. Так что было бы удобно иметь под рукой справочник. Ну что же, вот оно:
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT