oracleebsCustomer講解

1、三、客戶（Customer）客戶是企業(yè)提供產(chǎn)品與服務(wù)的對象，是企業(yè)的衣食父母，是企業(yè)存在的前提條件。在當(dāng)今世界經(jīng)濟(jì)全球化、一體化，市場競爭日益充分、激烈的大背景下， 如何滿足客戶需求，為客戶提供周到、細(xì)致的服務(wù)，是企業(yè)經(jīng)營管理活動的頭 等大事。因此，在企業(yè)信息化實(shí)踐方面，相較于最近幾年才逐漸得到更多重視 的供應(yīng)商關(guān)系管理系統(tǒng) SRM，企業(yè)的客戶關(guān)系管理系統(tǒng) CRM的發(fā)展歷史淵源 要早得多，產(chǎn)品的發(fā)展現(xiàn)狀也豐富、完善得多。習(xí)慣上，人們很早就已經(jīng)將CRM 與傳統(tǒng)的ERP看作是屬于前后臺（Front-Office、Back-Office）范疇，可以相提 并論，具有一定獨(dú)立性的兩大產(chǎn)品。任何企業(yè)在市場

2、環(huán)境中總是同時扮演著“供應(yīng)商與客戶”兩種角色，作為“客戶”角色，要管理好自己的“供應(yīng)商”，這屬于SRM產(chǎn)品的范疇；作為“供 應(yīng)商”，要對自己的“客戶”進(jìn)行有效管理，這屬于 CRM產(chǎn)品的范疇。無論屬 于哪種角色，都存在著所謂“供應(yīng)商與客戶”的競爭關(guān)系，但是在市場競爭的 環(huán)境中，作為“供應(yīng)商的客戶”與作為“客戶的供應(yīng)商”兩者所處的競爭地位 與競爭優(yōu)勢是截然不同的，存在著明顯的強(qiáng)弱差距。這一差距反映到企業(yè)管理 實(shí)踐與SRM/CRM產(chǎn)品的系統(tǒng)設(shè)計(jì)上，也會表現(xiàn)出鮮明的特點(diǎn)。在企業(yè)管理實(shí)踐中，企業(yè)對于供應(yīng)商的管理，通常會采取“嚴(yán)進(jìn)寬出”的總體策略， 管理的重點(diǎn)放在供應(yīng)商的“準(zhǔn)入”資格認(rèn)證過程管理，以及使用

3、中的績效考核管理上。而 企業(yè)對于客戶的管理，則通常會采取“寬進(jìn)嚴(yán)出”的總體策略，管理的重點(diǎn)放在客戶的信 息收集與挖掘管理，以及使用中的風(fēng)險控制管理上。企業(yè)管理實(shí)踐這一根本性的策略差別， 使得系統(tǒng)在供應(yīng)商與客戶的主數(shù)據(jù)管理的內(nèi)容方面差別較大，客戶主數(shù)據(jù)管理的復(fù)雜性與 靈活性要求要明顯高于供應(yīng)商主數(shù)據(jù)。推而廣之，使用供應(yīng)商主數(shù)據(jù)的業(yè)務(wù)模塊如PO系統(tǒng)，使用客戶主數(shù)據(jù)的業(yè)務(wù)模塊如 OM系統(tǒng)，其復(fù)雜性也會有很大不同。有經(jīng) 驗(yàn)數(shù)據(jù)表明，PO與OM在系統(tǒng)實(shí)施上的相對困難程度比較是 120: 170。（一）客戶數(shù)據(jù)管理概述盡管對于一個確定的企業(yè)來說，其所具有的客戶范疇可能并不復(fù)雜，例如 有些生產(chǎn)專業(yè)儀器設(shè)備的

