Let's Not Build a Bank: Case Managed and Core Standardised Capabilities

Sofie Blakstad and Robert Allen

This article is part of our randomised, post-structural Let's Not* Build a Bank series of articles.

Instead of trying to standardise end to end processes, with limited opportunities for simplification and a negative impact on customer experience, keeping key differentiator services flexible allows more standardisation in supporting services, while delivering a fully flexible customer experience

The Service Aligned model relies on two key models of capability: Case Managed – flexible at the customer facing edge, and Core Standardised – pre-loaded elements that are instantly available to the customer facing teams on demand. This article describes how to build the two types of capability.

While the two models are superficially completely different, they do share some important characteristics, and in the real world you will rarely see a single function which is a pure example of only one of the models; on top of most Core Standardised capability you would expect to see a thin Case Managed layer, facing off to internal customers, and within Case Managed teams there will almost always be some Core Standardised elements. Because both models rely on governance structure, roles, accountabilities and decision rights, it’s actually very easy to mix and match them like this, however it does mean that getting the governance right in the first place is critical

Service alignment is more than just how you structure your teams; your organisational architecture and in particular, your Capability model, needs to distinguish those services. your Capability structure may look something like this in the Service Aligned universal bank:

Figure BFB-BF-CMCS-1: Case Managed vs Core Standardised Capability Model

But before you get to that level of detail, the basic model for any organisation remains the same: Customer interacts with Case Managed capabilities, which in turn draw down on Core Standardised. While your customer may also have some direct interaction with some Core Standardised capabilities (Payments springs to mind), even these will have a customised element at the customer facing edge, so the basic model still holds.

Figure BFB-BF-CMCS-2: the Service Aligned organisation

Each of these boxes represents a Capability – i.e. a Purpose of your organisation, such as “Customer Management” or “Buildings & Equipment Management”. Each of these will represent a number of disciplines and roles, potentially spanning large ranges of what would have been different parts of the organisation in the traditional, pyramid organisation. Instead of being managed by a hierarchical triangle structure, capabilities are managed by formal communication networks and governance, agreed by key roles within the relevant parts of the structure and regularly reviewed for relevance. Within the capabilities, formal roles, domains, accountabilities and decision rights are agreed within the same governance structure, so that everyone is clear about roles – their own, and just as importantly, each others’. The importance of this governance in contrast to traditional hierarchies becomes clear when considering this at an organisational level:

• No supporting function is more than one “team” away from its end customer
• Teams are not arranged to fit into a specialism oriented hierarchy, but aligned to delivering customer outcomes
• Management hierarchies are replaced by governance structures, decoupling seniority from numbers of people managed
• Each capability has clearly defined and agreed supply links with its donor capabilities – and with its customers, internal or external
• Each capability has clear visibility of the customer facing metrics and how they can influence their fulfilment
• Each capability has the ability to prioritise and manage its workload internally, with formal governance triggers for escalation and rebalancing when problems arise
• Decision rights, including the ability to dynamically adjust and prioritise workload to support customers, are embedded into the capability

These important principles maintain the agility of the modular organisation, as well as embedding empowerment and customer aligned behaviours into the teams. But as we said above, this is where the similarities end. We’ll first examine each model, and then describe how they interact in practice.

Case Managed, multi-skilled teams at the customer facing edge

Case Management, as the name implies, arose originally from healthcare, where they’ve been doing it for centuries, and has subsequently been adopted by a huge range of retail and service organisations, either consciously by design, or by evolution. You may already have teams using case management in your organisation, unless you’ve learned everything – it’s equivalent to the old fashioned model of the bank manager making decisions about his customers on the fly. Let’s have a look at the typical case management system from a medical perspective.

Each customer of the system is presented as a unique case. You walk into the doctor’s surgery with a pain, or a fever, and the doctor, after some critical first steps (are you still breathing?) and authentication (are you who you said you are?) uses her knowledge and experience, through a series of questions, to determine the nature of your malady and the appropriate treatment. She will then recommend a course of treatment or further investigations, depending on whether the problem can be quickly identified. Your treatment and further investigations will all be standardised, centrally provided – by the pharmacy, the hospital, etc – and rigorously governed, but how they are delivered to you will be configured by your medical practitioner, based on her knowledge of you and your case. Costs are controlled and standards are maintained by the rigorous standardisation of operating theatre equipment, pharmaceutical production standards, etc, but she is (within standard control limits) completely free to prescribe and agree with you how your ailment should be treated. She will also have access to other specialists in the practice – nurses, administrators, etc – who can support the configuration of your experience at the point of delivery, without having to pass it on to another team in another building. In larger practices you will also be able to undergo minor surgery on site and there may be a dispensary.

As we said, other industries have learned from this model – you experience it each time you enter an Apple store. They don’t make you wait in line; they work with you as individuals to configure your experience based on your needs and stated wants. Apple consistently generates some of the highest customer loyalty of any brand, despite producing a smaller range of products than any equivalent manufacturer and using cheaper components in its products. Because it’s not the multiplicity of products or even the quality of the components that creates the customer experience. The products are designed with the consumer at the heart, but it’s not just that. The Apple experience also extends beyond the store, to when you unpack the product in your home, and this is all part of the configured customer experience. Apple still do all the things in their stores that every other shop does – take your money before handing over goods, validate your credit card – but what happens around these checks is designed with your experience in mind.

So Case Management isn’t a lack of control – as we’ve said above, the governance actually has to be more rigorous than in the functionally aligned model – but it embeds the controls into the customer experience in a way that’s seamless and appropriate for that customer. Let’s come closer to home with an account opening example.

A customer walks into a branch – or a virtual branch, if you prefer, wanting to open a new account. Close your eyes and think of that customer.

Ready?

Who is your customer? Is it you? Or someone else? Is he/she/it an individual or an organisation? A boomer opening an account in a new name following a divorce, or a 13-year-old kid opening his first account? A sole trader or a big corporate? Maybe you had more than one in mind. Maybe it’s a sole trader who’s also just got divorced, has a share portfolio and wants to move some funds from abroad?

For each of those cases, you’re going to need to do the obvious: KYC, credit checks, account opening procedures, validation of origin of funds, etc. But you wouldn’t instinctively treat each of these customers the same. The order in which you do the checks might vary, and how robust they are; your risk appetite and potential cross-selling opportunities will vary. Nowadays we have different account types for each of these customers, and we have as many different procedures, carefully designed around customer segment and profiling, predicted behaviours, etc. But they all want the same thing. And no customer really fits into a predetermined box. However many types of account you have, they’ll never really flex to all your different customer needs. Furthermore, many standard processes are imposed in a linear fashion, which means you’re asking questions in an illogical sequence, or simply not adjusting based on the answers you get.

For fun, let’s do our sole trader who’s also just got divorced, has a share portfolio and wants to move some funds from abroad. They go through the application process with someone in the branch (let’s call her Julie), who takes their details and passes them through to your processing centre. In the processing centre, Jim puts the details into the system (Jim can’t read some of the entries, so he puts some queries in the queue for Julie to pick up later, but he does what he can) and initiates the checks, which are operated by different teams, and the customer waits. Meanwhile in Sanctions screening, it turns out Julie hasn’t asked all the questions they need so they have to contact Julie to get more information from the customer. Julie manages the customer by trying to give him realistic expectations of how long the account will take to set up and answering his questions.

Now let’s picture the scenario differently. The same customer, with the same needs, walks in. Julie walks up the customer and asks what they need. On learning that the customer wants to open an account, Julie performs a triage, adjusting the questions along the way. There’s a question about the offshore funds, so she calls Pete over to offer some expert advice. Pete answers the question, drawing on an online tool for a quick answer, and the customer has the account provided with mobile payments and card issued on the spot. The transaction takes minutes.

So far, so Apple. But what’s happening in the background? We’ll look at those two scenarios in more detail later when we’ve covered the second capability type, but the key differences in the case managed example are.

• Multi-skilled customer facing teams available onsite at the point of customer interface to support every aspect of the customer need, not just sales
• Customer service teams able to adjust workflows in real time based on customer input
• Customer facing teams able to draw on core standardised resources, preconfigured to allow for instant access
• The resulting customer experience is seamless and quick, with controlled customers in the places they belong

Sounds too good to be true? It isn’t, but achieving this model takes careful design and whole operating model change, either at the service level, the capability level or the organisational level (usually all three) and that’s not a simple process, or an easy transition. We’ll examine the pitfalls below, in “Getting it wrong”. But in the meantime, let’s look at the details of building this capability model.

Building blocks

Figure BFB-BF-CMCS-3: Operating Model for Capabilities

If you’ve read other articles in this series, this model will be familiar by now. As with every other aspect of your organisation – target operating model, service model, and the capabilities themselves, you need to design every aspect of your Capability to be effective. In this context, you’ll note there’s a self-referential encapsulation – you can, and will, have capabilities within capabilities. That’s ok, and a Case Managed team is, by definition, a capability composed of other capabilities – how that works with horizontal capabilities and communities of practice is covered in the Service Architecture and Communities of Practice articles.

Here’s the breakdown for a typical Case Managed capability in a large bank – obviously, you can refer to the other chapters and in particular Target Operating Model Elements for more details, so I’ve tried to highlight the key ones, but that doesn’t mean you can ignore the rest:

Service Delivery

Capabilities

As discussed elsewhere, Capabilities are the things your organisation does; they are also encapsulated within other Capabilities, so you have a nested arrangement.

Processes

As discussed above, in contrast to linear end to end processes, Case Managed processes are composed of the same elements you would see in a linear process (mandatory activities, optional activities, decisions, flow of control, etc) but rather than these being arranged in a predetermined sequence, they are a toolkit at the disposal of the team.

Capacity

Closely related to team composition and role definition, you need to understand the throughput of demand. Historical data is useful for traditional services but when building new services, you will need to use modelling, analytics and prototyping to determine the ideal team capacity. Embedding multiple roles with flexibility to transfer capacity is key to managing this effectively.

Skills

Clearly, there’s a flipside to giving your customer facing teams greater autonomy, and that’s the need for them to have really strong skills and clear understanding of the impact of their decisions. Training is an important element, obviously, but you will also need to consistently maintain skills and ensure people are kept up to date with new service developments, processes, technology, regulations, etc. This is where Communities of Practice play an important role, backed up by pull training such as blogs, online guides, etc. Case Managed teams also create both the opportunity and the need for cross-fertilisation of skills, which will happen at an informal level, but also needs to be actively curated via role allocation procedures.

IT Solutions

Are not the subject of this article

Components

Decisions

Decisions are core to the governance of service alignment; what they are, which roles take them, and formalised structure for predictable outcomes based on a particular configuration of parameters. Formal decisions such as gateways and benchmarking (KYC, AML, pricing as examples) need to be captured and articulated so that the outcome is always consistent.

Products

The products the Case Managed teams use will be drawn from core standard pools of products (e.g. loans, PCs) and configured by them for the user at the point of delivery. Designing this product set and how the Case Managed teams configure it is obviously critical to this approach working well. The fewer products you have, the higher the level of customisation the teams should be able to apply. This also means balancing the skills to configure the tools (see Decisions, Skills etc) so that the Case Managed teams have the right level of knowledge both about how to configure the products, and the implications for the customer and the organisation.

Channels

Channels are key to customers experiencing a consistent service, however they access it. Channels also need to be designed so that services can be dynamically configured based on the customer’s input, with or without human intervention, seamlessly and in a way that is consistent with their face to face interaction with your organisation.

Artefacts

A governance charter is an important artefact for any self-organising team and this is equally true when that team is case managed.

Business Service Team

The often neglected element of service design, how you structure your teams is critical to delivering customer value and shortening value chains, so this needs to be particularly carefully designed. And yet it is often not only neglected, but consciously ignored, largely because it’s perceived as too difficult to change. But without changing this element, you will never resolve underlying service challenges; this is fundamental to building service alignment into your organisation and, as discussed in Building Service Aligned Organisations, should be the first place you start to build your change, in order to achieve the quickest and most important impact to customer experience.

Organisational Architecture

Organisational Structure

Your team is flat, so where’s the structure? Well, a “flat” team isn’t completely flat in the sense that everyone is equal – there will be more and less experienced team members, with different roles, and in many cases these people will need to organise into sub-teams with more or less formal internal structures, to achieve certain purposes. These structures are flexible, and one person can hold a more experienced role in one field, supervising the work of others, yet in another capacity be the subordinate/learner, supporting someone else more expert in that capacity, who might be her subordinate in the other sub-team. This makes best use of people’s strengths, without creating artificial hierarchies based on years of tenure or expertise in an unrelated area.

One of the roles will be responsible for allocating work or facilitating the allocation of work within the team, while that individual may not necessarily have any other roles we would associate with traditional management. There is a role (or roles) in each self-organised team which is responsible for interfacing with broader teams. Other roles will be “buyer” roles for services from other teams. You will also have the need to perform validation checks (4-eyes etc) and while this is partly determined by roles, some factors, such as regulatory obligations or your own internal needs, may require supervisory elements for certain types of activities.

And of course, where the team fits within the wider organisation is a consideration. It doesn’t sit within the old hierarchical model, but organisationally and for practical purposes you will need it to sit within a certain cost centre and broader sphere – usually the wider capability it’s serving. These organisational constructs, which are in reality largely theoretical anyway, are weaker in service aligned organisations than in the traditional hierarchical organisation, because more accountability is held at team level and less passed “upwards”, but there is still a broad organisational hierarchy.

Communication Networks

Communication networks and how they are designed are critical to the success of case managed services. Because there is a need for short value chains to support responsive delivery of other services, and in particular core standardised components, your communication network must always be designed with the aim of reaching the end service with the minimum possible divergence, and preferably directly. As you will easily imagine, this creates a spiders’ web of formal communications networks. Visualising these is more complex than capturing a traditional hierarchy and they don’t look so neat, so it gives the impression the organisation is more complex. But consider, that in this case what we’re capturing is not the formal reporting-line driven hierarchy – we’ve done away with these – but the communications networks, which in effect become the hierarchy, or the nearest thing there is to one – we don’t traditionally capture our formal or informal communications networks on traditional organisation charts. These are usually several orders of magnitude more complex, but we don’t notice how complex these networks are, because we don’t document them. Service aligned organisations will document their communications networks so there is transparency; people know what to expect, how to find the information and who to go to for help or information. In traditional organisations you’re expected to “know”, because they’re too complex to document.

Of course, there are also informal communications networks, which are built up by communities, and many of these are related to communities of practice (CoPs), your “shadow” organisation and the engine driving development, methods and learning in your teams.

Team Makeup

Team makeup is, of course, the key foundation to building successful case managed teams. As mentioned above, businesses and service organisations have been doing it for ages, so it should be much better understood than it is, but this sort of knowledge is slow to filter between industries and even within organisations. We think this is because of two reasons: it’s hard to visualise it working when your only experience is of a traditional hierarchy; and actually when you go and look at one, you don’t see the labels. Because there aren’t any. Teams are just teams. Your branch team just look like a branch; your employee onboarding team just look like a call centre. The fact that there are people in that area with experience and qualifications in HR, IT, Security, Analytics, etc, isn’t obvious to the outside observer, or even the customer, because they all have multiple roles and share duties (unless required not to by law/regulation).

Your teams, while identifying with their “home” communities of practice for skills development and tools, will also naturally identify more with the service they deliver than with the roles they fulfil; this doesn’t stop them being proud of their skills and keen to apply them in the best way they can to support the goal of the team, and you’re never going to get to a full communal “levelling” of everyone on the team to perform identical sets of roles, but they will talk about their job in relationship to the team’s purpose, rather than their skillset and how they apply it. This is further supported by your team goals, which again are aligned to the service (see below)

Roles

Defining clear roles and making them visible is critical to service alignment. The role descriptions form a core part of the governance of service aligned organisations. Roles differ from job descriptions in that they are not in a 1:1 relationship with people; individuals can, and in most cases, do hold multiple roles. Roles remove the association between authority and accountability; they also separate out traditional management tasks such as prioritising and allocating work, representing the team, and decision making and distribute these across different team members in a way that best supports the service. The key difference to traditional hierarchies is that the authority to make decisions is embedded into roles which have expertise, rather than leadership roles, and this is distinct from the role that is responsible for allocating work.

Responsibilities

Responsibilities include Domains, Accountabilities and Decision Rights. The Domain is where the role plays, which defines the boundaries of the responsibilities. Accountabilities are what the role does, while Decision Rights are what the role is expected to take responsibility for deciding.

Domain: in most cases, the Domain will be analogous to the service the team is providing, together with any subdivisions necessary to support specialisation. For example, in a Build my Business team, colleagues may be subdivided by customer segment, but their domain will include all the Build my Business customer journeys.

Accountabilities are usually fairly easy to identify; these are the things the role does to provide the service to the customer, such as customer relationship management, identifying components, etc. An important part of case managed accountabilities is clear articulation of the accountability to configure the customer experience at the point of delivery.

Decision Rights have two elements; the decisions the role is expected to take, and which other roles need to be engaged to support the process of making that decision. So for example, a lead allocation role which is responsible for allocating work within the team, will have a decision right for confirming the priority of work in consultation with the team involved and with key customer roles. Fulfilling Decision Rights requires both the consultation and the decision to be effective; the decision cannot be made in isolation, unless it’s for a type of Decision Right that doesn’t involve consultation. Examples of Decision Rights that don’t involve consultation are the decision about the order in which to manage components of a service, for customer facing staff, or the decision about which options to offer customers when configuring their experience. These two decision rights are the most important ones to get right in designing case managed teams:

Prioritisation: teams must be able to dynamically readjust their team composition to support fluctuating customer demand (for example, Operations and IT staff fulfilling customer facing roles at peak times). One role will be responsible for role allocation, however teams should also be able to adjust in real time without direction, using visual management tools The Lead Allocation role will be responsible both for the initial setup and for guidance around who picks up which other roles when capacity is crunched, but dynamic decisions can also be made by other roles within these parameters. Regular governance reviews will also adjust the standard setup and again, the Lead Allocation role calls the shots on this and on the new parameters within which roles can dynamically adjust.

Service Configuration: Customer facing roles must also have the ability to make decisions about how to adjust and present services, for example deposit maturity terms, product bundling, loan terms, etc. Clearly this requires key knowledge as well as full appreciation of the impact of their decisions both on the customer and the organisation, which has implications for skills (see below) but also for which other roles are involved in making those decisions. For example, some decision rights may include mandatory consultation with one other role, for example where a sales role needs confirmation by a compliance role before making a decision about credit risk.

Career Progression

Career Progression in service aligned organisations doesn’t follow the traditional triangle-shaped linear hierarchy, with people getting progressively better at one thing until they’re expected to switch to a completely different skillset (management). Instead, while individuals will progress from less skilled to more skilled roles in the same domain, they will also be picking up other roles which may not be directly related to that skillset, and thus be expanding their portfolio of skills and accountabilities. While we don’t deal with pay structures here, it’s worth noting that seniority and increased compensation are associated with greater role accountability, domain and decision rights, rather than the traditional association with the number of people managed.

Career paths within skillsets are also managed formally within the Communities of Practice (see Communities of Practice)

Technical Skills

Technical Skills are managed formally within Communities of Practice, but it’s also common for teams to agree they need specific skills training internally, and then communicate this to the relevant communities. The push is likely to come from individuals responsible for using those skills, but can also be identified by the wider team.

Leadership Skills

Leadership becomes more important when formal management is diluted, as multiple roles include leadership elements and therefore many more people are expected to display leadership skills. These skills can be developed in three ways:

Peer coaching within teams: feedback within teams is built into the governance model, and the multiple leadership roles gives opportunity for much more peer coaching than you would see in a traditionally structured team, as nearly everyone is likely to have a leadership role of some sort.

Formal coaching by Coaches: Coaches are a small but critical element in supporting Case Managed teams and Communities of Practice, and they also have a key role in leadership development for teams, ensuring best practices are adopted and shared across the organisation.

Formal teaching: to make peer coaching effective, it is sometimes necessary and useful to formalise learning for key role models in the organisation; you will also have a new set of leadership skills to communicate to people as they learn to adopt the model, which may require more formalised and structured teaching. However beyond your initial setup period (which may take a number of years), you should aim, as far as possible, to embed mentoring and coaching within the teams and communities of practice, rather than relying on third party trainers.

Service Objective Setting/Measurement

Traditional organisations develop metrics at a team or individual level based on the things that team does, which seems to be a logical way of measuring things. However, this builds in a bias towards focusing on a part of the service offered to the customer, and encourages siloed behaviours. Service Alignment needs your teams to think of themselves as part of the whole service, not just their component. With the right team metrics, you can embed this mindset into the teams and at the same time align their day to day prioritisation with their longer term performance goals.

Alignment to Strategy

Customer Outcomes/Objectives

Customer Outcome metrics developed during service design must be visible to all team members. For example, “Is the customer able to use their account within 15 minutes of application?” would be a metric that the case managed customer facing team will share with supporting core standardised services such as KYC, AML, Product design and Channel support, to name a few: any capability supporting any part of the customer journey is measured on that outcome. The nice thing about measuring customer outcomes is that most of them have a straightforward yes/no answer, and are therefore very easy to measure. They are also easy to monitor in real time; these metrics can so easily be built into your customer journeys and customer service model.

Customer Focus Performance Metrics

Slightly more challenging to identify, performance metrics that support customer experience indirectly can also be built into the teams if necessary, for example to measure the knock-on effects of customer satisfaction, to provide throughput indicators for supporting functions and leading indicators for complex activities with a longer term customer outcome. An example of this is the “repeat calls” metric, which indirectly measures the success of the initial customer contact by monitoring how many times the customer contacts the organisation to resolve the same problem.

Business Results

Of course, customer outcome metrics are the best indicator of how well your business is performing in real time, but you are also likely to have some more abstract indicators of how well you are achieving other business results – and not just the financial ones! Metrics such as staff attrition and sick leave taken will give you a barometer of the mood of your workforce, while setting targets around training days sends a very clear message to your staff about how you expect them to self develop.

There’s also a place for the more traditional forms of measurement if there’s no direct customer outcome from the activity, for example processing invoices; however even these should be managed by self-organising teams and prioritised within the team, rather than being driven top-down. Visual management techniques can also be used to manage these types of metrics in real time – for example, the old three tray trick – one red, one yellow and one green, is a low-tech example of how work can be prioritised and rebalanced in real time.

Ethics and Values

You probably already have metrics around compliance; behaviour based metrics should reflect the expression of your ethics and values as measurable targets. How do you measure “we’re responsible members of the community” and “it’s all about people”, though? If it’s in your values statement, you can put a metric around it. For example, just like training days, setting targets for days for your staff to give back to the community gives a strong message about how you expect your staff to represent your organisation to the wider community – you can’t force them to volunteer, but by creating the space for them to be out there and using your internal networks and communities of practice to come up with opportunities for people to give back, you create the opportunity for them to discover the benefits for themselves. Banks can also tap the rich skillset of their employees to support both voluntary and emerging organisations in developing projects, business models and so forth, bridging the parapet and engaging the wider ecosystem. Metrics can also measure the behaviours related to positive reinforcement; you can’t force your people to thank each other for work well done, but if you start recognising and rewarding positive behaviours, the effect spirals.

External Governance

As mentioned above, it’s likely you already have compliance metrics. A problem I always had with nearly every compliance metric I’ve seen in banks, is that they’re all negative, i.e. the metric is “I haven’t breached X rule”, which is all very well, but it doesn’t go very far towards building positive behaviours, and leads to compliance being seen as a burden, rather than a benefit. Back to the old question, “is Compliance a department or a behaviour?” we should be able to identify behaviours compatible with compliance and build metrics around these, for example, a metric to check if you have considered whether a decision benefits the customer before making that decision, rather than retroactively checking that cross-selling hasn’t breached certain rules.

Core Standardised, Capacity Managed Capabilities

First, a health warning: I tend to avoid using the term Capacity Managed in conversations with stakeholders, because it can confuse people, but the term best describes how these capabilities fundamentally differ from the prevalent internal service model we see in most banks today: the ticket, or request-driven approach. In this approach, nothing happens unless driven by a specific request, and only then are teams mobilised to start providing a service. In Capacity Management, service teams anticipate the capacity that will be needed, and frontload that capacity so that it will be available when needed. Just as water or electricity is provisioned, enough is there when you need it, and you use what you need, when you want it. That sounds really simple, and actually, it is.

