客戶關(guān)系管理系統(tǒng)論文

　　題目：基于微服務(wù)架構(gòu)的客戶關(guān)系管理系統(tǒng)的研究

　　摘要：以往信息系統(tǒng)軟件堆積在單獨(dú)的系統(tǒng)中, 存在可擴(kuò)展性差、可靠性低和維護(hù)成本高的問(wèn)題。雖然SOA服務(wù)被引入到后期階段, 但由于SOA使用總線模式, 因此這種總線模式會(huì)與特定的技術(shù)堆棧一起回收, 并與特定的技術(shù)堆棧緊密相關(guān)。通過(guò)將應(yīng)用程序和服務(wù)抽取到更小的應(yīng)用程序和服務(wù)中, 它可以更容易地改進(jìn)和擴(kuò)展, 從而提高應(yīng)用的高并發(fā)和高應(yīng)用。作為在云中部署應(yīng)用程序和服務(wù)的新技術(shù), 微服務(wù)已成為當(dāng)今最新的熱門話題。關(guān)于微服務(wù)器的討論主要集中在容器或其他技術(shù)是否可以很好地執(zhí)行微服務(wù)。公司和服務(wù)提供商正在尋找更好的方式將應(yīng)用程序應(yīng)用于云環(huán)境, 它將是微服務(wù)的未來(lái)方向。

　　關(guān)鍵詞：IT行業(yè); SOA服務(wù)化; 微服務(wù);客戶關(guān)系管理系統(tǒng)

　　傳統(tǒng)的客戶關(guān)系管理系統(tǒng)的實(shí)現(xiàn)方式是所有服務(wù)端邏輯都集成在一起, 這樣的結(jié)構(gòu)導(dǎo)致系統(tǒng)的擴(kuò)展性差, 可靠性不高, 維護(hù)成本高。雖然有的引入了SOA服務(wù)化, 但是, 由于SOA使用總線模式, 這種總線模式與某個(gè)技術(shù)堆棧緊密耦合, 例如J2EE等特定技術(shù)堆棧緊密相連。這導(dǎo)致許多公司的現(xiàn)有系統(tǒng)難以對(duì)接, 交換周期太長(zhǎng), 成本太高, 新系統(tǒng)穩(wěn)定性的收斂需要一些時(shí)間。最終SOA看上去很美, 但卻被認(rèn)為是企業(yè)級(jí)奢侈品, 中小公司都望而生畏。本系統(tǒng)是基于我國(guó)中小企業(yè)的管理現(xiàn)狀, 基于微服務(wù)架構(gòu)研發(fā)出來(lái)的, 擴(kuò)展性好, 可靠性高, 維護(hù)成不高, 技術(shù)棧不受限, 例如, 客戶微服務(wù)最初是用java編寫的�，F(xiàn)在我們想要將客戶的微服務(wù)改為node Js技術(shù)。這完全是可能的, 而且由于擔(dān)心只是客戶的邏輯, 所以技術(shù)更換的成本將會(huì)降低很多。所以如果研發(fā)成功, 達(dá)到預(yù)期的目標(biāo), 必定受到我國(guó)中小企業(yè)的歡迎。

　　微服務(wù)架構(gòu)是一種基于云中部署應(yīng)用程序和服務(wù)的新技術(shù)。關(guān)于微服務(wù)的大多數(shù)討論集中在容器或其他技術(shù)是否可以很好地實(shí)現(xiàn)微服務(wù), 并且API應(yīng)該成為焦點(diǎn)。微服務(wù)可以在他們自己的程序中運(yùn)行并且可以通過(guò)“輕量級(jí)設(shè)備和HTTP型API進(jìn)行通信”。關(guān)鍵是服務(wù)可以在自己的程序中運(yùn)行。通過(guò)這個(gè), 我們可以區(qū)分服務(wù)公開(kāi)和微服務(wù)架構(gòu) (在現(xiàn)有系統(tǒng)中分部一個(gè)API) 。在服務(wù)公開(kāi)中, 許多服務(wù)可能受到內(nèi)部獨(dú)立進(jìn)程的限制。如果這些服務(wù)中的任何一個(gè)需要添加某個(gè)功能, 則該進(jìn)程必須縮小范圍。在微服務(wù)體系結(jié)構(gòu)中, 只需將所需功能添加到特殊服務(wù)而不影響整個(gè)過(guò)程。本文就基于微服務(wù)架構(gòu)的客戶關(guān)系管理系統(tǒng)進(jìn)行如下研究:

