アシスト基幹刷新の取り組み

  • 実装段階
  • DXへの取り組み
2025.01.23

導入ベンダーから見るアシストの業務(3)

導入ベンダーから見るアシストの業務(3)

アシストでは創立50年を迎えた2022年、激変するビジネス環境、ますます加速されるスピード化に対応するため、今まで20年以上にわたり利用し続けてきた基幹システムの刷新を行うためのプロジェクト(社内名称:NEXIS)を発足しました。
この、基幹システム刷新の状況をなるべくリアルタイムに近い間隔で、社内キーパーソンへのインタビューを中心に、良い話も悪い話も区別なく皆様にお届けしたいと思います。

今回はアシストの従来の業務やSAPへの適用状況について、導入ベンダーとして本プロジェクトに参画いただいているアイ・ピー・エス社と本プロジェクトのプロジェクトマネージャーの岡田優治へのインタビューを通して、3回に渡りお伝えします(第3回)。

こんにちは。インタビューを担当させていただきます営業の真下(ましも)と駒形(こまがた)です。
今回は基幹刷新プロジェクト「NEXIS」に導入ベンターとして参画いただいているアイ・ピー・エス(以下IPS)さんとプロジェクトマネージャー(PM)である岡田さんにアシストの業務フローの特徴やSAPへの実装に向けた苦労について伺います。
第1回 第2回 から続く)

As-Isへの揺り戻しの苦悩

真下:まだプロジェクトの途上ではありますが、今回のプロジェクトに参画いただき実感した、業務改革を実現するために必要なこととは何でしょうか。

IPS:2年前に作ったTo-Beです。このTo-Beが実現すべき明確なゴール設定となり、そのゴールをプロジェクトメンバーと社員へ周知する。それが全てではないでしょうか。

社員からすると今の業務のやり方のままの方が楽ですし、慣れているので効率的だと思っている人がほとんどだと思います。「新しいことに変える、しかも全体最適になる」というのは窮屈にしか映らないと思いますので、To-Be側に寄せて行くのは個々の人にとってはきつい話です。トップのメッセージが大事という話がありましたが、それは、明確なゴール、全体最適に向かって有無を言わせず、「やるんだ!」といかに徹底できるかということです。そうしないと、どうしても現状に戻ってしまいます。1年くらいでやりきるのであれば、そのままTo-Beで突っ走れますが、2年くらいたつと、徐々にAs-Isに戻ってしまいます。だからこそ、右か左かで迷って立ち止まっている時には、「こちらに進まなければならない」という方向性を発信し続けることが非常に重要になってくると思います。

先ほど、最高意思決定会議でディシジョンする(導入ベンダーから見るアシストの業務(2) )という話がありましたが、本来はそこに行く前に錦の御旗のもとに、「To-Beはこうだよ!」と浸透をし続けることが大事だと思います。「変えることが目的のはずだ」というのが2年前から一緒に参加している私のこのプロジェクトへの認識です。「なぜSAPを入れるのですか?」という問いに対する理想解は、「属人化された業務をやめて経理が一つのやり方だけを覚えれば会社の決算ができるようにする」ですが、現実解としては一つのやり方にはできません。それでも、今の100通りの方法から6つくらいの方法で経理が回るようになれば、とても効率化されるはずです。それをゴールにすべきだと思って、私はこのプロジェクトに参加していますが、この3、4ヵ月はどうもそうなっていない気がしてきています。岡田さん、どうすれば良いですかね。

岡田:元々最初から想定されていたフェーズの一つであり、それが今来ているのかなと思っています。そのため、今IPSさんからお話しいただいた「To-Beを実現させる」というところに立ち返る部分のプロセスを踏めないとすると、ズルズル失敗してしまいます。

IPS:お金をかけて今と同じやり方をしました、という結果になってしまいますね。

岡田:先ほどお話があったように、アシストも業務としては回っています。現状のAMIS(販売管理システム)で業務が回っているので、今すぐに絶対に何かを変える必要があるかというとそうではありません。そのため、上層部を含めて関係者の間に危機感や温度感にばらつきがあります。この規模のプロジェクトで、どのようにして両者を同じ方向に持っていくかが非常に難しく大きな悩みの一つです。

プロジェクト外のメンバーからすると、NEXISは魔法の箱だと思われており、「NEXISになったら解決してくれるんでしょ?」という漠然とした期待を持っています。一方で「業務が増えるのではないか」という自分ごとで見た時に不安に思っているメンバーも一定数存在します。結局、会社として方向性を持って「全体最適をした後に何を目指すのか」というところをきちんとつなげていくのが重要だと思っています。
業務変革を行うことで「従来、事務処理に費やしていた時間をお客様のためになる業務に費やしましょう」というのが全社に向けたメッセージです。色々な立場の社員がいる中で、このメッセージをどう工夫して広めていくのかということが現状の課題の一つであると認識しています。

駒形:アシストの経営サイドの思いが、強い覚悟を持って進めるんだ!というレベルに達していない、と感じますか。

岡田:大塚(社長)は、その覚悟を持っていただいていると思っています。 プロジェクトオーナーである執行役員の林と大塚の間では、3年間くらい継続して要所要所で議論をしているため理解いただけています。一方で全ての役員や上位マネージャーは同じレベルの意識にあるかというと疑問があります。

駒形:一番のトップである社長はちゃんと覚悟を持っているが、現場を束ねている部門長は、そこまでに至ってくれないというケースは他社でも多いのでしょうか。

IPS:大体そうですね。他社では営業部門の反発が大きいことが多いですね。 経理は協力的なことが多いです。

駒形:そうするとますますトップの発信が重要ですね。

岡田:「あるべき姿に向けて業務が変わります」という大きな方向性は決まっているので、それを浸透させるために社内発信をしていくことが重要です。プロジェクト内では社内広報という呼び方をしていますが、ブログや動画を作って社内に発信する活動を強化しています。「アシストはこれからどう変わっていくのか」という点に関心を持っていただくための活動です。今まで、具体的になっていないことが多かったために発信できていなかったことが、ようやく全社に公開できるフェーズに差し掛かってきました。ここが踏ん張りどころだとプロジェクトのコアのメンバーは思っています。

IPS:このプロジェクトは何を目指しており、大事にするべきことは何かということを押さえておく必要があります。先ほどの仕様を固めることにおいては、

  • ・あるべき姿に向かった文脈で切ること
  • ・要件定義をちゃんと固めること
  • ・マスターの設定をおろそかにしないこと
  • ・ユーザートレーニングを行うこと

が大事です。
何を大事にするべきか周知徹底すると、トレーニングの時も「私は新しく変わった業務でやらなければならないからこのやり方でやる」と主語が自分ごとになります。
業務が忙しいのは分かっているが大事なことなのでやりなさい、と部門長がリーダーシップを発揮しないと、ユーザートレーニングが原因でプロジェクトが失敗します。そういうプロジェクトも非常に多いです。

駒形:トレーニング開始前の段階での意識付けがとても大事なのですね。

IPS:はい。「なぜ、定時後に新しいシステムにログインして受注コードを打たなくてはならないか」という意味を伝えないといけないのです。冒頭の話(導入ベンダーから見るアシストの業務(1) )にもありましたが、中堅規模の企業だとトップダウンが効くとあったのはこうした点をしっかりと伝えられる点にあります。

真下:話は変わりますが、数年前にアシストがSFAとしてSalesforceを導入した時には各部門に推進役を配置しました。彼らを通して現場への浸透を深める活動を行った結果、今ではかなり定着してきたと感じていますが、SAPも同様の進め方をする予定ですか。

岡田:SAPについては利用する部門を経理部門と業務改革センターに集中させているので、今回はそのような浸透活動は行いません。ただ、営業側で変わる業務や評価制度については、今後伝えていく予定です。これは技術部門も同様です。

これからは受発注、出荷などの受け皿が業務改革センターに全社的に統一されます。営業アシスタント業務で例えると、大阪、名古屋と東京の各拠点や部門ごとによってやり方が違うことがありました。業務改革センターを全社のバックオフィスとして統一し、全体最適化を目指します。これによってプロジェクトの当初からの目的と組織として目指すところが同じ状態になりました。これからは、それぞれがブレない状態を継続させることがとても大事になってきます。

