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

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

駒形：はじめに現行の業務プロセス、システムについてです。
どのような点がアシストにおける現行の業務プロセス、システムの限界と感じられて今回のプロジェクト発足に至ったのでしょうか。また、具体的なきっかけとなるようなことがあれば教えてください。

林：保守契約の更新処理を担当している継続保守チームが経営企画本部の配下となった時、皆さんから口々に「人が足りない、増やしてくれ、限界です」と聞かされました。
アシストのビジネスを考えた時、お客様と直接やり取りを行う営業や技術の増員をした方が良い。しかし、声を上げている人たちの負荷も同様に軽減させなければならない。
これら二つの側面から新しいシステムを考える必要がある、という話が出始めました。

沖：一方で営業を増員するには営業アシスタントも増やさないと業務が回らないという話がありました。でも、それはおかしいのではないか？業務処理効率が上がれば、アシスタントを増やさなくても営業を増やすことはできるのではないかと考えました。
もう一つの要因は、現行のシステムの保守をできる要員不足が喫緊の課題としてありました。
これらの課題感からシステムのリプレースは必然でした。

林：アシスタントの適正人数について、何人かの営業マネージャーにヒアリングしたところ、営業5人に対して1人は絶対に必要だという話がありました。そうすると、営業を増員する場合、それに応じてアシスタントも増員させなくてはならないということになります。アシスタントの方たちにも苦しい事情があります。現状、営業アシスタントという名前でありながら、契約や請求などの事務業務に工数の80～90%が取られており、本来のアシスタント業務（営業の支援）を行える状況ではありません。
とある地区の営業アシスタントの一部の方たちは、営業の代わりにアポイントを取ったり、提案チームを率先するなど、営業の助けになるようなことをしています。東京の営業アシスタントをはじめ、大多数のアシスタントがそのような業務を行えないのは、事務業務が非常に多く圧迫されているということです。それであれば、圧迫している原因を取り除かないと話が始まらないということです。

真下：業務負荷の問題は東日本で顕著だったのですか？

林：最も顕著なのは東日本ですが、他の地区にも徐々に波及しています。障壁となっているものが何か調べてもらったところ、やはり契約時の事務工数などがとても大きいということがわかりました。

営業部門だけでなく、経理部門でも問題を抱えていました。どのような問題かというと会計システムとAMIS（アシストの販売管理システム）が密なシステム連携をしておらず、Excelファイルの受け渡しで連携をさせている状況でした。会計システムからデータをExcelに出力し、そのデータを修正した後にAMISに流し込むようなことをしていました。これではシステムとは言えず手動とほぼ変わらない状態です。

さらに仕入れの問題もありました。取引しているメーカーによって処理のルールが異なっており、メーカーごとに担当者を分けて業務を回していました。
その際にメーカーの要望や事情に合わせて、取引メーカーごとに個別の処理を行っていました。
しかし、これら、メーカーごとの個別処理を全て把握している人はいませんでした。
さらにメーカーだけでなく、個々のお客様の要望や案件の状況に合わせて、様々な特殊処理、例外処理も行っていました。そうした特殊処理を全部把握している人はいるのだろうか？というと誰もいません。
メーカーに対しても、お客様に対しても全てを把握する状態にない、これは会社として制御されている状態なんだろうか？という問題となります。
お取引するメーカーやお客様が少なく、社員数も少ない時は良かったのですが、お客様やメーカーが増え、社員数が千何百人となり、従来のオペレーションが破綻しかかってきました。

沖：営業は「お客様が言ってるんだからこれくらいやってよ」と言ってくるのですが、それが積み重なるとすごい数になるんです（笑）。

林：その人がいないと業務が回らなくなってしまいます。私たちはそれを事務社員高職能化と呼んでいます。多能工化が進みすぎてしまいました。
完全に属人化している状態となってしまい、引き継ぎができません。
例えば、一人の非常に優秀なアシスタントが退職し、新しい派遣の方に交代した際、どのくらいで業務を覚えられますか？と確認すると、「1年程度です」とか「3年はかかります」と返ってきます。
しかし、派遣社員にお願いする場合、派遣法により、3年たったら別の部署に行かなくてはなりません。覚えた時にはもう別の部署に行かなくてはならず、これは大きな問題です。全ての人にとって不幸でしかありません。
これらの問題を解決するためにシステム的につなげることを決断しました。まずは経理の手作業をシステム化する。そして営業アシスタント、メーカー担当が判断して処理していた部分をIT化するのと同時に業務整理も行い、標準化（単能工化へのアプローチ）を図る方向に舵を切りました。

「人が辞めてしまったら、後任の人が3年もかけずに1ヵ月で習得できるようにしたい」
「営業アシスタントの人たちは事務作業に時間を割くのではなく営業支援をしてほしい」
その結果、アシスタントの人たちはもっと色々な業務に幅を広げることができます。例えば、お客様への提案時、彼・彼女たちが提案チームを編成してマネジメントをする、などです。そのようなことができれば、営業はもっと楽になりもっと稼げると思います。
このような仮説を持って、そこに向けたアプローチをしていこうと考えています。

駒形：今回、プロジェクトへ着手するにあたり、描いているTo-Be像について、業務プロセス面、システム面からお聞かせください。

沖：一昨年、業務分析をした時にアシストの業務自体がスパゲッティ状態になっていることが浮き彫りになりました。
一例として、見積書の作成、受注、メーカー発注、契約締結、請求、経理計上を行うというフローがあります。本来は川上から川下に向かって一つのフローとして流れます。それであれば業務プロセスはシンプルで分かりやすいのですが、実はアシストの業務モデルはスタート地点がバラバラです。
例えば、最初に請求データが作られてから契約処理を行うなど、どこからでも業務がスタートすることができる業務処理を行っています。これが複雑さを招いている一つの要因です。

真下：これはお客様によって違うのでしょうか。

沖：違います。お客様ごとにスタート地点が様々ですし順番も異なってきます。
それを川上から川下にきれいに流れるようにして業務単位で揃えるには何をしなければいけないのか、しっかりと決める必要があります。

もう一つ、アシストは受注データをフォーキャストデータで管理しているため受注データとしては存在しておらず、契約データしかありません。そのため、どのようなデータが受注されたかわからないのです。翌年のサポート契約があるものは契約データとしてきちんとシステムに登録されていますが、それ以外のデータはわかりません。受注に関する情報についてはフォーキャストデータによって把握しています。フォーキャストデータに精緻な金額が入っており、それを受注データとして扱っています。ところが、そのデータと経理が実際に入金されたデータと照合をした際に乖離が出てしまうことがあります。受注データがあれば、乖離の理由がわかるはずなのですが、それがすぐにはわかりません。例えば、一つの案件のフォーキャストとしてアシストが取り扱っている製品の明細とパートナー企業とお客様が直接契約する商材の明細が混じっているような場合、実際にお客様から入金された金額とフォーキャストデータに載っている金額が異なるケースがあります。このような場合、フォーキャストデータを一つ一つ紐解かないと乖離の理由がわからないのです。
（真下補足：フォーキャストデータの作成、管理はSalesforceで実装したシステムで行っています。）

真下：元々はシンプルだったものが、時間の経過とともに、色々なことが起きて複雑になったのでしょうか？

林：元々はシンプルでした。お客様の要望に応じて処理順番を変えたりすることを繰り返してきました。
アシストはお客様の話をしっかり聞くという良い文化がありますが、それが増えてきてよくわからなくなってしまった。そのため、一度きれいに整理するというフェーズに来た、ということだと考えています。

沖：メーカー対応も昔ほどシンプルではなくなりました。昔はメーカーへの報告は非常にシンプルで「ロイヤリティの金額」、「発注額」、「使用開始日と終了日」それだけで良かったのですが、最近はメーカーに対して他にも様々な報告事項があります。そのため、それに対するデータをちゃんと出していかなければなりません。その数がどんどん増えてきてしまっています。

林：現実のデータのフローや処理のフローはもっと見にくいです。
メーカー、製品、お客様、契約形態で異なる線が何本もあり、大きなモニターで映してもわからないくらい複雑でした。

駒形：これでも、わかりやすく簡素化したのですか？

林：これは一部を切り出したものです。（上記図）
これを頭の中に入れて業務を行っている人たちはすごいと思います。
「すごい仕事、よくこんなにやっているよね、大変だよね」と思います。

沖：これをシステム的にスッキリさせたいのですが、システムだけの問題ではないため、そもそもの業務自体を変えていかないとスッキリはしないということになり、本プロジェクトでは、業務改革を伴うシステムリプレースを目指しています。
まず受注データをしっかりと作りましょうということがベースにあり、そこで作ったデータが発注、請求、経理計上に流れていく、それをTo-Beで作っていきます。
この受注、発注、契約、請求から営業の計上までの複雑な業務処理をアシスタントが全て行い、一人で処理しています。
しかも、加えてお客様ごとの特殊処理が存在します。それらの特殊処理を全て理解して業務を行わなくてはなりません。また、取引メーカーが40くらいある中でそれぞれ発注処理が異なり、それも全て覚えなくてはならず、一人がやっていくには限界が来てしまいます。そこで業務を分けて、多能工ではなく単能工にしていこうということを試みています。受注なら受注、発注なら発注、請求なら請求と。それぞれを業務分担してそこだけやればいいというやり方に変えていきたいと考えています。

林：現在考えていることを実現すればシンプルになり、一つの業務だけに集中でき、覚える時間も短くなります。

沖：そしてシステムがデータをつなげます。例えば、受注業務の担当者が受注データを入れることにより、それを発注データとしてERPが引き継いでくれます。発注業務の担当者はERP上のデータを見て発注業務としての処理を行う。そうすると請求担当にデータが渡り、請求業務の担当者はそのデータを見て請求書を起こす。そういう業務の流れになっていくことをTo-Be像として考えています。

真下：ちなみに恥ずかしい質問なんですが、受注データとはどういうものでしょうか。

沖：受注データとは注文書で頂いた内容を全てデータ化するということです。

真下：アシストには注文内容のデータが全くないのでしょうか。

沖：あるものとないものがあります。正規に取り扱いを行っているソフトウェア製品のライセンス、サポート、サブスクリプションなど継続的に管理が必要なものは契約情報の一環でデータとして存在しますが、契約がないものはフォーキャストデータとしてしか存在しません。

例えばパートナー企業にハードウェアの発注をしたとします。営業はパートナーからハードウェアの見積書を取得し、アシストの見積書に転記してお客様に提出し、その後、お客様から注文を頂きます。この中のハードウェアに関するデータはAMISには残りません。お客様にハードウェアをいくらで販売した、というフォーキャストデータは残りますが注文データとしては残りません。

真下：なるほど。あまり意識していませんでした。例えば、Exadata（Oracle Databaseのアプライアンス製品）には何百もの明細があります。それをデータ化するのは大変です。

林：受領した注文書がシステム的に自動で反映されれば皆さんとしても良いのではないでしょうか。
このように現在のアシストには、業務に携わる人的、リソース面の問題と業務プロセス、システムそのものの問題があります。これらを一気に解決させましょうということです。

駒形：ありがとうございます。今回はここまでとさせていただきます。

次回は、今回お聞かせいただいた課題に対して、最初に取り組まれたことについてお伺いします。
次回も、よろしくお願いいたします。