从沟通方式看人的做事风格

        场景:四位不同角色的人聚集会议室

        主题:针对营改增带来的系统的需求变更      

        昨天下午与客户进行一场需求沟通会,参加会议的人员包括两位财务部人员,一位信息技术部人员及本人(乙方需求沟通及技术实现)。

        需求其实是一个比较常规的需求,但从这次需求会议中能明显看出两种不同风格的人的做事方式。一位三年左右的财务人员A,一位十年左右的专业财务人员B。此需求背景是金融行业营改增实施后,报销系统的优化问题,即就算某报销项拿到专票,也无法进行抵扣。因此,需要报销系统在前段标明费用和税额的关联报销项,最后在财务系统进行人工录入冲抵分录。但是目前的现实情况是报销人员为了方便,会尽可能多的将各项报销在同一张报销中完成。这样,从系统的角度无法准确区分出哪两条报销数据是税费项目。A提出在前端录入时通过某标记标示某两项是税费项,这样会减轻各机构财务人员的工作;B提出在费用项加一录入框,仅仅录入税额。这两种方式都可完成需求需要达到的效果。两位财务人员从不同的角度剖析需求,并提出自己倾向性的方案。于是一番争论开始了,A提出的方案的前提是需要报销人员对报销项及税有比较清楚的认识,要求相对较高;B主要从用户操作简便性及易理解性的角度来提出自己的方案,他主要考虑报销人员水平不尽相同,且流动性大,因此最好傻瓜式的操作。他提出他的论据,10年的工作经验告诉他,一定要将前端用户当成“傻瓜”来对待,这样才能减少后续工作带来的麻烦,宁愿自己辛苦一点,也不要让领导觉得这个问题是你的错。

        两种方案各有各的考虑,也不好说谁的方案更优。会议上并未形成最终的结论,会后半个小时,A邮件说最终决定用她的方案。从我的角度来看这个问题,其实用哪种方式都可行,最终的出发点还是用户的操作习惯问题,什么事情久了自然也就习惯了,不能习惯的事情,是压力不够大而不足以让你去习惯它。因此我也相对倾向A提出的方案。

对新员工的个人建议

        相信很多职场老员工都会有带实习期或者试用期员工的经历,如果遇到新进员工比较专业,那肯定会省心又省事。不过往往现在的市场行情,公司都希望招新人进来,原因主要有以下几点:

        第一,新人成本相对较低,公司除了承担社会责任外,它同时也是一家盈利机构,各种成本肯定会考虑进去;

        第二,新人未形成固化的工作模式,可快速引导其适应公司的工作方式,并尽快进入正式的工作中去;

        第三,新人往往能给公司带来一些创新及发散性的想法,对公司的发展带来比较积极的影响;

        第四,目前新进员工大都是90甚至95后,他们的工作方式及生活态度教70、80后有很大的区别,胆大,无所畏惧。

        以上这些都是企业招聘新人时常常考虑到的因素,然后并非所有的新人都是这样的。有部分新人往往是眼高手低、做事毛躁、时间观念差、做事效率低、责任心低……。这也并非个例,也并非自己对他们的偏见,只是希望这部分人能在职业化的道路上走得更好更快。举一个实例,A员工去年底招入某公司,至今未能转正,跟A共事过的同事都明显觉得A不太适合某行业所需的必要能力,因为驻场客户现场,需要时刻准备与客户沟通需求,解决问题,也需要与公司其他同事交流工作或生活上的事情。然后这些仿佛A都不具备,其实A已经毕业1年有余,进入公司前已经在某甲方公司工作接近一年。A进入公司后,公司领导将其分到B的名下,负责其在客户现场的工作及后续转正考核事宜。正常情况下,3个月的试用期是完全能够看出一个员工是否适合该公司,不过三个月早已经过去,A确丝毫没有表现出能适应这个公司的能力,B也多次电话/QQ/微信沟通(在这些沟通中,甚至连如何做工作,如果谈话,如何汇报工作都作了比较详细的指导),却效果甚微,在面谈后也没有明细的进展。于是转正事宜也只好一推再推,今年3月底,公司给出了一个截止日期,若A再不能通过考核只好劝其离职(试用期是双方共同选择的过程,并不涉及其它劳动纠纷)。实际上,到3月底,A依然没能通过领导和同事的认可。最近,A主动提出辞职,准备去往其他技术类公司。只希望A能好好让自己成长起来,职场有职场的规则,优胜劣汰是职场永恒不变的规则。以下是对实习期及试用期员工的个人建议:

        第一:员工忠诚度,这几乎是所有公司招聘员工的第一要素,因此新入职的员工需要在此方面表现积极;

        第二:做事的态度,这是任何公司任何领导都希望看到的,如果你不够聪明再不具备好的做事的态度,那么公司没有接受你的必要性;

        第三:时间观念,这同样是比较重要的职业素养之一,没有哪个公司希望看到员工天天到公司都是风尘仆仆的状态,这会给人一种不踏实的感觉;

        第四:专业能力,职场不同于生活,公司招你是因为你能为公司在某些方面带来利益,因此,专业能力的高低也决定了你在公司的受重用程度;这其中包括很多方面,与同事及客户沟通的能力、处理普通(紧急)问题的能力、对身边资源利用的能力、对工作计划实施能力等等;任何一方面做得比较好,都会使自己的职业发展走向更好的台阶;

        第五:情商,这个其实没有比较明显的评判标准,比如你能和身边的同事打成一片,说明你比较有亲和力;你能和客户保持比较好的关系,说明你比较懂得维护客户关系;你能在生活中主动关心身边的同事,帮忙解决某些生活工作中的问题,说明你有能力又热心;你能跟领导保持好的关系,说明你比较懂得人情世故(这也并非贬义),这都是情商高的表现形式。

        以上言论,纯属个人观点,不代表任何组织。

一条数据引发的“血案”

        情景:Oracle EBS系统批量付款

        现象:Oracle EBS系统批量付款卡死

        环境:Oracle EBS R12.1.1

    取名“一条数据引发的血案”是因为这次事件把自己的第二次通宵奉献出来了。

    直接进入主题:2016年4月21日周四,客户在财务系统内批量付款,这次付款从表面上看与往常的批量付款并无差异,92笔付款,量不算大,结果在最后一次鼠标点击确认的时候导致系统直接崩溃(只针对此功能页面,其他功能还是能正常操作)。如下图所示:

            点击应用    

            internal error

    一般涉及到付款的操作,一直都是需要十分谨慎的,要是因为付款抽盘数据错误,导致网银付款错误致使公司多付账款,将会造成不可挽回的错误。客户(刚进入公司的新同事)在第一时间找到我,焦急的心情从客户的表述中可以窥见一二。自己也是第一次遇到这样的错误,第一反应就是数据库表被锁了,因为之前也遇到过类似的错误,直接从后台解锁后即可解决问题。但是这次似乎并没有那么简单,后台并未锁表。于是,找到客户的纯数据库DBA检测,从后台的常规日志中可以看到“timeout”的描述,于是通过各种sql命令和linux命令穿梭于PLSQL和操作系统中(幸而能有同事提供生产环境的数据库)。然而,并没有解决,知道下班也并未有任何实质性的进展。于是,为了客户能在周五将今天的付款付出去,在已经格式化付款的状态,一条一条在付款撤销界面点击停止付款,大概统计了一下,这个步骤会超过500次鼠标点击(oracle做得太不智能了,吐槽一下),而且在这个过程中,还出现如下图所示的囧地,无法停止付款(后台解决,IBY_PAYMENTS_ALL表字段update).

            已提交打印

   由于感觉到事情的严重性,当天晚上到10点多仍然没有解决,于是乎觉得在办公室继续奋战,做到大概12点多,实在熬不起了,很久没有一直工作持续那么长时间,而且是脑袋一直不停的高速运作,在这过去的几个小时内,问过很多同行,大多都是没有好的建议,都建议再向EBS DBA咨询求助。晚上接近一点,睡觉(幸好办公室有张折叠床)。早上6点过几分,起床。继续查找问题,此时已经将昨天留下的92条中的78条数据付款(每次5条左右的数据批付款,也是倒霉,每次都没有碰到那天错误数据)。现在这个时候,最怕的就是客户的追问,不过第二天一早,客户的邮件就来了。客户希望在下午两点之前能解决问题。压力山大。为了能尽快解决问题,向公司申请EBS DBA资源,于是,公司提供一位DBA远程协助。经过20多分钟的排除,得出两个结论:第一,TCP SOCKET超时严重,排列超时第一位;第二,行级锁超时严重,排名超时第二位。DBA也只能做到这里了,但是此时时间已经是下午2点多,于是只能去跟客户解释,目前正在全力排查问题。客户也还好,也只能如此(其实我相信客户内心是崩溃的,两天时间已经积压了好几百万款项待付)。

    接下来是周六,本来是该好好休息的时间,结果因为这个事情,觉都睡不好,早上7点多就起来接着查问题。一上午还是没有比较实质性的进展,中午叫了外卖,下午还是继续排查。这之前跟领导甚至商议过如果找不出问题要怎么样先暂时解决问题(具体什么方法就不在此透露)。默默耕耘,必有回响。在晚上11点多的时候,也就是逐条付款的时候,界面上出现了一个比较直接的错误提示,违反唯一约束条件。如下图所示:

                唯一键

    于是,能80%确定是应用数据问题,结果果然发现,其中一个供应商的地点层竟然在失效后还多生成了一条付款数据,然后这在界面上看起并没有其他异样,结果从后台查看数据才发现此异象。表现如下图所示:

                失效地点层  

               同样付款数据

    此时,感觉修复此数据即可解决问题,于是对比正确的数据后,修复数据完成(具体修复方式,如果人遇到,可直接留言交流或者邮件),再次去付款,正常!!!此时想想一条错误数据,竟然能使系统到如此崩溃的地步,也是醉了。

    总结:这个问题告诉自己,很多事情并不只是表面上看起的那样,需要更深层次去发掘问题的根源所在。在解决这个问题的过程中,自己也学到了很多东西,对session的理解,查找效率低下的SQL方法,甚至一些很高级的操作系统层report方法。同时,要感谢在这个解决问题的过程中,客户的理解及各位同事的帮助。此文谨以记录此事。

