بزرگ‌ترین سوءتفاهم در بازار BPMS: موتور فرآیند همان پلتفرم BPMS نیست!
وقتی درباره انتخاب BPMS صحبت می‌کنیم، معمولاً بحث به نام محصولات، امکانات، فرم‌ها، داشبوردها و ابزارهای طراحی فرآیند ختم می‌شود.
اما یک سؤال بنیادی وجود دارد که گاهی در این مقایسه‌ها نادیده گرفته می‌شود:
آیا ما در حال انتخاب یک موتور اجرای فرآیند هستیم یا یک پلتفرم کامل برای توسعه و مدیریت راهکارهای سازمانی؟
این دو مفهوم به هم مرتبط‌اند، اما یکسان نیستند.
موتور فرآیند BPMS دقیقاً چه کاری انجام می‌دهد؟
موتور فرآیند، مسئول اجرای منطق فرآیند است؛ از ایجاد نمونه فرآیند و پیشبرد فعالیت‌ها گرفته تا مدیریت وضعیت اجرا و هماهنگی میان مراحل مختلف.
برای مثال، یک موتور BPMN می‌تواند تعیین کند که پس از تأیید مدیر، درخواست به کدام مرحله برود، چه شرطی بررسی شود و در صورت وقوع یک رویداد چه اتفاقی بیفتد.
اما سازمان برای ساخت یک راهکار واقعی معمولاً به اجزای بیشتری نیاز دارد:
- طراحی و مدیریت مدل‌های فرآیند
- فرم‌ها و رابط کاربری
- مدیریت کاربران، نقش‌ها و دسترسی‌ها
- قوانین کسب‌وکار و تصمیم‌گیری
- اتصال به سامانه‌های سازمانی
- پایش، گزارش‌گیری و مدیریت خطا
- ابزارهای توسعه، استقرار و نگهداری
بنابراین، قابلیت اجرای فرآیند با قابلیت ساخت یک راهکار سازمانی کامل یکسان نیست.
چرا این تفاوت در انتخاب BPMS اهمیت دارد؟
فرض کنید دو سازمان می‌خواهند فرآیند درخواست خرید را خودکار کنند.
سازمان اول به فرم، گردش تأیید و گزارش ساده نیاز دارد.
سازمان دوم باید همین فرآیند را با سامانه مالی، مدیریت تأمین‌کنندگان، قواعد پیچیده تصمیم‌گیری و چندین سرویس مستقل یکپارچه کند.
آیا معیار انتخاب پلتفرم برای این دو سازمان باید یکسان باشد؟
طبیعتاً نه.
در پروژه دوم، علاوه بر قابلیت‌های آماده، موضوعاتی مانند معماری استقرار، APIها، توسعه‌پذیری، مدل یکپارچه‌سازی و نحوه مدیریت تغییرات اهمیت بیشتری پیدا می‌کنند.
به همین دلیل، مقایسه BPMSها صرفاً بر اساس تعداد امکانات یا کیفیت ابزار طراحی، تصویر کاملی از توانایی آن‌ها به ما نمی‌دهد.
Flowable و Camunda؛ دو نمونه برای بررسی معماری
برای درک بهتر این موضوع، می‌توان دو پلتفرم شناخته‌شده در حوزه اتوماسیون فرآیند را بررسی کرد.
Flowable موتورهای مجزای BPMN، CMMN و DMN را ارائه می‌کند و امکان تعامل از طریق APIهای Java و REST و استفاده از موتور در قالب Embedded یا Service را دارد. این قابلیت‌ها آن را به گزینه‌ای قابل بررسی برای معماری‌های متنوع تبدیل می‌کنند.
Camunda 8 نیز معماری متفاوتی مبتنی بر موتور Zeebe دارد. در این معماری، کلاینت‌ها از طریق Gateway با کلاستر موتور ارتباط برقرار می‌کنند و اجرای کارهای کسب‌وکار می‌تواند به Workerهای مستقل سپرده شود.
مستندات رسمی این دو محصول، تفاوت‌های معماری و روش‌های یکپارچه‌سازی آن‌ها را تشریح می‌کنند.
منابع:
این تفاوت‌ها به معنی برتری مطلق یک محصول نیستند. نکته این است که معماری مناسب باید با نیازهای واقعی سازمان انتخاب شود، نه صرفاً بر اساس شهرت محصول یا امکانات نمایشی آن.
قبل از انتخاب پلتفرم، این پنج سؤال را بپرسید
۱. آیا به یک راهکار آماده و یکپارچه نیاز داریم یا می‌خواهیم بخش‌های مختلف را خودمان توسعه دهیم؟
۲. موتور فرآیند باید داخل برنامه ما اجرا شود یا به‌صورت یک سرویس مستقل؟
۳. چه میزان کنترل بر رابط کاربری، قوانین کسب‌وکار و منطق اجرایی لازم داریم؟
۴. اتصال به سامانه‌های موجود و مدیریت خطاها چگونه انجام خواهد شد؟
۵. اگر معماری سازمان در آینده تغییر کند، چه میزان آزادی عمل برای توسعه یا بازطراحی خواهیم داشت؟
پاسخ به این سؤال‌ها می‌تواند فهرست گزینه‌های مناسب را به‌طور جدی تغییر دهد.
جمع‌بندی:
از نام محصول به معماری راهکار برسیم
انتخاب BPMS فقط انتخاب یک ابزار مدل‌سازی یا یک موتور اجرای فرآیند نیست؛ انتخاب مجموعه‌ای از قابلیت‌ها و محدودیت‌های فنی است که در طول عمر راهکار با آن‌ها زندگی خواهیم کرد.
گاهی یک پلتفرم یکپارچه با امکانات آماده، بهترین پاسخ است. در پروژه‌ای دیگر، یک موتور فرآیند توسعه‌پذیر با APIهای مناسب و معماری متناسب با زیرساخت سازمان، انتخاب منطقی‌تری خواهد بود.
سؤال اصلی این نیست که کدام BPMS امکانات بیشتری دارد؛ سؤال این است که کدام معماری با نیازهای امروز و مسیر آینده سازمان ما سازگارتر است.
دیدگاهی یافت نشد