Info

You are currently browsing the archives for the IT顾问 category.

May 2012
M T W T F S S
« Apr    
 123456
78910111213
14151617181920
21222324252627
28293031  

Archive for the IT顾问 Category

SAINT/SPAM 出错怎么办?

自系统从4.6c升级到ECC 6后,发现RTCCTOOL用不了了。查Notes提示说要更新ST-A/PI补丁包,这步怎么在升级时漏了!?幸好是测试系统……

按部就班下载完ST-A/PI 01M_ECC600,开始安装。结果升到一半显示错误“BP_JOB_EDITOR: Job RDDMASGL is invalid”,进程就悬挂在DD ACTIVATION。查了半天发现有个变量丢失了,修复好后发现Saint/Spam被锁住了。提示:“OCS locked by user  CNHONGZHU0 with transaction SAINT”,并且在SAINT里面不能Reset那个安装任务,无奈,这下SAINTSPAM都不能用了。摸索了半天,终于找到解决方案:Call function module OCS_RESET_QUEUE
with the parameters
IV_TOOL=SAINT, IV_FORCE=X用这种方法,终于清楚了所有的OCS队列。继续安装,一切顺利!

iPAD 推动人类提前进入未来

上个月我老婆送了我一个32G的iPAD,用了之后感觉它将推动人类提前进入未来。

人在无聊的时候(坐飞机,等人,长坐……),用 iPAD 看小说,听音乐,玩儿游戏还是挺爽的。我花10美元买了一个移植的EA红警,头一次感觉到了用手指玩儿即时战略游戏的快感:你可以用三个手指圈定范围以锁定你要指挥的部队,你可以像翻书一样来到达地图上的一片区域,你可以用手指替代鼠标实现更快的操控速度……

很多跨国公司都在测试用iPAD来替代他们即将被淘汰的上一代手掌机系统。用iPAD一样可以联网查价格表,记录工时以及开发票。用iPAD连接相应的设备也可以诊断汽车故障……

想起无数电影中人们用手触摸屏幕来拯救未来世界,现在看起来iPAD就是现实版本,人类提前进入未来啦!

EDI上线直播4

发现2he5没有时间记录,那它冒充twitter还有些缺陷。手工加时间吧。

15:16 准备接受对方发来的EDI

15:52 德国人说,inbound不能是immediate,要用background program to inbound

16:36 inbound 成功进入SAP

17:47 Outbound全部切换成自动状态成功。

EDI上线直播3

第一个idoc file发送成功。虽然还有一些user mistakes….

EDI上线直播2

另有一个unexpected TO created with strange movement type。MM顾问金先生说,在SPRO里面没有看到这个配置,不知道哪里出来的。

变化

已经四年没有来美国了,这次出差等于是故地重游,城市基本和四年前一样,没有什么变化,唯一的感触是经济危机确实带来了巨大的冲击,原先人气旺盛的餐馆啊,购物中心啊现在人少多了。
但是美国的浪费基本没有改变,多数人,甚至更多的人开着大车,空调照旧是开着门吹,超市内也不限制塑料袋。美国的商品多数来自中国,但是价格有时比在中国还便宜,人们的平均收入又比中国人高,所以有更多的机会浪费,如果那一天中国和印度能完全达到美国这样的生活方式,估计业就离人类末日不远了,有的时候我想政府应该对出口到美国的商品收重税,如果让美国人一直沉坠于这种浪费而舒适的环境里简直就是支持美国人成为人类的终结着!

学习的能力是最重要的能力(引自乔治的SAP生活)

我的想法是,先去ST22看DUMP LOG, 那里有可能有明确提示,并给出了出错的ABAP语句,那么就可以开始修正了,一个经常发生的原因是动态的定义,赋值不对,在运行程序的过程中才出错,所以查一下变量定义是个办法。如果这个不对,那么一般在DUMPLOG里都给出了程序名或者关键字。

