ワークフローシステムの見積もりを依頼すると、最初に聞かれるのが利用人数です。ところが、稟議に触れているのは1,500名だが、グループ全体では5,000名になる、というように、同じ会社から出せる数字が2つあることがあります。どちらで出すかによって、年額の見当も、社内で通す予算の組み立て方も変わります。
この2択を決めるための材料は、依頼する側の手元にもまだありません。ワークフローシステムに関わる人は、申請する人と承認する人だけではないうえ、誰を数えるかは承認経路の組み方が決まって初めて確定するためです。そして見積もりを求められるのは、たいてい経路を設計するより前です。
本記事では、利用人数を4つの層に分けて整理します。RFPに書く数字を決めるときのたたき台として使ってください。
出せません。見積もりがぶれる原因は単価ではなく、掛け算のもう一方にある人数が決まっていないことにあります。
利用人数を調べると、1ユーザーあたり月額いくらという相場の情報がすぐに見つかります。クラウド型なら数百円から千円台という幅で紹介されていることが多く、目安としては妥当です。しかし掛け算の左側にあたる人数のほうは、どの情報源でも決まったものとして扱われています。
例として、大阪支店から上がってきた複合機3台の入れ替え稟議を考えます。金額は240万円、経路は支店長・管理部長・経理部長の3段です。この1件に関わる人を数えていくと、途中で手が止まります。
起票した支店の総務担当が1人、承認者が3人。ここまでは迷いません。しかし決裁のあと、この稟議を見るのは誰でしょうか。支払処理をする経理の担当者、翌年度に同じ機器の更新を検討する後任者、監査対応で証跡を確認する内部監査室。
申請も承認もしないのに、この稟議に触れる人がいます。数え漏らしはここから始まります。
利用人数とは、システムにユーザーとして登録される人の数です。稟議を上げる人の数ではありません。この2つがずれるところに、見積もりのぶれが集まっています。
登録が必要になる理由は、4つに分かれます。
層 | 誰が入るか | 数えるときの難所 |
|---|---|---|
第1層 申請する人 | 自分で起票する人 | 載せる業務を足すたびに増える |
第2層 承認する人 | 経路に登場する管理職と管理部門 | 第1層と重なるため二重に数えやすい |
第3層 見る人 | 経理、内部監査、後任者、部門の照会担当 | 申請も承認もしないため最後まで話題に出ない |
第4層 マスタに載る人 | 経路の計算や集計のために組織図上に必要な人 | 本人はログインしないのに登録が要ることがある |
第1層と第2層だけなら、人数の見当はつきます。稟議を回している部署の人数を足せば済むためです。冒頭に挙げた1,500名と5,000名の差は、第3層と第4層が理由の一部です。ただし「グループ全体」という言い方には、今使っている部署の外側(他の支店・グループ会社)まで対象を広げるかどうかという、層とは別の論点も混ざっています。層の数え方を直しても、対象範囲そのものが広がれば人数はさらに動きます。
どちらも「使う人」として意識されないまま検討が進むためです。第3層は申請も承認もせず、第4層は画面すら開きません。要件定義の場に出てくるのは、申請する人と承認する人の話ばかりになります。
第3層は、決裁が終わったあとに登場します。複合機の稟議でいえば、支払処理をする経理の担当者から先の人たちです。この層は、要件を聞き取る場にそもそも呼ばれません。見るだけなので特に要望はない、という位置づけで検討の外に置かれます。
見るだけの人が何人いるかは、閲覧権限の設計を詰める段階になって初めて数え始めることになります。閲覧の範囲をどう決めるかは、それ自体が長い議論になりがちです。
第4層は、さらに後ろで出てきます。構築が始まってからです。承認者を役職から計算する経路にする場合を考えます。「大阪支店の支店長」という指定で経路を組むなら、その支店長が誰なのかをシステムが知っている必要があります。組織と役職とユーザーの結びつきをマスタとして持たないと、計算が成り立ちません。
この結びつきは、経路に登場する部署だけでは閉じません。申請が上がりうる部署の分だけ必要になります。
必要なユーザー数は、載せる業務の範囲だけでなく、承認経路の組み方によって決まります。
まず稟議を回している部署の人数で小さく始め、対象業務を広げるときに追加すればよい。この進め方は自然に見えますし、実際そのとおりに進む企業もあります。しかし役職で経路を計算する方式を選んだ場合、その役職者が所属する組織ごとマスタが必要になり、当初出していた人数では収まらなくなることがあります。
経路の組み方は、大きく2つに分かれます。どちらが優れているという話ではなく、引き受けるものが違います。
経路の組み方 | 第4層の扱い | 引き受けること |
|---|---|---|
承認者を氏名で個別に指定する | 経路に名前が出る人だけ登録すれば足りる | 異動や退職のたびに経路を手で直す作業が残る |
役職や組織階層から計算する | 申請が上がりうる範囲の組織とユーザーが要る | 登録するユーザーが増え、課金対象かどうかの確認が必要になる |
氏名で指定する形は、登録するユーザーを少なく抑えられます。そのかわり、人が動くたびに経路のメンテナンスが発生します。この負荷の積み上がり方は、承認経路のメンテが終わらない理由で別途整理しています。
役職から計算する形は逆です。経路のメンテナンスは軽くなる一方で、マスタに載せるユーザーは増えます。
どちらを選ぶかは、見積もりの前ではなく設計の入口で決まる話です。それにもかかわらず、人数を出すよう求められる順番のほうが先に来ます。ここが噛み合っていません。
見積もりを急ぐ場面では、経路の方針を仮に置いたうえで、その前提を見積書に併記しておくことが有効です。前提が変われば人数が変わることを、依頼する側と受ける側の両方が把握できる形にしておきます。
多めに出せば安全とは限りません。単価の階段と、社内の予算の通し方の両方に影響するためです。
契約するライセンス数が増えるほど1人あたりの単価が下がる価格体系を採る製品があります。この場合、少なく契約すると、あとから追加したときに単価が想定より高いままになることがあります。
一方で、実際に使う人数より大きく多い数で稟議を通そうとすると、金額の根拠を説明しづらくなります。使われないライセンスの費用をどの部門が負担するのか、という話にもなります。
どちらに寄せるかは企業によって分かれ、一律の正解はありません。判断の材料として、次の5点を確認しておくと迷いが減ります。
4番目と5番目は、第4層に直接効いてきます。カタログに書かれていないことも多いため、選定の場で聞く項目に入れておく価値があります。
対象業務を段階的に広げていく計画なら、広げ切ったときの人数も先に置いておくと判断しやすくなります。切り替えの進め方については、新システムへの切り替えは「一斉リリース」か「段階リリース」どちらが良いのかで扱っています。
冒頭の複合機の稟議を、4つの層に沿って数え直します。数え直して増えるのは業務の量ではなく、同じ1件の稟議に関わる人の範囲です。
大阪支店から上がってきた複合機3台の入れ替え稟議。金額は240万円、経路は支店長・管理部長・経理部長の3段です。
この作業は、載せる業務を足すたびにやり直しになります。稟議に加えて情シスへの依頼業務を載せるなら、第1層に依頼を出す全社員が入り、第3層に作業を担当する情シスが入ります。依頼系の申請を載せたときに何が変わるかは、依頼系の申請は一覧を見ても誰の件か分からない。原因と一覧から逆算するフォーム設計にまとめています。
ワークフローシステムの利用人数が決まらないのは、社内の把握が足りないからではありません。登録が必要になる理由が4つあり、そのうち2つは検討の後半にならないと姿を現さないためです。
であれば、順番のほうを変えられます。人数を先に出すのではなく、経路を氏名指定で組むのか役職から計算するのかを仮に置き、その前提とセットで人数を出す。前提が書いてある見積書は、あとから前提ごと見直せます。
クラウド型の製品では、契約期間の途中でも追加できることが一般的です。ただし、追加分の単価が契約時のものになるか、そのときの人数帯の単価になるかは製品によって分かれます。減らす方向は更新時のみという条件が付くこともあるため、増やす場合と減らす場合の両方を契約前に確認してください。
決裁済みの稟議に承認者として名前が残っている場合、アカウントを消すと証跡の追跡が難しくなることがあります。ログインを止めたまま記録を残す「無効化」にあたる状態を用意している製品もあります。その状態が課金対象に入るかどうかは製品ごとに異なるため、証跡の保存年数とあわせて確認してください。
その人たちが申請を上げるか、申請の対象として指名されるかで変わります。自分で経費や休暇の申請を出すなら第1層に入ります。自分では申請しないものの、上長が代わりに申請を出す対象になるなら、第4層としてマスタへの登録が必要かどうかを確認することになります。