2019/09/06

経営企画統括部 戦略企画部 広報・CSV推進室

三井情報(以下、MKI)は6月からグループ会社全ての基幹システムをSAP S/4HANA CloudとSalesforceを使ったクラウド環境へ移行するプロジェクト(以下、本プロジェクト)を実行中です。本プロジェクトでは、MKIが皆さまの実験マウスとなって全基幹システムをIaaS型クラウド環境(以下、IaaS環境)からSaaS型クラウド環境(以下、SaaS環境)へ移行します。本コラムは本プロジェクトを蚊帳の外から生温かい視線で見守っているMKI広報担当ができる限り、技術者以外でも理解できるような文章を心がけて執筆しています。第2回となる今回はMKIがSaaSへの挑戦に至った経緯をお伝えします。

基幹システム更改のきっかけ

2019年度でMKIが利用している現行基幹システムの減価償却がほとんど終わります。そして、MKIの基幹システムが稼働するサーバで利用しているOSは2020年1月にEOL(End of Life)を迎えます。EOLを迎えるとサポートやアップデートの提供が終了し、何かセキュリティ的な問題が発生しても対応ができない状態になり、システムにセキュリティリスクを抱えることになります。本プロジェクトはこのような背景から始まりました。

現行基幹システムが抱える喫緊の問題がOSのEOLであるため、本プロジェクトの推進担当者はまずOSのバージョンアップ(案①)から検討を始めました。しかし、この案①ではOSだけでなく、基幹システムに付随するデータベース(DB)やアプリケーションのバージョンアップも必要です。また、通常業務で利用するシステムのため、業務時間外での対応が必要なことから工期が長引き、試算した費用も想定よりはるかに高くなりました。機能改善もなく、バージョンアップ作業だけで多額の費用がかかるならと以下の3案で比較・検討することにしました。

①  AWS上で稼働しているOSをバージョンアップする。
②  2025年にEOLを迎えるSAP ERP 6.0の対応も含めてシステムを移行する。
③  OS、SAP ERP 6.0、DBをすべてSAP S/4HANA Cloudへ移行する。

現行基幹システムであるSAP ERP 6.0は2025年にEOLを迎えます。そのため、このタイミングでSAP S/4HANAへのリプレースを含むシステム移行である案②を検討しました。(SAP ERP 6.0は2025年にEOLを迎えます。そのため今後数年の間に多くの企業でSAP S/4HANAへの移行が必要となり、SAP技術者が不足すると言われています。)SAP S/4HANAを利用するには、基幹システムのDBもHANAを使う必要があります。(HANAはSAP社が提供しているDB名です。)そのため、案②では既存でプライベートクラウドとして利用しているAWSからMicrosoft 社が提供するクラウド環境Microsoft Azure、SAP社が提供するHEC(HANA Enterprise Cloud)へ移行することもあわせて検討しました。そして、案③として今回採用したネットワークからアプリケーションまで全てがクラウドサービスとして提供されるSAP S/4HANA Cloud(SaaS環境)への移行を検討しました。

SaaS型を選択した背景

第1回目でもお伝えした通り、MKIのIT基盤戦略は2018年度に政府が公表している「クラウド・バイ・デフォルト原則」の考え方を基にしています。そのため、経営方針として、IT基盤はクラウドの選択が第一優先となっています。現行の基幹システムはすでにIaaS環境上にあることから、クラウドで稼働させること自体は実現できています。更改案検討時に本プロジェクトの推進担当者がMKIの技術部門へ相談した際は、実績がほぼなく苦労しそうな案③ではなく、実績の多い案②が推されていました。

しかし、ICTの未来を見つめるMKI代表取締役社長 小日山は10年から15年後には大半のアプリケーションがSaaS型で利用され、一般的なサービスもSaaS型になると予想しています。もちろん全てのサービスを網羅できる訳ではないため、独自システムはIaaSやPaaSで開発を行いつつ、APIを使ってクラウド環境にあるシステムと連携する形になるだろうと考えているとのこと。その時代に備え、まだどこの企業もやっていない基幹システムのSaaSへの移行をMKIがやろう。むしろ、MKIがやらず、どこがやるんだ！という鋼の意思を持っていました。また経営サイドは、過去に7社が合併した経緯から異なる業務プロセスが混在し非効率な状態になっていることを課題に感じていました。そのため、以前より社内事務手続きにかかる工数削減および業務標準化を検討していました。今回採用するSaaS型で提供されているSAP S/4HANA Cloudを利用するには、提供されるサービスに業務を合わせる必要があります。そのため、提供されるサービスをベースにBPR(Business Process Re-engineering)による業務フローの改善に活かすことができると考え、案③が推されました。
結果、MKIは社長の未来予想図と経営サイドが考える社内の課題を解決すべく、案③を採用しました。(8割強くらいは社長の強い鋼の意志です(笑))

難しい社内体制づくり

社長の未来予想図と経営サイドの熱い思いで案③のSaaS環境への移行が決定し、BPRを行うための体制づくりが始まりました。BPRが絡むため業務フローを熟知しているだけではなく、様々な観点から必要な業務フローの取捨選択ができるメンバーが必要です。そのため、案③の採用決定後、本プロジェクトの推進担当者は基幹システム利用部門へシステム更改の話をしに行きました。すると、「現在、問題ないシステムを何故更改する必要があるのか。」という声が上がったそうです。実際は「現在、運用回避で問題ないことにしているシステムを何故更改する必要があるのか。」が本音だったようですが。。。実は、現在利用している基幹システムは導入時に使い勝手が悪く、導入後の方が業務の手間が増えたと利用部門からクレームの嵐を頂戴したシステムです。(私も過去に一部機能を利用したことがありますが、使い勝手については同感です(苦笑)) 利用部門は長い期間を経てシステムを飼い慣らし、今年度にはRPA(ロボティック・プロセス・オートメーション)による業務効率化を予定していました。システム移行が実現すると、せっかく導入したRPAを半年しか利用できないこともあり、余計に強く反発したようです。今回のBPRでは、一担当者ではなく管理職層レベルの社員に現場から参画してもらう必要があります。現場は本プロジェクトに貴重な人員のリソースを提供するため、それなりの理由がないと納得しません。そのため、トップダウン形式でBPRによって業務がどう改善されるのか等のシステム更改後ビジョンおよび現場が参加することの重要性を説明し、利用部門の理解を得ていきました。(システムを刷新する際は刷新すること自体を目的とするのではなく、刷新後にどうなりたいか？どうなるのか？という明確なビジョンが大切なのです！)

このように本プロジェクトの体制づくりに悪戦苦闘しつつ、5月にようやく稟議が通り、本プロジェクトのスタートを迎えました。利用部門はBPRに関するワークショップを通じて大変ながらも前向きに新しい業務プロセスを検討しています。対する技術部門は予想していた通り、毎日四苦八苦しているようです(笑)。遅い時間に私の近くの席で技術部門が作戦会議する様子も多々見かけます。誰一人倒れずに12月の切り替えまで頑張って欲しいです。

第2回ではMKIがSaaSの採用理由と本プロジェクト開始までに時間がかかった理由をお伝えしました。次回は「SaaS型をベースとしたBPRのススメ ～Fit to Standardを添えて~(仮)」と題して、提供されるサービスに業務を合わせる“Fit to Standard”によるBPRの進め方についてお伝えします。次回もお楽しみに！

【関連ページ】
クラウドの端から失礼します。 vol.01