نسخه‌بندی فرایند در BPMS چیست؟

فرض کنید فرآیند درخواست خرید در سازمان اجرا شده است. در نسخه فعلی، درخواست ابتدا توسط مدیر واحد و سپس مدیر مالی تأیید می‌شود. چند ماه بعد سازمان تصمیم می‌گیرد برای درخواست‌های بیشتر از یک مبلغ مشخص، مرحله تأیید مدیرعامل نیز به فرآیند اضافه شود. در این شرایط یک سؤال مهم مطرح می‌شود: تکلیف درخواست‌هایی که قبل از این تغییر ثبت شده‌اند چیست؟

اگر فرایند بدون مدیریت نسخه تغییر کند، ممکن است درخواست‌هایی که همین حالا در جریان هستند با مسیری مواجه شوند که هنگام شروع آنها وجود نداشته است. همین مسئله می‌تواند باعث خطا، توقف فرآیند یا ایجاد ابهام در سوابق شود. نسخه‌بندی فرایند در BPMS برای مدیریت همین وضعیت استفاده می‌شود. سازمان می‌تواند نسخه جدیدی از فرآیند منتشر کند، بدون اینکه الزاماً نسخه قبلی یا نمونه‌های در حال اجرای آن از بین بروند.

در نرم‌افزار BPMS نیز امکان تغییر و بهبود فرآیندها اهمیت زیادی دارد؛ زیرا فرآیند سازمان یک ساختار ثابت نیست و ممکن است با تغییر قوانین، ساختار سازمانی، سیاست‌ها یا نیازهای کسب‌وکار اصلاح شود.

نسخه‌بندی فرایند چیست؟

Process Versioning یعنی نگهداری نسخه‌های مختلف یک تعریف فرآیند به‌گونه‌ای که مشخص باشد هر درخواست بر اساس کدام نسخه شروع و اجرا شده است.

برای مثال:

نسخه ۱: تأیید مدیر واحد ← مالی
نسخه ۲: تأیید مدیر واحد ← مالی ← مدیرعامل
نسخه ۳: اضافه شدن کنترل بودجه قبل از مدیر مالی

در این حالت هر سه نسخه بخشی از تاریخچه فرآیند هستند، اما معمولاً فقط آخرین نسخه برای شروع درخواست‌های جدید استفاده می‌شود. در بسیاری از موتورهای BPMS، انتشار مجدد یک فرآیند با همان شناسه باعث ایجاد نسخه جدید می‌شود و نمونه‌های جدید با آخرین نسخه آغاز می‌شوند. نمونه‌های قبلی نیز می‌توانند روی همان نسخه‌ای که با آن شروع شده‌اند باقی بمانند.

چرا نباید نسخه قبلی فرایند را مستقیماً تغییر دهیم؟

یک فرایند اجرایی فقط یک نمودار نیست. ممکن است صدها درخواست در نقاط مختلف آن در حال اجرا باشند. فرض کنید یکی از درخواست‌ها در مرحله «تأیید مالی» نسخه اول متوقف است. اگر طراحی فرآیند را مستقیماً تغییر دهیم و همان فعالیت را حذف یا جایگزین کنیم، موتور فرآیند باید بداند نمونه قبلی اکنون دقیقاً در کدام مرحله از ساختار جدید قرار می‌گیرد.

نسخه‌بندی این ریسک را کاهش می‌دهد. به‌جای دستکاری تعریف مورد استفاده نمونه‌های جاری، نسخه جدید مستقلی منتشر می‌شود. این جداسازی کمک می‌کند بدانیم هر پرونده با چه قواعد و چه ساختاری اجرا شده است. این موضوع برای ممیزی و پیگیری سوابق نیز مهم است؛ چون باید بتوان مشخص کرد فرآیندی که شش ماه قبل انجام شده، در آن زمان دقیقاً چه مراحلی داشته است.

بعد از انتشار نسخه جدید چه اتفاقی می‌افتد؟

یک مدل رایج در BPMSها این است:

