Exploring digital transformation

lemmings (1)

When I hear expressions such as digital transformation and digital leadership, the following images come to mind:

  • Millions of 0’s and 1’s transforming into 2’s and 3’s
  • An endless line of o’s and 1’s following each other like lemmings

More seriously, the following questions come to mind:

  • What is digital transformation?
  • What does it mean to my enterprise?
  • What decisions will it require?

Understanding digital transformation

So … let’s unpack digital transformation using some simple equations.

  • Digital transformation = digital strategy + business transformation
  • Digital strategy = digital products / services + business strategy

Combining the two equations, we get …

  • Digital transformation = digital products / services + business strategy + business transformation

For me, that makes things much simpler because:

  • I understand what is entailed in business transformation
  • I understand what is entailed in business strategy
  • Now, I need to understand the implications of digital products and services

Digital products and services

There are several different elements to consideration of digital products and services, including:

  • those existing products and services which are amenable to being delivered as a digital product or service
  • those new digital products or services which complement existing products and services in such a manner as to enhance the value proposition for existing or new customer segments
  • those digital products or services which can be integrated with other digital products and services from within your enteprise or from other sources

Each of these areas offer the opportunity to extend greater value to existing and new customers.

Examples

That all sounds fine – but what does it mean in practical terms for your or my enterprise? And let’s consider some pragmatic examples and not just trot out the usual, unreachable examples such as Amazon, Netflix, Air BnB or Uber!!

Depending on your enterprise – it may prove a valuable exercise, simply to list your products and services. For some enterprises, it is obvious. For others, not quite so easy.

In my own line of business, I provide consulting services. Often, these services are summarised in a deliverable (product). The consulting is largely done face-to-face and on a client site. The deliverable is typically a presentation or a document, already provided in digital form. There will often be several steps in developing the report. The early stages of the consultancy may involve some form of assessment. This could potentially be undertaken via a digital channel, enabling my client to undertake the assessment at a time and in a place that suits them, without needing to coordinate our schedules and our locations.

Of course, this is not feasible for all businesses. A friend who operates a lawn mowing and gardening business is not going to be able to offer an alternative digital product! But that does not mean that there are no digital product / service opportunities. Perhaps there are complementary digital products and services that he might offer? These could relate to:

  • booking and paying for his services
  • hints and tips for “after-care” of lawns and gardens

Ultimately, the test for complementary digital products and services relates to customer need and potential for the customer to value these, in combination with the physical products and services. A helpful approach to identification and consideration of such opportunities is to consider the “customer lifecycle”, from genesis to lapsing of a particular need. An important consideration in developing and delivering digital services is to consider the customer journey and customer experience. A disjointed, difficult customer experience will not be conducive to business growth in this area.

An example which has been given consideration by governments is the process involved in establishing a new cafe or restaurant. Depending on circumstances, the entire process can require interaction with a number of different government entities (at differing levels of government in differing national contexts) including:

  • Registering a business and business name
  • Securing licences for selling and serving alcohol
  • Gaining local authority approval for food preparation
  • Dealing with any entertainment licensing fees
  • Subsequent renewal of approvals

Such processes can involve provision of similar information on numerous occasions, and may entail presentation of considerable supporting documentation, through slow and cumbersome office / counter channels. A digital service would allow the prospective business owner to provide the necessary information once and to be able to undertake the process at a time and place of their convenience. This first emerged under a program entitled “Ask just once” – promoting the line of thinking that government agencies would move to a position where they did not repeatedly ask citizens or businesses for the same information.

Another example revolves around considering all the related events which occur in a “life event” such as moving house, where a range of changes occur in relation to:

  • the property transactions (sale and purchase)
  • utility connections (power, water, telecoms)
  • advice of change of address to other organisations

In this scenario, all three elements can prevail – replacing physical services with digital services, offering complementary digital services and integrating a range of digital services to offer greater value and convenience to customers.

Tools and techniques

What tools and techniques can be used to identify and explore opportunities and implications as part of developing a suitable digital strategy?

Changing the product or service portfolio can be effectively explored through the discipline of reviewing your enterprise business model(s). Such a review gives cause to considering the viability and sustainability of product and service offerings and their value proposition to customers and consumers.

Better understanding the value proposition for customers should prompt consideration of digital products and services and the use of digital channels to complement existing market channels.

The same disciplines, applied to your enterprise operating model, will enable identification of opportunities for efficiencies and more responsive processes in producing and delivering your products and services, offering greater value to existing or new customers.

Conclusion

Digital transformation calls for thinking about digital products and services which may complement or extend your existing products and services and which will deliver greater value to customers and enable you to offer your products and services to broader markets.

Provision of these digital products and services will leverage existing capabilities within your enterprise, but also require you to strengthen and extend your business and digital capabilities. It will demand that you better understand and manage the inter-dependencies between your enterprise capabilities and their integration to ensure that a seamless and positive customer experience is provided for the new products and services you offer through wider and more convenient channels.

Attention to development of your enterprise in this direction may be critical due to the emergence of digital products and services from existing or new competitors, but also offers your enterprise the opportunity to enter new markets which you have previously been unable to access.

Engaging enterprise architects

Business people in office

There are a number of key motivations behind the articles which I have written over the last 18 months, which may help in appreciating the manner in which I have approached the task of communicating the essence and value of architecting enterprises. These drivers include:

  • contributing to economic, social and environmental development
  • engaging Boards, Directors, Executives and Managers
  • exploring architecture as a preventive rather than corrective measure
  • continuing my commitment to using plain business language
  • linking with other well-established and sustained resources
  • extending systems engineering to enterprise systems engineering

Economic, social and environmental development

I am convinced that architecting enterprises leads to higher accomplishing enterprises, whether the enterprises are pursued within, by or across multiple public, private or community sector organisations. Mature, sustained architecting capabilities enable enterprises to more effectively achieve their intended outcomes, whatever combination of financial, economic, social and environmental dividends they realise. To that extent, improving enterprise performance is a means of making an effective contribution to the future economic, social and environmental wellbeing of the community, state, nation and world in which I live.

