کار با یکپارچه‌کننده‌های محلی در پروژه‌های قفل هوشمند: یک مدل همکاری واضح

در YS LOCKER، می‌بینیم که مکالمات سخت‌افزاری سریع‌تر حرکت می‌کنند، زمانی که سؤال عملیاتی از قبل واضح باشد. یک خریدار خارج از کشور چه زمانی باید تعریف کند که یکپارچه ساز محلی یک پروژه قفل هوشمند را متصل، نصب یا راه اندازی کند؟ هدف این نیست که در مورد یک کابینت، بسته نرم افزاری یا روش نصب، یک وعده جهانی بدهیم. این است که به خریداران B2B خارج از کشور روشی منظم برای تعریف پروژه قبل از مقایسه قیمت‌ها داده شود.

قفسه بسته بخشی از یک گردش کار عملیاتی است. گردش کار شامل اپراتور، تیم تحویل، تیم سایت، گیرنده و گاهی اوقات یک نرم افزار جداگانه یا شریک یکپارچه سازی است. وقتی آن نقش ها تعریف نشده باشند، یک پروژه می تواند طرح کابینت داشته باشد اما توافق قابل اعتمادی در مورد واگذاری، استثناها، جریان اطلاعات یا پذیرش ندارد. توصیه می کنیم گردش کار مورد انتظار را به زبان ساده ضبط کنید و آن را به عنوان ورودی طراحی در نظر بگیرید.

برای نقش های تامین کننده و یکپارچه، تحویل کابینه، کار سایت محلی، مالکیت نرم افزار، تبادل پروتکل، آزمایش، تشدید و کنترل تغییر، مهمترین سند نقشه مسئولیت است. این باید محدوده شریک محلی، مسئولیت نصب، مالک پلت فرم، اسناد رابط، شرایط سایت، طرح آزمایش، انتظارات آموزشی، و مخاطبین تشدید را تعیین کند. این امر مانع از این می‌شود که تأمین‌کننده کابینت، مالک پلتفرم، حامل، ادغام‌کننده و اپراتور سایت هر یک از طرف‌های دیگر مالک عملکرد مشابهی باشند.

بسیاری از اپراتورهای بسته‌بندی{0}}در حال حاضر از نرم‌افزار عامل خود یا پلتفرم شخص ثالث-استفاده می‌کنند. در آن پروژه‌ها، YS LOCKER می‌تواند یک API یا پروتکل برد کنترل قفل-برای یکپارچه‌سازی پروژه ارائه کند. نرم افزار پایانه، نام تجاری، گردش کار تحویل و پیکاپ، رابط های سرور و عملکردهای مدیریتی نیز می توانند با توجه به محدوده پروژه تایید شده مورد بحث قرار گیرند. ما عملکردهای شخص ثالث یا محدوده نرم افزاری سفارشی را به عنوان ویژگی پیش فرض هر قفسه ارائه نمی کنیم.

با سوالی شروع کنید که به ریسک واقعی خریدار نزدیکتر است. برای این موضوع، نقش های تامین کننده و یکپارچه کننده، تحویل کابینه، کار سایت محلی، مالکیت نرم افزار، تبادل پروتکل، آزمایش، تشدید و کنترل تغییر است. یک جدول کوتاه بسازید که شرایط فعلی، مالکی که می تواند آن را تأیید کند، شواهد موجود و تصمیمی که هنوز مورد نیاز است را فهرست می کند. این یک درخواست واضح تر برای نقل قول و یک بررسی فنی مفیدتر ایجاد می کند.

میز نباید در کابینت متوقف شود. باید طرح‌بندی فیزیکی، ترتیب تحویل و جمع‌آوری، دستگاه‌های پایانه در صورت نیاز، شرایط شبکه و برق، نرم‌افزار عملیاتی و نقش تیم سایت پس از راه‌اندازی را پوشش دهد. در جایی که یک تابع به پلتفرم مشتری یا پلتفرم شخص ثالث- تعلق دارد، آن را به وضوح شناسایی کنید. در جایی که یک پروژه{4}} درخواست سفارشی سازی خاص است، آن را به عنوان یک درخواست به جای یک ادعای استاندارد شناسایی کنید.

قبل از نهایی شدن یک پیشنهاد تجاری، خریداران باید بتوانند به این سوالات پاسخ دهند:

گردش کار واقعی کاربر و اپراتور در این سایت چیست؟

کدام طرح کابینت، ترکیب درب، دستگاه های ترمینال و شرایط سایت برای آن گردش کار مورد نیاز است؟

نرم‌افزار، داده‌ها، اعلان‌ها، قوانین دسترسی و رسیدگی به استثناها متعلق به کدام طرف است؟

چه نقشه‌ها، فایل‌های پروتکل، آثار هنری یا اسناد سایت برای بررسی در دسترس هستند؟

کدام موارد هنوز نیاز به تأیید مشتری، مالک سایت یا تیم پروژه محلی دارند؟

این رویکرد به ویژه برای پروژه‌های چندحزبی مهم است. کابینه یکسان می‌تواند بخشی از گردش کار مسکونی، خرده‌فروشی، پردیس، تجاری-املاک یا شرکت حمل‌ونقل{3}} باشد، اما مدل مسئولیت یکسان نخواهد بود. یک مختصر واضح، دامنه تجهیزات را با عملیاتی که از آن استفاده خواهد کرد، همراستا نگه می دارد.

ما سخت‌افزار قفسه هوشمند ارائه می‌کنیم و می‌توانیم پیکربندی کابینت خاص پروژه{0}}را برای برنامه‌های قفسه بسته بررسی کنیم. بر اساس الزامات تایید شده پروژه، می‌توانیم طرح‌بندی کابینت و درب، ساختار اصلی-و-، رنگ‌ها و گرافیک سطح، سخت‌افزار الکترونیکی مربوط، زمینه نصب، و مرزهای یکپارچه‌سازی نرم‌افزار یا سیستم- را مورد بحث قرار دهیم.

در جایی که یک اپراتور نرم افزار خود را دارد یا با پلتفرم دیگری کار می کند، می توانیم قفل{0}}API یا پروتکل مورد نیاز پروژه را بررسی کنیم. در جایی که نرم افزار ترمینال، مدیریت ابر، اطلاعات وضعیت، گزارش، روش های دسترسی یا سایر عملکردها درخواست می شود، دامنه واقعی آنها باید در راه حل فنی تعریف شود. این تمایز به خریداران کمک می کند تا از تلقی یک گزینه پیشنهادی به عنوان یک ویژگی محصول جهانی اجتناب کنند.