GW
HomeWorkAboutNotesStackLab
Experience atOmnicom Group

Driving financial systems and automation across global teams.

Builder ofEnterprise AI Systems

AI agents, audit workflows, and decision intelligence at scale.

Based inNew York City

Building systems for enterprises around the world.

HomeNotesWorkAboutStackLabPartners
XLinkedInGitHubEmailllms.txt
© 2026 · New York City
All enterprise work

Platform & data case study

Planning model and cube engineering.

Finance planning structures that connect cubes, dimensions, mappings, and user-facing views to real business processes.

IBM logoIBM Planning AnalyticsIBM logoTM1Cubes and dimensions
Ask the project copilotGrounded in this public-safe case study.

Business problem

What people needed to solve.

Planning models decay when the cube, dimension, and rule structure stops matching how finance actually plans, leaving fragile views, unclear ownership, and slow change cycles. Small edits then carry outsized risk because there is no clear validation step before a change reaches users.

Decision frame

Questions the work needed to answer.

  • Which dimensions and cubes support the planning process?
  • How does an input move into a usable finance view?
  • What must be validated before a change reaches users?
Interactive operating flowSelect any node for context or ask the AI guide.

Selected Operating layer

Planning model + cube engineering

Built and maintained planning cubes, dimensions, mappings, and calculation logic around core finance drivers, with distinct technical and finance ownership and a validation step before any model change is released to users.

Implementation

From the business problem to a working operating model.

Built and maintained planning cubes, dimensions, mappings, and calculation logic around core finance drivers, with distinct technical and finance ownership and a validation step before any model change is released to users.

  1. 01

    Designed planning structures around core finance drivers.

  2. 02

    Maintained dimensions, mappings, and model logic with change discipline.

  3. 03

    Created user-ready views aligned to planning activities.

Controls, approvals, and delivery constraints

The work around the work.

Enterprise systems change only when data, access, testing, ownership, and evidence move together.

  • Model changes require validation before wider use.
  • Technical and finance owners have distinct responsibilities.
  • No cube structure, calculations, or proprietary planning logic is disclosed.

Prior art

How leading teams approach this.

Public references for the same class of problem, so this work can be read against how other organizations are building it.

IBM

How Novolex contains its timelines

Novolex closed the gap between sales and production plans by unifying forecasting on one IBM Planning Analytics model, showing the payoff when model structure tracks the real process.

IBM

Revolutionizing budgeting and planning processes for a retail giant

Landmark Retail scaled one Planning Analytics model to budgeting, consolidation, and CAPEX across 1,200-plus stores while improving governance and transparency, an example of disciplined model extension over time.

Public-safe outcome

The planning structure stays aligned to finance processes and is traceable for technical owners, so change cycles are more predictable and user-facing views hold up as the model evolves.