在ERP或者BI的设计阶段，业务流程和业务数据，哪个重要？哪个应当首先确定？

近九成网友

原帖由 ccwlm741212 于 2010-7-17 11:54 发表


如果一开始就是全员工程，那是理想。。。ERP没有一把手来推动，你实施看看呢。。。问一下，你做过实施吗？

ERP做了十年了。从甲方做到乙方，从实施做到销售。我觉得ERP是一把手工程在打单的时候作用最大，毕竟上不上项目大老板说了算，但是要是把这句话放到实施中，只能说对了一半。原因就是我前面说的三点。

我没说不需要一把手推动，一把手推动也有很多讲究，什么时候推动，怎么样推动都要在实施经理的掌控中，如果在不合适的时候推动，业务部门可能会觉得我们做的好好的，老板怎么还说我们工作不力呢？本来张三的事情，老板推动到李四面前，这样的推动，结果可想而知。这样既对一把手的权威产生了负面影响，又打击了基层人员的积极性，最终实施方在那边都反馈回来的都是抱怨。

而且一把手工程把实施方引入一个只要搞定一把手就会搞定项目的误区。殊不知项目成功一开始就是由全员决定的。就如红楼梦中王熙凤虽然能干，但她只是哄好太太和老太太，对下人态度恶劣，到最后家破人亡孤家寡人一个。最要命的是实施这样做了，后续的销售再去谈什么别的项目，业务基层是不会再配合的，因为大家觉得你就是王熙凤的角色。

呵呵，到了一大堆苦水，其实做ERP和做其他的很相似，我的想法是这样，并不代表大家没有别的更好的办法，我只是抛砖引玉而已。

123crm

原帖由 近九成网友 于 2010-7-17 13:49 发表



ERP做了十年了。从甲方做到乙方，从实施做到销售。我觉得ERP是一把手工程在打单的时候作用最大，毕竟上不上项目大老板说了算，但是要是把这句话放到实施中，只能说对了一半。原因就是我前面说的三点。

我没说不需要一把手推动，一把手推动也有很多讲究，什么时候推动，怎么样推动都要在实施经理的掌控中，如果在不合适的时候推动，业务部门可能会觉得我们做的好好的，老板怎么还说我们工作不力呢？本来张三的事情，老板推动到李四面前，这样的推动，结果可想而知。这样既对一把手的权威产生了负面影响，又打击了基层人员的积极性，最终实施方在那边都反馈回来的都是抱怨。

而且一把手工程把实施方引入一个只要搞定一把手就会搞定项目的误区。殊不知项目成功一开始就是由全员决定的。就如红楼梦中王熙凤虽然能干，但她只是哄好太太和老太太，对下人态度恶劣，到最后家破人亡孤家寡人一个。最要命的是实施这样做了，后续的销售再去谈什么别的项目，业务基层是不会再配合的，因为大家觉得你就是王熙凤的角色。

呵呵，到了一大堆苦水，其实做ERP和做其他的很相似，我的想法是这样，并不代表大家没有别的更好的办法，我只是抛砖引玉而已。

是的啊。一把手能定一些大的方向。企业的利润和销售额全部是前端的业务部门产生的。在推动ERP或者其他的信息化建设的同时，他也必须要考虑到自己的财务报表和向股东交代的问题。如果过分推动，打击前端业务人员，甚至将整个考核指标和岗位职责都变了。是有风险的。。甚至导致人员流失。

IT不是用来变革，IT是用来做支撑的。 因为需要变革，才需要IT的手段。。 业务变革（包括流程和业务模式）的变革才是关键。。。

当然如果仅仅是企业内部的运营的一些管理变动（如财务,HR等），也许会好很多，但是涉及到前端部门那就没那么容易了。

olive

原帖由 cowherd 于 2010-7-17 11:52 发表
呵呵，同一一件事个人和部门利益的最大化和公司利益的最大化并不见得是完全同步一致的，
所以如何调整利益分配还得老板综合评估说了算。

有些事情对部门和个人直接说业务核心价值，核心利益用处不是很大；还是得要老板直接向部门
领导说白了：无论ERP也好，BPR也好，首先还是公司和老板的利益需要最大化，在此基础上才能
最求部门利益最大化，其实基本上是部门领导利益最大化，最后才到个人的利益最大化。

完全同意。公司利益的最大化往往触及到部门的利益，甚至要部门牺牲当前的利益。这就是BPR难以推行的原因。

olive

原帖由 ccwlm741212 于 2010-7-17 11:54 发表


如果一开始就是全员工程，那是理想。。。ERP没有一把手来推动，你实施看看呢。。。问一下，你做过实施吗？

反正我们公司远远没有达到全员工程的程度。真要到那个程度的话，我就没有什么可烦恼的了。

olive

原帖由 近九成网友 于 2010-7-17 13:49 发表



