IBM BPM Reviews

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.

I used it in my previous company where we did a lot of work with banks, financial institutions, and accounting firms. We were primarily using it for automating business processes, but a lot of them were really custom applications that used the process engine for making things happen. We were using it in innovative ways to make that BPM process engine do lots of other things that I'm not sure it was really ever designed to do. There was a lot of financial stuff. There were financial calculations that would fire off a SQL process and then get the results back. 

I liked its robustness the most. It was a very robust platform in my experience. It seemed like a very stable and powerful tool for handling lots of concurrent users and hammering at the system. 

It is a really powerful tool, but its entry price is so high, which makes it a very exclusive club for who gets to use it. 

The thing that seemed to be the most intolerable was that you could put lots and lots of users on it, and it worked fine, but if you put lots and lots of developers on it, it sure seemed to have challenges. The biggest challenge was the development because of the Eclipse tool. It just seemed like irrespective of the development team that you put together, whether it had 10 or 50 people, you would end up having to reboot the development server throughout the day when you concurrently had lots of people hammering on the system. The development server just got sluggish. This was true for every project I was on. Once you got more than about five people working on the system at the same time, it would just get slower and slower during development work, and the only way to fix it was to reboot the server. It became just like a routine. Sometimes, we would reboot at lunch or dinner time, which is silly. After the cloud instances started rolling out, I never saw that again. That was probably the one big advantage of the cloud version. Instead of using an independent Eclipse-based process development tool, we moved to web-based process and design. The web-based tool definitely had greater performance than the Eclipse-based tool. I never got onto another project after that with 50 people, so I don't know how the performance is when you get a large team on it, but it definitely seems that the cloud design tool was a massive improvement.

I have been using this solution for a little over seven years.

It was very stable. 

It is a powerful system. It can scale to really big numbers in terms of the number of users. You can put lots and lots of users on it, and it works fine, but if you put lots and lots of developers on it, it seems to have challenges.

It was a development house, and we had 25 people using it, but now, because of COVID, they have cut back, and there are probably 14 or 15 people left.

There are different kinds of tech support. There is the free knowledge-based stuff, and they also have really good development support if you have a high-end contract. I have used all that, and it is pretty fine. Sometimes, we would find bugs, and they would send us a fix that would get rolled in with the next version. I don't like to be the one that uncovers real bugs, but it has happened.

Support was superior and absolutely wonderful if you could afford it. It is IBM, so if you're in that ecosystem, they expect you to have lots of money and be prepared to let it go.

My first exposure to BPM was with IBM BPM. I had never heard of it before I got the job.

Having used lots of software over my life, I would say this one is pretty much on the complex side. Before the cloud version, it was challenging to make sure you've got the right versions downloaded. They had so many different variants with different licensing agreements, and then the patching has to be done in a particular order. The installation has always felt like a homebrew scripting system rather than a really robust installer. It always felt like if you made one mistake, it might take you an hour to back out of it. It was not a very forgiving and intuitive installation.

I wish it was less expensive. I don't know why their pricing model is so high for a piece of software that could benefit so many. It just seems to me that they could have a lower cost, maybe with fewer features or whatever, but it should be possible to do a lower cost workflow software that uses the same interface and underlying engine but does not cost so much that you have to be a Fortune 50 company to buy it. It is annoying to me. There are a lot of solutions that IBM has that are really powerful but nobody can afford them. They know their business, but I still feel that there are a lot of customers who would benefit from this sort of thing. I don't know what this elitism is all about. I am sure they have people doing the money numbers, but it seems like you can make a lot more money by selling it to way more people for a little bit less.

When it first started, one of the things that were clunky about it was that it was ugly out of the box. It was not a very pretty program. There was a whole ecosystem of people who would do development on top of this IBM business tool, and everybody was coming out with their own toolkits to have a better UI application-wise. That was a real big problem. Towards the end, they bought up something called SPARK UI, and that toolset was significantly prettier and made the applications that you produce with BPM look a lot nicer. There are definitely some improvements there, and they are heading in the right direction.

