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