氷山

誰もが氷山とは何かを知っています。海に浮かぶ大きな氷です。 誰もが氷山の何が悪いのかを覚えています。氷山のほんの一部しか見えず、それは水面の上にあり、残りは隠されています。 そして、どれだけあるか、この休憩-誰も知りません。



同様の状況は、自動化システムのデータにあります。



通常、データ自体が表示されます。 配達または領収書の請求書、振替、支払いなどの文書 ディレクトリ-命名法、取引相手、ユニット。 通常のタスクと処理タスクの両方のタスクが表示されます。 私たちは遺物を見る-どれだけの品物が在庫しているか、誰が私たちにお金を負っているのか、どれだけの赤字があるかなど



個々のデータまたは組み合わせたデータは、特定の状態を形成します。 たとえば、私たちの倉庫はいつでもある状態にあります。 私たちはそう言います-倉庫の状態。 または、売掛金または買掛金のステータス、タスクのステータス、またはプロセスのステータス。



自動化されたシステムと生活の両方で、状態を即座に評価することができます。 推定、逃げて忘れてしまった。



その後、しばらくして、再び同じデータまたは状況に遭遇します。 状態の再評価を再度行います。「すべてが良い」または「すべてが悪い」と言います。 これは、2、3、125回繰り返されます。



状況を重大と評価した場合、おそらく、何らかの形で修正するでしょう。 そうでない場合は？ はい、状況はあまり良くありませんが、あなたは生きることができます。 これはしばしば運用会議で起こります-誰かが質問を提起し、状況を伝え、評価を与えます。 誰もがうめき、または舌をたたくと...何？ 原則として、彼らは忘れます。 次回まで、誰かが注意を払うまで。



ネガティブな状況が寛大になるたびに、私たちはそれが初めてのように見えるので。 もちろん、誰かが思い出します-ああ、それはすでに起こっています。1か月前、あるいは6か月前のように、私は覚えていません。 彼らは沈黙を保つにはあまりにも良い記憶の所有者を突く-状況は赤ちゃんのようにきれいであると考えてみましょう。



なぜこれが起こっているのですか？ 否定的な状況情報には何が欠けていますか？ 非常に高品質で詳細な即時評価があります。 「すべてがここで悪い」というフレーズを続けて、彼女が新しい色で遊び、より有益になるようにする方法は？



「すべてがここで、そして長い間悪い」というフレーズを続けるのは非常に簡単です。 状態の時間または期間は、適切な決定に必要な情報です。



人生では、誰もがこれを理解しています。 いくつか例を挙げましょう。



「十分なお金がありません」-即座に評価するには、外科的介入が必要です。 「もう一年もお金が足りない」-ワオ、ここには体系的な問題があり、それについて一生懸命に考え、人生を変える必要がある。



「何かが私の足を傷つけます」-まあ、あなたは決して知らない、彼は時間を提供したかもしれない、または天気は関節炎に影響を与える。 「私の足はもう6ヶ月痛いです」-急いで診療所に急ぎます。



「子供がデュースを持ち込んだ」-よくやった。今こそ、デュースがバランスのために必要だ。 「子供が四半期全体にデュースをもたらします」-ああ、あなたのバカは未成年者です、そこで何をしているのですか、明日学校に行きます、あなたのクラスの先生の電話番号です。



ビジネスシステムでも同様です。



「クライアントは私たちに100万を負っている」-さて、あなたが苦しむものを支払う。 「今、クライアントは私たちに6ヶ月間100万を負っています」-あなたの母親、どこを見ましたか？



「赤字声明には5つの緊急の立場があります」-調達担当者が命令するので、人々を引き出すべきではありません。 「5つの緊急ポジションが2か月間赤字のポジションにとどまっています」-これが販売が落ちている理由です！ 全員をカーペットに緊急に引きずり込み、すぐに購入してください！



「プログラマは私の仕事を過ぎている」-はい、彼らはすべての仕事なので、心配しないでください。 します。 「プログラマーはすでに2か月間私の仕事を過ぎています」-いまいましい、私はこれらの嫌いな人を長い間分散させたい、彼らはそこで何をしているのか？



ご覧のとおり、条件の期間、特にマイナスの期間は、情報に新しい次元を与えます。 どうしたらいいのかわからないフラットで退屈な情報があるかのようでしたが、立体的な画像が得られました。 状況の分析と意思決定がはるかに簡単になります。



ここではすべてが明白なので、信じることすらできません。そのような卑劣さは、教科書の別の章に値するのでしょうか？ この質問に答えるには、情報システムを見てください。



測定された期間に多くの条件がありますか？ 従来、Icebergの原則に基づいた2つのレポートがあります。非流動資産と延滞です。 ところで、あなたは非流動資産を見ていますか？ すべてではなく、一般的なシステムでさえ、非流動資産を見ることができます。



残念ながら、情報システムには「状態」という概念すらありません。 さまざまな角度からそれらを表示するデータと手段があります。 膨大な数の数字をいじり回すのが好きだが、意思決定を行うのに十分な賢明な情報が必要ではないアナリストのためのシックな広がり さらに、誰が決定を下すかは関係ありません-人またはシステムそのものです。



Icebergの原則を実装するには、いくつかの方法があります。 従来-セパレーターが情報配列に追加される場合のバッチ会計-バッチ文書。 たとえば、商品は倉庫に到着しました-名称と数量だけでなく、領収書-請求書も覚えています。 請求書には日付があり、そこからいつでも期日を計算できます。 たとえば、売掛金勘定でも同じことを行います。取引相手と金額だけでなく、この債務を作成したドキュメント（配達請求書、仕入先への前払いなど）も保存します。



専門用語で言えば、パーティー文書には多くの困難があります。



まず、テーブル内のレコード数が増加します。 1つのエントリ「Sleeve、10 pieces」は10エントリになります-「Sleeve 1 pc from 09/01/2017」、「Sleeve 1 pc from 12/09/2017」など。



次に、バッチキャンセルアルゴリズムが必要です。 たとえば、出荷するとき（つまり、商品を償却するとき）、どのバッチから残りを差し引くかを知る必要があります。 または、買い手から支払う場合、どの出荷書類にお金が来たかを示す必要があります。 2つのアプローチが使用されます：バッチの自動計算、またはそれらの手動表示。 自動バッチ選択は、FIFO（最初、最初のバッチ）およびLIFO（最初、最新のバッチ）のよく知られた償却戦略です。 マニュアルのバッチ識別は、支払いの転記によく使用されます。



3番目の問題は、むしろ系統的なものですが、実際の生活はバッチキャンセルアルゴリズムに従わないということです。 店主は棚から部品を取りますが、プログラムが選択したものではありません。 彼はFIFOが何であるかを知りません。



技術的に複雑なシステムであり、その結果はめったに使用されません。 私は会計や管理会計について話しているのではありません。管理会計はロットを使用して償却費を計算します。 ネガティブステートの期間、つまり非流動資産の測定について話している。 非流動資産の実際の、定期的かつ効果的な作業プロセスをいくつ見なければなりませんでしたか？



2番目の方法は、すべての状態の期間を保存するのではなく、必要に応じて計算することです。 これは、持続時間の即時推定です。 たとえば、ロットを保管せずに倉庫内の非流動資産を見つけることができます。 多くの方法があります-例えば、現在のバランスを理解する、商品の動きを遡及的に見る。 動きがなければ、目の前には非流動的な資産があります。



この方法には、バッチアカウンティングのデメリットがありません。大量のデータを保存する必要がなく、現在の作業を複雑にすることもありません。 しかし、バッチアカウンティングの主な利点-期間の保存-はありません。 期間の推定値は、特定の時点でただちに表示されます。 入って、見て、感謝して、出て行った-所要時間の見積もりは消えた。



一方で-大丈夫、それは大丈夫です。 期間を計算するためのアルゴリズムを採用し、それをプロセスに組み込むことができます-負の状態がドラッグされたときにシステムに反応させます。 しかし、残念ながら、継続時間の瞬間的な推定はそれほど瞬間的ではありません。システムリソースは計算に費やされるため、毎分実行されないのはノイズコストだけです。



