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

Компания на подъеме. Только что пришел новый руководитель на новый отдел, созданный слиянием двух команд. То есть передним стоит задача разобраться с тем как работает два разных набора специалистов, два набора привычек «как у нас принято» и практически нет времени, чтобы превнести свой опыт.

И он формулирует запрос — заметьте, со своей позиции формулирует его совершенно здраво: «Нам нужна CRM. Только не стандартная. Своя, заточенная под наши процессы и наших людей». Желание понятное: людей и процессов много, держать всё в голове трудно, а держать надо — значит, нужен инструмент.

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

Но давайте зададим себе вопрос: что именно здесь заказано?

В начале двухтысячных оно означало вполне конкретную вещь — программу для отдела продаж, «управление взаимоотношениями с клиентами», как и написано в расшифровке аббревиатуры. Потом производители начали пристраивать к ней модули: задачи, документы, склад, телефония, аналитика.

Каждый модуль по отдельности был разумен. Но в результате слово растянулось до размеров «программа, в которой компания работает», и точное значение из него ушло. Сегодня, когда руководитель произносит «CRM», он ссылается не на категорию софта, а на собственное представление о порядке. А представления о порядке у всех разные.

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

**Первая — база клиентов.** Кто нам звонил, что мы ему обещали, на чём остановились, когда договорились созвониться снова. История взаимоотношений, которая принадлежит компании, а не записной книжке менеджера. Боль за этим запросом всегда одна: менеджер ушёл в отпуск или уволился — и вместе с ним из компании ушли клиенты, потому что вся история сотрудничества хранилась у него в голове и в личной переписке.

**Вторая — планировщик поручений.** Я поставил задачу, у неё есть срок и ответственный, и я без напоминаний вижу, выполнена она или тихо умерла. К клиентам это может не иметь никакого отношения: поручения бывают про склад, про документы, про ремонт погрузчика, про то, чтобы наконец повесили новую вывеску. Запрос рождается из усталости: руководитель однажды замечает, что половину рабочего дня тратит на вопрос «ну что там с тем, о чём мы говорили в понедельник?».

**Третья — картина по людям.** Чем занят каждый из моих двадцати человек прямо сейчас? Кто перегружен и скоро начнёт ошибаться, кто недозагружен и прячется за чужой спиной? Это запрос не про клиентов и не про задачи — это запрос про людей. Он особенно обостряется ровно в той ситуации, с которой я начал: сотрудников стало вдвое больше, и половину из них руководитель пока знает только по именам.

**Четвёртая — отчётность для руководителя.** Одна картинка вместо десяти таблиц: выручка, воронка, просрочки, загрузка, дебиторка. Чтобы утром открыть один экран и за пять минут понять, что происходит в бизнесе, — вместо того чтобы к обеду собрать три версии правды из трёх источников и не поверить ни одной.

**Пятая — «место, где всё лежит».** Единое хранилище: договоры, переписка, реквизиты, коммерческие предложения, история решений. Чтобы перестать искать нужный документ по чатам, почте и папкам на компьютере уволившегося сотрудника.

Возможно, это неочевидный момент, поэтому проговорим его в явном виде: это пять разных систем. У каждой свой центральный объект. В первой в центре стоит клиент. Во второй — задача. В третьей — сотрудник. В четвёртой — показатель. В пятой — документ. Всё остальное в системе выстраивается вокруг этого центрального объекта, как шестерёнки вокруг главного вала.

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

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

А исправить это потом настройками не получится. Центральный объект системы — фундамент здания: всё, что выше, опирается на него. Если система построена вокруг сделки, а вам на самом деле нужно было видеть людей и их загрузку, вы будете вечно прикручивать к ней обходные отчёты и параллельную табличку «для реальной картины». Кстати, параллельная табличка рядом с внедрённой системой — самый честный диагноз, который бизнес может себе поставить: она безошибочно показывает, чего в системе нет.

