Кейс моделирования ИТ-архитектуры предприятия

Давайте подумаем, кто такой ИТ-архитектор. Я встречал много определений, что такое ИТ-архитектура, но мне больше всего импонирует такое:

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

Обратите внимание, что имеется в виду именно совокупность информационных систем.

Почему-то некоторые считают, что аналитик 1С не должен заниматься ИТ-архитектурой – этим должны заниматься ИТ-архитекторы. Я с этим в корне не согласен, потому что одна из задач аналитика 1С – это понять бизнес клиента и решить, при помощи каких продуктов 1С (или не 1С) этот бизнес можно автоматизировать.

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

Итак, задание: нужно смоделировать ИТ-архитектуру сети из пяти мини-пекарен и одного производственного центра с целью показать, как бы вы рекомендовали это все автоматизировать. Состав подразделений:

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

• Офис (расположен в помещении Цеха по производству полуфабрикатов). Здесь расположено руководство, бухгалтерия, кадровая служба.

• Служба доставки (расположена в помещении Цеха по производству полуфабрикатов). Предназначена для доставки полуфабрикатов и готовых изделий в мини-пекарни, а также для закупки продуктов. Она же доставляет упаковочные материалы.

• Пять мини-пекарен – розничные точки, где выпекаются кондитерские изделия, упаковываются и продаются населению; некоторые изделия поступают из цеха в готовом виде.

По организационной структуре:

• производство – это ООО;

• мини-пекарни – это ИП на упрощенке.

Пользователей на старте – меньше 10: по одному в каждой пекарне и пару пользователей в офисе (главбух и помощник бухгалтера).

Ранее деятельность компании никак не была автоматизирована, все открывается с нуля. Необходимо составить карту информационных систем, где показать:

• Какие территории участвуют.

• Какие используются программные продукты. Приоритет – на бизнес-приложениях 1С.

• Кто является пользователем.

• Как организованы взаимосвязи между программными продуктами.

В интернет-продажи пока не лезем, сайт компании тоже не нужен. Бизнес пока еще только на стадии развития розничных точек.

Идеальное решение зависит от потребностей клиента

Для этого задания есть много правильных вариантов решения, но идеального нет, потому что для приближения к идеалу нужно задать еще много дополнительных вопросов – задание не полное:

• Нужно понять, как компания планирует развиваться через год – будет ли там больше точек.

• Будет ли развиваться производство.

• Будет ли организована доставка через сторонние сервисы и т.д.

Аналитик должен прежде всего вникать в бизнес. И правильное решение зависит именно от потребностей бизнеса.

Когда мы проектируем ИТ-архитектуру, у нас возникают вопросы:

• Какие пользователи, группы пользователей или роли будут работать с этими системами?

• Чем конкретно в решениях они будут пользоваться?

• Как это будет реализовано на уровне серверов и «железа»?

• Каким способом будут взаимодействовать информационные системы?

• Как функциональность элементов систем будет связана с конкретными бизнес-задачами?

• И многое-многое другое

Методики и инструменты для описания ИТ-архитектуры

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

Эти знания можно почерпнуть из свода знаний бизнес-анализа BABOK. Для моделирования ИТ-архитектуры BABOK рекомендует две модели (техники).

• TOGAF – это фреймворк для разработки архитектуры ИТ и предприятия от компании Open Group.

• И Archimate – это открытый стандарт языка моделирования ИТ и бизнес-архитектур.

Причем в BABOK есть и другие рекомендации – по архитектуре бизнес-процессов, проектированию карты возможностей, карты путешествий клиента, организационной карты и т.д. Там 50 техник, которые следует применять при выполнении работ по бизнес-анализу. Рекомендую почитать.

Суть TOGAF в том, что когда вы прорисовываете ИТ-архитектуру, нужно думать над разными уровнями:

• уровень программного обеспечения;

• уровень данных;

• уровень информационных систем;

• уровень информационной архитектуры;

• и уровень бизнес-архитектуры.

Это те самые слои.

Но есть еще и язык моделирования ИТ-архитектуры – Archimate. Он тоже использует многоуровневую структуру, но слои в него организованы немного иначе:

• физический уровень;

• технологический уровень;

• уровень приложений;

