← All projects

03 / ERP management system

DEXIN NEBULA

DEXIN NEBULA ERP management system cover

An internal operations platform blueprint connecting people, customers, supply, inventory, finance, and management insight.

Visit project website ↗GitHub · View repository ↗
RoleProduct coordination and process design
PeriodSummer 2026
StatusPlanned and building

The Challenge

Business functions used disconnected tools and definitions, limiting traceability and a consistent management view.

Design blueprint / OPERATIONS

An organization, made legible

Explore the operating blueprint, from responsibility to traceable decisions.

Skip exhibit, read decisions ↓
An organization, made legibleConcept model · not a simulation
01 / 04

People & permissions

Establish who can see, act, and own a change. Permissions translate organizational responsibility into software.

A CLOSER LOOK / DESIGN ANALYSIS

Follow one record through the system

An interpretation of the public architecture. A delivery-location change is an illustrative example, not a customer record or implementation result.

Entity

A location has its own identity. Changing an address does not change the customer entity.

Ownership

Who requests and approves the change, and which workflows need another check?

History

New orders may use the updated location. Historical records retain their original snapshot.

Public product reference ↗
Read the full reasoning · Chinese →

REAL SETTINGS

A system is tested where work actually happens

Dexin Miaosheng office environment
Office environmentOrganizational context only
Dexin Miaosheng warehouse environment
Warehouse environmentThe image does not imply that pictured items are connected to the system
DEXIN Nebula platform visual connecting organization, operations, and data
Public platform visualDEXIN NEBULA

Approach

  1. Defined business objects, ownership, and approval paths
  2. Separated requirements by module while preserving master-data consistency
  3. Treated access control, logs, and auditability as foundational

System Structure

  1. OA / HRM / CRM / SRM
  2. Inventory, finance, and product master data
  3. BI, permissions, and audit trails

Design Decisions

Public architecture interpretation · ongoing validation

Define entities, ownership, and definitions before expanding modules

As modules grow, who owns a shared record?

More connected screens cannot resolve inconsistent customer, inventory, and financial definitions. This principle interprets the public product structure; it is not a claim about migration results or implementation metrics.

德馨星云 · Public product overview ↗

Outcomes

  • Produced a cross-functional system blueprint
  • Combined process and data governance in one design
  • Created clear boundaries for phased implementation
Enterprise SystemsData GovernanceOperationsVisit project website ↗

Discuss this project

Interested in this project’s methods, implementation, or tradeoffs? I welcome a conversation by email.

Discuss this project
Next projectDEXIN AI