EBS web页面Internal Server Error错误

    今天财务人员在系统内做批量付款的时候,点击最终完成应用付款的时候,系统一直处于运行状态,但却一直无法完成付款,过几分钟后,直接跳转至如下图所示的界面:

error

这是第三次出现这样类似的问题,从遇到的情况主要可能有如下两点原因:

1. 表空间不足,特别是临时表空间不足(第一次出现是因为此问题造成)

   解决方法:增加表空间,通过脚本查询出需要增加的表空间,增加即可(一般须有DBA执行增加表空间操作),命令如下所示:

select upper(f.tablespace_name) "表空间名",
       d.tot_grootte_mb "表空间大小(M)",
       d.tot_grootte_mb – f.total_bytes "已使用空间(M)",
       to_char(round((d.tot_grootte_mb – f.total_bytes) / d.tot_grootte_mb * 100,
                     2),
               '990.99') || '%' "使用比",
       f.total_bytes "空闲空间(M)",
       f.max_bytes "最大块(M)"
  from (select tablespace_name,
               round(sum(bytes) / (1024 * 1024), 2) total_bytes,
               round(max(bytes) / (1024 * 1024), 2) max_bytes
          from sys.dba_free_space
         group by tablespace_name) f,
       (select dd.tablespace_name,
               round(sum(dd.bytes) / (1024 * 1024), 2) tot_grootte_mb
          from sys.dba_data_files dd
         group by dd.tablespace_name) d
 where d.tablespace_name = f.tablespace_name
 order by 1;

2. 锁表,与付款相关的表被锁住(其中两次是此问题造成)

   解决方法:通过如下命令查出被锁住的表,最后一个字段即是解锁命令,在COMMAND命令行执行即可,特别是locked_mode为‘6’的在很大程度上是不应该存在的,具体原因请自行网络上搜索。

select dob.object_name table_name,
       lo.locked_mode,
       lo.session_id,
       vss.serial#,
       vps.spid,
       vss.action action,
       vss.osuser osuser,
       vss.process ap_pid,
       vps.spid db_pid,
       'alter system kill session ' || '''' || lo.session_id || ',' ||
       vss.serial# || ''';' kill_command
  from v$locked_object lo, dba_objects dob, v$session vss, v$process vps
 where lo.object_id = dob.object_id
   and lo.session_id = vss.sid
   and vss.paddr = vps.addr
 order by 2, 3, dob.object_name;

lock

最终执行命令如下所示示例:

alter system kill session '38,19020';
alter system kill session '278,3533';
alter system kill session '293,3774';
alter system kill session '1016,64895';
alter system kill session '1054,9699';
alter system kill session '1780,20723';
 

 

技术笔记(小潘的技术记录博客)