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
Комментарии
Программист, Тюмень

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

Работаю программистом 1С в крупной строительной компании. Для описания архитектуры компании и дальнейшей автоматизации используем ''ИС Дракон''. По мимо описания архитектуры компании она позволяет также писать инструкции для конечных пользователей и программировать в 1С (автоматизировать процессы).

Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва

Прочитал статью и не понял о чем она. Приведенная последовательность работ может относиться к созданию любой модели управления: Процессной, Проектной, Матричной, Оргструктуры, Модели для реорганизации и т.д.
То есть - имеется описание ''трубы'', без учета содержимого (кстати специфичного для каждого типа работ и архитектуры).
Есть архитектура Захмана, модели TOGAF, DoDAF, FEA. К ним можно отнести еТОМ, APQC и еще с десяток моделей.
Гораздо интереснее было бы обсудить критерии занесения объектов в ''архитектуру предприятия (АП)'' (почему не в ''модель предприятия''?). Но для этого нужно читать правила построения сложных систем (Гради Буч, ISO 15288, 19760, 42010, 20000-1(-2)) и т.д.
А данный текст напомнил мне ''Инструкцию о порядке делопроизводства'' времен СССР: Что можно и нужно писать в стандарты, документы и регламенты.

Программист, Тюмень

Это упрощенное описание построения ''любой модели''. Название статьи ''Что владельцу нужно знать про описание архитектуры компании'' - а владельцу нужно знать основы. Если копать глубже и по стандартам, тогда это другая статья (а может и книга).

Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Александр Араптанов пишет: Это упрощенное описание построения ''любой модели''. Название статьи ''Что владельцу нужно знать про описание архитектуры компании'' - а владельцу нужно знать основы. Если копать глубже и по стандартам, тогда это другая статья (а может и книга).
Я не уверен, что Владельцу бизнеса будет интересно читать про то, как описать архитектуру. Обычно его интересуют другие вопросы: 1. Зачем это делают? 2. Что это даст для бизнеса? 3. Сколько это будет стоить? А удовлетворять свое научное любопытство за счет владельца компании, - далеко не лучший способ выполнения проектов.
Программист, Тюмень

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

Менеджер, Санкт-Петербург

Меня больше беспокоит неопределенность объекта архитектуры в статье это ''предприятие'', в названии ''компания'', местами по контексту очень возможен ''бизнес''...

P.S. ''формировать описание архитектуры предприятия'' -- Если описание это процесс, то что результат этого процесса?

Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
Александр Араптанов пишет: Если владелец не будет знать основ, он рискует стать жертвой привлеченных специалистов. Нанимая адвоката вы хотя бы знаете, что есть суды и примерно знаете как они работают. Это и есть основы.
Вообще-то такие знания являются необходимой компетенцией Генерального или Исполнительного директора (маленькие компании этим не занимаются).
Системный аналитик, Москва
Что, собственно говоря, хотел донести до владельцев бизнеса: • Архитектура предприятия - это просто. • Архитектура есть у любого предприятия, равно как и ее описание. Описание фрагментарное и не полное. (Но полного описания и не получится с силу закона необходимого разнообразия.) • Иметь описание АП - полезно. Но это всего на всего возможность. Говорить об «экономическом эффекте» описания АП можно только в контексте конкретных случае, когда этой информацией воспользуется кто-либо из ЛПР предприятия • Сформировать и систематически поддерживать в актуальном состоянии описание АП вести • Описание архитектуры предприятия и разработка архитектуры предприятия - разные активности Ключевой посыл - пора вести описание архитектуры предприятия на систематической основе. Будь у Клиента описание архитектуры предприятия - я точно был бы в числе лиц, которые этой информацией воспользовались бы.
Виталий Елиферов пишет: Есть архитектура Захмана, модели TOGAF, DoDAF, FEA. К ним можно отнести еТОМ, APQC и еще с десяток моделей.
Модели не упоминал. Не уверен что владельцы бизнеса знают хотя бы одну или начнут разбираться с этими моделями. С этим могут разобраться их ИТ-специалисты. А взять за основу можно любую. Все равно придется ее. И не расписывал все особенности описания разных элементов (компонент) АП. Не тот формат публикации: размер ограничен.
Виталий Елиферов пишет: (почему не в ''модель предприятия''?)
По сути АП - это модель предприятия. Для публикации выбрал другое название. Французы, те и вовсе называет это «картографией». А то и - урбанизмом.
Александр Араптанов пишет: Гораздо интереснее было бы обсудить критерии занесения объектов в ''архитектуру предприятия (АП)''
Да!. Мне тоже было бы это интересно. Но это уже другая тема. И обсуждать эти вопросы надо с теми, кто уже решил: интересно ему описывать АП или нет.
Программист, Тюмень

Должны быть компетенцией и есть, в наших реалиях не одно и тоже. Те-же самые наемные работники, управляют чужими деньгами и бизнесами.
Маленькие не могут вас нанять.) Маленькие тоже занимаются. Любой бизнес должен иметь систему доставки и учета денег. Обычно пытаются автоматизировать эти две системы в первую очередь. (опять я об автоматизации - профессиональное наверно). Размер компании значения не имеет. Если не сделать их описания будем автоматизировать хаос. Если автоматизировать хаос - получим автоматизированный хаос. У маленьких это маленький хаос у больших большой.

Виталий Елиферов +4100 Виталий Елиферов Менеджер, Москва
1. Принятое в Европе название - ''ландшафтная карта бизнеса''. 2. Про критерии занесения писал я, а не Араптанов. 3. Если Вы хотели донести до читателей важность архитектуры, то (как мне кажется) писать нужно было о том, что она дает ''Иметь описание АП - полезно'' - статье звучит очень мало, гораздо больше о технологии. Поверьте, Владельцу бизнеса технология описания не очень интересна. То есть эта статья не для него. 4. Я последовательно в течение более 10 лет выступаю против ''описаний'' . Описания - это только инструмент (не самый главный) с помощью которого могут достигаться поставленные цели (а могут и не достигаться). Вы же агитирует Владельца за необходимость данного инструмента. Владельцу интересны цели, а не инструменты с помощью которых исполнители будут их реализовывать. Так что ''описания'', с моей точки зрения вредны. P.S. Прошу извинить за резкие высказывания, но в проектах на первом месте стоит цель и польза.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

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

Уровень счастья напрямую влияет на продуктивность большинства россиян

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

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

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