東京ガスが経理申請をSaaSへ集約、独自要件の標準機能化とAI-OCR活用

効き目が大きかったのは、東京ガス固有の伝票への対応を、個別のカスタマイズではなく製品の標準機能として作るという切り分けだったと考えられます。提案の時点でSpendiaに収入予定報告や振替報告の機能はなく、他社からは別製品との組み合わせが必要という回答や、SaaSなので個社要件には対応できないという回答が返っていました。標準機能として実装しておけば、2カ月に1度のバージョンアップを重ねても機能は製品側に残り、旧システムでアドオンが積み重なってブラックボックス化した経緯を繰り返さずに済みます。標準機能にしても他社からの需要が見込めないものだけを例外的にアドオンへ回すという線引きは、どこまでを製品の資産として残すかの判断そのもの。

二つ目は、Fit to Standard（業務を製品の標準機能に合わせる進め方）を基本方針に据えながら、旧システムの中身を正面から洗い直したことです。勘定科目が新しい体系へ見直されるなかで、会計システムに正確なデータを渡すために必要な入力チェックや入力補助をあらためて整理し、それが標準機能の範囲で成り立つかを一つずつ確かめる作業が行われました。20年分の仕様を知るグループのIT機能会社と、製品を知るベンダーが同じ検討の場に着いた体制は、ブラックボックスを開けるための現実的な布陣だったと読めます。

三つ目に挙げたいのは、クラウドサービスの更新サイクルと基幹システム移行のスケジュールを噛み合わせた進め方です。Spendiaは2カ月に1度バージョンアップされるため、UIやデータ項目の仕様変更がSAP S/4HANA Cloudとの連携に影響しないよう、移行を担当する別ベンダーとの間で逐次すり合わせが重ねられました。SaaS導入としては異例の約2年という期間は、短期に入れ切れるという利点をあえて手放し、並走する複数プロジェクトの足並みに合わせた結果でしょう。