وبلاگ یکتا

آیا دوره استانداردها تمام شده است؟

 

این روزها کافی است وارد یک جلسه تحول دیجیتال، طراحی ساختار سازمانی یا بازطراحی عملیات شوید. خیلی زود اسمهایی مثل هوش مصنوعی، Agent AI، اتوماسیون، DevOps ،Agile، داده و پلتفرم مطرح میشوند. در چنین فضایی APQC و ITIL، eTOM، COBIT، SCOR، Six Sigma، ITSM، VRM مثل چارچوبهایی :میآید پیش جدی سؤال یک هنوز به کار میآیند یا باید آنها را متعلق به نسل قدیمی مدیریت دانست؟
پاسخ من روشن است: دوره استانداردها تمام نشده، اما دوره کپی کردن بی کم وکاست آنها تمام شده است. سازمانهای پیشرو هنوز از فریم‌ورکها استفاده میکنند، ولی کمتر سازمانی چارت، فرایندها و شیوه کارش را مستقیمًا از روی یک کتاب یا یک نمودار استاندارد کپی میکند. امروز این مدلها بیشتر نقش جعبه‌ابزار، زبان مشترک، چکلیست طراحی، مرجع بلوغ و مبنای بنچمارک را دارند. پیش از این ممکن بود مدیری بگوید: ساختار واحد فناوری ما بر اساس ITIL طراحی شده است. امروز پاسخ بالغ‌تر این است: Model Operating اختصاصی خودمان را داریم؛ برای مدیریت سرویس از ITIL، برای حاکمیت از COBIT، برای زنجیره تأمین از SCOR، برای کاهش خطا از Sigma Six Lean و برای معماری فرایند از APQC استفاده میکنیم.« این تغییر نشانه مرگ استانداردها نیست؛ نشانه بلوغ در استفاده از آنهاست.

یک سوءتفاهم رایج: L1؛ L2 و  L3 چارت سازمانی استاندارد نیستند

در بسیاری از شرکت‌های ایرانی، مخصوصاً در مراکز تماس، واحدهای پشتیبانی، NOC، TechOps و عملیات کسب‌وکار، ساختار لایه‌ای زیر دیده می‌شود: لایه یک برای تماس اولیه و حل مسائل ساده، لایه دو برای بررسی تخصصی، لایه سه برای تصمیم‌های پیچیده یا مداخله فنی و گاهی لایه چهار برای تأمین‌کننده یا Vendor.
این ساختار میتواند کاملا کاربردی باشد، اما هیچ چارچوب معتبری نمیگوید هر سازمانی الزامًا باید سه یا چهار لایه داشته باشد. حتی در Tier ،ITILهای پشتیبانی بیشتر یک الگوی رایج هستند تا یک چارت اجباری. 4 ITIL روی Service System Value، جریان ارزش، Practices، حاکمیت، بهبود مستمر و چهار ُبعد مدیریت سرویس تمرکز دارد: سازمان و افراد، اطالعات و فناوری، شرکا و تأمین‌کنندگان، و جریانهای ارزش و فرایندها.

در eTOM، APQC و SCOR هم وقتی عبارت Level 1، Level 2 یا Level 3 می‌بینیم، معمولاً منظور «سطح تجزیه فرایند» است، نه رتبه کارشناسان. مثلاً در APQC ممکن است سطح اول «مدیریت خدمات مشتری»، سطح دوم «مدیریت درخواست‌ها»، سطح سوم «بررسی و حل مسئله» و سطح چهارم فعالیت‌های اجرایی باشد. بنابراین Process Level را نباید با Support Tier یا Organizational Layer اشتباه گرفت.

هر چارچوب دقیقا کجا به کار میآید؟

 

۱. ITSM؛ مفهوم مدیریت سرویس، نه یک استاندارد واحد

ITSM یا Information Technology Service Management یک حوزه و رویکرد مدیریتی است. حرف اصلی‌اش ساده است: فناوری نباید فقط مجموعه‌ای از سرورها، نرم‌افزارها و تیم‌های تخصصی باشد؛ باید به شکل سرویس قابل‌تعریف، قابل‌اندازه‌گیری و قابل‌بهبود مدیریت شود.