4、企業(yè)，其客戶面可能很窄，客戶數(shù)量也很有限，但作 為一個通用的、需要適應(yīng)各行各業(yè)需要的CRM/ERP產(chǎn)品，其客戶主數(shù)據(jù)所要考慮的因素，其所必須具有的靈活性與適應(yīng)性就異常復(fù)雜了。有些企業(yè)的客戶 可能是政府機(jī)關(guān)、公用事業(yè)單位、生產(chǎn)制造企業(yè)、服務(wù)業(yè)、分銷商、零售商、 個人消費(fèi)者等等，情況千差萬別。若從信息系統(tǒng)設(shè)計(jì)與管理的角度去考察，客 戶主數(shù)據(jù)需要重點(diǎn)考慮以下幾種情況：一是“潛在客戶”與“當(dāng)前客戶”。我們通常所說的“客戶”（Customer）實(shí)際上是個廣義的概念，它包括了兩種情況，一種即所謂“售前客戶”（Prospect，還未達(dá)成銷售，企業(yè)正針對其展開營銷活動（Marketing），或者正在向其提供報(bào)

5、 價，等待最終結(jié)果；一種是所謂“當(dāng)前客戶”（Account），已經(jīng)與之達(dá)成過交易，正在繼續(xù)為之提供產(chǎn)品或服務(wù)，希望未來能達(dá)成更多銷售。二是“集團(tuán)客戶” （Headquarter）與“子公司客戶” （Subsidiary）0有些企業(yè) 采取的集中采購的管理策略，由總部統(tǒng)一執(zhí)行采購下單，但由各下述企業(yè)收貨 付款，或者由總部統(tǒng)一議定采購條款、簽訂框架合作協(xié)議，但由下屬各企業(yè)執(zhí) 行具體采購過程。系統(tǒng)必須考慮這些企業(yè)之間的復(fù)雜關(guān)系，考慮銷售策略、價 格與條款政策、信用風(fēng)險管控活動等等在它們之間如何協(xié)調(diào)問題。三是“組織客戶”與“個人客戶”。有些企業(yè)產(chǎn)品或服務(wù)的對象，既可能是組織或單 位，也可能個人，需要進(jìn)行

6、差別化的管理；四是“直銷”與“分銷”。有些企業(yè)的產(chǎn)品由銷售部門直接賣給終端客戶（組織或個 人），但有些則可能需要通過“中間商或渠道伙伴”（一級代理、二級代理等）才能最終到達(dá)最終用戶手上；五是“集中銷售”與“分散銷售”。有些企業(yè)的產(chǎn)品線可能比較復(fù)雜，不同產(chǎn)品可能 由不同的銷售團(tuán)隊(duì)，執(zhí)行不同的銷售政策銷售給同一個客戶，企業(yè)必須考慮相互間如何協(xié) 調(diào)等冋題。六是“客商關(guān)系”。即有些企業(yè)的客戶可能同時還是企業(yè)的供應(yīng)商，存在互為買賣的 關(guān)系，客觀上需要在買賣政策、款項(xiàng)結(jié)算等方面做特殊考慮?？傊?，外部客戶的復(fù)雜性 （個人與組織、組織與組織間關(guān)系）、銷售過程的復(fù)雜性 （售 前、售中、售后）、企業(yè)內(nèi)部的復(fù)雜性（

7、不同產(chǎn)品、不同銷售團(tuán)隊(duì)、不同銷售地域）等等因 素的綜合作用，要求企業(yè)的客戶主數(shù)據(jù)管理必須滿足不同業(yè)務(wù)模塊（諸如Marketing、Sales Quote、Contract、i-Store等等）的不同功能使用的具體要求。（二） EBS交易社區(qū)架構(gòu)（TCA）早期的ERP產(chǎn)品對于供應(yīng)商與客戶主數(shù)據(jù)的管理要求相對比較簡單，主 要是滿足PO/AP模塊、OM/AR模塊等核心業(yè)務(wù)系統(tǒng)的要求。隨著企業(yè)信息系 統(tǒng)集成從核心業(yè)務(wù)系統(tǒng)向外圍支持系統(tǒng)如SRM/CRM的擴(kuò)展，以及企業(yè)管理的數(shù)據(jù)信息逐步由過去單個企業(yè)的 “分散”應(yīng)用向未來企業(yè)集團(tuán)化、全球化的“集 中統(tǒng)一”過渡，系統(tǒng)對于客戶及供應(yīng)商的主數(shù)據(jù)管理在完善性、靈

