OLA چیست؟ توافق سطح عملیاتی بین تیم‌های داخلی

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

در این مقاله می‌بینید OLA چیست، چه تفاوتی با SLA دارد، چطور آن را بین تیم‌های داخلی بنویسیم و چگونه مطمئن شویم در عمل رعایت می‌شود.

OLA چیست؟ (پاسخ سریع)

OLA یا «توافق سطح عملیاتی»، توافقی داخلی میان دو یا چند تیم در یک سازمان است که مشخص می‌کند هر تیم برای پشتیبانی از یک خدمت، چه چیزی، در چه بازهٔ زمانی و با چه کیفیتی به تیم دیگر تحویل می‌دهد. OLA به‌جای رابطهٔ فروشنده-مشتری، رابطهٔ همکار-همکار را تنظیم می‌کند تا فعالیت‌های پراکندهٔ چند تیم در نهایت به یک تعهد قابل تحقق برای مشتری تبدیل شوند.

چرا OLA بدون SLA بیرونی هم می‌تواند مفید باشد؟

خیلی‌ها تصور می‌کنند OLA فقط زمانی لازم است که SLA بیرونی وجود داشته باشد. اما OLA مستقل از مشتری بیرونی هم ارزش دارد:

• کاهش کار تکراری: وقتی مرز تحویل روشن است، دو تیم یک کار را دو بار انجام نمی‌دهند.
• رفع «کار زمین‌مانده»: معلوم می‌شود مسئول گام بعدی چه کسی است.
• شفافیت انتظار داخلی: همکاران می‌دانند پاسخ‌گویی به یکدیگر هم قاعده دارد.
• بهبود تجربهٔ مشتری نهایی: چون تأخیرهای داخلی کاهش می‌یابد.

پس OLA یک ابزار «آرام‌سازی درون سازمان» است، حتی اگر هیچ قرارداد بیرونی در میان نباشد.

تفاوت OLA و SLA چیست؟

این دو مکمل هم‌اند، اما در چند بُعد کلیدی متفاوت‌اند:

نکته مهم: هر تعهدی که در SLA بیرونی وجود دارد، باید در پشت صحنه به یک یا چند OLA شکسته شود؛ در غیر این صورت SLA روی پایهٔ نامطمئن بنا شده است.

آیا OLA همان SLA داخلی است؟

نه دقیقاً، هرچند در برخی سازمان‌ها این دو را یکی می‌گیرند. اگر یک واحد داخلی برای واحد دیگر در حکم «مشتری داخلی» باشد و توافق با همان زبان SLA نوشته شود، گاهی آن را SLA داخلی می‌نامند. اما OLA معمولاً متمرکز بر جزئیات عملیاتی و تحویل بین تیم‌ها است، نه بر سطح خدمت نهایی. بهترین تمرین این است که اول OLAهای عملیاتی را ببندید و اگر لازم بود، از دل آن‌ها یک SLA داخلی رسمی‌تر بسازید.

یک OLA خوب چه اجزایی دارد؟

OLA باید به‌قدری روشن باشد که دو تیم بتوانند بدون جلسهٔ اضافه بفهمند «چه کسی، چه چیزی، تا کی». اجزای ضروری:

• دامنه: کدام خدمت یا فرایند بین این دو تیم را پوشش می‌دهد.
• ورودی (Input): تیم دریافت‌کننده برای شروع کار به چه چیزی نیاز دارد.
• خروجی (Deliverable): تیم ارائه‌دهنده دقیقاً چه چیزی تحویل می‌دهد.
• بازهٔ زمانی: از لحظهٔ دریافت ورودی تا تحویل خروجی چقدر مجاز است.
• کیفیت و شرط پذیرش: خروجی باید چه معیاری داشته باشد تا «تمام‌شده» تلقی شود.
• مسئول: نام نقش مسئول در هر طرف.
• مسیر ارجاع: اگر OLA نقض شد، موضوع کجا ارجاع می‌شود.

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

چطور یک OLA بین دو تیم بنویسیم؟

نوشتن OLA یک کار هفت‌گامی است:

1. خدمت یا فرایند را انتخاب کنید: یک جریان کاری مشخص که چند تیم در آن درگیرند.
2. نقشهٔ تحویل (Handoff Map) بکشید: چه چیزی از کدام تیم به کدام تیم می‌رود.
3. هر تحویل را با زمان و کیفیت تعریف کنید: نه کلی، بلکه عددی و قابل سنجش.
4. مسئول‌ها را نام‌دار کنید: نقش، نه فقط عنوان کلی واحد.
5. نقاط شکست را پیش‌بینی کنید: چه چیزی بیشتر از همه باعث تأخیر می‌شود؟
6. توقف ساعت و شرط‌ها را مشخص کنید: چه زمانی مسئولیت از یک تیم به تیم دیگر منتقل می‌شود؟
7. مکانیزم پایش و مرور بگذارید: هر OLA باید دوره‌ای بازبینی شود.

مثال‌های عددی از OLA در عمل

مثال ۱ — پشتیبانی به فنی: تیم پشتیبانی متعهد است هر تیکت سطح بحرانی را با خلاصهٔ کامل و لاگ خطا ظرف ۳۰ دقیقه به تیم فنی ارجاع دهد. OLA می‌گوید تیم فنی ظرف ۲ ساعت کاری از زمان دریافت، تشخیص اولیه را برمی‌گرداند. اگر در ماه ۸۰ تیکت بحرانی ارجاع شود و ۷۰ مورد در بازهٔ ۲ ساعت تشخیص بگیرند، نرخ پایبندی OLA فنی ۸۷.۵٪ است.

مثال ۲ — فروش به پیاده‌سازی: تیم فروش متعهد است بعد از نهایی‌شدن قرارداد، «سند نیازمندی مشتری» را ظرف ۲ روز کاری به تیم پیاده‌سازی بدهد. اگر ۲۵٪ این اسناد ناقص باشند، پیاده‌سازی به‌خاطر تأخیر دیگران عقب می‌افتد. OLA اینجا دو تعهد دارد: زمان تحویل و کیفیت/کامل‌بودن ورودی.

مثال ۳ — زیرساخت به محصول: زیرساخت متعهد است محیط تست را ظرف ۱ روز کاری پس از درخواست آماده کند. تیم محصول می‌تواند روزانه حداکثر ۳ درخواست آماده‌سازی ثبت کند، چون ظرفیت زیرساخت محدود است. اگر بدون این محدودیت، ۷ درخواست در یک روز ثبت شود، OLA از ابتدا محکوم به نقض است. این نشان می‌دهد OLA باید ظرفیت هر طرف را لحاظ کند.

مثال ۴ — حسابداری به پروژه‌ها: تیم مالی متعهد است بازبینی هزینهٔ پروژه را ظرف ۴۸ ساعت انجام دهد. اگر یک تیم پروژه گزارش را همیشه دیر می‌فرستد، OLA متقابل باید زمان تحویل گزارش را هم تعریف کند تا مسئولیت یک‌طرفه نشود.

چطور OLA را پایش و بازبینی کنیم؟

OLA امضاشده هم مثل هر توافق دیگری به مرور نیاز دارد. بدون پایش، به‌سرعت به سند تشریفاتی تبدیل می‌شود. چرخهٔ پایش OLA چهار گام دارد:

1. ثبت تحویل‌ها: هر تحویل بین دو تیم به‌عنوان یک رویداد با زمان مشخص ثبت شود.
2. محاسبهٔ پایبندی: درصد تحویل‌های انجام‌شده در بازهٔ تعهد محاسبه شود.
3. تحلیل علت: چرا تحویل‌های خارج از بازه رخ داده‌اند؟
4. بازبینی تعهد: اگر تکرار بالا بود، ظرفیت، ورودی یا خودِ تعهد اصلاح شود.

نکته مهم: OLA را با همان معیار SLA نسنجید. OLA معمولاً دربارهٔ تحویل‌های میانی است، پس معیار آن باید متناسب با همان گام باشد، نه با نتیجهٔ نهایی مشتری.

چرا OLAهای قدیمی باید هرس شوند؟

با رشد سازمان، بعضی OLAها دیگر موضوعیت ندارند؛ مثلاً وقتی یک فرایند دستی خودکار شده است. نگه‌داشتن توافق‌های منقضی، هم بار ذهنی می‌سازد و هم اعتبار کل سیستم OLA را کم می‌کند. در هر بازبینی فصلی بپرسید: «این توافق هنوز به کار کسی می‌آید؟ اگر حذفش کنیم چه چیزی از دست می‌رود؟» اگر پاسخ روشن نبود، آن را حذف یا ادغام کنید.

OLA و SLA داخلی: کدام را انتخاب کنیم؟

اگر رابطهٔ دو واحد شبیه مشتری-ارائه‌دهندهٔ رسمی است و نیاز به گزارش رسمی دارد، SLA داخلی مناسب‌تر است. اگر رابطه، همکاری متقابل روی یک جریان کار است، OLA کافی و سبک‌تر است. در بسیاری از موارد، OLA عملیاتی زیربنای یک SLA داخلی رسمی‌تر می‌شود و نیازی به نگه‌داشتن هر دو به‌صورت جداگانه نیست.

یک مثال از پایش OLA

فرض کنید OLA تیم فنی به پشتیبانی «تشخیص اولیه در ۲ ساعت کاری» است. در سه ماه، پایبندی به‌ترتیب ۷۹٪، ۸۴٪ و ۸۸٪ بوده است. روند صعودی اما هنوز زیر آستانهٔ ۹۵٪ است. تحلیل نشان می‌دهد بیشترین تأخیر در روزهای اوج هفتگی رخ می‌دهد. اقدام: جابه‌جایی شیفت و کاهش هم‌زمانی کارها. با این رویکرد، OLA نه عددی ثابت، بلکه مسیری در حال بهبود می‌شود.

مزایا، معایب و Trade-off

Trade-off اصلی: OLA سخت‌گیرانه، وابستگی‌ها را قابل پیش‌بینی می‌کند اما ریسک «قانون‌گرایی» و بی‌روح‌شدن همکاری را بالا می‌برد. OLA باید یک «توافق زنده» باشد که کنارش گفت‌وگوی انسانی جریان دارد، نه ابزاری برای سرزنش یکدیگر.

اشتباهات رایج در طراحی OLA

1. نوشتن OLA یک‌طرفه: تعهد بدون تعهد متقابل، به بی‌عدالتی و مقاومت می‌انجامد.
2. تعریف بدون ظرفیت‌سنجی: تعهدی که از ابتدا از ظرفیت تیم بیشتر است، بی‌معنا است.
3. نادیده‌گرفتن کیفیت ورودی: فقط زمان تحویل تعریف می‌شود، نه کامل‌بودن تحویل.
4. ابهام در نقطهٔ انتقال مسئولیت: معلوم نیست در چه لحظه‌ای وظیفه از یک تیم به تیم دیگر می‌رسد.
5. نبود مکانیزم مرور: OLA کهنه به‌سرعت از واقعیت جدا می‌شود.
6. تعداد زیاد OLAها: رفتن به سراغ ده‌ها توافق به‌جای یکی‌دو جریان مهم، همه را نیمه‌کاره می‌کند.

نکات کاربردی

• نکته مهم: از یک جریان کاری پرتکرار و پراصطکاک شروع کنید؛ نه از برنامهٔ کل سازمان.
• ترفند کاربردی: برای هر تحویل، «شرط پذیرش» را در یک جمله بنویسید: «وقتی این اطلاعات رسید، کار شروع می‌شود».
• اشتباه رایج: شمردن زمان از لحظهٔ «شروع کار تیم» به‌جای «رسیدن ورودی»؛ این اشتباه مسئولیت تأخیرهای بالادست را پنهان می‌کند.
• قبل از امضا این را بدانید: آیا هر دو طرف ظرفیت و اختیار لازم برای رعایت OLA را دارند؟

دوایتفای و توافق‌های سطح عملیاتی داخلی

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

شفاف باشیم: دوایتفای محصول ماست؛ برای تیم‌هایی که فقط دو واحد کوچک دارند و ارتباطشان مستقیم است، شاید یک توافق سادهٔ شفاهی کافی باشد و انتخاب ابزار به میزان پیچیدگی وابستگی‌ها بستگی دارد.

جمع‌بندی

OLA حلقهٔ گمشدهٔ بین تعهد بیرونی و اجرای درونی است. اگر SLA قول به مشتری است، OLA همان قولی است که تیم‌های داخلی به یکدیگر می‌دهند تا آن قول بیرونی محقق شود. برای شروع، یک جریان کاری پراصطکاک را انتخاب کنید، نقشهٔ تحویل بین تیم‌ها را بکشید و برای هر تحویل «ورودی، خروجی، بازهٔ زمانی، کیفیت و مسئول» را بنویسید. OLA خوب کوتاه، متقابل و قابل مرور است؛ نه سند سنگین و یک‌طرفه.

اگر موضوع OLA برایتان مفید بود، پیشنهاد می‌کنیم چک‌ لیست مدیریتی قبل از خرید نرم‌ افزار مدیریت پروژه سازمانی و مزایا و معایب استفاده از ابزار مدیریت پروژه آنلاین را هم بخوانید.