هنوز در بسیاری از جلسات وقتی نام Microsoft Dynamics 365 مطرح می‌شود، اولین واکنش این است: «همان CRM مایکروسافت؟»

پاسخ کوتاه این است: بله، ریشه بخشی از Dynamics 365 به CRM مایکروسافت بازمی‌گردد؛ اما اگر امروز Dynamics را فقط یک CRM ببینیم، بخش مهمی از ظرفیت آن را نادیده گرفته‌ایم.

مایکروسافت در سال ۲۰۱۶ نام Dynamics CRM را کنار گذاشت و Dynamics 365 را معرفی کرد. این تغییر فقط یک Rebranding ساده نبود؛ مسیری بود که خانواده راهکارهای CRM و ERP مایکروسافت را زیر چتر گسترده‌تری از Business Applications قرار داد.

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

تفاوت «نرم‌افزار» و «پلتفرم» دقیقاً همین‌جاست

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

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

Dynamics 365 Customer Engagement از معماری Metadata-driven استفاده می‌کند و امکان توسعه موجودیت‌ها، روابط، فرآیندها و Business Logic را فراهم می‌کند. همین قابلیت است که Dynamics را برای سناریوهایی فراتر از CRM جذاب می‌کند.

از CRM شروع کنیم؛ اما همان‌جا متوقف نشویم

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

چند ماه بعد نیاز دیگری مطرح می‌شود: قراردادها هم باید مدیریت شوند.

Contract به سیستم اضافه می‌شود و با Customer و Opportunity ارتباط پیدا می‌کند. محصولات و خدمات قرارداد، ضمانت‌نامه‌ها، الحاقیه‌ها و وضعیت فاکتور نیز به آن متصل می‌شوند.

کمی بعد مدیریت پروژه مطرح می‌شود. قرارداد موفق، پروژه ایجاد می‌کند و پروژه شامل Task، Milestone، Resource و Issue می‌شود.

حالا Dynamics دیگر فقط CRM نیست. سازمان بدون آنکه الزاماً از ابتدا نرم‌افزار جدیدی ساخته باشد، Contract Management و Project Management را نیز روی همان پلتفرم شکل داده است.

چه سیستم‌هایی می‌توان روی Dynamics 365 ساخت؟

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

برای مثال می‌توان سیستم‌های زیر را روی این بستر طراحی کرد:

  • مدیریت قراردادها: قرارداد، الحاقیه، ضمانت‌نامه، تعهدات، محصولات و وضعیت فاکتور و تحویل
  • مدیریت مناقصات: اسناد مناقصه، کارفرما، ضمانت‌نامه، رقبا، Deadlineها و نتیجه
  • مدیریت پروژه: پروژه، فعالیت، منابع، Milestone، مشکلات و تحویل‌ها
  • خدمات و پشتیبانی: درخواست مشتری، SLA، سوابق خدمات و رضایت مشتری
  • مدیریت تأمین‌کنندگان: Supplier، ارزیابی، قرارداد و سوابق همکاری
  • مدیریت دارایی‌ها: تجهیزات، مالکیت، سرویس‌ها و سوابق نگهداری
  • فرآیندهای خرید و انبار: در سطحی که متناسب با معماری و نیاز سازمان باشد
  • فرآیندهای اختصاصی صنعت: هر جایی که Data، Relationship و Process بخش مهمی از مسئله باشند

حتی حوزه‌هایی مانند مالی یا تولید نیز می‌توانند بسته به Scope پروژه دارای ماژول‌ها و فرآیندهایی روی Dynamics باشند؛ اما اینجا باید با دقت معماری کرد. اگر نیاز سازمان حسابداری تخصصی، MRP یا عملیات عمیق تولید باشد، معمولاً استفاده از ERP یا نرم‌افزار تخصصی و اتصال آن به Dynamics تصمیم حرفه‌ای‌تری از بازسازی همه‌چیز داخل CRM است.

توانایی ساختن یک قابلیت، الزاماً به این معنی نیست که باید آن را بسازیم. بخش مهم معماری Enterprise، تشخیص همین مرز است.

چرا این رویکرد برای سازمان جذاب است؟

مهم‌ترین مزیت، ایجاد یک مدل اطلاعاتی مشترک است.

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

در یک معماری مناسب Dynamics، می‌توان زنجیره‌ای مانند این داشت:

مشتری → فرصت → قرارداد → پروژه → تحویل → خدمات

و اطلاعات مالی یا انبار نیز از طریق Integration به این زنجیره متصل شوند.

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

Dynamics نباید همه سیستم‌های سازمان را ببلعد

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

این رویکرد معمولاً درست نیست.

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

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

از Dynamics تا BI و AI

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

اطلاعات Dynamics می‌توانند در کنار داده‌های مالی، انبار یا سایر سیستم‌ها وارد لایه BI شوند و تصویری مدیریتی از سازمان ایجاد کنند.

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

به همین دلیل ارزش Dynamics در آینده فقط در تعداد Moduleهای آن نیست؛ در این است که می‌تواند یکی از منابع اصلی Context سازمانی برای Analytics و AI باشد.

جمع‌بندی؛ Dynamics را به اندازه CRM کوچک نبینیم

Dynamics 365 می‌تواند یک CRM بسیار قدرتمند باشد، اما ظرفیت آن به مدیریت مشتری محدود نمی‌شود.

قرارداد، مناقصه، پروژه، خدمات، تأمین‌کننده، دارایی و بسیاری از فرآیندهای اختصاصی را می‌توان روی همان معماری توسعه داد و در جایی که سیستم تخصصی مناسب‌تری وجود دارد، به جای بازسازی آن، Integration ایجاد کرد.

برای من، جذاب‌ترین بخش Dynamics دقیقاً همین‌جاست: مسئله دیگر این نیست که «Dynamics چه Featureهایی دارد؟»؛ سؤال جذاب‌تر این است که چه بخشی از معماری دیجیتال سازمان را می‌توان روی این پلتفرم بنا کرد و چه بخش‌هایی باید با آن یکپارچه شوند؟

این تغییر نگاه، Dynamics را از یک CRM به یک Enterprise Business Platform تبدیل می‌کند؛ و دقیقاً از همین نقطه است که طراحی سیستم‌های سازمانی با آن جدی‌تر و جذاب‌تر می‌شود.