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

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

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

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

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

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

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

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

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

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

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

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

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