Showing posts with label dashboard. Show all posts
Showing posts with label dashboard. Show all posts

Wednesday, January 23, 2013

Does Cameron's Dashboard App Improve the OrgIntelligence of Government?

In November 2012, it was announced that a mobile app to aid in decision-making and day-to-day government affairs was being trialled by the prime minister.



Here are some quick comments from Twitter

@lesteph PM's dashboard is at best pointless, at worst dangerous, unless his briefing system has fundamentally collapsed

@dominiccampbell he may as well have it, but pretending it's anything other than a partial view and mostly for PR is daft

@willperrin rather an antediluvian counsel of despair there then. back to 'ringbinders full of..' briefing

@6loss The "dashboard vs intelligence" debate? IMHO dashboards are useless without fast feedback on action.

In a subsequent discussion on Linked-In, @6loss and I discussed some of the intriguing questions raised by this news story.

Firstly, we were missing the imperative for real-time action and feedback. Obviously the Prime Minister needs to know whether job vacancies are going up or down, but the idea of real-time update is just ridiculous. Suppose that seventeen new job vacancies have been posted in Smartchester in the past twenty minutes, Are we supposed to believe that these seventeen vacancies urgently need to be communicated to the PM so that he can take appropriate action?

What does make sense is a dashboard that supports an OODA loop. A well-designed dashboard should not only provide aggregated data, but also provide some way of making sense of the data. (It is possible that the data visualization may help here.) And then taking rapid action.

But in a well-designed organization, the responsibility for rapid action is delegated to the people in the front line, who are given the real-time intelligence and the resources/tools and the authority to solve problems effectively and efficiently. This is what the military call "Power to the Edge". A completely different order of intelligence is required at the centre, usually operating at a much slower tempo.

And since managers are often tempted to meddle with randomly varying processes (Deming called this "tampering"), a well-designed control system deliberately hides much of the volatility from senior management. (In cybernetics, this is called "attenuation".)

Secondly, I'm wondering what kind of statistics we are talking about here. When people talk about "statistics", they often mean the kind of statistics kids learn in primary school (totals and averages) rather than the kind of statistics kids learn in high school (correlation and significance). I wonder how many ministers could cope with high school statistics (let alone degree level) without a civil servant or adviser there to explain it to them? The danger of the "dashboard" is that it may eliminate the vital step of interpretation and sense-making, which is surely essential to evidence-based management. 

Thirdly, I'm wondering about the planned rollout of this App. Are we to suppose that all ministers and senior civil servants are going to be watching the same set of indicators, or does collective responsibility entail that each minister is watching a different set of indicators? In a typical control room, there are many people each watching a different dashboard or controlling a different sector: it would seem a bit redundant if they were all watching the same one. Meanwhile, the supervisor sits in his cubicle playing Angry Birds, or sending texts to his neighbours.

A few weeks after this discussion, writing in the New York Times, Will Wiles compared this dashboard with the Viable Systems Model implementation in Chile under Salvador Allende. He pointed out that the dashboard is not truly cybernetic because it lacks a mechanism to translate all that data into action. Quite so.

Will Wiles, Before Fruit Ninja, Cybernetics (New York Times, 30 November 2012)

 

Update: See also Shannon Mattern, Mission Control: A History of the Urban Dashboard (Places Journal, March 2015)

Monday, November 22, 2010

Embedding Intelligence into the Business Process 2

#orgintelligence #entarch In my previous post, I talked about two aspects of Embedding Intelligence into the Business Process.
  • Embedding business intelligence (BI) into the business process.
  • Embedding Enterprise 2.0 into the business process. 

In this post, I'm going to talk about two further aspects of this.

  • Embedding knowledge (content) into the business process.
  • Embedding learning into the business process.


Embedded Knowledge Content

There are various levels at which knowledge can be embedded in a business process. Some forms of procedural knowledge can be encapsulated as static rules, which can be either written into the process (as software or bureaucratic procedure) or stored in a form that can be easily and automatically referenced by software components or knowledge workers. There is a considerable software literature on so-called business rules - see for example my review of Business Rule Concepts.

More complex forms of knowledge can be represented as models. For example, the business processes associated with operating a complex industrial process or communications network require some representation of the physical structure and processes involved, while business processes in the finance world may use economic models that help to predict market trends and risks. These models may be buried within complicated algorithms, or represented visually in dashboards and control room displays. See my post on OrgIntelligence in the Control Room.

Thirdly there is contextual knowledge - an appreciation of the specific circumstances and general trends relevant to a business decision or action. This kind of knowledge is dynamic and typically requires human mediation and interpretation, although it may be possible to codify and even automate some limited kinds of contextual knowledge. When discussing the contribution of Enterprise 2.0 to the American security services, Dennis Howlett comments that "content without context in process is meaningless". (See my post on Connecting the Dots).

In her post on The Future of HRM Software, Naomi Bloom talks about embedded intelligence that integrates the rule-based and the contextual knowledge into a software agent she calls "Naomi". She claims that embedded intelligence can achieve several things.

  • It "replaces what we lost" when we reduced or eliminated the interaction between experts and the rest of the organization. (In her piece, the experts are HR professionals.)
  • It improves upon human embedded intelligence by removing human error. 
  • Automated embedded intelligence improves compliance to rules/policies/regulations and reduces the organization’s exposure to risk.
  • Commercial Web sites (Landsend.com, Amazon.com) and social Web sites (Wikipedia) set expectations of the embedded intelligence to be found in any self service environment. 
In my post Intelligent Knowledge Management, I pointed out the important step from collaborating-in-the-work (for example shared responsibility for decisions) and collaborating-in-the-knowledge (for example, shared responsibility for collecting and interpreting intelligence, connecting the dots). I also advocated a shift of emphasis from knowledge sharing to knowledge embedding - grounding the work in the best available and critically evaluated knowledge, as well as actively seeking well-grounded knowledge to support organizational learning.

One of the ways that enterprise architects can think strategically about business capabilities and business processes is in terms of knowledge intensity - in other words, the quantity and quality of knowledge required in a given capability or process to differentiate the enterprise from its competitors. The "core" activities of an enterprise are those requiring high levels of knowledge intensity and specificity, other activities can be regarded as "peripheral" and may be commoditized or outsourced.  See my post on Ecosystem SOA, which draws on the work of Amin and Cohendet.


Embedded Learning

In my post on Learning by Doing, I pointed out that such characteristics as adaptability, agility, flexibility, responsiveness (supposed to be the benefits of various technologies including SOA) imply processes of adaptation and learning. So we need to ask: How do business systems (both organizational and technical) improve? Where is the learning located? What is the nature of the feedback loop?
  1. The learning loop goes through the software developers. (The software development acts as a gate/brake on the learning process.)
  2. A learning process is contained in the software or service. (Learning can take place in real-time, but only for things that have been explicitly anticipated in software development.)
  3. The learning process is distributed across the community usage of the software or service.
In planning for organizational intelligence, we need to think about these learning processes, and how they may be accommodated in any sociotechnical system architecture. Advanced software (from SOA to Enterprise 2.0) gives us new and more flexible ways of implementing such learning processes, but only if we identify the learning requirements properly. We are going to need a business model that includes the learning capabilities as well as the operational capabilities, and an architecture that mobilizes these capabilities in a loosely coupled manner.



Places are still available for my Organizational Intelligence Workshop on December 8th.

Thursday, September 16, 2010

From water cooler to Web 2.0

On a Linked-In group discussion about organizational intelligence (CBDI Forum), Rob Mocking mentioned the water cooler, which prompted some questions and comments from Richard Gilyead and Ian Macdonald. I'm going to post an edited and expanded version of the discussion here.


Rob expressed some scepticism about formal systems for organizational intelligence, and speculated that the water-cooler might be the most important tool for knowledge management. But obviously a literal water cooler can only support a small number of people at a single location. So what is the internet or intranet equivalent, and what are the organizational and cultural requirements for making a metaphorical water cooler work as effectively as a real one?

As Richard asked

Does this virtual model make the "water cooler effect" a myth since the organisation itself may be small but its partners may be dispersed? Is the "water cooler" actually a personal network that spans organisations? What effect does Web 2.0 have on this (like LinkedIn!)?

Let's start by understanding the value of the "water cooler" to the enterprise. The first point is that people don't just rely on formal information systems and dashboards to know what is going on, they also use a range of informal communication mechanisms including casual and serendipitous chit-chat, as well as Management-By-Walking-Around (MBWA). Some of these mechanisms can be replicated or extended by Web 2.0; in any case, the water cooler merely stands in for anywhere (real or virtual) where these exchanges can take place.

Many IT architects concentrate on building and integrating formal systems (although this task is perhaps increasingly delegated to ERP or SaaS vendors and similar) but organizational intelligence raises the question about the relationship between formal systems and informal systems.

But although Web 2.0 may enable all kinds of communication and sharing that weren't possible before, both inside and outside the organization boundaries, I don't see technology as the efficient cause of change, but merely providing support for change in the organization itself and its processes and capabilities.

Richard made an important observation about strong inward-looking implications of the water cooler. Interestingly, the water cooler metaphor echoes a much older idea of the village pump being the locus of social interaction. (Several Bible stories take place near a well.)

Richard also notes that senior executives tend to rely more on traditional personal networks than on Web 2.0. Of course there are some obvious limitations with Web 2.0, at least as currently available. I posted a fictional example of the Old Boy Network on my blog (Social Networking as Reuse) and suggested it might take a while before Linked-In and Facebook can replicate the kind of affordance offered by more traditional methods.

Ian averred that in 30 years of consulting he never came across an organization where people gathered around a water cooler, and asked if it really happened?
The village pump is more likely, assuming an age where time passes more slowly, but sadly grabbing a coffee and taking it back to your desk is more likely. Of course the village pump was also a major transmitter of disease as untreated sewage would have been piled in middens just yards away and polluted the water source - just as the water cooler/coffee machine can be a source for the rapid spread of baseless rumours.
The main problem we seem to have with the traditional methods of networking is that they are not scaleable or interoperable. Each executive has his/her own personal network of friends and information sources, but that typically results in intelligence silos and thus may not be enough in the face of really large and complex problems.

The main problem we seem to have with Internet-based methods is that they are ungrounded. Poor quality information (rumour) has always existed, but now it can be disseminated globally with a single well-timed Tweet. A great deal of Internet discussion lacks rigour, relevance or respect, and is sometimes quite incomprehensible.

The Internet may therefore simultaneously amplify both intelligence and stupidity, is a constant battleground between them. This is now a large part of the environment in which organizational intelligence must operate.

Friday, June 18, 2010

Device-Driven Business IT Alignment?

@LTucci suggests Using the sex appeal of the iPad to push BI reporting in the C-suite (Total CIO, June 2010). @rtolido glosses this as "looking for better business-IT alignment? Get your CEO an iPad".

Linda Tucci talks about "democratizing business intelligence software" and announces that "users can become masters of their own dashboards!" Although giving more power to CEOs is a curious kind of democratization, I can see that allowing CEOs to become masters of their own dashboards could be interpreted as a move toward some kind of business-IT alignment.

But I hope the reference to the iPad is intended to be satirical, because believing that the CEO would be seduced by some device, thus magically achieving business-IT alignment, would not only show fair contempt for the CEO but also trivialize the notion of alignment. This belief appears to be an extreme form of technology fetishism, christened the device paradigm by the philosopher of technology Albert Borgmann.

For a similar kind of satire, see Newsbiscuit's proposal to give the UK Deputy Prime Minister a toy plastic steering wheel.

he can make all the noises, too

Tuesday, October 26, 2004

Web Services Dashboard

IBM is currently launching web service management tools into the WebSphere/Tivoli space, including a web services dashboard. This now appears as two slightly different products: IBM Web Services Navigator and IBM Tivoli Monitoring for Web Services.

The web services dashboard is designed to support the "Services Architect". This is a new role, acting as broker between development and operations. IBM estimates that 70% of services architects will have a development background and 30% will have an operations background. 

The web services dashboard displays the interaction patterns of web services, and these can be tracked against predefined profiles. A service profile is a recognised pattern of service interactions (an orchestration scenario). A service profile distribution is a statistical pattern indicating the occurrence of service profiles. (For example, this might allow the system to generate an alert if a given exception condition is executed for more than x% of cases. More generally, it supports Statistical Process Control.) Deviation from accepted service profiles or profile distributions may generate an alert, demanding someone's attention. Alternatively, the alert may be passed as a signal to the web service platform, where it triggers some autonomic response. 

A major issue for any tool of this kind is scalability. A screenful of information may be good enough for a small demonstration, but how does the tool cope with larger and more complex situations, when the information would spill over many screens? 

This is precisely why you need an architect, who can break the information down into manageable chunks. In a separate post on Web Service Management, I discuss the role of the service architect, and the web services management process.