Inspiration
We started with a simple question: how can a manufacturer know what a product really costs when its engineering and purchasing records do not connect?
A laptop made the problem tangible. Its screen, motherboard, storage, cooling, and power systems can appear across several models, but purchasing teams may buy those parts under different supplier names, service aliases, or part numbers. A price difference can look like a saving even when the records describe different assemblies.
The Kearney PERLab challenge inspired us to build PartLens around that gap. We wanted to connect the physical product to its purchasing evidence and help people understand the numbers before making a decision.
What it does
PartLens is an interactive BOM-to-spend explorer for a fictional laptop manufacturer. It connects grouped bills of materials to synthetic purchasing transactions and makes uncertain part identities reviewable.
Product explorer: Explore three laptop models through a real 3D viewer, assembly layers, and a catalog of 19 component groups. Select a component to inspect its cost and purchasing information.
Component intelligence: View reconciled spend, purchased quantities, weighted prices, factory and service price bases, and applicability across laptop models.
Source traceability: Follow a component from its BOM applications to its canonical identity and original purchase transactions. Purchase-line IDs prevent shared parts from causing duplicate spend counts.
Data reconciliation: Inspect exact identifiers, revisions, and linked transactions. Approve an identity, reject it, or request more information, with a reason and a browser-local decision history.
Supplier intelligence: Compare reconciled purchasing totals across suppliers.
Sourcing scenarios: Estimate a conditional future cost reduction from proposed prices, volume, and eligibility, then save the assumptions locally.
Configuration planner: Explore supported laptop options and see material estimates, recurring-cost assumptions, tooling allocation, and warnings for unsupported or unquoted configurations.
The demo uses synthetic data. Matching suggestions and scores are seeded examples, not a live AI matching model. No real enterprise SpendCube integration or current supplier quote is connected.
How we built it
We used HTML, CSS, and JavaScript for the application and Three.js with OrbitControls for the 3D laptop. The laptop is built from actual mesh geometry, with selectable components, camera presets, rotation, zoom, and exploded assembly views.
The data layer links canonical component identities to BOM applications and purchase-line records. Financial views use approved mappings and unique transaction IDs. Weighted prices account for quantities, and future scenarios remain separate from historical spend. Decisions and saved scenarios use browser-local storage.
We used AI-assisted development with Codex, GitHub for versioned source, and UI UX Pro Max guidance to refine accessibility and the purple-and-black interface. The current demo is published as a public website. Challenges we ran into
The hardest challenge was deciding what a match actually means. Similar descriptions do not establish identical parts, and identical parts do not guarantee comparable prices. A bare SSD and an SSD kit may have different contents. Factory terms may not transfer to service purchases. We made those distinctions visible instead of treating every price gap as a guaranteed saving.
Another challenge was balancing an engaging 3D experience with a useful procurement workflow. We expanded the component coverage, added assembly-level navigation, and kept catalog and table controls alongside the model so the experience does not depend on dragging a 3D object.
Design iteration also taught us that more polish is not always better. We tested different layouts and returned to the purple-accent sidebar version that fit the product best.
Accomplishments that we're proud of
We built a connected demonstration from physical component selection through source evidence, identity review, and financial scenario planning. The prototype includes 12 passing automated checks covering financial arithmetic, deduplication, invalid inputs, and reconciliation behavior, along with browser checks of the main workflows.
What we learned
Reliable cost analysis starts with reliable part identity. A useful tool must explain which records contribute to a number, which are excluded, and what assumptions remain unresolved. We also learned how important it is to keep engineering approval, purchasing history, and future sourcing decisions distinct.
What's next for PartLens
Our next steps are to ingest real BOM and purchasing files, add assisted matching with explainable evidence, and replace browser-local storage with a shared review database. We also want to handle units, currencies, revisions, and contract periods more deeply, then connect current supplier quotes and engineering constraints to the configuration planner.
The goal is to turn a disconnected collection of parts and purchases into a traceable basis for better manufacturing decisions.
