جبل جليدي

يعلم الجميع ما هو جبل جليدي - قطعة كبيرة من الجليد تطفو في المحيط. يتذكر الجميع الخطأ في جبل الجليد - فقط جزء صغير منه مرئي ، والذي يقع فوق سطح الماء ، والباقي مخفي. وكم هناك ، هذا الباقي - لا أحد يعلم.

موقف مشابه هو مع البيانات في النظم الآلية.

عادة ما نرى البيانات نفسها. المستندات ، مثل فواتير التسليم أو الاستلام ، التحويلات ، المدفوعات ، إلخ. الدلائل - التسميات ، النظراء ، الوحدات. نرى المهام ، سواء تلك العادية أو العملية. نرى البقايا - كم البضائع الموجودة في المخازن ، ومن مدين لنا بالمال ، وكم من عجزنا ، وما إلى ذلك.

أي بيانات ، منفردة أو مجتمعة ، تشكل حالة معينة. على سبيل المثال ، مستودعنا ، في كل لحظة من الزمن ، في حالة ما. نقول ذلك - حالة المستودع. أو حالة المستحقات ، أو المستحقات ، أو حالة المهام ، أو حالة العمليات.

نحن قادرون تمامًا على تقييم الحالة على الفور - سواء في النظام الآلي أو في الحياة. يقدر ، يهرب وينسى.

بعد ذلك ، بعد مرور بعض الوقت ، صادفنا مرة أخرى نفس البيانات أو الموقف. نجري مرة أخرى تقييماً فوريًا للدولة - نقول "كل شيء جيد" أو "كل شيء سيء". يتكرر هذا مرة ثانية ، ثالثة ، مائة مرة الخامسة والعشرين.

إذا قمنا بتقييم الموقف على أنه حرج ، فمن المحتمل أننا سنقوم بتصحيحه بطريقة أو بأخرى. وإذا لم يكن كذلك؟ نعم ، الوضع ليس جيدًا جدًا ، لكن يبدو أنك تستطيع العيش. يحدث هذا غالبًا في الاجتماعات التشغيلية - يقوم شخص ما بطرح سؤال ، ويخبر الموقف ، ويقدم تقييماً. الجميع يئن ، أو يعثر على ألسنتهم و ... ماذا؟ كقاعدة عامة ، ينسون. حتى في المرة القادمة ، حتى يهتم شخص آخر.

في كل مرة يحصل فيها الموقف السلبي على التساهل ، لأننا نراه كما لو كان لأول مرة. شخص ما ، بالطبع ، يتذكر - أوه ، لقد حدث بالفعل ، لا أتذكر ، منذ شهر ، أو ربما ستة أشهر. إنهم يختبئون على حامل ذاكرته الجيدة للغاية حتى لا يصمتوا - فليكن الوضع أفضل كطفل رضيع.

لماذا يحدث هذا؟ ما هو مفقود في معلومات الوضع السلبي؟ هناك تقييم فوري وجودة عالية ومفصلة. كيف تستمر عبارة "كل شيء سيء هنا" ، بحيث تلعب بألوان جديدة وتصبح أكثر إفادة؟

من السهل جدًا الاستمرار في عبارة: "كل شيء سيء هنا ولفترة طويلة". وقت أو مدة الولاية هي المعلومات اللازمة لاتخاذ قرار مناسب.

في الحياة ، الجميع يفهم هذا. اسمحوا لي أن أقدم لكم بعض الأمثلة.

"ليس لدي ما يكفي من المال" - يتطلب التقييم الفوري التدخل الجراحي. "لم يكن لدي ما يكفي من المال لمدة عام الآن" - واو ، لدينا مشكلة نظامية هنا ، والتي نحتاج إلى التفكير فيها بجدية وتغيير شيء ما في الحياة.

"هناك شيء يؤلم ساقي" - حسنًا ، أنت لا تعرف أبدًا ، ربما يكون قد قضى وقتًا ، أو أن الطقس يؤثر على التهاب المفاصل. "لقد ساقت ساقي لمدة ستة أشهر حتى الآن" - هرب على الفور إلى العيادة.