ERP做了十年了。从甲方做到乙方，从实施做到销售。我觉得ERP是一把手工程在打单的时候作用最大，毕竟上不上项目大老板说了算，但是要是把这句话放到实施中，只能说对了一半。原因就是我前面说的三点。

我没说不需要一把手推动，一把手推动也有很多讲究，什么时候推动，怎么样推动都要在实施经理的掌控中，如果在不合适的时候推动，业务部门可能会觉得我们做的好好的，老板怎么还说我们工作不力呢？本来张三的事情，老板推动到李四面前，这样的推动，结果可想而知。这样既对一把手的权威产生了负面影响，又打击了基层人员的积极性，最终实施方在那边都反馈回来的都是抱怨。

而且一把手工程把实施方引入一个只要搞定一把手就会搞定项目的误区。殊不知项目成功一开始就是由全员决定的。就如红楼梦中王熙凤虽然能干，但她只是哄好太太和老太太，对下人态度恶劣，到最后家破人亡孤家寡人一个。最要命的是实施这样做了，后续的销售再去谈什么别的项目，业务基层是不会再配合的，因为大家觉得你就是王熙凤的角色。

呵呵，到了一大堆苦水，其实做ERP和做其他的很相似，我的想法是这样，并不代表大家没有别的更好的办法，我只是抛砖引玉而已。

每个业务部门都会觉得自己做的好好的。谁会说“我们部门做得不好”呢？扯皮的时候，肯定是指责别的部门做得不好啊！所以一定要有个人在部门以上的高度来协调指挥。我觉得是这样。

wangyuweng

原帖由 近九成网友 于 2010-7-17 10:41 发表



呵呵，我一直不认为erp是一把手工程，把它说成是全员工程更贴切。

首先一把手只能决定大方向，而具体细节都是基层人员在把握，所谓细节决定成败，所以基层的参与积极性也是非常重要的。

其次一把手并不能全程参与erp，如果在实施erp前对基层人员的思想灌输不到位的话，项目拖期或者说不成功的可能性更大。

最后如果erp是一把手工程，那么项目的成功与失败都是一把手的责任，基层脱离干系也是不妥的，至少要让基层知道成功是源于他们的努力，失败开始于他们失职。职责明确才是项目成功的重要保证。

当然以上只是从内部而言的。从实施单位而言，系统的稳定性和可靠性也是重要保障

呵呵，没有高层的大力支持和中层的全程参与，基层的执行力是要大打折扣的，单是抱怨都把人给整得半死。

fals

认真的再读了一下，了解了楼主的困境了，至少我觉得是了解了。

先确认一下几个基本情况：

1  在整个公司的大流程中，某些部门或者大多数部门都有了服务于自己局部业务的信息系统，比如合同处理系统、财务管理系统、员工工作安排系统之类的，但这些信息都只是在各部门内部流通，部门与部门之间没有信息流通。

2  部门与部门之间存在重复的数据，但这些业务意义上重复的数据，在各自的系统中可能存在不同的编码方式、数据组织和表现形式。

3  各部门之间有强烈的信息交换需求，或者大老板强烈需要各部门及其系统之间交换数据，保证数据的一致性

4  老板从全局出发，需要一个系统，把各部门的业务流程及信息全部串起来，并且能够从这个大系统中掌握跨部门决策所需的信息或者统计报表。

这些基本情况确实不？

fals

如果实际情况真如上贴所说，楼主确实面临着极大的困难，建议找专业的咨询公司先拿出一个可行的解决方案来。

我的理解，至少需要解决以下几个问题：

1  各部门之间在业务意义上相同的数据，在数据库中存在着不同的编码方式、组织方式，计算机难以自动判断这些数据的业务意义是否相同。也就是说，必须解决各系统之间元数据定义的标准化问题，否则各部门的系统之间数据交换是一场空谈。这个任务极其艰巨！！

2  各部门之间的实际业务衔接是流畅的，但在全局的环境中信息流转中不畅通，而且在整个大的流程中某些环节还是手工处理。因此楼主必须解决新的大系统与各部门原有业务系统的衔接问题，可以是全部替换——这个相信阻力会很大，特别是对于那些信息系统已经应用得比较好的部门；或者是做一个新系统，与各部门原有系统通过数据接口的方式进行数据交换和衔接——这样的话，大系统会做得非常复杂

3  对于现有个别业务环节还是手工的情况，只能在新系统中解决，这个相反是最好解决的。

因此，一个可行的做法是：建立一个全新的大系统，这个大系统跑全局的业务流程，主要解决部门与部门之间的业务衔接问题，涉及到各部门内部流程的，仍然使用各部门自有的系统来处理。大系统监控各部门的业务系统中新产生的需要下一业务部门处理的数据，如A部门接了一个订单，需要B部门评估成本，那么大系统监测到A部门新增加了订单时，就将订单的相关数据转换成B部门的信息系统能够处理的数据写入B部门的系统中。对于全局性的统计需求，可以将需要的数据——或者业务部门所说的“全部”数据统一转换为标准数据之后提取到大系统的数据中心来，再按大老板的统计要求进行二次加工。

