方法论：业务系统的技术架构
|
好的架构能良好的支持业务的横向扩展。这点很重要，新的业务很多时候都在试错阶段，随时会增减业务环节，也就是不断地新的系统，新功能的融入。比如在几个流程节点上增减一个三方部门审核操作，审核系统本身不麻烦，但要做到即插即用，对接多个系统和公司多个单位，那不同的架构可能工作量差异很大 好的业务架构各个系统的数据在业务整体上是连续的、完整的、准确的。通过数据采集，方便建立DW。可以很好的为业务运营提供数据支撑。 好的业务架构，系统能提供的不止于业务功能，还有无时不刻无处不在的驱动各模块业务和各合作伙伴业务更好决策的数据。 四、业务系统和用户系统
以产品为中心，是我有好的市场调研，我有牛掰的产品经理，我给使用者的产品就是我能做的最好的，最大可能是使用者需要的。 以客户为中心，适合面向运营单位，面向商家的企业级应用，理念是使用者需要什么 使用者，可以是直接用户，商家，也可能是公司的销售，客服。 两类系统，一个标志性的区别，就是我们是否关注和承担使用者的业务结果。 CRM、供应链等业务系统是需要所有人共同承担业务结果的。邮件新闻用户产品，我们不需要承担用户使用后增长多少知识的结果。 如果不理解这个以产品为中心和以客户为中心的不同， 以用户产品的思路做企业级应用， 就会出发点出错，就是闹笑话。 比如，我之前的公司，明明是以CRM为主的销售管理系统，但同事们喜欢拿个淘宝网站的架构来做参考。 理论上， 用户系统里淘宝网站和人人车、链家、京东都是一样，都是把商品（车/房）展示给用户，获得订单（线索）。 作为“信息”提供方，是把自己有的东西，用自己的方式展示出来。 理解两类系统在逻辑上的差异，我也是用了很多年，过去在公司总是和同事说不清楚，其实也是我自己没想明白。可能是我在写这篇文章时候才多了些思考。
因此，只有业务系统才可以说数据是永远的程序是暂时的，用户系统不应该如是说。 五、运营驱动一般公司的内部销售运营体系，都是业务导向，实现业务目标是第一位。但会经历两个阶段， 一是 ，业务驱动。 这段时期，业务模式不稳定，产品能力的问题或者业务人员强势， 业务部门引导公司方向 。这种情况，产品的作用有限，虽然也有便利性，创新性的要求，但总体说还是业务需求的翻译官，业内称作功能性产品经理 二是，产品驱动。当业务模式固化下来，尤其是业务流程相对标准化以后，产品经理（或者运营）主导规则和流程 CRM 是最具代表性的业务系统
现在回答一下，什么是好的产品（业务模式）应该就是解决用户真实需求的实际痛点。从痛处入手。这里的用户可以是Toc的消费者，也可以是面向公司运营单位 产品思维： 从痛点入手，去解决问题，这是我理解的产品思维。而产品经理常常挂在嘴边的需求分析其实是个伪命题。做用户产品，产品经理能接触到多少用户了解到多少需求？ 做业务系统，北区大佬要APP，南区大佬要网页版，产品经理那个都惹不起，听谁的？ 无论做什么产品，得是PM自己有能力设计主流程和规则，紧贴公司的方向和核心KPI，而不是翻译谁的需求。 至于抽象，迭代，交互设计，那可能叫产品能力更合适。 就像java能力可能是技术的基本能力，java再好和是否能开发出微博微信，没直接关系。汉语再流利，和写一篇量子力学论文基本也没关系 接上一节的话题，我认为比较合理的公司架构是运营驱动。 什么是运营？？ 运营就是人为的干预规则。规则就是咱们的产品逻辑，也就是业务规则。 在电信行业出来以前，世界上是没有真正的运营的。 甚至诺基亚和微软卖出去产品，很难知道用户打了多少电话，用电脑做了什么， 而电信和互联网时代的到来，一切不一样了， 我们可以清楚的掌握业务执行结果，也就是用户使用我们的系统到底做了什么。通过使用者的使用情况，从结果知道客户需要什么，更新规则。 这套逻辑在业务系统提现得更加清楚明确， 用规则去约束销售、客户，接单后的动作，规定动作的时间等。 通过了解使用者对规则的执行情况，对比团队以及公司的KPI，分析偏差了那些，为什么偏差，再次升级系统，干预规则，干预偏差。 运营驱动，适合多个运营单位合作，非业务驱动的产品模式。很多时候，业务流程和公司组织架构的实际情况，做不到或者不需要运营驱动 多说一句，无论是做产品还是技术，掌握业务结果非常极其特别十分的重要，但大部分产品和技术都对此不感兴趣，也就限制了个人的上升空间。 业务结果分两部分，一是系统运行状况，二是用户（业务人员）的使用结果。前者及格线是系统出了问题你要第一时间知道，不能等运营单位投诉再排查。后者就是每天到底多少用户，多少订单成立率转化率，这些必须关心。不能光想着系统怎么去实现，更要知道业务用你的系统做出了什么，以及每次产品升级为什么而做。 （编辑：源码网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
