DXを進めようとすると、目の前の問題にとらわれがちになる
会社の業務をDX（デジタルトランスフォーメーション）しようと考えたとき、多くの場合、最初に目を向けるのは現場で発生している困りごとです。
「見積書をExcelで作るのが面倒なので自動化したい」「紙の申込書をなくしたい」「請求書の発行に時間がかかっている」といった相談は、中小企業でもよくあるものです。
もちろん、こうした問題を一つずつ解決することにも意味があります。しかし、目の前の問題だけに着目してシステムを導入すると、思うように業務改善が進まないことがあります。
例えば、見積書を自動作成できるようになっても、その後の受注管理はExcel、納品管理は別のシステム、請求管理は経理担当者の手作業という状態では、会社全体の業務はあまり変わりません。それぞれの業務は便利になっても、システム間のデータの受け渡しが必要になり、かえって管理が複雑になることさえあります。
このような事態を避けるために、DXを考える際には「抽象化して考える」という視点を持つことをおすすめします。
抽象化とは、仕事を一段高いところから眺めること
抽象化という言葉は、少し難しく聞こえるかもしれません。西山圭太氏の著書『DXの思考法』でも、DXを実現するための重要な考え方として抽象化が取り上げられています。
抽象化とは、目の前にある個別具体的な物事から少し離れて、共通する構造や本質を見つけ出すことです。
例えば、飲食店の予約管理、イベントの参加申込管理、訪問サービスの予約管理は、それぞれ異なる業務に見えます。飲食店では席数を管理し、イベントでは定員を管理します。訪問サービスであれば、スタッフの空き時間や移動時間を考慮する必要があります。
ところが、抽象的に考えてみると、いずれも「顧客から希望を受け付け、提供できるかを判断し、予約を確定し、その結果を顧客に伝える」という共通した構造を持っています。
この共通構造を理解できれば、業種ごとにまったく異なるシステムを作るのではなく、予約受付や顧客管理といった共通の仕組みを利用し、それぞれの業種に固有の部分だけを調整すればよいと考えられます。つまり、抽象化によって、別々に見えていた仕事を共通の仕組みとしてとらえられるようになるのです。
受注から請求までを一つの仕事として考えてみる
ある中小の製造業を例に考えてみましょう。
営業担当者がお客様からメールで注文を受けると、受注内容をExcelに入力します。製造担当者はそれを確認して製造計画を立て、出荷担当者が納品書を作成し、最後に経理担当者が請求書を発行します。
この会社でDXを進めようとすると、営業担当者は受注情報の入力を自動化したいと考え、製造担当者は製造計画を管理するシステムを欲しがります。出荷担当者は納品書の自動作成を希望し、経理担当者は請求書の発行を効率化したいと考えるでしょう。
それぞれの要望に個別に対応すると、部門ごとに異なるシステムを導入することになるかもしれません。
しかし、ここで一度、抽象化して考えてみます。そもそも、この会社が行っているのは「顧客から注文を受け、その注文に対して製品を提供し、代金を回収する」という一連の仕事です。
営業、製造、出荷、経理という部門の区分はありますが、顧客から見れば、一つの注文に対する対応にすぎません。
そう考えると、本当に必要なのは部門ごとの独立したシステムではなく、一つの注文情報を関係者全員で共有し、その処理状況を管理できる仕組みなのではないでしょうか。
例えば、注文を受けた時点で登録した顧客情報や商品情報を、製造計画にも、納品書にも、請求書にも利用できるようにするのです。
個別のボトルネックから考えると、DXが行き詰まることがある
個別具体的な問題からDXを始めることには、もう一つの難しさがあります。それは、現場で発生している例外的な業務や特殊な事情が、システム導入の障害になってしまうことです。
例えば、受注管理システムを導入しようとしたところ、「特定の取引先だけ注文書の形式が異なる」「一部の商品だけ特殊な価格計算が必要」「例外的な納期調整が発生する」といった問題が見つかったとします。
すべての例外に対応できるシステムを最初から作ろうとすれば、開発費用も時間もかかります。市販のシステムでは対応できないという理由で、導入を断念することもあるでしょう。しかし、業務全体を抽象化して考えれば、別の進め方が見えてきます。
まず、すべての注文に共通する情報や処理を整理し、そこを共通の仕組みにします。そのうえで、一部の特殊な取引だけは例外として扱えばよいのです。すべてを一度に自動化しなくても、通常の取引の大部分を効率化できれば、会社全体として大きな改善になります。
もちろん、法令対応や品質管理などの理由で省略できない業務もあります。そうした事情を確認しながら、共通化できる部分と個別に対応すべき部分を切り分けることが重要です。
部署や業種の違いにとらわれず、共通する仕組みを探す
抽象化して考えることのもう一つの利点は、関係がないと思っていた業務の間にも、共通点を見つけられることです。
例えば、社員の有給休暇申請、備品の購入申請、経費の精算申請は、会社の中では異なる業務として扱われています。しかし、抽象化すると、いずれも「申請者が情報を提出し、承認権限のある人が確認し、承認結果を記録して通知する」という構造を持っています。
そうであれば、申請の種類ごとに別々のシステムを用意するのではなく、共通の申請・承認システムを利用するという考え方ができます。
これは社内業務に限りません。顧客管理、予約管理、在庫管理、問い合わせ管理なども、共通構造を探すことで、既存のクラウドサービスを活用できる可能性が広がります。自社の業務は特殊だから専用システムが必要だと最初から考えるのではなく、まずは他の会社や業種にも共通する仕事ではないかと考えてみることです。
全体像を考えることと、すべてを一度に実行することは違う
ここで注意したいのは、業務全体を抽象化して考えることと、会社のすべての業務を一度にDX化することは別だという点です。
特に中小企業では、予算や人員に限りがあります。最初から全社のシステムを入れ替えようとすると、費用が膨らみ、現場の負担も大きくなります。そのため、考えるときは全体をとらえ、実行するときは小さく始める、という進め方が現実的です。
例えば、受注から請求までの流れを整理したうえで、最初は顧客情報と受注情報の一元管理だけを始めます。運用が安定したら納品管理との連携を進め、次に請求書の発行を自動化するという方法が考えられます。
最初から全体の構造を考えていれば、後から機能を増やす際にも、どの情報を共有し、どのシステムと連携させればよいかを判断しやすくなります。逆に、各部門がバラバラにシステムを導入すると、後から連携させるために余計な費用が発生することがあります。
AIを導入するときにも抽象化して考えてみる
この考え方は、生成AIを使った業務改善にも当てはまります。
例えば、「問い合わせメールへの返信文をAIに作らせたい」という要望があったとします。確かにAIで返信文を作成すれば、文章を書く時間を短縮できるでしょう。しかし、問い合わせ対応という業務を抽象化すると、「問い合わせを受け付け、内容を理解し、必要な情報を調べ、回答を判断し、顧客に伝える」という一連の流れがあります。この中で、本当に時間がかかっているのは、返信文を書く作業ではなく、過去の問い合わせ履歴や社内資料から回答を探す作業かもしれません。あるいは、問い合わせが適切な担当者に届かず、社内で何度も転送されていることが問題なのかもしれません。
そうであれば、AIに返信文を書かせるよりも、問い合わせ内容を自動分類したり、必要な社内情報を検索しやすくしたりする方が、大きな改善につながる可能性があります。
AIで何を自動化するかを最初に決めるのではなく、業務全体の中で、どの処理をAIに任せると効果的なのかを考えることが重要です。
まとめ
中小企業がDXを進める際には、目の前の困りごとを一つずつ解決しようとするのではなく、まず業務全体を抽象化して考えることをおすすめします。
個々の業務には固有の事情がありますが、一段高いところから眺めてみると、共通する処理や仕組みが見つかることがあります。そうした共通構造をもとに業務を設計し直せば、個別の問題にとらわれることなく、会社全体としてDXを進める方向性を見つけやすくなります。また、全体を抽象化して考えたからといって、すべての業務を一度に変える必要はありません。目指す姿を明確にしたうえで、実行できるところから少しずつ改善を進めればよいのです。
DXを検討するときには、いきなりシステムやAIツールを探し始める前に、「そもそも自分たちの会社は、何のために、どのような仕事をしているのか」を一度考えてみてはいかがでしょうか。