DX station

ケーススタディ Dynamics 365 で業務標準化を実現!SBT の導入プロジェクト

こんにちは、SB テクノロジー (以下、SBT ) セールスコンサルティングチームの築地です。

「属人化されている作業の標準化」という言葉をよく聞くようになりましたが、これまでも標準化への取り組みは、システム導入の目的・課題として挙げられるお客様がたくさんいらっしゃいました。ただ、標準化されていなくても多少の手間、面倒くささ、非効率さを我慢すれば、何も劇的な変化、改善をせずとも業務に支障はないため、標準化は後回し、社内の反対、調整の困難さから立ち消えた……というお話しを聞くことも珍しくありません。

今回、ご紹介するケーススタディは、そんな状況を打破し、結果を導いた Dynamics 365 導入のプロジェクトです。属人化、標準化されない業務をどう改善すればよいか、今、同じような問題を抱えている方に、SBT がなぜ Dynamics 365 導入をご提案し、どのようにプロジェクトを進めたかをご紹介します。

  • 製品名は、2021年8月時点の情報です。

ケーススタディ・プロフィール

今回のケーススタディのお客様(以下、X 社)をご紹介します。

X 社は、設備機器の製造販売、メンテナンスまでをワンストップで手掛ける企業です。世界各国に拠点を置くグローバル展開で、国内ではトップシェアを誇ります。

そんな X 社は、どのような目標を掲げ、何を解決するために Dynamics 365 の導入を決めたのでしょうか。

目指すゴールと課題

X 社は目標を「メンテナンスビジネスの収益拡大」と掲げました。

「ケーススタディ・プロフィール」でもご紹介しましたが、X 社は、自社でメンテナンスを行います。初期に販売した後も継続してメンテナンスサービスを提供することで利益を生むメンテナンスビジネスは X 社の重要な柱です。しかし、その目標を達成するためには、いくつもの課題がありました。

課題1 分散・散在された顧客情報

X 社全体では顧客情報を共有する仕組みがなく、情報が分散、散在していました。

例えば、メンテナンス作業に何か問題が発生しても、過去の対応を確認する仕組みがないため、ベテランエンジニアの経験、勘とコツに頼って問題解決をすることが常態化していました。本来ならば X 社の財産となるはずのノウハウはベテランエンジニアに蓄積され、ますます属人化していく、属人化を避けたくとも避けられない、全社的に共有する仕組みがないからそうせざるを得ないという状況でした。

課題2 共有されないメンテナンス情報

X 社はお客様からの問合せを電話でも受け付けています。電話で問合せ対応をするのはエンジニアで、実際にお客様の元に赴き対応するのも、電話で対応したエンジニアでした。

受付も対応も同じエンジニアが対応するため、お問合せしてくださったお客様の状況を把握しやすいというメリットがある反面、エンジニアの予定が埋まっていたら対応が遅くなり、対応件数も限られていました。問合せと対応の両方を担うエンジニアの高負荷状態も続く、メリットよりもデメリットの方が大きい状況でした。

どのような対応をしたかなどの情報共有がされる仕組み、ルールもないため、以前、対応をした内容も確認することができず、ここでも属人化が生まれていました。

課題がもたらした状況

課題1、課題2共に、情報共有ができていないことによって発生している課題です。それにより明確になった大きな課題は「メンテナンス作業の属人化」です。属人化している業務を誰でもできるようにするための仕組み作りが必要であると X 社は考えました。

メンテナンス作業の属人化図

プロジェクトが立ち上がるまで

冒頭で、作業の標準化の計画をしたけれど、途中で立ち消えてしまうということは珍しくないと書きました。実は、X 社も同じです。X 社でも、業務改善はだいぶ前から叫ばれており、過去にもプロジェクトが立ち上がったことがあります。その時は、X 社内での旗振り役がおらず、頓挫してしまいました。今回、どうしてプロジェクト化されたかと言えば、X 社に旗振り役を担ってくださる方が登場したから、に他ありません。

