Map the workflow before configurationКарта процесса до настройки системы
Everyone can agree with “receive, fulfill, close” while interpreting each transition differently. A useful workflow map lets someone reconstruct an actual case: who received the work, what they waited for, which decision they made and how completion was established. Resolve these differences before configuring screens and statuses.На встрече все могут согласиться с цепочкой «принять, выполнить, закрыть», но по-разному понимать каждый переход. Карта процесса становится полезной, когда по ней можно восстановить конкретный случай: кто получил работу, чего ждал, какое решение принял и чем подтверждено завершение. Именно такие различия стоит выяснить до настройки экранов и статусов.
Choose a case and define its boundariesВыбрать случай и границы процесса
The analyst asks participants to choose a recently completed ordinary case and a case with an exception. Gather anonymized records, messages and documents that establish the sequence. Name the starting event: a request received, an order confirmed or work accepted from another team. These are different boundaries. Alongside it, state the outcome for the customer or next participant and the evidence that it was achieved.Аналитик просит участников выбрать недавно завершённый обычный случай и случай с отклонением. Соберите обезличенные записи, сообщения и документы, по которым можно восстановить последовательность. Укажите событие начала: получен запрос, подтверждён заказ или поступила работа от другой команды. Эти события не взаимозаменяемы. Рядом запишите результат, который получает клиент или следующий участник, и признак его достижения.
Do not expand the first map to the entire company. Choose a route with a named owner and verifiable completion. Show related processes as inputs or outputs with a clear recipient. When participants disagree about the actual sequence, retain the question and find evidence that resolves it; meeting consensus does not replace observation of current work.Не расширяйте первую карту до всей компании. Выберите маршрут, у которого можно назвать владельца и проверить завершение. Связанные процессы обозначьте как вход или выход с понятным получателем. Если участники спорят о фактической последовательности, сохраните вопрос и найдите запись, которая его разрешит; договорённость на встрече не заменяет наблюдение за текущей работой.
Separate actions from waitingРазделить действия и ожидание
Place participants in separate lanes and name steps with verbs: check availability, agree a substitution, hand over to fulfillment. Each step needs an input, required information and output. Show waiting for a response, material or decision separately. Assign ownership of waiting; the absence of active work does not suspend responsibility. Make the timing source clear, even when only the event sequence is currently known.Разместите участников по отдельным дорожкам и запишите шаги глаголами: проверить наличие, согласовать замену, передать исполнителю. У каждого шага есть вход, нужные сведения и получаемый результат. Отдельно покажите ожидание ответа, материала или решения. Назначьте владельца ожидания: отсутствие активного действия не означает, что ответственность приостановлена. Источник времени должен быть понятен, даже если пока известна только последовательность событий.
Mark repeated entry and information searches where they actually occur. A software name is not an action: “open CRM” does not explain the employee’s decision. If a step bypasses the documented procedure, record it as observed practice and establish why. The current-state map should represent actual work, including inconvenient workarounds.Отмечайте повторный ввод и поиск сведений там, где они действительно происходят. Не превращайте название программы в действие: «открыть CRM» не объясняет, какое решение принимает сотрудник. Если шаг выполняется в обход утверждённого порядка, запишите его как наблюдаемую практику и выясните причину. На карте текущего процесса важно видеть реальную работу, включая неудобные обходы.
Inspect each handoff of workПроверить каждую передачу работы
At each lane crossing, describe what is handed over: request identifier, agreed content, deadline and unresolved questions. Name the event that establishes acceptance by the receiver. A sent message and an accepted task are different states. If the recipient is unavailable or rejects incomplete information, show who still owns the work and how it returns for correction.На переходе между дорожками опишите, что передаётся: идентификатор заявки, согласованное содержание, срок и незакрытые вопросы. Укажите событие принятия получателем. Отправленное сообщение и принятая задача обозначают разные состояния. Если получатель недоступен или отклонил неполные сведения, карта должна показывать, кто продолжает владеть работой и как она возвращается на исправление.
Ask the next participant to perform their step using only the handoff information. A missing address, uncertain order version or absent approval becomes a concrete handoff requirement. Identify where the current record lives and how the recipient learns about changes after acceptance. This is more useful than a general requirement to “improve communication between departments.”Попросите следующего участника выполнить свой шаг по переданному набору без пояснений автора. Недостающий адрес, неопределённая версия заказа или отсутствующее согласование становятся конкретным требованием к передаче. Зафиксируйте, где хранится актуальная запись и как участник узнаёт об изменении после принятия. Это полезнее общего требования «наладить взаимодействие отделов».
Move from requirements to implementationПерейти от требований к внедрению
Make decision branches testableСделать развилки проверяемыми
At each branch, write the question, evidence needed to answer it and role authorized to decide. Replace “problem order” with an observable condition: availability is unconfirmed or the customer has not accepted a substitution. Show permitted outcomes, including waiting for clarification. Mark an undecided rule as an open decision with an owner rather than inventing a condition to complete the diagram.На каждой развилке запишите вопрос, сведения для ответа и роль, имеющую право принять решение. Вместо «проблемный заказ» используйте наблюдаемый признак: нет подтверждения наличия или клиент не согласовал замену. Покажите все допустимые исходы, включая ожидание уточнения. Если правило ещё не принято, отметьте его как открытое решение с владельцем, а не придумывайте условие ради завершённой схемы.
Walk through the exceptional case selected earlier and add missing transitions. Check cancellation after handoff, a repeated request and changes to agreed content. Show what happens to work already performed and who receives the change. Every minor detail need not appear; include branches that change ownership, a commitment or the state of data.Пройдите исключительный случай из первого шага и добавьте потерянные переходы. Проверьте отмену после передачи, повторный запрос и изменение уже согласованного содержания. Для каждого покажите, что происходит с ранее выполненной работой и кому сообщают об изменении. Необязательно рисовать каждую мелочь; обязательны развилки, которые меняют ответственного, обязательство или состояние данных.
Turn the map into requirements and testsПеревести карту в требования и проверки
The process owner approves the intended workflow separately from the current-state description. Each change needs a reason and observable outcome: the recipient sees the required version, missing information stops handoff or waiting has an owner. Link each requirement to a step and test scenario. For SABSUS, confirm which transitions and checks are configurable and which need another operational arrangement.Владелец процесса утверждает целевой маршрут отдельно от описания текущего. Для изменения укажите причину и наблюдаемый результат: получатель видит нужную версию, пропущенные сведения останавливают передачу или ожидание имеет владельца. Каждое требование связывают с конкретным шагом и сценарием проверки. Для SABSUS подтвердите, какие переходы и проверки доступны настройкой, а какие требуют другого организационного решения.
The map is ready for configuration handover when participants can walk through ordinary and exceptional cases without inventing rules along the way. Retain its version, agreed decisions and open questions. When the process changes, update the linked test as well as the diagram; otherwise the approved map and actual requirements will describe different workflows.Карта готова к передаче настройщику, когда участники проходят обычный и исключительный случаи без придуманных на ходу правил. Сохраните версию, принятые решения и открытые вопросы. После изменения процесса обновляйте связанную проверку, а не только картинку: иначе утверждённая схема и фактические требования начнут описывать разные способы работы.
Test the intended workflow scenariosПроверить сценарии целевого процесса
Quick answersКороткие ответы
Is a specialist diagram notation required?Нужна ли специальная нотация?
Clear actions, participants, branches and handoffs can be enough. Participants should interpret the map consistently and use it to trace actual cases.Достаточно понятных действий, участников, развилок и передач. Участники должны одинаково читать карту и проходить по ней реальные случаи.
Should the current or intended workflow come first?Что описывать первым: текущий или целевой процесс?
Establish how the selected case works today. Record intended changes separately, with a reason and testable outcome.Сначала установите, как выполняется выбранный случай сейчас. Целевые изменения фиксируют отдельно, с причиной и проверяемым результатом.
When is the map detailed enough?Когда карта достаточно подробная?
When it identifies the next owner, required information, transition condition and outcome for both ordinary and exceptional cases.Когда по ней можно определить следующего владельца, нужные сведения, условие перехода и результат обычного либо исключительного случая.