情報システムの改修や、新たにシステムを導入する際に、問題点をよく分析しないままシステムの導入に入ってしまう場合があります。おおよその場合、問題点を分析する前に、トップからシステムを入れ替えなさい、とか、古くなったシステムを交換する、という具合に、最初から対策が議論されず、手段が目的になっている場合が多いと思います。
確かに、オムニチャンネル化とかCDP導入などがトップからIT的な機能を特定されて導入するように命令がされると、その新しいシステムを導入することが目的となってしまいます。
そうなると、今、会社で起こっている問題点よりも、いかにしてそのシステムを入れるか、と言う議論になります。これが悪いのかというと、実はそうでもなく、欧米型の考えであるトップダウンであれば「このシステムを入れるから、結果がこうなるはずだ」という演繹法的アプローチになります。
ERP（エンタープライズリソースプラニング）であるSAPが出現した頃、導入やカスタマイズが大変だ、という話をよく聞きました。その理由は、そもそも、会社全体のフローをそのシステムに合わせてしまうという考え方で仕事自体のやり方も変える必要があるからです。
これは、まさに演繹法的アプローチで、そのシステムを入れれば、必ず会社は良くなるはずだ、という考え方に基づいて対策から入っているのです。この演繹法的なアプローチは、人材の流動性が高い欧米ではフィットするのかもしれませんが、日本のビジネスカルチャーには向かないと考えています。
つまり、日本のビジネス文化では、旧来よりあるQC活動や現場からボトムアップで出てくる業務改善活動があるように、どちらかといえば、現場で社員が問題点を見つけて、それを改善する目的で新たな対策やシステム導入を図るという考え方なのです。これを帰納法的アプローチとも言います。つまり「こういう問題があるからこそ、こういうシステムを入れたら良くなるはずだ」という考え方です。
日本人にしっくりくるのは、このボトムアップ方式の帰納法的アプローチです。演繹法的アプローチでは現場が大変混乱します。なぜなら、日本では同じ職場に長期間働いている社員が比較的多いと思います。これまでのやり方を一掃して新たなやり方を導入すると、長年そのやり方で同じ人がやっている分現場はその変化に対して苦痛を伴います。さらに、 文字にされていないルールや長年のしきたりや習慣があるため、それらをシステム化することは簡単ではありません。
欧米のように人材が流動的であれば、新しい担当者が入社し、その新しいやり方に順応してやってくれるのです。あるいは、会社が示したやり方ができなければ、そのやり方をできる人を採用すれば良いという考え方があります。日本のような長期雇用ではないので、こうした演繹法的アプローチが通用するというわけです。
日本的なアプローチでは、長年その職場で働いている人たちから、粘り強くヒアリングを繰り返して、マニュアルや存在しているフローチャートに載っていないような内容も聞き出します。その上で、情報フローを分析してどこに問題点があるのかをまず特定しなければいけません。問題点は、システムへの入力項目が多いとか、作業が複雑である、といったことではなく、「時間がかかる」のはどこかというところに焦点を当ててください。
すなわち、入力項目が多かったり、画面の遷移が何度もある場合に、そのことによってエラーが 生じやすくなります。しかし、エラーは単なる結果であり、原因が入力項目が多い、画面の遷移が何度もあるということになります。そして、問題点はエラーによってその間違いを修正したり、下流工程へ誤った情報が行くことによって、やり直しが発生して多くの「時間がかかる」ということになります。このように、問題点は必ず時間がかかるというところに到達します。
ですから、この場合は、入力項目を減らし画面の遷移を少なくすることによって、エラーを起こりにくくするということも対策の１つですが、そもそも、入力自体をなくすことができないかとか、あるいは、データの連携フローを変えて、違うやり方はないか、といったことを考えるべきです。
フォーカスすべきは、このプロセスに時間がかかってしまうということです。くれぐれも、 原因である入力項目が多いとか、操作が複雑であるということを問題点にするのではなく、 プロセスとして時間がかかっているというところにフォーカスしなければいけません。
こうして問題点を特定し、帰納法的アプローチによって、現場の人たちも巻き込んでシステム導入を進めるのです。