IBM BPM Reviews

We have some developers and analytics providing the solution for customers. We use the solution for automation, credit processes, onboarding, and some HR processes. Our clients are international enterprise-sized banks.

The solution is deployed on-premises, but it's been on the cloud since 22nd February. It is rarely mixed. At most, there could be a cluster on the cloud and a data center.

The solution can be integrated with blockchain.

IBM BPM's most valuable features are its speed in implementing and providing any changes, its reusable processes and features, and its flexibility. The solution has a good interface that is upfront on the development part. IBM BPM has a lot of features that help developers with backend systems.

The initial setup can be tricky because IBM BPM is not based on a popular stack, and it's difficult to hire a developer for this product. It takes about three months to involve a new member of the team.

We've implemented IBM BPM for customers since 2011 or 2012. I have personally worked with IBM solutions for over 20 years.

I rate the solution's stability a nine or ten out of ten. It is very stable. But there are some exceptions, such as if you talk about using only one version. When migrating from one version to another new version, you can make some mistakes and face some difficulties, such as node capability and needing to rewrite code. When you use only one version without any migration between versions, it's very stable.

I rate the scalability a five out of ten because it is not quick to scale. My clients are enterprise-sized international businesses.

I rate the technical support a six or a seven out of ten. If you face a problem with the code, you may have to wait very long for a solution. Very often, you will be told to wait for another version.

Neutral

We currently use Camunda BPM. It is based on Java, a very popular stack for developers, and it is then easier to hire developers for the project. It's easier than for IBM products, where we must spend some time, up to three months, to involve a new member of the team.

I rate the initial setup a six to eight out of ten. It is not very easy to set up. If you have business analytics, there'll be some notifications, and if your new developer knows some technology stacks, it is not difficult.

The initial setup is not difficult, but it's not a stack commonly used by developers, which is a big minus because it is difficult to hire developers for this product.

I rate IBM BPM an eight out of ten.

We have taken the BPM route in BAW.

I don't know whether we started using all the features or not. There are many.

So far, it works well and we are satisfied with the product. 

It's got a good look and feel as compared to whether it is in a Case Manager or Case Foundation, which was there earlier.

It's simple to set up.

The solution is stable.

Technical support is good.

I can only speak from an end-user perspective. I don't know, from the development perspective, what would be improved. From a general improvement perspective, it's probably a little too early to judge as the implementation is still going on.

The pricing is a little bit high. It's gone up in cost.

The response time needs to be better. Every time when you click a link or a button or something, the response could be faster - although, I know it also depends on the network connectivity. However, I've noticed even when we are working on the office network with very good network connectivity, we still feel, a slowness. It could have responded much better or faster.

We've been using the solution for seven months. 

The stability has been good. We haven't dealt with bugs or glitches and it doesn't crash or freeze. It's reliable. 

We are in the implementation phase. We have done the basic things which are in place and now we are doing the enhancements. As we are doing the enhancements now, there might be various feasibility checks and so on. Then we would come to know whether the product is feasible to take care of our requirements. Only then, I would be able to comment on scalability.

From IBM, we get good support. There are no issues with that. We are satisfied with the level of support we get. 

We used to use IBM's Case Foundation before. From there, we have now moved to the BPM route.

The initial setup was pretty easy. There were not any complications involved in that.

We found the product to be on the higher side. We recently purchased it last year, and, when you purchase the whole product, about ten years back, that was a very reasonable amount. However, now, this time, we see that the amount could have been better - although we still went ahead and bought it. That said, it could have been better.

We pay for the solution annually.

We're a user and a customer. 

We're using something around version 20. I'm not sure of the exact version number.

From a system perspective, once we have something and we keep doing hundreds of enhancements on it, that's where sometimes the user experience might go for a hit in terms of ease. That said, if you are a new user and you have the requirements correctly captured, then starting might be easier. Yes. The tool will start functioning from day one, onwards, in a much better way. 

I'd rate it at a nine out of ten.

We use IBM BPM for brokerage operations transactions, and workflow and process automation for those transactions. We use it for straight workflow and process automation. We have some straight through processing (STP), but most of it is human intervention. Therefore, we will start a process, which will start by requiring some sort of human intervention step, like a review or approval, then it will post to a system of record afterwards.

