次の方法で共有


第 2 章: サンプル シナリオの概要

VanArsdel Heating および Air Conditioningは、加熱炉と空調の設置と修理において世界をリードする企業です。 この企業は、フィールド技術者を顧客の家に派遣して、すべてのブランドの空調設備を設置および修理します。 この 1 年間で、ビジネスは飛躍的に成長しました。 VanArsdel はまだ小規模企業ですが、手作業と書類を多用する作業プロセスに大きく依存していました。 ただし、次のセクションで説明するユース ケースで概説されているように、企業が成長するにつれて、コア ビジネス アプリケーションのスケーリングに多少の摩擦が生じました。

フィールド在庫管理

技術者が顧客の家に到着し、修理に必要な部品がトラックにないことに気付いたとき、彼らは時々店舗に戻って倉庫からそれをつかみます。 彼らは、部品が取り外されたことを示す一枚の紙に記入します。 部品が在庫にない場合、技術者はそれを要求します。 次に、オフィスの在庫管理者は、レガシ システムを使用して注文を出し、倉庫に適切な在庫があることを確認します。 この作業パターンは、次の非効率性をもたらします。

  • 技術者は、必要な部品をつかむために往復する必要があります。 部品の在庫がない場合、無駄な旅行になります。

  • オフィスの在庫管理者は、新しい消耗品を注文するために、在庫のある部品がリストされているブックを 1 日に数回チェックする必要があります。

  • 間違いが発生するため、オフィスの在庫管理者は、在庫に対してブックを監査する必要があります。

解決策は、フィールド技術者がフィールドから在庫を確認し、必要に応じてすぐに注文できるアプリを作成することです。 このアプリは、Azure で実行されている Web API とインターフェイスし、レガシ在庫管理システムへの制御されたアクセスを提供します。 オフィスの在庫管理者は、オンプレミスを実行しているデスクトップ アプリを介して同じレガシ システムに接続できます。 デスクトップ アプリを使用すると、オフィスの在庫管理者は、現在在庫がある部品と、不足している領域を補充するための注文をいつ行うかを確認できます。

フィールド在庫管理アプリ。

フィールドのサポート情報

1 人の技術者がフィールドで遭遇する可能性のあるすべてのモデルの加熱炉または空調設備についてすべてを知ることは不可能です。 ただし、優れた技術者チームの知識があれば、以前に問題を解決したことがある人が常にいます。 この豊富な知識を使用するために、個々の技術者は、現在直面している問題を解決した 1 人の人物を追跡しながら、他の複数の同僚と「電話タグ」を再生する必要がある場合があります。 このアプローチには、次のようないくつかの問題があります。

  • 問題を解決した一人を見つけるために何度か電話をかけることは、時間のかかるプロセスです。

  • 答えのある人は忙しく、最初の技術者を待たせる可能性があります。

  • 知識は、技術者の離職に伴って増減する情報カテゴリです。 重要な情報は、記録されない限り、簡単に失われたり、誤って記憶されたりする可能性があります。

解決策は、発生した加熱炉と空調 — に関する情報と、それらがどのように修正 — されたかに関する情報をサポート情報に取り込むことです。 技術者はアプリを使用して、顧客の敷地内にいる間に実行されたジョブや修理についてのコメントを記録できます。 同じアプリは、技術者が他の技術者が同様のジョブから学んだかもしれない役立つ情報についてサポート情報へのクエリを可能にするインターフェースを提供することができます。 サポート情報自体は、1 つ以上のキーワードに基づいて検索機能を提供する Azure Cognitive Search を使用してデータベースとして実装できます。

フィールドのサポート情報アプリ。

フィールド スケジューリングとメモ

顧客は VanArsdel オフィスに連絡して予約をします。 1 日を通じて、物事は変化します。 顧客は訪問をキャンセルし、緊急事態は他のイベントよりも優先されます。 顧客は、ジョブに関する追加情報を提供する場合があります。 オフィスの受付係は、この情報をレガシ 顧客データベースに格納します。

技術者は毎朝オフィスで、フィールドに向かう前に、レガシ システムからの印刷の形でその日の顧客訪問のスケジュールを受け取ります。 このスケジュールには、顧客とジョブに関する情報が含まれています。 この情報が日中に変更された場合、オフィスの受付係はフィールドの技術者に手動で電話をかけて更新を渡す必要があります。

フィールドにいる間、技術者はメモを取ります。 一日の終わりにオフィスに戻ったときに、同じ顧客情報データベースを手動で更新します。

現在のスケジューリング戦略には、いくつかの明らかな欠点があります。

  • 顧客が訪問をキャンセルし、オフィスが技術者に連絡できない場合、技術者は不必要な停止を行います。 技術者はまた、新しい顧客と再スケジュールされる機会を逃す可能性があります。

  • 技術者は最も重要なジョブに行かない場合があります。

  • 技術者は、1 日の終わりに顧客のメモを更新するのに多くの時間を費やします。

VanArsdel は、レガシ システムのフロントエンドとして機能するアプリを使用できます。 これにより、オフィスの受付係は予定とキャンセルを記録し、顧客の記録にメモを追加することができます。 技術者が使用できるアプリを使用すると、予定のスケジュールにリアルタイムでアクセスできるため、変更を確認できます。 同じアプリで、技術者は完了したジョブに関するメモを入力し、この情報をレガシ システムに保存できるようになります。

フィールド スケジュール アプリ。

フュージョン開発チームのメンバー

VanArsdel Heating および Air Conditioning は、前のセクションで強調した問題と非効率性を解決するソリューションを設計および構築するためのフュージョン開発チームを開始しました。 チーム メンバーは以下のとおりです。

  • Kiana Anderson: プロの開発者。 Kiana は、C# と .NET を専門とするフルスタック開発者およびソフトウェア アーキテクトです。 Kiana は VanArsdel のアプリケーションの多くを作成して設計しましたが、多くの依頼を受けて余力がなくなっています。 Kiana は Power Apps に高いレベルで精通していますが、開発者以外の人にアプリケーションを作成させることに懐疑的です。

  • Maria Zelaya: 在庫管理。 Maria は十分に倉庫に部品があることを確認し、そうでない場合は、Kiana が作成したレガシ システムを使用してさらに注文します。 しかしそれ以上に、Maria は在庫を監査し、ベンダーに最良価格を確認し、その他の在庫供給管理タスクを実行します。

  • Caleb Foster: フィールド技術者/エンジニア。 VanArsdel のリード フィールド技術者である Caleb は非常に知識が豊富で、経験の浅い技術者を指導するために頻繁に電話で話しています。 Caleb の時間は非常に貴重であり、VanArsdel では、彼に毎日できるだけ多くの重要顧客を訪問してほしいと考えられています。

  • Malik Barden: オフィスの受付係。 VanArsdel のオフィスの中心的存在である Malik は、すべての顧客からの問い合わせに答え、予定を立て、技術者が必要なときに答えを見つけるのを手伝います。 言い換えれば、Malik には負荷がかかっており、さらに優れた顧客サービスを提供するために、彼の反復的なタスクのいくつかを自動化する必要があります。

  • Preeti Rajdan: IT運用。 Preeti は、IT システムが稼働していることを確認する責任があります。 Preeti は、誤って「バック ドア」を開いたままにする可能性のあるセキュリティとアプリケーションについて多くのことを心配しています。 Preeti には余力がない状態で、新しいアプリが管理および管理しやすいことを確認する必要があります。