01 · Presales & kickoff · Four layers on one sheet
Finance already has a general ledger. The shop floor should not keep a second one
The solution consultant puts business, data, technology, and deployment on one table, and decides what the old system keeps, what the new system builds, what is read-only, and what writes back.
The solution consultant sits between presales and architecture
The solution consultant receives the documents presales already scoped, and the “not this phase” list. He is not answering whether membership still gets built. He is answering which system holds the numbers for those documents. He does not sequence phase one — that is the product manager. He does not write interfaces — that is the integration engineer. On a large project this role usually plans four layers at once: business architecture, data architecture, technical architecture, deployment architecture. If the four layers are presented separately, the customer's IT lead and finance lead each hear their own story. DaXi Technology folds the four layers into one table. Columns are systems. Rows are documents. A cell may hold only one of four words: keep, build, read, write.
Keep means the old system stays the owner. The new system does not copy a second set. Build means the old system has none of this work and it has to be made new. Read means the new system may query and may not change the old books. Write means after the new system produces a result, agreed fields go back to the old system. Two words in one cell will produce two balances later. The mark of a solution consultant is being able, when the customer says “put everything in the new system”, to point at which ledger already has an owner, and that moving it would leave tax, vouchers, or access control with no basis.
What he produces each day is not a thick proposal. It is signature lines
Outward, he talks documents in sentences the business owner can hear, and data origin in sentences the IT lead can hear. If one meeting uses only one of those languages, the other side will reopen the case at implementation. Inward, he hands the senior architect module boundaries and consistency rules, and the integration engineer write-back fields, direction, and who wins on failure. He does not write interface code. He does not sequence which document the product manager puts first in phase one. Phase sequence is a product choice. System boundary is a solution choice. Mix both in one deck, and engineering will not know whom to hear when they conflict.
The proposal must include failure. Does a write-back timeout count as success or as retry-pending. When master data does not match, is the work order refused or started under a temporary code. Those cannot wait until integration week. Public solution roles often require a POC on the critical path. A DaXi Technology POC only proves the path most likely to fight — for example whether a completion-to-stock draft can appear in Kingdee only once — without building every menu for the customer to click.
Injection moulding plant: shop-floor reporting can be built new. Vouchers cannot start over
An injection moulding plant wanted shop-floor reporting. The IT lead wanted work orders, stock, and completion all in the new system, so people would log in to one less place. The finance lead spread out month-end vouchers: material issues and completion-to-stock enter Kingdee from shop-floor numbers every month. Tax control and costing both trust this coding. If the new system kept a second item master, one letter off between two codes would drop cost onto the wrong product, and nobody would see it until month-end.
The solution consultant drew the table this way. Work orders, operations, shop-floor WIP stock: build in the new system, because Kingdee has no shifts and no machines. Item codes, units of measure, warehouse masters: keep in Kingdee. The new system only reads. A code that does not match refuses the work order. The floor is not allowed to create a master on the spot. Completion quantity: calculated in the new system, written back to Kingdee as a draft only. It becomes a voucher after finance approves. Write-back timeout: the local work order stays on “pending write-back”. Resend that one row. Do not post completion on both sides. On deployment, shop-floor network is unstable, so reporting lands in a local queue first. Every machine does not have to sit live on Kingdee.
Finance signed the write-back fields and “a draft must not auto-approve”. The shop floor signed reporting states and “no code, no start”. Two people signed separately. A proposal missing one side will meet an implementation consultant who finds the other side does not recognise the document. Later in integration Kingdee timed out once. The queue held one row to resend. Stock was not doubled. That is the behaviour a solution consultant has to lock down early, not a live decision on the engineering floor.
What happens when the proposal is too thin
If the proposal only says “integrate with Kingdee”, three practices appear together mid-project: someone creates items in the new system, someone exports Excel every night, someone writes completion straight as an approved voucher. All three can demo. None of them match at month-end. The solution consultant's job is to leave only one of those three practices before development starts, and to write why the other two were not taken. Detailed module splits go to the Senior architect. Industry-specific words go to the Industry consultant. If scope balloons back to “the full suite” at this step, send it back to the Presales consultant to change the contract. Do not sneak menus into the proposal body.