👨‍👦 🦌 🕯️ IDEF0表記法と使用例の紹介 ⛪️ 🎥 🙍🏼

一枚の写真は千の言葉に値する

民俗の知恵

私の仕事では、特定の問題を研究して解決するだけでなく、会社の一般的なモデルでその場所を特定する必要があることがよくあります。特定のユニットが正常に機能していないことを理解するだけでは不十分です。他のユニットとの相互作用を理解することは重要です。そうしないと、既存の問題をすべて特定して、問題を解決するための最適な方法を選択することは不可能です。そのためには、会社の仕事を研究し、その機能モデルを作成する必要があります。

もちろん、理論的には、マネージャーは会社の仕事の機能モデルを持っている必要があります。重要ではありません。倉庫の組織やリードからアプリケーションまでのITシステムについて話しているのです。しかし、実際にはそうなることはほとんどないため、クライアントが提起した問題の解決策を研究および検索する過程で、会社の機能モデルまたは特定のプロセス（機能）を自分で作成します。

グラフィックスの利点について一言

ご存じのように、IDEF0機能モデルは常にグラフィック図です。それらには、独自の特性とコンパイル規則があります。これについては少し後で説明します。そして今、私はグラフィックスの有効性のいくつかの例を挙げたいと思います。なぜこれに焦点を合わせているのですか？おそらく、会社の仕事の機能モデルの必要性についての私の主張の後、多くの人がこれはすべてオプションであると考え、このまたはその機能が会社でどのように機能するかを言葉で説明できました。それが私が話したいことです。

そもそも、歴史を少し探検してみましょう。ロシアとトルコの戦争の間、遠い1877年に戻りましょう。その時、ポリグラフ作家のシティンは最初に敵対行為の記述にグラフィックスを適用しました。戦闘について説明する際、誰もが目の前に矢印が付いたカードを持っているので、戦闘の経過を明確に示しています。そして当時、軍事作戦は言葉で説明されていました。すべての戦いのために-多くの、多くの言葉。そして最終的に、何が起こっているのかを理解することは非常に困難でした。

そのため、Sytinのアイデアは真に革命的でした-彼は要塞と軍ユニットの場所を指定して地図の平版コピーを印刷し始めました。これらのカードは「新聞読者向け」と呼ばれていました。手当。」このアイデアは非常に関連性が高いため、マニュアルの最初の版はすぐに売り切れました。そして、そのようなアプリケーションは非常に需要がありました。その理由は明らかです。グラフィックスは、言葉だけではわかりにくいことを理解するのに役立ちました。

また、私自身の実践からの言葉による説明の無力さの同様の例を引用することができます。顧客の1人から、会社のERPシステムの実装を依頼されました。技術的なタスクがあるかどうかという質問に対して、私は答えを受け取りました。「はい、あります。ただし、400ページあります。」同時に、クライアントは、以前に連絡していた同僚がプロジェクトを完全に拒否したか、明らかに高値で呼ばれたと非常に不満を述べました。技術的なタスクが実際に400ページあり、テキスト記述のみで構成されていることを確認した後、開発者の動作の理由を理解しました。このような大量のテキストを読み、掘り下げ、すべてのニュアンスを理解して、タスクを理解し、価格に名前を付けるだけです。これは本当に難しいことです。

私はこのクライアントに代替オプションを提供しました-表記法の形でグラフィカルに可能なすべてを記述するために。彼は彼にモデリング例を示しました。その結果、彼らは今、彼らの願いを再考し、技術仕様を設計しています。

また、ビジネスプロセスのグラフィカルモデリングが同僚、ビジネスコンサルタントと開発者、およびビジネスマン自身の両方を助けた他の多くの例を知っています。

なぜこれが私の仕事にとって重要なのですか？

私の仕事は、常に既存のシステムに変更を加えることに関連しています。そして、変更を加えて目的の結果を得るには、現在何が存在するかを調べる必要があります。そして、私たちが何をするかは問題ではありません。CRMシステムをゼロからセットアップまたはインストールし、効果的なERPシステムを作成し、さまざまなシステムを統合して一般的な自動化を促進します。いずれにせよ、まず最初に、既存の作業スキームのアイデアを得る必要があり、その後でのみ、いくつかの変更を提案し、問題を解決するためのオプションを熟考することができます。

