Опубликован: 12.11.2012 | Доступ: платный | Студентов: 17 / 0 | Длительность: 18:29:00
Лекция 7:

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

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >
Аннотация: В лекции описаны процессы домена "Приобретение и внедрение", отвечающие за выбор автоматизированных решений, программных приложений и подготовку обучающих материалов и инструкций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 7.1.
Источник Входящая информация
PO 1 Стратегия и тактические планы ИТ
PO 3 Регулярные обновления состояния технологий, технологические стандарты
PO 8 Стандарты в области приобретения и разработки
PO 10 Рекомендации по управлению проектами и детальные планы проектов
AI 6 Описание процесса управления изменениями
DS 1 Соглашения об уровне сервисов
DS 3 Требования плана по эффективности и объему

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

Таблица 7.2.
Результаты В процессы
Обоснование бизнес-требований (ТЭО) PO 2 PO 5 PO 7 AI 2 AI 3 AI 4 AI 5

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

Таблица 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 на основании отчета примет решение – покупать (и что конкретно покупать) или разрабатывать.

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >
Грета Березовская
Грета Березовская
Александр Медов
Александр Медов

Здравствуйте, прошел курс МБА Управление ИТ-проектами и направил документы на получение диплома почтой. Подскажите, сроки получения оного в бумажной форме?

: