پیش از اتصال سیستم‌ها، باید ذهن‌ها را متصل کرد

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

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

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

چالش واقعی: نه اتصال فنی، بلکه یکسان‌سازی داده

هر سازمانی، پیش از شروع پروژه یکپارچه‌سازی، معمولاً از قبل در سیستم تخصصی خودش (مثلاً CRM) داده‌هایی تعریف کرده است؛ مشتریانی با کدها و شناسه‌های مشخص که طی زمان و توسط افراد مختلف تیم فروش ثبت شده‌اند. از طرف دیگر، در نرم‌افزار حسابداری هم همان مشتریان، اغلب به‌صورت دستی و توسط فرد یا تیم دیگری، معمولاً واحد مالی، ثبت شده‌اند؛ افرادی که لزوماً از قواعد کدگذاری واحد فروش خبر نداشته‌اند و بر اساس نیازهای مالی و حسابداری خودشان، کدگذاری مستقلی انجام داده‌اند.

نتیجه این فرآیند موازی و غیرهماهنگ، این است که وقتی زمان برقراری ارتباط API فرا می‌رسد، این ارتباط به یک پیش‌نیاز اساسی نیاز دارد: نگاشت داده پایه (Data Mapping) بین دو سیستم. باید مشخص شود که هر مشتری در CRM، دقیقاً معادل کدام مشتری در نرم‌افزار حسابداری است و این تطبیق باید به‌صورت یک‌به‌یک و دقیق انجام شود؛ چراکه هرگونه خطا در این مرحله، می‌تواند به ثبت اشتباه اسناد مالی، دوباره‌کاری یا حتی مغایرت در گزارش‌های مالی سازمان منجر شود.

تجربه نشان می‌دهد در بهترین حالت، حدود ۹۰ درصد داده‌ها با قواعد و کدگذاری‌های یکسان یا قابل تطبیق تعریف شده‌اند و نگاشت آن‌ها با ابزارهای خودکار یا نیمه‌خودکار قابل انجام است. اما ۱۰ درصد باقی‌مانده و گاهی حتی بیشتر از آن، دچار مغایرت، نام‌گذاری متفاوت، تکرار یا حتی نبود هیچ تعریف مشترکی است. این‌ها همان مواردی هستند که هیچ الگوریتم یا API‌ای به‌تنهایی نمی‌تواند آن‌ها را تشخیص دهد یا اصلاح کند.

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

اینجاست که پروژه‌ها گیر می‌کنند

مشکل اصلی معمولاً فنی نیست؛ مسئله «مالکیت» است. وقتی نوبت به پاک‌سازی و تطبیق داده می‌رسد، اغلب هیچ واحد یا فردی مشخص مسئولیت این کار را نمی‌پذیرد. این وظیفه در فضایی خاکستری بین واحدهای مختلف سازمان مشتری معلق می‌ماند؛ نه فروش آن را کار خودش می‌داند -چون به نظرشان این یک مسئله مالی و حسابداری است- و نه مالی، چون معتقد است داده‌های مشتری در ابتدا توسط فروش وارد سیستم شده‌اند و اصلاح آن‌ها بر عهده همان واحد است.

نتیجه این کشمکش نامشخص، معمولاً یکی از حالت‌های زیر است:

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

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

سخن پایانی

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

این همراهی یعنی:

• افراد بدانند دقیقاً چه کاری از آن‌ها انتظار می‌رود و این انتظار از کجا نشأت می‌گیرد
• این کار را «بار اضافه» روی مسئولیت‌های قبلی خود نبینند، بلکه بخشی طبیعی از فرآیند تحول دیجیتال سازمان و ارتقای کیفیت داده‌های آن بدانند
• به‌جای «وقت ندارم» و «کارم زیاد است»، مسئولیت داده‌ای که خودشان تولید کرده‌اند را بپذیرند و برای اصلاح آن، زمان مشخصی در برنامه کاری خود در نظر بگیرند
• درک کنند که هزینه نپرداختن این هزینه کوچک در ابتدای مسیر، بسیار بیشتر از هزینه‌ای است که در آینده، در قالب خطاهای مالی، دوباره‌کاری، و نارضایتی از سیستم پرداخت خواهند کرد

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

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