こんばんは、たっちです。
前回から始めた集中予約システムの取組の振り返りから教訓を振り返るシリーズです。
ホテルシステムをよく分かっていないＳＩが手を出すと大火傷をします。あくまで当時はですが。
今はＵＩＵＸや操作性、レスポンスなどには敏感になっているので、それほどではないと思いますが、どの点に重きを置くかを理解しておく必要があります。
現状の課題整理
よく課題を整理すると言われますが、だいたいそう言うときに出てくるのは、事象であったり、問題点が出てきます。
『課題とは解決する（できる）ことである』
現場の人に業務で困っていること、問題はないですか？改善すべき事はなんですか？と聞くと、山のように出てきます。
・顧客管理システムがない
・チェックインに時間がかかる
・紙が多い などなど。
以前、とある有名な外資系コンサルティングファームのコンサルタントがこれらの『課題』について、報告書が出てたのですが、内容をみてびっくりしました。
『課題』
・顧客管理システムがない
『解決方法』
・顧客管理システムを導入する
こんな回答の為にん千万掛けるのか・・
いや、ちゃんとしたコンサルタントは居ますので・・そこはご理解ください。
当然、間にはそれなりの資料は入っていますが、中身がカスカスなので、これじゃ割に合わないと言うことで、そこで終わって貰いましたが。
上からの話しなので、費用とははまあ、目をつぶってです。
教訓 コンサルはピンキリ。はずれを引かないようにコンサルタントの見極めは重要。
コンサルを使うと、コンサルからあれやって、これやってと、納品物の資料の素材集めばかり頼んでくるのははずれ多し。
現場で問題分析とか、本当にこまっていること、真因を見つけにいこうとするコンサルタントは役に立ちます。
『顧客管理システムがない』
この手の話で良くやるのは、なぜなぜ分析からですね。
『顧客管理システムがないのか』
→なぜ顧客管理が出来ないのか？
「顧客の特定が出来ないから」
→なぜ顧客の特定が出来ないのか？
「チェックインするまで実際の利用者がわからないから」
→なぜチェックインするまで利用者が出来ないのか？
「会員制ホテルのため、予約は会員様から予約がはいるため」
→顧客管理システムがないと何が困るのか？
「宿泊者の好みや、趣味嗜好がわかるとより良いサービスができるようにかるから」
→趣味嗜好はどうやって入手できるのか
「お客様との会話から入手している」
みたいな禅問答のような会話から、本当に必要な事や要求を導き出していきます。
２５年前の結論は、利用者の特定が出来ないから、会員制ホテルだからこそ、会員ご本人だけはデータで管理できるようにしよう。
その後、ゲストの話が何度も出てきますが、最終的にはゲストの顧客管理は実装しておりません。
『紙が多い』
アナログ→デジタルの臭いがプンプンします。
→なぜ紙が多いのか？
「ホテルの予約連絡にＦＡＸでやりとりをしている」
→なぜ予約を紙でやり取りするのか？
「伝達ミスと受取の記録をのこすため」
→なぜ記録を残すのか
「先方から届いていないと言われる事があるので相互確認のため」
このＦＡＸのやり取りのため、１日ＦＡＸが５００枚近くになっていました。そのため、このＦＡＸを無くすことが目的の一つとなりました。
またこのＦＡＸの多さの理由が会員制ホテルのため、予約時は会員権所有のホテルに電話をして、会員権の権利を確認した上で予約を取る必要があり、これをオンラインでできるようにする事が重要なポイントになりました。
ゴール
・社内ＦＡＸでのやりとりをなくす。
・どこからでもすべてのホテルが予約できるようにする。
今では当たり前の事ですが、２５年前はある意味チャレンジャブルな目標でした。
システム開発のために解決しなければならないこと
過去の経験から単純にシステム作って終わりではありません。
今回は大幅な業務プロセスを変える必要があるためです。
①他のホテルから勝手に予約を取れるようにする
②予約時に紙の予約カードを書かずに直接コンピューターに入力する
③ホテル毎のルールは廃止し、名称、ルールなどを統一化する
今までのやり方を１８０度変える運用は現場から猛反発がありました。
システムに直接入力するなんて無理。他のホテルから勝手に部屋を使われるとコントロールが出来ない。部屋の在庫管理の方法は自分の所の方法じゃなきゃいやだ。などなど。
まあ、こうなるのは想定内で、毎月全ホテルの予約担当者と営業所の予約担当者を集めて会議・会議・会議でした。
部屋の在庫管理はブロック単位に管理できるようにして、どこからでも予約できるオープンなブロックや、自分のホテルしか予約できないブロック、営業所専用のブロックなどで管理するようにする事で、最初はＯＴＡに少しづつ部屋を出すようにオープンブロックに数部屋だす運用から徐々に増やしていって、気づいたら、殆どの部屋をオープンブロックに出すように仕向けていきました。
コンピューターに直接入力するために、ＵＩＵＸ（当時はそんな言葉ありませんが）には意識して、わざとそれまで使っていたオフコンの画面に近い操作性にしました。
電話で会話しながら、予約を入力する流れを作った感じです。
そんなやりとりを延々と続け、このシステムをオープンから利用する蓼科の予約担当者とがっちり手を握って進めました。
この時の予約担当者は私が山中湖で一緒に仕事していた人なので、かなり協力的で助かりました。
予算の役員会決裁
システムの開発規模がだいたい詰まった所で億単位の案件でしたので、取締役会での審議です。
実際の説明などは上司が行いましたが、説明資料などは私が作成して取締役会に挑んで無事承認。会社に入って初めて取締役会という場にでた記念すべき案件でした。
開発パートナーはオフコンのシステムを担当していた会社に決まっておりましたので、ＲＦＰはありません。
予約担当者会議で決めた方針に基づいて、機能概要書や画面イメージなどをペースに要件定義フェーズ、設計へと進みます。
アーキテクチャ決定
開発パートナーは元々オフコンで保守をしてもらっていた会社。
実は私が軽井沢で最初にさわったときは、別の会社が開発していましたが、その会社の親会社がとある事で倒産。そのシステムを引き継いでくれた会社での案件です。
山中湖ではその会社の下請けの会社がへたこいていたのです。
ですので、それ以来ぶりの仕事です。ＲＳ６０００での開発時はオフコンしかやれないと言うことで辞退されたのですが、その時にはオープンでやれますとのことで、復活となった訳です。
なので、アーキテクチャから検討。でもこの時点ではデータベースはオラクルに決定していました。オラクルで開発が決まっていたので、開発言語もオラクルで揃えましょうと言うことで、Oracle Developer 2000 で開発する事に。
これはPL/SQLで開発することで、モジュールをクライアントサイドやサーバーサイドで実行が可能ということでの採用でした。当時のことは良く覚えていませんが、要するにストアドプシージャ化がやりやすいというこですね。
レポーティングはVB+クリスタルレポートなどで対応しました。
《決定事項》
予約画面 Oracle Developer 2000 R2.0
フロント Oracle Developer 2000 R2.0
帳票印刷 Visual Basic 6.0 +Christal Report
Database Oracle Database 8.0 EE
Windows NT 4.0 Server ＆ Workstation
ハードウェアはＮＥＣの販社でしたので、ＮＥＣは決定。
教訓
システム導入の成功の鍵は業務プロセスをどれだけ変えることが出来て、それが利用者に受け入れられるかだ。
