Business model maturity

desel_051

The core model that most people use to explore and articulate the motivation, offerings and capabilities required to pursue an enterprise is the business model. This article explores our perceptions of the evolution of the business model artefact through four phases which we have named as versions (1.0, 2.0, 3.0 and 4.0).

Business model 1.0

This “version” encompasses the origins of business models, which were financial models reflecting the expected revenues for products and services being offered, the expected costs of producing, distributing or providing, and maintaining the products and services, and the resultant profits realised as a return on the investment made in establishing and operating the proposed business.

business-graph-with-arrow-showing-profits-and-gains_MyZdKgKd_L

This model would be reviewed and revised as:

  • opportunities or threats emerged in the market
  • product / service offerings could be extended, refreshed or reduce
  • improved efficiency and effectiveness needed to be or could be pursued

Business model 2.0

The next version emerged in the dot.com era and was formalised by Alex Osterwalder in his work and articulation of Business Model Canvas. This work established an ontology for the business model, in terms of the domains of information that required attention and articulation, covering:

  • Customer segments
  • Channels
  • Relationships
  • Key capabilities
  • Partners
  • Cost structure
  • Revenue streams
BMC

This ontology and associated tools have seen widespread adoption, with consulting services available to support startups through to large corporates in developing an expression of their business model(s).

Business model 3.0

This version takes the concepts in Business Model Canvas and extends them further based on a systems view of an enterprise and the environment in which it operates.

This encourages greater attention to the enterprise-as-a-system and the enterprise-as-a-part-of-broader-systems. In doing so, attention is given to:

  • the broader value chain of which an enterprise is part
  • the potential for enterprise suppliers to provide services directly to enterprise-customers (circumventing the value proposition of the enterprise)
  • the creation of new market dynamics through adoption of market platforms, shared economies and other market disruptions

This evolution explores these dimensions as they apply to the dynamic relationships which exist in the market environment, as shown in the following figure.

Systemic-business-model

Business model 4.0

The fractal application of business model might entail development of the business model for:

  • an organisation
  • a marketing capability
  • a production capability
  • a supplier chain capability
  • a corporate wide capability (eg. people management)

exploring the dynamics arising from the application of business models to enterprise-subsystems, enterprises-as-organisations, and multi-organisational enterprises.

Fractal-business-model

In practice, this requires an iterative approach:

  • to the application of business models and operating models
  • each component of the operating model being considered an enterprise-in-focus to which the next level of business model and operating model is applied

which effectively constitutes an objective – strategy cascade where:

  • business model establishes the objective(s)
  • operating model establishes the strategies

Maturity

Use of these models can be considered in terms of maturity, starting with a simple financial model (level 1) and eventually maturing to integrated application from individuals to the Board (level 4).

At what level of modeling maturity:

  • do you operate as a leader for your role and your team?
  • does your organisation operate?
  • does your industry or region operate?
  • does your nation operate?

This outlines the essential elements of the manner in which business model development is applied in any circumstance that we encounter.

 

Architectural sufficiency

This article is a republishing and updating to reflect some thinking which emerged in the comments when the original article we published in early 2016 – here is a link to the original article

One of the questions that I posed in the opening posting of the series that I started at that time was:

How would we go about describing the current or intended architecture of our enterprise?

Common models and views

In another posting about conventional practices, I indicated that the development of organisational charts and position descriptions were one of the current practices undertaken in many enterprises.  What other models and views do we develop to describe the current or intended architecture of an enterprise?

The next most common model and associated views is the process model.  This can be prompted by a range of motivations, including:

  • A continuous improvement program which encompasses the progressive development of process models for various subsystems within the enterprise
  • A quality management program, potentially in conjunction with adoption of standards within the ISO 9000 series, where the Corporate Management System or the Business Management System provides shared access to the processes developed to ensure a consistent approach to deliver of quality products and services
  • An information systems or IT system program which is establishing improved processes and/or IT enabled processes which need to be described to support the design and realisation of the proposed system

In the latter case, it is likely the information models and views will also be developed to reflect the way in which the shared information is to be organised, managed and accessed.

Key dimensions

What other dimensions of an enterprise are part of its architecture description? Various models suggest the following dimensions are encompassed:

  • People / roles / organisation units
  • Process
  • Information
  • Assets (offices, plant, equipment)
  • Finance
  • Information and communication technology (ICT)

These seem to be the primary:

  • resources
  • integration points

which can be encompassed within an architecture which has a focus on elements and relationships which are fundamental to the enterprise-as-system.

Other elements

There are other elements which are not owned and controlled and hence not designed and architected which feature in architecture descriptions, as there is a need to understand relationships, flows and interactions, both internal and external.  Hence, architecture descriptions will reference external entities, including:

  • Customers and consumers
  • Suppliers
  • Partners
  • Competitors
  • Regulators

This is an important feature of architecture descriptions and enterprises.

An architecture description includes reference to entities and relationships beyond the bounds of the enterprise

This has proven to be a point of considerable debate and confusion surrounding what I perceive to be the failure to appreciate the distinction between the scope of the enterprise and the scope of the architecture description.  The latter must convey information about the enterprise-as-system “in its environment” and necessarily includes entities beyond the scope of the enterprise.

Sufficiency

Do we have a sufficient coverage of entities and relationships to encompass the description of the architecture of our current and intended enterprise?  Are these sufficient?

The ultimate test, based on ISO 42010, is whether these provide all the necessary elements to address stakeholder concerns arising in considering the current or intended architecture of an enterprise.  In my experience, these have been sufficient.  I leave the question open as others may find my list incomplete.

With these foundations, we can now explore the models and views which seem to prove most useful across the range of architectural engagements in which I have been involved.  This draws me back to elaborating further on a number of the models that I listed in the posting about the elements of architecture descriptions, including:

Postlude

A key message in this posting on current practices is exactly what Doug McDavid said in a comment.

Executives and Managers create various elements of the architecture description already.

They are prescribing and describing the architecture, whether they realise it or not and whether they call it architecture or themselves architects, or not. What I have not said explicitly, but is implicit in this series, is in line with his linked article, is that aspects of the architecture become evident in various enterprise documents, and therefore can be discovered and, if necessary, made more explicit.

For example, principles are often implicit in business language and business documents, but few enterprises make the principles underpinning their enterprise explicit. Similarly, language and key concepts, commonly found in enterprise documents, may well reflect important elements of process and information architectures. A couple of colleagues have experimented with tag clouds as a tool for more rapidly identifying elements of the enterprise ontology.

A number of articles will be written over the next few weeks, expanding on key principles underpinning the practices that I have found most effective in supporting Directors, Executives and Managers to better architect their enterprises.

 

Organisations and enterprises

Many words have been written and many said about organisations and enterprises, and the extent to which they are the same or different.  This article is prompted by a current “debate” over the meaning of “enterprise” and a suggestion that “enterprise” is distinctly different to “organisation”.  I am not so sure about that!

So, this is part of my “normal process” of “thinking out loud” – an approach where I:

  • outline what I currently “think”
  • refine what I think in order to express it in a clear and coherent manner
  • expect to be challenged
  • am offered the opportunity to refine my thinking, based on the questions and challenges arising from articulating my thinking

For me, this is the way I have become better at understanding, articulating and practicing the disciplines of architecting enterprises, governing enterprises, becoming more systems savvy, and of recent times, becoming more brain savvy.

Organisations

In using this term, it is important to distinguish between organisations and legal entities.  Oftentimes, when I think of organisation, I am thinking of:

  • a commercial firm
  • a government department
  • a community entity

This pertains more to the legal status of the entity and to the basis upon which it is constituted, managed and governed.

In this discussion, whilst it includes all of these types of organisations, I am including other forms of organisation, including:

  • an organisational unit
  • a cross-functional team
  • a multi-organisational operation
  • a community
  • a region
  • an industry
  • a profession
  • a project
  • a program

Each of these groups have:

  • membership
  • bounds
  • shared interest and purpose
  • varying degrees of linkage and relationship
  • an existence for some period of time
  • some form of means by which they are “organised”

So to the definition of organisation

an organised group of people with a common purpose

Enterprise

A number of blogs have been written on this topic already, including:

In summary …

an enterprise is most easily understood as an undertaking or an endeavour

Context

Given a systems view of organisations and enterprises, it should not be surprising that there is a need to consider system context, including:

  • the market or environment in which the organisation, enterprise or system exists and operates
  • the economy, community and society within which the market and environment exists

Any organisation, enterprise or system will need to:

  • give attention to entities in these broader contexts
  • understand the relationships that exist or should exist, both
    • across the organisation / enterprise / system boundary, and
    • amongst entities in the external environment
  • adapt the structure and behaviour of the enterprise, both
    • in light of changes in the external environment, or
    • in order to shape and prompt changes in the external environment

These activities are evidenced as an inherent part of organisations through:

  • governance processes (attending to accountability and strategy)
  • intelligence processes (informing the organisation of activity in the external environment)
  • marketing processes (understanding changes and opportunities in the external environment)
  • supplier, partner, customer / consumer, regulator and other stakeholder relationship management processes (providing direct knowledge and understanding of key external relationships)

These represent the means by which organisations attend to life-beyond-the-organisation and about which organisations develop enterprise models to enable them to understand, architect and realise their intended business models and operating models.

In this respect, the business model is the key artefact which prompts understanding and articulation of the balance required between internal and external affairs (so to speak).  Further articles outlining key thinking and practices in this area, include:

Enterprise concept and views

There are a range of benefits that I see arise from taking an enterprise view of an organisation, including:

  • organisation tends to prompt a people / role based view
  • enterprise encourages a purpose and process view
  • enterprise allows the balancing of multiple views including:
    • strategic views
    • process views
    • role / responsibility views
    • information views
    • facilities / location views
    • service views (composite of internal and external sourcing)
    • integration views
  • enterprise provides an abstraction from the connection to organisation and the threat that arises in considering organisational change
  • enterprise enables views that are agnostic to a particular dimension

For me, there is incredible value in taking an enterprise view, but none of the value derives from viewing organisation and enterprise as distinctly different.  Perhaps the following is a reasonable way to summarise?

Enterprise is an abstraction that is orthogonal to organisation

 

Bringing it all together

STORYB~1.JPGOver the last two and a half years, I have written and published over 50 articles which relate to architecting and transforming enterprises.  These have been published on LinkedIn and an index of all articles maintained in the article “Architecting Enterprises“.

About twelve months ago, I started copying these articles across to this blog site.  As I did that, I published a post on LinkedIn which proved to receive far greater views than many of my original articles.  In parallel, Interface Consultants started holding public Lunch’n’nLearn events where I was using content from these articles in sessions on:

  • Curious about being more brain and systems savvy
  • Bootstrapping a systems savvy enterprise
  • Cultivating capabilities
  • Diversity, coherence and assurance (for Boards)

Reflecting on the development of these sessions and on feedback from these sessions, it became evident to me that participants in these sessions and readers of this blog need a sense of:

  • the whole story and how the fifty (or more) articles fit together
  • how to find the pieces of the puzzle that are missing without need to read all the pieces that they already know and understand

This is how the process of “bringing it all together” started.  It has led to:

Further content is being developed and will be released.  I hope this becomes an increasingly convenient, easy-to-use, valuable resource for those involved in transforming their enterprises and looking to advance their mastery of this highly rewarding activity.

Feedback on the articles and on this initiative to “bring it all together” is always welcome.  Please feel free to post comments or to contact Interface Consultants or Peter Murchland if you wish to respond privately.  These articles are also used to prompt discussion in the related LinkedIn Group – Enterprise Modeling

 

Enterprise design mantras

mantra-om-mani-padme-hum_zkPVd0Lu_L

What mantras do you find underpin your AE practices? Are there particular principles or guidelines that you remind yourself about or that you share with others in your team and amongst your stakeholder community?

Here are some of the mantras that I find myself repeating …

  • Keep the end in mind
  • Business process not system process
  • Continuum between autonomy and control
  • What is the system-of-interest?
  • What constitutes success?

Keep the end in mind

Many of us are trained to determine our objective and then explore the strategies for achieving the objective – determining the ends and exploring the means. So what is important about this mantra? Isn’t it a natural part of our daily practices?

Many years (actually decades) ago, I read “I’m right, you’re wrong” by Edward de Bono. I gained a number of insights from that book, but the most frequently referenced insight was:

creative ideas are logical in hindsight

This insight is important to solving problems and to learning. Once solved or learned, the problem seems simple. This can also mean that a solution can be more easily understood by working backwards rather than forwards.

This simplicity is often overlooked when we present the problem and solution to stakeholders. It all seems logical to us but can seem puzzling and difficult to our audience. This applies in many different scenarios, including many of the business improvement or business transformation undertakings I have encountered.

It was recently brought to mind and reinforced by a colleague sharing that they read books backwards – last chapter first. Another practice is that of describing what I aim for meeting participants to have gained at the end of the meeting – shared understanding, agreed actions, etc. This often helps construct are more effective sequencing of the agenda.

clarity in relation to goals, deliverables, and outcomes

has proven to be a valuable practice – keeping the output and outcome in mind as we design and plan our way forward.

Business process not system process

I have lost count of the times that I have encountered IT projects where the focus is on the IT system and not on the business objectives which the IT system should be designed to support.

Indicators of an inappropriate focus include:

  • A project scope expressed in system function terms rather than business terms
  • A “process” diagram which is focused on the interactions with the system and the “system processes” without attending to the “business processes and practices”
  • A project with system deliverables and few or no business deliverables
  • A project which regards business change as “out of scope”

Practices which have proven to prompt greater clarity and quality include distinguishing between:

  • business objectives, system objectives and project objectives
  • business scope, system scope and project scope
  • business processes and system processes

The first two areas typically apply in the initiation stages of a project, where as the third arises at various stages in the project, and hence is the distinction that is more frequently made (and needed).

Balancing autonomy and control

For any situation where alternate processes or means are being considered to achieve an agreed objective, consideration often needs to be given to the nature of the circumstances and the type of action or response that might be needed.

For example, if the situation entails lots of variability and unknowns, then it is likely to need a person to determine the nature of the situation as well as the appropriate action. Significant autonomy should be given to a person to determine and take the appropriate action. This is typical of situations that are described as being “knowledge work”.

There are other situations where it is possible or it is necessary to be prescriptive and for specific consistent action to occur. Situations such as ensuring consistent counting rules are applied to an information set, or where financial transactions need to be processed in a consistent manner. These situations call for appropriate control to be applied, with no need for flexibility or autonomy.

Redesign of processes requires careful consideration to the areas where autonomy versus control is required and how to design a process to achieve the appropriate balance and combination of these responses.

Be clear about the system-of-interest

Enterprises are complex. Enterprises can be viewed from the perspective of being a system-of-systems.

If one considers a system-of-systems, we have the situation where:

  • the whole is a system
  • the parts are each systems
  • some parts may be systems-of-systems

In addition, there are human activity systems (social systems or soft systems) and technology based systems (machines, computers, etc or hard systems). Given the pervasive use of IT systems, many times “system” is taken to be a synonym for “IT system”, making it more difficult for some to consider the “system” being a social system or socio-technical system.

If systems based views and techniques are to be applied successfully, it is important that those engaged are considering the same system – that the system-of-interest is clear, as it may be part of a containing system, and it may be composed of parts-as-systems. Oftentimes, I have found that the differing views or confusion being experienced in analysing or diagnosing systems has arisen because different stakeholders are holding a different system as the focal point.

Being clear about the “system-of-interest” or the “system-in-focus” ensures that the differences emerging arise from different perspectives, perceptions and conceptions of the system-of-interest, and not through a difference in the point of focus.

What constitutes success?

This is a valuable question that I learned as a Director on a Board, but is equally applicable in other settings. Similar questions are sometimes asked such as “What does good look like?”

Such questions draw us to being clear about outcomes such that then we can consider the differing outputs that might be required to realise the outcome and the alternate processes (and strategies) which might be pursued to deliver these outputs.

Exploring enterprise lifecycles

Wherever an enterprise engages in architectural activities, there are three key lifecycles which come into play:

  • enterprise operations, managing the entire lifecycle from prospective customer to satisfied customer
  • enterprise development, managing strategy, innovation and change, delivering and embedding new or improved capabilities within enterprise operations
  • enterprise architecture, managing the structures and principles through which enterprise operations and development are effected

Enterprise-development-1

Any engagement needs to assess:

  • the current position within these three key lifecycles
  • the maturity of the organisation with respect to each of these lifecycles

in determining where to direct efforts to deliver the greatest value to the organisation.

EM_journey_v0-15

In this respect, the approach shown above for architecting enterprises provides an effective mechanism for managing each of the lifecycles, prompting an assessment and appreciation of:

  • vision
  • future directions
  • capability gaps
  • initiatives addressing gaps
  • program (roadmap) of activities in train

This could lead to three inter-related capability development cycles for maturing the enterprise architecture capability, enterprise development capability and enterprise operations capability.

Enterprise-development-2

Where is your organisation placed in terms of its architecture, development and operations maturity?

To what extent does your strategy development take account of your maturity in these three domains?

To what extent does your program planning and execution explicitly take account of these differing levels of maturity, including:

  • delivery risks arising from varying maturity levels?
  • adaptive approaches which allow for the necessary enterprise learning required for successful delivery?
  • synergies which can be pursued to leverage investment and effort towards enhancing maturity in all three domains?

Being more systems savvy

What questions does this title prompt?

  • What is meant by “systems savvy”?
  • How systems savvy am I?
  • How systems savvy are the organisations of which I am part?
  • What is the value in being (more) systems savvy?
  • Why should I bother thinking, reading or trying to be (more) systems savvy?

Being (more) savvy

Let’s start with some synonyms for “savvy”

shrewdness, astuteness, sharp-wittedness, sharpness, acuteness, acumen, acuity, intelligence, wit, canniness, common sense, discernment, insight, understanding, penetration, perception, perceptiveness, perspicacity, knowledge, sagacity, sageness

“savvy” reflects the degree to which we understand “things” and can apply our knowledge and understanding to “things” and how we create, maintain and use these “things”.

Systems

Now, what about “systems”?

“systems” are one of the common ways in which we make sense of “things”, how they work and how to change how they work. In one respect, “systems” are a figment of our imagination. Why do I say that? Well, often different people view, describe and understand the same “system” in different ways. Lots of systems are sufficiently large and complex that we can’t know all that there is to know about the system. What we know about the system is influenced by:

  • what we know, in general
  • what we observe and experience in seeing and interacting with the system

Since that is different for each person, it is not surprising that the same system can seem different to different people. Hence, I find it helpful to appreciate that others probably have “a different system in mind” than the one in my mind.

Systems savvy

So, when we speak of being systems savvy, we mean that a person appreciates the finer points of understanding, designing, realising, and operating an entity through the lens of “systems” and is effective in designing, realising, operating, maintaining and changing “systems”.

Here are a couple of critical elements that are brought to bear in thinking about systems:

  • every system is part of a bigger (containing) system
  • many systems include feedback mechanisms

Every system is potentially part of more than just one containing system, prompting us to consider how a system-in-focus must operate in the context of being a part of a greater whole, where the other parts impact on the system-in-focus as much (or sometimes more) than any change to the parts of the system-in-focus might realise.

The feedback mechanisms enable the system to adjust to external factors over which the system-in-focus may have no “control” ie. they are open systems (when often “closed system” thinking is applied to their design and operation).

In particular, we also mean that a systems savvy person appreciates and practices the finer points relating to “social systems” – systems composed of people. Why? Because there are a number of critical differences between social systems and other systems.

Social systems

There is much to explore and understand about social systems – hence, our interest in continuing to:

  • explore new territory in this field
  • apply our learnings
  • share our learnings

Here are a couple of the most critical differences from our perspective. Social systems are:

  • self-designing, self-realising, self-operating, self-maintaining
  • reflective of how we make sense of the way in which we work or should work together
  • often the means by which we conceive, design, realise, operate and maintain other systems

Further elaboration on social systems is provided in a separate article.

Being brain savvy

Given that systems exist in our minds, as we learn more about how our minds work, we have the opportunity to change how we deal with systems in our minds.

Understanding more about how we think, feel, act and learn and applying this understanding is what is encompassed in being “brain savvy”.

So, we are interested in:

  • being more brain savvy
  • enabling us to be even more systems savvy

A range of different elements that are important to understanding systems, and how we govern, design, realise, operate and change them are explored in other articles, which can be found in this index.

Who are we? We are Associates with Interface Consultants. We offer services aimed at helping clients become more brain and systems savvy.

Interface Consultants are holding a lunch and learn event on being more brain and systems savvy. Further details are available on EventBrite.

Reducing enterprise dissonance

Have you thought about the degree of dissonance that exists within your enterprise?

Have you considered what the cost of this dissonance might be to the performance of your enterprise and its future success?

Have you identified where the greatest points of dissonance exist in your enterprise?

Have you considered what you might do to reduce dissonance in your enterprise?

Exploring enterprise dissonance

You may not have considered the concept of “enterprise dissonance” before now. It was prompted by thinking about enterprise integration, wholeness and harmony, and contemplating potential antonyms. Here are several definitions for dissonance that you might use to reflect on the dissonance within enterprises with whom you are engaged.

Dissonance: lack of agreement or harmony between people and things

Dissonance: conflict or incongruity

Dissonance: uncomfortable sense experienced by people in the midst of change

Assuming you do recognise the existence of dissonance in your enterprise. What are the causes of this dissonance? What might you do to reduce the degree of dissonance (assuming that it is an unnecessary overhead and impediment to enhanced enterprise performance)?

Diagnosing enterprise dissonance

One of the key causes of dissonance, in my experience, is that people hold different models of the enterprise, the environment in which it operates, or the parts of which it is composed. This prompts engaging with enterprises to explore:

  1. the explicit models that the enterprise is using to describe itself or its intended self
  2. any gaps or inconsistencies that might be evident in these models
  3. any gaps or inconsistencies between current capability and intended capability represented by these models
  4. any gaps or inconsistencies that might be evident between the implicit models that are evident in how leaders think, communicate, decide and act and the explicit

Any of these gaps or inconsistencies can be the cause for enterprise dissonance as people:

  • unknowingly act in differing and conflicting ways
  • respond to demands which expose gaps requiring immediate response without the opportunity to agree the manner in which the issue should be addressed
  • intentionally take actions to further personal or group goals and aspirations which may not be consistent with enterprise goals and aspirations

Dealing with enterprise dissonance

Having identified critical gaps, the enterprises are more readily able to develop a more integrated set of models on which to base an assessment of capability gap and a transformation plan to address the priority gaps.

Many enterprises have well established approaches to business transformation planning and capability development. The more critical issues seem to be:

  • identifying the critical gaps
  • addressing these gaps in a more holistic manner

This is where architecting enterprises, in enhancing enterprise awareness, enables enterprises to take a more effective approach to achieving enterprise integration, wholeness and harmony, thereby reducing enterprise dissonance, and enhancing enterprise performance and enterprise viability and sustainability.

