Как преодолеть проблемы завершающегося проекта

Павлов Владимир Алексеевич, Директор по корпоративным проектам Компании Деснол Софт Проджект - 11.03.2008

«Момент истины». Начало эксплуатации новой корпоративной информационной системы - проверка на соответствие ожиданиям бизнеса.

Как избежать ошибок и добиться успеха?

«Завтра» завершается внедрение системы, автоматизирующей основные бизнес процессы Компании, команда разработчиков и консультантов завершает проект. Как эффективно начать промышленную эксплуатацию системы? Как не допустить «разрыва, провала» в начале ее эксплуатации? Эти вопросы почти всегда возникают на последних этапах любого значительного проекта.

Проблемы и риски завершающегося проекта

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

Завершение проекта - это радостный праздник для Заказчика и Исполнителя. НО, после радостных коротких праздников всегда наступают будни. Начинается очень ответственный этап - переход к продуктивной эксплуатации системы.

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

Как тут не задаться множеством вопросов: Насколько внедренная система соответствует ожиданиям руководства и ключевых пользователей? Насколько тщательно проведено тестирование? Все ли доработки отражены в документации? Насколько эксплуатационные затраты новой системы будут укладываться в существующий ИТ бюджет? Эти и другие вопросы возникают когда есть четкое понимание того, что теперь руководитель ИТ службы отвечает за систему. В каком-то смысле, наступает «момент истины». Очень часто после завершения проекта руководство ожидает «мгновенных» результатов. А пользователи «неожиданно» начинают возмущаться.

Управление ожиданиями бизнеса и пользователей, происходящими изменениями, а не только проектом ИТ в этот момент - важнейшая задача. Ведь система создавалась и внедрялась для того, чтобы ее можно было эффективно использовать для решения бизнес задач предприятия.

Изменение инструментов управления

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

Прежде всего, для эффективного управления необходимо прейти от модели проектного управления к сервисной модели. Эффективной основой для этой модели является методология (Best Practice) ITIL, позволяющая выстроить процессы эксплуатации и сопровождения информационной системы.

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

Именно поэтому, на этом этапе необходимо особое внимание уделить организационным изменениям.

Управление организационными изменениями

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

Необходимо перечислить области приложения организационных усилий:

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

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

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

Опыт управления изменениями и ITIL дают четкий ответ: планируйте и реализуйте «быстрые победы». Именно они убедят скептиков, поднимут мотивацию персонала, снизят риски неудач. Для планирования и реализации «быстрых побед» крайне важно управлять ожиданиями - использование сервисной модели управления позволяет сделать это наиболее эффективно.

Многие проекты внедрения постоянно повторяют одну и ту же ошибку: Пользователям не нужна система, автоматизирующая бизнес - требуется сервис, помогающий им решать задачи бизнеса. Разница принципиальная: необходимо как можно скорее перевозить груз, а предлагается решать проблемы водителей, ремонтировать автомобили, строить удобный гараж. Именно скорейшее и успешное решение бизнес задач является критерием «быстрых побед».

Что делать? С чего начать? Первые шаги.

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

  1. Подготовить инфраструктуру системы и ее поддержки. 
  2. Убедиться, что персонал обучен и может осуществлять поддержку. 
  3. Убедиться, что процесс изменений системы контролируется службой поддержки. 
  4. Формализовать процесс передачи системы в эксплуатацию. 
  5. Формализовать процесс взаимодействия с пользователями.

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

  • создать паспорт системы;
  • специфицировать сервис;
  • разработать регламенты;
  • разработать метрики.

Далее об этом чуть более подробно.

Разработка сервиса

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

Однако в книгах, составляющих ядро ITIL v2 (тома Service Support, Service Delivery), информационные системы рассматриваются с момента передачи их в эксплуатацию. В каком-то смысле, это не совсем точно. Методология развивается, и именно поэтому в ITIL V3 изменился взгляд на эту проблему. Появление подхода базирующегося на понимании жизненного цикла сервиса позволяет сопоставить этапы жизненных циклов системы и сервиса. Это более живой и гибкий взгляд, который более четко определяет место проектного и сервисного подхода к управлению. Конечно, рекомендации ITIL требуют адаптации для конкретных условий, нужна зрелость как сервисных, так и проектных процессов. Тем не менее, эти принципы необходимо использовать для всех проектов внедрения.

Изменение подходов не меняет главного в методологии, определяя требования к системе и сервису, необходимо ориентироваться на бизнес. «Следуйте за бизнесом» - это главное утверждение ITIL.

Организация работы ИТ подразделения по сопровождению системы

Почти всегда существуют проблемы коммуникаций в ИТ подразделении. Как правило, в нем работают сотрудники различных специальностей и специализаций: системные администраторы, консультанты, программисты, специалисты обслуживающие кабельную сеть, оргтехнику, телефонию. Компетенции, знания, опыт каждого из них различны, порой они «говорят на разных языках». Решение типовой проблемы «программа не работает, срочно почините» требует совместных и слаженных усилий всей ИТ команды. Как часто во взаимодействии и объяснениях, а порой и упреках теряется драгоценное время. Именно ITIL решает эти проблемы, позволяет выстроить эффективные коммуникации. В каком то смысле методология определяет общий язык общения, создает единое информационное поле, которое конечно должно быть поддержано информационной системой ИТ подразделения.

Разработка регламентов на основе методологии ITIL - важная задача организации работы ИТ подразделения. Структура регламентов должна включать:

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

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

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

Примеры метрик процессов:

  • метрики процесса «Управление инцидентами»
    • количество инцидентов
    • среднее время работы между сбоями
    • среднее время закрытия инцидента
    • средняя стоимость поддержки на инцидент
    • процент инцидентов разрешенных на первой линии поддержки
    • процент инцидентов, некорректно назначенных исполнителям
    • количество инцидентов, решенных с превышением SLA
  • метрики процесса «Управление проблемами»
    • количество зарегистрированных проблем;
    • количество решенных проблем;
    • среднее время закрытия проблемы;
    • количество запросов на изменение сформированных процессом;
    • суммарные затраты на решение проблем;
  • метрики процесса «Управление изменениями»
    • затраты на произведенные изменения;
    • количество изменений;
    • количество неавторизованных изменений;
    • количество инцидентов вызванных изменениями;
    • количество срочных изменений;
    • процент отклоненных запросов на изменение;
  • метрики процесса «Управление релизами»
    • количество развернутых релизов;
    • средние затраты на релиз;
    • количество внеплановых релизов;
    • количество инцидентов, вызванных релизами;
    • количество срочных релизов;
    • процент запросов на изменений включенные в релизы за период.

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

Несмотря на то что проект завершился, остается проблема эффективно совмещения проектного и сервисного подходов в деятельности ИТ подразделения. Не существует универсальных решений и рецептов. Очень важно понимать, что проектное управление это инструмент, позволяющий эффективно «переместиться» из точки «А» в точку «В» в заданный срок и определенным бюджетом. Сервисная модель управления - это инструмент, который позволяет «находиться» в точке «В» с заданным уровнем сервиса и определенными затратами, управляя ожиданиями потребителей и совершенствуя качество обслуживания. Руководитель должен выбирать инструмент управления в каждом конкретном случае, руководствуясь потребностями бизнеса и возможностями своего подразделения. Кроме того, важно учитывать зрелость проектных и сервисных процессов. В рамках сервисных процессов это, прежде всего, управление изменениями, релизами и конфигурациями.

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

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

Вот простые советы, которые станут ключами к успеху по преодолению «разрыва, провала» в начале продуктивной эксплуатации.

Мы помогаем бизнесу
быть эффективным!