最近ServiceNowをワークフローツールとして導入する案件に関わることが多いのですが、製品の特性を理解しないまま導入を始めた結果、使いこなせず、十分な効果が出ないことが少なくないなと思ったので、その原因をシェアします。

↓要約
ServiceNowはワークフロー機能（Flow designer）をノーコードで作業の自動化のためのワークフローを作る機能だと言っており、日本企業にありがちな複雑な稟議・決済プロセスを実現するのには向いていません。そのため、ServiceNowの標準の範囲で実装できる程度に稟議・承認プロセスをシンプル化した上で、既存のシステムと連携したワークフローの自動化を本気でやる気がないのであれば、日本企業の求める複雑なワークフローを実現するための機能をはじめから備えた国産のワークフローツールを導入する/使い続けるほうが、結果としてROIもユーザの満足度も高くなることが多いと思います。

ServiceNowのワークフロー機能 Flow designerについて

まず、ServiceNowではワークフローの機能として、Flow designerという機能を提供しています。Flow designerでは、下図のようにレコード作成や承認、他システムとの連携を行う"アクション"と、分岐や繰り返しなどの"フローロジック"と呼ばれる2種類のパーツをGUI画面で配置していくことで、ノーコード・ローコードでワークフローを作成できる機能です。

なお、ServiceNowにはWorkflow editorというワークフロー機能もありますが、こちらはFlow desginerの前身機能という位置づけで、現在では機能拡張もされておらず、また公式のトレーニングでも扱われることがない過去の遺物です。しかしながら、Flow designerには存在しない「差戻」に近いRollback機能が存在するなど、日本企業が求める柔軟なフロー制御が実現しやすいことから未だに使われることがあります。しかし、旧機能ということでいつサポート終了になるかわかりませんし、Flow designerが（特に後述する自動化機能において）どんどん機能拡張され使いやすくなっているため、今後の利用は推奨しません。そのため、この記事でもFlow designerの利用を前提とします。

Flow designerは稟議・決済のための機能ではなく、自動化のための機能

ServiceNowの公式ドキュメントでは、Flow designerは次のように説明されています。

ここで重要なのは、ServiceNow社によるFlow designerの説明において、承認 （approval）という言葉が一切出てこないという点です。その代わりに、自動化（automate）やコード不要で（without having to code）という言葉が出てきます。つまり、ServiceNow社は、Flow designerをノーコードで作業の自動化のためのワークフローを作る機能だと言っているわけです。

しかし、「ワークフロー」と聞くと（海外がどうなのかはわかりませんが）日本では、「稟議・決済ワークフロー」つまり、稟議を回したり決裁（承認）のための機能である、と解釈されることが多いようです。そして、その考えのまま、ServiceNowをワークフローが得意らしい！ということで使い始めると、思った通りの効果を発揮できません。

差戻、引戻、回付、(柔軟な)代理承認機能などはデフォルトでは存在しない

日本企業がServiceNowのワークフロー機能（Flow designer）を稟議・決済ワークフロー機能として活用しようとしたときに問題になるのが、次のような機能が標準で存在していないことです。
・差戻　…　申請を却下・否認してやり直しさせるのではなく、申請者や下位承認者に戻して再検討を促す機能
・引戻　…　申請者や下位承認者が、一度進めたワークフローを自分に戻す機能
・回付/確認　…　承認をするわけではないが、"見たよ"という証跡を残す機能）

標準の機能を使う場合、申請の差戻や引戻を行いたい場合は、一度キャンセルして出し直すしかありません。また、回付などと言う機能はなく、承認で代用するか、メール通知を飛ばすだけ（この場合回付したという証跡を残すことができない）になります。

稟議・決済プロセスをシンプル化 & 外部システム連携やRPAを駆使した自動化を本気でやる気がないのであれば、国産のワークフローツールを使ったほうがよい場合が多い

まとめると、ServiceNow社はワークフロー機能（Flow designer）自動化のための機能を位置付けており、多くの日本企業が求める複雑な稟議・決済プロセスを実現するのには向いていません。

これを無理に実現しようとすると（とはいえそうしようとする場合がほとんどですが）、コーディングを伴うカスタマイズが必要になり、余計にコストがかかります。また、自動化ではなく稟議・決済機能をメインで使う場合、（少なくとも私の経験上は）ライセンス費用は割高になります。

そのため、ServiceNowをワークフローツールとして導入するのであれば、標準の範囲で実装できる程度に稟議・承認プロセスをシンプル化した上で、既存のシステムと連携したワークフローの自動化を本気でやる覚悟を持つべきです。

そうではなく、とりあえず紙業務を無くせたらよいとか、今使っているシステムがサポートが切れてしまうから、というきっかけでワークフローツールを検討しており、既存の複雑なプロセスに手を入れる気がない場合は、上述したような日本企業の求める複雑なワークフローを実現するための機能をはじめから備えた国産のワークフローツールを導入する/使い続けるほうが、結果としてROIもユーザの満足度も高くなることが多いと思います。

もちろんこれらを理解した上で、ワークフロー以外の様々な機能の活用も含めた総合的な判断としてServiceNowの導入を決め、ツールの一本化などを目的としてワークフロー機能についてはカスタマイズを行うという判断を行うのは問題ないのですが、そうでないことが多いのが現状です。

以上です。