Case study | enova365

One day, many events. How enova365 development streamlined complex time tracking processes at a financial institution.

  • Client
    Large financial institution
  • Industry
    Financial services
  • Country
    Poland
  • Solution
    enova365 – time tracking and accounting
  • Duration
    6 months

Project description - enova365 development for time tracking and accounting

The enova365 development project for a large financial institution employing more than 3,000 people focused on improving time tracking and accounting. Over six months, the work covered 15 interconnected processes, including business trips, remote work, personal time off during working hours, overtime and hourly leave requests.

In an organization of this size, the challenge is not only to handle individual employee events correctly, but also to maintain consistent data across employee calendars, attendance records and time accounting. A change in one process may affect several others. This is why the entire working day, rather than an individual form or request, had to serve as the point of reference.

What does this look like in practice? Consider a single employee’s working day.

An employee starts the day working remotely. Later, they take time off for a personal errand, go on a business trip and, after returning, work beyond their scheduled hours.

Each event makes sense on its own. The complexity emerges when all of them occur on the same day and affect the same time records.

Remote Work
Personal Leave
Business Trip
Overtime

The challenge - how to ensure consistent time tracking in enova365

Individual user requests did not reveal the full complexity of the process. Only when considered together did they show how closely the events recorded in enova365 were connected.

Initially, the requirements concerned specific processes: business trips, attendance lists, remote work, overtime and hourly requests. It soon became clear, however, that these processes could not be developed independently.

Changing how business trips were handled affected attendance records. Adjusting the start time of a working day could change overtime calculations. Allowing multiple events to be recorded on the same day also required clear rules for identifying genuine scheduling conflicts.

At that point, a list of isolated changes was no longer enough. A common model was needed to define how the system should interpret an employee’s entire working day.

From individual request to consistent time accounting

At the level of individual requests, users’ expectations were clear and specific. Meeting them, however, required checking what would change elsewhere in the time-tracking process.

An employee should be able to submit several requests for the same day. A business trip lasting only a few hours should be recorded correctly. A personal absence should not lead to incorrect attendance calculations. Overtime should reflect the hours actually worked.

Each of these requirements could be treated as a separate development task. But one question quickly arises: what happens to the other processes once the change is introduced?

This is where analysis becomes more important than implementation alone. Rather than asking only how to modify a particular feature, the first step is to establish which other parts of the system depend on it.

The solution and project delivery - scenario analysis and enova365 development

The BPX team adopted an approach based on analyzing real employee scenarios. Instead of starting with a list of modifications, the team examined how successive events affected time tracking and accounting.

This approach helped establish not only the scope of each change, but also its consequences for related functionality.

In this project, we did not limit our analysis to a single request. We reconstructed the employee’s entire day: from the start of work, through subsequent events, to the end of the working day and its eventual accounting.

1
SCENARIO
What actually happens throughout the workday?
2
DEPENDENCIES
Which processes and data are affected by the change?
3
RULES
Which rules should work together?
4
TESTING
Does the change also work correctly alongside other events?

As a result, seemingly unrelated issues began to form a coherent picture.

Only then was it possible to define the rules for the solution.

In one area, an additional validation rule was needed. Elsewhere, the workflow had to change. In another case, data had to be recalculated using information already stored in the system.

The key was to avoid creating isolated exceptions. Every change had to fit into the shared logic of the overall process.

Specific examples illustrate this best. In each case, the issue began with a seemingly simple action, but resolving it required taking other events from the same day into account.

Hourly requests in enova365 - how to identify genuine time conflicts

Hourly requests are a good example of a dependency that requires precise validation.

An employee takes childcare leave from 9:00 a.m. to 11:00 a.m. and later makes up for an earlier personal absence between 3:00 p.m. and 5:00 p.m.

Both events occur on the same day. That does not mean they conflict.

If the system checks only the date, it may block the second request. If it considers the actual time intervals, it can correctly recognize that both events can coexist.

The goal was not to add an exception for one form. A more universal rule was needed: for hourly processes, sharing the same date is not enough to establish a conflict.

The same approach can then be applied to other scenarios.

Distinguishing between events that share a date and events whose hours actually overlap illustrates how a precise rule can replace an ad hoc form restriction. In other processes, the crucial factor was the accurate reconstruction of working hours.

Personal absences – recording the actual working day

For personal absences during working hours, it is important not only to establish the period of absence but also to reconstruct the remaining working time correctly.

