Target Operating Model چیست؟ طراحی مدل عملیاتی آینده سازمان

هر سازمانی یک مدل عملیاتی «فعلی» دارد: همان روشی که امروز کارها انجام می‌شود، حتی اگر هیچ‌وقت روی کاغذ نیامده باشد. اما وقتی استراتژی عوض می‌شود، بازار تغییر می‌کند یا سازمان سریع رشد می‌کند، مدل فعلی دیگر جواب نمی‌دهد. اینجاست که بحث از مدل عملیاتی هدف (Target Operating Model) پیش می‌آید: تصویری از اینکه سازمان در آینده چگونه باید کار کند تا به استراتژی‌اش برسد.

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

Target Operating Model چیست؟ (پاسخ سریع)

مدل عملیاتی هدف (Target Operating Model یا TOM) توصیف وضعیت مطلوب مدل عملیاتی یک سازمان در یک نقطهٔ زمانی آینده است. اگر مدل عملیاتی فعلی نشان می‌دهد سازمان «الان» چگونه کار می‌کند، TOM نشان می‌دهد «باید چگونه کار کند» تا استراتژی محقق شود. TOM ایده‌های استراتژیک را به الزامات و تصمیم‌های عملیاتی ترجمه می‌کند و تصویری مشترک از آیندهٔ سازمان به مدیران می‌دهد.

تفاوت TOM با مدل عملیاتی فعلی چیست؟

هر تلاش برای طراحی TOM از دو تصویر شروع می‌شود: وضعیت فعلی (as-is) و وضعیت هدف (to-be). مدل فعلی توصیف صادقانهٔ امروز است؛ TOM توصیف مطلوب فردا. فاصلهٔ این دو، همان «شکاف تغییر» است که باید با نقشهٔ راه پر شود.

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

چرا سازمان‌ها به طراحی TOM نیاز پیدا می‌کنند؟

نیاز به TOM معمولاً از یکی از این موقعیت‌ها بیرون می‌آید:

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

در همهٔ این موقعیت‌ها، تغییر تنها یک بخش (مثلاً چارت) کافی نیست؛ چون جریان کار و تصمیم دست‌نخورده می‌ماند.

یک TOM از چه بخش‌هایی تشکیل می‌شود؟

مدل‌های مختلفی برای اجزای TOM وجود دارد. یکی از کامل‌ترین‌ها چارچوب POLISM است که شش لایه را پوشش می‌دهد و برای طراحی سازمان به‌کار می‌رود:

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

مراحل طراحی Target Operating Model

طراحی TOM یک پروژه است، نه یک جلسه. گام‌های منطقی آن به این شکل است:

1. روشن‌کردن استراتژی و اصول طراحی: ابتدا روشن کنید سازمان به کدام سمت می‌رود و بر چه اصولی استوار است (مثلاً سرعت تصمیم، نزدیکی به مشتری، استانداردسازی).
2. مستندسازی وضعیت فعلی: جریان‌های ارزش، نقش‌ها، داده‌ها و سیستم‌های امروز را صادقانه ترسیم کنید.
3. تعیین الزامات آینده: از استراتژی بیرون بیاورید که مدل مؤثر فردا چه مشخصاتی باید داشته باشد.
4. طراحی گزینه‌ها: دو یا سه گزینهٔ متفاوت TOM طراحی کنید، نه فقط یک گزینه.
5. ارزیابی گزینه‌ها: هر گزینه را بر اساس هزینه، پیچیدگی، ریسک و اثربخشی بسنجید.
6. انتخاب و تدوین TOM: گزینهٔ منتخب را با جزئیات لایه‌های شش‌گانه تکمیل کنید.
7. ساخت نقشهٔ گذار: گام‌ها، ترتیب، مالک و شاخص گذار از امروز به هدف را بنویسید.
8. اجرا و بازبینی: TOM را اجرا کنید و با تغییر شرایط، دوره‌ای بازبینی کنید.

پرش از گام ۳ یا ۷ شایع‌ترین خطاست. طراحی بدون الزامات آینده، به «کپی از وضع موجود» می‌رسد؛ و بدون نقشهٔ گذار، به سندی بایگانی‌شده.

TOM چگونه استراتژی را عملی می‌کند؟

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

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

مثال‌های عددی و سناریوها

اعداد این مثال‌ها فرضی‌اند و فقط برای روشن‌شدن موضوع ارائه شده‌اند.

• سناریوی شرکت خدماتی در حال رشد: سازمان از ۴۰ به ۹۰ نفر رسیده بود و سازوکارهای غیررسمی دیگر جواب نمی‌داد. TOM با تمرکز بر یکپارچه‌سازی فرآیندهای تحویل و مالکیت واحد طراحی شد. نتیجهٔ مورد انتظار: کاهش زمان ورود یک پروندهٔ مشتری از ۵ روز به ۲ روز و کاهش هماهنگی دستی حدود ۶ ساعت در هفته.
• سناریوی هلدینگ چند‌شرکتی: ستاد مرکزی می‌خواست گزارش‌ها یکدست شوند و در عین حال هر شرکت استقلال داشته باشد. TOM الگوی «هماهنگی» را انتخاب کرد: فرآیندها استاندارد نشدند اما گزارش‌دهی یکپارچه شد. تجمیع گزارش‌ها از ۱۰ ساعت به ۳ ساعت در هفته کاهش یافت.
• سناریوی سازمان در حال ادغام: دو واحد پشتیبانی با فرآیندهای متفاوت ادغام شدند. TOM با انتخاب اصول «یک نقطهٔ تماس با مشتری» و «دادهٔ مشترک»، اختلاف رویه‌ها را از میان برداشت و سردرگمی مشتری را کاهش داد.
• سناریوی ورود به بازار جدید: فروش می‌خواست سریع‌تر باشد اما تصمیم‌های قیمت‌گذاری در ستاد معطل می‌ماند. TOM با انتقال بخشی از اختیار قیمت به سطح منطقه، زمان انتظار تصمیم را از میانگین ۴ روز به زیر ۱ روز رساند.

TOM را برای کل سازمان طراحی کنیم یا یک واحد؟

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

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

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

Trade-off اصلی: طراحی TOM جامع‌تر، اطمینان بیشتری می‌دهد اما کندتر پیش می‌رود و منابع می‌برد. طراحی سریع‌تر، خطر نادیده‌گرفتن لایه‌های مهم را دارد. راه میانه، شروع از یک محدودهٔ روشن (مثلاً یک زنجیرهٔ ارزش) و تعمیم تدریجی است.

اشتباهات رایج

1. طراحی TOM بدون استراتژی روشن: مدل بدون مقصد، فقط چیدمان دوبارهٔ وضع موجود است.
2. پرش از نقشهٔ گذار: TOM بدون مسیر اجرا، به سند تشریفاتی تبدیل می‌شود.
3. طراحی فقط یک گزینه: بدون مقایسه، تصمیم‌گیری دربارهٔ Trade-offها ممکن نیست.
4. نادیده‌گرفتن لایهٔ داده: هماهنگی بین بخش‌ها بدون دادهٔ مشترک شکننده است.
5. تمرکز افراطی بر ساختار: تغییر چارت بدون تغییر جریان تصمیم و فرآیند، بی‌اثر می‌ماند.
6. بی‌توجهی به فرهنگ و آمادگی افراد: مدلی که افراد نپذیرند، در عمل اجرا نمی‌شود.

نکات کاربردی

• نکته مهم: TOM را از «ارزش مشتری» شروع کنید، نه از ساختار داخلی؛ سپس سازمان را حول تحویل آن ارزش بچینید.
• ترفند کاربردی: برای هر تصمیمِ پرتکرار در TOM، سه چیز را روشن کنید: مالک، مشاور و اجراکننده.
• ترفند کاربردی: قبل از تعهد به TOM نهایی، دو گزینهٔ جایگزین طراحی کنید و Trade-offهایشان را کنار هم بگذارید.
• قبل از شروع این را بدانید: اگر تیم نمی‌تواند تفاوت وضعیت فعلی و هدف را در سه جمله توضیح دهد، هنوز طراحی TOM را شروع نکرده‌اید.
• اشتباه رایج: انتظار تغییر سریع. گذار به TOM معمولاً چند مرحله دارد و باید تدریجی مدیریت شود.

دوایتفای و مدل عملیاتی هدف

پس از طراحی TOM، چالش بعدی نگه‌داشتن سازمان روی مسیر گذار است. دوایتفای پلتفرمی جامع برای مدیریت پروژه، مدیریت تیم و رسیدن به اهداف است که می‌تواند بستر اجرای برنامهٔ گذار باشد: هر گام از گذار به یک پروژه یا ابتکار با تسک، زیرتسک، چک‌لیست و مسئول تبدیل می‌شود و پیشرفت در همان محیط پیگیری می‌شود.

امکاناتی مثل بورد و کانبان، وابستگی‌های WBS، رودمپ، تقویم، گانت‌چارت، مدیریت منابع و Workload، گزارش‌های کاری و عملکرد، مستندات پروژه، Milestone و یادآورها به شفاف‌بودن مسیر گذار کمک می‌کنند. Doitify Copilot و AI Coach هم به‌عنوان دستیار مدیریت پروژه، در ساخت تسک‌ها، برنامه‌ریزی، اسپرینت‌ها و گزارش‌ها کمک می‌کنند. شفافیت: دوایتفای محصول ماست و امکاناتش را از نزدیک می‌شناسیم؛ اما انتخاب TOM یک تصمیم طراحی است که پیش از انتخاب ابزار باید گرفته شود.

جمع‌بندی

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

اگر موضوع Target Operating Model برایتان مفید بود، پیشنهاد می‌کنیم نرم افزار مدیریت پروژه چابک و انواع WBS در مدیریت پروژه؛ محصول‌محور، فازمحور و مسئولیت‌محور را هم بخوانید.