"أحضر الطفل شيطانا" - أحسنت ، حان الوقت ، وهناك حاجة لتحقيق التعادل لتحقيق التوازن. "يجلب الطفل توأمين فقط للربع بأكمله" - أوه ، أنت معتوه قاصر ، ماذا تفعل هناك ، وغداً سأذهب إلى المدرسة ، حيث يوجد رقم هاتف معلم صفك.

بالمثل في أنظمة العمل.

"العميل مدين لنا بمليون" - حسنًا ، ادفع ما تضايقه. "العميل مدين لنا بمليون دولار لمدة ستة أشهر الآن" - أمك ، أين نظرتم؟

"هناك خمسة مواقف عاجلة في بيان العجز" - سوف يقوم القوادون بالطلب ، وهذا هو السبب في أنه لا ينبغي سحب الناس. "تم تعليق خمس وظائف عاجلة في وضع عجز لمدة شهرين الآن" - ولهذا السبب تتراجع المبيعات! اسحب الجميع بشكل عاجل إلى السجادة ، واشترِ على الفور!

"لقد تأخر المبرمجون عن مهمتي" - نعم ، كلهم ​​يقومون بذلك ، فلا تقلق. سوف تفعل. "لقد تأخر المبرمجون بالفعل في مهمتي لمدة شهرين" - اللعنة ، لقد أردت منذ زمن طويل تفريق هذه المتسكعون ، ماذا يفعلون هناك على الإطلاق؟

كما ترون ، فإن مدة الحالة ، خاصة السلبية ، تعطي المعلومات بعدًا جديدًا. كان الأمر كما لو كان هناك معلومات مسطحة ومملة لم يكن من الواضح ما يجب القيام به ، ولكن تم الحصول على صورة ثلاثية الأبعاد. يصبح تحليل الموقف واتخاذ القرار أسهل بكثير.

كل شيء واضح هنا لدرجة أنني لا أستطيع حتى تصديقه - هل هذه التفاهات تستحق فصلاً منفصلاً في الكتاب المدرسي؟ للإجابة على هذا السؤال ، ألق نظرة على نظام المعلومات الخاص بك.

هل تجد العديد من الشروط مع المدة المقاسة؟ تقليديًا ، هناك تقريران يستندان إلى مبدأ Iceberg: الأصول غير السائلة والمتأخرات. هل ، بالمناسبة ، ترى الأصول غير السائلة؟ ليس في كل شيء ، حتى الأنظمة الشائعة ، يمكن رؤية الأصول غير السائلة.

لسوء الحظ ، في نظم المعلومات لا يوجد حتى مفهوم "الدولة". هناك بيانات ووسائل لمشاهدتها ، من زوايا مختلفة. فسحة أنيقة للمحلل الذي يحب أن يتجول في صفيفات كبيرة من الأرقام ، ولكن ليس بمعلومات معقولة كافية لاتخاذ القرارات. علاوة على ذلك ، لا يهم من يتخذ القرار - الشخص أو النظام نفسه.

هناك عدة طرق لتنفيذ مبدأ Iceberg. محاسبة الدُفعات التقليدية ، عند إضافة فاصل إلى صفيف المعلومات - مستند دفعي. على سبيل المثال ، وصلت البضائع إلى المستودع - لا نتذكر فقط التسمية والكمية ، ولكن أيضًا مستند الاستلام - الفاتورة. تحتوي الفاتورة على تاريخ ، ومنه يمكننا دائمًا حساب تاريخ الاستحقاق. يفعلون الشيء نفسه ، على سبيل المثال ، مع المستحقات - فهي لا تخزن فقط الطرف المقابل والمبلغ ، ولكن أيضا المستند الذي أنشأ هذا الدين - على سبيل المثال ، فاتورة التسليم ، أو الدفعة المقدمة إلى المورد.

من الناحية الفنية ، تخلق وثيقة الحزب العديد من الصعوبات.

أولاً ، يزيد عدد السجلات في الجداول. يمكن أن يتحول إدخال واحد "Sleeve، 10 pieces" إلى عشرة إدخالات - "Sleeve 1 pc من 09/01/2017" ، "Sleeve 1 pc من 12/09/2017" ، إلخ.