It has performed very well. We have had it for almost eight years. We will be hitting over a million transactions a day by the end of the year, so it is pretty successful.

• Easy to use
• Easy to develop
• It is transparent to business users because it is mostly picture based modelling.
• Easy for people to understand what the application is doing.

Turnaround time: It is easy to take a requirement, put it in the code, and deploy it. 

We have used a lot of out-of-the-box reporting on the process performance metrics. We have been able to make suggested changes to staff for this role or streamlining by eliminate some activities where people were not requiring a lot of work in the first place.

Some performance stuff around tasks and indexing. We know that there are changes coming in this space.

A lot of the management stuff: It is a rather thick stack because you have to have WebSphere skills, IBM BPM skills, and an understanding of how the product runs on WebSphere. A lot of this will start to get a lot easier as they put it in containers, which will allow the platform to manage itself in some regards.

Performance in the development environment space. I know that they have been taking it off the desktop version and putting on the web, and it is not 100% yet.

A lot of the features of the product are old. It would be nice to see those updated. They are on the roadmap. Hopefully, they will get around to them at some point.

It wavers. We have some opportunities for improvement in this space, especially as we approach our target volume of a million transactions a day. It is tough, because it is not necessarily the product. It is more around the platform and infrastructure to support it, so the connectivity to the database, web sessions, and reverse proxies in front of that. Therefore, the whole environment plays into how the application performs.

It has been okay so far, knock on wood. We are in the middle of refreshing our topology right now. We are trying to figure out if there are potential advantages that we have not been able to look at before by orchestrating how we cluster and divide the deployment environment, so we will see what happens.

We started with some processes that were about five or six a day to our target processes, which will be about hundred of thousands a day. The big effort now is to taking models from MQ Workflow and putting those into BPM. Obviously, MQ Workflow has been decommissioned and is end-of-life (EOL) later this year. We had 45 or so applications on MQ Workflow and we have been moving those over to BPM. That has been most of the work right now. 

We log PMRs constantly and the technical support has been great about providing Level 3 support. We have had some direct interaction with Level 3 personnel who provide easy, quick answers that we did not know, then we can implement those changes right away. We have definitely been happy with their response time.

We did not have a BPM solution previously. 

The initial setup was very complex. This was back on IBM BPM 7.5, so they had just converted from calling it Lombardi to IBM BPM. It was new infrastructure for us. We had some security and infrastructure constraints unique to the product that we had to work in. We did not previously have a huge WebSphere or Linux presence. We had some custom code at the beginning, but we have mainly moved away from that, and are pretty much out-of-the-box IBM BPM at this point.

We used IBM WebSphere software services for the initial setup because it was a new platform for them. They had just acquired it from Lombardi and were excited about having a role model for themselves for setup. Also, it was brand new for us, so any help we could receive was appreciated.

We have definitely seen ROI. When we first kicked it off, we said it had to pay for itself within three years, and it did. That is one of the reasons we have been able to keep the platform around.

We evaluated two other BPM platforms and did a PoC with one of them. Then we decided on Lombardi, and they were bought. After that, we decided on IBM BPM.

We did a PoC with Pega and looked at Appian, but settled on IBM BPM.

We chose IBM BPM because of the management that comes with the product: The performance stuff out-of-the-box around how efficient is the process and how efficient are the people involved (or how inefficient). The ability to view these metrics out-of-the-box without having to do a lot of work on top of that. Everything is coupled together and comes as one solution.

It is more than just a new development tool for IT. You need a capability within IT to support it, run it on the right platform, and have the right developers to develop within it. It is somewhat of a unique skill set. It is not Java development nor web development, it is a hybrid of both. Most importantly, you need business partners who are process-oriented. Anyone can put processes in a line and call it a workflow, but if you have process engineers who can find eligible processes for management, this is really important. Your business partners should be willing to define metrics in the process and work on changing the process. Therefore, it is not a new development tool, but a whole methodology around managing business processes in the IT and the business side. It is a little more of an endeavor than just buying the product and saying, "I use IBM BPM now."

Most important criteria when selecting a vendor: Originally, it was ease of development and the model-based development environment. It was entirely drag and drop plus pictures, so business people could comprehend.

