タスクスケジューラは、バッチファイルを実行させるだけのため、成功したか失敗したか判断できない。
実行ログが残らないため、失敗時にはバッチファイルが動作した結果を一つずつ確認するため、原因切り分けや復旧に時間がかかっている。
バッチファイルを同時に実行したり、バッチファイルで生成したファイルをもとに次のバッチファイルを実行したりするため、実行時間を予測してスケジューリングしなければならない。
バッチファイルの動作ログは、トラッカーで確認可能。万が一の失敗時にもログがあるため、迅速な原因解明を実現。
ジョブが失敗した場合、予めどのような処理を実行するか指定できるリカバリー設定が可能。
また、メール通知も可能なため、失敗したことにすぐに気がつくことができる。
「1 業務フロー = 1 ジョブネットワーク」としてスケジューリングでき、ジョブの並列処理やファイル待ち合わせなども可能なため、、実行時間を考えずにスケジューリング可能。
統合運用管理ツールは、多機能であるがゆえに使用しない機能も多く、実際の利用状況に対して、ライセンスコストが高くなりがちである。
サポートの利用の有無に関わらず、年間保守契約が必要なため、保守コストだけで高額になってしまう。
ジョブ管理に特化しているため、低価格の買い切りライセンスで購入可能。
年間保守契約不要のインシデントサポート制度のため、サポートが必要な時に必要な分だけ購入することが可能。
※インシデントサポートについては「インシデントサポートについて」をご確認ください。
シナリオ実行を手動で行っているため、属人化から抜け出せないでいる。純正の RPA 管理ソリューションで解決できるが、高額なため導入に踏み切れない。
シナリオ実行をジョブネットワークに組み込むことで自動実行を実現。また、シナリオが成功したか失敗したかをトラッカーより一覧で確認可能。
ジョブネットワークとして管理するため、他のジョブとの組み合わせが可能。例えば、業務アプリケーションが出力したファイルを RPA で加工し、別のアプリケーションに入力するといったフローの自動化を実現。
従量課金制のため、利用していないときは手動で停止する運用をしているが、停止漏れがあった場合、サービスの利用料金が想定以上に高騰してしまう。
API を利用すれば サービスの起動や停止を自動化できることはわかっているが、サービス独自のコマンドに関する知識が必要で、自動化を実現できない。
インスタンスやサービスの起動や停止をスケジューリングできるため、サービスの利用料金を最適化。また、自動で制御できるため、運用工数も削減可能。
AWS や Azure 専用の制御部品を標準で用意しているため、サービス独自の知識がなくても自動化を実現可能。