| Name | |
| Caroline Rüdisühli | [email protected] |
| Charline Unternährer | [email protected] |
| Michael Vontobel | [email protected] |
| Sabina Portmann | [email protected] |
| Name | |
| Charuta Pande | [email protected] |
Following deliverables were mandatory:
- Link to GitHub repositories containing modelling artefacts and other project artefacts, if required, and a documentation (e.g., Readme and interlinked .md files).
- Link to a running workflow(s) and/or instatiation(s) of a link to start form(s) and/or cloud-based deployment(s):
- → Link to Make
- → Link to Google Forms (process triger)
- → Final BPMN model
- → DMN Type of Absence
- → DMN Team Capacity
- Link to presentation slides: → Link to presentation slides
We had several DevOps-tools and development platforms available for our assessment. We used the following:
- Camunda Modeler (Platform 7)
- GitHub
- Visual Studio Code
- Git
- Make
- Dropbox
To fulfill our tasks, we used several languages:
- Hyper Text Markup Language (HTML) & Cascading Style Sheets (CSS)
- Business Process Modeling Notation (BPMN)
- Friendly Enough Expression Language (FEEL)
- Git commands
Every company has a human resources department responsible for employee administration. Indeed, employees receive a salary, sometimes social or company benefits, and are sometimes absent for various reasons such as illness, accident or vacation requests. There are as many companies as there are HR processes, and the larger the company, the more varied and complex the processes are likely to be. For our project, we based ourselves on a watchmaking company (whose name we'll keep anonymous) which currently employs over 600 people. This company has a traditional management style, with a strong hierarchy and heavy reliance on paper. However, the company is planning to digitize its processes, both in administration and production. This made it an ideal candidate for our project, and we chose to focus on absence request management.
Currently, when an employee wants to request a leave of absence, the process is time-consuming and almost entirely paper-based. The employee must first ask the secretary to print out a form that he can fill out and send to his manager. The manager can then validate the request, but cannot consult the attendance schedule of all employees in his team. If the manager refuses the request, he announces it to the employee, otherwise, the request is forwarded to the HR team. The HR manager must also sign the form before passing it to an HR secretary. The HR secretary then verifies the presence of both signatures as well as the employee's available day balance (in the ERP). If everything is in order, the request is officially accepted.
The As-Is Business Process looks like this:
- Time-consuming and cascading process (several people involved).
- Paper-based process, not digitized.
- The manager does not have the possibility to consult the planning of his team.
In order to improve the process based on the identified pain points, the following objectives have been defined.
- Process digitization.
- Provide fully automated scenarios in the new process.
- Reduce process execution time.
- Allow managers to consult the team schedule of their employees.
After analyzing the current process, its pain points to eliminate and the objectives set, a desired situation was identified. The system must be able to detect the receipt of an absence request made online by the employee. The system has various rules which identify 3 possible outputs:
- The conditions are not accepted and the request is automatically rejected by the system.
- The conditions are partially accepted and the application is given the status of provisionally approved.
- All conditions are accepted and the request is automatically approved by the system.
- Either there are enough people, and the absence is then approved by the system.
- Or the percentage of people present is limited, in which case it's up to the manager to make the final decision, based on the current situation with ongoing projects.
- Or no more absences can be accepted for the sake of the work in progress.
The To-Be Business Process looks like this:
To keep the modeling process as lean as possible, we used two decision tables (DMN).
The first DMN, cheks which type of absence is desired. This can be seen in the first column.
After that, there are a number of additional specifications that must be met in order for the request to be approved either automatically or provisionally. If a requirement is not met, the request is rejected.
The second DMN, ensures that the capacity of the team is not reached when an emyployee wants to take time off.
In the following subsections, the DRD models and the corresponding DMN models can be viewed.
In the DRD model, the dependencies on the DMN are evident:
By clicking on the blue square in the top box "Absence from Type", the DMN will be shown:
Below are some explanations about the rules.
- Types of absence 1-4 are about vacation; as this is a watchmaking company, all employees have fixed holidays in summer, it means they cannot take more than 5 following days during the rest of the year. There is a particularity: employees over the age of 50 are entitled to a 6th week's holiday.
- Types of absence 5-7 are about sickness; if the employee has a medical appointment, I can take a full day, and when he's sick or in an accident situation, there is no limitation of days.
- Types of absence 8-16 are regulated by law and the collective labour agreement.
- Any other situation leads to a rejected request.
In the DRD model, the dependencies on the DMN are evident:
By clicking on the blue square in the top box "Absence from team capacity", the DMN will be shown:
Below are some explanations about the rules.
- The team capacity is different for each department.
- For the Administration department the limit is <70% and for the Production <50%.
- Requests which are over the set capacity will be automatically rejected.
- Requests which are in the range, are going to the manager.
- For all departments, if the capacity is under <20% the request is automatically approved.
In the As-Is business process, there were a lot of manual subtasks that had to be paper-based and sent to other departments or processed internally by other people.
In the To-Be Business Process, the overall process is streamlined and simplified and involves fewer departments and people. The main improvement, however, is digitization and automation, because there are no more paper-based forms and many sub-process steps are now triggered automatically.
The first step was to model the As-Is Business Process in the tool "Camunda Modeler". This step quickly made it clear which departments or individuals were involved in the overall process. This allowed us to discuss how to proceed, what could be automated and what would remain a manual task. Ultimately, it gave us the basis for the To-Be Business Process and the certainty that paper-based forms could be dispensed with for the time being.
In the To-Be Business Process, we defined in a second step which departments or individuals were still needed in the overall process, which dependencies were still there or were new, and how we could possibly streamline the overall process. The results can be found in the previous chapter. The following subsections show our results, which we have worked out with the Make tool in order to automate the To-Be business process.
→ Link to Make scenario 1
The trigger of the overall process is indirectly a Google Form. As soon as the employee fills it out and sends it, the request is saved in a new row of the associated Google Sheet, which ultimately triggers the overall process.
As a second step, we defined a business key that generates a random number and is unique throughout the process. Since there were some problems with variables from the Google Sheet regarding typing, we forced some of them to become strings with the method "toString()", so that they would be recognized as strings later on.
The last step saves the received variables of the Google Sheet and sends them to our BPMN model in Camunda. This way the data can be further used in the following process steps. The following image sets up the Make process:
→ Link to Make scenario 2
After the first Make scenario was triggered with the main trigger, the entered data went through the first DMN as variables. As described above, the input is checked against predefined rules/criteria and then a decision is made as to whether the request is accepted or rejected automatically or provisionally.
In case of a rejection, which is what the trigger represents, this Make scenario is triggered. Again, since we were struggling with a variable, we forced it to be a string with the method "toString()". Finally, the system automatically sends the employee an email telling him or her that the request has been rejected.
The following image sets up the make process:
This is an example of the automatically sent mail:
→ Link to Make scenario 3
After the first Make scenario was triggered with the main trigger, the entered data went through the first DMN as variables. As described above, the input is checked against predefined rules/criteria and then a decision is made as to whether the request is accepted or rejected automatically or provisionally.
The following image sets up the Make process:
This is an example of the automatically sent mail:
→ Link to Make scenario 4
After an absence request has been definitively approved, the trigger in a new Make scenario will send an HTTP request to the camunda workflow. This scenario is the first step of two, which will continue in the following scenario named "Send Confirmation to HR and Employee".
Because we require a signature from the manager to finalise the absence request approval, we created a Make scenario that generates a document from a google docs template with the following information:
→ Link to the absence request approval template
This is a template that can take variables and generate a new document based on the data. All variables indicated as {{value}} can be replaced with data selected in the make scenario. After this document is created, the new document contains the information about the approved absence request and is automatically uploaded to a dropbox location.
After this document exists on dropbox, the manager has to sign it with an e-signature. For this, we are using the signing feature of dropbox itself. To accomplish this, the manager has to open the respective pdf and click on "add signature" to sign it.
The manager has the option to add a signature by drawing, typing or uploading a picture to the document
Once added, the manager can place the signature on the indicated line. The document will be saved and have the suffix "[signiert]" added to the document title.
The new signed document now has to be manually moved into a new folder named "Signed_Absence_Requests"
→ Link to Make scenario 5
This scenario is triggered once a new PDF file has been manually moved to the "Signed_Absence_Request" folder on dropbox.
The scenario will then download the respective file and send out an email with the following message and the signed PDF file as an attachement:
The second gmail module in the scenario will send out an email to HR with the request to update the team schedule with the data from the absence request:
In addition to the BMPN and DMN models and the Make scenarios, we also developed other artifacts that are needed for automation. They are an integral part of the overall process. They are briefly described and shown in the following subsections.
The Google Forms indirectly represents the trigger for the overall process. The information is stored in an associated Excel sheet, which ultimately triggers the overall process:
This Google Sheet is the direct trigger of the overall process. As soon as an employee fills in and submits the Google Forms described in the previous chapter, the data entered is saved in the form of a new row in this Google Sheet:
_few%20examples.png)
This Google Sheet is used for the user task "check team schedule". The manager has to check the capacity in the team schedule:
If the manager has to additionally check the project schedule (prov-approved request and team capacity is ok but not definite) then they must consult their project plan:
This Google Doc is used once an absence request has been approved. The scenario "04_Confirm and Sign HR" generates a PDF based on this template and replaces selected variables with the data from the request. The PDF is then moved to Dropbox for a signature:
→ Link to the process recordings
This video file contains some recordings of the processes as a back-up for the presentation.
For this project we had a very specific context with the traditional watchmaking company that want to improve its processes, especially the absence request. Pain points were quickly identified (paper-based, non-digitized processes with many time-consuming manual tasks) and objectives were built on them (digitization of the process, offering an automatic scenario and more time for managers). These objectives have been achieved with the To-Be process presented in chapter 4 and the Make scenarios explained in chapter 5.
While the As-Is process is very manual and happens mostly on paper, we aimed to automate some steps completely, such as the auto-reject scenario. Therefore, managers must only handle absence requests that do not fulfil the formal requirements, e.g. taking too many days off or not being eligible for a specific type of absence. And finally, when an absence is approved, the manager can sign the approval document electronically.
The "check team schedule" step remains manual because the google sheet containing the yearly team schedule is built quite complex and is unsuitable for looking up specific values. Future improvement could be to write a custom query to specify the date range of the absence request, identify the employee number and check the capacity simultaneously.
Also the "check project situation" step is a user task due to its complexity. While the second user task "sign approval document", has to be done manually due to legal reasons.
In the interests of continuous improvement, future work could attempt to further reduce the remaining manual tasks, and offer the possibility of tracking all approved requests to enable HR to analyze these absences, e.g. in a tool like a team tracker. Lastly another improvement for the future could be to introduce an innovative solution that integrats the coompany's ERP system with a user-friendly interface accessible to all employees, e.g. by incorporating fingerprint recognition for secure login, employees can easily request leaves of absence while conveniently checking their remaining vacation days.
Finally, we encountered problems with the flow of data in the workflow. When testing with data inputs, the scenarios in Make often processed old requests and we had to find out where the data was stuck several times. Often, we had to set up a module again or run the process until everything was up to date. But even with those measures in place, there were still issues that we were not fully able to solve.
Modeling the BPMN and DMN in Camunda Modeler went well at the beginning, although we were sometimes irritated by the many IDs and other fields that could potentially have been filled in. But what really caused us a lot of trouble was to understand the correlations with Camunda Modeler and Make. Thanks to successful coaching and the good "hands-on" tutorials on GitHub, we understood it better and better and were able to finish our group work successfully.
As mentioned in the section 7.1, we did have several issues with Make, often struggling with old data being stuck in the pipeline and making it difficult to test properly. We still struggled with this challenge until the end, even though we have been able to fix this issue several times in the past, it still causes issues up to date.
It was a very interesting and instructive module, where we were able to get to know many DevOps and other programs in more detail. We also think that we understood the topic of "digitalization and automation" a lot better. As this is a very topical subject in today's world, we will now be optimally prepared for possible points of contact in our respective companies.