ثانيا ، هناك حاجة إلى خوارزميات إلغاء دفعة واحدة. على سبيل المثال ، عند الشحن (أي شطب البضائع) ، يلزمك معرفة أي دفعة ناقص الباقي. أو عند الدفع من المشتري ، فأنت بحاجة إلى الإشارة إلى مستند الشحن الذي أتت منه الأموال. يتم استخدام طريقتين: إما الحساب التلقائي للدُفعات أو الإشارة اليدوية الخاصة بهم. اختيار الدُفعات التلقائية هو استراتيجيات الشطب المعروفة في FIFO (أولاً ، الدُفعة الأقدم) و LIFO (أولاً ، الدُفعة الأحدث). يستخدم تحديد الدُفعات اليدوية بشكل شائع في ترحيل المدفوعات.

المشكلة الثالثة ، وليست مشكلة منهجية ، هي أن الحياة الحقيقية لا تطيع خوارزمية إلغاء الدفعات. سيأخذ أمين المخزن الجزء من الرف ، ولكن ليس الجزء الذي حدده البرنامج. إنه لا يعرف ماهية FIFO.

لقد ظهر نظامًا معقدًا تقنيًا ، نادرًا ما يتم استخدام نتائجه. أنا لا أتحدث عن المحاسبة أو المحاسبة الإدارية ، والتي تستخدم الكثير لحساب تكلفة الشطب. أنا أتحدث عن قياس مدة الحالة السلبية - الأصول غير السائلة. كم كان عليك أن ترى حقا ، تعمل بانتظام وفعالية العمليات على الأصول غير السائلة؟

الطريقة الثانية ليست لتخزين مدة جميع الحالات ، ولكن لحسابها إذا لزم الأمر. هذا هو تقدير فوري للمدة. على سبيل المثال ، يمكن للمرء أن يجد الأصول غير السائلة في المستودع دون تخزين الكثير. هناك العديد من الطرق - على سبيل المثال ، فهم الأرصدة الحالية ، والنظر بأثر رجعي في حركة البضائع. إذا لم تكن هناك تحركات ، إذن أمامنا رصيد غير سائل.

لا تحتوي هذه الطريقة على عيوب حساب الدُفعات - فهي لا تتطلب تخزين كميات كبيرة من البيانات ولا تؤدي إلى تعقيد العمل الحالي. لكن الميزة الرئيسية للمحاسبة الدفعية - تخزين المدة - ليست في ذلك. ترى تقديراً للمدة على الفور فقط ، في وقت معين. ذهبنا ، بدا ، تقدير ، خرج - تقييم مدة اختفت.

من ناحية - حسناً ، هذا جيد. يمكنك استخدام خوارزمية لحساب المدة ، ودمجها في العمليات - دع النظام يتفاعل عندما تستمر الحالة السلبية. ولكن ، للأسف ، لا يكون التقدير الفوري للمدة فوريًا - حيث يتم إنفاق موارد النظام على الحساب بحيث لا تتعدى تكلفة الضوضاء فقط كل دقيقة.

يمكن استخدام تقدير فوري للمدة للعمليات غير الهامة التي لا تحتاج إلى مراقبة كل يوم. على سبيل المثال ، نفس الأصول غير السائلة عند إنشاء عملية التخلص منها - مرة واحدة كل شهر تقوم بإجراء العمليات الحسابية ، حدد قائمة العناصر الأكثر تراكمًا ، وتشكل مهمة التخلص منها (على سبيل المثال ، البيع بسعر مخفض أو تخريد).

الطريقة الثالثة هي حساب وفصل وتخزين وتتبع الحالة المزروعة.

على سبيل المثال ، لديك بيان عجز - قائمة بالسلع التي تحتاج إلى شرائها. للإنتاج ، المبيعات ، الإصلاحات ، إلخ. ليس من المنطقي مراقبة بيان العجز بالكامل - المراكز منتهية الصلاحية تمامًا. هذه المواقف الماضية تستحق تسليط الضوء عليها ، لأنه لن يكون هناك الكثير منها؟

فقط احفظ في مكان منفصل في النظام قائمة من العناصر منتهية الصلاحية ، مع الكميات ، والأهم من ذلك ، تاريخ حدوثها. بعد كل شيء ، لا توجد دائما وظائف منتهية الصلاحية هناك؟ بمجرد ظهورها - تذكر أن تاريخ الظهور سيكون نقطة البداية للمدة.

