电商后台产品

这是一篇关于电商后台产品的思维导图，电商后台的许多工作是将供应链流程信息化，以系统的方式来控制业务，比如商品下单，电商后天产品架构。

中心主题

• 1. 后台
  • 1.1. 服务器端的代码处理逻辑；后端
    • 1.1.1. 提交订单后台处理
  • 1.2. 后台业务管理系统（有页面）
    • 1.2.1. 你到后台上传下商品
• 2. 后台作用，为什么要有后台
  • 2.1. 给前台提供业务支持
    • 2.1.1. 订单
      • 2.1.1.1. 前台：下订单
      • 2.1.1.2. 后台：发货
  • 2.2. 给前台功能模块提供数据更新
    • 2.2.1. 拆盲盒里优惠券、津贴的配置
  • 2.3. 提供决策的依据
    • 2.3.1. 数据统计与分析后台
• 3. 后台是不是产品
  • 3.1. 产品：包含前台页面和后台处理逻辑部分；
• 4. B端、后台、SaaS、中台
  • 4.1. B端
    • 4.1.1. 使用用户是企业群体的产品
    • 4.1.2. 例子：
      • 4.1.2.1. 后台管理系统
      • 4.1.2.2. 商家端
      • 4.1.2.3. 客服系统
      • 4.1.2.4. 精准化营销平台
      • 4.1.2.5. OMS：订单管理系统
      • 4.1.2.6. TMS：
      • 4.1.2.7. ERP:
  • 4.2. 后台
    • 4.2.1. B端应用
  • 4.3. SaaS
    • 4.3.1. 软件即服务
    • 4.3.2. 软件交付使用的新模式
      • 4.3.2.1. 旧模式
    • 4.3.3. 优点：
      • 4.3.3.1. 接入门槛低：我只要旧模式下接入费用的10%或者20%
      • 4.3.3.2. 运维成本低：不需要再招人做运维
      • 4.3.3.3. 试错成本低
      • 4.3.3.4. 节约空间成本
    • 4.3.4. 缺点：
      • 4.3.4.1. 数据保密性弱
      • 4.3.4.2. 对接沟通麻烦
      • 4.3.4.3. 自由度不高
  • 4.4. 中台
    • 4.4.1. 业务中台
      • 4.4.1.1. 业务端1
      • 4.4.1.2. 业务端2
    • 4.4.2. 数据中台
      • 4.4.2.1. 一个中台处理各个业务端口的数据
    • 4.4.3. 技术中台
      • 4.4.3.1. SOA
        • 4.4.3.1.1. 面向服务架构
      • 4.4.3.2. 微服务
    • 4.4.4. 中台的作用
      • 4.4.4.1. 标准化的可复用模块或系统
    • 4.4.5. 后台定义之一
      • 4.4.5.1. 服务器端的代码处理逻辑；后端
    • 4.4.6. 公司在什么情况下会建立中台？
      • 4.4.6.1. 大公司才有？
      • 4.4.6.2. 新公司刚开始做系统，就会规划中台
    • 4.4.7. 技术
      • 4.4.7.1. 接口文档
• 5. 后台：B端
  • 5.1. B端应用
  • 5.2. 能不能把C端应用的那一套流程搬过来
  • 5.3. B端或者后台不需要做市场调研(SaaS产品除外)
    • 5.3.1. B端后台对应的市场调研流程被业务调研取代了
    • 5.3.2. 业务调研：跟公司内部人员从上到下了解公司处理某个业务的具体流程和相干角色
  • 5.4. B端也不需要定义商业模式、产品定位（SaaS除外）
  • 5.5. B端无像C端类似的用户运营、活动运营等， 公司内部处理各个业务的岗位角色；
  • 5.6. B端产品需不需要像C端产品那样事无巨细全部进行数据采集？
    • 5.6.1. 每一个按钮上都会进行埋点采集数据
    • 5.6.2. 甚至你在页面上停留了多长时间我都采集
    • 5.6.3. C端采集以上数据对用户进行行为分析去完善用户体验
    • 5.6.4. B端不会像C端那样采集各种行为数据 只会采集业务数据
      • 5.6.4.1. 客服系统：每个客服每天接待人数、 每个客服每次回复的平均时间、好评数、差评数；
    • 5.6.5. OMS系统：仓库处理订单（发货）的响应
      • 5.6.5.1. 响应速度
      • 5.6.5.2. 发货速度
  • 5.7. B端产品需不需要像C端产品那样事无巨细全部进行数据分析？
  • 5.8. B端与C端产品的区别等
    • 5.8.1. 针对用户对象不一样
      • 5.8.1.1. 都是处理用户需求，处理需求上可以一样
    • 5.8.2. C端应用更重体验（交互），B端应用重提升效率
      • 5.8.2.1. 只是关注点不一样了，做产品的过程
      • 5.8.2.2. 效率1：线下搬到了线上
      • 5.8.2.3. 效率2：原来转正申请是3层审核，进产品经理的业务调研发现其中3层审核完全是没有必要的，缩减到了2层审核
      • 5.8.2.4. 效率3：做了一个功能能够预测未来一个月商品的销售量，根据销售量来合理安排我仓库的进货；
    • 5.8.3. B端应用权限等级更多，C端基本对单一群体用户
      • 5.8.3.1. 在设计B端应用多花点形式在权限等级上
    • 5.8.4. C端运营会非常重，B端应用除做SaaS的没啥运营
      • 5.8.4.1. B端培训文档、操作手册
      • 5.8.4.2. B端解决方案PPT
      • 5.8.4.3. B端运营一般叫销售、业务
    • 5.8.5. UI设计上后台或非商用B端应用不会像C端应用设计那样全部页面都涉及， 挑选部分常规页面设计
      • 5.8.5.1. 列表页
        • 5.8.5.1.1. 数据筛选
        • 5.8.5.1.2. 数据排序
        • 5.8.5.1.3. 数据展示
        • 5.8.5.1.4. 数据分页
      • 5.8.5.2. 详情页
      • 5.8.5.3. 编辑页
      • 5.8.5.4. 图表页
      • 5.8.5.5. 主页
    • 5.8.6. 前端会专门挑选一套后台页面框架（页面样式、结构都定义好了）；
• 6. 后台常见的页面类型
• 7. 后台的难点
  • 7.1. 后台无固定的模块，根据不同的前台业务调整后台功能
    • 7.1.1. 没办法找到相应的竞品
  • 7.2. 后台业务逻辑相对于前台复杂很多
    • 7.2.1. 页面交互上
    • 7.2.2. 业务逻辑上
    • 7.2.3. 千万不要回答后台相对与前台技术实现难
• 8. B端应用（后台）产品设计流程
  • 8.1. step1：先梳理前台业务和功能结构
  • 8.2. step2:业务调研：梳理公司各个角色（公司组织架构中从上到下各个岗位） 对改后台的需求业务流程
  • 8.3. step3:根据对业务、需求、前台功能。对业务、需求、前台功能进行功能、需求分析后梳理出后台功能结构、信息结构、权限设计
  • 8.4. step4：根据功能、信息梳理出页面结构
  • 8.5. step5：画出具体页面（交互设计能力）
    • 8.5.1. 什么是交互
  • 8.6. 后台跟前台一样有一个产品，后台的产品设计流程
• 9. 设计系统之第三方系统
  • 9.1. 系统从0-1，以及某个功能的迭代优化、某个功能的从0-1
  • 9.2. 具体的某个功能跟该系统内其它功能的业务联系带来的功能逻辑联系
    • 9.2.1. 订单跟优惠券、积分、会员、活动、
  • 9.3. 该系统跟内部其它系统之间的业务联系以及带来的功能逻辑联系
    • 9.3.1. 订单（OMS系统）生成之后需要到WMS备货TMS系统配送
  • 9.4. 该系统跟外部系统之间的业务联系以及带来的功能逻辑联系
    • 9.4.1. 线上打款系统
    • 9.4.2. 短信发送
    • 9.4.3. 物流信息查询
    • 9.4.4. 支付
  • 沟通
