Architecting the new wave of automation

RESEARCH REPORT // FREE
 
This report tackles the subject of ‘automation architecture’ – the practice of deliberately planning and shaping how your organisation invests in work automation technologies. Automation architecture is important because – on the surface at least – numerous technologies have the potential to compete or substitute for each other in enabling the automation of aspects of knowledge work. For example: Robotic Process Automation (RPA) vendors claim that their technologies can be used to automate not only individual tasks, but also automate sets of tasks. Does this mean that if you use RPA, you don’t need to use workflow technology? This report attempts to help you answer these questions.
Automation architecture is a way for you and your colleagues to establish a set of clear guidelines and patterns that will help teams make the right decisions as they scope and conduct automation projects – making it clear to project teams how different automation technologies complement each other and add value to each other.

Top takeaways

A clear strategy is vital if you’re going to get the best out of technology choices on offer

Automation has been on a steady march through business for over 200 years: nevertheless, the past three years or so have seen a huge step-change in the variety of technologies being promoted to help businesses automate aspects of their work.

Given the wide variety of automation-related technologies being pitched to organisations, and the speedy pace of automation technology evolution, your organisation must develop an automation strategy that clearly and deliberately sets out how and where you will look to apply different kinds of automation technology capability – and why you are looking to apply particular technologies in particular places.

Think about ‘how work works’ as your automation starting point

We all know intuitively that not all work is equally amenable to automation: some work is highly suited to extensive automation, whereas the opportunity to automate other work is much less obvious. What is it that makes the difference?

A good starting point is to think about categorising work according to how much expert discretion is required to perform it. The more discretion is required, the less amenable the work will be to automation.

In practice we find that there are three types of work commonly found ‘in the wild’ in organisations, with human discretion tending to be required for different blends of features across the three types (which means each type is amenable to automation or augmentation with digital technology in different ways). We call these exploratory work, transactional workand programmatic work.

Make your architecture work real and practical

Once you’ve begun to analyse how you might use different kinds of automation technology to address opportunities in the different kinds of work you have in your organisation, it’s vital that you think beyond this analysis and put some plans in place to drive that analysis forward into action that will have real impact. There are four things you particularly need to focus on: collaborate and share your work in the open; be deliberate about creating an automation technology operating model; don’t fall in love with any one automation technology too much; and review your assumptions and analyses regularly.

The changing business automation landscape

It might seem like automation in the workplace is a relatively new phenomenon – there’s certainly a huge amount of talk about it in today’s corporate meeting-rooms, conference halls and news media. The reality is that automation has been on a steady march through business for over 200 years: nevertheless, the past three years or so have seen a huge step-change in the variety of technologies being promoted to help businesses automate aspects of their work.

One component of the energy pushing this new wave comes from organisations themselves, as they seek to apply digital technologies and concepts to make them more attractive and more competitive. The other component comes from changes in the economics of automation – the tools are becoming cheaper, quicker to deploy and easier to use, and data to train and improve ‘smart’ systems is more and more easily available.

In industry: digital initiatives are driving automation investments

Businesses the world over are rushing to explore digital initiatives. Some are driving full-on digital transformation programs; others are working more modestly, looking to apply digital technologies to particular business products and services, capabilities, activities or processes.

What’s become abundantly clear is that any organisation thinking about ‘digitising’ aspects of their business needs to think holistically. Customers’ experiences aren’t only shaped by customer service teams – they’re shaped by the interactions they have online; conversations with salespeople; the quality of a product; the accuracy of bills; and so on. By definition, delivering great customer experiences depends on activities that your organisation carries out across many teams and departments.

The implication is this: delivering on a digital transformation agenda ultimately means creating “digital threads” that enable organisations to seamlessly carry out and co-ordinate work, make decisions and share knowledge effectively, consistently and at scale – across teams, systems, channels, media platforms and business locations. The “digital outside” of your organisation must be connected to and supported by a “digital inside”.

Automation – of work, and of how work and information are connected together across an organisation – is a huge part of the answer. End-to-end automation of work is not always possible or desirable. But even where such automation is not possible, there are ways to use digital platforms to improve the work environment.

In technology: automation is cheaper and goes further, faster

It seems that every week we’re bombarded with new work automation technology choices.

