如何实施IT战略——宝智坚思关于发展电子建设的手册系列
如何实施IT战略——宝智坚思关于发展电子建设的手册系列
本指南是宝智坚思关于发展电子建设的手册系列的一部分。
简介
这本详细的手册是关于如何实施一个IT战略。这是一个宏观层次的文档，其目的是对于该主题给出概要性的帮助，而并非是一个具体的行动手册。之所以采取这样的方式，是由于每个公司都有着不同的要求，其要求依赖于公司的规模、从业活动以及IT战略实施所需的范围。
贯穿整个手册系列的原则是所有的IT开发都应该由业务所驱动。因此，它应该在大多数的建筑业活动和业务过程中起着重要的作用并且应与其紧密集成。
IT的实施过程
前提
在已经基本确定一个基于业务的IT运营的总体发展方法之后，本报告对于IT的实施作出了一些前提假设，如下所述：
- 您已经决定了您的公司需要一个IT战略
- 您已经从您公司的业务规划中得出一个IT战略，及其相应的要求
- 您已经审查过公司的业务过程，并已经识别出相关的需要考虑的业务领域
- 您已经决定了您的信息流程和系统要求
- 您已经进行了成本/效益分析
这些方面已经在其他的宝智坚思手册中进行了说明。
在这本详细的手册中，我们主要探讨以下几点实施问题：
整个IT实施过程的宏观层次示意图
1. 基本实施规划的发展
1.1 实施战略
关于实施规划的最重要方面之一（假如不是最重要的方面）是必须由业务所驱动。
这可能是显而易见的，但也经常被忽视，尤其是在那些具有许多部门或运营单位的公司。
比如，公司的管理中心可能决定实施一个全面的IT战略，但该战略不一定能得到所有组成部门的支持。结果，许多用户对此予以抵触或消极参与，这将导致新IT战略的实施十分困难或几乎是不可能。因此，实施战略是至关重要的。
以下是需要考虑的因素：
正如已经提及那样，对于新系统详细规范的发展，您必须已经审查目前的业务过程并关注通过新系统的实施需要改善的领域。
您还需要已经描绘出所希望实现的新的业务过程。
1.2 过程改变
新系统经常由基本业务过程的改变所引起，虽然有时候只有通过新系统的引进才能导致过程的改变。
但无论如何，改变应该是由过程而不是由IT所驱动。
如果可能的话，最好对业务过程的改变或者通过人工的方式或者借助于已有的系统。如果不可能的话，则有必要告知用户为什么过程需要予以改变。您还需要解释，改变过程或工作方式的不是计算机而是业务的要求。
在系统的实施之前，还有必要得出正确的改变方法。
变革管理过程不应该被低估。
1.3 组建项目团队
每个项目都需要一个负责人，该负责人在公司中的地位应该足够高层以处理一些事务，但也不能让项目团队中的其他人员觉得根本无法与之协商或者是在项目的不同决策中仅仅具有完全平等的权力。团队需要体现公司的不同方面，当然也应该确保团队不包含过多的人员以至于失去灵活性和效率。
团队成员需要具备一定的能力，以向其工作伙伴传达进展、寻求建议和承认。尽管团队成员并不是总是能够体现或获得公司中任何一个相关方的意见，但他们还是应该尽可能公正地反映所有相关方的意见。
1.4 集成
如果IT战略包括一个或多个解决方案的实施，并且您打算将数据从一个系统传递到另一个系统，则您需要考虑系统的集成问题及其实现方式。在此，需要注意到系统“集成”与系统“连接”之间的区别。系统之间进行双向的沟通称为“集成”，而单向的数据传递只能称为“连接”。
在本报告中，我们将“集成”定义为一个系统准备数据的场所，这些数据被传递到另一个系统，该系统对数据进行操纵并使其增值，然后将数据发送回第一个系统。这样的描述同样也适用于许多个系统，这些系统使用存储在一个地方（比如在中央系统中的一个数据库）的共同数据文件，比如名字和地址可以在任何一个不同的系统上予以更新。
系统的“连接”指的是一个系统发送数据的场所，而且数据的传递仅仅是单向的（或者根本不或者很少重新发送回去）。举个例子，一旦一个投标书已经成功，则可以将估价数据发送到一个工料测量软件包。
一个简单的区别方法是，集成化的系统需要进行双向沟通，而相连接的系统则往往是一次性的传递。
1.5 次序
在实施一个多重解决方案的战略时，还需要考虑业务过程中所发生事件的逻辑顺序。因此，您可以以一个结构化顺序的方式来实施您的系统，比如：
- 在估价之前进行市场调查
- 在评估之前进行估价
- 在估价之前进行规划
对于评估和估价而言，这种方法尤为有用。为了有效地使用评估系统，需要建立和输入大量的数据。这方面的绝大多数信息来源于估价系统。通过一个有效的界面连接，这些信息可以在几个小时、几天之内予以建立和传递，而不是几天或几周。因此一旦工料测量人员了解到该过程的速度，他们将会十分希望使用该系统，而不会象往常那样经常因为时间来不及而道歉。
另一个例子是在概念设计软件之前使用概略设计软件，所以来自于一个系统的信息可以传递到另一个系统。
除了决定一个合理的、实用的业务方法之外，在确定实施的次序中还需要考虑其他一些因素。最显而易见的一个因素是通过更换老的、低效的系统（其运行成本将会十分昂贵）来实现成本的大大缩减。
通过将替代的新的系统予以早期实施可以迅速节省一些成本，这将有助于支付其他新系统所需的开销。
特定的要求（尤其是客户的特殊要求）也可以改变事件的优先次序。
1.6 多少时间之内提交解决方案？
这对发展方法的选择有着很大的影响。如果解决方案必须在很短的时间内给出（明确定义最终期限），您将别无选择而只能使用软件包。这可能是唯一的解决方法。但假如您有充裕的时间，则您可以选择自行开发您的系统。
软件包和定制软件之间的优缺点比较将在后文讨论。
1.7 时间范围和资源
现在让我们考虑规划的整个时间范围。
“实施的选择”阶段应该尽可能的短。一旦您已经开始该过程，则必须尽可能快地予以尝试和完成。不应该调动起人们的欲望，但却然后使得他们等待几个月而没有任何动静。
为了避免这种情况的发生，需要考虑两个问题：
该系统能够在允许的期限内得到实施吗？
在该时间范围内，您具有足够的资源来合理地实施该系统吗？
伴随着这些考虑，您还需要对“期望”进行管理。
1.8 期望
维持用户的期望并使其了解各方面的情况是十分重要的，这是由于系统实施的较长过程会引起人们挫折感并最终导致积极性的丧失。如果您已经花费相当长的时间来正在详细说明和选择系统，并已经宣布这些系统将于某个月开始安装，用户的期望将会比较高。然而，如果您有12个方面需要予以实施，而且每个月仅能完成一个方面，则全部完成实施需要12个月的时间，然后一些关键的对系统进行了选择的人员可能需要继续参与。
显然，这不符合每个人的利益。
为了缩短这段时间，您将需要考虑另外的实施资源。您所要对其实施系统的业务或单元也需要考虑自身资源的问题。
业务总是很少会有多余的资源，您一般是通过IT来替换或更新一个目前的系统，该系统在此同时也必须予以维护，以确保维持数据的相关性和可用性。对于审计系统而言，尤为如此。结果，经常会出现老的系统与新的系统同时运行的情况，直到对新的系统有了足够的信心。
然而，两个系统的同时运行至少会导致三倍的工作量，因此为了实施的顺利您可能需要雇佣暂时的资源。
2. 软件选择
2.1 详细说明书
一旦已经了解对系统的基本需求，就很有必要编制一个更为详细的说明书，该说明书一般被称为所谓的“用户需求详细说明”（URS）。为了编制的目的，应该确定和获取潜在用户的所有需求情况，然后使用以下的优先权指导原则将这些用户予以分类：
- 基本--系统必须具有这些要素，否则将无法使用
- 有益—没有他们，系统也可以运行；但有了他们，系统可以增值
- 更精美—这如同蛋糕上的糖衣。如果系统能够拥有这些要素，那很好；但如果没有，您也可以应付得过去
编制URS的过程在更大程度上是一个往复的过程而不是一个线性过程。
在一开始，是由某个人员在纸上记下他们的需求，然后将其转交给其他的系统用户，让他们发表意见并添加其自身的要求。应该任命一个人员来对各种反馈进行协调，并定期更新详细说明书。该过程不断继续，直到完成最终的文档。作为该过程的一个不错起点，也可以对各种软件供应商所提交的合适的软件包进行评论，这是由于用户可以借此充分了解目前已有的许多典型要素。
如前所述，在编制用户详细说明的过程中，应该针对您所希望实现的业务过程结果。
2.2 软件包 VS 定制软件
当要确定您的软件获取途径时，您需要在购买现成的软件包和定制软件之间作出选择。
对此，需要考虑以下这些问题：
- 发展时间/软件的可获得性？
- 自行开发您的软件将花费多长时间？
- 有没有现成的软件包？
- 这样的软件包需要进行修改吗？
为了回答这些问题，值得对软件包和定制软件各自所涉及的不同方法予以考察。
2.2a 软件包
软件包指的是目前已有并且可以从软件供应商处以完全打包的形式来购买的软件。软件包的开发目的一般是满足整个行业的要求，因此在本质上往往难以100%地符合您确切的目标。
如果将您的URS与软件包的特点进行比较，您可以确定软件包（能有70%的符合程度就可令人接受）一般提供：
它满足您基本的要求
它该做的方面，做得不错，并且……
它在目前系统的基础上有所改进，比如提供了与其他系统进行集成的能力
许多软件包的共同问题是它们能够满足您的大多数要求，但在某些方面它们还需要予以加强。以这样的方式，软件包从其最初的原型得到发展。
然而，需要注意到您要进行的定制工作量。无论如何，需要确保所进行的任何改变应该针对基本的软件包，而不只是您的那个版本。否则，您的版本可能会由于不协调而无法利用原始产品最新版本所带来的好处。
软件包的一大优势是它们将不断发展和更新。软件包可以得到其他用户的输入所带来的好处，而不仅仅是您自己。因此，未来的升级可能会增加一些额外的有利的工具，对此您可能根本意料不到。
总之，可以认为“软件包通常提供更好的支持”。
2.2b 定制软件
定制软件指的是或者由您的人员内部开发或者是由他人根据您的确定要求所开发的软件。因此，这样的软件应该几乎能够100%地符合您的要求，这是其主要的优点。
如果是寻求外部组织的帮助，开发您定制软件的另一个方法是与软件供应商建立一种合作关系。在这种情况下，他们按照您的确定要求来开发软件，但他们保留将您的系统也卖给他人的权利。如果您的应用软件或者是其一部分在通用的市场中具有较广阔的前景时，这种情况常会发生。
不应该低估定制软件的开发时间。
对于用户而言，在最初的尝试中有时会得出不正确的软件详细说明书，所以在开始编程之前最好是采用一些快速开发原型。这可以帮助用户了解其功能需要及其界面的外观。
如果您并不是与一个合适的软件供应商合作来开发软件，则您开发的软件往往只是停留在第一个形式。这是由于一旦您已经得出合适的基本软件模块，它们往往会由于资源的缺乏而停留在同一个层次。此外，不象通用供应商所提供的软件或软件包，您不可能从其他用户那里得到反馈。
最后，不要忽视对任何已有软件提供支持的要求。
即使是最优秀的软件也无法避免含有一些小缺陷，所以在最初的几年之内您的应用程序将需要予以不断地修正以确保能够满足您用户的需求。因此，需要仔细地考虑内部开发的一些问题。
值得注意的是，进行计算机软件开发的往往不是您的核心业务人员。
2.3 寻找供应商
不管是寻求标准化的还是定制的软件解决方案，您都需要开始寻找合适的供应商。
尤其是对于定制软件而言，您更需要选择那些能够让客户满意的、具有良好成功记录的、对类似系统开发具有丰富经验的咨询顾问/软件开发商。
2.4 选择软件包
安排一小部分的用户来观看可能是合适的软件包的最初演示。这将有助于了解目前已有的一些特点。
在备择的软件包名单中，删除那些不能适应您技术环境的或是过于通用的软件包。尽量将该名单缩减到大约6个可能的供应商。
通过在演示中所观察到的任何特点，完成您的URS，然后将其发给可能的供应商，要求他们提供更为明确的演示/专题讨论以使其实现，您也可以趁这个机会来详细审查您的要求。当所选择的软件覆盖多个学科时，您可能需要进行多个演示。
通过这些演示，用户可以按照其URS将每个供应商的软件包的不同特点进行评分，然后选择最为合适的产品。此时，您将需要通过真实的数据在一个模拟环境中试用该产品，也就是让您自己的客户来对该系统进行数据的输入和输出。这最好是在供应商所要求的前提下进行，因为在这个阶段您可能还没有足够的培训。
一旦您对软件表示满意，认为它将能满足您的要求，则您应该与供应商确定一个实施计划。在此时，您还必须对您和供应商在该项目中的投入资源量予以考察。然后，您需要对该软件包进行尝试。
作为尝试，先选择您公司的一部分来使用该软件。在这个最初阶段，仔细监控实施的过程并记录任何一个您可能要对该软件所做的更改。然而，不要过早在项目中进行更改。
由于用户总是希望以他们所惯常的方式来处理事情，所以不要作出不必要的更改。一般而言，人们总是拒绝改变，但这不应该导致优秀的软件也因而作出多余的更改。因此，与供应商和您的员工共同进行调查，是否存在另外的方法，一方面不需要更改软件，另一方面也能够实现用户所希望的特点。
识别任何所需要的根本性的更改，并与供应商协商原定目标的实现方法。除非软件的更改能够给予您的公司以重大的竞争优势，否则总是确保供应商所更改的是基本的产品，因而您的版本与其他完全一样。
2.5 软件开发
对于定制的软件，应该与用户共同讨论确定详细说明书，对此可以尽可能地使用各种图表来向他们表明数据流程、界面设计等等。可能的话，应采用快速原型开发的方法。在用户、设计人员以及编程人员之间进行专题讨论以探讨详细说明书，必须总是确保软件设计人员能够充分理解您所期望的目标。
有必要与软件的开发人员一起确定一个工作计划。该工作计划应该进一步分解为可控制的工作单元，并应该包括一些里程碑成果。然后，选择一些用户参与，其职责是审查工作的进展并审批所提交的软件部分。另外，还有有专门的人员来确定系统开发的最终结束时刻。
还应该确定所要采用的具体的变更控制程序，确保任何参与人员（尤其是项目负责人）能够很好地了解任何所提出的对于详细说明书的更改。
然后，正如同软件包那样，下一步是进行试运行。
选择公司中对该系统最感兴趣的一个部门，并监控其使用情况和反馈。
将他们所遇到的问题以及任何对于系统的更改建议予以仔细地记录。应该使得这些问题能够迅速地被确定，但如果可能的话，直到您已经完成了一定程度的测试和使用，才作出相应的更改。然后，与项目团队一起审查所提出的更改建议，并对所需的更改达成共识。依赖于最初的详细说明书的完善程度，这个过程可能需要重复许多次。
3. 实施
3.1 技能的审查
在这个阶段，您应该已经具有一个被认同的解决方案，所以下一步是确保用户有基本的技能，以使得他们能够充分地利用这个解决方案。
为此，在您打算实施新解决方案的部门中可以进行技能的审查来衡量知识和技术的程度。在更换IT使用环境类型的情况下，这显得尤为重要。比如，从一个死板的DOS应用程序更换为Windows环境。
尽管有些用户可能对已有的一个软件包比较熟悉，但他们不一定也了解不同类型计算机的基本应用。
这个审查的阶段可以与任何一个测试过程同时进行。
3.2 数据准备
对于数据准备，您需要确定哪些数据将从任何一个已有的系统传输到新的解决方案。在此时，应该对所有的老的数据进行整理。一旦您已经将这些数据予以传输，它们将很难再得到整理。
确定最佳的方法，以使得数据在两个系统之间进行传输而只需要尽可能少的人工干预。另外，还需要确保任何您所传输的数据都是有效的。向一个数据库输入数据当然是十分容易的，但有时当一个用户在以后某个时刻访问该字段的时候，却发现包含有无效的数据。例如，名字和地址已经被输入，但省份却被错误地输入在城市字段中而且对邮政编码字段没有任何输入。当这些字段被确认时，系统将不允许您离开，直到您将其改正。如果一个用户仅仅是访问一个记录，并发现被一再要求提供正确的数据而无法离开，他必然对系统十分恼火。
3.3 培训
培训是成功实施的关键，可以确保您拥有合适的“原材料”。
将人员在相关数据的基础上并且以您公司希望使用该软件的方式来进行培训。当所使用的软件包比较复杂而且可以以不同的方式来予以使用的情况下，更是尤为如此。当然，还要按照用户的特点来定制培训内容。同时，还应该识别出那些“超级用户”，即部门中的其他人在无法确定软件某个方面的时候可以求助于他。
当实施一个复杂或综合性的战略时，应该与用户和供应商就各阶段所需的培训达成共识。必须从用户和实施者两个角度来考虑实施所需要的资源程度。培训和实施之间的联系应尽可能地紧密，并确保当用户返回到其工作场所的时候，他们能继续熟练地使用该软件。
对于用户而言，最糟糕的情况莫过于得到了良好的培训，但却没有机会将其所学到的东西进行实践。他们将迅速忘掉所学到的东西，并在后来真正需要的时候却只能再次进行培训。
3.4 用户的重访
一旦已经安装了解决方案，您将需要重新访问用户，以了解解决方案的运行情况及其使用方式是否恰当。
对于多重解决方案的实施而言，建议以渐进的方式来发布软件，这样用户可以逐渐熟悉其相关的部分。
对于正在运行的系统的任何升级或补丁，应小心地予以实施。记录升级或补丁可能引起的任何变更，并告知用户变更的发生时间以及变更的内容。
4. 支持
4.1 可能性
实施战略并不是简单地随着软件的实施就结束。任何系统都需要进一步的支持，您将需要考虑如何为用户支持提供帮助。
对此，第一个问题是：“您将借助于软件供应商吗？”
这种情况比较常见，但还存在着其他一些可能性。
4.2 问询处
在借助于供应商的外部支持部门之前，您可以考虑建立您自己的问询处来提供第一线的支持服务、基本问询的过滤以及简单问题的解决。如果您能事先将用户的各种请求予以过滤，则往往可以降低支持服务的费用。
建立问询处的一个重要优点是可以改善缺陷或问题的报告及其相应的分析。通过对此进行定期的检查，可以查明额外的培训需求或系统的更改要求以避免经常复发的问题。
4.3 用户群
维持产品发展的一个好办法是通过用户群。这可以是内部也可以是外部。
内部的用户群能帮助您的用户完善其产品使用的技能，而外部的用户群则能促使产品本身的进一步发展。在任何一种情况，这些用户群都必须由用户所引导。
对于维持IT的中心地位而言，一个十分重要的方法是让最终用户积极参与。
宝智坚思--工程项目管理软件专家