業務改革センターとしてのNEXISプロジェクトでの挑戦（前編）

真下：まず皆様の役割をお聞かせください。

柳：業務改革センターのセンター長を担当しています。今回のSAP導入の目的は業務改革です。システムを構築しただけでは改革は行えません。業務プロセスそのものを変えていく必要があります。SAPを基幹システムとして据えて、それを活用してどう業務を最適な形に改革していくか？それが業務改革センターの役割であり、私はその推進を担っています。

矢農：業務改革センターの購買管理部の部長を担当しています。また業務改革センターの設立前から、NEXISプロジェクトにおいて発注チームのPO（プロダクトオーナー）補佐としてプロジェクト活動の推進も行っています。

沖：私は経営企画統括部の所属ですが、兼務で属しているGKCの中では柳さんの下で、業務改革センター長補佐の役割を担っています。NEXISカットオーバー後の業務改革センターの業務とシステムをつなげていくようなところが、メインの仕事になると思っています。また、NEXISプロジェクトでは、プロジェクトマネージャー補佐と販売領域のスクラムマスターも担当しています。

真下：はじめに業務改革センターの設立の経緯や目指されていることをお話しください。

柳：アシストは属人化と個別最適という大きな2つの課題を抱えており、これらが営業系業務の負荷を高めている大きな原因であることがわかりました。
それを解決する方法の1つがシステム化であり、このNEXISですね。
システム化と合わせて専任の組織を持たないとなかなか対応と定着が難しい、というところもあり、システムに合わせた組織作りを考えた結果、今回の業務改革センターのような独立した組織体が発足したと理解しています。
役割と目指すところは、現在の受発注にかかわる業務処理を最大限効率化し、生産性を高めることです。
これらを行うことによって、自組織だけではなく、営業や技術部門の生産性も合わせて向上させていくことも目指します。
例えば、今回NEXISと業務改革センターが立ち上がることにより、営業部門が今まで担っていた業務の相当な部分をGKCが巻き取ります。それにより、営業組織は今まで費やしていた事務処理時間を軽減し、その時間をお客様への付加価値サービスの活動に向けることができます。このように自組織だけではなく、他に関係する組織の生産性向上にも寄与していくことが、我々の組織の役割になるのかなと考えています。

真下：矢農さんから業務改革センターのキックオフ資料を見せていただきました。

駒形：NEXISに完全移行した後の業務改革センターのミッションとして、業務への対応だけでなく、これから発生する課題への対応も行っていくのですか。

柳：業務を回していく中では、常に課題というのは生まれてくるものだと思っています。
現状はこれだけのことを営業部門がやっていました（図1）。それが、NEXISが稼働することによって、図2に変わります。
今までの受注から営業の計上、請求、継続保守の処理などが、ほぼ営業部門からなくなると考えると、営業もアシスタントもだいぶ時間に余裕ができると思うんですよね。
ただ、業務改革センターに移管された処理の仕方が本当にいいのかというと、属人化しているものが多くあったり、固有のお客様向けに行っている個別最適の処理があります。
それは全体から見た場合には、とても時間的なボトルネックになっているものもあります。一旦業務改革センター側で巻き取った後に改善できるものを見つけて、変えていくことになるかなと思います。
そうすることで、システムと組織がリンクして、本来会社が向かうべき方向に向かっていけるようになると考えています。

真下：もう少し細かい業務レベルで聞かせてください。営業がお客様から受注すると、受注した情報を営業部門が扇子（Salesforceの営業支援システム）に入れます。そこから先は全部業務改革センターが対応するということですか。

柳：イメージはそうですね。

真下：業務改革センターで受注の処理を担当するのはBPO（外部の委託先）を含めても10人弱と伺っています。全国の受注を全部ここで処理をするということですよね。大丈夫ですか。