　　1 主要研究?jī)?nèi)容、擬解決的技術(shù)難點(diǎn)和關(guān)鍵技術(shù)

　　1.1 主要研究?jī)?nèi)容

　　1) 微服務(wù)架構(gòu)的研究;

　　2) 客戶關(guān)系管理系統(tǒng)的原有服務(wù)拆分粒度的研究;

　　3) 微服務(wù)分布式事務(wù)的研究;

　　4) 設(shè)計(jì)實(shí)現(xiàn)適合客戶關(guān)系管理系統(tǒng)的微服務(wù)架構(gòu)。

　　1.2 擬解決技術(shù)難點(diǎn)

　　1) API Gateway (客戶端如何訪問(wèn)這些服務(wù)) :傳統(tǒng)的開(kāi)發(fā)方法, 所有的服務(wù)都是本地的, 可以直接調(diào)用UI, 現(xiàn)在可以按功能劃分為獨(dú)立的服務(wù)�？蛻舳薝I如何訪問(wèn)他的服務(wù)。后臺(tái)有N個(gè)服務(wù), 前臺(tái)需要記住管理N服務(wù)。因此, 通常在后臺(tái)會(huì)有N個(gè)服務(wù)和UI之間的代理或API網(wǎng)關(guān)。他的功能包括:

　　提供統(tǒng)一的服務(wù)門戶, 使微服務(wù)對(duì)前臺(tái)透明;

　　整合后臺(tái)服務(wù)以節(jié)省流量并提高性能;

　　提供API管理功能, 如安全性, 過(guò)濾和流量控制;

　　2) 服務(wù)調(diào)用 (如何在服務(wù)之間進(jìn)行通信) :因?yàn)樗�有的微服�?wù)都是獨(dú)立運(yùn)行在不同機(jī)器上的獨(dú)立進(jìn)程, 服務(wù)之間的通信是IPC (inter process communication) , 并且有許多成熟的解決方案�，F(xiàn)在基本上最常見(jiàn)的是方法:

　　REST (JAX-RS, Spring Boot) ;

　　RPC (Thrift, Dubbo) ;

　　異步消息調(diào)用 (Kafka, Notify) 。

　　同步呼叫相對(duì)簡(jiǎn)單且一致, 但容易引發(fā)問(wèn)題, 性能體驗(yàn)稍差, 特別是長(zhǎng)時(shí)間的呼叫級(jí)別。異步消息方法在分布式系統(tǒng)中具有特別廣泛的應(yīng)用范圍。他不僅可以減少呼叫業(yè)務(wù)之間的耦合, 還可以緩沖呼叫, 確保消息積壓不會(huì)沖洗被呼叫者, 同時(shí)保證呼叫。派對(duì)的服務(wù)體驗(yàn)將繼續(xù)實(shí)現(xiàn)其自身的功能沒(méi)有被背景表現(xiàn)放慢。

　　3) 服務(wù)發(fā)現(xiàn) (有多少服務(wù)查找) :在微服務(wù)體系結(jié)構(gòu)中, 每種服務(wù)通常具有多個(gè)副本, 并通過(guò)Spring Cloud的Ribbon進(jìn)行負(fù)載均衡。服務(wù)隨時(shí)可能脫機(jī), 并且可能會(huì)響應(yīng)臨時(shí)訪問(wèn)壓力以添加新的服務(wù)節(jié)點(diǎn)。服務(wù)如何相互感知?服務(wù)如何管理?這是服務(wù)發(fā)現(xiàn)的問(wèn)題。微服務(wù)通過(guò)Spring Cloud的Eureka進(jìn)行注冊(cè)。當(dāng)服務(wù)上線時(shí), 服務(wù)提供商將其服務(wù)信息與注冊(cè)中心 (或類似框架) 一起注冊(cè), 并通過(guò)心跳保持長(zhǎng)鏈接以實(shí)時(shí)更新鏈接信息�？梢酝ㄟ^(guò)Spring Boot Admin對(duì)注冊(cè)中心的服務(wù)進(jìn)行監(jiān)控 (服務(wù)的內(nèi)存占用情況, 日志級(jí)別等) 。服務(wù)調(diào)用者訪問(wèn)Eureka, 通過(guò)服務(wù)名稱找到相應(yīng)服務(wù)使用服務(wù)。

