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

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. Министерство Магии Великобритании

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

10.

Деловая игра Построение информационной стратегии организации»
«Кризисный штаб «ТехноПрогресс»
Компания "ТехноПрогресс" находится на грани катастрофы. Флагманский проект "Аура" —
масштабная SaaS-платформа для автоматизации бизнеса — отстает от графика на 4 месяца.
Ситуация достигла критической точки:
Контрактные обязательства: Через 90 дней истекает срок сдачи проекта ключевому
заказчику — холдингу "ГлобалТрейд". По контракту предусмотрены штрафы в
размере 200% от стоимости проекта + репутационные потери.
Финансовое давление: Инвесторы заморозили следующую порцию финансирования до
успешного запуска "Ауры".
Техническое состояние: Система представляет собой "монстра" из связанных костылей.
Ежедневно возникают критические инциденты.
Командный кризис: В команде разработки царит выгорание. За последний
месяц 2 миддла уволились без предупреждения.
Решение совета директоров: Создать "Кризисный штаб" — специальную команду из 5
человек, которой предоставляется:
Экстренный бюджет на премии (+50% к окладу)
Приоритет во всех ресурсах компании
Полномочия принимать любые технические решения
Задача кризисного штаба: Любой ценой запустить работоспособную версию "Ауры" в
течение 75 дней.
Остальной персонал будет переведен на поддержку второстепенных проектов или сокращен.
Вам предстоит решить, кто войдет в элитную пятёрку.

11.

Деловая игра «Построение информационной стратегии организации»
Ключевая цель деловой игры:
формировать из доступных кандидатов команду
из 5 человек, которая с наибольшей вероятностью выполнит миссию: за 75 дней
запустить работоспособную версию SaaS-платформы «Аура»
Правила для участников:
1.У вас есть описание ключевых сотрудников (роли в презентации либо карточки раздаю).
2.В кризисный штаб нужно выбрать ровно 5 человек за 5 (просчитать сколько) раундов
обсуждения на основе личной аргументации кандидатов.
3.Вы должны договориться о едином решении и представить его Совету директоров
(ведущему), аргументируя почему выбран именно этот состав, какую роль будет
исполнять каждый и как вы будете работать как команда.
4.Вы должны нарисовать организационную структуру и показать коммуникационное
взаимодействие между участниками
5.Вы должны прописать краткий план работы кризисного штаба на 75 дней (Гант)
6. Агрессивная внешняя среда может подкидывать вам дополнительные проблемки

12.

Деловая игра «Построение информационной стратегии организации»
Ключевая цель деловой игры:
формировать из доступных кандидатов команду
из 5 человек, которая с наибольшей вероятностью выполнит миссию: за 75 дней
запустить работоспособную версию SaaS-платформы «Аура»
Агрессивная внешняя среда (дополнительные проблемки)
Угроза: "Массовый исход"
Ситуация: Три ключевых senior-разработчика одновременно получили офферы от конкурента с зарплатой +70%.
Они готовы уйти через 2 недели.
Вопрос команде: Кого вы готовы немедленно повысить и на сколько, чтобы удержать? Чьи потери будут самыми
катастрофичными?
Угроза: "Смертельный баг"
Ситуация: Обнаружена критическая уязвимость в системе шифрования данных. Личные данные тысяч клиентов
под угрозой. Исправить можно только полным переписыванием модуля безопасности с нуля (3-4 недели).
Вопрос команде: Отложить основной релиз и срочно чинить безопасность? Или запуститься с риском штрафов от
регулятора?
Угроза: "Бунт заказчика"
Ситуация: Технический директор "ГлобалТрейд" лично приехал в офис и требует продемонстрировать текущий
прогресс. Он известен своим непониманием технических деталей и вспыльчивым характером.
Вопрос команде: Кто будет вести демо и как вы будете презентовать сырой продукт, чтобы не сорвать сделку?
Угроза: "Инфраструктурный коллапс"
Ситуация: Основной продакшен-сервер не выдерживает нагрузки и падает. Резервные копии данных устарели на 2
недели.
Вопрос команде: Чьи навыки сейчас критически важны? Кто виноват и как быстро можно восстановить работу?
Угроза: "Юридическая мина"
Ситуация: Обнаружено, что в проекте используется библиотека с запрещенной лицензией. Полная замена займет 1
месяц.
Вопрос команде: Игнорировать риск судебных исков или срочно переписывать, сорвав все сроки?

13.

Деловая игра «Построение информационной стратегии организации»
1. Алексей «Технарь» (Lead Backend-разработчик) Возраст: 34 года.
Профиль: Гений оптимизации кода. Знает всю «грязную» архитектуру «Ауры» изнутри, так как писал половину
«костылей». Асоциален, не любит совещания, общается только в тикете. Ценит только техническую элегантность.
Риск: Может потратить 2 недели на переписывание «неидеального» модуля вместо того, чтобы сделать быстрый
фикс.
Ключевая фраза: «Этот код — позор. Надо переписать, иначе всё рухнет».
2. Мария «Спасатель» (Системный архитектор) Возраст: 40 лет.
Профиль: Пришла в компанию 3 месяца назад. Со свежим взглядом составила карту архитектурного хаоса «Ауры».
Предлагает радикальный, но рискованный план: выбрать 2 ключевых модуля, запустить их как отдельные сервисы, а
остальное «заглушить».
Риск: Её план — это авантюра с шансом 50/50. Не успеем за 75 дней — конец.
Ключевая фраза: «У нас нет времени чинить самолёт в полёте. Нужно построить планер из обломков».
3. Дмитрий «Огнетушитель» (Head of DevOps & SRE) Возраст: 38 лет.
Профиль: Его команда тушит ежедневные пожары. Знает каждую «горящую» точку инфраструктуры. Прагматик,
мастер быстрых, «убойных» решений, которые хоть как-то стабилизируют систему.
Риск: Его решения увеличивают технический долг. Говорит, что план Марии — чистое безумие.
Ключевая фраза: «Мой приоритет — чтобы система не легла сегодня. О завтрашнем дне будем думать завтра».
4. Анна «Дирижёр» (Project Manager / Scrum Master) Возраст: 32 года.
Профиль: Управляла проектом с самого начала. Видела, как рождался хаос. Отличный организатор, но в условиях
кризиса демотивирована и выгорела. Знает все слабые места в команде и контракте.
Риск: Не верит в успех. Может действовать механически.
Ключевая фраза: «Мы снова срываем дедлайн. Я обновлю график в Jira, но это ничего не изменит».
5. Олег «Переговорщик» (Account & Delivery Manager) Возраст: 45 лет.
Профиль: Лично общался с заказчиком «ГлобалТрейд». Знает, что их раздражает больше всего. Умеет продать
«свисток» как «прорывную функцию». Уверен, что можно договориться о сдвиге сроков или изменении требований.
Риск: Может потратить время на иллюзии. Если переговоры провалятся — время будет безвозвратно упущено.
Ключевая фраза: «Дайте мне две недели и доступ к их СЕО — я решу вопрос со штрафами».

14.

Деловая игра «Построение информационной стратегии организации»
6. Ирина «Генератор» (Lead Frontend-разработчик) Возраст: 29 лет.
Профиль: Талантливый и быстрый инженер. Может за выходные сделать прототип интерфейса, который впечатлит
заказчика. Не погружена в проблемы бэкенда. Энергична, но наивна.
Риск: Её работа может создать иллюзию прогресса, пока бэкенд разваливается.
Ключевая фраза: «Зачем чинить старый движок? Давайте сделаем красивую новую приборную панель — клиент
будет в восторге!»
7. Виктор «Реалист» (Senior QA Automation Engineer) Возраст: 42 года.
Профиль: Пессимист по должности. Его тест-кейсы — это летопись всех багов системы. Не верит в возможность
стабильного запуска. Но именно он может построить «систему сдержек и противовесов» для быстрого контроля
качества любых изменений.
Риск: Его пессимизм может окончательно добить моральный дух команды.
Ключевая фраза: «Любое ваше "быстрое решение" создаст три новых скрытых бага. Вот чек-лист из 87 пунктов,
почему мы провалимся».
8. Сергей «Лидер» (CTO, в отпуске по уходу за ребёнком) Возраст: 41 год.
Профиль: Технический лидер, который создавал компанию. В отпуске последние 4 месяца. Его авторитет
непререкаем. Только он может заставить «Технаря» и «Огнетушителя» работать вместе. Готов экстренно вернуться,
но только если ему дадут карт-бланш.
Риск: Он — часть старой системы, которая привела к кризису. Его методы могут быть устаревшими.
Ключевая фраза: «Я знаю этот проект с пелёнок. Дайте мне команду, и я вытащу их. Но я не буду отчитываться
каждую пятницу».
9. Елена «Правовед» (Юрист по IT-контрактам)
Профиль: Специализируется на контрактах с IT-заказчиками. Точно знает, какие формулировки в договоре с
«ГлобалТрейд» можно использовать, чтобы оспорить штрафы или легально изменить объём работ. Работает только с
документами.
Риск: Полностью оторвана от технической реальности. Её успех — в суде через полгода, а компании нужно выжить
сейчас.
Ключевая фраза: «Пункт 4.3.а позволяет нам трактовать "работоспособную версию" не как полный функционал, а
как стабильный прототип. Это наша лазейка».

15.

