電子文書管理システムのアプリケーション。 パート1：主要な原則、コンポーネント、機能

この投稿では、電子文書管理システムでのアプリケーション開発のさまざまな側面に関する短いシリーズの記事を開始します。 現在、多かれ少なかれ強力な最新のEDS / ECMプラットフォームには、その実装用のコンポーネントとツールのセットが含まれており、プラットフォームに基づいて作成されたアプリケーションが、さまざまなクライアントワークフロー全体を自動化します。 Docsvisionプラットフォームのアプリケーションモデル、これらのアプリケーションのコンポーネントと開発ツール（設定）、開発用のツールを実装する際に遭遇した問題、および将来の展望についてお話します。 これは、Docsvisionと緊密に連携する人だけでなく、企業のEDMSを実装または開発する必要がある人も経験を積むことができるようになります。



最新のEDMSの適用。 用語を定義しましょう。



最新のEDMS / ECMプラットフォームは、さまざまな規模の企業でさまざまなドキュメント処理プロセスを自動化するためのツールです。 実際、プラットフォーム自体には完全なクライアント機能は含まれていませんが、プラットフォームに基づいてアプリケーションを迅速に作成するための一連のサービス、コンポーネント、およびツールを提供します。 この状況は、特定の企業の特定のプロセスを考慮に入れて、各実装が大幅なカスタマイズを必要とするERPプラットフォーム（Enterprise Resource Planning）の状況にやや似ています。 ただし、EDMSの特定の自動化プロセスの変動性のレベルはERPの場合よりもさらに高くなります。実践により、EDMS / ECMプラットフォームが使用されるタスクの範囲は、今日では事実上無制限です。



用語を定義しましょう。

EDMSの適用により 、特定の一連のタスクを解決するための特定の分離されたワークフローの自動化ツールを呼び出します。

EDMS / ECMプラットフォームの標準と標準要件のセットはまだ利用できないという事実にもかかわらず、多かれ少なかれ強力なプラットフォームには、アプリケーションを実装するためのコンポーネントとツールのセットが含まれています。 また、異なるプラットフォームで実行されるアプリケーションの構造は大きく異なる場合があります。 この一連の記事では、Docsvisionプラットフォームに基づいて作成されたアプリケーションの構造を見ていきます。 前述したように、この情報は、同様のアプリケーションの開発に関与する企業のビジネスアナリストにとって有用です。



EDSアプリケーションの概念。 アイデアから建築まで。



時系列で説明し、現在のプラットフォームアーキテクチャ（2000年に始まった）の開発に先行するものについて、いくつかの言葉から始めます。 アプリケーションの実装にはすでに豊富な経験があります：最初に、異なるプラットフォームに基づいて、次に約12のプロジェクトを実装し、閉じて完全に書き直さなければならなかったDocsvision 1.0プロジェクトの経験がありました（アプリケーションモデルを含む新しいアーキテクチャについて説明します） 、はるかに適切であることが判明し、現在も開発中です）。 さまざまなソリューションを使用したこの経験により、統合EDMSで次のアプリケーションコンセプトを形成するためのいくつかの重要なアイデアを強調することができました。

• プラットフォームは、「ロシアのワークフロー」の純粋に特定のタスク（電子文書のアーカイブを管理および作成するための文書化サポート）の自動化だけでなく、アプリケーションの作成を許可する必要があります。 いわゆるドキュメント中心のプロセス-ドキュメントが処理の中心的な対象であるプロセス-の広範な自動化を提供する必要があります。
• 文書処理プロセスには、さまざまな種類の文書（複雑なライフサイクルとビジネス処理ロジックを持つ構造化および非構造化データを含む）を含めることができます。 処理中に、あるドキュメントから別のドキュメントに情報を転送できます。
• アプリケーションは分離されていません。 1つのアプリケーションで生成された情報を他のアプリケーションに転送できます。
• EDMSプラットフォームに基づいたアプリケーションによって自動化されたプロセスには、特定の組織ごとに固有の特徴があるため、実装中にアプリケーションを調整する必要があります。
• 特定の組織のプロセスも安定しておらず、多くの場合変更できます。
• さまざまな組織での最も一般的なタスク（およびそのプロセス）のばらつきはそれほど大きくないため、既製の「ボックス化」アプリケーションの可用性が必要です。 （今日、私たちのEDSのそのようなアプリケーションは、「事務作業」、「契約管理」、「市民の訴え」、「会議の管理」および他のいくつかです）。

