ワークフローのトライアルは、何を確かめる30日か。検証を3層に分けて設計する
トライアル環境のタブを3つ並べたまま2週目に入っている。
申請を作って、承認して、差し戻して。ひととおり触った検証メンバーからは、毎回そろって同じ感想が返ってきます。
触った感じはどれも悪くない。ただ、どれが良いのかは分からない。
比較表の「操作性」の欄には3つとも○が並び、その下の欄が空いたままになっています。
ワークフローのトライアルは、たいてい30日。延長に応じる製品も多いので、期間そのものが足りなくなることはあまりありません。それでも検討が前に進まないのは、確かめる順番が決まっていないからだと思っています。
「まずは触ってみてください」という案内は、間違ってはいません。ただ、触って分かることと、導入後に効いてくることは、重なる部分が思ったより小さいんです。
この記事では、トライアルで確かめられることを3層に分けて整理します。どの順番で手を付けるかを選ぶときの、たたき台になれば十分です。
触った感想は集まるのに比較表が埋まらない
トライアル環境が届いてから最初の数日は、検証がいちばん進みます。
管理画面を開き、テスト用のフォームを1つ作り、自分宛てに申請を出して承認してみる。画面の分かりやすさ、レスポンスの速さ、スマートフォンでの見え方。ここまでは、どの製品でも同じ手順で確かめられます。
ところが、そこから先に進む道筋が見えません。
確かめる対象が「製品の使いやすさ」から「自社の運用に合うか」に切り替わった瞬間、何を試せばいいのかが急に分からなくなる。トライアルが止まるのは、たいていこの切り替わりの地点です。
理由は単純で、後者を試すには自社の運用が確定している必要があるからです。
どの申請から載せるのか。承認の段数はいくつか。誰が管理者になるのか。決まっていないものは、試しようがありません。だから検証は、決まっていること、つまり操作感の確認に自然と引き戻されます。
正直に言うと、私も以前は「まず触ってみてください」とだけお伝えしていました。トライアル環境をお渡しして、質問が来たら答える。それで十分だと思っていたんです。
考えが変わったのは、30日間まじめに触り込んだのに「もう少し検討します」で止まってしまう場面を、何度か見てからでした。触った時間が足りなかったわけではなく、触る順番が決まっていなかった。そう考えたほうが、起きていたことをうまく説明できます。
トライアルで確かめられることは3層に分かれている
トライアルで検証できることは、性質の違う3つの層に分かれます。
層 | 確かめること | 分かるまでの時間 | 製品ごとの差 |
|---|---|---|---|
第1層:操作感 | 画面の分かりやすさ、申請・承認の手順、モバイル対応 | 数時間〜3日 | ほとんどつかない |
第2層:再現性 | 自社の申請を、実際の承認ルールどおりに組めるか | 1〜2週間 | はっきりつく |
第3層:運用継続性 | 組織変更・例外処理・権限移譲を、運用として回せるか | 触るだけでは見えない | いちばん大きい |
第1層に近いほど、短い時間で分かります。そして第1層に近いほど、製品ごとの差はつきません。
多くの検証が第1層に時間を使うのは、順番として自然です。取っ掛かりやすく、検証メンバーを集めやすく、感想も集まります。
問題は、そこで集まった感想が、導入後にいちばん効いてくる第3層について何も語っていないことです。
第1層で差がつかないのは当たり前のこと
操作感で差がつかないのは、製品の努力不足ではありません。
申請フォームに入力して、承認者に通知が飛び、承認か差し戻しを選ぶ。この流れは業務そのものが規定しているので、どの製品でも似た形に収束します。
だから、第1層の検証で優劣をつけようとすると、たいてい空振りします。
代わりに確かめておくと後で効くのは、2つです。
1つは、モバイル利用や通知連携が標準機能なのか、有償オプションなのか。ここは製品によって分かれるので、操作感そのものより見積もりに効いてきます。
もう1つは、社員に説明が必要になりそうな箇所がどこかという点です。申請一覧の見方、差し戻しの受け取り方、代理申請の入り方。説明が要る場所が分かれば、そのまま導入時に配る説明会資料の目次になります。
3日触って分からない操作感は、30日触っても同じ評価になる。第1層は、早めに切り上げて次に進むための層だと思っています。
第2層はいちばん面倒な申請を1本だけ選ぶ
第2層で確かめるのは、自社の申請が実際のルールどおりに組めるかどうかです。
ここで選ぶ題材を間違えると、検証は意味を持ちません。休暇申請や押印依頼のような単純な申請は、どの製品でも問題なく組めてしまうからです。
選ぶのは、いちばん面倒な申請を1本だけ。
例えば、購買稟議。1件50万円未満は部長決裁、50万円以上は本部長、300万円以上は担当役員に上がり、さらに役員3名の合議に回る。ただし年間契約は金額に関わらず法務審査が入り、取引先が新規の場合はさらに与信確認が加わる。一方で、既存取引先との年間更新で金額が据え置きの場合は、法務審査を省略する。
この1本を、実際の承認ルールのまま最後まで組み切ります。
途中で「この分岐は本番では違う形にするかもしれないから、いったん単純にしておこう」と省略したくなりますが、省略した部分こそが製品の差が出る場所です。金額の閾値、条件による審査の追加、条件による省略。この3つが揃った申請を1本組めれば、社内の申請の大半は同じ手順で組めます。
組み切ったあとに確かめることも決めておきます。
- 申請者を変えて出したとき、決裁者が正しく切り替わるか
- 金額を閾値のちょうど境目にしたとき、意図した経路に流れるか
- 条件を満たさない申請で、法務審査のステップが飛ばされるか
- 省略条件に当てはまる申請で、審査を対象外にできるか
- 合議のステップで、全員承認・過半数などの条件を指定できるか
- 途中で差し戻して金額を変えたとき、経路が組み直されるか
最後の項目は、見落とされやすいところです。差し戻しは日常的に起きるのに、検証では「一度出して承認する」までしか試さないことが多い。
金額を直したら、経路は最初から引き直されるのか。それとも承認済みのステップはそのまま残るのか。
この挙動は製品によって考え方が違い、しかも運用が始まってから「思っていたのと違う」となりやすい部分です。
第2層で時間がかかるのは、設定を作る作業よりも、社内で承認ルールを確認する往復のほうです。
第3層は触るだけでは見えない
第3層は、運用が始まってからの数年を左右する層です。それなのに、画面を触っているだけでは絶対に見えません。
見えないのは、第3層で問われるのが「変化が起きたときにどうなるか」だからです。トライアル環境には変化が起きないので、こちらから起こしてやる必要があります。
起こす変化は3つで足ります。
1つ目は、組織変更。
トライアル環境に、期中の組織改編を再現します。部を1つ分割する、課を統合する、部長を交代させる。そのうえで、購買稟議の経路が何本修正を必要としたかを数えます。
数えるのは、修正できるかどうかではありません。修正の手間がどこに発生するかです。経路を1本ずつ開いて直す必要があるのか、組織図側を直せば経路は無修正で済むのか。ここが、運用の重さをそのまま決めます。
2つ目は、例外処理。
承認者が長期休暇に入った状態を作り、申請を出してみます。
いま誰に回せばいいのか分からない。とりあえず戻ってくるのを待つしかないか。
運用が始まればこの場面は必ず来ます。代理承認を誰が設定できるのか、本人が設定できない状態でも管理者が代われるのか、代理で承認した記録がどう残るのか。3点セットで確かめておきます。
3つ目は、権限の分担。
管理者アカウントを2つ作り、片方には一部の権限だけを渡します。
部門の担当者に選択肢の追加だけを任せたい、という場面を想定した検証です。渡せる権限の粒度が粗いと、結局すべての依頼が情シスに戻ってきます。
なお、本番の設定を壊さずに検証を続けたい場合、契約後にテスト環境を別途持てるかどうかも確認しておくと安心です。標準で付く製品と、有償オプションの製品があります。
30日の使い方は、第2層と第3層に厚く配る
どの層に何日、という正解はありません。申請の複雑さも、社内の承認ルールがどこまで決まっているかも、会社によって違うからです。
ただ、順番については1つだけ言えることがあります。第3層は、先に予定を取っておかないと消えます。
第3層の検証には、社内の承認ルールが確定していることと、組織変更を再現する手間の両方が要る。準備が必要なものは、他の作業に押し出されていきます。
第1層を早めに切り上げて浮いた時間を、第2層と第3層に寄せる。第2層で作った設定はそのまま第3層で使い回せるので、日数の印象ほど作業量は増えません。
30日で収まらなければ、延長を申し出て構いません。延長の可否は製品によって異なるので、必要になりそうなら早めに相談しておくのが確実です。
トライアルで出てくるのは製品の差より自社の未確定事項
ここまで書いておいて何ですが、私はトライアル環境をお渡しする側で、30日の検証計画を自分の手で回し切った当事者ではありません。設定の作り方は説明できても、社内の承認ルールを確定させる調整の大変さは、実際に進めているみなさんのほうがずっと詳しいはずです。
そのうえで、外から見ていて確かだと思うことが1つあります。
検証を第2層・第3層まで進めた会社が最後に持ち帰るのは、製品の優劣ではなく、自社でまだ決まっていないことの一覧です。
購買稟議を組もうとして、300万円の閾値が税抜か税込かで社内の認識が割れていることに気づく。組織変更を再現しようとして、部の分割時に旧部門宛ての申請をどう扱うか決まっていないことに気づく。
こうした未確定事項は、製品を選んでも消えません。導入プロジェクトが始まってから出てくると、そのまま遅延の原因になります。
だから、トライアル期間の成果物は2つあると考えると、進め方が変わります。
1つは、製品の可否判断。もう1つは、自社の未確定事項の一覧です。後者は、どの製品を選ぶことになっても無駄になりません。
先に聞いておくと30日の使い方が変わること
相談の場で「これは先に聞いておけばよかった」と言われることが多い質問を並べておきます。答えを用意しておく必要はなくて、聞く相手が社内なのかベンダーなのかを分けるだけでも、時間の使い方は変わるはずです。
社内に聞いておくこと
- いちばん複雑な申請はどれか。そして、その複雑さを説明できるのは誰か
- 金額の閾値は税抜か税込か
- 直近1年で予定されている組織の動きはあるか
- 決裁権限規程の最新版はどこにあるか
ベンダーに聞いておくこと
- 差し戻して金額を変えたとき、経路は引き直されるか
- 組織図を直せば経路は無修正で済むか、経路側も直す必要があるか
- 代理承認は本人以外が設定できるか。代理の記録はどう残るか
- 部門の担当者に渡せる権限は、どこまで細かく切れるか
この8つのうち、答えが出ていないものが、そのまま自社の未確定事項の一覧になります。
次にトライアル環境を開く前に
トライアルの30日は、製品を評価する期間であると同時に、自社の運用の解像度を上げる期間でもあります。
第1層の操作感は早めに切り上げ、第2層でいちばん面倒な申請を1本組み切り、その設定に第3層の変化を起こしてみる。順番を決めておくだけで、期間が終わったときに手元に残るものが変わります。
配分に正解があるわけではないので、この3層の整理を、次の検証計画を見直すときのたたき台として使ってもらえたら十分です。