最近又有时间了，所以准备更新一些实际在工作中会涉及到的一部分。目前主要是做学校相关的项目，我们的项目相对来说是属于ToB的，因此我们这边主要是面向学校做解决方案。那么基于学校的各种应用场景，我们会涉及到多套系统（目前囊括在做的和规划的目前主要是10多套IT系统的整合）。同时由于运营端在咱们公司，所以对于学校相关的运营数据及学校之间业务数据打通来说做一个数仓是非常有必要的。那么此块我们结合我们现在在做的系统来说，我们来梳理下整个搭建数仓所参与的情况。
本文我们主要介绍构建数仓的第一步：业务很重要。
不管是作为团队的架构师还是团队的产品经理，对于我们要做的系统来说，前期熟悉业务非常重要，整个业务的梳理，业务的筹划，运营方向的筹划作为我们IT系统建设来说，占比我个人会认为是80%以上。因为现如今国内的IT发展很快，相关的技术也很成熟，那么如何利用技术来完成甲方的需求，这个在实施阶段的话我觉得还是比较容易的。当然前提就是提前把整个业务相关的筹划做好了。
熟悉业务
这里熟悉业务的话，我们可以从几方面入手，以高校（大学）来举例，我们梳理数来的整体熟悉业务思路如下：
1、业务的目标和愿景是什么？
像我们做学校项目，我们的业务目标和愿景就是做学校的解决方案。我们为我们的每一个甲方客户（学校）构建解决方案，那么这个解决方案肯定不是空穴来凤的，我们的最终目的是盈利，所以我们需要考虑的点有什么呢？
1）学校的需求
既然我们是做学校解决方案的，那么我们基于学校的哪些痛点和需求来做解决方案呢？我们梳理的场景有：
⑴：面向学生的需求
1、学生进出门禁可以开发需求 2、学生吃饭/购物/洗浴等可以开发需求 3、学生快递可以开发需求 4、学生场馆预约/使用可以开发需求 5、学生社团相关的活动可以开发需求 6、等等
⑵：面向老师的需求
1、班级/学生的管理可以开发需求 2、学生的考试可以开发需求 3、学生的教学课件/视频等可以开发需求 4、学生的就业情况可以开发需求 5、等等
⑶：面向学校的需求
1、校区/学院/年级/班级管理相关的需求 2、教职工管理相关的需求 3、招生相关的需求 4、就业相关的需求 5、等等
2）业务盈利模式
这里的盈利模式也是一个比较大的考究，比如现有的业务是纯卖软件，靠软件收费+后期维护收费还是靠流量收费（用多少收多少钱）.
以上两点我觉得是我们在做业务前期一定要考究的重点，当然还可能有其他的一些点，比如客户的一些特殊需求，老板的一些特殊需求等等。我们都要进行综合的考量。
2、制定产品线/业务线框架
前期我们把战略目标和愿景定下来了，接下来我们就要开始制定相关的产品线了。此时我们要思考的是：
1、我们是做一个个单独的系统，为每一个业务场景单独做一个it系统，各业务线和产品互不干涉？ 2、我们做sass系统，各业务线和产品糅杂在一起。通过saas统一管理？ 3、我们分阶段做各个独立产品，通过某一个产品把各个独立的产品连接起来？ 4、其他方案？
我们根据上诉1的目标和愿景来考量具体采用那种实施方案的产品线框架。
3、业务痛点
目前来说其实各个学校已经实现了部分的电子化，一般对于新的企业产品进住的话无外乎以下几个原因：
1、当前学校没有相关业务的IT产品 2、当前学校有相关的业务产品，但是成本很高，需要更换 3、当前学校有相关的业务产品，但是乙方因为某些原因无法继续为甲方提供增值服务 4、当前学校有相关的业务产品，但是乙方的实力有限，无法提供给甲方满意好用的产品
所以我们在指定产品线之后，我们接下来就要了解下甲方的相关的背景，掌握甲方的一些痛点，然后根据痛点来制定接下来相关的解决方案。
4、需求收集
需求收集的话，这里主要是收集业务方（甲方）的各种需求，然后在符合乙方战略目标及愿景的前提下，为各种需求分配优先级，把乙方公司有限的资源（包括不仅限于人力资源，资金消耗，开发复杂度）利用到合理的程度。以尽快保值保量的交付甲方的需求。
5、需求调研
需求收集其实也是筹划的阶段，筹划完毕之后我们就要进入需求调研。此时我们主要分3步走：
1）业务调研
这里的业务调研主要是：
1、调研需求是否完全满足客户想要的目标。是否有额外没考虑到的地方。 2、调研此需求对于产品来说，是否好做，做出来是否好用。 3、调用此需求对于运营来说是否有阻碍，是否有没考虑到的地方。 4、归纳相关的需求，产出相关的业务过程、功能流程、数据流转等。
2）需求分析
这里的需求分析主要是：
1、把需求细化，根据前期制定的业务过程，功能流程，数据流转，产出相关的功能模块，数据指标体系等。
3）数据调研
做2b的场景，我们经常会涉及到甲方让乙方在某个产品里面接入丙方的数据（这种是非常常见的业务），那么此时数据方面除了乙方资深系统流转的数据，还需要加入第三方的数据尽力啊，所以对于技术模块还需要进行数据调研例如：
1、数据类型 2、数据来源 3、全量数据情况 4、每月/每年数据增长情况 5、数据的更新机制 6、数据是否结构化 7、数据是否需要清洗 8、使用接口调用还是直接访问库 9、有哪些类型的数据
6、产出
到这里的话其实就是内部产出的了，主要分为两个方面：
1）产品方面
到这里就是实施阶段了，产品方面要求的产出有：
1、产品业务架构图 2、产品业务流程图 3、产品原型 4、产品业务/功能/逻辑文档
2）架构师方面
1、业务架构图（技术层面的业务架构图：包括不仅限于各业务之间的模块，各业务内部子模块之间的层级关系，包含关系，评级关系，主次关系图等） 2、业务流程图（技术层面的业务架构图：包括不仅限于各业务之间的模块，各业务内部子模块之间的交互流程，交互模式，交互业务，注意事项等等） 3、技术文档(各个系统相关的技术文档，包括不仅限于：架构、业务、技术选型、技术开发实施、运维部署、扩展维护等信息)
以上6大版本其实主要是说明一个东西：熟悉业务很重要，在前期我们把业务相关的工作筹划好了，后期实施起来是非常方便的，也大大的减少了团队在实施阶段做一些重复性或者“浪费性”的工作。同时前期我们把业务熟悉后，相当于为后面的实施指定了方向，也会少走很多弯路。
本文虽然介绍的和数仓没太多关系，但是用他做数仓的开头，主要还是为了让大家提前有一个全局的概念。方便后期在实施阶段有统筹的能力。
还没有评论，来说两句吧...