ИТ-архитектура от А до Я: Теоретические основы. Первое издание - стр. 10
•Задачи менеджмента – минимальные инвестиции
•Место в организационной структуре компании – служба или отдел в составе бизнес департамента (администрация, финансы) или под курацией.
Становления или «оптимизация»
Компания строит сквозные бизнес процессы, используя общие данные и информационные системы. Централизует по возможности бизнес процессы и функции подразделений в централизованных информационных системах по предварительно описанных операционных моделях. Основные симптомы данного этапа развития:
•Роль ИТ департамента – важная
•Стратегия ИТ департамента – частично отвечает бизнес требованиям
•Бюджет ИТ департамента – существует и управляем
•Тип деятельности ИТ департамента – реактивная реакция на бизнес требования,
•Задачи менеджмента – получение бизнес выгоды в краткосрочной перспективе
•Место в организационной структуре компании – выделенный департамент, но ИТ менеджер не входит в состав совета директоров.
Зрелый
Повторное использование имеющихся бизнес процессов и компонентов для создания новых сервисов и возможностей. ИТ работает на опережение и является не отъемлющей частью бизнеса. Основные симптомы данного этапа развития:
•Роль ИТ департамента – стратегический ресурс организации
•Стратегия ИТ департамента – интегрированная в бизнес стратегию компании
•Бюджет ИТ департамента – существует и рассматривается как инвестиции в бизнес
•Тип деятельности ИТ департамента – активная реакция (превентивная) на бизнес требования
•Задачи менеджмента – долгосрочные инвестиции в бизнес
•Место в организационной структуре компании – департамент, ИТ директор в составе совета директоров
Каждый из этих этапов имеет плюсы и минусы. Этап развития ИТ должен соответствовать этапу развития компании. Опыт показывает, что перескочить хотя бы через один из этапов сложно и требуются колоссальные затраты ресурсов (времени, денег, энергии сотрудников и т. д.), при этом эффект будет обратный. Большинство компаний проходят их один за другим. Переход на следующую стадию переходит при осознании руководством компании или остроты возникших вопросов:
•Проблемы поддержки роста и изменений бизнеса
•Дублирование бизнес процессов
•Многообразие платформ и систем
•Неудовлетворенность текущем состоянием ИТ
Критерии выбора методологии
Так как методологии сильно отличаются друг от друга, то следует задать критерии для их сравнения.
• Полнота таксономии, определяет, насколько методология пригодна для классификации различных архитектурных артефактов. Полностью сосредоточена на фреймворке Захмана.
• Полнота процесса, определяет, насколько детально представлен процесс создания архитектуры предприятия.
• Руководство по эталонным моделям, определяет полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология FEA.
• Практическое руководство определяет, насколько методология позволяет воплотить в жизнь умозрительное представление об архитектуре предприятия и сформировать культуру, в которой эта архитектура будет использоваться. На этом практически полностью сосредоточена методология Gartner.
• Модель готовности определяет, насколько методология позволяет оценить эффективность использования архитектуры предприятия в различных подразделениях.
• Ориентированность на бизнес определяет, ориентирована ли методология на использование технологии для повышения ценности бизнеса, где ценность бизнеса определяется как снижение затрат или увеличение доходов.