نیاز خریداران/ چالش ارائه کنندگان نرم افزار
یکپارچگی نرم افزار CRM و سیستم های جامع مالی(ERP/MIS)
چرا این یکپارچگی پیچیده و حساس است؟
تا چند سال پیش از این، در کشور ما مساله یکپارچگی بیشتر بین نرم افزار های مالی، بازرگانی و اداری مطرح بود و یکپارچگی دغدغه اصلی خریداران و اولویت یک، ارائه کنندگان پیشرو نرم افزار بود. اما امروز با توسعه راهکارهای CRM و نیز توسعه راهکارهای یکپارچه سازی مانند وب سرویس ها و میکروسرویس، یکپارچگی بین سیستم های مالی و بازرگانی – یا به اختصار MIS در این نوشته – با CRM به دغدغه اصلی خریداران این راهکارهای نرم افزاری بدل شده است.
خریداران CRM سوال های زیر را از ارائه کنندگان نرم افزار مطرح می پرسند:
در این مطلب با تشریح پیچیدگی ها و حساسیت های موضوع یکپارچگی بین سیستم های مالی و CRM، تلاش خواهم کرد به این سوالات پاسخ دهم.
با توجه به پیچیده بودن موضوع، امکان خطا و ایراد در تشریح مطالب وجود دارد که دعوت می کنم با درج نظرات و انتقادات دوستانه خود، به افزایش دانش جمعی کمک کنید.
تعاریف:
سیستم های جامع مالی یا MIS: مجموعه نرم افزارهای مالی ، بازرگانی، تولید و… که دارای یکپارچگی اطلاعات پایه و عملیاتی هستند و نتیجه مالی هریک از این نرم افزارها در قالب سند حسابداری ، در سیستم حسابداری ثبت می شود.
CRM: مجموعه نرم افزارهای بازاریابی، قبل از فروش و پس از فروش که فعالیت های ارتباط با مشتری را مدیریت می کند.
ERP: نسل بعدی MIS که دارای ویژگی های جدیدی مانند فرایند محوری، سفارشی سازی، تحت وب و ماژولار و قابلیت برنامه ریزی منابع سازمان هستند.
یکپارچگی دیتا: به دقت، انطباق، امنیت و بروز بودن داده های ذخیره شده در یک یا چند پایگاه داده اشاره می کند.
سناریوی یکپارچگی اطلاعات مشتری و پیش فاکتور
برای شروع خوب است با مثال ساده یکپارچگی اطلاعات مشتری بین پایگاه دادهCRM و MIS شروع کنیم. همانطور که در تصویر زیر مشخص است داده های هر دو جدول مشتری در دو پایگاه داده با هم برابر و به اصطلاح سینک هستند و چنین به نظر می رسد اگر نرم افزار CRM با مکانیزمی دیتای جدول مشتری خود را در جدول مشتری مالی ، کپی کند، یکپارچگی کار راحتی است!
معمولا بعد از تعریف مشتری در CRM ، پیش فاکتور یا درخواست خرید در CRM ثبت و به ترتیب زیر باید با پیش فاکتور سیستم مالی یکپارچه شود. در تصویر زیر می بینیم که جداول دیتای پیش فاکتور از مشتری پیچیده تر است و در هر پایگاه داده دو جدول وجود دارد یکی جدول اطلاعات اصلی پیش فاکتور و دیگری قلم محصولات پیش فاکتور. طبق تصویر فوق، پیش فاکتور در دو پایگاه داده CRM و MIS یکپارچه هستند و در سمت پایگاه داده MIS احتمالا پیش فاکتور به فاکتور و سند حسابداری تبدیل خواهد شد.
اما اجازه دهید از کمی بالاتر به بخش بسیار کوچکی از یک پایگاه داده سیستم MIS نگاه کنیم:
همانطور که مشخص است وقتی شرکتA در جدول مشتری ثبت و ذخیره می شود باید ابتدا در جدول دیتای شرکت ها ثبت شده باشد. در زمان صدور پیش فاکتور از دیتای جدول مشتری استفاده می شود و برمبنای همان پیش فاکتور، فاکتور فروش و سند حسابداری در پایگاه داده ذخیره می شود.
ابعاد مالی یکپارچگی CRM و سیستم های مالی
همانطور که درسناریوی فوق آمده است، واحد مالی براساس سند حسابداری و فاکتور فروش گزارشات مالی زیر را تهیه به هیات مدیره و مراجع قانونی ارائه می کنند:
- گزارش خرید و فروش فصلی
- گزارش سود و زیان شرکت
- دفاتر قانونی
- …
بنابراین تا اینجا می بینیم مشتری و پیش فاکتوری که در CRM ثبت و با MIS یکپارچه می شوند، تا حساسترین گزارشات مالی شرکت اثر گذار هستند. همچنین در یکپارچه سازی پیش فاکتور بین دو پایگاه داده، جداول دیتای متعددی مانند کالا، واحد سنجش، عامل کنترل موجودی کالا، سیاست های افزایند و کاهنده، مشتری، انبار، سازمان فروش، ارزش، موجودی کالا و … مشارکت دارند که کار یکپارچه سازی را پیچده تر می کنند.
این سناریوها نوک کوه یخی است که ما بینیم. بنابراین یکپارچگی مشتری بین MIS و CRM به سادگی که به نظر می رسد نیست و کنترل های زیر توسط نرم افزار باید انجام شود، اما چه کسی این مسئولیت را بر عهده می گیرد
کنترل های مشتری:
- اگر برای مشتری فاکتور صادر شد، سمت CRM اطلاعات اصلی مشتری قابل تغییر نباشد
- اگر برای مشتری فاکتور صادر شد، سمت CRM مشتری قابل حذف نباشد
- اگر در نرم افزار جامع مالی اطلاعات هویتی مشتری مانند شناسه ملی اجباری بود، CRM نتواند بدون شناسه ملی، مشتری را در MIS ثبت کند.
- مشتری که قبلا در سیستم مالی ایجاد شده به صورت تکرار ایجاد نشود
کنترل های پیش فاکتور:
- اگر پیش فاکتوری درسمت سیستم مالی، تحویل یا فاکتور شد سمت CRM قابل تغییر یا حذف نباشد
- سیاست های افزاینده و کاهنده در زمان محاسبه در پیش فاکتور CRM با سیاست های سمت MIS دچار مغایرت نباشد.
- پیش فاکتور یکپارچه شده در سیستم مالی، قابل ویرایش توسط کاربر نباشد
کنترل های عمومی:
- اگر به هر دلیلی بک آپ سیستم مالی به تاریخ چند روز قبل بازگشت، دیتاهای یکپارچه CRM نیز به همان تاریخ برگردد.
- اگر سرور نرم افزار مالی به علت خارج از دسترس یا متوقف شد، عملیات های منجر به یکپارچگی با CRM نیز متوقف شود تا دیتاهای جدید از دست نرود
چالش های یکپارچگی MIS و CRM
تفاوت تحلیل در نرم افزارهای مختلف
مبنای طراحی و ساخت پایگاه داده در هر نرم افزاری براساس تحلیل انسانی می باشد، بنابراین به تعداد افراد تحلیلگر، تحلیل های نرم افزاری مختلف وجود خواهد داشت. در زیر برخی از تفاوت های مرسوم آمده است:
- در برخی از نرم افزارهای مالی جدول مشتری از اشخاص شرکت ها جداست اما در برخی دیگر، یک جدول است
- در برخی از نرم افزار CRM سرنخ و مشتری یک جدول است اما در برخی دیگر 2 جدول است
- در برخی از نرم افزار ها وضعیت پیش فاکتور ثابت و اما در برخی متغییر و قابل سفارشی سازی است.
تفاوت طراحی فنی جداول دیتا در نرم افزارهای مختلف
همانطور که تحلیل متفاوت است، طراحی ساختار و ارتباطات جداول دیتایی حتی با تحلیل یکسان نیز می تواند در نرم افزارهای مختلف متفاوت باشد. به طور مثال:
- در یک نرم افزار شماره پیش فاکتور می تواند یک فیلد در پیش فاکتور باشد، در نرم افزار دیگر، جدول دیتای شماره گذاری متفاوت وجود داشته باشد.
- در یک نرم افزار جدول قلم محصولات فاکتور و پیش فاکتور، ممکن است مجزا باشد اما در نرم افزار دیگر یک جدول واحد وجود داشته باشد.
- در یک نرم افزار عنوان مشتری با صورت هاردکد باشد، در نرم افزار دیگر، جدول مجزایی برای عنوان مشتری وجود داشته باشد.
الزام کنترل های کسب و کار در سیستم های جامع مالی
با توجه به انعکاس اطلاعات پایه و عملیاتی ثبت شده در سیستم هایی MIS، در گزارشات قانونی و مالی شرکت، طراحی کنترل های کسب و کار در داخل نرم افزار بسیار اهمیت دارد و این کنترل ها نباید توسط هیچ کاربر یا نرم افزار بیرونی نقض شود. نمونه محدودی از این کنترل های بی پایان عبارتند از:
- رعایت ترتیب شماره و تاریخ فاکتور فروش
- اجباری بودن شناسه ملی مشتری
- عدم صدور پیش فاکتور برای مشتری فاقد اعتبار
- عدم صدور پیش فاکتور برای کالای بدون موجودی
- رزو موجودی کالا در زمان درخواست کالا
بنابراین در ارتباط بین CRM و MIS باید از عدم نقض این کنترل های متنوع اطمنیان حاصل کرد، تا گزارشات مالی و قانونی و کنترل های داخلی دچار خدشه نشود.
تنوع فرایندهای کاری در شرکت ها
در سازمانهای مختلف ممکن است فرایندهای کسب وکار مشابه به روش های متفاوت انجام شود، اما ارائه کنندگان نرم افزارهای سازمانی، با مطالعه روش های کاری در صنایع، بهترین روش کاری را انتخاب و آنرا مبنای تحلیل و توسعه نرم افزارهای جامع مالی قرار می دهند و وب سرویس های توسعه داده شده در این نرم افزارها محدود به همان روش های منتخب می شود. بنابراین زمانی که ما از نرم افزار CRM دیگری بخواهیم با این سیستم های مالی یکپارچه شویم، از آنجا که هیچ تضمینی وجود ندارد فرایندهای CRM ما با فرایندهای سیستم مالی مشابه باشند، در نتیجه با وجود وب سرویس های استاندارد، امکان یکپارچگی با سیستم مالی برای پوشش فرایند مورد نظر وجود نخواهد داشت. در نتیجه نیاز به توسعه در وب سرویس های استاندارد شرکت ارائه کننده نرم افزارهای مالی است که این موضوع به دلایل مختلف از جمله محدودیت منابع قابل انجام نیست.
مدیریت انتشار تغییرات و پشتیبانی نسخه های جدید
درخواست تغییر و خطا بخش جدانشدنی از فرایند توسعه نرم افزار است و شرکت های نرم افزاری طبق برنامه زمنابندی مشخصی، تغییرات را تست و منتشر می کنند. بنابراین تغییرات در جداول یا کنترل های کسب و کار سمتMIS که در یکپارچگی با CRM مشارکت دارند، می تواند منجر به خرابی دیتا یا توقف یکپارچه سازی بین 2 نرم افزار بشود.
نتیجه گیری:
با درنظر گرفتن چالش های بیان شده، یکپارچگی با سیستم های مالی، موضوعی پر ریسک است و متفاوت از یکپارچه سازی دیتا های عادی CRM مانند سرنخ، مخاطبان، سوابق تماس و ... می باشد که اگر اشتباهی پیش آمد به راحتی قابل رفع و رجوع یا به جایی بر نخورد باشد.
خریدارن نرم افزارهای جامع مالی به دلیل حساست های گزارشات قانونی، مالی و کنترل های داخلی انتظار دارند که شرکت های ارائه کننده نرم افزارهای مالی، صحت، دقت، پایداری و بروز بودن دیتای سمت پایگاه داده مالی را تضمین کنند. لذا یکپارچگی CRM یا هر نرم افزار دیگری با این نرم افزارها باید از روش های مورد تایید و تضمین این شرکت ها باشد.
خوب راهکار چیست؟ در مطالب بعدی به این سوال پاسخ خواهم داد.
یکپارچگی با سیستم های جامع مالی
#راهکاران #سپیدار # راهکاران _ابری
