OneOperations

A CLI-first internal operations platform for making recurring finance and transfer-pricing workflows consistent, explainable, and easier to maintain.

Summary

OneOperations is an internal platform for centralising recurring finance and transfer-pricing processes across multiple entities and business activities.

It provides a consistent way to execute operational workflows, while allowing each workflow to use the architecture and processing pattern most appropriate for its own requirements.

The platform includes domain-specific workflows such as TaxFlow and Cost Plus Solution.

Status

Operations internal platform

This case study is anonymised and does not disclose company names, internal data, proprietary formulas, entity details, or confidential screenshots.

The problem

Before OneOperations, many operations were performed in Excel files that were not even standardised templates.

For each exercise, an analyst often had to understand how someone else had handled a similar case. The process was frequently undocumented or insufficiently annotated, which made it difficult to:

• reproduce previous work;
• distinguish business rules from individual judgement;
• apply the same approach across entities;
• onboard another analyst;
• implement changes consistently;
• understand why a particular output had been produced.

The problem was therefore not simply manual processing. It was the absence of a single, understandable way of doing things.

The architectural challenge

The most important question in each workflow was not which technology to use. It was how the process should operate.

Different workflows have different constraints, inputs, rules, and users. Applying one architecture everywhere would create unnecessary complexity in some cases and insufficient structure in others.

OneOperations therefore applies the most suitable architecture and operating pattern to each workflow.

This involves trade-offs between:

• convenience for the person running the process;
• clarity of the business logic;
• repeatability;
• maintainability;
• ease of explanation;
• the cost of introducing additional technical infrastructure.

Choosing the right process pattern is often the most consequential design decision in the entire workflow.

The operating model

OneOperations is CLI-first.

The command-line interface keeps the execution path explicit and makes it possible to define a consistent way of running each operation. The analyst should not need to rediscover how a previous person approached the exercise.

The expected operating model is straightforward:

1. the analyst performs a sanity check on the inputs;
2. the relevant workflow is executed using the defined process;
3. the outputs are reviewed;
4. changes to business logic are identified and communicated;
5. the workflow is updated when the underlying requirement changes.

This separates input judgement from business-logic implementation while keeping both connected.

My role

My role sits across both sides of the process.

I understand the finance and transfer-pricing requirements, perform the initial sanity checks, identify changes in business logic, and implement the corresponding workflow changes.

That means I can:

• translate finance requirements into explicit processing rules;
• choose an appropriate operating pattern for a workflow;
• implement and maintain the technical process;
• explain the process to non-technical users;
• identify when a requested change is a data issue, a process issue, or a business-rule change.

Being able to perform both the analyst and developer roles helps reduce the gap between what the business needs and what the system implements.

Designing for non-technical users

A process is not successful merely because it works technically.

It also needs to be understandable to the person responsible for running it. OneOperations therefore treats explanation as part of the system design.

A non-technical analyst should be able to understand:

• what inputs are required;
• what checks should be performed before execution;
• what the workflow is intended to do;
• what the outputs represent;
• when an unexpected result indicates a data issue;
• when a change requires an update to the business logic.

The goal is to make the process self-explanatory enough that it does not depend on private knowledge held by one person.

System model

OneOperations separates the main stages of a workflow:

1. inputs are collected and checked;
2. the workflow applies the relevant business and finance logic;
3. transformations and calculations are performed;
4. outputs are produced in a consistent structure;
5. results are reviewed against expected behaviour.

The exact architecture differs between workflows. TaxFlow uses configurable pipelines for tax-aware financial logic. Cost Plus Solution handles a different class of recurring transfer-pricing calculation.

The common principle is that each workflow has an explicit operating model rather than an informal collection of spreadsheet steps.

flowchart TD
    A[Analyst runs CLI workflow] --> B[Sanity-check inputs]
    B --> C{Choose workflow and architecture}

    C --> D[TaxFlow pipeline]
    C --> E[Cost Plus pipeline]
    C --> F[Shared-services workflow]

    D --> G[Apply domain logic and transformations]
    E --> G
    F --> G

    G --> H[Test implementation against expected behaviour]
    H --> I[Review outputs]
    I --> J[Execute operation]
    I --> K{Business-logic change?}
    K -->|Yes| L[Update workflow rules]
    L --> C
    K -->|No| J

Testing and risk control

Excel made it difficult to test the implementation of a business rule independently from the exercise being performed. In practice, this meant relying on the spreadsheet’s implementation without always being able to verify whether the logic matched the intended process.

OneOperations makes it possible to test the implementation against expected inputs and outputs. Bugs and unexpected behaviour can be identified earlier, before they affect a recurring operational process.

This improves the reliability of the workflow and makes it easier to execute the underlying finance or transfer-pricing strategy consistently. From a group tax and transfer-pricing perspective, testing also helps mitigate tax risk by reducing the chance that an incorrect implementation is repeated across entities or reporting cycles.

Controls and auditability

The platform is designed around repeatable and explainable processing.

Important controls include:

• input sanity checks;
• explicit business rules;
• consistent execution patterns;
• reviewable outputs;
• clear separation between data issues and logic changes;
• reproducible processing;
• testable implementations and expected outputs;
• documented assumptions where judgement is required.

The objective is not to remove the analyst from the process. It is to ensure that the analyst is reviewing the right things instead of reconstructing the entire process from scratch.

Outcome

OneOperations replaces person-dependent Excel processes with a single, reusable way of executing recurring operations.

It makes it easier to:

• run workflows consistently;
• onboard new analysts;
• identify changes to business logic;
• choose a suitable architecture for each process;
• explain operations to non-technical users;
• test business logic and identify implementation bugs;
• mitigate group tax and transfer-pricing risk;
• maintain shared finance and transfer-pricing workflows over time.

What I learned

The central lesson was that process design and architecture selection are more important than the choice of technology alone.

A technically sophisticated system can still be inconvenient, difficult to explain, or poorly matched to the people who need to use it.

The most effective workflow is the one that balances technical maintainability with operational convenience and business clarity.

OneOperations also made the gap between technical and non-technical work more visible. Building a reliable process requires not only implementing the logic, but also explaining it clearly and designing it so that the person running it can understand what is happening.

That combination of domain knowledge, architecture judgement, implementation, and explanation is the core value of the platform.