8、活性、可擴(kuò) 展性等方面提出了更高的要求。正是在這一需求的大背景之下，ORACLE于2000年提出了有關(guān)主數(shù)據(jù)管理（當(dāng)時主要是針對客戶）的所謂“交易社區(qū)架構(gòu)（Trading Community Architeture, TCA）” 的概念。所謂交易社區(qū)架構(gòu)TCA的概念，主要包含兩層涵義，一層是從“技術(shù)架構(gòu)” 角度的主數(shù)據(jù)如何共享去講的，系統(tǒng)中的各業(yè)務(wù)模塊被看作是“社區(qū)成員”，相互之間使用統(tǒng)一的主數(shù)據(jù)，系統(tǒng)只需集中維護(hù)單一的數(shù)據(jù)來源。有關(guān)這一層涵 義，今天人們已經(jīng)很熟悉，無需多講；二層涵義是從“業(yè)務(wù)應(yīng)用”角度的主數(shù) 據(jù)如何“模型化”角度去講的，正如前文已經(jīng)提到，任何企業(yè)在市場環(huán)境中， 都同時承擔(dān)著

9、既是供應(yīng)商又是客戶的雙重角色，作為每一獨(dú)立存在的企業(yè)個體， 在系統(tǒng)中也仿佛組成了一個“社區(qū)”，“社區(qū)成員”相互之間有時也存在著復(fù)雜 的交易連接關(guān)系。以下重點(diǎn)介紹 ORACLE客戶數(shù)據(jù)“業(yè)務(wù)應(yīng)用”層面的 TCA 架構(gòu)模型化問題。既然每一個企業(yè)作為“商業(yè)實(shí)體”是一種客觀存在，那么其在系統(tǒng)中首先也可以被看作是一個具有身份標(biāo)識、獨(dú)立存在的“交易方”（Party），該“交易方”可以是組織，也可以是個人，擁有自己的、不依賴于其他方的數(shù)據(jù)信息，如組織、人員、產(chǎn) 品、物理地址等等。在未與這些“交易方”產(chǎn)生真實(shí)的買賣活動之前，或曰“售 前”階段，這些“交易方”同樣屬于廣義的“客戶”概念范疇（Prospect,需

10、要在系統(tǒng)中對它們相關(guān)的市場活動進(jìn)行有效管理。一旦與交易方（Party）達(dá)成買賣協(xié)議或開始下單，則可能需要與交易方達(dá)成 一種或多種“買賣關(guān)系”，對于每一種“買賣關(guān)系” ，EBS系統(tǒng)將之稱為“賬戶（Accoun）'，注意，不要將這里的賬戶 Account與所謂的“銀行賬號 Bank Account'相混淆；在每一個賬戶 Account之下，為了進(jìn)一步區(qū)分某些交易屬性（例如收單地點(diǎn)、銀行賬號等），可以再分為多個“賬戶地點(diǎn)” （Account Site； 一個“交易方”與“賬戶”的組合（Party+Account）稱之為“客戶 Customer'（而不是Prospec）。我們通

11、常所說的“客戶經(jīng)理”，其英譯“Account Manager”, 正是很好地體現(xiàn)了這里的所謂“交易方賬戶”的概念。在EBS系統(tǒng)中所謂的“客戶間關(guān)系”，主要是指“交易方關(guān)系”而言的，由 于交易方Party是獨(dú)立的存在，Party之間所建立的關(guān)系也是一種客觀存在，不 依賴于與己方所建立的某種買賣關(guān)系（Account），故而，這種“交易方關(guān)系” 可以適應(yīng)于所有業(yè)務(wù)系統(tǒng)（而不僅僅是傳統(tǒng)的 OM/AR系統(tǒng)）的使用需要。早期的EBS版本（以及很多其它品牌的 ERP產(chǎn)品）在實(shí)際應(yīng)用中，人們都 習(xí)慣于以“供應(yīng)商地點(diǎn)、客戶地點(diǎn)”來表達(dá)“總公司與子公司”的關(guān)系或?qū)哟?結(jié)構(gòu)，但基于EBS的TCA架構(gòu)，對于客戶的“層

12、次結(jié)構(gòu)”關(guān)系， ORACLE強(qiáng) 烈建議不要使用“客戶地點(diǎn)”來表達(dá)，因?yàn)橄嚓P(guān)CRM模塊的諸多應(yīng)用（例如“商 機(jī)管理”等）是建立在 Party而不是Site之上的。對于一個總公司附帶若干分 公司、子公司的客戶情形，只要客觀上需要將某一個分、子公司在市場營銷、 客戶管理方面重點(diǎn)對待，ORACLE的建議傾向于為之建立單獨(dú)的 “ Party”實(shí)體 （細(xì)粒度管理），而不是降格為Site。關(guān)于TCA的一個賬戶 Account可以有多個“賬戶地點(diǎn) Account Site"的問 題，其含義類似于原來的“一個供應(yīng)商或客戶可以有多個地點(diǎn)Site”。而一個交易方Party具有多個賬戶Account的問題，

13、主要是為了滿足己方（而不是交易 方或客戶）內(nèi)部業(yè)務(wù)管理復(fù)雜性的需要，例如公司有性質(zhì)迥異的兩種不同產(chǎn)品（如電視機(jī)和X光機(jī)），有不同的銷售團(tuán)隊(duì)、商務(wù)策略以及生產(chǎn)廠家，但可能具 有同一個客戶（交易方），為了在內(nèi)部管理上加以區(qū)分，貝U可以在一個Party之下建立多個Accounts這有點(diǎn)類似你去同一個銀行的不同支行開了多個戶頭，銀行（一般是分行級）的業(yè)務(wù)管理系統(tǒng)第一次會根據(jù)你的身份證信息建立一個統(tǒng) 一的“客戶號”（類似Party Number），以后你在任一支行所開的戶頭均屬于此 客戶號之下的 Accounts按照ORACLE在多年以前的有關(guān)設(shè)想，最終包括供應(yīng)商數(shù)據(jù)在內(nèi)，所有 有關(guān)客戶的系統(tǒng)應(yīng)用都要逐

14、步遷移并適應(yīng)于 TCA架構(gòu)。但遺憾的是，近十年時 間過去，或許不可見的“技術(shù)架構(gòu)”層面的TCA工作早已完成，但可見的、業(yè)務(wù)應(yīng)用層面的TCA工作的進(jìn)展還是比較緩慢：供應(yīng)商主數(shù)據(jù)的TCA似乎尚未啟動，客戶主數(shù)據(jù)的TCA才開了一個頭，核心業(yè)務(wù)系統(tǒng)如 OM/AR的改造尚有 很長的路要走，目前還無法實(shí)現(xiàn)“ Party”層與“Account”層的數(shù)據(jù)分離，還無 法實(shí)現(xiàn)按“ Party”（或Account）實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)與活動的“卷積” （Roll-Up）。甚至于用"交易方 Party+賬戶Account”這個概念取代傳統(tǒng)的 “ CunstomeF' 概念都有一定困難。原先在 R11后期版本

15、中出現(xiàn)的Party術(shù)語，在R12版本中 甚至被改回用 Customer術(shù)語代替，原先的 Party Number則被改稱為 Registry ID。在系統(tǒng)中創(chuàng)建 Party（Customer）的同時，必須同時為之創(chuàng)建 Account, Party 或Customer與 Account被捆在了一起（原先的設(shè)想是根據(jù)需要再創(chuàng)建 Account）。 看來，ORACLE的主數(shù)據(jù)TCA架構(gòu)適應(yīng)性改造還任重道遠(yuǎn)，是一項(xiàng)艱巨的長 期任務(wù)。盡管TCA架構(gòu)的目前使用尚不完善，使用范圍有限，但在下面有關(guān)客戶 主數(shù)據(jù)的具體介紹中，將會不時出現(xiàn)它的身影，故為了幫助理解有關(guān)內(nèi)容，這 里有必要對其概念與內(nèi)涵作簡要介紹。（

16、三）客戶的配置文件分類（ Profile Class）盡管在R11中，“客戶配置文件分類”的設(shè)置并非為創(chuàng)建客戶數(shù)據(jù)的前提條 件，但在R12中，由于被改成了必須的前提條件，故這里要首先對之作介紹。 所謂“客戶配置文件分類”，簡單說就是對具有相似信譽(yù)、業(yè)務(wù)量和付款周期（以 及滯納費(fèi)用制度）的客戶（賬戶 Account）進(jìn)行分組。對于每個配置文件分類， 可以定義諸如信用限額、付款條件、對帳單周期、開票和折扣信息之類的信息。 也可以為經(jīng)營業(yè)務(wù)所用的每種幣種定義財(cái)務(wù)費(fèi)用、催款和對帳單限額等等信息。 如下圖82所示：:一種為準(zhǔn)時付款客戶，他們具作為業(yè)務(wù)實(shí)例，可以定義三種“客戶配置文件分類”有良好的信用限額

17、；一種為延遲付款客戶，他們具有較高的財(cái)務(wù)費(fèi)用利率；另一種為經(jīng)常 準(zhǔn)時付款的客戶，可以通過提供折扣來鼓勵他們提前付款。定義的“客戶配置文件分類”被客戶（Accoun”所引用后，則該客戶就具有了配置文件中所定義的所有相關(guān)屬性。對于已經(jīng)定義的配置文件相關(guān)字段進(jìn)行修改，在保存時系統(tǒng)會詢問對于已經(jīng)引用該配置文件的客戶的相關(guān)字段如何處理，如下圖83所示:4程3rt: ® P :Tradir CcrDuuii ty：配置文件分婁信用配置文件配置文件井類金頷St Oracle 應(yīng)州產(chǎn)品 - Vision名稱文件® 編輯 萱著電）工件產(chǎn)Q Tjij r；帖亦 幫勖Q?）SERACS-區(qū)壩和地

18、（Z區(qū)俎利地區(qū) 中磚時間醫(yī)塚矮口更改組級自型験贈交賀SBS 自動確認(rèn)交賀SIE 處理交費(fèi)SRS戶Tradi Cmwwjnity-交易社匱-奮戶標(biāo)堆圧總3信用檢查（C）o更新選項(xiàng):更新所有配置文件（Q事更新所有未目定義的配置文件）配直文件分類合并管理黃系分類-DQJ宇皆找記錄：1/11 .| . <osc>具體包括：“不更新現(xiàn)有配置文件”，即配置文件分類的更改只對新增客戶數(shù)據(jù)有效;“更新“更新所有配置文件”，即配置文件分類的更改對包括已存在的所有客戶數(shù)據(jù)有效;所有未自定義的配置文件”，即只更新與當(dāng)前被更改值具有相同值的客戶數(shù)據(jù)。顯然，系統(tǒng)的這種控制方式，對于批量定義、維護(hù)客戶數(shù)據(jù)的某

19、些字段內(nèi)容將十分方便、靈活。R12與R11的客戶配置文件相比，內(nèi)容及 Tab頁分組有一定變化，如下圖84所示：總的來說，客戶配置文件的字段屬性主要是應(yīng)用于AR系統(tǒng)中（個別與 0M系統(tǒng)有關(guān)，如信用檢查等），為AR系統(tǒng)相關(guān)字段提供默認(rèn)值或控制有關(guān)業(yè)務(wù)行為?！翱蛻襞渲梦募诸悺币?yàn)橹蛔饔糜诳蛻舻?Account層或Account Site層（被引 用），故稱之為“賬戶配置文件”可能更合適。有關(guān)客戶配置文件字段詳情，請 參考ORACLE相關(guān)文檔，這里不贅述。（四）客戶的創(chuàng)建規(guī)則目前，無論是 R11還是R12，當(dāng)在其中創(chuàng)建新客戶（Customer）時，系統(tǒng) 均需要同時創(chuàng)建一個賬戶 Account及其賬戶

