物語で覚える｜デジタル経営実行計画プロセス

ある日、ITコーディネータは社長からこう言われました。

 

「DXを進めたい。しかし、何から始めればよいのか分からない」

 

ITコーディネータは静かにうなずきます。

 

こういう場面で、いきなり製品比較を始めることもできます。

便利そうなツールを並べることもできます。

 

でも、たいていそれではうまくいきません。

 

本当に必要なのは、

経営の意図を、現場で動く計画に変えていくことです。

• 戦略を、業務につなぐ。
• 業務を、ITにつなぐ。
• そして、その結果を、評価につなぐ。

デジタル経営実行計画プロセスは、そのための流れなのだと思います。

 

ITコーディネータはまず、社長の言葉をそのまま受け取ることをしませんでした。

 

「DXを進めたい」という言葉の中に、何が含まれているのか。

• 売上を伸ばしたいのか。
• 業務を効率化したいのか。
• 顧客対応を変えたいのか。
• あるいは、将来の競争環境の変化に備えたいのか。

ここが曖昧なままだと、計画はすぐに現場都合へ流れていきます。

 

戦略目標は、そのままでは大きすぎます。

実行可能な単位に分解し、何を調査し、何を分析し、どんな制約条件の中で進めるのかを定めていく。

その作業が、最初の土台になります。

 

実行計画は、戦略と切り離された作業表ではありません。

戦略を動かすための設計図です。

 

次に、ITコーディネータは現場に入っていきました。

 

受注、見積、在庫、請求、顧客対応。

日々の仕事の流れを一つずつ見ていくと、いろいろな声が出てきます。

 

「入力が二度手間になっている」

「このシステムは使いにくい」

「担当者ごとにやり方が違う」

 

こうした声は大事です。

ただ、そのまま並べても、まだ課題とは言い切れません。

• 業務の問題なのか。
• システムの問題なのか。
• 役割分担や運用ルールの問題なのか。

そこを分けて見ないと、整理したつもりで混乱が残ります。

 

それともう一つ。

現状業務を丁寧に見るほど、今のやり方に引っ張られやすくなります。

でも考えたいのは、今の業務の延長ではなく、戦略を実現するためにどんな業務へ変わるべきかです。

 

現場を見たあとで、ようやくITの話が出てきます。

 

ここでよく起きるのが、製品比較の話が急に主役になることです。

• AIが流行っている。
• クラウドが便利そうだ。
• 他社が導入している。

 

たしかに気になります。

でも、その順番で考えると、だいたい話がぶれます。

 

まず確認したいのは、必要なデータがどこにあるかです。

• そのデータは使える状態なのか。
• 品質はどうか。
• 継続的に活用できるのか。

 

PoCも同じです。

• とりあえず試す、では足りません。
• 何を検証するのか。
• どの観点で評価するのか。

その設計がないと、試したこと自体が目的になってしまいます。

 

ITを調べることは、道具を探すことではなく、戦略実現の条件を見極めることなのだと思います。

 

調査が進むと、実現案がいくつか見えてきます。

• 営業から先に着手する案。
• 業務基盤を先に整える案。
• 一部業務に絞って段階導入する案。

ここで大事なのは、ひとつの案に早く飛びつかないことです。

• 実行しやすい。
• 費用が安い。
• 社内の抵抗が少ない。

そういう理由はもちろん大切です。

 

けれど、それだけで決めると、計画は小さくまとまりすぎます。

• その案は、経営目標にどのくらい近づくのか。
• 顧客価値をどう高めるのか。
• 投資に対してどんな成果が見込めるのか。

戦略実現案というのは、単なる改善案ではなく、経営の意図を現実の選択肢にしたものです。

比較して初めて、優先順位にも意味が出てきます。

 

方向性が見えてくると、今度は具体化です。

 

ここでありがちなのは、現行業務にそのままシステムを当てはめようとすることです。

でも、それでは変革にはなりません。

• どの業務を変えるのか。
• 誰が何を担うのか。
• どこを標準化するのか。
• どこに人の判断を残すのか。

先に考えるべきなのは、新しい業務プロセスです。

そして、その業務を支えるために、どんなIT導入方針が必要かを決める。

 

この順番が崩れると、業務とITが分断されます。

 

さらに、組織、役割、運用体制まで見ておかないと、導入後に誰も責任を持てない仕組みになります。

IT導入方針は、システムの話だけでは終わりません。

 

計画が形になると、そろそろKPIの話が出てきます。

 

