同じ川に2回入ることは可能ですか？
この記事は、 TriniDatに代わって私が作成したカンファレンスNeftegazstandart-2016でのレポートの結果に基づいて書かれました。
オントロジストとして、私は情報システムの情報モデルを作成しています。
この記事では、企業の資産のモデリングにISO 15926標準を適用する方法と、最終的に私たちを導いた結果についてお話したいと思います。 標準に不慣れな人は動揺しないかもしれません-記事を読むことは標準の知識に関係なく有用です。
資産モデリングの問題
- 企業向けの資産モデルの構築は、依然として複雑で重要な作業です。 私の意見では、この複雑さは、モデリング手法と通常の人間の思考との間のギャップによるものです。 たとえば、アリストテレスの論理にも論理にも、「インスタンス」という用語に似たものはありません。 ただし、プログラマやアナリストは、この意味を説明せずにこの語を使用することがよくあります。 個人的には、この用語の定義はどこにも見当たりません。
- 最も成功したアセットモデリング手法の1つはISO 15926標準と呼ばれ、通常の空間座標とともに時間を企業のモデリングの4番目の座標として使用できるという革命的な仮定を立てています。 このアプローチにより、資産ライフサイクル全体をシミュレートできました。 ただし、この標準の助けを借りても、企業の活動を記述するためのユニバーサルメタモデルを作成することはまだできていません。 実際、この規格の作成者はこのタスクを設定していません。
- 企業の活動をモデル化するための多くの標準、たとえばArchiMate標準が提案されています。 開発者によると、この標準はISO 15926標準およびTOGAFエンタープライズアーキテクチャモデリング方法論に適しています。 宣言された機能にもかかわらず、この標準はタスクに完全に対応していませんでした。 この理由の1つは、「アクティビティ」と「アクティビティ」の概念の区別がないことです（アクティビティとは、結果を達成するための意図的な努力を意味します。アクティビティは、被験者の意思とは無関係に発生すると解釈されます）。 難易度をよりよく理解するために、古代ギリシア人が正方形の「a」をどのように解釈したか覚えていますか？ 彼らは、長さaの辺を持つ正方形の面積よりも他のことを考えませんでした。 立方体についても同じことが言えます。長さ「a」の辺を持つ立方体の体積は、立方体で「a」として記録されました。 しかし、「a」の物理的な類似度を4度まで考え出すことは不可能であるため、古代ギリシャの立方体上の方程式は考慮されませんでした。 そして、中世になるまで、代数論者は物理的な意味から方程式を引き離しませんでした。 純粋数学の最初の時代は、方程式の物理的な類似物を探していませんでした。 ビジネス分析でもまったく同じことが起こります。 1つの角度からのみ何が起こっているかを（アクティビティとして）考慮すると、分析機能が大幅に制限されます。
- また、ISO 15926規格は、さまざまなタイプ（機能的および物理的など）のオブジェクト、およびこれらのオブジェクトの交差を時間内にモデリングする貴重な機会を提供します。 ただし、オブジェクトの可能なタイプのセットは標準によって厳密に定義されており、実際の場合には、オブジェクト、イベント、またはプロセスの概念を適切に反映するモデルを作成するだけでは不十分です。 たとえば、標準には「生産リソース」タイプのオブジェクトはありません。
問題の声明
私の最後の仕事はサマラ油田設備工場に関連しました。
顧客は、セールスマネージャーが最も効率的な方法でクライアントとやり取りするのに役立つ情報システムを作成したいと考えていました。 このために、マネージャーには以下を含むすべての必要な情報を提供する必要があります。
- 機能要件モデル（クライアントには何が必要ですか？）
- 可能な解決策のモデル（機能要件をどのように満たすことができますか？）
- 原価計算モデル
- リスクモデル
- 顧客関係モデル
問題を解決するために、実際には、資産モデルから始まり、アクティビティモデルで終わる、企業全体のモデルを作成する必要がありました。
ISO 15926標準は、モデルを作成するためのイデオロギーの基礎として採用されました。
この規格は、資産のライフサイクルを記述し、機能的オブジェクトと物理的オブジェクト、およびそれらの共通部分をモデル化するタスクに完全に対応しています。 ただし、本格的なエンタープライズモデルを作成するには、この標準の機能では不十分でした。
企業の活動を説明するには、ArchiMate表記を使用できます。
しかし、それは前述の理由により適合しませんでした-活動のモデルと活動のモデルとの間に違いはありません。 さらに、ビジネス機能とは何か、それが運用やプロセスにどのように関係しているかについての正確な説明は含まれていません。 標準でこの問題を解決するには、同じ質問の2つの意味を分離する必要があります。「これは同じオブジェクトですか？」同じオブジェクトの意味では？ それとも似たようなオブジェクトですか？ 残念ながら、標準ではこの問題のこれらの2つの異なる意味を区別していないため、アクティビティモデルを正しく構築することはできません：2つのビジネスオペレーションは互いに類似しているという意味で1つのオブジェクトとして認識されますが、2つのビジネス機能は実際の場合は1つのオブジェクトとして認識されます一致します。 1つのモデルでこれらの問題を混同することはできません。
さらに、アクティビティモデルの作成に引き続き取り組みました。 この作業の過程で、アクティビティだけでなく、コスト、機能オブジェクト、物理オブジェクトもモデル化できる単一のテンプレートが見つかったことに驚きました。 さらに、これらのエンティティをモデル化する方法は普遍的であることが判明しました。 このメソッドはどこでも使用できます！
次に、この方法について詳しく説明します。
解決策
私たちが必要としていた新しい概念は視点です。 資産の例としてポンプを考えてみましょう。
エンジニアの観点からは、これは機能的なオブジェクトであり、会計士または経済学者の観点からは、これは生産資産です。 オブジェクトの認識方法は、モデルを構築するサブジェクトが参加するビジネス機能によって異なります。 したがって、「視点」の概念を紹介し、特定の視点内のオブジェクトの解釈について説明します。 たとえば、この主題がポンプとして石油パイプラインの運用に参加しているエンジニアによって、予算の合意に参加している金融業者によって、生産資産として解釈され、企業のセキュリティ担当者によって盗難から保護されなければならない具体的なオブジェクトとして解釈されるという事実は、オブジェクトの観点に依存します。
必要な2番目の概念は構築です。 人体の設計を考慮してください。
少なくとも2つの異なる視点を知っています。 ある観点から見ると、身体は腕、脚、胴体、頭から構成されています。 別の観点から-筋骨格系、神経系、循環系、呼吸器系、消化器系から。 人体を構造の形で表す他の多くの方法を考え、想像することができます。 人体に当てはまることは資産にも当てはまります。 たとえば、掘削リグを考えてみましょう。
被験者が参加する機能に応じて、彼はその異なる構造を見るでしょう。
1つは多くの集計を表示し、もう1つは-多くのサブシステムを表示します。 さらに、そのようなパーティションは、任意に実行できます。
この多様性をモデル化するには、「建設」の概念と「オブジェクト」の概念が必要です。
結果を見ると、物理的および機能的なオブジェクトは存在しないという結論に達しました。 人間の活動には多くの領域があり、それぞれが独自の視点と独自のモデルを生み出しています。 このような各視点に基づいてモデルを作成し、あるモデルから別のモデルへの遷移マトリックスを記述することができます。 ISO 15926でこれを行う方法：
その後、1つのビューから別のビューに移動して、視点を変更できます。 これにより、1つのインフォメーションストアにさまざまな目標を持つさまざまな人々によって作成されたモデルに関する情報を保存できます。
ISO 15926は、物理世界の視点と機能オブジェクトの視点の2つの視点のみを考慮したデータウェアハウスの構築方法を説明しています。 また、一時的な部分を介してある表現から別の表現に移動する方法についても説明します。 つまり、この機能の役割を果たしたのはどの物理オブジェクトで、いつの質問かという答えを得ることができます。 あなたは反対の質問への答えを得ることができます：これはどの機能的なオブジェクトまたはその物理的なオブジェクトを実行しましたか？ これらの質問に対する答えは、あるビューから別のビューに移動する方法です。 ただし、「視点」の概念を導入すると、2つの視点に限定されることはなくなりました。 これで、モデリングの目的に必要な数の視点を作成できます。
モデリングに対するこのアプローチの最大のメリットは、企業自体のアクティビティをデザインを持つオブジェクトと見なすことで得られます。
ある観点から見ると、オペレーションの構築は空間的に一連のロールとして表現でき、一方で一時的に一連のサブオペレーションとしてシナリオとして表現できます。
したがって、エンタープライズアーキテクチャを記述するためのフレームワークは、視点、オブジェクト、および設計という概念に基づいています。 これにより、操作中に構造を変更する必要のない情報モデルを作成できます。 たとえば、あるオブジェクトから別のビューに移動できる情報モデルを作成できます。たとえば、サプライヤから顧客に、各オブジェクトに対して単一の共通の視点を強制せずに移動できます。
したがって、同じ操作は、サプライヤの観点から「販売」と呼ばれ、クライアントの観点から「購入」と呼ばれます。 ちなみに、視点を変えてモデル内を移動する機能により、エンドツーエンドのアカウンティング（トレーサビリティ）の問題を解決できます。
会話の舞台裏では、より複雑なアカウンティング単位であるセット、タイプ、属性についての考察は省略しましょう。 資産記述フレームワークを完成させるには、これらのオブジェクトを慎重に検討する必要があります。
要約：
結果のメタモデルには、次の利点があります。
- メタモデルは私たちの自然な考え方に近く、必要に応じて、たとえば確率を導入することで、メタモデルを簡単に拡張できます。
- メタモデルは多用途です。 シミュレーションに必要なものはすべて、この手法を使用して説明することができました。
- 追加のボーナスは、1つのフレームワークでさまざまなタイプのアクティビティを説明する機会でした。 たとえば、通常の生産活動と生産活動を妨害する活動は、1つのモデルで単一の方法で記述されます。
- モデルとそのアプリケーションの方法論との関係を断ち切ることができました。 モデル設計者は、このモデルまたはそのモデルが適用される目標を知る必要がなくなりました。 それは事実を捉えており、他の俳優は彼らの解釈に従事しています。 これにより、必要な機密レベルのモデルを作成できます。
- メタモデルは、事前定義されたタイプのオブジェクト（たとえば、機能的または物理的）の導入を必要としないサブジェクト領域上の視点を想定しています。 必要に応じて同様のタイプが導入され、同様のタイプの数はいくつでもかまいません。
- メタモデルを使用すると、1つの情報モデルを使用して、オブジェクトのある表現から別の表現に移動できます。
- メタモデルを使用すると、無制限に拡張できる情報モデルを作成できます。 その拡張は、格納される情報の量によってのみ制限されますが、一貫性のないデータのために発生する可能性のある論理的な矛盾によっては制限されません。
モデルの実装の難しさ：
- このモデルを実装することの難しさは、結果として得られるモデルが非常に複雑であるため、ソフトウェア実装に高い要求がかかることです。
- このレベルの複雑さのモデルを作成するには、専門家の追加トレーニングが必要です。