　　4) 分布式微服務(wù)下的session問(wèn)題:在分布式架構(gòu)中, 由于服務(wù)是跨域訪問(wèn), 所以session很難做到共享, 要想共享session, 其中一種比較理想的方案則是將session信息存儲(chǔ)在redis緩存中。只需在maven的pom文件中加入相關(guān)依賴即可使用。

　　1.3 關(guān)鍵技術(shù)

　　本次研究選用了當(dāng)今比較成熟的springboot和springcloud作為開(kāi)發(fā)架構(gòu), Springboot微服務(wù)開(kāi)發(fā)架構(gòu), 提供了展現(xiàn)、依賴注入、持久化、嵌入式容器、日志、緩存等常用功能, Eureka主要是實(shí)現(xiàn)服務(wù)注冊(cè)發(fā)現(xiàn), Ribbon主要實(shí)現(xiàn)負(fù)載均衡, Hystrix主要是服務(wù)的延遲和容錯(cuò)。ZUUL主要是提供動(dòng)態(tài)路由功能。

　　2 項(xiàng)目擬采取的研究方法 (或技術(shù)工藝路線、實(shí)施方案) , 以及預(yù)期達(dá)到的目標(biāo)、主要技術(shù)、經(jīng)濟(jì)指標(biāo)和水平

　　2.1 項(xiàng)目擬采取的研究方法

　　1) 收集整理資料;

　　2) 分析實(shí)施過(guò)程中要解決的技術(shù)難點(diǎn);

　　3) 根據(jù)分析結(jié)果提出集中初步設(shè)計(jì)方案;

　　4) 對(duì)比分析各種初步方案, 確定合理解決方案。

　　2.2 預(yù)期達(dá)到的目標(biāo)預(yù)期達(dá)到的目標(biāo)、主要技術(shù)、經(jīng)濟(jì)指標(biāo)和水平

　　本次研究選用了當(dāng)今比較成熟的springboot和springcloud作為開(kāi)發(fā)框架, Springboot微服務(wù)開(kāi)發(fā)架構(gòu), 提供了展現(xiàn)、依賴注入、持久化、嵌入式容器、日志、緩存等常用功能, Eureka主要是實(shí)現(xiàn)服務(wù)注冊(cè)發(fā)現(xiàn), Ribbon主要實(shí)現(xiàn)負(fù)載均衡, Hystrix主要是服務(wù)的延遲和容錯(cuò)。ZUUL主要是提供動(dòng)態(tài)路由功能。

　　1) API Gateway (客戶端如何訪問(wèn)這些服務(wù)) 實(shí)現(xiàn)了提供統(tǒng)一服務(wù)入口, 使每個(gè)服務(wù)對(duì)前臺(tái)透明, 在后臺(tái)聚合, 節(jié)省流量, 提升性能, 提供安全, 過(guò)濾, 流控等管理功能。

　　2) 服務(wù)調(diào)用通用的有以下幾種方式:REST (JAX-RS, Spring Boot) ;RPC (Thrift, Dubbo) 。

　　3) 服務(wù)發(fā)現(xiàn):在微服務(wù)架構(gòu)中, 通常每個(gè)服務(wù)都是有多個(gè)拷貝, 通過(guò)Spring Cloud的Ribbon來(lái)做負(fù)載均衡。微服務(wù)是通過(guò)Spring Cloud的Eureka做注冊(cè)中心, 當(dāng)服務(wù)上線時(shí), 服務(wù)提供者將自己的服務(wù)注冊(cè)到注冊(cè)中心, 通過(guò)心跳維持長(zhǎng)鏈接, 實(shí)時(shí)更新鏈接信息。可以通過(guò)Spring Boot Admin對(duì)注冊(cè)中心的服務(wù)進(jìn)行監(jiān)控 (服務(wù)的內(nèi)存占用情況, 日志級(jí)別等) 。服務(wù)調(diào)用者訪問(wèn)Eureka, 通過(guò)服務(wù)名稱找到相應(yīng)服務(wù)使用服務(wù)。

