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

Публикация № 662084

Управление - Управление бизнес-процессами (BPM)

77
В статье я поделюсь с вами практикой применения UML для решения актуальных задач в области выполнения проектов на 1С. Когда мы с коллегами обсуждаем применение UML - я чаще всего слышу такое возражение: «как мы можем применять UML, если все современные среды для него не поддерживают кодогенерацию в 1С?» Как будто у нас уже все проектные технологии отлажены, с заказчиками нет никаких проблем, и только кодогенерации нам не хватает. Конечно же, это не так. В статье рассмотрим для чего нам необходимо моделирование и что это даст для повышения эффективности проектов.

Какие задачи можно решить с помощью 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 в 2016 году.

Больше статей можно прочитать здесь.
Приглашаем вас на новую конференцию INFOSTART EVENT 2019!

77

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. rusmil 179 04.09.17 06:18 Сейчас в теме
Очень хорошая статья, написано интересно, наглядно и доступно. Спасибо.
Deslime; D@y; user597616_i.d.kravchenko; SergeyN; +4 Ответить
2. Alex_grem 245 06.09.17 13:00 Сейчас в теме
Ещё бы файлик модели приложить...
3. immemor 08.09.17 11:45 Сейчас в теме
4. boln 999 08.09.17 12:20 Сейчас в теме
Плюсанул, едва прочитав. Давно назревший разговор, независимо от того, насколько хороша статья.
5. Evgen.Ponomarenko 541 10.09.17 21:23 Сейчас в теме
Хорошая, правильная статья. Как раз принимаю участие в проекте по кодогенерации для целей IoT. Первые рабочие прототипы были написаны на 1С. Так, что генерация кода 1С средствами 1С - пройденный этап. Тем более, что тема моделирования мне очень близка см. https://infostart.ru/public/285811/ Надеюсь на продолжение беседы.
6. ifilll 15.09.17 16:24 Сейчас в теме
Кроме UML ничего не использовал, IDEF0 откровенно пугает, очень сложно воспринимается.
Спасибо, расширили кругозор.
7. boln 999 13.11.17 16:59 Сейчас в теме
Вопрос автору.

Есть ли средство в UML компактно отобразить наследование от предопределенного абстрактного класса? Например, для документа "Приходная накладная" не громоздить стрелку наследования от абстрактного класса "Документ", а изобразить как-то попроще, что "Приходная накладная" есть "Документ"?
8. amaksimov 12.09.18 14:30 Сейчас в теме
(7) может в названии задействовать , типо Документ::Приходная накладная
9. boln 999 12.09.18 15:08 Сейчас в теме
(8)
может в названии задействовать , типо Документ::Приходная накладная
Хорошая идея. Только тогда нужно прописывать в примечаниях к диаграмме, что это означает.
А стандартно-документированной нотации, как я понимаю, нет? Задавал этот же вопрос на UML-форумах, ответа не получил.

Только я бы предпочел использовать не C++, а Java-нотацию: ПриходнаяНакладная extends Документ :)
amaksimov; +1 Ответить
10. SergeyN 622 09.09.19 11:47 Сейчас в теме
(9) Еще вариант поместить в package: будет отображаться ПриходнаяНакладная (from Документы)
Оставьте свое сообщение

См. также

Как создать идеальную службу поддержки бизнеса 5

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Бухгалтерский учет

О том, насколько хорошо работают бизнес-процессы, можно понять по реакции пользователей: если они довольны - значит, все хорошо. А что является главным связывающим звеном между бизнесом и пользователями? Конечно, служба поддержки, и чем лучше вы организуете ее работу, тем удовлетворенность пользователей будет выше. О том, что как создать идеальную службу поддержки, на конференции INFOSTART EVENT 2018 Education рассказал Сергей Харитонов из ГК «Агат».

26.07.2019    1619    user1063453    0       

Как привлечь пользователей на портал самообслуживания 7

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

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

09.06.2019    1931    KoldunOne    6       

Уволен через автоматизацию 46

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Кейс бизнес-программирования

07.03.2019    7350    1c-intelligence    47       

Механизм бизнес-событий на конкретном примере 29

Статья Программист Нет файла v8::Бизнес-процессы ДО Россия УУ Документооборот и делопроизводство Бесплатно (free) Управление бизнес-процессами (BPM)

Есть в системе 1С:Документооборот механизм бизнес-событий. Когда мне понадобилось решить конкретную задачу, гугление ни к чему конкретному не привело. Хотелось так «вжух» и всё понять про данный механизм, но в итоге пришлось лезть в код 1С и смотреть реализацию данного механизма. В данной публикации поделюсь результатами исследований, может, кому-то это поможет быстро и легко во всём разобраться.

18.02.2019    4836    soulner    0       

Принципы проектирования справочников номенклатуры в 1С: Управление Предприятием 2 (ERP 2.4.6) 69

