業務改善への提言 2009-01-06T10:44:10Z Copyright 2007 WordPress maida01 http://www.office-aida.com/modules/wordpress/index.php?p=72 2007-08-25T14:52:03Z 2007-08-25T14:52:03Z 企業情報

業務分析サービス 現状業務フロー作成 理想的業務フロー討議・作成 改善提案作成 システム要望/システム化提案作成 ＩＴ関連 システム化計画サイクル策定 システム化コンセプト構築 システム要求作成 ベンダー選定 外部設計検討 設計書作成 業務フローとの付き合せ 導入テスト IT導入テスト 業務フローとの総合テスト プロジェクトマネージメント 情報システム部門改善

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=71 2006-01-29T00:52:52Z 2006-01-29T00:52:52Z IT有効活用 要求定義の改善

　システム開発で業務分析が大切だと言われながら、SIer、システム 開発会社の開発標準で、業務分析の必要な場合、不要な場合が例示され ていません。 　結果、業務分析の目的、必要性、位置付けが不明瞭になっています。 業務分析が必要な場合を、規定したい、システム開発において、何でも カンでも業務分析が必要なわけではない、というのが当文章の趣旨です。 　システムは、業務の中で使われて、業務の一部として機能すべきものです。 従って、システムへの要求を決めるのは、業務プロセス、業務フローを 決めてからになるはずである。業務プロセスが決まっていないと、システム への要求が決まりません。 　最近は、業務が既にシステム化されている場合が多い。従い、システム開発 といっても、現行システムの改修が非常に多い。 　システム改修では、既にある画面、データ内容、チェック方法の改善など、 お客様の要求が具体的である。また、業務プロセスは既に詳細まで定義されて いて、システム改修でも大きな業務プロセス変更にもならないことが多い。 　こういう場合には、業務分析は不要です。 　大きく業務プロセスを変更する、または新規のシステム開発などの場合に、 業務分析が必要にます。但し、これらの場合でも、お客様が業務プロセスを充分に 理解していて、システム化後の業務プロセスを理解されている場合には、業務分析 は不要になります。 　但し、お客様が自社の業務プロセスを理解して、システムへの要求を出される 場合が非常に少ないのも現実です。システム開発の要求定義段階で業務分析が 必要になる場合が多々あります。 　つまり、業務分析が必要になる場合は、お客様が現行業務プロセスを理解して いない、システム化後の新業務プロセスを明確にする場合に、業務分析が必要 になる。 　 　システム開発における業務分析とは、 現行の業務プロセスを明確にし、 それを改善するためのシステム化要求を決定し、 新業務プロセスを組み立てる ことです。 システム要求を決定するので、要求定義工程で実施します。 　業務分析が必要な場合は、お客様が業務プロセスを明確にできない時です。 　新規業務などでは、お客様が業務プロセスを簡単には決定できないのも事実です。 業務プロセスを最終化できずに、システム開発を開始してしまい、後で大きな変更 になる場合も良くあります。業務プロセスの決定を待っていると、開発期間がドンドン なくなってしまい、見切り発車で開発を始めなければいけないことが良くあります。 　タイミング、リスクの認識、注意が必要です。 　システム開発の最終に近いテスト段階になって要求の変更が多々あるプロジェクト を良く見かけます。 　これは、お客様が業務プロセスを詳細化せずにシステム要求を作成し、システム サイドはこれを信じて開発を実施し、システムが見え始めてからお客様が業務と 合わないと気付き、システムへの変更を要求してくる、という流れです。 　要求の明確化と同時に、要求が本当に業務プロセスと合致しているかの確認は 必須です。システムは業務の流れの中で使われて、初めて役に立つのですから。 　業務システムはシステムだけで動くのではありません。 　業務システムは、業務の一部として使われて、初めて力を発揮します。

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=69 2006-01-07T10:00:59Z 2006-01-07T10:00:59Z 業務改善の方法

