こんにちは、私の名前はセルゲイであり、私はDoksVisionの製品ラインの責任者です。 電子文書管理の分野での仕事中に、数十の実装プロジェクトに参加し、さまざまな役割（エンジニアからプロジェクトオフィスマネージャーまで）、さまざまな側面（顧客、実装会社の代表者、ベンダー）およびさまざまなシステム（DocsvisionおよびDirectum）に参加しました） 私のプロジェクトの経験をあなたと共有したいです。

プロセスを理解し、一連のコーンを詰めて、EDMSを実装するプロジェクト（ITシステムなど）でよりスムーズに準備して実装できるようにするためのいくつかの推奨事項を記事に示します。 私の同僚はすでに、実装を担当する顧客のITスペシャリストに助言しています 。 質問を別の角度から見て、インテグレーター会社が考慮すべき多くのニュアンスを共有します。 特に最初の実装プロジェクトに直面している場合。 この記事が役立つことを願っていますが、多くの「熊手」を時々独力で踏む必要があり、プロジェクトの実践には理想的なレシピはありません。

開始するには...

しかし、私たちはプロジェクトから始めるのではなく、プロジェクトに来ることから始めます-詳細のクライアントとの議論、提案の準備、契約の締結。 すでに注意を払うべきことがたくさんあります。なぜなら これが最初に設置されるレンガで、建物全体の安定性に影響を与える可能性があります。

「そして彼らは私に約束した...」
契約を締結する前にクライアントとプロジェクトを議論する段階での大きな間違いの1つは（特に大規模なインテグレーターの間では一般的です）、将来のプロジェクトマネージャーが不足していることです。 それがなければ、いくつかの合意（彼はプロジェクトの最後ではないとしてもよく知っています）、プロジェクトのタスクと目標の異なる解釈などがあります。 これが表示されると、顧客はテーブルで彼をpunchり、約束されていると言い始めます...実際には約束はないかもしれませんが、プロジェクトマネージャーが議論中に出席しなかった場合、彼はこれらの契約を理解することができません。

そのようなケースがいくつかありました。 私が実際に既製のボックスソリューションでパイロットプロジェクトを行っていた大企業Nで、ITディレクターが突然「ボックス」を置くことを決めましたが、それについては大きなカスタムプロジェクトを行うことにしました「同意しました」。 カスタム開発の価格が数倍高いという事実は彼を悩ませませんでした。 このケースや同様のケースで、私たち自身で顧客を納得させることができなかった場合（そして、よく起こりました）、私は単に対立を手配し、「同意した」人を連れてきました。 主なことは、たるみを与えず、最後まで自分の立場を守ることです。

青少年チーム
もう1つの重要な問題は、プロジェクトチームの編成です。 人を選ぶという点ではそれほど重要ではありませんが（これは重要ですが、それについては重要ではありません）、むしろ顧客にチームを紹介し、彼のチームを知るためです。 原則として、チームを不在で提示するだけで十分です。 両側で誰が何をしているかを説明するドキュメントが表示されます。 一般的な推奨事項：あらゆる種類の紙片を作成し、顧客の責任ある代表者と署名することをheしないでください。ある時点で、これはあなたを大いに助けることができます。

計画は単純なものです...
依然として「上陸」しているため、作業範囲に同意することが重要です。 もちろん、システムの詳細な要件についてではなく、設計作業のトップレベルのリストについてです。 プロジェクトの1つで、このカレンダープランのようなものに出会いました。



経験豊富な人は、ほとんどの場合、質問をするだけです。 すぐにではない場合は、後で、また、作業の複雑さが200時間であるのに対し、プロジェクトチームには1人しかいないのに、システムのユーザーとのミーティングを一切行わない理由などを説明し始めます。
誰もこれらの人件費を必要としません、プロジェクトのコストはすでに知られています、ここでこの情報は示唆にすぎません.... この段階の作業計画には、最も詳細な作業範囲（トップレベルのリスト）と、たとえば次のような日付を参照したプロジェクトの主な段階を反映する必要があります。



より速く。 上。 より強い
プロジェクトの開始前であっても、目標と目的を明確に話し合い、修正する必要があります。これは今後のすべての作業に影響を与える可能性があります。 たとえば、合意の交渉プロセスを高速化し、このプロセスを透明にすることは完全に異なる目標であり、目標が単に「自動化」される場合、これら2つのような100,500を理解できます。 顧客の期待を誤解すると、プロジェクト全体の評価を見逃す可能性があり、最終的には、顧客が満足していても不採算になります。 あまりにも一般的な目標を詳細に説明し、問題の一番下に到達してください。

