A number of years ago, I was transforming a city’s social care directorate and, as part of that transformation, we aimed to reduce the time it took to do anything when interacting with the service. The transformation was based on a more fundamental need to free up workers to be able to do the work they were meant to do rather than having to fight the fires caused by delays and resulting failure demand. I instigated a methodical approach for identifying which cycles to focus on first. As the team progressed through the cycles, I noticed a pattern; it’s the spike of activity followed by a lengthy delay as discussed in a previous article.
As we looked in particular at a few cycles of spike followed by a delay, I routinely advised the team to question the need for that common feature of bureaucracy: the signature.
Why require a signature?
In the case of social care, signatures are often required from service users or their representatives. This can be as proof that the content of a form is accurate or as a record of the service user providing consent (either for data to be shared from the form or for the authority to request data from other agencies).
These signatures create the spike-delay pattern in which a short spike of activity is followed by a lengthy delay while the authority sends the form to the customers and waits for the return of a signed copy. Part of that delay is caused by the postal service in both directions. Part will be the time it takes the service user to open the letter, read the form, make amendments, find an envelop and stamp and then go to the post box. Considering the high percentage of infirm service users compared to the general population, that sequence of activities can take a long time. Then we have the additional wait time caused by processing the response as it arrives into the authority.
So, my first instinct is to remove the need for a signature and thereby remove the need for the spike-delay round. This could be changed from requesting a signature to providing information on the form that the data will be used. If you don’t agree, don’t submit the form. The response from staff was that we needed the signature as a record of consent and/or accuracy, depending on the form in question.
On the fact of it, that seems a reasonable and fair response.
What does the evidence say?
However, the data showed a different reality. What actually happened is that, even if the form wasn’t returned, the process could still go ahead. True, it didn’t go ahead for every service user, but the fact that it could proceed implied that the signature wasn’t always required. Or rather, wasn’t required all of the time. We were able to look at the data to understand how many service users progressed without signature, we were able to look at common characteristics, etc.
By presenting this understanding back, we ended up moving forward in our joint understanding of the process; joint in that the consultant and the team had the same understanding. Before that point, they had had different interpretations.
So where does that leave us?
An undocumented process or exception is a risk. In the above case, we had uncovered that some of the cases were allowed to progress without signature, but there was no documentation defining which cases could proceed and which cases had to stop. Instead it was left to individual judgment, but again without defined criteria. So what happens if the usual staff members weren’t present? Were the decisions they made equal and equitable to all involved? How did we measure the outcomes?
Depending on the type of organisation and service involved, there will be a different focus regarding the risk involved.
In this case, we had a process with an unclear gateway, e.g. do we continue or do we halt and wait?
Complete the analysis in terms of understanding when the process can continue.
Engage with service users to understand what they need out of the process, what their engagement should be
As a team, choose a default option, either they progress by default or they pause by default
Help the team define the rules that govern the exceptions
Implement a training and induction programme for ensuring that everyone knows how to apply the rules
I always prefer the default option to be the one that improves efficiency, e.g. the one that’s the most common option or the one that removes a spike-delay pattern.
The wider understanding that, in most cases, the signature wasn’t required let us to a better solution. Had we not challenged either with data or further questioning, we would have been left with the difficult situation of lack of signatures stopping the process and the resulting action of requiring signatures in order to proceed. Instead by challenging the assumption and developing solutions to the issues of the spike-delay caused by several signatures for a sequence of documents, we were able to reduce the expected time from 6 months down to just over one day (actually 2.5 completions per week). That’s a massive difference in expectations for customer and the organisation serving the customer.
How long does it take you to do what your customers want? Not just the first part, but the whole of it?
1. The Pattern
I see this pattern commonly replicated across service industries. It involves a very short spike of activity (e.g. 5-20 minutes) followed by a lengthy delay where something is sent to the customer and the organisation waits for the return. This is followed by a 2nd spike of activity which in turn is followed by another lengthy delay. Depending on the bureaucracy involved, this process may involve several rounds of spike and delay, each adding to the overall delay in service for the customer and, most likely, increasing failure demand on the organisation.
2. Some Samples
Let’s have a look at a few industries and see how this pattern plays out:
2a. Retail Industry
Take for example, ordering a new item of furniture. We’ll start at the sales phase – although the complete process starts before then with marketing or customer acquisition – where the customer is in the retail store.
The customer, let’s call her Lilly, is buying a bed. Lilly spends up to an hour viewing and trying beds on a Saturday afternoon, talking to the sales advisor and then committing to buying one particular bed. The sales advisor creates the order, takes details in order to arrange finance, takes some information regarding proposed delivery times.
This is the first spike. There may be finance involved and almost definitely delivery involved. Lilly is told that the delivery company will contact her by the end of the week. That’s the first disappointment, can’t they arrange delivery now for later that week? Instead, she begrudgingly continues with the order hoping for a delivery time that meets her needs.
Some customers stop the order and go elsewhere. They’ve arrange finance, but may not have committed at this stage. For Lilly, who continues with the order, she goes home, then spends her week as normal waiting for the phonecall. This is the first of the delays. In Lilly’s case, the delivery company ring her on Tuesday, two working days after the order. Two days is a long time when you’re waiting. And it’s definitely a long time when compared to the processing time in the showroom on that Saturday afternoon. So it would not have been surprising had she rang the salesman on Monday or even Tuesday morning, creating failure demands disturbing him from achieving more sales.
The delivery company have a van that delivers to Lilly’s area on Tuesdays but she’s missed the delivery for that week so it will be the following Tuesday. This is the second spike followed by the second delay.
The week passes and Lilly receives the bed at her house. She finds there’s a part missing and calls the number. There’s a spike of activity as the after-sales staff figure out what’s missing, decide what to do with it and then initiate that action. For Lilly, it’s a small part that’s missing, so they’re going to post it to her. A few days wait ensues and, on Saturday – that’s 2 weeks after the order was placed – she receives the part.
It’s broken, either in the post or during the picking process. Again she calls the after-sales and they go through the same conversation as the previous week; this time a bit more aggravated. The part arrives intact on Tuesday and 2 weeks and 3 days after the initial order, Lilly has her bed.
If we take into account a pro rata of the delivery effort, we end up with about 5 hours activity across 17×8 hours = 136 hours. That works out at 3.7%. If we look at the actual value-add activities rather than all activities, that’s probably a lot less (i.e. the original order time plus the delivery, but not arranging the bed delivery or arranging for delivery and redelivery of the missing part). Let’s say that’s 1.5 hours including ordering, picking and delivery that works out at 1.1%. That also assumes that we’re looking at working day hours, not full 24 hours as customers are becoming more accustomed to. Had we considered 24 hour days for 7 days a week, that 1.1% reduces drastically.
2b. Service Function
Michael is returning a bluetooth speaker to an online retailer. It’s Saturday evening but, like most, the website is 24×7. First he logs onto the retailer’s website, looks at his past orders, finds the order for the bluetooth speaker and submits a complaint. This is the start of the RMA process that’s commonly used for returning (technical) goods.
On Monday afternoon, Maria a member of the service function, replies to Michael’s email. Maria expresses regret about the fault and attaches a fault reporting form for Michael to fill out. Michael’s a bit annoyed about this; he’s already provided some of the information in his original email to the company. However, he does accede that they will want some additional information in the form.
He has to print the form but he can’t do that until he’s next using a computer that can open the pdf document and print it to a nearby printer. So on Wednesday evening, he prints the Fault Report form, writes the details and then scans it. He emails back the completed form that evening.
On Thursday morning, one of Maria’s colleagues, Zoe reads the form, agrees that the bluetooth speaker is faulty and then sends Michael the RMA note, authorising the return.
Michael has to print this out, so again has to be next to the printer. He does this on Saturday morning, boxes up the speaker and posts it on Saturday afternoon. The parcel arrives on Tuesday morning, opened by customer returns who agree with the fault, authorise an exchange to be sent to Michael and inform Michael of such. Michael reads the email on Tuesday afternoon, around the same time that the warehouse dispatch his replacement to him.
On Friday morning, the delivery company attempted to deliver the replacement speaker to Michael’s address, but as he was working, it was returned to the depot. “Fortunately” for Michael, the depot is open on Saturday morning, so he drives to the depot and collects his blue speaker. That’s not really fortunate since a better solution would have been to have checked with Michael when he would be available to receive the package. But it could be worse, the depot could work standard mon-fri office hours.
Almost 2 weeks have passed since Michael reported the initial fault, with more effort required of the customer than of the retail company (so far). Michael has probably spent 4 hours of his time in sending emails, reading emails, printing, completing forms, boxing, arranging for delivery and subsequent collection. The retail company spent 3 minutes in the initial fault report form, 3 minutes reading the fault report form, 5 minutes arranging for the RMA, then 5 minutes despatching a new one. Less than an hour. They’d also have disposal or return of the fault item plus accounting and other supporting activities. However, having spent less than an hour of “value” time in the returns process, the company managed a process that took two weeks. The ratio of value added activities to the length of time to complete the process is low, 1 hour to 24 hours x 14 days = 0.29%. That’s not uncommon.
2c. Local Authorities
This is where I first encountered the pattern. Instead of writing about it in this article, I’m going to save it for its own article as I’d like to explore it in more depth. The pattern is rife in local government and related services. I’ll post a link here when the article has been published.
3. The Calculation
There’s a term for this concept and formula for calculating it. It’s called CPE for Cycle Process Efficiency or occasionally PCE for Process Cycle Efficiency.
In this case, I’m calculating the time for the whole end-to-end service process. If our examples are consistent, then the service function is showing a Process Lead Time of 2 weeks per unit. That’s the elapsed time it takes from the point that the customer first contacts us to the point that we deliver the solution back to the customer.
We also require the Value Add Time, i.e. how much time per customer is spent creating or transforming value? This may actually be easier to arrive at the Value Add Time as equal to the Process Lead Time minus the Non-Value Add Time. It’s often easier to identify the steps that do not add value. Whichever route we take, we’re aiming to identify the Value Add Time for this process.
The PCE is then the Value Add Time divided by the Process Lead Time. It’s usually way lower than you initially think. If it’s above 70%, then you probably haven’t identified all the non-value add steps. To put that statement into perspective, I’ve seen PCEs lower than 1% for appallingly bad processes and improved them to 25% for a drastic improvement. Unfortunately, finding PCEs <1% is not that uncommon.
So what can we do about the pattern?
1) Recognise if the pattern is active in your organisation’s services.
2) Focus on the delay. You’ll almost always achieve more value and improvement from resolving the delays since they outweigh the spikes.
3) Consider different methods for removing each round of the spike-delay pattern.
For example, in the returns process, the fault reporting form could be on the website, ready for customers to complete. In addition, the organisation could implement automated authorisations when submissions meet certain criteria. This could include printing returns labels on the invoices packaged with the original goods. That would be 2 of the rounds reduced.
There’s no question about the fact that fixing the problems so that they do not happen again is the most important step and will have a greater impact on CPE than any factor. However some of the above issues with CPE don’t involve a failure (such as a defective part), but are due to the inefficiencies present in the process. These are often caused by a bureaucratic need to manage risk. The question then becomes one of addressing that risk through other methods.
Do you want to comment, get in touch at @alanward.
I’m going to use GDPR as an example of how prioritised goals can make a big difference in how an organisation responds to change. I’ve no wish to jump on the consultancy bandwagon that is GDPR; I’m definitely no expert on the subject. However, GDPR will serve as a good example in this content as it’s a topical subject that many organisations are addressing and so should be at the forefront of many strategic and tactical discussions.
A brief perspective on GDPR
I have a simple view of GDPR in that it’s requiring organisations to be better citizens, i.e. to behave better with the data that they obtain and manage. While there are a those complaining about the effects of GDPR, I would first want to question the motives of the companies they work for. I would be looking to see whether the motives are customer-centric or profit-centric. For most customer-centric organisations, most of GDPR is doing what they do already, but with some more rigour to their processes. Unfortunately GDPR is a bit of sledgehammer and a few other nuts will get cracked.
GDPR has stronger implications for what can be done with customer data, potentially rendering data useless collected in such a way. Actually, it goes further in terms of legality of handling and processing data, but we’ll stick to usefulness to the company for now. The important point is that for many companies, there will have to be some changes to how they collect data in that manner and potentially if they continue to collect it at all.
Business Motivation Model
So let’s apply business motivation model and see what GDPR looks like in this case.
The above diagram depicts two companies. One on the left and one of the right; there’s a gap between the top. It is a simplified business motivation model showing the difference between the two organisations, based on one single goal at the top.
For the left-hand company, the main goal is to Provide the best customer service possible. They are achieving this through a sub-goal (maybe a mission in many organisations) of Build relationships with customers. This goal is achieved by the outcome of Capture Customer Contact Details. I’m simplifying to allow outcomes as measurable effects that will happen.
The outcome is realised by a process group of Ask for details of customer which is part of the Pre-GDPR state or plateau. That process group fulfils the outcome for the situation before GDPR. We’re interested in what happens in reaction to GDPR.
In the same company, we can see GDPR as a external driver. The company conducts an assessment and we have a goal of Be GDPR compliant.
That goal influences Capture Customer Contact Details.
We have a work package designed to achieve that goal of Become GDPR Compliant.
For the Post-GDPR state, notice that there is a revised process group of Revised Customer Engagement. This process group focusses on building the relationship. It’s implemented by the Become GDPR Compliant work package. You can trace the line up to the goal of Provide the best customer service possible and the driver of GDPR
Meanwhile, on the right-hand side, we see a similar motivation model, but with some differences. The GDPR elements remain the same. What has changed is the overall goal of Increase Revenue which includes the sub-goal of Increase Revenue from Individual Customers. To achieve those two goals, we end up with a different process group for the post-GDPR state. The result is the same as the original process, but prefaced with an explanation of what we’ll use the data for, etc.
The Business Motivation Model was simplified in this case. I’d expect to see design principles/constraints, more detailed goals and objectives on the company-side and more detailed goals and objectives on the GDPR assessment side. All of those would constrain the future design.
For instance, the revised process groups I’ve displayed are not the only options that meet the listed goals. However with more goals and outcomes included, I’d expect there to be fewer options to choose between.
The examination of the GDPR scenario through a Business Motivation Model indicates at least two responses to a common data collection issue.
The end result is that it:
may speed up queues since companies realise they can’t just ask for contact data and they decide to not ask,
may speed up queues since companies realise that the interaction doesn’t allow for valuable data to be collected since they won’t have an agreement to use it and, again they decide not to ask, or
may elongate queues so that the companies can ask for permission
Back to the title, I see options (1) and (2) being the white knights for the customers of many companies. We’re hoping that companies follow common sense and implement changes that both respect the customer experience and adhere to GDPR. However in addressing the elephant in the room of how processes can be changed to suit GDPR (rather than improved for the customer), we may end up with (3) and a worse customer experience.
I simplistically take the view that Service Design is the concepts and methods of Design Thinking applied to making services work better for their customers. It’s a definition that works in the circles I most commonly move in, i.e. directors, programme directors, etc. It allows me to set the stage in which service design and design thinking both play.
However on the same stage, we commonly find KPIs, OKRs, Business Architecture, etc. And the stage starts to look crowded very quickly. We also start to see people pulling in different directions, like someone has let a mouse loose in the chorus of an Italian opera.
Operas and plays have directors, often many directors each responsible for their own domain, but with one artistic director responsible for the overall vision.
Now imagine what would the stage look like if the director asked the question “How might we…..?”.
It’s the opening line of many a design thinking ideation round. And it serves many purposes, explained better by others elsewhere.
Taking the stage analogy further, I hear questions such as “How might we produce more colourful costumes?”, “How might we light the back of the stage better?”, “How might we fill this part of the stage?”.
All of them are good questions and relate to the specific problem that has been uncovered during the discovery phase.
What they’re not doing is thinking of the entirety of the show. They just resolve the problem that was uncovered for their part of the show.
How might we approach this differently?
What they’re not doing is asking “How might we aim to deliver a better show?”
Let’s look at that question more thoroughly.
It’s got the typical format of “How might we…?” introducing the concepts of inclusion, a shared problem, and an indication of possibilities and potential.
I didn’t stop at the simpler question of “How might we deliver a better show?”. That’s where service design typically fits.
If we step back from the stage and consider an organisation, even applying service design in this way would be a stretch. At this scale, we’d be trying to apply service design to the whole organisation, e.g. how might we deliver better services? Where typically each service would have its own change activity, often in the form of design sprints, etc. Instead, the simpler question of “how might we deliver a better show?” could be translated into a top-down design question for an organisation of “how might we deliver better products and services?”, “how might we become a better organisation?” or similar organisation-wide design questions.
However, the question I introduced earlier focusses on the aim, not necessarily the end result. It asks about how might we aim to deliver. In focussing on the aim, it allows us to explore the goals and how goals are set. It leads us to question what goals would be required in order to deliver a better show. In understanding the goals, we have to understand what good looks like, what counts as successful and not just in the eyes of the board, but in the eyes of customers. If we set the concept of goals smart enough, this could easily set the scene for continual improvement.
Alignment with Business Architecture
Back to the organisation, now that we’re asking about the aims, and we’ve looked at the goals, we can start to see how the goals for the enterprise could be set. This brings Service Design up to the area where it aligns with Business Architecture. While this may seem at odds with a top-down approach of setting KPIs, we have to ask the question of why wouldn’t we want to develop an organisation that is driven by achieving its goals that deliver value to customers?
Alternative Business Motivation
By combining Business Architecture with Service Design, there is the possibility of redefining the concept of Business Model Modelling. Typically that’s a top-down approach, modelling external influencers, assessments, goals, objectives/outcomes, etc. Taking the combined service design/business architecture approach would result in metrics that matter to customers as the metrics percolate up through the organisation, not cascade down as is more common.
Whereas the concept of One Metric That Matters may suit startups as they redefine/focus on a different metric per stage of development and growth, it would not be expected to change as often in a more mature organisation. Instead, we may see a single metric that is of most interest for a cycle of improvement. But here’s the clincher – that metric would be an aggregate of the metrics defined by exploring the problem space with customers, not one that’s defined by an executive board.
However we may see a situation where an executive board decides to steer the organisation away from its current model towards a different business model. In that case, we would consider a more top-down approach.
The entrepreneur mentioned that he was in the finance sector. On questioning further, the offer was a financial app for any sector. There’s a big difference and we can explore that difference in a matrix between capabilities and sectors.
At first glance, that looks like a contender for the world’s least useful matrix. On second glance, I’d also probably agree with my first impression. Not only does every cell in the matrix have a tick in it (so there’s no differentiation), it doesn’t include a full list of Business Capabilities. Instead, there’s sufficient to explore the concept for our purposes.
Let’s take it a bit further and use it to explore an issue I see with companies, mostly those in a supply position. If you’re selling software into healthcare, then are you a tech company or a healthcare company? It helps to phrase the position in terms of the capability you provide or improve in your target sector. So in that case, you’d be providing technology into healthcare. As we can see from the possibly-useless matrix above, we’d expect all sectors to require all business capabilities.
But I find more companies are confused if they’re providing software into finance. Suddenly they’re in the financial sector. True, the selling into the financial sector, by providing services into it, but they’re still a tech company.
This becomes more obvious when the software company that originally sold to Finance sector then also repackages the product to sell into Healthcare.
This is a simplistic view of the concepts of horizontal-integration or vertical-distribution; you can provide:
more services into your industry vertical, e.g. provide tech and financial management into healthcare or
the same capability into many sectors, e.g. provide financial management into healthcare and education or expand in both directions with
a mix of capabilities across sectors
However, it’s more complicated than that. Each of the capabilities listed in the only-slightly-useful Sector Capability Matrix features at Level 1 or Level 2 (depending on where you start counting from the top). From a standard business architecture practice, each of the capabilities can be decomposed further, for instance, within sales management, we’d expect to see sales analytics, sales commissions, sales execution (the actual doing the selling), sales performance management, etc. Different organisations have a different angle on how they decompose the lower level capabilities. The main concept to take away is that we can take a conceptual capability and split it into more granular capabilities.
Instead, we are going to decompose them in a different manner. Most of the capabilities can be viewed as mini-businesses in their own right, so we’d expect to see a microcosm of capabilities within them.
Whereas the traditional business architecture view is based on functional decomposition (in that the capabilities are decomposing into more specialist capabilities), we’re going to decompose into enabling components.
For each of those capabilities that support an organisation, there are several components that are required to turn those capabilities into reality. In the same way that the organisation requires capabilities to function, the capabilities themselves require the components to be able to deliver. These components are capabilities at the next level down, to some extent mirroring the capabilities of the organisation as whole. For instance, most capabilities require people who can do the job, people who can manage, technology, etc. Hence the concept of capabilities as mini-businesses in their own right and that’s what we see in Figure 2 above. Each capability is supported by components. Note that Figure 2 does not include all capabilities or components, just enough to give an indication of what we’re discussing here.
This becomes significant when we consider the role of the components in a B2B context. This article started with a founder’s confusion over the sector, we then took a route through exploring capabilities. Now I want us to focus on the components.
It’s that middle column, with the red border, that we should consider when creating a new business. For B2B, we provide Capability Components to a client business.
If your client is a car dealership, they’re in the automotive sector.
The car dealership will have many Capabilities, e.g. Sales Management, HR Management, Organisational Development, etc.
If you are a company selling sales training, then your selling into two capabilities. You’re improving their Sales Management capability, but providing services into their Organisational Development capability. And that’s why it’s confusing. We have to remember, not only the sector that the client is in, but the interplay of the Capability Components we offer with the client’s Capabilities.
A further angle is that if you have sufficient capability components, you can provide the whole Capability to your client business, e.g. fully outsourced HR services.
We need to be careful about how we define our sector. Depending on the context, your audience will interpret the sector differently. A lot of that will also depend on what you meaning you intend to convey when you say your company is in a given sector.
The key item to remember is that the client operates in a Sector and that we offer Capability Components that interact (e.g. support, improve, provide) with the client’s Capabilities.
In the fifth article, I introduced the whole diagram so far and the achieving different perspectives on that model
In this article, I’m going to introduce a related model that includes how to model the effects on capabilities and organisation units.
What we’ll cover:
Current and future states regarding one of the changes
What we won’t cover
The original model
All of the changes implied in the original model
Do not consider this article to contain the definitive method for documenting the combination of MSP, Business Motivation with Archimate.
It’s a work-in-progress and is developing in line as I understand more of the complexity of interaction between the different models, standards and tools.
Start with the Current Model
I’ve taken the design principle of Deliver local where possible from the main model as the root of this view. It’s off the page in this crop but we will see it later when we discuss the future model as well. The basic concept here is that the current model has 3 offices; one provides marketing, one provides sales and one provides product support. Each office houses staff aligned to those capabilities. The plateau is used to describe the current state (and relates back to the main model which has been updated with plateaus).
So working up from the plateau of the Current State at the bottom, we see that it comprises the business org units of Marketing Associate, Sales Associate and Product Support Associate. I’m using the Plateau to capture all the artifacts related to the state of the organisation at that time. Later we’ll see a second Plateau for the future of the organisation. For this particular plateau:
The Marketing Associate fulfils the role of Marketing in the NorthWest office. The Marketing role realises the Marketing capability.
The Sales Associate fulfils the role of Sales in the East office. The Sales role realises the Sales capability.
The Product Support Associate fulfils the role of Product Support in the South office. The Product Support role realises the Product Support capability.
This is necessarily simplified compared to the majority of companies in existence. It’s rare to see such simplicity in coterminosity but suffices for our purposes.
The Future Model
This is the top half of the diagram. What I’ve shown here starts at the top right, with the design principle. A fuller description of the principle is that we’ll provide the service as close to the customer as reasonable. It could be combined with another principle that allows for tailoring of products according to the demographic needs within specific geographies.
I’ve then used a Plateau for the the Future State, which realises the design principle of Deliver Local Where Possible.
In the current organisation, with three offices in the area, a customer is only served if they require the services of the office that is currently near to them. So Sales from one office and Product Support from another. If customer is in the North and they require Product Support, then they’d have to travel (assuming face-to-face is required) to the South office.
I would envisage an assessment detailing options. For instance, we could achieve the same design principle through acquiring other premises, through partnering with other organisations to achieve a more local spread, through rationalisation of current premises or through a combination of these options. I’ve chosen to progress with the option of rationalisation here, highlighting what the organisation could look like if it were to have all 3 capabilities available in every office.
One way of achieving this would be to distribute the people in each office and share them across the 3 offices so each office had one even share of 1/3 marketing, 1/3 sales and 1/3 product support. Or we can implement a cross-skilled role where every person can cover marketing, sales and product support. I’ve gone with the cross-skilled role option. I’m not saying here that organisations should do this, I’m using it as an exercise to model current and future states.
The Design Principle of Deliver Local Where Possible is realised by Cross-Skilled Roles Course of Action which in turn is realised by a new organisational unit of Product Line Associate. That’s the key to making this change. The Product Line Associate realises the Combined Team Capability and we find ourselves having to make some documentation descisions at this point. Part of the issue is that we’re crossing themes, discussing elements from Motivation, Business and Strategy in the same model.
So I’ve included the word Capability in the title of Combined Team Capability, only so that we can quickly identify and differentiate it in this article. I wouldn’t normally include the artifact name in the title; it’s clumsy.
Combined Team Capability is realised by the org units of NW Team, East Team and South Team. At the top-left, we see that Combined Team Capability is composed of the Combined Team Capabilities of Marketing, Sales Management and Product Support.
The same offices as in the current model have been used. Rather the association relationships crossing current and future, I’ve chosen to include a copy of the office artifacts in the future part of the model. There are benefits and disadvantages to both ways of modelling. Using an artifact only once, such as an office, allows you to see the nexus of change and more importantly, in this case, what’s not changing. Copying the artifact allows for a neater diagram but requires more interpretation.
The other main difference between current and future is that:
in the current state, the Offices serve the Business Role
in the future state, the Offices serve the Business Actor (or the organisational unit)
Neither is wrong, but consistency would be preferred. In the current state, there is significantly more clarity regarding which roles and actors are using which offices, due to a single capability per office. In the future state, with the mixed capabilities per office, there would be numerous business roles.
The complete view of Capability Change
I’m going to discuss the partner model to this model. It highlights the organisational units, capabilities etc.
I’m going to add in the relationships between the corporate goals and the programme goals. The aim is to see a clear line from top to bottom when using the Motivation viewpoint. That’s a starting position.
I’m going to replace the future organisation units in this model with a plateau
Update with consistent view of Business Roles and Offices
At the moment, it would be wise to view the diagrams and model included in these articles as a draft. They are open to discussion and subject to change.
Expectations can run deeper than you may at first think, especially if those expectations are based on decades of cultural information/misinformation. This may affect attitudes towards quality or acceptance of new ideas, including industry innovations. If we’re aiming to make changes in an organisation, we should look out for the deep-rooted expectations of what’s acceptable.
It’s about the form
High-heels have been a feature of women’s attire for centuries, especially since the latter half of the last century. They’ve become a focus for discussing what’s acceptable in our society, to the extent of legislation in some countries banning companies from requiring its female workforce to wear heels. But also, from a moral perspective about whether wearing them can ever be required. Setting the moral and legal arguments aside, let’s take a quick look at what’s behind them.
Morris conducted an experiment analysing the attractiveness of female gait with the observers having no idea that the women were or were not wearing heels or even that the people they were observing were men or women. The observed were all women, and they all wore flats and heels. The observers had no idea that they’d see the same person’s gait twice; once with heels, once with flats. The result was that the “video clips of the walks in high heels were judged to be significantly more attractive than those in flats”. So there is an characteristic that we find more attractive and that characteristic reveals itself in our perception of gait which high heels enable.
A follow-up experiment reached a further conclusion, summarised as “by exaggerating the normal female gait, high heels serve to falsely enhance our perception of the wearer’s femininity”
So we end up with a cultural expectation of femininity based on the shoe type. Wear flats and you appear less feminine. Wear heels and you accentuate your femininity. And this is whether or not the heels are the most attractive (not just the effect that they have on the wearer) or which footwear would be the functionally most appropriate attire.
Consider a woman walking towards you. If she’s wearing flats, she’d be considered less attractive than if she were wearing heels. But it’s the same woman with the same attributes, same personality, even the same body, but her form and gait is altered by the use of the heels. It’s an expectation and it’s deeply rooted. I’m not saying that it’s the right thing or that women should wear heels, just noting the cultural expectation.
It’s about the tone
Guitarist have for decades sought the tone of the electric guitar pioneers. Think Beatles-era guitar sounds. Those are the tones that act as a reference for all modern guitar tones. Later, Jimi Hendrix took that tone and added colour to it through distorting amplifiers and effects units. Tony Iommi of Black Sabbath took Hendrix’s tone and detuned it. And so on. You can trace the line back to 1950’s popular tones.
Let’s say I innovate and introduce an exceptional guitar amplifier based on amazing audio technology that can clearly reproduce the guitar tone as it’s produced from the guitar. It would fall flat and no-one would buy it. Guitarists are not interested in the best (if we define best as “accurate” to the sound made by the guitar). The reference from the 1950s was made using inefficient amplifiers, inefficient cables, substandard guitars, low technology in strings and speakers that were appalling by today’s hifi standards. Even the speaker in your tv has a better response that those 1950s speakers. But that’s the tone we recognise as good. It’s so deeply ingrained in our models of what counts as good, that more accurate to the guitar doesn’t mean better. In fact the opposite.
There’s an additional complication in that the tone we hear for the guitar isn’t even that 1950s tone from the guitar amps. That produced tone is manipulated at the mixing desk, with appropriate equalisation to filter out the parts of the tone that we don’t need and especially to filter out the parts of the tone that would conflict with other instruments. So if you listen to the isolated tone that’s been recorded, it’s reedy and thin compared to what you’d expect. But add that isolated track into the rest of the song and your brain fills in the gaps.
So when we hear a guitar in a song, we expect it to have a compromised frequency range compared to what the guitar and amplifier can actually produce. If we heard what it could do, then it would sound odd, very odd indeed.
Similar to the high heels, we’ve built up a cultural expectation over decades of what constitutes good. It doesn’t mean it is good and, similar to heels, in many ways it is worse than what can be achieved. But it’s difficult to argue with deep-rooted expectations and, while we know it is possible to change minds, changing something this ingrained will take a lot of effort, time and patience.
As transformation agents (whether directors, analysts, managers, etc), we often miss the cultural expectations. We could use the Empathy Map Canvas, Lewin’s Force-field Analysis, Prosci’s ADKAR or whatever model your organisation chooses to use. But we should be careful as we use each of them, because sometimes the expectations are that ingrained, it’s difficult to bring them to surface. If you were to ask members of the public to attend a focus group on guitar tone and then worked through what’s prompting the change or resisting it, would the concept of the tone from the 1950s actually feature as an arrow that resists change? I doubt it. It’s invisible to them.
Instead, these hidden expectations create a risk to the change programme in potentially blocking the changes for what initially appear to be non-sensical reasons. That is, until you uncover the expectations which run deeper than you first thought.
Now consider the above examples of high-heels and guitar tone. Imagine trying to motivate just the people in your organisation to accept the better alternative (i.e. flats for function regardless of event or a hifi guitar sound). How difficult do you think that would be? And how does that compare to recent significant changes you’ve had to introduce?
As a profession, Business Architects are in danger of becoming defined by just one of the products that they create. Unfortunately, it reduces the value that the profession can provide to organisations and limits expectations of prospects and clients.
What went wrong?
Imagine a fine-dining chef who makes tacos once at the request of a favourite customer. The chef knows tacos will do the job, she knows they’re sustenance, she knows that there are better products and even advises the customer of what she can do instead. But the customer wants tacos, so she delivers.
Other people like tacos as well. So she becomes known as a taco chef and the world is left short one fine-dining chef. Or rather, she’s no longer unavailable to provide the fine-dining experience since she’s now cooking tacos at the request of many customers. She knows she can do more and tries to prompt customers through educating them of other ideas and concepts. But the tacos are pleasing the short-termism of the current customers. It keeps them fed for an hour until they start to feel hungry again. She’s diligent and adds as much nutrition in them as she can. She listens to each customer, understands their needs and can plan a superb meal that will keep them well-nourished for hours. But the customers want tacos and end up hungry again in a hour or so.
The tacos could be cooked by someone on a lower salary. But they may not have her knowledge of nutrition and attention to detail. So yes, they’d still be tacos but not tacos of the quality that she’s been producing.
That’s our taco
And that taco situation is what I see with Business Architects. We’re commonly requested to perform a documentation task, e.g. “document the current business”. It’s usually followed by “so that we can …..”. Look on any job boards for contract Business Architects and you’ll see the activities we’re requested to perform. It’s usually the pattern described above of “document the current business”. Roles for permanent Business Architects are usually wider since clients don’t want professional expertise for just 6 months; they’re thinking longer-term.
The contract clients request knowledge or even certification of TOGAF or Zachman, but you don’t need knowledge of those to be able to document the business.
They may want specific knowledge of their industry sector (e.g. SOX and MiFID II for finance) and they may want experience with specific tools. But if the role requires a Business Architect, then documentation will be the activity.
They may even want knowledge about Business Architecture offerings specific to their industry sector (e.g. MODAF or ETOM). That last element can assist with documentation, especially if there are reusable models in the sector-specific offering.
But in the end, the client is asking for someone to document their current business. There’s often little thought for what to do with the documentation once it’s been produced. Some clients think ahead to wanting a future model, but don’t give much thought as to what to do with the gaps between current and future or how to evaluate benefits of different future models.
That’s our taco. Documenting the current business is the Taco of Business Architecture.
How did we get here?
Let’s take a look at some of the definitions for Business Architecture and then do the same for Enterprise Architecture. We would expect them to be similar, with Business Architecture being more focussed on the business domain.
Business Architecture Definitions
wikipedia: “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”
OMG: “defines the structure of the enterprise in terms of its governance structure, business processes, and business information.”
The BA Institute – “defines the enterprise value streams and their relationships to all external entities, other enterprise value streams, and the events that trigger instantiation.”
The common theme in these is that Business Architecture is referred to by the deliverable or product that it creates. It’s output is the definition of the enterprise business.
Whereas I’d see Business Architecture as an activity. I’d expect to see more relating to its purpose, what it does and why it does it.
Interestingly, TOGAF (also by OMG) describes the context of the first few steps of the ADM with:
“a knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).”
TOGAF, in the paragraph above, implies Business Architecture as an activity.
Enterprise Architecture Definitions
Let’s look at definitions for Enterprise Architecture and see if they exhibit the same characteristics.
Wikipedia defines EA as “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy”
MIT CISR defines EA as “the organizing logic for business process and IT capabilities reflecting the integration and standardization requirements of the firm’s operating model.” Jeanne W. Ross, Peter Weill, David C. Robertson
Gartner defines EA”is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes”
Enterprise Architect Body of Knowledges defines EA as “analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology”
Here we see words such as discipline, practice, logic, guide. There’s a mix of nouns and verbs in that list, but they all indicate activity, for instance, you’d only have a discipline if you were to produce something.
We seem to have lost that concept with the Business Architecture definitions, although the TOGAF ADM excerpt does imply that Business Architect involves activity.
The Tao of Business Architecture
I’m going to approach this from a different direction and simplify the concept.
1. Business Architecture assists strategy
Business Architecture only exists because of strategy. Without strategy, Business Architecture has no purpose, no reason for being. We would just be producing documents for the sake of producing documents. Either those documents have to be useful or the process of creating the documents has to be useful, otherwise Business Architecture is a waste in any organisation.
Business Architecture relates to how that strategy is developed and maintained, how that strategy is implemented, how different strategies are evaluated and indeed, even the documentation of current strategy.
A description of the current landscape and challenges
A description of the future target that can respond to those challenges
A plan to get you to that future
For Business Architecture (and also Enterprise Architecture), those concepts make a lot of sense and can be interpreted as:
A description of the current architecture. In this case business architecture, specifically the BMM, organisation units, influencers, partners, governance, etc
A description of the future target. In this case, the goals, outcomes, changes to capabilities, future organisation units
A plan to get you to that future. In this case, the change programme and work packages (most likely later supported by programme and project plans).
Here is the crux. Business Architecture is not only those documents, but it is the activity involved in producing those documents. There is more value in a Business Architect assisting an organisation in defining their strategy, challenging, providing other options, providing analyses, etc than there is in the delivered documents. It is the analysis and the progression of the conversation and the development of knowledge within the enterprise that is of most value. For some clients, the future state doesn’t need to be written down at the end of the assignment because the organisation has developed to the point that all know the common direction. The direction has become subsumed into organisational knowledge and culture. That’s not common, but the fact that it can happen, indicates that we’ve assigned value to the wrong part of the contract.
2. Business Architecture assists the enterprise
When I read the EA definition earlier from the Enterprise Architecture Body of Knowledge, I found that it described Business Architecture with one element missing:
“analyzes areas of common activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and the use of technology”
The simple addition of “the use of” alters the definition to be suitable for Business Architecture. I also like the focus on “future states” rather than current.
3. Business Architecture assists goals
This is fundamental for me. When I’m explaining to people what I do, I avoid phrases such as “I architect businesses” in the same way that a programme manager may say that “I manage programmes”. Instead I simplify for the layperson and say that:
“I help organisations do what they want to achieve”
and often the first step of that is
“assisting the organisation’s executive define what it wants to achieve.”
From my perspective, the majority of large issues within organisations stem from a lack of alignment. I find that larger organisations evolve to a state of disparate, loosely connected governance models that are not aligned with a central set of themes (or goals in this case). I work to align an enterprise so that it can focus resources on what it want to achieve, briefly (or as briefly as is reasonable) documenting where it is now, developing the future vision and then assisting the executive in steering the company towards that vision.
In short, it boils down to: “What direction do you want to go in? Then let’s define what we need to do to get you there.”
Business Architects need to retake the definition of the profession, in order to move clients and prospects from the Taco of Business Architecture to the Tao of Business Architecture.
This should be done with a focus on Strategy, Enterprise and Alignment and a lesser focus on documentation for the sake of documentation.
The model I’ve been using in the previous articles has grown to become relative complex (complex for a online article, not for a typical business architecture model) while trying to describe a common situation in most organisations. I’m going to show it all in one diagram in this article and show different perspectives on the diagram.
In the first article, I introduced the standards and the tools that are in scope of this series of articles. To recap, the chosen tools/standards/methods are:
Archimate – The open source enterprise architecture modelling standard
In this article, I’ll show the whole diagram so far and the achieving different perspectives on that model
What we’ll cover:
The model covering all elements that have been discussed so far
The use of viewpoints
What we won’t cover
The current to future organisation model
Do not consider this article to contain the definitive method for documenting the combination of MSP, Business Motivation with Archimate.
I’m more confident about the parts of the model described in articles 1, 2 and 3, than I am in this. Mainly the right-hand side of the model doesn’t feel fully integrated. That’s instinct at the moment, but I’ll look to evaluate further.
The Whole Model
The model starts with the external drivers, influencing corporate ambition. There’s an example of an assessment. Archimate implies that a influencer does nothing to an organisation without an assessment. I’m not keen on that thought. Events will happen to your organisation whether or not you assess them. I can see where they’re coming from, i.e. the internal organisation will not respond to the external influence without an assessment, but it feels odd at the moment.
We then descend the left-hand side of the model through the goals being set, then into corporate governance (probably including portfolios in larger organisations), the MSP Mandate and Brief.
Further down we see the goals related to the MSP Vision, the MSP Outcomes and the Requirements.
On the right-hand side, there’s the assessment mentioned earlier. Below that there’s a gap while we’re in corporate governance on the left-hand side. Then we see the MSP Blueprint. And it starts to become more convoluted at that stage, especially if we include the descriptions of the future state, as you may expect in a Blueprint.
In the previous article regarding blueprints and missions, I highlighted that many programmes cannot have a Blueprint with a future state defined at the start. These are the programmes that are created with the specific purpose of designing the future. Having been involved with many of these, it that’s type of programme that I chose to portray, plus it takes us out of the comfort zone of works-in-theory to a zone of how-does-this-work-in-reality?
The final part is a collection of the 3 work packages. There would usually be more, but their inclusion is more to show how they’d relate to the rest of the model.
I set out to see how Business Motivation Model and MSP could be modelled using Archimate. It’s common to see the use enterprise architecture tools focus on the current state or a future state, but without easily assisting with the navigation from one state to the other, especially regarding what needs to be involved in change programmes.
There is another part of the model, on a different diagram, that I’m going to discuss in a following article. It concerns that change, from documenting the current state to showing the delivery of the business capabilities in the future state.
In hindsight, I’d like to include the plateau artifact in the main model. That would be a better solution and would replace the To-Be organisation units currently included.
Part of what I wanted to achieve was to be able to see track the response to an influence all the way from the work package and it’s change on organisational units, policies, etc up through the programme governance to the executive. And also track the reverse.
Looking at the model, we can see that you can navigate from the top to the bottom. Nothing is isolated or standing on its own. However, not all of the relationships are that useful or required to be able to connect the top to the bottom.
For instance, look at the Corporate Archimate diagram above. You’ll notice the dotted lines with arrowheads, e.g. between Changes in Legislation and Assess Impact of Legislation. That’s because that relationship is “influences”. It hasn’t defaulted to the standard of “associates with”. Archimate allows a default “associated with” for any artifacts, but it’s not always that useful and implies that you’re deviating from the purposes of the model. The straight line relationship between Forthcoming Demographic Change and Increase Market share is a good example of that “associated with” relationship. Fine if you know what you’re doing.
In our case, I’d already mentioned I’d take a bit of short-cut and only included one assessment. The point here, is that to use Archimate properly, we have to go from Influencer through Assessment to Goal. Even if an assessment is just the CEO or MD thinking it through for a few minutes, it’s still an Assessment.
Looking further down the model, we see that the goal defined in the corporate vision do not relate directly to those defined in the programme vision. They should. In fact, that’s the alignment that I’m most interested in. Instead, during the development of this model, I connected them through the MSP Mandate and Brief. Since Archi is a repository-based system, it’d be easy enough to connect them. Unfortunately for us in the model, the mandate and the brief are only connected with a the default “associated with” relationship.
So my next step is to ensure that all relationships are worth documenting by trying to avoid the default “associated with” relationship where possible.
To assist with that, I’ve been looking at different perspectives within the same diagram. Archi implements these as Viewpoints. So far, we’ve been using the default “All” viewpoint.
The first viewpoint we’re going to look at is Motivation. Using this viewpoint, we’d expect to see only the artifacts and relationships that relate to motivation, and we’d hope that this viewpoint aligns with Business Motivation Model.
As we can see, all Deliverables are now greyed out (those relating the Mandate, Brief, Mission and Blueprint). Also greyed-out are the organisational units, business capabilities, capability changes and the work packages. From a BMM perspective, all that makes sense. It also highlights the need to connect the corporate goals with the programme goals directly, separate to the programme mandate and brief.
Goal Realization Viewpoint
I also used the Goal Realization viewpoint which overlaps with the Motivation viewpoint. In addition, it greys-out stakeholders and influencers. My intention here isn’t to find the perfect viewpoint. It can’t exist since it depends on the purpose and the audience. I was intending to see what the tool can do to assist in achieving a more logical model, consistent with the underlying Archimate language.
That quest for the logical consistency and use of the model/tool segues nicely to the validation tool. I had wanted this to point towards missing relationships or where the default relationship is used. I wanted pointers to making it a better model and I’d accept better being defined in terms of adherence to the Archimate language. More ideal, would be the ability to receive pointers to a better model based on a selectable standard, e.g. Business Motivation Model, Enterprise Business Motivation Model, etc. I had in mind the way that code editors, e.g. Sublime, can provide syntax checking based on various languages.
However, the validation in Archi is simpler than that.
There is the useful highlight of duplicate artifacts and unused artifacts. Then there is the list of artifacts that do not belong in that particular viewpoint. That’s useful if you only ever want to depict a model that conforms to a single viewpoint. It’s not as useful when you’re attempting to depict a model that crosses viewpoints, such as the mix of MSP, BMM and Archimate we’ve seen in this model.
I’m going to add in the relationships between the corporate goals and the programme goals. The aim is to see a clear line from top to bottom when using the Motivation viewpoint. That’s a starting position.
I’m going to replace the future organisation units in this model with a plateau
At the moment, it would be wise to view the diagrams and model included in these articles as a draft. They are open to discussion and subject to change.
Can we apply the KonMari to Organisational Design?
The KonMari method describes how to tidy your house and how to keep it tidy. It is a set of rules that you can absorb in order to keep a less cluttered house. Having read through the concepts and the rules, I noticed some similarities to the domain of Organisational Design. So let’s work through some of the main rules.
1. Tidy all at once
The premise of this is the concept that tidying an untidy house a bit at a time doesn’t work. Now before I hear you say Continuous Improvement, we have to remember that at first with KonMari, the house is already untidy. And so it is with our organisation. We’re performing Organisational Design because the organisation is an unfit state; it’s untidy.
So let’s allocate enough time, effort and people to redesign the organisation to get it into a fit shape. We need to accept the fact that it will take time and can’t be done piecemeal.
2. Visualize your destination.
This is the vision that sets the direction for your organisational design. Think of the vision that fits with MSP (Managing Successful Programmes) or the visions provided by your CEO or MD.
Define what you want your organisation to look like in the future, what it does, how it does it. That’s the direction you want to travel in and then that can act as constraints and drivers later on.
Create the design principles in order to identify what criteria you’re going to use to make decision about the future.
3. Identify why you want to live the way you envision
I think this is potentially the wrong way around. In my eyes, the ‘why’ should come before the ‘what’ of the vision in Step 2.
Using KonMari, you’d go through the exercise asking yourself why you need the items that are in your vision. This is a questioning of self, to understand how important an item is for you.
For us, this is the questioning we should ask about the vision. It’s time to reflect on the vision and evaluate it from a different perspective. As opposed to the vision that you’ve developed over time, question “if we achieve this vision, will it be good enough?”, “will it do what we set out to do?”, “are we aiming far enough?”
It’s also the questioning we should be asking ourselves when looking at the design principles. Are they fit for purpose? Are they good enough?
4. Determine if each item “sparks joy”
When you consider the items to keep or reject, KonMari suggests an emotional angle over whether it sparks joy. This enables you to reduce the items beyond just whether it’s functional or not, or whether you may use it in the future.
So we should look at each business capability in your organisation. Does its current implementation, e.g. which team makes it happen, work for you? Does it feel right? This isn’t about the logical response, but the emotional one.
5. Tidy by category, not location.
Remember this. It’s probably the most important one.
The KonMari suggestion is to bring all items of a certain category (e.g. sweaters) into a single place and work through them one-by-one. Rather than sorting through a chest of drawers, drawer-by-drawer.
Consider all the teams that deliver each Business Capability. Is that the way that you want to deliver that capability in future? How does it fit in with your vision? Is there a different way for you to provide that Business Capability, e.g. merging teams, outsourcing, joint venture, etc?
6. Tidy in the right order.
The KonMari method describes this order:
But also to create subcategories within the categories.
It’s a more complex situation for organisational design. We could find equivalent capabilities for clothes, books, etc, but the reality is that each organisation is different. They may have similar capabilities, but it’s likely that any two organisations will have different implementations of each capability or have capabilities at different stages of maturity.
So we need to create a plan that makes sense for each organisation. Start with the fundamentals of what needs changing first in order to create space (or capacity) elsewhere. For instance, if an intake team within value chain can’t change it’s filtering for whether customers, prospects, etc are passed further down the chain. Then it probably makes sense to focus on the receiving teams first, to then free up people assist with the intake team. It’s similar to clearing out a large enough area to act as swing space, so you can then make bigger changes more efficiently with the space you’ve just cleared.
7. Discard before you place things back
Set honest expectations early. If jobs will be at risk, complete the consultation and follow-up actions before you move people into the new team structure. There is always pain, but better to start a new organisation design with team members who are committed rather than retaining those who know that they are leaving.
I hadn’t intended this as a serious article, but I the more I wrote, the more I realised that there may be some useful perspectives to gain from the exercise.
Can we perform organisational design using just the KonMari method? From what I’ve found of the method so far, no we can’t.
Can we benefit from considering the KonMari method when performing organisational design? Yes, most likely we can.