انجمن‌ها

ماهیت بعضی از فرایندها به شکلی است که امکان طراحی به شکل کاملا دقیق و نظام­مند را ندارند. برای مثال فرایندهایی که شامل نوآوری و خلاقیت هستند امکان تعیین چارچوب دقیق برای فعالیتها وجود ندارد و در بعضی از مراحل فرایند، این کارشناس است که بسته به تخصص و قدرت نوآوری خود، تصمیم گیرنده است. به بیان دیگر تعداد پارامترها برای تصمیم گیری آنقدر زیاد و در مواردی مبهم است که منطق تجاری (Business Logic) قابل کنترل و طراحی دقیق نیست و کارشناس بسته به دانش و تجربه خود، جریان فرایند و وضعیت آن را تعیین می کند. به این ترتیب قابلیت انعطاف پذیری فرایند بیشتر می­شود و نقش کارشناس در تعیین روندهای فرایند پررنگ­تر می­گردد.

در این زمینه به چند مثال در دنیای واقعی توجه کنید:

مثال 1: تصمیم کارشناس حسابداری برای اعطای وام

فرض کنید در گردش کار «مدیریت وامها» پس از درخواست وام توسط متقاضی، این درخواست به کارتابل سرپرست منتقل می شود و سرپرست این درخواست را به حسابداری منتقل می کند (در کارتابل کارشناس حسابداری قرار می گیرد) . حال کارشناس حسابداری با توجه به پارامترهای زیادی که در نظر می گیرد، می تواند بسته به مورد، تصمیمهای زیر را اتخاذ کند:

1. استعلام سابقه وامهای متقاضی
2. تایید و دستور پرداخت
3. ارجاع به مدیر مالی برای بررسی بیشتر

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

مثال 2: تصمیم مدیر تدارکات برای خرید کالا

فرض کنید در گردش کار «تامین کالاها»  درخواست کالا به کارتابل کارشناس خرید منتقل می شود. حال کارشناس خرید بسته به تجربه و دانش خود و پارامترهای متعدد دیگر می تواند بسته به مورد و کالاهای درخواستی تصمیمهای زیر را اتخاذ کند:

1. دستور تامین کالا از انبار
2. خرید مستقیم کالا
3. خرید از طریق استعلام قیمت
4. ایجاد مناقصه برای خرید کالا

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

مثال 3: تصمیم مدیر در مورد نحوه تامین نیروی انسانی

فرض کنید در یک فرایند «تامین نیروی انسانی» باید مراحل زیر انجام شود:

• ثبت درخواست استخدام
• ارسال مدارک (مدرک تحصیلی، سفته، مدرک اسکان در شهر مورد نظر، ....)
• مصاحبه با کارشناس
• مصاحبه با مدیر شرکت
• آموزش
• به کار گیری

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

1. مصاحبه با مدیر شرکت
2. ثبت درخواست استخدام
3. به کارگیری  
4. مصاحبه با کارشناس
5. آموزش
6. ارسال مدارک

نحوه پیاده ­سازی کارشناس محوری

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

روش ایجاد زیرگردش کار در دیاگرام

برای درک بهتر این روش به یک مثال توجه کنید.

مثال : بررسی وام درخواستی توسط کارشناس حسابداری

فرض کنید در یک گردش کار مدیریت وامها، درخواست وام به دست کارشناس حسابداری می رسد و این کارشناس بسته به موقعیت و تشخیص خود می تواند یکی از راههایی را که در شکل زیر نمایش داده شده دنبال کند:

انتخابهای کارشناس حسابداری

همانطور که در شکل بالا ملاحظه می کنید کارشناس حسابداری می تواند و اختیار دارد که هر کدام از وظایف زیر را از طریق زیرگردشهای مرتبط اجرا کند:

• استعلام از سیستم پرسنلی
• دستور پرداخت
• کسب تکلیف از مدیر مالی

