Enterprises

Pain points experienced by SMEs

enterprise-modelingLeave a comment

Background

As outlined in the article on architecting small enterprises, the opportunity exists to:

  • Establish stronger foundations through well-architected small enterprises that enable them to scale and respond to emerging opportunities more readily
  • Gain experience in cultivating and managing the organisational capability portfolio
  • Harness enterprise potential earlier in the life of an enterprise, at lower cost and with greater value being realised

Motivation

This article is aimed at identifying:

  • Those points in the life of an enterprise where leaders experience pain arising from the difficulty of key “structural” decisions or from the legacy of failing to make appropriate “structural” decisions
  • The means by which they seek advice and support in resolving these difficulties
  • The search terms that they use in seeking to find appropriate advisory or assurance services

Ideas

Based on our experience in managing growth:

  • from soletrader to small enterprise
  • through the stages of small to medium enterprises
  • new divisions being formed in larger enterprises

it is evident to us that pain points emerge in the following general circumstances:

  • responding to significant market changes, requiring a change in business or operating models
  • seeking to “find efficiencies” to enable products / services to be “more competitive”
  • restructuring the organisation
  • formalising support arrangements (eg. establishing a Business Manager, or a Chief Operating Officer, or a Corporate Services function)
  • moving from informal (undocumented) to more formal (documented) business processes
  • addressing the “manual processes” that surround “IT systems” or the siloes that “IT systems” seem to have become

In larger organisations, advice and support for transformation and change will be sought from:

  • Management consultants
  • IT consultants
  • Organisational development specialists
  • Organisational and business change specialists
  • Business transformation specialists

In smaller organisations, the advice may be sought from:

  • existing relationships with accounting firms or IT service providers
  • middle-tier consulting firms
  • sole-trading business advisors
  • government funded business advisory services
  • university operated business growth researchers and academics

Questions

In light of the above:

    • What other pain points have you observed?
    • What other sources of advice have small to medium enterprises used?
    • What means have these organisations used to provide appropriate advice and support?

Enterprise babelfish

enterprise-modelingLeave a comment

Enterprise babelfish?

For those who have not read or heard of the babelfish – you can find it in Douglas Adam’s “Hitchhiker’s Guide to the Galaxy”.  Placed in your ear, the babelfish provides instant translation of any language being spoken by any alien you might encounter.

In thinking of my role as enterprise architect, business architect, business analyst, business synthesist in the many different enterprises with whom I have engaged, I realised that one of the important capabilities that I bring to bear is the capacity to understand an enterprise and the various ways in which each organisation or organisational entity thinks and communicates about themselves.

This article explores the need, nature and value of the role of enterprise babelfish and offers a different way of thinking about the role that various enterprise change professionals fulfill within the enterprises with whom they engage.

Business context and need

In any enterprise, there are special words and expressions that form part of the way in which the enterprise speaks of itself, encompassing:

  • vision and mission
  • culture and values
  • products and services
  • value propositions and differentiators
  • processes and ways of doing things

Understanding the intended meanings of these words and expressions is an important element in being part of the organisation and contributing to its operation, development, management and governance.

The larger the organisation, the more likely it is, that there are differences in understanding and articulation which result in different attitudes and behaviours, with the potential to limit the development and performance of the organisation.

Two influencing factors relate to how we use language and how we use models in our thinking and communication.  In these respects, it is helpful to appreciate aspects of:

  • denotation and connotation
  • perception and conception

The first of these was drawn to my attention by Len Fehskens.  The latter is more of a hypothesis of my own!

Denotation and connotation

For many words, but particularly for those words and expressions that reflect the essence of the identity and operation of an enterprise, there are two facets to their meaning:

  • the particular meaning that is denoted by the word or expression
  • the related concepts and expressions that are connoted by the word or expression

A simple example – wheel:

  • denotes a circular object fixed to another to enable movement
  • connotes an ability to rotate and having an axle

It is important that the appropriate denotation and connotations are formed – otherwise, a different meaning or interpretation may be made by others.

I have encountered numerous situations where different people in an enterprise use the same word or expression, but where the connotations associated with the expression they are using are quite different – to the point that the difference prompts use of completely different business processes.  In one client setting, the term “Work Pack” meant a Work Order in one Division and a Scheduled Operation (part of a Work Order) in another Division.  This difference was sufficient to mean that common systems, processes and practices were not feasible across Divisions until consistent definitions and processes were established.

As enterprises give attention to consistency in denotation and connotation of key terms and language, they are developing greater self-awareness and greater capacity to effect change and operate in a more integrated and consistent manner across the enterprise.

Perception and conception

As we encounter and interact with the enterprises of which we are part, we build mental models of the enterprise, based on our perception of how the enterprise operates.  Inevitably, we have very limited exposure to the full operation of the enterprise, so our perceptions lead to widely varying mental models of the enterprise.  This is reflected well in the story of the blind men who encounter an elephant, each describing what they have encountered based on the limited point of contact that they have.

Our perception is influenced, not only by the limited parts of the enterprise to which we have exposure, but also by the nature of the interactions we have – by what we observe about the thinking, attitude and behaviour of leaders, managers, peers and others.

Another element to our understanding of any enterprise relates to our conception of the enterprise – the model that we build of the entire enterprise, based on inputs such as:

  • corporate documents espousing vision, mission, purpose, objectives and strategies
  • organisational structure, policies and other elements describing how the enterprise is organised
  • similar materials available for each of the organisational units of which the enterprise is comprised

This enables us to develop a “high level” model or “conceptual” representation of the enterprise.  Not surprisingly, there can be significant gaps between our conception and our perception of the enterprise.

Barriers to understanding

There are a number of barriers to shared understanding, including how we deal with and think of our enterprises.

Systems

Organisations and enterprises can be conceived as systems-of-systems. This, in its own right, leads to numerous views of interwoven systems.  One only needs to consider a generic, high level operating model (see related article – Operating models) to appreciate how many systems might exist in any enterprise.

The vast majority of organisations entail human activity in combination with supporting technology, introducing considerations in relation to:

  • Human activity systems (HAS)
  • Information systems used by these HAS
  • IT systems and other technology based systems also used by these HAS

with a long history of difficulties in designing and implementing an effective combination of HAS / IS / ITS / TBS which effectively enhance enterprise performance.

Add to this that systems can be conceived of through conceptual models, designed through logical models and implemented in accord with physical models, and we have further added dimensions of complexity.

Beyond these factors, there are others which become evident as one explores the disciplines encompassed within the broad realm of “systems thinking”.

Models

There are various types of models at play within enterprises, including but not limited to:

  • Each of us have mental models of the world and the enterprise with which we engage and interact
  • Our information systems (whether paper based or digital) are a model of how the enterprise sees the environment in which it operates, its interactions with this environment, and its internal activities.
  • Our planning, designing and managing activities often develop models as a means of communicating intentions or exploring options

Our engagement in the development and operation of our enterprises requires us to better understand these different types of models, and to deal with the range of inherent conflicts which inevitably arise between the various models we use, whether individual or shared models.

Complexity

As we start to explore organisations and the enterprises they pursue, it does not take long to realise that, like human beings, organisations are complex entities. This leads to a number of different issues as no individual can hold within their mind all elements that go to make up the structure and behaviour of an organisation.  The implications of this include:

  • Each individual may have a different perception and conception of the organisation
  • A complete conception of the organisation requires multiple individuals to create and sustain
  • Common models and a common language and narrative will be required to deal with these implications

Role of enterprise babelfish

And so it is, that I see an invaluable role for those within an enterprise that have the capability of the babelfish to:

  • recognise the different languages and models being used within our enterprises
  • enable the enterprise to develop a more consistent expression of its aspirations, intentions and mode of operation
  • facilitate processes whereby business transformation can be more effectively planned and executed

In so doing, those fulfilling this role will contribute to developing greater self-awareness as an enterprise, to more effective development, and hence to enhanced performance, viability and sustainability of the enterprises of which they are part.

Architectural sufficiency

enterprise-modelingLeave a comment

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

enterprise-modelingLeave a comment

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

enterprise-modelingLeave a comment

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

enterprise-modelingLeave a comment

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

enterprise-modelingLeave a comment

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?

Capability cultivation

enterprise-modelingLeave a comment

Are you cultivating the capabilities your enterprise needs for the future? How do you know what capabilities you will need? How do you choose which capabilities to develop or strengthen sooner rather than later?

Last year, my son drew my attention to “Time for a new consensus”, subtitled “Fostering Australia’s comparative advantages” – an essay by Jonathan West and Tom Bentley, published by the Griffith Review. The essay in full is a very interesting read, but in this article I just want to pick up a couple of thoughts which caught my attention:

… the deeper problem is that the assumptions underpinning our current (political) consensus no longer fit Australia’s circumstances

and

… a new consensus must focus on how we construct comparative advantage in the Australian economy, by shifting from static, one-off efficiency reforms to dynamic, capability-enhancing investments

These reflect common themes facing many industries and many organisations

  • market disruption, laying waste our existing operating assumptions
  • developing dynamic capabilities, enabling greater flexibility and agility in responding to market / environmental changes, whether they represent disruptive forces or new opportunities

This aligns with key elements of the enterprise transformation lifecycle that underpins our work in developing next generation leaders and enterprises.

