IBM Operational Decision Manager Reviews

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.

ODM is mainly used in banks to handle large numbers of transactions.

I've been working with this solution since 2012.

ODM's most valuable features are that it's easy to define and divide business rules, and it can handle very large numbers of transactions per second.

ODM could be improved with better integration with other platforms. In the next release, IBM should include integrated analysis tools, summary metrics, and a friendlier way to integrate with dashboards or columns.

ODM is very stable and has good uptime. 

Scalability was the main reason we chose ODM, as it can handle almost a magnitude more transactions per second than its competitors. 

IBM's technical support is good - they're good at communication and are really helpful.

The initial setup was straightforward as we got a lot of help from IBM and were able to hire people who were already trained in the product.

ODM's pricing could be more competitive as there are open-source business rules engines that are becoming standard, like Drooms from the Java Open Source Enterprise Suite, although ODM is a better product than those. 

If implementing ODM, I'd recommend finding a partner with experience who understands the responsibilities and functions this product should provide, which can ease the transition. I would give ODM a rating of nine out of ten.