IT для бизнеса: Что владельцу нужно знать про описание архитектуры компании

Кому и зачем нужна архитектура предприятия

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

IT

Сталкиваясь с технологическими новинками, бизнес в лице владельца решает две задачи:

  • Что может дать технологическая новинка бизнесу?
  • Как и когда (при каких условиях) следует ее использовать?

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

У каждой категории топ-менеджеров разные компетенции, цели, полномочия и объем сведений, которые они успевают осваивать. Владельцы бизнеса – самая интересная аудитория. С одной стороны наибольшие полномочия, с другой – IT всего лишь одна из многочисленных тем, которой владельцы уделяют внимание. Причем многие решения о выборе, внедрении и поддержке IT-решений владельцы бизнеса делегируют. Поэтому особое значение приобретает то, чего они не могут делегировать либо в силу высокой стоимости проекта, либо потому, что это затрагивает сразу несколько направлений деятельности предприятия. Такой темой мне представляется описание архитектуры предприятия (АП).

Концепция архитектуры систем проста. Архитектура – это взаимосвязь структур, описывающих объект. Структура, в свою очередь, – это взаимосвязь однородных элементов, составляющих объект. Так что архитектура есть у каждого предприятия. Другими словами, АП – это писаные и неписаные правила появления, изменения, удаления и взаимодействия составляющих элементов предприятия. Получается, что и описание АП есть практически у каждого предприятия. За исключением, естественно, «неписаных правил». В чем же тогда особенный интерес к использованию IT для описания АП именно сейчас? Назову три особенности:

1) Компьютерные технологии сами по себе стали элементами АП. Их много и связей между ними достаточно много;

2) Компьютерные технологии связаны со многими другими элементами АП;

3) Изменяются компьютерные технологии очень быстро, следовательно – быстро изменяется и АП.

Описание АП это всего-навсего информация о том, как организован и как работает бизнес. Пока информацию никто не использует – она ничего никому не дает. Факт этот никого не должен обескураживать. Даже если программные системы имеют громкие привлекательные названия типа «Управление проектами» или «Управление кадрами» – никакими проектами они не управляют и, тем более, никто не позволит им управлять кадрами. Все, что подобные системы дают специалистам, так это информацию о предмете их занятости и автоматизацию отдельных операций по подготовке и обработке этой информации.

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

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

Как формировать описание архитектуры предприятия

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

Упрощенно, процесс описания архитектуры предприятия можно подразделить на пять этапов:

  • Инициировать работы по описанию АП: назначить ответственного исполнителя или создать подразделение. Открыть проект, установить сроки, выделить ресурсы, выбрать инструментарий (программное обеспечение).
  • Определить элементы, их характеристики и взаимосвязи для включения в описание АП.
  • Определить источники данных для описания элементов архитектуры и регламент их предоставления.
  • Выгрузить, очистить и агрегировать отобранные данные в хранилище.
  • Визуализировать описание архитектуры.

Этапы №2-5 повторяются регулярно.

IT

Циклы формирования описания архитектуры предприятия

Ключевым в этом процессе является этап №1, на котором создается и пересматривается общая модель описания АП. То есть выделяются элементы, их характеристики и связи, данные о которых будут собираться, а также формируются правила, по которым их можно выявить, что говорится, в «реальной жизни».

Все элементы АП описать невозможно, да и не нужно. В каждом цикле следует в первую очередь выбирать те элементы АП, информацию о которых вы считаете недостаточной. Большую помощь в выборе элементов может оказать знакомство с многочисленными моделями и методологиями построения архитектуры предприятия: TOGAF, Модель Захмана, DoDAF и другими.

Рекомендации

1) Не пытайтесь сразу описать сложные элементы архитектуры полностью. Выбранная модель представления АП должна позволять фиксировать неполноту описания. Например, лучше не оставлять значения описываемых элементов пустыми. Если какая-то из характеристик отсутствует – просто указывайте «N/A» (not applicable). Если значение характеристики необходимо выяснить – пишите «TBD» (to be defined). Можете расширить эту классификацию собственными категориями: «будет выявлено на этапе Х», «неважно на настоящий момент», «полное описание см. в системе Y» и т. п. Когда вы понимаете, какой именно информацией не располагаете и тем более почему – это тоже информация для принятия решений.

2) Отделите описание АП от ее проектирования (разработки). Описание АП – это документирование всех осуществленных изменений на предприятии согласно решениям, положенным в основу модели. Проектирование АП – подготовка любых изменений на предприятия. Эти две активности используют разные методы. Общее у них только документирование. Технически, можно объединить в общем описании АП и описание «как есть» (as is) и описания «как будет» (to be). Но необходимо учитывать, что это разные задачи, разные компетенции, разные проекты.