Статья Программист Пользователь Нет файла v8 ERP2 Россия Бесплатно (free) Управление бизнес-процессами (BPM) Бухгалтерский учет Пользователю системы

Принципы системного подхода к проектированию справочников номенклатуры в 1С: Управление Предприятием 2 (ERP 2.4.6) или как избежать замусоривания.

13.02.2019    10042    roman72    20       

Практика применения подсистемы Автозадачи 25

Статья Программист Нет файла v8 1cv8.cf Россия УУ Бесплатно (free) Пользователю системы Управление бизнес-процессами (BPM)

На Инфостарте есть публикация о подсистеме Автозадачи (https://infostart.ru/public/656758/). Я решил поделить своим опытом применения этой подсистемы Альфа-авто 5.

29.01.2019    4325    AntonSm    4       

Где мы взяли флакон? 38

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

История появления и развития методики

26.12.2018    6145    1c-intelligence    7       

Айсберг, кейсы 25

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Несколько примеров применения принципа "Айсберг".

26.12.2018    4768    1c-intelligence    12       

Методология управления изменениями на основе методологии TOGAF и языка моделирования Archimate 9

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

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

02.12.2018    4530    rossoxa    2       

Обзор блока адресного хранения в программах 1С: УТ, ERP и КА 34

Статья Бизнес-аналитик Руководитель проекта Нет файла v8 ERP2 УТ11 КА2 Россия УУ Учет ТМЦ Бесплатно (free) Управление бизнес-процессами (BPM) Бухгалтерский учет

В статье мы подробно расскажем вам, как реализовано адресное хранение в типовых решениях 1С:Управление торговлей, 1С:ERP и 1С:Комплексная автоматизация.

29.11.2018    10840    alis112358    22       

Похороны скрам-доски 19

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Личная эффективность

Продолжаем балансировать позитив Марии Темчиной. Вторая глава книги про американцев.

31.10.2018    6367    1c-intelligence    15       

Ограничения и недостатки производственного учёта в 1С: УНФ 40

Статья no Нет файла v8 УНФ УУ Производство готовой продукции (работ, услуг) Бесплатно (free) Управление бизнес-процессами (BPM) Бухгалтерский учет Производство

У любого программного продукта (и не только программного, да и не только у продукта) существуют свои сильные и слабые стороны. О многих сильных сторонах 1С: УНФ (Управление нашей фирмой) я писал и снимал обучающие видеоролики. Мне действительно нравится данная программа в силу сочетания функциональности и простоты учёта. Но давайте объективно коснёмся недостатков 1С: УНФ при внедрении на производственных предприятиях. Но сначала про…

30.10.2018    11530    Gavrik    22       

Цифровая трансформация. 3

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Цифровая трансформация. Что это и как мы можем помочь нашим клиентам?

21.08.2018    3551    -DenA-    4       

Принцип "Айсберг" 29

Статья Программист Пользователь Руководитель проекта Нет файла УУ Бесплатно (free) Управление бизнес-процессами (BPM)

Простой принцип, который стоит учитывать при автоматизации.

16.08.2018    9046    1c-intelligence    23       

На чьей стороне мячик? Алгоритм определения исполнителя задачи 5

Статья no Нет файла Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM)

Я считаю, что мало кому удалось избежать ситуации, когда его назначали исполнителем работы, мягко скажем, не его уровня. На мой взгляд, такое особенно часто встречается среди технических специалистов. Причем, в случае возражения, обычным аргументом противоположной стороны является: "Нам так раньше всегда делали!". Эта публикация является попыткой описать формализовано процесс определения исполнителя с точки зрения логики. Посвящается тем, кто, будучи невежественным в вопросе, смеет указывать, кому его решать. А также тем, кто это терпит.

14.08.2018    4897    itriot11    42       

Автоматизация контроля границ 25

Статья Программист Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Продолжаем изучение учебника по бизнес-программированию. На этот раз - параграф из раздела "Автоматизация".

08.08.2018    7104    1c-intelligence    18       

Канбан в условиях российской действительности 71

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Россия Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

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

08.08.2018    14704    MariaTemchina    63       

Миф о всесильном менеджере 15

Статья Программист Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Не будем заниматься изменениями, потому что мы - не менеджеры.

05.07.2018    6979    1c-intelligence    1       

Эсперанто, эльфийский и клингонский 30

Статья no Нет файла Бесплатно (free) О жизни Управление бизнес-процессами (BPM) Личная эффективность

Почему бизнес и ИТ не понимают друг друга? И как сделать, чтобы понимали?

14.06.2018    9469    1c-intelligence    47       

Продукт vs Процесс 26

Статья Программист Пользователь Руководитель проекта Нет файла УУ Бесплатно (free) Управление бизнес-процессами (BPM)

Продолжаем тему управления качеством, рассматривая ключевой акцент - продукт или процесс?

08.06.2018    9563    1c-intelligence    40       