でも、このあたりで少し違和感を覚えることがあります。

指標が、最後に慌てて付け足されたように見えることがあるからです。

• 処理時間の短縮。
• 入力ミスの削減。
• 売上成長率。
• 顧客満足度。

指標そのものは、それらしく見えます。

ただ、それが何を検証するための指標なのかが曖昧だと、あとで使えません。

• 業務改善の指標と経営成果の指標はつながっているか。
• 顧客価値の変化を見られるか。
• いつ測り、どの水準なら前進と判断するのか。

評価指標は、最後に埋める欄ではなく、計画全体の意味を支えるものです。

ここが弱いと、導入後に「結局、何がよくなったのか」が分からなくなります。

 

調達という言葉を使うと、ベンダー選定の話だけに見えやすいです。

でも、実際にはもう少し広い話です。

• 必要なシステム。
• 必要なデータ。
• 必要な人材。
• 外部に頼る範囲。
• 自社で担う範囲。
• 予算とスケジュール。

それらをどう確保するかを考えるのが、IT資源調達計画です。

• ここでも、前のタスクとのつながりが大切です。
• 業務改革の内容と結びついているか。
• 評価指標を実現するための要件になっているか。

そこが曖昧だと、価格や知名度で選ぶだけの調達になってしまいます。

調達は、実行計画を現実に近づけるための準備です。

 

ここまで来ると、いよいよ実行計画らしくなってきます。

 

ただ、この段階で計画が「システム導入計画だけ」になってしまうことがあります。

それは少し惜しい。

 

本来ここでまとめるのは、業務改革も含めた実行の道筋です。

• どの範囲を対象にするのか。
• どんな体制で進めるのか。
• どの順番で導入するのか。
• 教育や定着化をどう進めるのか。
• 評価をどこで確認するのか。

スコープ、体制、スケジュール、予算。

この整合が取れていないと、計画は動きません。

 

そして、この計画は次の開発・導入の現場に渡されます。

だからこそ、単に方針を並べるだけでは足りず、次工程が迷わず動ける粒度で整理する必要があります。

 

調達が行われ、開発が進み、導入され、現場で使われ始める。

すると、計画を立てていたときには見えなかったことが、少しずつ見えてきます。

• 想定どおりに進んだこと。
• 現場で使いにくかったこと。
• 不足していた施策。
• 顧客が本当に求めていた価値とのズレ。

ここで行う評価は、「実施したかどうか」の確認ではありません。

• この実行計画で、顧客価値は実現できたのか。
• 経営課題の解決に近づいたのか。
• 不足していた内容は何か。
• 改訂すべき計画はどこか。

必要なら、追加調査や追加分析を行い、再計画へ移ります。

でも、見直すべきものは実行計画だけとは限りません。

 

実行した結果として、顧客が求める価値そのものの理解が変わることがあります。

競争上のポジショニングの見直しが必要になることもあります。

つまり、デジタル経営実行計画プロセスの中で直せば済む話と、デジタル経営戦略プロセスの戦略側へ戻さなければいけない話を区別する必要があるわけです。

 

その意味で、実行計画評価は終点ではありません。

現場で起きた事実をもとに、実行計画の見直しが必要な内容を特定し、必要に応じて再計画へつなぎ、さらに戦略プロセスへフィードバックする。

その役割を持った、大事な節目だと思います。

 

こうして見ていくと、デジタル経営実行計画でのつまずきは、案外似たところに集まっています。

• 戦略と実行計画がつながらない。
• 業務改革とIT導入が分断される。
• 評価指標が後付けになる。

結局、難しいのは個々のタスクそのものより、タスクとタスクの間なのかもしれません。

 

戦略から始まり、

業務へ落とし込み、

ITで支え、

評価で確かめ、

必要ならまた見直す。

 

戦略 → 業務 → IT → 評価

 

この一本の線を保てるかどうか。

そこに、デジタル経営実行計画プロセスの要点があるように思います。

 

 

・・・ 

 

社長は、少し考えたあとで言いました。

 

「なるほど。

　何を入れるか、ではなくて、何を実現するかから考えるんですね」

 

ITコーディネータは静かにうなずきます。

 

DXの話は、どうしても道具の話に寄りやすいものです。

でも、実行計画の本質は、そこにはありません。

 

経営の意図を、現場で動く形にすること。

現場で起きたことを、次の計画や戦略に戻していくこと。

 

その往復が、少しずつ会社を変えていくのだと思います。