62,046
社区成员
发帖
与我相关
我的任务
分享哈喽哈喽大家好！~我又来了~问个关于审批流程及权限设计的话题！~
最近闲来无事
想弄点东西玩玩
其实就是一个简单的报帐系统
用户提交费用表单、领导审批、业务人员办理费用
基本94这些功能
偶想在审批流程和权限上琢磨琢磨
大家能不能提点好的意见和建议？！
1：权限
我基本上想这样
权限从类别上分为地区权限、产品权限等
从功能上分为申报、查看、审批权限等
能不能搞得灵活点？！
有没有可供参考的案例？？
2：审批流程
也搞灵活点？！
有没有可供参考的案例？？
最好能和权限也联系起来
大家给点思路？！
3：为什么只能给200分？！嘿嘿
想弄点东西玩玩
其实就是一个简单的报帐系统
用户提交费用表单、领导审批、业务人员办理费用
基本94这些功能
偶想在审批流程和权限上琢磨琢磨
大家能不能提点好的意见和建议？！
1：权限
我基本上想这样
权限从类别上分为地区权限、产品权限等
从功能上分为申报、查看、审批权限等
能不能搞得灵活点？！
有没有可供参考的案例？？
2：审批流程
也搞灵活点？！
有没有可供参考的案例？？
最好能和权限也联系起来
大家给点思路？！
3：为什么只能给200分？！嘿嘿
...全文
请发表友善的回复…
发表回复
AdonisChai 2007-01-18
- 打赏
- 举报
WWF（Microsoft Windows Workflow Foundation）中文社区：http://www.wwfcn.net
marrytone 2006-10-27
- 打赏
- 举报
这就给分了啊，哈哈，拿分了，就得给你说说：
用户A（北京主管） 用户B （上海主管） 用户C（广州主管）
A负责产品1和2 B负责产品2和3 C负责产品2和5
A的上级甲 B的上级也是甲 C上级乙
甲为北方区域（北京和上海）总经理
乙为南方区域（广州）总经理
丁为全国副总经理 负责产品3的销售
甲和乙的上级为丙（全国总经理）
A、B、C提交的销售报告都要提交给自己的上级审批
甲、乙审批完如果通过则由丙审批，如否决就返回
按照我设计的机制，
1。你有5个用户 A B C 甲 乙
2。部门分 全国 上海 北京 广州。。。。（还可以扩展啊，部门是树状，权限从根节点向上继承）
3。角色分： 主管 经理 总经理 副总经理
下面给你对应设置列表，你先看看
用户名 部门 角色
A 北京 主管
B 上海 主管
C 广州 主管
甲 北京 总经理
甲 上海 总经理
乙 广州 总经理
丙 全国 总经理
丁 全国 副总经理
你有1 2 3 5 这四种产品列四个流程，我管他叫文种
针对不同文种再设定流程就可以，从哪个点到哪个点，对应的是部门还是角色还是用户
a－b b－a正反向都可以这样就行了
不知道你是否明白，不明白留msn或者qq
用户A（北京主管） 用户B （上海主管） 用户C（广州主管）
A负责产品1和2 B负责产品2和3 C负责产品2和5
A的上级甲 B的上级也是甲 C上级乙
甲为北方区域（北京和上海）总经理
乙为南方区域（广州）总经理
丁为全国副总经理 负责产品3的销售
甲和乙的上级为丙（全国总经理）
A、B、C提交的销售报告都要提交给自己的上级审批
甲、乙审批完如果通过则由丙审批，如否决就返回
按照我设计的机制，
1。你有5个用户 A B C 甲 乙
2。部门分 全国 上海 北京 广州。。。。（还可以扩展啊，部门是树状，权限从根节点向上继承）
3。角色分： 主管 经理 总经理 副总经理
下面给你对应设置列表，你先看看
用户名 部门 角色
A 北京 主管
B 上海 主管
C 广州 主管
甲 北京 总经理
甲 上海 总经理
乙 广州 总经理
丙 全国 总经理
丁 全国 副总经理
你有1 2 3 5 这四种产品列四个流程，我管他叫文种
针对不同文种再设定流程就可以，从哪个点到哪个点，对应的是部门还是角色还是用户
a－b b－a正反向都可以这样就行了
不知道你是否明白，不明白留msn或者qq
aafshzj 2006-10-26
- 打赏
- 举报
“明年我可能会开始开发一个开源的高性能电子商务系统，里面有可能会使用我的工作流引擎（工作流不开源，呵呵）。大流量的在线商务系统使用真正的工作流引擎应该是蛮恐怖的。
这个问题现在还在考虑，目前想休息休息，今年太累了。”
=========================================================
“1、权限结构——别小看这一问题，如果像楼上某位说到的电子商务用的工作流，那其实在权限模型设计方面的要求相对要低一些”
这句是说我吧，呵呵，从哪里看出来我有你说的这个意思的啊？
呵呵，上面是我的原话。我根本没有提到我的权限管理模型和新的构想有什么关系。
明确地说，我的权限管理模型根本不是针对电子商务的，无论是OA、企业应用、内部大批量机密文档精细管理还是电子商务，无论是工作流还是普通应用，都轻松应对，而且性能极好。它的一个简化概念的退化版本早在几年前就在一个出名苛刻的电子政务制高点成功应用。
我说的是想把工作流彻底延伸到在线电子商务领域罢了。在线电子商务领域的工作流，单纯流程本身并不复杂，但是具体的处理方式和操作习惯上、对性能、数据吞吐能力以及查询分析能力的要求，确实与传统工作流应用迥然不同，我要把它和传统工作流模型放在一起进一步抽象得到一个更具价值的模型。而且这次我考虑的工作流比普通的工作流概念要大。多的不能再说了。有空再交流吧。
单单是工作流本身，就算是不延伸到在线电子商务领域，在其结构和特性上也能有霄壤之别。
这个问题现在还在考虑，目前想休息休息，今年太累了。”
=========================================================
“1、权限结构——别小看这一问题，如果像楼上某位说到的电子商务用的工作流，那其实在权限模型设计方面的要求相对要低一些”
这句是说我吧，呵呵，从哪里看出来我有你说的这个意思的啊？
呵呵，上面是我的原话。我根本没有提到我的权限管理模型和新的构想有什么关系。
明确地说，我的权限管理模型根本不是针对电子商务的，无论是OA、企业应用、内部大批量机密文档精细管理还是电子商务，无论是工作流还是普通应用，都轻松应对，而且性能极好。它的一个简化概念的退化版本早在几年前就在一个出名苛刻的电子政务制高点成功应用。
我说的是想把工作流彻底延伸到在线电子商务领域罢了。在线电子商务领域的工作流，单纯流程本身并不复杂，但是具体的处理方式和操作习惯上、对性能、数据吞吐能力以及查询分析能力的要求，确实与传统工作流应用迥然不同，我要把它和传统工作流模型放在一起进一步抽象得到一个更具价值的模型。而且这次我考虑的工作流比普通的工作流概念要大。多的不能再说了。有空再交流吧。
单单是工作流本身，就算是不延伸到在线电子商务领域，在其结构和特性上也能有霄壤之别。
噯卟釋手 2006-10-26
- 打赏
- 举报
zhongwanli(㊣【为了老婆，二次重构____然后升★★】㊣) ( ) 信誉：30 Blog 2006-10-26 12:27:00 得分: 0
审批的过程可以自定义，这个非常重要。
-----------------------------------------------------------
我也正有此意
因为本来就是一个不大不小的程序
又不要求太标准
只要能满足我的需求就可以了撒
审批的过程可以自定义，这个非常重要。
-----------------------------------------------------------
我也正有此意
因为本来就是一个不大不小的程序
又不要求太标准
只要能满足我的需求就可以了撒
zhongwanli 2006-10-26
- 打赏
- 举报
审批的过程可以自定义，这个非常重要。
wrenny 2006-10-26
- 打赏
- 举报
sworkflow
喝醉的咖啡 2006-10-26
- 打赏
- 举报
>权限还好，基本上都差不多，越灵活配置越麻烦。
>审批流程做灵活的话，你就牛了。看看现在那些专业做工作流的，可能有启发
可以参考专业的工作流系统，但大概如此。
2004年我自己设计了一套轻量级的工作流系统（定位很明确），不走专业和标准路线，就是为了解决 OA 中的流程定义问题。
相关还有几个方面的问题值得注意：
1、权限结构——别小看这一问题，如果像楼上某位说到的电子商务用的工作流，那其实在权限模型设计方面的要求相对要低一些。2001-2002年我们开发的专业门户网站级别 CMS 系统，因为为了满足国家要求的三审以及各个客户自己的特殊需要，在工作流方面折腾了很久，浪费了很多精力。后来负责过两个 OA 产品的研发（不是从头来，是在已有产品基础上），更发现这里面的问题没有那么简单——尤其是用于 OA，用于较大的企业和政府机关。
2、流程定义的灵活的限度以及使用难度、配置/维护和管理的工作量 之间的关系。专业工作流系统用于工业等比较适合，毕竟流程更加规范。而在企业以及非生产领域，往往日常的工作本身就比较随意，而客户的业务模型往往不是很成熟，变化非常频繁——不见的大，那么维护工作量是非常头疼的事情，要把握好度：不能过于灵活，也不能不灵活——要不就是累死客户，要不就是累死自己
3、表单——提到工作流，不考虑表单那就是白搭：工作流程中的数据是由表单来承载的，要能够设计并实现一套灵活的自定义表单机制——不一定完全是由客户来定制，至少方便我们的售后甚至开发工程师定制即可。不重视表单并从架构模型上把表单与工作流分开，结果就是工作流可以灵活定义，却不得不受限于表单系统。
4、适度：对于你的需求而言，如果不涉及到太频繁的调整，未必需要可定制的流程，未必涉及到工作流系统。比如，由使用者自己选择流程，由习惯、业务规则和制度，并配合优秀的用户教育、培训来保证系统在实际应用中的效果即可，未必需要把系统架构搞得过于复杂。
呵呵，我从事架构设计，一向是大脑走在手前面，所以很多东西设计出来一直没好好实现过。
最近可能时机比较成熟了（以前培养的几个团队里的人都慢慢成熟起来了），正计划和朋友们一起把在 过程管理/改进 + 任务跟踪/项目管理 + 源代码管理/文档管理 + 轻量级工作流（已经实际使用过，并可以按照原计划进一步改进） + 自定义表单系统（我构思了一个非常不错的架构，只是还没有证实过） + 多年来各种产品和项目中做得比较多的 权限系统（如果想在这方面深入，不妨好好借鉴一下 Exchange 2003，最能启发你的思路，与我们平时所说的各种很不错的案例相比，绝对不是一个层次），开发一套 中小企业，尤其是 IT 企业都能使用的 过程管理 + 知识管理 系统。
侧重于三个方面：
1. 过程的跟踪和管理，并提供良好的架构可以加入适应不同业务的模块，比如项目管理模块、xx业务的分析和接口模块等等
2. 过程知识以及结果知识的管理，今后可考虑加上模块以符合国家档案管理方面的要求
3. 方便的表单定制系统——并方便今后与 SmartDocument 相结合，至少能够根据业务需要定制
另外需要在架构设计时，为第三方报表系统、商业智能和数据挖掘系统留下衔接余地。
从而实现：企业和机关可以将之用于普通的任务管理和跟踪，知识管理，并可以在较低投入的情况下适应大多数业务。而更多的业务更建议在其专业的系统内完成，本系统主要在架构提供与其它业务系统接口的便利而已。
就看今年能不能完成预期目标，把钱存够，明年工作轻松一些才好做。
当然，最后项目的成功与否不在于动机和想象，但即便失败了，重点仍然是带人，朋友们水平越高，我才有机会往上拔得更高（尤其做设计，不可能把时间都花在实现自己的设计上） :)
>审批流程做灵活的话，你就牛了。看看现在那些专业做工作流的，可能有启发
可以参考专业的工作流系统，但大概如此。
2004年我自己设计了一套轻量级的工作流系统（定位很明确），不走专业和标准路线，就是为了解决 OA 中的流程定义问题。
相关还有几个方面的问题值得注意：
1、权限结构——别小看这一问题，如果像楼上某位说到的电子商务用的工作流，那其实在权限模型设计方面的要求相对要低一些。2001-2002年我们开发的专业门户网站级别 CMS 系统，因为为了满足国家要求的三审以及各个客户自己的特殊需要，在工作流方面折腾了很久，浪费了很多精力。后来负责过两个 OA 产品的研发（不是从头来，是在已有产品基础上），更发现这里面的问题没有那么简单——尤其是用于 OA，用于较大的企业和政府机关。
2、流程定义的灵活的限度以及使用难度、配置/维护和管理的工作量 之间的关系。专业工作流系统用于工业等比较适合，毕竟流程更加规范。而在企业以及非生产领域，往往日常的工作本身就比较随意，而客户的业务模型往往不是很成熟，变化非常频繁——不见的大，那么维护工作量是非常头疼的事情，要把握好度：不能过于灵活，也不能不灵活——要不就是累死客户，要不就是累死自己
3、表单——提到工作流，不考虑表单那就是白搭：工作流程中的数据是由表单来承载的，要能够设计并实现一套灵活的自定义表单机制——不一定完全是由客户来定制，至少方便我们的售后甚至开发工程师定制即可。不重视表单并从架构模型上把表单与工作流分开，结果就是工作流可以灵活定义，却不得不受限于表单系统。
4、适度：对于你的需求而言，如果不涉及到太频繁的调整，未必需要可定制的流程，未必涉及到工作流系统。比如，由使用者自己选择流程，由习惯、业务规则和制度，并配合优秀的用户教育、培训来保证系统在实际应用中的效果即可，未必需要把系统架构搞得过于复杂。
呵呵，我从事架构设计，一向是大脑走在手前面，所以很多东西设计出来一直没好好实现过。
最近可能时机比较成熟了（以前培养的几个团队里的人都慢慢成熟起来了），正计划和朋友们一起把在 过程管理/改进 + 任务跟踪/项目管理 + 源代码管理/文档管理 + 轻量级工作流（已经实际使用过，并可以按照原计划进一步改进） + 自定义表单系统（我构思了一个非常不错的架构，只是还没有证实过） + 多年来各种产品和项目中做得比较多的 权限系统（如果想在这方面深入，不妨好好借鉴一下 Exchange 2003，最能启发你的思路，与我们平时所说的各种很不错的案例相比，绝对不是一个层次），开发一套 中小企业，尤其是 IT 企业都能使用的 过程管理 + 知识管理 系统。
侧重于三个方面：
1. 过程的跟踪和管理，并提供良好的架构可以加入适应不同业务的模块，比如项目管理模块、xx业务的分析和接口模块等等
2. 过程知识以及结果知识的管理，今后可考虑加上模块以符合国家档案管理方面的要求
3. 方便的表单定制系统——并方便今后与 SmartDocument 相结合，至少能够根据业务需要定制
另外需要在架构设计时，为第三方报表系统、商业智能和数据挖掘系统留下衔接余地。
从而实现：企业和机关可以将之用于普通的任务管理和跟踪，知识管理，并可以在较低投入的情况下适应大多数业务。而更多的业务更建议在其专业的系统内完成，本系统主要在架构提供与其它业务系统接口的便利而已。
就看今年能不能完成预期目标，把钱存够，明年工作轻松一些才好做。
当然，最后项目的成功与否不在于动机和想象，但即便失败了，重点仍然是带人，朋友们水平越高，我才有机会往上拔得更高（尤其做设计，不可能把时间都花在实现自己的设计上） :)
噯卟釋手 2006-10-26
- 打赏
- 举报
我晕啊
连续回复不能超过3次？
日
正想还写点撒子呢
连续回复不能超过3次？
日
正想还写点撒子呢
噯卟釋手 2006-10-26
- 打赏
- 举报
这个问题我们细细研究
嘿嘿
嘿嘿
噯卟釋手 2006-10-26
- 打赏
- 举报
马上去
marrytone 2006-10-26
- 打赏
- 举报
兄弟有空帮我看看这个问题吧，哈哈
http://community.csdn.net/Expert/topic/5110/5110280.xml?temp=.4071772
http://community.csdn.net/Expert/topic/5110/5110280.xml?temp=.4071772
marrytone 2006-10-26
- 打赏
- 举报
握手握手，我一直在做类似的东东，在流转过程中
正因为你定义了部门，角色和用户，那么你应该在流转对象上也提供灵活定制，打个比方
从办件－－审核，你可以定制为流转到角色或者流转到部门或者流转到某个人，
可以弹出具体用户选择框来让用户选择某个部门或者某个角色的具体用户。
选择了步骤和流转方向外，流转对象也是个集合啊，你可以流转给集合，也可以到具体的人
灵活了以后，你可以建立多个文种根据开始办件的时候的地区和产品权限让他进入不同的文种就可以了
名词解释：文种，就是一个文件的流程。
正因为你定义了部门，角色和用户，那么你应该在流转对象上也提供灵活定制，打个比方
从办件－－审核，你可以定制为流转到角色或者流转到部门或者流转到某个人，
可以弹出具体用户选择框来让用户选择某个部门或者某个角色的具体用户。
选择了步骤和流转方向外，流转对象也是个集合啊，你可以流转给集合，也可以到具体的人
灵活了以后，你可以建立多个文种根据开始办件的时候的地区和产品权限让他进入不同的文种就可以了
名词解释：文种，就是一个文件的流程。
噯卟釋手 2006-10-26
- 打赏
- 举报
有点抠脑壳啊~！~
噯卟釋手 2006-10-26
- 打赏
- 举报
楼上兄弟 握个手先
其实我在权限控制上跟你的方法基本上相同的
我做的这个东东
根据不同的菜单权限基本上就可以确定用户能不能做什么事
但是审批的时候就有点麻烦撒
不同的单据由不同的人来审批
关键是单据是由人提交的
单据里包含地区、产品
而提交单据的这个人的地区权限、产品权限由决定了审批流程的不同
我觉得有点麻烦
你做过类似的东东没有嘛
这也不是什么标准的OA
仅仅是我个人搞的一个小程序而已
其实我在权限控制上跟你的方法基本上相同的
我做的这个东东
根据不同的菜单权限基本上就可以确定用户能不能做什么事
但是审批的时候就有点麻烦撒
不同的单据由不同的人来审批
关键是单据是由人提交的
单据里包含地区、产品
而提交单据的这个人的地区权限、产品权限由决定了审批流程的不同
我觉得有点麻烦
你做过类似的东东没有嘛
这也不是什么标准的OA
仅仅是我个人搞的一个小程序而已
marrytone 2006-10-26
- 打赏
- 举报
审批流程一般来说包括：办件（收件）－－初审－－复审－－审批－－归档
这已经是比较完整的流程了，大部分都不会超出这几个步骤，既然要灵活么，其实走几步到无所谓了，关键是你点和线的连接，流程要实现灵活定制的话，到时候正向反响都无所谓
跳步也是一样，关键是你的设计
这已经是比较完整的流程了，大部分都不会超出这几个步骤，既然要灵活么，其实走几步到无所谓了，关键是你点和线的连接，流程要实现灵活定制的话，到时候正向反响都无所谓
跳步也是一样，关键是你的设计
marrytone 2006-10-26
- 打赏
- 举报
灵活的没问题，我现在搞的就是，大部分oa系统都是灵活定制工作流程
除了角色，用户以外，再建立一个部门概念，这样人员的管理齐备了,给你大致列列
具体的可以再探讨
1 部门。2 角色 3 用户 4 文种定义 5 工作步骤定义 6 工作流向定义 7 权限定义
8 菜单定义
这些我大概用了20来张表来管理，部门，角色，用户都可以设置权限，一个用户可以属于某个部门的某个角色，权限可以继承；工作步骤就好像是点，工作流就好像是线，线把点穿起来组成一个文种；权限附加再工作步骤上，菜单可以对应权限，没有权限的就不能访问这个菜单
简单的说就是这些。
除了角色，用户以外，再建立一个部门概念，这样人员的管理齐备了,给你大致列列
具体的可以再探讨
1 部门。2 角色 3 用户 4 文种定义 5 工作步骤定义 6 工作流向定义 7 权限定义
8 菜单定义
这些我大概用了20来张表来管理，部门，角色，用户都可以设置权限，一个用户可以属于某个部门的某个角色，权限可以继承；工作步骤就好像是点，工作流就好像是线，线把点穿起来组成一个文种；权限附加再工作步骤上，菜单可以对应权限，没有权限的就不能访问这个菜单
简单的说就是这些。
噯卟釋手 2006-10-26
- 打赏
- 举报
权限都还比较好弄
94审批流程控制我到现在都木有一个比较成熟的构思撒
唉~
94审批流程控制我到现在都木有一个比较成熟的构思撒
唉~
噯卟釋手 2006-10-26
- 打赏
- 举报
各位大哥啊
能不能给点实际又具体的案例来看看撒
能不能给点实际又具体的案例来看看撒
test33 2006-10-26
- 打赏
- 举报
帮顶了
leaohong 2006-10-26
- 打赏
- 举报
aafshzj(上海北京) ( ) 信誉：100 Blog 2006-10-25 17:30:00 得分: 0
灵活不一定配置麻烦。同样的功能需求，灵活的往往配置更简单。只不过对于那些不灵活没法做的，灵活的有办法做到，未必很简单，但没有可比性。
————
这个灵活相信是模块化与可扩展，对于机构复杂多变的用户这样的系统应该更方便。
但如果使用者一味将所有工作不管有无必要都强行加入工作流中，相信用户的反应恐怕不仅仅是麻烦而已。
灵活不一定配置麻烦。同样的功能需求，灵活的往往配置更简单。只不过对于那些不灵活没法做的，灵活的有办法做到，未必很简单，但没有可比性。
————
这个灵活相信是模块化与可扩展，对于机构复杂多变的用户这样的系统应该更方便。
但如果使用者一味将所有工作不管有无必要都强行加入工作流中，相信用户的反应恐怕不仅仅是麻烦而已。
加载更多回复（67）