From about 2000 until 2015, organisations had three main technology choices if they wanted to automate aspects of administrative work: they could implement packaged business software applications (automating aspects of practices like ERP and CRM); they could build their own applications using traditional custom software development tools (probably based on Java or .NET technologies); or they could use more business-friendly, model-driven platforms to build systems (primarily focused on workflow automation and business rules automation).

Now, those three choices remain – but they’re joined by more:

  • Robotic Process Automation (RPA).  RPA technology provides a set of tools that organisations use to design, configure, deploy and manage software robots that act as synthetic application users, automating tasks across business software systems. RPA ‘bots’ gather and update information in business software applications by automating actions against their existing Windows-based, web-based or other user interfaces, and provide a non-invasive alternative to creating and using specialised integration APIs or programmed integration by other means. Specialist vendors like Automation Anywhere, Blue Prism, Kryon, Workfusion, UiPath and more offer RPA technology that works in two specific modes: unattended deployment uses RPA bots in a ‘headless’ configuration, working on tasks behind the scenes with no direct human involvement; whereas attended deployment uses RPA bots in an interactive mode, working side-by-side with human users to complete tasks from within users’ desktop environments.
  • AI services and frameworks. With a particular emphasis on machine-learning algorithms, a new wave of AI services – particularly focused on automated sense-making and interaction using voice and vision – has started to have a major impact. A big part of this impact comes from the fact that many of the technologies are offered free of charge, or offered via low-cost subscriptions. Additionally to these low-cost, general-purpose frameworks there’s renewed interest in using machine learning to create tailored, predictive analytics models that operate on structured data and can deliver tailored, context-sensitive recommendations to individual business people ‘in the flow of work’. Big brands like IBM’s Watson, Adobe’s Sensei and Salesforce’s Einstein operate across these categories, but there are many other players too – big web platform players Google, Amazon and Microsoft are investing huge resources here, and hundreds of smaller specialist technology vendors also in the frame.
  • Low-code application development platforms. Often bringing flexible workflow technology with them, a set of specialist vendors (K2, KiSSFLOW, Mendix, OutSystems, QuickBase and more) are offering increasingly sophisticated application development platforms for teams and departments wanting to drive quick digitally-driven improvements to their operations. Typically cloud-hosted and subscription-based, these tools excel at enabling business-technology generalists (rather than deep software development specialists) to quickly and cheaply build “good enough” business automation systems. Many of these platforms also provide high-grade deployment and administration options that enable systems to support more demanding enterprise-scale requirements.
  • Low-code application integration platforms. A set of specialist vendors (Azuqua, Dell Boomi, Jitterbit, SnapLogic, Workato and more) offer sophisticated, primarily cloud-hosted application integration platforms to business-technology generalists looking to quickly integrate cloud-hosted and on-premises applications and systems. With high-productivity, low-code approaches to the design and deployment of integration code these vendors are making application integration technology economical for an increasingly broad and diverse range of scenarios.

How do you make sense of how all these technology options fit together, and make sense of the different opportunities they present?

Building an automation strategy

Given the wide variety of automation-related technologies being pitched to organisations, and the speedy pace of automation technology evolution, your organisation must develop an automation strategy that clearly and deliberately sets out how and where you will look to apply different kinds of automation technology capability – and why you are looking to apply different technologies in different places.

You need an automation strategy that you can communicate widely across your organisation. Without one, the danger is that – because there’s so much technology variety on offer, because there is so much interest from different quarters of business in automation generally, and because there is significant danger of technologies being used for purposes they’re not necessarily most appropriate for – your organisation will end up with big problems. You may waste your investments, introduce unnecessary operational risks, and/or hinder business agility and scalability (through poor-quality, brittle technology implementations).

In this section, we introduce a way of thinking about the work that gets done in your organisation that will help you map out the best potential ‘sweet spots’ for individual automation technologies and see where multiple technologies can potentially be profitably used in combination.

An anatomical reference model for work

It can seem at first as if all these technologies we’ve talked about in the previous section are overlapping and potentially substitutes for each other. However different categories of automation-related software technology, for the most part, affect different aspects of work in different ways.

In the following sections we look in detail at how different technologies can be applied in different ways, for different types of work. To make our analysis consistent, the explanations in the following sections all reference a consistent ‘anatomical reference model’ of how work happens (which you can see in figure 1).

Figure 1: Anatomy of a job-to-be-done

Source: MWD Advisors

