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

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

longtime_construction

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

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

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

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

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

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

  • Илья Рунов

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

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

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

  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT