专访Ovum公司分析师Michael Azoff：如何创建敏捷企业

最新推荐文章于 2019-03-25 11:15:43 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2019-03-25 11:15:43 发布

阅读量226

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89094118

版权

在博文《如何创建敏捷企业》中，首席分析师Michael Azoff总结了Ovum在如何创建一个敏捷企业方面所持有的观点。Michael解释说明了何为敏捷企业的概念和目标：

\
敏捷企业的概念起源于那些遵循共同原则和价值观的实践，比如把生产高质量的产品和向客户交付价值放在第一位。
\
终极目标是业务敏捷，使各大主流业务流程都采用敏捷的工作方式，IT的使用效率得到优化，从“业务运行”到创新，从战术性的需求到能影响业务未来的长期战略性需求。
\

根据Ovum的说法，大型企业面临着三大挑战：

\
（...）首先，最成功的那些企业最终都突破了创新屏障的禁锢，并且打破了各种质疑最终实现了持续创新并且具有了新创企业一般的敏捷性和创新性。其次，年度预算流程严重阻碍了公司应对市场环境的变化响应能力，并且不利于组织策略响应这些变化。最后，软件开发已经在敏捷方法论的帮助下得到了转型，下一步就是对整个IT部门实施转型。
\

Ovum公司的报告“敏捷与精益业务转型”在如何利用敏捷-精益的原则进行业务转型方面提供了一定的指导思想。InfoQ为此采访了Ovum的Michael Azoff。

InfoQ：Michael，多谢你接受InfoQ的采访。你能跟InfoQ的读者简单的介绍下自己吗？

\
Michael：一开始我主要从事固态电子学的学术研究工作，接着转向工业研究与开发以及神经网络。经过一段创业期和IT咨询师的经历以后，在2003年我开始从事IT行业分析师的工作。虽然在经过一系列的收购兼并以后，公司的名字都已改变，但是在这过去的十年里，我们身边的同事基本上还是原来那些人：现在我们改名叫Ovum，是英富曼集团的子公司。在Ovum我是一名首席分析师，主要领导软件开发和生命周期管理研究工作，它主要涉及到相关的方法论和流程，特别是敏捷和精益相关的话题。
\

InfoQ:Ovum的报告探讨了与创建敏捷企业相关的三大领域：创新管理，组织管理和IT部门的敏捷性。为什么这些领域如此重要呢？

\
Michael：它们如此重要是因为它们代表了现今各组织要在当下的经济环境下生存下来时所必须面对的三大前沿领域；不仅包括最近上演的金融危机，还包括经济全球化所带来的日益激烈的竞争以及互联网所带来的商业改革。Richard N Foster研究了S\u0026amp;P500公司的平均寿命，它从十九世纪五十年代的平均70多年减少到现在的18年。因此，如果成功的公司要一直保持成功下去，那么创新就需要被放在一个高的优先级上。最近引起我关注的一点就是创新流程中的创新活动。比如，精益创业。第二大领域，组织管理，这又是另一个玄乎其玄的独立大话题，有无数的管理大师和MBA课程都为此在推销他们所谓的真相——我觉得一个比较有意思的东西就是一种跟敏捷和精益思想有很多相同之处，名叫超越预算的运动，我觉得正确的企业文化可以使组织跳出当前生存期限只有18年的怪圈。最后，对于那些把IT作为业务中关键因素的组织来说，IT部门的敏捷性起着至关重要的作用；敏捷可以弥补组织战略与愿景和现实之间的差距。起源于开发者的敏捷实践在运维的帮助下在IT部门的其他领域都得到了推广——最后的结果是理想情况下整个IT部门都具备敏捷性和精益思想。
\

InfoQ：小型新创企业所使用的精益创业方法被认为是创新管理的一个解决方案。你是如何在企业内运用精益创业方法的呢？

\
Michael: 首先，你需要得到一定级别的高层支持并争取到相应的预算，并且允许你在没有任何干扰的情况下在沙箱中运转。而且还需要划出清晰的界线以保护母公司的声誉，并且降低其品牌所承受的风险，因此，什么是沙箱允许做的，并且该怎么做都是需要经过严格界定的，但是一旦母公司和沙箱的关系确定了下来（可能是跨国公司的形式），那么沙箱就可以像新创企业一样拥有足够自由的权限。在Adobe的案例研究中，现有产品团队里的创新和精益创业沙箱中的创新主要的不同之处就在于产品团队的创新很少会超出他们现有产品的范围，然而，沙箱却可以利用他们的自由权限来创造一个完全崭新的产品。
\

InfoQ：你在博客上提到“要在产品开发之前进行顾客开发”，这句话是什么意思，它又是如何实现的呢？

\
Michael：这是Steve Blank所提倡，并且深远影响到Eric Reis及其精益创业思想的关键见解。基本上，当你梦想创建一个新产品的时候，你必须先搞清楚你的目标客户是谁：有许多失败产品的例子可以借鉴，产品中的创新却没搞清楚是否有人愿意购买这个产品。值得注意的是，许多企业并不记录他们自己的失败经历，随着人员变动和时间的推移，最终他们可能会重复这个失败，因此失败产品博物馆的成功就是一个很好的例子（主要是针对超市产品）：他们会购买超市货架上所摆放的每一个新产品。酸奶香波就是最好的一个例子。所以可以看出，顾客开发就是使你自己满意，假设你的新产品有一个真实市场，并且产品的增长规模也符合你的预期。精益创业的流程会很好地改变那些拉开创新周期变更序幕的原始产品，这就是顾客开发早于产品开发的关键所在，避免在未经检验的产品概念上浪费资源。假如你觉得这仅仅是简单的市场调查——顾客开发的精益创业模型被设计成一种科学的实验，用以检验各种假设并且由数据和证据所驱动，如果这个想法落空了，那么你就需要为下一次迭代创造新的灵感。
\
该如何实施具体要取决于你的市场，对于基于Web的业务，比较好的方式就是采用同期群分析，你可以跟踪新网站上的互联网用户群，并且调查他们的行为。当你对网页进行改变的时候你就可以看到这些改变对用户有什么影响，并且细化服务/产品以达到预期的使用和收入水平。
\

InfoQ：一旦你可以更好地理解你的客户，是否有更多的方式可以洞悉出那些你打算用精益创业的方式来开发的产品或服务的潜在商业价值（商业案例）呢？

\
Michael：当组织在研究新产品的时候，他们会谨慎评估其所期望的回报率：大的IT企业可能会拒绝一些完全可行的产品或服务，这样一来，其他的公司可能就会因此而死去，因为其收入水平不足以支撑大型企业的日常开销和各种资源投入。精益创业中的一项关键指标就是增长率，它应该与业务的期望所匹配。真实衡量这项指标的方法是被Ries称为创新核算，而且同期群分析也有助于解释这些结果。
\

InfoQ：企业中的年度预算会限制他们对市场环境变化的响应能力，就像你所说的。还有其他的替代方案来解决预算的问题吗？

\
Michael：我喜欢打个比方，将年度预算流程比作一年中只营业一个星期的银行。这种方法所具有的缺陷可以概括为：1.投入到预算过程中的资源都被浪费掉了，因为在一年中随着时间的推移，当初在预算中所做的假设跟现实的差距会越来越大。2.基于预算预估的的绩效目标同样也变得过时了。3.在一年中的某个短暂时刻进行有限的预算分配将会限制企业应对市场环境变化的能力。各大公司一直在尝试使用各种不同的替代解决方案，比如通过季度预算来进行滚动预测。超越预算（BB）的支持团队调查了那些使用相对更加成功的替代方案的公司，并将这些想法汇总起来，不仅可以用来解决预算的问题，而且还可以改善组织里的管理转型问题。
\

InfoQ：你能解释下什么是超越预算吗,它又是如何帮助企业的呢？

