Как рисовать для 1С бизнес-процессы, не забывая их главного участника

[ASenchenko]

Спасибо за статью, Юрий.

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

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

1. BPMN уже содержит многое из того, что вы описываете.
   Выделение «Системы» в отдельную дорожку - штатный механизм. Пулы и дорожки как раз предназначены для разделения ответственности между ролями, системами и подразделениями. Отправка сообщений между ними моделируется стандартными элементами (Message Flow), без необходимости вводить авторские «якоря».

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

3. Адаптация может привести к непониманию.
   Когда мы отступаем от стандарта осознанно и всей командой – это нормально. Мне на практике доводилось встречать минимум 3 кастомных версии BPMN.
   Но каждое такое отступление крайне желательно документировать, а дальше строго соблюдать, иначе через полгода-год даже автор схемы не вспомнит, чем «указание Системы» отличается от обычного потока управления. А недавно нанятый сотрудник - тем более, ему придётся проводить отдельный мини-курс по правилам чтения документов.
   Если команда регулярно решает одну и ту же задачу (например, документирует работу 1С в различных процессах), можно оформить набор допустимых расширений как внутренний профиль BPMN: зафиксировать цвета, шаблоны, правила. Можно даже частично «экспортировать» профиль из других нотаций, например из архимейта:
   «Бизнес» - желтый
   «Апликуха» - голубой
   «Системы» - зеленый
   Это сохранит преимущества стандарта, но даст гибкость.

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

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

P.S.

В качестве наглядной иллюстрации тезиса про адаптацию, я перевёл ключевую фразу этого комментария на болгарский:

«Нотацията е език за общуване... Адаптацията на езика... може да доведе до пълно неразбиране»

Для НЕ носителя языка текст выглядит почти как русский за счёт 100% совпадения алфавита и частичного совпадения словаря, но смысл считывается с трудом.

Это пример предельной «адаптации» - другой язык в рамках одного алфавита. Работает так же, как кастомизация нотации: вроде бы «всё те же квадратики, кружочки и стрелочки», но без знания легенды нет уверенности в понимании. А если легенда у каждого своя, то начинаются чудеса.