　業務フローの書き方の説明が必要だったようです。 　アクセスログを見ると、多くの方が、”業務フローの書き方”という検索結果から、 当サイトに来ています。 　フローの書き方より分析の方が重要だと思っていましたが、フローの書き方に興味が ある方の方が多いようです。今までは、業務プロセスの分析方法、改善策の作成について 書いてきましたが、業務フロー図の作成方法について説明します。 　ここでは、業務プロセスは判っているとの前提で業務フローの書き方だけに付いて説明 しています。従い、業務プロセスの抽出方法などは説明しません。 基本 　業務フロー図には、フローを書き出す枠組みとフローに組み立てるための工程記号が必要です。 　枠組みとは、部門/担当者などの枠（レーン）です。各プロセスを実施する部門などを長い 枠でくくり、これを必要分だけ並べます。水泳のレーンのようなので、スイムレーンとか、 単にレーンとか呼びます。これが、横書きでは横長になり、縦書きでは縦長になります。 　工程記号とは、プロセスとか帳票を表す記号です。これを組み合わせて業務フローを書き 表します。 　書き方は横でも、縦でもかまいません。他のドキュメントとの関係で決めます。最近は パソコンで書くためか、横書きが多いようです。 レーンのサンプル 縦書きの場合 横書きの場合 　いずれも、Visioで作成しました。ここまではVisioを使うとフローチャート、 部門連携フローチャート、横方向/縦方向と言う順番の選択で簡単に作成できます。 　このような図は、Visioでなくとも、PowerPointやExcelでも簡単に作成できます。 　レーンは、業務の主な部門/担当者は細かめに作成し、主でない部門などは大まかに 作成します。 　日時レーン：時系列を示すレーンを端に作る（横書きであれば上に、縦書きであれば左）。 処理日、経過日数/時間など記入し、該当する下とか横にプロセスを書き込みます。 　システムレーン：システムを利用している場合は、またはシステムを検討する場合は、 時系列とは反対側にシステムレーンを作る（横書きでは下、縦書きであれば右側に）。 主なシステムと関連システムとか内部と外部のシステムなどがある場合は、システムレーン を２つ使用します。 　誰にでも判りやすいという意味では、使用する工程記号は減らすべきです。産能大の 業務フローの書き方では、沢山の工程記号を使用し、慣れていない人には判り難いように 思っています。工程記号が多いと、工程記号の説明、理解が面倒です。 　判り難い部分は、工程記号の多用でなく、コメントを付ければ良いでしょう。 　利用する工程記号は、プロセスボックス、帳票、データベース（PCなどに保存する場合）、 台帳（マスターファイル）などで充分です。これらの工程記号を矢印（接続線）で結んで フロー図を作成します。システム機能はプロセスボックスでも良いですが、システムを明確に 分けたい場合に利用します。 　プロセス数が多い場合は、プロセス番号を付けるべきです。プロセス番号は、プロセス ボックスの脇に付ける方法と、プロセスボックス上部を横線で区切ってプロセス番号を書く 部分を作る方法もあります。 　システム機能も多い場合は、システム番号を付けるべきです。 　分岐の条件とか、特別なメモなどは、接続線の脇や工程記号の脇にメモ書きとして書き 加えます。 　各工程記号の内にプロセス名とかシステム機能名、帳票名などを記入します。業務フローを 見る関係者が、内容を理解できる名前を付けます。 　お客様番号など、業務プロセスとして重要な肝のナンバリング方法などとか、特定処理内容 の注意書きなどは、フローとは別ページで説明すべきです。 業務フロー図記述ツール 　本来は手書きでも良いのですが、作成後の修正、転用などを考えると、当然パソコンでの フロー図作成ツールを使うべきです。いまどきパソコンを使わないで、手書きはないです。 　関係者全員が利用している、利用できるツールを選ぶべきです。現在は企業のパソコン 利用ではMSオフィースが、多いと思いますから、ツールもMSオフィース系を使用すべきです。 PowerPoint ・通常ですと、PowerPointが描画ツールです。 ・まあ普通の作図ツールで、誰でもが書きなれています。 Excel ・意外と作図には適していて、IT系ではよく利用されます。印刷する用紙の大きさを意識せず 　に書け、フロー図が大きくなった時にも、そのまま書いていけます。多くのSEが、Excelで 　業務フローを作成しています。 ・Excelの上に図を書く方法でなく、セルを1つのプロセスと考える書き方で、業務フローを 　Excelで作成することもあります。 Word ・業務フロー図を書くのは適切ではないです。Wordは、あくまでドキュメント作成ツールで 　すから、作図には向かないと考えています。 ・Wordのドキュメントに統一するためには、PowerPointなどで完成させてから、全体を 　Wordにコピーすることはあるかと思います。 Visio ・MS系では、Visioが本来の作図ツールですが、MS Officeというパッケージには含まれ 　ていません。 ・しかし作図ツールですので、フローチャートだけでなく、グラフ、ネットワーク図、 　機械設計、電気設計などいろいろな図の作成に利用できます。利用にはVisioの購入が 　必要ですが、Visioで作成した図を見るだけならば、マイクロソフトのWebサイトから 　無料で参照プログラム（Visio Viewer）をダウンロードできます。 　したがい、フロー作成者だけがVisioを購入はあるかと思います。 ・Visioでは、工程記号もステンシルということで付属しています。必要な記号だけを 　ステンシルとしてカスタマイズも可能です。他のツールではフローチャートから選択 　します。 ということで、作図には、MS Office系では、PowerPoint、Excel、Visioが利用可能です。 書き方 　まず、書くツールと横書きか、縦書きかを決める。決めたツールで、プロセスを拾い出し てボックスに書いていく。 　業務フローの書き方を悩んでいる人が多いですが、とにかく書いてみるべきです。想定で 書いて直していくべきです。単に悩んでいるのはダメです。とにかく書き出していくべきです。 　レーンの中に、左から右へ、上から下へ時系列に流れる様にプロセスを、つなげて書き出 します。 　レーンを始めに用意して、プロセスを書き出していく方法でも、プロセスを書き出してから、 レーンに移す方法でもフロー図になります。 　書き出したものを、業務を知っている人に聞いて、相談して修正して、洗練し、全員で納得の 行く業務フローを作り上げます。 　処理のかたまりでの流れを作っていきます。このかたまりがプロセスで、大きさも問題になり ますが、とにかく書き出すことです。 　工程記号を使って、きっかけ、プロセス、帳票などを時系列に書き出して、矢印記号で接続し ていきます。 　プロセス間を行き来する情報/帳票名の明記が必要であれば、接続の線上にでもメモする。 　電話、メール、郵便、手渡し、FAXなどの情報の伝達手段が決まっている、もしくは明記し ないと判らない場合は、接続線の上にメモ書きにする。 　プロセス全体の始まるきっかけが帳票であれば、フローチャートの帳票記号を使う。 　その業務プロセスの最終成果物が帳票などであれば、帳票記号で記入し、その帳票を作成 するプロセスと線で接続します。 　各プロセスボックス、帳票工程記号を担当の部門レーンに入れる。 　特別な注意書きを付けたい場合は、該当するプロセスボックスなどに*1などと付記して、 欄外に*1として注意書きを書く。 　こんな風に書いていくと、用紙に入りきらなくなります。１つのフロー図には、10個程度 のプロセスにすべきです。 　ページが2、３であれば問題ないですが、これ以上ですと見難く判り難いです。 　幾つかのプロセスをまとめたりして、プロセスの粒度の検討をすべきです。 　業務の全体像を大まかに書き表す業務フロー図と、各詳細プロセスフロー図に分けると、 ページに入る、入らないの問題は解決します。 　一般的に、業務概要は1枚にまとめ、各業務詳細を個々のフロー図にします。この方が、 大局からの理解もでき、上位マネージメントへの説明、実務者との検討などでの使い分けが できます。 　プロセスが多い場合には、概要と詳細を3段階とか4段階にすることもあります。 工程記号 業務プロセスはボックスに 　プロセスボックス内には、プロセス名だけで内容が判る場合はプロセス名のみ、判らない 場合はスペースがあれば作業内容を書く。スペースがなく、明記必要であれば、注釈にする。 　ボックスは一人の人が連続して処理する論理的なかたまり（業務、仕事、処理）を１つの単位 として書く。 　一人の人が連続して処理していることを、細かく分けない。 　但し、休みなく働くということではなく、あくまでも論理的なつながりの単位です。 　 　論理的につながっていない仕事は、別なボックスにする。 　または通常は違うフロー図になるはずです。 　システム機能はボックスでも、角の取れたボックスでもいい。 ボックスには機能名を記入（誰でもが内容を想像できるような）する。 　情報のかたまりはコンピュータフローチャートで使う帳票マークで記入。 　ボックス、帳票などを時間的流れを線で結ぶ。連続した論理的な業務のかたまりを単位として フロー図を書いていく。 　同じフロー図に、全く違う業務を書き込まない、違う業務は別のフロー図に書き出す。 　1つのフロー図には、通常10個程度の業務プロセスボックスを書き出す。多くなった場合には、 ページを分ける。 　フロー図が長くなった場合は、論理的なかたまりに代表的な名前を付けて、レベル分けをする。 詳細は別の1枚のサブのフローとして書き出す。 　何らかの判断でプロセスボックスが分岐する場合は、接続線上に分岐条件を書き出す。 でも、本当は 　業務フロー作成自身よりも、重要、難しいことがあります。 ·業務プロセスの拾い出し方 ·業務プロセスの粒度（レベル）そろえ方 ·インタビュー方法 ·業務改善の方法 ·業務フローを書く目的の明確化は重要です 業務分析でできること ·仕事の品質、コスト、作業時間の改善 ·業務改善 ·業務全体の可視化 ·関係者全員で業務の全体像の共有することで品質改善、作業者のモチベーション向上 以下も重要です。 ·通常、担当者は、自分の担当部分しか判らず、全体での位置付けを理解していない。 ·担当者のモチベーションを向上し仕事の品質の改善できます。 ·担当部分の業務の全体での位置付けを理解することで、担当者のモチベーションをあげる。 ·単にやらされるだけの仕事では担当者のモチベーションは上がりません。 ·自分の仕事の全体への位置付け、必要性が判って、担当者のモチベーションはあがります。 ·モチベーションをあげることで、仕事の品質が上がります。 ·前工程、次工程を理解することで、自分の仕事を改善して、業務全体の改善効果をあげていきます。 以上、業務フローの書き方だけと思いましたが、以外の部分にも触れてしまいました。

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=68 2005-12-04T22:00:23Z 2005-12-04T22:00:23Z 業務改善の方法

