Практика применения UML для проектирования бизнес процессов и информационных систем

Какие задачи можно решить с помощью UML? Несколько примеров из личного опыта.

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

Представьте себе ситуацию: система готова, идут приемо-сдаточные мепрориятия с участием Генерального директора. Все идет хорошо, система работает как нужно. Мы прошли все основные бизнес-процессы и директор говорит: «да, мне уже все нравится, давай еще пробники проверим». И тут оказывается, что, несмотря на то, что я делал с этой компанией несколько систем и очень хорошо знаю ее процессы, у них есть такой уникальный процесс, который не «лег» на текущую архитектуру.

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

Другой пример – автотранспортное подразделение крупной нефтегазовой компании. Мы там автоматизировали механизм планирования:

• Расчет годовых планов;
• Календарное планирование;
• И уже непосредственно работу с заказ-нарядами в рамках тех лимитов, которые следуют из планов.

Особенностями проекта были:

• Большое количество транспортных средств.
• Большое количество вариантов расчетов планов – поставщики могли давать разные варианты предложений, и, соответственно, надо было подбирать те предложения, которые укладываются в лимиты.
• И еще большая особенность – параллельно с нашим проектом активно менялась архитектура основной системы.

Мы на этом проекте построили две модели: модель «как есть» и модель «как должно быть». Прописали все последовательности действий пользователей, какие документы и на каком этапе возникают. Выстроили архитектуру системы в целом – организовали для каждого пользователя именно то рабочее место, которое ему нужно. Но после запуска системы у нас возникло много проблем с одной обработкой, и мы на этом «топтались» несколько месяцев. Мы эту обработку переделывали, доделывали, исправляли ошибки. А всему виной было то, что мы неправильно выбрали объект метаданных. Если бы мы заранее построили модель метаданных, то наверняка бы увидели, что конкретно этот объект в каждодневной работе будет неудобен.

Зачем заниматься моделированием? Зачем тратить на него время?

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

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

Возникающие вопросы

Когда я только начал заниматься моделированием бизнес-процессов, я столкнулся с гигантским океаном информации, и у меня возникло много вопросов:

• Возможных нотаций описания очень много, но никаких сравнительных анализов по ним я на тот момент не нашел. Было непонятно, чем одна нотация лучше другой? Почему нужно использовать BPMN или IDEF, и как их использовать?
• Какой должна быть модель? Чем больше я занимаюсь построением моделей, тем больше я понимаю, что не всегда нужно рисовать схему. Это может быть текстовое описание, или, возможно, это будет какая-то комбинация нотаций: не только UML, а UML плюс что-то. Не столь важно, что рисовать, важно понимать, модель какого объекта мы хотим представить, хотим понять.
• Когда ко мне на собеседование приходят аналитики, мой любимый вопрос: «когда нужно готовить описание бизнес-процессов – до технического задания или после?» На это мне обычно отвечают, что должно быть две модели – «как есть» и «как должно быть», план перехода и прочие умные слова. Но по факту, на две модели в бюджете ресурсов никогда нет. И к тому же согласовать построение нескольких моделей очень трудно.
• К тому же, когда я только начинал заниматься моделированием, особенность наших проектов была в том, что они проводились на базе типовых конфигураций, и мне не всегда было понятно, а какие процессы рисовать? Как строить модель так, чтобы не перерисовывать все готовые процессы типовой конфигурации, но при этом, чтобы это было эффективно и понятно пользователю?

На все эти вопросы я постараюсь в статье ответить.

Теоретические аспекты моделирования

Итак, немного теории. Я уверен, что все это знают, но чтобы мы друг друга понимали одинаково, я напомню:

• Нотация – это набор символов и правил их использования для представления данных.
• Модель – это упрощенное представление некоторого объекта – чтобы лучше понять сложный объект, мы его упрощенно представляем и аналитически разбираем.
• Диаграмма – это уже конкретная схема, состоящая из набора геометрических фигур.

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

Чтобы проще это понять, можно представить, что:

• Модель – это система координат, по которой мы раскладываем наш объект.
• В нашем случае, объект – это наше предприятие, его информационная система и пользователи, которые эту информационную систему используют.
• А вот диаграмма – это уже проекция этого объекта на конкретную ось координат.

Какие проекции нам нужны?

• Очевидно, что нам нужна модель организационной структуры предприятия и верхнеуровневого состава его бизнес-процессов – такая модель очень хорошо помогает понять, что делает предприятие и чем оно занимается.
• Далее нам нужна модель бизнес-процессов и ролей пользователей, задействованных в этих бизнес-процессах. Модель ролей и профилей очень удобна для того, чтобы понять все действия пользователя в системе в рамках конкретных бизнес-процессов. На слайде еще указано, что нам будут нужны бизнес-правила. Что это такое – я чуть позже расскажу.
• Итогом всего этого является модель взаимосвязи метаданных и укрупненные схемы алгоритмов, отражающие все внесенные нами в конфигурацию изменения.