An employee starts work at 8:00 a.m. At noon, they leave for two hours, then return and continue working.

8:00 a.m. – 12:00 p.m.
WORK
12:00 p.m. – 2:00 p.m.
PERSONAL TIME OFF
2:00 p.m. – 4:00 p.m.
WORK RESUMED

Recording the absence alone is not enough. The system must also know when the employee actually started work. Otherwise, it may rely on the schedule and produce an inaccurate picture of the day.

This affects more than the calendar. It may change the calculation of required hours, overtime and subsequent time records.

That is why our analysis does not stop at the point where a user performs an action. We also examine where the same data will be used later.

Recording a personal absence is therefore only one step. The solution is also judged by whether the remaining data correctly reflects working time before and after the absence. Similar dependencies arise when accounting for business trips.

Business trips in enova365 - links to attendance and time accounting

Business trips introduce even more dependencies. A trip may last the entire day, but it may also begin after several hours of regular work. It may end early, allowing the employee to return to their usual duties.

In such cases, simply marking the day as “business trip” does not reflect what actually happened.

The start and end times of the trip matter, as does what happened before and after it.

If a business trip covers only part of the day, the remaining time must also be accounted for correctly.

If the employee continues working after returning and exceeds the applicable working-time limit, another dependency arises: overtime.

This is why business trips could no longer be analyzed as an entirely separate process. They had to be incorporated into the broader logic of working time. Only then could their interaction with attendance, other events and the final accounting of the day be defined.

Overtime – why the entire working day matters

An employee reports working from 4:00 p.m. to 6:00 p.m. At first glance, that looks like two hours of overtime. Not necessarily.

First, we need to know what happened earlier. Did the employee complete their standard working hours? Did they take partial-day leave? Was part of the day spent on a business trip? Did they take a personal absence? What is their daily working-time norm?

Without that context, the system knows the hours but does not yet have all the information needed to classify them.

Overtime accounting must therefore use data about the time actually accounted for, rather than operate alongside it as a separate process. Different processes cannot maintain their own independent versions of the same employee’s working day.

These four examples reveal different sources of complexity: overlapping time intervals, actual hours of attendance, partial-day business trips and overtime classification. What they share is the need for consistent data and common interpretation rules across the process.

 

Consistent rules for time tracking and accounting

At this stage, the project begins to look different. The goal is no longer to assign a separate fix to each request. The employee’s actual working day becomes the point of reference.

Each new requirement can then be assessed using a similar set of questions:

What is already recorded in the work calendar?Do we know the employee’s actual start time, absences, or other recorded activities?
What time period does the new event cover?Does it actually overlap with any existing entries?
How does it affect the employee’s working time requirements?Is it classified as working time, an absence, or an event subject to different time-accounting rules?
What happens after the event?Does the employee continue working, finish their workday, or potentially accumulate overtime?
Where does the information flow next?To the work calendar, approval workflow, payroll, reporting, or employee working time records?

This structure makes it possible to assess new requirements against the rules of the entire solution, rather than designing another exception each time.

For common rules to be implemented correctly, they had to be translated into unambiguous requirements. A general user expectation does not always specify how the system should behave in a particular sequence of events.

Requirements analysis in enova365 – from request descriptions to employee scenarios

With processes this interconnected, precise requirements are essential.

The statement “an employee should be able to submit several requests on the same day” leaves considerable room for interpretation. A specific scenario is far more informative:

An employee starts work at 8:00 a.m., takes childcare leave from 10:00 a.m. to noon, returns to work and then works overtime from 4:00 p.m. to 6:00 p.m.

This immediately allows us to check which intervals appear in the calendar, whether the working-time norm is met and when overtime can actually begin.

The same applies to business trips. Knowing that a trip took place is not enough. Its start and end times, work performed before departure and after returning, and the accounting of each stage all matter.

A precisely documented scenario reduces the risk of the client, consultant and developer interpreting the same requirement differently.

These scenarios also served a practical purpose during testing: they made it possible to verify whether the agreed rules worked both individually and in combination with other events.

 

Testing - verifying changes across the entire time-tracking process

A change could work correctly in one form yet still cause errors in the calendar or report. Verification therefore covered not only the functionality itself, but also its consequences at subsequent stages. More than 200 test cases were prepared for the project.

Implementation is only one stage. If a change allows multiple events on the same day, testing cannot end once the second request has been saved successfully.

How do both events appear in the calendar afterward?

What happens if one of them is cancelled?

Is the working-time norm still calculated correctly?

How does the overtime calculation change?

What appears in the final report?

These combined scenarios are particularly important when testing major changes. An individual feature may work correctly. Problems often arise only when it interacts with another feature that also works correctly but uses the same data.

That is why we test more than the change itself. We test its place in the entire process.

Verification therefore did not end with a request working correctly. It also covered the result seen by users and HR after the event passed through subsequent stages of time tracking and accounting.

Time records – final verification of data consistency

The employee time record is a useful test of the overall solution. It should present the final picture of the working day.

If an employee has several different events, the time record should reflect what actually happened. Personal absences, business trips, on-call duties and hourly leave cannot exist only within their respective forms. They must remain consistent at the end of the process as well.

Equally important is what the record should not show. Work scheduled for a future day is not work that has already been performed.

The final report is therefore not independent of the preceding stages. Its accuracy depends on the quality and consistency of data collected earlier in the process.

 

Client benefits - over 50% fewer manual employee calendar corrections

The most measurable outcome of the project was a reduction of more than 50% in the number of manual employee calendar corrections performed by HR. This figure refers specifically to those corrections, not to the HR department’s total workload. The changes also helped organize the handling of interconnected events and improve the consistency of data used in subsequent time-tracking and accounting stages.

This matters particularly in an organization employing several thousand people: recognizing events correctly when they are recorded reduces the need for later manual clarification and calendar corrections.

Key takeaways – how to develop HR processes in enova365

A single validation rule or an additional field may still be a minor modification. The situation changes when successive requirements use the same data and affect one another.

Solving one problem without considering the remaining dependencies may then create another.

That is when the backlog stops being a list of independent items. It becomes necessary to identify a shared logic.

In this project, the common denominator was the employee’s actual working day. It provided the basis for organizing events, validation rules, dependencies and subsequent time accounting.

The outcome does not necessarily have to be another button or form.

Often, what matters most is what users no longer need to do:

delete a correct entry just to add another one;

ask HR to correct the calendar manually;

reconstruct the working day from several separate documents;

approvers receive more context.

HR and payroll teams use data that has already been structured earlier in the process.

At this scale, changes like these can make the greatest difference.

Conclusion – consistent time tracking starts with a single working day

Time tracking shows how several seemingly minor requirements can develop into a much larger project.

A business trip, personal absence, remote work and overtime are separate events. Only when combined do they reveal how much depends on common system rules.

The central question then stops being “how do we add another feature?” What matters more is defining the rules that should apply throughout the process so that the next requirement does not demand yet another exception.

A well-designed solution does not eliminate business complexity. It brings order to it.

Above all, users should see the result: a system that reflects their actual working day without requiring them to understand all the dependencies operating behind the scenes.

 

Here you will find expert support on enova365

Learn more

See other case studies

  • Full SAP S/4HANA Private Cloud Transformation for a Leading European Chemical Group

    Full SAP S/4HANA Private Cloud Transformation for a Leading European Chemical Group

    Read more

  • Intelligent Product Classification Using AI

    Intelligent Product Classification Using AI

    Read more

  • SAP Implementation Case Study

    SAP Implementation Case Study

    Read more

  • SAP Integration for M&A Consolidation in the European Energy Sector

    SAP Integration for M&A Consolidation in the European Energy Sector

    Read more

Discover our capabilities

  • 20+ years of experience

    Since 2006 we have been helping our clients implement and develop systems and applications that streamline business processes. Owing to our know-how, our Partners are able to fully utilize the technologies of the future.

  • 1000+ completed projects

    We approach each project individually. We employ technologies that improve the enterprise functioning and management. The joint implementation of each projects brings our clients closer to perfection in managing a modern organization.

  • 500+ employees

    We have an appropriate team of experiences and qualified experts in many fields. Consultants, analysts, programmers and PMs. We have been successfully implementing even the most complex projects that streamline the development of organizations around the world.

  • 50+ countries where we have carried out deployments

    Based on our unique skills, we implement innovative projects around the world. We conquer new markets and constantly enter new areas. A comprehensive approach allows us to ensure the development of companies from numerous industries and sectors.

Contact us!

Let’s talk! Are you interested in our solutions? Our experts are happy to answer all of your questions.




    The controller of your personal date is BPX S.A., please see the Privacy policy for more detailed information regarding the processing of personal data by BPX S.A.

    Have a question? Contact us:
    +48 22 350 74 55