A → B₁ → B₂ → ・・・ → B_n.

　そして、A を、終いには、「既知のことがら」B_n に帰着する やりかた を 「解析」 と云います。

　この数学的考えかたを （事業分析のための） モデル に流用すれば、「解析」 の対象は 「情報 （文字列）」 です （現実的事象ではないことに注意されたい、その現実的事象を記述した 「情報」 が対象です）。複合命題 （複文） として記述されている 「情報」 （正確に言えば、ひとつの 「意味 （値）」 をもった単語が複数個 列べられている 「情報」──たとえば、受注入力画面とか出荷指図画面とか請求画面など──のこと） を対象にして、いくつかの要素命題 （単文）に分けていきます。たとえば、受注入力画面に記述されている 「情報」 として次の単語群を例にして考えてみましょう──

　　　　受注番号　受注日　顧客番号　顧客名称　商品 コード　商品名称　商品単価　受注数

　この 「情報」 は次のことを記述しています──「この受注は、かくかくの日に、しかじかの名称の顧客から しかじかの名称の商品を単価 かくかく円で しかじかの数量の注文があった事実を入力する」。この 「情報」 は複文です、それを次のような いくつかの単文に解体します──

　　　　（1） しかじかの受注 （受注番号） は かくかくの日に起こった。

　　　　（2） しかじかの顧客 （顧客番号） は、かくかくの名称である。

　　　　（3） しかじかの商品 （商品番号） は、かくかくの名称である。

　　　　（4） しかじかの商品 （商品番号） は、かくかくの単価である。

　　　　（5） しかじかの商品 （商品番号）[ 注文された商品 ] は、かくかくの数量である。

　それぞれの単文 （に入力される値） は、真偽を判断できる [ 命題です ]。
　ここまでが 「解析」 の手続きです。

　さて、モデル では、これらの単文を それぞれ そのまま モノ （entity） として扱う訳ではない。モデル とは、「模型・実例 [ 現実 （事実） の写像 ] 」 です──そのために、モデル のなかで扱う モノ （entity） は現実的世界と対比できる実存物 （beings） でなければならない。そのために、複文を解体した いくつかの単文を モノ （beings） として再構成 （統一） しなければならない。ここに至って厄介な問題が生じる──モノ とは何か、という定義が論点になる。

　数学は関係主義の立っていて、モノ とは 「関数」 のなかの変項として扱います。そして、或る限られた範囲 （domain） のなかで、変数として扱われる 「集合」 が問われる。モデル （現実の形式的構造）を作るうえで、絶対に破ってはいけない点は次の 2点です──

　　　　（1） ユーザ 言語を変形しない。
　　　　　　 （指示規則）

　　　　（2） できるだけ機械的に形式的構造を作る手続き （文法） が示されている。
　　　　　　 （生成規則）

　すなわち、いかなる記号 （単語） も、それに対する 「意味」 が保証されることなしに、新たな記号を導入してはいけない、かつ 既に導入された記号 （単語） を前提にして、文法的に正しい導出規則を適用して構成された記述は すべて 実際上 或る対象を指示していなければならないということです。簡単に言えば、事業のなかで実際に使われていない単語を持ち込まない、そして モデル を作成する論理規則が提示されていて、モデル のなかで扱われる モノ が事業のなかで実存する モノ である、ということ。

　ユーザ は、事業を効果的・効率的におこなうために、管理すべき対象に対して管理番号を付与しています──たとえば、先の受注入力画面の例でいえば、受注番号・顧客番号・商品番号が そうです、そして、日付 （受注日）・名称 （顧客名称、商品名称）・単価 （商品単価）・数量 （受注数） は、受注・顧客・商品のそれぞれに付帯する述語 （性質、条件） です。したがって、上述した 5つの単文は、次のように モノ として再構成 （統一） されます──

　　　　{ 受注番号、受注日、受注数 } { 顧客番号、顧客名称 } { 商品 コード、商品名称、商品単価 }

　これらが モデル 上の （そして、現実的世界の） モノ として扱われるのです。そして、「関係 （関数）」 のなかの変項として扱われる モノ なのです。数学では モノ は無定義語として扱われますが、事業分析を対象にした モデル では管理対象 （モノ） は次のように定義できます──

　　　　モノ である ＝_def 個体指定子を付与された管理対象である。