What is our primary use case?
We use it as the main landing page to allow users to go to other applications. We have built-in applications mainly for planning. We have a few other applications that we direct users from the portals to other dormant pages. IBM BPM is not really meant for either UI you know. The UI looks a bit outdated but we have another application in which we have 2000 plus users using this at the moment, so our user base is big. We have problems with the slowness and the UI and that impacts the user experience for who use it. We've decided to migrate away from this solution.
What is most valuable?
It can easily trace where the path has gone, what the next start is. We like the feature in which we can trace back instances. Users prefer all the .Net features. Sometimes there are tasks that failed without any reason. We process it from the inside which is a cumbersome task. Users won't know that it failed, they'll just ask what happened to their pass.
There are no issues with it. I think maybe our setup wrong. Our infrastructure uses a single cluster with two nodes. I don't think that's suitable for our production environment.
What needs improvement?
We have a process flow and we have multiple applications using the same platform. For example, application A uses the PX 1.0 and another application has to use 2.0 or 3.0 because 1.0 has been used by application A. That's the reason that the user asks why they are using version PX 3.3. They want to use whatever they want.
For how long have I used the solution?
We have been using IBM WebSphere since 2017.
What do I think about the scalability of the solution?
I am impressed with the scalability on our side. Our management is not investing in scaling up the service. It's quite stable at times but sometimes they give us headaches also. We have issues with the BPM lock not expanding in time. It becomes slow because it needs to expel the DB log.
How are customer service and technical support?
We have contacted their customer support a few times.
They are very technical. When writing the logs we are redirected to the correct support team. Before engaging the support team, we did our own research. IBM has its own website knowledge base. There are times that we are not confident to perform those steps ourselves because the impact will be huge because production will be down for a few days. There are times when we have had a few steps that we needed to troubleshoot with the support team. The onsite support requires additional charges. It depends on the severity of the ticket.
How was the initial setup?
We were not involved in the initial setup. It was already set up for us and unfortunately, we were not given any hands-on training on how to manage or how to become admins of the product. We learn as we go.
We had a good environment and we wanted to switch the environment to connect our production environment so that users will not be impacted because the production went down.
What other advice do I have?
It's a good product. It's stable. The support is available to you. If you have the budget and you have a solid developer team that is well versed in the IBM product then you can invest or else you would be in trouble because you need to source out all these resources.
Users have high demands. They want to have a single sign-on option and those kinds of things. They want to see less clicking. They want to see all of these features in the web nowadays and our version doesn't have them.
I would rate it a five out of ten.
Which deployment model are you using for this solution?