ワークフローシステムを設計したとき、あなたがやろうとしてもしていなかったタスクが、人生によってスローされることがあります。 もちろん、「私たちのシステムはこのために設計されていない」と誇らしげに言うことができ、それは完全に正直なプロの答えになります。 また、ECMの機能を新しい方法で使用する方法や、独自のニッチの境界を超えるリスクを真剣に考えることができます。顧客を満足させ、新しい体験を得ることができます。
ECMシステムが柔軟性と適応性を十分に考慮して設計されている場合、そのアプリケーションの範囲は、事務ワークフローの範囲を超える多くの関連タスクに大胆に拡張できます。 MTOプロセスの自動化-ロジスティクス、従来の決済ERPの侵害？ そして、もし顧客がそれを要求したらどうして？
問題の本質
私たちは、IT担当者の足がまだ踏み出されていない大規模な組織でサービスや部門を見つけることができなくなった時代に生きています。 もちろん、石油会社SANECO（Alliance Oil Companyの子会社）のMTO部門もかつて自動化されていました-独立した1Cがあり、1Cの企業会計システムとも連動せずに独自の独立した生活を送りました。 バイヤーは、部門からExcelファイルでアプリケーションを受け取り、データを自分自身に入力し、既知の手順に従って処理しました。 それ以外は、システムはブラックボックスでした。アプリケーションのステータスに関する情報を取得するには、調達部門に問い合わせる必要がありました。
よくあることですが、調達管理用のカスタム構成1Cの開発者は長くいなくなり、トレースはなくなりました。 一方、新しい要件が出現し、プロセスが変更され、ワークフローとの統合が必要になりました...実際、2つのシステムで作業する場合、情報の重複が避けられないため、最後の要因が決定的な役割を果たしました。
MTOプロセス：アプリケーションはどこから来て、何が起こるか
物流プロセスは必要から始まります。 ユニットの従業員が購入する必要があるものを知ったとき、彼はアプリケーションを作成し、それに必要なポジションを含めます。 実際、アプリケーションは多くのアイテムを購入するための一種のコンテナです。 たとえば、文房具アプリケーションには、ペン、ノート、ステープラーなどが含まれます。
準備されたアプリケーションは調達部門に送られ、そこで必要に応じて評価され、予算に収まるかどうかを確認できるようにイニシエーターに返されます。 さらに、ポジションの計画コストがほぼわかったら、アプリケーションの承認が開始され、そこでさまざまなサービスを通過し、最終的に承認されます。 承認ルートは、MTO部門の事務員が決定します。MTO部門は、開始ユニットからすべての申請を受け取ります。 また、申請書に記入し、それを原価項目に割り当てることの正当性をチェックします。
承認されたアプリケーションは、実行のためにMTO部門に戻され、そこで責任を負う従業員が任命されます。 ここで最も興味深い部分が始まります。アプリケーション内の位置を再グループ化したり、異なる部門のアプリケーションを統合したり、アプリケーションをいくつかの部分に分割したりできます。 その結果、アプリケーションに含まれるすべてのアイテムに基づいて、配信計画が作成されます。 次に、入札が行われ、勝者が決定され、契約が締結され、EDMSで承認されます。 申請者は、開始者が注文したポジションを受け取ったときに実行されたとみなされます。
そして、1Cですべてをしてみませんか
1つのプラットフォームですべての会計タスクを解決するのは理にかなっているようです。組織の主要な会計システムは1Cで構築されているため、物流プロセスは自動化されます。 しかし、いつものように、重要なのは細部にあります。 事実、企業1Cは保有レベルで実装され、モスクワで一元的にサポートされており、調達モジュールはありません。 さらに、これはボックスではなく、高度にカスタマイズされたソリューションであり、Alliance NCの下で強化されており、1人の娘のために誰も一般システムに変更を加えることはありません。 お客様は、MTO部門で「自動化アイランド」を1Cとして保存するように構成されていませんでした。
一方、SANECOはすでに契約管理を含むTESISの電子文書管理を導入しています。 MTOビジネスプロセスの概念は、調達契約が開始者と合意されるべきであることを暗示しており、会計システムよりもEDMSでこれを行う方が論理的です。 次に、契約の最終バージョンを「ビッグ」1Cにアップロードし、そこで会計部門が承認するようにします。
純粋に理論的には、MTOプロセスを自動化するタスクは、主にERPとECMの両方で実装でき、開発の負担を1つまたは別のシステムに移し、それらの統合によるデータ交換を保証します。 しかし、私たちは真空中の球状の馬についてではなく、特定の顧客について話しているので、1Cをアップグレードするオプションは考慮されませんでした。 そして、アプリケーションを開始および調整する多くのユーザーを会計システムに入れる意味は何ですか？ 彼らにワークフローでこれをさせてください、そして、財政に行かないでください。
主題分野の専門知識は利益の問題です
技術的な観点から見ると、新しいタスクは複雑に見えましたが、解決されていました。新しいタイプのドキュメントをシステムに追加し、新しいルートを作成し、ビジネスロジックを追加することです。 一般的に、異常なことは何もありません-優れた監督、対象分野の専門家がいる場合。 MTOプロセスに関する内部専門知識のEDMSの実装に従事している会社がそうではなかったことは明らかです。 しかし、顧客側には、自分たちのトピックを知っていて、ビジネスアナリストとして行動するリスクを冒す用意ができている人々がいました。
実際、双方が初めてこれを行い、コーンを詰めて、このプロジェクトで一緒に成長しました。 もちろん、プロセスを適切に構築する方法と自動化する方法を説明するビジネスコンサルタントを呼び出すこともできますが、第一に、これによりプロジェクトの予算が大幅に増加し、第二に、確かに成功につながるという事実ではありません。 主な優先事項は明確でした。サポートされていない時代遅れのシステムを取り除き、成功したTESIS SEDに基づいてエンドツーエンドのMTOビジネスプロセスを構築し、リーズナブルな価格でそれを行います。
市場で入手可能なボックスソリューションを見てみると、正式に問題を解決していることがわかりましたが、これは非常に不便であるため、人々に使用させることはほとんど不可能でした。 一般的に、すべての恐怖とリスクにもかかわらず、私たちは論文管理システムに調達管理システムを書くことにしました。
どうだった
このプロジェクトは2012年の夏に開始されました。 革新によってユーザーに衝撃を与えないために、彼らは古いシステムから新しいシステムへの段階的な移行を計画しました。 まず、アプリケーションがTHESISで作成され、メールでファイルとして送信されないことを確認しました。 最初の段階では、それらは半自動モードで古い1Cにアップロードされましたが、ベースが分割されていたため、一部のアプリケーションは既にTESISに提出され、一部は1Cに到達したため、ユーザーにとって困難でした。 そのため、新しい年までに、移行期間を遅らせないように、古いシステムを完全に放棄する必要がありました。 実際、それは行われました-新しい年の後、私たちは完全にTESISで働くようになり、1Cを埋めることができました。
対象分野の専門知識がなければ、顧客を管理する機会がなく、本当に必要なものや廃棄できるものを言ったり、要件の矛盾を見つけたりすることができませんでした。 したがって、彼らは彼らに耳を傾け、彼らが尋ねたことをしなければなりませんでした、そして、顧客は、彼の側では、徐々に体系的に考え始めました。 その結果、数か月の「一緒に暮らす」ことによってようやく、本当に必要な情報と、システム内での表示方法が認識され始めました。 しかし、これらの困難にもかかわらず、プロジェクトは期限に耐えることができました。
非標準プロジェクト-製品開発のインセンティブ
非定型プロジェクトで顧客から要求された機能がメイン製品にスムーズに流れ込み、開発に貢献することがよくあります。 MTOプロセスの自動化に関しては、原則として、プラットフォームの標準機能で十分であり、根本的な革新を発明する必要はありませんでした。 つまり、ドキュメントとビジネスプロセスを管理するためのツールは、新しい分野のタスクには十分であり、喜ぶしかありませんでした。
おそらく、レポートをいじる必要がありました。データに応じて拡大する動的な列と行でこのような大きな「チェスボード」シートが形成される場合、分析レポートを作成する必要がありました。 当時、私たちのCUBAプラットフォームはこれを行うことができませんでした。SANECOでのプロジェクトの結果によると、レポートを強化しました。
一般に、次の結論を導き出すことができます。通常のBPMと強固なドキュメント管理モジュールがあれば、そのような会計タスクを引き受けることができます。
私たちに新しい知識を与えるのは何ですか？
販売者が新しいソリューションが登場したことを聞いた場合、すぐに「今すぐ他の顧客にそれを転売し、ボックスをリリースします」と考えます。しかし、残念なことに、それはそれほど単純ではありません。
実際、新しいプロジェクトに取り組むとき、それが何であるか、このビジネスですべてがどのように機能するかを理解するために多くを投資することがわかります。 そして、最終的に何らかの役に立たない、要求されていない知識が得られた場合、費やされた時間は残念になります。 それをどこで使用しますか？ 箱に入れるのは難しく、ERPシステムと正面から競うのは愚かなことです。 しかし、この場合、これを行うことができること、プラットフォームによって通常のワークフローとはかけ離れたそのようなタスクを実装できることを理解することが非常に重要でした。
顧客は常に異なるように見えます-そして、そのようなプロジェクトは潜在的にどんな問題も解決できるという自信を与えます。 エンタープライズ管理では、調達および財務活動は最も複雑なプロセスの1つと見なされます。これらのプロセスには、調整モードだけでなく、情報、統合、何らかの処理などのアクティブな作業が含まれるため、多数のユーザー間の対話が含まれるためです。 そのようなプロジェクトのおかげで、より大規模で複雑なタスクに対応できる自信があります。