موضوعاتی مثل Incident Management، Problem Management، Service Request، Change Enablement، Service Level Management، Configuration Management، Knowledge Management و Continual Improvement در قلمرو ITSM قرار می‌گیرند. ITIL مشهورترین راهنمای اجرای ITSM است، اما ITSM و ITIL مترادف نیستند. در یک فین‌تک ایرانی، وقتی سرویس پرداخت، اعتبار، کارت، KYC یا اپلیکیشن دچار اختلال می‌شود، ITSM کمک می‌کند مشخص شود رخداد چگونه ثبت و اولویت‌بندی شود، فرمانده رخداد چه کسی باشد، چه زمانی Escalation انجام شود، چه پیامی به مشتری و مدیران برسد، RCA چگونه انجام شود و چه اقدامی جلوی تکرار را بگیرد.

۲. ITIL؛ برای مدیریت سرویس، نه طراحی کامل سازمان

ITIL برای خلق، ارائه، پشتیبانی و بهبود خدمات دیجیتال به کار می‌آید. نسخه‌های جدید آن فقط درباره Help Desk نیستند و مفاهیمی مثل Guiding Principles، Governance، Service Value Chain، Practices و Continual Improvement را کنار هم قرار می‌دهند.[1]

در بانک و فین‌تک، ITIL برای مدیریت رخدادهای پرداخت، اختلال اپلیکیشن و API، SLA و OLA، درخواست‌های کاربران، تغییرات حساس، Problem Management، RCA، مدیریت دانش و ارتباط عملیات با فناوری و محصول بسیار مفید است. اما ITIL به شما نمی‌گوید واحد وصول زیر نظر مالی باشد یا عملیات؛ KYC زیر نظر Risk باشد یا Customer Operations؛ لایه دو و سه تیکت ادغام شوند یا نه؛ یا نسبت نیروی AI به انسان چقدر باشد. این‌ها تصمیم‌های Operating Model هستند و باید بر اساس استراتژی، مقیاس، ریسک، حجم تقاضا، مهارت و فناوری گرفته شوند.

۳. ITOM؛ پایش و اداره فنی سرویس‌ها

ITOM یا IT Operations Management را نباید با eTOM اشتباه گرفت. ITOM به اداره روزمره زیرساخت، شبکه، Cloud، سرویس‌های فنی، Eventها، ظرفیت، دسترس‌پذیری، Discovery، Configuration، Observability و Automation مربوط است. برای نمونه، در یک فین‌تک ITOM باید بتواند افزایش خطای یک API، افت نرخ موفقیت تراکنش، رشد Latency، پرشدن Queue یا اشباع منابع را قبل از تبدیل‌شدن به موج تماس مشتریان تشخیص دهد. در شرکت‌های تلکامی، NOC، Fault Management، Network Monitoring و Capacity Management نمونه‌های نزدیک به ITOM هستند. تفاوت ساده این است: ITSM می‌پرسد «سرویس و نتیجه مورد انتظار ذی‌نفع را چگونه مدیریت کنیم؟» و ITOM می‌پرسد «زیرساخت و اجزای فنی این سرویس را چگونه پایدار و قابل‌مشاهده نگه داریم؟»

۴. eTOM؛ نقشه فرایندی برای تلکام و ارائه‌دهندگان سرویس دیجیتال

eTOM یا Business Process Framework توسط TM Forum توسعه یافته است. این مدل یک مرجع برای دسته‌بندی فعالیت‌های کسب‌وکار ارائه‌دهندگان سرویس است و کمک می‌کند فرایند، سیستم و معماری سرویس با یک زبان مشترک طراحی شوند.[2]

