多くのSalesforceユーザーが「パッケージに合わせて業務を変えられない」理由

　(これまでの記事はこちらをご覧ください。)

　「標準機能に寄せろ」 「パッケージに合わせて業務を変えろ」 「集合知であるベストプラクティスに業務を合わせろ、それをしないからダメなんだ」

　これらは何十年も前から耳慣れた正論です。しかし、これが聞こえてくるのは事情を知らない部外者の評論、ベンダーのポジショントーク、業務要件が肥大化し疲弊したプロジェクトメンバーがこぼす愚痴である、というのが現状でしょう。

　この問題を、我々は長い間克服できないままでいます。令和に入り、生成AIが生まれ、Agent時代に突入しても構造的な課題は残されたままです。

　新しいテクノロジーやサービスの革新性・メリットのみに焦点があたると、それらを取り入れるという経営判断のもと、現状を変えずに利用できるよう過度なDIYが行われる構造が生まれます。

　「テクノロジーを活用して成果を上げられる自社の業務構造そのもの」を考えていきたいと思います。

標準機能がベース、カスタムは補足という原則

　「標準かカスタムか」という問いは、ともすれば「内製か外注か」といった問いにも見えます。しかし、本質的には機能（How）にフォーカスされた議論により、価値や企画（Why-What）というセンターピンから、実態のプロジェクトがズレていく構造が問題です。標準機能を使うかカスタムするか、内製か外注かといった二元論はあくまでポジショントークです。結果として取りうる手段であり目的ではありません。

　Salesforceというサービスも、競合との機能比較表を作成すれば○がつく項目の多い、機能性に富んだプラットフォームです。しかし、その中でもSalesforceが想定する標準のプロセスモデル、設計思想、標準機能の活用方法というものがベースにあります。

　Salesforceが提供する拡張性は、あくまでもベースを活かす前提で、個社別の事業や商品や業務オペレーションにフィットさせるためのものになります。

　カスタム機能が少なければ良いという話でも、Salesforceの上でカスタマイズできるなら要求通りに作ってもいいという話でもありません。

　自社の業務があるべき新しい姿へ向かうにあたり、Salesforceが提供する型を活かすことで早く辿り着けるかどうか、これがそもそものパッケージ選定の根底になければいけません。（下図の1や2ではなく、3を目指すイメージ）

　Howに陥らずに成果にフォーカスしながらパッケージと向き合う上で、「プロセス」と「手順」を区別して捉えるというのも重要です。

　ISO9000:2015では、プロセスを「インプットを使用して意図した結果を生み出す，相互に関連する又は相互に作用する一連の活動」、手順を「活動又はプロセスを実行するために規定された方法」と表現しています。

　業務改善というと、現状の詳細な手順を業務フロー図にし、負荷のある担当者のシステム操作等を自動化・効率化するイメージがありますが、この場合は作業レベルの改善に留まります。

　たとえば見積書の作成が早くなれば売上が伸びるかというとそうではありません。間接的には、営業担当者の工数が下がり、商談に時間を割けるようになり、多くの商談数をこなせるようになり、受注件数はあがり……と繋がっていきます。しかし、理論上はそうでも、商談創出プロセスの改善が見込めなければ、営業担当者の工数を削減しても成果には直接寄与せず、あくまでも業績が伸びる可能性があるというレベルに留まるわけです。

　言ってしまえば当たり前の話ではありますが、商談創出のプロセスや、見込み客獲得のプロセスなど、価値が創出されるまでの繋がりをより良くすることこそが本質的には重要です。

　仮に、実現すべき「プロセス」を実務的に成立させるためであれば、手順レベルで現場要求に寄り添い機能のカスタムに応じるのは合理的です。ただし、プロセスの実現（成果）に対して影響力が低い現場レベルのペインについては、他の重要な要求よりも劣後することになります。

こうした判断と匙加減というのは、実際にはケースバイケースでの判断を必要とします。

そんな時、パッケージが想定するプロセスという全体感の設計や考え方、標準機能の使われ方、こうしたものを理解しているということが「パッケージに合わせる」ということの第一歩です。