組合員、供給会社、商品、在庫、人事と事業業務が、それぞれ別のファイルに散らばっていました。協同組合C社の業務の流れを整理し、共通データを中心にシステムを構築して、企画からQAとクラウド運用までつなぎました。
組合員情報は一つのファイルに、商品は別のファイルに、在庫と人事業務はまた別の記録にあります。各ファイルの中では業務が回ります。問題は、情報が互いにつながらなければならない瞬間に現れます。
どのファイルの内容が最新なのか、同じ情報をどこまで修正すべきなのかを確認しなければなりません。画面や表の問題ではなく、組織が同じ事実を別々の場所で管理しているという問題です。
協同組合C社も、組合員と供給会社、商品・在庫、人事と事業業務をスプレッドシートと手作業で管理していました。IXCは個別の業務を一つずつ電算化するところから出発しませんでした。業務同士がどの情報を共有すべきかを整理することが先でした。
メニューを作る前に、業務のあいだの関係を整理しました
既存のファイルを基準にメニューを作れば、各業務の画面は早く構成できます。しかし同じ情報を複数の場所に入力していた関係までそのまま移せば、不便も一緒についてきます。
C社では企画とデザインの段階で、組合員管理、商品と在庫、人事、事業業務を併せて見ながらシステムの流れを整理しました。組合員情報を中心に置き、供給会社と商品・在庫の管理が共通のデータ基盤を使うように構成しました。
この決定は、すべての業務を一つの画面に収めるという意味ではありません。業務ごとに必要な画面は違っても、同じ対象を説明する情報の基準が互いにずれないようにつなぐという意味です。
統合システムの価値は、メニューの数よりもこの関係にあります。利用者が別の業務に移っても、どの情報を基準に見ているのかが分かる必要があります。
組合員管理と商品・在庫を別々に置きませんでした
協同組合の運営には、組合員管理だけがあるわけではありません。供給者として扱う商品と在庫もあり、組織内部の人事と事業業務もあります。
今回のシステムでは、これらの業務を同じ環境の中に構成しました。それぞれのファイルで情報を別々に合わせる方式から離れ、つながったデータを基準に業務を処理するようにしたのです。
統合するときは、共通で参照する情報と業務ごとの状態を区別しなければなりません。組合員と供給会社を識別する情報は複数の業務で使いますが、商品ごとの在庫と人事業務の状態は、各業務の規則に従って管理する必要があります。
この区別があってこそ、統合という言葉が具体的な設計になります。一つにまとめること自体よりも、何を一緒に管理し、何を別々に判断するかを決めることが重要です。
案内に使う情報と運用に使う情報をつなぎました
組合員へ送る案内も組合員記録とつなぎました。業務システムで管理する対象とコミュニケーションの対象が、別々の基準のまま残らないようにしたのです。
組合員に連絡することは、メッセージ送信機能だけの問題ではありません。誰が案内を受け取るべきか、どの記録を基準に対象を決めるのかが先に必要です。
このプロジェクトの顧客関係管理は、組合員を理解するデータと実際の案内をつなぐところから始まりました。連絡のたびに別の名簿を基準にするのではなく、業務で管理している記録を併せて活用する方向です。
システムを活用したコミュニケーションは、データを信頼できるときに始まります。運用情報と連絡に使う情報が同じ基準を参照するようにすることが、その出発点でした。
構築と検証、運用環境を一つのプロジェクトとして扱いました
IXCは企画・デザインに続いて開発とQAを行い、クラウド環境とデプロイ経路、バックアップ周期を定めて運用を引き継ぎました。
業務システムは、機能ごとの画面を完成させたあとにも確認すべきことが残ります。実際に次の業務で必要な情報を使えるか、利用者が処理した結果が意図した流れにつながるかを見る必要があります。
また、新しい機能を追加するたびに運用環境を作り直す方式は負担になります。デプロイと運用の経路を一緒に用意してはじめて、システムを変え続けられます。
このプロジェクトで一つのチームが担った役割は、開発段階を広く受け持ったことで終わりません。業務を理解した内容が、画面とデータ、検証と運用までつながるように結びつけました。
変わったのは作業の場所ではなく、情報の基準でした
C社は散らばっていた業務を一つのシステムの中で処理するようになりました。組合員と供給会社、商品・在庫、人事と事業業務がつながった環境へ移り、構築後のクラウド運用も続きました。
この変化を、紙とファイルがなくなった結果としてだけ説明すると核心が抜けます。業務ごとに別々に管理していた情報の関係を整理し、同じ記録を参照できるようにしたことが重要です。
業務の自動化やERP構築を検討している組織でも、出発点は似ています。どの画面が必要かを考える前に、同じ事実をどこで繰り返し管理しているのかから見ていく必要があります。
C社の事例は、複数の業務を一か所に集めたプロジェクトであると同時に、組織が同じ情報を使う方法を整理し直したプロジェクトです。