HCL 中文技术社区

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1637|回复: 0

为什么OA应用软件不适合做企业的业务协同

[复制链接] TA的帖子

124

主题

200

帖子

5064

积分

超级版主

Rank: 8Rank: 8

积分
5064

活跃会员热心会员灌水之王最佳新人

发表于 2020-10-10 14:03:15 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 亓锋 于 2020-10-10 14:03 编辑

#dominoforever

这个文章标题一定会触动某些人的敏感神经:“什么?我们公司的OA不适合做业务协同?!”

淡定,淡定。请大家看看我二十年的职业生涯中所遇到的一些大是大非的问题。

我必须强调,我不是说OA应用软件不好,而是想告诉大家一个道理:“术业有专攻”,莫让一些认知误区给误导了,结果吊死了OA实施团队,坑惨了业务部门的用户。在某些应用场景下,OA应用软件的优势是非常明显的。但是,OA应用软件不是万能的,有很多时候OA软件不能解决你的业务问题。

OA应用软件适合做办公类应用,垂直行业或者垂直业务需求的信息化并不是OA的强项。这里需要特别指出:某些OA厂商也推出了面向某一类业务的解决方案或套件,比如电子合同管理、工程项目管理等等。这些解决方案不能归为OA应用软件本身,而是属于OA衍生方案或者属于业务型解决方案,即使它们用了OA的Logo、界面或者开发技术和架构。


640.jpeg


1、都在说“协作”,可是大多数客户都没有搞懂“协作”到底该怎么搞。

“协作”是一种行为,用软件来实现“协作”的前提必须满足协作的三个要素:“信息获取方式”、“人和人的互动”以及“信息和人的互动”。如果你认为把企业中的各种书面审批实现了电子化就是“协作”,在我们的行话里,你就是“唯流程论者”,是我们OA软件销售人员最喜欢的那一类客户——需求简单,可以快速卖钱冲业绩。


信息获取方式是要明确信息的来源和流向,也就是数据处理过程。大家听说过的“工作流”就是实现数据处理过程的一种自动化方式,但不是唯一方式。OA中的流程引擎,其实是“工作流引擎”。还有一种大家听到过的数据处理过程的引擎叫“BPM引擎”。BPM不仅仅可以实现工作流,还可以实现系统和系统之间的自动的信息获取和处理。例如很多HCL Domino应用就属于BPM类应用。


640.png


人和人的互动满足员工之间如何传递信息的需求,例如电子邮件、即时消息等通讯手段、社区、微博、Wiki等,以及在互动过程中产生的各种数据的管理。

题外话:HCL Connections了解一下。


信息和人的互动是在完成信息获取和处理后,信息如何被人感知的过程。挺抽象的,具体的理解就是我应该怎么把信息推送给正确的人。这里就包括各种现代化通讯手段,还有软件自身的UI设计等。


按照主要应对场景来划分,协作可以分为“办公协作”和“业务协作”两种。

  • “办公协作”解决“与员工相关”的问题,例如请假、出差、报销、入职等等。很多时候,我们把“办公协作”称为“行政办公电子化”。办公协作是最基本的企业协作需求,它能帮助客户实现最初步的审批过程电子化。请不要小看像请假、出差、报销等等这些小流程,如果一旦它们被提升到“业务协作”层次,就不是小流程,很可能是一个大系统。比如报销流程可以提升到企业预算和费用管控这个高层次需求,那是一个需要具备很强财务管理经验的项目团队才能实施成功的大系统。
  • “业务协作”解决“与业务管理”相关的问题。常见的业务管理范围包括:人力资源、人才、财务、采购、销售、行政、党建、运营、工程等等。大家可以想象一下,一旦使用“协作”理念实现上述业务的管理,将是一个多么大的工程:它需要以某些业务部门为核心,全盘考虑企业中其它部门与核心部门的数据互动,结合企业业务规则和自身特点,打通所有业务环节,实现数据采集、分享和分析的自动化。业务协作的一个捷径就是:以业务流程管控为主线采集数据,以数据分析为手段实现业务监管。

用户在“协作”上的需求是分成三个层次的。我按照一般的演变过程来讲解一下这三个层次。

一开始,实现审批过程电子化就可以了——这也是我们软件销售最喜欢卖给你的方案:办公电子化和自动化。这就是第一层次的需求:电子化(或者信息化)需求。这个层次的需求大部分是办公协作。

等用了一段时间,用户,尤其是业务管理部门的用户就会发现只有“台账”功能是不行的,例如请假流程做个请假单台账无法满足人事部门的报表输出需求了,报销流程做个报销台账无法满足财务部门的报表输出要求了,部门经理没法实时获取部门费用分析图表了……于是大多数用户就产生了第二层次的需求:数据分析需求。

