Сергей Авдошин - Информатизация бизнеса. Управление рисками

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

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

Аккуратная отчетность по проекту – это звучит просто, но на деле оказывается немалой проблемой. Реальность такова, что отчеты о статусе ИТ-проектов чрезмерно оптимистичны. Главная проблема здесь в том, что приукрашенный отчет гораздо удобнее для всех отделов, так как дает чувство устойчивого прогресса. Однако большинство сложностей, с которыми сталкиваются ИТ-проекты, можно преодолеть различными управленческими решениями. По мере того как проблемы возникают, менеджмент будет искать способы уменьшить негативные последствия и устранить источник этих проблем, однако давление, которое развивается в эти моменты, чаще всего изменяет ход проекта.

Для обеспечения успеха проекта сформулируем критические факторы успеха (КФУ) ИТ-проекта, то есть факторы, реализация которых позволит выполнить ИТ-проект в срок, в рамках бюджета, с заданным качеством:

1) наличие четких целей внедрения;

2) обязательное участие высшего руководства заказчика в процессе разработки системы и ее внедрения;

3) все сотрудники должны четко осознавать необходимость внедрения ИТ, оказывать посильную помощь, обучаться работе с ИТ;

4) участие всех ключевых пользователей системы в формулировке требований, разработке, тестировании, внедрении системы;

5) управление качеством и введение системы изменения результативности на основе показателей эффективности;

6) управление рисками на всех этапах ЖЦ проекта и своевременная минимизация рисков;

7) формирование единого глоссария терминов в области управления ИТ-рисками и установление единого «языка» общения между ИТ и бизнесом.

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

Главными источниками ИТ-рисков считаются большой объем изменений, возрастающая сложность систем, а также бреши в системах безопасности, которыми пользуются хакеры, – говорится в отчете HP за 2008 год по результатам глобального исследования, в котором приняли участие 1125 ИТ-специалистов из 20 стран. Один из четырех респондентов констатировал, что 50 % вынужденных простоев обусловлены изменениями. Это значит, что для многих ИТ-организаций жизненно необходимы предсказуемость их деятельности и управление изменениями. Добиться успеха смогут лишь те компании, которые, реагируя на перемены, быстрее других приспосабливаются к новым условиям – бизнес-процессам, технологиям, стандартам качества, способам коммуникаций и прочему.

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

Управление изменениями позволяет рассматривать все запросы заинтересованных лиц и удовлетворять их максимально возможно, при условии своевременного выпуска качественного продукта. Как правило, в начале проекта изменения проходят достаточно безболезненно. Можно скорректировать практически все – инфраструктуру, платформу, архитектуру, набор функций, подрядчика, сроки, бюджет. К концу проекта такой свободы все меньше и меньше, стоимость внедрения изменений в проект, напротив, существенно увеличивается (рис. 8).

Рис. 8. Зависимость изменений от ЖЦ проекта

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

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