یک فرایند روی کاغذ ممکن است بسیار ساده به نظر برسد: درخواست ثبت میشود، یک یا دو واحد آن را بررسی میکنند و در نهایت نتیجه اعلام میشود.
اما همین فرایند وقتی قرار است به سامانه تبدیل شود، با سؤالهای تازهای روبهرو میشود.
دقیقاً چه چیزی فرایند را شروع میکند؟ چه کسی مالک آن است؟ اگر اطلاعات ناقص باشد چه اتفاقی میافتد؟ تصمیم هر مرحله براساس چه قاعدهای گرفته میشود؟ اطلاعات موردنیاز از کدام سامانه میآید؟ اگر سرویس بیرونی در دسترس نباشد، کار باید متوقف شود یا مسیر دیگری داشته باشد؟
بخش مهمی از موفقیت یک پروژه دیجیتالیسازی، پیش از انتخاب ابزار و شروع پیادهسازی شکل میگیرد: زمانی که خود فرایند برای تبدیلشدن به یک سامانه اجرایی آماده میشود.
این آمادگی به معنای تهیه یک مستند حجیم یا مدلسازی تمام جزئیات سازمان نیست. هدف این است که ابهامهایی که هنگام اجرا به مسئله تبدیل میشوند، قبل از توسعه شناسایی شوند.
دیجیتالیکردن یک فرایند دقیقاً به چه معناست؟
دیجیتالیسازی یک فرایند با تبدیل فرم کاغذی به فرم آنلاین تمام نمیشود.
فرم فقط یکی از اجزای ماجراست. یک فرایند اجرایی مشخص میکند کار چگونه آغاز میشود، میان چه نقشهایی حرکت میکند، چه دادهای در هر مرحله لازم است، تصمیمها چگونه گرفته میشوند و در شرایط غیرعادی چه اتفاقی میافتد.
در بسیاری از فرایندهای سازمانی، یک لایه دیگر نیز وجود دارد: ارتباط با سامانههای دیگر. ممکن است اطلاعات مشتری، پرسنل، قرارداد، دارایی، منطقه یا پرونده از قبل در سیستم دیگری وجود داشته باشد و نباید دوباره از کاربر گرفته شود.
پس از اجرا نیز سازمان معمولاً میخواهد بداند پروندهها در چه وضعیتی هستند، کجا متوقف شدهاند و چه اتفاقاتی در طول مسیر رخ داده است.
بنابراین دیجیتالیسازی را بهتر است تبدیل یک فرایند کسبوکار به یک جریان اجرایی شامل نقش، اطلاعات، تصمیم، استثنا، ارتباط و امکان پایش در نظر بگیریم.
اگر میخواهید تصویر کاملتری از این نوع سامانهها داشته باشید، صفحه آشنایی با گراف BPMS و سامانههای سازمانی فرایندمحور مسیر بعدی مناسبی است.
قبل از انتخاب ابزار، محدوده فرایند را شفاف کنید
اولین سؤال این نیست که فرایند در چه نرمافزاری ساخته شود. ابتدا باید مشخص باشد دقیقاً چه چیزی قرار است دیجیتالی شود.
اگر محدوده روشن نباشد، پروژه بهتدریج بزرگتر میشود. فعالیتهایی وارد طراحی میشوند که در ابتدا دیده نشده بودند، واحدهای جدید اضافه میشوند و تیم پیادهسازی ناچار میشود بخشی از تصمیمهای تحلیلی را در میانه توسعه بگیرد.
محرک شروع فرایند چیست؟
برای هر فرایند باید بتوان یک پاسخ مشخص برای این سؤال داشت:
چه اتفاقی باعث میشود یک نمونه جدید از این فرایند ایجاد شود؟
ممکن است محرک، ثبت یک درخواست باشد. ممکن است دریافت یک نامه، رخداد یک وضعیت خاص، رسیدن یک موعد یا دریافت اطلاعات از سامانه دیگر فرایند را شروع کند.
عبارتهایی مثل «وقتی لازم شد» یا «هر زمان واحد مربوطه تشخیص داد» برای پیادهسازی کافی نیستند. شروع باید تا حدی روشن باشد که بتوان آن را در یک سناریوی اجرایی آزمود.
فرایند چه زمانی پایان پیدا میکند؟
پایان فرایند نیز باید بهاندازه شروع آن روشن باشد.
آیا فرایند با تأیید نهایی تمام میشود؟ با ثبت نتیجه؟ با اطلاعرسانی به درخواستکننده؟ با تکمیل یک اقدام بیرونی؟
گاهی چیزی که یک واحد «پایان» میداند، برای واحد بعدی فقط شروع مرحله دیگری است. مشخصکردن این مرز از بزرگشدن ناخواسته دامنه پروژه جلوگیری میکند.
چه چیزی داخل و خارج محدوده قرار دارد؟
در یک پروژه مشخص، لازم نیست تمام فعالیتهای مرتبط با یک موضوع وارد سامانه شوند.
بهتر است صریحاً ثبت شود چه فعالیتهایی در محدوده نسخه فعلی قرار دارند و چه مواردی در این مرحله پوشش داده نمیشوند.
این تصمیم ساده، معیار مشترکی برای تیم فرایند، فناوری اطلاعات و مالک کسبوکار ایجاد میکند.
نقشها و مسئولیتها را از نام افراد جدا کنید
یکی از خطاهای رایج در تحلیل فرایند این است که مسیر کار براساس افراد فعلی طراحی شود:
«پرونده برای آقای الف ارسال میشود، بعد خانم ب آن را بررسی میکند».
این توضیح شاید امروز کار کند، اما با جابهجایی افراد، مرخصی یا تغییر ساختار سازمانی به مشکل میخورد.
بهتر است ابتدا نقش مشخص شود و سپس فرد یا افراد فعلی به آن نقش نگاشت شوند.
چه نقشهایی در فرایند حضور دارند؟
برای هر مرحله مشخص کنید چه نقش سازمانی مسئول انجام کار است.
ممکن است یک فعالیت با «کارشناس بررسی»، فعالیت دیگری با «مدیر واحد» و تصمیم دیگری با «مالک فرایند» مرتبط باشد.
گراف BPMS در قابلیت فعلی خود از ساختار سازمانی و تخصیص وظیفه به فرد، نقش یا گروه پشتیبانی میکند؛ بنابراین این تفکیک در مرحله تحلیل میتواند مستقیماً به طراحی اجرایی فرایند منتقل شود.
مالک فرایند چه کسی است؟
مالک فرایند کسی است که درباره منطق کلی، تغییرات و نتیجه موردانتظار فرایند مسئولیت دارد.
این فرد لزوماً کسی نیست که بیشترین فعالیت روزمره را انجام میدهد.
اگر هنگام طراحی اختلافی درباره مسیر، قواعد یا استثناها پیش بیاید، باید مشخص باشد تصمیم نهایی درباره فرایند با چه نقشی است.
مسئول اجرا و مسئول تصمیم چه تفاوتی دارند؟
هر کسی که یک فعالیت را انجام میدهد، الزاماً اختیار تصمیم درباره ادامه مسیر را ندارد.
ممکن است کارشناس اطلاعات را بررسی کند، اما تأیید یا رد نهایی با مدیر باشد. یا یک واحد داده را تکمیل کند، در حالی که واحد دیگری درباره نتیجه تصمیم بگیرد.
تفکیک این دو مسئولیت از همان ابتدا، مسیرهای ارجاع و تصمیم را شفافتر میکند.
دادههای موردنیاز فرایند را مشخص کنید
بعد از محدوده و نقشها، باید بدانیم فرایند با چه اطلاعاتی کار میکند.
اینجا فقط فهرست فیلدهای یک فرم مطرح نیست. سؤال اصلی این است که هر داده از کجا میآید، در چه مرحلهای استفاده میشود و چه کسی مسئول صحت آن است.
چه دادهای در شروع لازم است؟
حداقل اطلاعاتی را مشخص کنید که بدون آنها فرایند نمیتواند آغاز شود.
اطلاعات ضروری را از دادههایی که میتوان در مراحل بعد تکمیل کرد جدا کنید. این کار از ساخت فرمهای شروع بسیار طولانی جلوگیری میکند.
چه دادهای در طول فرایند ایجاد میشود؟
برخی اطلاعات هنگام ثبت اولیه وجود ندارند.
نتیجه بررسی، نظر کارشناسی، تاریخ اقدام، وضعیت پرونده یا علت بازگشت ممکن است در مراحل مختلف ایجاد شوند.
برای هر داده مهم مشخص کنید چه کسی آن را ثبت میکند و در ادامه فرایند کجا استفاده میشود.
منبع مرجع هر داده کدام سامانه است؟
اگر اطلاعاتی مانند مشخصات پرسنل یا اطلاعات یک دارایی قبلاً در سامانه دیگری نگهداری میشود، باید مشخص شود کدام سیستم مرجع است.
در معماری داده از اصطلاح System of Recordاستفاده میشود؛ یعنی «سامانه یا منبعی که نسخه مرجع و مورد اتکای یک داده را نگهداری میکند».
هدف این است که در صورت امکان، سامانه فرایندی مصرفکننده داده مرجع باشد، نه اینکه نسخه موازی و ناسازگاری از همان اطلاعات ایجاد کند. مستند مدل داده گراف BPMS نیز تعیین مالک داده و منبع اصلی اطلاعات را از اصول طراحی داده میداند.
قواعد تصمیمگیری را از ذهن افراد خارج کنید
بسیاری از فرایندها در ظاهر مسیر مشخصی دارند، اما وقتی جزئیات را بررسی میکنیم، میشنویم:
«بستگی دارد.»
«کارشناس خودش تشخیص میدهد.»
«در بعضی موارد باید برای مدیر ارسال شود.»
همین نقاط معمولاً محل اصلی پیچیدگی فرایند هستند.
چه شرایطی مسیر پرونده را تغییر میدهد؟
شرایطی را که میتوانند مسیر رسیدگی را تغییر دهند فهرست کنید.
برای مثال:
- نوع پرونده؛
- منطقه یا واحد مربوط؛
- اولویت؛
- وضعیت اطلاعات؛
- نتیجه بررسی قبلی.
هدف هنوز طراحی فنی قاعده نیست. در این مرحله فقط باید روشن شود چه متغیرهایی بر مسیر فرایند اثر دارند.
کدام تصمیمها قاعدهپذیرند؟
برخی تصمیمها را میتوان بهصورت روشن توضیح داد:
«اگر وضعیت X بود، پرونده به مسیر Y برود.»
این تصمیمها گزینه مناسبی برای تبدیلشدن به قواعد اجرایی هستند؛ چون ورودی و نتیجه آنها قابل تعریف است.
گراف BPMS امکان تعریف قواعد کسبوکار و استفاده از آنها در جریان فرایند را مستند کرده است.
کدام تصمیمها باید انسانی باقی بمانند؟
هر تصمیمی را نباید به قاعده خودکار تبدیل کرد.
بعضی تصمیمها به تفسیر، قضاوت تخصصی، بررسی مدارک یا مسئولیت مدیریتی نیاز دارند. در چنین مواردی بهتر است سیستم اطلاعات لازم را در اختیار تصمیمگیر قرار دهد و نتیجه تصمیم را ثبت کند.
هدف دیجیتالیسازی، حذف نقش انسان از هر تصمیم نیست؛ بلکه روشنکردن جایگاه تصمیم انسانی و قواعد قابل اجراست.
استثناها را قبل از پیادهسازی ببینید
اگر فقط مسیر عادی فرایند طراحی شود، بخش بزرگی از مشکلات واقعی پس از شروع بهرهبرداری ظاهر خواهند شد.
برای هر مرحله بپرسید: اگر همهچیز طبق برنامه پیش نرفت چه؟
ممکن است اطلاعات ناقص باشند. مسئول اصلی در دسترس نباشد. پرونده برای اصلاح برگردد. سرویس یک سامانه بیرونی پاسخ ندهد. نتیجه بررسی نیازمند اقدام دستی باشد یا یک پرونده از مسیر غیرمعمولی عبور کند.
لازم نیست پیش از پروژه تمام حالتهای ممکن جهان پیشبینی شوند. اما استثناهای شناختهشده و پرتکرار باید قبل از پیادهسازی ثبت شوند.
برای هر استثنا حداقل این سه موضوع را مشخص کنید:
- چگونه تشخیص داده میشود؟
- چه کسی باید درباره آن اقدام کند؟
- فرایند پس از رفع مسئله از کجا ادامه پیدا میکند؟
این نگاه باعث میشود سامانه فقط برای Happy Path، یعنی مسیر ایدهآل و بدون خطا، طراحی نشود.
وابستگی به سامانههای دیگر را شناسایی کنید
در سازمانهای بزرگ، فرایندها معمولاً مستقل از سایر سیستمها نیستند.
یک مرحله ممکن است نیازمند دریافت اطلاعات از سامانه دیگری باشد و مرحله بعد باید نتیجهای را به سیستم دیگری ارسال کند.
اگر این وابستگیها در ابتدای پروژه دیده نشوند، در زمان پیادهسازی به یکی از منابع اصلی تأخیر و تغییر دامنه تبدیل میشوند.
چه اطلاعاتی باید دریافت شود؟
برای هر اتصال مشخص کنید چه اطلاعاتی لازم است، چه سامانهای آن را نگهداری میکند و در چه مرحلهای باید دریافت شود.
همچنین باید روشن باشد آیا داده فقط خوانده میشود یا امکان تغییر آن نیز وجود دارد.
چه اطلاعاتی باید ارسال شود؟
برخی فرایندها پس از انجام یک مرحله باید اطلاعات یا وضعیت جدیدی را در سامانه دیگری ثبت کنند.
نوع داده، زمان ارسال و مسئولیت صحت آن باید در سناریوی اجرایی روشن باشد.
گراف BPMS در قابلیت فعلی خود اتصال فرایند به REST API و SOAP Web Service را مستند کرده و مدل داده آن نیز Provider برای پایگاه داده، REST و WSDL را پوشش میدهد.
امکان اتصال یک سامانه مشخص به API، پروتکل، مجوزهای دسترسی و معماری همان سامانه وابسته است.
در زمان اختلال ارتباط چه باید کرد؟
این پرسش اغلب فراموش میشود:
اگر سامانه بیرونی در لحظه موردنیاز پاسخ نداد، تکلیف فرایند چیست؟
ممکن است فعالیت باید متوقف شود، کاربر امکان تلاش مجدد داشته باشد یا پرونده برای بررسی دستی ارسال شود.
پاسخ به این سؤال باید بخشی از طراحی فرایند باشد، نه تصمیمی که بعد از اولین قطعی گرفته میشود.
قبل از اجرا مشخص کنید چه چیزی را اندازه میگیرید
اگر پس از دیجیتالیسازی ندانیم چه چیزی باید قابل مشاهده باشد، گزارشگیری به مجموعهای از درخواستهای پراکنده پس از اجرا تبدیل میشود.
بهتر است پیش از طراحی سامانه مشخص شود مدیر فرایند برای ارزیابی وضعیت به چه اطلاعاتی نیاز دارد.
زمان چرخه
از شروع تا پایان یک پرونده چقدر زمان میگذرد؟
برای محاسبه آن باید نقطه شروع و پایان از ابتدا مشخص باشند.
زمان توقف
پرونده بیشترین زمان را در کدام مرحله یا وضعیت میگذراند؟
این سؤال میتواند برای شناخت گلوگاههای اجرایی مهمتر از زمان کل باشد.
برگشتها و استثناها
چه تعداد یا چه نوع پروندههایی به مرحله قبلی برمیگردند؟ کدام استثناها بیشتر رخ میدهند؟
در این مرحله لازم نیست Target یا درصد هدف ساخته شود. کافی است مشخص باشد چه رویدادهایی باید قابل اندازهگیری باشند.
وضعیت پروندهها
مدیر یا مالک فرایند احتمالاً میخواهد بداند چه پروندههایی باز هستند، در چه مرحلهای قرار دارند و مسئول اقدام بعدی چه نقشی است.
گزارشساز گراف BPMS برای استفاده از دادههای فرایندی، فرمی، سیستمی و منابع خارجی طراحی شده است و میتواند این دادهها را در گزارشهای موردنیاز راهکار به کار بگیرد.
چکلیست آمادگی فرایند برای دیجیتالیسازی
پیش از ورود به مرحله طراحی و پیادهسازی، بررسی کنید آیا برای این موارد پاسخ قابل استفاده دارید:
- شروع: چه رخدادی فرایند را آغاز میکند؟
- پایان: چه وضعیتی نشان میدهد فرایند تمام شده است؟
- محدوده: چه فعالیتهایی داخل پروژه و چه مواردی خارج از آن هستند؟
- مالک فرایند:چه نقشی مسئول منطق و تغییرات کلی فرایند است؟
- نقشها: چه نقشها و واحدهایی در اجرا مشارکت دارند؟
- دادههای ورودی:برای شروع چه اطلاعاتی ضروری است؟
- دادههای ایجادشده:در مراحل بعد چه اطلاعاتی تولید یا تکمیل میشود؟
- منبع مرجع داده:نسخه معتبر هر داده در کدام سامانه نگهداری میشود؟
- قواعد: چه شرایطی مسیر فرایند را تغییر میدهند؟
- تصمیمهای انسانی:کدام تصمیمها به قضاوت یا مسئولیت انسانی نیاز دارند؟
- استثناها: مهمترین مسیرهای غیرعادی و خطاها کداماند؟
- یکپارچهسازی: چه اطلاعاتی باید از سامانههای دیگر دریافت یا به آنها ارسال شود؟
- معیار پذیرش:چه شرایطی نشان میدهد راهکار پیادهسازیشده نیاز کسبوکار را پوشش میدهد؟
- KPI: چه شاخصها و وضعیتهایی باید قابل اندازهگیری باشند؟
- سناریوی تست:چه جریانهایی باید پیش از بهرهبرداری از ابتدا تا انتها آزموده شوند؟
لازم نیست همه این موارد در اولین جلسه به جزئیات کامل برسند. اما وجود پاسخ اولیه برای هرکدام نشان میدهد فرایند از یک «ایده کلی» به یک سناریوی قابل طراحی نزدیک شده است.
از تحلیل فرایند تا سامانه اجرایی چه اتفاقی میافتد؟
وقتی محدوده، نقشها، دادهها، قواعد، استثناها و اتصالهای اصلی روشن شدند، تحلیل فرایند میتواند وارد مرحله طراحی سامانه شود.
مسیر کلی را میتوان به این شکل دید:
نیاز کسبوکار ← محدوده فرایند ← نقش و قواعد ← فرم و داده ← یکپارچهسازی ← اجرا ← گزارش
در این مرحله یک پلتفرم فرایندمحور میتواند اجزایی را که در تحلیل شناسایی شدهاند به یک جریان اجرایی تبدیل کند.
گراف BPMS نمونهای از این نوع پلتفرم است. طراح و موتور فرایند آن از مدلسازی و اجرای فرایند استفاده میکند و مدل میتواند به فرم، نقشها، قواعد کسبوکار و سرویسها متصل شود. قابلیتهای داده و گزارش نیز امکان استفاده از منابع اطلاعاتی و داده حاصل از اجرای فرایند را فراهم میکنند.
برای بررسی جزئیات قابلیت طراحی و اجرا میتوانید صفحه طراحی و اجرای فرایند در گراف BPMS را ببینید یا از آموزش فرایندساز گراف BPMS استفاده کنید.
پرسشهای متداول
آیا قبل از دیجیتالیسازی باید فرایند را کاملاً بهینه کنیم؟
نه لزوماً. اگر مشکلات آشکار فرایند شناخته شدهاند، بهتر است قبل از پیادهسازی درباره آنها تصمیم گرفته شود؛ اما انتظار برای رسیدن به یک فرایند «کاملاً ایدهآل» میتواند پروژه را متوقف کند.
مهمتر این است که منطق نسخهای که قرار است اجرا شود، محدوده مشخص و مالک تصمیم داشته باشد و تغییرات بعدی نیز قابل مدیریت باشند.
آیا داشتن مدل کامل As-Is ضروری است؟
مدل As-Is، یعنی تصویر وضعیت فعلی، زمانی مفید است که برای فهم مسئله یا طراحی وضعیت آینده به آن نیاز داشته باشیم.
اما سطح جزئیات آن باید متناسب با هدف پروژه باشد. لازم نیست هر فعالیت تاریخی و استثنای کماهمیت صرفاً برای کاملبودن مستند شود.
آنچه برای پیادهسازی اهمیت دارد، درک کافی از وضع موجود و توافق روشن بر فرایندی است که قرار است اجرا شود.
BPMN را در چه مرحلهای وارد کنیم؟
BPMN یک زبان استاندارد برای مدلسازی فرایند است و زمانی ارزش بیشتری پیدا میکند که محدوده، بازیگران اصلی، فعالیتها و تصمیمهای مهم فرایند تا حد مناسبی روشن شده باشند.
مدلسازی بیش از حد زودهنگام ممکن است فقط ابهامهای تحلیل را به یک دیاگرام منتقل کند.
گراف BPMS در طراح فرایند خود از BPMN 2.0 استفاده میکند و مدل طراحیشده میتواند به اجزای اجرایی فرایند متصل شود.
آیا هر فرایندی مناسب دیجیتالیسازی است؟
نمیتوان برای همه فرایندها یک پاسخ یکسان داد. ارزش، تکرارپذیری، میزان تغییر، نقش داده، تعداد بازیگران و وابستگی به تصمیمهای انسانی یا سامانههای دیگر از عواملی هستند که باید در ارزیابی در نظر گرفته شوند.
اینکه کدام فرایند را ابتدا انتخاب کنیم موضوع مستقلی است و در مقاله بعدی با تمرکز بر معیارهای انتخاب اولین فرایند بررسی خواهد شد.
چه زمانی باید BPMS را وارد پروژه کرد؟
زمانی که مسئله کسبوکار و محدوده اولیه فرایند بهاندازه کافی روشن شده باشند، میتوان ارزیابی فنی یک پلتفرم BPMS را آغاز کرد.
لازم نیست تمام جزئیات پیش از ورود تیم فنی نهایی شده باشند؛ اما اگر هنوز درباره شروع، پایان، نقشهای اصلی یا هدف فرایند توافق وجود ندارد، انتخاب ابزار احتمالاً زودهنگام است.