これらのアプリケーションは、次の2つのシナリオで使用できます。

-AS-ISの実装（リエンジニアリングの実装、組織がアプリケーションの機能に応じてビジネスプロセスの既存の構造を変更する準備ができている場合）。

-最初のベースとして、実装のリエンジニアリングが不可能な場合に組織のプロセスの詳細を考慮して修正。

• 特定の業界または組織に深く固有のアプリケーションを最初から作成する機能をサポートする必要があります。
• さまざまなアプリケーションには、共通の機能、データ要素、およびアクセスコンポーネントが含まれる場合があります。 たとえば、ストレージおよびファイル管理ツール、共有ディレクトリ（請負業者、従業員）、ドキュメントカテゴリ、さまざまなアプリケーションのドキュメント間のリンク、通知ツールなど。すべてのアプリケーションのこれらの機能とデータを操作するための一般的なメカニズムをサポートする必要があります。
• さまざまなアプリケーションからドキュメントへのアクセスを提供する、ナビゲーション、検索、集計されたデータの表形式表現を提供する統合ツールが必要です。 たとえば、作成されたアプリケーションに関係なく、特定の取引先へのリンクを含むすべてのドキュメントを検索します。
• アプリケーションはEDSのフレームワーク内で分離されておらず、企業情報システムの他のサブシステムとの統合が必要になる場合があります。

もちろん、これらの要件により、EDMSアプリケーションを従来の方法で実装することはできません（個々のアプリケーションの独立したコーディング）。 明らかに、アプリケーションの迅速な開発と変更のために、すべてのアプリケーションとツールを統合するプラットフォームが必要です。



プラットフォームアーキテクチャ



幸いなことに、新しいプラットフォームアーキテクチャの形成時には、さまざまなクラスのシステムでの作業経験がありました。

• コラボレーションアプリケーション開発プラットフォーム（Lotus Notes、Microsoft Exchange）、
• Document Management System（DMS）クラスのシステム、ECMの概念はまだ存在していませんでした。
• ワークフローシステム（「BPMシステム」という用語は、まだワークフローエンジンを含むツールにそれほど無差別に適用されていませんでした）。

これらのクラスのプラットフォームは、まったく異なるイデオロギーとアプリケーションモデルを備えていましたが、それらはすべて、クライアントが必要とするドキュメント処理アプリケーションの作成にある程度適用できました。 確かに、それらのどれも完璧ではありませんでした。 グループ作業プラットフォームは、構造化されたドキュメント情報を操作するための便利なナビゲーションツールと優れたツールを提供しました。 DMSシステムにより、非構造化データ（ファイル）を操作するための完全なメカニズムセットを実装でき、ワークフローツールは、ファイルと電子フォームのドキュメントルーティングと処理シーケンスの編成に非常に適していました。



問題は、上で定式化された要件 （プロビジョニング）を満たすアプリケーションを実装できるプラットフォームを作成するために、1つのプラットフォームだけでは十分ではなかったことです。 たとえば、当時のロータスノーツシステムには、非構造化情報を処理するための非常に弱い機能（RTFフィールドにファイルを保存する機能）があり、プロセスモデリングツールが完全に欠けていました。 さらに、プラットフォーム（データベース）に基づく各アプリケーションは情報的に分離されており、アプリケーション間の相互作用の組織化には開発者であるコーダーの多大な努力が必要でした。

その結果、Docsvisionプラットフォームの新しいバージョンのアーキテクチャは、これらのシステムのアプリケーションモデルの利点を組み合わせたアプリケーションモデルに基づいていました。



Docsvisionアプリケーションモデル、5つのコンポーネント



Docsvisionアプリケーションモデルには、次の主要コンポーネントが含まれています。

1.カード -システムのメインオブジェクト。これにより、任意のアプリケーションアプリケーションオブジェクトをシミュレートできます。 EDMSアプリケーションの最も一般的なオブジェクトは、ドキュメント（着信、発信契約）およびタスク（実行タスク、承認タスク）のカードです。



