进销存系统，在满足业务需求之余，往往由于业务需要，跨组织跨部门的多线程协作相当多见，也正由于这种特殊性，大多数情况下进销存系统也需满足管理上的需求。
进销存的天然管理属性
也许你会问，进销存到底有哪些管理需求？
那么简单举个例子，比如采购物料，在这一个业务流程会经过哪些环节？从经验上来说，采购物料流程，必然经历“采购发起—>采购确认—>采购入库—>采购付款”的流程，这还只是采购物料的其中的一个举例流程，事实上由于行业供应商的多样性，采购物料的流程也相对比较多变。但万变不离其宗，在本流程，从管理角度上切入，可能会解决哪些管理上的问题？
比如，
- 本次采购物料的发起，当下是否合理？
- 确认采购订单，需要由哪些人拍板？
- 采购入库，怎么保证库存可用？
- 采购付款，如何走批款流程？
举例的以上种种，在业务单据的流转上，涉及到多方的确认或审批，自然而然提出了管理概念，这也是进销存系统天然带有管理需求上的属性。
业务上的需求，体现在“业务流-操作流-信息流-资金流”的管理。
而管理上需求，则重在把握业务在可控范围内如期流转，完整地结束业务生命。此过程的管理，是业务的审核流管理。可以说，进销存上的业务管理，基本上是审核流的管理（当然不排除其他行政上的管理，但能融入进销存的需求实在有限）。
进销存管理组织和角色的搭建
常见的管理，大致上可分成对事务的管理以及对人员的管理。运行最常见的管理结构，是以行政系统组织架构为核心，人员匹配行政岗位为链条，通过层级关系搭建而成的组织架构。如集团-分公司、总部-各行政部门、高层-中层-基层，再加以填充链条种具体岗位，就成了有血有肉的行政系统组织架构。
而进销存的管理需求，则需要实现在于如何将行政系统组织架构通过系统工具完成搭建和映射，使各组织的各人员能完成业务的行使上畅通无阻，甚至能提高业务效率。
如何实现？常见的做法，即在进销存系统也等同搭建起与之平行的行政系统组织架构，行政岗位对应进销存系统岗位信息，建立进销存各模块涉及的系统角色，分配各角色分配对应的功能权限。
在功能组织上，分析、拆解、打包进销存业务上的流转单据，使之成为一个个既独立又相连的功能模块。
这样一来，不同行政系统组织上岗位，对应进销存系统的岗位，根据业务蓝图，分配一个或者多个功能模块，是一对一或一对多的匹配关系，即能各岗位实现跨组织跨业务的管理需求。如财务部门的财务岗位角色，可以跨部门直接获取采购部门的采购订单，下推生成采购应付单，并在财务部门内部走采购预付货款的批款流程，在此中采购部门的采购角色只需做好物料的采购动作即可，共同协作完成采购物料的业务生命。
通过角色界定业务权限，互相独立又互不干扰混乱，各司其职，这便是进销存系统在管理需求上的明显体现。
五大权限
功能模块上的业务权限，只需分配操作上的权限进行设置。任何单据的操作权限，不外乎是增／删／改／查／审，每种操作权限都对应「确认」和「撤销」两种流向操作，这就是单据五大权限。
这可以实现怎样的一个场景呢？在系统组织架构上，比如可以实现由采购部门的采购专员新增采购订单，由采购部门的采购主管完成采购订单的审核确认或驳回拒绝。根据已界定的业务蓝图的单据流转，通过组织和操作权限，基本可以实现所有的业务场景。
权限的分配原则
权限的合理分配，需要对自身的业务流程有相当清晰的了解，并权衡好度的把握。目前介绍两种权限的分配原则，分别适用于两种截然相反的场景：
原则一：
上层做减法，基层做加法
使用场景：
适用于组织处于多变动调整期、或者组织架构不明确、或者是业务场景不清晰而导致权责不分明的作业场景。简单的说，在开始配置操作权限时，上层岗位角色分配较多的业务操作权限，而基层岗位分配较少的业务操作权限。业务在调整中前行，根据从多种渠道收集到的使用反馈，渐渐对上层无关要紧的操作权限做减法，对基层所需的必要操作权限做加法。
原则二：
按级按需分配
使用场景：
适用于组织架构严谨、业务流程清晰明了、岗位权责具体分明的作业场景。这种场景相对很好理解，不多做介绍。
在实际的权限分配上，大多数情况下，原则一和原则二经常并行执行，无可厚非。
嗯，以上本次的所有内容。文中多次提到业务流程的概念，计划到下次再做介绍吧。
不吝赐教。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。