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

Сколько должен длиться ITSM-проект?

longtime_construction

Ответ на этот вопрос, конечно, неоднозначен – зависит от того, что нужно получить в результате проекта. Однако, Стюарт Рэнс поделился своими соображения на этот счёт.

Не так давно Стюарт проводил рабочий семинар у заказчика, в котором принимал участие независимый ITSM-консультант, приглашённый для разработки и организации процессов в компании. Проект был разбит на несколько фаз и касался изменений в управлении инцидентами, запросах на обслуживание и управлении знаниями. Оценка сроков проекта, выданная консультантом, изумила всех – минимум 12 месяцев! Планировалось использовать подход постоянного совершенствования, чтобы улучшать процессы постепенно. Но и это условие не сильно изменило оценку консультанта – не меньше 8 месяцев и гораздо большей командой внедренцев, чем выделенные два сотрудника.

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

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

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

  • Илья Рунов

    Подход постоянного совершенствования замечатален, пока не сталкиваемся со сложностью\невозможностью заключения договора вида "time and material". На нашем рынке, предполагаю, для Заказчиков свойственно планировать бюджет под контракт за год-полтора. Как следствия – тендер и описание такого "содержания проекта", которое подтвердит такой бюджет и его ожидание Исполнителем. А так, слов нет – лучше бы и Исполнителям и Заказчикам делать маленькие подпроекты с понятными целями и возращаемой\измеряемой выгодой или почасовую оплату консультантов\внедренцев.

  • Петр Колобозников

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

  • Александр Тараторин

    Ого! Agile process management шагает по планете. Дальнейшее его распространение – вопрос времени. Вряд ли итеративный подход когда-нибудь займет доминирующую позицию, но, как и в мире software development, может серьезно потеснить классический "waterfall approach".

    Что касается области применимости – она, как и у agile software development методов, ограничена, но все равно достаточно широка


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM