مالک تصمیم همان نقشی است که در پروژههای مشترک، جلوی جملههای آشنای «فکر میکردیم واحد شما تصمیم میگیرد» یا «هنوز تأیید نهایی نیامده» را میگیرد. در بسیاری از سازمانها، پروژه تا مرحله ارائه پاورپوینت و تشکیل گروه کاری خوب جلو میرود، اما درست وقتی باید درباره دامنه، هزینه یا اولویت انتخاب شود، کار میایستد. آدمهای زیادی در جلسهاند؛ صاحب رأی نهایی پیدا نیست.
این مسئله با نوشتن چند نام زیر عنوان مسئولیت حل نمیشود. باید روشن باشد چه کسی تصمیم را میگیرد، تا کجا اختیار دارد، نظر چه کسانی را باید بشنود، چه کسانی فقط باید در جریان باشند و اگر اختلاف باقی ماند، چه کسی و در چه مهلتی آن را از بنبست بیرون میآورد. پروتکل مورد بحث، قرار نیست همکاری را کم کند؛ قرار است لحظهای را که گفتوگو باید به انتخاب تبدیل شود، از مه بیرون بکشد.
چرا ابهام مالکیت در پروژههای بینواحدی به تأخیر و اصطکاک تبدیل میشود؟
فرق مهمی میان انجامدادن یک کار و اختیار انتخاب مسیر آن وجود دارد. ممکن است واحد فناوری مسئول ساخت یک فرم باشد، واحد منابع انسانی محتوای فرم را آماده کند و مالی هزینه را کنترل کند؛ با این حال، تصمیم درباره اینکه نسخه اول با چه امکاناتی منتشر شود، لزوماً متعلق به هیچکدام از این سه واحد نیست. اگر این نقطه از ابتدا تعیین نشود، هر اصلاح کوچک به رفتوآمد میان مدیران تبدیل میشود.
الگوی شکست معمولاً آرام شروع میشود. در جلسه اول همه با کلیات موافقاند. هفته دوم، واحد حقوقی یک بند اضافه میکند؛ فناوری میگوید این بند دو هفته زمان میخواهد؛ کسبوکار میگوید موعد کمپین قابل جابهجایی نیست. هیچکس مخالفت صریحی هم ندارد. فقط عبارتهایی مثل «بعداً هماهنگ میکنیم»، «باید با مدیرمان چک کنیم» و «مسئولیت مشترک است» زیاد میشود. اینها نشانه همکاری نیستند؛ اغلب نشانه نداشتن مالک تصمیم هستند.
هزینه پنهان این وضعیت، فقط تأخیر تقویم نیست. نسخههای مختلف فایل در پیامرسان میچرخد، سه جلسه برای یک انتخاب تکرار میشود، مجریها کار را با فرضهای متفاوت آغاز میکنند و بعد بخشی از آن را برمیگردانند. در یک پروژه متوسط، تأخیر چهارروزه در انتخاب تأمینکننده میتواند شروع آموزش، قرارداد و تحویل را همزمان عقب بیندازد. بعد از چند تجربه، واحدها به هم اعتماد کمتری میکنند و هر کس برای محافظت از خودش، افراد بیشتری را در رونوشت پیامها میگذارد.
مالک تصمیم الزاماً مدیر ارشد، مدیر پروژه یا فردی با بلندترین عنوان سازمانی نیست. مدیر ارشد ممکن است باید درباره سقف سرمایهگذاری تصمیم بگیرد، اما برای انتخاب ترتیب اجرای قابلیتها، کارشناس محصولی که دادههای استفاده، محدودیتهای فنی و اثر عملیاتی را میبیند، گزینه مناسبتری باشد. عنوان شغلی بهتنهایی معیار خوبی نیست؛ اختیار واقعی و پاسخگویی بعد از نتیجه مهمتر است.
پروتکل مالک تصمیم دقیقاً چیست و چه تفاوتی با تقسیم وظایف دارد؟
پروتکل مالک تصمیم یک توافق مکتوب و کوتاه برای تصمیمهای مهم پروژه است. در آن، هر تصمیم جداگانه ثبت میشود، نه اینکه فقط یک نفر را مسئول کل پروژه بنویسند. مثلاً «انتخاب مدل پرداخت پاداش»، «تأیید دامنه نسخه اول» و «توقف آزمایشی در صورت خطای امنیتی» سه تصمیم متفاوتاند و میتوانند سه صاحب اختیار متفاوت داشته باشند.
سه واژه را نباید قاطی کرد. مالک خروجی کسی است که بابت تحویل نتیجه قابل اندازهگیری پاسخ میدهد؛ مثلاً راهاندازی موفق سامانه در ۱۲ شعبه. مالک اجرا کسی است که فعالیتهای روزانه را جلو میبرد؛ مانند هماهنگی نصب، آموزش و پیگیری تیکتها. اما مالک تصمیم فردی است که بین گزینههای معتبر انتخاب میکند و انتخابش را رسماً اعلام میکند. گاهی هر سه نقش در یک نفر جمع میشوند، ولی در پروژه بینواحدی اغلب اینطور نیست.
حداقل اطلاعات هر رکورد تصمیم اینهاست:
- خود تصمیم: دقیق و قابل انتخاب؛ نه عبارتی مبهم مانند «حل مسئله پرداخت».
- مالک تصمیم: نام یک فرد، نه نام یک واحد یا کمیته.
- حد اختیار: سقف هزینه، اثر زمانی و سطح ریسکی که میتواند بپذیرد.
- مشورتدهندگان و افراد مطلع: با تفکیک روشن میان نظر دادن و صرفاً آگاه شدن.
- موعد: آخرین زمان دریافت نظر و آخرین زمان اعلام انتخاب.
- مسیر تشدید: مرجع مشخص برای وقتی که اختلاف در مهلت تعیینشده حل نشود.
ابزارهایی مانند RACI برای روشنکردن نقش در فعالیتها مفیدند، اما تمرکزشان غالباً روی این است که چه کسی کار را انجام میدهد و چه کسی پاسخگوست. پروتکل مالک تصمیم سؤال باریکتری میپرسد: وقتی دو گزینه روی میز است و منافع واحدها با هم نمیخواند، چه کسی حق دارد انتخاب کند؟ همین تفاوت کوچک، بسیاری از جلسههای بیخروجی را از بین میبرد.
کدام تصمیمها باید مالک مشخص داشته باشند؟ نقشهبرداری از نقاط تصمیم پروژه
لازم نیست برای انتخاب رنگ یک آیکون یا ساعت جلسه، پرونده تصمیم بسازید. از انتخابهایی شروع کنید که پول، زمان، وابستگی بین واحدها یا ریسک اعتبار سازمان را جابهجا میکنند. اگر یک انتخاب برگشتپذیر است و دو ساعت بعد قابل اصلاح است، ثبت مفصل آن بیشتر از خود تصمیم هزینه میسازد. پروتکل باید اصطکاک را کم کند، نه اینکه لایه تازهای از امضا ایجاد کند.
در پروژههای بینواحدی، نقاط تصمیم معمولاً دور این موضوعها میچرخند: تعریف دامنه نسخه اول، ترتیب اولویتها، تخصیص بودجه، انتخاب تأمینکننده، تاریخ انتشار، معیار پذیرش، تغییر نیازمندی پس از شروع اجرا، نحوه پاسخ به ریسک امنیتی و زمان توقف یا ادامه پایلوت. برای هر مورد، بنویسید اگر این انتخاب پنج روز عقب بیفتد چه چیزی متوقف میشود و چه کسی هزینهاش را میدهد. جوابها اغلب محل نیاز به مالک تصمیم را نشان میدهند.
برنامه پروژه، گزارشهای پس از اجرا و حتی خاطره افراد باتجربه، منابع خوبی برای پیدا کردن گلوگاهها هستند. از افراد بپرسید «در پروژه مشابه، کجا بیشترین رفتوبرگشت را داشتیم؟» یا «کدام انتخاب را سه بار به جلسه بعد بردیم؟» بسیاری از سازمانها روی زمان تحویل حساساند، اما زمان معطلی تصمیم را اندازه نمیگیرند؛ در حالی که همان معطلی، ریشه بخشی از دیرکردهاست. مقاله نقشه وابستگی و کاهش زمان انتظار بین واحدها هم برای دیدن همین گرهها کاربرد عملی دارد.
برای اولویتبندی، به هر تصمیم از یک تا پنج امتیاز بدهید: اثر مالی، تعداد وابستگیها، ریسک حقوقی یا عملیاتی، دشواری بازگشت و فشار زمانی. تصمیمی که امتیاز ۱۸ از ۲۵ دارد، بدون تردید باید مالک تصمیم و مسیر تشدید روشن داشته باشد. تصمیمی با امتیاز ۶ را میشود به مسئول اجرا سپرد و فقط نتیجهاش را ثبت کرد.
چگونه مالک درست را انتخاب کنیم؟ اختیار، تخصص و پاسخگویی در یک نقطه
قاعده ساده است: کسی را مالک کنید که بتواند با پیامد انتخابش زندگی کند. فردی که بابت نتیجه پاسخ نمیدهد، معمولاً یا بیش از حد محتاط میشود یا تصمیمی میگیرد که هزینهاش را واحد دیگری میدهد. تناسب اختیار و پاسخگویی باید واقعی باشد، نه فقط روی کاغذ. اگر مالک اجازه جابهجایی بودجه ندارد ولی تصمیمش بدون بودجه اجراشدنی نیست، انتخاب او نمایشی است.
برای انتخاب مالک تصمیم، چهار چیز را بررسی کنید: آیا به دادههای لازم دسترسی دارد؟ آیا میتواند واحدهای وابسته را دور یک میز بنشاند؟ آیا در سقف مورد نظر اختیار منابع دارد؟ و آیا نام او در گزارش نتیجه پروژه میآید؟ فردی با دانش فنی عالی اما بدون دسترسی به اطلاعات مشتری یا بدون امکان تخصیص نفر، شاید مشورتدهندهای عالی باشد؛ ولی لزوماً مالک مناسب نیست.
مدیر پروژه در موارد زیادی نباید مالک تصمیم باشد. او ممکن است مسئول حفظ زمانبندی و هماهنگی باشد، اما تصمیم درباره پذیرش ریسک مالی، تغییر سیاست منابع انسانی یا انتخاب معماری فنی باید دست کسی باشد که اختیار آن حوزه را دارد. وقتی مدیر پروژه را برای همه انتخابها صاحب اختیار میکنند، عملاً از او میخواهند هم داور باشد، هم مجری و هم سپر اختلاف واحدها. این مدل خیلی زود فرسوده میشود.
پیش از ثبت نام، این پنج سؤال را بلند بپرسید:
- اگر این تصمیم اشتباه باشد، چه کسی باید پاسخگو باشد؟
- چه کسی به داده و تجربه لازم دسترسی سریع دارد؟
- چه کسی میتواند منابع لازم برای اجرای انتخاب را آزاد کند؟
- چه کسی میان منافع متعارض، حق اولویتگذاری دارد؟
- آیا این فرد تا پایان موعد تصمیم در دسترس است؟
مالکیت مشترک در تصمیمهای حساس، اغلب اسم محترمانه بیمالکی است. دو نفر میتوانند همنظر شوند، اما وقتی اختلاف دارند باید از قبل معلوم باشد رأی نهایی با کیست. مدل دو امضایی فقط در مواردی مناسب است که الزام قانونی، کنترل مالی یا ریسک اخلاقی وجود دارد. حتی آنجا هم بهتر است یکی مالک تصمیم عملیاتی باشد و دیگری نقش تأییدکننده با معیارهای محدود و نوشتهشده داشته باشد.
دامنه اختیار را بنویسید: تصمیمگیری مستقل تا الزام به مشورت و تأیید
نوشتن نام مالک، بدون نوشتن مرز اختیار، نصف کار است. فردی که نمیداند تا چه سقفی میتواند تصمیم بگیرد، برای کوچکترین مورد سراغ مدیر بالاتر میرود؛ یا برعکس، تصمیمی میگیرد که بعداً با این جمله پس گرفته میشود: «این در سطح اختیار تو نبود.» هر دو حالت اعتبار پروتکل را از بین میبرد.
چهار سطح کاربردی برای اختیار وجود دارد. سطح اول، تصمیم مستقل است: مالک پس از بررسی دادهها انتخاب میکند و فقط نتیجه را اطلاع میدهد. سطح دوم، تصمیم پس از مشورت است: باید نظر افراد مشخص را تا موعد مقرر بگیرد، اما حق انتخاب نهایی با اوست. سطح سوم، مشروط به تأیید است: مالک پیشنهاد میدهد و مرجع تأیید فقط بر اساس معیار ثبتشده پاسخ میدهد. سطح چهارم، قابل ارجاع است: وقتی آستانه مشخصی رد شد، مالک تصمیم باید موضوع را بیدرنگ به مرجع بالاتر ببرد.
مرزها را با عدد بنویسید. مثلاً مالک میتواند تأمینکننده را تا سقف ۴۵۰ میلیون تومان انتخاب کند، افزایش زمانبندی تا سه روز را بپذیرد و تغییرات بدون اثر بر دادههای محرمانه را تأیید کند. بیشتر از این سقف، یا هر تغییری که دسترسی به اطلاعات پرسنلی را عوض کند، نیازمند تأیید مدیر مربوطه است. عبارت «در موارد مهم» مرز نیست؛ محل دعوای بعدی است.
برای مشورت هم زمان تعیین کنید. مثلاً مشورتدهندگان از لحظه دریافت پرونده تصمیم، ۲۴ ساعت کاری فرصت دارند نظر مستندشان را بدهند. سکوت پس از این مهلت، به معنای نداشتن اعتراض در همان دامنه تعریف میشود، مگر در موضوع قانونی، ایمنی یا نقض حقوق افراد. این قاعده به مالک اجازه میدهد پروژه را جلو ببرد و به دیگران هم فرصتی منصفانه برای اعلام نگرانی میدهد.
نقش مشورتدهندگان، مجریان و افراد مطلع را از هم جدا کنید
مالک تصمیم انتخاب را میکند و مسئول توضیح منطق آن است. مشورتدهنده، تحلیل و هشدار میدهد؛ او باید قبل از تصمیم، داده یا تجربهاش را وارد کند، نه اینکه بعد از اعلام نتیجه فقط بگوید مخالف بوده است. مجری محدودیتهای واقعی اجرا را میگوید: ظرفیت نفرات، زمان تست، وضعیت قرارداد یا امکان عملیاتیشدن. فرد مطلع هم صرفاً باید بداند چه اتفاقی افتاده تا کار خودش را هماهنگ کند.
حضور در جلسه، حق وتو ایجاد نمیکند. این جمله باید در فرهنگ جلسه جا بیفتد، بهخصوص وقتی مدیران واحدهای مختلف کنار هم نشستهاند. گاهی یک مدیر صرفاً بهخاطر حضورش انتظار دارد تصمیم متوقف بماند تا رضایت کامل او جلب شود. اگر نقش او مشورتدهنده است، مخالفتش باید شنیده و ثبت شود، اما مالک تصمیم با توجه به کل تصویر انتخاب میکند.
یک قرارداد رفتاری کوتاه کمک زیادی میکند: مخالفت را با داده، ریسک و گزینه جایگزین مطرح کن؛ مخالفت را پیش از موعد ثبت کن؛ بعد از تصمیم، نسخه نهایی را به نسخههای شخصی ترجیح بده؛ و اگر تصمیم قانون، ایمنی یا شأن انسانی را نقض میکند، موضوع را از مسیر تشدید بالا ببر. این قرارداد، بحث را از «نظر واحد ما مهمتر است» به «این ریسک و این شواهد را داریم» منتقل میکند.
افراد مطلع را بیحساب زیاد نکنید. در یک پروژه استقرار فرایند جدید، شاید مدیر شعبهها باید نتیجه تصمیم را بدانند، اما لازم نیست در همه جلسههای انتخاب تأمینکننده حضور داشته باشند. رونوشتکردن ۴۰ نفر، معمولاً شفافیت نمیآورد؛ فقط پاسخدادن را کند میکند. دفتر تصمیم باید برای همه قابل مشاهده باشد، ولی حق مشارکت در هر تصمیم باید محدود و روشن بماند.
جلسه آغاز پروژه را به کارگاه شفافسازی تصمیم تبدیل کنید
جلسه آغاز پروژه اگر صرفاً به معرفی افراد و مرور اسلاید زمانبندی بگذرد، فرصت مهمی از دست رفته است. بخشی از جلسه را به کارگاه تصمیم تبدیل کنید. پیشنویس را قبل از جلسه بفرستید: خروجیهای اصلی، ۸ تا ۱۲ تصمیم حساس، پیشنهاد اولیه برای مالک تصمیم هر مورد و سطح اختیار. وقتی افراد با صفحه سفید روبهرو نشوند، بحث دقیقتر و کوتاهتر میشود.
توالی کارگاه میتواند این باشد: اول بگویید در پایان چه خروجی قابل سنجشی باید تحویل شود؛ بعد نقاطی را مرور کنید که انتخاب در آنها اجتنابناپذیر است؛ سپس برای هر نقطه مالک، مشورتدهنده و مرجع تشدید را تعیین کنید؛ آخر سر، قواعد مهلت پاسخ و ثبت نتیجه را توافق کنید. این کار برای پروژهای با پنج واحد درگیر، معمولاً در یک جلسه ۹۰ دقیقهای قابل انجام است، اگر پیشنویس آماده باشد.
پرسشهای تسهیلگر، جلسه را از کلیگویی درمیآورند: «اگر تا سهشنبه اختلاف حل نشد، چه کسی انتخاب میکند؟» «چه تصمیمی را این فرد بدون امضا میتواند بگیرد؟» «چه دادهای لازم است تا تصمیم معتبر باشد؟» «کدام واحد فقط از نتیجه متاثر است و نباید در بحث روزانه باشد؟» پاسخهای شفاهی را همان لحظه ثبت کنید؛ حافظه جمعی بعد از دو هفته قابل اتکا نیست.
سند نهایی بهتر است یک یا دو صفحه باشد و کنار برنامه پروژه نگهداری شود، نه در پوشهای که فقط مدیر پروژه به آن دسترسی دارد. هر تغییر در نام مالک یا سطح اختیار، باید تاریخ، دلیل و تأیید مرجع تغییر را داشته باشد. نسخه کوتاه و زنده از یک سند ۲۵ صفحهای که کسی بازش نمیکند، خیلی مفیدتر است.
وقتی اختلاف ایجاد میشود، پروتکل چگونه تصمیم را از بنبست خارج میکند؟
اختلاف نشانه شکست نیست. در پروژه مشترک، طبیعی است که مالی به هزینه حساس باشد، فناوری به پایداری و واحد عملیاتی به زمان آموزش. مسئله وقتی فرسایشی میشود که اختلاف شخصی شود یا معلوم نباشد چه زمانی تمام میشود. پروتکل مالک تصمیم اختلاف را حذف نمیکند؛ آن را از چرخه پیامهای بیپایان به یک مسیر زماندار منتقل میکند.
مسیر سهمرحلهای ساده است. مرحله اول، گفتوگوی مستقیم بین افراد درگیر با دادههای مشترک و حداکثر در یک نشست کوتاه. مرحله دوم، اگر توافق نشد، مالک تصمیم دلایل را میشنود و تا موعد تعیینشده انتخاب میکند. مرحله سوم، فقط وقتی اختلاف از مرز اختیار، قانون یا ریسک تعیینشده عبور میکند، موضوع همراه با گزینهها و آثار هر گزینه به مرجع تشدید میرود. ارجاع بدون گزینه و تحلیل، فقط انتقال ابهام به طبقه بالاتر است.
خوب است اختلافها را دستهبندی کنید. اختلاف بر سر داده یعنی یک طرف میگوید هزینه ۳۰۰ میلیون است و طرف دیگر ۵۲۰ میلیون؛ این با اعتبارسنجی اطلاعات حل میشود. اختلاف بر سر اولویت یعنی هر دو عدد را قبول دارند، اما یکی سرعت را مهمتر میداند و دیگری کنترل ریسک را. اینجا انتخاب ارزشی و مدیریتی لازم است. دسته سوم، اختلاف بر سر ریسک غیرقابلپذیرش است؛ مانند نقض الزام قانونی. این مورد نباید با رأی اکثریت حل شود.
در دفتر تصمیم، یک بخش کوچک برای اختلاف بگذارید: موضوع، دو یا سه گزینه، شواهد هر گزینه، افراد مخالف، انتخاب نهایی، دلیل انتخاب و تاریخ بازبینی. اصل مفید این است که «مخالفت کن، سپس متعهد شو». یعنی بعد از شنیدهشدن اعتراض و ثبت آن، افراد باید برای اجرای تصمیم منتخب همکاری کنند. استثنا روشن است: تخلف قانونی، آسیب ایمنی، تبعیض یا نقض حقوق اساسی افراد، تعهد به اجرا ایجاد نمیکند و باید فوراً ارجاع شود.
پروتکل را زنده نگه دارید: بازبینی، سنجش و بهبود در طول پروژه
پروتکل مالک تصمیم سند سنگی نیست. با تغییر دامنه، جابهجایی مدیر، ورود تأمینکننده تازه یا عبور پروژه از مرحله طراحی به اجرا، ممکن است صاحب اختیار مناسب هم عوض شود. مهم این است که تغییر، آشکار و ثبتشده باشد. بدترین حالت این است که افراد در عمل نقشها را عوض کنند، اما سند قدیمی بماند و دیگران با فرضهای پیشین کار کنند.
سه زمان برای بازبینی معمولاً کافی است: بعد از پایان طراحی، پیش از شروع اجرای گسترده و بلافاصله بعد از یک تغییر مهم در بودجه یا دامنه. در پروژههای کوتاهتر از دو ماه، یک مرور ۲۰ دقیقهای در میانه مسیر هم ارزش دارد. از خودتان بپرسید کدام تصمیم بیشتر از موعد معطل شد، کجا مشورتدهنده دیر وارد شد و کجا مالک اختیار کافی نداشت.
چند شاخص ساده، اثر پروتکل را قابل مشاهده میکند: میانگین زمان از طرح مسئله تا اعلام انتخاب، تعداد تصمیمهای معطل بیش از مهلت، تعداد دفعات بازگشایی یک تصمیم، ساعت جلسه صرفشده برای تصمیمهای تکراری و حجم بازکاری ناشی از تغییرات دیرهنگام. لازم نیست از روز اول داشبورد پیچیده بسازید. حتی یک فایل مشترک با تاریخ شروع و پایان هر تصمیم، بعد از یک ماه الگوها را نشان میدهد.
مدیران ارشد در این میان نقش حساسی دارند. اگر آنها هر زمان که با تصمیمی موافق نبودند، مستقیم از روی مالک تصمیم عبور کنند، هیچ پروتکلی دوام نمیآورد. اعتراض مدیر ارشد میتواند از مسیر تعریفشده وارد شود، اما باید معلوم باشد تصمیم قبلی چرا تغییر کرده است. احترام به مالکیت تعیینشده، به معنی حذف نظارت نیست؛ یعنی نظارت هم قاعده دارد.
بهتر است ابتدا روی پروژهای با پیچیدگی متوسط آزمایش کنید: مثلاً بازطراحی فرایند درخواست آموزش برای ۶۰۰ نفر، یا اجرای یک خدمت جدید در سه شعبه. پروژه خیلی کوچک، ارزش پروتکل را نشان نمیدهد و پروژه بحرانزده هم حوصله یادگیری ندارد. پس از پایان پایلوت، با افراد درگیر مرور کنید که کدام بخش واقعاً سرعت را بالا برد و کدام بند فقط کاغذبازی بود. برای مفهوم مسئولیتپذیری مدیریتی، مرور مدخل مسئولیتپذیری هم نقطه شروع بدی نیست.
جمعبندی
پروتکل مالک تصمیم قرار نیست همه را از گفتوگو کنار بگذارد. کارش این است که فرق میان مشورت، اجرا، اطلاع و انتخاب نهایی را قابل دیدن کند. پروژهای که برای هر نقطه حساس یک صاحب اختیار دارای مرز روشن دارد، کمتر در جلسههای تکراری میماند و وقتی اختلاف پیش میآید، راه خروجش را از قبل میشناسد.
شروع عملی، انتخاب یک پروژه جاری است. ۱۰ تصمیمی را که بیشترین اثر را بر زمان، هزینه یا ریسک دارند روی یک صفحه بنویسید؛ برای هر کدام یک مالک تصمیم، سطح اختیار، مهلت نظرخواهی و مرجع تشدید مشخص کنید. بعد از سه هفته، به جای حدسزدن، با تعداد تصمیمهای معطل و بازکاریهای ایجادشده قضاوت کنید.
این موضوع ارزش کندوکاو بیشتری دارد، مخصوصاً در سازمانهایی که رشدشان از سرعت تصمیمگیریشان جلو زده است. در نوشتههای بعدی، سراغ نمونههای اجراییتر از ثبت تصمیم و مدیریت اختلافهای بینواحدی خواهیم رفت.
