シリーズ1-1、UML1.3を使った業務分析・改善業務の実践報告。

今回は、ある企業の業務分析・改善を行うために、UML1.3を使いましたので、ご紹介したいと思います。皆さんの参考となれば幸いです。

私の場合は、業務分析・改善教務を、「対象範囲の定義」「AS IS（現状分析）」「問題点・改善点の洗い出し」「TO BE（あるべき姿の定義）」「PDCAサイクル」と進めていきます。

実際にUML1.3をベースに進めてみたのは、「AS IS（現状分析）」「問題点・改善点の洗い出し」「TO BE（あるべき姿の定義）」の部分です。

今回は、概略とはいっても1回で全てをご紹介することは難しいですので、下記の流れでご紹介していこうと考えています。
※執筆の状況によっては、少し構成が変わるかもしれませんがその節はご了承願います。

・対象とする業務の状況と背景
・なぜ、UML1.3を選択したのか
・AS ISの準備・実施・まとめ・確認とサンプル
・問題点・改善点の抽出のポイントとまとめ方とサンプル
・TO BEの準備・実施・まとめ・確認とサンプル
・PDCAサイクルに進む前の承認フェーズにおける役員・中間管理職・現場にむけたプレゼンのポイントとサンプル

もし、こんなことも聞きたいということがあれば、ご連絡頂ければ、加筆していきたいと思います。

【対象とする業務の状況と背景】

　この会社は、かなり歴史のある結構規模のある会社の子会社として6年前に設立されました。
※大企業が新規事業分野に新規参入する際の手法の一つです。

この事業はある程度の成功をおさめ、業界第2位の位置をキープしています。
ただ、懸念があり、サービス立ち上げの際に構築してきた組織・運用体制・システムが、現時点の事業を支えるにはギャップがあり、それを埋めるためにマンパワーに依存することになり、人件費がかさむとともに新たなサービスを創出するのにあたってかなりの制約をクリアしないといけない状況になってしまっていました。

それを改善することになったのです。

企業様と契約を締結にあたって、まず、事前に「ゴール」「改善範囲」「スケジュール」をある程度明確にするために、経営者層の方達から、事業設立の際の思い、現状に対する不満、今後の会社運営の思いを伺い、現場のリーダの方達からの協力を頂けることを確認し上で、当初かける工数をはじき出し、契約し、プロジェクトをスタートさせました。

本日は、ここまでとします。。。

※記事に関するお問い合わせは、下記までお願いします。
　yamazaki@yusukeyamazaki.jp