 使えないシステムが作られてしまう
 導入してから使えないことが発覚
発注者の立場から考えると
開発者の立場から考えると
一方的に相手が悪いと責めても
ソフト開発の見積りの"困った”
ソフト会社の選び方は？
当社の優秀な技術者？
不満を整理すると（依頼側）
不満を整理すると（開発側）
使えないシステムを運用すると
改造すると決定したら？
改造する価値の決め手とは
新規開発と改造の要件
使えないシステム開発の原因
契約の内容・範囲が大雑把
担当SEの能力の分野が不一致
導入側の社内体制創りが不十分
より良いシステム開発をするには
理想化から現実化へ進める
業務のシステム化をプロデュース
業務システムからブレークダウン
提案：業務システムの設計
経営者の「思い考え」を展開
成功要素を洗い出す
成功要素を組み立てる
仕事をＯＳとアプリで考える
オープンシステムの開発体制
| ＩＴ１１９番 |
|
【代表の池田より一言】
これまでたくさんの中小企業の業務システムの開発に携わってきました。ここに掲載していることは、自分の体験であったり、これまでの経験の中で見たり・聞いたりしたことをまとめてあります。このサイトを見ることで、これからの業務システムの開発のリスクを減らすことができれば考えます。
 詳しいプロフィール
|
|
| 各種お問合せ
有限会社テオリア
〒942-0036
新潟県上越市東中島1943-91
tel 025-531-1151
E-Mail
info@it119.org
|
|
 |
|
|
|
|
|
|
|
|
|
 業務のシステム化をプロデュースする
|
 なぜ、役に立たないシステム・動かないコンピュータが作られてしまうのか？
それはコンピュータは得意でも業務を理解する力量に乏しい技術者が
ユーザーから集めたあいまいな要求を基にシステムを設計・開発するからです
システムの開発では業務分析と言いますが．．．
分析する対象の業務がなかったらどうでしょうか？
コンピュータを導入することで仕事の運用方法が大きく変わります
変わる前の話を聞くことは大切ですが
そこから、どのように新しい業務運営の仕組みを創り上げるか
それは、分析ではなく業務設計なんです
そして、依頼側には「こうして欲しい」という要求はあります、でもあいまいな状態です
新しい業務の仕組み（業務システム）は取材するものではなく、開発するものなのです
導入するユーザーでも、自社の本当に必要なシステムの全体像を明確に言い表すことは難しいのです
明示されない要求や条件を引き出し仕組みにする．．．これが重要なのです
|
 |
より良いシステムを開発するには、業務のシステム化のプロデュースが大切です
最初に必要なことは
【経営陣の役割】
●システム化プロジェクトの編成
社内・社外からメンバーを専任してください
社内の役職の上下関係なく、業務に詳しい人、システム化思考できる人、責任感のある人．．
名前だけのリーダーやメンバーはブレーキになります
●業務のシステム化を「システム化プロジェクト」に委任すること
これが無いと、単なるソフト会社との連絡窓口になります
考えて・決定する権限を与えてください．．．最終決定は経営陣がすればいいんです
●社内に向けての協力の宣言
そのプロジェクトの役割・権限・期待を社内・社がに宣言してください
経営陣からのお墨付きが必要なんです
次に必要なことは
【 社内業務のこれからを考える機関（システム化プロジェクト）の役割】
●関係者の考え・意見をを汲み取る
対等な立場で、システム化に必要な情報を集めると共に、システムの必要性を解く
・システム導入の意味を伝える・理解を求める
・業務とシステムの検討の経過を伝える
・関係者に意見を聞き文書にまとめる
◇社員の意見を素直に聞いて役立ちたいと思える人
●業務システムの設計
業務とシステムのあり方を考える
・理想とする仕事の進め方とシステムを紙にまとめる
・組織・人間関係にしばられずに理想を語る
・現実からの段階的な成長の計画を立てる
◇会社の代表として自分の考えを文書でまとめる力のある人
|
|
|
テオリア
仕事の図解