مدل اقدامپذیری: از اندازهگیری تا هشدار، مسئول و واکنش — وگرنه IoT فقط آرشیو است.
نویسنده
تیپرینو
تاریخمطالعه
9 دقیقه
داده سنسور بهتنهایی ارزش زیادی ایجاد نمیکند. اگر یک سنسور دما، رطوبت، مصرف انرژی یا وضعیت یک دستگاه را اندازهگیری کند اما هیچکس بر اساس داده آن تصمیمی نگیرد، در نهایت فقط حجم دیگری از اطلاعات تولید شده است.
ارزش واقعی یک سیستم هوشمند زمانی ایجاد میشود که داده به یک اقدام مشخص متصل شود؛ یعنی سیستم بداند چه چیزی را اندازه بگیرد، چه زمانی یک وضعیت غیرعادی محسوب میشود، چه کسی باید مطلع شود و در نهایت چه اقدامی باید انجام شود.
داده سنسور بدون اقدام بیفایده است؛ پاسخ کوتاه
برای هر سنسور باید چهار چیز از ابتدا مشخص باشد: چه چیزی اندازهگیری میشود، آستانه هشدار چیست، چه کسی باید مطلع شود و در پاسخ چه کاری باید انجام شود.
برای مثال، نصب سنسور دما در یک فضای حساس بهتنهایی یک راهکار کامل نیست. باید مشخص باشد اگر دما از محدوده مجاز خارج شد، هشدار به چه کسی ارسال میشود، چه مدت برای واکنش وجود دارد و مسئول مربوطه دقیقاً چه اقدامی باید انجام دهد.
حلقه چهارمرحلهای از داده تا اقدام
یک سیستم سنسوری کاربردی را میتوان به یک حلقه ساده تقسیم کرد:
اندازهگیری قابل اعتماد: سنسور باید دادهای متناسب با نیاز واقعی کسبوکار تولید کند.
تشخیص انحراف: سیستم باید بتواند وضعیت عادی را از یک وضعیت غیرعادی تشخیص دهد.
اطلاع به مسئول درست: هشدار باید به فرد یا تیمی برسد که واقعاً امکان واکنش دارد.
اقدام و ثبت نتیجه: مسئول باید اقدام مشخصی انجام دهد و نتیجه آن تا حد امکان ثبت شود.
اگر یکی از این حلقهها حذف شود، سیستم ناقص میشود. مثلاً داشبوردی که وضعیت را نشان میدهد اما هیچ مسئول مشخصی برای پیگیری آن وجود ندارد، بیشتر ابزار مشاهده است تا یک سیستم عملیاتی.
اول مشخص کنید چه چیزی باید اندازهگیری شود
اشتباه رایج این است که انتخاب سنسور قبل از مشخص کردن مسئله انجام شود. ابتدا باید پرسید چه مشکلی قرار است شناسایی یا کنترل شود.
آیا هدف کنترل دما و رطوبت است؟
آیا باید خرابی یا توقف یک دستگاه سریعتر تشخیص داده شود؟
آیا مصرف انرژی غیرعادی اهمیت دارد؟
آیا باز و بسته شدن درها یا دسترسی به یک محیط باید ثبت شود؟
آیا هدف کاهش زمان واکنش به یک اتفاق است؟
بعد از مشخص شدن مسئله، میتوان تعیین کرد چه دادهای واقعاً لازم است و چه سنسوری میتواند آن را تولید کند.
هشدار خوب چه ویژگیهایی دارد؟
قرار نیست سیستم برای هر تغییر کوچک هشدار ارسال کند. اگر تعداد هشدارها بیش از حد باشد، کاربران بهمرور نسبت به آنها بیتفاوت میشوند؛ پدیدهای که معمولاً از آن با عنوان خستگی هشدار یاد میشود.
برای طراحی هشدار بهتر، چند سؤال را از ابتدا مشخص کنید:
آستانه چیست؟ از چه نقطهای وضعیت واقعاً نیازمند واکنش است؟
شدت هشدار چقدر است؟ آیا فقط اطلاعرسانی است یا نیاز به اقدام فوری دارد؟
چه کسی باید مطلع شود؟ هشدار باید به مسئول مرتبط برسد، نه لزوماً همه افراد.
از چه کانالی ارسال شود؟ پیامک، اعلان، داشبورد یا سیستم تیکتینگ میتواند بسته به سناریو مناسب باشد.
اقدام بعدی چیست؟ دریافت هشدار بدون مشخص بودن اقدام، بخش مهمی از ارزش سیستم را از بین میبرد.
آستانه هشدار را هوشمندانه تعیین کنید
آستانه بیش از حد حساس میتواند تعداد هشدارهای غیرضروری را زیاد کند و آستانه بیش از حد باز ممکن است باعث شود مشکل زمانی شناسایی شود که فرصت واکنش مناسب از دست رفته است.
بهتر است آستانهها بر اساس شرایط واقعی کسبوکار تعیین شوند و پس از مشاهده دادههای واقعی، در صورت نیاز اصلاح شوند. در بعضی سناریوها نیز بهجای یک آستانه ثابت، بررسی مداوم روند تغییرات میتواند اطلاعات مفیدتری ایجاد کند.
داشبورد باید برای تصمیمگیری طراحی شود
یک داشبورد خوب لزوماً داشبوردی نیست که بیشترین نمودار را داشته باشد. سؤال اصلی این است که کاربر پس از دیدن داده باید چه تصمیمی بگیرد.
برای هر شاخص بهتر است مشخص باشد:
وضعیت فعلی چیست؟
آیا وضعیت عادی است یا نیاز به بررسی دارد؟
چه کسی مسئول پیگیری است؟
اقدام پیشنهادی چیست؟
آیا اقدام انجام شده و نتیجه آن چه بوده است؟
این رویکرد باعث میشود داشبورد از یک صفحه گزارشگیری ساده به بخشی از فرایند عملیاتی کسبوکار تبدیل شود.
اگر اینترنت قطع شود چه اتفاقی میافتد؟
سناریوی قطع ارتباط باید از مرحله طراحی بررسی شود، مخصوصاً زمانی که داده سنسور مربوط به یک فرایند حساس است.
بسته به نوع پروژه میتوان درباره ذخیره موقت داده، بافر محلی، ارسال مجدد اطلاعات پس از برقراری ارتباط یا تعریف یک مسیر هشدار جایگزین تصمیم گرفت.
هدف این نیست که برای همه پروژهها یک راهکار یکسان ساخته شود؛ مهم این است که مشخص باشد قطع ارتباط چه اثری روی اندازهگیری، هشدار و اقدام خواهد داشت.
معیار موفقیت سیستم سنسوری چیست؟
موفقیت را نباید فقط با تعداد سنسورها یا حجم دادههای ذخیرهشده سنجید. شاخصهای عملیاتی مهمتر هستند.
زمان بین تشخیص مشکل و اقدام کاهش پیدا کند.
تعداد رخدادهای مهم از دسترفته کمتر شود.
هشدارهای غیرضروری کاهش پیدا کنند.
مسئول هر هشدار مشخص باشد.
نتیجه اقدامات مهم قابل پیگیری و ثبت باشد.
در واقع سؤال اصلی این نیست که «چند داده جمع میکنیم؟»؛ بلکه این است که «با این داده چه تصمیمی سریعتر و دقیقتر میگیریم؟»
جدول تصمیمگیری: از سنسور تا اقدام
عنصر
سؤال اصلی
خروجی مورد انتظار
متریک
چه چیزی باید اندازهگیری شود؟
داده مشخص و قابل اعتماد
آستانه
از چه زمانی وضعیت غیرعادی است؟
شرط مشخص برای هشدار
مخاطب
چه کسی باید مطلع شود؟
مسئول مشخص
کانال هشدار
چطور اطلاعرسانی شود؟
پیام، اعلان یا تیکت مناسب
اقدام
بعد از هشدار چه کاری انجام شود؟
فرایند واکنش مشخص
ثبت نتیجه
آیا اقدام انجام شد؟
سابقه قابل پیگیری
فاز ۱ عملی؛ قبل از خرید تجهیزات
برای شروع لازم نیست یک سیستم IoT کامل و پیچیده بسازید. یک پایلوت کوچک میتواند مشخص کند آیا ایده در عمل ارزش ایجاد میکند یا نه.
یک مسئله مشخص انتخاب کنید: مثلاً کاهش زمان تشخیص یک وضعیت غیرعادی.
هدف را با عدد تعریف کنید: مشخص کنید قرار است کدام شاخص بهتر شود.
وضعیت فعلی را ثبت کنید: قبل از نصب سیستم، وضعیت موجود را اندازهگیری کنید.
کوچکترین سناریوی قابل اجرا را بسازید: فقط سنسورها و هشدارهای ضروری را وارد پایلوت کنید.
مسئول واکنش را تعیین کنید: برای هر هشدار باید یک مالک مشخص وجود داشته باشد.
نتیجه را بررسی کنید: پس از یک دوره کوتاه، بررسی کنید آیا زمان واکنش، تعداد رخدادهای از دسترفته یا سایر شاخصهای هدف واقعاً بهتر شدهاند.
اشتباهات رایجی که پروژه را گران میکنند
هشدار برای همه
اگر هر هشدار برای تمام اعضای تیم ارسال شود، مسئولیت عملاً بین همه پخش میشود و احتمال بیتوجهی بالا میرود. بهتر است هر هشدار مخاطب مشخصی داشته باشد.
بدون مالک شیفت
در محیطهایی که چند نفر یا چند شیفت مسئول عملیات هستند، باید مشخص باشد در هر بازه زمانی چه کسی مسئول دریافت و پیگیری هشدار است.
آرشیو بدون مرور
ذخیره حجم زیادی از داده بدون بررسی دورهای، لزوماً ارزش ایجاد نمیکند. دادههای جمعشده باید در بازههای مشخص برای پیدا کردن الگو، خطا یا فرصت بهبود بررسی شوند.
خرید سختافزار قبل از طراحی فرایند
اگر ابتدا تجهیزات خریداری شود و بعد تازه مشخص شود قرار است با دادهها چه کاری انجام شود، احتمالاً بخشی از هزینه صرف قابلیتهایی خواهد شد که در عملیات واقعی استفاده نمیشوند.
سوالات متداول
اول سختافزار را انتخاب کنیم یا فرآیند را؟
بهتر است ابتدا مسئله، فرایند واکنش و شاخص موردنیاز مشخص شود و بعد سختافزار متناسب با آن انتخاب شود. سنسور باید در خدمت یک سناریوی عملیاتی باشد.
آیا هر داده سنسور باید وارد داشبورد شود؟
خیر. داشبورد باید روی اطلاعاتی تمرکز کند که برای تصمیمگیری یا اقدام اهمیت دارند. دادههای کماهمیت را میتوان جداگانه ذخیره یا در گزارشهای دورهای بررسی کرد.
اگر تعداد هشدارها زیاد شد چه کنیم؟
آستانهها، سطح اهمیت هشدارها و مخاطبان را بررسی کنید. ممکن است لازم باشد هشدارهای کماهمیت حذف یا تجمیع شوند تا موارد واقعاً مهم بیشتر دیده شوند.
آیا برای شروع حتماً به سیستم پیچیده IoT نیاز داریم؟
خیر. در بسیاری از پروژهها بهتر است ابتدا یک سناریوی کوچک و قابلاندازهگیری اجرا شود. اگر نتیجه مثبت بود، میتوان تعداد سنسورها، نقاط اندازهگیری و قابلیتهای سیستم را مرحلهبهمرحله افزایش داد.
اگر بعد از این راهنما به این نتیجه رسیدهاید که سنسورها میتوانند یک مسئله واقعی در کسبوکار شما را حل کنند، بهتر است قبل از انتخاب تجهیزات، سناریوی اندازهگیری، هشدار و اقدام را مشخص کنید. برای بررسی مسیر اجرا میتوانید صفحه از سنسور تا اقدام را ببینید یا از طریق مشاوره طراحی سناریو اولویتهای پروژه را با تیپرینو بررسی کنید.
جمعبندی
سنسور زمانی ارزشمند است که داده آن وارد یک فرایند مشخص شود. اندازهگیری، تشخیص انحراف، اطلاعرسانی و اقدام باید به یکدیگر متصل باشند تا سیستم هوشمند واقعاً به بهبود عملیات کمک کند.
بنابراین قبل از خرید تجهیزات، یک سؤال ساده بپرسید: اگر این سنسور فردا یک وضعیت غیرعادی را تشخیص داد، دقیقاً چه کسی باید چه کاری انجام دهد؟ اگر پاسخ این سؤال روشن باشد، طراحی سیستم از مسیر درست شروع شده است.
