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

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

　　摘要：以往信息系統(tǒng)軟件堆積在單獨的系統(tǒng)中, 存在可擴展性差、可靠性低和維護(hù)成本高的問題。雖然SOA服務(wù)被引入到后期階段, 但由于SOA使用總線模式, 因此這種總線模式會與特定的技術(shù)堆棧一起回收, 并與特定的技術(shù)堆棧緊密相關(guān)。通過將應(yīng)用程序和服務(wù)抽取到更小的應(yīng)用程序和服務(wù)中, 它可以更容易地改進(jìn)和擴展, 從而提高應(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ù)的未來方向。

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

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

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

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

　　1.1 主要研究內(nèi)容

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

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

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

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

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

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

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

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

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

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

　　REST (JAX-RS, Spring Boot) ;

　　RPC (Thrift, Dubbo) ;

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

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

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

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

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

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

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

　　2.1 項目擬采取的研究方法

　　1) 收集整理資料;

　　2) 分析實施過程中要解決的技術(shù)難點;

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

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

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

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

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

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

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

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

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

　　3.1 主要技術(shù)

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

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

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

　　4 結(jié)束語

　　使用微服務(wù)架構(gòu)構(gòu)建應(yīng)用程序很有意義, 因為它允許您同時具有水平縮放和垂直縮放功能;它還具有可在整個架構(gòu)中重復(fù)使用的額外API�？梢悦糠昼娞峁┬路�務(wù), 因此您必須擁有敏捷且響應(yīng)迅速的應(yīng)用程序平臺。這個平臺必須是未來發(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)分析

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

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

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

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

　　集成化供應(yīng)鏈?zhǔn)侵腹��?yīng)鏈內(nèi)部成員為了實現(xiàn)一個共同目標(biāo)而組建的一個“虛擬組織”, 組織內(nèi)部成員彼此間信息共享, 并通過一系列的協(xié)調(diào)與合作工作實現(xiàn)目標(biāo)。以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系包含兩種情況即傳統(tǒng)的競爭關(guān)系與合作關(guān)系。這樣的客戶關(guān)系需要企業(yè)與客戶之間實現(xiàn)有效的資源共享, 因此必須建立一種全新的、具有不同層次的客戶信息管理系統(tǒng)。[1]該系統(tǒng)需要滿足以下幾個方面的要求。 (1) 具備有效的客戶數(shù)據(jù)分析功能, 為相關(guān)的決策人員提供可靠的數(shù)據(jù)參考。 (2) 必須具有面向客戶的交互平臺, 讓客戶可以及時獲得信息, 以及與企業(yè)取得聯(lián)系。 (3) 具備企業(yè)和戰(zhàn)略合作伙伴的信息共享平臺, 實現(xiàn)信息流動, 為各個節(jié)點的企業(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ù)中心、功能層與用戶層三個部分組成。數(shù)據(jù)中心是由中心數(shù)據(jù)庫與客戶關(guān)系數(shù)據(jù)庫兩個部分組成。系統(tǒng)在獲得客戶的數(shù)據(jù)后會分別存儲在這兩個數(shù)據(jù)庫中。客戶關(guān)系數(shù)據(jù)庫涉及到的主要信息為各單位間的具體業(yè)務(wù)信息。最終中心數(shù)據(jù)庫的數(shù)據(jù)與客戶關(guān)系數(shù)據(jù)庫都會進(jìn)入多維數(shù)據(jù)庫, 從而實現(xiàn)對各類信息的保存與分析。管理系統(tǒng)的功能層是建立在對客戶數(shù)據(jù)的錄入的基礎(chǔ)上, 通過數(shù)據(jù)中心對數(shù)據(jù)信息進(jìn)行加工分析, 從而形成相應(yīng)的數(shù)據(jù)報告, 最終實現(xiàn)為企業(yè)提供數(shù)據(jù)支持的目的, 幫助公司決策層做出正確的決策。用戶層是由客戶、合作伙伴、業(yè)務(wù)員等多個單位共同構(gòu)成, 用戶層是面對客戶與合作伙伴等單位的交互平臺, 在這里客戶與合作伙伴可以獲得相關(guān)數(shù)據(jù)。

　　2.2 運營模式

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

　　以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系管理系統(tǒng)是建立在一系列數(shù)據(jù)保存與分析的基礎(chǔ)上的一個系統(tǒng)。在該客戶管理系統(tǒng)中主要運用的數(shù)據(jù)庫有中心數(shù)據(jù)庫、客戶關(guān)系數(shù)據(jù)庫、多維數(shù)據(jù)庫。數(shù)據(jù)庫可以實現(xiàn)對各單位數(shù)據(jù)信息, 并對這些分散的數(shù)據(jù)信息進(jìn)行融合、以便實現(xiàn)各種信息的查閱、存取與分析。[2]在進(jìn)行數(shù)據(jù)庫設(shè)計時需要確定數(shù)據(jù)收集范圍與數(shù)據(jù)收集方式;定義好數(shù)據(jù)的轉(zhuǎn)化、傳輸, 確保數(shù)據(jù)能夠進(jìn)入到正確的數(shù)據(jù)庫中并繼而完成相關(guān)的具體操作。此外, 數(shù)據(jù)庫還擔(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ù)挖掘是指對數(shù)據(jù)模型與數(shù)據(jù)之間深層次的關(guān)系進(jìn)行深一步的挖掘, 從而將隱藏在海量數(shù)據(jù)背后的信息找出來, 揭示信息內(nèi)部的規(guī)律性, 并呈現(xiàn)在相關(guān)決策人員面前。在完成數(shù)據(jù)采集后必須要對數(shù)據(jù)進(jìn)行挖掘, 從中獲取更多有用的信息, 從而為相關(guān)決策人員提供高質(zhì)量的數(shù)據(jù)參考。在具體的實施過程中, 首先要確保被選擇數(shù)據(jù)的準(zhǔn)確性。其次根據(jù)相關(guān)規(guī)則與時間序列進(jìn)行初步預(yù)測。最后再實踐工作中對結(jié)果進(jì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é)議。在實際的工作中, 主要采用的信息轉(zhuǎn)換協(xié)議為XML協(xié)議, 通過對SOAP技術(shù)進(jìn)行運用以完成標(biāo)準(zhǔn)畫的信息傳輸協(xié)議。在進(jìn)行系統(tǒng)建設(shè)過程中使用各種標(biāo)準(zhǔn)化的協(xié)議可以解決各系統(tǒng)間的不協(xié)調(diào)問題, 提高信息傳輸與轉(zhuǎn)換的穩(wěn)定性與效率。

　　4 結(jié)語

　　以集成化供應(yīng)鏈為基礎(chǔ)的客戶關(guān)系系統(tǒng)是是處理新時期企業(yè)與客戶復(fù)雜關(guān)系的有效系統(tǒng), 進(jìn)行該系統(tǒng)建設(shè)時必須對其內(nèi)部結(jié)構(gòu)與運形模式進(jìn)行深層次的了解, 并做好數(shù)據(jù)庫、數(shù)據(jù)挖掘技術(shù)的應(yīng)用工作。通過對系統(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è)時代, 2008 (10) :45-46.

　　[2]張繼德, 時斐.基于電子商務(wù)的供應(yīng)鏈管理應(yīng)用研究——以蘇寧易購為例[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è)計與實現(xiàn)論文06-28

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

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

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

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

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

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

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