Excel作業をシステム化することは正義なのか？

システム化の本質は情報の属人化からの脱却であり、Excelでの作業をシステム化することはあくまでも手段に過ぎず、費用対効果を考慮しながら現状維持する作業を選定し、段階的にシステム化を進めていく方法が自然であると考えます。

PDFをExcelに変換

インドネシアの自動車業界で、部品メーカーに送られるオーダはPDF形式（Portable Document Format）が多いのですが、その理由は発注先でファイルを改ざんされたくないというシンプルな理由です。

それは理解できるのですが、受注オーダは必ずデータとして管理されるわけで、PDFでファイルが送られればExcelを変換するという作業が発生することは自明なわけですから、せめて管理用にExcel版も送ってくれればいいのに、と思うわけです。

PDFのExcel変換は、本家本元のAdobe Acrobat DC（Document Cloud）以外にも、フリーウェアやSmallPDFなどのWebサービスでも変換可能です。

しかしExcelからPDF形式に保存されたファイルとか、複合機でスキャンしたイメージ形式のPDFファイルとかの場合は、文字化けはするは「8⇒B」とか「0⇒o」とか読み間違えるはで使い物になりません。

Excel管理とシステム管理の違い

システムの技術営業に行くと、断られるときによく言われ言葉がこれです。

現在のところExcel以上に企業活動に浸透しているソフトウェアはないわけで、表計算ソフトのセルにデータ入力してバイナリーファイルで保存するという「何でもできる」ソフトなので、どんな規模の会社でもやろうと思えばExcelで管理は可能です。

ただ問題の本質はそこではないのです。

これが問題なのであって、この結果会社全体の情報をトータルに活用できないし、会社全体としての作業効率が落ちる可能性があります。

例えば経営側からレポートを作成するよう指示を受けたとき、あちこちにあるフォーマットがバラバラの属人化したExcelファイルを元に作成するのは、非効率であるばかりでなく作成者の能力に応じて正確性にもバラつきがでます。

さらにそれらを元に作成したレポートの精度も、可及的に低くなる可能性が高く、精度の低いレポートを元に経営判断を下すと、おおげさかもしれませんが会社自体が道を踏み外す可能性があります。

運用はExcelで行いシステムで一元管理だけすれば十分では？

一方で業務システムを導入する際、SI（システムインテグレーター）業者側のスタンスは一貫しています。

ただこれは本当に正しいのでしょうか？

システム化の目的が「情報の属人化からの脱却」であれば、入力する方法はシステムに直接入力しようがExcelからインポートしようがどっちでもいいわけで、見方を変えれば長年Excel作業に慣れ親しんだスタッフの能力を生かしたまま、結果だけシステムに格納したほうが更にシステム導入効果が高まる、とも言えないこともないわけです。

僕自身もお客さんに対して、発注書やインボイスなどの伝票は一刻も早くシステムから出力してもらうように促しますが、この作業は担当者の適性と能力に依存する問題でもあり、具体的にストップウォッチで計ったわけでもなく、根拠のない言い分である可能性すらあるわけです。

「Excel作業（マニュアル作業）をシステム化することは正義なのか？」という問題意識は、業務のシステム化に携るすべての人が持ち続ける必要があると思います。

既存システムの不都合を解消するための問題解決志向

インドネシアの日系企業が業務システムの置き換えを行なうときの理由として、現行システムの不都合を解消したいという問題解決指向と、システムの活用範囲をもっと広げて業務に役立てようという戦略的活用指向の2つの軸があります。

もちろんこんな後ろ向きな感じの話もありますが、システム導入が行なわれる際には何らかの大義名分が必要です。

単なる現行システムのリフレッシュだけが目的の、新たな付加価値を何も生み出さない投資が行なわれるほど余裕のある会社はありません。

これはシステム導入を検討しているお客さんから、お問い合わせいただくときのよくあるシステム検討の理由ですが、その「不都合」というのは何なのかという話です。

システムの老朽化

今でこそインドネシアの注目度が高まり、IT投資の予算額も大きくとられるようになりました。

以前はインドネシア現地法人を立ち上げたものの、IT予算への理解が得られず、Excelによるマニュアル運用からはじまって、インドネシアの現地ベンダーが開発した怪しいローカルシステムを導入したり、たまたま社内にいたITオタクの社員が開発したシステムを使うなどして、今日まで耐え忍んできました、みたいな例は枚挙にいとまがありません。

いずれもシステムの老朽化により、今後物理的な支障をきたすことが予想される理由であり、この場合は速やかに新しいシステムへの置き換えを検討しないと、ある日突然Xデーがやってくるリスクが高くなります。

もちろん業務の規模によってはExcelによるマニュアル処理に戻すことも検討されるべきです。

システムの機能的制約

現行システムの仕様に基づく機能的限界によって生じている不都合ですが、これは現状のままでも運用は回るが改善できれば管理の効率が上がると思われるケースであり、現行システムにある長所を捨ててでも置き換えによるメリットが大きいという判断を下す必要があります。

裏を返せば現行システムにある長所として、スタンドアロン型だからこそセキュリティが確保される、モジュール間がリンクしていないからこそ部門ごとで責任を持たせてデータ入力をさせることができる、とも言えるわけです。

また日本側の情報システム部が「不都合である」と感じている問題が、現場でシステムを運用するインドネシア人スタッフにとっては「不都合でない」ケースも多々あり、システム置き換えによって現場に負荷をかけることを納得してもらうには相当のエネルギーが必要になります。

