IBM Operational Decision Manager Reviews

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.

The most valuable feature is the deployment part because it is very easy to deploy.

After being developed and configured once on server, even any one from a non-technical background can easily deploy it and the rules will work.

The testing part for the rules is also very easy to use.

Doesn't matter if you coding experience or not it is very user-friendly.

Configuring it on the Tomcat site and on the client's cloud environment, we faced a lot of issues. After configuring it on the Tomcat side, getting it on the Unix server was an issue.

There are two issues that I am facing right now. The first is that the errors I get from time to time are not easy to debug or easy to understand. They are very vague because if a XOM file is missing or there is a deserialization problem, on the client's side I only get a 500 Internal Server Error. To learn where the problem is, I have to go on the Rule Execution Server and test it myself. The deserialization issue is very vague. The error messages should be more straightforward and easy to understand.

I would also like to see the installation part on a single disk only, instead of on three disks. In our local environment we are installing it on Windows, and for the client side we are installing it on a Linux server. For a new user or a new developer or a fresher, it was tricky to understand which disk should be installed first, even if they're labeled Disk 1, Disk 2, Disk 3. Configuration is kind of tricky for a new person. Right now we have to use Installation Manager. It should be like installing any other software.

Finally, it should also start supporting the NoSQL DB. Currently, It does not support NoSQL. I don't know if the newer version supports it, but as far as I know it doesn't. It would make the job easier. Right now the client had to buy a MySQL license, so they are maintaining a separate database for ODM. It should be kept on a single system. NoSQL DBs are better and it can be done.

We've been using it over two years.

In terms of stability, from time to time I get runtime errors for the deserialization issue for the XOM file. I get an error on the Rule Execution Server saying, "This XOM class cannot be deserialized. Please check if it is configured properly." I have to redeploy that part from my Rule Designer. That has happened twice over the course of the project. I think someone might have changed the XOM. Otherwise, it shouldn't have occurred. On the IBM site there is not too much written about the error.

UPDATE: Changed in configurations : Issue was later resolved. Stability is great.

We have complete control over how the system is configured, managed, and run.We are using about eight server systems. In terms of scalability, it's more like a plug-and-play. We can just keep on adding however many servers we would like to add.

There was a dedicated IBM guy and we contacted him about the XOM issue but we have yet to get a substantive response. He said that it is not in his domain to fix that error. He is from the installation part only. This issue was later resolved.

Keep your rules in Excel format and they will be much easier to use and configure. A rule priority or sequence should be kept in mind: Which rule should be executed first. This should be clear for both the person who is developing the rules and the businesspeople who are going to be using them.

While ODM is an excellent business rules engine that solves a wide variety of business needs, the installation,configuration and deployment configuratiosn can be more complex than it appears on the surface. And if your business rules are incorrectly configured, you can put yourself at a major disadvantage.

I think this process can be improved. 

Drools

We use it for a cable company in a contract with Comcast.

It makes things easier for us. Productivity-wise, it helps. It has also helped to reduce operating costs by about 20 percent. In terms of decision-making it has helped some users. It has helped improve business processes. But it hasn't totally helped our decision-making.

The management features, based on the server side, have worked for us. So far, the usability is great. It's also easy to set up.

I don't see a need for additional features. I like it just the way it is. 

It does the job.

I have called technical support once or twice and they fixed the problems. I don't have any issues with tech support.

The setup is straightforward.

We did it ourselves.

It was not a large cost. It was a one-time cost.

It works. I would recommend trying 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.

It is accurate and saves us time.

It is very easy to use. We have one person works on it, building our rules, and other people can jump in and help if they need to.

It helps in keeping things logical and all in one place.

I would like to have integration of the user interfaces, and they are putting them together in the next version of the solution. There used to be two separate interfaces. Now, they are merging them into one.

It is very stable.

It is incredbly scalable. It is very easy if we need to add more rules to it. 

It is fine if we need to add more applications to run through it. That is very easy to do.

The technical support is great. IBM provides whatever we need whenever we ask them.

The initial setup was complex. Somebody else set it up, though. I wasn't involved with that.

Upon initial set up, I would get some help directly from IBM. When you set it up, make sure it is set up properly in the first place.

We used our own people for the deployment.

The solution has reduced our operating costs.

For each change, it probably saves about three weeks of coding time for a programmer.

We made a lifetime purchase. We purchased it by number of PVUs for our stage and product environments.

We are really happy with it. It is easy to use.

We have integrated this solution with other solutions. It was very easy to do, once we had a base to work with.

It could help with compliance or governance issues. It just hasn't yet.

We hope to use it for automation projects in the future.

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.

First and foremost for features, what you get out-of-the box is the most valuable. There are other solutions out there on the market, and by far, ODM is the most complete. It gives you that out-of-the-box capability, is enterprise scale, and has a lot of the internal workings to handle the complex use cases that we find out there for making business decisions.

Implementing regulations and business policies: There is a lot of business logic there. That is exactly what the solution will target.

There is some promise of how decisions could take advantage of machine learning and artificial intelligence (AI). That has been slow to develop. It is still not clear where the market will take it, but that is something that I am looking forward to down the road.  Today we augment some ODM decisions with AI and with analytics, but I expect that in the next several years we will see much more growth in this area.

ODM has recently released support for Decision Modeling and Notation (DMN) models that can be authored and executed right within the product.  This too is an area that is in its early stages and I expect will mature quickly to an enterprise level.

ODM originally comes from the ILOG company. This product has been around for 35 years. It is the most robust, mature rule engine on the market. It is very stable.

It is best on the market!

I personally don't use the technical support often. Our team has been working with ODM for a long time so we don't typically leverage IBM technical support.

As a consultant, I have seen customers using many different solutions.  There are only a few products out there on the market that actually allow business users to manage business rules.  Most of the other products that compete with ODM are too IT-centric.  By far, our most successful customers use ODM for managing business logic.

Customers switch to ODM for two primary reasons.  They want their business users to own the business rules and/or they need super-fast performance. 

The initial setup has gotten much easier. IBM now offers containers that you can spin up very quickly. They also offer ODM as a SaaS offering, so you can just subscribe to the service, then it's up and running.

I have been working in this automation project space for a long time. We have a client who had a three-month ROI on this tool, just in additional sales, from sort of "the next best action" of what product that they should offer to their clients. ROI can be very quick.

It reduces operating costs because you are taking some of this work out of the high cost IT people, freeing them up to work on new initiatives and getting them out of maintenance mode. Now, the business people are the ones making business decisions on what needs to change. They are hands on making these changes.

IBM has offered ODM on Cloud for over three years now.  They have a really attractive pricing model that allows our customers to get started very quickly without the need to worry about hardware provisioning and software installation.

Out-of-the-box, you get more capabilities with ODM than any other rule product out there.

ODM is a proven solution. There is a lot of talk about Decision Model and Notation (DMN), making sort of this DMN flow chart format for making complex decisions. I would caution you that DMNs is still very young. My decision to make recommendations to clients around ODM is based on knowing the solution will work for our customers. Some of these other newer products out there are very immature. I always look at scalability, maintainability and the capability to handle real complex decisions.  When looking at other solutions, I always ask myself:  "Do I trust this product to make my most critical business decisions?"

It is enterprise scale and provides amazing performance. 

In a process or case, there is decision logic. Without this tool, the business logic oftentimes gets coded into those tools, and now, it's no longer accessible to the business. While it compliments business process management and case management, managing business logic is separate and abstracted away from those processes. However, the tool is definitely used in conjunction with them.

Getting started with ODM can be a bit difficult without a little expertise. Most of our rules team have been working with it for a long time. In the end, it's well worth the investment to learn it, because it is the most capable solution. For nontechnical users, it's very easy to use. It is really the technical side of things to get it set up where the investment starts upfront and the usability ends up being the best experience in the end.

We use ODM for credit evaluation, online.

It helps keep our business areas independent, because they can make decisions without IT. It also reduces costs, because we can make the decisions online, in seconds.

What I'm really interested in, what I'd really like to see with this technology, is artificial intelligence, RPA. How can that interface with ODM?

It's 100 percent stable.

In terms of scalability, we have some 2,000 rules. In the next year, we expect to increase that amount by ten percent. It gives us that kind of scalability.

I have used IBM technical support in Peru. It has been really good.

