DAC（Digital Automation Center）方式は私が推奨しているRPA運用の方式で、開発部隊と運用部隊が一体となり業務を行う方式です。
従来のRPA運用は現場主動のボトムアップ方式と上層部、もしくは情シス等主導のウォーターフロー型。もしくはその両方を行う方式が主流でした。DAC方式はそれらの欠点を補う方式となります。
①情報部・情シス主導のウォーターフロー型RPA運用の欠点
・リストラ前提の印象が強く、現場からの協力を得にくい。
・上層部、情シスとも現場運用の経験が乏しく、現場が運用しやすいRPAを作成することが難しい。
・RPAは従来のシステムと異なり頻繁なメンテナンスが必要で、ウォーターフロー型での運用は難しい。
②現場主導のボトムアップ型の欠点
・プログラミングスキルを持った方が少ない。高額なRPAソフトを導入しても使いこなせる方が少ない。
・独学で高いプログラミングスキルを習得した方もいるがごく少数で、その方が異動した場合、プログラムのメンテナンスすら出来なくなり野良ロボット化する懸念がある。
市販の高額RPAを導入すれば業務効率が大幅に改善するとお思いの企業もありますが、実際には運用コストの高さからプロジェクトを解散、もしくは規模を大幅縮小する企業が多発している実情もあります。
RPAではウインドウズのバージョンアップ等である日突然ロボットが動かなくなることがあります。その場合、現場は開発部隊に対応を依頼しますが開発部隊もすぐに対応できるとは限りません。
ロボットの改修が完了するまで現場は手作業でその作業を行う必要に迫られますが、すぐに人員を確保できるとは限りません。
人間が行って数十時間以上かかる作業をボタン一個で完了させるようなRPAも存在しますが、そういったものが止まった場合、もはや人間がバックアップを行うことは不可能です。
頻繁に不具合を起こすRPAの場合、現場も対応できる人員を温存しますが、逆に長期間安定して動いているRPAが不具合を起こした場合、現場にはその作業を代行できる方は残ってはいないかもしれません。実は安定性が高いRPA、業務効率改善の効果が大きいRPAほど現場には厄介な存在です。
DAC方式について
DAC方式は現場と情シスといった既存の組織とは別にRPA運用に特化した組織を新規に立ち上げます。基本は社内のメンバーから選抜し、必要な場合外部の人員を招く必要もあるでしょう。
DACの内部は大きく2つのグループに分かれます。
〇開発・管理チーム
・高度なプログラミングスキルを持つ方のみで構成
・RPAの開発のみではなく、業務の設計、新規業務の立ち上げ、得意先との調整も行う
・運用チームの教育も行う
〇運用チーム
・ある程度のプロラミングスキルを持つか、これから習得したいという意思がある方のみで構成
・RPAの保守と運用
・RPA化困難な業務の手運用、運用マニュアルの作成。
・簡易的RPAの開発、もしくは要件定義等開発の補助
これらを同じ組織、同じオフィスで行います。
DAC方式のメリット
・運用と開発、業務の設計をすべて同じ組織で行うことで柔軟かつ迅速な運用が可能。
・プログラミングを習得したいと考えている社員を1～数年程度で教育し開発可能なレベルに引き上げることで組織全体のスキルアップを行える。
・ロボット化可能な業務のみではなく、現時点ではロボット化困難な業務も取り込むことが可能。それらは海外を含めアウトソースするか、将来RPAの技術が向上した段階でRPA化を再検討する。
海外では部署の大半のメンバーをリストラしコンピューターエンジニアに置き換える、といった手法も多く用いられておりそれなりに効果も上げているようですが、そういった手法は現在の日本に適しているとは思えませんし、必要なRPAエンジニアを外部から大量に確保することも難しいでしょう。
DAC方式では既存社員の中のプログラミングスキルが高い方、場合によっては外部からそういった方を少数招き、その方たちを核として既存社員を教育します。
DAC方式の場合、1年程度で目に見えて業務の質と効率が改善し、3年程度で既存社員を初期のコアメンバーに匹敵するプログラマーに育てることが可能です。
DAC方式はメンバーの成長にあわせ組織を拡大、対応できる業務の数と種類を増やしていきます。最終的には社内のすべての定型業務をDACで行い（もしくはDAC経由で社外にアウトソース）、業務の品質と効率を別次元まで引き上げることを目的としています。
Comments