Our anatomical reference model for work has eight features:

  • A goal sets out the desired outcome of the work. A goal might be expressed purely in terms of functional delivery (for example: “assess this claim”) but often will also include aspects of the desired outcome that are related to time, cost and so on (for example: “assess this claim within eight hours”).
  • Business context for the work that shapes the work to take account of the specific situation at hand (an example: the current status or loyalty tier of a customer requesting a particular service – here, a ‘premium’ customer may be eligible for more personal attention and a ‘regular’ customer might be serviced automatically).
  • A flow of work that shapes how the completion of tasks can lead to other tasks needing to be performed; along with associated work assignment policies that determine which tasks should be made available to which workers. Of course, these days it’s common to see these flow models specified ahead of time using some kind of sequential workflow model, but this doesn’t necessarily have to be the case.
  • One or more tasks represent the individual activities that need to be performed in order to achieve the goal. In almost all situations, at least some of the tasks required to complete the work will be known ahead of time – but of course in the real world, there are many situations where not all needed tasks will be predictable in advance.
  • One or more decisions that need to be taken in order to determine the outcome of the work, and in many cases to determine the tasks that need to be undertaken along the way.
  • Input information and material, and a trigger that invokes the work (for example: the notification of an insurance claim, along with the details of the claim and the identity of the claimant).
  • The output of the work.
  • A set of resources needed to complete the tasks. These will include existing business software applications and IT systems, of course, and may also include reference and guidance material, expertise from co-workers, and so on.

Note that our anatomical reference model makes as few assumptions as possible about the ways that these eight features are implemented in practice. For example, we don’t assume that workers are human, we don’t assume that flow is determined by a hard-coded workflow model, and we don’t assume that decisions are encoded in decision tables or a scripting language. That’s because as we start to look at the tools and technologies that are part of today’s business automation landscape, we see that in some cases different tools and technologies map onto the same features of our model, but use different approaches and strategies to drive automation.

Not all work is created equal (for automation)

We all know intuitively that not all work is equally amenable to automation: some work is highly suited to extensive automation, whereas the opportunity to automate other work is much less obvious. What is it that makes the difference?

A good starting point is to think about categorising work according to how much expert discretion is required to perform it. The more discretion is required, the less amenable the work will be to automation. But looking again at our model in figure 1, the obvious question then springs to mind: what feature(s) of the work in question are we talking about when we talk about ‘expert discretion’? And conversely, what features are able to be prescribed in advance? It’s by answering these questions that we start to map out our framework for automation strategy.

Three types of work: programmatic, transactional, exploratory

In practice we find that there are three types of work commonly found ‘in the wild’ in organisations, with human discretion tending to be required for different blends of features across the three types (which means each type is amenable to automation or augmentation with digital technology in different ways).

Figure 2: Prescription in programmatic, transactional and exploratory work

Source: MWD Advisors

Figure 2 highlights the three types of work we commonly find and shows, for each type of work, the features of the work that are typically prescribed ahead of time:

  • Programmatic work. With this kind of work, almost all features of the work in question – from tasks and decisions to flow, inputs, triggers, and resources – can be prescribed and designed in detail. This doesn’t mean that the work is automated, but it does mean that in theory it’s possible for the work to be almost completely automated (with people only handling any exceptions that occur). Many types of clerical back-office administration found in organisations from banks to retailers fall into this category.
  • Transactional work. With this kind of work, many of the tasks and decisions involved, and most of the flow of work, can be prescribed and designed in advance. The goal of the work is often also prescribed in quite a structured way. However human discretion and expertise is required to carry out some tasks, as well as in deciding when, how and where work needs to be progressed. A good example of a process revolving around transactional work is mortgage application processing (where the steps and decisions required are almost always definable ahead of time, but human discretion is often required to review decisions and minimise risks of fraud).
  • Exploratory work. With this kind of work, the goal of the work will be defined ahead of time, but the set and sequence of tasks and decisions needing to be performed, and the people or roles needing to perform them, are very unlikely to be decidable ahead of time. There may be some high-level waypoints or milestones that are common to a particular type of exploratory work (perhaps to ensure regulatory compliance, or management approval) but they provide a very loose, rather than tight, structure. In exploratory work, as the label suggests, the overall experience for both the work participants and the ‘customer’ of the work is that of a set of possibilities being explored rather than a recipe being followed. Common examples of processes revolving around exploratory work include complaint resolution and fraud investigation.
  • Building your automation strategy with our three work types

