# Договор подписан — и до свидания: где на самом деле кончается процесс продажи
> Разбор лекции по процессному управлению из программы MBA CIO: где проходят границы под-процессов, почему оценка удовлетворённости без обратной связи бесполезна, как дробление услуги расширяет рынок, когда нужен руководитель проекта над процессами и почему капитализация не бывает целью внедрения системы.
Источник: https://blog.uspeshnyy.ru/blog/dogovor-podpisan-i-do-svidaniya/
Автор: Александр Успешный · blog.uspeshnyy.ru
Опубликовано: 2015-03-21
Теги: MBA, система, продажи, стратегия, Процессное управление, Владислав Сирота
---
Разбираем на занятии схему процесса продажи оборудования. Всё нарисовано аккуратно, но одна деталь ломает конструкцию: **зона ответственности менеджера по продажам заканчивается в момент, когда подписан договор**. Он ставит отметку в системе — и свободен.
Дальше по цепочке начинается знакомое. Отдел закупок обнаруживает, что поставщик поменял линейку, а сроки в договоре назвал продавец — человек, который к закупкам отношения не имеет. Привозят не то, не тогда и не туда. Монтажники, которых клиенту обещали на конкретное число, оказываются заняты: их перебросили к другому заказчику. Клиент звонит и слышит про другой отдел.
Формально каждый выполнил свою работу.
Есть и вторая часть механики, которая закрепляет это намертво. **Бонус продавцу начисляется не в момент закрытия сделки, а спустя время** — по итогам квартала. К моменту выплаты уже неважно, что там было после подписи: деньги придут в любом случае, а если не в этом квартале, то в следующем.
Это десятая, заключительная лекция [процессного управления](/blog/tridcat-pyat-znachkov/) в программе MBA CIO — практикум, где разбирают чужие схемы. Собрал из него то, что применимо к любой компании.
## Граница процесса — это переход ответственности
Правильные границы в той же схеме выглядят иначе. Каждый под-процесс заканчивается **событием, после которого предмет ответственности физически переходит дальше**.
Разберём по звеньям.
**Купля-продажа** заканчивается не подписью под договором, а **переходом права собственности**. Её цель — не «согласовать взаимные обязательства», а сделать так, чтобы нужное клиенту оборудование в нужной спецификации физически оказалось на складе к нужному сроку. Внутри неё живут два под-процесса: подбор оборудования под задачу клиента и появление этого оборудования на складе в срок.
**Доставка** — самостоятельный под-процесс с понятной ценностью: переместить товар из точки А в точку Б. Начинается она с того, что товар уже лежит на складе, заканчивается — доставкой по согласованному адресу в согласованное время. Если клиент забирает сам, доставка нулевая, но процесс существует: **право собственности уже у клиента, а вещь лежит у вас на ответственном хранении**.
**Монтаж и пуско-наладка** заканчиваются подписанным актом: система работает, лампочки горят, клиент принял.
Смысл этого разбиения простой: **пока граница проходит по отметке в системе, а не по переходу ответственности, каждый отдел прав, а клиент недоволен**.
## Черногория: когда сопровождение не входит в процесс
Живая иллюстрация того же дефекта, но в туризме.
Семья приезжает на отдых, переезжает между городами. Трансфер не приходит туда, куда нужно, — а там дети, чемоданы и дороги, по которым пешком не пойдёшь. Когда до места всё-таки добираются, хозяин апартаментов отказывается селить: узнал, откуда гости.
Формально турагент своё сделал: тур продан, документы выданы. По схеме, которую он бы нарисовал, **его действий в этой ситуации не предусмотрено вообще**.
Вопрос, который стоит задать себе на любой схеме: клиент приехал в аэропорт, рейс задержали на трое суток — **что здесь делаете вы?** Если ответ «ничего, это не наша зона», то процесс заканчивается раньше, чем заканчивается ожидание клиента. И клиент это чувствует именно в тот момент, когда ему хуже всего.
## Спросили и записали
Отдельная беда — процесс оценки удовлетворённости, который никуда не ведёт.
Выглядит он безупречно: после монтажа спрашиваем клиента, доволен ли он, фиксируем отметку в системе. Ценность формулируют так: «гарантия качества» и «возможность оперативно подать рекламацию».
Только гарантия — это обещание. А клиенту нужно не обещание, а **устранение проблемы в минимальное время**. Если из процесса оценки не выходит ни одной стрелки назад — в монтаж, в доставку, в закупку, — вы построили механизм сбора жалоб, а не механизм их устранения.
Проверка на схеме буквальная: **посмотрите, куда ведут стрелки из блока «оценка удовлетворённости»**. Если никуда, блок можно убрать — работать он не будет.
**И честная граница ценности.** Обещать нулевое количество дефектов нельзя, и никто не обещает. Производители телевизоров прямо публикуют норму: до пяти битых пикселей — в пределах стандарта, шестой — замена по гарантии. Это и есть честно объявленная граница: клиент знает, где заканчиваются ваши обязательства, и не строит иллюзий. Гораздо хуже, когда границу не называют вовсе.
## Один тур или семь услуг
Мысль, которая на занятии звучит мимоходом, а стоит отдельного разговора.
Турфирма продаёт «тур». Внутри тура живут несколько вещей, каждая из которых имеет самостоятельную ценность:
| Под-процесс | Что получает клиент |
|---|---|
| Подбор | понимание, куда вообще ехать |
| Перелёт | билеты к месту проживания |
| Проживание | забронированный отель или апартаменты |
| Страховка | компенсация возможного ущерба |
| Трансфер | доставка от аэропорта до места |
| Визовая поддержка | документы |
| Сопровождение с гидом | помощь на месте |
Каждую из этих услуг можно продавать отдельно — и за каждую отдельно брать деньги. Вопрос, который стоит задать себе: **зачем искусственно сужать собственный рынок**, если у вас на руках не одна услуга, а семь?
Здесь же — про клиента, который сам не знает, чего хочет. «Хочу в Париж» — это уже сформулированная потребность, и процесс начинается с бронирования. «Хочу куда-нибудь, давно никуда не выбирался» — это другая потребность, и под неё нужен отдельный под-процесс подбора, который показывает варианты. Две разные услуги, два разных чека.
**Где сегодня помогает AI.** Разбор собственной услуги на самостоятельные части — работа на пару часов с моделью: она перечисляет, за что клиент теоретически готов платить отдельно, и сразу видно, что вы отдаёте бесплатно в составе пакета. Дальше остаётся проверить каждую гипотезу на реальных клиентах.
## Над-процесс: когда нужен руководитель проекта
Если услуги разделены и продаются по отдельности, поверх них появляется **комплексное предложение** — над-процесс, у которого есть свой руководитель.
И вот здесь важное различение. Ценность комплексного предложения не в том, что «мы делаем всё», а в том, что **суммарный срок пакета меньше суммы сроков по отдельности**. Если это не так, клиенту выгоднее купить три услуги у трёх подрядчиков.
Отсюда правило: **если каждый атомарный процесс справляется сам, руководитель проекта не нужен**. Планировать нечего — каждый выполняет свою работу и передаёт дальше. Руководитель появляется там, где нужно переигрывать сроки на стыках: здесь монтаж освободился раньше, значит доставку двигаем.
**И про организационную структуру.** В классической функциональной структуре сквозной процесс не живёт: клиент вместе со своей бумажкой скачет между отделами. Сначала в продажи, оттуда в закупки, оттуда за машиной, а на монтаже выясняется, что монтажников перебросили. Красивая схема процесса ничего не изменит, пока структура устроена так, что за весь путь не отвечает никто.
## Внутренняя автоматизация: найдите потребителя
Отдельный сюжет — про ИТ-процессы внутри компании, которые описывают как процессы, а они ими не являются.
Пример: «закупка оборудования». Кажется очевидным процессом — есть вход, есть выход, есть результат. Вопрос, который его проверяет: **есть ли подразделение, которому станет лучше от того, что у вас на складе появились компьютеры?** Если ответа нет, это функция, и ценности она не создаёт.
Когда ответ есть, картина меняется. Пятидесяти новым сотрудникам нужны рабочие места — значит закупка должна происходить **до** возникновения потребности: в конце года разбирают планы развития подразделений, под них согласуют поставщика и пакетный договор с фиксированным объёмом, а платят уже в момент реальной потребности.
**Техническая поддержка** тоже разваливается на два самостоятельных под-процесса, и это стоит запомнить:
- **восстановление работоспособности** — сломалось, чиним быстро;
- **предотвращение отказов** — профилактика, резервирование, откатываемые обновления.
Клиента интересует ровно две вещи: чтобы не ломалось и, если сломалось, чтобы починили быстро. Обещать нулевое время простоя без резервирования невозможно; с резервированием — можно, и вопрос упирается в цену. Считать её надо не саму по себе, а в сравнении с тремя часами простоя того, что она защищает: для бизнеса с высоким оборотом сравнение обычно оказывается не в пользу экономии.
## Зачем внедряют систему: капитализация не бывает целью
И последнее наблюдение, ради которого стоит дочитать.
Владельцы компаний иногда объясняют покупку дорогой системы **повышением капитализации**: вложили полмиллиона — на эту сумму компания стала дороже.
Так это не работает. Лицензии истекают, актив дешевеет, и в залог его никто не возьмёт. Если система при этом ещё и не используется, стоимость её как актива стремится к нулю быстрее срока лицензии.
Осмысленных целей внедрения ровно две, и обе про деньги:
- **увеличение скорости генерации дохода** — новый канал продаж, электронная площадка, интернет-магазин;
- **снижение операционных расходов** — но здесь нужна честная арифметика. Если ускорение документооборота потребовало содержать больше людей, чем сократило, эффекта нет, сколько бы ни стоила система.
## Вывод
Серия по процессному управлению заканчивается там же, где началась: ценность создаётся не внутри отделов, а на стыках между ними.
Три вещи стоит унести. **Граница процесса проходит по переходу ответственности, а не по отметке в системе** — и если бонус выплачивается позже, чем ответственность заканчивается, схема не удержится ни на каком регламенте. **Из оценки удовлетворённости должны выходить стрелки назад**, иначе это сбор жалоб, а не управление качеством. И **комплексное предложение имеет смысл, только если пакет быстрее суммы частей** — иначе вы продаёте клиенту собственные внутренние сложности.
**Следующий шаг:** возьмите свой процесс продажи и найдите точку, в которой сотрудник считает свою работу законченной. Потом найдите точку, в которой клиент считает, что получил результат. Расстояние между этими двумя точками — это и есть та часть работы, за которую у вас сейчас не отвечает никто.