چرا 3DEXPERIENCE در صنعت ایران به چالش می‌خورد؟

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

این تجربه، پرسش مهمی را مطرح می‌کند: آیا مسئله واقعاً ضعف نرم‌افزار است، یا سازمان تلاش کرده است با فناوری جدید، مشکلاتی را حل کند که ریشه آن‌ها در فرهنگ کاری، ساختار مدیریتی و دانش سازمانی قرار دارد؟

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

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

3DEXPERIENCE می‌تواند قابلیت‌های مهمی در اختیار صنایع قرار دهد، اما بهره‌برداری از این قابلیت‌ها نیازمند چیزی فراتر از خرید مجوز، نصب نرم‌افزار و برگزاری دوره آموزشی است. سازمان باید بتواند به شکل ساختاریافته کار کند، داده‌های معتبر تولید کند، مسئولیت بپذیرد، دانش خود را مستند کند و تصمیم‌های مهندسی را در قالب فرایندهای مشترک پیش ببرد.

در غیر این صورت، خطر آن وجود دارد که یک سامانه پیشرفته به پوششی جدید برای همان مشکلات قدیمی تبدیل شود.

یکی از مهم‌ترین چالش‌های استفاده از سامانه‌های یکپارچه مهندسی، وابستگی فعالیت‌ها به افراد است.

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

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

اگر با جابه‌جایی یک فرد، بخش مهمی از اطلاعات پروژه غیرقابل‌ردیابی شود، سازمان از دانش مهندسی خود به‌درستی محافظت نکرده است.

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

اما این تغییر همیشه آسان نیست.

مهندسی که سال‌ها با روش شخصی خود کار کرده است، ممکن است ثبت اطلاعات، تعریف روابط میان فایل‌ها، رعایت استانداردهای نام‌گذاری و پیروی از گردش کارهای رسمی را اضافه‌کاری بداند. اگر سازمان نتواند مزیت این تغییر را به‌روشنی نشان دهد، مقاومت در برابر سامانه قابل پیش‌بینی خواهد بود.

مسئله این نیست که مهندسان ایرانی توانایی کار گروهی ندارند؛ مسئله این است که در بعضی سازمان‌ها، ساختار انگیزشی، روش ارزیابی عملکرد و شیوه مدیریت، کار انفرادی را ساده‌تر و کم‌هزینه‌تر از همکاری سازمان‌یافته کرده است.

تا زمانی که موفقیت یک مهندس فقط با خروجی فردی سنجیده شود، نمی‌توان انتظار داشت که او بدون انگیزه و سازوکار مناسب، برای موفقیت یک فرایند مشترک وقت صرف کند.

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

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

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

وقتی تغییری در محصول ایجاد می‌شود، ممکن است همه واحدهای مرتبط به‌موقع مطلع نشوند. در نتیجه، خطاهایی رخ می‌دهد که نه به ضعف دانش فنی یک فرد، بلکه به نقص ارتباط میان واحدها مربوط است.

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

نمی‌توان انتظار داشت نرم‌افزار به‌تنهایی این تناقض را حل کند.

اگر واحدها حاضر نباشند مسئولیت داده‌های خود را بپذیرند، اطلاعات را به‌موقع به‌روزرسانی کنند و در تعریف فرایندهای مشترک مشارکت داشته باشند، سامانه جدید صرفاً محل دیگری برای ثبت اطلاعات خواهد بود.

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

یکی از سوءبرداشت‌های رایج در پروژه‌های مهندسی این است که تسلط بر نرم‌افزار CAD به معنای آمادگی برای کار با یک سامانه PLM است.

این دو موضوع به هم مرتبط‌اند، اما یکسان نیستند.

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

در یک محیط PLM، فقط داشتن یک فایل درست کافی نیست. باید مشخص باشد این فایل به کدام محصول تعلق دارد، چه نسخه‌ای از آن معتبر است، چه کسی آن را تأیید کرده، با کدام اسناد مرتبط است و تغییر آن چه تأثیری بر سایر اجزا دارد.

این همان جایی است که دانش داده اهمیت پیدا می‌کند.

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

اما اگر سازمان تفاوت میان فایل، سند، داده ساخت‌یافته و فرایند را درک نکند، پیاده‌سازی یک پلتفرم پیشرفته به‌سرعت با مشکل روبه‌رو خواهد شد.

داده‌های نامنظم، شناسه‌های تکراری، ساختار محصول ناقص و روابط نامشخص میان اسناد، با خرید یک نرم‌افزار جدید خودبه‌خود اصلاح نمی‌شوند.

نرم‌افزار می‌تواند داده‌ها را مدیریت کند، اما نمی‌تواند به‌جای سازمان تصمیم بگیرد که داده معتبر چیست، چه کسی مسئول آن است و چه زمانی باید تغییر کند.

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

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

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

این شیوه ممکن است در کوتاه‌مدت کارها را پیش ببرد، اما در پروژه‌های پیچیده، هزینه پنهان زیادی دارد.

