My grandfather Ivan Orlenko was a military pilot during WW II. He flied on torpedo bombers over the Baltic Sea in 1944-1945 and ended the war at the rank of regiment commander. (On this occasion I recommend to those interested in military history the site of my brother Oleg Belaychuk.)
Grandfather is at the center of the photo. The writing on the plane says it’s an American Boston A-20G, which were supplied to the USSR under Lend-Lease.
Among many stories that grandfather has left here is the one about planes that are best for war and for peace. Retelling in my own words:
When we got Bostons we were surprised with unprecedented level of comfort - they were warm! We could fly without fur shoes and fur coats which we all used to. But when we got involved into actions we’ve found that Bostons are too ready to burn. Technicians investigated why and found that heating was provided by a gasoline stove fed by a pipe running through the entire machine. A bullet or a shell fragment and the machine is down. So we dismounted the whole heating system and got our fur boots with sheepskin coats back.
It should be noted that when the bomber steers the target at the final approach it’s under the fire of all ship weaponry from the main battery to the officer on the bridge with a handgun. And being shot down over the Baltic… Grandfather’s engine has caught fire after attack once but he was able to knock down the flames and get back on one engine. Meanwhile he was “buried” at the base because the fuel calculation didn’t give a chance to stay in the air at the time.
Conclusion: the equipment may be perfect for parades and military exercises during times of peace yet no good for a real affair.
This story came into my mind in connection with the common practice of BPMS buyers called PoC (Proof of Concept). The idea is this: first, the software features and vendor/integrator expertise are demonstrated on a relatively simple process - the most popular are auxiliary processes like vacation request, expenses report and employee onboarding. If the product and consultant are good enough then the buyer signs the bill and approach to more complex core processes that interact with customers.
Now here is the trap: the difference between simple and complex process task is quantitative, not qualitative! It’s not that one would spend more time for complex task than for a simple - completely different process patterns would be used and therefore BPMS features that one was probably totally unaware of during PoC would become essential. The PoC approach is at risk of choosing a BPMS that perfectly showcases itself in a pilot project (”Equipment for peaceful times”), but fails in production (”Equipment for the war”).
And it’s not a speculation: support processes are simple because all they need is ability to command; core processes are complex because they need abilities to command and to respond (more on this in the next post.) BPMS is able to respond if it implements collaboration.
Therefore I pay special attention to collaboration when evaluating a BPMS. And what do I see? Most products don’t implement collaboration at all! (In particular, I didn’t find it in any of popular Open Source products.) My interest to such a product instantly drops to zero because I know that no matter how attractive it looks, it can be used only for auxiliary processes, and for core processes - those that make money! - it will be of little use.
Some may disagree with such a radical approach and argue that the product may have some great features. Sorry but for me a sound approach to the selection problem is to separate primary and secondary criteria and never score gains in possibly several secondaries as a compensation for a loss even in a single primary.