Overhauling Automation for a Public Utility Company

The challenge was on three fronts. First, it was non-existent essentials.

We discovered that critical modules were missing source codes. Instead of having access to the full set of code, the client only had executable files (.exe) built on Oracle. In essence, the client inherited a system that was difficult to maintain or improve. On top of that, documentation was missing. Admins of the modules failed to understand why certain functionalities behaved or failed the way they did.

Key actions taken –

• Reworking configurations: We worked with the client’s database administrators to break down complex database queries and troubleshoot issues in the code. We helped them decode the PL/SQL database, clear up anomalies and improve system stability.

• Rebuilding customizations: The software was originally designed for RMG factories, which we are reconfiguring to suit the needs of a public utility company.

The second front was that of deployment and data challenges. While software was a core focus, deployment-related issues also needed attention. We discovered a massive accumulation of data on the client’s servers. For example, user actions such as logging in and out of work triggered excessive data synchronization processes, leading to an unsustainable database bloat.

We noticed during the first month, the database size grew from 60 GB to 90 GB, and by the second month, it was over 120 GB, far more than what anyone had predicted. Attendance data alone consumed an additional 6 GB every month, which is immense given the actual employee count. A server request was 50 MB in size which we brought down to kilobytes.

We worked with the client to reduce unnecessary data by identifying and removing duplicate or irrelevant records. The system was made leaner by reducing the number of database partitions from six to three. This shrank the database size from 135 GB to just 35 GB, significantly reducing storage costs and securing provisions till 2028.

The last front is ensuring proper functionality of the existing modules.

Our client requested that the four modules be completely rebuilt. We addressed that starting from scratch could introduce new risks and complications. Instead, we recommended fixing the existing modules rather than rebuilding them entirely. This would allow them to continue using their current infrastructure while addressing specific pain points without the potential complexities of implementing a new system.

For example, the payroll module had over 20 pain points. We focused on resolving them incrementally. This approach helped avoid the introduction of new bugs or disruptions that often come with rebuilding systems.