\
Michael：超越预算（BB）涵盖了很多领域，但总结起来如下：出发点就是要抛弃年度预算周期。当然了，公司还是有一些特定的理由需要定期的发布阶段性报告，但是内部预算可以被调整为连续的、基于需求和机遇的，类似滚动预算的，甚至可以是动态预测的。其次，与命令和控制相比，BB提倡由客户领导管理流程——这样看来，这就是在改变组织文化了，赋予一线管理者足够的权力进行决策，而不用事事都要向上级请示并等待批准。再次，BB改善了组织内大部分人员的工作环境——这更好的激励了员工。它利用上面所描述的传统预算方式帮助企业解决了所面临的三大困境。
\

InfoQ：在大型组织里改变预算流程是很困难的。我们真的要这么做吗，它能带来什么好处呢？

\
Michael：坦言之，对于许多公司来说，传统预算确实是一件劳神费力的事，所以大家都在热切期盼替代方案的出现。能否走的更远，能否抛弃那种指挥控制式的文化，主要取决于CEO及其对业务未来所持的愿景，以及现有文化在改变成BB式文化的道路上能走多远。组织文化的问题将作为Ovum中的独立报告——但是现在，我们不得不说还没有一个简单的诀窍能解决这些问题，如果抛弃指挥和控制会有损于公司的话，那么这种做法也就不是永远正确的了——这也就没有意义了，你需要保持随时待命的状态。那些采用BB的典型企业通常都会先选择一些观点，然后在进一步探索这些观点之前先检验它们。
\

InfoQ：你提到“在整个IT部门推行敏捷和精益创业”，但是那些连开发团队都尚未实施敏捷的组织该怎么办呢。他们是该首先改变其软件开发的方式呢，还是直接在整个IT部门推行敏捷和精益创业的思想？

\
Michael：首先值得一提的是，如果它没有出问题就不要修复它。如果瀑布流模式很适合你，没问题。但需要指出的是，瀑布流模式对于许多使用它的开发团队来说都是个问题，因此敏捷和精益的思想就有了忠实的拥护者。（年度预算流程也是如此）。一个敏捷的IT部门意味着在开发方面具有敏捷性，在运作方面使用运维的方式，在其他的方面也引入敏捷/精益的思想：网络工程师、数据库管理员、IT服务、网页设计师等等，并加上他们的管理者。开发者进行敏捷实践可以扮演催化剂的角色，在通常顺序的情况下，下一个就是运维人员，一旦敏捷开发人员进行产品发布的频率越来越高，那么运营对于改善其效率的压力也日益增大。要成为一个有效率的敏捷IT部门，就需要跟当前的主流业务而不是那些特例保持更加密切的关系。这对于技术型公司来说很好理解，因为他们的主流业务就是IT，但是对于其他行业，这种由于整个业务都采用敏捷和精益思想所产生的协同效应却很少能真正做到相互协调——更常见的情况是，同一个组织中的敏捷开发人员和BB拥护者由于一个美丽的巧合而相互结识。传统的年度预算是一个大爆炸/瀑布的流程，它妨碍了业务部门资助其IT项目。所以其实有很多机会可以改善参与过程并且弥补业务和IT之间的空白，更好地调整IT和业务的策略等等。这是我们多年以来的目标，而现在我们有机会弄明白如何去实现它。
\

InfoQ：敏捷方法论的根源起源于软件开发。当整个IT部门都试图采用敏捷和精益思想的时候，是不是意味着敏捷已经从团队扩展到了部门，一直到管理层（由下而上的）？敏捷方法论适合这样吗？

\
Michael：在IT部门中，在除了开发活动以外的地方实施敏捷并不需要严格地按照Scrum或者其他已建立的敏捷开发方法论来亦步亦趋的实施。最重要的是分享共同的价值观和原则，这样一来就可以阻止一些创建新流程的想法。以运维为例，操作人员需要编写和运行数千行的Perl脚本代码，这种情况下，直接实施敏捷开发的方法论是可能的。同样，有些组织也在业务流程中采用了Scrum的做法。关键是考虑如何在新颖的情况下采用敏捷和精益的的思想。
\

InfoQ：如果要采用敏捷和精益创业的思想，最大的阻碍是什么？我们又该如何处理这些阻碍？