　　4) 分布式微服務(wù)下的session問(wèn)題:在分布式架構(gòu)中, 由于服務(wù)是跨域訪問(wèn), 所以session很難做到共享, 要想共享session, 其中一種比較理想的方案則是將session信息存儲(chǔ)在redis緩存中。只需在maven的pom文件中加入相關(guān)依賴即可使用。

　　3 主要技術(shù)及應(yīng)用轉(zhuǎn)化的前景預(yù)測(cè)分析

　　3.1 主要技術(shù)

　　html5、javascript、Ajax、Jquery、SQLSERVER2012、Maven、Redis、Git、springcloud、springboot等。

　　3.2 應(yīng)用轉(zhuǎn)化的前景預(yù)測(cè)分析

　　隨著業(yè)務(wù)敏捷性需求的增加, 我們開(kāi)始看到一個(gè)向“推送”架構(gòu)或者基于事件體系結(jié)構(gòu)的發(fā)展趨勢(shì), 即:一個(gè)服務(wù)發(fā)送一個(gè)事件, 一個(gè)或多個(gè)觀察者容器異步地運(yùn)行邏輯來(lái)響應(yīng)該事件, 而不需要通知事件生產(chǎn)者。另一個(gè)好處是, 在設(shè)計(jì)各自的服務(wù)時(shí), 開(kāi)發(fā)人員可以更加獨(dú)立。雖然開(kāi)發(fā)人員可以將容器環(huán)境構(gòu)建為事件驅(qū)動(dòng)架構(gòu), 但功能即服務(wù) (Faa S) 本身就體現(xiàn)了這種能力。在Faa S架構(gòu)中, 函數(shù)作為文本存儲(chǔ)在數(shù)據(jù)庫(kù)中, 并通過(guò)事件觸發(fā)。一旦調(diào)用了該函數(shù), API控制器就會(huì)接收消息并通過(guò)負(fù)載均衡器將其發(fā)送到消息總線, 消息總線將其排入計(jì)劃并提供給一個(gè)調(diào)用容器。執(zhí)行完后, 結(jié)果存儲(chǔ)在數(shù)據(jù)庫(kù)中, 并發(fā)送給用戶, 然后函數(shù)被分解, 直到再次觸發(fā)。Faa S的好處包括:1) 從編寫代碼到運(yùn)行服務(wù)的時(shí)間縮短了, 因?yàn)閯?chuàng)建或push源碼之后不需要做額外操作。2) 當(dāng)函數(shù)由Faa S平臺(tái) (如AWS) 管理和縮放時(shí), 開(kāi)銷會(huì)減少。然而, Faa S并非沒(méi)有自身的挑戰(zhàn)。由于Faa S要求將服務(wù)的每個(gè)部分解耦, 因此可能會(huì)出現(xiàn)難以發(fā)現(xiàn)、管理、編排和監(jiān)視的函數(shù)的擴(kuò)散。最后, 如果沒(méi)有依賴項(xiàng)的全面可視化工作, 就很難調(diào)試Faa S系統(tǒng), 可能會(huì)出現(xiàn)無(wú)限循環(huán)。

　　4 結(jié)束語(yǔ)

　　使用微服務(wù)架構(gòu)構(gòu)建應(yīng)用程序很有意義, 因?yàn)樗�允許您同時(shí)具有水平縮放和垂直縮放功能;它還具有可在整個(gè)架構(gòu)中重復(fù)使用的額外API�？梢悦糠昼娞峁┬路�務(wù), 因此您必須擁有敏捷且響應(yīng)迅速的應(yīng)用程序平臺(tái)。這個(gè)平臺(tái)必須是未來(lái)發(fā)展的方向。

　　參考文獻(xiàn)

　　[1]究竟什么是微服務(wù)架構(gòu)?[Z].Tech Target SOA[2015-10-23].

　　[2]Red Hat:API層是微服務(wù)架構(gòu)成功的關(guān)鍵[Z].Tech Target[2015-10-10].

　　[3]微服務(wù)與SOA:與其重用不如抓住敏捷性[Z].Tech Targe[2015-10-27].

　　客戶關(guān)系管理系統(tǒng)論文一（2）：

　　題目：以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系管理系統(tǒng)分析

