公開日：2021-06-07
kintoneにはプロセス管理と呼ばれる機能があります。これはいわゆるワークフローをkintoneで実現するための機能です。物品購入の申請フローや交通費申請のフローなど、ワークフローが必要な場面は色々あります。
申請承認のワークフローだけではなく、ワークフローというのは「誰がボールを握っていて、その人が何をすべきなのかを明確する」ものです。つまり、業務のキャッチボールを明文化するものです。
業務フローというのはさまざまな形態がありますので、kintoneのプロセス管理でどこまでの業務フローが表現できて、どういうものが表現できないかを知っておくというのはとても大切です。
このコラムでは、業務フローの図をみながらできるできないについて考えていきましょう。
前提条件
これからご紹介する例はすべて、ある申請承認フローを例として用いています。また、このフローに登場する人物および立場としては次の図のようになっています。
例1
まずは、オーソドックスな例からみていきましょう。
- 山田さんが起案し、「申請」すると「承認待ち」ステータスになりボールは大山田さんに行く
- 大山田さんは判断して「承認」すると「完了」になる
- 大山田さんは問題がある場合は「差戻し」すると「再提出」ステータスになり山田さんへボールが戻る
- 山田さんは修正して「再申請」することで「承認待ち」ステータスになる
これは問題なくkintoneで実現可能です。kintoneではこの図の黄色い四角が「ステータス」、薄赤色の四角が「アクション」となります。
例2
次に、少し応用したケースをみてみましょう。物品購入申請などでよくあるのは一定の金額を超えるとさらに上位の人の承認が必要というケースです。
この例では、上の例1に加えて「100万円以上の場合は社長である鈴木さんの承認が必要」という条件が追加されています。
これもkintoneで実現可能です。kintoneではレコードに含まれるフィールドの値に応じてアクションの組み合わせを切り替えることができ、次のステータスや誰にボールを渡すかを変えることができます。
例3
次は、少し特殊なケースをみてみましょう。基本的な流れは例1と同じなんですが、大山田さんが入院していて承認することができないけど、承認して欲しいという時もあると思います。
その場合、多くの会社では代理承認できるというルールを作っています。このケースでは、隣の部門の部長である北別府さんが代理承認できるというルールになっているとします。
さて、このケースは残念ながらkintoneでは一筋縄にはいきません。
kintoneでは、ボールを持っている状態を「作業者に指定されている」と言いますが、この作業者を変えられるのは「アプリ管理権限」を持っている人だけです。したがって、代理承認をしてもらおうと思うとアプリ管理者が作業者を北別府さんに変えるという作業が必要です。アプリ管理者がボールを北別府さんに転送して作業してもらう感じですね。
そうなると、アプリ管理者がいないと困ることになってしまいます。
そういう場合は、gusuku Customineを使うと、この「アプリ管理者が作業者を別の人に変える」という作業を自動化することができるため、代理承認を実現できます。代理承認できないと業務が回らないという場合は試してみください。詳細はこちらのサポート記事でご紹介しています。
例4
さて、代理承認と似たようなケースです。例1とほぼ同じなのですが何が違うかわかりますか？上に「引戻し」という線が追加されています。引戻しというのは、申請を出したものの間違いに気づいて自分へ戻す時に使います。紙の申請であれば、部長のところに行って「すみません、間違いに気づいたので返してください」って言うようなケースですね。
紙なら部長のところへ取りに行くだけなのですが、例3と同じ理由でこれは簡単にはできません。部長が持っているボールを強制的に動かせるのはアプリ管理者だけだからです。さらに、この場合は作業者を変えるだけではだめです。作業者を一時的に管理者に変えて、その後引戻し処理を行い未処理に戻し、作業者を山田さんにする必要があります。
これもgusuku Customineを使うとできますが、kintoneの標準機能では実現できません。これも具体的な方法はサポート記事をご覧ください。
あまりオススメ出来ない方法としては、申請を出したあとでも起案者が編集できるようにしておくと言うのがあるのですが、コンプライアンス上、申請・承認の意味が曖昧になるのでよくありません。
例5
出来ない例が続きましたが、今度はできる例です。この例では承認が1人でなく、2人の承認が必要なケースになります。これは、kintoneのプロセス管理で問題なく可能です。
どの2人が承認するかは色々な設定方法があり、グループで判断する方法や、起案時にユーザー選択してもらう方法もあります。
この2人の組み合わせが複雑になる場合は、kintone標準機能だけでは自動的に入れられない場合がありますが、そういう場合は、別アプリに承認者のパターンを定義しておいて、gusuku Customineをうまく使うと自動的に決定できます。
例6
これも例5と同じくkintoneのプロセス管理で可能です。先ほどは、全員の承認が必要となるケースでしたが、これは複数人のうち誰か1人でいい場合です。これもkintoneのプロセス管理でできます。
どの3人にするかは、例5と同じで複雑になる場合はgusuku Customineを使ってください。
例7
次の例は例6と似ていますが、3人のうち2人の承認がいると言う多数決パターンです。これはkintoneの標準機能では実現できません。
これをkintoneで実現するにはgusuku Customine等を使って承認した人数をカウントするようにして2人になったら上の代理承認の仕組みで前に進める必要があります。
少しややこしいですね。
例8
最後は、分岐して戻ってくるパターンです。例5と違って2人承認すればいいというだけではなく、北別府さんのあとは鈴木さんの承認が必要となっているため、流れが2つに分岐しているような形になっています。この例は単純ですが、実際にはもっと分岐後の流れが複雑になることもあります。
この形は、kintoneの標準機能では実現できません。ただ、このようなワークフローは終了までに時間がかかることも多く、どこかで停滞してしまうと停滞が見えにくいと言う欠点があります。
ですので、このようなワークフローが必要になった時点で、本当にこのフローが必要なのかを見直す必要があります。
どうしても必要な場合、kintoneで実現するにはカスタマイズが必要です。kintoneのプロセス管理上は分岐して合流することが出来ないため、どちらかのルートのみをプロセスとして定義しておいて、もう一方の流れは通常のフィールドを使ってプルダウンやチェックボックス等でステータス管理をし、合流する時にプロセスを進められる条件としてプロセス管理のステータスとプルダウンやチェックボックスの値をgusuku Customineなどでチェックすることになります。
これもややこしいですね・・・。
まとめ
8つの例をみてきましたが、ワークフローは奥が深くもっと色々なパターンもあります。ただ一貫して言えることは例8にも書いたように、複雑なワークフローになってきた時点で「本当にそのフローが必要なのかを見直す」と言うことです。
kintoneに限らず、業務をシステム化する時は「業務を見直すチャンス」です。複雑な部分や冗長な部分をゼロベースで見直して、スリムな業務にしてからシステム化するのが成功の鍵です。
きっかけとしては「今はこうしているから」とか「こういう時がたまにあるから」などの発言に要注意です。そういう時こそゼロベースで見直すチャンスです！
そんなこと言われてもやっことないし自信がないと言う方は、弊社ハイスピードSIでお手伝いできますのでご相談ください。20年以上の経験を積み重ねている弊社がプロとして支援します。