20、地點(diǎn)Site。R11與R12的共同之處 是，Acount與Site均可由系統(tǒng)自動生成（或手工輸入）的編號Number作為唯一性標(biāo)識，Site必須具有真實(shí)的物理地址 Address R11與R12的不同之處在于， R11 的賬戶名 Account Name變成了 R12 的賬戶說明 Account Description R12 的Account Site還可以為之給定一個地點(diǎn)名 Site Nameb系統(tǒng)同時還會給客戶自 動創(chuàng)建（或手工輸入）一個“頂層”的唯一性編號 Number，在R11中稱為交易 方編號Party Number，在R12中稱為注冊號 Registry ID。在R12中創(chuàng)建新客

21、戶時，首先需確定客戶類型是“組織”還是“個人”，然 后在“賬戶信息”區(qū)域選擇賬戶類型是“外部”還是“內(nèi)部”。“內(nèi)部”表示公司內(nèi)部客戶的賬戶，“外部”表示公司外部客戶賬戶。必須為賬戶賦予一個賬戶 地點(diǎn)的物理地址，并同時為該“賬戶地點(diǎn)”指定其所屬的業(yè)務(wù)實(shí)體OU，及其業(yè)務(wù)目的（收單方、收貨方等等）。如下圖85所示：ORACLG*交易社區(qū)客戶客戶Create Organization容尸突型ORGANIZATION組織名TEST別名名稱發(fā)音J-N-S編號URLJContext ValueI嶽戶信息條戶說明配豎文件分類TESTDEFAULT帳戶類盤外部二J 1系統(tǒng)會為新創(chuàng)建的客戶自動生成（或手工輸入）注

22、冊標(biāo)識號（亦即Party Number）、客戶賬戶號（Account Number）以及賬戶地點(diǎn)編號（Account Site Numbe）。然后可以根據(jù)業(yè)務(wù)需要，為該客戶添加新的賬戶 Account （及其Site，所屬的OU以及業(yè)務(wù)目的等），也可以為當(dāng)前賬戶Account添加新的地點(diǎn)Site信息。如 下圖86所示：ORACLe*交易社區(qū)客戶bbhCustomer: TEST客戶塊型Organization修戶配置文件0通信交易方關(guān)系稅配畫文件戟戶開始迭擇集號帳戶說四配置文件分類主要牧單地址狀態(tài)詳細(xì)信息a 5852 mDEFAULTBEURG 中國有效狀態(tài)W3用途1業(yè)務(wù)實(shí)體13r顯示扌地址行

23、1 1地址行2 |城市1?。ㄖ荩﹟國家（地區(qū)）|開始屈建施點(diǎn)Jfeit地點(diǎn)滋邨箱屆家（放反）1用途出務(wù)丈體| BEIJING.中國中國收單方Vision Operations24630客戶關(guān)閉窗口首選項(xiàng)幫助診斷關(guān)干此頁保童聲明R11的新客戶及其所屬賬戶的創(chuàng)建過程略為抽象，在輸入新客戶名稱后，系統(tǒng)如果未發(fā)現(xiàn)有重名，貝U會彈出是否“新建”的詢問界面，如下圖 87所示:文件 編輯謝 查看 文件夾心 T =L rp肛如 幫助渝程Rftrt:客尸：Tmdi6®/輸入客戶類型-權(quán)眼和職竟定義陣-區(qū)堀和地區(qū)中轉(zhuǎn)的 區(qū)域摟 發(fā)運(yùn)確更改組級自幼蘇籍交貧 自渤離認(rèn)交賽 處理交費(fèi)SK-Tradi 1% Ccud-交易耳丁二宮尸標(biāo)準(zhǔn)基本高級文本r霑戶名稱皿T帳戶塔r地址郵