系统规划阶段的工作会直接或间接影响以后几乎所有的工作，一个不小心就会导致无穷无尽的麻烦。这里有几个注意事项，希望读者在工作过程中注意。
根据处理业务规模的大小，程度的深浅不同，在推行信息化管理的过程中或多或少都要对企业的管理方式、工作流程进行重新设计，这就是所谓的“流程重组”。虽然以定制开发为主的解决方案，对流程重组的要求不如套装产品那么严格，但是要知道，流程重组是躲避不了的。流程重组是一次管理变革，而变革总是会遭到大部分人反对的，可能这个变革未必会损害他们的利益，这些人只是因为见识、习惯、思维等方面的原因反对这种变化，因为改变习惯总是痛苦的；另外，变革总会损害一部分人的利益——可能是经济利益受损，可能是工作负荷增加，可能是工作职权变化，甚至可能有失业的危险。
认清利益受损者，是系统规划阶段的一项重要工作，要对在信息系统建设的过程中来自这部分人的阻力有足够的心理准备，触动利益比触动灵魂还难，虽然这部分人是少数，但他们带来的阻力比单纯反对变革的阻力要大得多。
有两类工作最容易影响士气，一是重复劳动，二是返工（或许返工也是重复劳动的一种）。同样一件事，做一遍新鲜，做两遍无聊，做三遍厌恶，做四遍就要崩溃了。重复劳动，会严重影响用户体验，从而给信息系统的推行带来阻碍，因为人并非机器，不可避免地会把情绪带入工作。在进行工作方式规划时，要注意尽量避免给用户带来重复劳动（无论这种重复劳动来自于你的系统还是别的系统），重复劳动可能会导致软件根本无法上线投入使用，或者即使能勉强上线也不会有好结果，轻者天天有人发牢骚，导致你的软件或团队在客户那边声名扫地，重者消极怠工，拒绝使用，导致软件下线，最终不得不宣告项目失败。
对于一般用户来说，使用软件的大部分工作量都来自于数据录入（用户使用软件，无非就是调用功能、输入数据、软件系统加工处理、展现信息这几个过程，后两个过程是计算机完成的，需要耗时很少），因此重复劳动最大的可能性来自于数据的重复录入。如果规划、设计不合理，稍有不慎就会给用户带来重复录入数据的工作。
数据重复录入，可能是某些数据，明明在这个岗位或者这个工作步骤录入了，到另外一个岗位或者另外一个工作步骤，这些数据或者其中的一部分还需要重新录入一遍。
案例：直接重复录入数据
有甲、乙两个车间，在工序上是前后道，即甲车间的产品是乙车间的原料，甲车间的每批产品加工完成后，甲车间的记录员会登记该批成品移出本车间的时间，而乙车间的记录员又会登记接收该批产品的时间，事实上，这两个时间是一样的——这是典型的数据重复录入。
数据重复录入，也有可能不是这么直接。可能在某个岗位或某个工作步骤录入的数据从表面上看不像重复录入，但仔细分析下，发现这些数据跟其他数据有很强的逻辑依赖性，完全可以通过某种运算计算获得，这也算是数据重复录入的一种。
案例：间接重复录入数据
某公司人力资源部使用的人力资源管理系统中，有一个功能“员工基本信息管理”，管理员工的基础信息，包括工号、姓名、身份证、手机、住址、入职日期等。另外还有一个“年假管理”功能，管理员工每年应休的年假天数，已使用的年假天数，剩余年假天数。应休年假天数由用户在每年年初录入系统，已使用的年假天数从请假功能中抽取，两者的差额为剩余年假天数。
仔细分析下来，发现这里就有个数据重复录入的过程。应休年假天数跟员工在本公司的服务年限相关，计算的规则是，从员工入职那一天算起，到当前年份的1月1日，为员工服务年限，服务年限在1～3年一个级别，3～5年一个级别，等等。根据这个规则，完全可以根据员工的入职日期计算出来员工的应休年假天数，而不需要用户录入。
数据重复录入往往产生于三个方面，一是因为没有站在用户的角度规划与设计系统，上面的两个案例都属于这个方面；二是因为软件需求的变更与追加，在软件实施过程中发现缺少某数据，只好追加这种数据录入的功能，虽然这种数据跟用户在其他功能模块中录入的某些数据重复，但由于数据录入与处理的场景、规则不同，对于开发者来说，开发个新的录入功能比从其他功能模块通过一大堆规则抽取数据要简单得多，于是就产生了数据重复录入的问题；三是因为没有处理好软件与软件之间的关系——详见3.4.3节。
对于软件系统内部的事情，比较容易控制，因为功能也好，数据也好，都是统一设计的，你自己的软件做什么，不做什么，都可以统一规划，但千万不要忘记一点，大部分情况下，客户使用的软件不止一家，你们只是这个客户的若干软件供应商之一，所有的软件都是这个客户的信息化管理体系中不可或缺的组成部分。要规划你的软件如何跟这些已经存在的软件通力合作，共同为客户信息化管理体系的构建提供支持——这个就有点儿麻烦了，因为有太多的事情超出了控制范围。如何处理好软件之间的关系，是系统规划阶段的难题之一。
有些软件跟你的软件是完全不相干的领域，一般不需要考虑跟它们的关系。例如，你做OA系统，别人做工艺CAD系统，前者主要在于通知公告、沟通交流、办公流程的处理，而后者主要在于产品设计图纸的制作，从业务的角度来看，这两者之间的数据并没有什么关联关系，你在做OA系统时可以无视那个CAD系统。当然，说没有关联关系也是相对的，这两个系统中，至少有某些操作者有可能是相同的，管理者如果要分析某工艺员在这个企业中的综合状况，可能就会用到这种关系了。
有些软件跟你的软件在业务范围上有明显的交叉领域，这就不能不引起警惕，一定要做好这方面的处理预案。例如，你做MES系统，别人做了ERP系统，有些MES系统向外延伸得也像个ERP系统了，有些ERP系统向车间深入得也像个MES系统了，这两者之间有工作交叉的地方就会非常多，如生产单管理、生产任务调度、加工汇报、生产过程监控等，都是非常有可能交叉的地方。这种交叉关系处理不好，很容易产生两大恶果，一是给用户带来重复劳动，二是形成企业的信息孤岛。
业务范围有交叉的这些软件，往往需要输入许多相同的数据，而它们又各自为政，在这种情况下，重复录入数据不可避免。
案例：在不同的系统中重复录入数据
某财务部门使用两款软件，一是财务软件，一是预算软件。这两个软件系统是独立的，某些费用发生时，用户不得不在财务系统中登记一次，在预算系统中再登记一次，前者用于生成记账凭证，后者用于内部预算管理。
随着企业采购的软件越来越多，这种业务交叉的范围也会越来越宽，给用户带来重复劳动的可能性自然也越来越大，而重复劳动的工作量也会越来越大。笔者曾经遇到过一些客户，有些数据，同一个用户需要在四五个系统中都登记一遍。对于管理者来说，这些软件都各有侧重点，但对某个具体的操作者来说，这些侧重点跟他没有任何关系，他只知道他要在不同的软件中录入相同的数据，一遍又一遍。
案例：在多个系统中重复录入数据
某车间使用软件“生产管理系统”进行生产任务管理，每天记录人员都会把生产完成情况、完工产品质量检测信息录入到这个软件系统中。后来，公司为了提高产品质量，推行质量管理，设计了一套新的质量管理体系，又上了一款“质量管理系统”，管理方要求记录员每天在系统中录入质量检测的相关信息，但是由于生产管理系统中的质量信息需要用来计算加工人员的计件工资，也不能不录入。再后来，公司为了提高服务水平，维系好客户关系，又上了一款“客户关系管理系统”，为了让客户可以查看到自己订单的加工进度及质量检测结果，管理方要求记录员在每个订单完成后，在这个系统中录入完成日期，以及相关的质量检测结果。虽然这三个软件系统对质量信息的要求并不完全一样，但有些质量基本信息，如检验等级等，录入员不得不在三个系统中重复录入。
企业中的不同软件往往是由不同的软件供应商提供的，每款软件所管理的数据都有它特定的数据结构、编码规范、约束要求等，这就导致不同软件所管理数据的关联关系很难被处理好。例如，这个系统中员工编号是流水号，那个系统中员工编号是工号，从软件的角度，很难建立这两个系统中员工信息之间的关系，因为它们的编码规则完全不一样，软件根本无法识别一个系统中的某个员工跟另外一个系统中的某个员工是不是同一个员工。
可以这么说，一家企业中的所有数据从根本上讲都是有一定的业务关联关系的，就看从什么角度看这些数据。例如，仓库出库记录跟生产过程中的质量检验记录，貌似是两种独立的数据，但如果从生产单的角度来看，这都是围绕某一生产任务产生的数据，它们之间不但有关系，而且关系很紧密。还有些数据，当前看上去没有关系，但在未来当某事件发生时，这种建立关系的要求就会扑面而来。例如，企业中的库存数据、机器数据、物料工艺数据，这些数据看上去都可能是独立无关的，但一旦要求进行生产计划编排运算，建立这些数据的关联关系就成为必不可少的工作。
在业务上有关联关系的数据，在信息系统中难以建立关联关系，这样就形成了所谓的“信息孤岛”。
1.什么是信息孤岛
“信息孤岛”几个字用得比较形象，顾名思义，就是信息被分割成许多独立块，块与块之间缺少有效的联系手段，犹如海洋中孤零零的岛屿，这些岛屿之间没有桥梁，没有飞机，甚至船都没有。当然，一般来说，一家企业内部，信息不管如何被分割，总能找到一些方式进行信息块之间的数据沟通，“信息孤岛”几个字略嫌夸张，用“信息割据”几个字恐怕更能反映信息分割的状况。每一款软件系统所管理的数据都有一套自己的规则，都是一个割据的“信息诸侯”，这些诸侯对外各有自己的边境线，对内各有自己的规章制度，缺少一个中央政府的统一领导，有时候看起来同文同种的样子，但交流起来就是不那么顺利。如果想把这些系统都整合成一个系统，那将是个非常痛苦的过程。看看春秋战国时的那些诸侯王国，每个国家使用自己的车轨、自己的度量衡体系、自己的货币，国家跟国家之间的沟通非常麻烦，后来秦国花了几十年，杀了无数人，终于由秦始皇统一了六国，然后统一货币，统一度量衡，书同文车同轨，就使得沟通变得容易了。
信息孤岛包括两种，一种是物理信息孤岛，一种是逻辑信息孤岛。
物理信息孤岛：数据被存放在不同的物理地点，相互之间被完全隔开，除了用U盘复制数据外几乎找不到别的通信方式。由于现在网络发达，这种情况很少出现，出现的原因往往都是管理者从安全的角度着想有意识地隔开这些数据。例如，人力资源部上了一款工资管理软件，为了确保工资保密，就在人力资源部办公室部署了硬件环境，服务器就安装在人力资源部经理办公桌边，这个服务器跟公司的局域网完全隔开，只有人力资源部的几个员工才能访问。
逻辑信息孤岛：从物理层面来看，连接没有任何障碍，孤岛的形成纯粹是由数据的产生过程、加工过程、存储格式、数据结构引起的——这种情况占了绝大部分。可以这么说，是不是信息孤岛，跟数据存储的物理位置几乎没有任何关系，处理好了，哪怕是跨国界存放的数据都不是信息孤岛，处理不好，同一磁盘中的数据，同一数据库中的数据，甚至同一表中的数据都有可能成为信息孤岛。
2.形成信息孤岛的原因
形成逻辑信息孤岛的原因主要有以下几种。
1）人为因素
由于企业使用不同供应商提供的软件，这些供应商从各自的利益出发，可能采用一些方法控制别人对自己所管理数据的访问，如访问权限控制、数据加密等；或者即使不是有意进行控制，但由于本身平台的特性，数据格式的特性，开发工具的特性等，也可能导致其他人很难访问、处理他们的数据，例如，某工艺CAD软件，采用特殊的数据存储格式，没有软件供应商的帮助，其他人很难分析这些数据。
2）编码差异
有些明明是完全相同的数据，在这个软件系统中采用这种编码方式，在另外一个软件系统中又采用另外一种编码方式，例如前面提到的员工编号的例子，站在人的角度，一眼就可以看出这个系统中的某某跟另外一个系统中的某某是同一员工，可从软件的角度却很难确定。
3）缺少关联字段
有些明明是业务上有关联的数据，在两个软件系统中就是找不到关联方式，因为可能某些软件系统在设计时就没有考虑这种关联要求。例如，库存管理系统中管理出入库记录，生产单管理系统中管理生产单信息，但库存管理系统中管理的出库记录并没有登记是为哪个生产单而出库的，从业务的角度，材料发给哪个生产单是非常明确的关联要求，但现在缺少这种关联字段。
4）数据结构差异
有些在业务上相同或相似的数据，在不同的软件系统中采用了完全不同的数据结构。例如，人力资源管理系统中，用树来表达企业的组织方式，但是在项目管理系统中，却是用图来表达企业的组织方式的。
3.处理信息孤岛的方式
信息孤岛的存在既影响了企业信息的综合分析，又严重制约着企业信息化管理的发展。为了处理信息孤岛的问题，一般有以下几种方式。
1）数据接口
软件系统之间通过接口进行数据沟通，这是最常见的解决信息孤岛问题的方式。一般的过程是，当某事件发生时，数据发送方通过一定的规范格式将数据抛出，接收方根据一定的规则解析数据，转换成符合自己系统要求的数据，存储下来，然后给发送方提示信息。例如，前面提到的某财务部的财务系统与预算系统，当某些费用发生，用户在财务系统登记时，财务系统按照一定的格式将这笔费用数据抛给预算系统，预算系统通过接口程序接收下来，保存到数据库，这样既能够保证两个系统的数据一致，又能够减少用户的重复劳动。各个系统之间本来各干各的，你是你的数据，我是我的数据，因为有了接口，这些孤岛就有了连接通道，这相当于在岛跟岛之间开辟了航线，以后数据可以通过这些航线往返。不过，通过接口交换数据的方式还是有很多麻烦的：①通过接口交换的数据一般只能局限在小范围之内；②一般系统中的数据都是在不断更新的，通过接口很难保证接收方数据的实时性；③扔出去的数据也可能会变化，扔出去简单，但要保证两个系统的数据同步更新却非常麻烦。
案例：通过数据接口保持数据同步
某公司使用着两个信息系统，一是ERP系统，二是OA系统。这两个系统是不同的软件供应商开发的，双方之间是完全独立的，没有任何数据交换。很多用户在工作过程中需要使用两个系统，如销售人员需要在ERP系统中录入销售订单，在OA系统中请假，等等。使用一段时间后，用户就觉得非常麻烦，因为需要在两个系统中切换，来回登录，对于系统管理员来说，来了新员工需要在两个系统中同时建立用户，也是个麻烦事。于是，该公司想做一些整合工作。为了简化这项工作，只做用户同步与单点登录。需求是，在一个系统中建立用户后，在另外一个系统中可以自动生成相同的用户。另外，用户可以在OA系统中单击ERP系统链接，如果当前用户的用户名、密码通过了ERP系统的验证，就可以直接进入ERP系统，而不需要再在ERP系统中录入用户名、密码登录。同理，在ERP系统中，也可以单击OA系统的链接进入OA系统，而不需要在OA系统中再录入一遍用户名与密码。
由于系统用户信息的维护功能在两个系统中是独立的，为了实现上述需求，需要保持两个系统中用户信息的同步。在ERP系统中创建、修改、删除用户时，需要将相关数据通过OA系统的接口推送到OA系统；在OA系统中创建、修改、删除用户时，又需要将相关数据通过ERP系统的接口推送到ERP系统。而在这两个系统中，有很多功能牵涉到用户系统信息的变化，如用户修改密码、管理员重置密码、从员工档案自动生成用户等。
这项工作比大部分人的直觉要困难得多。
2）统一编码
对不同系统中保存的相同业务信息，特别是实体型的信息（如部门、员工、物料、客户、供应商等），进行统一编码，也是在解决信息孤岛问题时使用得比较多的方式。使用这种方式，虽然各个系统中的数据还是各存各的，该重复录入的还是要重复录入，孤岛之间也没有开辟直接航线，但有了一个最大的好处，就是这些关键数据变得一致了，只要采用一些非常简单的方式就可以进行不同程度的信息整合。例如，可以导出到Excel或Access之类的软件中，经过简单处理后进行综合分析。这相当于在各个岛内推行标准化，说相同的语言，吃相同的食品，等等。
3）整合平台
为了解决信息孤岛的问题，也可以在孤岛之外建立信息整合平台——这其实也是一种软件，不过它存在的目的是整合信息，消除信息孤岛。整合平台最基本的功能就是通过各种手段从其他软件系统中获取数据，给业务上相关的数据建立关联关系，在一个统一平台上处理、展示。对于整合平台来说，最麻烦的事情就是如何从其他软件中获取数据了，如果有别的软件供应商支持，可以采用数据接口的方式，由其他软件系统将需要整合的数据推送过来，或者按照一定的规则从对方系统中直接读取数据。但有时候并不是所有的软件供应商都会配合的，或者他们觉得利益受损，或者有些软件系统根本没人维护，供应商早就不见了，这时候可以在研究对方的数据结构后直接从数据库中提取数据。这相当于在大洋中建立了某种商业中心，所有的孤岛都跟这个商业中心有业务往来，有了这个中心后，所有的孤岛都不再孤单了，如图3-5所示。
图3-5 用整合平台处理信息孤岛
4）综合解决方案
无论采用前面的什么方案，信息孤岛的问题都不能从根本上得到解决，只能治标不能治本，而且，随着业务的发展，管理的变化，这种问题只会越来越严重，最终会严重阻碍企业信息化管理的发展。往往到了这个时候，就会推动管理层开始研究是不是该采用某种综合的信息化解决方案（如常见的ERP系统）。所谓综合解决方案，就是推行某种信息化管理系统，用以对全企业的管理信息进行综合管理，对信息化管理体系进行统一策划，信息统一建模，操作统一设计，数据采用统一规范。这种方案将企业的信息化管理系统建成了一个有机体，极大提高了信息系统的运转效率，极大提高了信息系统给管理提升带来的收益。这相当于将大洋填平，移山填海，不再有孤岛，大洋变成了一马平川。
当然，综合解决方案的前景是美好的，这不容怀疑，道路也是曲折的，这更不容怀疑。要想将综合解决方案建成，并真正投入使用，是一个相当艰巨的任务，需要开发或引入一个庞大的软件系统，需要梳理改变企业的管理流程，需要改变员工的工作方式，需要克服来自各方面的阻力，需要处理以前信息孤岛的遗留问题，需要应对各种异常情况，需要耗时少则几个月，多则几年。由于工程的复杂性，花费了大量的资金与人力而最终失败的案例层出不穷。