业务流程不是需求

现有的业务流程是否需要改造，如果需要，应该改造成什么样子？这样的决策不适合由软件开发团队做出。这应该是管理专家，或者管理专家和IT专家联合组成的团队来进行。

nod, 我就是这个意思，业务流程应该是什么样，这个决定是由大家共同做出的。开发者不应该等着别人把流程整出来了，然后再登场，不能把业务流程当作IT系统的需求，需求在更深处。开发者要注意这一点，用户也要注意这一点。不能单方面的提出一个业务流程，自己认为很合理，就让开发者去做。一定要大家一起把需求谈清楚。然后各自分工，干自己该干的事情去，同时注意保持联系。

非常同意这个说法。
对于小型企业，这种业务流程和IT系统重整的过程往往可以用一个项目来完成；
但是对于大型企业，这种重整过程往往会被拆成一个大的业务规划过程和若干个具体实施项目。作为某个具体的实施项目的参与者，包括开发人员/业务分析人员/项目经理/甚至是用户代表，一般都面对的是已经规划好的业务流程和IT系统的组合，只能在局部进行细化，却不能影响到整体的商业模式。如果整体方案没有规划好发生变化，这些具体实施的项目往往就会产生更大的变化，甚至可能整个项目都被取消。

楼主所谓的商业需求，应该成为包需求。也就是由客户，市场提出的关于系统的需求。完全是用户视角的。
然后通过包需求，通过场景分析，才得到所谓业务流程和设计需求

   这个问题越说越大，根据IT系统的分析进行业务流程的优化，这个是当前企业信息化进程中较高目标。以当前国内情况来说，企业对信息化的重视程度普遍较高。很多高层领导也愿意根据信息化来优化，改革业务流程。
   但是，在具体的实施过程中，困难重重。
   首先，是利益关系问题，会遇到很大阻力。
   其次，是局部业务流程的优化，需要跟公司整体信息化的步调相一致。
   第三，是成本问题，无论是采用完整的信息解决方案，还是采用更先进的技术，都不可避免的增加成本。在当前国内，对成本相当敏感的情况下，很难有实施的可能性。

   总结一下观点：不赞成在软件需求调研，开发中，过多的专注与业务流程的优化相关的内容，那会使我们偏离目标。至于商业利益，在现有的条件下有很多的限制，技术上的，人员上的，商业上的。根据商业利益去开发软件系统，或许适应了客户长远的目标，却带来了与现有系统衔接不上，当前不好使用诸多风险。当然，理解业务流程背后的实际商业需求应当是我们追寻的目标。但实际过程中，除非该领域内的专家，很难完整的把握商业需求。与其自己摸索，不如多与客户，专家进行沟通。
    持续，充分的沟通，更快的客户响应，是软件行业已经证明的成功法则。

其实我的原意在于提醒大家注意需求调查时常犯的一个错误。这个问题其实对甲方也有很强的意义。甲方经常喜欢说：我需要xxx功能，我需要xx接口，但是至于这个xx功能和xx接口在自己的商业活动中能起到的作用，很少对乙方去说明，或者自己也不太清楚。这就为以后的烦恼埋下了种子。

没错，话题是越说越大了，但是这也使我能更加深入的考虑这个问题。

有一个故事，说是一个将军到前线部队去视察，发现炮兵的队列里面，每一门大炮前面都站着一个士兵。他问：这里站着一个士兵是要做什么的？没有人能搞清楚，只是一直以来一直需要有人站在这里。后来，他调查了很长时间才搞清楚原因。原来是因为以前的大炮是靠马来拉的，为了防止炮声惊吓，马乱动造成无法瞄准，必须有人站在炮前把马拉住。到后来大炮不用马来拉了，但是这个士兵的位置确固定了下来，没有人知道为什么要这样，也没有人敢改变这样的情况。

甲乙双方在建设一个项目的时候，需要搞清楚当前的IT状况、业务状况，搞清楚自己的系统里面会不会存在这种不拉马的士兵。这一点甲方的责任其实更大。

    需求和业务流程肯定是不一样的！业务流程是用户的工作环境和工作习惯，这里边包含着正确的合理的工作方法同时也包含着用户对当前工作环境和工作习惯的不同看法（类似于不正确的，低效的，工作方式或工作流程，这也就是需求）。我们给人家搞东西肯定不是说把他们当前的工作环境和工作习惯无论好坏复制到程序中去，我们要做的是和用户一起分析当前的工作流程，详细讨论共同去伪存真，给人家搞一个确实更省时更省力的系统。我的一直不变得目标因该是节省劳动成本提高工作效率。也就是说让用户感觉物有所值，别到最后化大把的rmb买回去一堆垃圾！

楼主说的这句挺好，只不过一般的开发人员能否了解足够的商业信息及谈判中的元素，是个主要问题，也就是商业需求中的主要矛盾的问题。

lane_cn 写道：

总算可以发言了，这里多大 虾，偶不敢卖弄，只是说说自己的看法。



有一点需要说明的是，这里lane_cn兄似乎已经用对立的方式来看待自己与甲方的关系。事实上甲乙双方这个时候是一条绳上的。而且，我们没有办法告诉客户说“你们用不到这个功能”，因为作为分析师/需求访谈人员唯一能做的就是引导。当然，这里有一个问题是存在的，就是有些分析师为了使客户"满意"，总是一口答应下来所有需求，因为毕竟开发不是自己在做。单从上述所提的责任来看，如果真要有个归属，我认为责任归属于系统分析师的较大。如果客户什么都知道，那么分析师就没有用了。

回到业务流程是否是需求，我个人认为“业务流程不是需求”的命题是错的，业务流程是需求的一部分，而不是全部。需求包含很多方面，从系统功能到UI，都属于需求的范围。而对业务流程的支持无疑是系统功能的一个方面。

在现实中，我们不可能把企业原先的业务流程全部抛弃不管，而重新建立，这样必然会对企业造成巨大的冲击，所以一般的方式都是在现有流程基础上进行对应计算机自动化处理的改良，所以一般不会到业务流程再造的程度。而真正的业务流程，主要的职责不是我们的系统分析员来做的，因为计算机系统只是一个工具。

这里有个“商业需求”的提法，我没有明白和所说的“需求”的具体区别。
最重要的部分不是领域模型，而是接近前面Godlikeme提到的vision，再深入一步，则是该企业的business goals.他们的business goals决定了这个系统的visions，而这visions才产生了种种requirements.至于业务流程，前面我有提过，我认为是requirements的一部分。

俺也发表一下小见，和牛人交流才有进步嘛。

有人提到了无论RUP还是敏捷都把用例放在重要位置，用例本身强调的好像就是“挖掘目标”吧，我们不仅要了解工作流程，更要挖掘出 工作目标。我的理解，这个目标不就是所谓的商业需求嘛，流程仅仅是操作步骤，步骤当然会多变化，目的是明确的！所以，我认为可以得出结论－商业需求才是需求。

那么，这里的关键问题就是怎样适应多变的过程，并最终实现商业目的。就我的理解来说，我们只能是多和客户交流沟通，尽量设计灵活的系统，很难说完全为了商业目的而去改造固有的业务流程，流程再造那得是商业管理的问题了，我们只能是尽可能的发现流程中的变化点并灵活设计。再说了，就算是流程再造了，谁能保证商业专家设计的流程就是固定不变的呢？！

所以，我的观点是以商业需求为基础，并在流程分析得过程中要尽可能挖掘变化点，最后作出适当灵活的设计。

除非客户自己计划流程再造，否则，他们会因为信息化而去改变业务流程吗？难！