An integrated team and unified approach in Decision Automation plays a key role in ensuring that non-technical (non-IT/DEV) team members can automate and manage rule-based decisions.

More often than not, building and deploying the business decisions and rules by non-technical staff (e.g. domain experts, business analysts, business operation and etc.) starts at the beginning of the project, but as the project evolves, data changes, and requirements get updated, the ability of non-technical team members to model, test and execute decisions becomes very limited and its value becomes questionable.

What has gone wrong? Everyone was excited and committed! Non-technical team members could automate the decisions based on domain knowledge and rules. But what has changed over time making this far from optimal?

A Very Narrowed Focus

In many situations, all dependencies (i.e. data, system, processes…) around domain knowledge is abstracted out so much that the modeling domain knowledge (rules and decisions) has become too small, consequently, the value of software licensing, training of team members, administrating and coordinating between members to empower them (non-technical members outside IT) becomes questionable.

When companies are looking for ways to empower out-side-IT teams, they mostly think about business rules and business decisions only. Remember, business rules and decisions are not operating in a vacuum. When under pressure, IT teams are looking out for a solution to offload these activities, and have the mindset that everything else around it should be abstracted out by code in order to make it “easy for non-technical members” to model business decisions and rules.

The problem here is that there are a lot of those “other” things… and make the team members outside IT still heavily dependent on technical staff, defeating the original purpose (and wasting a lot of time in the process).

Book a Custom Demo

First or last name is too short





Dependencies and Bottlenecks

Empowering domain experts and operation team members to express their domain knowledge (i.e. modeling them) via a visually expressive and easy-to-understand language, and ensuring they can manage, change, and test their knowledge, is valuable to their team members and the organization as a whole.

However, two big obstacles make it inefficient:

  1. Suppose the domain knowledge model is to be activated so it can process inputs. In this case, it requires data and information that are not readily available or easily accessible by non-technical team members. In addition, the domain model and the required data evolve, reshape and change over time.
  2. If the activated models are not integrated deep into the systems and processes of organizations, they just act as stale and soon-to-be-outdated documentation at best. Therefore, operationalizing them and ensuring actions (automated or semi-automated) are taken based on their outcomes is the only way to adopt them within the organization, change behaviors and deliver business value.

The root cause of this is two fold: Firstly, looking at the problem in silos and secondly, considering individual contributors of business decisions and domain knowledge the members with limited ability to solve the problem end-to-end. For automated decision making to be truly effective and deliver on its promise, these two issues need to be addressed.

Illustration showing the steps and inputs of an automated decision process

Scaling Automation The Right Way

Part of this traditional way of thinking is due to the tooling and the other part is the team structure. In the next article I’m going to talk about how an integrated team and a unified end-to-end decision automation platform can address this issue to ensure that the non-technical team member can deliver the work end-to-end, and not just a seemingly small (yet critical for business) part of the project.

Last updated August 18th, 2023 at 02:28 pm, Published August 10th, 2023 at 02:28 pm