柳：営業部門で処理する業務は減りますが、お願いすることが1つあります。現状、受注の時に必要な情報が揃っていないことにより、受注した後に発注チームと情報のやり取りが必要となり、ボトルネックが発生しています。そこで、各製品を受注して発注するために必要な情報をまとめた発注依頼書というものを準備しています。受注の時には、注文書と合わせて、この発注依頼書で発注に必要な情報をすべて渡してもらいます。

駒形：その発注依頼書というのは標準化されたものですか。

柳：はい。そうです。
今までは、アシスタントが発注する際に発注担当に電話をして、発注に必要な情報を教えてもらったりするようなやり取りも結構ありました。そのため、発注担当は営業部門からの問い合わせ対応に結構時間を割かれていた、という声がありました。
営業側も情報収集、確認にかなり時間を使っていたことになります。そういったものが標準化されて、1つで上流から下流へと流れていくものになれば、そこでの業務工数は、アシスト全体としてはかなり減ると思われます。
営業の負荷を業務改革センターに持っていくだけではなくて、SAPを使うことで標準化されるものというのが多く出てくると思うんですね。そこが今回、SAPを使う意味の1つではないかと思います。

真下：今回標準化を図り、それに合わせるためには、お客様の理解も必要になると思います。そこの交渉は営業側になりますか。

柳：そうですね。ただ、現状でも出荷に必要な情報というのは何かしらの手段でお客様からいただいているはずなんですよね。
必要な項目が網羅されたExcelのシートをお渡しして、お客様に記入してもらえれば、お客様の負荷も下がるようになることも考えられます。

矢農：今、想定している発注依頼書は出荷に必要な情報を標準化して、それなりの項目数にまとめようとしていますが、今までは製品ごとに必要な項目というのはバラバラでした。
つまり営業側で属人化しているというよりも、発注する業務側でも属人化、というか属製品化していました。それを標準化することで工数がかなり減るのではないかと考えています。

真下：今までアシスタントやメーカー窓口担当者が確認をしながら対応していた業務は、全部GKCが吸収するのですか。

矢農：そうです。GKCが発注依頼書を用意して、それを営業もしくはお客様に埋めてもらうことで、その後の一連の作業が全部流れるようになります。
今までだと製品ごとに確認箇所が異なり、いろいろ処理が複雑になっていましたが、今後は、最初にその発注依頼書をもらったら、それをベースにメーカーへの発注から出荷処理まで全部流れていきます。

駒形：今のお話を聞いていると、発注依頼書を準備することで標準化が進むのであれば、そのためにわざわざSAPを使う必要はないのではと思ってしまったのですが、そんなことはないですか。

沖：ERPシステムというのは最終的に会計データを出さないといけないのです。
それがERPシステムの最終ゴールだとすると、SAPというのは会計データを作るところから、上に登っていくという考え方です。
会計データを作るために、上流できれいなデータを入れてくださいという考えなのです。
上流できれいなデータを入れるためには、業務標準化がされていないとなりません。他のお客様でも苦労されているのはそういうところだと思うんですね。
このSAPに合わせてデータ項目を入れる時に、今の業務のやり方だと入らないというギャップがあり、そこがERPを入れるときの難しさです。

真下：今、他のお客様で苦労しているという話がありましたけど、アシストの導入を支援いただいているアイ・ピー・エス（以下IPS）さんへのインタビューで、アシストは極端な個別最適なので導入するハードルが高いという話がありました。
ということは、アシストは現状とのギャップが大きいので相当な標準化を図る必要があるということですよね。

矢農：その通りです。経理だけでなく、発注側も受注側も含めてだいぶ変わる感覚があります。

真下：そのための重要なファクターが今回作る発注依頼書。

矢農：それだけではありませんが、重要であることは確かですね。

真下：続いて、現場で考えていること、現場の納得度について、お話しを伺えればと思いますがいかがでしょうか。
ここでいう現場というのは、プロジェクトに参画している割と現場寄りの方々（業務改革センターの課長クラス）という意味合いです。

