دورانی که صنعت IoT هرگز فراموش نمیکند
اگر در دوران کرونا در صنعت الکترونیک یا IoT فعالیت کرده باشید، احتمالاً هنوز آن روزها را به خاطر دارید.
روزی که تأمینکنندهای که همیشه ظرف دو هفته قطعه تحویل میداد، ناگهان زمان تحویل را به شش ماه افزایش داد.
بعد نه ماه.
بعد یک سال.
برخی از شرکتها حتی حاضر بودند پول کامل سفارش را دریافت کنند، اما تضمینی برای زمان تحویل ندهند.
در آن دوران اتفاق عجیبی افتاد.
محصولاتی که از نظر فنی عالی بودند، از بازار حذف شدند.
نه به خاطر مشکل نرمافزار.
نه به خاطر مشکل سختافزار.
نه به خاطر رقبا.
بلکه به خاطر اینکه یک قطعه کوچک چند دلاری دیگر در دسترس نبود.
برای بسیاری از شرکتها، کرونا یک بحران بهداشتی نبود.
یک بحران زنجیره تأمین بود.
و این بحران یک درس مهم به همه ما داد:
محصولی که فقط روی کاغذ قابل تولید باشد، هنوز یک محصول موفق نیست.
بزرگترین ریسک پنهان در بسیاری از پروژههای IoT
وقتی مهندسان درباره ریسک پروژه صحبت میکنند، معمولاً به این موارد فکر میکنند:
- باگ نرمافزار
- خرابی سختافزار
- امنیت
- کیفیت ارتباطات
اما یکی از بزرگترین ریسکهای واقعی معمولاً در هیچ نمودار فنی دیده نمیشود:
وابستگی بیش از حد به یک تأمینکننده.
کافی است فقط یکی از این اتفاقها رخ دهد:
- قطعه End Of Life شود.
- کارخانه تولیدکننده تعطیل شود.
- تحریم جدیدی اعمال شود.
- بحران حملونقل ایجاد شود.
- تقاضای جهانی ناگهان افزایش یابد.
در این لحظه ممکن است کل محصول شما متوقف شود.
اشتباهی که سالها بعد هزینه آن را میپردازید
بسیاری از تیمها هنگام طراحی فقط به سه سؤال فکر میکنند:
- آیا قطعه کار میکند؟
- آیا قیمت مناسبی دارد؟
- آیا مشخصات فنی خوبی دارد؟
اما سؤال چهارم معمولاً فراموش میشود:
اگر فردا این قطعه نایاب شد، چه اتفاقی برای محصول ما میافتد؟
این سؤال شاید امروز بیاهمیت به نظر برسد.
اما ممکن است چند سال بعد سرنوشت کسبوکار شما را تعیین کند.
طراحی برای روز بحران
یکی از مهمترین درسهایی که در پروژههای صنعتی یاد گرفتهام این است:
محصول را فقط برای شرایط عادی طراحی نکنید.
برای روز بحران طراحی کنید.
مثال واقعی: انتخاب ماژول ارتباطی
فرض کنید برای محصول خود از یک ماژول سلولار استفاده میکنید.
بسیاری از شرکتها فقط به قیمت یا مشخصات فنی نگاه میکنند.
اما رویکرد حرفهایتر این است که از ابتدا به جایگزینها فکر کنید.
برای مثال در بسیاری از پروژهها، ماژولهای Quectel گزینه محبوبی هستند.
اما در برخی خانوادهها، شرکت MeigSmart نیز نسخههای Pin-to-Pin Compatible ارائه میکند.
این یعنی اگر روزی تأمین یکی از آنها با مشکل مواجه شود، مسیر مهاجرت شما بسیار سادهتر خواهد بود.
این موضوع شاید در روز اول طراحی اهمیت زیادی نداشته باشد.
اما در زمان بحران میتواند تفاوت بین ادامه تولید و توقف کامل خط تولید باشد.
این موضوع فقط درباره ماژولها نیست
همین منطق باید برای تمام اجزای سیستم اعمال شود:
- میکروکنترلر
- حافظه
- سنسورها
- رگولاتورها
- کانکتورها
- آنتنها
- قطعات مکانیکی
هرچه تعداد تأمینکنندگان بالقوه یک قطعه بیشتر باشد، ریسک شما کمتر خواهد بود.
قانون طلایی طراحی سختافزار
تا حد امکان از قطعاتی استفاده کنید که:
✅ توسط چند تولیدکننده عرضه میشوند.
✅ در بازار جهانی رایج هستند.
✅ حجم تولید بالایی دارند.
✅ احتمال حذف شدن آنها پایین است.
گاهی بهترین قطعه از نظر فنی، بهترین انتخاب تجاری نیست.
فقط سختافزار نیست؛ نرمافزار هم باید منعطف باشد
یکی دیگر از اشتباهات رایج این است که Firmware و Software کاملاً به یک Vendor وابسته میشوند.
در چنین شرایطی تغییر یک قطعه ممکن است به بازنویسی بخش بزرگی از سیستم منجر شود.
معماری خوب باید به شما اجازه دهد:
- ماژولها را تغییر دهید.
- تأمینکنندگان را تغییر دهید.
- فناوری ارتباطی را تغییر دهید.
بدون اینکه کل سیستم از ابتدا طراحی شود.
موجودی انبار؛ هزینه یا بیمه؟
بسیاری از شرکتها تلاش میکنند موجودی انبار را به حداقل برسانند.
اما در صنعت IoT این تصمیم همیشه درست نیست.
وقتی فروش محصول تثبیت شد، نگهداری موجودی استراتژیک میتواند نقش یک بیمه را بازی کند.
البته این تعادل مهم است.
نه آنقدر زیاد که سرمایه شما قفل شود.
و نه آنقدر کم که با اولین بحران، تولید متوقف شود.
نقطه سربهسر فناوری را فراموش نکنید
گاهی شرکتها برای کاهش هزینه، تعداد بسیار زیادی از یک قطعه را خریداری میکنند.
اما یک خطر دیگر وجود دارد:
تکنولوژی متوقف نمیشود.
ممکن است قبل از مصرف موجودی شما:
- نسل جدیدی از فناوری وارد بازار شود.
- اپراتورها استانداردهای قدیمی را کنار بگذارند.
- مشتریان انتظار قابلیتهای جدید داشته باشند.
بنابراین مدیریت موجودی باید با سرعت تغییر فناوری متعادل باشد.
از مقاومت تا پادشکنندگی
بیشتر شرکتها تلاش میکنند در برابر بحران مقاوم باشند.
اما هدف نهایی باید چیزی فراتر از مقاومت باشد.
مفهومی که نسیم طالب آن را «پادشکنندگی» (Antifragility) مینامد.
سیستم پادشکننده فقط در بحران زنده نمیماند.
بلکه از بحران قویتر میشود.
در دنیای IoT، پادشکنندگی یعنی:
- چند مسیر تأمین داشته باشید.
- قطعات جایگزین از قبل شناسایی شده باشند.
- معماری نرمافزار منعطف باشد.
- وابستگی به یک Vendor حداقل باشد.
- موجودی استراتژیک داشته باشید.
در این حالت بحران شما را غافلگیر نمیکند.
یکی از فلسفههای IoTMastery
یکی از اهداف اصلی IoTMastery فقط آموزش فناوری نیست.
هدف این است که تجربههایی را منتقل کنیم که معمولاً شرکتها بعد از صرف زمان و هزینه زیاد یاد میگیرند.
بسیاری از اشتباهات طراحی، سالها بعد و در زمان بحران خود را نشان میدهند.
اگر بتوانیم از همان روز اول طراحی:
- انعطافپذیری را در نظر بگیریم،
- ریسک تأمین را مدیریت کنیم،
- و سیستم را برای شرایط واقعی بازار طراحی کنیم،
میتوانیم هزینههای مالی، زمانی و عملیاتی بسیار کمتری در آینده پرداخت کنیم.
جمعبندی
بیشتر مهندسان محصول را برای روزهای عادی طراحی میکنند.
اما شرکتهای موفق محصول را برای روز بحران طراحی میکنند.
در IoT فقط یک سختافزار یا نرمافزار نمیسازید.
شما در حال طراحی یک اکوسیستم کامل از تأمینکنندگان، قطعات، نرمافزار، تولید و پشتیبانی هستید.
و گاهی تفاوت بین موفقیت و شکست، نه در یک فناوری پیچیده، بلکه در یک تصمیم ساده هنگام انتخاب یک قطعه کوچک نهفته است.