یکی از تصمیمهای دشوار مدیران در مسیر تحول دیجیتال، انتخاب سیستم مناسب برای سازمان است. آیا باید فرآیندها را با BPMS مکانیزه کنیم؟ یک CRM راهاندازی کنیم؟ Dynamics 365 را با رویکرد XRM توسعه دهیم؟ یا از ابتدا به سراغ یک ERP جامع برویم؟
پاسخ این سؤال را نمیتوان تنها با مقایسه Feature List چند نرمافزار پیدا کرد. پیش از انتخاب محصول، باید مسئله مهمتری را روشن کنیم: سازمان امروز در چه سطحی از بلوغ فرآیندی و سیستمی قرار دارد و میخواهد طی سه تا پنج سال آینده به چه نقطهای برسد؟
CRM، BPMS، XRM و ERP در ظاهر همگی «نرمافزار سازمانی» هستند، اما از چهار زاویه متفاوت به کسبوکار نگاه میکنند. BPMS از فرآیند آغاز میکند، CRM مشتری را در مرکز قرار میدهد، XRM موجودیتها و روابط اختصاصی کسبوکار را وارد تصویر میکند و ERP تلاش میکند منابع و عملیات اصلی سازمان را در سطحی گستردهتر یکپارچه سازد.
بنابراین مسئله اصلی انتخاب میان چهار نام نیست؛ مسئله، طراحی مسیر بلوغ دیجیتال سازمان است.
BPMS؛ اولین قدم برای خروج از فرآیندهای دستی
در بسیاری از سازمانها نقطه شروع تحول دیجیتال بسیار ساده است. درخواست خرید هنوز در Excel ثبت میشود، مرخصی از طریق پیامرسان هماهنگ میشود، تأیید مدیران در ایمیلها گم میشود و برای فهمیدن وضعیت یک درخواست باید با چند نفر تماس گرفت.
در چنین محیطی BPMS میتواند ارزش زیادی ایجاد کند. فرآیند تعریف میشود، مسئول هر مرحله مشخص است، تأییدها ثبت میشوند، SLA قابل اندازهگیری میشود و مدیر میتواند ببیند هر درخواست دقیقاً در چه مرحلهای قرار دارد.
اما با رشد سازمان، نوع سؤالها تغییر میکند. دیگر فقط مهم نیست «درخواست خرید چه زمانی تأیید شد؟». مدیر میخواهد بداند این خرید برای کدام پروژه انجام شده، از چه تأمینکنندهای خرید کردهایم، آیا کالا وارد انبار شده، چه هزینهای برای پروژه ایجاد کرده و در نهایت این پروژه چقدر سودآور بوده است.
از این نقطه به بعد، فرآیند بدون داده و داده بدون ارتباط با سایر بخشهای سازمان کافی نیست.
CRM؛ جایی که مشتری محور اصلی کسبوکار است
برای سازمانی که مسئله اصلی آن فروش، ارتباط با مشتری و خدمات است، CRM نقطه شروع طبیعیتری خواهد بود. اطلاعات مشتری، Leadها، Opportunityها، فعالیت کارشناسان و سوابق خدمات در یک سیستم منظم قرار میگیرند و سازمان از وابستگی به فایلهای شخصی و حافظه کارشناسان فاصله میگیرد.
اما کسبوکار معمولاً در لحظه فروش متوقف نمیشود. فرصت فروش به قرارداد تبدیل میشود؛ قرارداد ممکن است پروژه ایجاد کند؛ پروژه منابع و فعالیتهای مختلف دارد؛ محصول باید تحویل شود؛ ضمانتنامه باید پیگیری شود و خدمات پس از فروش نیز ممکن است ماهها یا سالها ادامه پیدا کند.
وقتی این نیازها وارد CRM میشوند، سازمان بهتدریج از CRM کلاسیک به سمت XRM حرکت میکند.
XRM؛ وقتی میخواهیم مدل کسبوکار را در سیستم بسازیم
در XRM دیگر Customer تنها شخصیت اصلی داستان نیست. Contract، Tender، Project، Product، Supplier، Asset و سایر مفاهیم مهم سازمان نیز جایگاه مستقلی پیدا میکنند و روابط میان آنها شکل میگیرد.
برای مثال، در یک شرکت پروژهمحور ممکن است مسیر از مناقصه آغاز شود. مناقصه موفق به Opportunity و سپس Contract تبدیل شود، قرارداد یک Project ایجاد کند و در ادامه تحویل محصولات و صدور فاکتور بر اساس آن مدیریت شود.
یعنی به جای چند نرمافزار مستقل، یک زنجیره منسجم شکل میگیرد:
مزیت اصلی XRM در همین نقطه است. سازمان مجبور نیست از روز اول تمام فرآیندهای خود را مشخص کرده باشد؛ میتواند مرحلهبهمرحله سیستم را توسعه دهد، مشروط بر اینکه معماری از ابتدا برای این رشد آماده باشد.
ERP؛ زمانی که یکپارچگی عملیات به مسئله اصلی تبدیل میشود
در نقطهای از بلوغ سازمان، دیگر مدیریت چند فرآیند یا چند موجودیت کافی نیست. فروش بر انبار اثر میگذارد، خرید باید با تأمینکننده و مالی مرتبط باشد، پروژه هزینه ایجاد میکند، موجودی باید کنترل شود و مدیر نیاز دارد تصویر منسجمی از عملیات سازمان داشته باشد.
ERP برای پاسخ به چنین نیازی شکل گرفته است.
اما ERP جامع، صرفاً نسخه بزرگتر یک نرمافزار معمولی نیست. اجرای موفق آن نیازمند بلوغ فرآیندی، Master Data مناسب، استانداردهای مشخص، مالکیت داده، ساختار دسترسی، Integration و آمادگی سازمان برای تغییر است.
به همین دلیل یک نکته بسیار مهم را نباید فراموش کرد:
ERP میتواند نتیجه بلوغ سازمان باشد، اما خرید ERP به تنهایی بلوغ ایجاد نمیکند.
سازمانی که هنوز نمیداند فرآیند خریدش دقیقاً چگونه باید اجرا شود، با نصب ERP ناگهان صاحب فرآیند بالغ نخواهد شد. اگر دادهها پراکنده و مسئولیتها نامشخص باشند، یک سیستم بزرگ ممکن است به جای حل مسئله، پیچیدگی موجود را دیجیتالی کند.
آیا باید تا زمان آمادگی کامل برای ERP صبر کرد؟
نه. و دقیقاً اینجا رویکرد مرحلهای اهمیت پیدا میکند.
برای بسیاری از سازمانهایی که در مسیر بلوغ هستند، میتوان به جای یک پروژه Big Bang، یک پلتفرم قابل توسعه را انتخاب کرد و آن را مرحلهبهمرحله گسترش داد.
فرض کنیم Dynamics 365 بستر اصلی باشد. مسیر ممکن است با CRM آغاز شود، سپس Contract Management به آن اضافه شود، در مرحله بعد Tender Management و Project Management شکل بگیرد و بعد خدمات و پشتیبانی وارد سیستم شوند. همزمان Integration با مالی، انبار و سایر سیستمها ایجاد شود و در مراحل بعد BI و AI روی این اکوسیستم قرار بگیرند.
این مسیر را میتوان چنین دید:
در این رویکرد، هر مرحله باید یک مسئله واقعی را حل کند؛ اما هیچ مرحلهای نباید بدون توجه به معماری آینده ساخته شود.
آیا XRM میتواند به ERP تبدیل شود؟
پاسخ دقیق این است: در بعضی حوزهها میتواند به ERP نزدیک شود، اما هر XRM الزاماً ERP نیست.
ERP صرفاً مجموعه بزرگی از فرمها، موجودیتها و Workflowها نیست. کنترلهای مالی، Master Data، Audit، عملیات بینواحدی، یکپارچگی عمیق و بسیاری از الزامات Enterprise در آن اهمیت دارند.
با این حال، یک XRM که با معماری درست توسعه یافته باشد میتواند به مرور بخش قابل توجهی از عملیات سازمان را پوشش دهد و به یکی از اجزای اصلی Enterprise Architecture تبدیل شود.
در بسیاری از سازمانها حتی نیازی نیست XRM جای ERP را بگیرد. ممکن است ERP امور مالی، خرید و انبار را مدیریت کند و XRM مسئول مشتری، قرارداد، مناقصه، پروژه و خدمات باشد.
| نیاز اصلی | رویکرد مناسب برای بررسی |
|---|---|
| گردش کار و فرآیندهای تأییدی | BPMS |
| مشتری، فروش و خدمات | CRM |
| قرارداد، مناقصه، پروژه و فرآیندهای اختصاصی | XRM |
| مالی، خرید، انبار و عملیات اصلی | ERP |
| تحلیل مدیریتی | BI |
| هوشمندسازی و تصمیمیار | AI روی دادههای یکپارچه |
این جدول نسخه نهایی معماری هیچ سازمانی نیست؛ اما میتواند نقطه شروع خوبی برای گفتگو باشد.
خطر پنهان؛ ساختن جزیرههای نرمافزاری
یکی از اشتباهات رایج این است که هر واحد سازمانی مسئله خود را جداگانه حل کند. واحد قرارداد یک نرمافزار میخرد، PMO ابزار دیگری انتخاب میکند، فروش CRM خود را دارد، پشتیبانی سیستم دیگری دارد و مالی نیز در دنیای خودش زندگی میکند.
در کوتاهمدت همه راضیاند، چون هر واحد مسئله خودش را حل کرده است. هزینه واقعی چند سال بعد ظاهر میشود؛ زمانی که اطلاعات مشتری در پنج سیستم وجود دارد، قرارداد چند بار ثبت شده، هیچ شناسه مشترکی میان دادهها وجود ندارد و تهیه یک گزارش مدیریتی ساده نیازمند استخراج چند Excel و ساعتها تطبیق اطلاعات است.
به همین دلیل، هنگام انتخاب هر نرمافزار ــ داخلی یا خارجی ــ نباید فقط امکانات امروز آن را دید. باید API، Data Access، قابلیت توسعه، Integration، مقیاسپذیری و امکان اتصال به BI و AI را نیز بررسی کرد.
سیستم مناسب، سیستمی نیست که فقط نیاز امروز را پاسخ دهد؛ باید بتواند عضو خوبی از معماری فردای سازمان نیز باشد.
از ثبت اطلاعات تا تصمیمسازی
هدف نهایی سیستمهای سازمانی نباید دیجیتالی کردن فرمهای کاغذی باشد. ارزش واقعی زمانی ایجاد میشود که داده بتواند به بینش و سپس تصمیم تبدیل شود.
وقتی مشتری، قرارداد، پروژه، خرید، فروش و خدمات به شکل مناسبی به یکدیگر متصل باشند، مدیر میتواند به جای بررسی دهها گزارش، درباره خود کسبوکار سؤال کند: کدام مشتریان واقعاً سودآورند؟ کدام پروژهها در معرض تأخیر قرار دارند؟ کدام قراردادها نیازمند اقدام هستند؟ چرا حاشیه سود یک گروه از پروژهها کاهش یافته است؟
BI برای پاسخ به بخشی از این سؤالات وارد معماری میشود و هوش مصنوعی مرحله بعدی این تحول است.
اما ترتیب اهمیت دارد:
هوش مصنوعی روی دادههای پراکنده و فرآیندهای نامشخص، صرفاً لایهای هوشمند روی یک معماری نامنظم خواهد بود. در مقابل، وقتی زیرساخت درست باشد، AI میتواند به تدریج از یک ابزار عمومی به دستیار هوشمند سازمان تبدیل شود.
جمعبندی؛ به جای خرید نرمافزار، معماری آینده را طراحی کنید
برای سازمانی که چند فرآیند مشخص دارد، BPMS میتواند انتخاب کاملاً مناسبی باشد. برای سازمانی که مسئله اصلی آن فروش و ارتباط با مشتری است، CRM نقطه شروع منطقیتری خواهد بود. وقتی قرارداد، مناقصه، پروژه، خدمات و سایر فرآیندهای اختصاصی باید در بستری مشترک قرار بگیرند، XRM ارزش خود را نشان میدهد؛ و هنگامی که سازمان به یکپارچگی عمیق منابع و عملیات اصلی نیاز دارد، ERP به بخش مهمتری از معماری تبدیل میشود.
اما شاید مهمترین تصمیم مدیریتی این نباشد که امروز کدام محصول را انتخاب کنیم. سؤال ارزشمندتر این است:
سیستمی که امروز میسازیم، سه تا پنج سال دیگر قرار است چه جایگاهی در سازمان داشته باشد؟
لازم نیست از روز اول همهچیز را بسازیم. میتوان از یک مسئله واقعی شروع کرد، آن را درست حل کرد و سپس ماژولبهماژول پیش رفت؛ قرارداد، مناقصه، پروژه، خدمات، Integration، BI و در نهایت AI.
اصل مهم این است که هر مرحله، جزیره جدیدی نسازد؛ بلکه قطعه دیگری از یک معماری بزرگتر باشد.
کوچک شروع کردن ایرادی ندارد؛ کوچک فکر کردن است که چند سال بعد برای سازمان هزینه ایجاد میکند