ثم النظام يفعل كل شيء في حد ذاته. ينظر بشكل دوري من خلال العجز - الشيكات إذا كانت هناك مواقف منتهية الصلاحية. إن لم يكن ، ممتازة ، ثم توقفت الحالة السلبية. يمكن نسيان وحذف القائمة المحفوظة للمواضع المتأخرة من النظام (هنا ، وفقًا لتقديرك ، يمكنك تركها في الذاكرة ، أي للحصول على تحليل بأثر رجعي أو نظام التحفيز). إذا كانت المراكز منتهية الصلاحية لا تزال قليلة ، فهي جيدة أيضًا (بالنسبة للنظام) ، لأنك لا تحتاج إلى فعل أي شيء ، فالساعة تدق وتنتهي المدة.

الشخص الذي يشرف على العجز المتأخر سيكون ببساطة سعيدًا. أولاً ، لم يعد بإمكانه متابعة - فقط قم بإعداد إشعار حول التأخير. ثانياً ، لم تعد بحاجة إلى معرفة ما إذا كان التأخير قد ظهر لفترة طويلة - سيتم عرض المدة تلقائيًا. ثالثًا ، ليس من الضروري تتبع لحظة اختفاء التأخير - سيخبرك النظام عندما تسير الأمور بشكل جيد.

سيكون من الأسهل لك ، كمبرمج أعمال ، بناء عمليات الاستجابة في نظام العمل. على الرغم من عدم وجود فهم للمدة ، إلا أنك تضطر إلى سحب الشخص فورًا ، بمجرد ظهور حالة سلبية. و "الوخز" الخاص بك سوف يعلق باستمرار أمام أنفك ، مثل قطعة قماش حمراء.

عندما تكون هناك مدة ، يصبح الإعداد أكثر دقة - أنت بنفسك تختار اللحظة التي تُظهر فيها مشكلة لشخص ما. يمكنك أيضًا اختيار شاشة ملونة بناءً على مدة الحالة السلبية. على سبيل المثال ، الأصفر - يوم واحد ، أحمر - يومين أو أكثر ، إلخ.

في الوقت نفسه ، يمكنك بناء نظام استجابة المنبع. على سبيل المثال ، أوضح أولاً تأخر العجز في المورد. وبعد يوم ، إن لم يكن القضاء ، لرئيس التموين. بعد ثلاثة أيام ، إلى المدير التجاري. في أسبوع - للمخرج.

علاوة على ذلك ، فهمت: يعتمد جوهرها على المستوى الذي ارتفعت إليه المهمة. أنت تطلب من المورد التخلص من التأخير - يجب عليه طلب المنصب. أنت تطلب من مدير التوريد الانتباه ، وربما نقل المواقف إلى مورد آخر. أنت تقول للمدير أن خدمة التوريد بأكملها تعمل بطريقة غريبة ، وهناك حاجة إلى تغييرات النظام.

الملامح الرئيسية لهذه الطريقة: التخزين المنفصل لبيانات الحالة والتحديث التلقائي. تم تنفيذها تقنيًا باستخدام مبدأ "Auto Task" ، والذي سيتم مناقشته لاحقًا.

في هذه العملية ، ستجد بالتأكيد طرقًا أخرى لتحديد مدة الولاية ، أي حجم جبل الجليد تحت الماء. قد تكون برمجة في أنظمة لا تعمل فيها الطرق التي ذكرتها - ثم عليك البحث عن طرقك الخاصة.

الشيء الرئيسي - لا تنسى مبدأ "جبل الجليد" عند برمجة نظام العمل.

خاصة إذا كنت ترغب في استخدام محاسبة الأجزاء - يجب إعادة وضعها أثناء التصميم ، بأثر رجعي يتم نشرها بصعوبة كبيرة.

يمكن تضمين تقييم فوري للمدة ، مثل "المهام التلقائية" ، في أي وقت. حسنًا ، أطفئها أيضًا. في هذا الخفة هو مصلحتهم.

سأقدم بعض الأمثلة على استخدام جبل الجليد من ممارستي.

المثال الأول هو نظم إدارة المهام. هناك مهمة ، أو مهمة ، أو مذكرة. هناك البادئ ، هناك أداء. عندما يتم قبول المهمة في العمل ، يكون كل شيء واضحًا - هناك موعد نهائي ، ويمكنك بسرعة تحديد ما إذا كان كل شيء مع المهمة جيدًا أم لا.

