IBM Sustainability Software
EAMの勘所:第20回 企業ワイドの保全管理の仕組みづくり(4)
2014年06月14日
カテゴリー IBM Sustainability Software | 設備保全・高度解析
記事をシェアする:
モデルの作成
EAMの勘所とは
企業資産管理を円滑に行うために「EAMの勘所」と題して定期的にコラムを掲載していきます。
第 20 回目は、「企業ワイドの保全管理の仕組みづくり(4) モデルの作成 」についてご説明いたします。
(※EAMとは、IBM Enterprise Asset Management の略です。)
標準保全管理モデルの構築
現状調査のプロセスで、「保全管理の対象」「管理粒度」「管理プロセス」などが明確になり、Enterprise Asset Management(EAM)を導入する対象が決定されます。
しかし、一般的に現状調査で明確になることは、「非常の多くの対象資産種別が存在」し、またその各々に対して「個々の管理台帳、管理プロセス」が適用されている、という事実です。
この状態をそのままEAMのシステムに統合しても、管理の簡素化は実現できず、導入費用に非常に多くのコストがかかってしまいます。また現状の問題点の解 決策をシステムに求めると、カバーされる範囲は過去の問題を解決するシステムとなり(現状の問題点は過去に発生した問題点の積み残しの状況に帰着している ため)、今後起こりうる未来の問題に対処できず、数年でシステムの再構築が必要になってしまいます。
そこでシステム導入の前に、今後5~10年後を見据えた標準的な保全管理のモデルを作成し、そのモデルに沿ったシステム構築を行うことをお勧めします。
それでは「モデル」を考えてみますが、次のような項目がポイントになります。
表 1 標準保全管理モデルの構築に関する留意点
留意点 | 説明 |
---|---|
管理モデルの抽象化と標準化 | 保全管理プロセスを調査し、その共通点を把握して、抽象化し、標準化を行います。この作業により、従来統合できないと思われている管理対象、管理プロセスが統合できる可能性が理解できます。 |
複雑性の排除 | 管理プロセス(例:承認プロセスなど)は過去の事故や改善に従って構築された、または部門長の指示で追加されたものを基本として作成されている場合があります。このようなプロセスを標準化し、複雑性を排除します。 |
国際標準・業界標準の参照 | 国際標準や業界標準は様々な過去の知見及び、今後のあるべき姿を考慮して策定されています。管理モデルを構築する場合は、このようなモデルとなる教科書を準備します。 |
要求項目の共通化 | 構築するシステムのアプリケーション画面やデータ項目、帳票などを構築に参加する部門で話し合い、共通の仕様を作成します。 |
管理モデルの抽象化と標準化
1990年代、保全管理システムは管理対象の資産(機械設備、電気計装、車両・・・など)の種類別や、その対象を管理する組織別に作成されることが一般的 でした。これは管理対象により管理する項目や管理技術が異なっていると考えられ、その個別のプロセスをサポートするために情報システムが構築されていたた めです。
たとえば、管理対象に「ポンプ」が存在する場合、ポンプ管理台帳が存在し、ポンプ管理システムが構築されました。この考え方を延長すると、モータ管理シス テム、バルブ管理システムなど様々な設備単位に情報システムが構築されることとなり、実際に、電力会社などでは非常に多くのシステムを使用して、保全管理 をおこなっていました。
このようなシステムの場合、管理を行っている担当者にとっては非常に使いやすいシステムであり、便利なツールとして能力を発揮しました。
しかし2000年以降になると、この考え方が変化します。管理の効率性及び厳格性を求めるようになると、各々のシステム間の連携が必須となり、そのためシ ステム間のインターフェースが増大化します。このインターフェースの開発には多くのコストが必要になるとともに、システム全体としての硬直性を招きました (Aのシステムを更新するためには、Bシステムの変更が必要であるが、CシステムがBシステムの情報を利用しており、Cシステムは更新できないため、Aシ ステムは更新できない・・・などなど)。
このような問題を解決するためには、保全管理に関する考え方を変える必要があり、共通機能と個別機能を分離し、共通部分を組織全体で共有して利用するモデルへと変化してきています。
たとえば保全作業の分類は「予防保全」「事後保全(故障対応)」の2つに大別され、「予防保全」は「日常点検」「部品交換」「定期保全」「計画工事」などに分類できます(呼び方は組織によって異なりますが、分類の本質は変わりません)。
また予防保全と事後保全の管理の方法も予算管理を含めた「計画→実行→記録という保全モデルと実行→記録→故障分析」などの、事後保全モデルに標準化できます。
図 1 米国の電力会社様におけるシステムの整理の例
EAMの考え方を導入する場合、始めに管理対象、管理プロセス、管理粒度などその共通点を見いだし、「標準化可能なものは何か?」、「標準化できない理由はなにか?」をきちんと検討する必要があります。 また標準化可能な部分を集めて、管理モデルを検討することをお勧めします。
IBMの資産管理ソリューションMaximoはこの標準化の点において非常に優れた機能分類、データベース構造を持っており、標準化の検討を土台とするには最適なシステムです。また多くのお客様がMaximoの考え方にしたがってシステムを構築されています。
EAMの考え方を導入する場合、始めに管理対象、管理プロセス、管理粒度などその共通点を見いだし、「標準化可能なものは何か?」、「標準化できない理由はなにか?」をきちんと検討する必要があります。 また標準化可能な部分を集めて、管理モデルを検討することをお勧めします。
IBMの資産管理ソリューションMaximoはこの標準化の点において非常に優れた機能分類、データベース構造を持っており、標準化の検討を土台とするには最適なシステムです。また多くのお客様がMaximoの考え方にしたがってシステムを構築されています。
複雑性の排除
通常ビジネスを管理する立場では、様々な問題が発生するたびに様々な個別改善行われます。システムの変更や承認プロセスの強化など、システムからビジネス管理にいたるまで改善が実施されていきます。しかし、時としてこのような改善は管理の複雑性を招く原因になります。
たとえば、ある重大な問題が発生したことに対する予防措置としての「確認作業」や「承認行為」はその問題が発生する可能性がある間は非常に有効な方法です。
しかし、状況は常に変化します。この予防措置や承認行為がプロセスの中に組み入れられ、長い時間を経過するなかでその意味が失われ、「昔からやっていたので・・・・今もやってます」というような業務が多数存在するケースがあります。
一般的に業務管理は簡略化される方向にはなく、強化される方向にあり、単純な対策をプロセスやシステムに組み入れることにより、非常に膨大なシステム機能及び開発コストを生むばかりではなく、業務効率の低下を引き起こす原因になります。
EAMの導入に際して、このような複雑性を再検討し、「残すべきもの」と「排除すべきもの」を区別してモデルを組み立てる必要があります。
通常、改善活動でもたらされる効果は「点」の効果であり、その効果にも「賞味期限」があります。
また点の改善の集合は面として全体を観察した場合、必ずしも効果を上げていない場合もあり、プロセスの整理・整頓を実施することをお勧めしています。
- 整理とは = 複雑な状態を整えきちんとする。不要なものを処分する
- 整頓とは = あるべきものをあるべきところに片付ける
国際標準・業界標準の参照
前回の「第19回 企業ワイドの保全管理の仕組みづくり(3)」 の「手本となるベスト・プラクティスの参照」でも述べましたが、保全管理のモデルを作成する場合、その手本となる教科書が必要であり重要です。教科書とし て参照をお勧めするものに国際標準があります。一般的に国際標準はどの組織にも適用出来るように抽象的に記述されていることが多く、その内容を読んでも、 どのような具体的な活動を行なったらよいかを見つけ出すことが出来ないものがあります。
しかしこの表題にもあるとおり「モデルの作成」には非常に役立ちます。モデルとは「模範」となるべき考え方やその骨格を構成するもので、モデル自身は抽象 的なものです。このモデルを中心にその組織における特徴を肉付けし、ベスト・プラクティスとなる管理体系、管理プロセス、管理システムを構築していきま す。
国際標準ではわかりにくい場合は、業界標準を使用することもお勧めします。
業界標準はその業界における特徴を取り入れた個別標準と国際標準と比較して、具体的な内容が記述されています。しかし残念ながら、すべての業界で保全管理 に関する業界標準を持っているわけではありません。このような場合でも、保全管理上の類似点は十分理解可能で、流用が可能な場合が多々あります。様々な別 の業界標準を参考とし、その組織にあったモデルを作成してゆくことは十分可能です。
要求項目の標準化
多くの部門(複数の部門や工場など)が参加して導入を行うEAMでは、「総論賛成」「各論反対」に通常なりがちです。
これはモデルまでは全員の総意として賛成できるのですが、こと話が個別業務へ及んでくると「自分の仕事が変わったり」、また「余分な仕事が増えたり」します。すると途端に抵抗勢力に変わってしまう場合があります。 (これはどのようなプロジェクトでも同じです)
しかし、ここを乗り越えないとEAMの導入はできません。EAMの導入ではこの利害の衝突を調整して、大義のために犠牲を払う部門や担当者が出てくる場合 があります。しかし企業経営としては時にそのような判断を受け入れなければならない場合があります。EAMの導入ではこの利害の調整を行うコーディネー ターの存在も重要になります。
この個別に発生する要求事項を調整するためには、以下のような着目点を考慮する必要があります。
表 2 要求項目の標準化のコツ
着目点 | 説明 |
---|---|
データ項目の標準化と個別管理項目のサポート | 「あるべきデータの定義」「名称の標準化」などを行い、管理すべきデータ項目を全組織で共有化し合意します。またある一定の制限を決め、各組織独自のデー タ項目をサポートします。複雑性の排除の節でも述べましたが、要求項目には現在問題になっていることが含まれていますが、その項目は今後も必要になるとは 限りません。 |
画面の標準化 | 情報システムにおいて画面は使い易さの代表的な部分です。しかし使いやすさは一定の経験をつむと「なれ」によって解決する場合があります。画面の標準化は如何に個別要求の画面作成を標準化して制限し、画面開発コストを削減できるかに重点をおきます。 |
帳票の標準化 | 画面と同様、帳票も各組織及び目的ごとに作成され、導入コストを大幅に引き上げる原因となる領域です。通常帳票開発では所管官庁に提出するフォーマットが決められているもの以外は、共通化を検討します。 またデータのダウンロードなどデータウェアハウス機能、アドホック帳票作成機能などを使用し、なるべく個別の帳票開発を防止します。 |
承認プロセスの簡素化 | 一般的に承認プロセスは複雑になる傾向があります。権限の委譲などを含めて承認プロセスを簡素化します。よくある事例に「担当者→主任→課長→部長の承認 印を今までもらっているので、システムでもそうしたい!」という要求事項がありますが、仕事の内容によっては「担当者→主任」で十分な場合があります。こ れは管理職がその内容を確認したという証拠を残すのが目的で、承認を行うことが目的ではありません。このように一見承認という行為も深く突き詰めてみると 様々な目的が混合している場合があります。この整理と実現方法の検討が重要です。 |
システムの変更が柔軟に行えるシステムの選択 | 保全管理の分野ではその時々によって注力する部分に変化が発生する場合があります。モデルの標準化だけでは、不定期に発生する問題を統合的に管理できず に、表計算ソフトでの情報記録を余儀なくされます。このような状態を放置するとEAMシステムが陳腐化するため、EAMでは標準化と個別化の両方を同時に サポートでき、柔軟に改造できるシステムを選択することが、長期間でみた成功の秘訣です。 |
EAMの適用には多くの標準化やビジネスプロセス改革が必要になるため、単純な情報システム導入で終わることは決してありません。しかし、EAMの考え方 を採用されている企業では10年、20年と同じ考え方、システムを使用している例が非常に多く、このことはモデル作成効果の大きさを物語っています。
問い合わせ情報
日本Maximoユーザー会2024@天城ホームステッド 開催レポート
IBM Partner Ecosystem, IBM Sustainability Software
2024年10月15〜16日の2日間に渡り、IBM天城ホームステッドにて1年半ぶりの「日本Maximoユーザー会」が開催されました。 石油・化学企業、産業機械製造企業、エネルギー企業、エンターテインメント企 ...続きを読む
トヨタ紡織「 A-SPICE レベル3」取得活動事例 | シートシステム/車室空間開発の未来に向けて
IBM Partner Ecosystem, IBM Sustainability Software
「Automotive SPICE(A-SPICE)の取得を意識し、実際に検討を本格化したのは2021年です。そして昨年2023年3月にレベル2を取得し、そこから約1年半で今回のA-SPICE レベル3の取得となりました ...続きを読む
「何度でもやり直せる社会に」あいふろいでグループ代表 吉谷 愛 | PwDA+クロス9
IBM Partner Ecosystem, IBM Sustainability Software
「日本は一度ドロップアウトした人にとても厳しく、いわば『敗者復活』の機会が残念ながらとても限られています。ただそんな中で、半年程度の準備期間で再チャレンジの機会を手に入れられるのが『IT』です。 私自身、ITに救われた身 ...続きを読む