by 
Many do not know how we got to the ERPs (Enterprise Resource Planning, or in Portuguese Sistema Integrado de Gestão Empresarial) and BPM (Business Process Management)
At the turn of the twentieth century, the study of industrial work emerged, a direct descendant of Taylor’s research, which involved Galbraith and many other pioneers in the study and measurement of work, giving rise to O&M (Organization and Methods), which deals with techniques that aim to improve the functioning of organizations.
The emergence of information technology in the 50s changed the subject in an increasingly radical way. In the mid-1960s, issues involving data processing were presented in O&M books.
BPM and ERPs: Timeline
In the 70s, it was common to design work flowcharts in which professionals should follow the flow of information. These flowcharts were developed by the O&M team. In the 80s, the first microcomputer programs appeared with independent systems for billing, accounting, tax, accounts payable, accounts receivable, among others. It also started the workflow, which brought workflow automation.
In the 90’s we saw the emergence of the era of ERPs. It was believed that all the company’s information would be in one place and fully integrated, abandoning the model of the internal O&M area.
It was at the turn of the twentieth century that the concept of BPM emerged, which makes it possible to standardize corporate processes and gain productivity and efficiency points. BPM solutions also serve to measure, analyze and improve the management of a company’s business and financial analysis processes.
BPM as a complement to ERPs
The emergence of BPM happened from the wave of implementation of Integrated Business Management Systems (ERPs) in large private companies, at the end of the last century (products such as SAP, Peoplesoft and their national counterparts Microsiga, Datasul, etc. are in this category). ERPs contain a multitude of rules, which are costly and time-consuming to change, requiring specialized IT personnel. BPMs, on the other hand, extract the administration of these rules from ERPs and enable process analysts to make changes without modifying the programming.
It is at this point that BPMs complement ERPs, since a good BPM should allow in a simple and easy way the connection to extract the reading information that is in the ERP.
Example 1 of how BPM complements ERPs
In an analysis with one of our customers, we realized that it was possible to model complementary rules to the ERP so that we could monitor and have all the histories of the facts that happened with all security and confidentiality.
When we model a process of any type of request, we already identify the requester, the date and the time. As this flow goes on to the next activities, we have information about who did the activity, the date and time it was carried out and what was done.
Depending on our modeling, we even have the reason why a certain action was taken and, in the end (or even during the activities of this process) we can simply and quickly search for information in the ERP, or even record information. This, in addition to generating transparency in the information, meets the needs of the compliance department and ensures the execution of the rules and regulations defined by the sector (as well as the confidentiality of the information).
In each sales consultancy I have done, we have always been concerned with helping our client to make the best decision, not only in the acquisition of the solution but also in which processes (flows) are important for the company.
Example 2 of how BPM complements ERPs
I usually advise my clients to be careful not to invent the wheel. The ERP must continue to fulfill its function, and only processes that complement the information necessary for the company’s management must be modeled in BPM.
However, a curious fact happened. In a demo for a client, he asked me if we can model in BPM – in a simple and fast way – a purchase request flow using the levels of authority and approval hierarchies.
I commented to the customer that it was, but I took the opportunity and asked if the ERP they used didn’t already do that. The client argued two points that caught my attention.
The first was that in the ERP that he uses, the cost of parameterization and training is very expensive. The second point was that for the board’s approval they should hire more ERP users, but the board did not want to access the system to do that. The client asked me if we could do this type of process (flow) in BPM.
The answer was affirmative. Our flow modeling was very simple and the connection to record the information in the ERP was very easy, and from the levels of authority and the approval hierarchies, the Approved Order is generated in the ERP.
As the directors did not want to access the ERP or our BPM solution, we sent two buttons in the body of the approval email (pass/fail). In this way, the director executes the approval directly via e-mail.
This is a typical case of cost-benefit analysis that paid off very worthwhile to invent the wheel.
