参照条件の作成方法。 パート2.会計システムの要件とビジネスプロセスを記述するための情報を収集するときの作業の種類

「技術的なタスクの開発」という記事の最初の部分は何ですか、なぜそれが必要なのか、どこから始めて、どのように見えるべきなのかということです。 私のニュースレターに加えて、私はそれを有名なInfostart開発者サイトで公開しました。そこで、それはさらに大きな関心を呼び起こしました。これは良いニュースです。 約束どおり、続編を書いています。



よく考えて、私は計画された第2部のすべての資料を1つの記事に収めることは二度とうまくいかないと判断しました。さもなければ、多くの教科書にすでに書かれている理論のトップ記事になるでしょう。 しかし、実際にこれを適用できるようにタスクを設定しているため、トピックを完了するために必要な問題の数について、将来の計画を立てることはできません。 これは読者からのフィードバックの影響を受けるので、書くようにしてください。



この機会を利用して、私は質問をしたいと思います。参照条件の作成に関するサンクトペテルブルクでの実践的なトレーニングセミナーを開催することはどれほど興味深いでしょうか？ 会って、経験を交換したでしょう。 そのような関心が単一ではない場合、私は組織することを約束します。



読者はソフトウェア開発の分野の専門家であるだけでなく、さまざまなレベルのビジネスアナリストやマネージャーでもあるので、私は誰にとっても興味深い方法で書くようにします。



このパートでは、要件を収集する段階の編成方法、要件の構成、使用できるツールについて説明します。 ステージの観点からのデータは、ビジネスプロセスを説明するための企業の調査に非常に似ていることを繰り返します。



人生で通常起こるように：

ほとんどのプロジェクトでどのように起こるか
手順	これはどのように起こりますか
プロジェクトが決定されます！	喜びの理由があることは明らかです。特にプロジェクトが大きい場合、それは何の問題もありません！ 主なことは、あまりにも長く喜ぶことではなく、実際の作業の開始を遅らせることです。この瞬間から時間は変わります。
リーダーとの会議を開催し、結果のビジョンに関する情報を収集しました。	通常、このプロセスは、管理者との数回の会議に限定され、次に部門長との会議に限定されます。 顧客側のいくつかの「衝動」を修正すると、それらは一般的な定式化の形で修正されます。 時には既存のドキュメントが追加されることもあります（誰かが調査、既存の規制に関するドキュメント、使用されるレポートの形式を試みたことがあります）が、驚くべきことに、その後、オートメーションシステムのほとんどの実装者は喜んで次のように叫びます。 さて、少し調整すればすべてが機能します。」 すべてがどのように機能するか（または特定のプロセスがどのように実行されるか）をエンドユーザーと議論するかどうかを尋ねられたとき、答えは通常否定的です。 マネージャーは部下のすべてを知っていることが推奨されます。 しかし、無駄に...この背後には多くのandや障害があり、仕事の配達は障害コースに沿ってマラソンに変わることがあります。 ご存知のように、平らな道路でマラソンを走るのが慣習であり、障害物で走ることは近距離でのみ可能です（走ることはできません）。
作業結果の文書化	この後、作業の目的に応じて結果の文書化が開始されます ： 参照条件を作成する必要がある場合 、コンサルタントは準備された文書テンプレートで受け取った情報をばらまき始め、見た目が美しく基本的な要件が修正されます（管理者によって表明されたもの、そうでない場合はありません）承認）。 実際には、このような参照条件は特に使用されておらず、「途中で」すべてを調べる必要があることを理解し、参照条件の主な目標を承認および承認の最小時間として設定します。 そして、可能であれば、将来の作業のコストのおおよその推定値に関する情報（ちなみに、これも重要です）。 ビジネスプロセスを説明する必要がある場合。 奇妙なことですが、多くの場合、以前のすべての手順は、参照条件の開発の場合と同様に似ています。 唯一の違いは書類です。 考えられるオプションがあります。コンサルタントがプロセスを任意の単語で説明するか、ビジネスプロセス（表記法）を説明するためのルールを使用します。 最初のケースでは、そのような文書は、参照条件に驚くほど似ています。 タイトルページを置き換えても違いは見られないことがありますが、後者の場合、強調されるのは現実ではなく、「正しい説明」、つまり 残念ながら、両方のオプションはベストプラクティスではありません。 むしろ、それらは形式的なものであり、多くの利点はありません。

