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

ccwlm741212

原帖由 olive 于 2010-7-16 16:02 发表

用户确实意识到了信息孤岛的问题，因为这就是当前他们面对的问题。
但是他们的想法就是，做一个大的数据库，谁都把数据放进去，谁都可以拿出来用拿出来看，他们觉得这样就达到共享的目的了！

你搞清楚用户究竟是需要ERP还是BI没有？

如果是ERP肯定是流程当先，数据跟着流程走。。。。

如果是BI的话，建立数据中心，需要就拿出来分析分析，统计统计，这个就是数据优先了。。。。

zelef

不懂ERP得人路过~

123crm

原帖由 zelef 于 2010-7-16 23:29 发表
不懂ERP得人路过~

楼主这些问题实际跟ERP没关系。呵呵

liugmwx

一些老人都出来了
讨论得很深了

我觉得收集业务部门需求，然后讨论整体方案要从全局考虑，但务业务部门人员只会站在自己角度考虑没有全局意识，这个要和boss谈

olive

我看了前面几位高人的讨论，我来进一步说明一下我们公司当前的情况：
首先，说的都是内部用户，是各个业务部门。目前还没有涉及到外部第三方的实施。
例如，销售部接了订单回来，合同部要出报价，然后生产部要制定生产计划，安排生产，最后财务部要收钱。这些环节应该是在一个大的流程中运转，但是当前的问题是，各个业务部门的工作流程和期间发生的数据，存在于各自的系统中，互相不透明，要靠电话，人手查询，才能拿到其他部门的数据，而且其中某些环节还是靠纸笔，结果，老板想知道我们接了个单子最后赚了多少钱，都是很困难的一个事，需要有人到各个部门去查数据，再按计算器，才能算出来一个大概的数。
所以改进的目标就是想做系统整合，把流程打通，数据打通，形成一个流转于各相关部门之间的大流程。同时，把纸笔摒弃掉。
所以我认为第一步显然是要做业务流程的分析，把各个部门当前各自为政的流程提取出来，整理，归纳，整合，形成一个大的互通的流程，然后在这个流程上考虑数据和数据流，然后才能建立概念模型，数据模型，才能知道需要什么数据，怎么存放。
但是用户认为只要把数据有用没用的统统放进一个大数据库，谁都可以去看去用，就行了！这显然是不正确的想法。试想，连流程都不清晰，怎么定义数据？前面有人说，先把想到的数据放起来，然后有需要了再改，我不认同这种做法。谁都知道，在应用程序已经建立的情况下，改动数据结构是多么困难的一件事情！这也不是关系型数据库的初衷吧？
目前离数据库设计还差得远呢。
之所以要改动流程，是因为当前的流程不合理，或者说，当前没有一个可以通行于各个部门的流程，每个部门各自为政，他们做的事情可能是重复的，甚至是矛盾的，例如同一组数据，很可能各个部门重复以不同的形式在录入各自的系统。何况当前的流程中，还有一些步骤是靠纸笔的。这样的流程，不改怎么可能上系统呢？

olive

我现在的理解是，要先有ERP，然后才能谈BI。我们现在要做的事情，实际上应该是个BPR。

olive

原帖由 fals 于 2010-7-16 19:17 发表


为什么要把数据和流程对立起来？这两个东西本来就是统一的，是一个问题的两个方面

提几个问题就明白了：

1  原始数据（不是统计数据）是从哪里来的？是怎么产生的？
数据一定是从业务中产生的，一定是业务本身就具备的属性

2  哪些数据先产生？哪些数据后产生？
一定是先发生业务的数据先产生，后发生业务的数据后产生

3  不同的数据与数据之间的相互关系由谁来定义？
一定是业务流程和业务关系来定义的！！

使用部门是希望基础数据全采集，后期才能提取使用，这个要求是完全合理的，我们不能预见今后会使用哪些数据，因此在业务发生的当时把业务属性数据全部采集到数据库中，实际上是完全可行的。

