进销存系统除了满足业务需求外,由于业务的需要,还经常会有跨组织、跨部门的多线程协作。正是因为这种特殊性,进销存系统在大多数情况下也需要满足管理需要。
进销存的天然管理属性你可能会问,进销存的管理需求是什么?
所以举个简单的例子,比如采购材料。这个业务流程会经过哪些步骤?从经验来看,采购物资的流程必须经过“采购发起->:采购确认->:采购收货->:采购”流程,这只是采购物资的示例流程之一。事实上,由于行业内供应商的多样性,采购物料的流程也相对多变。然而,从管理的角度来看,在这个过程中可以解决哪些管理问题?
举个例子,
本次采购物料的发起,当下是否合理?确认采购订单,需要由哪些人拍板?采购入库,怎么保证库存可用?采购付款,如何走批款流程?比如上面提到的案例,都涉及到业务单据流转的多方确认或批准,自然就提出了管理的概念,这也是有管理需求的购销存系统的属性。
业务需求体现为“业务流-业务流-信息流-资金流”的管理。
管理需求是如期将业务流转掌握在可控范围内,从而彻底结束业务生命。这个过程的管理就是业务的审计流程管理。可以说进销存的业务管理基本就是审核流程的管理(当然也不排除其他行政管理,但是整合进销存的需求确实有限)。
进销存管理组织和角色的搭建常见的管理大致可以分为事务管理和人事管理。运营中最常见的管理架构是以行政系统的组织架构为核心,以人员与行政岗位的匹配为链条,通过层级关系构建的组织架构。如集团-分公司、总部-行政部门、高层-中层-基层,再填充链条中的具体岗位,就成了有血有肉的行政系统组织结构。
进销存管理的需求,需要在如何通过系统工具建立和映射行政系统的组织架构,让各个机构的工作人员畅通无阻的完成业务,甚至提高业务效率上实现。
如何实现?常见的做法,就是在购销存系统中,相当于设置了一个平行的行政系统组织结构。管理岗位对应进销存系统的岗位信息,建立进销存各模块涉及的系统角色,并为每个角色分配相应的职能权限。
在功能组织上,对进销存业务的流转单据进行分析、拆解、打包,使其成为独立又相互联系的功能模块。
这样根据业务蓝图将一个或多个功能模块分配给与进销存系统中的岗位相对应的不同行政系统中的岗位,是一对一或一对多的匹配关系,即每个岗位可以实现跨组织、跨业务的管理需求。比如财务部门的财务岗位角色,可以跨部门直接获取采购部门的采购订单,下推采购应付单,在财务部门内部走采购预付款的审批流程。在这个过程中,采购部门的采购角色只需要做好采购物资,共同完成采购物资的业务生命。
通过角色定义业务权限,相互独立互不干涉,各司其职,是购销存系统在管理要求上的明显体现。
五大权限只能通过分配 *** 作权限来设置模块的业务权限。单据的任何 *** 作权限无非就是增加/删除/修改/检查/审核,每个 *** 作权限对应两个流程 *** 作:确认和取消,这是一张单据的五个权限。
这能达到什么样的场景?在系统组织架构上,比如采购部门的采购专员可以增加采购订单,采购部门的采购主管可以完成采购订单的审批、确认或拒绝。按照定义好的业务蓝图的单据流转,所有的业务场景基本都可以通过组织和 *** 作权限来实现。
权限的分配原则权限的合理分配,需要对自己的业务流程有一个清晰的认识,需要对好的程度有一个平衡。目前,本文介绍了两种权限分配原则,分别适用于两种截然相反的场景:
原则一:上层做减法,下层做加法。
使用场景:
适用于组织处于多次变动调整期,或组织架构不清晰,或业务场景不清晰,导致权责不清的运营场景。简单来说,在 *** 作权限配置之初,上层岗位角色被赋予较多的业务 *** 作权限,而基层岗位被赋予较少的业务 *** 作权限。在业务调整过程中,根据各种渠道收集到的反馈,逐步减去上层不相关的 *** 作权限,增加基层所需的必要 *** 作权限。
原则二:按级别按需分配
使用场景:
适用于组织架构严谨、业务流程清晰、岗位职责明确的运营场景。这种场景比较好理解,就不多介绍了。
在实际的权限分配中,大多数情况下,原则1和原则2往往并行执行,这是可以理解的。
嗯,这个时间以上的一切。本文中多次提到了业务流程的概念。打算下次再介绍。
请随时给我你的建议。
相关阅读用MVP思想分析最小可行进销存产品
文章的作者是@阿诺德·阿诺德。未经许可,禁止转载。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)