Living in South Australia, an economy that has a higher proportion of small-to-medium enterprises (SMEs) than most other states in Australia, prompts me to explore ways in which architecting can be applied practically and deliver value to these organisations. In considering Directors as one part of my audience, I am conscious that one third of the 40,000+ members of the Australian Institute of Company Directors lead, direct and manage SMEs, reinforcing the significance of the SME constituency.

When considering Australian commercial businesses, statistics indicate the following profile:

  • 1-19 employees – 755,000
  • 20-199 employees – 78,000
  • 200+ employees – 5,000

Architecting offers the prospect of enhancing the performance of all of these organisations, well beyond the current profile which predominantly entails the 5,000 commercial businesses with more than 200 employees, plus other large organisations in the public and community sectors.

This orientation and motivation has prompted me to write articles which enable any leader to bring architectural thinking to bear in the enterprises in which they are engaged.

Directors, executives and leaders

Executives and leaders have always been the architects of enterprises. This does not change with the introduction of a more disciplined approach to architecting. Architecting of enterprises will always be done by executives and leaders. If done by others, this can compromise the efforts and value provided by these individuals, as executives and managers will inevitably change the architecture developed on their behalf by others. Even where advice is sought or tasks are delegated to others, it is critical to the sustainment of the enterprise and the integrity of its architecture, that executives and leaders understand the manner in which the architecture is expressed and maintained.

With the increasing degree of disruption to business and operating models, Boards are giving increasing attention to the intended business and operating models for their enterprise. This requires that the language used in expressing the architecture of the enterprise is based on natural business and governance language. The ability of executives and leaders to present meaningful architectural outputs and decisioning, and to demonstrate a mature architectural capability within their enterprise will offer significant confidence and assurance to Directors.

To that end, I have explicitly chosen to convey the approach to architecting enterprises in a manner that will be readily and easily understood by directors, executives and leaders. I have also chosen to demonstrate how the architecting capability speaks to corporate governance by attending to the integration of business and operating models with a sound, well recognised governance model.

Prevention rather than cure

Architecting has a number of different objectives, and one of these is to enable stakeholders to more easily deal with complexity. I recall early in my involvement in discussions on LinkedIn in The Enterprise Architecture Network (around 2012), there were views expressed that enterprise architecture just made enterprises more complex. This typically arose in discussions relating to the need to document the current architecture, where extensive effort could lead to high costs with limited value derived from these activities.

It occurred to me that:

  • architecting enterprises was most typically undertaken in large corporate and government organisations, with few smaller organisations making use of this capability
  • architecting capabilities were often directed towards dealing with organisational silos and to achieving greater organisational integration and wholeness
  • large enterprises arise from smaller enterprises that are less complex (or so I assumed)
  • embedding architecting capabilities in smaller enterprises might prove easier to effect and might aid in preventing the emergence of organisational silos

In this manner, I formed a simple view of disciplined attention to architecture being a treatment for various organisational ailments, which might be more readily addressed by taking a preventive approach. At this time, I also read Ichak Adizes “Managing Corporate Lifecycles”. Adizes looks at enterprises through the lens of their growth, pre-conception through childhood, teenager years, early adult life, maturity and through to death. Adizes also speaks of:

  • growth and change causing disintegration and requiring re-integration of our enterprises
  • an optimal path entailing earlier, balanced attention to integration

Viewing architecting as a tool for integration, this further encouraged me to consider the architecting of smaller enterprises (which I have explored in a number of other articles).

Plain business language

The nature of architecting systems is that it entails recognition and exploitation of common principles and patterns. That can lead to the creation and use of terms which seek to be neutral across multiple contexts and agnostic to the structures established in enterprises.

As examples:

  • the term organisation may be used as a more general term rather than business, corporation, government agency, or community body
  • the term enterprise may be used to accommodate the pursuit of an endeavour by part of an organisation, an entire organisation, or multiple organisations

However, it can also lead to terms which are foreign and unfamiliar to stakeholders.  “Segment” is one such concept which comes to mind.  Whilst it makes sense, it is not a term which is commonly used in normal business and executive conversation.

I have a preference to find and use terms that stakeholders already use and understand, and to avoid “special” language which can become exclusionary. This highlights a key aspect of my thinking and practice – taking an inclusive approach.

This is part of the reason that I commenced focusing on business models and operating models, now becoming more widely referenced by Boards, Executives and Management Consultants through research and tools such as:

  • Business model canvas
  • Value proposition canvas
  • Operating model canvas

Linking to other resources

When I first encountered Bruce McNaughton, I found that he was always trying to relate different frameworks to those well established frameworks that his clients use and/or are familiar with. Where this was possible, he would prefer to use the language in these frameworks and link his approach to architecting enterprises to these frameworks.

This makes great sense to me. It means that these elements will be developed and maintained by the appropriate bodies and will be familiar to many of my clients. Examples include:

  • ISO 9001 quality management
  • ISO 31000 risk management
  • Recognised project management and program management frameworks

Linking to these resources narrows the scope of architecture frameworks and the effort to sustain them, as well as making the architecture framework more readily understood by key stakeholders.

Applying enterprise systems engineering

A more recent driver has been to explore and apply concepts which have been outlined in the field of enterprise systems engineering.

I was introduced to this field through “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises” ed. John Gotze. This has since led me to INCOSE – the International Council of Systems Engineering – an international organisation advancing the discipline and profession of systems engineering, including enterprise systems engineering and socio-technical systems engineering. This provides a strong base for advancing enterprise architecture in its broadest context, being a natural part of enterprise engineering.

Early engagement with INCOSE through its International Symposium 2017 being held in Adelaide has afforded me the opportunity to explore the extent to which my articulation and practice of enterprise architecture aligns with the lines of thinking being advanced through this body. As I learn more, I expect this may result in further refinement of the language that I use in these articles and in engaging with directors, executives and leaders in architecting enterprises.

Important elements in the capability development lifecycle include:

  • stakeholder engagement in problem definition and redefinition
  • refining and building shared understanding of conceptual models

In this regard, it is important to “start simple” such that the learning journey is shared by all stakeholders.  Those facilitating the process must bear in mind that they hold a much more sophisticated model and understanding of the lifecycle processes which stakeholders will progressively learn by sharing the journey.

Summary

These different factors have remained as part of the context and motivation for the series of articles that I have developed, including the most recent one on the approach that I take to architecting.

It is aimed at providing a clear and simple approach (as outlined in my first article entitled “Enterprise architecture – plain and simple“) to architecting such that directors and leaders can apply the thinking tools that architecting offers to their ongoing role as architects of enterprises and assurers of the architecture of enterprises.

Approach to architecting enterprises

Many of my articles have been about particular concepts, topics, models or perspectives relating to architecting enterprises. In that regard, they have not offered as much about the process of architecting or the methodology that we employ.

This article seeks to explore this territory, offering a simple approach which can be applied to any enterprise-as-a-system, and on which I may elaborate in later articles.

Enterprise models

Our method uses three key models:

  • Governance model
  • Business model
  • Operating model

The governance model entails application of the Tricker model, which is introduced to any Director undertaking the Company Directors Course offered by the Australian Institute of Company Directors. Key areas that are given attention are shown in the following diagram.

Tricker-model

Use of this model this model means that the activity of architecting the enterprise is easily integrated into the corporate governance model and will be familiar to many Directors, not only in Australia but also in other countries.

The second model is the business model, taking an enhanced approach to the Business Model Canvas. An example of a business model representation for a disability organisation is shown in the following diagram.

New-disability-business-model

Further exploration of business models and their development is provided in:

The third model is the operating model which is developed to enable the enterprise to realise its intended business model(s). An example of an operating model for a fictitious taxi company is shown in the following diagram.

TTC-operating-model

Further exploration of operating models is provided in:

Transformation program

By iterating the use of business models and operating models, an enterprise can:

  • articulate its business strategy
  • express its intended business and operating model
  • enable the organisation to assess capability gaps
  • develop an investment portfolio and transformation program

Overall, this approach is reflected in the following diagram.

EM_journey_v0-15

As with the business models and operating models, this can be applied to any enterprise, whether it relates to a multi-organisational venture, a single organisation or part of an organisation.

Applying this pattern

If you interpret the diagram to mean that one creates a vision for where an enterprise should be in five years’ time, a roadmap to get there, and then religiously follow that roadmap for the next five years, then you will find it very 1970s thinking – as commented by a colleague.

That is not how the process “works out”. Nevertheless, it is the case that whenever a change in business model is contemplated, a number of change initatives will inevitably emerge. It is also the case, that whenever I encounter a client there is a “portfolio” of change initiatives in train, whether or not they are being managed as a program and portfolio, and that there will be elements of this cycle that are layered on top.

Sometimes, my starting point is the current portfolio, working backwards to ascertain whether there is clarity about the capabilities being improved, the operating model being realised, and the business models being pursued. So, the cycle may be entered at any point (because annual capital budgets create a cycle anyhow) and in any direction.

 

Enterprise dualities

There are a range of conceptual pairs that I have found to be important to understand and consider when architecting enterprises. Each of these pairs constitute a duality where change of one encompasses or allows change to the other. Understanding both dimensions of each of these dualities is essential to the successful architecting and design of enterprises. Equally, changing one without appreciating the other is changing can be fraught with danger! The pairs that come to mind include:

  • Self and other
  • Enterprise and organisation
  • Internal and external
  • Information and process
  • Means and ends
  • Capability and outcome
  • Autonomy and control

Self and other

I have listed this first because people are intrinsic to all enterprises. People conceive and pursue enterprises. Many enterprises entail collaboration with others, engaging them in the ongoing conception and pursuit of the enterprise.

From the outset of our lives, we engage in a process of understanding ourselves. The concept of “self” unavoidably entails the concept of “other” – to define “self”, we must be able to differentiate “self” from “other”. Consider the development of a child, coming to understand themselves as separate and distinct from:

  • their mother and father
  • the world or environment in which they live

Our understanding of ourselves is as much informed by our understanding of others, and vice versa. We communicate with others and that communication changes them. They communicate with us and that changes us.

As we collaborate with others in conceiving and pursuing enterprises, we engage in developing a shared conception of our enterprise and the manner in which we pursue it. We share our conception and others conception may be challenged, reinforced and possibly changed. They share their conception and the same may occur.

The models that we develop as part of conceiving and pursuing our collaborative enterprise inevitably entail ongoing changes to self and to others. In my experience, they are more successfully conceived and pursued when I give due attention to the manner in which others can and do contribute to the enterprise.

This duality prompts consideration of numerous dimensions, far more than can be covered in this article, providing an valuable source of topics for future articles, including:

Enterprise and organisation

“Enterprise” has a number of different meanings. Often it is used as a synonym for organisation, as in:

  • enterprise-bargaining and organisation-wide-bargaining
  • enterprise-agreement and organisation-wide-agreement
  • enterprise-development and organisational-development
  • our-enterprise and our-organisation

In architecting enterprises, it is helpful to bring a different meaning into play – as outlined by Len Fehskens when I encountered him through LinkedIn and more recently through the Association of Enterprise Architects and their journal, of which he is Chief Editor. Len encourages us to consider

enterprise as an undertaking or endeavour

In doing so, it is then possible to make a clearer distinction between the organisation that we establish to pursue the undertaking or endeavour and the undertaking or endeavour itself. It also enables us to apply the concept of enterprise in a range of different ways that are not tied to the scope of an organisation, including:

  • a new product or service as an endeavour
  • a multi-organisation endeavour
  • a project as an endeavour

Each time the conception of the endeavour changes, there will be a necessary change to the organisation established to pursue the endeavour. Each time the organisation is changed, we create the capability and opportunity to pursue different endeavours.

Internal and external

This is a more general version of self and other, but applied to any entity or system. As we create and define the boundary which “defines” the entity or system, so

the boundary creates the distinctions of internal to the boundary and external to the boundary

If we change what we regard as internal, then we are changing what we regard as external. If something changes externally, then this may cause us to change something internally.

For some enterprises, their ultimate failure has arisen through a failure to recognise the external changes that have been impacting their enterprise as each enterprise responds to external needs by making internally developed offers.

Information and process

This is probably the earliest “pair” that I encountered, as part of my role as a business analyst.

For any process, it is possible to identify:

  • the information consumed by the process
  • the information generated by the process

For any information, it is possible to identify:

  • the generating process
  • the consuming process

Hence, the view that one does not exist without the other. This has provided the basis for reviewing and assuring the quality of business requirements documents, checking that there are identified processes for the information requirements, and that there are identified information domains and entities for the process requirements.

Means and ends

This is a well known pair that comes in a variety of forms:

  • means and ends
  • strategies and objectives
  • how and why

They can exist in a cascade where:

  • Strategy A is pursued to realise objective 1
  • Objective 2 reflects Strategy A
  • Strategy B is pursued to realise objective 2

These elements may be used to explore:

  • business objectives and business strategies
  • program objectives and program strategies
  • project objectives and project strategies
  • system objectives and system strategies

Change the objectives and it is necessary to change the strategies. Change the strategies and different objectives may be realised.

Capability and outcome

Whenever a different outcome is required, there is a need to determine whether that demands new or different capabilities. Whenever a different capability is available, there is the opportunity to realise new of different outcomes.

There are several modeling techniques which enable effective exploration of this particular duality:

  • Benefit realisation chains aid in understanding the chain of outcomes that are required in order to realise ultimate enterprise goals and outcomes. Once developed, it is helpful to explore the capabilities required to deliver each benefit / outcome in the chain
  • Business capability models aid in reflecting the capabilities existing within an enterprise or required to pursue an intended enterprise. Once developed, it is helpful to explore the gaps in capability to inform a change or transformation program, and to articulate the outcome measures for each capability which aids in evaluating progress and degree of success.

Autonomy and control

Consideration of autonomy versus control arises in a range of situations, most commonly in relation to:

  • Governance
  • Management
  • Process

In a governance context, there is a recognition of the separation between the governing body and management. Governance creates an environment through articulation of strategy and policy within which management are expected to operate. Strategy and policy which are too prescriptive limit the capacity of management to respond the dynamic nature of the environment in which the enterprise operates. Alternately, ill-defined strategy and policy may offer a degree of autonomy such that management pursue outcomes beyond those identified by the governing body.

In a management context, managers and staff reporting to a manager will give consideration to the degree to which the manager controls staff or empower staff and affords them a degree of autonomy. Staff with little autonomy will often speak of being micro-managed, implying a degree of control beyond that which they deem necessary.

In a process context, consideration needs to be given to the conditions within which the process operates and the extent to which these can be accommodated by a process which prescribes what should be done versus a process which relies on the knowledge and skill of staff to determine what should be done.

In each context, increasing autonomy entails decreasing control and vice versa. Careful attention is required to determining the appropriate balance between autonomy and control.

Conclusion

Each of these dualities are important to the successful architecting, operation and sustaining of enterprises.

Perhaps there are other dualities of which you are conscious and which you find important to consider?

Enterprise development

In the article about Operating Models, one of the four primary systems is the Development System as shown in the following figure.

I have been prompted to further elaborate on enterprise development because of:

  • the increasing interest in effective business transformation and business change and the related field of digital transformation
  • some recent commentary on the development system element of operating models

The latter can be found on Andrew Campbell’s Operating Model blog where he comments on the representation of operating models that I have outlined.

This has led me to elaborate further on:

  • the role and purpose of this system
  • the increasing importance of this system
  • the place of this system in the enterprise lifecycle
  • the implications of ignoring this system
  • a maturity view of this enterprise capability

Development System

Let me start by talking about the naming of the system, and by indicating that others may have or prefer alternate names. I chose “development system” because I believe it is helpful to consider:

  • enterprises as living systems which adapt, evolve, develop and mature in response to internal and external factors
  • change and transformation as processes which develop the capabilities of an enterprise to realise its goals and aspirations
  • the transition from an existing operating model to an intended operating model as an enterprise learning and development process

The term also relates well to other enterprise activities such as:

  • business development
  • organisational development
  • leadership development
  • professional development

Role and purpose

The development system exists to fulfill a purpose which can be expressed in different ways, including:

  • Develop the necessary enterprise capabilities to execute business strategy
  • Transform the enterprise from its current to intended state
  • Design, plan and implement the necessary changes to realise the intended enterprise

The system exists from the moment that the founder creates the enterprise through to its current form. It supports the development of the enterprise through its lifecycle. An interesting set of perspectives on the enterprise lifecycle is provided by Ichak Adizes in his book “Managing Corporate Lifecycles”.

Importance

In the past, I have not incorporated this system and its subsystems in my descriptions of the architecture of an enterprise. However, the importance of its inclusion has become evident over time. Contributing factors include:

  • Commentary on the failure of business strategy execution. It seems to me that such failure either arises due to poor strategy or poor execution. The latter reflects a failure of the development system – and its role in establishing the necessary capabilities to fulfill the requisite business strategy.
  • Commentary on change failure or project failure. Both of these are about the failure of the development system. An enterprise can have the best strategy in the world, but if it cannot be realised, then it is of no use to the enterprise. Hence, there is a need to understand the adequacy of development capabilities and address these if strategic capabilities are to be realised.
  • The increasing degree of change in the market / environment in which enterprises operate means that the demand and necessity to change and develop is becoming an increasingly important aspect of any enterprise. This is reflected in an increasing allocation of resources to the development system within many enterprises.
  • In John Kotter’s article in HBR – Accelerate, John outlines the concept of a “dual operating system” within enterprises – the operational system and the change / transformation / development system – which he sees emerging in response to the increasing demand for enterprise agility and the significantly different features and culture required in these two systems.

Hence, it seems to me that the demands for enterprises to change, transform and develop in a more adaptable and agile manner for their ongoing viability and sustainability are such that attention to the development system is not just becoming increasingly important, but is becoming unavoidable.

Lifecycle

The enterprise development lifecycle is shown in the following figure.

The development system converts business strategy into enterprise operations. The performance system monitors the development system and the operations system in relation to progress and realisation of the intended outcomes. This provides inputs into subsequent cycles of strategy development.

Typically, key activities within the development system will include:

  • Refinement of the intended business model(s) and operating model required to effect the business model(s)
  • Development of the transformation or change strategy to realise the intended operating model
  • Formation and execution of the transformation program to put the change strategy into effect

Implications

The implications of failing to give attention to the development capabilities of an enterprise include:

  • Ongoing change and project failure
  • Higher than anticipated costs and lower than expected outcomes in effecting business strategy
  • Unnecessary revision to business strategy due to assumptions that the business strategy was deficient where it may be weaknesses in execution and deficiencies in change management capabilities
  • Unnecessary risk to enterprise viability due to an incapacity to respond to market disruption in a timely and cost effective manner

Maturity

The development capability is simply another capability within the enterprise. It can be assessed in terms of its maturity, just as any other capability, identifying the different dimensions to the capability and which of these may require improvement. In part, the value of the maturity view is one of acknowledging and leveraging the areas of strength, and determining those particular dimensions where learning and/or change is required. With the increasing degree of change occurring in enterprises, early attention to the maturity of this capability will be critical for many enterprises.

Enterprise resources

In the article about Operating Models, one of the four primary systems is the Resource Management System as shown in the following figure. 

Several comments have been made about the need or value in considering the Resource Management System. This has prompted me to elaborate further on:

  • the role and purpose of this system
  • the increasing importance of this system and the implications of ignoring this system

Role and purpose

All enterprises rely on a range of resources as part of their enterprise capabilities, established to deliver their intended products / services. These resources include:

  • Finance (a means of securing other resource types)
  • People (and their associated knowledge, experience, skills, attitudes and behaviours)
  • Information (both the information consumed and the information generated and consumed by other parts of the enterprise)
  • Assets (fixed assets, plant and equipment, and technology)
  • Materials (or consumables)

The types of resources required can vary significantly across different enterprises and different industries. All enterprises have in common the need to manage finance, people and information. Many enterprises have few assets that they require and can often access the assets on a usage basis without involving the additional activities and responsibilities entailed in asset ownership. Enterprises have varying needs for materials.

The primary role of the resource management systems is to ensure that other systems are readily able to access appropriate resources meeting their performance and other requirements. These systems attend to common activities such as those relating to:

  • financial resources, including management of financial resources, financial transactions (creditor and debtor management), allocation of financial resources and reporting of financial performance
  • human resources, including support for recruiting, employment conditions, training and development, workplace safety and performance management
  • information resources, including sourcing, organising and supporting access
  • physical assets, including the management of the asset through its lifecycle from acquisition / creation through to disposal
  • materials, including supplier selection and management, sourcing, storing and ensuring they are available for immediate use so as not to impede the productivity of the people or machines consuming them

Importance

These activities emerge and develop as enterprises grow in size and complexity. They are most commonly seen in the form of Corporate Service Divisions or Shared Service Centres. Their establishment and operation enables others to focus on their core capabilities and ensures that a consistent approach is taken to management and availability of these critical resources.

In some enterprises, intermediate products and services are developed and provided to provide more effective support to the core capabilities within the enterprise. This might constitute specific value adding services around a basic resource. For example, the fleet function in a policing organisation acquires vehicles and fits them out to be an appropriate resource for patrol staff. This takes a basic resource (car) and creates a key resource for a core capability – response to incidents. It is not a core value adding process and capability, rather it is a value adding capability in providing a critical resource.

Without these capabilities, enterprises are prone to:

  • duplicating these capabilities within their core capabilities
  • failing to adequately manage these capabilities
  • compromising overall enterprise performance

Resource development

The extent and sophistication of the resource systems vary considerably for different types of enterprise and different size and scale of enterprise.

In a small enterprise, the resource management capability is most likely to be part of the manager or director roles. As the enterprise grows, it might establish a “business manager” role, which may encompass a range of the resource management functions. Further growth will lead to a point where a Finance Manager may be appointed, or a HR Manager position established. As indicated earlier, these capabilities can grow to the point of an entire Division supporting the resource management systems.

In such situations, one needs to be mindful that some of these systems operate across all functions within the enterprise. So, for example, every manager in a 10,000 person enterprise will have financial management responsibilities and people management responsibilities. There may also be other roles in providing support. For example, in a university setting, when considering the HR or people management system, one needed to be mindful that this encompassed:

  • every employee
  • every manager
  • HR support functions at School level
  • HR support functions at Faculty level
  • HR support functions at Corporate level

In such scenarios, any one of the resource management systems can be viewed as an enterprise in its own right, and will entail a complex set of systems and functions providing support to the entire organisation. Whilst these systems are not part of the operations system, delivering the core products and services of the organisation, they can be critical to the success of the enterprise, and the manner in which they operate may be part of the way in which the enterprise is able to differentiate itself.

Operating models

This is an article in the series “Enterprise architecture – plain and simple” that I published on LinkedIn Pulse last year. In the article on elements of the description of current or intended architectures, I referenced a number of key models that I use. The first and primary model is the business model, described in another article in the series.

