ITPub博客

首页 > 数字化转型 > ERP > 项目部员工述职报告(轉)

项目部员工述职报告(轉)

原创 ERP 作者:sapstudysap 时间:2007-08-28 11:24:48 0 删除 编辑

ERP项目部员工述职报告表

(2xxx年度)

[@more@]


部 门: 集团ERP项目部
姓 名: X X X
岗 位: ERP系统管理员
填表时间: 2xxx-xx-xx

个人述职

第一部份:年度工作完成情况
(指标完成情况用数据和要点方式陈述)
作为一个ERP 系统管理员,个人认为在2005年度比较成功的实现了对ERP系统的BASIS方面事宜的管理。我的工作主要是:
ERP生产系统和测试系统维护(及时监控系统性能、系统备份、程序变更)。
ERP生产系统和测试系统用户权限维护(严格按照提交的<>维护系统用户的权限,全年维护上千次,几乎每天都会收到更改请求)。
在确保ERP系统全年稳定运行的情况下,解决了ERP系统大量BASIS模块相关问题。其主要事宜如下:
2005年2月 根据SAP EWA报告,调整SAP系统参数
2005年2月 编写<>和<>操作文档
2005年2月 春节假期协助MM人员重建生产系统信息结构表
2005年3月 财务科目管理程序(该程序实现科目数据同SAP系统自动同步,自动产生SAP系统授权科目相关的角色文件)
2005年3月 安装SAP IDES系统(科技公司)
2005年3月 重建帐务系统BSIM表索引,重建后排除数据库故障
2005年4月 完成HP小型机年检
2005年4月 处理小型机带库故障
2005年5月 处理小型机房空调故障
2005年5月 调整ERP生产系统HP-UX kernel文件相关参数
2005年6月 改变生产系统ORACLE数据库日志文件存放位置(因原目录较小)
2005年6月 增加DEV系统离线备份,扩大data9逻辑卷尺寸
2005年7月 协助解决财务CK40N运行时间太长问题
2005年7月 协助解决生产订单下达慢问题
2005年7月 按机车财务部需求完善科目管理程序
2005年7月 了解SAP kernel升级情况,编写kernel升级操作文档
2005年8月 检修ERP机房UPS故障及购买APC续保和更换过期电池
2005年8月 协助MM人员处理生产订单归档
2005年9月 根据PLM实施、ERP升级需求,提出合理的硬件配置方案和议标
2005年9月 协助PP人员处理生产订单归档
2005年10月扩充ERP小型机文件系统,节假日正常开关机
2005年10月完成HP对小型机的预防性维护检查
2005年11月UPS电源技术资料完善,验收报帐手续办理完毕
2005年12月SAP和ORACLE系统用户检查
2005年12月比亚乔业务直接接入系统运行技术可行性评估和测试

第二部份:主要问题与不足
(描述组织以及环境存在的问题以及自身的缺点和不足)
1、 现在无SAP的OSS技术支持,系统出现异常问题可能无法立刻解决,排除隐患。通常我们遇到系统异常问题。(有时是某个程序问题,也可能是数据库层或其它影响比较大的问题)会被提交到SAP的OSS网络上,上海SAP支持中心的人员会参与解决,如果问题比较严重,还会被上报到德国SAP总部让开发人员和知深顾问协同解决。这个机制可以比较稳妥的解决系统异常。
在没有OSS技术支持的情况下,我们也可以自己解决一些问题。如有一次系统在正在备份中死机。ORACLE数据库重新启动后无法识别数据文件,提示需要做介质恢复,就是数据库的全库恢复。当时我没有SAP OSS资源可用,只能打电话给原来有过联系的SAP上海公司的张顾问。虽然他可以算得上是中国比较好的BASIS顾问了,但得到的答复也是要去做全库恢复。我算了一下,按我们现在带库的读写速度,至少需要1-2天才能恢复完毕,而且是否能达到预期的结果也不知道。因为原来提交的问题多了,对上海SAP支持中心流程也比较了解,他们一般接到问题也是在SAP官网上去找Notes(一个人的经验总是有限的,SAP公司会把曾经被处理过的问题整理成Notes的形式供顾问参考)。我用出错提示信息做关键字找到了一个Note。上面清楚的讲述了备份中数据库文件会被打上备份标记,备份完成后会打上备份完毕标记。而数据库的启动需要全部的文件在未备份模式。这就是我们的ORACLE数据库后来启动不了的原因。参照Note记载的操作步骤,我手工去掉了备份标记然后启停数据库和完成了数据库检查。两个小时后,我们的系统又恢复了正常。
这一个问题是解决了,但在没有SAP OSS支持的情况下,如果其它异常的问题出现,而我们又没有那么幸运地找到一个note。可能就不会很快很完善地关闭它们。

