情報システム部やソフト会社などシステムを実際に開発する側は，利用部門に対し，「技術的にそれはできない」とつい，言ってしまいがちである。しかし本来は，技術的にできないときに，どうするかが技術者の腕の見せ所である。開発プロジェクトが難航した場合，開発側と利用部門は，システム化の目的は何だったのかを振り返るべきである。そうすれば，やり方は少し違っても同じ方向の結果が得られる解決策を見いだせるはずだ。
一般に業務のやり方を変えようとする場合，いくつかの代替案が考えられる。その企業の置かれた状況や，投入できる資源などを勘案し，業務改革の目的を達成できる最善の案を採用していくのが，真の改革である。ところが，情報システムの話になったとたん，技術的な問題が最優先される傾向が強くなる。
現場部門を巻き込んだプロジェクト・チームをせっかく作っても，情報システム部に「技術的に無理です」と言われると，それ以上反論できない雰囲気になる。逆に情報システム部が「技術的にはここまでできる」と主張して，現場が使いこなせないようなシステムを提案することもある。パソコン主流のシステムになっても，このギャップは存在する。しかし，「技術的にはこうだ」と言われて議論を止めてしまっては，いいシステムにはならない。
技術と現場のギャップ（1）
システム部が要請を拒否
機械メーカーA社の基幹情報システムは15年前に構築されており，もはや限界にきていた。各部門に固有の業務形態にシステムを合わすことがなかなかできず，しかもピーク時に処理が非常に遅くなるため，現場から不満が噴出していた。
そこでA社は「再構築プロジェクト」を立ち上げた。現場の各部門から責任者として管理職1名，さらに2名～3名のメンバーを選出。管理職メンバーの会議を「再構築委員会」，それ以外のメンバーの会議を「再構築分科会」とした。分科会の検討結果を委員会で承認していく仕組みである。
一方，情報システム部は新しい基幹情報システムの情報基盤を検討した。その結果，各部門にサーバーを置く，パソコンは全社員に一人一台配布する，オフィス・ツールとしてマイクロソフトのWordとExcel，グループウエアとしてロータスのノーツの採用を決めた。
当初，再構築委員会は各部門に対し，「再構築に際して，各部門の業務改革を前提に情報システムの在り方を検討せよ」という要請を出した。そのため，分科会のメンバーは日ごろの業務の中で不便な点や問題がある点を解消することはもちろん，新しい業務のやり方を理想像として描き，それを支える新システムを設計していくように心掛けた。
ところが，大まかな新システムの基本構想がまとまり，いざシステム仕様を決定する段階に入ってから，各分科会で問題が発生した。利用部門側の担当者が要請する新機能や業務のやり方を，情報システム部が「できない」と言って拒否するケースが目立った。
例えば，販売部門は受注があるたびに発注者の与信状況を自動的にチェックする機能の実現を，業務改革の目玉として目指していた。これまでは与信管理システムが販売システムと連携しておらず，問題が多かった。しかし，情報システム部は，「ソフトの都合上，自動処理は無理」として，与信管理システムと販売システムをそれぞれ別々に操作する必要があると説明した。
また，製造部門は部品管理システムに，過去の製品で使用した部品を検索するためのツールを用意してほしいと要望した。ところが，情報システム部の返事は，「一部門のために検索ソフトのインフラを作れない」だった。
新システムでは各部門にサーバー機を導入する。これで旧システムの懸案だった，部門独自の業務展開にマッチしたシステム作りが可能になるはずだった。しかし，情報システム部は，「全社の標準化のために，ここはこうしてもらいます」，「この機能は今回，入りません」などという台詞をあちこちの分科会で繰り返した。
各分科会に出席している利用部門の担当者たちは情報システム部の態度に業を煮やしてそれぞれの部門の管理職に訴えた。不満の声を吸い上げた各部門の管理職メンバーは，再構築委員会で情報システム部の責任者に，「全然話が違う」と問い質した。
しかし，情報システム部の責任者は，「我々はシステム・インフラも一緒に設計・構築している。インフラに大きな影響を与える要件をいちいちのんでいたら，予定している開発スケジュールを到底守れない」と反論。A社のシステム再構築プロジェクトは暗礁に乗り上げてしまった。
