То, что ITSM в целом и ITIL в частности являются инструментами управленца, а не самоценными результатами «внедрения» известно многим. То, что из этого следует, что подходить к организации каких-либо процессов ITSM надо с задач, а не с перечня процессов, так же известно многим. Тем не менее, «знаю» не превращается в «делаю» само собой.
Например, мы регулярно получаем на вход RFP с формулировками типа «Цель проекта – внедрение управления изменениями и конфигурациями». И далее, конечно «пришлите коммерческое предложение» или «сколько будут стоить ваши услуги по внедрению?». Иногда постановка незначительно варьируется и цель проекта формулируется как «Повысить качество управления ИТ» (без «излишних» деталей, разумеется) и далее то же «внедрить процесс такой-то». Нередки и вопросы типа «Как обосновать внедрение процесса такого-то?». То есть хвост продолжает вилять собакой.
Ну что ж, раз проекты не планируются сверху вниз (от задач к решениям), давайте попробуем ставить задачу «снизу вверх» – от процессов к задаче. Для этого предлагаю следующее несложное упражнение. Берём лист А4, располагаем его в альбомной ориентации и делим его на четыре равные части (как показано на рисунке). Далее выполняем следующие шаги:
В верхней левой части (Outcomes) пишем, что Вы, собственно, планируете сделать, получить в проекте. Есть только одно условие: писать не названия процессов, а содержание, конкретику. Например, если речь идёт про SLM, можно написать: «Сформирован каталог услуг, который включает в себя…», «Заключены SLA с такими-то контрагентами, определяющие такие-то условия», «Организован мониторинг параметров предоставления услуг» и так далее. Чем конкретнее, тем легче Вам будет потом.- В нижней левой части (Business benefits) пишем, чем это полезно бизнесу. На какие ответы руководства компании позволит ответить. Продолжая пример, «Численные KPI для оценки качества операционной деятельности ИТ-подразделения» и так далее.
- В нижней правой части (IT-department benefits) пишем, чем это полезно руководству ИТ-департамента, то есть возможно лично Вам. Какие Ваши проблемы удастся решить. Например, «Основания для пересмотра ресурсного плана при превышении согласованных объемов потребления ИТ-услуг».
- В верхней правой части (Risks) пишем, какие риски есть у проекта. Какие сложности необходимо преодолеть, чтобы получить перечисленные Outcomes и, таким образом, достичь заявленных преимуществ для бизнеса и ИТ-подразделения. Например, «Отсутствие средств мониторинга для контроля параметров предоставления услуг не позволит обеспечить достоверную отчетность».
Чем конкретнее и понятнее самому себе Вы заполните все четыре квадранта, тем яснее будет сформулирована проектная задача. Тем больше оснований у Вас будет для принятия решений по ходу проекта и для оценки его результатов. Тем меньше рисков с привлечением внешних консультантов. Тем проще перейти к экономическому обоснованию проекта, если это потребуется.
По понятным причинам это упражнение называется ORBIT. Как и у SWOT-анализа, его основная ценность в лаконичности представления, наглядности и полноте анализа. Поэтому очень важно уложиться на один лист, один слайд презентации. По крайней мере, для небольших проектов 🙂
Красиво. И универсально, можно ведь для любого ит-проекта использовать, не обязательно ITSM. Реорганизация ИТ, внедрение новой системы… Квадранты будут те же, и логика обоснования “снизу”, и проблема исходная та же – знаем, что делаем, но затрудняемся объяснить, зачем. Хорошая система, годная.