واضح است که هر کدام از این وظایف یک زیرگردش خاص و مرتبط با آن را ایجاد می کند. و گردش کار پس از ایجاد زیرگردش، به وضعیت در انتظار بررسی کارشناس حسابداری برمی گردد. به این ترتیب کارشناس می تواند هر تعداد از وظایف بالا را به ترتیب دلخواه خود انجام دهد.

نکته: کارشناس حتی می تواند هر وظیفه را بنا به تشخیص خود چند بار اجرا کند (یک حلقه (Loop) ایجاد کند)

روش ایجاد زیرگردش از طریق برنامه گردش کار

در این روش جدید که از نسخه 15.61 در سیستم پیاده سازی شده است، زیرگردشها در دیاگرام ایجاد نمی شود بلکه از طریق تابعی بنام StartFreeSubWork در برنامه گردش کار ایجاد می گردد. برای این کار می توانیم برای هر کدام از تصمیمها یک عملیات خاص داشته باشیم که کارکرد آن، ایجاد زیرگردش کار مرتبط با تصمیم است و کارشناس بسته به تشخیص خود، می تواند هر تعداد از این عملیات خاص را به هر ترتیبی که می خواهد اجرا کند.

در این روش، دیاگرام به شکل زیر ساده تر می گردد و خبری از زیرگردش کارها به شکل تصویری (Visual) نیست:

حال این کارشناس در وضعیت «در انتظار بررسی حسابداری» که با رنگ زرد مشخص شده است، بسته به تشخیص خود می تواند یا درخواست را لغو کند یا این که یک یا چند مورد از عملیاتهای خاص زیر را به تعداد و ترتیب دلخواه خود انجام دهد:

عملیاتهای خاص

• استعلام سابقه وامهای متقاضی
• دستور پرداخت
• کسب تکلیف از مدیر مالی

تابع ایجاد زیرگردش کار (StartFreeSubWork)

توسط این تابع که زیرمجموعه موجود WorkUtils است می توانیم در هر وظیفه دلخواه از کار، از طریق یک تابع اجرایی در برنامه گردش کار،  یک زیرگردش کار ایجاد کنیم. الگوی این تابع به شکل زیر است:

این تابع، یک زیرگردش کار جدید در پایگاه dbName با مشخصاتی که توسط پارامتر data بیان می‌شود ایجاد کرده و کلید آنرا بازمی‌گرداند. data یک XML با ساختار زیر است:

نکته 1: مقدار خالی برای dbName عملیات را در پایگاه جاری انجام می‌دهد.

نکته 2: برای اجرای موفق این تابع لازم است UserName و Password مناسب قبلا تعیین شده باشند.

نکته 3: به دلایل امنیتی فقط فیلدهایی در زیرگردش کار آغاز شده درج می‌شوند که به صورت قابل ویرایش در محاوره خاص وظیفه آغازین زیر گردش کار تعریف شده باشند.

نکته 4: WorkKey کلید کار اصلی و SubWorkflowKey کلید زیر گردش کار است.

نکته 5: کار آغاز شده مرتبط با کار اصلی خواهد بود (مشابه کارهایی که از طریق جداکننده آغاز می‌شوند).

نکته 6: اگر SubWorkflowHasDistinctDO="0" باشد یعنی زیرگردش کار آغاز شده از همان منبع دیجیتال کار اصلی استفاده خواهد کرد ولی اگر این پارامتر برابر یک تعیین شود ابتدا یک منبع دیجیتال با شرح SubWorkflowDODesc در زیر شاخه منبع دیجیتال کار اصلی ایجاد شده و زیرگردش کار آغاز شده به آن متصل می‌شود.

توجه کنید: از آنجایی که در این نوع از زیر گردش کار ، وضعیت جدا کننده ای وجود ندارد لذا در این حالت، وضعیت جمع کننده نیز معنایی پیدا نمی کند بنابراین زیر گردش کارها از نوع «بدون جمع کننده» خواهد بود.

در این زمینه به چند مثال در مورد تصمیم گیریهای متنوع کارشناس حسابداری توجه کنید:

مثال1 : کسب تکلیف از مدیر مالی و دستور پرداخت

