関西電力グループの情報通信事業再編のお知らせ&ブリ会議参加報告

31 1月

新年あけまして、おめでとうございます!Dynamics特派員こと、吉島良平(Microsoft MVP  for Business Applications )です。

代表の小林からは年頭所感が出ているのですが、私のほうは、プロジェクトや資料作成などでバタバタして、本投稿が遅れてしまいました。本当にごめんなさい。

まず最初に、ご存知の方もいらっしゃるかもしれませんが、1月末にプレスリリースが出ていますように、関西電力・関西電力グループの情報通信事業再編がアナウンスされました。

4月から、関西システムズが関西電力向けのITサービスを提供、OPTAGE(オプテージ)が、所謂外販部隊ということになります。

という事で、当社Pacific Business Consulting, Inc.は4月1日より、OPTAGEの子会社として、Dynamics365を外販していくということになります。関西電力グループ企業としてのシナジーをあげつつ、より多くの方々にDynamics365 +Power Platformをご利用いただき、ITを内製化していただき、DXを促進していくお手伝いができればと思っております。

心も新たにということで、当社の”企業理念””バリュー(行動指針)“はウェブサイトに掲載があるので、ミッションとビジョンを。

今年も、社員一同Dynamicsに頑張りますので、ご支援・ご鞭撻のほど何卒宜しくお願い致します。

さて、1月は8日間ほど、長野県でDynamics365 Financial & Operations ( 旧Dynamics AX)プロジェクトのワークショップに出向いていました。精密機器メーカー様の案件で、お客様も協力的で、工場に職人気質の方々が多く、非常に有意義な時間を過ごさせていただきました。やっぱ日本のモノ造り工場最高!工場Love!

でも、当然ながら、寒いんですよね(笑)工場の方々に言わせると、マイナス10度を超えないと驚かないとのことで、いやぁ、凄いなーと頭が下がる日々です。ほんと寒いので、サウナ/温かい食事が必須。

しっかりと本稼働に導いていきたいと思っています。みんな強力してDynamicsに頑張ろうね!

さて、1月末に富山県の宇奈月温泉にて、この時期恒例になってきた鰤会議(BuriKaigi)に参加してきました。

えっと、違いますよー!鰤を食べるだけの目的でわざわざ出向いているのではありません(笑)ほら、↓でも、むっちゃ美味しそうでしょ?↓

こちらも寒かったです。みて、この雪山の風景!(会場裏から撮影したもの)

毎年感動するのですが、登壇者も、コンテンツも、凄くて、えっ?ここ富山?って思うんです。Javaも.NETも超豪華メンバーなんです。

このC#ドキドキライブコーディングを見れるなら、僕は日本全国どこにでもいきますねぇ。プログラマーをやっている方々には是非みていただきたいセッションです。プログラマーによるエンターテーメントですからね。石野さん、小島さん、鈴木さん、室星さん、今年も楽しませてくれてありがとう!

僕は、Dynamics365-CRM側のMVPである杉本和也氏(API&コネクタで同じみCData所属)と、下記のタイトルでセッションを行いました。昨年度の続編です。

SELECT*FROM[CLOUD] by cdata 疋田さん、やるよねぇ。

まずは、こんな感じで、

今年はフィールドサービスエンジニアの作業と、バックオフィスのオペレーターの連携シナリオを模索してみました。実はこの領域は特にシステムが分断されているケースが多いんですよね。あと作業報告書がデータ化されるまでのタイムラグが結構ありがちで、使用在庫を消費したりするタイミングが遅延したりで、サービスエンジニアが持ち出したサービスパーツが適切に管理されず在庫管理がうまくいないとか、保証のコストがつかまえられないとか結構多岐にわたる課題があります。

実はマイクロソフト製品/サービスだけでこの業界のITインフラを管理する方法/設計はいくつかのパターンがあります。お問合せを受けてから作業指示書をつくるという流れで、相方の杉本氏がデモンストレーションを行いました。和也流石ですねー!

アウトルックの右上に、Dynamicsボタンがあって、受付担当者はOutlookのメールのやりとりから自然な流れで簡単に、Dynamics365のフィールドサービスモジュール(CRM)へ作業指示書がつくれるんです。

Outlookのリボンバーの右上にDynamics365ボタンがありますね。ここからサポートの入力ができるのです。ほんと、便利なんです。

続いて、サポート担当者がメール/電話など得た現象から、原因を調査して、

作業指示書を作成、エンジニアをアサイン

作業結果の入力、予定を更新します。

ここまでがCRM側(フィールドサービス機能)の作業ですね。ここから室長のほうでバトンタッチして、Dynamics365 Business Central (旧Dynamics NAV)で、CRM側でデータ化された作業結果をERPに取り込むという話をさせていただきました。

実は旧Dynamics NAV(D365BC)、Dynamics AX(現D365FO) に、サービスモジュール機能をマイクロソフトが買収して機能追加したという過去の経緯から、D365シリーズのERP機能群であるD365BCやD365FO*には同等レベルの修理機能が含まれています。修理の問い合わせ→作業指示書作成→作業者の割当→修理の実作業→作業報告書記入→修理保証・有償修理売上が管理できます。(*D365FOはプロジェクトモジュールと合わせて利用することが必須。D365BCはサービスモジュール単独利用可能)

作業報告書の入力画面はこんなイメージです。

保証(ワランティー)の範囲にあれば、システムが利用したパーツや作業工賃は請求せず、交通宿泊費などの実費のみを請求しようとしてくれます。

どこが壊れて、どんな現象で、どんな対応で解決した。これらの情報を世界各国の拠点から集めている弊社のお客様もありますし、保証作業、保証外無償作業分のコストを把握して、修理製品の仕入先との来期の保守契約を考える弊社クライアントもあります。こういった情報/データの管理がDynamics365をご利用いただければ、網羅的に管理ができるわけです。

異常検知には、Azure IoT Serviceの活用が有効!

熟練の技術者による遠隔地サポートには、HoloLensを活用したRemote Assistもいける!

ということで、まとめなんですけどね。シームレスにつながる事は非常に重要ですね。

もう少し製品間連携を深堀してみます。

パターン①>作業報告書のデータを会計PKGに連携する

会計PKGに流すI/Fが必要ですね。多分、管理会計の貴重な情報がいくつか落ちちゃいますね。

パターン②>作業報告書の会計データをD365FS→Dynamics365BC/FOに連携する

D365BC/FOに会計データのみ連携すると、修理以外に物販などの請求があると、両方を一括請求書に表示するのは難しくなりますね。ERP側で作業実績の詳細が確認できませんね。

パターン③>作業報告書のデータをDynamics365FS→D365BC/FOに連携する

作業見積もりの版管理や与信管理などをどうするか?考えなくてはなりませんね。

パターン④>Dynamics365FSで指示を出し、作業報告書のデータをPowerApps入力してD365BC/FOに連携する

パターン③に比べて簡単な入力画面をPowerAppsで作れるので、フィールドサービスエンジニアがリアルタイムで入力できる可能性が高まりますね。

パターン⑤>作業報告書のデータをD365BC/FOだけで管理する

ERP側にあるサービス管理モジュール(修理機能)に作業報告書のデータをフィールドサービスエンジニアもしくはインサイドサポートの方が手入力しなくてはなりませんね。作業報告書がデータ化されるまでに少し時間がかかりそうですね。

パターン⑥>作業報告書のデータをPowerAppsで入力してD365BC/FOに連携する

パターン⑤に比べて簡単な入力画面をPowerAppsで作れるので、フィールドサービスエンジニアがリアルタイムで入力出る可能性が高まりますね。

というようなPros&Consがあるわけですね。ライセンス価格の観点からは⑤⑥ですかね。でもフィールサービスエンジニアの数が多い場合は③④ですかね。でも課題がありますね。

③④の場合は、D365BC/FOのERP側でサービス(修理)のモジュールを使わず、販売モジュールに連携するにとどめるという方法もありますが、修理履歴はD365FS側に残りますね。結局うまくPower BIなどで見える化ができればという事になるのかもしれません。

マイクロソフトのビジネスアプリケーションを活用して、フィールドサービス、保守メンテナンス領域へのシステム構築を、ご検討されている方々の参考になれば幸いです。

お知らせ-DirectionsAsia

お知らせ-JavaRoomでのセッション/やるねーcdata

杉本和也さん、ありがと。また美味しいもの食べよ!来年も宜しくお願い致します!

 

セミナーが終わったら、みんなで夜の鰤会議!

今年も楽しかった。学びの多かった鰤会議。来年もDynamics365を北上させたいと思います。

皆様、お疲れ様でした!