Системы клиентской информации: кейс оборонного предприятия на Ближнем Востоке

Это кейс о том, как средний по размеру оборонный производитель на Ближнем Востоке привёл в порядок свои системы клиентской информации. Данные о клиентах хранились в трёх местах, коммерческие предложения (КП) уходили с противоречивыми ценами, а согласования терялись в почте. Решением стала единая запись о клиенте в Microsoft Dynamics, расчёт КП по правилам в Experlogix CPQ и автоматическая передача утверждённых КП в SAP Sales and Distribution (SD) через SAP Cloud Integration. Срок подготовки КП сократился в среднем на 35 %. Текст адресован руководителям отделов операций продаж, ИТ и финансов в производственных компаниях, где продажи долгие, продукт конфигурируется, а требования соответствия строги. Последовательность внедрения и уроки в конце текста можно использовать повторно.

Когда оборонные команды просят системы клиентской информации, они обычно имеют в виду больше, чем CRM. Им нужна структура: место, где сложные решения хранятся вместе, в контексте, на протяжении долгих циклов продаж, процессов с жёсткими требованиями соответствия и меняющихся групп лиц, принимающих решения.

В роли директора по цифровой трансформации в оборонной компании мне поручили решить именно это. Проблема была не в нехватке усилий. Люди делали свою работу. Беда в том, что у усилий не было дома. Не было общей платформы, прозрачности и согласованности между тем, что продавали, и тем, что планировали.

Средний по размеру оборонный производитель на Ближнем Востоке. Он работал за кулисами: не публичный бренд, и заметность не была целью. Его компоненты применялись в военной авиации и защищённой связи.

Каждая продажа шла по подробному маршруту: инженерные проверки, проверки соответствия, внутренние согласования, КП с контролем версий. Хаоса не было, но процесс был тяжёлым.

Системы клиентской информации разваливались. Продажи работали в одной платформе. Поддержка в другой. Операционный блок работал с таблицами, офлайн-папками и документами, которые устаревали раньше, чем их кто-то открывал.

Вот что было сломано и во что это обходилось:

Что было сломано	Последствия
Не было CRM для потока сделок и обзора лиц, принимающих решения	Не было общей картины того, на каком этапе находится каждая сделка
Цены задавались вручную без единого учёта	КП уходили с устаревшими или противоречивыми цифрами
Согласования шли по почте, их часто теряли или задерживали	Аудиторский след по соответствию требованиям был неполным
Записи о клиентах дублировались в разных системах с небольшими расхождениями в деталях	Никто не мог сказать, какая версия верна

На бумаге всё выглядело структурированно. Но стоило проследить КП от создания до поставки, и картина рассыпалась. Согласования застревали без явного владельца. Цены зависели от того, кто подавал предложение. КП тонули в почтовых цепочках. Команды снова и снова задавали друг другу одни и те же вопросы. Ни один из этих сбоев не был драматичным, но за месяцы мелкие задержки складывались, а для бизнеса с долгими циклами продаж потерянный темп значил больше, чем большинство людей понимало.

Цель была не в том, чтобы всё заменить. Она заключалась в том, чтобы снизить трение и ничего не усложнить в использовании: помочь системам отражать то, как команды уже работали, а не загонять людей в жёсткие процессы.

Прежде чем трогать любые настройки, я провёл время с командами. Я наблюдал, как работа идёт от фиксации до поставки, где инструменты мешали и где люди перестали доверять данным.

Из этих встреч выросли три приоритета:

1. Единая общая запись о клиенте, видимая продажам, поддержке и операционному блоку в одном и том же формате. Больше никаких параллельных версий.
2. Структурированный расчёт КП по единым правилам конфигурации и ценообразования вместо личных привычек и старых шаблонов.
3. Связанное исполнение заказов с чистой передачей из утверждённого КП в SAP SD и без ручного повторного ввода.

Система	Что решала
Microsoft Dynamics CRM	Единая запись о клиенте, связанная с активностью продаж и сделками
Experlogix Configure Price Quote (CPQ)	Правила конфигурации продукта, логика ценообразования, версии КП
SAP Sales and Distribution (SD)	Исполнение заказов и поставка
SAP Cloud Integration (CPI)	Интеграционный слой, соединяющий CPQ и CRM с SAP SD

Microsoft Dynamics как основа. Нам нужно было одно место, где информация о клиентах точна и видна в полном контексте. Dynamics дал нам место, с которого можно было начать распутывать данные. Помогла привычность платформы, а также её стыковка с Outlook и Teams. Людям не пришлось начинать с нуля; нужно было лишь подстроить систему под то, как работает бизнес. Когда команды увидели одни и те же данные в одном формате во всех функциях, начало расти доверие.

