方法论:业务系统的技术架构
|
好的架构能良好的支持业务的横向扩展。这点很重要,新的业务很多时候都在试错阶段,随时会增减业务环节,也就是不断地新的系统,新功能的融入。比如在几个流程节点上增减一个三方部门审核操作,审核系统本身不麻烦,但要做到即插即用,对接多个系统和公司多个单位,那不同的架构可能工作量差异很大 好的业务架构各个系统的数据在业务整体上是连续的、完整的、准确的。通过数据采集,方便建立DW。可以很好的为业务运营提供数据支撑。 好的业务架构,系统能提供的不止于业务功能,还有无时不刻无处不在的驱动各模块业务和各合作伙伴业务更好决策的数据。 四、业务系统和用户系统
以产品为中心,是我有好的市场调研,我有牛掰的产品经理,我给使用者的产品就是我能做的最好的,最大可能是使用者需要的。 以客户为中心,适合面向运营单位,面向商家的企业级应用,理念是使用者需要什么 使用者,可以是直接用户,商家,也可能是公司的销售,客服。 两类系统,一个标志性的区别,就是我们是否关注和承担使用者的业务结果。 CRM、供应链等业务系统是需要所有人共同承担业务结果的。邮件新闻用户产品,我们不需要承担用户使用后增长多少知识的结果。 如果不理解这个以产品为中心和以客户为中心的不同, 以用户产品的思路做企业级应用, 就会出发点出错,就是闹笑话。 比如,我之前的公司,明明是以CRM为主的销售管理系统,但同事们喜欢拿个淘宝网站的架构来做参考。 理论上, 用户系统里淘宝网站和人人车、链家、京东都是一样,都是把商品(车/房)展示给用户,获得订单(线索)。 作为“信息”提供方,是把自己有的东西,用自己的方式展示出来。 理解两类系统在逻辑上的差异,我也是用了很多年,过去在公司总是和同事说不清楚,其实也是我自己没想明白。可能是我在写这篇文章时候才多了些思考。
因此,只有业务系统才可以说数据是永远的程序是暂时的,用户系统不应该如是说。 五、运营驱动一般公司的内部销售运营体系,都是业务导向,实现业务目标是第一位。但会经历两个阶段, 一是 ,业务驱动。 这段时期,业务模式不稳定,产品能力的问题或者业务人员强势, 业务部门引导公司方向 。这种情况,产品的作用有限,虽然也有便利性,创新性的要求,但总体说还是业务需求的翻译官,业内称作功能性产品经理 二是,产品驱动。当业务模式固化下来,尤其是业务流程相对标准化以后,产品经理(或者运营)主导规则和流程 CRM 是最具代表性的业务系统
现在回答一下,什么是好的产品(业务模式)应该就是解决用户真实需求的实际痛点。从痛处入手。这里的用户可以是Toc的消费者,也可以是面向公司运营单位 产品思维: (编辑:PHP编程网 - 湛江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |




