システム導入は簡単じゃない。業務手順がなければ始まらない。
IT技術が発展し、システムの導入を考えている企業が増えてきた。システム屋として導入をする前にして欲しいことをアドバイスする。
システム導入を簡単に考えている人が多い。ワードやエクセルみたいに買ってきてインストールすれば使えるソフトとシステムじゃ導入する手間が違いすぎる。インストールしても、すぐには使えない。システムが大きくなればなるほど導入に手間が掛かることを知って欲しい。
「新しくシステムを導入したい」とか「うちのシステムは何で使いにくいんだ？」なんて言われて、困っているシステム導入の担当者に知って欲しい。
システム導入を煽ってくる経営陣と戦うために必要な知識を伝授する。しっかりと論理武装して、全社一丸となって、システム導入プロジェクトを進めるようになって欲しい。
システム導入は一大プロジェクト
システムを知らない人は簡単に考えているが、システムを導入すると言うことは、今行っている手順を全て見直す必要があると言うこと。今、うちが行っている業務手順のどこをシステムに置き換えるかを考えないとダメ。その理由は後で説明する。とりあえず、読み進めてくれ。
システムを導入する方法は大きく分けて二つある。どこかのシステム屋が販売しているシステムを買う、もしくは借りる方法とシステム屋でオーダーメイドで開発してもらう方法だ。どちらも一長一短がある。
どちらの方法でシステムを導入するにも、現在行っている業務手順が標準化されていないと失敗する。一番困るのは、業務手順がなく、経験と勘で業務が進んでいるなど、人依存で業務が進んでいる場合。
僕の経験で、2020年現在、システム導入を考えている場合の多くは人依存で業務を進めている会社だ。業務手順があるようで、ないことが多い。
システムはバカ
システムは万能だと思っているなら、その考えを捨てて欲しい。システムは何もできない。と言うか何もしない。なのでシステム屋はシステムに何をするかを教える。それがプログラミングだ。
「この画面が表示されたら、データを表示しなさい」
「このボタンをクリックされたら、このデータを更新しなさい」
と、条件とやることを教えていくのがプログラミング。システムは、この条件とやることが、膨大になる。そして、プログラム、システムは教えられたことしかしない、出来ない。
条件が少しでも違ければ、何も反応しないし、やることを教えてなければ反応しない。なんとなくでは動かない。もちろん、だいたいで動かすこともできる。でも、だいたいで動かすためには、だいたいの定義を教えてあげる必要がある。
そんなバカなシステムを使うと効率が良くなるかと言うと、システムはバカだけど教えられたことは忘れない。そして、教えられた手順で何千回、何万回動いても、へこたれない。
バカとハサミは使いよう
昔から「バカとハサミは使いよう」と言われる。システムはバカだけど、決められたことはキチンと完遂する。だから使い道がある。決められたことしか出来ないけど、決められたことは文句も言わず、実行する。
ここまでの話を整理すると
- 「条件」と「やること」をシステムに教える
- システムは教えたことを実行する
- システムは教えられたこと以外はできない
と言うことになる。つまり、いちいち、教えないと何もできないのがシステム。
システム導入をするためには手順が必要
つまり、業務手順がないとシステムにはならない。簡単にシステム導入ができるなんて言っている人たちにガツンと言って欲しい。大事なのでもう一度言う。
業務手順がないとシステム化は行えない。
その業務手順は、システム屋に聞いても知っている訳がない。と言うことが分かってもらえるだろう。もちろん、経験があるシステム屋は、他の会社では「こんな手順で行っているよ」なんて知識がある。ただ、導入を進める会社の手順とは違う。一番良い手順は、運用中の業務手順だ。
システム導入が進まない一番の原因は、業務手順が標準化されていないこと。なので、全社一丸となって、業務手順を作成する必要がある。業務手順を作成し、システムに何をさせるかを整理する必要がある。
繰り返しになるが、システムを導入する方法は２種類ある。販売されているシステムを導入する方法とシステム屋に新しいシステムを開発してもらう方法だ。
販売されているシステムを導入する場合
「大手システム屋が売っている既製品のパッケージを購入すれば良い」
「売っているソフトを買ってきて改造すれば良い」
なんて言うけど、ぶっちゃけた話、販売されているパッケージソフトを改造することは、ほぼ不可能。販売されているパッケージソフトは、そのソフトを開発した会社、もしくはライセンス契約をした会社じゃないと改造なんて出来ない。特に、最近流行りの「○○円/月で使用可能！！」と言うサービスは、クラウドシステムで構築されていて、改造は出来ない。
既製のシステムを導入する場合は、導入するシステムに手順を合わせる必要がある。既製のシステムを導入するメリットは、直ぐに使い始められることだ。月額制のサービスであれば、申し込んだ日から使えるものもある。でも、気をつけて欲しいのは、システムの手順に慣れるまでの時間が掛かると言うことだ。
理想的なのは、行っている業務と販売されているシステムの手順が同じことだと思う。そして、他のシステムとの連携が必要なければ完璧だ。でも、その判断をするためにも、業務手順が必要。業務手順と販売されている多くのシステムの手順を比べる必要がある。
そして、よく言われる「販売されているシステムを買ってきて、業務に合わないところは、改造すれば良い」は、ほぼ不可能だと思って欲しい。もちろん、そのシステムを販売している会社は、改造ができることが多いが莫大な費用が掛かる。一度、問い合わせをして貰えば分かることだが、ちょっとした改造でも数十万円～百万円、下手すると数百万円～一千万円超の費用が掛かる。
舐めちゃいけない。
そして、もうひとつリスクがある。小さなシステム屋が販売しているシステムを導入すると急にシステムが使えなくなることがリスクを抱えてしまう。僕もシステム会社に勤めていた時にシステム会社が潰れるのを何社も見た。順調に見えても人材不足で仕事が回らなくなったり、それこそブラックな企業で潰れてしまったりする。システム屋はサイクルが早い。いつ潰れてもおかしくない。
そのリスクを回避するためには、老舗のシステム屋のシステムを導入することをお勧めする。導入コストも高いがリスクを考えると払う価値はあると思う。一度、システムを導入すると、システムがなくなると業務が回らなってしまう。
システム開発を行う場合
システム屋にどんなシステムが必要かを理解してもらうためにも業務手順が必要だ。これは自社開発をする場合も同じで、先ほどの通り、システムは教えられたことしかできないので、条件とやることを決めて、システムに教えてあげる必要がある。
システムに教える側が、何をすれば良いのかを理解していなければシステムにはならない。「今やっていることなんて直ぐにまとまるだろ」なんて簡単に考えない方が良い。ハッキリ言って今からシステム導入を考えている会社は、何も業務手順がないと思う。あったとしても人に依存している手順になっていることだろう。
業務手順が細かければ、細かいほど良いシステムが導入できる。システム屋もプロだ。条件とやることを理解すれば、使いやすいようにシステムを構築する。過去にシステムを開発して導入して使いにくい場合は、業務手順がざっくりしていたんだと思う。残念ながら技術がいくら発展しても、ざっくりした業務手順では良いシステムは導入できない。
「読めば分かるだろ？！」とか「考えれば分かるだろ？！」と言うのは、システムには通用しない。読み方を知らないし、考え方を知らないからだ。システムに直接、命令するプログラミングをするシステム屋は、結構細かく手順がないと不安になる。と言うのは、例えば、システムが判断する条件が違うと決まった動きをしなくなる。それがバグになり、システム不全を起こす。だから、きっちりと条件が必要になる。
システム開発に必要な業務手順
システム開発を行うときに業務手順が必要なことは理解して貰えただろうか。僕がシステム屋として、営業や導入支援をしていて気づいたことだ。実際の話、システムを導入することって滅多にないと思う。なので分からないことだらけだ。
業務手順をどうやって書けば良いかを最後に簡単にまとめておく。
まずは、どんな業務があるかを拾い出し、名前を付けていく。例えば『検品』『棚卸』『ピッキング』『見積』などなど、ある塊で業務を拾い出していく。『日報入力』なども業務として拾い出す。
そして、拾い出した業務で何をしているかを箇条書きで良いので手順を見直す。例えば、『検品』では、配送業者から伝票を受け取る。伝票にサインをする。商品を受け入れる。開包して商品の数と伝票の数を検査する。数が正しかった場合はXXXする。間違っていた場合はXXXXする。など判断をする基準も拾い出せれば完璧だ。そうするとムダな作業を見つけられるかも知れないし、人間じゃないと行えないタスクも見えてくる。
この手順を作れば、販売されているシステムで行えるのかの判断にも使えるし、システム屋に開発してもらう際にも説明がしやすいと思う。
業務を全て知っている生き字引がいれば、その人を中心に手順書を作る。ただ実際の話、会社の業務は多岐にわたっている。なので、システム化対象の業務は何なのか、その業務の手順はどうなっているのかは、システム導入係じゃできないと思う。なので、全社一丸となってシステム導入プロジェクトを進める必要がある。
ぶっちゃけた話をすると、この手順書を作ってもらい、良いシステムを提案するのがITコンサルタントの仕事。このブログを読んでマネされたら、僕の仕事がなくなっちゃうな（笑）