فرض کنید مقدار وام درخواستی به اندازه ای است که کارشناس تصمیم می گیرد ابتدا از مدیر مالی کسب تکلیف کند و در صورت تایید او دستور پرداخت وام را صادر کند:

1. کسب تکلیف از مدیر مالی

این عملیات خاص از نوع انجام کار است و تابع اجرایی آن به شکل زیر در برنامه گردش ایجاد می شود:

فرض می کنیم این وام از طرف مدیر مالی تایید می شود. و این مورد از طریق پارامتر یک پیام به کار اصلی ارسال می شود.

1. دستور پرداخت

این عملیات خاص نیز از نوع انجام کار است و تابع اجرایی آن به شکل زیر است:

فرض می کنیم این زیرگردش (دریافت و پرداخت) در انتها یک پیام (یا رخداد) به کار اصلی می فرستد و آن را خاتمه می دهد. به این ترتیب کار درخواست وام از طریق اجرای دو عملیات خاص پایان می یابد.

مثال 2: دستور پرداخت مستقیم

در این مثال، کارشناس نیازی به استعلام و تایید مدیری مالی احساس نمی کند و بطور مستقیم عملیات خاص دستور پرداخت را اجرا می کند و کار پس از پرداخت وام به متقاضی به پایان می رسد.

مثال 3: استعلام از سیستم مالی و دستور پرداخت

در این مثال ابتدا کارشناس حسابداری ابتدا با اجرای عملیات خاص «استعلام سوابق مالی» سابقه تراکنشهای مالی مرتبط با وامها متقاضی را از سیستم پرسنلی استعلام می کند و سپس با تشخیص خود عملیات خاص «دستور پرداخت» را اجرا می کند.

مثال 4: استعلام از سیستم مالی و لغو درخواست

در این مثال کارشناس با توجه به سابقه تراکنشهای مالی متقاضی، تصمیم به لغو درخواست می گیرد.

مقایسه روش قبلی ( ایجاد زیرگردشها در دیاگرام) و روش جدید (ایجاد زیرگردشها در برنامه گردش کار)

واقعیت این است که در گردش کارهای ساده همانند مثال بالا، این دو روش تا حدی زیادی کارکرد مشابهی دارند اما همیشه قضیه به این سادگی  نیست و در گردش کارهای پیچیده و حرفه ای پیاده سازی تفاوتهای دو روش بیشتر آشکار می شود. بنابراین بهتر است مزایا و معایب دو روش را بررسی کنیم:

1-روش ایجاد زیرگردش از طریق برنامه گردش کار

مزایا

1. طراحی ساده تر دیاگرام
2. امکان تعیین مسیر گردش کار براساس داده های کار

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

1. امکان ایجاد شرط برای اجرای هر کدام از عملیاتهای خاص

فرض کنید قرار است یکی از عملیاتهای خاص در یک شرایط خاص انجام شود. یا مثلا در شرایط خاصی قرار است یک عملیات خاص تکرار شود، در این صورت به راحتی می توانیم این شرطها را در برنامه اعمال کنیم.

2. انعطاف پذیری بیشتر در نوشتن توابع عملیات خاص

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

1. کارآیی (Performance) بالاتر در گردش کارهای پیچیده

معایب

1. عدم ثبت (Log) فعالیتها و وضعیتهای کار

در این روش چون وضعیتها تغییر نمی کند بنابراین فعالیتها Log نمی شود.

2. پنهان بودن عملیات و عدم امکان نمایش تصویری آن به کاربر

بطور کلی نمایش تصویری (Visual) گردش کار، درک جریان فرایند و امکان ویرایش و نگهداری آن را راحت تر می سازد. در حالی که در این روش، عملیات در پشت صحنه اتفاق می افتد و کاربر هیچ درک تصویری از این عملیات را ندارد.

3. ضرورت ایجاد یک عملیات خاص از نوع «ویرایش فرم عمومی» برای ورود اطلاعات آغازین زیرگردش کار

اگر نیاز به تعیین اطلاعات آغازین برای گردش کار وجود داشته باشد آنگاه باید حتما برای ثبت اطلاعات آغازین در زیر گردش کار ، به یک عملیات خاص از نوع «ویرایش فرم عمومی» نیاز خواهیم داشت.

