James Taylor is CEO of Decision Management Solutions (DMS), an IBM Business Partner, and the name of the company spells out the group’s focus. “We put decisions first. That's our mantra,” says James. “It’s essential if you want to use decision automation software that you are really clear about what the decision is and how it works.
James Taylor, CEO Decision Management Solutions
After a career as a writer and software consultant focused on analytics and business rules, James founded DMS in 2009 as an advisory service for decision management vendors, including IBM. Within a few years, he realized he preferred to help customers design and deploy decision management software. “We became an IBM Business Partner in 2012 and have continued to grow ever since,” he says.
In 2018, Ryan Trollip, an enterprise architect and seasoned practitioner, joined DMS as CTO, bringing decades of decision management experience with ILOG and IBM, on the product known today as Operational Decision Manager (ODM). Ryan joining allowed DMS to expanded and do bigger Automation projects using more of the IBM Business Automation portfolio (although still with a decisions focus). Under Ryan’s leadership, DMS has expanded into South Africa and India.
Ryan Trollip, CTO Decision Management Solutions
Recently, Ryan was featured on the July Automation Expose, discussing a Decision Management application built for a large North American bank. You can view the session here.
Q: Your company has the skills to use the entire Business Automation portfolio. Why focus on Decisions?
JT: It’s a different way of thinking about automation. For a lot of businesses, how they make decisions, what decisions they make, and when they make decisions really is the critical thing to know, before you start designing their processes and data access. A decision-centric point of view changes the way a company thinks about this stuff. If you make bad decisions, it doesn't really matter how efficient your processes are. We want to make sure people understand what the decision is, how it affects the rest of their business and their KPIs, how it drives the process design, and even how it affects the data that they need.
RT: There are some practical reasons why I think it works that way. Folks have been improving processes for a long time, and looking at everything as a process, where decisions have been somewhat ignored. Meaning, there is a lot of opportunity for business automation optimization and improvement when you start focusing on the decisions.
Q: Do you have a formal discovery process you take companies through to get started?
JT: We have several starting points. First, we have our “Decision Discovery” session or what we call a decision value analysis workshop. Where we sit down together and ask questions like, ‘These are the metrics that you say you want to improve. What decisions do you make to have an impact on those metrics? In which processes do those decisions reside? How could you improve them?' A lot of companies will tell us that they've got a process that's bogged down. When we look at it, we’ll point out that they haven’t automated the decision. It’s still manual. We had a client who told us they have 100% automation in their claims process. But in fact, what they meant was they had digitized every claim, but they still had people looking at claims and making decisions. So, they actually had 0% automation in their claims process. Additionally, we offer a “quick win” proof of value project. Over approximately 12 weeks, we’ll gather input, identify decisions, and deliver a Decision Management system with a dashboard, with business user enablement and continuous improvement all built in. And at the end of this exercise, they have a decision that can be implemented.
RT: The benefit of framing out a decision using decision modeling is we can drill down into the individual data elements that make the decision. This is done by either a data capture or integration of a database and in doing so we can track towards KPIs and what will actually impact the business and its performance.
Q: So, is Automation a process or a decision?
JT: These things are always complementary. It doesn't matter how efficiently I process claims if I pay the wrong claims. But there are other processes where it's more nuanced. There are some decisions that need to stay manual; in some scenarios, what you really need is an effective workflow to coordinate the right people to make the decision.
Q: Do you have a vertical specialty or are all decisions somewhat the same?
JT: There are clearly industries that are more decision-centric. If you think about a bank or insurance company, risk-based, fraud detection is central to their operations. Well-established companies make a lot more decisions than they think they do and their daily operations are driven by these decisions in ways that they're not always aware of. Anytime you've got a transaction or an interaction that's high volume or reasonably fast-paced and it's not immediately obvious what you should do, then you have a decision in there.
JT: Another example is to think about approvals. An approval is actually a decision. Most companies we talk to, if I asked them about their approval processes, they’d say they hate it. The reason they hate the approval process is because it's not actually a process, it's a decision but they continue to model it like it's a process. Their perception of the process will never change until you begin thinking about it like a decision.
Q: Do you have a Decision Modeling Tool?
RT: We do indeed. Early on, we realized that there’s a need, as with Blueworks Live for process, to frame out and visually capture all the requirements when working with subject matter experts. We developed DecisionsFirst™ Modeler and we are integrating that with ODM, ADS and DMOE (Decision Manager Open Edition – the recently added Red Hat product) so we can move even faster from modeling to building.
JT: We’re also using IBM’s Process Mining tool. It doesn't just do process models -it also produces decision model fragments . We can bring those into DecisionsFirst™ Modeler and then you can add expertise to it. You may not find a complete model, but you're going to find thresholds and pieces of what the decision making is captured in the logs. And then you can roll up the decision, deploy it and often times, you can remove many steps in your process because you have automated the decision.
Q: Does the Modeling Tool reveal surprises for the customer?
JT: It's been very interesting. We have a client doing a large migration and they are using DecisionsFirst™ Modeler as a reference guide. They’ve thrown out all of their requirements documents, retired the Word docs and the PowerPoints and so when the QA team finds a problem, they’ll look at the decision model and say “The decision model says it should do X and it’s doing Y, therefore there’s a problem.” This is truly exciting to see because it means everybody from the business experts through to the implementation team and the QA team are all referring back to the decision model as the Big Picture. That’s what they should be doing and that has been truly transformative for many of our clients.