درخواست‌های جدید → نسخه جدید

درخواست‌های قبلی → نسخه‌ای که با آن شروع شده‌اند

برای مثال، اگر نسخه ۲ فرآیند خرید امروز منتشر شود، درخواست فردا با نسخه ۲ شروع خواهد شد. اما درخواست ثبت‌شده هفته قبل می‌تواند تا پایان مسیر با نسخه ۱ ادامه دهد. این روش باعث می‌شود انتشار تغییرات منتظر پایان تمام نمونه‌های جاری نماند. مستندات موتورهای BPMS مطرح نیز همین الگو را دنبال می‌کنند: تعریف جدید به‌عنوان نسخه تازه ثبت می‌شود، درحالی‌که Instanceهای موجود به نسخه‌ای که هنگام شروع داشتند متصل باقی می‌مانند.

تفاوت Process Version با Process Instance چیست؟

برای درک نسخه‌بندی باید این دو مفهوم را از هم جدا کنیم. Process Definition یا تعریف فرآیند همان الگویی است که مشخص می‌کند فرآیند چه مراحل و قواعدی دارد. Process Instance یا نمونه فرآیند اجرای واقعی همان الگو برای یک درخواست مشخص است. برای مثال «فرآیند درخواست خرید» یک Process Definition است.

اما «درخواست خرید لپ‌تاپ واحد بازاریابی در تاریخ ۱۰ مهر» یک Process Instance محسوب می‌شود. یک نسخه از فرآیند ممکن است صدها Instance داشته باشد. زمانی که نسخه جدید منتشر می‌شود، تعریف فرآیند تغییر می‌کند؛ نه اینکه همه نمونه‌های قبلی خودکار دوباره ساخته شوند.

Migration در نسخه‌بندی فرایند چیست؟

گاهی نمی‌خواهیم نمونه‌های قبلی تا پایان روی نسخه قدیمی باقی بمانند. فرض کنید در نسخه جدید یک خطای مهم اصلاح شده یا تغییر قانونی ایجاد شده که باید روی همه درخواست‌های جاری نیز اعمال شود. در این شرایط ممکن است Process Migration انجام شود. Migration یعنی انتقال نمونه‌های در حال اجرا از یک نسخه فرآیند به نسخه دیگر.

اما این انتقال همیشه ساده نیست. فرض کنید Instance فعلی روی فعالیتی به نام «بررسی مدیر مالی» قرار دارد، اما در نسخه جدید این فعالیت حذف شده و دو مرحله جدید جای آن را گرفته‌اند. هنگام Migration باید مشخص شود نمونه جاری در ساختار جدید به کدام فعالیت منتقل شود. به همین دلیل موتورهای فرآیندی برای Migration از Mapping میان فعالیت‌های نسخه قدیمی و جدید استفاده می‌کنند.

چه زمانی نمونه‌های جاری را Migration کنیم؟

هر نسخه جدیدی به مهاجرت نیاز ندارد. اگر تغییر کوچک است و نمونه‌های قبلی می‌توانند بدون مشکل با نسخه قدیمی تمام شوند، معمولاً ادامه هم‌زمان دو نسخه ساده‌تر و کم‌ریسک‌تر است. Migration زمانی جدی‌تر می‌شود که:

• نسخه قبلی خطای مهمی داشته باشد؛
• تغییر قانونی باید روی درخواست‌های جاری نیز اعمال شود؛
• فرآیند بسیار طولانی باشد و پایان نسخه قبلی ماه‌ها طول بکشد؛
• نگهداری چند نسخه هم‌زمان عملیات را پیچیده کند؛
• ادامه نسخه قبلی باعث ایجاد نتیجه متفاوت یا نامعتبر شود.

تصمیم مهاجرت باید بعد از بررسی اختلاف دو نسخه گرفته شود، نه صرفاً به دلیل اینکه نسخه جدید منتشر شده است.

Rollback در BPMS چه معنایی دارد؟

ممکن است نسخه جدید بعد از انتشار مشکلی ایجاد کند. مثلاً شرطی اشتباه تعریف شده باشد یا یک Integration در محیط واقعی درست کار نکند. در چنین شرایطی باید برنامه مشخصی برای بازگشت وجود داشته باشد. Rollback می‌تواند به معنای فعال کردن دوباره نسخه قبلی برای شروع درخواست‌های جدید یا انتشار نسخه اصلاح‌شده بر پایه نسخه پایدار قبلی باشد.

نکته مهم این است که Rollback نمونه‌های Migrationشده همیشه ساده نیست. برخی ابزارهای BPMS حتی تأکید می‌کنند مهاجرت Instanceها الزاماً Undo خودکار ندارد. به همین دلیل بهتر است قبل از هر Migration گسترده، نسخه جدید در محیط آزمایشی بررسی شود. در این زمینه مقاله اجرای آزمایشی فرایند در BPMS می‌تواند مکمل خوبی باشد؛ چون انتشار نسخه جدید بدون تست، ریسک توقف یا خطای فرآیندهای عملیاتی را بالا می‌برد.

چه تغییراتی باید باعث ایجاد نسخه جدید شوند؟

هر ویرایش کوچک الزاماً ارزش انتشار نسخه اجرایی جدید ندارد. اما تغییرات زیر معمولاً باید به‌صورت نسخه مستقل مدیریت شوند:

• اضافه یا حذف فعالیت
• تغییر مسیر تأیید
• تغییر Gateway یا قواعد تصمیم
• تغییر مسئول یک مرحله به‌صورت ساختاری
• اضافه شدن زیرفرآیند
• تغییر فرم‌هایی که روی منطق اجرا اثر دارند
• تغییر Integration یا سرویس خارجی
• تغییر قواعدی که نتیجه فرآیند را عوض می‌کنند

اصلاح یک توضیح یا تغییر ظاهری که هیچ اثری روی اجرا ندارد ممکن است نیازمند همان سطح از Versioning نباشد. به همین دلیل بهتر است سازمان برای تغییرات فرآیندی سیاست مشخصی داشته باشد.

قبل از انتشار نسخه جدید چه چیزهایی را بررسی کنیم؟

نسخه‌بندی فقط زدن دکمه Deploy نیست. قبل از انتشار بهتر است مشخص شود:

چه چیزی تغییر کرده است؟
تغییر باید مستند و قابل توضیح باشد.

چرا تغییر انجام شده است؟
برای هر نسخه بهتر است دلیل کسب‌وکاری مشخص باشد.

چه فرآیندهایی از این تغییر تأثیر می‌گیرند؟
گاهی یک زیرفرآیند در چند فرآیند دیگر استفاده می‌شود.

تکلیف Instanceهای جاری چیست؟
آیا روی نسخه قبلی می‌مانند یا Migration خواهند شد؟

Rollback چگونه انجام می‌شود؟
اگر نسخه جدید مشکل داشت، مسیر بازگشت چیست؟

این بررسی به‌ویژه در فرآیندهای پیچیده کسب‌وکار اهمیت بیشتری دارد؛ زیرا تغییر یک بخش ممکن است روی فرم‌ها، قوانین، APIها یا زیرفرآیندهای دیگر اثر بگذارد.

نام‌گذاری نسخه‌ها چگونه باشد؟

یکی از اشتباهات رایج این است که نسخه‌ها منتشر شوند اما از نام آنها نتوان فهمید چه تغییری اتفاق افتاده است.در کنار شماره نسخه، بهتر است Change Log کوتاهی وجود داشته باشد. برای مثال:

V1.0 – نسخه اولیه

V1.1 – اصلاح مسیر تأیید مالی

V1.2 – اضافه شدن کنترل بودجه

V2.0 – بازطراحی فرآیند خرید

این مدل کمک می‌کند تیم تحلیل فرآیند، IT و صاحبان فرآیند درباره یک نسخه مشخص صحبت کنند و بعداً نیز دلیل انتشار آن قابل تشخیص باشد.