• уровень бизнеса;

• уровень стратегии.

Причем здесь еще есть вертикальные столбцы:

• Passive Structures – пассивные структуры (например, документы, данные).

• Behavior – поведение, действия, процессы.

• Active Structures – активные структуры (например, подразделения, системы, сотрудники)

Можно образно объяснить это через простую фразу «Мама мыла раму», где:

• Кто? – активные структуры (мама);

• Что делает? – действия (мыла);

• С чем работает? – пассивные структуры (рама).

Только в Archimate это читается справа налево. Грубо говоря:

• Данные попадают в базу (пассивная структура);

• В результате выполнения какого-то действия (процесс);

• Которое инициировал пользователь или система (активная структура).

Причем на курсе я тоже сначала даю это задание, а только потом знакомлю студентов с Archimate и TOGAF – специально не объясняю эти подходы заранее. Потому что сначала аналитик должен все-таки подумать, а не работать строго по шаблонам. Поэтому сначала они пробуют нарисовать сами, а потом я показываю, как все это профессионально изобразить, чтобы было понятно.

Вот так, условно, выглядит «правильная» модель сети пекарен с офисом, прорисованная в Archimate. Здесь используется 1С:Бухгалтерия предприятия и РИБ из 1С:УНФ, где отражаются производственные процессы и расчеты с покупателями.

Кстати, если говорить об инструментах, с помощью которых можно строить модели ИТ-архитектур, то есть несколько вариантов:

• Archi – это бесплатное приложение американского происхождения, но его использование никто не запрещал. Я обычно использую именно его – его можно установить локально, интерфейс интуитивно понятный. Поддерживается на Windows и macOS.

• СиММА – российская система, тоже предназначенная для моделирования ИТ-архитектуры. Если честно, я с ней сразу не смог разобраться, поэтому прорисовывал все в archi.

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

Да, конечно, можно рисовать архитектуру «на глаз», как вы её видите. Но формальные языки, такие как Archimate, нужны не для красоты, а для того, чтобы другие вас понимали. И чтобы убедиться, что вы не забыли отобразить все, что нужно – пользователей (бизнес-уровень), приложения, технологии.

Причем при помощи нотации Archimate можно даже моделировать бизнес-процессы, но это не очень удобно. Для процессов лучше использовать BPMN, а Archimate – это в первую очередь архитектурное моделирование.

Рассмотрим типовые ошибки

Теперь я хочу показать решение того же задания, но уже после того как учащиеся изучили Archimate, чтобы показать наиболее часто встречающиеся ошибки.

Например, такой вариант:

• в мини-пекарнях используется РИБ на основе 1С:Розница

• а в офисе – 1С:TMS логистика, Бухгалтерия и УНФ.

Здесь много вопросов. Например, если есть УНФ, зачем еще Розницу ставить, тем более, что УНФ 3 и Розница 3 – это, по сути, одна и та же конфигурация.

Но в целом, можно сказать, что все нарисовано правильно. За исключением связей – они здесь обозначены в виде триггеров. Если боитесь ошибиться, лучше в Archimate рисовать ассоциации (простые линии).

Следующая проблема – цвета и значки.

Например, здесь не понятно, что обозначено розовым – территории или бизнес-объекты?

Если территории, что в Archimate для них предусмотрены специальные обозначения, и их не надо обозначать розовым – для каждого уровня есть рекомендуемые цвета, чтобы было понятно.

Обратите внимание, насколько по-разному все можно автоматизировать. И заодно думайте о том, как это сделать так, чтобы смоделировать понятно.

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

Если уж вы начали отображать технологический уровень – в данном случае, «Сеть интернет» – его нужно отображать везде.

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

Здесь не показали территории, вместо них обозначили только бизнес-объекты, потому что желтый уровень – это уровень бизнеса.

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

Здесь вообще вариант немного странный, если честно. На физическом уровне идет Файловая СУБД MS SQL Server, из нее выходит СУБД Центральная база, а их нее – Кластер серверов 1С и РИБ. Ко всему можно придираться.

Честно, очень сложно найти работу, которая прям идеально нарисована. Большинство людей путается.

Слои тоже нужно отображать корректно. Не может пекарня стоять поверх УНФ, наоборот – УНФ стоит в пекарне.

