ERP项目部员工述职报告表(2005年度)

 

ERP项目部员工述职报告表

（2005年度）

部    门：   集团ERP项目部
姓    名：     刘    欣    
岗    位：   ERP系统管理员 
填表时间：   2005-12-31     
      

 

 
个人述职

第一部份：年度工作完成情况
（指标完成情况用数据和要点方式陈述）
作为一个ERP 系统管理员，个人认为在2005年度比较成功的实现了对ERP系统的BASIS方面事宜的管理。我的工作主要是:
ERP生产系统和测试系统维护(及时监控系统性能、系统备份、程序变更)。
ERP生产系统和测试系统用户权限维护(严格按照提交的<<ERP系统权限修改表>>维护系统用户的权限，全年维护上千次，几乎每天都会收到更改请求)。
在确保ERP系统全年稳定运行的情况下，解决了ERP系统大量BASIS模块相关问题。其主要事宜如下:
2005年2月 根据SAP EWA报告，调整SAP系统参数
2005年2月 编写<<ERP系统维护流程>>和<<ERP系统数据备份>>操作文档
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里写了不少测试程序，半年前买的<<SAP程序设计>>也已经通读完一遍，却只在我们的正式系统中有一个ZBA03显示用户电话号码的报表是属于我的。而我的ABAP技能的积累也因为职务和工作侧重点的原因，进展缓慢。我准备在新的一年加强对ABAP的学习和使用。使自己的ABAP技能可以达到一个新的水平。

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

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

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

第五部份：自我综合评分（100分制）：
自评分：100分

个人签名：刘 欣