システム導入にあたって

アナタの業務管理能力を超えられない

システム構築は、①アナタの業務を整理して　②自動化する手順を明確にして　③コンピュータに自動処理させる仕組みを作成　することです。

例えば「在庫管理」を考えた時、数多ある「在庫管理システム」で最適なパッケージを導入すれば、①、②を飛ばして③の効果を得られると考える方が多くおられます。「これからのシステムは優秀なパッケージに業務を合わせる」「DXだ」「AIで自動処理だ」、の意見です。

私たちは30年以上のシステム構築経験がありますが、インストールしたら直ぐに導入効果を得られる状況を経験したことがありません。
業種、業態、規模によって、管理項目、機能が異なるのです。①、②の作業を実施して「オンネット統合業務」に適合させる作業（機能変更と追加）が必要なのです。また、運用開始したら入出庫伝票は正確に登録する、棚卸は正確に行う、などを運用規定で徹底する必要があります。正確なデータが登録されなければ、システムは正常動作しないのです。①、②、③の運用部分について、アナタ自身が主体で行う必要があるのです。

オンネット・システムズ（以下「当社」）は、これまで経験した在庫管理機能は詳細に説明できます。「オンネット統合業務」として提供できます。その上で「アナタは差異部分をどう考えるか」です。システムはアナタ自身（あるいは会社）の業務管理能力の超えられないのです。アナタの管理能力を写す鏡なのです。「在庫管理パッケージを買うだけで自社の在庫管理業務が先進的になる」なんてことはおこりません。

システムは、運用開始時点では半完成品

前項の①、②、③を確実に行ったと（思った）しても抜けが生じます。システム構築には、回路図、建築図面などの様な設計文書が存在しません。利用者側の出来上がりイメージが当社に正しく伝わっていない場合や、当社が間違って理解している場合があります。失礼ながら、アナタからの説明自体が抜けている場合もあります。

構築後に必要機能が不足していたりもします。システム運用後に新たな業務効率化機能を発見することもあります。システム運用後に継続対応するしかないと思います。何年か改善作業を繰り返すと、大きな業務効率化を得られることを経験しています。

当社は「オンネット統合業務（動作するシステム）」を事前に提示できますので、「半完成品の度合い（業務の混乱）は小さくなる」と考えています。

システム構築プロジェクトリーダは、「システム利用者のサンドバッグになる」覚悟が必要です

多くの開発プロジェクトリーダは「2度とリーダをしたくない」と感想を述べます。利用者からは「こんな使いづらいシステム（現状と変われば言う傾向がある）」、経営者側からは「（業務調整が長引き）いつまでコストが掛かるのか！」「ユーザ目線の使いやすいシステム構築をしてくれ（使いやすいシステムって何かが難しい）」の意見調整をする役回りです。

いささか古い名言ですが、「苦しいこともあるだろう、云いたいこともあるだろう、不満なこともあるだろう、腹の立つこともあるだろう、泣きたいこともあるだろう。これらをじっとこらえてゆくのが男の修行である。（山本五十六）」が、きっと役立ちます（残念ながら筆者は到達していません）。

数年後、明らかな業務効率化が図られた時、「アナタは社内で光り輝き、至上の喜びを感じる」でしょう。そんな困難から逃げないアナタと、当社はシステム構築したいと希望しています。

構築する工程について

オンネット・システムズのシステム構築は、以下の図の通り進めています。

（以下、図面に対応します）

A.計画工程

システムの導入・構築に先立ち、その範囲、段取り・スケジュール、費用などを明確にする必要があります。
システムにはモノとは違い、カタチがありません。なるべく文書化し、発注側と当社間で合意する必要があります。「なるべく」と申し上げたのは、文書で作るものを完全に定義することは困難だからです。ただ「曖昧な部分をなるべく極小化し、双方の努力で解決する事を可能にするための文書」は必要になると考えています。
また当社が構築する範囲は、原則的には「オンネット統合業務」に機能変更、追加となります（幹の部分は完成品として提示できる）ので、曖昧な部分はかなり局所化、最小化されると考えています。

この工程ではプロジェクトの実施に当たり、その全体観を「計画書」でまとめ、システム開発の依頼側と開発側で合意を確認します。

A.計画工程	依頼側作業	オンネット・システムズ側作業
A1.開発内容の確認	・システム構築する範囲、目的の概略説明	・超概略提案をまとめる
A2.現状調査・分析	・現状説明 　‐システム化範囲の業務 ‐既存システムとの連携 　‐業務課題 　‐画面、伝票、帳票など	・DFD（業務機能関連図） ・ERD（データベース構造図） を作成
A3.「オンネット統合業務」との差異分析	・「オンネット統合業務」のデモ確認 ・どう統合されるかの認識	・「オンネット統合業務」のデモ環境準備 ・システム化構想図の作成
A4.基本計画書作成	・基本計画書のレビュー	・基本計画書の作成 ‐DFD、ERD 　‐画面／帳票一覧 　‐開発体制／スケジュール 　‐開発費用／維持・利用費用など
A5.プロジェクト実施承認	・開発契約書の承認	・開発契約書の準備

B.準備・設計工程

この工程では、まずシステム開発（主にプログラミング）するための準備をします（通常はクラウド環境で準備）。
準備が完了すると「オンネット統合業務」に機能変更・追加が可能となり、開発依頼側と開発側で実際のプログラム動作が、進捗中でも確認できます。思い違いを早期に検出できます。

開発準備が完了しますと、機能変更・追加箇所を機能単位に設計（仕様書・設計書作成）をします。仕様書・設計書を元に次工程でプログラム製造をしていきます。

B.準備・設計工程	依頼側作業	オンネット・システムズ側作業
B1.クラウド環境準備	（なし）	・クラウド契約 ・仮想サーバ、DBの準備
B2.「オンネット統合業務」基盤準備	・「オンネット統合業務」理解 　‐基本操作 　-機能理解	・「オンネット統合業務」の準備 ・最小限のマスタ準備 　-得意先、品目、社員など
B3.マスタ連動機能実装	・既存システム説明 ・統合するマスタ抽出	・自動連係機能の作成
B4.機能別仕様設計	・機能変更設計書のレビュー ・機能追加設計書のレビュー	・機能変更設計書作成 ・機能追加設計書作成

C.製造工程

この工程では当社サービス（ソフトウエア・パッケージ）である「オンネット統合業務」に対し、機能変更（調整）、機能追加をプログラム開発により実現します。

基本部分は「オンネット統合業務」に装備しています。それに対しての変更、追加の差分開発となるためゼロからの開発ではなく、開発時の混乱は抑制されると考えています。
本工程の作業は主にプログラミングとなりますので、開発側作業が主となり、開発依頼側は作成物のレビューとなります。

C.製造工程	依頼側作業	オンネット・システムズ側作業
C1.追加機能開発	・実際画面でのレビュー	・プログラミング
C2.機能変更開発		・プログラミング
C3.「オンネット統合業務」組み込み		・メニューに実装
C4.組み合わせテスト	・実際画面でのレビュー	・修正プログラミング

D.移行工程

「C.製造工程」まででプログラミングは終了しています。ただ製造したプログラムを運用させるためには、マスタの準備、残高情報（売掛台帳、在庫台帳など）のセットが必要になります。その上で、運用確認し、本番運用への切り替えを決断する必要があります。

この作業は軽視されがちですが、「C.製造工程」よりも大きな工数を要する場合も結構あります。特に懸念されるのは現状の作業手順と変わるため、本番切替え時に社内利用者から出るネガティブな意見を調整する必要性がある点です。

D.移行工程	依頼側作業	オンネット・システムズ側作業
D1.データ準備	・マスタデータ準備 ・残高データ準備	・マスタ、残高のセットアップ
D2.現行システム比較機能作成	・現行システムとの結果比較	（既存システムがある場合） ・新システム結果との照合機能作成
D3.総合テスト	・社内利用者参加での試験利用	・状況確認 ・問題点対応
D4.システム機能説明書作成	・利用、操作説明書の作成	・システム機能説明の提示 ＊操作説明書ではない
D5.本番切替え	・本番切替えの決断	・本番環境の作成

E.維持・利用

ここまでで本番稼働となります。数か月は多少混乱します。「混乱を無くそう」と開発しても間違いや、解釈違いは必ず発生するものです。当社の経験では、例えば100台程度のPC利用のシステムで3か月程度は初期トラブルが発生します。

また運用が定着すると「さらに改善する」箇所が発見されます。この改善を継続的に行う事が「システムを経営に役立てる」ことに繋がると思います。

アナタの会社に対して「最適なシステムがパッケージとして市販されている」という様なことがあるハズがありません。アナタが中心になって改善作業を継続することが重要と考えています。

システムは「作ったら終わり」ではありません（システムの計画/製造/運用/廃棄のライフサイクルの中で、一番コストを要するのは「運用」と言われています）。継続改善の体制構築こそ重要です。

E.維持・利用	依頼側作業	オンネット・システムズ側作業
E1.初期トラブル対応	・初期トラブル、問い合わせ対応	・問題対応支援
E2.利用定着化支援	・利用促進のための活動 　-マニュアルの整備 　-問題点の聞き取りと対応	・定着化支援
E3.維持・利用運用	・「維持・利用契約」の締結	・「維持・利用契約」の提示
E4.月時定例会	・月1回程度の運用状況確認会議 　-課題、改善テーマなど	・会議の出席