ERP Gap: New Product Development Progress Management

Editor’s Take · Perspectives from an AI Serial Entrepreneur (Content distilled by AI; views belong to the original author. Reading this summary is enough—no need to open the original.)

This practical lead comes from an ERP implementation consultant, pointing out that major ERP systems like Yonyou and Kingdee can handle procurement and inventory but lack a “milestone progress dashboard.” The key evidence: a client needs to manage 34 nodes, and current tools can’t archive deliverables or auto-calculate overdue dates. This reveals a genuine demand for a “lightweight ERP add-on” targeting mid-sized manufacturers—but the average order value is high and customization costs are steep, making it suitable for technically strong independent developers or small studios. The biggest trap is that requirements are extremely personalized, so generic SaaS won’t work. The recommendation is to offer only consultation plus semi-custom services.

• Identify manufacturing pain points: ERPs lack progress management
• Entry strategy: sell consulting first, then development
• Validation method: interview three companies about their needs
• Pricing reference: customized development at ¥50,000–100,000
• Pitfall to avoid: pure standardized SaaS

1. What’s the Opportunity

A new product for NPI teams at mid-sized manufacturers that fills functionality gaps in major ERPs (such as Yonyou and Kingdee): “milestone progress visualization” and “cross-stage deliverable archiving.” An embedded lightweight add-on system handles automatic progress calculation and document packaging, billed per customized project at ¥50,000–100,000.

2. Independent Assessment

Worth pursuing, but strictly as vertical customization—do not try to build a generic SaaS. Evidence shows the client pain is highly specific (34 nodes, four stages, particular archiving logic). Generalization is extremely difficult and cannot cover long-tail needs. This is a high-ticket, low-repurchase, implementation-heavy B2B service business, suited for technical teams with ERP secondary-development skills, not for indie developers building a standardized product from scratch.

3. Cold-Start Path

First move: find three manufacturers actively using Yonyou/Kingdee and frequently going through new-product development. Offer free requirement diagnostics to verify whether they would pay ¥50,000–100,000 for a “dashboard + archiving” customization. Cost scale: about one month of time (three in-depth interviews and prototype demos), near-zero capital outlay. If two of the three express willingness to pay, launch the first benchmark-case development.

4. Biggest Risks and How to Avoid Them

Killer pitfall one: the requirement black hole. Clients may treat the dashboard as an entry point for everything and keep requesting non-progress features like financial analysis or HR attendance tracking, blowing past delivery timelines. Mitigation: clearly define the “milestone progress and archiving” boundary in the contract, and bill other requests as separate modules. Killer pitfall two: system coupling risk. The add-on embeds into the ERP interface but data doesn’t sync, or an ERP upgrade breaks the add-on. Mitigation: build only a front-end display layer with read-only data sync; never modify the ERP’s core transaction logic to ensure loose coupling.

5. Case Retrospective (How Others Did It)

• What product to build: Don’t refactor the ERP’s core. Instead, create an “embedded” progress dashboard page that reuses existing ERP data—purchase orders, approval workflows, and inventory ledgers—while adding four core objects missing from the ERP: milestones, stages, overdue days, and completion rate.
• How to acquire customers: (Inferred: target ERP implementation consultants and vertical industry communities directly, or bundle the tool as a value-add module through ERP service partners rather than attempting independent cold-start acquisition.)
• Key numbers and logic: The case involves 34 nodes across four stages. The system must automatically calculate overdue amounts as the difference between planned end dates and actual completion dates. Node 29 requires archiving deliverables from the previous 28 nodes. Nodes 30/31 generate purchase orders, nodes 33/34 complete goods receipts, and subsequent transactions must be created via “push-down” generation—no manual, sourceless additions allowed.
• Pitfalls encountered: ERPs attach documents to individual transactions, but the requirement is to attach them to milestones, with one milestone potentially holding multiple heterogeneous files. The technical challenge lies in cross-object data aggregation and online preview capability—neither is a standard ERP config item, requiring a dedicated file-service middleware layer.
• Interaction details: Clients refused to navigate to the ERP’s native Purchase Order page. They demanded all actions complete inside the dashboard popup. This forces the developer to wrap ERP APIs and reconstruct the operation flow on the front end, increasing UI consistency maintenance costs.
• Defining boundaries: Rules such as “does today count as overdue?” and “does deletion roll back progress?” must be locked down with the client upfront. Avoid repeatedly changing business logic during development—that’s the most common cause of schedule slippage in custom projects.

6. Dual-Track Feasibility

Cross-border: not viable. The demand is tightly coupled to China’s dominant ERPs (Yonyou/Kingdee) and manufacturing process compliance specific to the domestic market; no corresponding software ecosystem or use cases exist overseas. Domestic: viable. Launch by partnering with one or two ERP implementation-capable firms (such as Yonyou/Kingdee ecosystem service providers) for joint development. You own the core algorithms and front-end interactions; the partner handles ERP API integration and customer introductions, cooperating on a revenue-share basis.

Original article · AllAboutProduct (woshipm.com): Read the full article →