پروژههای تحول دیجیتال معمولاً به این دلیل شکست نمیخورند که فناوری مورد استفاده «بهاندازه کافی پیشرفته» نبوده است. مسئله در بسیاری از سازمانها جای دیگری است: پروژه آغاز شده، اما مسئلهای که باید حل کند دقیق نیست؛ مالک نتیجه مشخص نیست؛ چند پروژه بدون اولویت و وابستگی روشن همزمان پیش میروند؛ کاربران برای روش جدید آماده نشدهاند؛ و مدیریت نیز معیاری ندارد که نشان دهد سرمایهگذاری انجامشده واقعاً چه ارزشی ایجاد کرده است.
نتیجه میتواند سازمانی باشد که نرمافزارهای بیشتری دارد، داشبوردهای بیشتری تولید میکند و چند پروژه «تحول» را همزمان پیش میبرد، اما همچنان با همان تأخیرها، تصمیمگیریهای کند، دوبارهکاریها و نارضایتی کاربران مواجه است.
در چارچوب خدمات مشاوره گروه توسعه اقتصادی نگار نیز مسئله بسیاری از برنامههای تحول نه «نبود فناوری»، بلکه نبود اولویت روشن، معماری مشترک، مالکیت اجرایی و سازوکار کنترل تعریف شده است؛ وضعیتی که پروژههای پراکنده ایجاد میکند و تصمیمها را از اجرا و اثر پایدار جدا نگه میدارد.
این مقاله ۹ علت تکرارشونده شکست تحول دیجیتال را بررسی میکند؛ با تمرکز بر مسئلهای که برای مدیرعامل، معاون برنامهریزی و مدیر IT اهمیت بیشتری دارد:
چگونه قبل از هدررفتن بودجه و انرژی سازمان، بفهمیم پروژه تحول در مسیر اشتباه قرار گرفته است؟
شکست تحول دیجیتال دقیقاً چیست و چه مرزی دارد؟
هر تأخیر، تغییر برنامه یا مشکل اجرایی را نمیتوان شکست تحول دیجیتال دانست.
پروژههای سازمانی ذاتاً با تغییر نیاز، محدودیت منابع، ریسک فنی و یادگیری در طول اجرا مواجهاند. حتی ممکن است یک پروژه بخشی از دامنه اولیه خود را تغییر دهد و در نهایت نتیجه بهتری ایجاد کند.
مسئله زمانی جدی میشود که پروژه، با وجود صرف زمان و منابع، نتواند تغییر مورد انتظار در عملکرد سازمان را ایجاد کند.
برای مثال:
سامانه تحویل شده، اما کاربران روش قبلی را ادامه میدهند.
داشبورد ساخته شده، اما تصمیم مدیریتی بر اساس آن تغییر نمیکند.
فرآیند مکانیزه شده، اما زمان انجام یا دوبارهکاری کاهش نیافته است.
راهکار AI توسعه پیدا کرده، اما سناریوی استفاده واقعی ندارد.
پروژه به پایان رسیده، اما کسی نمیتواند بگوید چه شاخصی بهتر شده است.
بنابراین شکست تحول را بهتر است فقط با معیار «تحویل نرمافزار» یا «اتمام قرارداد» نسنجیم.
یک پروژه ممکن است از منظر فنی تحویل شده باشد اما از منظر تحول سازمانی موفق نباشد.
در نگاه گروه توسعه اقتصادی نگار نیز نقطه شروع پروژه باید مسئله واقعی سازمان باشد و خروجی مشاوره و فناوری باید به تصمیم و اقدام قابل اجرا متصل شود؛ نه اینکه خود فناوری هدف نهایی تلقی شود.
مسئله سازمانی پشت شکست تحول؛ پروژههای متعدد بدون مالک، ارزش روشن و پذیرش کاربر
یکی از خطرناکترین وضعیتها زمانی است که سازمان بهظاهر بسیار فعال است.
چند پروژه تحول در جریاناند.
واحد فناوری ERP را توسعه میدهد.
تیم دیگری داشبورد مدیریتی میسازد.
یک پروژه BPM شروع شده است.
مدیریت درباره هوش مصنوعی صحبت میکند.
سامانههای جدید خریداری میشوند.
اما اگر بپرسیم:
کدام مسئله اولویت اول سازمان است؟
کدام پروژه بیشترین ارزش را ایجاد میکند؟
وابستگی این پروژهها به یکدیگر چیست؟
مالک نتیجه هرکدام کیست؟
چه کسی درباره توقف یا تغییر دامنه تصمیم میگیرد؟
موفقیت چگونه اندازهگیری خواهد شد؟
ممکن است پاسخ مشترکی وجود نداشته باشد.
در چنین شرایطی، تحول دیجیتال عملاً به مجموعهای از پروژههای فناوری تبدیل میشود.
۹ علت تکرارشونده شکست پروژههای تحول دیجیتال
۱. پروژه از فناوری شروع میشود، نه از مسئله کسبوکار
یکی از رایجترین خطاها این است که پروژه با یک راهحل از پیش انتخابشده آغاز شود:
«باید ERP جدید بخریم.»
«باید هوش مصنوعی راهاندازی کنیم.»
«باید همه فرآیندها را مکانیزه کنیم.»
«مدیرعامل داشبورد میخواهد.»
اما هنوز معلوم نیست دقیقاً چه مسئلهای باید حل شود.
راه درست جهت معکوس دارد:
مسئله → نتیجه مورد انتظار → فرآیند و داده → راهکار → فناوری
برای مثال، اگر مسئله واقعی «تأخیر در تصمیمگیری درباره عملکرد شرکتهای تابعه» باشد، ممکن است بخشی از راهحل BI باشد؛ بخشی اصلاح فرآیند گزارشدهی؛ بخشی استانداردسازی KPI؛ و بخشی تعیین مسئولیت شرکتها.
شروع مستقیم از ابزار، این احتمال را افزایش میدهد که سازمان یک قابلیت جدید به معماری خود اضافه کند، بدون اینکه علت اصلی مسئله برطرف شود.
در منطق مشترک خدمات مشاوره گروه توسعه اقتصادی نگار نیز نخستین مرحله «فهم مسئله، دامنه و معیار موفقیت» است و طراحی مدل هدف و اجرای فاز اول بعد از تحلیل وضع موجود و شکافها انجام میشود.
2. ارزش پروژه قابل اندازهگیری نیست
گاهی همه میدانند پروژه «مهم» است، اما کسی نمیتواند بگوید موفقیت دقیقاً چه شکلی دارد.
برای مثال:
«بهرهوری بیشتر شود.»
«سازمان دادهمحور شود.»
«خدمات هوشمند شوند.»
«فرآیندها بهبود پیدا کنند.»
این عبارات جهت کلی میدهند، اما برای کنترل پروژه کافی نیستند.
پروژه باید بتواند چند تغییر مشخص را هدف قرار دهد؛ مثلاً:
کاهش زمان چرخه یک فرآیند،
کاهش ورود مجدد اطلاعات،
کاهش زمان تهیه گزارش،
افزایش درصد استفاده کاربران از سامانه،
کاهش خطا،
یا افزایش قابلیت ردیابی یک تصمیم.
بدون معیار ارزش، حتی پروژهای که دامنه فنی خود را تحویل داده است قابل قضاوت نیست.
سازمان نمیداند ادامه دهد، اصلاح کند یا متوقف شود.
در رویکرد گروه توسعه اقتصادی نگار نیز راهبرد زمانی قابل اجرا تلقی میشود که به شاخص، مالک، دوره پایش، آستانه هشدار و اقدام اصلاحی متصل شود.
۳. پروژههای تحول بدون اولویت و وابستگی روشن آغاز میشوند
فرض کنید سازمان همزمان قصد اجرای CRM، BI، AI، BPMS و تغییر بخشی از ERP را دارد.
هر پروژه ممکن است توجیه خوبی داشته باشد.
اما ممکن است BI به داده ERP وابسته باشد.
AI به دسترسی و کیفیت داده وابسته باشد.
مکانیزاسیون فرآیند نیز نیازمند API سامانههای دیگر باشد.
اگر این وابستگیها دیده نشوند، پروژهها مستقل از یکدیگر برنامهریزی میشوند و بعد در حین اجرا به یکدیگر برخورد میکنند.
نتیجه میتواند تأخیر، بازطراحی، هزینه اضافه و اختلاف میان تیمها باشد.
حوزه مشاوره گروه توسعه اقتصادی نگار «سبد پروژههای پراکنده» را یکی از دلایل اصلی نرسیدن برنامههای تحول به نتیجه معرفی میکند: پروژههایی که بدون منطق اولویت، وابستگی و سنجش ارزش آغاز میشوند.
همه پروژههای مهم را نمیتوان همزمان اجرا کرد.
تحول به «انتخاب» نیاز دارد؛ نه فقط تعریف پروژههای بیشتر.
۴. معماری مشترکی بین فرآیند، داده و سامانه وجود ندارد
ممکن است هر پروژه بهتنهایی درست طراحی شده باشد، اما مجموعه پروژهها معماری مشترکی نداشته باشند.
یک سامانه مشتری را با یک شناسه نگهداری میکند.
سامانه دیگر تعریف متفاوتی دارد.
داده در چند نقطه تکرار میشود.
یکپارچهسازیها موردی هستند.
فرآیند از مرز چند سامانه عبور میکند اما هیچکس مالک جریان انتهابهانتها نیست.
نتیجه این میشود که با هر پروژه جدید، پیچیدگی معماری نیز بیشتر میشود.
در گروه توسعه اقتصادی نگار، توسعه جزیرهای سامانه و داده مستقیماً با افزایش هزینه یکپارچهسازی و شکلنگرفتن تصویر مدیریتی قابل اتکا مرتبط دانسته شده است. همچنین معماری تحول باید قابلیت، فرآیند، داده، سامانه، فناوری و امنیت را در یک تصویر اجراپذیر ببیند.
۵. مالک نتیجه و سازوکار تصمیمگیری روشن نیست
پروژه فناوری ممکن است مدیر پروژه داشته باشد، اما این الزاماً به معنای وجود مالک نتیجه کسبوکاری نیست.
برای مثال:
IT سامانه را تحویل میدهد.
مشاور تحلیل را انجام میدهد.
پیمانکار توسعه میدهد.
واحد کسبوکار نیازمندی ارائه میکند.
اما اگر اختلافی درباره فرآیند، KPI یا اولویت ایجاد شود، چه کسی تصمیم نهایی میگیرد؟
اگر کاربران از راهکار استفاده نکنند، چه کسی مسئول نتیجه است؟
اگر نیاز به تغییر دامنه باشد، تصمیم با چه کسی است؟
پروژهای که این سؤالها را پاسخ نداده باشد، معمولاً در نقاط حساس گرفتار تأخیر و تصمیمهای موقت میشود.
حاکمیت مناسب باید حداقل حامی ارشد، مالک کسبوکاری، مدیر پروژه، نقشهای تصمیمگیر و مسیر Escalation را روشن کند.
گروه توسعه اقتصادی نگار نیز در خروجیهای راهبری اجرا بر منشور پروژه، RACI، وضعیت، ریسک، تصمیمهای باز و مسیر Escalation تأکید دارد.
۶. حامی ارشد پروژه فقط در جلسه آغاز حضور دارد
یکی از تفاوتهای مهم میان «حامی پروژه» و «نام یک مدیر در منشور پروژه» این است که حامی واقعی باید در نقاط تصمیم وارد عمل شود.
پروژه تحول معمولاً مرز واحدها را جابهجا میکند.
ممکن است مسئولیتی از یک واحد به واحد دیگر منتقل شود.
ممکن است بعضی مراحل حذف شوند.
ممکن است تعریف یک KPI محل اختلاف باشد.
ممکن است استفاده از روش جدید برای برخی مدیران هزینه یا محدودیت ایجاد کند.
تیم پروژه در بسیاری از این موارد اختیار حل تعارض سازمانی را ندارد.
اینجا حمایت مدیریت ارشد لازم است.
اگر حامی پروژه فقط در Kick-off حضور داشته باشد و تصمیمهای سخت به تعویق بیفتند، تیم پروژه ناچار میشود مسائل سازمانی را با راهحلهای فنی دور بزند.
و معمولاً همان مشکلات بعداً دوباره ظاهر میشوند.
۷. مدیریت تغییر به آموزش نرمافزار در پایان پروژه تقلیل پیدا میکند
تحول دیجیتال روش کار افراد را تغییر میدهد؛ نه فقط صفحهای که روی مانیتور میبینند.
ممکن است اختیار تغییر کند.
شفافیت عملکرد افزایش پیدا کند.
کاری که قبلاً با تماس و هماهنگی شخصی انجام میشد وارد فرآیند رسمی شود.
گزارشهایی که قبلاً در اختیار چند نفر بود برای مدیران دیگر قابل مشاهده شود.
طبیعی است که بخشی از سازمان در برابر چنین تغییراتی مقاومت کند.
مدیریت تغییر فقط برگزاری یک جلسه آموزشی پیش از Go-Live نیست.
باید از قبل مشخص شود:
چه ذینفعانی تحت تأثیر قرار میگیرند؟
نگرانی آنها چیست؟
پیام تغییر چگونه منتقل میشود؟
چه مهارتی لازم دارند؟
چه کسی حامی تغییر در هر واحد است؟
و پذیرش چگونه سنجیده میشود؟
در چارچوب مشاوره گروه توسعه اقتصادی نگار، مدیریت تغییر شامل نقشه ذینفعان، برنامه ارتباطات، آموزش نقشمحور و سنجه پذیرش است؛ و پایینبودن آمادگی کاربران و مدیران میانی یکی از چالشهای صریح پروژههای تحول محسوب میشود.
۸. تحول با دامنهای بیش از ظرفیت سازمان آغاز میشود
یک خطای رایج دیگر، طراحی یک Big Bang بزرگ است:
«همه فرآیندها را اصلاح میکنیم.»
«کل داده سازمان را یکپارچه میکنیم.»
«همه سامانهها را عوض میکنیم.»
«AI را در تمام واحدها اجرا میکنیم.»
روی کاغذ چنین برنامهای جذاب است، اما سازمان ظرفیت محدودی برای جذب تغییر دارد.
تعداد کاربران، توان تیم داخلی، آمادگی داده، بودجه، کیفیت زیرساخت، توان پیمانکار و میزان حمایت مدیران همگی محدودیت ایجاد میکنند.
به همین دلیل دامنه تحول باید با ظرفیت اجرا متناسب باشد.
در روششناسی گروه توسعه اقتصادی نگار نیز صراحتاً تأکید شده که شروع همکاری الزاماً به معنای پروژه بزرگ نیست؛ فاز نخست میتواند بر اساس مسئله اولویتدار و ظرفیت اجرا محدود شود و هدف آن ایجاد خروجی ملموس و قابل پذیرش باشد.
گاهی یک فاز کوچک موفق، بیشتر از یک Master Plan عظیم و اجرانشده برای سازمان ارزش ایجاد میکند.
۹. پروژه با Go-Live تمامشده تلقی میشود
راهاندازی سامانه پایان تحول نیست.
اتفاقاً بخش مهم یادگیری بعد از آن آغاز میشود.
آیا کاربران واقعاً از راهکار استفاده میکنند؟
چه خطاهایی تکرار میشوند؟
کدام بخش فرآیند هنوز دستی است؟
کدام KPI بهتر نشده؟
چه درخواستهای جدیدی شکل گرفته؟
آیا آموزش تکمیلی لازم است؟
اگر پروژه پس از تحویل وارد چرخه پایش و بهبود نشود، بهتدریج فاصله میان «راهکار طراحیشده» و «روش واقعی کار» افزایش پیدا میکند.
در منطق اجرایی گروه توسعه اقتصادی نگار نیز مرحله نهایی صرفاً تحویل نیست؛ توانمندسازی، مالکیت داخلی و بهبود مستمر بخشی از مسیر تحول است.
خلاصه ۹ علت شکست تحول دیجیتال
علت | نشانهای که مدیریت میبیند | اقدام اصلاحی |
شروع از فناوری | راهکار انتخاب شده اما مسئله مبهم است | تعریف مسئله و نتیجه مورد انتظار |
نبود معیار ارزش | موفقیت قابل اثبات نیست | KPI و Baseline |
سبد پروژه پراکنده | همه پروژهها «اولویت بالا» هستند | اولویتبندی و تحلیل وابستگی |
نبود معماری مشترک | یکپارچهسازی پرهزینه و داده متناقض | معماری هدف و اصول مشترک |
مالکیت مبهم | تصمیمها بین IT و کسبوکار معطل میمانند | مالک، RACI و حاکمیت |
حامی ارشد ضعیف | تعارضهای بینواحدی حل نمیشوند | Sponsor فعال و نقاط تصمیم |
مدیریت تغییر ضعیف | کاربران روش قبلی را ادامه میدهند | ذینفع، ارتباطات، آموزش و پذیرش |
دامنه بزرگ | تأخیر و فرسودگی تیم | فازبندی و Quick Win |
پایان پروژه در Go-Live | ارزش راهکار پس از مدتی کاهش مییابد | پایش، Backlog و بهبود مستمر |
مثال سازمانی؛ پنج پروژه تحول، اما یک مسئله حلنشده
فرض کنیم سازمانی با مشکل تأخیر در گزارشدهی و تصمیمگیری مدیریتی روبهرو است.
برای حل مسئله، طی دو سال چند پروژه آغاز میشود:
یک داشبورد BI،
اصلاح ERP،
مکانیزاسیون چند فرآیند،
پرتال سازمانی،
و یک پروژه آزمایشی AI.
هر پروژه تیم و بودجه مستقل دارد.
اما تعریف KPI بین واحدها یکسان نیست.
منابع داده مشخص نشدهاند.
فرآیند تأیید گزارش همچنان دستی است.
مالک تصمیم مدیریتی نیز در طراحی پروژهها حضور مؤثری ندارد.
در نتیجه، داشبورد BI داده متناقض نمایش میدهد.
تیم AI به داده قابل اتکا دسترسی ندارد.
BPMS برای اتصال به ERP منتظر API میماند.
کاربران نیز همچنان گزارش Excel تهیه میکنند.
این سازمان لزوماً با «پنج پروژه بد» مواجه نیست.
مشکل این است که پنج پروژه به یک مسئله مشترک و معماری واحد متصل نشدهاند.
اگر کار از مسئله آغاز میشد، احتمالاً مسیر متفاوت بود:
تعریف تصمیم مدیریتی →
توافق روی KPI →
تعیین مالک داده و فرآیند →
اصلاح منابع اولویتدار →
اجرای یک داشبورد یا فرآیند محدود →
سنجش ارزش →
و سپس توسعه مرحلهای.
این نگاه با جایگاه گروه توسعه اقتصادی نگار بهعنوان مجموعهای که فرآیند، داده، حاکمیت، AI و مشاوره تحول را حوزههای مستقل اما قابل ترکیب میبیند همراستاست؛ هدف، تبدیل اجزای پراکنده سازمان به نظامی یکپارچه، قابل کنترل و قابل توسعه است.
اشتباه رایجتر از شکست پروژه: ادامهدادن پروژهای که باید بازطراحی شود
گاهی بزرگترین ریسک، متوقفشدن پروژه نیست؛ ادامه آن فقط به این دلیل است که قبلاً برایش هزینه شده است.
وقتی نشانههای مشکل ظاهر میشوند، باید امکان چند تصمیم وجود داشته باشد:
ادامه بدون تغییر،
اصلاح دامنه،
تغییر توالی،
اجرای پایلوت محدودتر،
تعلیق،
یا حتی توقف.
برای تصمیم درست، مدیریت به داده و سازوکار کنترل نیاز دارد.
پروژهای که فقط وضعیت «درصد پیشرفت» را گزارش میکند اما درباره ارزش، ریسک، تصمیمهای باز و پذیرش کاربر اطلاعاتی نمیدهد، لزوماً تصویر واقعی سلامت تحول را نمایش نمیدهد.
در چارچوب راهبری اجرای گروه توسعه اقتصادی نگار نیز داشبورد PMO باید علاوه بر وضعیت، ریسک، تصمیم باز و مسیر Escalation را در اختیار مدیریت قرار دهد.
قبل از شروع یا ادامه پروژه تحول، این ۹ سؤال را بپرسید
یک چکلیست ساده مدیریتی میتواند بسیاری از ریسکها را زودتر آشکار کند:
آیا مسئلهای که پروژه باید حل کند در یک یا دو جمله روشن است؟
آیا Baseline و KPI نتیجه مشخص شدهاند؟
آیا مشخص است این پروژه نسبت به سایر پروژهها چه اولویتی دارد؟
آیا وابستگی آن به فرآیند، داده و سامانههای دیگر شناخته شده است؟
آیا یک مالک کسبوکاری مشخص مسئول نتیجه است؟
آیا حامی ارشد در نقاط تصمیم حضور فعال دارد؟
آیا برنامه مدیریت ذینفعان و پذیرش کاربر وجود دارد؟
آیا دامنه پروژه با ظرفیت واقعی سازمان تناسب دارد؟
آیا برای پس از Go-Live چرخه پایش و بهبود تعریف شده است؟
اگر پاسخ چند مورد از این سؤالات مبهم باشد، افزایش سرعت توسعه الزاماً راهحل نیست.
ممکن است لازم باشد خود مسیر تحول بازطراحی شود.
جمعبندی؛ شکست تحول معمولاً قبل از شکست فناوری آغاز میشود
شکست تحول دیجیتال معمولاً زمانی شروع نمیشود که نرمافزار خطا بدهد.
اغلب خیلی زودتر آغاز شده است:
وقتی مسئله دقیق نشده،
ارزش قابل اندازهگیری نیست،
پروژهها اولویت مشترکی ندارند،
معماری پراکنده است،
مالک و حامی روشن نیستند،
کاربران در طراحی تغییر حضور ندارند،
و دامنه اجرا بزرگتر از ظرفیت سازمان است.
فناوری میتواند اجرای یک تحول را ممکن کند؛ اما نمیتواند جای تصمیم مدیریتی، حاکمیت، معماری، مالکیت و مدیریت تغییر را بگیرد.
به همین دلیل شاید مهمترین سؤال مدیرعامل پیش از تصویب یک پروژه تحول این نباشد که:
«این فناوری چه قابلیتهایی دارد؟»
بلکه این باشد:
«دقیقاً کدام نتیجه سازمانی قرار است تغییر کند، چه کسی مالک آن است و چگونه میفهمیم به آن رسیدهایم؟»
اگر پاسخ این سه سؤال روشن باشد، بخش مهمی از مسیر درست از همان ابتدا ساخته شده است.
گام بعدی
شناخت دلایل شکست کافی نیست؛ سازمان باید بتواند پروژههای تحول را در یک مسیر مرحلهای، اولویتبندیشده و قابل کنترل قرار دهد.
ادامه مسیر: «طراحی نقشه راه تحول دیجیتال مرحلهای؛ چارچوب ۷ گام»
سؤالات متداول
بررسی ریسک شکست تحول دیجیتال برای چه سازمانهایی اهمیت بیشتری دارد؟
برای سازمانهایی که چند پروژه فناوری و تحول را همزمان اجرا میکنند، پروژههای قبلی آنها ارزش مورد انتظار را ایجاد نکرده، کسبوکار و IT درباره اولویتها توافق ندارند یا پذیرش کاربران پایین است، این بررسی اهمیت بیشتری دارد. در گروه توسعه اقتصادی نگار نیز پروژههای جزیرهای، نبود اولویت سرمایهگذاری و اختلاف کسبوکار و IT از نشانههای نیاز به معماری و نقشه راه تحول معرفی شدهاند.
مهمترین پیشنیاز کاهش احتمال شکست تحول دیجیتال چیست؟
یک مسئله روشن با مالک و معیار موفقیت مشخص. پیش از انتخاب فناوری باید معلوم باشد چه نتیجهای قرار است تغییر کند، چه کسی مسئول تحقق آن است و موفقیت با چه شاخصی سنجیده میشود.
چه ریسکی باید پیش از شروع کنترل شود؟
شروع همزمان چند پروژه بدون شناخت وابستگی و ظرفیت اجرا، یکی از مهمترین ریسکهاست. در کنار آن، مالکیت مبهم، نبود حامی ارشد، مدیریت تغییر ضعیف و نداشتن Baseline و KPI نیز باید پیش از اجرا کنترل شوند.
برای شروع با دامنه محدود چه گامی پیشنهاد میشود؟
یک مسئله اولویتدار انتخاب کنید که ارزش آن برای مدیریت روشن باشد و بتوان نتیجه آن را در یک فاز محدود مشاهده کرد. وضع موجود، مالک، شاخص، وابستگی و کاربران درگیر را مشخص کنید و بهجای Big Bang، یک فاز اول قابل پذیرش اجرا کنید. منطق خدمات مشاوره گروه توسعه اقتصادی نگار نیز بر تعیین دامنه فاز نخست متناسب با مسئله اولویتدار و ظرفیت اجرا استوار است.
دیدگاهها
نظر یا پرسش خود را درباره این مقاله ثبت کنید.