もう1つのポイントは、基本バージョンでは、Sharepointは2つの基本的なポイント（以下について）を考慮していないことです。これは、私の意見では、タスク設定と電子文書管理の両方の意味での基礎であり、ライセンスを購入した後すぐにカスタマイズする必要がありますMicrosoft、または事前に構成された機能を購入します。
1.デフォルトでは、Sharepointは従業員の役割への参加を使用せず、ビジネスプロセスの観点からは会社の役割（役職）に関連付けられていないアカウントを使用します。 大まかな検査では、これは問題ではなく、一般にすべてが正常です。 一方、これは組織の組織構造を詳細に理解する上で大きな制限と不便を課します。
最も単純な例では、我々（ユーザーA）がタスクのイニシエーターであり、実行、承認、承認のために（ユーザーBに）送信するとします。 すべてが素晴らしい-タスクが来る。 通知を送信しました。 ユーザーB-タスクを実行し、すべてが正常です。 しかし、この素晴らしさはすべて素晴らしいです。10〜20人が会社で働いていて、誰もが視覚的にも名前でもお互いを知っている場合のみです。 しかし、会社で約900人の従業員が貸借対照表に参加している場合、または数千人の場合でも.....そして、私は彼らが誰なのか分かりませんが、オフィスフロントの戦闘機のように、直感的なオフィスレベルで、私は論理的なポジションが何であり、誰が私の上と下。 特に、従業員が病気にかかったり、辞めたり、死亡したり、より魅力的な気候条件のある国に単に出航した場合。 したがって、名前を知る必要はありません。無力になるだけで十分です。どんな種類の投稿があるか想像してみてください。 それは比類のないほどシンプルで便利です。
現時点では、原始的規模で例を検討しており、権利の代用や委任などを行わないことは明らかですが、彼らは非常に役立ちますが、主要な問題-従業員を役割（ポジション）に関連付けるという観点からシステムをカスタマイズすることは解決しません。
役割構造を使用すると、部門、支社、部門でいつでもフィルタリングでき、従業員の位置（会社の従業員の役割）を正確に選択できます。 事実は、基本的なシステムの標準的なロジックによると-私は名前で全員を知っている必要がありますが、実際にはこれはまったく起こりません。 したがって、主要なカスタマイズの主なポイントの1つは、正確に会計と会社の組織構造における役割との接続です。
2. 2番目の落とし穴は、Sharepointに特定の瞬間にプロセスルートを構築するためのわかりやすいシステムが存在しないことです。 もちろん、Sharepoint DesignerとVisual Studioは、すべてを行うことができる揺るぎない拠点です。 しかし、私たちはシステムの単純なオペレーターについて話している...したがって、事前に構成されたプロセスルートを持つオプション、またはNintexを販売するサードパーティのデザイナーがあります（それは文字通りすべてを行うことができますが、それはジャガイモを剥くだけですが、それは神のないものであり、深刻な建設スキルも必要です）、またはポイントAからポイントBまでのような非常に単純なルートの使用。まあ、一般に、それは問題ではありません。
ここでは、全体として非常にシンプルなルーターを実装しました。もちろん、大きな分岐プロセスを構築することはできませんが、動的に（つまり、今実行するために必要な方法で）静的に（事前に構築する）チェーンと保存-リストから選択するだけです。
つまり、機能的です-それは非常に簡単に動作します：
文書承認プロセスを開始すると、従業員は承認期間を示し、事前に設計された文書承認ルートのいずれかを選択します。
パッセージの段階と従業員をさらに示します（会社への役割参加からフィルターで選択し、システムは既にその関連するアカウントを置き換えます）
次に、必要なすべてのステップを設定し、プロセスを開始します。
ここにフルサイズ
それだけです-プロセスが実行されました！ シンプルで美しい:)ルートが永続的なものの場合、毎回それを埋めることはできませんが、単に保存してください。 そして、何か新しいものが必要な場合は、変更を加えて動的に示します。
たとえば、製品Worklite DocsおよびWorklite Portal-ここでは、 電子文書管理と企業ポータルが表示される例として見ることができます。