We just raised a $30M Series A: Read our story

Red Hat Polymita Business Suite OverviewUNIXBusinessApplication

What is Red Hat Polymita Business Suite?
Red Hat JBoss BPM Suite combines business process management (BPM), business rules management (BRM), business resource planning, and complex event processing (CEP) technologies into a single, integrated, open source platform. JBoss BPM Suite lets project stakeholders collaborate to build business automation solutions with a choice of modeling tools. This includes a web-based authoring environment for business experts and an Eclipse plug-in for developers. A rich set of tools for process and decision management covers the full process life cycle - from modeling, simulation, and testing to deployment, monitoring, and optimization. Process and decision logic can be modeled and automated together, without the need to learn multiple tools or develop custom integrations between disparate environments.

Red Hat Polymita Business Suite was previously known as Polymita Business Suite.

Buyer's Guide

Download the Business Process Management (BPM) Buyer's Guide including reviews and more. Updated: November 2021

Red Hat Polymita Business Suite Customers
Bayer, Grupo Televisa, RCBC, Peavey
Red Hat Polymita Business Suite Video

Archived Red Hat Polymita Business Suite Reviews (more than two years old)

Filter by:
Filter Reviews
Filter Unavailable
Company Size
Filter Unavailable
Job Level
Filter Unavailable
Filter Unavailable
Filter Unavailable
Order by:
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Showingreviews based on the current filters. Reset all filters
Luis Yndigoyen
Partner at a tech services company with 11-50 employees
Real User
Gives you the ability to design the screens outside the software and connect them as a component with the BPM engine

Pros and Cons

  • "The main factor that separates Red Hat software from Oracle, IBM, Pegasystems, is the ability that it gives you to design the screens outside the software and connect it as another component with the BPM engine."
  • "I think the documentation for the tool, the official documentation, is not as strong as in other tools. You have lot of community. That is good. But sometimes you need - when you are working on a big client or a critical process - to be certain about certain things. So I think that the documentation for the tool, from the company, could be a little stronger."

What is our primary use case?

In Latin America, a common business case is in banks, for onboarding clients and credits approval, also the government and insurance, lately. During the last three or four years insurance companies have come to use it more.

How has it helped my organization?

I am a business consultant. So really I can comment about the results for the customers. The most important benefit is to have a good solution at a good price that enable to the Red Hat BPM users to develop by theirselves their fromt end above the language and schemes that suites more to them. 

What is most valuable?

For us the most important feature is the ability, similar to any BPM tool really, to design and easily implement integration with the other systems. That is the key.

The main factor that separates Red Hat software from Oracle, IBM, Pegasystems, is the ability that it gives you to design the screens outside the software and connect it as another component with the BPM engine. That could be seen as a disadvantage, but really but in a world where specialized IT resources are more difficult to find, you can develop coding in the language that you prefer: In  Angular, in Java, in .NET. So for us, and for the customer, it is a benefit.

What needs improvement?

On the improvement part, I think the documentation for the tool, the official documentation, is not as strong as in other tools. You have lot of community. That is good. But sometimes you need - when you are working on a big client or a critical process - to be certain about certain things. So I think that the documentation for the tool, from the company, could be a little stronger.

Also, the size of the team within Latin America. The size of the team that, in each country, knows about BPM - because of the size of Red Hat in comparison with the size of IBM or Oracle - is very little. You have maybe three or four people in the company, in Red Hat Mexico, that know about BPM; and in Peru, maybe one, who also needs to know about five other tools. You have help there, but sometimes you don't need that kind of help. You need to sit down with someone and take a good amount of time and discuss a process to solve a problem.

It's a consequence of the size. IBM and Oracle are monsters. They have, say, 100 more employees than Red Hat. That is the problem. But on the other side, the price is good. You could pay four times less, five times less, in an average implementation with Red Hat than with IBM. So there is a trade-off.

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

It's stable, as far as the volume that I use goes. In BPM you could have the opportunity of using huge volumes for big clients, but I don't work on that level. But really, because it's working over Linux, I think that it's a platform that works very well. 

What do I think about the scalability of the solution?

No problems with scalability. 

I think this is also an advantage of the size. IBM, Oracle, and other tools have some 100 kinds complementary elements to the program that makes it very hard to understand what you need to buy. Usually, when you compete against other software, at the end they show a list of 20 pros to the client. Red Hat is very simple. You need to buy BPM, and the operating system - Red Hat Enterprise Linux - and the database. You don't need more. That is an advantage for Red Hat, they don't have a thousand things on their price list, a very short and concise offer on BPM.

How are customer service and technical support?

On this point the community is good, because you have a lot of community that use the software, for the price. So you have a lot of use cases.

The tech support is good. I think that works well because they have people that know the tool very well in English.

Which solution did I use previously and why did I switch?

I used to work with IBM. We decided to switch because IBM has a consulting arm, GBS, Global Business Services. GBS began to compete with the partners. At that time, four years ago, I was one of the main partners in Latin American BPM, in the top fifth. They began to take people away from me, not directly, but indirectly through other channels. They began to compete, and the ecosystem became very crazy and the prices went down, so I preferred to leave that tool. Also the tool is very expensive.

