如何实现企业创新？需要转变为初创企业思维

对于寻求创新优势的企业，如何实现企业创新是他们关注的重点问题。初创企业的办法的确能带来回报，但转变仍然充满挑战，且不是所有企业都适用这样的方法。

初创企业和有一定规模的企业有不同的思维——且有理有据。一家有10名员工的企业能比一家有10000名员工的企业更快实现发展。规模企业支持着许多遗留系统，并有一定的客户群体。即使他们通常拥有更多的运转资金，他们的企业口碑也因为公司运作死板、缺乏创新、混乱频繁而变差。

因此，为了保持公司的竞争力，这些企业的股东和最高管理层会要求他们的IT团队以初创企业的思维工作。有时候这种思维转变是奏效的：哥伦比亚广播公司（CBS）的CTO Phil Wiser表示，他在之前的公司赫斯特国际集团通信部（Hearst Communications）担任CTO时，用了六年时间引导公司从大型企业转变为初创企业思维，这个转变让公司从新的技术操作中获得了更多的利益。美国利宝相互保险公司（Liberty Mutual）的CIO James McGlennon对此表示同意，他认为初创企业的思维方式能从效率的角度推动企业自动化和优化进程，让企业脱颖而出。

并不是所有企业都适用初创企业思维。但如果你的团队正在寻求这种优势，以下是成功实现转变的IT领导者们提供的几点关键步骤和方法论。

确定是否真的需要转变

“快速失败”、“关键转折”、“不怕犯错”这些流行语让初创企业听起来很酷，但并不代表规模大一些的企业也需要接受这些观念。万事达卡创新与创业实验室（Mastercard Labs）高级副总裁Debbie Barta警告企业慎防陷入她所称“两极化”的心态，认为初创企业千好万好，规模企业一无是处。她还解释道，“两者不是极端对立的”，初创企业和规模企业的思维模式都有各自的利弊。例如，更成熟的企业更能规避风险，相对的，初创企业在创造灵活敏捷的技术方面更在行。

在万事达卡实验室，Barta寻求的是皆大欢喜的“中间点”，先确认初创企业的可取之处、他们的思维模式以及他们运作方式背后的敏捷方法，然后从一个更成熟企业的角度去试行这些方法。她称，区块链、增强现实（AR）和物联网等新项目还更多地处在设想阶段，相对来说更有风险，也需要我们以更加灵活敏捷的模式去测试和学习。因此，要批判地看待你的项目，谨慎决定哪些需要改进，哪些不需要。

利宝公司的McGlennon在评估其组织需求时，认识到他们需要加快开发速度。“我们意识到，我们开发软件的整体方法，使用瀑布模型的方法论，门径管理和需求管理，接着还有设计、开发、测试等等，这样太慢了。”因此，利宝把其技术工作的88%都转向了使用敏捷方法。

有战略性地拥抱转变，扩大范围

看着这88%，我们很容易会想到利宝公司只是还没有开始着手转变剩下的项目。McGlennon则称，目前已完成的转变，花了他们四到五年的时间。“随转变而来的有对范围的考虑、有挑战，还有公司超过5000人团队的新技能培训。每天都像战场，挑战不断。”

但剩下的12%之所以仍然停留在瀑布模型方法，是因为他们故意为之。McGlennon的最终目标是让所有团队实现敏捷转变，但同时，利宝公司的运作建立在4000到5000个应用程序之上，其中许多程序如大型机遗留系统已有几十年的历史。他指出，这些程序“不适用持续集成和持续部署流水线”，也不能轻易进行转变。但如今企业资源规划系统（ERP）软件，人力资源管理技术以及其他后台管理系统都在敏捷方法之下运行，“我们能够很快就看到解决方案生效。”

不过如今利宝剩余的以瀑布模式工作的项目中，开发人员们一般以专门小组或是规模较小的多功能团队进行交替工作。McGlennon同时也消除了通信和操作方面的障碍，这些障碍曾经将保险业务部门与技术团队分隔开来。甚至那些还未采用敏捷方法的开发团队也需要有敏捷思维，专注于“哪些部分要优先处理，以及当数据运算指出优先选项时，需要学会接受”。McGlennon称，“我们希望确保我们的技术能够帮助分析收到的反馈意见，有用的就进行规模化，否则就及时关停。”

在此，快速的制胜造就成功的商业案例。哥伦比亚广播公司的Wiser指出，“当一个系统完全过时，你去跟那个团队的负责人说你要换成新的系统，这需要让他们从心里接受转变带来的价值。”技术部门的领导者需要证明他们做出的转变是明智的，不仅从技术方面，还有财务方面。他还说，“任何不愿意按要求做出转变的部门都会从财务方面说明他们不这么做的理由。所以，要准备好一个更有力的理由说服他们。”

最后，如果成功案例无法说服最高管理层，试着从安保方面入手。根据Wiser的说法，“网络安全最大的威胁之一就是那些落伍的软件系统。”

实现企业创新

实现企业创新

保持专注

初创企业分心必败。大众可能会认为，这些企业以风险投资为基础，投资过剩。但实际上其中只有6%有外部资金支持。大多数初创企业仅靠收入运营，他们无法同时承担多个项目。

Wiser指出，同样的，规模企业的技术部门如果贪心想做太多，也会失败。这不是说，这样做公司会倒闭，而是说这些项目会无法得到上级管理层的认同。“通信业务是赫斯特的重点，需要我们专注于此。如果你这一年内给自己定了20个大目标，你肯定会失败。”因此，他建议技术高管们“有计划地选择转变，一次一个。”

作为一个大型企业集团，赫斯特有50多名CTO。从前Wiser的职责是监督赫斯特通信这个专注技术的部门，开发项目，“卖”给赫斯特的业务部门。尽管其他人都争先恐后研发区块链和其他热门技术，他们自己是不能这样做的。Wiser按轻重缓急程度将项目划分为四类：探索、观察、原形开发和现金流投资。这让赫斯特集团能在保持专注的同时，密切留意未来可能需要的技术。

多构建，少开发

若你拥有庞大的技术团队，可能会考虑直接开发公司所需的应用程序。毕竟，公司自己最清楚自己需要什么，而且定制内部软件能在确保新技术满足业务需求的同时，避免功能膨胀。但McGlennon对此说不，因为这样的做法不是永远必须的。

威瑞森电信公司数字化转型首席技术官 Ashok Kumar表示，以聊天机器人为例，这项技术的开发需要好几个月，甚至好几年来从零开始做起。威瑞森用了十年开发各种机器人，但初创企业没有十年可耗。为了节省时间，他们通常借助一些现有的技术。因此，当利宝公司需构建一款专门的聊天机器人来处理客户索赔事务，工程师使用了亚马逊云计算服务平台（AWS）的产品Lambda（代码运行服务）、Connect（自助式联络中心服务）和Lex（对话界面构建服务），大大加快了研发进程。如今这款机器人每月能处理超过150000通客户电话。

降低标准，避免过度投入

“快速构建，快速失败”听起来老生常谈，但的确是初创企业的成功秘诀。因为小型企业既不能分心，也没有太多时间可用来犯错。比起在发布之前将软件做到完美，初创企业通常会构建一些最简可行的产品（MVP）。他们的用户界面通常制作粗糙，且这些基础版本没有任何附加功能，但初创企业能快速上线这些产品以尽早收到市场反馈。

对于那些习惯于向领导展示完美产品的工程师而言，要做到这一点很不容易。McGlennon称，这是要通过改变他们惯用的工具、流程和方法，“来彻底地改变他们的行为，并树立对产品全新的标准预设。对每个人来说，要一时间完全接受这些，都是很难的。”

McGlennon称，为了让员工更好适应转变，利宝公司很早就开始设置新的标准，公司告知员工“在各种事情上犯错了也没关系。”但他同时也说，技术领导者们也向团队明确支持：“我们要尽早开始构建，这意味着一旦我们了解了我们的目标，就要着手构建；而且，我们并没有几个月的时间可以耗费在搞清楚我们需要什么样的成品和产品将怎样运作的问题上。”

最后，利宝公司在28天内成功构建出一个摩托车保险客服平台。根据McGlennon的说法，这的确是MVP，但也是一条确认投保人是否会使用这款产品的捷径。“你需要提供一些例子，指出最合适的方向，来帮助人们了解事情改进的方法，接受并使用这些方法。”

总而言之，从初创企业学到的还有一点：成功乃成功之父。

原作者：Terena Bell

原文链接：https://www.cio.com/article/3391205/making-the-shift-to-a-startup-mentality.html?upd=1558936214411