システム導入の『こんなはずじゃなかった』を回避する

2022年7月9日2022年7月11日

情シスや社内SEであれば必ずと言っていいほど経験することが多いシステム導入対応。上司や上層部から指示されて導入したものの、導入中や導入後に『こんなはずじゃなかった』と失敗の烙印を押されてしまうこともしばしば。

今回は、そんな『こんなはずじゃなかった』に対抗する方法を考えてみます。

『こんなはずじゃなかった』はパッケージ導入に多い

システム導入の方法には大きく分けて自社内で構築する”スクラッチ”という方法と、広く販売されている”パッケージ”という方法があります（カスタマイズとかアジャイルなどはおいといて）。

そして私の経験では『こんなはずじゃなかった』はパッケージ導入時に圧倒的に多いように感じます。

なぜならばスクラッチで導入していれば、なにか不便さや不満があれば自社内でシステムに手を加えて解消するという手段があるためです。

たとえ導入時と運用時のミスマッチが発生したとしてもシステム改造という方法でミスマッチを乗り越えることができます。

ところがパッケージ導入ではシステムやプログラムの著作権は発売元が持っていることがほとんどであり、勝手な改造ができないことが多いです。

最近はAPI連携の充実やオープンソースシステムの拡充によって裾野は広がりつつありますが、それでもユーザー企業が手を加えられないシステムはまだまだ多いです。

そしてこの場合、ユーザー企業はシステム改造という方法で導入時と運用時のミスマッチを乗り越えることができず、運用でカバーするか、いつ採用されるかも分からない改善要望を出すか、システムの利用を取りやめるかという後ろ向きな選択しか残されていません。

そしてどの選択肢を選んだとしても利用者にとっては不便さの解消にはならないので、結果として失敗を意味する『こんなはずじゃなかった』ということに陥りがちです。

ベンダーは”できること”しか言えない

まず、スクラッチとパッケージの大きな違いにベンダーの存在があります。スクラッチであっても構築を外部に発注することはありますが、改造可能なソースコードを納入するベンダーと一切改造できないパッケージシステムを導入するベンダーという違いがあります。ここでは後者のベンダーを想定してください。

そしてパッケージ品のベンダーは、販売しているパッケージ品のできることしか言えません。情シスが社内の状況や既存システムについて共有したうえで質問を投げかければ答えることはできますが、広告や売り込みの段階ではシステムでできることしか説明ができません。

反対にベンダーが説明できないことはできることを実現するために必要な前提条件です。

ここでいう前提条件とは、システム導入により得られる利益を実現するために必要な不利益です。

ベンダーの立場におけるこの特徴は、ユーザー企業の内情をほとんど知らないこと、ベンダーはシステムを販売することで売り上げを得ている以上は不利益な部分は（意識的にせよ無意識的にせよ）説明を避けたがることからある意味当然のことかもしれません。

とあるRPAパッケージ導入の例

少し具体的な事例で説明します。とある会社はあるSaaSグループウェアを利用しています。そして以前から労務管理の一環で、グループウェアのスケジュール帳から手動でデータをコピーしてExcelの帳票に転記するという作業を繰り返していました。

この作業は各部署で行われている定形作業であったため、多くの部課長がその作業時間を問題視していました。そこで最近流行りのRPAを導入することでコピー作業が無くなるのではないかということで、情報システム部門にRPA導入の検討を依頼しました。

この依頼を受けた情報システム部門はRPAパッケージの選定、導入、展開を行い各部署にてグループウェアのスケジュール帳からExcelにデータを転記するプログラムが作成されました。

システム構築になじみのない社員も多くRPAプログラムの構築には時間がかかりましたが、無事に転記処理を自動化することに成功し、導入・学習の時間や改善後の処理時間を総合すると約2年で導入コストと改善費用・時間が逆転してプラスになることが分かりました。

これでシステムの導入は大成功、あとは継続してRPAプログラムを動かし続けるだけと誰もが考えていましたが、少しずつ思惑とは逸れていきます。

半年後、この会社が利用していたグループウェアのバージョンアップがアナウンスされ、バージョンアップに伴いUIの改善を行うということになりました。バージョンアップ作業はグループウェアのベンダーが行うためユーザー企業では何もする必要はありませんでしたが、UIの改善に伴いRPAプログラムの修正が必要になる可能性が浮上します。

ところが、グループウェアのUI変更箇所の詳細は告知されておらず、ましてやバージョンアップ後のテスト環境を得ることもできません。結果、既存のRPAプログラムが今後も動作するかどうかはグループウェアのバージョンアップ後にしか分からないということになりました。

案の定、バージョンアップ後にRPAプログラムは動作しなくなり修正が必要となりましたが、半年のブランクもありRPAに関する知識や熟練度が誰しも低下していました。既存のRPAプログラムがあるとはいえ、各部署で作成されたRPAプログラムは多数に上りシステム部門だけでは手が回りません。

ところが転記作業はすぐさまやめることはできないので、プログラムの改修が終わるまではまた手作業で転記することになりました。RPAで浮いた時間を別業務にあてていたことから、どの部署も業務負荷が以前より高くなってしまい、RPAプログラムの改修がなかなか進まず、手作業の転記作業が数か月にわたって長引くことになりました。

そして夢のRPA導入を提案した部課長は『こんなはずじゃなかった』とぼやくことになりました。