免責事項
高度な分析の分野が勢いを増しており、より多くの専門家がこの分野に関心を持っていることは誰もが認めています。 同時に、オープンソースで分析アプリケーションを開発する際のビジネス分析プロセスの構築に関する明確でアクセス可能な情報はあまりありません。 したがって、この方向の枠組みで適切なレシピ（アクションのシーケンス）を決定することは非常に困難です。 この点で、重要な成分を体系化し、対象分野を解決し、漠然としたタスクを「やる、わからない」を将来のアプリケーションの詳細な要件に変えるためのアナリストの行動を説明するステップバイステップの指示を共有することにしました。
以下のプロセスの説明は、当社の分析アプリケーション開発の詳細に基づいています。 この資料は、アプリケーション開発者だけでなく、初心者のBIアナリストにも役立ちます。
それでは始めましょう！
分析アプリケーション開発プロジェクトの分析プロセスは、次の手順で構成されています。
- 問題の記述と作業の開始。
- 顧客調査とオープンソースの使用。
- 分析、要件および文書の作成。
- 最終文書「アプリケーションの説明」の作成。
問題の記述と作業の始まり
作業は、「特定の会社Horns and Hoovesがあり、何らかの分析アプリケーションが本当に必要です」という言葉で到着したセールスマネージャーから始まります。 このような問題の定式化は私たちの生活では非常に一般的であり、私たちはずっと前からそれに慣れています。
したがって、最終的に「何か」ではなく、顧客にとって有用なアプリケーションであることが判明するための最初の質問は、「どの顧客が「痛み」（問題）を抱えているか」という質問です。 」
この質問に対する答えは、次の2つの方法で得られます。
- お客様に尋ねます。 方法は正しいですが、最初の会議の前に顧客の痛みを知っておくことをお勧めします。そうすれば、顧客は戸口から「好き」になり、同じ言語を話すことができます。 多くの場合、顧客自身は特定のプロセスのボトルネックを知らないか、単にそれらを策定することはできません。
- オープンソースで個別に答えを見つけ、主題分野の専門家を集めます。 解決したい問題を理解していない顧客の場合、このコースが唯一可能なコースです。 この状況は、ビジネスの「内部」であるため、顧客がそれを側面から見て問題領域を明確に区別することが難しいという事実によって説明されると思います。
したがって、私たちの実践では、顧客との最初の会議の前にアナリストの仕事がオープンソースの独立した詳細な研究に専念している場合、つまり、積極的にグーグルとYandexを使っている場合、私たちはしばしば2番目の方法に行きます。 次の質問に答える情報を探しています。
- 顧客のビジネスで、または市場の他の企業との同様のビジネスで、どのプロセスが実行されますか？
- そのようなビジネスの中でどのようなデータが流通していますか？
- このようなビジネスで、お客様や他の企業が直面する問題は何ですか？
- これらの企業はどのような戦術的および戦略的目標を自ら設定していますか？
- ビジネスの主要業績評価指標（KPI-主要業績評価指標）とは何ですか？
オープンソースを研究する主な目的は、最高品質の顧客との初対面の準備をすることです。 これは、彼と同じ波長で調整し、発見した問題領域の解決策にプロジェクトを向けるために必要です。
顧客との最初の会議の準備のタイミングについて話す場合、費やされる時間は異なる場合があります-数時間から数日-この期間は、タスクの複雑さ、業界、および他の多くの要因によって異なります。 いずれにせよ、アナリストは彼について何も知らずに顧客に行く権利がありません。 彼は少なくとも可能な限り準備する必要があります。
顧客調査とオープンソース
この段階は、顧客との最初のインストール会議から始まります。そこでは、プロジェクトの目標に対するビジョン、最も不透明なビジネスプロセス、問題があると見なされるゾーンなどを見つけようとします。 次に、前の段階で開始した調査および分析作業を継続します。 また、クライアントから提供された資料がデータに追加されるため、調査作業の範囲が広がります。
通常、顧客との数回の会議が必要です。その間に、プロジェクトの実装に必要な最大量の情報を「削除」しようとします。
受け取って分析した情報量が「クリティカルマス」を獲得している場合、次の段階に徐々に進みます。
私たちのプロジェクトの良い例は、「商業銀行のローンポートフォリオを管理する」ケースです。
ケースバンク。 クレジットプロセス
ほとんどの銀行の主な収入は、企業や一般に融資を提供することです。 私たちは、大規模な借入企業へのローンの監視を任されました。
銀行では、各企業がプロファイルを作成しました。プロファイルには、企業の信頼性、財務実績に関する情報が含まれています。 各ローンについて、タイムリーな支払いが追跡されます。 次回の支払いが遅れた場合、銀行は遅れの理由を見つけ、借入会社に関して行動を起こします。
この主題分野のアプリケーションの主なアイデアは、次のとおりでした。ローンの量の管理、借り手の信頼性、支払いスケジュールの順守、およびローンの他の指標。
銀行の金銭的条件で「不良」なローンが多いほど、ローンポートフォリオの質は低下します。 したがって、銀行経営者は、すぐに「不良」ローンを確認し、問題のあるローンの詳細な状況を確認し、借入会社に関連するさらなるアクションを決定する必要があります。
アプリケーションでの作業は、最終的にゲームのようなものになります。「問題のあるローンを見つけて、手間のかからないようにします。」
この記事をさらに読みながら、この主題分野の分析プロセスの段階を「試して」ください。 これはずっと読みやすいと思います。
分析、要件形成、文書化
実際には、この段階への移行は存在せず、この段階の作業は前の段階の作業と並行して実行されます。 しかし、分析プロセス全体が段階的に、より調和的で構造的に見えるように、意図的に強調しました。
したがって、このブロックのフレームワーク内で、次のアクティビティが実行されます。
- ブレインストーム;
- 情報の分析と要件の形成;
- アプリケーション画面のスケッチ。
プロジェクトアナリストは、顧客のビジネスに関する多くの情報を既に受け取った後、会議（ブレインストーム）を開催します。そこで、彼と当社の主要なアナリストは、将来のアプリケーションの基礎となる主要なアイデアを思いつきます。 その後、これらのアイデアが深く練られ、実装の段階が決定されます。 その結果、最終的に顧客のビジネスの主な問題を定式化し、アプリケーションの対象を決定します。
次に、指標の構成を決定し、監視と分析を行うことで、顧客が痛みを満たせるようにします。 顧客がこれらのインジケータを操作する画面フォームの構成と構造を指定します。
「通常の」BIレポートを作成するのではなく、3次元のアプリケーションを作成していることに注意してください。 これらのアプリケーションでは、分析情報の視覚化は3Dオブジェクトの形式で実行され、テーマ別のインタラクティブシーン（画面フォーム）に結合され、論理的な遷移によって相互接続されます。 それらをテキストで説明するのは非常に難しいので、さまざまな業界所属の多くのアプリケーションの画面形式の例を提供します。
3次元アプリケーションを開発しているため、会議にはアナリストだけでなく、インフォグラフィック、ユーザビリティ、3Dデザイナーの専門家も参加します。 画面レイアウト、顧客データを視覚化する3D画像、画面間の便利なナビゲーションなどを提供します。 将来のアプリケーションの複雑さに応じて、このような暴風雨がいくつかあります。
各会議の結果に基づいて、プロジェクトアナリストは、「アプリケーションの説明」ドキュメントの将来のアプリケーションのすべての要件を修正します。 その構造については、次のセクションで説明します。 分析のすべての結果を注意深く文書化する必要があるという事実に注意を喚起したいと思います。これは非常に重要です。
最終文書「アプリケーションの説明」の作成
それでは、「Application Description」ドキュメントには何が含まれていますか？ その構造は非常に単純です。
- 問題の記述と作業の開始。
- 顧客調査とオープンソースの使用。
- 分析、要件および文書の作成。
- 最終文書「アプリケーションの説明」の作成。
「サブジェクトエリアの説明」セクションでは、ビジネスに関する情報を記録します。これは、将来のアプリケーションの要件を形成するために重要です。 このセクションは、セマンティックエラーを回避するために、必ずお客様と合意します。 なぜなら、それらが現れたとき、この説明からの結論は誤りであり、その結果、アプリケーションをやり直す必要があるからです。
たとえば、顧客との会議の結果に基づいて、ローンの監視に重要ないくつかの指標を記録しました。 このセクションを他の顧客部門と合意した後、これらの指標の一部はローンポートフォリオの監視にとって重要ではないが、いくつかの重要な指標が欠落していることが判明しました。
「目標とタスク」セクションには、同僚とのブレインストームおよび顧客とのミーティングで策定したアイデアが含まれています。
最後に、ドキュメントの最もボリュームのあるセクションは「ソリューションの説明」です。 次の点に影響します。
- 分析されたインジケータのリスト。
- これらの指標を抽出するデータソース（情報システム）。
- アプリケーション画面の構造。
- 各アプリケーション画面のスケッチとテキストの説明。
- アプリケーションを使用するユーザーの主なシナリオ。
インディケーターとデータソースについて書くことは何もありません。それらはすべて明確です。 画面の構造の説明も比較的簡単です。アプリケーション画面のリストと、画面間の可能な遷移が含まれています。
スケッチについて詳しく見てみましょう。 最終的なドキュメント「アプリケーションの説明」を作成するとき、グラフィックエディターおよび3Dモデリングツールで3Dデザイナーがスケッチを実行します。 将来のアプリケーションのスケッチは、スケッチから作成され、「ほぼ同じ」ではなく、描画されたスケッチとまったく違いはありません。 顧客がプロジェクトの初期段階で、少なくとも画面の形で将来のアプリケーションを確認し、コメントを作成できるように、ドキュメントには詳細なスケッチが必要です。 編集は、セマンティック（たとえば、間違ったインジケーターが表示される）と視覚化（別のカラーパレット、インフォグラフィックの他の要素が必要、インジケーターを画面の別の部分に移動する必要があるなど）の両方です。
ユーザーがアプリケーションを操作するためのシナリオを開発するとき、1つから5つの主要なシナリオを作成します。 ユーザーが段階的に目標を達成し、アプリケーションの特定のタスクを解決するように導くシナリオのみを選択します。 スクリプトの助けを借りて、すべての目標が達成され、すべてのタスクが解決されたことを確認した場合、アプリケーションは正しく設計されています。
最終的なドキュメント「ソリューションの説明」は、顧客との調整を何度か繰り返し、最終バージョンは作業のパフォーマンスに関する契約に添付されます。 この合意文書によると、プロジェクトは次のように継続されます。
- アプリケーションの視覚部分に関するステートメントの形成。
- アプリケーションデータの読み込みと処理に関するステートメントの形成。
- 3Dコンポーネントの開発。
- アプリケーションのレイアウト。
- アプリケーションのテストと承認。
しかし、これらの作品は他の記事の主題です。 この記事は、私たちのプロジェクトにおけるビジネス分析のプロセスのみに当てられています。
結論の代わりに
結論として、アプリケーションを開発する際に従うべきいくつかの原則を挙げたいと思います。
それらの3つだけがあります。
- 顧客のビジネス写真の視覚的表現。 すでに画面上のアプリケーションを初めて知っているユーザーは、自分の興味のあるビジネスのすべての部分を確認し、最初の連絡時に、どのゾーンが問題で、どのゾーンが逸脱することなく動作するかを理解する必要があります。 提示される情報は、リーダーにとって直感的である必要があります。リーダーにとって、時間は限られたリソースです。 彼は長時間のトレーニングを受ける機会がありません：数字の解釈、スクリーン上の視覚的なオブジェクトなど。 インタラクティブな視覚化の助けを借りて、異なるセクションのデータの直感的なプレゼンテーションを実現しています。 同時に、タッチスクリーンを介してアプリケーションとの連携を構築しています。これにより、快適性、人間工学、そして最も重要な分析プロセスへのユーザーの関与が得られます。
- 問題の原因の開示。 問題点を選択すると、ユーザーはドリルダウン機能を使用できるようになります。ドリルダウン機能を使用すると、次の画面フォームで問題のゾーンに深く潜り、偏差の原因を確認できます。 さらに、アプリケーションは、問題を特定するための可能なオプションをユーザーに提供する必要があります。
- 技術的な美学。 アプリケーションはすごい効果、すなわち 魅力的で直感的で便利なものでなければなりません。 私たちは、これらの側面が機能コンポーネントとともに平等な位置を占めるべきだと確信しています。
リストされた原則は非常に単純ですが、それらを遵守することで、お客様に利益をもたらす興味深いソリューションを作成することができます。
そのようなアプリケーションがどのように見え、どの産業に適用するかを理解できるように、おそらくもう少し写真を追加するでしょう。
最後まで読んでくれてありがとう。 読みながら質問がありました。 コメントでそれらに答える準備ができました。 書いて！