三户模型学习笔记
QBOSS:Qunar BusinessOperating Support System 去哪儿业务操作支撑系统
BOSS :Business OperatingSupport System 业务操作支撑系统
QBOSS 划分
Billing &Account:计费账务,接入公司各个业务线的收入数据
Clearance &Settlement: 清结算,结算属于供应商的款,支付,供应商之间的结算
Financial System :财务系统,仅仅只是财务人员相关的,就是我们QPX做的事情.
ContractManagement:合同管理
Service Fulfillment 业务自动开通,当跟供应商签订合同后,但是供应商上线操作还是有很多事情要做到,域名,网站,tts系统,分配账户等等操作打包完成它.
Master Data Management主数据管理. 客户信息,供应商信息,合同信息,业务签订相关,供应商账户等. 订单,支付等数据不属于主数据.
Business Analysis业务分析,商业行为,收入增长,利润,盈亏等等
BU: Business Unit事业部
SI : Special Items 特殊部门.
三户模型:
业务线越来越多:机票,酒店,车票,火车票
业务模型越来越多了: CPC/CPA,CPM等
边缘系统越来越多
客户越来越多
收入数据骤增
越来越复杂了
因此系统越来越复杂,我们现有系统已经搞不定了.
返点
现金
保险:保险收入要单独计算,由于财务计算上的需要
这三种钱的使用方式不同,需要根据不同的规则去使用这些,有些时候能用
保险,有的只能用现金,扣款
大客户: 酒店和机票 分开计算,归并计算,就只能用一个来进行计算
点击:集团付
赔付:各个分公司去付
业务系统提需求,我们去实现,实现完成了,呵呵需求变了,不做了,被需求追着走,
我们能否有一种方式去支持,走在业务之前.引导业务的走向,从根本上解决这些问题.
A methodolgoy of how tounderstand Business?
企业的业务架构
Business is a story about ...
who:你跟谁在做生意
what:你跟你的交易对象卖的是啥?
how:怎么卖?怎么算钱,怎么计费.
进一步进化为:
people:人
product:产品
money:钱
进一步抽象成
social:社会属性
marketing:市场属性
finance:财务属性
所以就有了我们的三户模型
customer:客户
subscriber:订户(用户)
account:账户
三户模型是谁发明的?来源于电信行业,中国人民的智慧, eTOM(Business ProcessFramework)
引入这个是我们给他们做的事情非常类型,业务模式差不多.
计费方式类似,依照你对资源的使用进行计费的.基于使用进行计费(CPC,CPA,CPM)
来源于中国联通,给的文档相对ok
BSS:Business Support System 业务支撑系统:
OSS:Operating Support System 操作支撑系统/OPS
MSS:Management Support System 管理支撑系统,ERP/OA
简单业务下,三者之前是非常类似的,经常混了.
三户模型:triple account model
客户:
产品域账务域 客户域
怎么定义一个客户:能给去哪儿带来收益的才算客户.收入是由谁带来的,谁才是我们的客户.谁能给我们带来收益.收取的是代理商的佣金.
代理商是我们客户.
酒店直销场景中,去哪儿给消费者开发票,然后找供应商要酒店开票.
供应商是我们的客户.
包房的场景中,消费者是我们的客户,我们是供应商的客户.给供应商带来收益.
而消费者给我们带来了收益,就是我们的客户.
用户(subscriber):用户描述的是一种关系,客户和产品之间的订购关系,订购行为,才能成为用户.
是一种逻辑上的概念,而不是某个实体.用户一定是由于购买或者订购了某个产品才能成为用户,必须要有订阅产品关系.
也叫订购实例.subscribe_instance,是相对于某个产品来说的.
用户是订购关系的实体.
产品:是一个抽象概念
产品实例:用户对应于一个产品实例的
什么叫产品? 服务+价格=产品
一定要有价格,才会能成为产品.
机票OTA: 提供了服务,交易平台服务
定价策略:CPC/CPA,交易平台免费,点击流量计费
CDR: click detail record ,基于CDR进行计费.--->得出一个价格
产品服务:
产品的属性包括:价格,服务,资源,市场渠道,促销优惠,contract合同,DID链路
优惠要单独出来:作为一个和产品平级的东西去描述.
有一个优惠对象,把产品作为参数丢给优惠接口,获取到一个优惠价格,就算完事了.
抛开用树形结构去描述这个事情
supplier,用关系去描述,而不是树形结构去描述.
这样我们就能很好的进行处理了
供应商不是来签合同的,是来买你的产品的.
支撑系统的自动化:节约成本,提高效率
销售只管跟合同卖产品,因为要卖产品,所以我们要签订一个合同.
产品订购实例:
面向产品去做这个事情
abstractproduct: service resource price
ProductInstanceA: ServiceInstanceA,ResourceInstanceA PriceInstanceA
ServiceInstanceA内部又有各种东西,从服务层面去进行抽象
产品的抽象思维
费用都是用户产生的,客户是不会产生费用的.
用户和账户:多对多关系,集团和子公司计费.
点击就由集团账户进行支付,
赔付金由子账户进行支付.
账户:是使用服务的付费实体,是用户付费和定制账单的最小单元