3) Не назначайте ответственным за описание АП «главного архитектора». И вообще, не ищите главного архитектора. Архитекторов много: архитектор бизнес-процессов, архитектор данных, архитектор информационной безопасности и некоторые другие. Все, кто уполномочен принимать решения по формированию или изменению каких-либо структур или процессов на предприятии являются архитекторами. И все они – ответственные за соответствующие элементы АП. Иерархию архитекторов, естественно, возглавляет владелец бизнеса. Задача описания заключается в подготовке консолидации данных. Ответственный за описание АП не должен проектировать проведение каких-либо изменений на предприятии или в IT. Единственное требование к его профессиональным способностям – это разработка модели АП и организация работ по ее наполнению.

4) Не торопитесь автоматизировать новые технологии. IT-решение не автоматизирует всю технологию. То есть вы не замените технологический процесс полностью автоматическим IT-решением. Автоматизация означает не автоматический процесс, а всего лишь автоматизацию отдельных операций с данными в этом процессе. Сможет ли персонал своевременно готовить эти данные и использовать их с пользой для предприятия – это ответственность бизнеса. Поэтому рекомендуется сначала развернуть на предприятии необходимый процесс на имеющихся средствах. Потом, когда убедитесь, что технология работоспособна и целесообразна, можно ставить вопрос о более широком использовании в ней IT. В этом случае можно рассчитывать, что IT-специалисты сами определят, где именно и как конкретно применить IT наилучшим образом.

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

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

6) Не стремитесь собрать все описание АП в одной информационной системе. Максимально используйте данные об элементах АП, которые уже ведутся в имеющихся на предприятии системах.

7) Начинайте задумываться об описании АП тогда, когда почувствуете неуверенность в правильной расстановке приоритетов своих задач.

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

Редактор рубрики «IT для бизнеса» – Сергей Соловьев

