なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

業務とプロセスとフローとタスクを勘違いした話(長編の派生)

最近、小難しくマニアックな話をたくさんしてきてしまった気がするので、ちょっとお茶請けにでも。

 

私の仕出かした(いや、現在進行形なので、仕出かしてる)失敗談の話。

 

よくある話。

「今これに困ってるんです!」

「このデータを加工したいのにできないんです!」

「この作業にこれだけ時間がかかってて、困ってるんです」

「もっといい方法があるかもしれないんですけど、私にはこれしかできないんです。」

 

などなど。

 

よくある(ありますかね?)ギョームカイゼン、プロセス改善の時の課題発見のトリガーになる言葉たち。

 

ほんと、ほんの少し前に気がついたのですが、これって、あまり役に立たないなって認識しました。

 

例えば、RPAが始まり出した時ぐらいにノラロボット問題とか、メンテに時間がかかる問題とかがとりだたされてました。

 

最近はRPAの使われ方も結構マトモになりつつあるのかなぁと思います。よく言うじゃないですか。RPAを使う前にプロセスを整理しましょう!業務を整理しましょう!とか。

 

他にも無駄を省こう!とか。

 

だけど、よーく、考えて欲しい。

 

それ、タスクの整理になってませんか?

それ、フローの整理になってませんか?

 

いえ、いずれも業務の整理であることは変わらないのです。ただ、本質的にはプロセスを整理しないといけなくて。

 

余談ですが、私の得意な戦術にフローと登場人物を書き出して役割を記載し、役割を再度割り当て直して登場人物を減らしフローの流れを早くする、というテクニックがあります。

ちなみに、これを使った活動で最高に効果が出たのは、1サービスの提供までに15営業日かかっていたものを、リードタイムを5営業日にまで縮めた事があります。

 

TMSで言う7つの無駄のウチ「移動の無駄」を省く、と言うものかなと思ってます。

 

ただ、これは、フローの整理に過ぎず(フローの整理を突き詰めるだけでもこれだけ早くなるってのもどうかと思うのですが)、実際のところ、本質的なプロセス改善には至っていなかったのです。

 

少し混乱してきそうなので解説すると。

プロセスとは、抽象化されモデル化された大枠のものです。極端なことを言うと、

仕入れる」→「作る」→「売る」→「仕訳る」これがプロセス。

要は、組織間の関係性を可視化して、最終ゴール(≒儲ける)に持って行くまでのモデル図。

フローとは、これらプロセスの中のものや情報の流れ。

誰が、誰に、何を、何して、渡すのかを図式化したもの。

例えば先ほどの「仕入れる」であれば、仕入れるものを探してきて、上司に稟議書を切って、承認されたら発注して〜となるはずです。

これを表したものがフロー。

 

じゃあ、タスクは?

そのフローの中に表現される一つ一つの作業、といえばよいでしょうか?

例えば、先ほどの仕入れるものを探してくるというフローの一要素がありましたが、これ、探すためには目的の素材を定義したり、仕入価格を決めたり、その素材でいいのか、仕入れ元は仕入れ元としての基準を満たすのか調べるとか色々やらなきゃいけないことありますよね。これら一つ一つのものがタスクです。

 

お気付きの方もいるでしょうか?RPAは使う前に業務を整理する、プロセスを整理することを大切だと言ってます。

RPAはタスクを省力化するもののはずなのに、何故かプロセスを整理するんです。

 

悪い営業が、テキトーなこと言ってるパターンもあるかもしれませんが、これは本質的に痛いところをついてくるなぁと思うわけです。

 

その仕事、業務、プロセスに、そのフロー、タスク、必要ですか?をまず考えましょう!って言ってるんですね。それをしないと、ノラロボットやメンテが大変なロボットが生まれると。まぁ、他人が作ったエクセルのマクロだと思えば大体あってるのでは?と思います。

 

ああ、話がすっ飛びました。

 

私がした失敗ってのは、最初の言葉「これに困ってるんです!」を真に受けて、タスクを整理してしまい、プロセスにたどり着けなかったってことなんです。

 

言い訳ですが違和感は感じてたんです。なんか違うなと。頭は痛くなるし、自分のやっていることや考えていることに違和感も感じてました。でも、止まれなかった。で、ある日同僚と喋ってだときに気がつかされました。

あれ?これってプロセスの改善してなくないかと。タスクやフローの可視化には繋がってた。けど、けど、プロセス。つまり、モデリングされた大きな流れに全くたどり着けてないと。

 

それからは、まず今まで集めてきたタスクが、どのプロセス、またはフローに準ずるものかを必死に書き出しています。タスクなのかフローなのかは気にしてません。つまり、どんなプロセスが存在するのか?を理解するために、今目の前にある事実を書き出していってます。

 

で、これまたつい最近気がついたのです。

あ、これ、社長だと。

当ブログの最長シリーズ「SoRとSoE」の第5回で申し上げた「社長」の話です。一つのサービスを提供する上で必要となる機能をバックログに取り込むためには社長やって肌感覚を身につけないと難しいんじゃない?という話です。

 

どうも、社長にならなくても、ビジネスプロセスを作ること、可視化することは出来るんじゃないか?そう思ったわけです。

 

今の取り組みが成功すれば、社長にならなくてもピジネスプロセスを理解し、可視化するコンサルタントにはなれるんじゃないかな?と思ってます。要は、あるべきプロダクトオーナーになれる。ただ、この取り組みをする上で最大の障害があって。。

日常オペレーションにかなり時間を取られそうな上に、私はこの「ルーチン」を行うということが死ぬほど苦手なんです。総合職としての立場上、PMだけをやりたいというのもはばかられ。。うーん。ルーチンに忙殺されるほど本末転倒なことはないはずなのですが。。