DC-BPM · ①プロセス上、文書を排除しきれない：購買・調達など、他社との文書のやり取りが主となる業務プロセスにおいては、FAXや

特集

38 富士ゼロックステクニカルレポート No.19 2010

DC-BPM Document Centric-Business Process Management

要旨企業を取り巻くさまざまな環境の変化を受けて、企

業内プロセスの継続的改善を行なうことで、企業全体のパフォーマンスアップを目指す BPM (Business Process Management)のアプローチや、それを実現させるソリューションに注目が集まっている。しかし、既存のシステム導入を前提とした BPM のアプローチには問題も多く、BPM の目指す継続的改善を達成できていないケースも多かった。本稿では、これらの問題を明らかにし、これを解決するために、「文書」を構成要素の中心に置いた新しい BPM アプローチ―Document Centric-BPM―を提案する。併せて、構想を実現するプラットフォーム、適用事例を紹介する。

Abstract 執筆者小松裕（Yutaka Komatsu）伊藤泰（Yasushi Itoh）大橋俊也(Toshiya Ohashi) ソリューション本部ソリューション開発部 (Solution Development, Solution Group)

These days much attention is being paid to the Business Process Management (BPM) approach and solutions to meet a company's BPM needs due to various environmental changes now affecting corporations. BPM is a method of improving the business performance of an entire organization by continuously optimizing its business processes.

In many cases, however, continuous improvement sought by BPM is not achieved because the current BPM approach is based on implementing systems, thus posing certain issues with this approach.

This paper discusses actual examples of these issues and then describes our proposed solution: "Document Centric BPM," a new BPM approach where “documents” become the central hub of configuration elements. The paper also introduces a platform to realize this concept and gives some case examples.

特集

DC-BPM

富士ゼロックステクニカルレポート No.19 2010 39

1. 序

企業の IT 化が進み、ERP（Enterprise Resource Planning ）、 CRM （ Customer Relationship Management）などの基幹システムが整備された結果、売り上げ・利益・顧客動向などの企業活動のアウトプットがリアルタイムに把握できるようになった。それに伴い、アウトプットを定量的に把握・改善できない業務プロセスは、それ自体が経営リスクととられるようになってきている。このような環境変化を踏まえ、企業のパフォーマンスを定量的に表現するアプローチに注目が集まっている。代表的なものが、企業活動のプロセスに着目し、プロセスの継続的改善を目指す BPM（Business Process Management）である。この論文では、文書を中心に BPM の実現を目指すDC-BPM(Document Centric Business Process Management)の意義と構想、それを支える富士ゼロックスの強み、適用事例、将来展望を明らかにする。

2. DC-BPMとは

2.1 BPMと BPMS BPMとは、組織活動のプロセスに着目した考え方で、プロセスに対し、「設計」「実行」「モニタリング」「改善」のサイクルを繰り返しながら、継続的に改善させようという考え方である。これはTQCにおけるPDCA(Plan Do Check Action)、リーンシックスシグマにおける DMIAC(Define Measure Analyze Improve Control)に相当する（図1）。

このBPMの考え方をITシステム上で実現したものがBPMS(BPM System/BPM Suite)である。 BPMS には明確な定義が存在しないが、システム化を念頭に置いたアプローチとしては、企業内のあらゆるプロセスをデータ化し、それらデータを統合的に管理することで、経営者が企業の状態を分析/改善できるようにする、といったコンセプトが一般的である。フェーズごとに以下に挙げるような機能を持つシステム/ソフトウエアまたはコンサルティングなどの人間系サービスが存在し、それらを組み合わせて提供されることが多い。設計：モデリング・シミュレーション実行：ワークフローモニタリング：データ統合管理改善：データ分析 2.2 BPMSの問題点既存BPMSで問題となるのが、紙文書主体のプロセスである。データ化できないプロセスは統合管理できないため、紙文書プロセスは、「設計」段階で同等のシステム処理に置き換えなければならない。たとえば、「営業部員が契約書に必要事項を記入し、上長の印をもらって関連部署に送付する」というプロセスに対しては、「契約管理システムに必要事項を入力すると、ワークフローシステムが起動し、上長承認・他部署への送付などはワークフローシステム上で行なわれる」といった具合である。しかし、現実には以下に挙げるようにシステム処理に置き換えることが困難な紙文書プロセスが多々存在する。 ①プロセス上、文書を排除しきれない：購買・調達など、他社との文書のやり取りが主となる業務プロセスにおいては、FAXや郵送、e-mail によるファイル添付などの文書到着・発行をトリガーとして業務プロセスが実行される場合が考えられる。このように他社とのやり取りを主とするプロセスの場合、完全に紙文書を排除するには他社の業務までシステム化しなければならず、現実的ではない。

1. 設計 2. 実行

3. モニタリング4. 改善

業務フローを定義する

フローに沿って業務を実行する

監視内容を分析し、問題点を抽出する

実行状況を監視する

図 1. BPM サイクル

BPM cycle

特集

DC-BPM


② 環境上、文書を排除しきれない：工場や倉庫など、物理的に IT システムを配置しづらい現場や、精密計測機器などプロセス上重要なシステムが紙出力しかサポートしていない場合など、システム化に際して費用対効果が見合わない場合が考えられる。また、外部協力会社に処理を委託するため、自社のIT システムにログインさせたくない場合や、システム利用対象ユーザーが IT に不慣れで教育に膨大な労力を必要とする場合などもこれに相当する。このような場合、回避策として、「プロセスではなく（データとして補足可能な）結果値のみを管理する」といった運用がされがちであり、プロセスの中で行なわれている業務の詳細は見えなくなってしまう。 ③プロセスがノウハウの塊である：文書が主体のプロセスにおいては、プロセスやそこで流れる文書、それを扱う人々に長い間少しずつノウハウが蓄積される例も少なくない。また、事務処理などの定型的な作業ではなく、製造業における設計業務や、ソフトウエア開発など、職人的な意味合いを持つ作業においては、アウトプットは変わらずとも、作業のやりかたが流動的に変化することも起こりうる。このような固有の事情を鑑みず、画一的にワークフローシステムや自由度が低いシステムに置き換えた結果、個々人の業務ノウハウや工夫の結果が表現しきれず、システム化したとたん融通が利かなくなり、業務効率が著しく低下する、といった事態が起こり得る。上記に挙げたように、現実の業務プロセスには、既存のアプローチで単純にデータに置き換えることができない紙文書プロセスが多数存在する。このような状態でシステムありきのBPMSを導入しても、あちこちに「中身の詳細が見えないプロセス」が散在した状態でしか管理できず、コンセプトである「あらゆるプロセスデータの統合管理」をベースとした BPM が実現できない。これが既存BPMSの最大の問題点である。

2.3 DC-BPM DC-BPMとはこれらの問題点を鑑みて、データではなく文書を中心に考える富士ゼロックスの BPM 構想である。これは、業務プロセスのアウトプットや状況はなんらかの「文書」で表現されているはずで、その「文書」を基本的な構成要素に据えて BPM を実現させようというコンセプトである。ここでいう文書とは紙文書、電子文書など、形態を問わない。図 2 にDC-BPMのフェーズサイクルを示す。

上図と、図 1BPMサイクルを比べてわかるように、DC-BPMのサイクルは通常のBPMに「文書」の考え方を付加したものになっている。これにより、前節で挙げたようなデータ化できない紙文書も、サイクルに取り込めるようになり、問題は解決する。 2.3.1 DC-BPMビジネスアーキテクチャこの考え方をサポートするために、「実行」「モニタリング」フェーズにおいて、文書を（データに変換するのではなく）文書として扱うことができるプラットフォームを採用する。以下に示すのが、プラットフォームのビジネスアーキテクチャである（図 3）。中核には文書イメージとそのメタデータを統合的に扱うコンテンツデータベースと、業務プロセス定義を保持するプロセスデータベースが存在し、モニタリングモジュールが業務プロセス定義と実文書（＝業務実行結果）を関連づける。それらと、複合機からのコンテンツデータベースへのドキュメントフローを制御するソフトウエアや、他社BPMS/基幹システムとの連

図 2. DC-BPM サイクル

DC-BPM cycle

1. 設計 2. 実行

3. モニタリング4. 改善

業務フローを定義する

フローに沿って業務を実行する

監視内容を分析し、問題点を抽出する

実行状況を監視する

業務フロー内の文書の流れを定義するKPIに関連する重要文書を洗い出す

業務フロー内の文書の流れを定義するKPIに関連する重要文書を洗い出す

各実行ステップにおける文書の生成/更新を補足する

各実行ステップにおける文書の生成/更新を補足する

文書から解析用データを抽出する文書から解析用データを抽出する文書生成/更新状況と文書内容とをフロー定義と併せ、現況を表示する

文書生成/更新状況と文書内容とをフロー定義と併せ、現況を表示する

特集

DC-BPM


携を行なうミドルウエアとが連携して動作する。構成要素の組み合わせ方により、単独でBPMS としても動作可能であるし、既存のBPMSが持つデータ統合アーキテクチャに合致させることも可能である。また、プラットフォームの構成要素は既存製品・技術で構成されており、安価に構築が可能である。このプラットフォームでは、業務担当者は、日々の業務で発生する文書をコンテントデータベースに登録することさえできればよい。プラットフォーム上で紙文書と電子データは相互変換可能な状態であるため、企業活動の分析が必要な場合はデータを提供し、現場業務担当者が紙証跡を必要とする場合は文書形態を提供することができ、既存の業務プロセスの形態を無理に ITシステムに置き換えることなくBPMを実現することができるようになる。しかし、これを実現するのは簡単なことではない。各業界/業種における業務のプロセスとそこに存在する文書や問題点を、正しく把握/解析できる人材や経験に加え、基幹システム、他社BPM システムなどの各種データシステムと紙文書を連携できるようなシステム基盤が必要である。もちろん、紙文書の入出力のインターフェイスとなる複合機の機能も重要である。次章では、富士ゼロックスの強みであるこれらの構成要素について解説する。

3. DC-BPMの基盤となる商品・技術

DC-BPM を業務システムとして安価に実現するには、基盤となる商品や技術が既に存在することが前提となる。本章では富士ゼロックスが有する DC-BPMの基盤となる商品や技術を 2章で紹介したアーキテクチャに沿って紹介する。紹介した商品や技術が 4章「事例紹介」で登場する。 3.1 コンテンツデータベース DC-BPM 基盤としてのコンテンツデータベースには、業務プロセスインスタンスの ID や、進捗（予定、実績日時）や状態（終了、中止など）を決定する際に必要となる属性情報を紙文書イメージとともに格納できることが必須である。加えて、アクセス権管理、版管理、スケーラビリティなど大規模な記録管理のための基本機能や他システムと連携するためのインターフェイス（Webサービスなど）も必要である。富士ゼロックスでは上記要件を満たす文書管理システム ArcSuite を既に商品として販売している実績があり、DC-BPM の基盤としてArcSuite をベースに開発された Apeos PEMaster Evidence Manager を採用している。 3.2 ドキュメントフロー制御 DC-BPMでは、お客様の業務文書の授受作業を、複合機上の操作によるコンテンツデータベースへの入出力に置きかえる必要がある。この入出力を実現する際には、以下の要件がある。 ① 複合機からコンテンツデータベースに業務文書を入出力できる。このとき、お客様が既存の授受作業から違和感なく簡単に複合機上での操作に移行できるように、複合機の操作画面のカスタマイズが柔軟に行なえることが重要である。

② 入力後や出力前の業務文書に対してさまざまな処理を行なうことができる。入力後の処理には、たとえば、業務関係者に入力文書をメール送信することがある。出力前の処理には、たとえば、顧客情報のような業務案件固有の情報を文書に埋め込むなどがある。実行する処理は業務によりさまざま

図 3. DC-BPM ビジネスアーキテクチャ

DC-BPM Business Architecture

業務プロセス業務プロセス

DCDC--BPMBPMソリューションソリューション

基幹システム

他社

BPMS

人人システムシステム人

P

DC

A P

DC

Aプロセスモデルビジネスルール

ワークフローコラボレーション

定期点検監査

改善管理レポーティング

エビデンス成果物

モニタリング

コンテンツデータベース

プロセスデータベース

XPDLBPMN

SOA

DCDC--BPMSBPMS

人材教育体制構築業務可視化プロセス設計

特集

DC-BPM


となるため、処理フローを柔軟に組み替えられることが重要である。

すでに富士ゼロックスは、上記要件①・②を実現の基盤となる商品技術を有している。要件①に対する基盤技術はApeosPortである。ApeosPortは操作パネル上でのWebブラウザ表示機能と Web サービス連携フレームワークであるApeos iiX1)を持つ複合機である（図 4）。 Apeos iiX を使うことで、WebサービスからApeosPort 上での処理（スキャン、FAX、電子メール、FTP転送など）をコントロールできる。

①を実現するには、ApeosPort の操作パネル上のWebブラウザに、お客様の業務に合わせた入出力操作画面を表示するWebアプリケーションを作成すればよい（図 5）。このとき、Webサービスは、お客様の画面上での操作に応じてiiX連携によりApeosPort をコントロールする。要件②に対する基盤技術は ApeosWare とPGA（Process Gateway for Apeos）2）である。 ApeosWare とは Apeos iiX 連携により実現されるドキュメントフロー制御を強化・補助する富士ゼロックスのソフトウエアの総称である。 ApeosWare の一例として、ApeosWare

Flow Service（AWFS）がある。AWFSは文書の入出力先と、文書を処理する部品を自由に組み合わせて多様な処理フローを実現する。AWFSの部品には、イメージ処理、フォーマット変換、OCR処理、QRコード解釈やコンテンツデータベースへの登録、電子メール送信、FAX送信などがある。 PGA は基幹業務プロセスと紙文書プロセスの統合を実現するミドルウエアである。基幹システムと ApeosPort などで電子化した紙文書を連携させる機能を提供する。 ②を実現するには、上述の各ドキュメントフロー制御技術の組み合わせればよい。たとえば、複合機から入力された文書を、業務関係者にメール送信した後、コンテンツデータベースに登録したければ、AWFSのメール送信部品とコンテンツデータベース登録部品を組み合わせればよい。 3.3. モニタリングモジュール DC-BPMを実現するには、コンテンツデータベースに蓄積された文書とメタ情報を、個々の業務プロセスに変換してモニタリング用に整形表示する仕組みが必要である。DC-BPM基盤のモニタリングモジュールがその仕組みを担う（図6）。

図 4. Apeos iiXApeos iiX

見積　発注　支払

　見積発注

見積

　見積　発注　納品　支払

調達ID:X001

調達ID:X002

調達ID:X003

調達ID:X00n

・

・

・

EvidenceManager

証跡

収集元

EM Workflow

others

調達ID:X001文書名:見積書

調達ID:X001文書名:発注書

調達ID:X001文書名:請求書

証跡群

どの収集元から取得したデータであっても、「証跡」として扱われる。

証跡＝属性名と値の組

業務定義

証跡収集

証跡収集

証跡収集

業務定義には、証跡をどう分類するかと、証跡と業務の関連性を記述する

業務インスタンス群

調達ID:X00n文書名:請求書

振り分け

振り分け

振り分け

振り分け

　支払

　支払　納品

　納品

納品

　発注

「請求書」と「経理処理依頼書」がちゃんと存在するので、この業務ステップは進捗BLUE

Database

証跡収集

図 6. DC-BPM モニタリングモジュール DC-BPM Monitoring Module

図 5. ApeosPort 操作パネルの画面例 An example of ApeosPort operation panel

特集

DC-BPM


モニタリングモジュールは、個々の業務プロセス・ステップの進捗状態を予め用意された業務定義に従って可視化する。業務定義は、業務プロセス・ステップの進捗状態と、文書の登録状況やメタ情報（発行日や発行者などの文書属性）および基幹システム・業務システム上のデータとの対応関係を定めるものである。 3.4. まとめ本章では DC-BPM の基盤となる商品・技術を紹介した。これらの商品・技術は、ドキュメントに関するソリューションを通じて培ってきたものである。当然のことながら商品・技術だけではソリューションは成り立たない。DC-BPMソリューションにおいては、業務プロセスの可視化・整流化・改善、システム構築などを実施できる人材が重要である。富士ゼロックスはドキュメントソリューションを長年行なっており、商品だけでなく、上述の商品を組み合わせてお客様の課題を解決してきた人材も有し、DC-BPMを実現する体制が整っている。

