中小企業のビジネスプロセスの特徴とBPM の方法 …日本BPM協会...

Aｌｌ Rights Reserved, Copyright© process-design-engineering，Ｉｎｃ1

バリューチェーンプロセス協議会(VCPC) 理事長

㈱プロセスデザインエンジニアリング

中小企業のビジネスプロセスの特徴とBPM の方法、事例

渡辺和宣[email protected]

http://process-design-eng.com

http://vcpc.org/

SCM とIT 経営・実践研究会 2014年12月20日


1 ビジネスプロセスとは何か


ビジネスプロセスとは

50-10-10

A.ワークフロー的定義仕事の手順⇒プロセスを連結して自動化・一つ以上の入力を持ち、顧客に対する価値となる出力を生成する活動の集まり[M・ハマー]・ある特定の顧客や市場に特定の出力を生成するために設計されたある順序を持った活動であり、時間と空間を越え、開始と終了を持ち、明確に特定された入力と出力を持つもの[T・ダベンポート]

B.コーディネーション的定義知識の調整と統合⇒重要なプロセスへ着目・モノや情報の流れではなく、活動に関係する人々の行動を統合するもの[Fフローレス、T・ウィグラード]・ビジネスチャンスに即応するために、企業全体の技術や生産能力をコア・コンピタンスとして統合したもの[G・ハメル、Ｃ・Ｋ・ハメル]

日本BPM協会組織における価値創出過程の基本単位。論理的関連性を持つタスクあるいはアクティビティの集合体で、インプットに価値を付加してアウトプットに変換し、ビジネス・ユニット内外の顧客に届ける。タスク/アクティビティは連続的あるいは並行的に遂行され、その過程で、一連の資材、情報、当該プロセス内外の人員が投入される。これにゲートウエイという判断ルールを加えた流れをワークフローと言う。外部顧客が認容する価値を創出する総合的かつ上位概念のビジネスプロセスを、バリュー・チェーンと呼ぶ。

渡辺の定義モノや情報からなる入力に対して、資源（モノ、情報、知識）を利用して価値を付加して、モノや情報からなる出力を生成する活動のこと。プロセスの開始のもと、実際の活動内容と終了条件は、一定の順序やルールに従う定型的な場合（上記A「作業」)、またはこれを実行する人々の判断によってアドホックな場合(上記Ｂ「意思決定」）とがある。したがって、プロセスは業務手順や作業手順とは異なる。

１．業務プロセスとは何か LINK


ビジネスプロセスの特徴

IT系プロセス人間系プロセス

２．階層構造を持つ

DoD AF2.0

１．業務プロセスとは何か

３．個々のプロセスの機能定義がある（プロセス構成要素：機能、イン、アウト、ルール等）

４．様々なプロセスの種類がある定型的/非定型的、人間系/IT、実行/支援(Enable)、意思決定/作業、戦略/戦略計画/計画管理/業務遂行PDCA（Plan/Do/Check/Action)

50-10-11

１．順序関係がある（定型の場合）

LINK


ビジネスプロセスの種類・タイプ


種類・タイプ説明備考

定型的/

非定型的

定型的：実行するプロセスの順序が決まっており、個人の判断が入る余地が

あまりない（業務ルールが強固）

非定型的：実行するプロセスの順序が決まっておらず、個人の判断が必要とされる

人間系/

IT系

人間系：IT化がされていないプロセス

IT系：アプリケーションソフトウェアによって自動化されたプロセス

実行/

支援(Enable)

実行：それ自体が独立して意味のあるアウトプットを生み出すプロセス

支援(Enable)：実行系を支援するプロセス例) 在庫管理や情報管理

作業/意思決定

作業：予め定められた方針やビジネスルールのもとに、作業を実施する（ほとんど定型的）

意思決定：何らかの決定を行うプロセス。H.A.サイモンの意思決定プロセス

構造化/半構造化/非構造化の３タイプ

[アンソニー]

戦略/

戦略計画/

計画管理/

業務実行

経営のタテのPDCA、

戦略：全社戦略や経営機能別戦略を立案するプロセス

