SAP配置传输增量还是全量有规律可循么？

antigodzyz

shenzhen_sap 发表于 2016-4-29 11:17
OBYC 也是增量好吧。

配置的还好说， 增强开发才扯呢，现在是 动 共用增强口，改完 释放c到测试机后，赶紧再开发机再“锁”一下，尤其是大需求变更的时候，就怕 “隔壁”哪家公司，也来动，改完测完 提前上传prd了，而这边还在测试；一个集团级系统，硬生生的变成分级运维，各自为政，集团也不建立沟通机制，basis就是看联系单 审批过了就传prd，先到先得，每个公司内部审批流程长短不一。

shenzhen_sap

antigodzyz 发表于 2016-4-29 11:26
no idea，我不具体干活，都是 外包顾问告诉我的  obyc gbb之类的  都是全量 动的时候要特别小心

那是指同一个科目表的意思。就是你如果有10间公司，用的同一个科目表INT，那你动一个，10间公司都一样变的意思。

shenzhen_sap

antigodzyz 发表于 2016-4-29 11:23
我们现在就是 业务组织机构（采购组/组织 什么的）在 开发机配然后上传prd
但是 财务利润中心 就是800 直 ...

利润中心是主数据，直接前台维护。

shenzhen_sap

antigodzyz 发表于 2016-4-29 12:00
配置的还好说， 增强开发才扯呢，现在是 动 共用增强口，改完 释放c到测试机后，赶紧再开发机再“锁”一下 ...

增强开发是CROSS CLIENT的，像你们这种情况，如果某一个公司不需要用的话，建议在开发里面加判断吧，利用组织架构来判断，多数增强都带组织架构。

antigodzyz

shenzhen_sap 发表于 2016-4-29 12:03
那是指同一个科目表的意思。就是你如果有10间公司，用的同一个科目表INT，那你动一个，10间公司都一样变的 ...

是  就是举个例子，被参照体变了肯定都变，这个顾问会去考虑的，我想到这样会有隐患也是 因为我们的 增强开发被别家的公司 影响过，但是这东西集团又不管，开发还好说，肯定是全量代码，版本管理什么的都可以帮着监控，现在就是自保；但是联想到配置，总感觉不妥，反正 集团内部顾问 集团外部运维，我们的外部运维，项目公司，没一个人所得清楚怎么判断，就有一个人说，看 请求里面的具体数据，是啥就是啥，还有些直接带*的就更不用提了，肯定全量。 再最新的项目上，集团问过AC项目经理，有没有什么清单或者方法之类的 判别，那些配置适合下放到各公司自己完成，哪些必须集团统一管理，也是没个说法。就刚才举的例子， 我们管辖的 公司组织机构变更，业务的我们配置 上传prd，同时还要通知集团 prd里面直接加 利润中心，然后我们有增强 业务组织机构和利润中心有1:1对应关系， 最后搞笑的就是两边不同步，用户看到 采购组prd里面有了，结果用不了，因为 利润中心还没有配置。。。。领导在审批联系单。。。

justforregister

antigodzyz 发表于 2016-4-29 11:23
我们现在就是 业务组织机构（采购组/组织 什么的）在 开发机配然后上传prd
但是 财务利润中心 就是800 直 ...

你操那么多心干嘛。。。。闲的蛋疼。。。。。。

antigodzyz

shenzhen_sap 发表于 2016-4-29 12:07
增强开发是CROSS CLIENT的，像你们这种情况，如果某一个公司不需要用的话，建议在开发里面加判断吧，利用 ...

这个我们有机制的，有做了 配置表，写增强的时候 必须加一段代码判断 配置表里面有没有配置增强格式 比如 公司代码订单类型 之类的，否则不起作用，但是吧 这东西也不是100%这么玩，有些简单的顺手就过去了，我也不能监控别家公司要求人必须这么做~~~ 说难听的 我是硬赶着上架的，我又不懂abap，全集团懂abap的内部人员就2人，我们运维是外包性质的，以前我就是做需求分析，知道些sap标准的玩意就够了，具体怎么实现不是我的事，我的使命就是 帮助 用户理解系统，帮助顾问理解用户；然后帮着顾问抵挡不合理需求，帮助用户跟乙方叫嚣实现必须实现的需求；现在 15+5个 公司的总体运维（包括abap)全落在我一个人头上，带着10多个外部顾问pk 上中下几百号 人；硬着头皮上，能做的就是 怎么确保 我们的团队不会影响集团整体系统平稳运行；

antigodzyz

justforregister 发表于 2016-4-29 12:16
你操那么多心干嘛。。。。闲的蛋疼。。。。。。

因为 出问题了 责任我担啊 ； 就昨天 隔壁公司  把一个 800直接配置的玩意，200测试的时候 无意抱进了一个需要上传的 配置请求里，给传到800了，还好没有影响我们，那个就是全量，涉及财务替代，否则用户又臭骂我们，我们赶紧全部检查一遍。。。。。弄的人心惶惶。 然后集团领导把隔壁公司臭骂一顿。。。。
运维跟做项目 不一样啊，做完项目拍拍屁股走人，运维是吃力不讨好，一边擦项目上的shit，一边还有新需求，还要用户辅导等等等等

antigodzyz

justforregister 发表于 2016-4-29 12:16
你操那么多心干嘛。。。。闲的蛋疼。。。。。。

企业信息化你懂啦，尤其是大央企这种环境和作风，但凡跟系统沾边的都会说 系统的问题，不沾边的用户也会想方设法沾边，让系统背黑锅，用户才不会管 项目还是运维，出了问题就是你系统的事，项目是短痛，运维是长痛。。。。

antigodzyz

话题说偏了啊，真心求问 各位  配置方面有没有 规律可循， 现在连外包顾问就只知道看看请求里面的具体信息，太土鳖了；运维顾问 考虑成本，不会请什么大拿过来，我们运维顾问是常驻的，相当于包人了。