This week, host Jimmy A. Hewitt had the opportunity to sit down with one of the worlds leading decision-automation experts and Salient’s very own DJ Des Jardins!
This interview covers DJ’s background and how he got into the business rules space! We cover #ruleautomation, discuss industries, and use cases that are favored. We discuss what type of role within a company is best suited to bring in rule automation, how rule automation fits into the agenda of most companies’ strategy decks, and more!
Watch Episode 24 now!
Follow along with the episode now!
23+ years in the rules technology, business rules management space
Navy 6.5 Years
2000: Working at Versata
Worked with Blaze and implemented business rules on mainframe solutions
Move to iLog doing technical pre-sales until they were acquired by IBM
Did pre-sales at IBM
Moved into Product Management at IBM and pivoted to BPM side of the house
After some time passed, went back to do Product Management with the iLog product which became something else
then ODM moved into the partner world at IBM
Now with Salient Process for 6+ years now as Salients ODM practice lead
This type of role in the insurance world is seens as the biggest early Adopters and users for BRMS (Business rules management systems)
(Current date: April 2023)
Companies are looking to automate and make those decisions consistent
Business Rule Management Systems (BRMS) sole purpose is to make a decision. On transactional basis, you ask it a question, it gives you an answer. Business Rules are written in a Plain Language Syntax (No Hard Code), allowing non-programmers to understand exactly what the solution is doing.
For example: “I have this situation, this data, these claims, loan applications, etc… but I have questions I have to answer such as what is the risk score? Should I do this or that? What should I do next?”
Those are the kinds of decisions being made. (As mentioned above) They have the straight due processing approach we want to process electronically, but companies are really looking for the consistency and accuracy on top of that.
Even if you are hand-coding and automating the rules, the benefits of the BRMS isn’t there such as
“If you remember that all BRMS does is answer a question, and questions are answered throughout any solution… it’s in essence of anywhere you see an “if” condition- IF you have a condition, THEN you have an action. The goal is to look at a higher level and start to identify what the decision point are. If you can identify this- the complexity is simplified.”
Are you making a decision? Yes or no
What decision are you making? and then what is THAT decision?
Are you deciding risk score? Calculations? Evaluations? Etc.
Once you have the decision points identified, you can categorize, group or evaluate them and look at which would be a good candidate to be made into a decision service. The hardest one is better to do first and the easy ones will fall into place. You can start easy- it is the companies preference.
You can have one person playing many roles or all of the roles. Minimally, the roles you need are a
Have the developer work with the Subject Matter Expert (SME) to understand the questions being asked, then figure out what data you need to have coe in and out.
The ODM Developer will build the “Operational Framework” which is all the artifacts necessary to implement the services without the rules. It’s all the technical aspects that the individual need to have the skill set for.
Then build the rules on top of the framework, and as you evolve the rules, the framework could evolve as well.
“Three Tier Governance”
The goal is to have a framework that rule authors only need to do their work. They write rules, test rules and modify rules. Have them manage the day-to-day change activities without requiring heavy code on the operational side.
Need the same roles and can even have small individuals in these roles but even if you have 30-40 rule authors, once the company is stable, the developers maintain the infrastructure, framework and begin doing rule deployments daily because the organization and the volatility of the logic… you evolve into this.
Business Policy Analyst: They understand the business policies that go into the decisions / rules
Subject Matter Experts: Ideally someone who is willing to take the responsibility of using the system and make sure it works correctly.
More holistic implementations.
“I would say 90% of the business rules applications and solutions i’ve worked on had nothing to do with business processes. There was no business process solution automating behind the scenes.
What the industry needs to have is more holistic solution where we have those business processes managing the long-term activities, we have automation within that-determining what tasks can be done in an automated way, what tasks need to be managed by a human, ensuring the data gets to the human at the right time, right place, right order, etc. In addition, automating those decisions. Allowing humans to only deal with the escalations. Also allowing integrations of systems.
“I’ve always pictured the whole solution as something that covers not a technology platform or portfolio, but a holistic look at what you’re trying to solve. Every solution has a process involved. Every solution has a decision involved. Every solution has contextual data. Every solution has events, actions, activities. There is absolutely no reason why solutions can’t be built around holistically managing those problems/ requirements as a holistic solution.”
You always start with a decision. It doesn’t matter what solution is consuming it. If you have other solutions you’re putting into place such as business process or other platforms, you are still making decision. If you identify the decision points, you select your decision services and consume it within the old applications and then start to build off that. Aside from data, decisions is the root of everything.
Often times, the misconception is that our rules, concepts are too complicated for a BRMS. It’s complicated from a human perspective, not for the technology.
Its old code, its procedurally spread out and its uncomfortable to understand how the technology can find and exact the rules.
Instead of saying this is too complex, say “maybe I don’t know what they are exactly and where they are” and move to automate them. We’re not pulling up business rules, we are pulling out a decision. You work on a decision, by a decision basis, find a decision whether its complicated or simple, find a decision that’s being made and replicate that decision externally. You can do this by looking at old code, looking in manuals, asking the people that do the work, etc. Its natural for people to want to pull this information themselves and convert that into a system themselves but there’s tools out there that will do this for you and if you do it the way you think it should be done, you’re not doing it right. You will not get the benefits
Not everything is going to be a good fit for business rules. Some decisions are better left in other platforms like BAW but the key is to identify, which is which. You’ll often find that the hard ones you don’t want to do right now are the best fit. Identify the decision points, pick which ones are good for your BRMS and focus on the best ones for that.
Watch Episode 24 Now
If you have a topic idea, contact us today. We want our podcast to answer your questions, and if you have something that you want to hear, we would love to know. In addition, you can ask questions and get in touch with our Salient Process team.
At Salient Process, we understand the importance of comprehensive digital transformation. We work closely with each client and use a North Star methodology to align your procedures with overall business goals. Our expert team works hard to understand your unique needs, making a customized plan for success. With our Digital Business Automation solutions, you can move closer to your digital transformation goals.
