本人2001年至今一直從事basis工作，曾經是erphome-basis版主之一，管理過多個500人以上的sap系統N年，創有
BASIS終極授權の內部顧問引數檔案的產生 https://github.com/basis100/SAPauthor我經歷的多個ERP系統中，基本會分為2個大的階段：建設和運維。一、專案啟動至上線正式執行為建設階段，這個階段一般是由乙方實施公司主導完成。外部顧問會全權參與使用者許可權的設定。SAP系統中的許可權會被外部顧問設計成使用者名稱---角色（崗位）---事務程式碼。 這個階段外部顧問會根據公司部門，崗位把事務程式碼按組分好，最後加給使用者。因為系統是新建，使用者-角色-事務程式碼關係也是新建，使用者還未大量完整的使用許可權，專案就結束了，對於外部顧問，不會有什麼問題。二、ERP系統正真運維階段，是內部顧問和業務部門使用者全部完整的參與階段，這個時候之前的設計就可能遇到問題：問題的本質：內部顧問基於之前的角色（崗位）來管理SAP許可權，而業務部門使用者壓根不知道有角色這個東西，他們只知道使用者名稱和事務程式碼，因為資訊不對稱，就會出現矛盾。1、 表現為減少事務程式碼的時候，出現問題。一個角色，包含三個事務程式碼A、B、C，之前付給了5個使用者，這5個使用者都有A、B、C三個事務程式碼。某天，業務部門提出有一個使用者，她改變了工作事務，她只需要一個事務程式碼，請basis拿掉其它兩個不需要的事務程式碼，這個做法只有把使用者的原來角色去掉，新建一個角色（只包含一個事務程式碼），加給這個使用者，這時候新的角色（崗位）產生了，內部顧問需要記錄這個角色，並且清楚這個角色的使用範圍。 但是這樣的需求會有很多，角色因為事務程式碼偏差開始大量增加，而出現一個使用者使用多個角色需要變更再涉及到後面的許可權物件，就很難理清了。所以有人說髒活累活屬於basis.2、表現為業務部門需求提出後，內部顧問是否改變原需求。在增加事務程式碼上，內部顧問很可能改變原需求。某日，一個使用者提出她需要MIGO這個事務程式碼，需求送遞到MM內部顧問一看，如果給這個使用者所擁有的角色只增加MIGO，這個角色又可能被其它使用者所共用的，其它使用者就也會有MIGO，這是不行的。MM內部顧問就很可能在已經有的角色中尋找，他發現了一個庫管員的角色，裡面包含有MIGO，他就會讓basis把這個庫管員角色加個這個使用者。但是，這個庫管員角色可能包含不止一個MIGO，它可能還包含MB51，使用者沒有提這樣的需求，但她有了MB51。當然MM的地盤一定是MM內部顧問做主，但是這同原來使用者的提出的需求並不一致，這個弊端說輕一點是不夠嚴謹，說重一點許可權審計的時候可能過不了，再重一點如果使用者用她沒有申請的許可權做了出格的事情，追查責任的時候都會有。出於上面的困擾，我在一個系統中曾使用過基於使用者的許可權設計，就是一個人一個角色, 角色不按崗位來而按人頭來，其實就是弱化角色這一層，讓整個許可權只有使用者和事物程式碼。這樣的模型就同業務部門使用者腦子裡的一致了，他們按使用者--事務程式碼來提許可權，沒問題。 但這樣消除了共用角色，basis的工作量又會加大，不過許可權清單拖出來的報表絕對是清晰的,和需求一致的。----------------------2017.7.10續---------------------------------------------------解決SAP許可權管理的一個審計痛處：SAP系統內許可權的變更，來源於外部的變更申請（OA系統內的一次工作流程或紙質的簽字文件，這個文件一般包含，業務使用者提出申請、業務部門領導簽字、ERP內部顧問、ERP專案經理簽字)。使用者管理員按上面材料，在SAP系統中實施變更。這種變更是很多的，日積月累後，可能堆了一大箱子，如果是OA流程可能走了成百上千個。。。某天，審計來了，他想看一個使用者的系統內變更，系統外申請憑證，還有這個對應情況（許可權管理員有沒有亂做），我認為他的要求是合理的，但是許可權管理員可能要累死，他要在之前做過的全部申請中找出該使用者的OA流程或紙質申請，而這僅僅是一個使用者。。。。我想到一個解決辦法：在SAP系統裡面開發一個事務程式碼，ZSU01（每一次許可權管理員在系統維護完使用者許可權後），把“外部變更號“，“SAP使用者名稱”，“變更日期“儲存到SAP系統裡。輸入變更號，帶出使用者名稱，選擇使用者名稱，儲存。 做好用一點，對許可權管理員增加不了多少工作量。但是這樣以來，審計要的系統內外的對應關係就很方便的找出了。整個授權過程也是清晰透明可追逆了。這個想法源於PP模組的BOM變更號管理，SAP呀，為什麼對BASIS模組不使用這麼好的功能。 這麼多SAP的企業，有多少把這個系統內外許可權管理做得很清楚的？----------------------2018.6.2續---------------------------------------------------
如果按我的方法，SAP的許可權管理其實能夠管理得很好，也很輕鬆：1、簡化系統複雜度：一個使用者只有一個角色（還可以在加一個基本角色）。2、簡化維護人員結構：業務使用者----內部顧問 ，內部顧問按模組負責系統的許可權維護工作。3、嚴格按照流程：業務使用者--業務部門領導--內部顧問--ERP專案經理。4、BASIS管理內部顧問使用者和開發使用者。以上4點，第一和第二點尤為重要，第一點，一個使用者只給他一個角色，角色的名字可以同用戶同名。不這樣做，只會造成事務程式碼和許可權物件大量重複。

第二點，不要再讓BASIS來維護使用者的許可權，如果多了basis這一層，會讓內部顧問丟掉對SAP系統內授權情況的掌握。

試想一個MM內部顧問，他一定對物料和採購的業務人員是熟悉和了解的，他再掌握SAP系統內的授權內容，

他自己可以很清晰的比較出許可權是否同實際一致。而一般一個企業一個模組使用者在100個以內，這100個又正好在

人大腦的處理範圍內。所以內部顧問全程參與管理，一定能把SAP系統許可權管理得清清楚楚。