IPS:例えば商社では営業とアシスタントが個々の取引先向けに独自に行っている業務は山ほどあります。そのような企業がSAPを導入する場合、受注センターを作りSAPを使う組織を集中させるというやり方をすることがあります。それにより、受注センターの中で標準の業務フローを作り、今まであった独自の業務フローの翻訳を行い、きれいにデータが入るようにする、というやり方です。アシストさんが立ち上げた業務改革センターと同じ役割ですね。

そうすることにより標準形ができあがり、ここに統制をかけると標準から外れるものは受け付けなくて済みます。また、もう一つの効果として、今までは10人いたら10人分のやり方があるので担当者の代替が効かなかったものが、標準化により代替が効くようになり余力ができます。平均値でいうとSAPを入れて標準化を図ることにより10人必要だったところが6人で済むようになります。

真下:ありがとうございます。アシストもまさしく、今のお話のような効果を狙って業務改革センターをつくったのですね。

コミュニケーションの重要性を痛感

真下:次の質問です。先ほどより、今回のプロジェクトでは仕様を確定させる明確なルールがなかったことが大きな課題としてあるというお話を伺いましたが、それ以外で大きな課題となったことはありますか。

IPS:アシストさんはITのプロフェッショナル集団なので、言葉はすごく通じやすくて良いのですが、IPSとアシストさんの間で言葉の認識齟齬が結構ありました。われわれはSAPのワードとして話すのですが、アシストさんの中では同じワードでも指し示すものが違うことがありました。その結果、われわれは伝わったと思っており、同様にアシストさんはわれわれに伝えて合意できたと思っていることが、後々になって「なんでそんなことが決まっていないんだ」ということが多かったですね。

例えばデータ移行を例にすると、われわれSAP側からすると「マスターには現行システムからこの情報を入れてください。もしくはこのシートに当てはめてもらえればこちら側でアップデートします」というような作業をイメージした言葉を“移行”と捉えて話をしていましたが、アシストさんからするとSalesforceがあってSAPにつながる業務があります。そのため、SAPにだけ単独でデータをいれても意味がなく、業務上SalesforceからどうSAPにつなげるかという一連の流れが“移行”です。アシストさんにとってはシステムの切り替えをどう行っていくかが移行のテーマなのに対し、われわれはSAPの中にデータを貯めて不整合が起きないかが移行のテーマであったため、最初から認識がまったく異なっており、議論のスタートラインに立つまでに非常に時間を要しました。ここはIPS側が反省しなければならない点だったと感じています。

駒形:言葉の解釈の違いというのは、よくある話だと思いますが、今回それが大きな問題となったのはアシストがIT業界の会社だったからでしょうか。

IPS:それもあると思います。IT業界の常識である言葉とわれわれも似た言葉を多く使っていますが、意味が全然違うということが起こったのだと思います。

駒形:他の業種の企業だとこういったことは起きにくいですか。

IPS:はい。他の業種の場合、われわれの言っている言葉がわからないので質問をしてきます。そもそも「移行とはなにか?」から始まります。そのため、一見、同じ言葉で会話ができるような業種の方とプロジェクトを進める時は、特にコミュニケーションを重ねて認識合わせをしっかりしないとリスクが高くなるということを痛感しました。

駒形:同じIT業界の方が、よりスムーズに進むかなと思いますよね。

IPS:われわれはSAP専業なので、われわれの常識もそういう意味では偏っているんですよね。
一例をあげると、「アドオン」という言葉をよく使いますが、他のパッケージであれば「アドオン」に相当するのは「カスタマイズ」になります。パッケージを「カスタマイズ」するということは「手を加えてプログラムを書く」ことになりますが、SAPの場合、「カスタマイズ」は「パラメーターを変更する」だけなので、そこで認識のギャップがおきます。今回はそうした認識ギャップの一つが起きたということですね。

その他、苦労したところというか一番時間がかかったのは「プロセスのマッピング」ですね。アシストさんの中で最適化して決めた業務プロセスを、いざSAPに落とし込むと当てはまらないものが相当数あり、時間がかかりました。例えば、本来だと「在庫販売」、「直送販売」などのキーワードで落とし込みをすることが多いですが、アシストさんの場合、「在庫は保持しない」、「直送販売にも色々な方法がある」、「請求方法も本来は売り上げをあげてから請求書の発行をするが、売り上げをあげる前に請求書を発行することもある。ただし、それは検収基準である」というケースなど、なかなか一つの箱に収まりませんでした。それらをどのように標準のプロセスの中で派生を作るか、という整理に一番時間がかかり苦労しました。

駒形:今回、まずアシスト側でSignavio(業務プロセスのモデリングツール)を使ってプロセスフローを作りました。そこからSAPのプロセスにマッピングさせるという進め方をしましたが、このやり方は一般的なのですか。

IPS:いえ。どちらかというとSAPを前提にして業務フローを作る方が多いです。

駒形:それは初めからSAPに合わせるという前提の場合ですよね。アシストは業務フローを作る段階ではSAPを前提にはしていませんでしたね。

岡田:そうです。

駒形:マスターはどうですか。非常に苦労していると聞きました。

IPS:マスターもそうですね。今も苦労されていると思いますが、例えば仕入先マスターを準備しないとなりません。マスター整備の課題として最たるものは汎用項目というものがあり、同じ項目にもかかわらず、商材によってまったく別の意味のデータで使われています。
そのため他の人が見てもわかりません。Aさんはここは「納入期日」が入っていると理解していたが、実際には「希望期日」が入っていた、などと本来は意味合いが違っているものが共存している項目があり、それを精査するのは苦労されたと思います。

駒形:今回最終的に正のマスターがSalesforceになったと聞きました。

岡田:品目に関してはそうです。

駒形:それはSAPにすることが難しかったのですか。

岡田:アシストには大きなシステムとしてSalesforceとSAPの2つのシステムがあり、見積もりに関してはSalesforceを利用しています。今までは品目マスターに登録されていなくても見積もりの作成ができましたが、SAPリリース以降はマスターがないと見積もりの発行ができなくなります。2つのシステムの連携の流れを考えたときに、ビジネスの発生源であるSalesforce側の品目マスターを正として、SAPと整合性を持たせた方が都合が良いと判断をしました。
元々はSAPを正としてSalesforceに戻すことを考えていましたが、その場合、システムの制約上、どうしてもタイムラグが発生してしまいます。それでは業務に支障が出るため、営業が操作できるSalesforceを正にした方がスムーズになるだろうと考えました。

IPS:マスターはSAPの根幹なので、フラグ一つでも間違えるとまったく違うプロセスが走ってしまいます。マスターが全ての業務プロセスをコントロールしており、SAPにとっては非常に大事なので、SAPを正にすべきであるとベンダー側の常識としては考えるんですよ。そのため、業務全体を眺めたときにマスターはフロント側に持った方が良い、というのは当たり前のことなのですが、われわれの中で納得感を得るのに少し時間がかかりました。ここはわれわれの常識で縛られているところでSAPを専業にしている者の弱さかもしれません。

プロジェクト推進に見るアシストの強みと弱み

真下:ありがとうございます。私もSalesforceにマスターを持つと聞いたときは「あれ?」と思いましたが、そういう背景があったのですね。
次の質問に移ります。今回のプロジェクトが他社のプロジェクトと異なると感じた部分などありましたか。また、アシストの動きについて感じられることがあればお願いします。

IPS:上から目線での言い方になってしまいますが、アシストさんは発注者責任の自覚がすごくちゃんとしています。プロジェクトの責任者として、オーナーシップの強さはすごいなと思いますね。
理不尽な話ではなく、われわれの足りないところに対して「もっとこうして欲しい」と色々なご意見、ご指摘をいただきますが、責任感があるからこその話だと捉えています。

通常はわれわれが「あなた方が当事者意識を持ってやらないといけない、あなた達が主役でやらないと要件定義とマスターとユーザー教育では問題が起こります」と、こんこんと説明して盛り立てているのですが、そういう場面はありませんでした。
一方で裏返しになりますが、SAPもあくまで今回のプロジェクトの中では一つのパーツです。大きいパーツではありますが、その他にたくさんのパーツがあり、われわれが絡むところは一部のパーツなので全体感としては見えていない部分もあります。

