各顯神通 CIO如何避免CRM系統(tǒng)測試盲點(diǎn)

申請免費(fèi)試用、咨詢電話：400-8352-114

盲點(diǎn)一般是指人們留意不到的地方，或者說令人意想不到的事物。其實(shí)盲點(diǎn)在生活中時刻存在。如衛(wèi)生盲點(diǎn)等等。其實(shí)在CRM系統(tǒng)測試中，也存在著一些盲點(diǎn)。即使具有最詳細(xì)的測試計劃，也不能夠保證百分之百的發(fā)現(xiàn)漏洞。在這里我們要做的就是如何有效的減少盲點(diǎn)，或者說將一些已知的盲點(diǎn)消除掉。在這里筆者就跟大家共享這方面的內(nèi)容。

　　一、多考慮意外情況

　　在實(shí)際工作中，如果企業(yè)的日常操作沒有任何意外，那么無論是CRM系統(tǒng)的開發(fā)，還是事實(shí)，都是非常輕松的一件事情?，F(xiàn)在之所以CRM系統(tǒng)的成功率不高，很大一部分原因就是因?yàn)槠髽I(yè)存在著各種各樣的意外情況。在系統(tǒng)開發(fā)時，由于缺乏預(yù)見性，沒有對這種意外情況采取措施，從而導(dǎo)致系統(tǒng)出現(xiàn)了漏洞。如果測試時，沒有發(fā)現(xiàn)這些漏洞，就存在測試的盲點(diǎn)。

　　當(dāng)企業(yè)的意外情況比較多(如客戶經(jīng)常改名)時，要在測試之前先做好準(zhǔn)備工作。如先根據(jù)自己的經(jīng)驗(yàn)，想象在供應(yīng)商改名時可能遇到的情況。如更改供應(yīng)商名字后，后續(xù)為處理的訂單該怎么辦?已經(jīng)有銷售訂單的客戶，后續(xù)有訂單時要出貨并生成相關(guān)憑證并進(jìn)行數(shù)據(jù)分析。改名后，是使用更改前的名字呢還是更改后的名字?在數(shù)據(jù)統(tǒng)計分析方面，采用的是全部的數(shù)據(jù)，還是按改名后的數(shù)據(jù)進(jìn)行分析與統(tǒng)計?這些內(nèi)容都需要在實(shí)現(xiàn)準(zhǔn)備中確認(rèn)清楚。其實(shí)只要靜下心來根據(jù)以往的工作經(jīng)驗(yàn)好好想想，要得到這些問題的答案并沒有多大的難度。

　　筆者擔(dān)心的是很多企業(yè)用戶在軟件測試時，往往不會先想到企業(yè)的實(shí)際情況。二是不管三七二十一，先用了再說。此時在根據(jù)標(biāo)準(zhǔn)業(yè)務(wù)來進(jìn)行軟件測試時，不存在什么問題。但是等到意外情況真的發(fā)生時，再來采取應(yīng)對措施，已經(jīng)來不及了。故筆者加以，在對CRM軟件進(jìn)行測試時，需要注意意外情況對軟件所造成的負(fù)面影響。

二、靈活性與BUG往往同時存在

　　很多用戶在選擇系統(tǒng)時，往往太過于追求系統(tǒng)的靈活性。但是他們往往忽視了一個關(guān)鍵性的內(nèi)容。即系統(tǒng)的靈活性往往是同Bug共存的。簡單的說，就是系統(tǒng)的靈活性越高，其可能存在的BUG也就越多。那么系統(tǒng)測試時發(fā)生的盲點(diǎn)也會越多。其實(shí)這也很好理解。CRM系統(tǒng)的靈活性主要是靠各種參數(shù)來實(shí)現(xiàn)的。而這些參數(shù)就好像是一個機(jī)器人的零件。零件越多，其出現(xiàn)故障的幾率也就越高。

　　為此筆者這里需要提醒大家，在考慮系統(tǒng)靈活性時，要同時兼顧系統(tǒng)可能存在的Bug。在做系統(tǒng)測試時，需要多多關(guān)注這些地方。

　　如在CRM系統(tǒng)選型時，有些企業(yè)用戶會關(guān)系客戶付款條件的靈活性上。如會根據(jù)客戶的信用狀況來調(diào)整客戶的收款條件。此時在系統(tǒng)測試時，就需要測試，這個收款條件更改之后，所影響的范圍有哪些?如只是對新訂單有效，還是會影響到現(xiàn)有的未結(jié)案的銷售訂單等等。

　　筆者建議，在測試時需要在這些類似的環(huán)節(jié)中多投入一些精力。在系統(tǒng)投入到生產(chǎn)使用之前，盡量將這些可能存在漏洞的地方一一摸清楚。能夠解決的解決，不能夠解決的則采取其它的應(yīng)對措施。

三、多測試，少紙上談兵

　　在系統(tǒng)選型時，軟件公司的咨詢顧問與實(shí)施顧問會將軟件說的天花亂墜。但是真的在使用時，用戶卻會發(fā)現(xiàn)使用的磕磕碰碰。此時軟件公司又會將責(zé)任推給企業(yè)，說企業(yè)的流程或者操作不夠規(guī)范。需要企業(yè)調(diào)整相關(guān)的操作，以符合系統(tǒng)的需要。

