Thanks to Clay Richardson of Forrester whose early morning tweet yesterday brought me the news that Progress was buying Savvion. He’s right. Another one does bite the dust!
And how will Savvion survive being surrounded by integration and development tools? Neal Ward Dutton observed in his blog that the deal makes sense ‘in theory’. In practice we need only to look at what happened to Fuego (BEA) and Staffware (TIBCO).
And, I also worry, with Bruce Silver “that the notion of business-empowered implementation, those BPMS vendors’ sole reason for being, if you ask me, will fade away“ as a consequence of being buried “beneath an IT-centric middleware stack”. Frankly, pragmatic buyers will now be, and should be, even more concerned about a vendor’s dedicated focus on BPM, growth in product R&D, and financial stability.
Everything from my last blog about IBM eating Lombardi applies to Savvion’s ingestion by Progress. Both acquiring companies have too many tools (connected primarily by PowerPoint) that require far too much real integration for the whole to come close to the sum of the parts. Clearly, departmental-focused BPM companies stalled during the recent tough times. Is it okay to finally say that departmental BPM is not able to satisfy growing customer needs for real business change?
Frankly, the best evidence comes from the acquiring company itself, which sees only tepid growth from the Savvion buy, forecasting only an additional $20M in revenue and 2 cents of profit… This kind of growth is not what real BPM is about. If BPM is to be truly BPM it needs to grow rapidly and organically – and be seen to be growing. It needs to be a transforming wave that embraces strategic change across a distributed organization.
We see across our customers successive enterprise BPM projects get launched and achieve payback and return within one or two quarters, funding the next BPM projects organically. These initiatives, sometimes small and highly focused and sometimes global, follow an iterative but enterprise-wide approach that leverages components made in earlier projects. Departmental BPM, quite simply, is not engineered for this kind of rapid dissemination across the enterprise. We long suspected that departmental BPMs that could not scale wide and deep quickly enough would run out of steam.
Quite simply, BPM must be engineered and architected from the ground up to support the rapid transition from low-risk, entry projects and proof points to enterprise-wide transformational initiatives. What the C-level seems to like better are fast, but strategic, BPM initiatives laser-focused on corporate success imperatives, that cross multiple functional areas and deliver an immediate and measurable bang for buck that seeds the next wave of strategic improvement. Happy New Year! 2010 looks like it will be even more interesting than 2009. And, now that the choices are even clearer than they were just a couple of months ago, it looks like another great year for Pegasystems SmartBPM!