アシストさんは全体感の議論をしながら、われわれと1パーツであるSAPについてやり取りをするわけです。そこでキャッチアップできていないことを言われることがあります。例えば「品目マスターはSAPが正のはずだったが、何かが変わった?」というようなことは、アシストさんが全体を責任持ってコントロールしているが故に発生します。1パーツとはいえ、コミュニケーションギャップにより全体が崩れてしまう大事なところを担っているという自覚があるため、そこの難しさはありましたね。
初期はこうしたことが多々発生し大変でしたが、ここ半年は「雑談会」と称する会議体を作っていただき、2社間のコミュニケーションは格段に向上し解消されました。

決めきれないアシスト

駒形:厳しい話もぜひお願いします。

IPS:先週決まったことが翌週にひっくり返ります。それも結構な頻度で(笑)。

真下:それはアジャイルだからですか。

IPS:アジャイルだからではないと思います。例えば価格に関するセッションで「これで行きましょう。計算式もこれで大丈夫です」という決定があり、システムに設定を全て反映してお見せします。すると「この計算式、違う時があるな」という話になるのです。このようにわれわれとしては決まったと思っていたことが、次の回で議論をし直し、持ち帰りになるというケースが多かったです。ここは他社さんより多いですね。 先ほどの話とつながりますが、「これで仕様凍結です」の前提で進むのですが、ルールがふわっとしているために揺り戻しが起こるのかなと思います。事務局の方々も苦労しているところだと思います。
こうして決定が変わることで、決まっている追加開発の部分に影響を及ぼすこともあります。

真下:他社と比べてプロジェクトのスピード感はいかがでしょうか。早いですか。普通ですか。

IPS:議論に取り掛かるまでは、すごく早いと思います。一方で最終的な結論に至るのにはすごく時間がかかってしまうことが多いという印象です。

駒形:ステークホルダーが多くて、その意見を聞いてしまうからでしょうか。

IPS:そうですね。販売・購買のセッションも20数名が参加されていますが、「ここの部分はそうではない」という意見が一つ出ると皆さん確定しきれなくなってしまい、後回しだったり、持ち帰りというのが続きます。今日決めよう、と合意していたのに決まらないということはかなりありますね。後半になればなるほどその傾向が強いですね。議論している課題自体が相当重いものだからだと思いますが。

岡田:プロジェクトで把握しているコアな課題もありますが、それは1年くらい同じ議論をしているんです。結局、結論が出ないので、その結論を出すために意識して会議体を設け、ここからスピード感を高めていこうと考えています。

駒形:責任の所在を明確にしたということですかね。

IPS:そうですね。

岡田:意思決定者にポイントを理解していただいて、その意思決定者がメンバーに発言をすることによって、As-Isへの揺れ戻しをプロジェクトとして防ぐような体制を急ピッチで構築している最中です。

SAPプロジェクトを成功させる3つの要素

真下:ありがとうございます。なかなか耳の痛いご意見もいただきました。最後の質問です。これからSAPを導入するユーザーにアドバイスがありましたらお願いします。
さきほど、目的の明確化と周知というお話をいただきましたが、プロジェクトの進め方という観点でお願いできればと思います。

IPS:先ほどまでの話をまとめることになりますが、プロジェクトを成功させる要素は3つあると考えています。

1つめは要件定義です。いかにアドオンという余計なものを作らないようにするか、「要件定義の決定力」です。 要件定義で問題がおきた場合、このプロジェクトをなぜやるのか、が要件の取捨選択の基準になります。そこが「いかに明確か?」だけがポイントになります。
プロジェクトに入る前に、どれだけ価値基準を持てているか、トップ含めて合意ができているか、反発が出てきた時に「価値基準はこうだから、これを選択するのです」ということを言えるかです。