The system at IBM didn't care about the partners in Mexico and Peru and they opened the door for many people that didn't invest previously. Also, the price was a reason I decided to switch to another tool, that tool was Red Hat because of the price and because it has a presence in Peru and Mexico.

If a client approached me with a lot of money - and money was not a problem - I would go for IBM, because IBM is really a better program. You couldn't compare a program that invests around $300 million in development against a program that invested $3 million. It's a big difference.

On the other hand, you always have problems with budget, and more so in Latin America. That is the reason that we go for Red Hat, because we can run and compete for more clients. For me it works, it solves 90% of the problems that clients usually have in Latin America.

What about the implementation team?

Really easy. An easy installation in a couple of days, and that part is well documented by the company. And if not, you have the community and a lot of us can help you with it.

What's my experience with pricing, setup cost, and licensing?

Red Hat doesn't like it that I advise people that there is the community version. The problem, many times, is not for the IT department or for business unit, it is that you need to convince to the boss that you need a big budget for a BPM initiative, depending on the size of the client. The prices are global, so without any discount, you need tools that cost roughly between $80,000 to $100,000. That is less than with IBM. And on top of that you need the consulting. That will be another $200,000. So a quarter to a third of a million dollars is needed to use get started with BPM.

So I usually recommend to my clients that they begin with a little project, with the community version. That way they don't spend $200,000 or $300,000, they spend $150,000 and zero on software. So it's half the quantity of money, or even less if you negotiate with a Red Hat partner, so that you only need to try the concept.

I think that you need to begin as a project, to hire a consulting company. You should use the community version, maybe for an internal process and not on the front-end. You should test the tool, test the concept. I think that almost any company can benefit from a BBM implementation. But the question is whether they have the capability in terms of time, of management, of the people. Those are some of the factors that can affect and the implementation from IBM or from any tool.

Begin with a non-critical project and make it a proof a concept, a pilot, and with that you can go and sell the result, or see what you need to change first, before going ahead with full BPM.

Many times big companies, they buy half a million dollars, $1 million of licenses. They have tons of functionality and tons of capacity. They are told, "Oh, buy for 40 processors and you will obtain this discount." But for the first two years they only need a tiny part of that capacity. I have seen a lot of clients that have, for example, $4 million for a BPM initiative - the government usually. They launch a competition and they offer $3 million for software, $1 million for consulting, and usually it doesn't work that way. They sit down over a ton of software but they don't have money for implementation or for training. It's like they are building the pool first and after that begin to worry about the house. I have seen that many times. That is because of the strength of the software industry. They don't put enough money on the consulting side, on the services, on the training of the people.

That really makes me upset because in Latin America that money could be used for the government, the institutions have a lot of things to improve, and BPM could really help. So the pension of the government sent like $10 million for an initiative and when the project ended they had nothing, almost nothing. We don't have a lot of money in the government in Peru, in Mexico, in Colombia. And there is a lot of poverty. You could have people who are dying, waiting for some approval. There are a lot of things that the government needs to do and that BPM could help with, could improve, could provide answers to the companies for bureaucratic processes. They put money into it, but in a bad way.  It also happens in the private sector.

Also, BPM has a bad rap because a lot of projects don't provide value, for this reason. They concentrate more on the tools, and really, any tool will handle 80% of your needs. If you are an IBM company, maybe an IBM tool would be better.

Sometimes you might buy IBM or Oracle because you get a big discount and in three years, the discount is not so big, they raise all the prices because they know that you are tied to the solution. Then you have to pay a price that you can't afford, so you leave the solution. 

I it's important to evaluate very well the capabilities and begin with something little.

Which other solutions did I evaluate?

It depends on the size of the company, but for a given company and project, IBM is really the best tool. However, there are a lot of problems with the IBM implementation.

What other advice do I have?

I would recommend for any BPM implementation - and I have been dedicated to this the last 11 years - that you have a very clear objective, the goal of the BPM implementation. It's not the tool for the tool's sake. The end of the project is not the project itself or the tool itself. The end must be, "Okay this process is from this current condition, has these performance indicators, and I want to obtain this improvement. If the process is taking three days I want it to take one day. If the process is costing $100, I want it to costs $40. If the process requires 10 signatures, I want to apply one." 

So at the beginning, for me, it's three things. One, that you have the goal clearly defined for the process. Second, that you have support from the directors. And third, that you need to work in a non-traditional way.

Regarding the third piece, one of the values of BPM is that the customer should be able to see the benefits and the resources, step by step. In addition to the the sponsor, involve the key users in the process, almost on a weekly basis. That means that each week you need to show them the progress.

If you have those three, usually projects  are successful. 

In terms of Red Hat, I think it is no different from any software really. You need to understand very well what you are you buying, what you get with it, what you need to complement it, and to decide if you put it in the cloud or not, from the beginning.

It is a very technical project, so you need technical people looking very closely with the architect from Red Hat, or from the vendor. Don't forget anything, like the operating system, the database, to have a clear diagram of that. 

Disclosure: My company has a business relationship with this vendor other than being a customer: Distributor.