Search Results for: open group

What Happened to the Fine Art of Business Analysis? – Revisited 2013

by
Back in 2008, I wrote a paper on Business Analysis. Recently, I’ve been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in italics).

The role of the Business Analyst has never been more important but needs refocus on Information Systems not the technical solution. Many of us can recall a time when a distinction was made between the hardware and software supporting the business and the information used by the business – there was a clear difference between IT, to describe the former, and IS to describe the latter. 
IS stood for Information Systems: 
IS: The landscape  of business  information used by people within an organisation 
and how they use information to deliver business outcomes. 

IT, in contrast, meant: 
IT:  The  hardware  and  software  technology  that  automates  or  otherwise  supports 
information processing. 

This distinction between these two concepts is all but lost, and the disciplines associated with Information Systems (such as Business Analysis and IS Architecture), are have become too obsessed with IT. 

Where did the Business Analysts go? 
The change of focus was probably, in part, caused by the rise in enterprise software packages and the associated promise that these out­-of­-the-­box solutions could work miracles – magically automating all kinds of business processes and spraying efficiency glitter over all parts of the organisation. Powerful promises! 
And to make them even more seductive, they contrasted sharply with often, expensive and unsatisfactory, custom­-build software projects. Small wonder then, the new-kids-on-the-block, ­ERP packages,­ were seen as being more business relevant: enforcing standardisation and promising to boost efficiency. Business Analysts started to abandon their ‘real job’ to become, in effect, package ‘fit­-and­-configuration’ specialists. Inevitably, their work began to focus on the features and functions of the software, rather than the realities of the business with its complexities: messy processes and human interactions. 
Since then, others with expertise in IS, have gravitated to the world of IT architecture. This discipline has proved increasingly important with the many large organisations who realise that packages – even so called ‘enterprise-­wide’ ones, need to coexist the rest of the IT estate. You can’t buy architecture in-a-box!
At the same time, the revolution in Open Source and Web technologies meant that the focus of architecture began to move away from the organisation’s internal IS needs and towards the emerging global IT standards, tools and methods used by its customers, suppliers and partners. The sheer complexity of all aspects of ‘architecture’ meant that areas of technology­-focused specialism began to develop within the architecture community. 
This article suggests, it’s time to dust-off the concept of Information Systems, and return to  business analysis practice that focuses on:
Simplifying [as much as makes-sense], balancing  and consolidating requirements across all aspects of  the business, but with, the important business outcomes, front­-of­-mind. 
Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services. 
Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions. 
Studying the elementary aspects of the business’s Information System such as rules and constraints embedded in policies, the business­-meaningful, real­-world, events of interest and the information content being exchanged between individuals and groups. 
Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’. 

What’s in a Word? The Problem with ‘Process’ 

There appears to be a problem with how we use the word ‘process’. To support business efficiency goals, many envisage the world as a set of neatly ordered, well planned, pre­determined and logically sequenced set of activities – just as Henry Ford did when he introduced the production line. This is hardly surprising as it is a tried and tested approach to manufacturing, and more generally reflects a simple but intelligent goal – to be more efficient at a task through understanding and optimising all the steps. However, optimisation and automation require all the steps and parties involved to be specifically defined, so this approach usually seeks to ‘decompose’ the task into detailed models of all the interacting parts within the end­-to-­end process. The process being defined is also typically mapped to an organisational framework and financial models which constrain it within central and departmental rules, polices and edicts, which are often inherited from corporate decisions unrelated to the process in-­hand. This is Six-Simga-Everything mentality! The most critical problem with this efficency-only focus, is in its  poor representation of the softer, more knotty problems associated with differing values, policies, and operational ‘realities’.
To add to this problem, the language of users differs significantly from that of the IT specialist. This difference in language is a reflection of apparently opposing values (value systems) in play. Fundamentally, the users want a system that works the way they do ­one which is often prone to change and which supports learning. The IT specialist seeks a high degree of functional certainty and actionable rules that can be configured or encoded. 
(see note about ‘Agile’ SDLC at little later).

To make matters worse, the gaps and inconsistencies in the expression of business requirements force a high degree of IT ‘engineering rigour’ that attempts to complete the picture. IT engineering relies upon techniques and tools that are designed to convert process and policy into precise rules and constraints. This can result in important behavioural dimensions ­such as the effect of variance in values and levels of trust – being left unspecified, and tension-points left unresolved. The dialogue between user and the IT specialist becomes focused on the detailed features and functions of the IT ‘solution’. The business outcomes of the sponsoring executive become obscured by this drive towards detail and by the end-users’ individual, and collective, ideas on how the ‘solution’ will work. 
C-level ‘Businesss Stakeholder Standardisation Edicts’ or sent out in an attempt to ‘Get Things Back on Track’: ensure that operational efficiency goals are met and key business outcomes are delivered. This can result in an unwitting collusion between the C-level ‘Business Stakeholder’ and the IT specialist: both parties are motivated to build ‘standardised’ behaviour into the IT solution.

The top­-down edict approach to driving IT­-enabled business change projects suffers from three major problems: 

Adoption Barriers ­ 
The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions 
Brittle Processes ­
The top­-down specification of process works against flexibility and becomes a barrier to future business change. 

Business/IT Misalignment ­
The organisational and management models of the business are not properly reflected in the IT solution. In, for example, a multinational business with diverse operations, it may be necessary and desirable to allow for local freedom­-to­-act, in say, Customer-facing processes. 
It seems we need a different approach to how we specify requirements for IT: an approach that balances the desired business outcomes of the stakeholder with the needs of the user, yet with the precision needed by the IT specialist. 

Significant improvements are being claimed by the ‘Agile’ development  community, however, the problem still exists when likes of SCRUM and XP don’t apply, such as the deployment of a package solution or, increasingly, the purchase of SaaS. Not to mention, that  ‘Agile’ approaches can be left wanting when in comes to cyber-security and data privacy.

It appears that the language-used, and a premature focus on IT, are at the root of this problem.  The language problem starts with how we express the concept of processes.  The word ‘process’ can have very different meanings and implications. These can range from the loose collection of unsystematic activities, that might support a contract negotiation, or an HR process, to the highly repetitious, and predetermined behaviour, of say, a production line. Maybe a common language for describing the range of business behaviour, across any type of process, would help?
A premature obsession with the details of the IT solution, seems to drive the analysis of the business problem towards IT engineering methods. Such methods often ignore or, at best, neglect softer, human, aspects. IT engineering methods and techniques are designed to drive completeness and precision for systems and, in doing so, introduce a language that is, by its nature, hard for the business to understand. This creates frustration on both sides of the Business/IT divide: neither party understanding the needs of the other.  The sheer volume of information produced during the engineering life­-cycle, means the overall business context gets lost in the production of  flow diagrams and technical plans. The complexity of the task requires a high degree of technical specialism. This can lead to a lack of focus on the nuances of real-world behaviour and human interaction ‘on­-the-ground’. Often the focus is slanted towards engineering ‘How’ rather than the business ‘What’: the business outcome. 
The reality is that many business scenarios are more organic, and unpredictable, than  pre-determinable, and mechanistic. In today’s connected world, many business scenarios encounter tensions ­ between corporate and local functions, between customer and supplier, and between partners. No one is in control of the end­ end processes; rather, a combination of interacting service agreements make up the overall value delivered to the customer. 
In contrast to usual business/IT dialogues, what’s needed is a natural-language that moves the focus away from any technologies and towards business behaviour – as expressed in values, policies, real­-world events and any type of information [Content] being exchanged.  

The original article bangs-on about VPEC-T and, our then, current, book ‘Lost In Translation‘, which I’ll skip now [sigh of relief for many!]. I would end the article differently now.  In hindsight, it missed-out some more fundamental (and frankly, more broadly applicable techniques) such as SWOT, Risk-Radar, Hypothesis-led and PESTLE analysis. Perhaps more importantly, I would emphasise the value of; ‘abstraction’ (conceptual and logical ‘What’ before ‘How’ thinking), an understanding of ‘Complex Systems’ – The Cynefin Model (Dave Snowden) would be a good starting point –  and  workshop techniques such as those described in ‘Gamestorming‘ (Dave Gray, Sunni Brown and James Macanufo).
I recently came across the ‘Brown Cow Model‘  (Suzanne & James Robertson) when wrestling with a culture of ‘How’ before ‘What’ behaviour  – aka ‘I have the solution, so what’s the problem’ ! I love the simplicity of ‘Brown Cow’:

I’ve found this simple model a great way to keep project teams focused on understanding the ‘What’ before the ‘How’ and the importance of knowing the AS-IS situation before leaping to the TO-BE. This, for example, has opened-up the requirements discussion to include the, often-overlooked, business requirements of the transition between ‘Now’ and ‘Future’ states. Maybe, this is more of a problem here in Asia, but given some experiences I had in the UK over the past five years, I suspect not!

 I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.

What Happened to the Fine Art of Business Analysis? – Revisited 2013

by
Back in 2008, I wrote a paper on Business Analysis. Recently, I’ve been revisiting this subject in my day-job and this made me realise how little things had changed and inspired me to write this post, which is, basically, the original article re-written, with additional thoughts (in italics).

The role of the Business Analyst has never been more important but needs refocus on Information Systems not the technical solution. Many of us can recall a time when a distinction was made between the hardware and software supporting the business and the information used by the business – there was a clear difference between IT, to describe the former, and IS to describe the latter. 
IS stood for Information Systems: 
IS: The landscape  of business  information used by people within an organisation 
and how they use information to deliver business outcomes. 

IT, in contrast, meant: 
IT:  The  hardware  and  software  technology  that  automates  or  otherwise  supports 
information processing. 

This distinction between these two concepts is all but lost, and the disciplines associated with Information Systems (such as Business Analysis and IS Architecture), are have become too obsessed with IT. 

Where did the Business Analysts go? 
The change of focus was probably, in part, caused by the rise in enterprise software packages and the associated promise that these out­-of­-the-­box solutions could work miracles – magically automating all kinds of business processes and spraying efficiency glitter over all parts of the organisation. Powerful promises! 
And to make them even more seductive, they contrasted sharply with often, expensive and unsatisfactory, custom­-build software projects. Small wonder then, the new-kids-on-the-block, ­ERP packages,­ were seen as being more business relevant: enforcing standardisation and promising to boost efficiency. Business Analysts started to abandon their ‘real job’ to become, in effect, package ‘fit­-and­-configuration’ specialists. Inevitably, their work began to focus on the features and functions of the software, rather than the realities of the business with its complexities: messy processes and human interactions. 
Since then, others with expertise in IS, have gravitated to the world of IT architecture. This discipline has proved increasingly important with the many large organisations who realise that packages – even so called ‘enterprise-­wide’ ones, need to coexist the rest of the IT estate. You can’t buy architecture in-a-box!
At the same time, the revolution in Open Source and Web technologies meant that the focus of architecture began to move away from the organisation’s internal IS needs and towards the emerging global IT standards, tools and methods used by its customers, suppliers and partners. The sheer complexity of all aspects of ‘architecture’ meant that areas of technology­-focused specialism began to develop within the architecture community. 
This article suggests, it’s time to dust-off the concept of Information Systems, and return to  business analysis practice that focuses on:
Simplifying [as much as makes-sense], balancing  and consolidating requirements across all aspects of  the business, but with, the important business outcomes, front­-of­-mind. 
Identifying repeating patterns of business activity and seeking out opportunities for shared competencies and services. 
Understanding the behavioural aspects of the business that have been proven to be barriers to adoption of IT solutions. 
Studying the elementary aspects of the business’s Information System such as rules and constraints embedded in policies, the business­-meaningful, real­-world, events of interest and the information content being exchanged between individuals and groups. 
Communicating and agreeing upon the business ‘what’ before getting immersed in the technology ‘how’. 

What’s in a Word? The Problem with ‘Process’ 

There appears to be a problem with how we use the word ‘process’. To support business efficiency goals, many envisage the world as a set of neatly ordered, well planned, pre­determined and logically sequenced set of activities – just as Henry Ford did when he introduced the production line. This is hardly surprising as it is a tried and tested approach to manufacturing, and more generally reflects a simple but intelligent goal – to be more efficient at a task through understanding and optimising all the steps. However, optimisation and automation require all the steps and parties involved to be specifically defined, so this approach usually seeks to ‘decompose’ the task into detailed models of all the interacting parts within the end­-to-­end process. The process being defined is also typically mapped to an organisational framework and financial models which constrain it within central and departmental rules, polices and edicts, which are often inherited from corporate decisions unrelated to the process in-­hand. This is Six-Simga-Everything mentality! The most critical problem with this efficency-only focus, is in its  poor representation of the softer, more knotty problems associated with differing values, policies, and operational ‘realities’.
To add to this problem, the language of users differs significantly from that of the IT specialist. This difference in language is a reflection of apparently opposing values (value systems) in play. Fundamentally, the users want a system that works the way they do ­one which is often prone to change and which supports learning. The IT specialist seeks a high degree of functional certainty and actionable rules that can be configured or encoded. 
(see note about ‘Agile’ SDLC at little later).

To make matters worse, the gaps and inconsistencies in the expression of business requirements force a high degree of IT ‘engineering rigour’ that attempts to complete the picture. IT engineering relies upon techniques and tools that are designed to convert process and policy into precise rules and constraints. This can result in important behavioural dimensions ­such as the effect of variance in values and levels of trust – being left unspecified, and tension-points left unresolved. The dialogue between user and the IT specialist becomes focused on the detailed features and functions of the IT ‘solution’. The business outcomes of the sponsoring executive become obscured by this drive towards detail and by the end-users’ individual, and collective, ideas on how the ‘solution’ will work. 
C-level ‘Businesss Stakeholder Standardisation Edicts’ or sent out in an attempt to ‘Get Things Back on Track’: ensure that operational efficiency goals are met and key business outcomes are delivered. This can result in an unwitting collusion between the C-level ‘Business Stakeholder’ and the IT specialist: both parties are motivated to build ‘standardised’ behaviour into the IT solution.

The top­-down edict approach to driving IT­-enabled business change projects suffers from three major problems: 

Adoption Barriers ­ 
The users are less inclined to adopt the IT solution, claiming that it doesn’t work for them – they continue to use and develop ‘shadow’ IT solutions 
Brittle Processes ­
The top­-down specification of process works against flexibility and becomes a barrier to future business change. 

Business/IT Misalignment ­
The organisational and management models of the business are not properly reflected in the IT solution. In, for example, a multinational business with diverse operations, it may be necessary and desirable to allow for local freedom­-to­-act, in say, Customer-facing processes. 
It seems we need a different approach to how we specify requirements for IT: an approach that balances the desired business outcomes of the stakeholder with the needs of the user, yet with the precision needed by the IT specialist. 

Significant improvements are being claimed by the ‘Agile’ development  community, however, the problem still exists when likes of SCRUM and XP don’t apply, such as the deployment of a package solution or, increasingly, the purchase of SaaS. Not to mention, that  ‘Agile’ approaches can be left wanting when in comes to cyber-security and data privacy.

It appears that the language-used, and a premature focus on IT, are at the root of this problem.  The language problem starts with how we express the concept of processes.  The word ‘process’ can have very different meanings and implications. These can range from the loose collection of unsystematic activities, that might support a contract negotiation, or an HR process, to the highly repetitious, and predetermined behaviour, of say, a production line. Maybe a common language for describing the range of business behaviour, across any type of process, would help?
A premature obsession with the details of the IT solution, seems to drive the analysis of the business problem towards IT engineering methods. Such methods often ignore or, at best, neglect softer, human, aspects. IT engineering methods and techniques are designed to drive completeness and precision for systems and, in doing so, introduce a language that is, by its nature, hard for the business to understand. This creates frustration on both sides of the Business/IT divide: neither party understanding the needs of the other.  The sheer volume of information produced during the engineering life­-cycle, means the overall business context gets lost in the production of  flow diagrams and technical plans. The complexity of the task requires a high degree of technical specialism. This can lead to a lack of focus on the nuances of real-world behaviour and human interaction ‘on­-the-ground’. Often the focus is slanted towards engineering ‘How’ rather than the business ‘What’: the business outcome. 
The reality is that many business scenarios are more organic, and unpredictable, than  pre-determinable, and mechanistic. In today’s connected world, many business scenarios encounter tensions ­ between corporate and local functions, between customer and supplier, and between partners. No one is in control of the end­ end processes; rather, a combination of interacting service agreements make up the overall value delivered to the customer. 
In contrast to usual business/IT dialogues, what’s needed is a natural-language that moves the focus away from any technologies and towards business behaviour – as expressed in values, policies, real­-world events and any type of information [Content] being exchanged.  

