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

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

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

Рис. 7.1. Процесс "Выбор решений по автоматизации"

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

удовлетворяет следующим требованиям к ИТ:

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

сосредоточено на:

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

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

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

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

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

В таблице 7.1 представлена информация, необходимая для процесса и ее источники.

В таблице 7.2 приведены результаты процесса и то, куда они должны поступить.

Таблица 7.3 содержит таблицу ОУКИ для процесса, а таблица 7.4 – цели и показатели.

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

• AI 1.1. Определение и поддержка бизнес-требований к функциональности

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

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

  Все требования должны быть исследованы на обоснованность, то есть на возможность и необходимость их реализации.
• AI 1.4. Требования, обоснование и утверждение

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

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

Рассмотрим процесс на примере, встречавшемся ранее. Допустим ВЫ – CIO в крупном издательстве. Для выхода на новый рынок CEO решил сделать платформу, где авторы смогли бы публиковать свои работы самостоятельно. Он(CEO) выдвинул такие требования:

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

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

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

Для требования "система должны быть безопасной" можно сделать следующее:

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

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