When we look at organisations and how they carry out work from an end-to-end business process perspective, we see a common big-picture pattern: business processes tend to be composed of our three types of work as explained above.

Figure 3: Prescription in programmatic, transactional and exploratory work

Source: MWD Advisors

We see many business processes being structured along the lines of figure 3:

  • The work carried out at the ‘front end’ of business processes – the work that’s driven from external (customer, partner, supplier) requests and interactions – tends to be somewhat exploratory and needs some degree of expert discretion to deliver the best result.
  • In these situations, the work that flows ‘downstream’ as a result of initial interactions with customers, partners and suppliers – the work that’s involved in taking actions and making changes in various business systems – tends to be more transactional or programmatic in nature.
  • Where work not driven directly by external parties is exploratory in nature (fraud investigation or compliance checking are good examples), the work that flows downstream from this work – the work involved in recording outcomes, updating reference systems and so on – is still transactional or programmatic in nature.

Considering again how our three different types of work are automatable to differing extents, a clear strategy presents itself (as shown in figure 3):

  • Analyse the work that gets done today in your key business processes to identify which parts of the work are exploratory, which are transactional and which are programmatic.
  • Where you find programmatic work (and you will typically find it ‘downstream’ from work that requires more human discretion to complete) explore opportunities to drive as much automation into this work as possible.
  • Where segments of your business processes are more exploratory or transactional in nature, look to use automation technologies to augmentthe work of human knowledge workers – providing smart assists for those people, and so putting the ‘human in the middle’ of work, rather than trying to automate what humans do. 

Exploring your work automation options

In this section, we look at our three types of work (programmatic work, transactional work and exploratory work) in turn and show how different kinds of automation technology can be used for each work type.

Automation options: programmatic work

Where work is highly routine and rules-based, the current vogue is to apply RPA technology (specifically unattended RPA) to automate as much of that work as possible. Certainly, unattended RPA technology is a likely candidate in many situations – but it’s not the only thing you might want to consider.

Figure 4 provides an overview of the roles that different automation technologies can play in programmatic work. The sections below provide more information about the suitability of each technology to particular scenarios.

Figure 4: Automation options for programmatic work 

Source: MWD Advisors

Unattended RPA

RPA technology is particularly useful today as a way to automate and orchestrate frequent, highly routine and rules-based interactions with IT systems, where those systems don’t have handy integration APIs. However, RPA isn’t the best option in every situation. For one thing: although RPA bots can work faster than humans as they ‘type’ and ‘read’ information through an application’s user interface, their overall performance is limited by the speed with which those applications can render and update through their user interfaces.

Application integration platforms

Where the source and target applications required to carry out programmatic work expose their own programmable, documented APIs, or where high-performance automated integration is a key requirement, a purpose-built application integration platform is likely to present a better option than RPA technology.

Where source/target system APIs are available, a purpose-built integration platform will perform much more efficiently than an RPA platform – and as part of the same package, they also typically bring sophisticated data transformation capabilities that make it straightforward to change the formats and structures of data as they’re passed from one system to another.

These purpose-built integration platforms have a reputation in some quarters for being expensive to procure and complicated to use, but in recent years this reputation has become increasingly outdated: as cloud-based, subscription integration platform services have become more popular and more capable they’ve become a lot simpler to use (by employing ‘low-code’ model-driven design techniques) and a lot cheaper to procure and use.

Intelligent capture and AI services

In situations where programmatic work fulfils administrative requests from customers, partners or suppliers (for example, fulfilling a shipment delivery address change request) it’s often the case that such requests arrive in a variety of formats over a variety of channels – for example requests might arrive via email, fax, PDF or via a web form. In situations where work inputs arrive in the form of documents, you should consider using intelligent capture technology to digitise the data in those documents and identify and extract key data fields. Intelligent capture technology, for example, can automate the digitisation of contracts and invoices, and automatically identify extract key terms and items (like contract signatories, subjects and key clauses; or like PO numbers, invoicing addresses, totals and products, payment terms and so on). Third-party commercial or open-source AI libraries can further enhance the flexibility of this technology by improving the accuracy of image or document classification, as well as improving the accuracy of detecting important features in the data that will be used to drive subsequent decisions (and improving the later discoverability of assets, by enriching document metadata).

