「報告」と「案件」との関係整理
ここでいう「報告」とはオーナー等への報告の事であり、紙帳票で業務遂行していた時の報告書の事を指しています。一方、「案件」とは不具合等により修繕を実施する際の一連の情報を指します。簡単な不具合であれば報告と案件は一件ずつ組みになる場合もありますが、一般的にはひとつの報告書で複数の修繕箇所を指示する場合がある一方、不具合が無い報告書もあり得ます。逆に一件の不具合に関して何度も報告する事も頻繁にあります。この様に報告と案件の関係は多様です。
これをFMシステムや電子データから見ると、この多様さが問題になる場合があります。例えば、FMシステムによっては報告は不具合単位に提出する仕様になっている可能性がありますし、電子データとしてCSVを使う事を想定すると「報告一覧」という様な表に幾つの不具合のカラムを設けるべきなのか一概には決められません。そこで、FMシステム毎のルールを確認して関係を整理しておく必要があります。以下、検討項目を例示します。
- 不具合が伴わない報告の可否
FMシステムの機能に依存します。CSVとして報告に関する電子データを作る場合は、不具合が無い場合に不具合のカラムに何を登録するか決めておく必要があります。例えば長さがゼロの文字列(“”)などです。 - 不具合数の上限
これもFMシステムの機能に依存します。CSVとして報告に関する電子データを作る場合は、不具合を示す項目数を決めておきます。例えば「報告に記載できる不具合は一件だけ」と決めると必要なカラム数はひとつだけになります。また、応急処置・本処置・恒久処置の最大3件にしている事例も見受けられます。尚、12条点検の報告書の様に上限を設定できない報告書もあります。この様な報告書については別管理にするなどの工夫も必要です。
尚、共通データ仕様の形式を採用する電子データの場合は報告と案件の関係は自由に登録可能ですので、ここで関係整理するのはFMシステムとCSV等の表形式の電子データについてのみです。
不具合の登録単位
■不具合は一件ずつ登録
共通データ仕様を採用する目的のひとつは後々不具合傾向などの各種分析を行えるようにする事です。従って、登録される不具合情報は不具合毎に1件いっけん別々に登録しておくことが有効です。施設管理のソフトウェアやクラウドサービスによっては、ひとつの不具合を登録する際に、複数の場所や設備を一括して登録出来るものがあります。その場合、電子データを出力する際に別々の不具合として出力できるかどうかを確認する必要があります。もし、別々の不具合として出力できない場合は、一回の点検で複数の不具合を見つけた場合でも不具合を1件いっけん別々に登録する様な運用にする必要があります。
■再発した不具合は別の不具合として登録
雨漏りなどでは原因が明確に判断できない場合があります。その様な場合にも被疑箇所を全て修繕し尽くす事が可能であればよいのですが、一般的にはコストや工期の関係から最も効果が出るであろう被疑箇所(第一被疑)を修繕し、様子見する事があります。この雨漏りの例だけでなく、一般的な保守管理業務では複数の被疑箇所をコスト・工期・リスクの観点から比較検討し、順位を決めて対応する事がよくあります。その場合、修繕がいつ終わったかよく判らないのですが、データ管理の観点では最小の単位である個々の修繕ごとに不具合を登録する事が望ましいです。これは、データ分析時にはなるべく細かな単位で情報登録されている方が分析が容易であるためです。FMシステムによっては、この対応として不具合同士を鎖に様につないで一連の不具合である事を表現できる機能を備えている場合もありますので、確認してください。