Приём первый: вспомните последний момент, когда вы физически ощутили потерю контроля. Не абстрактное «всё разваливается», а конкретный эпизод. Клиент позвонил с претензией, о которой вы узнали последним. Сотрудник два дня делал работу, которая уже никому не нужна. Вы пообещали партнёру цифру и вечером не смогли её подтвердить. Чего именно вы не увидели в тот момент? Ответ почти всегда указывает на один из пяти центральных объектов.

Приём второй: представьте один-единственный экран, который вы открываете утром. На нём помещается семь-десять строк, не больше. Что там написано? Фамилии людей и их загрузка? Клиенты и стадии сделок? Просроченные поручения? Цифры за вчерашний день? То, что вы мысленно поставили в первую строку этого экрана, и есть ваш центральный объект. Остальное — важное, но второе. До второго тоже дойдёт очередь, только не в первом шаге.

Менеджер по продажам, скорее всего, расскажет про клиентские карточки. Логист — про то, что перестанут теряться заявки. Бухгалтер поморщится и вспомнит прошлое внедрение. Если ответы разошлись — а они разойдутся, — вы своими глазами увидите те самые пять систем под одним словом, только теперь внутри собственной компании.

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

За фразой «только не X» обычно стоит одно из двух. Либо неудачный прошлый опыт: было внедрение, оно оставило шрам, и теперь всё похожее на тот инструмент вызывает отторжение. Тогда полезно разобрать, что именно тогда пошло не так, — с высокой вероятностью причина была не в платформе, а как раз в непроговорённом центральном объекте, и на новой платформе история повторится.

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

Бывает и третье, самое простое: «не хотим как у всех». За этим стоит верное ощущение, что бизнес у компании свой, непохожий, — и опасный вывод, что поэтому и софт должен быть написан с нуля. Ощущение стоит сохранить, вывод — проверить: уникальность компании почти всегда живёт в процессах и людях, а не в том, какими кнопками это обслуживается.

**Вопрос первый: что стоит в центре?** Если вы проделали упражнения из предыдущего раздела, ответ у вас уже есть. Осталось записать его одной фразой: «система, в центре которой стоит ..., потому что ...». Эта фраза — первая строка будущего технического задания, и она важнее всех остальных строк вместе взятых.

**Вопрос второй: какое решение вы сейчас принимаете на ощущениях, а хотите принимать на данных?** Кого премировать по итогам квартала. Какого клиента пора отпустить. Куда направить освободившиеся руки. Кому из двух бывших отделов отдать спорный заказ. Система оправдывает себя тогда, когда меняет качество конкретных решений, а не когда «всё стало в одном месте». Если такого решения назвать не получается — это сигнал, что заказывать систему рано: вы купите склад данных, к которому никто не будет ходить.

**Вопрос третий: кто будет вносить данные и что он получит взамен?** Любая система живёт ровно до тех пор, пока людям выгодно её наполнять. Если менеджер тратит двадцать минут в день на заполнение карточек и не получает от системы ничего, кроме контроля над собой, — мы с вами знаем, чем это закончится. Через месяц-полтора данные перестанут отражать реальность. А решения на мёртвых данных опаснее решений на ощущениях: ощущениям руководитель хотя бы не доверяет полностью, а красивому отчёту — доверяет.

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

Софт эту формулировку только фиксирует. Сформулировано точно — и даже скромный по деньгам инструмент наведёт порядок. Не сформулировано — и самая дорогая разработка «под вас» аккуратно закрепит хаос в программном коде, где менять его дороже, чем в головах.

Как выглядит такая формулировка на практике? Это одна-две страницы обычного текста, без единого технического термина. Что стоит в центре и почему. Какие четыре-пять решений система должна поддерживать.

Кто и в какой момент вносит данные, что получает взамен. Что руководитель видит на утреннем экране. Что в компании поменяется в ближайший год и как система это переживёт.

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

Если вы сейчас в точке «инструмент нужен, но с чего начать — непонятно», начните с диагностики. За одну рабочую сессию мы помогаем руководителю сформулировать, что должно стоять в центре его системы и какие решения она обязана поддерживать, — до того, как эта формулировка начнёт стоить денег у разработчика. Напишите нам на melalex@chelovekplusplus.ru — обсудим вашу ситуацию.