本ケーススタディの概要
施設管理のクラウドサービスには多様なものがあり機能性操作性付随サービスなどでお互いに覇を競っています。一方共通データ仕様はオーナーと各種施設管理事業者とのやりとりや事業者間の情報共有に着目してそのデータ仕様を共通化する取り組みですから、各クラウドサービスが共通データ仕様に全て則って設計されている事はあり得ません。そこで、個々の施設管理のクラウドサービスで具体的にどの様に共通データ仕様を活用するのか、実際にサービスを使った操作例を紹介します。
本ケーススタディでは、株式会社設備保全総合研究所(以下、EML)が提供する設備管理に強みを持つクラウドサービスEMLinkを使ってみます。上記の様に共通データ仕様は関係者間での情報のやりとりをする際のデータ仕様を共通化しようとするものですが、EMLinkは情報のやり取りだけでなく内部管理や計画策定なども含めた多様な使い方ができます。従って、本ケーススタディはEMLinkの機能のほんの一部だけを紹介しているものである事、そしてこのケーススタディの使い方はEMLinkの利用法のごく一例だとご理解ください。もしEMLinkを導入する場合は、本ケーススタディを単純に踏襲する事はお勧めしません。事前に同社とよく相談してみる事を強くお勧めします。尚、EMLinkの機能詳細は同社の一般ユーザ向けヘルプページをご覧ください。
EMLinkの特徴と共通データ仕様との整合方法
共通データ仕様は文字通りデータの仕様に過ぎませんし、その対象も事業者やオーナー等の法人間のデータのやり取りである事に対し、EMLinkは独立したシステムでありクラウドサービスなので単純に比較する事は無理があります。そこで、ここではEMLinkのデータ登録などの各種画面やCSVへのダウンロードの機能をデータをやり取りするためのデータ仕様に見立てて比較します。
「共通データ仕様の基礎知識」に記載しように、共通データ仕様は「多目的データモデル」であり、モノやコト単位にデータを登録する流儀で作成されています。EMLinkも同様にモノやコトを登録できるようになっています。モノはEMLinkでは便宜的に「設備」または「機器」と呼んでいますが、設備などのいわいる機器だけでなく、施設・場所(棟や部屋や駐車場などの施設内の場所こと)などのあらゆる作業対象のモノを表現できます。
設備管理で登録しなければならないモノは、事業者やオーナによるそれぞれ異なると思われますが、一般的には以下の様になっていると思われます。「共通データ仕様の呼び方」にはデータモデルの呼称を表示していますが、項目を表示する場合は「データモデルの呼称/項目の呼称」の形式で表示しています。
| 管理対象の「モノ」 | 共通データ仕様の呼び方 | 説明 |
|---|---|---|
| 施設全体 | 施設 | 例えば施設の法定点検や巡回点検を行う際は対象は施設全体となります。共通データ仕様では「施設(Facility)」「建物(Building)」「土地(Land)」が対応します。尚、ここで言う「施設」は施設全体であり、テナントとして入居している「施設」ではありません。同様に、「建物」も建物全体を指します。 |
| 建物 土地 | 施設が複数の棟から構成されている場合、12条点検などの法的な点検報告では棟毎に分けて記載する事を求められます。共通データ仕様では「建物(Building)」が対応します。施設全体とおなじ「建物」が出てきたので混乱するかもしれませんが、詳しくは「施設管理における使い方」をご覧ください。尚、本ケーススタディでは棟毎の点検などは対象外としているので、棟は登録しません。 | |
| 入居施設 | 施設 | 施設内に入居している施設です。施設カルテなどでは複合施設の場合には入居している施設毎に分けてカルテを作成する事があります。入居施設は共通データ仕様では「施設(Facility)」が対応します。施設全体と同様に「施設」が出てきます。この点についても詳しくは「施設管理における使い方」をご覧ください。尚、本ケーススタディでは入居施設の登録はしません。 |
| 場所 | 施設内で設備以外に不具合があった時、例えば部屋の壁が汚れているなどの事態が発生した場合、施設のどの部分で不具合が発生したのかを明確にする必要があります。例えば「”校舎”の”1階”の”音楽室”の壁が汚れている」や「”屋外”の”駐車場”の車止めが壊れている」などとなります。本ケーススタディでは屋内は部屋を、屋外は各場所をモノ(つまり機器)として登録します。例えば「校舎-1F-音楽室」などと部屋ごとに登録します。詳しくはケーススタディ#0をご覧ください。 | |
| 設備 | 設備 | 文字通り設備です。設備は一つひとつ別のモノとして考え、一つひとつの設備を「機器」として登録します。但し、どこまで細かく管理するのかは事業者やオーナーによって異なります。 |
以上をまとめると、本ケーススタディでは管理対象の施設のに関する共通データ仕様とEMLinkに登録する施設情報の関係は以下の通りです。
この図の中で共通データ仕様の「施設」にある「場所」とは、施設内の各場所の名前を登録しておく項目を指します。この項目にはケーススタディ#0にある様な名前のリストを登録する事が出来ます。EMLinkではこの場所の情報を単に名前が並んでいるリストを登録するのではなく、一つひとつの場所を「機器」として登録します。機器として登録する事で、後述する様に設備以外の部位に関しても不具合の登録が可能となります。
次にコトの表現です。施設管理におけるコトとは各種作業の計画や実行を指します。EMLinkは施設管理における多様なコトを柔軟に表現できます。例えば法定点検の計画や実行、不具合の検出や修理、利用者やオーナーからの要望と対応などです。これに対し、共通データ仕様は不具合と各種報告だけを対象にしていますので、共通データ仕様の方が表現可能な範囲は狭いと言えるでしょう。EMLinkはこれらのコトの情報の登録は、基本的に「勧告」と「保全」の登録で行います。「勧告」とは各種の計画であり、「保全」とはその勧告に対する対応です。要望や不具合は計画的に発生する訳ではありませんが、計画と同様に「勧告」で表現し、その対応を「保全」として登録します。実際の運用では、単に保全を登録して作業が完了する訳ではなく、ワークフローで承認を求めるなどの手続きも必要となりますが、本ユースケースでは省略します。また複数の不具合を検出して、それらの勧告を一気に作成したり、処置の内容を報告書に転換するなど、利用者の利便性を考えた機能も豊富ですが、本ケーススタディでは省略しています。
以上を図にすると以下の様になります。EMLinkの勧告と保全は機器に対して登録します。つまり、本ケーススタディでは機器としては施設全体・場所・設備の3種類を考えていますから、これらに対して登録する事になります。例えば「施設全体」に対して巡回点検を計画するとか、「場所」に対して雨漏れや汚損などの不具合を登録するとか、「設備」に対して異音などの不具合を登録するなどとなります。下図は屋上の設備で不具合が起きた例です。
共通データ仕様では、不具合等に対する一連の報告を「報告(Report)」でそれぞれ登録可能であると共に、不具合等そのものは「案件(Complaint)」で1件登録します。この様にEMLink勧告や保全報告と共通データ仕様のデータモデルでは、登録情報そのものに対応関係があるのではなく、登録情報を構成する個々の項目ごとに対応関係がある事になります。この対応関係は、EMLinkの項目の設計時に詳しく説明します。
以下、マッピングの例です。尚、マッピング先が括弧付きの項目は、本ケーススタディではマッピングせずEMLinでは対応を作成しない項目を指します。
ケーススタディ詳細
本ケーススタディでは、ケーススタディ#0に示した仮想的な施設を管理する事を想定します。
実際にデータをEMLinkに登録する作業についてはEMLに必ず事前にご相談ください。EMLinkに限らず、全てのクラウドサービスは初期導入時のデータ登録や操作の修得がひとつのハードルです。そこで同社としても利用者の負担を減らす多様な対応を提供しています。従ってこのケーススタディでは、登録手順の詳細はイチイチ記載しませんので、実際の手順はEMLにお願いするかマニュアルをご覧ください。繰り返しですが、皆様はEMLとよく相談して効率よく、そして後で後悔しない導入を進めて下さい。
では話をケーススタディに戻しましょう。
本ケーススタディで想定する作業は下図のように巡回点検により不具合を見つけたけれど、まずは応急的な処置を実施し危険を取り除いたうえで恒久処置を計画する内容を想定します。恒久処置は予算の都合なのか実施されていないと想定します。
このケーススタディでは既に記述した様に施設全体と場所と設備を事前に登録します。設備に関する不具合は登録しておいた設備情報に対して報告する運用を想定します。一方、設備以外の部位の不具合、例えば壁に傷がついてイメなどの不具合は、場所(部屋など)に対して不具合を報告する運用を想定します。
さて、いよいよ施設の情報の登録を検討しましょう。EMLinkは、「事務所」「ユニット」「設備カテゴリ(設備分類)」「設備(機器)」「資材・部品」の5階層で設備を定義します。以下、それぞれの階層を本ケーススタディではどの様に活用するのかを紹介します。
・事務所
ログインするユーザはいずれかの「事務所」属します。従って事務所はログインしたユーザが共有できる情報の最大の範囲となります。そこで本ケーススタディでは、施設管理事業者からみたお客様の単位とします。例えば包括施設管理であれば自治体毎に「事務所」を分ける運用となりますし、PFIであれば案件毎となります。複数の「事業所」にまたがってデータを集計したいなどの操作は本ケーススタディの範囲外とします。提供元のEMLにご確認ください。
・ユニット
ユニットは、EMLinkにおける基本的な単位です。本ケーススタディでは管理対象の施設をひとつのユニットとします。施設の規模によっては棟などをユニットとする事も可能ですし所管の部門をユニットとすること可能ですが、本ケーススタディでは施設単位に統一しました。
・設備カテゴリ(設備分類)
設備カテゴリは機器をおおまかに分類する単位です。本ケーススタディでは以下の分類を活用します。
| 建屋 – 全般 | 施設全体の「機器」を登録する際に「建屋 – 全般」を選択します。 |
| 建屋 – その他 | 施設内の「場所(zones)」を登録する際に「建屋 – その他」を選択します。駐車場やグランドなどといった建屋外の場所についてもこの設備カテゴリを選択します。 |
| (それ以外) | 設備を登録する際には建屋以外の最も設備に近いものを選択します。 |
・設備(機器)
既に述べたようにあらゆる管理対象を機器として登録します。本ユースケースの管理対象は「施設全体」「場所」および「設備」です。「共通データ仕様の呼び方」にはデータモデルの呼称を表示していますが、項目を表示する場合は「データモデルの呼称/項目の呼称」の形式で表示しています。
| 管理対象の「モノ」 | 共通データ仕様の呼称 | 「機器」に登録する情報 |
|---|---|---|
| 施設 建物 土地 | 施設全体の機器に情報を登録します。共通データ仕様では、「施設」は施設全体を表す事も、テナントとして入居する個々の施設を表す事も、避難所の様に臨時に設置される施設を表す事も出来ますが、このケーススタディは施設管理のための施設ですから、最初の施設全体を意味します。共通データ仕様では、「建物」と「土地」の情報は「施設」と分離して登録する様になっていますが、本ケーススタディでは施設の機器に併せて登録してしまいます。つまり、この機器には、施設名、住所、所管部門、総床面積、連絡先などをまとめて登録してしまいます。 | |
| 場所 | 次項の「設備」ではない部位で発生した不具合、例えばある部屋の天井から水漏れがあったなどの不具合で使う「機器」です。管理の最小単位を登録すべきと考えますが、本ケーススタディでは「場所(zones)」の「場所小分類(subzoneNameの第2項)」となります。「小分類」が無い場合は「場所中分類(subzoneNameの第1項)」となります。例えば、ケーススタディ#0の「呉市吉浦市民センター」であれば、“建物内部”の”1F”の”吉浦支所”がひとつの「機器」として登録されます。因みにこの場合の機器の名前は”建物内部-1F-吉浦支所”となります。 | |
| 設備 | 設備/機種 | 設備も「機器」として登録します。設備も複数の部分から構成されているかもしれませんが、施設管理業務上の管理の単位で登録します。本ケーススタディでは「呉市吉浦市民センター」であれば、9つの設備用の「機器」が登録される事になります。 |
・資材・部品
資材・部品は本ケーススタディの対象外とします。勿論、実際の施設管理ではぜひ活用して効率的な管理を実現してください。
「機器」の項目(カラム)の設計
既に述べた様に施設や場所などの各種の「モノ」は「機器」として登録します。この機器には既定の項目(カラム)があり、ID､名称、ユニットなどの幾つかの項目が最初から定義されていますが、追加で10個までの項目を追加定義する事ができます。本ケーススタディでは以下の項目を定義する事とします。基本的に多数の設備や場所から探す際に絞り込みのキーとなる情報は独立した項目とし、キーとなりにくい情報はひとまとめにして特記事項に登録する仕様としました。
■施設全体を表す「機器」の設計
| EMLinkの項目名 | 種類 | ケーススタディ#1の項目 | 説明 | |
|---|---|---|---|---|
| 設備ID | 既定 | 管理通番 | 施設/管理通番 | 本ケーススタディでは、他の機器と重複しない文字列として管理通番を採用しました。他の文字列でも構わないと思います。 |
| 既定 | 施設名 | 施設/施設名 | 施設名を採用しました。 | |
| ユニット | 既定 | 施設名 | 施設/施設名 | 本ケーススタディでは施設とユニットを対応させています。 |
| 設備分類 | 既定 | (なし) | (なし) | 施設全体の機器なので”建屋・全般”を選択しています。 |
| 設置日 | 既定 | (なし) | 建物/竣工日 | 本ケーススタディでは設定していません。 |
| 市区町村 | 追加 | (なし) | 法人/名称 | 複数の自治体の情報を統合して分析する場合に備え、自治体の名称を登録しておきます |
| 特記事項 | 既定 | 施設名カナ 管理通番 所管部門名 部門コード 郵便番号 住所 | 施設/管理通番 部門/部門名 部門/部門ID 部門/連絡先 土地/郵便番号 土地/住所 | 本ケーススタディでは特記事項には、設備や部位の固定的な情報をまとめて登録します。JSON形式で登録しますが、JSON以外の扱いやすい形式でも構いません。 管理通番: オーナーが施設を識別するために付与している文字列です。施設番号、施設ID、施設コードなど多様な呼び方があります。将来施設名(ユニットID)が変更になったとしても管理通番は変更しません。この項目によりオーナーのシステムとEMLlinkの対応付けを行う事を想定しています 所管部門名: 施設(ユニット)を所管するオーナーの法人内の部門名です。オーナーはこの所管部門名で自分が担当する施設を抽出して作業する事を想定しています。尚、実際の組織では組織が階層化されていることが多いですが、共通データ仕様では階層化してあることを前提としていません。従って、所管部門名だけで部門の識別ができる様に名前を付ける必要があります。例えば、「第一課」の様な他の部署にもあるような名称ではなく「総務部第一課」の様な名称が望ましいです。 郵便番号、住所: 施設の郵便番号と住所です。 |
尚、共通データ仕様では所管部門の「部門」は「施設」の「部門ID」から辿る事ができる情報であり、「法人」は「部門」の「法人ID｣から辿る事ができる情報です。施設の「土地」は、「施設」の「建物ID」から施設が入居する「建物」を求め、その「建物」の「土地ID」から辿る事ができる情報です。
■場所を表す「機器」の設計
| EMLinkの項目名 | 種類 | ケーススタディ#1の項目 | 説明 | |
|---|---|---|---|---|
| 設備ID | 既定 | 場所中分類 場所小分類 | 施設/場所 | 場所大分類、場所中分類、および場所小分類をハイフンで繋げた文字列とします。 |
| 機器名称 | 既定 | (同上) | (同上) | 設備IDと同じ文字列を登録する事としました。 |
| ユニット | 既定 | 施設名 | 施設/施設名 | ユニット名です。ユニット名は施設名と同じです |
| 設備分類 | 既定 | (なし) | (なし) | 場所の機器なので”建屋・その他”を選択しています。 |
| 設置日 製造社 型式 内容物 材質 適用法規 (関連図書) | 既定 | (なし) | (なし) | 本ケーススタディでは使用しません。 |
| 市区町村 | 追加 | (なし) | 法人/名称 | 複数の自治体の情報を統合して分析する場合に備え、自治体の名称を登録しておきます |
| 場所 | 追加 | 場所大分類 場所中分類 場所小分類 | 施設/場所 | 場所の情報を登録します。本ケーススタディではJSON形式で登録しますが、JSON以外の形式でも構いません。機器一覧をCSVでエクスポートした際に、必要に応じてExcel等の表計算ソフトで場所情報を大分類・中分類・小分類・場所備考に分解できる様に、キーワードが埋め込まれている形式としてJSONを選択しました。例えば次の形式となります。 {“大分類”: “建物内部”, “中分類”: “1F”, “小分類”: “男子トイレ”, “備考”: “個室2”} |
| 特記事項 | 既定 | 管理通番 | 施設/管理通番 | 本ケーススタディでは特記事項には、固定的な情報をまとめて登録します。場所と同様にJSON形式で登録しますが、JSON以外の扱いやすい形式でも構いません。 管理通番: オーナーが施設を識別するために付与している文字列です。施設番号、施設ID、施設コードなど多様な呼び方があります。将来施設名(ユニット名)が変更になったとしても管理通番は変更しません。この項目によりオーナーのシステムとEMLlinkの対応付けを行う事を想定しています |
■設備を表す「機器」の設計
| EMLinkの項目名 | 種類 | ケーススタディ#1の項目 | 説明 | |
|---|---|---|---|---|
| 設備ID | 既定 | 製造番号 | 設備/製造番号 | 製造番号を重複しない識別子として使用します。 |
| 機器名称 | 既定 | 設備名称 | 設備/設備名称 | 設備名称をそのまま登録します |
| ユニット | 既定 | 施設名 | 施設/施設名 | ユニット名です。ユニット名は施設名と同じです |
| 設備分類 | 既定 | (なし) | (なし) | 建屋以外の分類を設備の種類に合わせて適宜選択します。 |
| 設置日 | 既定 | 設置日 | 設備/設置日 | 設置日を登録します。 |
| 製造社 | 既定 | 機種/メーカー | 設備の場合、設備のメーカー名を登録します | |
| 型式 | 既定 | 型番 | 機種/型番 | 設備の場合、機種のモデル名を登録します |
内容物 材質 適用法規 (関連図書) | 既定 | (なし) | (なし) | 本ケーススタディでは使用しません。 |
| 市区町村 | 追加 | (なし) | 法人/名称 | 複数の自治体の情報を統合して分析する場合に備え、自治体の名称を登録しておきます |
| 設備種別 | 追加 | 設備種別 | 機種/設備種別 | 設備の場合、設備種別を共通データ仕様の用語に従って登録します |
| 場所 | 追加 | 場所大分類 場所中分類 場所小分類 | 設備/場所 | 設備の場合に設置場所の情報を登録します。本ケーススタディではJSON形式で登録しますが、JSONである事には意味はありません。機器一覧をCSVでエクスポートした際に、必要に応じてExcel等の表計算ソフトで場所情報を大分類・中分類・小分類・場所備考に分解できる様に、キーワードが埋め込まれている形式としてJSONを選択しました。例えば次の形式となります。 {“大分類”: “建物内部”, “中分類”: “1F”, “小分類”: “男子トイレ”, “備考”: “個室2”} |
| 追加 | ブランド名 | 機種/ブランド名 | 設備の場合に機器にブランド名がある場合に登録します | |
| 特記事項 | 既定 | 説明 管理通番 所管部門名 製造日 耐用年数 | 施設/管理通番 部門/所管部門 設備/製造日 機種/耐用年数 設備/場所備考 | 本ケーススタディでは特記事項には、設備や部位の固定的な情報をまとめて登録します。場所と同様にJSON形式で登録しますが、JSON以外の扱いやすい形式でも構いません。 説明: 設備や部位の説明です。オプションであり、必ず登録されているとは限りません。 管理通番: オーナーが施設を識別するために付与している文字列です。施設番号、施設ID、施設コードなど多様な呼び方があります。将来施設名(ユニットID)が変更になったとしても管理通番は変更しません。この項目によりオーナーのシステムとEMLlinkの対応付けを行う事を想定しています 所管部門: 施設(ユニット)を所管するオーナーの法人内の部門名です。オーナーはこの所管部門名で自分が担当する施設を抽出して作業する事を想定しています。尚、実際の組織では組織が階層化されていることが多いですが、共通データ仕様では階層化してあることを前提としていません。従って、所管部門名だけで部門の識別ができる様に名前を付ける必要があります。例えば、「第一課」の様な他の部署にもあるような名称ではなく「総務部第一課」の様な名称が望ましいです。 製造日: 設備の製造年月日を登録します。製造年月日を登録します。 耐用年数: 当該機種の耐用年数を登録します。 |
尚、共通データ仕様の「機種」とは設備の機種を表現するデータモデルであり、「設備」の「機種ID｣から辿る事ができる情報です。
機器に対する項目の追加は「システム設定」⇒「情報設定」⇒「機器情報設定」で行います。「場所」も「ブランド名」も項目の属性は「自由入力」です。自由入力とは任意の文字列を登録できるという意味です。詳しくはEMLにお尋ねになるかマニュアルをご覧ください。
以上でEMLinkの使い方の検討は終わりです。次ページからは実際に各種データを登録してみましょう。
