Не дублировать роли вручную: связь задач BPMN с должностями 1С

 Должности уже есть в 1С

В компаниях с кадровым контуром актуальные должности обычно уже хранятся в 1С. Это может быть ERP, УНФ, ЗУП или другая информационная база, из которой кадровые данные поступают по обмену.

Справочник "Должности" в 1С:Бухгалтерия

При описании процессов ту же информацию часто вводят повторно: аналитик вручную пишет «Менеджер», «Кладовщик» или «Руководитель отдела продаж» в названии задачи, дорожке либо комментарии.

В Схемопоинт 1.0.1 должность можно выбрать непосредственно из справочника 1С и связать с задачей BPMN.

Проблема ручных подписей

Текстовая роль на схеме не связана с данными информационной базы. Для 1С слова «Менеджер по продажам» остаются обычным текстом.

Из-за этого возникают два независимых источника информации:

• в кадровом контуре — справочник должностей;

• в BPMN-схемах — вручную введённые наименования.

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

Что изменилось в релизе 1.0.1

Теперь для BPMN-задачи можно выбрать один элемент справочника Должности.

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

Название самой задачи при этом остаётся независимым. Например:

• действие — «Проверить условия оплаты»;

• связанная должность — «Специалист по расчётам».

Должность хранится как ссылка на элемент справочника, а не как часть названия задачи или произвольный комментарий. В BPMN XML служебная информация о связи не записывается.

Пример: выполнение заказа клиента

В процессе выполнения заказа ответственность можно зафиксировать на уровне отдельных действий:

Задача BPMN	Должность из 1С
Принять и проверить заказ	Менеджер по продажам
Проверить условия оплаты	Специалист по расчётам
Согласовать нестандартную скидку	Генеральный директор
Подготовить товар к отгрузке	Кладовщик

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

Границы текущей реализации

Связь с должностью в версии 1.0.1 доступна для BPMN-задач.

Она не назначает работу конкретному сотруднику, не создаёт задания и не запускает маршрут согласования. Это инструмент описания ответственности, а не исполнения процесса.

Вывод

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

Действия описываются на схеме, а должности выбираются из тех данных, которые уже используются в 1С. Это уменьшает дублирование информации и создаёт основу для дальнейшей связи процессных моделей с организационной структурой компании.

Нотация BPMN 2.0 в Схемопоинт

 

Что такое нотация BPMN 2.0 и как она помогает смоделировать бизнес-процесс

Прежде чем улучшать рабочие процессы, нужно построить их модели. Сделать это можно с помощью специального инструмента — нотации BPMN 2.0.

Что такое нотация BPMN

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

Если организация небольшая, зафиксировать изменения в процессах несложно. Иногда достаточно обсудить их с коллегами. В крупных компаниях процессы часто запутанные, поэтому нужно проводить моделирование — описание процессов.

Бизнес-процесс можно описать разными способами. Например, составить подробный текстовый документ, собрать всю информацию в таблицу или изобразить его в диаграмме — для их создания используют специальный набор правил и символов для изображения разных элементов процесса. Такие наборы называются нотациями. В бизнес-аналитике используют разные нотации, например: IDEF0, EPC, блок-схемы.

Для сложных процессов с большим количеством исполнителей подходит BPMN 2.0 (от англ. Business Process Model and Notation) — на сегодняшний день одна из самых популярных нотаций.

Преимущества нотации BPMN

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

• Возможность разделить исполнителей

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

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

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

• Возможность графически представить развилки процесса

Развилки в процессе, или точки принятия решений, — это точки, в которых движение процесса меняется в зависимости от действий участников.

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

В точках принятия решений может происходить не только ветвление процесса, но и слияние нескольких веток в одну.

Использование нотации BPMN в бизнес-аналитике

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

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

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

Ещё модель процесса в нотации BPMN 2.0 можно упростить — оставить на схеме основные элементы без дополнительных символов для их детализации. Тогда модель можно использовать как инструкцию по работе с ПО для конечных пользователей.

Построение модели бизнес-процесса с помощью BPMN: основные элементы и алгоритм

