• 川野辺
• PMOコンサルティング事業部　シニアマネージャー

「DXの現場」では、ノムラシステムコーポレーションの現役コンサルタントが、SAPの導入をはじめ、DXに20年以上携わった経験から、DXで重要となるポイントについて紹介します。

今回のテーマは「担当者から始めるDX」です。

DX推進のご担当者様より「何から始めたら良いかわからない」「導入までのイメージが湧かない」という相談をよくいただきます。

SAPなどの基幹システム導入プロジェクトは、専門コンサルタントと共に進めるのが一般的です。

そこで本記事では、自社で事業部単位の業務効率化DXを検討されている方に絞って、私たちが相談後に実施している実際のプロセスを5つのステップに分けてご紹介します。

Step1.  「現場へのヒアリング」で問題を把握

ご相談をいただいた後、ご担当者様よりお話を伺いつつ、現場の方にも業務課題をヒアリングします。ヒアリングの目的は、現場の業務プロセスを把握し、具体的な問題を洗い出すことです。

ご相談をいただいた時点でDXの方向性が明確な場合でもヒアリングからスタートし、各業務担当ごとに1人～ 5人にお話を伺います。

ヒアリングによって、既存の業務プロセスの問題がさらに明確になります。
一般的によくある問題は、以下の通りです。

システムが入っていない場合

• 手作業が多い
• ミスがなくならない

システムが入っている場合

• 使い勝手が悪い
• システムが業務プロセスの一部しか入っていない
• システムを上手く扱えない、または一部の人しか扱えていない

このように、ヒアリングで問題を洗い出してから、目指すべきプロジェクトの方向性をあらためて決定します。

DXを導入する業務「以外」の担当者へのヒアリングが効率化へのさらなるヒントに

一般的にヒアリングは、業務プロセス上でシステムを使われる方に実施されると思いますが、私たちはシステムを使わない方にもあえてヒアリングしています。

システムを使わない方とは、例えば製造業であれば、システム入力を行っていない外観検査に従事している方や、データ分析をしない工場生産ラインの方といった、システム導入とは直接関係のない方が該当します。

現場ヒアリングで、あえて新システムの使用予定のない方に参加していただくことには、以下のメリットがあります。

• 改善余地の発見
• 工程全体への理解促進

それぞれについて詳しく説明します。

改善余地の発見

ヒアリングを通じて、当初DXを計画していなかった業務からでも効率化のヒントが見つかることがあります。

例えばある製造現場では、形状の複雑な製品の外観検査を「熟練作業員の目視確認でしかできない」と考えていました。しかし、最新のAI画像認識カメラでは、熟練作業員ほどではないが微細なキズや歪みを一定の基準で自動検出ができそうでした。

さらに検査データを自動でデータベースに記録することで、不良傾向の分析や予防保全にも利用できる可能性もあります。

このように、システムを使わない予定だった領域の方にも話を聞くことで、改善の幅が広まることがあるのです。

工程全体への理解促進

DXに限らず、異なる業務間でのデータの流れや活用方法は見えづらいです。日々の業務もあるなか、自分が扱うデータが他の業務でどのように活用されているのかまで把握することは容易ではありません。

ヒアリング時は他の方が話している業務内容や全体像についての話も聞けるため、後続の工程でどのようにデータが用いられているかを把握するきっかけになります。

後続の工程を知ることで、業務の改善点が明確になることもあります。

このように、想定している領域外でもヒアリングをすることで、これまで見えなかった範囲までDXを拡大できるのです。

ヒアリングの実施によりDXの機運が高まることも

ヒアリングを実施することで、想定外の改善余地の発見だけでなく、社内のDXへの機運も高まった例があります。

ヒアリング実施後、社内でDXを推進していることが話題となり、これまでは連絡がなかった方々からも「こういうことできないですか？」という要望が寄せられるようになりました。

ヒアリング実施時には、「今は忙しくて…」と参加をためらわれる方もいらっしゃいますが、ヒアリング後には「参加して良かった」「思わぬ発見があった」と言ってもらえることも多いですね。

Step2. 方針を決める

次のステップではヒアリングで整理した課題を基に、DXの方針を決めていきます。

DXには様々な選択肢があります。

一般的にDXというと、基幹システムの刷新を想像されるかもしれません。その場合、導入までに2〜3年、金額としても約10億円と、多大な時間とコストがかかります。

プロジェクトにも寄りますが、短期で効果を出したい場合は、短期間で実施可能な小規模プロジェクトから着手し、少しずつ社内にDXを浸透させていく手法をご提案しています。

例えば営業支援ツールやスキル管理ツールの導入であれば、半年程度で導入が可能です。

RPAを用いたExcelデータの転記作業の自動化など、比較的小規模な改善でも、業務効率化の効果を実感しやすく、社内でのDXに対する理解も深まりやすいのです。

