راهنمافرم و گردش کار
نسخه‌بندی فرایند در BPMS: تغییر فرایند بدون اختلال در درخواست‌های در جریان
نسخه‌بندی فرایند یعنی هر تغییر معنادار در مسیر، شرط یا داده یک نسخه جدید بسازد تا نمونه‌های در جریان با نسخه قبلی ادامه دهند. برای تغییر فرایند در BPMS، نیاز به نسخه جدید را تشخیص دهید، سرنوشت نمونه‌های باز را با مالک فرایند تعیین کنید، نسخه را در پیش‌نویس طراحی و با سناریوهای مرزی آزمون کنید و با یادداشت انتشار، تاریخ اجرا و مرجع تغییر منتشر و پایش کنید.
خلاصه در چند نکته
- تعریف فرایند، نسخه و نمونه سه مفهوم جدا هستند.
- هر تغییری که بر مسیر، تصمیم یا داده اثر دارد نسخه جدید میخواهد.
- رایج‌ترین گزینه، ادامه نمونه‌های در جریان با نسخه قدیم است.
- سرنوشت نمونه‌های باز را مالک فرایند تعیین می‌کند، نه طراح.
- آزمون مرزها مثل دقیقاً ۱۰۰ میلیون، بیشترین خطا را آشکار می‌کند.
- هر نسخه یادداشت انتشار با تاریخ اجرا و مرجع تغییر دارد.
- نسخه قدیم را حذف نکنید تا سابقه ممیزی حفظ شود.
فهرست مطالب
فرایندها ثابت نمی‌مانند. هیئت‌مدیره سقف تأیید خرید را تغییر می‌دهد، یک واحد جدید به ساختار اضافه می‌شود، قانونی تازه مدرک جدیدی را الزامی می‌کند یا تحلیل گلوگاه نشان می‌دهد یک ایستگاه تأیید اضافی است. در همه این حالت‌ها فرایند در سامانه باید عوض شود. اما یک پرسش مهم پیش می‌آید: درخواست‌هایی که همین حالا در جریان‌اند چه می‌شوند؟ آیا با قاعده قدیم ادامه می‌دهند یا ناگهان با قاعده جدید روبه‌رو می‌شوند؟
پاسخ این پرسش در مفهوم نسخه‌بندی فرایند است. این راهنما توضیح می‌دهد تغییر فرایند در BPMS چطور باید مدیریت شود: چه زمانی نسخه جدید لازم است، سرنوشت نمونه‌های در جریان چیست، چطور نسخه جدید را آزمون کنید و یادداشت انتشار چه چیزی باید داشته باشد. در طول مقاله یک مثال واقعی‌نما را دنبال می‌کنیم: تغییر سقف مبلغ تأیید خرید.
نسخه‌بندی فرایند یعنی چه؟
نسخه‌بندی یعنی هر تغییر معنادار در تعریف فرایند، به‌جای بازنویسی تعریف قبلی، یک نسخه جدید بسازد. نسخه قبلی حذف نمی‌شود؛ نمونه‌هایی که با آن شروع شده‌اند، معمولاً با همان ادامه می‌دهند و نمونه‌های جدید با نسخه تازه شروع می‌شوند.
سه مفهوم را از هم جدا کنید:
| مفهوم | تعریف |
|---|---|
| تعریف فرایند | نقشه مسیر: ایستگاه‌ها، شرط‌ها، فرم‌ها، نقش‌ها و مهلت‌ها |
| نسخه | یک ویرایش مشخص از تعریف با شماره و تاریخ انتشار |
| نمونه | یک درخواست واقعی که با یک نسخه مشخص شروع شده است، مثلاً درخواست خرید شماره ۱۲۴ |
اگر سامانه نسخه‌بندی نداشته باشد، ویرایش تعریف ممکن است نمونه‌های باز را خراب کند؛ مثلاً درخواستی که در ایستگاه حذف‌شده منتظر بود، بی‌صاحب بماند.
مثال: تغییر سقف تأیید خرید
فرض کنید آیین‌نامه فعلی می‌گوید:
- خرید تا ۵۰ میلیون تومان: تأیید مدیر واحد.
- خرید بالای ۵۰ میلیون تومان: تأیید مدیر واحد و مدیر مالی.
هیئت‌مدیره تصمیم می‌گیرد از اول ماه آینده:
- خرید تا ۱۰۰ میلیون تومان: تأیید مدیر واحد.
- خرید ۱۰۰ تا ۵۰۰ میلیون تومان: مدیر واحد و مدیر مالی.
- خرید بالای ۵۰۰ میلیون تومان: مدیر واحد، مدیر مالی و مدیرعامل.
این تغییر دو بخش دارد: عوض شدن یک عدد و اضافه شدن یک ایستگاه جدید. هر دو بر نمونه‌های در جریان اثر دارند.
گام ۱: تشخیص دهید آیا نسخه جدید لازم است
همه تغییرها نسخه جدید نمی‌خواهند. یک قاعده ساده:
| نوع تغییر | نسخه جدید؟ | مثال |
|---|---|---|
| تغییر متن راهنما یا برچسب فیلد | معمولاً خیر | اصلاح املای «توضیحات» |
| تغییر شرط یا سقف | بله | سقف ۵۰ به ۱۰۰ میلیون |
| افزودن یا حذف ایستگاه | بله | افزودن تأیید مدیرعامل |
| افزودن فیلد اجباری | بله | الزام پیوست سه پیش‌فاکتور |
| تغییر مهلت خدمت | بله، یا بر اساس سیاست سازمان | مهلت تأیید از ۳ به ۲ روز |
| تغییر نقش مسئول ایستگاه | بله | انتقال تأیید از مدیر مالی به معاون مالی |
قاعده کلی: اگر تغییر بر مسیر، تصمیم یا داده نمونه‌ها اثر دارد، نسخه جدید بسازید.
گام ۲: سرنوشت نمونه‌های در جریان را تعیین کنید
سه گزینه رایج وجود دارد:
- ادامه با نسخه قدیم: نمونه‌های باز با همان قاعده‌ای که شروع شده‌اند تمام می‌شوند. این رایج‌ترین و کم‌ریسک‌ترین گزینه است.
- انتقال به نسخه جدید: نمونه‌های باز به نسخه جدید منتقل می‌شوند. این گزینه فقط وقتی لازم است که قاعده قدیم دیگر قانونی یا مجاز نباشد، و باید با دقت و برای هر نمونه بررسی شود.
- بستن و شروع مجدد: نمونه‌های باز با دلیل بسته و درخواست‌کننده‌ها خواسته می‌شوند درخواست جدید ثبت کنند. فقط برای تغییرهای بنیادی.
در مثال ما، تصمیم منطقی این است که درخواست‌های خریدی که پیش از اول ماه ثبت شده‌اند، با قاعده قدیم ادامه دهند. اما یک سؤال باقی می‌ماند: درخواست ۴۰۰ میلیونی که با قاعده قدیم فقط به مدیر مالی می‌رسد، پس از اول ماه هم بدون تأیید مدیرعامل تأیید شود؟ این تصمیم را مالک فرایند و مدیریت باید بگیرند و مکتوب کنند، نه طراح فرایند.
گام ۳: نسخه جدید را در محیط پیش‌نویس طراحی کنید
تغییرها را روی پیش‌نویس نسخه جدید اعمال کنید، نه روی نسخه منتشرشده. در مثال ما:
- شرط سقف اول از ۵۰ به ۱۰۰ میلیون تغییر می‌کند.
- شرط دوم (۱۰۰ تا ۵۰۰ میلیون) اضافه می‌شود.
- ایستگاه جدید «تأیید مدیرعامل» برای بالای ۵۰۰ میلیون اضافه می‌شود.
- مهلت خدمت ایستگاه جدید و جانشین مدیرعامل تعریف می‌شود.
- گزارش‌ها و داشبوردها برای ایستگاه جدید به‌روز می‌شوند.
گام ۴: آزمون پایلوت
پیش از انتشار، نسخه جدید را با داده آزمایشی و چند کاربر آزمون کنید. سناریوهای آزمون باید مرزها را پوشش دهند:
- [ ] درخواست ۹۹ میلیونی فقط به مدیر واحد برود.
- [ ] درخواست ۱۰۰ میلیونی دقیقاً طبق آیین‌نامه رفتار کند (مرز را روشن کنید: «تا ۱۰۰» یعنی شامل ۱۰۰؟).
- [ ] درخواست ۳۰۰ میلیونی به مدیر واحد و مدیر مالی برود.
- [ ] درخواست ۶۰۰ میلیونی به مدیرعامل هم برسد.
- [ ] اگر مدیرعامل در مرخصی است، درخواست به جانشین برسد.
- [ ] رد در ایستگاه مدیرعامل، درخواست را با دلیل به درخواست‌کننده برگرداند.
- [ ] گزارش‌ها ایستگاه جدید را نشان دهند.
مرزها جایی است که بیشترین خطا رخ می‌دهد. یک «بزرگ‌تر از» به‌جای «بزرگ‌تر یا مساوی» می‌تواند درخواست‌های دقیقاً ۱۰۰ میلیونی را به مسیر اشتباه بفرستد.
گام ۵: یادداشت انتشار بنویسید
هر نسخه جدید باید یک یادداشت انتشار کوتاه داشته باشد. نمونه:
فرایند درخواست خرید – نسخه ۴ تاریخ اجرا: ۱ آذر مرجع تغییر: مصوبه هیئت‌مدیره، جلسه شماره [شماره] تغییرات: سقف تأیید مدیر واحد از ۵۰ به ۱۰۰ میلیون تومان افزایش یافت؛ برای خرید بالای ۵۰۰ میلیون تومان تأیید مدیرعامل الزامی شد. نمونه‌های در جریان: درخواست‌های ثبت‌شده پیش از ۱ آذر با نسخه ۳ ادامه می‌یابند. مالک فرایند: مدیر امور مالی تأییدکننده انتشار: [نام و سمت]
یادداشت انتشار را در پایگاه دانش سازمان منتشر کنید و به کاربران فرایند اطلاع دهید.
گام ۶: انتشار و پایش
نسخه جدید را در تاریخ اجرا منتشر کنید. در دو هفته اول، این موارد را پایش کنید:
- آیا نمونه‌های جدید با نسخه ۴ شروع می‌شوند؟
- آیا نمونه‌های قدیمی بدون مشکل با نسخه ۳ تمام می‌شوند؟
- آیا زمان تأیید در ایستگاه جدید در مهلت است؟
- آیا کاربران سؤال یا شکایت تکراری دارند؟
برای پایش زمان و صف ایستگاه‌ها، روش‌های مقاله پیدا کردن گلوگاه فرایند کاربرد دارد.
تغییر فرم همراه با فرایند
بسیاری از تغییرهای فرایند با تغییر فرم همراه‌اند؛ مثلاً در مثال ما ممکن است برای خریدهای بالای ۵۰۰ میلیون، پیوست «توجیه فنی» اجباری شود. در این حالت دو نکته مهم است:
- درخواست‌های قدیمی با طرح قدیم فرم خوانده شوند. اگر فیلد جدیدی اضافه شده، درخواست‌های پیش از تغییر نباید به‌خاطر خالی بودن آن فیلد ناقص به نظر برسند.
- گزارش‌ها هر دو طرح را پوشش دهند. گزارش ماهانه خرید نباید با تغییر فرم بشکند یا ستون‌ها جابه‌جا شوند.
چه زمانی تغییر را جمع کنیم؟
تغییرهای کوچک پیاپی کاربران را سردرگم می‌کند. اگر چند تغییر در صف دارید، بهتر است آن‌ها را در یک نسخه جمع کنید و در تاریخ مشخص منتشر کنید؛ مثلاً یک انتشار در هر فصل، به‌جز تغییرهای فوری قانونی یا امنیتی. این کار آموزش کاربران و پایش را هم ساده‌تر می‌کند.
اشتباهات رایج در تغییر فرایند
- ویرایش مستقیم نسخه منتشرشده: نمونه‌های باز خراب می‌شوند.
- تغییر بدون مرجع: معلوم نیست چه کسی و بر اساس چه مصوبه‌ای سقف را عوض کرده است.
- آزمون نکردن مرزها: خطای «بزرگ‌تر» و «بزرگ‌تر یا مساوی».
- فراموشی جانشین برای ایستگاه جدید: درخواست در مرخصی مدیرعامل می‌خوابد.
- اطلاع ندادن به کاربران: درخواست‌کننده تعجب می‌کند چرا درخواستش به مدیرعامل رفته است.
- حذف نسخه قدیم: سابقه ممیزی نمونه‌های قدیمی از بین می‌رود.
نقش‌ها در مدیریت تغییر فرایند
| نقش | مسئولیت |
|---|---|
| مالک فرایند | تصمیم درباره تغییر و سرنوشت نمونه‌های در جریان |
| تحلیل‌گر یا طراح فرایند | طراحی نسخه جدید و آزمون |
| کاربران کلیدی | شرکت در پایلوت |
| مدیریت یا مرجع مصوبه | تأیید تغییر |
| فناوری اطلاعات | انتشار و پایش فنی |
برای روشن کردن این نقش‌ها، ماتریس RACI ابزار مناسبی است. اگر تغییر به فرایند تأیید قرارداد مربوط است، مقاله گردش‌کار تأیید قرارداد را هم ببینید.
نسخه‌بندی فرایند در آریا آی‌تی
BPMS آریا آی‌تی برای تحلیل‌گر و معمار فرایند طراحی شده است: نسخه‌بندی فرایند، زیرفرایند، قواعد کسب‌وکار، مهلت خدمت، شاخص فرایند و تحلیل گلوگاه دارد و طبق صفحه محصول، انتشار نسخه جدید بدون قطع نمونه در حال اجرا انجام می‌شود. گردش‌کار مسیر تأیید روزمره را با شرط مبلغ، تأیید موازی یا ترتیبی، مهلت و تشدید اجرا می‌کند. در راهکار سفارشی گردش تأیید و کنترل تغییر هم سقف‌ها و ایستگاه‌ها از آیین‌نامه همان سازمان پیکربندی می‌شوند. طبق صفحه تعرفه، گردش‌کار و مدیریت فرایند در پلن سازمانی قرار دارند.
جمع‌بندی
تغییر فرایند در BPMS بدون نسخه‌بندی ریسک خراب شدن درخواست‌های در جریان را دارد. هر تغییری که بر مسیر، تصمیم یا داده اثر دارد، نسخه جدید بسازد؛ سرنوشت نمونه‌های باز را مالک فرایند تعیین کند؛ نسخه جدید در پیش‌نویس طراحی و با سناریوهای مرزی آزمون شود؛ و با یادداشت انتشار، تاریخ اجرا و مرجع تغییر منتشر و پایش گردد.
فرایند را بدون توقف تغییر دهید: برای بررسی نسخه‌بندی و BPMS آریا آی‌تی مشاوره رایگان بگیرید یا ۷ روز رایگان شروع کنید.
مراحل انجام کار
نیاز به نسخه جدید را تشخیص دهید
اگر تغییر بر مسیر، تصمیم یا داده نمونه‌ها اثر دارد، نسخه جدید بسازید.
سرنوشت نمونه‌های در جریان را تعیین کنید
مالک فرایند بین ادامه با نسخه قدیم، انتقال یا بستن و شروع مجدد تصمیم بگیرد.
نسخه را در پیش‌نویس طراحی کنید
شرط‌ها، ایستگاه‌ها، مهلت، جانشین و گزارش‌ها را روی پیش‌نویس تغییر دهید.
آزمون پایلوت انجام دهید
سناریوهای مرزی، جانشینی و رد را با داده آزمایشی آزمون کنید.
یادداشت انتشار بنویسید
تاریخ اجرا، مرجع تغییر، تغییرات، تکلیف نمونه‌های باز و مالک را ثبت کنید.
منتشر و پایش کنید
در تاریخ اجرا منتشر کنید و دو هفته رفتار نمونه‌ها و زمان ایستگاه‌ها را پایش کنید.
پرسش‌های متداول
نسخه‌بندی فرایند چیست؟
+
یعنی هر تغییر معنادار در تعریف فرایند یک نسخه جدید بسازد و نسخه قبلی حذف نشود؛ نمونه‌هایی که با نسخه قبلی شروع شده‌اند معمولاً با همان ادامه می‌دهند.
با تغییر فرایند، درخواست‌های در جریان چه می‌شوند؟
+
سه گزینه رایج است: ادامه با نسخه قدیم، انتقال به نسخه جدید یا بستن و شروع مجدد. ادامه با نسخه قدیم کم‌ریسک‌ترین است و تصمیم نهایی با مالک فرایند است.
آیا هر تغییری نسخه جدید میخواهد؟
+
خیر. تغییر متن راهنما یا برچسب معمولاً نسخه نمیخواهد، اما تغییر شرط، سقف، ایستگاه، فیلد اجباری یا نقش مسئول نسخه جدید لازم دارد.
یادداشت انتشار فرایند چه بخش‌هایی دارد؟
+
نام و شماره نسخه، تاریخ اجرا، مرجع تغییر، شرح تغییرات، تکلیف نمونه‌های در جریان، مالک فرایند و تأییدکننده انتشار.