基幹システムは稼働してからが情シスの腕の見せどころ

重苦しかったプロジェクトがようやく終わる

ある現場で、ようやく基幹システムが稼働しました！

大変長かった…です。

あまりにも辛すぎて、ダークサイドに落ちてしまった人が続出しました（苦笑）

そのうち何人かは戻ってきましたが、他は戻ってこないままです。

経験上、大型プロジェクトはそんなものです。「一期一会」を楽しむスタンスでないと、精神的に乗り切れないと思います。

新システム稼働に伴い、プロジェクトは縮小に向かいます。ベンダーの開発体制も解除され、保守体制に移行していきます。

端的にいうと、人が減っていくのです。

この光景をみると「終わった～」と気が抜けるかもしれません。

しかし、まだ終わりではありません。

情シスは、この後、何をすべきなのでしょうか？

稼働してからが、情シスの腕の見せどころ

新システムの稼働当初は、トラブルが続きます。バグもあれば、設定不備もあります。マスタデータの登録ミスや移行データの不備などもあります。

数か月は、このトラブル対応が最優先となります。

これは、どの現場でも同じです。とにかく、やるしかありません。

問題は、この先です。

ここで情シスがどう動くか。

この後、情シスにしかできないことがたくさんあります。ここで、現場のユーザーの満足度が変わり、このプロジェクトの評価も変わってきます。

情シスが稼働後に考えるべきタスク

新システム稼働後に情シスが考えるべきタスクを挙げていきます。

①積み残し課題の優先順位付け

稼働にあたり、大抵は必要最低限のリリースとなっています。今後、積み残しの機能を構築して、順次リリースしていかないといけません。

しかし、何も考えずに順次構築しようとすると、初期構築に負けないぐらいの追加コストがかかることになります。

ここは、少し発想の転換が必要です。

当初「絶対に必要」と言われた機能を予定通り作っていくのではなく、「稼働後に現場から出てきた要望」を中心にリリースする、のです。

つまり、当時の「As-Is思考」にまみれた要求ではなく、稼働した今の実態に応じた要求を軸に優先順位を考えていきます。

逆を言えば、何も言ってこない「積み残し機能」は、実際は不要なのです。そのまま闇に葬り、復活させる必要はありません。
 

②保守ベンダーと保守フェーズの調整

保守コストは必ず必要です。しかし、あまり潤沢にするべきではありません。コスト制約があるからこそ、取捨選択を真剣に考えるからです。

予算に限りがあることで、根強く残る「As-Is要求」や「現場のわがまま」の抑止にもなります。

稼働後の現場からの要求ベースで優先順位を動的に見直し、保守工数をあらためて算出していきます。そして、ベンダーと調整します。

また、ベンダー側のキーパーソンもしばらくは残ってもらうよう交渉しましょう。安定稼働を見届けてから離任していただきます。

現場の状況を見極め、実装イメージや開発工数のイメージをもって、ベンダーと交渉できるのは、情シスだけです。
 

③カスタマイズ以外の手法検討

パッケージシステムの場合は、必要な要求であってもカスタマイズが難しいものもあります。そこで「封印」していたRPAやエクセルマクロなどで「ラストワンマイル」の自動化を検討していきます。

過度な自動化ツールは、業務を複雑なまま固定してしまうのでよくありません。しかし、ここぞという場面での自動化は有効です。

この自動化ツールで、情シスの出番となります。
 

④マニュアルやFAQの充実化

現場からの質問が多いものは、マニュアルに説明を追加し、自己解決できるよう修正していきます。

また、よくある質問と回答は抽出し、FAQを作り、問い合わせの件数を減らしていきます。

これらのマニュアルやFAQは、置き場も工夫します。

ファイルサーバーに置くだけではなく、システムのトップ画面やポータルサイト、チャットツールの専用チャネルなどで共有し、ユーザーが探しやすくする工夫も重要です。

今はWebベースで見栄えのよいサイトも簡単に作れます。Webは「検索性」が優れているメリットがあります。

技を駆使して、ユーザーの利便性が高いインタフェースにしていくのも、情シスにしかできない役割です。
 

⑤問い合わせ窓口の移管

情シスの負担を減らすためには、一次窓口は業務部門にすることです。問い合わせの内容でシステムやインフラに関わるものだけ、情シスに回してもらいます。

そうすることで、業務部門が当事者意識をもって、今後の保守にあたってくれるようになります。

情シスの負荷も下げられ、余力を他に回すことができます。
 

⑥新システムの内製化

例えば、新システムにデータが溜まっていくと、それらを活用できる環境となります。それらを参照する帳票・画面・レポート・ダッシュボードなどを作っていくことができます。

これらはパッケージの標準機能で構築できたり、ローコード／ノーコードで作れたりするものが多く、「内製」と相性が良いといえます。

他にも、ベンダーにわざわざ頼まなくても、自社でできそうな部分はあるはずです。

内製といえば情シスです。情シスが中心となって検討すべき重要テーマといえるでしょう。
 

⑦知られざる便利機能の促進

今までは業務の「MUST機能」だけを優先してきました。一方で、パッケージシステムでは、便利な標準機能がたくさん付属しています。

それらのうち「使えそうな機能」をピックアップし、情シスで検証します。そこで業務が便利になると判断したら、それをマニュアルに追加し、使い方をアナウンスし、活用を促進していきます。

パッケージシステムは、機能を使い倒してこそ、恩恵を最大化できます。ユーザーにも愛されるシステムとなります。

基幹システムが稼働したらDXの入り口

新しい基幹システムが稼働したら、いったんはプロジェクトが一区切りします。

でも、それは新しい業務のやり方の始まりともいえます。

ここをどうフィットさせていくかで、新システムの評価が決まります。

せっかく今までとても苦労して、リリースまでこぎつけたのです。それが、ユーザーの満足度が不当に低くなると、全てが台無しとなります。

今までの自分たちの活動を正当化し、評価してもらうためには、ここからが勝負です。そして、ユーザーの満足度を高めて、笑顔と感謝を受け取って、ようやくゴールです。

さらにいえば、DXという文脈においては、最初のステップをクリアしたに過ぎません。この「守りのIT」から「攻めのIT」にどう繋げていくのか。このグランドデザインを描いていくのも、情シスの腕の見せどころといえます。

貴社の基幹システムは、プロジェクトが終わってからも情シスが積極的に仕掛けていますでしょうか？