戦略計画（戦術)：まだ曖昧模糊とした戦略をより具体的な戦略計画にブレーク

ダウンする、そして実行後の各戦略計画間の調整を行うプロセス

計画管理：戦略計画を遂行するための計画と是正プロセス

業務実行：計画の実施計画を立案、実行、是正を行うプロセス

人間では

←大脳

←小脳

←神経

←各器官

計画/実行/測定/是正

経営のヨコのPDCA

計画(Plan）、実行(Do)、測定(Check)、是正(Action)

管理（Control)は測定と是正を合わせたもの

例) 計画と管理

50-10-12 LINK


プロセス階層レベルの例と粒度（数）


ﾚﾍﾞﾙプロセス階層の意味数

０事業戦略 --

１経営機能(事業機能）

経営機能の全体を社外ステークホルダを含めて検討する単位

--

２業務機能

業務機能の改革を社内ステークホルダを含めて検討する単位

22

３ビジネスプロセス上位

業務改革をビジネスプロセス改革として検討・設計する単位

337

４ビジネスプロセス中位

プロセス改善を検討・設計する単位、アクティビティと呼ばれる

3,057

５ビジネスプロセス下位

プロセスを実行する単位、

タスク/ITトランザクション

11,630

６トランザクション機能部品

タスクやITトランザクションを構成する単位、アクション/ITコンポーネントと呼ばれる

７システム機能部品（ITクラス、詳細動作)

プロセス数は、見込生産組立型消費財製造業の場合出所：吉原賢治「ビジネスモデル入門」工業調査会

組織例

事業部

製造本部

営業本部

製造部

営業部

生産計画課

営業課

生産計画係

受注係

生産計画者

受注担当者

機能・ビジネスプロセス例

・計画、調達、製造

・見込生産、受注生産機能

・終製品への組立日程計画プロセス

・日程計画における負荷平準案の作成

・生産日程計画における能力負荷調整ｼﾐｭﾚｰｼｮﾝ処理

・ｼﾐｭﾚｰｼｮﾝﾊﾟﾗﾒｰﾀ設定画面

・ｼﾐｭﾚｰｼｮﾝ画面

・結果保存画面

機能・ビジネスプロセス例

・受注・出荷

・在庫品の受注・出荷機能

・受注設計生産品の受注・出荷機能

・在庫引当と納期設定プロセス

・利用可能在庫の引当と納期の特定

・在庫自動引当処理

・利用可能在庫の確認画面

・回答納期確認画面

・在庫引当更新指示

60-01-41 LINK


The BPTrends Pyramid （プロセス階層レベル）

40-04-01EX

Strategy or Enterprise Level

レベル０

レベル１

レベル２

Process Levelレベル３

レベル４

Implementation Levelレベル５

レベル６


出所：渡辺和宣「ビジネスプロセス参照モデルを利用したサプライチェーン改革と情報システム構築の統合（詳細計画フェーズ）」電子情報通信学会、信学技報Vol.106 No.85, 2006 図２に加筆・修正

情報活動

プロセスニーズの把握

プロセス指示情報

タイプＡ

情報活動

プロダクト/リソース準備

制約条件の把握や対象の確認

プロダクトリソース

プロセス制約情報

タイプB

設計活動

選択活動

プロセスの実行結果の確認

プロセスの実行

タイプＣ

プロセスニーズ充足の確定

検討活動

プロダクト/リソース解放

プロセス完了情報

プロダクトリソース

タイプＤ

ビジネスルール

情報ｵﾌﾞｼﾞｪｸﾄ

情報ｵﾌﾞｼﾞｪｸﾄプロダクト/リソース

意思決定者、実行者

情報ｵﾌﾞｼﾞｪｸﾄプロダクト/リソース

① ③

⑤② ⑥

④

製造指図

原材料旋盤

加工処理

部品

②④

プロセス構成要素①プロセス機能 ②インプット③アウトプット ④リソース⑤コントロール ⑥人・組織

後で知ったが拡張UML[Eriksson=Penker]に似ている（目標オブジェクト以外）


H.A.サイモンによる意思決定プロセスをプロセス全体に拡張

業務プロセスにおける６種類の構成要素60-01-30


６．モデリング（目標、ビジネス、ビジネスプロセス、要求、ソフトウェア）

プロセスの構成要素プロセス構成要素の意味例

プロセス番号 4.3.4-6

プロセス名称プロセス名製造・テスト完了(関連情報の更新)

ステークホルダプロセスに関わる利害関係者加工外注先、製造従業員

①目的当該プロセスが必要となる目的製造・テスト完了に伴って、在庫や進捗等の関連情報を更新する。

①機能

(上段）人間系を含めた全て

当該プロセスが実施すべき機能製造完了として、製造進捗やプロダクト在庫に関する情報を更新するプロセス。

(下段)情報システム機能情報システムが支援する機能指図完了処理機能。在庫ｽﾃｰﾀｽの更新処理、会計仕訳処理はシステム側で自動処理、品質管理情報更新機能（シリアル・ロット管理ほか）など。

②インプット０当該プロセスを起動する開始イベント条件

②インプット１プロセスへの指示となるエンティティ（情報）作業指示書(4.3.4-1)

②インプット２制約条件となるエンティティ（情報、プロダクト、リソース）

③アウトプット０当該プロセスが完了した際の終了イベント条件

③アウトプット１プロセスの成果物となるイベント系エンティティ（情報）

製造フィードバック情報<MAKE進捗>(4.3E.03-1)(4.3.2-1)

製造スケジュール（ワークフロー、4.3E.03-1）(4.3.5-1)

③アウトプット2 プロセスの成果物となるリソース系エンティティ（情報、プロダクト、リソース）

資材在庫情報(4.3E.04-1)

仕掛品在庫情報(4.3E.04-2)

完成品在庫情報(4.3E.04-3)

④発生する仕訳当該プロセスで発生する勘定仕訳製品未完成棚卸資産（仕掛）/在庫(資材）、労務費、経費

製品完成棚卸資産（製品)/在庫(資材、仕掛）、労務費、経費

⑤コントロール（ルール）プロセスにおけるビジネスルール製造工程作業手順：完成計上基準(4.3E.01-1)

⑤コントロール（パフォーマンス）プロセスのパーフォマンス測定尺度（SCORより）生産能力活用率他

⑤コントロール（財務報告）財務報告の信頼性の確保のためのコントロール別紙に一覧で記述

⑤コントロール（法規制）法規制の遵守のためのコントロール別紙に一覧で記述

⑥担当責任組織プロセスの実施責任を割り当てられた組織・人生産拠点（工場）生産部の検査課、製造課、外注課

ビジネスプロセスモデルの定義例

800-101


ビジネスルールとは

60-10-60

ロナルド・G・ロス Ronald G.Ross日々のビジネス活動を導くため、ビジネス運用上の判断を形成するため、またはビジネス運用上の決定を行うために使用する基準である。・明確な形を持つ非常に具体的なもの・用語は、ビジネス用語集（ファクトモデル）に基づく・表現は、手続き的ではなく、（結果をしめす）宣言的である

渡辺の定義ビジネス活動の中で、組織や個人が意思決定を行うために準拠する判断や行動のための基準。基準としては、形式知もあれば暗黙知も含まれる。・意思決定の種類⇒業務ルールの目的別タイプ・準拠する⇒業務ルールの構造タイプビジネスルールは、ビジネスプロセスに関連付けられるが、従属ではなく独立している。

BABOK2.0ビジネスの管理下にあり、ビジネスポリシーを支援するため、具体的で実践的でテスト可能な指示。



ビジネスルールの特徴

２．階層構造を持つ

３．ルールの定義形式があるメタモデル例：目的タイプ、目的、

適用プロセス、事前条件、事後条件、構造タイプ、標準（決定、行動）、制約、ガイダンス、他

１．ルールには様々な目的がある前提とすべき事実、制約、起動すべきアクション、対象の状態の定義、計算方法、従うべきガイドライン、ノウハウ

60-10-61

４．ルールには様々な構造がある合否判定、選定、アクション誘導、レベル判定、計算、ガイドライン、標準化されたノウハウ

５．ルールはプロセスからは独立一つのルールが複数のプロセスに適用される



業務ルールのメタモデル

800-103 ６．モデリング（目標、ビジネス、ビジネスプロセス、要求、ソフトウェア）

メタモデル「ルール」のメタモデルの内容説明

①ルールコード

②ルール名

③目的別タイプ業務ルールの目的別タイプ。事実、制約ルール、アクションイネブラー、状態設定、計算方法、ガイドライン、ノウハウなど

④適用プロセス名業務ルールが適用されるビジネスプロセスの名称。

⑤目的なぜ、このルールが必要なのかの目的。

目的、適用場所、適用範囲

⑥適用条件

（事前条件）

どういう状況の時に、このルールを適用するのかの条件（単一、AND､OR)。

⑦完了条件

（事後条件)

どういう状況になれば、このルールの適用が完了したかの条件（単一、AND､OR)。

⑧構造別タイプ業務ルールの構造別タイプ。合否判定、選定、アクション誘導、レベル判定、計算、ガイドライン、標準・ノウハウなど

⑨標準ルール記述のメイン部分、２と３を「入れ子」構造で記述

1. 適用条件までの流れ（省略可）

2. 決定基準(If)

3. 行動基準（Then)

4. 完了条件（省略可）

[ロス]

強制度

ガイダンスメッセージ

違反対応

⑩制約ルールを適用する際の代替ケースや例外ケースを記述。

⑪ガイダンスルール運用の際のガイダンス、未定義の場合の処理

⑫関連ルール、

関連文書名

関連する業務ルール。

関連する、参照する文書名。関連文書・シート名、ITシステムの画面名


2 日本企業とビジネスプロセス

非明示的な管理方式vs「プロセス志向」


日本的経営の特質アベグレンの「日本の経営」他


「プロセス志向」とは

50-10-13

「プロセス志向」とは、ビジネスプロセスを中心に、業務やマネジメントの仕組みを設計して実行すること。（特長）プロセスによって、成果が繰り返し可能な仕組みになる。例)おいしいコーヒーの入れ方

関係者の共通理解ができて、コミュニケーションが改善する。プロセス改善によって、仕組みを進化させられる。機能中心に仕組みを考えることで、人が成長する。

（プロセス志向でないと）仕組みがないため、個人の能力に依存してしまい、成果を継続的に出せない。例）２度とこういう事が起きないように再発防止に努めますという「精神論」で終わる。

「プロセス志向」の使われ方の例★ PDCA (タテ、ヨコ）★ バリューチェーン戦略、サプライチェーン戦略★ 事業リスクマネジメント★ プロセスベンチマーキング★ 業務の見える化★ プロセスからのIT要求開発★ 意思決定マネジメント★ プロダクト品質[ISO]、経営品質[米国MB賞]★ 業務基盤の「適化」 [経済産業省]

LINK


230-022

海外販売会社

日本本社

海外製造会社

調達計画

サプライチェーン全体計画

出荷計画

在庫品出荷

見込生産

在庫品調達

■■製品グループ

調達計画

生産計画

出荷計画

在庫品調達

在庫品出荷データ業務ルール

現状のレベル３プロセス図例230-022

サプライチェーンのレベル３プロセスは、A3 １枚に書ける


60-10-01

業務プロセスへの様々な要求

戦略との整合性

プロセス構成要素①機能、②インプット、③アウトプット、⑤コントロール（ルール等４種類）

重視するプロセス構成要素①機能（効率性）②インプット③アウトプット（有効性）④リソース⑤コントロール（ルール）⑤コントロール（パフォーマンス）

重視するプロセス構成要素③アウトプット（セキュリティ）⑤コントロール（ルール）⑥コントロール（財務報告）

重視するプロセス構成要素③コントロール（ルール）⑤コントロール（法規制対応）


BPM、BPMN、BPMSとは

BPM(Business Process Management)とは経営目標を達成するために、業務プロセスの可視化、分析・設計・開発(Plan)、実行(Do)、

モニタリング(Check)、改善・再構築(Action)により、業務プロセスを構築する経営手法[日本BPM協会]。

どうやって経営目標を設定するかがカギ。シックスシグマでは、これはDefineというプロセス。

BPMにおけるPDCAサイクル出所：ガートナー、飯島氏(2008)

可視化

問題分析

解決案設計

BPMSが備えている機能

BPMS（BPM Suite）とはBPMを実践するためのITシステム。

定型業務プロセスだけでなく、非定型業務プロセスもIT化の対象とする。

MDA（モデル主導IT開発）の実現の

ためのツールともなる。

60-10-00

BPMN(Business Process Model and Notation）とはOMGが開発したワークフローとしてビジネスプロセスを描画するグラフィカルな標準記法。

プロセス機能の詳細化、情報/データモデリングには適していない。


ビジネスプロセスへの要求の階層的定義①

60-10-10

人間系

IT系

BABOKにおける要求

ビジネス要求

ステークホルダ要求

ソリューション要求

ソリューション要求

プロセス階層レベル

０１

２

３

４

５

戦略

業務機能

プロセス

アクティビティ

人間系タスク ITﾄﾗﾝｻﾞｸｼｮﾝ

単純作業系意思決定系

プロセス改革

プロセス改善

プロセス構築 IT構築

戦術

経営機能

ITを利用した意思決定

個別開発ERPﾜｰｸﾌﾛｰ系BPMS

意思決定系BPMS



ビジネスモデル

ビジネスプロセスモデリング

構造化

<ローレベル>

ビジネスプロセスモデル

<ハイレベル>


<ミドルレベル>


２

３

４

５

０

１

業務改革モデル

現状記述モデル

<戦術レベル>

プロセス改革モデル

業務改革モデルを反映

レベル２プロセス分析

レベル２プロセス設計

顧客価値提供モデル


レベル２設計を構造化

レベル３プロセス分析

レベル３プロセス設計


レベル２プロセス課題抽出

レベル３プロセス課題抽出

レベル３設計を構造化

レベル４プロセス分析

レベル４プロセス設計

レベル４プロセス課題抽出


レベル４設計を構造化

レベル５プロセス設計

トップダウンボトムアップ

現状プロセスの調査・記述

上位設計からの構造化

現状プロセスの課題抽出

構造化

+

+

+

レベル２設計の範囲だけ

レベル３設計の範囲だけ

レベル４設計の範囲からさらに絞る

プロセス分析(CSFや根本原因の特定)

プロセス設計(プロセス分析の解決策設計)

構造化

構造化

60-10-12

GUTSY-4 階層的なビジネスプロセスモデリング共通ステップ：現状の記述、上位からの構造化、課題抽出、分析、設計

５．業務プロセス概論とその定義


3 中小企業のビジネスプロセスの特徴

日本的経営の特質のいくつかを継承して


ビジネスプロセスと人（担当）との関係例【大企業】

①ステークホルダ ②プロダクトと情報

③プロセス

社外社内

特定の

顧客

サプライヤ

商社

流通業者

物流業者

産廃業者

銀行

特定の機能部門内の課レベル

協力会社

特定の

資材

部品

MRO品

仕入品

仕掛品

半製品

製品

商品

および情報

レベル３

プロセス

発注プロセス

ビジネスプロセスへ影響する要素

半導体

本社調達本部、工場調達部

サプライヤＴ社担当

ビジネスプロセスにおける職務分担例


ビジネスプロセスと人（担当）との関係例【中小企業】

ヨコの兼務

タテの兼務

構想設計プロセスリサーチ調達プロセス

・・

設計部長（構想設計、基本・詳細設計）設計デザインレビュー主宰

・・

兼務は、複数ビジネスプロセスにまたがる（同一階層レベル、異なる階層レベル）


4 中小企業のBPM事例（レベル４まで）

株式会社今野製作所


プロセス改革後の新レベル２プロセス図

225-201 フェーズⅡ：プロセス上位設計によるプロセス改革企画事例

A２


プロセス改革後の新レベル３プロセス図

235-201 フェーズⅡ：プロセス上位設計によるプロセス改革企画目的：レベル３プロセス設計によるプロセス改革要求のポイントを図示して、組織内で合意形成をはかる

事例

A２


フェーズⅢ：プロセス中位設計によるプロセス改革計画328-301

レベル４プロセス設計プロセスフローチャート（静脈流れ）

事例

A２

目的：現状のレベル４プロセス課題の解決、およびプロセス改革要求（レベル３）の実現のため、レベル４プロセスフローを設計する


事例

A２

見積・受注出荷・顧客サービスのIT化


5 中小企業のBPM事例（レベル５）

株式会社今野製作所


BPMツールを利用したレベル５プロセス定義(記述・分析・設計・IT化）

目的：レベル４設計からレベル５プロセ設計を行う・非定型業務→同時にIT化が完了・定型業務 →この要求からIT化に着手

２．業務シナリオを選定、レベル５分解レベル４プロセス設計から、業務シナリオを選定して、レベル４プロセスをレベル５に分解する（業務イベント分解法などにより）例）見込顧客特定、事前調査、訪問・・・・・

(1)レベル４設計に基づき、BPMツール上に、個々のレベル５プロセスと必要なルール、データ・情報を設計する

(2)①を業務シナリオに含まれる全レベル５プロセスについてプロトタイプを作成する

(3)プロトタイプは複数を作成して、選定

３．BPMツール上にプロトタイプを開発

４．ワークショップを開催し、プロトタイプを検討

(1)関係するメンバによるワークショップを開催(2)出席メンバでプロトタイプを検討

自分の現状の仕事の仕方を思い浮かべて＝現状調査・記述を省略画面上の新レベル５プロセスを検討＝情報項目(順番も）、参照ルールなどの設計改善案を提案

(3)直ちにプロトタイプを変更・・・・・すぐにプロトを変更できる場合(4)後日にプロトタイプを修正・・・・・修正案を検討してプロトを修正

フェーズⅣ：プロセス下位設計によるプロセス改革実施

これが、新レベル５プロセスとなる

425-002

１．レベル４プロセス設計を確認


レベル５プロセス定義方法(例）①

Ｋ製作所では、戦略や経営課題を受けて、レベル２～４へと階層的にプロセス定義（現状の記述、分析、設計）を行った。特に、レベル４プロセスでは、論理設計として以下を明確にしてある。(1)業務シナリオ別のプロセスフロー(2)個々のプロセスについて・・・・プロセス詳細記述書①主なプロセス機能②インプットやアウトプットの情報エンティティの主要属性③整備すべき業務ルール、およびその概要

このレベル４プロセス設計を基にして、作業の実行レベルであるレベル５プロセスを定義した。レベル４設計が定まっていなければ、右往左往してしまっただろう。

フェーズⅣ：プロセス下位設計によるプロセス改革実施425-003

１．レベル４設計を確認、業務シナリオを選定

この範囲や方針は、前フェーズでレベル４プロセス設計として完了済み

プロセスフロ｜

プロセス詳細記述書

事例

A２



２．業務シナリオを選定、レベル５分解

(1)レベル４プロセスフローから、業務シナリオを選定①顧客サービス、②通常返品、③修理受付、見積・受注、修理完了・出荷、④クレーム受付、引取調査、報告、⑤代品出荷・引取、⑥欠陥の修正

(2)レベル４プロセスをレベル５に分解業務イベント分解法を利用して、レベル４アクティビティから、レベル５タスクに分解し、フローを描いた。イベント候補①開始/中断/終了のトリガー

②処理名が変わる③インプットのエンティティ名が変わる④アウトプットのエンティティ名が変わる⑤適用する業務ルールが変わる⑥プロセス実行担当者が変わる

レベル５分解例

設計・開発者について従来は経理・総務の担当をしており、今回の返品・修理関係の業務シナリオに詳しい訳ではない。中小企業では、規模が小さいからお互いの仕事が分かっているというのは誤り。

425-003

レベル５プロセス定義方法(例）②レベル４プロセス設計をレベル５に分解

事例

A２



３．業務シナリオのプロトタイプの開発・・・・約３カ月間

(1)レベル５プロセス(タスク)の設計レベル４設計に基づいて、個々のレベル５プロセス(タスク)に関して

①タスクの完了条件は何か②インプット・アウトプットは何か

インプット２の参照情報も重要・・・・中小企業では共有されていない③インプット・アウトプットに必要な情報項目（属性）は何か

例.見積依頼先候補④業務ルールの詳細は何か、この完了条件は何か

例.見積依頼先決定ルール・・・・中小企業ではルールが未確立・業務ルールの論理設計から

業務ルール定義書に詳細設計・定義

「顧客からの苦情」の情報項目例

425-003

レベル５プロセス定義方法(例）③業務シナリオごとのレベル５プロセス設計

ル｜ル定義書

事例

A２



(2)BPMツール上にプロトタイプを開発①一つの画面内にどのタククを入れるか、

画面の区切りはどうかタスク設計の機能をもとにして、タスクの業務担当者を考慮して一つの画面に収める

・・・・中小企業では、水平・垂直の職務兼務が多い②開発期間は２週間、３つほどのプロトタイプを開発して選定

評価基準は、「画面のまとめ方（タスクと担当者）」など。③ワークショップに提出するプロトタイプを１つ選定

選定基準は、「使い勝手」など。・・・・操作性とは異なる

425-003

レベル５プロセス定義方法(例）④プロトタイプを開発・準備

プロトタイプ例

事例

A２


４．ワークショップを開催し、プロトタイプを検討

(1)関係するメンバによるワークショップを開催開発者の仮説（思い込みの場合も）から、使う人からの評価へ。プロトタイプを見て、初めて意見が出てくる、引き出せる。

(2)出席メンバでプロトタイプを動かしてみて検討①自分の現状の仕事の仕方を思い浮かべて検討②メンバが新タスクを検討

・情報項目を順番も含めて検討例）顧客サービスでは相手が言った内容をそのまま記録・タスクで参照すべき業務ルールと内容を検討など（効果）現状調査・記述を省略できる

メンバから、情報項目(順番も）、参照ルールなどの設計改善案を引き出せる

(3)直ちにプロトタイプを変更して、動かしてみる・・・・・すぐにプロトを変更できる場合

・メンバがその場で確認できる・メンバは、「困っていた業務がスムーズに行くんだ」という

確信を抱ける。（効果）使いたくない、使わない、ということは起きない

・初めての開発者は、時間をかけて設計・開発してきたものが「使える形」になった喜び。

(4)後日にプロトタイプを修正・・・・・修正案を検討してプロトを修正

425-003

情報項目の移動

情報項目の追加

入力方法の変更（選定、自由入力）


レベル５プロセス定義方法(例）⑤ワークショップにて、プロトタイプを稼働させ評価する

事例

A２


５．プロトタイプを運用して修正していく

(1)利用者は運用時点では、「タスク機能自体を理解している」（効果）操作ミスが少ない

直ぐに、業務上の効果を得られる(2)修正例

・画面上の項目の配置を「使い勝手」から変更・情報項目の入力し忘れや入力モレへの対策

425-003

６．次の業務シナリオを選定、開発・・・・インクリメンタル開発もちろん、本番運用中のものも修正（保守）する


レベル５プロセス定義方法(例）⑥プロトタイプを早期に運用して修正する・・・・インクリメンタル開発

ITシステムの利用者が業務シナリオを自ら開発できる。・・・・トフラーのプロシューマーの実現業務シナリオは、作業系プロセスだけではなく、意思決定系プロセスも含む。

事例

A２


6 まとめ


60-10-81

シックスシグマとGUTSY-4

GUTSY-4は、Defineを階層的に定義


ビジネスモデル

ビジネスプロセスモデリング

構造化

２

３

４

５

０

１

業務改革モデル


業務改革モデルを反映

レベル２プロセス分析

レベル２プロセス設計

顧客価値提供モデル


レベル２設計を構造化

レベル３プロセス分析

レベル３プロセス設計


レベル２プロセス課題抽出

レベル３プロセス課題抽出

レベル３設計を構造化

レベル４プロセス分析

レベル４プロセス設計

レベル４プロセス課題抽出


レベル４設計を構造化

レベル５プロセス設計

トップダウンボトムアップ

現状プロセスの調査・記述

上位設計からの構造化

現状プロセスの課題抽出

構造化

+

+

+

プロセス分析(CSFや根本原因の特定)

プロセス設計(プロセス分析の解決策設計)

構造化

構造化

Ｄ M A I

実行

実行

実行

実行

戦略実行

ＤM A I

ＤM A I

レベル５プロセス課題抽出

レベル５プロセス分析

ＤM A I

C

C

C

C

C

D：プロセス改善点の特定M：現状プロセスの調査・記述A：改善点を構造化I：新たなプロセスの設計C：パフォーマンス測定


350-002

レベル４プロセス記述レベル４プロセス設計

プロセス構成要素ごとの要求の引き出し

引き出した要求の分析・仕様化

引き出した要求の妥当性確認

非機能要求のまとめ

概念データモデルの作成

【310】～【345】【350-01、10】【350-20、30】【350-40】

【350-70】

【351】

要求引き出し２次元インタビュ｜シ｜トによる

プロセス構成要素ごとに８Ｗ２Ｈで詳細化

インプット・アウトプット説明書

業務ルール説明書

プロセス構成要素ごとに８Ｗ２Ｈで詳細化

引き出したユ｜ザ要求を整理・記述する

再インタビュ｜が必要な場合もある

レベル４要求定義書

概要レベルIT要求定義の主要アクティビティ（定型的プロセス）②

要求工学の要求定義プラクティス

【352】

＋


IT効果理由

１経営面からのビジネス要求をITに反映できる

＜階層化アプローチによる＞

「日本ではビジネス要求が実現していない」 (63%の企業)

出所：アクセンチュア「日本におけるIT生産性の調査結果と提言」2007.5.21発表

２ IT要求トラブルの減少

<ビジネスプロセスからのIT要求の引き出し>

(業務観察法に近い）

日経コンピュータ誌20081201第２回プロジェクト実態調査

ＱＣＴ全部の遵守率は、3.8%？

その原因は、「要求」、５年前よりも拡大

３使われないIT機能を要求段階で排除できる

⇒金メッキ要求や保険的要求など64%の要求の削減が可能、事例では約４割の削減実績

<ビジネスプロセスからのIT要求の引き出し>

（参考）ITシステム機能の利用率：2000 CHAOS Report

・全く利用されない機能 45%

・ほとんど利用されない機能 19%

・まれに利用する機能 16%

・よく利用する機能 13%

・常に利用する機能 7%

４意思決定系業務へIT適用を拡大できる

⇒事例）顧客要求の確認の標準化により、ETO品の受注が1.9倍

今までは、作業系プロセスにおけるIT省力化・効率化だけが狙い

＜これからは情報化による効果的意思決定＞

５プロセス、組織・人との三位一体の改革によるIT投資効果の向上

IT投資効果の定量化

<ビジネスプロセスを中心としたアプローチ>

「ＩＴ投資効果が大限に発揮されるのは、組織・プロセス改革と人的対応の両方にしっかり取り組んだ場合」出所：篠崎彰彦教授[九州大学]の分析(2007)

経済産業省3,141社調査データを分析

GUTSY-4 ®によるビジネスアナリシスのITへの効果

６．IT要求概論とその定義00-01-01B LINK

中小企業のビジネスプロセスの特徴とBPM の方法 …日本BPM協会...

Documents

Transcript of 中小企業のビジネスプロセスの特徴とBPM の方法 …日本BPM協会...

中小企業のビジネスプロセスの特徴 とBPM の方法 …日本BPM協会...

Documents

Transcript of 中小企業のビジネスプロセスの特徴 とBPM の方法 …日本BPM協会...

中小企業のビジネスプロセスの特徴とBPM の方法 …日本BPM協会...

Transcript of 中小企業のビジネスプロセスの特徴とBPM の方法 …日本BPM協会...