そして「不都合」を改善する方法は必ずしも新システムへの置き換えである必要はなく、外部にサブシステムをくっつけて機能追加するという方法を取ることにより、今まで蓄積してきた運用への慣れとか、標準業務フローに関する理解とかをリセットせずに済む可能性もあります。

システムをもっと活用しようという戦略的活用志向

現行システムよりも高機能かつ価格も高いシステムに置き換える場合には、システムを業務の中核と考えて、単なる管理ツールとしてだけではなく、事業計画を作成する上で重要なKPI（Key Performance Indicators 組織の目標達成の度合いを定義する補助となる計量基準）を提供できるくらいの目標は立てると思います。

ただし高機能なシステムをフル活用するためには、運用する現場に高いレベルの意識と技量が必要になり、それが追いつかない場合は、システムに実装されている機能の一部しか使用されなくなります。

その結果十分な投資効果が得られないことになりかねません。

コスパの問題

システム投資は、短期的にコスパ無視して費用をかけることがあっても、最終的にはBalik modal（元手回収）するだけの効果を得るために行なうものであり、投資効果の大小にかかわらずライセンス料金の10%～20%という年間保守メンテナンスコストが毎年ランニングコストとしてかかります。

インドネシアではPCなどのハードウェアやパッケージソフトのような無形固定資産は4年で償却（カテゴリー1）するケースが多いと思われますが、その金額に見合った効果があったかどうかを知るための指標を、数値データとして本社に報告することになると思いますが、それ以前にシステムを運用する現場スタッフの反応はどうかという問題のほうが重要です。

システム投資は高額になればなるほど多機能になり、多機能になるほど運用の難易度が上がりコスパは落ちますが、効果の絶対値は高まります。

インドネシアでのシステム導入の難しさ

一般的にパッケージソフトによる業務システムの導入では、最初にソフトウェアやDBのライセンス、新規サーバーなどに対する大きな初期投資コストがかかります。

プロジェクトはウォーターフォール型といって、まず最初にユーザーの要件のとりまとめを行い、システムをどのように運用していくかを決める要件定義というフェーズがあり、ここでの決定事項に基づいて、どうしてもシステムで対応できないギャップを考慮しながら、運用フローを決めます。

しかし現実にはここですべての必要事項を出し尽くしてしまうのは難しく、机上の議論で決めた運用フローが実際に現場では対応できないことが判明すると、トレーニングやテスト運用期間に、運用フローの変更が発生します。

このように最初の要件定義フェーズでの決定事項を後になって変更する場合、通常はドキュメントの修正、追加カスタマイズなどの工数が発生しますので、追加費用がかかります。

近年はSales forceなどの営業支援システムSFA（Sales Force Automation）ツールで業務システムを開発する事例が増えていますが、最大のメリットは安価に短期間で開発可能という点です。

何故安価に導入できるかと言えば、日本であれば社内の情報システム部がSaaS（クラウドで提供されるソフトウェア）環境にて内製するからですが、社内に情報システム部のないインドネシアでは、ITベンダーに外注せざるを得ません。

ITベンダーはSFAツールを使って開発するにあたって、プロジェクトの初期段階で要件定義を行いますが、上述のパッケージシステム導入と同じく要件漏れのリスクをヘッジするために多めの工数を見積もるため、見積り金額が多くなりSaaS利用のメリットが軽減します。

Excelが業務改善に適している点

Excelを使って業務が回っている現場に対してシステム化の提案をする場合、まずはこのままExcel業務を続けていくことの問題点を指摘します。

本来表計算ソフトであるExcelは、セルにデータ入力したままファイルとして保存でき、コピーして共有したりバックアップを作成したりという気軽さこそが、四半世紀もの間、業務に浸透してきた最大の理由です。

これを業務改善という観点から見た場合、計算式やフォーマットを業務を行う上でより便利になるようにトライアル＆エラーで修正しながら、少しずつ改善していけると言い換えることができます。

パッケージシステムの場合は入力画面の変更や出力帳票のフォーマット変更などの修正が気軽にできなくなり、やる場合には社内手続きやコストがかかり大変ですからね。

またExcelに入力したデータは、下書き、承認前、確定など、レベルに応じて補足情報を付箋を付けるようにメモ書きすることで、業務フローの次の部門に確定情報としてパスする前にバッファを持たせることができます。

データ入力はするが発注はせずペンディング、出荷はお客のOKを待ってから行う、インボイスの支払いは現場の検収報告を待ってから、などなどデータが正式反映されるまでにメモやフラグを付けることでバッファを持たせて情報管理できるわけです。

完成形を求めず改善活動の過程と考える発想の転換

パッケージシステム導入では最初に要件をすべて取りまとめて、システム運用フローはかくあるべしというターゲットを決め、それを実現するよう限られた期間内でプロジェクトを進めていきます。

ところが実際にはプロジェクトが期間内できっちり終わることのほうが少ないことをITベンダー側は知っているので、リスクヘッジのために工数を多めに見積もり、結果的にお客さん側の初期投資が大きくなります。

お客さんはシステム化という資産への初期投資を償却して費用化していきますが、導入の成否が見えず効果が不透明なシステムに対する大きな投資を敬遠する傾向があり、それがクラウド化、SaaSの利用に繋がっています。

そうであればオンプレミス型の業務システムも、初期段階での要件定義では全てが決まらないという前提で、Excelによる業務改善と同じように運用の中で少しずつ改善していくプロセスと考えるほうが自然だと思います。

そのためにはシステムを売るというよりも、業務のシステム化というサービスを売るという考え方への脳内変革、改善のための継続的な技術保守というストックビジネスで、長いお付き合いをしていただくのが理想だと考えます。