画像素材:TKM /PIXTA
クラウド時代の到来に伴い、企業はシステムの「運用」を一層強化し、情報システム部門の態勢を見直しています。その中で、運用保守の内製比率を高め、保守の人員を増加させる取り組みが増加しています。これにより、迅速な経営環境の変化に適応し、同時に新しいビジネスを創造し、低コストで効果的にシステムを運用することが企業の重要な目標となっています。
システムの運用・保守には、避けて通れない守りの側面が付きまといますが、多くの企業の情報システム部門が”事なかれ主義”に陥り、機能不全に陥っているとの報告があります。既存のシステムが安定稼働している限り、自分達の仕事は増えないといった保守的な考え方です。しかしながら、現代は急速にデジタルが進化し、企業は自社のビジネスモデルを継続的に変革していく時代です。そのため、既存システムを柔軟に変更し、素早く新しいサービスやビジネスを展開する攻めのIT投資が求められています。
<目次>
1.京セラのアメーバー経営ならぬアメーバシステム?
重要なのはシステムの改良です。より具体的に言えば、継続的かつ効果的な改良が求められます。システムの改良は利用者に近い場所で行う方が良いため、内製化の傾向が高まっています。現時点で内製化が難しい場合でも、将来的な内製化に向けた準備を進めたり、内製化比率を段階的に向上させる取り組みが重要です。今後、ベンダーのエンジニアがユーザー企業に移籍するケースも増加していくことでしょう。
これまでにも紹介しましたが、ニトリやウォルマートなどデジタル投資に積極的な成長企業は毎日新しいアプリケーションがリリースされています。どんどん作ってどんどん動かして、どんどん改良しているのです。彼らのように、膨大な数のアプリケーションを素早くリリースするには、既にあるアプリケーションの機能を追加修正しながら、新サービスを提供することがポイントです。そうすることでスピードを上げることができます。
ただし、レガシーシステムの時代と同様に、基幹系システムに機能を無理に追加していくアプローチは、一つの改修が引き起こす影響範囲の特定が複雑化し、開発作業に時間がかかったり、思わぬ不具合に悩まされたりする可能性があります。このような課題を避けるためには、効果的な手法が求められます。その中で注目されているのが、各機能をAPIで結
合する方法です。これは、かつてのDLL化の概念に近いものです。
各機能やアプリケーションが独立しており、これらをAPIで結合することで、システム全体を柔軟かつ迅速に改良していくことが可能となります。京セラ創業者の稲盛氏の提唱するアメーバ経営の考え方になぞらえると、それぞれの機能やアプリケーションが独自の「アメーバ」として独立し、APIを通じて連携することで、組織全体が効率的に成長していく仕組みと言えるでしょう。これをアメーバシステムとでも呼びましょうか。。。
2.システム改良の予算は予め確保しておく
新たにシステムを導入する際、多くの場合予算取りに非常に時間がかかります。例えばこれまで販売管理系の基幹システムを改良し、そこに物流機能を持たせていたところに、倉庫管理システム(WMS)を新たに導入するといった場合は、通常はWMSを導入するための予算取りを行います。ROIの観点で3年~5年で投資を回収できるかを、導入の判断基準にするのが一般的でしょう。
しかし、導入後のシステム改良はその都度、予算を確保して稟議申請してということでは、システム改良のスピードが落ちてしまいます。導入後は、改良のスピードが重要なので、こうした予算は通常のシステム開発とは別に確保することを推奨します。例えばWMSを新規導入するため、5千万円の予算を確保したとします。その後の予算としては、システムの運用保守として毎月50万円の保守費用を予算として計上します。これで、終わってしまうと、利用者から改良の要望があがっても、都度予算確保に時間をとられてしまいます。
ですから、WMSの成長戦略を描くために、機能単位のロードマップを引き、予め改良のための予算を確保しておきましょう。
ただし、これはシステムの種類に応じて行う必要があります。経理や財務などのバックオフィス系のシステムは、従来通りのやり方で問題ありません。自社のサービスサイトや、店舗向けのシステムなど、顧客により近いシステムが対象となります。物流システムは、企業によって、判断が異なります。物流を顧客サービスの差別化として、フロントエンドに置く戦略の場合は、対象となります。
3.ゼロからフルスクラッチの開発は出来るだけ避ける
物流システムについては、システムを高速化するだけでなく、それを使った新しい顧客サービスを素早く提供することが競争力の強化には不可欠です。ここは外部のベンダーに任せきりにするのではなく、自社で素早く対応できる体制にする必要があるというのが私たちの考えです。
ただし、物流を顧客サービスの差別化機能として捉えない場合は別です。その場合は物流機能がバックオフィス機能になりますので、会計システムなどと同様の導入・保守の考え方になり、ベンダーにお任せでも問題ありません。
WMSの分野については、基本的には入荷、出荷、在庫管理というアプリケーションの基本機能は、ほとんど共通で利用可能です。ですから、ゼロからフルスクラッチでWMSを開発するというのは、余程の理由がない限り避けた方がよいでしょう。すでに基本機能が揃ったWMSパッケージがありますので、そのパッケージをベースに自社でカスタマイズして、改良を重ねる方が立ち上げのスピードとコストを大幅に削減することが可能になります。また通信不具合や、トランザクション処理の初歩的な不具合等で現場を困らせることもありません。
4.おわりに
環境変化にビジネスを対応させるには、ITの積極的な活用が必要なことは、皆さんご承知の通りです。攻めのIT投資といった言葉も最近ではよく聞きます。ユーザーの要求をすぐに把握したり、現状の業務の問題点を素早く察知したりできるようになれば、即時にシステムを保守できます。デジタル競争力が物を言ういま、システムの運用・保守という言葉の意味は変わっていくことでしょう。そのままの形を保って守るのではなく、手を加えながら新しい価値を創造することが、これからのシステム運用・保守になると思います。