Whereas the description of business models seems to have become more consistent through the application of the ontology developed by Alex Osterwalder, I am not so confident that there is a clear ontology or framework for operating models.

There is research and thinking which has occurred in the area of operating model design. Andrew Campbell of Ashridge Business School runs courses on operating model design and publishes a blog on the topic – Ashridge on Operating Models. He and I have exchanged views and explored the relationship between enterprise architecture and operating model design. We have already published one article on the topic of enterprise architecture – see Why business managers should understand enterprise architecture. We have only a little further to go before we could confidently say that we have shared views in this domain. That represents for me, an interesting challenge and a great learning opportunity!

As I have explored the high level models that different practitioners develop, it has become evident that different frameworks (whether individual or commercial) adopt different ways of conceiving of the primary systems of which an enterprise is comprised. The highest level abstraction of the systems of which an enterprise is comprised, then “sets the tone” for all subsequent elaborations.

In this article, I will simply share some of the patterns and models which I have used quite successfully with a variety of clients. I do not pretend that the framework that I use is any better than any others. I will outline the rationale for the framework and leave it to readers to ascertain whether it seems to provide a satisfactory basis for further development to reflect the operating model for enterprises with which they are engaged.

Purpose

The primary purpose of an operating model is to express the means by which an organisation:

  • pursues its enterprise
  • realises its goals and aspirations
  • achieves and sustains viable operation

Enterprise system

There are four key systems forming the expression of any enterprise-as-system that I consider:

  1. Operations management system
  2. Resource management system
  3. Governance and management system
  4. Development management system

For many years, I have only addressed systems 1 to 3. Typically, I have not addressed the development management system, because:

  • I was usually part of this system
  • the development management system was usually embedded in the other systems

However, with the increasing degree of change, I am finding that more enterprises are recognising the development management system as a distinct system. This can be seen in John Kotter’s article – Accelerate! – where he outlines the case for a dual operating system. It can also be seen in the increasing profile of Program Management in enterprises and in enterprises where they have established a Chief Operating Officer and a Chief Change Officer.

Operations system

This system is the core system which produces the products and/or services of the enterprise. It is most commonly represented as a value stream, reflecting the core capabilities by which the enterprise transforms inputs into outputs and delivers value to its customers and consumers.

This system may also include support systems which are not part of the primary value stream. These may be systems which require specialist capabilities and are required by different systems in the value stream and deliver internal products and services beyond those provided as part of resource management.

Resource management system

This system manages each of the resource types required for successful operation of the enterprise. At a minimum, this will encompass:

  • Human resource management
  • Financial management
  • Information management

It may also include:

  • IT management
  • Asset management
  • Procurement, contract and materials management
  • Record management

Governance system

All enterprises require governance and management.

With respect to governance, I have drawn on the Tricker Model which is one of the models covered within the Company Directors Course run by the Australian Institute of Company Directors. By drawing on this model, I know that there are many Directors and Boards who will be familiar with the model and therefore comfortable with the subsystems that I include:

  • Accountability and reporting
  • Strategy
  • Policy
  • Performance reporting
  • Strategic risk management

To date, I have not modeled the management system. It seems to be adequately covered by the management embedded in each of the systems that I consider. I have included reference in this area – governance and management – to allow for inclusion of additional capabilities that become evident and require attention beyond those evident in all other areas.

Development system

This system supports the development of an enterprise and effects change in any of the systems. Change may derive from strategy, as the means by which strategy is executed, or from individual systems as part of continuous improvement. It includes:

  • Architecture management
  • Program management
  • Project management
  • Change management
  • Program and project support

I view change through a lifecycle lens taking change from idea to realisation. Key steps include:

  • Initiative formation
  • Investigation
  • Acquisition
  • Design, build and test
  • Implement
  • Review and close

Conclusion

Overall, this conceptualisation of an enterprise-as-system has enabled successful:

  • development of architectural models
  • formation of program strategies, plans and roadmaps

It seems to prompt reasonable coverage of the activities of any enterprise and it seems to be easily understood by stakeholders with whom I engage.  Further elaboration has been provided in relation to:

  • Enterprise resources
  • Enterprise development

 

Since initially publishing this article, Andrew Campbell has published Operating Model Canvas which provides a clearer articulation of operating models.  In due course, I will publish an update which outlines the elements of my thinking and practices that extend beyond the approaches outlined in Operating Model Canvas.

 

Exploring business models

This article extends on my first article about business models, where I outlined the key elements of such models and the value in developing such models.  This article explores:

  • the use of business model thinking for any system within an organisation
  • the relationship of the business model to other familiar techniques
  • the different considerations that arise in different enterprise contexts, with some specific examples

Systems within the enterprise

Traditionally, the concept of developing a business model has been applied at the enterprise level, inviting exploration of customers, products/services, value propositions, channels (on the output side of the business) and suppliers, partners, activities / capabilities (on the input and production side of the business) and developing a financial model that reflects an appropriate outcome (break-even or profit, depending on the type of enterprise).

These concepts can just as legitimately be considered for any system within the enterprise, whether that is an enterprise capability or an organisational unit.  It might be a particular “line of business”, a “shared service”, or a support function.  Taking people (or human resource) management as an example, it is feasible to consider:

  • the HR Branch (or organisational unit) providing products and services to the enterprise as customers with appropriate consideration of value propositions and channels, etc
  • the people management capability as a whole across the entire enterprise providing products and services to employees and to managers as customers with appropriate consideration of value propositions and channels, etc

Care needs to be taken in such treatments.  For the HR Branch, there is the risk of assuming its continued existence, whereas the people management capability model allows consideration of alternate sources for products and services. A genuine exploration of services and value propositions should test these against competitors (or other options) in either scenario.

