SAP实施顾问到底是一项什么工作？-（01）-需求与开发的桥梁
原文鏈接：https://mp.weixin.qq.com/s/sfDk-NOq03bwmDwE5nPugw
大家可以關注我個人公眾號，所有分享內容，會在公眾號第一時間推送，且閱讀排版更好。
愿大家的學習，輕松且愉快。
如果大家覺得有用，希望轉發關注，謝謝
?
導讀
?
最近有一個做開發的朋友聯系我說：想轉行，想從SAP實施相關行業，聽說：“SAP業務顧問是用戶與開發人員之間溝通橋梁。”感覺這個更適合他。
?
這篇內容，就簡單從SAP實施顧問在用戶需求與開發之間的溝通作用方面，簡單分享一點思考總結，希望對想了解、想從事SAP相關行業的朋友有用。
?
以下僅個人理解，還請大家批評指正。
?
?
正文
?
作為SAP顧問，得具備SAP系統的標準知識，同時又要具備一定的行業經驗，還得了解一定系統開發及功能實現的知識。
因此，有很多人都將SAP業務顧問解釋為：“用戶與程序員之間的一座橋”，從而保證用戶的想法被正確地實現。
如果一定從業務需求到技術實現的角度上看，那么這座橋，不是簡單的傳遞，而是要至少包含以下三個方面。
?
1.對用戶需求的合理分析
?
一般用戶提出的需求和想法，都是基于自己本崗位的現狀和問題的。
?
作為SAP顧問，不能直接按照用戶的想法就進行系統實現的，這樣的系統實現，最后，是無法有效使用的。
?
用戶的需求想法，是有強烈的局限性和不全面性的。
?
從局限性而言，企業產線上的領料員提出了一些想法，做為SAP顧問，你不能期待一個產線上的領料員，幫你去思考從需求到采購，再到物料倉儲，以及最后財務結算整條業務鏈上的合理性，但SAP大多數的系統功能，卻是要貫穿整個業務鏈的。
?
從不全面性而言，業務用戶提出業務需求時，多數情況是單一正向的，我們也不能過分依賴于用戶能清晰地列舉出各種不同的業務情況。
?
所以，在對用戶需求進行收集和調研時，作為SAP業務顧問，需要有效地幫助用戶去合理的管控需求。比如，某部門提出希望改變當前對物料需求的提報流程和功能，那我們就得考慮新需求的變化對其他部門的現有流程和系統功能是否影響，比如采購、物流、倉儲，甚至生產及財務等部門。這是作為業務顧問，所應具備的基本的全局性思考方式。
?
同時，關于當我們在幫助用戶梳理業務時，還要不斷幫用戶思考各種可能存在的業務場景，進而保證未來的系統功能，能夠滿足各種業務場景的使用。
?
比如，A部門提出其部門的物料需求，提給部門經理，審批通過后，再發給B采購計劃部門進行評估采購，到貨至C庫存管理部門，A部門直接領用。剛聽起來，這個業務流程不算復雜，很容易就梳理出來了。
?
但是作為一個SAP業務顧問，要考慮的問題就多了：
?
1.A部門提交物料需求后，部門經理審批不通過，后續流程怎么走，需求該是什么狀態，打回去重新修改，還是默認自動關閉，用戶重新提交？
?
2.A部門員工將物料需求提交后，部門經理也審批了，由采購計劃部門發現物料號不對，或者數量維護不合理，后續流程又改怎么辦？
?
3.A部門的需求提交到采購部門后，采購計劃部門發現不需要采購，當前庫存夠用，或者發現當前庫存只滿足部分需求，剩下的需要采購，或者幾天后就有到貨，能夠滿足需求等等，這些業務情況發生后，后續流程又該怎么辦？
?
4.甚至A部門發出了需求，B部門也幫著采購了，供應商已送貨至工廠了，突然A部門因為某些意外發生，不需要這批物料，又有沒有這種情況的發生，如果發生了后續該如何處理，等等。
?
除了啟發用戶考慮各種不同的業務情況，SAP業務顧問還得盡量建議用戶去避免讓系統去支持各種不合理的業務，并建議線下處理。如上述4中的描述，需求提了，也采購了，都送貨到廠了，突然需求部門說不要了，這種業務本身就是不合理的。作為需求部門，對自己需求的合理性要有一個起碼的預期。
?
上述舉例，在實際需求梳理工作中，情況可能會更多更復雜。所以，作為有經驗的SAP顧問，幫助用戶合理地平衡規劃業務流程，從而保證系統功能實現后，能夠全面地支持健康合理的業務情況，且能有效避免不合理業務的發生。
?
其實，除了業務本身以外，我們還需要考慮開發成本。如果為了滿足某種極少發生的特殊業務，我們開發了大量且不常用的系統功能，同時，給最常見的業務操作都帶來干擾，這種情況下，我們就要考慮，這種功能有沒有實現的必要了。
?
以上這些內容，都是我們在幫助用戶對需求進行管控時，所需要考慮的事情。
?
?
2.將用戶需求有效地傳遞給開發團隊
?
作為SAP業務顧問是需要具備一些代碼實現、數據庫設計及接口實現原理等基本知識的。
?
當SAP業務顧問在和用戶聊需求時，肯定是有一定開發難度的估算的。
?
當需求被確定時，作為SAP業務顧問一定是大致系統功能已經形成了，同時，支撐這些功能背后的數據庫表間關系也有了初步結構。也就是說，SAP業務顧問設計出來的系統功能，其數據庫表的基本表間關系、表關鍵字以及具體字段等也就被設計出來了。
?
當然，如果用戶需求涉及增強，大致的增強點，業務顧問也應該清楚；如果需求涉及系統接口，與外部系統哪些數據需要交互，如何產生數據，并發送數據給外部系統，如何接受外部系統的數據，并如何處理這些外部系統的數據。
上述這些問題，在SAP業務顧問確認需求后，大致框架應該已經形成了，后續只需要具體實現細節上的進一步討論了。
?
曾經一個項目上，甲方要做一個采購平臺，采購平臺上的數據直接傳輸至SAP，生成相應的采購訂單，收貨等聯動。這個采購平臺系統，有產品經理，數據庫團隊，后端團隊，前端團隊，以及設計團隊。
?
產品經理負責業務調研和需求整理，設計部門也做了設計。由于是to B業務，對業務的閉環要求比較高，同時多次收貨、或者取消收貨、發票校驗等，會有大量單據間多對多的情況，這對數據庫表關鍵字及表間關系的設計，就提升了一定的難度了。
?
而這個產品經理收集的需求后，也沒有任何結構化的整理，每天跟傳話筒一樣，將需求直接交給數據庫團隊進行設計。數據庫團隊由于不了解實際業務，各種認為不合理，不可行，經過大量討論后統一意見了，也經常是，會上都覺得可行了，會后執行又發現問題，這是典型的沒有帶著數據庫表設計的思路，去分析業務流程，其實這在SAP顧問看來，就是業務沒有理解透徹，對SAP顧問來說，理解業務絕不僅是將用戶的業務需求背過，而是能夠業務從技術實現的角度進行徹底解構。
?
我還記得那個項目最后上線時，從下午7點開始，表間關系一直沒梳理清楚。最后SAP顧問被要求幫忙，重新梳理了幾個關鍵表的關系，重新修改了代碼，才保證首筆業務正常流轉，那晚我是凌晨4點下班的。
聊到這里，很多朋友會問，為啥沒怎么測試就能上線呢。因為對方系統的開發，屬于邊開發邊理解需求，最后要上線了，才算是對需求有點兒認識了，當時又有回款合同條約，而且因為某種關系，乙方比甲方還強勢，要求必須在那個時間上線，所以，最后就這么“正常”上線了。
?
其實，作為業務顧問了解一些開發的基本原理也是非常有用的。曾經，在一個項目上，一個不算復雜的報表，在單元測試環境中運轉正常，當我們在集成測試環境中進行測試時，就發現很慢，但也可以執行出來。當時的開發顧問，不算是一個特別上心的哥們兒，當我提出異議時，這哥們兒的回復是：“這不能用么？別想太多，給用戶解釋一下就行了。”
?
經過多次交涉后，這哥們消極反饋。這樣，實際上就把問題交到我手里了，我得用這個很慢的功能去說服用戶，而且我自己也認為，復雜度一般的報表，這么慢的運行速度是不太合理的。后來就自行分析了一下，單元測試環境的數據少，而集成測試環境數據和生產環境一樣，數據多，很有可能是報表取數時，并沒有按照選擇條件，先取部分數據再做計算，最后展示。大概率是直接先取了表里面的所有數據，再做篩選，再做計算，最后展示。最后，自行debug了一下，果然如此，有了這些，問題就好解決多了。
?
說白了，如果項目中碰到好隊友啥事兒都不難，要是隊友不是很靠譜，再簡單的事情都很難。當然，我碰到的大多數開發顧問都是很靠譜的，現在也都是很好的朋友。
?
所以，沒事兒學點兒ABAP知識，在某些時候還是很有用的。給大家推薦一下我最近在梳理的基本語法：https://mp.weixin.qq.com/s/duqoiqWTre1Bk2GnUn5ecg
?
?
3.對系統上線前后的有效評估
?
一般我們系統上線時，會有大量的測試工作，SAP業務顧問相關的測試，多數是基于各種業務情況在系統中能否合理運轉進行測試的。當然，有的項目也有對代碼本身，進行一點壓力測試，看看大量數據下的運轉速度等。
?
其實基于各種不同的業務場景，我們要清楚地知道，我們在上線前要準備哪些靜態和動態數據，在上線的那個時間節點，我們得知道不同狀態的業務數據，該如何處理，才能保證該筆業務在新功能上線后，應該如何進行等。
?
同時，我們也能大致預測到當新功能上線后，用戶大致的新需求會提在什么地方？比如進一步自動化需求，比如功能可能被推廣到其他工廠或部門的應用，比如哪些報表用戶可能會需要，比如某個業務流程的進一步優化等等。
?
當我們大致掌握了這些方向，下一期的項目方向，整個項目團隊就心理有數了，具體的項目工作量、功能難度、項目周期等，就大致就有一個初步的預估了。
?
這在某種程度上來說，不是只是把用戶需求傳遞給開發這么簡單，而是根據當前的系統評估，要預測用戶未來的需求走向了。
?
這對于后續系統建設工作來說，是非常有利的。
?
本篇就分享這些，后續在結合其他方面給大家分享相關內容。
?
?
?
總結
以上是生活随笔為你收集整理的SAP实施顾问到底是一项什么工作？-（01）-需求与开发的桥梁的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： html转义字符解码,js对html转义
- 下一篇： 计算机考研择校分析-长江大学