情報システムの概念をhabrasocietyの裁判所に紹介したいと思います。
前のブログで約束したように、この投稿では情報システムの概念について説明します。 この原稿はIP作成の分野での私のささやかな経験の一般化と形式化であるため、厳密に判断しないでください。 このドキュメントを公開することで、建設的な批判と改善の提案を受け取りたいと思います。 また、このコンセプトで実装された情報システムの商用アプリケーションにも興味があります。
私はこの方向に取り組むことに非常に興味があります。既存のシステムに無料でオープンなアナログを作成し、貴重な開発経験を得たいです。 「別の自転車を作成しない」や「X社とY社はすでにこれを行っており、販売に成功しています」などのコメントを書かないでください。しかし、アナログを見るのは面白いでしょう。
現在、情報システムにはいくつかのクラスがあります。
CRM-顧客関係管理システム
ERP-エンタープライズリソースプランニングのためのシステム
MES-生産管理システム
WMS-倉庫管理システム
SCM-サプライチェーン管理システム
ECM-エンタープライズ情報管理システム
EMM-マーケティング自動化システム
MRP-資材ニーズ計画システム
SSDT-統一問題解決システム
EAM-エンタープライズ資産管理システム
HRM-人事管理システム
ServiceDesk-ITサービス管理システム
CMS-コンテンツ管理システム
問題追跡-タスク管理システム
ワークフロー-ワークフロー管理システム
BPMS-ビジネスプロセス管理システム
この問題を研究する過程で、情報システムの各クラスは、データモデルとこのデータに対する一連のアクションの実装によってのみ、全体として互いに異なることがわかりました（おそらく、各IPクラスの説明と分析が次の投稿のトピックになります）。すべての情報システムのゴールデン平均は、ワークフローと問題追跡システムに基づくハイブリッドであるという結論に至りました。
ITサービスを管理するための小規模な情報システムの例を使用して、このハイブリッドを説明します。
説明する情報システムは、アプリケーション管理モジュールとIT資産管理モジュールで構成する必要があります。
読者に負担をかけないように、ITILの用語を故意に使用していません。
アプリケーション管理モジュールは、問題追跡システムの典型的な例です。各アプリケーション（問題）は、そのステータスと、優先度、アプリケーションの説明、ユーザーデータ、アプリケーション分類などの付随データによって決定されます。 アプリケーションステータスによって決定されるアプリケーションライフサイクルは、ワークフローシステムによって提供されます。ワークフローシステムは、作業の段階、編集されるデータ、ライフサイクルの特定の段階で参加するユーザーを記述します。 たとえば、オペレーターとテクニカルサポートエンジニアはアプリケーション登録フェーズに参加し、優先度、説明、ユーザーデータを示す必要があります。 また、アプリケーションを閉じる段階では、エンジニアだけが参加し、アプリケーションを分類してそのソリューションを説明する必要があります。
IT資産管理モジュールは資産データベース（サーバー、ワークステーション、ネットワーク機器、オフィス機器、消耗品）であり、特定の条件下で特定のコンテキストでインフラストラクチャを確認できるように相互接続および分類されます。 各アセットには少なくとも2つのステータス（アクティブまたは非アクティブ）があり、特定のユーザーがアセットのグループを利用できる場合があります。 資産管理をより便利にするには、資産管理からアプリケーションを開始し、アプリケーション管理から資産データベースに変更を加えることができるように、モジュールの統合が必要です。 もちろん、このモジュールは課題追跡およびワークフローシステムを使用して実装されます。
サブジェクト領域から抽出すると、いくつかの構造要素を識別できます。これらの要素に基づいて、適切なアプローチを使用すると、IS管理ITサービスのスケーリングは問題ではなくなります。
ユーザー管理
説明
承認およびユーザーアカウント管理のサブシステム。
必要条件
LDAP、OpenID、その他のシステムを使用して、独立して動作するはずです。
パーソナライズ
説明
ソーシャルネットワークのメカニズムとユーザーインターフェイス設定を整理するサブシステム。
必要条件
サブシステムはディレクトリを使用し、次のコンポーネントのサービスおよび参照情報に基づいている必要があります。
-個人ページ
-プライベートメッセージ
-他のユーザーとのリンク
-ユーザーグループ
-個人設定
-ユーザーインターフェイスのカスタマイズ
-プロジェクトとのリンク
-プロジェクト情報との関係
-システム内のカスタマイズ可能なアクティビティチャネル
アクセス制御
説明
ロール、ロールの階層、および特権の継承に基づいて、オブジェクトへのサブジェクトのアクセスを管理するためのサブシステム。 ロールベースのアクセス制御により、ワークフロー内で動的に変化する柔軟なアクセス制御ルールを実装できます。
プロジェクト、サブプロジェクト
説明
プロジェクトおよびサブプロジェクトを独立した論理的に接続された情報システムとして管理するためのサブシステム。
必要条件
サブシステムは、独自のプロジェクトまたはサブプロジェクトのユーザーを作成でき、アクセス制御によって規制される必要があります。 サブシステムは、情報システムを柔軟に結合する方法を提供するために、プロジェクトをリンクし、プロジェクト間で情報を交換するためのメカニズムを提供する必要があります。
ナビゲーション
説明
メニュー、ページネーション、および同様のインターフェース要素を整理するためのサブシステムで、情報システムのさまざまな状態への迅速かつ便利で直感的な移行を提供します。
トラッカー
説明
トラッカーサブシステムは、情報システムのモジュールを作成するために必要です。
必要条件
サブシステムは、処理されたデータの柔軟な構成のために、ワークフローで定義された動的に接続されたディレクトリを使用する必要があります。 1つのプロジェクトのフレームワーク内で、複数のトラッカーを作成および相互接続でき、1つのトラッカーを複数のプロジェクトで使用することもできます。 トラッカーからのデータは移植可能でなければなりません。 各トラッカーには、トラッカーオブジェクトの数とステータス、オブジェクトが作成された日付、ステータスが変更および変更されたカウンター、オブジェクトの履歴、オブジェクトに関するコメントを決定するための必須属性が必要です。 トラッカーサブシステムは、オブジェクトの編集フォームと表現の自動生成を提供する必要があります。
ディレクトリ
説明
ディレクトリは、情報システムによって運用されるデータです。 これは、データベースデータ、またはシステムのオブジェクトとその状態を記述する他のデータ構造のいずれかです。
必要条件
コンポーネントは、リストの表示、ディレクトリオブジェクトの追加、編集、削除を提供する必要があります。
ディレクトリの構成は次のとおりです。
-基本的なデータ型
-オブジェクトのリスト
-階層リスト
-自動補完フィールド
-キーワードの分類
統合ディレクトリ
説明
ファイル、データベース、さまざまなサービスなど、情報システムで使用されていないデータソースから接続されたディレクトリ。
必要条件
コンポーネントには、便利な統合カスタマイズメカニズムを提供する必要があります。
フォーム生成
必要条件
トラッカーサブシステムには、次のようなデータ編集フォームの自動および手動作成のメカニズムを提供する必要があります。
-単一のオブジェクトの作成/編集
-オブジェクトのグループの作成と編集
-オブジェクト\グループの転送
-他のデータモデルとの統合
提出世代
必要条件
トラッカーサブシステムには、次のようなリプレゼンテーションの自動および手動作成のメカニズムを提供する必要があります。
-オブジェクトのリスト
-オブジェクト
テンプレート化
必要条件
トラッカーサブシステムには、フォームに入力するためのテンプレートを作成して、情報の追加と処理の効率を高めるメカニズムを提供する必要があります。
フィルター
説明
フィルターサブシステムは、選択したフィルター条件に応じて、必要なデータを検索および表示するために必要です。
必要条件
サブシステムには、サービスおよび参照情報に基づいたフィルタリング条件が含まれている必要があります。 サブシステムは、マルチレベルのデータソートを提供する必要があります。 フィルターは以下でなければなりません：
-カスタム
-一般
-特権（特定のユーザーまたはユーザーグループが利用可能）
柔軟なレポート
説明
ディレクトリおよびサービス情報に基づいて、テーブルおよびグラフの形式で一般レポートおよびユーザーレポートを作成するためのサブシステム。
情報のエクスポート（ファイル、電子メール、LDAP、3dparty、rss、soap）
システム内のアクティビティ
説明
システム内のアクティビティを監視するためのサブシステム。
必要条件
サブシステムは、一般的なアクティビティ、プロジェクト内のアクティビティを表示する機能を提供する必要があります。また、アクティビティを表示するための一般およびユーザーチャネルの柔軟な構成を提供する必要があります。
ワークフロー
説明
ワークフローサブシステムは、データへのアクセスを制御し、ユーザー、ユーザーグループ、単純および複雑なシステムの一連のアクションを記述します。 また、システムで発生するイベントについて、被験者にタイムリーに通知します。
データアクセス
説明
特定の作業段階で処理および表示されたデータへのロール管理アクセスのコンポーネント。
アクションのシーケンス
説明
情報処理におけるシーケンス制御のコンポーネント。
必要条件
アクションのシーケンスは、次のような制御構造によって説明できます。
-用語
-サイクル
自動トランザクション管理
説明
処理されたデータを使用した自動操作を記述するコンポーネント。
ルーティング
説明
サブジェクトへのオブジェクトのルーティングを記述するコンポーネント
効率、生産性、品質管理
警報システム
説明
システム内メッセージ、電子メール、およびrssを介して情報システムで発生するイベントに関する通知のサブシステム。
プラグインシステム
プラグインの例：
-オフィスアプリケーションへの統合
-バージョン管理システム
-グループカレンダー
プロジェクトのインポート、エクスポート
説明
あるプラットフォームから別のプラットフォームに移行し、カスタマイズされた情報システムを再利用できるメカニズム。
国際化
これらのコンストラクトについて説明した後、プログラマーの参加なしで既存のユーザー指向の情報システムを構築するために使用できるという結論に達しました（場合によっては、必要なプラグインを作成することで問題が解決されます）。 同じ目標を解決することを目的とした既存のクラスの情報システムBPMS（Bussines Process Management System）ですが、私の意見では重大な欠点があり、必要に応じて、ワークフローとデータモデルのグラフィカルモデリング用のアドインの形で、私の概念に統合できます。 残りの既存のIPクラスは、動的モデルとワークフローのメカニズムを実装していますが、私の意見では、まだ完全には実装されていません。
おそらく私は共通の真実を説明しましたが、私にとっては一種の発見でした。 したがって、次の投稿でこの概念を説明し、このIPの設計と実装の段階に進んで説明します。
銀の弾丸または中盤？
All Articles