01 · EXECUTIVE SUMMARY
Redesigning a report that already had the data it needed

The New Business Partners team tracked operational effort across support functions — IT, Accounting, Credit, Legal, and others — directly in Jira, which Accounting then used to calculate SLA costs. But the reporting process itself relied on manually copying and consolidating that data every cycle, which was slow and left room for error. I redesigned the process to pull from Jira directly into a structured, pivot-table-based reporting model — turning a rebuild-from-scratch report into a refresh-and-go one.

02 · BUSINESS CONTEXT
Good data, inefficient path to the report

The operational effort data Accounting needed already existed in Jira — support functions logged their time there as part of normal workflow. The problem wasn't data availability; it was that the reporting process hadn't been built to use that data directly, so every monthly cycle repeated the same manual consolidation work.

03 · STAKEHOLDERS
The team producing the data, and the team consuming it
  • Accounting — the primary report consumer, responsible for applying cost rates and using the output for profitability analysis.
  • New Business Partners team — owned the underlying process and reporting requirements.
  • Support functions (IT, Credit, Legal, and others) — the source of the operational effort data being reported on.
04 · BUSINESS PROCESS
Before and after, side by side

Before: Accounting manually extracted operational effort data, performed manual calculations, consolidated everything into reporting sheets, and prepared the final report — every single cycle, from close to scratch.

After: operational effort data flows from Jira directly into a structured pivot-table model. Accounting refreshes the report by replacing the latest Jira export and refreshing the pivot tables — the underlying structure and logic stay intact.

05 · BUSINESS QUESTIONS
What the redesign needed to solve
  • How much of the monthly reporting cycle is manual rework that a structured data model could eliminate?
  • Can Jira's existing operational effort data feed the report directly, without manual restructuring first?
  • What additional level of reporting detail — by employee, support function, country — would actually be useful to Accounting?
06 · DATA UNDERSTANDING
Jira effort logs, Accounting cost rates

Primary source: Jira operational effort data. Supporting data: Accounting-provided hourly cost rates, the existing reporting template, and support-function metadata. The raw material was complete — the redesign was about restructuring it into a reusable analytical model instead of a one-off manual export.

07 · ANALYSIS
Mapping the manual steps before removing them

The existing workflow was reviewed step by step to identify exactly which activities were manual and where they introduced risk: filtering exported records to the reporting scope, removing null or incomplete entries, validating support-function assignments, and consolidating data across multiple exports before any calculation could happen.

08 · KEY FINDINGS
The bottleneck was structural, not a skills gap
FINDING 1

The report was rebuilt from scratch every cycle instead of being refreshed from a persistent data model — every month repeated the same manual consolidation work.

FINDING 2

Reporting granularity was limited by the manual process itself. Breaking costs down by employee, support function, and country wasn't technically hard — it just wasn't practical to do by hand every month.

09 · ROOT CAUSE ANALYSIS
No reusable model between the source and the report

The root cause wasn't the data source or the cost-calculation logic — both were sound. It was the absence of a structured reporting model sitting between Jira and the final report. Without one, every cycle required rebuilding that link by hand, which capped both the process's efficiency and the level of detail Accounting could realistically request.

10 · RECOMMENDATIONS
Build the model once, refresh it monthly
  • Use Jira as the direct source for the reporting model, rather than a manually consolidated intermediate file.
  • Structure the data across three dimensions — Support Function, Individual Employee, and Country — so Accounting could analyze cost at both summary and detailed levels.
  • Build the reporting layer in pivot tables specifically so it could be refreshed by replacing the latest export, not rebuilt.
  • Validate and document the new data model so it could be maintained by Accounting without requiring the original builder each cycle.
11 · BUSINESS CASE
Less manual work, more reporting depth, same accuracy

The redesigned process reduced the manual effort required for monthly SLA cost reporting, minimized the risk of reporting errors introduced by manual consolidation, and increased reporting granularity — all while keeping the underlying cost-calculation logic Accounting already relied on. The recurring reporting cycle went from rebuilding a report to refreshing one.

12 · DASHBOARD
A reporting model, not a single chart

The deliverable here was the pivot-table-based reporting model itself — structured across Support Function, Employee, Country, Operational Effort (Hours), and Operational Cost — rather than a single fixed dashboard view. That structure is what let Accounting explore the data from multiple angles without rebuilding anything.

13 · LESSONS LEARNED
Automation isn't always about new tools
  • The highest-leverage fix used data that already existed. No new tracking was added — the win came entirely from restructuring how existing data reached the report.
  • Pivot tables were the right tool because the goal wasn't a static summary. Accounting needed to explore cost from multiple angles, and a flexible analytical layer served that better than a fixed report template.
  • A redesigned process only sticks if someone other than the builder can maintain it. Documentation and a clear refresh procedure mattered as much as the model itself.