لكن المشكلة لديها أيضا بعض الدول المتوسطة. على سبيل المثال ، كتبه البادئ وأرسله ، ويجب أن يقبله المنفذ للعمل. القبول في العمل هو علامة معينة في المهمة. إلى أن يضع المقاول ذلك ، فإن حالة المهمة هي الجزء تحت الماء من الجبل الجليدي. لا يوجد شيء واضح عندما يتأخر في النهاية للقيام بذلك.

لقد تصرفت ببساطة - أضفت تاريخ القبول للعمل كحقل منفصل في المهمة. مقبول - تم تذكر التاريخ. وتاريخ إرسال المهمة إلى المنفذ موجود بالفعل. وفقًا لذلك ، نحصل على فترتين من الحالة السلبية. حتى يتم قبول المهمة ، تكون المدة هي الفرق بين التاريخ الحالي وتاريخ الإرسال. عندما ، على الرغم من ذلك ، قبل المقاول ذلك ، يظهر الفاصل الزمني الدقيق بين القبول والإرسال ، وهو ما يتم تذكره إلى الأبد في النظام ويستخدم لمزيد من التحليل.

يحدث موقف مماثل ، مع مدة غير مفهومة ، عندما يقوم المقاول بالعمل وأرسله إلى البادئ للتحقق منه. عندما يتحقق هناك ، فإنه غير معروف. أي مبرمج لائق يعمل مباشرة مع المستخدم النهائي سيؤكد أن المهام في كثير من الأحيان تتجمد في الاختبار. علاوة على ذلك ، جسديا يمكن التحقق منه بالفعل ، يحب المستخدم كل شيء ، لكنه لا يكلف نفسه عناء تسجيل الدخول إلى النظام وتقديم مذكرة.

الحل مشابه. نضيف تاريخين للمهمة - عندما يتم إرسال المقاول للتحقق ، وعندما يكون رد فعل البادئ ، قبل النتيجة أو عاد للمراجعة. وفقًا لذلك ، تكون مدة حالة التحقق في متناول اليد دائمًا ، ويمكننا تطبيع وقت التحقق من المهمة. حسنا ، لذلك لم يكن كذلك.

المثال المفضل لدي هو الشراء. كل شيء بسيط مع المهام - هناك دائمًا كائن يتم تسجيل هذه المهمة بالذات ، ويمكنك إضافة حقول إلى هذا الكائن الذي يخزن البيانات طوال مدة الولاية.

والمشتريات هو تيار. لا أحد هناك ، في عقلهم الصحيح ، سوف تفرض أي مهام منفصلة. حسنا ، تخيل نفسك - فتاة تجلس وترتب البطانات. كل يوم نفس البطانات. وكذلك مهاوي ، البراغي ، المكسرات ، المعادن ، المطروقات ، الجملات ، إلخ.

لا يوجد سوى معلومات حول ما يجب طلبه. نعم ، يحدث ذلك على مستويات مختلفة من التفاصيل - في بعض الأحيان مجرد قائمة بالعناصر والكميات ، وأحيانًا - بواسطة المستلمين والمقاولين والأوامر والوحدات ، إلخ. لكن هذه المعلومات دائمًا ما تكون فورية ، مثل الفلاش. ذهبت - كما ترى ، تحتاج إلى طلب 1020 قطعة. بعد دقيقة دخل - واو ، إنه بالفعل 1200 ، لأن الوضع قد تغير.

يفهم القوادون هذا ويستفيدون منه. في الاجتماعات ، واستخلاص المعلومات والنشطاء ، غالباً ما يتم محاولة المشترين للوصول إلى القاع ، ولكن منهم ، مثل المياه قبالة بطة. يقولون لهم - يا شباب ، وما هي البطانات المفقودة؟ حتى أمس ، نشأت حاجة فقط! - أجب عن هؤلاء. كيف حال الأمس؟ حسنا ، أمس. أقسم أنني ذهبت إلى النقص في صباح اليوم الماضي ، لم تكن هناك شجيرات!

لإثبات أن الأكمام كانت بالأمس ، يمكنك فقط من خلال رفع النسخة الاحتياطية. بطبيعة الحال ، لن يلتقط الأشخاص الحيون النسخ الاحتياطية يوميًا ، لذلك يتوصل البائعون والمصنعون المتعبون إلى نسختهم الخاصة من Iceberg - المطبوعات. على سبيل المثال ، يدخلون النظام يوم الاثنين ، وينظرون إلى العجز ، ويطبعونه. عندما تنشأ مشكلة ، أو ممتنون للموردين ، أظهر لهم هذه الورقة.

