The WorkFlow in the enterprise
The labyrinthine approach
When we see the waiter introduce our purchase in his POS terminal we can get an idea of, in general, a vertical software, with an specific use and a very reduced incidence in the company’s processes. Probably the restaurant will add up the sales at the end of the day, and maybe it will have some interface to communicate with another accounting application.
Usually no more than that. And it’s good that it’s like that, simple, effective, no frills.
We change the area
We are now in a factory management centre, a program is in charge of managing the manufacturing processes. It needs to communicate with human resources and their shifts, since the machines must always be in service.
The availability of the raw materials should also be monitored, because the lack of a single raw material would result in the cessation of production.
In real time the software must contact the suppliers to inform them about the projections. When each batch arrives, a verification and transformation process must be followed before it is incorporated into the production line… let’s stop here.
There is a certain approach to built the software in charge for managing the mentioned scenario: to make the program from top to bottom, no matter how complex it is. We will open the door to that
software to communicate with any data repository or external applications. Everyone in the business knows that this is truly complicated. In first instance, without
going too deep, we found some weaknesses:
- Rigid software
- Difficult to make change
- Developers must understand the business very well, the whole business in all its phases
Why do we consider this approach to be labyrinthine?
Let’s take an example. Let’s take an example. Up to now, one of the parts that the supplier provides us (in our example) needed “x” hours of handling before being incorporated into the assembly line. And it had to be assembled with another part from a different supplier. But now it turns out that the whole piece comes without handling needs. It completely changes the manufacturing route and its timing. How do we fix this in traditional monolithic software? Well, it all depends on how it’s done, we will have to find the code areas that are involved in these processes and make changes, recompile, redistribute and hope that everything goes according to the plan. As the software complexity increases, so complicated will be the modifications, labyrinthine.
A mathematician in a factory
He was born in 1926 in Leipzig, a mathematician’s son, with an easy-going personality, it is said that at the age of 13 he created the networks that would bear his name for chemical reaction models. He was trained at technical universities and his great mathematical contribution would not be related to abstractions or pure mathematical theorems, but rather with the mathematical application to something fundamental in any process, industry, activity, society: the interaction, the concurrence, the collaboration between processes. Its first guiding principle: Concurrency should be the starting point for designing a system, not added later as a reflection, it means, life is complex. . In any activity (an industrial process or any activity) many actors and forces converge and interact at the same time. One process depends on another and this one on a third. This can lead to race conditions or even deadlocks. The software we create is actually an abstraction in code of these realities, we can’t save it from facing the same problems. Well, our admired Carl (Adam Petri) proposed in his doctoral thesis in the 1960s a formal description of how complex systems interact.
With these devices, complex concepts can be easily modelled: parallelism, cooperation or competition. States and transitions are represented. The last ones can be forked or merged. Thanks to the Petri Nets conceptualization, complex situations could be formalized and problems could be highlighted.
Take for example the problem of the philosophers’ dinner. Where a group of diners are competing for a given set of resources (forks), exposing themselves to leave each other without dinner, even all at once, when instead, if they cooperate with each other and take turns, everyone can have dinner.
In summary, Petri Nets are a mathematical conceptualization of transition modeling, used in computer science often at the theoretical level. They can be represented with mathematical formulas. But a new player was about to emerge:
How to apply the Petri Nets concepts to the specific company problems?
A stakeholder group creates Business Process Management Notation, a XML notation system to explain the processes, states, flows, interactions, but not those of the theoretical-mathematical world, but those specific to the business world (BPM).
These concepts, once formalized and described, can serve as a common language for all stakeholders to agree on “drawing” the Company (its workflows).
There is a serious drawback to using BPM software in an organization. Usually it has to be activated “suddenly”, and that can be intimidating. It’s a kind of “marriage” that can work out… or not. SAP is a good example of what we are talking about. Of
course, like almost every wedding, marrying a software that “draws” our company is not cheap.
By comparing both (workflow vs. BPM) let’s say, the Workflow:
- It coordinates tasks and functions of a process
While the BPM software
- It coordinates the organization
What if the BPM methodology could be implemented little by little, department by department, process by process?
Of course, without making irreparable or difficult decisions (marriage) and having a global vision from the beginning. Does such a methodology/software/panacea exist?
SIf it exists, why haven’t I heard of it before?
A workflow software is a spin-off, a Petri Network specialization applied to activities, usually corporate. It presents, among others, numerous advantages:
- In workflow design phase, all parties are forced to streamline processes, achieve efficiency, cleanliness, eliminate redundancy, and optimize flows.
- When programmers are faced with “snacking” code, they have very clear ideas about the responsibilities of each program part. This helps to avoid the maze problem noted at the outset.
- • And throughout the program’s life cycle, it’s easier to make changeswithout causing damage. It is known what part of software can be manipulated and how it affects other parts of the system..
And why aren’t they well-known? Because we have enough to deal with getting the code out day by day, week by week, to learn a technology that, although it makes things easier for everyone, forces us to invest a lot of time learning it. Well, Flash Data has already made that investment for your benefit.
Add a workflow to your life, the developers who relate to our workflow technology confirm that their work is simpler, higher quality, more organized. In fact, as it is, it is possible that with few changes (ideally none at all) your organization’s current software can use this approach.
The licensed Flash Data software is based on the Workflow Engine, we have a license to use the code. We adapt and develop this software to the client’s needs. Some features are:
Now, based on that great platform at Flash Data we have developed : the AntWay platform, which brings the workflow world closer to the BPM world due to its centralized features. So with AntWay we have: