ワークフローサンプル: 子プロセスで業務データを加工する（翻訳プロセス）

「業務フロー」に組み込まれるべき「業務フロー」を考える。（へ？）

結論から言えば『専門技能を部門横断的に発揮すべき仕事』が、それにあたる。事業内容あるいは会社規模によって大きく異なるが、「誤植確認」「原稿翻訳」「商標法違反チェック」「プレゼン資料ブラッシュアップ」などなど様々だ。

以下のワークフロー定義は、「原稿の日英翻訳業務」が多くの部署で発生する会社の「原稿翻訳フロー」だ。他の業務フローから呼び出される事（組み込まれる事）が想定されている点が秀逸だ。しかも翻訳完了後、「元の業務プロセス」に対して英訳済原稿データを自動的に送り返す。古いIT用語で言えば『サブルーチン』と言う仕組みだ。ビジネスプロセス的（BPM的）には『サブプロセスの呼び出し』と言っても良い。

社内の「翻訳センター」とでも言うべきこのチームは専門技能者の集まりだ。「彼らへの入力」と「彼らからの出力」を定義することは全社の業務効率の改善に大いに貢献する（在宅勤務制度のヒントにもなろう）。ちなみに、しばしば「本業に集中すべくこの業務は社外アウトソースしましょう」と言う議論になるが、社内用語・専門用語を熟知している点で、社外へのアウトソースとはクオリティが違う。

[原稿翻訳フロー]

[原稿翻訳フロー：「1.翻訳依頼に回答する」画面]

[データ項目一覧画面]

上記のプロセスモデル「原稿翻訳フロー」は、それを呼び出すプロセスモデルが同じ Questetra ID 上にある事を想定している。

すなわち【依頼元プロセスモデル】は、『案件ID：processInstanceId』（Questetra ID 内でユニーク）、『返信先イベントID：nodeNumber』、『翻訳元原稿』などを翻訳プロセスモデルに渡す。【翻訳プロセスモデル】は完成した『英訳済原稿』を『案件ID：processInstanceId』と『受信イベントID：nodeNumber』を使って、依頼元プロセスモデルに投げ返す仕組みだ。

なお、Questetra v9.7時点での仕様上の都合だが、依頼元の業務プロセスは、データ項目の0番目（data[0]）に「英訳済原稿」（複数行テキスト）を、データ項目の1番目（data[1]）に「翻訳者コメント」（複数行テキスト）を、格納できる様にしなければならない。つまるところ依頼元の業務プロセス定義は、以下のサンプルを拡張して作れば良い。ただし、呼び出し先の翻訳プロセスモデルの業務ID（processModelInfoId）は、利用環境に合わせて変更する必要があるので、注意して欲しい。

[翻訳依頼元プロセスモデル]