ИСО. Практика.Кейсы

1. кейсы

2. Сеть супермаркетов «ФрешСИТИ»

«Фрешсити» — федеральная сеть супермаркетов среднего ценового сегмента (300
магазинов).
За последние 4 квартала наблюдается устойчивый отток лояльных клиентов (покупатели
с историей более 1 года).
Падение ключевых метрик:
Поток лояльных клиентов снизился на 15%.
Частота визитов постоянных клиентов упала на 20%.
Доля рынка в ключевых регионах сократилась на 3%.
Руководство инициировало несколько точечных маркетинговых кампаний (скидки,
рассылки), но эффект был краткосрочным. Есть подозрение, что проблема системная
и связана с неэффективностью или ограничениями текущих информационных систем.
Провести всесторонний анализ информационных систем с целью принятия
решения об их целесообразности для борьбы с оттоком. Определить,
достаточно ли их модернизации или требуется внедрение принципиально
новых систем.
Решение должно быть основано на данных и их аналитической обработке.
КЕЙС 1

3.

Кейс не про техническую экспертизу, а про системное
мышление
Информационные системы:
• Кассовая программа -учет продаж, базовый
• Карты лояльности с отдельным приложением - списание бонусов, простые акции
• CRM - SMS-рассылки
• Отзывы на сайте - сбор отзывов о магазинах
• Складская ИС - управление запасами, закупки, логистика
Гипотезы:
1. Отток вызван снижением удовлетворенности ассортиментом (товарный ряд не
соответствует ожиданиям лояльных клиентов
2. Отток связан с нерелевантностью маркетинговых коммуникаций
КЕЙС 1

4. Внедрение CRM-системы в логистической компании «ТрансКом»

Сфера деятельности: Международные и внутрироссийские грузоперевозки.
Масштаб: Средний бизнес (150 сотрудников, офисы в Москве, СПб, Новосибирске).
Проблемная ситуация
Ряд системных проблем, тормозящих развитие компании:
Потеря клиентов и сделок. Менеджеры по продажам вели учет в Excel и в личных почтовых
ящиках. При увольнении сотрудника терялась история коммуникаций с его клиентами. Новым
менеджерам было сложно подхватить работу.
Низкая эффективность отдела продаж. Не было единой воронки продаж. Руководство не
понимало, на каком этапе «застревают» сделки, сколько потенциальных клиентов в работе.
Отсутствие клиентоориентированности. Клиенты жаловались на необходимость многократно
повторять одну и ту же информацию разным менеджерам (по продажам, по операционной
работе). Не системы для массовых рассылок (например, поздравление с НГ, информация об
изменении таможенного законодательства). Невозможно было проанализировать, какие клиенты
приносят наибольшую прибыль в долгосрочной перспективе, чтобы сосредоточить на них усилия.
Ручная работа и человеческий фактор: Подготовка коммерческих предложений занимала
много времени. Менеджеры вручную рассчитывали стоимость перевозки на основе старых Excelтаблиц с тарифами перевозчиков, что часто приводило к ошибкам.
КЕЙС 2

5.

Цель внедрения CRM-системы в логистической компании «ТрансКом»:
повысить доходность компании за счет увеличения конверсии входящих
заявок, роста лояльности текущих клиентов и повышения эффективности
работы отдела продаж
1. Анализ ситуации и выбор решения (анализ требований по показателям
интеграции, автоматизации, мобильности , гибкости, цене)
2. Подробный план внедрения ( этапы: подготовительный, пилотное внедрение и
обучение, промышленная эксплуатация и интеграция, пост-внедрение)
3. Количественные и качественные результаты
Показатель
До внедрения
Конверсия из заявки в сделку
15%
Среднее время обработки заявки
4 часа
Количество повторных продаж
25%
Количество упущенных сделок
30%
Время на подготовку КП
После
внедрения
Рост, %
30-40 мин.
CRM в логистике — это не просто «база клиентов», а комплексный инструмент управления продажами, клиентским
КЕЙС 2 опытом и операционной эффективностью, который напрямую влияет на финансовый результат

6. Внедрение CRM-системы в ритейл-сети «Уютный дом»

Сфера деятельности: сеть магазинов товаров для дома и ремонта (50+ точек).
Проект: внедрение тиражной CRM-системы «SalesHub» для автоматизации продаж, управления
клиентской базой и аналитики сторонней IT-компанией «ТехноСофт».
Проблемная ситуация
Существующие процессы — в Excel, почте и «головах» менеджеров. Нет единой клиентской базы,
срываются сроки поставок, маркетинг не может сегментировать аудиторию.
По Чек-листу решить кейс «Выявление и устранение рассогласования
между
ИТ-системой и требованиями заказчика»
Этап 1: Диагностика проблемы и оценка текущего состояния
1. Зафиксировать проблемные точки и сформулировать главную жалобу (напр., «Системой не пользуются»,
«Данные неверные», «Процесс стал дольше»).
2. Определить стейкхолдеров и ключевых лиц (кто недоволен (варианты: ЛПР, финансы, пользователи); кто
может дать информацию (пользователи, администраторы); кто является основным ЛПР по
изменениям (директор, менеджер проекта, спонсор проекта.. с обеих сторон); сбор первичной информации,
например, короткие интервью (15-20 мин.) с представителями каждой группы, чтобы понять их боль (не «что
не работает», а «что мешает работе»).
КЕЙС 3

7.

Этап 2: Анализ причин сбоя
1. Проверить полноту и четкость исходных требований: найти и изучить ТЗ, проверить наличие четких критериев
приемки для каждого требования. (Пример: Не «есть отчет», а «отчет Х показывает данные Y с точностью 99.5% по
сравнению с системой Z на дату D»); построить, заполнить и проанализировать матрицу:
Требование
Раздел ТЗ
Реализованная функция
Критерий тестирования.
2. Визуализировать процесс As-Is: любым методом собрать информацию конечного пользователя и определить, как
задача реально выполняется сейчас с новой системой. Найти шаги, где пользователь «обходит» систему (Excel,
блокнот, личные сообщения).
3. Проанализировать интеграции:схема обмена данными с другими системами; полнота данных и контроль
согласованности.
Этап 3: Планирование и внесение корректировок
1. Сформировать рабочую группу: (от заказчика: ЛПР, ведущий пользователь от каждого отдела, от
исполнителя: бизнес-аналитик, архитектор..)
2. Переформулировать и приоритизировать требования: определить ключевые требования в формате
роль-цель-ценность; предложить конкретные критерии и расставить приоритеты
3. Создать прототипы для спорных и проблемных моментов: например, для интерфейсов, вызывающих
больше всего проблем (эскизы ) и показать их пользователям до начала программирования и получить
обратную связь.
4. Определить формат исправлений: принять решение о доработках, назначить периоды взаимодействия
с демонстрацией результатов.
КЕЙС 3

8.

Этап 4: Реализация и валидация
1. Внедрять изменения итерационно: для первого цикла на примере обновить требования из пересмотренного
списка и после каждой итерации проводить демо для рабочей группы и ключевых пользователей.
2.Тестировать по обновленным критериям: проверка реализации строго по критериям приемки, а не по
абстрактному ТЗ, особое внимание уделить интеграционным тестам и точкам обмена данными.
3. Провести пилотное внедрение и обучение: запустить доработанную функциональность на примере,
переобучить пользователей на основе реального, исправленного процесса. ВКЛЮЧИТЬ стимулирующие
моменты и определять «чемпионов» для поддержки.
4. Обновить матрицу, чтобы она отражала связь между пересмотренными требованиями, кодом и тестами.
Этап 5: Итоги и контроль
1. Зафиксировать результат: подпись акта приемки-передачи по итогам корректировок на основе выполненных
критериев; обновить документацию (регламенты работы, руководства пользователя).
2. Внедрить превентивные меры на будущее: внедрение практики регулярных демо в ходе будущих проектов;
прописывание критериев приемки для всех новых требований% обязательное использование матрицы
трассировки с самого начала проекта.
КЕЙС 3
Переход от поиска виноватых («Вы сделали не по ТЗ!» - «Вы написали плохое ТЗ!») к совместному анализу разрывов в
процессах коммуникации и проектирования, и их системному устранению.

9. Министерство Магии Великобритании

ИСТОРИЯ:
После окончания Второй Магической Войны Министерство Магии столкнулось
с тревожной тенденцией: нарастающим оттоком («утечкой») молодых магов и
магловского происхождения (маглорожденных). Они разочаровываются в
магическом обществе, предпочитая либо уезжать в другие магические
сообщества (например, в Америку), либо полностью уходить в магловский мир,
подавляя в себе магические способности. Это ослабляет британское
магическое сообщество и создает риски нарушения Международного Статута
Секретности.
Были попытки точечных решений: праздники, памятные мероприятия, новые
должности. Но проблема системная. Подозрение падает на устаревшие,
несправедливые и неэффективные информационные и бюрократические
системы Министерства, которые отталкивают новое поколение.
Задача для специальной рабочей группы (Гермиона Грейнджер, Гарри Поттер,
Рон Уизли):
Провести анализ информационных и бюрократических систем Министерства с
целью принятия решения об их целесообразности для интеграции и удержания
молодых магов. Определить ключевые точки оттока и предложить решение.
КЕЙС 1

10.

11.

1. Анализ и выбор решения
Был сформирован проектный комитет в составе: коммерческий директор, директор по ИТ, руководитель отдела продаж.
Проведен анализ требований:
1.
Интеграция: Система должна интегрироваться с 1С (учет договоров и платежей) и с почтовыми сервисами (Gmail/Outlook).
2.
Автоматизация расчетов: Возможность подключения модуля калькуляции стоимости перевозки на основе актуальных тарифов.
3.
Мобильность: Доступ для менеджеров с мобильных устройств.
4.
Гибкость: Возможность настройки воронки продаж и этапов сделок под специфику логистического бизнеса (Заявка -> КП -> Согласование -> Договор -> Операционная работа -> Отчетность).
5.
Цена: Предпочтение cloud-решению (SaaS) для минимизации первоначальных затрат.
Выбор: После анализа рынка (Bitrix24, amoCRM, SalesapCRM, Мегаплан) был выбран «1С:CRM Логистика» (на базе 1С:CRM), так как решение предлагало:
Готовую отраслевую специфику для логистики.
Бесшовную интеграцию с уже используемой в компании «1С:Бухгалтерией».
Встроенный модуль для расчета стоимости перевозки.
2. Подробный план внедрения
Этап 1: Подготовительный (1 месяц)
Формирование рабочей группы: Назначены ответственные из ИТ, продаж и операционного отдела.
Описание бизнес-процессов: Вместе с приглашенным консультантом были прописаны идеальные процессы работы с лидом, ведения сделки, перехода клиента в операционную работу.
Настройка и кастомизация: Система была настроена под процессы «ТрансКарго»:
o
Созданы этапы воронки продаж: «Новая заявка», «Первичный контакт», «Подготовка КП», «Согласование КП», «Закрыта/Отказ».
o
Настроены автоматические письма-уведомления клиентам.
o
Внедрен модуль калькуляции, интегрированный с базой тарифов.
o
Настроены права доступа (менеджеры, руководители, операторы).
Этап 2: Пилотное внедрение и обучение (2 недели)
Обучение: Проведены интенсивные тренинги для 20 пилотных пользователей (менеджеры по продажам и их руководитель). Сняты видео-инструкции.
Пилот: Группа начала работать в новой системе параллельно со старыми методами. Собрана обратная связь, внесены точечные правки.
Этап 3: Промышленная эксплуатация и интеграция (1 месяц)
Полномасштабный запуск: Все 35 менеджеров отдела продаж начали работать исключительно в CRM.
Интеграция с 1С: Настроен обмен данными: из CRM в 1С автоматически создаются договоры, а из 1С в CRM поступает информация об оплатах.
Настройка отчетности: Созданы дашборды для руководства: воронка продаж, конверсия по менеджерам, план/факт, количество новых клиентов.
Этап 4: Развитие и сквозная аналитика (пост-внедрение)
Подключение коллтрекинга (определение, с каких рекламных источников звонят клиенты).
Настройка сквозной аналитики: от метки в Google Ads до закрытой прибыльной сделки в CRM.
3. Количественные и качественные результаты (через 6 месяцев
Качественные результаты:
Повышение прозрачности: Руководство в режиме реального времени видит всю воронку продаж и может управлять прогнозом.
Рост клиентской лояльности: Клиенты отмечают более профессиональный и персональный подход (напоминания, информирование, единое окно).
Снижение операционных рисков: Вся история коммуникаций и документов хранится в единой системе.
Упрощение адаптации новых менеджеров: Готовые скрипты, процессы и история клиента позволяют новичку быстро входить в курс дела.
Data-Driven управление: Появилась возможность анализировать эффективность рекламных каналов и принимать решения на основе данных, а не интуиции.
Кейс 2 - решение
Показатель
До внедрения
После
внедрения
Рост
Конверсия из заявки в сделку
15%
28%
+87%
Среднее время обработки заявки
4 часа
1 час
-75%
Количество повторных продаж
25%
40%
+60%
Количество упущенных сделок
~30% (оценка)
<5%
>-83%
Время на подготовку КП
30-40 мин.
5-10 мин.
-75%

12.

ЭТАП 1: Формирование первоначальных требований (Идеальный мир)
Методы, использованные IT-компанией:
•Интервью с ключевыми стейкхолдерами: Отдельные беседы с коммерческим директором, руководителем отдела продаж,
маркетологом.
•Семинар по сбору требований (Workshop): Совместная сессия с представителями всех отделов.
•Анализ документов: Изучение существующих отчетов в Excel, форм заказов, регламентов.
Сформулированные первоначальные требования (ключевые):
1.Управление клиентами: Единая карточка клиента с историей покупок и обращений.
2.Управление сделками: Воронка продаж с этапами «Заявка» -> «Обработка» -> «Согласование» -> «Отгрузка» -> «Оплата».
3.Отчетность: Автоматическое формирование отчетов по продажам менеджеров, конверсии, выручке.
4.Интеграция: Обмен данными с системой 1С:Управление торговлей (номенклатура, остатки, факты отгрузок).
5.Мобильность: Доступ для менеджеров с планшетов в торговом зале.
6.Маркетинг: Возможность делать рассылки по сегментам клиентов.
Результат фазы 1: Подписанное Техническое задание (ТЗ), составленное на основе требований, но сформулированное в
технических терминах исполнителя. Критическая ошибка: ТЗ слабо детализировало бизнес-процессы и не содержало четких
критериев приемки (Acceptance Criteria) для каждого требования.
ЭТАП 2: Реализация и первые признаки рассогласования
В процессе внедрения «ТехноСофт» действовал строго по ТЗ, но:
•Сделка в CRM считалась завершенной на этапе «Отгрузка». Для финансового отдела из 1С факт оплаты приходил с задержкой в
2-3 дня. Результат: В отчетах CRM выручка всегда отличалась от данных бухгалтерии. Требование №3 не выполнено в понимании
заказчика.
•Карточка клиента содержала все данные, но при вводе с мобильного планшета форма была громоздкой. Менеджерам
требовалось 3-4 минуты на ввод, что в потоке покупателей было неприемлемо. Они начали записывать контакты в блокнот, а
потом переносить в CRM. Результат: Данные устаревали, процесс не работал. Требование №1 и №5 конфликтовали на практике.
•Интеграция с 1С работала в одну сторону (номенклатура -> CRM). Обратный поток данных (новые клиенты из CRM в 1С)
реализован не был, так как это не было явно прописано в ТЗ. Результат: В 1С не появлялись новые контрагенты, созданные в
CRM.
Итог через 3 месяца после «внедрения»: Система работала, но ею почти не пользовались. Заказчик был в ярости, считал деньги
выброшенными на ветер. Исполнитель ссылался на выполненное ТЗ.
ЭТАП 3: Анализ рассогласования и выбор методик для «спасения» проекта
Была созвана кризисная встреча. Решили провести аудит и перевыровнять систему под реальные нужды.
Ответственный: Привлеченный с обеих сторон Бизнес-аналитик.
КЕЙС 3- решение

13.

Выбранные методы сопоставления и диагностики:
1.Метод трассировки требований (Requirements Traceability Matrix):
1. Цель: Проследить каждое первоначальное требование через все артефакты проекта (ТЗ, сценарии тестирования, реализованные функции) и найти
разрывы.
2. Пример: Для требования №3 «Отчетность» построили связь: *Бизнес-требование (Отчет по выручке) -> ТЗ (Формирование отчета «Продажи») -> Тесткейс (Сравнение данных в отчете) -> Критерий приемки (Отчет должен соответствовать данным в 1С на 99,5%)*. Выявили, что критерий приемки был
сформулирован абстрактно («формирование отчетов»), а не конкретно («данные должны совпадать с 1С с учетом задержки на оплату»).
2.User Story Mapping (Картирование пользовательских историй):
1. Цель: Визуализировать весь путь пользователя (например, менеджера в магазине) от начала (встреча с клиентом) до конца (закрытие сделки и отчет).
Провести воркшоп с реальными пользователями.
2. Результат: Стало очевидно, что «процесс ввода клиента» — это не одна точка, а две: 1) Быстрый захват контакта (30 секунд), 2) Детальное заполнение
в спокойной обстановке. Система поддерживала только второй сценарий.
3.Демонстрации и прототипирование (Agile-подход):
1. Цель: Не обсуждать требования в терминах, а показывать интерфейсы на ранних стадиях.
2. Пример: Для мобильного интерфейса аналитик быстро набросал в Figma два варианта формы: «полную» и «быструю» (только имя и телефон).
Варианты были показаны менеджерам, и они мгновенно выбрали и доработали «быстрый» вариант.
ЭТАП 4: Последовательность решения кейса (План корректирующих действий)
1.Приостановка доработок. Заморозка всех изменений, не связанных с критическими ошибками.
2.Создание рабочей группы: От заказчика — по 1-2 ключевых пользователя из каждого отдела + ЛПР. От исполнителя — аналитик, ведущий разработчик,
тестировщик.
3.Ревизия и детализация требований: Используя User Story Mapping и User Stories с четкими критериями приемки (Given-When-Then).
1. Было: «Мобильный доступ для менеджеров».
2. Стало: «Как менеджер в торговом зале, я хочу за 30 секунд внести контактные данные заинтересованного покупателя в CRM, чтобы позже с ним
связаться и не потерять лид».
4.Восстановление трассировки: Построение полной матрицы трассировки от пересмотренных требований до конкретных задач в системе управления проектами
(Jira) и тест-кейсов.
5.Итеративная доработка (Agile): Внедрение изменений не одним блоком, а небольшими итерациями (спринтами по 2 недели) с обязательной демонстрацией
результата рабочей группе после каждого спринта и сбором обратной связи.
6.Фокус на интеграционные точки: Специальный анализ всех точек обмена данными с 1С. Формализация двусторонних потоков. Создание регламента сверки
данных (какая система в какой момент является «главной» для каждого типа данных).
7.Обучение и поддержка: Переобучение пользователей на основе переработанных процессов, а не старого ТЗ. Назначение «чемпионов» внутри отделов
«Домашнего Уюта».
ЭТАП 5. Итог и выводы Через 4 месяца корректировок система была принята и активно использовалась.
1.ТЗ — не панацея. Без постоянной валидации с пользователями и детальных критериев оно становится формальным документом, не гарантирующим успех.
2.Важны не функциональные, а нефункциональные требования: Для мобильного ввода критичной была производительность (скорость) и удобство
использования (Usability), а не просто наличие поля «Телефон».
3.Методы визуализации (User Story Map, прототипы) эффективнее многостраничных текстовых описаний для выявления рассогласования.
4.Трассировка требований — это «спасательный круг» проекта. Она позволяет объективно понять, где и почему было упущено требование, а не искать виноватых.
5.Постоянная вовлеченность заказчика (реальных пользователей) в процесс через демонстрации — залог того, что итоговый продукт будет
соответствовать реальным, а не формально зафиксированным требованиям.

14.

ID
Формулировка
Требован требования (Что хотел
ия
заказчик?)
FUNC-01 Управление
сделками: Фиксация всех
этапов от заявки до
оплаты для
формирования полной
финансовой картины.
Источник
Статус
Ссылка на ТЗ / ID задачи Реализованная функция (Что
ID тест(Стейкхолдер
Раздел
в Jira
сделал исполнитель?)
кейса
)
Ком.
Рассогласов ТЗ, п. 2.3
SH-45
Реализована воронка продаж с TC-101
директор,
ание
этапами: "Заявка«Отдел
"Обработка" - "Согласование«продаж
"Отгрузка".
FUNC-02 Мобильный
доступ: Возможность для
менеджеров оперативно
работать с системой в
торговом зале.
Рук. отдела
продаж
Рассогласов ТЗ, п. 5.1
ание
SH-78
Разработано мобильное
веб-приложение. Все поля
карточки клиента доступны
для ввода.
TC-205
Критерий
приемки
Комментарий / Выявленное
рассогласование
Функция
КРИТИЧЕСКОЕ. Не учтен этап
работает. Сделка "Оплата". Данные в CRM (выручка
переходит в статус по отгрузкам) и в 1С (выручка по
"Завершено"
оплатам) никогда не совпадают.
после этапа
Нет финансового контроля.
"Отгрузка".
Все поля
формы
сохраняются
корректно.
Функция
работает.
НФТ: Требование
выполнено функционально,
но провалено по удобству
(Usability) и производительнос
ти. На заполнение уходит 3-4
минуты, что неприемлемо в
потоке покупателей.
1.Столбец «Статус» — это индикатор. «Рассогласование» — красная лампочка.
2.Строка FUNC-01: Прямая связь с REP-01. Проблема в отчете коренится в неполной реализации процесса. Матрица позволяет проследить эту связь.
3.Строка FUNC-02 vs FUNC-03: Демонстрация конфликта нефункциональных требований (NFR). Одна функция (FUNC-03) технически работает, но другая
(FUNC-02) делает ее бесполезной на практике.
4.Строка INT-01: Яркий пример неполного/неоднозначного требования в ТЗ ("Интеграция" без детализации потоков данных). Матрица выявляет этот
пробел.
5.Ключевая польза: Такую таблицу можно показывать на совместных встречах с заказчиком и исполнителем. Это объективный факт, а не мнение. Он
четко показывает:
1.
Что было понято неправильно?
2.
Где не хватило деталей в ТЗ?
3.
Какие доработки нужны в приоритетном порядке? (Все со статусом «Рассогласование»).
Эта матрица становится живым документом для управления корректирующими действиями из Чек-листа. Каждое исправление (новая задача в Jira,
новый тест-кейс) должно добавляться в соответствующую строку, пока статус не изменится на «Выполнено».