« April 2005 | Main | June 2005 »
May 31, 2005
The Business Logic of IT Services
Business reliance on enablement through IT has evolved into a necessity for IT strategy to become a design element of business strategy.
Seen as a critical success factor, IT enablement describes the basic underlying assumption of the business's execution of strategy. That is, overwhelmingly due to IT, operational fundamentals such as communication, analysis, and processing are meaningful and viable in the face of change, costs, speed and regulation.
However, the relationship of IT to business is not one of simple cause-and effect.
Intuitively, we link motivation to importance (i.e, what is valuable) and we link automation to opportunity, which goes a long way towards clarifying the main difference between business strategy and IT strategy. But they must be reconciled.
Reconciling the strategies means to develop assurance that alignment is established between the type of opportunity generated and the type of value pursued. In alignment, "opportunity" represents satisfaction of certain pre-requisites for subsequent gain, and "value" controls the prioritization of possible effects leveraged from the opportunity. In alignment, prerequisites-for-priorities, rather than cause-and-effect, is the key relationship.
Practical institution of alignment is an ongoing management function. Business organizations and technology systems are both developed with the idea of their being functionally reliable, but their respective functions reflect significantly different design dynamics that easily diverge or lack synchronicity. Functionality in technology systems is increasingly focused through automation, while the functionality of a business organization is increasingly focused through motivation.
The successful business operation is one in which the negotiation between organizational motivation and systems automation is successful.
Typically, where motivation is the business basis of effectiveness, and automation is the business basis of availability, their combination generates the execution capacity of the business. To manage that execution capacity, the alignment negotiation must internally balance motivation against change, costs, speed and regulation -- and do the same for automation -- and then balance the two against each other.
Customers experience that execution capacity as the "availability" of the entire business, through the business response to specific customer demands. In effect, to the customer competitively evaluating things, the business behavior represents what the business "wants to do". The question is whether that perception is favorable or not.
For managers who want sustained execution at a level that creates advantage from the customer's evaluation, it means creating descriptions of business availability that literally make sense in terms of organizational motivation. For example, does the business want to do follow-the-sun customer support? If so, why?
Regarding IT, the description should highlight IT's enabler role in the business. In the business view, "value" describes the importance of something. The objective of IT meanwhile is to create or enlarge opportunity for the organization to pursue selected value.
Approaching the bottom line
IT can be pretty successful in its role, however, the business must still actually use the opportunity to get anything out of it. In fact, when assessing the "value" and "return on investment" of IT's role, the difference between them is that while business value describes the importance of IT's role, ROI actually describes the business opportunity IT creates, more than it does the business result. The business ROI of IT's role can correlate with business value but it does not cause it.
In aligning opportunity and value, the primary agents are processes and policies which act as mediators. Most simply, processes coordinate goal-oriented activities, and policies likewise coordinate decisions.
Pragmatically linking IT strategy and Business strategy
As a mediating agent, the design of a process or policy ideally navigates or corrects the various functional strengths, weaknesses, opportunities and threats (SWOT) characterizing the technology systems and likewise the business organization.
Processes and policies often want to perfect their respective SWOT solutions separately, and/or to target either the systems or the organization but not both. The danger in this is that disparities between events and accountability will usually develop, sometimes with extremely counterproductive impact.
Therefore, for aligning the business-IT relationship, the most critical aspect is the correspondence created between processes and policies. To generate and sustain maximum business capacity, they must ensure that they way they shape operations is complementary to each other, collaboratively managing responsiveness within accepted tolerances. (Typically, this is where businesses are advised to specifically model the interactions of people, process and technology -- and where now a pronounced emphasis on performance management and governance has emerged.)
Whether the issue is the systems or the organization, Directors and Managers in the business live with the additional responsibility of continuously tuning the SWOT solutions to minimize constraints which especially provoke future risk, opportunity cost, and malfeasance.
This strategically important adjustment occurs as the outcome of dialog that discusses the business model. Because the form and/or the "metabolism" of the business model adjusts over time to its market environment, the dialog is ongoing or recurring, and changes to the constraints are iterative.
Thereafter, the collection of constraints allowed in the systems and in the organization represents the business' operational tolerances, which typically are documented or institutionalized in the form of practices (adopted) and agreements (contracted).
"Services" operationalize these practices and agreements by defining the way that planned availability (or "IT supply") is finally allocated and requested against planned effectiveness (or "business demand"). The definition provides a common "interface" for business and IT to manage execution capacity through a lifecycle of needs, orders, fulfillment, replenishment and improvement.
Posted by Malcolm Ryder at 8:09 PM | Comments (0) | TrackBack
May 29, 2005
Managing knowledge about Knowledge Management
Discussion about Knowledge Management still seems all too often to avoid something that is a fact of life for most organizations. That is, the practice (utilization) of knowledge development and the distribution of usable knowledge are two very different but related things. The popular phrase "knowledge transfer" bestows a mystical virtue on what is invariably a practical matter constrained by costs and politics. And here I definitely include both "political capital" and the politics of budgeting as key factors. Effective knowledge utilization requires motivation, selection, usability and quality management -- and these things are never givens in a complex organization dealing with profitability pressures and change.
A discussion of proper scope should call out these factors explicitly, and examine how they help or hinder each other, rather than focusing on one or two issues that may excite certain roles in the organization but benignly neglect other roles that will be on the critical path to KM success.
Posted by Malcolm Ryder at 8:22 PM | Comments (0) | TrackBack
May 26, 2005
Business Process Management and Organizational Architecture: a performance ecology
This month, Gartner Group research chief Peter Sondergaard outlined the top emerging issues in Business-IT management, by identifying the already driving needs to:
"...foster greater business agility, to promote quick build-up and tear-down of business partnerships, to facilitate adjustment and deployment of resources where needed and to render harmless approaching danger well in advance of that danger's arrival," Sondergaard said.
We're accustomed already to the idea that processes must be readily modifiable to keep up with changes and risks. But a closer study of Sondergaard's statements yields two other survival requirements:
(1) repositioning and security capabilities: this will require a mature "sense-and-response" ability that exploits forecasting.
(2) re-organization capabilities: this will require a mature ability to "re-compose" the organization by exploiting a model of it components.
In a nutshell, a form of organizational architecture must drive suitable types of readiness.
Meanwhile, business processes will remain the delivery vehicle for the operational impact that creates business value. To users of a process, the process is virtually the organization... But forecasting and organizational modeling determine whether the business process executes effectively -- that is, in the right direction and at the right strength.
Said differently, processes execute with critical "ecological" dependencies on their environment.
This dependency can be described from two viewpoints. In one, any process is essentially a "behavior" of the organization that enacts it. In the other, the process is a "user" of the organization that hosts it. Either way, to modify a process and obtain effectiveness, the organization that enables the process must successfully adapt as well. The issue is to determine the nature of the necessary adaptation. Is it repositioning, reorganization, training/maturation, or a blend?
The more frequently or continuously processes must be changed to meet requirements, the more explicit it is that the logical purpose of a process is to "map" the current requirements to the current functional capacity of the organization. In this view, "successfully" adapting a process to changing requirements means that changes of the underlying organizational structure must keep up with or even precede changes of the process. (The lessons we have already learned about mapping requirements to organizations come from project management and product management, where the organizations are often shaped and managed specifically to conform to fulfillment of the new requirements.)
Here, it is important to see organizational "structure" as a configuration of functional capacity. The purpose of the organizational structure is to deliver the capacity, and the purpose of the process is to leverage the capacity.
Usually, the chosen configuration will be selected according to criteria of cost, risk, availability, scale, stability and durability. But those attributes really describe outcomes of the organization-in-use, as enabled by the interactions of its elements. To recombine the elements and predictably obtain the same (or acceptable) attributes, the elements must be identified in terms of the properties they are known to exhibit in interactions.
In powering business agility, forecasting and modeling are both going to be based on those interactive properties of the elements, which comprise the business' operating environment.
Organizational building blocks
The type of understanding that will exploit elements defined this way is akin to both chemistry and meteorology.
Chemistry is an especially compelling metaphor: we already recognize that preparing a chemical "reaction" is precisely how we proactively develop the solution impact that we seek. It emphasizes that the structure (i.e., the chemical composition, the "organization") hosting the reaction is the driver of the reaction, containing within itself the potential and also sometimes the catalyst. Accordingly, the prescriptions that are developed by a chemist reference what is known about the interactions of the chemical elements, to compose the offering. Similarly, we are entering an era that calls for organizational composers, working with or without automated help...
Meteorology is also a compelling metaphor because of its constant analysis of the environmental dynamics. Meteorological analysis accomplishes tasks by means such as distinguishing weather "elements" from weather "factors", by determining what underlying elements are interacting, and tracking how they are interacting when certain dynamics occur. The interactions of elements are factors; factors combine to produce dynamics; and systems of dynamics produce the common high-level weather structures.
Abstracting the components of an environment or state such as the weather, we might identify:
- Structure: a seasonal climate
- Dynamics: a rainstorm, tornado, wind current, etc.
- Factors: a high-pressure system, cold front, etc.
- Elements: air, water, heat, etc.
Although we still can't control the weather based on what we know about it, we understand much about the near future weather because this analytic discipline helps us to model it and forecast it in advance.
Decomposing a business's internal organization this way, the business can then plan for the organization's states or behavior just as we might plan for the weather's, and exploit reorganization. Likewise, decomposing the external environment of the business helps with making decisions about where and when we can best "locate" ourselves to accomplish what we need or want, repositioning as needed.
Process architecture
Linking elements to factors to dynamics to structures is an abstract design technique. It can produce architectural models that are:
- the prescriptive composition of the business organization; this addresses the need for a re-organization capability
- the projected state of a business environment; this supports a repositioning capability.
Here is a diagram about composing an organization:
The picture gives an example of the many-to-many relationships that build up an organization, from assets to resources and so on.
In effect, a running business process issues requests that must intelligently "invoke" a certain configuration of these relationships during run-time.
The "intelligence" includes rules, permissions, and qualifications of various kinds. At run-time, if new items have entered the picture or earlier ones have changed or left, some of these rules, permissions and qualifications might need to be discovered on the fly, to assess and accomodate the differences from expectations.
The same approach can describe external environments as well as internal organizations; for example, a market space might be decomposed into:
- (structure) channels and partnerships
- (dynamics) campaigns and contracts
- (factors) products and services
- (elements) features and property
This market decomposition would exhibit the same many-to-many relationships of one tier's items to the next tier, whether going up the hierarchy or down.
Process-driven architecture
Leveraging that architecture, a business process requests a real-time configuration of an organization. The process always anticipates the potential for effectively exploiting the organization to meet the expected current or future state. But that anticipation is not always satisfied.
As business process management(BPM) increasingly centers itself around a business analyst role (performed by a manager or other employee) and expands that role across functions, it also extends itself into a request-management function that wants to ensure the satisfaction of the request with available and approved resources.
The key challenge in the request management effort is to determine whether the request can be satisfied through an existing organization or must be through a "reorganization" that makes acceptable resources available. The challenge for the analyst is to get the process to make the optimal number and type of requests in the available environments.
If a reorganization is suggested, it is likely not permitted until the request has been assigned a priority that effectively authorizes the reorganization for the request. (This prioritization typically comes from strategy and performance management.)
In this scenario, "orchestrating" resources brings selected factors into play, enabling the dynamics that a process attempts to manage. The orchestration is the virtual real-time organization. In effect, the organization becomes a resource agent for the process. And that orchestration comes with scale and scope issues that must be assessed for their implications in cost, risk, stability, duration, etc.
Which came first: the chicken or the egg?
BPM is evolving (expanding)into a complex of practices within which the design of the process prescribes a solution for the delivery of business outputs, and that prescription requests a fulfillment through organizational functions.
In that way we can say that the targeted process catalyzes the organization. But at the same time, those prescriptions are speculative without knowledge of the organizational potentials, and speculation is a risk to business efficiency and effectiveness.
Necessarily, the attending organization may be a "just-in-time" organization derived through bidding, collaboration, or the standing availability of a qualified outfit (whether internal or external).
What's especially important to note is that the criteria for selecting or composing the organization should effectively function as architectural standards looking for compliance by the actual organization that winds up engaged with the process.
These ersatz standards must be validated against evidence of the business' tolerance for them. We can't always get what we ask for, and we have to be careful because we might get it!
Why "architectural"... ?
By demanding certain combinations of cost, scale, scope and duration, the criteria effectively specify what capacity can be expected from given organizational (structural)configurations. The business must agree to those expectations, or seek sufficient capacity through whatever means available. The issue is whether the specification is too constraining or not.
In that way we see that architecture is actually what is being exercized. Far better that this is understood from the start than to encounter it as a barrier. The challenge is to apply architectural discipline proactively, yet in a manner that is calculated to maximize the ability of processes to obtain the organization that they need on demand.
Posted by Malcolm Ryder at 9:25 AM | Comments (0) | TrackBack
May 25, 2005
Data, Dictionaries, and Organizational Performance Alignment
Engineering is often where we find crisp statements of problems and solution-approaches that are already pretty far along but may not have found their way to routine use in a more general population of managers.
An example of this is from a BMC Corporation technical whitepaper that stated the following: Nowadays each IT infrastructure component has its own language or dialect when communicating with the outside world. This makes it extremely difficult to derive and understand the impact certain events or combinations of events have on the business. BMC is, shall we say, very much "on the case" in creating a system for more uniform identification of components-in-deployment.
Not coincidentally, this same type of problem is cited quite explicitly by at least two other sources of tremendous import to performance management -- the Zachman Framework (for enterprise architecture) and the IT Infrastructure Library a.k.a. ITIL (for IT service management). Both Zachman and ITIL go on to provide a logical framework of how the semantics and syntax of an organization allow efficient and effective construction of complex functional products.
The online Wiktionary offers the following explanations:
Semantics - the science of the meaning of "words"...
Syntax - A set of rules that govern how "words" are combined to form "phrases" and "sentences" ...
These definitions literally look at communications as a construction process, with the quality of the output being at stake. But what Zachman, ITIL and other development aides take from that is a way of looking at construction as a communications process.
Why is this meaningful instead of just a handy twist of phrase?
Performance Legos
First, items like words, sentences, etc. all point to "information", which we use as a construction material in the business.
Second, when complex constructions require that "components" are developed and integrated to make higher-level "subsystems", then the functional compatibility of the components becomes the primary goal of managing their development and provision.
Altogether, that throws focus on how information itself is developed, and thus on how that information development effort is managed.
The objective of that management effort is to assure that the quality of the construction process minimizes the risk that its "product" will fail to meet its requirements. The development process must create components that support the construction process.
For business purposes, the management effort for information has at least two major issues:
- how does the information have meaning (semantics), and
- how are the meanings combined for practical use (syntax)?
What makes information usage practical?
First, "information" is itself a component of the business because it is used to create, for example, "processes" and/or "workflow" -- in other words, subsystems of the business.
Second, "business" information describes the characteristics of the business itself. Successful identification of a business entity, condition or characteristic is fundamental to the point of the info's usage.
Practically speaking, the information is usable only when the user understands the information's way of providing identification. The semantics always come first. The biggest challenge in transporting information across a progression of different users is the risk of the semantics being lost along the way. This is not a matter of "what" something means but instead a problem of "how" it comes to mean what it is supposed to mean.
Here, Wiktionary again is convenient. It offers the following:
Protocol - A rule which guides how an activity should be performed.
Context - the circumstances or settings which determine, specify, or clarify the meaning of an event.
Interestingly, this suggests that business terminology probably should be managed as a thesaurus, and that business information should primarily be managed as terms of requirements and agreement (i.e., specifications).
Construction quality as a performance factor
Communications protocol comes to the foreground as the mechanism by which the business constructs its understanding of where it is and how it is doing.
- Protocol represents the quality requirements issued to those activities that construct and convey meaning across the enterprise.
- The organization uses those meanings to determine and drive performance.
- The mechanism for utilization is the problem that the organization (and solution providers) must solve.
Decision support as an organizational constructor
Let's go back to the original issue at hand, which is to "derive and understand the impact certain events or combinations of events have on the business."
Decisions shouldn't be made without having that understanding in hand. But naturally, recognizing events must precede any determination of their impact.
Of course, decisions don't just make themselves. The organization makes decisions -- including the ones that change the organization. So we have two additional things to consider here.
First, from the vast universe of business data, what are the essential classes of information to derive -- for example, "entities", "events", "impacts", and so forth... And second, to what extent does our idea of "the organization" rely on demonstrated usage of this information instead of on prefabricated boundaries (silos) of data ownership and custodianship?
Does the organization define itself by the way it actually uses information, or instead by what it thinks it should "know"?
The emerging consensus is that what distinguishes high-performance businesses from lesser ones is their smarts in the midst of environmental change; but therefore, information usage must drive the business and the "organization" should conform to the necessity of making information useful. This spawns a couple of giant trends in organizational management: standardization of operating language and automation of decision support -- or put differently, vocabulary and analytics.
Together, the two trends do nothing less than attempt to reconstruct the organization.
The off-hand expectation would be that a standardized vocabulary should make analysis easier, since the terms in the analyses wuold be more efficiently validated and transmitted. For this, we would be looking for a new and improved "dictionary".
But organizations can certainly fail faster when they try to replace the need for communication with analysis. If they had to have one without the other, communication should win every time. And dictionaries don't make communication successful: protocol does.
In what follows, we'll go through the key points of this graphic:
The use and abuse of "universal vocabularies" and "analytics"
Let's use ITIL as a case where a better single dictionary, in fact a great one, is available and necessary -- but insufficient.
Many IT organizations are attempting to implement quality improvement initiatives aimed at their service management processes. Taking ITIL as a guide, standardization of vocabulary is a strategically critical dimension of their efforts. IT organization leaders realize, both instinctively and empirically, that the standardization will be disruptive to a significant degree, as adoption of the standards must run through the current configuration and linkage of most people and systems in the IT organization. The expectation, however, is that the resulting changed organization will be leaner, faster and more powerful as a services provider.
In a recent article, Pennsylvania consultant David Pultorak, president of Fox IT, provided the following citation:
Organizations implementing ITIL saw the following benefits:
according to a 2003 itSMF survey...
- Improved customer satisfaction
- Motivated staff and increased productivity
and according to a 2002 survey by DMR...
- More consistently implemented changes
- Reduced repetitive problems
- Reduced amount of time spent "firefighting"
- Produced more business-focused metrics
These outcomes are highly worthy goals. How were they reached?
ITIL's intended impact, on the capability to manage IT services to high levels of business value, is promoted primarily through improvement in management processes. That improvement is heavily predicated on the standardized vocabulary for identifying actions, conditions and events. With ITIL, one management process can more readily understand another management process, making their interactions more dependable and predictable.
But finally, a successful "ITIL implementation" requires (and means) that the organization has adapted itself to be a suitable and healthy host for the management processes and for their integration.
Success rates with ITIL implementations might always be measured in terms of goals such as above, but ITIL implementation failures are most often discussed in terms of being overwhelmed by the difficultes of adaptation. Organizational change management discplines emphasize that adaptation should be both strategic and evolutionary, so we assume that the "successful" implementations will actually exhibit accomplishments that are both strategic and phased.
Does this mean that in successful implementations, the vocabulary standardization was incomplete at various points along the way? If we look at ITIL consultants' frequent references to capability maturity models, the answer is evidently "it depends". If "process improvement" was intermittently verified, and IT organizational performance was also measured trending up, the real situation is that the terms of measurement allowed the evaluation outcome to be positive. This suggests that a certain amount of the process vocabulary was identified for inclusion in the implementation, and that somehow it translated into business vocabulary, "completely enough" to support definitive assessments.
But how did that those assessments take place? Measurement puts vocabulary to the ultimate test. Even with ITIL's dictionary, processes can improve in quality independently of the change in their business impact. Why? Because process utilization is by choice. At first, the impact of a new process may be mainly a reflection of the degree to which the process is used effectively, regardless of its inherent quality. So if process quality does not equate to business quality, what vocabulary is universally applicable? This is the issue.
A business communications protocol
Standardized process terminology can be quite different from process information. Terminology that helps to conduct the process may describe the integrity of the process without describing the impact of the process. This is likely the terminology in a model.
Process information, on the other hand, should describe the availability and relevance of the process to participate as a component in the business operations. Standardized process information would concentrate on bringing consistency to describing availability and relevance. This kind of information might be found in a catalog or registry.
As identified earlier, business terminology, managed with a thesaurus, should allow observations to cross contexts without losing their meaning. Attaching certain perspectives to terminology, the thesaurus provides "persistence", yet not rigidity, in the ways that business operations are observed.
And finally, business information should supply the description of impacts, risks, benefits, goals, and other value judgements that distinguish the state of the business from one situation to another. The most prevalent example of this is a contract.
Deriving "business intelligence" from business communications
As shown in the graphic above, these four approaches in protocol anchor the development of certain types of communications, to which numerous business roles can subscribe without fear of confusion. Thereafter, business performance analysis mainly relies on integrating the different types of understanding derived through the protocol, not on integrating the data.
The conceptual integration of those different kinds of understanding will require models of operation and models of performance that define the chains or networks of influence expected amongst the associations of actions, events and states. But it is higher-level frameworks that provide the mechanism for identifying the actions, events and states which need to be observed in order to build the models.
Since most performance measurement analyzes compliance to existing models, the initial frameworks actually lay out the "foundations" for the business analysis as well. Business vocabulary should therefore concentrate on the frameworks, first.
Posted by Malcolm Ryder at 6:03 AM | Comments (0) | TrackBack
May 24, 2005
People, Process and Technology
Said Mr. Cho, the president of Toyota Motor Corporation:
Other companies tended to hire brilliant people to run broken, disconnected processes. Toyota designed processes that average people could use to get brilliant results. In the end, Toyota would win.
Leaning Toward Utopia
by Art Kleiner
http://www.strategy-business.com/article/05208?gko=2d846-1876-9231515-5208
Posted by Malcolm Ryder at 8:04 PM | Comments (0) | TrackBack
Optimizing Performance Capacity
Concepts like the Balanced Scorecard have shown that the notion of business performance should be built on a logical foundation of contributions identified from multiple corporate perspectives.
The BSC perspectives -- which describe the overall set of interactions between a workforce, the process designs, the market requirements, and the economy -- give a good account of the "biology" of the business.
The organic flavor of the Balanced Scorecard (BSC) set a benchmark of expectations about a management team's ability to describe the underlying complexity of operational effectiveness. It neither downplayed the complexity, nor asked for overwhelmingly detailed intelligence. Furthermore, it had strong intuitive appeal to the virtuous management desire to "take care of the business" in terms of health and prosperity, not just wins and dollars.
Yet with amazing consistency, senior executives cite the same two shortcomings in the attempt to adopt of the BSC. On the one hand, it didn't tell companies how to accomplish the linkages that it described; and on the other hand it wasn't a boon to profitability within the short and brutal cycles of typical "performance measurement." Some companies get it done anyway, but most who try don't.
Understanding that the BSC consciousness is institutionalized in evolutionary fashion helps to put these shortcomings in perspective (no pun intended). In a sense, the major focus of the BSC is accountability. It provides a guide to constructing the explanation of why things worked the way they did. As management tries to attribute outcomes more consistently to the "biological fundamentals" represented by the BSC's four perspectives, it is actually trying to account for how health drives performance.
More often, though, management is pressed to describe how competency drives performance, and this is a view that is coming into focus more rapidly now than before. Due to the distinctive pressures of the current business climate, the major issues controlling the dynamics of the business outcomes are strategy, efficiency, and governance.
The following graphic shows why this is the case: the three high-level variables or "levers" of corporate management are
- direction and purpose against market shifts;
- bandwidth; against the economy; and,
- permission under regulatory constraints.
When any one of those three variables changes, there is a corresponding risk or opportunity created in the three management concerns that link them together -- those links being priority, availablity, and authority (as seen below):
Those management links are the very ones that obviously dominate the decisions about what to do, what to change and what to stop -- in other words, they are the internal business drivers that put competencies like strategy, efficiency and governance into play. The goal is to optimize their balance so that the overall response capacity of the organization can be held at a maximum.
In sum, reviewing events according to this view accounts for how the organization is brought to a state that is best for business agility and continuity.
Posted by Malcolm Ryder at 1:50 PM | Comments (0) | TrackBack
May 23, 2005
Permission versus Approval in Governance
"Governance", unfortunately, means different things to different people. First, there is the aspect of who enforces compliance. Second, there is the issue of how each given business participant's scope of responsibilities mean they should conduct compliance. Depending on who most needs increased orderliness in the environment, the two aspects are blended in various ways.
In order to work out those blends, one thing that governance should especially be able to do is to formally distinguish permission from approval. Why? Because when company members must decide amongst multiple options for action, approval will link the choice to current priorities, while permission only links it to opportunity. Thus, permission fosters opportunism, while approval fosters performance.
Enforcement and conduct are, of course, fairly direct influences on "successful" governance, both individually and in their relationship to each other. But the relationship between the two of them is often invented, not just legislated.
That happens because an organizational structure, although highly pragmatic, must not be rigid; and as it structurally changes to meet evolving and new requirements, it must rediscover what is governed and where a practical need for governance is most emphatic.
In the business organization, the relationship between enforcement and conduct must usually be resolved from the top down in the management structure. Yet "top-down" is not a one-size fits all approach. Instead, a variety of formats exist to establish the presence of a governance practice, including centralized, shared, federated, and others.
Our society is so complicated these days that governance is becoming an increasingly explicit topic of concern in regular life. This exposure might be very instructive.
For example, one especially interesting phenomenon of top-down governance surfaces in the news every few months: how can there be an event that is federally banned yet allowed by the states? What is the point of having a state position that apparently is overruled by a higher authority?
A review of this governance issue may hold lessons for use within the individual company arena.
First, we would consider what is the purpose of the state level of government versus the federal level. Second, we look at how the purpose distinguishes the position taken on the issue.
As an example, certain medication options appear to be permitted by a state but not permitted by the federal govenment.
The trick here is that the overrule is only apparent. Here's a solution to the paradox:
- The Federal-level position is that the medication is "not permitted" unless authorized, but that authorization is permitted at a state level.
- The State-level position is that the medication is permitted if the state authorizes it, but it is not authorized unless it is approved, an action for which there is generally some procedure defined. The procedure itself may have to pass Federal muster.
This makes a state-level approval the condition that establishes permission recognized at both the state level and the federal level, bringing them into alignment.
This complex mechanism of granting authorization and approval rights is interesting primarily because it allows a "think global, act local" approach that accommodates present risk and change in operations.
The accommodation allows for contingencies and innovation that help the organization generate and capture more opportunities of great value -- namely, opportunities for business recovery, continuity or growth.
A business mechanism similar to the example above might feature a policy guiding a portfolio with which the organization is managing some contracts.
Posted by Malcolm Ryder at 11:48 AM | Comments (0) | TrackBack
Aligning Operations and Strategy
"So, you know how to get there, right?"
In business, results rule. Understanding the results of operations is typically the dominant issue in management communications between different levels and departments of a company.
This accumulated understanding is key to synchronizing operations throughout the enterprise; and by providing end-to-end support for fulfilling business requests, that synchronicity allows current priorities to be a successfully demanding driver of operations.
But different parts of the organization respond to different kinds of requests. Over time, if a common awareness of objectives is lost, the request-driven results being observed more easily diverge from strategy, and those results are then much harder to use as representations or predictors of future performance.
To minimize or prevent this divergence, the organization needs a shared and consistent view of the big picture -- consistency that provides an on-demand ability to refresh the awareness of shared objectives, across the multiple parties involved in the pursuit and across the multiple occasions in which action must be prioritized.
"Honey, please stop and ask for directions..."
The organization's most consistent view of a strategy comes not from the analysis of results but from the enterprise-wide publication of the plan.
Drawn from that awareness, a management-grade depiction of planned organizational readiness would cover the state of the organization spanning all possible states to all actual states.
Put that way, the task first seems to require a prohibitively large amount of descriptive information; yet ordinarily the company fully attends to getting that scope of information by capturing it through processes and the systems that host those processes. With the numerous information sources, creating the "big picture" is not done through brute force but instead through compiling surgical slices of observations that are each shaped by a particular point-of-view. Because there can be an almost unlimited variety in the points-of-view, the classic problem is to prioritize them, and then to coordinate the ones that are most important. The compilation is a model.
This model helps to reveal, remedy, and support key interdependencies amongst the differing responsibilities and authorities that run the business day-to-day. Consequently, it is seen as a critical success factor in understanding how the organization is really functioning.
But what is the model's prevailing logic for coordinating those differing views? Is the logic oriented towards explaining results or towards monitoring objectives?
"Are you sure we can get there from here?"
We want to say that the logic must be oriented to both... but this rarely happens except in product management or in project management.
Outside of those two domains, there still needs to be a framework in which operations are synchronized in a way that can account for both objectives and results, while allowing changing priorities to be flexibly accommodated.
This framework must take into account the different perspectives on organizational readiness that are usually established by managers. The question: what is the organization ready for? In taking responsibilities for issues ranging from all possible to all actual states, "management" sees selected, authorized, and assigned states.
But while managers are doing that, operations must make things happen through the front-lines perspective on current demand versus its capabilities to respond. The operational perspective recognizes and must handle constraints that appear in another spectrum of concerns -- going from demand, to associated requirements, to response options, and then final responses.
A key management problem is that organizational readiness and operational perspective can develop independently of each other as separate pre-dispositions -- without productively converging or co-operating. This source of misalignment must be rigorously minimized.
"Okay that's it. Gimme the keys."
The Archestra framework cross-references the organizational and operational issues.
On the organizational side, the problem is to correctly determine the positioning of the organizational unit within the implications of the strategy. On the operational side, the problem is to identify the availability factors that underpin decisions and responses.
When organizational positioning and operational availability are reconciled, the proper throughput of energies is established for objectives to drive results. Alignment solutions must provide support for the intersection of positioning and availability.
Copyright 2004 M. Ryder
Click here for an enlarged detail of the populated framework, showing the reconciliation touchpoints.
For a review of how to develop solution models from the framework, contact me via email.
Posted by Malcolm Ryder at 7:05 AM | Comments (0) | TrackBack
May 21, 2005
The Archestra Lexicon
The Archestra lexicon consists of terms that describe three classes of structures:
entities,
instruments, and
domains.
Entities identify the organization as distinguished from other organizations having autonomy and independent ownership of assets.
Instruments describe and supply the logic used to guide the organizational activities.
Domains identify the relationship networks used to host and channel agreements that form the enterprise.
Strategy and Architecture blend these structures to create the business.
[Entities] include: ---------------
Enterprise the full extent of relationships that constitute an organization's sphere of influence through its developmental and transactional activities.
Company an organizational unit of an enterprise accountable for the distribution and utilization of designated assets within a prescribed jurisdiction and range of locations.
Department a unit of an organization established to be accountable for the functional progress and quality of business processes based on a task-level of execution.
Task a prescribed association of a work-requirement, a skill set, and a work-product -- to measurably change a condition and thereby meet the requirement.
[Instruments] include: ---------------
Framework dimensions that select and coordinate the structural components and relationships within an entity.
Model a demonstration of the characteristics and interrelationships of components in an entity that allow its structure to support its purpose.
Policy a charter of negotiated tolerances constraining operational decisions.
Process a prescribed series of inputs and outputs for points of action that transform conditions from one state to another.
Function a predefined type of transformation of material or conditions performed by a predefined type of action.
[Domains] include: ---------------
Firm all stakeholders whose management decisions directly affect the balance of cost and risk in the enterprise's investments.
Organization the full set of contractual and regulated relationships that dictates the consumption of resources by business processes.
Project the organizational method for development of a specified construction
Infrastructure the set of rules, policies and mechanisms that make "environmental resources" available to inhabitants on demand for purposeful activities.
Architecture a set of principles that prescribes standards and models of construction and component interactions, to assure compatibility between environmental capacity and the functional needs.
Posted by Malcolm Ryder at 5:21 PM | Comments (0) | TrackBack
May 20, 2005
Who is IT's customer?
It's the spring of 2005, and this week's reading was similar to most prior weeks in that analysts and consultants pointed IT towards achieving more strategic delivery of value by focusing on the "customer". But as usual, there is a buffet of choices about who the IT customer actually is: direct, indirect, internal, external, and more, and mixes of them to boot. Does this make the original question to unwieldy to be helpful?
As a preface to answering, it's worth noting that there are different reasons for IT in a business because there are different kinds of businesses. It's reasonable to assume that the focus of IT should "default" to the needs of the business model.
This assumption makes the discussion begin with how those needs are articulated into supporting operations that IT enables, producing the satisfaction of the needs.
How does the business define and measure that satisfaction?
One perspective looks at results that represent the concrete outputs mandated for delivery to stakeholders. The stakeholders include customers, employees, shareholders, and basically any other "business partners" who measurably and intentionally contribute to the protection, health and growth of the designated business.
Another perspective looks at the functional mechanism for the production of those outputs. This mechanism includes the resources, systems and fulfillment processes that day-to-day generate the business deliverables within established costs, priorities and locations.
We're used to seeing assessment techniques that hold IT "accountable" -- sometimes for the results, but sometimes for production. Those assessments have a lot in common, though, because the implications of doing any of them is always the same. They investigate whether IT's impact is:
- desirable;
- optional; and/or
- exclusively or uniquely due to IT.
With those facts in hand, the next stage of consideration is:
- should any of those impact characteristics change?
- who cares if they do or don't?
- why do they care?
- how much do we care about who cares?
Imagine not asking those last four questions: omitting them leaves no way at all to determine a connection of IT to business strategy. This argues that there is a level on which what IT does is promoting things either towards or away from strategy, but that there is a different level on which the business actually responds to the opportunity given it by IT and closes the deal in the form of measurable value delivered and gained.
That level is... business management. And this means that business managers are the direct customer of IT. To make this point more strongly, let's look at what it means to be a "customer".
As a customer, you have what we'll call a need. Your need is based on the desire to have and use a capability of some kind for yourself. To satisfy that need, you search for and acquire an enabler of that capability. The enabler is what we call a "product". The way that the enabler works for you is what distinguishes it as one kind of product versus another kind. Typically, what IT provides is an impact that can be delivered as a product. The impact may be delivered in the form of a tool or a service (and therefore note that a "service" is a product). Once the recipient starts doing something with the impact/product, the capability exercized by that user becomes the sign of the "customer's" presence.
If we look at a business, and we think of how IT gets used, we usually come up with multiple types and populations of users. But if we imagine removing IT impacts (the enabling "product") from any of those user-groups, the effects on the business will be most crippling when IT impacts are removed from managers. Why? Because the success of the business is fundamentally predicated on targeted functional organization, not on labor output -- and at a fairly low threshold of combined speed and size, competitively sustaining the organization is virtually impossible without IT-enabled management.
So, if we assume that the business must have IT, then it is easy to see who is the primary "customer" of that IT.
Posted by Malcolm Ryder at 12:21 PM | Comments (0)
May 18, 2005
Strategy versus Change, and the battle for Agility
Now that we're used to the idea that change is the number one challenge to a company's business performance, it would seem that strategy and change compete for the right to dictate priorities.
Business intelligence vendors go so far as to say that "managing change" is the top survival skill of a business. But the meaning of this is typically specified just as Business Objects puts it in their white paper on enabling business insight: "...organizations, plans and management theories don't accomplish anything directly... success lies in making each person as productive as they can be..." -- which means "to make the right choices among their daily decisions."
The most important aspect of that idea is that the point is not to make the same choices correctly and repeatedly, but to make the right choice each time.
What we could be seeing is a gradually forming understanding that productivity and agility are two views of the same thing - effectiveness:
- productivity being the view that describes resource-effectiveness, and
- agility being the view that describes process-effectiveness (as supported by productivity).
This proposes the logic of responding to an appropriate awareness of change. If timely information about new states can be input to people's decision-making on a continuous basis, the actions driven by those decisions become the life of the processes that drive the company. Ultimately, the process behavior is the output of the linkage between the people and the process.
Given "inputs" and "outputs" as just described, it seems that the people-process link can itself be treated as a (processing) system.
But there are caveats: the inputs are only meaningful to the extent that they are actually usable, and the outputs will of course be subject to tolerances that the business either mandates or discovers within its idea of "business-valuable".
That means there are three stages of management involved in the progression from the initial awareness of change to the business response provided:
- information modeling...
- followed by decision support...
- which is followed by policy compliance.
But this description still leaves "successful" decision support as either a wishful assumption or as a "black box". What's the related caveat? A decision is a micro-process, so to speak. The question is, in that middle stage, how do we organize decision-making so that it actually effects a dynamic alignment of new changes to previous objectives?
To get through this problem, the first step is to think about decision management.
Decision management would mean that the types, distributions, and timing of decisions would be defined and controlled throughout their lifecycle, with alterations made according to the demonstrated patterns of value generated from their current setup.
One useful analogy for understanding what this means is asset management, in which a collection of assets is categorized, inventoried, and tracked throughout their distribution into a user-population according to ownership, location, and occasion of actual use -- from the birth (acquisition) of each asset to its death (disposal). At a given moment, the condition of all these assets can be mapped, and that map can be used to establish correlations of asset distribution against economic impacts. These correlations tend to be used along with allocation histories to establish recommendations, permissions and standards for the use of the asset.
By analogy, each type of "decision" is an asset, and it may be "owned", "allocated" and "utilized" in various ways over time.
What controls decisions?
This perspective on decisions gets into the issue of what the organizational chart looks like, insofar as the orgchart might map how responsibilities and authorities are mixed, matched and bundled around the enterprise.
But (due to the analogy) we're also considering the aspect of "recommendations, permissions and standards" being applied to the decisions. Here, therefore, it makes sense that we'd look into what is considered to be an "acceptable decision" -- acceptable both in terms of how the decision is made and regarding what the decision addresses. The subject of the decision would represent some point or issue of "business value" that makes the decision important to have and use in the first place. That is, the decision will address the subject, but the subject actually validates the need for the decision.
Thus, if we take the subjects of all the decisions being made, and we map them out per their interrelationships and impacts, the subjects map should look like a model of value-capture -- or in other words, like a strategy.
This is pretty much what is presented by many "strategic performance management" solutions today, which offer a strategy map that is decomposed into objectives, their supporting (underlying) performance targets, and the initiatives that secure prioritized achievement of targets. It makes sense that these are, in fact, the "subjects" of business value-capture. Decisions and actions go on to address those subjects.
But that's only half of the picture...
"Business processes" present a different view of action-requirements that drive decisions. The processes are modeled to operationally coordinate resources and actions around specified events that have defined business value. But the events are mainly transformative ones, representing a prescribed change to the state of some environmental condition or some relationship.
If we take the desired states that all the processes are pursuing, and we map them out per their interrelationships and impacts, the states map should look like a model of the operational environment -- or in other words, like an ecosystem.
This leaves us with the challenge of reconciling the two main models -- strategy and ecosystem. This reconciliation, which needs to be continuously produced in real-time, is the essence of "alignment".
Managing alignment
So - regarding change: if decision-management is the people-process linkage where alignment takes place, and there are inputs and outputs regarding alignment, then how can we manage the alignment as a dynamic process? The answer we decide upon will be the real basis of the agility that otherwise is presupposing productivity.
Finding the answer means understanding why environmental states change, and what to do about it.
Along with that, the really big issue to consider is this: what happens out there that makes the business "change the subject?"
Here is an approach that deals with both issues.
Let's position the business model as the principal client of all operations. The business model makes judgements about whether it has different needs now than it did before. In effect, the business model (not something else) changes the subjects.
If it has new needs, and then requests follow-up action to them, it looks to business processes to conduct the fulfillment of the needs. The request that it makes will describe what kind of conditions need to prevail, and this will indicate both a difference from current states and a priority for achieving the difference.
Processes will see the requested difference as the result of events that should now occur, and the processes have to "configure themselves" to execute the events that generate the desired future states.
The requested priority will mean that some configuration options are viable while others are not. Therefore, some "intelligent rules" will need to be imposed on the real-time configuring of the process. The source of these intelligent rules may range widely -- from historically successful habits, to negotiated policies, to analytically discovered recommendations. (This is entirely typical of a change management procedure.)
Meanwhile, a risk-lowering condition is that multiple processes could "collaborate" to "orchestrate" the appropriate event-support, which means that one process will not be burdened with singly covering the huge variation that can occur from one request to the next. Here, there is evident need for a "broker" that can acquire and coordinate the support on time. The source of this brokering can range widely -- from contracts, to service agents, to discretionary managerial intervention.
We've seen it before
Think of the business model as a client with a portfolio, who decides to change contributions or investments -- from one part of the portfolio to another part, or from one level to another level within a part. Operations should respond to that decision by acting through rules and brokering to adjust the portfolio to the client's current needs.
An Enterprise Performance Portfolio segments business model needs into areas for operational attention applied and adjusted in real-time by rules and brokering that engineer process workflow for targeted, risk-managed fulfillments of business model demand. This links business strategy to the business ecosystem, facilitating agile response to change that translates resource productivity into business performance.
Copyright 2004 Malcolm Ryder
Posted by Malcolm Ryder at 3:34 PM | Comments (0) | TrackBack
May 16, 2005
Making space for Strategy
The distinguishing feature of strategy is its key topic: "Where you're going to be, and why you're going to be there."
This topic's key idea is that strategy always seeks an advantageous position allowing some following action to accomplish an objective.
A strategy-in-progress might seek a group or succession of positions, allowing an accumulation of impacts that finally, pressing past the tipping point, realizes a singular higher-level goal.
But one essential difficulty of strategy is that it usually must be cultivated in an environment whose own dynamics tend to diverge from the positions of the strategy and are busy enough in some other way that (worst case) leaves little room for strategy. Just as farming or gardening creates a productive order by leveraging conditions driven by autonomous natural "forces", organizations must be induced to support progress towards the positions of the strategy.
The idea of cultivation gives a way to describe organizational requirements for enabling strategy. What are the levels of preparation that characterise the development of an organization's state of hospitality to strategy?
For example, an initial "groundwork" level is involved in the form of tending the quality of assets (like the fertility of the soil)... this creates one supporting "base" layer of readiness.
Strategic readiness can be built up progressively through various supporting layers, each layer logically contributing to the overall capacity to capture, leverage and resolve strategic positions. For example, the top to bottom order of layers might be identified and managed as follows:
- engagement (fit with environment)
- policy
- administration
- process
- assets
Strategic readiness is enhanced by increasing the coherence of each layer's capacity and by synchronizing the different capacities across the layers.
"Capacity", for any given layer, means the distinguishing volume and type of impacts generated on that layer's intrinsic terms. This might be most easily promoted through a management framework for each respective layer, ensuring the quality and availability of the output of the layer.
Coherence of the layers means that they "stick together" by virtue of the practical strength of their interrelationships (and interdependencies) -- both internally amongst their components, and externally across layers.
Synchronization means that the production "rhythms" of each layer are beneficially coincident across the layers.
The design, maintenance and interlinking of the layers creates the space for strategy...
Posted by Malcolm Ryder at 10:54 PM | Comments (0)
May 15, 2005
What is "what you know" worth?
It's not what you know that counts; it's how you know it.
Ask any psychic.
I. So, you wanna be a knowledge manager.
What are you, psychic or something?
Ordinarily, you can go down the KM path armed with this:
Data+context = info
info+usage = knowledge
knowledge+history = wisdom
You'd think this would be a good place to have your employees wind up, but that's not what they care about.
Their issue is that they have to go from observing to thinking to deciding to expecting. The path they want you to pave is like this:
Reconnaissance --> Information
Information --> Analysis
Analysis --> Patterns
We're accustomed to leaning on our "information systems" to carry out the reconnaissance and analysis, but do our info systems make us smarter? Only if they interpret the patterns, too. We feel "smarter" when, based on what the patterns mean, we know what to expect.
Why the emphasis on expectation?
Because in business there are two main types of "smarts", both future-oriented -- the kind that reduces risk, and the kind that leads to innovation. By solving problems, and by surprising customers and competitors, the business goes forward and gets ahead. That's where the rewards kick in.
So what do patterns have to do with these benefits?
With the speed of information processing now available, the main problem for a business is not to get enough information on time, but instead to get "the right" information. For the most part, the problem lies in not knowing which information is relevant or "best", and that confusion makes both finding and choosing the right information equally daunting. Result: complexity in the thought process overwhelms confidence in decision-making.
But a pattern exhibits a path that navigates through complexity. This is the kind of knowledge that rates highest, the kind that the business wants.
And who are considered the smart guys in your company? The ones who can either make a path or see one, where others can't or don't.
But how do they do it? More importantly, how do you do it for your folks?
II. Teach a man to fish...
Typically, "business intelligence" comes in with the responsibility of generating patterns from the complexity. This sets the stage for what the business is really after, which is to use the patterns to make decisions.
Thus seeing the affair as having two steps, we can look at what essential challenges the knowledge manager will need to overcome.
The first step, "intelligence", is critically dependent on information discovery. We realize that the diversity of the company's employee and customer population means that there is a lot of information distributed in ways and places that are tended mainly by those people. To aggregate the distributed information, we need them each to contribute what they have. Usually called collaboration, a voluntary aggregation creates a body of information that must be formatted for usability-on-demand. Making contributions voluntary is a tough prerequisite worth solving only if their usability is also known to be within reach. Altogether, this is the heavy lifting that changes the way most people can get things done. Even exceptionally gifted "knowledge workers" or experts like Infoworld's Jon Udell rely mainly on this capability enhancement.
The second step, "interpretation" of patterns developed from business intelligence, is about what people will decide to do. It has most often gone by names that we (except for marketers) don't attach to information systems, names like "wisdom", "insight", and "intuition"... Too often hopelessly confused with each other, they seem unmanageable or evangelically mystical.
Fortunately, each mode of interpretation can be seen generating a distinctive kind of "findings" which have practical value in support of decision-making. But these kinds of findings are something that we need to get our hands on -- and then record, repeat, compare, associate, and so on -- from less than supernatural sources. People, histories and systems can all variously help, but the full value comes from covering all the interpretative modes:
Wisdom --> Probabilities (operations)
Insight --> Implications (tactics)
Intuition --> Foresight (strategy)
III. The Payoff...
This consistently future-oriented perspective on the value of knowledge is naturally where KM needs to bank, strategically empowering risk management and innovation on demand.
Ultimately, what the business wants from knowledge is explanations for "what kind of risk did we decide to take?" and "how is this going to give us a new advantage?" Bottom line: "What makes you think that?"
Managers should have a bird's eye view of the plan for keeping those explanations coming.
- A certain amount of excitement comes with realizing that a description consisting of foresight followed by implications and then probabilities yields... a business case!
- And, accompanying the aggregation that initially supports decision making, critical review finishes off the job.
- Under the umbrella presumption of their "experience", we should look to other people for both the content to aggregate and for the terms of a critique. The manager's challenge is to determine when and how.
In the end, cleared of hype, the business point of actually managing knowledge is to get beyond knowledge per se, and into an accountability of expectations.
It's also clear that management should set expectations of KM's deliverables accordingly.
Posted by Malcolm Ryder at 10:04 PM | Comments (0) | TrackBack
May 14, 2005
Performance Management - The Return of Engineering
Engineering -
The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems. - American Heritage Dictionary
This definition is a good reason to ask what is intended by the use of the phrase "performance management". Isn't "operation" already responsible for performance? What is separate about performance that needs to be managed?
In the generic cycle of responsibilities that make up management, engineering clearly refers to the conception, development and implementation of whatever instrument is being utilized.
But we're asked by "performance" management to consider how and why the effectiveness of the instrument is faring.
What's interesting is the step from engineering's economy and efficiency on further to effectiveness.
In the management cycle, the "support" phase follows the implementation phase; so, is support where effectiveness starts?
Normally, performance management places top priority on the cause-and-effect relationships -- namely, the operational designs -- that drive and account for achievement of intended results. The approach, however, assumes that information about the causes, effects and results will be available for analysis in order to deduce or (more often) infer what part of the operations should be accountable for results -- and accordingly what part if any should be reinforced or changed.
This makes it obvious that feedback is the primary active ingredient in the support phase. By comparing feedback to the intended effects of the operations, we get indications of whether or not the operations are appropriate to the intentions.
Informing the decisions about reinforcing operations certainly qualifies as "support"... But where changing operations is concerned, it's appropriate to investigate whether the change should be made to the intentions that are labelled results, or instead to the result-oriented activities that have so far been developed and employed.
How does this relate to effectiveness? A simple working definition of "effectiveness" distinguishes it as being the quality of the given means's ability to achieve necessary levels of impact. In performance management, as in engineering, effectiveness is an aspect that is tested under the stress of action.
Based on the feedback, it might be decided that engineering adjustments of those activities will be made, or that the intentions themselves might be adjusted as acknowledgement of what the engineering is really capable of offering.
A key here is to have both a broad field of view regarding what the engineering should be capable of, and a narrow field of view examining the situation-specific results. Variations in both the means and the circumstances will be discovered to be the rule rather than the exception, and tolerances will have to be established for all the combinations that allow a desired outcome. The ability to dynamically adjust within tolerances must be built in.
In the end, "acceptable performance" is not merely constructed or induced -- it is engineered.
Posted by Malcolm Ryder at 8:22 PM | Comments (0) | TrackBack
May 12, 2005
Performance Management - a master framework
Performance management is most often presented as an analytical effort. But managing "performance" means managing activity designated to produce certain levels of prescribed effects, including the befores, durings, and afters in the activity lifecycle.
- The befores must logically relate events to influences and to each other.
- The durings must occur within tolerances expected to preserve the integrity of those relationships.
- The afters must validate the correlation of the actual results and the planned results -- providing critical information to the management of change that will deliberately adjust ongoing activity.
In each case, the fundamental effort is to generate alignment between the business mandated state and the reality of the business organization's production. This alignment must be managed on strategic, tactical and operational levels, in each case covering the complete decision cycle that establishes business positions and reactions from intentions throughout impacts.
(Click here for an enlargement of this image.)
Therefore inherently operational, performance management involves a universe of interactions between methods, tools and knowledge that can manipulate actions from the abstractions of their original conception to the concreteness of their impact.
Performance management "solutions" must provide logically integrated coverage of this scope of interactions-management .
(Click here for an enlargement of this image.)
Copyright 2004 M. Ryder
Posted by Malcolm Ryder at 8:16 PM | Comments (0) | TrackBack
Turning Measurement into Management
So you can't manage what you can't measure, and if you tell me how I'm measured then I'll tell you how I'll behave, but how can you trust me, and how can I trust your measurements?
(A presentation about the items below is here in Adobe PDF format which can be downloaded.)
As a manager, the best thing you've got going for you is feedback. You can ask for "certain kinds of feedback", in order to be more sure that you can interpret what you find out.
This can mean two different things, however:
- feedback on certain kinds of things,
- or certain ways of feeding back on things.
Usually, the management effort calls for specifying both. And together, valuable efficiency in communication should be achieved. But then the issue becomes completeness. Is enough of either requirement being accomplished?
To avoid incompleteness, companies often go into overdrive both ways. The downside of that is when overdrive becomes overkill, creating a new kind of gap between the feedback and the effort to manage. Unusable feedback throws management into reverse by cultivating uncertainty, waste or rework, and skepticism in communications.
So a plan for systemically reinforcing "measurement that matters" is a high priority.
Making this reinforcement systemic means creating a two-way communications bridge between what people plan to do about a goal and what they actually do about it. With this, the focus can be put on how well the planned and actual correlate, and emphasizing the value of the correlation will naturally drive attention to the two sides of the correlation.
Many organizations immediately think of this correlation as "compliance". But that is giving short shrift to the idea that the correlation is valuable. Managers must additionally communicate what correlation is valuable to the business and why -- in order for compliance to be culturally adopted as a performance enhancement tactic.
By clarifying the value of the compliance, managers provide credibility to the idea that the measurements they ask for are important, and people who are in position to provide feedback in the form of measurements are more motivated by the idea that they really have first-hand knowledge of how the business is doing. In that frame of mind they are more likely to show that they know.
Copyright 2004 M. Ryder
Posted by Malcolm Ryder at 4:22 PM | Comments (0) | TrackBack
May 11, 2005
Investing in Returns on Infrastructure
ROI doesn't just come to the party with an invitation in hand. Instead, it must be brought to the party by the host. The activities for making that happen are numerous and even predictable to an extent, but there is no one-size-fits all methodology. Instead, opportunities for actively cultivating ROI are found in various levels and dimensions of management. Several of these, associated with production infrastructures, are surveyed below.
Getting the value of Processes
Process integration in effect dynamically prioritizes the selection of supporting resources to consume for the purpose of assuring focus on the value proposition (goal) of the process. Then the integrated processes also provide efficiency in actually provisioning those resources on demand.
The immediate payoff of that one-two punch is effective navigation of the complexity of the operations infrastructure, allowing sustained productivity and expansion of capacity for productivity. The effectiveness can be verbally expressed as "getting the right thing to the right place at the right time for the right reason." Placing a value on that effectiveness sets one term of the "ROI" of implementing the integrated processes. The other term is the cost of executing the implementation.
Value
Value is defined as the significance of a difference.
The most important aspect of evaluating the difference is to distinguish between whether things have just gotten different versus whether they have actually gotten "better". This means that the only real meaning of an ROI calculation must logically come from the original definition of what represents "better".
Typical examples of "better" are:
- faster cycle time
- lower opportunity cost
- increased re-usability of employed resources
- greater scale of process availability
But even those examples are arbitrary unless they are causally (logically) associated with a higher-level business performance need – such as competition, compliance, reorganization or growth.
Cost
Meanwhile, cost must also be properly defined. When what is being considered is "expense", cost seems obvious – but a line-item expense does not automatically include consideration of: the cost of the funds; nor the unavailability of those same funds to other purposes (that may also either earn more money or spend more); nor the additional expense of maintaining the target outcome of the initial expense; nor the disposition of the expense amount against the time period, and/or the changes, of the demand for the funds.
In general, those additional considerations (and more) are assumed to be covered by the "expense approval" process. The key observation here is that the presumed final value of a proposed expense may be irrelevant to the importance of using the funds, unless that value is clearly competitive with (and probably superior to) other options of equal spending opportunity. In order to know what the best calculable choice should be, a minimum level of real-time business intelligence is required to support decision-makers. Decision makers should look for expenses that actually represent effective total costs.
Value versus Cost in ROI
The relationship of cost to value will show that overall operational improvement should take place as a matter of optimizing procedures at a target scale within the constraints of cost-effectiveness, for a defined goal.
Optimization, scale, and constraints can all be separately modeled and then interrelated in deployment. For example, workflow running at an enterprise scale under a policy is a demonstration of modeled relations comprising an operation.
The investment in this includes:
- all measures taken to conduct the goal-seeking.
The return in this includes:
- the impact of the amount of the goal achieved by the effort, versus the impact of the prior "as is" conditions.
A related way to represent the visibility of the ROI is through a portfolio within which any given category of investment is handled with business process management.
Architecture
The purpose of architecture is to bring cost-effectiveness to sustaining the quality of the process throughout the lifetime of the demand on the process.
This means that the quality of the process must be defined. The definition normally starts with the selection of outcomes to attribute to the influence of the process, followed by determination of requirements for supporting those outcomes, and then by identifying utilization of resources to attend to the requirements.
This shows that quality is about fit-to-purpose, which makes quality variable in two ways:
- relative fit against variations of purpose
- absolute fit to a fixed purpose
Associating "investment" and "architecture" is logical because both have the aim of establishing a foundational environment for producing against requirements. The production methodology utilized at any time is literally based on the foundation, but this makes sense only because the foundation is a resource supply. So the logic of the foundation (i.e., investments or architecture) is in the way it offers "resources" on-demand.
Assets
By definition, a resource is an asset that has an assigned job. This means that the "assets" used to make up the investment or architecture must be subject to some function that converts the asset into a resource. (The question of whether the resource is passive or active in its assignment at any given time is a different issue, one that is not essential to the distinction of whether the asset is a resource or is not a resource.)
When committing an asset as a resource, economy of scope, not economy of scale, is the main economic issue in the allocation of the asset.
In investment and in architecture, the purpose of the resource is to be consumed by the assignment – which makes the economics of the resource a matter of how much of an intended effect can be generated by the consumption before the resource is exhausted. This makes the pattern or mode of consumption a key factor, since there is the problem of whether the consumption wastes the resource or not. The flip side of the consumption pattern is the quality of the asset that allows itself to be consumed in the role of being a resource.
Thus, a formulation very basic to the calculation for ROI is the statistical correlation of the engineered quality of the asset to the probable impact of a given consumption mode. For example, an old VW Beetle in the hands of a highly competent adult driver will likely be a more "productive" combination than a Ferrari in the hands of an inexperienced teen.
BUT, the economics problem is not to know what is the capacity of the asset to support some level of demand for one effect (economy of scale).
Instead the problem is to know what breadth of effects can be and may need to be supported by the asset (economy of scope).
That is, the qualities of the asset must offer a degree of versatility that is appropriate only to the controllable range of "necessary" patterns of resource consumption that it will host. This brings out another issue, which is the use of control mechanisms (disciplines) and judgments of necessity (priorities, or in effect, policies).
Modeling ROI
So the ROI is really a calculation that refers to an outcome based on a set of four interrelated and variable aspects:
- quality (engineered) of the base asset
- security of the asset’s assignment to a role (making it a resource)
- control of the consumption imposed on the resource
- predictability of the requirement for consumption.
We can generally say that to start things off a "cost" (via either build or buy) develops the availability of the asset. However, that cost is a long way from being a predictor of the ultimate "benefit". The expectation of the benefit is most often predicated on making all of the four variables as little variable as possible. This so-called "optimization" might raise confidence levels, but it also makes the fully interconnected set of aspects more rigid, and therefore less likely suitable to conditions outside of the declared tolerances. Thus, in conditions of change and uncertainty, the optimized set is more risky. Consequently, the next concern becomes to make this risk affordable, or (to emphasize the point) "tolerably disposable" – which is what is really at the heart of the goal of "agility".
That concern pressures the entire set of variables to be obtainable at the lowest cost and/or at the highest "billable" rate of employment. The main problem here lies in the case where the beneficiary of the set must also be the supplier – in which case, on the way to determining ROI, the (approved) expense of self-provision must be subtracted from the presumed income of the benefit to discover if agility is in the cards.
Assuming affordability, it follows that this is a point at which focus should be placed mainly on the competency necessary to generate the benefit.
"Competency" is the ability to meet necessary performance levels under circumstantial demand. Differently, "capabilities" are persistent mechanical components of the competency. Ideally, constituent capabilities can be improved to drive greater competency. In this perspective, the supporting capabilities need to be exchangeable without altering the target competency, because relative improvement in capability may come through either modifying (upgrading) old capabilities or replacing them with different new ones.
Capability improvements are generally viewed as either increased "effectiveness" or increased "maturity". But the two are not similar. While effectiveness normally indicates "strength of impact", maturity normally indicates "consistency of required impact", which is really in other words "quality".
Risk vs. Benefit in ROI
With that observation, the concern of "capability maturity models" is recognizable as being about specified quality levels, with higher levels actually representing less risk as opposed to more effectiveness.
This natural objective of increasing "capability maturity" is to bring more ability to define (and limit) the range of variability in the four interrelated aspects of driving targeted (i.e., pre-specified) operational benefit.
The greatest significance of that change in ability is that by reducing the likelihood of waste against the target, it increases the probable value-contribution of predefined resources and predefined patterns of resource consumption.
However, since more rigidity in the production also increases operational risk under conditions of uncertainty, the logical strategic addition to this improvement is to contain the extent of the risk by limiting the scope of predefined production assigned to the set of variables. That is, "modules" of production capability will be defined.
In most cases, this turns into an approach of achieving greater overall operational scope by combining (integrating) several high-quality modules of production, each having a distinctive functional responsibility treated as a constituent capability.
Once these modules are defined, their utilization drives their economic impact, which is not the same as the ROI of the processes that they support. Again, the greatest importance of these modules (or optimized capabilities) is in how much more the impact of their utilization results in achievement of goals when compared with the use of the current-state infrastructure to pursue those same goals.
Investing in the Return
Summing up, the "return" on an investment is described as:
- how much improvement has been obtained in…
- the ability to carry the risk that is inherent in…
- requirements for supporting the process of…
- meeting targeted levels of performance in…
- pursuing a defined goal.
Posted by Malcolm Ryder at 11:05 AM | Comments (0) | TrackBack
The new architecture of Business alignment: Services
This discussion is one in a long series about how Business derives value from IT.
In this discussion, Business is wondering how IT can better support the functional capacity that Business needs in order to address its market requirements.
This functional capacity decomposes into qualities, economies and availabilities derived from the arrangement and interactivity of "components" of information technology.
But here is where the going gets gnarly. The notion of components is meaningless unless components are given roles that explain their reason for being involved and that effectively issue design requirements for the components. Examples of roles would be support functions that make up data communication, information management, or event synchronization.
Architecture manages the design of both the components and their relationships, according to their roles. Given that, the superceding business issue is to agree on what kind of effects the roles are supporting.
Establishing the value of roles
Rather than listing an undifferentiated universe of "important business effects", effects should be classified according to the way the business recognizes value being generated.
These classes of effects make sense when they logically discriminate the conditions in which a given effect has a certain type of value.
Generally, the business needs to run in certain conditions, and in those given conditions it needs to do certain things to a certain effect. This means we should take into consideration a difference between environmental values and operational values. They need to be respected separately because they can change independently of each other.
Despite that, IT implementations are often asked to solve both problems -- that is, to create the conditions and to prosecute functions in the conditions that they created.
After all, that is precisely the holy grail of "automation". Think of it this way: we ask a Hum-Vee to make inhibiting terrain navigable so that we can transport something through it in the Hum-Vee. Likewise, we ask radar to guide missiles. We ask spreadsheets to derive answers. We ask process modelers to write executable code. Or as the guys at Sun Microsystems used to like to say, we want the network to bethe computer...
Since we admit that we mainly like technology because we like automation, it's understandable that we might struggle with separating the environmental aspect and the operational aspect. We don't like the environment and the operation to be separate.
Engineering the effectiveness
Annoyingly, they don't readily cooperate with us unless we intervene in a big way.
The latest industry-level intervention -- the new zenith of automation -- is utility computing. Utility computing does things to the computing environment that makes the environment more worth doing things in.
As noted by Quocirca (and found via Silicon.com), "vendors such as IBM, Microsoft, Oracle and HP use terms as diverse as 'on demand', 'agile business', 'grid computing' and 'adaptive infrastructure' to describe their visions of utility computing, but the general push is similar, even if the rhetoric is different."
Despite the similarities, there are really two different pushes: one is about IT serving the business, and the other is about the business serving its market.
This starts to remind me of a typical "value chain" -- in which several different roles correspond to fulfill an order for a deliverable of known (or at least agreed-upon) effective value. We already know that value chains are actually complex and asynchronous, distributed over time and space. But then they are brought to the task of fulfillment specifically by agreements amongst them to also collaboratively operate a supply chain.
The value chain is how we can catalog the classes of effects. For example, printing a finished report at my desk, developed from live raw data stored in a computer in Switzerland, means invoking a value chain with links that can:
- understand and accept my request
- decompose it into subrequests
- farm out the subrequests to producers
- produce the components of the deliverable
- coordinate those production artifacts in the desired format
- route the resulting compound product to me.
In fact, each link in the value chain can represent a certain class of services, resulting from supplier and consumer agreements (about effects) typically made at each link.
But for the chain to finally deliver value, alignment of the services is needed, meaning that the success of the precedent service reliably promotes the success of the subsequent one. So it seems reasonable to ask more carefully what "success" means in both cases.
When it comes to services, the specific issue of "providing for" is crucially important to understand: a supplier may or may not be the creator of the product or operator of the production effort that we expect to be the "deliverable" gained by the consumer. But the supplier arranges for the deliverable to be received by the consumer, more or less on demand. The agreements that constitute the "service" also include definitions of when the demand will be respected by the supplier. That is, the demand itself must satisfy certain criteria, just as the deliverable must.
As consumers, though, one thing we always want is the maximum convenience in navigating the value chain to reach our fulfillment. I like exotically designed plastic pens, but I have no interest in being involved in the original oil-drilling that is making them available.
As suppliers, we want to maximize the economy of scope of our influence in the value chain. I don't want to be both a distributor and a manufacturer if I can get better "ROI" just being a distributor.
And the zinger is that at every link there is competition both for demand and for supply. I'm not the only one who wants to use the oil, and not everyone wants plastic pens.
Making it all workable
This is where an architecture of services kicks in.
The business purpose for architecture is to instantiate a value chain as an environment of several infrastructures -- that is, an environment that allows supply chains to be dynamically constructed from networks of value chains, for fulfilling demanded deliverables. By any name, this is basically what the Business wants the capability to do.
This is also where the difference emerges amongst the vendor spins on SOA. They differently prioritize the need for this environment.
For example, consider a business's current strategic priorities in its relations to its market. Does the business's current degree of automation allow the desired level of:
- Business capacity? (agile business)
- How about responsiveness? (on demand)
- How about risk? (grid)
- How about change? (adaptive infrastructure)
Now, for whichever of the above types, what is it that the Business thinks is suffering from an underlying undersupply of automation?
- Horsepower?
- Applications?
- Security?
- Continuity?
- other?
Role-based IT "components" will be conceived to support whatever issues the business has from combinations of concerns like the above. There are many many possible combinations... which tells us that there will be a wide array of value chains designed.
For now it seems that each link in each value chain might have its own optimal definition, which challenges the idea that a link can be shared by two chains (e.g like a node shared by two paths...) and threatens to dis-integrate infrastructures instead of integrating them. And should the infrastructure for a service link exploit a particular architecture to ensure its optimization?
Because we're already accustomed to having a network of networks (the internet), we can already abstractly imagine an architecture of architectures. But the complexity of that makes a unified environment seem quite far off into the future.
To make this struggle immediately less aggravating for the Business, we have the concept of services.
The practical usefulness of this concept is that it lets us represent a situation in which a "supplier" and a "consumer" agree on what are the salient characteristics of an "effect" -- and also agree on the terms of providing for that effect -- thus mapping the value chain. The question is, with more than one value chain at stake, how hard will it be to manage all the services desired?
The key to meeting this challenge would seem to be a broker that can discover, qualify and select advertised services. And this makes the service qualification process the heart of the new architecture.
Posted by Malcolm Ryder at 10:56 AM | Comments (0) | TrackBack
May 10, 2005
Alignment rap: Cats and Dogs, playing together, nicely
I'll leave these here just drying on the sun line instead of in the hot tumbler, until I need to use the clamps for something else.
Collaboration: two parties working concurrently on the same goal for the same reason.
Co-operation: two parties working concurrently on different things in the same place, compatibly.
So far, if you're a parent, you already knew those two were different. If you're not, you might have felt like arguing. Don't bother.
Correspondence: two parties knowingly and separately acting on the same thing, compatibly.
Corellation: two parties separately acting on different but interrelated things.
Coincidence: two parties acting on something at the same time or place, whether different "somethings" or not, but usually meaning on the same something.
And in the not-so-nice category:
Competition: two parties working on the same thing for different reasons.
Collision: two parties working on different things for different reasons in the same place at the same time, incompatibly.
Confusion: two parties thinking that each knows what the other one is doing but at least one of them being wrong at least at this place and/or time.
Corruption: two parties, where one party has the other party unknowingly doing the first party's work for the first party's reason.
Coercion: one party unwillingly doing the other party's work for the other party's reason.
Constipation: one party just not being able to get rid of the other party. :-O
Posted by Malcolm Ryder at 3:47 PM | Comments (0) | TrackBack
Much ado about Knowledge
Here's a riff about KM.
You have the hierarchy (bottom to top) of data-info-knowledge-wisdom.
Data+context = info
info+usage = knowledge
knowledge+history = wisdom
All four items in the hierarchy can be recorded, making them "content".
Every kind of this content has a lifecycle of:
-acquire (discover/create/buy)
-store (classify/format/save)
-deploy (publish)
-process (consume/transform)
etc.
Then the fun begins:
-what are the reasons for taking any action in any phase of the lifecycle of any kind of content?
-what are the restrictions for ditto...
-what are the rules...
-what are the requirements...
Why are those the reasons/restrictions/rules/requirements?
- authorization (by who)
- circumstances (where, when)
- benefits (and for whom)
- costs (and for whom)
Perhaps lastly you have the idiosyncratic stuff:
- expectations
- permissions
- quality
and those kind of things tend to determine whether behaviors with content get exercized, prioritized, banned, or whatever:
- sharing
- distribution
- licensing
- maintenance
- etc.
Now, in each of those groups of considerations above, think of every separate item as a possible term or factor or "feature" of a content package that party A can make available to party B. (Ignore that some of the features might be undesirable or irrelevant sometimes; they still have to be accounted for in production as being intentionally included or excluded.)
Next, work up all the feature permutations and price them. What's the "market" for each permutation (i.e., type of package)?
Then, if you think of yourself as the package provider, and you think of the start-to-finish provision of a package as a "made-to-order, from scratch" event, it's easy to imagine yourself quickly wondering "hmmm... how can I do this as a mass-customization gig, where my speed and cost and complexity is not pushed out of control by the unpredictability of the next order versus the previous one?"
In designing that thing, you'll clearly have to run the gauntlet of politics, property, ambiguity, and risks.
It's amazing how much knowledge it's going to take to manage knowledge!
Wherefore, my two impertinences of the day:
#1 - "When information is free, only bums will have information." (Original, thanks.)
#2 - "A fool with a tool is still a fool." (Borrowed that one.)
Don't let this happen to you!
Posted by Malcolm Ryder at 3:00 PM | Comments (0) | TrackBack
May 9, 2005
Returning to Return on Investment
Not being an economist or statistician has its small virtues when talking about value. One of the best virtues is an undaunted respect for the ability to say that something is valuable without needing to qualify it other than logically. This is what I've always thought of as the difference between ratings and metrics. Both are cases of "measurement", but a metric needs a standardized rule and a rating only needs a non-standardized preference.
So who cares about this? People who like gift boxes full of ROI. They don't like ratings when what they want is metrics.
It seems to me, though, that the point of ROI metrics is still to wind up with a preference, namely, to have a certain amount of value of a certain kind, above and beyond what value you think you gave up (i.e., invested) in exchange.
This makes it easy to lean on a logical definition of ROI instead of necessarily a mathematical one. That is, where does ROI actually come from?
If there is some kind of property for which you have "ownership rights", you can treat that property as an asset. Once you give the asset a job, then you can treat it as a resource. This assignment is also the point where you can first say that you've made a specific investment.
The purpose of the resource is the next important issue. The purpose is all about what yield should be obtained from the utilization of the resource. The yield represents the type of benefit targeted.
But the yield is valuable only due to the event that it can address. The event is a type of condition that the benefit can affect. The effect that the benefit has in the occasion of its influence is the return.
For example, let's say that there is a rusty chest believed to contain important memorabilia and some expensive antiques. If someone gives me ten dollars with permission to use it, I virtually own the ten dollars (an asset). If I spend the ten dollars on a hammer, I've created a resource (the hammer). Then I use the hammer to open the rusty chest (a benefit), with the understanding that I'll be rewarded for opening the chest. The reward can be 20 dollars for getting the chest open, or ownership of the contents of the chest. The value of the contents of the chest is monetarily (we presume) either greater than the original ten dollars or not, but at this point the issue is the importance of the kind of value that the contents have for me. Would I rather have the contents, or have the ten dollars back with ten more to spare?
This simple example shows that the "ROI mechanism" is to:
- create a resource from an asset, then
- use the resource to create a benefit, and then
- offer to redeem the benefit to gain new value, and finally
- select the type of value to accept in ultimate exchange.
Logically this would always be the pattern. Circumstantially, meaning in any given instance, you may not have many choices in the amounts, types or occasions involved in the mechanism, and this might make the whole affair seem to involve fewer steps and options. For example we often automatically think of an asset as a resource because we think of assigning the asset to only one purpose (even though it could be assigned to a different one). Or we don't seem to have choices of rewards so we think of the benefit as automatically provoking a certain kind of value, which makes the benefit and the value synonymous.
Experience shows that these "abbreviations" are ideas that we choose to have instead of facts. The logical facts allow for circumstances where the number of options at any step is somewhere between zero and more than zero, but the step is still always a part of the mechanism. We might not be aware of it until someone comes into the picture with a different agenda and an ability to add or subtract options from a step. For example: you can typically do that with "efficiency measures" (subtractions) or "contracts" (additions).
People like to "maximize ROI" and they may have various reasons (or requirements) to do so. The ROI mechanism just described also shows, perhaps more importantly, that there are a number of points at which decisions might be made to adjust the effectiveness of pursuing a desired return. It also shows a mechanism that can take only minutes or might take years. The difference is in the details of executing each step, and in the progress made to align each step with its subsequent one. In the Archestra view, this is the basis of the need for what we call "ActiveROI".
For more info on the illustration below, contact me via email...
Copyright 2004 M. Ryder
Posted by Malcolm Ryder at 1:20 PM | Comments (0) | TrackBack
May 4, 2005
Revisiting the Operations Trinity - People, Process and Technology
The "holy trinity" of operational effectiveness has, and will go on having, a long tenure. Getting people, process and technology working together is the goal and advice of nearly every expert on business systems; and it's one of the most familiar mantras of management.
The conventional advice about coordinating this triplet is the kind of expertise that is more recounted experience than it is privileged knowledge. What it describes is predictable "common sense" from the point of view that effective business action results from careful process designs being operationalized by the right people using technology appropriately. This is a familiar line of sight.
But in an alternative and somewhat more formalized view, people, processes and technology are each considered "business assets" that need to be managed. Company departments want to "own" stuff. Their logic for dividing responsibilities and authorities into sub-units of the organization presses forward a requirement to control the internal distribution of enabling assets -- even moreso than effective business action calls for the integration of the assets. Ironically, this "control" creates inconsistencies and silos that frustrate enterprise visibility of resources. Additionally, it leads to duplication of efforts to integrate them as described above.
Although those "component" integrations and "asset" allocations each have a loose end of their own, they are often believed to be resolved with each other in settling the question: "how do we get 'finance' to support 'engineering' ?" This kind of reconciliation produces some number of agreements indicating what to worry about no further or what need not be fought over. A balance of political and economical concerns might be struck. But that doesn't instruct on how to align our famous triplets for successfully driving business value...
Mixing Apples and Oranges
Thus, despite the easy rhythm of the mantra, its suggested coordination can't be taken for granted.
Here's a third problem: processes are complex constructions created by the business, that institutionalize certain behavioral characteristics of the business.Unlike people and technology, processes do not simply arrive autonomously intact into the business action scenario. So, to "align" them with people and technology, how do we proceed? What transformations are necessary in order to blend them together?
These days, thanks to ASPs and "built-in best practices", we're tempted to think and even say that most processes actually are selected off the rack and then tailored to the business. In that way, it appears that processes are in an asset class that also includes already-skilled people and pre-formulated technology. The idea is that the business doesn't design people or technology, and increasingly it really doesn't design the process either -- rather, it chooses, customizes and "implements" all three of them.
But to hold that position, it's necessary to be fairly explicit about what is covered by each term. For example, is "technology" supposed to include homegrown applications, printers from HP and hammers from Sears? With that breadth, talking about coordinating technology with processes and people doesn't advance any particular idea very much in the direction of better management. Instead, it just reiterates the common-sense awareness of a need -- namely, to somehow organize their interaction in an accountable way.
Ordinarily, the advice regarding blending these items does specify what form of each one is in question, and go on from there to promote a coordination methodology. The point is that we have to decide what each term of the holy trinity really is or really means, before we can know what to do about it.
We know that each term attempts to identify an essential building block of a capacity to operate (on business requirements). Each term of the triplet is at least a placeholder for some fundamental item.
What if we logically "normalize" the people/process/technology triplets, so that the scope of each placeholder is inherently comparable to that of each other's? Wouldn't that generally help clarify what kinds of management will be called on to guide and sustain their coordination? Let's try.
Processes are actually complex constructions of choreographed events. In effect, processes are a description of how to use events based mainly on where and when they should occur.
Likewise, the choreography of people describes how their positions relative to each other are "prefigured" to support certain interactions. Assignments create this arrangement.
Choreographing technology means deploying it in a way that its on-demand availability gives real-time support for functions. Configuration prescribes this situation.
Coordinating levels of management
Those observations give a new version of the triplet to use: People/Events/Technology is the new component-level triplet. Once we start this, we can follow suit as in the chart below, which summarizes the overall business view of the architecture for operational business value:
Copyright 2004 M. Ryder
Assignments/Processes/Configurations become infrastructure-level identifiers related to the more "atomic" elements of people/events/technology.
A key outcome of that "normalization" is that it clarifies the management coordination steps up to the necessary levels of value, such as a third level -- a production level -- where Relationships, Operations and Resources live. This is the level on which the business starts defining the conditions that strategically support the type of opportunities it deems "valuable" (or literally, value enabling). But stepping up to this level is not just a simple matter of promoting "assignments" as relationships, "processes" as operations, or "configurations" as resources.
Instead, relationships, operations and resources are each perspectives, with each given perspective addressing all three of the elements on the level below. Relationships present requirements to the coordination of assignments, processes and configurations. Likewise, Operations present requirements, and Resources yet another set of requirements.
The requirements are generated from objectives that have been established for each of the perspectives. The objectives represent the business's idea of how it can develop and sustain advantaged positions for growing and changing -- or in other words to benefit from competing, from producing, and from consuming or exchanging assets. This points to one even higher level of consideration.
At the fourth and higher level of concern, we find the business defining itself as an entity, through identifying Accounts, Services and Portfolios -- managing them separately and in relation to each other, for bridging market-level demand and supply.
Here again, each higher level item is a perspective on all of the items in the level below. Accounts establishes an agenda for relationships, for operations, and for resources. Likewise, the Services and Portfolios perspectives establish their respective agendas for each item in the level below.
Posted by Malcolm Ryder at 10:35 PM | Comments (0) | TrackBack
May 2, 2005
Driving Strategy to Success
Executives and business experts are generally agreeing that improvement in profitable competitiveness must now come from taking measures beyond cost-cutting. Profitable competitiveness is their basic idea of good performance. It reinforces the idea that the business should organize how it competes according to the chance of profit; so, changes in the perceived sources of profit should change the competitive strategy.
What should stay under very close examination, naturally, is the idea of these "profit sources". In one view, the strategy should actually create and/or secure the sources; this is a fundamental part of understanding the quality of the strategy. Another part concerns how usable the strategy is by the organization, for the purpose of creating and securing profit sources.
Accordingly, as the conventional idea of performance management goes increasingly mainstream, what we see talked about is that companies are increasingly concerned with the ability to "execute" the strategy. Naming the problem in that way intuitively makes sense, given the outlook described above. But to solve the problem, it first needs to be defined in a different way.
To begin the redefinition, let's dump the word "execute" and use the word "drive". To illustrate why this makes sense, let's imagine that we're competing in a autorace on a difficult closed-loop track. One of the key things we need for success is a car that "handles" well enough for us to actually make each section of the track "conform" to what we need to get out of it. For example, a steeply banked curve is an area where a poor-handling car will fail to keep us positioned the way we need to be throughout the curve, and we may fly off the curve against the crashwall or at least lose crucial time recovering from poor position in the curve. But in an excellent example of relativity, a great-handling car is said to "flatten" the curve because it can hold us in the optimal position throughout the entire curve, for least risk and highest speed (combined). The great thing to see about this is that although the actual physical curve of the track does not change shape in either case, the effective shape of the curve does change along with how we can handle it. Our great-handling car re-shapes the curve to our needs.
Strategy is like that great-handling car. With it, we can reshape the entire "track" into an optimum competitive environment. But that assumes our own compatibility with the car, which in turn assumes that we are ourselves capable of operating the car appropriately.
If performance is a measure of profitable competitiveness, and we rely on strategy to establish that performance, then the strategy's reliance on our operational compatibility and capability is clearly 50% of the "source" of the competitiveness. The strategy is designed to reshape the environment (so there's the other 50%), but that effect won't occur if we, the driver, do not or cannot use the strategy in accordance with its design.
So, let's use that conventional working definition of "performance", in which managing performance improvement means increasing profitable competitiveness. That means doing something that might best be called co-opting the strategy. Literally, to co-opt means "to take or assume for one's own use; to appropriate..."
This idea includes a couple of great things that are useful to us. For one, it immediately suggests that a good strategy can be built, bought or borrowed; naturally it can be home grown but it doesn't have to be.
The other thing is even more interesting: think of "co-opt" as relating to the strategy through a combination of "co-operating" with it and "adopting" it. To co-opt a strategy, you cooperate with its intent and you adopt the strategy's attitude towards the environment that it wants to reshape.
Now we see the issue of strategy in light of a more tangible performance management agenda. When the organization's behavior shows that the organization wants to do what the strategy wants to do, the organization is driving the strategy, and the profitable competitiveness premised (if not promised) by the strategy is more likely to be demonstrated.
For managers, seeing that the organization drives the strategy is probably a much more important perspective on things than is the evangelical idea that "strategy drives the organization."
In co-opting the strategy, cooperation with the strategy's intent must be a desire of the organization, and this is likely cultivated through incentives or there will be much less persistence to it. However, adopting the strategy's attitude towards the business's operating environment is even more essential, since this attitude is what reshapes the environment to the business's purpose. The reshaping is where strategy actually creates and secures the sources of profit. Without adoption, no strategy can take credit for any success. Thus, strategy adoption is something that must be at or near the top of a manager's agenda, and we must develop clarity on how the particular and various managers should actively and practically repond to that priority.
Posted by Malcolm Ryder at 7:56 AM | Comments (0)
May 1, 2005
When is a Model not a model?
Usually we develop a "strategy" based on other ways of organizing our observations. But this gets tricky. We are all the time seeing things called models that are not models. Likewise, we see so-called frameworks that are not frameworks, and so-called processes that are not processes.
Two other typical confusions compare models against frameworks (apples vs. oranges), or offer a hybrid of a model and a framework, to provide "valid" grounds for the strategy.
The toughest test of a framework, model or process is its ability to tell you how to make something that works the one chance you have to make it.
With that in mind, navigating through the variety of misnomers and mismatches is a prerequisite for developing strategy and for managing performance.
Here's the basic lay of the land:
- The Framework is where the value system for construction is defined.
- The Model is simply an application of the value system to a proposed circumstance.
- Plans then translate the model into an actual circumstance.
- Programming is like planning. Programs create and relate functions.
- Functions are executed by processes using instructions.
- Following instructions is when the rubber meets the road.
The whole point of applying a strategy is to logically drive results of intended value, but the intended impact of the strategy arrives only as the payoff of other underlyng levels of success. Although frameworks and models are offered to guide construction of strategic solutions or improvements, strategy is more like programming than it is like frameworks or models. Essentially, the guidance supplied by frameworks and models promises the effectiveness of the programming in the context that the framework or model inhabits. But the faithfulness of the program's processes to its instructions, which greatly depends on the run-time environment of the processes, will always be challenged by some degree of risk, so the design of the process must make risk management an integral part of its quality.
A key point to sign off with here is that processes must negotiate with their environments, consequently they really only "interpret" instructions. However, depending on the circustances, that interpretation might be quite literal or might range to the very improvisational. The difference is meaningful in terms of control, cost, repeatability and other aspects, but the process always finally has one main responsibility: to produce the targeted output. Organizational tolerance for the methods of the particular process may allow or disallow the use of that process, but this is what process management is for.
Posted by Malcolm Ryder at 8:35 AM | Comments (0) | TrackBack