4. 事例紹介

受注生産型製造業のお客様向けに提供したDC-BPMソリューションの事例を紹介する。 4.1 課題・要望お客様の製造プロセスでは、部品組立工程の一部を外部業者に委託している。図 7に示すようにこの業務プロセスは、外部業者への見積り、発注、外部業者への部品・材料支給、外部業者からの納品という流れとなっている。この業務プロセスにおいて、お客様と外部業者間で行なわれる見積りや材料の手配などは、各業務ステップの担当者や部署による個別の

FAX・紙文書の受け渡しで行なわれていた。お客様は、この業務プロセスをシステム化し、進捗を可視化することができずにいた。システム化できなかった理由は、受注生産という業態上、外注とのやりとりも様々となり、紙文書を排除して完全にシステム化するのが困難であるためである。また、「２.2. BPMSの問題点」の①でも述べたように、外注先の業務も含めて ITシステム化することはコスト的に非現実的であるからである。この状況において、お客様は以下の課題を抱えていた。 ① 業務プロセスの進捗をリアルタイムに把握できないため（特に外部業者の進捗を把握できていなかったため）、納期遅延リスクに対して早期に対応できない。

② 現場従業者が外部業者とのやり取りを含む業務プロセスの状況を把握するために無駄な工数がかかる。

③ 業務プロセス改善に必要となる外注部分を含む業務プロセスの実施データ、指標を得られない。外注業者のパフォーマンスを測定できないため、業者を選別できない。

図 8に、お客様の課題の原因となっている部品組立工程進捗の可視化の現状（本ソリューション導入前）と本ソリューション導入後の改善された状況を示す。

4.2 ソリューションこのソリューションでは、業務文書をDC-BPM のコンテンツデータベースに格納し、モニタリングモジュールで業務プロセスの進捗状況を可視化するアプローチをとっている。このアプローチによる可視化の結果として、

図 8. お客様の課題 The Customer’s problems

納入希望日

材料支給予定日納入日実納入日納入予定日材料実支給日

Ｇａｐ見えないＧａｐ見えない

進捗見えない

Ｇａｐの把握

→内部コントロール可能

Ｇａｐ情報の先取り

→組み立て工程改善

実リードタイムの分析因子抽出

見積依頼日

督促日

遅延督促

ソリューション導入前（ASIS)

ソリューション導入後（TOBE)

★DC-BPMソリューション導入により可視化されること。

Ｇａｐの把握

★進捗や予定と実日とのGAPが見えない。

図 7. お客様の業務プロセス The customer’s business process

見積発注材料支給治具貸出

納期確認納品

外部業者

お客様

外部業者外部業者

見積発注材料支給治具貸出

納期確認納品

外部業者

お客様

外部業者外部業者

特集

DC-BPM


図 9に、お客様が進捗状況を確認するために用いるモニタリングモジュールの画面を示す。ソリューションは以下のステップで行なわれた。 ①業務フロー図の作成と、プロセスのパフォーマンス測定に必要となる重要文書の抽出

②抽出された紙文書のスキャン登録を含めた整流化された新業務プロセスの設計

③新業務プロセスのためのシステム設計・構築ステップ①では業務プロセスを分析し、プロセスをステップで区切り、業務フロー図を作成した。また、見積、発注、材料支給などの各ステップと文書との対応関係およびパフォーマンス計測に必要なデータと文書との関係性を特定した。たとえば、実支給日を把握するためには材料支給票の受け渡し捕捉が必要であることを明らかにした。ステップ②では業務文書をコンテンツデータベースで一元管理するための新しい業務プロセスを設計した。新業務プロセスは、現業務プロセス中のステップ①で特定された紙文書の受け渡し業務が、ApeosPort によるスキャン登録作業に置きかえられたものである。業務プロセス変更により作業効率が落ちることがないように、お客様のApeosPort による作業は、操作パネル上に表示されるメニューからスキャンする文書を選択するだけとした。ステップ③ではシステム設計・構築を行なった。ステップ①でコンテンツデータベース上の文

書・メタ情報と業務プロセスとの関係が定まり、ステップ②で ApeosPort によるスキャン作業が定まっているので、ステップ③ではApeosPort とコンテンツデータベース間のドキュメントフローを実現する仕組みを主に設計・構築した（図 10参照）。 ApeosPort からコンテンツデータベースへのスキャン文書登録のフローは、3 章で述べたApeosPort と Web サービス（図中のジョブ登録サービス）との iiX 連携と、お客様サイト内のサイトオペレータによる文書登録作業により実現した。ジョブ登録サービスが、お客様によりスキャンされた文書と作業指示のセットをサイトオペレータに渡すかたちとなっている。このフローでは、可視化・データ集計のための必要なメタ情報（属性）を文書に付与する作業を行なうのはサイトオペレータである。新業務プロセス設計において、お客様のスキャン作業を ApeosPort の操作パネル上で文書種類を選択するだけで行なえるようにしたためである。 4.3 導入効果課題①と課題②は、外部業者とやりとりされる紙文書をコンテンツデータベースに一元管理し、モニタリングモジュールにより業務進捗可視化をすることで解決した。進捗可視化により、外部業者の業務の遅れをほぼリアルタイムで把握できるようになり、納期遅延のリスクに早期

図 9. モニタリングモジュールの画面 A screenshot of DC-BPM Monitoring Module

特集

DC-BPM


に対応できるようになった。また、外部業者の業務進捗が可視化されたため、進捗確認に要する現場担当者の工数を減らすことができた。課題③は、依頼文書と回答文書の登録日時からリードタイムを算出するなど、文書のメタ情報を利用した集計処理により、プロセス中のボトルネックや外部業者毎のパフォーマンスを可視化することで解決した。

5. まとめ

この論文では、2 章で富士ゼロックスが目指す文書をベースとした人間本位のアプローチであるDC-BPMについて述べた。3章では、富士ゼロックスに蓄積された経験と技術について述べ、4 章では、紙文書主体の業務プロセスに対し DC-BPM を適用することでプロセスの可視化を行ない、改善サイクルを実現するソリューション事例を説明した。経営の都合、IT 開発の都合だけの一方的なシステム化ではなく、あるべき姿の実現に向けて、全社、全員（経営陣、現場担当者、IT 開発エンジニア、運用担当者）で改善に取り組むことがBPMの基本である。その中で、業務プロセスに内在する定量化できない現場の知恵や工夫、時間的積み重ねを経て改善されてきた文書を有効に活用することに拘りを持ちソリューションを

行なっていくことが、富士ゼロックスらしさであると認識している。また、これからの改善は、単に業務の「効率性」を高めるだけでなく、同時に「有効性」を確保することが求められている（図 11）。今後は、これまでの内部統制ソリューションの経験を統合した DC-BPMS を Apeos PEMaster 商品群として展開していく予定である。これにより、さらに効果的にお客様の企業

図 11. 提供価値と実現の仕組み the value and the achievement methodology

図 10. システム構成 System Construction

特集

DC-BPM


品質向上のお手伝いができるだろうと確信している。

6. 登録商標について

ArcSuite 、 Apeos PEMaster 、 Apeos PEMaster Evidence Manager 、ApeosPort、Apeos iiX、PGA、ApeosWare Flow Service（AWFS）、は富士ゼロックス株式会社の登録商標です。その他、掲載されている会社名、製品名は、各社の登録商標または商標です。

7. 参考文献

1) 安方確ほか. Apeos iiX. 富士ゼロックステクニカルレポート. No.16（2006）

2) 熊井量也ほか、Process Gateway for Apeos. 富士ゼロックステクニカルレポート No.19 p121～129,（2010）

筆者紹介

小松裕ソリューション本部ソリューション開発部に所属専門分野：情報工学伊藤泰ソリューション本部ソリューション開発部に所属専門分野：情報工学大橋俊也ソリューション本部ソリューション開発部に所属専門分野：

Documents

DC-BPM · ①プロセス上、文書を排除しきれない： 購買・調達など、他社との文書のやり取り が主となる業務プロセスにおいては、FAXや

DC-BPM · ①プロセス上、文書を排除しきれない：購買・調達など、他社との文書のやり取りが主となる業務プロセスにおいては、FAXや