IBM BPM Reviews

We use it for process or case management in the healthcare industry. We use it to make sure that, when a case moves between operators, that the right level of people approve the workflow. It causes the processes to pull the information back in, so we can redact the case appropriately.

When we started out it was a little painful, but as we adopted it to the healthcare industry practices that we have to follow, it has helped in faster development.

We don't use it with any other IBM products. We actually built our own processes for how applications behave, so we use the process engine piece of it to redirect the workflow appropriately. When a case or support ticket comes in to the customer service reps, we look at the information and, using the process engine, we figure out which process in the workflow we need to call to get the information back in. Then the customer service rep can use it to appropriately manage the case that they're looking at or investigating.

I'm not sure that it has improved our organization, per se, but the speed to market, delivery of our processes and rules that change constantly, it helps a lot with that.

Also, not having to build our own and customize it is another advantage.

In terms of impacting our ability to change or update our processes, we haven't gotten there yet. We are legally bound by what the rules are, and other issues, so there is only so much we can do, our hands are tied. But we are definitely looking at robotic process-automation, to see if that can help and solve some of our issues. We are going to be working with the IBM RPA team to see if any of those can be derived from the existing processes to benefit it. That is something we are looking at here.

From an architecture perspective, the thing that we like about it is the ease by which our development teams could pick the tool up. That was cool.

The Process Designer is good. We like how we can drag and drop and link the processes up, that works out great for us.

We also like the monitoring, support, and stability of the platform.

When we compare it, with respect to migration upgrades, we find it to be much faster and much cheaper than the other vendor. We have both products in-house, so we are actually evaluating from a price-comparison perspective, as well as from a development and skill-set-availability perspective, across the products, as well.

One of the things that we are looking at is cognitive learning. IBM has another product called IBM RPA, I think, which is doing some of that stuff. We would like to see more of that with respect to cognitive learning and AI put back into the process engine to help.

Process engines have been here for a long time now. When you look at IBM BPM it provides the same stability that most engines do today. I think it is more in terms of development time and the ease of learning it that helped us more.

It is not as heavy as a Pega workflow system which is customized and has a lot more things you can do with it, but we don't need that level of complexity.

We haven't had any issues yet in terms of scaling it out to our customer service reps. You never know, it depends on the complexity, what it's going to look like in the future.

It's cheaper than Pega, definitely.

I haven't personally talked with anybody yet in technical support. I don't think we've had a need to. From a design and consulting perspective we did reach out to IBM to get some help to improve our processes in terms of development; not the actual process engine though.

There is more stability in that team to deliver things faster, so that helps.

We used Pega. Pega can be used both as a workflow engine and a process engine. We have our own internally built process engine too, written in Java, but it's more customized to a certain issue and we are not able to scale it out. That's why we looked at Pega and IBM BPM.

When looking at vendors - we sell a health platform to our clients, the Blue Cross and Blue Shields of the world - and one of the things we look at is, when we sell a platform, how can we reduce the cost of the platform, to reduce healthcare costs at the end of the day. We keep on evaluating products based on the licensing cost and the cost to run it, the consulting rates for each product.

We look at the scalability and stability of the platform too. We also look at what other capabilities there are, the capabilities of the future, and that's one of the reasons we are going towards robotic process-automation, trying to automate some of these mundane tasks that people have to perform manually. Although it is process-oriented, it is still difficult to figure things out across multiple applications.

The initial set up was easy. The challenge was in adopting it into the release and deployment processes that we have in-house, what we have to follow for the healthcare industry. There was a little bit of a challenge trying to figure out how to take the process and put the appropriate release management processes in place to follow our auditing compliance.

We have ironed that out now and we are able to develop and showcase the product much faster when we compare it with something like Pega. Pega has a process engine that we use. Our development times are much faster in IBM BPM, as well as the pricing is even better than Pega.

We looked at Pega, it's very expensive in terms of licensing. We are now looking at Red Hat's implementation of the BPM tool to see, from a price point ratio, how it behaves as well. Red Hat has a business process engine, their JBoss BRMS does that, so we are evaluating it.

We do evaluate, over time, how we can reduce our internal cost to provide a better solution.

In terms of advice to a colleague who is looking this or a similar solution, I think it is based on the needs of the company, overall, in terms of the business capabilities, the business development, is it a stable platform. And at the end of the day it's the total cost of ownership which is the key. You always have to look at that from your company's perspective. IBM BPM might be the best tool out there, but if you don't have the appropriate training and funding it's going to be a challenge. That's true of any other tool too.

That's why we're evaluating Pega and IBM BPM. Our teams are liking BPM better because it's faster to set up and they have showcased two or three projects where they were able to do them in a three-month cycle, where it really should take them seven or eight months, and it would take more in Pega. So we see the benefits, but we need to constantly look at technologies because, in the market, things are evolving over time, and that's one of the reasons we are looking at automating some of the processes too.

We evaluate every three to six months, to make sure we are ahead of the curve and looking at what the market is bringing to the table to reduce the total cost of ownership. So something like robotic process-automation where, with cognitive learning, it can figure out some of the processes and improve them automatically, is something that we are looking into big-time.

Helped our organization move from paper work to automated work.

• Reach with Integration Adapters
• Support for adding custom Java code

• The product is extremely complex to use and administrate.
• It can definitely be improved in terms of performance and stability.
• Process versioning was tricky, not straightforward.

Under load, the server crashes and many of the applications become lost. You have to handle this manually. In some cases, we had to resubmit the applications from start.

Server crashes under heavy load.

Customer support is good.

The first level of tech support does not provide much assistance. You need the ticket to reach a high level to start to see results.

No previous solution.

Very complex. Too many steps need to be done at the database and server levels, and complex configurations. From what I see, a lot of these steps can be and should be automated.

Sometimes, after updates, the modules did not work and we had to remove the application and deploy as new.

Process Server is no more available than new products out there, but in general IBM has a high cost and complex setup.

My advice to others looking into implementing this product is "Don't."

• The process creation
• Task creation
• User management
• Task allocation
• Rich UI and third party integration

The above features have helped me to build a successful application.

It has reduced the time a human spends in completing the jobs using spreadsheets and other traditional methods.

There are a few areas, like triggering mechanisms, externally exposed variables, and changing its values, which need to be revisited, as they do not sometimes function properly. However, this is a rare scenario.

Seven years.

No, it is highly stable.

No.

I would give their technical support an eight and a half out of 10 as a rating.

No, I did not previously use a different solution.

The initial setup is quite simple and user-friendly to perform.

I am unclear about the pricing and licensing as I do not deal with such matters. I only develop things from the tool.

Not applicable to me.

If you are looking for a product which should be capable of handling SOA principles, third-party integration, and effective user management, I highly recommend this product for you.

• Workflow implementation
• It follows BPMN notation.
• Quick to automate workflows. Allows for quick design and build of the workflow.
• Strong integration capabilities in both Standard and Advanced version.
• In-built ECM capabilities as well.

It introduces process orchestration with adherence and process optimization into the organization. Also, it provides visibility and insight into the process within an organization.

• Development of user interfaces
• Load time (performance) of the user interfaces

I have used this solution for nine years.

• Product is pretty stable, if sized correctly with the right platform architecture.
• Even the version migrations have improved and simplified for IBM BPM 8.5.x.

No.

Ajax services are most important to me, but currently we've moved them more into status closed. This is because we are using the HL7 version of iBPM. Thus, the one thing that I love about them is that they make it easier to integrate with other systems, especially with the use of smaller files.

It's ability to hand over processes. There are stages of the process from one user to another, and also the ability of keeping a session. Because I'm in a financial institution, where you are originating an account for a customer and could possibly frustrate a customer. You have to keep the account's permissions process simple.

Previously, you find that 115 in the system would be for onboarding, and that was how to engage the customer's profile. Then, you have to engage with multiple other systems to actually pay that account.

The nice thing about the BPM is that it is able to hold all of those sessions to say, "Okay, this is one, two, three, then I take this process and hand it over to another system, which will also do some work, then once they are done they come back and then I pass on the information to another system."

So, the integration that the different systems use, it's what has been most valuable.

When you have to integrate files for enterprise applications. We call them ESIs. This requires a lot of work, because you have to first create the EF file and integration designer, which takes quite some time, before you can be able to consume a website.

I've been using it for two years now.

Yes, we did actually. When we were initially installing 8.5.7, it deleted the server. We encountered a lot of issues when we had to migrate processes in the old version to the new version. This was happened recently, because we only started with the 8.5.7 server this year around June.

It is quite a scalable product. On one of our projects, we are running something like 50,000 processes a day. We're able to actually handle that efficiently without a lot of hassle.

It doesn't require installation. The user doesn't have to install anything on their system. It's all in the update. So, that makes it easy to scale.

I'd have to say 10 out of 10. Because I have never called their tech support, but they always make sure they attend to whatever problems we face. Not sure that's why they attend to us only, quickly, or maybe just how their tech support team works, but from my experience, I would give them a 10 out of 10.

It wasn't complex. Putting an app on is quite easy.

No, they were the only option at that time. Also, in terms of keeping up with the industry, they're always bringing new updates and you get updates every two months. That was actually a major factor.

My advice for them would be to use the product for what it's intended for, and to not try to make it do anything rather than what it is intended for. Because there you will come across problems which you might not find the right software. Also, find people who are skilled in the product. Most of the time, when you come across problems, they were not caused by the product, but caused by the people using the product who are not very skilled in terms of using it.

It's mostly about the process designing and the additional features with IBM BPM, with the tester coach wherein you can interact with the interface while you're designing the process.

We do implementation for various clients. Most of the clients are BFSI clients, Banking and Financial Sector clients.

It's under performance, maybe the moving from one activity to other activity, or one process step to other process step takes awhile. It can be because of the database thing, so it's to do with the database processing. If the processing gets better, it would be more efficient.

Around three years.

It is a stable product, and there's quite a lot of support from IBM.

When you start implementing a new BPM in your organization, there's some questionnaires that have to be submit to IBM and IBM gives the hardware specs according to that. The performance and the load have to be taken by the system.

I would give them a seven out of 10. The organization that I'm associated with is an IBM partner, so we have priority support.

The initial is not complicated, and it's not easy; It's medium.

No, we were clear with what product we were going to go with based on our research.

When compared to other BPMs, it's very efficient for the developers to develop and deliver on time with an effective process.

Process Design, Integration Services (UCA), Event Management, Web Service Provision.

It has reduced the amount of code that we write in a process to achieve the required functionality. Also, the integration with our core product (UI interface) has improved and allowed flexibility for user assignment and management.

More features for user management and dynamic role change.

Three years.

Apart from the usual fixes (which any product encounters), generally the product works well in production.

Based on the sizing and hardware capability, we don't face any scalability issues.

The possibility to add Java code as embedded .jar, that increases the flexibility of the solution.

BPM products are there to optimize the business flows in mid to large organizations. IBM BPM does that pretty well. Currently we use it for the automation of virtual machine provisioning in private clouds.

• The user interface builder could be more powerful and easier to use.
• The real-time process reporting functionality is limited to human activities – there is no visibility over the system tasks.
• IBM BPM uses JavaScript as a programming language for the server-side. I don’t know why it’s not Java, as it’s more powerful and the JavaScript part is translated into Java anyway.
• Sending complex data from the user interfaces to the server side is not achieved easily.

Three years, constantly.

No, stability is good, even with hundreds of new process instances per day.

Scalability depends greatly on the application server, WebSphere Application Server in this case. I haven't encountered any issues so far.