This is not novel.  The application of customer service thinking to corporate services occurred several decades ago now.  For those with experience in such initiatives, it should be easy to recognise the focus as having been the “enterprise” or “system of interest”, to which the business model can be applied. This demonstrates the value of applying this “business model concept” in a fractal manner to any designated system-of-interest.  As such, it can be applied to any identified system-of-interest or organisational unit.

Relationship to other techniques

Whilst I was familiar with business-model-as-financial-model, I had not encountered the Ostwerwalder analysis and structure until about two years ago. Prior to that, along with many other architects, I had applied a range of traditional modeling techniques to the enterprise.

The simplest technique involved the use of a Context Diagram, placing the enterprise as the system-of-interest, and showing the external relationships to suppliers, partners and customers, each of which are considered in the business model .

As I started to explore value chains and value streams, it became evident that I could apply models used in Six Sigma and Lean thinking, in particular SIPOC, by considering the enterprise as a single process (P), and showing the suppliers (S), inputs (I), outputs (O) and customers (C).  This was (and is) a useful tool in making explicit these elements of the enterprise, as is the case when developing an expression of the business model.  Then, the core value stream could be expressed as a series of inter-connected SIPOC models as the next level of decomposition.

Another model which I have used is IDEFo, providing a different perspective by treating the enterprise as a function, and reflecting the inputs, outputs, controls (governance) and mechanisms (processes) which underpin the function.  Again, this model reflects some elements in common with the business model concept.

Each of these techniques demonstrates how the applicability of a system-related model to the enterprise, many of them paralleling elements that are included in the business model concept.  Analysts familiar with these techniques will be readily able to apply them to enterprises.

Application in different settings

There are different and distinctive differences in business models applied to different sectors.  Some assume that business models are not applicable to government and community sector organisations.  The following outlines some of the differences and demonstrates that the business model concept offers utility and value in all enterprise settings.

Public sector enterprises

These enterprises operate in more complex environments, where additional considerations are necessary.  Yet, the same concept and general principles can be applied, and potentially deliver additional value by establishing greater clarity and understanding of the way in which these enterprises can address the goals and objectives which communities set and expect of them.

The most obvious differences are that often public sector enterprises:

  • are not required to make a profit or realise a return on assets or investment
  • do not derive their income (revenue) from their customers
  • do not have choice as to their client / customer base
  • are measured on outcomes rather than outputs

(I may write a separate article to elaborate on these differences, as they are fundamental to better understanding the differing management challenges facing public and private sector managers.)

Business models are able to be accommodate these differences, as long as appropriate consideration is given to distinguishing between:

  • customers and consumers – customers being those who pay for products / services and consumers being those who use the products / services
  • treatment of income versus revenue, and profit/loss versus surplus/deficit
  • outputs and outcomes – the latter arising as an effect of the existence or use of an output

In order to treat these elements appropriately, greater attention must be given to:

  • the use of language and terminology
  • the varying stakeholders who may have interests and be beneficiaries of the enterprise beyond simply considering customers
  • the varying value propositions and benefits which may be afforded to the differing stakeholder groups

For example, I find it helpful to consider the following dimensions:

  • Financial dividends (afforded to owners and shareholders)
  • Economic, social and environmental dividends (afforded to other stakeholders)
  • Balancing of value propositions for owners, customers and employees (at a minimum)

Each of these can be explored and expressed in an enhanced business model representation.

People management as an enterprise

This provides an example of applying business model analysis to part of an organisation as opposed to an entire organisation. Whilst it is feasible to consider the HR organisation unit, it is often wiser to consider the entire people management capability or system, as there are elements of this system within the role of every manager and executive, in addition to any specialist services which the HR organisation unit may provide.

In considering this capability or system, the business model concept prompts consideration of:

  • customers – Executives, managers, employees
  • services – from workforce planning and industrial relations to payroll
  • channels – face to face, phone and online / self-service
  • suppliers and partners – providing specialist services
  • capabilities required to deliver the various services

An important element in this process is applying a combination of the business model concept and systems thinking concepts.  It is common in support functions to seek to optimise a particular function, when it is only part of the whole, and optimising a part may result in sub-optimal outcomes from a broader enterprise perspective.

Business models

The concept of business model is relatively recent, emerging in the 60’s and gaining greater attention in the 90’s and succeeding decades.  The different lines of thinking were subject of review in 2004 by Alex Osterwalder, who developed an ontology for understanding and expressing a business model. This ontology has provided the basis for development of a number of tools for expressing business models, the most well-known being Business Model Canvas.

This posting explores:

  • the concept and value of the business model as a key artefact in describing the architecture of an enterprise (AE)
  • potential areas for further development of this concept to provide greater utility

Key elements

Key elements of the business model ontology include:

  • Value proposition
  • Target customer
  • Distribution channel
  • Relationship
  • Value configuration
  • Capability
  • Partnership
  • Cost structure
  • Revenue model

Drivers

Looking at enterprises over the last 50 years, it is possible to see how their business models have moved from being quite static to quite dynamic. This has occurred as a result of the increasing rate of change in the business environment and internal organisation of capabilities.

A significant factor has been the increasing use of ICT in developing digital capabilities, complementary digital products / services and use of alternate digital channels.  This is evidenced in the increased attention given to business models in the dot.com era where digital channels became available as an alternative delivery mechanism.  It is also evident in the current business model disruption arising from effective use of ICT within the market in which enterprises operate, where digital services enable disaggregation of the value chain, opening up new points of competition for an enterprise.

Value

One of the key benefits of the business model is that it presents a model which encompasses both internal and external elements which underpin the viable operation of the intended enterprise.  Consideration of:

  • value proposition, target customer, channels and relationship give attention to factors underpinning the revenue / income model and the balancing of stakeholder value with income
  • value configuration, capability, and partnership give due attention to factors underpinning the expenditure / cost structure

Review and validation of the business model gives attention to the viability of the enterprise and provides a suitable foundation for development of the supporting operating model.

