FDE Practical Application (II): From Excel Field to Executable Business Model

“We have always used Excel.”

This is one of the most frequently heard phrases in enterprise digitalization projects. It usually does not mean that clients do not want to use a system, but rather reminds you that real business already exists; the rules are just scattered across spreadsheet formulas, group messages, and individual experiences.

In the project at this manufacturing plant, planners first recorded different products in multiple sub-sheets, then summarized them into a master sheet, manually judging inventory, in-transit items, packaging specifications, and expiration dates, ultimately providing procurement with a “suggested purchase list.” It looks like a table, but in reality, it is a shell of a business model.

In Interviews, Don’t Ask “What Page Do You Want”

We categorized interview questions into five dimensions. By asking this way, discussions immediately shift from “what the page looks like” to “what the rules actually are”:

1. Where does this data come from, and who is responsible for its confirmation?

2. When can we move to the next step, and under what circumstances must we stop?

3. Which fields are input for calculations, and which are merely for displaying results?

4. How are different statuses handled, and who has the authority to approve?

5. Who will ultimately trace, print, or export this record?

For example, “purchase quantity” is not a problem that can be solved with just an input box. The plan provides a suggested quantity, while procurement will adjust the actual quantity based on minimum packaging, expiration dates, supplier quotes, and market changes. The system should retain both suggested and actual values, rather than overwriting the planned results with the final input from procurement personnel.

Replace Department Menus with Objects and Events

In meetings, everyone describes processes according to their own departments, easily leading to menus like “sales module, procurement module, warehouse module,” without seeing the relationships between them.

We reorganized the content into business objects: orders, products, formulas, materials, procurement contracts, inventory batches, production batches, sampling records, outbound records, and reconciliation statements. Then we mapped the verbs from the meeting into events: confirmation, calculation, procurement, warehousing, sampling, release, production scheduling, material requisition, reporting work, shipping, and payment collection.

This reveals several key relationships:

• Orders are the source of demand, but procurement contracts do not directly belong to orders.

• Formulas are the basis for calculating material requirements and must retain historical versions.

• Inventory batches connect procurement prices with subsequent material requisition costs.

• Production batches can correspond to multiple orders, and finance needs to allocate costs again during reconciliation and cost analysis.

• Sampling and quality results can change inventory availability.

This approach is closer to what the system truly needs to express than simply creating a page for each department, and it also facilitates subsequent tracing and reconciliation.

Define Boundaries for Calculation Rules

The aspect most easily underestimated in requirement documents is calculation. We broke down material requirements into three layers: order quantity multiplied by the unit usage in the formula gives us gross demand; gross demand minus available inventory gives us net demand; net demand combined with packaging, expiration dates, alternative materials, and procurement strategies forms the suggested purchase quantity.

This formula is still not sufficient because “available inventory” does not equal the total quantity in the inventory table. Items awaiting inspection, locked, and non-conforming batches cannot be used directly; inventory must also be frozen after production scheduling to avoid double allocation for two orders.

Therefore, every instance of “usually,” “sometimes,” or “depending on the situation” in the interview records should be followed up with questions about its corresponding status and responsible person. Calculations without boundaries can only be corrected manually, and the system will be unable to explain its results.

First Draw a Verifiable Minimum Closed Loop

We defined the initial closed loop as: a sales order, calculated through formulas and material requirements, driving procurement and warehousing, entering production after quality release, with finished products shipped by batches, and finally generating reconciliation and cost data. The business side can use real orders to walk through the process, and the engineering team can quickly identify cross-module issues.

In this chain, each module only performs the minimum capability required to complete the closed loop. For example, the notification center first covers material, sampling, material requisition and return, and approval reminders; training exams, maintenance work orders, and deeper reports are reserved for later.

Demonstrations Are Tools for Requirements, Not Reporting Tools

During the first version demonstration, discussions quickly shifted from “what the page looks like” to “who initiates sales outbound,” “can we print documents before inspection is complete,” and “how to reconcile when one production batch corresponds to multiple orders.” These questions often do not arise proactively in written requirements because users only realize that previous verbal agreements need to be recorded in the system once they see an operable process.

We categorized feedback from each demonstration into three types: rule errors, where the status or calculation does not align with the business and must be corrected; information gaps, where pages, export forms, or notifications do not present key fields; and process trade-offs, where the business wishes to retain manual judgment, and the system only provides assistance. After this classification, the team will not turn all feedback into fields, nor will they hard-code all manual judgments.

This Method Applies to More Enterprises

1. First, collect raw materials, but do not rush to write requirements.

2. Then extract objects, events, statuses, roles, and calculation rules.

3. Next, mark conflicts and unresolved items, returning to the business site for confirmation.

4. Then select a minimum closed loop that can produce real results.

5. Use demonstrations to validate boundaries, then decide which rules enter the system.

6. Maintain clear distinctions between what has been implemented, what is planned, and what is not currently being addressed.

“Moving Excel to the web” is merely surface work. The real task is to transform the judgments behind the spreadsheets into rules visible to the entire team while leaving room for manual confirmation of uncertainties.