アシストが抱える業務面、システム面の課題について　～後編～

こんにちは。インタビューを担当させていただきます営業の真下（ましも）と駒形（こまがた）です。
前回に引き続き今回も経営企画本部長の林さんとITサービス企画部長の沖さんにERP導入前の状況について伺います。

駒形：改善のために、一番最初に取り組まれたことは何でしょうか。

林：一番最初は業務分析です。まずは今の業務を解きほぐそうというところからスタートしました。

沖：当時、先行して営業部門の執行役員がリーダーとなり、営業事務の業務プロセス可視化を行うプロジェクト「業務整理プロジェクト（GSP）」が活動しており、そこで現状の問題点の洗い出しを行っていました。

林：具体的には営業アシスタントの仕事をBPEC（ビーペック）という業務分析ツールを使って洗い出していました。それであれば、その波にのって他の業務もやってしまおう、ということになり、継続保守の担当やメーカー発注担当の人たちにも協力してもらい、BPECでまずはどのような業務があるのか洗い出しました。その後に各業務項目がどういう流れで進んでいるのか、各業務担当にヒアリングを行い、そこからSignavio（シグナビオ）（※1）というビジネスモデリングツールを使ってあるべき姿であるTo-Be図を作成しました。
このTo-Be図を作る過程で、ボトルネックとなる業務を洗い出したり、本来不要な業務をそぎ落としたり、フローの見直しなどをしてあるべき姿に近づけました。
ここはコンサルティング会社にも入ってもらっています。

（※1）現在の名称はSAP SignavioでSAP社の登録商標です

真下：SignavioはSAPに特化したツールではないのでしょうか。

沖：今はSAP社に買収されましたが、元々は独立したツールとして販売されていました。

林：今回のSAP導入プロジェクトでは、「仕様書を作るのをやめよう」という話をしていました。いわゆるプログラム仕様書といわれるものは作らず、かつ開発をアジャイルでやろうと決めました。
仕様書を作らず、電子的に設計図を作ることを考えると、Signavioというツールは必要不可欠で、それに合わせてSAPを構築していくという流れになります。

駒形：ここまで業務棚卸をした背景と手法についてお伺いしましたが、加えてどのくらいの期間をかけて行ったのか、どの程度の粒度まで行ったのかをお話しください。

沖：業務棚卸によるAs-Isを作るのに1年かかりました。BPECで可視化する部分です。
その後、BPECのデータをインプットにして To-BeとなるSignavioで可視化するのに1年くらいかかりました。両方合わせて約2年になります。もっとも、As-Is、To-Beはいずれも現業の傍らに行っていたため、本プロジェクトに専念することができればもっと短い期間で済ませることができたと思います。

真下：これは営業事務と継続保守業務の2つの領域でしょうか。

沖：その2つに加えてメーカー発注業務と会計業務です。

林：今回の刷新の対象は販売管理と会計なので、ステークホルダーは経理部門とメーカー仕入れ担当、業務刷新プロジェクト、営業事務を行う営業アシスタントと継続保守部門です。
現行業務（As-Is）の粒度については、BPECを使って業務を5段階のレベルまで掘り下げました。どの部署がどのような業務の分野で具体的な業務として何を行っているか、というところまで落とし込んでいます。

真下：つまり、業務の最明細まで落とし込んだということですか。

林：その通りです。

真下：先日、SAPを導入されたお客様とお話をする機会があったのですが、そちらの会社では、SAP S/4HANAを導入するにあたり、Fit to Standardで導入するためにAs-Isは行わず、To-Beをベースに構築をされたと伺いました。その理由はAs-Isを行うと従来の業務プロセスに引っ張られてしまい、本来目指すStandardモデルにできないからだと伺いました。アシストもFit to Standardで導入すると聞いていたのですが、今回、As-Isを実施されたのには、理由があるのでしょうか？

沖：業務の棚卸しをなぜ行ったかというとデータ項目を拾いたかったからです。データ項目に漏れがあると困るというのと、SAP側で保持できない項目だが、業務上絶対に必要な項目があった時にどうするかを考えなければならないため、ある程度As-Isはやらないといけないと考えました。

真下：つまり、システム的に必要なデータを捕捉するために行ったのであり、業務プロセスの洗い出しを目的として行ったわけではないということですね。

沖：その通りです。そうしないとAs-Isに引っ張られてしまうので、業務プロセスについてはAs-Isは殆ど見てません。あくまでもシステム面の目的のために実施したということです。

林：今回のAs-Is、To-Beの見える化によりギャップの抽出は行いましたが、ギャップは尊重しつつもTo-Beで進めるということです。

駒形：ありがとうございます。よく理解できました。
続いての質問です。
今回、業務棚卸を長期間かけて行いましたが、その評価はいかがでしょうか。
また、そこから見えてきたアシスト独自の業務プロセスは顕在化できましたでしょうか。
加えて、今後自動化できそうなところなどは見えてきましたでしょうか。

林：私はやって良かったと思います。上手くいったのではないですかね。アシスト独自のプロセスは冒頭(前編 )に沖さんが話をしていたスパゲティ状態のフローですね。
良い意味で言うとお客様に合わせる。悪い意味で言うとスタンダードが一切無いということで、その複雑なフローの流れを人がコントロールしていた、人依存のシステムだったということが浮き彫りになりました。
To-Beに振り切ることを決めたので、自動化できる範囲はかなり広くなるのではないかと思っています。

