اگر عبارت «بهترین نرم افزار BPMS» را در اینترنت جستوجو کنید، احتمالاً با فهرستهای بلندبالایی از محصولات و قابلیتهای نرمافزارهای BPMS مختلف روبهرو میشوید. این لیستها شاید کمککننده باشد، اما مسئله مهم اینجاست: محصولی که برای یک سازمان انتخاب مناسبی است، ممکن است برای سازمان دیگری انتخاب خوبی نباشد.
یک مجموعه شاید چند فرایند نسبتاً ساده داشته باشد و بخواهد بخش زیادی از تغییرات را با تیم داخلی خود انجام دهد. سازمان دیگری ممکن است دهها فرایند بینواحدی، سامانههای قدیمی، محدودیتهای زیرساختی و الزامات سختگیرانهتری برای استقرار داشته باشد. طبیعی است که معیار انتخاب این دو یکسان نباشد.
به همین دلیل، «بهترین» BPMS را نمیتوان فقط از روی تعداد قابلیتها یا شهرت یک محصول تعیین کرد. باید دید نرمافزار تا چه اندازه با فرایندها، فناوری، کاربران، روش نگهداری و محدودیتهای واقعی سازمان هماهنگ است.
اگر هنوز در مرحله شناخت این دسته از نرمافزارها هستید، ابتدا راهنمای BPMS چیست؟ را بخوانید. در این مطلب فرض میکنیم میدانید BPMS چیست و تصمیم گرفتهاید چند گزینه را جدیتر بررسی کنید.
بهترین نرم افزار BPMS چه ویژگیهایی دارد؟
یک BPMS مناسب باید بتواند فرایند واقعی سازمان را اجرا کند، با سامانههای موجود کنار بیاید و تغییرات آینده را به مسئلهای پرهزینه و فرسایشی تبدیل نکند.
برای ارزیابی اولیه، این شش سؤال نقطه شروع خوبی هستند:
معیار | سؤال تصمیمگیری |
|---|---|
اجرای فرایند | آیا نرمافزار میتواند سناریوی واقعی ما را اجرا کند؟ |
تغییرپذیری | تغییر یک مرحله، نقش یا قاعده چقدر دشوار است؟ |
یکپارچهسازی | ارتباط با سامانههای فعلی سازمان چگونه انجام میشود؟ |
استقلال تیم داخلی | چه تغییراتی را میتوانیم خودمان انجام دهیم؟ |
استقرار | آیا مدل استقرار با معماری و سیاستهای سازمان سازگار است؟ |
هزینه مالکیت | هزینه استفاده و نگهداری نرمافزار در طول زمان چیست؟ |
این جدول برای حذف سریع گزینههای نامتناسب مفید است، اما تصمیم نهایی به بررسی دقیقتر نیاز دارد.
قبل از مقایسه BPMSها، اول صورت مسئله را روشن کنید
رفتن مستقیم سراغ دموی چند محصول معمولاً کار را سختتر میکند. هر ارائهدهنده نقاط قوت خودش را نشان میدهد و در پایان چند نمایش متفاوت دارید که مقایسه مستقیم آنها کار آسانی نیست.
قبل از دیدن محصول، بهتر است چند موضوع را در سازمان مشخص کنید.
قرار است چه فرایندهایی اجرا شوند؟
لازم نیست تمام فرایندهای سازمان را از ابتدا تحلیل کنید. دو یا سه سناریوی نمونه انتخاب کنید؛ ترجیحاً سناریوهایی که کمی تفاوت با یکدیگر دارند.
مثلاً ببینید:
- چند نقش یا واحد در آنها درگیر است؛
- کجا تصمیم گرفته میشود؛
- چه استثناهایی دارند؛
- چه اطلاعاتی میان مراحل جابهجا میشود؛
- آیا مرحلهای به سامانه دیگری وابسته است.
محصولی که فقط روی یک Flow (گردش) تأیید ساده خوب به نظر میرسد، هنوز برای اجرای فرایندهای واقعی سازمان ارزیابی نشده است.
چه سامانههایی باید به BPMS متصل شوند؟
ERP، CRM، منابع انسانی، سامانه مالی، Active Directory، سرویسهای داخلی یا حتی یک نرمافزار قدیمی ممکن است بخشی از فرایند باشند.
فقط نوشتن نام این سامانهها کافی نیست. مشخص کنید چه دادهای باید خوانده یا ثبت شود، ارتباط از چه طریقی ممکن است و در صورت قطع یا خطای سرویس چه اتفاقی باید بیفتد.
چه کسی بعداً سیستم را تغییر میدهد؟
این سؤال در زمان خرید ساده به نظر میرسد، اما چند ماه بعد اهمیت زیادی پیدا میکند.
آیا کارشناس فرایند سازمان قرار است تغییرات متداول را انجام دهد؟ تیم IT مسئول است؟ یا هر اصلاحی باید به ارائهدهنده سپرده شود؟
بهتر است از ابتدا مشخص باشد مرز کار تیم داخلی و تیم ارائهدهنده کجاست.
چه محدودیتهایی قابل مذاکره نیستند؟
گاهی یک الزام بهتنهایی میتواند گزینهای را از فهرست خارج کند.
ممکن است سازمان به استقرار در زیرساخت داخلی نیاز داشته باشد، نوع خاصی از احراز هویت برایش ضروری باشد یا یک اتصال مشخص برای ادامه پروژه حیاتی باشد.
این موارد را پیش از امتیازدهی جدا کنید.
چگونه یک فهرست محدود از نرمافزارهای BPMS بسازیم؟
برای مقایسه جدی، معمولاً نیازی به بررسی ده یا پانزده محصول ندارید.
ابتدا شرطهای حذف را مشخص کنید. محصولاتی که نیازهای غیرقابل مذاکره را پوشش نمیدهند کنار بگذارید.
بعد، معیارهای مهم را وزن بدهید. مثلاً ممکن است یکپارچهسازی برای شما دو برابر رابط کاربری اهمیت داشته باشد؛ در سازمان دیگری، استقلال تیم داخلی و کیفیت پشتیبانی وزن بیشتری بگیرد.
در نهایت سه یا چهار گزینه را وارد ارزیابی عملی کنید.
این روش یک مزیت مهم دارد: بهجای اینکه از هر محصول بپرسید «چه امکاناتی دارید؟»، از همه میخواهید یک مسئله مشابه را حل کنند.
برای مقایسه نرمافزارهای BPMS از چه گزینههایی شروع کنیم؟
بهتر است فهرست اولیه فقط از محصولاتی تشکیل نشود که بیشترین حضور تبلیغاتی را دارند.
ترکیب فهرست میتواند شامل چند رویکرد متفاوت باشد؛ برای مثال:
- یک یا دو نرمافزار BPMS ایرانی با پشتیبانی و استقرار محلی؛
- یک پلتفرم بینالمللی با تأکید بیشتر بر توسعه بصری و کاربران کسبوکار؛
- یک ابزار فنیتر برای سازمانی که تیم توسعه قوی دارد و کنترل بیشتری روی معماری میخواهد.
هدف از این دستهبندی، معرفی «سه نوع قطعی BPMS» نیست. فقط کمک میکند از ابتدا گزینههایی را کنار هم بگذارید که رویکردهای متفاوتی دارند.
فهرست اولیه هم لازم نیست ثابت بماند. اگر در بررسی مستندات یا دموی اولیه مشخص شد محصولی با نیازهای اصلی سازمان فاصله دارد، بهتر است زود حذف شود تا زمان ارزیابی روی گزینههای جدیتر صرف شود.
مهمترین معیارهای انتخاب نرمافزار BPMS
هنگام ارزیابی، بهجای علامتزدن یک فهرست قابلیت، هر معیار را به یک آزمون تبدیل کنید.
این جدول برای شروع مفید است:
معیار | چه چیزی بررسی شود؟ | علامت هشدار |
|---|---|---|
مدلسازی فرایند | اجرای منطق و استثناهای فرایند واقعی | نمایش خوب نمودار، بدون پوشش منطق موردنیاز |
فرم | ساخت و تغییر فرم در سناریوی واقعی | وابستگی فنی بالا برای تغییرات متداول |
موتور فرایند | اجرای چند نمونه و مدیریت وضعیت آنها | تمرکز ابزار فقط بر طراحی گردش کار |
قواعد | تغییر یک تصمیم بدون بههمزدن کل فرایند | منطق تصمیم پراکنده در چند بخش سیستم |
یکپارچهسازی | اتصال عملی به یک سرویس نمونه | اکتفا به جمله «API داریم» |
امنیت | کنترل دسترسی و ثبت فعالیت | پاسخهای کلی بدون مستندات یا دامنه روشن |
گزارش و پایش | گزارش از داده اجرای واقعی | گزارشهای جدا از وضعیت واقعی فرایند |
نگهداری | تغییر یک نیاز پس از استقرار | وابستگی دائمی برای اصلاحات کوچک |
تجربه کاربری | انجام یک وظیفه توسط کاربر نهایی | پیچیدگی غیرضروری در کار روزمره |
استقرار | تطابق با معماری موردنیاز | اجبار سازمان به مدل استقرار نامتناسب |
پشتیبانی | مسیر آموزش، رفع مسئله و ارتقا | ابهام در مسئولیتهای پس از استقرار |
هزینه مالکیت | هزینه کل چندساله | تمرکز صرف بر مبلغ اولیه |
طراحی و مدلسازی فرایند
ظاهر گرافیکی طراح فرایند مهم است، اما کافی نیست.
یک سناریوی واقعی بردارید و ببینید آیا میتوانید مسیر اصلی، تصمیمها، برگشتها، فعالیتهای موازی و حالتهای استثنایی موردنیاز خود را با منطق روشن مدل کنید.
اگر محصول از یک استاندارد مانند BPMN استفاده میکند، دامنه واقعی پشتیبانی از عناصر موردنیاز پروژه را هم بررسی کنید؛ صرف عبارت «پشتیبانی از BPMN»پاسخ کاملی نیست.
برای بررسی نحوه مدلسازی و اجرای این منطق در گراف BPMS، میتوانید قابلیتهای فرایندساز و موتور فرایند را مشاهده کنید.
ساخت و مدیریت فرمها
فرم در BPMS معمولاً بخشی از اجرای فرایند است، نه یک صفحه جدا.در دمو یک فرم واقعی بخواهید: فیلدهای ساده و پیچیده، اعتبارسنجی، نمایش شرطی اطلاعات و استفاده از داده موجود.
سؤال مهم این نیست که «فرمساز دارید؟». سؤال این است که تغییر فرم در پروژه واقعی شما چگونه انجام خواهد شد.
موتور اجرای فرایند
بعد از طراحی، باید ببینید هنگام اجرای چند درخواست همزمان چه اتفاقی میافتد.
یک نمونه مشخص را دنبال کنید: اکنون در چه مرحلهای است؟ وظیفه دست چه کسی است؟ اگر کار برگشت بخورد چه میشود؟ سابقه اجرای همان درخواست را از کجا میتوان دید؟
این قسمت معمولاً فاصله میان «ابزار رسم جریان» و یک BPMS اجرایی را بهتر نشان میدهد.
قواعد و منطق کسبوکار
بعضی تصمیمها مرتب تغییر میکنند؛ سقف مبلغ، نوع درخواست، واحد سازمانی یا شرایط تأیید.
یکی از این تصمیمها را در جلسه ارزیابی تغییر دهید و ببینید برای اعمال آن چه بخشهایی باید دستکاری شوند. اگر یک تغییر ساده در قاعده، مستلزم بازطراحی گسترده فرایند یا توسعه اختصاصی باشد، این موضوع بعداً روی نگهداری اثر میگذارد.
اگر میخواهید ببینید این نوع تصمیمها در گراف چگونه از منطق فرایند تفکیک و مدیریت میشوند، میتوانید موتور قواعد کسبوکار را بررسی کنید.
یکپارچهسازی و API
در پروژههای سازمانی، عبارت «قابلیت اتصال» بهاندازه کافی دقیق نیست.
یک سرویس نمونه را انتخاب کنید و مسیر واقعی را ببینید: داده از کجا وارد میشود، چگونه نگاشت میشود، احراز هویت چطور انجام میشود و اگر سرویس مقصد پاسخ ندهد سیستم چه رفتاری دارد.
همین آزمون کوچک معمولاً اطلاعات بیشتری از چند اسلاید درباره API میدهد.
برای بررسی روشهای اتصال فرایندها به سرویسها و منابع داده در گراف BPMS نیز میتوانید بخش یکپارچهسازی داده و سرویسهای سازمانی را ببینید.
امنیت و مدیریت دسترسی
امنیت را با یک سؤال کلی مثل «آیا نرمافزار امن است؟» نسنجید.
در همین مرحله کافی است بررسی کنید مدیریت کاربران و نقشها چگونه انجام میشود، چه سطحی از کنترل دسترسی وجود دارد، فعالیتهای مهم تا چه حد قابل ردیابیاند و کدام مسئولیتهای امنیتی بر عهده محصول، زیرساخت یا تیم سازمان است.
ارزیابی تخصصی امنیت موضوع مستقلی است و نباید صرفاً از روی قابلیتهای ارائهشده در یک جلسه دمو نتیجهگیری شود.
گزارشگیری و پایش
گزارشی بخواهید که مستقیماً از اجرای همان سناریوی دمو ساخته شده باشد.
آیا میتوان نمونههای فعال، تأخیرها، وضعیت فعالیتها یا داده موردنیاز مدیر را دید؟ اگر گزارش فقط بر پایه دادههای نمونه از قبل آماده شده باشد، هنوز نمیدانید داده اجرای فرایند واقعی چگونه در اختیار شما قرار میگیرد.
برای بررسی ابزارهای این حوزه در گراف BPMS میتوانید قابلیتهای گزارشساز سازمانی را مشاهده کنید.
توسعهپذیری و نگهداری
یکی از بهترین آزمونها این است که بعد از تکمیل سناریو، یک تغییر کوچک درخواست کنید.
مثلاً یک مرحله تأیید اضافه کنید، مسئول یکفعالیت را تغییر دهید یا شرط مسیر را اصلاح کنید.
بعد ببینید این تغییر چقدر زمان و چه نوع مهارتی میخواهد. همین سناریو تصویر بهتری از نگهداری آینده میدهد.
تجربه کاربری
BPMS را فقط از دید طراح فرایند ارزیابی نکنید.
یک کاربر عادی باید بتواند وظیفه خود را پیدا کند، اطلاعات لازم را ببیند و نتیجه را ثبت کند، بدون اینکه مجبور باشد ساختار فنی فرایند را بفهمد.
در طرف دیگر، تجربه تحلیلگر و مدیر سیستم هم مهم است. محصول ممکن است برای کاربر نهایی ساده باشد اما نگهداری آن برای تیم داخلی بیش از حد پیچیده شود.
مدل استقرار
استقرار ابری یا درونسازمانی فقط یک انتخاب فنی نیست.
محل نگهداری داده، مسئولیت عملیات، دسترسی تیم سازمان، سیاستهای امنیتی و معماری فعلی روی این تصمیم اثر دارند.اگر استقرار مشخصی برای شما الزامی است، آن را در مرحله اول بهعنوان شرط حذف بررسی کنید.
پشتیبانی و نگهداری محصول
از ارائهدهنده بپرسید بعد از استقرار چه اتفاقی میافتد.
آموزش تیم چگونه انجام میشود؟ تغییرات محصول چگونه مدیریت میشوند؟ در صورت بروز مسئله، مرز مسئولیت تیم شما و ارائهدهنده چیست؟
کیفیت محصول مهم است، اما پروژهای که مدل نگهداری آن مبهم باشد، در ادامه با مسئله روبهرو میشود.
اطلاعات مرتبط با شرکت گراف در صفحه درباره گراف در دسترس است.
هزینه کل مالکیت
قیمت اولیه تنها بخشی از تصمیم است.
لایسنس، استقرار، آموزش، زیرساخت، یکپارچهسازی، پشتیبانی و تغییرات آینده میتوانند در مجموع تصویر متفاوتی از هزینه ایجاد کنند.
اگر در مرحله بررسی مدل تجاری گراف هستید، اطلاعات مربوط به لایسنس BPMS را جداگانه بررسی کنید. هنگام مقایسه سایر محصولات هم همین اصل را رعایت کنید: عدد اولیه را بدون هزینه ادامه استفاده مقایسه نکنید.
در دموی نرمافزار چه چیزی را واقعاً بررسی کنیم؟
جلسه دمو جایی است که ادعاهای محصول باید به رفتار واقعی سیستم تبدیل شوند.
برای همه گزینههای نهایی یک سناریوی مشترک تعریف کنید. مثلاً:
ثبت اطلاعات ← دو نقش انسانی ← یک قاعده تصمیمگیری ← ارتباط با یک سامانه دیگر ← یک حالت استثنا ← گزارش وضعیت
بعد از هر ارائهدهنده بخواهید همین مسیر را اجرا کند.
موضوع | چیزی که باید در دمو دیده شود |
|---|---|
طراحی فرایند | مدلکردن همان سناریو |
فرم | ساخت فرم موردنیاز |
اجرا | اجرای چند نمونه از فرایند |
قواعد | تغییر یک تصمیم و مشاهده نتیجه |
یکپارچهسازی | تبادل داده با سرویس نمونه |
دسترسی | تفاوت دسترسی دو نقش |
استثنا | برگشت، تأخیر یا خطا |
گزارش | گزارش از اجرای همان نمونهها |
تغییر | اصلاح یک بخش از فرایند |
تجربه کاربر | انجام وظیفه از دید کاربر نهایی |
این روش مقایسه را منصفانهتر میکند. اگر هر محصول سناریوی خودش را نمایش دهد، در پایان چیزهای متفاوتی دیدهاید که الزاماً قابل مقایسه نیستند.
در جلسه دمو چه سؤالهایی بپرسیم؟
لازم نیست دهها سؤال از پیش آماده داشته باشید. چند سؤال رفتاری معمولاً چیزهای بیشتری روشن میکنند:
- اگر مسیر فرایند بعداً تغییر کند، اصلاح آن دقیقاً چگونه انجام میشود؟
- اضافهکردن یک نقش یا مرحله جدید چه مراحلی دارد؟
- اتصال به یکی از سامانههای موجود سازمان ما چگونه انجام خواهد شد؟
- دسترسی دو نقش مختلف به یک داده چگونه کنترل میشود؟
- وضعیت یک درخواست مشخص را از شروع تا این لحظه چگونه میتوان دید؟
- اگر سرویس خارجی در دسترس نباشد، فرایند چه رفتاری دارد؟
- چه تغییراتی را تیم داخلی ما میتواند انجام دهد؟
- چه تغییراتی نیازمند توسعه یا همراهی ارائهدهنده است؟
برای پروژههای پیچیده، دمو ممکن است کافی نباشد. در چنین شرایطی یک PoC محدود روی مسئلهای مشخص، اطلاعات فنی قابل اتکاتری ایجاد میکند.
انواع نرم افزارهای BPMS چه تفاوتی دارند؟
«انواع BPMS» را میتوان از زاویههای مختلف دستهبندی کرد. برای انتخاب نرمافزار، سه تفاوت بیشتر از بقیه روی تصمیم اثر میگذارند.
BPMS ایرانی و خارجی
این تقسیمبندی بهخودیخود چیزی درباره کیفیت محصول ثابت نمیکند.
تفاوت عملی معمولاً در موضوعاتی مثل دسترسی به پشتیبانی، زبان، شرایط تجاری، اکوسیستم فنی، مدل استقرار و امکان استفاده از خدمات تخصصی دیده میشود.
دو محصول ایرانی هم ممکن است از نظر معماری و شیوه توسعه تفاوت زیادی داشته باشند؛ همانطور که دو محصول خارجی الزاماً شبیه یکدیگر نیستند.
استقرار ابری و درونسازمانی
در مدل ابری، زیرساخت در یک محیط ابری مدیریت میشود. اما «ابری» بهتنهایی پاسخ سؤالهای مهم سازمان نیست. باید مشخص باشد داده کجا نگهداری میشود، کنترل زیرساخت با چه کسی است و مسئولیت عملیاتی چگونه تقسیم شده است.
در استقرار درونسازمانی، نرمافزار روی زیرساخت تحت کنترل سازمان قرار میگیرد و در مقابل، بخشی از مسئولیت نگهداری و عملیات نیز به سازمان منتقل میشود.
ابزارهای نزدیکتر به کسبوکار و ابزارهای فنیتر
در بعضی BPMSها بخش بیشتری از طراحی در اختیار تحلیلگر یا کارشناس فرایند قرار میگیرد. برخی ابزارها نیز برای تیمهای فنی و توسعهدهندگان کنترل بیشتری فراهم میکنند.
این تفاوت را با عنوانهایی مثل Low-Code یا Developer-Friendly بهتنهایی قضاوت نکنید. بهتر است در عمل ببینید تیم شما برای انجام تغییرات متداول به چه مهارتهایی نیاز دارد.
بهترین نرم افزار BPMS ایرانی را چگونه انتخاب کنیم؟
برای سازمانی که در ایران فعالیت میکند، بررسی یک BPMS ایرانی دلایل عملی مشخصی دارد: امکان ارتباط مستقیمتر با تیم ارائهدهنده، دسترسی به پشتیبانی فارسی، شرایط تجاری داخلی و در بعضی محصولات امکان هماهنگی بیشتر با مدل استقرار موردنیاز سازمان.
اما هیچکدام از این موارد به این معنی نیست که «ایرانیبودن» بهتنهایی یک محصول را به بهترین نرم افزار BPMS ایرانی تبدیل میکند.
برای مقایسه چند نرم افزار BPMS ایرانی، حداقل این موارد را بررسی کنید:
- کیفیت ابزارهای طراحی و اجرای فرایند؛
- توان یکپارچهسازی با سامانههای موجود؛
- امکان انجام تغییرات توسط تیم داخلی؛
- مدل استقرار قابل ارائه؛
- مستندات و مسیر آموزش؛
- کیفیت و دسترسی پشتیبانی؛
- نحوه ارتقا و نگهداری؛
- شرایط تجاری و هزینه مالکیت.
بعد، همان سناریوی دمو را روی گزینههای ایرانی اجرا کنید. این روش بسیار قابل دفاعتر از انتخاب براساس ادعای «بومی»، «کامل» یا «قدرتمند» است.
BPMS ایرانی بهتر است یا خارجی؟
پاسخ به نیاز سازمان بستگی دارد.
موضوع | در گزینه ایرانی چه چیزی بررسی شود؟ | در گزینه خارجی چه چیزی بررسی شود؟ |
|---|---|---|
پشتیبانی | کیفیت و دسترسی واقعی تیم | دسترسی مستقیم یا همکار اجرایی |
زبان فارسی | کیفیت رابط و محتوای فارسی | میزان پشتیبانی واقعی از فارسی |
یکپارچهسازی | اتصال به سامانههای سازمان | دسترسی به ابزارهای اتصال، API و تخصص لازم |
استقرار | مدلهای قابل ارائه | امکان استفاده از مدل موردنیاز در ایران |
تیم داخلی | آموزش و ابزارهای توسعه | مهارت و اکوسیستم موردنیاز |
ارتقا | فرایند و اثر سفارشیسازیها | مسیر نسخهها و وابستگیهای فنی |
هزینه | کل هزینه استفاده و نگهداری | هزینه ارزی، خدمات و زیرساخت |
در بعضی پروژهها، تفاوت میان دو محصول ایرانی از تفاوت کلی «ایرانی و خارجی» مهمتر است. انتخاب را تا سطح خود محصول پایین بیاورید.
چکلیست نهایی انتخاب BPMS
قبل از تصمیم نهایی، ببینید پاسخ این موارد روشن است یا نه:
- فرایندهای نمونه برای ارزیابی انتخاب شدهاند.
- سامانهها و یکپارچهسازیهای ضروری مشخصاند.
- شروط حذف از معیارهای امتیازدهی جدا شدهاند.
- سه یا چهار گزینه جدی باقی ماندهاند.
- همه گزینهها روی سناریوی مشابه ارزیابی شدهاند.
- مدل استقرار موردنیاز مشخص است.
- مرز تغییرات تیم داخلی و ارائهدهنده روشن است.
- الزامات امنیتی سازمان ثبت شدهاند.
- هزینه کل مالکیت، نه فقط مبلغ اولیه، بررسی شده است.
- مدل آموزش، پشتیبانی و ارتقا مشخص است.
اگر هنوز در چند مورد اصلی پاسخ روشنی ندارید، احتمالاً برای تصمیم نهایی زود است.
گراف BPMS بهعنوان یکی از گزینههای قابل بررسی
اگر گراف BPMS در فهرست گزینههای سازمان شما قرار دارد، بهتر است دقیقاً همان معیارهایی را روی آن اجرا کنید که برای محصولات دیگر استفاده میکنید.
گراف BPMS امکان مدلسازی فرایند مبتنی بر BPMN 2.0 را فراهم میکند و مدل فرایند میتواند با فرمها، قواعد کسبوکار، منابع داده و سرویسهای سازمانی در یک محیط فرایندمحور ترکیب شود.
بهجای ارزیابی محصول از روی فهرست قابلیتها، یک فرایند واقعی سازمان را انتخاب کنید و طراحی، تغییر، اجرا، یکپارچهسازی و گزارش همان سناریو را در دمو بررسی کنید.
جمعبندی؛ بهترین BPMS برای سازمان شما کدام است؟
بهترین نرم افزار BPMS لزوماً محصولی نیست که در یک جدول بیشترین علامت مثبت را داشته باشد.
انتخاب خوب زمانی اتفاق میافتد که ابتدا بدانید چه چیزی برای سازمان حیاتی است، گزینههای نامتناسب را زود کنار بگذارید و چند محصول باقیمانده را با سناریوی یکسان بسنجید.
در آن مرحله، سؤال «کدام BPMS بهترین است؟» شکل دقیقتری پیدا میکند:
کدام گزینه با فرایندها، معماری، تیم و محدودیتهای ما تناسب بیشتری دارد و میتوانیم این تناسب را در عمل نشان دهیم؟
سؤالات متداول
بهترین نرمافزار BPMS کدام است؟
یک محصول واحد برای همه سازمانها بهترین نیست. انتخاب به نوع فرایندها، معماری فناوری، یکپارچهسازی، مدل استقرار، توان تیم داخلی، پشتیبانی و هزینه مالکیت بستگی دارد. مقایسه روی یک سناریوی واقعی روش قابل اتکاتری برای انتخاب است
بهترین نرمافزار BPMS ایرانی کدام است؟
بدون تعریف نیاز و روش مقایسه نمیتوان یک محصول را بهطور عمومی بهترین BPMS ایرانی دانست. چند گزینه ایرانی را با معیارهای یکسان و روی یک سناریوی واقعی بررسی کنید و کیفیت پشتیبانی، توسعهپذیری، یکپارچهسازی، استقرار و هزینه مالکیت را در تصمیم وارد کنید.
برای مقایسه نرم افزارهای BPMS چه معیارهایی مهمترند؟
اجرای فرایند واقعی، تغییرپذیری، یکپارچهسازی، امکان نگهداری توسط تیم داخلی، مدل استقرار، تجربه کاربری، امنیت، گزارش و پایش، پشتیبانی و هزینه کل مالکیت از معیارهای اصلی هستند.
BPMS ایرانی بهتر است یا خارجی؟
پاسخ عمومی وجود ندارد. BPMS ایرانی ممکن است از نظر دسترسی به تیم پشتیبانی، زبان و شرایط تجاری مزیت عملی داشته باشد؛ گزینه خارجی نیز ممکن است برای معماری یا نیاز فنی خاصی مناسبتر باشد. خود محصول و شرایط پروژه باید مقایسه شوند.
انواع نرم افزارهای BPMS چه تفاوتی دارند؟
تفاوتها را میتوان از نظر ایرانی یا خارجی بودن، مدل استقرار و میزان تمرکز ابزار بر کاربران کسبوکار یا تیمهای فنی بررسی کرد. این دستهبندیها برای ساخت فهرست اولیه مفیدند، اما کیفیت محصول را بهتنهایی تعیین نمیکنند.
در دموی BPMS چه چیزی را بررسی کنیم؟
بهتر است همه محصولات یک سناریوی مشترک را اجرا کنند؛ سناریویی که شامل فرم، نقش انسانی، تصمیم، یکپارچهسازی، حالت استثنا و گزارش باشد. علاوه بر اجرای اولیه، حداقل یک تغییر در فرایند یا قاعده نیز در همان جلسه بررسی شود.