NTT DATA 変える力を、ともに生み出す。

NTTデータ関西

導入事例

淺田鉄工株式会社様
受注生産向け生産管理システム「Biz∫SCAW製番管理システム」の導入事例

実績収集のスピードと精度に劇的な変化!
仕掛在庫の減少にも貢献!

淺田鉄工様の抱える課題と問題点

  • 基幹システムを統一し、スピーディーな原価管理の実現と個別受注シフトへの対応

  • 実績収集のスピードと精度の向上、在庫削減

淺田鉄工様が実感!
Biz∫SCAW製番管理システムの導入効果

  • 社内で起こっている問題を整理し、目的を明確化!

    システム企画という上流フェーズからのスタートだったからこそ、社内で起こっている問題を整理し、目的を絞り込むことによって業務要件の整理を行うことができた。
  • 登録ありきの発注への変化、実績収集のスピードと精度が劇的に向上!

    以前は口頭発注、モノと請求書が来て初めてこちらから発注書を出すことも多かったが、まず登録ありきの発注に変わった。また、以前は1カ月半かかっていた締め処理もシステムを動かすだけで数日に改善され、実績収集のスピードと精度が劇的に変わった。
  • 理論値と実棚の差異を追求することによる在庫精度の向上!

    以前は0.95カ月分程度持っていた仕掛在庫が0.8カ月程度に改善された。
    常備在庫品も毎月200品目程度ずつ循環棚卸を行い、理論値と実棚の差異を追究することにより、在庫精度が向上した。

導入以前の業務管理の状況

基幹システムを統一し、
スピーディーな原価管理の実現と個別受注シフトへの対応

以前は販売管理と財務をオフコンで、発注手配と原価管理はミニコンで行っていました。
一部データのやり取りはありましたが、基本的には手作業も含めてバラバラな感じでしたね。

システムを新しくしようとした時に抱えていた問題としては、(1)基幹業務の統一性がない、システム的にバラバラだったということ。(2)原価管理に時間がかかっていた、出荷したものが1カ月半くらい経たないと正確な原価が出てこなかったり、出てきたら出てきたで予定原価を大きくオーバーしていたりすることもありました。(3)工程管理が大変だった、仕様変更や飛び込みが常態化していたし、発生の度に、営業や設計を駆け回ってたりと、計画というものがないに等しい状態でした。(4)環境変化にシステムが対応していなかった、以前は標準型式の見込み生産も多かったけど、年々、個別受注生産色が強くなって、そのままの仕組みでは対応が取れなくなってきていました。(5)業務担当者の意識が低下していた、先の問題に対して、「自分の責任範囲だけはちゃんとしておこう」とか「一品ずつの個別受注だから仕方ないか」など、根本的な見直しに向かわなくても良いような言い訳が通っていました。そんな中で当時の社長(橋詰氏)(現社長は当時門永氏の直属上司であった小田氏)の意向もあってこれはなんとかしようと。

製品とベンダー選定のポイント

個別受注に対応し、
自社の業態、文化、レベルを理解してもらえること

当時はちょうどERPの第一次ブームの時で、30社くらい会ったり、資料請求をしました。最終的に提案プレゼンを通して満場一致でNTTデータ関西(当時は関西NTTデータ通信システムズ株式会社)と進めることになりましたが、そこに辿り着くまでは大変でしたね。まずまともに話を聞いてくれるベンダーが少なかったですね。当時は量産型向けのパッケージシステムがほとんどで、個別受注業の話ができない、話をしても通じなかったりで、自信をなくしかけてました。正直、無理かなと。

NTTデータ関西と話をしたのは検討を始めて比較的後半だったと思います。さっきのとおり、ちょっと無理かな?と思っていたので、半ばあきらめ気味でしたけどね。SCAWのことは雑誌なんかで名前ぐらいは知っていました。実際に打ち合わせを進めていく中で、他のベンダーに比べると一番淺田鉄工の業態、文化、レベルを理解していただきましたし、悩みを語り合えるSEがいたことが大きかったですね。どういうところで困っているとか、それに対してどうすればいいとか、そういう会話ができたことが大きかった。他のベンダーには計画生産の話をされたり、話をしながら、「無理なんじゃないか?」というベンダー側の思いが見えたりしましたから。