3DEXPERIENCE و سامانه‌های مشابه زمانی می‌توانند ارزش ایجاد کنند که بخشی از این فعالیت‌های پراکنده به فرایندهای قابل‌ردیابی تبدیل شوند. برای مثال، تغییر مهندسی باید مسئول، وضعیت، تأییدیه و اثرات مشخصی داشته باشد.

اگر سازمان تمایلی به تعریف مسئولیت‌ها و رعایت مراحل تأیید نداشته باشد، ممکن است گردش کار نرم‌افزار را مانعی در برابر سرعت کار تلقی کند.

در واقع، مسئله اصلی تعارض میان سرعت و نظم نیست؛ مسئله، تفاوت میان سرعت ظاهری و سرعت واقعی است.

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

گاهی در انتخاب نرم‌افزار، تعداد قابلیت‌ها، گستردگی پلتفرم و پیشرفته‌بودن فناوری به معیار اصلی تبدیل می‌شود.

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

این ترتیب همیشه منطقی نیست.

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

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

در مورد 3DEXPERIENCE نیز نباید تصور کرد که استفاده از تمام قابلیت‌های موجود، الزاماً به معنای بلوغ بیشتر سازمان است.

پیچیدگی فناوری، نشانه بلوغ سازمان نیست؛ توانایی حل مسئله با روشی پایدار، قابل‌اندازه‌گیری و اقتصادی نشانه بلوغ است.

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

در ایران، نوسان نرخ ارز، محدودیت‌های تأمین تجهیزات و دشواری دسترسی به برخی خدمات خارجی نیز می‌توانند ارزیابی اقتصادی پروژه را پیچیده‌تر کنند.

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

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

در این حالت، نرم‌افزار ممکن است از نظر فنی مستقر شده باشد، اما بخش مهمی از ارزش مورد انتظار هنوز تحقق نیافته است.

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

بدون این سنجش، پروژه ممکن است صرفاً به دلیل هزینه‌ای که تاکنون صرف شده است ادامه یابد؛ درحالی‌که تصمیم درست باید بر اساس هزینه و منفعت آینده گرفته شود، نه فقط هزینه‌های گذشته.

یک پلتفرم سازمانی پیچیده به تیمی نیاز دارد که علاوه بر دانش نرم‌افزار، درک مناسبی از مهندسی، مدیریت داده، فرایندهای سازمانی، آموزش و پشتیبانی داشته باشد.

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

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

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

این وابستگی برای سازمان خطرناک است؛ زیرا حتی تغییرات ساده نیز ممکن است به خدمات بیرونی نیاز پیدا کنند.

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

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

این پرسش نباید به یک قضاوت کلی درباره توانایی صنعت ایران تبدیل شود. در کشور، سازمان‌ها و تیم‌های مهندسی با سطوح متفاوتی از تجربه، بلوغ فرایندی و توان فنی فعالیت می‌کنند.

مسئله، ارزیابی واقع‌بینانه آمادگی هر سازمان است.

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

آمادگی تحول دیجیتال مجموعه‌ای از قابلیت‌هاست؛ نه صرفاً خرید تجهیزات و نرم‌افزار.

پیش از اجرای 3DEXPERIENCE باید حداقل چهار حوزه بررسی شوند:

بلوغ فرایندی: آیا روش‌های کاری مشخص، مسئولیت‌های روشن و مسیرهای تأیید تعریف شده‌اند؟

بلوغ داده: آیا اطلاعات مهندسی دارای ساختار، شناسه، نسخه و مالک مشخص هستند؟

بلوغ انسانی: آیا مدیران و کاربران درک مشترکی از هدف پروژه دارند و برای یادگیری روش‌های جدید آماده‌اند؟

بلوغ اجرایی: آیا بودجه، زیرساخت، تیم داخلی و پشتیبانی موردنیاز برای راه‌اندازی و بهره‌برداری فراهم است؟

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

برای کاهش ریسک پروژه‌های 3DEXPERIENCE ، راهکار را باید از سطح سازمان آغاز کرد.

نخست، مسئله واقعی مشخص شود. پروژه باید با هدفی روشن، مانند کنترل نسخه اسناد، مدیریت ساختار محصول یا ردیابی تغییرات مهندسی آغاز شود.

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

سوم، کاربران نهایی در تصمیم‌گیری مشارکت داشته باشند. اگر فرایندها صرفاً توسط مدیران یا مجریان نرم‌افزار طراحی شوند، ممکن است با واقعیت کار روزانه مهندسان سازگار نباشند.

چهارم، پروژه به مراحل کوچک و قابل‌اندازه‌گیری تقسیم شود. هر مرحله باید خروجی عملیاتی، معیار پذیرش و مسئول مشخص داشته باشد.

پنجم، آموزش از انتقال اطلاعات فراتر برود. هدف باید توانایی انجام وظایف واقعی در سامانه باشد، نه صرفاً آشنایی با منوها و قابلیت‌ها.

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

در نهایت، اگر پایلوت نتواند ارزش مورد انتظار را ایجاد کند، باید علت آن بررسی شود. توسعه پروژه بدون ارزیابی نتایج، فقط به این دلیل که هزینه زیادی تا آن زمان صرف شده است، تصمیم منطقی نیست.