Управление ИТ на основе COBIT 4.1

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

Показывать лекцию целиком

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    7.2. Приобретение и поддержка программных приложений

    Приведем определение программного приложения из COBIT. Программное приложение (Application program) – компьютерная программа, осуществляющая обработку бизнес-данных, в частности, ввод данных, обновление и запрос. Бизнес-приложение отличается от системных программ (таких как операционная система или программа контроля сети) и от сервисных программ (таких как копирование и сортировка данных)[1] .Разработка и приобретение программных приложений требуют формирования требований к контролю и безопасности, а также обеспечение их соответствия существующим стандартам и требованиям бизнеса. Первостепенными для данного процесса являются результативность и эффективность информации, вторичными – целостность и достоверность. Процесс работает с приложениями в ключевых областях управления ИТ Соответствие стратегии и Полезность. Первостепенное значение имеет результативность и эффективность информации (рис.7.2).

    (рис 7.2) Процесс "Приобретение и поддержка программных приложений"

    Приобретение и поддержка программных приложений

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

    обеспечение соответствия доступных приложений требованиям бизнеса при условиях своевременности и разумных затрат.

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

    своевременном и эффективном с точки зрения затрат процессе разработки

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

  • преобразования требований бизнеса в спецификации разработки;
  • соблюдения стандартов разработки для всех модификаций;
  • разделения работ по разработке, тестированию и сопровождению.
    •

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

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

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

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

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

    РезультатыВ процессы
    Спецификации мер контроля безопасности приложенийDS 5
    Знания в области приложений и программных пакетовAI 4
    Решения по закупкамAI 5
    Первоначально запланированные соглашения об уровне сервисаDS 1
    Спецификация по доступности, непрерывности и восстановлениюDS 3DS 4

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

    Действия\ФункцииПрезидентФинансовый директорВысшее руководствоДиректор по ИТВладелец бизнес-процессаРуководитель эксплуатации системыГлавный архитектор ИТ-системыРуководитель разработокРуководитель администрации ИТРуководитель проектного офисаАудит, риски, безопасность
    Преобразовать бизнес-требования в спецификации общего дизайна приложенийККУ/ООК
    Подготовить детальный дизайн приложений и технические требованияИКККУ/ООК
    Определить меры контроля в рамках дизайна приложений ОКУ/ООО
    Настроить и внедрить функциональности ККУ/ООК
    Разработать формализованную методологию и процессы управления разработкой приложенийКККУКОК
    Подготовить план обеспечения качества программного обеспеченияИКОУ/ОК
    Управлять требованиями к приложениям и отслеживать ихОУ/О
    Подготовить план поддержки программных приложенийККУ/ОК
    ЦелиПоказатели
    ИТ:
  • определить, как корпоративные, функциональные и контрольные требования были преобразованы в эффективные автоматизированные решения
  • приобретать и поддерживать интегрированные и стандартизированные программные приложения
    		•
  • доля проектов, обеспечивающих изменения бизнеса в требуемые сроки
  • число проектов, в которых не были достигнуты заявленные выгоды по причине плохого дизайна или разработки
    • Процесса:
  • приобретать и поддерживать приложения, которые соответствуют определенным бизнес-требованиям и эффективны с точки зрения затрат
  • приобретать и поддерживать приложения, которые соответствуют стратегии и архитектуре ИТ
  • обеспечить сроки и эффективность процесса разработки с точки зрения затрат
    		•
  • доля проектов по разработке, соответствующих сроку и бюджету
  • доля мероприятий, направленных на поддержку существующих приложений
  • число проблем в расчете на приложение, приводящих к ощутимым простоям
  • число зафиксированных дефектов в месяц
    • Действия:
  • преобразование требований бизнеса в спецификации разработки
  • соблюдение стандартов разработки
  • управление приоритетами требований в соответствии с актуальностью для бизнеса
  • разделение работ по разработке, тестированию и сопровождению
  • управление инвестициями в существующую технологию
    		•
  • доля проектов программных приложений с разработанным и реализованным планом качества
  • доля проектов программных приложений, по которым проводился анализ и утверждение соответствия стандартам разработки
  • среднее время обеспечения функциональности, на основе таких измерений как функциональные возможности или строки кода
  • оценка усилий по программированию, направленных на обеспечение функциональности, основанная на таких измерениях как функциональные возможности или строки кода

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

  • AI 2.1. Общий дизайн приложений

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

  • AI 2.2. Детальный дизайн приложений

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

  • AI 2.3. Меры контроля приложений и проверяемость

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

  • AI 2.4. Безопасность приложений и доступность

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

  • AI 2.5. Конфигурирование и внедрение приобретенного программного обеспечения

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

  • AI 2.6. Значительные обновления существующих систем

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

  • AI 2.7. Разработка программных приложений

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

  • AI 2.8. Обеспечение качества приложений

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

  • AI 2.9. Управление требованиями к приложениям

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

  • AI 2.10. Поддержка приложений

    Разработать стратегию и план поддержки приложений

    •

    Рассмотрим процесс на примере издательства из предыдущего пункта. Допустим, CEO решил, что издательство не будет покупать систему на стороне, а создаст ее силами собственных программистов. Прежде чем они начнут создавать код, архитектор (или руководитель проекта) должен определить высокоуровневые аспекты дизайна, которые впоследствии очень трудно изменить (и даже невозможно):

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

    При этом архитектор должен обратиться к процессу "Определение направления технологического развития" для того, чтобы выяснить, какие технологические стандарты используются в организации. Если принято использовать C, то он не должен использовать Java в этом проекте. После определения всех технологических требований и функционала программисты начинают создавать код. Необходимо предусмотреть контроль качества. Для этого CIO должен:

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

    Это процедуры оценки всей системы. Хорошо было бы предусмотреть проверку качества отдельных компонентов системы и их взаимосвязей. Для этого необходимо:

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

    Основная идея в том, что для того, чтобы вся система была качественной, ее отдельные компоненты также должны быть качественными.

    Будут ли инвесторы довольны, если их первоначальные требования будут выполнены? Нет. Они будут довольны, когда увидят реальную прибыль от проекта или решение какой-то проблемы. Поэтому при проектировании системы необходимо всегда за технологическими требованиями видеть требования бизнеса. Например:

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

    Что делать, если инвестор изменит свою идею, увидев систему на практике? Что если он захочет изменить или добавить требования к системе? Если Вы будете реализовывать эти пожелания, то, скорее всего, не уложитесь в заданный бюджет и временной интервал.

    Чтобы решить эту проблему, CIO необходимо:

  • убедиться, что менеджер проектов правильно определил "добавленную" стоимость и время. Если требование заменяет другое требования или не требует значимых трудовых затрат, оно может не учитываться;
  • донести до инвестора (или другого лица, принимающего решение) о дополнительных временных и стоимостных затратах. Инвестор должен принять окончательное решение о необходимости выполнения изменения.
    •

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

    Когда пользователи начнут работать с системой, появятся пожелания о доработках - мелких (увеличить кнопку "login") и крупных (поддержка e-book). Вы, как CIO, должны будете взаимодействовать с инвесторами, чтобы определить необходимость доработок и расставить приоритеты.

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

    7.3. AI 3. Приобретение и обслуживание технологической инфраструктуры

    Организации имеют процессы, предназначенные для приобретения, внедрения и обновления технологической инфраструктуры. Данные процессы требуют планового подхода к приобретению, поддержке и защите инфраструктуры в соответствии с заранее согласованными технологическими стратегиями, обеспечением среды разработки и тестирования. В таком случае можно говорить о постоянной технологической поддержке корпоративных приложений (рис.7.3).

    (рис 7.3) Процесс "Приобретение и обслуживание технологической инфраструктуры"

    Приобретение и обслуживание технологической инфраструктуры.

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

    приобретение и поддержка интегрированной и стандартизованной ИТ -инфраструктуры.

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

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

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

  • Создания плана приобретения технологий в соответствии с технологическим планом инфраструктуры.
  • Планирования поддержки инфраструктуры.
  • Внедрения мер внутреннего контроля, безопасности и проверяемых показателей.
    •

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

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

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

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

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

    РезультатыВ процессы
    Решения по закупкамAI 5
    Конфигурированная система, которая должна быть протестирована и установленаAI 7
    Требования к физической средеDS 12
    Обновления технологических стандартовPO 3
    Требования системного мониторингаDS 3
    Знания в области инфраструктурыAI 4
    Первоначально запланированные соглашения об уровне операционной поддержкиDS 1

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

    Действия\ФункцииПрезидентФинансовый директорВысшее руководствоДиректор по ИТВладелец бизнес-процессаРуководитель эксплуатации системыГлавный архитектор ИТ-системыРуководитель разработокРуководитель администрации ИТРуководитель проектного офисаАудит, риски, безопасность
    Определить процедуру/процесс приобретенияКУКККОИ
    Обсудить инфраструктурные требования с утвержденными поставщикамиК/ИУИОККОИ
    Определить стратегию и план поддержки инфраструктурыУОООК
    Конфигурировать компоненты инфраструктурыУОКИ
    ЦелиПоказатели
    ИТ:
  • приобретать и поддерживать интегрированную и стандартизированную инфраструктуру
  • оптимизировать инфраструктуру, ресурсы и возможности
  • обеспечить гибкость ИТ
    		•
  • число критичных бизнес-процессов, обслуживаемых устаревшей или устаревающей инфраструктурой
    • Процесса:
  • обеспечить подходящие платформы для корпоративных приложений в соответствии с определенной ИТ-архитектурой и технологическими стандартами
  • обеспечить надежную и безопасную ИТ-инфраструктуру
    		•
  • доля платформ, не соответствующих утвержденной ИТ-архитектуре и технологическим стандартам
  • число различных технологических платформ в организации в расчете на функцию
  • доля компонентов инфраструктуры, приобретенных не в соответствии с процессом приобретения
  • число компонентов инфраструктуры, которые не подлежат поддержке или не будут поддерживаться в скором времени
    • Действия:
  • создание плана приобретения технологий в соответствии с технологическим планом инфраструктуры
  • планирование поддержки инфраструктуры
  • обеспечение инфраструктуры среды разработки и тестирования
  • внедрение мер внутреннего контроля, безопасности и проверяемых показателей
    		•
  • число и тип аварийных изменений в компонентах инфраструктуры
  • число нереализованных заявок на приобретение
  • среднее время конфигурирования компонентов инфраструктуры

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

  • AI 3.1. План приобретения технологической инфраструктуры

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

  • AI 3.2. Защита и доступность ресурсов инфраструктуры

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

  • AI 3.3. Обслуживание инфраструктуры

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

  • AI 3.4. Тестовая среда

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

    •

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

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

    Если говорить о безопасности технологической инфраструктуры, то основной мерой является своевременная установка патчей (обновлений) операционных систем и других приложений. Необходимо предусмотреть некоторый процесс контроля за их своевременной установкой:

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

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

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

    7.4. AI 4. Обеспечение выполнения операций

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

    (рис 7.4) Процесс "Обеспечение выполнения операций"

    Обеспечение выполнения операций.

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

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

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

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

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

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

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

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

    ИсточникВходящая информация
    PO 10Рекомендации по управлению проектами и детальные планы проектов
    AI 1ТЭО
    AI 2Знания в области приложений и пакетов программного обеспечения
    AI 3Знания в области инфраструктуры
    AI 7Известные и подтвержденные ошибки
    DS 7Запрошенные обновления документации

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

    РезультатыВ процессы
    Руководства для пользователей, системных администраторов, руководства службы технической поддержкиAI 7DS 4DS 8DS 9DS 11DS 13
    Требования по передаче знаний для внедрения решенийDS 7
    Учебные материалыDS 7

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

    Действия\ФункцииПрезидентФинансовый директорВысшее руководствоДиректор по ИТВладелец бизнес-процессаРуководитель эксплуатации системыГлавный архитектор ИТ-системыРуководитель разработокРуководитель администрации ИТРуководитель проектного офисаАудит, риски, безопасность
    Разрабатывать стратегию эксплуатации решенияУУООИОК
    Разрабатывать методологию передачи данныхКУКО
    Разрабатывать руководства по процедурам для конечных пользователейУ/ООКК
    Разрабатывать техническую документацию по эксплуатации и поддержкеУ/ОКК
    Разрабатывать и проводить обучениеУУОО
    Оценивать результаты обучения и при необходимости обновлять документациюУУОО
    ЦелиПоказатели
    ИТ:
  • обеспечить правильное использование и эффективность приложений и технологических решений
  • обеспечить удовлетворенность конечных пользователей предложением услуг и уровнем сервиса
  • обеспечить гармоничную интеграцию приложений и бизнес-процессов
  • сократить уровень сбоев и переделок в решениях и услугах
    		•
  • число приложений, в которых ИТ-процедуры гармонично интегрированы с бизнес-процессами
  • доля владельцев бизнес-процессов, удовлетворенных обучением и соответствующими материалами
    • Процесса:
  • обеспечить эффективные пользовательские и операционные руководства и обучающие материалы по приложениям и техническим решениям
  • передавать знания, необходимые для успешной работы систем
    		•
  • число инцидентов, вызванных недостаточной пользовательской и операционной документацией и обучением
  • число запросов на обучение, удовлетворяемых службой поддержки
  • уровень удовлетворенности обучением и документацией, относящимися к пользовательским и операционным процедурам
  • уменьшение стоимости разработки и поддержки пользовательской и операционной документации, операционных процедур и материалов для обучения
    • Действия:
  • разработка и распространение документации, способствующей передаче знаний
  • информирование и обучение пользователей, корпоративного руководства, обслуживающего и операционного персонала
  • разработка обучающих материалов
    		•
  • уровень посещаемости занятий по обучению пользователей и операторов по каждому приложению
  • временная задержка между изменениями и обновлениями в программах обучения, процедурах и документации
  • доступность, полнота, точность пользовательской и операционной документации
  • число приложений, подкрепленных адекватным обучением пользователей и обслуживающего персонала

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

    AI 4.1. Планирование для операционных решений

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

    AI 4.2. Передача знаний бизнес-менеджерам

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

    AI 4.3. Передача знаний конечным пользователям

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

    AI 4.4. Передача знаний операционному и обслуживающему персоналу

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

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

    Для начала нужно определиться, кто будет с ней работать. Например:

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

    • После определения групп, которые будут работать с системой, Вам надо как-то передать им знания. При этом знания для каждой из групп будут разными. Знания можно передать с помощью составления документации (руководств пользователей, администраторов и т.п.), базы знаний, FAQ, и, собственно, обучения.

    Ключевые термины

    Программное приложение (Application program) – компьютерная программа, осуществляющая обработку бизнес-данных, в частности, ввод данных, обновление и запрос. Бизнес-приложение отличается от системных программ (таких как операционная система или программа контроля сети) и от сервисных программ (таких как копирование и сортировка данных).

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^