In my previous organization, we had mostly moved to the cloud. Originally, I was doing server implementation, so we were running everything on AWS and EC2 instances. After that, we moved over to cloud-based stuff. I've been doing IT work for 25 years, and I've always been a get inside and figure out what's going on kind of guy. Personally, for troubleshooting, I don't like the extra layer of abstraction. I like being able to dig in and go right for the logs and see exactly what's happening. I like being able to see exactly what's going on performance-wise. The cloud instances felt a little further away, but on the other hand, I didn't really see any of the performance issues, so there wasn't a lot of troubleshooting to do. Maybe it's just me being old-fashioned, but I do prefer the ability to get in as far as I want to go into troubleshooting. BPM in itself was already running in a big Java instance on IBM, so it was already isolated in the operating system into its own Java Virtual Machine. There were already abstraction issues, but I did enjoy having more detailed access.

IBM has clearly invested a lot of money in making the product robust in developing it. At the same time, as an IT professional within the same career field, it is risky to be a single vendor ecosystem participant. It is really much wiser to have BPM development skills that would transfer to other platforms. I would say don't forget that there are other systems besides IBM BPM to fix automation and workflow challenges.

I would rate IBM BPM a seven of ten. It is really good and powerful, and you can do a lot with it, but its price is hard, and there are challenges using it.

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.

We use IBM BPM for banking transactions. 

The tool's workflow function is very strong. 

IBM BPM should become cloud-native. It should also add a cloud deployment feature. 

I have been using the product for ten years. 

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

I rate the tool's scalability an eight out of ten. My company has 1000 users. 

IBM BPM's support is good. 

The tool's deployment is complex. 

Integrators helped us with deployment. 

I rate the tool's pricing a seven out of ten. 

I'm a consultant. We are working for a consulting company, and we initiate solutions in IBM BPM at the moment, mostly for banks.

Overall, I'm satisfied with the product. It has a lot of capabilities and potential. 

This is technology, and there's always room for improvement. It would be better to have a single solution. Trying to have an overview in terms of this solution brings together the concepts of BPM processes, customer journeys, and an automation part for KPIs. All of this working together and coming up with a single solution with privacy is more commercial than anything else.

Because when you try and initiate things, we see that it's two different applications. But there's an effort to combine all of these applications and have an overview of internal processes. I believe they are making investments in this part, but they are probably delayed a bit.

Adding a control app or something easier in terms of maintaining the versioning will help. Make it easier to manage the patches so you can just do it and move on to the next one. Every time we tried to meet to do some upgrade of a version of the solution, it was a lot of work. Even minor upgrades always required a significant amount of work in intensities and trials.

From our side and our core customers, we didn't get any complaints.

Depending on the geographical area you're in, depending on the relevance of your customer, and if it's a big customer, the support goes very well. We don't have many complaints. If it's a smaller client in a smaller country, sometimes the support is delayed a bit, and we get some pushing from their side to make sure that we have a proper response.

We also have projects in our systems and projects with Comunda, and we are doing some parallelly. We also have some experience in using the BPMO methods and Software AG. It's not great, but for small things, it does the trick in terms of the licenses model. Sometimes depending on the situation, it becomes much more interesting for some of our clients.

The initial setup is kind of a pain when compared with other solutions like Comunda, which is more or less like plug-and-play and quite easy. The solution is quite quick in terms of IBM, and it's a bit more complex. Especially if you're talking about having a more enterprise environment, it becomes a bit complex. You have to configure a lot of additional components from that infrastructure to make sure it's running okay, and sometimes it becomes a bit complex.

It's expensive. All software is always extremely high. The manufacturing cost that we have compared to the selling cost, it's not like you're building a house or building a car. But putting that aside, considering that it's expensive, it's a lot of money. If you compare it with some of the other alternatives in the market, it's a similar price. For instance, if you compare it with Pegasystems, it's a similar price.

If you're talking about smaller companies or smaller clients, probably they're going for something more simple like Comunda or something else because it's much cheaper. Even the support becomes much cheaper than getting a full IBM BPM solution. 

If you're a very big company or a bank or don't want any headaches, you would probably prefer IBM. You know the old saying that no one has ever been fired for buying IBM. It's one of those things, and that rule still applies. 

I would advise potential users to get proper training and figure out the most suitable version that they need. Because in terms of internal versions and support, they need to be careful. Like all software, the latest versions always include some bugs. Older versions lack some support. You need to be careful about that. 

Have a proper solution architect that knows enough about the BPM system's ins and outs to make sure that you have proper internal support in terms of projects. Apart from that, try to build a close relationship with the vendor.

People who come from different technology backgrounds have some difficulty getting used to working with IBM products. If you compare it with other products, it's probably not as easygoing or as simple to implement as the rest. But after you get used to it, it works.

On a scale from one to ten, I would give IBM BPM an eight.

We currently use IBM BPM in our company to digitize platforms, to ensure that whatever we are currently doing in terms of manual operations, gets digitized. It means that anything a customer needs becomes an STP journey straight through processing instead of requiring any manual work. We chose IBM BPM because of that. I'm the head of enterprise platforms and we're a customer of IBM. 

It has a good user interface and I think the easy add option to build features with deployment in six to eight weeks is one of the key features. Also the add option, being an industry linker, simplifies things with the scale of production and all our production processes.

We place a lot of importance on security and one area they could make improvements in is to definitely increase the vulnerability and security patches to make it more robust and stable. As a financial institution we're always concerned about product and security vulnerabilities, it's an important parameter. The product could be more competitive in terms of cost. 

In a future release, I'd like to see more business related KPIs that can be measured from a digital transformation perspective. If they could build more on analytics reporting and help businesses to derive more benefits out of the solution that would be beneficial. I think they need to probably make it more business friendly and get more insights based on analytics.

Both stability and scalability are fine. I think we have been able to manage the monumental growth of the processes over the last three to four years. It has been pretty encouraging. It's been a success story for us. 

We get very good support from IBM on whatever issues and challenges we have. I think they are very quick to respond. We have a good, healthy relationship with IBM in this regard.

I'm pretty sure licensing is on the pricier side, but it depends on the use case and the benefits that you realize from your investment. There are different versions of the product; a standard edition and an advanced edition. Each is based on the number of PC users, CPU's that you license out, and the cost varies based on your instrumentation and the number of processes.

I have no serious complaints, it's basically the combination of pricing and the security vulnerability that are concerns. I think they also repackage a lot of their products within the new upgraded version of IBM BPM, a BAW - Business Automation Workflow. 

For anyone contemplating using this solution, it's important to study the entire landscape of your business operations. A solution needs to be chosen based on your business needs and there are multiple solutions available. If you're a smaller company, for example, there are other tools like Zing that have less scalability, but it's a reasonable alternative. If you're in the big league, then IBM BPM is the way to go forward.

The workflow design is the solution's most effective feature.

I suggest establishing a developer forum for better communication and issue resolution. Also, the administration panel could be improved for task management.

I have been working with IBM BPM for the last five years.

I rate the platform's stability a seven. 

We have around 200 IBM users in our organization. I rate the platform's scalability an eight. 

The initial setup process is easy. Although it took time to establish, we have automated many processes.

Following the SDLC can prolong the timeline, but utilizing a DevOps environment can speed up the deployment.

We design independent workflows using Business Process Diagrams (BPD). We identify different roles and entities in various departments and create dummy workflows to visualize these entities and processes.

A dedicated enterprise integration department uses IBM SOA services. We design various services for enterprise applications, including integration with content management systems like IBM FileNet.

Overall, I rate IBM BPM a nine out of ten. 

We have encountered different use cases with our clients. For example, in the financial, oil field, and automotive areas, we have used the solution for onboarding applications.

IBM BPM is equipped with all the functionalities which are needed for building BPM enterprise-level applications. The integration is very good by using the restore service. The UI has improved and it is now a lot better.

There needs to be better documentation for IBM BPM in a central place. There is not any standard documentation for each component available and has been a barrier for developers.

I have been using this solution for approximately nine years.

The IBM engine is very powerful, it is highly stable.

IBM BPM has been scalable our my experience.

The support needs to improve.

The initial setup was complex and can be made simpler by starting with better documentation.

I have evaluated Pega and Appian which have come to be major competitors for IBM in the market. IBM BPM site is lacking documentation and that is why customers are going to other solutions.

I would advise those wanting to use IBM BPM to have very experienced consultants at the time of implementation because it is essential to have the infrastructure properly configured. The solution is available on-premise and on the cloud, it is important to follow best practices with the developers, if they are ignored, then the infrastructure and applications will be in trouble. It is important to have good supervision from an architect, without one, IBM BPM will not be as useful as it could be.

I rate IBM BPM a six out of ten.