2、 系统硬件资源及使用管理不够。我们的系统硬件资源不足也是老大难的问题了,内存偏小,给ORACLE数据库的总是那么可怜的一点点。ORACLE数据库的SGA区分得的物理内存越大,所得到的数据库性能越好。但现在我们的SGA是偏小的,因为没有更多的物理内存给它了。现在的SAP服务器使用的虚拟内存大大超过了标配值,这表明系统在使用缓慢的磁盘SWAP区代替物理内存,这样所得到的性能肯定是不会好的。
在这样的硬件资源上,要求我们更精细的管理和分配用户的使用,比如数据组的很多批倒入操作都很影响系统性能。经常会发现这样的情况:当有用户反映系统比较慢时,总能发现有数据组的人员在系统中操作。
还有就是现在我们的系统数据非常的大,有时用户在一个事务代码中查询数据的量也非常的大。这些操作都应该安排在夜间而不是在高峰期出现。
从近几个月数据库的统计看,新增编码的减少使数据库的新增数据也大量减少。数据库增长从上半年的20G/月减到10G/月。

3、 对ABAP的使用不够深入。当我意识到应该有一个程序能够自动的监控ORACLE的日志目录,我写了一个HP-UX shell程序,让我的系统可以自维护。从此我们远离了因日志爆满而数据库停机的困扰。当在给财务部做科目授权因数据量太大,用手工操作无法保证准确性和进度时,我用VC写了个财务科目授权程序,它能够自动产生SAP的角色文件,只需要财务关键用户分配完科目数据后,简单的把角色文件加到用户上, 就准确高效的完成了令人眼花缭乱的科目授权控制。
但是我的ABAP空间中,ides里写了不少测试程序,半年前买的<>也已经通读完一遍,却只在我们的正式系统中有一个ZBA03显示用户电话号码的报表是属于我的。而我的ABAP技能的积累也因为职务和工作侧重点的原因,进展缓慢。我准备在新的一年加强对ABAP的学习和使用。使自己的ABAP技能可以达到一个新的水平。

4、 项目实施经验少,对其它系统构架了解少。从erphome上大量涌现的新人和51job长期求贤若渴的招聘信息,可以预示新的2006年,SAP在中国的发展依然强劲。SAP系统是跨平台的,可以使用多种数据库。现在我比较熟悉的构架是我们目前的HP-UX+ORACLE的方式。同BASIS的朋友的交流中体会到,一个好的顾问应该不但经验丰富而且熟悉多种平台。从身边的越来越多的SAP软件被使用的环境中,也能够感到,一个称得上好的BASIS技术人员需要去掌握多种平台上的复杂情况。

第三部份:个人改进计划
(对个人缺点与不足的改进措施和计划)
1、加强对其它模块和ABAP技能的学习
2、加强对其它系统构架的学习


第四部份:下一年度工作计划要点及建议
(主要工作项目要点或思路,可以向上级领导提出与本职相关的工作建议)
1、确保ERP系统稳定、不间断运行,严格维护ERP系统用户权限。
2、精通BASIS涉及的各项技术,向顾问角色转变。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/791207/viewspace-966444/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    12
  • 访问量
    177555