画面などのイメージを見てみたい。
システムデモおよび各種サンプルをご用意しております。
パッケージ製品をはじめ、各種システムのデモ画面をご用意しております。
全ての画面を確認できるデモ、設計書サンプルがあります。
「お問い合わせ」より、デモをご希望の旨をお知らせください。
デモサイトへの「アクセス用ID」と「パスワード」を発行させて頂きます。
見積を依頼する際には、どんな情報をお伝えすれば良いですか?
まずは、今お使いの帳票類をご用意ください。
業務システムの導入や既存システムの再構築を行う場合、一番重要なのは現状の業務がどのような内容で、 どの部分を改変したいのかを「具体的に」理解することです。 より具体的かつ確実に状況を把握し、必要な情報を得るための資料として、もっとも適しているのが「帳票類」です。
社内の報告書類・集計等計画書類・注文書・請求書等の伝票に類する書類、まずはこれらをご用意ください。 システムプロジェクト用の資料などを別途作成することもありますが、情報が概念的すぎたり現状と違う部分が多かったりして、 業務理解を進めるには情報が不十分なことが少なくないのです。
また「どこをシステム化したいのか」「どこを改変したいのか」などは、口頭でご説明いただくだけで概ね問題ありません。 全くの新規業務であった場合などにも、このような帳票類から検討を始め、利用することになる帳票から設計していくと具体性が増し、 良い議論ができると思います。
見積の見方を教えてください。
「機能見積」と「工程見積」によって見方が異なります。
実際に作成する見積書は各社各様で異なりますが、オーバルテクノロジーでは「機能見積」を採用しています。
一般的な見積は大きく分けて「機能見積」と「工程見積」の2種類があります。機能見積は作業料の見積は行わずに、 「何をつくるのか」を基準として機能ごとに金額を定め、全機能を足し上げて全体見積とするものです。 特定のシステムを機能に分け機能ごとに金額を確定させるため、発注側から見て「どの部分がいくらなのか」の判別がしやすく、 機能の追加・削除で見積金額を調整しやすいというメリットがあります。
一方の工程見積は建築などで利用されています。どの作業をどれだけやるという「作業料」を基本に計算し、 これに作業で使う資材の材料費を足して全体見積とするものです。システムの見積にこちらを採用してしまうと「ある材料をもとに、 ある作業を行い、特定のシステムができあがる」という算出方法になるため、 見積を見てもシステムのどの部分に該当している金額なのかを概観で判別することは難しく、 また必要・不要などの検討がしにくくなってしまいます。
各社で見積金額が大幅に違うのですが、どのように検討すれば良いですか?
「見積内容」と「見積基準」をご確認ください。
見積金額は、各システム会社によって大きく異なります。
その上で、最初に確認していただきたい項目が「見積に含まれている内容」です。業務システムを導入する場合、 見積の項目には「システムだけ」ではなく、事前企画の料金、導入に際する作業料金、サーバその他の機器類の代金が必ず含まれます。 業者によっては、あえて未確定部分の代金を見積から外し、金額が低めに見えるようにしている場合があります。 「事前の見積は低めだったのに、実際は高かった…」ということがないように、想定される全体見積での比較検討が必要です。
さらに重要な点は「見積の基準」です。工程見積の場合は「作業にかかる時間に、作業の時間単価を掛け合わせる」ことで計算しますが、 その基準とは「なぜそれだけの時間がかかるのか」を算出する根拠です。 もしもその根拠が提示できない場合は、見積基準が不確かで金額があいまいということになってしまいます。
オーバルテクノロジーが採用している機能見積の基準は、「作成するシステムのプログラム量」です。 当社の場合は、「プログラムファイル数」を見積数量に利用しています。概ね、大半を占める画面数から算出することができます。 画面数は、発注側にとってもわかりやすいため、算出基準としてとても明朗です。
当社は、設計料・実装料込みで1プログラムファイル10万円ポッキリ。大体何画面あるかが想定できればシステム代金はすぐに算出可能です。 30画面もあれば業務システムがつくれますので、当社では初期導入として400万~500万円程度のシステムを最もよくご依頼頂いています。
ちなみに某I社では、さらに精密に見積を行うために画面内項目をもって見積数量とし1項目4万円だそうです。 1画面に概ね20項目ぐらいありますので、1画面80万円ぐらいになります。
どのような業者を選択すれば良いですか?
難しい質問ですね。
システム導入は、金額もある程度かかりますし、期間もそれなりにかかります。 業者選定を失敗すると金銭的、時間的に大きなロスが生じるものです。 業者選択については、相性である部分も大いにありますので、一概に良い業者、悪い業者というものはないでしょう。
そのようななかで、あえてポイントを提示すると一番目は「付き合ってくれるか業者か」「付き合ってくれない業者」かが大きいかも知れません。 業務システムも1つの商品ですので、購入後にはほとんど何もしてくれないけど比較的安いものと、 購入後のアフターケアを重視して比較的高価で販売しているものがあります。 機能が単純で限られた用途にしか利用しない業務システムであれば、付き合ってもらう必要はないので、安価なシステムを選択するべきでしょう。 しかし、業務に直結し、自社の収益を大きく左右する業務システムを導入する場合に、後の問題に付き合ってくれない業者では不安が残ります。 収益に直結するシステムを検討するのであれば、諸々の問題に真摯に付き合ってくれるかどうかを判断基準にする必要があります。
次に重要な点は、業者の日程、予算等の計画、管理能力があります。 予定通りの日程でできあがらない、できたは良いが見積金額を大幅に超過している。 このようなことが起こるとその後のシステム運用に大きな問題が起こります。 システムを運用し、収益を上げなければならないにも関わらず、システム運用が問題でそんなこともままならない事態が生じます。 購入するだけで利用できる機器類であれば、計画能力といえるものは納期期日ぐらいしかありませんので、 計画能力の優劣は関係ありませんが、相当な期間利用することが前提の業務システムでは、計画能力は必須です。 ガントチャートで作成したスケジュール表を書面で提示し、それをもとに作業を進めることができるかを見るだけで十分です。 見積に際しては、想定される概要スケジュールを要求し、書面できちんと出せるかどうかを確認ください。
システム導入で成功する秘訣は何ですか?
ありません。
システム導入プロジェクトを立ち上げ、企画、設計し、システムが完成するだけでは、成功とはいえません。 成功基準が何であるかは状況により変わるものですが、作業の効率化を行うにせよ、売上を増やすにせよ、収益を確保するにせよ、 成功の一つの基準とできることは「普通に業務が回る」ことです。 システム導入を行った結果、収益が増えたとしても、業務担当者にかかる負荷が増えていたらあまり意味がないでしょう。
どちらかというと導入したシステムは業務担当者を鞭打ち、より多く仕事をさせることに貢献していることになります。 これも成果としてありえたとしても、これ以上収益を増やすことはもうできません。普通に業務が回っており収益も若干増えたとしましょう。 業務担当者の負荷は減っているはずなので、さらなる収益アップに関わる施策を実行できるかもしれません。 施策をせずとも余裕のある業務状況であれば、業務の繁忙期などで別段の増員、残業などをせず、コスト増を招かずに業務を遂行できます。 これだけで収益が増えます。
大前提になりますが、システムがきちんとできあがらなくては、その後の活動も何もないので、システムを無理なく構築できることは必須です。 また、システムが完成してからがシステムを活用する本番なので、システム完成段階である程度の余裕を残しておくことも重要です。 システムが完成した段階で疲れ果て、仕事が終わったかのような雰囲気もよく目にしますが、 システムができてからがシステムプロジェクトの本当の始まりです。
システム導入で失敗するポイントはどこですか?
ほとんどが見積ミスです。
システム会社の優劣は、見積を見ればほとんど分かります。見積にはどれくらいの時間がかかるのか、 どれくらいの人員が必要となるのか、どれくらいの機器類が必要となるのかが含まれているはずです。 時間・人員・ものに関する総合金額を算出しなくてはならないので、事前の計画能力が見積に反映されるのです。 また、時間的な制約、品質に対する制約、金額的な制約があるわけですから、この制約をうまくクリアしていなくてはなりません。 システムであろうがなんであろうが、制約なくできるのであればどんなものでもつくることはできますが、 制約を加味した上で可能な限り要求を満たしているものを作成しなくてはならないからこそ、見積は大変難しいのです。
さらに、各制約が重大であるからこそ見積が要求されるわけですから、各制約が満たされないことは重大問題です。 時間的制約が厳しいのであれば当然時間厳守であり、金額的制約が厳しいのであれば当然金額厳守です。 システム導入の失敗事例とは、重大である制約事項が満たされないことを意味しており、 重大な制約が破られることによってプロジェクト自体が存続できなくなる状態なのです。
一方で、当初見積が進行中のプロジェクトと乖離してしまうことは普通に起こります。 このとき、当初予見していなかった事態だからといって見積が全く変更できないことは問題です。 後から見つかった事態が重要事項であれば、見積変更をし、プロジェクトに取り込んでいく必要があります。 これも、見積作成段階である程度の変更が可能なように計画し、どうしても変えられない部分と、 ある程度変更しても支障がない部分をつくっておくべきです。 せっかく厳しい制約の上につくった見積を、さらなる制約の上で再計画し、再見積することは至難の業です。 ここに、計画能力・見積能力が顕著に出ます。
システム導入を途中で中止することはできるのですか?
中止するタイミングは3回あります。
通常のシステム導入は、いくつかの段階に分かれています。最初に行うのは、 どのようなシステムをつくるべきかを検討する企画(要件定義)段階、その後に、どのような方法で実現するかを検討する概要設計段階、 つくるもの全ての詳細を決定する本設計段階、そして、実際にシステムをつくる実装段階です。 その後、システム動作を確認する検査、予想した結果となっているかを確認する検証などに続きますが、 基本的に、つくり始めてしまう実装段階になるとプロジェクトを中止するのは困難です。
また、上記の企画・概要設計・本設計・実装と続く段階で、システム構築コストのほとんどは実装段階で生じます。 概ねシステム構築予算の3分の2は実装費用です。実装以外の企画・概要設計・本設計、その他の段階では、 予算の3分の1程度で予算規模が大きくなるとさらに減少します。 これはプロジェクト初期に行う企画・設計作業は、システム全体像を把握し、諸々の部分の調整を考える作業なので、 多くて4、5名、通常であれば1、2名でしか実施できません。 一方、実装段階は、設計作業によってつくるものが決まっているので、大人数で一気に行うことが可能です。 また製作作業は大変手間がかかるので、必然的に大きな費用を要します。 時間的側面は逆に、企画・設計作業は早くやれば良いということではなく、妥当な解答を導き出さなくてはならないので、 ああでもない、こうでもないと時間がかかります。システム構築期間の3分の2は、企画・設計期間になります。
システムプロジェクトはある程度時間のかかるものですので、プロジェクト途中で事情変更があり、 当初予定していたシステムが期待されなくなることもあります。 費用はあまりかからず、時間はかかる企画、設計段階でプロジェクトを中止するのであれば、 発注側・受注側双方とも大きな損害から逃れることができます。 企画終了段階・概要設計終了段階・本設計終了段階がプロジェクト中止が可能なポイントであると理解して良いと思います。 全プロジェクト期間が6ヶ月を超えるような長期プロジェクトの場合には、各段階で契約を分け、次段階に進んで良いことを確認した上で、 プロジェクトを進行していくなどの方法も良い方法です。
画面デザインにはこだわりたいのですが、どこまでできますか?
指定デザインがございましたら、それで作成可能です。
最近は、企業のホームページと連動し、お客様が直接利用するマイページ的なものも一般的となってきました。 自社内だけで利用するシステムであれば、デザインなどどうでも良いので、早く、安く出来るのであれば何でも良いと言う要望が普通です。 しかし、お客様が自分で使うシステムであれば、企業イメージに影響するため、画面デザインは何でも良いとは言えず、 各企業のこだわりが出るところ、出さなくてはならない所です。
しかし、業務システムの画面は、プログラム上で自動生成しているものなので、自動生成の仕方に大きく依存します。 自由に変更できるところもありますが、極めて変更し辛い部分もあります。ある程度デザイン変更を想定しているシステムでは、 画面の大枠を決めるためのテンプレートを定義し、テンプレートを読み込んで、システム画面を生成するようになっています。 テンプレートで出来る範囲であれば、デザイン変更が出来る仕組みとなっています。
オーバルテクノロジーの業務システムもこのテンプレート方式で画面生成をするようになっています。このテンプレートで解決できる範囲であれば、 大した問題ではないのですが、デザインにこだわる以上、どうしてもテンプレートの範囲では課題を解決できないことも度々あります。
オーバルテクノロジーではこのような課題にも対応できます。オーバルテクノロジーのシステムは、 仕組み上、見た目とデータ処理を行う部分が完全に分離されており、見た目を生成するテンプレート方式そのものを変更することが出来ます。 さらには、見た目を作り出すためには、さまざまなライブラリ(プログラム)を利用するのですが、 オーバルテクノロジーは全て自社で開発したライブラリを用いているので、見た目を作り出す方法そのものも変更できます。 基本的に、論理的に実現可能であれば、全て出来ます。後は、予算次第です。
仕様書は作成してくれるのですか?
標準形式であれば無償で作成いたします。
通常、仕様書または設計書と呼ばれる文書は、有償で作成されます。仕様書の作成は、システム作成とは別に行う必要があり、 作成労力が非常に大きいので、システム代金とは別に有料で作成されることが多いです。 仕様書を代替するものとして、打合せに利用した資料等の仕様概要を記した文書を利用しています。 実際には、システムが完成した後に仕様書を参照することも少ないので、仕様書作成は、基本的にしないと言うことになっています。
しかし、仕様書がないとシステムを作成する側としては、何を作れば良いのかわからないので、製作物を定義する文書が必要です。 文書作成の手間が掛かるからと仕様書を作成しなければ、何を作るはずであったのかが、曖昧になる事態を招きます。 また、システムは長期間利用することが前提であり、しばらくしてから、仕様の確認をしたいことが良くあります。 このときに仕様書がないと、システムがどのような状態になっているのかを、現物を見ながら調査することになり、大変な手間が生じます。 ある程度複雑なシステムの場合には、調査をしても一体どうなっているかが、まったく分からない事もあります。
そこで、オーバルテクノロジーでは、システム製作に最低限必要な仕様書は無償で作成することとしております。 システムの全体を全て文書化することは、大変な労力を必要とするのですが、わざわざ文書化する必要もないあたりまえな部分も多々あります。 一方では、文書に残しておかないと後々理解不能となる部分もあります。オーバルテクノロジーでは、製作効率上、必要である部分と、 文書で残しておかないと問題となる部分を優先した仕様書を標準仕様書として提供しています。 比較的単純なシステムの仕様書は少なく、複雑なシステムでは必要な部分が多くなるため大量の仕様書が出来上がります。
社内のメンバーをプロジェクトに参加させたいが、一緒にやってくれますか?
ご指導いたします。
本来は、システムプロジェクトの企画と完成したシステムの検証作業は、発注側企業が実施するべきです。その後の設計作業は、 受注側システム会社が行うことが通常ですが、社内に設計を行う能力を有している場合には、社内で設計作業も不可能ではありません。 自社内で企画、設計を行い、実装部分のみをシステム会社に発注し、システム開発を行う会社はあります。 しかし、実際には、発注側企業で企画作業を遂行することも難しく、コンサルティング会社やシステム会社が代行して実施しています。
オーバルテクノロジーでは、このように本来行うべき企画作業を尊重して、基本的には発注側で企画を行っていただく方法を取っています。 かといって、「やってください」と言ってもなかなか難しいので、企画の運営、資料作成の仕方、企画文書の作成など、 企画支援的にプロジェクトに参加します。 大抵は、資料と口頭ヒアリング程度で内容を詰めていくのですが、企画作業は、企業の課題や問題点を把握する作業でもあるので、 社内のメンバーが本気でやる事には意味があります。
必要とあれば、問題点を顕在化させる方法や、解決方法のまとめ方、他部門を説得する方法などについて、協力して作業することも可能です。
社内の複雑な事情など理解してもらえますか?
それが仕事です。
業務システムは、1部門で利用するものもありますが、多部門をまたいで情報流通をすることで本領を発揮します。 したがって、システム導入を考える場合、社内の関係部門全てと検討を重ねなくてはなりません。 社内各部門が、他の部門の状況をよく把握している場合には、協調作業はスムーズに進むわけですが、各部門がいわゆる「縦割り」によって、 他部門の事情をよく理解していない場合には、複数部門にまたがるプロジェクト遂行は大変難しいものとなります。 それぞれの担当者が、他部門の課題は過少に評価し、自部門の課題は過大に評価するわけです。
これらの問題に関して定型の解決策はないのだと思いますが、非公式の有志による部会や、部門ごとの小部会などの形態で検討することは、 経験的には有効と思います。多くの場合は、「仕方がないもの」であったり、「情報不足」であったり、「単なる勘違い」であったりするので、 これらに適宜対応することでプロジェクト運営が円滑になる場合があります。
通り一辺倒で、無理やりプロジェクトを進行させようとすることは、無益であるばかりか、有害ですらあるので、注意を要します。 問題解決をしようとするシステムプロジェクトが成立できないのであれば、プロジェクトが成立しないことが最大の問題であり、 プロジェクトを成立できるように対応することが最優先課題であると言うことになります。
出来上がるまで、どのようになるのか分からないのですか?
設計書およびモックアップでほぼ分かります。
これは、少し前まではよく言われたことです。 以前のシステム構築方法では、書面上のみで製作物を定義し、実際に作るというプロセスを踏んでいました。 しかも、製作は同時並行で行うので、製作物の完成は全部同時となり、いきなり全部出来てきた上、 思っていたものと違っていてビックリ、などということがよくありました。
現在では、システム構築方法も多少は改善され、事前に完成製作物の「見た目」を作成するようになりました。 これは内部のプログラム等は出来ていないので、システムとしては動作しませんが、 見た目が全部出来ているので、ほぼ完全に完成物のイメージをつかむことが出来ます。これを「モックアップ」と言います。
見た目を重視するシステムを構築する場合には、最初の企画段階から、基本的なデザインを検討します。 通常は、概要設計段階で基本デザインを検討し、本設計段階で全ての画面を作成します。 画面上のボタン等を押すと別の画面に移動することを「画面遷移」と言いますが、この段階でボタンを押したときの画面遷移も作りこみます。 全ての画面の「見た目」が確認でき、画面上でボタンを押して「画面遷移」まで確認できますので、 実際にシステムが動作しているときの雰囲気が完全に再現されます。 本当に動いている状態と近いので、モックアップ作成段階で「もうシステムはできたのか」などと言われることも良くあります。
オーバルテクノロジーのモックアップは「プロトタイプ」と非常に近い状態のものを提供しているため、 モックアップを実際に触って見ると「やっぱりこの方が良いな」と言うような課題点も見つかりやすく、より使いやすいシステムとなります。
自分たちは何をすれば良いですか?
資料、情報の提供と最終判断をお願いします。
現状の問題、課題、業務内容、改善方法などを、自社で検討し、一連の文書にまとめていただければ、これに勝るものはありません。 しかし、これらは大変な手間を要することであり、完結できずに中途半端になりがちです。 これらのプロジェクト資料で重要な点は、「網羅性」ですので、全体像が見ていることが大変重要です。 多大な労力をかけて中途半端な資料になるくらいであれば、現在手元にある資料をとにかく集められるだけ集め、 ガサと山積みしてもらったほうが、よほど分かりやすいことがあります。 抜けている部分や理解しがたい部分を口頭のヒアリングで補完すれば、網羅性は確保できます。 企画案、設計案をまとめていく過程で、提供された資料をもとに、内容を整理し、具体的実施案をまとめていきます。
実施案は、各種制約の中で、実現可能性を基本に組み立てていくわけですが、その後、どの案が最も妥当かを判断しなくてはなりません。 一番重要で、やってもらわなくてはならない事項はこの「判断」です。 いくつかの実施案があり、どれもある程度の妥当性があったとしても、どれにするか決まらないと次の段階に進めません。 ある程度、実施案が詰まってくると、どちらの案が良いのか、合理的判断基準がなくなってくるので、 こういうときこそある意味直感的な「判断」が必要です。
企業によっては、判断にとても時間を要したり、判断しなかったりするところがあります。これは大変困ります。おそらく、 正しい判断をしなくてはならないと誤解しており、間違った判断をした場合には、責任を取らなくてはならないと思っているからだと思われます。
しかし、これは間違えです。妥当性のないものを判断し、選択してしまったのであれば、責任を負わなければなりませんが、 十分な妥当性検討を行い、実現可能性も十分で、これ以上検討を重ねても有効な検討が出来なくなったときに判断が必要なのです。 どちらかというと、「これ以上検討しても、あまり意味がないから、この辺で決めよう」が重要なのです。 ここまでくれば、正しいか、間違っているかの問題ではないので、正誤の検討は不要です。 逆に、判断を間違ったと思ったときは、判断を変えて構わないのです。 判断できる状態にも関わらず、判断しないことによって、時間が浪費され、他で使えた時間がなくなってしまうわけですから、本当は大問題です。 判断しないことによって、失敗リスクを上げているのです。
個人情報漏洩は大丈夫ですか?
個人情報データは触らせないのが基本です。
個人情報を悪用しようとする輩が増えたこともあって、個人情報保護は必須のテーマです。 その中でもデータベースに大量に保管されている「個人情報データ」を一括で奪われてしまう大量流出が一番の問題です。 個人情報漏洩は基本的に3箇所から行われます。①インターネットに接続されているサーバへ直接ハッキングし、データを奪うもの、 ②データベースサーバにアクセスすることの出来る担当者が権限を横領し、データを奪うもの、 ③業務システムを利用するユーザが、システム画面をコピーする等により持ち出すもの、があります。
この内一番多いものは③です。しかし、 システム画面から個人情報を持ち出そうとしても1件ずつしか取り出せないので、大量流出まで発展することは少なく大きな問題にはなりません。 また、個人情報は業務利用するためにあるわけですから、業務利用者が個人情報を参照できなくするわけにも行きません。 職務倫理の教育で対処して行く類のものと理解できます。
そして、件数としてもある程度あり問題が大きいのが②です。問題となっている個人情報漏洩はほとんどが②と言って過言ではありません。 業務システムを管理運営している担当者はメンテナンスの必要上、データベースにアクセスする権限を持っており、 この権限があれば全ての個人情報を持ち出すことが出来ます。 必要な権限ですのでアクセス権限を与えないわけには行かず、最終的には担当者の選任と担当者の職務倫理の問題となります。
しかし、実際に起こっている個人情報漏洩事件では、個人情報管理の方法が方法論として問題があることが多いと思われます。 ③に関しても課題となる部分は同じであり、個人情報管理の方法論が問題視されるべきものと思われます。 システムの管理方法およびサーバのセキュリティ設定が妥当な方法となっており、かつ規定どおりに運用されているのであれば、 個人情報漏洩はそうは起こりません。職務倫理についてもデータの盗用は犯罪ですから、規定が守られているかどうかが問題なのです。 規定が守られていない、悪意を持って守っていない、と言うことが個人情報漏洩事件です。 これらは個人の責任感、義務感に任せて行うことは妥当な解決策ではありません。 もう一歩進んだ方法論として「規定違反が難しい状況」を作ることが、賢い個人情報管理となります。
個人情報はデータベース内にあり、業務システム画面上で利用しているのみでは当然ながら正しい利用です。 しかし、データベースからファイル等で個人情報を抜き出し、整理したり、加工したりすることも必要となる場合があります。 そして、個人情報の持ち出しは、このようなファイル形式でなくては持ち出せません。 個人情報漏洩を抑制する方法は、このデータベースから出てきた個人情報ファイルを厳しく管理することに他なりません。 個人情報がファイルとなっている状態は、例外的な状態であるはずですから、そこらへんにファイルが転がっている事態はありえないはずです。 例外的作業によって個人情報ファイルが生じたとしても、作業が終了した段階でファイルは完全に削除し、決してどこかに保存してはいけません。 ファイルが転がっていれば、誰かが持ち出しても分かりませんが、そもそもファイルが転がっている事態を問題にするべきです。
単純なようですが、ファイルが転がっている時点で問題だと明確に判断できる状態にしておけば、漏洩リスクのほとんどを抑止することができます。
システムの問題で事業に損害が出た場合はどうするのですか?
損害保険で担保するのがベストです。
業務システムは、お客様との取引を管理し、ビジネスプロセスを回すために利用しますので、システム障害が発生し、システムが停止した場合、 もしくは取引情報を誤って記録している場合には、ビジネスそのものに損害が生じる場合があります。 そのような事態が起こらないように誰しもが努力しているのですが、所詮人間がやっていることなので、間違えは起こります。 重要な点は、問題を未然に防ぐことと、起こった場合にどのように対応するかにかかります。
発注側がシステム導入に際して、システム問題が起こった場合に、ペナルティを課す契約を課すことがあります。このやり方は明らかに間違っています。 問題が起こった場合に、受注側であるシステム会社から、金銭を受け取ったとしても問題は解決しません。 しかも、問題を起こした側の会社は、ペナルティを支払うわけですから、問題解決に協力するわけがありません。 ペナルティを課す契約をしているプロジェクトに限って、ペナルティを支払う問題が起こります。 結果、発注側、受注側双方が大変な損害を被るのです。
そもそも、ペナルティを課しても問題解決にならないのですから、課すべきでないですし、課された側も受けるべきではないはずです。 なのに、これらの契約が成立してしまう背景には、問題に対する本質的な理解がないことがあるのではないでしょうか。 真面目に考えていないので、安易に課し、安易に課され、共倒れしていると見えます。
解決策としては、問題は起こるものとの認識を持ち、問題が起こった場合の損害の補填を如何に行うかを考えれば事足ります。 システム導入についても、リスクは十分に高いですから、一般的な損害保険で担保すれば良いのです。 大きな問題が起こることは不幸ですが、お金で解決できることはお金で解決し、 問題を取り除くための作業は、作業担当者が可能な限り頑張る。 このような分担であれば、発注側、受注側の関係が破綻することはなく、問題処理に専念できます。
オーバルテクノロジーでは、提供する業務システムは全て保険に入っています。 もしものときに備えているのですが、損害保険で補償しなくてはならないような事態は起こったことはなく、 大規模なシステム障害にも見舞われたことがありません。 軽率な物言いは出来ませんが、問題を抑制する最大の方法は、問題は起こることと想定し、事前に策を講じておくことと思われます。 問題は起こると想定すると、なぜか起こらないようです。
HPも一緒にやってほしいのですが、可能ですか?
製作会社とタックを組んで実施します。
最近ではシステムと連携し、お客様に動的な情報を提供するマイページ的な機能を有するHPが一般的となってきました。 お客様も時間を問わずに自分の都合に合わせて取引が出来るインターネットを好む傾向となっています。 このようなものは完全に業務システムであり、一見HPに見えることからHP製作会社で実現可能なように見えますが、まず無理です。 一方、業務システムもWEBシステムとなると一見HPですから、システム会社でHPを作成できるように見えますが、こちらも無理です。
HPも業務システムもプログラミング等のコンピュータの知識が必要ですが、本質的に重視するものが違います。 HPで一番重要なものは「コンテンツ」であり、HP内にどのような内容を込めるかが重要です。 また、広告宣伝やPRが目的でしょうから、「キャッチコピー」などの目に留まる要素を意識しておかないと意味がありません。 一方、業務システムは、「業務情報の流通」を主として、如何に円滑に、効果的な成果を上げるかを考えるものであり、 HPと必要となる知見が全く異なります。
オーバルテクノロジーでは、HP作成は行いませんが、HPで必要とするシステムの構築は行います。 既存のHPが存在する場合には、既存のHPを作成した制作会社と協力して、HPシステムを構築していきます。 既存の制作会社がいない場合には、オーバルテクノロジーから紹介申し上げることは出来ますが、 自らの会社にあったコンテンツを作成できるとは限らないので、お気に入りのHP制作会社を探すことをお勧めします。
まれに、HP製作とシステム製作を分離して構築することに抵抗する業者がおり、自社で両方ともやりたがる会社があります。 仮に両方出来たとしても、全く知見が違うため、一方に専念したほうがより効果的なHPシステムが出来るとも思われます。 当業者は、他の良からぬ理由で、両方を望んでいる可能性が高いので、将来のために長い付き合いはしないほうが良いでしょう。
PC等の面倒も見てほしいのですが、可能ですか?
別途PCサポート、ユーザサポートがございます。
残念ながら、基本的にオーバルテクノロジーでは、PCの販売、メンテナンス等は行いません。
しかし、システムを導入したは良いが、PCがまともに動かないのであればシステムが使えないので、最低限のPCサポートをする場合があります。 特に利用者が100名を超えてくると、PCの不具合でシステムが利用できないと言う事象がよく起こるので、 対応してくれる担当者がいないと業務遂行もままならない事態になります。
このような場合、オーバルテクノロジーでは、ユーザサポートの一環としてPCサポートを行っています。 ユーザサポートは、システムの利用方法や、データの登録方法などを電話、メール等を用いてご案内するサービスです。 業務担当者が多数に上る場合、全ての利用者が、システム全体を理解しているわけではないので、 使い方が分からず業務が進められなくなります。近くに分かる人がいれば良いですが、その人も忙しいので、いちいち答えてられないのが普通です。 この場合、ユーザサポートが問合せを受付、回答をご案内します。
オーバルテクノロジーのユーザサポートは、システムの利用方法を教えてくれる問合せ窓口ではありません。 システム利用に関して、何でも聞ける窓口として開設します。 そして、問合せに対して、分かる部門、分かる人を探しだし、回答を確認して、問合せ者に返信します。 一見かなり無駄な作業が発生しそうですが、ユーザの分からない部分や、問題となる部分は、大抵同じなので、 一度回答が出来れば、2度目からは即答できます。誰かが質問してくれると、次の利用者は、前回の回答が再利用できるのです。 回答がユーザサポートに集約され、過去に起こった問題の解決策が一元的に引き出せるようになり効率的に問題解決できます。
特に、利用者が増えてくると、この2度目以降の回答が早くなる方法は、非常に効率的になります。 同じ事を何度も言わなくて良くなり、本来の業務に専念できるので、現場の業務の品質向上にとても効果があります。
著作権等、知的財産権はどうなりますか?
適宜対応いたします。
著作物としては設計書およびシステム本体であるソースコードプログラムがあります。 基本的に著作権はその文書を作成した主体に帰属しますので、設計書とソースコードプログラムの著作権はオーバルテクノロジーに帰属します。 企画段階で作成する企画書(要件定義書)などは、発注側の資料を基に適宜整理したものとなるので、共同著作物に近いものとなります。 オーバルテクノロジーではこの企画書の著作権は主張しません。著作権は誰が著作したものであるかを詐称することが問題なので、 オーバルテクノロジーで作成したものをあたかも自分で作成したものであるかのごとく利用することはお控え下さい。 設計書に関してはオーバルテクノロジーで作成したものであることを引用明記いただければ、ご自由に利用していただいて結構です。
オーバルテクノロジーでは導入したシステムの「所有権」は、発注者に移転することにしています。 これが意味していることは、設計書およびソースコートの処分を自由に行う権利を移転したことであり、 改変して利用すること、破棄すること、他社に転売することを認めます。 注意が必要な点は改変した場合は、オーバルテクノロジーで不具合修正をする責任(瑕疵担保責任)はなくなりますので、 1箇所でも改変した場合はシステム全体の瑕疵担保は出来なくなります。
システム開発では特許化を検討する要素がある場合があります。 この場合、単独で発明したものは単独の特許、共同で発明したものは共同特許とするように致します。 単独発明のものは問題ありませんが、共同特許の場合は特許の申請費、維持費も共同分担となるので、 オーバルテクノロジーでは共同の特許権を放棄する場合もあります。個別事案ごとに対応いたします。
開発したシステムを販売したいのですが可能ですか?
可能です。
著作権の検討の一部として、システムを他の複数者に販売したい場合の対応があります。これはシステムの「再販売」に関する対応です。 システムをクラウド的なサービスとして提供する場合には、再販売に当たらないので著作権の検討は不要です。 システムの設計書またはソースプログラムのコピーの所有権を他社に販売するときに再販売の検討が必要です。 改変を認めない利用範囲を限定する所有権の販売は、利用権販売(ライセンス販売)という形態になります。
オーバルテクノロジーでは当社で開発したシステムを再販売する場合は、基本的にライセンス販売で対応していただくようにしています。 業務システムはどうしても利用しているうちに改変が必要となる場合がありますが、 このときもオーバルテクノロジーで改変を行う限りはライセンスは保たれるものとし、瑕疵担当責任も保たれることになります。 自社で改変してしまう等、利用範囲を超えて利用してしまう場合は、所有権販売とは異なり、ライセンス違反となり利用権を失います。
再販売を行った上に、販売業者または利用企業で改変を行いたい場合は、 基本的には設計書とソースコードを自由に利用できる権利(ソースコードライセンス)を提供することになります。 これらはソースコードに不具合があった場合の対応はどうするのか、改変を行う開発者の質問等の問合せはどうするか、 問題があった場合の責任分担はどうなるのか等を綿密に計画する必要があります。こちらも個別事案ごとに対応させていただきます。
リースで購入することはできますか?
可能です。
基本的に業務システムは情報通信機器ということでリース契約を結ぶことが出来ます。
しかし、オーバルテクノロジーで提供する業務システムは、インターネット上のクラウド環境を利用したシステムが前提となっており、 リース物件となるものはソフトウェア部分だけです。また、リース契約を結ぶ際にはリース物件が明確に特定できる必要がありますが、 クラウド環境上にあるソフトウェアは見た目上リース物件の特定が出来ないため、敬遠される傾向があるように見えます。
リース契約に適した形態としては自社内に業務システム専用サーバ機器を設置し、その中に該当ソフトウェアを設定するようにする形態があります。 この場合はサーバ機器、ソフトウェア、設定費用までを含めて一つのリース契約にまとめることが出来ます。 しかし、自社内にサーバ機器を設置した場合には、この機器類が故障した場合の対応、 ソフトウェアを更新したい場合の対応を別途検討しなくてはならず、インターネットシステムの利便性を失うだけでなく、 運用コスト的なデメリットもあり、積極的に薦められないのが事実です。 特定の業界では業務上のデータを社外で管理することを好まず、秘匿性を重視してあえて社内でサーバ管理をすることがありますが、 このような特殊事情がない限り、社内運用は不利だと思います。
リース物件に出来るかどうかはリース会社の審査基準により異なりますので、 あるリース会社の契約が難しい場合でも、他のリース会社では審査が通ることもあります。個別事案ごとに対応いたします。
業務システムは資産に計上するのですか?
資産に計上する部分と経費に計上する部分に分けるのが一般的です。
基本的には、設計および構築に関係する費用は、業務システム資産として計上し、 それ以外の作業に要した費用は、経費に計上するのが一般的だと思います。
購入したシステムのみを資産とするのが基本と思いますが、 システム導入に際して行う計画、設置、設定作業も資産に組み入れることはできますので、 企画作業から、完成後の導入作業までを一連のシステム購入として、一括で資産計上することもあります。 詳細については、担当税理士等にご確認願いたいですが、一括資産計上する場合には、 受注側業者が主体となってシステム導入を進める場合に、限られるかもしれません。
オーバルテクノロジーでは、設計、構築段階は当社主体で作業を進め、1つの業務システムとして納品が行われますが、 発注側企業が主体になり、当社は作業支援が中心となる企画段階、導入段階は、システム購入に直接関係のない費用であり、 経費計上するということになると思われます。
システム導入プロジェクトでは、特に、企画段階、導入段階での作業内容が大きく変化しますので、 資産的意味合いとなるのか、経費的意味合いとなるのかは、事案ごとに違います。 実施状況を確認の上、経理処理をして下さい。