论文部分内容阅读
最近的新闻里有个特别刺耳的声音，说人工智能是一个伪命题，我看了标题，就没有再往下看了。其实，在我服务过的企业里，也陆续听到一些对于人工智能是否有效的质疑，甚至有些企业用相对保守的“数字化”替代了过激的“人工智能”在行文里的使用。
我最近和华为的一个业务单元高管聊天，他很实际地讲：“我其实现在对于人工智能没有报以太多期望。对于维护业务来讲，我看中的还是它未来是否能帮助我节省更多的成本，甚至是我的客户运营商的成本;而现在它对我来说，还仅仅只是一个概念。”
那么人工智能是什么呢？
我始终认为，人工智能是一个概念，并且是一个“品牌”。没错，是一个“品牌”，不属于技术，但是包含技术。因为我相信，人类是因为有想象力和思考力而进步的。在新的人工智能“品牌”下，我们会发现，今天的人类又朝着另一个社会应用的高度在前进。如果说工业革命、电气革命带来自动化，信息革命带来了连接，那么人工智能“品牌”下技术与商业模式的推进，将带领着人类逐步实现社会智能。而正是这样的想象力和思考力，又会带来大量新的需求，以及社会新消费驱动的创新进步，我把这样的社会性牵引力叫做一一趋势。
所以，人工智能是我们看待和发展这个社会的一种新方式。我们会在这个“品牌”下，不断地创造更多的人类社会需求，满足用户以后产生更多的价值，从而让我们的未来更加美好。
饥饿的公牛
一次我和国内风电行业的客户聊天，他談到最近在尝试实践人工智能，将嵌入人工智能的技术，应用到风电的设备制造过程中，帮助企业拥抱创新，形成新的竞争力。但是这个项目现在实际上举步维艰，进展缓慢，他很沮丧，找不到任何改进的可能，于是找到我。我首先和他分享了一个故事：
有一头在山顶上饥饿的公牛，已经十多天没有找到食物了，就在这个时候，它突然看到山下有一片绿意盎然的草地，眼睛发光，追不及待地从山顶猛冲了下去。刚冲到山下，却突然发现面前挡着一堵高墙，无法翻越，但是它清醒地知道在墙的那边就是那片可口的青草。于是，它无暇顾及，立刻就向这堵墙撞了过去，希望能够撞破这堵墙，然后吃到青草。“砰！”公牛被厚墙弹了回来，头破血流，墙依然立在那里，安然无事。这个时候，公牛开始疯狂了，它退后了20米，再一次冲击这堵墙，“砰！！！”公牛的头有点撞晕，但是墙依然毫无破损。公牛变得愤怒了，这次它退后到了半山腰，打算用尽自己所有的力气赌在这一次撞击上，不是你死就是我亡。但是，就在它退到半山腰的时候，它突然看见，其实那堵墙也就只有百米长，原来这堵墙是有两端的，于是，公牛慢慢从半山腰下来，从墙的一侧绕了过去，吃到了背后的青草。
我很喜欢用这个故事来隐喻现在人工智能概念下我看到的一些景象：大量的企业，大量的人员涌入到这个创新之下，饥肠辘辘，恨不得用尽全身力气最先吃到那片青草……但当你进入一个人工智能项目组的时候，往往会发现项目成员的桌上都放着深度学习、人工智能算法类的书籍，学习氛围很浓，但是另一方面也体现出“人工智能式的混乱”——这是一个学习型的组织，也在不断试错和迭代，但是这试错的方式是无序的，是粗放的。
人工智能类型的项目与通常的项目管理是完全不同的，传统意义的项目管理有三个基本特征：有明确的目标;在项目过程中有持续性的进展;通常有开始和结束的时间。而对于创新型的人工智能项目，完全没有这三个特征——首先，目标往往不太明确的时候就开始了，是奔着创新去的。其次，在执行过程中往往包含大量的试错，甚至失败，不总是在持续进展。最后，这类项目往往只有开始的时间，没有结束的时间。因此，如果慌忙地开展这类创新项目，往往风险都会很大，无法评估ROI。
我来华为之前，看到过太多的人工智能项目“死亡”，它们往往都是在人工智能战略还不清晰的时候，就匆忙开始。我所说的战略不清晰，不是指业务价值目标不明确，因为你会看到企业的高层对于人工智能的预期是很明确的，比如创新带来的收益，以及成本的减少。但是，战略的另一个部分，用怎样的模式来执行、来确保成功率，基本上又回到了传统的项目管理模式，甚至，很多时候是项目经理的处女作。他们往往就如同那头饥饿的公牛，面对前面的厚墙，然后碰得头破血流。
那么“人工智能”创新面前的这堵墙，是否有方法可以绕过去呢？
组织中的新角色
我经常会组织人工智能的研讨会议，会邀请这个项目所有涉及的资源部分，包括研发、开发以及业务。你往往会发现，这类的会议一般充满了争吵，并且收效甚微。原因很简单，这类会议往往充斥着两种不同的语言，研发、开发人员的话语里塞满了“算法、模型、代码、机器学习、系统、准确率、可靠性”……而业务人员的话语里却总是在讲“业务目标、场景、收益、维护、问题”……如果你是一个客观的旁观者，你会发现这两边聊天的语言是不一致的，不在一个体系里，甚至完全属于不同的两个世界。
这里缺少一个“翻译”。当年麦肯锡在为平安进行咨询服务的时候，曾帮助平安建立了一个“系统分析师”的团队，他们不负责具体的业务，也不执行具体的IT，而是连接这两块，通过对于业务和IT的理解，进行相应的转化，把业务的价值目标变成IT能接受的执行语言，把IT执行的阶段性业务进行汇报，从而很好地缩短了两个世界的差距。《哈佛商业评论》曾宣称“数据科学家”是二十一世纪最性感的职业。什么是“数据科学家”？在我看来，他不必是统计学、运筹学或者数学的天才，他们的能力关键在于：是否能持续化地用数据来解决业务问题，并且以往是否有这样卓越的经验。
我最近在帮助华为的业务部门定义数据分析师的招聘条件，我明确了把需要具备卓越的沟通能力和协作能力，能快速理解业务用户的痛点，并且转化为基于数据的洞察作为一项非常重要的能力。无论是微软、AWS、IBM，还是国内的阿里、京东……你会发现这些算法堆砌的应用平台，其最佳的特质就是协同，而不是算法的深度。这个时候，你就会明白，其实作为一个卓越的“数据科学家”你需要具备的特质是什么了。 作为一个人工智能领域的观察者，我会看到一些对于这个岗位招聘的偏见，比如由一个做图像识别出名的领袖人物来牵头成立一个研究院，你会发现对于“数据科学家”的要求更多包涵了一些图像识别领域的特长要求;或者一个机器学习领域的专家，在招聘里也会更多提到关于机器学习算法的要求。其实，这是一种对“数据科学家”招聘的偏见，如果作为一个企业，特别是一个业务驱动型的企业，习惯了这种偏见，你会发现最后对于沟通的有效性会变得越来越困难，最后的结果往往是“他们根本不懂人工智能技术嘛” “算了，他不知道我在说什么”。所以，除非是纯粹的研究课题，一般的人工智能项目，或是提到企业战略的人工智能创新，我一般不主张由一个完全研究领域的专家来负责，不是因为他不够学术权威，而是他有很多偏执会影响到项目的沟通，当然如果他是一个全面的人才，并且有很强的实战经验，也是一个不错的例外。这样的领袖往往需要有三个关键能力来帮助企业成功：定义价值、奠定基础、管理变化（图1）。
另外，这类角色的集中，就会形成一个新的组织，叫做分析组织。为什么叫分析组织，而不是智能变革组织或数字化变革组织呢（甚至我在有些公司看到取名人工智能部门的）。因为这类组织的作用不是在于技术的研究，当然也不是一个完全的企业转型的战略组织，而是更多利用技术转化为应用的分析组织，里面的人会更多地去协作、沟通、分析以及架构，而不是执行，他将成为一个企业人工智能实践的真正永动机。
三种运营模式
我看到很多公司的人工智能项目是由技术在引导，不停地讨论算法、数据以及系统，这其实是我不推荐的方式，在华为你也会看到，很多部门、很多人员都在搞人工智能，但是见到成效的很少。事实上，人工智能实践需要首先从部门功能设置开始。
在Facebook的人工智能创新里，有个AML团队，全称叫做Applied Machine Learning。主要就是构建人工智能业务与研究之间的桥梁，他们有明确的业务价值定义方法，以及人工智能技术实现的最佳实践。这个部门对业务创新负责，并且管理研究落地，在职责上是独立运作的，他们的职责就是基于人工智能技术的创新，然后落地到Facebook的各种产品里，很类似任正非在华为人工智能实践上讲的“自己的狗粮，自己吃”思路。但是，不同的方面在于部门设置模式，我这里简要陈述下基于创新构建分析价值的三种不同运营模式：
分散式服务模式 这种模式往往喜欢把“分析专家”散放在各个业务部门，并且由每个部门的主管来管理，好处是业务的智能需求可以马上得到匹配，我刚来到华为就去马来西亚的TAC站点做了一次mini Design Thinking，通过两天的研讨会，快速理解了一线业务。因此，这种模式可以很好地接触一线，了解一线，支持一线，但是缺点也很明显，缺乏全面的跨职能的视野，仅仅落脚在自己的问题点上，而且在各个部门，重复性资源和重复性的工作太多，团队组织也是重復的，浪费很多资金，无法标准化或者扩大规模。
嵌入式共享服务模式 这种模式是过渡阶段，在一个业务单元里，比如华为的GTS，设置一个独立共享的分析组织，这个组织充分对于业务进行支撑，但是运作上又是独立的，好处在于可以在某个业务或职能内部设置标准化的流程和方法，并与各部门都可以进行协作，对于专家也可以共享，很多资源不是在某个点上，而是全面对业务进行统筹型支撑。当然在这个阶段数据分析资源还未形成一个专业化、体系化的运营模式，对于跨业务单元的部门而言还是存在重复性建设的问题，而且在专业化的集中度上也只是一个过渡阶段，还不能独立核算部门价值。
独立式共享服务模式这种模式是一个终极运营模式，完全的独立和标准化运营，完全作为一个公司内部的服务机构存在，对每个战略业务单元进行支撑和核算，完全关注在业务的服务提升上，而不是技术研发。在IBM深圳有个ISC部门，对于IBM全球供应链来讲，它就相当于一个“航塔”的角色，IBM的业务资源外包是做得比较彻底的，到现在很多给IBM提供Power芯片的芯片厂都不再属于IBM了，在这样一个超离散的资源架构里，这个“航塔”不断地对这些制造单元输出标准，采集数据，形成分析和预测，然后由这个“航塔”里的“数据科学家”来进行控制，使得到今天为止IBM的全球供应链控制力都超强。
这样的模式设计其实是在做企业级人工智能应该首先思考的，也属于人工智能顶层设计的一部分。另外，当这样的组织建设成熟的时候，又需要思考在这个独立分析组织内部的运营机制建设了。我比较推崇的是以“垂直服务化”+“散点创新”的方式进行运营机制建立，其实它也融入了很多DevOps的思想：一部分强调服务运营的持续化和深度，另一方面又提倡在创新上加入竞争，接受失败和快速迭代，后面的文章我会专门再详细地描述这种充满魅力和“时代感”的机制创新。
我最近和华为的一个业务单元高管聊天，他很实际地讲：“我其实现在对于人工智能没有报以太多期望。对于维护业务来讲，我看中的还是它未来是否能帮助我节省更多的成本，甚至是我的客户运营商的成本;而现在它对我来说，还仅仅只是一个概念。”
那么人工智能是什么呢？
我始终认为，人工智能是一个概念，并且是一个“品牌”。没错，是一个“品牌”，不属于技术，但是包含技术。因为我相信，人类是因为有想象力和思考力而进步的。在新的人工智能“品牌”下，我们会发现，今天的人类又朝着另一个社会应用的高度在前进。如果说工业革命、电气革命带来自动化，信息革命带来了连接，那么人工智能“品牌”下技术与商业模式的推进，将带领着人类逐步实现社会智能。而正是这样的想象力和思考力，又会带来大量新的需求，以及社会新消费驱动的创新进步，我把这样的社会性牵引力叫做一一趋势。
所以，人工智能是我们看待和发展这个社会的一种新方式。我们会在这个“品牌”下，不断地创造更多的人类社会需求，满足用户以后产生更多的价值，从而让我们的未来更加美好。
饥饿的公牛
一次我和国内风电行业的客户聊天，他談到最近在尝试实践人工智能，将嵌入人工智能的技术，应用到风电的设备制造过程中，帮助企业拥抱创新，形成新的竞争力。但是这个项目现在实际上举步维艰，进展缓慢，他很沮丧，找不到任何改进的可能，于是找到我。我首先和他分享了一个故事：
有一头在山顶上饥饿的公牛，已经十多天没有找到食物了，就在这个时候，它突然看到山下有一片绿意盎然的草地，眼睛发光，追不及待地从山顶猛冲了下去。刚冲到山下，却突然发现面前挡着一堵高墙，无法翻越，但是它清醒地知道在墙的那边就是那片可口的青草。于是，它无暇顾及，立刻就向这堵墙撞了过去，希望能够撞破这堵墙，然后吃到青草。“砰！”公牛被厚墙弹了回来，头破血流，墙依然立在那里，安然无事。这个时候，公牛开始疯狂了，它退后了20米，再一次冲击这堵墙，“砰！！！”公牛的头有点撞晕，但是墙依然毫无破损。公牛变得愤怒了，这次它退后到了半山腰，打算用尽自己所有的力气赌在这一次撞击上，不是你死就是我亡。但是，就在它退到半山腰的时候，它突然看见，其实那堵墙也就只有百米长，原来这堵墙是有两端的，于是，公牛慢慢从半山腰下来，从墙的一侧绕了过去，吃到了背后的青草。
我很喜欢用这个故事来隐喻现在人工智能概念下我看到的一些景象：大量的企业，大量的人员涌入到这个创新之下，饥肠辘辘，恨不得用尽全身力气最先吃到那片青草……但当你进入一个人工智能项目组的时候，往往会发现项目成员的桌上都放着深度学习、人工智能算法类的书籍，学习氛围很浓，但是另一方面也体现出“人工智能式的混乱”——这是一个学习型的组织，也在不断试错和迭代，但是这试错的方式是无序的，是粗放的。
人工智能类型的项目与通常的项目管理是完全不同的，传统意义的项目管理有三个基本特征：有明确的目标;在项目过程中有持续性的进展;通常有开始和结束的时间。而对于创新型的人工智能项目，完全没有这三个特征——首先，目标往往不太明确的时候就开始了，是奔着创新去的。其次，在执行过程中往往包含大量的试错，甚至失败，不总是在持续进展。最后，这类项目往往只有开始的时间，没有结束的时间。因此，如果慌忙地开展这类创新项目，往往风险都会很大，无法评估ROI。
我来华为之前，看到过太多的人工智能项目“死亡”，它们往往都是在人工智能战略还不清晰的时候，就匆忙开始。我所说的战略不清晰，不是指业务价值目标不明确，因为你会看到企业的高层对于人工智能的预期是很明确的，比如创新带来的收益，以及成本的减少。但是，战略的另一个部分，用怎样的模式来执行、来确保成功率，基本上又回到了传统的项目管理模式，甚至，很多时候是项目经理的处女作。他们往往就如同那头饥饿的公牛，面对前面的厚墙，然后碰得头破血流。
那么“人工智能”创新面前的这堵墙，是否有方法可以绕过去呢？
组织中的新角色
我经常会组织人工智能的研讨会议，会邀请这个项目所有涉及的资源部分，包括研发、开发以及业务。你往往会发现，这类的会议一般充满了争吵，并且收效甚微。原因很简单，这类会议往往充斥着两种不同的语言，研发、开发人员的话语里塞满了“算法、模型、代码、机器学习、系统、准确率、可靠性”……而业务人员的话语里却总是在讲“业务目标、场景、收益、维护、问题”……如果你是一个客观的旁观者，你会发现这两边聊天的语言是不一致的，不在一个体系里，甚至完全属于不同的两个世界。
这里缺少一个“翻译”。当年麦肯锡在为平安进行咨询服务的时候，曾帮助平安建立了一个“系统分析师”的团队，他们不负责具体的业务，也不执行具体的IT，而是连接这两块，通过对于业务和IT的理解，进行相应的转化，把业务的价值目标变成IT能接受的执行语言，把IT执行的阶段性业务进行汇报，从而很好地缩短了两个世界的差距。《哈佛商业评论》曾宣称“数据科学家”是二十一世纪最性感的职业。什么是“数据科学家”？在我看来，他不必是统计学、运筹学或者数学的天才，他们的能力关键在于：是否能持续化地用数据来解决业务问题，并且以往是否有这样卓越的经验。
我最近在帮助华为的业务部门定义数据分析师的招聘条件，我明确了把需要具备卓越的沟通能力和协作能力，能快速理解业务用户的痛点，并且转化为基于数据的洞察作为一项非常重要的能力。无论是微软、AWS、IBM，还是国内的阿里、京东……你会发现这些算法堆砌的应用平台，其最佳的特质就是协同，而不是算法的深度。这个时候，你就会明白，其实作为一个卓越的“数据科学家”你需要具备的特质是什么了。 作为一个人工智能领域的观察者，我会看到一些对于这个岗位招聘的偏见，比如由一个做图像识别出名的领袖人物来牵头成立一个研究院，你会发现对于“数据科学家”的要求更多包涵了一些图像识别领域的特长要求;或者一个机器学习领域的专家，在招聘里也会更多提到关于机器学习算法的要求。其实，这是一种对“数据科学家”招聘的偏见，如果作为一个企业，特别是一个业务驱动型的企业，习惯了这种偏见，你会发现最后对于沟通的有效性会变得越来越困难，最后的结果往往是“他们根本不懂人工智能技术嘛” “算了，他不知道我在说什么”。所以，除非是纯粹的研究课题，一般的人工智能项目，或是提到企业战略的人工智能创新，我一般不主张由一个完全研究领域的专家来负责，不是因为他不够学术权威，而是他有很多偏执会影响到项目的沟通，当然如果他是一个全面的人才，并且有很强的实战经验，也是一个不错的例外。这样的领袖往往需要有三个关键能力来帮助企业成功：定义价值、奠定基础、管理变化（图1）。
另外，这类角色的集中，就会形成一个新的组织，叫做分析组织。为什么叫分析组织，而不是智能变革组织或数字化变革组织呢（甚至我在有些公司看到取名人工智能部门的）。因为这类组织的作用不是在于技术的研究，当然也不是一个完全的企业转型的战略组织，而是更多利用技术转化为应用的分析组织，里面的人会更多地去协作、沟通、分析以及架构，而不是执行，他将成为一个企业人工智能实践的真正永动机。
三种运营模式
我看到很多公司的人工智能项目是由技术在引导，不停地讨论算法、数据以及系统，这其实是我不推荐的方式，在华为你也会看到，很多部门、很多人员都在搞人工智能，但是见到成效的很少。事实上，人工智能实践需要首先从部门功能设置开始。
在Facebook的人工智能创新里，有个AML团队，全称叫做Applied Machine Learning。主要就是构建人工智能业务与研究之间的桥梁，他们有明确的业务价值定义方法，以及人工智能技术实现的最佳实践。这个部门对业务创新负责，并且管理研究落地，在职责上是独立运作的，他们的职责就是基于人工智能技术的创新，然后落地到Facebook的各种产品里，很类似任正非在华为人工智能实践上讲的“自己的狗粮，自己吃”思路。但是，不同的方面在于部门设置模式，我这里简要陈述下基于创新构建分析价值的三种不同运营模式：
分散式服务模式 这种模式往往喜欢把“分析专家”散放在各个业务部门，并且由每个部门的主管来管理，好处是业务的智能需求可以马上得到匹配，我刚来到华为就去马来西亚的TAC站点做了一次mini Design Thinking，通过两天的研讨会，快速理解了一线业务。因此，这种模式可以很好地接触一线，了解一线，支持一线，但是缺点也很明显，缺乏全面的跨职能的视野，仅仅落脚在自己的问题点上，而且在各个部门，重复性资源和重复性的工作太多，团队组织也是重復的，浪费很多资金，无法标准化或者扩大规模。
嵌入式共享服务模式 这种模式是过渡阶段，在一个业务单元里，比如华为的GTS，设置一个独立共享的分析组织，这个组织充分对于业务进行支撑，但是运作上又是独立的，好处在于可以在某个业务或职能内部设置标准化的流程和方法，并与各部门都可以进行协作，对于专家也可以共享，很多资源不是在某个点上，而是全面对业务进行统筹型支撑。当然在这个阶段数据分析资源还未形成一个专业化、体系化的运营模式，对于跨业务单元的部门而言还是存在重复性建设的问题，而且在专业化的集中度上也只是一个过渡阶段，还不能独立核算部门价值。
独立式共享服务模式这种模式是一个终极运营模式，完全的独立和标准化运营，完全作为一个公司内部的服务机构存在，对每个战略业务单元进行支撑和核算，完全关注在业务的服务提升上，而不是技术研发。在IBM深圳有个ISC部门，对于IBM全球供应链来讲，它就相当于一个“航塔”的角色，IBM的业务资源外包是做得比较彻底的，到现在很多给IBM提供Power芯片的芯片厂都不再属于IBM了，在这样一个超离散的资源架构里，这个“航塔”不断地对这些制造单元输出标准，采集数据，形成分析和预测，然后由这个“航塔”里的“数据科学家”来进行控制，使得到今天为止IBM的全球供应链控制力都超强。
这样的模式设计其实是在做企业级人工智能应该首先思考的，也属于人工智能顶层设计的一部分。另外，当这样的组织建设成熟的时候，又需要思考在这个独立分析组织内部的运营机制建设了。我比较推崇的是以“垂直服务化”+“散点创新”的方式进行运营机制建立，其实它也融入了很多DevOps的思想：一部分强调服务运营的持续化和深度，另一方面又提倡在创新上加入竞争，接受失败和快速迭代，后面的文章我会专门再详细地描述这种充满魅力和“时代感”的机制创新。