ご利用をご希望の方は、APIご利用についてをご確認ください。
業務を効率化して働きやすく、事業の拡大や発展へとつなげるには、自社に合ったシステムの導入が欠かせません。
システム導入は、最初が肝心です。
「新しいシステムでどのような機能が実装されるか」など、SaaSの契約やシステム開発が進んだ段階で「この機能は意図した内容と異なる」ことが判明すると、スケジュールの大幅な遅延につながりかねません。
この記事ではシステム導入の流れについて、プロセスごとに徹底解説します。より良いシステムの導入にお役立てください。
卸売、商社、メーカー向け
クラウド販売管理 DEXTRE（デクスター）
国内取引、輸出取引を取引先ごとの価格、条件でオンライン受注。在庫、納品、請求、入金までひとつながりに管理できます。
貿易書類の発行もかんたん、多言語多通貨対応です。
主な機能 一覧 導入事例
INDEX
システム導入の流れは？プロジェクトの全体像
システム導入は、以下の流れで進められます。
| システム導入の工程 | 主な作業項目 |
|---|---|
| 上流工程 |
|
| 下流工程 |
|
| 本稼働後 |
|
それぞれの工程と行われる業務について、順に解説します。
システム導入①上流工程の流れ
上流工程はシステム導入の目的や要求事項を決定し、設計を行います。7つの項目に分けて、それぞれの内容を解説します。
目的の設定と現状の調査
システム導入はどの業務にどのような効果を見込むか、どの課題を解消するためなのかなど、導入目的の設定から始まります。システム導入の方向性を決めるうえで、重要なプロセスです。
「○○の業務の□□という課題を解決する」など、現状の変革を目的とするケースも少なくありません。この場合は目的の設定に先立ち、現状の調査と把握が必要です。
その過程で、課題の洗い出しや業務の棚卸も求められます。経営層や管理職、現場で働く担当者など、幅広い層に意見を求め多くの課題を可視化するとよいでしょう。
課題の整理とスコープの設定
現状の調査結果から、業務における課題が「見える化」されます。
個々の課題を十分に検討したうえで、業務への影響度や重要度、緊急度、解決策を実施した場合の費用対効果などを検討しましょう。
それぞれの課題は、優先度や優先順位の設定も必要です。
なぜなら予算などシステム導入に投入できるリソース「ヒト・モノ・カネ」に比べて、改善を要する項目が多いこともよくあるためです。この場合は、システムの機能に含める範囲を決める「スコープ」の設定が必要です。
優先順位の高い課題を選んで、新しいシステムの要件に含めましょう。
要求仕様書やRFP（提案依頼書）の作成
スコープが決定したら、新しいシステムで実現することを具体的に言語化する「要求仕様書の作成」へと進みます。
「バイヤーごとに販売価格を変更できること」など、実現したい項目をもれなくリストアップしたうえで、要求仕様書を作成しましょう。
開発や導入を行う開発会社やベンダーを募るため、RFP（提案依頼書）の作成を求められることもあります。
RFPには、自社が求めるシステムの仕様や条件が含まれます。開発会社やベンダーはRFPを見て応募するか否かを決めますから、過不足なく正確に記述しましょう。
ベンダーや開発企業の選定
要求定義書やRFPを作成したあとは、ベンダーや開発を依頼する企業の選定に移ります。
応募した企業から選定する場合もあれば、気になった企業に声をかけるケースもあるでしょう。どちらも提案書や見積書の内容を検討して、発注先を決めることになります。
SaaSは、無料トライアル期間のあるサービスも多いです。選定にあたり、自社の業務フローに合うか機能や性能、操作性のチェックに役立ちます。
要件定義
ここからは、導入するシステムのベンダーや開発会社が決定した後のフェーズです。
はじめに行うプロセスは「要件定義」です。
利用者側の希望を示す「要求定義」と異なり、要件定義では要求事項の実現に必要となる機能や性能を決定します。
要求事項を満たすために、業務内容の深堀りが求められるケースも多いでしょう。業務フローの詳細な分析は、手法の一つです。何をどのように実現したいか、詳細まで要望やニーズを言語化することをおすすめします。
そのうえでシステムで実現する方法を検討しましょう。実装する機能や処理速度、活用する機器やソフトウェア、セキュリティなどを考慮し、新しいシステムの要件を細部まで決めていきます。
基本設計
要件定義が終わったら、システムそのものの設計に移ります。設計には、以下の2種類があります。
- 基本設計
利用者から見たときの動作を設計する。外部設計とも呼ばれる - 詳細設計
機能の実装方法を決める工程。内部設計とも呼ばれる
基本設計では実装対象の機能について、業務フロー図や画面・帳票のレイアウト、画面遷移図、ネットワーク構成図やデータベース設計図などを作成します。アウトプットは「基本設計書」です。
システムを利用する企業の担当者も確認する基本設計書は、専門用語をなるべく使わず平易な表現で作成する工夫も求められます。
詳細設計
基本設計書は、そのままではコーディング（プログラムの作成）に使えません。
基本設計書をもとに、プログラムの作成者向けに作られる書類が「詳細設計書」です。基本設計書と異なり、詳細設計書の作成にシステム利用者側は関与しません。
プログラム内部の構造や関係性を示す「クラス図」は、詳細設計書に含まれる代表的なドキュメントです。
作成にあたり、ロジックを明確にして迷いが生じないように表記します。複数のプログラムで共通化できる部分は、積極的に共通化するとよいでしょう。
システム導入②下流工程の流れ
下流工程は、システムを作り実装する工程です。進め方は、開発、テスト、実装の順番となります。それぞれの項目で行うべき内容を解説します。
開発
詳細設計書に基づき、システムを作る工程です。
プログラミング言語を用いたコーディングを行い、プログラムを作る方法が代表的です。近年では、統合開発環境の活用やプログラムの自動生成など、開発の効率化も進んでいます。
テスト
作成したプログラムは、そのままでは納品できません。テストを行い、正常動作を確認する必要があります。
システムを使用する企業が新しいシステムを使い始める前に、5種類のテストが実施されます。
| テストの種類 | テストの内容 |
|---|---|
| 単体テスト | プログラム単体で、設計書の記載どおりに動作することを確認する |
| 結合テスト | プログラム間の動作を確認する （複数のプログラムによる連携が可能、値の受け渡しが正常に行えることなど） |
| 総合テスト | システム要件に沿って安定した動作を行えるか、システム全体を通してチェックする （処理速度、負荷をかけた際の動作、セキュリティなど） |
| 受入テスト | システムが業務における要件を満たすことを、ユーザーが確認する （使い勝手、操作性、業務要件を満たすことなど） |
| 運用テスト | 本番環境において、システムの正常動作を確認する |
実装
テストが完了したシステムは、システムを使う企業の本番環境（サーバーやクラウド環境）に実装され、実務で活用されます。
新規で使うシステムは、企業や利用するユーザーの情報など、データの初期設定が必要です。別のシステムから乗り換える場合は、データ移行も行う必要があります。
システム導入③本稼働後の流れ
システム導入では、導入した企業で運用が開始された後も工程があります。導入後のフローを、3つに分けて解説します。
導入後の効果を検証
システムが本稼働した後は、導入したシステムが目的やスコープで設定したように業務改善・業務改革に役立っているかをチェックする「効果の検証」を行います。
現場が新しいシステムの操作に慣れた時点で、検証を行うとよいでしょう。導入後1～2ヶ月の時点がおすすめです。
導入効果は、可能な限り数値で示すと客観的に評価できます。
あらかじめシステムの導入で改善したい項目と目標値を定めておき、導入後に数値がクリアされているかチェックする方法を取るとスムーズに検証を進められます。「全体の処理時間が1時間以内」は目標値の一例です。
追加開発
システム導入プロジェクトでは、本稼働後にも開発が行われるケースがしばしばあります。
これはプロジェクトの進行が、当初のスケジュールから遅延しやすいことに起因します。「スケジュールに遅れが発生しているなら、本稼働の日も後ろにずらす」ことは理想ですが、現実には以下の理由で本稼働の日をずらせないことが少なくありません。
- 運用開始日をアナウンスしてしまっている
- 競合他社に対抗するため、1日でも早く新システムを運用開始したい
- 検収日をずらせない（例：今年度中の売上や費用にしたい）
解決策の一つとして、「本稼働後、すぐに使わない機能」を切り分ける方法があります。後回しとなった機能は本稼働を迎えた後に「追加開発」として開発が行われ、後日実装されます。
保守・運用
本稼働後は、保守・運用のフェーズに移ります。
システムに不具合があれば対応することはもちろんですが、保守・運用には以下の項目も含まれます。
- 法令改正に伴うシステムの修正
- 修正プログラムの適用（サーバーやミドルウェアなど）
- 連携する他システムの仕様変更に伴う修正対応
保守・運用では、対応する曜日や時間帯の決定も重要です。
24時間365日の対応だけが選択肢ではありません。平日の日中時間帯のみ対応するケースも多いです。システムの特徴や利用する時間帯、予算もふまえて決定しましょう。
開発手法や技術分野ごとに、システムの導入方法に違いはあるか？
近年では「ウォーターフォール型開発」以外の開発手法も用いられています。
できあがったシステムをサービスとして活用する「SaaSの導入」もよく使われています。また、システム導入には業務システムだけでなく、インフラの導入もあります。これらの導入プロセスについて確認していきましょう。
アジャイル開発やスクラム開発でシステムを導入する
アジャイル開発やスクラム開発では、1つの開発期間は1週間から4週間程度と短期間です。
この間に要件定義からリリースまで行われますが、単一の開発期間ですべての機能を開発し終えるわけではありません。複数の開発期間が設定され、必要な機能を少しずつ開発する手法です。
このためウォーターフォール型開発のように、開発に着手する前の段階ですべてを決定する必要はありません。
順次リリースされた機能をチェックしながら、後の開発で方向性を修正するなど柔軟な対応を行えることは、アジャイル開発やスクラム開発の特徴です。
SaaSを利用してシステムを導入する
SaaSは、システムそのものは事前に完成されています。
標準機能をそのまま使用する場合、開発工程はありません。アドオンやカスタマイズを行う際に、その部分の設計や開発が必要になります。
また、多くのSaaSには無料トライアル期間があり、利用するSaaSを決める前にトライアルを利用することは一般的です。
SaaSには、多種多様な設定項目があります。
どのような業務や処理に関連する項目なのか把握したうえで、適切な値を入力・設定します。設定値は、SaaS導入前に検討しておく重要な項目の一つです。
データ移行を行った後は、新システム上でデータが正しく反映され、意図どおりに動作するかテストを行います。
インフラシステムを構築する
インフラの構築も、基本的なプロセスは業務システムの場合と変わりありません。ただし、プロセスごとに行われる作業項目は、業務システムと大きく異なります。
ネットワーク機器やデータを格納するストレージの実機に触れ、設定を行うことも多くなります。テストでも「業務が滞りなく行えるか」という視点ではなく、「通信が設計書の通りに行えているか」などの観点で動作を確認します。
BtoBの受発注を入金までシステム化、オンライン化！クラウド販売管理DEXTRE
中小企業から大企業まで販売業務のシステム化、オンライン化はクラウド販売管理 DEXTRE（デクスター）にお任せください。
DEXTREは国内外の卸取引に特化した、クラウド販売管理システムです。
顧客からのWeb受注から在庫、納品、請求、入金まで販売管理業務をオンラインで一元管理できます。初期費用は0円、月額20,000円からご利用いただけます。
卸売業や商社、メーカーの商慣習、商流に特化した機能が充実しており、費用対効果の高い販売管理のシステム化、リプレイスをご提供できます。
- 社内で分散していた業務の情報を共有、統合
- 転記作業などミスが発生しやすい業務を削減、軽減
- 商慣習や社内ルールに合わせて細かく設定できる
- APIやExcelで他システムやSaaSと連携
- 国内外の取引、オンラインとオフラインの受注を一元管理
など、販売や卸売の業務を自動化、効率化してコストやリスクの軽減に貢献します。
DEXTREは1人から中小企業、大企業まで事業の規模を問わず導入でき、部署単位での導入も可能です。
また、さまざまな業種でDXのサポート経験のある専任の担当者が導入前のご相談、無料体験から導入後のサポートまで、安定した運用に向けて支援いたします。
リプレイスのデータ移行、連携についても代行サービスをご用意して、スムーズなシステムの入れ替えを実現いたします。
ほかにも、DEXTREには、
- 受注データを起点に在庫、納品、請求、入金まで一元管理
- 日中英3言語23通貨で取引、画面操作
- クローズドBtoB ECから24時間365日世界中からWEB受注
- 取引先ごとの価格、掛け率、貿易条件など複数条件で取引
- 輸出に必要な貿易書類をかんたん作成
など、商社、卸売、メーカーの企業様に向けて国内外のBtoBに特化した販売管理の機能が充実しています。
ご利用をご希望の方は、APIご利用についてをご確認ください。
卸取引の受発注から
入金までクラウドで一つに
30日間すべての機能をお試しください
無料で試してみる
