What is it helpful to think of big data as "like a jelly fish"?

Both big data and jelly fish can be very beautiful. But if not treated with respect, you might get stung. And how you get stung, at least where data is concerned, relates to the other similarity between jellyfish and big data, which is a lack of bones, or structure.

To be in any way useful, big data needs to be used alongside an interpretive structure or model – the “bones” if you will, without which big data is as amorphous and useless as a jellyfish. The necessity of having this model is a critical challenge for any organization seeking to derive benefit from big data.

Let's prove the point about the necessity of interpretive structure with the simplest possible model.

Consider the results of a query on a joined accounts receivable table. You may have columns representing company names, owed amounts and due dates. And the meaning of the table is completely clear, but only because you know the column headers and table name, which comprise a simple "model" providing the meta-data meaning of the table. Without this "interpretive model" the table could just as easily imply accounts payables as account receivables! . . . read more

Lost business. The phrase strikes a chill into any CEO or line-of-business ("LOB") executive.

Lost business is also a special data management challenge.

So, let's see how a story about the "business of lost business" plays out between LOB execs and IT.  There is a data management angle on this story, and eventually we might even find some leverage for master data management (MDM) and analytics, but first we need to understand the all-important business drivers behind the scenes.

In our example, based on real events, imagine a technology services business employing close to a 1,000 people, and with accelerating product life-cycles. In only a half decade, the field refresh period for installed systems has fallen from seven years to five. This change means system sales reps must be on their toes for the upgrade sale, and ensuring the upgrade is even harder when smaller systems are sold through channels where warranty registration isn't complete.

What kinds of lost business events are there? First you have to understand that "lost business" as defined by Field Service means a "lost service contract" -- not a "lost system sale", although of course the two are closely linked. And in the distinction between services sales and systems sales we see the collision between three huge organizations: engineering, systems sales and services sales, each with different metrics and P&Ls! And to make matters more interesting, the engineering bill-of-materials ("BOM") has never been shared with customer services! . . . read more

On his ebizQ blog, Peter Schooff, asks (September 2012) "what is the number one reason a BPM project fails?"

Asking this question is audacious. But important.

Here's the short answer: BPM projects fail at a rate higher than tolerable (thus the question) because BPM projects, being fundamentally different than all other IT projects, are not yet sufficiently supported culturally, organizationally and economically.  

In particular, a BPM projects puts pressure on business executives for detailed process leadership, a time-based pressure without precedent and for which many or even most executives are not ready.

The first response to ebizQ's question, from Emiel Kelly, alludes to these issues with the statement that BPM is seen as "a project, not as daily business". Subsequent comments by other contributors elaborate in worthwhile ways. But it's worth making Kelly's "not as daily business" explanation more explicit.

Specifically, from the original answer above, what does it mean that BPM projects are "fundamentally different", and why is this difference important? And what is "cultural, organizational and economic" support?

. . . read more

Your host started his IT career at IDC, in the previous millennium.  Working for IDC gives one a perspective on analyst relations with vendors and end-users.  Analysts are little bit like movie reviewers -- they like technology as much as movie reviewers like movies.  And the economics of the technology analysis business is such that it's difficult for analysts not to be cheerleaders for technology, in the same way that movie reviewers find it difficult not to be cheerleaders for movies, or, considering the subject of this website, cheerleading for BPM software. . . . read more

The promise of BPM technology is only realized within the context of traditional management skills and discipline.  Ironically, it is an erroneous common pattern of “magical thinking” that impedes success in both traditional- and new "BPM technology"-enabled management environments.

Intervention Warning Against Overselling BPM Technology

On a discussion hosted by the BP Group on LinkedIn, member Mr. Ajit Kapoor has made an excellent intervention in this discussion.  Our root discussion concerns an “experimental BPM technology sales pitch” which posited that “for the first time in history, we have a technology that is explicitly about taking your vision about how your business operates, and building tools that directly make it possible to run your business, according to that vision."

Specifically Mr. Kapoor has articulated a powerful position that new technologies such as BPM software should not be pitched as "nirvana".  And his riposte comes with powerful credibility based on his achievements and career.

. . . read more

On the LinkedIn BP Group, in response to your host's item Selling BPM Reveals Essence Of BPM, one of the participants contributed an excellent response questioning the emphasis on the idea of technology when selling BPM.  This dialogue is a great opportunity to highlight the importance of seeing BPM as a business technology. . . . read more

BPM prospects often ask a question about "simulation".  Our standard answer is "simulation is best done by a best-of-breed business simulation product, outside of BPM".  This answer is usually delivered after some qualification to discover what the prospect means by "simulation".  Some of the time the prospect is concerned about technical simulations and the regular process of software QA.  But the majority of the time the prospect wants to be able to do business what-if simulations to answer questions such as "how many warehouse staff should we have" or "should we add a new warehouse in the Midwest".

Why is the BPM business simulation question so frequently asked?  The reason is that the question is directly related the two main business cases for BPM.  BPM is justified either on efficiency terms or on business model terms.  The BPM efficiency business case is the same IT efficiency business case that has driven most IT investments for two generations.  Efficiency in the best of situations is about dramatically reducing costs for a given business process; in the worst of situations, it's about "paving the cow path"!

. . . read more

You'd expect the BPM-savvy practitioners and evangelists such as found on LinkedIn's "BP Group" to be able to easily come up with a good definition of BPM   .  A specific and actionable definition.  You'd be wrong.

In a BP Group forum discussion entitled "Can Anyone Make One Sentence Describing BPM", most of the answers were generic and non-actionable and often sounded like mission statements -- the kind of feel-good mission statements that are ridiculed by cynical business writers -- or worse the statements were self-referential ("BPM is about improving your processes").  In fairness. participants shared many worthwhile insights.  It's just that the there was a general and disappointing failure to answer the question in a useful way.

Let's look at what would be a good top-level definition of business process management -- and then why a good definition is important.

On the forum, Kenneth Beard came the closest to a good description of BPM with his "scientific management of work activity to enable informed decision-making", although I would make the case that final phrase in this definition is outside the scope of a definition of BPM.

Your host proposed the that BPM can be simply defined as "the modelling and management of repetitive work", which is certainly not original, but this concise definition emphasizes a fundamental concept, specifically the centrality of the question of work to the definition of BPM.

. . . read more

Takeaway Summary:   According to the theory of Nobel Prize winning economist Ronald Coase, corporations exist to manage the transaction costs involved in organizing work.  And the size of a corporation is determined by the optimal management of those costs.  However, new information technologies have changed that transaction cost landscape for business processes.  It is now more than ever possible to disaggregate the work of the firm, and still maintain corporate identity and control.  And for the intercompany integration technology business, the good news is that integration technologies have a leading role to play in this evolut . . . read more

Dynamic BPM, along with Adaptive Case Management, is the name given to a growing body of practical knowledge about building better software for business process.  The trouble with much of existing BPM is that poorly done, the implementation of BPM can contribute to a reduction in organizational flexibility.  The wags have it as "pouring concrete over your business" -- as if enough concrete wasn't already there from the acquisition of ERP systems.  It's fair to say that no one is to blame for this -- and ER . . . read more