The original article bangs-on about VPEC-T and, our then, current, book ‘Lost In Translation‘, which I’ll skip now [sigh of relief for many!]. I would end the article differently now.  In hindsight, it missed-out some more fundamental (and frankly, more broadly applicable techniques) such as SWOT, Risk-Radar, Hypothesis-led and PESTLE analysis. Perhaps more importantly, I would emphasise the value of; ‘abstraction’ (conceptual and logical ‘What’ before ‘How’ thinking), an understanding of ‘Complex Systems’ – The Cynefin Model (Dave Snowden) would be a good starting point –  and  workshop techniques such as those described in ‘Gamestorming‘ (Dave Gray, Sunni Brown and James Macanufo).
I recently came across the ‘Brown Cow Model‘  (Suzanne & James Robertson) when wrestling with a culture of ‘How’ before ‘What’ behaviour  – aka ‘I have the solution, so what’s the problem’ ! I love the simplicity of ‘Brown Cow’:

I’ve found this simple model a great way to keep project teams focused on understanding the ‘What’ before the ‘How’ and the importance of knowing the AS-IS situation before leaping to the TO-BE. This, for example, has opened-up the requirements discussion to include the, often-overlooked, business requirements of the transition between ‘Now’ and ‘Future’ states. Maybe, this is more of a problem here in Asia, but given some experiences I had in the UK over the past five years, I suspect not!

 I about to run out of battery on my iPad now – so that’s all for now. As always, I ask for your comments! Thx.

