TSUGIME 設備保守の案件管理クラウド

設備保守／多拠点運用のための案件管理

現場と事務の間に落ちる案件を、なくす。

依頼はメールとチャットに分かれ、進行はその都度聞かないと分からない。TSUGIME は受付から完了報告までを一本の状態にまとめ、拠点をまたいだ案件を1つの画面で追えるようにします。

これは検証用サンプルのボタンです。送信・申込・問い合わせは行われません。

対象
3拠点以上の設備保守
導入
標準9週間
提供
ブラウザのみ

01DEMO

触れる状態で、見てください。

合成データですが、絞り込みとタブは実際に動きます。操作しなくても、初期表示だけで案件の状態は読み取れます。

対象
4拠点 ／ 設備保守
期間
08/09 – 08/26
更新
09:41
出典
合成データ

拠点をまたいだ案件の一覧

  • 表示中の案件

    9件

  • 期限超過

    2件

  • 完了

    1件

  • 対象拠点

    4拠点

状態で絞り込む

表示中の案件 9 件

  • 番号MT-2041 拠点第2工場 種別空調 期限08/14 担当第1班 状態作業中
  • 番号HV-1188 拠点物流A棟 種別受変電 期限08/12 担当第2班 状態期限超過
  • 番号EL-0472 拠点第2工場 種別昇降機 期限08/20 担当外部委託A 状態未着手
  • 番号PL-3310 拠点営業所B 種別給排水 期限08/18 担当第1班 状態保留
  • 番号MT-2044 拠点物流A棟 種別空調 期限08/09 担当第2班 状態完了
  • 番号EL-0475 拠点三号データ室 種別昇降機 期限08/22 担当第3班 状態未着手
  • 番号HV-1192 拠点三号データ室 種別受変電 期限08/15 担当第3班 状態作業中
  • 番号PL-3316 拠点営業所B 種別給排水 期限08/11 担当外部委託A 状態期限超過
  • 番号MT-2047 拠点第2工場 種別空調 期限08/26 担当第1班 状態未着手

状態で絞り込むと、上の数値と「表示中の案件」が同時に変わります。並び順は期限ではなく起票順です。

段階ごとの滞留

  1. 受付

    12件

    自動起票を含む

  2. 一次点検

    9件

    現場の記録待ち

  3. 見積

    7件

    承認待ち2件

  4. 作業

    5件

    部材待ち1件

  5. 完了報告

    4件

    受理済み

受付を100としたときの各段階の件数比です。落ち込みが大きい段階が、実際に詰まっている場所です。

今日の更新

  • 09:41 期限

    HV-1188 が期限を超過しました

    担当は第2班。一次点検の記録から6日が経過しています。

  • 09:12 着手

    MT-2041 が作業中になりました

    現場端末から着手の記録が届いています。

  • 08:57 保留

    PL-3310 が保留になりました

    部材の入荷待ちです。解除予定日が未入力のため通知しています。

  • 08:30 完了

    MT-2044 の完了報告を受理しました

    写真3件と作業記録が様式どおりに添付されています。

  • 08:02 受付

    EL-0475 を受け付けました

    点検周期からの自動起票です。担当が未割り当てです。

  • 07:45 更新

    HV-1192 の期限が変更されました

    現場都合により3日うしろへ移動しました。変更の理由が記録されています。

状態が変わった案件と、期限の判定結果です。通知の宛先は拠点と役割の組み合わせで決まります。

このUIは合成データによる操作デモです。実在の案件・拠点・担当は含まれず、保存・送信・外部通信は行いません。

02PROBLEM

抜けるのは、記録ではなく引き継ぎです。

案件そのものが消えることは多くありません。誰かの手元で止まったまま、次へ渡らないことが問題になります。

  • 依頼の入口が分かれている

    メール、チャット、電話のメモ。入口ごとに台帳が分かれ、どれが最新か判断できません。

  • 進行を聞かないと分からない

    状況確認のために連絡が発生し、現場の作業時間が確認対応で削られていきます。

  • 完了報告の粒度が揃わない

    写真だけの報告と長文の報告が混在し、後から同じ条件で振り返れません。

  • 期限超過に気づくのが遅い

    超過が判明するのは、多くの場合、先方から問い合わせが入ったときです。

進行中の案件が、聞かなくても同じ画面で分かる状態になります。

03FEATURE

増やす機能より、揃える機能を。

入口・状態・様式・権限。ばらばらのまま自動化しても、ばらつきが速く広がるだけです。

  • 受付の一本化

    経路の違う依頼を1つの起票に集約します。転記の手作業をなくすことが目的で、経路を減らすことは求めません。

  • 状態の共通言語化

    未着手・作業中・保留・完了の4状態に統一し、拠点ごとの独自呼称を置き換えます。期限超過は状態ではなく判定として持ちます。

  • 期限の監視

    期限の当日ではなく、超過が起きうる時点で通知します。誰に届くかは拠点と役割で決まります。

  • 完了報告の様式

    必要な項目を様式として固定し、欠けた状態では受理しません。後から同じ条件で比較できます。

  • 拠点横断の一覧

    拠点をまたいで並べ、状態と期限で絞り込みます。拠点ごとに画面を開き直す必要がありません。

  • 権限の分離

    閲覧・起票・受理を役割ごとに分けます。表示を隠すだけの制御は行いません。

担当するのは案件の受付・進行・完了報告の管理です。設備そのものの点検・修繕、部材の調達、現場要員の手配は行いません。基幹会計・人事システムの改修も範囲外です。

04PROCESS

1拠点で回してから、広げます。

全拠点へ同時に入れません。1拠点で1サイクル動かし、入力できない箇所を潰してから広げます。

  1. STEP 12週間

    現状の棚卸し

    拠点ごとの依頼経路と、いま使っている台帳を並べます。移行しないものもここで決めます。

  2. STEP 23週間

    設定と移行

    拠点・種別・状態の呼び方を統一し、進行中の案件だけを移します。過去分は参照用に置きます。

  3. STEP 34週間

    試験運用

    1拠点で実際に1サイクル回します。現場が入力できない箇所をここで直します。

  4. STEP 4—

    本運用開始

    残る拠点へ広げます。運用手引きと権限の一覧を渡して引き渡します。

05OPERATION

止まったときの手順まで、導入に含めます。

権限、履歴、保持期間、そして停止時の代替手順。運用の前提を先に決めてから移行します。

  • 権限は拠点と役割で分ける

    閲覧、起票、受理をそれぞれ別の権限として持ちます。画面上で隠すだけの制御を権限の代わりにしません。

  • 操作の履歴を残す

    状態を変えた操作について、いつ・どの役割が・何を変えたかを記録します。記録には個人を特定する情報を含めません。

  • 個人情報を持たない設計

    担当は班・委託区分で表します。氏名、連絡先、所属個人の情報を保持しません。

  • 保持期間を先に決める

    案件記録と操作履歴の保持期間を導入時に決め、期間を過ぎたものは削除します。

  • 停止時の代替手順

    サービスが使えないあいだの紙および表計算での運用手順を、導入時に一緒に用意します。

本サンプルは方針の記述であり、実際の稼働環境・認証・保存先を示すものではありません。

06RECORD

決めたことを、記録して渡す。

導入で決めた設定と、その理由を残します。担当が替わっても同じ判断ができる状態にします。

  • 62拠点

    導入済みの拠点数

  • 9週

    本運用までの標準期間

  • 4状態

    統一した案件状態の数

上記はすべて検証用サンプルの架空値です。実際の導入実績・稼働実績を示すものではありません。

  • 導入は担当2名で進めます

    設定担当と現場担当を分け、現場側の窓口を固定します。

  • 設定変更の履歴を残します

    状態・様式・権限の変更は、変更前の値とあわせて記録します。

  • 解約時にデータを書き出せます

    案件記録と操作履歴を、こちらの形式に依存しない形で渡します。

07CONTACT

現状の棚卸しから、始められます。

最初の相談では、いまの依頼経路と台帳を見せていただくところから始めます。

案件の状態を、聞かなくても分かる形にする。

これは検証用サンプルのボタンです。送信・申込・問い合わせは行われません。

  • 相談は60分・費用は発生しません
  • 受付は平日 9:00–18:00
  • 返答の目安は2営業日以内