袁龍友來得真早，已經在後面聊上了
這兩天主要說需求方面，不談太多技術，因爲袁龍友他……本來也不是搞java的
CRM：客戶關係管理系統
企業的信息化階段：
第一階段：購置電腦，搭建網絡
第二階段：電信、銀行、證券是信息化程度最高的，它們解決的是業務系統。企業建立起相應
的業務系統標誌着信息化階段第二階段的到來。
第三階段：用業務系統進行決策分析：比如移動用戶享受免費接聽，而且每分鐘的電話費用降低，支撐移動
做這一決策的原因就是對自己用戶的海量數據分析
也就是商業決策過程（這一階段是很有市場份額的）
什麼叫做業務系統：實現企業單位中的業務過程的系統。
中國的軟件市場：企業多且業務需求多樣。
軟件公司發展對軟件代碼的重用性要求很高，寫代碼時要注意通用性。
要麼出去做產品、要麼是做企業的業務系統。
一個一般的商業企業的業務系統：
CRM
客戶要買的時候這個企業給國外下訂單，把東西搞回來，其實就是個倒買倒賣的中介。
這個系統要挖掘國內的潛在客戶信息（是由這個企業的銷售人員來做的），銷售人員弄來了這個
客戶之後，這個客戶的基本信息就要被錄入系統中去，包括基本信息和客戶的基本愛好之類。
一般的大產品要買賣交易成功週期很長的，比如從客戶聯繫開始，到這個客戶買產品，有時可
長達4、5年之久，銷售的提成是10%左右。
正因爲週期很長，因此銷售的過程管理很重要。國外有一些很成熟的模型可供使用。BP、SP模型
銷售A要把產品C賣給潛在的客戶B，BP、SP是兩個量化的指標
SP是銷售把產品賣給客戶的可能性百分比
BP是客戶把產品買來的可能性的百分比
比如如果客戶的經費不足，就會導致SP很低，但是BP有可能很高（雖然客戶沒錢但是可能對這個產品
需求很高）
一般遇到這種情況的時候就暫時不打擾這個客戶，等他以後有了經費再說……
BP和SP的值一般由具體的公司的規定來定位，最後是由銷售決定數字然後錄入系統給銷售主管看。
BP其實是表明用戶想不想買
SP就是用戶想不想在你這裏買
用戶取消：BP突然爲0的時候
丟單列表：BP爲100%，SP爲0
已籤合同：BP和SP都是100%
預籤合同：BP和SP都要大於等於75%
後三個月：當錄入客戶信息的時候有一個截止日期，從今天開始三個月後就有結果的客戶，這部分客戶
需要來重點公關。
其實管理的重點是是兩部分：
客戶的基本信息和銷售的過程管理
還要注意一點，客戶和你的聯繫人要分開！客戶應該是單位，而不是具體的聯繫人
===========================================================================
數據庫設計：
裏面用到了一個簡單的工具，首先要做實體建模，你的需求中有哪些實體……
銷售、客戶、跟蹤（銷售意向）、聯繫人、跟蹤歷史
客戶和聯繫人之間是一對多關係
跟蹤表：客戶ID、主鍵ID、聯繫人ID、產品、BP、SP、截止日期、競爭對手、購買方式、數量、金額
跟蹤歷史表和跟蹤表的結構是基本一樣的，只不過多了一個字段，用來記錄跟蹤的ID，跟蹤表記錄的是當前狀態
跟蹤歷史中是歷史記錄，跟蹤表是最新狀態，但是問題還有一個就是要保持數據一致……但是儘量不用觸發器，
因爲觸發器不通用……最好的辦法是把更新跟蹤歷史和跟蹤表的記錄做到一個事務裏面就可以了。
----------------------------------------------------
產品：這涉及到一個樹狀結構的生成問題
數據庫層有兩種方法：第一種是把父id設爲01，子id設爲0101………………
還有一種是單獨存儲父id，用遞歸方式……
其中第二種方式和數據庫交互可能會多一些……
產品：
產品分類：分類編號、分類名稱、描述、組件
產品部件：id、進價、出價、描述、備註信息、
產品-部件：是張關聯表，產品分類和產品部件之間是多對多的關係
報價：
報價單：報價單號、產品號、客戶號、客戶名、
報價明細：部件id、報價單號、
報價單審批信息表：ID、報價單號、送給誰。送的時間、類型、
報價明細與報價單關係是多對一的關係、
報價單與報價單審批信息之間是一對多的關係
---------------------------------------------------------
合同：合同基本信息（編號、時間、標的、合同的雙方）
合同基本信息表：合同編號（主鍵）、合同名稱、合同日期、客戶名稱、聯繫人、聯繫電話
合同配置清單：ID（主鍵）、合同編號
合同基本信息表和合同配置信息是一對多的關係
合同客戶信息表：合同編號（主鍵）
外貿公司信息表：、合同編號
合同相關文檔：、合同編號
