Система «Федерация». Часть 2/10 Концепция
Сформулируем цель для нашей системы принятия архитектурных решений «Федерация» более четко следующим образом:
• Есть поставщики систем, автоматизирующие отдельные виды деятельности, функциональные области — CRM, АБС, ДБО и т.д.
• Есть ИТ-ландшафты компаний Группы различного профиля, финансовые, транспортные, лизинговые и т.д. — потребители этих систем
• Необходимо иметь траекторию принятия архитектурных решений для тиражирования систем поставщиков в ИТ-ландшафты потребителей с учетом «мутной» зоны между централизацией и локализацией
Определим базовые блоки функций «Федерации» для типовой Gруппы компаний (финансовой, промышленной — нет разницы). Типовой, что бы можно было бы легко адаптировать приведенную схему к конкретной
Управляющий контур : коллегиальные органы, принимающие архитектурные решения. Обычно, есть некий Управляющий комитет (УК), при нем есть технологический или технический комитет, а при нем специализированная рабочая группу для принятия решения в части корпоративной архитектуры. В вашей организации структура и названия могут отличаться, но общая конструкция, полагаю, похожа.
Архитектурные инструменты: это необходимые средства управления корпоративной архитектурой.
• Функциональная архитектура (ФА) — таксономия функциональных областей, декомпозирующей бизнес конкретной организации, на слабосвязанные области деятельности: фронты продаж и обслуживания, Управление сотрудниками, бух и налоговый учёт. Аналоги BusinessCapabilities в TOGAF. Подробнее далее.
• Критериальная модель (КМ) для оценки различных информационных систем. Мы рассмотрим КМ более подробнее далее, сейчас обзор общей архитектуры системы принятия решений (СПАР)
• Каталог «Групповых прикладных решений»: каталог — это место, куда будет попадать системы, прошедшие определенную оценку по критериальной модели и рекомендованные для тиража в определенные функциональные области (см. выше)
Источники продуктов: по сути партнеры, текущие и потенциальные поставщики Gруппы. Обычно их можно распределить на следующие домены:
• Партнеры — поставщики, уже имеющие отношения с Gруппой. Причем могут быть как «ситуативные» партнеры, так и стратегические.
• Рынок — это рынок, что тут скажешь. Причём, важно заметить, что в данном случае рынок может быть международным, если Gруппа имеет несколько стран присутствия
Потребители продуктов: компании Gруппы, кому мы и должны наладить процесс выбора решений в их ИТ-ландшафт. Для рассмотрения более сложного для управляемости организационного устройства Gруппы, примем, что участники Gруппы, самостоятельные ЮЛ, со своей, локальной закупочной процедурой, но архитектурные стандарты, унифицированны на уровне методологии моделирования корпоративной архитектуры. Исходя из этого предположим, стандарт нашей Группы определяет следующие понятия:
• Целевая прикладная архитектура (ЦПА)(: связка функциональных областей функциональной архитектуры (ФА) и конкретных систем, автоматизирующих эту функциональную область (см. Далее). Например, область CRM реализуется Siebel CRM, запрещенный в ЗОО КИ РФ, а АБС — ЦФТ, ДБО BSS и т.д.
• Каталог, или реестр информационных систем (РИС): список информационных систем, используемых в ИТ-ландшафте конкретной организации
Включение системы в РИС конкретной организации — это тиражирование системы в организацию, а в какую функциональную область — это целевая прикладная архитектуру (ЦПА) конкретной дочки.
Все выше описанное «собирается» в единую конструкцию некоторыми архитектурными процессами:
• Первый процесс — это управление основным инструментом оценки — критериальной моделью. Инструмент требует регулярной «правки», «заточки» кромки и для этого нужно операционная модель. Конечно рассмотрим. Позже.
• Второй процесс — это сама оценка решений, для включения в каталог групповых продуктов. Тоже, обсудим.
• Третий процесс — это актуализация ЦПА конкретной организации, с включением решения из каталога «Групповых прикладных решений»
Требования уточнены, начнем проектировать архитектуру «Федерации».
Что имеем на входе:
множество продуктов, которые мы хотим тиражировать в Gруппу с одной стороны
с другой стороны — потребителей этих продуктов
Явно видны два контекста — контекст поставщика и потребителя. Они объективно не связаны — действительно, создатель продукта при его проектировании имел в голове свое понимание «использования» своего детища.
Например,
«Мой CRM продукт будет использоваться в «ламповой» организации — в теплой части нашей Родины исключительно для задач операционного CRM» — мечтательно и с легким оттенком наивности подумал Поставщик.
«Операционный CRM — хорошо, мне еще нужен MDM — почему нет, вроде выглядит нормально, запилю» — с блеском архитектурного азарта замечает про себя Потребитель №1
«а чего еще и досье клиента в нем реализовать» — простодушно, подхватывает Потребитель №2
Т.е. нужна оценка одного решения в контекстах различных потребителей. Если будет решать задачу «в лоб» и оценивать продукт для каждого потребителя отдельно. Т.е. каждый потребитель оценивает продукт под себя исключительно. Здесь видятся два недостатка:
Трудоемкость каждой конкретной оценки по используемым ресурсам — эксперты нужны в полном составе и каждый раз. Они должны будут погружаться в контекст потребителя каждый раз и проводить полный анализ.
«Мутная зона» — здесь у нас оцеки идет «мимо» Центра Gруппы. Т.е. 3–5–10 «междусобойчика». Кручу-верчу себе выбрать хочу. Есть существенный риск потери управляемости.
Масштабируемость — если в полку участников Gруппы прибыло — опять собирать всю команду оценки и засучив рукава приниматься за дель
Как-то неопрятно.
Что можно предложить для решения этих и не только этих проблем:
Фаза 1 Централизованная: Сперва проработка общей централизованной оценки, проведенной, что называется, на полный штык. Как в свете федеральных стандартов выглядеть решение, другими словами — продукт вообще?
Фаза 2 Локальная: Следующий шаг — адаптация общей оценки к контексту организации. Например, эта особенность решения для всех ли участников Gруппы важна или для кого-то не так. «Прикручиваемость» к системе функционала досье клиента одному потребителю хорошо, а другому все равно, а третьему — вообще «кость в горле».
Мы добавляем еще один контекст в нашу задачу — федеративный или gрупповой контекст. Такая «двухфазная» централизованная схема балансирует большую управляемость (Централизация) тиражирования технологий и гибкость для учета контекста участника Gруппы (локализация).
Ключевым элементом этой схемы является критериальная модель оценки системы. Каждый критерий такой модели — определенный аспект — луч радара, в которым рассматривается конкретная система в федеративном контексте. Т.е. как центр оценивает это решения для группы вообще. Насколько это CRM решение соответствует стандартам и архитектуре Gруппы. Используемые технологии, масштабируемость, «настраиваемость» и т.д.
Детали критериальной модели мы посмотрим позже, сейчас важно понять, что на этой фазе мы получаем оценку решения в системе ИТ-координат Gруппы.
Преобразовать эту оценку в общей системе координат в контекст конкретной организации предполагается «профилирование» этой централизованной оценки — весами или профилем конкретной организации. Т.е. заключение gруппового эксперта остается неизменным, но насколько этот аспект актуален в конкретной организации — решается уже в контексте данной организации экспертами, хорошо «чувствующими» этот контекст. Каждому участнику gруппы или однотипным участникам назначается свой «профиль» весов.
Дополнительным плюсом приведенной схемы является возможность иметь высококвалифицированную команду экспертов в центре и использовать ее на все 100 при централизованной оценке решения. Профиль оценки для каждой организации следует утвердить и адаптацию централизованной оценки в контекст конкретной организации можно уже локальными людьми.
Например, в центре провели оценку двигателя для легкового автомобиля, разобрали его до тонкостей и зафиксировали такой экспертный «обзор». Каждая локальная организация, которой занадобиться такой движок возьмет этот «обзор» уважаемых коллеги и посмотрит, как ему подойдет такой агрегат? У кого есть опыт эксплуатации такой техники на севере, а у кого-то на юге и т.д.
Таким образом, ключевым архитектурным решением в проектировании СПАР «Федерация» является двухфазная диалектичная оценка.
Теперь, исходя из выше сказанного у нас получается следующая конструкция:
Продукты представлены на рынке стран пребывания Gруппы
Поставщиками этих продуктов могут быть партнеры Gруппы — как стратегические, так и ситуативные (здесь и сейчас этот продукт этого поставщика будет весьма хорошо)
Фаза 1: Централизованная :
поставщик продукта, которые имеет намерение предложить свой продукт в Gруппу, предоставляет информацию о своем желании и данные о продукте в Центр «Федерации» в карточке продукта (посмотрим позже). Важно что карточка это не столько анкета, которую нужно заполнить, сколько список данных, которые необходимы для оценки системы.
продукт (по данным представленным в карточке) оценивается по определённому набору критериев — критериальная модель, в рамках некоторой рабочей группы или Архитектурного комитета
оценка утверждается на технологическом коллегиальном органе Gруппы и соответствующая оценка помещается в каталог Групповых решений
важно заметить, что в данном процессе оценивается техническое совершенство системы. «Экономика» — финагнсовые словия, цены и т.д. решщается в другом контуре, мы ж лишь предполагаем, что эти вопросы решаются в рамках некоторой закупочной процедуры
результатом этой фазы является централизованная оценка которую мы смотрели выше
Фаза 2 . Локальная : Как было дано в условиях задачи, каждая организация является самостоятельным ЮЛ и мы предполагаем, что в каждом участнике Gруппы своя собственная процедура закупки.
Процедуры закупки в организациях по всех России, да и в мире, могут различаться, но в любой такой процедуре есть типовые шаги: «Формирование списка финалистов», сравнение финалистов
На этапе «Формирования списка финалистов» в рамках закупочной процедуры необходимо просто «заглянуть» в каталог gрупповых решений
Если в каталоге в есть система с соответствующим функционалом (CRM, MDM или ESB и т.д.), то нужно включить такое решение в список финалистов, для дальнейшего анализа
После этого, на этапе анализа решений в рамках локальной процедуры, проводится локализация оценки —
функциональный анализ, на соответствие локальным функциональным требованиям (GAP-анализ)
применение локального профиля оценки (конкретные баллы для данной организации по критериям модели оценки). Т.е. если есть критерий «Импортозамещение», но для данной организации он не актуален (организаций вне РФ), то мы его обнулим или снизим до «ИТ-суверенитета»
Экономические условия — вне рамок нашего технического материала, но этапе анализа финансов, очевидно своя модель оценки — ТСО и другие волшебный слова
Таким, представляется общая концепция, конструкция системы принятия архитектурных решений — СПАР «Федерация».
Далее мы рассмотрим ее составные части по отдельности и более детально.
