Lumentum — Global Fixed Asset Register Standardization & AutoCap Implementation

Executive Summary

Lumentum Holdings, a global manufacturer of optical and photonic products spun off from JDSU in 2015, required a comprehensive overhaul of its Oracle Fixed Assets implementation to support consistent, auditable asset management across its global manufacturing footprint. The engagement addressed three interdependent challenges: standardizing the asset register data model across geographies, automating asset capitalization at the point of invoice or receipt (AutoCap), and deploying mobile scanning technology for barcode-based physical asset tagging.

The engagement followed Oracle's MD50 functional design methodology, with multiple Business Requirements Document (BRD) versions reflecting the iterative refinement typical of global standards projects where stakeholders across time zones must reach alignment before configuration begins. The fit-gap analysis reached version 4.0+ — an indicator of significant requirements discovery and scope refinement throughout the engagement.

The result was a globally consistent Oracle FA implementation with automated capitalization workflows, standardized location and asset category codes, and handheld device integration (Honeywell and Zebra scanners) for physical inventory — dramatically reducing the manual effort and error rate associated with annual asset verification.

Engagement Context

Lumentum's spin-off from JDSU created an immediate obligation to establish clean, auditable financial records as a standalone public company. The fixed asset register inherited from JDSU was inconsistent across sites: asset categories used different naming conventions, location codes were not standardized, asset descriptions were free-form, and the capitalization process varied by site. For a newly public company subject to SOX compliance, this was unacceptable.

AutoCap — the automated creation of Oracle FA assets from qualifying AP invoices or PO receipts — was a priority because the manual capitalization process was slow (assets were frequently not capitalized in the period of purchase), inconsistent (different sites applied different capitalization thresholds), and difficult to audit. Automating capitalization at the transaction source eliminated the lag and provided a clear, system-generated audit trail.

The mobile scanning requirement arose from the operational reality of managing assets across manufacturing facilities: physical asset verification using paper lists and manual lookups was time-consuming, error-prone, and produced results that were outdated by the time the audit was complete. Barcode-tagging all assets and enabling handheld verification against the Oracle asset register would make physical inventory an ongoing process rather than an annual ordeal.

Oracle Implementation Scope

Fixed Asset Register Data Standardization (FA)

The foundational work of this engagement was establishing a global data standard for the Oracle FA asset register. This encompassed: standardized asset category codes (with clear capitalization thresholds and depreciation method assignments), a global location code hierarchy (Country → Site → Building → Floor → Room), standardized asset description formats, and a data cleanse of the existing asset register to bring all records into conformance. The FA Register Data Standards document was the governing specification for all configuration and data remediation work.

Automated Capitalization (AutoCap)

AutoCap was implemented at both the AP invoice level and the PO receipt level. At the AP level, invoices coded to capital expense accounts meeting the capitalization threshold triggered automatic creation of FA mass addition records. At the PO receipt level, receipts of items with the capital item flag triggered the same process. Custom capitalization rules handled exceptions: partial capitalizations, project-funded assets, and leasehold improvements requiring manual allocation.

The Capitalized Asset Reporting (CAR) workbench was configured to provide finance managers visibility into pending capitalizations, approved assets, and exceptions requiring manual intervention — replacing spreadsheet-based tracking with an Oracle-native workflow.

Mobile Supply Chain Applications (MSCA) — Asset Tagging

Oracle Mobile Supply Chain Applications (MSCA) was configured to support barcode-based asset tagging and physical inventory verification. Honeywell and Zebra handheld devices were configured with the Oracle MSCA interface, allowing warehouse and facilities staff to scan asset barcodes and verify asset existence, location, and condition against the Oracle asset register in real time.

A global barcode labeling standard was established, defining label format, barcode symbology (Code 128), and the asset tag number format derived from the Oracle asset number. A custom concurrent program generated mass-print label files from Oracle FA asset records.

LITE Finance Manager Portal Integration

Integration with the LITE Finance Manager web portal allowed finance managers outside the Oracle environment to review AutoCap queues, approve pending capitalizations, and flag assets for excess disposition — without requiring Oracle EBS access, which was restricted to the finance team.

Methodology Applied

