在差不多2010年左右开始我向国内IT组织推介DevOps(开发运维一体化)抑或是敏捷管理的时候，碰到大公司，无一例外，最大的顾虑都是认为会破坏和影响公司的合规、安全、风险管理。比如在IT合规需求中，典型的一条，开发人员不能拥有生产系统的帐号，即访问、管理权限；而DevOps或者说精益IT管理中则可能要求开发人员直接在生产系统上部署新版本，又或者提倡开发人员和运维人员一起为用户提供一线支持。这样看上去，都有悖GRC要求。
其实这首先是对GRC的一个误解，或者说把风险管理简单的理解成是满足一些教条的检查表(checklist)，没有真正理解风险管理的原则。风险管理本身在企业中处于战略位置，风险偏好(risk appetite)是企业战略层面定义，也影响着企业战略规划。但在大部分企业风险管理工作中把这个环节丢失了，直接从运营层面进行检查、审计、评估、改进等。通俗一点，也就是忘了“为什么出发”。
企业管理层要做的一个决定就是“愿意承担哪些风险”，风险的另外一面就是收益，控制了某些风险，也随即会影响了某些收益。在上述例子中，限制了开发人员对生产系统的访问、操作，的确降低了生产系统的安全风险和稳定运行风险，但同时却会导致产品／服务交付延期、time to market时间加长的后果风险，从而降低了企业的营收。那管理层就需要在这里做出取舍，这是一个基于战略的折衷。
当然在这里，有一点需要强调的是，如果是法律法规的合规(compliance)的要求的话，通常是难以妥协的。打个比方，如果银监会要求银行IT禁止开发人员访问生产系统，作为银行业合规需求，那意味着此项控制措施对银行风险等级再次升高，比如可能会导致大额罚款、暂停某些业务等等，自然在风险对策制定的时候会做出不同的决策。但仔细想想，风险管理的原则并没有变，只是对此风险的评估不一样而已。
另外，风险管理是一个动态演进的过程，当环境、技术、过程、组织等因素发生变化时，风险识别和风险偏好也会变化。在我们采纳了指纹识别技术后，我们降低了对物理访问的风险等级；在wifi技术完全普及时成为业务必不可少时，我们调整对无线网络的风险偏好。任何风险管理必须放在时间、空间、市场、竞争者／合作伙伴、员工构成等环境下去进行认知。这一点就不展开了。也因此，风险管理也需要在未来精益企业环境下进行考量。
我们回到精益企业的价值流概念，把GRC也放到整个组织的价值流中去进行评估和管理，切忌发生把GRC独立游离在外进行孤立的控制点评估和控制措施设计。这样你会发现，风险和价值其实是统一的，就是我常说的，控制风险是为了产生价值，风险点也是价值点。
不幸的，我的观察是大部分企业，尤其是大型企业，把GRC工作职能依然是孤立的(silo)建立和执行。
那精益企业环境下，GRC是不是有很多变化呢，的确是，毕竟精益环境下采纳了不同的技术手段和组织过程，就如上述分析，风险管理也是会有变化。这些包括：
$ 精益秉承的不浪费原则，即做正确的事和正确的做事，即控制了企业最大的风险。精益本身就是一种有效的风险控制。 所以精益并不像很多人直觉认为的与GRC冲突，而是提升了风险管理水平。
$ 精益企业中建议采取尽可能的自动化而非人工的过程，从人工到自动系统，很自然风险的属性和等级也发生变化。我们可以将大量的风险控制措施以代码的方式设计在过程系统中，风险也相可控和降低。（我们有时把这种自动化定义为“infrastrucure as code”）
$ 精益强调以团队聚焦模式进行工作协同，而非按职能／部门割裂开流程和人员，这样对于大大有利于风险的识别和控制。
$ 精益企业提升了组织学习，自然也利于管理层和员工对于风险的认知，可以更有效的进行风险的持续评估和管理。
$ 精益企业强调一线人员的自主性，将GRC的工作落实到日常的营运中，可以在风险的尽早期阶段进行分析、识别和响应。
最后我再重点谈一下风险控制手段与精益的关系。我们都晓得，风险控制的一种分类方法是定义为预防性控制(preventive control)、检查性控制(detective control)和纠正性控制(corrective control)三种类型。在精益企业中，我们的确要审慎采用预防性控制，在组织中大量采用预防性控制将可能导致：
> 人员因为预防性控制而被束缚住手脚，从而影响大家的主动性和创造性，这是与精益文化背道而驰
> 员工会因预防性控制要求而等待僵硬的审批流程，而导致交付速度大打折扣
> 员工会为了预防性控制而完成大量的未来被证实是无谓的、不产生价值的paper work
也就是说，我们要适当限制预防性控制措施，而尽可能使用检查性控制和纠正性控制，包括补偿控制。事实上，即便是使用预防性控制，我们尽可能使得这些控制自动化。