Some RPA technology vendors offer intelligent capture capabilities as part of their platforms, either themselves or via partnerships with specialist capture technology vendors. However, integration platform vendors rarely provide these capabilities themselves.

Decision management and external business logic services

Whether you’re employing RPA technology or a purpose-built application integration platform as the backbone for automating programmatic work, there will be situations where significant business logic needs to be worked through in order to drive end-to-end automation. For example, in processing and responding to simple customer administration requests, you might want to execute some business logic to determine which RPA bot needs to be invoked to process each inbound document and update the relevant back-end system(s).

We’ve seen a number of situations where adopting organisations have simply used the inbuilt features of their automation platform of choice to code this business logic – most often leveraging a scripting language of some kind. This isn’t always a bad idea, but it can be.

The key considerations here are: is it important that this logic is transparent and easy to understand? Is this logic likely to need to be used elsewhere, too? If either or both of these are true, then you should seriously consider externalising this logic, using specialised tools and deploying it as a separate capability. Where you’re encoding sophisticated decision logic that needs to be auditable and easily understandable to a range of stakeholders, you should seriously consider leveraging a specialised decision management platform to manage this business logic (which you can also use to design, deploy and control other key business decision logic).

Automation options: transactional work

Where work needs to be structured to a significant degree ahead of time, with work following a prescribed flow and set of prescribed rules about which actors are qualified or authorised to carry out which tasks, workflow technology (either contained within ‘heritage’ BPM or workflow platforms, or contained within more modern, low-code process application development platforms) is a natural fit.

However, there are other technologies that can complement workflow, providing ‘smart assists’ to human workers and augmenting a core foundation of workflow, depending on the situation. Figure 5 provides an overview of the main technologies worth considering.

Figure 5: Automation options for transactional work

Source: MWD Advisors

Workflow

Specialised workflow platforms are a natural fit for transactional work because they’re expressly designed to make it easy to specify, and change, an automated flow of work that determines who does what, in what order.

Modern workflow platforms provide flexible facilities to distribute tasks to human participants where they need to be performed by people – and in the more sophisticated platforms, that distribution can be influenced not only by workers’ roles and where they sit in the organisation, but also according to workers’ skills and their availability. These platforms also make it easy to specify automated implementations for certain tasks – essentially enabling you to implement automated tasks via the programmatic work automation patterns we describe above.

Intelligent capture and AI services

In situations where transactional work fulfils administrative requests from customers, partners or suppliers and work inputs arrive in the form of documents, then as in our discussion of programmatic work above you should consider using intelligent capture technology to digitise the data in those documents and identify and extract key data fields.

Also as is the case in the context of programmatic work, third-party commercial or open-source AI libraries can further enhance the flexibility of this technology by improving the accuracy of image or document classification, together with the accuracy of detecting important features in the data that will be used to drive subsequent decisions.

Workflow technology vendors are increasingly partnering with intelligent capture technology vendors and embedding third-party (or open source) AI image-detection and feature-extraction libraries.

Attended RPA

In contrast to unattended RPA – where bots execute to drive UI-based automation on servers, behind the scenes – RPA technology can also deployed in attended mode. Here, instead of being installed on virtual desktop images that run on servers, bots are deployed on users’ own desktop and laptop computers.

In attended mode, the goal is not to have RPA bots automate complete tasks end-to-end. Instead, users invoke RPA bots themselves at specific points in their work, using them as ‘automated assistants’. At the end of a process to respond to a customer enquiry, for example, a human user might invoke an RPA bot to update a handful of legacy reference systems to close out the process; in a call centre environment, an agent might invoke a bot to automate logging-on tasks across multiple systems and applications at the start of a shift.

Attended RPA technology is a useful augmentation for workflow deployments in automating aspects of transactional work because in principle it enables organisations to increase the ‘coverage’ of automation in processes that are fundamentally still driven by knowledge workers, to include ‘long tail’ automation opportunities where implementing more sophisticated (but complicated to implement) integration technologies is difficult to justify.

Decision management

Decision management tools have a very similar role to play in the context of transactional work, as a complement to a workflow ‘backbone’, as the role they can play in programmatic work.

Where modern workflow platforms typically employ visual model-driven tools to help teams specify workflows and change them over time – rather than having those workflows coded in a programming language – decision management platforms apply the same concepts to decisions and their implementations through business rule sets. Just as workflow platforms excel in specifying flows in a way that’s explainable and easy to maintain over time, so decision management platforms also use abstract definition approaches (some based on visual models, some based on natural languages) to help teams specify decisions and their implementations in a way that’s explainable and easy to maintain.