要知道,你不太可能是第一个碰到这个错误的人,那么别人是怎么解决的,对你非常有益。所以我的第二步是去SERVICE MARKET PLACE,按关键字查OSS NOTE,这里是否有足够的SAP经验就非常关键,如果没有经验的人,输入的关键字,可能得出上百条NOTES,而无所适从。而有经验的,可以给出更多的关键字,比如FUNCTIONAL AREA,TCODE, ABAP DICTIONARY VARIABLE NAME, 得出的信息是几条或者十几条。

然后还是阅读能力和经验在起作用,如何能在短时间内迅速排除不相关的信息?如果是我,我看标题,看SYMPTOM一栏,基本可以确定是否有效,NOTE的号码越大说明越新,这对RAMP-UP用户来说就是要尽可能排除老的NOTE,因为已经失效。如果找到合适的NOTE,然后再看DIAGNOSIS, SOLUTION。如果是直接的更正,这里有两个好工具,一个是T-CODE: SNOTE,很容易掌握,可以直接实施NOTE,而且可以反向卸装NOTE,另外一个是DOWNLOAD MANAGER, 这是保证续传的一个工具,对于比较大的文件,可以用SAP DOWNLOAD MANAGER来执行下载。

如果SERVICE MARKET PLACE还是没有找到解决办法,这就可以到我最喜欢的SDN去了,这里本来是自SAP拥抱第三方开发工具,JAVA等等而开始的一个开发者的论坛,主要的读者是技术开发者,但是这里越来越取代SERVICE MARKET PLACE成为最受欢迎的地方,因为这里你可以提任何SAP认为BILLABLE的问题。 (SAP有个臭名昭著的NOTE,解释什么问题是BILLABLE的,如果一旦判定是BILLABLE的,SAP就不予解答,除非你答应付咨询费)。在SDN,任何问题都是有效的,而且你可以得到SAP开发者的非常友善详尽的回答,还包括很多非常杰出的印度人,俄罗斯人的答复。很多时候我甚至都不需要提问,而只需要搜索即可,而得到的答案更加令我满意,相比SERVICE MARKETPLACE的OSS NOTE来说。 为什么呢? OSS NOTE是SAP编写的,基本上是以典型问题为主,而且内容的详细程度受到SAP AG的人力限制,尽管德国人已经尽力了,他们在爱尔兰,新西兰,印度都设了全球支持。

但是SDN是大家自发的互助论坛,最大的优势,也是我最喜欢的,是SDN的回复速度,使我一直怀疑有一批家伙一直守着SDN,喝着啤酒,吃着波兰的小泥肠,时刻准备回答问题。一般来说我的提问的回复速度,是3-30分钟,不管我问的问题多么棘手。(当然这里有个如何描述问题的技巧,这,也是与SAP的经验绝对相关的。)

好了,如果SDN得到了答复,就知道如何往下执行了。如果得不到答复呢? 这时候可以问同事,查公司的以前的HELP TICKET 记录(以前的HELP TICKET记录,如果保存的好的话,自己建立了TREX式的KNOWLEDGE BASE, 那么应该是第一步该做的)。

为什么不先问同事呢? 因为自己需要在寻找问题的过程中熟悉问题,需要锻炼自己的思考能力,需要自己独立解决问题,至少试图解决问题。我发现一说就收不住了,很容易跑题,我尽力集中在这个主题上吧,学习能力。 有时候SAP的工作令人沮丧,因为长久无法取得进展,但是在失败,否定中,长时间地和系统打交道,和错误信息打交道,慢慢地你在熟悉这个系统,而你并不知觉。谁能知道呢?

如果我来面试你的话,我就可以知道。 SAP的经验,大多数的时候是从失败的经验中获得的,这是做支持的人优于做实施的人的地方。当然实施的人也有优势,这个以后再说。