这个方案的关键在于两点：数据标准和系统接口。优势在于对业务部门目前使用的系统尽可能少改或者不改，对各部门内部业务基本无干扰，即使是调整流程也仅仅是局部的调整，不会涉及各部门的利益。至于各部门都需要使用的共同数据，也可以全面性的清理一下，由大系统从首次产生这些信息的部门系统里定期提取，再转换后写入各部门的系统中。

这样，大系统主要由几部分构成：数据中心，接口系统，标准数据字典及其转换关系对照表，统计报表，管理系统

我想这样应该能解决楼主的困惑了吧？用不着去纠缠流程优先还是数据优先，工作先做起来再说，别去纠缠这些概念

[ 本帖最后由 fals 于 2010-7-17 21:21 编辑 ]

olive

原帖由 fals 于 2010-7-17 21:03 发表
认真的再读了一下，了解了楼主的困境了，至少我觉得是了解了。

先确认一下几个基本情况：

1  在整个公司的大流程中，某些部门或者大多数部门都有了服务于自己局部业务的信息系统，比如合同处理系统、财务管理系统、员工工作安排系统之类的，但这些信息都只是在各部门内部流通，部门与部门之间没有信息流通。

2  部门与部门之间存在重复的数据，但这些业务意义上重复的数据，在各自的系统中可能存在不同的编码方式、数据组织和表现形式。

3  各部门之间有强烈的信息交换需求，或者大老板强烈需要各部门及其系统之间交换数据，保证数据的一致性

4  老板从全局出发，需要一个系统，把各部门的业务流程及信息全部串起来，并且能够从这个大系统中掌握跨部门决策所需的信息或者统计报表。

这些基本情况确实不？

总结得很正确。

olive

原帖由 fals 于 2010-7-17 21:18 发表
如果实际情况真如上贴所说，楼主确实面临着极大的困难，建议找专业的咨询公司先拿出一个可行的解决方案来。

我的理解，至少需要解决以下几个问题：

1  各部门之间在业务意义上相同的数据，在数据库中存在着不同的编码方式、组织方式，计算机难以自动判断这些数据的业务意义是否相同。也就是说，必须解决各系统之间元数据定义的标准化问题，否则各部门的系统之间数据交换是一场空谈。这个任务极其艰巨！！

2  各部门之间的实际业务衔接是流畅的，但在全局的环境中信息流转中不畅通，而且在整个大的流程中某些环节还是手工处理。因此楼主必须解决新的大系统与各部门原有业务系统的衔接问题，可以是全部替换——这个相信阻力会很大，特别是对于那些信息系统已经应用得比较好的部门；或者是做一个新系统，与各部门原有系统通过数据接口的方式进行数据交换和衔接——这样的话，大系统会做得非常复杂

3  对于现有个别业务环节还是手工的情况，只能在新系统中解决，这个相反是最好解决的。

因此，一个可行的做法是：建立一个全新的大系统，这个大系统跑全局的业务流程，主要解决部门与部门之间的业务衔接问题，涉及到各部门内部流程的，仍然使用各部门自有的系统来处理。大系统监控各部门的业务系统中新产生的需要下一业务部门处理的数据，如A部门接了一个订单，需要B部门评估成本，那么大系统监测到A部门新增加了订单时，就将订单的相关数据转换成B部门的信息系统能够处理的数据写入B部门的系统中。对于全局性的统计需求，可以将需要的数据——或者业务部门所说的“全部”数据统一转换为标准数据之后提取到大系统的数据中心来，再按大老板的统计要求进行二次加工。

这个方案的关键在于两点：数据标准和系统接口。优势在于对业务部门目前使用的系统尽可能少改或者不改，对各部门内部业务基本无干扰，即使是调整流程也仅仅是局部的调整，不会涉及各部门的利益。至于各部门都需要使用的共同数据，也可以全面性的清理一下，由大系统从首次产生这些信息的部门系统里定期提取，再转换后写入各部门的系统中。

这样，大系统主要由几部分构成：数据中心，接口系统，标准数据字典及其转换关系对照表，统计报表，管理系统

我想这样应该能解决楼主的困惑了吧？用不着去纠缠流程优先还是数据优先，工作先做起来再说，别去纠缠这些概念

前三点非常同意。
最后的建议，建立一个大系统，和现有的小系统衔接，有这样几个问题：
1. A系统中的数据未必能转换到B系统中，因为两个系统完全没有考虑对方的需要，数据可能完全衔接不上的。退一步说，如果可以衔接，那么直接改一下A系统，把数据自动写入B系统（即使这是个额外的步骤，对A系统本身来说是多余的），不是更方便？如果想要做到能够衔接，还是要改动各部门的小系统。
2. 用户既要操作原来的系统，又要操作新的大系统，数据和操作都要重复，用户也会怨声载道吧。