文書管理システム導入は、移行で苦労します

お客様が文書管理システムの導入を検討するのは、ある程度の量の文書が蓄積し始めたときです。業歴が短い会社には管理すべき文書も少なく、最初はファイルサーバ上に保管用のフォルダを作ればおしまいです。

したがって、文書管理システムの導入時に最初に必要なのが、既に蓄積した過去文書をどうやって文書管理システムに登録するか、つまりはこれが「移行作業」です。

ファイルサーバから他の文書管理システムやクラウドサービスに移行する場合には、最初に全データのアップロードをともなう登録作業が必要になります。この作業はかなり骨が折れるため、一定時間以上古いデータは移行を断念することも珍しくありません。

移行が不要であればどれほど楽でしょうか?

ファイルサーバ+FileBlogはファイル移行が不要です

FileBlogは、もともとファイルサーバ向け検索エンジンから発展した製品であるため、既存のファイルサーバ上のフォルダ・ファイルにそのままアクセスできます。ですから、ファイル本体の移行が全く必要ありません。

そのうえで、ファイル・フォルダにタグと呼ぶ属性値を付加して、ファイル一覧をリッチにしたり、フォルダ検索時に属性をキー項目とすることが可能になります。

なおタグの値は、テキストファイル(CSVファイル)から一括登録可能ですので、管理台帳のExcelファイルを加工して一括インポートで移行が可能です。ファイル本体の総量に比べて、属性データはデータ容量が小さいため、移行に必要な所要時間も圧倒的に少なくなります。

従来ファイルサーバで運用してきた場合

既にファイルサーバで物件フォルダを運用しており、物件IDで整理できているがファイルの数が多く、Excelワークブックを物件管理台帳として利用してきた場合や、物件管理台帳DBを基幹システムで運用しているような場合は、ファイルサーバの物件フォルダをほぼそのまま温存して、単純にフォルダに属性として、管理台帳のデータを付与することで目的のファイルが早く見つかるようになります。既存のファイルサーバ上のファイルを移行することなしに、そのまま活用できるのが一番のメリットです。

場合によっては物件管理台帳DBを廃止することも可能ですが、あるいは業務システムで物件管理台帳DBが運用されている場合に、ある一定の期間ごとに物件DBからエクスポートした物件一覧にもとづいて物件フォルダの属性を自動で更新するといった運用もできます。

文書管理システムで運用してきた場合

文書管理システムからファイルサーバに戻したいというケースも時々あります。

文書管理DBの利用が定着しなかった場合

汎用の文書管理システムを10年くらい前に導入したけれど、登録が面倒で利用が定着せずにファイルサーバに回帰するというケースがあります。

本来は、建物が竣工したらただちに全ての文書や図面をDBにアップロードして属性を入力するというルールを決めていても、登録作業が面倒だと現場のユーザーはそのシステムから逃げるようになります。竣工直後でなくチェックが入る年度末などにアリバイ作りのために最低限の文書を登録するというようになってきます。

現場のユーザーは非公式のファイルサーバに最新のファイルを持つようになって、公式の文書管理システムは形だけになってしまいます。

こんなときは、現場で運用している非公式のファイルサーバを公式の文書管理システムに昇格させ、全文検索エンジンを組み合わせて運用するというのが、一つの現実的な解決策でしょう。

文書管理システムが老朽化・保守打切りになった場合

かつては、文書管理カテゴリに各社からさまざまなシステム製品が発売されていましたが、バブル崩壊後の日本経済の長期低迷ためか、開発停止に至った製品も少なくありません。

運悪くお客様のお使いの文書管理システムがその道をたどってしまった場合には、何とかして新システムにデータを移行しなければなりません。

一般的には、旧システムのデータをまずファイルサーバにエクスポート(取り出し)して、それから新システムにデータをインポート(取り込み)することになります。

文書管理システムにもいろいろありますが、どんなものでもファイルサーバにデータをエクスポートできないようなシステムは、ほとんどありません。FileBlogを使うと新システムへのインポート部分が一瞬で終わりますので、このケースでも移行費用が半分になります。

文書管理システムか、ファイルサーバ + 全文検索システムか

