はじめに

「オンネット統合業務シリーズ」とは販売、購買、在庫などの企業内基幹業務を株式会社オンネット・システムズ（以下「当社」）により、コンピュータ・システム化（以下「基幹システム」）したものです。

当社は創業以来、一貫して基幹システムを構築して参りました。この基幹システムは、それまで数億円する汎用コンピュータや数千万円のオフィスコンピュータで稼働させてきた経験・知識に基づいています。

汎用コンピュータやオフィスコンピュータでのシステムをコンピュータ業界では「レガシーシステム」などとネガティブに語る向きもありますが、販売、購買業務、会計自体が、大きく変化していないのですから、その知識を継続、発展する事が合理的と考えてきました。

現在「オンネット統合業務」はクラウドで稼働し、汎用コンピュータやオフィスコンピュータ時代に比べて劇的に安価になったPCやインターネットを用いて、世界中、どこでも動作する仕組みになっています。

世間ではDX、Aiなどの言葉が飛び交っていますが、言葉自体は、企業経営にあまり関係ありません。「劇的に安価になった情報処理利用環境」を「どう企業経営に役立てるか」であり、その最初に手掛けるべきは「自社業務の徹底効率化」と考えているのです。

「オンネット統合業務」の考え方

開発経験を以下の体系の中に整理しています（詳細は後述）

基幹業務は常に改善による更新される必要があるということ

基幹システムは業務の変更、コンピュータ化範囲の拡大により、常に更新される必要があると考えています。注意すべきはOSや業務ソフトウエアのバージョン更新によりシステム変更されるべきではありません（必要性の無い更新は最小化すべきです）。

システム更新はあくまで業務効率化の改善活動によって更新されるべきであり、改善活動は常に連続化するべきと考えています。

「業務効率化の仕組み作り」（ノウハウ）は、利用企業側でコントロールすべきです。ある「ソフトウエアパッケージを買ってきて」「５年くらいに１回、バージョンアップ通知でバージョンアップする」。このことがアナタの会社の業務効率化ですか？

統合管理されたDB項目

「オンネット統合業務」のDBはひとつです。これまで20年以上にわたり、DBを構成するテーブルの項目は増え続けてきました。個々の利用企業からすれば不要な項目もあるかもしれません。でも利用しない項目は画面、帳票で利用しなければ良いだけです。このDB内の項目説明（項目名は日本語にしています）が、当社が考える基幹業務を説明することになります。

DB項目に着目することは、企業のシステムを考える際の原点です。これが出来なければコンピュータによる自動化は出来ません。

「オンネット統合業務」は、業種別システムを準備していない

一般の業務システムは「XXX向けシステム」といい、そのXXX向けを一覧にしています。ただ当社の経験から見ますと、XXX向け（Aとします）は業種の特殊性があり、意味があると思います。しかし企業規模、風土、過去の経緯により複数の管理手順（Bとします）が存在します。AとBの組み合わせを考えた時、その数は無数（ほぼ会社ごと）となります。

「XXX向けシステム」の多くは「経験したことがある」の一覧と推測しています（経験一覧として意味はあります）。

当社のアプローチは、「業務の機能部品」（画面と処理モジュール）をこれまでの経験から複数蓄積しています。具体的には受注画面、発注画面、単価決定処理モジュールなどです。

この機能部品は全部、一部コピーと一部差し換えにより新たな業務、業種に対応できる様になっています。これまで化学会社販売、航空機内POS、スポーツジム、医療機器販売などに対応してまいりました。

途中作業（主に画面）を確認しながら構築を進めていく

大変失礼ながら、汎用コンピュータやオフィスコンピュータ時代（25年くらい前）に比べ、導入企業側の要件定義、業務手順の文書化能力、説明能力は劇的に下がっています。

恐らく「システムは洗練されたプロが作成した業務パッケージ（商品）がある」「そのパッケージを導入し、自社の業務手順をそれに合わせることが業務改善」と思う様になったからだと推測します。またPCなどが一般化し、その操作が出来る人が「情報処理人材」と勘違いされていることもあると思います。

当社側（パッケージ作成側）から見ると、導入企業側の業務内容の理解は実際のところ素人レベルなのです。導入企業側の業務内容を経験したことが無いのですから。私たちは「この様なシステム開発を経験した」ということなのです。

システム構築の開始時が一番双方仲が良く、だんだん関係が険悪になります。「パッケージを導入し自社の業務手順をそれに合わせることが業務改善」という事が自社業務に合わない、と理解し始めるからです。「プロだろ」「説明しなきゃ出来ないよね」となります。そこにコンサル的な会社が間に入ったらもっとややこしくなります。

要は、導入企業側で「情報と機能の図（箇条書き）で説明」してもらう必要があります。もしそれが出来ないのであれば現状システム、現状手作業を一緒に分析する必要があるのです。

「オンネット統合業務」構築の進め方は、

1. 基本システムをクラウドにインストールする
2. 現状のデータをセットアップする（品目、得意先、発注先、組織など）
3. 基本システムと実際データで動作確認する
4. 差異、機能抜けを確認し実装する
5. 3、4を繰り返す

となります。

この方法で「ケンカ」を最小限にして、プロジェクトをコントロールします。筆者は40年のシステム開発経験がありますが「ケンカ」を０にすることは出来ないと考えています。

段階的システム開発と既存システムデータ連携の重要性

「オンネット統合業務」の守備範囲は販売、購買、在庫など広範囲です。この範囲を一度で全部行うというのは無理があると思います。理由は3点あります。

1. システムは「導入企業側の管理レベルを越えられない」

例えば「在庫管理業務」の管理能力が低い会社が「在庫管理システム」を導入しても、管理水準は利用側の能力を超えることはありません。「それなりに」です。システムを一度に刷新することは、全業務にわたって管理能力がそれなりにあることが前提となります。もしあったとしても広範囲となりますので、各機能間の調整も必要になり作業量が増大します。既存システム機能を残しながら少しずつ「オンネット統合業務」に切り離していく方策が現実的と考えています。

2. 既存システムがある場合、新システムも既存システムに合わせる必要がある

よく「システムに業務を合わす」と言われますが、これまでの経験ではパッケージには必要機能が不足している場合が多いです。コード体系を刷新することなどできないのです。当社はこれまでの構築経験を通じ、既存システムの機能、データを継続しながら新システムを構築する方法が現実的と考えます。

3. 総合テストで「データの正しさ」をだれがどう確かめますか？

新システムの動作検証をする際、新旧のデータを見比べてテストする方法が一番安心です（当社はこちらを推奨しています）。もし新システムのデータ構造、機能が変わった場合は、その変化をアタマに入れて検証する必要があります。検証は無理かもしれません。

どちらの方式を選択するにしても、検証するためにデータを新旧両方で投入することはしないでしょう。25年前はやっていましたが。既存システムの登録データの新システム登録、結果データの比較機能が必要になります。

当社ではまず「オンネット統合システム」のマスタと既存システムマスタのブリッジ機能（自社開発ツール利用）を作成します。必要により処理結果の比較機能を作成します。