Discovery before implementationДиагностика перед внедрением
Discovery is useful when the business can choose which problem to solve first and how to accept the result. A software wish list does not provide that decision. Start with completed and stalled cases: they reveal where information disappears, who makes decisions and which constraints cannot be removed by configuring an interface.Диагностика приносит пользу, когда бизнес может выбрать, какую проблему решать первой и по каким признакам принять результат. Список пожеланий к программе такого решения не даёт. Начните с нескольких завершённых и застрявших случаев: они покажут, где теряются данные, кто принимает решения и какие ограничения нельзя обойти настройкой интерфейса.
Frame the business questionСформулировать вопрос бизнеса
The sponsor and process owner describe an observed problem, such as accepted requests waiting too long for assignment. Clarify where waiting starts, which cases are included and what consequence matters. “We need automation” names a possible method but does not explain the required outcome. Avoid promising a numerical improvement without a comparable baseline.Заказчик и руководитель процесса описывают наблюдаемую проблему: например, принятые заявки слишком долго ждут назначения. Уточните, где начинается ожидание, какие случаи входят в наблюдение и какое последствие важно. «Нужна автоматизация» обозначает возможный способ, но не объясняет, какой результат нужен. Не обещайте числовое улучшение, пока нет сопоставимой исходной оценки.
Record mandatory conditions separately: operating hours, multiple locations, existing commitments and staff availability for training. A preference for a particular screen and an inability to interrupt order intake carry different weight. The decision owner distinguishes requirements, preferences and items that can be deferred with understood consequences.Отдельно запишите обязательные условия: часы работы, несколько точек, существующие договорённости и доступность команды для обучения. Предпочтение красивого экрана и невозможность прервать приём заказов имеют разный вес. Владелец решения определяет, что обязательно, что желательно и что можно отложить с понятным последствием.
Follow real cases through to the outcomeПроследить реальные случаи до результата
Representatives from intake, execution and review show one ordinary and one difficult case from start to finish. The facilitator records the records used, handoffs, waiting and decisions. Do not replace observation with “we usually do this”: ask where the next person obtains the necessary context. Use anonymized materials when personal information is unnecessary for the discussion.Представители приёма, исполнения и контроля показывают один обычный и один сложный случай от начала до конца. Ведущий отмечает используемые записи, передачи, ожидания и решения. Не заменяйте наблюдение описанием «обычно делаем так»: попросите показать, где следующий человек получает нужный контекст. Используйте обезличенные материалы, если для обсуждения не нужны личные данные.
Distinguish the agreed procedure from a workaround. If an employee keeps a separate list, find out which commitment it helps preserve. Removing it before an equivalent method exists loses a function, even if the interface becomes simpler. Keep disagreements between roles as owned questions rather than averaging them into a vague description.Различайте установленное правило и обходной путь. Если сотрудник ведёт отдельный список, выясните, какое обязательство он помогает удерживать. Убирать список до появления равноценного способа значит потерять функцию, даже если интерфейс станет проще. Несогласие между ролями сохраните как вопрос с владельцем, а не усредняйте в расплывчатое описание.
Inspect dependencies and unknownsПроверить зависимости и неизвестное
List the data sources, external systems, devices and people required to finish the selected workflow. Identify an owner and verification method for each dependency. A claim that an integration exists does not establish the needed field or transfer direction. Record unknown capabilities as checks required before estimating scope rather than treating them as established project conditions.Перечислите источники данных, внешние системы, устройства и людей, без которых выбранный процесс не завершается. Уточните владельца и способ проверки каждой зависимости. Заявление о наличии интеграции ещё не подтверждает нужное поле или направление передачи. Неизвестные возможности записывают как проверку до оценки объёма, а не как готовое условие проекта.
Establish who can approve the workflow, data decisions and use of staff time. One meeting participant may not have authority over all three. If an essential owner is absent, prepare a specific question and response date. Independent work can then continue while the uncertain part remains explicitly open.Зафиксируйте, кто вправе согласовать процесс, данные и расходы времени команды. Один участник встречи не обязательно принимает все эти решения. Если ключевой владелец отсутствует, подготовьте конкретный вопрос и срок ответа. Это позволяет продолжать независимую работу, сохраняя неопределённую часть открытой.
Choose a complete first-launch scopeВыбрать завершённый объём первого запуска
Compare options by problem importance, data dependencies and owner readiness. The chosen scope must take a concrete case through to an outcome. A convenient intake form without a handoff to execution is not a complete workflow. Specify boundaries: included order types, locations and exceptions, and what continues under the existing routine.Сравните варианты по значимости проблемы, зависимости от данных и готовности владельца. Выбранный объём должен доводить конкретный случай до результата. Одна удобная форма ввода без передачи исполнителю не образует законченного процесса. Укажите границы: какие типы заказов, точки и исключения входят, а что пока продолжает прежнюю работу.
Produce findings that support a decisionПодготовить выводы для решения
The output includes the problem, case map, baseline observations, constraints, open questions and acceptance criteria. Each criterion names an observable action and evidence of the outcome. Use this package in a SABSUS discussion to assess configuration fit. Do not close unknowns with a general “it can be configured”; ask for a specific verification method and a decision on the limitation.Итог содержит описание проблемы, карту случая, исходные наблюдения, ограничения, вопросы и критерии приёмки. Для каждого критерия укажите наблюдаемое действие и доказательство результата. На встрече по SABSUS используйте этот набор для проверки соответствия конфигурации. Не закрывайте неизвестные вопросы общим обещанием «можно настроить»: попросите конкретный способ проверки и решение по ограничению.
Build a workflow mapПостроить карту процесса · Audit migration dataПроверить данные для переноса
Quick answersКороткие ответы
Is a complete feature list needed before the first meeting?Нужен полный список функций до первой встречи?
Operational cases, the problem and constraints are more useful. Discuss features after defining the required outcome.Полезнее принести рабочие случаи, проблему и ограничения. Функции обсуждают после определения нужного результата.
Who should participate in discovery?Кто должен участвовать в диагностике?
The decision owner and representatives of roles involved in the selected case, with data and external-system owners where needed.Владелец решения и представители ролей, через которые проходит выбранный случай, а при необходимости владельцы данных и внешних систем.
How do you know discovery is finished?Как понять, что диагностика закончена?
When launch scope and acceptance criteria support a decision, and remaining unknowns have owners and verification methods.Когда область запуска и критерии приёмки позволяют принять решение, а оставшиеся неизвестные имеют владельцев и способы проверки.