Improvements in the first 90 daysУлучшения за первые 90 дней
A few weeks after launch, it is tempting to enable more features at once. First establish what actually limits the outcome: waiting for a decision, incomplete data or repeated work. The first 90 days can become a sequence of improvements, each with a baseline, a testable hypothesis and a decision about continued use.Через несколько недель после запуска появляется соблазн включить больше функций сразу. Полезнее сначала выяснить, что действительно ограничивает результат: ожидание решения, неполные данные или повторная работа. Первые 90 дней можно использовать как период последовательных улучшений, где каждое изменение имеет исходную оценку, проверяемую гипотезу и решение о дальнейшем использовании.
Separate stabilization from improvementОтделить стабилизацию от улучшения
The process owner checks that essential cases complete and known blockers have resolutions. Fixing a defect that prevents an order from closing is stabilization. Changing assignment to reduce waiting is an improvement. Mixing them in one evaluation makes it difficult to explain the result or judge whether it can be repeated.Владелец процесса проверяет, что основные случаи завершаются и известные блокеры имеют решения. Исправление ошибки, из-за которой заказ нельзя закрыть, относится к стабилизации. Изменение способа назначения ради меньшего ожидания — уже улучшение. Если смешать их в одной оценке, трудно понять, откуда появился результат и можно ли его повторить.
Retain baseline observations after initial setup settles. Specify case types, locations, operating hours and excluded events. Comparing against a chaotic first shift can exaggerate the effect. If baseline data is unreliable, first collect observations under agreed rules rather than presenting them as evidence of benefits already achieved.Сохраните исходные наблюдения после периода первоначальной настройки. Укажите типы случаев, точки, часы работы и исключённые события. Сравнение с хаотичной первой сменой может преувеличить эффект. Если исходные данные ненадёжны, сначала проведите короткое наблюдение по согласованным правилам, не выдавая его за доказательство уже полученной выгоды.
Choose a constraint by where work waitsВыбрать ограничение по потерянному времени
Separate the case journey into active work, waiting and rework. A long overall duration does not identify the step to change. Find recurring waiting with a clear decision owner. Check whether seasonal demand, a missing resource or a changed order mix explains it. Those conditions need different responses from unnecessary data handoffs.Разложите путь случая на работу, ожидание и возврат на исправление. Долгая общая длительность не показывает, какой участок стоит менять. Найдите повторяющееся ожидание с понятным владельцем решения. Проверьте, не возникло ли оно из-за сезонного спроса, отсутствия ресурса или сменившегося состава заказов. Такие обстоятельства требуют другого решения, чем лишняя передача данных.
Choose a bounded step whose effect can be observed. Preparing required context before assignment, for example, may reduce clarification. State the expected result and what must not deteriorate: assignment accuracy, completion quality or workload in the next role. Speeding up one step is not useful if the queue merely moves downstream.Выбирайте ограниченный участок, влияние которого можно наблюдать. Например, подготовка обязательного контекста до назначения исполнителя может уменьшить уточнения. Опишите, какой результат ожидается и что не должно ухудшиться: точность назначения, качество завершения или нагрузка следующей роли. Ускорение одного шага не полезно, если очередь просто переместилась дальше.
Test one understandable changeПроверить одно понятное изменение
Record the revised procedure, owner and application boundary. Avoid changing the form, assignment rules and team composition together if you need to understand each decision’s effect. Participants should know which instruction version applies. Compare equivalent case types and flag unusual demand separately; totals alone can conceal a changed workload mix.Зафиксируйте новую процедуру, владельца и границу применения. Не меняйте одновременно форму, правила назначения и состав команды, если хотите понять эффект каждого решения. Участники должны знать действующую версию инструкции. Сравнивайте случаи одинакового типа и отдельно отмечайте необычную нагрузку; одни итоговые суммы могут скрыть изменение состава работы.
Before automation, verify an unambiguous trigger and the effect of repeated events. Define when the rule must stop and who handles the exception. In SABSUS, confirm the available mechanism through a concrete scenario; a module name does not establish that the workflow can be automated. Before enabling live actions, test the workflow without unintended external effects.Для автоматизации сначала проверьте однозначность сигнала и последствия повторного события. Определите, когда правило должно остановиться и кто разбирает исключение. В SABSUS подтвердите доступный механизм на конкретном сценарии; возможность автоматизировать процесс не предполагается по названию модуля. До включения реальных действий проведите проверку без нежелательных внешних последствий.
Review the effect alongside qualityОценить эффект вместе с качеством
Compare waiting, repeated corrections and support effort using consistent counting rules. Retain cases that worsened as well as the average. If data is limited or conditions changed substantially, keep the conclusion provisional. The manager decides whether to observe longer, revise the rule, retain it or return to the previous routine while accounting for records already created.Сравните ожидание, повторные исправления и усилия на сопровождение по одинаковым правилам подсчёта. Сохраните не только среднее, но и случаи, где результат ухудшился. Если данных мало или условия сильно поменялись, вывод остаётся предварительным. Руководитель выбирает продолжить наблюдение, изменить правило, оставить его или вернуться к прежнему порядку с учётом уже созданных записей.
Expand only when the result can be explainedРасширять только объяснимый результат
At the 90-day review, list verified changes, unresolved questions and conditions for applying them to another location or workflow. The receiving team needs rules and exception examples, not just a headline metric. Inspect differences in data, demand and resources. Expand when those dependencies are ready; a calendar milestone alone is not a reason to scale.На обзоре 90 дней перечислите проверенные изменения, незавершённые вопросы и условия переноса на другую точку или процесс. Новая команда должна получить правила и примеры исключений, а не только итоговый показатель. Проверьте отличия данных, нагрузки и ресурсов. Расширение принимают, когда эти зависимости готовы; сам срок в календаре не является основанием для масштабирования.
Complete first-month stabilizationЗавершить стабилизацию первого месяца · Prepare the next launch waveПодготовить следующую волну
Quick answersКороткие ответы
Must all modules be implemented within 90 days?Нужно внедрить все модули за 90 дней?
No. Use the period to evaluate selected improvements. Expansion depends on results and dependency readiness.Нет. Период полезен для проверки выбранных улучшений. Объём расширения зависит от результата и готовности зависимостей.
How can a configuration effect be separated from demand changes?Как отличить эффект настройки от изменения спроса?
Compare similar case types and conditions, recording seasonality, workload and other changes. Limited evidence means the conclusion remains provisional.Сравнивайте похожие типы случаев и условия, фиксируя сезонность, нагрузку и другие изменения. При недостатке данных вывод остаётся предварительным.
When does a step make sense to automate?Когда имеет смысл автоматизировать шаг?
When its trigger, rule, exceptions and repeated-event effects are understood and the required mechanism has been verified in the selected configuration.Когда понятны сигнал, правило, исключения и последствия повтора, а нужный механизм проверен в выбранной конфигурации.