In Part 1 of this series on automation alignment, we described an overall approach to fitting the right type of automation to the type of work being
done. We discussed the high level of looking at the type of work being done and fitting Digital Business Automation (DBA) capabilities to that work.
Here in Part 2, we’ll focus on the Decision portion of DBA, indicated in Figure 1 in orange. 

 Figure 1: Digital Business Automation capabilities with Decisions highlighted 

Decisions permeate our everyday lives. They are everywhere and happen minute by minute. Some of them are subconscious (taking the known
path to work), and some of them are highly conscious, such as deciding to seek out a new job. They also permeate the organizations where we work.
Every business has probably thousands of decisions made per day, with some of them being very opaque, others being driven by regulations, and
others just a part of the company’s culture. Whatever type they are, there is no question decisions are weaved into every thread of a business. The
question for us is, how can we best automate these decisions? 

The way we approach making automation decisions is by leveraging an Automation Alignment Matrix (AAM). The Automation Alignment Matrix 
allows us to analyze the type of work being done and map that to the type of automation recommended.  

Figure 2: Automation Alignment Matrix 

Along the Y-axis, we measure the Uniqueness of Work being done, while the Volume of Work is measured along the X-axis. What we are attempting
to do with this matrix is determine where an automation capability best fits into one of the four quadrants based on the type of work being done,
with the type of work determined by its uniqueness and volume. There are other factors an organization should take into account, such as assessing
the relationship between job performance and strategic value, which will help you determine the return on improved performance (ROIP). ROIP is
a subject unto its own, which we may cover in another blog. For a deeper dive into ROIP, read Part 1 -> Step 2 of Reinventing Jobs by Ravin Jesuthasan and John Boudreau.  

Before we go too much further, some definitions seem appropriate. Low and High Volume (X-Axis), as well as Repetitive and Unique (Y-Axis), are
self-explanatory. However, the Programmatic, Transactional, and Exploratory terms along the X-Axis are less self-explanatory. The definitions for
Programmatic, Transactional, and Exploratory are from the MWD Advisor’s article mentioned earlier. These criteria were added to the X-Axis because
we felt they added more depth to the matrix. Below are definitions for the three words needing more explanation (somewhat appropriately, the
definitions for each of these get longer the less prescriptively the work can be defined up front): 

• Programmatic: Almost all the features of the work can be prescribed and designed in detail. It’s possible for the work to be almost entirely
  automated.  
• Transactional: Many of the tasks and decisions involved, and most of the flow of work, can be prescribed and designed in advance. However,
  human discretion and expertise are required to carry out some tasks, as well as in deciding when, how, and where work needs to be progressed.  
• Exploratory: 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. In exploratory work, the overall experience for both the work participants and the customer of the work
  is a set of possibilities being explored rather than a recipe being followed.  

We’ll look at Decision Automation in the context of all three types of work.  

Programmatic: 

For programmatic work (highly predictable), the consideration comes down to whether it is worth it to automate these decisions by encapsulating
the logic in rules, typically via a decision management engine. Also, companies can consider whether the thousands of rules they have buried in code 
should be externalized. These rules are what end up making many decisions for the company. However, they are not easy to get to or change, nor is
the logic transparent to the business users.  For programmatic work, much of the decision of whether to leverage Decision Management to automate
the rules comes down to whether transparency, reuse, and ease of understanding are important for that set of rules. If any of these are true, then
Decision Management becomes a good choice for automating rules for programmatic and repetitive work, regardless of whether the work is low or
high volume.  

Figure 3: Decision Automation for Programmatic Work

Transactional: 

