业务用例示范.docx

3.1 软件是组织的零件 业务建模的目的是从组织的角度来定位系统应该提供的价值，所以说“业务建模”这个名字其实起得不好，应该更名为“组织建模”。出于对过去叫法的尊重，本书依然称为“业务建模”。做一做以下题目，可能会发现答案出乎你的意料。 很多时候我们把自己在开发的系统（现在流行叫××平台了）看得太重了，感觉没有我们开发的系统，组织就玩不转了。其实，我们那牛×哄哄的系统也只是组织的一个零件，和组织厕所里的马桶没有本质区别。组织里面还有很多系统，其中最值钱的是千百年来一直在使用，现在依然是最复杂的系统——人肉系统，它由“父母公司”开发，“老师公司”不断升级，组织以每月每人几千上万的租金租用。要改进组织的价值，不一定要开发软件，有时换人（也就是说，不是更换软件系统，而是更换人肉系统）更管用。和一套软件系统的价格相比，也许雇用一名高级员工花费更多。 开发人员有时会有意无意把自己的系统想得太重要。有一次我到北京某公司讲课，开发人员在写某信贷风险系统的愿景时写道：本系统的目标是，银行风险部能够对贷款做风险评估。我问道：难道银行以前不能做风险评估吗？他认真地回答：不能啊，有我们的系统才行！其实想想就知道，银行已经成立多少年，贵公司才成立几年？所以，为了抵消开发人员这种“致命的自负”，有时我会故意将“系统”称为“马桶”——你做这个马桶是干什么的？ 为什么需求经常“容易变化”？根源之一是它们的来路不正，一开始的时候是拍脑袋得来的，没有把系统当作一个零件放在组织中来看，得到的系统当然和组织的其他零件格格不入，系统上马磨合后发现问题，自然要改。“需求变化剧烈”只是一个假象，许多需求的变化是假的变化，真正的需求并没有变，只不过开发人员一开始捕获的需求是假的。如果能正确运用业务建模技能，大多数假的需求变化会消于无形。遗憾的是，不少开发团队在改进的时候给自己开错了药方，以为应该通过提升设计的弹性来应变。设计是应对真正需求变化的手段，假的需求变化应该通过改进业务建模来应对。 如果东西拿到客户面前，客户说“好呀，正是我想要的！”，过了半年，客户又说“形势变了，这个东西要改一下。”这是需求变了。如果东西拿到客户面前，客户说“这不是我想要的！”，这时硬要说“需求变了”，脸皮有点厚了。 说起业务建模，很多人会联想到大企业、ERP、工作流….其实，所有类型的系统都可以使用业务建模技术来得到有价值的需求。后文会看到各种领域的具体例子。 3.2【业务建模步骤1-1】：选定要改进的组织 业务建模既然是研究组织，那么研究哪个组织呢？理论上来说，先研究整个世界，再慢慢缩小范围，一直到能定位我们要开发的的系统，但这显然太浪费了。最佳的研究范围就是愿景波及的、需要改进的组织，它可能是一个公司、一个政府单位、一个部门、一间办公室、一个家庭、一群人…… 现在的许多系统，改进的组织是一个人群（如车友）而不是正式组织（如某公司）。人群也是组织，组织也就是人群，业务建模的方法是一样的。某公司是一帮人，车友也是一帮人，它们之间的区别仅在于有没有组织机构代码证而已。某公司里有总经理、部门经理、普通职员……车友里有骨灰车友、发烧车友、入门车友…… 如何圈定这个最合适的研究范围，没有标准答案，可能要试很多次。如果发现组织的绝大多数流程和改进不相干，说明选的范围可能太大了；如果发现很多要改进的地方未涉及，说明选的范围可能太小了。 以下是可以参考的几点思路： 画一个圈，把大多数责任可能被（部分/全部）替换的系统（人肉系统/电脑系统…）包在里面。 例如：要开发一个企业内部员工训练平台，替换的责任大多属于人力资源部人肉系统的工作，这时可以把人力资源部作为研究对象： 图3-1 把大多数系统圈在里面 请注意上面的用词，“大多数责任可能被替换的系统”，而不是“大多数系统用户”。因为此时待开发系统的边界尚未确定，不能先入为主地把某些人肉系统称为用户（而且前面我们说了，不是“用户”，而是“执行者”）。系统要做的改进和训练专员的工作有关，不代表训练专员一定是该系统的执行者，也许人力资源总监会觉得取消所有的训练专员可能是更好的方案。 得到的结果其实就是老大所代表的那个组织，所以这个范围大小和老大的职权范围是相关的，如果老大只是人力资源总监，把整个公司作为研究对象就太大了；如果老大只是大学里面某个学院的院长，把整个大学作为研究对象就太大了。 互联网网站项目如何选择业务组织 如果苍井老师购买了一套软件安装在她的电脑里，她会觉得这套软件是她的，但是，如果苍井老师觉得新浪微博很好用，她的认识就有些微妙的变化，会觉得新浪微博是新浪公司的。开发人员在为探索互联网网站的需求而做业务建模时，也常会发生类似错误——要开发下一代互联网网站挑战新浪微博，所以把新浪公司作为研究对象？更正确的做法是把明星人群作为研究对象，思考如何做出更牛的网站