مشاوره یکپارچه‌سازی نرم‌افزارها و داده‌ها؛ نقشه‌ی داده پیش از انتخاب ابزار

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

این مسئله قدیمی است و اندازه‌گیری هم شده است. مطالعه‌ی NIST هزینه‌ی ناکافی‌بودن تبادل داده در صنعت تأسیسات سرمایه‌ای آمریکا را برای سال ۲۰۰۲، ۱۵٫۸ میلیارد دلار برآورد کرده و خود گزارش، این عدد را احتمالاً محافظه‌کارانه می‌داند. مطالعه‌ی Autodesk و FMI نیز نشان داد ۳۰ درصد از پاسخ‌دهندگان گفتند بیش از نیمی از داده‌های پروژه‌هایشان نامناسب است.

مشاوره در این حوزه به یک پرسش پاسخ می‌دهد: کدام اتصال‌ها ارزش ساخت دارند، به چه ترتیبی و با چه روشی؟

نقشه‌ی داده یک جدول ساده است که برای هر سامانه، پنج پرسش را پاسخ می‌دهد:

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

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

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

شماره‌ی پروژه در همه‌ی سامانه‌ها یکسان است، تا زمانی که کسی آن را بررسی کند.

داده‌هایی که میان همه‌ی سامانه‌ها مشترک‌اند، مانند شماره‌ی پروژه، نام کارفرما، کد فاز و کد هزینه، داده‌های مرجع نام دارند. برای هرکدام باید سه مورد مشخص شود:

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

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

روش مناسب به تعداد دفعات انتقال، حجم داده و امکاناتی بستگی دارد که هر نرم‌افزار در اختیار می‌گذارد:

• تبادل فایل زمان‌بندی‌شده: یک سامانه خروجی CSV یا Excel تولید می‌کند و سامانه‌ی دیگر آن را در زمان مشخصی وارد می‌کند. ساده‌ترین روش و برای نرم‌افزارهایی که API ندارند، اغلب تنها روش.
• اتصال مستقیم با API: یک برنامه داده را از API یک سامانه می‌خواند و در سامانه‌ی دیگر می‌نویسد. سریع و دقیق، اما هر تغییر در API یکی از دو طرف، اتصال را متوقف می‌کند.
• لایه‌ی میانی: همه‌ی سامانه‌ها به یک لایه‌ی مشترک متصل می‌شوند و این لایه، قواعد تبدیل و ثبت خطاها را مدیریت می‌کند. وقتی تعداد سامانه‌ها از سه یا چهار بیشتر شود، از اتصال‌های دوبه‌دو قابل‌نگهداری‌تر است.
• پایگاه داده‌ی مشترک: داده‌های همه‌ی سامانه‌ها در یک پایگاه داده جمع می‌شوند و گزارش‌ها و داشبوردها فقط از همان‌جا می‌خوانند.

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

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

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

سه ابزار این اتصال را ممکن می‌کنند:

• Revit API: برنامه‌ای که داده‌ها را مستقیماً از مدل می‌خواند و در صورت نیاز در آن می‌نویسد.
• IFC: قالب باز تبادل مدل که buildingSMART آن را نگهداری می‌کند و برای انتقال میان نرم‌افزارهای مختلف BIM به کار می‌رود.
• ISO 19650: استانداردی برای مدیریت اطلاعات در طول چرخه‌ی عمر یک دارایی ساخته‌شده با استفاده از BIM، که نام‌گذاری، وضعیت و مسیر تأیید اطلاعات را تعیین می‌کند.

هر اتصالی به مدل Revit باید شناسه‌ی پایدار هر المان را حفظ کند، واحدها را درست تبدیل کند و میان پارامترهای تایپ و نمونه تفاوت بگذارد. خروجی Excel از اسکجوال رویت این شرایط را برای رفت‌وبرگشت داده میان Revit و Excel به‌صورت کامل بررسی می‌کند.

راهنماهای یکپارچه‌سازی معمولاً انگلیسی و تقویم میلادی را فرض می‌گیرند. دفتری در ایران با مسائلی روبه‌رو می‌شود که در این راهنماها مطرح نمی‌شوند:

• نویسه‌های فارسی و عربی: «ی» و «ک» عربی در یک سامانه و فارسی در سامانه‌ی دیگر باعث می‌شوند نام یکسان کارفرما، دو رکورد متفاوت شناخته شود.
• ارقام: ارقام فارسی در یک فایل و لاتین در فایل دیگر، مقایسه‌ی کدها را ناممکن می‌کنند.
• تاریخ: تاریخ شمسی در نرم‌افزار حسابداری و میلادی در Revit یا نرم‌افزار زمان‌بندی، و سال مالی‌ای که با سال میلادی هم‌خوانی ندارد.
• نرم‌افزارهای داخلی: بسیاری از نرم‌افزارهای حسابداری و اداری داخلی API عمومی ندارند و تبادل فایل تنها روش اتصال آن‌ها است.

یکسان‌سازی این موارد باید در قواعد تبدیل هر اتصال نوشته شود و یک‌بار برای همیشه انجام شود. آماده‌سازی داده برای هوش مصنوعی همین یکسان‌سازی را از زاویه‌ی جست‌وجو و بازیابی متن بررسی می‌کند.

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

چهار مورد این ریسک را کنترل می‌کنند:

• ثبت هر انتقال: چه رکوردی، در چه زمانی، با چه نتیجه‌ای.
• گزارش تطبیق: مقایسه‌ی دوره‌ای تعداد و جمع رکوردها در دو سامانه.
• اعلان خطا: پیامی به فرد مسئول، هم‌زمان با رخ‌دادن خطا.
• مسئول مشخص: فردی در دفتر که خطا را بررسی و برطرف می‌کند.

هیچ رکوردی نباید بی‌صدا از فرآیند حذف شود و هر مورد منتقل‌نشده باید قابل‌مشاهده و پیگیری باشد.

مشاوره‌ای که فقط به فهرستی از نرم‌افزارهای پیشنهادی ختم شود، کار اصلی را انجام نداده است. خروجی قابل‌استفاده شامل این موارد است:

1. نقشه‌ی داده، با همه‌ی سامانه‌ها و انتقال‌های فعلی.
2. جدول داده‌های مرجع، با منبع واحد، قالب و قاعده‌ی تعارض هرکدام.
3. فهرست اتصال‌ها بر اساس اولویت، همراه با زمانی که هرکدام صرفه‌جویی می‌کند یا خطایی که حذف می‌کند.
4. روش پیشنهادی برای هر اتصال.
5. نخستین اتصال، ساخته و اندازه‌گیری‌شده، پیش از تصمیم‌گیری درباره‌ی بقیه.

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