• 10. 商家端
  • 10.1. 业务调研：需求
    • 10.1.1. 商家需要处理订单(发货、查询、修改地址)
    • 10.1.2. 针对订单备货，实际流程是由商家的仓储人员去进行的， 根据订单去仓库准备好每个订单的商品
    • 10.1.3. 需要结算给商家
    • 10.1.4. 商家需要处理退款订单
    • 10.1.5. 商品需要上传到系统展示给用户查看购买
    • 10.1.6. 还要上传设置一些活动
    • 10.1.7. 商家希望订单量越多越好
    • 10.1.8. 用户管理
      • 10.1.8.1. 想给用户退款
      • 10.1.8.2. 想知道每个用户平均买了多少东西
      • 10.1.8.3. 想要给用户进行分组， 把经常消费的用户分为一组， 商家线下单独给到他们一些礼品
    • 10.1.9. 我想看下店铺最近卖出去了多少商品， 哪些商品量卖的最多
  • 10.2. 针对需求给出功能模块
    • 10.2.1. 订单管理
      • 10.2.1.1. 发货
      • 10.2.1.2. 生成发货单
      • 10.2.1.3. 订单查询
      • 10.2.1.4. 修改收货地址
      • 10.2.1.5. 退款退货、换货
        • 10.2.1.5.1. 拒绝退款申请
        • 10.2.1.5.2. 同意退款申请
        • 10.2.1.5.3. 发起退款
        • 10.2.1.5.4. 发出换货
      • 10.2.1.6. 订单备注
      • 10.2.1.7. 页面
        • 10.2.1.7.1. 订单详情页
        • 10.2.1.7.2. 订单管理页
          • 10.2.1.7.2.1. 发货弹窗
          • 10.2.1.7.2.2. 修改收货地址弹窗
        • 10.2.1.7.3. 发货页
        • 10.2.1.7.4. 退款管理页
    • 10.2.2. 订单结算
      • 10.2.2.1. 结算单管理（信息）
        • 10.2.2.1.1. 生成结算单
        • 10.2.2.1.2. 更新结算状态
      • 10.2.2.2. 平台给商家结算（具体打款）
    • 10.2.3. 商品管理
      • 10.2.3.1. 上传商品
      • 10.2.3.2. 商品审核
      • 10.2.3.3. 商品发布（上架、下架）
      • 10.2.3.4. 商品编辑
      • 10.2.3.5. 商品删除
    • 10.2.4. 营销管理
      • 10.2.4.1. 优惠券
        • 10.2.4.1.1. 满减
        • 10.2.4.1.2. 满折
        • 10.2.4.1.3. 无门槛优惠券
        • 10.2.4.1.4. 直减券
      • 10.2.4.2. 秒杀活动
      • 10.2.4.3. 拼团活动
      • 10.2.4.4. 砍一刀
      • 10.2.4.5. 付费会员
      • 10.2.4.6. 分销
    • 10.2.5. 用户管理
      • 10.2.5.1. 用户查询
      • 10.2.5.2. 用户详情
      • 10.2.5.3. 用户分组
      • 10.2.5.4. 用户标签
    • 10.2.6. 数据中心
      • 10.2.6.1. 商品数据
      • 10.2.6.2. 订单数据
        • 10.2.6.2.1. 转化数据
      • 10.2.6.3. 活动数据
      • 10.2.6.4. 用户数据
      • 10.2.6.5. 店铺数据
        • 10.2.6.5.1. 曝光等
• 11. 平台端：后台
  • 11.1. 怎么去推后台的功能结构
    • 11.1.1. 1、先理清楚前台的业务和功能结构
    • 11.1.2. 2、功能是满足用户（公司组织架构中的岗位）需求的
      • 11.1.2.1. 找到对应岗位的人去了解他们的需求
      • 11.1.2.2. 找到对应岗位的人了解公司做某件事的流程以及业务上的细节点
    • 11.1.3. 后台或B端应用，处理的是对现实世界的 抽象， 对于抽象对象的管理上都会使用状态方便管理
  • 11.2. 先理清楚前台的业务和功能结构
  • 11.3. 订单管理
  • 11.4. 资金管理（财务）
  • 11.5. 权限管理
  • 11.6. 营销活动管理
  • 11.7. 功能模块
• 12. 前台是必备后台？