モデリングだけでは語れない業務分析の現場〜IT技術者のための戦略・業務分析入門〜：事例で学ぶビジネスモデリング（5）（4/4 ページ）

» 2005年11月23日 12時00分 公開
[大川敏彦（シニアコンサルタン），ウルシステムズ]
前のページへ 1|2|3|4 　　　　　　

第3章　施策立案

　さて上記の報告会と並行して、我々プロジェクトメンバーは施策の詳細化作業に入った。報告会の結果によって、若干修正はあるであろうが、すべての報告会が終了するのを待っていては、プロジェクトの進捗（しんちょく）に支障を来してしまうからだ。

　施策の立案と新業務設計は、これまでと違って、予算、MD計画、発注……などの業務分野ごとに、ペアになって作業を行った。これは、前半の現状業務分析および問題点分析作業で、業務手順や問題点について、カテゴリあるいは品種ごとの違いがあまりなく、大部分は共通的に扱えることが分かったからだ。今回まとめた主な施策例をいくつかに示す。

主要施策

  • B-01：商品部での店舗予算の把握とMD計画との連携強化
  • M-01：店舗別商品台帳の作成
  • O-01：発注業務の簡素化による容易な結果把握の実現
  • R-01：実績の全社共有・予実分析の実施


　先ほどまとめていった発注の問題点に対する施策は、「O−01発注業務の簡素化による容易な結果把握の実現」としてまとめられている。施策の概要としては、以下のようになる。

施策 発注業務の簡略化による容易な状況把握の実現
施策の概要 現在数十種類ある発注業務を可能な限り簡略化し、直感的に発注状況を把握できるようにする。さらに発注状況を把握するシステムツールを導入することで、発注担当者、スーパーバイザ、バイヤーが適時発注状況を把握できるようにする
施策の効果 重複発注の削減、指導効果のアップ、売価変更・廃棄の削減

ALT 図4 前半の現状業務分析および問題点分析作業で、業務手順や問題点について、カテゴリあるいは品種ごとの違いがあまりなく、大部分は共通的に扱えることが分かった

第4章　新業務設計

　各施策の概要イメージが固まったので、次に最終段階としてあるべき業務（To-Beモデル）を業務モデルとしてまとめる作業に入った。各メンバーは施策立案のときと同様の体制で、業務ごとのチームに分かれて作業を行った。一方、私ともう1人の担当者が全体のまとめとして全体業務モデルの作成と業務チームごとに作成した業務モデル間の整合性をチェックする役割を担った。

　各チームは各施策をさらに詳細に展開していった。例えば、O-01：「発注業務の簡素化と容易な結果把握の実現」では、5W1Hを基本の考え方として、以下のように施策を詳細化していった。

  1. What：今回、発注の主体者により発注パターンを（1）店舗発注、（2）本部発注、（3）店舗・本部協調型発注と3種類に分類・定義した
  2. Who：発注業務における調達サイド（バイヤー）、販売サイド（店舗発注担当者）、管理サイド（店長など）の役割を明確にする
  3. When：店舗発注と本部発注のタイミングを精査した。発注パターンごとに、本部店舗間のやりとりに注意しながら、それぞれの発注スケジュールを定義した
  4. How：発注ツールを整理した。また、そのとき店舗発注、本部発注のデータを統一管理発注数量などの状況の確認ができるようにする

　一方で、全体の新業務フロー作成を担当した私たちは作業を分担して行うことにした。具体的には全体業務フロー作成をもう1人の担当者が行い、業務間の整合性の確認を私が行うことにした。

　業務間の整合性の確認では、それぞれが作成した業務モデルをMS-Projectなどのツールを使って実際の日次を設定して、因果関係を付けながら、業務のつながりに不整合がないか検証していく。