なぜこのような慣行が上記のように開発されたのですか？ 率直に言って、私は知りません。 誰にも尋ねない、誰も知らない。 さらに、彼らは絶えず議論し、経験を交換し、この主題について本を書きますが、状況はそれほど速く変わりません。理由の一つは、関連する教育の質の低さであるように思えます。 また、多くの専門家が一般に他のビジネスから来て、実際にすべてを理解しているという事実によって影響を受ける可能性があります。 彼らの経験は彼らが得た環境で形成されます。 大学の態度と現実に近づきたいという欲求の欠如も知られている事実ですが、彼らの立場は時々私を驚かせます。 たとえば、優秀な専門家である大学院生が1Cプラットフォーム（優れた産業開発）で論文を書きたいと思ったケースがありましたが、学科ではトピックに関係なく、「優れた」マークを当てにすることは不可能だと言われました。 1C軽薄なシステム。 ここでのポイントは、そのような意見の深刻さと客観性ではなく、古典的なプログラミング言語の原始的なタスクがすぐに「優れた」マークの価値があると見なされたという事実です。



上記のプロセスに、より体系的なアプローチを試みてみましょう。 そのとき彼はどのように見えるのでしょうか？







ご覧のとおり、プロセスは質問で終了します。なぜなら、 これに関する作業はまだ終わりではなく、最も困難で実用的なものが開始されます-実際の結果における結果の適用可能性を決定するものです。 前の作品の運命を正確に決定するもの：クローゼット（棚またはどこか）に行くか、貴重な情報源になります。 さらに良いのは、将来のプロジェクトのモデルになる場合です。



ダイアグラムの最後のステップ（質問があるところ）まで、会社の活動に関する情報を収集する一般的な原則は、将来の予定、ビジネスプロセスの説明、自動化システムの導入に関係なく、同じように見えます。 はい、手順の順序は同じですが、一部の手順で使用されるツールは異なる場合があります。 個々の段階の方法とツールを研究する瞬間を明確に検討します。 これについては別の記事で詳しく説明しますが、ここでは最も重要なことだけを検討します。 以降のステップは異なり、プロジェクトに必要なもの（ビジネスプロセスの説明や会計システムの実装）によって決まります。



会社に関する情報を収集するアプローチを再編成する方法を見てみましょう。

より有能な組織でこれをどのように行うことができますか
手順	これはどのように起こりますか
プロジェクトが決定されます！	最初のオプションに関してはここで何も変わりません。誰も感情をキャンセルしませんでした
リーダーとの会議を開催し、結果のビジョンに関する情報を収集しました。	このステップも残っており、非常に重要です。 しかし、マネージャーとオーナーとの最初の会議（またはいくつかの会議）の主な目的は、お互いを知ることです。 まずは人や会社と知り合います。 そのような一般的な会議で述べられている目標と希望は、素晴らしいものも含めて、非常に異なる場合があります。 もちろん、それらはすべて聞かれますが、実装されるという事実は聞かれません。 会社のビジネスに深く浸ると、他の目標が現れ、以前の目標は拒否されます。 予備会議では明確な目標を策定することは不可能であり、すべてを慎重に検討する必要があります。そのような会議では、所有者や最高幹部からのすべてのメッセージの概要を説明する必要があります。 一見単純な要件であっても、実現不可能であるか、非常に面倒です。
顧客と請負業者からのワーキンググループの形成、役割の分配	顧客側と請負業者の両方からプロジェクトで作業する人を決定する必要があります。 この段階は明らかに単純ですが、非常に大きな役割を果たします。 誰が何に対して責任を負うかを明確に記録しないと、作業の実施中に混乱の危険が生じます。 自分のチームでいつでもロールを指定できる場合、顧客はこれに問題がある可能性があります。 注意すべきこと：結果の採用に少なくとも何らかの形で影響を与える将来の人々は、顧客のワーキンググループの一部であるべきです。 作業が完了したときに、目標の設定と要件の特定に関する作業に参加しなかったお客様の従業員が参加するという状況を許容する場合、問題は保証されます。 このような不条理な状況でさえ、すべてが必要とされないことが判明する可能性があります。私の実践では、そのような状況に何度も遭遇しました。 仕事の受け入れに参加するかもしれません 。 そして何よりも、これを契約条件で（契約またはプロジェクトの憲章で）規定すること。 そのようなケースがあったことを覚えています。ある大規模なプロジェクトで、創業者がプロセスに参加することを決め（理由はわかりませんが、見るのが退屈になりました）、請求顧客の問題が議論される作業会議に出席しました。 彼は、セールスマネージャーが顧客に請求することを知って驚いた。 彼のプレゼンテーションでは、会計士は請求書を発行し、それ以外は何も発行しません。 しかし、実際には、会計士は何が起こっているのかわからず、マネージャーはあなたがすべての費用で会計士に走った場合、このように働く方法を想像できませんでした。 その結果、私たちは多くの時間を失いましたが、何も変わらず、マネージャーはまだ請求していました。 そして、創始者は彼の意見のままでしたが、もうプロセスに介入しませんでした。 同じ段階で、プロジェクトの憲章を作成することをお勧めします。この憲章では 、参加者の役割、コミュニケーションの順序、規制、報告の構成、および憲章で規定されるべき他のすべてを修正します。 プロジェクトの憲章の開発もまた別の問題です。
作業方法とツールに関するプロジェクトチームのトレーニング、作業ルールの調整、ドキュメントの種類と構成	最初に、憲章に記載されているすべてのこと、実際にどのように適用されるかをプロジェクトチームに説明する必要があります。 第二に、顧客のプロジェクトチームは、その後のすべての段階で使用する予定の作業方法についてトレーニングする必要があります。 サンプルを検討するために、使用されるドキュメントの形式を議論することは理にかなっています。 モデルまたはビジネスプロセスを記述するためのルールが適用される場合、これらのルールを理解できるように議論する必要があります。
質問する	質問段階では、会社に関する情報のかなり信頼できるスライスを比較的迅速に取得できます。 このような情報の品質は、次の3つの要因によって決まります。 まず、顧客の設計チームのトレーニング方法。 彼らは、アンケートのプロセスがどのように進んでいるかを明確に理解し、すべての参加者に情報を伝えることができなければなりません。 アンケートのまさに形式。 アンケートは明確にする必要があります。 アンケートに記入するための指示があることが望ましい。 充填の例があればさらに良い。 参加者の構成。 参加者の構成を正しく選択する必要があります。 マネージャーだけに限定すると、信頼できる情報を収集することはできません。 アンケートに、将来最終結果のユーザーとなるすべての人を含めることをお勧めします。 たとえば、自動化システムの導入に関しては、ユーザーになるすべての人を含める価値があります。 1人の役職の10人の従業員のうち、残りの9人は誰も知らない特別な機能を実行する人がいる場合があります（たとえば、管理用の特別なレポートを準備します）。 職務のさらなる再分配または職務記述書の作成について話している場合は、同じことを行う必要があります。 自動化されたシステムの後続の実装のアンケート方法論または適切なケースでのビジネスプロセスの説明が異なるという事実に注意を喚起します。 もちろん、アンケートの構造は同じかもしれませんが、これは最良の選択肢ではありません。 ビジネスプロセスを説明する場合、アンケートは通常、より一般的な性質のものです。 何に直面しなければならないかは正確にはわかっていません。 特定の自動システムの実装について話している場合は、このシステムの機能を考慮したアンケートを作成することをお勧めします。 このアプローチを使用すると、企業に適さないシステムのすべてのボトルネックをすぐに特定できます。 原則として、既製のシステムを実装する方法には、このようなアンケートの可用性が含まれます。 このようなアンケートは、会計の特定の領域（注文、販売、価格設定など）または特定の役職（財務ディレクターなど）向けに作成できます。 質問の構成はほぼ同じです。
アンケート	調査は、個々のプロセスの特徴を調べるための専門家との口頭によるインタビューです。 調査は、単に「会った、話し合った」ように見えないように、より整理されたものにする必要があります。 そのためには、いわゆる調査計画を準備する必要があります。 質問のある部分、他のプロファイルの情報と矛盾する部分、または情報が表面的に提示されている部分を含めることができます。 単に個人的な経験から質問を追加することをお勧めします。 オーディオの録音に同意する場合に最適です。 同じ段階で、ドキュメントフローで提供される情報の完全性（プライマリドキュメントとさまざまなレポートの両方の形式）に従う必要があります。
主要なビジネスプロセスまたは自動化の領域を強調する	アンケートと調査の後、主要なビジネスプロセスの識別に関する結論を引き出すのに十分な情報があると合理的に考えることができます。 実際、主要なビジネスプロセスだけでなく、ほとんどすべて（参加者の構成が正しく選択されている場合）を選択することは既に可能です。 ビジネスプロセスの強調表示の問題は、完全に独立した難しいトピックです。 ここで学ぶことは難しく、主に経験によって開発されます。 選択したビジネスプロセスからリスト（分類子）を作成する必要があります。 そうすれば、どれをより深く調査すべきか、そうでないかを決定し、優先順位を付けることができます。
主要なシステム要件、目標、プロジェクトの成功基準、詳細な調査プロセスの策定	この段階までに、会社の活動に関するすべての主要情報を収集し、ビジネスプロセスのリストを収集する必要があります。 今すぐ目標に戻るために、必要に応じて目標を指定し、会社のトップ役員と話し合ってください。 目標を策定する際には、特定の指標を考慮に入れる必要があります。到達すると、プロジェクトを成功と見なします。 自動システムの実装について話している場合は、別のリストで主要ユーザーのシステム要件を強調できます。 これは個別のテーブルの形式で行います。すべての要件はサブシステムごとにグループ化されており、要件ごとに要件の作成者、文言、優先度が示されています。 この情報を使用して、システム展開計画（個々のサブシステムの実装順序）を作成したり、システムのさらなる開発の提案を行ったりすることができます（現在のプロジェクトに個別のサブシステムを導入する予定がない場合）。 ビジネスプロセスを説明する必要がある場合、より詳細に調査する必要があるプロセスについて決定が行われます。

そこで、「次は何？」という質問に答えました。 さらに、ビジネスプロセスを説明し、参照条件を個別に作成するタスクを検討します。 これらのタスクを並行して検討するのは偶然ではありません。 それらの間には本当に多くの共通点があり、それを実証したいと思います。 まず、ビジネスプロセスを記述する際のワークフローを検討します。

手順	何をどのように
ビジネスプロセスを選択する	前の段階で取得したビジネスプロセスの一般的なリストから、詳細な調査のために1つ（優先順位を付けて）選択します。 残りについては、同じことを行います。
ビジネスプロセスの詳細な調査	選択したビジネスプロセスを詳細な調査にかけます。受信したプライマリドキュメント、レポート、プログラムプロセスで使用されるそれらの構造、さまざまなファイル（Excelなど）を分析し、最終的な実行者と話し合います。 プロセスを改善する方法に関するさまざまなアイデアを収集します。 プロセスが実行される条件でプロセスを正確に観察できる場合、非常に役立ちます（多くの人は見られたくないが、何をすべきか）
ビジネスプロセスのグラフィックおよび/またはテキストによる説明（プライマリ）	取得した詳細情報の説明を開始しますが、プロセスを説明する前に、グラフィックの説明が必要かどうかを判断する必要があります。 プロセスが単純で単純な場合、その中に機能はほとんどなく、グラフィカルな表現はその理解や認識を改善しないため、時間は無駄になりません。 この場合、表形式でテキスト形式で記述すれば十分です。 プロセスが複雑で、論理条件が異なる場合は、グラフィックダイアグラムを提供する方が適切です。 チャートは常に簡単に認識されます。 プロセスをグラフィック形式で説明することにした場合、これはそのテキスト説明を提供する必要がないという意味ではありません。 つまり さらに、プロセスのテキストによる説明は、どの場合でも同じ方法で実行する必要があります。 これは、各ステップの実行者、入力で受け取る情報、各ステップの説明、出力で生成される情報を示す表形式で行うと便利です。 以下に、これがどのように見えるかの例を見てみましょう。
エグゼキュータおよびビジネスプロセスの所有者との調整	どのように情報を提示するスタイルを選択したかを理解する最善の方法は、プロセスのユーザー（パフォーマンス）に結果を示すことです。このようなデモンストレーションで最も重要なことは、プロセスの実行方法を正しく理解したことを理解することです。プロジェクトチームのトレーニングが成功した場合、期待できます。非常に適切なフィードバックの実行者から。 そして、それらが興味を引くようになったら、すべてがより速く進み始めます特定された明確化と矛盾は、説明に反映され（更新）、必要に応じて、操作を繰り返します。
ビジネスプロセスメトリックの強調表示	ビジネスプロセスの実行方法を正しく理解したら、プロセスの品質や速度を測定できる指標について考える必要があります。 簡単ではありませんが、必要です。 指標は測定可能でなければなりません。 数値で表現され、この値を取得する簡単な方法があるはずです。 測定されたインジケータを分離することが不可能な場合、ビジネスプロセスが正常に割り当てられないリスクがあります。 さらに、プロセスの変更がその改善につながるかどうかを理解することはできません（結局、測定することは不可能です）。
ビジネスプロセスの最終文書	プロセスの実行方法（または実行する必要がある方法）が正しく理解されたと確信した後、ドキュメントに含めることができます。
プロジェクトの目的に応じて、さらなるアクション（またはその欠如）	さらにオプションが考えられます。検討中のプロセスの分析と最適化、職務記述書の作成、個々のプロセスの自動化の必要性などに関する決定が行われます。これは、別のプロジェクトであるビジネスプロセスの説明でもあります。

