第一章 概述
本文闡述了關于在J2EE
統的理解，利用J2EE平臺開
等等。這些都是作者在實際
統分析員的重要性，尤其是
素質對于整個項目的成功與
|
平臺上開發CRM應用系統的各方
發過程中要注意的一些技術深層
的工作中通過經驗與教訓所得來
對于以組件為主要開發對象的工
否起著非常關鍵性的作用。
|
面內容，包括本人對于CRM系
的問題，開發分析中要注意的原則
的。在工作中，我深刻的體會到系
程項目，系統分析員的技術與業務
|
需要說明的是，這并非
其中關于一些涉及到具體的
|
作者工作文檔，而僅僅是一篇分
系統設計問題，我僅僅寫了標題
|
享經驗與教訓的交流文檔，因此，
，敬請諒解。
|
科學技術在不斷的進步
源是他獲勝的最重要的資源
成為關鍵；現代競爭其實就
所得到的體驗，如何做到最
(CRM)應運而生，并成為近
|
，市場競爭日益激烈，對于企業
之一：首先企業競爭的優勢不僅
是客戶的全面爭奪而客戶對企業
大程度的滿足客戶是非常重要的
年來西方市場的熱點和大買點。
|
來說，越來越強烈的感覺到客戶資
僅是產品本身，先進的服務手段已
的信任程度往往是從其消費過程中
內容，因此，客戶關系管理系統
|
實際上，CRM就是企業與客戶的一種
過去的部門級別提升到了企業的層次，各
戶交流，因此，這就要求能夠將與客戶通
的所有信息有機的整合。
|
一對一的需求關系管理。這樣，對待客戶的視角就從
個部門共享客戶資源，以一個統一的對外接口來與客
過各種方式如傳真、郵件、電話、網頁等交流所獲得
|
在設計CRM應用系統的過程中，我們
鍵是以客戶為數據結構的核心，這其中包
怨、客戶建議、客戶服務記錄、客戶潛在
是使CRM應用系統有一個對于企業易于理
設計開發可以比較輕易地拓展，具有良好
員能夠更加易于控制整個的開發過程，減
|
首先要注意數據結構的格式：CRM應用系統的實施關
括客戶的基本信息、客戶所購買的商品列表、客戶抱
需求、客戶對企業的忠誠度等等。這樣設計的原因一
解，易于操作的用戶接口，二是對于CRM應用系統的
的開發接口與開發彈性，對于項目負責人、系統分析
少項目開發的風險。
|
另外，我們仔細研究過
但同時也看到了這些產品的
原因在很大程度上是因為技
的J2EE平臺上進行開發，這
|
國內的數家公司的CRM應用系統
不足，在本文的后面部分我們將
術的原因，因此，經過反復的論
樣就很大程度上克服了那些不足
|
的產品，從中學到了很多的東西，
提到，我們發現，造成這種不足的
證，我們最終還是選擇了在我熟悉
。
|
CRM應用系統主要由市場管理(Market
中心(Call Center)、電子商務(E_Busine
|
ing)、銷售管理(Sales)、服務管理(Service)、呼叫
ss)五部分組成。
|
市場管理：提供易于使
跟蹤市場策略，分析競爭對
過客戶資料中的諸如地域、
等等有價值的信息來從不同
經進行或者正在進行的營銷
加有效的銷售策略。
|
用的界面與工具，使操作人員能
手的市場策略等等，以便更加有
消費層次，消費習慣與方式、潛
的角度徹底的進行市場的策略分
策略，以及通過對自己和競爭對
|
夠徹底的分析市場、客戶，策劃和
效的拓展市場。在這個模塊中，通
在需求、忠誠度、已購買產品列表
析，同時還可以評估和跟蹤目前已
手的數據進行詳細的分析，策劃更
|
銷售管理：管理用戶信
員可以不受地域限制及時掌
感興趣的商品列表以及價格
售隊伍成員以及資源重新調
考，靈活進行產品配置、報
整合，以便達到多方位、多
|
息、商業機會以及銷售渠道等等
握資源以及企業的最新的價格信
信息。本模塊包括機會、賬戶、
配的管理，有效跟蹤銷售業績，
價、打折、生成銷售訂單等。另
層次的銷售，同時減少銷售成本
|
各方面的內容，從而能夠使銷售人
息，并可以向客戶提供最新的和最
合同等的管理，銷售隊伍組成、銷
同時提供個體的銷售方式與過程參
外，本模塊還應該和電子商務模塊
。
|
服務管理：本模塊通過
客戶的滿意程度，并且捕捉
能夠適時的向客戶建議其他
|
動態建立知識庫，使客戶服務代
和跟蹤服務中出現的商業機會、
的產品和服務。
|
表能夠有效的提高服務質量，增加
產品質量信息、客戶需求等等，并
|
呼叫中心：呼叫中心是實施CRM應用
務模塊進行了一個高度的集成，使一般的
賬戶、合同等等信息，并通過知識庫的支
叫中心提供當今最全面的計算機電話集成
號嗎識別(ANI)，交互式語音應答系統(IV
技術，可以在用戶撥叫的過程中業務代表
|
系統的重要的組成部分，他實際上是將銷售模塊和服
業務代表就可以進行實時的銷售和服務。它通過管理
持，就可以最大程度的滿足客戶的多方面的需求。呼
技術(CTI)，通過對已撥號碼識別服務(DNIS)，自動
R)得全面支持，通過采用系統預制的計算機電話集成
已經可以獲得客戶的資料，就靈活的進行業務處理。
|
電子商務：電子商務模塊是以上所有
、高度集成以及易于使用的用戶界面，在
購買、付款、尋求服務支持、查詢產品與
聯系在一起，最大程度的滿足客戶需求。
|
模塊的一個邏輯集成，它提供了一個個性化、人性化
這個用戶界面上客戶可以進行幾乎所有的需求，諸如
服務目錄、查詢訂單狀態等等，甚至可以與呼叫中心
|
由于我們采用J2EE架構
、服務管理以及呼叫中心模
以并且也應該使用銷售管理
，要充分利用J2EE平臺的優
同時可以控制開發的質量。
負責人、系統分析員必須把
|
平臺的開發方式，所以可以很容
塊的內容集成到電子商務模塊中
、服務管理模塊中開發的組件。
點，組件的高度可重用性，減少
在實際的開發中，對于EJB 、Se
握好質量。
|
易的將我們在市場管理、銷售管理
，同時呼叫中心的大部分功能也可
因此，這就要求我們在開發過程中
開發的成本，加快開發的進度，并
rvlet的質量要求非常嚴格，項目
|
在前面已經提到，在開
為企業提供一個良好的易于
風險。以客戶信息為核心，
大為提高，維護性加強。對
一種“插件”，各個模塊功
制。
|
發CRM應用系統的數據結構時一
操作的用戶界面，另一方面是提
所有的模塊的內容都是圍繞客戶
于開發人員，尤其是系統分析員
能之間的耦合性大為降低，很顯
|
定要以客戶信息為核心，一方面是
高開發的可控性，減少開發成本與
，這樣也使得應用系統的可拓展性
，所有的功能內容對于他來說都是
然會使整個的開發過程更加易于控
|
在各個模塊的具體開發實施中，銷售
過銷售人員的銷售活動的信息支持，對于
實時的給與市場人員以信息支持，從而隨
應該說銷售管理、服務管理、呼叫中心以
，同時反過來，市場管理策略也給與其余
結構地設計上以客戶信息為核心數據。
|
模塊是基礎，他負責管理賬戶、機會等信息，并且經
客戶的信息（如需求、購買行為等）的補充，就可以
時把握銷售策略，便于及時調整。從某種意義上講，
及電子商務這四個模塊都是作為市場模塊的信息支持
企業活動以策略支持。要實現這一點，就必須在數據
|
CRM應用系統各個模塊
復雜的系統，我們不能按照
帶來應用系統在開發、擴充
象，將客戶資源作為操作的
|
之間的關系在企業業務上關系非
一般傳統的軟件工程觀念，在各
以及維護方面等很多的問題。正
核心。
|
常緊密，但是作為一個非常龐大和
個模塊之間通過接口通信，這樣會
確合理的方案是將客戶視做一個對
|
基于客戶對于CRM應用
用系統各個模塊中除了呼叫
成瘦客戶端（瀏覽器）/服
較，我們最終確定采用在J2
較成熟的技術規范，相對于
從很久就一直跟蹤分布式開
書籍)。因此，比較了幾種
務邏輯抽象出來，寫成組件
臺界面，調用后臺的商務邏
|
系統的實際需求以及考慮到系統
中心可以做成客戶/服務器(C/S)
務器(B/S)模式。經過了反復的
EE平臺上開發CRM應用系統的技
微軟的.NET來說，它的開發要更
發的技術，對于J2EE的開發非常
開發平臺之后，我們決定采用J2
，然后將其發布到服務器上，再
輯。
|
的未來拓展性、可維護性，CRM應
體系模式之外，其他模塊都應該做
論證并且通過與別的技術方式的比
術方案。一方面是因為作為一種比
加安全、成本更低，另一方面，我
熟悉。(當時還沒有相關的中文版
EE。在這種開發平臺上，我們將業
通過前臺程序的開發程序員開發前
|
市場管理、銷售管理、服務管理之所
需要，可以不受地域的限制，隨時隨地地
。因為我們看到，在呼叫中心模塊中有銷
其余模塊的商務邏輯，我們將其抽象出來
。
|
以采用分布式的開發，一方面是滿足業務人員的辦公
辦公，另一方面也是為了降低開發的成本與維護成本
售管理、服務管理等內容，同時電子商務模塊中又有
，一是組件復用，二是減少開發工作量同時減少風險
|
任何一個有經驗的Java
綜合程度，并且發展非常迅
統級別程序設計提供了豐富
，它定義了整個標準的應用
注意力集中在封裝商業邏輯
都由應用程序容器或者服務
的運行時屬性都可以使用高
供了一個簡化的開發模型，
發商和應用服務器無關。
|
平臺開發人員，都會知道這個平
速。Java平臺的許多應用程序接
的功能。J2EE是一種技術規范，
開發體系結構和一個部署環境，
和商業規則上，一切與基礎結構
器來處理。甚至，從屬于事務、
度靈活的聲明方法在部署環境中
它具有工業強度的可拓展性，支
|
臺具有非常強大的功能和非常高的
口(API)為各種應用程序設計和系
他給開發人員提供了一種工作平臺
在這個體系結構中，應用開發者的
服務相關的問題以及底層分配問題
持久化、安全等等方面的應用組件
定制(一般采用XML)。這個平臺提
持合理的集成和靈活的部署，與開
|
對于開發人員來說，J2EE平臺提供給
式。
|
他們的就是三種，Jsp、Servlet、EJB這三種開發方
|
Jsp其實是一種高層的S
在執行時有一些不同。Jsp
執行就和Servlet的一樣了
然后輸出結果。
|
ervlet。他與以往的其他網頁編
引擎將它和它所在的HTML文件一
：先編譯成.class文件，然后由
|
寫腳本有很大的相似性，但是只是
起合成Servlet的代碼，然后它的
支持java虛擬機的服務器來執行，
|
| 我們在使用Jsp中可以使用JavaBean來進行更加靈活的處理。 |
Servlet可以被看作是
這兩個對象來輸出和接收用
問別的Servlet方法、調用E
具來進行開發。在一般的工
一般的java語言就可以進行
|
服務器端的applet，它通過Serv
戶傳遞的參數，然后在內部的方
JB等等，然后將處理結果返回給
具中都已經構建好一個框架，程
開發了。
|
letResponse以及ServletRequest
法中執行操作，如訪問數據庫、訪
客戶端。可以通過集成化的開發工
序員只需要熟悉html標簽以及熟悉
|
EJB如果除去它的語言特點外，我想
可以輕松理解，他非常類似于微軟的DCOM
讓客戶進行透明調用，而不必關心位置，
相關的配置文件，以便告訴容器她要怎樣
開發工具，如JBuilder，就可以大大減少
容器信息，我們可以通過它的模板來完成
。
|
對于大多數有比較豐富編程經驗的開發人員來說應該
。他有一個自己要存活要活動的一個容器，為了可以
他還必須有一個本地和遠程接口，同時還應該有一個
的活法。對于開發人員來說，如果采用一種集成化的
工作量。在JBuilder中通過配置相關的服務器路徑、
一個EJB組件的開發以及分發，非常方便也非常簡單
|
在開發過程中，建議的
但是對數據庫的親和，而會
以結合這兩種bean的所有優
據庫的訪問同時會話bean用
|
開發方式是在會話bean內部調用
話bean中有我們為了控制程序而
點，來比較輕松的進行開發。比
來保存客戶的上下文信息。
|
實體bean，因為實體bean沒有狀態
需要的上下文信息，因此，我們可
如在會話bean中用實體bean進行數
|
| 3.3 J2EE各組成部分在開發CRM應用系統中的腳色 |
我們已經提到過，開發一個健壯的、
外我們都將采用瀏覽器/服務器模式。因
|
可拓展的CRM應用系統中的各個模塊，除了呼叫中心
此，下面的模式是除了呼叫中心模塊之外的方式：
|
瀏覽器--------〉Jsp腳本文件-----
EJB------訪問數據庫---------〉處理返
|
---調用---------〉Servlet------調用--------〉
回。
|
其中Jsp屬于前臺開發
，使用性強，便于操作；
|
人員進行的開發內容，也就是提
|
供給客戶的用戶界面，要求是美觀
|
Servlet、EJB為后臺開
他們主要是進行企業的商務
的獨立性與組合性。
|
發人員開發的具有可以重用性的
邏輯的處理。要求是開發的程序
|
包含商務邏輯的組件，也就是說，
一定要健壯，充分注意到業務邏輯
|
在開發CRM系統時，前面已經說過，
系統業務的理解程度將極大的決定了系統
完全細化到Servlet、EJB組件所封裝的商
|
系統分析員自身對于J2EE技術的把握深度，對于CRM
的成功與否。就是在做系統分析時一定要做到將功能
務邏輯中去，并且要反復論證其合理性與獨立性。
|
Jsp相對來說比較簡單，但是在開發
放到Jsp文件中，有幾個原因，一是Jsp文
的開發，將會極大的增加開發與維護成本
后將版面分割成不同的部分，用不同的被
某些與程序邏輯實現無關的動態內容最好
的Jsp文件時系統分析員要注意下面的幾
|
過程中系統分析員一定要注意盡可能少地將商務邏輯
件本身的可維護性比較差，尤其是如果不采用的方式
。因此，在前臺的Jsp開發中首先要劃分出版面，然
包含文件來最終組成用戶界面。另外要注意的一點是
放在數據庫中，而不要放在文件中。所以在開發前臺
個問題：
|
| 1、劃分版面的界面邏輯，用包含文件的方式給程序員確定開發代碼； |
| 2、盡量不將商務邏輯放在Jsp文件中，所有的業務處理都要調用后臺的組件； |
3、當涉及到的界面邏
Jsp文件中直接嵌入java代
|
輯較多的時候，要給程序員設計
碼，否則會造成Jsp文件的可讀
|
JavaBean來進行處理，而不是在
性非常差，維護與調試異常困難。
|
Servlet作為在服務器
的、準確等的要求外，還有
相比通用網關接口CGI有著
的線程，但是可能很多程序
間是共享的，并且如果存在
鼓勵程序員多注意利用Java
synchronized技術等）解決
的訪問數據庫會造成數據庫
分配連接并在釋放以后能夠
|
后臺進行處理的組件，除了業務
一個很重要的要求：就是線程安
明顯的優點就是可以維護一個線
員都會意識不到一個經常會遇到
著Servlet鏈互調時，就會發生
提供的方法（如聲明自己的類實
線程的問題，另外還要注意的是
服務器的負擔同時使客戶端的回
回收的連接池。所以，在開發Se
|
上商務邏輯要獨立、完整、可組合
全性。顯然，我們都知道Servlet
程池，不用每一次都要創建一個新
的問題：實例變量在所有的線程之
數據錯誤。因此系統分析員一定要
現了Runnable接口或者采用同步
數據庫的連接問題，因為如果頻繁
饋速度變慢，因此要注意利用預先
rvlet也要注意下面的3個問題：
|
1、鼓勵程序員關注線
步synchronized技術等解決
|
程安全問題(如采用聲明自己的
線程的問題)；
|
類實現了Runnable接口或者采用同
|
2、數據庫的訪問要充
|
分利用JDBC技術的預先分配連接
|
并在釋放以后能夠回收的連接池；
|
3、鼓勵系統分析員將
實際的程序中通過Servlet
|
商務邏輯劃分成單個的獨立的可
鏈來完成某項商務邏輯。
|
通用的可重用的商務邏輯組件，在
|
EJB實際上單就程序的寫作方面要比S
甚麼就可以了，而不必關心事務的處理，
要求：
|
ervlet簡單的多，它使程序員只需要關心要實現的是
底層的操作等等問題。但是也還是有一些編程方面的
|
1、最好能夠在程序中
出現時語義的不一致問題；
|
將所有的static字段都聲明為fi
|
nal型的，這樣可以保證多個實例
|
3、不使用文件系統。E
詢，基本上是不用文件系統
|
JB組件可以通過環境命名上下文
。
|
用一種標準的方法進行環境實體查
|
| 4、禁用socket來進行監聽和接收連接，或者用其進行多路發送。 |
5、不可能用awt函數來完成鍵盤的輸
息，因為組件是用來在服務器端完成某一
|
入和輸出，如果有的話，應該是向控制臺輸出控制信
項商務邏輯的。
|
本章的內容是一個非常
，運行圖等等。因為某種原
|
大的部分，他所涵蓋的就是具體
因，這兒就不寫了，請諒解。
|
的開發方案，其中包括使用案例圖
|
| 第五章：技術層面控制J2EE平臺架構開發CRM的過程 |
在J2EE平臺上開發CRM應用系統，是
技術規范，各大IT服務器、中間件廠商也
竟.NET是一項新的技術規范，如果在其上
是在走向成熟。
|
一個非常優秀的方案，一方面J2EE是一項比較成熟的
都大力推崇并支持，盡管微軟大力推出.NET，但是畢
進行開發的話，風險顯然要大得多，而J2EE目前卻正
|
正像任何事情一樣，在
，在這個過程當中，有一個
握深度、對CRM應用系統的
系統分析員自身的素質決定
員對于客戶的需求的理解程
；其次是系統分析員的思維
到將商務邏輯進一步細化成
有著非常深的掌握，這是實
就在服務器端組件的開發上
是否規范與合理，而系統分
|
先進的J2EE平臺上開發CRM應用
非常重要的腳色：系統分析員。
業務理解程度很大得影響了開發
了開發的成功與否，這是一個非
度，只有深入的理解了客戶的需
是否嚴密，是否嚴謹，是否具有
獨立的可重用的業務邏輯與使用
施CRM的另外一個重要之處，因
，一個系統能否穩定，高效的運
析員在實施編碼階段的主要職責
|
系統必須要有一個良好的實施過程
系統分析員自身對于J2EE技術的掌
的過程，甚至可以毫不夸張的說，
常關鍵的因素。 首先是系統分析
求，才能夠將商務邏輯很好的劃分
很強的邏輯思維能力，因為這涉及
邏輯。第三是其是否對于J2EE技術
為在整個的開發過程中，其實重心
行，很大程度上取決于開發技術上
就是負責檢查程序員的程序代碼
|
在開發過程中另外一個
概念不同，它有著嚴格的分
|
注意的是開發人員的分工。在J2
工：
|
EE平臺上的開發與一般的軟件開發
|
| 2、后臺組件開發程序員（主要是Servlet與EJB）; |
| 3、后臺服務器實施技術人員(主要負責組件的管理)； |
| 5、前臺用戶界面程序員（主要是jsp程序員+美工）； |
在實際的實施過程中，后臺服務器實
，前臺用戶界面程序員可以充當前臺測試
|
施技術人員可以充當后臺組件測試人員的腳色，同樣
技術人員，因為他的頁面中所包含的邏輯比較少。
|
總結一下，關鍵的幾點
含有一種商務邏輯，一般的
何組合就是看系統分析員的
，盡量避免前臺程序員與后
而這是絕對不允許的，否則
在開發過程中一定要注意組
嚴格把關，這一點非常非常
|
：1、商務邏輯一定要劃分的非
商務邏輯應該是通過幾個組件的
功底了！）2、分工一定要明確
臺程序員的腳色互換，否則很可
隨著開發過程的進行，就會發現
件的商務邏輯的獨立性與唯一性
重要。
|
常合理，原則是一個組件中應該只
協同合作來實現的（如何劃分，如
，除了上面所列出的腳色充當之外
能造成商務邏輯組件之間的耦合，
越來越難以控制應用的開發。所以
，系統分析員和項目負責人一定要
|
應用系統都是開發商基于對某項業務
，即便是同一行業也有不同，因此，要根
都有一個共同的框架，就是上面所提到的
架+具體商務邏輯。而框架部分則就是上
象出來做成組件，以備復用。
|
的深刻理解而產生的，不同的行業有不同的商務邏輯
據客戶的實際需求來做。但是，作為一個CRM系統她
，因為，一套完整和實用的CRM系統可以看作是： 框
面要求系統分析員所做的工作：將通用的商務邏輯抽
|
本章應該是一個詳細的模塊設計，其
。出于和第四章同樣的原因，請諒解。
|
中包括組件組合使用圖，流程圖以及其他的文檔等等
|
| 第七章：國內CRM系統目前存在的問題以及采用J2EE技術進行的解決方案 |
我們研究過國內幾家CR
例子：
|
M系統，學習到很多的東西，但
|
同時也發現一些問題，現在舉幾個
|
| 1、 大而全，但是各個功能做的太過于簡單，無法實用。 |
| 2、 缺乏集成能力，無法將網頁、電郵、電話、傳真等集成。 |
就這三個原因，是因為在整個的設計
細、完整的劃分成個體的、獨立的功能組
加上如開發成本的壓力等。而如果是采用
開發，就會解決或者避免或者減輕這些問
，電子商務模塊基本上也就完成，只需要
|
上偏離了以客戶為中心的原則，沒有將客戶的需求詳
件，沒有將各個功能做成是以客戶為核心的插件，再
J2EE，并且嚴格的按照合理劃分的組件的方式來進行
題。比如，在開發完銷售模塊與服務模塊的組件之后
少許的其它組件就可以完成一個電子商務模塊。
|
posted on 2005-08-01 13:17
黑武士 閱讀(146)
評論(0) 編輯 收藏 所屬分類:
JAVA技術