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

ORBIT или методика обоснования ITSM-проекта снизу вверх

Опубликовано 28 октября 2012
Рубрики: ITIL, ITSM, Практика и опыт, Проекты
Комментарии

То, что ITSM в целом и ITIL в частности являются инструментами управленца, а не самоценными результатами «внедрения» известно многим. То, что из этого следует, что подходить к организации каких-либо процессов ITSM надо с задач, а не с перечня процессов, так же известно многим. Тем не менее, «знаю» не превращается в «делаю» само собой.

Например, мы регулярно получаем на вход RFP с формулировками типа «Цель проекта – внедрение управления изменениями и конфигурациями». И далее, конечно «пришлите коммерческое предложение» или «сколько будут стоить ваши услуги по внедрению?». Иногда постановка незначительно варьируется и цель проекта формулируется как «Повысить качество управления ИТ» (без «излишних» деталей, разумеется) и далее то же «внедрить процесс такой-то». Нередки и вопросы типа «Как обосновать внедрение процесса такого-то?». То есть хвост продолжает вилять собакой.

Ну что ж, раз проекты не планируются сверху вниз (от задач к решениям), давайте попробуем ставить задачу «снизу вверх» – от процессов к задаче. Для этого предлагаю следующее несложное упражнение. Берём лист А4, располагаем его в альбомной ориентации и делим его на четыре равные части (как показано на рисунке). Далее выполняем следующие шаги:

  1. В верхней левой части (Outcomes) пишем, что Вы, собственно, планируете сделать, получить в проекте. Есть только одно условие: писать не названия процессов, а содержание, конкретику. Например, если речь идёт про SLM, можно написать: «Сформирован каталог услуг, который включает в себя…», «Заключены SLA с такими-то контрагентами, определяющие такие-то условия», «Организован мониторинг параметров предоставления услуг» и так далее. Чем конкретнее, тем легче Вам будет потом.
  2. В нижней левой части (Business benefits) пишем, чем это полезно бизнесу. На какие ответы руководства компании позволит ответить. Продолжая пример, «Численные KPI для оценки качества операционной деятельности ИТ-подразделения» и так далее.
  3. В нижней правой части (IT-department benefits) пишем, чем это полезно руководству ИТ-департамента, то есть возможно лично Вам. Какие Ваши проблемы удастся решить. Например, «Основания для пересмотра ресурсного плана при превышении согласованных объемов потребления ИТ-услуг».
  4. В верхней правой части (Risks) пишем, какие риски есть у проекта. Какие сложности необходимо преодолеть, чтобы получить перечисленные Outcomes и, таким образом, достичь заявленных преимуществ для бизнеса и ИТ-подразделения. Например, «Отсутствие средств мониторинга для контроля параметров предоставления услуг не позволит обеспечить достоверную отчетность».

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

По понятным причинам это упражнение называется ORBIT. Как и у SWOT-анализа, его основная ценность в лаконичности представления, наглядности и полноте анализа. Поэтому очень важно уложиться на один лист, один слайд презентации. По крайней мере, для небольших проектов 🙂

