精华内容
下载资源
问答
  • 为了提高煤矿企业安全管理水平,...从本质安全的概念引出本质安全体系建设意义,展开叙述本质安全研究的主要内容,给出了煤炭企业应该如何建设本质安全管理体系的答案,研究出了一套煤炭企业建设本质安全管理体系方法。
  • 阐述了深化企业安全生产诚信体系建设重要意义,介绍了企业安全生产诚信体系建设过程中的经验做法,针对目前已建立的企业安全生产公示和承诺、诚信报告、诚信档案和诚信缺失企业"黑名单"等相关措施,就进一步深化制度...
  • 为了推进企业风险防控体系建设,提高企业管理水平,使企业管理者充分认识到风险防控体系建设对于企业可持续发展的重要意义,特别是对于煤炭企业而言,近年来市场疲软,价格下跌,企业经营风险、资金风险集聚,做好风险防控...
  • 根据财政部"十二五"时期稳步推进内部控制规范体系建设的相关要求,结合COSO的理论框架及煤炭企业生产经营实际情况,提出了基于信息技术的煤炭企业内部控制体系结构框架,并对三大系统进行了详细介绍。该研究对指导我国...
  • 互联网企业数据安全体系建设

    千次阅读 2020-06-25 09:05:34
    但是全球的趋势是越来越重视隐私,在安全领域中,数据安全这个子领域也重新被提到了一个新的高度,所以笔者就借机来说一下数据安全建设。(按照惯例,本文涉及敏感信息的部分会进行省略处理或者一笔带过。) 二、...

    一、背景

    Facebook数据泄露事件一度成为互联网行业的焦点,几百亿美元市值瞬间蒸发,这个代价足以在地球上养活一支绝对庞大的安全团队,甚至可以直接收购几家规模比较大的安全公司了。

    虽然媒体上发表了很多谴责的言论,但实事求是地讲,Facebook面临是一个业界难题,任何一家千亿美元的互联网公司面对这种问题,可能都没有太大的抵抗力,仅仅是因为全球区域的法律和国情不同,暂时不被顶上舆论的浪尖罢了。但是全球的趋势是越来越重视隐私,在安全领域中,数据安全这个子领域也重新被提到了一个新的高度,所以笔者就借机来说一下数据安全建设。(按照惯例,本文涉及敏感信息的部分会进行省略处理或者一笔带过。)

    二、概念

    这里特别强调一下,“隐私保护”和“数据安全”是两个完全不同的概念,隐私保护对于安全专业人员来说是一个更加偏向合规的事情,主要是指数据过度收集和数据滥用方面对法律法规的遵从性,对很多把自身的盈利模式建立在数据之上的互联网公司而言,这个问题特别有挑战。有些公司甚至把自己定义为数据公司,如果不用数据来做点什么,要么用户体验大打折扣,要么商业价值减半。GDPR即将实施,有些公司或将离场欧洲,就足见这件事的难度不容小觑。当然市场上也有一些特别推崇隐私保护的公司,他们很大程度上并不能真正代表用户意愿,而只是因为自家没有数据或缺少数据,随口说说而已。

    数据安全是实现隐私保护的最重要手段之一。对安全有一定了解的读者可能也会察觉到,数据安全并不是一个独立的要素,而是需要连同网络安全、系统安全、业务安全等多种因素,只有全部都做好了,才能最终达到数据安全的效果。所以本文尽可能的以数据安全为核心,但没有把跟数据安全弱相关的传统安全体系防护全部列出来,对于数据安全这个命题而言尽可能的系统化,又避免啰嗦。另外笔者也打算在夏季和秋季把其他子领域的话题单独成文,譬如海量IDC下的入侵防御体系等,敬请期待。

    三、全生命周期建设

    尽管业内也有同学表示数据是没有边界的,如果按照泄露途径去做可能起不到“根治”的效果,但事实上以目前的技术是做不到无边界数据安全的。下图汇总了一个全生命周期内的数据安全措施:

    四、数据采集

    数据泄露有一部分原因是用户会话流量被复制,尽管有点技术门槛,但也是发生频率比较高的安全事件之一,只是是很多企业没有感知到而已。下面从几个维度来说明数据采集阶段的数据保护。

    流量保护

    全站HTTPS是目前互联网的主流趋势,它解决的是用户到服务器之间链路被嗅探、流量镜像、数据被第三方掠走的问题。这些问题其实是比较严重的,比如电信运营商内部偶有舞弊现象,各种导流劫持插广告(当然也可以存数据,插木马),甚至连AWS也被劫持DNS请求,对于掌握链路资源的人来说无异于可以发动一次“核战争”。即使目标对象IDC入侵防御做的好,攻击者也可以不通过正面渗透,而是直接复制流量,甚至定向APT,最终只是看操纵流量后达到目的的收益是否具有性价比。

    HTTPS是一个表面现象,它暗示着任何互联网上未加密的流量都是没有隐私和数据安全的,同时,也不是说有了HTTPS就一定安全。HTTPS本身也有各种安全问题,比如使用不安全的协议TLS1.0、SSL3,采用已经过时的弱加密算法套件,实现框架安全漏洞如心脏滴血,还有很多的数字证书本身导致的安全问题。

    全站HTTPS会带来的附带问题是CDN和高防IP。历史上有家很大的互联网公司被NSA嗅探获取了用户数据,原因是CDN回源时没有使用加密,即用户浏览器到CDN是加密的,但CDN到IDC源站是明文的。如果CDN到源站加密就需要把网站的证书私钥给到CDN厂商,这对于没有完全自建CDN的公司而言也是一个很大的安全隐患,所以后来衍生出了Keyless CDN技术,无需给出自己的证书就可以实现CDN回源加密。

    广域网流量未加密的问题也要避免出现在“自家后院”——IDC间的流量复制和备份同步,对应的解决方案是跨IDC流量自动加密、TLS隧道化。

    业务安全属性

    在用户到服务器之间还涉及两个业务安全方向的问题。第一个问题是账号安全,只要账号泄露(撞库&爆破)到达一定数量级,把这些账号的数据汇总一下,就必定可以产生批量数据泄露的效果。

    第二个问题是反爬,爬虫的问题存在于一切可通过页面、接口获取数据的场合,大概1小时爬个几百万条数据是一点问题都没有的,对于没有彻底脱敏的数据,爬虫的效果有时候等价于“黑掉”服务器。账号主动地或被动地泄露+爬虫技术,培育了不少黑产和数据获取的灰色地带。

    UUID

    UUID最大的作用是建立中间映射层,屏蔽与真实用户信息的关系链。譬如在开放平台第三方应用数据按需自主授权只能读取UUID,但不能直接获取个人的微信号。更潜在的意义是屏蔽个体识别数据,因为实名制,手机号越来越能代表个人标识,且一般绑定了各种账号,更改成本很高,找到手机号就能对上这个人,因此理论上但凡带有个体识别数据的信息都需要“转接桥梁”、匿名化和脱敏。譬如当商家ID能唯一标识一个品牌和店名的时候,这个原本用于程序检索的数据结构也一下子变成了个体识别数据,也都需要纳入保护范畴。

    五、前台业务处理

    鉴权模型

    在很多企业的应用架构中,只有在业务逻辑最开始处理的部分设置登录态校验,后面的事务处理不再会出现用户鉴权,进而引发了一系列的越权漏洞。事实上越权漏洞并不是这种模型的全部危害,还包括各种K/V、RDS(关系型数据库)、消息队列等等,RPC没有鉴权导致可任意读取的安全问题。

    在数据层只知道请求来自一个数据访问层中间件,来自一个RPC调用,但完全不知道来自哪个用户,还是哪个诸如客服系统或其他上游应用,无法判断究竟对当前的数据(对象)是否拥有完整的访问权限。绝大多数互联网公司都用开源软件或修改后的开源软件,这类开源软件的特点是基本不带安全特性,或者只具备很弱的安全特性,以至于完全不适用于海量IDC规模下的4A模型(认证、授权、管理、审计)。外面防御做的很好,而在内网可以随意读写,这可能是互联网行业的普遍现状了。主要矛盾还是鉴权颗粒度和弹性计算的问题,关于这个问题的解决方案可以参考笔者的另外一篇文章《初探下一代网络隔离与访问控制》,其中提到Google的方法是内网RPC鉴权,由于Google的内网只有RPC一种协议,所以就规避了上述大多数安全问题。

    对于业务流的鉴权模型,本质上是需要做到Data和App分离,建立Data默认不信任App的模型,而应用中的全程Ticket和逐级鉴权是这种思想下的具体实现方法。

    服务化

    服务化并不能认为是一个安全机制,但安全却是服务化的受益者。我们再来温习一下当年Bezos在Amazon推行服务化的一纸号令:

    1)所有团队今后将通过服务接口公开他们的数据和功能。 2)团队必须通过这些接口相互通信。 3)不允许使用其他形式的进程间通信:不允许直接链接,不允许直接读取其他团队的数据存储,不支持共享内存模式,无后门。唯一允许的通信是通过网络上的服务接口调用。 4)他们使用什么技术并不重要。HTTP,Corba,Pubsub,自定义协议 - 无关紧要。贝索斯不在乎。 5)所有服务接口无一例外都必须从头开始设计为可外部化。也就是说,团队必须规划和设计能够将接口展示给外部开发人员。没有例外。 6)任何不这样做的人都会被解雇。

    服务化的结果在安全上的意义是必须通过接口访问数据,屏蔽了各种直接访问数据的途径,有了API控制和审计就会方便很多。

    内网加密

    一些业界Top的公司甚至在IDC内网里也做到了加密,也就是在后台的组件之间的数据传输都是加密的,譬如Goolge的RPC加密和Amazon的TLS。由于IDC内网的流量比公网大得多,所以这里是比较考验工程能力的地方。对于大多数主营业务迭代仍然感觉有压力的公司而言,这个需求可能有点苛刻了,所以笔者认为用这些指标来衡量一家公司的安全能力属于哪一个档位是合理的。私有协议算不算?如果私有协议里不含有标准TLS(SHA256)以上强度的加密,或者只是信息不对称的哈希,笔者认为都不算。

    数据库审计

    数据库审计/数据库防火墙是一个入侵检测/防御组件,是一个强对抗领域的产品,但是在数据安全方面它的意义也是明显的:防止SQL注入批量拉取数据,检测API鉴权类漏洞和爬虫的成功访问。

    除此之外,对数据库的审计还有一层含义,是指内部人员对数据库的操作,要避免某个RD或DBA为了泄愤,把数据库拖走或者删除这种危险动作。通常大型互联网公司都会有数据库访问层组件,通过这个组件,可以审计、控制危险操作。

    六、数据存储

    数据存储之于数据安全最大的部分是数据加密。Amazon CTO Werner Vogels曾经总结:“AWS所有的新服务,在原型设计阶段就会考虑到对数据加密的支持。”国外的互联网公司中普遍比较重视数据加密。

    HSM/KMS

    业界的普遍问题是不加密,或者加密了但没有使用正确的方法:使用自定义UDF,算法选用不正确或加密强度不合适,或随机数问题,或者密钥没有Rotation机制,密钥没有存储在KMS中。数据加密的正确方法本身就是可信计算的思路,信任根存储在HSM中,加密采用分层密钥结构,以方便动态转换和过期失效。当Intel CPU普遍开始支持SGX安全特性时,密钥、指纹、凭证等数据的处理也将以更加平民化的方式使用类似Trustzone的芯片级隔离技术。

    结构化数据

    这里主要是指结构化数据静态加密,以对称加密算法对诸如手机、身份证、银行卡等需要保密的字段加密持久化,另外除了数据库外,数仓里的加密也是类似的。比如,在 Amazon Redshift 服务中,每一个数据块都通过一个随机的密钥进行加密,而这些随机密钥则由一个主密钥进行加密存储。用户可以自定义这个主密钥,这样也就保证了只有用户本人才能访问这些机密数据或敏感信息。鉴于这部分属于比较常用的技术,不再展开。

    文件加密

    对单个文件独立加密,一般情况下采用分块加密,典型的场景譬如在《互联网企业安全高级指南》一书中提到的iCloud将手机备份分块加密后存储于AWS的S3,每一个文件切块用随机密钥加密后放在文件的meta data中,meta data再用file key包裹,file key再用特定类型的data key(涉及数据类型和访问权限)加密,然后data key被master key包裹。

    文件系统加密

    文件系统加密由于对应用来说是透明的,所以只要应用具备访问权限,那么文件系统加密对用户来说也是“无感知”的。它解决的主要是冷数据持久化后存储介质可访问的问题,即使去机房拔一块硬盘,或者从一块报废的硬盘上尝试恢复数据,都是没有用的。但是对于API鉴权漏洞或者SQL注入而言,显然文件系统的加密是透明的,只要App有权限,漏洞利用也有权限。

    七、访问和运维

    在这个环节,主要阐述防止内部人员越权的一些措施。

    角色分离

    研发和运维要分离,密钥持有者和数据运维者要分离,运维角色和审计角色要分离。特权账号须回收,满足最小权限,多权分立的审计原则。

    运维审计

    堡垒机(跳板机)是一种针对人肉运维的常规审计手段,随着大型IDC中运维自动化的加深,运维操作都被API化,所以针对这些API的调用也需要被列入审计范畴,数量级比较大的情况下需要使用数据挖掘的方法。

    工具链脱敏

    典型的工具脱敏包括监控系统和Debug工具/日志。在监控系统类目中,通常由于运维和安全的监控系统包含了全站用户流量,对用户Token和敏感数据需要脱敏,同时这些系统也可能通过简单的计算得出一些运营数据,譬如模糊的交易数目,这些都是需要脱敏的地方。在Debug方面也出过Debug Log带有CVV码等比较严重的安全事件,因此都是需要注意的数据泄漏点。

    生产转测试

    生产环境和测试环境必须有严格定义和分离,如特殊情况生产数据需要转测试,必须经过脱敏、匿名化。

    八、后台数据处理

    数仓安全

    目前大数据处理基本是每个互联网公司的必需品,通常承载了公司所有的用户数据,甚至有的公司用于数据处理的算力超过用于前台事务处理的算力。以Hadoop为代表的开源平台本身不太具备很强的安全能力,因此在成为公有云服务前需要做很多改造。在公司比较小的时候可以选择内部信任模式,不去过于纠结开源平台本身的安全,但在公司规模比较大,数据RD和BI分析师成千上万的时候,内部信任模式就需要被抛弃了,这时候需要的是一站式的授权&审计平台,需要看到数据的血缘继承关系,需要高敏数据仍然被加密。在这种规模下,工具链的成熟度会决定数据本地化的需求,工具链越成熟数据就越不需要落到开发者本地,这样就能大幅提升安全能力。同时鼓励一切计算机器化&程序化&自动化,尽可能避免人工操作。

    对于数据的分类标识、分布和加工,以及访问状况需要有一个全局的大盘视图,结合数据使用者的行为建立“态势感知”的能力。

    因为数仓是最大的数据集散地,因此每家公司对于数据归属的价值观也会影响数据安全方案的落地形态:放逐+检测型 or 隔离+管控型。

    匿名化算法

    匿名化算法更大的意义其实在于隐私保护而不在于数据安全(关于隐私保护部分笔者打算另外单独写一篇),如果说对数据安全有意义,匿名化可能在于减少数据被滥用的可能性,以及减弱数据泄漏后的影响面。

    九、展示和使用

    这个环节泛指大量的应用系统后台、运营报表以及所有可以展示和看到数据的地方,都可能是数据泄露的重灾区。

    展示脱敏

    对页面上需要展示的敏感信息进行脱敏。一种是完全脱敏,部分字段打码后不再展示完整的信息和字段,另一种是不完全脱敏,默认展示脱敏后的信息,但仍然保留查看明细的按钮(API),这样所有的查看明细都会有一条Log,对应审计需求。具体用哪种脱敏需要考虑工作场景和效率综合评估。

    水印

    水印主要用在截图的场景,分为明水印和暗水印,明水印是肉眼可见的,暗水印是肉眼不可见暗藏在图片里的识别信息。水印的形式也有很多种,有抵抗截屏的,也有抵抗拍照的。这里面也涉及很多对抗元素不一一展开。

    安全边界

    这里的边界其实是办公网和生产网组成的公司数据边界,由于办公移动化程度的加深,这种边界被进一步模糊化,所以这种边界实际上是逻辑的,而非物理上的,它等价于公司办公网络,生产网络和支持MDM的认证移动设备。对这个边界内的数据,使用DLP来做检测,DLP这个名词很早就有,但实际上它的产品形态和技术已经发生了变化,用于应对大规模环境下重检测,轻阻断的数据保护模式。

    除了DLP之外,整个办公网络会采用BeyondCorp的“零信任”架构,对整个的OA类应用实现动态访问控制,全面去除匿名化访问,全部HTTPS,根据角色最小权限化,也就是每个账号即使泄露能访问到的也有限。同时提高账号泄露的成本(多因素认证)和检测手段,一旦检测到泄露提供远程擦除的能力。

    堡垒机

    堡垒机作为一种备选的方式主要用来解决局部场景下避免操作和开发人员将敏感数据下载到本地的方法,这种方法跟VDI类似,比较厚重,使用门槛不高,不适合大面积普遍推广。

    十、共享和再分发

    对于业务盘子比较大的公司而言,其数据都不会是只在自己的系统内流转,通常都有开放平台,有贯穿整个产业链的上下游数据应用。Facebook事件曝光其实就属于这类问题,不开放是不可能的,因为这影响了公司的内核—-赖以生存的商业价值。

    所以这个问题的解决方案等价于:1)内核有限妥协(为保障用户隐私牺牲一部分商业利益);2)一站式数据安全服务。

    防止下游数据沉淀

    首先,所有被第三方调用的数据,如非必要一律脱敏和加密。如果部分场景有必要查询明细数据,设置单独的API,并对账号行为及API查询做风控。

    其次如果自身有云基础设施,公有云平台,可以推动第三方上云,从而进行(1)安全赋能,避免一些因自身能力不足引起的安全问题;(2)数据集中化,在云上集中之后利于实施一站式整体安全解决方案(数据加密,风控,反爬和数据泄露检测类服务),大幅度降低外部风险并在一定程度上降低作恶和监守自盗的问题。

    反爬

    反爬在这里主要是针对公开页面,或通过接口爬取的信息,因为脱敏这件事不可能在所有的环节做的很彻底,所以即便通过大量的“公开”信息也可以进行汇聚和数据挖掘,最终形成一些诸如用户关系链,经营数据或辅助决策类数据,造成过度信息披露的影响。

    授权审核

    设置专门的团队对开放平台的第三方进行机器审核及人工审核,禁止“无照经营”和虚假三方,提高恶意第三方接入的门槛,同时给开发者/合作方公司信誉评级提供基础。

    法律条款

    所有的第三方接入必须有严格的用户协议,明确数据使用权利,数据披露限制和隐私保护的要求。像GDPR一样,明确数据处理者角色和惩罚条约。

    十一、数据销毁

    数据销毁主要是指安全删除,这里特别强调是,往往数据的主实例容易在视野范围内,而把备份类的数据忽略掉。 如果希望做到快速的安全删除,最好使用加密数据的方法,因为完整覆写不太可能在短时间内完成,但是加密数据的安全删除只要删除密钥即可。

    十二、数据的边界

    数据治理常常涉及到“边界”问题,不管你承不承认,边界其实总是存在的,只不过表达方式不一样,如果真的没有边界,也就不存在数据安全一说。

    企业内部

    在不超越网络安全法和隐私保护规定的情况下,法律上企业对内部的数据都拥有绝对控制权,这使得企业内部的数据安全建设实际上最后会转化为一项运营类的工作,挑战难度也无非是各个业务方推动落地的成本。但对规模比较大的公司而言,光企业内部自治可能是不够的,所以数据安全会衍生出产业链上闭环的需求。

    生态建设

    为了能让数据安全建设在企业内部价值链之外的部分更加平坦化,大型企业可能需要通过投资收购等手段获得上下游企业的数据控制权及标准制定权,从而在大生态里将自己的数据安全标准推行到底。如果不能掌控数据,数据安全也无从谈起。在话语权不足的情况下,现实选择是提供更多的工具给合作方,也是一种数据控制能力的延伸。

    十三、ROI和建设次第

    对于很多规模不大的公司而言,上述数据安全建设手段可能真的有点多,对于小一点公司即便什么事不干可能也消化不了那么多需求,因为开源软件和大多数的开发框架都不具备这些能力,需要DIY的成分很高,所以我们梳理一下前置条件,优先级和ROI,让数据安全这件事对任何人都是可以接受的,当然这种情况其实也对应了一些创业空间。

    基础

    账号、权限、日志、脱敏和加密这些都是数据安全的基础。同时还有一些不完全是基础,但能体现为优势的部分:基础架构统一,应用架构统一,如果这两者高度统一,数据安全建设能事半功倍。

    日志收集

    日志是做数据风控的基础,但这里面也有两个比较重要的因素:

    1. 办公网络是否BeyondCorp化,这给数据风控提供了极大地便利。
    2. 服务化,所有的数据调用皆以API的形式,给日志记录提供了统一的形式。

    数据风控

    在数据安全中,“放之四海皆准”的工作就是数据风控,适用于各类企业,结合设备信息、账号行为、查询/爬(读)取行为做风控模型。对于面向2C用户类,2B第三方合作类,OA员工账号类都是适用的。具体的策略思想笔者打算在后续文章《入侵防御体系建设》中详细描述。

    作者简介

    赵彦,现任美团集团安全部高级总监,负责集团旗下全线业务的信息安全与隐私保护。加盟美团前,曾任华为云安全首席架构师,奇虎360企业安全技术总监、久游网安全总监、绿盟科技安全专家等职务。白帽子时代是Ph4nt0m Security Team的核心成员,互联网安全领域第一代资深从业者。

    关于美团安全

    美团安全部的大多数核心人员,拥有多年互联网以及安全领域实践经验,很多同学参与过大型互联网公司的安全体系建设,其中也不乏全球化安全运营人才,具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”,有受邀在Black Hat等国际顶级会议发言的讲者,当然还有很多漂亮的运营妹子。

    目前,美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等,同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系,这套体系构建于零信任架构之上,横跨多种云基础设施,包括网络层、虚拟化/容器层、Server 软件层(内核态/用户态)、语言虚拟机层(JVM/JS V8)、Web应用层、数据访问层等,并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统,努力打造成业界最前沿的内置式安全架构和纵深防御体系。

    随着美团的高速发展,业务复杂度不断提升,安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地,同时为更多的安全从业者提供一个广阔的发展平台,并提供更多在安全新兴领域不断探索的机会。

    招聘信息

    美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们,欢迎简历请发至邮箱zhaoyan17@meituan.com

    具体职位信息可参考这里:https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw

    美团安全应急响应中心MTSRC主页:security.meituan.com

    展开全文
  • 教育精品资料
  • 针对目前我国应急管理的现状,着重阐述了煤炭企业应急管理工作的必要性,根据我国矿山应急救援体系建设的特点,提出了矿山企业应急管理体系建设主要内容,并结合国家应急救援体系总体框架,分析了煤炭企业应急管理体制、...
  • 随着我国经济的持续健康...本文从基础管理、设备设施、作业环境安全与职业健康等几个方面阐述了小微企业如何实现安全生产标准化,并提出了可行性建议,对小微工贸企业的安全生产标准化创建工作具有一定的借鉴和指导意义
  • 安全运营的价值与意义 安全运营的衡量标准 安全运营之道:关注落地 安全运营之道:抓主要矛盾 安全运营之道:控制增量 安全运营之道:纵深防御 安全运营之道:关注未知 安全运营之道:实战检验 安全运营之道:全面...
  • 以世界一流企业对标分析研究模型为基础,运用技术分析工具与实案研究方法,理清世界一流企业的内涵与特征,提出3个层级22个指标的世界一流企业指标体系。参考"2018年财富世界500强排行榜采矿子榜单"、"2018年度全球40强...
  • 大数据蕴含着巨大的价值,如今众多企业已将数据视作企业的宝贵资产。然而,数据价值密度与数据总量成反比。面对巨大的数据规模,如何管理和利用数据,使其发挥价值是企业必须考虑的重要问题。大数据的价值所在使其...

         随着云计算、物联网、移动互联网等新一代信息技术的快速发展,人类产生的数据量呈指数级增长。据资料显示,2012年,全球数据量达到2.8ZB,预计到2020年,全球数据量将达到40ZB。大数据蕴含着巨大的价值,如今众多企业已将数据视作企业的宝贵资产。然而,数据价值密度与数据总量成反比。面对巨大的数据规模,如何管理和利用数据,使其发挥价值是企业必须考虑的重要问题。大数据的价值所在使其面临着隐私和安全方面的威胁。大数据治理将组织的部门、流程、人等元素与数据的整个生命周期联系在了一起,对企业数据管理和数据资产价值有着至关重要的作用。

    《DGI数据治理框架》一文将数据治理定义为“数据相关事务的决策和授权的执行”,并进一步解释为信息处理过程决策权和职责的策略,约定了由谁负责处理哪些信息,并在什么情况下采用哪种方法,以及何时来执行。首先,大数据治理是信息治理计划的一部分,这是其定位。这就要求组织在制订信息治理框架时,必须将大数据纳入其中,比如在信息治理委员会中增加数据科学家,在信息治理目标中增加大数据治理目标等。其次,大数据治理主要是数据处理的一系列相关政策的制订,这是其内涵。再次,必须优化大数据,这是大数据治理的重点。最后,大数据必须变现,这是大数据治理的目的所在。

    大数据体量大、种类繁多,且价值密度低,组织必须对其进行优化,比如定义元数据、净化大数据、实施数据生命周期管理等。看似没有任何价值的单一数据集合在一起时,会发现新的价值,这是大数据价值体现的重要途径之一。而大数据价值的体现往往会涉及数据的隐私,这就要求组织在进行大数据价值体现时,必须注重大数据的隐私处理。组织将数据视作其资产的一种,要将其转化成组织可以使用的现金,而变现的方式可以是单纯地出售数据本身,也可以是利用数据开发新业务。

    一、企业实施大数据治理的必要性

    1、企业实现数据资源在组织内部的共享和交换的需要

    目前,大部分工业企业已经完成了ERP、CRM、供应链、协同办公等企业信息化系统的建设,但是由于数据分散在众多系统中,缺乏统一的数据定义和数据分类,因此在数据使用上存在数据不标准、数据不一致、数据完整性差等问题。

    数据不标准主要表现在不同系统之间描述同一业务实体的数据定义标准不同;数据不一致主要表现在相关联业务系统的数据不同步、各应用系统间存在数据编码规则不一致的问题,还有重复编码的问题;数据完整性差表现为缺少数据实体的关键信息。企业必须对各个系统的数据源以及输出的数据资产进行统一的数据治理,实现数据在不同组织和系统内的交换与共享。只有解决了数据问题,才能实现IT价值。

    2、提升海量数据资源质量的需要

    大数据时代数据产生的价值越来越大,各企业都在探索基于大数据的相关技术和应用模式,最终目的就是挖掘数据的价值,推动企业的发展。因为数据有可能是成本,也有可能是资产,能给企业带来重要的价值,是企业宝贵的资源。如果没有数据治理,数据的质量就无法保证,数据难以成为企业的资产,既使再多的业务和技术投入也都是徒劳。数据质量低下会导致企业在IT方面的重复投入,各种应用系统的价值难以有效地发挥出来,数据的问题甚至会使得企业错失商机,损失无法估量。

    数据治理是保证数据质量的必需手段,数据治理的价值贡献在于确保数据的准确性、可获取性、安全性、适度分享和合规使用。例如,可以对数据服务涉及的计算资源、数据资源制定标准化的统一管理规范,制定涵盖主数据、数据主题、数据质量、数据安全、数据共享等数据标准体系及数据管理体系。

    3、数据驱动企业进行科学决策的需要

    当今世界进入了数据爆炸的时代,数据成为企业重要的资产。企业涉及的数据类型,包括文本、图像、音频、视频等,分为静态数据和动态数据,实时数据和非实时数据,结构化数据、半结构化数据和非结构化数据,这些数据有些来源于企业的内部信息系统及设备,有些来源于外部的供应链和社交网络。数据驱动企业的决策成为时代发展的必然。

    数据治理能使企业清楚地认识自己的优势和劣势,有利于企业提高决策的合理性,为用户提供更加优质的服务。大数据时代,企业可以通过对数据的整合和分析,从中获取对企业有用的数据。新的数据技术手段,使得信息在企业内部不同部门之间有效、快速地传递,使得不同部门之间的交流、沟通更加透明,使得企业不同的利益主体能广泛地参与决策,从而提高决策的科学性和合理性。

    4、企业整合数据资源提升竞争力的需要

    在企业的生产经营活动中会产生大量的数据,企业需要对事务性数据、机器生成数据、社交媒体数据等内外部数据进行整合,特别是对与企业重大商业利益相关的数据资源的整合、分析与利用,从而指导企业的经营与发展。

    数据技术带来的不仅是技术的更新,还有管理方式的改变,数据治理不仅局限在企业的决策层,还包含管理层和业务层,数据治理能改善企业管理层与其他利益相关者的关系,使企业变得更加敏捷和高效,更注重用户体验的提升和需求的满足。例如,为解决日常的数据收集、数据处理效率较低、数据不一致的问题,可以通过元数据管理系统,建立采集元数据和元数据关系,提升跨系统的数据交互能力以及数据整合能力,进一步提升企业的核心竞争力。

    二、企业大数据治理现状

    伴随着大数据时代的到来,企业由于早期在信息系统构建中缺乏统一的全局规划,使得其在当前数据治理体系的构建中存在着一系列的问题,如果不能有效对这些问题进行解决,以构造出完善的数据治理体系,势必会对未来企业的发展带来不利的影响。

    1、大数据时代的定义及特征

    (1)大数据时代的定义

    我国已经进入了数字经济时代,必然会产生大量数据,大数据主要是指人们在日常工作、生产、生活中通过数字化的方式进行呈现和存储。也可以很通俗地将大数据理解成为巨大的数据信息,而伴随着人们的各种需求的不断增加,这种数据量还在不断的增加。举例来说,人们通过计算机互联网对视频和新闻的观看,都不同程度地促进了大数据时代的快速形成。

    (2)大数据时代的特征

    大数据时代具有如下几个明显的特征:

    数据量大。这是大数据时代最为突出的特征,这也是大数据时代本来就是基于大量数据信息所产生的是分不开的。

    速度很快。正是由于大量数据的产生,需要不断提升信息数据处理速度,才能跟上大数据时代的要求,而如果数据处理速度难以跟上,就不能满足信息的快速传播和扩散。

    种类很多。伴随着大数据时代的到来,计算机互联网技术在人们的生活中获得了非常广泛的应用,也使得数据来源变的更加丰富,相应地,数据的种类也变的更多。

    2、大数据时代企业数据治理现状

    在大数据时代下,企业在数据治理体系的构建过程中,主要面临着如下几个突出的问题:

    (1)数据定义的缺失

    所谓数据定义的缺失,就是企业的部分业务源系统以及外部数据源缺少关键业务元素定义。这是因为企业系统开发建设的出发点大多以满足客户业务交易为主要目标,对于统计分析涉及的数据要素项的定义不够关注,因此造成部分业务源系统和外部数据源的数据定义不完备。在这种情况下,就很容易造成企业的不同部门有着不同的理解,甚至在对同一个字段的理解也会产生很大的歧义。

    (2)数据标准的差异

    我国企业的早期信息化建设过程中,其业务源系统相对是比较分散的,很少有从全局的角度进行考虑,也就使得信息孤岛的现象比较突出,也带来了有关系统的物料、客户、供应商、会计科目、指标数据的不一致。正是由于企业在数据标准之间的差异,也使得各个信息系统之间的数据很难有效进行共享,也带来了企业的信息资源利用效率难以跟上实际需求,伴随着大数据时代的到来,更加使得挑战进一步扩大。

    (3)数据更新的滞后

    在大数据时代下,虽然企业为了满足各个系统与外部数据的内部访问,都提升了访问效率,减少手工数据传输,相同的信息经常会在不同系统之间进行冗余存放,不过由于对数据的更新滞后,很容易带来冗余数据的不一致,继而产生了数据质量的问题,这也是在企业在数据治理中应该重点关注的问题。

    (4)数据管控程度不高

    企业大数据建设的最终目标是促进企业对于数据应用,最大程度发挥数据价值。因此,在当前企业大数据的治理中,人们普遍重视数据应用,围绕应用中出现的数据关联、质量管理、业务协同等进行数据治理,而忽视数据治理体系中的管理机制、控制能力以及安全与隐私保护等。

    (5)数据治理机制不健全

    在大数据环境下,数据治理的主体趋于多元化,即一个数据治理流程往往需要多方参与。例如,在数据质量管理中,问题数据的发现、反馈、修正是一个多方参与的闭环流程,参与方包括:企业数据中心(数据治理方)、数据源头单位(数据提供方)、数据用户(数据使用方)等。这种多方协同治理的业务模式,对企业大数据治理制度和流程机制提出了更高要求。

    (6)技术支撑能力不足

    企业大数据治理体系的技术支撑需要涵盖大数据管理、存储、质量、共享与开放、安全与隐私保护等多个方面,当前相应的技术研究关联性和系统性还存在欠缺,都是侧重于点,而在整体上将技术关联起来还有问题。具体来说,以金融或电信运营商行业为典型代表的传统数据治理技术,是以基于主数据、元数据、数据规范的数据仓库管理系统,可实现特定领域和类型的应用级数据质量管理。但无法满足企业大数据环境下的海量、异构、多源、全格式(结构化、半结构化和非结构化)数据的治理需求。

    三、企业大数据治理成熟度评估

    1、大数据治理模型

    基于以上概念分析,只有更好的评估企业大数据治理成熟度,才能更好的指导企业大数据治理的建设。根据实践可以将大数据治理模型理解为人与组织、策略和能力的三维架构。人与组织是数据治理的主体,涉及企业中的各个职能部门及分子等,他们分别承担着不同的治理职责。策略是大数据治理的工具,能力是大数据治理的手段。下图所示为大数据治理模型三维架构。

    具体来说,人与组织包含利益相关者、治理委员会、管理委员会和内部员工。利益相关者指组织内部和外部环境中受组织决策和行动影响的任何相关者,数据的产生者、管理者、使用者和监督者等;治理委员会是组织治理数据的最高机构,负责作出数据相关事务的决定,并将数据治理标准和措施汇报给数据的利益相关者;管理委员会负责具体实施治理委员会制定的各项数据治理决定,并将数据治理结果汇报给治理委员会;内部员工是数据治理架构中不可或缺的一部分,贯彻执行数据治理委员会和管理委员会制定的各项数据治理策略。

    策略是组织制定的所有与大数据有关的数据优化、隐私保护和数据变现的准则和规范,包括组织数据治理的使命和愿景、治理指标、数据治理规则和定义、权利与职责、控制措施。数据治理的使命和愿景包括数据治理的整体目标,给予数据利益相关者持续与跨界的数据保护和服务,不合规准则引发的问题的解决方案等;数据治理指标定义了数据治理目标的衡量方法;数据治理规则和定义包括与数据相关的政策、标准、合规要求、业务规则和数据定义等;权利和职责规定了由谁来负责制订数据相关的决策、何时实施、如何实施,以及组织和个人在数据治理策略中该做什么;控制措施主要针对数据未治理风险防范和数据治理过程中可能发生的各类风险,以及如何做好数据隐私保护。

    能力则反映了组织进行数据治理所具备的条件和水平,包括元数据管理、数据质量管理、业务流程整合、主数据管理和信息生命周期管理。元数据是描述数据的数据,即描述数据和信息资源的信息。元数据管理就是整合大数据与企业的元数据库。数据质量管理准则包括数据识别、采集、测量、提升和论证质量、整合组织数据的方法,比如具备应对非结构化数据占据数据总量绝大部分情况的能力。业务流程整合要求组织制定的大数据治理计划必须与组织的核心业务流程相匹配,以便从核心业务流程中获取大数据治理的关键支持政策。主数据管理描述了一组规程、技术和解决方案,用于维护业务数据的一致性、完整性、相关性和精确性。大数据治理需要制订将大数据整合到主数据管理环境的政策。信息生命周期管理则要求组织判断应该将何种数据保留在数据分析系统,何种数据需要存档,何种数据需要删除。

    2、大数据治理成熟度评估

    等级

    等级描述

    初始级

    a.没有定义与数据治理相关的架构和角色;

    b.没有正式的数据治理策略;

    c.不具备数据治理能力。

    基本级

    a.定义了数据治理角色和职责,管理者意识到数据治理的重要性,但对管理知识知之甚少;

    b.已有的数据治理策略已经文件化,但不具有连贯性;

    c.数据治理能力十分有限,只有很少一部分人掌握数据治理通用级别的知识。

    定义级

    a.定义了数据治理角色和职责,管理者能主动推动数据治理计划实施;

    b.数据策略已经文件化,并涵盖了针对特殊数据的治理策略;策略通过公共渠道容易获取,大多数利益相关者能够理解;

    c.具备数据治理的全部要素,一部分人知道详细的数据治理能力。

    管理级

    a.定义了完备的数据治理角色和职责,并有专门的数据质量专家,管理者能主动推动数据治理计划实施;

    b.所有的数据策略都已经文件化,并且是审计合规的,都能通过公用渠道获取,数据治理利益相关者主动关注策略的增添、更新和删除;

    c.所有定义的数据治理能力层级都有可用的方法,建立了系统化的数据治理处理流程。

    优化级

    a.定义了完备的数据治理角色和职责,管理委员会来自各个部门,拥有元数据管理小组、数据质量技能中心、主数据管理委员会等;

    b.所有的数据策略都已经文件化,并且是审计合规的,所有的数据治理利益相关者都参与了策略发展过程;制订了自动化的政策,以保证数据在整个组织内保持一致、准确和可靠;

    c.所有定义的数据治理能力层级所指定的部门和关键数据是固定的,能够在数据处于静态和动态时进行数据质量修复,数据不间断地被跟踪检查,且任何偏离标准的问题都可以立即解决。

    成熟度评估是企业大数据治理状态和能力的一种衡量方式。大数据治理模型共三个维度,具体涵盖14个评价指标。每个指标分别以5个等级来衡量其成熟度,然后再统筹考虑评价指标权重,得到组织大数据治理的整体成熟度评价。根据综合评价结果,企业大数据治理成熟度可以分为以下5个等级,即初始级、基本级、定义级、管理级和优化级。

    四、企业大数据治理框架

    1、大数据治理总体框架

    根据企业大数据治理特点和需求分析,从企业大数据应用创新的角度,企业大数据治理总体框架由九部分组成。

    (1)大数据生命周期管理

    数据生命周期是数据治理的时间轴,数据治理服务于数据的全生命周期。因此,完善的数据生命周期管理是确保数据治理有序、全面的前提条件之一。在企业大数据领域,数据生命周期管理又分为两类,一类是技术层面的数据周期管理,指按照数据加工处理时序(数据采集、数据存储、数据处理、数据建模、数据调度、数据销存)而建立的时间里程管理;另一类是业务层面的数据周期管理,指按照业务流程时序而建立的时间里程管理。

    (2)数据源管理

    以数据资源目录的功能形式,提供对待治理的数据源的管理。在功能模块上,数据源管理由两类功能组成:一是数据源部门相关的组织机构管理功能,二是数据源的目录、格式类型和交互周期等资源属性管理功能。从数据源提供的数据类型上看,企业大数据治理的对象包括结构化数据、半结构化数据和非结构化数据,以及来自互联网的数据等。

    (3)主要技术支撑

    企业大数据治理中所用的主要技术包括数据检核引擎、ETL工具、消息中间件、流程引擎、Hive和MPPDB等。相对于传统数据治理技术,专门引入了Hive和MPPDB等大数据领域的数仓工具,代替传统数仓中Oracle、MySQL等关系型数据库,以满足大规模数据的治理效率要求。另外,要特别强调的是,数据质量检核引擎的设计最具技术含量,也最为重要,它直接决定了数据检核的能力和数据质量的把控程度。因此,质量检核引擎的设计要充分响应上文中的需求分析,体现技术先进性、功能完整性、覆盖全面性、检核深度性和使用便捷性,实现良好的数据质量检查和核对功能。

    (4)贴源层治理

    贴源层治理又叫近源治理,是指在最贴近数据源头的一侧,对数据进行建模、标准化和技术检核方面的治理。贴源层治理的要点如下:

    第一,数据建模时,须按照对业务属性的影响程度,区分主数据和业务数据,以满足数据实体在业务流程、数据质量控制方面的不同要求。主数据是指对业务影响至关重要的共享数据,如组织机构、员工、会计科目、物料、供应商、客户等。同时,也要按照记录属性对数据实体识别的影响,为每个属性设计权重,区分核心和普通属性,以满足深度数据质量控制要求。

    第二,数据标准化是指按照元数据或数据元标准规范,对汇集的源头数据进行格式转换、字典映射,进行初步的数据规范。

    第三,数据检核是数据质量控制的核心举措,根据是否存在业务相关性,又分为技术检核和业务检核。其中,数据技术检核是指对数据进行不涉及业务的检查和核对。即按照数据质量标准,使用数据检核引擎,对源数据进行格式、值域、重复度、完整性、准确性等质量校核,以最大程度地发现、排除问题数据,为后续质量控制打下坚实基础。

    第四,数据质量考核评价是贴源层治理的主要输出结果,通常这个结果以数据质量报告的形式输出。数据质量报告由标准规范体系中预先定义的质量评价指标组成,用于反馈数据治理相关方,触发数据质量控制的相关业务流程。

    (5)中心层治理

    与贴源层治理相对应的是中心层治理,即在贴源层治理和数据资源中心之外的其他治理内容。中心层治理的内容包括数据关联、数据融合和数据业务检核,它们具有一个业务相关的共性特征,即治理内容与数据所属业务领域密切相关。中心层治理的要点如下:

    第一,数据关联是指基于业务主数据,将各相关数据模型串联起来,形成实体的一个全息数据画像,并通过相关属性,将这种数据间的关联关系保存起来。数据关联对于企业大数据应用实施具有决定性作用,通常可关联的数据,才是实际可用的数据。

    第二,数据融合是指在数据关联的基础上,将同类数据去重后聚合,把“一数多源”变为“一数一源”;或者将同一个实体的不同数据片段,构建形成新的、更完整的数据描述。数据融合通常面向特定应用场景,是数据应用中最为常见的数据操作之一。

    第三,数据业务检核是基于数据的业务属性进行的业务逻辑合规性检查核对。业务检核是数据质量检核中不可或缺的部分,与技术检核同等重要。以个人身份证号数据为例,技术检核仅能做到身份证号长度、格式、特定位值(地区编码、年龄)等的合规检查,而不能识别该号码的真假;业务校核则是通过把该号码与身份证登记机关的数据库相比对,确认出号码的真假。

    (6)数据资源中心

    数据资源中心是数据治理的结尾环节,进入数据资源中心的数据被认为是标准、合规、正确、可直接应用的数据。在企业大数据治理体系中,数据资源中心阶段的数据治理,侧重于数据资产的形成和管理,以及数据集的存储划分。在该框架中,以数据资产目录来统领数据资产的管理;以面向数据实体的基础数据库和面向应用的主题数据库,统一存储治理后的数据。

    (7)数据标准规范体系

    数据标准规范是实施数据治理的基础前提条件,对数据治理的成效起着决定性作用。没有标准规范,无从数据治理;标准规范不全,数据治理不全。对于企业大数据来说,要做好治理需建立健全以下规范:

    第一,元数据标准。要全面建立元数据标准,做到对全域数据的覆盖。

    第二,数据元标准。要有选择地为主要数据实体建立数据元标准。

    第三,数据分类编码标准。要为重要数据建立分类编码标准,并为基础数据建立编码字典表。

    第四,数据目录规范。要在尽可能大的范围内,建立统一的企业数据资源目录规范,在最大程度上规范目录编码和操作。

    第五,数据质量标准。要从准确性、合规性、一致性、重复性、及时性、完整性等指标角度,建立全面的数据质量标准,并给出评估指标和评估方式。

    第六,数据治理流程规范。流程化是治理有序的保障,要将数据治理流程化,建立相应的流程规范,通过流程规范提升治理有序水平。

    (8)大数据安全和隐私管理

    企业的生产经营数据价值大、敏感度高,涉及企业战略的隐私和股东的权益。因此,在企业大数据的治理中,要建立相应的治理安全管理体系,确保各治理环节的数据安全。一般情况下,数据治理要达到以下安全保护要求:

    第一,按照《工业数据分类分级指南(试行)、《信息安全等级保护管理办法》和《信息系统安全等级保护定级指南》的要求,确定数据治理系统的安全保护等级,构建安全防护体系。

    第二,针对不同信息可动态设置安全保护手段。

    第三,治理功能与组织机构和用户分级权限相结合。

    第四,提供数据签名和数据脱敏功能,确保隐私安全。

    第五,所有治理操作均有记录日志,纳入统一安全审计管理。

    (9)其他方面

    为构建自动化、智能化的数据治理平台,企业大数据治理框架还需具有追溯和可视化展示功能。追溯功能是指设置并记录数据治理的各个里程节点,可以追查数据治理的过程信息。并且在一定时效和条件下,可将某节点治理后的数据回退到其之前的任何状态。追溯功能可实现数据治理的灵活控制,利于复杂数据环境下实现智能化数据治理。具有良好可视化展示功能是先进数据治理平台的基本要求。治理可视化能带来良好的用户操作体验,便于治理工作的实施,利于人工参与治理效率的提高。

    2、企业大数据治理主要流程

    企业大数据治理的主要流程如下图所示:

    第一,数据源分析。在新的数据源接入时,首先做数据源的分析,内容包括:确认要治理的数据类别、数据项和数据周期等,抽取样例数据,分析数据特征,做好为数据治理服务的规划准备。

    第二,数据治理规划。数据治理规划分为三个步骤:(一)对样例数据进行标准规范分析,根据分析结果得出数据模型和元数据标准;(二)对样例数据进行数据质量评估,根据评估结果制定数据检核规则、关联策略和融合方案;(三)将样例数据与其他已有数据进行对比,确定数据关联和融合策略,并进一步确认数据归属(所属的基础库或主题库)。

    第三,数据标准管理。根据数据治理规划的标准规范分析结果,建立全部数据模型,以及相关元数据、主数据或数据元标准,更新相关数据标准。

    第四,数据治理策略管理。根据数据质量评估和数据对比结果,确定数据检核规则,以及建立数据关联和数据融合的策略。

    第五,常态化数据治理实施。对待治理的数据进行数据检核、数据关联和数据融合,除初次治理的数据须经前四个步骤外,同类型数据后续进入常态化治理阶段,直接从本步骤开始。

    第六,数据资源管理。将治理后的数据存入基础库或主题库,从资产的属性对数据进行资产化处理,形成数据资产,进行数据资产管理。

    五、大数据时代企业数据治理策略

    1、建立完善的数据标准体系

    在大数据时代下,企业应该根据业务管理中所涉及的渠道、合约、产品、分类、事件等数据要素,逐步建立起机构标准类、员工标准类、产品标准类、客户标准类、渠道标准类、营销标准类、账户标准类、交易标准类、公共标准类以及合约标准类数据标准体系框架。同时伴随着大数据时代的不断发展,还要对该数据标准体系进行完善,从而更加规范、科学地指导企业使用数据。

    2、制定完善的数据应用标准流程

    数据标准的核心是建立一个统一的企业级规范,从而促进企业全行范围之内的数据有机共享,继而提升数据的管理和使用水平。尤其在大数据的时代下,企业更应该根据半结构化和结构化、非结构化数据的不同特征,基于加强内外部数据共享的角度为大数据制定统一的业务解释和标准,加强协调企业的相关部门对数据标准的不同需求,继而建立其适用的统一模型以及数据共享为基础的数据应用标准流程。

    3、形成完善的数据评估体系

    在大数据时代,企业更应该加强对数据一致性、完整性以及准确性的评估,继而保证数据的使用治理。也就是:(一)提供的信息不能存在着重复和冲突的现象,以保证数据的一致性;(二)必需的数据以及关联关系务必要存在,不能出现违反数据标准和质量需求的数据,体现数据的完整性;(三)数据务必能够反映出企业的真实信息,符合企业的实际业务需求,体现出准确性的特征。

    展开全文
  • 煤炭企业作为高危行业,煤矿企业员工按章诚信作业、严格诚信监管,一切以诚信为基本原则,才能铸牢煤矿的安全防线。在介绍了安全诚信概念的基础上,给出了煤矿安全诚信的概念和要义,并分析了安全诚信管理与传统的安全...
  • 生态文明是我国"五位一体"发展...论述了煤炭企业开展生态文明建设的原则和内容,在此基础上,又研究提出了系统的煤炭企业生态文明建设评价指标体系,对于今后一段时期我国煤炭企业生态文明建设的开展具有一定的指导意义
  • 我国需再制造的煤机装备数量巨大,开展煤机装备再制造企业标准化体系建设与实施对煤机企业具有重要的意义。结合再制造过程中废旧液压支架的全生命周期和工艺流程,根据企业统一的技术要求、质量要求和工作要求,...
  • 推进全集团统一的流程体系为什么比想象的难? 很多企业在推进全集团的流程管理过程中,经常会有一种“望山跑死马”的感觉。“各成员公司都建立起与集团公司统一的流程管理体系”,看似很简单一件事情,但没有经过...

    推进全集团统一的流程体系为什么比想象的难?

    很多企业在推进全集团的流程管理过程中,经常会有一种“望山跑死马”的感觉。“各成员公司都建立起与集团公司统一的流程管理体系”,看似很简单一件事情,但没有经过良好的规划和有策略的推进,其结果和愿望会大相径庭。让我们来看一个案例:

     

    A企业在全国各地都有分公司,各分公司的主营业务相似度很高。该企业希望一年内,在三家分公司内梳理流程,建立流程管理体系,然后在三家中挑选一家作为典范,将做法推广到其他分公司。A企业总部制定了流程编写的方法、规范、图例,并聘请了外部培训师制作了培训材料,在三家分公司分别进行了讲解和辅导。流程编制如火如荼地开展,但等到三家分公司“交作业”的时候,却发现各分公司流程除了图形、图例一样外,其他的都五花八门。有的分公司按部门职责切分流程,有的分公司按产品线切分流程。即便是针对同一项业务,三家流程的细致程度也不一样,有的分公司将一件日常工作细化为一项流程,有的分公司却将跨越好几个部门的工作才形成一项流程。A企业发现既选不出典范,也没有办法让三家的流程取长补短,集团式流程体系建设只能暂时搁置。

     

    在这个案例中,A企业将集团式流程建设等同于若干家企业的流程建设,因此缺乏周全规划和策略,体现在以下五个方面:

    01

    没有形成广泛的流程推进目标

    下属公司自主地考虑流程建设的目标与效果,没有在统一的目标与效果上与集团达成共识。

    02

    “标准”过于单薄

    总部推行的“标准”仅是对单条流程进行编写的标准,没有对深度、细度的详细定义,更没有对与集团管理对接。

    03

    回避了对流程设计内容的统一

    既没有流程切分与定义的规则,也没有相应的架构或者模板。推行中完全交由下属公司自由发挥,因此其流程设计的成果全仰仗于下属公司的管理水平。

    04

    采取“运动式”的建设方式

    寄希望于下属公司动员式的建设运动来完成流程推进工作,没有深入的建设方法辅导,也没有成型的顶层设计、验证推广过程。

    05

    对推进过程中的管理责任考虑欠缺

    没有提前研究流程推进完成后的管理方式,到最后才考虑如何整合,也没有为下属公司考虑如何开展日常流程管理工作,提出管理要求。

     

    因此,集团式企业的流程体系建设要远难于单个企业内进行流程体系建设,它犹如一场大的战役,既要安排好下属公司的每一场战斗,又要进行全局的考量,需要认真地研究推进的目标、方法、策略。

     

    先求“快”还是先求“准”?

    流程体系建设要全面铺开,就需要有策略。是先“跑马圈地”,让各公司先从无到有,再求精益;还是“先磨刀再砍柴”,先实现保留各公司业务特点,再逐一优化?我们总结“快”模式和“准”模式。

     

    “快”模式,即以先建设后管控为策略常见做法为通过顶层设计,形成一个虚拟的“标准公司”(例如:一家虚拟的“标准门店”,一个虚拟的“标准生产厂”等),借助“标准公司”完整地展现其流程体系建设后的全貌(如流程、组织、管理要求、指标等)。被推广公司可以直接在“标准公司”的模板上进行个性化的修改,达到快速建成的效果。等各下属公司完成建设后,总部再统一收集建设成果,横向比较,逐步求精。

     

    “快”模式的优点在于建设周期相对短,各公司一次性建设后标准性高,推行“标准公司”本身可带有流程优化或流程再造性质。缺点在于对顶层设计要求很高,推进过程造成的影响较大,后期治理体系建设难度也较大。“快”模式适合下属公司业务相近,总部对初期管控要求不高的集团式企业。

     

    “准”模式,即以建设与管控同步并行为策略。常见做法是通过顶层设计,形成流程架构、标准组织架构、业务表单分类等全集团需高度统一的内容进行推广。被推广公司通过“填空”的方式,补充自己的设计,例如:基于标准的流程清单,补充本公司的流程逻辑,但不允许重新切分流程的范围。涉及到对顶层设计的修改,都需要向总部进行申报。在建设过程中,每家下属公司的特点都可以实现先保留,再优化。集团的管控也随着推进在不断地加强。

     

    “准模式”的优点在于借助流程池保留各公司差异性,变革难度较小,逐步推广影响也较小,借助逐步收拢的管控力度为后期治理体系建设奠定基础。缺点在于周期相对长,总体投资相对大。“准”模式适合下属公司间业务差异较大,总部对初期管控要求高的集团式企业。

     

    谁“试点”,谁“验证”,谁“推广”,谁“评价”?

    无论是先“快”还是先“准”,集团式企业的流程体系建设切不可“走夜路”。借助小范围的流程建设试点,探明意义、标准、方法后,再逐步在各公司间推行,是较为常见和容易成功的做法。另一方面,这样可以保障各公司推行流程建设时达到接近的水平,避免出现极端好和极端差的情况。常见的推进方式可以分为以下几个阶段:

     

    01

    “试点”阶段

    选取具有典型特色的下属公司进行全面的流程体系建设(也可限定业务范围),以探索成果、意义、方法为主。对于下属公司业务差异小的集团,可考虑选取规模适中,管理基础较好的下属公司作为试点公司;对于下属公司业务差异大的集团,可考虑选取业务通用性强和业务覆盖面大的下属公司作为试点公司。

    02

    “顶层设计”阶段

    借助“试点”成果形成可推广的顶层设计。如标准模板、通用流程架构,通用流程设计规范等。同时,将“顶层设计”在一到两家下属公司进行验证和完善。

    03

    “推广”阶段

    借助推广“顶层设计”成果实现流程体系全面推广建设。借助推广流程体系的过程推行总部的流程管控要求,同时借助推广经验不断提升顶层设计,为治理体系建设做准备。

    04

    “评价”阶段

    在各下属公司推行流程体系建设的过程中,开展建设过程与建设成果的评价工作。评价可由总部和试点公司组成专家组来进行。

     

    顶层设计哪些内容?

    顶层设计是集团式企业在流程体系建设过程中,向分子公司进行统一推行的原则、方法、框架、模板、必须遵守和进行参考的设计内容。一个完整的顶层设计应至少涵盖的内容如下:

     

    1

      流程体系建设的总体目标、策略和原则。

    2

      流程体系建设的方法论,包括管理理念、实施步骤、技术要点等。

    3

      流程体系建设的规范,包括流程设计规范、文档模板规范等。

    4

      各下属公司必须遵守的标准设计,如标准流程架构、标准流程名录等。

    5

      供各下属公司学习使用的参考设计,如参考角色设计,参考流程模型等。

     

    目前,国内很多集团式企业在推进流程体系建设时,都选用ARIS作为顶层设计与推广的平台,那顶层设计中也要涵盖以下内容:

    1

      ARIS平台中的建模规范、技术要点等。

    2

      ARIS平台中的过滤器、模板、导出脚本等。

    3

      ARIS平台中的标准库和流程参考库(Process Reference House)等。

    4

      基于ARIS平台模型的流程评估检查报告等。

     

    一次性还是分批推广?

    推行顶层设计过程中,如果集团式企业的下属公司数量较多,或者业务差异过大,可以考虑分批推广。有些企业青睐于“先苦后甜”,第一批推广选择规模较大、管理较乱的企业;有些企业青睐于先推管理基础较好的企业。建议要先选择对流程管理的需求迫切,推动力较好的下属公司。

     

    B企业的流程体系建设试点选择在公司总部开展,流程管理推进小组对如何在其超过一百家规模不一、业务多样、且管理水平参差不齐的分公司进行流程推广非常发愁,既怕实施难度太大影响下属公司正常业务开展,又怕实施力度太小见不到成效。眼看着推广启动时间一天一天逼近,却研究不出好的办法。B企业下属某生产厂是中德合资,其德国外派专家恰好曾经是德国资方公司的流程管理推进人,他刚上任就在该合资生产厂积极地宣传流程管理价值意义和先进做法,获得该生产厂上下一致的认可。就在集团一筹莫展的时候,该生产厂将管理需求汇报到集团,恰好与总部不谋而合。虽然该生产厂既不是该集团最复杂的公司,也不是最赚钱的公司,但却成了流程管理推进过程中最积极的推动者之一,他们借助贴切生产实际的管理需求提出了很多有价值的典型经验。因此,第一批推广名单尘埃落定,B企业上下都充满了信心和动力。

     

    B企业从第一批推广到全面建设成功预计还有四到五年的时间。一个企业如果采用分批推广策略,则总部要做好不断地吸纳每一批推广过程中的优秀做法,完善到顶层设计中,再反过来向已经推行过的下属公司推介经验。因此,总部的专家团队要时刻保持高度的责任感,借助辅导、评价、管控等工作,深化流程体系建设要求,做到“步步为营”。同时,此时已经在为推广完成后的治理体系进行预演了。

     

    文章转载自公众号:博阳咨询业务流程管理

     

     

     
     

    转载于:https://www.cnblogs.com/K2China/p/10727705.html

    展开全文
  • 浅谈软件研发管理体系建设

    万次阅读 多人点赞 2018-12-08 21:40:52
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更多的伙伴碰撞,进一步完善这种认识,并逐步...

    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?在不断思考的过程中,逐步有一些粗浅的认识,在此将这些认识记录成文字,并期待能够与更多的伙伴碰撞,进一步完善这种认识,并逐步上升到理论高度,从而有利于指导具体实践。

    1. 对软件研发管理体系的一些概念认知
    1.1. 研发管理是什么
    关于研发管理,百度百科中这样定义:研发管理就是在研发体系结构设计和各种管理理论基础之上,借助信息平台对研发过程中进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等的一系列协调活动。

    也就是说,研发管理首要一点就是要根据公司业务的发展确定相应的研发体系结构,之后按照这种研发体系结构组件一支高水平的研发团队,设计高效合理的研发流程,借助合适的研发信息平台支持研发团队高效工作,以绩效管理调动研发团队的积极性,以风险管理控制研发风险,以成本管理使研发在成本预算范围内完成研发工作,以项目管理确保研发项目的顺利进行,而知识管理使得研发团队的智慧联网和知识沉淀。

    纵观各类软件企业,由于自身所处环境不同,因此其软件研发管理模式也不尽相同,这其中有基于CMMI能力成熟度模型指导下构建的研发管理体系,也有基于IPD集成产品研发框架指导下构建的研发管理体系,当然也有一些目前不少小企业、互联网企业推崇的敏捷研发管理体系。不同的研发管理体系其实都会有相应的交叉部分,最终追求的目标都是能否适合企业的发展,给企业带来市场和财务上的成功。

    1.2. 基于CMMI的研发管理
    CMMI能力成熟度模型相信大家都不陌生,从一级到五级,覆盖了22个过程域,一般能达到CMMI3级别的基本上可以理解为各类流程、过程规则等已经达到一个较好的水平。当然,这里主要是指企业能够确实按照CMMI模型去实践,这种实践其实更适合于以瀑布式开发为主导的项目开发及产品研发模式。然则,实际上,大部分企业尤其是国内企业并不会严格按照这个模型去做,因为如果每一个过程域都不打折扣地执行地话,需要非常标准化的流程和强大的资源支撑,在这个讲究快速响应变化的时代其实是很难做到的,通常这个时候都会进行相应的裁剪,甚至会结合敏捷迭代等方面的模式,从而逐步形成自己公司的研发管理体系。

    1.3. 基于敏捷模式的研发管理
    在这个快鱼吃慢鱼的互联网时代,对用户和环境越来越要求要快速响应。敏捷研发是当前不少互联网企业、中小企业推行的研发管理体系,主要理念就是敏捷迭代、小步快跑,快速改进、拥抱变化,用户参与等等。目前这方面也有不少公司除了有相应的敏捷研发体系之外,还有相应的成熟工具做支撑。例如,腾讯的TAPD敏捷研发平台就是其中的代表。通过对用户故事的层级拆分,实现对需求的有效管控和分解,从而确保持续迭代上线。

    敏捷研发管理在当前我们以业务为导向、项目为主的情况下,要全面实施尚有较大困难,当然并非是完全不能做,主要是当前所处的环境、所面向的业务、项目开发模式、人员结构等可能较难满足敏捷模式推行的需要。

    1.4. 基于IPD的研发管理
    之前有简单了解过IPD产品研发管理体系,我认为其中的核心就是“四四四”模型,四四四代表了四大团队、四个流程、四个支撑体系。

    四大团队建设包括建立集成产品管理团队(IPMT)、建立产品市场团队(PMT)、建立产品开发团队(PDT)、建立技术开发团队(TDT)。

    四大流程建设包括建立产品战略流程、建立需求管理流程、建立产品开发流程、建立技术开发及平台开发流程。

    四个支撑体系建设包括建立项目管理体系、建立质量管理体系、建立绩效管理体系、建立成本管理体系。

    个人感觉,基于IPD的产品研发管理从整体上来看是一个相对重量级的体系,要落地执行往往需要从整个公司层面去整体考虑和推动。

    IPD的理念和敏捷开发理念在本质上是基本一致的,比如以市场需求(用户价值)为核心,将产品开发看成一项投资(商业价值),通过CBB—公共基础模块和跨部门的团队准确、快速、低成本、高质量地推出产品(各评审点的多团队参与和决策、通过各种技术改进提升产品开发效率和降低浪费、持续交付)。

    从理论上来讲,IPD研发管理体系是一个较全面的体系,在当前我们的现状下也可能容易出现水土不服的情形,当然其中有一些好的做法是值得借鉴的。

    2. 什么样的软件研发管理体系适合我们的发展
    从项目及产品的研发角度来看,发展到一定阶段的传统IT企业在研发管理上多数都是基于瀑布型的传统研发模式,由于项目的特点及人员的组织结构等因素,项目开发及产品研发的周期往往较长,较难适应市场快速变化的需要,也较难做到对客户的需求进行快速响应。而大部分的互联网公司及一些大厂,推行了敏捷研发模式,或者是在标准化项目管理和敏捷迭代两者融合上进行了相应的实践。

    那么,针对当前我们所面临的一系列问题,究竟什么样的软件研发管理体系在未来一定时期内适合我们的发展?我们需要重构我们的软件研发管理体系吗?我们有必要重构我们的软件研发管理体系吗?带着这些问题,我想主要思考几个方面的问题。

    2.1. 能否快速适应未来业务的发展变化
    技术是为业务发展而服务的,因此在考虑软件研发管理体系构建时,第一个要考虑的问题就是我们的软件研发管理体系能否快速适应公司未来业务的发展变化。特别是在传统IT业务与互联网新兴业务加速融合的大环境下,信息化能力是越来越多客户的第一选择,因此在业务的快速发展方面需要更加强有力的技术支撑,而这个支撑的背后就是需要我们能够有一套能够快速响应变化、敏捷高效的研发体系,特别是能够有一定的前瞻性并支撑到老业务的快速转型和新业务的拓展。

    2.2. 在业务出现较大波动时能否弹性伸缩
    另外一个问题就是,业务在发展过程中,受大环境等诸多因素的影响,定然很难一直都是呈现直线上升的发展趋势,这当中必然会有波峰波谷,只不过这个波峰波谷是大是小的问题。而我们面临的问题则是,当出现较大的波峰波谷的时候,我们的研发管理体系应该如何适应?特别是在软件业务处于相对低谷时,既能够继续保持对技术研发的持续投入,又能够在应用开发等方面有一定的可伸缩性,从而正确地处理好软件生产效益问题。这里面可能会涉及到中高层次软件人才的相对稳定和低层次软件人才的灵活流动等问题。特别是在我们业务多样化的背景下,不同业务单元的发展会有不同的发展路径,对软件研发能力的诉求也有所不同,那么这里面首先涉及到的一点就是如何有效平衡基础研发能力和行业研发能力。

    对于基础研发能力,个人认为应该是一个软件公司最内在的核心技术能力,往往很多时候基础研发工作很难像做行业应用开发那样立竿见影,但这项工作干得不好往往又容易成为行业研发能力的掣肘,这也是我们当前在人工智能、区块链等新技术潮流背景下总感觉难以发力的原因之一。

    对于行业研发能力,个人认为应该要从两个方面去考虑,一个是产品化的能力,其二才是应用开发能力。应用开发能力很好理解,就是目前我们这么多年以来一直在做的各种类型的项目开发,而这里面大部分的项目开发其实都是偏应用层面的开发。而产品化的能力则是最近一两年以来我们重新关注的一个内容,不过这条路上我们尚开始起步,还有很长的路要走,也还有不少坑要踩。个人认为,产品化的能力能否真正发展起来,其中很重要的一点就是要考虑如何与基础研发能力做充分融合。产品化不等同于应用开发,应用开发更多是定制化的开发,是客户导向的软件开发,通常面向的是一个或少数几个的客户;而产品化则是要综合行业、市场、客户群体、新技术等多方面因素的研发,是市场导向的软件开发,面向的是一个或多个的客户群体,甚至面向的是一个市场或跨界市场。

    2.3. 新技术研发及成果转化能否跟上业务变化
    最近几年,新技术层出不穷,在软件架构的发展方面也非常迅猛,历经了单体架构、垂直架构、SOA架构、微服务架构的演化。从我们公司目前的技术研发实际来看,我们有少量的项目/系统采用了SOA架构,然则大部分的项目/系统仍然采用的是单体架构和垂直架构。单从这一点来看,我们在技术领域的持续跟进及成果转化方面已然有落后趋势,这方面需要我们奋起直追才行。当然,出现如今这种局面固然由众多因素催生而成。比如,已有开发框架前端兼容性的问题最近一两年以来常常被诟病,诚然有它内在的好处,然则最近一两年以来,用户对系统的用户体验要求更高了,不再是单纯地满足于功能实现层面,而是开始追求良好的人机交互和界面展现。因此,这方面势必对新技术的要求更加迫切。最近几年,当不少团队都在往前后端分离走的时候,我们至今的绝大部分软件项目开发仍然停留在前后端分离之前,对不少用户界面展现要求高的软件项目而言,难以快速有效响应变化,同时对一些相对比较成熟的软件产品而言也难以做到接口自动化。

    因此,能否在新技术的研发上抓住正确的方向并加快研发成果转化,为业务的快速变化提供强有力的技术支撑,是一个摆在我们面前急需解决的课题。从当今新技术的发展趋势来看,研发架构方面,我们虽说不能完全抛弃传统的单体/垂直架构,但我们必须要往微服务架构方向迈进,除了与最新技术接轨之外,更重要的是如何进行业务解耦,沉淀行业积累,并反向推动人员组织层次的变革,提升软件生产效率,提高软件质量。

    除此之外,对于人工智能、区块链等新领域,也是需要综合业务应用场景打造适合我们自身发展的技术+业务融合之路。

    2.4. 在标准化和敏捷迭代之间如何平衡
    标准化的软件研发道路固然有不少好处,有严谨的流程、规范的体系、固定的套路,当然更多的则是瀑布开发模式,虽然最近几年也陆续有迭代开发的模式,但更多的是被动式响应,而且这种迭代开发模式基本上是大阶段的划分,在每一个大阶段里面依旧是一个典型的瀑布开发模式,即历经需求分析、交互原型设计、UI设计、Web前端开发、程序开发、系统测试、部署实施等步骤,横跨周期往往较长,一旦发生需求变更,变动的代价过高。

    敏捷开发强调以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    那么,问题来了,既然标准化项目管理模式下存在太多流水线作业及效率低下等问题,那么我们能够直接转向敏捷迭代模式呢?世界上万事万物都是对立统一的,个人认为不论是标准化项目管理模式还是敏捷迭代项目管理模式都有其擅长的一面。一方面,在现有的以项目为主导的软件开发体系中,标准化模式是我们一直以来的主要做法,也积累了不少经验做法;另一方面,采用敏捷迭代模式对于产品复杂不断有新需求加入等场景是比较适合的。所以这里面更多的是考虑如何更好地平衡标准化项目管理和敏捷迭代两者之间的关系。基本的思路就是结合标准化项目管理和敏捷迭代的优缺点进行适度裁剪,既能提高软件质量和软件开发效率,也能够保留一定的规范性和软件过程文档。例如,针对项目管理,通常是五个过程组:启动、规划、执行、监控、收尾,那么我们其实可以结合实际将规划提前,将监控贯穿于执行过程,这样就势必要求在启动时也要做好项目计划相关工作,在执行过程中抓住关注点并定期监控其执行情况,在收尾阶段做好项目回顾总结。

    不论采用何种模式,我们的根本目标就是达到更低的成本实现更快速、更可靠的交付。近年来比较火热的是DevOps。DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

    因此,我们的软件研发管理体系中是否应该引入DevOps,进而改善公司组织文化、提高员工的参与感、提高交付效率,我想这也是需要重点关注和考虑的。

    2.5. 组织过程资产能否持续积累并盘活
    组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标,项目组织在实践中形成自己独特的过程资产,构成组织的核心竞争力。

    组织过程资产主要包括但不限于以下内容:项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训,其中既包括已经形成文字的档案,也包括留在团队成员脑子中没有形成文字的思想。项目组织在项目管理过程中形成的所有文档,包括知识资料库、文档模板、标准化的表格、风险清单等。 项目组织在以往的项目操作过程中留下的历史信息。

    经过多年的软件开发,我们做了大大小小形形色色的软件项目和产品,也逐渐积累了一些行业化的软件项目,但总的来看,能够形成规模化效应的软件产品尚较为匮乏,更多的是以定制化开发为主的软件系统,当然也积累了不少项目经验。在这过程中,也积累了不少标准、规范、流程、模板等各类软件过程资源。然而,从目前掌握的情况来看,这些资源是分散的,不够体系化的,还谈不上真正意义上的资产,至少在价值的发挥上还不充分。况且,软件行业这几年的人才流动率明显加快,人员更替的速度以及未能体系化的过程资产积累,加剧了组织过程资产的盘活难度。

    那么,构建一个相对健全的、动态的、能够适应未来业务发展的组织过程资产库就显得尤为重要。这既是软件研发管理体系的一个重要组成部分,也是公司层面应该给予充分重视的。在组织过程资产库构建的过程中,其中很重要的一点就是如何让研发知识与经验成为公司的宝贵财产,这里就要充分考虑研发知识管理。知识管理把“隐形知识显性化”,是一项涉及知识库、过程资产、环境和交流等元素的整合过程,所管理的知识将作为一个团组织中过程资产的重要组成部分。对于软件研发而言,我们需要考虑怎么把业务人员和技术人员脑中的蓝图转化为显性知识。

    3. 构建我们的软件研发管理体系应包含哪些内容
    软件研发管理体系的建设离不开几个关键要素:人员、技术、过程、资源,并在此基础上配以相应的管理手段。进一步来看,要构建适合我们自身发展的软件研发管理体系,需要着重考虑几个能力体系的建设,即:人员组织能力、技术研发能力、过程管理能力和资源建设能力。

    前面也有针对“什么样的软件研发管理体系适合我们的发展”进行了一些相对粗浅的探讨,那么在考虑如何构建适合我们发展的软件研发管理体系之前,我想这里首先要明确一下我们期待构建的软件研发管理体系。我们公司的业务涉及众多行业客户,一直以来主要以定制化项目开发为主,同时也涉及运维服务,而在产品研发等方面则处于起步阶段,且在一段时期内项目、产品、服务将会长期并存,因此,个人认为适合我们的软件研发管理体系应该至少经历三个阶段,包括初期的标准化软件研发管理体系、中期的标准化与敏捷相结合的软件研发管理体系和后期的敏捷化软件研发管理体系。

    基于上述这样的考虑,正常来讲我们当前应该在标准化的软件研发管理体系中要做进一步强化,而考虑到市场的快速变化、技术的日益进步,个人认为我们当前就需要开始考虑标准化的与敏捷相结合的软件研发管理体系。为什么还需要考虑标准化的软件研发管理体系呢?主要是传统的定制化的软件项目开发依旧占据主体,且目前在这方面仍然有非常大的改进提升空间,然而标准化的模式常常是过于强调标准、规范、流程,开发模式过于线性化,因此需要引入敏捷开发模式。所以,我们又需要考虑敏捷的软件研发管理体系,这主要是为了更好地适应市场变化、更快速地响应客户需求,更好地提升软件开发生产效率。

    3.1. 人员组织能力
    关于人员组织能力,个人认为有两个关注点:一是团队的发展,二是个体的发展。这两者是相辅相成、互相融合促进的。综合来看,人员组织能力的建设主要包括设立与公司战略、业务、技术发展相适应的组织架构,并配以构建相对完整可行的岗位体系和对应的人员考核体系,同时在团队建设等方面持续改进与提升。

    关于组织架构,当前的组织架构虽然解决了一些曾经的主要矛盾,但依然存在不少问题,突出的一点就是核心薄弱,即核心技术能力不强,仍旧需要投入大量的人力到各行业的应用开发中,当然这与我们一直以来承接定制化的软件项目开发不无关系。这是当前乃至未来一定时期需要解决的。

    同时,最近几年来的组织架构主要是以职能型组织架构为主,产品线为主导的研发模式尚不成熟,针对项目及产品的团队构建主要是以项目经理来驱动,在项目团队的组成方面固然与互联网的项目团队截然不同。在团队建设方面,需要进一步打通团队之间的壁垒,强化团队的整体协同作战能力。

    在岗位体系方面,特别是对人员的绩效评价方面,需要在已有的岗位体系基础上进一步考虑如何更好地执行落地,确保个人绩效目标与团队绩效目标的一致性和顺利达成。

    3.2. 技术研发能力
    结合我们的实际,我认为在技术研发能力方面要考虑四个方面:一是技术预研,二是技术开发,三是产品开发,四是定制开发。

    关于技术预研,通俗来讲就是:预研=预先+研究。这种预先研究通常来源于几个方面,例如来自外部竞争对手的迫使、来自客户或市场的需求、来自公司高层的决策等。为什么要做技术预研呢?这是扫清前行障碍的过程,这为后续展开总体设计、详细设计指明了方向,也是持续积累公司技术能力、保持与新技术同步而不至于脱离轨道的方式之一。

    关于技术开发,其实这里主要指与基础平台、公共组件、关键技术等方面的技术研发。另外一个方面来理解,技术开发是技术预研的延续,是在技术预研成果经论证的基础上开展的一系列能促进公司发展、业务发展、技术发展而开展的技术研发工作。

    软件产品是指向用户提供的计算机软件、信息系统、套装软件或在提供计算机信息系统集成、应用服务等技术服务时提供的软件,是通用的产品应用于某一行业领域而不是像软件项目一样为某一需求或者单位定制开发。

    软件项目主要为特定企业开发或者部署实施一套专用的系统,在进入项目开发之前需要与用户进行具体的交流和讨论,了解用户心中对于软件预期的样子,后经过招投标,签订合同,实施交付。

    关于产品开发,这方面我们尚处于起步阶段,尚缺乏一套完整可行的产品研发流程及最佳实践,需要摸着石头过河,也需要长期坚持不懈地努力。

    关于定制开发,当前主要是基于客户需求的软件项目定制开发,后续还会包括基于产品衍生出来的定制化开发。前面的这种方式是我们当前最熟悉的模式,主要面临的困境是两个:一是如何实现快速交付,二是如何实现成本可控,从而提升软件项目的利润。

    做项目侧重于在最短的时间内,按照客户的需求开发出操作敏捷,用户体验良好的软件。而做产品则侧重于市场驱动,时间相对充足,但要开发出有竞争力,有自身特色,且受客户欢迎的产品,要求功能响应速度快,操作简单,界面美观。

    技术预研+技术开发是强化内核的内在需要,定制开发是现阶段的生存根本,产品开发则是为未来发展铺路。

    3.3. 过程管理能力
    过程管理能力主要包括项目管理、开发管理、质量管理和配置管理等几个方面,需要一套完整合理的流程贯穿整个过程。

    在项目管理方面,我们需要梳理当前项目管理体系的标准、规范、流程及相关实践,建立以过程为核心、以度量为基础、以人为本的可裁剪、受认可、能执行的信息集成项目管理体系,进一步规范公司的项目管理,提升项目群管理能力。结合项目管理的五大过程组(启动、计划、执行、监控、收尾),并结合敏捷迭代的思想,形成标准化项目管理与敏捷迭代相结合的具有实际指导意义的方法体系,同时将这套方法体系以指南性文件、规范性文件等形式传导到相关人员,确保可落地执行。此外,为加强过程管控、资源共享、工作协同,组建PMO团队,实现对项目群及重大项目的统一管控与决策支持。

    在开发管理方面,一是要落实统一的软件开发规范,包括架构规范、设计规范、UI规范、编码规范、测试规范等。强化设计及开发关键环节的评审,包括对需求、概要设计、详细设计、UI设计等的设计方面的评审,对测试用例等方面的评审,对代码的评审检查(例如利用SonarQube进行代码的自动检查等)及发布评审等。同时通过试点+逐步铺开的方式着力推进CI/CD的落地。

    在质量管理方面,进一步强化项目质量审计,逐步改进软件过程生产效能。而在配置方面,则加强对配置项的识别、配置空间的管理、变更控制等,规范软件开发过程,确保构建正确的系统。正确应用软件配置管理是开发高质量软件所不可缺少的。软件配置管理的过程是软件开发过程中质量管理的精髓。

    综合来讲,在过程管理方面就是要形成一套适用的软件研发管理流程,并配以相应的节点管控,让不同开发角色之间即各司其职又相互融合促进,从而促进软件开发自组织能力的逐步提升,充分调动软件开发人员的主动性和积极性。

    3.4. 资源建设能力
    简单来讲,资源建设是软件研发管理体系中的支撑体系。资源建设主要包括了一系列的制度规范、工具、模板、过程资料及交付物(例如项目文档、源代码等),以及相应的经验、知识沉淀等。一是要适时梳理相应的制度、规程、标准、规范、文档模板等,形成标准化资源库;二是要对不同行业历年来的项目资料及源代码分门别类做好规划和归档管理,形成静态库(归档库)和活跃库,同时做好数据安全管理;三是要对软件研发人员及工作中的一些隐性知识转化为显性知识,并逐步构建软件研发的知识图谱,促进知识经验的持续积累与转化,并通过链条式、网状式等方式实现知识分享与传播,形成经验知识库。

    展开全文
  • 数据指标体系建设

    千次阅读 2020-03-08 23:57:11
    但对于传统电商这类关注供应链、管理成本的企业来说,这套指标体系并不能覆盖所有的场景,因此我们主要采用的是第一关键指标法作为指标体系建设的理论基础。 第一关键指标法: 第一关键指标法的核心思想,不是说一个...
  • 我国煤炭企业数量众多,但企业文化建设好的数量却并不多。而企业文化对于煤炭生产企业保持发展方向、凝聚发展力量、激发竞争活力等都具有重要的作用,因此,积极完善煤炭生产企业文化体系建设意义重大。
  • 数据仓库之指标体系建设分享

    千次阅读 2020-08-28 00:10:35
    1 指标体系 2 为什么要搭建指标体系 3 如何搭建指标体系 4怎么管理指标体系 5 如何产品化指标体系 6 结束 7 参考文献
  • 上一篇:基于欧美法律法规的企业隐私合规体系建设经验总结(一) 下一篇:基于欧美法律法规的企业隐私合规体系建设经验总结(三) 引子 在2019年,我有幸主导了公司的隐私合规体系建设。几乎是从零开始,完成了ISO ...
  • 软件研发管理体系建设

    千次阅读 2019-09-11 23:30:51
    最近一段时间,我一直在反复思考一个问题:我们的软件研发管理体系应该是怎样的?...本Chat讨论的软件研发管理体系建设主要包括以下内容: 1、对软件研发管理体系的一些概念认知 2、什么样的软件研发管理...
  • 数据治理体系建设方案(PPT)

    千次阅读 2021-05-02 00:26:25
    数据治理其实是一种体系,是一个关注于信息系统执行层面的体系,这一体系的目的是整合IT与业务部的知识和意见,通过将流程、策略、标准和组织的有效组合,对企业的信息化建设进行全方位的监管,需要企...
  • 运用解释结构模型(ISM)对构建出的 20 个影 响因素进行分析, 绘制出多级递阶有向图, 根据解释结构模型显示的分层结果分析各因素间的层级 递阶关系, 并对煤炭企业 TQM 体系的改进提出了建设意见
  • 数据治理之——数据标准体系建设示例

    万次阅读 多人点赞 2019-04-29 14:11:31
    1.1.1 数据标准体系建设 数据标准是企业级的业务规范,用于指导各业务系统及数据仓库的建设依据,元数据是系统级的描述手段,更多的反映系统建设情况;数据标准指导系统建设的成果可以通过元数据来反映,系统的建设...
  • 《网络数据安全标准体系建设指南》(征求意见稿).docx http://www.miit.gov.cn/n1146295/n7281310/c7858148/part/7858164.docx 《网络数据安全标准体系建设指南》编制说明.docx ...
  • 什么是零信任网络 制造企业信息安全现状说明 制造企业建设“零信任”的第一步,应该怎么走 “零信任”架构
  • 指标体系建设-理论

    2020-11-10 12:44:46
    但对于传统电商这类关注供应链、管理成本的企业来说,这套指标体系并不能覆盖所有的场景,因此我们主要采用的是第一关键指标法作为指标体系建设的理论基础。 ② 第一关键指标法: 第一关键指标法的核心思想,不是说...
  • 博主是涂鸦安全部门最早期成员之...本文是博主关于甲方安全体系建设历程的思考,分为三部分: 一、安全体系建设v1.0---快速治理 二、安全体系建设v2.0---系统化建设 三、安全体系建设v3.0---全面完善 附:安全制度管理
  • •安全建设的困境 •安全度量的意义 •什么是好的度量体系 •度量体系建设思路 •总结
  • 滴滴数据仓库指标体系建设实践

    千次阅读 2020-08-27 21:34:39
    桔妹导读:指标体系是什么?如何使用OSM模型和AARRR模型搭建指标体系?如何统一流程、规范化、工具化管理指标体系?本文会对建设的方法论结合滴滴数据指标体系建设实践进行解答分析。1.什...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,000
精华内容 12,800
关键字:

企业体系建设的意义