کاربرد ریسمان آندون در مدیریت خدمات فناوری اطلاعات

آندون در مدیریت فناوری اطلاعات

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

مثلاً شرکت تویوتا از این مفهوم در کلیه‌ی ایستگاه‌های خط تولید خود استفاده کرد این یعنی در دسترس هر کارگری یک فانوس آندون هست که هرکسی می‌تواند ریسمان آندون Andon Cord را بکشد (یا دکمه‌ای را فشار دهد) و خط تولید را متوقف کند اینکار برای نشان‌دادن این است مشکلی حادث شده و یک سری اقدامات درمانی و اصلاحی باید صورت گیرد و این امکان را می‌دهد تا پیش از شروع مجدد تولید، مشکل حل شود. با آندون، اگر چیزی نادرست باشد، نیازی به کسب تکلیف و یا دریافت فرمان سلسه‌مراتبی نیست و هر کارگر در خط تولید، با هر تجربه و سطح دستمزدی که داشته باشد، حق دارد ریسمان را بکشد. ریسمان آندون به عنوان یکی از عناصر روش کیفیت Jidoka توسعه یافته و با کمک آن تویوتا و سیستم تولید تویوتا، به کارگران این امکان را می‌دهد تا به همکاران و مدیریت مشکلات کیفیت و فرآیند در سراسر مونتاژ اطلاع دهند و حتی تولید را متوقف کنند.

شبیه کشیدن ترمز یک قطار مترو با اینکه راننده قطار کسی دیگر است و اختیار هدایت قطار را دارد اما هر مسافری در شرایط خاص قادر است این ترمز را بکشد.

آندون نشان‌دهنده‌ی درجه‌ای از استقلال فردی در یک سیستم است برای جلوگیری از پیامدهای ناخوشایندتر! این مفهوم امروزه از کنوانسیون‌های صنعتی فراتر رفته. این استقلال یکی از بلوک‌های ساختاری فرهنگی تولید ناب است. در دنیای فناوری اطلاعات نیز افرادی که به‌دنبال درک چارچوب‌های ITIL،   Lean IT و یا DevOps باشند، مهم است که این موضوع را بشناسد.

همچنان که آندون یکی از نمادهای صنعتی در تولید ناب است، جلسه‌ی هیئت مشاورین تغییر ITIL (CAB) برای بسیاری از افراد در DevOps نیز نمادی قدرتمند برای ITSM است.

هدف اصلی تیم‌های DevOps ایجاد تعداد بالای نسخه‌های تولیدی قابل اعتماد که همواره روندی افزایشی در پی دارد و جلسه CAB اغلب به عنوان پادزهر این امر تلقی می‌شود، که بسیار مناسب هم هست و جلوی تولید و تغییرات ناخواسته را می‌گیرد اما گاهاً فرایند بررسی و تصویب تغییر در تولید یک روند دشوار و زمانبری ایجاد می‌کند و ممکن است کسب اجازه‌ی تغییر پس از صرف‌کردن زمان زیاد در جلسات، حدود یک یا دو هفته زمان نیاز داشته باشد. همین موضوع سبب ناراحتی تولیدکنندگان DevOps‌ می‌شود، که از نظر آنها فرایند تایید در کمیته CAB تا حدی ناعادلانه است. دلایل آنها نیز گاها درست است. خوشبختانه، ITSM در طی سالیان متمادی تفکر خود را متحول کرده و تلاش زیادی برای تطبیق نیازهای DevOps با ITIL انجام داده. به عنوان مثال: داشتن بررسی CAB برای هر درخواست تغییر، کارآمد نیست و قطعاً منطقی هم نیست. دعوای DevOps و ITIL را از لینک زیر بخوانید.

با این وجود، داشتن درخواست بررسی CAB در مورد ریسک ناشناخته، هنگامی که افراد و ذینفعان بیشتری ممکن است تحت تأثیر این تغییر قرار بگیرند، اهمیت و ضرورت پیدا می‌کند این یعنی بسته به ریسک تغییر، مفهوم کاربردی آن بیشتر به‌چشم می‌آید.

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

بیاید کمی بازترش کنیم. مفهوم Andon Cord شامل استفاده از سیگنال‌ها و هشدارها برای نشان‌دادن این است که یک ایستگاه در خط مونتاژ، مشکل دارد. هشدارها توسط کارگران با کشیدن ریسمان آندون یا به طور خودکار توسط خود تجهیزات فعال می‌شوند.

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

بسیاری استدلال می‌کنند که استفاده از مفاهیم مدیریت ناب مانند ریسمان آندون در فناوری اطلاعات و مهندسی نرم‌افزار چالش برانگیزتر است. بخصوص در تولید نرم‌افزار و فرایند مدیریت نشر در ITIL.

معمولاً تنها فرصتی که برای آزمایش و بررسی وجود نقص در نرم‌افزار هست پس از تولید نرم‌افزار است که در اواخر چرخه‌ی تولید و توسعه رخ می‌دهد. که صد البته این خیلی دیر است زیرا در واقع، این مشتریان خواهند بود که با ثبت اعلام خرابی، اکثر آزمایشات را انجام می‌دهند.

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

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

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

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