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

Вне зависимости от выбранного типа решения программный продукт по управлению рисками в ИТ-проекте должен отвечать сформулированным требованиям и выполнять основные задачи управления рисками за счет:

• функций системного автоматизированного подхода в области управления рисками ИТ-проекта;

• механизмов анализа рисков с применением современных статистико-математических методов;

• функций контроля выполнения мероприятий по минимизации рисков и расчету экономического эффекта;

• механизмов автоматического мониторинга эффективности системы управления рисками;

• реализации сводной аналитической отчетности по управлению рисками в режиме реального времени.

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

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

При выборе следует обратить внимание на три фактора: сроки внедрения, качество внедрения, стоимость внедрения.

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

Часть функций можно передать сторонним разработчикам и выполнить заказную разработку решения по управлению рисками (табл. 10).

Таблица 10.

Критерии выбора заказного/готового программного продукта

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

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

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

При принятии решения об использовании пакетного (готового) решения в области управления рисками программных проектов также существуют существенные ограничения. Это и необходимость придерживаться шаблонных процессов, и сложность интеграции с существующими приложениями в случае нестандартной базовой ИТ. Также возможны трудности с самостоятельным выбором подходящего поставщика и формированием объективных критериев. Существует возможность избыточной функциональности и неудобства программного интерфейса. Очень часто необходимо выполнять пользовательские настройки и решать проблемы локализации (для западных продуктов).