ドキュメント管理およびビジネスプロセス自動化システムは、会社の仕事に秩序をもたらすように設計されています。 企業のドキュメントサポートを体系化し、ドキュメントの作業が移動する際の明確で直接的な不変のルートをレイアウトします。 このように、ワークフローシステムは会社の日常業務の混乱と無秩序を合理化し、一定のペースとスケジュールを設定します。
しかし、何かを体系化して整理できるツールを作成するには、まず自分で問題を体系化して整理する方法を学ぶ必要があります。 私たちにとって、主なものはTESISドキュメント管理システムの開発です。 したがって、EDMSのドキュメントの作業のように、システムの新しいリリースの作業も明確なルートに沿って移動することは驚くことではありません。
この記事では、読者にワークフローシステムを開発するための内部キッチンを簡単に紹介します。 THESIS SEDのリリースの準備段階について説明し、新しいバージョンの作業がどのように構築されるかを示します。 おそらく私たちの組織的な経験は誰かに役立つでしょう。
EDMS論文の新しいバージョンの開発の段階
SED論文の新しいバージョンは、年に一度リリースされます。 秋には、通常9月下旬から10月上旬に、各新リリースの誕生日を祝います。 ただし、システムの新しいバージョンのリリースの準備は、リリースの作業スケジュールが作成される冬の深夜に始まります。
毎年、TESISプロジェクト全体について、公開されているドキュメントが作成されます。これは、システムの新しいバージョンの作業段階を詳述するリリーススケジュールです。 それらの4つがあります。
- 開発の準備;
- 新しいシステム機能の開発。
- 新しいリリースのリリースの準備。
- リリースリリース。
各ステージには多数の中間ステージが含まれており、それらもスケジュールで規定されています。 さらに、この段階またはその中間段階を完了する期限を規定しています。
原則として、開発の準備は3月から4月です。 開発期間は5月から8月です。 リリースの準備は8月から9月に行われ、10月にはリリースがあります。その後、11月までに新しいバージョンがインストールされます。 11月上旬には、 TESISの最新バージョンもリリースされます。ポータル 、 Unified Holdingモジュール、 システムのモバイルバージョン、およびTESISシステムの他のブランチです。
EDMS開発の準備：アイデアのふるい
3月の初めまで、リリース年の製品開発の一般的な概念が開発され、アイデア、提案、コメントの予備的な収集が行われます。
3月1日には、新しいリリースの提案を収集するためのドキュメントが作成され、3月中旬まで、冬に電子ドキュメント管理システムを開発するために生成されたアイデアが導入されます。 以下の参加者が文書に提案を提出します。
- 電子文書管理のヘッド。
- 個々のTESIS実装プロジェクトのマネージャー。 彼らは、既存の顧客のプロジェクトの実際の作業の過程で生まれたアイデアとコメントを文書にもたらします。
- 営業部長。 彼は、システムの実装に関して交渉が行われた顧客の要件に基づいて登場したすべての販売スタッフからのアイデアを統合します。
- テクニカルサポート責任者。 彼は、顧客の希望に基づいて彼の部門によって形成されたアイデアを文書にもたらします。
- テスト責任者。 以前のバージョンで発生したシステムエラーに気づいたドキュメントを入力します。
- 開発責任者 開発者からの提案をドキュメントに作成します。
- マーケティング部長。 EDMS市場の現在の傾向、デザインのアイデア、インターフェースの使いやすさに基づいて生まれたアイデアをドキュメントに導入します。
- ビジネスアナリスト。 新しい技術能力、競合他社の変更、EDSの要件に関する法律の変更について、1年にわたって蓄積された情報に基づいて生じたアイデアを文書に導入します。
ドキュメントが完成すると、アイデアの選択が始まります。 提案は「ふるい」を通過します。2つの専門評議会があり、1つは3月中旬、2つ目は4月中旬に開催されます。
専門評議会には、電子文書管理部長、セールスディレクター、テクニカルサポート部長、テスト部長、開発部長、ビジネスアナリスト、マーケティング部長が含まれます。
最初の専門評議会で、改善の予備プールが形成されます。 専門家評議会は、提案を収集するために文書の各パラグラフについて議論します：何かがすぐに破棄され、何かがすぐに受け入れられ、何かが予備分析の条件で受け入れられます-これは必要ですか？
この会議は意見の真の戦争です。 議論は白熱しており、各参加者は弁護士として、自分の部署が提供する変更を擁護しています。 開発者は、技術的に実現可能なもの、プロジェクトマネージャー-クライアントの利益のために、技術サポート-それを最も得た苦情、営業部門-潜在的な顧客が最も頻繁に投げかけるオファーのために戦っています。 議論は終日続き、専門家は交渉室を離れることなく費やします。
「あなたが変更を加えることはありますが、専門家評議会でそれらを守ることはできません。 システムに精通したとき、私はすぐに「Application Folders」と「Search Folders」の名前を変更することを提案しました-それは明確に聞こえません。 そして、あなたの視点を守ることができなかったたびに-それはそのような些細なことのように思えますが、あなたはそれを理解していません。 今年だけ、顧客が私の主張を確認しました。 従業員間の競争を開催し、名前の変更の提案を受け取り、「アプリケーションフォルダ」は最終的に「アクションフォルダ」に名前が変更されました。 それはナンセンスに思えますが、実際には-UIシステムの重要なポイントです。 システム全体の再設計について話し合ったとき、どのような戦いが起こったのか想像してみてください。
同じ「アプリケーションフォルダー」。 ユーザーは最後にそれらを見ます。
4月中旬まで、リスト上のすべての係争中のアイテムの必要性が明確にされています。 ビジネスアナリストが分析メモを編集し、従業員を含む技術サポート部門の責任者が顧客の調査を実施します-そのようなシステム機能が必要ですか？ 開発部門の責任者は、論争の的となるアイデアを実装するための技術的機会を求めて研究開発（R＆D）を実施しています。
4月中旬に、2回目の専門評議会が開催されます。 分析、顧客調査、R＆Dの結果について説明し、開発者向けのタスクの最終的なプールを形成します。 タスクはグループに分けられ、リソースの強度と優先度が決定されます。
この段階で、経済的な問題が前面に出ます。これらの変更が私たちと顧客にどれだけ必要であり、それらを実装するのに十分なリソースがあるかどうかで、私たちに何が来るかです。 ここで決定的な言葉は、会社のコマーシャルディレクターにあります（彼は、電子文書管理ビジネスの責任者でもあります）。
同じ段階で、個々のタスクの専門家グループが形成されます。 開発者に加えて、さまざまな専門家が専門家グループに入ることができます。何かのために、デザイナーのために、何かのために-技術サポートの専門家などを引き付ける必要があります。 各専門家グループごとに、タスクの現在の作業について議論する会議スケジュールが形成されます。
EDS開発：アイデアから実装まで
EDMSの新しいバージョンの機能の開発は、4月下旬に始まります。 これに先立ち、プロジェクトのリリースが作成され、リソーススケジュールとともに開発部門に転送されます。どのタスクを完了する必要があるか、これを行う必要があるプログラマの数、および作業に必要な時間。 これには、専門家評議会によって承認された改善と、以前のリリースに対して承認された改善が含まれますが、何らかの理由でそれらは含まれません（ビジネスアナリストによって提供されます）。 同じ中間段階で、リリースの技術的な説明が作成されます：何が変更され、どのように動作するか。
同時に、開発者で構成されるワーキンググループが集まり、ドキュメントを読み、タスクを配布し、5月に電子ドキュメント管理システムの開発を開始します。これは8月中旬まで続きます。 開発のプロセスでは、さまざまなタスクの専門家グループがスケジュールに基づいて、現在の問題について話し合います。
会議モジュールの誕生
開発者が新しい各タスクの作業を終了し、システムのメインブランチに完成した結果を入力すると、テストが開始されます。 テスト部門は、パフォーマンスの新しい変更をチェックし、エラーを修正するためのタスクのリストを開発部門に転送します。 エラーは8月中旬までに修正する必要があります。
「テスト時には、一部のクライアントは標準のTESISソリューションを使用し、他のクライアントはシステムの機能を変更し、提供する設定、デザイナー、その他の機能を使用してシステムの機能を補完することを考慮する必要があります。 そして、3番目のものは、独自にまたは私たちの助けを借りて拡張プロジェクトを作成します。 これにより、リリースに新機能を追加する際の制限が決まります。これは、現在の顧客に「害を与えない」必要があるためです。 当社のスペシャリストは顧客のビジネスコンテキストに深く没頭しているため、この部門は製品全体の開発に積極的に参加しています」と、品質部門の責任者であるスヴェトラーナメルニコワはコメントしています。
終末月：DMS開発の完了とリリースの準備
8月中旬に、コードのフリーズが行われる日が来ます。変更のためにシステムコードを「フリーズ」します。 開発者は、リリースに新しい機能を追加できなくなりました。バグを修正するだけです。 テスト部門は再び作業を開始し、他のエラーを修正した結果として発生したエラーを探します（プログラミングの世界では逸話です-有名な韻を知っていますか？）。
開発期間中に生じた新しい「概念」は、次のマイナー（中間）リリースで保存され始めます。 リソースが不足したために削除された作業や、実装が容易な場合は営業部門からの突然の申し出は、そこに転送されます。
次に、リリースのリリースの準備が始まります。
残りのエラーのテストと修正が継続され、同時にテクニカルライターが仕事に入り、新しい「機能」のドキュメントを作成し、マーケティング部門が新しいバージョンのリリースに関するニュースとプレスリリースを準備します。 彼らの仕事では、これらの従業員は技術的な説明に導かれます（通常はテスト部門が編集します）。
9月上旬、新しいリリースの最初のインストール：アルファリリースは、営業スタッフが利用できるサーバーにインストールされます。 システムの新機能を顧客に伝える前に、システムの新機能に慣れる必要があります。
同時に、システムの一般的な機能仕様が更新されます（ドキュメントの「やりたいこと」が「実際にしたこと」に修正されます）。 （同じ原則に従って）専門家グループに発行された、電子文書管理システムの開発に関する私的な技術仕様も更新されています。
ChTZの更新に関するビジネスアナリストによる図解
バグ（販売部門が既に発見）のテストと修正はまだ進行中です...同じ期間に、マーケティング部門（またはワークロードに応じてテクニカルサポート）が文書「TESIS XXリリースの特徴的な機能」を作成し、既存の顧客に送信します。
すぐに、営業部門は修正されたエラーを含むアルファリリースの更新を受け取り、テスト部門は「リリースの技術的な説明」ドキュメントを更新して、顧客に表示できる形式にします。
9月中旬は、新しいリリースの2回目のインストールです。TESIS内部企業EDMSが更新されます。 はい、私たちはEDSを使用しており、お客様に提供する前に、すべての変更を最初に体験する必要があると考えています。
9月末までに、マーケティング部門は作業を完了します。システムの今後のリリースに関するニュースとプレスリリースが送信され、システムの機能に関する情報、およびサイトのデモ資料とビデオが更新されます。
同時に、販売部門はウェビナーを開催します。このウェビナーでは、システムの新しいバージョンが最初にパートナー向けに、次に顧客向けに裁判所に提示されます。
月末までにテストが完了します。 この時点で、システムの指示が準備できているはずです。 システムの「誕生日」の準備が完了しました。
完全リリース：EDSの開発結果をクライアントに提示
TESISシステムは9月30日または10月1日にリリースされます。たとえば、TESIS 4.1は2015年10月1日にリリースされました。 ホロスコープによると、我々のSEDS THESISは明らかに天秤座です。
この時点から、電子文書管理システムの開発が終了し、テクニカルサポート部門が顧客とのシステムの更新を開始します。
10月中旬まで、「小さな」顧客は更新されます。TESISEDMSのBasicエディションまたはStandardエディション、つまりシステムの最小「変更」またはシステムの標準「ボックス」を購入した顧客です。 そのような顧客向けの更新は、確立された日に迅速かつ標準化されます。
11月に、「大規模」な顧客は通常、アップデートを受け取り始めます。AdvancedEditionのユーザーは大幅に改善されています。
この期間中に、顧客からのフィードバックが入り始めます。新しいアイデアは次のリリースまで「蓄積」されます。 または、来年の開発プロセスでマイナーリリースがリリースされます。これは、システムの暫定リリースであり、慎重に収集および分析された顧客の要望に応じて修正および変更が行われます。 現時点では、論文4.1.4です。
したがって、電子文書管理システムTESISの開発は、スケジュール通りに厳密に実行されます。 これは当然のことです。私たちは自分自身を規律し、顧客のワークフローを効果的にクリーンアップできる必要があります。 現在、TESIS 4.2リリースのリリースの準備が進行中です。