情報戦略モデル研究所（ISMリサーチ）メルマガ・バックナンバー

第３８０回「整流化課題との関係」

2012-01-24T11:21:05Z

～ＩＴコンサルタント養成講座～

第３８０回「整流化課題との関係」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。
　
　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「整流化課題との関係」を取り上げます。

　前号までの2回で現状業務プロセスの課題の整理を述べてきましたが、
　現状課題には業務プロセスの「整流化」課題が関係してきます。
　この課題改善は現状業務プロセスの課題と関係してきます。
　整流化の課題は2重の業務処理の課題に近い。

　一般に、企業の業務プロセスは整流化されているのですが、「どこの部門の業務ミッションか
　が決まっていない」や「ミッションは決まっていても処理が遅い」などの課題要因によって、
　余分の業務処理が付け加わってしまい業務フローに逆の流れが発生することにあります。
　この整流化課題まとめ方は、現行業務の中であるべき業務機能を定義することで
　2重業務をあぶりだすことができます。

　DFDで記述した業務機能をもとにDMM（Diamond Mandara Matrix）で上位階層から、
　8つずつの業務機能を階層化してレベル３まで定義していくことです。
　そうして、分解されたあるべき業務機能を現行の業務機能と対比することで
　容易に整流化阻害要因をはじき出すことができます。
　はじき出された余分の業務機能は、しかるべき業務機能グループに機能改善要因として
　課題定義をしていくことになります。
　そうして、整流化業務プロセスの改善課題を抽出します。

　今日はここで終わります。次回は「整流化と部門ミッション」を取り上げます。

【大寒】二十四節気の第二十四。１月２１日ごろ。
　寒さが最も厳しくなるころ。『暦便覧』では「冷ゆることの至りて甚だしきときなれば也」と
　説明している。寒（小寒 - 立春前日）の中日で、一年で最も寒い時期である。
　武道ではこのころ寒稽古が行われる。
　大寒の朝の水は1年間腐らないとされており容器などにいれ納戸に保管する家庭が多い。
　（ウィキペディア）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

【弊社サイトのコンテンツご紹介】
　★今までの全てのメルマガバックナンバーを閲覧できるようにしました。
　　こちらです⇒ http://www.ism-research.com/mail-mag/mail-mag/
　★弊社のIT経営研修コース体系です。
　　こちらです⇒ http://www.ism-research.com/course/course-chart.html
　★弊社のIT経営の関連テキスト本です。
　　こちらです⇒ http://www.ism-research.com/book/book-menu.html
　★ITコーディネータ試験対策のテキスト本と研修コースです。
　　試験対策本⇒ http://ism-researh.heteml.jp/book/itc-book/
　　研修コース⇒ http://ism-researh.heteml.jp/course/course-9.html
　★お客様内での研修コース実施要領です。
　　こちらです。⇒ http://www.ism-research.com/course/post-20.html#search_word=
　★「経営改革のイロハ」（大蔵財務協会）の出版本です。
　　こちらです。⇒ http://www.zaikyo.or.jp/bookshop/products/product/626
　　著者割引で購入される場合はFAXで注文です。“著者の澤村氏の紹介です。”
　　と記入してFAXしてください。ＦＡＸ先：０３－３２６４－１７０６
　　大蔵財務協会税のしるべ編集部部長斉藤博之殿

【協業パートナー募集】
　◆弊社でのサイトを活用して研修コースやコンサルコース等を販売されませんか？
　　弊社のインフラがありますので簡単に安価に販売が可能になります。
　　弊社掲載の管理会計のコースはその例です。
　◆弊社で実施の「IT経営研修コース」の販売パートナーを求めています。
　　もし、協業をご要望の方がございましたら、ご案内させていただきます。
　　パートナ募集お問い合わせはこちらでご返信ください。 ⇒ inouemas@axel.ocn.ne.jp

　★メルマガの配信停止は次のURLをご参照ください。
　　こちらです⇒ http://www.mag2.com/m/0000118350.html

　　　　　　　-+-+-+-+-+-+-+-+-+-+-+-+-+-+-================★
　　　　　　　　　　　　　　　　（有）情報戦略モデル研究所（ＩＳＭ研）
　　　　　　　　　　　　　　ITコーディネータ協会認定研修実施機関
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　代表井上正和
　　　　　　　　　　　　　　　　　e-Mail：inouemas@axel.ocn.ne.jp
　　　　　　　　　　　　　　　URL：http://www.ISM-Research.com/
　　　　　　　-+-+-+-+-+-+-+-+-+-+-+-+-+-+-================★

第３７９回「業務プロセス課題のまとめ方-2」

2012-01-24T11:19:41Z

～ＩＴコンサルタント養成講座～

第３７９回「業務プロセス課題のまとめ方-2」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。
　
　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「業務プロセス課題のまとめ方-2」を取り上げます。

　前号で現状業務課題の優先度付けについて述べました。
　今回はこの優先度の妥当性の検証について述べておきます。
　現状業務課題の優先度付けは現行の部門責任で配点をしてもらいますが、
　多くの課題に重要課題という優先度の高い配転がされることが一般的です。
　最上位の優先度課題のみを取り上げても、数多くの対応すべき課題が出てきます。
　全社的な観点から見えないわけですから、
　自分のところの課題が一番大変だという意識で配点することになるからです。

　さらに課題を絞り込み、より必要な課題をどうやって整理するか？
　客観的な指標が必要になります。
　当方が実施した例を述べておきます。優先度カテゴリーを設定しました。
　たとえば、3つのカテゴリーとして「顧客に関わる課題」、「取引先に関わる課題」、
　「社内の部門に関わる課題」を設け、優先度付けをします。
　「顧客に関わる課題」が優先度を最も高く設定し、最優先課題とします。
　次が「取引先に関わる課題」、優先度が最も低い課題が「社内の部門に関わる課題」です。
　顧客の課題でも2分類して優先度を付けます。
　優先度の高い順に「顧客に直接的に関係しミスを発生させる」、
　そして「顧客に間接的な関係があり顧客満足度を低下させる」の優先順位付けをします。

　同様に、「取引先に関わる課題」の課題は、「取引先に直接的に関係しミスを発生させる
　取引先に間接的に関係があり満足度低下を及ぼす」。
　
　「社内の部門に関わる課題」は、「他部門に直接的に関係し身オスを発生させる」、
　「自部門の業務に関係する正確性、迅速性に関わる」として分類します。
　この分類で、6段階の分類ができることになります。
　顧客の環境によっては、この6段階の順序が変わることがあるかもしれません。
　優先度の高い課題をさらにこの6段階で優先度を配分し、
　整理することでより適切な対策が可能になります。

　今日はここで終わります。次回は「業務課題の最終的なまとめ」を取り上げます。

【小寒】小寒とは寒さが最も厳しくなる前とか、寒さが加わる頃という意味で、
　いわゆる『寒の入り』のことで１月５日ごろを指します。この日から寒中見舞いを出し始めます。
　小寒後15日で大寒に入り、大寒後15日で、寒が明けます。
　小寒から節分までが寒の内と呼ばれています。
　寒の内とは一年の内最も気候の寒い季節のことで、
　暦の上の寒の内が実際には気温の最も低い季節です。（越前屋）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７９回「業務プロセス課題のまとめ方-2」

2012-01-24T11:09:08Z

～ＩＴコンサルタント養成講座～

第３７９回「業務プロセス課題のまとめ方-2」

2012-01-24T11:09:08Z

～ＩＴコンサルタント養成講座～

第３７８回「業務プロセス課題のまとめ方-１」

2012-01-24T11:00:25Z

～ＩＴコンサルタント養成講座～

第３７８回「業務プロセス課題のまとめ方-１」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。
　
　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「業務プロセス課題のまとめ方-１」を取り上げます。

　業務プロセスの課題については、以前のメルマガで取り上げましたので
　思い出す程度の解説を加えながら進めていきます。
　現行業務プロセスの課題の分野として7分野を挙げました。「人手作業」、「情報の停滞」、
　「2重処理」、「データフロー媒体」、「業務ルール」、「データオーナー権限」、「プロセスの整流化」です。

　現行業務の改善でヒアリングして把握できる課題は、「人手作業」、「情報の停滞」、「2重処理」、
　「データフロー媒体」、「業務ルール」の5点です。「データオーナー権限」、「プロセスの整流化」の
　課題は前者の5つの課題の分析作業の結果出てくる改善課題です。

　今日は前者の5つの課題分野の整理について述べておきます。
　ヒアリングしてきた課題を整理始めると、次の2つの観点での整理が必要になることに気付きます。
　◆1点目は、課題分野ごとにヒアリング時に記述した内容をいかなるキーワードで整理するか。
　　　課題の意味を理解するときの識別が分析には必要です。
　◆2点目は、この識別された課題はどんな悪い結果をどの程度及ぼすのか。
　　　課題の悪さ度合いを表す指標となります。
　1点目のキーワード整理から述べておきます。
　
　たとえば、「人手作業」の課題分野でも、「作業の負荷が増える」、｢作業ミスがでる｣、
　「処理漏れが起こる」、「連絡漏れが出る」など現データではいろいろです。
　これらの課題がどんな悪い結果を及ぼすかの観点で見ますと、ほぼ「作業負荷増大」と
　「作業ミス発生」の2つの観点に集約されます。
　経営的視点で見ますと「顧客満足度の低下」、｢コスト増大｣の2点に整理されます。
　この課題の整理は、「現データのキーワード化」、「悪い結果への集約」、
　「経営視点での整理」の3段階のステップを通して整理できることがわかります。

　2点目の「悪さ度合い」についての整理について述べておきます。
　1点目で述べた「悪い結果への集約」された課題には悪さの度合いを
　割り当てることが必要になります。
　悪さ度合いのレベルを3段階位に数値化して表示するとわかりやすくなります。
　「経営視点での整理」では、「悪い結果への集約」の悪さ加減を参考にして
　「顧客満足度の低下」、｢コスト増大｣に対する影響度合いをレベル化して配転し、
　両方の合計値を対処優先度の評価として活用することになります。

　たとえば、3段階レベルを設定した場合、「顧客満足度の低下」が「3」、
　｢コスト増大｣が「3」であれば合計値は「６」となり最優先対処課題であり、
　合計値が「２」であれば優先度の最も低い課題項目になるというわけです。

　今日はここで終わります。次回は「業務プロセス課題のまとめ方-2」を取り上げます。
　今年のメルマガは今日で終わりです。1年間のご愛読ありがとうございました。
　来年も皆様方にとって、より良き年でありますように。

【正月】古来より1年の最初の日（一年の始まりの日）である1月1日「元日」は、
　全てのものに命を与えてくれる"歳神〔としがみ〕様"をおまつりするための
　特別な行事が行われていました。
　1948年に「年のはじめを祝う日」として法律で国民の祝日と制定されました。
　「元日」は1月1日のこと、そして「元旦」というのは1月1日の朝の事です。
　「元」という字には「一番初め」という意味があり「旦」という字には
　「あした(朝)」「夜明け」という意味があります。
　古来から行われてきた元日の風習は、現在でも受け継がれています。
　今でも私達は歳神様をお迎えするために門松を門の前に飾ったり、
　鏡餅を備えたり、前日に準備したおせち料理を食べたりしています。
　また、子供は親や親戚からお年玉をもらいます。
　元日から2日にかけてみる夢のことを「初夢」といいます。
　最もよい夢は、「一富士二鷹三茄子〔いちふじにたかさんなすび〕」である、
　と駿河〔するが〕（現在の静岡県辺）の国のことわざにあります。
　富士山は日本で一番高い山、鷹は足高山（愛鷹山）のことで、　これは駿河で二番目に高い山です。
　また、茄子は正月になると驚くほどの高値で売られていました。
　これら3つに共通して言えるのは、全て「高い」という言葉が入っていることです。
　この言葉は縁起が良いとされていました。
　その他にも、縁起の良い夢をみるためには「宝船」の絵を枕の下にいれて寝ると
　良いなどと言われています。ぜひ実践してみてはいかがでしょうか。（日本文化いろは辞典）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７７回「ユーザーフレンドリーなWFAの書き方」

2012-01-24T10:51:40Z

～ＩＴコンサルタント養成講座～

第３７７回「ユーザーフレンドリーなWFAの書き方」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「ユーザーフレンドリーなWFAの書き方」を取り上げます。

　以前のメルマガでWFA(Work Flow Architecture)というEA(Enterprise Architecture)用語
　を紹介しましたが、業務フローを部門に位置付けて記述した部門間業務フロー記述書です。
　当メルマガでは「業務フローマトリクス」という表現で平易に呼び変えています。
　
　この業務フローマトリクスは、ユーザーが業務内容を検証するには必須の記述書です。
　ユーザーが確認するのですから、専門的な記号や用語はまず使用しないほうがよいでしょう。
　業務フローの検証を依頼されたユーザーはどんな視点で業務フローを検証するか。
　そのための留意点を若干述べてみます。
　① 作業に必要なインプットとアウトプットは適切か
　② インプットとアウトプットの情報入手部門と情報媒体は適切か
　③ アウトプットの作成様式は適切か
　④ 業務の作業区別として手作業または機械化の区別ができているか
　⑤ 業務処理の業務ルールは適切か
　⑥ 業務の成果物の宛先部門は適切か
　⑦ 業務を担当する部門は適切か
　などがあります。
　これらの項目について、ユーザーにとって誤解のより尐ない記述を心がけることです。
　たとえば、
　① インプット情報は作成する部門で作成媒体を加味して、提供部門へ矢印を付ける。
　　　たとえば、加味媒体は「紙」の表示、ＴＥＬは「電話」のマークを使用するなどです。
　② 業務フローマトリクスを業務階層別に記述する。
　　　部門のサイズ部、課、係と業務サイズを一致させることです。
　③ 業務の手作業では「筆記の図柄」、機械化は「ＰＣの絵」を使用すると一目瞭然です。
　④ インプット、アウトプットとともにDFDで使用したDF(データフロー)の表示はできるだけ減らす。
　　　部門での作成媒体に名称を付け、宛先に矢印を付けることで理解が容易になります。
　⑤ 作成様式や、業務ルールは蔑視として一覧表を作成しておけば良いでしょう。
　　　ユーザーが特別な勉強をしなくても理解できる図としての表示を心がけることが
　　　業務要件のミスを最小化するもっとも近道であるといえます。
　今日はここで終わります。次回は「業務プロセス課題のまとめ」を取り上げます。

【冬至】(Winter solstice)
　二十四節気の一つで、北半球では太陽が最も低く、夜が最も長くなる日。
　天文学的には、天球上の黄経270度の点を太陽が通過する時。
　この日に、柚子[ゆず]湯に入り小豆粥や南瓜[かぼちゃ]を食べると、　
　風邪をひかないと言われている。
　古代には、冬至を1年の始まりとしていた。
　その名残で、現在でも冬至は暦の基準となっている。
　太陽太陰暦では、冬至を含む月を11月と定義しているが、19年に1度、
　冬至の日が11月1日となることがあり、
　これを「朔旦冬至」と言う。朔旦冬至が正確に19年周期で訪れることは、
　暦が正確に運用されている証であり、それは政治が正しく行われているということであるとして、
　朔旦冬至は盛大に祝われた。
　これまでで最後の朔旦冬至は1995年、次の朔旦冬至は2014年である。

　
　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７６回「支援業務DFDの取扱」

2012-01-24T09:51:44Z

～ＩＴコンサルタント養成講座～

第３７６回「支援業務DFDの取扱」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「支援業務DFDの取扱」を取り上げます。

　業務フローを分析するときに業務には基幹業務と支援業務があり、
　「支援業務は如何に記述するのか」が問題になる場合があります。
　ここでいう支援業務とは総務、経理、人事、企画、品質管理など、
　作業そのものがお金を稼ぐわけではなく、会社運営のための間接的業務です。
　支援業務も業務プロセスはあり記述することは可能ですが、
　基幹業務あっての支援業務ですので、事業強化の観点より
　経営リスクの観点に重点が置かれることになります。
　例として、基幹業務に近い営業管理業務を取り上げてみましょう。

　営業管理業務には、顧客管理、受注残管理、契約管理、請求管理、
　予算実績比較など営業活動にかかわる管理活動が含まれます。
　これらの内容は、職制で実施するものと独立業務として実施する業務が混在するものです。
　企業のDFDレベル０にある販売業務の受注業務のDFDには、
　受注管理があり予算と実績管理は組み込まれますし、
　請求業務においても請求管理が発生しています。
　＊＊課レベルでは職制でのコントロールが大きくなりますが、
　部や本部レベルになってくると営業管理としての支援が必要になってきます。
　
　DFDの記述では、基幹業務のモニタリング業務として組み込まれた業務が
　この営業管理の業務になってきます。
　DFDのレベル１ですと受注業務モニタリング、出荷業務モニタリング、
　請求業務モニタリングといった予算と実績管理の業務プロセスとなります。
　ここは独立的なモニタリングとして間接業務をとらえたがよいでしょう。
　もう1段DFDレベルが下がると、受注入力モニタリングや在庫引当モニタリングという
　レベルになってきますので、職制でのモニタリング業務としてDFDを記述したほうが適切です。

　いづれにしても、経営戦略は基幹業務プロセスの改革に焦点が当たります。
　支援業務はこの改革を如何に迅速に正確に情報把握して、
　経営陣や管理者にフィードバックできるかが業務プロセス構築の目標になります。
　今日はここで終わります。次回は「ユーザーフレンドリーなWFAの書き方」を取り上げます。

【大雪（たいせつ）】
　山の峰々に雪がかぶり、平地にも雪が降る頃。
　雪はまさに冬の象徴といえますが、雪を見つめる眼差しに、日本人の美学が垣間見えます。
　降り積もる雪も、やがては消えてしまう儚さに愛しみを感じさせます。
　その雪の結晶は六枚の花びらをもつ花のように美しいものですが、
　儚さを封じ込めるかのように「六花（りっか）」という名前がついています。
　また、「風花」といえば晴れた空から舞い落ちる雪のことですが、
　それは、山に降り積もった雪や雪雲から風にのって流されてきた雪のかけら。
　すくい取ろうとしてもすぐにとけてしまう、幻の花なのです。
　雪の結晶を研究し、随筆家としても有名な中谷宇吉郎は、
　雪の結晶を見れば上空の状態がわかることから、こんな言葉を残しました。
　「雪は天から送られた手紙である」と。（環境goo）

　
　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７５回「業務プロセス記述体制」

2012-01-24T09:23:20Z

～ＩＴコンサルタント養成講座～

第３７５回「業務プロセス記述体制」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「業務プロセス記述体制」を取り上げます。

　実際に業務フローのコーチングでヒアリングを始めてみますと、
　全社的または事業内の業務プロセスを把握できている方はかなり限られてきます。
　課長、部長のレベルでも意外と少ないと感じられるはずです。
　そうすると、全社的な業務プロセスを記述するには、
　現場である事業部の下位レベルからまとめることになります。
　
　実際の業務フローを記述する事業部とそのとりまとめを行うプロジェクト本部の両頭体制が必要です。
　事業部のレベルからスタートするのですから、全社から見ればDFDレベル１からのスタートになります。
　階層レベルはDFDレベル０の「1.0」、「2.0」、「3.0」、・・・からスタートではなく、
　DFDレベル１の「1.1」、[1.2]、「1.3」、・・・からのスタートになります。
　事業部のレベル１は「販売」、「生産」、「物流」、・・・といったレベルになりますが、
　事業間やレベル1の業務機能間に関係するデータフローとマスターファイル
　そしてデータフロー発生のルールを明記することが必要です。
　このDFDレベルで、事業部間や外部（顧客や取引先）に関係するデータフロー
　およびマスターファイル名称とIDの事業部間整合性を業務ルールを踏まえ検討し、
　合議のうえで確定していきます。
　
　本部では、事業の最上位レベル１のDFDからデータフロー名称、
　マスターファイル/トランザクションファイルを確定し、共通化していきます。
　こうすることで、本部は全社のDFDレベル０を積み上げて作成することが可能になります。
　事業部のDFDレベル１（全社のレベル２）以降のDFD記述は
　事業部に記述ルールに沿って任せればよいのですが、
　レベル2までは事業部内で業務機能レベルを検討し、DFD記述の標準化を図るのが重要です。
　全社レベルのDFDレベル３までは、
　本部主導で記述標準化を図るのに検証会議を開催していくことです。
　今日はここで終わります。次回は「間接業務DFDの取扱」を取り上げます。

　【雑感】先日、永平寺の開祖である道元の話を聞いていました。
　　禅と言うのは生活宗教であり、道元が著した「正法眼蔵」には「修証一等」と言うことが
　　書かれているそうです。
　　「修」とは修行のことで「証」とは悟りのこと。「一等」とは同じという意味で、
　　「修行すなわち悟り、悟りすなわち修行」と言うことらしいです。
　　修行して、悟ろうと思うように手段と目的を分離するから悩みが出る。
　　手段と目的を一体化すると悩みは無くなるそうです。
　　こんなことを教えてくれるのも、日本だけのようです。
　　本家の中国では、文化大革命のときすべての寺院が破壊され、
　　僧侶は免職になったらしいです。最近の文化・経済開放政策に則り、
　　日本へ仏教の勉強に来ているということのようです。少し驚きました。
　
　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７４回「DFDの記述ルールの捉え方－課題キーワードの標準化」

2011-12-04T12:42:07Z

～ＩＴコンサルタント養成講座～

第３７４回「DFDの記述ルールの捉え方－課題キーワードの標準化」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「DFDの記述ルールの捉え方－課題キーワードの記述」を取り上げます。

　全社的なプロジェクトとして、分担してDFDの記述をするとき、
　その調査時に発掘する課題はいかに記述していくかを取り上げます。

　各自業務や部門に任せていくわけですから、課題の記述ルールと表現の標準化が必要になります。
　以前プロセス課題の４つの要因として、手作業、媒体、2重処理、情報停滞をあげましたが、
　分析用として記述するには課題の詳細レベルの定義をしておく必要があります。
　なぜなら、手作業としての課題をとらえても、この手作業は、「負荷がかかる」のか、
　「インプットのミス」になるのか、「処理漏れ」を発生させるのかなど、出てきます。
　そのままにしておきますと、“どの課題に該当するか不明”というのが、続々と出てきます。

　対処法としては、手作業の下位構成にある上記の課題例をできる限りあげておき、
　4つの課題要因を補完説明しておくこと。そして、課題の方針を明確にしておくことです。
　当職の例では、最上位の方針として「顧客や取引先に迷惑をかける事象」と
　「作業の負荷を増大させる事象」の2点を掲げました。
　上記に該当する事象は、定期的に討議し新しい詳細課題として定義していくことで解消できます。
　課題としてとらえる最上位方針と標準キーワードを設定することで、
　課題抽出の漏れが少なくなったと思います。

　今日はここで終わります。次回は「DFDの記述の実施体制」を取り上げます。

　【勤労感謝の日】「瑞穂の国」の祭祀。瑞穂とはみずみずしい稲穂のことである。
　　勤労感謝の日が制定される以前は、「新嘗祭」が行われていました。
　　新嘗祭は古くから国家の重要な行事であり「瑞穂の国」の祭祀を司る
　　最高責任者である大王〔おおきみ〕(天皇)が国民を代表して、
　　農作物の恵みに感謝する式典でした。「新嘗」とはその年収穫された新しい穀物のことをいいます。
　　農業中心の時代、この行事はとても重要な儀式でした。
　　「勤労感謝の日」は1948年に定められましたが、この日を制定するにあたっては、
　　元々の「新嘗祭」として祝いたいなど様々な意見があったようです。
　　しかし「労働」とは本来「農業に従事して生産を行うもの」だけを言うのではなく、
　　今日のサービス産業なども含めた幅広い意味を持つことから「新嘗祭の日」という考えは却下され、
　　現在の「勤労感謝の日」が制定されました。（日本文化いろは辞典）
　
　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７３回「DFDの記述ルールの捉え方－IDnoの採番」

2011-12-04T12:35:11Z

～ＩＴコンサルタント養成講座～

第３７３回「DFDの記述ルールの捉え方－IDnoの採番」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「DFDの記述ルールの捉え方－IDnoの採番」を取り上げます。

　全社的な業務プロセスを把握するプロジェクトでは、多くの部署の参画が必要になります。
　そうするとDFD記述にかかわる標準化の問題が出てきます。
　今日は、DFDのIDnoの記述標準について述べておきます。
　
　DFDの記述には、プロセスボックスのIDno、データフローのIDno、データストアのIDnoが
　主要なIDnoとしたあります。
　プロセスボックスは階層に従って、「１．０」、「１．１」、「１．１．１」とルール化されていますので
　問題ありませんが、DFnoやDSnoはDFDルールにはなく独自の標準化が必要です。
　たとえば、データフローのDFnoはよく連番で採番しますが、追加のフローが出てくると頓挫します。
　後になればなるほど、修正時の負荷が大変になるからです。
　
　工夫としては、階層単位に連番基準を持つ場合もありますが、
　当方では部門IDを入れて5ケタ連番を使いました。
　たとえば、A事業部であれば、スタートは“a”のIDを付けて2ケタ目の10からスタートします。
　そうしますと、a00010、a00020、a00030、・・という採番ルールを作りました。
　この記述ですと、9999のデータフローを記述できることになります。
　全社の業務フロー統合時に、各事業部の識別のために付けた“a”を外す処置をとりました。
　対象業務がもっと大きい場合は6ケタ採番をとればよいと思います。
　後で修正が出ても、10個のDFを追加することが可能ですので、修正箇所を限定して
　ユニークなIDnoとして維持できます。

　DFのIDnoはこのルールで時事業部ごとの現場に任せることが可能ですが、DSnoは別の問題があります。　　
　DSのIDnoは連番の色彩は弱くなりますが、事業部に任せるのは無理があります。
　本部や企画室で、現在活用しているマスターやファイルを洗い出し、ナンバリングしておくことが必要です。
　マスターとトランザクションファイルの区別をして、2ケタで採番しておけばよいでしょう。

　今日はここで終わります。
　次回は「DFDの記述ルールの捉え方－課題キーワードの記述」を取り上げます。

　【小雪：しょうせつ】二十四節気「小雪」
　　１１月２２日１９時１５分「小雪」です。旧暦１０月、亥（い）の月の中気で、立冬後１５日目。
　　小雪とは『寒さいまだ深まらず、雪いまだ大ならざるなり』の候、
　　すなわち小雪とは「雪はさほど多くない」という意味です。
　　暦便覧では「冷ゆるが故に雨も雪と也てくだるが故也」と説明しています。
　　本格的な降雪はないものの、山嶺の頂には白銀の雪が眺められる頃です。
　　紅葉は終りを告げ寒さは徐々に厳しくなり、冬の到来を感じさせられます。（八木宏之ブログ）
　
　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７２回「DFDの記述ルールの捉え方－WFAの記述ポイント」

2011-12-04T12:26:52Z

～ＩＴコンサルタント養成講座～

第３７２回「DFDの記述ルールの捉え方－WFAの記述ポイント」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「DFDの記述ルールの捉え方－WFAの記述ポイント」を取り上げます。

　前回のDFD記述法でWFA（Work Flow Diagram）について若干、述べました。
　部門間の業務フローを記述するもので、横軸に部門名称、縦軸に業務名で囲まれた
　マトリクスの中に業務フローを記述したものです。
　当職はWFAと言うより業務フローマトリクスと呼んでいます。

　この特徴は、DFDが分析用記述であるのに対し、業務フローマトリクスはユーザーに
　確認してもらうための記述図として活用するのが有効です。
　業務フローマトリクスに統合したツールをよく見かけますが、分析用記述を加えていくと
　どんどん込み入った図になっていき、ユーザーにわからない図とならないように留意する必要があります。

　留意点です。
　① DFDのプロセスボックスに部門名を記入しておくことをお勧めします。
　　　業務フローマトリクスとの連携が容易に取れるようになります。
　② 業務フローマトリクスはユーザーフレンドリーに記述するべきです。
　　　たとえば、「手作業か」、「IT処理か」が見て区別できること。DF(Data Flow)はなるべく
　　　記述しないでわかるようにすること。
　③ フローチャートで使用するようなコンピュータ向け記号は使用しないことです。
　　　政府のEAプロジェクトの失敗の中で、その要因の一つはWFAがコンピュータ向け記号を
　　　使用したことです。

　メーカーにしか分からない図になってしまい、ユーザーの確認が困難であったことがあります。
　たとえば、出力帳票は帳票の図を使い、TELは電話の絵を使うことです。
　「判断」は業務のルーとして業務ルール表としてまとめることです。
　人手による業務は人の絵を使い、ITによる処理はPCの絵を使えばよいでしょう。
　業務フローの検証はユーザー部門にやっていただくしかないわけですから、
　ユーザーフレンドリーに一目でわかる業務フロー図にすることが肝要です。

　今日はここで終わります。次回は「DFDの記述ルールのとらえ方－ID採番」を取り上げます。

　【年中行事：七五三】11月15日。七五三は子供の成長を祝い、
　　子供自身にもその自覚を与えるためのものです。子供に持たせる千歳飴には、
　　子供が元気によく成長するよう、また長生きするように、という願いがこめられています。
　　[髪置き、袴着、紐落し、帯解き]
　　古来の七五三の形は「髪置き〔かみおき〕」、「袴着〔はかまぎ〕」、「紐落し」、「帯解き〔おびとき〕」と
　　呼ばれ、各地各様に男女とも行われていました。
　　髪置きは2～3歳の間に行われ、その日を境にそれまで剃って短いままだった子供の髪を伸ばし
　　始める儀式でした。袴着は3～7歳の子供が、初めて袴〔はかま〕をつける儀式でした。
　　紐落しは5～9歳の間に、それまで着物を留めるのに使っていた紐を帯に変える儀式で、
　　帯解きとも呼ばれました。
　　昔は医療・衛生的に未発達で乳幼児の死亡率が高く、成長する子供は幸運とされていました。
　　そのため｢七つ前は神のうち｣といわれ、7歳未満の子はまだ神に属するものとされ、
　　神がその運命を決めると考えられていました。
　　そこで人々は数々の儀礼を行うことで、子供の無事な成長を祈りました。
　　そして7歳の祝いはその不安定な時期を乗り越えた節目の儀礼であったため、
　　特に7歳の祝いを重視する地方は多かったようです。（日本文化いろは辞典）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７１回「DFDの記述ルールの捉え方－要件記述法」

2011-12-04T12:14:53Z

～ＩＴコンサルタント養成講座～

第３７１回「DFDの記述ルールの捉え方－要件記述法」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。
　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「DFDの記述ルールの捉え方－要件記述法」を取り上げます。

　業務プロセスの課題として何をとらえるか？
　以前のメルマガで述べましたが、業務プロセスを構成する業務機能は組織ミッションと重なります。
　一番大きな問題は業務機能が複数の部門で実施されていることによるムダ作業がありました。
　この原因には作業の困難さ、組織構造、人の力関係、企業文化、意識などの問題がありますが、
　見える形にしない限りは問題の解決への進展はありません。

　それでは「業務プロセス課題の見える化」のための課題をとらえるDFDでの要件記述法を考察します。
　◆DFDの処理ボックスには部門名を記述する
　　　この処置はエンドユーザーに業務処理記述を行ってもらうために必須の措置です。
　　　処理ボックスには部門名を記述することで、部門間の業務フロー（WFA：Work Flow Architecture）
　　　への変換が容易になりゆーざーと設計者の検証が容易になります。

　◆DFDに処理ボックスへの入出力のデータフロー（DF）に時間差をつけて記述する。
　　　入力のDFは出力のDFにあるわけですから、入力DFの下段に出力のDFを記述するようにする。
　　　この記述では処理業務の停滞が見えます。停滞の時間を記述すれば、その課題を分析可能です。

　◆DFの媒体を記述する。
　　　業務処理をする際の間違いの大きな原因になります。
　　　たとえば、紙やEXCELで来た入力DFを人で登録して出力のDFを作成する。
　　　そうすると、間違いの種ができる。また、通常はIT 化されているはずなのに
　　　そういった手作業が発生している場合も出てくる。
　　　ITが有効に機能していないことの原因もある。

　◆業務プロセス階層ごとの業務課題を分類する
　　　顧客や取引先といった「対外的な課題」、事業部にある部門間の重複や
　　　部門伝達上の「部門間課題」、部内での業務処理の負荷や作業標準等の
　　　「部門内課題」などに分類して整理することで、原因の掘り下げができる。

　◆業務機能の業務ルールを記述する
　　　この記述は課題ではありませんが、DFDの弱点を補うのに必要な処置になります。

　以上の業務フロー要因を記述することで、業務フローの清流化が可能になり、
　あるべき業務ﾌﾛｰ来つつとして展開することができます。

　今日はここで終わります。
　次回は「DFDの記述ルールのとらえ方－構造化とネーミング」を取り上げます。

　【立冬】11月8日頃（2011年は11月8日）。霜降から数えて15日目頃。立冬とは、冬の始まりのこと。
　　朝夕冷えみ、日中の陽射しも弱まって来て、冬が近いことを感じさせる頃。
　　木枯らし１号や初雪の便りも届き始めます。
　　立冬を過ぎると、初霜が降りて冬の佇まいへと変わります。この日から立春の前日までが冬。
　　木枯らし・凩晩秋から初冬にかけて吹く、冷たくやや強い風。
　　気象的には、10月半ばから11月末にかけて西高東低の冬型の気圧配置の時、
　　最大風速8m/秒以上の西北西から北向きの風のことをいいます。
　　「凩」という文字には、風が吹くたび葉が落ちるため、木を枯らしてしまう風という意味があります。
　　（日本の行事・こよみ）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３７０回「DFDの記述ルールの捉え方－記述範囲」

2011-12-04T05:38:28Z

～ＩＴコンサルタント養成講座～

第３７０回「DFDの記述ルールの捉え方－記述範囲」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「DFDの記述ルールの捉え方－記述範囲」を取り上げます。

　業務フローの記述手法はいくつもあることを前述しました。
　ここでは、当職がよく活用しているDFD（Ｄａｔａ Flow Diagram）手法を例にとって
　記述ルールでの考慮点を述べていきたいと思います。
　最初に、記述範囲について記述しておきたいと思います。
　
　コンサルや講義をしていてよく質問されますのが、
　“どこまで、どんな範囲で記述すればよいのですか？”の質問が出てきます。
　この質問に答えておきましょう。
　この質問に対する回答は、業務分析の深さと記述要素を抑えないといけません。
　業務プロセスの階層化のところで業務分析の深さについては若干触れていました。
　業務粒度として成果物が１つになるレベルまでです。
　業務プロセス階層レベルで言うと、業務階層レベル４の位置になるのが一般的です。
　業務プロセスの分析記述は事業戦略目標と業務改革・改善方針があって開始します。

　このスタートレベルが階層レベル０でした。もう一度思い出してみましょう。
　階層レベル１：販売、生産、物流といった事業機能の業務粒度
　階層レベル２：受注生産、見込み生産・販売などの事業機能の実施形態による階層レベル１の
　　　　　　　　　　業務粒度
　階層レベル３：販売を例にとれば、受注、発注、出荷などの業務粒度の業務プロセス
　階層レベル４：受注を例にとれば、受注受付、在庫引当、出荷指示など
　に階層化されました。

　業務改革方針がありますと改革の対象となる業務分野は階層レベル１，２で決まるはずです。
　対象外の業務はどうするか？
　階層レベル１、２の事業機能間のデータフローの記述は必須です。
　理由は事業を遂行する業務の整合性と情報の関係は抑えておかないと、
　設計後事業機能間の連携が取れなくなる場合が出てくるからです。
　
　階層レベル３，４は改革対象の事業機能分野として詳細化していきます。
　当然、改革対象でない業務機能の箇所でも業務間のデータフローは常に抑えて、階層化することです。
　今日はここで終わります。次回は「DFDの記述ルールのとらえ方－記述法ポイント」を取り上げます。

【霜降】二十四節気の一つ。寒露から１５日目頃。
　　初霜が降りる頃という意味。
　　霜降七十二候の初候は「霜始めて降る」です。
　　（参考）「七十二候」（しちじゅうにこう）とは、各節気を三分して
　　一年を七十二候にし、時候の変化を示したものです。
　　霜降は
　　初侯「霜始めて降る」（しもはじめてふる）
　　二候「小雨ときどき降る」（こさめときどきふる）
　　三候「楓蔦黄ばむ」（もみじつたきばむ）
　　頃と解説されています。
　　七十二候は自然や気象の変化、動植物の活動などを表しています。
　　早朝には霜を見るようになり、虫の声も弱々しくなってきます。
　　三候は「楓蔦黄ばむ」（もみじつたきばむ）で、
　　カエデやツタの葉が色づく頃です。
　　葉がきれいな赤や黄色に変色する条件に、朝晩の
　　冷え込みや霜が関係しています。
　　朝の最低気温が１０℃以下になると紅葉が始まり、
　　気温が低くなるほど色鮮やかになるといわれています。（和のこころ）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３６９回「業務機能要件定義の考慮点」

2011-10-21T23:52:25Z

～ＩＴコンサルタント養成講座～

第３６９回「業務機能要件定義の考慮点」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「業務機能要件定義の考慮点」を取り上げます。

　業務機能や業務プロセスは事業毎に業務遂行の手続きとして決まります。
　新規事業の業務プロセスを定義する場合を除けば、合理化してもその形態は
　変化することがありますが、同機能は残ることになります。
　この業務機能は経営リスクとしてプロセス分析対応する場合も必須の機能になることは
　前号で述べました。そうすると、

　業務機能や業務プロセスは何を如何に定義すればよいのかが重要になります。
　お客様に伺ってみて、ときどき見受けますのが業務プロセスの記述が入出力のフローに
　なっていることと階層化で最小単位の業務機能に落とされていないことに気付きます。
　階層化の定義がなく、単なる入出力フローですと課題が見えてこないことと汎用化ができません。
　折角、事業目標に向けて業務フローを作成したにも関わらず、ISMSでそのための業務フローをつくり、
　内部統制でまた別の業務フローを作成することになってきます。

　業務プロセスの現状分析の例で考えてみましょう。
　業務プロセス、業務機能をまとめるとき、8つの要件が必要であることは以前紹介しました。
　この要件とは、「前状態（この処理へのトリガー）」、「後状態（後処理へのイベント）」、「入力データ」、
　「出力データ」、「資源（ファイル等）」、「組織（担当部門）」、「業務ルール」、
　「シナリオ（事業、対象次章）」でした。

　この要件を整理するには、業務改革方針が必要です。
　実戦での業務プロセスの現状分析は業務改革方針のもとに現状とのギャップ課題を掴んでいき、
　「整流化」、「業務オーナ」を決めました。
　
　つまり、業務フローを分析する時には、課題を掴む記述ルールが必要になってくることになります。
　今日はここで終わります。次回は「DFDの記述ルールの捉え方」を取り上げます。

　【雑感】
　　あまりにも有名になりましたが、“Stay Hungry、Stay Foolish”
　　Steve Jobsがスタンフォード大学の卒業式のスピーチの最後に残した言葉。
　　強烈な印象を与えました。
　　もうひとつのメッセージ。
　　「もし、今日が自分の最後の日だとしたら、今日やろうとしていることを私は本当にやりたいだろうか？」と。　　　
　　その答えが「NO」である日が続くなら何かを変える必要がある。
　　日本を含めて世界には多くに偉人がいますが、
　　Steve Jobsも“死せる孔明、いける仲達を走らす。”ほどのインパクトを感じました。

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

第３６８回「業務フロー記述の考慮点－シナリオと業務フロー」

2011-10-21T23:19:39Z

～ＩＴコンサルタント養成講座～

第３６８回「業務フロー記述の考慮点－シナリオと業務フロー」

　皆さん、おはようございます！当メルマガを担当しています井上正和です。

　コンサルやワーキンググループ等、現場で実践していて感じていることからテーマを取り上げます。
　今日は「業務フロー記述の考慮点－業務定義」を取り上げます。

　2008年4月の内部統制実施に向けて「内部統制のための3点セット」として、
　業務フロー記述の需要が盛り上がった一時期がありました。聞くところによると、
　その時の文書はほとんど利用されていないようです。
　記述文書は、EAで用いたWFA（Work Flow Architecture）で部門間の業務情報を
　記述した図です。内部統制でしたから財務アサーションに関わる会計に関わるデータの記述でした。

　会計情報に関する情報記述ですから内部統制だけにしか使えない業務フローです。
　ここで、尐し疑問が湧きませんか？
　この対応をしていますと、業務フローがシナリオ単位に出来てきて業務フローの山になります。
　また、異なるベンダーや異なる人が指導すれば、互換性のない業務フローが出来上がります。
　業務フローが求められるシナリオは数多くあります。
　経営改革に向けた業務改善、ISO9000対応、ISMS対応/Pマーク対応、BCM対応、
　内部統制等多岐に亘りますので、すべて対応すれば“監査倒産を招く”と
　言われるのも納得のいく話しです。

　1つの業務フローで対応するにはどうすればよいのか？
　基本は「定義する最終業務粒度を定める」、そして「各業務粒度毎に業務機能要件を定義する」
　の2点であると思います。
　最終業務粒度は以前のメルマガでも述べましたが、ユーザーが業務に必要な最小単位です。
　別の言い方をしますと、業務に必要な最小単位とは目に見える一つの成果物が出来る業務単位です。
　事業部目標から階層化し、このレベルの定義を行うことでシナリオ別の業務フロー記述は不要になります。
　業務の最小単位になっていますので、この業務機能に業務機能要件を定義するだけになります。

　「シナリオの変更は業務要件を変更することで、業務機能が変化するようにすればよい」
　と捉える事が必要と思います。
　今日はここで終わります。次回は「業務機能要件定義の考慮点」を取り上げます。

　【寒露】二十四節気のひとつで10月8日頃（2011年は10月9日）。および霜降までの期間。
　　秋分から数えて15日目頃。
　　寒露とは、晩夏から初秋にかけて野草に宿る冷たい露のこと。
　　秋の長雨が終わり、本格的な秋の始まりになります。この頃になると五穀の収穫もたけなわで、
　　農家では繁忙を極めます。
　　露が冷たい空気と接し、霜に変わる直前で、紅葉が濃くなり、燕などの夏鳥と雁などの冬鳥が
　　交代される時期でもあります。
　　この頃は、大気の状態が安定して空気が澄んだ秋晴れの日が多くなります。
　　夜には月も美しく輝いて見えます。寒露の頃になったら、空を見上げてみてはいかがでしょう。
　　これまでと違った、秋の清々しさと趣を感じる空に出会えるはずです。
　　天明八年の「暦便覧」には、「陰寒の気に合って、露むすび凝（こ）らんとすればなり」
　　と記されています。（日本の行事・暦）

　【新着情報】
　　★現場主導の全社業務改革のコースを開催します。
　　　　「現場主導の全社業務改革基礎知識」コース
　　　　⇒ http://www.ism-research.com/course/transformation/dk30.html
　　★プロジェクトマネジメントのコースを開催します。
　　　　「実践プロジェクトマネジメント基本」コース
　　　　⇒ http://www.ism-research.com/course/project-management/pk10.html
　　★戦略会計、管理会計コースを実施します。
　　　　経営者向け「安心経営のための管理会計」コース
　　　　⇒ http://www.ism-research.com/course/post-24.html
　　★コーチングを開始します。
　　　　「業務プロセスの見える化」のコーチング
　　　　⇒ http://www.ism-research.com/consult/ojt.html

情報戦略モデル研究所（ISMリサーチ）メルマガ・バックナンバー

第３８０回 「整流化課題との関係」

第３７９回 「業務プロセス課題のまとめ方-2」

第３７９回 「業務プロセス課題のまとめ方-2」

第３７９回 「業務プロセス課題のまとめ方-2」

第３７８回 「業務プロセス課題のまとめ方-１」

第３７７回 「ユーザーフレンドリーなWFAの書き方」

第３７６回 「支援業務DFDの取扱」

第３７５回 「業務プロセス記述体制」

第３７４回 「DFDの記述ルールの捉え方－課題キーワードの標準化」

第３７３回 「DFDの記述ルールの捉え方－IDnoの採番」

第３７２回 「DFDの記述ルールの捉え方－WFAの記述ポイント」

第３７１回 「DFDの記述ルールの捉え方－要件記述法」

第３７０回 「DFDの記述ルールの捉え方－記述範囲」

第３６９回 「業務機能要件定義の考慮点」

第３６８回 「業務フロー記述の考慮点－シナリオと業務フロー」

第３８０回「整流化課題との関係」

第３７９回「業務プロセス課題のまとめ方-2」

第３７９回「業務プロセス課題のまとめ方-2」

第３７９回「業務プロセス課題のまとめ方-2」

第３７８回「業務プロセス課題のまとめ方-１」

第３７７回「ユーザーフレンドリーなWFAの書き方」

第３７６回「支援業務DFDの取扱」

第３７５回「業務プロセス記述体制」

第３７４回「DFDの記述ルールの捉え方－課題キーワードの標準化」

第３７３回「DFDの記述ルールの捉え方－IDnoの採番」

第３７２回「DFDの記述ルールの捉え方－WFAの記述ポイント」

第３７１回「DFDの記述ルールの捉え方－要件記述法」

第３７０回「DFDの記述ルールの捉え方－記述範囲」

第３６９回「業務機能要件定義の考慮点」

第３６８回「業務フロー記述の考慮点－シナリオと業務フロー」