ワークフローサンプル: 2015

2016年版の「基本業務パック」を考える。

今回はシリーズ第２弾、シンプルな「物品購入依頼」を紹介する。

この調達フローは、「買うべき／買ってほしい」と思ったモノを、気楽に申請できるワークフローだ。
つまり「コピー用紙」「飲料水」「洗剤」といった消耗品から、「机」「掃除機」「パソコン」といった備品まで、、、社員であれば何でも申請できる。ただし、実際に購入されるか否かについては調達部門に委ねられる。特に、必要性や緊急性が判断しづらいものについては、「購入判断保留中」のステータスが長く続くことになる。

なお「10万円を超える申請」については、「事前に『稟議フロー』にて決裁承認されていること」が購買条件となる。

[物品購入依頼]

続きを読む »

2016年版の「基本業務パック」を考える。

今回はシリーズ第１弾、シンプルな「稟議フロー」を紹介する。

何ということはない、基本的には、

社員が稟議書を「申請」し、
申請者の上司が「承認」する。

それだけの業務フローだ。

この業務フローは、オンラインのワークフロー・システムに「慣れる」には、ちょうど良いテンプレートだ。入力フォームにある「注記」（入力ヒント）をアレンジする程度で十分だ。それでいて長く使える可能性も高い。。

紙の稟議書を止めようと考えている方、
MS-Excel や Google Spreadsheet での稟議書管理に限界を感じている方

は、無料のワークフロー基盤『Questetra BPM Suite』にインポートし、まずは小規模チーム内で試運転してみてほしい。

[稟議フロー]

続きを読む »

前回は『法人番号システム』（Web-API 機能）との連携事例を公開した。

◇2015-12-07: 顧客マスタを「法人番号システム Web-API」でクリーニング

この業務プロセスは、「取引先の商号が変更されていないか」を、毎週自動チェックする仕組みだ。日曜日の朝6時に自動的に開始される。人間は、「顧客マスター」（XML）に修正すべき点が発生したことを、自然と検知できる。

ただ「全ての取引先が法人番号を持っている」と言う前提に立っている。つまり、全ての取引先について、1件1件「Web-API 機能」に問い合わせているのだ。現実には『法人番号』を持たない取引先（個人事業主や海外企業など）も存在する。

以下の業務プロセス定義では、「顧客マスター」にダミー番号「9999999999999」（13桁の9）の存在を許容する。

すなわち、海外顧客など法人番号を持たない取引先は「13桁の9」を登録するというルールだ。また『Web-API 機能』へのリクエストも、10件ずつ行う仕組みになっている。

[取引先マスタ登録商号の自動チェック２]

続きを読む »

『会社名（商号）が変わります』
『グループ再編で取引会社が変わります』

取引先から「社名変更の通知ハガキ」が届くことは多い。しかし、この手のハガキだけを頼りに「取引先マスタ」のメンテナンスを行う、、、と言うのは、実に心もとない。

2015年12月1日、日本政府は『法人番号システム』の『Web-API 機能』を稼働させた。

もし、アプリケーション側が「取引先の法人番号」(13桁数字)を把握していれば、取引先の商号や所在地等の登記情報をいつでも参照できる。加えて「商号変更」「吸収合併」「会社解散」などの変化情報（処理区分）についても検知できるようになったのだ。

以下のワークフロー定義は、この『Web-API 機能』を活用し「商号変更」を自動検知する仕組みだ。

ここでは、ワークフロー基盤に「取引先マスタ」（Business-Connection.xml）が存在していることを前提にしている。つまり、「取引先マスタ」に登録されている商号が登記情報と同一であるかを確認している。毎週日曜日の朝に自動実行される設定だ。

[取引先マスタ登録商号の自動チェック]

続きを読む »

日本人は「生命保険」がスキだ。

人口１億人程度にもかかわらず、毎年40～50兆円のお金が保険金として収められる。１人当たり年間40万円も支払う計算だ。（ちなみに、パチンコにも25兆円ほど…）

専業主婦が多く（共働きが少なく）サラリーマン死亡時の家族リスクが大きい
保険会社も、企業の大株主やビルの建設といった社会貢献している
そもそも、国民性として貯蓄志向が強い

理由は色々とあるだろうが、

所得税と個人住民税が減額される（年間24万円まで）

という税制優遇制度の存在によるところも大きい。

つまり日本では「多くの国民が保険に入るべき」という思想(?)のもとに、

「保険の加入にはキャッシュバック特典付けるよ。
年間24万円分までだけど、最大で約3.2万円(※)も戻ってくるよ!!」

という制度になっているのだ。（※ 所得税率20％・個人住民税10％の人の場合）

『最大12万円控除×税率』の所得税還付
『最大8.4万円控除×税率』の住民税減額

事実「控除の上限額」にあわせて、保険に加入するケースは少なくない。

ただ、この特典を受けるためには毎年末の申請が必要だ。2枚提出する年末調整書類のうち「保険料控除」と書かれた方だ。

A. 「平成27年度分給与所得者の保険料控除申請書兼給与所得者の配偶者特別控除申請書」
B. 「平成28年度分給与所得者の扶養控除等（異動）申告書」

以下のワークフローは、この「申請書 PDF」が自動的に生成される仕組みとなっている。一度頑張れば、来年以降はデータコピー（再利用開始）によって非常にラクになる。

[年末調整：保険料控除の申請]

続きを読む »

A. 「平成27年度分給与所得者の保険料控除申請書兼給与所得者の配偶者特別控除申請書」
B. 「平成28年度分給与所得者の扶養控除等（異動）申告書」

日本企業における「年末の風物詩」、、、いわゆる『年末調整』というヤツだ。「天引きされた額」と「支払うべき所得税」の差分を精算してもらうことを目的に、「家族等の扶養状況」や「保険の加入状況」などを申請するのだ。日本全国5000万人の給与所得者が、紙の書類に記入し、押印をした上で、会社に提出する。

ちなみに、日本では、所得税や地方税を徴税する業務は、企業が肩代わりするルールだ。（所得税法＞源泉徴収）

つまるところ、これらの書類が税務署や国税庁に郵送されるようなことはない。企業にしてみれば「正しい情報」が集まりさえすれば良く「紙での提出」というルール自体はどうでも良いのだが、法令に従って7年間の保管義務に従っている。もちろん「紙・プリンタ・転記の手間・郵送の手間…、あらゆる資源を無駄遣いしている」と感じている企業は少なくない。。。（ブツブツ）（ぶっちゃけシャチハタであろうが、芋版であろうが、ナンデも良い）

さて、、、これらの書類のうち B 書類のフォーマットが今年から変わる。

一見すればわかるように「マイナンバー」が追加されるのだ。賢明な読者諸氏ならお気づきの事とは思うが、、、この紙が『個人情報』から『特定個人情報』に格上げされてしまうのだ。。。（よし、頑丈な棚を買うか？？）

[年末調整：扶養控除の申請]

続きを読む »

「内部工数が見えない…」

企業活動において「作業コストの可視化」は重要なテーマだ。しかも、今日に至っては、情報処理技術・通信技術の進化によって多種多様な表現手法が可能なハズだ。

移動経路が分かる「GPS ロガー」（移動マップ）
熱分布が分かる「サーモグラフィー」（赤外線熱画像）
予算履歴を把握できる「EVM グラフ」（完成度推移グラフ）

※ GPS: Global Positioning System, EVM: Earned Value Management

そもそも『可視化』とは「直視するだけでは認識しづらい情報」を、画像やグラフなどによって認識しやすくする取り組みだ。企業活動（業務プロセス）の可視化に限っても、すでに様々な図表が活躍している。

作業工程の順序が分かる「BPMN フロー図」
各工程での滞留状況が分かる「ヒートマップ」
個人やチームでの「マイタスク処理数の推移グラフ」
フロー全体や一部工程における「BAM 平均所要時間の推移グラフ」

※ BPMN: Business Process Model and Notation, BAM: Business Activity Monitoring

「うーむ、何とかして可視化したい…」。

ただ一方で、、、「内部工数」をテーマにする場合には、それらの要素データとなる「実稼働時間」の情報をどのように収集するかが、大きな課題と言える。

[汎用的な作業依頼フロー]

続きを読む »

「『ワークフロー』を体験してみたいけど、どの業務で試せば良いのか分からない」

特に「一人で試す」のではなく「組織として試したい」場合は、悩ましい。たとえば仮に「日報業務」をワークフロー化＆ペーパレス化するにしても、その体験期間において、従来のやり方とクラウドなやり方の両方を行わなければならないなんて、、、試用者が可哀そうだ。

以下は、ワークフロー製品試用の際に設定されることが多い「汎用的な業務依頼フロー」だ。

「ワークフロー化＆ペーパレス化」されていない業務で利用することができる。つまり、このテンプレートをワークフローとして稼働させれば、社内のメンバに対して、様々な依頼を投げる体験が可能だ。そして、依頼を受けた側もワークフロー製品内に「マイタスク」が溜まっていくのを体験することができる。

「新製品用のアイコンを作成して下さい」
「作成した資料のレビューをお願いします」
「前回広告のデータ抽出をお願いできますか？」

なお、この「汎用作業依頼」はアチコチで紹介されるワークフローだが、ここで紹介されている「業務依頼フロー」が秀逸な点は、依頼を申請する画面において「時間コスト」が掲示されているところだ。
（上手く表現できないが）、良い意味で「頼みづらく」なる。（軽々しく依頼できなくなる）。言い換えれば、キチンと依頼するようになる。

＜時間コスト（目安）＞

オフィサー： 10,000 円/時
マネージャー： 7,500 円/時
常勤スタッフ： 5,000 円/時
パートスタッフ： 2,500 円/時

[汎用的な作業依頼フロー]

続きを読む »

業務で『住所データ』を入力する機会は少なくない。

代金請求プロセスにおいて「請求書の郵送先を入力する工程」
アンケート集計プロセスにおいて「回答データを入力する工程」
エレベータ保守プロセスにおいて「点検した地点を入力する工程」

などなど、、、様々な部門が、様々な日常業務の中で『住所データ』を入力している。

以下のワークフロー定義は、「回収した名刺／アンケート紙」をデータ化する業務プロセスだ。展示会やイベントの終了後などに、大量に獲得された名刺やアンケート紙が、順次データ化される。

この入力画面には「住所の部分入力」によって住所候補が自動的に列挙される仕組みが実装されている。

非常に秀逸な点は、その絞り込み検索において『大口事業所を含む郵便番号データ』（約15万件）が参照されている点だ。つまり、役所の名前や大企業の名称の一部を入力するだけで、その「郵便番号」「住所」「法人名」の全項目を補完入力できる。

※ 日本郵便株式会社は、配達物数の多い大口事業所に対して、専用の郵便番号（個別番号）を割り当てている。

ちなみに「大津市役所」と入力すれば

「大津市役所」に並んで
「泉大津市役所」

も補完候補として表示される。

[個人情報のデータ化フロー]

続きを読む »

『Web-API』というテクノロジーが注目されてから、もう10年以上たつ。

Web-API とは、平たく言えば「データリクエストに応える Web サーバ」のことだ。 ※ Application Programming Interface

もし「気象情報」「為替情報」「株価情報」「郵便番号」「電力使用率」など、、、日々刻々と変化する最新の情報が、いつでも・誰でも・できれば無料で、参照/収集できる環境が整えば、、、世界中の情報システムはもっともっと進化するだろう。Web-API は『データ・インフラの基盤技術』と言っても良い。

そして『データ・インフラ』の整備は、人類社会の発展のカギでもある。（ヒトや車が利用する『交通インフラ』（道路）とも近い話）

しかし、、
目下のところ、、、
無料で使える「有用な Web-API」は皆無に等しい。

そもそも「情報を提供し続ける側のメリット」が、ほとんど無いのだ。（「広告」を載せられるでもなく。。。）それでいて、世界中のコンピュータからの膨大なリクエスト（＋攻撃）に対して、耐え忍ばなければならない。。。（もっとも「だからこそ新ビジネスの種」であることは間違いないノダガ。。。）

2015年12月。
そんな状況下、日本政府（国税庁）は「法人番号」（マイナンバー法）の情報参照サービスを開始する。正式名称は『法人番号システム Web-API 機能』だ。大きく２つの機能を持つ。是非とも、（是が非でも）、頑張ってもらいたい。。。（※詳細は国税庁のホームページへ）

A 「13桁番号」から法人情報を取得する
B 「期間」を指定して更新された法人情報を取得する

以下のワークフロー定義は、フローの途中で『法人番号システム Web-API 機能』が呼び出される仕組みだ。

[法人番号システム Web-API 機能の呼び出し]

続きを読む »

「たしかに営業日報は『地味な報告作業』だ。しかし同時に『非常に重要な活動記録』でもある。」（取引先マスターを参照する営業日報）

という投稿に対して、「記録としての価値を高めるためにも『GPS 情報』も記録したい」という話を頂いた。

なるほど。たとえば、客先往訪した直後にスマホで日報を書くスタイルなら、そのスマホが保持している「緯度経度情報」（GPS 情報）を使うべきだ。その『GPS 情報』は現場サポートの記録として、非常に有用な情報になるだろう。（GPS: Global Positioning System ／全地球測位システム）

今日『GPS 情報』は、非常に使いやすくなった。つまり、多くのブラウザが「GPS 情報を取得する機能」を持つようになり、スマホに限らず、パソコンですら、想像以上に正確な位置情報を取得できる。事実、この機能（「ジオロケーション機能」という）は、新しい表示フォーマット「HTML5」（by W3C）の中で、最も人気がある機能だ。

以下は、以前投稿した「営業日報プロセス」が改良されたものだ。

変更点は、入力項目『活動詳細』（textarea）の下の［入力のヒント］部に、２つのボタンが追加されただけだ。しかし、これが非常に使いやすい。

「Googleマップ URL を表示するボタン」
「表示 URL をテキストエリアに貼り付けるボタン」

[営業日報プロセス]

続きを読む »

「お客様の声に、誠実にお応えします」。。。

言うのは簡単だが、実践するのはナカナカ難しい。実際「全てのお客様の声に即応する」のが不可能な時だってある。たとえば「人手リソース」を動的にスケールさせる（変化させる）仕組みにも限界がある。いや、待て。そもそも「単純に人手を増やす」という方針は、それは「コスト増」につながる話だ。延いては、お客様の為にならない。

う～む、「誠実にお応えする」とは何か？

大きなヒントは『ISO 10002』だ。すなわち「苦情対応プロセスについて PDCA サイクルによる継続的な改善を行うこと」に主眼を置くのだ。（組織としての成熟度を高めると言っても良い）

具体的に言えば、顧客からの意見要望を受け付けてから、顧客への応対が終了するまでの進捗を捕捉記録する。そして、「苦情対応プロセスの流れ」や「業務マニュアル」を改善し続ける。（まさに Business Process Management (BPM) 活動そのもの）

ISO 10002: Quality management (Customer satisfaction):
Guidelines for complaints handling in organizations (2004)
JIS Q 10002: 品質マネジメント (顧客満足):
組織における苦情対応のための指針 (2005)

以下のワークフロー定義は、非常にシンプルな「苦情対応プロセス」だ。
※ 「クレーム対応プロセス」あるいは「問合対応プロセス」と呼んでも良い。

まずは１週間なり１か月なり、このシンプルなワークフローで実際の「お客様の声」を回す。そして、蓄積された処理記録と実体験とを踏まえ、一回目のプロセス改編を行う。更にその後、その改善サイクルを繰り返す。

なお、このワークフロー定義、、、「顧客マスター」を参照できる点が秀逸だ。「顧客マスター」を用意すれば、「ユラギのない顧客名」が簡単に入力できるようになる。

[問合対応プロセス]

続きを読む »

たしかに営業日報は『地味な報告作業』だ。しかし同時に『非常に重要な活動記録』でもある。

もし「販売が好調だった月」を振り返ろうと考えた時、
もし「不調に終わった月」を反省しようと考えた時、

その月の活動記録がなければ分析のしようが無い。たとえば、セールス部門全体として、どのような顧客グループに、何をプッシュしたのか？、、、各メンバーにヒアリングしたとしても、「まともな分析資料」が出来上がるには相当な時間を要してしまうだろう。

言い換えれば、日々の営業日報は「次のセールス戦略」を考えるための重要な基礎資料なのだ。

とは言っても「顧客の属性」や「顧客社名」あるいは「活動内容」の入力にユラギがあるようでは、それはそれで意味がない。また一方、入力の手間がかかってしまうなら、それも本末転倒だ。（ホント悩ましい）

以下は『面談記録』と『上司コメント』で構成される「極めてシンプルなビジネスプロセス」だ。

ただ、何より秀逸な点は、その入力支援の仕組みと言える。つまり、「顧客の属性」や「顧客社名」にはワークフロー基盤で統一管理している『顧客マスター』を参照できるようになっている。また「セールス活動内容」には『基本活動・重点提案活動』の一覧が参照できるようになっている。

[営業日報フロー]

続きを読む »

最近の『ワークフローシステム』は、見積現場のニーズにも上手に応えている。

A. 「本社にいる上司」の "承認" が必要
B. 「顧客」に提出するための "紙" も必要

つまり単に「スマホ対応」しているだけでなく、いわゆる「帳票出力機能」を持つワークフローも多くなっているのだ。しかし、そんなワークフローシステムであっても、

X. 「セールスマン別」の集計もしたい
Y. 「顧客別」の集計をしたい

となれば更なる工夫が必要となるだろう。つまり、、、たとえば、顧客名の入力で「ゆらぎ」が多発してしまう様な現場であれば、スムーズな集計は望めなくなる。すなわち、次の３つの視点を事前考察しておかなければならないと言える。

o. 「見積書」の Group 管理
x. 「セールスマン」の ID 管理および Group 管理
y. 「顧客」の ID 管理および Group 管理

以下のワークフローは、顧客名の入力に「取引先マスター連動フォーム」を利用する。（検索コンボボックス）

[見積書作成業務]

続きを読む »

仕入元の「名称」（商号）が変わる。良くある話だ。

得意先の「優先度」を変える。これも良くある話だ。

以下は「取引先マスター」を一括してメンテナンスする業務フローだ。営業事務チームによって、定例の「月次見直し」と、随時任意の「臨時見直し」が行われる。

この特別なワークフローで「取引先マスター」を更新すると、ワークフロー基盤上の多くワークフローで表示される『顧客の一覧』（選択肢プルダウン・コンボボックスのリストなど）を一斉に切り替えることができる。言い換えれば、「見積書承認フロー」「請求プロセス」「修理依頼対応プロセス」など、それぞれの業務プロセスを設計運用している各プロセスオーナーは、『顧客の一覧』のデータについて、メンテナンスする必要がない。

※ 取引先マスターへの「個別追加」については前回記事を参考されたい

[取引先マスターのメンテナンス業務]

続きを読む »

ワークフロー基盤が『顧客マスター』を持っていれば、色々と都合が良い。

もし「自由なテキストフォーム」で入力させていると、

「NTT」だったり、「日本電信電話株式会社」だったり
「NTT西日本」だったり、「西日本電信電話株式会社」だったり
「NTTデータ」だったり、「エヌ・ティ・ティ・データ」だったり
「NTTドコモ」は、「NTTドコモ」のままで良かったのに…

そして「株式会社」が、前株だったり後株だったり、、、（そもそも）、あったりなかったり。。。ナンにせよ法人名の入力が発散して仕方ない。。。俗に『名寄せ』ど呼ばれる作業は「非常に不毛な作業」と言わざるをえない。

以下のワークフローは「取引口座開設業務」だ。

一見すると前回記事（与信管理フロー）とほぼ同じフローだが、、、新しく取引先を登録する際に『顧客マスター』（Business-Connections.xml）が自動的に更新される仕組みとなっている。

この『顧客マスター』は、他の業務フローから、「プルダウンメニュー選択」や「テキスト入力中にリストが絞られるコンボボックス」として呼び出せる。つまり「見積書承認フロー」「請求プロセス」「問合対応プロセス」において、入力される法人名は、必ず『顧客マスター』から選択され、常に「正式な社名」が入力されるようになるのだ。

[取引口座開設業務]

続きを読む »

「商品と現金は同時に交換される」、、、とは限らない。むしろ企業間取引においては「同時に交換されない」の方が一般的だ。つまるところ、企業間取引においては、、、

どちらかが相手方を『信用』する必要がある。

商品と請求書を渡し、翌月末までに送金してもらう（売掛金）
現金を振り込み、後日商品を配送してもらう（前払金）

そこで多くの企業は、全ての取引相手に対して『信用限度額』を設定する。初めて設定する際の手続きを特に「取引口座開設の手続き」と言う場合もある。（ちなみに、どちらが『信用』を与える側（与信者）になるかは、「商品が先」か「現金が先」かによって決まる。ドラマや映画で目にする「身代金の受け渡しシーン」と同じ構造だ。）