I'm an independent consultant. Most of my work involves designing and compiling RFPs for IT public sector projects or working as a solution architect for RFPs. This is my primary job, but I also freelance and work with two companies.

For me, the most important feature is the easy-to-use business process dashboard. It's simple to orchestrate business processes, and the interface is clean and intuitive. Once your workflow is designed on paper, it's easy for the business process manager to implement and follow it. Another IBM product that was good in the past is the IBM Case Manager. I haven't used it for three or four years, so I'm unsure if it's still available, but it was quite effective.

One downside is that changing intermediate steps after you've finalized your flow can be challenging. Also, the integration with identity management could be easier. It would be helpful to have role-based access functions, allowing for specific custom models associated with certain streamlines in the IBM dashboard. Also, a simpler way to integrate some notation with other middleware platforms would be beneficial.

Most support tickets can't be handled at the first level and must be escalated to the second level, which takes time. The first-level support should be more knowledgeable and able to provide immediate answers.

I have been working with the product for five years. 

I rate IBM BPM's stability a seven out of ten. 

I rate the solution's scalability a seven out of ten. 

IBM doesn't offer local support in Greece. We rely on global support. 

Neutral

One of the things IBM lacks is the ease of setup. It's not very straightforward and can be confusing, especially when you need to upgrade. I would rate it a four on a scale from one to ten, where ten is very easy, and one is very difficult.

The tool improves processes by 30 percent. 

The solution might be expensive, but I can't give you a precise number. In the market here, I've seen two main products for BPM: IBM BPM and Camunda. Camunda is very popular and open-source, so there's no direct comparison.

IBM BPM is suitable for companies that have at least 500 users. Be specific about your requirements and the business problems you're trying to solve. Framing the problem will help determine if IBM BPM fits your needs. There's no one-size-fits-all solution. Once you've accurately described your business problem, you can tell if IBM BPM or any other product is the right fit, especially with the help of an experienced architect or solution designer.

I rate the overall product a seven out of ten. 

We're using BPM in our policy area for when we deploy new rates. We're an insurance company. We change rates based on market trends, or analysis, or new vehicles in the market. We try to get those change requests in, process them, and get them back out so our rates are updated for market share.

We had been using a process that was very manually intensive. We use BPM to take that manual process and automate it from start to finish. When the product manager requests a change, it will go to the pricing analyst, they'll do their work and it's all organized and coordinated in sequence, so that they can make the right decisions at the right times for the process. And hopefully reduce the time that we get the rate revisions out to market.

We're not using it with Case Manager, it's just BPM exclusively at this point. In terms of workflow process, as I mentioned, the request comes in and it follows a sequence of events. The pricing analysts that work on these requests, they have a lot of decisions to make, a lot of documentation to look at based on state regulations or different product types. This helps them organize that and presents the information to them at the right step of the process, so they're not spending extra time searching through hundreds of pages of documentation to try to find what they need. It's all right there as they work through the process.

Right now we're about eight months in, and the processes are long. They can take multiple weeks, so we haven't had a chance to go through a number of those to realize the benefits. But just word of mouth, and talking to people using it, they're seeing value in more efficiency in the steps that they're working through, they have documentation presented to them. Word of mouth has been great, but we haven't actually seen the numbers yet because it's just been implemented recently.

It is having an impact on our ability to change or update our processes. There is information during the process that the analyst will look at, their procedures. We created a part of the application such that the business can change those procedures as needed, on a daily, weekly, monthly basis. As the reps go through the process, they don't necessarily know it's changing, they just know they have to refer to some documentation, and the business can keep that up to date. That's been a great way for them to make those changes quickly as they need to.

It's really helped our customers learn the process. Before you go into BPM you have to document the process. Working with the different groups that are involved with the process, there was good collaboration so they understand what the process is and how it can be most efficient, prior to adding the tool on top of it.

So, process analysis first and then applying the tooling, it's been working great.

I would like to see more inclusion of RPA technologies. If we have more manual processes, we can use robotic process automation and integrate that in with the solution. Other than that, it's meeting our needs with what the requirements were.

