私はすべてを知りたい：ビジネス分析。 パート2

→最初の部分はこちら

プロセス分析と説明

ビジネス分析の次のポイントは、ビジネスプロセスの説明です。 この段階では、通常、いわゆる「現状のまま」のビジネスプロセス図を作成します。 そして、彼らは言うように、誰もが問題に直面している場所です。 最大の問題は、木の後ろに森が見えないことです。 ビジネス目標を説明するときと同じように、人々は多くの場合、すべてが現在どのように機能するかを説明することに熱心です。 同時に、現在のプロセスが一般的にどれだけのものに対応しているかを把握しようとする人はほとんどいませんか？ おそらく誰もが自動化のルールの1つを知っています。「 混乱を自動化することによって、自動化された混乱が発生するだけです。」 したがって、全員を破壊する別の「スカイネット」を構築しないためには、「すべてが一般的にどのように機能するのか」を理解する必要があります。 これは非常に興味深いタスクです。



もちろん、すべてのビジネスアナリストがすぐにビジネスプロセスをスローすることはできません。すべてのケースですべてが発生するはずです。 しかし、秘密はありません。 この問題を解決するには、リスクアナリストがいる場合はそれを呼び出すか、関連する文献に少し精通して少し考える必要があります。 正直、難しくありません。



したがって、メールを使用した優れた例からそれほど遠くはなく、「最も簡単な」プロセスである「小包配達サービス」を検討します。 郵便局の料理を知っている人のために、私はすぐに、「洗練された形式」の簡単な例、ビジネスアナリスト、またはマネージャーでさえそれを見る方法について説明します。 「既存のインフラストラクチャへのリンク」スタイルやその他の「歴史的に確立された条件」のスタイルの詳細はここにはありません。 実際、これらすべての詳細は、この記事では考慮されていないビジネスアナリストの作業の第3段階で既に考慮されています。 さらに、この段階では、技術的な詳細はまったく必要ありません。さらに詳しく説明します。 As Asプロセスの説明と同様に、詳細と詳細が必要であり、重要であり、プロセスおよび後続の提案、推奨事項などの分析の一部で正確に使用されます。



したがって、目標は、顧客から受取人への価値の提供です。 この目標を達成するオプションがあります。

• 顧客は来て、彼のパックされた価値を引き渡します（そして、パッケージングは​​すでに私たちが現在無視している別のプロセスとビジネスです）。
• 会社は、受取人が受け取ることができる小包（梱包された値）の配達を提供します。
• 事前に合意した場所に到着した受取人は、荷物を受け取ります。

すでに述べたように、私たちはあなたが注意を払う必要があることと何をすべきかを示すために単純化されたプロセスを取ります。 ご覧のとおり、すべてが非常にシンプルで、少なくとも今は何かを描くことができます。 しかし、急ぐことはありません。 ことわざにあるように、「 叩いてください、そして複数回。 全世界が荒廃しています。 しかし、 ”（c）。 そのため、夢の霧からこの人間の世界に戻ってきた私たちは、私たち（会社）がどのようにニーズの充足（小包の配達）を確保し、それを提供するだけでなく、利害関係者（顧客と受取人） ）満足します。 そして最後の発言は重要です、私は言うと思います。 はい、「ビジネスの目的はお金を稼ぐことです」、「企業は顧客を気にしない」など、かなり合理的なスタイルで多くの反対があることを知っています。 しかし、繰り返しますが、ビジネスの目標はニーズを満たすことです。 そして、この職業がどれほど有益であるか、これはもう一つの商業的な問題です。



続けます。 ニーズの満足を保証する必要があります。 必要なのは、コスト、ボリュームなどを除くことです。 利害関係者がこのサービスを使用して結果に満足した場合、それは目標を首尾よく達成したことを意味します。 つまり、これらの同じ個人が不幸になる理由を理解する必要があるだけです。 いくつかのオプションがあります。予想されるイベントが発生しなかった、または想定どおりに発生しなかった。 私たちの特定のケースでは、質問を明確にするための選択肢があります：

1. 受取人は小包を受け取りませんでした
   
   
   • 受信者は、この特定の特定の小包が受信されなかったと主張します/これを確認します（どのようにこれを確認できますか？誰がどのように送信し、どのように修正しますか？）。
     
     
   • 荷物は予想どおりに配達されませんでした：
     
     
     • 納期について合意された要件はありません（他の期待があったのはなぜですか？これは何らかの形で修正されましたか？）。
       
       
     • 会社（または個々の従業員、請負業者）は仕事をすることができません。彼らは病気であり、適切な資格がなく、利用できません。 資金（誰がこれをフォローしており、いつそれが知られるようになったのですか？）
       
       
     • 会社（または個々の従業員、請負業者）は、この区画について何も知りません。 （これを確認する方法？）
2. 受信者は、受信した内容と方法に満足していません。 たとえば、添付ファイルが破損しました。 （この場合、投資が確認されたかどうか、またはこれらの「注意深い取り扱いの要件」が請負業者/従業員に知られることができるかどうかは不明です。さらに、請負業者/従業員として、投資および/または取扱いの要件を確実にすることができます、特定の顧客の期待に応えますか？）
3. 送信者はサービスを拒否しました：
   
   
   • 顧客がサービスを使用できなかった、たとえば、キュ​​ーがあった、サービスが利用可能であるという情報を受け取っていなかった-たとえば、従業員がそれを説明できなかった、または彼がそれを提供するのに十分な資格を持っていない（通話と結果が記録されている？）
     
     
   • 提案されたサービスは、たとえば価格やその他の条件で、顧客の希望を満たしていません（どうすればこれを確認できますか？）。
   
   
   

これは「リスク管理」に似ており、これらのリスクを反映し、最小限に抑える必要があります。 ご覧のとおり、実際の詳細を深く掘り下げることなく、何をすべきか、何を制御する必要があるかについての一般的な考えを既に得ています。 もちろん、これは何が起こっているのかを完全に把握したり、アドバイスを与えるのに十分ではありません。 それでも、この段階では、「現状のまま」の説明で省略される可能性のある機能が既に明らかになっているため、この情報で十分です。 そして、この情報の価値は高く、何が行われているのか、どのような方法で、どのような目的のために明確な考えを持っている人でも、現在のプロセス実装が目標と条件にどのように適切であるかを常に評価できるためです。



したがって、私たちはすでにプロセスについて何かを知っていますが、テキストの「... 20」ページを読むことなく、すべての人がこのすべてをアクセスしやすく理解できるようにする方法はありますか？ 答えはすべての人に知られています-あなたは描くだけです。 そして、いつものように、別の「驚き」が私たちを待っています。 ビジネスプロセスをグラフィカルに表示するために使用されるほとんどの方法論では、技術的な詳細を図（BPMN、UML、EPCなど）に表示することを推奨しています。 それには何の問題もありません。また、分析と推奨事項の準備段階では、現状のままの図表はまさにそのはずです。 しかし、プロセス自体、そのロジックとルールを直接説明すると、砂漠の砂のようなこれらの詳細は、すべての宝物をカバーします。 その結果、プロセス自体の正確性や誤り、またはビジネスアナリストによる理解をすぐに評価できる人はほとんどいません。



そこで、私たちは別の「自転車」を発明する問題にスムーズに取り組みました。 はい、私たちはいたずらに哲学するのではなく、ビジネスプロセスのロジックを記述するために「自作」表記法を単に適用します。 この図は、トレーニングを受けていないユーザー（マネージャー、アナリスト、開発者）向けに設計されているため、巧妙な表記法を使用すると有害になる可能性が高くなります。



このようなチャートの私のバージョンを、タジク/ペルシャ語の「Safed Chart」と呼びます。「safed」-クリア、クリーン、ホワイト。 実際、安全な図には、プロセスのロジックに関する統合された一般化された情報が含まれているため、理解が容易になります。 Excelでダイアグラム自体を「描いた」ので、魔法のツールも必要ありません。 少し説明しますが、プロセスのテキストによる説明は提供しませんが、特定の機能や詳細が示されている理由、または使用されている表記法の説明ですらあります。 この段階での私の目標は、テキストの説明を読んだり、使用する表記法にデコードしたりしなくても、ダイアグラムスキームをどれだけ理解できるかを示すことです。



そのため、「小包の配達サービスを示す」プロセスのロジックの表示は、次の図のようになります（プロセス自体を3つの部分に分割したため、検討するのに便利です）。



パート1（ 大きい ）：





パート2（ 大きい ）：





パート3（ 大きい ）：





そして追加のスキーム-プロセスの移動とデータソース（ 大 ）：





ご覧のように、図は、誰が何をどこから取得し、どこでデータを修正し、誰がその（データ）関連性とデータの記入を担当するかを明確に示しています。 今は仕事の説明をしますが。 さらに、どの職責を組み合わせることができるかは明らかです。 一言で言えば、何が起こるべきかを見てきました。



同時に、プロセス図には図自体の周りに場所があり、任意の説明と詳細を自由に追加できます（私の場合、ステップに復号化とコメントをいくつか追加しました）。 必要に応じて、コメント用の「第2層」を追加し、関係者がプロセスの個々のステップに質問、コメント、および/またはコメントを送信できるようにすることができます。



特定のプロセス図を少し注意して見ると、すぐに漏れと欠点の両方がわかります。 たとえば、

1. 輸送の段階を考慮すると、輸送部門または会社に転送された後の小包の処理を制御することはできません。 したがって、サプライヤからの配送の追加の監視を要求するか、出荷の遅延または「消失」の場合に「輸送ログ」を管理する必要があります。 良い意味で、このニュアンスは個別に説明し、プロセス図に反映する必要があります。
   
   
   
   
2. 「ピッカー」の役割/役職については、規制データのソースは示されていません。 一方では、すべての情報が「配達注文」および/または「輸送日誌」にある場合がありますが、他方では、これはビジネスアナリストが見逃した結果である場合があります。 いずれの場合も、説明が必要です。すべての結果を伴う従業員の不正行為のリスクがあるためです。
   
   
   
   
3. 同様に、前の発言のように、輸送から貨物を受け取るとき、さらに最終段階では、従業員のいずれについても規制情報源は示されません

おそらく、最後の図に存在するソース/データセットの表示の「冗長性」に関するコメントもあるでしょう。 しかし、私は理由のためにそれらをオンにしました。 IT関連のプロセスの場合、実際、プロセスとデータを制御するために、これは必要な情報です。 チャートのユーザーは、特定のデータセットに誰が、どのような情報を、どこで貢献しているかなど、詳細を確認してすばやく取得する機会を得ます。





その結果、Safedダイアグラムを見ると、マネージャーまたは別の専門家は、プロセスで必要なすべての情報をすぐに見ることができます。 さらに、現在のプロセスの欠点、その説明、またはビジネスアナリストが提供するものは、多くの場合顕著です。 一方、技術を変更しても、当社または顧客がプロセスの一部として使用することを意味する場合（内部電子文書管理システム、物理記憶媒体など）、プロセス図自体は変更されません。 そして、これは、私の観点からすると、かなり大きなプラスです。なぜなら、プロセスのロジックではなく、その実装を記述するからです。 さらに、将来、推奨事項を比較するときに、プロセスのロジックが変更されたかどうか、すべての通信、相互作用、アラート、チェックが実装されたかどうかをいつでも評価できます。



原則として、BPMN、EPC、およびUMLのフレームワーク内で同様のものを描くことができます。 ただし、これらの表記に関する推奨事項は、ロジックではなく、特定のプロセス実装の説明に焦点を当てています。 これらのSafedダイアグラムを追加として使用し、「現状のまま」および「To Be」プロセスを分析するための出発点として使用することであり、これらのダイアグラムの代替としてではないことを皆が理解してください。



上記のすべてを要約すると、私たちが抱える主な問題は手段（図の種類、要件の分類など）にあるのではなく、ビジネス分析が直面するタスクの不完全な理解にあります。 その結果、ビジネスプロセスを分析する代わりに（以前にわかったように、ビジネス目標を達成しないリスクを最小限に抑えるために必要な手順、および/またはそれを達成するためのコストを削減するため）、同僚は技術プロセスまたは従業員の職務のいずれかの分析と文書化に関与します。 まれに、これらすべてをワークフローの説明で補足します。



私にはすべてがあります。 誰かが自分に役立つものを見つけてくれることを願っています。



すべての人に幸運と成功を。









画像ソース：



1.わんわんと「郵便局での混乱」-それぞれここ から、ここ から 。

2.チャート-個人の創造性。