發(fā)布時(shí)間： 2017-01-04 
瀏覽次數(shù)： 1340
次 
迪森實(shí)施項(xiàng)目的經(jīng)驗(yàn)與大家分享，文字較長......
值得耐心閱讀，相信會收獲頗多！
根據(jù)國外研究表明，SAP系統(tǒng)在長期運(yùn)行后，對于企業(yè)戰(zhàn)略及卓越運(yùn)營的支撐能力在逐步降低，其中七年是一個拐點(diǎn)。造成這一問題的原因很多：技術(shù)架構(gòu)、解決方案、數(shù)據(jù)、硬件、運(yùn)維、業(yè)務(wù)及組織的變革、IT組織架構(gòu)……
正是在這樣背景下，許多公司都在進(jìn)行SAP系統(tǒng)的優(yōu)化實(shí)施工作，而優(yōu)化項(xiàng)目不同于新的實(shí)施項(xiàng)目，在需求分析、方案設(shè)計(jì)、系統(tǒng)測試、數(shù)據(jù)切換等階段都有著許多需要特別關(guān)注的地方，以下以一個實(shí)際優(yōu)化項(xiàng)目為例深度剖析。
▼背景介紹：這是一家通過經(jīng)銷商或賣場將產(chǎn)品賣到到最終消費(fèi)者的企業(yè)，因此對經(jīng)銷商的信用、返利的管控有很高的要求。七、八年前首次實(shí)施SAP，并通過標(biāo)準(zhǔn)功能和自開發(fā)結(jié)合實(shí)現(xiàn)了信用、返利的管理。但隨著市場的發(fā)展和內(nèi)控的需要，迫切需要對目前信用返利管理應(yīng)用進(jìn)行優(yōu)化完善。
還原需求本質(zhì)
▼項(xiàng)目啟動后，首先開始需求調(diào)研分析。經(jīng)過幾輪調(diào)研下來，第一個問題來了，之前客戶提到的按品類進(jìn)行額度授信的真正需求并不是為了區(qū)分授信，而是在授信額度中對某些品類的產(chǎn)品有銷量要求，例如在給客戶授信100萬時(shí)，客戶如果想用完這100萬額度，至少要買8萬的某類產(chǎn)品。
從業(yè)務(wù)實(shí)質(zhì)需求來看，這是考慮到季節(jié)原因，希望某類產(chǎn)品多賣，而信用管控不是控制在額度范圍內(nèi)賣嗎？這不是矛盾的嗎？
既然是優(yōu)化，先看看之前方案是怎樣做的，客戶希望優(yōu)化的點(diǎn)是什么。
經(jīng)過進(jìn)一步分析發(fā)現(xiàn)，之前系統(tǒng)中將此100萬授信分成了92萬和8萬兩部分額度，客戶授信92萬可以買所有產(chǎn)品，然后給該客戶再創(chuàng)建一個相應(yīng)的專用產(chǎn)品客戶（只能購買專用產(chǎn)品），該專用產(chǎn)品客戶的額度為8萬，這樣這個客戶如果想用滿100萬，必須用這兩個客戶下單，通過專用產(chǎn)品客戶用滿8萬額度，實(shí)現(xiàn)100萬額度用完至少滿夠8萬專用產(chǎn)品的目的。
顯然一個客戶在系統(tǒng)中要對應(yīng)創(chuàng)建一個專用產(chǎn)品客戶，如果以后有多個專用產(chǎn)品要進(jìn)行這樣信用管理，一個客戶將會有多個對應(yīng)的專用產(chǎn)品客戶，未來無論是給經(jīng)銷商還是給公司客戶管理都帶來巨大困難，因此，迫切需要改變這種專用產(chǎn)品客戶的做法。
從大的思路上來看，之前將100萬分成92萬和8萬兩部分信用額度的做法還是很巧妙的，按照這個思路，只需設(shè)置專用產(chǎn)品信控范圍對應(yīng)銷售范圍取代專用產(chǎn)品客戶就可以了，8萬額度設(shè)在專用產(chǎn)品信控范圍下，取消專用產(chǎn)品客戶。其余就是考慮新的銷售范圍、信控范圍帶來的影響分析及應(yīng)對等等。
▼很快，第二個問題來了，客戶返利管理的復(fù)雜度超出預(yù)期。首先客戶有多種返利模式，在系統(tǒng)中針對不同類型的返利業(yè)務(wù)有不同的TCODE（事務(wù)代碼）進(jìn)行處理。現(xiàn)有方案針對返利是通過生成特定預(yù)收款憑證來增加信用額度的。
本次項(xiàng)目的優(yōu)化需求就是要取消生成憑證的做法，因此，首先要搞清楚哪些業(yè)務(wù)和應(yīng)用涉及這部分處理。雖然通過與主要業(yè)務(wù)人員調(diào)研基本理清了主要的業(yè)務(wù)場景和類型，但是等上線后，由于后臺關(guān)閉了生成這類預(yù)收款憑證的設(shè)置，上線當(dāng)天突然有用戶反映有些返利業(yè)務(wù)做不了了，經(jīng)進(jìn)一步了解，才發(fā)現(xiàn)有些業(yè)務(wù)涉及其它部門和人員，調(diào)研時(shí)沒有考慮到，要不是把系統(tǒng)后門關(guān)了，是很難及時(shí)發(fā)現(xiàn)這些當(dāng)初沒納入項(xiàng)目范圍的業(yè)務(wù)的。
探尋解決方案之道
▼如同大多客戶一樣，由于人員頻繁流動、文檔管理不善，留下來可供項(xiàng)目組參考的文檔很有限，沒辦法通過文檔對整個方案和具體技術(shù)細(xì)節(jié)快速了解，只能根據(jù)業(yè)務(wù)理解看程序代碼了。
首先看返利導(dǎo)入，這是源頭，通過搜索生成會計(jì)憑證的BAPI自然就找到了這段代碼，如同黑箱子，這段代碼的輸入、輸出要保留，黑箱里的憑證處理邏輯替換掉，只是輸入輸出有點(diǎn)復(fù)雜，需要花時(shí)間慢慢梳理。正在慶幸之余，突然發(fā)現(xiàn)，導(dǎo)入的返利數(shù)據(jù)不僅生成憑證，還更新到了一些表里，這就有點(diǎn)復(fù)雜了，進(jìn)一步分析這些表，才發(fā)現(xiàn)是管理返利導(dǎo)入和匯總的。
通過對導(dǎo)入的分析，發(fā)現(xiàn)返利導(dǎo)入時(shí)分會計(jì)憑證和數(shù)據(jù)表兩條線進(jìn)行了更新，那按照這個理解，在消耗時(shí)應(yīng)該也是兩條線。由于是事后返，返利的消耗在開發(fā)票的時(shí)候處理，開發(fā)票用了自定義的TCODE，那一定是為了返利消耗處理包了一層殼。
迫不及待地去打開這個殼，里面真是復(fù)雜，各種規(guī)則進(jìn)行批量發(fā)票的處理等，但是按照創(chuàng)建會計(jì)憑證的BAPI和返利表的關(guān)鍵字在程序中都沒有搜到處理代碼。難道判斷有誤？看來這層殼不是為了處理返利的，只是為了處理批量發(fā)票。那在哪處理這返利的消耗呢？一定是增強(qiáng)。然后CMOD、SMOD、標(biāo)準(zhǔn)程序搜索、會計(jì)憑證替代都沒有找到，感覺人間蒸發(fā)了，但返利數(shù)據(jù)經(jīng)過測試確實(shí)消耗更新了。再一次陷入死胡同。
看來只有最后一招了，既然返利數(shù)據(jù)更新到自建表里去了，查這個表的所用處清單，看哪些程序、函數(shù)用到了這個表，一下子查出了幾十條，其中一條讓人眼前一亮，就是它，發(fā)票的BADI。此處必須致敬一下，這個增強(qiáng)點(diǎn)找的很好。果然返利消耗表的數(shù)據(jù)在此BADI處理，但并沒有看到會計(jì)憑證的處理。
兩條線的消耗，只找到了一條線，另外一條呢？再度陷入迷茫，有點(diǎn)黔驢技窮的感覺。只能再次如法炮制，查生成憑證BAPI的所用處清單，這次并沒有增強(qiáng)用到，而是有一堆自開發(fā)的程序用到了，通過進(jìn)一步篩選終于找到了這個程序，并且，這個程序是每五分鐘通過后臺作業(yè)調(diào)用執(zhí)行的，從而實(shí)現(xiàn)相對實(shí)時(shí)地創(chuàng)建會計(jì)憑證。
至此，兩條線導(dǎo)入、消耗的輪廓出來了，整個過程如同尋寶、探案。在此基礎(chǔ)上，后續(xù)優(yōu)化方案很快就制定出來了。
高難度的方案替換和信用規(guī)則實(shí)現(xiàn)
▼方案定下來了，就開始系統(tǒng)實(shí)現(xiàn)了。這個過程如同給病人做換心手術(shù)，之前心臟連著許多血管、神經(jīng)，新的心臟換上去后也必須和原來的血管、神經(jīng)連上，才能保證機(jī)體正常運(yùn)轉(zhuǎn)。本次項(xiàng)目也是一樣，把會計(jì)憑證的生成處理換掉了，但新的邏輯處理必須和處理前的輸入?yún)?shù)、處理后的消息處理、狀態(tài)回寫等無縫接上，這樣才不會破壞原來程序總的邏輯處理，并且回歸測試工作量會減少。
因此，接下來就是要靜下心來仔細(xì)分析這些輸入、輸出參數(shù)的具體賦值和被其它地方使用到的情況。難度很大，需要保持清晰的思路。經(jīng)過細(xì)致、繁瑣的分析、對應(yīng)過程，這部分工作順利完成。整個過程中，腦子里經(jīng)常浮現(xiàn)的是手術(shù)臺上一刀、一針、一線做手術(shù)的場景。
總結(jié)：優(yōu)化項(xiàng)目的具體實(shí)現(xiàn)不同于新實(shí)施項(xiàng)目，需要在原方案基礎(chǔ)上仔細(xì)考慮細(xì)節(jié)，盡量少動原來的代碼，保證新方案的業(yè)務(wù)處理和現(xiàn)有其它業(yè)務(wù)處理無縫銜接。
▼系統(tǒng)實(shí)現(xiàn)過程中另外一個挑戰(zhàn)就是信用管理的規(guī)則實(shí)現(xiàn)。由于業(yè)務(wù)需要，經(jīng)常會有一些客戶屬于母子客戶（多個客戶號歸屬同一客戶主體）。這些母子客戶授信額度共用，但預(yù)收賬款不共用。
針對這個需求，可以考慮的方案還是比較多的，母子客戶可以考慮客戶主數(shù)據(jù)合作伙伴關(guān)系設(shè)置、FSCM的合作伙伴管理等，針對授信額度共用可以考慮信用賬戶共用等，預(yù)收賬款不共用可考慮分開信控范圍或用戶出口增強(qiáng)。最終統(tǒng)一考慮，選擇在SAP標(biāo)準(zhǔn)信貸基礎(chǔ)上，通過信用用戶出口處理。
方案定好，壓力就在開發(fā)代碼了，如何通過代碼實(shí)現(xiàn)信用管理規(guī)則成為關(guān)鍵。考慮到信用規(guī)則不僅在訂單檢查時(shí)用，在許多信用相關(guān)報(bào)表和接口都會用到，這部分代碼一定要模塊化，并且一定是RFC函數(shù)?？蚣艽詈昧肆?，就開始邏輯實(shí)現(xiàn)了，取信用規(guī)則所需的基礎(chǔ)數(shù)據(jù)比較簡單，從S066、S067、KNKK這些表取數(shù)就都搞定了，但這個規(guī)則實(shí)現(xiàn)就沒有那么簡單了，由于一部分額度是共用的，母子客戶都可以去搶，而預(yù)收賬款是獨(dú)享的。共用額度部分如同春運(yùn)搶火車票的邏輯。
在整個邏輯處理中，針對先共用、后預(yù)收和先預(yù)收、后共用規(guī)則前后做了近10個版本的邏輯處理，但總是在某些業(yè)務(wù)場景下有些不太合理的情況出現(xiàn)。其中甚至客戶提出要模擬系統(tǒng)計(jì)算信用更新數(shù)據(jù)的處理，這一點(diǎn)被斷然否掉，SAP ECC的信用管理中信用更新部分是最容易有問題的（S/4HANA應(yīng)該是解決了這個問題）。最后在不斷修正規(guī)則、調(diào)整算法的基礎(chǔ)上，圓滿完成。
總結(jié)：SAP SD模塊的信用管理功能非常強(qiáng)大，企業(yè)信用管理需求盡量用標(biāo)準(zhǔn)功能實(shí)現(xiàn)。對于特殊需求，SAP提供了信用出口進(jìn)行信用檢查增強(qiáng)，但對于信用數(shù)據(jù)更新不要去做調(diào)整處理。
針對性地高效測試
因?yàn)閷?yōu)化點(diǎn)和原方案的調(diào)整點(diǎn)比較清楚，所以項(xiàng)目組有針對性地設(shè)計(jì)了新的信控范圍、新的信用規(guī)則和返利優(yōu)化方案的測試場景，并有針對性地做了回歸測試，雖然業(yè)務(wù)人員比較忙，測試工作還是比較順利、高效地完成了。
總結(jié)：由于優(yōu)化工作都是對原方案的整體優(yōu)化或局部優(yōu)化，所以對于系統(tǒng)的回歸測試是難免的，為了最大限度地提高測試效率，除了一方面在方案和實(shí)現(xiàn)上盡量少動原代碼，并做到與其它相關(guān)部分無縫銜接，另一方面，需要針對優(yōu)化點(diǎn)有針對性地設(shè)計(jì)測試場景和進(jìn)行回歸測試。
平滑切換上線
系統(tǒng)切換上線除了系統(tǒng)功能切換外，最重要的就是數(shù)據(jù)切換了。由于現(xiàn)有業(yè)務(wù)還在系統(tǒng)上處理，系統(tǒng)作為后臺支撐著前臺經(jīng)銷商下單系統(tǒng)，原則上是不能停機(jī)的。這就對數(shù)據(jù)切換提出了很高的要求。所以在制定整個優(yōu)化方案的時(shí)候，就重點(diǎn)考慮了數(shù)據(jù)切換方案，包括切換數(shù)據(jù)、切換方式等，以保證將數(shù)據(jù)切換工作量降到最小。
考慮到客戶業(yè)務(wù)的連續(xù)性和數(shù)據(jù)清理的難度，制定了兩套切換方案，一套是自然切換法，即新業(yè)務(wù)新辦法、老業(yè)務(wù)老辦法，歷史數(shù)據(jù)隨著業(yè)務(wù)發(fā)生自然消耗調(diào)整結(jié)束。另一套是整體切換法，即將歷史數(shù)據(jù)整體按新方案切換，之后業(yè)務(wù)都按新方案執(zhí)行。由于客戶有能力將歷史數(shù)據(jù)清理和調(diào)整，也需要短時(shí)間內(nèi)清理歷史數(shù)據(jù)，因此，很快確定了整體切換方案。
接下來顧問就開始著手準(zhǔn)備切換工具，客戶開始清理和調(diào)整歷史數(shù)據(jù)，一切有條不紊。按照制定的切換方案，系統(tǒng)并沒有停機(jī)，也沒有鎖用戶，只是針對一些特定某幾個TCODE進(jìn)行了鎖定，停掉了幾個后臺作業(yè)，對業(yè)務(wù)運(yùn)作基本沒有什么影響。
總結(jié)：優(yōu)化方案不能單純考慮問題解決方案，還要結(jié)合數(shù)據(jù)切換方案一起考慮，數(shù)據(jù)切換方案往往對切換工作量和時(shí)間有很高的要求，要根據(jù)客戶的數(shù)據(jù)基礎(chǔ)和清理調(diào)整能力制定數(shù)據(jù)切換方案。
以上是一個優(yōu)化項(xiàng)目的回顧和總結(jié)，其中還有許多故事就不一一敘述了。
每個項(xiàng)目都有自己的故事和特點(diǎn)，各有各的不同；每個項(xiàng)目的經(jīng)驗(yàn)和教訓(xùn)又是相似的。
優(yōu)化項(xiàng)目不同于新的實(shí)施項(xiàng)目，以上總結(jié)的內(nèi)容希望能給大家?guī)硪恍┙梃b和參考。
以上內(nèi)容均為【迪森】原創(chuàng)出品，版權(quán)歸迪森所有，嚴(yán)禁任何形式的抄襲行為，否則將追究其法律責(zé)任，敬請遵守！敬請各位維護(hù)好良好的SAP圈內(nèi)正能量環(huán)境，我們會分享越來越多的精華，謝謝！
服務(wù)指南
如需了解更多SAP課程資訊、項(xiàng)目咨詢運(yùn)維，請撥打迪森官方咨詢熱線： 400-600-8756
【迪森微課堂】
SAP圈內(nèi)最接地氣的純技術(shù)交流、純干貨分享平臺，全球SAP顧問與業(yè)界頂尖名師的聚集地，是SAP顧問進(jìn)階的官方橋梁。
【如何加入迪森微課堂】
請即刻關(guān)注迪森官方微信公眾平臺，第一時(shí)間獲得迪森最新動態(tài)，秒搶寶貴席位！