旗振り役の方は、現状での課題解決がどれほど困難かを充分に理解し、危機感を抱いていました。できているからよいではなく、本来のあるべき姿に向かわないと X 社の未来はないと考えたのです。

必要なのは、現状を解決するシステムの導入。導入することにより次の2点を解決することを目標とし、プロジェクトが発足しました。

  • 顧客情報の可視化
  • 標準的な仕事の流れを作る

どちらも、「脱 属人化」には必要不可欠です。

SBT の提案

ここまでで、X 社の目標、それに対しての課題、また、プロジェクトが発足した経緯をご理解いただけたと思います。それではなぜ、X 社の課題を解決し、目標達成につなぐ新システム導入プロジェクトに SBT が参画できたのでしょうか。

Dynamics 365 導入のご提案

X 社の課題から、SBT は次のように考えました。

まずは SFA ※ を構築し、その後、フィールドサービス機能を拡張することがベストと考え、SBT が得意とする Dynamics 365 をご提案しました。Dynamics 365 には、SFA 機能はもちろんのこと、フィールドサービス機能を提供する Dynamics 365 Field Service が含まれているからです。

SBT から Dynamics 365 をご提案したポイントは大きく2つあります。

POINT1
情報の一元管理が得意
情報共有の基盤として Dynamics 365 が得意としていることはみなさんもご存じかと思います。情報収集だけではなく、「脱 属人化」の課題となっていた「顧客情報の可視化」の実現もできます。営業支援、サポートとサービス、マーケティング、業務管理と Dynamics 365 で支援できるエリアは広く、要望にお応えしやすい製品です。
POINT2
カスタマイズによる要望実現が可能
Dynamics 365 では標準機能でも各支援は可能です。しかし、X 社のように属人化が常態化している場合、「脱 属人化」と言ってもどうしても譲れない業務フローや機能があります。
Dynamics 365 では、顧客、業種、業態の特徴に応えるべく柔軟にカスタマイズができ、機能要望にも対応しやすい製品です。
  • ※ Sales Force Automation の略称。営業支援システム

フィールドサービスアセスメントのご提案

販売~メンテナンスサービスの工程で基礎となる顧客情報の収集から着手すべきと考え、SFA 導入を優先した提案をしました。まずは、製品アセスメント・要件定義を実施するというプロジェクト計画です。この図で言うと STEP1 が該当します。

STEP 図

ただ、X 社の課題は、顧客情報の集約だけでは解決しないことを SBT は理解していました。Dynamics 365 Field Service への拡張こそが、X 社の目標である「メンテナンスビジネスの収益拡大」につながるからです。そこで、早期に拡張プロジェクトを開始するために、SBT は STEP1 と並行して、フィールドサービスについてアセスメントを実施する分科会のご提案をしました。

STEP 図

フィールドサービスのアセスメントの実施は、具体的なシステム運用イメージを X 社に描いてもらうことも目的です。「システムを導入すればすべて解決する」ということはあり得ないことを SBT は過去の経験から充分に理解しています。「システム導入で解決します、実現します」だけではなく、課題解決に向けたロードマップを描き、「脱 属人化」の課題となっていた「標準的な仕事の流れを作る」ための重要な工程です。

サンドボックスを用いた認識合わせのご提案

STEP1 では製品の Fit&Gap を洗い出します。SBT は、STEP1 でサンドボックス環境を構築し、実際に X 社に触れてもらうことにより、製品理解の認識相違を避けるご提案をしました。STEP1 で X 社に製品理解を深めてもらい、運用のイメージを持ってもらうことで、X 社と SBT の認識のずれを軽減するための提案です。

STEP 図

段階的な横展開のご提案

「ケーススタディ・プロフィール」で書きましたが X 社は海外にいくつもの拠点を有するグローバル企業です。当然、1拠点に導入して終わりというわけではありません。SBT は X 社の要件から、一括で全拠点に導入してしまうリスクの大きさを懸念しました。そこで、まずは1拠点に導入し、運用をしてみることで、機能改善、追加要望を洗い出し、次の拠点に導入を行うことを提案しました。導入した後、改善をしていく計画です。

最終的に、SBT は X 社のシステム導入を次のように計画し、提案しました。

STEP 図

X 社の目標である「メンテナンスビジネスの収益拡大」につなげるためには、どのように導入プロジェクトを進めていくかを具体的に提案したことに評価をいただき、SBT の X 社 Dynamics 365 導入プロジェクト参画が決定しました。

SBT の挑戦

SBT のプロジェクト計画は、当初、X 社が描いていたものとは異なるものでした。しかし、プロジェクトを進めていく中で、このプロジェクト計画を提案したことの効果はいくつもありました。

フィールドサービスアセスメント

フィールドサービスついてアセスメントを実施したことで、SBT は X 社の業務理解を深めることができたため、システム稼働後の運用イメージを具体的に説明することができ、その結果どのような機能が必要か、本当にそれは必要なのか、を整理することができました。

また、STEP1 ですべてを並行して実施したことで、X 社からどのような情報の提供が必要かも明確になりプロジェクトの早期立ち上げを実現しました。

サンドボックスを用いた認識合わせ

システムの認識違いは後からのインパクトがとても大きいものとなります。最悪、目標達成にも、課題解決にもつながらず、システムを導入した影響の負担ばかりが増え、「どうしてこんなことに」となってしまうことも珍しくありません。そのようなことを回避するために実施したサンドボックスを用いた認識合わせは、X 社と SBT の相互認識を常に保つことができ、ギャップを埋めることに大きく貢献しました。製品仕様によるギャップの代替え案についても両社で折り合いをつけながら進めることができました。

段階的な導入

最初に導入先と決まったのは、海外拠点でした。X 社の旗振り役の方は、自身の拠点であることから強いリーダーシップを持ってプロジェクトに挑んでくれました。常に X 社と目線、歩幅を合わせることを意識した SBT のプロジェクト進行を高く評価され、プロジェクト中に発生する数々の問題、課題を SBT と共に立ち向かってくれました。

導入効果

X 社の本質的な課題を解決するためのプロジェクト進行を実施し、無事、海外拠点に導入することができました。

問合せ・対応履歴が顧客と紐づくことで、今まで取りこぼしてきたメンテナンス・サポート情報から営業活動へつなげることができた結果、受注確度10%アップと、Dynamics 365 を導入した結果が数字にも表れ、X 社の目標である「メンテナンスビジネスの収益拡大」に向けて、全社的な取り組みプロジェクトへ進んだのです。

導入効果

まとめ

業務の標準化、顧客情報・活動情報をメンテナンス部門・営業部門で共有することで、「メンテナンスビジネスの収益拡大」を実現したケーススタディをご紹介しました。今回、ポイントとなるのは次の4つです。

  • 将来の人材不足によるリスク予防に重きを置いた取り組みであったこと
  • チーム・組織による顧客対応 (顧客満足度の向上)
  • 多重業務の削減
  • 案件機会の創出

メンテナンス業務を起点とした顧客情報の収集は顧客アプローチの中で、より根拠や納得感をもたらすことができます。その結果、X 社では比較的確度の高い案件創出につながっております。また組織による顧客対応で分業を実現し、メンテナンス員の業務負荷も改善しております。システムの導入は今起きている課題を解決する取り組みでもあり、将来を見据えたリスクを回避するための取り組みでもあります。「今の業務が回っているから問題なし」ではなく X 社のように問題意識を持ち、課題解決するお客様の取り組みを SBT はご支援致します。

SBT では、ひとりでも多くのお客様の目標達成に向けて、お客様と共創する Dynamics 365 の導入を目指しています。お気軽にご相談ください。

関連ブログ記事

Dynamics 365 Sales とは?機能・利用シーンについて解説

関連ページ

Microsoft Dynamics 365 導入支援サービス

【総合】お問い合わせ

製品・サービスに関するお問い合わせはお気軽にご相談ください

ピックアップ

セミナー情報
クラウドエンジニアブログ
clouXion
メールマガジン登録