DBICメンバーの4社が集まって、「ビジネスプロセス」について語り合いながら、BA（ビジネスアナリスト）の職務も理解してみようという取り組みを始めた。4社・6名の方々はほぼビジネス部門の方で、ビジネス部門として「ビジネスプロセス」を理解しようという趣向だ。アドバイザーを「ビジネスプロセスの教科書（第2版）」などの著書を書かれている山本政樹氏ににお願いしている。 このチームのゴールは誰もわからない。ただ、全員が共感していることは、ビジネスプロセスという考え方を理解し、実践していくことは、企業の優位性を築くうえで有効なのではないか、という仮説だ。
初回は参加者の課題認識などを語り合い、2回目は各社からビジネスプロセスの一例を持ち寄り、自由なフォームでの説明とそれに関する質問を行いながら、ビジネスプロセスへのアプローチを始めた。2回目の活動で感じたことをいくつか書いてみる。
〇誰の目線でプロセスを書くのか サービスを提供している企業側の目線で書くプロセスと、パートナーやお客様の目線で書くプロセスとは大きく違ってくる。どれが正解ということではなく、何を目的に書くのか、ということで目線の設定を決めていくことの必要性を感じた。とかく私たちは企業側の目線で書く習慣があるが、パートナーやお客さまに焦点をあてて書いてみると、まったく別の世界が現れる。
〇プロセスを書いてみることでの発見 自分の身近な仕事をプロセスで書いてみると、普段思いつかない新たな発見に遭遇する。例えば、研修のプロセスを書きながら、研修そのもののプロセスとは別に、送り出す上司のプロセスや、研修後のフォローのプロセスに課題を感じた。あるいは、商品開発のプロセスを書いてみると、従来のものとデジタルインフラを使うものとが同じプロセスだったことに、新鮮な気づきを得たなど。
〇火力発電所と人財育成は同じプロセス 俯瞰したプロセスを書いてみると、火力発電所の運営と人財を育成する業務のプロセスが同じものだと気づいた。プロセスは、設計・開発・運用で構成されており、まったく同じだ。そして、対象業務の「設計・開発・運用」を具体的な活動にブレークダウンしていくと、何ができていて、何が手薄いというのが見えてくる。例えば、人財育成の「設計」フェーズが今のままでいいのだろうか、という課題を感じるようになる。
〇設計・開発・運用が、一貫したコンセプトで実行されているのだろうか 大企業では、一つの業務でも、設計・開発・運用を別々の部署が担当することが多いから、一貫したコンセプトが伝わりにくいかもしれない、という問題意識にぶつかった。トヨタの主査制度とか、プロダクトオーナーの考え方を調べてみると面白いかも。ただ、組織はどうしても縦割り機能にならざるを得ないから、そこの悩みは大きい。
〇プロセスで語れない仕事の中身も多い プロセス図を書くと一つの箱だが、その中身はかなりのノウハウを要する仕事も多い。つまり、業務をプロセスだけで表現することは難しい。ノウハウを可視化するとか、それをソフトウエアで置き換えるとかを考える際には、判断の内容が論理的に整理できるものなのか、もっと違う要素での判断なのかを分析していく必要がある。
〇ビジネスプロセスを書くことで、他の人との議論が進めやすくなる 他の部署やチームの人と議論するとき、共通の土俵がないと議論が空中戦になりやすい。お互いの主張の輪郭が微妙にずれていることが多いのがその理由だ。なので、ビジネスプロセス図を共通の土俵として、それを見ながら議論すると充実した議論になる。これは、データを共通の土俵にするときも同じ効果が得られる。
〇ビジネスプロセスを図に書く意義 ビジネスプロセスを図に書こうと試みると、書くルールを覚えなくてはいけない、とか、粒度のレベルをどの程度にすべきかなどで悩んでしまう。しかし、実はそれは些末なことで、ある意味どう書いてもいい。大事なことは、プロセス図を書きながら、ビジネスの構造上の課題、このプロセスが持つ弱点、あるいは、お客さまやパートナーが抱えている潜在的な課題などに気がつくことではないだろうか。その目的のために、誰に焦点をあてて書くのか、その粒度をどの程度にするのか、などを自分の思考回路に合わせながら工夫し、本質的な課題を探り当てることが肝心だと感じた。
3回目では、「俯瞰する」という考え方を中心に議論する予定。
他のDBIC活動
他のDBICコラム
他のDBICケーススタディ
一覧へ戻る
一覧へ戻る
一覧へ戻る
このお知らせをシェアする