И все моделирование нашего объекта (нашего предприятия с его информационной системой и его пользователями) проводится в рамках выбранной нотации.

Выбор нотации для моделирования

С объектом мы определились. По каким проекциям мы будем раскладывать наш объект, мы также определились. Теперь нам нужно определиться с правилами взаимосвязи моделей между собой. Простой пример:

• Если в модели состава бизнес-процессов мы определили, что у предприятия есть процессы:
  • Продажи,
  • Закупки,
  • Финансы
  • И управление,
• Соответственно, на следующем уровне (в модели бизнес-процессов) у нас должно быть 4 диаграммы на каждый бизнес-процесс предприятия.

И уже после того, как мы определили:

• Объект, который мы моделируем;
• Модели – проекции, по которым мы его раскладываем;
• Правила взаимосвязи моделей;
• Только после этого имеет смысл переходить к выбору нотации для построения конкретной диаграммы.

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

• IDEF0;
• UML:UseCase;
• DFD;
• и еще масса вариантов.

Какой выбрать – решать вам. А я постараюсь объяснить, почему UML удобнее всего.

IDEF0

Итак, пройдемся вкратце по основным нотациям примерно в том порядке, в котором я их сам в свое время изучал и пытался применять. Это был период поиска, когда я сам лично строил эти модели, приносил их заказчикам и пытался объяснить, что они обозначают. Заказчики меня не понимали, я уходил, перерисовывал и приносил уже в другой нотации. Заказчики меня опять не понимали. Этот процесс был очень долгим, я вложил в него существенные деньги, но в результате выработал, как мне кажется, именно тот простой подход, который понятен и заказчикам, и разработчикам.

Первым делом мы рассмотрим диаграмму, построенную в нотации IDEF0. Похожа на микросхему. Обратите внимание, здесь:

• Квадратиками изображаются бизнес-процессы.
• Стрелочки слева – это входящие потоки.
• Стрелочки справа – исходящие потоки.

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

BPMN

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

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

DFD

Следующий пример – DFD. Это интересная, простая нотация, она легко понимается, на ней сразу видны взаимосвязи между бизнес-процессами, какими информационными потоками они обмениваются, какие информационные системы в процессах участвуют. Но, к сожалению, эта нотация сейчас незаслуженно забыта, и за последние 10 лет я на практике эти диаграммы ни разу не встречал.

ARIS <>EPC

Часто можно слышать про моделирование в нотации ARIS. Такое определение не совсем корректно, потому что ARIS – это не нотация, это целая методология, которая предполагает много представлений предприятия: организационная структура, функциональная структура и т.д. Эта методология реализована в соответствующем программном продукте, в котором наряду с другими нотациями используют EPC – это специальная нотация для построения диаграмм в системе ARIS.

Нотация EPC – очень неплохая, в ней получаются понятные бизнес-процессы. Единственное, что если бизнес-процесс чуть сложнее, чем «принял заказ» - «отгрузил товар», то он редко укладывается на A4. Я когда в этой нотации диаграммы делал, мне приходилось их как-то склеивать, складывать – получались большие бумаги.

UML

Давайте рассмотрим схему модели UML: Use Case. Что здесь изображено?

• Здесь изображено два участника бизнес-процесса – поросенок и волк, которые являются животными.
• Они участвуют в некоторых сценариях.
  • Например, поросенок участвует в сценарии «Строит дом». Что такое сценарий «Строит дом»? Это – съездить на рынок, купить материалов, спроектировать дом, построить его, протестировать на прочность и т.д. Фактически, это – бизнес-процесс.
  • Есть другой сценарий «Кушает», в котором участвует волк и поросенок. Для волка это, наверное, приятно, а для поросенка – не очень.

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

Вот так бы выглядела объектная модель UML сказки «Три поросенка». Обратите внимание, сколько информации несет одна только связь. Здесь мы видим, что один поросенок (это обозначает цифра «1» в начале связи) строит один дом. О том, что он «строит» дом, мы видим надпись на стрелке. Связь «один к одному». Каждый поросенок построил для себя один дом.

Язык UML – это унифицированный язык моделирования для разработки моделей на основе многих видов диаграмм, например:

• Диаграммы, которые показывают поведение;
• Диаграммы, которые показывают структуру;
• Диаграммы активности.
• Там даже есть диаграмма развертывания, чтобы показать, на каком узле, что будет исполняться.

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

