Практика
Разбираем задачи, решения команды и способы проверки результата. Названия заказчиков и конфиденциальные сведения не раскрываем без их разрешения.
Фильтруйте кейсы по технологии, процессу или симптому. В каждом разборе есть исходная ситуация, причина проблемы, действия команды и результат.
Справочники клиентов, товаров и контрагентов жили в нескольких системах.
Один объект создавался повторно и по разным правилам.
Появились правила проверки справочников и контроля их влияния на обмены и отчёты.
Открыть полный разбор ↗Справочники клиентов, товаров и контрагентов жили в нескольких системах.
Один объект создавался повторно и по разным правилам.
Появились правила проверки справочников и контроля их влияния на обмены и отчёты.
Открыть полный разбор ↗Команда выбирала между API, файловым обменом и очередью сообщений.
Обсуждение шло вокруг технологии, а не вокруг требований процесса.
Выбор интеграции стал связан с эксплуатацией и результатом бизнеса.
Открыть полный разбор ↗Команда выбирала между API, файловым обменом и очередью сообщений.
Обсуждение шло вокруг технологии, а не вокруг требований процесса.
Выбор интеграции стал связан с эксплуатацией и результатом бизнеса.
Открыть полный разбор ↗Внешняя площадка продаж должна была работать вместе с внутренним учётом и складом.
Заказы, товары и статусы могли расходиться между внешним каналом и внутренними системами.
Канал продаж стал частью единого процесса, а не отдельной витриной.
Открыть полный разбор ↗Внешняя площадка продаж должна была работать вместе с внутренним учётом и складом.
Заказы, товары и статусы могли расходиться между внешним каналом и внутренними системами.
Канал продаж стал частью единого процесса, а не отдельной витриной.
Открыть полный разбор ↗Технический реестр интеграций существовал, но не отвечал на вопрос, кто действует при сбое.
При проблеме участники спорили, где находится ответственность.
Реестр интеграций стал инструментом управления, а не просто перечнем интерфейсов.
Открыть полный разбор ↗Технический реестр интеграций существовал, но не отвечал на вопрос, кто действует при сбое.
При проблеме участники спорили, где находится ответственность.
Реестр интеграций стал инструментом управления, а не просто перечнем интерфейсов.
Открыть полный разбор ↗Ошибка проявлялась в одной системе, но могла возникать на несколько шагов раньше.
Команды искали причину только в последнем интерфейсе, где пользователь видел сбой.
Диагностика стала смотреть на процесс целиком, а не на последний симптом.
Открыть полный разбор ↗Ошибка проявлялась в одной системе, но могла возникать на несколько шагов раньше.
Команды искали причину только в последнем интерфейсе, где пользователь видел сбой.
Диагностика стала смотреть на процесс целиком, а не на последний симптом.
Открыть полный разбор ↗При описании систем часть атрибутов могла отсутствовать в доступных источниках.
Не для всех описаний были указаны источники и ответственные за проверку.
Документация стала надёжнее для анализа изменений и передачи на сопровождение.
Открыть полный разбор ↗При описании систем часть атрибутов могла отсутствовать в доступных источниках.
Не для всех описаний были указаны источники и ответственные за проверку.
Документация стала надёжнее для анализа изменений и передачи на сопровождение.
Открыть полный разбор ↗Показано 12 из 18
Практический фокус
Один и тот же симптом может иметь разные причины. Кейсы показывают способ мышления, а не обещают повторить результат без анализа.
Сравните контекст и границы процесса с вашей ситуацией.
Обратите внимание, где находился разрыв между ролями и системами.
Проверьте, каким событием и критерием измерялось изменение.
Соберите собственный пример и обсудите его с нами.
Ваш случай не обязан быть похож на готовый кейс. Начнём с фактов вашего процесса.
Обсудить проблемный участок ↗