現行システムが陳腐化
法律や制度改正時がシステム導入のタイミング
あらかじめ法律改正がアナウンスされますので、余裕をみてシステム構築する必要があります。また法律改正の可能性が高い部分、例えば消費税率などは、あらかじめ変更がありうるのを前提に設計しておく必要があります。なかにはアナウンス期間が短い場合もあります。例えば、民主党が子ども手当支給を決めたとき、住民基本台帳などとの整合性をとったシステム開発が各市町村で必要となりました。官公庁では入札による業者決定が必要となるため、システム開発が間に合わないなどトラブルが発生しました。
現行システムが陳腐化すると運用保守費が無視できないほど大きくなってきます。開発当時は該当するパッケージがなかったため、独自システムで開発し必要に応じてメンテナンスしているケースでは、適用できるパッケージが登場していたら乗り換えて運用保守費を下げることも可能です。また自前システムではなくSaasシステムを導入する選択肢もあります。
既存事業以外に新事業が立ち上げるケースでは、現行システムではもともと想定していなかったため見直しが必要となります。現行システムのメンテナンス・レベルにおさめるか、よい機会なのでBPR(業務改革）をすすめ、業務が一気通貫で流れる全体最適システムにするか決断しなければなりません。
→ 信長、武田騎馬隊を破る BPR（業務改革）
中小企業では後継者不足による廃業もありますが、企業合併やM&Aが少しずつ増えています。企業を取り巻く外部環境が大きく変わった時、新システム導入のタイミングです。合併するどちらかの企業システムを是とし、もう一方のシステムを切り替えるか、それとも一から新システムを作るか判断が分かれます。3行が合併し、みずほ銀行が誕生した時にもシステムトラブルが発生しました。
→ みずほのトラブルの原因に迫る！
中小企業で多いのは担当者が辞めてしまった時
システム担当者が辞めた時、仕方なく新システム導入が多い
システム担当専従は珍しく、ほとんどの場合は総務など他の業務と兼務して行っています。パソコンが得意ということで社内のシステム案件が集中してしまいます。本人も得意な分野なのでアクセスなどでシステムを組んだり、外部事業者にシステム発注したりし、企業にとってかゆいところに手が届くシステムができあがります。
ところが突然、システム担当が辞めると、ドキュメントも残っていず、残っていても一番最初のバージョンでメンテナンスなどが反映されていないケースが発生。現行システムとしてそのまま使うことは可能ですが、ちょっと手直ししたいなと思っても誰も触れられないシステムになっています。この場合、時期をみて新システムに作り直すしか方法はありません。
会社としては担当者の片手間業務とせず、きちんとシステム担当の時間を確保することです。その中にはドキュメント整備が含まれます。またシステム変更については上司がドキュメント変更も含めてチェックする業務の流れにしておくことが必要です。要はシステムがブラックボックスになってしまわないよう仕組みを社内に作ることが肝心です。
