IBM BPM Reviews

 It is perferct if you have to develop complex apps without much coding (only java script). It is also good if you don't have much IT resurces in your company and woudl like to involve business analysts in process of developing apps. My opinion is that no it stuff can do about 50% of all developers work.

If you have a company that doesn't like to have everything ready out of the box and likes the capability of customizing a solution, you'll probably have a problem with this solution. You will need to do customizations on process portal, on your BPM applications ...

If you want to use IBM BPM, you will have to invest a lot of money for licenses and you need to learn that there are limitations in developing applications. You cannot create anything you want. You need to follow all the rules that IBM BPM requires.

For example: you cannot implement modern programming techniques (OOP), microservise architecture. You have services, you have a graphical tool for creating solutions, however, you cannot use this part of the code in other apps freely if you don't use toolkits and it can be sometimes very tricky. 

There are some things that the solution needs to improve upon from a developer's perspective. Software developers that use the eclipse process designer in older versions of BPM have had issues. The eclipse process designer and web process designer are quite different. With a web process designer, they cannot use IntelliSense during the coding in JavaScript. They cannot use some functionalities that weere in previous versions.

From the client's perspective, there are problems with licensing. It is complex especially when you need to do upgrade from old to new version. You will  need to use VPC instead of PVU per core and it is confusing. 

In case we are talking about cloud pack for automation it is good idea and it shoud be the future of automation of business processes but it is not ready yet. There are some functionalities that are missing ( for exampe sql services).I epxect that it will be solved soon.

I've been using the solution for more than ten years. I started with the very old versions, with BPEL processes and then swich to BPMN.

The solution is extremely stable. IBM is a reliable product. There aren't issues with bugs or glitches. It doesn't crash or freeze.

The solution can scale well. It's already quite sizeable and it's designed for larger organizations.

We actually give technical support to our clients directly.

I do have some technical support experience with some of IBM's technical support team, especially in relation to the setup, installation, and upgrade. I needed their help during installation and the response was okay. I'd say that I am satisfied with the level of support.

I am using also Camunda. It is an open-source BPM and I can make a parallel between these two tools. Therefore, if you want to create new apps and you have experiance software developers and have resources, and you don't wish to pay licences then it will be better for you to create a business process apps using open-source.  If you woudl like to create your services and your UI in some external tools, like Java. .NET, Angular, .. it is possible in camunda and it is not easy to achive in IBM BPM. On other hand if you don't have IT resources and you woud like to create apps faster then use IBM BPM.

The solution is complex to set up. However, you expect this going in. It is a huge application. It is running on a WebSphere Application Server. The WebSphere Application Server is an application server, and therefore, you need to set up this application server first and then to set up the BPM solution. After that, you need to create profiles and so on. There are multiple and sizable parts to the implementation that have some very problematic steps. On top of that, if some error is happening with these steps, we will have a problem. 

On the other hand, you really have a huge and powerful tool at the end. Therefore, you cannot expect the tool will have a simple setup or simple installation and to have all this functionality that you get with IBM BPM, especially with IBM Business Automation Workflow that you ultimately have.

Basically, for first installation and customization of one small dev, test and prod environment  you will not need more than a week.

If you have old version of BPM and olready finished some appps, and you need to upgrade it, then it is a bit more complex, due to the fact that you will probably have problems with the application if these applications are developed in an older version of BPM. Instead of only upgrading software, you will need to convert the application and sometimes it could need some time.

IBM BPM is not for every company. This is a solution is for a company that has at least 500 people and more employees. I don't expect a company with only 100 people to invest a half-million dollars into the licensing and the same in the services. A company like that should look into other open-source options.

We're just customers. We are not partners. We don't have any business relationship with IBM.

I started with the very old versions, with only BPEL processes. It was also BPM, however, I was using BPEL processes

Right now, for the latest client, we are using the business automation workflow 19.0.0.3.

Our clients are mostly in the banking industry, and therefore we don't really deal with the cloud versions.

IBM is preparing some new tools specific only for the banking industry and for the cloud. I don't much about it but I'm sure that it will be presented soon.

Basically, if you company is large, has problem with IT resources, need to rapidly change business processes and to fast create new apps IBM BPM will do your job.

I'd rate the solution eight out of ten. They can still improve their software. They have some parts missing and I'm expecting that these parts will be upgraded in the future. It is not a full 10 now, as there are somethings that they need to improve on.

A good portion of our customers are in the financial services industry, so back office processing related to financial services.

The main benefits would be getting previously undocumented processes under control, improving efficiency, eliminating redundant work, and a few of them being able to achieve some sort of compliance requirement.

Our customers use the solution as a workflow platform to manage their processes. They typically model processes with human and system activities. Then, they use the workflow engine to coordinate those activities making sure work progresses, providing visibility metrics and tracking.

With a regional bank, they used it to update some of their back-end processes for their credit division. It definitely enabled them to change their processes and become more efficient.

We have used it in conjunction with operational decision manager, in several cases.

• Visualizing the process.
• Quickly build a solution.

Better integration with other products in the automation suite; easier to integrate with IBM's Operational Decision Manager and content management system.

It is stable.

Scalability is very good provided you bear it in mind during implementation phase. It's possible to do bad things that will affect you later with scalability.

The initial setup is fairly complex. Luckily, we have a few people in our company that know how to do it. It is just a question of having the right resources.

We implemented the solution at the right time for our company and customers.

Our customers do see ROI. They'll identify some particularly painful or uncoordinated processes to start with, then build out from there, picking off low hanging fruit.

We are purely IBM. However, we do run into Pega BPM when we are evaluating BPM solutions.

I would recommend IBM BPM.

It comes down to the speed of implementation: How fast can we build something which our customers can use in their business and run with.

Our customers use it as a workflow management platform for processes. We have a wide range of customers in terms of the types of processes. We've worked with a couple of the very large accounting firms on, for example, tax calculations for commercial clients. Think of it as TurboTax, but for commercial customers.

We also have onboarding use cases - every BPM product out there just supports onboarding. We have several of those types of use cases as well.

The vision of what BPM can bring to our clients to be able to manage workflow quickly, efficiently, and to get visibility, that's what the IBM suite provides us.

Agility is the key. It gives our customers a faster way to be able to implement processes, get ownership of task, visibility into a process. The ability to modify that process, optimize that process over time, is probably the biggest benefit that they get from the software.

It gives us, as a partner, a lot of options for building on additional capabilities that we see customers asking for time and time again. It's a very open model for adding in toolkits or functionality on top of the overall BPM platform.

BPM has always had this challenge: It had this promise to enable non-technical users, business people. That is an area where we, as a business partner, and other business partners, continue to build new tools that sit on top of BPM, to push that level of engagement further and further out to the business side. That's an area that still needs to be improved.

Also, we would like to see integration with artificial intelligence, machine learning-type of technical capabilities. Right now, there are a lot Watson libraries out there. Building those integrations more, out-of-the-box, from IBM would be a good direction.

It is a consistently stable product. IBM BPM has come a long way from its original Lombardi days, to coming into IBM and the rewriting of the overall framework, to the way the UIs work. Where it is today, it's quite an enterprise-level product.

We use it across the board for what IBM labels smaller clients, commercial clients, all the way to enterprise clients. It's like any software package. Scalability is built into it, but it doesn't always come automatically. There is a lot of expertise that we use in performance-tuning it. There are times when, if you have a tremendous number of API calls, there's some tweaking that should happen to optimize that. But it's all configurable. There are things that you can tune to make it enterprise-capable, based on your use case.

Tech support is an area that could be improved. What we've seen over the years is that they had better support in the past than they do now. They're a little slower to respond; that could be based on the resources that are available to IBM.

Setup is a little more complex. But with the support of platforms on cloud, we love that, our customers love it. This becomes so much easier. We provision an environment and now we start building business processes or the application immediately. We don't worry about configuration.

Installation for on-prem used to be a one-time activity for engagement. And we may not even mentor a customer on that, because all they really care about is building processes. With the cloud, it becomes just a push of a button to provision it.

Mostly for business orchestrations, and developing the process applications within Wells Fargo Advisors, and we have other lines of business like retirement, wealth, etc. So we basically build the process models for all the internal back-office operations.

We started four years ago with one or two process apps, but now we've got close to 40. So that's a lot of incremental development in the last three years.

We have a legacy product, called MQ Workflow, and we developed so many process apps using that tool, but we migrated everything to BPM three years ago. The best part is the orchestration simplicity. However, we do have some issues, but, as we work on those challenges, I think overall, product-wise, it is pretty good.

I checked out a session, here at the Think 2018 conference. They basically merged the old BPM with the Case Manager, PFS, etc. That's pretty good, but we need to figure out how we can better use the Case Manager and PFS with that existing business flow.

It is pretty much stable. We had some hiccups in the beginning, because of the product learning curve. But once we got the environment stabilized, we have hardly seen problems, from a BPM standpoint. We do have other components like, the LDAP and databases, and the ASM F5 Web tier, but from a BPM product standpoint, I think it's pretty good.

It's scalable. We started with three nodes on day one. We expanded to five nodes, then we basically had two other engines, so we have about 15 now.

But there is a limit. There is a point where you stop, you can't scale anymore to improve the performance. But for now, I think we are okay.

We have engagement, whenever there is an issue we open a ticket with IBM, depending on the severity, whether it's two, three, sometimes one, if production is down. The people who we work with are pretty responsible, most of the time. Again, not every time, but when it comes to the production and management, I think we get good response.

We do have a liaison between Wells Fargo and IBM who takes care of high-priority tasks with Wells Fargo. They escalate, sometimes it goes to labs, level 2. We don't see any problems where nobody is looking at it and we're struggling, nothing like that. People are helping.

I think we had some assistance from IBM, for a few months. After that, in-house, we pretty much took care of handling it.

I would rate BPM an eight out of 10. Again, this is all from my infrastructure platform support standpoint. We do have a lot of application development, testing teams, QA teams, they also interact with the BPM product. But my job is more platform topology, architecture.

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.

The most valuable feature of IBM BPM is the low code design, and ease of maintenance. Additionally, the integration is good and easy to do.

IBM BPM can improve the dashboards and reports. It only has two dashboards, and reporting is very difficult to build.

I have been using IBM BPM for approximately five years.

IBM BPM is a stable solution.

The scalability of IBM BPM is good. It's easy to add features and applications to the platform.

I have approximately 10 customers, with each having an average of approximately 300 users.

The support for IBM BPM is good.

I have not used other solutions in this category.

The initial setup of IBM BPM is easy to do. The implementation time depends on the business that the solution is being put into. It typically takes six months to one year to complete the process. For a deployment that is easy, the process could take only a few hours.

We have two to three administrators that support IBM BPM.

My advice to others is this is a good solution and they can find a lot of advantages. I recommend this solution to many users.

I rate IBM BPM an eight out of ten.

Process automation.

• Traceability
• Fewer humans errors.

The integration layer is powerful in the advanced version.

It should have a more powerful and faster form builder, also the license is complex using PVUs.

Excellent but some network latency should be prevented for development since Web Process Designer is collaborative and distributed

Very good! horizontally and vertically

no

It allows for model-driven development, easy to use drag and drop type configuration, integrations, reporting, etc.

The main business benefits, at the highest level, are to improve the customer experience and operational efficiency. Sometimes, you can't do one without the other. I am trying to improve how customers interact with organizations. These days, everybody has many channels through which they arrive. For example, even in this day and age, a lot of very large companies have siloed operations across channels, which leads to a disjointed customer experience.

We use it as a client workflow platform, because it is designed for improving client-facing and internal processes. There are other uses for the platform: rapid application development, low code development, and high performance application.

As soon as you go live, you have a bunch of changes right on the back of it. Those changes will go live in two to four weeks. It will continue to keep up with the changing needs of the business. That is the strong value proposition of BPM. It's not a one-time automation.

The user experience, while it has improved, should continue to improve. It should stay on that trajectory. These days, we are all spoiled by applications, like Amazon and Facebook, and stuff we are using in our day-to-day lives. We expect the same experience from enterprise applications as we do from consumer applications. Some of the companies which are leading the charge have minimized the gap of customer experience from consumer to enterprise. IBM and its BPM platform is moving in this direction. It still need to improve, but it's getting there.

It is very stable right now. We have seen nothing but amazing results over the last six years.

I have yet to come across a use case where scalability was an issue. 

We don't use their support. We have our own IBM experts who are certified and have years of experience.

The initial setup is very quick. 

Most of our projects take about three people and are done in three months.

BPM is good when used for the right use cases. I will not use BPM for a trading desk that's making split-second decisions because that is not the right use case for it. When you use it for the right use cases (e.g., a loan origination process for a bank, claims processing for an insurance company, or a healthcare provider accepting a claim and settling it), processes which typically range from hours to weeks, then when you apply BPM, you bring the processes down by an order of magnitude to minutes to hours, respectively. Those are the right use cases for BPM. There's no performance issue if you use it the right way. 

Our customer continue to use the product over time, which is the best indicator that they are seeing ROI from the product. 

It has a low cost to implement. You'll get your money back in the same year that you complete the project. 

One of its competitors is Appium.

If you're not leveraging these types of technologies, you're missing out.