先例管理スタイルとツール

プロジェクトはRedmineで管理されていましたが、これはクライアントによって若干強化され、いくつかの便利な変更が加えられました。 同社の他の部門では、Microsoft Dynamics NAVを使用して作業を整理し、データをそこに保存しています。システム（RedmineとNAV）は、部門間の通信を可能にし自動化するために相互接続されています。

技術的には次のように機能しました。NAVで新しいプロジェクトが設定され定義されたら、これらのデータをRedmineに転送して特定の属性を持つ新しいプロジェクトを作成するオプションがありました。

Redmineはこの会社で仕事を組織するのを助けていた便利なツールになりました。 JIRIモデルが取り組んでいるプロジェクトは非常によく似ており、Redmineのプロジェクト構造はシンプルに保たれていました。 プロジェクトは4または5タスクで分割されていましたが、これらは各プロジェクトで同一または類似していました。 タスクは、そのタスクにパッケージされているパートワークに対してアクションを実行する順番に応じて、ライフサイクル中に複数の担当者間で受け渡されていました。 このようなタスクは、現在の担当者だけが気付いて監視していました。 タスクを追跡するために、Redmine個人用ダッシュボードのデフォルトの「自分のタスク」フィルタが使用されました。

このシステムはしばらく前からうまく機能していましたが、会社の経営陣の革新的な計画や戦略に追いつくには不十分であることがわかりました。 これらの戦略は、プロセス全体の透明性と透明性の向上、プロジェクトの遅延の原因を予測または発見して責任者に対処する能力、および効率的なリソース管理計画の実施などに特に重点を置いています。利益は確かに速くて滑らかな配達プロセスと従業員のやる気と満足を高めるために他の内部ツールとメカニズムを開発するためのしっかりしたデータを得ることでしょう。

実装が始まる前に、JIRIモデルの管理者は、実装しようとしている新しいプロセス、およびワークフローが理想的にどのように見えるべきかについて、すでに明確なアイデアを持っていました。 まず最初に、タスクの構造を作成し、適切な情報が適切な人に確実に届くように、各グループのユーザーのインタフェースとフローとアクセス許可を定義して、これらのプロセスをシステムに実装することに焦点を当てました。時間。 実装中は、Easy ProjectとMicrosoft Dynamics NAVの間の接続を設定および改善するために、JIRIモデルのさまざまな外部パートナーとも協力しました。 実装には、事前に多くの計画と設計が必要でした。 これは、データの連続性を損なわないために、すべての生産プロセスがRedmineで実行されていたため、展開直後にEasy Projectに置き換えられていたためです。 

プロジェクトテンプレートとAPI統合

すべてのプロジェクトは同様の構造をしています。 Redmine Easy Projectとは異なり、新しいプロジェクトのセットアップのベースとして使用されるプロジェクトテンプレートを作成することができます。 この場合、テンプレートを使用することの最も重要な利点は、タスクの構造、その関係、および各タスクの説明をそこに保持できることです。 簡単なプロジェクトとMicrosoft Dynamics NAVとの間の接続を確立しました。 新しいプロジェクトがNAVで作成されているときは、関連する「プロジェクトの種類」がカスタムフィールドで選択されます。 この情報はEasy Projectに送信され、Easy Projectが新しいセットアップ用のプロジェクトテンプレートを自動的に選択し、NAVからのデータがそこに転送されます。

簡単なプロジェクトのコア機能とパーソナルダッシュボード

Easy Projectが提供するコア機能を利用し、さまざまなワークフローでさまざまな種類のタスクを設定しました。 タスクの可能なステータスは、このタスクの種類によって異なります。 また、状況の順序は、ユーザーが次のステップを識別するのに役立つように定義されており、状況はユーザーの役割によって異なりますが、役割はそれぞれ異なります。 ステータスとトラッカー（タスクの種類）を個人用ダッシュボードの設定に使用して、各ユーザーに関連するタスクをフィルタリングしました。 例えば、監督者は、行われるべきタスクのステータスを監視し、フィードバックがあったかまたは自分の側から承認が必要であったタスクを別々に追跡し、遅れているものを識別することなどができる。