We at Business Console decided not to offer PoCs any more.
Let me explain why first and then what’s instead.
What is PoC
PoC is a project where a supplier (BPMS vendor, partner or consulting company) demonstrates its capabilities using customer’s business process as an example.
The fundamental reason is that BPM concept is new for most customers. Although there are three BPM conference per year in Moscow since 2005, the number of companies that have implemented BPM is still low. BPM is attractive yet risky for prospective customers.
The PoC’s purpose is to minimize the customer’s risk by providing a working prototype (implemented in BPMS) of a BPM system in a short timeframe and for a fixed price or free of charge. The prototype may be evaluated from different perspectives: business analyst, developer, process participant. Besides the customer gets an idea of provider’s competence and capabilities.
In theory, this allows the PoC customer to decide whether to go on with the proposed solution or not. If yes then licenses purchase and production system development follows.
Seems logical, right? Yet there are some pitfalls:
1) Free pilot projects is bad practice: what’s get for no cost is valued exactly that. Unfortunately there were several cases in our practice where fair projects ended up in the trash can. The customer just didn’t make up a decision, neither positive nor negative.
Large vendors have a reason for doing PoCs: the price of their products is such that even if one of several PoCs will bring the order then it’s worth the cost. But for those who, like us, offer consulting mostly and a resonably-priced BPMS as an addition, this is unacceptable.
2) Hence we started to charge for PoCs. Charge a fixed price because (let me remind you) the fundamental goal was to reduce the risk for the customer. The plot was to make the customer more commited and more interested in project’s progress and result.
Unfortunately it did not work well either. Whatever we did to explain a customer that the purpose of the PoC was not to develop a producton system but to provide him all necessary information for the decision - he never fully understood. He formally agreed but used to request more and more features which a) where absolutely non-essential and b) he didn’t mention at the beginning of the project. Inertia of considering BPM as an automation project turned out to be too strong.
We encountered a trivial greed, too: if the price is fixed then let’s get the maximum number of features. Nobody seems to care that the decision is postponed and the system which could already benefit to the customer was not implemented. We failed to explain the simple fact: time is more important at PoC than functionality!
Besides we as suppliers have had another driver for PoCs - the hands-on experience of solving real business problems with BPM. But now it’s over: after years of field work we are fully confident; basically we don’t care what the next business process would be. We know beforehand that we’ll meet the same process patterns, the same integration tasks and the same organizational and cultural challenges of process management implementation.
A customer learns a lot from a PoC but we learn almost nothing. Hence a logical change in our tactics:
Training Instead of PoC
We lanched bpmntraining.ru in September 2010. At that time nobody could say whether anyone would ever sign up for the BPMN training. Now it’s evident that it was a good idea: the BPMN adoption is growing and so do the demand for the training.
We started with public trainings and now we give two corporate trainings per month in addition. More and more companies adopt BPMN as an internal business process modeling standard. The geography is expanding too; the recent addition was Tbilisi, Georgia.
We picked the right format for the training:
1) At the first day students learn the elements of the notation, do excersices and write tests. At the end of the first day students choose processes from their own business practice to work on.
2) These processes become the homework. Students publish intermediate results at bpmnforum.ru and discuss them with each other and with the trainer.
3) On the second day in the classroom we continue working on the selected processes. This is a key element of the training; the brainstorming sessions alternate with drawing BPMN diagrams in BizAgi Modeler. At the end of the day students become confident in BPMN modeling and process analysis, they get familiar with basic BPMN orchestration and collaboration patterns and are well-prepared to meet the BPMN challenges at their workplaces.
4) On the third day of training students get a complete understanding of what an executable business process is, how a modern BPM Suite works and how it can benefit to them. Right in the classroom they create from scratch a business process diagram plus other artifacts necessary to execute and analyze a business process within BizAgi BPM Suite.
So what the students of BPMN training finally get? It’s a complete understanding of how BPMN and BPMS can be applied to process-related challenges facing their organization, what benefits the organization will get from BPM and what are the associated costs.
Now tell me please: isn’t it the same result that a PoC should give?!
In fact it’s even more: the organization gets an idea of how to use BPM in both cases yet in case of PoC the resulting prototype is created by the supplier while in case of training the customer’s employees did it with their own hands. The latter result is much more valuable indeed.
Training is also far better from the relationships between customer and supplier viewpoint. No more conflicts because a supplier rejects yet another feature request or because a customer postpones a decision. The training agreed - conducted - paid off, that’s it!
After that the customer can leverage on the wave of enthusiasm from the training to initiate a project that will result in a production system managing customer’s business processes. Or if he isn’t ready yet for some reason then he can take a time-out; he knows where where to go and he knows our capabilities.
Это просто супер!
Жаль что 3-а года назад, когда я начинал внедрять системы ITSM\ITIL мне такие мысли в голову не приходили.
Однако на старте без кошек совсем никак -)
> на старте без кошек совсем никак -)
Конечно! Поэтому жалеть абсолютно не о чем. Без этого откуда возьмется уверенность в себе и, в конце концов, те же тренинги. Пересказ учебника без примеров из реальной практики нафиг никому не интересен.
I think your new approach is absolutely the way to go. Until you’ve built a BPM project, you don’t truly understand that BPM is and what it is not.
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).
Thanks for the support John.
Anatoly, I don’t agree. PoCs are about relationships and not about delivering proof. The problem is that typical BPM tends to be to complicated to deliver anything in a PoC.
Max
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.
Андрей,
Добрый день!
Позволю себе несколько не согласиться с Вами.
Небольшой личный опытт подсказывает, что ни 3х, ни 5ти дневные курсы не помогут определиться с самым главным - подходит ли выбираемая система для конкретного предприятия. Точнее помогут, если в предприятии работает несколько человек и нет никакой интеграции.
Если же на предприятии где планируется внедрить bpm-систему:
- работает несколько сотен или тысяч пользователей (и они являются участниками автоматизируемых бизнес-процессов)
- гетерогенная информационная система состоит и N-нного количества разнородных систем
то никакие курсы не помогут.
С уважением,
Григорий.
Григорий
А что поможет в этом случае?
Добрый день Анатолий,
Вот такие у меня соображения:
>”Применительно к BPM, это проект, в ходе которого поставщик
>(производитель программного обеспечения, партнер, консалтинговая компания)
> демонстрирует свое решение на примере бизнес-процесса заказчика.”
1. Так кто?
У производителя под “своим решением” понимается -одно,
у партнёра - другое, у консалтинга - третье.
И демонстрировать “своё решение” они должны по-разному!
Если это производитель, то стандартизация скорее всего высока, и это ближе
к “коробочному” подходу.
Если это консалтинг, и требуется именно он, то стандартизация тоже высока,
но, как правило, ещё требуется решение уникальных задач.
>цель пилота – не разработать для него некую автоматизированную систему,
> а предоставить информацию для принятия решения о том, подходят ему или
> нет предлагаемые управленческие подходы и программное обеспечение
2. Вот именно, то есть насколько Вы готовы решать нестандартные задачи
заказчика, таким способом, что у него после такого решения ощутимо
улучшился бизнес. (Если Вы позиционируете себя, как Консультант).
Если Вы поставщик ПО, то немного другое дело.
Да, тогда скорее обучение, демонстрирующее больше продукт, чем консалтинг.
>Но сейчас этот стимул исчерпал себя: после нескольких лет работы мы уверены в себе
> настолько, что нам все равно за какой бизнес-процесс браться. Мы заранее знаем,
> что увидим там те же самые, вдоль и поперек изученные процессные паттерны,
> ту же интеграцию с учетной системой и те же организационно-культурные проблемы
> внедрения процессного управления.
3. Здесь Вы, очевидно, позиционируете себя скорее, как поставщик, и в меньшей степени
консультант, который постоянно совершенствуется, обучается и развивается.
(А BPM - это не постоянное совершенствование? Для консультанта Ваши слова очень
рискованны.)
Во-первых, проблемы похожие, это не значит, что “те же самые”.
Во-вторых, решения могут быть совершенно разные даже при тех же проблемах
(просто из-за разного размера компаний или разных стилей руководства или …)
Во-третьих, от Вас могут ожидать отличных решений, показывающих не результаты
двухлетней давности, а что-то новое, уникальное, что даст рывок в бизнесе
сегодня.
>Большие вендоры на такие пилоты идут, но у них свои расчеты: их продукты стоят столько,
> что даже если один из нескольких пилотов даст заказ, то это окупит затраты. Но для тех,
> кто, как мы, предлагает в основном консалтинг, а к нему программное обеспечение BPMS по
> разумной цене, это неприемлемо.
4. Из этих рассуждений не вытекает, что пилот не нужен. Да, допустим Вы не хотите брать на
себя риски и/или у Вас недостаточно ресурсов. Тем самым Вы признаёте, что риски есть и
издержки могут быть большими. Но это не означает, что не нужна данная стадия проекта
(пилотная или НИИОКР), а скорее ровно наоборот. (Кто за это заплатит, сколько и когда -
это уже следующие вопросы)
Мои Выводы:
1. Да, пилотный проект может включать обучение продукту и методике, но если он
на этом заканчивается, то Вы можете не показать (не раскрыть) себя должным образом.
2. Заказчик может не увидеть реальных результатов. Особенно если это
достаточно крупная компания, где разрыв между примером (кейсом) на
обучении и реальностью, не просто большой, но НЕочевидна сходимость.
То есть, риски и всякие “но”, приводят к неочевидности результата.
Всего Наилучшего,
Maxim
Максим
Спасибо что поделились своими соображениями, но боюсь, Вы не уловили главный тезис. Я не против пилотных проектов, я против POC, которые часто тоже называют “пилотами”.
Пилот, который дает реальные результаты, за которые Вы ратуете, мы для точности называем “продуктивным пилотом”. Такие проекты мы делали, делаем и будем делать. Но не по фиксированной цене.
По поводу обучения: мы учим не на “примерах”, а на реальных процессах заказчика - см. http://bpmnforum.ru