For Transactional work, because many of the tasks and decisions involved can be prescribed and designed in advance, much of the way decisions can
be automated here mirrors what we defined for programmatic work. However, because transactional work requires human discretion to carry out some
tasks, as well as deciding when, how and where work needs to progress, there is a wrinkle to the way Decision Automation should be applied to 
Transactional work. For the highly predictable decisions, the standard approach of using prescribed business rules with predefined results is the best fit.
However, there are many situations in transactional work where things aren’t so predictable. In these cases, guided decisions are more appropriate than
prescriptive decisions. This allows the human to get advice based on predictive statistical models; this will help the human to take the next best step.  

An example of this type of transactional work is a sales process where there are certain steps and rules which are always followed. However, there may
be certain points in the sales process where based on the current prospect data combined with historical data of other customers, the predictive engine
could recommend a few alternate actions which have produced the desired outcome (a sale, or even faster deal progression) in the past. Figure 3 indicates
Decisions are relevant in the Transactional part of the matrix for both low and high volume work. 

Figure 3: Decision Automation for Transactional Work

Exploratory: 

Exploratory work is, by definition, unpredictable. The very word explore brings to mind going off and doing exciting and unforeseeable things. Every company
has a ton of exploratory work. This work is typically the highest value work done at a company. This area houses your knowledge workers, and we predict this
is where automation will eventually drive all human workers to live. Applying prescribed automation to exploratory work becomes much more difficult than
the other types of work, if not impossible. Think about the work your executive teams typically do. Mostly, it is making decisions and delegating work based on 
their experience and knowledge of the business. Trying to predict those decisions and actions through prescribed rules and workflows would be a recipe for disaster. 
Thus, prescriptive rules do not play much of a part here. However, guided decisions via AI engines suggesting next best actions are highly relevant here. If your
organization has a lot of historical data relevant to the exploratory area decisions are being made in, it would make sense to mine that data to determine what
decisions produced the most desired outcomes for your organization. From this, models could be created, which would augment knowledge workers to help
them make the best decisions. A great example of this is the way Ray Dalio described how his business ran in Principles: Life and Work. No decisions were made
without data, and because of this, their decisions kept getting better and better.  

Figure 4: Decision Automation for Exploratory Work

You may notice that the High Volume / Unique / Exploratory quadrant has an AI / Decisions icon which is smaller than the Low Volume / Unique / Exploratory quadrant.
That is due to the nature of exploratory / unique work. There just isn’t a lot of work that is highly exploratory in nature and also high volume. 

You now have a high–level approach to what type of work fits bests with what type of Decision Automation. In future blogs, we’ll cover Tasks, Workflow, Content, and
Data Capture, although not necessarily in that order. 

What is the Automation Alignment Matrix?

How to Avoid an Automation Tower of Babel

This is the first in a series of blogs describing an approach to aligning types of work with the proper automation capabilities within Digital Business Automation.

In the Bible’s Tower of Babel story, a group of people decided to build a tower to heaven. They were doing great until God realized they were going to succeed and decided he/she doesn’t want them making it to heaven without going through the proper channels. So, God decided to make them speak different languages. At this point, the construction of the tower grinds to a halt, and the people scatter to the corners of the earth. I’ve highly paraphrased the story, and maybe even taken some liberties, but you hopefully get the point. I’ve always thought the story was fundamentally about the incredible heights a group of people can reach if they speak the same language (culture) and have the same goal. And alternatively, what can happen if they start speaking a different language (culture) and their goals aren’t aligned. There are enough studies about companies who have a shared culture and set of goals that we know how incredibly important this is to success.

Figure 1. Szkieletor in Poland. Construction started in 1975 and has not finished yet

