すべてのプロセスが別々のツールに散らばっているとき
販売はあるプラットフォームで。研修は別のプラットフォームで。レポートはスプレッドシートで。コミュニケーションはさまざまなチャネルで。管理情報はさらに別のシステムで。
個別に見れば、それぞれのツールはきちんと役割を果たしているのかもしれません。ある時点の、ごく具体的なニーズを解決するために導入されたものかもしれません。
課題が表れるのは、その後です。
企業が成長すると、プロセスは単独では動かなくなります。情報は部門から部門へと流れはじめ、ある業務は前の業務に依存し、複数のチームが同じデータを参照して意思決定をする必要が出てきます。
その段階で本当の課題になるのは、もはやツールが足りているかどうかではありません。
それらすべてを、つながった業務の一部にできるかどうかです。
1つのニーズを解決しても、プロセス全体が解決するとは限らない
プラットフォームは、設計された目的に対しては完璧に機能することがあります。
問題が起きるのは、プロセスがその外側へと続くときです。
販売記録は管理部門に届かなければなりません。あるプラットフォームで行った変更は、別のプラットフォームにも反映される必要があります。レポートは複数のシステムに保存された情報に依存しています。あるチームは、別の部門が管理するデータを参照しなければなりません。
そして、ある地点から次の地点までの間に、余計な作業が生まれはじめます。
情報のエクスポート、ファイルの更新、データのコピー、記録の検証、整合性の確認、あるいは変更が正しく行われたかを手作業で確かめること。
どれも、単独ではそれほど複雑な作業には見えません。
しかし、毎日繰り返されるプロセスの一部になると、業務のかなりの部分を占めるようになります。
見えない作業も、業務の一部である
2つのシステムが互いに連携していないとき、たいていは誰かがその作業を代わりに担うことになります。
あるプラットフォームから別のプラットフォームへ情報を移す担当者かもしれません。レポートを取りまとめるチームかもしれません。橋渡し役になっているスプレッドシート、更新を確認するためのメール、あるいはすべてが一致しているかを確かめるためだけに存在する一連の社内チェックかもしれません。
こうした作業は、プロセス図には表れないことがよくあります。
それでも時間がかかり、注意を必要とし、情報量が増えるにつれて膨らんでいきます。
業務は回り続けますが、もともと別々に動くよう設計されたツールをつなぐために、小さな手作業にますます頼るようになっていきます。
情報が分散すると、一貫性が失われることがある
同じデータが複数の場所に存在するときにも、別の影響が表れます。
営業部門にはあるバージョンがあり、管理部門には別のバージョンがあり、サポート部門には3つ目のバージョンがある。さらに、追跡用のスプレッドシートに4つ目があることさえあります。
情報がめったに変わらないうちは、その違いに気づかないこともあります。
しかし、更新が頻繁になると、重要な疑問が浮かびます。
どのバージョンが正しいのか？
問題は、必ずしも人や仕事の質にあるわけではありません。
多くの場合、原因はアーキテクチャにあります。
同じデータを複数のプラットフォームで手作業で更新しなければならないなら、一貫性を保つのは難しくなります。そして関わるシステムが多いほど、確認すべきポイントも増えていきます。
分断は、チームの体験にも影響する
企業のデジタル体験は、顧客のためだけに存在するものではありません。
社内にも存在します。
日々業務の中で働く人にとって、ツールを絶えず切り替えることは、当たり前のことに感じられるようになっていきます。
情報を調べるためにあるプラットフォームを開き、詳細を確かめるために別のプラットフォームを開き、最初のプラットフォームに戻って記録を更新し、さらに別のチャネルで変更を伝える。
1回の切り替えにかかるのは、ほんの数分かもしれません。
影響が表れるのは、その同じ流れが数十のプロセス、人、勤務日にわたって積み重なったときです。
だからこそ、デジタル業務の改善は、必ずしも新機能の追加を意味しません。
本来必要なかったはずの手順をなくすことを意味する場合もあるのです。
統合とは、必ずしも単一のプラットフォームを使うことではない
業務全体を1つのシステムにまとめることが便利な場合もありますが、整理されたテクノロジーエコシステムを構築する方法はそれだけではありません。
多くの企業には、専門的なソリューションが必要です。
違いを生むのは、それらのソリューションがどのように連携するかです。
異なるツールで構成されたインフラでも、明確な接続、情報をどこに置くかのルール、そして情報を共有するための定められたプロセスがあれば、効率的に機能します。
ですから、企業がいくつのプラットフォームを使っているかを問うだけでなく、次の点も考えてみると役に立ちます。
作業を重複させることなく、情報をプラットフォーム間で移動できるか？
どのシステムが主たる記録を保持しているかは明確か？
各チームは一貫した情報を参照しているか？
同じデータを再入力することなく、ある操作を次のプロセスへつなげられるか？
ツールの数だけで複雑さが決まるわけではありません。
複雑さを生むのは、ツール同士の接続の欠如です。
新しいツールは、エコシステム全体を変える
新たなニーズが生じると、それに対応できるプラットフォームを探すのが自然な反応です。
しかし、機能だけを評価していると、判断の重要な部分を見落とすことがあります。
導入した後に何が起きるのかも問う必要があります。
どのような情報を受け取る必要があるのか？
どのようなデータを生み出すのか？
誰がそれを参照する必要があるのか？
どのシステムと連携する必要があるのか？
新たな手作業を生み出さないか？
既存のプロセスを置き換えるのか、それとも業務フローにもう1つのポイントを加えるだけなのか？
問いは、もはや次のものだけではなくなります。
「このツールは必要なことができるか？」
そして、次のように変わっていきます。
「すでにあるすべてのものと、どのように連携するのか？」
この違いが、テクノロジーの評価の仕方を根本から変えます。
テクノロジーにもアーキテクチャが必要
企業のデジタル化とは、プラットフォームを積み重ねることではありません。
システム、情報、プロセスが連携して機能できる構造を築くことです。
それは既存のツールを統合することを意味する場合もあります。また別のケースでは、接続を自動化したり、プロセスを再編したり、業務の重要な部分を一元化できるソリューションを開発したりすることを意味します。
優れたツールを持っていても、企業が分断された状態で業務を行っていることはあり得ます。
テクノロジーがより大きな価値を生むのは、独立したソリューションの寄せ集めとして機能するのをやめ、エコシステムとして振る舞いはじめたときです。
ツールをもう1つ追加する前に問うべきは、何が足りないかではないのかもしれません。
何をもっとうまくつなぐ必要があるか、なのかもしれません。
Disruptive Studioでは、個々の機能だけでなく、それが業務全体とどのように連携する必要があるかまで見据えてテクノロジーを構築しています。
あなたの会社のデジタルエコシステムはつながっていますか？それとも、単に多くのツールで構成されているだけでしょうか？