　　摘要：隨著我國(guó)市場(chǎng)經(jīng)濟(jì)體制的完善與經(jīng)濟(jì)全球化的發(fā)展, 企業(yè)必須采用更為先進(jìn)的客戶管理系統(tǒng)以處理更為復(fù)雜的關(guān)系。本文對(duì)以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系系統(tǒng)進(jìn)行分析, 指出其組成結(jié)構(gòu)與運(yùn)行模式, 并對(duì)建設(shè)系統(tǒng)時(shí)用到的關(guān)鍵技術(shù)進(jìn)行分析, 希望能給廣大相關(guān)工作人員提供幫助。

　　關(guān)鍵詞：集成化供應(yīng)鏈; 客戶關(guān)系; 管理系統(tǒng);

　　隨著改革開(kāi)放的不斷推進(jìn), 我國(guó)市場(chǎng)經(jīng)濟(jì)體制越發(fā)完善, 市場(chǎng)競(jìng)爭(zhēng)模式也發(fā)生了巨大的變化�？茖W(xué)技術(shù)的快速普及縮小了各企業(yè)間產(chǎn)品間的差距�？蛻粼谶x擇產(chǎn)品時(shí)已經(jīng)不僅僅關(guān)注于價(jià)格與產(chǎn)品質(zhì)量, 對(duì)企業(yè)的服務(wù)也提出了更高的要求。在這樣的時(shí)代背景下, 任何企業(yè)都不可能獨(dú)立存在與發(fā)展。深度合作是大勢(shì)所趨, 基于集成化供應(yīng)鏈的客戶關(guān)系管理系統(tǒng)是企業(yè)未來(lái)發(fā)展的必然趨勢(shì)。

　　1 以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系管理系統(tǒng)

　　集成化供應(yīng)鏈?zhǔn)侵腹��?yīng)鏈內(nèi)部成員為了實(shí)現(xiàn)一個(gè)共同目標(biāo)而組建的一個(gè)“虛擬組織”, 組織內(nèi)部成員彼此間信息共享, 并通過(guò)一系列的協(xié)調(diào)與合作工作實(shí)現(xiàn)目標(biāo)。以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系包含兩種情況即傳統(tǒng)的競(jìng)爭(zhēng)關(guān)系與合作關(guān)系。這樣的客戶關(guān)系需要企業(yè)與客戶之間實(shí)現(xiàn)有效的資源共享, 因此必須建立一種全新的、具有不同層次的客戶信息管理系統(tǒng)。[1]該系統(tǒng)需要滿足以下幾個(gè)方面的要求。 (1) 具備有效的客戶數(shù)據(jù)分析功能, 為相關(guān)的決策人員提供可靠的數(shù)據(jù)參考。 (2) 必須具有面向客戶的交互平臺(tái), 讓客戶可以及時(shí)獲得信息, 以及與企業(yè)取得聯(lián)系。 (3) 具備企業(yè)和戰(zhàn)略合作伙伴的信息共享平臺(tái), 實(shí)現(xiàn)信息流動(dòng), 為各個(gè)節(jié)點(diǎn)的企業(yè)做出正確的決策提供數(shù)據(jù)、信息保障。

　　2 以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系管理系統(tǒng)的基本結(jié)構(gòu)

　　2.1 系統(tǒng)結(jié)構(gòu)

　　以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系管理系統(tǒng)主要由數(shù)據(jù)中心、功能層與用戶層三個(gè)部分組成。數(shù)據(jù)中心是由中心數(shù)據(jù)庫(kù)與客戶關(guān)系數(shù)據(jù)庫(kù)兩個(gè)部分組成。系統(tǒng)在獲得客戶的數(shù)據(jù)后會(huì)分別存儲(chǔ)在這兩個(gè)數(shù)據(jù)庫(kù)中�？蛻絷P(guān)系數(shù)據(jù)庫(kù)涉及到的主要信息為各單位間的具體業(yè)務(wù)信息。最終中心數(shù)據(jù)庫(kù)的數(shù)據(jù)與客戶關(guān)系數(shù)據(jù)庫(kù)都會(huì)進(jìn)入多維數(shù)據(jù)庫(kù), 從而實(shí)現(xiàn)對(duì)各類信息的保存與分析。管理系統(tǒng)的功能層是建立在對(duì)客戶數(shù)據(jù)的錄入的基礎(chǔ)上, 通過(guò)數(shù)據(jù)中心對(duì)數(shù)據(jù)信息進(jìn)行加工分析, 從而形成相應(yīng)的數(shù)據(jù)報(bào)告, 最終實(shí)現(xiàn)為企業(yè)提供數(shù)據(jù)支持的目的, 幫助公司決策層做出正確的決策。用戶層是由客戶、合作伙伴、業(yè)務(wù)員等多個(gè)單位共同構(gòu)成, 用戶層是面對(duì)客戶與合作伙伴等單位的交互平臺(tái), 在這里客戶與合作伙伴可以獲得相關(guān)數(shù)據(jù)。

