Showing posts with label BI. Show all posts
Showing posts with label BI. Show all posts
Wednesday, February 26, 2014
Monday, February 25, 2013
Who owns data management strategy?
@joel_schectman exposes an apparent divergence of opinion among #Gartner analysts - whether CEO or CIO should be in charge of data management strategy.
@ted_friedman says that taking out IT as the gatekeeper of centrally stored data can promote “better fact based decision making across the organization”.
@merv adrian says that bypassing the CIO can have unintended side effects like risks to privacy and the quality of the analysis.
Merv explains further “If you don’t have to go through a procurement process and IT, you’re a lot freer to do what you want,” said Mr. Adrian. “But all of that carefully constructed governance is completely undermined, you can be drawing incorrect conclusions, and exposing risks to privacy because they are doing things IT hasn’t vetted.”
Merv's concern about quality also applies to the widespread and often uncontrolled use of spreadsheets and other end-user tools. For example, we can find @JamesYKwak and @alexhern discussing whether we can blame Microsoft Excel for $9bn losses at JPMorgan?
What exactly do we mean by data management strategy? Joel says it includes how to best utilize customer information to leverage growth. Most CIOs seem to think their responsibility for data finishes when they deliver data and information to the user's device. They seem uninterested in how these users actually use the data, and whether better or faster data genuinely improve decisions and policies, and produce better business outcomes.
In other words, the CIO doesn't operate as a Chief Information Officer but as a Chief Information Systems and Technology Officer.
True information strategy includes a closed feedback and learning loop, so that the use of the information can be monitored. Are these expensively collected and elaborately processed data analytics actually influencing decisions, or are the users mostly ignoring them?
Alex Hern, Is Excel the most dangerous piece of software in the world? (New Statesman Feb 2013)
James Kwak, The Importance of Excel (Baseline Scenario Feb 2013)
Joel Schectman, Democratizing Data Analysis Has Risk (WSJ Feb 2013)
Updated 20 February 2016
@ted_friedman says that taking out IT as the gatekeeper of centrally stored data can promote “better fact based decision making across the organization”.
@merv adrian says that bypassing the CIO can have unintended side effects like risks to privacy and the quality of the analysis.
Merv explains further “If you don’t have to go through a procurement process and IT, you’re a lot freer to do what you want,” said Mr. Adrian. “But all of that carefully constructed governance is completely undermined, you can be drawing incorrect conclusions, and exposing risks to privacy because they are doing things IT hasn’t vetted.”
Merv's concern about quality also applies to the widespread and often uncontrolled use of spreadsheets and other end-user tools. For example, we can find @JamesYKwak and @alexhern discussing whether we can blame Microsoft Excel for $9bn losses at JPMorgan?
What exactly do we mean by data management strategy? Joel says it includes how to best utilize customer information to leverage growth. Most CIOs seem to think their responsibility for data finishes when they deliver data and information to the user's device. They seem uninterested in how these users actually use the data, and whether better or faster data genuinely improve decisions and policies, and produce better business outcomes.
In other words, the CIO doesn't operate as a Chief Information Officer but as a Chief Information Systems and Technology Officer.
True information strategy includes a closed feedback and learning loop, so that the use of the information can be monitored. Are these expensively collected and elaborately processed data analytics actually influencing decisions, or are the users mostly ignoring them?
Alex Hern, Is Excel the most dangerous piece of software in the world? (New Statesman Feb 2013)
James Kwak, The Importance of Excel (Baseline Scenario Feb 2013)
Joel Schectman, Democratizing Data Analysis Has Risk (WSJ Feb 2013)
Updated 20 February 2016
Wednesday, June 30, 2010
The Analytic Organization
There are several possible ways of defining the term
One way is to define a set of capabilities and working practices loosely called
It's often a good idea to have a centre of excellence to promote and coordinate some desired capability, and Peter's centralized approach may make sense for many organizations. However, I'd be reluctant to say that Peter's approach is the only possible approach for building the analytic organization, and I should like to think that some organizations (depending on culture and circumstances) will achieve greater results with a more decentralized approach.
Meanwhile, @joemckendrick talks about an analytic organization in terms of the ability to fully leverage data (Joe McKendrick, 7 Simple Steps to Becoming an Analytic Organization, Insurance Experts' Forum, June 18, 2010). He quotes Christina Colby of CapGemini as identifying three ingredients for using analytics to its full potential as a competitive asset:
Lex Donaldson goes one step further than everyone else. His book is called The Meta-Analytic Organization, and is based on something he calls Statistico-Organizational Theory, which appears to be a combination of statistics and psychometrics.
Meanwhile, other writers such as Bob Marshall (@flowchainsensei) focus attention on what a so-called analytic organization cannot do. An organization that is dominated by a certain kind of thinking may consequently be incapable of other kinds of thinking.
Some writers use the left-brain / right-brain metaphor, and characterize analytics as exclusively left-brain in character. I'm not convinced by this metaphor, but it may well be true that analytic organizations have characteristic patterns of strength and weakness. So I was especially interested to find a "think piece" from the CIA which calls for
and concludes that
Thus opening up the possibility for analytic organizations of transcending the stereotype.
Warren Fishbein and Gregory Treverton, Rethinking “Alternative Analysis” to Address Transnational Threats, The Sherman Kent Center for Intelligence Analysis, Occasional Papers: Volume 3, Number 2, Oct. ‘04. [For further comments on Treverton's work, see my post Puzzles and Mysteries.]
Peter Graham, Building the analytic organization (Information Management, August 2007).
Bob Marshall, The Marshall Model of Organisational Evolution (October 2010)
Updated 5 May 2020
analytic organization.
One way is to define a set of capabilities and working practices loosely called
analytics, and use the label
analytic organizationfor an organization that has reached a certain level of collective competence or maturity in these. This is the approach taken by Peter Graham, who recommends the following set of characteristic features.
- Formal functional role (e.g. Chief Analytics Officer)
- Enterprise analytics applied across all functions of the organization
- Shared analytics
Understanding the drivers of the business
- Focus on applying order to information to create knowledge
- Common platform centrally maintained by analytic functional group
It's often a good idea to have a centre of excellence to promote and coordinate some desired capability, and Peter's centralized approach may make sense for many organizations. However, I'd be reluctant to say that Peter's approach is the only possible approach for building the analytic organization, and I should like to think that some organizations (depending on culture and circumstances) will achieve greater results with a more decentralized approach.
Meanwhile, @joemckendrick talks about an analytic organization in terms of the ability to fully leverage data (Joe McKendrick, 7 Simple Steps to Becoming an Analytic Organization, Insurance Experts' Forum, June 18, 2010). He quotes Christina Colby of CapGemini as identifying three ingredients for using analytics to its full potential as a competitive asset:
- treasure-troves of data
- the right analytic applications
- effective management.
Lex Donaldson goes one step further than everyone else. His book is called The Meta-Analytic Organization, and is based on something he calls Statistico-Organizational Theory, which appears to be a combination of statistics and psychometrics.
Meanwhile, other writers such as Bob Marshall (@flowchainsensei) focus attention on what a so-called analytic organization cannot do. An organization that is dominated by a certain kind of thinking may consequently be incapable of other kinds of thinking.
Some writers use the left-brain / right-brain metaphor, and characterize analytics as exclusively left-brain in character. I'm not convinced by this metaphor, but it may well be true that analytic organizations have characteristic patterns of strength and weakness. So I was especially interested to find a "think piece" from the CIA which calls for
an alternative analysis approach that is more an ongoing organizational process aimed at promoting.mindfulness—continuous wariness of analytic failure—than a set of tools that analysts are encouraged to employ when needed
and concludes that
Intelligence Community analytic organizations need to institutionalize sustained, collaborative efforts by analysts to question their judgments and underlying assumptions, employing both critical and creative modes of thought. For this approach to be effective, significant changes in the cultures and business processes of analytic organizations will be required.
Thus opening up the possibility for analytic organizations of transcending the stereotype.
Warren Fishbein and Gregory Treverton, Rethinking “Alternative Analysis” to Address Transnational Threats, The Sherman Kent Center for Intelligence Analysis, Occasional Papers: Volume 3, Number 2, Oct. ‘04. [For further comments on Treverton's work, see my post Puzzles and Mysteries.]
Peter Graham, Building the analytic organization (Information Management, August 2007).
Bob Marshall, The Marshall Model of Organisational Evolution (October 2010)
Updated 5 May 2020
Wednesday, January 20, 2010
Towards an Enterprise Architecture of Knowledge
A customary way of modelling an enterprise is as a collection of purposeful behaviours - functions or processes or capabilities or whatever. Each function or process or capability encapsulates some knowledge or know-how. Sometimes this knowledge will be fairly static, so the behaviour will be stable and unchanging. And sometimes the underlying knowledge will change, so the behaviour will need to be adjusted to accommodate the most up-to-date and relevant knowledge. In some areas, such as product development and marketing, there may be a strategic imperative to find and assimilate new knowledge and ideas (about market trends, technology trends, competitor trends, and so on), to build new collaborative partnerships, and to experiment with new behaviours. These areas will rely on business intelligence - not just BI tools but all the practices associated with collecting and making sense of complex information.
The overall architecture of the enterprise can then be understood in terms of how these functions or processes or capabilities interoperate to produce a viable system-of-systems. The enterprise architect must understand which of these functions are relatively stable, which of them are strategically volatile, and create appropriate mechanisms for coordinating between them. These mechanisms are essentially behavioural ones - information flows, event triggers, process flows and so on.
But if we look at the enterprise through a knowledge management lens, we will see a different kind of structure. There is a series of overlapping knowledge domains - marketing, accounting, regulatory compliance, health and safety, employment, technology - each with its own specialist terminology and ways of thinking. So there is an architectural question about how these knowledge domains (we might also call them agendas or discourses) interoperate.
In a traditional organization, these knowledge domains only come together at board level, with one or more directors speaking for each significant domain. Thus the CTO speaks for the technology domain, the HR director speaks for the employment domain, and so on. Of course all the directors will try to influence the agenda of their peers - so everyone else might be citing random snippets of evidence of technology trends, or challenging the CTO's decisions and interpretations, pushing the CTO to explain or change direction. In a well-functioning organization, this will be all done in the spirit of healthy and vigorous debate.
In a hierarchical organization, some pieces of this debate can of course be delegated - either to internal departments or to external consultants - but the directors remain responsible for putting the pieces together.
Thus the coherence and intelligence of a traditional organization depends heavily on the collective intelligence and effective functioning of the board of directors. But there are several evident problems with this approach. Firstly, we can observe many organizations that lack coherence and intelligence, so this approach is manifestly not working well enough for these organizations. Secondly, we may assume that the board of directors has a finite reasoning capacity - however clever they are as individuals, and however well-bonded they are as a team - and that they will not always be able to keep up with the increasing complexity and volatility of the business environment. And thirdly, we can see a lack of joined-up intelligence at the lower levels of the organization.
Some people think there is a different way of integrating an enterprise. If we can identify a single universal knowledge domain, then we can use this knowledge domain to join up everything else. For example, in a financially driven organization, management accounting acts as a unifying language across all functions. Conversely, many enterprise architects regard their favourite EA framework as providing such a unifying language. Although there have certainly been very large organizations that have been managed according to a single unifying principle (such as GEC under Lord Weinstock), the fact that there are several specialisms each wanting to be top dog helps to explain why this doesn't work very often.
A third idea would be a bottom-up Enterprise 2.0 swarm intelligence, in which a satisfactory resolution to all difficult issues emerges from uncontrolled debate and "sharing" across the organization. To read some of the material on the internet, it's tempting to believe that this is how some of the really cool organizations in Silicon Valley are organized. But even if this were true, there is still a need for some kind of architecture and governance, for example, providing suitable platforms and pathways for constructive and reasonably efficient problem-solving. Kevin Kelly, whose book Out of Control introduced me and many other people to the huge potential of bottom-up intelligence, is careful to warn that the bottom is not enough.
Which brings me to the fourth idea - regarding the coherence and intelligence of the knowledge-bearing organization as a real architectural issue. Not the kind of structure that enterprise architects are accustomed to modelling or managing perhaps, but this structure may have a significant effect on the business outcomes of the organization. Isn't this something enterprise architects should be interested in?
The overall architecture of the enterprise can then be understood in terms of how these functions or processes or capabilities interoperate to produce a viable system-of-systems. The enterprise architect must understand which of these functions are relatively stable, which of them are strategically volatile, and create appropriate mechanisms for coordinating between them. These mechanisms are essentially behavioural ones - information flows, event triggers, process flows and so on.
But if we look at the enterprise through a knowledge management lens, we will see a different kind of structure. There is a series of overlapping knowledge domains - marketing, accounting, regulatory compliance, health and safety, employment, technology - each with its own specialist terminology and ways of thinking. So there is an architectural question about how these knowledge domains (we might also call them agendas or discourses) interoperate.
In a traditional organization, these knowledge domains only come together at board level, with one or more directors speaking for each significant domain. Thus the CTO speaks for the technology domain, the HR director speaks for the employment domain, and so on. Of course all the directors will try to influence the agenda of their peers - so everyone else might be citing random snippets of evidence of technology trends, or challenging the CTO's decisions and interpretations, pushing the CTO to explain or change direction. In a well-functioning organization, this will be all done in the spirit of healthy and vigorous debate.
In a hierarchical organization, some pieces of this debate can of course be delegated - either to internal departments or to external consultants - but the directors remain responsible for putting the pieces together.
Thus the coherence and intelligence of a traditional organization depends heavily on the collective intelligence and effective functioning of the board of directors. But there are several evident problems with this approach. Firstly, we can observe many organizations that lack coherence and intelligence, so this approach is manifestly not working well enough for these organizations. Secondly, we may assume that the board of directors has a finite reasoning capacity - however clever they are as individuals, and however well-bonded they are as a team - and that they will not always be able to keep up with the increasing complexity and volatility of the business environment. And thirdly, we can see a lack of joined-up intelligence at the lower levels of the organization.
Some people think there is a different way of integrating an enterprise. If we can identify a single universal knowledge domain, then we can use this knowledge domain to join up everything else. For example, in a financially driven organization, management accounting acts as a unifying language across all functions. Conversely, many enterprise architects regard their favourite EA framework as providing such a unifying language. Although there have certainly been very large organizations that have been managed according to a single unifying principle (such as GEC under Lord Weinstock), the fact that there are several specialisms each wanting to be top dog helps to explain why this doesn't work very often.
A third idea would be a bottom-up Enterprise 2.0 swarm intelligence, in which a satisfactory resolution to all difficult issues emerges from uncontrolled debate and "sharing" across the organization. To read some of the material on the internet, it's tempting to believe that this is how some of the really cool organizations in Silicon Valley are organized. But even if this were true, there is still a need for some kind of architecture and governance, for example, providing suitable platforms and pathways for constructive and reasonably efficient problem-solving. Kevin Kelly, whose book Out of Control introduced me and many other people to the huge potential of bottom-up intelligence, is careful to warn that the bottom is not enough.
Which brings me to the fourth idea - regarding the coherence and intelligence of the knowledge-bearing organization as a real architectural issue. Not the kind of structure that enterprise architects are accustomed to modelling or managing perhaps, but this structure may have a significant effect on the business outcomes of the organization. Isn't this something enterprise architects should be interested in?
Monday, December 21, 2009
Beyond the Predictive Enterprise
@ebizQ James Taylor says you (or more likely your organization) should be striving to become a predictive enterprise. His definition comes from an old SPSS presentation.
But prediction forms part of an important learning loop. We make predictions in order to take better actions. There is no point making predictions about customer behaviour unless this prediction allows you to create some value for the customer.
Secondly, we take actions with uncertain outcomes, in order to improve our future ability to predict. Received wisdom may tell us that the “best” colour packaging for a given product is blue, but an inquisitive organization will continually experiment with different packaging rather than settle for a “best practice” solution.
Thirdly, intelligent behaviour allows for its own likely effects. For example, if an intelligent organization drops its prices, it has already considered how (and how quickly) competitors might respond. (In contrast, a stupid organization predicts the outcome of a marketing offensive as if they don't expect other players to retaliate.)
So instead of predictive, I prefer the term anticipative or anticipatory. Anticipation means not passively predicting the future, but taking action in advance of the future. Robert Rosen defined an anticipatory system as "containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a latter instant". Thus anticipatory contains a degree of self-awareness and self-embodiment, which allows proactive and agile action, not merely disinterested forecasting. This is an essential aspect of what I call Organizational Intelligence.
- Derives maximum value from its data assets
- Understands its business by gaining deep insight
- Leverages advanced analytics to predict outcomes
- Turns this knowledge into action to optimize decision making across all areas of its operations
But prediction forms part of an important learning loop. We make predictions in order to take better actions. There is no point making predictions about customer behaviour unless this prediction allows you to create some value for the customer.
Secondly, we take actions with uncertain outcomes, in order to improve our future ability to predict. Received wisdom may tell us that the “best” colour packaging for a given product is blue, but an inquisitive organization will continually experiment with different packaging rather than settle for a “best practice” solution.
Thirdly, intelligent behaviour allows for its own likely effects. For example, if an intelligent organization drops its prices, it has already considered how (and how quickly) competitors might respond. (In contrast, a stupid organization predicts the outcome of a marketing offensive as if they don't expect other players to retaliate.)
So instead of predictive, I prefer the term anticipative or anticipatory. Anticipation means not passively predicting the future, but taking action in advance of the future. Robert Rosen defined an anticipatory system as "containing a predictive model of itself and/or its environment, which allows it to change state at an instant in accord with the model's predictions pertaining to a latter instant". Thus anticipatory contains a degree of self-awareness and self-embodiment, which allows proactive and agile action, not merely disinterested forecasting. This is an essential aspect of what I call Organizational Intelligence.
Friday, May 08, 2009
From Business Intelligence to Organizational Intelligence
#orgintelligence ...
Business Intelligence (BI) is one component of what I'm calling Organizational Intelligence, so let's look at some useful trends within the BI world that are relevant to Org Intelligence, as well as some criticisms of the current state of the art in BI.
Last month Charles Nicholls (SeeWhy CEO) attacked IBM in his blog for (as he claims) neglecting the web: What about the web, IBM? At eBizQ, Michael Dortch offers a more balanced view: Some Shafts of Light. The real proof will be if IBM's new Business Analytics and Optimization Services unit will address the kind of real-time process issues identified by SeeWhy a couple of years ago.
Nari Kannan also criticizes conventional BI for its lack of connection to the business process. Drawbacks of Business Intelligence Tools When Handling Business Processes.
Dave Linthicum agrees.
Business Intelligence (BI) is one component of what I'm calling Organizational Intelligence, so let's look at some useful trends within the BI world that are relevant to Org Intelligence, as well as some criticisms of the current state of the art in BI.
Real-time, event-driven process-driven BI
Over the past couple of years, we've seen the emergence of real-time BI platforms such as SeeWhy. Champions of realtime BI suggest that it can address weakness of conventional BI, including- out-of-date information
- failure to identify process problems
- lack of suitability as predictors
Last month Charles Nicholls (SeeWhy CEO) attacked IBM in his blog for (as he claims) neglecting the web: What about the web, IBM? At eBizQ, Michael Dortch offers a more balanced view: Some Shafts of Light. The real proof will be if IBM's new Business Analytics and Optimization Services unit will address the kind of real-time process issues identified by SeeWhy a couple of years ago.
Nari Kannan also criticizes conventional BI for its lack of connection to the business process. Drawbacks of Business Intelligence Tools When Handling Business Processes.
"When it comes to Process or Operational Intelligence, the problem becomes slightly different. Post mortem, rear view mirror kind of information is not very useful. Knowing that you screwed up a patient's surgery experience or the Automobile Insurance Claim, after the fact is not as useful as getting real-time information as and when it is happening and you have a chance to set things right."
Collaborative decision-making
In January, Gartner published some forecasts about the BI market for the next three years, including this.In 2009, collaborative decision making will emerge as a new product category that combines social software with BI Platform capabilities. The emergence of social software presents an opportunity for savvy IT leaders to exploit the groundswell of interest in informal collaboration. Instead of promoting a formal, top-down decision-making initiative, these IT leaders will tap people's natural inclination to use social software to collaborate and make decisions.
Dave Linthicum agrees.
"This is occurring now, and is a huge area of growth in BI, if you ask me. With all of that good data being placed on the social networks these days, the BI applications around mining that data is going to be extremely valuable."
Collaborative BI
I predicted the emergence of collaborative business intelligence nearly four years ago (Service-Oriented Business Intelligence). So I am very happy to see early signs that this might now be moving into the realm of practical application. If you are a BI toolmaker or advanced user, I'd be delighted to talk to you.Wednesday, April 01, 2009
Enterprise as a Network of Events 2
Following my post on Enterprise as a Network of Events, Nigel Green drew my attention to something he wrote a couple of years ago on the case for a clear distinction between events and content, in which he points out that "aggregated events become content over time".
As it happens, I touched on something like this in my 1992 book on Information Modelling. At that time, the specific question I was addressing was how to represent the history of organizational change in a data model. There are two basic options.
What both representations have in common is a definition of information in terms of difference: a difference that makes a difference, as Bateson puts it.
A lizard hunting insects operates on the same principle. The lizard's eye only reports movement to the lizard's brain. If the hunted insect settles on a leaf, the lizard literally cannot see it. But the moment the insect starts to move, whop, the lizard can see it again, and the tongue flickers out and catches it.
But there are differences and differences. Information is difference that makes a difference. You were probably aware, as you dropped the coin into your palm, your eyes told you automatically, without your brain even asking, what the value of the coin was; but you were probably not aware what date it was minted. This is because (unless you are a numismatist) the value of the coin makes a difference to you whereas its date doesn't.
What is it that makes a difference to a lizard, to a numismatist, to you? Surely not the same things. What is information for the lizard is not information for you, and what is information for you is not information for the lizard.
This is why the perspective of information is important. Perspective defines what counts as information at all, perspective defines to whom the information makes a difference.
Now what's this got to do with the enterprise? There are two important differentiation questions for any enterprise: how do They differentiate Us, and how do We differentiate Them.
Firstly how do They differentiate Us. In other words what differences in our products and services or organization are (a) going to be noticed by external stakeholders such as customers and (b) going to affect the behaviour and attitudes of these stakeholders.
Sophisticated marketing organizations pay a lot of attention to this kind of thing. Does it make a difference if we put this in a blue envelope? Does it make a difference if we have a female voice here? Sometimes you have to experiment with differences that don't matter, in order to have a refined view of what differences do matter.
Secondly, how do We differentiate Them. What are the strong signals in the environment that we must respond to, and what are the weak signals we might respond to? An organization that responded to every weak signal would be impossibly unstable, so most organizations have operational processes that respond to strong signals, and some form of business intelligence that scans the environment for weak signals and identifies a subset of these signals demanding some kind of response.
Sometimes the appropriate response to some detected difference or discrepancy is some kind of business improvement, such as business process improvement and/or system engineering. Which means that the history of the organization is inscribed into its current structure and processes.
But that's not actually what I'm trying to do. I think understanding an organization as an information-processing system helps us to do two practical and concrete things.
My next question is: what kind of business model supports these challenges.
As it happens, I touched on something like this in my 1992 book on Information Modelling. At that time, the specific question I was addressing was how to represent the history of organizational change in a data model. There are two basic options.
- History is represented as a series of snapshots of the organization at specific times. If you want to know what the change was, you just have to compare two snapshots. (For example, this is how page history is represented on Wikipedia.)
- History is represented as a series of changes (differences). Then if you want to know what the state of the organization was at a given time, you just have to aggregate the changes forwards or backwards from a fixed point.
What both representations have in common is a definition of information in terms of difference: a difference that makes a difference, as Bateson puts it.
Information as Difference
Hold your hand perfectly still, palm upwards and resting comfortably on a table. With your other hand, drop a small coin into the palm. You will feel the impact, and if the coin is cold, you will feel the coldness of the metal. Soon however, you will feel nothing. The nerve cells don't bother repeating themselves. They will only report to the brain when something changes. Information is difference.A lizard hunting insects operates on the same principle. The lizard's eye only reports movement to the lizard's brain. If the hunted insect settles on a leaf, the lizard literally cannot see it. But the moment the insect starts to move, whop, the lizard can see it again, and the tongue flickers out and catches it.
But there are differences and differences. Information is difference that makes a difference. You were probably aware, as you dropped the coin into your palm, your eyes told you automatically, without your brain even asking, what the value of the coin was; but you were probably not aware what date it was minted. This is because (unless you are a numismatist) the value of the coin makes a difference to you whereas its date doesn't.
What is it that makes a difference to a lizard, to a numismatist, to you? Surely not the same things. What is information for the lizard is not information for you, and what is information for you is not information for the lizard.
This is why the perspective of information is important. Perspective defines what counts as information at all, perspective defines to whom the information makes a difference.
Enterprise Strategy and Difference
Now what's this got to do with the enterprise? There are two important differentiation questions for any enterprise: how do They differentiate Us, and how do We differentiate Them.
Firstly how do They differentiate Us. In other words what differences in our products and services or organization are (a) going to be noticed by external stakeholders such as customers and (b) going to affect the behaviour and attitudes of these stakeholders.
Sophisticated marketing organizations pay a lot of attention to this kind of thing. Does it make a difference if we put this in a blue envelope? Does it make a difference if we have a female voice here? Sometimes you have to experiment with differences that don't matter, in order to have a refined view of what differences do matter.
Secondly, how do We differentiate Them. What are the strong signals in the environment that we must respond to, and what are the weak signals we might respond to? An organization that responded to every weak signal would be impossibly unstable, so most organizations have operational processes that respond to strong signals, and some form of business intelligence that scans the environment for weak signals and identifies a subset of these signals demanding some kind of response.
Sometimes the appropriate response to some detected difference or discrepancy is some kind of business improvement, such as business process improvement and/or system engineering. Which means that the history of the organization is inscribed into its current structure and processes.
"What's the purpose of this process step?"If we knew enough (which of course we don't), we might conceivable infer the current state of the organization from a careful analysis of all the events that have ever happened to it. That would join this post back to where we started. Neat but impractical.
"We've done that extra check ever since we got badly burned in the XYZ deal five years ago."
But that's not actually what I'm trying to do. I think understanding an organization as an information-processing system helps us to do two practical and concrete things.
- Diagnose the current problems and opportunities facing a complex organization.
- Design an event-driven business improvement process, based on business intelligence.
My next question is: what kind of business model supports these challenges.
Monday, March 09, 2009
Service-Orientation and Bureaucracy
A lot of business services are difficult to value. Take HR for example.
During an economic crisis, HR performs some pretty unpopular services. On the one hand, they may be the bearer of bad news to the redundant employee. On the other hand, they may restrict the authority of the line manager to dismiss employees without following the proper procedure. Does HR bureaucracy get in your way? asks Michael D Haberman. Newest despised role, suggests Dana Gardner, they are in no-win situation given economic climate.
However, the unpopularity of HR is nothing new. I fished out an old article called Taking on the Last Bureaucracy (Fortune Magazine, January 1996) and showed it to a few people, including Annrai O'Toole.
As ESB afficionados may recall, Annrai was the boss of Cape Clear Software, which was acquired by SaaS company Workday last year. Workday offers HR-as-a-Service plus Payroll, Worker Spend Management, Financials: ERP-as-a-Service, with a strong focus on human capital management.
Annrai agreed that the article was (sadly) still relevant, and made three further points
But what is the business model for HR? What value does HR provide at the business level, and how can we design a portfolio of services to maintain and enhance this business value? If HR is strategic, does this mean that each enterprise has different requirements for HR services?
Bureaucracies are relatively easy to automate, if that's what you want to do. You can make a bureaucracy faster and more efficient, and you can move a lot of clerical processing onto an online self-service portal. But making a system more efficient doesn't necessarily make it more effective. So good design requires system thinking at the business level, before you dive into computer systems architectures, service-oriented or otherwise.
Maybe I'm being old-fashioned, but I can't see that it makes much sense to invest in an SOA or SaaS project to reduce the headcount of the HR department by (say) 25% if you still don't have much idea what value the remaining 75% are going to provide, and how you are going to make them more effective.
During an economic crisis, HR performs some pretty unpopular services. On the one hand, they may be the bearer of bad news to the redundant employee. On the other hand, they may restrict the authority of the line manager to dismiss employees without following the proper procedure. Does HR bureaucracy get in your way? asks Michael D Haberman. Newest despised role, suggests Dana Gardner, they are in no-win situation given economic climate.
However, the unpopularity of HR is nothing new. I fished out an old article called Taking on the Last Bureaucracy (Fortune Magazine, January 1996) and showed it to a few people, including Annrai O'Toole.
As ESB afficionados may recall, Annrai was the boss of Cape Clear Software, which was acquired by SaaS company Workday last year. Workday offers HR-as-a-Service plus Payroll, Worker Spend Management, Financials: ERP-as-a-Service, with a strong focus on human capital management.
Annrai agreed that the article was (sadly) still relevant, and made three further points
- HR must be strategic (not paper pushing) ...
- performance measurement must be automated and linked to business performance, not just subjective objectives - better BI (on hard business metrics) is the way to go.
- HR tooling must breakdown the barrier between the workers it serves and the environment they work in
But what is the business model for HR? What value does HR provide at the business level, and how can we design a portfolio of services to maintain and enhance this business value? If HR is strategic, does this mean that each enterprise has different requirements for HR services?
Bureaucracies are relatively easy to automate, if that's what you want to do. You can make a bureaucracy faster and more efficient, and you can move a lot of clerical processing onto an online self-service portal. But making a system more efficient doesn't necessarily make it more effective. So good design requires system thinking at the business level, before you dive into computer systems architectures, service-oriented or otherwise.
Maybe I'm being old-fashioned, but I can't see that it makes much sense to invest in an SOA or SaaS project to reduce the headcount of the HR department by (say) 25% if you still don't have much idea what value the remaining 75% are going to provide, and how you are going to make them more effective.
Wednesday, November 26, 2008
From Complex Events to Predictive Analytics
Beth Gold-Bernstein (eBizQ) reckons that predictive analytics, which she describes as "a capability based on complex event processing (CEP)" is A Good Investment for a Down Economy.
Hans Gilde is scornful. In Predictive analytics, CEP and your local mechanic, he points out that the key capability for an effective predictive system is "a solid foundation for ongoing critical analysis of the effectiveness of your analytics".
I would extend his scorn to anyone who uses the term "real-time" in a sloppy and confused manner. I keep reading about "real-time complex event processing", but in many cases it looks as if much of the complex processing is actually done at design-time, leaving the real-time portion fairly quick and simple. And that's probably as much as the current state-of-the-art technology can manage.
To do predictive analytics properly, as Hans says, you need critical analysis - what is sometimes called double-loop learning. How does a CEP system learn new patterns? How does a CEP get recalibrated as the environment evolves? How do we control (and reduce) the level of false positives and false negatives? And how much of this analysis does it make sense to even attempt in real-time?
So I looked at a recent paper in the IBM Systems Journal, Generating real-time complex event-processing applications (Volume 47, Number 2, 2008).
The IBM paper talks about some of the challenges of achieving genuine real-time data extraction based on predefined patterns, and talks about the possibility of real-time CEP applications, but is careful not to make any larger claims.
Other writers are not so careful, and you can find lots of websites promising real-time predictive analytics or real-time decision-making. But there are not only technological but conceptual limits to what you can do in real-time.
Hans Gilde is scornful. In Predictive analytics, CEP and your local mechanic, he points out that the key capability for an effective predictive system is "a solid foundation for ongoing critical analysis of the effectiveness of your analytics".
I would extend his scorn to anyone who uses the term "real-time" in a sloppy and confused manner. I keep reading about "real-time complex event processing", but in many cases it looks as if much of the complex processing is actually done at design-time, leaving the real-time portion fairly quick and simple. And that's probably as much as the current state-of-the-art technology can manage.
To do predictive analytics properly, as Hans says, you need critical analysis - what is sometimes called double-loop learning. How does a CEP system learn new patterns? How does a CEP get recalibrated as the environment evolves? How do we control (and reduce) the level of false positives and false negatives? And how much of this analysis does it make sense to even attempt in real-time?
So I looked at a recent paper in the IBM Systems Journal, Generating real-time complex event-processing applications (Volume 47, Number 2, 2008).
"Complex event processing (CEP) enables the extraction of meaningful and actionable information from event streams. The CEP technology is intended to provide applications with a flexible and scalable mechanism for constructing condensed, refined views of the data. CEP correlates the data (viewed as event streams) in order to detect and report meaningful predefined patterns, thus supplying the application with an effective view of the accumulated incoming data (events), and allowing the application to react to the detections by executing actions."
The IBM paper talks about some of the challenges of achieving genuine real-time data extraction based on predefined patterns, and talks about the possibility of real-time CEP applications, but is careful not to make any larger claims.
Other writers are not so careful, and you can find lots of websites promising real-time predictive analytics or real-time decision-making. But there are not only technological but conceptual limits to what you can do in real-time.
Tuesday, October 14, 2008
Laundry as Intelligence
During the "troubles" in Northern Ireland, the British Army operated a laundry - an apparently innocent laundry with some additional hidden functionality - checking dirty clothes for traces of explosive. [Washington Post via Bruce Schneier]
In my earlier post Services Like Laundry I said "I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to anyone". Clearly the actions of the British Army would count as a breach of this kind of expectation, but this would be justified by its effectiveness as a clever counter-terrorism measure. However, laundries might well test for various other substances, or test the DNA of any stains on the clothing, for a broad range of purposes other than counter-terrorism.
So what's the lesson from this? Basically, if you have any illicit substances or just embarrassing stains on your clothing, you can't trust the laundry service not to notice. And you certainly can't specify this not-noticing as part of the service contract - what are you going to do, draw the laundryman's attention to the thing he isn't supposed to notice?
And what if the laundryman noticed your shirts were getting a little frayed about the collar, and sold your address, together with details of your designer-label preferences, to a mail order shirt supplier? You might think this was unreasonable if you knew about it, but you would probably never find out. You might receive a mailshot from the shirt supplier, but you probably wouldn't connect it with the laundryman. (One possible mechanism for tracing abuse of your name and address is to give slightly variant names and addresses to every supplier, but lots of organizations nowadays have clever data cleansing software that wipes out these variations.)
How does this apply to other kinds of service? If I use CRM-as-a-service, how can I prevent my service provider picking up information about my customers? If I use a third-party delivery service, how can I prevent the service provider selling details of my customers and their purchasing habits to my competitors? How can I even specify this as part of the service level agreement?
WS Security standards cover some aspects of confidentiality and trust, but this merely relates to the security of a message in transit (at the technology level), and not to the broader questions of confidentiality and trust between two parties (at the enterprise level).
According to legend, the automatic telephone exchange was invented by an undertaker (Almon Strowger) who believed his business was being redirected to his competitors by corrupt telephone operators. (See Call Forwarding.) So this suggests a possible answer to this difficulty is to redesign the service architecture to reduce the enterprise vulnerability, supported by more sophisticated technology. For example, does your CRM provider really need unencrypted names and addresses, or can you pass your customer data through an encryption module?
So what's the lesson from this? You need an enterprise view of trust and security that is supported by (aligned with) a technology view of trust and security. The relationship between these two views is tough.
In my earlier post Services Like Laundry I said "I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to anyone". Clearly the actions of the British Army would count as a breach of this kind of expectation, but this would be justified by its effectiveness as a clever counter-terrorism measure. However, laundries might well test for various other substances, or test the DNA of any stains on the clothing, for a broad range of purposes other than counter-terrorism.
So what's the lesson from this? Basically, if you have any illicit substances or just embarrassing stains on your clothing, you can't trust the laundry service not to notice. And you certainly can't specify this not-noticing as part of the service contract - what are you going to do, draw the laundryman's attention to the thing he isn't supposed to notice?
And what if the laundryman noticed your shirts were getting a little frayed about the collar, and sold your address, together with details of your designer-label preferences, to a mail order shirt supplier? You might think this was unreasonable if you knew about it, but you would probably never find out. You might receive a mailshot from the shirt supplier, but you probably wouldn't connect it with the laundryman. (One possible mechanism for tracing abuse of your name and address is to give slightly variant names and addresses to every supplier, but lots of organizations nowadays have clever data cleansing software that wipes out these variations.)
How does this apply to other kinds of service? If I use CRM-as-a-service, how can I prevent my service provider picking up information about my customers? If I use a third-party delivery service, how can I prevent the service provider selling details of my customers and their purchasing habits to my competitors? How can I even specify this as part of the service level agreement?
WS Security standards cover some aspects of confidentiality and trust, but this merely relates to the security of a message in transit (at the technology level), and not to the broader questions of confidentiality and trust between two parties (at the enterprise level).
According to legend, the automatic telephone exchange was invented by an undertaker (Almon Strowger) who believed his business was being redirected to his competitors by corrupt telephone operators. (See Call Forwarding.) So this suggests a possible answer to this difficulty is to redesign the service architecture to reduce the enterprise vulnerability, supported by more sophisticated technology. For example, does your CRM provider really need unencrypted names and addresses, or can you pass your customer data through an encryption module?
So what's the lesson from this? You need an enterprise view of trust and security that is supported by (aligned with) a technology view of trust and security. The relationship between these two views is tough.
Saturday, January 19, 2008
Technological Perfecta
There are several technologies that might work well together, indeed they certainly should work well together. At various times in this blog, I've talked about the potential synergies between (i) SOA and Business Intelligence, (ii) SOA and Business Process Management, and (iii) SOA/EDA and Complex Event Processing. The third of these synergies is currently getting some attention, following some enthusiastic remarks by Jerry Cuomo, WebSphere CTO (see Rich Seeley and Joe McKendrick).
All four together would be amazing, but a lot of organizations aren't ready for this. Moreover each technology has its own set of tools and platforms, and its own set of disciplines and disciples.
In Betting on the SOA Horse, Tim Bass describes this potential synergy using the language of gambling - exacta and trifecta. I'm not very familiar with this language, but what I think this means is that you only win the bet if the horses pass the post in the correct sequence. Tim writes:
In On Trifecta and Event Processing, Opher Etzion disagrees with this metaphor. He argues that these technologies are mutually independent (he calls them "orthogonal"). If he is correct, this would have three consequences: (i) flexibility of deployment - you can implement and exploit them in any sequence; (ii) flexibility of benefit - you can get business benefits from any of them in isolation, and then additional benefits if and when they are all deployed together; and therefore (iii) considerably lower risk.
My position on this is closer to Opher. I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies. P has a hard dependency on Q if Q is necessary for P. Whereas P has a soft dependency on Q if Q is desirable for P.
In planning a technology change programme, it is very useful to recognize soft dependencies, because it permits some deconfliction between different elements. Deconfliction here means forced decoupling, understanding that the results may be sub-optimal (at least initially), but accepting this in the interests of getting things done.
In a perfect world, we might want to deploy all four technologies together, or in a precisely defined sequence. But pragmatism suggests we don't bet on the impossible or highly improbable. The challenge for the technology architect is to organize a technology portfolio to get the best balance of risk and reward. This is not primarily about comparing the features of different products, but about understanding the fundamental structural principles that allow these technologies to be deployed in a flexible and efficient manner.
Discussion continues: Technological Perfecta 2
All four together would be amazing, but a lot of organizations aren't ready for this. Moreover each technology has its own set of tools and platforms, and its own set of disciplines and disciples.
In Betting on the SOA Horse, Tim Bass describes this potential synergy using the language of gambling - exacta and trifecta. I'm not very familiar with this language, but what I think this means is that you only win the bet if the horses pass the post in the correct sequence. Tim writes:
"Betting on horses is a risky business. Exactas and trifecta have enormous payouts, but the odds are remote."
In On Trifecta and Event Processing, Opher Etzion disagrees with this metaphor. He argues that these technologies are mutually independent (he calls them "orthogonal"). If he is correct, this would have three consequences: (i) flexibility of deployment - you can implement and exploit them in any sequence; (ii) flexibility of benefit - you can get business benefits from any of them in isolation, and then additional benefits if and when they are all deployed together; and therefore (iii) considerably lower risk.
My position on this is closer to Opher. I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies. P has a hard dependency on Q if Q is necessary for P. Whereas P has a soft dependency on Q if Q is desirable for P.
In planning a technology change programme, it is very useful to recognize soft dependencies, because it permits some deconfliction between different elements. Deconfliction here means forced decoupling, understanding that the results may be sub-optimal (at least initially), but accepting this in the interests of getting things done.
In a perfect world, we might want to deploy all four technologies together, or in a precisely defined sequence. But pragmatism suggests we don't bet on the impossible or highly improbable. The challenge for the technology architect is to organize a technology portfolio to get the best balance of risk and reward. This is not primarily about comparing the features of different products, but about understanding the fundamental structural principles that allow these technologies to be deployed in a flexible and efficient manner.
Discussion continues: Technological Perfecta 2
Thursday, September 22, 2005
Service-Oriented Business Intelligence
What can SOA offer to business intelligence?
This reflects a common attitude about BI – that because the complex stuff is hard to use, and costly to service, therefore it is only going to be used by a small number of highly skilled users working on stand-alone problems.
The complex stuff is also hard to specify. Traditional system development methods are not very helpful in defining the more complex information needs, but we are looking at alternative methods of requirements analysis. See my previous post on Business Intelligence Requirements (Sept 2005).
Closed-Loop, Holistic and Real-Time BI
In June 2003, I produced a report for the CBDI Forum on Web Services for BI, which talked about closed-loop business intelligence. Among other things, this includes the ability to generate derived data objects (such as customer clusters), which can be made available for further BI enquiry or even automatically re-input into the operational information systems. One way of doing this is to wrap BI enquiries as web services, which can then be invoked from the operational applications. This is known as Embedded BI.
Anant Jhingran, IBM's director of business intelligence, made the following points to journalists last summer.
SOBI Roadmap
We can identify four general ways of managing and implementing BI, as follows.
1. Stand-Alone BI
BI activities are decoupled and desynchronized from the business and from operational systems. BI activities are performed by independent knowledge workers.
2. Embedded BI
3. Integrated BI
4. Collaborative BI
I'd like to develop this roadmap further, with the help of my readers. I should be most interested to hear from vendors and others. Who in your organization is doing this stuff? Please let me know about your products, projects and future plans.
Five Types of BI
The BI vendor MicroStrategy has identified five types of business intelligence, which are (not surprisingly) covered by its own BI tools. The five types are differentiated in two ways: firstly by the number and range of users, and secondly by the degree of analytical sophistication and user interactivity. According to MicroStrategy, these two are inversely proportional – thus the greater the number and range of users, the lower the sophistication and interactivity. MicroStrategy's five types of BI can therefore be arranged in a 2x2 matrix with the top right quadrant empty.
This reflects a common attitude about BI – that because the complex stuff is hard to use, and costly to service, therefore it is only going to be used by a small number of highly skilled users working on stand-alone problems.
The complex stuff is also hard to specify. Traditional system development methods are not very helpful in defining the more complex information needs, but we are looking at alternative methods of requirements analysis. See my previous post on Business Intelligence Requirements (Sept 2005).
Closed-Loop, Holistic and Real-Time BI
In June 2003, I produced a report for the CBDI Forum on Web Services for BI, which talked about closed-loop business intelligence. Among other things, this includes the ability to generate derived data objects (such as customer clusters), which can be made available for further BI enquiry or even automatically re-input into the operational information systems. One way of doing this is to wrap BI enquiries as web services, which can then be invoked from the operational applications. This is known as Embedded BI.Anant Jhingran, IBM's director of business intelligence, made the following points to journalists last summer.
- it's not enough for an ETL tool to just grab data and dump it in a warehouse; you need the data that has made it into the warehouse, and the data that might be part of the business processes
- you also need data that is outside traditional sources and outside the enterprise
- current information is important; putting it into historical perspective is equally crucial
- business process monitoring and business activity monitoring is about a holistic perspective on the historical and current data. It's all about synergies between the warehouse and business processes. It's all about unification around XML because XML is the way business processes are communicating the data
SOBI Roadmap
We can identify four general ways of managing and implementing BI, as follows.1. Stand-Alone BI
BI activities are decoupled and desynchronized from the business and from operational systems. BI activities are performed by independent knowledge workers.
Current BI practice?
2. Embedded BI
- BI enquiries are wrapped as services and invoked from the operational systems.
- For example, calculating the appropriate credit limit or policy for a specific customer in real time, based on a 360 degree picture of the customer and his recent behaviour.
Short-term SOA opportunity?
3. Integrated BI
- BI activities are coordinated with one another, and synchronized with business and operations.
- Faster and more effective business response to external change
- Greater consistency and coordination of planning effort across the enterprise.
Medium-term SOA opportunity?
4. Collaborative BI
- Orchestrate BI services across a federated management or governance structure.
- Collaboration between knowledge workers.
Longer-term SOA opportunity?
I'd like to develop this roadmap further, with the help of my readers. I should be most interested to hear from vendors and others. Who in your organization is doing this stuff? Please let me know about your products, projects and future plans.
Service Oriented Business Intelligence from Richard Veryard
Articles:
Web Services to Improve Business Intelligence (CBDI Journal, June 2003)
Service-Oriented Business Intelligence (CBDI Journal, October 2005)
Related posts:
From Business Intelligence to Organizational Intelligence (May 2009)
From Networked BI to Collaborative BI (April 2016)
Articles:
Web Services to Improve Business Intelligence (CBDI Journal, June 2003)
Service-Oriented Business Intelligence (CBDI Journal, October 2005)
Related posts:
From Business Intelligence to Organizational Intelligence (May 2009)
From Networked BI to Collaborative BI (April 2016)
Friday, September 02, 2005
Business Intelligence Requirements
One of the problems of Business Intelligence (BI) is that you cannot define static information needs for advanced BI requirements such as data mining. Instead, you typically need to produce an entire class of enquiries ranging over all possible variables that might affect business performance.
For example, in manufacturing there are large numbers of people doing statistical process control, trying to manage derived business objects such as Process Variation, trying to identify, measure and eliminate causes of process variation. For each possible variable, or combination of variables, we may want to generate specific monitoring/measuring processes, as well as specific corrective/preventative actions.
If you want to achieve economies of scale in data mining, one of the difficulties is that you have to find systematic ways of linking different levels of abstraction within a single enquiry. For example: "which context variables are statistically correlated with these customer behaviours?" - where the object CONTEXT VARIABLE appears to belong to the metamodel rather than the model. Obviously there are ways of collapsing meta-level into the model itself, but these are fraught with danger for the logically naive: resulting in extremely clumsy class diagrams, and in error-prone or grossly inefficient implementations.
I am currently investigating something like a software factory / DSL approach to deal with the dynamic nature of emerging information needs. I'm hoping to find a safe (or at least safer) way to express specific data mining enquiries (e.g. for manufacturing or statistical process control) - reducing the potential for logical error and inefficiency, and increasing the potential for churning them out quickly.
If you have relevant ideas or experience, please contact me.
Post previously called Service-Oriented Business Intelligence, which didn't reflect the content. Name of post changed 3 April 2016
For example, in manufacturing there are large numbers of people doing statistical process control, trying to manage derived business objects such as Process Variation, trying to identify, measure and eliminate causes of process variation. For each possible variable, or combination of variables, we may want to generate specific monitoring/measuring processes, as well as specific corrective/preventative actions.
If you want to achieve economies of scale in data mining, one of the difficulties is that you have to find systematic ways of linking different levels of abstraction within a single enquiry. For example: "which context variables are statistically correlated with these customer behaviours?" - where the object CONTEXT VARIABLE appears to belong to the metamodel rather than the model. Obviously there are ways of collapsing meta-level into the model itself, but these are fraught with danger for the logically naive: resulting in extremely clumsy class diagrams, and in error-prone or grossly inefficient implementations.
I am currently investigating something like a software factory / DSL approach to deal with the dynamic nature of emerging information needs. I'm hoping to find a safe (or at least safer) way to express specific data mining enquiries (e.g. for manufacturing or statistical process control) - reducing the potential for logical error and inefficiency, and increasing the potential for churning them out quickly.
If you have relevant ideas or experience, please contact me.
Post previously called Service-Oriented Business Intelligence, which didn't reflect the content. Name of post changed 3 April 2016
Subscribe to:
Posts (Atom)