JP2012059020A - 保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法 - Google Patents

Abstract

【課題】
従来、装置障害発生時のオンサイト保守スポット費の見込み金額の算出および障害の波及範囲の有無や保守員の増員の有無などの判別、保守完了後の費用明細書の作成などを適切に行うことができなかった。
【解決手段】
伝送装置の障害発生時に保守費用の見積もりを行う保守費見積／明細作成用サーバ装置において、情報を入出力するマンマシンインターフェース手段と、障害対応終了後にマンマシンインターフェース手段から入力される障害対応内容を含む障害情報を過去の障害履歴として記憶する記憶手段と、オンコール受付時にマンマシンインターフェース手段から入力された検索キーワードに応じて記憶手段に記憶された過去の障害情報を検索する検索手段と、検索手段の検索結果に基づいて保守費用の見積額を求め、前記マンマシンインターフェース手段に出力する見積り手段とを備えることを特徴とする。
【選択図】図１

Description

本発明は、装置障害の発生時に保守員が現地で障害の復旧作業を行う場合のオンサイト保守スポット費の見込み金額の算出および障害の波及範囲の有無や保守員の増員の有無などの判別、保守完了後の費用明細書の作成などを行う保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法に関する。

ＷＤＭ（Ｗavelength Ｄivision Ｍultiplexing）装置やＡＤＭ（Ａdd Ｄrop Ｍultiplexer）装置、或いはルータやＬ２ＳＷなどの伝送装置に障害が発生した場合、保守員が現地で障害の復旧作業を行う必要がある。通常、顧客はテクニカルアシストセンター（ＴＡＣ）と保守契約を結び、障害発生時に伝送装置を復旧できる体制を整えている。

ここで、保守契約の種類として、顧客側で保守作業を行う場合とＴＡＣ側で保守作業を行う場合とがある。例えば下記のように、有償保守契約とオンコール契約の二種類が知られている。
（１）有償保守契約：現地での保守作業（オンサイト保守）を含む包括契約で、障害発生時にＴＡＣの受付窓口に電話やメールなどで連絡をすれば、現地にＴＡＣ側の保守員を派遣して障害復旧対応を行ってくれる。この場合、保守費用は有償保守契約の中に含まれており、スポット費は発生しない。
（２）オンコール契約：障害発生時に電話やメールなどでのオンコール受付を行い、障害解決のためのサポートを行う契約である。この場合、障害対応は顧客側で行うが、障害箇所の特定や交換すべき部品・基盤などの指示は電話やメールなどで受けることができる。ところが、オンコール契約において、顧客側で障害対応を行わずにＴＡＣ側に一時的な障害復旧対応（スポット対応）を依頼する場合、その都度、スポット費を支払わなければならない。

このようなオンコール契約では、事前に正確なスポット費の見積もりを行うことが難しいという問題がある。また、保守を依頼した顧客は、通常は保守業者による障害対応完了後の費用請求の連絡までいくら掛かるか不安になる。このように、顧客はできるだけ正確な費用の見積もり額を事前に知りたいという強い要望を持っている。一般的な家電製品やパソコンおよびプリンタなどの汎用品の場合は、修理内容が限られており、また伝送装置のように障害が他の装置に波及することもないので、修理に掛かる費用の見積もりは比較的正確に行うことができる。例えば顧客情報や部品在庫情報などを用いて修理費用や修理日程を求める技術が検討されている（例えば特許文献１参照）。

特開２００４−２４０６７３号公報

ところが、ネットワーク接続された伝送装置に障害が発生した場合は、装置の種類や障害部位、ネットワーク障害の波及範囲によって様々なケースがあり、復旧作業に要する項目は多岐に渡り、正確な保守費用の見積もりが難しいという問題がある。特に伝送装置の場合はネットワークで相互に接続されているため、障害波及範囲の有無や保守員の増派の有無などの判断を行う必要もあり、顧客から障害発生のオンコールを受け付けた時点で迅速に保守費用を見積ることは難しい。このため、障害の復旧を依頼した顧客は、保守業者による障害対応完了後の費用請求まで待たなければならないという問題がある。さらに、事後請求は、顧客側の想定金額を大幅に超過する場合があり、この場合は顧客側のコンセンサスを得ることが難しく、顧客とのトラブルに発展する恐れもある。

顧客は、伝送装置の安定的な運用および運用費用や保守費用の経済性だけでなく、事後精算による費用リスクの低減を望んでいる。そして、このような顧客は、突発的に発生する障害に対するオンサイト対応スポット保守費用の事前見積り提示額と保守後に提示される請求額との差ができるだけ少ないことを期待している。さらに、顧客は、保守後の迅速な費用明細書の発行を望んでいるが、保守員の作業時間の把握に時間が掛かり、迅速に費用明細書を作成できないという問題がある。特に単金が異なる時間内作業と時間外作業とが保守員毎に複雑に組み合わさっているので、費用明細書の作成に時間が掛かるという問題がある。

上記課題に鑑み、本発明の目的は、装置障害の発生時に保守員が現地で障害の復旧作業を行う場合のオンサイト保守スポット費の見込み金額の算出および障害の波及範囲の有無や保守員の増員の有無などの判別、保守完了後の費用明細書の作成などを行うことができる保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法を提供することである。

請求項１に係る発明は、伝送装置の障害発生時に保守費用の見積もりを行う保守費見積／明細作成用サーバ装置において、情報を入出力するマンマシンインターフェース手段と、障害対応終了後に前記マンマシンインターフェース手段から入力される障害対応内容を含む障害情報を過去の障害履歴として記憶する記憶手段と、オンコール受付時に前記マンマシンインターフェース手段から入力された検索キーワードに応じて前記記憶手段に記憶された過去の障害情報を検索する検索手段と、前記検索手段の検索結果に基づいて保守費用の見積額を求め、前記マンマシンインターフェース手段に出力する見積り手段とを備えることを特徴とする。

請求項２に係る発明は、請求項１に記載の保守費見積／明細作成用サーバ装置において、前記伝送装置は、他の伝送装置と互いにネットワークで接続され、前記マンマシンインターフェース手段から入力される障害情報は、前記ネットワーク接続された他の伝送装置への障害の波及範囲に関する情報を含み、前記見積り手段は、前記検索手段が前記検索キーワードに基づいて検索した過去の障害情報に障害の波及範囲に関する情報が含まれている場合に障害の波及箇所や保守員の増員数の情報を求め、前記マンマシンインターフェース手段に出力することを特徴とする。

請求項３に係る発明は、請求項１または２に記載の保守費見積／明細作成用サーバ装置を有する保守費見積／明細作成システムにおいて、前記保守費見積／明細作成用サーバ装置に通信回線を介して接続される携帯端末を設け、前記携帯端末は、日時情報を出力する時計手段と、複数の作業項目を選択するための操作手段と、前記操作手段で選択された前記作業項目情報と選択時点に前記時計手段が出力する日時情報とを前記通信回線を介して前記保守費見積／明細作成用サーバ装置に送信する送信手段とを備え、前記保守費見積／明細作成用サーバ装置は、予め設定された作業時間単価を示す単金テーブルと、前記携帯端末から送信される前記作業項目情報および前記日時情報を受信する受信手段と、前記受信手段が受信した前記作業項目情報および前記日時情報から作業時間を求め、前記作業時間と前記単金テーブルとを用いて費用明細書を作成して前記入出力手段に出力する明細書作成手段とを更に備えることを特徴とする。