　　2.2 運(yùn)營(yíng)模式

　　以集成化供應(yīng)鏈為基礎(chǔ)的客戶管理系統(tǒng)建立的目的是要處理復(fù)雜的客戶關(guān)系。在該系統(tǒng)中, 企業(yè)與客戶之間既有合作也有競(jìng)爭(zhēng), 因此, 集成化供應(yīng)鏈的基本運(yùn)行模式為螺旋型周期循環(huán)模式。在系統(tǒng)具體的運(yùn)行中, 需要為不同的用戶群體提供不同的終端。一方面可以滿足客戶、合作伙伴、業(yè)務(wù)人員等不同人員對(duì)于數(shù)據(jù)的要求, 另一方面也可以更加有效地收集其具體信息。在完成信息收集時(shí), 系統(tǒng)數(shù)據(jù)庫(kù)以及數(shù)據(jù)處理中心會(huì)根據(jù)數(shù)學(xué)模型展開(kāi)一系列復(fù)雜的運(yùn)算獲得, 最后以最直觀的形式出現(xiàn)在公司決策人員面前。這些決策人員會(huì)根據(jù)數(shù)據(jù)分析結(jié)果制定制定相關(guān)的發(fā)展計(jì)劃以及相關(guān)部門的管理制度、運(yùn)營(yíng)標(biāo)準(zhǔn)。相關(guān)部門需要根據(jù)這些標(biāo)準(zhǔn)開(kāi)展工作, 再通過(guò)系統(tǒng)收集相關(guān)信息繼而對(duì)工作標(biāo)準(zhǔn)加以調(diào)整、修改, 如此往復(fù)循環(huán)。該客戶管理系統(tǒng)的核心是用戶, 有效的數(shù)據(jù)分析可以為決策人員提供最為重要的數(shù)據(jù)參考, 有助于決策者做出正確的決定, 從而促進(jìn)企業(yè)的的發(fā)展進(jìn)步。

　　3 系統(tǒng)中應(yīng)用的關(guān)鍵技術(shù)

　　3.1 數(shù)據(jù)庫(kù)

　　以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系管理系統(tǒng)是建立在一系列數(shù)據(jù)保存與分析的基礎(chǔ)上的一個(gè)系統(tǒng)。在該客戶管理系統(tǒng)中主要運(yùn)用的數(shù)據(jù)庫(kù)有中心數(shù)據(jù)庫(kù)、客戶關(guān)系數(shù)據(jù)庫(kù)、多維數(shù)據(jù)庫(kù)。數(shù)據(jù)庫(kù)可以實(shí)現(xiàn)對(duì)各單位數(shù)據(jù)信息, 并對(duì)這些分散的數(shù)據(jù)信息進(jìn)行融合、以便實(shí)現(xiàn)各種信息的查閱、存取與分析。[2]在進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)需要確定數(shù)據(jù)收集范圍與數(shù)據(jù)收集方式;定義好數(shù)據(jù)的轉(zhuǎn)化、傳輸, 確保數(shù)據(jù)能夠進(jìn)入到正確的數(shù)據(jù)庫(kù)中并繼而完成相關(guān)的具體操作。此外, 數(shù)據(jù)庫(kù)還擔(dān)負(fù)著數(shù)據(jù)優(yōu)化的重要職責(zé), 數(shù)據(jù)優(yōu)化是確保數(shù)據(jù)準(zhǔn)確性的重要手段,

　　3.2 數(shù)據(jù)挖掘