I am encountering an increasing number of situations where enterprises are finding it necessary and valuable to revisit the viability of their current business model(s), demanding that they change in order to remain viable.  In one case, a review of a transformation program led to identifying deficiencies in their intended operating model, which led to identifying deficiencies in their intended business model.  Their failure to recognise and address the business model issues has led to the failure of the enterprise (going into administration last year).

Attention to the business model gives cause to consider the fundamentals underlying the market strategy for an enterprise and the corporate / development strategy for an enterprise.  Developing a transformation program for a flawed business model is a recipe for disaster and for wasting valuable change investment, both personal effort, energy and enthusiasm as well as financial.  Attention to the business model also gives cause to consider the balance between changes to the market strategy versus development strategy.

Developments

There are two areas of development that I see occurring:

  • viewing the external environment in systems terms ie as an ecosystem
  • viewing the internal elements in systems terms

In the past, there has been a tendency to consider entities in the external environment relatively independently.  With increasing market disruption, viewing the market as the containing system gives recognition to interactions occurring in the market that have implications for an enterprise that were not previously considered because the interactions were not directly with the enterprise.

From what I have seen, the use of tools such as Business Model Canvas prompt consideration of the various internal elements of an enterprise, but this does not require the elements to be considered through a systems view, recognising that there are interactions which require consideration of the “whole” and not just the parts.

In bringing a systems perspective, this also introduces the opportunity to apply:

  • elements of systems thinking to the enterprise
  • the Viable Systems Model to the enterprise
  • business model thinking in a fractal manner to subsystems within the enterprise

Practical application

It is probably worth adding that I have found that thinking about and exploring the business model of various enterprises has been helpful, whether or not I am engaged in developing the architecture of the enterprise.  Cases in point include:

  • LinkedIn Groups – considering the business model for LinkedIn to provide context and understanding of the role and contribution of LinkedIn Groups when it is not a direct part of the revenue model for LinkedIn
  • My state of South Australia and nation of Australia – thinking about how we are positioned in the global context, what capabilities we have or need, etc, including contribution to a group which considered the “innovation system” within our nation, and another interested in “reinventing our nation”
  • Voluntary collaborations in which I have been a member and contributor, helping the group to think about its goals and aspirations, the outcomes it is seeking (value propositions), the capabilities the collaboration needs and the areas to which we need to give priority

 

I have elaborated further on business models in a more recent article – Exploring business models.

 

Enterprises as systems squared

Enterprises as systems …

Enterprises as systems of systems (or systems squared) …

Makes sense! Seems reasonable! But what does it really mean? How does it help in making sense of the enterprises in which we engage and the change or transformation required to realise the goals and aspirations of our enterprises?

A system of systems sounds like it is a hierarchy of systems embedded in systems. Closer inspection indicates that it is more complex than that!

Sole trader or freelancer

An interesting starting point is provided by considering a sole trader or freelancer – a one person enterprise. That should be simple! What systems are encompassed within their enterprise-as-a-system? Likely candidates include:

  • Business development system
  • Contract management system
  • Financial management system
  • Work management system
  • Service delivery system

How do each of these relate to the others? How should they relate to each other? How might they be organised to readily support enterprise development and growth?

Even for a sole trader, key principles and models are helpful in establishing an effective operating model which supports future enterprise flexibility, agility and growth.

Professional services enterprise

For several different professional services enterprises, I have used the APQC Process Classification Framework as a reference model for likely systems in their enterprise. An example of what this might look like is shown in the following figure.

EaaSoS

Whilst this is portrayed as a systems hierarchy with systems composed of subsystems, it is evident on closer consideration that the system relationships are more complex than this.

For example, every executive, manager and supervisor exercises the people management system. In fact, every employee is part of the people management system. Hence, customer service staff and customer service managers are part of both, the customer service system and the people management system. Effective operation of the customer service system, as with all other systems, is dependent on a range of subsystems, including:

  • people management system
  • finance management system
  • IT management system (if IT systems are relied upon as part of customer service operations)
  • asset management system (for office and other assets which might be used)

Similarly, any enterprise subsystem could be subject to change and improvement. In such situations, elements of the business capability management system (eg. program management or project management) may be exercised in effecting improvements to the relevant enterprise subsystem.

With various of these system interdependencies in play, it is critical in planning and executing any improvement initiative for one or more enterprise subsystems, that clarity is established as to:

  • the subsystem(s)-of-interest
  • the containing system(s) of which the subsystem-of-interest may be part
  • the embedded systems which may be part of the subsystem-of-interest

Supporting technology systems

Many organisations have subsystems which are dependent on supporting technology systems, where technology encompasses any entity other than people which represents and enables the application of embedded processes. Examples of subsystems using technology include:

  • manufacturing production subsystems which operate production lines, robots, and other machinery
  • hospital intensive care subsystems which use highly sophisticated medical monitoring and life support technology
  • the vast array of organisations that use IT systems to support finance management subsystems, people management subsystems, customer management subsystems and other enterprise subsystems

This extends the system-of-systems line of thinking into addressing more complex networks of people-based-systems (soft systems) and technology-based-systems (hard systems), enabling consideration of:

  • subsystems composed of a combination of soft and hard systems
  • differing relationships and dependencies, where a single technology-based-system might provide support to multiple people-based-systems and a single people-based-system may be reliant on multiple technology-based-systems
  • application of differing methods required to deal with soft systems versus hard systems

It is in such situations of complexity that architectural methods are applied to enable multiple stakeholders and multiple solution design and delivery roles to develop shared views and deliver solution components that can be integrated into the full system-of-systems. This is where various forms of abstraction are applied to consider the parts of the enterprise requiring change and improvement, including:

  • inclusion and exclusion of subsystems
  • composition and decomposition of subsystems
  • generalisation and specialisation of subsystems

These issues are explored in other articles, including: