قیمت BPMS را نمی‌توان با یک عدد عمومی برای همه سازمان‌ها بیان کرد. هزینه نهایی از خود نرم‌افزار فراتر می‌رود و به دامنه استفاده، کاربران، فرایندها، قابلیت‌های موردنیاز، نحوه استقرار، یکپارچه‌سازی با سامانه‌های موجود و حجم خدمات اجرایی بستگی دارد.
بنابراین برای گرفتن یک قیمت قابل اتکا، قبل از هر چیز باید مشخص شود دقیقاً چه چیزی قرار است خریداری، پیاده‌سازی و نگهداری شود.
این مقاله قرار نیست عددی فرضی برای قیمت BPMS ارائه کند. هدف این است که قبل از استعلام قیمت بتوانید سه سؤال را پاسخ دهید:
چه چیزهایی هزینه را می‌سازند؟ پروژه ما از نظر اجرایی چقدر پیچیده است؟ و وقتی چند پیشنهاد مالی دریافت کردیم، چطور آن‌ها را درست مقایسه کنیم؟
هزینه BPMS از چه اجزایی تشکیل می‌شود؟
وقتی درباره «قیمت BPMS»صحبت می‌کنیم، بهتر است مبلغ را در چند بخش جدا ببینیم. در غیر این صورت ممکن است قیمت لایسنس یک محصول را با هزینه کامل اجرای محصول دیگری مقایسه کنیم.
بخش هزینه | شامل چه چیزی می‌شود؟ |
نرم‌افزار و لایسنس | حق استفاده از پلتفرم براساس مدل تجاری ارائه‌دهنده |
زیرساخت و استقرار | محیط موردنیاز برای نصب و بهره‌برداری |
پیاده‌سازی | تحلیل، طراحی، ساخت و آماده‌سازی فرایندها برای اجرا |
یکپارچه‌سازی | ارتباط با سامانه‌ها، APIها، سرویس‌ها و منابع داده موجود |
آموزش و انتقال دانش | آماده‌سازی تیم‌هایی که قرار است با سامانه کار یا آن را توسعه دهند |
پشتیبانی و توسعه بعدی | خدمات پس از بهره‌برداری، تغییرات و توسعه‌های آینده |
این تفکیک در مذاکره اهمیت زیادی دارد.
ممکن است یک پیشنهاد فقط قیمت نرم‌افزار را اعلام کرده باشد، درحالی‌که پیشنهاد دیگری بخشی از استقرار، آموزش یا پیاده‌سازی اولیه را نیز پوشش دهد. مقایسه رقم نهایی بدون دیدن اجزای آن، نتیجه قابل اعتمادی نمی‌دهد.
برای بررسی شرایط مربوط به خود نرم‌افزار و مدل دریافت آن در GraphBPMS، صفحه خرید و لایسنس BPMS موضوع را از زاویه تجاری دنبال می‌کند.
چه عواملی دامنه هزینه BPMS را تغییر می‌دهند؟
همه عوامل به یک اندازه روی پروژه اثر ندارند. بعضی مستقیماً به مدل تجاری نرم‌افزار مربوط‌اند و بعضی حجم کاری را که برای رسیدن به بهره‌برداری لازم است تغییر می‌دهند.
عامل | چه چیزی دامنه پروژه را بزرگ‌تر می‌کند؟ |
کاربران و واحدها | افزایش نقش‌ها، واحدهای درگیر و گستره استفاده |
فرایندها | تعداد بیشتر یا منطق پیچیده‌تر فرایندها |
قواعد کسب‌وکار | تصمیم‌های متعدد، شرایط متغیر و قواعد پیچیده |
استثناها | برگشت‌ها، مسیرهای خاص و حالت‌های غیرعادی بیشتر |
یکپارچه‌سازی | تعداد بیشتر سامانه‌ها یا ارتباط‌های پیچیده‌تر |
سامانه‌های قدیمی | نبود API مناسب، مستندات محدود یا محدودیت فنی |
استقرار | الزامات خاص زیرساختی و محیط‌های موردنیاز |
خدمات پروژه | نیاز بیشتر به تحلیل، طراحی، پیاده‌سازی، تست و آموزش |
نگهداری | میزان تغییری که بعد از بهره‌برداری پیش‌بینی می‌شود |
تعداد کاربران مهم است، اما تصویر کامل را نمی‌دهد
در بعضی مدل‌های تجاری، تعداد یا نوع کاربران می‌تواند یکی از عوامل قیمت نرم‌افزار باشد. اما برای برآورد کل پروژه، تعداد کاربر به‌تنهایی کافی نیست.
صد کاربری که یک فرایند نسبتاً مشخص را اجرا می‌کنند، الزاماً پروژه پیچیده‌تری از سازمانی با کاربران کمتر اما چند فرایند بین‌واحدی و یکپارچه‌سازی‌های متعدد ایجاد نمی‌کنند.
پس هنگام استعلام، کنار تعداد کاربران باید نوع استفاده هم روشن باشد.
پیچیدگی فرایند از تعداد فرایند مهم‌تر است
«ده فرایند» به‌تنهایی اطلاعات زیادی درباره حجم پیاده‌سازی نمی‌دهد.
ممکن است بیشتر آن‌ها مسیرهای کوتاه و قواعد مشخص داشته باشند. در مقابل، یک فرایند واحد می‌تواند چند واحد، تصمیم‌های متعدد، زیر‌فرایند، استثنا و ارتباط با چند سامانه دیگر داشته باشد.
برای همین در برآورد پروژه باید تعداد و پیچیدگی را کنار هم دید.
یکپارچه‌سازی یکی از متغیرهای جدی پروژه است
وجود API به‌تنهایی به معنی ساده‌بودن اتصال نیست.
باید دید چه داده‌ای ردوبدل می‌شود، ارتباط یک‌طرفه است یا دوطرفه، احراز هویت چگونه انجام می‌شود، خطا چگونه مدیریت می‌شود و سامانه مقصد چه محدودیت‌هایی دارد.
تفاوت میان اتصال به یک سرویس مستند و اتصال به یک سامانه قدیمی که رابط مناسبی ندارد، می‌تواند روی دامنه کار اثر قابل توجهی بگذارد.
پروژه شما از نظر پیچیدگی در چه سطحی قرار می‌گیرد؟
به‌جای اینکه پروژه را فقط با عباراتی مثل «کوچک» یا «بزرگ» توصیف کنیم، بهتر است چند محور مشخص را بررسی کنیم.
جدول زیر فرمول قیمت نیست. هدف آن این است که قبل از استعلام، تصویری واقع‌بینانه‌تر از دامنه پروژه داشته باشید.
عامل | پیچیدگی پایین | پیچیدگی متوسط | پیچیدگی بالا |
فرایندها | چند فرایند با مسیر نسبتاً روشن | چند فرایند بین‌واحدی | فرایندهای متعدد یا بسیار پیچیده |
نقش‌ها و واحدها | تعداد محدود نقش و واحد | چند واحد با مسئولیت‌های متفاوت | نقش‌ها و ساختار سازمانی گسترده |
قواعد کسب‌وکار | تصمیم‌های محدود و نسبتاً ثابت | چند قاعده و مسیر شرطی | قواعد زیاد، متغیر یا وابسته به چند داده |
استثناها | مسیرهای جایگزین محدود | برگشت و حالت‌های خاص شناخته‌شده | استثناهای متعدد یا رفتارهای پیچیده |
یکپارچه‌سازی | بدون اتصال یا اتصال محدود | چند سامانه با رابط مشخص | چند سامانه با منطق ارتباطی متفاوت |
وضعیت سامانه‌های موجود | API یا سرویس مناسب | محدودیت‌هایی در برخی سامانه‌ها | سامانه قدیمی، APIمحدود یا وابستگی فنی بالا |
استقرار | معماری نسبتاً استاندارد | چند الزام زیرساختی مشخص | محدودیت‌های زیرساختی یا محیطی ویژه |
تحلیل اولیه | فرایندها نسبتاً مشخص‌اند | نیاز به جلسات تحلیل وجود دارد | فرایندها نیازمند کشف و تحلیل گسترده‌اند |
پیاده‌سازی | تیم سازمان بخش زیادی از نیاز را می‌شناسد | کار بین تیم داخلی و مجری تقسیم می‌شود | وابستگی بیشتر به تحلیل و اجرای تخصصی |
اگر بیشتر شرایط پروژه در ستون «پیچیدگی پایین» قرار می‌گیرند، احتمالاً دامنه اولیه قابل‌کنترل‌تر است.
وقتی چند واحد، قواعد متعدد و چند یکپارچه‌سازی وارد پروژه می‌شوند، حجم تحلیل، ساخت و تست افزایش پیدا می‌کند.
و اگر علاوه بر این موارد، سامانه‌های قدیمی، استثناهای زیاد یا فرایندهای هنوز نامشخص هم وجود داشته باشند، قبل از اعلام یک قیمت قابل دفاع معمولاً به شناخت دقیق‌تری از پروژه نیاز است.
نکته مهم این است که اندازه سازمان به‌تنهایی سطح پیچیدگی پروژه را تعیین نمی‌کند. یک سازمان بزرگ می‌تواند فاز اول محدودی تعریف کند و یک مجموعه کوچک‌تر ممکن است از همان ابتدا سناریوی فنی دشواری داشته باشد.
چه هزینه‌هایی معمولاً در برآورد اولیه فراموش می‌شوند؟
بعضی هزینه‌ها مستقیماً روی ردیف «لایسنس» دیده نمی‌شوند، اما برای اجرای واقعی پروژه منابع مصرف می‌کنند.
زمان تیم داخلی سازمان
تحلیلگر فرایند، مدیر واحد، ITو کاربران کلیدی باید در بخش‌هایی از پروژه حضور داشته باشند؛ از توضیح نیازها تا تأیید طراحی و تست نهایی.
حتی وقتی کل پیاده‌سازی برون‌سپاری شده، پروژه بدون مشارکت سازمان پیش نمی‌رود.
آماده‌سازی داده و سامانه‌های مقصد
گاهی مشکل اصلی خود BPMS نیست.
ممکن است API آماده نباشد، داده موردنیاز کیفیت مناسبی نداشته باشد، دسترسی فنی ایجاد نشده باشد یا تغییراتی در سامانه مقصد لازم شود.
این وابستگی‌ها باید زودتر شناسایی شوند.
محیط‌های غیرعملیاتی
فقط محیط اصلی بهره‌برداری را در نظر نگیرید.
بسته به معماری پروژه ممکن است محیط‌های دیگری برای توسعه یا تست لازم باشند. مسئولیت آماده‌سازی و نگهداری این محیط‌ها باید مشخص شود.
تست و پذیرش کاربر
فرایند باید با داده و رفتار واقعی بررسی شود.
زمان موردنیاز برای تست سناریوهای اصلی، استثناها و پذیرش کاربران بخشی از پروژه است؛ حتی اگر در پیشنهاد اولیه به شکل یک ردیف مالی مستقل دیده نشود.
آموزش و انتقال دانش
کسی باید بعد از راه‌اندازی بداند با سامانه چگونه کار کند.
اگر تیم داخلی قرار است فرایند یا فرم جدید بسازد، دامنه آموزش با حالتی که کاربران فقط فعالیت‌های روزمره خود را انجام می‌دهند یکسان نیست.
تغییرات بعد از شروع استفاده
بعضی نیازها تازه بعد از بهره‌برداری واقعی دیده می‌شوند.
فرم تغییر می‌کند، یک قاعده جدید اضافه می‌شود، مسئولیت یک مرحله عوض می‌شود یا ارتباط تازه‌ای با سامانه دیگر لازم می‌شود.
برای همین هزینه تغییر بعد از Go-Live باید در ارزیابی مالی دیده شود، نه اینکه تمام توجه روی پروژه اولیه باشد.
برای استعلام قیمت BPMS چه اطلاعاتی آماده کنیم؟
این بخش را می‌توانید مستقیماً به‌عنوان چک‌لیست پیش از مذاکره با ارائه‌دهنده استفاده کنید.
مشخصات کاربران و ساختار سازمانی
- تعداد تقریبی کاربران
- نوع کاربران و نقش‌های اصلی
- واحدهای سازمانی درگیر
- گستره استفاده در فاز اول
فرایندهای فاز اول
- فهرست فرایندهایی که واقعاً قرار است پیاده‌سازی شوند
- اولویت آن‌ها
- شروع و پایان هر فرایند
- واحدها و نقش‌های درگیر
- برآورد اولیه از میزان پیچیدگی هر فرایند
قواعد و استثناها
- تصمیم‌های مهم داخل هر فرایند
- قواعد کسب‌وکار تأثیرگذار بر مسیر
- برگشت‌ها و مسیرهای جایگزین
- استثناهای شناخته‌شده
لازم نیست تمام قواعد از ابتدا مستند شده باشند؛ اما اگر بخش مهمی از منطق هنوز ناشناخته است، باید در دامنه تحلیل پروژه دیده شود.
سامانه‌های نیازمند یکپارچه‌سازی
برای هر سامانه مشخص کنید:
- چه اطلاعاتی باید دریافت شود؟
- چه اطلاعاتی باید ارسال شود؟
- آیا API یا سرویس مشخصی وجود دارد؟
- مستندات فنی در دسترس است؟
- چه تیمی مسئول سامانه مقصد است؟
- آیا محدودیت شناخته‌شده‌ای وجود دارد؟
استقرار و زیرساخت
- محل موردنظر برای استقرار
- محدودیت‌های زیرساختی
- محیط‌های موردنیاز
- مسئولیت تیم داخلی و ارائه‌دهنده در آماده‌سازی زیرساخت
خدمات موردنیاز
مشخص کنید سازمان از ارائه‌دهنده چه انتظاری دارد:
- تحلیل فرایند
- طراحی راهکار
- پیاده‌سازی
- تست
- آموزش
- انتقال دانش
- پشتیبانی پس از بهره‌برداری
- توسعه‌های بعدی
وضعیت تیم داخلی
این سؤال روی هزینه دوره بهره‌برداری اثر زیادی دارد:
بعد از راه‌اندازی، چه کسی قرار است تغییرات معمول را انجام دهد؟
اگر قرار است بخشی از توسعه و نگهداری به تیم داخلی منتقل شود، سطح آموزش و مهارت موردنیاز باید از ابتدا مشخص شود.
هرچه این اطلاعات روشن‌تر باشند، احتمال اینکه پیشنهاد مالی براساس فرض‌های متفاوت تهیه شود کمتر خواهد شد.
چطور پیشنهاد قیمت ارائه‌دهنده‌ها را با هم مقایسه کنیم؟
دو پیشنهاد را فقط از روی رقم پایین صفحه مقایسه نکنید.
ابتدا آن‌ها را به یک قالب مشترک تبدیل کنید.
موضوع | در هر پیشنهاد چه چیزی باید روشن باشد؟ |
مدل لایسنس | مبنای محاسبه حق استفاده چیست؟ |
دامنه کاربران | چه کاربران یا ظرفیتی در پیشنهاد لحاظ شده است؟ |
قابلیت‌ها | چه بخش‌هایی از پلتفرم در دامنه قرار دارند؟ |
محیط‌ها | محیط تست، توسعه یا عملیاتی چگونه دیده شده‌اند؟ |
یکپارچه‌سازی | چه اتصال‌هایی داخل پیشنهاد هستند؟ |
تحلیل | چه میزان تحلیل فرایند و نیازمندی انجام می‌شود؟ |
پیاده‌سازی | چه فرایندها و خروجی‌هایی تحویل می‌شوند؟ |
تست | مسئولیت تست فنی و پذیرش کاربر با چه کسی است؟ |
آموزش | چه کسانی و در چه سطحی آموزش می‌بینند؟ |
پشتیبانی | چه نوع خدمتی بعد از بهره‌برداری ارائه می‌شود؟ |
هزینه‌های تکرارشونده | چه هزینه‌هایی بعداً ادامه پیدا می‌کنند؟ |
خارج از دامنه | چه مواردی صراحتاً در قیمت محاسبه نشده‌اند؟ |
بخش خارج از دامنه را با همان دقت مبلغ نهایی بخوانید.
ممکن است اتصال به یک سامانه، انتقال داده، آموزش تیم توسعه یا تغییرات بعد از تحویل در پیشنهاد اول لحاظ شده باشد و در پیشنهاد دوم نه.
در چنین شرایطی، عدد پایین‌تر الزاماً پیشنهاد ارزان‌تر نیست؛ فقط دامنه دو پیشنهاد متفاوت است.
بعد از هم‌سطح‌کردن دامنه مالی، تازه می‌توان سراغ معیارهای فنی و انتخاب محصول رفت. اگر در این مرحله هستید، راهنمای مقایسه و انتخاب بهترین نرم‌افزار BPMS این بخش از تصمیم را جداگانه بررسی می‌کند.
هزینه کل مالکیت یا TCO در BPMS چیست؟
هزینه کل مالکیت یا TCOکمک می‌کند تصمیم را فقط براساس هزینه شروع پروژه نگیریم.
در ساده‌ترین نگاه، TCO را می‌توان چنین دید:
هزینه نرم‌افزار + استقرار و زیرساخت + پیاده‌سازی + یکپارچه‌سازی + آموزش + پشتیبانی + توسعه و تغییرات آینده
این یک فرمول برای محاسبه قیمت نیست؛ چارچوبی است برای اینکه چیزی از قلم نیفتد.
در BPMS، بخش «تغییرات آینده» اهمیت ویژه‌ای دارد. فرایند سازمان ثابت نمی‌ماند. نقش‌ها تغییر می‌کنند، قواعد اصلاح می‌شوند، فرم‌ها نیاز تازه پیدا می‌کنند و سامانه‌های دیگر نیز ارتقا یا جایگزین می‌شوند.
در نتیجه هنگام ارزیابی یک پلتفرم فقط نپرسید ساخت نسخه اول چقدر هزینه دارد.
بپرسید:
تغییر یک فرایند بعداً چگونه انجام می‌شود؟
اصلاح یک قاعده تصمیم چه میزان درگیری فنی ایجاد می‌کند؟
اگر API یک سامانه تغییر کند، مسئول اصلاح اتصال چه کسی است؟
تیم داخلی چه بخش‌هایی را می‌تواند خودش مدیریت کند؟
پاسخ این سؤال‌ها مشخص می‌کند هزینه پروژه در سال‌های بعد فقط تابع قرارداد پشتیبانی نیست؛ معماری محصول و مدل نگهداری نیز در آن نقش دارند.
GraphBPMS در این ساختار هزینه‌ای چه رویکردی دارد؟
برای GraphBPMS هم برآورد دقیق پس از شناخت دامنه و نیاز پروژه انجام می‌شود. اما هنگام ارزیابی هزینه دوره بهره‌برداری، فقط مبلغ اولیه مهم نیست؛ شیوه اعمال تغییرات، یکپارچه‌سازی و میزان کاری که تیم داخلی می‌تواند بر عهده بگیرد نیز اهمیت دارد.
تغییر فرایند و قواعد کسب‌وکار
GraphBPMS امکان مدل‌سازی فرایند مبتنی بر BPMN 2.0 را فراهم می‌کند و قواعد کسب‌وکار نیز می‌توانند مستقل از منطق اصلی فرایند تعریف شوند.
در سناریوهای مناسب، تغییر یک قاعده الزاماً به معنی بازطراحی منطق اصلی فرایند نیست.
این موضوع هنگام برآورد نگهداری اهمیت دارد؛ چون باید بدانید تغییرات متداول از طریق ابزارهای خود پلتفرم قابل انجام‌اند یا برای هر تغییر به توسعه تخصصی نیاز خواهد بود.
یکپارچه‌سازی با سامانه‌های موجود
GraphBPMS می‌تواند براساس API، سرویس و منابع داده موجود سازمان با سامانه‌های دیگر یکپارچه شود.
حجم کار هر اتصال همچنان به وضعیت سامانه مقصد، رابط‌های موجود، ساختار داده و منطق تبادل اطلاعات وابسته است. به همین دلیل بهتر است یکپارچه‌سازی‌ها از همان مرحله برآورد به‌صورت مشخص وارد دامنه پروژه شوند.
تیم داخلی و خدمات تخصصی
آموزش و انتقال دانش می‌تواند بخشی از مدل همکاری GraphBPMS باشد تا تیم داخلی متناسب با مهارت و دامنه راهکار، بخشی از توسعه‌های آینده را با اتکای بیشتری به ظرفیت خودش پیش ببرد.
در مقابل، خدمات تخصصی مانند توسعه یا تغییر فرایند، فرم، گزارش، سفارشی‌سازی و یکپارچه‌سازی نیز می‌توانند متناسب با نیاز پروژه تعریف شوند و نباید به‌صورت پیش‌فرض جزئی از قیمت لایسنس فرض شوند.
این ویژگی‌ها به‌تنهایی به معنی پایین‌تر بودن قطعی TCO نیستند؛ اما کمک می‌کنند هنگام برآورد هزینه، مشخص شود چه تغییراتی داخل ظرفیت پلتفرم و تیم سازمان قرار می‌گیرند و برای چه بخش‌هایی باید خدمات تخصصی جداگانه در نظر گرفت.
هزینه BPMS برای سازمان شما چگونه مشخص می‌شود؟
در پایان، مسئله اصلی پیدا کردن یک «قیمت عمومی BPMS» نیست.
برای یک برآورد قابل دفاع باید مشخص شود چه کسانی از سامانه استفاده می‌کنند، چه فرایندهایی در فاز اول قرار دارند، پیچیدگی آن‌ها چقدر است، چه سیستم‌هایی باید متصل شوند، زیرساخت چه شرایطی دارد و سازمان چه میزان خدمات اجرایی و پشتیبانی می‌خواهد.
اگر اطلاعات اولیه پروژه‌تان را براساسچک‌لیست بالا آماده کرده‌اید، می‌توانید برای بررسی دامنه پروژه و دریافت برآورد متناسب با سناریوی سازمانتان با تیم گراف در ارتباط باشید.
سؤالات متداول درباره قیمت BPMS
آیا نرم‌افزار BPMS قیمت ثابتی دارد؟
مدل قیمت‌گذاری محصولات مختلف یکسان نیست. در پروژه‌های سازمانی، عواملی مانند مدل لایسنس، دامنه استفاده، قابلیت‌های موردنیاز، استقرار، پیاده‌سازی و خدمات می‌توانند روی پیشنهاد نهایی اثر بگذارند.
آیا قیمت BPMS به تعداد کاربران بستگی دارد؟
ممکن است تعداد یا نوع کاربران یکی از عوامل مدل تجاری یک محصول باشد، اما تعداد کاربر به‌تنهایی هزینه کل پروژه را مشخص نمی‌کند. پیچیدگی فرایندها، یکپارچه‌سازی‌ها و خدمات اجرایی نیز باید در نظر گرفته شوند.
آیا هزینه پیاده‌سازی BPMS جدا از لایسنس است؟
لایسنس و خدمات پیاده‌سازی دو مفهوم جدا هستند؛ اما نحوه ارائه و قرارداد میان محصولات و ارائه‌دهندگان تفاوت دارد. در هر پیشنهاد باید مشخص باشد چه خدماتی در مبلغ اعلام‌شده قرار دارند و چه مواردی جداگانه محاسبه می‌شوند.
یکپارچه‌سازی با ERP یا سایر سامانه‌ها چه اثری بر هزینه دارد؟
اثر آن به تعداد اتصال‌ها و خصوصاً پیچیدگی هر اتصال بستگی دارد. وجود API، کیفیت مستندات، ساختار داده، روش احراز هویت و محدودیت‌های سامانه مقصد می‌توانند حجم کار را تغییر دهند.
برای دریافت قیمت دقیق BPMS چه اطلاعاتی باید آماده کنیم؟
اطلاعات اولیه کاربران و واحدها، فرایندهای فاز اول، میزان پیچیدگی آن‌ها، قواعد و استثناهای مهم، سامانه‌های نیازمند یکپارچه‌سازی، شرایط استقرار و سطح خدمات موردنیاز برای تحلیل، پیاده‌سازی، آموزش و پشتیبانی کمک می‌کنند برآورد دقیق‌تری تهیه شود.
قیمت GraphBPMS چگونه مشخص می‌شود؟
قیمت دقیق GraphBPMS پس از بررسی دامنه و نیاز پروژه و در قالب پیشنهاد تجاری مشخص می‌شود. عواملی مانند نوع استفاده، ظرفیت، قابلیت‌های موردنیاز و سطح خدمات می‌توانند در پیشنهاد نهایی مؤثر باشند.