Choosing a digital foundation: set the yardstick with these 8 questions before talking price

Everything works fine in the demo room, but you only find out where it gets stuck when you return to the factory.

Vendors make procurement requests and leave approvals look very smooth: fill out a form, drag a process, generate a report. Your quality changes, non-conformance handling, and multi-plant transfers don't look like this—they have many branches, many parallel processes, require rollback, additional approvals, and you still need to keep the old rules for in-progress documents. Just clicking a few times in the demo hall to 'fit everything' doesn't mean it can handle real business back at the factory.

The bases all look pretty similar; the real differences are in two places:Expression ceilingIt determines how complex things you can do with it.Exit costDecide whether you no longer want to use it and if you can let it go. The price can be negotiated later; the standard must be set first. The following 8 questions are arranged in the order of 'first ask if you can use it at all, then ask if you use it well' — each comes with an action that can be tested on the spot.

The first four questions: Will it be useless?

Many people treat base selection as 'whether controls can be dragged,' but what really determines fate over three years is whether it can withstand the density and state changes of manufacturing documents. If the first four questions are not clear, discussing price and lead time later is not very meaningful.

1. Does it carry 'forms and processes,' or 'business systems'?

This is the most fundamental question, and also the one that most people realize only afterward.

Form-based platforms are good at digitizing paper documents: one form, one approval, one list. They are sufficient for single-point scenarios. Business system-based platforms also need to have: the lifecycle and uniqueness of master data such as materials, suppliers, customers, equipment, and processes; multi-table associations and configurable business rules; document state machines (in progress, partially completed, closed, voided, etc.) and guard conditions; definitive results for concurrency and transactions; precise control over quantity and units and unit conversion— in manufacturing, a mistake of a single decimal place can cause an accident.

On-site verification: Have the person most familiar with the business describe a real document from creation to closure, including returns, changes, and splits, to see if the other party can mainly configure it rather than just promising 'it can be customized.' If the other party repeatedly diverts the topic back to 'we have many templates' and avoids your complex document, it usually indicates a limitation in their capabilities, not a sales pitch issue.

2. Can the process engine handle branches, parallelism, rollbacks, and countersignatures?

The demonstration process is usually very clean. Your actual process is often not clean.

On-site verification: use your most complex current process (most likely changes or nonconforming product handling) to test, not a simple flow like a purchase request.

3. Is the data in your hands or in his hands?

Three aspects of export need to be clarified: whether a full export includes table structure, field types, relationships, and attachments (being able to export to Excel does not mean it can be rebuilt); whether API documentation, quotas, Webhook, and authentication are suitable for server-side integration; whether it supports privatization or dedicated cloud, whether the database is under your control, and whether the backup strategy can be customized.

Shortcut: Have the vendor demonstrate 'exporting a certain business object along with its related data completely, and explain the reconstruction steps.' If the answer is vague, the cost of quitting is high.

4. Where is the boundary for the second development, and will the upgrade cause conflicts?

The base must be extensible, and the issue lies in the method of extension: whether conventional fields, rules, and processes can be configured to address it; whether the interface version strategy for plugins/hooks/custom components is clear; where the extension code is placed and whether upgrades overwrite it; whether it supports grayscale release and rollback, and how historical data is compatible.

Be especially cautious about 'relying on scripts for everything' — it's flexible in the short term, but in the long term, every line becomes an upgrade liability. You should also ask clearly: when the vendor releases a major version upgrade, will your extensions 'upgrade along', 'freeze the old version', or 'merge conflicts yourself' — the workload for these three options differs by an order of magnitude.

The last four questions: Are they used well?

"Usable" does not equal "works well." Multiple factories within a group, overseas languages, implementation teams, and exit clauses often only become painful after signing — by then, it's already too late to change the standards.

5. Are multi-organization, multi-factory, and multi-tenant native?

Common demands in group manufacturing: hierarchy permissions and data isolation or aggregation from group → company → factory → workshop; whether the isolation model is an independent database, independent schema, or shared table with tenant identifier—these three have very different costs and complexities, so it must be clarified; inter-organizational allocation, unified group procurement distribution, shared master data but individually maintained business; whether there is a complete process from tenant account opening to deactivation and data destruction; whether headquarters can compare factories horizontally instead of logging into each one individually.

Red line: If multi-tenancy is implemented as a later patch, data isolation and the permission model often have potential risks. It's better to spend an extra half hour asking questions now.

6. Multilingualism and going global: is it true internationalization or just a translation plugin?

Check the language directory and additional costs; when a translation is missing, should it revert to the original text, leave it blank, or report an error; whether business data such as material names and inspection items support multiple languages (not just interface translation); formats for dates, numbers, currency, and addresses; whose time zone should be used for approval deadlines.

On-site verification: switch to another language, open a real business data entry — see if it's just the interface that changes or if the data changes as well.

7. Who will do the first scene?

No matter how good the product is, its implementation depends on people. Ask whether the industry template aligns with operational standards; whether it can be demonstrated in a real environment with real data; the turnover of the delivery team; the first suggested implementation scenario and the reasoning behind it—if they recommend starting from a trivial scenario, it usually indicates a lack of confidence; and whether they are willing to honestly admit 'we can't handle this scenario'.

8. It needs to be replaced in three years; can it be moved?

Specify clearly in the contract stage: data and configuration export formats, frequency, and whether there is a fee; retention period and destruction method after termination; whether key objects such as forms, workflows, and reports can be exported in a readable format, rather than just a database backup; and ownership of source code or extension code.

In one sentence:A base that can be left at a low cost is the only one worth staying with long-term. A base that cannot be moved will lose its bargaining power.

A score sheet and the differences among three people

Have the three people who understand the business best each give a score, and take the average. The weight can be adjusted;Differences are more important than the total score——A large difference in scores within the same dimension indicates that the requirements were not clearly explained or the other party did not demonstrate them clearly, and both should be further explored.

Not very suitable for scenarios where you forcefully attach a base

• Millisecond-level production line control — belongs to SCADA/edge layer
• Strong algorithm scheduling and simulation—the base is not a suitable carrier
• Standard financial accounting and statutory reports — more stability with specialized products
• Purely one-time use forms that won't be modified once completed — overly heavy investment
• The homework standards are still changing every week—first standardize them before implementing, otherwise it’s equivalent to digitizing the chaos.

If your pain point is actually 'a missing component in a specific dedicated system,' rather than 'frequent, large-scale changes in cross-department processes,' first consider completing the dedicated system or doing light integration; you may not need to deploy a full platform. What a platform excels at is consolidating organizational structures, permissions, forms, processes, reports, and integrations into reusable capabilities; treating it as a universal replacement, however, can easily blur boundaries.

Once the standard is set, we can discuss the quotation and schedule.

Before selecting a solution, first clearly write out the priority of requirements and acceptance criteria, then run it once with real data — this is much cheaper than being misled by a demo. For PoC, it is recommended to directly use a document that will give your team headaches (including exceptional branches), rather than the vendor-prepared happy path. JEDP is built on six main engines: organization, permissions, forms, processes, reports, and integrations, and supports multilingual operation and multi-tenant isolation; during selection, treating the above 8 questions as a common language for contracts and PoC is more useful than merely comparing feature lists.

• JEDP Platform Capabilities: Six Major Engines / Dual Agents / Multilingual / Multi-Tenant
• Information Technology Selection Scoring Sheet (Self-Test Without Providing Contact Information)
• Platform and Dual-Agent Sandbox Trial