大家可以看到,第一层次需求解决了如何获取数据的难题,即实现电子化和流程化地采集各类数据,第二层次的需求需要解决的是数据如何利用的问题,即数据进行汇总和分析以后对业务管理的决策支持。

又过了一段时间,每个业务部门的领导们开会一合计,不如把各个业务部门的流程和数据做一次全盘规划,真正打通每个业务环节,实现业务管理的部门联动,让每个业务管理人员能够各取所需,为企业管理者提供更准确的决策支持。于是第三层次的需求就来了:业务自动化。

举一个简单的例子,采购部门提请的一份原材料采购合同后,一些列的事情就发生了:财务部门看到的是什么时候应该支付什么款项(应付账款),仓储部门看到的是收货清单和验收标准,生产部门看到的是原材料库存清单……同时,在企业ERP/财务系统中,库存、应付账款等就会发生变化。



第二层次和第三层次的需求就全部是业务协作范畴了。


你看看这三层需求像不像人的基本需求:

  • 生存的需求(解决有没有的问题)
  • 认识自我的需求(解决这些东西是个啥的问题)
  • 实现自我价值的需求(解决这些东西咋利用的问题)


当用户需求发展到第二层次数据分析需求时,原来粗糙的电子化表单和表格就可能要进行精细化改造,确保能够采集到更多、更准的数据。以前报销流程中一个报销总金额就不够用了,它需要被改造为按照公司财务会计科目分类进行填报的分项表格,要求每个员工按照财务规定将费用填写到不同的会计科目下面。

当用户需求发展到第三层次业务自动化需求时,所有过程管理都必须实现与企业各种业务系统的对接。比如客户数据对接到CRM,供应商数据对接到ERP,财务凭证要自动对接到财务系统等等。

当然不排除有些客户在第一层次电子化需求时,就提出了与企业各种系统的对接,那么恭喜这些客户,你们就差第三层次需求了——实现业务决策支持系统,最差也要实现各类业务报表。


OA应用软件适合“短、平、快”地解决客户的第一层次需求。但是,如果用户在打算进入到第二层次或者从一开始就要进入第二层次时,OA应用软件在实施过程中就必须做到“精细化”和“定制化”,尤其是各种表单的格式要依照企业要求变得复杂,同时还要实现企业要求的数据分析图表。

所以,一旦OA应用软件进入到业务协作领域,就基本上丧失了其“短平快”的优势,同时实施团队也要从应用实施团队变成业务开发团队,从技术实施团队变为业务顾问加技术实施团队。


协作系统项目实施时,请注意以下几点,避免吃瘪:


  • 如果一个实施商团队全部是技术人员帮你做业务场景设计时,你真的要小心了。不理解业务管理的团队,做不出你要的业务协作系统。
  • 一旦业务部门对正在实施的业务应用提出改进意见,请仔细评估是三个层次的需求的哪一种。如果是第二和第三层次,必须要求实施团队按照业务部门在数据采集、数据处理和数据分析和利用上的要求进行实施。千万别抱着幻想先搞定第一层次需求以后再说。等真的到了以后,你会发现系统里面存储的数据根本就不完整,根本无法顺利提升到更高的层次。
  • 每个企业都有各自的业务特点,这是一个底线。如果实施团队拿来一个现成的业务模块给你使用,请一定要小心。如果连公司领导都觉得“我们拿来就用,我们可以适应软件里面的规则”,那么请准备好另外一笔预算:系统重构预算——这不是系统升级和改造预算哟,是重构,就是推翻重来!除非企业不发展了,迟早有一天这笔预算要派上用场。
  • 请从“关注流程”转变为“关注数据”。作为实施团队要尽可能地引导业务部门的用户讲出“数据从哪里来,数据怎么处理,数据与其它系统的交互,数据怎么汇总和分析”。前面讲过,流程仅仅是实现数据采集,数据的利用才是业务部门最关心的结果。如果一个实施团队总是在和业务部门谈及表单什么样,流程怎么走,请小心为妙。


640-2.png



2、大多数人看到“流程”两个字就想到“OA”,还没有搞明白“流程”的本质是什么。

我曾经碰到很多用户,他们一旦提及要实现审批电子化就先说上一套OA软件就好了。可以看出OA软件在企业市场是被普遍接受的,而且其流程电子化的好处是众所周知的。可是,在没有搞明白“流程”的本质的时候,贸贸然去实施一套OA软件是非常不合适的。

