We have been trying various methods for years to describe our business processes. Our story, which started with the purpose of modeling by industrial and information engineers, has brought forth languages ​​such as BPMN and UML as our needs increased over time.

You can see a summary of our story below

Since 2005, we have turned towards languages ​​such as BPMN, which tries to translate the diagrams we use for modeling (documentation and analysis) into software that we can use directly without the need for a conversion. (link:http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation )

Based on engineering needs, BPM and UML models consist of symbols with different meanings in accordance with their starting point and are still an engineering field. 

Although this diagram is relatively simple for those with technical knowledge, it is a very complex language for those who work in the accounting department that owns the main job.

To understand and comment on this language;

• Learning the meanings of symbols
• Having knowledge of the subject of the process
• Understanding and being able to ignore technical details such as sending e-mails

Apart from that, a good computer user and a lot of drawing effort are required for a clear diagram view.

So usually such models; It is drawn either by technical people with no field knowledge or by field experts with no technical knowledge, and often contains minor errors. When used for documentation purposes, minor errors do not pose much of a problem, but they do occur as a problem because it is designed to run on systems such as BPMN.

In order to avoid these problems, we wanted to use our language instead of a modeling language like BPMN. The language we use should be in a simplicity that can be easily understood by the process owners and with a logic that does not contain technical details, as we consider this we reached a model like the one below.

The symbols you see in the form of large boxes in this model show the tasks in the flow direction in the process.

Each task (Task) consists of a title, the role (Role) to which the task will be assigned, the action (Action) that is a result of the task, and the route (Route) that connects the tasks. In this way, anyone who examines the model of the process can develop a comment about what happened in a very short time.

During the modeling of the process, technical details such as sending mail and database access are included in the definitions called PreWork and PostWork. PreWork definitions work when a job is assigned to a user, PostWork is another piece of code that runs when the user selects an action on the task.

Apart from this, all the technical works that we want to take place in the process as a distinct step can take place in the form of a task type called Module, just like other tasks.

Another thing we do differently is that there is no need to draw a drawing to produce the graphic. As long as you make the definitions in the process, Emakin decides how the graphic should be byself. With a type of artificial intelligence technology called “Directed Acyclic Graph”, it defines how the relevant connections should be drawn instead of the steps in the process in the graph. In this way, the user is focused on the process in the time taken to draw a clear process diagram.