1. BRD Development (v1.0–v4.0+): Business Requirements Documents were developed iteratively through structured interviews with finance, operations, and IT stakeholders at each site. Each BRD version was formally reviewed and approved before the next iteration began. Version control of BRD documents was maintained throughout the engagement.
2. Fit-Gap Analysis (v4.0+): Oracle's standard FA functionality was mapped against each BRD requirement. Gaps were categorized and resolution approaches proposed. The fit-gap went through multiple versions as requirements evolved, ultimately reaching version 4.0+ — reflecting the genuine complexity of achieving global stakeholder alignment.
3. MD50 Functional Design: Oracle AIM MD50 functional design documents were produced for each major functional area: FA data standards, AutoCap rules, MSCA configuration, CAR reporting, and excess asset process.
4. Configuration and Unit Testing: Oracle R12 FA, AP, and MSCA were configured per the MD50 designs and unit-tested against representative scenarios from each site.
5. Pilot Deployment (Single Site): The full implementation — data standardization, AutoCap, barcode tagging — was piloted at one manufacturing site before global rollout, allowing real-world validation and process refinement.
6. Global Rollout: The validated configuration and process were rolled out to remaining sites with site-specific data cleanse and label printing operations.

Key Deliverables

Technical Architecture

AutoCap at the invoice level used Oracle's standard Mass Additions Create program, triggered by AP posting for invoices meeting capital criteria (account type = asset, amount ≥ capitalization threshold). A custom pre-processor evaluated invoices against the capitalization rules before creating mass addition records, handling split invoices, project-funded assets, and site-specific threshold variations.

MSCA operates over a wireless network using Oracle's thin-client architecture: the handheld device connects to Oracle's middle tier via the device's web browser, displaying Oracle forms optimized for small screens. Device configuration required Oracle system administrator setup of the MSCA responsibility, transaction menu, and warehouse/organization assignments. Wi-Fi coverage mapping at each site was a prerequisite — MSCA performance is highly sensitive to network latency.

Critical Challenges & Resolutions

Challenge 1: Global Stakeholder Alignment on Data Standards

Achieving consensus on a single global asset category taxonomy across manufacturing sites with different historical conventions required multiple rounds of review. Each site had local preferences that conflicted with global standardization objectives. Resolution was a tiered decision-making structure: global standards (non-negotiable) were defined by corporate finance; site-specific extensions (allowable within the global standard) were defined by site finance managers with corporate approval.

Challenge 2: BRD Version Proliferation

The BRD reaching v4.0+ indicates significant requirements churn — stakeholders continued adding requirements after the BRD was supposed to be frozen. Resolution mid-engagement was implementing a formal change control process: any requirement added after BRD v2.0 required a written change request with impact assessment. This slowed new requirement introduction without preventing legitimate refinements.

Challenge 3: Wi-Fi Coverage Gaps at Manufacturing Sites

MSCA physical inventory testing revealed Wi-Fi dead zones in several manufacturing areas where Oracle handheld sessions dropped. Resolution required IT infrastructure upgrades (access point placement) at affected sites — a dependency that extended the MSCA deployment timeline but was essential for reliable physical inventory operations.

Challenge 4: Legacy Asset Data Quality

The existing Oracle FA asset register contained records that were incomplete (missing location codes), inconsistent (multiple naming conventions for the same asset category), and inaccurate (assets disposed of in the field but not in Oracle). The data cleanse effort — larger than initially scoped — required a structured remediation process: automated correction for systemic issues, manual review for complex records, and a formal acceptance test comparing cleansed record counts against source documentation.

Consultant Insights

Reusable Patterns

• Global FA Data Standards Template: The five-element data model (asset category, location hierarchy, description format, capitalization threshold, depreciation method) established here is directly reusable as a starting template for any global FA standardization engagement.
• AutoCap Rule Design Framework: The decision matrix (invoice vs. receipt trigger, threshold by asset category, exception handling for split invoices and project assets) is reusable as a design starting point for any AutoCap implementation.
• MSCA Deployment Checklist: The physical prerequisites (Wi-Fi coverage, device procurement lead time, Oracle MSCA responsibility setup, warehouse organization assignment) form a deployment checklist applicable to any MSCA engagement.
• Tiered Stakeholder Alignment Model: The two-tier decision structure (global standards = corporate; site extensions = local with approval) is a governance pattern applicable to any global Oracle standards project with multi-site stakeholders.

Lessons Learned

Related Engagements