IBM BPM Reviews

We've been using BPM for most of the enrollment process, for banking, infrastructure, the financial side. So we've been using BPM to improve our business management process.

Performance so far has been pretty good. We've been using for almost five years now. A lot of auditing is in there, so we're pretty good with it.

We will be using the automation product, that's a new version, I think. These are new things we just learned about it. So we'll be discussing that more now.

The audit functionality.

IBM BPM has had an impact on our ability to change or update our processes in a good way. We have improved our process with it.

The business process management, where we can avoid lot of paperwork.

I'm more on the infrastructure side, not on the development side of it. So I'm not sure I can answer this. It's scalable right now from the infrastructure perspective. But I'm not sure of the development side of it. I'm not a developer.

The latest versions have been more stable. Initially, we were using older versions. With the latest version it is more stable.

It's pretty good. I would rate it eight or nine out of 10.

I'm not sure if we've seen ROI as a result of implementing BPM.

It's pretty good. We've been on calls with IBM. We have a technical account manager, so it's pretty good. I can almost rate it 10 out of 10. Good relationship.

Mainly for auditing purposes, and security concerns. That's why we started using the BPM tool.

When looking at vendors, we do a PoC with them to find out their support structure, etc.

I was not involved in the initial setup. It was done in-house.

Right now we're looking at BP3.

On the infrastructure side, I'd rate this a 10 out of 10.

I would recommend this solution, it's a pretty stable, good environment and platform for business process management. 

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.

I work for an insurance company and we use BPM to digitize two of our main claiming processes, to make them paperless.

We use it as a workflow platform and little more than that, because they are interconnected with other platforms of ours: our legacy systems, our customers, our partners, providers, etc. There are two BPM applications we developed with IBM, as a partner, to follow the bottlenecks and those kinds of things. So, I would say that it is more than a workflow software for us.

One of the most notable things is how you can develop use cases with the customers, internal customers, but directly within. The software process model that BPM supports is really exciting in that aspect. The natural interconnection with other IBM products is sure: WebSphere Portal, FileNet. We interconnect all of those.

We haven't discovered what features could be added, yet. We are still in the early phases, and it has more features than we are using now.

The people working on the front desk are having some problem with managing the documentation. For instance, they get a picture, and if the picture comes rotated 90 degrees, together with a picture that is not rotated, they have some problems dealing with that, technically. There are some minor aspects that on the usability side that are still lacking. That has to do with FileNet, too, I'm talking about the suite together.

One of the processes, the one that we developed first, is running okay. The other one is not, but I attribute that to the fact that we are still in the rollout process, and it's still in the early stages of development.

In terms of ROI through scaling, one of the processes we automatated with BPM is running smoothly with fewer people than before, and in fact the size of the demand has scaled, very notably. We haven't calculated it yet, but it's really returning on the investment.

I think it will meet our needs going forward. And they better make sure it does.

Support is good. They had to escalate internally, in order to get some more expert advice internally, but it was okay.

We've been helped by IBM staff, but there was no problem there. We used BPM on Cloud for development, testing, and pre-prod, and we used the on-premises for production, and everything is working properly.

We're looking at automating and digitizing our processes. There are two use cases. One is centralization of account opening. That has been out there for just over a year. 

The second process that we picked is the consumer loans process, the loan approval process, the whole loan application. The loan application process has just been automated, so it's been there for about two or three months.That is what has been put on the BPM tool.

So we use it primarily for managing the workflow of the loan application or of account opening for a new customer who walks into one of the branches.

So far, the tool is fantastic. The challenge has been for our people, I think the ability to realize that the tool is only as good as the thought that you put behind it. So what my team ended up doing was using the existing process and putting it on the tool. Based on that, now they've realized that using the tool means there is an opportunity to rethink the process itself, as well. That's what we're going to go through. But the tool itself, the experience was fantastic.

We're not using it in conjunction with any other IBM products. This is a standalone application that we're using.

In terms of the process automation and the workflow improvement, although, as I said earlier, we did not re-engineer the process, just the fact that there are lots of times when there is back-and-forth between the branch staff and the back office staff. So all of that, now that it is all automated on the workflow, has significantly reduced the turnaround time for the loan application. Previously, if it used to take anywhere between 10 to 12 days on average, now it takes between two to three days on average.

There is a component of this BPM pool - I can't recall the name. What it does is, it allows you to create various scenarios and then run them quickly, before actually putting them onto a tool. So I think that part of the tool is really fantastic, because that enables you to create scenarios, create simulations, before actually going out and putting it into the tool itself.

At this point, we're still going through the process of exploring the features that we have. I think we're far from the stage where we can talk about new features.

So far, we have not put huge volumes onto it, so it's been working fine. I am not sure how it will behave when we put really large volumes onto it.

We will be scaling it up, especially on the account opening side, because we do end up opening about a couple of a million accounts a year. So yes, we will be putting it to scale and we'll be seeing how it goes.

So far, we've been doing it in a couple of hundred branches, we wanted to do it in a controlled manner. But starting in about the second quarter this year is when we're going to put it to test on a mass scale and we'll see how it goes.

In terms of scaling, it's not like you can see the return on investment in hard dollar terms, but just the fact that from a customer experience perspective, if you can turn it around in two days instead of 10 days, by default, that should hopefully translate into more loans that we book, better customer experience, and better word out there in the market. Obviously, you can't put a dollar value to that itself.

The technical team was fully involved in the process, and it was a fantastic experience.

I wasn't involved in the setup personally, but my team members were involved in it. I have seen the tool itself. It wasn't that complex. I think it required a little bit of programming understanding, but by and large it was reasonably easy to use.

We worked directly with IBM itself. They're the ones we deal with. We are the largest client for IBM in Pakistan, so IBM works with us directly.

Regarding when we implemented it, we should have started a few years ago. It's automation, digitization. I think the earlier you do, the better it is.

I think it's worth looking at the IBM BPM solution. Certainly, when it comes in combination with the other tool that I talked about, where you can do a simulation, I think it's worth it. One should certainly look at it.

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.

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.