毎月新しいバージョンがあります。 彼女は顧客に引き渡される前に厳しいテストを受けます。 これは、6枚のシートでのこのような指示です。 そして、このバージョンはすべてが最高になるまで公開されません。 テスターはほとんど考えず、指示に従ってテストするだけです。 もちろん、パンクは起こりますが、頻繁ではありません。 穴を開けるたびに、テストカードが完成します。 これは、私がここで話しているテストでも、同様の原則で行われるべきです。 いくつかの単純で小さいながらも重要なテストがあります。 あなたはただそれらを実行し、結果を見てください。 テストは成功したので、TKの実装、開発、およびそれ以上の事項に関する会話を続けることができます。 テストに失敗しました-さようなら。 それだけです！
そして、私が書いているテストが何らかの基準であると考えることを神は禁じています。 これは私のオプションです。 しかし、別のものを見つけてみてください。
思い出させてください。高等数学のように、必要ではありますが、十分な機能ではありません。 誰のために、何が十分なのか、誰もが自分でそれを終えます。
「注文どおり」の配送。
前のパートでは、サプライに焦点を合わせました。 ただし、単に商品を持ち込んで在庫を補充する場合、倉庫へのいわゆる配送の問題がありました。 これらは不適切な購入です。 また、ターゲットを絞ったものもあります。 これは、クライアントがあなたに来て、あなたが持っていないものにお金を払い、あなたがこの「何か」を彼に届けるときです。 これは「注文への配達」と呼ばれ、非常にファッショナブルな（そして実際に必要な）機能です。 主な問題は、あなたから商品を注文したクライアントが保証を受けられないことです。 彼はあなたにお金を支払い、あなたは購入して倉庫に配達します。 その後、別のマネージャーがこの製品を別のクライアントに簡単に販売します。 非常に頻繁にこれが起こっています。 あなたが10人であるとき、あなたは30歳のとき、あなたが販売する前に何を尋ねるかについて互いに同意する機会があります-チャンスはありません。 この機能の目的は、クライアントが注文した場合（さらに前払いを行った場合）に商品を受け取ることを100％保証することです。
別のニュアンスがあります。 顧客はあなたに20個のアイテムを注文しました。 2日間で1つのアイテムを、20日に2番目のアイテムを購入します。質問：購買マネージャーは、各アイテムの調達プロセスをいつ開始するかをどのように理解できますか？
簡単にテストされます。 クライアントに注文を書きます（システムでどのように機能するかに関係なく、請求書を送ります）。 次に、購入リクエストを作成します。 再び、少しニュアンス。 2つのアイテムを書き留めます。1つは在庫があり、もう1つは「注文済み」にする必要があります。 1つ目は予約済みで、2つ目は購入に送信されます。 ゆっくりとゆっくりと、購入者に2番目の名前を送信する方法を示すように依頼します（この2番目の名前に1つのアイテムがあり、さらに2つのアイテムを購入する必要がある場合のより複雑なケースについては話しません）。 さらに進んでいます。 この特定のアイテムを購入する必要があることを購買部長はどこで見ますか？ この場所を見せてください。 この場所にはどの見出しが含まれますか？ 注文が前払いされている（または支払いなしで購入ガイドの承認を受けた）すべての商品またはそれらの商品のみですか？
次に、購入を実行し、購入した商品を倉庫に運びます。 今注目！ 注文（またはアカウント）に移動して、商品が倉庫に保管されているかどうかを確認します。 いや？ それでは、「ショーマン」の次のフレーズを引用します。「What the x ... you can punch my brain？」 調達プロセスの完了時の商品の自動予約-これは、「注文どおり」の配送の本質です。 冗長性なし-機能なし。
テスト時に、システムがMRP標準をサポートしていると誇らしげに言われました。 実際の見た目は次のとおりです。
彼らは、計画のための特定のフォームを示しました。そこでは、調達マネージャーと言われる人が、一か所で正確に何を買うべきかを見るでしょう。 計画フォームに、顧客が単に請求した商品が含まれていることを発見したときの驚きを想像してください。 つまり 顧客に請求するだけで、購入マネージャーは購入についてこれを自動的に確認します。 請求書が簡単に未払いになる可能性があるという事実は考慮されていません。 商品は購入され、倉庫に運ばれますが、顧客はそれを受け取りません。 法案を支払うように心を変えさえします。 倉庫の過剰在庫への直接的な方法。 これがMRPです。
したがって、製品をテストするときは、これらすべての用語を頭から取り出して、機能をテストするだけです。 それが何と呼ばれるかは重要ではありません。
倉庫
最初に店主と実験してください。 2つの倉庫を開始します。 倉庫への店主のアクセスを共有するよう依頼します。 まあ、これは、各店主が自分の倉庫だけでなく、あらゆる倉庫から簡単に商品を出荷できる異常な状況です。 それ以外の場合、責任のポイントは何ですか？ この店主の下でプログラムに移動し、彼が彼の倉庫でのみ操作を実行できることを確認してください。
実際には、店主の機能は非常に簡単です。 彼は商品を倉庫に持って行き、出荷しなければなりません。 それだけです しかし、ここでは、運が良いように、ニュアンスがあります。 店主は、どのように、どこに正確に自分の倉庫に発送するか、持ち帰るべきかを見つけますか？ この場所を見せてください。 この場所では、少なくとも、何を、誰から、どの文書で、どれだけ受け入れるべきか（そして、その他の必要な情報）を明確にする必要があります。
アドレスストレージ。 これが本当に必要な機能であるとは言えませんが、アドレスストレージ（ファッショナブルなもの）がないため、これはERPではないと非難します。 これはいくつかの場合に役立ちます：
1.非常に大きな倉庫。
2.店主と彼らがどこにあるのかという知識に頼らないことを強く望みます。
3.膨大な数のアイテムと小物。
4.これらの同じ店主の高い規律。
少なくとも1つの条件が満たされていない場合、アドレスストレージを実装できない可能性があります。 私の練習では、一度成功しました。 ドラコニアの規律はみんなと一緒でした。
機能性の観点からは、複雑なことは何もありません。 倉庫があり、ここにその保管場所がありますが、各保管場所に置くことができる商品は何ですか。 店主は商品を受け取ります。住所を指定する必要があります。 出荷時も同じです。 より複雑な機能はすでにWMSであり、通常の企業では必要ありません。 ここでは、データ収集端末、バーコードスキャナーなどのトピックをさらに発展させることができますが、この機能は重要ではないと思います。それなしで生き残ることができます。
このシステムは、商品を迅速に把握し、特定の倉庫、すべての倉庫での移動の履歴を確認できるようにする必要があります。 特定の倉庫の残りの商品の履歴を表示します。 他の何かかもしれませんが、必要な機能に起因するものは何もありません。 何かを忘れた場合は、コメントを書いて、補足します。
条約
それでは、まず、契約のレジストリを見てみましょう。 何を理解すべきですか？
1.この契約を誰が誰と締結したか。
2.これは、クライアントまたはサプライヤーとの契約です（ただし、これは重要ではないかもしれません）。
3.期間、数、署名者。
4.契約のタイプ（タイプ）（何らかの形で分離されている場合）。
5.配信の命名法（契約がフレームワークでない場合）。
6.契約の現在のステータス。 署名、同意、閉鎖など
7.契約のスキャン。
たぶん何か他のもの。
契約が商品の特定の仕様の提供または特定のサービスの提供に関するものである場合、商品が配送されているか、これらのサービスが提供されているか、すべて提供されているか、または一部のみを理解するか？
契約がフレームワーク契約である場合、定期的な出荷はそれを参照する必要があることを意味します。 これらの同じ貨物を見て、この貨物がこの契約の下にあることをどこかで見ることができます（もちろん、コメントを除く）。 交渉-12を見てください、契約へのリンクはありますか？
契約の動きはどうですか。 契約がシンプルで標準的なものであれば、すべてが明確です。 調整するものは何ですか？ そして、典型的ではない場合、承認手続きはどうですか？ どの調整チェーンがすでに存在し、どのように変更されていますか？ この段階またはその段階を調整する責任者は、何かにまったく同意する必要があることをどのように見つけますか？ 合意が必要な契約のみ、または通知などが見える職場のようなものであるべきです。 要するに、これがどのように実装されているかを示してください。 それはビジネスプロセスそのものです。
会社で少なくとも300人働いている場合、その契約から1年半後、契約を見つける（紙で、たとえばコピーを作成する、またはクライアントにFAXで送信する）のは、新しい契約よりも困難です。 あなたがそのような会社で働いているなら、それを試してください。
この問題を解決するには、ERPシステムが契約のスキャンされたコピーをデータベースに保存する必要があります（商品の写真、クライアントへの指示など）。 私はそう思う、私は間違っている可能性があります。 簡単に確認できます。 ファイルを取り、コンピューターのデスクトップに置きます。 契約に添付します。 デスクトップに戻り、デスクトップからファイルを削除します。 プログラムに戻り、契約を開きます。
契約のパラメーターを変更（添付ファイルの削除）するアクセスをブロックするシステムはどのように編成されていますか？ このロックシステムの仕組みを説明してください。 この原則を理解していますか？ こちらが契約書です。 システムは、変更できないことをどのように理解していますか？
システム自体がテンプレート契約のテキストを生成できますか？ それをするように頼みなさい。 システムは、姓、地位の属格を理解していますか？ 条約の前文は条約を適切に満たしていますか？ 彼女は、契約書の本文に当事者の詳細を正しく形成する方法を知っていますか？ 生成されたテキストを一般に受け入れられている形式（pdf、docなど）でアンロードすることはできますか？
費用
ERPシステムの実装を開始した場合、もちろん、目標はそこから請求書を印刷することではありません。 これも重要ですが、目標はそれではありません。 目標は、企業を管理し、その有効性、状態を理解し、いくつかの決定を下せるようにすることです。 言い換えれば、ビジネスの純利益を制御し、その成長に従事し、品揃え、顧客ベースなどを最適化することです...これらが目標です。
あなたの許可を得て、ここに写真を表示します。 ロゴなし、写真だけ。
これは、会社の責任者が毎日見るべき写真（またはそのようなもの）です。 これは損益計算書です。 すべてに当てはまるわけではありませんでしたが、その本質は明らかです。以下に、「営業利益」、「税引前利益」、「純利益」という指標が続きます
このようなレポートを取得するには、明確に機能するコスト管理システムが必要です（それだけではありません）。
ここでは、家賃（通信、出張など）にお金を使う必要があります。 これはどうですか？ 誰が何を記入するか、誰が何を承認する（同意する）かなど。 この手順が正確にどのように発生するかを示すように依頼します。
2010年2月のレンタル料金を受け取りました。 しかし、彼らは2010年3月5日にそれをあなたに持ってきました。あなたはそれを3月10日に支払います。 このお金が2月に正確に「下落」し、3月に正確にお金の動きが明らかになったのはどこですか。 この状況では、これは、損益計算書ではこの金額を2月に、キャッシュフロー計算書では3月に反映する必要があることを意味します。
予算編成のシステムについて推測することはできますが、この機能が必要だとは思わず、それなしでも存続できます。 誰がそれを必須と考えるか、あなたはそれについてコメントを書くことができます、私は補足します。
これで次のパートは完了です。 次のパートでは、プロジェクト、在庫管理、生産、品揃えの最適化、財務報告などについて説明します。