「業界標準システム普及」を現実のものにする
システム化は民間が常に先行
前節では、「行政手続き」のシステム化の動きについて書きました。
しかし、こういった手続き効率化の取り組みは、民間ほど進んでいるのが常です。
銀行、流通業など、とても「手でやっていられない」業界は、古くからアナログ電話回線網にてメッセージをやりとりするプロトコルを標準化し、マシン間でのデータのやりとりを実現してきました。
NTTのサービス廃止に伴い、現在はインターネットの標準プロトコルたるTCP/IP上で動作する仕組みへの移行が普及してきているところです。
データはFTP、SOAPやJSONといったプレゼンテーション層プロトコルでやりとりされますが、データ構造の定義は各業界団体で企業をまたいで話し合いきっちり標準化されるケースもあれば、特定の先駆者企業が独自で開始し、取引先に相乗りしてもらって実質的に標準を勝ち取るケースもあります。
受発注などの取引を電子上で自動処理する仕組みを広くEDIといいますが、各業界のEDI推進団体は、インターネットを前提とした認証・データ通信プロトコルを標準化する動きを昨今活発化しています。
一般広域網を使えば、データ連携のためのサーバを自社に設置するような大手企業を除いて、特殊な専用回線やハードウェアも必要とせず、パッケージソフトなどの導入だけでEDIが利用できるようになります。
しかし、このようにシステム導入の障壁は一見低くなっているにもかかわらず、業界標準システムが望むようなスピードで普及していかないのは、「中小企業」という大きな壁があるためです。
業界標準システム普及の苦悩〜EDIを例に
たとえば流通業界であれば、インターネットを利用した標準EDIとして「流通BMS」を規定しています。
スーパー、ホームセンター、ドラッグストアなどの大手小売りチェーンは、数多くの仕入先を抱えており、統一的な仕組みで発注・納品管理するためにこれを導入します。
彼らはサーバーを用意する側となり、SaaSやIaaSを選択したとしても初期導入費や運用費などけっこうなコストがかかりますから、当然フル活用して投資対効果を高めたいわけです。
つまり仕入れ先となる卸企業やメーカーに対して、従来のFAX発注などは止め、自社のEDIに参画するよう半強制的にお願いすることになります。
お願いされた卸・メーカー側が、他の顧客との間で既に流通BMSのEDIクライアントソフトを利用していれば、通信先が増えるだけなので問題はないのですが、そんなものはなく「他の顧客も皆FAXで注文を入れてきます」という状態だったらどうするかが問題となります。
これを機に流通BMSを導入するとすれば、対応するソフトウェアが必要となります。
しかし多くの中小企業は、費用対効果の関係からその導入に二の足を踏むでしょう。
そんなケースの「妥協案」として、「WEB EDI」という選択肢が提示されます。
このWEB EDIとは、なんてことはない、ブラウザのUIを通じて受注〜納品管〜請求管理を行うものです。
しかしWEBインターフェースはあくまで人間が操作するものであり、当然自社の基幹システムと結合しているわけではありあません。
そのため、卸・メーカー企業の業務システムとWEB EDI間でデータエクスポート/インポートできるようなデータの互換性がなければ、結局入力が二度手間になるだけなのです。
これではEDIの本来の趣旨に反しています。
つまりある程度の費用負担覚悟で流通BMS導入に舵を切らない限りは、EDI本来の恩恵を受け入れられないわけです。
しかし、多くの中小企業はそのリスクを取ることができません。
日本企業の7割が中小企業なわけですから、それによって業界として推進しているシステム化の波があわや堰き止められかねません。
なぜ中小企業は自社システムを標準化できないか？
できない理由は、確かにコスト面の問題も大きいでしょう。
しかし妥協案のWEB EDでさえ利用する方にシステム利用料などの名目で負担が強いられます。
むしろ大きな問題は、「舵とり役がいない」ことです。
現在の紙とFAXの運用をEDIに変えるためには、下記のような項目をクリアする必要があるでしょう。
- システム仕様の理解、現状業務とのギャップの把握
- インフラ要求の理解と対応
- 社員教育
- 上記にかかるコストメリット計算
- 導入する上では発注先の選定、価格折衝、導入管理
これらはいわばシステムコンサルティングに相当する仕事です。
もちろんこれらも含めて外注することはできますが、コストは開発部分よりもむしろ大きく、開発自体の費用に二の足を踏む企業にとってとても受け入れられるレベルではないでしょう。
つまり「お前が舵をとれ」
つまり、これらのコンサル的な部分を担える社員がいれば、導入の障壁は断然低くなります。
ある程度大きな企業ならば、専門のワーキンググループでも立ち上げれば良いですが、中小企業にそんな人的リソースはありません。
ここで活躍できる逸材こそが「元SEの経理担当社員」です。
経理には繁忙期と閑散期が必ずあります。
特に決算月から2ヶ月間以上は余裕のない状態が続きます。しかし逆にいえばそうでない月もあります。
月末月初は毎月忙しいという会社もあるでしょう。しかしそれも言い替えれば月の中頃は余裕があるということです。
何より重要なのが、事前にある程度仕事量の波が把握できている点です。
また、SE視点で見ると、経理業務においては効率化できるポイントが多く、前任者から引き継いだ業務の多くは、プログラムやツールを活用すれば作業時間の削減ができます。
このあたりは次のカテゴリで書いたとおりです。
つまり、通常ならばライン業務を抱えた社員が別プロジェクトを兼任することは時間的に困難なのですが、「元SEの経理担当社員」ならばそれがそれをこなせる可能性が高いのです。
むしろ中小企業の限られた人員の中では他にできる人はいないとさえ言えないでしょうか。
このように中小企業が大企業との”システム恩恵格差”を縮めるための最有力手段が「元SEの経理担当を社員として置く」という人材戦略なのです。
その理解が広く浸透すれば、業界標準システム・プロトコルが普及する素地が形成され、ひいてはそれが業界全体の効率化・発展に繋がります。
業界やシステム屋が一方的に標準化をごり押ししても、導入する側に「わかって動ける」社員がいなければ何も進みはしないのです。
「働き方改革」の推進者現る
中小企業にとって働き方改革は絵空事ではない
業務システムの汎用化だけでなく、もっと広く「働き方改革」という点で考えれば、RPAとAIを活用できるかが会社の業績を左右する時代が来ています。
本来、RPAとAIはまったく質の異なるものであり、導入先も導入フェーズも全く異なります。
違いにいての解説は他サイトに譲ります。
RPAだとかAIだとかIoTだとか、なんだか怪しいアルファベット略語が次々登場するものの、中小企業は「様子見」または「大企業で効果が検証されてから」などと考えていないでしょうか。
しかし、大企業の後追いをしていればいつまでも格差は縮まらないですし、RPAに至っては「中小企業ほど導入を急ぐべきではないか」と筆者は思っています。
なにせもともと無駄が多いのは中小企業のほうであり、資金の問題で今まで諦めていたこともRPAによって低コストに解決できる可能性があるのです。
「働き方改革」なんて、ただでさえ人が少ない中小企業にとっちゃ絵空事、なんて思っていませんか。
RPAは中小企業ほど「使いどころ」がセクシーになる
大企業との差を縮めるのがRPA
RPAとは、簡単に言えば定型業務をプログラムで自動化するものです。
導入にもそれなりにコストがかかりますから、同じ単純作業であっても100件分の仕事より1000件分の仕事に適用した方が望ましいわけです。
つまり、企業の規模が大きく社員や取引数量が多いほど費用対効果が高いように見えます。
しかし、千人、一万人といった大規模の会社では、RPA利用により業績に大きなインパクトを与えるほど効率化できる業務は残っていないのではないかというのが筆者の見立てです。
既に効率的なパッケージソフトを使って十分効率化されていたり、自作ツールを使っていたり、派遣社員や外部にアウトソースしていることも多いでしょう。
そもそも、RPAの「使いどころ」を考えると、「本来であればシステム連携できるはずだができておらず、仕方なく人力で処理している部分」に他なりません。
既にAPIでシステムどうしが繋がっているなら手作業はそもそも不要なわけなので。
大企業の多くは、上で述べたEDIを筆頭に、かなりの取引がAPI連携されているのに対し、中小企業はまったくそうではありません。
古い独自システムやオフコンなんかを使い続けているようであれば、WEBインターフェースでSOAPでデータ通信などということ当然はできません。そういう場所こそが、RPAの使い所となるのです。
たとえば・・・
WEBアプリや他社製ソフトの決められたボタンを自動的にマウスクリック
→応答結果から必要部分をテキストとして認識
→内容に応じて自社システムの入力画面で自動タイピング
→以上の処理をワンボタンで繰り返し実行できる
というように、システム間のデータ送受信を手作業で繋げている箇所に適用することでRPAの本領が発揮されます。
このような部分は、本来ならば自社システムが相手の汎用IFを使ってデータを入出力できるようにするため、高い改修費用を払って対応しないといけないケースです。
取引規模が大きく、コストをかけても恩恵が余りある大企業ならば王道に則りそれをやった方がよいでしょう。
しかし資金に乏しい中小企業が限られた取引のためにそれをするには分が悪すぎます。
そういうときこそ、最小限の範囲かつ低コストでRPAを適用することができれば、必要最小限の自動化が達成でき、”王道のやりかた”との差をぐっと縮めることができるというわけです。
中小企業がRPAを導入するのに必要なこと
導入に向けて必要なことは、自社システムは何ができて何ができないか、RPAなら何ができるか、といったシステム仕様・要件整理と、どの手作業部分にRPAを適用すれば劇的な効果を生むのか、といったいわば目利きです。
こういったポイント捉える感覚は、日頃の業務に何も疑問を持たずに何年もやってきた人たちは全く持ち合わせていません。
残念ながら、そういう人たちに例えば「非効率な作業を挙げてください」と言っても、今の何が非効率で何が自動化できそうかなどのアイディアが出ることはほぼないのです。
かといって、外部の人間にRPA適用先を見定めてもらおうとしても、限られたプロジェクト期間内に実務担当者へヒアリングした上で、的確に抽出することは困難でしょう。
（だから、トップダウン的に強引にシステム導入しても、現場ニーズに基づいていないためにうまくいかないわけです）
残された唯一の選択肢として、実務を理解した上でシステムにも明るい社員が推進者になることが必要になるのです。
結局RPAを導入するにはプログラマー思考が必要
規模の不利に加え、中小企業のRPA適用における障壁とされるのが「業務の可視化」です。
中小企業の仕事は業務マニュアルが無く属人化しまくっているため、システマチックにフローに起こせず、RPAのシナリオも書けない、という問題。
これも「SE知識があり社内業務を知る物」がいればこそクリアできるプロセスです。
「業務のフロー化」は、まるで引き継ぎ資料のように、単に業務を時系列に沿って手順書化するだけの作業ではありません。
「RPAの動作原理を理解した上で、それにとって必要な単位に業務を分解し、条件分岐や例外処理含めフロー化する」といったプログラミング的な思考に基づいて進めることが必要となります。
なお、実務担当者が協力的ならば良いのですが、「これは俺の仕事だ」とわざとブラックボックス化して会社で存在感を出しているつもりな人がいたとすれば、その業務は放っておきましょう。
例えば営業の事務処理負荷軽減が重要課題であれば、売上入力や実績集計、回収計画であったり、まずは多くの人が定期的に実施している業務への適用から着手したら良いと思います。
なお、そもそも業務を知っていなければ外の人間と一緒なので、他部門であってもできるだけ多くの人と仕事に関わる関心と勇気は必要となってきます。
中小企業の場合は部門の垣根は限りなく低いので、その点は良い方向に作用するでしょう。
まとめ
本コラムではEDIとRPAをピックアップしました。
そういった「システムによる業務効率化」を中小企業が達成するには、
- 常日頃から業務をシステマチックな目線で捕捉し、
- ITソリューションの肝を理解し、
- 費用対効果を推定した上で、
- いざ導入となれば要件定義しプロジェクト遂行できる
という人材が社内にいることが大事だと理解いただけたでしょうか。
これらシステム導入の過程では、システム発注先の営業やSEと対等に会話できなければいけません。
また、インフラの強化やライセンス管理、社内向けシステム運用規定の策定、マニュアル作成など、自社で別途対応が必要な付随作業が発生することもあるでしょう。
中小企業内に経理として元SEが潜んでいれば、満を持してこういった大小のプロジェクトの推進者となり、こういった対応を担うことができます。
そうなると、これまではシステム案件となると外部業者といちいち契約書を取り交わして作業依頼していたような中小企業の、「ITフットワーク」が格段に軽くなるのです。
さすれば、大企業ばかりがICTの恩恵を教授するような「IT格差」は緩和され、多くの労働者の受け皿となっている中小企業が平等に成長の機会を得るための素地が形成されるのです。