jueves, 28 de mayo de 2009

Enterprise 2.0 Isn’t a Checklist

by Paula Thornton
May 27, 2009 at 1:46 pm

When speaking at national Data Warehousing conferences years ago I was surprised by two clear patterns:
  1. Each year, over 50% of the people in attendance were new to the field and often were there because they’d ‘inherited’ responsibility for a data warehousing initiative, but knew nothing about the industry or the practices.
  2. Because of #1, the majority of the attendees were under tremendous pressure to perform. They were looking for recipes — checklists that they could take home and just start working on.
This appears to be indicative of all emerging disciplines/practices. But for Enterprise 2.0, unlike Data Warehousing, the predominant focus is NOT technology. And yet, from where does the funding or focus from such initiatives typically come? This is a much larger issue — one related to obsolete organizational design practices. The reason IT is the most obvious choice for sponsorship is that it is the only organization not vertically challenged — it delivers (or should) only horizontal services to an enterprise — crossing all other departments. Indeed, IT is one of the few organizations that takes on the battle to find common threads across organizations to weave the horizontal lines of the tapestry that holds the business together.

And yet, the approaches needed for E2.0 initiatives are the antithesis of typical IT practices.

1. There are no rules; there are no requirements
An optimal E2.0 initiative evolves organically (hold that thought for further clarification). E2.0 initiatives are the canary for Business 2.0 — if they die, the business will as well (either absorbed by the larger market or re-emerging anew after an identity meltdown).

2. The goal is not Binary Code
This is the realm for Design Thinking, not Analytical Thinking (previously noted: end of piece). As Roger Martin alludes to in The Design of Business (starting pg 6) this is an era to shift away from the locked down binary code of repeatability (optimal for machinery) and become more comfortable with the ’squishy’ realm of the heuristic (optimal for capitalizing on human wetware). It doesn’t mean that we abandon the right side of the continuum — mystery…heuristic…algorithm…binary code — but that we shift to the left.

3. Controls are Nooses of Death
This is the realm of ‘middles’: neither chaos or order, but a powerful, constantly changing space called complexity (think practice of ’science’ not ‘lots of pieces’). IT is still focused on increasing controls to improve results — increasing compliance, embracing defined practices of Project Management, etc. If you’re building a spaceship and lives are at stake, these practices are a must. If you’re running a company in today’s turbulent marketplace, everything that is locked down and fixed prevents the real human capital of the organization from adapting to constantly changing circumstances. There is never an ideal process or system and there will always be exceptions. IT cannot respond fast enough to these changes. That means the flexibility has to be built into the systems. This is not to suggest that controls are abandoned — it simply means that all of the existing controls have to be questioned and likely changed for greater human oversight throughout the organization (managed via a distributed social governance model, not a hierarchy).

4. It’s not about a Blog or a Wiki
A true sign of a E2.0 initiative destined for failure is one that focuses on the technologies. Certainly there are a variety of technologies that enhance and help to enable E2.0, but even as technologies, they are absolutely ineffective when implemented with a typical IT approach: install them. Blogs, Wikis, Mashups, and other Social Computing mechanisms are elements of a flexible infrastructure. As a solution they have to be architected. This will prove problematic for most IT groups for the same reason that SOA has failed — IT hires ‘drafters’ not ‘architects’. In company after company, the majority of people I’ve met who hold ‘architect’ titles know nothing about real design: they can draft solutions, but not architect them (the problem starts with the job descriptions — check out some postings).

So what IS Enterprise 2.0 focused on? People: tapping the human potential, helping to change the way business gets done by optimizing it not to the systems but to the people. Not shaping the people (via training and documentation) to the systems and the business, but changing the systems and the business to optimize the potential of the people.

Enterprise 2.0 is a mindset, framed by the orders of nature: enabling endless possibilities, organizing simple things in simple ways.