The underlying assumption is that when you regularly produce large volumes of something, you can predict the need for that something based on past demand. The challenge is that the greater the number of variations of that something there are, the more difficult it is to forecast how many you will need of each variation and the harder it is to manage it as capacity. So it’s also really important to reduce the number of variations as much as possible, unless you are supported by a layer of capacity managed elements. Even service organisations producing essentially similar outputs, with some variation, can be managed in this way, by applying a thin case managed layer within the capacity managed capability (which is a perfectly effective variant of this model, discussed below).

The advantage of this two layer approach is that, by configuring the capabilities at the point of customer delivery, i.e. the Case Managed end, whether it’s a separate capability or embedded within the Capacity Managed capability, we can achieve much greater standardisation at the back end by having a very small set of base products, artefacts, resources and core components. For example, if your customer facing teams are empowered to fix the term of a deposit based on customer requirements, you don’t need a three month, a six month, a 12 month and an 18 month version. You just need a deposit. The same applies to everything from technology to agreements. So with little product variation, volumes are much easier to forecast and it becomes very easy to manage frontloaded capacity.

So what’s wrong with using the term “Capacity Managed”? Our experience has told us to shy away from any term that looks as though it might involve doing something “to” people, and most leaders leap on the “capacity” word as related to people, rather than output. So we feel the term Core Standardised, while not so descriptive, is sufficiently accurate, and captures the critical essence of why you’re doing this, for leadership consumption.

Like Case Managed teams, Core Standardised teams have embedded prioritisation rights and decision rights. This means that they don’t need to operate on a ticket based system; just like the Case Managed teams, they can and should use visual management techniques to have visibility of the customer metrics in real time and are able to adjust priorities in order to meet the metric for each customer, achieving a much higher hit rate than the usual time-bound targets for ticket closure.

How does it work?

Referring to the Building Blocks model in the previous section, many elements of Core Utility teams are exactly the same – teams are self-organising, self-prioritising, can share multiple roles and readjust in real time. Unlike Case Managed teams, they are also usually their own Communities of Practice, so many of the things you would normally expect not to find in a Case Managed team, such as skills development, career paths and management mentoring, exist within the home Capability for Core Standardised services. This has both advantages and challenges; it can lead your Core Utility resources to feel differentiated if not managed effectively, so you need to give them the opportunity to explore additional roles both within and outside the Core Utility Capability, if they want to experience how their skillset could be applied to other types of teams, for example. It also means that you are likely to be tempted to centralise all three management roles (Lead Allocation, Lead Link and Pastoral Development) into a single individual. This should be avoided, not just because it will give the Capability the tendency to be more inward-looking and hierarchy focused, but also because it creates unnecessary stress in the single leader, and the subsequent need to create multiple layers of cascading hierarchy to support them, thus losing many of the advantages of agility and flexibility, and making self-governance impossible.

Table BFB-BF-CMCS-1: Case Managed vs Core Standardised Similarities and Differences

The advantages of this approach to supporting services, on the surface, are the significant cost saving involved (and this should not be ignored, both manpower and capital investment are reduced by around 20-30% by this approach) and the improved time to market of the output. Quality also goes up considerably, but again this isn’t the only benefit. As with Case Management, the key consideration here is the impact on customer experience, which is significant not just because it delivers a better customer outcome, but because of the engagement with that customer outcome your supporting service staff are now able to experience, partly because you’ve shortened the value chains so they are closer to the end customer anyway, but also because they are now self-managing their own throughput based on visible customer satisfaction metrics – not some internally generated “do it in three days or else” metric, but “did the customer get what she wanted? Yes or no? Did we meet the date we promised as an organisation to deliver this service and was it to the quality we expect our customers to experience?” It may be hard to imagine the impact that has on the supporting service teams, who usually haven’t been anywhere near a customer, let alone understood how what they do benefits them. The effects, I can assure you, are extraordinary.

Let’s use a really geeky and buried-in-the-organisation example.

About ten years ago, a very large global bank (one of the largest, I mean really, really big) had a problem with delivering storage into its data centres. Not surprising, this was universal before virtualisation and Cloud were widely used, and even now in most major banks, it’s pretty normal, especially for Mainframe and Midrange. We have to wait for a need to arise before we commit to spending any money, right? I mean, this kit is expensive, we need to be really sure we need it before we put our necks on the line and order it. Then the big guys have to prioritise what they need to buy. Obviously nowadays many of us (not all, and not always) have more flexible options for storage, but even if this is the case, we still face this challenge in many service areas. I’ve chosen this example to demonstrate that it’s not just AML or Product standardisation that this works on