Using this lifecycle, we:

  • explore business models and operating models, exposing, testing and adjusting assumptions that we make about our organisation and the ecosystem within which it operates
  • maintain business models and operating models, informing the progressive development of a dynamic organisational capability portfolio
  • assess and develop these organisational capabilities through consideration of a number of different dimensions, including culture, process, practice, systems, assets and other resources

What do we need to do to successfully cultivate a capability?

We need to consider the different composite elements of a capability, be it an organisational capability or a technology-based capability. The inclusion of attention to people, culture, practices, attitudes, behaviour, leadership is one of the reasons that we have chosen to describe the work of defining and realising organisational capabilities as an act of cultivation – helping to underscore the cultural and social elements that are equally important as other elements of these capabilities.

How do we choose which capabilities to develop? Through reconsideration of our business models and operating models, establishing an understanding of which will make the most significant contribution to enterprise viability and sustainability and where capability inter-dependencies exist that influence timing and sequencing.

Being more systems savvy

enterprise-modelingLeave a comment

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.

Enterprise pertinence

enterprise-modeling2 Comments

pertinence

In thinking about the problems that enterprises encounter, the following questions came to mind:

  • What problems is your enterprise experiencing?
  • What problems is your enterprise trying to resolve?
  • How do you decide that these are the most important problems to solve?
  • What questions do you ask in this process?
  • Are you asking the right questions?

The answers to some of the questions will provide some insight into the measure of your enterprise pertinence.

Enterprise problems

All enterprises encounter problems. Yet, I wonder how well enterprises deal with the problems they encounter, and more particularly, how well enterprises deal with determining which problems to resolve, what priority to give to resolving them and how much to invest in resolving them.

The constant references to failed enterprises, failed business strategies, failed change initiatives, failed IT projects, … suggests that there are no shortage of problems to address and no shortage of opportunities to get better at solving problems!

Given how many problems might be encountered and the investment in effort to analyse the problem, design and assess potential solution options, develop and integrate these solutions into our enterprises, there is a need to:

  • assess and prioritise the problems, their solutions and the value they will deliver in terms of enhanced enterprise performance and outcomes
  • assess the cost and value of assessing and prioritising any prospective problem

This is what leads to considering whether we are asking the right questions about:

  • the problems we are experiencing or might experience
  • the extent to which these problems might prevail given changes in the ecosystems in which they operate or in the directions we might pursue (whereby some problems might not arise)
  • the root causes of the problems we are experiencing
  • how we perceive the problems that might or might not arise

Attention economy

What is the attention economy? How is it relevant to enterprise pertinence?

The attention economy reflects a view of our lives as being awash with information commanding our attention. Think of all the information coming to you via:

  • television, radio and print media
  • emails commanding your attention and action
  • social media – Facebook, LinkedIn, Twitter feeds

There are only so many “waking hours” in a day, so there are only so many “signals” to which you can give your attention. Here we have a supply and demand problem – one where “economics” comes into play. There is more demand for your attention than there is supply of attention that you can give. How do you decide which to ignore and which to consider? We make choices as to the allocation of our time and attention. We deem one signal to be more pertinent to our life and the various enterprises in which we engage. This is the “stuff” of work / life balance, of strategic versus tactical, of relevant versus irrelevant, of attention versus distraction.

It is as much about how we spend our “personal” time as it is about how we spend our “work” or “enterprise” time. Our awareness of problems and attention to problems is part of enterprise pertinence.

Power of questions

How do we identify problems? How do we assess problems? How do we assure ourselves that we are assessing problems well (right) and assessing the right problems?

This is the business of quality, assurance and governance, asking questions and asking the right questions. In governance roles, one learns to ask questions and one learns to recognise powerful questions. An example is the question all Boards must ask themselves and should be able to answer:

  • What constitutes success? How would we recognise success?

This is also the field of learning, single, double and triple loop learning:

  • Single loop learning – are we doing things right?
  • Double loop learning – are we doing the right things?
  • Triple loop learning – how do we decide what is right?

In understanding and exploring any area of activity, it becomes evident when asking a leader in the field a particular question, and they respond “That’s a good question” or “I have thought of asking that question”. Such situations of evidence of high individual and (potentially) enterprise pertinence.

Enterprise development

With the increasing complexity of the environments in which enterprises operate, we appreciate that enterprises must adopt an adaptive approach, where they need to learn about their situation and the associated problem space before being able to consider potential solutions. This will engage us in asking a range of questions, often around the five interrogatives:

  • Why?
  • What?
  • How?
  • Where?
  • When?

Deloitte University recognises this growing dynamic, and advises clients that we are transitioning:

  • from the industrial age where successful enterprises successfully scale efficiency
  • to the knowledge age where successful enterprises successfully scale learning

That entails developing the capability of asking and answering the right questions – the capability of developing enterprise pertinence.

Are you asking good questions in your enterprise?