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

はじめに

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

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

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

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

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

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

業務ロジックとマスタは、可能な限り再利用するということ

当社は2000年から業務システム開発をしています。当時は高価な汎用コンピュータやオフコンシステムを、安価になったインテル系、UNIX系の安価なサーバーに移行するという流れになっていました。「ダウンサイジング」「オープン化」という言葉に象徴されていた時期でした。

その頃はまだWEB(HTTP)技術の高度な利用は考えられませんでした。スマホはまだ出現していません。2003年頃まで当社はマイクロソフト社の(レガシー)VBで開発を行っていました。しかし、マイクロソフト社が新たな開発方法論(.net体系)を発表したため、VB開発で蓄積した業務機能の再利用は難しくなりました。

これでは知識の継続利用が困難になる、という事で、以降①画面プログラム、②通信プロトコル、③業務ロジック、④DBロジックに分離して開発しています。

20年を経過した今、①はデスクトップ画面やWEB画面、②はSOAP、WCF、REST、③は変化なし、④も変化なし、となっています。大きく変化したのは、①のWEB画面技術・認証・認可技術・スマホ画面技術と、②のプロトコル変化です(TCP/IP、HTTPは変わりません)。着目すべき点は③④の変化が小さいことです。

「オンネット統合業務」は、③④に着目し、業務ロジック、DB項目・ロジックの蓄積に努めてきました。①の技術変化があっても、③④が再利用できる点を大いに享受できているのです。20年前に開発した業務ロジックは、今のWEB画面、スマホ画面でも活用できているのです。

開発手法「プロダクトライン開発」であるということ

先に述べた、蓄積した知識を再利用する考え方を別の見方で説明します。

当社の商品は「オンネット統合業務」です。この商品開発前提にソフトウエア・ファミリーを形成しています。例えば「認証・認可基盤」「メニュー基盤」「ジョブスケジューラ基盤」「マスタ基盤」は、同じものを利用します。

今後必要とされるソフトウェア要求と要求の変更頻度を予見しながら、長期間にわたってアーキテクチャやコンポーネントの基盤を再利用できるので、確実に低コストで高機能なシステムを構築できる基盤を保持しているのです。開発方法、技術もいつでも同じなので、適用先が異なっていても、少ない社員で開発、運用が出来ています。今、注目されているDevOps(開発と運用の一体化)が行えているのです。

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

分類 説明
基幹業務モジュール 販売、購買、在庫、生産などの基幹業務システム
業務補助モジュール 見積もり、工数管理、定期販売、EC、入金明細消みなど基幹業務モジュールと連動して動作する機能で、基幹業務モジュールの補助機能として機能追加され続けています
マスタ管理モジュール 「オンネット統合業務」のデータ一元化の基盤となるマスタ管理機能
運用管理ツール ジョブスケジューラ、汎用メニュー(認証、プログラム配布、画面起動)
開発支援 画面プログラムパターン、バッチ作成機能

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

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

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

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

統合管理された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年のシステム開発経験がありますが「ケンカ」を0にすることは出来ないと考えています。

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

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

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

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

  5. 総合テストで「データの正しさ」をだれがどう確かめますか?
  6. 新システムの動作検証をする際、新旧のデータを見比べてテストする方法が一番安心です(当社はこちらを推奨しています)。もし新システムのデータ構造、機能が変わった場合は、その変化をアタマに入れて検証する必要があります。検証は無理かもしれません。

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

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