用劳动分工理论思考端产品的本质

　　笔者结合自己做B端产品以来踩过的坑，从劳动分工理论开始去思考B端产品的本质。
　　入职以后负责设计的两个系统都属于公司内部业务支持性产品，即所谓的B端产品。
　　在做第一个系统由于经验不足，犯了很多错踩了很多坑，总结教训后，在做第二个时便得心应手了很多。期间也对B端产品有了些零散的领悟，希望通过写文章的方式将自己的思考提炼总结与大家分享。
　　文章内容可能更偏上层理论和思维方法，个人认为这比产品设计细节更为重要。正如吴军在《数学之美》中提到的，有正确设计思想方法的技术未必成功，但没有正确设计思想方法的技术一定失败，无一例外。
　　什么是业务？
　　在工作中，我们常常道听途说一些意义模糊的词，我们只知道它大概的意思和用法，但如果真的要求解释，就没用起来那么简单了业务就是这样的词。我们常听说，c端产品服务于用户，b端产品服务于业务，在做b端产品设计之前也常常需要先进行业务分析，熟悉业务是做好b端产品的关键等等。
　　类似的词还有企业，这个词的经济学定义直到1937年才被科斯解释清楚。在建立一种理论时，首先应该考察其赖以成立的基础，同样如果我们甚至不能明确什么是业务，又怎么能在此基础上进行分析？
　　究竟什么是业务？这要从劳动分工说起。
　　自亚当斯密提出分工理论以来，劳动分工被视为高效组织的必要条件。亚当斯密在《国富论》以扣针制造为例解释到，由于分工能够充分运用工人在劳动时所表现的熟练技巧和判断力，因此能够最大程度上提高劳动生产率。在此基础上，以泰勒为代表的的科学管理学派开始将流程管理思想作为正式的管理理论进行研究，将基于经验的隐性知识抽象为显性知识用于划分流程，同时代福特基于此创造了第一条流水线作业模式。
　　20世纪以来，随着机械化大生产的发展和企业规模的扩大，组织内部均按照分工理论，将价值产生过程分解为简单基本的动作和对应的科学明确的管理规程。有了分工之后，不同的人，不同的部门，不同的企业都有自己为达到某个特定目的而进行的工作（而职业和行业，就是指跨组织的人和企业的相似的工作内容）。
　　我们所说的业务，就是这些企业层面、部门层面和个人层面的特定工作任务的集合。同一层面上的各项业务或环环相扣，或相互辅助，最终将价值片段编织为价值链，完成由输入到输出的转化，为顾客提供有价值的产品和服务。因此，劳动分工决定了各种各样的业务目标和业务结构，流程抽象区分层级组合结构特定目标价值增值就是描述一个业务的关键要点。
　　在理解了什么是业务之后，我们在就能把握业务分析时的重点，事实上，整个业务分析的方法论就是建立在这样的基础之上，具体方式方法很多书都有介绍，就不在此详述了。
　　B端产品在业务中扮演的角色
　　各项业务在进行过程中，会产生事物的流转，包括信息流、物流、资金流等等，价值增值正是在这些流转过程中产生。
　　在信息化产品出现之前，信息是如何在业务进行过程中流转的呢？
　　劳动分工使组织达到某一目标需要经历多个活动，各项活动间的关系包括中介和合作。中介程度高的流程包含较多输入输出的有序步骤，而合作程度高的流程意味着需要随时交换信息。在这些流程中，大量的精力被耗费在了信息内容的同步工作以及解决同步工作的延误与差错之上，并没有劳动力、知识的转化带来的直接的价值增值。
　　与此同时，分工理论将工作划分为细小的单元并定义好各单元输入输出接口的做法，造成了信息在各个流程主体认知中的割裂，使每个流程主体仅对自己处理的部分的输入和输出负责，缺乏对于总体流程的认识，对业务的最终结果也缺乏责任感和工作积极性。
　　从解决传统分工理论带来的信息问题的角度出发，B端产品要帮助企业解决的首要问题，就是信息的记录、传递和共享问题。包括CRM（客户关系管理）系统、SCM（供应链管理）系统、ERP（企业资源计划管理）系统等，其核心都是为了帮助某个业务单元解决以上的三种问题。
　　他们通过建立共享数据库，使不同人员更新数据状态都能同步合作者或是流程中的下一环节，消除了业务中的非增值环节，极大节省了达成同一项业务目标需要付出的成本。同时由于不设限的情况下，所有人都能查看业务流程中的所有信息，并将其用来辅助自身，做出真正产生价值增值的工作。
　　而至于B端产品的其他功能，与解决劳动分工带来信息问题关系不大，并非系统的核心诉求。如自动化数据处理和计算，是通过利用计算机的计算能力，获取局部的效率优势，而包括数据分析、报表、监控在内的功能，都是B端产品在解决这些基本问题基础之上，通过数据的积累而产生的附加价值。
　　B端产品设计
　　以上感悟对于具体的产品设计工作至少有以下几点指导作用。
　　1。重构业务流程
　　将已有业务流程简单复制，是产品设计的误区之一。企业的旧业务流程一般建立在过时的假设和规则下，新的规则需要与信息技术相适应，某一些不必要的任务和人员都可以进行清除、简化和整合。
　　例如在信息化产品出现之前，由于管理层掌握了更多信息，决策只能由管理层作出，这种层层向上的决策体质严重业务的进度和对外界的响应速度，而在开放数据库和建模工具的支持下，较低层的员工也能获取充分的信息来做出决策，我们在设计核心业务流程时，就可以考虑清除或简化这些不必要的流程。
　　2。挖掘流程之外的隐性需求
　　我在两次系统功能设计时都犯过一个错误，就是仅仅将眼光放在信息的记录和传递之上，而忽略了B端产品另一个重要功能，即知识共享。这是对信息化产品的应用本质的理解不足导致的。
　　基于过去割裂式的工作经验，业务方自己也无法认识到业务流程之外的信息需求，这需要产品经理在理解信息化产品的应用本质的基础上，识别能够使业务能够更充分利用信息价值的产品功能，例如全局的基于对象（而非基于流程）的检索功能、数据看板功能等。
　　3。评估功能优先级
　　我们在确定功能的优先级时，有一些简单粗暴的原则，例如：凡是手工可以处理的问题，都暂时不做系统支持。但如果按照这个原则，什么不是手工能够操作的呢？
　　如上所诉，既作为信息化产品，要帮助组织解决的首要问题，就是完成某一业务目标过程中与信息流转相关的问题，包括信息的记录、传递和共享。而其他与之无关的功能都非系统建设的核心，除非老板强制要求，就可以往后放一放了。以此来评估功能优先级，有了理论的支持，就不怕怼不过谁了。