Although it might be tempting to implement decision logic that needs to run within workflow models using a traditional programming language, if those decisions have any kind of business relevance and impact then you should consider using a specialised decision management platform instead.

Predictive models

Most decision management tools available today are designed to support teams implementing decisions using prescribed business rules that always produce a definitive result (for example: if the customer is a premium customer, have an agent call the customer back; otherwise, send an email response to the customer’s request).

However, there’s also a lot of potential value not in automating decisions with prescriptive rules; but in guiding decisions through automated recommendations, based on predictive statistical models. For example, a customer retention team might build a model that predicts, based on perhaps dozens of data features related to a customer’s record and their service usage history with your organisation, how likely they are to switch providers (or ‘churn’). These models don’t provide definitive results: they provide confidence levels. So, for example, a predictive customer churn model might highlight that for a given customer with a given history, that customer is currently 81% likely to churn. A trained call centre agent can then use that information to make an informed judgement.

Historically, the cost of computing meant that predictive model generation and maintenance would typically be carried out by a specialised team using dedicated infrastructure, and that models would be applied to business data in batch mode on a periodic basis. However in recent years, competition in the provision of cloud computing infrastructure services has created environments in which it’s now feasible to apply predictive models in real time, in the flow of work, as decisions need to be taken. This means that where predictive models used to be used primarily to do things like shape email marketing campaigns, they can now be used interactively as part of conversations with customers.

Automation options: exploratory work

Where the goal of work can be clearly prescribed but the details of how the work needs to be performed are hard to define in advance, case management technology – often offered by BPM or workflow platform vendors alongside support for more structured transactional work – is a natural fit. However, there are other technologies that can complement a foundation of case management technology, depending on the situation. Figure 6 provides an overview.

It’s worth noting that at a high level, the automation technologies that can add value to exploratory work, and the roles that they can play (figure 6), are broadly similar as for transactional work (figure 5). In practice, the crucial difference in how technologies can be applied is that as case management technology enforces less prescribed structure on work than BPM or workflow technology does, there are correspondingly more opportunities to use complementary technologies here to offer knowledge workers recommendations and other smart assists.

Figure 6: Automation options for exploratory work

Source: MWD Advisors

Case management

Case management technology provides a ‘container’ for exploratory work, improving co-ordination and communication between people carrying out the work, providing structure where required for regulatory or business policy reasons, and logging and tracking the work so it can be audited or analysed later to drive improvement. Within case management platforms cases are typically structured at a high level using the concepts of milestones or stages, and within those, mandatory and optional tasks may be definable – with designers being able to define conditions under which certain tasks or become available to work on.

Intelligent capture and AI services

In situations where exploratory work fulfils requests from customers, partners or suppliers and work inputs arrive in the form of documents (for example: in fulfilling customer requests to receive complicated products or services), then as in our discussion of programmatic work above you should consider using intelligent capture technology to digitise the data in those documents and identify and extract key data fields.

Also as is the case in the context of programmatic work, third-party commercial or open-source AI libraries can further enhance the flexibility of this technology by improving the accuracy of image or document classification, together with the accuracy of detecting important features in the data that will be used to drive subsequent decisions.

BPM and workflow technology vendors, many of which offer case management frameworks, are increasingly partnering with intelligent capture technology vendors and embedding third-party (or open source) AI image-detection and feature-extraction libraries.

Attended RPA

As in our discussion of transactional work, attended RPA technology is a useful augmentation for case management deployments in automating aspects of exploratory work because in principle it enables organisations to increase the ‘coverage’ of automation in processes that are fundamentally still driven by knowledge workers, to include ‘long tail’ automation opportunities where implementing more sophisticated (but perhaps more complicated to implement) integration technologies is difficult to justify.

Decision management

Decision management tools have a very similar role to play in the context of exploratory work, as a complement to a case management ‘backbone’, as the role they can play in transactional and programmatic work. However as mentioned above, the opportunities to add value with decision management tools – specialised to make it easy to design and maintain automations of complicated decisions – are likely to be greater in the context of exploratory work.