• Первый критерий – это то, что диаграммы должны быть наглядными и простыми. Их должны понимать все люди, и понимать на таком уровне, что ты принес пользователю диаграмму и не объясняешь ему, что означает та или иная фигура, а обсуждаешь с ним предметно, что на этой диаграмме изображено. Диаграммы действительно должны помогать нам коммуницировать с пользователями.
• В нотации IDEF думать очень сложно. И рисовать, в общем-то, тоже непросто. Вы на бумаге диаграмму IDEF вряд ли сходу нарисуете. А диаграмму UML: Use case набросать на доске или на бумаге совсем не сложно, и это будет понятно.
• Конечно, было бы удобно, чтобы все модели можно было построить в рамках одной программы, чтобы не переключаться между разными окнами.
• А также, поскольку ни одна из этих нотаций явным образом не предназначена для 1С, нам так или иначе придется расширять ее нашими обозначениями. Поэтому хотелось бы, чтобы нотация гарантированно поддерживала расширение и инструменты, которые эту нотацию поддерживают, также были расширяемыми.

Применение UML на практическом примере

Начнем с диаграмм пакетов.

Есть определение, которое гласит, что диаграммы пакетов унифицированного языка моделирования UML отображают зависимости между пакетами, составляющими модель.

После его прочтения с UML можно было бы закончить, потому что ничего не понятно: как применить это к 1С – непонятно, какие пакеты в наших проектах возникают – тоже непонятно. Поэтому на определение мы внимания не обращаем, а смотрим, как это применяется на практике. Здесь и далее все диаграммы будут построены в программном продукте Enterprise Architect.

• В левом окне мы видим Project Browser – браузер модели, где представлены все элементы модели.
• А справа – диаграмма. В частности, здесь это – диаграмма оргструктуры. Вполне понятно, что нарисовано. Если у нас какая-то сложная оргструктура – подчиненные узлы подразделений можно убирать внутрь пакетов, и диаграмма все равно будет небольшая – будет вмещаться на одном листе А4.

Диаграмма состава бизнес-процессов.

• Посередине перечислены те бизнес-процессы, которые выполняются на предприятии.
• Слева – внутренние участники бизнес-процессов (сотрудники предприятия).
• Справа – внешние участники бизнес-процессов.

После того, как мы построили модель состава бизнес-процессов, мы переходим непосредственно к описанию каждого конкретного бизнес-процесса. Сложные бизнес-процессы удобно раскладывать сначала на макро-шаги, а потом уже делать детальное описание каждого шага. Обратите внимание, при построении модели в Project Browser мы также получаем очень удобную навигацию по модели: удобно переходить между бизнес-процессами и находить нужный шаг.

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

А справа мы видим детальное описание конкретного макро-шага бизнес-процесса:

• Мы здесь видим, кто выполняет бизнес-процесс.
• Видим, что он делает в рамках этого бизнес-процесса.
• Видим, что является входом для этого действия или что является результатом этого действия.
• И видим бизнес-правила, которые описывают, как он это делает.

Это такая блок-схема, которая разделена на дорожки. В таком виде бизнес-пользователи очень хорошо понимают бизнес-процессы. Не надо проводить никакого дополнительного обучения. Вы просто приносите им эту схему и спрашиваете: «Этот человек это делает?» Он отвечает: «Нет, не делает». Или говорит: «Да, делает, все правильно, иди дальше программируй».

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

Немного о бизнес-правилах. Бизнес-правила – это просто скрипт некоторого действия, он не персонифицирован.

Здесь на слайде как раз показан реальный пример такого скрипта – это разговор сервис-менеджера с клиентом. Обратите внимание, что на одном из шагов может запускаться новый бизнес-процесс. Это реальный пример из моей практики. Причем при составлении схемы этого бизнес-процесса мы пренебрегли правилом размещения не более семи элементов на диаграмме. Мы сделали столько элементов, сколько было удобно, сколько поместилось, и диаграмма все равно получилась понятной и читаемой благодаря тому, что она разделена на дорожки.

Модель ролей.

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

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

Мы с вами посмотрели, как можно построить орг. структуру, состав бизнес-процессов, сами бизнес-процессы, роли и  профили, и бизнес-правила. При этом и для бизнес-процессов, и для бизнес-правил мы использовали диаграммы UML:Activity. Но выглядели они по-разному, и это – нормально, UML допускает, что одинаковые диаграммы могут выглядеть по-разному, когда дополнены нужными нам элементами.

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

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

Но ни в коем случае не моделируйте всю конфигурацию, делайте модели только того, что вы меняете, чтобы новые люди, которые приходят, видели изменения типовой конфигурации. Модель типовой конфигурации ERP2 поставляется самой фирмой 1С на IDEF0, она входит в состав дистрибутива к ERP2. А нам важно понимать, что для типовой модели в рамках проекта нужно дополнить.

На слайде показана модель метаданных небольшой подсистемы «Управление предложениями».

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

