本节书摘来自华章出版社《企业大数据系统构建实战：技术、架构、实施与应用》一 书中的第2章，第2.3节，作者：吕兆星 郑传峰 宋天龙 杨晓鹏，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.3 大数据制度和流程规范
2.3.1 制度和流程规范意义
规范化管理是企业中一项艰巨的且需要持续改进的工作，它是企业各项工作正常有效开展的基础，是企业健康有序发展的有力保障。大数据制度和流程规范作为企业规范化管理的一部分，对于大数据工作的开展至关重要。大数据制度和流程规范建设的意义主要侧重于三个方面：
可以保障企业内部大数据系统和周边业务系统运作的有序化、规范化、流程化和标准化，可以降低沟通成本并提高工作效率，保证最终的工作产出。
可以通过制度性措施界定各事业群、事业部、体系、中心、部门间的利益主体和权责范围，是有机开展工作，避免推脱、不作为、越权工作的重要途径。
通过制度性约束可以降低业务运作风险以及数据安全风险，这是企业开展大数据工作的基本前提。
通俗而言，制度和流程规范不是必须的，或者说不是所有企业都需要严格的制度和流程规范。在实际应用中，制度和流程规范通常适用于大中型企业，为了提高企业运转效率而采取建立现代企业制度的方式；而对于小企业而言，灵活的管理方式、直接高效的沟通机制和更扁平化的直接管理可能更适合真实运营的需要。因此，这里的制度和流程规范的试用对象更多的是针对大中型企业。
2.3.2 制度和流程规范内容
制度和流程规范类内容大致可以划分为两类：
工作制度，这类文档对其范围内的人员进行约束，常有“制度”“规范”“规章”等字眼出现，这类内容不能被随意修改；
工作模板，这类文档是相应人员开展工作的参考内容，可供其直接应用于大数据工作开展，也可根据实际情况进行修改。
大数据制度和流程规范建设涉及大数据工作中的所有环节，从大数据的工作体系看，包含以下几个部分：
1.?基础平台类
基础平台类规范提供服务器测试和正式环境的系统运营、服务维护、应用维护管理的范围、目的、性质和原则，通常以系统运维管理规范或制度的形式存在。该规范适用于开展系统运维护活动涉及的各类组织及其落地操作的工程师。
规范主要涉及的内容包括：
机房环境，包括安全系统、空调、UPS、备用发电机、供水、供气、排污等；
基础服务器，包括主机系统、存储/备份系统、终端系统等；
网络设施，包括交换机、网络、通信、电缆等；
应用系统，包括内部办公系统、门户网站等应用系统；
业务系统，包括内部开发以及外部购买的业务系统等；?
中间件，包括配置信息、故障信息、性能信息监控等；
供应商系统，包括基础设施和应用系统的供应商以及IT运维服务的供应商系统；
云服务系统，包括采购云端的固定投入平台以及按需付费的弹性平台系统等。
除了基本运维信息涉及的系统软硬件运维管理外，还可能包括权限管理、数据管理、系统监控、系统培训等内容。
基础平台类规范的主要核心是通过各种标准化和流程化规范保证系统的可用性和稳定性，规范中需要兼顾到不同角色的负责人和职能分工、量化的工作标准和响应时间、操作流程和方法、问题沟通工具和流程等。除上述规范性工作流程外，建立针对突发事件应急预案和防护策略也是规范的重要组成和安全的应急保障。
大多数企业中除运维工程师自己发现并解决问题外，其他系统或部门人员也会反映相应的问题，此时通常会通过一个名为“IT工作台”或“IT服务台”的角色对涉及的大数据相关事务进行统一收集、分配、处理和反馈管理。
2.?数据管理类
除CDO（首席数据官）外，数据管理类的主要操作或管理对象是数据，因此本小节主要讨论的内容是有关数据及其数据周边的制度及流程规范。数据管理类规范的主要存在方式为数据库管理规范以及相应的流程规范，它主要针对数据进行管理，降低数据被非法生成、变更、泄露、丢失及破坏的风险。该规范适用于DBA、数据库管理工程师、数据安全管控师等。
规范主要涉及的内容包括：
数据范围，涉及所有的业务系统、职能系统和IT系统数据；
数据环境，包括所有的测试环境和生产环境数据；
数据公司，适用所有集团、总部、子公司和分部等各类数据相关组织；
数据有效期，大多数数据都是有有效期的，不同有效期状态下的数据应该有针对性的管理策略、存储介质；
数据安全规范，包括数据安全定义、接触、接入、备份、同步、授权、认证、加密、操作日志记录等；
数据操作规范，包括数据的新增、修改、更新、删除等数据变更规范，数据加密、解密等脱敏和安全规范以及数据提取、分发、打印、登记等流通规范；
数据库管理规范，包括用户角色管理、数据库管理、系统升级维护、数据库安全管理等。
数据管理类规范是数据安全的必要保障，也是开展所有数据工作的基本前提，因此是每个公司必须具备的一类规范和流程制度。出于数据安全第一的考虑，必要的数据流程和权限申请管理是必不可少的。
大多数企业的数据操作都是针对非生产数据进行的，生产数据都是作为原始数据进行保存，然后将原始数据同步到附属库或丛库的库表中进行操作。保存至少一份原始数据是保证数据在任何时间都处于高可用状态的前提。
3.?技术研发类
技术研发类规范主要用于在团队协作开发的情况下，保证架构、编码、测试等各个研究环节的一致性、可读性、可重用性、程序健壮性、可移植性、可维护性。该规范是提高团队协作开发效率和软件质量的必要保障，也是降低后期维护成本的重要举措。
技术研发类规范从流程上可分为两大类：
（1）文档规范
技术研发过程中，需要根据不同的项目撰写相应的研发文档，包括概要设计文档、详细开发文档、质量校验文档、集成测试文档等，这些文档是日后进行技术研发的基础。文档需要详细记录产品的研发背景、蓝图、目的、原则、阶段、里程碑、排期、内容、约束和前置条件、沟通计划、机会风险等，其阅读对象是项目成员以及相关的研发工程师。该类文档是项目执行的参考，为项目按时交付、项目测试、质量跟踪以及后续开发等提供了书面依据。除了面向技术研发的文档规范外，还有一类面向客户的文档规范，这些信息会在“项目产品类”规范中具体介绍。
（2）代码规范
代码规范是面向技术研发人员在产品或系统开发时具体实施的操作性规范，它涉及开发过程中撰写代码时的各个方面。规范主要涉及的内容包括：
文件结构，包括头文件、定义文件、其他文件的路径、目录、结构等具体定义；
程序风格，包括空行、空格、缩进、续行等定义，这是通过逻辑关联分组、组之间的关系，提高可读性的保障；
命名规范，比较著名的命名规则当推“匈牙利”命名法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。命名规范中包含了对库、包、类、域、方法和声明的具体定义；
注释规范，包括文本注释、块注释和单行注释的注释内容、方式、位置等约束，对于文件头和函数头的注释内容包括功能、参数、返回值、设计思想、调用函数、日期、修改记录、设计者信息；
类、函数和方法，包括对象本身的参数和返回值，对象相关的声明格式、可选元素、类体成员、类内成员顺序、方法释义、影射关系、引用等；
错误处理：对于可能出现的错误信息的提示方法、处理过程和逻辑的定义；
兼容性规范：对于程序开发过程中涉及同一程序或语言由于版本不同可能导致的兼容性或功能问题，以及适配周边系统环境的兼容性问题的处理；
资源调用：区分Debug版本和Release版本，同时对系统软硬件资源进行配置，例如指针、资源释放等。
在项目建立之初，通常所有的文档规范就需要制定好，这些规范或材料通常会通过知识中心或知识库作统一管理，这些知识库或知识中心可以集成到SVN、Bug管理工具、Wiki工具、知识管理系统以及其他项目管理工具或公司系统中，以便于知识和制度共享以及信息发布。
4.?项目产品类
项目产品类的规范和制度主要针对项目实施和产品实施的整个项目制定的相关规范。项目产品类的规范和文档的主要对象是项目中不同阶段的参与人员，包括项目、产品、设计、开发、运维等人员。
项目产品类规范和制度涉及每个文档生命周期的始末，从创建、审批、发布、变更、分发、追缴、归档、废止到恢复等。
常见的项目文档通常分为4个阶段分别进行定义：
（1）立项前的市场分析类
立项前的市场分析类文档通常包括市场调研报告、可行性报告、风险评估报告等。这三份报告都是针对市场调查、收集、整理和分析后，结合市场规模、特点、容量等对项目的可行性、前景、利弊、机会进行分析，常用的维度包括宏观环境、竞争对手、自身情况、目标客户等，分析模型包括SWOT、PEST、STP、4P、4C、波士顿矩阵、五力模型、生命周期模型等，分析方法包括系统分析法、结构分析法、演绎分析法、定量与定性分析法、案例分析法、复合分析法等。
（2）立项后的规划分析类
立项后的规划分析类主要指的是在项目立项后，为了整体项目的开展而进行的整体规划和分析工作，通常产出物为项目开发计划文档。项目开发计划中通常涉及对项目前景、主要内容、参与范围和人员、人员角色定位与分工、计划实施分解和进度跟踪、关键里程碑及产出交付物、前置和约束条件、预期和最晚交付时间、验收标准和评审、成本和预算评估、风险评估和控制等。制订开发计划需要不断细化和丰富，开发计划是项目经理管理和跟踪的依据，可起到指导项目组的整体进度调控和日常工作跟踪的作用。当实际开发情况与开发计划偏离较大时，应修正开发计划或实际开发情况。
（3）实施中的开发规范类
项目开发实施过程中，在不同阶段涉及不同的文档和规范，从实施的阶段来划分可分为产品类文档、技术研发类文档、测试类文档三类。
产品类文档包括软件/产品需求说明书、UI/UE设计规范、用户交互设计规范等。
技术研发类文档在2.3.2节中有具体解释，在此不再赘述。
测试类文档包括测试计划书、测试评估报告、问题追踪报告等。
（4）实施后的验收类
项目实施完成，通常需要交付一系列文档，可能包括软件/产品验收报告、项目总结报告、运营管理手册、软件质量保证计划书、用户操作手册、帮助文档和FAQ等。
除此以外，项目进行过程中，会贯穿着多种项目跟踪类报告，包括开发进度月报、阶段性总结报告等，这些报告根据实际排期和里程碑计划情况安排即可。
对于项目文档的管理，可以使用SVN，但通常更多的是使用专门的项目文档管理系统，例如VSS、HFS、TeamOff?ice、SharePoint等。但采用何种工具，具体根据企业需求和实际情况进行选择即可，适合的才是最好的。
5.?数据挖掘、分析和应用类
数据挖掘、分析和应用类规范是针对开展数据工作中，涉及非技术开发类的数据挖掘、分析和应用类的流程和方法而制定的规范，其目的是保证数据工作的及时性、有效性，以及结果的正确性和可应用性。
按照数据工作的项目流程，通常分为需求沟通、需求提报、商业理解、数据准备、数据挖掘（含分析）、部署实施6个阶段，如图2-6所示。整个过程应该通过一定的工具和流程规范进行控制和集中管理，否则数据工作就会失控并且毫无落地价值可言。
（1）需求沟通
需求沟通已经在数据需求管理中提到，不合理或不可行的需求将被直接驳回。正常情况下，需求沟通当天应该反馈沟通结果。对于需求中由于主客观原因无法实现的、错误的需求，无法落地的需求以及重复需求应该予以驳回。在这个过程中，建议采用数据对接人制度，将不同业务部门负责数据对接工作的人员固定下来。
很多时候业务需求不能落地，例如数据提取工作只是为了验证工作效果，对于此类简单的需求需要通过培训、开放权限等方法让业务自行实现。数据部门不应该把时间浪费在这种价值太低的工作上。
（2）需求提报
在需求提报阶段，不符合公司利益或可能对公司产品产生负面影响的需求也将被驳回。需求提报和审批根据不同企业的流程复杂程度和实际审批效率而定，通常在1～7天之内完成。当续期需求中涉及公司敏感性指标、较高的数据权限、加密和解密处理、外部数据处理请求等特殊内容时，通常需要通过公司内部OA类系统进行申报和审批。
数据需求提报管理是数据需求审核中不可或缺的步骤，在很多大型企业中往往是企业级流程管理的重要部分。需求提报管理过程中，企业领导层从企业全局的角度把控数据需求是否合理，其决策关乎整个公司而非数据部门。
（3）商业理解
商业理解是将业务语言转化为数据语言的过程，目的是确定业务预期效果的维度、范围等，这个阶段通常需要2～3天的工作时间。商业理解阶段包括两部分内容：
商业理解沟通：数据部门理解业务部门具体需求的过程。
数据思路沟通：数据部门将业务理解转化为数据分析和挖掘思路的过程。
本阶段的产出是数据分析和挖掘工作思路，通常以思维导图的形式输入并加以沟通确认。如图2-7所示为渠道画像分析思路。
（4）数据准备
数据准备是对即将进行的分析和挖掘工作进行预处理，包括从数据仓库中取数、验证数据质量、数据特征提取、异常值处理、数据转换和合并等，为后期的数据分析挖掘做准备。这个阶段是费时但非常重要的工作，前期这个工作做不好会直接影响数据质量，从而影响结果的可信度及稳定程度。
该项工作通常需要1～4天的工作时间，根据原始数据质量及数据量级的不同而有所差异。阶段性数据产出结果为数据质量报告以及清洗之后的数据。
数据准备是数据工作中的难点，很多时候由于原始数据质量较差或数据从业者自身工作经验和能力不足，导致大量时间耗费在数据准备和清洗阶段，使得后期数据价值挖掘的投入精力不足，从而影响数据结果和价值产出。因此，这个阶段一定要在保证数据质量的基础上缩减投入时间。
（5）数据挖掘（含分析）
经过前期的各项准备工作，接下来就开始了数据工作的核心环节——专项分析和挖掘工作，包括常用的描述性数据统计方法，LDA、PCA等数据预处理和转换方法，时间序列、分类、聚类、回归、关联和序列关联、规则提取等传统数据挖掘和建模方法，以及协同过滤、神经网络、深度学习、自然语言处理等监督式和非监督式学习算法等，并在专项分析或建模结束后完成模型测试和评估工作，以保持模型的稳定性和最佳拟合度。
本阶段通常需要至少一周的时间，产出结果包括数据挖掘流、数据挖掘报告等。在报告中需要对数据挖掘的背景、数据选取和处理方法、异常值处理措施、数据建模主要流程、数据挖掘结果评估和解读说明等内容进行描述。这也是规范数据挖掘工作的必要措施。
（6）部署实施
部署实施包括数据结果沟通、制定落地方案、业务落地执行、数据再优化四个阶段。
数据结果沟通：结果沟通可能通过邮件、会议等方式开展，沟通的内容主要是围绕业务需求和数据结果，还包括对数据结论的进一步深入讨论。
制定落地方案：在沟通过程中需要有落地方案的制定部分，即根据数据结论和建议确定下一步工作计划和排期。
业务落地执行：根据业务制定的落地方案跟进实施，实施过程中同步监测数据反馈结果。
数据再优化：针对执行结果做模型和数据结论的调整优化，从而不断迭代项目进程，直至达到理想业务目标或业务预期。
在整个项目结束后通常会进行项目总结，总结内容包括前期需求沟通是否清晰，中期数据处理、分析和挖掘存在哪些可优化点，后期数据落地效果和协作流程改进等。
不是所有的项目都以成功结束，很多时候由于主客观原因导致项目失败。但项目失败也是一种知识成长的过程，此时更应该与业务部门一起深入总结，以避免日后出现类似的失败问题。
本阶段的时间大概为2周左右，具体以业务落地执行时间为主。产出结果包括业务落地计划方案、落地执行结果评估报告等。
2.3.3 制度和流程规范模板
由于不同的制度具有不同的内容指向性，因此不同类型的文档规范的内容主题不同。对于不同类型的规范和制度，通常规范会涉及以下几个方面：
1.?页眉
页眉信息英语封面（如果有）应与正文部分相同，由公司名称或Logo、制度编号、制度名称及发布日期组成。制作页眉时需要注意以下几点：
文字格式：统一使用一种格式，通常使用宋体五号字。
制度编号：由中心简称、部门简称和分类顺序号三部分组成，由相应的管理部门在制度发布时统一编制并添加。
制度名称与封面页顶端所注标题一致。
发布日期以公司制度审批最高层签发日期为准，由管理部门在制度发布时标注。
2.?页脚
页脚信息应与封面、正文部分相同，其内容及形式固定，制度起草部门不应擅自修改，具体内容为页码信息，如“第×页共×页”，为了提高规范或文档的保密性，还可增加一些版权或禁止类信息，例如“内部资料严禁外传”，且其字体格式应该与页眉保持一致。
3.?封面
封面包括标题、文本框及目录三部分内容。制度标题结构为“管理主题管理制度”，后面标注版本号，例如数据库管理制度V1.2。制度名称应明确体现制度规范的主要事项，使之与其他制度相区分，同时应力求简练，不应涉及不必要的细节。
制度名称一栏字体必须具有统一的格式要求，例如“黑体，小四，加粗”。
文本框行和列需要固定，例如可做成两行三列的表格，包括版本号、附件数、密级、撰写人、审核人、审批人六项内容。前四项由制定部门根据实际情况填写，审核人、审批人栏由管理部门在发布制度时填写，审核人根据审批单情况填写，审批人栏填写最高制度审批层电子签名。
目录部分的“目录”两字居中排列，字体应统一，例如“宋体，五号，加粗”；目录正文根据制度正文中的一级标题和二级标题自动生成，字体统一为宋体五号。正文部分进行修改后，应同时更新相应目录。
通过Word中的引用功能来生成目录是一个维护目录和内容一致性的有效方法。
4.?正文
制度正文包含目的、范围、名词解释、职责、管理制度、工作流程、注意事项、附件八部分内容。
目的（必备）：简要说明制度出台所需要解决的问题，或要达到的目标，以及制度的作用和意义。
范围（必备）：说明制度的适用范围（适用于哪些部门、人员、事项及工作环节）和发布范围（制度需要在哪些部门、区域或人员范围内发布）。
名词解释（可选）：主要对制度中出现的专有名词进行解释或界定范围，以便大家准确理解。一般包括需要相关知识、技术背景或工作经历的人才能理解的专业术语，以及使用中有不唯一确定含义的词语和其他特定含义的用语。
职责（必备）：主要确定制度中各事项、环节的实施主体部门、岗位，以及与此相关的其他部门、岗位的分工、各自的权限和相互间的协调关系。
管理制度（必备）：管理内容和管理方式是管理制度的主体内容。管理内容与要求主要规定该制度管理的业务内容、工作标准及具体要求、信息反馈的渠道、时间等；管理方式主要规定对管理事项执行检查、考核的负责部门、内容、程序、时间、方法等。
工作流程（必备）：对制度涉及的特定业务工作的流程予以详细描述，必要时可以辅以流程示意图或标准流程图。
注意事项（可选）：对制度理解与贯彻执行中的需要予以特别强调、提起重视或有特殊要求、须格外注意的问题做出说明，例如制度的生效或实施日期、制度的执行部门、解释权限等。
附件（可选）：附件即为制度内容中所要求的相应记录及管理表单（空白模版），须为公司其他管理制度文件中所未包含的。制度内容中首次引用附件时，需在该附件名称后作“（见附件×）”标注。
正文部分各部分序号使用多级列表形式，一级列表顶格排列，以下一般依次缩进2字节。
正文中一级标题一般设置为“标题1”样式，制度的主要、重点部分的二级标题可以设置为“标题2”样式，以便在目录中引用。正文部分字体需统一（例如统一使用宋体五号字，标题加粗，段落设置段前段后均为0，行间距一律为1.4倍）。
5.?附件
附件应按文中所列顺序置于正文之后，一般情况下各附件独立排列。对于管理制度的附件通常包括管理汇总信息表和新增管理内容表两部分。
6.?附录
其他需要体现在制度中的特定内容或指导信息。
