我们有自己的OA系统，但那玩意儿太难用了，所以考虑一下Odoo。
我所接触的大多数员工，都用这个理由来理解我们的BOSS要在今年上线ERP系统的原因。正如这个问题所言：
OA是不是使得我们先入为主了？我们需要什么的IT内控流程？
这是以OA先入为主的管理理念。这是指：
所谓管理就是一系列审批流程。管理到位就是把审批细化到每一个业务操作中，因为人是会犯错误的，所以通过层层的审批就能最大程度杜绝错误，就能让领导做到有效的监管。乍一听似乎没有问题，员工出错，有其它部门同事确认呢，再不济，还有领导审核把关啊，还有领导的领导盯着呢，还有领导的领导的领导批示呢...。因为日常每个人都涉及了大量的审批提交和审批工作，为了防止人浮于事，要求每次审批还都要有审批意见。所以，就会有一个定制要求，就是将一些常用的审批意见保存，以方便审批人选择。所以，每个审批流里都充满了“已审核”，“通过”，”同意“， ”已阅“。
我们的认知模型，往往是先定义后理解。我们真正需要的IT内控流程是什么？是需要在业务出了问题的时候来认定责任吗？因为领导批了呀，连老板都已阅了，所以责任不在业务人员吗？
业务部门内合理的审批是必要的，毕竟业务处理人员才是最了解业务和当前状态的人，但对于更上级的管理人员，因为有更多的信息来源和更广的管理视角则更应该关注业务状态的分析和计划工作，而不是参与到具体的业务操作审批中。大多数情况下，业务的协同需要的是业务信息的正确传递，比如订单确认后我们可以自动通知仓库备货，提供准确的备货信息，通知财务部门开票，提供客户的信用和开票信息。如果某些业务需要进行多部门的会商讨论，讨论的过程和结论都与能业务记录关联。
总结来说，我们需要的IT内控流程要做到两方面：
-
在企业经营的环节促进信息流转，适当引入自动化，提高我们的生产效率。
-
业务相关人员应该主动，高频的沟通（不是通过OA审批流！），IT系统只保证：这些沟通的过程和结论和业务记录相关联。
Odoo的产品设计理念是怎样的？
Odoo的产品设计理念是：开箱即用。 以原生应用的方式导入，可以降低企业实施的门坎并且保持易用性，在原生应用下可以容易感受到Odoo基于管理的应用逻辑。
Odoo从V9开始就逐步去掉workflow背后的原因有哪些？给我们什么样的启示？
首先，Odoo去掉了workflow更多的是技术上的意味。
Odoo的工作流，是针对一张单据而言，每个【角色】可以执行一定的【操作】从而触发【信号】，改变单据的【状态】。这些操作对应的是该角色参与这项工作的职责，而不是【同意】【不同意】【已阅】。Odoo的工作流也没有【回退】这样的路径，如果某个环节发现单据的信息有误，就做【归档】处理，也就是报废单据，然后需要重新发起单据。
image.png
在左上角的【审核】按钮是【操作】按钮，右上角的【草稿】【开启】【已付款】则是单据的状态。
所以Odoo的workflow不是审批流，而是围绕一张单据从草稿到生效的状态，不同角色参与的流程，或者说是一个有限状态机。Odoo从V9开始就逐步去掉workflow，是指Odoo不再提供在界面上可以配置的某张单据的状态，而是让不同的模块开发者在代码中实现单据的状态流转。
请看两种实现方式的对比：
使用workflow配置：
<record id="act_draft" model="workflow.activity">
<field name="wkf_id" ref="wkf_sale"/>
<field name="flow_start">True</field>
<field name="name">draft</field>
</record>
<record id="act_cancel" model="workflow.activity">
<field name="wkf_id" ref="wkf_sale"/>
<field name="name">cancel</field>
<field name="flow_stop">True</field>
<field name="kind">stopall</field>
<field name="action">action_cancel()</field>
</record>
<record id="trans_draft_cancel" model="workflow.transition">
<field name="act_from" ref="act_draft"/>
<field name="act_to" ref="act_cancel"/>
<field name="signal">cancel</field>
</record>
使用代码实现：
@api.multi
def action_cancel(self):
...
self.write({
'state': 'cancel',
})
用代码实现的方式似乎是更容易维护。我觉得一个需要保持更新的系统，它的维护人员，一定是要有代码能力的，国内的类似产品，可能会配置专门的配置管理员，不需要有代码能力，就可能导致维护成本很高。
Odoo的推行的管理理念是怎样的？
工具始终是工具，我们最终的落脚点是管理者的管理逻辑。如果管理者的管理逻辑和Odoo不匹配，那么我们不必要投入精力去改造Odoo。
沟通过程应该在线下完成，不是在审批的环节中去沟通。业务人员只要填写必要的信息，越少越好，其他的信息由财务人员或者行政人员填写。
from Draft to Done
一个单据通过不同的角色的协作，从草稿到完成，强调了各自的职能范围。存在这种情况，业务人员不理解合同需要的法务信息，如果将所有的合同条款交给法务来填充，那么法务的工作量就会激增。这当然是不合理的情况，我们还应回到各自的工作标准是什么的问题。如果法务人员和业务人员沟通好一些事项，做好普及工作，同时又制定了相应的标准模板，让业务人员可以在系统中选择，而不是连猜带蒙的填写，那么就可以减少双方的工作量。所以有没有沟通是一个问题，沟通结论有没有固化也是一个问题。
办公用品，IT用品只需要发起需求流程，不需要发起采购流程。由行政管理来管理库存。
Different Role in Different workflow
将需求流程和采购流程混为一谈，也就是将行政人员和业务人员的职能混淆，行政人员应该及时保证库存可以满足需求而又不至于浪费，而这不是业务人员的职能。如果引入Odoo的仓储模块，行政人员是办公用品仓库的管理员，库存的出库单可以关联到一个需求单，而行政人员又可以检索库存，确定用量。这才能满足管理制度上对各岗位的职能设置。
也就是，通过Odoo的模块化应用，赋予一个用户不同的角色，这个角色对应其在这个工作流的岗位职责。
对相应的财务信息要做好统计分析工作，报表要自动化输出。
what you do will to be seen
Odoo在代码的model和底层的data之间的映射是直观的，这个和其他的数据库逻辑是不一样的。所以我们可以方便的获取流程中产生的数据，我们还可以通过源代码相关的类来理解数据之间的关系。而使用第三方OA平台，在数据这一层都设置了复杂的交互逻辑。除了将数据同步给BI之外，Odoo也专门为报表做了设计，可以在合适的场景使用。
参考链接
网友评论