«Управление проектами на основе PRINCE2»
Трёхдневный аккредитованный учебный курс

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

  • Красиво. И универсально, можно ведь для любого ит-проекта использовать, не обязательно ITSM. Реорганизация ИТ, внедрение новой системы… Квадранты будут те же, и логика обоснования “снизу”, и проблема исходная та же – знаем, что делаем, но затрудняемся объяснить, зачем. Хорошая система, годная.

  • Вадим

    Нравится! Согласен и с Романом: “можно использовать для любого проекта” (причем не обязательно ИТ-, но мы о других-то не говорим)

    Однако, как мне кажется, проблема тут не в том, чтобы красиво разложить по полочкам(впрочем, это тоже нужно уметь) , а скорее в том, чтобы ИТишники, которые продают этот проект “своему” бизнесу, реально понимали потребности бизнеса (и не только в терминах “да добавим пару полей в базу, и наступит счастье”)

    P.S. Кстати, в вводной части резануло …э… стилистика, что ли, чего не замечалость в последнее время. В качестве примера – второе предложение.

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

    • Вадим

      ОК, вопрос снимаю.
      остается “просто нравится”, постараюсь использовать опыт в работе, будут результаты – поделюсь.

    • Вадим

      а по второму предложению [в тексте] что? )))

      • После Вашего комментария я слегка изменил второе предложение. Сейчас оно меня больше не беспокоит 🙂 Но если у Вас есть лучший вариант текста – присылайте, рассмотрим.

        • Вадим

          Меня вот не беспокоит такая формулировка
          Поэтому подходить к организации каких-либо процессов ITSM надо с задач, а не с перечня процессов, что так_же известно многим.

          Еще вариант, получччче:
          Большинство этих многих также знает, что подходить к организации каких-либо процессов ITSM надо с задач [которые ими решаются], а не с перечня процессов.

          дарю )))

          при желании можно еще наскорректурировать))

  • Pavel Solopov

    Немного разбавлю всеобщий оптимизм и позитив. 🙂
    Чтобы заполнять такой квадрат надо обладать определённым опытом и навыками в построении процесса. Иначе может получиться абсолютно надуманно и никак не связано с реальностью. Можно конечно взять ITIL и попытаться заполнить квадрат теми преимуществами и рисками, которые там иногда описаны. Но насколько такой квадрат будет полезен, большой вопрос.
    К тому же надо не забывать, что заполнение квадрата это лишь первый шаг. Вторым шагом должно стать сравнение написанного в четверти Business benefits с имеющимися потребностями бизнеса. И если они не совпали, то надо переигрывать Outcomes и т.д. Вобщем есть большие сомнения, что это сможет качественно реализовать человек, который не выбрал данную стезю для себя в качестве профессии.

    С другой стороны, на каждом углу трубят о лучших (ну или хотя бы просто хороших практиках). Раз наличие SLM – хорошая практика (или даже лучшая), значит надо ей следовать! Поэтому вполне логично и просят: “внедрить процесс такой-то”.

    • “Поэтому вполне логично и просят: «внедрить процесс такой-то».”

      Павел, скажите честно, Вы и правда так думаете (про “вполне логично”)? Или просто, чтобы беседу поддержать? 😉

      • Pavel Solopov

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

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

        • Наверно разница в том, что бизнес всё ещё интересуется обоснованием ITSM-проектов, в то время как центральная канализация воспринимается как неотъемлемая часть инфраструктуры, и отдельного обоснования не требует.
          Видимо они ещё не настолько привыкли к идеям Карра, как Вы 🙂 Я, честно говоря тоже отношусь к этим идеям, как к некоторой перспективе. Во всяком случае, сегодня доля организаций, использующих центральную канализацию, существенно превышает долю организацией, у которых работает SLM (упомянутый Вами в качестве примера) 🙂

          • Pavel Solopov

            Несомненно разница есть.
            Канализацией бизнес пользуется значительно чаще, чем отчётами о соблюдении SLA (кстати хорошо если он этими отчётами не только в привязке к пользованию канализацией 🙂 ).
            Да и отсутствие канализации бизнес ощутит на собственной шкуре быстро и явно, не в пример отсутствию процесса SLM. 🙂

            А если серьёзно, то пропаганда “лучших/хороших” практик, о которых мы ведём речь ведётся в среде ИТ-шной. А в среде бизнеса о них возможно и не догадываются.
            При этом “лучшая/хорошая” практика воспринимается, как папочка в которой есть и обоснование для бизнеса на любые случаи жизни.

            У меня как-то был такой диалог:
            – Какие основные выгоды вы хотели бы получить от внедрения управления инцидентами.
            – Ну, все обычные выгоды управления инцидентами.
            – Могли бы вы конкретно сформулировать, что именно.
            – Ну что конкретно, да все обычные выгоды, как у всех, все их знают…

        • Есть и ещё одна важная разница: реалистичность и ясность ожиданий заказчика. Всё-таки большинство заказчиков неплохо представляет себе, что такое центральная канализация и какие плюсы появляются при её наличии. Вот про SLM я такого сказать не могу 🙂

    • Вадим

      Раз наличие SLM — хорошая практика (или даже лучшая), значит надо ей следовать! Поэтому вполне логично и просят: «внедрить процесс такой-то».

      Для того, чтобы следовать “практике SLM” надо ведь каталог услуг какой-никакой сначала иметь, по крайней мере, чтобы было уровнем чего управлять )))
      Получается смешная картинка: чтобы внедрить SLM – начать с внедрения SLM нельзя ))

      P.S. и потом все-таки процесс внедряется для чего-то, а не для того, чтобы “а не внедрить ли нам какой-нибудь SLM?”

      P.P.S. в качестве SLM можно поставить любую другую аббревиатуру любого другого процесса.

      • Pavel Solopov

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

        • “Процесс (наличие которого объявлено лучшей практикой) внедряется для того, чтобы следовать этой лучшей практике”

          К сожалению маловато доказательств того, что эта практика – лучшая (в частности в таких областях, как SLM, CFG, PRB). Утверждение про лучшие практики является типично рекламным. Следуя этой логике можно принять очень много спорных решений – в выборе автомобиля, жилья, лекарств, еды, средств гигиены, программного обеспечения и многого другого, не только практик управления. Если предприятие коммерческое и должно выживать и конкурировать, ему такой подход не по силам. Как говорил известный персонаж известного фильма: “Плохо кончится, родной”.

          • Pavel Solopov

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

            Так ведь и принимают… 🙂
            Я же не обсуждаю с Вами правильно ли делают или нет.
            Я только говорю, что такое поведение вполне логично в существующем информационном поле.
            Есит реклама, как вы справедливо заметили, есть те, кто этой рекламе верит.

            • Вадим

              Так ведь и принимают…

              а если все будут с крыши сигать? тоже, видимо, следует поддаться “лучшим практикам”?

              Я только говорю, что такое поведение вполне логично в существующем информационном поле.

              Вы, конечно, можете говорить любую ахинею все что хотите, но от этого логичности поведению не добавляется )))

              • Pavel Solopov

                Вадим, я никого не убеждаю в том, что что-то НУЖНО. Я говорю о том, как есть в нашем не совершенном мире. Вы же, если хотите, можете попытаться изменить мир.
                Но пока, если появится такая “лучшая практика” с крыши прыгать, то, я уверен, найдётся достаточно много желающих ей последовать.
                (Так, например, произошло во времена великой депрессии в США)

                • Вадим

                  это все ваши, простите, тараканы.
                  а вообще в ИТ много лет назад я пошел, чтобы действительно как-то по своему менять мир. вы же не будете утверждать, что за последние лет 25-30 он сильно изменился.
                  не скажу, конечно, что это исключительно моя заслуга, но смею надеяться, что малая толика в этом все-таки имеется…

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

                  Nothing personal just business

                  • Pavel Solopov

                    Вадим у нас с вами дискуссия как с органами власти.
                    Я вам говорю, что асфальт уложили абы как и везде лужи на дороге.
                    А вы мне отвечаете, что в соответствии с ТЗ луж быть не должно, согласно актам всё сделано в соответствии с ТЗ, значит луж нет.

                    А тараканы, Вадим, это ваши. У меня красные летающие крокодилы.

                    • Вадим

                      у меня тоже нет тараканов, только синие лягушки)))

        • Вадим

          не слишком задумываться вредно для здоровья

          правильно ниже написали: “плохо кончится, родной” (с)

          • Pavel Solopov

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

            • Вадим

              эк жеж вас скрутило)))
              отпуск в неизведанном месте (неизвестной стране с неизвестным языком и совершенно непонятными обычаями) быстро ставит голову на место.

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

  • Георгий

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

    Плюс, чтобы это называть ясной формулировкой проектной задачи, надо бы добавить (помимо денег, но это может быть след шагом, в качестве расчета показателей) как минимум:
    1. Конкретики по поводу того, кого называем бизнесом, чьи задачи решаем
    2. Про ит-департамент понятно, видимо там цели ИТ-руководителя, если нет, то уточнить бы стоит
    3. Что именно делам в проекте и чего не делаем точно

    • “То есть это ни разу не снизу вверх, а просто «раз хотите процессы», напишите процессы, а потом будьте добры все равно писать сверху вниз”

      Почему “все равно писать сверху вниз”? Ты же пишешь преимущества, основываясь на разделе Outcomes, а не наоборот. Это и есть снизу вверх. Никакого обмана 🙂

      • Георгий

        А-а 🙂 так, это ж еще хуже 🙂 Обмана нет, да, но тогда буквы B и IT в славной аббревиатуре вообще ни о чем 🙂
        так чисто переписать, что дает процесс некому вирутальному бизнесу и виртуальному ИТ-директору – фактически книжку ITIL переписать на листочке, помедитировать и все… выбросить 🙂

        Ибо если, задаться мыслью брать реальные Бизнес-преимущества и ИТ-преимущества, то придется сразу думать о том, кто это такие “Бизнес” и “ИТ”, целях, которые перед этими лицами стоят, ну итд, т.е. по-любому “подниматься сразу вверх, хотя и начал вроде снизу”

        • “т.е. по-любому «подниматься сразу вверх, хотя и начал вроде снизу»”

          Конечно! Так это и есть – снизу вверх 🙂 Просто я сталкиваюсь с тем, что выйти на бизнес-задачи, сначала сформулировав более-менее конкретные ожидания для многих заказчиков проще, чем наоборот. Так и родилась идея.

          “чисто переписать, что дает процесс некому вирутальному бизнесу и виртуальному ИТ-директору — фактически книжку ITIL переписать на листочке, помедитировать и все… выбросить”

          А вот это неверно. Делать это упражнение вне контекста – вообще бессмысленно. Поэтому ничего виртуального. Наоборот – даже если это упражнение делает консультант, он может это сделать только вместе с заказчиком. Иначе просто смысла нет никакого.

          • Георгий

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

          • Я почти ничего из комментов не понял, но за “контекст упражнения” глаз зацепился.

            Дело в том, что я прямо в понедельник попробовал использовать ORBIT в качестве упражнения на семинаре про управление конфигурациями. Слушатели – участники и менеджеры процесса.
            И вы не поверите: Результаты сформулированы и мгновенно привязаны к преимуществам бизнеса. Те кто пришел учиться и читал про учет активов и конфигураций точно себе представляет, что предприятие-заказчик (или группа заказчиков) выиграют время. Время, которое ИТ-директор тратит на ответы про стоимость ИТ, учет ОС и т.д.
            А вот изобретение выгод для ИТ-руководства заняло больше времени. Выгоды ведь получились те же: меньше времени на ответы + возможность управленческого учета. То есть, разницы между нижними квадратами нет? Может быть, Дмитрий, дополнить нижний правый не только ИТ-руководством, а?

            • Только что в соседней ветке (http://www.realitsm.ru/2012/10/trojan/) Роман переживал, что задачи бизнеса и ИТ-подразделения различаются. Теперь здесь Костя переживает, что они совпадают. А Вадим с Павлом обсуждают тараканов, драконов и лягушек…
              Отпусти меня, чудо-трава! 😀

              • Pavel Solopov

                Чем вам не нарвятся тараканы, лягушки и крокодилы (не путать с драконами) или хотите поговорить про определение ИТ-сервиса?
                🙂

            • Pavel Solopov

              Странная выгода для бизнеса: Выиграть время, которое ИТ-директор тратит на ответы про стоимость ИТ, учет ОС и т.д.
              У кого выиграть? У ИТ-директора, чтобы с ним кофейку попить, ведь он так мастерски травит анекдоты?

              Я бы на месте бизнеса хотел бы, чтобы у меня вообще не было необходимости задавать такие вопросы, вот это я понимаю преимущество: ставлю задачу и всё работает как мне нужно и без всяких вопросов.
              А так получается, что бизнес зачем-то хочет получить техническую информацию, видимо чтобы её как-то обрабатывать и принимать решения, а ИТ-директор это всего лишь такой оператор БД.

        • Вадим

          все хорошо, одного не понял “почему речь о процессе?”
          не процессом единым!

          • Особенно верно то, что не единым 🙂

            • Вадим

              мое любимое слово, которое я часто применяю в контексте? схожем с тематикой статьи? чем постоянно задалбливаю коллег и иногда заказчиков – “зачем?”

              • Вадим

                чёртов пунтосвитчер! вопросики вместо запятых образовались (кроме последнего)

              • Георгий

                С какого-то возраста появился вопрос “Зачем”, вот раньше тебе звонил приятель, говорил, я познакомился с двумя девушками, у них отдельная квартира в Отрадном, я выпить купил, поехали. Ты сразу ехал… (с) О чем говорят мужчины

          • Георгий

            Ну так в заметке же про процессы и про то как их обосновывать снизу вверх…

            • Вадим

              ааа, ну да, это ж первое предложение )))


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM