Welcome! My name is John Morris and this website is all about a business revolution enabled by technology, including especially technology around "BPO", "BPM", "data services" and "presentation".
Using journalism as my model, I want to share what I learn about the potential, the successes, the reality and the dysfunctions of this new technology-enabled business world. And luckily, my role as a front-line sales person and evangelist for business technology-based projects gives me a great perspective "at the rock face". In addition to that bottom-up perspective, I'm also able to attend both industry and academic conferences, which along with wide reading and conversation provides the theory that helps make sense of daily practice.Business Model
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 |
|||
What is it helpful to think of big data as "like a jelly fish"?
|
|||
No business person really cares about technology except insofar as that technology helps get the job done. But there's one technology that's different.
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?
|
|||
On his
Note that that your host is not making any assumption that corporate size is necessarily a bad thing. Although it's a separate topic, and acknowledging that there are clearly many downsides to large organizations, there are all also examples, supported by research, showing that large organzations can also have many positive attributes, and that by
|
|||
Geoffrey Moore of "
And thereby submit that enterprise to the will of executive leadership? John Zachman, well-known evangelist for enterprise architecture and originator of the Zachman “Framework for Enterprise Architecture”, says “yes”. Canada’s DAMA affiliate IRMAC scored a coup last week by hosting Mr. Zachman on his road show for an update of the famous Zachman Framework. Mr. Zachman gave a comprehensive tour of the Framework, the reasoning behind it and the advantages that adopting organizations might enjoy. Mr. Zachman’s key message was that the application of normalization and ontological modeling to low-order, high-entropy organizations – i.e. organizations which are failing due to high cost structures and sclerotic inflexibility -- would reverse that state. The sciences of organizational normalization and ontological modeling, defined by the Zachman Framework, unlock enormous benefits for organizational stakeholders. |
|||
Below is a draft BPM sales pitch which is also an inventory of BPM concepts. It's all about business motivation, and revealing the power of BPM. Is this how you see BPM? If not, why not? BPM Provides The Tools For The Job, Now Business process management is about the technology of the work you do. 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 your vision. All other technology is really mostly about technology and bits and bytes and machines talking to machines.
|
|||
BPM prospects often ask a question about "simulation". Our standard answer is "simulation is best done by a best-of-breed 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"! |
|||
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".
