これを気を付けておけば承認プロセスと呼べるんじゃないかというポイント
Salesforceで承認プロセスを使う機会ってそこそこありますよね。
ただ、承認プロセスの構築って本当難しいんですよね。
ただ単に機能を実装しただけみたいな。。。(自分もそうでした。)
え、それ承認申請じゃないじゃん、みたいなものもあるので、
今一度承認プロセスの構築においてこういう風に考えたらいいんじゃないか的な考え方を主観でまとめてみました。
この記事の内容は個人の見解です。
へえ、そういう考えがあるんだというくらいに受け取っていただけるとうれしいです。
ステップ設定
まず、承認プロセスのステップ設定からです。
業務や会社にもよりますが、承認申請には以下のようなステップが存在します。
(めちゃ簡単に。)
- 00 未申請
- 10 申請済
- 20 承認済
- 30 却下
承認申請フローが今どの段階まで進んでいるのか、あとどれくらいのステップが残っているのか誰が見ても分かる状態にするためです。
このステップ作成時に気を付けた方がいいなと思うのは、「粒度」です。
承認フローの複雑さや期間の長さによってステップの粒度を使い分けます。
- 承認プロセスがシンプルだったり、承認期間が短い場合、ステップは最小限
- 承認プロセスが複雑だったり、承認期間が長い場合、ステップは詳細に定義
例えば上記に記載したステップは4つしかなく、これは非常に短い期間(1日とか)で承認作業が完了するケースです。
短い期間で終わるということが申請側も承認側もわかっているので最低限のステップ管理で十分ですよね。
一方、承認者にいろいろな関係者が含まれ、かつ、承認期間が数週間など長くなる場合はどうでしょう?
「申請済」のステップからなかなか「承認済」に移らず。現状誰のどのステップで止まっているのかわからないですよね。
このような場合には、「承認中」や「マネージャー確認中」など、より粒度の細かいステップを定義すると全体の位置を把握できます。
ステップはすべて自動更新
ステップはすべて自動更新にします。
申請時、承認時、却下時、にはステップの項目を更新する「項目自動更新」を使用しましょう。
そしてステップは画面から編集できないようにします。
ステップを自分で変更できちゃう承認プロセスは承認プロセスじゃないですよね。
ちょろまかし放題。
レコードロックの利用
申請後、承認後には「レコードロック」を使用します。
申請の後や承認の後にレコードを編集できるなんてことはあってはいけませんよね。
もし申請内容に変更がある場合は、正式な修正依頼を出すか、その申請が却下された後に再申請を上げるべきだと考えています。
よくよく考えれば当たり前のことで、紙で申請する際、変更があってもそれを書き直さず、申請書をもう一枚起票するはず。
Salesforceになってもやることは同じ。
運用のイメージ
承認プロセスは作ったら終わりではなく、実際の運用フローもちゃんと考える必要があります。(どの機能もそうですが。)
特に承認申請についてはレポートでタスク管理ができず、自分が承認しなければならない申請がどれかを把握するのに工夫が必要です。
例えば、ホーム画面に「未承認申請」の一覧(標準コンポーネント)を表示して、承認者の目に留まるようにしたり、リストビューで申請対象のレコードのステップを絞り確認するなどが挙げられます。
ここは正直自分もどのように運用していくべきか迷走中~。
みなさんはどのように承認申請のタスク管理(承認側)をされているんでしょうか。
何か良い方法があれば教えてくださいませ。
おわりに
Salesforceの承認プロセスはポチポチ設定すればそれなりの形にはなるのですが、詰めるところは詰めないと穴だらけのプロセスになってしまいます。
個人的なポイントとしては、紙で申請する場合はどうする?と考えることです。(上司の方の受け売りです)
紙でもSalesforceでも基本的にやることは変わりません。
その目線をもっていれば少なくとも承認プロセスと呼べる機能を構築できるのではないでしょうか。
ただ、レポートでタスク管理ができなかったりするのでそこは工夫が必要なんですよね。
レポート、ダッシュボード管理できるようにしていただきたいなあ。
コメント