با وجود اینکه امروزه تب و تاب نرمافزارهای ابری (Cloud) در دنیای فناوری اطلاعات بسیار بالاست، اما واقعیت این است که بسیاری از سازمانهای بزرگ، صنعتی و دولتی در ایران، به دلایل مختلفی مانند محدودیتهای زیرساختی اینترنت، الزامات امنیتی و حفظ حریم خصوصی دادهها، تمایل دارند از نسخه On-Premise (محلی و درونسازمانی) مایکروسافت داینامیکس 365 استفاده کنند.
استقرار نسخه On-Premise داینامیکس، مسیر کاملاً متفاوتی نسبت به نسخه ابری دارد. متاسفانه بسیاری از مدیران ارشد و حتی تیمهای IT، با ذهنیت سیستمهای ابری یا نرمافزارهای حسابداری ساده وارد فرآیند ارزیابی و خرید میشوند. پرسیدن سوالات نادرست در این مرحله، منجر به خرید سختافزارهای نامناسب، شکست پروژه استقرار و هدر رفتن میلیاردها تومان سرمایه میشود.
در این مقاله، بررسی میکنیم که در پروژههای نسخه محلی داینامیکس ۳۶۵، چه سوالاتی اشتباه هستند و شما به عنوان یک تصمیمگیرنده سازمانی، باید دقیقاً چه سوالاتی را از تامینکننده و مجری بپرسید.
بخش اول: سوالات اشتباه فنی و زیرساختی (مختص نسخه On-Premise)
در نسخه On-Premise، سازمان خودش میزبان (Host) نرمافزار است. بنابراین، دانش زیرساختی در اینجا حرف اول را میزند.
۱. آیا میتوانیم داینامیکس را روی همان سرورهای فعلی شرکت خودمان نصب کنیم؟
چرا اشتباه است؟ داینامیکس ۳۶۵ یک نرمافزار سنگین سازمانی (Enterprise) است. سرورهایی که در حال حاضر میزبان نرمافزارهای حسابداری، فایلسرور یا دیتابیسهای سبک شما هستند، از نظر پردازنده (CPU)، حافظه رم (RAM) و به ویژه سرعت دیسکها (که حتماً باید از نوع SSD یا NVMe باشند) توان اجرای این سیستم را ندارند. سوال درست: «برای استقرار نسخه On-Premise داینامیکس با توجه به تعداد کاربران همزمان و حجم دادههای ما، معماری پیشنهادی شما برای سرورهای دیتابیس (SQL Server) و سرورهای اپلیکیشن (AOS) چیست و مشخصات سختافزاری دقیق آنها چه باید باشد؟»
۲. آیا برای کار با داینامیکس On-Premise به اینترنت نیاز داریم؟
چرا اشتباه است؟ پرسیدن این سوال نشان میدهد که مفهوم سیستمهای مبتنی بر وب (Web-based) در شبکه داخلی (Intranet) را به درستی درک نکردهاید. خیر، برای کار روزمره نیازی به اینترنت جهانی نیست، اما نیازمند یک شبکه داخلی پایدار و پرسرعت هستید. سوال درست: «برای دسترسی بیوقفه کاربران به سیستم در شبکه محلی، چه زیرساخت شبکهای (سوئیچها، کابلکشی، پهنای باند داخلی و پایداری سرورهای دامین) نیاز است تا سیستم دچار تاخیر (Latency) نشود؟»
۳. آیا داینامیکس روی سیستمعامل مک (Mac) کار میکند؟
چرا اشتباه است؟ بله، چون رابط کاربری داینامیکس از طریق مرورگر وب اجرا میشود. اما تمرکز مدیران IT باید روی سازگاری مرورگرها و تنظیمات امنیتی مرورگر در شبکه داخلی باشد، نه صرفاً سیستمعامل سختافزار کاربر. سوال درست: «آیا مرورگرهای استاندارد موجود در سازمان ما (مثل Chrome یا Edge) برای اجرای رابط کاربری داینامیکس بدون مشکل پلاگینها و ActiveXهای قدیمی تنظیم هستند؟»
۴. آیا برنامهنویس داخلی ما میتواند مدیریت سرور و دیتابیس داینامیکس را بر عهده بگیرد؟
چرا اشتباه است؟ مدیریت دیتابیس داینامیکس (SQL Server Enterprise) و معماری سرورهای AOS نیازمند تخصصهای سطح بالا در مایکروسافت (مانند گواهینامههای MB-300 یا مشابه آن در بخش زیرساخت) است. واگذاری این بخش به یک ادمین شبکه عمومی، امنیت و پایداری کل سیستم را به خطر میاندازد. سوال درست: «برای مدیریت روزمره زیرساخت داینامیکس در داخل سازمان، چه سطحی از آموزش (مثلاً دورههای مدیریت SQL Server در محیط ERP) برای تیم IT ما نیاز است و چه وظایف حیاتی باید حتماً با قرارداد پشتیبانی به مجری واگذار شود؟»
۵. آیا میتوانیم سورس کد (Source Code) داینامیکس را مستقیماً تغییر دهیم؟
چرا اشتباه است؟ در نسخه On-Premise، برخلاف نسخه ابری، شما دسترسی بیشتری به کدها دارید؛ اما تغییر مستقیم سورس کد هسته (Over-layering) بزرگترین گناه در استقرار داینامیکس است، زیرا در آپدیتهای بعدی باعث ناسازگاری شدید میشود. سوال درست: «با توجه به اینکه در نسخه محلی امکان توسعه وجود دارد، چگونه میتوانیم منطق تجاری اختصاصی خود را از طریق افزونهها (Extensions) و مدلهای استاندارد مایکروسافت پیاده کنیم تا در آپدیتهای نسخههای بعدی با مشکل مواجه نشویم؟»
۶. آیا داینامیکس ۱۰۰٪ در برابر هک ایمن است چون روی سرور خودمان است؟
چرا اشتباه است؟ دیتاسنترهای مایکروسافت لایههای امنیتی بینظیری دارند. وقتی شما سیستم را روی سرور خودتان میگذارید، تامین امنیت فیزیکی سرور، فایروالهای شبکه، آنتیویروسهای سازمانی و جلوگیری از حملات داخلی (Insider Threats) کاملاً به عهده خود شماست. سوال درست: «برای استقرار داینامیکس در سرور داخلی، چه معماری امنیتی (شامل فایروالهای نسل جدید، ایزولهسازی شبکه، و پشتیبانگیریهای پنهان (Snapshot) از دیتابیس) پیشنهاد میکنید تا امنیت دادهها تضمین شود؟»
۷. آیا بهروزرسانیهای (Updates) مایکروسافت به صورت خودکار روی سرور ما نصب میشود؟
چرا اشتباه است؟ در نسخه ابری آپدیتها خودکارند، اما در نسخه On-Premise، هیچ آپدیتی نباید به صورت خودکار و بدون کنترل روی سرور سازمان اعمال شود. آپدیتهای داینامیکس در نسخه محلی نیازمند یک “پروژه مهاجرت نسخه” هستند. سوال درست: «فرآیند ارتقا نسخه (Version Upgrade) در محیط On-Premise ما چگونه مدیریت میشود؟ هزینه و زمان لازم برای پروژه ارتقا از نسخه فعلی به نسخههای جدیدتر مایکروسافت چقدر برآورد میشود؟»
۸. زبان برنامهنویسی داینامیکس چیست؟ آیا با زبانهای قدیمی ما سازگار است؟
چرا اشتباه است؟ داینامیکس از زبان X++ در لایه هسته و C# در لایههای توسعه استفاده میکند. مقایسه آن با سیستمهای قدیمی بیفایده است. مهم این است که بدانید توسعه در این سیستم چقدر سریع و استاندارد است. سوال درست: «برای پیادهسازی فرآیندهای سفارشی در آینده، آیا مجری ما از ابزارهای کمکد (Low-Code) و Power Platform در کنار محیط توسعه اصلی استفاده میکند تا وابستگی به برنامهنویسان ارشد کاهش یابد؟»
۹. آیا میتوانیم تمام دادههای ۲۰ ساله سیستم قدیمیمان را دقیقاً به همان شکل در داینامیکس بریزیم؟
چرا اشتباه است؟ انتقال کورکورانه دادهها به یک دیتابیس قدرتمند اما آشفته، فقط زبالههای دیجیتال شما را در محیط جدید تکثیر میکند. پاکسازی دادهها در نسخه On-Premise به دلیل حجم بالای دیتابیس، بسیار حیاتیتر است. سوال درست: «روند استاندارد پاکسازی، تبدیل فرمت (Data Mapping) و انتقال دادههای master (کالاها، مشتریان، حوالههای انبار باز) به دیتابیس جدید داینامیکس چقدر زمان میبرد و چه ابزارهایی (مثل DMF) برای این کار استفاده میشود؟»
۱۰. آیا داینامیکس با هر نرمافزار دیگری در شبکه داخلی ۱۰۰٪ یکپارچه میشود؟
چرا اشتباه است؟ یکپارچگی در محیط On-Premise معمولاً از طریق وبسرویسها (OData), API یا ارتباط مستقیم با دیتابیس لینک انجام میشود که هر کدام ریسکهای فنی خود را دارند. سوال درست: «با توجه به سیستمهای سختافزاری و نرمافزاری موجود در سازمان ما (مثل دستگاههای بارکد، سیستمهای اتوماسیون یا ماشینآلات تولید)، مکانیزمهای یکپارچگی (Integration) در شبکه محلی چیست و چگونه پایداری آنها تضمین میشود؟»
بخش دوم: سوالات اشتباه درباره زمانبندی و فرآیند استقرار
نسخه On-Premise معمولاً پیچیدگیهای فنی بیشتری در زمان استقرار دارد و نیازمند نگاهی مهندسیشدهتر است.
۱۱. استقرار داینامیکس روی سرورهای ما دقیقاً چند ماه طول میکشد؟
چرا اشتباه است؟ اعلام زمان قطعی پیش از شروع تحلیل دقیق فرآیندها و بررسی زیرساخت سرورهای شما، یک فریب تجاری است. استقرار On-Premise به دلیل تنظیمات سرور، معمولاً زمانبرتر از نسخه ابری است. سوال درست: «با فرض اینکه زیرساخت سختافزاری ما تامین شده باشد و ما در تامین دادهها همکاری کامل داشته باشیم، برآورد زمانی بر اساس متدولوژی Agile (به تفکیک فازهای تحلیل، توسعه، تست و راهاندازی) چقدر است؟»
۱۲. آیا میشود آخر هفته سیستم را روی سرور نصب کرد و دوشنبه با آن کار کنیم؟
چرا اشتباه است؟ داینامیکس یک نرمافزار نیست که با(next-next-finish) نصب شود! نصب روی سرور فقط ۱٪ کار است؛ ۹۹٪ مابقی شامل پیکربندی سازمان (Organization Setup)، تعریف ساختار قانونی، طراحی فرمها و ورود دادههاست. سوال درست: «مراحل حیاتی پیش از راهاندازی نهایی (Go-Live) شامل تستهای یکپارچگی سرور، تست بارگذاری (Load Testing) و تست پذیرش کاربران (UAT) در شبکه داخلی چقدر زمان میبرد؟»
۱۳. آیا برای اجرای داینامیکس باید فرآیندهای شرکت خود را کاملاً تغییر دهیم؟
چرا اشتباه است؟ تغییر ۱۰۰٪ فرآیندها باعث مقاومت شدید کاربران میشود. اما در نسخه محلی چون امکان تغییر کد وجود دارد، برخی مجریان سعی میکنند سیستم را دقیقاً شبیه سیستم خراب قبلی شما بکنند! این یک فاجعه است. سوال درست: «چگونه در فرآیند استقرار، بین بهترین شیوههای صنعتی (Best Practices) موجود در داینامیکس و نیازهای خاص سازمان ما، تعادل منطقی ایجاد میکنید تا نیازی به تغییرات مخرب کد (Over-layering) نباشد؟»
۱۴. میخواهیم داینامیکس دقیقاً مثل سیستم قبلی ما کار کند، ممکن است؟
چرا اشتباه است؟ اگر سیستم جدید دقیقاً مثل سیستم قبلی کار کند، چرا باید هزینه میلیارد تومانی برای سرور و داینامیکس 365 بدهید؟ هدف مهاجرت ارتقای سطح عملکرد است. سوال درست: «سیستم قبلی ما چه نقاط ضعفی داشته که داینامیکس با ویژگیهای استاندارد خود آنها را بهبود میبخشد و ما از چه روشهایی برای توجیه تغییر فرهنگ سازمانی به سمت این سیستم جدید استفاده کنیم؟»
۱۵. آیا مجری باید همه کارها را انجام دهد و ما فقط نتیجه را ببینیم؟
چرا اشتباه است؟ در نسخه On-Premise، تیم های شما باید به شدت درگیر باشد تا معماری سرورها و دیتابیسها را یاد بگیرد. اگر تیم شما فقط تماشاگر باشد، روزی که مجری پروژه را ترک کند، سیستم فلج میشود. سوال درست: «تعهدات و زمان مورد نیاز همکاران ما (به ویژه تیم IT و کارشناسان ارشد حوزهها) در طول پروژه برای انتقال دانش (Knowledge Transfer) چقدر است؟»
۱۶. چرا برای آموزش کاربران وقت زیادی در نظر میگیرید؟
چرا اشتباه است؟ راحتی رابط کاربری به معنای درک منطق پیچیده تجاری پشت آن نیست (مثلاً تاثیر یک تراکنش انبار بر حسابداری). در نسخه محلی که پشتیبانی آنلاین ۲۴ ساعته مایکروسافت وجود ندارد، آموزش کاربران برای عیبیابی اولیه حیاتیتر است. سوال درست: «برنامه آموزشی شما شامل چه سطوحی است (آموزش فرآیندها، آموزش عملی، و آموزش نحوه مدیریت خطاهای رایج روزمره) و چگونه میزان تسلط کاربران را قبل از Go-Live میسنجید؟»
۱۷. آیا میتوانیم در روز اول، تمام ماژولها (مالی، انبار، تولید) را همزمان روی سرور راهاندازی کنیم؟
چرا اشتباه است؟ راهاندازی همزمان (Big Bang) ریسک فوقالعاده بالایی دارد، زیرا در نسخه On-Premise در صورت بروز باگ در یک ماژول، بازگشت به عقب (Rollback) دیتابیس بسیار پیچیده و زمانبر است. سوال درست: «آیا رویکرد فازبندی شده (مثلاً شروع با ماژول مالی و انبار، و سپس اضافه کردن ماژول تولید) برای کاهش ریسک کریتیکال شدن سیستم در سازمان ما مناسبتر نیست؟»
۱۸. اگر پروژه شکست خورد، جریمه میدهید؟
چرا اشتباه است؟ هیچ مجری معتبر Macro disrupted Project را با ضمانت مالی مطلق نمیپذیرد، زیرا متغیرهایی مثل تامین به موقع سختافزار توسط شما یا مقاومت کاربران در کنترل او نیست. سوال درست: «مکانیزمهای مدیریت ریسک شما در قرارداد چیست؟ اگر در میانه راه مشخص شود که سختافزار خریداری شده توسط ما جوابگو نیست، چگونه مسیر پروژه را اصلاح میکنید؟»
بخش سوم: سوالات اشتباه درباره نیازهای کسبوکار و قابلیتها
سیستم باید پاسخگوی مشکلات واقعی سازمان باشد، نه صرفاً یک تکه کد زیبا روی سرور.
۱۹. آیا داینامیکس ویژگی X را دارد؟
چرا اشتباه است؟ پرسیدن صدها سوال بله/خیر درباره لیست ویژگیها (Feature-list) باعث گمراهی میشود. ممکن است ویژگی وجود داشته باشد، اما با منطق سازمان شما همخوانی نداشته باشد. سوال درست: «ما در فرآیند انبار خود با چالش Y مواجهیم. داینامیکس چگونه این چالش را از طریق ماژولهای مدیریت زنجیره تامین (Supply Chain Management) حل میکند؟»
۲۰. آیا میتوانید دقیقاً کاری کنید که داینامیکس خروجی اکسل ما را شبیهسازی کند؟
چرا اشتباه است؟ شما برای رهایی از محدودیتهای اکسل CRM/ ERP روی سرور خودتان نصب میکنید! خواستار شبیهسازی یک سیستم دستی در یک سیستم هوشمند بودن، پول سختافزار را دور میریزد. سوال درست: «داینامیکس چه داشبوردهای مدیریتی و گزارشهای تعاملی (مثل SSRS یا Power BI) به صورت استاندارد روی سرور ما ارائه میدهد که جایگزین گزارشهای دستی اکسل شود؟»
۲۱. آیا داینامیکس بهترین نرم افزار CRM/ ERP دنیاست؟
چرا اشتباه است؟ “بهترین” واژهای بیمعنی در دنیای CRM ERP است. داینامیکس ممکن است برای یک کارخانه خاص مناسب نباشد، اما برای یک شرکت پخش مویرگی بیرقیب باشد. سوال درست: «دلیل اینکه معماری On-Premise داینامیکس نسبت به رقبا برای نوع صنعت ما و شرایط زیرساختیمان مناسبتر است، چیست؟»
۲۲. آیا با نصب این سیستم روی سرور، فروش ما به طور خودکار چند برابر میشود؟
چرا اشتباه است؟ نرمافزار یک ابزار است، نه یک جادو. داینامیکس فرآیند فروش را شفاف میکند، اما فروش نیازمند استراتژی انسانی است. سوال درست: «داینامیکس چگونه میتواند با حذف فرآیندهای تکراری و ارائه دیدگاه ۳۶۰ درجه از مشتری در شبکه داخلی، بهرهوری تیم فروش ما را افزایش دهد؟»
۲۳. آیا میشود قابلیتهایی که دوست نداریم را از روی سرور پاک کنیم تا سیستم ساده شود؟
چرا اشتباه است؟ پاک کردن کدهای هسته از روی سرور غیرممکن و خطرناک است. اما میتوانید از طریق مدیریت نقشهای کاربری (Security Roles)، دسترسی به فرمها را برای کاربران مخفی کنید. سوال درست: «چگونه میتوانیم از طریق شخصیسازی رابط کاربری و مدیریت دقیق دسترسیهای امنیتی در شبکه داخلی، محیط کاری را برای هر گروه از کاربران ساده و اختصاصی کنیم؟»
۲۴. آیا با خرید داینامیکس، دیگر به برخی از کارمندان نیاز نداریم؟
چرا اشتباه است؟ ERP و CRM جایگزین تفکر انسانی نمیشود. داینامیکس عملیات دستی را خودکار میکند تا افراد به جای ورود داده، به تحلیل مالی بپردازد. سوال درست: «داینامیکس چگونه اتوماسیون فرآیندهای مالی (مثل تسویه خودکار، تطبیق بانکی) را انجام میدهد تا نقش تیم مالی یا بقیه از عملیاتی به تحلیلی ارتقا یابد؟»
۲۵. آیا این نرم افزار مدیریت ضعیف ما را اصلاح میکند؟
چرا اشتباه است؟ نرمافزار نمیتواند جایگزین رهبری شود. اگر مدیران بخواهند فرآیندها را دور بزنند (مثلاً جنس را بدون ثبت در سیستم از انبار خارج کنند)، داینامیکس روی سرور شما هم نمیتواند جلوی آنها را بگیرد، مگر اینکه سختافزارهای کنترلی (مثل بارکدخوان) به آن متصل شود. سوال درست: «داینامیکس چگونه از طریق گردش کار (Workflow) و یکپارچگی با سختافزارهای عملیاتی (مثل PLCها یا بارکدخوانها)، شفافیت ایجاد کرده و از بروز تخلفات جلوگیری میکند؟»
۲۶. آیا رنگ دکمهها و ظاهر فرمها را دقیقاً میتوانید شبیه برند ما کنید؟
چرا اشتباه است؟ تمرکز بیش از حد بر ظاهر در نسخه On-Premise باعث اتلاف بودجه و ایجاد مشکلات فنی در پشتیبانی میشود. سوال درست: «تا چه حد میتوانیم لوگوی شرکت و تم کلی را بدون ایجاد مشکل در پایداری سیستم و آپدیتهای آتی، در داینامیکس اعمال کنیم؟»
بخش چهارم: سوالات اشتباه در انتخاب فروشنده/مجری (Partner)
در نسخه On-Premise، نقش مجری به مراتب خطرناکتر و حیاتیتر از نسخه ابری است، زیرا او تمام بار فنی سرورها و کدها را به عهده میگیرد.
۲۷. آیا شما خودتان مایکروسافت هستید؟
چرا اشتباه است؟ مایکروسافت تولیدکننده نرمافزار است و معمولاً مستقیماً استقرار On-Premise را برای شرکتها انجام نمیدهد. این سوال نشاندهنده عدم آشنایی با اکوسیستم مایکروسافت است. سوال درست: « آیا تخصص اصلی شما دقیقاً روی استقرار نسخه محلی (On-Prem) داینامیکس است؟»
۲۸. تا به حال چند تا داینامیکس فروختهاید؟
چرا اشتباه است؟ تعداد فروش نشاندهنده قدرت بازاریابی است. در نسخه On-Premise، مهم این است که چند پروژه با موفقیت روی سرور مشتری راهاندازی کرده و پایدار نگه داشتهاید. سوال درست: «چند پروژه استقرار نسخه On-Premise داینامیکس با موفقیت به مرحله بهرهبرداری رساندهاید و آیا میتوانیم با مدیران شرکتهایی که پروژههای مشابه ما را انجام دادهاید صحبت کنیم؟»
۲۹. آیا میتوانید قبل از امضای قرارداد، یک دمو از سیستم کامل روی سرور خودتان به ما نشان دهید؟
چرا اشتباه است؟ دمو کردن سیستمِ “کاملاً پیادهسازی شده برای سازمان شما” قبل از شروع پروژه غیرممکن است. دموهای آماده فقط جنبه تبلیغاتی دارند. سوال درست: «آیا میتوانید یک سناریوی تجاری پیچیده مشابه صنعت ما را در یک محیط تست (شبیهسازی شده روی سرور خودتان) طی کنید تا درک ما از ظرفیتهای سیستم و معماری آن بالا برود؟»
۳۰. آیا در کل مدت پروژه، همان مشاور ارشدی که در جلسه حضور دارد با ما کار خواهد کرد؟
چرا اشتباه است؟ این یک تله فروش است. معمولاً مدیران ارشد برای جذب پروژه میآیند و پس از امضای قرارداد، پروژه به سایر نیروها سپرده میشود. سوال درست: «ساختار تیمی که به پروژه ما (با تمرکز بر زیرساخت و کدنویسی) اختصاص مییابد دقیقاً چگونه است؟ رزومه معمار سیستم (Solution Architect) و توسعهدهندگان ارشد شما چیست و میزان درگیری ساعتی شان چقدر است؟»
۳۱. چرا نباید یک برنامهنویس فریلنسر را استخدام کنیم تا داینامیکس را برایمان روی سرور راهاندازی کند؟
چرا اشتباه است؟ فریلنسرها هیچ تعهدی به کیفیت بلندمدت، مستندسازی معماری سرور و پشتیبانی در بحرانهای دیتابیس ندارند. در نسخه محلی، اگر فریلنسر قطع همکاری کند، سازمان شما در یک بحران بیسرپرست خواهد ماند. سوال درست: «ارزش افزودهای که یک شرکت مجری رسمی (با تیم تخصصی چندنفره شامل ادمین سرور، دیتابیس من، مشاور فرآیند و توسعهدهنده) برای یک سیستم حیاتی On-Premise ایجاد میکند، دقیقاً چیست؟»
۳۲. اگر مشاور پروژه یا برنامهنویس کلیدی شما استعفا داد چه میشود؟
چرا اشتباه است؟ افراد مستعد ممکن است جابجا شوند. مهم این است که “دانش فنی و معماری سرور/کد” نزد مجری به صورت مستند شده باشد، نه فقط در ذهن یک نفر. سوال درست: «سیاست مدیریت دانش (Knowledge Management) و مستندسازی فنی (توسعهها و تنظیمات سرور) شما در طول پروژه چگونه است که در صورت تغییر نیروی کلیدی، پروژه دچار وقفه نشود؟»
۳۳. آیا پشتیبانی ۲۴ ساعته در ۷ روز هفته (24/7) با تلفن به ما میدهید؟
چرا اشتباه است؟ در نسخه On-Premise، شما صاحب سرور هستید. انتظار پشتیبانی ۲۴/۷ تلفنی از مجری غیرمنطقی است، مگر اینکه قراردادهای بسیار گرانقیمت (SLA سطح ۱) ببندید. بیشتر مشکلات روزمره باید توسط تیم IT خودتان مدیریت شود. سوال درست: «ساعات پشتیبانی استاندارد شما چیست؟ برای مواقع بحرانی (مثل قطع شدن سرویسهای AOS یا دیتابیس در شب) مکانیزم دسترسی اورژانسی شما چگونه تعریف شده است؟»
۳۴. آیا تضمین مینویسید که همه کاربران ما از سیستم راضی باشند؟
چرا اشتباه است؟ رضایت ۱۰۰٪ کاربران در هر پروژه تغییر، یک توهم است. مجری نمیتواند احساسات و مقاومت روانشناختی کاربران در برابر یادگیری یک سیستم پیچیده را تضمین کند. سوال درست: «استراتژی شما برای مدیریت تغییر (Change Management) و کاهش مقاومت کاربران در برابر سیستم جدید چیست و چگونه میخواهید پذیرش (Adoption) سیستم را در سازمان تضمین کنید؟»
۳۵. چرا نباید یک نرم افزار ایرانی ارزانتر بخریم که نیاز به سرور قدرتمند ندارد؟
چرا اشتباه است؟ مقایسه یک نرم افزارCRM ERP ایرانی محلی (که معمولاً برای کسبوکارهای خرد و متوسط طراحی شدهاند) با یک پلتفرم جهانی مانند داینامیکس که روی معماری چندلایه پیچیده اجرا میشود، نامنصفانه است. سوال درست: «تفاوتهای کلیدی معماری داینامیکس (شامل قابلیت توسعه عمیق، یکپارچگی با سختافزارهای صنعتی، قدرت دیتابیس در حجم کلان داده و پشتیبانی از زنجیره تامین پیچیده) نسبت به راهکارهای بومی چیست که توجیه خرید سختافزارهای گرانقیمت را کند؟»
۳۶. آیا میتوانید پشتیبانی سالهای بعد را رایگان انجام دهید؟
چرا اشتباه است؟ پشتیبانی یک سیستم On-Premise شامل مانیتورینگ سرورها، پشتیبانگیری، رفع باگهای نرمافزاری و مشاوره فرآیندی است. این یک “خدمت مستمر” است که هزینه دارد. درخواست رایگان بودن آن باعث افت شدید کیفیت در بلندمدت میشود. سوال درست: «بستههای مختلف پشتیبانی شما پس از پایان گارانتی اولیه شامل چه سطوحی است (مثلاً شامل پشتیبانی زیرساخت یا فقط نرمافزار) و چگونه میتوانیم با خرید یک SLA مناسب، پایداری سیستم روی سرورهای خودمان را تضمین کنیم؟»
نتیجهگیری: رویکرد متفاوت برای نسخه محلی (On-Premise)
خرید و استقرار نسخه On-Premise مایکروسافت داینامیکس 365، یک پروژه صرفاً نرمافزاری نیست؛ بلکه یک پروژه زیرساختی-مهندسی است. همانطور که در این ۳۶ مورد بررسی کردیم، سازمانهایی که با رویکرد سیستمهای سبک یا ابری وارد این مسیر میشوند، معمولاً با چالشهای عظیم در پایداری سرور، هزینههای پنهان سختافزاری و شکست در یکپارچگی مواجه میگردند.
برای اینکه استقرار نسخه محلی داینامیکس برای شما یک موفقیت بزرگ باشد، به این ۳ اصل عمل کنید:
- زیرساخت را جدی بگیرید: در پروژه On-Premise، سرورها و شبکه داخلی شما قلب تپنده سیستم هستند. روی خرید سختافزار استاندارد و پیشنهادهای ادمینهای حرفهای سرمایهگذاری کنید.
- از تغییرات کد (Over-layering) فرار کنید: بزرگترین تله نسخه محلی، امکان تغییر مستقیم کدهاست. اصرار کنید که مجری تمام نیازمندیها را از طریق افزونههای استاندارد (Extensions) پیاده کند تا آپدیتهای آینده میسر باشد.
- انتقال دانش به تیم IT خود را الزامی کنید: چون سرورها در اختیار شماست، تیم IT داخلی شما باید به خوبی معماری سیستم، ساختار دیتابیس و مدیریت لاگها را یاد بگیرد. وابستگی ۱۰۰٪ به مجری خارجی در نسخه On-Premise یک خطر بزرگ امنیتی و عملیاتی است.
بدون دیدگاه