History: From Paper and Emails to Electronic Document Circulation

Customer needed an information system that was able to keep track of all contracts being signed with third party contractors. They already had offline approval procedures defined by legal requirements for both contracts and third party contractors. Still doing all this offline and with help of an email exchange or simple paper circulation was both not very efficient and there was no traceability of who approved what and when.

Nexedi proposed a combination of a document management system (DMS) and an electronic document circulation system (EDC) based on a simulation of decisions which is able to manage the entire life cycle of a contract approval procedure with all involved contract's documents. What made this project challenging was that mixture of two types of system in a quite complex and ever changing business requirements environment.

In order to fulfill customers requirements for an EDC system we developed a new abstract approach of a Decision where a decision is an object into the system representing an activity request to an assigned person. This simple but power and quite generic concept provided traceability, history and simplicity: everybody who is assigned to decide on a contract must either approve or refuse a decision generated by the system for him / her. It is the system which knows based on business rules described by business processes what decision to built and for who. Thus users do not need to do anything else except approve or refuse a decision.

Another interesting feature of the system is that it provides collaborative tools for co-working and co-creation of documents which describe a contract into a textual legitimate form. For this we used an already existing ERP5's DMS application which allowed users to effectively work together on any document into the system while system takes care to handle all details like document's revisions, versions and history. All of these actions are tightly coupled with EDC part as well: for example adding a new contract's document revision is considered as a decision refusal in some cases in other when revision change is minor it can be considered a decision approval.

Implementation started with 1.5 month of a prototyping in order to demonstrate how ERP5 would meet the requirements of the customer. After successful first prototype Nexedi started real implementation. After going to production for first time any other additional feature is again first prototyped so customer can see feature before any time is spend to make it perfect. After going production big part of the system was translated by customer's engineers to Russian.

Business Process to model any process inside a company

The concept of Business Process was used to describe the contract approval procedure in order to approve a contract or third party contractor. This is a general purpose concept which allows a developer to model any process inside of a company no matter if company is a service oriented, trade or a manufacturing company. Nexedi developed this concept actually for manufacturing business but it still applies as in this case for a trade and sale company. This shows that it is possible and needed for any ERP system to have tool which allows business managers to describe any business process using nice ERP5 user interface themselves. It also proves that it modeling these business processes provides a nice abstraction layer between business people who understand in depth the business of their company and real system integrators like Nexedi who understand the system technically but have little knowledge about their customer's business. They both can work together seamlessly as discovered in this project.

In the context of the current system we used business processes as an abstract tool to describe any possible contract approval procedure based on existing business rules. This tool allowed us to have a configurable layer which even customer's engineers could use to extend system with new approval procedures themselves.

Why abstraction through Business Process is important

In the context of the current system we started initially with set of business processes which allowed parallel approvals of decision between all involved decision makers. Initially it was considered that people working in parallel will be much more efficient than working in sequence which in theory is right but reality showed it was different.

In reality, revision of contract attributes or body during approval process can be frequent because document circulation itself also involve collaborative creation of document but approval process always requires unanimous approvals from all relevant members. This is why parallel decision model, which is the most beneficial part of system was not accepted initially as it might cause regression of document versions.
However, sequential decision model which was introduced later can also caused lots of frustration among contract initiators as it will cause multiple iteration of decision requests and rejections.  And even worse, inefficiency becomes so transparent due to the good historical traceability of system. Luckily this lack of efficiency could quickly be fixed by re-arranging business rules for a contract approval inside company and later turning them into pure ERP5 Business Processes for use into the system.

This example above show how quickly business requirements can change (from parallel to sequential approval processes). Luckily due to using an abstract tool of a Business Process this change in customer's requirements didn't require re-factoring the system - we just had to re-model the used set of business processes.

The Challenges of implementing such a system

There are many challenges in this project which can be grouped into two categories: technical and human ones.

Technically we needed a way to represent quite complex internal company structure based on departments and positions, implement strong security based on it and make sure the system can generate decisions for every member of a department based on any used approval procedure required by our customer. For this we introduces a new module for ERP5: Positions. This is a general purpose tool which allows one to model its company hierarchy using Positions. Based on such hierarchy we can build security rules which define what user is allowed to see and what user is allowed to modify.

Change in internal approval procedures happens almost constantly due to ever changing business needs of customer which require great flexibility by Nexedi. This was initially accounted for and a generic workflow system which is able to represent any customer's approval procedure was created. This workflow system uses ERP5 simulation module internally and allows if required for customer's engineers themselves to model new procedures using built in user interface.

Because system relies on human decisions  - it was soon discovered need for some additional features like: support from external personnel or assigning a specific decision to a specific person (either due to leave / absence or due to type of decision which requires some specific skills). All of these features were implemented after a small prototype and then implemented for real. This partial development would not be possible without heavy testing each and every part of the system thus preventing regressions.

Interestingly the most challenging part was how to make people understand complexity of the system and use it effectively. Both Nexedi and engineers at customers side had to face and overcome many challenges like: mental barrier of users who never used such a system before, doubts for system efficiency as in some cases from user's point of view a paper circulation can be quite fast and efficient (but not manageable), etc.Training was not only to understand and use system and its business processes, it soon became apparent that the introduction of such a system influenced the internal company culture.

Part of being successful in this was to make system as simple as possible for user and provide good video training materials. Translation of user interface was also helpful. 

Implementing Good Security Model

Definition of good and strong security is very important. This requires carefully analyzing customers' internal company rules and turning them into system rules.

This wouldn't be possible without support from customer's engineers. Still such a system requires to define who, when and what can be accessed which creates quite a complex security schema entirely based on combination of security rules based on current used approval procedure and users' department and positions into company's hierarchy.

To implement such a complex security nexedi followed the best ERP5 Security practices - i.e. the so called "5A" model into which the security of the system is built around 5 type of roles Author, Assignee, Assignor, Associate and Auditor which any logged in user can posses. Each of these roles defines certain permissions of a given object in any moment in its lifetime. Using a matrix or documents' permissions and 5A model allows any ERP5 developer to model security rights for any group of users easily which is very important when sensitive information is handled like financial documents.Another layer of complexity comes from fact that company has a hierarchy structure based on combination of Departments and Positions. This makes the matrix of security quite complex considering fact the very strict business rules of a customer.

Agile development and remote work

Nexedi uses agile methods for development both because of fast emerging changes required by business and because developing in small steps in short time allows us to minimize risk of misunderstanding between business requirements and real implementation.

This project is not an exception to this rule: the normal feature development time is in matter of weeks rather than months. This wouldn't be possible without ERP5 being designed as completely generic system with general purpose tools and no assumptions at all. Another tool and concept used heavily in this project was the so called live tests which basically are unit tests which can be run on a "live" instance and test anything into it. This allows rapid development cycles as in any moment you can run live tests to prove your current change didn't introduce any regressions into code. Without heavily testing such a complex system wouldn't have been possible to create.

Considering that customer's location is in Russia and Nexedi is based in France with developers from all over the world the entire project implementation was done remotely which was quite challenging itself.

SlapOS Cloud, Distributed System, Resiliency and NoSQL

Customer instance is based in a cloud infrastructure provided by SlapOS.

Access to system relies heavily on res6tnet which is another babel based resilient network component developed by Nexedi. As reliability of any data center is not always predictable and depends on many factors for this project a new component was first intorduced which is called Resillient Webrunner. This Webrunner is responsible for making copies of production system to at least 2 computers in different data centers. If one data center is down with dynamic DNS rules we can adjust frontend to point to a backup one easily. As traffic is over Ipv6 any machine is accessible from anywhere.

All the data is stored in a ZODB which is a NoSQL database. Still as with many NoSQL database ZODB lacks efficient query language thus ERP5 uses MySQL database to index objects and provide native query API.