The installation was easy. ODM enabled us to make decisions with a GUI. My business areas designed their rules, and it was very good.

We purchased the solution directly through IBM.

We looked at a lot of vendors, many open-source products.

We would recommend this solution.

We went with this solution from IBM because IBM has a roadmap and because Watson is the best software for artificial intelligence. We expect that our company's efficiency will increase, given the roadmap: ODM, RPA, Watson, etc. And the scalability was also an important factor for us.

To automate business decisions and allow businesses to make smarter decisions faster with a moden business friendly Web Application, the users adore.

The business owns the rules and they're taken away from IT, so business doesn't need to ask IT to implement them, and IT doesn't need to implement them. So the business owns their decisions and their rules, and therefore, finally, they take proper ownership, and model and maintain them properly.

In terms of compliance and reporting, that's tricky because we are not using it in such a hard way. It's more a help for business to automate their decision-making. They are improving that and they are much, much, faster than before. Instead of having quarterly, or yearly cycles and changes, they have them, now, pretty much daily.

It's very business friendly and rock solid.

We manage business rules within this product and the benefit is that businesses can manage these rules themselves.

One area for improvement is master data integration. That should be more fluid. The others are hierarchical drop-down lists, and hierarchical master data. We have a few hundred others that I have on the list.

Every software has small glitches, but generally it's a rock solid product. It's proven, and that's what it should do. 

We are pushing it quite crazily and, currently, from the scaling, we don't see an issue. So it scales.

They're really, really good. We only have the problem of getting them the data that they need because they're basically supporting us from a black box perspective. But besides that, they work day and night to get our problems solved. We're impressed.

Initially, it's straightforward, but you then need to tune it to your needs. Like your own car, you tune it if you have many kids, or if you have just a mistress. You configure the same car slightly differently, depending how you evolve. And same with platforms. So, it starts in vanilla and then you get creative.

When looking for a vendor I want to have the confidence that they are competent and they have a proper team behind it, that they have a big team. So I know that in 10 years, the product will still be around, and we will not have to rebuild our solutions every two years because they change everything.

I give it an eight out of 10 overall. Software never gets a 10. They can still add a lot of things. There's a very good base, vanilla setup, but all the other things that are customer-specific, you need to add.

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.

By using ODM, we get rules to our applications, then we get those applications to go to market a lot faster. 

Get to the cloud.

ODM has probably been one of the more stable IBM products I have used.

Scalability is really good. We have it deployed on ODM, which comes on WebSphere Application Server. We have it on a cluster environment of two nodes, production and test. It is scalable as much as we need it, if needed. Two node is good for us right now. If we would ever need to scale higher than that, the scalability of WebSphere would allow us to do it. 

We have used IBM technical support with the product. The feedback has been that the support has been very helpful at times. We have had some issues here and there that they have had to dig into. However, for the most part, they have been helpful.  

The decision to purchase ODM was made before I was hired on with my current company.

It was one of the first IBM products that I had experience with installing. 

It has an easy installation and administration to use. If you read the knowledge center and do your research on the instructions needed, it is easy to follow. You just have to be prepared to gather the knowledge and know what needs to happen to get it installed. If you do your homework, there will be no issues. 

If you are looking for a good rule solution that is easy to implement if you do your homework, which also has good support, then I would say go for IBM ODM.

We are looking into using Decision Server Insights (DSI) within ODM going forward.

If our compliance department needed to have a better understanding of what rules were implemented, it would probably be easy just to pull them out of the one system, since they are not dispersed across multiple applications. Though, we have never had compliance ask for this type of information.

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.

The fact that I don't have to deal with business rules, and then our business partners deal with it. I'm a developer, so I don't have to deal with that kind of stuff. I just make the code, then our business people take care of the business side. It's a great split.

Merging. If merging could be just like SVN, that would help. It should be a lot simpler. That's the only thing I don't like about ODM, merging from our local computer up to the Decision Server. I feel like it could be a lot easier.

Also, extracting specific rules. We've had to do a lot of custom work on that. The testing, we've played a little bit with it, but we have our own testing methods. If it could be as simple as we have for our custom work, that would be great.

I think it's stable, but if they could beef it up a little bit for bigger businesses, that'd be great, because we have so much in there. We have products that we have to split up because they are too big for it to handle sometimes. But that's just in development, within ODM. Again, processing has been fine, but I wish things were a little bit beefier.

We haven't really had to worry about increasing the scalability on it. When our infrastructure was set up, it was set up to add on. So if we truly wanted to scale up our infrastructure, we could just plug in servers, push it out, add another Rule Execution Server, XU, and apply it to it.

Every time we implement an upgrade, we do have help from IBM with setting up the PMRs. We work with some of the ODM architects when we do it. It's been really nice, because they have been getting work done. They've been getting fixes back based on things that we've noticed, so that's been really great.

At the time, we were trying to use an IBM solution for testing, but it wasn't as easy as it could have been. Really, our rule authors, as we call them, we needed them to be able to just get them out on the fly. Set up a project and make it work just like we would our actual application, and then have it run those rules. That's how we needed it to be.

My top criteria for selecting a vendor start with, do people like it? There's got to be some reviews on these vendors, and there has to be some kind of reliability with them. And with the software they're bringing out, how is their testing going with hit? Do you know what their testing methods are? That's one of my favorite things to say. They say, "Oh yeah, we tried this out. Let us show you it working." But I don't want to see it in some perfect scenario. When they say, "Let us let you use it for a bit," I love that. I like getting my hands on things.

My shortlist was Microsoft. There are so many bugs. It's a little bit annoying. They've gotten a lot better, but I am always a little wary about using certain application suites with them. 

At this point, I would rate this solution a seven out of 10, because I see room for improvement. 

Regarding advice, it's great if you're going big. Just be careful about the merging.

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.

It's easy to build, easy to adopt for the business. Business can change those rules. I think IBM has done a good job in re-architecting the product with Decision Center as its centralized view, where the business can make changes to the rules dynamically. That's what I like most.

The initial set of features that I'd like to see are, for an IT guy like me to start building a rule, we end up using a lot of IT tools. But I think there should be more involvement by business. Business should be able to create those rules from scratch. I think Blueworks does it great. I think there should be a facility for business to really create rules from scratch. The only part for IT should be to make sure the platform is stable, the technology platform, but everything else, the business should be able to create those rules.

It is business-user friendly, but it still needs to be from scratch, from ODM.

The stability is good, because it's built based out of IBM WAS, WebSphere Application Server, which is a solid J2 platform that IBM has had forever. The platform is good. Its footprint is a little heavy. Other than that, the product works great.

It's scalable. More and more geographic regions were added to the requirements for what we did for Walmart.

We expanded both horizontally and vertically. So we can add more clusters onto the WAS, and you can still scale it up.

I have not been in touch with technical support in recent times. But I used to work with IBM vendors all along, throughout my career. Honest opinion, I think in the last few years, five or six years, I've seen a little bit of lag in the support. It's not as good as what we used to get in the past. I think IBM should improve in that area.

With my current organization, because we have so many repeatable processes, repeatable requirements, I strongly feel we need to have a centralized ODM solution. We have had discussions with my leads and my higher-ups. ODM is in line, it is first in line. Obviously this is my preferred ODM solution. And I would recommend it to my colleagues as well, definitely.

It is to drive our rules engine for our revenue cycle.

We are just signing the contract and migrating to it now.

Its ability to untangle hard coded rules and put them in a more manageable structure.

Its ability to use decision tables to codify the rules and manage them better.

We are still testing and figuring it out.

We have not contacted technical support yet.

We have a homegrown solution. We are switching because it is not scalable nor performing as well as we would like it to.

It will definitely improve the cash flow of our clients, thereby it will improve the cash flow to us.

I came in at the very end of the decision-making process and do not know who was evaluated.

Most important criteria when selecting a vendor: 

• Scalability
• The ability to migrate away from having developers be the only ones able to create rules. 
• The ability to free up our resources to look for other sources of rules which currently are not an effective aid.

Rules authoring and governance.

Very flexible for business users in terms of business rules authoring.

Designing orchestration.

For more than eight years, I have used version 7.5 onwards.

No.

No.

A six out of 10.

No. However, I have used other rules engines.

Little more costly than other business rules management system (BRMS) products.

JBoss Drools and FICO’s Blaze.

Although costly, it is a very strong product in the BRMS domain.