OTSUMU KNOWLEDGE
業務システム・Excel脱却.
知ることを、事業を動かす力へ。
検証・開発・運用の現場で使える知識を集めました。
25件のナレッジ
該当するナレッジはありません。
稟議・申請承認ワークフローのシステム化：設計と導入の手順
稟議・申請承認のシステム化で成否を分けるのは、代理承認・差し戻し・組織変更などの例外処理の設計です。承認ルールの整理、例外処理の決め方、既製品と個別開発の比較、導入の8つ…
続きを読む ↗業務システム開発の進め方：現場ヒアリングから運用定着まで
業務システム開発は、現場の実際の動きと例外処理を正しく集め、段階的に導入して定着させるまでが一連の仕事です。ヒアリングの進め方、要件の絞り方、導入方式の比較、運用定着ま…
続きを読む ↗CRMを自社開発すべきか：Salesforce・HubSpotとの比較と判断軸
CRMを自社開発すべきかは、既製CRMの設定で業務が表現できるか、業界特有の取引構造や他システムとの連携が中心にあるかで決まります。Salesforce・HubSpotなど既製品との比較軸、判…
続きを読む ↗顧客データ移行の手順：Excelや旧CRMから新システムへ移す注意点
顧客データ移行は、取り込む前の整理と移行テストで成否が決まります。Excelや旧CRMから新システムへ移すときの範囲決め、項目の対応表、重複と表記揺れの整理、移行テスト、切り替…
続きを読む ↗顧客管理システムの設計：顧客データの項目と名寄せの考え方
顧客管理システムの設計では、法人・担当者・取引の関係をどう持つか、どの項目を必須にするか、重複データをどう名寄せするかを先に決めることが重要です。データ構造の考え方、項…
続きを読む ↗日報・報告業務のシステム化：入力が続き活用される仕組みの作り方
日報のシステム化は、書かせるだけでなく集計・フィードバック・ナレッジ化まで設計すると定着します。形骸化の原因、目的別の項目設計、入力が続く工夫、活用される仕組み、既製ツ…
続きを読む ↗Excelデータをシステムに移す前のデータ整備：重複と表記揺れ対策
Excelデータを新しいシステムへ移す前には、全角半角・表記揺れ・結合セル・重複データの整備が欠かせません。問題の種類別の直し方、機械処理と人の判断の分け方、8つの手順、再発…
続きを読む ↗Excelマクロの属人化を解消する：VBA業務のシステム移行の進め方
作った人しか直せないExcelマクロは、作り直す前に処理内容を業務の言葉で書き出すことが移行の第一歩です。属人化のリスク、マクロの棚卸しと優先順位づけ、入力・出力・例外の洗い…
続きを読む ↗Excel業務をシステム化する手順：失敗しない移行の5ステップ
Excel業務のシステム化は、棚卸し・整理・要件化・段階移行・定着の5ステップで進めると失敗しにくくなります。Excelをそのまま再現せず、不要な作業とデータを減らしてから要件を決…
続きを読む ↗GAS（Google Apps Script）で作る社内ツールの限界と移行の目安
GASで作った社内ツールは、実行時間の制限・権限とアカウント・保守担当の不在が業務の重要度に見合わなくなったときが移行の目安です。限界の種類とサイン、継続・改善・移行の判断…
続きを読む ↗社内ポータル・ナレッジ共有ツールを作るときの設計のポイント
使われ続ける社内ポータルの条件は、情報の探しやすさ・鮮度・適切な権限の三つです。使われなくなる原因、載せる情報の整理、目的別の分類と検索、更新責任の決め方、権限設計、構…
続きを読む ↗社内ツールを開発する前に：内製・ノーコード・外注の選び方
社内ツールの作り方は、利用人数・仕様の変更頻度・業務上の重要度・保守できる人の有無で選ぶのが基本です。内製・ノーコード・外注それぞれの特徴と費用の考え方、判断基準、作る…
続きを読む ↗Excelの在庫管理が限界になるサインと、システム化の進め方
Excelの在庫管理が限界かは、在庫の数字を信じられなくなっているかで判断できます。同時編集の待ち、帳簿と実数のずれ、集計の遅れなど8つのサイン、Excelのままできる改善、入出庫…
続きを読む ↗在庫管理システムの費用：クラウドサービスと受託開発の比較
在庫管理システムの費用は、クラウドサービスか受託開発かでかかり方が大きく違います。費用の内訳、業務の独自性と連携要件による比べ方、手作業の人件費を含めた数年の総費用の試…
続きを読む ↗kintoneの限界はどこか：スクラッチ開発に移行する判断基準
kintoneの限界は、レコード数・複雑な計算・細かい権限・外部連携で運用の複雑さが利点を上回ったときに訪れます。限界のサイン、継続・併用・移行の判断基準、4つの選択肢とスクラ…
続きを読む ↗Salesforceの費用が重いときの選択肢：移行・併用・自社開発
Salesforceの費用が重いときは、まず使っていないライセンスと機能の棚卸しから。残る・軽いCRMへ移行・一部を自社開発して併用・全面自社開発の4つの選択肢を、費用の全体像と業務…
続きを読む ↗スプレッドシート管理からWebシステムへ移る判断基準と費用感
スプレッドシートからWebシステムへ移るべきかは、同時編集・権限・変更履歴・入力ミスの影響で判断できます。限界のサイン、SaaS・ノーコード・スクラッチの選び方、費用が決まる要…
続きを読む ↗業務システムが現場で使われない原因と、定着させる導入の工夫
業務システムが現場で使われない原因の多くは、入力負担、旧業務の併存、使う理由の不在にあります。定着を妨げる要因の見分け方、導入前後に打てる対策、利用状況の測り方、現場を…
続きを読む ↗As-Is/To-Be分析で業務システムの要件を固める進め方と注意点
As-Is/To-Be分析は、現状業務をそのままシステムに写さず、あるべき姿との差分から要件を決める方法です。現状把握の範囲、To-Beの描き方、差分を要件と運用変更に振り分ける手順、…
続きを読む ↗バーコード・QR読み取りで在庫管理を効率化するシステム設計
バーコード・QR読み取りの目的は、作業の速さより記録の間違いと漏れを減らすことです。ラベル運用、読み取るタイミング、ハンディ端末とスマホの選び方、間違いに気づける画面の作…
続きを読む ↗業務フロー図の書き方：システム化の前に現状を可視化する手順
業務フロー図は、担当者・作業・判断・帳票を一枚に並べ、システム化すべき箇所を見つけるための道具です。書く前の準備、記号とレーンの決め方、ヒアリングから清書までの手順、図…
続きを読む ↗営業がCRMに入力しない問題：入力負担を減らす設計と運用の工夫
営業がCRMに入力しないのは意識ではなく設計の問題です。入力項目の絞り込み、問い合わせやメールの自動取り込み、日報の自動化など入力した人が得をする仕組み、会議の進め方の変え…
続きを読む ↗在庫管理システムの作り方：必要な機能と自社開発の判断基準
在庫管理システムは、在庫の数字を誰が何に使うかから決めるのが近道です。入出庫・棚卸し・ロット・発注点・引当など必要な機能の整理と優先順位、クラウドサービスで足りるか自社…
続きを読む ↗複数倉庫・複数チャネルの在庫を一元管理するシステムの設計
複数倉庫・店舗・ECの在庫一元管理は、どの在庫をどの販売先にいつ時点の数字で見せるかの設計で決まります。実在庫・引当済み・販売可能数の区分、引当ルール、同期の方式とタイミ…
続きを読む ↗パッケージ導入のフィット＆ギャップ分析：カスタマイズを減らす方法
フィット＆ギャップ分析は、パッケージの標準機能と自社業務の差を洗い出し、業務を合わせるか、設定や周辺開発で埋めるかを決める作業です。分析の手順、ギャップの分類と対応方針…
続きを読む ↗FROM KNOWLEDGE TO ACTION
知識を、次の一手に。
新規事業の検証からMVP開発、運用の自動化まで伴走します。
事業について相談する ↗ 事業開発支援を見る ↗