複雑なのは「予定表」ではなく、予定が決まるまでの業務
ビルメンテナンス業では、一つの作業日程を決めるだけでも、多くの調整が発生します。
定期清掃。
設備点検。
保守作業。
衛生管理。
こうした作業は、自社だけで完結するとは限りません。
多くの場合、
* 顧客
* ビルメンテナンス会社
* 協力業者
の三者間で日程を調整する必要があります。
現場では今も、
* 電話
* FAX
* メール
* Excel
* 紙の予定表
などが併用されていることがあります。
その結果、
* 誰が回答待ちなのか分からない
* 一度決まった日程が変更になり、履歴が追えない
* 顧客への確認を忘れる
* 協力業者からの回答を見落とす
* 現場作業後の写真や報告書が別の場所に保存される
* 担当者しか経緯を把握できない
といった問題が発生します。
こうした課題に対して、単純にカレンダー機能を導入するだけでは十分ではありません。
必要なのは、
作業予定を登録してから、日程を調整し、確定し、作業を実施し、報告書を提出するまでの業務全体を一つの流れとして設計することです。
Sekimosoft合同会社では、ビルメンテナンス業の三者間調整を題材に、作業予定管理、日程調整、現場報告までを一元化するWebシステムの設計を行いました。
> 本事例について
>
> 本記事は、Sekimosoft合同会社がビルメンテナンス業における作業予定管理の課題を題材に行った、自社開発検討・システム設計事例です。
>
> 特定の顧客企業から受託したプロジェクトではありません。
>
> 実際の導入時には、既存業務、契約条件、利用人数、既存システム、運用方法などを確認した上で個別に設計します。
ビルメンテナンス業では、年間を通じて多くの作業が発生します。
たとえば、
* 月次の定期清掃
* 年次の設備点検
* 特定月に行う保守作業
* 季節ごとの衛生管理
などです。
一つの作業には、
* 顧客の都合
* 物件ごとの条件
* 協力業者の空き状況
* 作業可能な曜日
* 時間帯
* 契約上の実施月
など、複数の条件があります。
場合によっては、
* 大安
* 仏滅
* 特定曜日
* 特定時間帯
など、顧客固有の条件も存在します。
つまり、日程調整は単なる空き時間の確認ではありません。
複数の条件を満たしながら、三者の合意を取る業務です。
ここを電話やメールで管理すると、担当者の記憶や経験に依存しやすくなります。
そこで今回の設計では、
日程調整を「人のやり取り」ではなく「状態を持つワークフロー」として扱う
ことを中心に据えました。
利用者ごとに、必要な情報は違う
今回のシステムでは、
* 自社
* 顧客
* 協力業者
が同じWebシステムを利用します。
しかし、全員に同じ画面を見せるのは適切ではありません。
それぞれが知りたい情報も、行う操作も違うからです。
自社が必要とする機能
自社側では、業務全体を管理する必要があります。
主な機能は、
* 顧客管理
* 物件管理
* 協力業者管理
* 契約情報管理
* 作業予定管理
* 日程条件管理
* 候補日作成
* 顧客回答状況の確認
* 協力業者回答状況の確認
* 日程確定
* 作業履歴管理
* 報告書管理
です。
自社画面では、
今、どの作業がどの段階にあるのか
を一覧で把握できることが重要です。
顧客が必要とする機能
顧客側では、複雑な入力を求めないことが重要です。
顧客が知りたいのは、
* いつ作業が入る予定か
* 何の作業が行われるか
* その日程で問題ないか
* 過去にどのような作業が行われたか
* 作業後の報告書を確認できるか
です。
そのため、操作はできるだけ単純にします。
たとえば、
候補日を確認
↓
OKまたはNGを選択
↓
必要に応じてコメント
程度にします。
顧客側では、
システムを使うための学習コストを増やさない
ことが重要です。
協力業者が必要とする機能
協力業者側では、
* 今後入りそうな作業の確認
* 対応可能日の入力
* 確定作業の確認
* 現場での作業開始・終了報告
* 写真アップロード
* 報告書作成
* 報告書提出
が中心です。
PCだけでなく、現場ではスマートフォンやタブレットを使うことを前提にします。
特に現場報告では、
事務所に戻ってから入力するのではなく、その場で完結できること
が重要です。
今回のシステムで最も重要なのは、カレンダーではありません。
中心になるのは、
作業予定の状態管理
です。
想定する流れは次の通りです。
作業予定を作成
↓
協力業者へ候補日確認
↓
協力業者が対応可能日を入力
↓
顧客へ候補日提示
↓
顧客がOKまたはNGで回答
↓
必要に応じて再調整
↓
日程確定
↓
作業実施
↓
写真・報告書提出
↓
完了
この流れを、システム上で明確に管理します。
たとえば、
* 未調整
* 業者回答待ち
* 顧客回答待ち
* 再調整中
* 確定
* 実施待ち
* 報告待ち
* 完了
といった状態を持たせます。
これにより、
「今、誰の回答を待っているのか」
が分かります。
電話やメールでは、やり取りの履歴を人が追う必要があります。
Webシステムでは、
現在の状態と次に必要な行動を見えるようにする
ことができます。
日程調整の負担を減らすには、最初の候補作成を効率化する
ビルメンテナンス業では、作業ごとに条件があります。
たとえば、
* 毎月第2週
* 火曜日のみ
* 午前中のみ
* 特定月に実施
* 土日不可
* 特定業者のみ対応可能
* 六曜条件あり
などです。
これらを毎回、人が一つずつ確認すると、予定作成だけでも時間がかかります。
そこで、今回の設計では、
作業条件から候補日を自動で絞り込む仕組み
を想定します。
候補日算出の条件には、
* 契約上の実施月
* 曜日
* 時間帯
* 顧客条件
* 物件条件
* 協力業者の対応可能日
* 祝日
* 六曜などの個別条件
を利用します。
最初から完全自動で日程を決定するのではありません。
まずは、
条件を満たす候補日をシステムが提示し、人が確認する
形から始めます。
この方が、現場運用に合わせやすくなります。
顧客に複雑な操作を求める必要はありません。
たとえば、顧客へ送る画面では、
* 作業名
* 物件名
* 候補日時
を表示し、
OK
または
NG
を選んでもらいます。
これだけでも、
* メール返信待ち
* 電話連絡
* FAX返信
* 担当者による転記
を減らせます。
NGの場合は、システム上で自動的に再調整へ戻します。
重要なのは、
高機能な画面を作ることではなく、やり取りの往復回数を減らすこと
です。
多くの予定管理システムは、日程が決まった時点で役割を終えます。
しかし、実際の業務はそこから続きます。
作業当日には、
* 現場到着
* 作業開始
* 作業終了
* 写真撮影
* 報告書作成
* 顧客確認
が発生します。
そこで、今回の設計では、
日程調整と現場報告を分断しない
ことを重視しました。
確定した作業は、そのまま現場対応へつなげます。
協力業者はスマートフォンやタブレットから、
* 作業開始
* 作業終了
* 現場写真
* 作業内容
* 特記事項
を登録します。
入力された情報から、報告書の下書きを作成します。
担当者が確認し、必要に応じて修正して提出します。
これにより、
作業予定
↓
実施
↓
写真
↓
報告書
↓
履歴
が一つにつながります。
現場写真がメールに届く。
報告書は共有フォルダにある。
日程履歴はExcelにある。
このように情報が分かれていると、後から確認するのが難しくなります。
今回のシステムでは、
一つの作業を中心に、すべての情報をまとめる
設計にします。
一つの作業に対して、
* 顧客
* 物件
* 作業内容
* 調整履歴
* 確定日
* 担当業者
* 現場写真
* 報告書
をひも付けます。
これにより、
「この物件で、過去に何をしたか」
を後から確認しやすくなります。
業務システムを新しく作るとき、既存の基幹システムをすべて置き換えようとすると、開発規模が大きくなります。
今回のようなケースでは、既存システムに、
* 顧客情報
* 契約情報
* 物件情報
* 作業予定月
などがすでに存在している場合があります。
そのため、最初の段階では、
既存システムを残し、必要な情報だけ連携する
方法が現実的です。
たとえば、
既存システム
↓
CSV出力
↓
新システムへ取込
という形です。
これにより、
* 二重入力を減らす
* 基幹システムを無理に変更しない
* 開発範囲を絞る
ことができます。
将来的に必要性が高まれば、API連携や自動同期を検討します。
Googleカレンダーなどとの連携も有効です。
ただし、カレンダーを業務の中心にしてはいけません。
カレンダーでは、
* 顧客回答待ち
* 再調整中
* 報告書未提出
といった業務状態を十分に管理できないからです。
そのため、
正しい情報は作業予定管理システムに持ち、カレンダーは表示や通知に使う
構成が適しています。
たとえば、日程確定後に、
* 自社担当者
* 協力業者
のカレンダーへ予定を連携します。
これにより、予定確認は便利になります。
今回のような業務課題は、他のビルメンテナンス会社にも存在する可能性があります。
そのため、将来的に、
業界向けサービスとして外販する
という展開も考えられます。
ただし、最初からSaaSを作るのはおすすめしません。
最初に必要なのは、
自社業務で本当に使える仕組みを作ること
です。
想定する進め方は次の通りです。
第1段階：自社向けMVP
まずは、
* 顧客管理
* 物件管理
* 作業予定
* 日程調整
* OK・NG回答
* 作業完了報告
など、重要な機能に絞ります。
第2段階：実運用
実際の業務で使い、
* どこで入力が増えるか
* どの通知が必要か
* どの条件が複雑か
* どの機能が使われないか
を確認します。
第3段階：業務ルールを整理
自社固有のルールと、業界共通のルールを分けます。
第4段階：共通機能を抽出
他社でも利用できる部分を整理します。
第5段階：SaaS化
必要に応じて、
* 会社ごとのデータ分離
* 契約プラン
* 権限管理
* 初期設定
などを追加します。
この順番で進めることで、
自社専用システムを無理にSaaSへ変える失敗
を減らせます。
要件が多いシステムでは、すべてを一度に作ろうとすると、完成まで時間がかかります。
その間、現場は何も改善されません。
そこで、段階的な開発が有効です。
たとえば、
フェーズ1
* マスター管理
* 作業予定登録
* 日程調整
* OK・NG回答
* 状態管理
フェーズ2
* 協力業者ポータル
* スマートフォン対応
* 写真登録
* 作業完了報告
フェーズ3
* 報告書作成
* 既存システム連携
* カレンダー連携
フェーズ4
* 日程候補最適化
* 分析
* SaaS化準備
という形です。
これにより、
早い段階から一部業務を改善し、その結果を次の開発へ反映する
ことができます。
今回の作業予定管理システムは、次の流れで構成します。
既存の顧客・契約情報を取り込む
↓
作業予定を作成
↓
条件から候補日を抽出
↓
協力業者が対応可能日を入力
↓
顧客へ候補日を提示
↓
顧客がOK・NGで回答
↓
必要に応じて再調整
↓
日程確定
↓
作業実施
↓
現場から写真・実績を登録
↓
報告書を作成・提出
↓
履歴として保存
重要なのは、予定管理だけで終わらないことです。
調整から実施、報告までを一つの業務としてつなげる。
それが、このシステムの中心です。
三者間の日程調整と現場報告がある業務は、ビルメンテナンスだけではありません。
たとえば、
清掃業
* 定期作業
* 顧客確認
* 現場写真
* 完了報告
設備保守
* 点検日程
* 協力業者調整
* 作業結果
* 保守履歴
工事会社
* 顧客
* 元請
* 協力会社
の調整。
警備
* 配置予定
* 変更調整
* 実施報告
訪問サービス
* 訪問予定
* 日程変更
* 現場報告
共通しているのは、
複数の関係者が、電話やメールで予定を調整し、作業後の報告を別の手段で行っていること
です。
この業務構造があれば、同じ考え方を応用できます。
Sekimosoft合同会社は、単なる予定表を作ることを目的にしていません。
重要なのは、
* 誰の回答を待っているのか
* 次に何をすべきか
* 日程がどのように決まったか
* 作業が完了したか
* 報告書が提出されたか
が分かることです。
つまり、必要なのはカレンダーではなく、
業務全体を前に進める仕組み
です。
電話。
FAX。
メール。
Excel。
これらを単純にWeb画面へ置き換えるだけでは、業務は大きく変わりません。
やり取りの流れそのものを整理し、
不要な確認を減らし、
回答待ちを見える化し、
現場報告までつなげる。
そこまで設計して、初めて業務改善につながります。
作業予定管理・現場業務システムについてご相談ください
次のような課題がある場合は、ご相談ください。
* 電話やFAXによる日程調整が多い
* 顧客や協力業者との調整履歴が追えない
* 誰の回答待ちか分からない
* 作業予定と報告書が別々に管理されている
* 現場写真の管理が属人化している
* 既存システムを残したまま業務を改善したい
* まずは自社利用から始め、将来的にサービス化したい
最初からすべての仕様を決める必要はありません。
現在、誰が、どのように日程を調整しているのか。
まずは、その業務を整理するところから始めます。
Sekimosoft合同会社は、課題整理、業務設計、システム設計、開発、段階導入、運用改善までを一気通貫で支援します。