我遇到过很多客户,明明是要完成业务协作场景的实现,还没有搞明白各种业务流程的关联和数据关系的时候,就提出上一套OA软件。好一点的结果,一些客户上了一大批离离散散的各种OA工作流;而最坏的结果就是无法向业务部门交付一套完整的业务协同应用,项目超期,甚至烂尾。

我喜欢用“业务过程”这个词来替代“流程”这个词。我会问业务部门的用户,这个业务的过程是什么样的、我需要了解一下你有没有现成的或者需要实现的数据图表、根据最终的数据报表,我们需要在业务处理过程中获得哪些数据、每个环节可以得到什么数据,数据怎么样被处理……

一旦你的实施团队用“业务过程”这个词去和业务部门洽谈需求时,你就会发现很多潜在的用户需求就暴露出来了;你会发现这不是简单的一个电子化流程的事情,而是一连串的业务处理环节,每个环节都可能涉及到数据格式、数据交互和系统集成的问题。


曾经有一个非常著名的国际大公司需要做一个系统对各种营销和销售的预算和费用进行管理。这是一个典型的财务型业务协作需求,其实就是实现各种预算和费用的关联,结合在线审批,实现费用管控规范化。

我的团队当时给客户的方案里面提及了如下几个要点:

  • 企业编码统一化:供应商、客户、物料、财务科目、成本中心等全部依照其SAP系统的编码进行管理。
  • 以流程管控为主线采集各种营销和销售的费用数据,面向营销部门的报表分析的需求实现数据采集的精细化。
  • 预算与费用实现强关联,从任何一笔预算均可查询到这笔预算的使用情况——预算汇总表要实现每笔预算的费用分解。
  • 按照权限,实现图表分析——汇总、走势、分解……
  • 移动化(必须滴)
  • 与SAP实现集成,费用可以自动生成财务凭证
  • 本地化部署合同电子签名系统,实现“强甲方”模式的供应商合同管理
  • 按照事项进行审计和监管,任何一个营销活动都可以拉出预算与费用清单,便于内审和审计

很可惜,客户最终认为这些需求使用一套OA软件就可以解决了。如果OA厂商能够派出业务顾问和实施团队,采用企业预算和费用管控的理念,这项目也许就顺利实施完成了。可惜的是从2019年12月份到2020年5月份,这个最多30个业务过程的“营销和销售费控系统”还没有上线。

640-2.jpeg

OA的强项确实在于“流程”,严格意义上说,OA的强项是“工作流”。在涉及到强数据关联,强业务关联,强数据分析需求时,OA的唯一优势也只能在于“工作流”,大量的定制化开发需要OA软件不能有太多的局限性、大量的业务规则往往在工作流之外、符合业务管理需求的数据分析和图表需求不可能是标准化的,一定需要实施团队里面有熟悉业务管理的顾问……



总结

搞明白某些概念,避免认知误区,才能把企业信息化做好。和大家说了这么多,等于把我们这些协作软件销售的底裤给扒掉了。



最后请看看你是不是容易被忽悠的那一类客户。

1、买个现成的软件用就行了,我们没有啥特别的需求

2、你会相信某个销售的话:“你要的这些模块我们的软件里面都有,是现成的。大不了稍微修改一下就能用了” 。

3、你会相信某个销售的话:“我们的产品在业界是No 1!这么多客户在使用,是有口皆碑的。”

4、你会相信某个销售的话:“你的需求没毛病,我保证两个月就能上线”。

5、我们的合同都是这样签的,首付50%,上线后收30%,上线后三个月支付尾款。(注意,是“上线”,不是“上线验收后”;没有质保)

6、我们的产品使用起来很简单的,一学就会了。

7、项目实施一半了……“这个功能我们实施不了,需要定制,如果定制的话得另外加钱。”

8、项目实施一半了……“我们提供的实施模块里面没有这个功能的……”

9、项目实施一半了……“你们的业务规则能不能按照我们软件的设定来改,不然上不了线。”

10、项目实施一半了……“你要的那个模块不包括在我们的合同里,需要的话要额外加钱。”

遇到以上情况,赶紧填坑吧,免得吃瘪!



给某些软件销售的话

心即理

知行合一

致良知



WechatIMG2.jpeg

回复

使用道具 举报

高级模式
B Color Image Link Quote Code Smilies

本版积分规则

QQ|手机版|小黑屋|HCL 中文技术社区 ( 沪ICP备17044822号 )

GMT+8, 2023-1-28 17:44 , Processed in 1.050072 second(s), 25 queries .

快速回复 返回顶部 返回列表