我理解业务部门疑惑的问题是：每一个业务对象的需要定义哪些属性？比如一个个人基本信息中，除了姓名性别外，是不是需要记录他的手机号、家庭电话号码、办公室电话号码、家庭住址、紧急联系人、紧急联系人电话、与紧急联系人的关系……这些数据才是需要与业务部门讨论的。业务部门希望这些数据尽量的全，但实际上是不可能的，因为二十年以前不会有人想到要记录手机号，到今天就非常需要了；今天的大多数系统记录个人信息时也不记录他们的email地址，但很快就会发现这是需要的，以后可能还会要求记录QQ号什么的，这些东西是我们没法预测的，但是这东西随时可以通过修改数据库结构在需要的时候增加。关系型数据库设计来就是让人能够根据业务的扩展而不断地增加新的信息的，所以这个疑虑完全可以让业务部门打消掉。在系统早期设计的时候，完全可以不考虑得那么全，在需要的时候再增加就行了。

楼主数据库原理学得不好啊！！！丢人噢

我同意你前三点。但是这和数据库原理没关系吧。关系型数据库是用来在后期随便改数据结构的吗？那还要建模干什么呢？应用已经建立的条件下，修改数据结构似乎是非常痛苦的事情吧？
你一方面说“在业务发生的当时把业务属性数据全部采集到数据库中，实际上是完全可行的”，另一方面又说“业务部门希望这些数据尽量的全，但实际上是不可能的”。我认同后者。

olive

原帖由 fals 于 2010-7-16 19:27 发表


很不理解做信息系统为什么一定需要改动流程？？你就按他们现有的业务流程，把手工的业务搬到信息系统里就不行了吗？这是最简单的办法，为什么一定要用户改动流程？

改动业务流程一定是因为数据的原因：以前手工操作的时候为了某些原因方便之类的，增加了一些业务环节，现在信息系统上起来了，这些环节可以不要了——我在医院上系统第一件事就是取消住院结算中心，只需要出入院处了，因为系统能够自动结算了；同样因为以前的业务为了某些数据采集比较繁琐就省略掉了，现在上信息系统了，以前繁琐的业务现在变成了必须的，比如医院挂号的问题，以前不挂号也可以看病，现在不挂号的话，医生连病人都找不着，所以变成必须的了。这种改动一定不会是基础业务的改动，信息系统必须让基础业务、核心业务更方便，效率更高，这是不用讨论的，信息系统的价值就在这里，如果一个系统上起来让人家的基础业务核心业务都变得不方便了，那上这个系统干嘛？管理也是为基础业务和核心业务服务的，管理的目标是让核心业务效率更高、资源配置更合理，而不是单纯的为了领导的某些统计数据！！这个一定不能本末倒置！！！

有点理解为什么楼主和业务部门有这么大的分歧了，楼主应该抛开数据啦、业务流程啦这些表象的东西，从核心上去理解你要服务的部门发生的业务价值在哪里！要从根上去找，找着了这个东西，你提出来的方法自然能让用户接受了。

我的目的的确是要去理解各个部门的业务的核心价值。但是接下来要做的，就是流程的整合优化，其中必然涉及到改动。如果业务流程已经最优，不需要改动，那我也不需要做任何事情了。

olive

原帖由 fals 于 2010-7-16 19:31 发表
前面的兄弟们的回复，我觉得没有一个人抓住了楼主问题的核心！

可能你的理解有偏颇。我需要做流程的优化。

olive

原帖由 cowherd 于 2010-7-16 20:04 发表
很奇怪，没有ERP的正确数据，楼主如何做BI呢！难道不是先把erp弄好，再来谈BI？
即便你需要先考虑到BI，顶多也是在erp过程中，考虑一下接着上BI的需求吧！

是我对ERP和BI的概念理解的不好。我第一步要做的实际上是BPR，在此基础上上一个ERP，然后才能谈BI。