業務プロセスの高度化において、チェック要件（ビジネスルール）こそ重要な現場ノウハウ

業務要件の本流は、業務規定書に業務フローなどが書かれている。

社内で公知の事実であって、他社と比べてもそれほど特殊なケースはそう多くない。

ましてや、業務パッケージなどを使用する場合、すでに標準的な業務フローや機能は組み込まれており、他社との差別化にはならない。

引合い→見積→受注→生産計画。。。などと書くとそれこそ皆同じになってしまう。

では、自社の強みや差別化はどこか。

やはり、現場の経験から得たノウハウではないだろうか。成功や失敗の経験から、「こうすれば上手くいく」という現場ノウハウはとても重要なものだ。

そして、この現場ノウハウは業務フローなどには表れない、チェック要件などになる。チェック要件はビジネスルールともいう。

さまざま業務パッケージがあるが、このチェック要件は最初から組み込まれていないことが多い。それは現場ノウハウから出てくることが多いので、標準機能として組み込むのが難しいからだ。

業務フローは同じでも、チェック要件（ビジネスルール）は百社百様、そして常に変化する。

例えば、給与明細に毎月の稼働日数と稼働時間があったとしよう。システムの標準機能では両者を入力することになっていたとする。

この時、稼働日数と稼働時間の整合性をチェックする要件は、現場ノウハウによる。

例えば、1日の稼働時間が8時間なら稼働日数ｘ8時間が稼働時間と等しくなければ警告かエラーを出すことにするとか。あるいは、稼働時間は入力せずに自動計算するとか。

あえて自動計算せず、内部統制上、別々に集計入力して双方を整合性をチェックするというチェック要件もありだ。

このあたりは、現場の経験からどちらがより自社にとって有効かを評価することになる。

いずれにしても、こういったチェック要件を組み込まず、稼働日数と稼働時間を人が目視チェックする「力技」というのでは、

わざわざ敵が有利な地形にいるところに出向いて戦う、自ら敗北を求める愚行である。

どうしたら効率的に入力ミスを無くし、システムを有効に活用できるか自社の有利な土俵に持ち込めるかといった現場ノウハウ、それが「チェック要件」だ。

だから、現場ノウハウが少ないスタートアップ企業は十分な「チェック要件」をパッケージに組み込むことができないため、標準のまま使用していて、人手不足（力技）によるミスなどが発生しやすくなる。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　●企業システム戦略兵法三十六計　攻戦の計　第十五計　調虎離山
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

　調虎離山（ちょうこりざん）「調って虎を山から離す」

　敵が有利な地形にいるところに出向いて戦うのは、自ら敗北を求める愚行である。