PDF のバッチを処理するということは、すべてのファイルに同じ操作を適用することを意味することはほとんどありません。 10 枚の PDF が机の上に置かれます。 3 つは電子メールの圧縮が必要です。 2 つは編集のために Word に変換する必要があります。 4 つを 1 つのドキュメントに結合する必要があります。検索可能にするためには OCR が必要です。各ファイルには異なるツールまたは異なる操作が必要であり、ファイルごとにツール、インターフェイス、精神的コンテキストを切り替えるには、実際の処理よりも多くの時間がかかります。
処理中にオーバーヘッドは発生しません。ツール間の切り替えは常にコンテキスト内で行われます。
要件が異なる複数の PDF を 1 つのセッションで処理するということは、到着した順序でファイルを 1 つずつ処理するのではなく、操作の種類ごとにバッチを編成し、ツールごとにファイルをキューに入れ、各キューをバッチとして実行することを意味します。 WukongPDF の PDF Batch 処理ツールと Split PDF 機能はボリュームを効率的に処理し、以下のセッション編成方法は、使用する特定のツールに関係なく機能します。
操作タイプによる受信バッチの並べ替え
ファイルに触れる前に、各ファイルに必要な操作によってバッチ全体を並べ替えます。デスクトップ上に山、物理フォルダー、または精神的なカテゴリーを作成します: 圧縮、変換、マージ、OCR、署名など。各ファイルを適切な山に移動します。 50 ファイルのバッチを 2 分間ソートすると、処理中のコンテキスト切り替えが 20 分間節約されます。 1 つの山にあるすべてのファイルは、次のファイルに移る前に、1 つのツールと 1 つの設定セットを使用して一緒に処理されます。
複数の操作ファイルがパイル内を順番に流れます。 OCR とその後の圧縮が必要なファイルは、OCR パイルで開始され、その後圧縮に進みます。ファイルが進む前に、OCR パイル全体が処理されます。このバッチ規律は、脳が一度に 1 つの動作モード、つまりすべての圧縮ファイルに対して圧縮モード、すべての変換ファイルに対して変換モードを維持することを意味します。精神的なコンテキストの切り替えは、ファイルごとにではなく、操作の種類ごとに 1 回発生します。効率は、個々のファイルをより速く処理することではなく、スイッチを減らすことによってもたらされます。
キュー全体に対して各ツールを 1 回セットアップする
最初の操作タイプのツールを開き、そのキュー内のすべてのファイルに必要な設定を一度構成します。圧縮ファイルはすべて 150 DPI の中程度の品質が必要ですか?これらのパラメータを設定し、そのままにしておきます。これらの設定を使用してすべてのファイルを処理します。特定のファイルが実際に異なるパラメータを必要とする場合を除き、ファイルごとに調整しないでください。ファイルごとの調整はバッチ効率を破壊します。
体感速度にはキューの順序が重要です。最小のファイルを最初に処理します。それらは迅速に完了し、勢いを高める早期の勝利をもたらします。大きなファイルの処理は遅く、最初に処理すると、セッション開始時に非生産的な待ち時間が発生してしまいます。最初の小さいファイルは、セッションが進行するにつれてキューが加速し、次のキューを設定する間に最大のファイルが削除されることを意味します。セッションは、他のすべてが完了した後に 1 つの巨大なファイルを待つのではなく、満足のいく最終的ないくつかのファイルのリズムで終了します。
トラックを失わずに複数操作ファイルを処理する
システムが単純なテキスト ファイルであっても、複数の操作ファイルを追跡する必要があります。各マルチ操作ファイルをその操作シーケンスとともにリストします。完了した各操作にチェックマークを付けます。すべての操作がチェックされると、ファイルは出力フォルダーに移動されます。このチェックリストは、最も一般的なバッチ エラー、つまりファイルが操作 1 と操作 3 を受信するが、どのファイルがパイプライン途中にあったかを見失ったため、操作 2 が欠落するというエラーを防ぎます。
中間出力に明確な名前を付けます。 filename-step1.pdf、filename-step2.pdf のような規則により、各処理段階が識別可能に保たれます。ステップ 3 が失敗した場合は、ステップ 1 を再実行せずに、ステップ 2 の出力から再開します。中間ファイルは、最終出力が検証に合格した後にのみ削除してください。ディスク容量には数セントの費用がかかります。再処理時間には何ドルもの費用がかかり、より正確に言えば、取り戻すことのできない分がかかります。
| バッチサイズ | 組織方法 | 追跡ツール |
|---|---|---|
| 10ファイル未満 | 操作によって命名されたデスクトップフォルダー | メンタルチェックリストまたは付箋 |
| 10～50ファイル | 中間ファイルのフォルダー + 命名規則 | 単純なテキスト ファイルまたはスプレッドシート |
| 50～200ファイル | 構造化されたフォルダー階層 + 一貫した名前付け | ステータス列を含むスプレッドシート |
| 200以上のファイル | 専用のバッチ処理スクリプトまたはツール | データベースまたはプロジェクト管理ツール |
さまざまなツールにわたる品質チェックの管理
処理と同様に、ツールごとに品質チェックをバッチ処理します。圧縮キューが終了したら、すべての圧縮ファイルを 200% ズームで並べて確認し、アーティファクトをスキャンします。変換キューの後、フォーマットの忠実度をチェックして、変換されたすべてのファイルを検証します。操作タイプによるグループ化検証には、グループ化処理と同じバッチ効率の原則が適用されます。
各バッチの割合を抜き取り検査します。 50 個の圧縮ファイルのうちランダムに選択された 5 個は、50 個すべてをチェックしなくても系統的な問題を検出します。スポット チェックがクリーンであれば、バッチはおそらくクリーンであることを意味します。スポットチェックで問題が発生した場合は、チェック率を高め、設定の調整が必要かどうかを調査します。統計的サンプリングは、大規模なバッチ内のすべてのファイルを検証する時間が誰もないという現実と徹底性のバランスをとります。
バッチ途中でファイルが失敗した場合の回復
キューを停止せずに、失敗をすぐに再試行フォルダーに移動します。次のファイルに進みます。キューが完了したら、もう一度注意して再試行フォルダーにアクセスしてください。場合によっては、エラーが一時的なもの、サーバーのタイムアウトまたはメモリの中断によるものであり、再処理が成功することがあります。また、ソースの破損やサポートされていない機能など、本質的に障害が発生しており、ファイルへの手動介入が必要な場合もあります。
ファイル名、操作、エラー メッセージ (ある場合)、および時刻をそれぞれログに記録します。このログからパターンが明らかになります。同じファイル タイプが複数のツール間で同じ操作に失敗する場合は、そのファイル タイプに問題があることが示唆されます。同じツールで異なるファイルが同じようなタイミングで失敗する場合は、ツールの信頼性に問題があることが示唆されます。ログは、孤立した迷惑行為による個々の障害をデータに変換し、ツールやワークフローの意思決定を改善します。
今後の参照のためにセッションをアーカイブする
セッション後、バッチの詳細 (どのファイル、どの操作、どの設定、出力がどこに送信されたか) をアーカイブします。これには 2 つの目的があります。後でファイルに問題が発生した場合、アーカイブは、いつ、何が行われたかを正確に追跡します。来月同様のバッチが到着した場合、アーカイブにより、再計画することなく複製可能なワークフローが提供されます。
ファイル名、操作、ツール、設定、出力場所を含む単純なスプレッドシートにすべてが記録されます。 2 分で入力すれば、同じバッチ パターンを繰り返す場合の再計画の時間が 20 分節約されます。再利用可能なワークフロードキュメントコンパウンド。文書化されたすべてのバッチにより、そのタイプの次のバッチが高速化されます。投資は前倒しで行われますが、収益は永続的です。