Шпаргалка по архитектуре организации. Теория АО. 1. Понятие и области применения архитектуры предприятия
 Скачать 3.38 Mb.
|
|
1. Понятие и области применения архитектуры предприятия. Архитектура предприятия – фундаментальная организация предприятия либо как целого, либо вместе с партнерами, поставщиками и\или покупателями («Расширенное предприятие»), либо части (например, бизнес-направление, департамент), а также руководящие принципы его проектирования и развития. Архитектура предприятия определяет общую структуру и функции систем (бизнес и ИТ) в рамках всей организации в целом (включая партнеров и другие организации, формирующие так называемое расширенное предприятие) и обеспечивает общую рамочную модель (framework), стандарты и руководства для архитектуры последующих уровней. Общее видение, обеспечиваемое АП, создает возможность единого проектирования систем, адекватных с точки зрения обеспечения потребностей организации и способных к взаимодействию и интеграции там, где это необходимо. Такой взгляд является наименее детальным, зато охватывает всю организацию и рассчитан на долгосрочное планирование. В настоящий момент архитектурный подход применяется различными компаниями по всему миру, в основном в крупных и средних фирмах. Архитектурный подход находит свое применение как среди компаний в разных рыночных сегментах, так и среди государственных или некоммерческих организаций. В работеД. В. Кудрявцева и М. Ю. Арзуманяна предложено шесть основных сценариев применения АП: — управление развитием организации; — обеспечение единого языка для коммуникаций и интеграции управленческих дисциплин; — выравнивание бизнеса и ИТ; — операционное совершенствование бизнеса и ИТ; — повышение капитализации и (или) обеспечение соответствия; — использование передовых практик или «бенчмаркинг»; — управление сложностью или снижение рисков. 2. Архитектурный подход как основа управления развитием информационных систем Концепция корпоративной архитектуры напоминает градостроительство в области ИТ – составление общего плана интеграции различных объектов в рамках всей организации, определение порядка их использования и путей построения необходимых для этого механизмов. Ее суть заключается в том, чтобы разработать план использования ИТ-ресурсов бизнес-процессами, а также совокупность принципов управления, позволяющих выразить стратегию бизнеса через ИТ. Непосредственно архитектура организации не описывает конкретные технические решения отдельных информационных систем, но позволяет получить существенную выгоду для бизнеса организации в целом. Основные аспекты связаны с повышением эффективности эксплуатации информационных систем, снижением рисков инвестиций в ИТ, а также с повышением гибкости или возможности относительно простой адаптации под изменяющиеся внешние условия и требования бизнеса. Наличие в организации разработанной архитектуры обеспечивает: поддержку принятия решений и управление в условиях сложных бизнес-процессов и информационных технологий; план развития и изменений; основу для назначения приоритетов при формировании ИТ-бюджетов; основу для управления портфелем ИТ- проектов; соответствие принятым корпоративным стандартам; поддержку разработки новых систем. Архитектура является средством снижения рисков и увеличения отдачи от инвестиций в ИТ. Причина в том, что она четко определяет структуру как существующих, так и будущих ИТ-систем, что приводит к снижению их сложности. А наличие ясной стратегии будущих закупок, выбора поставщиков технологий и планируемых изменений позволяет упростить и ускорить все процессы, связанные с закупками, при одновременном обеспечении совместимости и взаимодействия компонент ИТ-систем организации. 3. Модель Д. Захмана Матрица Захмана представляет собой таксономию, позволяющую связать различные модели, предоставляемые заинтересованным сторонам. Основная идея схемы Захмана заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта предприятия в координации с остальными. Метод преследует две основные цели: с одной стороны, логически разбить все описание архитектуры на отдельные разделы, с другой — обеспечить возможность рассмотрения целостной архитектуры на нескольких уровнях абстракции. Для этого применяется матрица 6 х 6, в которой каждая ячейка задает свой тип описания (моделей) свойств предприятия.  По Захману, модель предприятия, на основе его схемы должна быть:  Правила заполнения модели Захмана: порядок следования колонок несущественен; каждая колонка имеет в основе простую, базовую модель; базовые модели для каждой из колонок являются уникальными; каждая клетка уникальна и содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа); каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы («базис»); совокупность клеток одного ряда формирует полное описание системы с соответствующей точки зрения (перспективы); заполнение клеток должно проводиться последовательно «сверху вниз».  4. Методология TOGAF. Общая характеристика The Open Group Architecture Framework (TOGAF) — методология/библиотечный метод описания/подход (framework) для описания архитектуры предприятия, который предлагает подход для проектирования, планирования, внедрения IT-архитектуры предприятия и управления ей. TOGAF - высокоуровневый подход к проектированию. В соответствии с TOGAF архитектуру предприятия можно представить в виде четырёх основных доменов: Бизнес архитектура (Business) — определяет стратегию предприятия, структуру управления и ключевые бизнес-процессы. Архитектура данных (Data) — описывает логическую и физическую структуру данных организации, а также структуру корпоративных ресурсов для управления данными. Архитектура приложений (Application) — служит своеобразной картой всех используемых корпоративных приложений и определяет следующие аспекты: участие каждого из приложений в бизнес-процессах компании; взаимодействие приложений друг с другом и внешними сервисами. Технологическая архитектура (Technology) — определяет структуру и логику программного обеспечения и аппаратной среды, необходимых для работы бизнес-приложений и доступа к нужным данным. Этот уровень включает всю поддерживающую инфраструктуру: сети, сервера, процессинг и т.п. Основные принципы: модульность стандартизованность повторное использование зарекомендовавших себя существующих продуктов и технологий В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами. Основные термины в стандарте TOGAF взяты из стандарта ISO 42010. Архитектура — фундаментальная организация системы, состоящая из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы. TOGAF рассматривает предприятие как систему. В состав модели TOGAF входят две основные компоненты: Метод разработки архитектуры (ADM, Architecture Development Method), определяющий процесс разработки архитектуры; Базовая Архитектура (Foundation Architecture) 5. Заинтересованные стороны. Ракурсы, представления, потребности в артефактах Заинтересованная сторона – лицо, группа лиц или организация, которые имеют определенные интересы относительно изменений в бизнесе. Заинтересованные стороны выражают цели организации и реализуют их; формулируют требования для реализации целей организации. Заинтересованные стороны управляют объектами и используют для этого артефакты. Примеры: руководство организации, акционеры, архитектор предприятия. Ракурс — это своеобразная точка зрения, с которой заинтересованная сторона смотрит на организацию, на ее часть или на сам процесс трансформации. Например, руководителя ИТ-отдела и на организацию, и на ее трансформацию смотрит с точки зрения информационных технологий. Его точка зрения охватывает информационные системы организации, данные, информацию, приложения и их разработку, технологическую инфраструктуру и т. п. В зависимости от компании и ее специфики могут использоваться различные ракурсы, например: — верхнеуровневый ракурс; — ракурс организационной структуры; — ракурс бизнес-процессов; — ракурс использования приложений; — ракурс поведения приложений; — ракурс структуры приложений; — ракурс инфраструктуры; Представление — это конкретное выражение ракурса, которое доступно заинтересованной стороне. Приведенный ранее в качестве примера ракурс структуры приложения может быть представлен различными диаграммами, созданными на этапе проектирования. Выстраивается следующая цепочка: руководитель ИТ-отдела заинтересован в понимании структуры приложения; он смотрит на некоторую часть компании — к примеру, на отдел разработки — с точки зрения структуры приложений; в результате он получает представление о его структуре в виде соответствующих диаграмм. Артефакт – не синоним к слову «архитектурный документ» в его формальном понимании. Артефакт описывает определенный аспект целостной архитектуры и необходим прежде всего заинтересованным сторонам для принятия решений относительно текущей или целевой архитектуры. Выделяют три вида артефактов: реестры, матрицы (например, матрица целей/процессы) и диаграммы (стратегическая карта). Каждая заинтересованная сторона, исходя из ракурса и представления, имеет потребность в артефактах. К примеру, руководитель ИТ-отдела может использовать артефакт под названием «Реестр ИС» для управления приложением, в котором содержится информация обо всех приложениях организации. На основе этого артефакта заинтересованная сторона может принять решения о разработке новой ИС, выводе старой ИС из эксплуатации, модернизации ИС и т. д. Однако для принятия решения могут потребоваться (и обычно требуются) и другие артефакты. 6. Язык моделирования архитектуры предприятия ArchiMate ArchiMate — это открытый и независимый язык моделирования архитектуры предприятия, поддерживающий описание, анализ и визуализацию архитектуры внутри и через основные бизнес-домены. Сейчас язык ArchiMate активно применяется консалтинговыми компаниями. Он полностью согласован с моделью архитектуры предприятия TOGAF. В ArchiMate выделяют три слоя архитектуры, которые условно соотносятся с доменами архитектуры предприятия по TOGAF: бизнес-слой, слой приложения и технологический слой. Бизнес-слой (Business layer) — все то, что не относится к информационным технологиям. Уровень описывает продукты и сервисы для внешних клиентов, процессы реализации этих продуктов и сервисов, а также организационную модель. Слой приложений (Application layer) — описывает поддержку бизнес-уровня ИТ-приложениями и основные виды данных. Технологический слой (Technology layer) — описывает технологическую инфраструктуру, включающую аппаратное обеспечение, общесистемное программное обеспечение, необходимое для ИТ-приложений. Например, системы хранения данных, каналы связи, ЦОДы, сервера и т. д. Каждый уровень описания, в дополнение, описывается с учетом трех аспектов: — пассивные структурные элементы (Passive structure); — элементы поведения (Behavior); — активные структурные элементы (Active structure). 7. Характеристика основных методов и моделей разработки архитектуры предприятия Элементы архитектуры предприятия: 
8. Методология BSC Д. Нортона и Р. Каплана Система сбалансированных показателей, ССП — это один из ключевых инструментов менеджмента, который позволяет отслеживать достижение целей в рамках реализации стратегии компании. По сути, ССП - это механизм взаимосвязи стратегических замыслов и решений с ежедневными задачами, способ направить деятельность всей компании (или группы) на их достижение.  9. Метамодель архитектуры предприятия. Метамодель организации - общее и всестороннее представление ее как единой системы, имеющей краткосрочные и долгосрочные цели ведения деятельности, миссию и стратегию, обладающая внешним и внутренним ресурсом, необходимым для выполнения миссии и стратегии, а также способная реализовать бизнес-процесс и бизнес-функции. Построение метамодели организации означает определение ее архитектуры и инфраструктуры. Архитектура организации – некоторая концепция (логически построенная) определенная, что и как она делает (миссия, цели, стратегия, основные функции), на какие части она распадается (свойства элементов), где они размещаются и как эти части и на каких принципах взаимодействуют (взаимосвязь компонентов). Для построения архитектуры организации необходимо определить инфраструктуру организации –комплекс взаимосвязанных обслуживающих структур, составляющие и (или) обеспечивающие основу для решения некоторых задач. Объекты архитектуры предприятия могут варьироваться в разных организациях, но существуют наиболее типичные и распространенные объекты. Они группируются при помощи метамодели, которая отражает основные объекты, наиболее значимые связи и позволяет произвести классификацию по слоям и аспектам. Содержание уровней архитектуры: Бизнес-архитектура -Вся деятельность предприятия, используется для помощи в приоритезации и трансляции стратегии предприятия Архитектуры ИС: Архитектура данных - Информационная модель с базами и хранилищами данных и потоками информации + Архитектура приложений - Все приложения и программы компании, Области применения приложений, Взаимодействие приложений Технологическая архитектура - Вычислительная инфраструктура, сетевая инфраструктура, инженерная инфраструктура предприятия В рамках метамодели определяются основные объекты, из которых в дальнейшем будут создаваться модели текущего и целевого состояния АП. Выбор объектов для метамодели должен соответствовать контексту формирования архитектурной практики, а также уровню зрелости управления в целом и АП в частности.  10. Канва бизнес-модели по А.Остервальдеру Бизнес-модель Остервальдера (Business Model Canvas) — инструмент стратегического управления, используемый для описания бизнес-моделей новых или уже работающих предприятий. Представляет собой схему из 9 блоков, описывающих разные бизнес-процессы организации. Модель полезна для построения бизнес-модели на любом этапе существования бизнеса: она помогает определить дальнейший вектор развития. Работающие фирмы используют модель для поиска новых точек роста, анализа конкурентов и определения лучших практик развития бизнеса, однако это полезно и для стартапа на стадии визуализации для поиска уязвимостей и анализа рисков, а также определения четкой структуры бизнеса. Инструмент пользуется популярностью из-за простоты. Обобщенная информация дает понять, где есть проблемы, с чем работать не стоит, а что, наоборот, можно улучшить. Модель состоит из 9 блоков: Потребительские сегменты (Общий круг потребителей делится на сегменты в зависимости от того, каким образом продукция или услуги организации удовлетворяют конкретную потребность в этом сегменте) Ценностные предложения (Ценностное предложение организации — это сочетание продуктов и услуг, которые она предоставляет своим клиентам. Эти предложения должны быть уникальными и легко отличаться от конкурентов) Каналы сбыта (Среда, через которую организация предоставляет свое ценностное предложение своему клиентскому сегменту) Отношения с клиентами (Организация должна выбрать вид отношений, которые она будет поддерживать со своим клиентским сегментом, чтобы добиться финансового успеха и устойчивости) Потоки доходов (Поток доходов — это методология, которой компания следует, чтобы побудить свои сегменты клиентов покупать ее продукт или услугу) Ключевые ресурсы (Это активы организации, лежащие в основе того, как она приносит пользу своим клиентам) Ключевые виды деятельности (Действия, которые являются ключевыми для создания ценностного предложения компании) Ключевые партнеры (Ключевые партнерские отношения — это сеть поставщиков и партнеров, которые дополняют друг друга, помогая компании создавать свои ценностные предложения) Структура издержек (определяет стоимость ведения бизнеса в соответствии с конкретной моделью) 11. Метамодель и общая характеристика бизнес-архитектуры предприятия  Каждый слой описывает различные области архитектуры предприятия. Бизнес-архитектура Вся деятельность предприятия, Используется для помощи в приоритезации итрансляции стратегии предприятия. Технологическая архитектура - Вычислительная инфраструктура, сетевая инфраструктура, инженерная инфраструктура предприятия. Бизнес-слой в свою очередь описывает деятельность предприятия и его развитие. Объектами бизнес-архитектуры являются: цели; деятельность, структура, объект деятельности и остальные объекты, из которых они состоят. Метамодель также отражает всякие связи между объектами бизнес-архитектуры. Артефакты бизнес-архитектуры основаны на соответствующей метамодели и описывают некоторую область бизнес-архитектуры. Задача: детализировано описать часть бизнес-архитектуры средствами архитектора Результат применения: детализирует часть бизнес-архитектуры (модели могут быть как для текущего состояния, так и для целевого.  12. Общая характеристика ИТ-архитектуры предприятия IT архитектура– это концепция, которая определяет модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы предприятия (компьютеры, сервера, информационная безопасность, программное обеспечение). IT Архитектура предприятия определяет общую структуру и функции систем и подсистем в рамках всей организации в целом (включая, в том числе, партнеров) и обеспечивает общую модель руководства. Тем самым создается общее видение взаимодействия элементов предприятия для достижения общей цели. IT архитектура: • обеспечивает достижение бизнес-целей компании посредством использования нужного программного обеспечения; • включает совокупность программных и аппаратных средств компании, в том числе, базы данных и промежуточное программное обеспечение. Для моделирования архитектуры разработан специальный графический язык Archimate. 13. Общая характеристика метода разработки архитектуры по TOGAF (ADM) TOGAF – подход для разработки, планирования, внедрения и управления архитектурой предприятия и ее элементами. Architecture Development Method (ADM) – пошаговая инструкция для разработки архитектуры предприятия, содержащийся в TOGAF. В соответствии с методикой ADM архитектурный процесс можно разбить на девять фаз: Фаза подготовки, на которой модель уточняется под особенности компании, определяются принципы осуществления проекта; Фаза А, в ходе которой определяются границы проекта, разрабатывается общее представление архитектуры, утверждается план работ; Фаза В, на которой разрабатывается бизнес-архитектура предприятия; Фаза С – разрабатывается архитектура данных и архитектура приложений; Фаза D – разрабатывается технологическая архитектура; Фаза Е – проверяются возможности реализации разработанных решений; Фаза F – планируется переход к новой системе; Фаза G – формируется система управления преобразованиями; Фаза Н – осуществляется управление всеми изменениями архитектуры. В свою очередь, базовая архитектура состоит из: Набора общих служб и функций, которые объединены в эталонную модель; Набора элементарных элементов архитектуры, используемых в качестве «строительных блоков» при разработке решений; Базы данных стандартов. Архитектор на уровне предприятия выполняет следующие задачи: 1. Формализует выявленные проблемы и заявленные требования в ИТ со стороны компании; 2. Разрабатывает архитектурные представления, которые могут показать процесс решения конкретных задач и обеспечения реализации требований; 3. Определяет точки разногласия заинтересованных сторон и разрабатывает компромиссные предложения. 14. Анализ и идентификация фактической бизнес-архитектуры предприятия На этапе идентификации и анализа существующей архитектуры производится описание основных слоев АП: бизнес-слоя, слоя ИС и технологического слоя. От архитекторов требуется выявить основные объекты АП для каждого слоя, а затем отразить их в соответствующих артефактах (рис. 4.10).  Как правило, исчерпывающее описание каждого из сегментов компании не является обязательным. Более того, в ряде случаев на практике это и вовсе невозможно из-за сложности компании и огромных финансовых и временных расходов на такой проект. На рис. 4.11 отражено соответствие этапа анализа и идентификации существующей архитектуры с фазами, выделяемыми в TOGAF ADM.  Обратите внимание, что на рисунке хотя и показана линейная последовательность выполнения фаз, на практике дело может обстоять иначе. Часто архитектор повторно возвращается, к примеру, на фазу С (Архитектура ИС) после описания технологической архитектуры, чтобы внести некоторые правки и дополнения. Аналогично обстоит ситуация и со многими другими фазами ADM. При анализе и проектировании АП можно выделить два крайних подхода. Первый подход предполагает, что изначально описывается по каждому слою текущая и целевая АП. Второй подход идет другим путем: первой описывается текущая архитектура всех трех слоев, а затем — целевая. На практике данные подходы могут комбинироваться. 15. Анализ фактической архитектуры информационных систем предприятия Цели: Цели описания и разработки архитектуры ИС в целом соответствуют общим целям этапа анализа и разработки ядра архитектуры. Тем не менее важно понимать следующее: при создании артефактов слоя ИС может выясниться, что артефакты бизнес-слоя нуждаются в дополнениях или исправлениях. Итак, цели: • выбрать ракурсы и инструменты; • описать текущую архитектура ИС; • разработать целевую архитектуру ИС; • уточнить, как архитектура ИС поддерживает бизнес-архитектуру предприятия, и при необходимости доработать артефакты бизнес-слоя; • произвести анализ разрывов; • определить объекты слоя ИС, которые потенциально войдут в диаграмму перехода. Входы: Входами в данном случае являются все артефакты, созданные на этапе анализа мотивации, артефакты верхнеуровневого описания предприятия, а также все артефакты бизнес-слоя. Таким образом, входы содержат следующее. Реестры: — реестр требований; — мотивационные реестры; — реестры верхнеуровневых объектов; —реестры бизнес-слоя и др. Матрицы соответствия: — мотивационные матрицы соответствия; — матрицы соответствия бизнес-слоя и др. Диаграммы: — канва бизнес-модели; — диаграмма внешнего окружения предприятия; — мотивационная модель; — верхнеуровневые диаграммы; — диаграммы бизнес-слоя и др. Выходы. Выходы содержат все артефакты, которые создаются при описании и разработке слоя ИС. Чаще всего они собираются в единый документ, описывающий ядро АП. Обычно артефакты слоя ИС идут в этом документе после артефактов бизнес-слоя, но порядок может быть произвольным — он зависит от различных потребностей и обстоятельств. В качестве артефактов-выходов для описания/разработки слоя ИС могут фигурировать следующие. Реестры: — реестр информационных систем; — реестр информационных сервисов и др. Матрицы соответствия: — матрица соответствия ИС и местоположений и др. Диаграммы: — диаграмма состояния ландшафта ИС; — диаграммы проектирования ИС на языке UML и др. 16. Формирование целевой архитектуры предприятия Целевая архитектура описывает желаемое будущее состояние предприятия или «что должно быть сформулировано». Она является будущей моделью предприятия. Этап проектирования целевой архитектуры является наиболее сложным, поскольку требует не только знаний и навыков сбора и структурирования информации, но и способности создавать новое с учетом понимания принципов функционирования предприятий, существующих технологических возможностей, ограничений и т. п. На данном этапе формируются те артефакты, в которых отражаются изменения по отношению к существующей АП. Цели: выбрать ракурсы и инструменты; разработать целевую архитектуру предприятия на основе требований с учетом движущих сил и целей (бизнес, ИТ, технологии); провести анализ разрывов между текущим и целевым состоянием АП; определить объекты архитектуры, которые потенциально войдут в диаграмму перехода. Важным ориентиром на данном этапе будут являться требования к целевой архитектуре, сформированные на предыдущих этапах и задокументированные в реестре требований. Требования определяют критерии, которым должна соответствовать целевая архитектура. Реестр требований может обновляться и дополняться, в том числе и на этом этапе. Все прочие артефакты, созданные на предыдущих этапах, также поступают на вход. Преимуществами проработки целевых архитектурных моделей при реализации ИТ-решений в проектных организациях являются: 1.Повышение прозрачности концепций ИТ-решений. 2.Гибкость в выборе состава элементов программно-аппаратного комплекса ИТ-решения без привязки к конкретному производителю или поставщику. 3.Упрощение согласования ИТ-бюджета и запуска ИТ-проектов. 4.Рост ценности «Информации» и связанности бизнеса и ИТ. 17.Этап реализации и перехода архитектурного проекта Этап реализации определяет, как архитектура направляет и удерживает в заданных рамках реализацию проектов, контролирует их в процессе выполнения, отвечает за создание и подписание архитектурных контрактов. Конечным выходом являются решения, совместимые с архитектурой. Цели: 1) Отслеживать соответствие целевой архитектуре при выполнении проектов 2) Осуществлять соответствующие функции управления архитектурой для решений и любых запросов на изменение архитектуры, инициированных в ходе реализации. Ключевые виды деятельности: Обеспечить архитектурный надзор за реализацией Определить архитектурные ограничения для проектов реализации Управлять архитектурными контрактами Осуществлять контроль за выполнением работ на соответствие архитектуре Этап перехода направлен на детальное планирование миграции, т.е. на то, каким образом перейти от текущей к целевой архитектуре. Цели: 1) Сформировать проекты трансформации для выделенных пакетов работ, оценить затраты ресурсов и времени для каждого проекта 2) Приоритезировать проекты трансформации в соответствии с ценностью и затратами 3) Сформировать план реализации и перехода 4) Обеспечить архитектурное соответствие при реализации решения и переходе к эксплуатации Ключевые виды деятельности: Для пакетов работ и определённых проектов выполняется анализ затрат, выгод и оценка рисков. Проектируется текущее и целевое состояние каждого бизнес-процесса. Возможно проектирование ИС в диаграммах UML (строится определенный набор диаграмм): д. прецедентов, д. последовательности, д. кооперации, верхнеуровневая д. классов, д. состояний, детализированная д. классов) Завершается создание детального плана реализации и миграции. Важно отметить, что диаграмма перехода описывает переход статично. План реализации и перехода – динамично. Реализация и переход детализируются до уровня конкретных задач (в виде Плана реализации и перехода), который в явном виде содержит Пакеты работ и Поставляемый результат. 18.Методика проведения gap-анализа между текущим и целевым состоянием архитектуры предприятия. Gap-анализ является важным элементом для определения ключевых шагов и каких-либо изменений в направлении целевой архитектуры. На данном этапе осуществляется определение несоответствий между текущим и целевым состоянием, сбор и обобщение требований к компонентам модели бизнес-архитектуры и планирование мероприятий по переходу из текущего состояния в целевое. Gap-анализ предусматривает выполнение следующих шагов: 1) Обнаружение различий между существующей и целевой архитектурами 2) Формирование списка обнаруженных несоответствий с разделением на категории и определение состава требуемых изменений. Могут быть выделены следующие категории несоответствий: Структурные - несоответствия между существующим и целевым состоянием, связанные с вопросами инфраструктуры. Основное внимание здесь связано с архитектурными принципами и архитектурой отдельных доменов. Функциональные - связаны с возможностями систем по поддержке новых бизнес-процессов, которые необходимы для реализации новых бизнес-стратегий. Основное внимание должно быть уделено реализации необходимых приложений и систем, требующихся для обеспечения улучшенных или новых бизнес-процессов. Культурные - несоответствия между сегодняшним состоянием ИТ-департамента организации (набор навыков, компетенций и структуры) и требующимися навыками, компетенциями и структурами. Процедурные несоответствия – несоответствия между существующими и желаемыми методами управления, процессами эксплуатации ИТ-сервисов и организационными процедурами. 3) Определение возможностей организационно-технологической архитектуры для решения обнаруженных проблемных мест и обновление списка несоответствий с учетом полученных данных. 4) Группировка полученных несоответствий по типу влияния на деятельность. Таким образом, условно можно сказать, что существует два типа несоответствий: "жёсткие" несоответствия, которые связаны, например, с необходимостью замены ряда технологий или внедрения новых; "мягкие" несоответствия, например, несоответствие архитектурным принципам или несоответствия между имеющейся и требуемой квалификацией персонала. После того как найденные несоответствия идентифицированы, должны быть расставлены приоритеты, а затем предложены возможные решения и проекты, которые бы "закрывали" найденные проблемные места. То есть, в конечном итоге, несоответствия "становятся" проектами, реализуемыми ИТ-департаментом и группой управления проектами. Существуют такие ситуации, которые связаны с количеством выявленных несоответствий между состояниями. Одной из причин незначительного количества найденных соответствий является недостаточный уровень детализации состояний. И обратная ситуация, где появляется большое количество различий может является следствием избыточного уровня детализацией состояний. Наиболее естественной выглядит ситуация, где происходит постепенное наращивание количества несоответствий по мере повышения уровня детализации. 21.Характеристика мотивационной модели Модель мотивации проекта — это диаграмма, которая визуализирует объекты АП, описывающие заинтересованные стороны, причины инициации проекта, цели проекта и основные требования в общем виде. Использование этой диаграммы имеет смысл только в случае зрелости корпоративной культуры предприятия и готовности заинтересованных сторон работать с этой моделью. Чаще всего заинтересованным сторонам удобнее работать с реестрами и таблицами, отражающими мотивацию проекта. Хотя на метамодели мотивации отражен такой объект АП, как «Принципы», его использование на практике оправдано в случае достаточной зрелости архитектурной культуры. Модель мотивации проекта использует объекты и связи, которые отражены в артефактах, созданных на этапе начала проекта.  22. Бизнес-способности компании Способность – это уникальная комбинация ресурсов, позволяющая компании осуществлять определенную деятельность (например, маркетинг, проектирование, производство), направленную на создание ценности для клиентов. Основные характеристики способностей:  Применение бизнес-способностей: Для комплексного анализа бизнеса; Для управления и планирования; Для специализации бизнеса; Для бенчмаркинга; Для выравнивания бизнеса и ИТ Карта способностей – это инструмент коммуникаций и единого понимания между всеми заинтересованными сторонами (на языки бизнеса). 24. Компонентное моделирование деятельности компании Компонентная бизнес-модель –модель предприятия в форме двухмерной матрицы, столбцы которой являются крупными и принципиально различимыми областями деятельности, а строки –уровнями управления. Уровень управления –структура для разделения Управления (direct), Контроля (control) и Выполнения (execute). Бизнес-компетенции–высокоуровневое описание осуществляемой деятельности; области деятельности. Бизнес-компоненты–индивидуальные бизнес-модули, которые имеют специфическую роль внутри предприятия и объединяют схожие виды деятельности. Каждый бизнес-компонент имеет пять измерений: бизнес-цель (почему существует этот компонент), активности (какие простые действия обычно выполняются), ресурсы (какие активы и человеческие ресурсы необходимы), модель управления (как активности и ресурсы управляются) и бизнес-сервисы (что берется и предлагается для других компонентов)  Цели компонентного моделирования: Сделать предприятие более гибким Определить элементы управления и сфокусироваться на них Наглядно представить компанию и её составляющие Облегчение понимание бизнеса за счёт единократного составления модели и многократного применения Понять существующие процессы управления, определить возможности для улучшения, наглядно описать процессы Демонстрация пробелов (gaps) и областей прикрытия (overlaps) Формирование сервисов и ИТ как предпосылка для построения SOA 25. Моделирование уровня зрелости процессов компании Любое совершенствование процессов подразумевает плавный/поэтапный процесс. В CMMI эти этапы формализованы — существует 5 уровней зрелости, каждый из которых указывает на зрелость процессов организации. Изначально модель создавалась для проектных организаций, занимающихся разработкой ИС. Со временем модель была многократно модифицирована. Сегодня применяется в разработке ПО, управлении бизнес-и ИТ-процессами, управлении проектами, управлении поставками и т.п. Уровень зрелости ИТ-процесса: Уровень 0. Несуществующий. Процесса не существует в организации. Отсутствие понимания необходимости в процессе управления ИТ. Уровень 1. Начальный/ Хаотичный. Процессы непредсказуемые, слабо контролируемые. Процессы появляются в ответ на определенные события. Это уровень, на котором, по определению, находится любая компания. Отдельные руководители в компании понимают необходимость совершенствования процесса, однако на практике меры принимаются бессистемно и непоследовательно. Уровень 2. Повторяемый/ Реактивный. Процессы определены на уровне проектов. Здесь уже появляются политики и процедуры организации процессов, утвержденные на уровне компании. Но в полной мере процессы существуют лишь в рамках отдельных проектов. В компании определены наиболее критичные для бизнеса ИТ-процессы и сервисы. Уровень 3. Определенный/ Формализованный. Процессы определены на уровне всей организации. Здесь появляется стандартный процесс на уровне всей компании в целом. Это большой и постоянно пополняющийся набор активов процесса – шаблонов документов, моделей жизненного цикла, программных средств, практик и пр. Начинает осуществляться контроль значений показателей работы информационных систем/сервисов и могут применяться специализированные подходы. Уровень 4. Управляемый/ Измеримый. Процессы измеряются и контролируются. Подразумевает появление системы измерений в компании, которые происходят на базе стандартного процесса и позволяют количественно управлять разработкой. Взаимоотношения между бизнесом и ИТ строятся по принципу предоставления услуг в рамках модели “поставщик-потребитель”, все участники используют возможности ИТ. Уровень 5. Оптимизированный. Фокус на совершенствование процессов. Подразумевает постоянное улучшение процессов разработки, как постепенных, пошаговых, так и революционных. Процесс совершенствуется сам и постоянно – есть, реализованы соответствующие механизмы. Полноценное взаимовыгодное сотрудничество бизнеса и ИТ, когда управление ИТ выводится на стратегический уровень. Данная модель применяется для оценки зрелости процессов внутри организации. Для демонстрации уровня зрелости процессов в компании используются тепловые карты или же радарные диаграммы. Так же в Cobit 4 можно найти описание уровня зрелости по каждому эталонному процессу. |