背景

为改善业务构建了新的现成系统（package-system ）， 以更换原有的系统。

因为业务量增加或数据变更等造成现有的系统无法应对的新业务不断增加，据此而增加的人工费成为当下的课题。现计划更换现行系统以解决这一课题。

经过公司内部协商，决定导入比scratch开发价格更为低廉的成套系统。为了避免导入后的业务变更带来的混乱，决定尽可能不变更业务流程，针对各业务特点导入各自所需的系统包，各个包之间的数据往来通过插件来实现

计划进展得很顺利，系统包的导入也在计划周期内完成了。但是导入后不久系统开始频繁发生故障，由于用户的咨询业务以及系统运行作业的增加使得业务负荷甚至高出导入前的水平。 至此，我们不得不寻求从根本上解决问题，以及修改导入计划。

课题

为减轻负荷而导入系统包，但反而增加了负荷。

导入系统包后，用户开始抱怨“业务上无法使用”，运行作业增加又导致系统负责人只能埋头应对这些问题等。本来为了减轻负荷导入了系统包产品，但反而却加重了业务负荷。

根据调查的结果，从故障现象出发我们列举了以下5个课题。

【课题①】
对于1个系统，同时使用了多个系统包。

■故障现象
各个系统包之间的数据协同处理造成异常终止。
上游的系统包作为正常数据处理，下游的系统包里被作为异常数据处理，用户输入是正常的，但系统包之间的数据协同造成了异常终止。

【课题②】
为充分发挥各个系统包功能，同时降低业务的大幅变更而追加了插件。

■故障现象
在界面操作中，根据操作方法不同会产生不必要的事务处理和相应的操作。
用户在一连串的业务中途中断界面操作的情况下，仅中断前的操作会发生事务处理，使得数据失真。

【课题③】
在用户手册中记载有系统包的限制条件，新系统与现行系统同时使用。

■故障现象
用户进行了规定功能外的操作，造成了数据失真。
系统包有较为灵活的校验功能，可以应对各种用户的数据输入，但协同数据是根据各自的功能严格生成的，发生矛盾后就造成数据错误。

【课题④】
将旨在识别上游系统数据的关键项目设置为IF项目。

■故障现象
无法引用来自上游系统的数据，系统负责人也无法引用该数据。
将旨在识别上游系统数据的关键项目设置为IF项目后， IF项目仅保持在系统包的非公开DB，界面显示或DB中无法实现关键项目的检索， 需要找到从IF文档中检索文本进行调查的手法。

【课题⑤】
故障发生时，第一时间与系统供应商共同进行了处理和原因调查。

■故障现象
但工作时间外发生的故障，由于无法联系到系统供应商，调查只能中止。
系统正式上线后经过了1个月的时间，在即将进入保修合同期前发生了故障。 对于系统包界面的系统出错，无法判断到底是上游系统传来的数据问题，还是系统包和插件的问题，在与系统供应商负责人员取得联系之前只能凭可供引用的信息依靠想象来调查问题所在。

措施

对现行业务进行了改组，以能够最大限度地充分利用所导入的系统包功能。

从课题分析推测，不是系统包本身的问题，而是系统包的选择及导入存在问题。由此决定针对各个课题逐个实施对策。

 

【措施①】 将系统改为由单一系统包构建。
(图1)

■ 前提
●各个系统包都有各自独特的思想体系。由于思想体系的不同，校验数据的基准和实现方式也各不相同，可以使用的数据范围也不尽相同。因此，考虑到思想体系带来的这个不利因素，我们推荐导入单一系统包的模式。

●系统包供应商也无法违反系统包的思想体系来解决问题。即使试图通过插件来解决这种体系的差异，当需要违反该系统包的思想体系进行内容变更时，供应商也会出于品质保证的考虑拒绝该项修改。所以需要探讨的是在用户手册中提示对该内容的注意，或通过系统来应对该问题。

●通过系统包之间的插件或各自独立解决此问题是困难的。系统包的设计、安装内容对导入该系统的企业来说是非公开的，通过供应商增加插件或者企业独自修改安装等，都因为无法实施充分的评审和验证，无法合适地解决问题。

(图1)

 

【措施 ②】如果有可以变更事务处理的发生单位的插件，可以再考虑。
(图2)

■ 前提
●我们很难调查因事务处理的发生单位的变更所带来的的影响
通常，事务处理有多条发生路径，将全部的 事务处理的发生单位都进行变更是一件十分困难的事情。

●“通过测试确认即可”这个思路无法通用，这是变更的前提。
系统包在受质保的前提下，往往只会开展业务模式范围内的测试，
因此例外情形的测试是无法一一覆盖的，这往往又造成了正式运行时的故障。

（图2）

 

【措施③】贯彻双系统并行，在正式上线运行前降低因用户的误操作带来的数据错误。
将系统包的限制条件记述在用户手册中，旧系统与现行系统同时使用。(图3)

■ 前提
●企业不一定可以按照系统包的标准功能来自由设置权限。系统包的权限设置是在任何企业都可以通用的标准功能，未必能够满足公司特有的权限设置需求。

●用户为了自己能够开展业务，进行系统预设之外的输入。对于用户手册的理解不足、或者手册说明不充分、或者为了应对例外情形，用户进行系统预设之外的操作。系统包的标准功能有时也无法规避这种不正常的信息输入。

（图3）

【措施④】事前确认是否能在界面上确认IF项目，是否能够从下游识别对上游的数据。
(图4)

■ 前提
●与周边系统协同时的限制条件，特别是关键项目的可否保持与能否显示。系统间必然发生交互协同，但不仅是能否交互协同，包含维护和运用在内的数据交互的检索方法和操作性都需要考虑在内。

●日志的输出粒度和IF文档的保存方法，可引用范围和检索功能。界面上显示的信息只是保存的数据的一部分，因此对于用户和系统负责人来说，界面上无法确认到的数据到底有多大程度可供引用也需要考虑。

（图4）

【措施⑤】 为了更好地调查故障原因与采取对策，需要构建保体制前前的咨询体制。
(图5)

■ 前提
●为了区分故障原因，必须寻求能够看得到系统包的逻辑设定的供应商的帮助。故障的原因中，除了系统的安装不良之外，master的设置不良或者用户不遵守规则、系统运作错误等都有可能。系统包内部结构是非公开的，因此调查故障原因必须要供应商的帮助。

●系统包供应商未能理解业务内容。
从合同来讲这是理所当然的条件，系统包供应商为了提供系统包服务， 仅了解必要的业务知识，不对业务做深入了解。
需注意区分，在系统包导入后的运用与维保时表现的对于系统包知识的了解程度之深，和对于业务的了解程度，并不是一回事。

（图5）

成果

完善运行规则和架构，将手工作业控制在最低限度，
有效降低了因用户误操作造成的错误。

另外，保证足够时间的用户培训，这也使得最终系统上线后的故障、咨询等比预想的数量少了许多。