آیا می‌توان Dynamics 365 را به سیستم مالی، منابع انسانی و سایر نرم‌افزارهای سازمان متصل کرد؟

Dynamics 365 چقدر قابلیت Integration دارد؟

Dynamics 365 برای توسعه و ارتباط با سایر سیستم‌ها API و Web Service در اختیار توسعه‌دهندگان قرار می‌دهد. در نسخه‌های Customer Engagement، Web API مبتنی بر استاندارد OData و همچنین Organization Service امکان خواندن، ایجاد و تغییر اطلاعات و اجرای عملیات مختلف را فراهم می‌کنند.

اما در عمل مسئله از این هم گسترده‌تر است.

برای اتصال دو سیستم همیشه لازم نیست هر دو طرف API ایده‌آلی داشته باشند. بسته به معماری، امنیت و محدودیت‌های نرم‌افزار مقصد می‌توان از API، Web Service، Database Integration، Middleware، File Exchange، Webhook یا روش‌های دیگری استفاده کرد.

بنابراین سؤال معمولاً این نیست که:

«آیا Dynamics به سیستم X متصل می‌شود؟»

سؤال حرفه‌ای‌تر این است:

«امن‌ترین و پایدارترین معماری برای تبادل اطلاعات میان Dynamics و سیستم X چیست؟»

اتصال Dynamics به نرم‌افزارهای مالی

یکی از متداول‌ترین سناریوها، ارتباط CRM یا XRM با نرم‌افزار مالی و ERP موجود سازمان است.

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

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

برای مثال Dynamics مالک Customer و Contract باشد، در حالی که سیستم مالی مالک سند حسابداری و اطلاعات مالی نهایی است. هنگام تأیید قرارداد، اطلاعات مورد نیاز برای سیستم مالی ارسال شود و در مقابل، وضعیت فاکتور یا پرداخت به Dynamics بازگردد.

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

اصل مهم این است که Integration به معنی کپی کردن بی‌قاعده اطلاعات میان دو Database نیست؛ باید مالکیت داده و جهت حرکت آن مشخص باشد.

اتصال به منابع انسانی و حضور و غیاب

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

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

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

این اصل ساده در معماری Enterprise اهمیت زیادی دارد:

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

اتصال Dynamics به وب‌سایت و پورتال مشتری

وب‌سایت نیز می‌تواند بخشی از همین اکوسیستم باشد.

فرض کنید مشتری در سایت درخواست خدمات ثبت می‌کند. این درخواست می‌تواند مستقیماً در Dynamics به Case تبدیل شود، به کارشناس مربوطه تخصیص داده شود و فرآیند SLA روی آن اجرا شود.

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

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

پیامک، پیام‌رسان و کانال‌های ارتباطی

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

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

در نتیجه کارشناس برای مشاهده تاریخچه تعاملات مشتری مجبور نیست میان چند سامانه جابه‌جا شود.

اتصال Dynamics 365 به هوش مصنوعی

یکی از جذاب‌ترین Integrationهای امروز، ارتباط Dynamics با سرویس‌های AI است.

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

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

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

API بهتر است یا اتصال مستقیم به Database؟

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

اتصال مستقیم به Database نیز در برخی محیط‌های داخلی و سیستم‌های قدیمی اجتناب‌ناپذیر است، اما باید با احتیاط انجام شود؛ به‌خصوص نوشتن مستقیم در Database یک نرم‌افزار Enterprise بدون پشتیبانی رسمی آن می‌تواند Business Logic، Audit و یکپارچگی اطلاعات را مختل کند.

در بسیاری از پروژه‌ها معماری مناسب چیزی شبیه این است:

این لایه واسط می‌تواند Validation، Logging، Retry، Security و تبدیل ساختار داده را نیز مدیریت کند.

Integration فقط انتقال اطلاعات نیست

یکی از تفاوت‌های پروژه Integration خوب و ضعیف همین‌جاست.

فرض کنید مشتری در Dynamics تغییر نام داده است. آیا باید فوراً در مالی نیز تغییر کند؟ اگر سیستم مالی در دسترس نبود چه اتفاقی می‌افتد؟ اگر همان مشتری در سیستم مقصد وجود نداشت چه؟ اگر دو سیستم برای یک مشتری کد متفاوت داشته باشند چه؟

Integration حرفه‌ای باید برای این سؤال‌ها پاسخ داشته باشد.

موضوعاتی مانند Master Data، Mapping، Error Handling، Retry، Logging، Authentication، Synchronization Direction و Conflict Resolution بخشی از معماری Integration هستند.

به همین دلیل اتصال دو سیستم بسیار بیشتر از نوشتن یک API Call است.

تصویر بزرگ‌تر؛ Dynamics به عنوان بخشی از اکوسیستم سازمان

من Dynamics را زمانی جذاب‌تر می‌بینم که قرار نباشد به یک جزیره جدید تبدیل شود.

ممکن است اطلاعات مالی در راهکاران باشد، منابع انسانی در سیستم دیگری، گزارش‌ها در Power BI، وب‌سایت با فناوری دیگری توسعه یافته باشد و سرویس AI نیز کاملاً مستقل اجرا شود. Dynamics لازم نیست جای همه این‌ها را بگیرد.

آنچه اهمیت دارد این است که بتواند با آن‌ها ارتباط برقرار کند و در جای درست معماری قرار گیرد.

جمع‌بندی؛ ارزش Dynamics فقط در خودش نیست

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

Dynamics 365 از این منظر ظرفیت قابل توجهی دارد. می‌تواند با نرم‌افزار مالی، منابع انسانی، انبار، وب‌سایت، تجهیزات، سامانه‌های ارتباطی، BI، هوش مصنوعی و بسیاری از سیستم‌های دیگر ارتباط برقرار کند؛ به شرط آنکه معماری Integration درست طراحی شود.

در تجربه من، سؤال «آیا می‌توان این دو سیستم را به هم وصل کرد؟» معمولاً سؤال دشواری نیست. در اغلب موارد، اگر API، Web Service یا دسترسی مناسب به داده وجود داشته باشد، راه فنی برای اتصال پیدا می‌شود.

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

و شاید همین موضوع یکی از مهم‌ترین تفاوت‌های میان «اتصال دو نرم‌افزار» و طراحی معماری Enterprise باشد.