現場の記録と基幹の数字をどうつなぐか——調達業務で見るkintone × ASTERIA Warpの役割分担

南崎氏 定性的な情報を保存するのは、kintoneがとても得意なところです。

山脇 基幹システムには確定した単価と納期しか入っていないので、前回なぜこの単価で決まったのかが分からない。前任者のメールを探すか、サプライヤーに聞き直すことになります。担当者の異動や退職のときは特にそうです。

山脇 過去の納品遅れや品質不良といったトラブル履歴も、一緒に残すケースがあります。なぜこのサプライヤーで、なぜこの単価なのかを判断する材料になるからです。

森 基幹側で見た型番などで検索して、kintone側で履歴を見れば、こういう経緯で値段が変わったから今この単価なのだ、と確認できる。入力は全部kintoneでしてもらって、そこと基幹をつなぐのがASTERIA Warpの立ち位置です。

山脇 基幹からkintoneに渡すだけでなく、kintoneから基幹に戻すケースもよくあります。上長がkintone上で新しい単価を承認したら、ASTERIA Warpで基幹の単価マスタに書き戻す。これで二重入力が防げます。

山脇 経緯を入力するのは人です。その運用が定着しなければ、レコードは空のまま。そこはツールでは解決できません。

南崎氏 材料を調達して、作って、届けるまでのサプライチェーンは、ERPなどのシステム群でだいたいまとめて扱えます。とはいえ会社ごとに違いはあるので、どうしてもギャップが出てくる。Fit to Standardと言っても、やっぱりギャップは出るんです。

南崎氏 システムを入れる側は、基本的にお願いする立場なんです。『これがルールなので使ってください』と言っても、現場からは『なぜ変えるのか』『そちらの事情は知らない』となってしまいます。だから、現場にどれだけ寄り添えるかがとても大事なんです。

南崎氏 紙やExcelが多くなっているのも、そこに理由があるんです。でも、それだと基幹システムとの整合性が取れない。だから、現場とERPの橋渡しをするのにkintoneが使える。これが、MES(製造実行システム)の領域でkintoneが適している理由だと私は思っています。

森 使ってもらわなければ、というのは、まさに私たちも同じです。業務を効率よく回してもらうために私たちがいる。現場とERPの間に入るのが、ASTERIA Warpの役目だと思います。

南崎氏 現場の情報をデータ化していくと、もともとあるシステムと整合性を取りたい、データを流用したい、実績データは別の場所にある、という話になってきます。このようにデータの場所がバラバラになる場合は、絶対に連携したほうがいいので、データ連携の話は必ず出てきます。

山脇 生産管理と、現場の方が使っているシステムだけでは、業務プロセスが完結していないんです。システム一つでは足りないので、連携のニーズは少なくとも6〜7割はあるという感覚です。

南崎氏 MESを入れたときに連携が出てくるのは、8〜9割だと思います。ERPの情報を現場に伝えることも、現場の情報を吸い上げて渡すこともあって、双方向なんです。ほぼ100%と言ってもいいかもしれません。

南崎氏 点検系やメンテナンス系、設備の部品在庫の管理、あとは修理依頼ですね。製造から『これが壊れたんだけど、どうにかしてもらえますか』という依頼を受けるワークフローが多いです。

森 正直に言うと、IoTの連携はASTERIA Warpの苦手なところです。データ量が多く、1ミリ秒単位で届くデータは処理しきれません。

山脇 センサーから直接というのは、ASTERIA Warpだけでは難しい。アステリアのIoT製品のGravioなどでデータベースに貯めて、バッチで取り出す。そういう使い方で、設備のデータを分析しているお客様もいます。

山脇 貯めたデータは、1時間ごと、1日ごとなどに丸めてkintoneやデータウェアハウスに渡します。生データを全件kintoneに入れることは勧めていません。異常が起きたあとに現場で何をしたかはセンサーに残らないので、点検や処置の内容は担当者がkintoneに記録します。

南崎氏 EBOM(設計BOM)、MBOM(製造BOM)、それから保守のほうのSBOMがあります。SBOMは、設備を出荷したあとに部材を交換したときなど、作ったときから変わった構成を管理するものです。

南崎氏 SBOMで変わっていった情報は、次の製品を設計するときにとても大事な情報になります。どの部材の交換頻度や故障頻度が高いかが分かるので、改善のネタになる。絶対に連携したほうがいいのですが、実際はできていません。EBOMは設計、SBOMはサービス管轄と部署が違うことで、情報を取りに行きにくい構造になっています。

森 私たちのデータ連携部分だと、多分最初のEBOMのほうですかね。SBOMの領域は、アフターメンテナンスなど別のパッケージの側でやるケースのほうが多いという印象です。

南崎氏 材料構成や材料マスタ自体が、そもそも百万点を超えるケースもあります。普通にやろうとすると難しく、工夫が必要な領域です。あと、リレーショナルな扱いも求められるんですけど、kintoneはリレーショナルではないので、そこは苦労するところです。

南崎氏 BOMを作る部分は、基本的にパッケージ製品でやったほうがいいんです。出来上がったBOMの情報をkintoneに持ってきて、いろいろなところで活用していくパターンが多い。そういう意味でも、連携していったほうが絶対いいです。

森 私たちがお話をいただくときは、基本的に情報システム部門が多いんですけど、製造業の場合、kintoneの問い合わせは現場から直接来るんですか。

南崎氏 現場からです。

南崎氏 製造業では、ものを作っている現場の発言力がとても大きいので、情報システム部門も現場の要望に合わせて動くことが多いんです。

南崎氏 現場がデータ化を進めると、基幹と連携したいという話になるので、結果的に情報システム部門も合流してくるケースが多いんです。情報システム部門と合わせてください、と言うと、一緒に巻き込んでやりましょう、という形になります。

山脇 ASTERIA Warpは、圧倒的に情報システム部門からの問い合わせが多く、やり取りや管理をするのも情報システム部門です。ただ、その恩恵を受けて課題が解決しているのは、現場の部門であることが多いんです。

森 たまに現場の方から連絡が来ることもありますが、なんだかんだで情報システム部門が出てきます。

南崎氏 一緒です。

南崎氏 kintoneに限った話ですが、(現場と情報システム部門の)どちらがアプリを作るのか、という問題もあったりします。

森 情報システム部門に期待するところで言うと、基幹システムまわり、ERPのデータの管理をちゃんとやっていく、ということでしょうか。

南崎氏 そうですね、ただ、システムを持っているのは情報システム部門でも、使うのは本当に現場の人たちなんです。

南崎氏 工場の現場の人たちは、そもそも端末を持って仕事をしないので、AIとは関係ない、という話になります。デスクワーカーの人たちはAIを活用しましょうとなりますが、アイデア出しや要約など、個人利用にとどまってしまうんです。

南崎氏 分析したいという声はあっても、紙やExcelのところでデータ化できていないので、まずAIを使う以前の問題ですよね、という話になることがそもそも多いんです。

森 kintoneで、今まで紙だったもののデータを集める。それを私たちがASTERIA Warpでつなぎ合わせて、AI-Ready(AIに使える形にデータを整えた状態)に持っていく。

南崎氏 システム化して、AIがデータを活用できる状態になっているかどうかで、圧倒的に差がつく状況に、もうなっています。提案していて、お客様と接していて、すごく感じます。今からでも、kintoneでなくてもいいので、できる範囲でシステム化を進める動きは、ぜひ皆さんにやってほしい。それが企業としての財産になっていくと思います。