For example, you couldspecify the logic of a decision that determines which insurance products to offer to which customers, based on a number of factors (perhaps age, income, medical history, family arrangements, credit score, and so on) using a traditional programming language, and automate the decision that way. However the result would be likely to suffer from transparency and maintainability issues. Alternatively, you could provide training materials to advisors so they can try to make the decision manually – but even with significant time and money devoted to training, that might lead to inconsistency, bias and quality issues. Neither of these alternatives helps you manage crucial operational business decisions, or their implementation, effectively and economically over the long term.

Predictive models

As we described in the context of transactional work, there’s also a lot of potential value not in automating decisions with prescriptive rules; but in guiding decisions through automated recommendations, based on predictive statistical models.

In the context of exploratory work, where fewer work features are prescribed through up-front design, there are more opportunities to use predictive models to make recommendations that guide the flow and results of work. We’ve seen examples of predictive models being used to:

  • Recommend best-next actions for workers to take as they progress cases – matching case features against those of historical cases to recommend courses of action that are most likely to resolve the case quickly.
  • Recommend colleagues who can help with progressing a case, working on a task or making a decision – based on the features of the case and the skills of all available colleagues provisioned on the system.
  • Recommend guidance documents and procedures that should be referenced by people working on a particular case stage or task, based on case features and the use of reference documents across historical cases.

Taking your next steps

Once you’ve begun to analyse how you might use different kinds of automation technology to address opportunities in the different kinds of work you have in your organisation, it’s vital that you think beyond this analysis and put some plans in place to drive that analysis forward into action that will have real impact.

This final section offers some next-steps advice, drawn from our community research and client engagements.

Collaborate and share

Just as is the case with any architecture exercise, automation architecture work will return most value to your organisation if you do it in the open. Seek to share your automation patterns and technology guidance with other stakeholders as you’re developing them, so the business and technology teams across your organisation that are driving projects have the opportunity to ask questions, provide feedback and see the potential for savings and risk avoidance that a consistent approach will bring.

If possible, organise a roadshow or internal marketing event where you can talk to multiple stakeholders and teams all at the same time. When stakeholders can see that their challenges and opportunities are similar to those that others have, the benefits of taking consistent approaches to applying automation technologies will be much more obvious to all.

Be deliberate about your technology operating model

For some operations leaders and managers, work automation – particularly automation of programmatic administrative work – can seem very much like outsourcing. In some ways it is, particularly when you consider how RPA technology vendors position their products and services as providing a ‘digital workforce’ that can potentially replace a human workforce (in the right work context).

One of the very important ways that automation is unlike outsourcing, however, is in the operating model you’ll need to support automation in the business. Traditional process outsourcing involves humans being paid wages to do routine work, with work cost and quality as the principal areas of management concern and control. One natural consequence of this is that outsourcing tends to aggregate and consolidate the performance of work into ‘factories’ – using shared-services models.

Where automation technology is concerned, however, software doesn’t need to be physically deployed anywhere in particular. Certainly, work doesn’t need to be physically aggregated in one place. Bots can be developed and deployed in a widely distributed fashion if that’s what makes most sense for technical, or political, reasons.

However it absolutely does make sense to consolidate and aggregate knowledge and experience about how to design, configure, deploy and maintain automations in once place where possible. Some organisations call these consolidation points ‘centres of excellence’, some call them something else. Whatever you call it, you should push to create and maintain a team that works to manage and maximise the knowledge of what works in your business, and make sure that knowledge is shared as widely and effectively as possible.

Don’t fall in love with any particular technology too much

Hopefully, by know you realise that across the variety of automation technologies currently available and ready for enterprise use, different technologies play different automation roles across the features of different types of work.

Be careful not to overstretch any particular technology, trying to use it to automate work features (or work types) where it’s not suited. Be aware of what each kind of tool is best at doing, and be aware of the risks of overstepping those boundaries.

Review your assumptions and analyses regularly

Be aware that over time, the boundaries that you draw between exploratory, transactional and programmatic work are likely to shift. As this happens, it pays to be aware that more automation may be possible and profitable.

As automation technologies mature and are able to more economically automate more and more human-discretion tasks (and this will surely happen), you may find that work you would initially characterise as transactional (for example) could be reclassified as programmatic and automated straight through.

A good start is an annual architecture review process that explores how work is classified, reappraises technology state-of-the-art and investment cases, and determines whether reclassification of work (and therefore the application of new automation patterns) is necessary.

 

Download PDF version
RESEARCH REPORT // FREE