HOME
流通工房について
各フェーズ定義
トピックについて
Link
■サイトマップ
■書籍・プロフィール
■サイト内検索
-------------------------
|
 |
 |
|
| ＜システム化計画＞ |
＜吉田君＞
次のフェーズの要件定義からある程度機能別に担当を明確したチーム編成になりますが
次のようにしようと思います
・売上チーム
・仕入・在庫チーム
・発注チーム
・マスターチーム
・企画・特売チーム
・帳票チーム
・外部I/Fチーム
・DBチーム
それぞれにリーダを一人ずつわりあてます。
仕入・在庫、発注チームはボリュームが大きいのでさらにサブリーダをつけようと思います
＜早瀬＞
サブシステムごとに分けるとこうなるね。
ただ、2つほど気になる点がある。
１つはシステム機能単位のチーム編成になっていることだ。
もう１つは帳票チーム、外部I/Fチームだけ技術要素によるチームわけになっているね。
＜吉田君＞
でも、今後の詳細設計、開発を考えるとこのシステム機能単位のチーム編成が良いと思う
のですが。また、帳票、外部I/Fはそれぞれ対象の帳票数、外部I/F数が多いため別チーム
として分けました
＜早瀬＞
基本的にはシステム機能単位に分けることは問題ないんだ。
ただ、帳票、外部I/F含めて業務の流れを考えた上でチーム編成を組んでおく必要がある。
【ポイント】
大きなポイントは以下の２つ
１．業務の流れでのチーム編成
基幹系システムは「業務を支えるシステム」であり、その企業の「動脈」にあたる。
流通業務においては大きくは以下の２つに分けることができるため、まずは大きく
この２つに分けリーダをおき、その下にサブ機能ごとに担当リーダをおくとよい
●実行系
該当サブ機能：売上、発注、仕入、在庫、棚卸
商品を販売する実務に関連する機能を担当するチーム
さらに、対象ボリュームによるが、仕入・在庫はシステム機能、データ構造上の
連携が強いため１人の担当リーダとするのが良い。また、発注と仕入・在庫の関連
も強いため、発注の担当リーダと仕入・在庫の担当リーダはデータ構造、ロジック
設計において連携を密にすることが重要
※店舗在庫についても当然売上と密接な関係があるため連携に気をつけること
●計画系
該当サブ機能：企画、特売、店舗棚割、商品マスタ管理（PLU送信、売変含む）
その他マスタ（店マスタ含む）
商品計画、販売計画といった計画業務に関する機能を担当するチーム
商品マスタ登録とPLU送信、売変、企画、特売についてはシステム機能、データ構造上
の連携が強いため、担当チームわけが難しいが、商品マスタ登録、PLU送信、売変を
１つの担当チームとし、企画・特売をもう１つのチームとし、企画・特売のチームは
計画業務の設計、実装までとし、PLU送信、売変についてはもう１つのチームへ連携
するようにするのが良いと考えます。
なお、店舗棚割については企業によっては非常に複雑なケースも多く、また、一方で
システム機能、データ構造上の連携は弱いので１つの担当チームとしてよいでしょう
それから企画・特売は最終的には発注業務連携をするため発注の担当リーダとの連携
が重要。
また、商品マスタの新規登録から廃番まで、店舗の開店から閉店までの過程でやはり
発注業務と連携するためこちらも発注の担当リーダとの連携が必要
※この商品サイクル（登録〜廃番）、店舗サイクル（開店〜閉店）は非常に重要だが
つい設計上もれてしまうことが多いことと、一方で実行系業務、PLU送信などとの
連携、特殊要件が多いため留意すること
詳細は、「商品サイクル」「店舗サイクル」の各トピック参照
★補足
実行系と計画系の場合、計画系の方が計画系内における各サブ機能との連携、また
さらには実行系の発注機能との連携なども発生するため、もし流通システムの設計、
構築経験があり基本的な業務サイクル、業務知識を持っているメンバーがいる場合は
そのメンバーを計画系のほうに割り当てると良い
また、実行系、計画系のリーダは、進捗管理の他、それぞれの中のサブ機能の連携、
データ構造の論理設計、またお互いに連携を密にし実行系と計画系間の連携などに
留意する
２．帳票、外部I/Fはそれぞれのチームで調査、設計を行う
システム規模が大きい場合、帳票や外部I/Fの数が数百に及ぶことが多いため、その
ようなケースではつい帳票チーム、外部I/Fチームといった形でチーム編成を分けて
しまうことがあるかもしれない。
しかし、システム機能の根本は
・データを流す
・データをためる
・データを見せる
ことであり、帳票も画面同様そのデータ自体は各業務から発生したデータであり
それをエンドユーザに表示するのが画面ではなく紙やファイルというだけです。
また、外部I/Fも同様でI/Fするデータの元となるのは売上や発注といった業務から
発生したデータとなる
よって、データ構造を正しく理解しロジック実装すること、リリース直後の障害時
のデータ調査などを考えると、帳票、外部I/Fについては１．で記載した実行系、
計画系のそれぞれの中の担当チームで調査、設計、実装まで行うようにすることが重要
具体的に主要なものを記載すると以下
・売上チーム管理：店舗からの売上データ集信、売上速報、日経などの社外企業への
販売実績送信、会計システムへの売上データ送信
※個人的には予実績対比、営業管理表などの管理帳票もこのチーム
に集約すると良いと考えている
・発注チーム管理：仕入先への発注データ送信、発注リスト、発注伝票
会計システムへの買掛データ送信
・仕入チーム管理：仕入先からの納品予定データの集信、仕入伝票
物流センターとのデータ連携
・棚卸チーム管理：実地棚卸表、棚卸結果表
・商品マスタ管理：PLU送信、店舗への指示書
★補足
これは要件定義〜基本設計フェーズのタスクとなるが、帳票については業務上での
使う場所、用途により自動出力とするか、手動出力とするか、出力必要タイミング
（朝一で必要、データ入力後即出力が必要など）、紙での出力、PDF形式、EXCEL形式
などを留意する。
これにより、必要技術要素、またプリンター選定、システム運用機能などの要件が
決まることとなる
関連トピック：「機器、プリンター」「バッチ起動画面」
|
Copyright (C) ビーコネクト. All rights reserved.
サイト内のテキスト、画像データの無断転載を禁じます |
|