如果一切都无济于事,那么怎么办呢?这才是需要开始学习这个流程,实施的文件,做128POINT CHECK的时候了。(比较高级的二手车,比如凌志,宝马,奥迪,在销售的时候,车商都做一个CERTIFIED 128 POINT CHECK,完整检查维护一遍,然后给出几万英里的WARRANTY)。 这比较累人,需要仔细检查每个环节,记录每个疑点,多次测试,争取达到错误的可重复性,对了,还有联想能力,假设能力,这些都非常重要,这里不多说了,以后再说。这个工作比较繁重了,但是做得好,迅速的,仍然是有经验的人。

about EDI

第一次要做这个东西是2008年。那个时候,只有需求,没有knowledge,没有experience,没有support。有的,只是“猜想”。当我现在再回头看当初做的文档,还能发现有很多错误。当时居然还能按时完成任务,运气真好。

今年,第一次做外部系统连接。且external partner不是customer,不是supplier,不是carrier,而是warehouse。项目计划10月上线。整个项目的进程是很怪异的。

1)2009年底,需求被提出。

2)2010年初,解决方案A提交。

3)2010年5月,解决方案A被否决。

4)2010年6月,解决方案B提交。

5)2010年7月27日,解决方案B被否决,重新回到解决方案A。

6)2010年8月,解决方案A,完成配置和开发。

由此可见,解决方案A真正从确认到完成,差不多花了才一个月。大多数时间纠结在了选择哪个解决方案的问题上。

而解决方案临到上线前两个月才被确认。难怪从年初到现在,很少有人对项目能按时上线持乐观态度。

我终于明白了什么叫“坚持目标,并面对现实”。如果这次居然还能按时完成任务,我要承认,运气是项目成功的关键因素。。。

解决问题要想多远想多广?

最近参加了一个中级桌球课程,颇有感悟。由于本人已经有一定的桌球基础,所以基本技术并不是培训重点,而思想意识则是被经常强调的。我的教练(具备职业水平的非职业注册球员)跟我讲,打斯诺克也好,打九球也好,只要用二分法考虑三个球,然后滚动思考,再加上一定的全局观,就足够了。所谓二分法就是在打下一个目标球的时候考虑好母球的走位,这个走位不能简单的只考虑第二个目标球,还要考虑怎么打第三个目标球更顺手。具体做法就是在打球之前,先到击打第二个目标球的理想位置,看看第三个球是否好打。真正做起来,不是很容易;不过习惯了,确实感觉水平有所提高。所谓全局观,就是在整盘球的一开始,要看清全局,知道有哪些主要矛盾,也就是不太好处理的球。

由此想到解决问题时要想多远向多广。我们有的时候想问题是不是纠结得太远了?是不是在明确长期目标后,向着中短期目标努力,然后循序渐进就可以了?经常纠结在长远问题上的思考,是不是就一定比在阶段性成果后的方向调整要高瞻远瞩?是不是不谋全局也可以谋一域?所以我觉得具有全局观的滚动型中短期战略调整是比较实际的一种做法。

好顾问必杀技之一

问问题–顾问其实就和医生或律师式的,要想替业务方解决问题就得了解需求到底是啥,而不简单的做头疼医头,脚疼医脚的事,所以必须学会如何去问问题,一个好的方法叫Ascending & Desending Questions,通过这种方法向client问好的问题可以让client自己去发现真理!

 举个例子:

有人说我想需要个M解决方案…

要想了解要M解决方案主要的动机,背后的情感等抽象的东西时可以这样问, Ascending Question:

  • M为什么对你很重要啊?
  • 你需要M是为啥啊?
  • 你希望M替你带来什么样的帮助啊?

要了解要M解决方案的背景的具体的,清晰的和基于事实的状况时可以这样问,Descending Question:

  • M是什么?
  • M对你来说意为着什么?
  • 给我一个例子?

具体问的时候其实是Ascending和Descending交织着问,目的是通过好的问题来排除client的对M需求的偏见,从而达到了解问题的本质,然后提供真正可靠的M解决方案!