柳：現場の理解度、納得度としては頭では分かっているけれども、たまに感情に揺さぶられるようなイメージですかね（笑）

駒形：先日、IPSさんへインタビューをしたときに、今の段階になってかなりAs-Isへの揺り戻しが起きる懸念があると聞きました。
現場に近ければ近いほど、そういった細かい話になってくると思いますが、課長クラスでもそういう話になりますか。

柳：そうです。
大前提として全体最適をしましょうとか、属人化を省いた形で業務を定義していきましょうという認識は持っています。
ただ、日々の業務でお客様やメーカーと個別で発生するやり取りに関しての議論になっていくと、どうしても個別最適の話に潜り込んでいってしまうという傾向は正直あります。
それらの問題を解決するために、意思決定会議という会議体を設けて方向性を決めていくことにしています。
今のシステムも個別最適に揺り戻しがあると言いながらも、ある程度は要件は決まっていて、IPSさんからアドオンの部分も含めて、モジュールが納品されている状態です。新たなアドオン開発はしていません。
そのため、これ以上新しい要望を組み込む議論はありません。今決まっているNEXISに乗らないものはどうしていくかという別の検討を行い、運用で回すのか、次のステップで採用するのかなど、ある程度線引きを行って、最終工程に向かっているような状態です。
一方で、大変なのはSalesforce側だと思います。
SAP側も一部アドオンは開発しましたが、やはり大きなもの、例えば継続保守業務の取り扱いなど、SAPの中で回らないものは全部、Salesforce側で吸収するということで進めています。

真下：SAPに乗らない機能についてはSalesforceで、という話ですけども、それはイコール、個別最適で対応しなくてはいけないことをSalesforce側で対応しているという話ではないですか。

柳：個別最適というよりも、SAPで持っていない機能というものがあるんですよね。
例えばアシストの売り上げの柱の1つである継続保守契約の考え方というのはSAPの標準機能ではもっていません。
最初は単純に受注伝票を回してしまうかという話もありましたが、今までの業務とのすり合わせをして落とし所を考えていく中で、Salesforceで吸収していくことになりました。
この方針は当初から決められていたもので、途中から急遽このように対応し始めたということではありません。当初の設計としてそういうものはSalesforce側で手当てしていくという形にはなっていました。

真下：なるほど。ここまでのTo-Beのラインは維持しつつ、SAP側が持っていないものに関しては、To-Beにのっとった形でSalesforceで対応するということですね。

柳：はい、そうです。

沖：あとはSAPの受注伝票に渡す部分のデータの整形がSalesforce側になります。受注依頼のようなデータを作ってもらうんですけれど、これは見積もりデータから落としていくんですね。
見積もりがSalesforceで作られるので、作られた明細データに基づいて受注データが起票されるという流れがあり、そこをSalesforceが担っています。

駒形：一般的にはSAPで見積もりを作ることが多いですか。

沖：はい、多いと思います。
SAPの販売管理で見積もりを作る会社さんは非常に多いと思っています。
アシストのようにフォーキャストデータ（受注見込みデータ）をSalesforceでガッツリ管理して、フォーキャストと見積もりを連動させている会社はほとんどないと思います。
アシストはSalesforceによる見積もり管理が浸透しており資産も相当あるため、SAPができたときにどうしても連携をさせたいというところが他の会社と比較して珍しいのではないかと思います。

駒形：SAP側に見積もり機能があるなら、そちらを使おうという話はありましたか。

沖：そういう声もありましたね。
アシストは以前から見積もりと案件管理を一体化して管理しているので、受注予測の精度が高いという良さがありました。SAPで見積もりを作るということは案件管理側に見積もり金額を転記することになるため、従来のような高い精度の受注予測管理が崩れる恐れが発生します。どのようにして精度を担保すべきかを議論した結果、やはり、Salesforceで見積もり管理を行うという結論になりました。