「男の子はいたの？」
最初に、「自動化するものはありますか？」という質問に対する答えを正確に知る必要があります。おそらく、「EDMSを実装し、同時に内部プロセスを最適化したい」と言われたときに、それについて自分で知っているでしょう。 よくこれを聞いた？ 内部プロセスは最適化されていませんが、もちろんプロジェクトの最初の段階がコンサルティングでない限り、そこで行うことは何もありません。 「カオスを自動化することはできません」という一般的な表現があるのも不思議ではありません。自動化は最適化の後にのみ行われます。 顧客がそのようなことを並行して行いたい場合、これはあなたにとって驚くべき鐘になるはずです。つまり、プロジェクトを編成するプロセスに慎重にアプローチする必要があることを意味します。 今、振り返ってみると、私がこのようなプロジェクトに関与することはもうありません。特にそれが私の最初のプロジェクトである場合は特にそうです。

この問題に関連する悲しい経験がありました。 それは大企業Zの問題であり、プロジェクトの開始時に、同時にプロセスを最適化する必要があるというインストールが与えられました...同時に、意思決定者の不足によりすべてが非常に複雑になりました（これはプロジェクトチームとそのメンバーの責任/責任に関するものです）。 しかし、これについては後で詳しく説明します。

「一度、寒い冬の季節に...」
...私たちは大企業Yのユーザーにインタビューし、セキュリティ部門のオフィスに入りました...私たちはそこを去り、システムの要件を収集し、プロジェクトを完了する大きなチャンスを得ました。 セキュリティ担当者は、システム、そして実際に当社がセキュリティ要件を満たしていることへの疑念を表明し、一般に誰も質問していないと述べました。
なぜ私はこれをしていますか。 プロジェクトが誰に影響を与える可能性があるかを慎重に検討し、事前にそれらに行き、すべての論争のある問題について話し合います。 結局、すべてがうまくいき、質問は解決し、システムはすべての要件を満たし、作業を続けましたが、すべてが悪化する可能性がありました。

誰がこれをすべて必要としますか...
多くの場合、ほとんどのユーザーは、自分のシステムを彼らが自分に課したものが何であるかを明確に認識していないという事実に直面しなければなりません。 最初、私はこれに非常に驚きました。会計システムを導入する前は、これに遭遇したことがなかったからです（ただし、会計士にとってはシステムが主要な作業ツールであり、原則としてそれなしでは機能しません）。 どうやらこれはあるように思えますが、最終的には事件は妨害行為で終わる可能性があります。
このような問題を回避するために、トップマネジメントの支援を求めることをお勧めします。または、少なくともプロジェクトの開始には、会社の注文の発行を伴う必要があります。
何らかのプロパガンダ作業を実行できれば、プロジェクトの目標と目的をエンドユーザーに伝えることができます。最終的に何が得られるのか、なぜ必要なのかを説明できます。 少なくとも部門長のサポートを得ることができます-あなた自身の問題の数を減らすことができます。
もちろん、これがどれも不可能な場合もありますが、頼れるのはプロジェクトマネージャーのスキルだけです。 上で言ったように-紙に署名することをためらわないでください。変更は紙の上に同意して記録しなければなりません。難しい瞬間にプロジェクトを救うことができます。

はじめに...

原則として、EDMSの導入は設計段階から始まります。設計段階では、将来のシステムの詳細な技術タスクが準備され、合意されます。 おそらく、これは最も問題の少ない段階です。なぜなら、顧客に何が起こったのかを強制することはまだできないからです。しかし、この瞬間が来ると、問題が始まります。
原則として、顧客はトレーニングで、またはすでに試運転の段階で、場合によってはシステムが恒久的に稼働しているときでも、結果を見るという事実に関連しています。 それ以前は、すべてが紙の上にしかありませんでしたが、文字とメガバイトはまったく別のものです。

考えるべきことは何ですか？
システム設計の初期段階で入門トレーニングを提供します。 主要なユーザー、プロジェクトグループ（これらは、エキスパートとして機能し、システムの要件の構成を形成するユーザーです）、システム、そのメインインターフェイス、機能、基本的な作業シナリオ、カスタマイズ機能を示します。
しかし、これでは十分ではありません。

プロジェクトの1つで、これを行った請負業者が、今では誰もが製品を非常によく知っていると判断し、プロセスを大幅に簡素化できるという事実に直面しました。 特に、技術的なタスク全体は、実証された内容に関する変更（設定）の説明でした。 このようなイベントを開催することはお勧めしません。会議の質や人々によって異なりますが、相互理解を深めるためにユーザーと共通言語を見つけようとするだけです。 これは万能薬ではありません。間違えないでください。1週間後にそのうちの1つが何かを覚えると思います。

