组织经常根据业务需求和对IT或运营的技术支持来设置工作岗位，但电子商务战略的不确定性，个别的角色调整可能也是一种解决方案。

　　■ 文/克里斯·萨澳　 莱斯利·韦尔考克斯

　　■ 编译/弘毅

　　0年以来，技术与战略仍然占据商业主流。很多企业都接受了信息技术可以提升竞争优势这一理论，但投入的努力却失败了。要害的断裂发生在战略与技术之间，这也是为什么很多企业花很多年时间规划IT战略却仅执行一半的原因。

　　未来竞争的变化也在战略与技术之间带来了很大的一个差距。高管人员忙于建立和提炼愿景，没有时间关注技术。技术人员忙于让目前的平台正常运作，没有时间深刻理解商业。这些技术人员都有远大的愿景、实用的信息和强大的运作系统，但却不知道这些对商业而言意味着什么。

　　不少企业都错误地假定，战略家和技术专家会通过与其他人非凡是IT专家的沟通，而保持一致。一个大型企业的IT主管评论说，企业都在追求电子商务，但我不能让任何人清楚地说出电子商务的模型在2-3年后会是什么样的。另一方面，战略家需要IT提供要害的技术将商业伙伴连结起来，但却提不出任何方案实现这个连结。治理人员希望IT能够更新技术结构，却保持老旧的应用软件。持续的会议讨论使双方在结果上接近但内容却越来越多。高管人员最后也成了一个技术专家，听取讨论技术问题成了日常工作。

　　一些企业指望CEO或CIO解决问题，但很少人具备将技术与思维完美结合的角色。很少CEO会将IT视为企业治理的核心，即使CIO对CEO的内心极其了解和信任，但CIO对组织的设计往往都有一个较为浅薄的理解。

　　也有一些企业成功地将业务与技术结合到一起，成功“嫁接”的组织中都有一个要害的核心人物主导，这些人既不是战略家也不是技术专家，却引导战略愿景向一个灵活的、整合的平台转化。这就是组织架构师：在愿景策划者和技术专家之间维持对话，界定和实现了结构、流程、能力和技术的完美融合，对组织的目标做出回应。使真正的协同配合成为可能：平台基于愿景形成，愿景在定制化平台的支持下改造后得以实现。

　　组织架构师做些什么？

　　组织架构师和战略专家、技术专家一起工作，通过其支持平台，确认、培养组织和技术需要实现的愿景。架构师必须是一个专职人员，而不是CEO或CIO，但要害的高管人员的支持是不可或缺的，而且架构师必须是CEO所信任的内部核心圈的人。拥有直接的战略变革经验的也是组织架构师的合适人选，战略主管可以成为一个架构师，但必须与技术专家一起合作过一段时间，对平台的问题有较深的知识与了解。

　　架构师通过三个主要的转变阶段了解愿景(参阅企业愿景怎样转化成一个灵活的平台)。架构师参与的每一个阶段都必须是连续的，包括评估、修改、沟通和重述。

　　第一阶段：从愿景到组织　

　　假定一个零售银行有一个愿景“成为我们的客户信任的合作伙伴”。经过反复的质疑、沟通，组织架构师将愿景变得更为具体化：通过简化他们的手续，成为我们的客户唯一的银行与金融服务提供商。成为客户“唯一的提供商”意味着重视关系治理。“简化他们的手续”则意味着每年都要以一种简便的、个性化的方式将银行帐号简化，给客户提供服务。架构师与CEO的核心圈子人士讨论愿景，他们决定强调客户关系更甚于简化。

　　然后，组织架构师设定将愿景变成现实的组织结构、流程和能力的参数。关系治理作为核心因而是稳定的，因此，架构师规划一个结构时要基于客户细分，银行根据收益率来治理不同的客户。为了强化客户的信任，银行需要测量、调控和评估工作流程。利润率来源于对老客户的销售，因而架构师需要规划一个支持跨区销售的组织。

　　第三个步骤是确定愿景中哪一个灵活性是最重要的。一个是客户细分，客户细分会让银行明白哪些客户带来最多的利润。银行需要采取一些方式了解和分析客户行为，在业务单元中互换客户与服务。同时也需要在怎样提供产品中保持一定的灵活性。比如可能会培育所有自有的投资与保险产品，可以是扮演一个给其他企业的品牌产品的中间角色，也可以是塑造自有的产品品牌。

　　总之，组织必须在新产品培育和产品资源中取得一致。假如银行没有购买金融产品的经验，可能就需要3年时间来培育或并购来获得这方面的能力。架构师需要在快速获得能力与并购的挑战之间取得平衡，这也要提交给CEO的核心圈子进行讨论。

　　第二阶段：从组织到技术需求

　　架构师现在着手绘制银行的组织需要的平台特性。核心的组织需求可以直接处理，以客户为中心的设计意味着对所有的客户信息、所有的渠道都有唯一的通道，这意味着跟进所有客户从内部客户沟通到产品/服务传递，都需要较强的能力和高效的流程。

　　较大的挑战是界定技术需求，以满足第一阶段中确定的组织灵活性需求。这一平台不仅要支持自有产品的开发与维护，而且要联接金融服务企业的既有产品。假如银行决定购买产品资源，平台就必须使其更易于吸收和整合其他系统，这可通过采用标准化技术来实现。然而，假如银行需要改善其自有的产品培育能力并有足够的时间做营销，就需要整合各个结构要素和可重复使用的技术模块、快速发展的技能与工具、界定严格的治理流程、简短的项目、与IT供给商反应式的关联。

　　第三阶段：从技术要求到实际平台

　　架构师现在就要通过与技术专家的沟通，确定技术上实际上能实现哪些功能，确定一个可行性方案。这一对话的起点是现有的技术，最糟糕的是点解决方案的收集，然后做一个部分的融合来建构系统，最理想的是基于客户。

　　由于银行是一个综合性平台，针对所有储蓄与投资帐户有着统一的客户数据库。假设技术专家说，适度的成本投入可以扩展数据库就可以合并贷款与抵押，但他们并不能在缺乏一个重要平台更新的前提下，将所有的金融产品与客户整合到一起。他们很自信可以建立一个新的平台来支持组织灵活性的需求，但支持产品资源必须使用未经证实的安全技术。

　　这种情况下，组织架构师必须明确两点。第一，以创新的整合安装一个新的以客户为中心的平台，这有很大的风险。第二，合并银行的平台，一般来说，保险与投资产品的两个平台是分开的，现在要进行整合。最终的结果是，组织结构是灵活(可以将最合适的产品传递给最适合的客户)而安全的(结构要使银行产品与其他的产品保持独立性)。而为了提炼愿景中可实现的目标，架构师要将所有选择都提供给CEO及其核心层。

　　伙伴原则

　　尽管没有企业有一个组织架构师执行上述所概括的精准的任务，但高科技公司或很有业务头脑的CIO们都在谨守类似的原则。IT行业在这方面无疑走在了前沿，高管非凡理解战略、组织与技术怎样关联。两个最为明显的例子是甲骨文的CEO拉里·艾利森和澳大利亚麦格理投资银行的COO盖尔·柏克

[1] [2] [3] 下一页