導入事例：ANAシステムズ株式会社様

ANAシステムズ株式会社について
ANAシステムズ株式会社では、新業務システムにGRANDITを採用しました。 システム導入プロジェクトを牽引されていた、同社企画営業部 営業グループ スーパーバイザーの加藤誠氏、総務部 ビジネスセンター スーパーバイザーの宮川洋子氏に導入経緯や理由について伺いました。

ANAシステムズについて

- ANAシステムズについて教えてください。

ANAシステムズは、旅行会社に設置されたANA航空座席予約端末（able）の保守および通信ネットワークの運用を実施する会社として、1989年に設立されました。

設立以来、ANAのフライトを支えるシステム（搭乗、運航、整備、貨物など）の端末開発・展開・保守、無線設備の構築、空港映像配信システムの開発、国内・海外の空港施設展開、オフィスのITインフラ環境（各種電話システム、無線LAN、OA端末など）の構築等、取り扱い業務を拡大し、ANAグループの各種業務を支えています。

従業員数は215名（2009年4月1日現在）、売上高は52億3,357万円（2008年度）です。

GRANDITを用いて新業務システムを構築

- 今回システムインテグレータに依頼したプロジェクトの概要を教えてください。

システムインテグレータには、新業務システム「ARMS（ANA Communications Revenue Management System）」の構築を依頼しました。ARMSの構築プロジェクトは、下記のようなスケジュールで進行しました。

• ～2009年2月　ERPパッケージの選定、実機検証
• 2009年3月～　プロジェクト立ち上げ
• 2009年7月～　稼働準備（運用マニュアル作成、ユーザ教育等）
• 2009年10月～　本番稼働

ARMSは、システムインテグレータのERPパッケージ「GRANDIT」を導入して構築しました。下図のとおり、ほとんどの部分を標準機能のままで使用しています。

個別最適化された業務プロセスが、迅速な経営判断の妨げに

- GRANDITの導入経緯をお伺いします。まず、新業務システムを構築した背景について教えてください。

新業務システムを構築した目的は、ひとことで言うと「これまでの業務プロセスの見直し、統一化」でした。より具体的にご理解いただくために、当社の業務の特徴から説明します。

当社の業務の特徴は、「LANケーブル1本の販売」といった案件から、「ANA空港事務所の開設」といった大規模プロジェクトを日本のみでなく海外も対象としているため、この事業規模にしては対応案件数が多く、また利用通貨が多種多様であることです。

プロジェクトの種類や規模によって、売上計上や発注のタイミング、見積の承認基準などが異なります。それが今までは属人的で、部門によってバラバラ、統一されていない状態でした。これは、別の言い方をすると、長年慣れ親しんできたやり方で個別最適化されていた、とも言えます。

「多少アバウトな所があっても、最終的に収支のつじつまが合えばそれでいいじゃないか」という時代もありましたが、経済環境が厳しくなるにつれて、それが許されなくなりました。例えば、収支予測を行うにしても、業務プロセスがバラバラなままでは精度の高い予測はできません。さまざまな経営データがすぐに集まらない、揃わないことによって迅速な経営判断ができないことが問題視されてきました。

以上のような背景で、ANAシステムズでは2008年頃からBPR*に取り組み始めました。営業現場を担っている企画営業部の主導の元、経理業務を担当している総務部メンバー等とBPRプロジェクトを立ち上げ、業務プロセス改善の方向性を検討しました。

検討の結果、BPRの手段としてERPパッケージを導入することにしました。

*BPR（Business Process Re-engineering）: 企業活動に関するある目標(売上高、収益率など)を設定し、それを達成するために業務内容や業務の流れ、組織構造を分析、再設計（リエンジニアリング）すること。

BPRの手段としてのERPパッケージ導入

- BPRの手段として、ERPパッケージの導入を選んだ理由を教えてください。

ANAシステムズにとってのBPRをどのように進めていくかを検討するために、社内だけではなく外部の協力を仰ぎました。既に先行してBPRに取り組んでいたANAグループの会社がありましたので、業務分析や施策の検討を支援してもらいました。
ERPの導入に至った理由、ポイントとしては下記のようなものが挙げられます。

当面のゴールとしてまず「レベル3」を目指す

「業務プロセス成熟度モデル*」で説明すると、これまでのANAシステムズの現状は「レベル2」でした。一方、経営層が求めていたのは「レベル4」の段階でした。一足飛びにレベル4は実現できません。当面のゴール（まずは実現しなくてはいけない状態）として、レベル3（業務規定やプロセスの標準化）を目指すことにしました。

*参考：業務プロセス成熟度モデル （出典：日本BPM協会）

レベル5：最適化	PDCAサイクルが適切なスピードと精度で回り、絶えず最適な状態が維持可能になっている
レベル4：管理・測定可能	仕事の成果や環境条件への適合性がモニタリングされ、PDCAサイクルが回せる状態にある
レベル3：定義されたプロセス	組織として「良い仕事のやり方」が検討・定義されて、統一ができている
レベル2：初期状態	属人的、刹那的な判断に頼ってはいるが、一定の仕事のやり方が繰り返し可能になっている
レベル1：混沌・マネジメント不在	仕事の目的・目標や手段・方法が吟味されず、その必要性の認識も薄い

パッケージ導入により、早く業務プロセスが定義できる

業務管理には必ずシステムがついて回ります。すると
「業務にシステムを合わせるか、システムに業務を合わせるか」
という議論になるのですが、ANAシステムズでは後者を選択しました。各事業部門にはそれぞれの「慣れ親しんできた今までのやり方」がありましたが、その1つ1つの正当性や根拠を見ていくと、ただ「今までそうやってきただけ」というものがほとんどでした。

これらをすり合わるのに時間をかけても、望ましい業務プロセスが紡ぎ出されるとは限らない。それなら「ひな形」となるような業務プロセスを外から取り入れ、それを基準にしたほうが早く標準化できると考えました。

内部統制の強化

ちょうどその頃、J-SOX法による内部統制の強化が言われはじめ、ANAシステムズの既存のシステムも対応させなければなりませんでした。
いずれにせよ業務システムのリニューアルを行う必要がありましたので、ERPパッケージの導入は選択肢として有効でした。

以上のような経緯で、ERPパッケージの選定に進んでいきました。
候補として4社のERPパッケージをピックアップし、その中からシステムインテグレータのGRANDITを選びました。

システムインテグレータのGRANDITを選んだ理由

- 複数の候補の中から、GRANDITを選んだ理由を教えてください。

まず、GRANDITがANAシステムズの業務に最も適合していたからです。
GRANDITの導入可否を判断するために、実機を用いた検証作業を行いました。結果、既存システムとの連携が必要な一部の機能を除き、ほとんどの機能がANAシステムズの業務に適合していると判断しました。

GRANDITの実機検証結果（一部簡略化しています）

導入対象機能	主な要件	適合度	備考
プロスペクト	引合からプロジェクト終了までのステータスを管理する。	◎
見積	見積を作成し、承認を行う。	◎
受注・売上	プロジェクト、部門、事業分野ごとの売上を把握する。	◎
発注・仕入(1)	得意先からの受注をもって発注を可能とする。	◯	大規模案件時に受注前に発注を行う業務がある。その際には受注の代わりの確証を確認するよう運用で対応する。
発注・仕入(2)	プロジェクト、部門、事業分野ごとの仕入を把握する。	◎
在庫	保守部品の在庫を管理し仕訳連動を行う。	◯	修理管理については別システムとの連携が必要なため、今回はGRANDITでの置き換えは見送る。
債権	請求書を発行する（回収消込はANAグループ会計システムで行う）。	◎
債務	仕入以外の債務を概算未払金として計上する（未払金の計上、支払はANAグループ会計システムで行う）。	◎
会計	ANAグループ会計システムにGRANDITで行った取引から発生する仕訳を連携する。	△	ANAグループ会計システムの形式に合わせたGRANDITの仕訳出力/取込機能をアドオン開発
配賦	工数管理システムと連携し、労務費、経費、販売管理費をプロジェクト、事業分野、部門に按分する。	△	工数管理システムからの工数情報を、GRANDITの配賦処理に取り込むカスタマイズ
原価計算	未完了のプロジェクトの費用は月末に仕掛計上し、完了時に再び費用化する。	△	プロジェクトの完了状況によって、ANAグループ会計システムから取り込んだ費用の仕訳を、仕掛に振替えたり、費用に再振替する機能をアドオン開発

◎：適合している　◯：標準で可能だが、運用での対応が必要　△：アドオン、カスタマイズが必要

アドオン部分に関しても、GRANDITのプロジェクト管理、配賦処理、仕訳処理の機能を使用し、GRANDITの利点を十分に活用した形での導入が可能であることがわかりました。

以上の実機検証の結果が一番の理由ですが、他にGRANDITの導入を後押しした理由として、下記のようなものも挙げられます。

• 導入費用：他社のERPパッケージの中には、当社の規模では非現実的な高額なものもありましたが、GRANDITは妥当な金額でした。
• 外貨取引に対応：GRANDITは標準で他通貨に対応しており、残高管理だけではなく支払や請求処理にも対応していました。
• 豊富なワークフロー機能：GRANDITは業務システムと電子承認が一緒に設計されており、さまざまなワークフロー機能が標準搭載されていました。承認も含めた業務プロセスを変えることが目的ですので、はじめからセットで考えられることは効率的だと考えました。
• 導入実績：システムインテグレータは、ANAグループの複数の会社でGRANDITの導入実績があり、ANAグループ全体で使っている会計システムへの連携なども、安心して任せられると考えました。

以上のような理由で、システムインテグレータにGRANDITを用いた新業務システムの構築を依頼しました。構築作業がスタートした時点で、目標としていたカットオーバー時期は約半年後でした。当社にとって始めての経験であり、最初は予定通り進むか不安でした。しかし、結果的に進捗遅れは無く、余裕を持ってカットオーバーを迎えることができました。

進捗遅れが無く、余裕を持ってカットオーバーを迎えた

- 進捗遅れが無く、余裕を持ってカットオーバーを迎えられた理由をどのようにお考えですか。

今考えると、うまく進めることができた理由、ポイントだったと思われることはいくつかあります。 下記に、重要だと感じたことを列挙します。

ユーザー部門＝システム部門

先述の通り、新業務システム構築プロジェクトの大多数が企画営業部のメンバーでした。通常の営業業務をしながらERPの導入を進めることになったため、プロジェクトメンバーはユーザー部門とシステム部門の一人二役をやっていたということになります。当初から意図していたわけではなく、BPRの検討からERP導入に進んでいった流れの中でそうなってしまいました。

結果的にはそれが功を奏したと思います。やはり、プロジェクトメンバー自身が現場の事を一番よくわかっていますので、「ユーザー部門とシステム部門の対立」が起こりえない体制で進めることができました。

ぶれないコンセプトと、経営トップの積極的な関与

ユーザー部門の気持ちがわかるだけに、構築作業を進めていく中で「ここは既存のやり方を変えないほうがいいのでは」と迷いが生じるときもありました。しかし、「迅速な経営判断を可能にする、業務プロセスの標準化」という明確なコンセプトがあったので、収拾がつかなくなってしまいそうな局面に陥っても、すぐに軌道を元に戻すことができたのだと思います。

コンセプトを維持していくことを、経営トップも積極的に支援してくれました。進捗会議にも頻繁に参加し、ある時には「それはGRANDITに合わせろ」と檄を飛ばすこともありました。ぶれない明確なコンセプトと、トップダウンによる強力な推進力があったことが、円滑な構築作業に大きく影響していたと考えます。

早い段階でパッケージに触れる

