自動経路選択
あらかじめ、経路を複数設定しておき、条件にあった経路を自動的に選択するように設定できます。
ワークフローシステムを検討する際、そのワークフローシステムがどのような企業規模の範囲まで対応できる機能や運用コストを下げられる仕組みがあるかがポイントになります。
特に大企業は中小企業にくらべて、規模が大きく従業員数も多いため、分業化や専門化がすすんでおり、複数の事業を展開しているケースが多いことから、職種や役職も多い特徴があります。そのため大企業では必然的に事業部も多くなるため、部署によって環境が大きく変わることも珍しくなく、社風も一様でないケースもしばしばです。よって構築するワークフローの内容も大企業では一律のルールでおさまることはほとんどありません。
楽々WorkflowIIは、経路が複雑でかつ、多くの部門にまたがるワークフローを簡単に定義できる他、きめ細かなユーザ・組織管理を採用しているため、人事異動時のメンテナンスを各部門で対応することで、ワークフローシステムの維持コストを最小限に抑えることができます。
また、業務システムに承認機能を組み込み、統合ワークフローエンジンとして利用することもできるため、大規模なワークフローを実現することが可能です。
申請文書の種類ごとに、事前に承認経路を複数設定することが可能です。
申請者は、申請時に経路を選択することで、経路設定の手間を省くことができます。
また、社内ルールにそぐわない経路を設定するという不正やミスを防止することができます。
状況に応じて、多様なワークフローの決裁ルートが実現できます。
あらかじめ、経路を複数設定しておき、条件にあった経路を自動的に選択するように設定できます。
条件によって、自動でルートが分岐されます。
グループ全員に承認をもらうと次の承認者にフローがまわります。
複数の承認者に対して、同時にフローをまわすことができます。
合議承認で、指定人数以上になると承認とみなし、承認を進めることができます。
※承認とみなす基準は、人数または率を設定できます。
申請者や承認者が不在時に、代理人が申請や承認を行います。
事前に登録しておけば、上長が承認できずにいる文書もその上の上長がまとめて承認できます。
前の承認者が承認依頼を取り消して、別の承認者に承認を依頼することができます。
指定期日を過ぎると、システムが自動的に承認したことにして、次に進むことができます。
ワークフローを円滑に進める為に、申請者や承認者が事前に決裁者や他の関係者に審議内容を知らせることが可能です。事前通知は通知記録が残り、検討指示は記録が残りません。
承認者が自分より前の担当者を指定して戻すことができます。否認するとワークフローの再申請が必要になります。
どのフェーズにあっても申請者がワークフローを中止させることができます。 中止されたワークフローは中身を修正して、再度申請することができます。
1つの入力画面で文書を作成すると、その文書の内容を基に複数の文書を自動的に作成します。複数の申請文書が必要な事象に対して漏れなくすべての申請を行うことができ便利です。
決裁のタイミングなどで、自動的に次の申請文書を作成してワークフローを開始します。前後関係がある申請業務を、忘れずに登録できます。
楽々WorkflowIIでは、申請者がワークフローをまわし始めると、承認依頼メールが承認者、決裁者に即座に送付されます。
楽々WorkflowIIでは、申請されたワークフローが滞りなく、承認・決裁されるように様々なタイミングでメールを送信します。
また、メッセージを編集することもできるので、メッセージに文書内容の重要な個所を記載することで、スムーズに承認作業を促すことができます。
申請者から見た相対的な役職を定義でき、経路の担当者として指定することができます。
これにより部門・部署によらないマスタ経路を作成でき、組織改正・人事異動時のメンテナンス性が飛躍的に向上します。
異動日になっても、旧部長であるAさんと新部長であるBさんもどちらも部長で承認することが可能です。
この引継ぎ期間で業務引継ぎを行うことができ、事前に指定した引継ぎ完了日に自動的にAさんの部長権限がはずれます。
予め新組織データを登録しておくことで、組織改正日に自動的に新組織に移行します。
組織改正に伴うデータ変更作業を組織改正日当日にスムーズに行なうことができます。
自部門、経理部門や人事総務部門をまたがるワークフローなど、複数のグループの担当者が経路に存在する場合に、経路の管理を各グループに分散させることができます。
たとえば、フォルダの管理者は各グループが存在する大まかな経路を設定すれば、各グループは自グループの経路を設定することができます。
また、申請者にとっても各グループの担当者をいちいち調べる必要がなくなり、手間を軽減することができます。
大規模な運用形態においては、アプリケーション・サーバ、ワークフロー・エンジン・サーバ、 データベース・サーバの3層にサーバを分け、さらにそれぞれを複数台のサーバに分散させることができます。
これにより、1つのワークフロー・エンジンに障害が発生しても、別のエンジンで業務を続行することが可能となり、可用性の高い、堅牢なシステムを構築できます。
また、エンジンを二重化することで、申請や承認業務の負荷が集中する場合も複数のサーバに負荷を分散させることができます。