沖：少なくとも、人がバッチ処理で入力していた部分は自動化します。これを残してしまったら意味がないので（笑）

駒形：また、今回採用した手法、BPEC、Singnavioの評価についてはいかがでしょうか。

林：最終的な評価はまだわかりません。システムが稼働して業務が動き出してからの評価になります。

沖：BPECについては、時間軸で可視化ができたことが良かったです。どの業務でどのくらいの時間を費やしているかがわかったので、全体の総時間を把握できました。

真下：BPECと同様の他サービスは検討されましたか？

沖：していないと思います。業務刷新プロジェクトのリーダーがお付き合いのあるパートナーさんから紹介をいただいて利用を開始したと聞いています。

林：同様のサービスは他には無いんじゃないかと話してましたね。

駒形：最後の質問になります。
今回、業務の棚卸や標準を策定するにあたっての気づきや、これから実施しようと考えている方へのアドバイスなどがありましたらお願いします。

沖：現行の業務フローの中でも、個別最適の観点ではそれぞれ効率化を図っています。例えば営業アシスタントの方々は自分の中では効率よく業務処理をされているので、それを標準化するのは難しいと感じました。

林：やはり、進めていくには強い力が必要です。アシストは従来、ある程度の自由裁量で業務を行ってきました。それは良く言えば柔軟、悪く言えば統制が取れていないシステム作りを経営が許してきたということで、それが反省点なのかなと思います。
こうしたことを正すためには、強い力を行使しないと無理だということがわかりました。

まず、行ったことは、沖さんと岡田さん（本プロジェクトのプロジェクトマネージャー）が業務執行会議に出席して経営陣に対し今回のプロジェクトをコミットして欲しい、と話をしました。
基幹の刷新を行うことを会社の一大事として経営陣に認識してもらうところからスタートしました。
経営としてのコミット事項であるという前提でTo-Beに変えていかないと色々なところから反発がでると思います。
また、SAPを導入する場合はTo-Beに振り切らないとダメです。絶対に無理です。
なぜなら、SAPというプロダクト自体がTo-Beを実現するための業務改革を行うシステムだからなのです。つまり、SAPを入れるということは業務改革をやり遂げることである、ということを経営陣が覚悟しておかないとうまくいきません。
あるお客様とアシストのイベント時に話をしていても、As-Isを拾ってしまうと大変苦労すると仰ってました。
そのお客様によると、移行前のバージョンであるECC6.0の時にアドオンを大量に作ってしまったので、HANAに移行する際もそれを踏襲すると大変なことになるとのことでした。

真下：今後稼働し始めると現場からの不満などが出てくると思われますが、そのあたりの対処などは現時点で考えておりますか？

林：間違いなく出てくるでしょうね。必ず（笑）
ただ、それは動いてみないとわからないですね。

沖：今回はパッケージを入れるというより、業務改革を行うということが前提なのでこの流れに変えますよ、というところをどれだけ皆さんが理解してくれるかが一番重要なことだと思います。あとはシステムの使いにくさというところは出てくると思いますが、そこは追々改修していければいいかなと思ってます。

真下：前回のインタビューでも大塚さん（社長）も、そこを理解してもらうのが自分の仕事であると言ってましたしね。

林：できた先の未来はすごく明るい気がします。業務設計をしていても思うのですが、今まで担当者の人たちは大変だったな、と思います。営業アシスタントや、メーカー担当、継続保守担当の人たちは、あんなに複雑なフローでよく業務を回してくれていたなと、ねぎらわないといけないなと思います。私が担当者だったら、ブチ切れてます（笑）
本当に感謝しています。そのため、彼ら、彼女らがもっと良い仕事ができるようにするためにもこのプロジェクトは重要だと考えています。

真下：今まではお客様、営業現場の要望を最大限聞いて対応してきたと思いますが、今回の業務刷新により、そういった標準に合わないものは対応しないということでしょうか？

沖：すべてに対応しないというわけではなく、必要なものは残せば良いと思っています。今は何をやれば良いか当事者以外、誰もわかっていないということが問題なので、最低限、それをみんながシェアできる状態にしたい。また、業務仕様について、今までは他人が見ても分からず、本人にしかわからない言葉で書いてあったりしているので、それを誰もがわかる状態にしたいと考えております。
必要なお客様毎の個別対応においては、何をすれば良いかが誰でもわかる状態にすることが重要です。こうした手順（マニュアル等）の整備を行っていきたいと思います。

真下：どうしてもやらないといけないと判断されたお客様個別対応は、アドオンで開発するということですか。

沖：お客様毎の個別対応はシステムで対応できることとできないことがあります。システムで対応できることはS/4HANAで対応するのか、または外部システムで対応するのか検討します。システムで対応できないことは業務運用で対応することとなります。

林：アシストはSalesforceを先行して使っているので、Salesforceで対応する予定です。

沖：アジャイルをベースにした開発基盤を考えた場合、Salesforceは十分に機能を有しているため、Salesforce基盤を利用する判断をしました。それができれば、SalesforceとSAPを両方使っているお客様に色々な提案ができるようになりますしね（笑）

真下、駒形：本日はどうもありがとうございました。お二方のお話を聞いて、改めて基幹刷新＝業務改革だということを理解することができました。