実現には、現場、情シス、データの専門家が必要
小泉: 未来というのは受注が入っている未来なのでしょうか。それとも受注が入っていない状態からの見込み生産での生産計画なのでしょうか。
佐野: 機種ごとの生産計画があり、MRP(Material Requirements Planning System:資材所要計画)によって、どの部品がいつどれだけ必要か「所要量」が計算されています。
小泉: SAPの中にもともと入っていた生産計画と、部品の在庫状況が入っているウィングアーク1stの在庫システムを紐付ければ、今後生産予定の製品と、それに関係するBOM(部品)が全部わかるということですね。
しかしSAPとつなぐという技術はかなり難しいものだと思うのですがどのように構築したのですか。

佐野: SAPのデータ構造などに詳しい情報企画部門のスタッフの方と協力しながら構築したということが大きいと思います。
私は在庫適正化の要件を満たすために必要なデータは何かということを伝え、そのデータをどこから持ってくるかという部分はこの情報機関部門の方に任せていました。
小泉: 協力も必要なことですね。構造や実現しようとしていることを理解し、適切な情報を適切に加工や連携を施しながら構築していかなければならないわけですから。
佐野: そうですね。我々と現場とシステム部門の方という三者で取り組んでいくということは他の案件でも重要になってきます。
うまくいかなかった例としては、システム部門の方起点でデータを活用したソリューションを構築していったのですが、実際に現場に提案したところ「必要ない」と判断され、導入に至らなかったということがありました。
ですから現場、システム、我々という三者が連携して構築していくことが大事だなと感じています。
小泉: 開発をしていく中で、現場や御社、上部システム部門で期待値の差が生まれることはないのですか。
佐野: BIのプロジェクトの特徴は、最初からやりたいことややるべきことが明確でないことが多い点です。
基幹系であればやるべきことは決まっているので、それを実現するために要件定義をしていけばいいのですが、BIは必ずしも業務に必要とは限らないシステムなので、「何を形づくればいいのか」を考えるところから始まります。
ですから担当の方と上長の方と、情報システム企画の方と話し合いながら進めていきます。
情報システムの方も単なる情報システム部分だけでなく、業務の中身をきちんと理解した方なので、現場に対して本当にこれでいいのかとお客様の中でディスカッションされます。
一見完成されたように見えても、実際の現場のオペレーションを踏まえるとうまく機能しないのではないか、という部分が見えてきます。「こういった情報も必要なんじゃないか」と、別の担当の方から意見が出ることもあります。
小泉: 情報システムの方だと俯瞰してみているからこそ見えてくる気づきがありそうですね。
佐野: ですからどなたか一人が正解を持っているということではなく、それぞれ意見を出し合いながら、少しずつ形作っていきました。
小泉: MotionBoardはもともとそのような柔軟性を視野に入れた製品なのでしょうか。
アジャイル的プロジェクト管理が成否を分ける
佐野: 使い方次第だとは思います。中にはウォーターフォール型のしっかりと要件を決め、設計をし、開発をしてという大規模なやり方で進めていく方もいらっしゃいます。
ただ可視化をしてすぐに直せるという点では、アジャイル的にやるのに向いているとは思います。
小泉: なるほど。現場の方も実際に見てみて次のアイディアが浮かんでくるというお話がありましたが、イメージが湧きますね。
ところで、お客様と一緒に開発をしていく中で、要望はあったが実現できなかったこともあるのでしょうか。
佐野: コネクティッドショリューションズ社の例でいくと、プロジェクトが約2ヶ月だったので、アジャイル的に進行していました。
週に一回打ち合わせをし、その結果を翌週までに反映させます。その結果を再度見てもらうと、また気づきが生まれる。というように、どんどん展開していき広がっていく話を、どのように収束させ落とし込んでいくかがコンサルの仕事です。
そういった中で期間と費用の都合もあるので、見送った機能というのももちろんあります。
小泉: それは話題が広がってしまい、本筋とはズレているから、見送ったということでしょうか。
佐野: 広がった結果、明確な部分については取り組みましょうとなりますが、少し曖昧なものは、無理して構築していっても後から気が変わる可能性が高い傾向にあると考えています。
そういった曖昧な要望に対しては、実際に使っていき、そこから改善していけばいいのではないかと思っています。
小泉: 具体的にはどういったことでしょうか。
佐野: 例えば在庫の品目が一万数千ある中で、それをただずらっと並べても見方がわからないですよね。ですから何を持って絞り込んでいくかということが一番重要になってきます。
その中でMOQと呼ばれる最小発注数量というものが、大きい数字だと実際に必要な数量よりも多くの部品を発注する必要があるため、在庫を増やす要因となるということがあります。
コネクティッドソリューションズ社にかかわらず言えることなのですが、見るべきポイントを分析して、こちらから提示して欲しいという要望があります。
例えば出荷が上昇傾向にあるようなものは、在庫確保しなければならないといったことや、出荷データを分析し、怪しい品目をAIや統計解析的に分析することで「システムが教えてくれる」といったことは、まだ実現できていませんが、今後やっていきたいことの1つです。
今は部品ごとですが、「製品で使われている部品」という単位で絞り込む機能というものを構築したいと思っています。
理由としては、重要な機種で使われている部品は注意して見るべきでしょうし、逆にこれから生産中止を予定しているものであれば、そこで使われている専用部品は抑えていかなければならない。
このように事前に手を打つために製品単位で見られるようにしたいと考えています。
自動発注の定義が「定期的に」や「ある一定数量になったら」といった単純なものではなく、製品の今後の動向によって発注されるような仕組み作りをしていきたいと思っています。
次ページは、「儲かる工場には、原価に着目した収益管理も必要」
無料メルマガ会員に登録しませんか?

現在、デジタルをビジネスに取り込むことで生まれる価値について研究中。IoTに関する様々な情報を取材し、皆様にお届けいたします。