　　大多數(shù)有用的信息都隱藏在數(shù)據(jù)背后。數(shù)據(jù)挖掘是指對(duì)數(shù)據(jù)模型與數(shù)據(jù)之間深層次的關(guān)系進(jìn)行深一步的挖掘, 從而將隱藏在海量數(shù)據(jù)背后的信息找出來(lái), 揭示信息內(nèi)部的規(guī)律性, 并呈現(xiàn)在相關(guān)決策人員面前。在完成數(shù)據(jù)采集后必須要對(duì)數(shù)據(jù)進(jìn)行挖掘, 從中獲取更多有用的信息, 從而為相關(guān)決策人員提供高質(zhì)量的數(shù)據(jù)參考。在具體的實(shí)施過(guò)程中, 首先要確保被選擇數(shù)據(jù)的準(zhǔn)確性。其次根據(jù)相關(guān)規(guī)則與時(shí)間序列進(jìn)行初步預(yù)測(cè)。最后再實(shí)踐工作中對(duì)結(jié)果進(jìn)行必須的驗(yàn)證, 從而得到準(zhǔn)確的結(jié)果。

　　3.3 信息集成

　　信息集成技術(shù)要求該系統(tǒng)與其他系統(tǒng)之間進(jìn)行數(shù)據(jù)同步、信息交流, 是客戶管理系統(tǒng)與其他系統(tǒng)進(jìn)行協(xié)作的基礎(chǔ), 是將客戶管理系統(tǒng)與其他系統(tǒng)進(jìn)行融合工作的紐帶。信息集成技術(shù)主要包含有信息轉(zhuǎn)換標(biāo)準(zhǔn)協(xié)議與信息傳輸標(biāo)準(zhǔn)協(xié)議。在實(shí)際的工作中, 主要采用的信息轉(zhuǎn)換協(xié)議為XML協(xié)議, 通過(guò)對(duì)SOAP技術(shù)進(jìn)行運(yùn)用以完成標(biāo)準(zhǔn)畫的信息傳輸協(xié)議。在進(jìn)行系統(tǒng)建設(shè)過(guò)程中使用各種標(biāo)準(zhǔn)化的協(xié)議可以解決各系統(tǒng)間的不協(xié)調(diào)問(wèn)題, 提高信息傳輸與轉(zhuǎn)換的穩(wěn)定性與效率。

　　4 結(jié)語(yǔ)

　　以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系系統(tǒng)是是處理新時(shí)期企業(yè)與客戶復(fù)雜關(guān)系的有效系統(tǒng), 進(jìn)行該系統(tǒng)建設(shè)時(shí)必須對(duì)其內(nèi)部結(jié)構(gòu)與運(yùn)形模式進(jìn)行深層次的了解, 并做好數(shù)據(jù)庫(kù)、數(shù)據(jù)挖掘技術(shù)的應(yīng)用工作。通過(guò)對(duì)系統(tǒng)數(shù)據(jù)的進(jìn)一步挖掘揭示數(shù)據(jù)背后的規(guī)律, 為相關(guān)決策者提供可靠的數(shù)據(jù)支持, 從而促進(jìn)企業(yè)的健康穩(wěn)定發(fā)展。

　　參考文獻(xiàn)

　　[1]鄭麗娟, 張乾.基于集成化供應(yīng)鏈的客戶關(guān)系管理系統(tǒng)研究[J].商業(yè)時(shí)代, 2008 (10) :45-46.

　　[2]張繼德, 時(shí)斐.基于電子商務(wù)的供應(yīng)鏈管理應(yīng)用研究——以蘇寧易購(gòu)為例[J].會(huì)計(jì)之友, 2014 (36) :122-126.

【客戶關(guān)系管理系統(tǒng)論文】相關(guān)文章：

客戶關(guān)系管理的論文07-28

客戶關(guān)系管理的論文07-28

商業(yè)銀行客戶關(guān)系管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)論文06-28

關(guān)于客戶關(guān)系管理的論文07-05

客戶關(guān)系管理論文08-22

管理系統(tǒng)設(shè)計(jì)論文08-10

關(guān)于客戶關(guān)系管理數(shù)據(jù)挖掘論文06-26

客戶關(guān)系管理的價(jià)值論文參考07-13

管理系統(tǒng)論文發(fā)表10-24

物資管理系統(tǒng)論文08-22