案件管理システムを比べる前に、自社の「案件」を定義できていますか

案件管理システムを導入しようと、いくつかの製品を比較し始める。多くの会社が、ここから検討を始めます。機能を比べ、料金を比べ、評判を調べる。ところが、製品を比べる前に、もっと大事な確認が抜けていることがあります。それは、自社にとっての「案件」とは何か、という定義です。

案件管理システムは、たいてい「1つの案件」を1つの単位として管理する作りになっています。案件を登録し、進捗を追い、完了させる。このモデルは、案件の形がシンプルな会社では、きれいに機能します。問題は、自社の案件が、システムの想定する「1つの案件」という形に、そのまま収まらない場合です。このズレに気づかないまま製品を選ぶと、導入してから「自社の案件の管理に合わない」と気づくことになります。この記事では、既製の案件管理システムが想定する案件の形と、現実の案件がどうズレるのか、そしてそのズレにどう対処すべきかを整理します。

案件管理システムが想定している「案件」の形

まず、多くの案件管理システムが、どういう案件を前提に作られているかを見ておきます。

一般的な案件管理システムのモデル

一般的な案件管理システムは、「1つの案件」を、1つのまとまった単位として扱います。案件を登録すると、その案件に対して、進捗、担当者、金額、期日などが紐づく。案件は受注から始まって、進行し、完了する。この、案件が一つの直線的な流れをたどる、というモデルが、案件管理システムの基本的な発想です。

このモデルは、案件の構造がシンプルな業種では、よく機能します。一つの案件が、明確に区切られていて、受注から完了まで一本道で進み、完了したら終わり。たとえば、案件ごとに作業内容がはっきり分かれていて、それぞれが独立して進むようなビジネスでは、この形がぴったりはまります。実際、IT開発やコンサルティング、制作業など、案件がプロジェクトとしてきれいに区切られる業種向けに、優れた案件管理システムが数多く存在します。

問題は、自社の案件が、この「1案件=1つの直線的な単位」というモデルに、収まらない場合です。現実の案件は、もっと複雑な形をしていることがあります。次に、どういうズレが起きるのかを、具体的に見ていきます。

現実の案件は、システムの想定からこうズレる

案件の構造が一対一でない

既製の案件管理システムの想定と、現実の案件が、どうズレるのか。よくあるパターンがいくつかあります。

ひとつは、案件の構造が、一対一でないことです。たとえば、1つの契約の下に、複数の現場がぶら下がることがあります。契約は1つなのに、実際に動く現場は3つ4つあって、それぞれ進捗も担当も違う。これを、1案件=1レコードのシステムで管理しようとすると、無理が出ます。契約単位で管理すれば現場ごとの進捗が見えないし、現場単位で管理すれば契約全体がバラバラになる。さらに、案件が途中で分かれることもあります。最初は1つの案件だったものが、進めるうちに複数に分割される。逆に、別々だったものが統合されることもある。案件が固定された1つの単位であることを前提としたシステムは、こうした分裂や統合を、うまく扱えません。

完了が一度で終わらない

もうひとつは、完了が一度で終わらないことです。多くのシステムは、案件に「完了」のステータスがあって、完了したら、その案件は終わり、という作りになっています。でも、現実には、完了したように見えて、終わっていない案件があります。たとえば、現場の作業自体は完了しても、その後に実際の経費が確定して、はじめて最終的な完了になる、というケースです。作業完了と、経費確定による最終完了の、二段階がある。単純な完了フラグしか持たないシステムでは、この「完了したけれど、まだ確定していない」という中間の状態を、表現できません。結果、完了にしてしまうと経費の確定が追えなくなり、完了にしないと終わった案件が一覧に残り続ける、というジレンマになります。

この二段階の完了は、案件の本当の利益を把握する上で、決定的に重要です。作業が終わった時点では、まだ最終的な経費が出揃っていない。後から請求や支払いが確定して、はじめて、その案件が本当はいくら儲かったのかが分かる。ところが、システム上で作業完了と同時に案件を閉じてしまうと、その後に確定する経費が、どの案件のものか追えなくなる。すると、案件ごとの本当の採算が、いつまでも正確には見えない。完了の扱いが雑なシステムは、見た目の進捗管理はできても、肝心の「その案件は儲かったのか」という問いに、答えられないことになります。

外部のパートナーが絡む場合

そして、外部のパートナーが絡む場合です。案件が自社内だけで完結せず、外部のパートナーや協力会社が関わると、管理の形が変わります。パートナーとの間の発注や情報のやり取り、パートナー側の進捗、パートナーへの支払い。こうした、自社の外にまたがる要素は、自社内の案件進行を前提に作られたシステムの想定の外にあることが多い。外部が絡む案件を、社内案件と同じ仕組みで管理しようとすると、肝心のパートナーとのやり取りの部分が、システムの外で手作業になってしまいます。

しかも、外部パートナーが絡むと、進捗の把握が一気に難しくなります。社内なら、担当者に聞けばすぐ分かる進捗も、パートナー側の作業は、連絡を取らないと見えない。電話やメールで都度確認し、それを自社のシステムに手で転記する。この、外部とのやり取りを人が仲介してシステムに反映する作業が、案件が増えるほど膨らみます。本来、案件管理システムは進捗を一目で見えるようにするためのものなのに、外部が絡む部分だけは、相変わらず人が走り回って情報を集める、という状態が残ってしまう。

これらのズレは、自社の業務が特殊だから起きるのではありません。多くの会社の案件は、本来こうした複雑さを持っているのに、既製のシステムが、扱いやすい単純な形だけを前提にしているから、ズレるんです。

なぜ、既製システムはこの複雑さを扱えないのか

既製の案件管理システムが、こうした複雑さを扱えないのには、理由があります。

既製のシステムは、多くの会社で使えるように、案件管理の共通部分を抽出して作られています。「案件を登録し、進捗を追い、完了させる」という、ほとんどの会社に共通する骨格です。この共通の骨格に絞ることで、安く、多くの会社に提供できる。これは、既製システムの合理的な設計です。

ところが、案件の複雑さ、つまり、案件の構造がどうなっているか、完了がどう定義されるか、外部がどう絡むかは、会社ごとに大きく違います。この「会社ごとに違う部分」は、共通部分ではないので、既製システムの標準機能には含まれていません。だから、自社の案件が、共通の骨格から外れる複雑さを持っていると、既製システムでは扱いきれない。

そして、扱いきれない部分は、結局、システムの外で管理することになります。システムでは案件の大枠だけを管理して、複数現場の対応関係や、経費確定の追跡や、パートナーとのやり取りは、Excelや手作業で補う。これでは、案件管理システムを入れたのに、肝心の複雑な部分は相変わらず人が抱えたまま、ということになります。システムと手作業が併存して、二重管理になり、かえって手間が増えることすらあります。

ここで起きるのが、システムへの信頼の低下です。システムを見ても、複雑な部分は反映されていないから、結局、本当の状況はExcelや担当者の頭の中を見ないと分からない。そうなると、現場は「システムを見ても意味がない」と感じ、入力もおろそかになる。入力されないシステムは、ますます実態と乖離していく。せっかく導入した案件管理システムが、使われない箱になってしまう。これは、システムが悪いというより、自社の案件の形に合わないものを選んでしまった結果です。この、入力されなくなって実態と乖離していく構造については、既存SaaSが現場に定着しない理由で詳しく書いています。

だから、まず自社の「案件」を定義する

ここまでを踏まえると、案件管理システムを選ぶ前にやるべきことが見えてきます。製品を比較する前に、自社にとっての「案件」とは何かを、はっきり定義することです。

自社の案件は、1つの単位できれいに区切れるのか、それとも1つの契約に複数の現場がぶら下がるのか。案件は一本道で進むのか、途中で分かれたり統合したりするのか。完了は一度で終わるのか、経費確定などの二段階目があるのか。外部のパートナーは絡むのか、絡むならどう管理する必要があるのか。こうした、自社の案件の実際の形を、言葉にして整理する。

この定義ができていれば、製品を選ぶときの基準がはっきりします。自社の案件の形を、その製品が扱えるかどうかで判断できる。逆に、定義をしないまま、機能の多さや料金だけで製品を選ぶと、導入してから「自社の案件の形に合わない」と気づくことになる。製品比較は、自社の案件を定義した後の話です。

この「自社の案件を定義する」という作業は、システム選びのためだけのものではありません。やってみると、自社の業務そのものの理解が深まることが多い。案件がどう始まり、どう枝分かれし、どう終わるのか。誰が関わり、どこで利益が確定するのか。これを言葉にする過程で、これまで担当者の頭の中だけにあった案件の進め方が、はっきりと見えるようになる。案件の定義をするということは、自社の仕事の流れを、改めて整理するということでもあります。だから、たとえ最終的に既製システムを選ぶとしても、この定義をやっておく価値はあります。

そして、もし自社の案件が、既製のシステムでは扱えない複雑さを持っているなら、選択肢は2つです。複雑な部分を諦めて、既製システムに合わせて業務を単純化するか、自社の案件の形に合わせて、システムを作るか。案件の複雑さに、業務上の理由があるなら、つまり、複数現場も、二段階の完了も、外部パートナーとの連携も、その会社のビジネスに必要だから存在しているなら、それを無理に単純化するのは、現場を苦しめます。その場合は、自社の案件の定義に合わせて作るほうが、結果的にうまくいきます。

ただし、すべての会社が、自社専用のシステムを必要とするわけではありません。自社の案件を定義してみた結果、それが既製システムの想定する単純な形に収まるなら、既製システムを使うのが、いちばん手軽で安い。大事なのは、定義もせずに製品を選んで後悔することを避け、自社の案件の形を分かった上で、既製で足りるのか、作るべきなのかを判断することです。費用の面から見た案件管理システムの選択肢は、案件管理システムの費用相場で整理しています。

自社の案件の形を定義してから製品を選ぶ

案件管理システムを選ぶとき、多くの会社は製品の比較から始めますが、その前に、自社にとっての「案件」とは何かを定義することが先です。既製の案件管理システムは、案件を1つの直線的な単位として扱う前提で作られていることが多く、1つの契約に複数の現場がぶら下がる、案件が途中で分かれる、完了後に経費が確定する、外部パートナーが絡む、といった現実の複雑さに、収まらないことがあります。自社の案件の形を定義して初めて、その複雑さを既製システムで扱えるのか、それとも自社に合わせて作るべきなのかを、判断できます。