业务流的另外一种场景:工作协同流程

Posted senline

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了业务流的另外一种场景:工作协同流程相关的知识,希望对你有一定的参考价值。

今天给开发的讨论业务流程,其中一个业务部门土匪甲的说道,我的流程可能不是固定的,随时可变怎么办?

这下子开发的蒙圈了,屌丝A叫道:那怎么行,你老变来变去,怎么画流程?

另一个屌丝B说,你老变,是不守规矩,说明你还没有搞清楚自己要做什么。你先搞明白了我们在讨论如何定义流程吧。

我在旁边看他们撕逼,自己在想土匪甲要求的合理性,在现实中有没有应用场景。

一般来讲,企业中的业务流程相对是比较稳定的,很多流程系统也是基于这个假设进行开发和设计,并据此划出流程图,绑定上业务逻辑。

但是实际中,除了这些“典型的”,“经常发生”的业务事项之外,还有一些偶发的,但是种类繁多的事项发生,需要处理。这些事项也会涉及到方方面面的人,但是特点是处理过程不固定,随意性比较强。比如迎新会中的人员统计,体检服务单位的选择,打印招聘材料等等。

对这种事项如何应对呢?

对策A是不放到系统中,不处理,

另一种对策B是,对所有的这种杂项进行抽象,统一成同样的处理流程。

对策A是一种不作为的,不讨论,对策B,抽象的可行性有多大?如果杂项非常多的话,难度还是比较大的。

那么,我们有没有对策C,以不变应万变的方法呢。

其实处理这种杂项的本质和其他业务流程是一样的,就是在一定的时间内,由一帮子人一块把某个事情办好,只不过,办事的步骤千变万化,涉及的人也不固定,办事的方法也因事而异。那么我们能否这样考虑:

1,步骤在发起的时候由发起人来指定,人也有发起人来指定,或者中间步骤的任何一个人都可以指定或修改。这就解决了办事步骤千变万化的问题,解决了设计的人不固定的额问题。你变没关系,我即时指定啊。

2,办事方法,这个稍微有点复杂,需要我们抽象下。我们不考虑方法,我们只考虑结果,你只要把结果提报上来就行了。

提报结果的方式有很多,输入一个或者一些数据(比如输入我的邮箱地址,我的借款余额),回答是否同意,某件事情是否办妥,上传数据文件(根据模板)等等。

这一步是核心,是比较难的一点。可以慢慢完善和优化。

我们把这个称之为 即时工作协同流程

 

我们以一个例子来具体说下

我在招聘会上收了份简历,这个简历想回家东营工作,恰好我们在东营有开发团队,也在招聘人,我需要把这个事情通知到东营的人,联系面试,并跟踪这个事情的进展。

当然这个离职可以有固定的流程,但是我这里用上面说到的“即时工作协同流程”来演练一下。

1,人事招聘专员发起一个协同

      输入协同事项的主题:东营本地化面试-张三

      输入事项的关键之:面试,招聘,东营

      输入事项描述:说明白这个事项的缘由,需要做的工作。

      输入关注者:可以理解为邮件的额抄送,事项的任何变动都会通知到关注者

2,提交给下一环节

      输入提交给谁:东营的招聘负责人,可以是多个,

      工作主题:输入下一环节的工作主题,比如,请联系该人,组织面试

      输入或变更关注者:

待续。。。

以上是关于业务流的另外一种场景:工作协同流程的主要内容,如果未能解决你的问题,请参考以下文章

在离线填报的场景下,用SpreadJS完成权限控制

在离线填报的场景下,用SpreadJS完成权限控制

浅谈RocketMQ的事务消息

高速公路车路协同应用场景分析

Quick BI产品核心功能大图移动端:让数据在更多业务场景中流通

车路协同若干痛点问题的思考