وقتی صحبت از Microsoft Dynamics 365 میشود، هنوز برای بسیاری از مدیران اولین تصویری که شکل میگیرد یک CRM است؛ سیستمی برای نگهداری اطلاعات مشتریان، مدیریت فرصتهای فروش، پیگیری فعالیت کارشناسان و ساماندهی خدمات مشتری. این تصویر اشتباه نیست، اما تنها بخشی از ظرفیت واقعی این پلتفرم را نشان میدهد.
در بسیاری از سازمانها، نیازها کمی بعد از راهاندازی CRM از مرز فروش و ارتباط با مشتری عبور میکنند. سازمان میخواهد قراردادهایش را مدیریت کند، مناقصات را زیر نظر داشته باشد، پروژههای مرتبط با قراردادها را کنترل کند، وضعیت تحویل کالا را ببیند، ضمانتنامهها را پیگیری کند و اطلاعات خدمات و پشتیبانی را نیز در همان تصویر قرار دهد. در چنین نقطهای دیگر با یک CRM کلاسیک روبهرو نیستیم؛ پلتفرم آرامآرام در حال تبدیل شدن به بستری برای مدیریت بخش گستردهتری از کسبوکار است.
مفهوم XRM دقیقاً از همین نگاه شکل میگیرد: استفاده از قابلیتهای یک پلتفرم CRM برای مدیریت هر موجودیت، رابطه و فرآیندی که برای کسبوکار اهمیت دارد؛ نه فقط Customer.
XRM چیست و چه تفاوتی با CRM دارد؟
در CRM حرف C از Customer میآید و طبیعی است که مشتری در مرکز مدل قرار داشته باشد. مشتری سرنخ و فرصت فروش دارد، کارشناسان با او فعالیت انجام میدهند، پیشنهاد قیمت صادر میشود و در ادامه خدماتی دریافت میکند.
اما واقعیت یک سازمان معمولاً بسیار گستردهتر از این زنجیره است. قرارداد، پروژه، مناقصه، محصول، تأمینکننده، ضمانتنامه، دارایی، درخواست، صورتوضعیت و دهها مفهوم دیگر ممکن است به اندازه Customer برای کسبوکار اهمیت داشته باشند.
در XRM، حرف X نمادی از همین مفاهیم است. به جای اینکه پلتفرم را فقط حول Customer طراحی کنیم، میتوانیم مدل اطلاعاتی سازمان را گسترش دهیم و روابط واقعی کسبوکار را در آن بازتاب دهیم.
برای نمونه، در یک شرکت پروژهمحور ممکن است مسیر کسبوکار با یک مناقصه آغاز شود. مناقصه در صورت موفقیت به فرصت تجاری و سپس قرارداد تبدیل شود؛ قرارداد یک یا چند پروژه ایجاد کند و هر پروژه نیز شامل فعالیتها، منابع و نقاط تحویل مشخصی باشد. در بخش دیگری از همان سیستم، قرارداد به محصولات، فاکتورها، ضمانتنامهها و وضعیت تحویل متصل باشد.
در نتیجه به جای چند نرمافزار مستقل، با تصویری پیوسته از کسبوکار مواجه میشویم:
این همان جایی است که تفاوت CRM و XRM معنا پیدا میکند. CRM بخشی از این تصویر است؛ XRM تلاش میکند تصویر بزرگتری را روی همان بستر شکل دهد.
وقتی «مدیریت قرارداد» فقط ثبت شماره قرارداد نیست
برای درک بهتر موضوع، مدیریت قرارداد را در نظر بگیریم. در یک CRM ساده ممکن است شماره قرارداد، تاریخ شروع و پایان آن در اطلاعات مشتری ذخیره شود. برای یک سازمان کوچک شاید همین مقدار کافی باشد، اما در یک شرکت قراردادمحور، Contract خود یک مفهوم مستقل و مهم در کسبوکار است.
یک قرارداد میتواند چند محصول یا خدمت داشته باشد، به یک پروژه متصل شود، دارای الحاقیه و ضمانتنامه باشد، چند مرحله تأیید را طی کند، وضعیت صدور فاکتور و تحویل آن مشخص باشد و در طول عمر خود مجموعهای از فعالیتها و تعهدات ایجاد کند.
در معماری XRM، تمام این اطلاعات در یک مدل منسجم کنار یکدیگر قرار میگیرند. مدیر با مشاهده یک قرارداد صرفاً چند فیلد اطلاعاتی نمیبیند؛ میتواند از همان نقطه به مشتری، پروژه، محصولات، فاکتورها، تحویلها، اسناد و فعالیتهای مرتبط برسد.
این تفاوت مهمی است. ما دیگر فرم طراحی نمیکنیم؛ در حال مدلسازی بخشی از واقعیت کسبوکار هستیم.
چرا Dynamics 365 برای پیادهسازی XRM جذاب است؟
مزیت Dynamics 365 فقط در ماژولهای آماده CRM خلاصه نمیشود. بخش مهمی از ارزش آن به معماری قابل توسعه و Metadata-driven پلتفرم بازمیگردد.
میتوان موجودیتها و فیلدهای جدید ایجاد کرد، بین اطلاعات Relationship تعریف کرد، Form و Viewهای مختلف ساخت و سطح دسترسی کاربران را متناسب با ساختار سازمان طراحی کرد. Business Process، Workflow و Business Rule نیز امکان پیادهسازی منطق فرآیندی را فراهم میکنند و در سناریوهای پیچیدهتر میتوان رفتار سیستم را با توسعه اختصاصی و Plugin گسترش داد.
این زیرساخت یک مزیت مهم ایجاد میکند: برای ساخت هر سیستم سازمانی جدید مجبور نیستیم همهچیز را از نقطه صفر آغاز کنیم. بسیاری از اجزایی که یک نرمافزار Enterprise به آنها نیاز دارد، از مدیریت کاربران و Security گرفته تا Audit، Data Model و قابلیت توسعه، در پلتفرم وجود دارند.
از CRM کوچک تا یک پلتفرم سازمانی
یکی از جذابترین ویژگیهای XRM، امکان توسعه تدریجی آن است. سازمان لازم نیست در روز اول پروژهای تعریف کند که قرار باشد تمام بخشهای کسبوکار را یکباره متحول کند.
ممکن است نقطه شروع صرفاً CRM و مدیریت فروش باشد. پس از تثبیت این بخش، مدیریت قراردادها به سیستم اضافه شود. مدتی بعد مناقصات، پروژهها و خدمات وارد همان اکوسیستم شوند و در مراحل بعد ارتباط با سیستم مالی، انبار یا سایر نرمافزارهای سازمان شکل بگیرد.
برای مثال مسیر توسعه میتواند چنین باشد:
- مرحله اول: مشتری، Lead، Opportunity و فرآیند فروش
- مرحله دوم: قرارداد، محصولات قرارداد، الحاقیهها و ضمانتنامهها
- مرحله سوم: مناقصات و ارتباط آنها با فرصتهای تجاری و قراردادها
- مرحله چهارم: پروژهها، فعالیتها، منابع و تحویلها
- مرحله پنجم: خدمات، SLA و پشتیبانی مشتری
- مرحله ششم: Integration با مالی، انبار، BI و سایر سیستمهای سازمان
مزیت چنین رویکردی این است که هر مرحله باید ارزش مستقلی برای سازمان ایجاد کند، اما در عین حال بخشی از معماری بزرگتری باشد که از ابتدا برای رشد طراحی شده است.
به بیان دیگر، Scope اولیه میتواند کوچک باشد، اما Architecture نباید کوتاهمدت طراحی شود.
XRM کجای مسیر میان CRM و ERP قرار میگیرد؟
XRM را نباید با ERP یکسان دانست. ERP معمولاً با هدف یکپارچهسازی عمیق عملیات و منابع اصلی سازمان شکل میگیرد و حوزههایی مانند مالی، خرید، فروش، انبار، تولید و برنامهریزی منابع را با عمق بیشتری پوشش میدهد.
XRM در مقابل، انعطاف زیادی در مدلسازی موجودیتها، روابط و فرآیندهای اختصاصی کسبوکار ایجاد میکند.
| رویکرد | تمرکز اصلی |
|---|---|
| CRM | مشتری، فروش و خدمات |
| XRM | موجودیتها، روابط و فرآیندهای اختصاصی سازمان |
| BPMS | طراحی و اتوماسیون گردش فرآیند |
| ERP | یکپارچگی منابع و عملیات اصلی سازمان |
در یک معماری واقعی ممکن است ERP مسئول مالی، خرید و انبار باشد، در حالی که Dynamics/XRM مشتری، قرارداد، مناقصه، پروژه و خدمات را مدیریت کند. هدف معماری Enterprise این نیست که همه مسائل را به اجبار در یک نرمافزار قرار دهد؛ هدف این است که سیستمهای مختلف بتوانند در یک اکوسیستم منسجم با یکدیگر کار کنند.
ارزش واقعی XRM زمانی مشخص میشود که داده به تصمیم تبدیل شود
اگر Customer، Contract، Project، Product، Tender و Service در یک مدل اطلاعاتی منظم و مرتبط قرار گرفته باشند، ارزش سیستم از ثبت اطلاعات فراتر میرود.
در چنین شرایطی مدیر میتواند بپرسد چه میزان از قراردادهای فعال هنوز فاکتور نشدهاند، کدام پروژهها از برنامه عقب افتادهاند، نرخ موفقیت شرکت در مناقصات چقدر بوده یا کدام مشتریان بیشترین ارزش اقتصادی را ایجاد کردهاند.
در مرحله بعد، همین دادهها میتوانند در Data Warehouse و Power BI قرار گیرند و تصویر مدیریتی گستردهتری از سازمان بسازند.
هوش مصنوعی نیز ادامه طبیعی همین مسیر است. وقتی AI به دادههای ساختارمند و Context واقعی سازمان دسترسی داشته باشد، میتواند وضعیت یک قرارداد را خلاصه کند، پروژههای نیازمند توجه را شناسایی کند، سابقه مشتری را تحلیل کند یا برای یک کارشناس اقدام بعدی را پیشنهاد دهد.
به همین دلیل، شاید یکی از مهمترین اصول در مسیر هوشمندسازی سازمان این باشد:
پیش از آنکه به AI فکر کنیم، باید بدانیم داده و Context مورد نیاز آن کجا و چگونه ساخته میشود.
XRM خوب، مجموعهای از فرمها نیست
یکی از خطرهای توسعه بدون معماری این است که Dynamics پس از چند سال به انباری از Entityها، فیلدها، فرمها و Workflowهای پراکنده تبدیل شود.
یک XRM حرفهای باید حداقل چهار لایه را همزمان ببیند: Data، Process، Security و Integration. اطلاعات باید مدل مناسبی داشته باشند، فرآیندها روی آن مدل حرکت کنند، سطح دسترسیها متناسب با ساختار سازمان طراحی شود و ارتباط با سایر سیستمها نیز از ابتدا بخشی از معماری باشد.
در غیر این صورت، Customization بیشتر الزاماً به معنی سیستم بهتر نیست.
جمعبندی؛ Dynamics را به اندازه CRM محدود نکنیم
XRM بیش از آنکه نام یک محصول باشد، نوعی نگاه به معماری سیستمهای سازمانی است. نگاهی که میگوید لازم نیست برای هر مسئله جدید، نرمافزار جدیدی از صفر ساخته شود و لازم نیست Dynamics نیز برای همیشه در مرزهای CRM باقی بماند.
ممکن است مسیر از Customer و Opportunity آغاز شود، اما به Contract، Tender، Project، Service و دهها مفهوم دیگر برسد. سپس همین پلتفرم با سیستم مالی، انبار، BI و سرویسهای هوش مصنوعی ارتباط برقرار کند و به تدریج بخشی از هسته دیجیتال سازمان را شکل دهد.
قدرت XRM دقیقاً در همین قابلیت رشد نهفته است: از یک مسئله واقعی شروع کنیم، آن را درست حل کنیم و هر مرحله را به قطعهای از معماری بزرگتر سازمان تبدیل کنیم.
به همین دلیل، شاید بهترین توصیف برای یک استراتژی XRM موفق این باشد: کوچک شروع کنیم، مرحلهای توسعه دهیم و از همان ابتدا برای بزرگ شدن معماری کنیم.