業務システムを開発・導入のポイントは他部署をまたがることである。

前回書いた業務システムを開発し導入するコツでも書いたように、

システム導入の効果を大きくするには他部署と連携すべきである。

自部署だけで完結すると効果がとても小さくなる。しいては使われなくなってしまうことが多々ある。

まず情報の発生起点から紙に記入してスタートではなく、最初からシステムに入力。この情報の発生が他部署の場合が多い。

他部署が今まで紙で起票していたのをシステムに入力となると、他部署への協力のお願いをすることになり、またお願いしてスタートしたシステムを簡単に辞めるわけにもいかない。

よくあるのは、他部署への協力を得るのが難しいので、まず初めは他部署は今まで通りに紙で起票してもらい、自部署でシステムに入力する体制で始める。

これが大失敗のもとである。自部署でシステムに入力する工数が増えてしまう。そのために人の採用や残業をさせることになる。

システムの導入の狙いが、工数低減なら逆効果となってしまう。

そしてシステムが立ち上げっても効果が明確に出ない。システムの導入の狙いが工数低減なら、人員を減らさなければならない。つまり誰かクビ。しかしなかなかクビにできないので人員はそのままである。

何をやっているのかわからなくなり、向こうで紙の情報を一生懸命に入力している人がぽつんと浮き立ち、そのうち辞めるかとなってしまう。

しかし、他部署に情報の入力をお願いして立ち上げた場合、なかなかシステムを辞めるわけにはいかない。今一つのシステムでも改良をして使える良いシステムにしていく行動になる。

起票だけでなく、その後の処理も他部署にもシステムでやってもらうようにしたらより強固なシステムになるだろう。

ACTIVE21ではワークフローをシステムでやった。この中には「差し戻し」や「回覧」や「ルート者の追加」などの機能があり充実している。

当然導入時は他部署といろいろと揉めたが、周りを固め説明をしてうまく立ち上げたと思う。

なかなかできないだろう。

前回の業務システムを開発し導入するコツの続きです。

業務システムを納入するためのトラップの例を書いていきます。

1. システム開発のチームにユーザーの人員を入れる。物理的に開発チームに席を設ける。できれば専任が良い。
2. 開発チームに参加したユーザーの人員にシステムの現実をしっかり伝える。なんでもできるとは絶対に言わない。さらにユーザー側が作業する内容を伝えること。
3. システム開発は全社活動として全社アピールをする。一部の部署・人がゴネると全社が損をすると認識させる。
4. 紙の運用はできなくする。万が一のため紙の運用を残しても良いが、それによって周りがとても迷惑をする状態にする。たとえば、帳票の起票をパソコンで入力するシステムでも、一旦紙に記入しそれをパソコンに入力する明らかな2度手間にする。
5. データーの取得を今までコンピューターに貯めたデータを流用や、QRコード、バーコードで読み取る。更に画像の読み取り。その読み取りもコンベア上など手間がかからないようにする。

などの例があるが、この中でも特に1）2）が重要だと持っております。

ACTIVE21では1）2）を事前に進めたプロジェクトリーダーがとても良かったです。

業務システムを開発し導入するにおいてよく失敗をする例がある。

「箱もの作って魂入れず。」と揶揄される。

ACTIVE21のシステム開発でもこの件は慎重にかつ入念に取り組んだ。

良くある失敗の例を挙げると、

1. システム開発側が勝手に良いシステムだと思い込みユーザーの意図を組まずにシステム開発を進め、いざユーザーに展開すると全く使ってくれない。
2. 逆にユーザーの意見を真に受けそのままシステムに反映すると使い物にならない、意味のないシステムになり使ってくれない。
3. システムは他部署と関連があり利害関係が出てくる。必ずメリットの無い更にはデメリットとなる部署や人が出てくるので、そういった部署の方を事前に協力者にしておかないと、その部署でシステム運用がスタックしてしまい使ってくれない。
4. 紙の運用を残すと、デジタル音痴の人が今まで慣れた方式の紙で運用を続け、開発したシステムを運用し使ってくれない。
5. システムを運用させるのにデーターの登録にとても手間がかかってしまうため、データーが入らずシステムを運用し使ってくれない。

などの例があるが、これらの課題をうまく乗り越える必要がある。たとえ良いシステムでもユーザーが協力しないと使われないシステムとなり「箱もの作って魂入れず。」となってしまう。

ユーザーにうまく運用させるには、それはトラップを仕掛けることだ。

次はそのトラップの例を書いていきます。

そして、支給品が不良なので、支給品であるB社から購入する粗材品に対して「既受入返品」を手書き起票します。これはその返却された不良の支給品も一旦受入の計上をしてしまうからである。なお有償支給である。

したがって既に受入計上したものを返品するという処理である。

そして不良の現物を支給元B社へ「支給品返品」と「既受入返品」の控えを付けて返却となります。支給先C社からまとまって（たとえば1ケ月に1回とか）返却されるので情報もまとまった情報となり遅れます。支給元B社では確認時には既に情報が古くなり次の生産をどんどん進めている状態です。

大変めんどくさい。一つの支給品の不良が出ると、手書き起票される伝票が「既受入返品」「支給品返品」の３つもある。そしてその３つの伝票を取りまわすそれぞれの部署がある。仕分け、チェック、コンピューターに入力、保管、支給明細および買入明細などと照合などをそれぞれの部署が行いとても手間がかかる処理になる。

これをACTIVE21では電子化にして処理をリアルタイムにして情報の伝達もリアルタイムにして簡潔にした。いまも運用されているようだ。なかなか良い仕組みだとおもう。他社でこの支給品返品という処理を電子化している話を聞いたことがない。