このステップでは上記も踏まえた上で、どのような方針でDXを実施するのか、を明確にします。さらに経営陣に対し、試算した効果を基に施策を提案していきます。

Step3. 業務プロセスの問題を浮き彫りにする「As-Is業務フロー」

プロジェクトの方向性が決まれば、次は現状の業務や手順を視覚化するために「As-Is（アズイズ）業務フロー」を作成します。

As-Is業務フローとは、現状の業務プロセスをフローチャートに落とし込んだものです。

現状の業務プロセスを図に表し、各工程の所要時間や使用ツールなど、詳細な部分まで記載することで、業務プロセスやシステムが持つ問題点をはじめ、現場の実態を把握できるため、DX導入に際しては欠かせないステップになります。

具体的なAs-Is業務フローの作成手順について次に解説します。

As-Is業務フローの作成方法

As-Is業務フローの作成は、以下の手順に沿って進めます。

1. フローチャート作成
2. 問題点の特定

1. フローチャート作成

これまでに現場へヒアリングした内容を元に、今度は全体の業務フローを整理するためのフローチャートを作成します。

フローチャート作成時は、各業務の作業内容や情報の流れなど、詳細な点まで書き起こすことが重要です。

例えば、Excelを使用する業務の場合、以下のような情報を書き込みます。

• どのようなExcelファイルを使用しているのか
• インプットデータはどのようなデータか
• アウトプットデータはどのようなデータか
• 実務担当者は誰か
• どのくらい時間がかかるのか

インプットデータからアウトプットデータ、使用ツールといった細かな情報まで記載するイメージです。

このように細かく記載することで、効果測定が容易になるだけでなく、導入するツールが必要な機能を満たすのかも判断しやすくなります。

2. 問題の特定

フローチャートが完成したら、最後に問題を特定します。

業務プロセスの中で、時間やコスト、エラーが発生しやすいといった業務の流れを妨げるボトルネックや重複している工程がないかなど、フローチャートを基に分析します。

As-Is業務フローで問題を明確化した後に実施するのは、解決策を検討するための新たな業務フロー「To-Be（トゥービー）業務フロー」の設計です。

Step4. To-Be業務フローで解決策を決定

As-Is業務フローで現状の問題と課題を洗い出した後は、「To-Be業務フロー」を作成し、解決策を検討します。

To-Be業務フローとは、DX導入後に目指すべき業務フローの状態のことです。

To-Be業務フローを作成するメリットは、主に3つあります。

• 問題を解決するための明確な目標設定が可能になる
• DX導入後の業務を具体的にイメージできる
• 業務時間がどれぐらい短縮できるかを把握できる

例えば「紙を使用している」ケースでAs-Is / To-Beを考えてみます。

• As-Is：手書きの帳票をシステムに手入力している
• 問題：同じ内容を紙とシステムに入力している
• To-Be：タブレットで直接入力できるツールを導入

このように業務の重複を省くことで、作業時間の短縮と入力ミスの削減が期待できます。

実際のシステムはここまでシンプルではありませんが、このように洗い出した問題をもとに解決策を検討します。

As-Is / To-Beを明確にすることによって、RPAなどでの自動化で解決するのか、それともツール導入によって解決するのかなど、初めて手段が検討できる段階になるのです。

Step5. 機能要件とツール選定

To-Be業務フロー作成後、新システムに求める機能要件を整理し、その要件にマッチする手法を選定していきます。

先ほどの例でいえば「問題：手書きの帳票をシステムに手入力していること」に対して、「解決策：タブレットで入力可能な帳票ツールの導入」である場合、この機能にマッチするツールを取り扱っているベンダーに問い合わせ、要件定義を進める形です。

その後はツール候補の中から、以下の流れで各フェーズを進めていきます。

1. 導入するツールの選定
2. 導入計画の立案
3. 開発
4. テスト
5. 導入

導入期間は手段によってまちまちで、営業ツールやスキル管理ツールなどであれば約半年。小規模なRPAだと1ヶ月程度で実装できることもあります。

なお、もし機能要件にマッチするツールがなければ、システムをゼロから作り出す「スクラッチ開発」でも対応は可能です。ただ、開発コストやメンテナンスコストが高額となるため、お客様にとってのデメリットも決して少なくありません。

そのため、最終手段として採用するケースが多く、あえて未導入という形を提案させていただくこともあります。

なお機能要件を基にベンダーに対し情報提供依頼（RFI）や提案依頼（RFP）を作成する必要があるのですが、作成は少し難しいため、そこは専門家に頼っていただけたらと思います。

まとめ：小さな困りごとの解決にもDX

DXというと大規模なシステム刷新をイメージされがちですが、実際には現場の小さな困りごとを解決することから始められます。

重要なのは、現場の声に耳を傾け、業務の実態を丁寧に把握すること。そして、どのような形に改善するのかを明確にしてから手段を定めることです。