申請・承認のプロセスをゼロベースで見直すには
申請と承認
仕事ではたくさんの「申請と承認」がありますね。
大変重要なプロセスです。
kintoneでも「プロセス管理」という機能があり、簡単にこの「申請と承認」を作ることができます。kintoneの優れているところはこの「プロセス管理」を「申請と承認」に限ってないところですね。「申請者」とか「承認者」といった名前定義ではなく「作業者」としている点も自由度を上げていますね。
業務効率化を考えるシーンではこの「申請と承認」のプロセスを見直すことが多いです。要は「無駄な申請・承認はないか」ということですね。
Ａ部署内で書類を作成し、Ａ部署の部長が承認したものをＢ部署に回したときにＢ部長が承認するといったことは本当に必要なのでしょうか？というような議論ですね。
ただ、この議論には地雷がつきもので、ただ「本当に必要ですか？」と聞いても「必要だからやってるんだよ」という結論になってしまいがちです。
システム化においてプロセスの整理は必要不可欠
脱ペーパーや業務のクラウド化を進めるにあたって、このプロセス整理はすごく大事です。なぜならアナログのプロセスって複雑なものでも作りやすいんです。もっと具体的に言うと、長年かけて複雑化しているというのが実態でしょう。
例を挙げます。
経費精算の申請を社員が出すプロセスがあるとしましょう。
まず最初に作られたルールとして、「経費精算は部長が承認して経理部に申請書が渡り、経理部が処理をして完了する」という、至ってシンプルなルールが出来上がりました。
仕事をしていくと様々なルールが追加されていきます。
・部長がいないときは課長が代理承認できる。
・金額ミスを防ぐため、係長がチェックすることとする。
・1万円未満は部長がいても課長承認で良い。
・交際費は事前承認をしなければならない。
・経理処理を行ったあと、経理部の課長がチェックする。
・100万円以上は役員決裁を添付する。
はい、きっと大きな会社では「あるある」なフローなんじゃないかと思いますが、こんな感じでどんどんルールが追加されていきました。
最初の「経費精算は部長が承認して経理部に申請書が渡り、経理部が処理をして完了する」というルールのみであれば、めちゃめちゃ簡単にシステム化できそうですが、後から追加されたルールも盛り込むとなると、ロジックとしては複雑になっていきますね。
フローはどうやって見直すか？
ただ、既に存在しているルールは「必要だから存在する」という大きな壁があります。これは色んなミスや不正を防ぐためだったり、顧客に迷惑をかけないように試行錯誤して作られたルールです。
これに対して「本当に必要ですか？」と言ってしまうと、「今までの作業は無駄だったというのか」と、ハレーションを起こしてしまうでしょう。
上記のルール追加は正直まだシンプルなほうです。会社によっては50を超えるような分岐があるようなフローも存在するでしょう。その全てをそのままシステム化しようとすると、工数も費用もかかり、結局バグが多くなりがちで、「紙のほうがラクだった！」なんて声も上がってしまうオチが待ってます。
そうならないように、システム化する前にフローの見直しをすることをオススメするのですが、「どうやって？」がポイントです。
ぼくはこの「どうやって？」の整理法として「流れる水を堰き止めてまで確認したいか？」という比喩表現を使用して説明しています。
流れる水を堰き止める覚悟
例えば川の水をろ過して家庭に送るような設備を管理する場合、常に最高水準の品質を担保するために全ての工程で水を堰き止める判断をしたとしましょう。そしたら家庭に水が届かなくなるときがありますね。
それは絶対にしてはいけないので、水を流しながらチェックしている機能が存在するのでしょう。専門家じゃないので詳しくは知らないですが。
ただ、超重要な局面では「水を止めてチェックする」というプロセスもあるかも知れません。これを例えにしています。
承認とは「水を堰き止めてでも確認したいようなこと」であり、水を流しながらできる確認は「チェック」です。
「水を堰き止めてでも」という言葉を使うと、そのプロセスの重みが少しわかりやすくなります。「法律上必要な確認」だったり「顧客に直接影響がある確認」だったりがその対象になりそうですよね。
上記の経費精算の例で見てみると、「水を堰き止めてでも確認したいこと」ってなんでしょうね？正直一つもないのでは？という答えも会社によってはありそうです。
「100万円以上の申請には決裁を添付」についても、ルール自体が存在していれば、水を堰き止めてまで必要か？と言われると「もし決裁が取れてなければ事後で取ればいいし、申請者を叱ればいいし」という判断もアリだったりします。
部長の承認も「水を堰き止めてでも必要な承認か？」という観点で言えば、会社によっては「絶対」というところと、「把握さえできればいい」という会社もありそうです。
「全部が必要ない。そこまで重く考える必要はない。」
と言ってるのではありません。整理をするための基準として、そう考えてみようという話なんですね。
この基準で考えても「水を堰き止めてでも確認したいプロセスが50だった」ということであれば、それが正解でいいんです。「ちゃんと見つめ直したか」が重要なんです。
むすんでみますね
kintoneなんかのシステムでは、脱ペーパーが簡単にできるアプリが誰でも作れる便利なツールですが、他部署と連携しているような業務をアプリ化するにあたっては、このような「プロセスの整理」が必要になります。
もちろん他の「データの整理」「アクセス権の整理」といった点も重要ではあるのですが、杓子定規に「全部整理できてからアプリを作りましょう」なんて言ってたら「それ、kintoneじゃなくてもよくね？」って話です。
そこまで完璧な整理ができている会社はそもそも業務プロセスに対する課題なんて抱えてないでしょうｗ
できることから失敗しながらやっていけばいいと思います。
だから「スモールスタート」がいいんですね。失敗も小さいもので済みますからね。
ただ、プロセスの整理はやっておいて損はないです。
システム化するにしてもしないにしても、この整理を行っていると後々効いてくるはずです。
「流れる水を堰き止めてまでのことか？」という例えは、要は「点ではなく線で見ろ」と一緒なんですが、前者のほうがわかりやすくないですか？
「流れを堰き止めてまで」なんて誰も思ってないけど、それでも苦渋の判断で堰き止める。これが「承認」という行為なんです。
さて、視点を変えて締めますが、通常業務でも常に存在していることでしょう、あなたに対する「承認依頼」をうっかり止めてたりしませんか？
「大切な水が堰き止められている」状態ですよ。「ああ、ごめんごめん」で済ませていませんか？
こう考えると「結構ヤバいことをしてる」と思いませんか？
ただ、罪悪感を持つ必要はありません。悪いのは忙しくて作業が追い付いてないあなたではなく、水が止まりやすいプロセスなんです。
こういう視点から「見直し」を考えるきっかけになればいいんじゃないかと思っています。