Experlogix CPQ для конфигурации и ценообразования. Раньше КП готовили слишком по-разному. Люди полагались на память и ручные правки. Мы настроили Experlogix с чёткими правилами для сочетаний продуктов, ценами, привязанными к конфигурациям, и маршрутизацией согласований по типу и размеру сделки. Сначала это казалось ограничением, и некоторые не стеснялись об этом говорить, но неоднозначность исчезла. Инженеры получали более чистые КП, а продавцы перестали подправлять цены по памяти о прошлых сделках.

SAP SD через SAP CPI. SAP SD уже использовался для заказов. Проблема была в передаче: утверждённое КП всё равно приходилось заново вводить в SAP. Мы связали их через SAP CPI, так что утверждённые КП шли прямо в SAP как заказы, а данные о клиентах и заказах синхронизировались между Dynamics и SAP. Там, где мы упирались в ограничения, мы добавляли собственную логику. Не везде это выглядело изящно, но работало.

1. 01Запись о клиентеMicrosoft Dynamics, одна версия для всех команд
2. 02Конфигурация и ценаПравила Experlogix CPQ для сочетаний и цен
3. 03СогласованиеМаршрут по типу и размеру сделки
4. 04Создание заказаSAP CPI передаёт утверждённое КП в SAP SD
5. 05ИсполнениеSAP SD, данные о клиентах синхронизированы

Без повторного ввода и с аудиторским следом от согласования до заказа

Внедрение шло поэтапно примерно шесть-восемь месяцев. Без драматизма: изменения накладывались слоями, на каждом шаге проверялись.

1. Пилот. Небольшая группа пользователей и конкретные сценарии вокруг CRM и CPQ. Мы тестировали граничные случаи, выявляли пробелы и вносили изменения до масштабирования.
2. Очистка данных. Записи о клиентах консолидировали и дедуплицировали до загрузки в Dynamics, а документы по соответствию привязывали к нужным сделкам. Это заняло больше времени, чем настройка.
3. Расширение на подразделения. Когда процессы пилота были доработаны, решение пришло в продажи, поддержку и операционный блок.
4. Интеграция SAP SD на середине пути. Интеграция CPQ с SAP заработала, когда вышестоящие системы стабилизировались, поэтому ранние проблемы не перекинулись на заказы.

Безопасность и соответствие требованиям закладывались с первого дня. Для оборонного клиента целостность аудиторского следа и ролевой доступ не опциональны. Мы чётко определили роли доступа и фиксировали цепочки согласований. Вопрос размещения данных решили рано: все данные оставались в пределах ОАЭ, в соответствии с правилами оборонного сектора. Сначала это нас немного замедлило, зато предотвратило более серьёзные проблемы позже.

Обучение было практичным: короткие занятия, адресные материалы, живые демонстрации и видеоинструкции, растянутые на недели и месяцы, а не одно занятие. Поначалу внедрение шло не идеально. Постоянная поддержка и заметная польза преодолели первоначальные колебания. Переломный момент наступил, когда команды применили инструменты в реальных ситуациях и убедились, что получаемые данные верны.

Результат	Что изменилось
Срок подготовки КП	Сократился в среднем на 35 %; по многим сделкам сэкономлены часы, по сложным несколько дней
Точность конфигурации	Правила валидации предотвращали ошибки до того, как они доходили до инженеров
Готовность к аудиту	Проверки соответствия больше не требовали спешки в последнюю минуту
Согласованность между командами	Продажи, поддержка и операционный блок работали с одной записью о клиенте

Сокращение на 35 % не случилось за первую неделю. Первые циклы по-прежнему требовали уточнений и исправлений. Когда правила по продуктам и логика ценообразования стали единообразными, подготовка КП ускорилась. Менеджеры по продажам перестали гоняться за согласованиями и править повторно используемые шаблоны. Эти шаги взяла на себя система.

Согласованность важнее технологии. Техническая часть была проще. Труднее было добиться, чтобы команды доверяли одному источнику истины и перестали вести собственные записи. Для этого нужно было показать людям, что данные надёжны, прежде чем просить на них опираться.

Детали интеграции важнее функций. Именно интеграция CPQ с SAP SD сделала всю систему ценной. Отдельная CRM и отдельный расчёт КП с ручным вводом заказов помогли бы каждая понемногу. Трение исчезло на стыке между ними.

Поддержка и обучение закрепляют результат. Развернуть и бросить не значит поставить. Обучение продолжалось недели и месяцы после go-live, и именно в этот период внедрение либо приживается, либо рассыпается.

Архитектура остаётся в силе: CRM для записи о клиенте, CPQ для структурированного расчёта КП, интеграция с ERP для исполнения заказов. Если бы такой же проект стартовал сейчас, изменились бы три вещи.