かなり早い段階からGRANDITに触れていた事も、スムーズにプロジェクトが進んだ要因だと思います。2009年3月に構築プロジェクトはスタートしましたが、3月時点でシステムインテグレータに用意していただいたGRANDITの実機に触れていました。実際に普段の業務で使うようにデータを打ち込み、いろいろと検証していくうちに「ここの機能の運用ルールはこうしたほうがよい」「システムに合わせてここの業務フローを定義すると、現場は◯◯について疑問を持つだろう」といったことが次々と明らかになってきます。

早期から実機に触れたことによって得られた多くの知見が、運用マニュアルやユーザー教育に反映されました。

後に完成した運用マニュアルは、およそ100ページの大作になりました。ユーザー教育についても、想定される現場の不安や疑問を解消するために、実機環境を用意した中身の濃いプログラムを作り、各部門・支店を行脚して、カットオーバー前後の混乱を最小限に抑えることができました。

自分たちのシステム

- 新業務システム稼働後の業務の現状や、今後の課題について教えてください。

カットオーバーからおよそ9ヶ月がたちましたが、先述の業務プロセス成熟度モデル「レベル3」の状態はほぼ実現できたと言えます。各部門に新しい業務プロセスが浸透し、機能しています。

今後の取り組みは、大きく分けて2つあります。1つは、いざ使ってみるとやはりもう少しカスタマイズを加えたほうが良い部分が見つかったので、その部分の追加開発です。もう1つは、本来の狙いであった「レベル4」を目指すことです。精度の高い収支予測のためには、どの情報をどのタイミングで集めるかを明らかにする必要がありますが、ようやくそのための仮説検証ができる環境が整いました。

- GRANDITをほぼ標準パッケージのままで利用した新業務システム。現場では抵抗無く使われているのでしょうか。

浸透には時間がかかりましたが、うまくいっていると思います。運用マニュアルやユーザー教育のプログラム等をかなり作り込みましたし、現在でも日々現場から挙がってくる質問をマニュアルにフィードバックしたり、FAQに集約したりしています。新業務システムについて現場社員に発信されている情報のほとんどが、自社独自の練られた情報です。おそらく標準パッケージと思って使っている社員はほとんどいないと思います。

標準パッケージであっても、このシステムは「現場の自分たちが理解し、考え抜き、浸透させていった、自分たちだけのシステム」です。

システムインテグレータの評価

- 新業務システムの構築における、システムインテグレータの活動を評価してください。

これまでずっと自社側の話をしてきましたが、もちろん、システムインテグレータの皆様のご協力無しには、新業務システムが予定通り稼働する事はありませんでした。
システムインテグレータは常に良き相談相手でいてくれました。もともとシステム面に詳しくない私たちの希望を汲み取って、様々な提案をしてくれました。

また、進捗会議ではいつも効果的な情報提供をしてくれました。「いい具合に進んでいます」というような曖昧な対応は無く、「フィット率」「課題クリア率」「進捗予測表」「障害一覧」などを明確に提示してくれました。これらの情報が、抜け漏れの無い状況把握と着実な進行に貢献してくれたと思います。
会議に参加した当社の経営陣も、「数値化による評価方式」には感心していました。

システムインテグレータの方に伺ったところ、今回のプロジェクトの管理には自社開発した管理ツール「 SI Object Browser PM 」を使われたとのことでした。上述の各種データも、これによって管理されていたとのことです。さすが、自分たちが開発したツールを使いこなしていると思いました。

- 最後に、システムインテグレータへのメッセージをお願いします。

業務プロセスの標準化は、ANAシステムズにとって未知のチャレンジでした。ここまで持ってくることができたのも、システムインテグレータのご支援があったからです。

より業務の成熟度を高めていくためには、まだまだ乗り越えなくてはいけないことがたくさんあります。システムインテグレータには、引き続きご協力いただき、当社の発展を支えていただきたいと思っています。

- お忙しい中、ありがとうございました。