نوشتهٔ زیر ترجمهٔ مقالهای از امیل کلی Emiel Kelly، متخصص مدیریت فرایند است که طی آن چرخهٔ جایگزینی برای چرخه سنتی BPM ارائه میکند.
گزارش گارتنر میگوید «مدیریت فرایندهای کسبوکار» اصولاً موضوعی دربارهٔ مشتری است.
مشتری؟ بله، یک فرایند میتواند ذینفعان بیشتری از آن چه که در ابتدا فکر میکردیم داشته باشد. در حقیقت اگر فرایندهای ما در خدمت مشتری نباشند، همهٔ ذینفعان از جمله خودمان باید کسبوکار را تعطیل کنیم و به خانه برگردیم.
فرایند اصولاً برای رسیدن به یک نتیجه است و اگر از فرایند به دنبال نتیجه نباشیم اصلاً به آن دیگر نیازی نداریم. آنچه که در موضوع «مدیریت فرایندهای کسبوکار» اهمیت دارد اجرای فرایندهای مفید است.
فهرست مطالب
چرخه BPM یا چرخه مدیریت فرایندهای کسبوکار
BPM یا همان مدیریت فرایندهای کسب و کار همانطور که از نامش مشخص است دربارهٔ مدیریت فرایندها است. و اگر دربارهٔ BPM چیزهایی خوانده باشیم حتماً از چرخه BPM یا همان چرخه مدیریت فرایندهای کسب و کار چیزهایی شنیدهایم.
میدانم همه چیز به نحوهٔ نفسیر ما بازمیگردد اما به نظر من اقدامات داخل این چرخه باید در سطوح مختلفی رخ دهد. آنچه که من تفاوت بین «زمین بازی» و «داخل رختکن» میدانم.
بیشتر بخوانید: پنج اشتباه رایج سازمانها در مورد مدیریت فرایند کسب و کار – BPM
موضوع تنها یک چرخه نیست
زمانی جرقهٔ نوشتن این مطلب در من زده شد که دیدم گامهای «طراحی» و «پایش» در یک حلقه اتفاق میافتد. به عقیدهٔ من اما این اقدامات در سطوح متفاوتی نسبت به چرخهٔ اصلی رخ میدهد و به نظرم این سطوح متفاوت در «مدیریت کردن فرایند» در این چرخه به نمایش درنیامدهاند و نادیده گرفته شدهاند.
برای تشریح این موضوع میخواهم با مثال معروف پیتزا پیش بروم. فرض کنید یک پیتزافروشی میخواهد پیتزایی را به دست مشتری برساند. در اینجا فرایند «تحویل پیتزا» باید طراحی شود. در این صورت در ذهن کارکنان پیتزا فروشی چنین سوالاتی نقش میبندد:
- چطور یک پیتزا را درست میکنیم؟
- چطور آن پیتزا را تحویل میدهیم؟
- به چه ابزارهایی نیاز داریم؟
- به چه نوع افرادی نیاز داریم؟
- به چه اطلاعاتی نیاز داریم؟
- مشتری چگونه میتواند با ما تماس بگیرد؟
در این مرحله فرض میکنیم استقرار به صورت معجزهواری درست انجام شده و فرایند قابلیت اجرا پیدا کرده است. اولین بخش از چرخهٔ جایگزین پیشنهادی من همینجا شکل میگیرد:
موارد (سفارشهای) بیشتر
ولی اینجا با تعداد زیادی از این «سفارشدهندهها» روبرو هستیم؛ پس هنگام اجرای فرایند به صورت واقعی موارد بسیاری وجود خواهد داشت که در فرایند «تحویل پیتزا» باید اجرا شوند.
در زمان مشخصی از شب ممکن است چندین مورد (سفارش) در فرایند به وجود بیاید. احتمالاً همهٔ ما پیتزافروشیهایی که در آن وضعیت همهٔ سفارشها روی یک صفحه نمایش به صورت زنده در حال نمایش است را دیدهایم. تصویر سادهای شبیه به تصویر زیر:
دایرههای رنگی نشاندهندهٔ تعداد سفارشهایی (موارد) است که در حال حاضر در گامهای مختلف فرایند وجود دارند. نمایی کلی مثل تصویر بالا را من پایش فرایند مینامم.
پس اگر میخواهید در لحظه وضعیتی از تمام موارد در حال اجرا را داشته باشید باید «پایش» را مدام در هنگام «اجرا» به جریان بیاندازید. اتفاقی که باید در مرحلهٔ رسیدگی به موارد (سفارشها) بیافند و نه در مرحلهٔ طراحی. این موضوع گام بعدی چرخهٔ جایگزین من را مشخص میسازد:
اهداف و نتایجِ فرایند
طراحی فرایند برای مشتریان اهمیت ندارد؛ تنها چیز با اهمیت برای آنها تحویل پیتزای سفارشداده شدهٔ آنها مطابق انتظاری است که از محصول دارند و مطابق با تعهدات و وعدههای داده شده از سوی ما است.
پس هنگام طراحی فرایند باید به این فکر کنیم که «در هر مورد (سفارش) خاص ما باید به چه تعهداتی عمل کنیم؟»
ضمن این که باید متوجه تفاوت بین هدف فرایند و نتیجهٔ فرایند باشیم. در این مثالِ مشخص نتیجه «تحویل پیتزا به مشتری» است. کاری که میلیونها بار در روز پیتزافروشیهای سراسر جهان انجام میدهند؛ ولی هدف آن چیزی است که ما دربارهٔ نتیجهٔ فرایند خود متعهد شدهایم. و این هدفگذاری بستگی به استراتژی، کیفیت کار ما و زمان و هزینهٔ صرف شده برای آن دارد.
ولی فعلا «هدف» را پیچیده نمیکنیم و تصمیم میگیریم که هدف و تعهد ما رساندن پیتزا ظرف مدت ۳۰ دقیقه باشد.
اگر این تعهد ما باشد؛ «پایش» باید وضعیت این تعهد ما نسبت به مشتری در هر مورد (سفارش) خاص را نشان دهد. پس در مثال پیتزا پایش باید به ما زمان تحویل مورد انتظار را بگوید:
و وقتی پردازش موارد (سفارشها) ادامه پیدا میکند ممکن است در مواردی وعدهٔ زمان تحویل محقق نشود. هدفِ «پایش» آگاهسازی ما نسبت به این موضوع است. پس از مدتی وضعیت موارد در حال اجرا میتواند شبیه تصویر زیر باشد:
بیشتر بخوانید: اتوماسیون فرایندها را از کجا شروع کنیم؟ نقشه سفر مشتری و زنجیره ارزش
توانِ واکنش نشان دادن
در مورد قرمز تحویل مورد انتظار در بازهٔ زمانی ۳۰ دقیقهای اتفاق نیافتاده است. البته دانستن این موضوع به خودی خود چیز جالبی است اما اگر نتوانیم اقدامی برای جلوگیری از رخ دادن این اتفاق انجام دهیم کاملا بیفایده به نظر میرسد.
توان واکنش نشان دادن به انعطافپذیری ما در سطح هر مورد اشاره دارد. آیا در مرحلهٔ طراحی فرایند، انعطافپذیری برای اقدام مناسب هنگام اجرا در نظر گرفته شده است؟ در مثال بالا انعطافپذیری و اقدام مناسب در اولویت قرار دادن سفارش قرمز با متوقف ساختن سفارشهایی است که هنوز زمان کافی برای انجام تعهد «تحویل ظرف مدت ۳۰ دقیقه» در مورد آنها وحود دارد.
اگر انعطافپذیری مورد نظر ممکن باشد، «پایش» به صورت فوری به «تنظیم» دوبارهٔ «اجرا» ختم میشود. و در این صورت چرخهٔ جایگزین من به این شکل درخواهد آمد:
تصویر بالا همان چیزی است که تصور میکنم «مدیریت فرایند» باید باشد. ولی اگر بخواهم صادق باشم، بهتر است آن را مدیریت موارد (Case Management) بنامیم چون به وسیلهٔ آن در حال مدیریت پردازش همهٔ «موارد (سفارشها)» هستیم.
از زمین بازی تا رختکن
چرخهٔ «اجرا – پایش – تنظیم» چیزی است که نام آن را «بازی در زمین بازی» میگذارم؛ به این دلیل که تنها در صورتی میتوانیم یک بازی را برنده شویم که اصولاً مشغول بازی در آن زمین باشیم.
ولی همچنان چیزی به نام « صحبتهای داخل رختکن» را داریم. بعد از این که به نظر میرسد قادر نیستیم در طول بازی مشکل را حل کنیم و چندین بازی را باختهایم شاید زمان آن رسیده باشد که دربارهٔ تغییر استراتژی بازی در رختکن صحبت کنیم.
وقتی بیشتر و بیشتر با شکایتِ مشتریان دربارهٔ تاخیر در تحویل پیتزاها روبرو میشویم و قادر نیستیم این مشکل را در خلال روند «اجرای فرایند» حل کنیم، زمان آن فرا میرسد که به «طراحی فرایند» خود مجدد نگاهی بیاندازیم. این چرخهٔ سنتی بهبود فرایند است. بعد از این که متوجه شدیم عملکرد فرایند مطابق انتظار نیست، فرایند را تجزیه و تحلیل میکنیم؛ و این تحلیل مبنای بازطراحی فرایند برای اجرای موردانتظار از آن میشود. بازطراحی ممکن است منجر به تغییر در گردشکار، ابزارها، نیروی انسانی و غیره شود.
و این کار بلاخره چرخه یا در حقیقت چرخهها را تکمیل میکند:
این تصویر به خودی خود اهمیتی ندارد، اما این تصویر به من کمک میکند که روشن کنم و توضیح بدهم که «مدیریت فرایندهای کسبوکار» چه باید باشد.
«اجرا» که مهمترین مولفه برای مشتریان هم هست در بالاترین سطح قرار گرفته است. وقتی مشتریان بیشتری داریم موارد یا همان سفارشها را با پایش تنظیم میکنیم و وقتی که به کلی فرایند عملکرد درستی ندارد دست به بازطراحی آن میزنیم.
چه کسی مسئول است؟
این چرخهٔ جایگزین این امکان را میدهد که نقشها را به عنوان «مجری فرایند»، «مدیر فرایند» و «مالک فرایند» را به صورت زیر در نظربگیریم.
اینها فقط عنوان نقشها هستند اما این موضوع که چه کسی قرار است این نقشها را ایفا کند بستگی به روش ما در مدیریت فرایندهای خود دارد.
مقایسهای برای نتیجهگیری
در این نوشته من از تصویر سنتی چرخهٔ مدیریت فرایندهای کسب و کار به یک چرخهٔ جایگزین حرکت کردم تنها به یک دلیل: متمایز ساختن مدیریت بر روی سطح «مورد» از مدیریت بر روی سطح «فرایند».
وقتی تصویر نهایی چرخهٔ جایگزین من را با تصویر اصلی مقایسه میکنید متوجه میشوید که دو مورد «بهینهسازی» و «مدلسازی» غیب شدهاند. برای من «مدلسازی» گامی مجزا نیست بلکه اقدامی است که میتوان در خلال گام طراحی انجام داد. به نظرم در چرخه سنتی BPM مدلسازی به دلیل گرایشهای مبتنی بر سیستمهای مدیریت فرایندهای کسب و کار یا همان BPMSها مجزا از طراحی در نظر گرفته شده است.
علاوه بر «مدلسازی» من «بهینهسازی» را هم به عنوان یک گام جدا در نظر نگرفتم چون فکر میکنم «بهینهسازی» اصولاً یک فعالیت نیست بلکه هدف هر دو چرخهٔ موجود در مدل جایگزین است.
چرخهٔ «پایش» در مورد بهینهسازی در سطح هر موردِ مشخص است. و چرخهٔ طراحی به بهینهسازی فرایند در زمانی که عملکرد فرایند مناسب نیست برمیگردد.
به کدام چرخه باید بیشتر توجه داشت؟
این که به کدام چرخهٔ بهینهسازی توجه بیشتری داشته باشیم بستگی به سطح انعطافپذیری ارائه شده یا امکان استقرار در خلال عملیات اجرای فرایندهایمان دارد.
اگر روندهای ثابتی داشته باشم که امکان تغییر در سطح هر مورد مشخص برای آنها فراهم نباشد باید به سراغ چرخهٔ «بازطراحی» برویم.
و اگر در خلال اجرای فرایند آزادی بیشتری داشته باشیم انعطاف بیشتری در چرخه «پایش» خواهیم داشت.
ولی بزرگترین تفاوت میان چرخهٔ اصلی و چرخهٔ جایگزین در نقطهٔ «اجرا» است. در چرخهٔ جایگزین «اجرا» بالا قرار گرفته است چون بیشتر شرکتها و سازمانها در حال حاضر فرایندهای خود را دارند و در نهایت با اجرای فرایند است که میتوانند به مشتریان خود خدمت بدهند.
سلام
خوشحالیم که براتون مفید بوده.
سپاس از شما