開発期間とコストに制約が無い場合に限り理想的なシステムが構築できると思っています。現実はコスト面で制約が加わり、運用でカバーできる範囲は人的にカバーするのでシステム化しないという妥協点を見出す事になります。
この妥協点はキチンと明文化して周知徹底していないとトラブルの元にもなりかねません。トラブルネタは後日に取って置くとして、ここでは運用で想定してない事例が起こった話。
営業時間が8:00～19:00のお店。月次処理はバッチで行うという有り触れたシステムを設計した際、稼動当初の月次バッチの起動は月末営業日の最終売上げ後、担当者が[月末処理ボタン]を蹴るというスタイルで、月次処理未完了ならは次月のエントリーはできないという要件(これも一考の余地があるのですが)。
ところが、担当者が月次締めを失念してしまうことが頻繁にあり月初の売上げ処理の度にクレームが来たりします。対策協議の結果、「月次を自動化する。深夜の無人起動は不安だ。蹴るタイミングは月初めの日で最初の立上げた端末から自動で蹴る。朝の数10分はバッチ処理で入力できなくても、さほど支障がない。」
対処療法的な気がしたので一つ提案しました。「月末日の処理が長引いて深夜0:00回った時で且つPCを立ち上げ直したら困るよ。」->「遅くても20:00には店を閉めるのでその様な事態は起こらないから考慮無用」
歳月が経過したある日、販売品目のメーカーのキャンペーンとかで販売時間を 22:00まで延長することになり且つ其の期間に月末が含まれてました。重なるもので、データ入力が追いつかず、日を跨いでしまい且つ、PCを立ち上げ直した人がいました。=>月次処理が起動した……以後泥沼化
業界名言の「危惧されながらも対処していない事態は必ず起こる」がまさに当てはまります。
責任云々で揉めることは無かったのですが、回避できたのではないかと考えることがあります。前日の業務が完了しているのを判定する仕組みとか、連続業務か非連続業務かなども必要かも知れません。
結局は開発コストと要件とのトレードオフになるんですが、運用でカバーするとしていないがらも、カバー出来ずにシステムに負担が被ることは結構起こります。
この辺りの調整も難しいものです。