ITシステム・ソフト関連  

関連広告

IT関連ページの移動


5.付 録


社内で業務系システム開発をする際の進め方について

(1)初期考察
・システムを使う人が少数であるときは気を使う必要はないが、
 複数の部署にまたがるシステムのときや、将来DBが拡張する
 可能性があるときなどは、必要に応じて小規模でも良いから
 プロジェクト化する。この「プロジェクト」とはプログラマ
 ーの集まりではなく、実務を行っている担当者(ある程度責
 任/権限を有する者が望ましい)。業務フローの分析や改善項
 目、仕様固め、マスターデータや初期データの入力作業、テ
 スト運用依頼、導入スケジュール管理、既存システムからの
 切替え導入作業、などのプログラマー以外でもできる項目は
 ほかの者を統括/管理して業務負荷を分散を行う(そうしない
 とプログラミングに専念できない)。
※通常システム導入と同時に業務改善を実現したい場合が多い
 (業務改善のためにシステム化を行うことのほうが多いかも)。
 周りの人が十分優秀であれば問題ないが、単なる事務処理者は
 自分の担当分のことしか知らなかったり、全体の流れをつかん
 だ改善ネタまで考えられなかったりする。この点を軽視すると
 使い勝手の悪い、効率の悪いソフトとなってしまう。
・「構想/指針」が示されているだけで、具体的な作りこみのレ
 ベルまで示されていないケースが多い。よって、「キーマン」
 となる主要な人物に対して初期の聞き込みを行い、各部署、各
 人の意見を聞き取っておくことからはじめるとよい。
※ただし、何も考えを持たずに聞き込みを行うと煙たがれるので
 次項(2),(3)の分析をわかる範囲で行うべき。

(2)業務分析
<現状把握>
@人的把握
 実際の部署・工程(単独部署の場合は単純だが、複数にまたが
 ることが多い)、操作する人(人数や個々のスキルによってど
 こまで作りこむかが変わってくる場合がある)を把握する。
A物と情報の流れ
 物(商品や部品など)と情報(伝票等)が現在どう流れている
 か。
<流れ図作成>
 上記の事柄を1枚の紙に図解して確認する

(3)業務改善有無確認
・まったく新規に形態が出来上がるのでない限り、多くの場合何
 らかの問題解決のためにソフト化されることがほとんど。この
 場合、
  @解決したい内容が何か
  A付帯して改善できることがあるか
 を考える必要がある。
・通常DB化されていない環境では、同じ内容の2重入力が目立つ。
 ここがポイントであるときは、上流データ使い回しから検討し
 ておく(段階を踏む場合は、将来の連携を考えて、現状のデー
 タ形式に一致させておくなどの配慮がいる)。

(4)仕様作成
・新しく出来上がるシステムを図解/作図する。
<大局的内容>
@業務フロー(部署間、人の結びつき具合)
A物(商品、材料など)と情報(伝票など)流れを上記に併記
Bデータ入力のタイミングなど補足
<詳細内容>
@画面構成

(5)全体構想への同意
・管理したいデータ
・これからどんなシステムを作っていくか
・どんなデータ(テーブル)を用意するか、管理したいか

※作業開始前に承認をえる。必要に応じてプレゼンテーションを
 行う。この際、工数改善(省力化)が狙いであれば必ず対費用
 効果(償却)まで試算しておく。

About Us | Site Map | Privacy Policy | Contact Us | © 2003-2007 Copyright (c) LaFraise.netR All Rights Reserved.