Нотации для графического изображения процессов состоят из определённых элементов. Разберём подробнее элементы BPMN 2.0 в том порядке, в котором их обычно размещают на схеме:

1. Пул (от англ. pool — бассейн)
Область, в которой описывают процесс. Построение модели процесса начинают с пула. Если в процессе участвуют сторонние организации — для каждой рисуют отдельный пул.

Пул обозначает границы процесса, внутри него размещают остальные элементы

2. Дорожки (от англ. swimlane — дорожки для плавания)
Это элемент для изображения исполнителей процесса. Если пул — это организация, то дорожки — подразделения или отделы этой организации, которые участвуют в процессе.

Дорожки разделяют пул. Так на схеме процесса чётко видны зоны ответственности исполнителей

3. Действия или задачи
Каждый исполнитель выполняет свои задачи. Например, заказ обрабатывают сотрудники отдела продаж, склада и доставки. Первые принимают заказ, вторые собирают, третьи — доставляют покупателю.

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

Маркеры указывают на характер действия, которое нужно выполнить. На диаграммах BPMN 2.0 часто можно увидеть такие маркеры:

• Подпроцесс. Указывает, что внутри одного действия есть вложенный процесс с набором других действий. Если не всем читателям диаграммы интересны детали вложенного процесса, можно не утяжелять диаграмму, а добавить символ «квадрат с плюсом».
• Цикл. Используют, чтобы обозначить регулярное действие с одними и теми же данными. Например, попытки регистрации на рейс одного пассажира. Исполнитель вводит одни и те же данные, пока регистрация не пройдёт успешно.
• Параллельные и последовательные процессы. Параллельные действия — одни те же действия, которые выполняют разные сотрудники. Например, несколько человек регистрируют на рейс разных пассажиров. Последовательные действия совершает один исполнитель друг за другом. Например, по очереди регистрирует на рейс несколько пассажиров.

Кроме маркеров действий в нотации BPMN 2.0 есть символы для обозначения типовых задач. Например: отправка или получение сообщения, задача со сроком. Эти символы не обязательны — тип задачи можно прописать и текстом.

4. События
Всё, что происходит в рамках процесса, отмечают на диаграмме в виде круга. Событие отличается от действия тем, что действие подразумевает активность исполнителя, а событие — случившийся факт. Например, «внести заявку в базу» — действие, а «письмо получено» — событие. Выделяют три ключевых вида событий:

• Стартовое — то, с чего начинается любой процесс. Например, получена заявка с сайта на обратный звонок. На диаграмме стартовое событие обозначают кругом с тонкой линией ободка. В нотации BPMN 2.0 любой процесс в каждом пуле всегда начинается с события и никогда — с действия.
• Конечное — то, чем заканчивается процесс. Например, договор подписан. На схеме событие отмечают кругом с жирной линией ободка.
• Промежуточное — всё, что происходит по ходу процесса. Например, получен ответ на коммерческое предложение, согласован договор. Промежуточные события обозначают кругом с двойным ободком.

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

5. Точки принятия решений
В нотации BPMN 2.0 точки принятия решений также называют логическими операторами или шлюзами. Это точки, в которых процесс разветвляется на несколько потоков или несколько потоков процесса сливаются в один.

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

Всего выделяют три типа операторов:

• Эксклюзивный шлюз, или «строгое ИЛИ», обозначает, что дальше процесс может пойти только по одному из направлений. Обычно задаётся условие, например, оплатил клиент заказ или нет.
• Неэксклюзивный шлюз, или «нестрогое ИЛИ», указывает, что процесс может пойти по нескольким путям, но не обязательно по всем сразу. Например, пользователь оформляет на сайте доставку с самовывозом из пункта выдачи заказов. И оставляет контактные данные: номер телефона, адрес в мессенджере, email. От того, какие способы связи укажет пользователь, зависит способ отправки уведомления о том, что посылку можно забирать. Это может быть СМС-сообщение, письмо на электронную почту, сообщение в мессенджере, или все три способа сразу. Это универсальный шлюз, после которого процесс может пойти по разным направлениям.
• Параллельный шлюз используют для ветвления или слияния потоков процесса. Если это шлюз ветвления, дальше обязательно должно произойти несколько событий. Если шлюз слияния, процесс двинется дальше, только когда завершатся несколько параллельных действий. Например, чтобы отправить договор на подпись подрядчику, его обязательно должны согласовать юридический отдел, бухгалтерия и генеральный директор.

