Amirali YaghoutiSenior Software Engineer

python Case study

Attendance / Office Automation

Attendance data is collected everywhere and used almost nowhere, because getting from a raw log to something a manager can act on involves several manual steps that nobody wants to own.

The business problem

The attendance and operational records existed but lived in incompatible files that someone had to reconcile before any question could be answered. That made routine management reporting expensive enough that it happened rarely and inconsistently, so decisions were made on impressions.

What I delivered

  • An automation flow that collects attendance and operational data and produces reporting without a manual reconciliation step.
  • Normalised inputs, so files arriving in different shapes from different sources become one consistent dataset.
  • Output structured for a business reader rather than for a developer, since the whole point is that management can use it directly.
  • Repeatable runs with logging, so a number in a report can be traced back to the run that produced it.

Technical approach

  • Normalisation is a separate, explicit stage. Most of the real difficulty in this kind of work is the input formats, and mixing that into the analysis makes both harder to change.
  • The output is designed for the person who reads it, which usually means a spreadsheet rather than a dashboard.
  • Runs are logged so that a disputed figure can be checked rather than argued about.
  • Scope stayed on the questions actually being asked, rather than building general reporting infrastructure that would need its own maintenance.

Result and evidence

Management reporting on attendance and operations became routine output rather than a task somebody had to be assigned.

Commercial value

Reporting that requires effort is reporting that stops. Removing the manual steps is what makes it survive contact with a busy month.

implementation-brief.readme

Readable implementation brief

implementation_brief {
  project: "Attendance / Office Automation"
  stack: "Python data workflow"
  stages: "collect -> normalise -> report, separated"
  output: "shaped for a business reader, not a developer"
  traceability: "runs logged; a figure can be traced back"
  scope: "the questions actually asked, not a platform"
}

What this project shows

The useful judgement here was scoping to the questions being asked. A general platform would have been more impressive to build and less likely to be used.

Separating normalisation from analysis is what keeps it working when a source system changes its export format, which it always does.