\
Michael：要改变现有正在使用的流程是需要有充分的理由的。现有问题的关键需要被识别出来，然后定义一个新的流程来解决这些问题。创建一个愿景并达成共识，这就是为什么当实现一个变更的时候，人们就会克服那些不愿意变更的惰性，而这个惰性通常都会扼杀组织里的变更积极性。如果基层有一股强烈的变更意愿，而管理层却没有参与进来并且/或者漠不关心，那么这个变更就会受到限制。最起码你需要动员高级管理者和执行者这两个群体，没有这些动员的话，失败的风险将会很高。就算有了这些支持，挑战也依然存在，但是却有方法应对这些挑战。对于组织，变更最大的障碍就是其文化，以及新流程跟文化的兼容程度。改变组织文化是过渡到敏捷/精益时的一个巨大挑战，也是一个高风险的活动。
\

InfoQ：最近出现了很多针对运维的讨论。那么运维是如何帮助我们在企业内采用敏捷的呢？

\
Michael：运维运动是受到了开发中敏捷实践的启发，并且有助于打破传统存在于开发和运营活动之间的壁垒。它还会带来改善运营活动的新思想，比如发布管理中新工具和自动化的出现。因此运维有助于敏捷信息的传播（就像敏捷宣言里所说的那样）并且长期帮助整个IT部门进行敏捷转型。
\

InfoQ：如果组织有兴趣采取下一步措施来变得更加敏捷和精益，对此你有什么建议吗？

\
Michael：理想情况下，那些主动性最好是起源于CXO级别的高管们，但如果不是这样的话，那么就需要放一个案例在他们面前并且赢得他们的支持。如果得到了组织里最高层的支持，那么下一步就是设计出一个变更管理计划。这可以通过敏捷的方式进行，不信可以看看Mike Cohn在敏捷变更管理上的例子。组织应该引进敏捷精益专家和教练来培训和指导员工。在我的报告中使用了一个比喻，将一个敏捷企业比作一座高山，其中有很多道路可以通向山顶。在创新管理中使用精益创业，在组织管理中使用超越预算，在整个IT部门使用敏捷和精益的思想，选择以上所提到的组合就是选择了一条上山到达敏捷企业这个顶峰最好的道路。
\

InfoQ：你刚说到你可以用一种敏捷的方式来进行变更，但是从组织里的高层开始并采取下一步行动，在我看来像是一种自上而下的形式，类似于“瀑布流模式”。有什么替代的（并且更快的）方式可以使企业更好地进入变更模式吗？

\
Michael：这要看我们所讨论的是一个组织级的敏捷变更，还是一个IT部门内部的转型。在前面那种情况下，你必须得到最高层的支持，是的，是自上而下的，最起码在开始是这样的。变更流程可以变得很敏捷，比如，我们可以深入影响那些参与人，可以将变更以迭代的方式进行，可以更加透明等等。在后面那种情况下，你也可以在没有董事会参与的情况下进行的很好，但是得到上层人员的支持还是有好处的。
\
关于我们能够多快将敏捷引入变更这个问题，我们到底是采用大爆炸的方式一天内搞定还是采用循序渐进的方式引入变更，这主要取决于变更计划和当前文化的兼容度，以及其他实际情况。比如，Statoil就是以大爆炸的方式在其全球多个部门里同时采用了滚动预算，因为在一个公司里采用两套不同的预算流程，不仅会加大工作量，还会加深大家的困惑。
\
总结一下：为了使一个变更计划成功，你需要动员组织内抱有这个愿景的各级成员，如果人们没有这个愿景，那么任何变更流程都不会成功。
\

关于受访者

Michael Azoff（博士，美国电气与电子工程师协会成员）从2003年开始一直从事IT界分析师的工作，并将其超过20年的纯理论研究和应用研究及咨询经验引入到了IT界。在Ovum他主要负责领导软件开发和生命周期管理（SDLM）研究工作，最近他主要将精力放在了软件开发的敏捷性和精益实践上，包括企业的敏捷转型活动、运维、云相关的SDLM、应用性能管理、企业IT移动开发。