In production, it's great. We have about 60 or so users, so it's small. We are in the cloud. There was some learning early on in development of the application. We just had one, sometimes two, developers, and there were some things that we had to do in the cloud to allow for the performance. It was taking up memory and we didn't know it. We had to work with IBM support, create some scripts to clean up the environment on a weekly basis, so that we weren't loading up memory.

It was a little challenging early on because we had just started. We were having problems right away with just two developers, but we got it sorted out and support helped.

We haven't had an opportunity to scale it. From what I understand about the architecture, it's definitely scalable to the enterprise. But we haven't used it in that capacity yet.

We just have the one application and it has not been in production long enough to really see the ROI yet, in terms of scaling. But based on the project, cost benefit analysis early on, it was showing positive. But we're not there yet.

It's been good. They've been responsive. We've been able to escalate when we needed to. We haven't had any incidents in production. It was just, while we were developing a solution, working with it, there were some issues early on, and support was great.

No solution previously. We've been discussing BPM for a number of years, just looking for the right use case and the right time to do it.

When selecting a vendor, typically we look to see if we have strategic partners, strategic relationships with larger vendors, like IBM; if they have the product that meets the requirements. We tend to look at analyst information to say, "Okay, who are the players in this particular space?" We tend to go with that as a starting place, and go from there. If they're someone we're already doing business with, and we have a strategic relationship with them, that will be our first point of reference, and then look at the requirements, can they meet the requirements?

We went with IBM largely due to, from what I gather, the requirements, the technology and functionality, were very similar. And we weren't doing business with the other vendors, while IBM, we are.

It was straightforward from our perspective. It was in the cloud, they provisioned the instance for us. However, I think there were some things that we didn't know about that needed to be fixed, and those incidents happened early on. We were a little bit caught off guard. 

We thought there might have been a little more discussion early on about, "Hey, if you're doing this, set it up this way," or some best practices or some guidance that we didn't get. But we fixed the issues and were able to work through that. From that point on, it's been good.

We worked with IBM to implement. I think we implemented it at the right time. I don't think we needed to have started earlier. The business unit that's using it had some overarching projects to look at, in terms of efficiency and improving speed to market. As they were looking at different technologies or process improvements, one of the options was to try to clean up this process. In working with them and working with IT, we landed on using BPM for that. It was actually good timing for their overarching goals. They have other projects in flight that will work in parallel with this to hopefully reduce the time to market.

I think this solution is an eight out of 10. It has a strong place in the market. BPM is one of the leading tools, if not the best BPM solution out there. It has extensibility across the platform to allow you to do any number of things. It gives you scalability and functionality, breadth to handle just about anything you need to do.

Regarding advice, if you're not using a partner, use a partner, or use IBM to get some consulting services to help you get started. They have some quick-win programs that are designed to come in, they'll bring a developer in and they'll work with your developer to get you started. That's what we did and that worked really great. We got an understanding of the product, we got an understanding of how to deploy the product. And when we were done with that engagement, we were off and running. I would definitely say go that route. It works.

Our clients use IBM BPM for loan origination and for opening accounts.

The most valuable features include the workflow, ease of use, and the ease of configuration. 

The analysis reports could be much better.

I've been using this solution for a year and a half.

IBM BPM's stability has been good so far.

The solution is scalable because the licensing cost is per the number of cores. Our clients are medium-sized companies.

I would rate IBM BPM's technical support at ten on a scale from one to ten.

Positive

The initial setup is straightforward and easy. I would give it a nine out of ten.

The deployment can take one to two months depending on the company. We have a deployment team of four people including an engineer, an architect, a technical support person, and a project manager. For maintenance of the solution, we have two staff members.

Price wise, IBM BPM is cheaper than other similar solutions and has excellent pricing.

If you're considering IBM BPM, my advice would be to understand your environment so that you know your exact requirements and can get the most benefit from the solution.

I would recommend IBM BPM and rate it at ten on a scale from one to ten.

We use the solution for business management.

The solution can be deployed both on-prem and cloud.

The solution is a module and we can interface with consent and document management which is important.

The designer feature, compared to other solutions is easy to use.

The solution is an out-of-the-box solution.

The cost of the solution has room for improvement.

I have been using the solution for 15 years.

I give the stability an eight out of ten. The solution works especially well with Linux.

I give the scalability an eight out of ten.

The initial setup depends on if the solution is deployed on the cloud or on-prem. The cloud version is easy because we just have to deploy the containers. The on-prem setup requires a lot of work before we can even begin because we need to masterpiece all the layers from the operations system to the database, and the middleware at the front and back end. I give the initial setup an eight out of ten. The deployment takes a full business day.

An experienced person can do the complete deployment on their own however we usually use three people, one for the beginning, middle, and end.

I give the pricing an eight out of ten. The solution is a bit expensive.

I give the solution an eight out of ten.

IBM BPM is a good solution but we should always look at our business requirements. The solution is intended for medium and large businesses, so it is not recommended for small businesses.

A banking client is using IBM jBPM for Customer Due Diligence, and they are having user screens developed in Brazos. I think they are treating it like headless BPM, but it is not actually headless BPM. So, some of the screens and the navigation are from the old jBPM technology itself, and they have some of the customizations on top of that by using Brazos screens.

Initially, when it was developed eight or nine years back, it was really good because of the features and usability.

Setting it up is fairly easy. If somebody has knowledge of the system, he or she will be able to do it fairly quickly.

From the testing perspective and minor enhancements perspective, customization is something that is a little tedious as compared to new tools. In addition, various open-source tools that are available are not working with IBM BPM.

Some of the flows that are developed are end-to-end flows rather than modular flows. With a complex system, such as Customer Due Diligence, there are a lot of reviewers and profiles, and people need to log in and use the same flow again and again, which makes the maintenance of the tool difficult.

The security and testing side of things can be improved. If something can be done to make the latest tools and technologies available for doing the testing from the performance side and security side, it would add a lot of value. Currently, it is very difficult to put all of those tools on top of the closed infrastructure of IBM. Some of the new tools, such as Camunda, have solved this a little bit with the security scan that needs to be done in the DevSecOps pipeline that we are using nowadays.

IBM is known for stability and reliability.

From a scalability perspective, it is already being used as a very complex system, and it is working okay. The new solutions, such as Camunda, say that they are good from the scalability perspective, but it has not yet been proven, especially in the financial world. That's the reason we're rating Red Hat and IBM higher in this regard.

Initially, there was a lot of to-and-fro communication with the IBM team. Without them, it was not possible at all. Their support was good. 

Because it is very IBM-centric in terms of technology, getting the right people is very difficult. That's the reason why people go to the support team more for getting answers. This is something that is good in other offerings available in the market where the customization can be done very easily, resulting in fewer calls going to the support team. 

Their support is very good. People are good, and everything is good, but in this modern world, there should not be a need to go to the support most of the time.

Its deployment was good and easy, but the problem was that we were not able to get the people with the right skills. It is not like Java technology for which you get a lot of people with skills. It requires very specific skills, which was another challenge that the client was facing. That's why they asked us. 

We don't own the entire application. We have just done a small part of it. They are now looking at what needs to be done and how they can modernize it.

Licensing is managed by the client, but we know it is yearly.

Camunda is relatively cheaper. There is not much difference in pricing of IBM and PEGA. For large licensing, there are discounts as well.

We are currently checking out various BPM solutions and seeing how IBM BPM stands with respect to other BPM tools that are available. Red Hat is now IBM, and we found the Red Hat BPM to be a little bit more open source. So, the problem the client is getting may get resolved by Red Hat BPM. Our recommendation is Red Hat BPM and not Camunda, which is an okay solution, but it is a new kid in the market. From the robustness perspective, we are leaning towards Red Hat BPM, but the client has not taken a decision yet.

There are two types of BPM products available. One is the platform solution, and the other one is a little bit open-source kind of solution. Camunda is kind of open-source.

If you are looking for a good solution where you don't need to do multiple enhancements and there is a good troubleshooting and support team, you can definitely go ahead with this solution. If you are looking for a lot of customization after implementing a BPM suite, then I would recommend Red Hat BPM over IBM BPM. For example, in the financial industry, we have critical processes that keep on changing because of regulatory changes. For such cases, Red Hat BPM is more suitable.

I would rate IBM BPM a seven out of 10.