هشدار چیست؟
هشدار برای یک نیاز تکرارشونده طراحی شده است: داده در زمانهای تعیینشده بررسی شود و در موقعیت موردنظر، مسیر اعلان به کار بیفتد. برای نمونه، مسئول موجودی میخواهد عبور موجودی یک محصول از حد سفارش را دنبال کند، بدون اینکه هر بار همان پرسش را دوباره اجرا کند. یک هشدار مفید فقط یک شرط عددی نیست؛ باید منبع، معنای شاخص، زمان بررسی، گیرنده و اقدام پس از دریافت پیام روشن باشد.
هشدار را به یک اقدام پیوند دهید
Section titled “هشدار را به یک اقدام پیوند دهید”از وضعیتی شروع کنید که مسئول مشخص و اقدام قابل انجام دارد. «موجودی قابل فروش محصول الف کمتر از ۵۰ واحد شد» میتواند به بررسی سفارش تأمین منجر شود. «چیزی در داده غیرعادی شد» مبهم است، زیرا نوع تغییر و مسئول پاسخگویی معلوم نیست. پیش از ساخت، توضیح دهید چرا حد انتخابی برای کار شما مهم است و کدام داده آن را اندازه میگیرد. آستانهٔ مناسب از سرعت مصرف و زمان تأمین میآید؛ خود برنامه قرار نیست این تصمیم عملیاتی را بدون زمینه حدس بزند.
اگر سؤال فقط یک بار مطرح میشود، گفتوگو مسیر مناسبتری است. اگر هنگام مراجعه میخواهید چند شاخص را کنار هم ببینید، داشبورد را به کار ببرید. هشدار زمانی مفید است که مشاهده باید تکرار شود یا خلاصهای طبق برنامه تهیه گردد. حتی هشدار درست هم جای اقدام انسانی پس از دریافت پیام را نمیگیرد؛ برای رسیدگی، مسئول و روش پیگیری داشته باشید.
چرخهٔ هشدار را جداگانه بخوانید
Section titled “چرخهٔ هشدار را جداگانه بخوانید”ابتدا منبع خوانده میشود و نتیجهٔ بررسی به دست میآید. سپس بر اساس تعریف هشدار و وضعیت قبلی، تصمیم گرفته میشود آیا رویدادی برای اعلان ایجاد شود. بعد، ارسال به مخاطبان مرتبط انجام میشود. این مراحل یک نتیجهٔ واحد نیستند: اجرای موفق داده به معنای برقرار شدن شرط نیست و برقرار شدن شرط نیز دریافت قطعی پیام توسط انسان را ثابت نمیکند. برای پیگیری باید هر مرحله را در محل مربوط بررسی کنید.
در هشدار شرطی، ادامه داشتن یک وضعیت لزوماً در هر بررسی پیام تازه ایجاد نمیکند. تنظیماتی مانند یادآوری مجدد، فاصلهٔ سکوت و محدودیت فعالشدن بر رویداد اعلان اثر دارند. همچنین میتوان اعلان رفع هشدار را تنظیم کرد. نوع خلاصهٔ دورهای هدف متفاوتی دارد و برای گزارش طبق برنامه است؛ نتیجهٔ آن را مانند عبور از یک آستانه نخوانید. خلاصه و شرط باید با نیاز واقعی شما انتخاب شوند.
چه چیزهایی را پیش از ساخت آماده کنید؟
Section titled “چه چیزهایی را پیش از ساخت آماده کنید؟”منبع قابل دسترس و تعریف شاخص را آماده کنید. موجودی فیزیکی، موجودی رزروشده و موجودی قابل فروش متفاوتاند. برای پایش موجودی قابل فروش، باید بدانید کدام ستون یا محاسبه این مفهوم را بیان میکند. در شرکت دارای چند اتصال، منبع درست را مشخص کنید. قابلیت ارزیابی هشدار برای منابع مختلف پشتیبانی میشود، اما تعریف و روش خواندن هر منبع باید با همان اتصال سازگار باشد؛ محدودیت نمودار داشبورد را به همهٔ هشدارها تعمیم ندهید.
گیرندگان را نیز از قبل آماده کنید. مخاطب باید فعال و، در کانالهای نیازمند تأیید، تأییدشده باشد و به همین هشدار متصل شود. صرف حضور فرد در شرکت یا وجود یک مخاطب در فهرست، ارسال برای او را تضمین نمیکند. راهنمای مخاطبان تفاوت ثبت، تأیید و اتصال را توضیح میدهد. برای مدیریت تعریفها به دسترسی مدیریت هشدارها نیاز دارید؛ گیرندهٔ درونبرنامهای برای خواندن صندوق شخصی خود این دسترسی مدیریتی را لازم ندارد.
ساخت و وضعیت جاری را مرور کنید
Section titled “ساخت و وضعیت جاری را مرور کنید”از فهرست هشدارها، مسیر ساخت را باز کنید و خواسته را به زبان روشن توضیح دهید. برنامه خلاصهٔ تعریف و بخش اعتبارسنجی را نشان میدهد. پیش از ذخیره، آزمون با دادهٔ فعلی و بازآزمایی را بررسی کنید. این بررسیهای تعریف، پیام واقعی برای گیرندگان ارسال نمیکنند. اما «آزمایش هشدار» در صفحهٔ هشدار ذخیرهشده، آزمایش مسیر ارسال است و میتواند پیام واقعی ایجاد کند؛ این دو را یکی ندانید.
پس از ذخیره، فعال یا غیرفعال بودن را از وضعیت داده جدا بخوانید. غیرفعال بودن یعنی بررسی زمانبندیشده متوقف است، نه اینکه شرط هرگز برقرار نشده. وضعیت خراب نشان میدهد مشکل ارزیابی نیازمند رسیدگی است؛ برقرار نشدن شرط، خرابی نیست. آخرین و بررسی بعدی را همراه وضعیت ببینید. وجود نام هشدار در فهرست بهتنهایی اثبات اجرای منظم آن نیست.
یک مثال فرضی از چند بررسی
Section titled “یک مثال فرضی از چند بررسی”فرض کنید حد موجودی قابل فروش محصول الف ۵۰ واحد است و بررسی دورهای تعریف کردهاید. در مثال فرضی، یک بررسی مقدار ۶۰ را برمیگرداند و شرط برقرار نیست. بررسی بعدی مقدار ۴۵ را میبیند و وضعیت هشدار ایجاد میشود. در بررسی بعدی، مقدار ۴۲ همچنان زیر حد است؛ بسته به تنظیم یادآوری، ممکن است پیام تازهای ساخته نشود. نبود پیام تازه در این مرحله به معنای برگشت موجودی به حد عادی نیست.
بعداً موجودی به ۷۰ میرسد. اگر اعلان رفع هشدار در تعریف فعال باشد و شرایط آن برقرار شود، پیام رفع وضعیت میتواند ثبت شود. اما اگر اتصال در زمان بررسی قطع شود، مقدار نامعلوم است؛ آن را ۷۰ یا صفر فرض نکنید. خطای خواندن نمیتواند سلامت موجودی را ثابت کند. تاریخچهٔ اجرا کمک میکند بررسی بدون هشدار، خطا و محدود شدن اعلان را از هم تشخیص دهید.
محدودیت و رسیدگی عملیاتی
Section titled “محدودیت و رسیدگی عملیاتی”شرایط فعلی شرکت میتواند تعداد هشدارها، فاصلهٔ مجاز بررسی و ظرفیت اعلان را محدود کند. این شرایط را در برنامه ببینید و زمانبندی را متناسب با سرعت تغییر داده انتخاب کنید. بررسی خیلی مکرر روی منبعی که روزانه بهروز میشود الزاماً خبر بهتری نمیدهد. همچنین هنگام دریافت پیام، زمان بررسی و بازهٔ داده را بخوانید؛ پیام دربارهٔ مشاهدهٔ ثبتشده است و ممکن است وضع منبع بعد از آن تغییر کرده باشد.
اگر پیام مورد انتظار نرسید، ابتدا تاریخچهٔ ارزیابی، سپس رویداد و وضعیت ارسال، و در پایان مقصد واقعی را کنترل کنید. صندوق خالی بهتنهایی نبود مشکل را ثابت نمیکند. برای تعریف نخستین هشدار ساخت هشدار، برای آزمودن مسیر ارسال تاریخچه و آزمایش و برای خواندن اعلانهای شخصی صندوق هشدار را ادامه دهید.