Broadly speaking, IA refers to the use of automation technologies such as Robotic Process Automation (RPA), Business Process Management (BPM), and Artificial Intelligence (AI) together to streamline and scale workflow and decision-making across organizations. You might also hear about the term hyperautomation, which was defined by Gartner [3], where they refer to it as a business-driven, disciplined approach that organizations use to automate as many business and IT processes as possible. In a way, IA is often used within the context of the overall hyperautomation initiative of an organization. [4]

We believe that there are three key motivations driving the need for IA:

• Speed and rate of changes – With the COVID-19 pandemic, many businesses have had to change how they work, how they interact with their customers, their sales models, and many of them have even had to change their products. Additionally, many of these businesses realize that they have to react and make changes within days as opposed to weeks or months. This has resulted in an unprecedented pace of digital transformation, and success, in many cases, depends on how fast an organization can react to sudden changes and real-time decisions.
• Stay competitive through better customer experience – These days, in order for businesses to stay competitive, they have to improve their customer engagement experience (for example, NPS score and retention ratio), but at the same time, they need to make sure their operating cost is under control and be able to do more with less.
• Labor shortage – Many businesses are suffering from labor shortages and many have a high volume of repetitive tasks that are still being performed manually.

To create a successful IA project, we believe an integrated automation platform that supports a low-code/no-code approach to automation is necessary to engage everyone in the enterprise to create a usable and scalable solution. This is where IBM Cloud Pak for Business Automation comes in.

IBM Cloud Pak for Business Automation [5] is a set of integrated software that will allow organizations to accelerate their IA and hyperautomation journey. There are multiple entry points for Cloud Pak for Business Automation – whether it is Workflow, Enterprise Content Management, Data Capture, Decisions, Business Apps, RPAs, or Process Mining.

Customers do not have to use all of them, but they can start with any one of them to complement what they already have in place today. With the focus on low-code/no-code, increasing use of built-in AI, and the integrated development experience, we should be able to identify the business impact alongside the time to value.

The following figure is a high-level component overview of Cloud Pak. Cloud Pak is built upon Red Hat OpenShift Kubernetes as the foundational technology that allows it to run in a multi-cloud environment. We then provide a set of foundational technology – RPA, Natural Language Processing, Process and Task Mining, Event Management, Machine Learning, third-party integrations, and a comprehensive set of operational models – to support a set of core automation and accelerators such as Workflow, Decision Management, Content Services and Document Processing, and Operational Intelligence. To complement all of these capabilities, we provide a low-code application design environment where customers can build automation applications for their business users:

Figure 1.1 – Component overview of Cloud Pak for Business Automation

The following table shows the key features that will be covered in this book:

Table 1.1 – Cloud Pak for Business Automation capabilities