請求項４に係る発明は、請求項３に記載の保守費見積／明細作成システムにおいて、前記携帯端末の前記送信手段および前記保守費見積／明細作成用サーバ装置の前記受信手段は、電子メールによって前記作業項目情報および前記日時情報を送受信することを特徴とする。

請求項５に係る発明は、伝送装置の障害発生時に保守費用の見積もりを保守費見積／明細作成用サーバ装置で実行する保守費見積／明細作成方法において、障害対応終了後に障害対応内容を含む障害情報を入力して過去の障害履歴として記憶媒体に記憶する記憶手順と、オンコール受付時に検索キーワードを入力して前記記憶媒体に記憶された過去の障害情報を検索する検索手順と、前記検索手順の検索結果に基づいて保守費用の見積額を求める見積り手順とを備えることを特徴とする。

請求項６に係る発明は、請求項５に記載の保守費見積／明細作成方法において、前記伝送装置は相互にネットワークで接続され、前記記憶手順で前記記憶媒体に記憶する障害情報は、前記ネットワーク接続された他の装置への障害の波及範囲の情報を含み、前記見積り手順は、前記検索手順の検索結果に障害の波及範囲に関する情報が含まれている場合に障害の波及箇所や保守員の増員数を推定することを特徴とする。

請求項７に係る発明は、請求項５または６に記載の保守費見積／明細作成方法において、前記保守費見積／明細作成用サーバ装置に通信回線を介して接続される携帯端末を使用し、前記携帯端末は、操作部材によって複数の作業項目のいずれかが選択された時点の日時情報と選択された作業項目情報とを前記保守費見積／明細作成用サーバ装置に送信する送信手順を実行し、前記保守費見積／明細作成用サーバ装置は、前記携帯端末から送信される前記作業項目情報および前記日時情報を受信する受信手順と、前記受信手順で受信した前記作業項目情報および前記日時情報から作業時間を求め、前記作業時間と予め設定された作業時間単価を示す単金テーブルとを用いて費用明細書を作成する明細書作成手順とを更に実行することを特徴とする。

請求項８に係る発明は、請求項７に記載の保守費見積／明細作成方法において、前記作業項目情報および前記日時情報は電子メールによって前記携帯端末から前記保守費見積／明細作成用サーバ装置に送信されることを特徴とする。

本発明に係る保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法は、装置障害の発生時に保守員が現地で障害の復旧作業を行う場合のオンサイト保守スポット費の見込み金額の算出および障害の波及範囲の有無や保守員の増員の有無などの判別、保守完了後の費用明細書の作成などを行うことができる。特に、顧客からのオンコール受付時に過去に発生した類似障害に対する障害対応履歴を記録した履歴データを参照し、精度の高い保守費用の見込み金額を顧客に事前提示を行なうことができる。また、過去の障害履歴情報をデータベースに蓄積するので、障害の波及がある場合は保守員の増派提案や案内もオンコール受付時に行うことができる。さらに、保守員は障害対応に関する情報を携帯端末からサーバ装置に逐次送信し、サーバー装置は携帯端末の送信情報から実請求金額の計算と費用明細書の作成をリアルタイムで行なうことができるので、費用明細書や請求書を迅速に顧客側に提示することができる。

保守費見積／明細作成システム１００全体の一例を示す図である。 ＤＢ１５３の障害対応履歴データ２０７の一例を示す図である。 モニタ１５２の画面に表示された検索結果の一例を示す図である。 各付加情報の表示例を示す図である。 サーバ装置１０１側の構成例を示す図である。 携帯端末１０２の構成例を示す図である。 携帯端末１０２の表示部３０５の出動時の画面例を示す図である。 オンコール受付から出動までの処理の流れを示すフローチャートである。 出動から費用明細書作成および保守対応終了までの処理の流れを示すフローチャートである。 オンサイト保守スポット費用明細書の一例を示す図である。 時間内定義／時間外定義と保守時間のパターン例を示す図である。 ＤＢ１５３の単金マスターテーブル２０８の一例を示す図である。 保守時間の算出および費用明細書作成処理の一例を示すフローチャートである。

以下、本発明に係る「保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法」の実施形態について図面を用いて詳しく説明する。

尚、各実施形態で説明する障害対応方法は、従来技術で説明した保守契約種類の中のオンコール契約を前提とする。先に説明したように、オンコール契約では、障害発生時に電話やメールなどでの受付を行い、障害箇所の特定や交換すべき部品や基盤などの指示を電話やメールなどで受けることができる。この場合、保守作業は顧客側で行うのが基本であるが、障害復旧作業を顧客側で行わずにＴＡＣ側（保守会社側）にスポット対応を依頼することができる。但し、その都度、オンコール契約費用とは別にスポット費が発生する。

以降の実施形態で説明する保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法では、装置障害が発生した時にＴＡＣ側の保守員が現地で障害復旧作業を行う場合のオンサイト保守スポット費の見込み金額の算出を精度良く行うことができる。これにより、保守前に精度の高いスポット費の見積り額を顧客側に提示できるので、顧客は安心してＴＡＣ側にスポット対応を依頼することができる。同時に、障害の波及範囲の有無や保守員の増員の有無などの情報も顧客側に提示するので、顧客は障害が波及する場所を知ることができ、安定したネットワーク運営を行うことができる。さらに、保守員の作業状況に応じた費用明細書の作成をリアルタイムで行い、保守完了後に迅速に顧客側に提示することができる。

［保守費見積／明細作成システム］
先ず、本実施形態に係る保守費見積／明細作成システム１００の一例を図１に示す。図１において、保守費見積／明細作成システム１００は、装置障害発生時に保守費用の見積もりを行うための保守費見積／明細作成用のサーバ装置１０１と、サーバ装置１０１に通信回線で接続可能な携帯端末１０２とを基本とするシステムである。図１では、通信回線の例として携帯電話会社が提供する携帯電話網を利用し、保守員が所持する携帯端末１０２は携帯電話会社が提供する各地に配置された基地局（ＢＳ）１６３から１６５に無線で接続され、携帯電話会社のアクセスサーバ１６２およびネットワーク１６１を介してサーバ装置１０１に接続される。ここで、携帯端末１０２は、専用の端末装置であってもよいが、一般の携帯電話に専用のアプリケーションをダウンロードして動作させるものとする。

保守費見積／明細作成用のサーバ装置１０１は、入力部１５１と、モニタ１５２と、データベース（ＤＢ）１５３とを有し、ネットワーク１６１に接続されている。入力部１５１は、例えばキーボードやマウスなどが用いられ、オペレータによって操作される。モニタ１５２は、例えば液晶ディスプレイなどが用いられ、サーバ装置１０１が出力する様々な情報を表示する。ＤＢ１５３は、障害対応終了後にオペレータが入力部１５１から入力する障害対応内容を含む障害情報を過去の障害履歴として記憶する。尚、本実施形態では、ある程度の十分な量の過去の障害情報がＤＢ１５３に蓄積されているものとする。

ここで、図１に示す入力部１５１とモニタ１５２は、サーバ装置１０１のマンマシンインターフェース手段に対応する。また、ＤＢ１５３はサーバ装置１０１の記憶手段に相当する。

図１において、オペレータは、顧客から電話１５４で障害発生の連絡を受け付ける。尚、インターネット等のネットワーク１６１を介して顧客から電子メールで受け付けてもよい。或いは、障害受付のための特定のＵＲＬに設けたウェブサイト上のＷｅｂサーバにアクセスして、専用ホームページ上で障害発生の連絡を受け付けても構わない。この場合は、サーバ装置１０１はメール機能や専用ホームページのＷｅｂサーバ機能を有し、オペレータはサーバ装置１０１を操作して顧客からの障害発生の連絡を知ることができる。或いは、図１に示すように、メールサーバ１７１をサーバ装置１０１とは別に設けても構わないし、同様にＷｅｂサーバを別に設けても構わない。いずれの場合でも、サーバ装置１０１は、顧客からの電子メールや携帯端末１０２からの電子メールを受け取ることができる。或いは、サーバ装置１０１は、顧客や携帯端末１０２から専用ホームページにアクセスした情報を受け取ることができる。

このようにして、電話または電子メールや専用ホームページへのアクセス情報で障害発生の連絡を受けたオペレータは、顧客に障害状況を聞き合わせると共に、検索キーワード（以降、検索キーと称する）を用いてサーバ装置１０１のＤＢ１５３に記憶されている過去の障害情報を検索する。
［過去の障害対応履歴を記憶するＤＢ１５３の検索］
過去の障害対応履歴を記憶するＤＢ１５３の記憶内容の一例を図２に示す。図２において、過去の障害対応履歴は、例えば管理番号（Ｎｏ），顧客名，顧客コード，障害発生日，障害が発生した局名，装置名，架番号（Ｎｏ），シェルフ名／シェルフ番号（Ｎｏ），パッケージ名（ＰＫＧ名），インターフェース名（ＩＦ名），アラーム名などの基本的な情報である。さらに、本実施形態では、障害発生時に障害発生箇所とは異なる局などに障害が波及した場合の障害波及範囲の情報，部品交換やパッケージの交換などの復旧方法の情報，スポット対応に出動した保守員の人数や出動・入局・作業開始・作業終了・退局などの日時およびスポット費用などのスポット対応情報なども付加情報としてＤＢ１５３に記憶されている。

オペレータは、サーバ装置１０１の検索ツールを起動して、入力部１５１から検索キーを入力する。例えば、使用する検索キーは、顧客名または顧客名に予め付与された任意の顧客コードを第一キーとして優先させる。さらに、下記に示す検索情報の少なくとも１つを第二キーとして、過去の障害対応履歴を記憶するＤＢ１５３を検索する。
（第一キーの例）顧客名または顧客コード。
（第二キーの例）装置名、シェルフ名（シェルフ番号）、パッケージ名（ＩＦ盤名など）、アラーム名など。

検索の結果、１件以上の過去の履歴データを検出した場合は、当該履歴データをモニタ１５２の画面に表示する。例えば、第一キーの顧客名：Ａ１（顧客コード：９８７）および装置名：Ｃ１で検索した場合、図３に示すようにモニタ１５２の画面には、ＤＢ１５３に記憶されている顧客名：Ａ１および装置名：Ｃ１の履歴情報のリストが表示される。

尚、モニタ１５２の画面には、付加情報ボタン１、ボタン２、ボタン３も表示され、各履歴情報のリストの詳細な付加情報を見たい場合は、例えばカーソル１５２ａでラジオボタン１５２ｂを選択後、付加情報ボタン１、ボタン２、ボタン３のいずれかを押下する。図３の例では、管理Ｎｏが１２３の履歴情報がラジオボタン１５２ｂで選択されているので、いずれかの付加情報ボタンを押下すると、管理Ｎｏが１２３の履歴情報に関する付加情報が例えば図４に示すようなポップアップウィンドウに表示される。尚、請求ボタン４は、保守終了時に費用明細書を出力するためのボタンで、後で詳しく説明する。

図４（ａ）に示したウィンドウＡは、図３で付加情報ボタン１を押下した場合に表示される付加情報で、障害発生局のシステム構成、障害ＰＫＧ情報がモニタ１５２の画面に表示される。例えば、図３のウィンドウＡには、Ｂ１局のＣ１装置のＤ１シェルフが描画され、障害が発生したＥ１パッケージ（ＰＫＧ）の位置が具体的に示されている。

図４（ｂ）に示したウィンドウＢは、図３で付加情報ボタン２を押下した場合に表示される付加情報で、障害が発生したネットワーク構成、自局以外への障害の波及範囲、発生原因、復旧方法などがモニタ１５２の画面に表示される。例えば、ウィンドウＢには、ＸリングとＹリングの間に位置するＢ１局で障害が発生し、ＸリングのＢ３局に障害が波及したことを示している。また、障害原因はＩＦ盤の光モジュール不良で、復旧方法はＩＦ盤の交換であることがわかる。

図４（ｃ）に示したウィンドウＣは、図３で付加情報ボタン３を押下した場合に表示される付加情報で、復旧対応に出動した保守員の人数や対応時間および費用などの明細がモニタ１５２の画面に表示される。例えば、ウィンドウＣには、管理Ｎｏ．１２３のオンサイト対応日がＹ３／Ｍ３／Ｄ３で、出動人数が８人であることが示されている。さらに、出動・入局・作業開始・作業終了・退局などの日時情報と、時間内作業の費用および時間外作業の費用と、合計のスポット費用とが表示されている。

このようにして、ＴＡＣ側のオペレータはオンコール受付時に過去の障害履歴情報を検索することによって、他局への障害波及の可能性や波及範囲およびオンサイト対応の保守員の数、さらに復旧対応に必要なスポット費用などを顧客側に即座に回答することができる。尚、上記の検索において、膨大な検索結果がモニタ１５２の画面に表示される場合は、顧客からの通報情報などに応じて検索キーを増やすことによって履歴データの絞り込みを行うことができ、より類似性の高い障害履歴の情報を得ることができる。そして、ＴＡＣオペレータは、検索結果の中から今回申告された障害情報と比較を行い、一番類似性が高いと思われる過去の履歴データを選択し、その履歴データの付加情報から復旧対応に必要なスポット費用を概算見積額としてその場で回答する。或いは、サーバ装置１０１で類似性を自動的に計算して、類似性の高い履歴データから順番にモニタ１５２に表示するようにしてもよい。類似性の自動判別は、例えばアラーム名やＩＦ名などの各情報に重み付けを行うことにより実現可能である。例えば同一アラーム名の場合は１０ポイント、同一ＩＦ名の場合は６ポイントのようにポイントを加算して最も大きいポイントの履歴データの類似性が高いと判別する。この場合、同じポイント数の場合は、最新の発生日の履歴データを選択するようにする。これにより、単金データが変更になった場合などにおいて、古い変更前の単金データで見積額を提示することを防止できる。

ここで、類似する履歴データが複数ある場合に、上記のようにして１つの履歴データを選択すれば、その履歴データのスポット費用がそのまま顧客に回答する見積額となる。或いは、類似する履歴データが複数ある場合に、１つの履歴データを選択せずに、複数の履歴データのスポット費用を演算して見積額を求めるようにしてもよい。演算例として、複数のスポット費用の平均額を見積額として求めたり、上記で説明した類似度でスポット費用を重み付けして見積額を求めるなどの処理を行う。

このようにして、精度の高いスポット費用の見込み額を顧客側にオンコール受付時に即座に回答することができる。また、必要な保守員の数や、障害の波及範囲や過去の障害の原因および復旧方法なども回答することができる。

ここで、検索結果がゼロ件の場合は、「類似する履歴データ無し」などのメッセージをモニタ１５２の画面に表示する。そして、顧客に対して「新規障害ケース」の旨、回答するものとする。この場合は、新規の障害情報と対応履歴、復旧費用などの情報が新規データとしてＤＢ１５３に追加登録され、ＤＢ１５３には履歴情報が蓄積されていく。

［サーバ装置１０１］
図１のサーバ装置１０１の構成例を図５に示す。尚、図１と同符号のものは同じものを示す。図５において、サーバ装置１０１は、サーバ制御部２０１と、検索部２０２と、概算見積部２０３と、ＤＢ更新部２０４と、通信部２０５と、費用明細書作成部２０６とを有する。

サーバ制御部２０１は、予め記憶されたプログラムに従ってサーバ装置１０１全体の動作を制御する。例えば、入力部１５１から入力される情報に応じて必要な情報をモニタ１５２の画面に表示したり、ＤＢ１５３に対して情報を読み書きする。

検索部２０２は、先に説明したように、検索キーワードを用いてＤＢ１５３に記憶されている過去の履歴データを検索する。

概算見積部２０３は、過去の障害履歴データからスポット費用の概算見積を行う。尚、過去の障害履歴データのスポット費用をそのまま顧客に回答する場合は、特別な見積処理を行う必要はないが、類似する履歴データが複数ある場合は、先に説明したように、類似度の高いものや演算処理によって見積額を求めてもよい。

ＤＢ更新部２０４は、障害復旧の保守対応が終了する毎に、新たな障害情報としてＤＢ１５３に追加登録する。

通信部２０５は、顧客からの電子メールによる受付を行う。尚、図１のメールサーバ１７１が別に配置されている場合は、メールサーバ１７１を経由して顧客からの電子メールを受け付ける。

費用明細書作成部２０６は、携帯端末１０２を保持する保守員から作業に関する日時情報を逐次連絡を受けてリアルタイムでスポット費用の明細書を作成する。尚、保守員からの連絡方法については後で詳しく説明する。

図５において、ＤＢ１５３は、障害対応履歴データ２０７と、単金マスターテーブル２０８とを有する。尚、これらは物理的に別の記憶媒体に記憶してもよいし、同じ記憶媒体の異なる記憶領域に記憶してもよい。

障害対応履歴データ２０７は、ＤＢ１５３内の記憶領域の一部で、過去の障害データを保持する。

単金マスターテーブル２０８は、ＤＢ１５３内の記憶領域の一部で、顧客毎に予め決められた保守員の時間単価を示す情報で、例えば時間外単金および時間内単金と、時間外および時間内の時間定義を示す情報が記憶されている。

［携帯端末１０２］
図１の携帯端末１０２の構成例を図６に示す。尚、図１と同符号のものは同じものを示す。図６において、携帯端末１０２は、端末制御部３０１と、時計部３０２と、操作部３０３と、通信部３０４と、表示部３０５とを有する。

端末制御部３０１は、予め記憶されたプログラムに従って携帯端末１０２全体の動作を制御する。例えば、操作部３０３から入力される情報に応じて必要な情報を表示部３０５に表示したり、操作部３０３の操作情報や時計部３０２の日時情報などを通信部３０４を介してサーバ装置１０１に送信する。尚、サーバ装置１０１への送信方法は、電子メールを用いるものとするが、サーバ装置１０１がＷｅｂサーバ機能を有する場合は、通信部３０４を介して特定のＵＲＬに設けたウェブサイト上のサーバにアクセスし、専用ホームページ上に操作情報や日時情報などをアップロードしてサーバ装置１０１に通知する。

時計部３０２は、カレンダー機能や時計機能を提供し、現在日時の情報を端末制御部３０１などに出力する。

操作部３０３は、保守者が電話の発着信や電子メールの送受信などを行うための操作ボタンや表示部３０５に一体化されたタッチパネルを含む。そして、タッチパネルの座標情報により、画面上に表示された操作ボタンの押下を検出する。

通信部３０４は、サーバ装置１０１との間で電子メールの送受信を行ったり、サーバ装置１０１がＷｅｂサーバ機能を有する場合は専用ホームページにアクセスする。

表示部３０５は、液晶モニタなどが用いられ、端末制御部３０１が出力する情報を表示する。特に本実施形態では、保守員の状況をサーバ装置１０１に通知するための操作ボタンが表示され、表示部３０５に一体化された操作部３０３のタッチパネルを用いて、表示部３０５の画面に表示された操作ボタンを操作する。

ここで、携帯端末１０２の表示部３０５に表示される画面例を図７に示す。図７は、保守員が障害復旧に出動した時に携行する携帯端末１０２の表示部３０５に表示される表示画面４０１を示している。表示画面４０１には、管理番号（Ｎｏ）４０２と、出動した保守員の人数４０３と、出動ボタン４０４と、入局ボタン４０５と、作業開始ボタン４０６と、作業終了ボタン４０７と、退局ボタン４０８と、送信ボタン４０９と、クリアボタン４１０とが表示されている。

尚、管理番号：２０１０−０１２３や人数：１人の情報は、保守員がオペレータから電話連絡または電子メールなどで出動指示を受けた際に入力される。また、これらの情報は保守員が手動で携帯端末１０２に設定してもよいし、電子メールの場合は携帯端末１０２が受信した電子メールから自動的に情報を抽出してもよい。ここで、保守員が手動で情報を入力する場合は、表示画面４０１の管理番号４０２と人数４０３の部分を指でタッチして入力欄を選択し、携帯端末１０２のテンキーボタン１０２ａで数字を入力する。

図７において、出動ボタン４０４、入局ボタン４０５、作業開始ボタン４０６、作業終了ボタン４０７および退局ボタン４０８は、保守員の対応状況を選択するボタンである。例えば保守員は、オペレータから出動指示を受けて障害が発生した現地に出動する時に出動ボタン４０４を押下する。出動ボタン４０４が押下されると、選択マーク４０４ａが画面内で点灯表示される。間違いがなければ送信ボタン４０９を押下する。もし誤って入局ボタン４０５を押下した場合は選択マーク４０５ａが点灯表示されるので、保守員は押し間違えたことがわかる。この場合は、再び出動ボタン４０４を押下すれば、選択マーク４０５ａが消灯表示に変わり、選択マーク４０４ａが点灯表示される。また、保守作業が終了した時や出動前に前の情報（管理番号や人数など）が残っている場合は、クリアボタン４１０を押下すると全ての情報がリセットされる。

このようにして、保守員は対応状況に応じて該当するボタンを押下して押下したボタンの種類を示す情報と、押下時の日時情報をサーバ装置１０１に通知する。例えば、図７の場合は、出動ボタン４０４を押下した後、送信ボタン４０９が押されると８月１１日の１５時３０分に出動したことが電子メールなどでサーバ装置１０１に通知される。同様に、障害が発生している局へ入局または退局した情報とその日時情報、障害復旧作業を開始または終了した情報とその日時情報などの情報が電子メールなどでサーバ装置１０１に通知される。尚、送信ボタン４０９を設けずに出動ボタン４０４などの押下時に情報をサーバ装置１０１に送信するようにしてもよいが、誤操作を考慮して直前の送信情報を破棄する通知をサーバ装置１０１に送信するための取り消しボタンを設ける必要である。もちろん図７の場合にも送信後に間違いに気づいた場合の対策として、取り消しボタンを設けてもよい。

［オンコール受付から出動までの処理］
次に、オンコール受付から出動までの処理の流れについて図８のフローチャートを用いて説明する。図８のフローチャートは、顧客側と、保守会社のコールセンター側（ＴＡＣ側）と、保守員側とに分けて描かれている。以下、顧客側、ＴＡＣ側、保守員側の各処理を複合して時系列順に説明する。

（ステップＳ１０１）先ず、顧客がＴＡＣに障害の連絡を行うための障害オンコールを電話または電子メール或いは専用ホームページなどで行う。

（ステップＳ２０１）ＴＡＣのオペレータは、顧客からの障害オンコールを受け付ける。この時、顧客名あるいは顧客番号を確認する。

（ステップＳ１０２）顧客は、障害の具体的な内容を説明する。例えば「Ｂ１局からＬＯＦ（Ｌｏｓｓ Ｏｆ Ｆｌａｍｅ）のアラーム通報があった」などである。

（ステップＳ２０２）ＴＡＣのオペレータは、顧客が説明する障害の具体的な内容をヒアリングする。この時、オペレータはヒアリングを行いながら、後で使用する検索キーワードをヒアリング内容から抽出する。

（ステップＳ２０３）ＴＡＣのオペレータは、サーバ装置１０１の検索ツールにログインして、ＤＢ１５３に記憶されている過去の障害情報を検索する準備を行う。

（ステップＳ２０４）ＴＡＣのオペレータは、顧客名や顧客コードおよび顧客から説明を受けた障害内容から抽出した検索キーワードを用いて、ＤＢ１５３に記憶されている過去の障害情報から類似する障害情報をサーチする。

（ステップＳ２０５）サーバ装置１０１の検索ツールで類似障害が検出されたか否かを判別する。そして、類似障害が検出された場合はステップＳ２０６に進み、類似障害が検出されなかった場合はステップＳ２０８に進む。尚、この判別処理は、サーバ装置１０１のソフトウェアで自動的に行ってもよいし、オペレータがモニタ１５２の画面に表示される検索結果を見てマニュアルで判断してもよい。

（ステップＳ２０６）サーバ装置１０１は、検索ツールで検出された類似障害の情報からスポット対応に関する概算見積額を算出する。尚、サーバ装置１０１が行うスポット費の概算見積り処理は、先に説明したように、例えば類似障害の検出結果が１件の場合はそのまま当該案件のスポット費の概算見積額とし、複数件が検出された場合は、先に説明したような類似度や演算処理などによってスポット費の概算見積額を求める。

（ステップＳ２０７）ＴＡＣのオペレータは、モニタ１５２の画面に表示されたサーバー装置１０１が求めたスポット費の概算見積額を顧客に回答する。尚、必要であれば印刷して顧客にＦＡＸまたは郵送したり、電子メールで送信してもよい。

（ステップＳ１０３）顧客は、ＴＡＣ側からスポット費の概算見積額の回答を受ける。そして、顧客は、概算見積額に納得した上でＴＡＣにスポット対応を正式に依頼する。尚、概算見積額が予想外に高い場合は、この時点で顧客はスポット対応を断ったり、費用を安くする方策をＴＡＣのオペレータに相談することができる。

（ステップＳ２０８）顧客から正式なスポット対応の依頼を受けたＴＡＣのオペレータは、保守員のスケジュールなどを検討して障害が発生した局（例えばＢ１局）に保守員が入局する予定日時を回答する。尚、本実施形態では詳細な説明は行わないが、保守員のスケジュールは、別途、サーバ装置１０１のＤＢ１５３で管理されているものとし、オペレータは即座に入局予定日時（保守員の数を含めてもよい）を回答できる。

（ステップＳ１０４）顧客は、ＴＡＣ側から入局予定日時の回答を受ける。

（ステップＳ２０９）ＴＡＣのオペレータは、今回の障害対応案件についてサーバ装置１０１から唯一の管理番号を取得して起票を行う。尚、起票によって、サーバ装置１０１は、ＤＢ１５３のデータベース上に新たな障害情報として記憶することができる。ここで、先のステップＳ２０５で類似障害が検出されなかった場合についても同様に起票が行われ、新たな障害情報がＤＢ１５３に蓄積される。

（ステップＳ２１０）ＴＡＣのオペレータは、障害が発生した局に派遣する保守員に電話やＦＡＸ或いは電子メールで新たに取得した管理番号を通知し、保守員に現地への出動を指示する。尚、指示を受けるまで保守員は保守会社の事務所などで待機しており、管理番号の通知や出動指示は保守会社の事務所などに連絡される。或いは、携帯端末１０２を保守員が常に所持して、携帯端末１０２に直接、管理番号の通知や出動指示を電話や電子メールなどで行うようにしても構わない。これにより、別の障害場所で作業を終えた保守員を連続して新たな障害場所に派遣することができる。

（ステップＳ３０１）ＴＡＣ側から管理番号と出動指示を受けた保守員は、携帯端末１０２を所持して指示された現地（例えばＢ１局など）へ出動する。

以上、図８のフローチャートを用いて、オンコール受付から出動までの処理の流れについて説明した。

［現地での障害対応時の処理から障害対応に関する費用明細書の作成処理］
次に、現地での障害対応時の処理から障害対応に関する費用明細書の作成処理などについて、図９のフローチャートを用いて説明する。尚、図９のフローチャートは図８のフローチャートの続きを示したもので、ステップＳ２１０とステップＳ３０１はわかり易いように図８と重複して描いてある。また、図８と同様に、顧客側と、ＴＡＣ側と、保守員側とに分けて描いてある。以下、顧客側、ＴＡＣ側、保守員側の各処理を複合して時系列順に説明する。

尚、保守員が携行する携帯端末１０２に搭載されたオンサイト通報用のアプリケーションには、特定のメール送信先（本実施例の場合は、図１のＴＡＣ側のメールサーバ１７１の特定のメールアドレス、或いはサーバ装置１０１のメール機能を使用する場合はサーバ装置１０１のメールアドレス）が携帯端末１０２にプリセットされている。そして、保守員がオンサイト通報用のアプリケーションを起動して、後に説明する送信ボタン４０９が押下されることにより、ネットワークを介してＴＡＣ側のメールサーバを経由してサーバ装置１０１に、或いは直接、サーバ装置１０１に所定の情報が送信される。そして、サーバ装置１０１は受信したメール情報が携帯端末１０２のオンサイト通報用のアプリケーションから送信された情報である場合には、ＤＢ１５３の障害対応履歴データ２０７に起票されたデータに保守員の対応情報が書き込まれる。尚、携帯端末１０２から送信される情報には出動前にオペレータから通知された管理番号が付加されているので、これにより、複数の障害対応を行っている場合でも、サーバ装置１０１はどの障害対応に対する情報であるかを判別することができる。

（ステップＳ３０２）先ず、障害が発生した現地へ出動する時点で（出動時）、保守員は携帯端末１０２の出動ボタン４０４を押下し、サーバ装置１０１に出動情報と日時情報とを通知する。例えば、「出動：２０１０／８／１５，８：１０」のようにテキストデータやバイナリデータで携帯端末１０２からサーバ装置１０１に送信される。尚、図９では現地で通知することをオンサイト通報と称している。

（ステップＳ３０３）現地に到着した保守員は、障害が発生した局（例えばＢ１局）に入った時点で（入局時）、携帯端末１０２の入局ボタン４０５を押下し、サーバ装置１０１に入局情報と日時情報とを通知する。携帯端末１０２からサーバ装置１０１に送信される情報は、出動時と同様に、例えば「入局：２０１０／８／１５，８：５５」となる。

（ステップＳ３０４）入局した保守員が障害が発生した装置（例えばＣ１装置）の障害復旧作業を開始する時点で（作業開始時）、保守員は携帯端末１０２の作業開始ボタン４０６を押下し、サーバ装置１０１に作業開始情報と日時情報とを通知する。携帯端末１０２からサーバ装置１０１に送信される情報は、出動時と同様に、例えば「作業開始：２０１０／８／１５，９：１５」となる。

（ステップＳ３０５）保守員は、障害復旧作業を行う。障害復旧作業は、例えば不良部品の交換や、不良基盤・パッケージなどの交換を行う。

（ステップＳ３０６）保守員は、障害復旧作業を終了した時点で（作業終了時）、携帯端末１０２の作業終了ボタン４０７を押下し、サーバ装置１０１に作業終了情報と日時情報とを通知する。携帯端末１０２からサーバ装置１０１に送信される情報は、出動時と同様に、例えば「作業終了：２０１０／８／１６，３：３０」となる。

（ステップＳ３０７）復旧作業を終了した保守員が局から出る時点で（退局時）、携帯端末１０２の退局ボタン４０８を押下し、サーバ装置１０１に退局情報と日時情報とを通知する。携帯端末１０２からサーバ装置１０１に送信される情報は、出動時と同様に、例えば「退局：２０１０／８／１６，３：４５」となる。

（ステップＳ２１１）サーバ装置１０１側では、ステップＳ３０２からステップＳ３０７までの間に逐次、携帯端末１０２から通知される保守員の状況を示す情報と日時情報とから、作業時間を計算して費用明細書を自動的に作成する。ここで、サーバ装置１０１は、保守員の携帯端末１０２から退局日時通知を受けたタイミングで費用明細書を自動的に作成する。或いは、ＴＡＣ側のオペレータが保守員からの復旧完了報告を受けたときに、サーバ装置１０１に手動で費用明細書の作成を指令しても構わない。いずれの場合でも、通知されたオンサイト対応の日時情報を基に実費用を計算して迅速に費用明細書を顧客側に送付することができる。尚、サーバ装置１０１が行う作業時間の計算と費用明細書の作成方法については後で詳しく説明する。

（ステップＳ２１２）ＴＡＣのオペレータは、障害対応の完了報告と共に、サーバ装置１０１が作成したスポット対応の費用明細書を顧客側にＦＡＸ或いは電子メールなどで送付する。

尚、複数の障害対応を同時に行っている場合、ＴＡＣのオペレータは、保守員からオンサイト保守スポット対応の完了報告時または退局通知時に通知される管理Ｎｏを検索キーとして障害対応履歴データ２０７を検索して、図３に示したような今回の障害データをモニタ１５２の画面に表示させることができる。そして、例えばオペレータは付加情報ボタン３を押下して図４（ｃ）のウィンドウＣを開いて、今回の保守スポット費を確認することができる。さらに、図３の請求ボタン４を押下すれば、ウィンドウＣに示すフォーマットの帳票が自動的にサーバ装置１０１のプリンタ（不図示）などから出力される。或いは、請求ボタン４を押下することにより、サーバ装置１０１から顧客側に費用明細書の帳票をＦＡＸまたは電子メールで自動的に送付されるようにしてもよい。

（ステップＳ１０５）顧客側は、ＴＡＣ側から障害対応の完了報告とスポット対応の費用明細書を受領する。ここで、オンサイト保守のスポット費用明細書の一例を図１０に示す。図１０の費用明細書には、Ｂ１局のＣ１装置の障害対応作業費として、２３０，０００円が見積額として示されている。そして、詳細内容として保守要員数や時間内費用および時間外費用などの費用明細書が記載されている。図１０の例では、保守要員数が６名で、時間内費用が１２時間、時間外費用が６時間、そして明細書に記載された顧客のＡ１株式会社向けの単金（時間内：１０，０００円、時間外：１５，０００円）に応じて、時間内費用が１２０，０００円、時間外費用が９０，０００円、交通費が２０，０００円で、合計が２３０，０００円（消費税別）となる。尚、交通費は、保守員が携帯端末１０２からリアルタイムでサーバ装置１０１に通知するようにしてもよいが、迅速に費用明細書を作成するために、派遣地域に応じた交通費を予め決めておくのが好ましい。

このように、保守員が保守を終了した時点（厳密には保守員がサーバ装置１０１に退局日時を通知した時点）で即座にスポット費用明細書が作成され、顧客側に提示することができる。

図９において、費用明細書を作成した後の処理について続けて説明する。

（ステップＳ２１３）ＴＡＣのオペレータは、障害対応の完了報告とスポット費用明細書を担当営業に連絡し、担当営業から費用明細書に基づく正式な請求書を顧客側に郵送またはＦＡＸ或いは電子メールなどで送付する。

（ステップＳ１０６）顧客側は、ＴＡＣ側から正式なオンサイト保守のスポット費用の請求書を受領する。

（ステップＳ１０７）顧客側は、ＴＡＣ側に請求されたスポット費用の支払いを行い、今回の障害に対する顧客側の対応は終了する。

（ステップＳ３０６）現地から保守会社の事務所に戻った保守員は、今回の障害内容（障害箇所や復旧方法あるいは障害波及範囲などの詳細な情報）をＴＡＣのオペレータに事後報告し、今回の障害に対する保守員の対応は終了する。

（ステップＳ２１４）ＴＡＣのオペレータは、保守員から報告された今回の障害対応の内容（図２で説明した各項目）をサーバ装置１０１の入力部１５１から入力し、ＤＢ１５３の障害対応履歴２０７に追加登録を行う。以上で、今回の障害に対するＴＡＣ側の対応は終了する。尚、追加登録された情報は、次のオンコール受付時の類似障害の検索時に使用される。

［作業時間の計算と費用明細書の作成方法］
次に、サーバ装置１０１が行う作業時間の計算と費用明細書の作成方法について詳しく説明する。図１１は、保守員の作業時間のパターン例を示した図である。ここで、保守員の作業時間は、時間外と時間内とがあり、単金が異なる。先に説明した図１０の費用明細書の例では、時間内単金が１０，０００円、時間外単金が１５，０００円である。また、契約している会社によって時間内単金および時間外単金を適用する時間範囲が異なる。これらの情報は、顧客との契約時などに、単金マスターテーブル２０８としてＤＢ１５３に記憶される。図１２は、単金マスターテーブル２０８の一例を示した図である。図１２の例では、顧客コード：１２３の会社は、時間内単金が１０，０００円、時間外単金が１５，０００円であるが、顧客コード：２３４の会社は、時間内単金が２０，０００円、時間外単金が３０，０００円である。また、図１２では、時間外の時間範囲も会社によって異なり、顧客コード：１２３の会社は、時間外定義（Ｓ−Ｅ）が１７：００−８：００、顧客コード：２３４の会社は、時間外定義（Ｓ−Ｅ）が１９：００−９：００である。ここで、Ｓは時間外の開始時刻を示し、Ｅは時間外の終了時刻を示す。例えば１８：００の場合、顧客コード：１２３の会社は時間外単金が適用されるが、顧客コード：２３４の会社は時間内単金が適用される。また、本実施形態では、費用を計算する際の時間管理は保守員の入局または退局の時間で行うものとする。

例えば図１１において、保守Ａは保守員が時間内に入局して同じ時間内に退局する場合を示し、保守Ｂは保守員が時間内に入局して次の時間外に退局する場合を示し、保守Ｃは保守員が時間外に入局して同じ時間外に退局する場合を示している。また、保守Ｄは保守員が時間外に入局して次の時間内に退局する場合を示し、保守Ｅは保守員が時間内に入局して次の時間外を跨いでその次の時間内に退局する場合を示している。このように、保守員が入局する日時および対局する日時に応じていろいろなパターンが考えられるので、スポット費用を計算する際に場合分けを行う必要がある。尚、図１１において、先に説明したように、Ｓは時間外の開始時刻を示し、Ｅは時間外の終了時刻を示している。

次に、図９のステップ２１１で説明したサーバ装置１０１が行う作業時間の計算と費用明細書の作成の流れについて、図１３のフローチャートを用いて説明する。尚、図１３のフローチャートは、図１１の保守Ａから保守Ｅに対応する処理で、図１１以外のパターン（例えば数日に亘る保守作業や中断が入る場合など）についても図１３と同様にフローチャートを作成することができる。

以下、図１３のフローチャートに従って順番に説明する。尚、図１３において、先に説明したように、Ｓは時間外の開始時刻を示し、Ｅは時間外の終了時刻を示している。

（ステップＳ４０１）サーバ装置１０１は、携帯端末１０２から通知される入局日時と、単金マスターテーブル２０８に記憶されている該当する顧客の時間外定義（Ｓ）とを比較して、時間内入局であるか時間外入局であるかを判別する。時間内入局である場合はステップＳ４０２に進み、時間外入局である場合はステップＳ４０３に進む。

（ステップＳ４０２）サーバ装置１０１は、携帯端末１０２から通知される退局日時と、単金マスターテーブル２０８に記憶されている該当する顧客の時間外定義（Ｅ）とを比較して、時間内退局であるか時間外退局であるかを判別する。時間内退局である場合はステップＳ４０４に進み、時間外退局である場合はステップＳ４０５に進む。

（ステップＳ４０３）ステップＳ４０２と同様に、サーバ装置１０１は、携帯端末１０２から通知される退局日時と、単金マスターテーブル２０８に記憶されている該当する顧客の時間外定義（Ｅ）とを比較して、時間内退局であるか時間外退局であるかを判別する。時間内退局である場合はステップＳ４０８に進み、時間外退局である場合はステップＳ４０９に進む。

（ステップＳ４０４）サーバ装置１０１は、携帯端末１０２から通知される退局日時と先に通知された入局日時とを比較して、翌日に跨っているか否かを判別する。翌日に跨っている場合はステップＳ４０６に進み、翌日に跨っていない場合はステップＳ４０７に進む。

（ステップＳ４０５）この場合は、時間内入局して次の時間外退局のパターン（図１１の保守Ｂのパターン）に該当するので、サーバ装置１０１は、時間外定義（Ｓ）から保守Ｂの入局時間を引いた時間内単金に相当する時間と、保守Ｂの退局時間から時間外定義（Ｓ）を引いた時間外単金に相当する時間とを求める。そして、時間内単金に相当する時間に時間内単金を掛けた金額と、時間外単金に相当する時間に時間外単金を掛けた金額とを加算して実費用を求める。

（ステップＳ４０６）この場合は、時間内入局して次の時間外を跨いで翌日の時間内に退局するパターン（図１１の保守Ｅのパターン）に該当するので、サーバ装置１０１は、時間外定義（Ｓ）から保守Ｅの入局時間を引いた時間内単金に相当する時間と、時間外定義（Ｅ）から時間外定義（Ｓ）までの時間外単金に相当する時間と、保守Ｅの翌日の退局時間から時間外定義（Ｅ）を引いた翌日の時間内単金に相当する時間とを求める。そして、当日の時間内単金に相当する時間に時間内単金を掛けた金額と、時間外単金に相当する時間に時間外単金を掛けた金額と、翌日の時間内単金に相当する時間に時間内単金を掛けた金額とを加算して実費用を求める。

（ステップＳ４０７）この場合は、時間内入局して同じ時間内に退局するパターン（図１１の保守Ａのパターン）に該当するので、サーバ装置１０１は、保守Ａの退局時間から保守Ａの入局時間を引いた時間内単金に相当する時間を求める。そして、時間内単金に相当する時間に時間内単金を掛けた金額を実費用として求める。

（ステップＳ４０８）この場合は、時間外入局して次の時間内退局のパターン（図１１の保守Ｄのパターン）に該当するので、サーバ装置１０１は、時間外定義（Ｅ）から保守Ｄの入局時間を引いた時間外単金に相当する時間と、保守Ｄの退局時間から時間外定義（Ｅ）を引いた時間内単金に相当する時間とを求める。そして、時間内単金に相当する時間に時間内単金を掛けた金額と、時間外単金に相当する時間に時間外単金を掛けた金額とを加算して実費用を求める。

（ステップＳ４０９）この場合は、時間外入局して同じ時間外に退局するパターン（図１１の保守Ｃのパターン）に該当するので、サーバ装置１０１は、保守Ｃの退局時間から保守Ｃの入局時間を引いた時間外単金に相当する時間を求める。そして、時間外単金に相当する時間に時間外単金を掛けた金額を実費用として求める。

（ステップＳ４１０）サーバ装置１０１は、ステップＳ４０１からステップＳ４０９までの処理で求めた実費用と、実費用を計算するために求めた時間内単金に相当する時間および時間外単金に相当する時間などの情報とを基にして、図１０で説明したようなオンサイト保守スポット費用明細書を作成する。尚、必要に応じて、予めオペレータにより入力された保守要員数や交通費などの情報も費用明細書に記載してもよい。

また、複数の保守員で対応した場合は、上記の計算で求めた金額に人数を掛ければよい。以下に、基本的な計算式をまとめる。
（オンサイト対応の実費用計算式）
・時間内費用 ＝ 時間内 × 時間内単金 × 人数 …（式１）
・時間外費用 ＝ 時間外 × 時間外単金 × 人数 …（式２）
・合計 ＝ 時間内費用 ＋ 時間外費用 …（式３）
さらに、上記の例では入局および退局の時刻を基準にして計算したが、顧客との契約に応じて出動時刻から課金するようにしてもよいし、作業開始から作業終了までの時間に課金するようにしてもよい。いずれの場合でも、上記の例と同様に計算することができる。

このように、本実施形態に係る保守費見積／明細作成システム１００およびサーバ装置１０１並びに保守費見積／明細作成方法は、装置障害の発生時に保守員が現地で障害の復旧作業を行う場合のオンサイト保守スポット費の見込み金額の算出および障害の波及範囲の有無や保守員の増員の有無などの判別、保守完了後の費用明細書の作成などを行うことができる。

特に、顧客からのオンコール受付時に過去に発生した類似障害に対する障害対応履歴を記録したＤＢ１５３の障害対応履歴データ２０７を参照し、精度の高い保守費用の見込み金額を顧客に事前提示を行なうことができる。従来はオンサイト保守スポット費用の事前見積は困難で事後精算となり、顧客側の想定金額との差異が問題になる可能性があったが、本実施形態の場合は、精度の高いスポット費用の見積額を事前に回答するので、顧客は安心して保守依頼を行うことができ、顧客との信頼関係を維持できる。

また、過去の障害履歴情報をＤＢ１５３に蓄積するので、障害の波及がある場合は保守員の増派提案や案内もオンコール受付時に行うことができる。

さらに、オンサイト対応通報メール機能を具備することにより、保守員は障害対応に関する情報を携帯端末１０２からサーバ装置１０１に逐次、自動的に収集および記録し、サーバー装置１０１は携帯端末１０２の送信情報から実費用の計算と費用明細書の作成をリアルタイムで行なうことができるので、費用明細書や請求書を迅速に顧客に提示することができる。これにより、従来、保守員が障害対応を終えた後でＴＡＣ側の担当者が行っていた作業時間（時刻計算を行って費用を計算し、明細書を作成する作業時間）を大幅に短縮することができる。特に、従来は保守員が事務所に戻った後で日時情報などを元に費用明細書を作成していたが、オンサイト対応通報メールの日時情報をＤＢ１５３の障害対応履歴データ２０７として自動登録することにより、保守員の手番および時間短縮の効果も得られる。

以上、本発明に係る保守費見積／明細作成システムおよびサーバ装置並びに保守費見積／明細作成方法部品備蓄管理システムについて、実施例を挙げて説明してきたが、その精神またはその主要な特徴から逸脱することなく他の多様な形で実施することができる。そのため、上述した実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明は、特許請求の範囲によって示されるものであって、本発明は明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内である。

１００・・・保守費見積／明細作成システム
１０１・・・サーバ装置
１０２・・・携帯端末
１６３−１６５・・・基地局
１６２・・・アクセスサーバ
１６１・・・ネットワーク
１５１・・・入力部
１５２・・・モニタ
１５３・・・ＤＢ
１５４・・・電話
１７１・・・メールサーバ
２０１・・・サーバ制御部
２０２・・・検索部
２０３・・・概算見積部
２０４・・・ＤＢ更新部
２０５・・・通信部
２０６・・・費用明細書作成部
２０７・・・障害対応履歴データ
２０８・・・単金マスターテーブル
３０１・・・端末制御部
３０２・・・時計部
３０３・・・操作部
３０４・・・通信部
３０５・・・表示部
４０４・・・出動ボタン
４０５・・・入局ボタン
４０６・・・作業開始ボタン
４０７・・・作業終了ボタン
４０８・・・退局ボタン
４０９・・・送信ボタン
４１０・・・クリアボタン

Claims (8)

1. 伝送装置の障害発生時に保守費用の見積もりを行う保守費見積／明細作成用サーバ装置において、
   情報を入出力するマンマシンインターフェース手段と、
   障害対応終了後に前記マンマシンインターフェース手段から入力される障害対応内容を含む障害情報を過去の障害履歴として記憶する記憶手段と、
   オンコール受付時に前記マンマシンインターフェース手段から入力された検索キーワードに応じて前記記憶手段に記憶された過去の障害情報を検索する検索手段と、
   前記検索手段の検索結果に基づいて保守費用の見積額を求め、前記マンマシンインターフェース手段に出力する見積り手段と
   を備えることを特徴とする保守費見積／明細作成用サーバ装置。
2. 請求項１に記載の保守費見積／明細作成用サーバ装置において、
   前記伝送装置は、他の伝送装置と互いにネットワークで接続され、
   前記マンマシンインターフェース手段から入力される障害情報は、前記ネットワーク接続された他の伝送装置への障害の波及範囲に関する情報を含み、
   前記見積り手段は、前記検索手段が前記検索キーワードに基づいて検索した過去の障害情報に障害の波及範囲に関する情報が含まれている場合に障害の波及箇所や保守員の増員数の情報を求め、前記マンマシンインターフェース手段に出力する
   ことを特徴とする保守費見積／明細作成用サーバ装置。
3. 請求項１または２に記載の保守費見積／明細作成用サーバ装置を有する保守費見積／明細作成システムにおいて、
   前記保守費見積／明細作成用サーバ装置に通信回線を介して接続される携帯端末を設け、
   前記携帯端末は、
   日時情報を出力する時計手段と、
   複数の作業項目を選択するための操作手段と、
   前記操作手段で選択された前記作業項目情報と選択時点に前記時計手段が出力する日時情報とを前記通信回線を介して前記保守費見積／明細作成用サーバ装置に送信する送信手段と
   を備え、
   前記保守費見積／明細作成用サーバ装置は、
   予め設定された作業時間単価を示す単金テーブルと、
   前記携帯端末から送信される前記作業項目情報および前記日時情報を受信する受信手段と、
   前記受信手段が受信した前記作業項目情報および前記日時情報から作業時間を求め、前記作業時間と前記単金テーブルとを用いて費用明細書を作成して前記入出力手段に出力する明細書作成手段と
   を更に備える
   ことを特徴とする保守費見積／明細作成システム。
4. 請求項３に記載の保守費見積／明細作成システムにおいて、
   前記携帯端末の前記送信手段および前記保守費見積／明細作成用サーバ装置の前記受信手段は、電子メールによって前記作業項目情報および前記日時情報を送受信することを特徴とする保守費見積／明細作成システム。
5. 伝送装置の障害発生時に保守費用の見積もりを保守費見積／明細作成用サーバ装置で実行する保守費見積／明細作成方法において、
   障害対応終了後に障害対応内容を含む障害情報を入力して過去の障害履歴として記憶媒体に記憶する記憶手順と、
   オンコール受付時に検索キーワードを入力して前記記憶媒体に記憶された過去の障害情報を検索する検索手順と、
   前記検索手順の検索結果に基づいて保守費用の見積額を求める見積り手順と
   を備えることを特徴とする保守費見積／明細作成方法。
6. 請求項５に記載の保守費見積／明細作成方法において、
   前記伝送装置は相互にネットワークで接続され、
   前記記憶手順で前記記憶媒体に記憶する障害情報は、前記ネットワーク接続された他の装置への障害の波及範囲の情報を含み、
   前記見積り手順は、前記検索手順の検索結果に障害の波及範囲に関する情報が含まれている場合に障害の波及箇所や保守員の増員数を推定する
   ことを特徴とする保守費見積／明細作成方法。
7. 請求項５または６に記載の保守費見積／明細作成方法において、
   前記保守費見積／明細作成用サーバ装置に通信回線を介して接続される携帯端末を使用し、
   前記携帯端末は、
   操作部材によって複数の作業項目のいずれかが選択された時点の日時情報と選択された作業項目情報とを前記保守費見積／明細作成用サーバ装置に送信する送信手順を実行し、
   前記保守費見積／明細作成用サーバ装置は、
   前記携帯端末から送信される前記作業項目情報および前記日時情報を受信する受信手順と、
   前記受信手順で受信した前記作業項目情報および前記日時情報から作業時間を求め、前記作業時間と予め設定された作業時間単価を示す単金テーブルとを用いて費用明細書を作成する明細書作成手順と
   を更に実行する
   ことを特徴とする保守費見積／明細作成方法。
8. 請求項７に記載の保守費見積／明細作成方法において、
   前記作業項目情報および前記日時情報は電子メールによって前記携帯端末から前記保守費見積／明細作成用サーバ装置に送信されることを特徴とする保守費見積／明細作成方法。

Images