Слои можно отображать по вертикали или один над другим наслаивать.

Но тогда надо наслаивать правильно – более низкий по уровню слой должен быть внизу. Например, у нас есть пекарня, а в пекарне уже стоит УНФ. А не УНФ где-то там непонятно стоит, а на него погрузили пекарню с магазином.

Причем здесь используется «1С:Управление пищевым производством», но решения с таким названием нет. Есть «Управление нашим пищевым производством» – без приставки «1С:» Я считаю, что аналитик все-таки должен знать программные продукты. А если не знает, залезть в интернет и посмотреть.

Но вообще есть специализированные решения – в том числе, под хлебобулочное производство. Причем не одно. На ERP есть специальные наработки под хлебобулочные производства – если уж такие решения есть, наверное, надо хотя бы задуматься и применить их.

Путаница в типах и направлении связей.

Почему-то здесь из ERP что-то попадает в 1С:Бухгалтерию, а обратно ничего не идет, хотя обмены – почти всегда взаимные. А в ЗУП – нормально: и туда, и сюда что-то передается.

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

Обратите внимание, здесь у нас и ERP есть, и в «TMS. Логистика», и WMS. Все это излишне.

И Бухгалтерию с ЗУП отдельно от ERP тоже необязательно было выносить. Я понимаю, что Бухгалтерию часто ставят отдельно, потому что она неудобна бухгалтерам – они не выучились там работать. Но в ERP-то, в принципе, регламентированный учет есть, и ЗУП там есть.

Причем в качестве основной системы оперативного учета выбрана «Розница». Можно, конечно, ставить «Розницу», но там действительно нет никакого производства, даже самого простого. Понятно, что можно и в Excel вести. Но все вместе – излишне.

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

Перепутали цвета для всех слоев. УНФ показали вообще значком из технологических уровней, а тут все-таки уровень приложения.

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

• На бизнес-уровне мы доставляем товар.

• На уровне приложения это будет определенный документ, который отражает доставку товара – он заводится в определенной системе.

• А на технологическом уровне будет видно, как все это попадает в базу данных.

И очень круто, что в Archimate это есть. Но здесь все напутали, конечно.

Здесь не хватает слоя приложения, элементы без связей.

Теоретически Archimate позволяет рисовать вообще без связей. Например, вы хотите просто нарисовать состав подразделений. Или – какие программные продукты будете использовать. Но если уж вы взялись рисовать связи, рисуйте их до конца.

Например, тут у пекарей есть удаленный доступ. А к чему? Непонятно.

Из конфигураций здесь у нас «1С:Бухгалтерия хлебобулочного и кондитерского производства» и «Розница». Причем все это находится на одном уровне с кластером серверов, ОС Linux и СУБД PostgreSQL. Тоже непонятно.

Очень много пользователей пользуются Бухгалтерией – директор, начальник отдела кадров, коммерческий директор. А начальник ИТ-служба пользуется удаленным доступом и РМК 2 в одной из пекарен. Ездит он что ли в эту пекарню? Очень сложно все.

Еще один вариант – неверно выбраны элементы, не понятны связи.

«Товарный учет, аналитика, управление складом» – это должен быть бизнес-уровень, его нужно немного по-другому нарисовать.

Причем в мини-пекарне используется «1С:Розница», а в офисе – «1С:Предприятие. Общепит», «Зарплата и управление персоналом» и «Документооборот». Зачем в маленькой производственной компании «Документооборот»? Непонятно.

Какие еще бывают ошибки?

• Люди воспринимают моделирование архитектуры просто как создание картинок, а это не так.

• Путают моделирование архитектуры предприятия с моделированием бизнес-процессов.

• Вписывают технологические процессы внутри приложения – неправильно отображают уровни.

• Не ориентируются на правильную структуру представлений.

• Путают ситуации, когда активный структурный элемент получает сервис, и когда он назначается на представление сервиса.

• Плохо ориентируются в доменах мотивации и стратегии.

• Не могут корректно создать диаграмму по текстовому описанию.

• Взаимодействие ИТ-систем отражают как в других нотациях стрелкой, соединяющей две системы

• Не умеют правильно пользоваться расширениями нотации и т.д.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.