Источник изображения: pixabay.com

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Программист, Тюмень
Виктор Жилин пишет: Александр любое описание чего-либо, любая модель ''as is'' устаревает в момент начала своего составления... своего рода фотография бизнеса, компании, предприятия и т.п. на момент составления... Если ...
Оптимизация бизнеса - это процесс инкрементального прироста. Он основан на итерационных циклах. Итерационный цикл имеет шесть этапов: 1. Наблюдать 2. Думать 3. Предполагать 4. Решать 5. Менять 6. Оценивать АП - как модель, появляется на первом этапе. И на всех последующих пяти этапах она используется (потому как инструмент). И так до достижения совершенства. То есть быть эффективной при минимальном количестве элементов. На шестом этапе - мы уже имеем АП` как один из результатов. И на следующем итерационном цикле мы начнем с АП` и закончим АП``.
Менеджер, Санкт-Петербург
Александр Араптанов пишет: И на следующем итерационном цикле мы начнем с АП` и закончим АП``.
Зачем эти документы кроме как фиксации (документирования) состояния ''as is'' в момент перехода на следующую итерацию?... Как они используются в дальнейшем?
Менеджер, Санкт-Петербург
Виктор Жилин пишет: Александр, вероятно ваш вопрос указывает на еще одно упущение в публикации. Никто не предлагает рассматривать Описание АП как один документ: doc, pdf или xls. Есть много определений у документа. Мне нравится такое: это материал, который имеет название, содержание, дату выпуска и автора. Описание АП - это модель. Компоненты этой модели регулярно изменяются. Меняются и связи между компонентами. И у каждого из таких изменений есть: название, содержание , дата и автор. Так что Описание АП ведется в среде, в которой можно ''документировать'' каждое изменение отдельно.
Виктор В Вашей публикации четкое указание что описание АП это процесс... относительно того что описание АП это модель типа ''as is'', то сразу встаёт вопрос -- это процесс моделирования или результат моделирования? меня совершенно не волнует форма документирования ''Описание АП'', мне интересы только цели создания этого документа (комплекта документов) и его потребители...
Программист, Тюмень
Александр Воробьев пишет: Зачем эти документы кроме как фиксации (документирования) состояния ''as is'' в момент перехода на следующую итерацию?... Как они используются в дальнейшем?
На долгую память и на координацию действий.
Системный аналитик, Москва
Александр Воробьев пишет: мне интересы только цели создания этого документа (комплекта документов) и его потребители...
Александр, Описание АП - это всего на всего информация. Информация помогает (или не помогает) решать задачи, которые стоят перед предприятием. Пока информация не используется - она ничего предприятию не дает, кроме убытков. Только эту мысль и хотел донести в публикации. А на ваш вопрос есть много хороших ответов в интернет. И все они правильные. Например: … 7 основных задач, которые поможет решить Архитектура Предприятия (Enterprise Architecture) в конкретной компании [COLOR=gray=gray]***сообщение отредактировано модератором***[/COLOR] 1. Сфокусировать действия ИТ на целях и задачах бизнеса. 2. Наладить сотрудничество между бизнесом и ИТ. 3. Получить максимальную ценность от ИТ. 4. Управлять изменениями в компании. 5. Навести порядок в ИТ. 6. Внедрять новые ИТ-функции быстро, качественно и недорого. 7. Управлять развитием ИТ. Или мнение PDTEX[COLOR=gray=gray] ***сообщение отредактировано модератором***[/COLOR] Единое, комплексное описание текущей архитектуры предприятия обеспечивает: целостное, непротиворечивое видение инфраструктуры бизнеса и информационных технологий предприятия; чёткое представление взаимосвязей и взаимовлияния бизнеса и информационных технологий предприятия; стандартизацию на описательном уровне архитектурных компонентов; поддержку анализа и выявление проблемных областей бизнеса, его поддержку со стороны информационных технологий; уменьшение стоимости идентификации архитектурных компонентов; повышение эффективности и достоверности информационного обеспечения процессов поддержки принятия решений по согласованному управлению бизнесом и ИТ предприятия; снижение уровня зависимости предприятия от конкретных носителей архитектурных знаний (персоналий, организаций-соисполнителей); возможность применения средств автоматизации для анализа архитектурных компонентов и их взаимосвязей, а также для автоматизированного формирования различных архитектурных представлений для целей управления предприятием; структурированное хранение технических, нормативных, административных, регламентирующих и распорядительных документов в их привязке к соответствующим архитектурным компонентам; информационный базис для разработки системы управления архитектурой предприятия и реализации процессов управления архитектурой [COLOR=gray=gray]***сообщение отредактировано модератором на основании пункта 7.2 Декларации Сообщества: 7. Участникам Сообщества настоятельно рекомендуется: 7.2. При создании блога/дискуссии полностью излагать свою мысль/ проблему, а не переадресовывать участников Сообщества к сторонним сайтам. Администрация ресурса оставляет за собой право удалять ссылки на другие сайты (например, «Читайте дальше здесь» и др.); ***[/COLOR]
Менеджер, Санкт-Петербург
Виктор Жилин пишет: Александр, Описание АП - это всего на всего информация. Информация помогает (или не помогает) решать задачи, которые стоят перед предприятием. Пока информация не используется - она ничего предприятию не дает, кроме убытков. Только эту мысль и хотел донести в публикации.
И я такого же мнения... Виктор
Виктор Жилин пишет: А на ваш вопрос есть много хороших ответов в интернет. И все они правильные. Например:
Нет там ответа на мой вопрос (там про ценность самого процесса описания, но нет ни буквы про ценность документа ''описание'' и его потребителей при наличии модели ''as is'')
Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Виктор Жилин пишет: Забавно, цитирую Виталия Елиферова, а сайт подставляет Александра Араптанова. В этот раз заметил и поправил ручками
Бывают такие глюки на этом сайте. При размещение ссылки на FB своей статьи, размещенной здесь, вижу на FB фото автора - дама в красном жакете :-)) - на меня совсем не похожа.
Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Виктор Жилин пишет: 1. Сфокусировать действия ИТ на целях и задачах бизнеса. 2. Наладить сотрудничество между бизнесом и ИТ. 3. Получить максимальную ценность от ИТ. 4. Управлять изменениями в компании. 5. Навести порядок в ИТ. 6. Внедрять новые ИТ-функции быстро, качественно и недорого. 7. Управлять развитием ИТ.
Все правильно и замечательно, но ... причем здесь Владелец? Все что перечислено, - это для ИТ-Директора. Владельцу нужны другие вещи (предметы, услуги), за это он не заплатит.
Системный аналитик, Москва
Виталий Елиферов пишет: Все правильно и замечательно, но ... причем здесь Владелец? Все что перечислено, - это для ИТ-Директора.
Виталий, ''это'' пишет Андрей Коротков в своей книге «Архитектура Предприятия». В свою публикацию я не выключал никакие перечни того, что может дать Описание АП, кроме как информацию. Перечень приведен в качестве ответа на вопросы Александра Воробьева. Впрочем, с приведенным перечнем - совершено согласен. Более того, полагаю что существуют и такие владельцы бизнеса, которые поймут формулировки и увидят в них и свой интерес.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Уровень счастья напрямую влияет на продуктивность большинства россиян

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

70% россиян отмечают сильное влияние работы на уровень стресса

Наибольший стресс создают строгие дедлайны, внезапные и большие объемы задач, а также собственные ошибки при выполнении задач.