Экспансия решений 1С на глобальный рынок: как взять быстрый старт? 42

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

Николай Шилкин рассказал о требованиях, которые предъявляет глобальный рынок к решениям 1С, рассмотрел достоинства и недостатки платформы в контексте ее выхода за пределы рынка стран СНГ. Он также объяснил, у каких решений есть шансы добиться успеха на мировом рынке, и дал рекомендации 1С-стартаперам.

04.06.2018    9260    RayCon    21       

Золотой франч. Часть 1 34

Статья Программист Пользователь Руководитель проекта Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление бизнес-процессами (BPM)

Попробуем сформировать кейс для конкретной части знакомого нам бизнеса – 1С:Франчайзи.

22.05.2018    11142    1c-intelligence    61       

Регулярные задачи 20

Статья Программист Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Личная эффективность

Регулярные задачи и регулярный менеджмент, как инструмент работы над изменениями. Варианты, проблемы, решения.

17.05.2018    9041    1c-intelligence    5       

Жизненный цикл задачи 40

Статья Программист Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Личная эффективность

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

15.05.2018    11677    1c-intelligence    16       

Почему менеджеры не изменяют? 27

Статья Пользователь Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Почему менеджеры не занимаются изменениями? А если занимаются, то ничего не получается?

10.05.2018    10569    1c-intelligence    32       

Менеджер vs Программист 24

Статья Программист Пользователь Руководитель проекта Нет файла Бесплатно (free) О жизни Управление бизнес-процессами (BPM)

Что общего между менеджером и программистом? И в чем различие?

07.05.2018    10404    1c-intelligence    57       

Первый шаг к успешному проекту автоматизации 11

Статья no Нет файла Россия Бесплатно (free) Техническое задание Управление бизнес-процессами (BPM) Управление проектом

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

30.03.2018    7947    Апрель-С    1       

Автоматизация для "полевых" сотрудников (тех, кто не работает в офисе) 42

Статья Программист Руководитель проекта Нет файла v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса УУ Учет рабочего времени Бесплатно (free) Управление бизнес-процессами (BPM)

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

24.01.2018    12089    siddy    0       

Ад своими руками 240

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Почему не надо внедрять системы управления задачами

28.12.2017    35678    1c-intelligence    179       

Внутренние бизнес-процессы 22

Статья no Нет файла v8::Бизнес-процессы 1cv8.cf УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Управление бизнес-процессами (BPM)

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

20.12.2017    11402    siddy    0       

Латентные паразиты 136

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

Вот вы сидите, и не думаете о паразитах. А они рядом.

04.12.2017    23130    1c-intelligence    143       

Куда дальше? 80

Статья Программист Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

1С умеем, бизнес-процессы умеем, системы мотивации умеем, ТОС умеем, Scrum умеем... Чего не умеем?

17.10.2017    21856    1c-intelligence    278       

Контроллинг и системное мышление: примитивный пример 31

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

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

17.08.2017    17193    1c-intelligence    110       

Практический пример автоматизации производства в 1С: УНФ 31

Статья Программист Бизнес-аналитик Нет файла v8 УНФ УУ Производство готовой продукции (работ, услуг) Бесплатно (free) Пользователю системы Управление бизнес-процессами (BPM) Бухгалтерский учет

Конфигурация 1C:УНФ обладает явным преимуществом для небольших предприятий по сравнению с другими программными продуктами семейства 1С. Это лёгкость использования с отсутствием изобилия функционала, в котором теряются многие пользователи, которым представлено УТ, КА, не говоря про ERP. Другими словами, ничего лишнего. Это большой плюс, если нет бюрократии и сложных методик в организации.

31.07.2017    23331    Gavrik    13       

Использование GAP-анализа для выявления и согласования задач по проекту 5

Статья Программист Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

Данная статья размещена здесь для тех, кто хочет знать больше про GAP анализ и как его использовать на проекте. Так как формат статьи не позволяет рассказать все, я постарался рассказать основное по этой теме. Больше, если получится, я расскажу на Event 2017, если мой доклад наберет достаточное количество голоcов. Ссылка на доклад http://event.infostart.ru/2017/agenda/#item643129

05.07.2017    10270    raiml    0       

Внедрение автоматизированной системы управления работами в сервисной компании 15

Статья Пользователь Нет файла v8 ERP2 1С:Франчайзи, автоматизация бизнеса Россия УУ Производство готовой продукции (работ, услуг) Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

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

29.06.2017    9948    Soliton    2       

IDEF0. Знакомство с нотацией и пример использования 43

Статья Бизнес-аналитик Пользователь Нет файла Обучение, бизнес-тренинг, курсы 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление бизнес-процессами (BPM)

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

28.06.2017    24079    raiml    36       

Краткое описание BPMN с примером 49

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM)

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

28.06.2017    23565    raiml    10       

Запуск систем без тестовой эксплуатации 2

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

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

30.05.2017    10763    Gavrik    1