لكن من السهل تفادي مثل هذه الورقة. يقول مندوبو المبيعات - ما الذي تقفزني إليه هنا؟ نعم ، لم يكن هناك عدد كاف من الأكمام يوم الاثنين ، فماذا في ذلك؟ بالفعل يوم الثلاثاء كان هناك الكثير لدرجة أن الجميع كان لديهم الكثير! وما تراه في النظام اليوم نشأ بالأمس فقط.

ثم يجبرون أيضًا على المشاركة في الشؤون الورقية - فهم لا يطبعون النقص فحسب ، بل يمنحون الموردين للتوقيع. وتطلب مواعيد التسليم للالتصاق. أنت تدرك أن العملية من حيث الكفاءة هي غاية في الأهمية.

عملت المبدأ Iceberg في المهام ، لكنها لم تنجح في العرض. لقد أدرك البائعون أنه يجب القيام بشيء ما ، وبدأوا في تحديد المهام للشراء - لقد قاموا بإنشاء الكائن مباشرة ووضع قائمة بالمواقف عليه وينتظرون التنفيذ. في البداية بدأ العمل ، ثم بدأ الموردون يرفضون بغباء مثل هذه المهام ، مع تعليق مثل "لسنا بحاجة إلى وضع تعليمات منفصلة لعملنا الروتيني". بشكل عام ، التعليق الصحيح هو أنه إذا قمت بتعيين مهمة للجميع ، فسيتعين على عمال النظافة أن يكونوا متصلين بالنظام.

تم حل المشكلة عن طريق المهام التلقائية و Iceberg ، والتي توجد افتراضيًا. تؤدي وظيفة autotask ببساطة إلى حدوث عجز ، وتفتت المواضع المفقودة من قِبل فناني الأداء ، وتشكل بعض الكائنات التي تحتوي على معلومات حول ما يجب طلبه من الموردين. يتم تحديد تاريخ التكوين التلقائي للمهمة تلقائيًا ، بالإضافة إلى تاريخ التنفيذ ، أي وضع المناصب مع الموردين.

إذا كان ذلك ضروريًا ، على سبيل المثال ، 100 جلبة ، وطلب المورد 70 ، فإن إغلاق تلقائي لا يغلق ، ولكن يتم ضبطه ببساطة - تحتاج الآن إلى وضع 30 وظيفة. المهم هو تاريخ بدء الحالة السلبية ، أي العجز لا يزال هو نفسه. طلب الشخص 70 وظيفة لفترة زمنية واحدة ، و 30 وظيفة أخرى.

مع تطبيق جبل الجليد ، تم حل المشكلة بسرعة كبيرة ، لأنه كان من المستحيل إخفاء أي شيء. أولاً ، تتم المحاسبة عن مدة العجز في سياق المواقف والكميات ، وثانياً ، بالرجوع إلى المقاول.بالطبع ، بالطبع ، ولدت شركة KPI معينة للمورد - ما هي النسبة المئوية من الوظائف التي يطلبها في الوقت المحدد (يبدو أنه كان عليه أن يجتمع اليوم ، منذ اللحظة التي نشأت فيها الحاجة).

جبل الجليد يقع بشكل جيد على المحاسبة. بالنسبة لأولئك ، بعد كل شيء ، هناك دائما شيء خاطئ في مكان ما. الأرصدة السلبية موجودة ، في مجموعة متنوعة من الحسابات ، أو في السجلات التي يكرهونها. لا يتم حساب التقدم ، على الرغم من تطبيق استعادة تسلسل المستوطنات. ناهيك عن إجمالي الأرصدة بدون كمية ، والعكس صحيح.