継続時間の即時評価を使用できます-毎日監視する必要がない、あまり重要ではないプロセスの場合。 たとえば、同じ非流動資産を処分するプロセスを構築する場合-月に一度計算を行い、最も蓄積されたアイテムのリストを決定し、それらを処分するタスクを形成します（たとえば、値引き販売や廃棄）。



3番目の方法は、トリミングされたステータスを計算、分離、保存、および追跡することです。



たとえば、赤字声明書-購入する必要がある商品のリストがあります。 生産、販売、修理など 赤字ステートメント全体を監視することは意味がありません。かなり期限切れのポジションです。 これらの過去の位置は、それらの多くがないので、強調する価値がありますか？



システム内の別の場所に、有効期限が切れたアイテムのリスト、数量、そして最も重要なのは発生日を保存するだけです。 結局のところ、そこに常に期限切れの位置があるわけではありませんか？ それらが現れたらすぐに-覚えておいてください、そして出現の日付は期間の開始点になります。



その後、システムはそれ自体ですべてを行います。 定期的に赤字を調べ、期限切れのポジションがあるかどうかを確認します。 そうでない場合-優れている場合、負の状態は停止しています。 期限切れのポジションの保存リストは忘れてシステムから削除することができます（ここでは、あなたの裁量で、それを思い出として、つまり遡及的な分析や動機付けシステムのために残すことができます）。 期限切れのポジションがまだ不足している場合は、何もする必要がなく、クロックが刻々と過ぎ、継続時間が増加しているため、システムにとっても適切です。



期限切れの赤字を監督する人は、単に幸せになります。 第一に、彼はもはや目を離すことができません-遅延に関する通知を設定するだけです。 第二に、遅延が長く発生しているかどうかを把握する必要がなくなりました-継続時間が自動的に表示されます。 第三に、遅延が消えた瞬間を追跡する必要はありません-システムは、物事がうまくいくとあなたに知らせます。



ビジネスプログラマとして、ビジネスシステムで応答プロセスを構築するのがはるかに簡単になります。 持続時間の理解はありませんが、否定的な状態が発生するとすぐに、その人をすぐに引っ張らなければなりません。 そして、あなたの「けいれん」は、赤い布のように常に鼻の前に垂れ下がっています。



期間がある場合、設定はより細かくなります-自分に問題を示すタイミングを自分で選択します。 ネガティブ状態の持続時間に基づいてカラーディスプレイを選択することもできます。 たとえば、黄色-1日、赤-2日以上など。



同時に、上流の応答システムを構築できます。 たとえば、最初にサプライヤに赤字の遅延を表示します。 1日後、もし排除されなければ、供給長に。 3日後、コマーシャルディレクターに。 一週間で-監督に。



さらに、あなたは理解しています。その本質は、タスクがどれだけ上昇したかによって異なります。 サプライヤに遅延を解消するよう依頼します。ポジションを注文する必要があります。 サプライマネージャに注意を払い、場合によっては、ポジションを別のサプライヤに転送するよう依頼します。 監督に、サプライサービス全体が何らかの形で奇妙に機能していると言います。システムの変更が必要です。



この方法の主な機能：ステータスデータの保存とその自動更新。 後で説明する「自動タスク」の原理を使用して技術的に実装されます。



その過程で、状態の持続時間を決定する他の方法、つまり 水中の氷山の大きさ。 おそらく、私がリストしたメソッドが機能しないシステムでプログラミングしているのであれば、独自のメソッドを探す必要があります。



主なもの-ビジネスシステムをプログラミングするとき、「Iceberg」の原則を忘れないでください。



特に、パーティショニングアカウンティングを使用する場合は、設計中に配置する必要があり、遡及的に展開するのは非常に困難です。



「AutoTasks」などの期間の即時評価は、いつでも含めることができます。 まあ、それもオフにします。 この軽さに彼らの利点があります。



練習からIcebergを使用する例をいくつか示します。



最初の例は、タスク管理システムです。 タスク、割り当て、またはメモが​​あります。 イニシエーター、パフォーマーがいます。 タスクが仕事に受け入れられると、すべてが明確になります-期限があり、タスクのすべてが良いかどうかをすぐに判断できます。



