【正文】 ........................................................................ 46 致 謝 ........................................................................................................................................ 47 常州大學本科畢業(yè)設計（論文） 第 1 頁 共 47 頁 1 概述 課題背景 客戶關系管理 (Customer Relationship Management, CRM)是一個不斷加強與顧客交流，不斷了解顧客需求，并不斷對產(chǎn)品及服務進行改進和提高以滿足顧客的需求的連續(xù)的過程。 本課題借助XML 數(shù)據(jù)管理 技術開發(fā) CRM 系統(tǒng) 。 在系統(tǒng) 開發(fā)過程中以面向對象的思想 ， 結合了 CRM 管理理念 。為方便與客戶的溝通，客戶關系管理可以為客戶提供多種交流的渠道。結合 新經(jīng)濟 的 需求 和新技術的發(fā)展， Gartner Group Inc 提出了 CRM 概念。這樣做是沒有必要的，因為在數(shù)據(jù)交換時有些數(shù)據(jù)是不需要進行轉換的，因此轉換的效率有所降低。 (3)XML 綁定工具，這些產(chǎn)品能把 XML 文檔和對象進行綁定，主要應用在以數(shù)據(jù)為中心的場合。如 Sunopsis 的 Sunopsis XML Driver 等。并且客戶提供的產(chǎn)品質量和類型也不一樣，自然客戶的優(yōu)先級別就不一樣，所以當多個客戶可供選擇時無法很快的分析其優(yōu)劣并做出選擇。所以這是企業(yè)最大的需求：那就是有一套電子解決或者提醒方案，可以提醒業(yè)務人員與各位客戶都能保持聯(lián)系，避免客戶流失。 數(shù)據(jù)庫技術的應用是建立在數(shù)據(jù)庫管理系統(tǒng)基礎上的，各數(shù)據(jù)庫管理系統(tǒng)之間的異構性及其所依賴操作系統(tǒng)的異構性，嚴重限制了信息共享和數(shù)據(jù)交換范圍 ； 數(shù)據(jù)庫技術的語義描述能力差，大多通過技術文檔表 示，很難實現(xiàn)數(shù)據(jù)語義的持久性和傳遞性，而數(shù)據(jù)交換和信息共享都是基于語義進行的，在異構應用數(shù)據(jù)交換時，不利于計算機基于語義自動進行正確數(shù)據(jù)的檢索與應用 ； 關系 數(shù)據(jù)庫屬于高端應用，需要昂貴的價格和運行環(huán)境。有了業(yè)務統(tǒng)計功能 后 ，在月末等特殊時期時能夠大量的減少勞動力的消耗。 (2)恰當?shù)卣莆蘸媚K的大小原則 ： 究竟劃分多大的模塊最合理，很難給出絕對的標準。銷售主管也可以在系統(tǒng)中創(chuàng)建銷售機會。在本系統(tǒng)中，客戶信息將得到充分的共享，從而發(fā)揮最大的價值。 比如服務類型、客戶等級等。每隔一小段時間生產(chǎn)機就自檢是否正常，若出現(xiàn)異常，系統(tǒng)能夠立刻切換到備份機繼續(xù)工作，而不影響業(yè)務員的工作，使得 系統(tǒng)具有很好的可靠性。在可行性分析階段我們要搞清問題的定義，能清楚的列舉出目標系統(tǒng)存在的一些約束和限制，為新系統(tǒng)服務。所以，在硬件方面，本系統(tǒng)的開發(fā)也是可行的。而且如今的信息化管理顯得尤為重要，公司要想更好的發(fā)展就得花費一定的資金來購買此系統(tǒng)產(chǎn)品，而開發(fā)此系統(tǒng)并不需要投入多大的人力和物力，只需掌握相關的知識和技術就能很快的得以實現(xiàn)。系統(tǒng)分析的任務主要是在確定系統(tǒng)需求以后，繼續(xù)的識別待開發(fā)的系統(tǒng)的應用領域的對象，分析對象間的關系，建立出復合系統(tǒng)需求的模型。包括：對客戶信息的增刪改查、與客戶進行聯(lián)系，對業(yè)務記錄的增刪改查，同時其還可以查看修改自身的個人信息 。 其中序列圖描述對象如何交互的，并且將重點放在消息的順序上，也就是說，描述消息如何在對象間發(fā)送和接受。 某公司 系統(tǒng)分為了幾個模塊，不過各個模塊之間沒有過多的相互作用，每個模塊完成一個相應的子功能，從而實現(xiàn)模塊的獨立化。通過對本系統(tǒng)的分析后，本系統(tǒng)需要達到的主要設計目標有： (1)首先我們應該確定，系統(tǒng)的最終效果要達到一個友好的人機交互模式，系統(tǒng)界面簡潔友好，信息的查詢要靈活、方便、快捷和準確。 軟件平臺 (1)操作系統(tǒng) ： Windows 7； (2)數(shù)據(jù)庫 ： SQL Server 20xx； (3)Java 開發(fā)工具包 ： JDK ； (4)java 開發(fā)集成工具 ： MyEclipse。 在進行代碼設計的過程中，要求程序員遵循下列代碼設計的基本原則： (1)要適合計算機處理 代碼是計算機進行分類、排序、檢索、統(tǒng)計、分析等所有處理的依據(jù)，因此代碼選擇要便于計算機識別和處理。要考慮到各種代碼的適用范圍、適用時 間和適用的技術特點，直觀性要好，通用性要強。 (2)客戶的編碼 采用順序碼，初始 ID 為 10000，步長為 1，每增加一位會員， ID 便增加 1。表 LINKMAN 的結構如表 35所示： 表 35LINKMAN 名稱 類型 主鍵 是否為空 約束條件 備注 id number 是 否 唯一 主鍵 custid varchar 否 否 fk 引用客戶表主鍵 custname varchar 否 是 客戶名稱 name varchar 否 否 聯(lián)系人名字 sex varchar 否 是 性別 postion varchar 否 是 聯(lián)系人職位 telephone varchar 否 否 聯(lián)系人手機 mobile varchar 否 是 辦公室電話 remark varchar 否 是 備注 (6)DICT（ 數(shù)據(jù)字典 表 ） 結構如表 36 所示： 常州大學本科畢業(yè)設計（論文） 第 18 頁 共 47 頁 表 36 DICT 名稱 類型 主鍵 是否為空 約束條件 備注 id number 是 否 唯一 主鍵 type varchar 否 是 數(shù)據(jù)類型，服務類型，客戶登記，地區(qū) item varchar 否 是 數(shù)據(jù)字典條目 itemvalue varchar 否 是 條目的值 isedit number 否 是 1 可以編輯， 0 不可 編輯 (7)CUSTSERVICE（客戶服務表）結構如表 367 所示： 表 37CUSTSERVICE 名稱 類型 主鍵 是否為空 約束條件 備注 id number 是 否 唯一 銷售機會編號 custid varchar 否 是 FK 引用客戶編號 Servicetype varchar 否 是 服務類型 summary varchar 否 是 概要 custname varchar 否 否 客戶名稱 state number 否 否 服務狀態(tài) 1,新創(chuàng)建 ,2 已分配 ,3 已處理 ,4已歸檔 servicerequest varchar 否 否 服務請求 createid number 否 否 創(chuàng)建人編號 createby varchar 否 是 創(chuàng)建人名字 createdate timestamp 否 否 創(chuàng)建時間 managerid number 否 是 指派人編號 managerby varchar 否 是 指派人名字 assigndate timestamp 否 是 指派時間 Servicedeal varchar 否 是 服務處理 dealid number 否 是 處理人的 id dealby varchar 否 是 處理人的名字 dealdate timestamp 否 是 處理時間 dealresult varchar 否 是 處理結果 satisfy number 否 是 滿意度 (8)CUSTOMER（客戶表）主要用來顯示客戶信息 ， 如表 368 所示： 常州大學本科畢業(yè)設計（論文） 第 19 頁 共 47 頁 表 38CUSTOMER 名稱 類型 主鍵 是否為空 約束條件 備注 id varchar 是 否 唯一 客戶編號 custname varchar 否 否 客戶名稱 region varchar 否 是 客戶所在地區(qū) managerid number 否 是 客戶經(jīng)理編號 Managername varchar 否 是 客戶經(jīng)理名字 custlevel number 否 是 客戶等級編號 levellabel varchar 否 是 客戶等級名稱 Custsatisfy number 否 是 客戶滿意度 credit number 否 是 客戶信用度 address varchar 否 是 客戶所在地址 zipcode varchar 否 是 郵編 telephone varchar 否 是 客戶電話 fax varchar 否 是 客戶傳真 website varchar 否 是 客戶網(wǎng)站 licenceno varchar 否 是 客戶營業(yè)執(zhí)照 chieftain varchar 否 是 客戶的法人 bankroll number 否 是 客戶注冊資金 yearturnover number 否 是 客戶年收入 bank varchar 否 是 開戶銀行 Bankaccount varchar 否 是 銀行賬號 placetaxno varchar 否 是 地稅號 nationaltaxno varchar 否 是 國稅號 state number 否 是 1 正常， 2，預警， 3，暫緩 ,4，流失， 5 客戶被加入流失表， 6,客戶被刪除 (9) CUSTLOST（ 客戶流失表 ） 主要用來顯示所流失的客戶的信息 ，表 結構如表 369所示 ： 常州大學本科畢業(yè)設計（論文） 第 20 頁 共 47 頁 表 39 CUSTLOST 名稱 類型 主鍵 是否為空 約束條件 備注 id number 是 否 唯一 主鍵 custid varchar 否 否 FK 引用客戶編號 custname varchar 否 是 客戶名稱 managerid number 否 否 客戶經(jīng)理編號 managerby varchar 否 否 客戶經(jīng)理名字 lastorderdate timestamp 否 是 最后一次下訂單時間 lostdate timestamp 否 是 確認流失的時間 delay varchar 否 是 采取的暫緩流失的措施 reason varchar 否 是 確認流失的原因 state number 否 否 2 預警， 3 暫緩， 4確認流失 (10) ORDERDETAIL(訂單表 )結構如表 3610 所示： 表 310 ORDERDETAIL 名稱 類型 主鍵 是否為空 約束條件 備注 id number 是 否 唯一 主鍵 orderid varchar 否 是 fk 引用訂單表主鍵 productid number 否 是 fk 引用產(chǎn)品表主鍵 quantity number 否 是 數(shù)量 unit varchar 否 否 單位 price number 否 否 價格 (11) PRODUCT（ 商品表 ） 顯示商品的主要信息 ， 結構如表 3611 所示 ： 表 311 PRODUCT 名稱 類型 主鍵 是否為空 約束條件 備注 id number 是 否 唯一 主鍵 price number 否 是 fk 引用訂單表主鍵 productname varchar 否 是 fk 引用產(chǎn)品表主鍵 producttype varchar 否 是 數(shù)量 batch varchar 否 否 單位 unit number 否 否 價格 remark varchar 否 否 描述 常州大學本科畢業(yè)設計（論文） 第 21 頁 共 47 頁 4 系統(tǒng) 的詳細設計和 實現(xiàn) 本系統(tǒng)分營銷管理、客戶管理、服務管理、統(tǒng)計報表、基礎數(shù)據(jù)和權限管理六個模塊。 String basePath = () + ： // 常州大學本科畢業(yè)設計（論文） 第 22 頁 共 47 頁 + () + ： + () + path + /。如圖 411 銷售機會用戶圖： 圖 411 銷售機會用戶圖 (2)修改銷售機會 業(yè)務概述 ： 對未分配的銷售機會記錄可以編輯。 使用者 ： 銷售主管、客戶經(jīng)理 。兩相皆未必輸項。客戶經(jīng)理可以通過新建計劃項，編輯已經(jīng)有的計劃項，即刪除計劃項來針對一個銷售機會來制定客戶開發(fā)計劃。 輸入要素 ： 對每個計劃項填寫執(zhí)行效果，并保存。根據(jù)銷售機會中相應信息（包括客戶名稱、聯(lián)系人和聯(lián)系人電話）自動創(chuàng)建