C. Dwight Alworth provided an excellent example of how best processes (i.e.,
patterns are used by BP Exploration to enhance organizational learning and
promote continuous improvement . . .
Dwight Alworth wrote:
> ...snip...
> The results are that the teams using the tools improve their performance
> and have a documented trail of how, and more importantly why, the plans
> have changed from project to project; the learning is retained by the
> teams so that as new personnel come on board they get up to speed quicker;
> and other teams trying a new area most likely have a base from which to
> start based on similar operations somewhere else which was better than
> starting with nothing.
>
> ...snip...
> C. Dwight Alworth
> Dwight Alworth <dalworth@compuserve.com>
Let me take a step back and push patterns around the organization a
little.
Patterns help an organization understand and manage its context in an
environment of competitors, cooperators and partners. These would be
organizational and reengineering patterns -- those patterns used to
structure our 'being'.
Patterns help information technology teams understand and manage its
context in an environment of software engineering. These would be
development and software patterns -- those patterns used to structure our
application development and architectures.
Patterns help operational units understand and manage its context in an
environment of the client or customer. These would be specific
service-oriented patterns -- those patterns used to structure our
behaviours and image towards our customer.
To summarize, given our current environment (or domain), patterns will
define how we best 'fit'. We know this 'fit' evolves constantly. How do
we manage that? Through patterns of change management.
>From my experiences and research in this area, pattern development in just
beginning to emerge. After all, managing knowledge is difficult enough,
let alone managing the volatility of that knowledge over time.
Please let me put forth a few thoughts.
Because patterns are linked across internal domains (e.g., organizational
patterns will intersect with service-oriented patterns, etc.), change
management must be 'institutionalized' to provide a seamless management
framework from the time change is identified or anticipated (as affecting
us) to the implementation of the operational solutions.
The bureaucratic, hierarchical organizations of yesterday(?) provided a
framework for change through multiple reporting levels of management.
This provided a 'processor' through which change would have to flow before
it reached its operational solution. As we know, this tall organizational
structure did more damage (generally) than good for the organization, so
we collapsed all the management layers and flattened our reporting
structures. Teamwork, empowerment, all that good stuff. But while we
gained cross-functional efficiency, we lost our 'processors'.
So what happens now? In my experiences in the trenches change attacks
teams and forces them to react. Teams react and affect other teams. We
end up with an endless loop of team suboptimization, a 'downstream
effect'.
So how do we solve this? Change Management patterns? Communication
patterns? Team patterns? Has anyone put an integrated system or
framework of managing change in place?
Thanks for listening,
Nigel Vickers
Analysis by design, Inc.
thenige@interlog.com
--Nigel Vickers <thenige@interlog.com>
Learning-org -- Hosted by Rick Karash <rkarash@karash.com> Public Dialog on Learning Organizations -- <http://www.learning-org.com>