So what does this have to do with Automation? What every organization wants to achieve with automation is a much more productive and competitive workforce, with the hope their organization will gain an insurmountable advantage over the competition. As IBM states in their whitepaper Reinventing business with automation “Ultimately, the goal of digital automation is to move everyone in the organization closer to the expert level by giving them enhanced capabilities and empowering them to use those capabilities more effectively.” By giving users enhanced capabilities and freeing them from the highly repetitive and mundane, they are freed up for higher level thinking and possibly becoming indispensable experts, which gives them and their organization the possibility of being great. In our opinion, all greatness starts with expertise. To gain your insurmountable advantage, your organization has to put your employees in a position to be experts. Automation can help with this. 

 However, you cannot get your employees there if you are all speaking different languages. You’ll end up with your own automation Tower of Babel. We covered how you can create a Digital Business Automation Organization (Program or Center of Excellence is another way to put it) in a separate blog. Organizational alignment is integral to establishing a culture, or speaking the same language. Another essential part of the formula to make sure you are speaking the same language is to have a documented framework that allows you to analyze the type of work being performed, and match it with the type of automation which is the best fit for that work. There are some excellent write-ups on this, with one of the best coming from Neil Ward Dutton, formerly of MWD Advisors and now working at IDC. Unfortunately, the MWD Advisors website is no longer operational so you cannot download the article. However, there are a few other adaptations out there to give you an idea of Neil’s approach (recording of presentation at BPMNext,  podcast at bpm.com, and SlideShare). 

 While Neil’s approach is extensive and truly vendor agnostic, we wanted something a bit more narrow, and specifically created for the areas of automation covered by Digital Business Automation (DBA). DBA  focuses on the automation areas of Tasks, Workflow, Decisions, Content, and Capture, with all components being augmented and extended by AI. Since we are an IBM partner, this is what we advise on most of the time, and thus the language we need to be able to speak with our clients. 

Figure 2: Components of Digital Business Automation

What we came up with is what we call our Automation Alignment Matrix. It is a hybrid of the approach from MWD Advisors and IBM’s Reinventing Business With Automation whitepaper. We wanted a matrix which was much more prescriptive than IBM’s depiction, but less encompassing than the MWD Advisor approach.

Figure 3: Automation Alignment Matrix

Along the Y–axis, we measure the Uniqueness of Work being done, while the Volume of Work is measured along the X–axis. What we are attempting to do with this matrix is determine where an automation capability best fits into one of the four quadrants based on the type of work being done, with the type of work determined by its uniqueness and volume. There are other factors an organization should take into account, such as assessing the relationship between job performance and strategic value, which will help you determine the return on improved performance (ROIP). ROIP is a subject unto its own, which we may cover in another blog. For a deeper dive into ROIP, read Part 1 -> Step 2 of Reinventing Jobs by Ravin Jesuthasan and John Boudreau.  

Before we go too much further, some definitions seem appropriate. Low and High Volume (X-Axis), as well as Repetitive and Unique (Y-Axis), are self-explanatory. However, the Programmatic, Transactional, and Exploratory terms along the X-Axis are less self-explanatory. The definitions for Programmatic, Transactional, and Exploratory are from the MWD Advisor’s article mentioned earlier. These criteria were added to the X-Axis because we felt they added more depth to the matrix. Below are definitions for the three words needing more explanation (somewhat appropriately, the definitions for each of these get longer the less prescriptively the work can be defined up front): 

• Programmatic: Almost all features of the work can be prescribed and designed in detail. It’s possible for the work to be almost entirely automated. 
• Transactional: Many of the tasks and decisions involved, and most of the flow of work, can be prescribed and designed in advance. However, human discretion and expertise are required to carry out some tasks, as well as in deciding when, how and where work needs to be progressed. 
• Exploratory: 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. In exploratory work, the overall experience for both the work participants and the customer of the work is a set of possibilities being explored rather than a recipe being followed. 

Now that we have a framework defined, we can start to classify what type of automation will fit with the type of work being done. Not all work is created equal. Some work is a great fit for automation. Some work can be augmented by automation, and some work can’t be automated, but it can be enhanced with AI. Figure 4 is a representation of how different types of automation can be aligned with the type of work being done.  

In the following weeks, we will add blogs to this series explaining how each component of Digital Business Automation is mapped onto our Automation Alignment Matrix based on the type of work being done. This set of blogs will encompass Tasks, Workflow, Decisions, Content, Capture, and AI. At the end of this series, you should have a high–level understanding of how to align the right type of work with the right type of automation. 

Lately, we’ve been speaking with a lot of companies about what a Digital Business Automation (DBA) platform is, and how to best leverage the powerful capabilities offered. While many companies are comfortable with the technology aspect of DBA, we hear a lot of confusion related to what type of organizational structure and methodology to use with DBA. In the past, for both our customers and ourselves, it has been sufficient to say here is “the tool” you need, and this is the org structure and methodology you’ll need to get the most out of it. With more and more focus on digital automation, that has changed a great deal. Today we’re going to focus on what DBA means from an organization perspective. That is, what does it take to build a DBA practice within your organization?

First, let’s define Digital Business Automation. At its simplest, it is a platform which allows you to automate repetitive and mundane tasks, workflows, and rules so you are freed up to focus on more complex tasks requiring human interaction (See Free the Humans). It’s really about automating the mundane, so organizations have the freedom to be great. The platform components enable organizations to model processes, capture unstructured data, manage content, execute workflows, automate decisions and tasks, and have great User Interfaces for using and benefitting from these tools. Of course, we must have a touch of AI and Analytics included (<sarcasm> you can’t have anything without AI these days </sarcasm>). For this discussion, we’ll focus on the pillars of Modeling, Tasks, Workflow, Decisions, Content, and Capture.

See Digital Business Automation Overview video for more information.

Before we describe the Digital Business Automation organization, let’s revisit the past. For convenience, let’s focus on a BPM Workflow implementation. Typically, as a company matured in their process automation capability from doing single projects to doing programs, they would set up program governance which would consist of a few Practice Areas such as Support, Infrastructure, Process Strategy, and BPM Solution Delivery. However, what this did was create a biased effect where every project this organization reviewed had to fit into a Business Process Management Solution (BPMS, or Workflow). If it didn’t, they would typically make it fit. More importantly, any methodologies, reusable artifacts, and frameworks developed would be very specific to BPMS. In our experience, this effect extended across all pillars of Digital Business Automation and created silos. While within each pillar/silo some companies have good practices and methods, there isn’t visibility across these silos. In the example of Workflow, there may be great best practices and methodologies for how to implement whatever flavor of BPMS they have, but there is no relation to Decisions, Tasks, Content, etc. In other words, if you are in the silo, things are great, but if you are outside of the silo, it is very difficult to see in.

What this siloed approach creates, even if there are mature methodologies and best practices within the silos, which many companies do not have, is a lack of repeatability, reuse, and documented processes for automation. In one recent engagement, during two weeks of analysis, we found close to $1M in wasted work due to creating the same things over and over within the Workflow area. Imagine if we had spent more than just two weeks doing the analysis, not to mention the implications if we had quantified duplicated work/capabilities across ALL of the Digital Business Automation pillars (silos). If we look at this from the perspective of Salient’s Digital Business Automation Maturity Level framework, this type of siloed approach to grade out approximately as in Figure 3:

Figure 3: Siloed Digital Business Automation Maturity Level

A big part of fixing this siloed view is accomplished through organizational structure and methodology. We’ll focus on the organizational structure and leave the methodology piece for another day/blog. We’re also going to leave any details around infrastructure to another day, although Shared Infrastructure is a critical piece of your DBA org. What we propose is setting up DBA Strategy and Delivery practices, which will be part of a triumvirate, including DBA Shared Infrastructure, which will form DBA Oversight. These practices will be separate but equal, and interact frequently. Figure 4 represents a 20,000 foot view of the practice spheres.

Figure 4: DBA Oversight