以下のワークフローは、非常にシンプルな「与信管理」の業務フローだ。特定の取引先に対して『信用限度額』を設定する。具体的には、「相手方から直接もらった財務書類」や「信用調査会社からの情報」、あるいは「これまでの取引実績」や「事業戦略上の優先度」などの情報から上司が判断し、最終的には CFO が決裁する。（そして日々の「売掛金」は、そこで設定された限度額の中で総額コントロールされる）

このワークフロー定義の注目すべきは、2015年10月に日本政府が運用を始める「法人番号」(マイナンバー法)を活用している点だ。「名寄せの失敗」（限度額の多重設定）を防ぐことができる。

[与信管理フロー]

続きを読む »

いよいよ、後１か月。。。

日本でも個人番号制度「マイナンバー制度」が始まる（2015年10月5日）。当ブログでも『個人番号の収集プロセス』について、いくつかのワークフロー（業務プロセス）を例示してきた。

そして、次週以降は「法人番号」の利活用についても、その事例を紹介していく予定となっている。法人番号システム『Web-API 機能』の活用事例についても、「事前検証環境」にて動作確認でき次第、順次公開していく予定だ。

今回は「マイナンバー」を取り扱う業務でかかせない「誤り検出」についてまとめておく。
以下のワークフロー定義は、入力データの「正確性チェック」を体験できるサンプルだ。[1] 入力中データが自動的にチェックされる仕組み(入力画面での JavaScript)と、[2] サーバ側にてデータチェックされる仕組み(スクリプト工程での JavaScript)の両方が設定されている。

なお、チェックディジットとは「検査用文字」という意味だ。『クレジットカード番号』や『商品コード』(EAN/JANバーコード)や『国際標準図書番号』(ISBN)などでも幅広く活用されている。日本の『マイナンバー』の場合は、

法人番号（13桁数字）: 左端の数字
個人番号（12桁数字）: 右端の数字

が「一定の計算式」によって算出され、付加されている。

[Check Digit サンプル：「TEST Form」画面]

続きを読む »

前回は日本における「民事訴訟」について、そのプロセス図（BPMN図）を紹介した。（BPMN: Business Process Model and Notation）

以下は日本における「刑事訴訟」の裁判プロセスを表している。

このプロセス図は、刑事裁判における「三審制」や「簡易裁判所の位置づけ」の概要理解に役立つ。また「民事訴訟」の裁判プロセスと比較することで「民事訴訟と刑事訴訟の違い」についても理解できる。

例えば、民事裁判では「簡易裁判所が第一審」の場合の控訴審が「地方裁判所」になっているのに対して、刑事裁判では「高等裁判所」にてその控訴審が開かれることは、意外と認識されていない。あるいは、民事裁判では「原告」による「訴状の提出」が裁判のきっかけ（トリガー）になっているのに対して、刑事裁判では「検察官」による「起訴状の提出」が裁判のきっかけとなっている点も、フロー図で認識することで理解が進む。

法律文にせよ、社内規定にせよ、その「ルール」を理解するうえで「プロセス図」は欠かせない。

＜参照＞

※ いま日本で導入検討されている「司法取引」は、起訴状を提出するこの「検察官」が主人公だ。はたして犯罪組織の「黒幕」を供述させることができる制度になるか、注目されている。

[刑事裁判フロー]

続きを読む »

およそ「ルール」と呼ばれるモノは「文字」で記述されている。

法律
行政手続
社内規程
学校の校則

そして、その中には「手続きの流れ」についても記述されている。

言うまでもないが、もし『プロセス図』があれば「ルール全体を理解させる／する際のコスト」を大きく下げることができるだろう。前回紹介したプロセス図「法律案の審議プロセス」も、日本の立法ルールを理解するには非常に有用だ。 (BPMN: Business Process Model and Notation)

以下に紹介するプロセス図は「民事訴訟の裁判プロセス」だ。

日本における「司法ルール」が描かれており、「三審制」や「簡易裁判所の位置づけ」を理解するに有効な図と言える。例えば Web サイト「裁判手続きのご案内」にこの図を貼り付ければ、サイト訪問者の理解に資することは間違いない。
※ http://www.courts.go.jp/saiban/syurui_minzi/index.html

ちなみに、以下の業務プロセス図が、「民事訴訟」のうち「通常訴訟」（個人の間の法的な紛争）に限定して記述されている点に注意されたい。（刑事訴訟・行政訴訟・特許訴訟・家事事件・少年事件などは含まれない）

[民事裁判フロー]

続きを読む »

「なるほど、日本では『衆議院』と『参議院』の両方で審議されて法律ができあがるのね」

もし、この基本的な仕組み（だけ）を理解させたい場合であれば、前回紹介した業務プロセス図（業務フロー図）は少し情報量が多すぎる。見やすい／理解しやすいとは言えない。つまり、可能性がある様々なフローを詳細に記述しているが故に見づらいのだ。

確かに、これでも「現実的に選択されうる経路」に絞って記述されているのだが、、、（例えば）注目されるべき「60日ルールの流れ」（参議院審議が長期化した際の、衆議院による再可決成立）が理解しやすいとは言い難い。もし「公民科の教科書」や「新聞の記事」で利用するなら、更なる「簡素化」を検討したいところだ。

以下の業務プロセス図は、前回の業務プロセス図を簡素化したモノだ。
業務手続きの「骨格」を説明するためのフロー図と言っても良い。「現実に発生しうる手順」が一部省略されてはいるが、仕組みを理解したり、審議ステータスを確認したりする上においては不都合ない。（後議院が「修正可決」した場合など）

[法律案の国会審査２]

続きを読む »

「法律案の成立プロセスが分かりにくい」

日本の法律は日本の国会で作られている、、、そこまでは誰でも知っているのだが、「どのように作られているか？」（ルール・手順）となれば、ナカナカに説明しづらい。

そもそも国会の『業務』には、「法律案の審査」以外にも、、、「予算」や「内閣総理大臣の指名」、あるいは「条約の締結に必要な国会の承認」をはじめとする承諾や承認、「内閣不信任決議案」をはじめとする決議など、様々な業務がある。もちろんそれらの業務プロセスはそれぞれ似ているのだが、違うところも少なくない。たとえば、最近毎日のようにメディアが伝える「60日ルールで再可決」といった手順は、「予算」を決める業務においては存在しない。

以下は、国会における「法律案を審査するプロセス」だ。「みなし否決」（60日ルール）の位置づけも良く分かる。

ちなみに、ココでいう「プロセス」に、議院運営委員たちの「根回しプロセス」は含まれない。（そんなモノは複雑すぎて書ききれない…）

[法律案の国会審査]

続きを読む »

「リーマンショック」を彷彿とさせる。すでに「東芝ショック」と言っても良い。

東芝と言えば、なんといっても『サザエさん』だ。小学生以上の日本人であれば一人として知らない人は居ない国民的アニメだ。日本の子供たちは、あの家族をみて育つ。。。東芝は、もう45年以上も『サザエさん』のメインスポンサーをしている。（そして、東芝日曜劇場『Beautiful Life - ふたりでいた日々』は人類史上最高の恋愛ドラマだ）

そんな東芝に、大規模な不正会計処理が発覚したのだ。

過日(7月21日)の記者会見を見て、組織的かつ悪質な粉飾決算と感じた人は少なくない。委員会設置会社（指名委員会等設置会社）という組織機構において「監査委員会」は何を監査してきたのか、「会計監査人」（監査法人）は何を監査してきたのか、、、世界中の投資家から疑問に思われても仕方がない。「カネボウ」や「オリンパス」の教訓は何も生かされていない。この際、グループ全体を解体し、140年の歴史に幕を下ろすべきだ。日本の家電分野や重工業分野の再編にも促進されるだろう。

「循環取引」や「集計の不正」を防ぐには、業務データを可視化することに尽きる。

業務プロセスが見えないが故に、、、そこに流れる業務データが見えないが故に、、、不正が生じるのだ。例えば部長職以上には、事業部内のリアルタイムの業務データを閲覧できる権限をあたえるべきだ。例えば執行役や取締役には、全社の業務データをリアルタイムに閲覧できる権限をあたえるべきだ。「いつ誰が何をしたのか」が自動的に記録される仕組みにあって、わざわざ「取締役会の資料」を改ざんしようとは思うまい。

[見積/受注/請求等の部内基本フロー]

続きを読む »

登録: 投稿 ( Atom )