2-روش ایجاد زیرگردشها در دیاگرام

مزایا

1. نمایش روند کارها به شکل تصویری به کاربر و طراح
2. ثبت (Log)  تراکنشهای فرایند
3. عدم نیاز به طراحی فرم برای ورود اطلاعات آغازین در زیرگردش کار

معایب

1. دشواری پیاده سازی شرط برای ایجاد زیرگردشها

البته در واقع امکان پیاده سازی شرط از طریق وضعیتهای تصمیم گیر وجود دارد اما دقت کنید که در این روش هم باید اسکریپتهای شرط را بنویسید ضمن اینکه حالا باید وضعیتهای تصمیم گیر را نیز با پیچیدگی های خاص خود در دیاگرام ایجاد کنید.

2. عدم امکان پیاده سازی زیرگردشهای ترکیبی

برای مثال اگر سه زیرگردش داشته باشیم ترکیبهای مختلف این زیرگردشها را نمی توانیم به سادگی در دیاگرام پیاده سازی کنیم و با زیادتر شدن زیرگردشها عملا امکان پیاده سازی این مورد امکان پذیر نیست.

3. عدم انعطاف پذیری در تعیین جهت گردش کار

اگر بنا به هر دلیل، یکی از گردش کارها خروجی به یک وضعیت دیگر داشته باشد، جهت جریان کار دیگر از دست کاربر خارج می شود. برای نمونه به مثال زیر توجه کنید:

ملاحظه می کنید که اگر کارشناس حسابداری، وظیفه کسب تکلیف از مدیر مالی را انجام دهد، مسیر گردش کار به بررسی مدیرعامل هدایت می شود و از آنجا بسته به تصمیم مدیر عامل ممکن است دستور تغییر مبلغ را به مدیر عامل بدهد یا درخواست را لغو کند یا این که دستور پرداخت را صادر نماید. در این مثال جریان فرایند از وضعیت «بررسی مدیر امور مالی» به بعد برگشت ناپذیر است و از کنترل کارشناس حسابداری خارج می شود.

معیارهای انتخاب روش مناسب

واقعیت این است که در طراحی گردش کارها این دو روش، امتیاز و برتری خاصی نسبت به یکدیگر ندارند و گردش کارها با هر دو روش کاملا قابل پیاده سازی است . اما اگر بخواهیم دقیق تر موضوع را بررسی کنیم و از منظر حرفه ای به موضوع نگاه کنیم، می توانیم دو معیار اصلی برای انتخاب یکی از روشها را تشخیص دهیم: 1- میزان پیچیدگی گردش کار و 2- میزان اهمیت ثبت تراکنشها (Log)

1-میزان پیچیدگی گردش کار

اگر گردش کار ساده با منطق های تجاری ساده باشد بهتر است از روش اول یعنی ایجاد گردش کار در دیاگرام استفاده کنیم. و اما اگر گردش کار پیچیده باشد و منطقهای تجاری با شرایط متنوع و ... دارد آنگاه بهتر است از روش دوم یعنی ایجاد گردش کار در برنامه گردش کار استفاده کنیم. در واقع پیاده سازی روالهای پیچیده با منطقهای تجاری مشروط، متنوع و ترکیبی از طریق دیاگرام اگرچه از نظر تئوری امکان پذیر است اما از نظر عملی دشوار و در مواردی ناممکن است.

2-میزان اهمیت ثبت تراکنشها

اگر مدیر یک مجموعه، علاقمند به نظارت و گزارشگیری دقیق از روند اجرای کارها باشد آنگاه حتما باید روش دیاگرام را انتخاب کند. چرا که  در این حالت، تمام تراکنشها با زمان دقیق و کاربر مربوطه ثبت (Log) می شود و به این ترتیب مدیر می تواند پارامترهای مرتبط با شاخص عملکرد کاربران (زمان، هزینه و کیفیت) را محاسبه و در تصمیم گیریهای خود استفاده نماید.