In this bank, it took about nine months to get a new server – six if you were very lucky. That’s because when you were developing an application and you wanted some storage for it, you had to be pretty sure how you wanted that application to be set up before you could even order the storage; the data centre engineers knew they’d have to order bespoke kit for you, so they wouldn’t even talk to you before you knew what you wanted. Then once you’d got to the point in your development cycle that you had a pretty good idea what configuration and volume you’d need, you could go ahead and order the kit. The engineers would then design it, build a spec, and have that signed off as ok from an architectural perspective. Then they’d build a bill of materials for the vendors, which the vendor would quote on. That quote would then be built into a financial approval process with 55 (yep, 55) mandatory approvers. When it had been approved, the quote had expired because it took longer than a month to get responses from all 55 approvers, and go through the layers of meetings (two in EMEA, one in HQ) for signoff, so you had to get another quote before revalidating and making any necessary adjustments. Eventually it found its way into the order system, someone would order the kit, and you’d eventually get it delivered (3 month order cycle) and then someone would schedule it for racking, stacking and configuration in the data centre. When you look at that, you have to be impressed that they even did it in six months – and usually they didn’t, unless you could shout very, very loud.

Multiple attempts had been made over a number of years to fix the ordering system, by introducing new technology for placing tickets, putting in place architectural controls, etc. But none of these helped make it quicker, in fact most of them slowed it down even further. Because the answer was that the root of the problem (time to market) was a misperception of what successful customer outcomes looked like. The underlying assumption in the system was that the primary objective of the (internal) customers was to have custom builds for everything they were creating. This was proved to be false even before the core standardised service was introduced to replace the old system – orders stopped coming into the team over two months before the new service went live. Because the primary objective wasn’t the specialisation; it was getting storage. By moving to a capacity managed storage service, lead times dropped from nine months to six days, and probably could have been driven down further, but it wasn’t felt necessary at the time.

So how did it work?

The solution was simple; achieving it was less simple. Instead of the full request based design, order and build service, we moved to four types of server within each of the core technology families (Unix/Windows) – Small, Medium, Large and Very Large. These were bought in batches and pre-racked and stacked in advance, with standard operating systems loaded. A small, Case Managed team was created within the capability to manage incoming orders and apply any operating system configuration needed at the point of delivery. This team of six consisted of people with project management, engineering design, capacity management and service delivery skills. Embedded in the Core Standardised capability, they were the only people who weren’t hardware engineers of some sort, or Data Centre support staff, and they identified with the skills communities from which they came, while their primary anchor was in the Capability they served. An existing order system was modified to support the new, hugely reduced options available, which made it much easier to learn and use for the team.

I’ll be honest, when it first went live, I was nervous about the backlog, when those two plus months of orders hit the system, but it worked like clockwork and we immediately hit our SLA of six days (or less). There was still the option to order fully customised kit in the case where something special was needed, but this was hardly ever used; the level of configuration that could be applied was more than enough for most purposes. Our assumption that customisation was needed at every level of hardware build had simply been wrong, even though it had originally been based on experience of how orders came in – but we had never tested our assumptions against customer behaviour, simply what they were telling us.

Immediate benefits delivered by this change were:

• Time to Market reduction from nine months to six days
• 32% cost saving on Data Centre supplier and service management
• Reduced errors and greater environmental stability due to simpler architecture and more standardised builds
• Greater transparency and traceability made incident management much simpler (and less needed)
• 72% reduction in number of infrastructure project managers needed
• Reduced staff attrition
• Faster onboarding of staff due to reduced learning needs
• Reduction in cost of approvals process (which had been running at about $3.500 per request in man hours)
• Greater transparency for Total Cost of Ownership, as Data Centre rate cards were completely standardised

Of course, implementing this new approach was not without challenges. The main difficulty to overcome was persuading Infrastructure management and Financial Control to invest upfront, rather than waiting for the tickets to come in before making an investment decision. Analysis was needed to support the business case for making a change that is so counter-intuitive, and I hope the results listed above, based on our experience, will help you to visualise similar ideas for supporting your business case.

Getting it right

As you will have seen, this is a big design job. Like with Communities of Practice, building a Case Managed or Core Standardised capability requires both an element of top-down design and a strong element of co-creation. The keys to success are:

• Start with your target architecture / transition architecture: the capability must support your overall vision and fulfil a clear purpose. However, structure your governance with built-in flexibility and the ability to redesign as customer needs adjust and you learn from experience.
• Prioritise a small number of key areas: trying to shift a whole organisation towards this model quickly will result in confusion, change fatigue and failure.
• Start with the Case Managed customer facing capabilities; the Core Standardised capabilities will represent a big saving and de-risk to your organisation, but fixing customer experience doesn’t need to wait for this, and it will start to deliver benefits immediately, building confidence and pull for the approach.
• Don’t skimp on analysis, but focus on the things you want to fix (customer experience, time to market, cost, quality) rather than too much detailed process analysis; you’ll almost certainly be replacing some of the old processes anyway. A couple of focus groups together with a high level Lean approach based on your core team will yield results, and give you a good idea of whether you have a business case for change, pretty quickly
• Use professional, dedicated coaches and facilitators: facilitating co-creation effectively is particularly important when your teams are relatively new to the paradigm; as they learn through experience, they will become more confident with the principles of service alignment and the techniques of service design and co-creation, however it will still be important to facilitate significant changes to your capability structure, to ensure the wider targets are included and that teams don’t become too self-focused.
• There’s no such thing as Done: creating a service aligned team is the beginning. The most important thing you are building in alongside your customer experience is the team’s ability to dynamically adjust, learn from the customers and each other, and feed that learning into further adjustments to governance and to your service architecture.