Один логический оператор не может одновременно разветвлять и соединять потоки процесса — только одно из двух

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

Есть несколько дополнительных обозначений связей, которые упрощают чтение диаграммы:

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

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

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

Такой тип связи называют поток сообщений — обмен данными между участниками процесса

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

Вот такие символы используют для обозначения артефактов на диаграмме в нотации BPMN 2.0

Прежде чем автоматизировать: нарисуйте путь заявки

Бизнес процессы и рост компании

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

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

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

• клиенту обещали срок до проверки возможности выполнения;

• заявку не передали исполнителю или передали без важной информации;

• расчёт, счёт и фактические условия расходятся;

• одни и те же данные вводятся в 1С, Excel и переписку;

• собственник узнаёт о проблеме, когда клиент уже ждёт ответ.

Проблема не обязательно в 1С или в сотрудниках. Часто компания просто не видит процесс целиком.

Сначала увидеть путь заявки

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

Не регламент на двадцать страниц, а простую схему с ответом на несколько вопросов:

• откуда приходит заявка;

• кто и на основании чего делает расчёт;

• кто подтверждает срок;

• кому и как передают работу;

• где фиксируется результат;

• в каких точках нужно проверить, что заявка не потерялась.

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

Что становится заметно на схеме

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

Например, расчёт может выполняться до проверки остатка или загрузки исполнителей. Заказ может считаться «переданным», хотя информация остаётся только в чате. Условия клиента могут существовать в переписке, а в 1С появляется лишь итоговый счёт.

Это не означает, что нужно немедленно менять всё. Но появляется основа для разумного выбора:

• какую операцию можно закрепить за конкретной ролью;

• что стоит фиксировать в 1С;

• где достаточно контрольной точки;

• какие данные не нужно вводить повторно;

• какую доработку действительно имеет смысл заказывать.

Автоматизация становится предметной

Фраза «нужно автоматизировать работу с заявками» слишком общая. После схемы разговор меняется.

Можно обсуждать конкретно:

• проверку срока до обещания клиенту;

• передачу заявки на исполнение;

• единое место для статуса заказа;

• контроль неполных данных;

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

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

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

Подробнее о Схемопоинте: https://www.schemopoint.net

Схемопоинт 1.0.0. Один процесс — несколько BPMN-схем

Один процесс — несколько BPMN-схем: что изменилось в Схемопоинт 1.0.0

В реальном проекте одна BPMN-схема быстро начинает выполнять несколько разных задач.

На первой встрече она фиксирует предварительное понимание процесса. После обсуждения превращается в согласованную основную схему. Затем аналитик добавляет детали для разработки: объекты 1С, ИТ-системы, данные и исключения. Параллельно появляется схема будущего процесса — каким он должен стать после автоматизации.

Если всё это поместить в одну диаграмму, она становится перегруженной. Если разнести по отдельным файлам, теряется связь с самим процессом: непонятно, какая схема основная, где актуальная детализация и к какому процессу относится очередной файл Процесс_финал_2.bpmn.

В версии 1.0.0 в Схемопоинте разделены две сущности:

• процесс — управленческая карточка;

• схема — отдельное BPMN-представление этого процесса.

Теперь один процесс может иметь основную и несколько дополнительных схем, которые хранятся и открываются непосредственно в 1С.

Один процесс — четыре разных представления

Предварительная схема

Создаётся во время первичного обследования. В ней фиксируется текущее понимание процесса: основные участники, действия, точки передачи ответственности и обнаруженные проблемы.

Такая схема ещё может быть неполной. Её задача — сделать предмет обсуждения видимым и помочь аналитику задавать точные вопросы.

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

Основная схема

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

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

• где начинается и заканчивается ответственность подразделения;

• кто отвечает за ключевые этапы;

• где принимаются решения;

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

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

Расширенная схема для ИТ

В этой схеме тот же процесс рассматривается с точки зрения автоматизации.