　　其實(shí)這很大一部分原因確實(shí)在于企業(yè)。當(dāng)然并不是說企業(yè)的流程或著操作方式不規(guī)范，而是說企業(yè)沒有做好相關(guān)的測試。在選型與系統(tǒng)測試時，太過于相信事實(shí)顧問與咨詢顧問的解說，而沒有自己實(shí)際去測試。有些不負(fù)責(zé)任的CRM提供商，就喜歡在這里玩貓膩。如某個功能明明系統(tǒng)里面無法實(shí)現(xiàn)或者還存在缺陷，但是卻欺騙說企業(yè)用戶可以實(shí)現(xiàn)。而使用事先準(zhǔn)備好的數(shù)據(jù)來迷惑用戶。為此如果用戶沒有自己親自測試幾次，而只是在那邊紙上談兵，那么一切都是白搭。

　　為此筆者在這里給大家的意見就是：少動嘴，多測試。通常情況下，CRM系統(tǒng)的主干流程一般出問題的幾率不大，為此只需要測試1到兩次即可。而容易出現(xiàn)問題的地方主要是哪些分支流程上。如其采用的客戶生命價值分析模型，相關(guān)參數(shù)是否考慮完整;項(xiàng)目管理員能否根據(jù)企業(yè)的實(shí)際情況來調(diào)整參數(shù)的設(shè)置(如設(shè)置某個參數(shù)的默認(rèn)值或者分析時暫不考慮某個參數(shù))等等。

　　說道這里筆者再揭露其中的一個黑幕。有些CRM軟件公司在一些核心模型上做的很漂亮。但是不少只是做的好看，但是并不使用。這有很多方面的原因所造成的。如可能這個分析模型本來就比較理論化，在實(shí)際工作中用途并不是很大。也有可能軟件在設(shè)計這個模型時，死搬硬套，缺乏靈活性，從而企業(yè)很難使用。當(dāng)然也有可能是企業(yè)企業(yè)的管理水平還沒有到達(dá)這個程度，還不能夠使用這個分析模型?？傊?，最好的分析模型，如果企業(yè)不能夠?yàn)槠渌茫彩呛翢o價值的。但是軟件公司的實(shí)施顧問或者咨詢顧問，則對這方面的使用限制避而不談。畢竟，只要企業(yè)多個一個模塊，那么他們就會有多一份收入。

　　要避免這個盲點(diǎn)，其實(shí)也很簡單。就是要自己去親身測試一下。如可以拿自己企業(yè)的基礎(chǔ)數(shù)據(jù)，利用系統(tǒng)的這個分析模型測試一下，看看得到的結(jié)果是否是自己所需要的。又或者得到的結(jié)果毫無科學(xué)依據(jù)，像看天書一樣。

　四、測試數(shù)據(jù)要真實(shí)

　　在進(jìn)行軟件測試時，基礎(chǔ)數(shù)據(jù)是少不了的。不過不少用戶在測試CRM系統(tǒng)時，喜歡“偷懶”。他們采取的基礎(chǔ)數(shù)據(jù)量跟實(shí)際工作中遇到的數(shù)據(jù)量會少許多。雖然從理論上來說，只要一個數(shù)據(jù)準(zhǔn)確了，那么其它數(shù)據(jù)也是準(zhǔn)確的。但是在實(shí)際工作中，由于各種意外情況的存在，就很難保證這個推斷的正確。

　　如現(xiàn)在要分析客戶的利潤貢獻(xiàn)率。此時需要考慮到產(chǎn)品的增值稅信息。即需要將增值稅從產(chǎn)品的銷售單價中剔除出去。這里就有一個細(xì)節(jié)問題。有些產(chǎn)品是免稅的，而有些產(chǎn)品需要收增值稅。對于免稅的產(chǎn)品，在剔稅計算時，就會出現(xiàn)錯誤。在剔稅時，核心公式就是銷售價格處以增值稅率。而免稅產(chǎn)品增值稅率為0。而0是不能夠當(dāng)作除數(shù)的。此時如果在軟件測試階段，采用的數(shù)據(jù)剛好都是需要收增值稅的產(chǎn)品。那么系統(tǒng)測試時就存在盲點(diǎn)。

　　為此筆者建議，在系統(tǒng)測試作業(yè)中，所采用的數(shù)據(jù)需要真實(shí)。最好能夠包含企業(yè)全部的情況。如可以抽取企業(yè)10%的數(shù)據(jù)作為系統(tǒng)測試的基礎(chǔ)數(shù)據(jù)。如果另外有一些比較特殊的情況，如免稅產(chǎn)品或者出口產(chǎn)品，則需要額外的將他們加入到基礎(chǔ)數(shù)據(jù)中了。

　　在系統(tǒng)測試時，我們雖然不能夠?qū)⑺忻c(diǎn)一網(wǎng)打盡，但是還是要朝這方面努力。在前期系統(tǒng)測試中發(fā)現(xiàn)的問題越多，在后續(xù)的工作中可以把握更多的主動權(quán)。