There are other capabilities, such as IBM Content Collector for SAP Applications or IBM Enterprise Records, that are designed for specific content management use cases. For more information about those capabilities, please refer to the IBM Cloud Pak for Business Automation Knowledge Center (https://www.ibm.com/docs/en/cloud-paks/cp-biz-automation/21.0.x?topic=automation-using-cloud-pak-business-software) for details.

RPA

A large part of any human-centric process automation is related to work that will need to be performed by humans. This would be knowledge-based work, such as providing a medical diagnosis for a symptom, or repetitive work, such as copying information from one website to another. The purpose of Robotic Process Automation (RPA) is to automate as much repetitive work as possible, oftentimes with the help of AI.

While we assume that in today’s digital world many repetitive tasks have already been automated, there is still a large portion of the daily work in an organization that will require manual labor. In many instances, these kinds of tasks are situational or occasional, while some of them are performed daily. Imagine a data clerk responsible for processing incoming invoices (by email or fax) into an order processing system (such as SAP) or a consultant that will need to enter their project activities on a time tracking system for billing purposes.

RPA is a program (in this case, it is a software robot) to mimic human users’ interaction with their desktops to perform tasks. The RPA bot performs mouse clicks and keyboard strokes on the computer screen to enter the information into the ordering application. One question that is sometimes asked is how RPA is different than other API-based integration techniques (for example, popular personal automation platforms such as IFTTT, integration-centric approaches such as SOA or microservices, or script-based automation such as Ansible runbook). One key difference between RPA- and API-based integration approaches is that RPA is not only limited to the command line or API, but also the user interfaces.

Despite the advances in the API economy in the last decades, there are still many legacy business applications (for example, CICS, IMS, and SAP) or native applications (for example, Windows-based) that do not provide modern APIs or command lines. In some cases, the user just doesn’t have access to the APIs (imagine you’re using a third-party web-based application, such as a banking website or an online bookstore) – since the chances of legacy business applications giving regular users access to their backend API are very small.

Workflow

For many years, workflow, or Business Process Management (BPM), has been the starting point of many IA projects. Lately, the term workflow has become more popular as it implies a broader definition for the sequencing of activities – whether the activities will be performed by humans (Task Workers or Knowledge Workers), robots (RPA bots), or system services.

There are also three major workflow processes:

1. Straight-through process
2. Human-assisted process (or process-centric)
3. Knowledge-driven process (or case management or case-centric)

Depending on the use cases or maturity of the business process, we could start with a non-deterministic knowledge-driven case-centric solution, and as the process matured, it might evolve into a more deterministic process-centric straight-through process.

Decisions

There are thousands of decisions made by all of us every day – even simple things such as what is the next word to use in an email or the route to take when driving to work. In the business world, a decision could be used to determine the risk score of a borrower or the premium of a life insurance quote. The ability to automate decision-making is a key approach to speeding up and also adding intelligence to your automation.

Automation Decision Services is a low-code experience that allows business users to build and automate their decisions. Traditionally, decisions were created through a combination of business rules and decision tables. More recently, we also combine the use of AI/ML to combine deterministic rules together with predictive rules.

Content management

Documents are still the primary means where information is exchanged. In 2020, Statista estimated there were 306.4 billion emails sent and received per day. At some point in your IA journey, we must tackle the issue of automating how these documents/contents are stored, updated, accessed, processed, archived, and deleted.

Document processing

Closely related to content management is how to extract the information from the documents that are managed by the content management system. Typically, the optical character recognition (OCR) technique can help with identifying the characters that are buried within a document but understanding that the sequence of numbers is an invoice number is a different matter.

In a well-structured document such as a tax form or a questionnaire with predefined boxes, it is relatively easier to identify the meaning of certain fields. However, many of the documents that require human processing would fall into the class of semi-structured documents (for example, invoices or bills of lading) or unstructured documents (for example, contracts, emails, and memos). The ability to capture information from all document types (structured, semi-structured, and unstructured) will be a key attribute in automating the entire workflow. In Automation Document Processing, we make use of various AI techniques to allow knowledge workers to teach the system visually to recognize information from documents without having to write a single line of code.

Process discovery and process mining

Before you can create an IA solution, first, you must understand the business problem and how it comes to be. There are two approaches to process discovery:

• In the first approach, the business analysts will bring all the business stakeholders together, and using a process documentation tool, the business analysts will create a business process diagram (typically using the Business Process Management Notation (BPMN)).
• More recently, with the advances in technology, you can also use a Process Mining tool to discover processes by analyzing and correlating information from multiple transaction logs.

It is also often useful to apply both techniques, first by using a process documentation tool to describe the perceived business process and then by using a process mining tool to discover the actual process. By comparing the two, you can more easily identify existing process discrepancies and potential business-compliant issues.

Business applications

In any IA solution, time to value is paramount. Additionally, this means we must have a way to bring all the automation to the hands of the business users, independent of whether they are working from the office or remotely using their mobile devices. The ability to create business applications and leverage low-code techniques will allow your automation developers to create both strategic and situational applications and make them available to your business populations in days versus months.

Operational intelligence

In any IA solution, intelligence can come in one of two ways:

• The first way is through built-in AI; examples include cognitive AI skills such as natural language processing, vision recognition in RPA bots, or content extraction in the document process.
• The second way is to use the data gathered or generated during the everyday processing of the application to gain insights and can, thus, be translated into actions. This second way is where operational intelligence comes in.

Your business processes or bots can create a large amount of business data, and many of them capture the decisions made by the task or knowledge workers as they perform their work. The operational intelligence component in IBM Cloud Pak for Business Automation (CP4BA) provides a data lake where all the data can be stored and then subsequently analyzed and used to create predictions or recommendations.

CP4BA differentiates itself in the market through four key different aspects:

1. Low-code/no-code: A completely integrated environment to build automation using a true low-code approach to build enterprise solutions – whether it is workflow, content, decisions, robots, apps, or interactive agents.
2. Built-in security, scalability, and governance: One argument against low-code/no-code is the proliferation of badly written solutions that are not secure, do not scale, or have a lack of change control. Given the enterprise software heritage of CP4BA, IBM already considered many of the non-functional characteristics that an IT shop demands, so clients do not have to worry about coming up with something themselves.
3. Built-in AI: There are many examples where IBM is pioneering the use of AI within its solutions with no need for customers to hire data scientists or any kind of ML modeling.
4. The breadth and depth of the portfolio: With thousands of clients using the technology inside CP4BA worldwide, chances are that some clients have implemented your use cases before and there is enough flexibility in the products to support your use cases.

The following section will explain, at a high level, how to design an IA solution.

IA solutions

When starting an IA project, it is important that we guide the stakeholders (often, these are the line of business owners or IT executives) to focus more on the intended business outcome rather than a specific set of technology. The intended business outcome can be to improve the customer engagement experience, speed up the time to value of existing projects, or increase the agility of the business in response to changing business conditions. By focusing on the business outcome, we can help LOBs to better define the business problems rather than just a particular solution upfront.

In this section, we will discuss how to go about the methodology and considerations to create a solution architecture for your IA solution.

Business analysis

An IA solution cannot be truly successful until we get buy-ins from both the business and IT sides of the organization. To get those buy-ins, enterprise architects can start with a business analysis and utilize an approach such as IBM Design Thinking to bring both business and IT together.

There are several important principles that enterprise architects and automation developers can use to create an initial concept of a solution:

• Hills: Hills are statements of meaningful business outcomes. They are written with users in mind and will describe the Who, What, and How aspects of what the solution is trying to achieve.
• Playbacks: In simple terms, playbacks are the gatherings of minds that are used to keep stakeholders, clients, and teams in sync. Playbacks should occur at regular intervals and often align with either the start or end of a development iteration of an agile development process.
• Sponsor users: Sponsor users are people that the project team engages on a regular basis to solicit and gather feedback. Sponsor users can be a part of your project team, but often, they are external users who can provide guidance and feedback as you design the IA solution.

This book will not go into detail about how you can apply Design Thinking to your IA solutions. For those who are interested, there are reference materials available on the IBM Enterprise Design Thinking website (https://www.ibm.com/design/thinking/).

Understanding the CP4BA architecture

To begin the solution design, a high-level understanding of the CP4BA architecture and its use cases would be beneficial. The CP4BA architecture is designed with modularity in mind – you can start with just one capability, for example, workflow or RPA, and add more as the use cases expand. As you add each capability, new integrated use cases will become available:

Figure 1.2 – The CP4BA logical architecture

The following table explains each use case:

Table 1.2 – Examples of CP4BA use cases

Business scenario – client onboarding

To start putting together the solution architecture, let’s go through an end-to-end scenario, where multiple pieces of these solutions are used together.

In this scenario, we are going to implement an IA solution to onboard clients for a fictitious national financial consulting company. The solution consists of a business application, where the client representative collects all the required information and the requested services about the client before the representative will submit the request to the back office for further processing:

Figure 1.3 – Client onboarding scenario with corresponding key personas

Before we can design the architecture of the solution, first, we will need to break down the business requirements into a set of hills. In this example, we are going to start with three hills. Each hill should speak to the desired business outcome that we want to achieve as a part of the automation solution:

• Hill 1: As a client representative, I want to be able to collect all the necessary information to onboard a new client in under 10 minutes.
• Hill 2: As an account manager, I want to be able to validate and onboard a new client in under 30 minutes.
• Hill 3: As an account executive, I want to make sure a new client can be onboarded within 2 business days, with a performance report on a weekly basis.

You might notice that the preceding hills do not mention any technology at all, but instead, we are trying to focus on the business values – in this case, we want to make sure any new client can be onboarded within 2 business days.

In this case, we have identified four personas:

• The client
• The client representative
• The account manager
• The account executive

As a solution designer, you will have to go through one or more playback sessions with the participants – in this case, with the client representatives, account managers, and account executives to roughly identify the outline of your solution.

Hill 1

We will be creating a business application to help the client representative collect all the information required, such as the contact details and the services required, and even offer a potential quote. Once all of the information has been collected, the client representative will then submit the request for further validation and approval, and to schedule the actual service date with the client.

Through the design session, it was also decided that the business application will have three steps:

1. Fill out the onboarding info
2. Review documentation
3. Submit for approval:

Figure 1.4 – Hill 1 high-level solution architecture

Within each step, we will also be using other automation services to gather the necessary information:

• On Page 1: We will be using the Workflow capability to retrieve the client information by name. The reason for using Workflow is that we already know there is an available service in the back office to work with client information. We will also be using Decisions to determine an initial quote, depending on the currently-selected service plan, along with any past transaction history with the client.
• On Page 2: The client representative will get an opportunity to review any prior documentation that the company has collected about this client and to submit additional information this client will have. In this case, all documentation is stored in the content service.
• On Page 3: The client representative will get a chance to review the collected information with the client before submitting the request for approval. The approval will be handled by the IBM Enterprise Design Thinking website by a workflow in the back office.

Hill 2

In this hill, we will focus on the work required by the account manager to review the submitted information from the front office, approve the request, and schedule the requested services with the client. If the request cannot be approved, both the client and client representative will be informed:

Figure 1.5 – Hill 2 high-level solution architecture

The entire process will be orchestrated by a workflow, where multiple automation services will be used together to complete the client onboarding process.

1. The process will validate that all the necessary information is available. In cases where information is missing, the system will wait for documents to be provided by the client before proceeding to the next step. The client can upload missing information by sending the data via email, which will then be picked up by an RPA bot to deposit the information into the content repository.
2. In this step, we will be using rules and machine learning models from Decisions to categorize the client into segment 1 or segment 2 and will also leverage machine learning techniques to determine whether the request is a low-risk or a high-risk request.
3. We will be using RPA bots to update existing legacy systems with the assessment results and onboard the client into the system of records.
4. We will be using another workflow to notify both the client and the client representative of the approval or denial. If approved, the workflow will also instruct the client representative to work with the client to schedule the actual service calls.

Hill 3

In this final hill, we will be focused on the experience of the account executives. On a regular basis, the account executive should be able to inspect the business performance of the organization, and make adjustments (for example, re-balance the workload of different account managers) or suggest changes in the scoring model:

Figure 1.6 – Hill 3 high-level solution architecture

There are three data sources that we can use to draw information from:

1. In Workflow, we can obtain process performance information, such as the number of new onboarding requests per day, the time it took to complete an onboarding request, and the relative performance of the client representatives and account managers.
2. In RPA, we can obtain information about the success and failure rates of the robots, along with performance characteristics to decide whether any changes are needed.
3. In Decisions, we can obtain information about the scoring models and potentially make a comparison to the actual business outcome.

Technical Foundation

Since we usually focused more on the business outcomes during the initial hill discussion, one aspect that we sometimes miss during the initial hill discussion is the Technical Foundation hill. Technical Foundation is where we lay down the non-functional requirements of the solutions. In this particular use case, the following aspects are important:

• What is the expected client traffic? Is it hundreds or thousands a day?
• What is the number of client representatives that we need to support?
• What is the expected uptime of the system? Is it 8x5 or 24x7?
• What is the disaster recovery requirement? What are the recovery point objective (RPO) and recovery time objective (RTO)?
• What are the security requirements?
• Any data privacy and GDPR considerations? Are we storing any sensitive personal information (SPI)?
• What is the timeframe for the project? (1 month or 3 months)
• What is the budget for the solution?
• What is the set of existing services that are available?

Many of these questions will have a direct impact on the deployment topology and the overall cost of the solution. While everyone might want to be able to support thousands of concurrent users and want the system to be up 100 percent of the time, it does not come for free. We will discuss this further in Part 3, Deployment Considerations, of the book, where we will go deeper into the deployment topology and architecture of an IA solution.

In this chapter, we discussed the promise of IA and how an automation solution can be realized with IBM CP4BA. We provided a brief overview of the key capabilities in CP4BA. Also, we briefly discussed how to leverage the Design Thinking approach to break down the initial automation problem into a set of hills, and how we can come up with different solution architecture for each hill.

In the next chapter, we will go into future details on the key capabilities of RPA, Workflow, Decisions, and Business Applications.

• How COVID-19 has pushed companies over the technology tipping point—and transformed business forever, McKinsey & Company, https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/how-covid-19-has-pushed-companies-over-the-technology-tipping-point-and-transformed-business-forever
• Automation and the future of work, IBM Institute of Business Value, https://www.ibm.com/thought-leadership/institute-business-value/report/automation-workflows
• Gartner Glossary – Hyperautomation, Gartner, https://www.gartner.com/en/information-technology/glossary/hyperautomation
• Differentiating Between Intelligent Automation and Hyperautomation, IBM Cloud Education, Oct 2021, https://www.ibm.com/cloud/blog/differentiating-between-intelligent-automation-and-hyperautomation
• IBM Cloud Pak for Business Automation, https://www.ibm.com/cloud/cloud-pak-for-business-automation
• Number of sent and received e-mails per day worldwide from 2017 to 2025, Statisa.com, https://www.statista.com/statistics/456500/daily-number-of-e-mails-worldwide/