The DBA strategy practice consists of Enterprise Architecture, Process Owners, and a focused role of DBA Process Analyst (focused because they are not only a process analyst, but also understand Digital Business Automation; maybe we should call them an Automation Analyst). The DBA Strategy practice is responsible for defining automation goals, setting the course for DBA initiatives, and defining strategy and long-term planning for DBA initiatives (all from a business perspective). The group will also advocate Digital Business Automation as a core competitive differentiator within the organization. Lastly, they are responsible for eliciting and tracking critical business KPIs and measuring the overall success of DBA initiatives across projects.

Within the DBA Delivery Practice, we have Solution Delivery, the Program Management team, Solution Architecture, and Quality Assurance. The Solution Delivery team represents all of the delivery teams for the technical components, or pillars, of DBA. That is, Workflow, Tasks, Decisions, Modeling, etc. As a group, the Delivery Practice is responsible for project deliverables, a scalable delivery model, hiring DBA talent, tactical best practices, reusable assets, and architecture design specific to projects.

We won’t delve into Shared Infrastructure here much since that is a moving target with companies having on-prem, cloud, and hybrid infrastructures which need to be taken into account. We will tackle this in a separate blog. Suffice to say, this sphere and team play a critical role in Digital Business Automation.

The way these overarching teams interact to provide governance and oversight will vary based on your organization, but what follows is a framework you can leverage to merge into your culture. Figure 5 shows how representatives from each of the core teams of DBA Governance can form an Oversight Committee. This Oversight Committee should consist of Delivery and Project Managers from the Delivery Practice, Process Analyst Managers and Enterprise Architects from the Strategy Practice, a DBA Infrastructure representative, and let’s not forget the Support organization. 

Figure 5:

To show how these teams would typically interact and provide oversight, let’s walk through a scenario. A business executive sponsors a project and asks the DBA Strategy team to take a look at it. In order to vet the process, the DBA Strategy team would form a Virtual Process Team which consists of one or more Analysts, Solution Architects, SMEs, and a Process Owner assuming we are focused on one process. If more than one process, there could be multiple process owners. Figure 6 is a representation of the Virtual Process Team.

Figure 6:

There are a couple of approaches we can take here. One approach is what is today called many different things, but is essentially Process Re-Engineering (Digital Transformation is just a modern version of Process Re-Engineering). This is a “let’s start from scratch” endeavor in which we incorporate Design Thinking to rebuild from the ground up to create a new and innovative process. However, that requires a separate blog or two, so we’ll stick with modifying existing processes and focusing on what parts can be automated. With this approach, we want to break a process down into its component tasks, determine which ones can be helped by automation, and then analyze what types of automation best fit the type of work. Figure 7 is one way to represent the different types of work and what component of automation might apply based on our Automation Alignment Matrix. Figure 8 is the Automation Alignment Matrix, which allows the DBA Strategy team to use a guided approach to what type of automation best fits the type of work.

Figure 7: Analyze process for type of work being done

Figure 8: Automation Alignment Matrix (just a representation; your situation could be different)

Once the DBA Strategy team has done their analysis, which should include cost-benefit analysis, they’ll either propose the project to the DBA Oversight Committee or discuss with the Project Sponsor (typically a business exec) why this project isn’t a great fit for Digital Business Automation. One thing to note here is this does not mean the business should not go out and do DBA on their own. It is quite possible the DBA Strategy team could say it isn’t a good fit but the main reason for that might be bandwidth or other projects having a higher cost-benefit return and thus this project isn’t a priority. This requires a different blog, but by no means should an organization avoid automation because their IT department can’t keep up. In fact, this might be a primary driver for why the way IT is doing automation needs to change. I digress…

Let’s assume the DBA Oversight Committee approves the project. We will then want to form a Virtual DBA team. Remember, we had our Virtual Process Team review this proposal earlier in the vetting process, so ideally we will want that same team to be part of the Virtual DBA Team we form for this effort. Continuity here is critical as the Virtual Process Team has already done some high-level analysis and thus are very familiar with the process and overall pain points. This continuity will help streamline the project and determine which resources from the DBA Delivery Practice -> Solution Delivery team are necessary. 

