راهنمای انتخاب BPMS؛ چطور تصمیمی بگیریم که پنج سال بعد پشیمان نشویم
معیارهای انتخاب BPMS، اشتباهات رایج در فرآیند خرید، و روش ارزیابی عملی پلتفرم‌های مدیریت فرآیند با سناریوهای واقعی و اثبات مفهوم.
چند سال در سمت طراحی محصول و مهندسی سامانه یکی از پلتفرم‌های مدیریت فرآیند شناخته‌شده کشور کار کرده‌ام و ده‌ها جلسه ارزیابی و دمو را از آن طرف میز دیده‌ام. حالا که در سمت مشاور کارفرما می‌نشینم، دقیقاً می‌دانم در آن جلسات چه چیزی گفته می‌شود و چه چیزی گفته نمی‌شود. این یادداشت خلاصه همان تجربه است.
پیش از هر مذاکره، سه کار را انجام دهید
- معماری فرآیندهای سازمان را شفاف کنید تا بدانید پلتفرم قرار است چه دامنه‌ای را پوشش دهد.
- فرآیندهایی را که در موج اول پیاده می‌شوند بازطراحی کنید؛ خرید پلتفرم برای اجرای فرآیند معیوب، تثبیت ناکارآمدی است.
- معیار موفقیت پروژه را عددی تعریف کنید تا در پایان بتوانید قضاوت کنید.
سازمانی که این سه کار را نکرده باشد، بدون لنگر وارد مذاکره می‌شود و ناچار است چارچوب پیشنهادی فروشنده را بپذیرد.
معیارهایی که واقعاً تعیین‌کننده‌اند
قدرت و صداقت موتور مدل‌سازی
بسیاری از پلتفرم‌ها ادعای پشتیبانی از BPMN 2.0 دارند اما در عمل تنها زیرمجموعه محدودی از عناصر آن را پیاده کرده‌اند. فهرست عناصر پشتیبانی‌شده را مکتوب بخواهید و به‌طور مشخص رفتار رویدادهای میانی، زیرفرآیندها و مدیریت استثنا را آزمون کنید. اینجا همان جایی است که پروژه‌ها در ماه ششم به دیوار می‌خورند.
توان یکپارچگی
BPMS در خلأ کار نمی‌کند؛ باید با سامانه‌های مالی، منابع انسانی، احراز هویت و گاهی سامانه‌های قدیمی بدون واسط استاندارد گفت‌وگو کند. کیفیت لایه یکپارچگی و میزان تلاش لازم برای هر اتصال را با یک سناریوی واقعی از سازمان خودتان بسنجید، نه با اسلاید معماری.
توان کاربر کسب‌وکار
اگر برای تغییر یک قاعده ساده یا افزودن یک فیلد به فرم، باید هفته‌ها در صف تیم فنی بمانید، عملاً چابکی را از دست داده‌اید. بسنجید یک کاربر کسب‌وکاری آموزش‌دیده — همان مفهوم شهروند توسعه‌دهنده — بدون کدنویسی چه کارهایی می‌تواند انجام دهد. این معیار در بلندمدت بیشترین اثر را بر سرعت بهبود سازمان دارد.
پایش و گزارش‌گیری
پلتفرمی که نتواند زمان چرخه، گلوگاه و بار کاری را به‌صورت بومی گزارش دهد، شما را مجبور می‌کند ابزار تحلیلی جداگانه بخرید و داده را بیرون ببرید. توان پایش فعالیت‌های کسب‌وکار را جزو معیارهای درجه‌یک قرار دهید، نه امکانات جانبی.
هزینه کل مالکیت
قیمت لایسنس معمولاً کوچک‌ترین بخش هزینه است. هزینه پیاده‌سازی هر فرآیند، هزینه آموزش، هزینه پشتیبانی سالانه، و مهم‌تر از همه هزینه تغییر در آینده را در محاسبه بیاورید. پلتفرم ارزانی که هر تغییر در آن گران تمام می‌شود، در افق پنج‌ساله گران‌ترین گزینه است.
روش ارزیابی: اثبات مفهوم به‌جای دمو
دمو را فروشنده طراحی می‌کند تا نقاط قوتش را نشان دهد؛ طبیعی هم هست. به‌جای آن، یک یا دو فرآیند واقعی از سازمان خودتان را — ترجیحاً با یک استثنای دشوار — به‌عنوان سناریوی آزمون به گزینه‌های نهایی بدهید و از آن‌ها بخواهید در بازه زمانی محدود پیاده‌سازی کنند. تفاوت‌ها در همین مرحله آشکار می‌شود: نه فقط اینکه آیا توانستند، بلکه اینکه با چه میزان تلاش و چه میزان کدنویسی سفارشی توانستند.
در دمو همه پلتفرم‌ها عالی‌اند. تفاوت‌ها در استثناها آشکار می‌شود.
داخلی یا خارجی؟
پاسخ واحدی ندارد و به زمینه سازمان بستگی دارد. الزامات امنیتی و حاکمیتی، امکان دسترسی به پشتیبانی محلی، توان بومی‌سازی و پایداری تأمین‌کننده، عوامل تعیین‌کننده‌اند. در بسیاری از سازمان‌های حاکمیتی کشور، همین الزامات عملاً دامنه انتخاب را از پیش محدود می‌کند و بحث را به مقایسه میان گزینه‌های داخلی می‌برد.
و یک توصیه پایانی
از موج اول کوچک شروع کنید. یک فرآیند با اثر بالا و پیچیدگی قابل مدیریت را کامل پیاده کنید، الگوهای پیاده‌سازی و استانداردهای داخلی را از دل همان تجربه بسازید، و بعد گسترش دهید. سازمان‌هایی که با قرارداد بزرگ و بیست فرآیند هم‌زمان شروع می‌کنند، معمولاً یک سال بعد هنوز در فاز تحلیل‌اند.