またプロジェクト体制上の苦労もありました。実はプロジェクト体制については、良くなかったと今でも反省しています。普通なら各部署のキーマンを参画させてスタートするのでしょうけど、当時、情報システムを使って社内を変えていこうと考えていたのは私と当時の社長、と私の直属の上司(前述の現社長)だけでしたから。課長層を巻き込めなかったので、最後まで体制らしいものは組めなかったですね。私が当時工程管理係をしていて、営業や設計とも関わりが深かったですから、大体全体の業務を判断できるということもあって、ほぼ1人で回したという感じですね。もちろん、検討を通していろんな部署の人に相談もしましたけれど、どちらかというと非公式だったので、プロジェクトという感じではなかったです。

このような大きなシステム構築という経験があまりなかったので、業務要件をまとめることができない、どうしていいかわからないという状態だったので、そこから一緒に始めることができたことはとても良かったと思っています。社内で起こっている問題が整理できましたし、目的を絞り込むこともできましたしね。

導入と定着

必ず効果を出せるという確信とメリットの明確化

実際にシステムを使ってどう業務を改善していきたいかという自分なりの判断基準はありました。それでも迷うことはありましたし、話のできる現場部門の人間には相談したりもしました。基本的には自分たちにもやれそうだという部分と、こうできたらいいなぁと思う部分、ここは理論的にはした方がいいけど、自分が実際まわりを引っ張って、そこまで実現できるかどうかという基準がいると思います。後はSEから指摘されるここまでやらないと意味がないよと言われる部分ですね。例えば、作番(製番)完工という処理がありますけど、これは最初できる自信がなかったですね。でも、それで止めてしまうと何も業務が改善されません。業務を改善できるかどうかという比重が大きかったと思います。

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

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

導入後の効果

実績収集のスピードと精度が劇的に向上し、在庫削減を実現

例えば、発注でいうとまず登録ありきの発注に変わりました。以前は口頭発注、モノと請求書が来て初めてこちらから発注書を出すことも結構ありました。次に実績収集のスピードと精度、これは劇的に変わりました。システムをきちんと動かすだけで得られた効果だと思います。以前は1カ月半かかっていた締め処理も数日に改善されました。次に在庫精度も以前より上がりました。仕掛在庫も以前は0.95カ月分程度持っていたものが0.8カ月程度に改善されました。常備在庫品については毎月200品目程度ずつ循環棚卸を行って、理論値と実棚の差異を追究していきました。この時にはデータを使った改善とはこういうものかと少しわかりました。内外作の振り分けも作業1週間前には完了し、現在2週間前にできないか検討中しています。ただ、個別受注という形態上、どうしても予定の変更が発生します。これに対しては変わっても構わないというスタンスで臨んでいます。変わった計画をきちんとメンテして、他部署にも伝えていくということを徹底しています。そうしないとシステムの日付が信用されなくなりますから。

また、改善行為をしていく上での管理レベルの仕掛けはたくさん折り込みました。これに関する枠組みはできたし、こうやれば実際に効果も上がるという道筋はできたと思っています。導入前に比べると一段レベルアップしたと言えますね。ただ、運用のルールというものはいろいろ決めても守られないことが多い。システムに情報が入ってくる以前の問題ですね。ここについては後にISOのプロジェクトもやったのですが、私としてはシステムに入る前の運用ルールを現場へ定着させていくという狙いで取り組ませていただきました。

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

今後の目標

システムの限界を知りながら、
強みを生かすというバランスのとれた運用

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

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

企業プロフィール

photo

淺田鉄工株式会社

会社名:
淺田鉄工株式会社
所在地:
大阪府
資本金:
9,900万円
従業員数:
120名

お問い合わせ、資料請求、リーフレットダウンロードはこちらから。
まずはお気軽にご相談ください。