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

Обследования (основы)

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

  1. Есть проблемные области в управлении ИТ, ситуацию  в которых хотелось бы улучшить.
  2. Есть непреодолимое желание проверить, что "все сделано правильно".

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

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

Теперь о том, что должно быть на выходе.Обычно заказчика интересует перечень мероприятий для совершенствования. Здесь можно рекомендовать только проверку наличия обоснования для каждого из мероприятий и достаточного уровня детализации. Обоснование для реализации мероприятий должно содержать объяснение, основывающееся на фактах, а не фразы "так в ITIL, поэтому и вам необходимо", "так делают все, а вы – нет". Желательно, чтобы был проведен анализ рисков, описано чем грозит отказ от реализации данных мероприятий.

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

К сожалению, на практике не всегда эти простые идеи используются, поэтому периодически приходится сталкиваться с отчетами об обследовании, подготовленными различными компаниями, которые вызывают ощущение "развода" Заказчика на выполнение дополнительных работ, которые не всегда нужны, ну или не нужны в предлагаемом объеме.

Возможно кому-то изложенные мной мысли помогут правильнее поставить задачу консультантам или оценить результат.Если у вас тоже есть, чем поделиться по этой теме – ждем ваши комментарии. 

«VAP: Построение системы KPI для ИТ»
Как обеспечить управление процессами, проектами, услугами, персоналом

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

  • Pavel Solopov

    Обоснование для реализации мероприятий должно содержать объяснение, основывающееся на фактах, а не фразы “так в ITIL, поэтому и вам необходимо”, “так делают все, а вы — нет”.

    Что вы имеете в виду под фактами? Можете пример привести?
    “так делают все, а вы — нет” это вполне себе факты достаточные для принятия решения. Что вы можете им противопоставить? Противопоставить им можно либо ваше личное мнение “я думаю, что вам это поможет”, либо эксперимент “давайте попробуем сделать так в филиале Х и посмотрим как получится”. Я других фактов не вижу.

    • Павел, конечно могу привести примеры и детализировать свои мысли. Например, не во всякой компании найдутся ресурсы для полноценной (т.е. со всеми, описанными в ITIL, видами деятельности) реализации процесса управления проблемами. Однако, даже небольшие компании хотят устранять ошибки в инфраструктуре. Можно им советовать умереть, но внедрить процесс управления проблемами для решения своей задачи устранения ошибок инфраструктуры. А можно подумать, как решить задачу другими способами, возможно опирающимися на идеи ITIL, но не копирующими их полностью.
      «так делают все, а вы — нет» – не всегда аргумент. Все зависит от того, как построена выборка “Все”, учитывает ли выборка специфику компании, и речь не только о размере и отрасли. Консультант должен анализировать гораздо больше параметров для принятия решения о том, что предложить в качестве решения. Зачастую личный опыт и детальный анализ текущей ситуации позволяет принять более точное решение.

      • Pavel Solopov

        Евгений, при всём моём к вам уважении, Вы не привели примера “фактов”. Вы говориет как раз о собственных (как консультанта) предположениях.
        Фактами (с моей точки зрения) были бы следующие утверждения:
        1. Внедрение проблема требует N человеко дней.
        2. Вы имеете свободных K человеко дней.
        3. K-N0.

        Как-то так. Вот только где вы такие факты добудете?

        “все”, конечно же, должны выбираться с учётом специфики. Вот только откуда выбираться? Я такого систематизированного источника не знаю. Кроме что, разве, моего листа на list.ly 🙂

        • Pavel Solopov

          Что-то часть сообщения кануло в небытие… Повторяю.
          3. K-N меньше 0.
          4. Если выкинуть из проблема а, б, в, г… то трудоёмкость внедрения составит M человеко дней. K-M больше или равно 0.

        • “Вот только откуда выбираться?” – я как раз о том же. Не стоит опираться на странные выборки, надо смотреть на конкретную компанию. И т.к. этот пост я адресовал больше заказчикам подобных услуг, то и рекомендация звучала как “Обоснование для реализации мероприятий должно содержать объяснение, основывающееся на фактах”.
          Павел, про факты – мы говорим с вами об одном и том же с разной степенью детализации. Когда я говорю о нехватке ресурсов, то очевидно, что речь идет о том, что работа процесса требует больше трудозатрат, чем имеется в распоряжении.
          Причем я бы делал акцент именно на трудозатратах на работу процесса, а не на внедрение, т.к. внедрение – разовая активность и трудозатраты по ней можно растянуть во времени. А вот работа процесса – активность регулярная и повлиять на трудозатраты в рамках процесса можно правильно его спроектировав (упростив, сузив область охвата и т.д.).

          • Pavel Solopov

            В том-то и дело, что для заказчиков. Неаккуратно пророненное слово, да ещё и возможно неверно понятое потом и клещами не выкорчуешь…
            Вы говорите факт, а имеете в виду свою личную субъективную оценку ситуации, а другие понимают факт как объективное доказательство.

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

            P.S. Очень часто даже в очень больших компаниях в которых и ресурсов достаточно и запасы есть приходится слышать: “Кто же это будет делать? У нас нет свободных ресурсов…”. Вот вам и факт…

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

    • «так делают все, а вы — нет» это вполне себе факты достаточные для принятия решения

      Где же здесь факты? “Так делают все” – это отголоски пропаганды, или рекламы, или призывов вендоров и проч.

      • Pavel Solopov

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

  • Vladimir Lyaleko

    В последнее время, очень часто сталкиваюсь с вариантом обследования после “политических переворотов” 🙂

    Команда меняется целиком, новое руководство не может понять текущие положение дела (as is) и приглашает внешних консультантов в надежде разобраться в новой для себя среде.

    Это я к чему…

    В приведенных Вами примерах у нас есть понимание правильного состояния. Мы проверяем соответствие правильному состоянию или пытаемся устранить проблемные области в ИТ. В этом случае, как мне кажется, речь идет скорее об аудите, а обследование \ исследование (анг SURVEY) не подразумевает в себе каких либо проверок на соответствие, просто исследование текущего состояние среды \ объекта управления.

    З.Ы. До Вашего поста у меня в голове укладывалась разница между Аудитом и Обследованием…. теперь похоже я запутался 🙂

    • Grigory Kornilov

      Предлагаю использовать as is и to be, имхо
      1. При аудите мы знаем to be (обязательство, главное), узнаем as is
      2. При исследовании мы узнаем as is (главное), и думаем какое хотим to be (желание)

      • Вот это очень хороший тезис – может быть он и не совсем точный, но зато отлично показывает разницу. При проведении аудита to be есть на входе (как часть стандарта), именно на основании известного to be оцениваем as is. При проведении диагностики (обследования) to be получается на выходе, как результат анализа рисков в контексте выявленного as is. То есть “to be” и есть существенное отличие.
        Бывает и так, что внешний аудит может являться частью внутренней диагностики (обследования). В этом случае внешний исполнитель проводит аудит, базируясь на каком-то согласованном с заказчиком стандарте (to be). А затем заказчик, анализирую аудиторское заключение, формирует to be с учетом рисков сохранения выявленных несоответствий.

        • Георгий

          Согласен на 99%, только вот
          to be получается на выходе, как результат анализа рисков в контексте выявленного as is
          тут не только риски анализируем для to be

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM