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

Новая схема и незавершённая работа

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

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

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

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

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

Что меняется вместе со схемой

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

В документации о версионности BPMSoft 1.9 указано: при создании новой версии ранее запущенные экземпляры продолжают прежнюю работу. Отдельно предусмотрено сохранение текущей версии; оно может остановить её запущенные экземпляры. Это разные действия с разными последствиями. Назначение актуальной версии также не является доказательством переноса существующего состояния.

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

На уровне методов такое разделение разобрано в исследовании Rinderle, Reichert и Dadam: изменение типа процесса и изменение выполняющегося экземпляра — разные задачи, а корректность перехода зависит от совместимости состояния с изменённой схемой. Исследование не относится к BPMSoft и не оценивает частоту ошибок этой платформы. Здесь оно помогает сформулировать вопрос проверки: может ли новая последовательность продолжить уже случившееся без противоречия?

×

Основа схемы — официальное описание версионности BPMSoft 1.9. Стрелки показывают выбор версии выполнения, а не встроенный механизм миграции.

Три способа распорядиться открытыми заявками

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

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

Второй способ — управляемый переход выбранных состояний. Команда должна показать соответствие старой и новой работы: где находится заявка, что уже исполнено и с какого обязательства она продолжится. Это название проектного решения. В статье не утверждается наличие универсальной команды BPMSoft, которая переносит любой активный экземпляр. Применимость механизма устанавливается отдельно для версии и реализации.

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

Третий способ — отмена прежнего выполнения и новый запуск. Он понятен организационно, когда старый путь больше непригоден, но создаёт новую последовательность действий. До его выбора определяют, какие прежние результаты сохраняют силу, какие задания прекращаются и что запрещено повторять. Новое выполнение связывают с прежним так, чтобы контролёр мог восстановить основание перехода. Без такой связи перезапуск превращает продолжение одной заявки в два несогласованных рассказа.

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

Почему отмена не возвращает прошлое

У отмены есть собственное выполнение. Руководство BPMSoft 1.9 описывает состояния «Отменяется» и «Отменен». Если уже выполняется элемент «Задание-сценарий», отмена заканчивается после его выполнения. Следовательно, нажатие команды ещё не подтверждает завершение старой работы. Новый запуск нельзя объявлять безопасным только потому, что запрос отмены отправлен.

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

Механизм этой неопределённости объясняет первичное инженерное описание Amazon Builders’ Library. Повтор без дополнительного эффекта требует соответствующего поведения принимающей стороны и различения намерений. Переносим в нашу задачу только этот принцип. Он не означает, что для BPMSoft нужен AWS или что произвольный получатель уже умеет безопасно обрабатывать повторы.

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

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

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

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

Три заявки перед одним изменением

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

Заявка А ещё не получила согласующего. Важно установить, что это означает технически. Запись могла быть создана без экземпляра либо экземпляр уже запущен и ждёт условия назначения. В первом случае проверяют нужный новый запуск. Во втором одной актуальной схемы недостаточно: уже существует прежнее исполнение. Одинаковая подпись «не назначена» не доказывает одинаковый способ перехода.

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

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

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

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

Сроки, роли и внешние события

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

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

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

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

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

Как провести приёмку без догадок

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

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

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

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

После испытания сравнивают идентификаторы, связи и обязательства по каждой заявке. Одинаковое общее число открытых записей недостаточно: одна заявка могла исчезнуть, а другая получить два задания. Для учебного линейного примера нужны объяснённые старое и новое исполнения, одна следующая работа и прослеживаемая история принятого решения. При параллельном согласовании ожидаемое число и правила завершения будут другими.

Признаки остановки устанавливают заранее: неизвестное внешнее действие, необъяснённый повтор задания, потерянная связь с исходным решением, отсутствие уполномоченного исполнителя или неподтверждённый срок. Это не утверждение, что такие дефекты найдены в BPMSoft. Это основания не принимать переход, пока команда не объяснит фактический результат для затронутого класса заявок.

Как разобрать ответ на границе перехода

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

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

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

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

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

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

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

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

Где заканчивается применимость решения

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

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

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

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

Матрица перехода для владельца процесса

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

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

×

Учебная инфографика НТА показывает разные предметы проверки. Она не сообщает о выполненном испытании и не изображает экран BPMSoft.

Полезный вопрос к заполненной строке: сможет ли другой специалист восстановить продолжение заявки без устного рассказа автора изменения? Если для этого требуется помнить, что «этот запуск можно не учитывать», объяснение ещё не закончено. История должна показывать основание сама: через ссылки, результаты и принятые правила, доступные уполномоченному проверяющему.

Что разрешать перед включением

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

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

НТА может помочь обследовать состояния, согласовать правила и подготовить изменения процесса с отдельной приёмкой перехода. Речь о проектной работе, без обещания готовой универсальной функции миграции. В разборе управления изменениями CRM рассматривается согласование самого изменения; здесь предмет уже — незавершённые обязательства внутри процесса. А материал об ответственности за дебиторскую задолженность показывает другую сторону той же управляемости: у оставшейся работы должны быть явный исполнитель и условие завершения.

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

Тест понедельником

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

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

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

Важное уведомление

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