Здесь можно подробнее показать:

• документы, справочники и регистры 1С;

• используемые ИТ-системы и хранилища данных;

• интеграции;

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

Схема будущих улучшений

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

Так руководитель видит предполагаемый организационный результат, а аналитик может детализировать будущую автоматизацию.

Что изменилось в Схемопоинте 1.0.0

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

В версии 1.0.0 схема стала самостоятельным объектом.

Карточка процесса хранит устойчивую управленческую информацию:

• наименование;

• тип процесса;

• владельца;

• статус;

• состояние описания;

• описание;

• ссылку на основную схему.

Каждая BPMN-схема хранится отдельно и принадлежит определённому процессу. Процесс может иметь одну основную и несколько дополнительных схем.

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

BPMN-элементы также относятся к конкретной схеме. Поэтому одинаковые идентификаторы элементов в разных схемах больше не смешиваются при хранении и формировании отчётов.

Что получает бизнес-аналитик

Главная выгода для аналитика — возможность разделять содержание по назначению, не теряя контекст процесса.

Можно сохранить промежуточный результат

Предварительную схему не требуется немедленно превращать в окончательную. Её можно сохранить как отдельное представление, продолжить обсуждение и параллельно подготовить основную схему.

Можно разделить бизнес- и техническую детализацию

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

Можно моделировать изменения отдельно

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

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

Можно работать без набора внешних файлов

Схемы хранятся непосредственно в 1С. Их не нужно распределять между локальными папками, Miro, Draw.io и перепиской с участниками проекта.

Что получает функциональный руководитель

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

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

Это позволяет разделить разные вопросы:

• Как процесс работает в целом? — основная схема.

• Что происходит на конкретном участке? — детализированная схема.

• Какие системы и данные используются? — расширенная схема для ИТ.

• Что должно измениться? — схема будущего процесса.

В результате руководитель и аналитик работают с одним процессом, но получают представление, соответствующее своей задаче.

Отчёты теперь учитывают схемы

Разделение затронуло не только редактор, но и отчётность.

Отчёты по BPMN-элементам, объектам 1С и связанным ИТ-системам теперь могут использовать отборы по процессу и конкретной схеме.

Это важно, когда у процесса несколько представлений. Например, объект 1С может использоваться только в расширенной технической схеме и отсутствовать в основной. Без разделения такой результат было бы трудно интерпретировать: непонятно, в какой именно диаграмме находится элемент и почему он появился в отчёте.

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

Границы версии 1.0.0

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

В текущую версию не входят:

• специальные статусы схем;

• встроенные типы AS-IS и TO-BE;

• автоматическое сравнение схем;

• согласование и публикация;

• история версий отдельных схем;

• копирование схем;

• автоматическое выполнение процессов.

Эти функции требуют отдельной логики. В 1.0.0 решена базовая задача: процесс и его BPMN-представления больше не являются одним объектом.

Скачать Схемопоинт 1.0.0

Основная версия Схемопоинта 1.0.0 доступна на GitHub.

Написать автору или сообщить об ошибке можно непосредственно через раздел «Обратная связь» в Схемопоинте.

 

Ошибки в заказах повторяются. Какие процессы описывать первыми?

От повторяющихся ошибок — к реестру процессов

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

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

Рассмотрим торговую компанию с собственным складом. Задача коммерческого директора — структурировать процессы выполнения заказов и описать первый проблемный участок.

Собрать реестр коммерческого блока

Для первого прохода определим пять процессов. По каждому зафиксируем тип, владельца и состояние описания. Ниже — условный пример заполнения.

Тип	Процесс	Владелец	Состояние описания
Управляющий	Планирование и контроль продаж	Коммерческий директор	Актуально
Основной	Обработка обращения и подготовка предложения	Коммерческий директор	Актуально
Основной	Согласование заказа и подтверждение срока	Коммерческий директор	Требует актуализации
Основной	Выполнение заказа: комплектация и отгрузка	Коммерческий директор	Не определено
Вспомогательный	Поддержание данных о товарах и клиентах	Коммерческий директор	Черновик

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

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

Найти пробелы средствами «Схемопоинта»

В реестре «Схемопоинта» используются отборы по типу процесса, владельцу и состоянию описания. Для разбора заказов выбираем основные процессы коммерческого директора и последовательно просматриваем те, которые требуют актуализации, находятся в черновике или ещё не оценены.

Схемопоинт. реестр процессов с колонками «Тип», «Владелец», «Состояние описания» и установленными отборами.

Состояния описания помогают разделить следующие действия:

Состояние в карточке	Что проверить или сделать
Не определено	Найти существующие описания и оценить, охватывают ли они процесс
Черновик	Завершить описание и проверить его с участниками
Требует актуализации	Выявить изменения в работе и внести их в описание
Актуально	Использовать проверенное описание; при изменении процесса пересмотреть его

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

В нашем примере отборы выделяют два связанных участка: согласование заказа и его выполнение. У первого описание требует актуализации, у второго состояние ещё не определено. С учётом ошибок комплектации и переноса сроков именно их выбираем для первого разбора.

В текстовом описании карточки можно зафиксировать обнаруженный пробел: «Не определён порядок подтверждения срока складом и проверки комплекта перед отгрузкой». Так у записи появляется конкретное основание для дальнейшей работы.

Одна схема для начала

Первой схемой коммерческий директор разбирает выполнение заказа вместе с менеджером и руководителем склада. На схеме достаточно показать ключевые передачи работы и решения:

1. Менеджер фиксирует согласованный состав заказа.

2. Ответственный проверяет наличие товара и возможность комплектации.

3. Клиенту подтверждают срок на основании этой проверки.

4. Склад получает задание и комплектует заказ.

5. Перед отгрузкой состав комплекта сверяют с заказом.

6. При расхождении определяют, кто исправляет заказ и кто сообщает клиенту новый срок.

Для проверки стыка процессов на схеме показаны и предшествующие действия — согласование состава и срока.

Ценность обсуждения возникает в конкретных вопросах. Может ли менеджер обещать дату до подтверждения склада? Из какого документа склад получает состав заказа? Кто вправе заменить товар? На каком этапе и кем выполняется сверка комплекта?

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

Что получает директор

После первого прохода у директора есть короткий перечень решений:

• подтвердить владельца процесса выполнения заказа и его полномочия;

• согласовать правило подтверждения срока клиенту;

• определить, кто сверяет комплект перед отгрузкой;

• обновить описание согласования заказа;

• после проверки изменить состояния описания в реестре.

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

Соберите первый реестр в своей базе

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

Бесплатное расширение и описание установки доступны  здесь  , в разделе «Файлы».

После установки:

1. Добавьте пять процессов своего подразделения.

2. Укажите их типы и владельцев.

3. Оцените состояние существующих описаний.

4. Через отборы выберите процессы с пробелами.

5. Создайте первую схему для процесса, в котором повторяются ошибки.

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

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

Релиз 0.0.8 Идея и реализация

 

Задача и принятое решение

В Схемопоинте отсутствовал пользовательский инструмент назначения цвета BPMN-элементам. Требовалось добавить визуальное выделение элементов, сохранив читаемость схемы и минимальный объём изменений.

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

Реализована компактная палитра из семи согласованных цветов и команды «Без цвета», расположенная над выбранным элементом. Применение цвета выполняется штатным API bpmn-js.

Пользовательское поведение (требования)

• Палитра появляется при выборе одного поддерживаемого BPMN-элемента.
• Нажатие цвета немедленно изменяет заливку фигуры.
• Контур фигуры, внутренние и внешние подписи становятся чёрными.
• Для дорожек применяется более светлый вариант выбранного оттенка.
• «Без цвета» снимает пользовательскую заливку, сохраняя чёрные контур и текст.
• При снятии выделения, выборе нескольких элементов или загрузке другой схемы палитра скрывается.
• Для потоков, соединений и отдельно выделенных подписей палитра не отображается.
• Изменения сохраняются по существующей команде 1С «Записать».

Окрашивание доступно для задач, событий, шлюзов, дорожек, Data Object, Data Store, подпроцессов и Call Activity. Пулы в текущую реализацию не включены.