From Business Design to Business Change (#3) – The Learning Circle

by

<p><span class=”s1″>Let us suppose you are to consult in the redesign of the ‘Incident Management’ process in a business-IT environment. This is not necessarily rocket science. But what do you do when the managers of the six different teams involved in the process have overlapping views on the roles of their teams? How do you avoid the pitfall of endless discussions on roles and responsibilities between teams and business units? And how do you take advantage of the involvement of the employees to arrive at a workable and acceptable solution?</span></p><p><span class=”s1″>The case I write about in this blog is situated in a governmental service organization, 15k+ employees, where a restructuring of the organization required this cross-business unit redesign. This case represents a nice example of how I recently encountered the <a href=”http://www.bizzdesign.com/blog/from-business-design-to-business-change-1-the-content-paradox/” target=”_self”>content paradox</a>.</span></p><p><span style=”font-size: 11px; line-height: 19px;”><img alt=”” class=”right” longdesc=”Improvisation on television” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/Business-design-business-change-improvisation_large.jpg” style=”width: 180px; height: 124px; float: right;” title=”Improvisation. Dutch TV show the Lama’s”/>A traditional design approach would start out by trying to define a design scope and process requirements by interviewing stakeholders. We assumed this approach would be a one-way ticket to views a world apart. We looked at other options and our good experiences with </span><a href=”http://www.bizzdesign.com/blog/business-games-1-of-4-why-and-when-of-gaming/” style=”font-size: 11px; line-height: 19px;” target=”_self”>serious gaming</a><span style=”font-size: 11px; line-height: 19px;”> </span><span style=”font-size: 11px; line-height: 19px;”>came to mind. What I personally like about it is that participants are caught in the moment and have to improvise. Sensible decisions and behaviour just arise. We used this effect to kick-start our design process. We organised what we called a Learning Circle with participants from each team.</span></p><p> </p><h2>The Learning Circle</h2><p><span class=”s1″>We planned a full day for the Learning Circle workshop. We had one of the team managers as the sponsor for our approach. He asked all other team managers to send two or three employees to participate, in total about fifteen people. The participants had no idea what to expect and came without preparation. The workshop had three parts:</span></p><ul><li class=”li1″><span class=”s2″>The first part of the session was the <b>gaming</b>-part. We started from scratch with a simulation, as if the future process was already there. The idea was to just see what would happen, to experiment and to harvest the issues that would naturally arise.</span></li> <li class=”li1″><span class=”s2″>T</span><span class=”s2″>he second part of the session was the <b>dialogue</b>-part. For every issue teams were asked to share their view with the other teams. No discussion, just sharing of truths.</span></li> <li class=”li1″>T<span class=”s2″>he third part of the session was the <b>solution</b>-part. The participants were split into two groups with all teams represented in both groups. The groups were asked to come up with a draft proposal addressing as much issues as possible. Issues could also be put in the ‘for management to decide’ box.</span></li></ul><h2 class=”li1″><span class=”s2″>​The gaming part</span></h2><p><span class=”s1″><img alt=”” class=”right” longdesc=”Learning Circle” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/Learning-Circle-workshop-set-up_large.png” style=”width: 171px; height: 180px; float: right;” title=”Learning Circle workshop set-up”/>The participants were seated into a half circle, grouped in teams, facing a number of flip over sheets put on the wall. We asked the participants to imagine as if the process to-be was already in place and they were performing their future roles already – whatever that might be. In case of doubt we asked them to act the way they would find most logical or sensible for the organisation as a whole and its (internal) customers.</span></p><p><span class=”s1″>We triggered the incident process by presenting typical incident calls and handing over a marker pen to the team that first indicated they would receive it. The rules of the game were simple:</span></p><ol><li><span class=”s1″>​</span><span class=”s1″>The team with the marker pen decides how they act themselves and which team they trigger next by handing over the marker pen.</span></li> <li><span class=”s1″>The team with the marker pen is allowed to discuss among themselves what to do. The other teams are to remain silent</span></li> <li><span class=”s1″>The team with the marker pen writes down on the flip over sheet which activities they perform (if any!) and what result or information they pass on to which team</span></li> <li><span class=”s1″>All other participants are allowed at any time to come forward, in utter silence, with a sticky note with their initials. They can place it on the flip over sheet on the spot where they want to raise an issue (or question).</span></li></ol><p><span class=”s1″>​<img alt=”” class=”left” longdesc=”The power of silence” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/Learning-circle-the-silence-rule_medium.gif” style=”float: left; width: 120px; height: 113px;” title=”The best and most fun part was the silence rule”/>The harvest of the gaming part was rich. A process developed spontaneously and at the same time the astonishing number of 28 issues were already raised during the handling of the first incident alone – but no panic at all. The best and most fun part was the silence rule. With some small interventions from our side and some grinning of team members even the most control-freaky participants were able to zip it, just let it happen and use their – silent – sticky notes.</span></p><p> </p><h2><span class=”s1″>The dialogue and solution part</span></h2><p class=”p1″><span class=”s1″>After the game we saw curious and smiling faces going for the coffee break. With the notion that each participant would get their turn on expressing their views the atmosphere had become open and calm. After the break issue per issue was addressed. Participants were amazingly patient with each other and interruptions were rare. The result was interesting: without making agreements it was clear that most issues could be resolved. The role of one team appeared to be almost completely omitted in the simulation of the process. Yet the dialogue part gave this team a great platform to position with their tasks themselves in a way that was logical and sensible for the other teams. </span>After sharing six separate truths in a dialogue, the two groups had a good go at resolving the issues and their first ideas were presented. </p><h2 class=”p1″>Follow-up of the Learning Circle</h2><p class=”p1″><span class=”s1″>With just a few issues to be resolved, the overall result was a great kick-start. It brought about a good energy among participants who brought this feeling across to their respective team managers. Next we, as independent consultants, formulated a number of recommendations on the redesign for management. We based this on the results of the Learning Circle. We organised a management meeting to have them decide on these recommendations. We asked the participants to prepare this meeting with their team manager.  The managers were happy that a lot of issues were already tackled by their employees. The open energy was also present on this table. It took management two meetings to resolve all redesign issues and start the implementation. </span></p><p class=”p1″><img alt=”” class=”left” longdesc=”How to bring these different truths together” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/20130515_From-Business-Design-to-Business-Change-3/How-to-bring-different-truths-together_700x184.png” style=”width: 700px; height: 184px; float: left;” title=”All in all it was not about “which team is right?”, but more about “how to bring these different truths together?””/></p><h2 class=”p1″>In conclusion</h2><p class=”p1″><span class=”s1″>In a traditional design approach it is good practice to test a business process design when it is finished in a simulation workshop with employees. In the case above we turned it around! We used the Learning Circle as an open experiment to speed up the design process with a lot of parties involved. Each participant brought along their own mix of ideas, stakes, insecurity on the outcome, personal preferences and historical context. Still, we noticed everyone was in his or her own way committed to deliver a good service in the end. All in all it was not about “which team is right?”, but more about “how to bring these different truths together?”.</span></p>

Categories Uncategorized

How to build a Roadmap – Define End State

by

This post will provide a little more exposition and insight into one method I have found useful in practice for quickly defining desired end states. Done well, it can provide an honest and objective look to successfully understand where we truly want to be as an organization and face the uncomfortable truth in some cases where we need to improve.

Everyday sexism of the subtler kind

by

How does sexism and suchlike become invisibly ingrained in our society? Answer: whenever said sexism is promoted as ‘progressive thinking’… To many people, the term ‘sexism’ applies only to gender-imbalance that directly affects women: yet a few moments thought should…

Corso Introduces Roadmapping Support for TOGAF® 9 in its Strategic Planning Platform

by

By Martin Owen, CEO, Corso Last week, we announced new roadmapping support for TOGAF® in IBM Rational System Architect®, a leading Enterprise Architecture and modeling software. The new TOGAF extension supports the modeling, migration and implementation of an Enterprise Architecture within Corso’s Strategic Planning Platform, which integrates Enterprise Architecture, IT planning and strategic planning into … … Continue reading →

Avoid the PowerPoint-to-Execution Gap: Strategists as Operators

by

Reading a point-of-view piece by Cynthia Montgomery in Rotman Magazine reminded me of a soapbox tweet of mine: “we need to value execution on par with creation”.

That tweet was inspired by a consultation I did on a critical project that had fallen into the PowerPoint-to-Execution Gap.

This project made all the right upfront moves: defined a bold, yet attainable business vision, rallied executive support, hired a top talent technology consultancy, and hand-picked a skunkworks team.

Upon completion of the upfront, they had a well-defined business problem (process, requirements, data, roles), which would be supported by a state-of-art technology architecture. The creation portion was top-notch. 

The problem was that company and project executives assumed that execution would take care of itself. They didn’t recognize that there is a strategic element to execution, involving not just scheduling, but careful packaging and orchestration of development, delivery, acceptance and business transformation activities.

In her Rotman piece, The Role of the Strategic Leader, Montgomery speaks to the often missed leadership component in strategic work, the “ongoing responsibility of leading strategy”.

“A great strategy, in short, is not a dream or a lofty idea, but rather the bridge between the economics of a market, the ideas at the core of a business, and action. To be sound, that bridge must rest on a foundation of clarity and realism, and it also needs a real operating sensibility.”

To illustrate her point, Montgomery — a Harvard Professor — describes how her MBA and Executive Education students inevitably debate the importance of strategy versus execution:

“Every year, early in the term, someone in class always wants to engage the group in a discussion about what’s more important: strategy or execution. In my view, this is a false dichotomy and a wrongheaded debate that the students themselves have to resolve, and I let them have a go at it.”

Montgomery revisits that early term debate with a real-world case on Gucci:

“I always bring that discussion up again at the end of my course, when we talk about Domenico De Sole’s tenure at Italian fashion eminence Gucci Group. De Sole, a tax attorney, was tapped for the company’s top job in 1995, following years of plummeting sales and mounting losses in the aftermath of unbridled licensing that had plastered Gucci’s name and distinctive red-and-green logo on everything from sneakers to whiskey — in fact, on 22,000 different products — making Gucci a cheapened and overexposed brand.

De Sole started by summoning every Gucci manager worldwide to a meeting in Florence. Instead of telling managers what he thought Gucci should be, De Sole asked them to look closely at the business and tell him what was selling and what wasn’t. He wanted to tackle the question “not by philosophy, but by data” — bringing strategy in line with experience rather than relying on intuition. The data were eye opening. Some of Gucci’s greatest recent successes had come from its few trendier, seasonal fashion items, and the traditional customer — the woman who cherished style, not fashion, and who wanted a classic item she would buy once and keep for a lifetime — had not come back to Gucci.

De Sole and his team, especially lead designer Tom Ford, weighed the evidence and concluded that they would follow the data and position the company in the upper middle of the designer market: luxury aimed at the masses. To complement its leather goods, Ford designed original, trendy — and, above all, exciting — ready-to-wear clothing each year, not as the company’s mainstay, but as its draw. The increased focus on fashion would help the world forget all those counterfeit bags and the Gucci toilet paper. It would propel the company toward a new brand identity, generating the kind of excitement that would bring new customers into Gucci stores, where they would also buy high-margin handbags and accessories.

To support the new fashion and brand strategies, De Sole and his team doubled advertising spending, modernized stores, and upgraded customer support. Unseen but no less important to the strategy’s success was Gucci’s supply chain. De Sole personally drove the back roads of Tuscany to pick the best 25 suppliers, and the company provided them with financial and technical support while simultaneously boosting the efficiency of its logistics. Costs fell and flexibility rose.”

The lesson from the Gucci case, according to Montgomery is clear:

“The only way a company will deliver on its promises, is if its strategists can think like operators.”

Montgomery continues:

“In effect, everything De Sole and Ford did — in design, product lineup, pricing, marketing, distribution, manufacturing, and logistics, not to mention organizational culture and management — was tightly coordinated, internally consistent, and interlocking. This was a system of resources and activities that worked together and reinforced each other, all aimed at producing products that were fashion forward, high quality, and good value.

It is easy to see the beauty of such a system of value creation once it is constructed, but constructing it isn’t often an easy or a beautiful process. The decisions embedded in such systems are often gutsy choices. For every moving part in the Gucci universe, De Sole faced a strictly binary decision: either it advanced the cause of fashion-forwardness, high quality, and good value — or it did not and was rebuilt. Strategists call such choices ‘identity-conferring commitments’, and they are central to what an organization is or wants to be and reflect what it stands for.”

Returning to the student debate (and the PowerPoint-to-Execution Gap):

“When I ask executives at the end of this class, “Where does strategy end and execution begin?” there isn’t a clear answer — and that’s as it should be. What could be more desirable than a well-conceived strategy that flows without a ripple into execution? Yet I know from working with thousands of organizations just how rare it is to find a carefully honed system that really delivers. You and every leader of a company must ask yourself whether you have one — and if you don’t, take the responsibility to build it. The only way a company will deliver on its promises, in short, is if its strategists can think like operators.”

Successful strategy demands execution excellence, which starts with an execution strategist. Or, if you are lucky, with one of the rare strategists who think like operators.

Building Networks with Business Models: Two approaches that will help you to understand and improve your value network

by

<p>In an earlier posting we addressed <a href=”http://www.bizzdesign.com/blog/7-applications-of-the-business-model-canvas/”>7 applications of the Business Model Canvas</a>. Sure, we can agree that the Business Model Canvas is very useful for establishing, evaluating and reinventing businesses. But we should not only highlight the countless possibilities of it for a single enterprise. We need to synthesize our understanding of Value Chains and the Business Models and look for the next level of analysis: Value Networks.</p><p>In this blog we will highlight a less addressed aspect from the Business Model Canvas that is rooted in Value Network thinking. There are multiple methods and even tools that support the analysis of Value Networks which is regarded as the collaborations, interactions, and exchanges between business actors. You might have heard or read about <a href=”http://www.amazon.com/Mobile-Service-Innovation-Business-Models/dp/3540792376″ target=”_blank”>STOF</a> and <a href=”http://e3value.few.vu.nl/” target=”_blank”>e3-value</a>. But apart from academic research, Value Networks are less represented in practical settings today. Why? Because of the rapidly increasing complexity of Value Networks – soon we lose track when we think about relations between multiple actors involved in our business such as suppliers, customers, governments, partners, NGO’s. Therefore in this blog we will explain how the simplicity of Business Model Canvas can be used to highlight Value Networks. We discuss an external network approach as well as a more internally oriented network approach.</p><h3>The network is the challenge</h3><p>Imagine a pension fund with three business units – one for asset management, one for customer advice and a third one for customer relationship management and administration – that attempts to broaden its service offerings. We can use the Business Model Canvas to guide this effort. First, we establish the pension fund’s current Business Model Canvas. Then we formulate our goal – which is to broaden the current service offerings. Step by step we elaborate desired Business Model Canvases that include different new service offerings. Finally we selected the most feasible Business Model Canvas for implementation. Business as usual – except that until now we have limited ourselves to only the Business Model Canvas of the pension fund.</p><div class=”captionImage leftAlone” style=”width: 561px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/business-model-canvas-pension-fund.png” alt=”Business Model Canvas pension fund” title=”The main goal is to reach our customers, provide them with our value proposition, and get paid” width=”561″ height=”417″/><p class=”caption”>three main elements of the business model canvas: key partners, enterprise and customers</p></div><p>Although external elements like key partners (1) and customers (3) are included in the Business Model Canvas, at the end of the story the emphasis is on the business model of a single enterprise (2). It seems that key partners are just there to be included in our Business Model Canvas. We also take customers for granted. The main goal is to reach our customers, provide them with our value proposition, and get paid.</p><p>Today more than ever, an isolated view on an organization is not feasible. We are not suggesting that the Business Model Canvas only provides an isolated view. Instead, we want to add some additional support to the Business Model Canvas to broaden and deepen its application from the perspective of Value Networks. This support comes in the form of a Networked and an Aggregated Business Model Canvas.</p><h3>The chained network approach</h3><p>Lets think about the pension fund example again. In addition to the single enterprise view of the Business Model Canvas we should also consider the canvases of our partners and customers for broadening our service offerings. That way we will be able to highlight the interactions of the pension fund and its actors for the sake of the pension fund and its actors –so basically focusing on the Value Network instead of a single company in order to retrieve additional insights that might not be highlighted through a single Business Model Canvas.</p><p> </p><div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600210-canvases-of-partners-and-customers.png” alt=”chained network approach” title=”Does the entire Value Network benefit from newly offered services of the pension fund?” width=”600″ height=”210″/><p class=”caption”>consider the canvases of our partners and customers for broadening our service offerings</p></div><div class=”captionImage leftAlone” style=”width: 561px;”><div class=”captionImage leftAlone” style=”width: 561px;”><span style=”font-size: 11px;”>By representing the Value Network through Networked Business Model Canvases we could answer new questions like: How can we broaden our service offerings through the current Value Network? What improvements can we implement? Does the entire Value Network benefit from newly offered services of the pension fund?</span></div></div><p>Now we are able to involve our partners as well and benefit as a group from the applications of the Business Model Canvas by:</p><ul><li>considering the potential improvement for all value network actors;</li><li>identifying (un)equal distributions of risks, costs and profits for actors based on changes in the value network;</li><li>and using the capabilities and knowledge of all actors to improve the value network;</li><li>Address opportunities of <a href=”http://en.wikipedia.org/wiki/Disintermediation” target=”_blank”>disintermediation</a> concerning removal of intermediaries from a value chain;</li><li>Apply (elements of) the unbundling pattern (page 62), concerning specialization. In commoditizing markets successful organizations focus on either Product Innovation, Customer Relationship Management or Infrastructure Management. Also see <a href=”http://www.amazon.com/Discipline-Market-Leaders-Customers-Dominate/dp/0201407191″ target=”_blank”>Tracy &amp; Wiersema’s value disciplines</a> and <a href=”http://en.wikipedia.org/wiki/Porter_generic_strategies” target=”_blank”>Porter’s generic strategies</a>.</li></ul><h3>The aggregated network approach</h3><p>In addition to a networked Business Model Canvas we can also establish an aggregated Business Model Canvas for the pension fund. Think about the individual business units that are part of the pension fund. While customers may perceive the pension fund as one entity, business units could be independent in terms of their financial performances. Each business unit operates independently and is responsible for own results and achievements. However, because all business units are part of the same pensions fund, the might be using each other’s assets, serve similar customers and share similar partners. Actually a customer could be advised by one business unit on his savings and investment plans, while the same investments could be managed by the assets management business unit. Along the process the customer wants to experience being served consistently by one organization – the pension fund – instead of separate business units. Providing such consistency is obviously important for the pension fund and its business units. But how can they start addressing related issues? And all business units have other internal and external customers as well….</p><p>That is when the aggregated Business Model Canvas comes into play. First we need to establish the individual Business Model Canvases of the pension fund and its business units. Then we need to examine the relations between building blocks across the network by connecting the Business Model Canvases.</p><p> </p><div class=”captionImage leftAlone” style=”width: 600px;”><img class=”leftAlone” src=”http://www.bizzdesign.com/assets/BlogDocuments-2/_resampled/resizedimage600219-Aggregated-Business-Model-Canvas.png” alt=”aggregated Business Model Canvas” title=”Along the process the customer wants to experience being served consistently by one organization instead of separate business units” width=”600″ height=”219″/><p class=”caption”>The aggregated business Model Canvas asks more questions</p></div><p>Again this allows us to answer additional questions like: How can we improve our corporate business model? Is each business unit aligned properly with the corporate organization? What similar partners are used by the different business units? Do we collaborate sufficiently to provide consistent service quality to our customers? Where are opportunities for synergy?</p><p>Now we are able to understand our internal model and consider our business models as complementary parts of the same aggregated model. Benefits of applying this internal network approach are:</p><ul><li>Aligning the whole with its parts</li><li>Learn from each other: using the capabilities and knowledge of all actors to improve the network</li><li>Understand and learn how costs and value creation are distributed throughout the organization in more detail then seen when only creating an enterprise view</li><li>identifying (un)equal distributions of risks, costs and profits for business units based on changes in the value network;</li><li>Understand and manage differences in the business unit’s business models</li><li>Understand and benefit from synergies between the different business models</li></ul><h3><span style=”color: #e3004a; line-height: 14px;”><span style=”color: #e3004a;”><span style=”line-height: 14px;”>Conclusions and advice for applying business model networks in practice</span></span></span></h3><p><span style=”color: #e3004a; line-height: 14px;”><span style=”color: #e3004a;”><span style=”line-height: 14px;”> </span></span></span>Supported by the alternative application suggestions of het Business Model Canvas discussed above, we recommend you to:</p><ol><li>Establish your current business model canvas</li><li>Establish the business model canvases of your internal and external customers</li><li>Establish the business model canvases of your internal and external partners and suppliers</li><li>Interconnect and aggregate the business model canvases</li><li>Assess the effectiveness of the network in term of experienced pain and gain by each partner</li><li>Elaborate opportunities to improve the networks performance as a whole</li><li>Work out these opportunities by following each dependency relation through the network, taking into account pains and gains addressed by each actor in the network</li><li>Establish an integrated implementation plan for the whole</li><li>Establish detail implementation plans for each partner</li></ol><p>Whether the additional Business Models concern internal or external customers and partners, in both cases you will benefit from the additional insights – you will improve your understandings of your own business model as well as the business models of your stakeholders and together you will be able to identify improvement opportunities in your value network. At the end of the day no business operates on its own. Every organization has to collaborate to different extends with multiple actors. Trends that are already here to stay, and trends that should be on your agenda today, all underline the importance of collaboration and require insight in your network. Supply chain management, co-creation, open innovation, knowledge sharing, social enterprise, big-data, predictive analytics.<br/><strong><em>“Understanding your business model is only a first step in understanding your value network.”</em></strong></p><p>We look forward to helping you achieve your goals in the new, networked, normal!<br/>BiZZdesign organizes <a href=”http://www.bizzdesign.com/training/business-model-management/”>training on Business Model Innovation</a> in London (UK), Brussels (BE) and Amersfoort (NL – <a href=”http://www.bizzdesign.nl/training/business-model-management/”>see our Dutch website</a>). More about BiZZdesign’s Business Model Management services, examples and a reference to recent webinars on this subject can be found <a href=”http://www.bizzdesign.nl/consultancy/business-model-management/”>here</a>. Feel free to download the <a href=”http://www.bizzdesign.com/tools/business-model-canvas-module/”>free trial version of our Business Model Canvas tool</a> from our website.</p><p> </p><p> </p>

The Interconnectedness of All Things

by

Cloud, SOA, Enterprise Mobility, Social Media/Enterprise/Business, The Internet of Things, Big Data (you name it) – each in its own way is part of an overall tendency. The general trend is for enterprises to become increasingly involved in increasingly broad ecosystems. … Continue reading →

Enterprise as a … System

by

Notwithstanding the earnest way some people use the phrase “enterprise-as-a-system”, I don’t see any great significance in regarding an enterprise or organization as a system.

Indeed, given the very broad way people commonly use the word “system”, it is difficult to think of anyway to regard an enterprise other than as some kind of system. A machine or complicated technological assembly is a system; a human activity or social unit is a system; an abstract legal or procedural process is a system. All of the chapters in Gareth Morgan’s book Images of Organization represent organizations as different kinds of system. And even if we don’t regard an enterprise as quite the same as an organization, what could an enterprise possibly be, from anyone’s perspective, other than some kind of system?

And many popular architecture frameworks claim to regard an enterprise as a system. For example

  • TOGAF considers the enterprise as a system (TOGAF9, Chapter 2) 
  • Enterprise architecture structures the business planning into an integrated framework that regards the enterprise as a system or system of systems. (TOGAF9 Chapter 6)

Elsewhere in TOGAF however, as well as in ArchiMate, we can find reference to systems OR organizations, which suggests that they do not regard the enterprise as a system.

    Some people claim to regard the enterprise as a system, and then offer a layered schema with System Layer near the bottom. This represents a shift in the use of the word “system”.

    However, when people use the phrase “enterprise-as-a-system”, they may well have a particular kind of system in mind. Here are some examples.

    Enterprise as a sociotechnical system

      Enterprise as a socio-cultural—techno-economic system

      Enterprise as a human activity system

        Enterprise as a self-organizing system

          Enterprise as an open or closed system

          Clearly it is the adjective that helps to make this phrase meaningful.

          See also
           
          Alan Hakimi, Addressing the Multi-Dimensionality Challenge on Thinking of The Enterprise as a System (Feb 2013)

          Linked-In Discussion Enterprises *NOT AS* Systems (April 2013 onwards)

          Categories Uncategorized