これまで、ファイルサーバ+FileBlogに向いているケースについて説明しましたが、やはり専用の文書管理システムが必要なケースはあります。契約書や見積書など1つの管理対象についてファイルが1つの場合、つまり1つの契約書に対して相手先情報や満期日などの日付情報などの区分を入れるようなものは、文書管理システムで管理したほうがいいでしょう。契約書管理や経費管管理など、専用の市販パッケージが安価で入手できる場合は、そういったシステムを買ってしまったほうが得策だと思います。

一方で、建築現場などで撮る写真や動画は、1つの管理対象にファイルが多数になるわけで、その場合はファイルサーバに放り込んだほうが楽です。特にこれらのファイルはサイズが大きいので、Web系のシステムやクラウドサービスにアップロードするのは本当に苦痛です。社内で管理しているファイルサーバにドラッグ&ドロップできるほうが、現場の業務がスムーズにまわります。

アーカイブデータを扱う場合もファイルサーバが有効です。基本的に文書というものは追加されて増える一方で、しかも長期保存が求められます。一定以上に古くなったデータは参照専用という場合も、ファイルサーバのほうが運用しやすいと思います。それに対して、公開前の文書で編集を頻繁に行うなど、ステータス管理やバージョン管理が必要で、かつ申請や承認のワークフロー管理が必要とされる場合は、専用の文書管理システムが向いています。

フローのデータや保存期間が数年でかまわないデータなど、長期保存が求められない場合はファイルサーバでなくてもいいですが、長期保存・長期運用が重要な場合はファイルサーバです。5年後、10年後にハードウェアを更新しながら運用するときに、ファイルサーバなら古いサーバから新しいサーバにデータをコピーする方法が既に確立されていて、コマンド1つで移行できます。そして、新しいサーバに同じシステムをインストールすれば、即座に同じように動かすことができます。

その他の応用事例

ここまで、建設会社や不動産会社などの物件フォルダ管理を例に、ファイルサーバと全文検索エンジンの活用を検討してきましたが、他の業種についてもIDでフォルダを作成して大量データを長期に保管・管理している例がいろいろとあります。

製造業:製品データ・クレーム対応履歴

製造業では製品データの管理において、製品図面を型番や図番で管理しているケースや、製造マニュアル、品質管理チェックリスト、ユーザーマニュアルなどを型番に紐付けて分類し、様々なファイル形式で保管しているケースがあります。また、クレーム対応の分野での利用例もあります。トラブルが起きた現場の写真や履歴、報告書などを長期間にわたって保存することが求められるケースです。

印刷・出版・デザイン・広告業:原稿データ

印刷・出版・デザイン・広告といった業種では、原稿データや案件データの長期保存にファイルサーバと全文検索エンジンを組み合わせて活用している例が多くあります。これらの業種では、成果物としてのポスターや冊子などの印刷データや原稿データ、あるいは写真やイラストなどの素材データを長期保存しています。印刷でいえば数年経って印刷物を再版する場合があり、広告でも定期的なイベントで前回時のパネルのデータを再利用することなどがあります。これらの業種が持つファイルは総じて解像度が高いので、データ容量が数十テラバイトになることも珍しくなく、ファイルサーバが好んで使われています。

人事データ・取引先データ

企業の人事部門や人材派遣会社の人事ファイル管理で、履歴書や職務経歴書、人物写真、各種証明書のデータを社員IDやスタッフIDで管理している例、また法務部門や経理部門において、取引先の登記簿や決算書、契約書、各種調査資料といったファイルを、取引先IDをベースに管理しているケースもあります。

IDでフォルダ管理するとフォルダが散らかることはそれほどありません。ただ、そのIDのフォルダを一発で見つけるために、IDを覚えていないけれども取引先名などで検索したいときには、先程説明したようにフォルダに属性を付与しておけばすぐに見つかります。

関連事例
物件/案件別文書保管
物件/案件別文書保管
情報への入り口を統一して、情報共有を大幅に効率化 - 建設業 設計・工事管理部門
物件/案件別文書保管
快適な情報共有の仕組みを実現 - 製造業(デザイン統括部門) 国内外の拠点からファイル共有をスムーズに

ご質問・ご相談はお気軽にお問い合わせください