2019/10/04

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

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

SaaS利用をBPRの基準にする

MKIの基幹システムの移行先であるSAP S/4HANA CloudとSalesforceはSaaSとして提供されています。SaaSは“Software as a Service”という名前の通り、サービスとして提供されるソフトウェアを使用します。そのため利用にあたっては、利用目的と提供される機能をうまく組み合わせていく必要があります。MKIでは機能をうまく組み合わせていくためのステップとして、SaaSで提供されている機能をベースにしたBPRを行っています。

BPRでは業務プロセスを見直し、最適化していくことが求められます。業務プロセスを最適化するにあたり、既存のプロセス業務を見直して本当に必要か、そうでないかを判断し、取捨選択していく必要があります。しかし、取捨選択を迫られたとき、なかなか「捨てる」判断をすることができない人も多いのではないでしょうか。(私は「捨てる」判断が苦手なので、ロッカーの中は捨てられないもので溢れかえっています(苦笑)) 企業として「捨てる」判断をする際、個人の裁量などで決められないプロセス業務も多くあるため、事前に何かしらの基準を用意すると思います。そして、企業の規模によってはその基準を決めるのに時間を要す場合もあります。(個人的にMKIも内容によって時間がかかる部分がちらほら…。) スムーズな業務プロセスの取捨選択の解決策として、SaaSで提供されている機能を基準にしてBPRをする方法があります。

Fit to Standardによる業務プロセスの取捨選択

SAP S/4HANA CloudはSAP社が提唱している“Fit to Standard(標準への準拠)”と呼ばれる手法でシステム導入をしていきます。この“Fit to Standard”では、SAP S/4HANA Cloudで提供されている標準機能に業務プロセスを合わせてシステムを作っていきます。そのため、標準機能にないものは明確に必要な機能であると判断されない限り業務プロセスの中から基本的に破棄します。SAP S/4HANAを採用した場合、必要な業務プロセスである場合はアドオンと呼ばれるカスタマイズで対応が可能です。しかし、MKIが採用したSAP S/4HANA Cloudでは、明細書や請求書などの「帳票」と他システムとデータ連携する「インターフェース」のみカスタマイズが可能です。そのため、標準機能で対応できない業務プロセスは別にツールを用意して対応します。

SAP S/4HANA Cloudでアドオンが限定されているのには理由があります。日本国内の多くの企業が所有するシステムは企業都合で様々なアドオンが追加されています。システム利用者側からは企業都合に合うため便利と考えられる反面、システムのバージョンアップや更改時にアドオンの互換性確認や改修に時間やコストがかかります。そのため、多くの企業は必要最低限のバージョンアップしかせず、最新の機能を充分に使えている企業自体が少ないと聞きます。またセキュリティを拡張したバージョンもリリースされていることからも、魅力的な機能がなくとも最新バージョンにする意義はあるようです。SAP社では利用者に最大限に機能・セキュリティを使ってもらうため、バージョンアップの機会を遠ざけるきっかけになり得るアドオンは一部を除いて不可になっています。特にMKIは今回、マルチテナント形式と呼ばれる他企業と基幹システムを共用するサービスを購入しています。マルチテナント形式ではバージョンアップのタイミングをSAP社が決めます。そのため、アドオンが多いとバージョンアップ時の確認項目が多くなり、大変な目に遭います。このような背景もあり、MKIは標準機能内に業務プロセスが収まるように業務プロセスの取捨選択をしています。しかし、リリースして間もないシステムであるため標準機能が足りないという声もチラホラ…。SAP社には頑張って標準機能を増やしていって欲しいです(笑)。

順調に見えるSalesforce

SAP S/4HANA Cloudと同じくSaaSで提供されるSalesforceも同様の苦労があると予想していたのですが、MKIでは2016年から一部営業部門で利用していることもあり、比較的スムーズにBPRができているそうです。(過去導入時に当時の担当者がたくさんの検討をしてくれたおかげらしいです。) 先行的に導入されていることもスムーズに進められている理由にあるのですが、Salesforceの方が長い期間サービス提供をしていることもあり、選択できる標準機能がたくさんあるそうです。また、Salesforceではアジャイル開発という手法を採用していることもスムーズに進められている理由に挙げることができます。アジャイル開発は近年、日本でも採用する企業が増加しており、「Agile(アジャイル)」という単語の通り、素早く機敏であること、柔軟性があることが重視されている開発手法です。アジャイル開発ではシステム利用者からこまめに要望を聞き、その要望を短い期間で少しずつ柔軟にシステムに実装させていきます。それにより、システム導入直前で大きな問題が発生することを防ぎます。そのため、業務プロセスを取捨選択して進めるSAP S/4HANA Cloudとは異なり、Salesforceでは夢を語りながらBPRを行っているようです。(MKI代表取締役社長 小日山もよく「夢を語れ！」と言っており、実現されています(笑)。)

考え方の異なるシステムを同時に検討する

このようにSAP S/4HANA Cloudは決められた機能の中から業務プロセスを組み上げるのに対し、Salesforceは選び放題の機能の中から要望事項に優先順位をつけて業務プロセスを組み上げるため、考え方が真逆に近い状態です。そのため、現場では混乱も起きているようです。

本プロジェクト開始時にMKIではSAP S/4HANA CloudとSalesforceを理解するためのワークショップが利用部門向けに開かれました。SAP S/4HANA Cloudのワークショップでは、システムの細かい機能を1つ1つ説明した後にシステムの全体像の話が行われたそうです。一方のSalesforceはシステムの全体像を説明した後に細かい機能を1つ1つ説明したそうです。Salesforceは全体像を理解したうえで構成要素が理解できたため、ワークショップの参加者はSalesforceでできることが明確に理解できたそうです。しかし、SAP S/4HANA Cloudは構成要素の説明から始まったことにより、システムの全体像のイメージが難しかったそうです。プロジェクト開始当初、プロジェクト推進担当者から「発想の転換」がうまくできていないとの声を聞いていました。業務プロセスを標準に合わせていくには、1つ1つの要素を理解することも大切ですが、先に全体像を把握してゴールが見えた方が、どのように業務プロセスを組み立てていけるか分かり易いのではないかと思います。(山で迷子になった時に通過点をすべて理解するよりも、山頂の場所を理解していた方が行き方を色々模索することができるようなイメージです。私はゴールまで挑戦しすぎて迷子になりますが…(苦笑))

このように一言でSaaSと言ってもサービス提供者によって考え方は異なります。自社導入する前はサービスの根本的な考え方、標準機能、導入方法などを充分に調べて検討した上でサービスを選んでいくことが大事だと考えます。(ベンダーであるMKIでさえ、すでに想定外のことが多々発生しているらしいので、反面教師にしていただければ…(笑)。) 基幹システムは企業経営を支える重要なシステムであると同時に多くの社員が利用するシステムでもあります。導入開始後に利用者が持つシステムへのイメージと実際の使用感のギャップによるモチベーション低下等を防ぐために、積極的に関係者を巻き込んでギャップを少なくして進めていくと導入後の反発も減るかと思われます！ (現場に反対されたり、不満言われたり、意見の収集ができなくなっても責任はとれませんが…。)

第3回ではSaaSで提供される機能をベースとしたBPRについてお伝えしました。次回は「利用部門を悩ませる業務プロセスの発想転換(仮)」と題して利用部門が躓いたFit to Standardを進める際に必要となる「発想の転換」についてお伝えします。次回もお楽しみに！

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