2.ディレクトリ -システム内に1つのコピーとして存在する特別なタイプのカードで、特に階層的に編成された、最も多様な背景情報を保存できます。





図1 Docsvisionアプリケーションカード



3.プロセス -アプリケーション内、相互接続されたアプリケーションのグループ内、またはシステムレベルで一連のアクションをシミュレートするオブジェクト。 プロセスには、プロセスを処理するロジックを確保するために、手動ステップ（カードまたは外部オブジェクトとのユーザーインタラクション）とサービスによって実装される自動ステップの両方が含まれます。







図2。 Docsvisionプロセス



4.フォルダー -カードのグループ化を提供するオブジェクト。 システムには通常のフォルダーがあります-その中に作成されたカードをグループ化するか、ラベルをカードに物理的に配置することにより（ファイルシステムフォルダーと同様）-特定の基準に従ってカードをグループ化する仮想フォルダー（検索結果）



5.プレゼンテーション -表または行のセットの形でのカードのセットのグループプレゼンテーション。 表のセルには、カードの属性、その集計、および決済操作の結果が表示されます。







図3 Docsvision EDSアプリケーションのフォルダーとプレゼンテーション



ロータスノーツシステムのファンは多くの類似点を見たに違いありません。これは事実です。Docsvisionはこのシステムから多くを継承しました。 ただし、プラットフォームをゼロから開発しました。これにより、Lotus Notesの制限の多くが回避され、Docsvisionに多くの有用で建設的なアイデアが実装されました。

アプリケーションは、上記の要素の特定のセットの組み合わせです。 また、上記のアプリケーション要件を満たすために、次の機能が実装されました。







図4 Docsvisionアプリケーション構造



新しいアプリケーション機能

• 各アプリケーション要素（カード、プロセス、フォルダー、およびプレゼンテーション）は、残りのコンポーネントを変更せずに変更できます。 たとえば、ドキュメントの承認シーケンスが変更された場合、アプリケーションの他のコンポーネントに影響を与えることなくプロセスを再構築できます。 新しい機能要件が発生すると、アプリケーションで新しいオブジェクトを作成し、既存のオブジェクトに接続できます。
• リストされているすべてのシステムコンポーネントには、「プログラミングなし」でアプリケーションを作成し、すでに実行中のアプリケーションを簡単に変更できるインタラクティブなデザイナーがいます。
• 低レベルのプログラミングインターフェイスがサポートされており、インタラクティブなモデリングツールでは利用できない機能を実装できます。
• 個々のアプリケーションは互いに分離されておらず、個々のアプリケーションオブジェクトへのアクセスはアクセス権によってのみ制限されます。
• システム内のすべてのアプリケーションは、共通の参照情報構造を使用します。
• 1つのビジネスプロセスで、さまざまなアプリケーション内で作成されたオブジェクトを処理できます。
• 1つのフォルダーで、さまざまなアプリケーションで作成されたカードをグループ化できます。
• 1つのビューには、さまざまなアプリケーションで作成されたカードのデータを表示できます。
• あるアプリケーションのカードには、ユーザーがアクセス権を持つ他のアプリケーションのカードへのリンクが含まれる場合があります。

クライアントコンポーネント（ナビゲーターなど）は、ユーザーにナビゲーション、検索、およびすべてのアプリケーションのデータとアクセス権が付与されている参照データへのアクセスの統合システムを提供します。

説明した新しいアプリケーションモデルの機能は、すべてのアプリケーションを単一の統合環境に配置する問題を解決しながら、Docsvisionで完全に異なる業界向けの最も多様なソリューションを実装するための基盤を提供しました。

次の記事では、Docsvisionアプリケーションモデルの個々のコンポーネントを詳細に調べ、これらのツールを使用した特定のソリューションの実装例を示します。



PS最近、専門家は、ECM、BPM、グループウェア市場の統合、およびこれらの技術の利点を組み合わせた新しいプラットフォームパラダイムの誕生を祝い始めました。 私たちはこれらの傾向を満足して観察します。 15年前にこの収束の必要性を認識し、さらに特定の製品に実装しました。