司会進行・JSUGアンバサダー　星野さん、田村さん

JSUG田村さん：現在、ヒロセ電機さんはS/4HANAを活用した基幹システム刷新プロジェクトを推進中です。本日お越しいただきましたのは、プロジェクトのコアメンバーである次世代SCM委員会の方々です。

JSUG星野さん：それでは早速ではありますが、ヒロセ電機さんのお悩みはどんなものなのでしょうか？

ヒロセ・鎌形さん：私たちは日々、システム導入や業務改革の実現に向け議論を行っております。社内全体としては改革していくことへの賛成意見が主流で、敵対構造はありません。とは言え、BPRをどのレベル感で実行すべきか悩んでいます。大きい変化を狙う人間と、同じく変化を許容しつつも現実解を狙う人間と、個々でせめぎあいが起こることもあります。

JSUG久下さん：スクラップアンドビルドを本気でやる。その覚悟で臨むならS/4HANAの標準機能に合わせて業務改革を進めていくことになりますね。

JSUG酒井さん：プロジェクトの最初から経営層は「アドオンゼロ」と強調しています。しかしながらプロジェクトが進んでいくうちに、どんどんAs-Isに引っ張られてしまう

JSUG友利さん：「俺が見る帳票だけは今まで通りに出力してくれ」というリクエストがあったりしますよね。

JSUG酒井さん：笑。あるあるですよね。そういう話は。

ヒロセ・鎌形さん：システムのオペレーショナルなところはS/4HANAの標準機能にあわせるかアドオンするか、ある程度、結論を出せると思っています。ただシステム導入を行う私たちのところに、例えば、「グループ全体の物流倉庫を一カ所に寄せよう」といったレベルのBPRが持ち込まれることもあります。そうすると、組織も含めて全部変えていくみたいな話になってきます。そうなると、議論がまとまらなくなる。

JSUG酒井さん：それは大変ですね。もはや経営会議で扱うレベルの内容ですよね。

JSUG久下さん：意思決定も難しいですよね。業務改革とシステム導入についてお手本通りに進めるならば、今後の会社としてあり方や業務のあり方といった理想像を描き、その後、業務手順や業務フローはどうあるべきかといった全体設計を行うというアプローチになりますね。

JSUG都筑さん：本来、実施すべきアプローチですよね。ただ当社がS/4HANAクラウドを導入したときは、そういう手順は取りませんでした。

ヒロセ・鎌形さん：どのように実施したのか、そこを是非お聞きしたいです。

JSUG酒井さん：業務改革とシステム導入、そして組織改革はなかなか一回ではできません。業務フローや、製品、部品、子会社をどうするかなどいろいろな問題が出てきて、経営層を巻き込み、二転三転していきます。それを一度にやろうとするとプロジェクトは最後まで行きつかない。議論を重ねていくうちに最終的には「最適化する」という目的が残るから、その目的に向け、ステップ分けして実行することも大切です。つまり、負けるところは負けて、「もう一回」を何度も繰り返して、理想へと近づけていくアプローチがあると思います。

JSUG都筑さん：一回ではうまくいかない。だからまずはシステムを先に稼働させるという方法もあります。当社はそのケースでした。まずSAPに入れ替えることによって業務の見直しをする、今の業務ができるかどうかじゃなくて、このシステムと標準機能で業務が回るか確認していく。その作業を重ねていって、検証していくことで現場も体力がついていき、「じゃあそろそろ、この改革もできるよね」という話になる。全てを同時にやっていたら現場の体力が持たない。

ヒロセ・鎌形さん：当社もその考えに近いです。最終ゴールとして高いレベルのピクチャーを描くものの、そこからバックキャスティングしていく。けど、「（このステップとこの時間軸でなら）できるよね。」の基準がないのが悩みです。

JSUG酒井さん：我々の会社も改革のためによく考えようと言うと、部下に「そんなことしていたら動きませんよ」って言われることもあった。しかし、改革を実現するためには、稼働日を延期することも視野に入れた。うちは改革が目的であって、S/4HANAの導入や稼動が優先じゃない。だから稼働日を延期しようという判断になった。

JSUG都筑さん：うちの場合は、会計処理期日や予算の兼ね合いもあって、納期死守でやりました。全く逆ですね。ただその代わり、「サービスインの段階では、100点満点で機能が揃っている必要はない。」とシステム完成度のハードルを下げました。

ヒロセ・鎌形さん：なるほど。ある種真逆ですが、これは会社としてどちらが優先かということですね。

JSUG都筑さん：一旦、稼働させたら、その後一年間かけて触ってもらい、本当に不足している部分見極めてもらって、機能追加を判断していきました。最初は必要だと言っていた機能に対して、「もう要らない」とか「やっぱり要るよね」みたいなことを一年かけて話し合った。

ヒロセ・関さん：なぜそういった方法をとったのですか？

JSUG都筑さん：予算の問題も大きいですし、社内外でSAP人材は限定される。稼動を延期し、そういった人材をリザーブして「一年後に、また来てくださいと」はいかないので、運用開始してから１年かけて、手直しをしていくという形を取りました。

ヒロセ・鎌形さん：それもありですね。参考にさせていただきます。

ヒロセ・関さん：ちなみに私たちは、基幹システムにSAPを使うこと自体、今回がはじめてです。皆さんの会社では、SAP ECCを使ってから、S/4HANAを導入されましたか？

JSUG一同：そうですね。

JSUG久下さん：まず「現状のシステムサービスレベルは維持されない」ということを現場に理解してもらう必要がありますね。

JSUG酒井さん：正直ホントに大変です。沢山アドオンされたシステムが、自分たちの「標準システム」と思っていますので、「標準じゃない」と言ってもなかなか通じません。（笑）。むしろ、全くの新規導入の方が、過去のシステム仕様に引っ張られないからやりやすいと思いますよ。

JSUG都筑さん：そうですね。ECCでアドオンを山ほど作っていた方が大変です。「前はできていたのになぜ新システムではできないのか」という声が必ず出てくる。

ヒロセ・関さん：システムを変えることで、今までできなかったことができるようになったり、逆に今までできていたことができなくなったりがありますよね。