　例えば、来年4月からの年次予算を1月初旬に経営企画部が作成し始めるとする。それが本部店舗間、あるいは店舗内で何度かの会議体を経て、年度始に立案する月次予算になり、月次修正予算、週次予算、日次販売計画まで落ちる流れを週単位や、必要に応じて日次の計画で詳細化する。一方、MD計画業務では、同様に年度のMD計画作業が行われ、2カ月前になる2月中には品揃（ぞろ）え計画を実施し、対象週の1週間前までには単品計画が終了することになる。

　この作業で重要なのは、新業務では、MD計画で作成した品揃え計画や単品計画が週次の売上目標を達成するための計画になっているかを確認していくことにある。そして最終的には、課題で設定した「週次・単品レベルでの、予算から実績管理までの一環した業務サイクルの実現」が実現できているかを確認するのである。

　当然のことであるが、この作業の中には、先ほどの発注業務の簡素化の検討結果も盛り込んで、予算やMD計画などとの関連についても検証し、全体として問題がないかを確認した。　

　またさらに重要なのは、この計画が実際の運用に耐え得るかも検証しておくことである。そのためにはこのような机上のシミュレーションも重要であるが、作成したTo-Beモデルについて、顧客と十分にレビューしておくことが、より重要になる。また、可能なら現場で実際に試してみて、業務として十分適応可能かどうかを実地検証しておきたい。今回は、現場での検証は別途行うこととして、週1回程度のレビューを1カ月ぐらい繰り返し実施し、細かな修正を行っていくことで最終的にあるべき業務としてまとめ上げた。

ALT 図5 細かな修正を行っていくことで最終的にあるべき業務としてまとめ上げた

　そして、このあるべき業務をもとに議論をすることで、ようやく当初の課題である今回のシステム開発の目的、スコープを確定することができた。

第6章　まとめ

　およそこのような経緯で、業務分析作業はほぼスケジュールどおりに終了することができた。客先での最終報告を終えた帰り道、PMと私は肩を並べて歩いていた。

　「何とか、うまく終了することができましたね」

　「本当だね。このくらい大規模な業務分析作業はなかなか難しいものだね」

　「最初にお話をお聞きしたときに、正直なところ私が参加してうまく回せるだろうかと不安に思いました。でもお客さまも協力的でしたし、大変だったけど、とても良いプロジェクトだったと思いますよ」

　「本当だね。また今度このようなプロジェクトがあったときにはよろしく頼むよ」

　「こちらこそよろしくお願いします」

　今回は、業務分析作業の実際の姿を、現実に即した形で紹介した。このプロジェクトでは、当初システム化を行う目的や範囲があいまいであったが、業務分析を行うことで、それを明確にし、関係者間で合意することができた。また、ヒアリングでは発見できなかった事業全体を貫く重要な問題点を発見することもできた。最終的には、顧客が納得するあるべき業務の姿を明確にすることができたと考えている。

　この後は、システム開発プロジェクトに向けてのRFP（Request For Proposal：提案依頼）を作成し、ベンダ選定を行う段階に進む。開発ベンダが決まれば、システム開発プロジェクトが始まり、システムが提供する機能やインフラ構成の定義といった、いわゆる要件定義や基本設計の段階に入っていく。いよいよIT技術者が主役として活躍する場面の始まりである。しかし私は要件定義の1つ前段階の業務分析プロジェクトにおいても、IT技術者が参加すべきであると考える。

　なぜなら、業務分析の後半段階で立案する施策は、ITを活用する場合が少なくない。こうした施策を「絵に描いた餅」にしないためには、IT技術者の知見が不可欠である。また業務分析に続くシステム開発段階においても、業務の意義や重要性を理解したメンバーが参画していれば、実現する機能を決める際のトレードオフ判断もより的確になるだろう。そしてビジネス上の意義の理解は、システム開発が成功し、無事カットオーバーしたときの喜びと達成感をさらに高めてくれるはずである。

　そう、だからこそ、IT技術者が、業務分析の主役になるべきである。

「事例で学ぶビジネスモデリング」バックナンバー
前のページへ 1|2|3|4 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