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

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

Опубликовано 13 октября 2013
Рубрики: Обо всём на свете, Общие вопросы менеджмента, Постоянное улучшение, Практика и опыт, Технологии, автоматизация, ПО для ITSM
Комментарии

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

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

Например, незачем заставлять читать рядового ИТ-специалиста описание процесса управления изменениями на 80 листах, если его работа в процессе ограничена одной процедурой. Достаточно общего представления о процессе и понимания своего места в процессе. 

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

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

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

А вы что думаете? 

 

АВТОМАТИЗАЦИЯ
Реестр ESM- и ITSM-систем в России 2024
Из чего выбирать и на что мигрировать

Также по теме:

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

  • Анатолий Павлюченко

    Документирование – мерило зрелости организации.

    • Кротов Алексей

      документирование ради документирования? =))

      ИМХО, это единый источник данных, к-рый не завязан на личности и "хотелки". Все знают, как делаем, все знают, почему так делаем и кто делает.

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

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

      • Pavel Solopov

        Да уж, а обеспечить не противоречивость документа в процессе его изменения это та ещё задача, а если он ещё и связан с другими процессами… Без автоматизации тут не обойтись…

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

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

          • Pavel Solopov

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

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

    • Дмитрий Исайченко

      Только если документы являются рабочими инструментами. Иначе это показатель безделия организации.

      • Анатолий Павлюченко

        А кто сказал, что безделие не есть уровень зрелости?

  • Дмитрий Исайченко

    Я думаю предложенная практика регламентации процессов (описание процесса на 60-80 страниц) имеет альтернативы. Я видел процессы, задокументированные в MS Excel – на одном (хоть и большом :)) листе. У нас в Cleverics есть несколько внутренних, весьма важных, реламентов на 3-5 страниц. Есть практика единого документирования только основных положений процесса (политик, требований, распределения обязанностей), а дальше каждая группа подстраивается под общие верхнеуровневые правила по-своему, в том числе с разным подходом к документированию.

    Кто хочет, тот ищет способ 😉 И рано или поздно находит наиболее подходящий для себя вариант.

    • Денис Денисов

      Вот есть такой термин  – "итальянская забастовка", когда все работают по правилам. В своей практике я знаю примеры, когда разработчики документов старались описывать всё очень глубоко, детальной. Это приводило к тому, что документы приобретали большой объём. Но, насколько я ощутил, всех нюансов не предусмотришь, всех правил в документе не опишешь. И часто выходило так, что, столкнувшись с нештатной ситуацией, не увидев её отражения в регламенте, работали либо по своим, либо приостанавливали работу, кивая на "сырой документ". А поскольку регламент претендовал на "истину в последней инстанции", то авторитета это ему явно не добавляло.

  • Andrey

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

    При этом процессы, хоть их и не много (было, по крайней)

  • Andrey

    продолжение предыдущего поста – 

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

  • Андрей

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

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

  • Pavel Solopov

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

    И толщина документов является мерилом обоснованности затрат на проект.

     

    • Олег Скрынник

      И толщина документов является мерилом обоснованности затрат на проект.

      неужели это всё ещё так?

      • Pavel Solopov

        А что такое эпохальное произошло, чтобы это изменилось? Да и поставьте себя на место аудиторов им же приходится проверять проекты всевозможной тематики, и не только в области ИТ, как им оценивать обоснованность расходов? Оценка по толщине проета весьма обоснованная: чем больше материалов – тем больше исполнитель работал, тем обоснованней расходы…

  • Роман

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

    • Анастасия Кировская

      У нас нечто подобное (полторы сотни ИТ-специалистов) – только не в форме конкурса, а зачета. Вопросы предварительно передаются на ознакомление, результат влияет на премирование (до следующего зачета). 

  • Nargiza Suleymanova

    Согласна, что редко бывает необходимым делать регламенты процессов объемными. В моем случае это были документы страниц на 20-30, причем описание самого процесса (цели, задачи, определения, участники, визуальная схема процесса, описание логики переходов) занимало страниц 10, остальной объем – формы используемых документов (шаблоны) и метрики процесса. Детально шаги (задачи) описывались отдельно, в рабочих инструкциях.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.