Спасибо что поделились своими соображениями, но боюсь, Вы не уловили главный тезис. Я не против пилотных проектов, я против POC, которые часто тоже называют “пилотами”.

Пилот, который дает реальные результаты, за которые Вы ратуете, мы для точности называем “продуктивным пилотом”. Такие проекты мы делали, делаем и будем делать. Но не по фиксированной цене.

По поводу обучения: мы учим не на “примерах”, а на реальных процессах заказчика - см. http://bpmnforum.ru

>цель пилота – не разработать для него некую автоматизированную систему,
> а предоставить информацию для принятия решения о том, подходят ему или
> нет предлагаемые управленческие подходы и программное обеспечение
2. Вот именно, то есть насколько Вы готовы решать нестандартные задачи
заказчика, таким способом, что у него после такого решения ощутимо
улучшился бизнес. (Если Вы позиционируете себя, как Консультант).
Если Вы поставщик ПО, то немного другое дело.
Да, тогда скорее обучение, демонстрирующее больше продукт, чем консалтинг.

>Но сейчас этот стимул исчерпал себя: после нескольких лет работы мы уверены в себе
> настолько, что нам все равно за какой бизнес-процесс браться. Мы заранее знаем,
> что увидим там те же самые, вдоль и поперек изученные процессные паттерны,
> ту же интеграцию с учетной системой и те же организационно-культурные проблемы
> внедрения процессного управления.
3. Здесь Вы, очевидно, позиционируете себя скорее, как поставщик, и в меньшей степени
консультант, который постоянно совершенствуется, обучается и развивается.
(А BPM - это не постоянное совершенствование? Для консультанта Ваши слова очень
рискованны.)
Во-первых, проблемы похожие, это не значит, что “те же самые”.
Во-вторых, решения могут быть совершенно разные даже при тех же проблемах
(просто из-за разного размера компаний или разных стилей руководства или …)
Во-третьих, от Вас могут ожидать отличных решений, показывающих не результаты
двухлетней давности, а что-то новое, уникальное, что даст рывок в бизнесе
сегодня.

>Большие вендоры на такие пилоты идут, но у них свои расчеты: их продукты стоят столько,
> что даже если один из нескольких пилотов даст заказ, то это окупит затраты. Но для тех,
> кто, как мы, предлагает в основном консалтинг, а к нему программное обеспечение BPMS по
> разумной цене, это неприемлемо.
4. Из этих рассуждений не вытекает, что пилот не нужен. Да, допустим Вы не хотите брать на
себя риски и/или у Вас недостаточно ресурсов. Тем самым Вы признаёте, что риски есть и
издержки могут быть большими. Но это не означает, что не нужна данная стадия проекта
(пилотная или НИИОКР), а скорее ровно наоборот. (Кто за это заплатит, сколько и когда -
это уже следующие вопросы)

Мои Выводы:
1. Да, пилотный проект может включать обучение продукту и методике, но если он
на этом заканчивается, то Вы можете не показать (не раскрыть) себя должным образом.
2. Заказчик может не увидеть реальных результатов. Особенно если это
достаточно крупная компания, где разрыв между примером (кейсом) на
обучении и реальностью, не просто большой, но НЕочевидна сходимость.
То есть, риски и всякие “но”, приводят к неочевидности результата.

Всего Наилучшего,
Maxim

А что поможет в этом случае?

С уважением,
Григорий.

Thank you for sharing your thoughts.

The point is that whatever PoC is about - a proof or relationships - trainings (or workshops in Adam’s case) deliver it better.

PoC projects generally focus on “gee wiz” features to impress and close the deal, rather than on giving the client a true appreciation for what it is going to take to really implement their projects, both in terms of the technical challenges and in terms of the organizational and people challenges (which are often more daunting than the technical challenges).

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

Однако на старте без кошек совсем никак -)