IBM Operational Decision Manager Reviews

The primary use case is being able to expose business logic to non-technical users. This logic is traditionally hidden within code. ODM exposes the logic out to the business users for them to be able to manage it over time without IT involvement.

I work with many customers across industries such as healthcare, insurance, finance, manufacturing and others.  In every industry there are business decisions that involve complex logic.  My customers are enabled to have their business teams manage this logic and to change their business rules on demand without IT involvement.  

As an implementer of IBM Operational Decision Manager, I have helped many customers improve their organization by leveraging ODM.

Operational Decision Management is a decision management solution. By the nature of it, it is helping our customer manage decisions.

For my clients, ODM gives them the flexibility to modify their decisions without the three-month or the six-month IT cycle.  The reality is that business decisions need to change at a much faster pace than what IT teams have been able to deliver.  By enabling the business users (business owners) the ability to manage these rules, we achieve two primary things:

1. Business policy can change much faster to accommodate market changes, regulation changes, competition, fraud, or what ever other conditions drive the change.
2. Provides IT departments with agility.  By offloading the maintenance of this business logic from IT, they are now available to work on providing new capabilities to the business.

For clients that have embraced ODM in this model, it has been a win-win to both the business and IT teams.

Objective: The primary use case is being able to expose business logic to
non-technical users. This logic is traditionally hidden within code. ODM
exposes the logic out to the business users for them to be able to
manage it over time without IT involvement.

Before ODM, all the rules were configured on legacy
systems we're transforming all this into a new set of technologies such
as REST microservices, cassandra and with IBM ODM so that Business Users will be able to easily change the rules.

Deployment is done on the client-side only. Business User can update rules through UI

I have used it for few projects in which number of business logic rules varied from the 70  to about 1,800 rules.

There is an increase in productivity, agility and responsiveness because after it is configured once in the environment, Business User can deploy the rules and configuring the rules and making the changes by themselves. Deployment failures have happened very few times. (So far, twice only). Only then do we get a call: "We are experiencing issues." So productivity, being on the developer side has improved because once I have configured the rules, I don't have to worry about them. I have time to work on other things. The Business User is able to keep changing the rules and it is very easy for them. The client is very happy.The
result is a step toward creating a more modern infrastructure, to evolving business
needs.

Apart from the cost savings, efficiency has also increased. I never thought we would be able to develop that amount of change, it is now near real-time; being from the It used to be a very time-consuming process.

Now, As soon as Business User deploys a rule, well... it gets deployed.

There's more, they can even use an Excel sheet for input for updating the rules.

Our use case is that our business side has to make rules to take care of all the files that we process. Honestly, we do the coding side, I'm the developer on the site, and then the rule authors are the ones who create all the rules.

We have a lot of files that we process throughout the day. We're talking about 32,000 records per second, and it has been holding up really well. We have certain projects within ODM that are gigantic. They can get slowed down sometimes, but we're the only ones - I've looked around - we're the only ones that use that much; it can get slow editing. But when it comes to actually processing it in our production environment, we process things really quickly.

There are absolutely benefits to managing business rules with IBM ODM instead of hard coding them into our applications. They can change things on the fly and they don't have to deal with us in IT. If there's something wrong, obviously we'll come in and we'll help. But, on a day-to-day basis, after we've already implemented everything we need to, they can make changes on the fly. It's really enhanced our close dates, they have shrunk, because if something happens and they need to change up the rules, they don't have to mess around with us.

It used to take about 30 days to close at the end of the month, but now I think it's around six or seven days. Everything goes pretty smoothly after that, so that's been really beneficial.

In terms of the effects of allowing business users to update business rules instead of IT, no one is going to understand business better than business people. I've learned that at Nationwide very quickly. And no one is going to understand IT better than developers. So we keep our side of the fence, we keep it nice and pretty, and they keep their side of the fence nice and pretty. The fact is, we need each other. I need business, because how is IT going to make money without them? And how is business going to make good money without using IT efficiently? And that's ODM.

We do have a governance model, but it's a little bit difficult for me to talk about whether ODM has influenced time spent on compliance and reporting, because I don't have to deal with that.

As for Decision Server Insights, we don't currently have it.

We use ODM to set complex business rules. For instance, we deploy this solution for most of our banking customers because there are frequent changes in the policies and business rules. These are complex to manage for enterprise applications. 

ODM provides an efficient, comprehensive way to manage all the applications. Regardless of the BPM tool we are using, we choose ODM because it's flexible.

The only thing we have trouble with is integrating IBM ODM with the cloud. The product is on-prem, and we need to migrate the rules to the cloud. It's a hectic process. 

This was primarily to enable rules. I used it before, when I worked with Walmart, so not with my current employer, but the previous company that I worked for, Walmart Humana. The classic use case for Walmart was during Thanksgiving. Thanksgiving is a time when Walmart has huge sales and, at the same time, the most returns the next day. The rules should be competent enough so that business can apply those rules runtime, dynamically, without much involvement from IT. So IT just creates rules to apply discounts, initial discounts, and business has the ability to apply those discounts, change those discounts, dynamically. So that's one of the use cases.

The second use case that we did at Walmart was returns. So, you buy some stuff during Thanksgiving in one store, then you go to the next state and return it in the next state. So the tax rules change a lot. All those rules have been built in ODM. That was a classic example that we did in ODM. That's my first experience working with ODM as well.

The second one was with Humana. Humana is premium Medicare claims processing. There, we implemented ODM on mainframes, AS400. That's the first time I did work on AS400 and implemented ODM on them. There is a huge claims adjudication process that goes on within Humana. Most of the claims processing rules were done in ODM.

Hard coding was always a problem, because developers come and go, the teams come and go, the maintenance is always a challenge. You had to document those rules somewhere. If you work as a part of a specific solution, you have to document and maintain those changes every time you do. 

But with ODM as a centralized rules engine, it's easy to track. You can version the rules in the ODM engine itself. It's always better to decentralize the rules. If your organization doesn't have an option to go with ODM, I would still do modular coding, keep those rules separate, and then plug them into a future ODM implementation, or any other rules engine.

In terms of the effects of allowing business users to update business rules instead of IT, the name indicates business rules are "business rules." So business should own those rules. IT should should simply enable deploying the initial set of rules, and then let business maintain those rules, unless the core datasets change. That would involve IT in the business rules. But once we set the platform for the basic rules, the business should be able to apply their changes periodically.

IBM ODM has definitely reduced the backlog for IT in our case.

In terms of the solution influencing time spent on compliance and reporting, the work I did was mostly internal, we were not reaching out to any external. All the rules, the state tax calculations, they're all internal. So I didn't have an issue with regulations and compliance issues with ODM as such.

We've used Decision Server Insights within IBM ODM, and it's context-based. Every rule has its own business use case, so you know what context it really comes from. When you build a rule, you should know it's lifecycle, how you harvest the rules. You have business requirements, you come up with the rule harvest backlog, so you know each context. That is your driver to start building the context for each of those rules.

We use the solution to resolve complex business rules for our customers.

The solution is robust, scalable, and easy to maintain. We can also implement complex business rules using it.

ODM tell us if customers are allowed to purchase specific tickets on our carrier.

It is a lot easier to make decisions using this solution. That is what it does.

It is a really good product.

It is used by business users in our organization, who are very happy with it. They can make changes on it very easily.

It has benefited our organization by having less coding changes. Thus, we save time and don't have to hire as many people.

It is way quicker to make changes and bring them to production.

Being rules, the solutions has improved business processes and case management in our organization.

We use ODM for rules management for many of our systems to manage rules for business coming in. We also use it to manage rules for our BPM solutions.

The effects of allowing business users to update business rules instead of IT are business users have a closer relationship with what rules they need and are able to make those rules a lot quicker in the tools that ODM provides than if an IT person had to do it, and do it in code, requiring compiling code and deploying it. 

The solution has reduced the backlog for IT.