Getting it wrong

None of this can be done without careful design and it’s easy to fall into pitfalls along the way, either by attempting shortcuts without achieving the necessary structural and cultural changes, or by trying to retrofit the model into an existing hierarchy. Obviously, moving from a standard model to Service Aligned isn’t straightforward. Critical mistakes we’ve seen include:

• Declare victory too early/overpromising – if you’re getting it right, you shouldn’t have to declare victory too loudly, as your customers and the rest of the organisation will notice, and create pull. Obviously you need to have a business case, and you will have investors to satisfy, so create targets, but keep them modest and achievable. If your business case promises a 15% cost reduction and you achieve 30%, nobody will be too upset.
• Assume your existing managers will take on all the lead roles in the new organisation: apart from the act that most existing managers will have been drawn from a pool of people not naturally talented at management (i.e. people who are very good at something else), all leaders are stronger in some areas than others, and dividing up the lead roles gives you an opportunity to think about which qualities will be best suited to those roles, and then to find people with those qualities. Trying to retrofit your existing leadership team into roles without designing it, won’t work unless you’re very lucky indeed.
• Try to keep everybody happy by minimising the rhetoric about how different this is: mot people are uncomfortable with change and initially respond badly to new ideas. But it doesn’t take long for people to become enthusiastic about self-management and shorter value chains, because the benefits to employees and customers are so obvious. But if you try to pretend this is just a minor adjustment to your existing team, you won’t achieve the scale of change you need for it to be effective.
• Designing it all in minute detail, top down: as you go through this process, always bear in mind that however excited you are, and however much invested you are in this model, you have no idea what everyone in the organisation does in everyday life – what their products are, how their processes work, what the business rules are, who needs to talk to who – this can only be achieved effectively by co-creation within the overall structure you design, which in itself should be a co-creation exercise.
• Not designing it at all: conversely, you will be asking teams to design roles, structures, governance and accountability in a completely new way to anything they’ve experienced before (in most cases); you will also need to ensure there are expert facilitators to guide them through the process in the early stages, until you reach the point where you are developing your own expert facilitators in-house as part of the natural heartbeat of the governance review process in the organisation.
• Try to plug it into the existing hierarchy/performance metrics: none of this will work in isolation; you need to change the whole operating model for it to work.
• Impose change by stealth: you need both very clear communication and very visible sponsorship to make this level of change to an organisation; bottom-up doesn’t work. You need to have a clear direction for at least a significant chunk of an organisation, in order to impact whole capabilities. If the sponsorship isn’t yet there, then you need to address that first.

Conclusion

In this article, we have described the two basic building blocks of the Service Aligned organisation: the Case Managed capability and the Core Standardised capability. We have discussed the different elements you need to design to ensure they are created effectively, and discussed the need for teams to co-create the capabilities within the broader capability architecture you have designed. We’ve given you a comparison table to understand the similarities and differences, and briefly discussed the relationship between Communities of Practice/Centres of Excellence and the Case Managed/Core Standardised model within Service Aligned organisations.

We have included a case study of the Core Standardised model, demonstrating how by lifting customisation into Case Management, you can achieve extraordinary improvements to customer experience factors such as time to market and to organisational targets such as cost and headcount. We have also included key tips for Getting it right and Getting it wrong. Key points to take away:

• Case Managed and Core Standardised are two superficially very different types of capability needed to deliver full service alignment in banks; they share important common elements such as internal self-management and key governance constructs.
• Fundamental to Service Alignment, enabling Case Managed capabilities to configure the customer experience at the point of delivery supports radically standardised product and supporting services in your Core Standardised capacity
• These teams must be created within an overall service aligned capability architecture which is flat and delivers core elements rapidly to the customer via the Case Managed teams, to be fully effective
• However, delivering Case Managed customer facing capabilities early will achieve enhanced customer experience, even before you’ve tackled the Core Standardised capabilities.
• Co-creation and building learning into the governance of your teams is critical to ensuring services are well designed and able to self-adjust

 * we have been publishing articles under the title 'Let's Build a Bank' for the last year or so, but have now decided that this is exactly the opposite of what's needed. No-one needs another bank; what we need are interoperable financial services ecosystems that support the needs of participants, producers and consumers, reach the unbanked and financially underserved, and drive a new democratisation of trust, fair commerce and non-exploitative flow of value operating within well governed and compliant frameworks. So 'Let's NOT build a bank'. Let's change the world with some extraordinary thinking and sustainable financial development. 

@SofieBlakstad @rallen_consult