Parallel Operations — Sophia Guo

Why this matters

Think of it like cooking dinner

When you make a meal, you don't wait for the rice to finish before you start chopping vegetables or heating the pan — you run those tasks at the same time. That's the only way dinner lands on the table on time.

A factory floor works the same way — many operations can run in parallel — but Oracle's software could only describe work as a single-file line, like a kitchen forced to cook one dish at a time. The result: overstated timelines, idle machines, and engineers hacking workarounds to match what their floor already did.

My job: let manufacturers describe parallel work honestly — and make that tangled logic simple enough to read at a glance.

First, a quick primer

A few terms in plain English — skip ahead if you know the domain.

Work Definition: The template that defines how a product is manufactured — the operations, items, and resources required to build it.
Operation: A single step in a Work Definition — cut, weld, paint, package. The thing that can run one at a time or in parallel.
Manufacturing Engineer: My primary user — responsible for creating and managing the exact steps, materials, and resources required to manufacture an item or batch.

01 — The Challenge

Breaking the Sequential Bottleneck

In electronics, furniture, and packaging, many operations should run in parallel — but Oracle's Work Definition modeled everything sequentially, forcing workarounds that distorted data and inflated timelines.

Users were setting "one-minute lead times" to trick the software into allowing parallel starts — a sign the product had a real gap to close.

Sequential Execution vs Parallel Execution diagram

Sequential vs. parallel execution — the same operations take significantly longer when forced to run one at a time.

Business Impact

Inflated Lead Times Parallel tasks modeled sequentially artificially extended production — a 2-hour process showed as 6 hours.
Resource Inefficiency Labor and equipment sat idle during "sequential" steps that could run simultaneously.
Clunky Workarounds Users set "one-minute lead times" to trick software into allowing parallel starts — a signal the model was fundamentally broken.

The Goal

Design a solution allowing manufacturing engineers to specify which operations run in parallel — based on dependency relationships between operation start and completion — without compromising data integrity or established workflows.

02 — Research

Understanding the Users

I consulted Oracle Cloud Customer Connect for peer feedback and mapped the experience across three distinct user types — each with different needs and contexts around parallel operations.

Customer evidence — Oracle Cloud Customer Connect

This wasn't a hypothesis. Manufacturers requested parallel operations as far back as 2018, and again in 2020 — real production lines run steps simultaneously, yet the system forced them into sequential routings. Oracle credits the shipped capability directly to that demand: it ships officially labeled “from a customer submitted idea.” The actual threads, and the insight I pulled from each, are below.

Oracle Cloud Customer Connect feedback threads with my design insights annotated

Real requests from Oracle Cloud Customer Connect — peer feedback that surfaced the parallel-operations gap, paired with the insights I pulled from each.

Three user types: Planning, Scheduling, and Execution

The parallel operations experience spans three roles — from the engineer authoring Finish-to-Start vs. Start-to-Start dependencies, to the supervisor monitoring parallel branches, to the operator who needs the next startable operation surfaced instantly.

03 — Design Principles

Four anchors before sketching a single frame

Before exploring any solutions, I established four guiding principles to keep every design decision tethered to real user needs.

1

Wayfinding Provide clear visual cues for the "next step" in a complex, multi-stage setup.

2

Context Awareness Help users orient within the macro-process even while deep in micro-tasks.

3

Clear Workflow Visualization Make non-sequential flows easy to digest — highlight dependency types and transfer percentages.

4

System Validation & Error Handling Proactively catch circular dependencies and invalid sequences with clear recovery paths.

04 — Information Architecture

The Operation Dependencies Tab

I restructured the Work Definition experience to accommodate new data points without overwhelming existing users. The solution centers on a new dedicated tab that introduces three new relationship types:

Finish-to-Start

The previous operation must complete before the next one can begin — the traditional sequential model.

Start-to-Start

A scheduling dependency where the next operation can start as soon as the previous one starts — enabling true parallelism.

Transfer Percent

The percentage of completed quantity that moves to the next operation — enabling accurate yield calculations across parallel branches.

The Operation Dependencies tab — a datagrid for authoring parallel relationships

A new Operation Dependencies tab in Work Definition — each row authors one dependency between two operations, with its type, transfer percentage, and dates.

Finish-to-Start vs. Start-to-Start dependency comparison

Finish-to-Start keeps operations sequential and moves completed quantity forward; Start-to-Start is a scheduling link that lets the next operation begin in parallel, with no quantity movement.

05 — Exploration

Navigating the Redwood Design System

The core challenge: balancing the user's need for a robust, interactive flowchart against the technical boundaries of Oracle's Redwood Design System. Oracle requires consistent UI across the SCM suite, which means using existing, tested components over custom code.

I explored four low-fidelity architectural options, each representing a different tradeoff between authoring power and visual clarity:

Three wireframe options for visualizing operation dependencies

Early wireframe exploration — three distinct approaches to surfacing the dependency diagram.

Option 1 — Diagram + Bottom Drawer

Focus on the flow with a read-only data grid visible below — keeping both views in context simultaneously.

Option 2 — Diagram + Properties Panel

A side configuration drawer for real-time editing alongside the visualization — authoring and validating in one place.

Option 3 — The In-Tab Canvas

A large diagram opened in a drawer directly from the Operation Dependencies tab — keeping the diagram within the same page context.

Option 4 — The Toggle Approach

Switch between "Data Authoring" and "Visual Model" views — reducing cognitive load by separating concerns.

Redwood Office Hours — Three Critical Constraints

1

Release Readiness The Configuration Drawer component wasn't available until the following quarter — eliminating Option 2.

2

Performance Limits Large drawers caused significant latency with complex manufacturing datasets — ruling out any drawer-based approach.

3

Template Fidelity The Toggle idea deviated from established Redwood guidelines, risking inconsistency across the SCM suite.

Option 5 — A Dedicated Operation Dependencies Page

Where the constraints pointed: pull the diagram out of any drawer or toggle and give it its own page, separate from the datagrid.

Pros

Best for performance — no heavy in-page drawer
Most feasible for development
Enables a "tear-apart" view for authoring and viewing — each can open in its own browser window. From office hours: most enterprise customers run two monitors, so they can keep the datagrid and the canvas side by side.

Cons

Two separate pages mean two separate REST services
Requires saving the data after each change — so the save behavior has to be crystal-clear and feasible for development

The Final Strategy

Constraints shifted focus from "interactive editing" to "visual validation." The diagram's primary value isn't authoring — it's giving manufacturing engineers a sanity check for the data they've already entered in the grid. This reframing unlocked the dedicated Canvas Page approach.

Save / Save and Close flow — validating the data grid, opening the dependency diagram in a new browser tab, fixing setup errors, and refreshing the diagram only after the grid is saved

Mapping the save behavior — 'Save' / 'Save and Close' triggers data-grid validation; the dependency diagram always opens in a new browser tab and can only update after the grid has been saved.

06 — The Solution

Bridging Data and Visualization

The final design pairs two complementary surfaces: a structured datagrid for authoring parallel relationships, and a dedicated canvas page for visual validation.

Adding a dependency by hand in the Operation Dependencies tab — one row per relationship.

01

Principle: Context Awareness

Adding Dependencies by Hand

A new "Operation Dependencies" tab in Work Definition gives manufacturing engineers a structured space to author relationships one row at a time — each row links two operations with a Finish-to-Start (sequential) or Start-to-Start (parallel) relationship and a Transfer Percent for the quantity moving between them.

Initialize auto-fills the table from the operations already defined — sequential by default, ready to edit into the real parallel structure.

02

Principle: Head Start over Blank Slate

Initializing from Existing Operations

If an engineer has already defined their operations in the Operations tab, the Initialize action auto-populates the dependency table for them — laying every operation out sequentially as a starting point. From there they only edit what actually runs in parallel, turning a blank grid into a head start.

The diagram opens in its own tab; edits to the grid flag it stale until refreshed.

03

Save Behavior: Protecting Data Integrity

Because the diagram opens in a separate browser tab, I designed a strict save flow to handle the state between the two views. When a user edits the datagrid after opening the diagram, the diagram is flagged as stale and must be refreshed — so engineers always validate against the latest authored data, never a cached snapshot.

Invalid dependency state — circular loops and bad transfer percentages surface clearly with recovery guidance.

04

Principle: System Validation & Error Handling

Proactive Error Validation

Parallel logic introduces risks invisible in a standard grid — circular dependencies, multiple last operations, transfer percentages that don't sum to 100%. I worked with developers to categorize every client- and server-side error, then designed banners and inline messages that explain exactly what's wrong and how to fix it. The diagram turns red for invalid nodes and renders the problematic edges in a distinct error color, making issues unmissable at a glance.

Cross-Product Impact

Designing for the Entire Ecosystem

The project didn't end at Work Definition. Parallel dependency data is only useful if it's visible to the people executing the plan — so I worked with each downstream team to surface it in their own workbench, in the format their role actually needs.

Work Orders Management showing parallel operations

Work Orders — Accurate Scheduling

I surfaced Start-to-Start relationships directly in the work order list, so the scheduled duration reflects true parallel-adjusted lead time instead of inflated sequential totals.

Production Supervisor Workbench with parallel operations

Supervisor Workbench — Real-Time Monitoring

I added a parallel-status indicator that flags when a concurrent branch is lagging, so supervisors can intervene before it affects operations waiting on it.

Operator Workbench showing which operations can start

Operator Workbench — Clear Task Prioritization

The task list promotes any operation the moment its Start-to-Start dependency is satisfied, so operators always know the next task to start without interpreting ambiguity.

07 — Impact

Results

Closed a major product gap Enabled support for 100% of parallel-operation manufacturing workflows, eliminating a major product gap for customers with split-and-merge production processes.
Cut manual cost reconciliation Reduced manual cost reconciliation by an estimated 30–50% by automatically calculating cost transfers across parallel operations.

Made work-in-process costs traceable Improved traceability of work-in-process costs by introducing visual representations of operation dependencies and cost rollups.
Extended the costing engine Extended Oracle's costing engine from sequential-only to complex parallel flows, across both discrete and process manufacturing.

08 — Reflection

What I learned

01

Innovation Through Constraints

Redwood's constraints filtered better decisions. The push for interactive side-by-side editing gave way to a streamlined "validation-first" approach — cleaner and more focused than the original idea.

02

Bridging the "Reality Gap"

Sequential modeling turned a 2-hour process into 6 — a vivid reminder that in SCM, UX accuracy is operational accuracy. Restoring parallelism killed the workarounds and gave engineers their time back.

03

Visualization as Validation

Complex logic needs a visual error-checker. Reframing the diagram as validation let engineers catch circular dependencies and multiple last operations — impossible to spot in a raw data grid.

Parallel Operationsin Work Definition