現在の状況を調査した後、私は他のサードパーティの専門家と同様に、現在の状況に対するビジョンと、タスクを解決するために実行する必要があるアクション、そして当然のこととして期待される結果をできる限り公開する商用提案を作成します。

仕事の調査に関するそのような報告は膨大であり、それらは複数のページを占有し、一方では必要であり、他方では知覚を複雑にします。多くの人と同じように、私は多くの人と同じように、膨大なレポートは良いと思っていました。なぜなら、人は仕事にお金を払い、できるだけ詳細な情報を提供する必要があるからです。

→ テキスト形式のレポートの例

実際、ボリュームを提供するのではなく、本質をできるだけ迅速かつ完全に伝えることが重要です。大量のテキストには時間が必要ですが、ビジネスマンにはほとんど時間がありません。また、スケジュールにより、提案の量を減らすことができ、ソリューションを明確に理解できる形で示すことができます。その結果、私の提案は大幅に削減され、それらにグラフィックが表示され、協力を開始する決定がより迅速になり始めました。

このため、視覚モデルを使用しています。ご存じのとおり、1枚の写真は1000語に値します。そして、ビジネスプロセスの説明とビジネスの仕事を近代化するためのオプションの場合、これは確かにそうです。ここで、IDEF0表記は非常にうまく機能します。

しかし、初心者のために、表記法の基本概念、それらが必要な理由、IDEF0とは何か、このメソッドの特徴と利点は何かを見てみましょう。

ビジネスプロセス記述表記法とは

表記法は、ビジネスプロセスを記述するための形式です。ビジネスプロセスは、モデリングルールおよびモデリングで使用されるグラフィックオブジェクトのコレクションです。

実際、表記法は、会社の仕事を説明し、異なる部門間の相互作用を明確に示すことができる特別なグラフィック言語です。ビジネスプロセスを説明する表記法は、プロセスまたは機能のモデリングに使用できます。

一般に、表記はビジネス分析ではプログラミング言語と呼ばれます。

IDEF0とは何ですか？

IDEF0は、ビジネスプロセスを形式化して説明するために設計された機能モデリング（英語の機能モデリング）とグラフィック表記の方法論です。 IDEF0の特徴は、オブジェクトの主観性に重点を置いていることです。 IDEF0は、ジョブの一時的な順序（ワークフロー）ではなく、ジョブ間の論理的な関係に対処します。

ウィキペディア

IDEF0標準は、1981年に米国で空軍部によって工業企業の自動化のために開発されました。ソフトウェア開発のプロセスでは、開発者はビジネスプロセスを分析するための新しい方法を開発する必要に直面しています。その結果、機能的なモデリング手法IDEF0が登場しました。この方法では、分析に特別なIDEF0表記が使用されます。

機能的な会社モデル

機能モデルIDEF0はブロックのセットであり、各ブロックは、入力と出力、制御、および必要なレベルまで詳細な（分解された）メカニズムを持つ「ブラックボックス」です。最も重要な機能は左上隅にあります。そして、機能は矢印と機能ブロックの説明の助けを借りて相互接続されています。さらに、矢印またはアクティビティの各タイプには独自の意味があります。このモデルを使用すると、管理と組織の両方のプロセスのすべての主要なタイプを記述することができます。

矢印には次のものがあります。

Inbox-入門、特定のタスクを設定します。
発信-アクティビティの結果を出力します。
制御（上から下）-制御メカニズム（規制、指示など）。
メカニズム（下から上）-必要な作業を生成するために使用されます。

英語ではそれぞれ入力および出力と呼ばれるため、入力および出力の矢印の入力および出力を呼び出す方がより正確です。しかし、翻訳の特徴と通常の名前は、すでに起こったように見えます。それでも、用語を正しく理解するには、この場合の意味を覚えておくことが重要です。これは、この表記法が主にソフトウェア開発のために作成されたという事実によっても確認されており、この観点から用語をより正確に翻訳する必要があります。

矢印は名詞（経験、計画、規則）を使用して署名され、ブロックは動詞を使用して署名されます。実行されるアクション（商品の作成、契約の締結、出荷の実行）を記述します。

IDEF0は、ビジネスプロセスを記述するための非常にシンプルなビジュアル言語です。この標準を使用すると、開発者、コンサルタント、ユーザー間で情報を転送できます。標準は非常に慎重に開発されており、設計に便利で、普遍的です。 VISIO、BPWIN、ERWIN、Bussines studioなど、それを操作するための多くのツールがあります。

さらに、IDEF0を使用してビジネスモデルを作成することは便利であるだけでなく、正しいことでもあります。このツールはビジネス分析用に開発されたものであり、長時間にわたる徹底的なデバッグと粉砕が行われています。したがって、IDEF0を使用してエラーのない機能モデルを作成する方が、この標準を適用しない場合よりもはるかに簡単です。

ご存知のように、釘を打つにはハンマーを使用するのが最適です。もちろん、これには他のツールも使用できますが、ハンマーは最も機能的であり、その助けを借りて、釘を正確かつ正確にハンマーで打つことが最も簡単です。したがって、IDEF0を使用すると、このツールは機能モデリング用に作成され、これを使用すると、目的の結果をより迅速かつ正確に取得できます。

機能モデルIDEF0の作成例

機能モデリングの使用方法を理解するために、記事を書くプロセスの例を示します。

メインブロックは「記事を書く」です。

トップレベルの機能モデルの説明例

入ってくる矢印-「経験」、「第三者ソースからの情報」。これらは、開始するために必要な紹介です。

記事を書くためのマネージャーは、「出版計画」、「出版社の要件」、「ロシア語の規則」です。

そして、「メカニズム」の役割には、著者、コピーライター、修正者、ソフトウェアがあります。この場合、著者は、記事に反映されるべきすべての考えやアイデアを収集するオーディオ素材を作成します。コピーライターとは、出版社の要件、出版計画、およびロシア語の規則に基づいて、完成した記事を作成する人です。修正プログラムは、素材のエラーをチェックします。そしてソフトウェアは、プロセスのすべての参加者が仕事で使用するツールです。

したがって、プロセスの基本パラメーター、その入力、出力、およびプロセスの成功に必要なすべてを設定します。しかし、これはプロセスの基本的な枠組みにすぎません。これは、会社全体の一般的なスキームを説明しています。

実際、記事を作成するプロセスは、他のビジネスプロセスと同様に、詳細に説明できます。これを行うには、一般的なブロック「記事を書く」を関連する要素に分解します。

私たちの場合、作業は4つの主要な段階に分かれています。

オーディオを準備します。
テキストを準備する
出版用のテキストを準備します。
パブリケーションに記事を投稿します。

第2レベルのビジネスプロセスの機能モデルの記述例

この図は、どの段階でどの制御要素とどのメカニズムが関係しているかを明確に示しています。

したがって、著者はオーディオを作成する際に知識と経験を活用し、出版計画と出版社の要件に導かれます。コピーライターは入力で音声録音を受け取り、そこからロシア語の規則に従ってテキストを作成します。修正者はテキストを受け取り、それをチェックします。これもロシア語の規則に従っています。出版物に記事を掲載するには、特別なソフトウェアが必要です。

機能モデルを作成する場合、重要なパラメーターは目標と視点です。それらに基づいて、同じプロセスのモデリングは多少異なるように見えるかもしれません。たとえば、私の場合、目標は「記事を書くプロセスについて話す」ことです。そして、コピーライターの観点は、「プロセスリーダーの観点から記事を書いて公開する」ことです。

したがって、コピーライターの観点から同じプロセスが記述されている場合、作成者からの経験と音声ファイルが入力されます。この場合、この場合、経験とはコピーライターの経験を意味しますが、リーダーまたは著者の経験は意味しません。したがって、ビジネスプロセスのモデルを作成するときに最初に決定することは、視点を選択し、目標を明確に策定することです。

このようなモデリングは視覚的なだけでなく、効果的な管理上の意思決定を行うのに非常に便利です。たとえば、上記のビジネスプロセスには、コピーライターと修正者の2人の専門家がいます。プロジェクトの資金調達を最適化するようにタスクを設定すると、スキームのおかげで、それがどこにあり、どのようにそれを行うかがすぐにわかります。そのため、コピーライターと修正プログラムはほぼ同じ規則を使用しますが、コピーライターは音声を受信し、結果をテキスト形式で提供し、修正プログラムもテキストを受信して提供します。したがって、必要に応じて、たとえば、コピーライターに修正者の義務の半額を提供できます。だから、私はさまざまな専門家の相互作用にお金と時間を節約します。もちろん、校正者のすべてのメリットと、個々の専門家と協力する方が良い理由を理解しています。しかし、私はあなたに思い出させます-私には仕事があります：コスト最適化。

このような視覚的なツールがなければ、どのブロックを削除できるかを判断し、作業を最適化することは困難です。

IDEF0表記を作成する方法

表記の作成に使用できるソフトウェア製品は多数あります。機能モデリング用に特別に作成されたものもあれば、グラフィック要素を使用した作業用に設計されたものもあります。これらのモデルをどこでどのように構築するかはあなた次第です。

個人的には、最初の段階では、エラーが発生した場合に修正するための普通紙、シンプルな鉛筆、消しゴムに勝るものはないと思います。

既存のビジネスプロセスの表記を作成するため、つまり会社が現在どのように働いているかを説明するには、仕事の原則を勉強する必要があります。外部の専門家（コンサルタント、開発者）がこのためのインタビューを実施します。最初の段階では、会社の責任者が質問に回答します。その後、表記の詳細を作成する過程で、さまざまな作業段階を担当する従業員にインタビューを実施します。

結果として、2つの表記が必要であることを理解することが重要です。最初のものは、ビジネスプロセスをそのまま表示します。インタビューに基づいて作成し、各詳細を会社の従業員と責任者と調整します。既存のプロセスのビジョンが現実と一致することが非常に重要です。これが、すべてのレベルでの確認が必要な理由です。

2番目の表記は「あるべき姿」です。タスクの一部として会社の作業を最適化および自動化するために、作業の構造に加えることを提案する最初の変更およびそれらの変更に基づいて作成されます。

IDEF0標準要件

IDEF0標準の基本要件は、原則として上記で説明し、例を示しました。

左上隅は常にメイン要素です。
すべての要素には入力矢印と出力矢印が必要です。実行のために入力（注文、タスク）で何かを取得する必要があり、出力を処理した後、完成品を転送する必要があるためです。着信矢印は常に左側にあり、発信矢印は右側にあります。
上は制御要素、下はプロセスを完了するために必要なメカニズムです。
複数のブロックが1つのシート（画面）に配置されている場合、後続の各ブロックは、前のブロックよりも右下に配置されます。
矢印の交差が最小になるようにスキームを作成するよう努力する必要があります。

IDEF0標準には、一般に受け入れられている表記法、ルール、ダイアグラムブロックの要件も含まれており、独自のセマンティクスがあります。「機能モデリングIDEF0の方法論」というドキュメントで、それらに慣れることができます。

よくある間違い

機能モデリングは、モデリングを目的としないツールを含むさまざまなツールを使用して実行されます。後者の場合、エラーチェックや標準の制限はありません。視認性と経験不足を増やしたいという欲求は、しばしばエラーに終わります。

異なる色を使用する

ダイアグラム内のすべての要素は同様に重要です。機能モデリングでは、重要な要素は多かれ少なかれありません。いずれかの消失は、プロセスと生産の欠陥の混乱につながります。

多くの場合、紙またはさまざまなプログラムでモデリングする場合、ユーザーはさまざまな色を使用して視認性を高めようとします。これは最も一般的な間違いの1つです。実際、マルチカラーの矢印とブロックを使用すると、さらに混乱を招くだけでなく、回路の知覚を歪めます。

モデルは、カラーソリューションを追加せずに、白黒で読む必要があります。このアプローチは、モデルの作成者の誤解と規律の回避に役立ち、その結果、モデルの読みやすさとリテラシーが向上します。

ブロックが多すぎる

モデルをコンパイルするとき、会社の仕事のすべてのニュアンスをすべての詳細とともに1つのシートに表示しようとすることがよくあります。その結果、非常に多数のブロックと多数の制御矢印が作成されます。可読性が失われます。

最良のオプションは、問題を理解するのに十分な粒度であり、それ以上はありません。プロセスの詳細ビューを選択すると、各ユニットまたは従業員の作業の詳細が開示される場合があります。そして、そのような構造は、仕事や意思決定に本当に必要な場合にのみ作成されます。

調整を行う際の構造の違反

着信、発信、およびその他の重要な要素がない限り、混乱やプロセスがないように注意してください。たとえば、上記の例で、視点をコピーライターにシフトする必要があると考える場合、著者をスキームから削除します。そして、コントロール要素である「著者の経験とサードパーティのソース」、および出版計画が不要になります。結局のところ、著者はそれらを使用しています。コピーライターは音声ファイルを処理します。そして、それらが一般的なスキームにとどまる場合、詳細化するとき、それらは理解不能な場所につながり、混乱をもたらします。

同様に、何らかの種類のブロックを追加することにした場合、必要なすべての属性も確実に持つことが重要です。ここでは注意が非常に重要です。複雑なビジネスプロセスをモデル化するとき、モデルのある部分の変更が別の部分の変更につながる可能性があるためです。入力する必要があります。

コントロールとブロックの名前の規則

単純なルールを覚えておくことは重要です。制御矢印は名詞と呼ばれ、ブロックは動詞と呼ばれます。これはIDEF0標準で受け入れられており、このアプローチは混乱とエラーの回避に役立ちます。

ほとんどの場合、ブロックに名前を付けるときに間違いが生じます。たとえば、「記事を作成する」の代わりに、「記事を作成する」と書きます。このアプローチのブロックはアクションであるため、常に動詞である必要があります。

IDEF0を使用する利点

最初の利点は明らかです-それは視覚的です。 あなた自身がこのシステムまたはそのシステムがどのように機能するかを理解し始め、またこのシステムのどこに「薄いスポット」があるか、そしてあなたの決定がそれらを取り除くのにどのように役立つかを明確に説明できます。
理解と矛盾の欠如。 機能モデルを使用して会社の作業を議論するとき、制御要素を備えた直感的に明確で直感的なタスクブロックがあります。さらに、機能モデリングには、必要に応じて、シンボルと用語が開示されている用語集の作成が含まれます。その結果、問題について話し合うとき、あなたとあなたのクライアント、マネージャー、および他の従業員は同じ言語を話します。
モデル作成のシンプルさと高速。 もちろん、モデル化の方法を学ぶことは思ったほど簡単ではありません。結局のところ、スキームは、本質的に、情報の過剰な提示であり、理解には非常に優れていますが、そのような提示を実装するには特別なアプローチが必要です。この場合、アナリストの脳は、非常に強力なプレスとして、またフィルターとして表示されます。しかし、経験があれば、このプロセスは非常に高速になります。その結果、特定のシステムで何が起こっているかを把握し、短時間で作成された視覚資料を使用して同僚や顧客に重要なポイントを説明するのに役立つツールを入手できます。
規律とエラーの欠如。 IDEF0標準には、厳格なフレームワークとルールが必要です。このアプローチ規律、および標準のフレームワーク内で行動する習慣は、不注意によるエラーを回避するのに役立ちます。規格の違反はすぐに目立つようになります。

IDEF0を使用する難しさは何ですか

最も単純な場合にのみ、2人のビジネスアナリストがまったく同じ機能モデルを作成して、会社の仕事を説明することを理解することが重要です。どのモデルも、アナリストの経験、彼が説明しようとしているビジネスの理解の深さ、そして何らかの形でこのビジネスに関する彼の個人的な視点を反映しています。つまり人はリーダーの観点からビジネスモデルを開発します。まるでそのリーダーが彼であるかのように。

同時に、ビジネスアナリストは専門家ではなく、一部のシステムのすべてのビジネスリーダーまたは開発者は、ビジネスを分析し、最も効果的なシステムを構築しようとするビジネス分析に携わっていると思います。 IDEF0ツールが意図されているのは、これらの人々とこれらの目的のためです。

したがって、機能的なビジネスモデルを「現状のまま」コンパイルする場合、分解の段階で自動的にエラーを伴うミスをしないように、常に会社のトップと相談することが非常に重要です。また、その後の段階では、構造部門および従業員の長との追加の調整が必要になる場合があります。機能モデルが「現状のまま」で物事の実際の状態を本当に反映する場合にのみ、変更や提案を行うことができます。そして、そのような仕事で高品質の結果を達成するには、まず、特定のタイプのビジネスの特徴に関する実践的な経験と知識が必要です。

このトピックに関する他の記事：

また、現在、ビジネスおよびプロセスモデリングの分野での実際の経験だけでなく、ビジネスへのプロセスアプローチについての私自身のビジョンを詳細に説明する本とオンラインコースを出版する準備をしています。誰もが他のニュースリンクから新しい本のリリースに関する通知にサインアップできます。

IDEF0表記法と使用例の紹介