نسخه‌بندی با «تغییر فرایند» چه تفاوتی دارد؟

تغییر فرآیند یک مفهوم کسب‌وکاری است؛ مثلاً سازمان تصمیم می‌گیرد مرحله‌ای حذف یا مسئولیتی جابه‌جا شود. Versioning مکانیزمی است که این تغییر را به شکلی کنترل‌شده در سیستم مدیریت می‌کند. به بیان ساده:

Change می‌گوید چه چیزی باید تغییر کند.

Versioning مشخص می‌کند این تغییر چگونه بدون از بین رفتن سابقه و اختلال در اجرا منتشر شود.

اگر می‌خواهید موضوع تغییر را از زاویه مدیریتی و اجرایی بررسی کنید، مقاله تغییر فرایند در BPMS مکمل مناسبی برای این بخش است.

نقش BPMN در مدیریت نسخه‌های فرآیند

نسخه‌بندی خوب از مدل‌سازی درست شروع می‌شود. اگر فعالیت‌ها نام‌گذاری مشخصی نداشته باشند، مدل بیش از حد پیچیده باشد یا هر تغییر باعث بازطراحی کامل نمودار شود، مقایسه نسخه‌ها و Migration دشوارتر خواهد شد.

استاندارد BPMN کمک می‌کند ساختار فرآیند با زبان مشخص و قابل فهمی طراحی شود. برای افرادی که در ابتدای مسیر مدل‌سازی هستند، آموزش نصب ابزار مدل‌سازی و طراحی اولین فرآیند با BPMN 2.0 در آکادمی چارگون می‌تواند نقطه شروع مناسبی باشد. آکادمی این دوره را با تمرکز بر طراحی عملی فرآیند، Activity، Event و Pool ارائه کرده است.

چند اصل برای نسخه‌بندی بهتر فرایندها

• برای هر تغییر نسخه جدید منتشر نکنید؛ تغییرات را ابتدا جمع‌بندی و تست کنید.
• نسخه‌های منتشرشده را بدون دلیل حذف نکنید؛ تاریخچه آنها بخشی از سابقه اجرای فرآیند است.
• برای هر نسخه Change Log داشته باشید.
• قبل از Migration نمونه‌های جاری، اختلاف ساختاری نسخه‌ها را بررسی کنید.
• فرم‌ها، زیرفرآیندها، قواعد و Integrationهای وابسته را هم در ارزیابی تغییر ببینید.

و مهم‌تر از همه، نسخه جدید را ابتدا در محیط تست اجرا کنید؛ چون هدف Versioning فقط نگهداری نسخه‌های مختلف نیست، بلکه کاهش ریسک تغییر در محیط عملیاتی است.

جمع‌بندی

فرآیندهای سازمانی دائماً تغییر می‌کنند؛ مسئله اصلی این نیست که جلوی تغییر را بگیریم، بلکه باید تغییر را بدون ایجاد اختلال مدیریت کنیم. نسخه‌بندی در BPMS این امکان را فراهم می‌کند که تعریف جدید یک فرآیند منتشر شود، درحالی‌که سابقه نسخه‌های قبلی باقی بماند و وضعیت نمونه‌های جاری نیز مشخص باشد.

در حالت معمول، درخواست‌های جدید با آخرین نسخه شروع می‌شوند و Instanceهای قبلی می‌توانند روی نسخه قدیمی ادامه پیدا کنند. اگر لازم باشد نمونه‌های جاری نیز از تغییر جدید استفاده کنند، Migration باید با برنامه و Mapping مناسب انجام شود.

بنابراین یک سیاست نسخه‌بندی مناسب باید چهار موضوع را روشن کند: چه زمانی نسخه جدید منتشر می‌شود، نمونه‌های جاری چه می‌شوند، تغییر قبل از انتشار چگونه تست می‌شود و در صورت بروز مشکل مسیر بازگشت چیست.

سؤالات متداول