Enterprise 2.0 is about facilitating orderly chaos:
  • Minimizing Structure, Optimizing Connections
  • Tapping Existing Kinetic Energy
  • Celebrating Flaw-Finding and Fixing
  • Supporting Rapid Change

How do you get there?
  • Truly Utilize Resources: It’s not a destination — it’s a journey. You’re already on the path: embrace where you stand. First assess whether or not existing resources have access to one another: the people element. Finding people has to be the first priority. Determine the typical scenarios for problem solving and recognize that departments or hierarchies do not hold the answers to business problems/issues: people do. Warning: classic ‘expertise locator’ technologies will likely not be the right answer here.
  • Shorten Distances: Simplify all aspects of ‘doing’ business. Repeatedly ask: What can we stop doing? Leverage what’s working (from the perspective of all individuals impacted, not just those with ‘management’ responsibility to execute) — bypass the rest. From an IT perspective, being successful here the concept of software as we know it goes away. The desktop becomes a collection of functions that can be assembled into sequential processes, but are not locked into place. Existing applications can be tapped, bypassing inefficient UIs and raising the most relevant activities and functions to the ‘top’ (omnipresence). Even two years ago Dion Hinchcliffe introduced the concept of situational software.
  • Embrace Organic: Organic is not chaotic. A palm frond is distinct from a maple leaf. Nature has order, but that order is under rapid cycles of repeated construction and destruction. The question becomes one of determining what structure is necessary to support a specific, unique pattern (purpose), yet does not prevent the ability to adapt to constantly changing conditions — not only to survive, but flourish.
  • Shift Focus: Particularly for IT, the focus shifts from code (developers) to UI (designers). Coders are trained to make things binary; good designers are comfortable with the ’squishiness’ of heuristics. That doesn’t mean developers go away; it means that there should be a 1-to1 ratio of developers and designers. They’re two totally different kinds of mindsets — and while there are unique individuals who can do both, it’s rare that 1) you can find them or 2) you know what to look for and adequately assess. Besides, there’s an important phase of working through the natural ‘dissonance’ that will occur between these two mindsets. This can be lost when resolved in the mind of a single person (or it will just increase work-induced-schizophrenia, ala. stress). The fallacy of paired programming is not in the number, but in the resources and their focus. Pairs should be made up of two different perspectives.
  • Shift Thinking: Design Thinking requires a different approach: it focuses on trying out multiple possibilities (fail fast) to test an algoritm — a problem statement. Don’t think problem=flaw, but problem=mathematical equation. Different algorithms solve different problems. Many solutions fail because they either 1) started with the wrong question (the solution is the answer to the question) or 2) did not adapt to change the question (the problem statement) as more was learned along the way. Our current definition and funding of projects is a key contributor to this fatal flaw.
  • Shift Culture: A company that has been optimized for ‘machine’ design (command and control), will have a culture that reinforces such behaviors. Such a culture will undermine E2.0 potential. It will seek to eliminate the efforts as a ‘foreign body’. A different culture is not a prerequisite, it’s a corequisite. It should evolve as enabled by the other changes. Such cultures have to move from ‘rules’ to ‘guidelines’; from ‘fixed processes’ to ‘governance models’; from binary to heuristic (obvious exceptions will be for those industries and/or business artifacts subject to legislation).
A primary challenge is that we’re so used to operating in ‘binary’ that we attempt to turn everything into linear processes. This is not a linear solution space (in reality, neither is business — we’ve only artificially forced it to be so). Most of these things are codependent — they rely on small changes from the other dimensions to accommodate their own change. This is ‘informed change’ not ‘command and control change’. How is this possible? Social computing — facilitating conversations and exchange of business artifacts that are: transparent, persistent and accessible.

Now we can start the technology discussion…

http://www.fastforwardblog.com/2009/05/27/enterprise-20-isnt-a-checklist/

No hay comentarios:

Publicar un comentario

por favor, goza de tu libertad y de la nuestra ...