機能一覧で差がつかないのは、どの製品も同じ機能名を掲げているからです。差が出るのは、その機能が現場の困りごとを実際に解消できるかどうかです。軸ごとに、確認すべき質問と、満たさなかった場合に起きることを示します。
軸1 申請がどこで止まっているかが見えるか
紙やメールの回覧で起きる最大の損失は、承認そのものにかかる時間ではありません。「あの申請、いまどこですか」と聞いて回る時間と、聞かれた側が探す時間です。前述の製造業(建設機械)でも、回覧がどこで止まっているのかわからない状態が、検討を始めるきっかけになりました。
確認すべきは、承認者ごとの滞留一覧を標準機能で表示できるかどうかです。加えて、滞留した申請に自動で督促が送られるか、その宛先を承認者本人に設定できるかも確認します。この点が弱い製品では、電子化しても催促の電話だけが残ります。
同社では、社内規定が社長席の後ろに紙のまま置かれていて確認しづらい、という課題も挙がりました。申請の可視化と、判断基準となる文書の参照しやすさは表裏一体です。この軸を確認すれば、電子化後も催促作業が残る製品を候補から外せます。
軸2 課金体系が自社の使い方と合っているか
課金体系は、機能よりも導入の可否を左右します。正社員約520名の食品製造業では、有給申請のワークフローに既存のデータベース製品を使っていました。ユーザー数無制限の契約で月額10万円を支払っていますが、使い勝手が悪く社内では不満でています。その状態で、費用だけが固定費として残っている状態です。
対照的なのが従業員約70名の食品製造業です。「全社員にワークフローを使わせたいが、システムに費用を掛けられない」という条件から検討が始まりました。この企業では、個別の機能よりも費用を抑えられるかどうかが優先されています。ユーザー数課金の製品では、全社員を対象にした時点で予算を超えてしまいます。
確認すべき点は3つです。1つ目は、課金の単位がユーザー数か、業務量か、環境単位かという点です。2つ目は、申請フォームや承認ルートを追加したときに費用が増えるかどうかです。3つ目は、年に数回しか申請しない社員にも同じ料金が発生するかどうかです。この軸を通せば、稟議の段階で否決される製品を先に外すことができます。
軸3 既存のグループウェアで足りなかった点が埋まるか
すでにグループウェアを使っている企業では、付属のワークフロー機能で足りるかどうかが最初の分岐点になります。前述の商社は付属機能の利用も検討しましたが、機能不足と判断しました。同社の基幹システムはAS/400で、紙伝票の内容を人手で入力する作業が常態化しています。
そのため社内からは、AS/400と連携できなければ入力作業がそのまま残る、という指摘が出ました。連携できないツールでは導入する意味がないという判断です。ここが、付属機能と専用システムを分ける境界線になります。連携の可否は、CSVの取り込みと書き出しだけでなく、Web APIで双方向にデータをやり取りできるかまで確認しましょう。二重入力を残さない考え方は「ノーコードで始めるAPIデータ連携入門:開発不要の範囲と失敗しない進め方」で整理しています。
比較の観点を表にまとめます。
| 比較軸 |
確認する質問 |
満たさない場合に起きること |
| 止まり位置の可視化 |
承認者別の滞留一覧と自動督促が標準機能か |
電子化後も催促の連絡が残る |
| 課金体系 |
ユーザー数課金か業務量課金か、追加時に増えるか |
全社展開の段階で費用が上限を超える |
| 既存機能との差分 |
条件分岐と外部システム連携がどこまで可能か |
手入力作業が残り効果が出ない |
この3行を自社の言葉で埋められれば、比較表の残りの列は読まなくても判断できます。