The themes developed on this site have a new home at https://datadecisioning.com, with the Data Decisioning LLC team. Data Decisioning is focused on the "data-to-decisioning-value-chain", and covers everything from Big Data all the way to decision technologies and business decision making in the executive suite. Decisions are the purpose of management! And every technology from artificial intelligence to IoT to business analytics and more is all in support of the work of management, which is decision-making. Join the Data Decisioning team for a great dialogue. There's humor, Quotes of the Week, amazing podcast interviews, analyses and the popular "virtual conference listing". See you there! 

Bell Telephone Switchboard Operators, 1943, USA (Courtesy, Wikipedia and US National Archives)

Do you want to enter the business of selling telephone switches?

Probably not. The telephone switch business is super competitive and very low margin.

But the telephone switch business is a pretty good analogy to what your Internet of Things business could be, if you get it wrong.

And you can get your new Internet of Things business model wrong if you think that all you need to do is connect M2M ("machine-to-machine") edge devices to decision makers -- without providing any business value add in the middle.

Without applying your domain knowledge, captured through business analysis, you're at the mercy of a rapidly commoditizing business of selling sensors, wires, wireless and connectivity. And this warning applies to both vendors and business users. The real value of Internet of Things programs is achieved when hard-won domain knowledge enables the addition of value between edge device and centre. Without that "value-add-in-the-middle", again, you've just built a telephone switch. . . . read more

If you are an executive charged with a "big data project", here's a prediction. On your first week on the job you'll likely be surprised. And the surprise concerns what you'll actually spend your time doing.

What might be the surprise on your first week on the job? The surprise is that your biggest responsibility won't concern what you thought you signed up for, which is likely something like "generating analytical insights". Rather, your biggest responsibility is almost the opposite, which is focusing on everything but generating analytical insights.

And if you've been dreaming of fishing in sea of data, with a big net to scoop up any of the myriad insights just swimming by your boat, your surprise might even be one of disappointment. Because this blue ocean metaphor, lovely to imagine, is also seriously misleading about the nature of the world of big data. It's more likely that your ocean will consist of nothing but fish, all of which have three eyes and which are inedible! You'll have lots of data but nothing to take home that you can call a great insight.

Here's the problem, which could define the basis of your surprise, your job responsibility and the sort of metaphor that you should use to describe the world of big data. The problem with big data concerns the very definition of big data, which is that it is "big" -- but although big is subjective, there's a very practical and non-trivial definition of "big". Your set of big data is defined as such if it is too big for any of your machines to process in one chunk in a reasonable amount of time. In other words, the world of big data is defined by the system capacity constraints. . . . read more

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 popular ebizQ blog, Peter Schooff, asks (December, 2012) "How central of a role should BPM play in customer experience?"  Readers interested in this question should visit the original discussion as there are some terrific contributions and insights; the question concerning the centrality of the role that BPM should play in customer experience is a good one.  (In the context, "BPM" means "business process management software and practices".)

A short answer is this: "In a competitive world, and for both technical and economic reasons, BPM is likely to play an increasingly important role in customer experience".

This blog entry explores this proposition in more detail.  But first let's qualify our short answer above by defining the terms "customer experience" and "BPM". (For the purposes of this discussion, we'll focus on BPM as "technology" or "software" and on customer experience as "customer experience system"). . . . read more

According to the analysts at Aberdeen Group, on average 26% of world workforce headcount is considered "contingent", including contract and temporary staff.  Clearly contingent labour-force outlays account for a huge portion of total spend.  But Aberdeen asks if this spend is well-managed. 

There are in fact very significant differences between best-in-class and laggard organizations concerning how contingent work is managed.  Best-in-class managers get much better results (over 50% higher reporting program objectives achieved), better contingent workforce cost control and most important, significantly better overall organizational efficiency.  This last benefit gets to the heart of the whole contingent workforce business case. 

Why bother with all the effort and management time to organize contingent workforce scaling if your organization does enjoy overall improved efficiency as a result?

In a world of intense competition, contingent workforce scaling makes intuitive sense, and it's not surprising the Aberdeen Group has identified characteristics of the organizations that "do contingent" better.  But why highlight these insights in this Decision Models forum on business process management technology?

. . . read more

BPM software advocates need look no further than the regular reports from the analysts at Aberdeen Group for terrific examples of BPM in action.  The latest example, by Analyst William Jan, is AP Invoice Management in a Networked Economy (you can acquire this report without charge for a limited time via the embedded URL; registration is required).

The world of business process is about the processes at the core of any business.  And for this reason unless you are an insider in any given function or vertical market, it's difficult to acquire in-depth knowledge about business processes in real life.  Organizations tend to be reticent about revealing the secrets about how they do business; and as well, in any given function the processes reflect the complexity of corporate life and one is not likely to master that complexity over night. 

So, for these reasons, the work by Aberdeen Group is very welcome.  Their analysis work focuses especially on identifying best practices in various corporate functions, such as sales, accounts payables, inventory management, and so on.  And although Aberdeen Group includes technology in its analyses, their work is refreshingly "business first".

The case of Accounts Payable is a nice example of an end-to-end process analysis of an important corporate function.  Using A/P practices as a measure, and compared to "laggards", best-in-class organizations manage their A/P to deliver much better cash flow, which can have a huge impact on bottom lines. 

. . . read more

Some of my best friends are BPM-istas!  And evangelists-of-BPM as the second coming of application development.  I say bravo!  But then I have a few questions, such as . . .

1.       How many managers does it take to build a business process in BPM?  

“None.  Managers aren’t allowed to build a process in BPM.” . . . read more