Далее, после того, как мы построили модель метаданных, можно смоделировать алгоритм.

Все ли алгоритмы нужно моделировать? Нет, конечно. Делать модель алгоритма «Ввод на основании», не нужно, потому что программист и без этого напишет, что контрагент одного документа равен контрагенту другого документа. А вот, например, если у вас сложное проведение с множественным контролем остатков по разным регистрам и областям учета,  тогда имеет смысл все-таки построить модель алгоритма именно для проведения этого документа. Причем, используя опять же, инструмент Enterprise Architect у вас этот алгоритм с функцией проведения будет связан, и вы сможете, кликнув по этой функции, перейти к описанию алгоритма.

Модель алгоритма может выглядеть, как показано на слайде.

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

Как вы видите, с помощью UML мы построили полную нотацию для выполнения проекта на 1С. Причем используя только основные диаграммы, немного их модифицировав.

Требования и модели

Теперь несколько слов о требованиях.

• Требования – это будущая характеристика информационной системы. Техническое задание, которое мы пишем для клиента по ГОСТ 34, содержит требования.
• Модель – это упрощенное представление некоторого объекта.

Как между собой связаны требования и модель? Напрямую они не связаны. Модель показывает как будет выглядеть система, удовлетворяющая требованиям. И если посмотреть на расшифровку видов требований - то согласно ГОСТ34, там про модель ничего не сказано. Можем ли мы модель задокументировать в техническом задании? Если следовать ГОСТ - то, нет. Но если очень хочется, то можно.

Давайте разберем две ситуации.

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

Обращаемся к стандартам ГОСТ 34, по которому работают все крупные заказчики. Стандарт ГОСТ 34 предусматривает этап работ «Технический проект». Обратите внимание, «Технический проект» – это не документ, а этап работ. И в рамках этого этапа работ согласно ГОСТ34 есть документ, который подходит для документирования модели бизнес-процессов - "Описание автоматизируемых функций". А так как этап «Технический проект» – это вполне формализованный этап по  ГОСТ 34, то логично в его рамках модель системы задокументировать и утвердить у заказчика. С крупными заказчиками успешно проходит.

Другой вариант – когда заказчик вас нанимает и говорит: «Техническое задание будете делать вы, но никаких дополнительных документов я на проекте видеть не хочу, я хочу видеть только техническое задание». Лично сталкивался – мне была поставлена задача: «мне нужно техническое задание и все». Я выяснил аргументы того заказчика: опасения были в том, что пользователи привыкли к ТЗ и другие документы рассматривать и изучать не будут. Что в этом случае делать?

В этом случае можно поступить просто – вставить модель в техническое задание. Формально по ГОСТ34 так делать нельзя. Но когда очень хочется, то можно.

• В техническом задании есть «Раздел 2. Характеристика объектов автоматизации». Тут можно разместить состав бизнес-процессов и орг. структура.
• Также в техническом задании есть «Раздел 3. Требования к информационной системе». Вы их группируете по подсистемам, которые автоматизируете. И перед началом блока требований вставляете схему того бизнес-процесса, для которого эти требования были выработаны.

Мне никто ни разу не сказал, что у меня ТЗ не по ГОСТу. Всегда такой документ принимался. Пользователи видят эти схемы, им все понятно, и ТЗ становится понятнее.

Еще один вариант – это когда вы приходите к клиенту, и там не проект, а клиент просто хочет обработку. Например, изобрел какую-то уникальную схему заказа товаров, которую в УТ11 реализовать нельзя, и просит: «сделай мне ее этот отдельный блок».

В этом случае можно:

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

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

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

В общем случае так можно представить идеальный процесс управления моделями на предприятии.

• Сначала вы строите модель одного процесса (первый проект),
• А потом на основании следующего проекта дополняете эту модель.

Получается, что процесс моделирования – непрерывный. Вы им постоянно занимаетесь и органично вписали его в свой процесс.

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

Заключение

Перед тем, как строить модели, обратите внимание на особенности заказчика. Я лично сталкивался с людьми, которые не понимают схемы – они хотят вас слышать, им лучше принести ТЗ и рассказать его голосом. Это лучше выяснить до того, как вы начнете строить модели.

В заключение хочу сказать, что, по моему опыту, для построения моделей в проектах 1С удобнее всего использовать UML. Он решает насущные проблемы нахождения взаимопонимания с заказчиком и передачи информации в рамках проекта. А также позволяет снизить риски проектов – те риски, которые могут вскрыться на поздних стадиях и дорого обойтись.

Тема моделирования очень важна для повышения эффективности наших проектов, но, к сожалениию, в нашей отрасли пока не очень популярна. Давайте обсуждать эту тему. Если у вас есть какие-то примеры проектов, которые вы хотите обсудить, напишите мне, я с удовольствием подключусь.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.