في الحالة الطبيعية للنظام ، وبدون وجود جبل جليدي ، يصبح الوصول إلى قسم المحاسبة أمرًا صعبًا. الطريقة الوحيدة لإثبات أن السلبيات كانت معلقة لمدة شهر هي نسخة احتياطية. لكنهم أيضًا ليسوا أغبياء - سيقولون نعم ، كانت هناك سلبيات قبل شهر ، ثم أزلناهم ، والآن خرجنا مجددًا ، أنت المبرمجون الذين خلطوا شيئًا ما. إذا كان المورّدون ببساطة يعذّرون أنفسهم دون تحويل المشاكل إلى الآخرين ، ففكر المحاسبون منذ فترة طويلة - لا أعرف أو بوعي أو لا - طريقة مثل ضغط الوقت المصطنع.

هناك مبرمج لائق في المؤسسة يهتم بحالة المحاسبة. يرى السلبيات في الخلف ، ويخبر المحاسبين - العمات العزيزات ، ماذا تفعلين ، دعنا نقضي عليه! في البداية يقولون - نعم ، بالطبع ، سنقضي عليها ، فهذا في مصلحتنا. سلبيات سوف تعيقنا كثيرا عند إغلاق الربع ، تأكد من القضاء عليها. في هذه اللحظة - دعنا نقول ، هذا هو أيار (مايو) - لا يوجد ضغط وقت ، أي لا أحد لديه وقت محدود لحل المشكلة. لذلك ، تم تأجيل مهمة استعادة النظام ، كما هو متوقع ، إلى المربع البعيد.

يكاد يكون من المستحيل منع إنشاء مخلفات سلبية بطرق مراقبة العمل اليومي الحالي. حتى لو قمت بحظر الشطب بالسالب ، فهناك تصحيح للرعية. لذلك ، يتنهد مبرمجنا الكريم وينتظره.

قبل نهاية يونيو ، على سبيل المثال ، يذكر المبرمج المحاسب عدة مرات أنه سيكون من الجيد إزالة السلبيات. كلما اقترب الموعد النهائي ، أصبحت الإجابة أكثر عدوانية - توقف ، ليس من شأنك ، ولا تعلمنا كيفية العمل ، وفي النهاية ، تجاهل تام.

ثم جاء يوليو ، فمن الضروري إغلاق الربع. الآن يجب حل المشكلة في وضع ضغط الوقت - بأسرع وقت وبكفاءة ممكنة ، لأنه لا يزال هناك الكثير من الأشياء التي يتعين القيام بها ، باستثناء السلبيات. إذا كنت تعمل كمبرمجين في المصنع ، فأنت تعلم ما يحدث في هذه اللحظة - المهمة تتحول بسرعة وبشكل جميل من المحاسبة إلى المبرمجين.

بعد فوات الأوان لتكون ساخطا ، على الرغم من أن المبرمجين يحاولون. لكن المحاسبين يقدمون حججاً حديدية - كل شيء ، مرة واحدة ، من الضروري تسليم التقارير ، وهناك غرامات soooo يجب أن تكون الشركة مغلقة. لم يتبق شيء للزعيم الذي يسيطر على إساءة استخدام المبرمج والمحاسب كيفية اتخاذ جانب الآخر - يبدو التهديد حقيقيًا جدًا. المبرمج هناك شيء ما ، مثل هذا هو عمل المحاسب ، فهم يعرفون ماذا يفعلون ، وبشكل عام يكلف المبرمج الشركة ثلاثة أضعاف ما يكلفه المحاسب ، وكل هذا خطأ ، ولكن بعد فوات الأوان - نشأت مشكلة زمنية مصطنعة.

وعادة ما ينتهي مثل هذا: يوافق المبرمج على إصلاح السلبيات بأيديه ، ويتعهد المدير والمحاسب بمعالجة هذه المشكلة النظامية بعد القضاء على ضغط الوقت. وهكذا - في كل مرة.

يشبه حل المشكلة العرض. نحن نقوم بمهمة تلقائية لكل متغير من دعامة - على سبيل المثال ، نقوم بحساب وإظهار السلبيات في التحول ، ونحدد المسؤول ، والأهم من ذلك ، تاريخ نشأة المهمة للحصول على جبل الجليد. الآن ، ما إن نشأ ناقص ، تظهر مهمة تلقائية ، ويمكن استخدامها كوسيطة في النزاعات.

من الواضح أن المحاسبة ستتجاهل هذه المهام. ولكن بعد ذلك سوف يظهر شيء يفتقر إليه المبرمج في الاجتماعات مع الإدارة - حقائق. هنا هو عضادة ، وهنا هو تاريخ وقوعها ، وهنا هي مدة الحالة السلبية - شهر ، على سبيل المثال. الشيء الرئيسي هو تقديم المعلومات بشكل صحيح - نظرة ، عزيزي القائد ، لقد كانت حساباتنا في حالة لا يمكن التحكم فيها لمدة شهر الآن ، وليس لدينا أي فكرة عن مقدار تكاليف مستودعاتنا ، ومقدارنا من التكاليف ، لأننا لدينا عيوب. أنت تفهم ، يا عزيزي الزعيم ، أن النقطة ليست في السلبيات ، ولكن فيما يتعلق بالمحاسبة. ناقص هو الوضع المدقع ، خطأ واضح وواضح. وما زالت هناك أشياء ضمنية غير مرئية للعين ، ولكنها تحرمك من فرصة استخدام البيانات. حسنا وهلم جرا.

حتى Iceberg يسأل مباشرة عن أي عمليات حيث يكون هناك اتفاق. طلبات إنفاق الأموال والعقود والمواصفات والميزانيات والخطط وإصدار ملابس خاصة وهلم جرا ، إلى ما لا نهاية.

يحب البيروقراطيون التنسيق ، لكن ليس كعملية يجب القيام بها ، ولكن كعملية يمكن أن تتأخر إلى ما لا نهاية. يعمل المبرمج الساذج ، الذي تم تكليفه بإضافة موافقة كبير المحاسبين أو المدير المالي إلى العقد ، بكل بساطة وبدون تفهم - يضيف مجالًا معينًا ، مثل "متفق عليه" ، إلى هذا العقد. إنه لا يعلم عن جبل الجليد ، لذلك يفسد عملية التفاوض على الاتفاقات من أجل الموت البطيء والمؤلم.

لن يكون التنسيق بلا نهاية بشكل ديناميكي إذا لم يكن العقد مهمًا للغاية ولم يكن في مجال رؤية المدير. ولن يكون أمام المبادرين في المعاهدات خيار سوى الترشح بشكل دوري لكبير المحاسبين لمعرفة متى سيحدث السر العظيم.

جبل الجليد يحل المشكلة على الفور وبسرعة. في هذه الحالة ، يكفي معرفة تاريخين - وقت إرساله للموافقة ، ومتى تم. يتم احتساب مدة حالة عدم الاتساق في هذه الحالة بشكل أولي ، ويمكنك التطبيع بشكل تافه هذه المرة.

لقد فعلت ذلك بتنسيق العقود ، حيث كانت السلسلة تتألف من عدة أشخاص - رئيس الوحدة والممول والمحاسب والمحامي. أعطيت كل يوم للموافقة عليها ، ورفع Iceberg نسبة الزيارات في هذه الفترة إلى 90 ٪.

ومع ذلك ، بدأت المشكلة من ناحية أخرى - عندما تم الاتفاق على الاتفاق وتوقيعه على الورق ، يتم إرسال نسختين إلى الطرف المقابل لوضع توقيعه وختمه. وفقًا لذلك ، ينبغي أن تعود الورقة بعد ذلك للدخول إلى أرشيف القسم القانوني.

لكن الأشخاص الذين اشتكوا في السابق من الموافقة الطويلة لم يكونوا في عجلة من أمرهم لتسليم أصول العقود إلى المحامين. لقد نسوا ذلك بشكل عام - يكفي أن يتم توقيع العقد ، ويمكنك العمل مع الطرف المقابل. هنا عوي المحامون - من المستحيل بدون النسخ الأصلية ، فإن أي شيك سوف يلائم شركة أوشفيتز بحيث لا يبدو ذلك كافياً.

تبعا لذلك ، ظهر فيض آخر لتسليم أصول العقود. خصص شهرًا للعادي ، و 100 يوم لاتفاقيات التجارة الخارجية. وكل شيء يعمل. خاصة عندما بدأ المحامون برفض العقود الجديدة حتى تم تسليم العقود القديمة. كانت صورة عدد العقود الفاشلة وتوقيتها متاحة باستمرار في النظام ، ونظراً لأهمية هذه القضية ، فقد كانت تحت السيطرة المستمرة للإدارة. لا أحد يريد الدخول في مجال اهتمام المدير في كثير من الأحيان ، لذلك سلموا النسخ الأصلية في الوقت المحدد تقريبًا.