「Microsoft Power Platform と AI Builder コンポーネントにより、Dynamics 365 プラットフォーム内で革新的で十分に統合されたソリューションをマーケティングおよび販売ビジネス パートナーに迅速に提供することができました。このプラットフォームは、迅速なアプリ配信の新しい世界におけるゲームチェンジャーです。」Jim Parker: Web およびコラボレーション サービス マネージャー リファレンス:
https://customers.microsoft.com/en-au/story/810656-hexion-manufacturing-power-platform
トピック 1、Contoso, Ltd
会計システムと購買
同社にはクラウドベースの ERP/会計システムがあり、総勘定元帳、売掛金、買掛金モジュールを使用しています。現在のシステムには、製造現場または製造計画機能を処理するモジュールがありません。
従業員情報は、会計システム内でのみ維持されます。情報へのアクセスは、プライバシー規制および会社のポリシーにより厳しく管理されています。
原材料のすべての購入は、エンジニアリング プリントの作成時にエンジニアリング部門によって生成された部品表 (BOM) に基づいて行われます。
本社は Dynamics 365 Finance を使用しています。運用マネージャーは、Dynamics 365 Finance が少なくとも 5 年間は製造工場に実装されないと報告しています。
製造・企画
Contoso, Ltd. が買収したプラントでは、Microsoft Excel ワークブックと Microsoft Word ドキュメントを使用して、販売パイプライン、見積回答の要求、および作業見積もりを追跡しています。ドキュメントは共有ネットワーク ドライブに保存されます。
印刷された設計図は、複数の注文で誤って使用されることがあります。これにより、やり直し、コスト超過、納期の遅れが発生します。
同社は Job Traveler ドキュメントを使用して、実行する必要がある操作と、特定のジョブ番号に必要な材料を詳述します。
販売
見積依頼は現在、販売ログ ワークブックに保存されています。ワークブックには次の情報が含まれています。
お客様依頼番号
顧客名
説明
販売の推定値
受注、失注、入札なし、キャンセルの値を含む見積依頼 (RFQ) のステータス 営業マネージャ、営業担当者、見積担当者の名前 製品ラインの名前 見積書が顧客に送信された日付 おおよその開始日と終了日プロジェクトの受注日 (受注した場合) 受注した場合に割り当てられるジョブ番号 会社には、見積もりを管理するための正式なプロセスがあります。正式なプロセスが実施されていても、人件費や材料の見積もりなど、必要なサポート ドキュメントが不足している販売見積もあります。同社は、正式なプロセスをアプリの一部として組み込みたいと考えています。
営業担当者は、販売が終了し、顧客の注文書を受け取ったときに、販売ログの RFQ のステータスを [受注] に設定しないことがよくあります。
販売ログの成約確率フィールドは、販売が成立した場合は 100% に設定され、販売が失われた場合は 0% に設定されているため、現在、正確な販売パイプラインと勝敗情報を報告することはできません。
顧客がネットワーク ドライブにフォルダ システムを設定しても、現在のバージョンの販売見積の製造部門への引き渡しは改善されませんでした。
要件
解決
Microsoft Teams と Power Platform を使用するソリューションを作成する予定です。
Sales Log ブックを Common Data Service データベースに変換する必要があります。
各部門には個別の Teams チャネルがあります。従業員は、自分の部門のチャネルにのみアクセスできる必要があります。すべての従業員と経営陣は、一般的な企業チャネルへの読み取りアクセス権を持ちます。Teams サイトには、次のチャネルが含まれている必要があります。
販売
販売ダッシュボードは、販売チャネルに存在する必要があり、地域ごとの販売ノルマのアクティブな見積もり、販売パイプライン、および年初来の販売 KPI に関する情報が含まれている必要があります。
すべてのセールス関連のドキュメントは、このチャネルのファイルの場所にあるフォルダーに保存する必要があります。ドキュメントのバージョン管理が有効になります。ドキュメントの最新の 10 バージョンを保存する必要があります。
製造業
月ごとのキャパシティ ヒート マップと、翌月に成立する可能性が高い予想売上を表示するダッシュボード。
ジョブ セットアップ テーブルからのすべての進行中のジョブの、顧客別、開始日別、および製品別の並べ替え可能なリスト。
印刷された紙の図面は、もはや使用してはなりません。図面は、製造チャネルのファイルの場所にあるフォルダーに保存する必要があります。
全般的
次のアプリを作成する必要があります。
時間追跡
モバイル デバイスで各従業員の時間を追跡するには、キャンバス アプリを作成する必要があります。アプリには次のものが含まれている必要があります。
サインイン画面
従業員の週の時間エントリを一覧表示する画面
従業員の現在の時間エントリを編集する画面
アプリは次の要件を満たす必要があります。
アプリは、そのデータを既存のオンプレミスの Microsoft SQL Server インスタンスに格納する必要があります。
従業員は、アプリから自分のタイム トラッキング レコードにのみアクセスできる必要があります。
従業員は、各顧客ジョブの製造に費やされたすべての時間を記録する必要があります。
従業員は、当日と前日の時間記録のみを変更できる必要があります。
従業員は自分のバッジをスキャンしてチェックインおよびチェックアウトできる必要があります。各バッジには、従業員の名前と現在の写真が含まれています。
すべての従業員バッジに QR コードを追加する必要があります。コードには従業員番号を含める必要があります。
Job Traveler ドキュメントは PDF ドキュメントとして印刷する必要があり、ジョブ番号とタスク番号の UPC E バーコードを含める必要があります。バーコードは時間追跡アプリケーションで使用されます。
販売
Sales アプリは次の要件を満たす必要があります。
簡単にアクセスでき、見積もり、見積もり、およびエンジニアリング ドキュメントのすべてのバージョンを維持する、すべての販売パイプラインと見積もり情報を一元的に管理します。
現在アクティブなすべての見積もり、販売サイクルでのステータス、成約の可能性、推定製造日と設置日を顧客別、製品部門別、ステータス別、営業担当者別に表示するダッシュボードを含めます。
セールス ログ アプリは、セールス ライフサイクル中に必要な見積もりとサポート資料の完了に関連するプロセス標準を適用する必要があります。
セールが成立するとすぐに、次のアクションを自動的に実行します。
連続ジョブ番号を生成します。
主要な販売情報を、製造で使用されるジョブ セットアップ エンティティにコピーします。
販売が失われた場合は、[ステータス] フィールドを [紛失] に設定し、損失の理由をテキスト フィールドに入力する必要があります。説明フィールドの最後に理由を追加する必要があります。
従業員が顧客のサイトにいる場合でも、販売ログを簡単に更新できるようにします。
製造・企画
アプリは次の要件を満たす必要があります。
パイプラインの現在および今後の注文の容量リソース要件を計画および予測する機能を提供します。
紙のタイムシートを交換し、チェックイン、チェックアウト、休憩、および各ジョブ タスクに費やされた時間を追跡します。
作業の実行中および設計図面の表示に要した時間を記録します。
ジョブ セットアップ エンティティは、そのデータを既存のオンプレミス SQL Server インスタンスに格納する必要があります。
Job Traveler ドキュメントは、PDF ドキュメントとして生成し、Job Setup エンティティから印刷する必要があります。
問題
顧客要求番号が解釈しにくいというレポートを使用します。番号をシステム生成の連続番号に変更するように要求されます。
オペレーション マネージャーは、ユーザーがタイム トラッキング アプリに誤ってサインインすることが多いと報告しています。オペレーション マネージャーは、従業員がバッジをスキャンしたら、タイム トラッキング アプリに従業員の写真を表示するように依頼します。
ユーザーは、すべての画面から入力された 1 週間の合計時間を確認できるようにしたいと考えています。
テスターは、自分のタイム エントリだけでなく、タイム トラッカー アプリでもタイム エントリを確認できると報告しています。さらに、既存の時間エントリを編集することもできます。