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.
