Когда мы начинали делать CRM все выглядело довольно привычно. Формулировка была простая и понятная: нужна CRM. То есть система, в которой можно вести клиентов, сделки, фиксировать этапы работы, хранить контактные данные, документы и в целом навести порядок в процессе продаж. На старте это действительно выглядело как классическая история про CRM: есть заказчик, есть менеджер, есть продажа, есть какая-то логика движения сделки. Ничего необычного.
Но такие проекты почти никогда не раскрываются в самом начале в полном объеме. Пока все существует в виде общей формулировки, кажется, что речь идет о довольно стандартной задаче. А потом начинается реальная работа, и постепенно выясняется, что за словом «CRM» может скрываться вообще совсем другая система.
Проблема в том, что CRM — это довольно расплывчатое слово. Для кого-то CRM — это записная книжка с клиентами. Для кого-то — воронка продаж. Для кого-то — большая корпоративная система с задачами, документами, согласованиями и отчетами. Но если смотреть строго по смыслу, то классическая CRM все-таки крутится вокруг клиента и сделки. В центре такой системы находится история взаимодействия с клиентом: как пришел, кто с ним общался, что ему предложили, на каком этапе находится продажа, чем все закончилось. Это логика коммуникации и продажи.
А у нас довольно быстро стало понятно, что в центре процесса находится не просто клиент и даже не сделка. В центре находится сам продукт и все, что с ним связано до продажи, в момент продажи и после продажи. И вот в этот момент проект начал очень заметно уходить в сторону от классической CRM.
Сначала кажется, что это мелочь. Ну добавили карточку продукта. Ну добавили немного справочной информации. Ну сделали больше полей в сделке. На этом этапе многие еще продолжают думать, что все это по-прежнему обычная CRM, просто чуть более подробная. Но потом ты начинаешь раскладывать систему по сущностям и видишь, что она уже живет по совсем другой логике.
Появляется не просто клиент, а несколько разных участников процесса. Есть организация, которая оформляет заказ. Есть партнер, через которого идет взаимодействие. Есть компания, которая участвует в производственной или конфигурационной части. Есть конечный получатель. И это уже не одно и то же лицо и не одна и та же сущность. Это разные роли в одном процессе, и каждая из них должна жить в системе отдельно.
Потом появляется сам продукт как отдельный объект учета. Не как строка в сделке и не как условное название в комментарии менеджера, а как полноценная сущность со своей карточкой, своими характеристиками, документами, статусами, историей и дальнейшей жизнью внутри системы. И вот тут становится понятно, что система начинает строиться уже не вокруг продажи, а вокруг объекта.
Дальше больше. Выясняется, что продукт не исчезает из системы после того, как сделка закрыта. Наоборот, после этого у него начинается следующая жизнь. У него появляются документы, связанные с поставкой и сопровождением. У него есть сервисная история. По нему могут возникать обращения, согласования, претензии, дополнительные работы, расходы, изменения статусов, накопление аналитики. То есть продажа — это не финал, а только один из этапов большого маршрута.
В этот момент слово CRM уже начинает звучать слишком узко. Потому что CRM в классическом понимании не обязана знать, что происходит с продуктом после продажи, какие у него документы, кто его фактический пользователь, какая по нему история обслуживания, какие согласования по нему проходили, какие дополнительные сущности были задействованы и как все это между собой связано. Для обычной CRM это уже избыточная глубина.
А здесь глубина как раз и была нужна. Причем нужна не ради красоты структуры и не ради сложной схемы, а потому что сам бизнес-процесс так устроен. Если попытаться все это упростить до уровня «клиент — сделка — комментарий», система быстро начинает врать. Формально данные есть, а реальную картину они не отражают. И вот это, наверное, главный момент, в котором многие проекты ломаются: когда пытаются натянуть реальный процесс на слишком простую модель.
Если смотреть совсем по-простому, то классическая CRM отвечает на вопрос: кто пришел, что хотел, что ему продали и на каком этапе находится работа менеджера. А система, которую мы в итоге сделали, отвечает на другой вопрос: какой именно продукт проходит через систему, кто в нем участвует на разных этапах, кто его заказал, кто его получил, какие документы к нему относятся, что с ним происходило дальше и как вся эта история выглядит целиком. Это уже совсем другая глубина учета.
По сути, когда таких связей становится много, CRM начинает превращаться в ERP-логику. Потому что ERP — это уже не про общение с клиентом как таковое. ERP — это про учет процессов, объектов, ролей, состояний и маршрутов между подразделениями. Там важен не только факт продажи, а все, что происходит вокруг нее. Кто участвует. Что передается. В каком состоянии находится объект. Какие есть документы. Какие есть ограничения. Какие действия происходят дальше. Какие подразделения вовлечены. Какая информация должна быть доступна на каждом этапе. Как данные переходят из одного процесса в другой.
Именно это у нас и произошло. Система перестала быть системой одного отдела. Она уже не обслуживает только продажи. Она связывает между собой несколько зон: коммерческий блок, учетный блок, блок сопровождения, блок документов, блок статусов, блок справочников, блок ролей и прав, а потом еще и аналитику сверху. Это уже не инструмент менеджера по продажам. Это уже общая рабочая среда, в которой живет сама логика продукта.
Но и слово ERP тут тоже не до конца все объясняет. Потому что в какой-то момент стало видно еще одну вещь: система хранит не только процесс сделки и не только маршрут документа, а саму структуру знания о продукте. Не просто название, а характеристики. Не просто наличие, а конфигурацию. Не просто факт передачи, а набор связанных данных, которые потом продолжают использоваться в других частях системы. И здесь логика начинает приближаться уже к PLM.
PLM обычно воспринимают как что-то очень большое, промышленное и почти всегда слишком тяжелое для обычного разговора. Но если убрать всю академическую упаковку, то PLM по сути — это подход, в котором продукт рассматривается как центральный объект на всем его жизненном цикле. От исходных параметров и конфигурации до сопровождения, изменений, эксплуатации и накопления истории по нему. И вот именно это мышление очень незаметно начало формироваться внутри системы.
Сначала продукт появился как объект в продаже. Потом стало понятно, что его карточка должна быть не декоративной, а рабочей. Потом к этой карточке стали привязываться документы. Потом стало важно, какие именно участники связаны с конкретным продуктом. Потом стало важно, какие обращения по нему были. Потом стало важно, что с ним происходило после передачи. Потом стало важно, как хранить это не в виде разрозненных заметок, а в виде связанной структуры. А это уже чистая логика жизненного цикла объекта, а не просто логика клиентской базы.
И в какой-то момент стало очевидно, что мы уже давно не делаем просто CRM. Мы делаем систему, в которой есть и CRM-часть, и ERP-часть, и кусок PLM-логики. Причем это не была попытка специально написать какую-то огромную аббревиатурную платформу ради сложных слов. Все получилось наоборот: мы шли от реального процесса, и сама структура системы постепенно вывела нас туда, куда вывела.
Это важный момент. Очень часто системы становятся плохими именно потому, что их начинают строить от модного названия. Хотят сделать CRM — и все начинают загонять в CRM. Хотят сделать ERP — и сразу на старте получают тяжеловесного монстра. Хотят сделать PLM — и тонут в абстракциях раньше, чем появляется хоть один рабочий экран. У нас путь был обратный. Мы начали с прикладной задачи, а уже потом увидели, во что она по факту выросла.
И это, на самом деле, гораздо здоровее. Потому что система не выдумана из теории. Она выросла из конкретной необходимости. Если в процессе работы выясняется, что у тебя недостаточно просто учитывать клиентов и сделки, значит нужно учитывать еще и продукт как центральную сущность. Если выясняется, что одного продукта мало и важны еще участники процесса, значит появляются отдельные сущности под эти роли. Если после продажи начинается длинная и важная жизнь объекта, значит система должна это сопровождать. Если по объекту копятся документы, согласования и история, значит это уже должно быть частью модели, а не просто приложением к сделке.
Именно поэтому в таких проектах очень быстро становится понятно, почему стандартные коробочные CRM обычно не подходят без серьезной переделки. Они изначально думают в другой логике. Для них центр мира — клиент и сделка. Для них продукт чаще всего вторичен. Для них постпродажный цикл обычно не является сердцем системы. Для них сложные связи между несколькими независимыми сущностями — это уже нестандартный сценарий. И вот когда пытаешься натянуть на такую платформу реальную многоуровневую предметную область, начинаются костыли.
У нас же логика строилась сразу изнутри процесса. И поэтому система получилась не самой простой по устройству, но зато честной по отношению к бизнесу. В ней нет искусственного упрощения, когда ради удобства платформы искажают саму модель данных. Это, кстати, одна из самых частых проблем в корпоративной автоматизации: когда бизнес-процесс начинают ломать под систему, а не систему делать под бизнес-процесс. Сначала это кажется экономией, а потом выливается в постоянные обходные пути, ручные операции, дублирование данных и раздражение всех участников процесса.
Когда система строится вокруг продукта и его жизненного цикла, очень многое становится на свои места. Появляется понятная ось, вокруг которой собираются остальные сущности. Сделка больше не висит в воздухе, а привязана к конкретному объекту. Участники процесса тоже перестают быть абстракцией и занимают свои роли. Документы получают свое место. Сервис перестает быть внешним хвостом после продажи и становится продолжением общей истории. Аналитика начинает собираться не из разрозненных таблиц, а из реальной структуры данных. И даже права доступа становятся логичнее, потому что уже понятно, кто в этой системе работает с чем именно.
Интересно, что внешне такая система все равно может выглядеть как CRM. У нее есть карточки, разделы, сделки, пользователи, статусы, документы. Если смотреть только на интерфейс верхнего уровня, можно даже не заметить, насколько сильно изменилась внутренняя логика. Но суть определяется не тем, как это называется в меню, а тем, вокруг чего строится сама модель. А модель в нашем случае строится уже не вокруг клиента как такового, а вокруг продукта и связанных с ним процессов.
Наверное, самая точная формулировка здесь такая: мы начинали делать CRM, а в итоге сделали систему, в которой CRM — это только один из слоев. В ней есть коммерческий слой, потому что без него нельзя. Есть учетный слой, потому что без отдельного объекта продукта все распадается. Есть процессный слой, потому что продукт проходит через несколько состояний и подразделений. Есть сервисный слой, потому что работа не заканчивается продажей. И есть слой накопления знаний о самом продукте, его параметрах, документах и истории. И вот именно сумма этих слоев уже выводит систему за рамки обычной CRM.
Поэтому если совсем коротко и без красивых слов, то история получилась довольно простая. Начинали с мысли «сделаем CRM, чтобы было удобно работать с заказами и клиентами». А когда начали честно раскладывать реальный процесс на сущности, роли, документы, статусы и дальнейшую жизнь продукта, стало понятно, что это уже совсем другой класс системы. Не в теории, а по факту.
И в этом, наверное, главный вывод. Иногда проект вырастает во что-то большее не потому, что кто-то решил его усложнить, а потому что сама реальность процесса оказывается глубже, чем казалось на старте. И если эту глубину не игнорировать, а нормально оформить в системе, то в какой-то момент ты просто честно признаешь: да, мы начинали делать CRM. Но сделали уже ERP/PLM-систему, потому что сам процесс требовал именно этого.
17 марта 2026