Цветам не назначена обязательная бизнес-семантика: пользователь самостоятельно определяет их значение.

Палитра и оформление дорожек

Цвет	Обычные фигуры	Дорожки
Голубой	#B8DAF5	#DCEDFA
Зелёный	#C5E4B5	#E2F2DA
Жёлтый	#F7E39A	#FBF1CD
Персиковый	#F5C7A5	#FAE3D2
Розовый	#F0BBC9	#F8DDE4
Сиреневый	#D5C1EE	#EAE0F7
Серый	#D5DEE5	#EAEFF2

Для дорожек оттенки осветлены примерно наполовину белым. Дополнительно используется штатная отрисовка bpmn-js 18.16.1: непрозрачность заливки дорожек — 0.25, задач — 0.95.

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

Отдельные полупрозрачные rgba-цвета не используются: штатный setColor() этой версии не принимает цвета с альфа-каналом меньше единицы. В XML сохраняются обычные HEX-цвета.

Взаимодействие 1С, HTML и JavaScript

Этап	Реализация
Выбор элемента	Существующее событие selection.changed определяет выбранную фигуру
Показ палитры	Сервис overlays размещает HTML-палитру над элементом
Назначение цвета	modeling.setColor() задаёт заливку и чёрный контур
Цвет подписи	При наличии отдельного объекта di.label его цвет устанавливается через modeling.updateModdleProperties()
Запись процесса	Существующий modeler.saveXML() формирует XML с оформлением
Повторное открытие и импорт	Существующий modeler.importXML() восстанавливает оформление

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

Цвет хранится в графических данных BPMN XML. Отдельное хранение цветов в 1С не требуется.

Изменённые файлы и функции

Файл / объект	Изменения
src/oneCEntry.js	Массив elementColors, получение сервиса modeling, функции создания, показа, удаления палитры и применения цвета
selection.changed	Добавлен показ палитры для одного выбранного элемента
clearSelectedElement()	Добавлено удаление палитры
loadDiagram()	Добавлено удаление палитры перед загрузкой XML
build-1c.mjs	CSS палитры и обновлённое оформление значка связи
dist/BPMNHTML.html	Пересобран автономный HTML
Общий макет BPMNHTML	Заменён результатом сборки

Основные функции палитры:

• createColorPalette(element) — создаёт восемь кнопок;
• showColorPalette(element) — проверяет допустимость элемента и показывает палитру;
• removeColorPalette() — удаляет overlay палитры;
• applyElementColor(element, color) — применяет заливку, чёрный контур и цвет подписи.

Для исключения соединений используется наличие element.waypoints, для исключения отдельных подписей — element.labelTarget.

Функция isSupportedBpmnElement() не изменялась: она продолжает использоваться для синхронизации элементов с 1С, включая потоки.

Результаты визуальной корректировки

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

После проверки:

• согласованы более насыщенные светлые заливки;
• контуры и подписи переведены в чёрный цвет;
• палитра поднята: позиция top изменена с -38 на -54, left: 0;
• для дорожек добавлены отдельные облегчённые оттенки;
• палитра скрыта для потоков.

Синий круг значка связи Data Store заменён тонкой тёмно-серой цепочкой:

• цвет — #555555;
• фон, круговая рамка и тень отсутствуют;
• область значка — 20 × 20;
• SVG — 18 × 18;
• толщина линии — 1.6;
• текст представления связанного объекта — чёрный.

Сам SVG-рисунок цепочки и логика связи с объектом 1С не менялись.

Совместимость и границы доработки

Сохранённые XML автоматически не изменяются. Новое оформление применяется только после выбора цвета пользователем и сохраняется при записи. Ранее окрашенные потоки также автоматически не перекрашиваются.

Оформление цепочки обновляется при открытии схемы независимо от её версии: это HTML-overlay, формируемый по данным связи из 1С.

В объём доработки не входили:

• обновление bpmn-js;
• изменение размеров элементов;
• массовое окрашивание;
• разработка интерфейса Undo/Redo и его проверка;
• автоматическое размещение палитры у границ холста.

Используется штатный API моделирования; внутренний механизм истории команд библиотеки не отключался.