最高技術責任者で共同創設者のマイク・ベックリー氏は、ワシントン DC で開催された Appian World カンファレンスの 2 日目の基調講演で、今後何が期待できるかについて参加者に事前に警告しました。実際、AI 活用に関する同社の計画の一部は、単なる監視と洞察の生成を超えて、より「袖をまくり上げて」機能を直接管理および制御する方向へと進む強い兆しを示しています。
しかし、彼はプレゼンテーション全体を自分で行う機会を避け、代わりに実際に開発作業を行っているスタッフ数名に、今年後半にユーザーが発表すると予想される初期のプロトタイプについて話す機会を与えました。
まず最初に登場したのは、チーフ プロダクト アーキテクトの Matt Hilliard 氏です。彼は、仮想の衛星運用を実行するために使用する一連の管理プロセスについてプレゼンテーションの舞台を設定しました。その目的は、技術者が AI と Appian AI Co-Pilot を使用して、近い将来に可能になる可能性のある管理アクションの範囲を強化および拡張する可能性について、高レベルの見解を示すことでした。
衛星群の管理は、その性質上、非常に複雑なプロセスの集合体であるため、プロジェクト管理を簡素化または強化するための新しいプロセスの必要性が見つかる可能性が非常に高いユーザー ケースです。示された全体的な管理プロセスの基礎は、さまざまなプロセスとプロセス フローの図でした。デモの場合、最初のプロセス変更は、顧客からの異常な動作の報告を処理する方法を提供することでした。
副操縦士により、ユーザーは会話形式で AI リソースとコミュニケーションを取り、何を達成したいのか、それが図のどこに当てはまるのかを説明できます。その結果、図に新しいプロセスが追加されます。この時点で、レビュー手順など、プロセスに欠けている要素を視覚化できます。プロセス全体の複雑さを考えると、レビューには複数の入力が必要になります。ヒリアード氏は次のように述べています。
この段階で物事を正しく行うには、多くの人の目が必要ですが、仮想の部屋であっても、すべての人の目を同じ部屋に集めるのは困難です。
レビュー プロセスは、複数のタイム ゾーンと複数の言語にまたがって非同期的に機能し、ほぼリアルタイムの翻訳を提供して同僚が自分の言語で作業できるようにする必要があります。新しいレビュー プロセスに関するすべての提案はコパイロットに取り込まれ、レビューのすべての関係者が自分の言語でコメントと追加を受け取り、開発リーダーがそれを含めるかどうかを決定できます。提案を受け入れると、更新されたプロセス ダイアグラムにその提案が含まれます。
さらに、副操縦士は、企業がエンタープライズ アプリケーションを構築する方法や、すでに構築されているものについての知識に基づいて提案を行うこともできます。たとえば、問題を抱えている顧客のアカウント マネージャーに常に連絡を取ることは、一般的なビジネス プラクティスです。この機能は、業界セクターのコンプライアンスやガバナンス規制など、プロセスの開発方法に影響を与える可能性のあるより広い領域に容易に拡張できます。それらを含めるかどうかの最終決定は、開発リーダーである個人が行います。
開発リーダーがこのプロセスを前進させ、開発の準備を整えるためにできることは、提案されたプロセスを充実させる追加手順について副操縦士に提案を求めることです。典型的な対応としては、異常の性質とこれまでに収集された証拠に関する関連データを顧客から収集し、関係チームが適切な是正措置をどこから探し始めればよいかを把握することが考えられます。Hilliard 氏は次のようにコメントしています。
私はとりとめのないくだけた方法で答えるだけで、副操縦士がそれを箇条書きにしてフォーマットし、開発チームが作業を開始できるようにしてくれます。インターフェイス デザイナーに立ち寄って、開発チームに渡したメモを表示してもらうこともできます。これにより、フォームがどのように見えるか、実際にどのように機能するかを把握できます。
これは、既知の解決策で問題をより早く解決するために、関連するコード再利用の機会を提案する機会にもなるかもしれません。これは、提供されるビジネス価値などに基づいて優先順位を設定するという点で、特に作業を整理することで開発チームを支援する副操縦士の一部を形成する可能性があります。
テクノロジー戦略エンジニアの Julian Grunauer が、構築されたアプリケーションをユーザーが使用する際に AI がどのように役立つかについて説明しました。特に、従来のアプリケーション構造から生じる大きな障害の 1 つを AI がどのように克服できるかについて説明しました。
アプリケーションは、データ インターフェイスとアクションの 3 つから構成されます。データは、ユーザーが関心を持つ情報です。インターフェイスは、その情報を説得力のある方法で提示し、アクションはそのデータを変更できます。この方法は過去 30 年間機能してきましたが、欠点がないわけではありません。ユーザーであるあなたが、ネストされたリンクのウェブをナビゲートして、データとアクションが実際に保存されている場所を見つける責任があるからです。
必要なページにたどり着くまでに何度もクリックや検索を繰り返す必要があり、一度ページを保存するには、個々のインターフェースをブックマークするか、別の場所に移動するために新しいタブを開く必要があります。解決策は、コンピューターにインターフェースと意味的に検索されたデータを表示させ、必要なアクションを実行するようシステムに指示することです。Appian は現在、この新しいテクノロジーを適用して、ユーザーがビジネス アプリケーションとやりとりする方法を再考する方法を模索していると彼は述べました。
同じ架空の衛星管理会社を基に、シナリオは衛星の 1 つが動作しない理由を突き止める役割に移りました。障害に関する報告はすでに多数ありますが、それらはほぼ同数のさまざまなアプリケーションとインターフェイスに分散しています。そのため、副操縦士に指示して、システム全体で利用可能なすべてのデータからその衛星のすべての障害報告を検索し、その保存場所に関係なく、実際の原因 (電源障害など) を指摘できるような順序立てて提示する必要があります。
これにより、経験豊富なエンジニアは、そのエリアに関するメンテナンス レポートなどの履歴記録を含むすべての関連データを Co-Pilot で検索できます。これは、これまで非常に時間のかかる作業であり、役立つ可能性のあるすべての関連データを見つけられない傾向がありました。Grunauer 氏は次のように語っています。
Co-pilot は、必要なタスクを呼び出し、データをフィルタリングし、意味的に検索を作成し、自然言語をこれらのクエリに変換できます。フォーム情報を入力し、アプリで直接編集されている Word 文書に至るまで、このすべてのドキュメント情報を Appian 内から直接識別、生成、作成できます。そして、ユーザーとしての私たちの責任は、AI が生成したこの情報を Appian 内で直接編集および確認することです。これは単一のディスプレイです。タブを無数に開いたり、見たいページを個別にブックマークしたりする必要はありません。後で保存できる単一のワークフローがあります。
最後に、製品戦略ソフトウェア エンジニアの Brooks Watson 氏が、将来の可能性に関する発表の中で唯一の本当の発表を行いました。Appian 3D Plus の正式リリースです。これは、Appian がますます悪化していると考えているサイクルを正すことを目的としています。Watson 氏は次のように説明しています。
従来、3D モデルはクライアントのデスクトップ ベースのアプリケーションに合わせてロックされていました。最近では、Web ベースのサービスが市場に登場しましたが、ファイルを放棄して安全でないクラウド環境に保存する必要があります。一方、関連データは異なるシステムにサイロ化されています。モデルを表示するだけでなく、それを他のエンタープライズ データと完全に統合できるとしたらどうでしょうか。モデルを中心にワークフローを構築できるとしたらどうでしょうか。
これは、カンファレンスで発表された Appian の強化された Data Fabric に便乗したもので、3D モデルをアプリケーションに直接取り込んで、直接表示および利用できるようにします。表示には、個々のパーツを表示するためのドリルダウンと、追加のデータ ソースとして利用できるようにすることも含まれます。これらはすべて、副操縦士が直接操作できる製品の視覚化の一部として利用できるようにすることができます。これにより、安全で準拠したプラットフォーム内で、問題の調査と原因の特定が容易になります。
同じ仮想的な衛星電源障害を使用して、彼は 3D Plus のデモを行い、最も可能性の高い原因としてソーラーパネルを指摘しました。そして、副操縦士が発見した文書を自動的に添付して送信し、送信をクリックすることで、それらの発見を運用化する方法を示しました。ここで、イベント ストリーミング機能によりアクションをリアルタイムで監視できるようにすることで、データ ファブリックを介してアクションをガイドし、チームが常に最新のデータを使用して作業できるようにします。
最後に、CTO のベックリー氏が、同社は検索、拡張生成、AI の領域をはるかに超えて、AI エージェントを呼び出し、現在利用可能なすべての外部ツールを活用する機能的なアクションの領域に移行していると述べて締めくくりました。
同社は、日常業務で AI アプリケーションを制御する役割を担う必要があると認識しているものの、プロセス管理を構成する要素に関する視野がますます広がる中で、AI テクノロジーを自社の業務にまったく役立てられないと考えるほど同社がこの技術を軽視しているわけではない。
diginomica および diginomica ロゴは diginomica Limited の商標です。
© Diginomica Limited およびそのライセンサー 2013- 2024
元記事: https://diginomica.com/appian-world-eating-your-own-ai-dog-food