序言：创作者了解的关联性就是指有类似的內容，并不是逻辑性类似便是前面网页页面类似。能够彻底不变立即同用，还可以合拼步骤，提升目前步骤后同用。

如今的OA系统基础都是有流程引擎，建立步骤简易便捷，通常新创建步骤比改步骤快的得多。那建立步骤这般快，为什么还考虑到同用难题？

基本上各家企业都是有OA系统，而且OA朝向企业全部职工，应用頻率很高，假如好几个步骤的页面和实际操作都相差无异，会给职工导致反复的幻觉，若同用，不但简单化职工实际操作，也降低学习培训成本费和学习培训成本费。

工作人员经营规模大的企业，单位多，步骤也多，各单位间的信息内容不通畅，很有可能A有的步骤，B也是有相近的，但她们相互之间不清楚。虽然建立步骤迅速，但PM得有效整体规划商品，需立在融合者的视角给需求者一定参照提议，降低沉余单一数据信息。

系统软件使用时间越长，步骤就越大，有一些步骤设计方案简易且应用頻率很低。为了更好地网页页面美观大方和工作效率也必须持续精减、提升步骤。

举个工作上碰到的事例：

2个工作职责和岗位职责很类似的技术性单位，都做抽成全自动清算。A单位早已进行，在使用环节了，但B单位由于和A相近因此 就期待立即结合在A里。为此为例子，而言说我是怎样剖析是不是必须同用的。

更先，从表层上分辨步骤是不是能同用，是不是一样的要求，同用的一部分多否。

实例里AB单位都确立做抽成清算，虽后台管理涉及到的数据库有不一样，但前面网页页面內容90%类似，能够考虑到同用。

次之，在技术上分辨开发设计是否可以使做，技术性可否完成，估计同用和单独的开发设计难度系数及开发设计時间。若差别很大，依据投入产出率测算，看是不是非常值得资金投入不必要的项目成本来完成同用。

实例里单独比同用的時间节省一半，发布時间没强制性规定，因此 ，可单独可同用。

再度，从利与弊上剖析同用后是不是真实产生便捷，是提升/降低劳动量，提升哪些人的工作中，降低哪些人的工作中，依据应用总数及应用頻率分辨是不是必须同用。

实例里AB同用，降低了有交叉式新项目抽成工作人员的申请办理時间，但提升了审批工作人员的工作中，有交叉式新项目的工作人员比审批工作人员多，但交叉式新项目的应用頻率比审批工作人员低。

碰到这类状况，若同用，应当让受影响的彼此了解，依据彼此商议建议再明确是不是同用。

如实例里的AB单位，获益的是普通职工，但复杂化的是管理人员，虽然普通职工占比管理人员多，但管理人员的主导权高些。因此 ，这只有把利与弊告知彼此，让彼此沟通交流清晰后再做准确决策，防止发布后因彼此矛盾造成 换计划方案。

最终，最重要的需看同用是不是危害中后期延伸，是不是有别的潜在性要求（例如业务流程要求或是管理 *** 要求），许多情况下这都变成决策要素。

实例里B单位是以A单位里单独出去的，尽管B单位常常融洽做A单位工作中，但2个单位的市场拓展方位不一致，在管理 *** 上各成管理体系，中后期发展趋势免不了不一样，那人性化的要求也无可避免。

综上所述，这两个步骤沒有同用，缘故是同用的开发设计时间长了一倍，而且危害审批高效率和审批結果，中后期有人性化要求，因此 单独分离。之上是有关有关联性的步骤是不是同用的个人观点！

来源于：莫然blog，热烈欢迎共享文中！