ここで、情報システムの要件を調査するアプローチが、参照条件にさらに反映されてどのようになるかを検討します。

手順	何をどのように
ビジネス要件/自動化エリアを選択してください	要件として自動化の領域全体（たとえば、「在庫」）を選択することが実際に使用されますが、これは要件を詳述する最も効果的な方法ではありません。 自動化の分野は要件のグループであり、それらを個別に考慮することをお勧めします。 たとえば、「倉庫での材料の受領の会計処理」
ビジネス要件の詳細な調査	ビジネス要件の詳細な調査は、エンドユーザーがそれをどのように見たいと思うか、それを使用する方法として理解されます（もちろん、プロジェクトの目的に従って）。 ソフトウェア開発技術では、これはしばしば「ユースケース」と呼ばれます。 したがって、ビジネス要件の詳細な調査は、ユースケースの調査に限定されます。 このオプションの例は、記事の付録2に記載されています。 最も単純な場合、ユースケースはグラフィックダイアグラムの形式で描画する必要はなく、テキストの言葉遣いに制限することができます。 たとえば、「アイテムを入力するとき、購入価格+ 20％として価格を計算する必要がある」という要件は、描画する意味がありません。 付録2の例に示すように、自動化の分野に組み合わされた要件を図の形式で提示することは理にかなっています。
情報システムのモデリング要件	ここにある！ おそらく覚えていると思いますが、私はすでに、参照規約の開発方法論におけるこの最も重要な要素に注意を喚起しました。 「モデルを構築し、結果を取得してください！」そして、何をモデル化する必要がありますか？ 前の手順で取得したユースケースをシミュレートする必要があります。 シミュレーションの出力はどうなりますか？ ユーザーデータが入力されるデモプログラムを入手する必要があります。業界固有の現在の問題を考慮して、それを聞くことが望ましいです（ユーザー）。 入力しただけでなく、このデータがどこから来たのか、どのように計算されたのかを明確にする必要があります。 この時点で、読者には質問があります。 しかし、新しいシステムの開発が計画されていて、シミュレートするものがまったくない場合はどうでしょうか？ デモンストレーションに機能がなく、システムをさらに開発する必要がある場合はどうなりますか？ もちろん、このような状況に直面する必要があり、これは正常です。 どうする システムが完全に新しい場合（「ゼロから」と言う場合）、ほとんどの部分を紙でシミュレートする必要があります。ここでは、ユースケースの図が非常に役立ちます。 一部には、開発されるはずのいくつかの画面フォームの概要を説明するのが理にかなっています（開発が行われる環境で）。 一部のエディターでそれらを描画するのに時間がかかり、この作業は退屈です。 既製のシステムが導入され、その中に十分な機能がない場合、心配することはありません。データは手動で入力され、ユーザーは必要な改善後、これを計算する必要があることを知らされます（そして彼はそれを見る）。 ユーザーが空き時間に独立してモデルを操作できるように、このようなモデルには短い場合でもテキストの説明を添付することをお勧めします。 同じ説明で、改善のための要件を策定できます。
ワーキンググループへの情報モデルのデモンストレーション	得られたモデルを顧客に見せ、すべてがどのように機能するかを伝えます。サブシステムに従ってモデルをデモンストレーションすることをお勧めします。 要件のグループごと。 提案されたスキームがクライアントに対して機能しないことが判明した場合、他のユースケースについて考え、モデルに変更を加えて再度表示する必要があります。 このクライアントの計画されたモデルが「生きる」という確信がある場合にのみ、モデルを成功と見なすことができます。
テスト開発	なぜテストが必要なのですか？ 要件をどのように実装できたかを確認する必要があります。 したがって、すべての重要な領域、複雑なアルゴリズムなどのテストを行うことが望ましいです。 これらのテストを含めることは、作業を提出するときに使用できます。 システムのすべての機能に対してテストを行う必要はありません。常識があるところならどこでも。 既製のシステムについて話している場合、「顧客ディレクトリに新しい要素を入力する」ためのテストを行うことは、愚かで無駄な時間とエネルギーの無駄のように見えます。 しかし、これが完全に新しいシステムである場合、これは非常に可能です。 まだシステムがない場合にテストを行うのはなぜですか？まず、開発者は自分が何を達成したいのかを理解します。 第二に、テスターの生活を楽にします（結局、誰かが開発結果をテストします）。 一般に、テストは別の分野であり、多くの方法ではそれほど単純ではありません。 実際には、原則として、最も単純なテスト方法が引き続き使用されます。
参照条件の形式での要件の文書化	前の段階で収集された情報は、要件セクションの「技術的割り当て」文書の基礎に含まれるべきものであるため、これらすべてを正しくフォーマットする必要があります。
プロジェクトの目的に応じて、さらなるアクション（またはその欠如）	開発プロセスは、プロジェクトのパートナーの検索、入札など、より長く開始できますが、すべて状況に依存します。

はい、参照条件の開発は労働集約的なプロセスであるため、コストがかかります。 しかし、それが正しく行われれば、満たされていない期待から顧客を救います。 請負業者は、顧客が要求することを実行する必要があり、同じことを100回やり直す必要はありません。 とにかく、プロジェクト全体に透明性を与えます。

付録1. EPC表記で説明されているビジネスプロセス。

2. « »