Tips for SAP rollout project

本文分享了SAP SD模块实施的经验,强调了了解客户需求的重要性,包括知识转移、差距分析、输出格式定制等内容,对SAP项目的成功实施具有指导意义。

在看ITPUB的时候,无意中找到"潜龙勿用"的博客,从博客主人的资料看,作者Ryan是一个SD顾问,他的这篇文章是关于SAP的SD模块实施的一些经验总结,我看了其中的内容,觉得相当的好,虽然我不是学习SD的。所以我在此转载了。作者是从实施顾问的角度来看问题,这对我这个PP Key User理解SAP实施是有帮助的。

原文地址:

http://gqlny.spaces.live.com/blog/cns!9E1B98E7AB455851!2455.entry

As per my experience and understanding, following points which I learnt from GFAU rollout may contribute to  a successful rollout project. These points listed below doesn't work as a SD specific guideline, it pretty much may be regarded as experience sharing.

1. Template knowledge transfer and customer customized solution
As far as I'm concerned, usually we are likely to build up the questionnaires from standard SAP view, but customer maybe have customized many add-ons based on SAP standard functions. So those customer specific solutions, on which should be put more effort for discussion. The more information we get, the easier we can tackle surprises on following phases. Especially for those highly customized system by customer, like GFAU. Both customers and SAP team were bombarded by heavy email communication during realization due to lack of enough global template knowledge.

2. Fit/Gap analysis
Elaborate the template to local customers, and try to note down their local requirements in detail whatever it makes sense or not. Afterwards, all those information different from template can be translated in to GAP list. From time to time, the point which is ignored on this phase, may be raised again on system realization, as customer sometimes is not quite sure what's their exact requirements. It may involve group discussion from different departments. Finally, double check with local key user to minimize the GAP, and stick to it.

3. Output forms
The Form format is also a key point for SD. It may involve some of followings in one project, order confirmation, delivery note,  goods issue slip, normal invoice, proforma invoice, credit and debit memo, etc. During GFAU realization, we spent big chuck of time on discussing the layout and testing . So it's better to have customer prepare the format in advance, latter we can spend less time polish the layout.

4. SD customizing list
During my last project, before the knowledge transfer, I built up a customizing list which contains almost all SAP standard functions used by customer, for example, sales order types, item categories, pricing procedure, partner determination, billing types and output types, etc. Since not all of them can be implemented in China, it speed up the knowledge transfer by marking China relevant items directly in the list instead of navigating in SAP. And it's easier to discuss based on one Excel book.

5. Issue list and report
From project management point of view, in order to avoid email overload and miscommunication, the approach for issue raise and status report should be discussed and finalized at the beginning. Also it helps to put both customer and SAP team into the same picture.

One more point, it makes more sense to understand customer's business process from his/her point view instead of sticking  to SAP standard solution, which can prevent us from missing some points. That's all what I learnt from my previous project experience. Hope it helps.

08-09
在信息技术领域,rollout 通常指的是将新功能、更新或修复逐步部署到生产环境中的过程。这种部署方式可以确保更新过程的稳定性,并减少对用户的影响。以下是几种常见的 rollout 策略及其应用场景。 ### 蓝绿部署(Blue-Green Deployment) 蓝绿部署是一种常见的 rollout 策略,它通过在两个相同的生产环境中切换流量来实现无缝更新。一个环境(蓝色)用于当前的生产版本,而另一个环境(绿色)用于新版本的部署。一旦新版本在绿色环境中测试通过,流量就会被切换到绿色环境,从而实现零停机时间的更新 [^2]。 ### 金丝雀发布(Canary Release) 金丝雀发布是一种逐步将新版本暴露给一部分用户的方法,以便在全面发布之前检测潜在的问题。这种策略可以通过逐步增加新版本的流量比例来实现。例如,在 Kubernetes 中可以使用 Kruise Rollouts 来实现金丝雀发布 [^4]。 ```yaml apiVersion: rollouts.kruise.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo annotations: rollouts.kruise.io/rolling-style: canary spec: objectRef: workloadRef: apiVersion: apps/v1 kind: Deployment name: workload-demo strategy: ``` ### 滚动更新(Rolling Update) 滚动更新是一种逐步替换旧版本实例为新版本实例的策略。这种方法可以确保在整个更新过程中,服务始终保持可用。例如,使用 `docker-rollout` 工具可以实现 Docker Compose 服务的零停机部署 [^5]。 ```bash $ docker-rollout api_server ==> Scaling 'api_server' to 2 instances [+] Running 2/2 ✔ Container api_server-1 Running 0.0s ✔ Container api_server-2 Started 1.3s ==> Waiting for new container to be ready (10 seconds) ==> Stopping old container ``` ### 使用 Prometheus Metrics 监控 Rolloutrollout 过程中,使用 Prometheus 收集的业务指标可以帮助确定发布是否符合预期。这些指标可以包括请求延迟、错误率、吞吐量等。一旦发现异常,可以立即停止 rollout 过程并进行回滚 [^1]。 ### Argo Rollouts Argo Rollouts 是一个 Kubernetes Operator 实现,它为 Kubernetes 提供更加高级的部署能力,如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能。它支持自动化和基于 GitOps 的逐步交付,适用于云原生应用和服务 [^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值