These themes are explored further in the linked articles and more fully in the following series of articles (see series index).

  • Architecting enterprises – plain and simple
  • Architecting enterprises – digging deeper
  • Architecting enterprises – principles
  • Architecting enterprises – for Directors
  • Architecting smaller enterprises
  • Architecting disability sector enterprises
  • Architecting enterprises – reflections

Enterprise awareness

This article extends the thinking outlined in Enterprise Development which encompasses those capabilities required by an enterprise to support its adaptation, development, or transformation towards its intended future state. It explores enterprise awareness as a key capability within the enterprise development domain, and considers enterprise awareness in terms similar to those of individual self-awareness.

This is the first real expression and articulation of the thinking around enterprise awareness. I expect that further discussion and exploration will lead to progressive refinement and expansion of the thinking around this concept and its application to enterprises and their development. I would like to acknowledge Doug McDavid who prompted this thinking through his long-standing advocacy for the value of establishing and maintaining a repository of the architecture of enterprises.

Concept

When we are more self-aware as an individual, we are able to act in more effective ways in challenging situations. In this regard, I am suggesting that when enterprises are more self-aware, they are more able to recognise and respond appropriately to situations they encounter, whether these be threats or opportunities. In effect, an enterprise is more able to sense, respond, adapt, transform or develop:

  • than it would with lesser awareness
  • then other enterprises in the environment in which it is operating.

Application

What is required to be more enterprise-self-aware? In its most simplest form, it is to be aware of its existing and potential capability.

How often do we encounter:

  • The left hand does not know what the right hand is doing.
  • The divisions are silos with no collaboration between them.
  • Duplicated capabilities in different parts of the organisation

These and other similar situations are symptoms of an insufficiently self-aware enterprise.

What does it take to redress this situation?

  • Some minimal diligence in maintaining models and views which reflect the way in which the enterprise is organised and operates
  • A place where these models are visible across the enterprise and able to be explained and shared as part of the enterprise narrative
  • An assurance mechanism which monitors the maintenance of the models and views and the quality, integrity and usability of their representation
  • Appropriate skills and experience to provide support for this activity to occur in a sustained manner

Implementation

If this makes sense to you, you might be asking how you might explore and apply this concept to your enterprise? There are a number of minimum essential elements to consider and pursue:

  • Leadership
  • Learning and development
  • Scalability

Leadership

Developing enterprise awareness requires leadership to effect a cultural change which creates an environment in which enterprise awareness can develop and thrive.

An effective starting point is simply for the Executive team to test their own shared awareness and consistency in understanding and expressing:

  • the business model(s) underpinning their enterprise
  • the operating model for their enterprise
  • the desired culture and values for their enterprise
  • the means by which the performance of the enterprise should be assessed

Failure to be able to do this in a consistent and coherent fashion prompts serious questions as to how well others in the enterprise understand these fundamentals about the enterprise.

Exploration of the differences and development of a consistent expression with a shared narrative will then enable the Executive team to undertake this process with their direct reports. There will need to be, in conjunction with this activity, an organised way of recording the shared expression of the business model, operating model, values and principles, which can be used in common by all who engage in the progressive development of greater enterprise awareness.

Learning and Development

As the enterprise leadership engages in establishing greater enterprise awareness and greater enterprise alignment, the recognition of differences in understanding and practice are part of learning about the reality of the enterprise, and about deficiencies in its current organisation to achieve its desired goals and aspirations.

This is part of a self-discovery and learning journey. It should be treated as an open enquiry process where no participant is “wrong” and where no “blame” is attached to the existence of differences. These value arises in appreciating the differences and being able to attend to them, as they are, in part, one of the fundamental reasons that the enterprise is unable to realise its aspirations and its full potential.

Deficiencies in the current business model(s) and operating model will prompt revisiting of business strategy, which in turn will require the development and transformation of the enterprise to realise revised business strategies, business model(s) and the associated operating model.

