Планирование и организация

PO1. Разработка стратегического плана развития ИТ

PO2 Определение ИТ архитектуры

PO3 Определение направлений развития технологий

PO4 Формализация ИТ процессов, организации и взаимоотношений с бизнесом

PO5 Управление инвестициями в ИТ

PO6 Согласованное управление целями и задачами

PO7 Управление ИТ персоналом

PO8 Управление качеством

PO9 Оценка и управление рисками ИТ

PO10 Управление проектами

Приобретение и внедрение

AI 1. Выбор решений по автоматизации

Организации постоянно требуется новый функционал или приложения. При этом встает вопрос: разрабатывать самим или приобрести на стороне? За ответ на этот вопрос и отвечает первый процесс домена "Приобретение и внедрение" – Выбор решений по автоматизации. Он также отвечает за выбор конкретного решения среди альтернатив путем анализа требований бизнеса, технологического и экономического обоснования, анализа рисков, затрат и преимуществ. Этот процесс позволяет организации минимизировать затраты на приобретение и внедрение решений по автоматизации и гарантирует их одновременное соответствие требованиям бизнеса (рис.AI1.1). Первостепенными областями Управления ИТ являются Соответствие стратегии и Полезность. Процесс работает с приложениями и инфраструктурой, а основным требованием к информации является ее результативность.

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

Рисунок AI1.1 - Процесс "Выбор решений по автоматизации"

Выбор решений по автоматизации удовлетворяет следующим требованиям к ИТ:

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

• сосредоточено на определении технически обоснованных и эффективных с точки зрения затрат решений.

• достигается с помощью:

• определения технических и бизнес требований;

• проведения исследования обоснованности в соответствии со стандартами разработки;

• утверждения (или отмены) требований и результатов технико-экономического обоснования.

• результаты оцениваются с помощью следующих показателей:

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

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

• доля пользователей, удовлетворенных реализованной функциональностью.

На рисунке AI1.2 представлена информация, необходимая для процесса и ее источники.

Рисунок AI1.2 – Входящая информация для процесса

На рисунке AI1.3 приведены результаты процесса и то, куда они должны поступить.

Рисунок AI1.3 – Выходящая информация для процесса

Рисунок AI1.4 содержит таблицу ОУКИ для процесса.

Рисунок AI1.4 - Таблицу ОУКИ для процесса.

В таблице AI1.1 описаны цели и показатели процесса.

Таблица AI1.1 – цели и показатели

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

Цели контроля:

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

• AI 1.2. Результаты анализа рисков. Требуется выявить, документировать и проанализировать риски, связанные с реализацией бизнес-требований и разработкой решений в рамках общекорпоративного процесса разработки требований.

• AI 1.3. Исследование обоснованности и разработка альтернативного плана действий. Все требования должны быть исследованы на обоснованность, то есть на возможность и необходимость их реализации.

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

Ключевым термином процесса является технико-экономическое обоснование (ТЭО). ТЭО является документом, содержащим обоснование целесообразности создания продукта или услуги на основе анализа затрат, выгод и рисков. ТЭО может использовать различные способы для оценки. Самым простым и традиционным способом является расчет Величины возврата от инвестиций (Return-on-investment, ROI). Но следует понимать, что далеко не все инвестиционные проекты связаны с непосредственной выгодой для бизнеса, то есть с конкретным доходом. Поэтому более правильным является учет стратегического влияния результатов отдельных ИТ-проектов на дальнейшее развитие информационных систем и бизнеса организации в целом. Соответствующим показателями будут в данном случае являться рентабельность активов (ROA) и оценка возможностей или опций для бизнеса. Так как многие инвестиции в ИТ являются долгосрочными, то использование такого показателя как ROA, позволяет более корректно учитывать увеличение капитализации компании. Другим примером может служить вероятностный метод, связанный с учетом возможных эффектов от данного проекта. Выбор метода в конкретном случае зависит от целого комплекса факторов, включая масштабы и сроки инвестиций, сложность портфеля проектов, сроки и характер инвестиций, необходимая точность оценки.

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

На практике технические требования сложны и детализованы. После "разбиения" на мелкие кусочки можно посчитать финансовые и временные затраты. Необходимо также учесть, что всегда есть непредвиденные обстоятельства – риски, которые могут сделать требование бизнеса или весь проект невыполнимыми. Например, Вы купили платформу у стороннего поставщика и хотите, чтобы информация о продажах поступала в систему от Отдела продаж. Но у вендора нет такого функционала, а кастомизировать систему на таком уровне невозможно или очень сложно. Как же справиться с риском? Риск нужно либо уменьшить его вероятность, либо уменьшить его негативное влияние, то есть ущерб. Но в описанном выше примере либо у вендора есть функционал по загрузке данных о продажах в систему (0% риска), либо его нет (100%) риска. Если Вы внимательно подойдете к рассмотрению альтернатив, то будете знать заранее и выберете решения, у которых этот функционал есть. Вы составите подробный отчет с несколькими выбранными альтернативами, затратами, рисками, преимуществами и требованиями. Отвественный на основании отчета примет решение – покупать или разрабатывать.