وقتی یک سازمان تصمیم میگیرد فرآیندهای کاری خود را از حالت دستی، ایمیلی یا مبتنی بر فایلهای پراکنده خارج کند، معمولاً با یک سؤال مهم مواجه میشود:
آیا باید برای این کار یک نرمافزار اختصاصی توسعه دهیم یا از BPMS استفاده کنیم؟
پاسخ این سؤال برای همه سازمانها یکسان نیست.
در برخی پروژهها، توسعه یک نرمافزار اختصاصی بهترین انتخاب است. در برخی دیگر، استفاده از یک پلتفرم مدیریت و اتوماسیون فرآیند میتواند زمان توسعه و تغییرات آینده را سادهتر کند.
بنابراین انتخاب بین این دو گزینه نباید صرفاً بر اساس قیمت یا نام یک محصول انجام شود. ابتدا باید مشخص شود سازمان دقیقاً چه مسئلهای را میخواهد حل کند و این مسئله تا چه اندازه به مدیریت و تغییر مداوم فرآیندها وابسته است.
BPMS و نرمافزار اختصاصی چه تفاوتی دارند؟
به زبان ساده، در توسعه نرمافزار اختصاصی، نرمافزار از ابتدا متناسب با نیازهای مشخص یک سازمان طراحی و برنامهنویسی میشود. اما در رویکرد BPMS، سازمان از یک پلتفرم آماده برای مدلسازی، اجرا و مدیریت فرآیندهای کسبوکار استفاده میکند و فرآیندها، فرمها، نقشها و قوانین مورد نیاز را روی آن پیادهسازی میکند. BPMSها با هدف مدیریت و خودکارسازی فرآیندها ساخته شدهاند و معمولاً قابلیتهایی مانند طراحی گردش کار، فرمها، تخصیص وظایف و پایش فرآیند را در یک محیط یکپارچه ارائه میکنند.
در مقابل در توسعه اختصاصی، دامنه امکانات و معماری سیستم میتواند دقیقاً بر اساس نیاز پروژه طراحی شود.
بنابراین تفاوت اصلی را میتوان اینگونه خلاصه کرد:
نرمافزار اختصاصی = ساخت یک راهکار متناسب با یک نیاز مشخص
BPMS =استفاده از یک بستر آماده برای ساخت و تغییر راهکارهای مبتنی بر فرآیند
BPMS بهتر است یا نرمافزار اختصاصی؟
پاسخ کوتاه این است: هیچکدام بهصورت مطلق بهتر نیستند.
انتخاب مناسب به ماهیت مسئله بستگی دارد.
اگر سازمان نیاز به یک سیستم کاملاً تخصصی با منطق پیچیده و منحصر به فرد داشته باشد، توسعه اختصاصی میتواند گزینه مناسبی باشد. اما اگر مسئله اصلی سازمان، مدیریت گردش کار، تأییدها، وظایف، فرمها، نقشها، قوانین و ارتباط بین واحدها باشد و احتمال تغییر این فرآیندها در آینده زیاد باشد، استفاده از BPMS میتواند گزینه مناسبی برای بررسی باشد.
حتی ممکن است در یک سازمان، هر دو رویکرد در کنار یکدیگر استفاده شوند.
مقایسه BPMS و نرمافزار اختصاصی
برای تصمیمگیری بهتر، بهتر است این دو رویکرد را از چند زاویه مختلف بررسی کنیم.
|
معیار |
BPMS |
نرمافزار اختصاصی |
|
شروع پروژه |
معمولاً سریعتر |
معمولاً زمانبرتر |
|
طراحی فرآیند |
مبتنی بر ابزارهای فرآیندی |
نیازمند توسعه |
|
تغییر گردش کار |
معمولاً سادهتر |
وابسته به ساختار نرمافزار |
|
سفارشیسازی |
در چارچوب پلتفرم |
بسیار گسترده |
|
توسعه قابلیتهای کاملاً خاص |
ممکن است محدودیت داشته باشد |
انعطاف بسیار بالا |
|
مدیریت فرآیند |
قابلیت اصلی |
باید توسعه داده شود |
|
فرمهای فرآیندی |
معمولاً آمادهتر |
نیازمند طراحی و توسعه |
|
یکپارچهسازی |
بسته به قابلیتهای پلتفرم |
قابل توسعه بر اساس معماری |
|
وابستگی به تیم توسعه |
در بسیاری از تغییرات کمتر |
معمولاً بیشتر |
|
هزینه اولیه |
وابسته به محصول و پروژه |
وابسته به دامنه توسعه |
|
نگهداری |
وابسته به پلتفرم و پیادهسازی |
بر عهده تیم توسعه |
|
مناسب برای |
فرآیندهای قابل تغییر و گردش کار |
سیستمهای کاملاً تخصصی |
البته این جدول یک قاعده مطلق نیست. قابلیتهای هر محصول و کیفیت اجرای پروژه میتواند نتیجه واقعی را تغییر دهد.
۱. سرعت توسعه و راهاندازی
یکی از مهمترین تفاوتها، نحوه شروع پروژه است.
در توسعه اختصاصی، معمولاً باید مراحل مختلفی مانند تحلیل نیازمندیها، طراحی معماری، طراحی دیتابیس، طراحی رابط کاربری، برنامهنویسی، تست و استقرار انجام شود.
در یک پلتفرم BPMS، بخشی از زیرساخت مورد نیاز برای مدیریت فرآیند از قبل وجود دارد و تیم پیادهسازی میتواند تمرکز بیشتری روی تحلیل و طراحی فرآیند سازمان داشته باشد.
در نتیجه، برای پروژههایی که بخش مهمی از نیازمندی آنها حول فرآیند و گردش کار شکل گرفته است، BPMS میتواند زمان رسیدن به یک نمونه قابل اجرا را کاهش دهد. منابع مرتبط با BPM نیز یکی از مزیتهای رویکردهای فرآیندمحور را کاهش وابستگی به توسعه سنتی برای تغییرات فرآیندی میدانند.
البته سرعت واقعی پروژه به پیچیدگی فرآیند، یکپارچهسازیها و میزان سفارشیسازی نیز وابسته است.
۲. انعطافپذیری در برابر تغییر فرآیندها
فرآیندهای سازمانی ثابت نیستند. ممکن است سازمان تصمیم بگیرد:
- یک مرحله جدید اضافه کند؛
- مسئول یک مرحله را تغییر دهد؛
- یک تأیید جدید ایجاد کند؛
- مسیر فرآیند را بر اساس مبلغ یا نوع درخواست تغییر دهد؛
- یک فرم را اصلاح کند؛
- یک واحد جدید به فرآیند اضافه کند.
در یک سیستم اختصاصی، روش انجام این تغییرات کاملاً به معماری نرمافزار و نحوه توسعه آن بستگی دارد. اما در BPMS، تغییر فرآیند یکی از سناریوهای اصلی استفاده از پلتفرم است.
به همین دلیل اگر سازمان انتظار دارد فرآیندهای آن مرتباً تغییر کنند، این معیار باید در انتخاب معماری راهکار جدی گرفته شود.
۳. میزان سفارشیسازی
در نگاه اول ممکن است تصور شود نرمافزار اختصاصی همیشه انعطافپذیرتر است. از نظر فنی، این موضوع تا حد زیادی درست است.
در توسعه اختصاصی، تیم توسعه میتواند منطق، ساختار داده، رابط کاربری و معماری سیستم را بر اساس نیاز پروژه طراحی کند. اما این انعطافپذیری یک هزینه نیز دارد:
هر قابلیت جدید باید طراحی، توسعه، تست و نگهداری شود.
در BPMS، بخشی از این قابلیتها از قبل در پلتفرم وجود دارد، اما سازمان باید در چارچوب قابلیتهای آن پلتفرم حرکت کند.
بنابراین سؤال بهتر این نیست که: "کدامیک سفارشیتر است؟"
بلکه باید پرسید:
آیا نیازهای سازمان در محدوده قابلیتهای BPMS قرار میگیرند یا به یک سیستم کاملاً اختصاصی نیاز دارند؟
۴. هزینه توسعه و نگهداری
مقایسه هزینه BPMS و نرمافزار اختصاصی تنها با نگاه کردن به هزینه اولیه اشتباه است. هزینه واقعی پروژه میتواند شامل موارد مختلفی باشد:
در پروژه BPMS:
- هزینه نرمافزار یا مجوز
- تحلیل فرآیند
- طراحی و پیادهسازی
- توسعه سفارشی
- یکپارچهسازی
- آموزش
- پشتیبانی
- زیرساخت
در پروژه اختصاصی:
- تحلیل نیازمندی
- طراحی معماری
- طراحی UI/UX
- برنامهنویسی
- تست
- استقرار
- نگهداری
- توسعه نسخههای بعدی
- زیرساخت
- پشتیبانی
بنابراین برای مقایسه واقعی، بهتر است هزینه کل مالکیت (TCO) در یک بازه چندساله بررسی شود، نه فقط هزینه شروع پروژه.
۵. وقتی فرآیندها مرتب تغییر میکنند چه گزینهای مناسبتر است؟
فرض کنید یک سازمان فرآیندهای زیادی دارد و هر چند ماه یکبار تغییراتی در آنها ایجاد میشود.
برای مثال:
درخواست خرید ---> تأیید مدیر ---> بررسی مالی ---> تدارکات ---> خرید
ممکن است سازمان بعداً تصمیم بگیرد:
- برای خریدهای بالاتر از مبلغ مشخص، تأیید مدیرعامل اضافه شود؛
- خریدهای خاص به واحد دیگری ارسال شوند؛
- مرحله مالی حذف یا جابهجا شود؛
- فرم درخواست تغییر کند.
در چنین شرایطی، قابلیت تغییر سریع فرآیند اهمیت زیادی پیدا میکند. در راهکارهای فرآیندمحور، مدلسازی و تغییر گردش کار بخش مهمی از معماری سیستم است. بنابراین اگر تغییر مداوم فرآیندها یکی از ویژگیهای اصلی پروژه باشد، BPMS ارزش بررسی بیشتری پیدا میکند.
۶. چه زمانی نرمافزار اختصاصی انتخاب بهتری است؟
BPMS برای همه مسائل نرمافزاری مناسب نیست. توسعه اختصاصی میتواند گزینه مناسبتری باشد اگر:
۱. منطق کسبوکار کاملاً منحصر به فرد باشد
اگر سازمان به سیستمی نیاز دارد که منطق آن بسیار خاص باشد و نمونه مشابهی در قالب پلتفرمهای موجود وجود نداشته باشد، توسعه اختصاصی میتواند منطقی باشد.
۲. محصول اصلی سازمان همان نرمافزار باشد
برای مثال، اگر شرکت قصد دارد یک محصول نرمافزاری تخصصی برای فروش به مشتریان مختلف ایجاد کند، کنترل کامل روی معماری محصول اهمیت زیادی دارد.
۳. نیازهای فنی خاصی وجود داشته باشد
ممکن است پروژه به معماری، الگوریتم، رابط کاربری یا قابلیتهایی نیاز داشته باشد که در چارچوب یک BPMS بهسادگی قابل پیادهسازی نباشند.
۴. فرآیندها نسبتاً ثابت باشند
اگر فرآیندهای سازمان مشخص و پایدار هستند و تغییرات زیادی ندارند، ممکن است ساخت یک نرمافزار اختصاصی برای آنها منطقی باشد.
۷. چه زمانی BPMS ارزش بررسی بیشتری دارد؟
از طرف دیگر، BPMS زمانی گزینه جذابی برای بررسی است که مسئله اصلی سازمان، اتوماسیون و مدیریت فرآیندهای چندمرحلهای باشد.
برای مثال:
- فرآیندهای تأیید
- درخواست خرید
- درخواست مرخصی
- استخدام
- گردش اسناد
- بررسی و تأیید مدارک
- درخواست خدمات
- فرآیندهای مالی
- فرآیندهای منابع انسانی
- گردش مکاتبات و درخواستهای داخلی
در این نوع پروژهها، سازمان معمولاً بیش از آنکه به یک نرمافزار کاملاً منحصر به فرد نیاز داشته باشد، به یک بستر قابل تغییر برای مدیریت گردش کار نیاز دارد.
۸ .آیا BPMS و نرمافزار اختصاصی میتوانند در کنار هم استفاده شوند؟
بله. این نکته بسیار مهم است و نباید انتخاب را الزاماً به یک گزینه محدود کرد.
برای مثال، سازمان ممکن است یک نرمافزار اختصاصی ERP یا CRM داشته باشد و از BPMS برای مدیریت فرآیندهایی استفاده کند که بین چند سیستم و چند واحد سازمانی گردش دارند. در این حالت معماری میتواند چیزی شبیه این باشد:
نرمافزارهای موجود سازمان
↓ ↑
API / Web Service / Integration
↓ ↑
لایه مدیریت فرآیند
↓
کاربران و واحدهای سازمان
در چنین معماری، BPMS الزاماً جایگزین نرمافزارهای موجود نمیشود، بلکه میتواند گردش فرآیند بین آنها را مدیریت کند. یک پلتفرم فرآیند میتواند برای اتصال فرآیندها به سیستمهای خارجی و برنامههای قدیمی نیز مورد استفاده قرار گیرد.
۹. یک مثال عملی: فرآیند درخواست خرید
فرض کنیم یک شرکت میخواهد فرآیند درخواست خرید خود را اتوماسیون کند.
فرآیند فعلی:
درخواست کارمند ---> تأیید مدیر ---> بررسی تدارکات ---> استعلام ---> تأیید مالی ---> خرید
اگر سازمان تنها به یک فرم ساده برای ثبت درخواست نیاز داشته باشد، شاید توسعه یک نرمافزار کوچک اختصاصی کافی باشد.
اما اگر نیازها شامل موارد زیر باشد:
- چند مسیر مختلف بر اساس مبلغ خرید
- چند سطح تأیید
- اتصال به سیستم مالی
- تخصیص خودکار وظایف
- کنترل مهلت انجام
- ثبت سوابق
- گزارشگیری
- تغییر مسیر بر اساس نوع کالا
- امکان تغییر فرآیند در آینده
در این حالت، رویکرد فرآیندمحور ارزش بررسی بیشتری پیدا میکند.
نکته مهم این است که انتخاب نهایی باید بر اساس نیاز واقعی پروژه انجام شود، نه صرفاً بر اساس نام فناوری.
۱۰. برای انتخاب بین BPMS و نرمافزار اختصاصی چه سوالهایی بپرسیم؟
قبل از تصمیمگیری، به این سوالها پاسخ دهید:
درباره فرآیند
- چند فرآیند قرار است اتوماسیون شوند؟
- فرآیندها چند مرحله دارند؟
- چند واحد در آنها دخیل هستند؟
- فرآیندها چقدر تغییر میکنند؟
درباره سیستم
- آیا نیاز به فرمهای متعدد داریم؟
- آیا نیاز به گردش کار و تأییدهای مختلف داریم؟
- آیا سیستم باید با نرمافزارهای موجود ارتباط داشته باشد؟
- آیا گزارشگیری و پایش فرآیند اهمیت دارد؟
درباره توسعه
- چه مقدار سفارشیسازی نیاز داریم؟
- چه تیمی قرار است سیستم را توسعه دهد؟
- بعد از استقرار، چه کسی تغییرات را انجام میدهد؟
- هزینه نگهداری در چند سال آینده چقدر خواهد بود؟
درباره کسبوکار
- هدف اصلی کاهش زمان انجام فرآیند است یا ساخت یک سیستم تخصصی؟
- آیا فرآیندها در آینده تغییر خواهند کرد؟
- آیا قرار است راهکار برای فرآیندهای دیگری نیز توسعه پیدا کند؟
پاسخ به این سوالها معمولاً تصویر واضحتری از گزینه مناسب ایجاد میکند.
یک ماتریس ساده برای تصمیمگیری
میتوان برای تصمیمگیری از یک امتیازدهی ساده استفاده کرد:

این جدول صرفاً یک چارچوب تصمیمگیری است و امتیاز واقعی هر گزینه باید بر اساس محصول، تیم اجرا و نیازهای همان سازمان تعیین شود.
یک اشتباه رایج: انتخاب فناوری قبل از تحلیل فرآیند
یکی از اشتباهات رایج این است که سازمان ابتدا یک فناوری یا محصول را انتخاب کند و بعد تلاش کند فرآیندهای خود را با آن تطبیق دهد. رویکرد بهتر این است:
تحلیل مسئله ---> تحلیل فرآیند موجود ---> تعیین نیازمندیها ---> طراحی فرآیند مطلوب ---> بررسی گزینههای فنی ---> اجرای آزمایشی ---> انتخاب راهکار
تحلیل فرآیند پیش از انتخاب ابزار نیز در راهنماهای اتوماسیون فرآیند به عنوان یکی از گامهای مهم توصیه میشود.
آیا انتخاب BPMS به معنی حذف برنامهنویسی است؟
خیر. این تصور که استفاده از BPMS به معنی «عدم نیاز به برنامهنویسی» است، دقیق نیست.
BPMS میتواند بسیاری از قابلیتهای عمومی مورد نیاز فرآیندها را آماده کند و برای بخشی از توسعه نیز ابزارهای Low-Code یا مشابه آن ارائه دهد. اما پروژههای واقعی ممکن است همچنان به توسعه اختصاصی، اسکریپتنویسی، یکپارچهسازی یا اتصال به سیستمهای دیگر نیاز داشته باشند.
بنابراین تفاوت اصلی را باید در محل تمرکز توسعه دید:
در توسعه اختصاصی، بخش بزرگی از زیرساخت نرمافزار باید توسط تیم توسعه ساخته شود. در BPMS، بخش مهمی از زیرساخت مدیریت فرآیند از قبل فراهم است و تیم میتواند تمرکز بیشتری بر تحلیل، طراحی و پیادهسازی نیازهای کسبوکار داشته باشد.
BPMS یا نرمافزار اختصاصی؛ در نهایت کدام را انتخاب کنیم؟
پاسخ را میتوان در یک جدول خلاصه کرد:
|
اگر مسئله شما این است... |
گزینهای که ارزش بررسی بیشتری دارد |
|
فرآیندها مرتباً تغییر میکنند |
BPMS |
|
چند واحد در فرآیند دخیل هستند |
BPMS |
|
تأییدها و گردش کار اهمیت زیادی دارند |
BPMS |
|
قرار است فرآیندهای متعددی اتوماسیون شوند |
BPMS |
|
نیاز به ساخت یک سیستم کاملاً خاص دارید |
نرمافزار اختصاصی |
|
منطق اصلی سیستم بسیار تخصصی است |
نرمافزار اختصاصی |
|
کنترل کامل روی معماری ضروری است |
نرمافزار اختصاصی |
|
سیستم قرار است یک محصول نرمافزاری مستقل باشد |
نرمافزار اختصاصی |
|
بخشی از نیازها فرآیندی و بخشی کاملاً اختصاصی هستند |
ترکیب دو رویکرد |
بنابراین BPMS جایگزین تمام نرمافزارهای اختصاصی نیست و نرمافزار اختصاصی نیز همیشه بهترین راه برای اتوماسیون فرآیند نیست. انتخاب درست به ماهیت مسئله بستگی دارد.
اگر سازمان به دنبال اتوماسیون فرآیندها باشد
اگر بعد از تحلیل نیازهای سازمان مشخص شود که مسئله اصلی، مدیریت و خودکارسازی فرآیندهای چندمرحلهای است، بررسی راهکارهای BPMS میتواند گام بعدی باشد. در این مرحله بهتر است به جای مقایسه صرفاً فهرست امکانات، یک فرآیند واقعی سازمان انتخاب و با گزینههای مختلف بررسی شود.
برای مثال میتوان فرآیندهایی مانند خرید، درخواست خدمات، مدیریت اسناد، منابع انسانی یا تأییدهای سازمانی را به صورت آزمایشی مدل کرد و مواردی مانند سرعت پیادهسازی، انعطافپذیری، یکپارچهسازی و امکان تغییرات آینده را ارزیابی کرد.
برای آشنایی با راهکاری که برای این نوع نیازها در مجموعه مدیریت فرآیند پارس ارائه میشود، میتوانید صفحه نرم افزار BPMS پارس را بررسی کنید.
جمع بندی
انتخاب بین BPMS و نرمافزار اختصاصی یک تصمیم فنی صرف نیست. بلکه باید بر اساس نیاز کسب و کار و ماهیت مسئله انجام شود.
اگر سازمان با فرآیندهای چندمرحلهای، گردش وظایف، تأییدها، تغییرات مداوم و نیاز به اتوماسیون فرآیندهای مختلف مواجه است، BPMS میتواند گزینه مناسبی برای بررسی باشد.
در مقابل، اگر سازمان به یک سیستم کاملاً تخصصی با منطق، معماری یا قابلیتهایی نیاز دارد که در چارچوب یک پلتفرم فرآیندی بهراحتی قابل پیادهسازی نیست، توسعه اختصاصی میتواند انتخاب منطقیتری باشد.
و در بسیاری از پروژهها، ترکیب این دو رویکرد نیز میتواند بهترین نتیجه را ایجاد کند.
بنابراین سؤال اصلی این نیست که:
"BPMS بهتر است یا نرمافزار اختصاصی؟"
بلکه سؤال درست این است:
"برای مسئلهای که میخواهیم حل کنیم، کدام رویکرد هزینه، سرعت، انعطافپذیری و قابلیت توسعه مناسبتری ایجاد میکند؟"
انتخاب فناوری باید بعد از شناخت مسئله و تحلیل فرآیند انجام شود، نه قبل از آن.
هیچ دیدگاهی تا به این لحظه در این صفحه ثبت نشده است