2000年以来，技术与战略仍然占据商业主流。很多企业都接受了信息技术可以提升竞争优势这一理论，但投入的努力却失败了。关键的断裂发生在战略与技术之间，这也是为什么很多企业花很多年时间规划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盖尔·柏克。

　　其他一些知名的高科技公司如travelstore.com和澳大利亚的CitiPower，都有类似的组织架构师机制联结战略与技术。IBM、Electrocomponents、劳埃德集团、特易购、HP、西门子、德意志银行、英国娱乐、嘉信理财等都承认，技术—组织之间的“伙伴”关系会从技术投入中获得更多的回报。

　　从这些企业中，可以得出一个组织架构师取得基本成功的普遍性的原则：

　　技术与组织的影响是同等的。

　　甲骨文采用单一的电子商务平台，结合了其集中化的业务支持功能，就是将技术与组织视为具有同样的资源灵活性的一个例子。

　　艾利森确立了三个原则。在每个国家每个业务流程使用单实例结构，代替现有的系统和数据库，他选择了一个单一的全球性版本的甲骨文应用系统与数据库。首先放到网络上，在网络上激活了应用系统，使员工与客户能够直接进入。同时在组织架构与技术上进行了强化。甲骨文以四个共享的服务中心(分布在不同时区提供24小时全球服务)为基础，构建了一个全球性的操作架构，同时在这个中心强化了IT与市场功能。

　　通过这个过程，艾利森构建了一个组织与平台，使甲骨文具备了相当大的灵活性在一个广阔的市场领域竞争。这个平台避免了重复性，加强了自我服务的运用。艾利森还通过简化许可协议，将产品简单化。在全球市场，他几乎可以毫不费力地进行信息沟通。

　　一些企业则鼓励关键的技术专家来增加专业业务技能。麦克理银行的架构团队非常重视培训员工了解企业的业务、文化与环境。银行各个分行的业务团队帮助这些员工理解那些需要开发前瞻性平台的业务的精确要点。

　　其他企业选择招聘拥有相关融合技能的雇员。CitiPower的CIO吉尔·利特高面临的挑战是建立一个平台支撑并未明确阐述的电子商务远景，雇用的员工至少要具备三个知识领域(运营、执行和战略)中的两个， 而且必须是“外向型技术敏感度高”。皇家和太阳联盟保险公司的CIO菲利浦·史密斯认为，这些涉及构建未来业务灵活性应该是“表面坚硬的变色龙”——在处理技术与业务的关系时很轻松，但与保守观点格格不入。泰晤士水务公司走得很远，其创新部门融合了重要的高管人员——技术架构师，测试和开发新的以客户为中心的技术。通过融合创新架构师的观点，构建了一个运营平台，泰晤士水务公司确保业务创新始终走在前头。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。