Менеджер встретился с клиентом. Встреча прошла хорошо: клиент задавал вопросы, интересовался решением, попросил сделать расчет. Компания быстро подключила технических специалистов, подготовила технико-коммерческое предложение (ТКП). Менеджер отправил файл, поставил в CRM высокую вероятность сделки. Через неделю клиент сказал: «Смотрим». Через месяц – «Пока согласовываем». Еще через месяц выяснилось, что в проект уже заложено решение другого поставщика.
Что мешает закрыть проектную продажу
Сложную B2B-сделку нельзя воспринимать как более длинную версию обычных продаж: недостаточно позвонить, выявить потребность, провести презентацию и отправить коммерческое предложение. Нужно управлять системой принятия решения. Разберу ключевые моменты, где происходит сбой.
1. Клиент – это не один человек
Одна из самых дорогих ошибок в проектных продажах – считать своим клиентом того человека, с которым удалось установить хороший контакт. Он может искренне поддерживать ваше решение, отвечать на звонки, приглашать на встречи и даже говорить, что «все выглядит хорошо». Но рядом с ним почти всегда есть другие участники: проектировщик, технический специалист, руководитель проекта, представители отделов эксплуатации, закупок, финансового блока и руководство. И у каждого из них своя логика:
- Инженеру важно, чтобы решение работало и не создало ему проблем.
- Руководителю проекта – чтобы не сорвались сроки.
- Отделу эксплуатации – чтобы с этим решением потом можно было жить.
- Отделу закупок – чтобы процедура была соблюдена, а цена выглядела обоснованной.
- Руководству – чтобы риск решения был приемлем.
Иногда человек, который больше всех разговаривает, влияет на конечный выбор меньше остальных. Поэтому недостаточно определить лицо, принимающее решение (ЛПР). Гораздо полезнее понять, какие этапы решение о сделке проходит внутри организации.
- Кто формирует требования?
- Кто сравнивает варианты?
- Кто может остановить решение?
- Кто способен его защитить?
- У кого есть формальные полномочия, а у кого – неформальное влияние?
Пока этой картины нет, менеджер не управляет проектной продажей, а лишь питает надежды.
2. Интерес клиента еще не означает движение сделки
После хорошей встречи с клиентом менеджеру психологически хочется считать, что проект движется. Но интерес и движение – разные вещи. Можно полгода быть в прекрасных отношениях с человеком со стороны клиента и не приблизиться к подписанию контракта ни на один шаг. Поэтому в проектной продаже важно отслеживать, что реально меняется в проекте после последнего контакта с клиентом.
- Появился доступ к новому участнику?
- Согласованы критерии?
- Изменилось техническое решение?
- Получены исходные данные?
- Назначена защита?
- Определен следующий шаг?
Если ничего из этого не происходит – сделка просто стоит.
3. Отправку коммерческого предложение считать окончанием работы
У менеджеров есть странная привычка считать коммерческое предложение финальной точкой работы: получили запрос, подготовили, отправили, ждем. Но оно лишь фиксирует детали предложенного решения. Если продавец не понимает критерии выбора клиента, ограничения проекта, риски и внутреннюю логику согласования, хороший PDF-файл ничего не исправит. Технический специалист может подготовить безупречное решение. Маркетолог – красиво его оформить. Компания – дать конкурентную цену. И все равно проиграть, потому что конкурент работал не с документом, а с системой принятия решения. После отправки ТКП работа не заканчивается, а становится сложнее.
- Кто будет рассматривать предложение?
- С чем его будут сравнивать?
- Какие вопросы возникнут?
- Нужно ли решение защищать перед техническим блоком?
- Попадает ли оно в бюджет?
- Кто способен заменить его на более привычный вариант?
- Что произойдет дальше?
Фраза в CRM «КП отправлено» описывает действие продавца и почти ничего не говорит о состоянии сделки.
4. Не учитывать риск изменения
Лучшее техническое решение может проиграть. Это особенно тяжело принять людям с инженерным складом мышления. Если решение объективно сильнее, кажется логичным, что его должны выбрать. Но клиент делает выбор не в лаборатории, а внутри организации. Новое решение может быть надежнее, быстрее в монтаже или выгоднее в эксплуатации – и все равно проиграть. Причины могут быть разными:
- Привычный вариант уже заложен в проект.
- Проектировщик не хочет переделывать документацию.
- Технический специалист не хочет брать на себя риск замены.
- Закупке проще сравнить три одинаковые позиции.
- Человеку, который должен защищать новое решение перед руководством, никто не дал нормальной аргументации.
В этот момент менеджер часто думает, что клиент сделал выбор только по цене. Не всегда это так. Иногда компания просто не помогла клиенту безопасно принять другое решение. В проектных продажах продавать приходится не только преимущества продукта, но и работать с риском изменения.
5. Разрыв коммуникации на стороне продавца
Сложную проектную продажу редко способен провести один менеджер. Ему нужны технические специалисты, расчетчики, проектный блок, производство, логистика, сервис, иногда юристы и руководство. Для клиента все это – одна компания, ему безразлично, что один отдел не передал информацию другому. Типичный сценарий: менеджер обещал одно, технический специалист понял задачу немного иначе, в КП появилась третья версия, сроки производства никто заранее не проверил, после заключения договора новый руководитель проекта получил документацию, но не получил контекст предыдущих переговоров. Формально каждый выполнил свою часть работы, но для клиента система дала сбой. Поэтому проектные продажи требуют управлять не только внешней картой влияния, но и собственной командой. Иначе поставщик начинает создавать для клиента тот самый риск, от которого обещал его защитить.
6. CRM не отражает реальную динамику сделки
В простой продаже этапы «Контакт», «Встреча», «КП», «Переговоры», «Договор» еще могут что-то объяснять, в проектной – этого мало. Представьте две записи в CRM cо статусом «Переговоры».
- В первой известны участники решения, техническое решение согласовано, бюджет подтвержден, через неделю назначена защита.
- Во второй – менеджер два месяца периодически звонит одному контакту и слышит: «Пока думаем».
В системе они могут находиться на одном этапе, но с точки зрения реальной вероятности сделки между ними пропасть. Поэтому хорошая воронка проектных продаж должна не только показывать, где находится сделка, но и за счет чего она должна перейти дальше.
- Есть ли следующий шаг?
- Кто за него отвечает?
- Когда он произойдет?
- Что сейчас мешает?
- Какой факт подтверждает текущий этап?
Если на эти вопросы нет ответа, процент вероятности в CRM отражает скорее настроение менеджера, чем дает прогноз по продаже.
7. Превращать гипотезы о клиенте в факты
Разбирая сложные сделки, я постоянно слышу формулировки: «Им важна цена», «Технический директор за нас», «Закупка будет давить», «Проект точно состоится», «Конкурент у них слабый». Иногда все это правда. Но сначала стоит проверить источник информации. Клиент сам так сказал? Есть документ? Кто может подтвердить информацию? Или менеджеру просто так кажется?
В проектных продажах гипотезы необходимы. Без них невозможно планировать следующий шаг. Проблема начинается тогда, когда гипотеза незаметно превращается в факт, и на ней строится дальнейшая стратегия. Поэтому разбирая сделки, не стоит сразу выдавать менеджеру советы. Сначала нужно очистить картину.
- Что мы действительно знаем?
- Чего не знаем?
- Что предполагаем?
- Что необходимо проверить?
Очень часто уже после этого становится понятно, какой следующий шаг нужен.
Вывод
Проектные продажи разваливаются постепенно. Когда не поговорили с одним из участников, не проверили одну гипотезу, отправили ТКП без обсуждения, не договорились о следующем действии, пропустили изменение проекта, не передали информацию техническому специалисту или решили, что хороший контакт означает поддержку всей организации. Подождали неделю, еще одну, а через три месяца появляется удобное объяснение: «Проиграли по цене». Как правило, цена оказывается последней видимой точкой в этой длинной цепочке.
Проектные продажи – это не набор приемов убеждения, а управление движением сложного решения через людей, технические требования, риски, деньги, сроки и внутренние процессы двух организаций. Сильный менеджер в этом деле не тот, кто говорит громче всех, и быстрее всех отправляет КП, а тот, кто в любой момент способен ответить на четыре вопроса:
- Где реально находится проект?
- Кто влияет на следующее решение?
- Что мы пока только предполагаем?
- Какой конкретный шаг должен произойти дальше?
Если ответов на них нет, то сделкой пока управляет кто-то другой.
Читайте также:
Маркетинг - это не моя компетенция, поэтому я не могу быть экспертом в этой области. Я могу лишь на основе своих наблюдений поделиться обобщенными фактами (опять все в проекции моей профдеформации никак не связанной с маркетингом).
А на основе моего опыта, связка capture / проектная продажа → выбор и квалификация → APQP / интеграция → реализация проекта мне не понятна, т.к. по моим наблюдениям APQP распространяется на весь процесс (от концепции - формулировании требований - оценка и выбор поставщиков - совместная разработка ...)
Вот пример (давнишний, могу без опасений поделиться): FORD во Всеволожске объявляет тендер на поставщика комплектов кресел (вариативность по цвету, оборудованию, модификациям существенно большая) на сборочный конвейер автомобилей FORD FOCUS.
Требования к поставщику:
FORD выберет поставщика, который предложит лучшие гарантии такой гибкой работы без сбоев при приемлемых соотношениях цена/качества.
В итоге, тендер выиграла корпорация Johnson Controls построив в 60 км (гарантия времени поставки в 2 часа) от сборочного конвейера минизавод по производству кресел в соответствии с требованиями и моделью работы FORDa. А например, американская корпорация Lear, которая поставляет кресла на конвейер ГАЗа и на момент тендера имела соответствующую производственную площадку в РФ этот тендер проиграла.
Для этого в корпорации Johnson Controls была создана своя APQP команда по работе с APQP командой FORDa во Всеволожске, которая начала свою работу еще до момента выбора FORDом поставщика кресел (FORD выбирал поставщика, работая с APQP командами претендентов, в т.ч. от Lear Corporation).
FORD при этом курировал (согласовывал, мониторил, был соразработчиком) программу развития/действий поставщика под свои требования (у FORDа такая программа называется Q1)
Выводы, которые я делаю: (1) без такой плотной работы в APQP формате поставщиком FORDа не стать и (2) этот результат выбора будет известен (на начальной стадии стороны решения принять не могут) только в APQP процессе, поэтому никакого решения по выбору по результатам предварительной работы CAPTURE команды нет (т.е. эта CAPTURE команда сразу должна стать по составу APQP командой, которая понимает стадии/этапы проработки, терминологию, стандарты ... и будет сопровождать этот проект на протяжении всего его жизненного цикла (не закончит свою работу после "кивка головой")
Владимир, а откуда в нашем разговоре вообще появился маркетинг?
Я маркетинг не обсуждал и экспертом по маркетингу себя здесь не представлял. Моя статья — о проектной продаже: как поставщик выигрывает или проигрывает сложную возможность, когда есть конкуренты, несколько участников решения, технические требования, деньги и риски.
Возможно, часть нашего расхождения действительно в языке. Вы описываете работу через терминологию APQP, цепей поставок, виртуального конвейера, реагирующих транзакций и межфункциональных команд. Я привык сначала раскладывать ту же работу на конкретные управленческие задачи.
Чтобы не создавалось впечатление, будто я смотрю на сложный проект только из позиции «продавец — закупщик — CRM», немного добавлю контекста.
Я знаком с Производственной системой Росатома не по пересказам: 5С, картирование потока создания ценности, поток единичных изделий, работа с потерями и организацией производства.
На Курской АЭС-2 я запускал непосредственно на строительной площадке производство воздуховодов 2-го и 3-го классов безопасности.
Мы заранее понимали риски поставок и объём будущей потребности, поэтому производство создавалось именно под поток проекта. Я участвовал в выборе технологии и оборудования, раскладке цеха, движении материала, расстановке рабочих мест. Буквально ходил с миллиметровкой и собирал схему производства.
Логика была как раз в том, чтобы не создать склад готовой продукции, а максимально приблизить выпуск к реальной потребности монтажа: изготовили — передали дальше в работу.
Поэтому сама идея межфункциональной команды, потока, изменчивости, интеграции производства и поставщиков мне вполне понятна и без автомобильного примера.
Именно поэтому я не согласен с противопоставлением:
«старый функциональный мир — продавец, закупщик и CRM» против «современного APQP — межфункциональная работа в неопределённости».
На больших строительных и промышленных проектах межфункциональная работа, изменения, производство под проект, логистика, качество, ограничения поставщиков и работа в неопределённости существовали и существуют независимо от того, называется всё это APQP или каким-то другим набором терминов.
И здесь у меня остаётся тот же вопрос: где заканчивается APQP?
Если включить в него концепцию, формирование требований, работу с потенциальными поставщиками, конкурентный выбор, квалификацию, разработку продукта и процесса, производство, логистику, запуск, изменения и весь последующий жизненный цикл, то APQP начинает означать практически всю межфункциональную деятельность вокруг сложного проекта.
Тогда мы рискуем просто назвать одним термином несколько разных управленческих функций.
Но после вашего примера с Ford я решил сделать ещё одну вещь — просто проверить сам кейс по открытым источникам.
И здесь появились уже не терминологические, а вполне конкретные вопросы.
Johnson Controls действительно в 2005 году запустила под Петербургом JIT-производство кресел для Ford Focus. Это подтверждается самой Johnson Controls.
Но утверждение о производительности всеволожского конвейера 20 000 автомобилей в месяц у меня с открытыми данными не сошлось.
20 тысяч в месяц — это 240 тысяч автомобилей в год.
Между тем в 2006 году Ford сообщал об увеличении мощности Всеволожска с 30 до 60 тысяч автомобилей в год и рассматривал дальнейшее увеличение до 72 тысяч. Даже последующее расширение под Focus и Mondeo давало другой порядок цифр.
Второй момент ещё интереснее.
Я пока не нашёл подтверждения именно описанного вами тендера, где Johnson Controls победила Lear за поставку кресел для российского Focus.
Зато находится публично описанный тендер 2008 года на кресла для Mondeo во Всеволожске — и там результат обратный: Lear выиграла у Johnson Controls, которая к тому моменту уже поставляла сиденья для Focus.
Возможно, речь действительно о другом, более раннем тендере. Возможно, в воспоминании просто соединились два разных кейса. Такое спустя много лет вполне бывает.
Но тогда нужен источник.
Есть вопрос и к Q1.
Вы написали, что для заключения сделки новый поставщик должен был выполнить программу Q1. При этом в документации Ford существует статус Working Toward Q1 для нового поставщика, которому Q1 ещё только предстоит получить после начала производства.
То есть если вы имеете в виду, что поставщик ещё до запуска должен начать работу по требованиям Q1 — вопросов нет.
Если же речь именно о получении Q1 до выбора или начала поставок — тогда это уже другое утверждение и его тоже хотелось бы подтвердить.
И наконец, документы самого Ford того периода несколько усложняют тезис о том, что коммерческий контур якобы «растворяется» в APQP.
В Ford APQP Guideline 2003 первым элементом действительно стоит Sourcing Decision — здесь я вашу поправку принимаю.
Но ответственным за этот элемент указан Purchasing, а Supplier Technical Assistance участвует в поддержке решения.
А в Ford Production Purchasing Global Terms and Conditions 2004 совершенно нормально существуют Request for Quote, Sourcing Agreement, Target Agreement, quotation, price и Production Purchase Order.
То есть я вижу не «APQP вместо коммерческого выбора», а совместную работу нескольких контуров: sourcing, purchasing, APQP, quality, engineering и коммерческих договорённостей.
И это как раз возвращает меня к исходной теме моей статьи. Она была не о CRM как программе и не о маркетинге. Она о том, почему один поставщик выигрывает сложную проектную продажу, а другой проигрывает, когда в решении участвуют разные люди, интересы, требования, риски и конкуренты.
Поэтому и вопрос по вашему примеру для меня остаётся очень простым:
почему Johnson Controls выиграла у Lear?
Если ответ: «потому что лучше прошла APQP», давайте переведём это на обычный управленческий язык.
Что конкретно она сделала лучше?
Какой критерий оказался решающим?
Что предложила лучше конкурента?
Какие риски сняла?
Почему Ford доверил проект именно ей?
Вот здесь мы, скорее всего, снова придём к той самой работе по завоеванию проекта, которую я называю проектной продажей / Capture.
Поэтому предлагаю сделать совсем просто.
Если у вас сохранился источник именно на тендер Johnson Controls против Lear по Focus и на цифру 20 000 автомобилей в месяц — дайте, пожалуйста. Я спокойно посмотрю и, если мои выводы неверны, поправлюсь.
Если источника уже нет — тоже нормально, история старая. Тогда предлагаю на этом дискуссию завершить и не закапываться дальше в доказательство тезиса через кейс, детали которого мы сегодня объективно не можем подтвердить.
Мне как раз кажется, это хороший пример того, как я привык работать и в продажах: когда информации не хватает, отделять то, что мы знаем, от того, что предполагаем.
В любом случае спасибо за содержательный спор. В части раннего включения APQP вы моё понимание этой системы действительно расширили.
Спасибо за дискуссию: неудобные вопросы и разные точки зрения очень хорошо развивают!
Выделю два аспекта для ответа на Ваш комментарий:
Первый: какая-то непонятная (зачем и для чего!?) для меня попытка девальвировать мои наблюдения!?
Данные по этому кейсу я получил при посещении завода Johnson Controls, который был построен и работал в 60 км от проходной завода FORDа во Всеволожске в 2010 году. Что мне во время визита показали/рассказали - то и воспроизвожу, мотивов искажать у меня нет, как и не было мотивов как то перепроверять/не доверять тому, что мне рассказывали.
Допускаю, что цифры были изменены (коммерческая тайна, может указывались пиковые значения, может озвучивался пример взаимодействия, а не конкретные цифры, еще что-то - не знаю).
После Ваших оценок попросил Алису узнать проектную мощность завода - получил ответ 125 000 авто в год, но на эти объемы производства завод так и не вышел.
Второй: назначение и область применения APQP в нашей дискуссии
Я вступил в дискуссию по теме "заключение В2В сделки" с простой двоичной логикой БЫЛО СТАЛО, т.к. не увидел (не рассмотрел) в публикации маркеров для СТАЛО.
Маркеры для БЫЛО: Для меня это набор инструментов для развития и управления проектом в условиях определенности (аналогия работа по твердому ТЗ), это функциональный подход (в т.ч. так Вас интересующий аспект КТО и когда принимает решение по сделке, CRM - как удобная записная книжка, закупочные транзакции как инструмент оперативного управления проектом, ...)
Маркеры для СТАЛО - Для меня это набор инструментов для развития и управления проектом в условиях неопределенности (отсутствует твердое ТЗ - AGILE подход), это процессный подход, в котором выраженного старта в виде КП и ЛПРа нет, т.к. это непрерывный процесс подбора и трансформации партнера под непрерывно же меняющийся проект. Поэтому и критерии принятия решения и сам процесс заключения сделки сложней, он рекурсивный, в нем участвуют большие межфункциональные команды. Чтобы правильно управлять таким процессом нужна "мудрено устроенная", а не "простая" записная книжка. В качестве формата и устройства такой "мудрено устроенной" записной книжки для такого сложного процесса выхода на сделку я и привел APQP формат (т.к. он не просто описан, а стандартизирован до уровня международного отраслевого стандарта) описывающий В2В формат проработки сделки в автомобильной отрасли.
Моя цель участия в дискуссии - показать существенную трансформацию целей и смыслов процесса СТАЛО заключения сделки в В2В. Мне кажется он схематично понятен (разницу увидеть можно). Разбираться же в деталях лучше в учебном формате, а не в комментариях к публикации. Пытаться языком инструментария БЫЛО (КП и КТО принимает решение), описать процесс СТАЛО, ИМХО, неблагодарное занятия (любые аналогии и совпадения будут "условными"), т.к. это принципиально разные процессы.
Ваш пример из РОСАТОМа - отличный отраслевой пример, который показывает необходимость сложного управления проектом в условиях неопределенности/изменчивости. Это был Ваш творческий успешный микс каких то решений из БЫЛО и СТАЛО. Насколько этот опыт осмыслен, стандартизирован, может быть перенесен в другие области применения, служить в качестве примера и т.п. - это вопрос исследований и может вызвать сомнения. А APQP-процесс, который я взял в качестве примера такого сложного управления, отлично с ролью "мальчика для битья" справится (мне легко отправить по ссылке интересующихся к первоисточнику, есть огромная масса кейсов применения, миграции этого стандарта в другие отрасли, это не "моя" история и опыт, ...).
На большее я в этой дискуссии не претендую!
PS: У меня нет договора с IATF и я не могу монетизировать продвижение APQP - поэтому мое участие в дискуссии исключительно для получения и систематизации знаний, развития собственных компетенций и нахождения интересных собеседников!)))
Владимир, здесь как раз появилась интересная подмена.
Я не пытался девальвировать ваши наблюдения и тем более не приписывал вам мотив что-либо искажать.
Вы сами привели конкретный кейс Ford / Johnson Controls как аргумент в пользу своей модели и дали вполне конкретные параметры. Я сделал ровно то, о чём пишу в собственной статье: отделил то, что мы знаем, от того, что предполагаем, и проверил источник.
Теперь вы сами допускаете, что цифры могли быть пиковыми, условными, иллюстративными или сообщёнными вам иначе. Никакой проблемы. Но тогда давайте просто зафиксируем: это ценное наблюдение с посещения предприятия, а не подтверждённые параметры кейса, на которых стоит строить доказательство более общего тезиса.
Гораздо интереснее другое.
Вы пишете, что вступили в дискуссию, потому что не увидели в моей статье маркеров вашего «СТАЛО», и поэтому отнесли её к модели «продавец — закупщик — CRM — твёрдое ТЗ».
Но именно такой модели в статье у меня нет.
Статья как раз о ситуации, где участников решения много, позиции различаются, информация неполна, требования и проект меняются, гипотезы приходится проверять, а CRM-статус сам по себе практически ничего не говорит о реальном положении сделки.
Поэтому получается немного странно: сначала моей статье приписывается довольно примитивная модель «БЫЛО», а затем APQP противопоставляется уже этой модели.
С Росатомом то же самое. Я не предлагал свой производственный кейс как отраслевой стандарт, который надо тиражировать по миру. Он был приведён в ответ на более узкий тезис: будто межфункциональная работа, поток, работа с поставщиками и управление в изменяющейся среде сами по себе являются признаком APQP. Нет — подобные управленческие задачи решаются и в других проектных системах под другими названиями.
И здесь мы снова приходим к исходной точке нашего расхождения.
APQP может начинаться очень рано, пересекаться с sourcing, включать межфункциональную работу и сопровождать большой участок жизненного цикла продукта. С этим я уже не спорю.
Но из этого всё ещё не следует, что управление конкурентной возможностью — кто выиграет, почему именно он, какие критерии сформируются, как работает конкурент, кто влияет на решение и какую позицию должен занять поставщик — перестаёт быть отдельной управленческой задачей и становится просто APQP.
Кстати, в актуальных материалах AIAG APQP по-прежнему находится среди Quality Core Tools и описывается прежде всего как Advanced Product Quality Planning. То, что инструмент стандартизирован и широко применяется, ещё не делает его универсальным названием всей работы по сложной B2B-сделке.
Владимир, поэтому я не вижу смысла дальше спорить с конструкцией «БЫЛО — СТАЛО», которую вы сами наложили на мою статью.
Если хотите продолжить дискуссию — давайте по конкретике.
Какую именно управленческую задачу из описанных мной в статье APQP заменяет?
Карта влияния? Работа с критериями выбора? Конкурентная стратегия? Экономика решения? Работа с внутренним защитником? Формирование следующего шага сделки?
Назовите конкретную задачу и покажите механизм — обсудим.
А просто расширять APQP до тех пор, пока в него не войдёт практически вся работа вокруг сложного проекта, для меня уже не аргумент.
Владимир, здесь как раз появилась интересная подмена.
Я не пытался девальвировать ваши наблюдения и тем более не приписывал вам мотив что-либо искажать.
Вы сами привели конкретный кейс Ford / Johnson Controls как аргумент в пользу своей модели и дали вполне конкретные параметры. Я сделал ровно то, о чём пишу в собственной статье: отделил то, что мы знаем, от того, что предполагаем, и проверил источник.
Теперь вы сами допускаете, что цифры могли быть пиковыми, условными, иллюстративными или сообщёнными вам иначе. Никакой проблемы. Но тогда давайте просто зафиксируем: это ценное наблюдение с посещения предприятия, а не подтверждённые параметры кейса, на которых стоит строить доказательство более общего тезиса.
Гораздо интереснее другое.
Вы пишете, что вступили в дискуссию, потому что не увидели в моей статье маркеров вашего «СТАЛО», и поэтому отнесли её к модели «продавец — закупщик — CRM — твёрдое ТЗ».
Но именно такой модели в статье у меня нет.
Статья как раз о ситуации, где участников решения много, позиции различаются, информация неполна, требования и проект меняются, гипотезы приходится проверять, а CRM-статус сам по себе практически ничего не говорит о реальном положении сделки.
Поэтому получается немного странно: сначала моей статье приписывается довольно примитивная модель «БЫЛО», а затем APQP противопоставляется уже этой модели.
С Росатомом то же самое. Я не предлагал свой производственный кейс как отраслевой стандарт, который надо тиражировать по миру. Он был приведён в ответ на более узкий тезис: будто межфункциональная работа, поток, работа с поставщиками и управление в изменяющейся среде сами по себе являются признаком APQP. Нет — подобные управленческие задачи решаются и в других проектных системах под другими названиями.
И здесь мы снова приходим к исходной точке нашего расхождения.
APQP может начинаться очень рано, пересекаться с sourcing, включать межфункциональную работу и сопровождать большой участок жизненного цикла продукта. С этим я уже не спорю.
Но из этого всё ещё не следует, что управление конкурентной возможностью — кто выиграет, почему именно он, какие критерии сформируются, как работает конкурент, кто влияет на решение и какую позицию должен занять поставщик — перестаёт быть отдельной управленческой задачей и становится просто APQP.
Кстати, в актуальных материалах AIAG APQP по-прежнему находится среди Quality Core Tools и описывается прежде всего как Advanced Product Quality Planning. То, что инструмент стандартизирован и широко применяется, ещё не делает его универсальным названием всей работы по сложной B2B-сделке.
Владимир, поэтому я не вижу смысла дальше спорить с конструкцией «БЫЛО — СТАЛО», которую вы сами наложили на мою статью.
Если хотите продолжить дискуссию — давайте по конкретике.
Какую именно управленческую задачу из описанных мной в статье APQP заменяет?
Карта влияния? Работа с критериями выбора? Конкурентная стратегия? Экономика решения? Работа с внутренним защитником? Формирование следующего шага сделки?
Назовите конкретную задачу и покажите механизм — обсудим.
А просто расширять APQP до тех пор, пока в него не войдёт практически вся работа вокруг сложного проекта, для меня уже не аргумент.
Мне нечего добавить к своим тезисам:
Среда B2B взаимодействия существенно изменилась (стала высокоизменчивой, малопредсказуемой), это радикально же изменило и смыслы/формат/инструменты заключения сделки. Это создает почву для классификации смыслов/форматов/инструментов в категориях БЫЛО и СТАЛО (т.е. это не эволюция и/или модификация старых смыслов/форматов/инструментов, а переход на принципиально другие).
Результаты APQP (взят как отраслевой пример такого нового смысла/формата/инструментов) перспективного планирования требуемого B2B взаимодействия стали необходимой частью выхода на сделку (в автомобильной отрасли), т.е. нельзя ее (сделку) заключить не получив одобрения по результатам работы APQP команды.
Мои примеры - это пояснения к вышеизложенной логике (не бухотчетность или строгое доказательство, а именно демонстрация логики выхода на сделку и нового формата B2B взаимодействия).
Я не претендую на то, что бы Вы эти мои тезисы и логику разделяли.
Спасибо за дискуссию!