システム開発　|　SATSYSTEM [サットシステム]

下記の問題を解消します。

複数のパッケージソフトを使っているが統合性・連動性がない。
パッケージソフトに業務を合わせようとして現場が混乱した。
業界の親会社の推薦ソフトを使用中だが合わない部分が多い。
リプレースの費用が大き過ぎるので我慢している。
リプレースしたいがデータの移行が難しい
レガシーシステムを捨てたいが捨てられない

　イージーオーダーやパターンオーダーとは異なり大量生産はできません。だから全国に拠点があるような大規模なシステムはお受けできません。
　御社の実情に合わせて最適なシステムをご提案いたします。そして最初から最後まで基本的には一人のベテランエンジニアが作り上げていきます。
　開発期間はある程度掛かります。（半年程度、規模によっては１年以上）しかし導入効果は期待以上を目指しており、極力自動化を図り入力ミス・操作ミスを防ぎます。
　必要な情報が見やすい形で取り出すことができるようになれば、処理時間の短縮にもなります。利用開始してからも改良が必要な部分があれば即対応いたします。

低コストで提供できる訳

自社のエンジニアだけで請け負い、下請け・外注を利用しておりません。発注に必要な仕様書・要件定義書などを省き、メンテナンスに必要な最小限の書類だけで済ますことができます。

経験値の異なる複数のエンジニアが共同で開発しようとすると、社内でも仕様書・要件定義書などが必要になります。仕様の認識に齟齬があった場合はトラブルの原因になります。

御社に密着して開発しますので、試作品を都度見てもらい、操作方法にも慣れて頂きます。完成する頃にはマニュアルを必要としなくなっています。

画面上に操作説明を可能な限り表示しております。マニュアル作成には膨大な時間とコストが掛かりますので、これを省けると大きなコスト削減になります。

サポート面ではリモート機能を使って対応時間の短縮化を図っております。ハードメーカーとも契約を結びトラブル対応面でも万全を期しております。

一般的なシステム導入例

オーダーメイド（スクラッチ）開発

自社の業務スタイルを大きく変えることなく（独自性・優位性を生かしたままで）システム化を図ることができます。受注・発注・在庫管理などで同業他社との差別化をされている場合は、この方法がお勧めできます。また旧システムから移行する場合に、データの継続性や操作面のとまどいを抑える点でも優れています。

パッケージソフトの導入

自社の業務スタイルに非常に合致したパッケージソフトウェアが見つかった場合や、現状スタイルを標準化に向けて大きく変更しようと思った場合などは、この方法がお勧めできます。ただ現場での業務手順や物流などへの影響も大きく、経営トップから現場の末端までの意識の統一が図られないと混乱を招く場合があります。　また標準化を図るということは、独自性・優位性が損なわれる危険性も無視できません。

パッケージソフトのカスタマイズ

パッケージの欠点を補う方法として、パッケージソフトウェアのカスタマイズをする場合があります。自社のスタイルに合わせてソフトウェアを修正するので、良いとこ取りのようにも思えますが、実際にはそれほど大きく変更する事はできません。　建物で例えれば基礎部分を変更するには大変な時間とコストが掛かりますし、それによる不具合の検証を行う必要もでてきます。場合によっては建て直した方が良い場合もありますので慎重な検討が必要です。
　ソフトウェアをカスタマイズするという事は、その中身を熟知している必要があります。しかしパッケージ・ソフトの開発者がそのプロジェクトに参加するという事は通常考えられないので、大きなカスタマイズは避ける傾向があります。これは後々にトラブルの原因になるからです。

パッケージソフトの問題点

▼パッケージソフトは最大公約数的に顧客の要望に応えるので、多機能ではあるが自社にとっては不要な機能が含まれ、設定や操作面での煩わしい部分があります。

▼パッケージソフトは自社にとって必要な機能が十二分に備わっていない可能性が高いです。
　カスタマイズにも限度があり、費用面でもオーダーメイドを超えるほどになる場合があります。

▼現場でのユーザーインターフェース面は、オーダーメイドには及びません。
　入力ミスを防ぐ機能や参考情報を同画面上に表示するなどのオペレーションを手助けする機能はオーダーメイドシステムには劣ります。

パッケージソフトの利点

▼短期間で導入でき、カスタマイズが不要ならコスト面でも有利です。
　業界で取引伝票やデータ処理の標準化が進み、顧客コードや商品コード等も統一化が図られれば、積極的に取り入れるべきでしょう。

▼スクラッチ開発のような大きな初期費用は不要ですので、取り組みやすいと言えます。
　しかしクラウド化と共にサブスクリプション化が進んでおり、長期的にはコスト面で有利とは言えなくなってきてます。

コラム　【ＩＴ業界の実情】

ＩＴ業界、とくにソフトウェアの受託開発業界は建築業界と似ていると言われてます。上はＩＴゼネコンと言われる大企業から下は個人企業まで様々なエンジニアで構成されています。

受注に於ける多重下請け構造の点でも似ていると言えますが、仕事の進め方では異なる点があります。それは建築業界では精密な図面があり、それに基づいて仕事が進んでいきます。たまに図面通りに行かないトラブルもありますが、作ったものを取り壊して作り直すほどの事は滅多にありません。

ところがＩＴ業界では顧客の要求に合わないものが出来上がり、作り直すことがあります。原因は、実際にコードを書く（プログラムのコーディング）のは顧客の要望や実情を聞き取り調査した上流工程のエンジニアではなく、下流の下請けエンジニアであったり、新人エンジニアだったりするからです。それに完成が近づくごとに、顧客の要望も追加や変更が出てくることが多いようです。

建築の場合は、住宅を例にとれば様々なデザインの家であっても玄関・キッチン・トイレ等の基本的には工事の考え方が同じなので経験の積み重ねができ、とんでもない間違いをすることは皆無です。

ソフトウェアの場合は顧客の業種・業態が様々でそれぞれに合わせて開発しており、経験の蓄積が難しく顧客自身も理解が不十分で試作品が出来上がってから要望を変更することが往々にしてあります。

顧客との打ち合わせを十分に行い、仕様書を作成したらその通りにソフトウェアを完成して納品すれば終了、というのであれば問題の発生はほとんどないはずですが、実際には使ってみて判る問題が多々あります。

優秀なベテランエンジニアは顧客との打ち合わせに出てこない部分も想定して準備している場合がありますが、経験の少ないエンジニアには無理なことです。つまり個人差が大きいのです。

顧客からすれば大手の方が安心感がありますが、実際に現場を支えているのは中小下請けや派遣社員などになり、個人の能力までは判るすべがありません。

結局のところ判断基準としては、経験と実績という微妙なところになります。