Scalability

The approach which have been outlined can be applied to any “enterprise”. This means that it can be applied to:

  • an entire organisation
  • a division within an organisation
  • a team
  • a cross divisional function (eg. people management system)
  • a cross organisational system (eg. criminal justice system)

For each, it is entirely appropriate to consider:

  • business model (customers, services, channels, value proposition, capabilities)
  • operating model (operations, development, resources and governance)
  • culture, value and principles

For enterprises that are part of an organisation, there will be a need to determine the manner in which the enterprise integrates with other parts of the organisation. This may prompt a broader approach being taken, having determined that value has been derived in considering a smaller part of the organisation.

Facilitation

How might you facilitate the exploration of your enterprise and its self-awareness?

There are often a range of people within enterprises who are well placed to support such an activity. These include staff in the following functions:

  • Business strategy
  • Organisation development
  • Quality management
  • Business architecture

If your enterprise is not of sufficient size to have these positions, then a consultant with appropriate understanding of the architecture of enterprises could facilitate such an activity.

Enterprise guidance

In reflecting on various approaches to expressing the design of our enterprises, I have discovered an interesting common pattern as to how we provide guidance to the ongoing evolution of the design and its realisation. This article describes the background to learning about each approach and the common pattern between them.

Knowledge Ecology Workgroup

In the late 90’s, I was a member of a global, online community exploring how to articulate and engage others in understanding the generation and sharing of knowledge through the lens of knowledge ecology.

As part of the group, Mike McMasters introduced an approach to “defining an organisation” based around articulating its essence through four themes:

  • Core idea
  • Principles and values
  • Models
  • Rules

The core idea conveys the essence of what the organisation is about and around which the organisation revolves, so to speak.

Principles and values are those held dear to the organisation and which reflect and guide the manner in which the organisation thinks, make decisions and behaves.

Models reflect the manner in which the organisation will operate.

Rules are key policies that act as guidance to the manner in which the organisation will operate.

These were seen as the minimalist set of guidance that would adequately describe an enterprise and give it the freedom to innovate and leverage the resources, particularly its people and their knowledge, to the greatest benefit to the organisation.

Economic Development Advisor

In that same period, I worked with Tim Waterhouse in the South Australian Development Council, which was established to provide advice to the Government on economic development strategies. Our role was to further develop strategies for building a strong and vibrant IT industry, expanding on the IT 2000 strategies that the government has established in the mid 90’s.

Tim operated on the basis that if we shared the same vision and values, then he was confident I would make similar decisions to him in whatever circumstances I might find myself, enabling us to be involved in more activities individually, and achieving broader coverage and engagement.

I would add to this that we also shared a number of common models which underpinned our thinking and understanding of the South Australian economy and of approaches to developing a stronger and broader economy, the IT industry as an enabling industry, and government as an anchor customer.

Latest articulation of approach

In a recent article, I have explored (a little) around the vision and purpose of enterprises, and have been reflecting on the need for such statements. I have wondered whether a vision or statement of purpose is required or whether it can be derived from the business model and business strategy? I am aware that there are significant challenges in crafting a useful vision or statement of purpose (but that does not mean it should not be done). I am also aware that there are benefits in expressing the core motivation for the enterprise.

Several comments were made about the “positioning” of vision at the commencement of the approach. In a subsequent revision, I left the vision element out. Yet, there does seem to be a need for expressing the motivation for the enterprise, perhaps as that element which provides the energy, life and inspiration for pursuing the enterprise.

In reflecting on the “core idea” from my Knowledge Ecology Workgroup experience, I can see that this is essentially the expression of vision and purpose in that particular approach.

Common pattern

From these different experiences, it is probably pretty evident that the common pattern looks quite like the model outlined by Mike McMasters in the following visual.

Common-pattern

This seems to align closely with the core elements of expressing the intended architecture of an enterprise, providing guidance to the ongoing design of a self-organising, self-designing, self-realising enterprise.