استانداردسازی اجزای تکرارپذیر و حفظ شرایط محلی

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

رتروفیت مقیاس‌پذیر از روز پایلوت باید بداند کدام جزء قرار است محصول شود و کدام جزء باید هر بار محلی بماند. اگر این تفکیک بعد از جشن پایلوت شروع شود، معمولاً دیر است؛ چون پایلوت طوری بسته شده که فقط همان تیم می‌تواند آن را زنده نگه دارد.

چرا کپی پایلوت کار نمی‌کند

پایلوت روی یک پمپ، یک کوره یا یک شبکه بخار، نگاشت تگ دستی دارد. نام‌ها یکدست نیستند. حسگرها هم‌خانواده نیستند. بار و خوراک فرق می‌کند. قطعه یدکی و افزونگی فرق می‌کند. دانش شیفت فرق می‌کند. حتی تعریف خرابی در CMMS یکی نیست.

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

از سوی دیگر، اگر سازمان به بهانه تفاوت سایت‌ها هیچ‌چیز را استاندارد نکند، هر واحد یک پروژه تازه می‌شود. آن هم مقیاس نیست؛ تکرار هزینه است. راه میانی سند همین است: جزء تکرارپذیر را محصول کن، جزء محلی را آگاهانه محلی نگه دار.

چه چیزی استانداردشدنی است

مواردی که سند قابلیت استانداردسازی بیشتری برایشان قائل است:

• خط لوله دا‌ده و قواعد کیفیت؛
• الگوی استقرار و پایش؛
• رابط کاربری و زبان هشدار؛
• روش اعتبارسنجی و قالب آزمون؛
• قالب مدل و محدوده اعتبار؛
• مدل اطلاعاتی دارایی و نام‌گذاری زمینه؛
• مسیر نسخه، بازگشت و جدایی محیط‌ها؛
• تفکیک جریان دا‌ده از جریان تصمیم.

این‌ها را اگر هر سایت از نو اختراع کند، هلدینگ هیچ‌وقت یاد نمی‌گیرد. این‌ها را اگر محصول شوند، سایت بعدی از شناخت مسئله شروع می‌کند نه از اختراع سکو.

استانداردسازی به معنی قفل شدن روی یک فروشنده نیست. معنی‌اش قرارداد مرز و رفتار است: تگ چگونه به دارایی بند می‌شود، برآورد چگونه از اندازه جدا می‌ماند، قطع ورودی چگونه اعلام می‌شود.

چه چیزی باید محلی بماند

خط مبنا، حدود عملیاتی، زمینه فرایند، ترتیب مجاز تغییر رژیم، و حتی پارامتر مدل ممکن است محلی باشند. اهمیت تجهیز محلی است. پنجره توقف محلی است. کیفیت حسگر موجود محلی است. قیود نانوشته شیفت محلی است.

کپی کردن آستانه ارتعاش سایت اول روی سایت دوم، یا کپی کردن نقطه تنظیم بهینه کوره، دقیقاً همان نادیده‌گرفتن As-operated است. اعتبارسنجی محلی برای همین است: روش یکی است، نتیجه باید روی دا‌ده و قید همین دارایی دوباره ثابت شود.

محلی ماندن نباید بهانه بی‌انضباطی باشد. باید مکتوب شود که کدام پارامتر محلی است، چه کسی آن را عوض می‌کند و بعد از اورهال چگونه بازبینی می‌شود. در غیر این صورت «محلی» نام دیگر وابستگی به فرد است.

چهار گام: Prove، Standardize، Productize و Scale

Prove

پایلوت باید قابلیت را در محیط واقعی ثابت کند نه توان فناوری را در دمو.

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

Standardize

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

Productize

جزء استاندارد باید صاحب، نسخه، نصب، پایش و پشتیبانی پیدا کند. تا وقتی استقرار به تیم پروژه وابسته است، محصول نیست. محصول یعنی سایت دوم بتواند با تیم محلی و خدمات مشترک، همان روش را اجرا کند.

Scale

گسترش با اعتبارسنجی محلی. انتخاب دارایی بعدی بر اساس شباهت مسئله و آمادگی سرمایه موجود است نه بر اساس فشار سهمیه‌ای «صد تجهیز تا پایان سال.

ضمناً پریدن از Prove به Scale همان مسیر شکست کلاسیک است. میان‌بر Productize بدون Standardize هم فقط بسته‌بندی همان استثنای پایلوت است.

مقیاس در هلدینگ

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

خدمات مشترک مقیاس را ارزان می‌کنند: رجیستری، آموزش کنترل‌شده، الگوی امنیتی، زبان KPI. اجرای قابلیت همچنان به آمادگی سایت بند است. سایتی که CMMS علت خرابی ندارد یا Historian کیفیت ندارد، با دریافت مدل مرجع بالغ نمی‌شود؛ فقط گزارش ناهماهنگی‌اش زیباتر می‌شود.

از Pilot به Scale همچنین یعنی نپذیرفتن موفقیت‌های غیرقابل انتقال به‌عنوان استراتژی. هیئت‌مدیره باید بپرسد: اگر تیم پایلوت نباشد، سایت دوم در نود روز به قابلیت می‌رسد یا به همان افراد نیاز دارد؟ پاسخ دوم یعنی هنوز در Prove مانده‌اید.

معیارهای خروج از هر گام

از Prove بیرون نر‌وید مگر منبع دا‌‌ده پاید‌ار باشد، منفعت در عملیات دید‌‌ه شد‌ه با‌شد و سطح اختیار مکتوب با‌شد.

Standardize بیرون نروید مگر فهرست جزء محصول و جزء محلی امضا شد‌ه باشد.

از Productize بیرون نروید مگر استقرار توسط تیمی غیر از تیم اولیه روی یک دارایی دوم انجام شد‌ه باشد.

و‌ارد Scale گسترد‌ه نشو‌ید مگر اعتبار‌سنجی محلی شکست‌خورد‌ه هم تجربه شده باشد. توانایی نه گفتن به دارایی نامناسب، نشا‌نه بلوغ مقیاس ا‌‌ست.

نقش VCها در این مسیر

هر VC اگر فقط پایلوت را موفق کند و برود، همان شکست را بازتولید می‌کند. نقش درست این است که از ابتدا جزء تکرارپذیر را طراحی کند، شرکا را روی قالب نه روی استثنا متعهد کند، و مقیاس را به Validation محلی گره بزند.

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

جمع‌بندی

پایلوت موفق آغاز کار است اگر از آن روش ساخته شود؛ و اگر از آن بت ساخته شود، پایان کار و همان شکست است. مقیاس کپی مدل نیست. مقیاس تکرار معماری و روش است با احترام به پارادایم، رژیم، دا‌ده و اختیار هر سایت. سازمانی که این را بپذیرد، کندتر شروع می‌کند و سریع‌تر گسترش می‌دهد. سازمانی که نپذیرد، هر سال پایلوت تازه‌ای برای همان مسئله برگزار می‌کند.