より多くのユーザーインターフェイス。 前の段落で説明した大規模な展開のプラクティスでは、目標をまったく達成できない場合があります。 プロセスでユーザーとより密接にコミュニケーションをとるのが適切です。小さなデモンストレーションを行い、すべてを明確に示し、「文字」ではなく「写真」で説明し、プロトタイプを適用します（これは、Docsvisionなどの高度なインターフェース構成ツールを備えたシステムで、プログラミングなしでインターフェースを作成できるようにします）、そしてもちろん、本格的な技術タスクを作成します。

参照条件：「すべての人のために」詳細な説明を行います。 上記に加えて、TKの設計に関する別の推奨事項があります。 もちろん、それは純粋に個人的なものであり、GOSTなどによると、会社が認める基準や規則に従って、誰もが独自の方法で記述しますが、どのように書くかではなく重要です。 多くの場合、このドキュメントは一般ユーザー（たとえば、書記官）によって同意されているため、技術言語で記述するのは間違いかもしれません。 このようなドキュメントに記載されているシステム設定と構成は一貫している場合がありますが、合意された内容を理解していないことは確かです。 2つのブロックを明示的に区別して説明する慣行があります。1つ目は、作業シナリオの説明です。 システムで誰が、何を、どのように行うか。 2番目はすでに設定の説明です。

誰がどのようにシステムをサポートし続けるかを考えてください。 選択したプラットフォームの標準機能とそのカスタマイズの通常の手段を使用すればするほど、顧客がサポートできるすべての設定の大部分が、このサポートがより安く簡単になります。 この修正またはその修正を求められたら、この考えを伝え、同時に顧客がこの追加フラグから受け取る特定の経済効果を見つけます。 2つの数値を比較すると、彼は拒否する可能性があります。

上で約束したように、お客様が実装と同時に内部プロセスを最適化したい場合、この段階で何が起こるかを説明します。 そのため、大企業Xでは、EDMSを導入すると同時に、ほぼすべての部門に影響を与える内部プロセスを再設計しています。 私の意見では、このプロジェクトで書いた請負業者の「間違った」行動のほとんどをこのプロジェクトが収集したとすぐに言わなければなりませんが、それは異なっていました。 プロジェクトワーキンググループが形成され、責任者が任命され、会社に命令さえ出されましたが、このワーキンググループには意思決定者がいませんでした。 より正確には、彼は正式でしたが、高い雇用のために、システム要件に捧げられた無限の会議に常に出席していませんでした、そして本当に無限に見えました：同じ質問を何度も先延ばしにし、外出先ですべてを単純化する方法を考え出しました反対に、複雑になりますが、何かを承認する必要があるとすぐに、全員が手を洗いました。 私たちは合意したものの論文を定式化して調整しようとしましたが、それが技術的なタスクになったとき、または関連するプロセスを議論する会議が開催されたとき、すべてが再び根本的に変わる可能性があります。

どういうわけかこのプロセスを止めるために、私は同じ意思決定者のために走り、この決定を得るか、次の会議に電話しようとしました。 もちろん役立ちましたが、最速の選択肢ではないことが判明し、すべてが非常に引き伸ばされました。 私は請負業者と会社の間で公式の通信を開始しませんでした。すべてがかなり友好的な雰囲気になり、制裁は期待されなかったが、反対は関係の悪化につながる可能性があるためです。

この状況で何ができるかを考える機会を全員に与えます。

そのような行動は、誰も意思決定の責任を負いたくない場合、少数の組織では一般的ですが、発生するため、このために準備する必要があります。 契約の中で顧客による意思決定を修正し、可能であれば承認条件を規定します。これにより、少なくとも顧客が訓練され、プロジェクトのリスクが最小限に抑えられます。

道路の真ん中のどこかに......

設計作業が完了すると、システム開発フェーズが続きます。 ここでアドバイスできるのは、この段階を「ブラックボックス」にしないでください。 技術的なタスクに同意した後、1か月後に既成のシステムを使用してユーザーをトレーニングし、試用できるようにすることは非常に正常であると考える請負業者と協力する必要がありました。 多くの場合、失敗に終わります。

正直なところ、最初はよく、自分でこれをよくやった、またはほぼそのようにしました（作業中にまだ1つの予備的なデモンストレーションを行いました）。

大企業Zで、EDS自体に注文して、パンの店に行くなど、EDS自体に署名してもらいたいと思ったユーザーに出会ったので、彼女は彼の要求に応じて走らなければなりませんでした。 インタビューの中で、私たちは何か、何がどのように機能するかについて合意したと説明しましたが、彼が文書に同意すると、再び質問が現れました。 この従業員はかなり高い地位にあり、プロジェクトに強い影響を与える可能性がありました。

何が起こっているのかを見て、この会社のCIOは簡単なアドバイスを1つだけ出しました。 これはアドバイスではなく、ユーザーと頻繁に会って話し合い、全員が同じことを理解していることを確認し、デモを行い、ユーザーが私たちを知っている必要があるため、EDMSを実装する誰かに尋ねると、誰もが言う：はい、ここを走り回ります。 セルゲイに電話してください。」

私は抵抗しましたが、そのような作業は計画されておらず、プロジェクトのコストを増加させ、収益性を低下させたため、私たちはそうしたのです。 しかし、私はこのアドバイスに感謝しています-結果として、このおかげでプロジェクトを実現できました。 このユーザーでは、最終的に彼が必要なものに同意することはできませんでしたが、一方で、CEOを含む他のすべての人のサポートを募りました。

ここと以前、主に将来のシステムのユーザーについて話しましたが、顧客のITスペシャリストについても忘れないでください。適切に構築された関係も重要な役割を果たします。 彼らがどのような役割を果たしているかを考えてください-システムにハードウェアを準備し、インフラストラクチャ全体の効率を確保し、トレーニングや試運転などのすべてのアクティビティに技術トレーニングを提供し、ユーザーサポートなどを提供します。

私たちは構築しました...

最後に、すべてが合意され、構成され、配信されました。トレーニングを実施し、システムを試運転するときです。 ここでは、どのデータを実行する必要があるか-実際のドキュメントを実行して処理するか、ドキュメントをテストするかという疑問に遭遇する可能性が最も高くなります。 本当かもしれませんが、同時に紙の形で処理するのですか？ 正しい答えはありませんが、考えるべきことがあります。

テストドキュメントを選択すると、ユーザーはオプションのボタンとして、ボタンを押す必要があるものとして、それらが背後にある場合のみ扱います。 それは何につながりますか？ ほとんどの場合、何も良いことはありませんが、永続的な操作を行った直後に何かが機能しないか、まったく機能しないことがわかります。 結果は理解できると思います。

実際のドキュメントについて話す場合、以前の問題はありませんが、何かがうまくいかず、会社のワークフローに影響を与え、いくつかの結果をもたらした状況が考えられます。 あなたはこれに頭をでられないので、このオプションを選択するとき、あなたは警戒する必要があり、何かが失敗したらすぐに応答します。

テストモードおよび紙でのシステム内のドキュメントの並列処理のオプションにも生命権がありますが、全員が同意するわけではありません。また、エンドユーザーは、二重の作業を行う必要があるため、原則としてエンドユーザーが抗議します。
私にとっては、いくつかの中間オプションを選択する必要があります。たとえば、実際のドキュメントを使用しますが、境界を明確に定義します。ドキュメントの種類を制限し、緊急のドキュメントを実行しません。 いずれにせよ、これは最初に考えて、これがどのように組織化されるかを事前に同意する必要があるものです。

ユーザートレーニングに関しては、 ユーザーが抽象的な「トレーニング」ユーザーではなく、システムの実際の作業を自分自身で模倣し、プロセスを開始して最初から最後まで完全に実行すると、オプションは非常に効果的な方法で表示されました。 この場合、理論的な部分を与えることも最小化することもできません。 ユーザーは教室にいながら、自分の場所で仕事をすることができます。 ただし、後者はドキュメントの後にユーザー間で実行する必要があるため、教師にとってはあまり便利ではありません。
この方法は常に適切であるとは限らず、常に整理できるわけではありませんが、判明した場合、他のオプションよりもリターンが高くなる可能性が高いため、試してください！

あなたが遭遇するかもしれないことについて長い間話すことができます。 私はたくさんの円錐形を満たしました、そして、私はすべてを覚えていません。 実装の規模、組織の範囲、およびその他の要因に大きく依存します。 しかし、主なものはこれではなく、導入されているプラ​​ットフォームではありません（私が遭遇したものの中で機能に大きな違いはないと自信を持って言うことができますが、実装するものを選択するように提案されたら、Docsvisionを選択します） 、しかし適切に組織化された実装プロセス。

他に誰に対処しなければならなかったのだろうか、リストを拡大して経験を共有しましょう。 あなたのプロジェクトで皆さんの幸運を祈ります！