● 報告体系 （情報体系）
TM は、事業過程そのものを対象にして仕事の手続きを記述するのではなくて、（「情報 （伝票、画面など）」 を インプット にして、） 管理過程に対して 「構造」 を与える。
管理過程は、情報を報告伝達しながら、事業過程を管理する体系である。情報は、事前報告・経過報告・事後報告として伝達される。TM の 「event」 は、それらの 「情報」 を基礎にして entity を認知している。
● 仕事の手続き
「情報」 を基礎にして entity （event） を認知することは、逆に言えば、event を起点にして、仕事の 「plan、do、see」 を遡及できるということを意味している。したがって、TMD （TM Diagram） を読むときには、それぞれの 「event」 に関して、「plan、do、see」 を検証すれば良い。
たとえば、「受注」 event を対象にすれば、受注に関して、どのような事前作業──たとえば、「受注予測」 とか、「在庫照会」 とか、「在庫引当」 とか、さらに、もし、受注された商品が欠品しているときには、どのような措置をとるのか （代替品の提示とか、他の営業所へ振り替え、倉庫間移動） など──があるのか、そして、どのように進捗するのか──たとえば、記録 （計上）・承認・注残など──、そして、どのような事後作業があるのか──たとえば、出庫・出荷の確認とか、配送の確認 （たとえば、配送便、配送中の位置確認、引き渡しの確認、不良品・苦情の対応など）──を遡及して確認すれば良い。
そして、「情報」 を起点にして仕事の手続きを検証する際、その 「情報」 を 「だれが」 使っているのかを、まず、確認するのが コツ である。仕事そのものを対象にして 「いかに」 を記述しようとしたら、収拾がつかない。
「plan、do、see」 を確認すれば、たとえば、フォーマル・システム のなかには 「情報」 として記録されていないが、（フォーマル・システム を補うために、） インフォーマル・システム が作用していることを発見したり──「情報」 の利用度を検証して、もし、フォーマル な 「情報」 が使われていなければ、インフォーマル な 「情報」 が フォーマル な システム に代わって仕事を コントロール していることを想像できる──、あるいは、いままでの仕事のなかに、そういう管理機能 （事前・経過・事後の仕事の流れ） が組み込まれていないことなどを発見できる。
さらに、管理は、以下の手順 （plan、do、see） で実施される。
（1） 標準値を設定する。
（2） 許容枠 （上限・下限） を設定する。
（3） 実績値を採取する。
（4） 標準値と実績値を対比して、フィードバック する。
したがって、それぞれの仕事を確認したら、次に、それぞれの仕事に対して、「標準値・許容枠・実績値・フィードバック」 を検証すれば良い。たとえば、「引合」 の量が、生産力あるいは在庫量に対して設定されている契約可能量を超えたときには、どういう対応をしているのか──受注するのかしないのか （いちぶ受注して注残を起こすのか、それとも、全部の オーダー を accept しないのか──など。
「業務分析は、仕事そのものを対象にしてやるべきであって、『情報』 は、その仕事を検証するために使う」 という昔の考えかたは、単純すぎる。というのは、以下の諸点を考えてみれば良い。
（1） ユーザ の仕事の手続きは、いちぶ （あるいは、高い比率で） すでに、コンピュータ 化されている。
仕事の データ を入力するのだから、コンピュータ が作用するためには 仕事が、まず、存在する
という考えかたは正しいと思うが、たとえば、受注を入力して受注を検算する （整合性を検証する）
作業は自動化されているし、在庫を調べる作業も出荷を指示する作業も請求書を発行する作業も
自動化されている。たとえば、もし、受注と請求が自動化されていて、出荷指示が自動化されて
いないとしたら、受注の情報と請求の情報を観れば、当然ながら、出荷がどのようになっている
のかを システム・エンジニア は ユーザ に問うはずである。そして、もし、仕事の流れを問う
のであれば、仕事が どのように流れているかということではなくて、「品物」 が どのように流れて
いるかという点を調べるはずである。そして、「品物」 の流れは、事業過程のなかで、監査証跡として、
「情報」 の流れと一致しているはずである。
購買過程・生産過程・販売過程の流れ （正常営業循環） は、さまざまな材料を最終 プロダクト
と完成するためには、どのような仕事をしなければならないかという観点に立って仕事が構成さ
ているのであって、仕事の構成を最初に考えている訳ではない。
（2） 事業過程は、事業を効果的・効率的に進めるために、管理過程の統制下にある。
それぞれの仕事は、ほかの仕事対して効果的・効率的に相互作用 （あるいは、伝達作用） を
及ぼすように設計されなければならない。したがって、「plan、do、see」 の観点 （管理過程の
観点） に立って仕事を検証するほうが効果的・効率的である。
管理過程に対して 「構造」 を与え （TMD を作成し）、「event」 情報の入力・更新・照会を 「だれ」 が担当しているかを調べて、担当している人たちの作業日報を調査すれば事足りる。現代経営では、「plan the work, work the plan」 が常態であって、管理 （planning＆control） は仕事 （job-process） に先行する。
仕事そのものを対象にして 「仕事の流れ図」 を作成しなければ、仕事を理解できないというのは、1960年代・1970年代にやっていた業務分析法に囚われたまま──どのような仕事が自動化できるのかを検討するために、業務の流れを調べていたが （ちなみに、そういう目的を満たすためにも、作業日報は有効なのだが）──、先入観として継承されているのではないか。あるいは、モデル （modeling） に興味を示す システム・エンジニア の都合 （わがまま、または業務知識 [ 通論の知識 ] の欠如） にすぎないのではないか。参照項 （通論程度の知識） を習得していない システム・エンジニア が 「実際の」 仕事を観ても、的確な まとめなどできる訳がない。