点検データを、
次のO&M判断へ。

監視システムによってはAPIが公開されていない場合があります。そのため最初からAPI連携を前提にせず、CSV出力、定期レポート、メール通知など、実際に取得できる形式を確認したうえで設計します。何を、どの頻度で、どの形式で取り出せるかは、ヒアリングとデータ確認の段階で一緒に整理します。

自動では決定しません。発電損失、継続時間、設備の重要度、過去の異常履歴、契約条件といった判断材料と、その根拠を提示するところまでが仕組みの役割です。最終的な判断は必ず貴社のご担当者が行う設計にしています。安全や保安に関わる判断を、システムが代替することは想定していません。

この点は設計の中心に置いています。オーナーごとの契約範囲、駆けつけ対応の有無、追加費用の発生条件、承認が必要かどうかをマスタとして管理し、アラート発生時にその発電所の契約条件と合わせて表示します。契約内容を都度確認する手間と、担当者による判断のばらつきを減らすことを狙っています。

現在お使いの帳票を前提に設計します。新しいフォーマットへの移行を求めるのではなく、点検結果や写真を既存の帳票へ反映する形を基本に考えています。実際の帳票を拝見したうえで、どこまで自動反映できるかをお伝えします。

発電所・設備単位で点検項目を設定できる構成を前提にしています。加えて、前回の異常箇所や要経過観察項目を、その回だけの重点確認項目として追加できる形を想定しています。

現場での入力は、チェック、選択、写真撮影、短いコメントを中心に設計します。文字入力を前提にした画面や、多階層のメニューは避ける方針です。実際の現場で試していただきながら調整することを前提にしています。

担当する発電所や実施項目に応じて、閲覧・操作できる範囲を分ける構成を想定しています。どこまで細かく分ける必要があるかは、実際の体制を伺ったうえで設計します。

発電所によっては電波状況が良くないことを前提に、オフラインでの記録と、通信が回復した後の同期を想定しています。対応できる範囲はPoCの段階で実際の現場環境を確認しながら決めていきます。

国内リージョンのクラウド環境での運用を基本とし、アクセス権限を役割ごとに分ける設計を想定しています。貴社の社内規定や、オーナー企業との契約上の要件がある場合は、その条件に合わせて構成を調整します。具体的な要件は個別にご相談ください。

対象とする業務範囲によって異なります。まずは1発電所・1業務に絞った小さなPoCから始め、有効性を確認したうえで範囲を広げる進め方をおすすめしています。期間と費用は、ヒアリングとデータ確認を経たうえで個別にお見積りします。

問題ありません。要件書やシステム化の計画は不要です。現在の点検表、報告書、異常対応の記録を拝見しながら、どの業務から手をつけるべきかを一緒に整理するところから始めます。