本文主要講述了在傳統電商企業中，訂單系統應承載的角色，就訂單系統所包含的主要功能子產品梳理了設計思路，并對訂單系統未來的發展做了一些思考。
在搭建企業訂單系統之前，需要先梳理企業整體業務系統之間的關系和訂單系統上下遊關系，隻有劃厘清業務系統邊界，才能确定訂單系統的職責與功能，進而保證各系統之間高效簡潔的工作。
訂單架構
訂單架構
應用層直接面對終端使用者，負責為使用者提供訂單交易服務，從是否為自建系統可以分為自建平台管道和第三方平台管道。自建系統管道分為PC商城、App商城、小程式商城。第三方平台店鋪可分為淘寶天貓店鋪、京東店鋪、拼多多店鋪等。
盡可能的拓展應用層的服務管道，通過各種管道觸達使用者，進而提升訂單交易量和交易額，這是應用層的使命。
服務層作為整個交易系統中最重要的一層架構，支撐着應用層各管道的交易，為應用層提供基礎服務能力。訂單系統更像是一個排程指揮中心，井然有序地調用其他系統的服務來支撐訂單交易的完成。訂單交易系統的服務層包含：訂單中心、支付中心、商品中心、營銷中心、客戶中心、倉儲中心、采購中心。
訂單中心：記錄訂單資訊、商品資訊、支付資訊、物流資訊等内容，并提供訂單操作。
支付中心：為訂單交易提供支付能力，包含支付方式和支付工具。
商品中心：為訂單提供商品基礎資料，包含SKU型号、商品參數、商品價格等資訊。
營銷中心：查詢活動優惠資訊，結合客戶資訊，判斷目前訂單是否滿足活動優惠的條件，是否滿足優惠券的使用條件，進而調用優惠資訊。
客戶資訊：查詢客戶的身份及權益，以及可用于交易的虛拟資産，如積分、紅包、卡券等。
倉儲中心：提供商品的庫存查詢，商品鎖庫，以及負責訂單商品出庫、退換貨入庫等貨物管理的有關能力。
采購中心：對于期貨類訂單、預售類訂單，采購中心能夠提供智能化的采購服務，縮短采購時間、減少采購成本。
資料層為交易系統提供資料分析能力，利用資料分析的結果驅動交易鍊路的服務體驗優化，提升訂單交易的增長，進而更好的實作業務目标。資料層從交易、商品、管道三個方面來分析訂單交易的過程。
交易分析：統計商品的下單轉化率、訂單的支付轉化率；統計訂單的付款人數、下單人數、訂單量、累計交易額、人均交易額、平均每筆訂單交易額；統計新老使用者的付款人數、訂單量、訂單金額，新老使用者的訂單量占比。
商品分析：統計各單品的銷量、銷售額、付款人數、支付轉化率；統計各類目銷量、銷售額、各類目銷售占比、各類目與上一統計周期的環比情況。
管道分析：統計PC商城、App應用、小程式、天貓淘寶店鋪、京東店鋪、拼多多店鋪等管道的銷量、銷售額、付款人數，以及各管道的占比，各管道與上一統計周期的環比情況。
二、訂單流程
訂單流程
- 使用者通過購物車或商品詳情頁進行下單。下單時系統需判斷有無活動優惠，有無可用的優惠券、紅包，是否可使用積分抵扣等優惠資訊，使用者選擇優惠券、積分抵扣，填寫收貨資訊，确認沒問題後提價訂單；
- 選擇支付方式（微信支付、支付寶支付、銀行卡支付），進行訂單付款。付款時，系統查詢商品有無可用銷售庫存，若無可用庫存則訂單支付失敗，并提示使用者庫存不足，若庫存充足則進入下一個判斷，判斷是否超出支付時間。
- 庫存充足，系統檢查是否超出支付時間，若超出則支付失敗，若未超出則執行支付。
- 完成付款後，系統鎖定庫存，訂單進入待發貨狀态；
- 背景系統進行訂單商品的揀貨、清點及訂單發貨，系統扣減庫存；
- 使用者簽收快遞，并确認收貨。若使用者長時間未操作确認收貨，系統則根據背景系統設定的規則，發貨後15天自動收貨；
- 訂單完成交易，流程結束。
此為訂單的正向交易流程，逆向交易流程屬于訂單售後子產品，後續單獨分析有關訂單售後的系統設計。本流程重點講解訂單系統中涉及的背景業務流程，前端設計請檢視文末的推薦閱讀。
三、訂單功能
訂單中心可通過訂單清單和訂單詳情檢視訂單資訊。
訂單詳情
訂單資訊的展示要考慮各種字段的全面性，字段展示考慮的如果足夠的周到，也便于營運、客服等崗位的同學分析處理問題。背景訂單詳情頁的展示不僅包含商品資訊、單據資訊、費用資訊、位址資訊，還包含倉儲資訊、發票資訊、客戶資訊。
商品資訊：包含但不限于商品名稱、型号、規格、參數、促銷價、市場價、類目、品牌等資訊等資料字段。
單據資訊：包含但限于訂單來源、訂單類型、配送方式、訂單編号、下單時間、支付時間、訂單狀态等資料字段。訂單來源包含PC商城、APP商城、小程式商城、淘寶天貓店鋪、京東店鋪、拼多多店鋪。訂單類型包含線上普通訂單、團購訂單（僅線上有）、預售訂單（僅線上有）、線下訂單等。配送方式包含快遞發貨、上門自提、同城配送。
費用資訊：包含但不限于商品金額、運費金額、優惠券金額、紅包金額、積分抵扣金額、訂單金額、積分獎勵數量等資料字段。訂單金額=商品金額+運費金額-優惠券金額-紅包金額-積分抵扣金額。
位址資訊：包含收貨位址和代發位址。位址資訊展示的内容包含姓名、電話和街道位址。
倉儲資訊：包含但不限于訂單鎖定庫存、倉庫可用庫存、倉庫總庫存、倉庫編号、倉庫區域，預計送達日期等資料字段。
發票資訊：包含開票擡頭名稱（機關或個人）、機關稅号、電話、注冊位址。
客戶資訊：包含但不限于客戶賬号、客戶名稱、客戶等級、客戶下單量、客戶交易額等資料字段。
2B類的客戶訂單，通常還會涉及到合同，訂單詳情頁還應能夠檢視合同資訊，合同支援線上預覽和本地下載下傳。系統根據訂單商品、訂單金額、客戶資訊、收貨位址、賣家資訊（一般為商城）自動生成訂單銷售合同。
訂單詳情示意圖
訂單清單
訂單清單将詳情頁當中的最常用的字段展示出來即可，大家可根據自己的實際需要和查詢習慣展示相應的字段。如果清單頁展示的字段太多，可以通過設定面闆，來控制清單頁顯示的字段，通過拖拽表單列來調整字段的顯示順序。
建議在清單資料的上方使用訂單狀态作為内頁切換的标簽，将不同狀态的訂單分别顯示在不同的狀态标簽頁下方，在頁面設計時通常還會新增一個全部狀态的Tab标簽。訂單清單支援的查詢條件包含條件篩選類、關鍵字查詢類和日期查詢類條件。
條件篩選
包含訂單管道、訂單類型、配送方式、支付方式、訂單狀态、結算狀态、結算方式、開票狀态。
訂單管道：包含PC商城、App商城、小程式商城，淘寶天貓店鋪、京東店鋪、拼多多店鋪等第三方平台店鋪。
訂單類型：包含線上普通訂單、團購訂單（僅線上有）、預售訂單（僅線上有）、線下訂單。
配送方式：包含快遞發貨、上門自提和同城配送。上門自提需要線下有實體門店，同城配送一般為生鮮類商品。
支付方式：包含微信支付、支付寶支付、銀行卡支付等支付方式。
訂單狀态：包含待支付、待發貨、已發貨、已完成、已取消和異常。已取消訂單包含因支付逾時取消的訂單和客戶不想要手動取消的訂單。異常訂單即因系統問題引發的訂單出現的異常，如訂單金額的計算錯誤、訂單狀态的錯誤、發貨數量錯誤等各種由于各系統間的資料傳遞錯誤、資料邏輯運算出現的問題造成的訂單異常。
結算狀态：結算狀态為商城與各商家之間的訂單結算，一般分為未結算和已結算。
結算方式：結算方式分為手動結算、定期自動結算。
開票狀态：開票狀态即商城給客戶開具的訂單發票的開具狀态，為未開票和已開票。
關鍵字查詢
關鍵字查詢包含支援按訂單編号、商品編号、客戶賬号、收貨人姓名、收貨人手機号等内容模糊查詢。
日期查詢
訂單清單支援按下單日期範圍、發貨日期範圍查詢訂單。
訂單清單的資料支援以Excel、PDF格式導出到本地。
訂單清單示意圖
在訂單中心可以對訂單進行的處理操作包含：訂單修改、訂單關閉、合并訂單、訂單發貨、訂單備注、列印發貨單、列印快遞單、确認收貨。
訂單修改：訂單未發貨前，在訂單背景可以修改訂單的位址資訊、訂單費用資訊和發票資訊。位址資訊包含收貨位址和代發位址，支援修改姓名、電話和位址；訂單費用資訊包含運費金額、優惠金額，修改後系統重新計算訂單金額；發票資訊包含開票擡頭（支援機關和個人）、機關稅号。
部分ERP系統背景，還支援修改商品、單價、客戶，基本上訂單所有的資訊都支援修改。很多ERP系統中支援商家為客戶在背景下手工單，下單的整個過程都是商家代替客戶操作。
訂單關閉：由于某些特殊原因，常常需要背景提供關閉訂單的靈活操作，如客戶退單、訂單異常等特殊情況。
合并訂單：當同一個收貨人（姓名、電話和位址全部相同）有多筆訂單，且下單時間接近時，商家為了節省物流成本，通常會将銷售訂單進行合并，合并為一個發貨單，進行一次性發貨。
訂單發貨：使用者付款後，需要進行訂單發貨操作。系統需要支援訂單批量發貨，發貨時需在背景頁面填寫選擇快遞公司，填寫運單号。具有成熟WMS系統的商城，這裡可以不填寫快遞公司，快遞單号，這一步隻負責将訂單推送至倉儲系統。倉儲系統進行揀貨、清點後，進行最終發貨時再填寫快遞公司和快遞單号。
訂單備注：編輯訂單備注資訊，通常是營運的同學提醒倉庫部門需要注意的發貨事項。
列印發貨單：列印發貨單資訊，發貨單資訊包含商品資訊、訂單基礎資訊、收貨資訊。
列印快遞單：列印快遞單資訊，快遞單資訊包含發貨倉庫、發貨人姓名、電話、位址、快遞單号。快遞單内容支援編輯修改，預設根據系統規則推薦。
确認收貨：對于使用者已簽收的訂單，若使用者忘記“确認收貨”，營運人員可以在背景進行确認收貨，确認收貨的訂單狀态将變更為已完成，訂單流程結束。
發貨單示意圖
快遞單示意圖
對于期貨訂單、預售訂單、超賣訂單，由于沒有現貨，使用者需要經曆漫長的等待。為了緩解使用者的等待焦慮，提升服務體驗，當貨物到倉後，系統需要及時提醒下單使用者。當訂單貨物到貨後，系統需要通過短信、App Push消息、微信消息等多種方式告知使用者。
對于此類訂單，背景系統應有一個專門的頁面用于檢視訂單到貨情況，以及提醒消息的下發情況。便于訂單營運人員或客服人員掌握客戶訂單的最新情況。
訂單背景系統需要針對商城訂單進行一些基礎設定。如訂單支付時間設定、訂單售後時間限制、自動好評設定。
支付時間：設定訂單的支付時間，超出支付時間則訂單将被自動取消。一般零售普通訂單的支付時間為2小時以内，對于預售類訂單，将會涉及預付款和尾款，需要對預付款和尾款分别設定訂單支付時間。
售後時間：為訂單設定售後的限制時間，超出售後限制時間則不允許使用者申請售後。售後時間一般為确認收貨後15天内，可以根據自己的實際情況靈活設定。
自動好評：可以設定自動好評的時間。使用者在訂單完成的某一時間内未進行評價，系統自動給與五星好評，具體時間各電商平台可以根據自己的實際情況進行靈活設定。
以上的訂單設定完成後，将對PC商城、App商城和小程式商城的所有訂單均生效。
訂單中心在整個電商系統中占據非常重要的位置，屬于電商系統的核心功能。檢視訂單、處理訂單的操作涉及各部門不同的人員，是以有必要針對訂單系統設計權限。權限系統根據不同的作用與範圍，可以分為菜單權限、操作資料、資料權限。
菜單權限用于控制背景使用者能夠看到的菜單，操作權限用于控制背景使用者能夠操作的按鈕，資料權限則控制着背景使用者能夠看到的資料字段。将這三種權限共同作用于背景系統的使用者賬号，則可以實作對不同部門的員工賬号實作精準掌控。大家根據自己的工作職責去申請配置賬号的權限範圍，與自己工作無關的資料或操作則進行系統限制，以避免引發一些不必要的麻煩。
賬号與權限并不是直接建立關系的，需要引入角色來為連接配接它們。通常在背景系統中需要先定義角色，角色的定義與員工所處的部門、工作的崗位、工作的職責有關。根據崗位與職責定義角色，然後再為角色添加賬号。簡單的來說就是幹相同工作的人同屬于一個角色。角色建立完成後，再為角色配置權限，權限的配置則可以按照上文的菜單權限、操作權限和資料權限三個方面進行配置。
訂單系統與各業務系統的關系
（1）對外系統：
所有給企業外部使用者使用的系統都在這一層，包括官網、普通使用者使用的C端，還包括給商戶使用的商家背景和在各個銷售管道進行分銷的系統，比如與銀行信用卡中心合作、微信合作在合作商的平台露出本企業的産品。這類系統站在與客戶接觸的最前線，是公司實作商業模式的橋頭堡。
（2）管理中背景：
每個C端的業務形态都會有一個對應的系統子產品，如負責管理平台交易的訂單系統，管理優惠資訊的促銷系統，管理平台所有産品的産品系統，以及管理所有對外系統顯示内容的内容系統等。
（3）公共服務系統：
随着企業的發展，資訊化建設到達一定程度後，企業需要将通用功能服務化、平台化，以保證應用架構的合理性，提升服務效率。這類系統主要給其他應用系統提供基礎服務能力支援。
訂單系統上下遊關系
由此可見，訂單系統對上接收使用者資訊，将使用者資訊轉化為産品訂單，同時管理并跟蹤訂單資訊和資料，承載了公司整個交易線的重要對客環節。對下則銜接産品系統、促銷系統、倉儲系統、會員系統、支付系統等，對整個電商平台起着承上啟下的作用。
4. 訂單系統的業務架構
（1）訂單服務
該子產品的主要功能是使用者日常使用的服務和頁面，主要有訂單清單、訂單詳情、線上下單等，還包括為公共業務子產品提供的多元度訂單資料服務。
（2）訂單邏輯
訂單系統的核心，起着至關重要的作用，在訂單系統負責管理訂單建立、訂單支付、訂單生産、訂單确認、訂單完成、取消訂單等訂單流程。還涉及到複雜的訂單狀态規則、訂單金額計算規則以及增減庫存規則等。在4節核心功能設計中會重點來說。
（3）底層服務
資訊化建設達到一定程度的企業，一般會将公司公共服務子產品化，比如：産品，會建構對應的産品系統，代碼、資料庫，接口等相對獨立。但是，這也帶來了一個問題，比如：訂單建立的場景下需要擷取的資訊分散在各個系統。
如果需要從各個公共服務系統調用：一是會花費大量時間，二是代碼的維護成本非常高。是以，訂單系統接入所需的公共服務子產品接口，在訂單系統即可完成對接公共系統的服務。
2
訂單系統核心功能
1. 訂單中所包含的内容資訊
為了使訂單系統能夠對訂單進行高效、精準的管理和跟蹤，訂單會儲存關于産品、優惠、使用者、支付資訊等一系列的訂單實時資料，來和下遊系統，如：促銷、倉儲、物流進行互動。
以一個通用B2C商城的訂單為例，梳理其包含的資訊如下：
這裡要注意的是訂單類型，随着平台業務的不斷發展，品類豐富、交易方式豐富後，需要對訂單進行多元度的分類管理，同時訂單類型利于訂單系統的擴充性。每種訂單類型将會對應一套流程及一套狀态，便于對訂單進行分類管理和複用。
2. 流程引擎
流程是指從平台角度出發，将訂單從建立到完成的整個流轉過程進行抽象，進而行程了一套标準流程規則。而不同的産品類型或交易類型在系統中的流程會千差萬别，是以為了友善對訂單流程進行管理，會組建流程引擎子產品。
每套訂單流程中會包含正向流程及逆向流程，正向流程可以比作一次順利的網購體驗過程中，背景系統之間的資訊流轉。逆向流程則是修改訂單、取消訂單、退款、退貨等各種動作引起的背景系統流程，同時每個流程觸發的條件又可分為系統觸發和人工觸發兩種場景。
（1）正向流程
以一個通用B2C商城的訂單系統為例，根據其實際業務場景，其訂單流程可抽象為5大步驟：訂單建立>訂單支付>訂單生産>訂單确認>訂單完成。
而每個步驟的背後，訂單是如何在多系統之間互動流轉的，可概括如下圖：
訂單建立：
使用者下單後，系統需要生成訂單，此時需要先擷取下單中涉及的商品資訊，然後擷取該商品所涉及到的優惠資訊，如果商品不參與優惠資訊，則無此環節。
接着擷取該賬戶的會員權益，這裡要注意的是：優惠資訊與會員權益的差別，比如：商品滿減是優惠資訊，SUPER會員全場9.8折指的是會員權益，一個是針對商品，另一個是針對賬戶。其次就是優惠活動的疊加規則和優先級規則等。
增減庫存規則是指訂單中的商品，何時從倉儲系統中對相應商品庫存進行扣除，目前主流有兩種方式：
下單減庫存——即使用者下單成功時減少庫存數量
- 優勢：使用者體驗友好，系統邏輯簡潔；
- 缺點：會導緻惡意下單或下單後卻不買，使得真正有需求的使用者無法購買，影響真實銷量。
解決辦法：
- 設定訂單有效時間，若訂單建立成功N分鐘不付款，則訂單取消，庫存復原；
- 限購，用各種條件來限制買家的購買件數，比如一個賬号、一個ip，隻能買一件；
- 風控，從技術角度進行判斷，屏蔽惡意賬号，禁止惡意賬号購買。
付款減庫存——即使用者支付完成并回報給平台後再減少庫存數量
- 優勢：減少無效訂單帶來的資源損耗；
- 缺點：因第三方支付傳回結果存在時差，同一時間多個使用者同時付款成功，會導緻下單數目超過庫存，商家庫存不足容易引發斷貨和投訴，成本增加。
解決辦法：
- 付款前再次校驗庫存，如确認訂單要付款時再驗證一次，并友好提示使用者庫存不足；
- 增加提示資訊：在商品詳情頁，訂單步驟頁面提示不及時付款，不能保證有庫存等。
綜上所述，兩種方式各有優缺點，是以，需結合實際場景進行考慮，如：秒殺、搶購、促銷活動等，可使用下單減庫存的方式。而對于産品庫存量大，并發流量沒有那麼強的産品使用付款減庫存的方式。
将兩種方式帶入到銷售場景中，關聯商品類型、促銷類型、供需關系等，靈活使用，以充分發揮計算機系統的優勢。
訂單支付：
使用者支付完訂單後，需要擷取訂單的支付資訊，包括支付流水号、支付時間等。支付完訂單接着就是等商家發貨，但在發貨過程中，根據平台業務模式的不同，可能會涉及到訂單的拆分。
訂單拆分一般分兩種：
- 一種是使用者挑選的商品來自于不同管道（自營與商家，商家與商家）；
- 另一種是在SKU層面上拆分訂單：不同倉庫，不同運輸要求的SKU，包裹重量體積限制等因素需要将訂單拆分。
訂單拆分也是一個相對獨立的子產品，這裡就不較長的描述了。
訂單生産：訂單生産，是指産品從企業到使用者這一流程的概述。如電商平台中，商家發貨過程已有一個标準化的流程，訂單内容會發送到倉庫，倉庫對商品進行打單、揀貨、包裝、交接快遞進行配送。
訂單确認：收到貨後，訂單系統需要在快遞被簽收後提醒使用者對商品做評價。這裡要注意，确認收到貨不代表交易成功，相反是售後服務的開始。
訂單完成：訂單完成是指在收到貨X天的狀态，此時訂單不在售後的支援時間範圍内。到此，一個訂單的正向流程就算走完了。
（2）逆向流程
上面說到逆向流程是各種修改訂單、取消訂單、退款、退貨等操作，需要梳理清楚這些流程與正向流程的關系，才能理清訂單系統完整的訂單流程。
訂單修改：可梳理訂單内資訊，根據資訊關聯程度及業務訴求，設定訂單的可修改範圍是什麼，比如：客戶下單後，想修改收貨人位址及電話。此時隻需對相應資料進行更新即可。
訂單取消：使用者送出訂單後沒有進行支付操作，此時使用者原則上屬于取消訂單，因為還未付款，則比較簡單，隻需要将原本送出訂單時扣減的庫存補回，促銷優惠中使用的優惠券，權益等視平台規則，進行相應補回。
退款：使用者支付成功後，客戶發出退款的訴求後，需商戶進行退款稽核，雙方達成一緻後，系統應以退款單的形式完成退款，關聯原訂單資料。因商品無變化，是以不許考慮與庫存系統的互動，僅需考慮促銷系統及支付系統互動即可。
退貨：使用者支付成功後，客戶發出退貨的訴求後，需商戶進行退款稽核，雙方達成一緻後，需對庫存系統進行補回，支付系統、促銷系統以退款單形式完成退款。最後，在退款/退貨流程中，需結合平台業務場景，考慮優惠分攤的邏輯，在發生退款/退貨時，優惠該如何退回的處理規則和流程。
（3）狀态機
狀态機是管理訂單狀态邏輯的工具。狀态機可歸納為3個要素，即現态、動作、次态。
- 現态：是指目前所處的狀态。
- 動作：動作執行完畢後，可以遷移到新的狀态，也可以仍舊保持原狀态。
- 次态：動作滿足後要遷往的新狀态，“次态”是相對于“現态”而言的，“次态”一旦被激活，就轉變成新的“現态”了。
狀态機的設計需要結合平台實際業務場景，将狀态間的切換細化成了執行了某個動作。
以一個B2C商城的訂單系統舉例如下：
訂單系統為了高效的對訂單進行跟蹤和管理，會對訂單流程當中的關鍵節點，抽象出訂單狀态。而訂單狀态從不同使用者的角度可分為，系統訂單狀态、商家訂單狀态、買家訂單狀态等。
對于訂單系統來說，訂單狀态細分的顆粒度越細、越明确，訂單系統管理的精度和可靠性就越高，比如：在待付款和待發貨兩個狀态中，訂單系統背景會細分為訂單逾時取消、訂單支付失敗、訂單付款完成等。
是以，訂單狀态子產品中，通常會維護狀态映射表，以不同的使用者角色對系統訂單狀态進行重新劃分，以滿足不同使用者的需求。
除此以外，随着電商平台的不斷發展，不同的業務類型，所對應的訂單狀态都會有所差別。是以，訂單系統中一般會儲存多套狀态機，以滿足不同的訂單類型來使用。
3
訂單系統的發展
訂單系統的主體架構，和主要業務子產品已基本講完，那麼随着企業的發展，業務量和業務形式不斷變化，企業有可能形成多個訂單系統并存以滿足不同的業務需要的情況。
業務系統架構如下：
這種狀況的出現，将會給平台帶來非常大的發展瓶頸，如：
三個訂單系統，每個訂單系統處理不同類型的訂單，沒有統一的訂單銷量、訂單狀态資訊，網站前台對訂單的狀态展示與控制不統一，隻能是在網站前台會員中心硬代碼維護一套面向會員的統一訂單明細與狀态資料。
而無線側上線後，由于不了解前台網站會員中心的訂單狀态管理邏輯，是以需要把前台網站的訂單明細及狀态管理再在無線應用側再實作一遍。
三套背景訂單系統與公共業務系統如會員中心、支付與财務、促銷工具、客戶分單等系統都需要對接一遍，公共業務處理邏輯不統一，一旦邏輯變更多個系統統一個接口都要修改一遍，接口的重複維護開發工作量大。
訂單開發目前分到事業部，各個事業部隻會考慮自己的邏輯，不會考慮公共架構，隻會越走越遠。碰到像無線這樣的項目，需要對接各個事業部，無線側應用上線進展慢。
是以未來的訂單系統可拆分為訂單中心與業務訂單系統兩個子產品，以管理公司所有訂單資料，并為各個子產品提供統一服務。
業務系統架構如下：
對于企業訂單系統的搭建，并不是要做的大而全、也不是要小而精。而需要結合市場、公司、業務的實際情況來最終制定系統設計方案和産品疊代計劃。最終，和公司整體發展互相協調，相輔相成。