Деловая игра «Построение информационной стратегии организации»
10. Артём «Инфлюенсер» (PR-директор) Возраст: 59 лет
Профиль: Мастер создания нарративов. Уверен, что можно смягчить репутационный удар, если правильно подать
историю: «Героические разработчики борются за стабильность для крупнейшего клиента». Имеет связи в медиа.
Риск: Занимается косметикой, а не лечением. Может создать иллюзию контроля у внешнего мира, пока внутри хаос
нарастает.
Ключевая фраза: «Катастрофу можно продать как этап грандиозного прорыва. Доверьтесь мне».
11. Павел «Архивариус» (Data Engineer / Аналитик) Возраст: 36 лет
Профиль: Никто лучше него не знает, где и какие данные хранятся в «Ауре». Может быстро организовать выгрузку
критически важной информации для нового модуля или найти причину бага в неочевидных логах трёхлетней
давности.
Риск: Перфекционист. Стремится к полной целостности данных, что в условиях кризиса — непозволительная
роскошь.
Ключевая фраза: «Прежде чем что-то ломать, давайте я построю полную схему зависимостей данных. Это займёт
неделю».
12. Ксения «Мотиватор» (HR Business Partner) Возраст: 49 лет
Профиль: Понимает глубинные причины выгорания в команде. Может разработать систему экстренной поддержки,
микробонусов и восстановления климата. Знает, кто с кем в конфликте и как это обойти.
Риск: Её методы требуют времени. В аврале её советы («Проведём ретроспективу чувств») могут вызвать
раздражение у технических специалистов.
Ключевая фраза: «Люди не горят из-за deadlines. Они горят из-за отсутствия признания. Дайте мне возможность
это исправить».
13. Максим «Вендор» (Эксперт по зарубежным облачным решениям) Возраст: 19 лет
Профиль: Настоящий фанат конкретного облачного провайдера (например, AWS). Убеждён, что ключ к спасению
— срочно «поднять» ядро «Ауры» в облаке, чтобы получить мгновенную масштабируемость и отказоустойчивость.
Риск: Его решение игнорирует гигантские затраты на миграцию, риски потери данных при переносе и
необходимость переобучения команды.
Ключевая фраза: «Все ваши проблемы — от устаревшего железа. 48 часов в моём облаке — и у вас будет другая
система».

16.

Деловая игра «Построение информационной стратегии организации»
Оптимальный выбор — не просто собрать самых сильных технарей, а создать
управляемый организм, способный действовать на четырёх критических фронтах
одновременно. РЕШЕНИЕ
Рекомендуемый состав Кризисного штаба:
1.Сергей «Лидер» (CTO) — Роль в штабе: Кризисный менеджер. Его авторитет немедленно остановит
распад команды и заставит услышать друг друга таких противостоящих друг другу людей, как «Технарь» и
«Спасатель». Он — единственный, кто может принимать финальные решения, беря на себя ответственность.
2.Мария «Спасатель» (Архитектор) — Роль в штабе: Стратег по продукту. Её радикальный план —
единственная за 75 дней возможность предложить заказчику хоть что-то работающее. Нужен человек,
который будет вести всех к конкретной цели, а не тушить бесконечные пожары.
3.Алексей «Технарь» (Lead Dev) — Роль в штабе: Технический гарант. Без его глубочайшего знания
«костылей» любая попытка что-то вычленить или переписать закончится крахом. Он — «живая
документация» системы.
4.Дмитрий «Огнетушитель» (Head of DevOps) — Роль в штабе: Оперативный командующий. Пока
«Спасатель» и «Технарь» готовят новый планер, он должен удерживать старый самолёт в воздухе. Его
прагматизм — противовес идеализму «Технаря» и авантюризму «Спасателя».
5.Елена «Правовед» (Юрист) — Роль в штабе: Страховой полис. Включение юриста в ядро кризисной
команды — ключевое изменение стратегии. Её задача — немедленно начать работу по легальному
смягчению последствий: формализовать изменения в требованиях, подготовить почву для переговоров по
штрафам, искать договорные лазейки. Это даёт технической команде столь необходимое правовое
прикрытие и пространство для манёвра.

17.

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

18.

Деловая игра «Построение информационной стратегии организации»
РЕШЕНИЕ
Краткий план работы штаба:
1.День 1-2: «Лидер» собирает штаб. «Правовед» начинает анализ
договора. «Спасатель» и «Технарь» делают инвентаризацию модулей для
вычленения.
2.День 3-10: «Огнетушитель» стабилизирует текущую систему на
минимуме функций. «Спасатель» с «Технарём» проектируют два новых
микросервиса. «Правовед» готовит проекты допсоглашений.
3.День 11-75: Жёсткая двухнедельная спринт-машина по разработке и
интеграции под прямым управлением штаба. «Переговорщик»
подключается с готовыми документами от «Правоведа».
Этот состав обеспечивает максимальный контроль над всеми
элементами кризиса: техническим, временным, кадровым и
юридическим.

19.

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%

20.

ЭТАП 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- решение

21.

Выбранные методы сопоставления и диагностики:
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.Постоянная вовлеченность заказчика (реальных пользователей) в процесс через демонстрации — залог того, что итоговый продукт будет
соответствовать реальным, а не формально зафиксированным требованиям.

22.

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,
новый тест-кейс) должно добавляться в соответствующую строку, пока статус не изменится на «Выполнено».