　以前ご紹介した 米国生産性品質センター(APQC)の 　提供しているProcess Classification Frameworkを翻訳していましたが、 　偶然、日本能率協会コンサルティングの翻訳が既にAPQCのサイトにあるのを 発見しました。 　企業の一般化した業務プロセスの一覧表です。非常に詳細なリストです。 　業務プロセス構築、改善、見直し、また業務プロセスの勉強などに役立ちます。 　経営者、マネージメントの方々は、もっと業務プロセスのあり方を考えて、 　業務品質、仕事の品質の向上をはかるべきです。 　誰でも利用できるようです。是非、ご一読ください。 　当社では、PCFを別な形態にすることによる利用方法を検討していきます。

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=67 2005-11-29T23:38:05Z 2005-11-29T23:38:05Z 業務改善の方法 業務分析方法論

　初めて、業務分析方法論を開発したときの話です。 　1993年始めに、当時勤務していた会社で、業務フロー作成ツールを利用 して、お客様の業務フローを作成しました。 　非常に便利なツールだったので、実際に業務をしている人にインタビュー して、最終的にフローが生成できます。 　数人の部下が、出来たあがったフロー図を見せてくれました。 しかし、問題があるとの話。 　フローは出来たが、何処の、何が問題か、どうか改善すべきかが判らない という問題でした。米国本社でも、ツールの使い方、インタビューの方法 などはガイドがあります。しかし、分析そのものについての方法がありません。 　一人が、図のある部分が花火のようになってるんですよね、と言い出した。 これだと、思い付いたのが方法論の始まりでした。 　花火のようになっている部分は、幾つもの前後の処理から１つの処理に、 情報、用紙などが沢山集まって、沢山の処理をしている部分でした。 　調べると、1つの処理で、複数の処理をしています。いろいろな知識、スキルが 必要な複雑な処理です。１つの処理を複数の処理に分解、マニュアルの用意など によって、処理の単純化が可能になりました。 　他にも、フローを図として見るだけでも、部門間で処理が行き来している部分、 処理がループしている部分、単純に処理が連続している部分など、図として見た だけでも、問題の可能性、改善の可能性の発見出来ることが判りました。 　それぞれには、そのような図になる理由、改善の可能性の説明が、常識で考えれば 判ります。 　それから、これらを方法論としてまとめ、業務フロー作成ツールと業務分析方法論 のセットでお客様へ営業しました。方法論とて紹介することで、お客様にスキルを 理解して頂くことも出来ました。 　常識的判断を、順序立ててで説明することで方法論になります。説明されると、 当り前だよなと思われますが、方法論は、特別な魔法ではなく、順序立てた理屈の 積み上げです。 　真面目に解決方法を考えて、組み立てれば何事も解決できます。

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=66 2005-11-03T19:34:44Z 2005-11-03T19:34:44Z IT有効活用 要求定義の改善

　システム開発の上流工程の始めは、要求定義なのか要件定義なのか？ 　自分自身でも、去年までは、要求定義と要件定義をいい加減に使っていた。 全く意識せずに、要求定義と言ったり、要件定義と言ったりしていた。 　最近、システム開発のQAerをさせてもらい、要件定義のドキュメントに お客様の要求を一覧表に書き出した部分が殆どなく、何か変だなと思い、 要求定義、要件定義について調べ始めた。 　現在は、IBMのADSGが一番身近なので、これを調べることから始めた。 驚いたことに、お客様の要求を書き出す部分が非常に薄い。 　要件定義がDFDから始まる。 　私は、DFDはシステム分析が基本だと考えている。 　要求分析には向かない。 　本来、要件を出す始めは、お客様の要求なはずだ。 　昔のシステム開発の初めには、お客の要求を一覧表化し、一つひとつに ついて、具体的に何をしたいのか、どうすればシステム化できるのか、 それぞれの優先順位は、などと一覧表に付け加えていき、最終的に優先順位に 従った開発をしたものです。 　最近の開発では、このパートのドキュメントを殆ど見かけない。 検討作業は実施しているのでしょう。ドキュメント化していないだけで しょう。 　などの問題意識から、要求定義、要件定義などを調べ始めた。 　CMMや幾つかの書籍から、やっと自分なりの回答を得た。 　まず、言葉の問題。 　要求と要件の使い分け、そして要求の前に要望があると考えるべきだ。 お客の言っているのは、要求でなく、要望が殆ど。 システム開発につなげるには、要望を要求というレベルまで明確に 　しなければいけない。 要求はお客様の言葉で語るべきもので、システムがイメージできるレベル 　までに落とすべきだ。 お客様をまじえて、要求に優先順位を付ける。 要求が明確になったときに、初めてシステム屋としてのシステム要件の 　定義に入る。 この段階では、お客様の要求だけでなく、システムとして装備しなければ 　いけない要件（非機能要件、品質要件など）の追加が必要になる。 最終的には、再度優先順位を付けて、開発の範囲が確定する。 　要するに、お客は要望を言っているので、それを要求と言うレベルまで 詳細化/具体化し、その後システムとしての要件として決定する。 　最近のＣＭＭでも言及されているように、要件定義の前に要求開発が必要で、 その後に要件定義になる。 　　要望−＞要求−＞要件 と言うのがシステム要件を決定するまでの流れになる。 　次回はもっと詳細に。 参考資料 ・若手SEのための要求仕様のまとめ方(Amazon.co.jpへ) ・要求を仕様化する技術・表現する技術 -仕様が書けていますか?(Amazon.co.jpへ) ・Software People Vol.4(Amazon.co.jpへ) ・能力成熟度モデル®統合CMMI 連続表現

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=65 2005-10-26T20:32:20Z 2005-10-26T20:32:20Z 業務改善の方法 業務分析方法論

　システム開発では、問題が山積です。 　問題の半分は要件定義関連です。 　お客様の業務が判らないから、要件が決まらないという話を良く聞きます。 　要件定義で業務分析をすると決められている開発方法論はたくさんありますが、 業務分析の方法が規定されていません。 　多くの開発方法論で、要件定義工程での作業がDFDに重きがおかれています。 DFDも必要でしょうが、DFDはシステム分析が主体です。 　通常のDFDでは、業務分析にはなりません。 　昔のように、業務をよく理解しているSEがいるときは、業務分析は不要でした。 　また、開発のベテランは、業務を知らなくとも、業務分析の方法を知っていたので 問題ありませんでした。 　最近のように、業務も判らない、業務分析の方法も知らないSEが多い状況では、 SEに業務分析の方法を教える必要があります。 　特に、SIer、システム開発会社では、業務ノウハウもなく、業務分析スキルが 必須です。現場SEを助けるために、業務分析手法/方法論を作成しましょう。 　業務分析は、業務フローを書くことではありません。現行業務を分析して、 業務改善案を作り、そこからシステム化案を作ることが、業務分析です。 　手探りで実施する業務分析は効率的ではありません。 業務分析の計画立案から、現状分析方法、業務改善案作成方法までを網羅した 業務分析手法を提供することが、本社サイドから現場のシステム開発プロジェクトを 助ける効果的な方法です。 　本社からプロジェクト進捗状況を要求ばかりするPMOでは、現場のSEを助ける ことにはなりません。 　ベテランのノウハウが詰まった、開発方法論を作成しましょう。 特に他社では用意していない、業務分析方法論は効果的です。 　当社の業務分析手法概要を、当サイトで説明していますが、 １つのドキュメントにまとめました。ご参考に提供しています。 ご要望の方は、ご連絡ください。 　当社の業務分析手法の概要が必要な方は、お名前、御社名、目的などを メール下さい。読後にコメントを頂ければドキュメントを差し上げます。

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=64 2005-10-20T23:01:54Z 2005-10-20T23:01:54Z 業務改善の方法 業務分析方法論

　注文は取れたのに、発送にいつも問題が発生 　毎月の経理処理に、いつも問題がある 　日常業務なのに引継ぎが難しい 　など、定期的に処理している業務に問題はありませんか？ 　業務分析をすべきです。 　何か改善すべき、問題がある可能性があります。 　業務分析をしてください。 　但し、業務フローを書いただけでは、 　　問題の発見 　も 　　改善案の検討 　も難しいと思います。 　何かの参考になればと思い、当社の業務分析の手法をまとめました。 　ご利用の結果、読んでいただいた後の感想などを頂ける方に、差し上げます。 　メールにて、 　お名前、社名、メールアドレス、手法の利用方法、解決したいお悩み、 　などをお知らせください。 　 　個人でご利用になりいた方は、個人と利用目的などを明記ください。 　まとめはPDFにて作成してあります。 　メールの件名に、”業務分析手法希望”と明記ください。 　maida01@yahoo.co.jp まで、メールにてお申し付けください。 　メールにてご返事させてもらいます。 　ご連絡をお待ちしています。 　代表　相田　誠　

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=63 2005-10-17T21:09:56Z 2005-10-17T21:09:56Z IT有効活用 要求定義の改善

　成功しているシステム開発プロジェクトは、非常に少ないそうです。 成功しているのは２７％しかないという記事があります。 　失敗しているプロジェクトの半分は、要求が中々決まらない、または、 システム開発の後半に要求が変化することが問題です。 　他の半分は、開発プロジェクトの管理の問題です。 　要求を明確にすることは、ユーザ企業からも実施できる、 システム導入を成功させるための重要な対抗策です。 　システム/コンピュータは、機械です。ソフトウェアは、コンピュータ の動作を規定する方法です。コンピュータは、ソフトウェアで規定した 通りに動作します。 　ソフトウェア/ソフトを作るには、詳細に仕様を規定しないといけません。 ユーザのシステムへの要求が、その仕様の元になります。 　コンピュータは米国で始まり、発達したものですがら、詳細な規定を ソフトで記述しければいけません。欧米流の契約のように、詳細に全て の規定を必要とします。 　コンピュータが、日本とかアジアで発明されていれば、違った方法を 取った可能性はありますが、現状では要求の明確化は必須です。 　通常は、ビジネスからの要求は中々決まらなく、システム開発がどんどん 遅れ、早く開発が始まっても、途中で要求が変わってきて、システム開発の 手直しが発生することが頻発しています。 　これから数回で、システム開発での、ユーザ要求定義について、解決案の 考察をしていきます。

maida01 http://www.office-aida.com/modules/wordpress/index.php?p=62 2005-10-02T22:36:01Z 2005-10-02T22:36:01Z 業務改善の方法

　米国生産性品質センター（APQC：American Productivity and Quality Center）が 提供しているProcess Classification Frameworkが、今年6月にversion3.0を発表 していました。 　Process Classification Frameworkは、標準的な業務プロセスの細分化です。 業務プロセスのベストプラクティスを調査し、ベンチマーキングするための基準として 定義されたもので、業務分析や経営改革を行う際のリファレンスモデルとして利用 できます。 　この図は、PCFの概要です。 　米国の事例ですが、日本でも業務プロセスの雛型として使えます。 　現在、翻訳中です。近々、ご紹介したいと思います。 　業務プロセス事例を読むことで、業務分析の勉強になります。