In Figure 8, we can see the Virtual Process team has been added to our Virtual DBA Team. Also, based on the analysis the Virtual Process team did with Salient’s Automation Alignment Matrix, we add to the Virtual DBA team RPA, Workflow, and Rules solution delivery experts because the analysis indicated these were the areas of automation needed. Naturally, we’ll need Solution Architecture, Project Management, and QA as part of the effort.

If we look back at our original picture of the DBA Org and Oversight Committee, we can see how this would flow. A Business Exec, or even an IT exec if IT is the target for automation, sponsors a project to the DBA Strategy Practice. They will vet the proposal to determine whether it is a good fit for Digital Business Automation. If the Strategy Practice believes it is a good fit, they will propose it to the Oversight Committee, who would then vote as to whether this project should be taken on, and when it can be taken on. Assuming approval, the project moves to the DBA Delivery Practice, which will then form a Virtual DBA Team which combine technical, analyst, and business resources to give the proposed solution the perfect balance.

Figure 9: Virtual DBA Team – Form based on the types of automation tools needed.

With this Digital Business Automation organization in place, or even as you iterate towards this type of organization (iterating towards this is the safer approach with better odds for success) you’ll see your organization’s DBA maturity start to greatly improve and increase your levels across the areas of ROI, DevOps, Quality and Compliance, and especially Reuse. Figure 10 illustrates what your organization could expect from a maturity perspective as you scale out your DBA Practice. The recommended approach is to start with making sure you have a dedicated team of DBA Analysts, then creating your DBA Strategy Practice, then pulling together the DBA Delivery Practice sphere, and then bringing this all together by having these areas work together in concert as a full DBA Practice. 

Figure 10: Healthy DBA Practice Maturity

This blog laid out a very high-level overview of one approach to a Digital Business Automation organization. You can leverage this information to create a well-balanced automation team based on the overall goals of the business, and more importantly, take an approach to automation which is holistic and matches the right type of automation with the right type of work. The devil is always in the details, so we’ll expand on many of these areas via follow-up blogs in the coming weeks and months.

Demystifying DBA

Author: Geoffrey Hamm, Sr. Automation Advisor

Over the past few years, IBM has consolidated several products to form one comprehensive Digital Business Automation (DBA) platform also known as Cloud Pak. As a child of the 90’s, it reminds me of when the Power Rangers joined forces to become “Megazord”. Often referred to as “greater than the sum of its parts,” this is not exactly true, as many of the contained offerings have functional overlap. A better takeaway from the platform push is that it alleviates the pressure to get the most out of any one product, which has historically led to bastardized solutions. This is extremely good news.

If you are a prospective or current user of the IBM Automation Platform for Digital Business (a common rearrangement of DBA), you have probably been hearing a lot of three letter acronyms like BAW, ODM, DPA, ECM, RPA, ICM, and you may be thinking WTF?

WTF = Why the frustration?

I am here to help demystify the DBA platform.

Let’s rewind the clock.

Enter DPA

Three Letter Acronym #1:

DPA = Digital Process Automation

DPA was the first run at consolidation.

DPA includes BAW, ODM and (depending on who you’re talking to) RPA. Fear not, all acronyms will be explained.

You may be keen to the fact that “process” is a more specific term than “business.” You may also be wondering if that means that DPA is more specific than DBA…

You’ll find out soon enough.

First, let’s bust some more acronyms…

Three Letter Acronym #2:

BAW = Business Automation Workflow

BAW is a tool used to model, automate, change, monitor and optimize core business processes to improve consistency across tasks and processes, increase productivity and straight-through processing.

BAW = BPM + ICM

BAW is the combination of Business Process Manager (BPM) and IBM Case Manager (ICM). Historically, BPM handled predictable, structured processes performed by clerical workers; whereas, ICM handled unpredictable, unstructured processes performed by knowledge workers. What we’ve learned from these products being partitioned is that they should not be partitioned. There is too much fluidity between structured and unstructured processes.

