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

Документы и практика

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

Поэтому в ответ на вопрос "вы следуете регламенту [название]", получаю ответы: "да, но только вот тут и вот тут мы уже работаем иначе", "нет, не следуем, документ далек от практики" и т.д.

Практика показывает, что наиболее распространенные причины кроются в том, что:

  1. Непонятна цель создания документа. 
  2. Непонятны потребители документа.
  3. Документ разработан одним-двумя сотрудниками без вовлечения в разработку всех заинтересованных лиц.
  4. Документ не прошел согласование и ему не придан статус официального.

Список причин конечно можно продолжать: 

  1. Не зафиксирован ответственный за обновление документа.
  2. Нет триггеров и процедуры обновления документа.
  3. Участники регламентируемой деятельности не информированы о существовании документа.
  4. Доступ к документу затруднен.
  5. Отсутствует контроль за соблюдением положений документа.

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

  1. Стоит определить цель создания документа и его потребителей. Например, если вам необходимо обеспечить единообразное выполнение процедур всеми участниками процесса, то вряд ли им стоит давать в руки пятидесятистраничное описание процесса, а вот краткая ролевая инструкция подойдет, если ее структура позволит быстро найти описание необходимых действий. 
  2. В разработку документа или его согласование необходимо вовлечь ключевых специалистов, которые смогут внести в документ специфику той области в которой они работают, оценить реалистичность описываемых действий и скорректировать документ так, чтобы его требования были выполнимы.
  3. Разработанный документ должен быть утвержден на уровне руководства и доведен до сведения сотрудников как обязательный к исполнению.
  4. Должен быть определен порядок обновления документа и ответственный за его обновление.
«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

  • Pavel Solopov

    Я бы ещё добавил:

    5. Должен быть организован контроль за исполнением исполнения с применением санкций зп не исполнение.

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

    Не в стиле РеальногоИТСМа. 🙂

  • Peshkov Alexander

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

    • Вадим

      ну замОчите — где других найдете?

      • Мне тоже сдается, что мочить — это не выход. Лучше создать условия при которых документ будет востребован.

        • Peshkov Alexander

          Евгений, я ведь в самом начале написал, что все условия выполнены —

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

          При этом таких — подавляющее меньшинство. Большинство включились, ходят на семинары и изучают материал, выдают RFC. Так вот я предлагаю мочить конкретно именно эти меньшинства.

      • Peshkov Alexander

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

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

        Я и говорю — мочить!!

        • Вадим

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

          если же не в вашей, то ничего вы с ним не сделаете.

          и потом, перефразируя О.И.Б.М.Бендер-бея, Трудовой кодекс надо чтить, его ведь тоже никто не отменял...

  • Вадим

    IMHO причины, что по документам не работают всего две:

    — документы плохие и сложные

    — люди не умеют (и не хотят) работать по документам

    документы плохие по нескольким причинам:

    — «писателям» свойственно непроизвольно усложнять язык, многие просто не владеют русской письменной речью на достаточном уровне, чтобы простым языком на одной странице написать все, что нужно,

    — «писатели» не умеют рисовать простые и понятные схемы, используя инструменты порождающие схемы с высоким уровнем абстракции, т.е. концентрируются на средствах, а не на целях документа,

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

    — при всем старании документ получается бОльшим, чем нужно «читателю», несмотря на то, что «писатели» хотят сэкономить собственные силы (и при этом просто опускают какие-то связующие моменты).

    Вывод - документ должен быть простой как гвоздь.

    «читатели» тоже хороши:

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

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

    Вывод - читателей нужно готовить, тренировать.

    Есть и внешние причины:

    — людей обычно меньше, чем ролей, поэтому документов много и они перегружены,

    — конкретная используемая процессная схема недостаточно проработана и поэтому невнятная,

    — про цель уже написано.

    P.S. Чтобы кто-то не подумал лишнего, я тоже «писатель» :о))) что, впрочем, видно из коммента )))

  • «Практика показывает, что наиболее распространенные причины кроются в том, что»

    Моя причина номер 1 — у исполнителей нет стимулов работать по регламенту. А сам документ может быть абсолютно не причём. Нормативные документы не являются достаточным условием изменения деятельности. Даже о-о-очень хорошие нормативные документы.

    • у исполнителей нет стимулов работать по регламенту

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

      • Ну может быть я просто не увидел это в твоих пунктах. Контроль исполнения у тебя стоит на 9-м месте (пятый пункт в списке «конечно можно продолжать»), стимулирование явно не указано.

        На мой взгляд, стимул исполнять новые правила работы не является прямым следствием ни одного из перечисленных 9-ти пунктов. Иначе достаточно было бы написать хороший регламент и — вуаля — все прекрасно работают 🙂

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

    А кто-то Устав (воинской службы) видел-помнит-учил?

    В армии нет проблемы «неправильного» документа, только проблема исполнения приказов.

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

    Создание неработоспособного документа тоже легко укладывается в эти рамки.

    • Вадим

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

      Это-то как раз и приводит к отсутствию документов и ситуации «всё, что и как нужно делать, написано в должностной инструкции» — т.е. замкнутый круг

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

        Я не имел в виду только «должностную инструкцию». Набор регламентов должен содержать наборы ролей и соответствующих обязанностей в рамках того или иного процесса.

        Должностная инструкция не должна содержать те же самые обязанности. Это, скорее, набор более обобщённых обязанностей для позиции из организационной структуры. А регламенты содержат функциональные обязанности.

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

  • Вадим

    кстати, про то какими должны быть документы ... ну хорошо-хорошо не документы, а хотя бы пользовательские инструкции

    www.youtube.com/watch?fea...mp;v=vQT7yX2csG0


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

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

  • Рубрики

  •  
  • Авторы

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

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT