ISO 15288の資料を読んでかなり偶然、「典型的な有効化システムとシステムの相互作用」の図を見ました（図の元の形式は意図的に記事の最後にのみ示されています）。
- ターゲットシステムの作成とメンテナンスに関係するシステムの種類
- これらのシステムとターゲットシステムの通信。
私はすぐに、このスキームをビジネスシステムの一部への分解に適用したいと考え、この記事でこの試みの結果を共有します。
ISO 15288の基本概念の1つは、システムのライフサイクルです。これは、次のように概略的に表されます。
ライフサイクルの段階は、次の考えを反映しています。「新しいシステムの開発手順は、システムの段階的な「具体化」と考えることができます。エンジニアリング」、p.143]。 これは、実際の段階の経過の簡略化されたイメージであり、実際には時間的に重複するか、代替（たとえば、システムの機能とそのメンテナンス）などになる可能性があることを理解する必要があります。 しかし、それにもかかわらず、このスキームはいくつかの基本的なアイデアを視覚化するのに十分です。
私は、ビジネスシステムの主題分野に適用されるライフサイクルのアイデアを採用しました。
ライフサイクルの段階のプリズムを通して、ビジネスシステムの構造を見てみましょう。 最初に、生成するターゲットシステムを示します。
ビジネスシステムの場合、ターゲットシステムは通常「製品」と呼ばれ、メインシステムとして使用し続けます。 製品は非常に複雑（車）、非常に単純（（など）になる可能性がありますが、これはこの記事では重要ではありません。 すべてがシステムであり、すべてのシステムにはライフサイクルがあります。
明らかに、製品は少なくとも生産される必要がありますが、最大でも-広告、販売、配送など。 図では、これは次のように表示されます。
「生産システム」という用語は、必要な意味を伝えるのにあまり成功していないかもしれませんが、これまでのところ、私はこれ以上成功するものを思いつきませんでした。 ビジネスでは、これは通常「オペレーション」と呼ばれますが、さらに不幸な用語です。
このスキームに反映される重要な事実：
- 本番システムは、ライフサイクルの各段階を経るシステムでもあります。
- 矢印は、システム間の関係を示しています。つまり、「運用」段階の生産システムは、製品に「生産」ライフサイクル段階を提供します。 または、もっと簡単に言うと、生産システムが製品を生産するという事実が図に反映されています。
- 実動システムは、製品に「開発」段階を部分的に提供します。 これの意味についての説明を以下に示します。
また、通常はビジネスシステムにも（必ずしもそうではありません！）実稼働システムの「修復」に従事するサービスシステムがあります。 「修理」という用語には、定期的な定期メンテナンスと、使用できない部品の適切な部品との交換の両方が含まれます。 サービスシステムにより、本番システムを任意の時間存続させ、製品を生産する機能を実行できます。
この段階で、読者は既に質問をしているかもしれません。生産システムとサービスシステムはどこから来たのか、そして製品の設計と開発に誰が関与しているのでしょうか。
この質問に物語で答えると、次のように定式化されます。
有能なチームが集まり、製品のコンセプトとそれを生産する能力について話し合います。
コンセプトが満足のいくもので、製品を生産する能力が存在する場合、チームは実装に移り始めます：製品、生産およびサポートシステムの詳細なプロジェクトを開発し、生産およびサポートシステムのプロジェクトを材料に実装します。
生産システムを材料に実装した後、製品の生産を開始する準備ができているはずです。 この物語を図の形で反映します。
このスキームに反映される重要な事実：
1）まず、典型的なビジネスシステムの境界（この場合、システムエンジニアリング用語「システムのシステム」（SoS）と呼ぶことができます）は、この図にすでに表示されています。
「実際、多数の独立した実行可能なシステムが組み合わされて、個々のシステムの能力の合計を超える能力を獲得するたびに、システムのシステムが得られます。 もちろん、統合のレベルは大きく異なります。 スペクトルの一端にSoSがあります。これは、開発のごく初期の段階で完全に統合されており、個々のシステムは独立して機能しますが、SoS専用に設計されています。 もう一方の端では、所有者の同意以外の正式な正当化なしに、ローカル問題を一時的に解決するために疎結合されたシステムを見つけます」[A. Kosyakov "System Engineering"、p.119]。
そのようなSoSとそのようなタイプの両方が、ビジネスシステムに見られると思います。 これに加えて、プレゼンテーションの最上位のビジネスは、一般に信じられているような「リジッド」な階層システムではなく、システムのシステムであると付け加えます。
a）その中のシステムはかなり特定の関係にあり、部分整数の関係にはありません：
- 開発システムは、生産およびサービスシステムを計画、設計、および開発します。
- サービスシステムは、運用システムの「修復」に従事しています。
この場合、活動の理論（たとえば、GP ShchedrovitskyのSMD方法論）を思い出して、システムは活動の対象であり手段であると言うこともできます。 ただし、その役割は変更される場合があります。 たとえば、本番システムの作成では、本番システムがオブジェクトであり、開発システムがアクティビティの手段です。 生産システムが構築されると、それは製品の生産における手段になります（または、問題の本質を見ると利益の形でのお金の生産における）
b）システムは相互に非常に自律的であり（相互に関係なく長期間存在する可能性があります）、他のシステムに置き換えることもできます（たとえば、運用システムの保守を外部委託することができます）。
2）開発システムは、製品ライフサイクルの「開発」段階をほぼ完全に提供しますが、「開発」段階のごく一部は本番システムによって提供されます。 実際には、これは、顧客の注文を受けた段階で製品の設計を明確にする必要があるときに起こります。 この場合の開発システムは、実際には全クラスの製品と、再構築なしでこのクラスの製品を生産できる生産システムを設計します。 たとえば、プラスチック製の窓を製造している会社の場合：さまざまなサイズの窓の全範囲を生産できるように生産システムが作成され、生産システムが注文を受け取ったときに特定の窓が設計されます。
生産システムが製品を変更せずに何度も生産する場合、開発システムは完全に「製品開発」の段階を提供します。 しかし、他のタイプの企業（設計、ソフトウェア）については、製品のライフサイクルを確保するための他のオプションが可能です。
このスキームに反映されていない事実：
- 実際には、開発サイクルの開発システムは、製品、生産、およびサービスシステムの「設計-設計」段階と、生産およびサービスシステムの「生産」を繰り返し実行します。
記事の冒頭で述べたように、このタイプの回路ではこの事実を簡潔に表現することはできません。 - 開発システムの「設計-生産-生産」段階には誰が関与していますか？
明らかに、彼女自身はどこからでも現れることができません。 ほとんどの場合、実際には、「開発システム」を作成するプロセスは形式化されておらず、次のように見えます。主要な利害関係者（投資家など）は、チームを形成するマネージャーを探しています。 さらに、このチームは、すでに前述した一次研究を実施しています。 ビジネスシステムを作成する機会を見つけた場合、チームは「開発システム」になります：1回限りまたは永続的に。 後者の場合、開発システムも再構築する必要がある場合があることに留意する必要があります。
「開発システム」の作成プロセスが十分に形式化されている他の状況があります。以下で検討します。 - 生産および保守システムの廃止措置がどのように行われるかは反映されません。 実際には、これは非常にまれです。
サービスを扱う/サービスを提供するビジネスのオプションを以下に示します（図7）。
この場合、次のことが言えます。
a） ビジネスシステムから分離可能なアーティファクトとしての製品はありません。
b） この場合、実稼働システムはターゲットシステムです。
c） 「運用」段階の生産システムは、顧客にサービスを提供します。
このようなビジネスシステムの例としては、美容院やタクシーサービスがあります。
さらに、図6に示すビジネスシステム図を2つのケースに拡張することを検討できます。
製品サービスが必要な最初のケース。 この場合、製品のサービスシステムも作成する必要があります。
サービスシステムが複数の所有者に属する一般的な状況があります。 たとえば、家電製品の生産の場合、サービスシステムには、製造業者（スペアパーツの製造）と、個々の法人が所有するサービスセンターのネットワークの両方が含まれます。
必要に応じて、製品の「償却」ステージを確保するために、利用システムを構築することも必要であることは明らかです。 製品の例は、必要な場合、現在は自動車です。
引用したい2番目のケースは、投資会社とベンチャーファンドの仕事に関するものです。 この場合、ビジネスシステムを大量に作成するための「マシン」についてはすでに説明しています。
図では、ビジネスレプリケーションシステムが製品および本番システムの設計に部分的に関与しているという事実を反映しています。 計画が正常に終了すると、開発システムが作成され、ビジネスシステムの作成に引き続き取り組みます。
おわりに
ビジネスシステムエンジニアリングの主題分野で重要な質問の1つは、プロセス（または機能）をどのように区別するかです。 広く見られるのは、ビジネスは非常に不安定な混乱であり、アクティビティ自体がこのアクティビティを改善するためのアクティビティと密接に絡み合っているということです。
この記事の目的は、ビジネスに3つのシステムとそれに対応するアクティビティがあることを明確に説明することでした。 3つのシステムのそれぞれの仕事の論理（テクノロジー）は根本的に異なります。 人々は通常、これらのテクノロジーを頭の中やモデルに混ぜます。 良いことは何もありません。 したがって、実際には、たとえばチーフエンジニアが新しい生産ラインを考えている場合、その瞬間にビジネスアーキテクトであり、開発システムに座っている（役割を果たしている）ことが明らかになるはずです。 そして、彼が生産ラインの修理を管理する場合、その瞬間に彼は保守スタッフであり、保守システムに座っています。 そして、彼はあらゆる種類の活動に時間を割くべきです。
将来の記事では、一般的なモデリング表記法を使用して、このようなビジネスシステムの構造をモデリングすることを検討する予定です。
アプリケーション。 ISO 15288のオリジナルデザイン
回路のこの特定のイメージは、ドキュメントISO / IEC TR 24748-1「TECHNICAL
報告する。 システムおよびソフトウェアエンジニアリング-ライフサイクル管理。 パート1「ほぼ同じ形式で、彼はISO / IEC 15288：2002に登場しましたが、2015年の最新版からこのスキームはISO / IEC TR 24748で取り上げられました。
ドミトリーピナエフ、GK「モダンマネジメントテクノロジー」