改善したい成果を決める
売上、納期、品質、引継ぎなど、今回の仕組みで改善したい成果と、関係者、守る条件を整理します。
業務基盤システムの更新時期が近い。改修できる人がいない。
既製のシステムでは、自社固有の条件や例外に対応しきれない。
現場の帳票や画面を確認し、実際の業務に合う設計から一緒に進めます。
限定した1業務なら、標準6週間で本番利用できる状態まで納品します。
最初の一業務を標準範囲に収められる場合は、方向性確認用プロトタイプを0円で作り、実物を見てから本開発へ進むか決められます。
固定範囲の進め方と料金を見る最初の一業務を、下記の標準範囲で本番化するプランです。方向性確認用プロトタイプで主要画面と基本の流れを確かめ、本開発へ進まない場合は費用はかかりません。
プロトタイプは方向性確認用です。本番利用、実データでの本番運用、本番用アカウント・権限・監視・バックアップ、外部サービスとの本番接続、性能・可用性の保証は含みません。
方向性確認用プロトタイプ:0円
主要画面と基本の流れを確認します。本番利用はできません。
本開発着手:150万円(税別)
範囲・受入条件・予定・変更境界を契約で合意し、着手金の入金確認後に本開発を開始します。
受入確認合格後:残金150万円(税別)
合意した必須受入条件に合格し、主要な未解決不具合がないことを確認した後に請求します。
残金の入金確認後に本番利用を開始
各税別額に法定税率の消費税を別途加算します。
知式の責任で必須受入条件を満たせない場合は、合意した期間内に是正し、再確認します。それでも満たせない場合、残金150万円(税別)は発生しません。着手金は、実施済みの設計・実装等の対価として自動返金しません。お客様の資料未提出・確認遅延、合意後の仕様変更、標準範囲外の追加、第三者サービスに起因する事象は、知式責任の受入不合格とは分けて扱います。
月10万円(税別)は、本番利用開始後のシステム利用と標準運用の料金です。新機能、業務ルールの変更、二つ目の対象業務、大規模なデータ移行、外部連携、高い保証、買い取り・他社移行支援は別途お見積りします。
お申し込みが一定数に達した場合、以後の新規お申し込み分から価格を改定することがあります。すでに契約で合意した金額は変更しません。
システム・アプリ開発300万円〜として、対象業務・範囲に合わせて個別にお見積りします。個別見積りの金額は、固定プランの総額300万円(税別)を上限とするものではありません。
すでに契約で合意した金額は変更しません。お申し込みが一定数に達した場合は、以後の新規お申し込み分から価格を改定することがあります。
業務基盤システムの更新時期が来ても、今の仕組みをそのまま移せばよいとは限りません。使われていない機能が残る一方で、現場が別の表や手作業で補っていることもあります。
知式は、今も必要な業務、止まりやすい場面、担当者しか知らない判断を確認します。既製サービスで足りるのか、一部だけ作るのかも含めて、何を変えるべきかを整理します。
現行の機能をそのまま移すべきか、周辺業務を見直すべきか、判断材料がそろっていない。
作った担当者や以前のベンダーが不在で、不具合や業務変更があっても改修できない。
条件、例外、確認待ちが複数の表やシステムに分かれ、担当者へ聞かないと現在の状況が分からない。
実装前に、業務とのずれを減らす
ご要望をそのまま機能一覧へ変えません。現場の帳票や画面に記録されている事実を確認し、何を管理し、業務上の情報・出来事・判断がどう関係しているかを整理してから設計します。
売上、納期、品質、引継ぎなど、今回の仕組みで改善したい成果と、関係者、守る条件を整理します。
現場で使われている言葉と番号から、管理する情報と業務上の関係を確認し、実際の業務に合う設計を作ります。
この設計図をもとに、画面・処理・データを弊社が設計、実装、テストします。
ここで生まれる疑問
いいえ。知式の業務整理は、現在の手順をそのまま図にする作業ではありません。企業が管理する対象と、事業で起きる出来事、それらの関係を構造として捉えます。
何を管理し、どんな出来事が起き、それらがどう関係しているかを明らかにします。
既存システムや組織の都合で続いている手順と、事業に必要なルールを分けて考えます。
これまで結びつけていなかった管理対象と出来事を組み合わせ、新しい提供方法、顧客との関わり方、収益の仕組みを検討します。
現状を正確にシステム化するだけでなく、経営戦略に合わせて業務を組み直し、新しい価値やビジネスモデルの可能性を、実行できる仕組みへ落とし込めることが、この設計の利点です。
具体的なご相談例
これらはご相談の一例です。業種や業務名が決まっていなくても、今の困りごとからご相談いただけます。
作るものを先に決めず、何が止まり、誰に負担がかかり、何を変えたいのかから確認します。
From Current Problems to a Workable System
今のシステムで使えている部分は残し、手作業や二重入力、
確認待ち、担当者頼みになっている部分を見直します。
※ 画面は業務アプリの一例です。実際の画面・項目・処理は、対象業務と利用者に合わせて設計します。
今の仕組みをそのまま移す、既製サービスへ替える、必要な部分だけ作る。それぞれを業務に照らして比べます。
誰が担当し、今どの状態で、次に何をするのかを、必要な人が同じ情報から確認できるようにします。
何を待っているのか、なぜ戻ったのか、期限を過ぎていないかを一覧で確認できるようにします。
業務に必要な情報が複数の表やシステムへ分かれている状態を見直し、確認先を減らします。
通常と違う処理、特別な確認、差異の理由を記録し、後から経緯を追えるようにします。
必要な履歴、取引先、商品、権限、判断ルールを確認し、新しい仕組みへ移す範囲を決めます。
WORK REVIEW
更新時期、改修できない箇所、二重入力、確認待ちなど、実際に負担が出ている場面を確認します。
SCOPE DECISION
今も使えている部分、やめる機能、既製サービスで補える部分、個別に作る部分を分けます。
DEVELOPMENT & REVIEW
個別開発が必要な部分を、業務アプリ・業務システムとして作り、利用場面に合わせて直します。
MIGRATION & ACCEPTANCE
必要なデータと業務ルールを移し、実際の担当者が日々の仕事を進められるか確認します。
業務担当者が6週間、週15時間を使ってAIへ指示し、限定した1業務で動く小さな業務アプリを作る導入支援もあります。弊社が完成品を納品する方式ではなく、社員が次の小型ツールも作れる能力を社内へ残す方法です。
限定した1業務で動く小さな業務アプリ、AI開発環境、変更・テスト手順を作り、社員が次の小型ツールへ自力で進めることを確認します。
社員がAIで作る支援を見る更新時期、直せずに困っていること、今どこで仕事が止まるか。分かる範囲からお知らせください。
何を作るかを決める前に、今の業務で困っていることを確認します。既製サービスで足りるのか、個別開発が必要かも含めて整理します。
既製サービスで解決できるなら、その選択肢も比べます。個別開発が必要な場合だけ、業務に合わせたアプリやシステムを作ります。更新後も、社内担当者や別の保守会社が状況を確認できる形を目指します。
システムの更新時期、改修できない業務、
進捗や確認待ちの悩みを、分かる範囲でお聞かせください。
※ 通常2営業日以内にご返信いたします。