Интеграционная платформа. SAP CPI теперь представляет собой возможность Cloud Integration внутри SAP Integration Suite, рядом с управлением API, событийной интеграцией и готовым интеграционным контентом. Поток от Dynamics через CPQ к SAP SD сегодня потребовал бы меньше времени на проектирование. Платформа разобрана в моём руководстве по SAP Cloud Integration.

CRM от самой SAP попала бы в шорт-лист. Если на бэкенде стоит SAP SD, в новом проекте следует сравнить SAP Sales Cloud, в который теперь встроен Joule, с Microsoft Dynamics. Dynamics здесь был верным выбором из-за привычности. Ответ по-прежнему зависит от возможностей и предпочтений по интеграции, но вариант от SAP стал более серьёзным претендентом, чем раньше. Варианты разобраны в моём сравнении CRM-систем для SAP.

Для федерального сектора США нужна другая модель хостинга. Этому клиенту она не требовалась, но оборонной компании с операциями для федеральных заказчиков США стоило бы посмотреть на SAP National Security Services (SAP NS2). В 2025 году она получила временную авторизацию на запуск S/4HANA Cloud Private Edition и SAP BTP на уровне FedRAMP+ Impact Level 5, с эксплуатацией только в США.

Специфические для обороны требования (аудиторские следы, ролевой доступ, контроль версий КП, размещение данных) действуют при любом поколении платформы. Более широкую картину соответствия требованиям см. в моём руководстве по соответствию SAP в государственном секторе.

Почему выбрали Microsoft Dynamics, а не другие CRM-платформы?

Она могла вести весь жизненный цикл клиента, от лида через сделку до работы после продажи, и справлялась с долгими сложными циклами оборонных продаж. Стыковка с Outlook и Teams помогла внедрению, а знакомство команды с платформой ещё больше снизило порог.

Управление доступом, журналирование аудита, гибкость и запас для масштабирования стали остальными решающими факторами для клиента с жёсткими требованиями соответствия.

Какую роль сыграл Experlogix CPQ и зачем вообще нужен CPQ?

У оборонной продукции сложные правила конфигурации. Прайс-лист не может описать взаимодействие вариантов продукта, требований соответствия и условий конкретного клиента. Без CPQ каждое КП зависело от того, знает ли составитель правила.

Experlogix перенёс эти правила в инструмент расчёта КП. Менеджер по продажам получал обратную связь по проверке прямо при составлении предложения, а не исправление от инженеров спустя несколько дней. Ошибки сместились вверх по потоку, где их дёшево исправлять.

Как SAP SD интегрировали с CRM и CPQ?

SAP CPI выступал промежуточным слоем. Утверждённое КП в Experlogix запускало поток, который создавал заказ в SAP SD с нужными позициями, ценами и данными клиента. CPI также синхронизировал данные о клиентах и заказах между Dynamics и SAP, а правила валидации не пропускали несовпадающие данные.

Раньше кто-то вручную копировал каждое утверждённое КП в SAP. Автоматизация убрала ошибки повторного ввода и создала чистый аудиторский след от согласования до заказа.

Какие трудности при внедрении были самыми серьёзными?

Первым стало качество данных. Данные о клиентах были несогласованными между подразделениями, с дублями и пропущенными полями, и их пришлось очистить, чтобы Dynamics мог стать источником истины.

Вторым был маппинг интеграции, особенно для конфигураций продуктов и цен в трёх системах. Третьим стало согласование позиций продаж, инженеров, ИТ и финансов, особенно когда менялось владение частями процесса.

Как решались вопросы безопасности и соответствия требованиям?

Это закладывалось с первого дня. Каждый компонент должен был соответствовать внутренним политикам безопасности и национальным нормам. Ролевой доступ ограничивал, кто может видеть и изменять какие записи. Полные аудиторские следы охватывали расчёт КП, согласования и изменения данных. Все данные оставались в ОАЭ, в соответствии с правилами оборонного сектора.

Поскольку проектирование начиналось с этих требований, к проверкам соответствия данные уже были в нужной форме.

Сколько длилось внедрение?

Примерно шесть-восемь месяцев, поэтапно. Начали с пилота по CRM и CPQ, после обратной связи расширили на подразделения, а интеграцию с SAP SD добавили на середине пути, когда вышестоящие системы стабилизировались. Обучение, поддержка и настройка шли всё это время.

Можно ли применить эту модель в других оборонных и производственных компаниях?

Да, везде, где циклы продаж долгие, продукты конфигурируются, а документация по соответствию обязательна: аэрокосмическая отрасль, промышленное оборудование и любой бизнес, где КП перед отправкой требует инженерной проверки.

Конкретные инструменты значат меньше, чем логика интеграции. Утверждённое КП должно попадать в ERP без повторного ввода, а запись о клиенте должна быть единым источником истины.