タイトルにもある「業務設計」という言葉。
なじみのある方はどのくらいいらっしゃるのでしょう？
私がこれまで主に製造業向けにコンサルティング活動をしてきた感覚では、あまり浸透していない感覚です。
一方で、ITの業界では比較的なじみある言葉なのかな、とも思います。
IT導入にはこの「業務設計」という考え方は必要不可欠なんです。業務を整理し、何の機能を果たし、どのように行うのか、定義できて初めてシステム化が可能になります。
さて、今回は、製造業ではあまりなじみのない「業務設計」について紹介していきます。
製造業の製造現場だけでなく、間接業務の現場や製品開発の現場においても大いに役立つ考え方ですので、ぜひ参考にしてみてください。
目次
業務設計の５つのポイント
それでは、この業務設計に重要な５つのポイントについて、ひとつずつ見ていきましょう。
Point.1 目的・ゴールの設定
何はともあれ、まずは目的を決めなければなりません。
「この業務が成し遂げることは何か」
明確に定義をしましょう。
文章で書くと当たり前のように思える内容なのですが、この「業務のそもそもの目的」というのは、けっこうおざなりになりがちなんです。
とかく、ITツールなどの導入を前提として考えられている場合、いわゆる「手段の目的化」現象が生じてしまい、ツールを使いこなすためのルールや業務のやり方になりがちです。
IT導入による業務効率化も重要なんですが、
「要は、何ができればいいのか」
という業務の本質をいつでも忘れないようにしましょう。
Point.2 業務の流れや進め方
業務の目的を忘れなかったとして、次に必要になるのは「順番」です。
何をして、その次に何をして、、、、というプロセスの連鎖を考える必要があります。
ここでも陥りがちな罠があります。
それは、「現状の作業の順番」で考えてしまうことです。
その結果、【現状をそのままIT化してしまい】、効率化も何もなく、むしろITツールを操作する作業が増えるだけ。。。
なんていう悲しい現場も何度も見てきました。
IT開発者から言わせれば、POA(Process Oriented Approach)ではなく、DOA(Data Oriented Approach)で考える、と言えばわかるのでしょうが、ITに馴染みのない方に言うとすると、
「情報の流れを考えましょう！」
と言うことになります。
ぜひ、客観的に情報の流れを見て、業務プロセスを組んでみてください。
Point.3 関係者（ステークホルダー）の整理
さて、業務プロセスが組めてきたら、各作業を実行する担当者や担当部門が見えてくると思います。
その際に、以下の点に注意して導入前の情報を整理してみてください。
・そのプロセスを担当する部署はどこか
・直接的なオペレーション以外の影響があるプロセスはあるか
・その関係者は誰か
・仕事内容は現状とどう変わるのか
・今できていることで、できなくなることは何か
この作業、けっこう地味ですが非常に重要です。
この作業を怠ると、
「え！！聞いてない！！」
「なんでこっちまでやり方変えなきゃいけないの？」
「いつ決まったの？」
なんて混乱を招いてしまいます。
そんな混乱した現場を鎮静化することは非常に労力が掛かりますし、最悪の場合、それによって協力が得られずプロジェクトが頓挫してしまう、なんてこともあります。その時になって後悔するのではなく、予めの周知は行っておきましょう。
Point.4 判断基準を明確に！
業務設計において、ある種の「決断」が重要になります。
ここでいう「判断基準」とは、
【いる / いらない】
【やる / やらない】
【重要 / 重要じゃない】
【定常 / 非定常】
【終わり / 終わりじゃない】
いろいろありますが、これら全てです！
特に重要なのが、
【そのプロセスは何を持って終わりなのか】
を明確にすることです。
つまり、アウトプットの品質ですね。この判断基準を明確にしておかなければ、その次のプロセスのインプットの質が悪く、悪さ加減が雪だるま式に大きくなってしまったり、どこかのプロセスで気を使って修正したことが的外れだったり、プロセス間の “ゆらぎ を生みます。
Point.5 ムリ・ムダ・ムラを洗い出す
こちらは、もはや改めて書く必要もないくらいに周知されていることかもしれないので改めて説明することは致しませんが、ここでは、このムリ・ムダを見つけるコツのような考え方をお伝えします。
それは以下の６つの考え方を持ってみると良いでしょう。
・繰り返し性のある作業
・モチベーションの下がる「やらされ感」満載の仕事
・手戻りやヒューマンエラーが起こりやすい仕事
・紙や押印を伴う仕事
・定時内に終わらない仕事
・誰も得してない形骸化した定期会議や資料作成
もしこんな業務があるなら、業務再設計時には積極的に排除していきましょう。
ECRS（Eliminate(排除する) / Combine(くっつける) / Rearrange(再構成) / Simplify(単純化)）なんていう考え方もありますね。この考え方もぜひ参考にしてください。
さいごに
業務改善やIT導入においては、「業務設計」という考え方は必須だと考えています。
作業をこなすための小技もいいのですが、やはり目を向けるべきは仕事そのもののやり方であるべきです。
「オレら、ITわからないし」
「ITの専門家にお願いしよう」
IT導入時、開発時に、こんな発言をするユーザー（発注側）の担当者がいますが、それは少し間違いです。
いくらITの専門家といえど、業務そのものを理解しているわけではないですよね？
そんなベンダーに業務設計をも丸投げしてしまった結果、業務での適用が全然できなかった！なんていう現場も、これまた数多く見てきました。
業務設計については、最終的にITを導入するかどうかの判断も含めて必要で重要な作業です。
ITに詳しいかどうかは関係なく、ぜひ、取り組んでみてください。
もう少し具体的に、どのようにやったら良いのかを知りたい方は、お問い合わせフォームから遠慮なくご連絡ください。
