Skip to content
all work
Data· Client work · anonymized

Operations Analytics for Manufacturing

Hourly exports into Snowflake and two dashboards built as code, so stakeholders on a manufacturing and warehouse platform can see effective labor across operators and stages.

impactHourly — app data into the warehouse
Aurora PostgresS3KMSSnowflake

Problem

Stakeholders on a manufacturing and warehouse operations platform couldn't see effective labor across operators and stages, because the app reported one work item at a time.

What I built

An hourly export from the app's Aurora Postgres to a dedicated S3 bucket, encrypted with a customer-managed KMS key so the warehouse's cross-account role can decrypt it. Snowflake loads and stages the data.

Two dashboards, built as code through the BI tool's API: a 13-tile labor dashboard and a four-report pick and warehouse dashboard.

  app database (Aurora Postgres)
       │  hourly export
       ▼
  dedicated S3 bucket · customer-managed KMS key
       │  warehouse's cross-account role decrypts
       ▼
  Snowflake: load ──▶ staging layer
       │  dashboards read from staging only
       ▼
  dashboards as code: labor (13 tiles) · pick & warehouse (4 reports)

The metric

Effective time is session time divided by the number of concurrent tasks. That matches the app's own adjusted duration, so parallel work isn't counted twice.

Durations come from start and stop times. Operators come from timecard entries, because a stage's owner isn't always the person doing the work.

Incident

Loads had been failing for months after a new column tripped a strict column-count check. I traced it, fixed it, and rebuilt the production pipeline end to end.

The lesson: alert on failed loads, and map columns explicitly.

Decisions and tradeoffs

Code-first dashboards, so changes are reviewable and repeatable.

Dashboards read only from a staging layer.

BI load stays off the app database.