2つめがマスターの制御です。マスターについては「あるある」の話ですが、マスター項目は山ほどあるわけです。
価格や品名といった普通の項目ならよいですが、マスターにはSAPのプログラムを制御する項目もたくさんあります。「Aのフラグに1を立てると在庫がないと出荷できない商品」とか「この項目に1が立つとロット管理される」などです。
ただ一般ユーザーの方はそんなプログラム制御の話をされてもわかりません。
そのため、マスター制御として何をするかというと「まあいいや。全部1を立てておけ」と放り込むのです。
プロジェクトが進行し、最後の稼働直前のユーザートレーニングの時に自分で処理をする時に1の意味を知るのです。「なぜかロット管理をしないと登録できない。受注できないんだけど」という具合に慌てふためくわけです。このように最後の場面で初めてマスターの意味が分かる、というのがSAP導入遅延の「あるある」なのです。この状況でマスターを再整理すると3ヵ月ぐらいかかります。
それを防ぐためには、マスターの項目の意味やマスターがSAPのプロセスとどう連携しているのかを学習する姿勢と、マスターを知り尽くした人を4、5人作ることが必要になってきます。

3つめがユーザートレーニングです。ユーザートレーニングは、トップがその重要性を理解すること、現場の部門長の協力体制をいかに取り付けるかが重要です。われわれはユーザートレーニングの進捗管理表を作ります。これを部門長のマネジメント能力評価と直結させることをよくやります。トレーニングの重要性をいかに部門長に落とし込んで取り組ませるかがポイントになってくると思います。 今お話しした3つのことは全てユーザー側の責任で進めるべきものです。

責任逃れするつもりで言っているのではなく、結局、最後はユーザー側の責任になってしまうんですよね。
最終的にはわれわれのお手伝いのしようがないところです。アドバイスはできますが、やってくれないと困る部分で、ここは変わらないところです。
誰かがやってくれる、という当事者意識がないプロジェクトは必ず失敗します。

まったく違う観点で、プロジェクト推進において属人化しないということも重要です。
業務の属人化とはまた別で、「なぜ、この仕様に決定したのかわからない」ということが過去にありました。仕様を決めた人が急に病気で倒れてしまい、プロジェクトが数ヵ月止まってしまったのです。キーパーソンが退職してしまい、止まってしまうケースもあります。
属人化しないために全体最適をしたのにプロジェクト自体が属人化していたという例です。
アシストさんには当てはまりませんが、そこも結構大きなポイントかと思います。


駒形:以上でIPSさんへのインタビューを終了いたします。
今回は耳の痛い話も含めて、勉強になるお話を多く聞くことができました。
これからSAPを導入しようとしている企業の方にも参考になったのではないでしょうか。長時間にわたり、ありがとうございました。


(本記事は2024年10月に行ったインタビューをもとに執筆しています)

※記載されている会社名、製品名は、各社の商標または登録商標です。





インタビュアー&執筆者情報

​真下 悦拡(ましも よしひろ)
東日本営業本部 東日本営業統括部

粘り強い営業に定評あり。同世代のエース。



駒形 美鈴(こまがた みすず)
東日本営業本部 東日本営業統括部

童顔からは想像できないキレキャラ。番犬的存在。


関連している記事

  • 実装段階
  • DXへの取り組み
2024.12.26

導入ベンダーから見るアシストの業務(2)

アシストの基幹刷新プロジェクト(NEXIS)について、これまでは社内のプロジェクト関係者へ話を聞いて状況をお伝えしてきました。今回より導入ベンダーであるアイ・ピー・エス様から見てアシストの業務やプロジェクトの推進がどのように映っているのか、話を伺います(第2回)。

  • 実装段階
  • DXへの取り組み
2024.12.12

導入ベンダーから見るアシストの業務(1)

アシストの基幹刷新プロジェクト(NEXIS)について、これまでは社内のプロジェクト関係者へ話を聞いて状況をお伝えしてきました。今回より導入ベンダーであるアイ・ピー・エス様から見てアシストの業務やプロジェクトの推進がどのように映っているのか、話を伺います(第1回)。

  • 実装段階
  • DXへの取り組み
2024.12.06

ERPパッケージ選定とSAP導入を決めた理由

アシストの基幹刷新プロジェクト(NEXIS)について、これまでは社内のプロジェクト関係者へ話を聞いて状況をお伝えしてきました。その中でお伝えできなかったアシストがSAPを選定した理由について、今回は遡って伺います。

ページの先頭へ戻る