この事例のトップへ戻る

前ページからの続き

実際にシステムをスタートさせてみた時の状態はいかがでしたか？

当初半年間は大変でした。やはり、システムを導入するということは全てではないけれど、今までの仕事のやり方を否定する部分はあるわけですから、社内の反発も結構ありました。ＳＥの方にも１年くらいは結構サポートをしてもらったと思います。現場の利用を促すために若手にも参画してもらって、とにかく動かさないといけないという状態で取り組んで、まずは使ってもらおうと。システムというものはすぐに効果は出ないですよね。管理レベルを上げていく仕組みですから、逆に手間が増えるくらい。１年〜２年も経つとデータも溜まってきて、いろんな見方もできるようになってきました。そうなるとなくてはならないものになっていきました。

導入から定着までご苦労も多かったと思いますが、こういうプロジェクトを推進していく原動力というものにはどのような点を挙げることができますか？

自分自身にこうしたいという思いがありました。信頼してもらっていたトップや若手にも応えていきたかったし、当時、受注が多くて現場が非常に混乱していて、なんとかならないかという意見も実際にはありましたからね。そういう意見にも応えていきたかったということがありました。実際、できたシステムをきちっと運用するだけでそれなりのメリットは得られると思ったし、業務の改善をして効果を出していく部分に対しても必ず効果は出ると思っていました。どこかに確信がないと続けられないし、続ける気にならないと思いますよ。あと、メリットが出るということが現場に伝わるということも大事だと思います。

実際の導入効果はいかがでしょうか？

いろいろとあります。例えば、発注でいうとまず登録ありきの発注に変わりました。以前は口頭発注、モノと請求書が来て初めてこちらから発注書を出すことも結構ありました。次に実績収集のスピードと精度、これは劇的に変わりました。システムをきちんと動かすだけで得られた効果だと思います。以前は１カ月半かかっていた締め処理も数日に改善されました。次に在庫精度も以前より上がりました。仕掛在庫も以前は０．９５カ月分程度持っていたものが０．８カ月程度に改善されました。常備在庫品については毎月２００品目程度ずつ循環棚卸を行って、理論値と実棚の差異を追究していきました。この時にはデータを使った改善とはこういうものかと少しわかりました。内外作の振り分けも作業１週間前には完了し、現在２週間前にできないか検討中しています。ただ、個別受注という形態上、どうしても予定の変更が発生します。これに対しては変わっても構わないというスタンスで臨んでいます。変わった計画をきちんとメンテして、他部署にも伝えていくということを徹底しています。そうしないとシステムの日付が信用されなくなりますから。
また、改善行為をしていく上での管理レベルの仕掛けはたくさん折り込みました。これに関する枠組みはできたし、こうやれば実際に効果も上がるという道筋はできたと思っています。導入前に比べると一段レベルアップしたと言えますね。ただ、運用のルールというものはいろいろ決めても守られないことが多い。システムに情報が入ってくる以前の問題ですね。ここについては後にＩＳＯのプロジェクトもやったのですが、私としてはシステムに入る前の運用ルールを現場へ定着させていくという狙いで取り組ませていただきました。

次にシステムの運用に苦労した部分はありますか？

まずはストラクチャー型部品表ですね。中小の個別生産ではなかなか難しい世界だと思います。入力データを持ってくるまでに改善活動を実施しないと、ＳＣＡＷには届かない部分もあります。やはり設計からはさみだれ型の先行手配が主流。標準部品表の流用というわけにはいきません。でも、やることが大事だと思っています。工程管理（日程管理）をしていく上では必要ですから。工程管理ではそれによって得られた日程計画を日付順に並べたり、工程毎にくくってみたりと現場は活用しています。１週間単位の小日程計画は本当にできるかどうか製造現場に判断してもらっています。システムからはいつまでにどれを作らないといけないかという優先順位を提供しているという形です。
次に日程計画の確定処理の使い方ですね。考え方としては理解できるのですが、やはりどうしても確定後の変更が発生するわけです。でも、それを許してしまうと安易に変更に走ってしまいがちになります、そうすると、部品表に紐付けができないとか計画外の手配や指示になってしまうとか、別の問題も発生してしまうので、非常に手間をかければシステムとして変更できるということにしました。そうすることで、できるだけ変更を減らそうという動機付けにしています。
後は作番（製番）完工。この処理で物件を締めると、以降は原価計上ができないという仕組みですが、運用１年目に、この処理の後にキャンセルをしてステータスを戻したいという事象が発生したことがありましたが、これについても一度事例を作ってしまうと以降の歯止めが効かなくなってしまうということもあって、認めませんでした。

また、システム構築に携わる機会があるとするとどうしますか？

今のシステム構築の時は、先にも言ったとおりプロジェクトの体制が不十分だったので、ここをなんとかしたいですね。会社の中でキーになってくる人をどう巻き込めるかがポイントだと思います。また、今までと違うことをやろうとすると、どうしても反発がありますので、そこを踏ん張れるかどうかも大きいと思います。会社としてもそういうことに携わる人を評価する仕組みも必要だと思います。

では最後に会社にとって情報システムの果たす役割はなんでしょうか？

私個人としてはなくてはならないものだと思っています。導入することの意味や効果を確信していましたから。システム構築以降もいろんなプロジェクトがありましたが、当時の経験が非常に役立っていると思います。
また、会社にとってもいろんな効果があったし、なくてはならないものだと思います。
ただ、限界を超えてシステムに期待してはいけないとも思います。実際のものづくりの作業場面には届かないし、届かせようとしてもダメなのでは？というのが今の考え方ですね。しかし、ものづくり全体を管理する、プロセスを見ていくという目線では絶対に必要なものです。管理レベルが原因でものづくりの現場にいろんな混乱や無駄を作り出すということは日常茶飯事です。システムにはそのようなロス・ミス・無駄を回避させていく効用はあります。管理面のミスやロスの影響は本当に大きいのです。作業の優先順位を決められないとか、機械の段取り中に飛び込みが発生するとか、そうなると製造現場のストレスは大きい。そういうものが回避されるようになったのはシステムの力だと思います。

本日はありがとうございました。