در تلکام، eTOM برای حوزه‌هایی مثل Fulfillment، Assurance، Billing، Customer Management، Service Management، Resource Management و Partner Management کاربرد دارد. دلیل ماندگاری آن هم روشن است: فعال‌سازی یک سرویس، صورتحساب، رفع Fault، شکایت مشتری و هماهنگی شرکا از چندین سامانه و واحد عبور می‌کند و بدون یک معماری مرجع، هر تیم تعریف خودش را از فرایند خواهد داشت. یک بنچمارک قابل‌اتکا، استفاده VodafoneZiggo از eTOM برای مدل‌سازی فرایندهای End-to-End Order-to-Use و دریافت گواهی انطباق TM Forum است.[3] این نمونه نشان می‌دهد eTOM هنوز در شرکت‌های بزرگ تلکامی یک ابزار زنده است، نه میراثی موزه‌ای. با این حال eTOM هم تعداد لایه‌های مرکز تماس یا جایگاه هر مدیر را تعیین نمی‌کند.

۵. COBIT؛ وقتی سؤال اصلی حاکمیت، کنترل و پاسخ‌گویی است

COBIT چارچوب حاکمیت و مدیریت اطلاعات و فناوری سازمانی است. تمرکز آن روی هم‌راستایی فناوری با اهداف کسب‌وکار، خلق ارزش، کنترل ریسک، تعریف حقوق تصمیم‌گیری و پاسخ‌گویی است.[4]

COBIT برای بانک‌ها، بیمه‌ها، شرکت‌های پرداخت، تلکام‌ها، هلدینگ‌ها و شرکت‌های بورسی اهمیت ویژه دارد. با آن می‌توان روشن کرد مالک تصمیم فناوری چه کسی است، چه کسی ریسک یک سرویس برون‌سپاری‌شده را می‌پذیرد، کنترل دسترسی چگونه طراحی می‌شود، تغییرات حساس چگونه تصویب می‌شوند و چه چیزی باید به کمیته ریسک یا هیئت‌مدیره گزارش شود. نکته مهم این است که COBIT هم ثابت نمانده است. ISACA در سال ۲۰۲۵ راهنمایی درباره استفاده از COBIT برای حاکمیت سیستم‌های AI منتشر کرد؛ یعنی حتی یک چارچوب باسابقه حاکمیتی هم در حال تطبیق با مسئله مدل، داده و ریسک هوش مصنوعی است.[5]

۶. APQC؛ برای ساختن نقشه جامع فرایند

APQC Process Classification Framework یا PCF یک طبقه‌بندی مرجع از فرایندهای کسب‌وکار است. سازمان می‌تواند با کمک آن فرایندها را نام‌گذاری، دسته‌بندی، مقایسه و بنچمارک کند. APQC این چارچوب را یکی از پرکاربردترین مدل‌های فرایندی جهان معرفی می‌کند و در سال ۲۰۲۶ نسخه ۸.۰ آن را منتشر کرده است.[6][7]

APQC برای طراحی Process Architecture بسیار مفید است، چون کمک می‌کند چیزی از قلم نیفتد: توسعه محصول، فروش، تحویل، خدمات مشتری، منابع انسانی، مالی، فناوری، ریسک، مدیریت دانش، دارایی و تأمین‌کننده. مثلاً یک گروه FMCG ایرانی که چند کارخانه، شبکه فروش مویرگی، ناوگان پخش، مرکز تماس و فروشگاه آنلاین دارد، می‌تواند با APQC نقشه جامع فرایند بسازد. بعد برای طراحی عمیق زنجیره تأمین از SCOR و برای کاهش خطا از Lean Six Sigma استفاده کند. APQC بیشتر می‌گوید «چه فرایندهایی باید دیده شوند»، نه اینکه همه آن‌ها دقیقاً چگونه اجرا شوند.

۷. SCOR؛ برای زنجیره تأمین، تولید، پخش و لجستیک

نام درست این مدل SCOR است، نه SCORE. SCOR مخفف Supply Chain Operations Reference است و توسط ASCM نگهداری می‌شود. این مدل فرایندها، شاخص‌ها، Practices و مهارت‌های زنجیره تأمین را برای ارزیابی و بهبود در کنار هم قرار می‌دهد.[8]

SCOR برای شرکت‌های تولیدی و FMCG ایرانی بسیار کاربردی است: برنامه‌ریزی تقاضا، تأمین مواد اولیه، تولید، انبار، سفارش، توزیع، تحویل، مرجوعی، مدیریت تأمین‌کننده و تاب‌آوری زنجیره تأمین. در ایران، کاربرد SCOR فقط کاهش موجودی یا هزینه حمل نیست. نوسان ارز، محدودیت واردات، تأخیر ترخیص، کمبود قطعه، اختلال انرژی و تغییر مقررات باعث می‌شوند Alternative Supplier، Buffer Policy، جایگزینی مواد، مسیرهای پخش جایگزین و سناریوهای کمبود به بخشی از طراحی اصلی عملیات تبدیل شوند، نه ضمیمه بحران.

۸. Six Sigma؛ وقتی مسئله، خطا و تغییرپذیری است

Six Sigma یک رویکرد داده‌محور برای کاهش نقص، تغییرپذیری و اتلاف است. چرخه معروف DMAIC شامل Define، Measure، Analyze، Improve و Control است و می‌تواند در برنامه Six Sigma یا به‌عنوان روش مستقل بهبود فرایند استفاده شود.[9]

این روش فقط برای کارخانه نیست. در یک فین‌تک می‌توان از آن برای کاهش خطای KYC، تماس تکراری، زمان صدور کارت، مغایرت مالی، برگشت پرونده اعتباری، Reopen شدن تیکت و نوسان کیفیت پاسخ‌گویی استفاده کرد. هرجا فرایند تکرارشونده، داده قابل‌اندازه‌گیری، خروجی مشخص و تعریف روشنی از خطا وجود دارد، Six Sigma می‌تواند مفید باشد. محدودیتش این است که به‌تنهایی مدل سازمانی، تجربه مشتری یا معماری فناوری نمی‌سازد.

۹. VRM؛ طراحی از منظر ارزش، نه واحد سازمانی

VRM یا Value Reference Model یک مدل مرجع برای پیوند دادن جریان ارزش، فرایند و قابلیت‌های سازمانی است. VRM توسط Value Chain Group توسعه یافت و فرایندها را در سطوح مختلف برای برنامه‌ریزی، حاکمیت و اجرای زنجیره ارزش توصیف می‌کند.[10]

در یک فین‌تک، «دریافت و استفاده از اعتبار» یک Value Stream است که جذب مشتری، KYC، اعتبارسنجی، ریسک، تخصیص اعتبار، پشتیبانی، وصول، شکایت، فناوری و داده را درگیر می‌کند. هیچ دپارتمان واحدی مالک کل تجربه نیست. نگاه VRM کمک می‌کند به‌جای بهینه‌سازی سیلوها، نتیجه End-to-End را ببینیم. مزیت VRM برای طراحی عملیات این است که بحث را از «این تیم زیر نظر چه کسی باشد؟» به «برای تحویل این ارزش، چه قابلیت‌هایی لازم است و ارتباطشان چیست؟» منتقل می‌کند. البته VRM نیز برای اجرا به چارچوب‌های تخصصی و طراحی اختصاصی نقش‌ها نیاز دارد

پس برندهای معروف دنیا هنوز از فریم‌ورک‌ها استفاده می‌کنند؟

بله، اما معمولاً با یک ترکیب اختصاصی. سازمان‌های بزرگ به‌جای اینکه یک فریم‌ورک را دین سازمانی کنند، چند منبع را کنار هم می‌گذارند.

گوگل در عملیات فنی بیشتر با زبان Site Reliability Engineering، SLO، Error Budget، Incident Response و Blameless Postmortem کار می‌کند. Error Budget برای ایجاد تعادل بین سرعت تغییر و قابلیت اطمینان است و اگر یک رخداد سهم بزرگی از بودجه خطا را مصرف کند، Postmortem و اقدام اصلاحی الزامی می‌شود.[11][12] این مفاهیم با ITIL رقابت صفر و یکی ندارند؛ بخشی از مسائل مشترک را با زبان و مکانیسم دیگری حل می‌کنند. AWS در Well-Architected Framework یک ستون مستقل به نام Operational Excellence دارد و آن را شامل سازمان‌دهی تیم، طراحی Workload، اداره در مقیاس و تکامل مستمر می‌داند.[13] مایکروسافت نیز در Cloud Adoption Framework تأکید می‌کند Operating Model باید مسئولیت‌ها، همکاری تیم‌ها و نحوه مدیریت منابع را با اهداف کسب‌وکار هم‌راستا کند.[14]

در تلکام، TM Forum همچنان eTOM را به‌روزرسانی می‌کند و شرکت‌هایی مانند VodafoneZiggo برای فرایندهای End-to-End از آن استفاده کرده‌اند. APQC در ۲۰۲۶ نسخه جدید PCF و ASCM نسخه دیجیتال SCOR را عرضه کرده‌اند. پس فریم‌ورک‌ها زنده‌اند؛ چیزی که تغییر کرده، جایگاه آن‌ها در معماری تصمیم‌گیری است.

چرا شرایط ایران به یک مدل عملیاتی متفاوت نیاز دارد؟

بخش مهم ماجرا از اینجا شروع می‌شود. نسخه‌ای که یک شرکت آمریکایی یا اروپایی از Operational Excellence اجرا می‌کند، الزاماً برای یک شرکت ایرانی کافی نیست. بسیاری از مدل‌های جهانی با پیش‌فرض‌هایی طراحی شده‌اند که در ایران همیشه برقرار نیستند: دسترسی پایدار به سرویس‌های ابری، امکان پرداخت بین‌المللی، تأمین‌کننده خارجی قابل‌دسترس، نرخ ارز نسبتاً قابل‌پیش‌بینی، اینترنت بین‌الملل پایدار و امکان خرید ساده ابزار و لایسنس. بانک جهانی در ارزیابی اقتصاد ایران، تحریم، محدودیت دسترسی به فناوری و بازار خارجی، کمبود انرژی و آب، نااطمینانی و کمبود سرمایه‌گذاری را از فشارهای ساختاری بر فعالیت اقتصادی ذکر می‌کند.[15] برای مدیر عملیات، این‌ها صرفاً متغیرهای اقتصاد کلان نیستند؛ هرکدام به Queue، SLA، هزینه، ظرفیت، تأمین‌کننده و تجربه مشتری تبدیل می‌شوند. بنابراین در ایران Operational Excellence فقط به معنی کار سریع‌تر و ارزان‌تر نیست. توان ادامه خدمت در شرایط محدودیت، قابلیت جایگزینی، مالکیت دانش و داده و توان بازگشت از اختلال، خود بخشی از اکسلنس عملیات هستند.

۱. وابستگی تک‌تأمین‌کننده‌ای باید یک ریسک رسمی باشد

اگر فرایند KYC، پیامک، پرداخت، اعتبارسنجی، لجستیک یا AI فقط به یک Provider وابسته باشد، اختلال آن می‌تواند کل Value Stream را متوقف کند. راه‌حل فقط قرارداد SLA نیست؛ طراحی Multi-provider، Health Check، Routing، Fallback، صف بازیابی، Manual Review کنترل‌شده و تست دوره‌ای سناریوی جایگزین لازم است.

۲. هر Cloud و API خارجی باید Exit Plan داشته باشد

سؤال‌های ضروری این‌ها هستند: داده چگونه Export می‌شود؟ دانش و Promptها کجا نگهداری می‌شوند؟ اگر Vendor یا کشور ارائه‌دهنده دسترسی را قطع کرد، جایگزین چیست؟ نسخه داخلی یا On-Premise داریم؟ مدل AI قابل‌انتقال است؟ چه مدت می‌توانیم در Degraded Mode ادامه دهیم؟

۳. BCP نباید یک فایل سالانه برای ممیزی باشد

در ایران Business Continuity باید در عملیات روزمره زندگی کند. قطع اینترنت بین‌الملل، اختلال دیتاسنتر، محدودیت برق، خرابی OTP، اختلال بانک یا PSP، بسته‌شدن مسیر حمل، نرسیدن نیروی انسانی یا جهش ناگهانی تقاضا باید Runbook، مالک، Trigger و مانور واقعی داشته باشد.

۴. نوسان ارز باید به داشبورد عملیات وصل شود

ممکن است هزینه AI، لایسنس، تجهیزات یا Cloud دلاری باشد، اما درآمد ریالی. پس مدیر عملیات باید در کنار SLA، Unit Economics را هم ببیند: هزینه هر تماس، هر تیکت، هر KYC، هر وصول موفق، هر صدور کارت، هر تحویل، هر تراکنش موفق و هر دقیقه Downtime.

۵. کمبود نیروی متخصص، دانش را به دارایی حیاتی تبدیل می‌کند

وقتی دانش سرویس در ذهن چند نفر باشد، خروج یک کارشناس می‌تواند به رخداد عملیاتی تبدیل شود. Runbook، Playbook، Process Versioning، API Documentation، Decision Log، جانشین‌پروری و Knowledge Base قابل‌استفاده برای انسان و AI باید جزو معماری اصلی عملیات باشند.

مدل پیشنهادی ANOX؛ اکسلنس عملیات AI-Native

برای کنار هم گذاشتن نقاط قوت مدل‌های کلاسیک و الزامات عملیات جدید، می‌توان از یک چارچوب پیشنهادی با عنوان AI-Native Operations Excellence Model یا ANOX استفاده کرد. ANOX یک استاندارد رسمی یا ثبت‌شده نیست؛ یک مدل تلفیقی و تجربه‌محور برای طراحی عملیات سازمان‌هایی است که انسان، AI، اتوماسیون، داده و پلتفرم را هم‌زمان به کار می‌گیرند. ANOX به‌جای شروع از چارت، از شش سؤال شروع می‌کند: چه ارزشی باید تحویل شود؟ چه جریان ارزشی (Value Stream) آن را ایجاد می‌کند؟ چه Capabilityهائی لازم است؟ کدام کار را انسان، AI یا اتوماسیون انجام دهد؟ چه داده، دانش و پلتفرمی لازم است؟ و در صورت اختلال یا محدودیت، سرویس چگونه ادامه پیدا می‌کند؟

هفت لایه ANOX

۱. Value Stream: جریان‌های اصلی ارزش مانند دریافت اعتبار، استفاده از اعتبار، صدور و تحویل کارت، حل مسئله مشتری، وصول، تحویل محصول و مدیریت اختلال تعریف می‌شوند.

۲. Capability: برای هر جریان، قابلیت‌هایی مثل Customer Interaction، Case Management، KYC Operations، Credit Operations، Collections، Fulfillment، Service Assurance، Data & Analytics و Platform Operations مشخص می‌شوند.

۳. Human Work: کارهایی که به قضاوت، مذاکره، همدلی، پذیرش ریسک، مدیریت استثنا، تصمیم اخلاقی یا مدیریت بحران نیاز دارند از کارهای روتین جدا می‌شوند.

۴. AI and Automation : هوش مصنوعی AI می‌تواند پاسخ اولیه، خلاصه‌سازی، استخراج علت تماس، پیشنهاد Next Best Action، کنترل کیفیت، اولویت‌بندی تیکت، پیش‌بینی ریزش، تشخیص تقلب و نودج وصول را انجام دهد. Automation نیز گردش کار و اجرای بدون مداخله را بر عهده می‌گیرد.

۵. Knowledge and Data: به بیان دیگر Single Source of Truth، کیفیت داده، Knowledge Base، Master Data، Process Versioning، API Catalog، Decision Log و Feedback Loop پایه تصمیم انسان و AI هستند.

۶. Platform and Governance: مجموعه CRM، Workflow Engine، Integration Platform، Monitoring، AI Platform، IAM، Auditability، کنترل ریسک و Model Governance در یک معماری منسجم قرار می‌گیرند.

۷. Resilience by Design: همچنین Multi-provider، Degraded Mode، Manual Fallback، مالکیت محلی داده، کانال ارتباطی جایگزین، برنامه خروج Vendor، ظرفیت‌سنجی حساس به ارز و Crisis Staffing از ابتدا در طراحی وارد می‌شوند.

در ANOX، L1، L2 و L3 چه می‌شوند؟

ANOX لایه‌های پشتیبانی را حذف نمی‌کند؛ آن‌ها را بر اساس نوع تقاضا و ارزش بازتعریف می‌کند. به‌جای اینکه صرفاً سه جعبه L1، L2 و L3 بکشیم، سه نوع کار را تفکیک می‌کنیم. Interaction and Fast Resolution شامل پاسخ اولیه، احراز، راهنمایی، Self-service و حل سریع است و می‌تواند ترکیبی از AI و انسان باشد. Investigation and Case Resolution شامل بررسی پرونده، اتصال داده‌ها، رفع مغایرت و هماهنگی بین تیم‌هاست. Expert Decision and Exception Management شامل تصمیم‌های پیچیده، استثنا، Risk Acceptance، RCA، Policy و مداخله محصول یا فناوری است. در یک درخواست ساده، AI ممکن است کل مسیر را حل کند و هیچ Escalationی رخ ندهد. در یک شکایت حساس یا رخداد بحرانی، چند نقش تخصصی ممکن است هم‌زمان وارد شوند. بنابراین سؤال درست این نیست که «چند لایه داشته باشیم؟» سؤال درست این است: «برای هر نوع تقاضا، کوتاه‌ترین، کم‌هزینه‌ترین و کم‌ریسک‌ترین مسیر رسیدن به نتیجه چیست؟»

نسخه عملیاتی برای صنایع ایران

• تلکام: برای اپراتور تلکام، eTOM می‌تواند معماری فرایند، ITOM مدل مانیتورینگ و اداره شبکه، ITIL مدل مدیریت سرویس و رخداد، COBIT حاکمیت و ANOX تقسیم کار انسان، AI، Automation و تاب‌آوری را پوشش دهد. مثلاً در اختلال یک سرویس دیتا، Event فنی باید به Incident کسب‌وکاری، تخمین مشتریان متاثر، پیام‌رسانی، جبران خدمت و RCA متصل شود.
• فین‌تک و بانک: در بانک و فین‌تک، ITIL برای Incident، Problem، Change و SLA؛ COBIT برای ریسک، کنترل و پاسخ‌گویی؛ APQC برای نقشه جامع فرایند؛ Six Sigma برای کاهش خطا و زمان؛ VRM برای طراحی Value Stream؛ و ANOX برای نقش AI، دانش، پلتفرم و تاب‌آوری قابل‌ترکیب هستند.
• نمونه عملی: در فرایند صدور کارت، نباید فقط زمان پاسخ مرکز تماس یا تعداد تیکت را بسنجیم. KPIهای End-to-End باید از ثبت درخواست تا احراز، صدور، شخصی‌سازی، تحویل، فعال‌سازی و اولین استفاده را پوشش دهند. اگر ۹۰ درصد تیکت‌ها سریع بسته شوند ولی کارت به مشتری نرسد، عملیات موفق نیست. تولید و FMCG: برای شرکت تولیدی یا FMCG، SCOR ستون اصلی زنجیره تأمین، Lean و Six Sigma ابزار بهره‌وری و کیفیت، APQC نقشه کلان فرایندها، ITIL و ITOM مدیریت سرویس‌های دیجیتال و فناوری کارخانه و ANOX لایه تصمیم، پیش‌بینی، اتوماسیون و تاب‌آوری است.

مثلاً وقتی یک ماده اولیه وارداتی کمیاب می‌شود، مسئله فقط Procurement نیست. باید اثر آن روی برنامه تولید، کیفیت جایگزین، موجودی، قیمت، توزیع، کمپین فروش، تعهد مشتری و سرمایه در گردش در یک Control Tower دیده شود.

از کجا شروع کنیم؟ یک نقشه اجرایی شش‌مرحله‌ای

• گام ۱: پنج Value Stream اصلی را مشخص کنید

نه پنج دپارتمان؛ پنج نتیجه‌ای که مشتری یا کسب‌وکار از شما انتظار دارد. مرز ابتدا و انتهای هر جریان، مشتری، خروجی و مالک نتیجه را مشخص کنید.

• گام ۲: Capability Map بسازید

برای هر Value Stream، توانمندی‌های لازم، مالک، سطح بلوغ، شکاف مهارتی و وابستگی سامانه‌ای را مشخص کنید.

• گام ۳: تقاضا را Segmentation کنید

درخواست‌ها را به ساده و پرتکرار، نیازمند بررسی، نیازمند تصمیم تخصصی، بحرانی، استثنایی و قابل‌اتوماسیون تقسیم کنید.

• گام ۴: مدل همکاری انسان و AI را تعیین کنید

برای هر فعالیت یکی از حالت‌های Human Only، AI Assisted، AI Executed/Human Supervised، Fully Automated یا Manual Fallback را انتخاب کنید.

• گام ۵: KPI را End-to-End کنید

Time to Resolution، Repeat Contact، Transfer Rate، Reopen Rate، Cost per Successful Outcome، Straight-Through Processing، AI Error Rate، MTTR و Fallback Success Rate را بسنجید.

• گام ۶: تاب‌آوری را تست کنید

سناریوی قطع Provider، Cloud، بانک، اینترنت، برق و کمبود نیروی انسانی را مانور دهید و نتیجه را به Backlog بهبود تبدیل کنید.

پنج اشتباه رایج در شرکت‌های ایرانی

اشتباه اول این است که ITIL را مساوی L1، L2 و L3 بدانیم. اشتباه دوم این است که استاندارد را جایگزین استراتژی و Operating Model کنیم. اشتباه سوم این است که AI را فقط Voicebot یا Chatbot ببینیم. اشتباه چهارم این است که مستندسازی را با Knowledge Management یکی بدانیم. اشتباه پنجم این است که موفقیت هر واحد را جداگانه بسنجیم و نتیجه End-to-End مشتری را فراموش کنیم.

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

جمع‌بندی

نه ITIL مرده است، نه eTOM، نه COBIT، نه SCOR، نه APQC و نه Six Sigma. چیزی که باید کنار گذاشته شود، نگاه تک‌چارچوبی و نسخه‌برداری مکانیکی از آن‌هاست. ITIL برای مدیریت سرویس عالی است، ولی چارت کامل عملیات را طراحی نمی‌کند. eTOM برای معماری فرایند تلکام قدرتمند است، ولی مدل نیروی انسانی و AI را نمی‌سازد. COBIT حاکمیت و کنترل می‌دهد، نه تجربه مشتری. SCOR زنجیره تأمین را بهبود می‌دهد، ولی پاسخ کامل عملیات فین‌تک نیست. APQC نقشه جامع می‌دهد، اما روش اجرای همه فرایندها را مشخص نمی‌کند. Six Sigma خطا و نوسان را کاهش می‌دهد، اما Operating Model نمی‌سازد. VRM نگاه ارزش‌محور می‌دهد، ولی به مدل‌های اجرایی مکمل نیاز دارد.

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

به زبان ساده، سازمان برنده الزاماً سازمانی نیست که بهترین استاندارد را انتخاب کرده باشد؛ سازمانی است که از استانداردها یاد بگیرد، مدل خودش را بسازد، آن را با داده اداره کند و دائماً با واقعیت جدید تطبیق دهد.

اگر در انتخاب، ترکیب یا پیاده‌سازی چارچوب‌هایی مانند ITIL، COBIT، eTOM، SCOR یا APQC برای سازمان خود با چالش روبه‌رو هستید، یک تصمیم درست می‌تواند مسیر تحول کسب‌وکار شما را متحول کند. برای دریافت مشاوره تخصصی و طراحی یک مدل عملیاتی متناسب با نیازهای سازمان، با سعید رستم‌اف در ارتباط باشید.