Three Letter Acronym #3:

ODM = Operational Decision Management

ODM is a tool used to capture, automate and manage business rules to encourage rapid adaptation to change, increase the consistency and auditability of decisions, and detect problem situations in real time.

This tool allows us to execute very sophisticated rule sets very quickly. Can you imagine trying to calculate airfare by hand with all the variables at play (distance, demand, time of the day, day of the week, season of the year, historical data, etc…)? Me neither. By the time you had an answer, it would already be irrelevant as so many of the aforementioned variables would have changed.

Three Letter Acronym #4:

RPA = Robotic Process Automation

RPA is a tool used to record and automate repetitive human tasks to automate mundane work, eliminate copy-and-paste and data entry errors, and free employee time to do higher-value work.

In essence, RPA emulates a human’s interactions with their operating system – The Phantom of the Opera…ting system. I’m sure I could come up with additional ghost-themed metaphors, but I’ll spare you for now.

This is the only tool on the platform that IBM has not acquired. IBM has a strong relationship with Automation Anywhere however, and Automation Anywhere plays very nice with its siblings in the DBA family.

And there you have it:

DPA = BAW + ODM + RPA.

So, we’re done? Not quite.

Enter ECM.

Three Letter Acronym #5:

ECM = Enterprise Content Management

ECM is a suite of tools used to provide highly secure and compliant management of most types of content, support instant access to content, connect content to digital business applications and help manage governance and compliance.

This suite contains several products including IBM FileNet, IBM Content Manager, IBM Content Collector, IBM Enterprise Records, IBM Content Classification and IBM Watson Explorer. All these products deal with content in some form or fashion.

Data Capture, non-acronymic, is another component which sits inside the DBA portfolio. Although it sits outside the ECM umbrella, it is tightly coupled – ingesting documents with ECM being the final destination.

The reality is that a lot of operations revolve around content (i.e. a document comes in and someone must process it, or a client requests a document that has to then be located or generated, etc…), thus ECM was included in the platform.

The problem is that DPA + ECM ≠ DPA

Enter DBA.

Three Letter Acronym #6:

DBA = Digital Business Automation

Let’s review the math.

DPA = BAW + ODM + RPA

DBA =DPA + ECM

Thus…

DBA = BAW + ODM + RPA +ECM

There are a few other offerings as well, but these are the four “pillars” of the IBM Digital Business Automation platform.

To add one additional layer of complexity, these acronymized pillars also have what I refer to as “street names”. Here’s a terminology conversion table to help make this all make sense:

Now the following graphic should make more sense. You’ll notice the four pillars with operational intelligence, machine learning, governance and a variety of deployment options underneath. Data Capture sits across the pillars as a means of ingesting documents. And across the entire platform exists a unified user interface – Navigator.

Here’s a full conversion chart for your reference. This includes a few products and competencies not discussed in this article, so expect more on these at a future date.

What it means is that you shouldn’t have to decide whether you need ODM more than BAW, or RPA more than ECM, or if RPA can work in lieu of BAW. The truth is that you need it all, and it depends on which aspect of your operations you are automating as to which product you use at that point in time.

To return to my world-class Power Ranger analogy from the introductory paragraph, you shouldn’t have to decide if you are going to use Megazord’s arms or legs, nor should you have to figure out how to make an arm act as a leg in certain situations. DBA is fully equipped with both “arms and legs,” so you can pick things up without compromising the speed at which you run.

With the IBM Digital Business Automation platform, you can automate all of your operations without compromise…

You just have to learn a few acronyms first.

Let’s Chat!

START YOUR Digital Business Automation JOURNEY TODAY

CONTACT SR. AUTOMATION ADVISOR, GEOFFREY HAMM HERE TO learn more