しかし、問題にはいくつかの中間状態もあります。 たとえば、イニシエーターはそれを作成して送信し、エグゼキューターは作業のためにそれを受け入れる必要があります。 仕事での受け入れは、タスクの特定の兆候です。 請負業者がそれを置くまで、タスクの状態は氷山の水中部分です。 彼が最終的にそれを行うことを決めたとき、いまいましいことは明らかではありません。



私は単純に行動しました-承認日をタスクの別のフィールドとして機能するように追加しました。 承認済み-日付は記憶されています。 そして、エグゼキュータにタスクを送信する日付はすでにそこにあります。 したがって、負の状態の2つの期間を取得します。 タスクが受け入れられるまで、期間は現在の日付とディスパッチの日付の差です。 それにもかかわらず、請負業者がそれを受け入れた場合、受け入れと送信の間に正確な間隔が表示されます。これはシステムに永久に記憶され、さらなる分析に使用されます。



理解できない期間の同様の状況は、請負業者が作業を行い、検証のために開始者に送信したときに発生します。 彼がそこでチェックするとき、それは知られていない。 エンドユーザーと直接作業するきちんとしたプログラマーは、テストでタスクが頻繁にフリーズすることを確認します。 さらに、物理的にはすでに確認できており、ユーザーはすべてを気に入っていますが、システムにログインしてメモをとることはありません。



解決策は似ています。 タスクに2つの日付を追加します-請負業者が検証のために送信したときと、開始者が反応したとき、結果を受け入れたか、修正のために返されました。 したがって、検証状態の期間は常に手元にあり、タスクの検証時間を正規化できます。 まあ、いたずらにならないように。



私のお気に入りの例は調達です。 タスクを使用すると、すべてが簡単になります。このタスクが記録される特定のオブジェクトが常に存在し、このオブジェクトに状態の継続時間に関するデータを保存するフィールドを追加できます。



そして、調達は流れです。 そこにいる誰も、彼らの正しい考えでは、別の仕事をすることはありません。 さて、あなた自身を想像してください-女の子が座って、ブッシュを注文しています。 毎日。 同じブッシング。 また、シャフト、ボルト、ナット、金属、鍛造品、スタンピングなど



注文する必要があるものに関する情報のみがあります。 はい、さまざまな詳細レベルで発生します-時にはアイテムと数量のリスト、時には受信者、請負業者、注文、ユニットなどによって発生します。 しかし、この情報はフラッシュのように常に瞬間的です。 私が入った-ほら、1020個を注文する必要があります。 数分後、彼は入りました-わあ、すでに1200です。状況が変わったからです。



調達担当者はこれを理解し、活用します。 ミーティング、デブリーフィング、および工作員では、買い手はしばしば底に到達しようとしますが、彼らからは、アヒルの水のようです。 彼らは彼らに言います-ええと、ブッシングは何が欠けていますか？ だから昨日、必要性だけが生じました！ -それらに答えてください。 昨日はどうですか？ さて、昨日。 私は誓います、昨朝、私は不足していました、茂みがありませんでした！



スリーブが昨日であることを証明するには、バックアップを解除することによってのみ可能です。 もちろん、生きている人は毎日バックアップを取りませんので、疲れた売り手と製造業者は、独自のバージョンのIceberg-印刷物を思いつきます。 たとえば、彼らは月曜日にシステムに入り、赤字を見て、それを印刷します。 問題が発生した場合、またはサプライヤに感謝する場合は、この紙を見せてください。



しかし、このような紙をかわすのは簡単です。 セールスマンは言う-あなたは私にここで何を滑らせていますか？ はい、月曜日には袖が足りませんでした。 火曜日にはすでにたくさんの人がいたので、誰もが十分に食べていただろう！ そして、今日のシステムに見られるのは昨日だけでした。



その後、彼らはまた、紙の問題に参加することを余儀なくされます-彼らは単に不足を印刷するだけでなく、署名のためにサプライヤーに与えます。 そして、納期は添付するよう求められます。 あなたは、効率の面でのプロセスがまあまあであることを理解しています。



原則Icebergはタスクで働いていましたが、供給で働いていませんでした。 売り手は何かをしなければならないことを理解し、購入のためのタスクを設定し始めました-オブジェクトを直接作成し、ポジションのリストを添付し、実行を待ちました。 最初は解決し始め、その後、サプライヤーはそのようなタスクを愚かに拒否し始めました。たとえば、「日常業務に別の注文をする必要はありません」などのコメントが寄せられました。 一般に、正しいコメントは、全員にタスクを設定する場合、クリーナーをシステムに接続する必要があるということです。



この問題は、自動タスクとデフォルトで存在するIcebergによって解決されました。 自動タスクは単純に赤字を解消し、行方不明者の位置を分割し、サプライヤに注文する必要があるものに関する情報を含むオブジェクトを作成します。 自動タスク形成日は、実行日と同様に自動的に固定されます。 サプライヤーとのポジションの配置。



たとえば、100個のブッシングが必要で、サプライヤーが70個を注文した場合、自動タスクは終了せず、単に調整されるだけです。30個のポジションを配置する必要があります。 重要なのは、ネガティブ状態の開始日、つまり 赤字は同じままです。 ある時間間隔で70ポジション、別の時間間隔で30ポジションを注文しました。



Icebergの適用により、すでに何も隠されていないため、問題は非常に迅速に解決されました。 第1に、赤字の期間の会計処理は、ポジションと数量のコンテキストで実行され、第2に、請負業者に関連して実行されます。もちろん、サプライヤ用に特定のKPIがすぐに生まれました-時間通りに注文するポジションの何パーセント（必要になった瞬間から、その日に会わなければならなかったようです）。



アイスバーグは会計に適しています。結局のところ、結局のところ、どこか間違ったことが常にあります。負の残高は、さまざまなアカウント、または彼らが嫌いなレジスターによって存在します。決済のシーケンスの復元の適用にもかかわらず、前払い金はカウントされません。数量のない合計残高は言うまでもなく、逆も同様です。



氷山のないシステムの通常の状態では、簿記を取得することは困難です。短所が1か月続いていることを証明する唯一の方法は、バックアップです。しかし、彼らも愚か者ではありません-はい、1ヶ月前に短所があったと言います、それから私たちはそれらを削除しました、そして今、彼らは再び出てきました、それはあなたが何かを混乱させたプログラマーです。サプライヤーが問題を他の人に移すことなく単に言い訳をする場合、会計士は長い間考えていました-意識的であろうとなかろうと-人工的な時間的プレッシャーのような方法。



企業には会計の状態を管理するきちんとしたプログラマーがいます。彼は後ろの短所を見て、会計士に伝えます-親愛なる叔母さん、あなたは何をしているのですか、それを排除しましょう！最初に彼らは言う-はい、もちろん、私たちは排除します、それは私たちの利益のためです。四半期を閉じるときに短所は私たちを大きく妨げますので、必ず排除してください。この時点で-たとえば、これは5月-時間的なプレッシャーがない、つまり問題を解決する時間が限られている人はいません。したがって、順序を復元するタスクは、予想どおり、遠くのボックスに延期されます。



現在の日々の仕事を監視する方法で、負の残留物の生成を防ぐことはほとんど不可能です。マイナスへの償却を禁止している場合でも、教区の修正があります。したがって、私たちのまともなプログラマーはため息をつき、待ちます。



たとえば、6月末までに、プログラマーは会計士に短所を削除したほうがいいと何度か思い出させます。締め切りが近ければ近いほど、答えはより積極的になります。性交はあなたの仕事ではありません。仕事の仕方を教えてはいけません。最終的には無視してください。



そして、7月になって、四半期を閉じる必要があります。今、問題は時間プレッシャーモードで解決する必要があります-可能な限り迅速かつ効率的です。あなたが工場でプログラマーとして働いていたなら、あなたはこの瞬間に何が起こるか知っています-タスクは会計からプログラマーに迅速かつ美しく移行します。



プログラマーが試みていますが、inするのは遅すぎます。しかし、会計士は鉄の議論を与えます-一度、すべてを報告する必要があり、会社を閉鎖しなければならないすごい罰金があります。プログラマーと会計士の虐待を司るリーダーに残されたものは何もありません。プログラマーの味方です-脅威はあまりにもリアルに聞こえます。プログラマーは会計士の仕事のように何かを泣き叫んでいます。彼らは何をすべきかを完全によく知っていますし、一般的にプログラマーは会計士の3倍の費用がかかりますが、これはすべて間違っていますが、手遅れです-人為的な時間の問題が発生しました。



通常、このように終わります。プログラマーはマイナスを自分の手で修正することに同意し、マネージャーと会計士の誓いは時間的なプレッシャーを取り除いた後、この体系的な問題に取り組むことを約束します。そして-毎回。



問題の解決策は供給に似ています。 jambの各バリアントに対して自動タスクを実行します。たとえば、ターンアラウンドでマイナスを計算して表示し、責任を設定し、最も重要なことには、タスクがIcebergを取得する日付を設定します。マイナスが発生するとすぐに、自動タスクが表示され、紛争の議論として使用できます。



アカウンティングがこれらの自動タスクを無視することは明らかです。しかし、その後、プログラマーがリーダーシップとのミーティングに欠けているもの、事実があります。ここに横棒があり、ここにその発生の日付があり、ここに負の状態の期間があります-たとえば、1か月です。主なことは、情報を正しく送信することです-見て、親愛なる、私たちの会計は1ヶ月間制御不能な状態にあります、私たちには不利な点があるので、私たちの倉庫費用、費用がどれだけかかったかわかりません。親愛なるリーダー、ポイントはマイナスではなく、会計に関連していることを理解しています。マイナスは極端な状況であり、明らかで間違いです。また、目に見えない暗黙のデータもありますが、データを使用する能力を奪います。まあなど。



また、Icebergは、合意がある場合はプロセスを直接要求します。お金、契約、仕様、予算、計画、特別な衣服の発行などを無限に費やすためのアプリケーション。



官僚は調整が大好きですが、実行する必要があるプロセスとしてではなく、無限に遅延させる可能性があるプロセスとしてです。契約にチーフアカウンタントまたはファイナンシャルディレクターの承認を追加するタスクを与えられた素朴なプログラマーは、シンプルで控えめなことを行います。「契約」などの特定のフィールドをこの契約に追加します。彼はアイスバーグについて知らないので、ゆっくりと痛みを伴う死のために合意を交渉するプロセスを運命づけます。



契約がそれほど重要ではなく、監督の視野にない場合、調整は動的に無限になります。そして、条約の発起人は、偉大な秘跡がいつ起こるかを知るために、主任会計士に定期的に走る以外に選択肢はありません。



Icebergは、問題を即座に迅速に解決します。この場合、承認のために送信された日付と実行された日付の2つの日付を知るだけで十分です。この場合、不整合状態の持続時間は基本的に計算され、この時間は簡単に正規化できます。



私はこれを契約の調整で行いました。そこでは、チェーンは複数の人で構成されていました-ユニットの長、金融家、会計士、弁護士。それぞれが承認のために1日与えられ、Icebergはこの期間のヒット率を90％にしました。



しかし、一方で、問題は始まりました-契約が合意され、紙で署名されたとき、両方のコピーが相手方に送られ、彼の署名とシールが押されます。したがって、紙片は法務部のアーカイブに戻るために戻ってくる必要があります。



しかし、以前に長い承認について不平を言っていた人々は、契約の原本を弁護士に手渡すことを急いでいませんでした。彼らは一般にそれを忘れていました-彼らが契約に署名することは彼らにとって十分であり、あなたはカウンターパーティと協力することができます。ここで弁護士はhowえた-オリジナルなしでは不可能であり、そのようなアウシュヴィッツでは会社に適したチェックは十分ではないようだ。



したがって、別の氷山が契約の原本を引き渡すように見えた。通常の場合は1か月、外国貿易協定の場合は100日が割り当てられます。そして、すべてがうまくいきました。特に弁護士が古い契約が放棄されるまで新しい契約を拒否し始めたとき。失敗した契約の数とタイミングの図はシステムで常に利用可能であり、この問題の重要性を考慮して、それは経営陣の絶え間ない管理下にありました。監督の興味のある分野に行きたがる人は誰もいないので、ほとんどの場合、時間通りにオリジナルを手渡しました。