I’m not familiar with the market in Russia but I can tell you my experience here in the US is that it is unusual for a company to not have any CRM or the like systems in place. Sometimes a company will be missing one key system, or moving off of a mainframe to something more unix or windows centric. And sometimes a company is in the process of tossing one of these applications overboard. Also, of course small companies often don’t have the same infrastructure or existing systems. And so you end up spending more time on some traditional stuff (db tables, etc), but, on the other hand, smaller firms usually have more flexibility to arrive at an answer that is good, rather than perfect (similar to necessary but not sufficient… perfect is the enemy of good, or good enough).

I haven’t read the book, but very familiar with the concept ;) I’ll have to look for it!

Thank you for sharing your thoughts.

This is exactly what we do. But even implementation of bare necessary business objects, basic UI forms and minimal set of reports overweights process-related part if measured by development efforts. We know how to do both parts; what insults me is the fact that the excellent performance of process implementation within BPMS sinks in man-months of traditional applications development. It’s hard to find a pure BPM project; we are not spreading a process “butter” on existing applications infrastructure “bread” as we would like to being essentially a BPM company but have to deliver both bread and butter.

Someone may say there is easier way: depending on particular BPMS on hands there are process attributes or more advanced data structures to implement business objects right within BPMS. But it only works at very limited scope. You still need to access business objects after a process have ended hence you need all traditional stuff of database tables, O-R mapping, UI, reports etc.

I only wonder: is it local specialty – maybe Russian companies in average are worse equipped with basic business apps – or people at other sides of the globe have similar issues?

Anatoly

BTW, did you read “Necessary But Not Sufficient”? The revolutionary work, for me at least.

As for the personal nightmare – I can certainly relate! It is a difficult position to be in, as a process developer, to help someone with a tough project like this. And yet, in some cases it may still make sense to the business (the buyer). I think if put in that situation, the first thing I would do is say – ok, but I’m not building your CRM system with a BPM tool. We’re building a “process” that would normally fit in the CRM bucket, and let’s define, it shall we? And so that way you avoid replicating EVERYTHING in a CRM or trying to live up to those expectations, and just solving the CRM-related process problem they are having…

(Might be more than one process though)…

Your point about incremental nature of BPM ROI is excellent, wish I have found the term myself :)

As for the second part, my personal nightmare is a project that started as BPM but after few successfull steps turned out to be a custom development of accounting, planning or CRM functionality with relatively small BPM part atop. It isn’t very professional because we can deliver only part of boxed products functionality this way. But what should we do if most part of say CRM info is stored in paper or Excel spreadsheets? Waiting until a full-scale CRM will be deployed? It may never happen. Besides the customer needs a solution “yesterday”.