فرآیند کسب‌وکار چیست؟ از ورودی و خروجی تا مالک فرآیند

در بسیاری از سازمان‌ها، همه می‌دانند «چه کاری» باید انجام شود، اما وقتی سؤال دقیق‌تر می‌شود، پاسخ‌ها متفاوت‌اند.

یک درخواست دقیقاً از کجا شروع می‌شود؟

برای تکمیل آن چه اطلاعاتی لازم است؟

در طول مسیر از چه واحدهایی عبور می‌کند؟

چه کسی درباره آن تصمیم می‌گیرد؟

اگر کار متوقف شد چه کسی مسئول پیگیری است؟

خروجی نهایی دقیقاً چیست و چه کسی آن را دریافت می‌کند؟

و مهم‌تر از همه، چه کسی مسئول عملکرد کل این مسیر است؟

وقتی پاسخ این سؤال‌ها روشن نباشد، سازمان ممکن است فعالیت‌های زیادی انجام دهد، اما همچنان مرز فرآیندها، مسئولیت‌ها و خروجی خدمات آن مبهم باقی بماند. همین مسئله در بریف مقاله BPM-A02 به‌عنوان درد اصلی مخاطب تعریف شده است: «مرز فرآیند، مسئولیت و خروجی خدمت روشن نیست». مقاله نیز باید برای مدیر عملیات و تحلیلگر کسب‌وکار توضیح دهد که چگونه یک فرآیند را از ورودی تا خروجی و مالک آن درست ببینند.

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

فرآیند کسب‌وکار دقیقاً چیست و چه مرزی دارد؟

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

کلمات «جریان» و «خروجی» در این تعریف اهمیت زیادی دارند.

فرآیند یک فعالیت منفرد نیست.

فرآیند یک واحد سازمانی هم نیست.

و حتی الزاماً برابر با یک نرم‌افزار یا فرم نیست.

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

واحد تدارکات فقط یکی از بازیگران این فرآیند است؛ درست همان‌طور که واحد مالی، مدیر درخواست‌کننده، انبار و تأمین‌کننده نیز ممکن است در بخش‌هایی از مسیر نقش داشته باشند.

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

یکی از ساده‌ترین راه‌ها برای تشخیص مرز یک فرآیند این است که سه سؤال مطرح کنیم:

چه چیزی فرآیند را آغاز می‌کند؟

خروجی قابل تشخیص آن چیست؟

چه کسی این خروجی را دریافت می‌کند یا از آن ارزش می‌گیرد؟

اگر پاسخ این سه سؤال مبهم باشد، احتمالاً مرز فرآیند هنوز به‌درستی تعریف نشده است.

در خدمات BPM گروه توسعه اقتصادی نگار نیز مرحله تحلیل و طراحی به رسم نمودار محدود نمی‌شود؛ شناسنامه فرآیند، SIPOC، RACI، نقش‌ها، قواعد و وضعیت موجود و مطلوب بخشی از خروجی این مرحله محسوب می‌شوند.

مسئله سازمانی پشت این موضوع؛ وقتی مرز فرآیند، مسئولیت و خروجی روشن نیست

یکی از مشکلات متداول در سازمان‌ها این است که هر واحد کار خودش را انجام می‌دهد، اما کسی مسئول نتیجه انتها‌به‌انتهای فرآیند نیست.

فرض کنید مشتری درخواست خدمتی ثبت کرده است.

واحد پذیرش می‌گوید اطلاعات را دریافت کرده است.

واحد فنی می‌گوید درخواست دیر به آن رسیده.

واحد مالی منتظر تأیید دیگری بوده است.

مدیر مربوطه نیز معتقد است مسئول پیگیری، واحد قبلی بوده است.

ممکن است هیچ‌کدام از این واحدها وظیفه داخلی خود را کاملاً رها نکرده باشند؛ بااین‌حال مشتری همچنان خروجی مورد انتظار را دریافت نکرده است.

این همان تفاوت میان مدیریت واحدها و مدیریت فرآیند است.

چارت سازمانی نشان می‌دهد هر فرد به چه مدیری گزارش می‌دهد، اما فرآیند نشان می‌دهد یک کار برای رسیدن به نتیجه چگونه از میان نقش‌ها و واحدها عبور می‌کند.

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

به همین دلیل اولین هدف تحلیل فرآیند الزاماً مکانیزاسیون نیست.

ابتدا باید بتوان گفت:

«این فرآیند دقیقاً از کجا تا کجاست و چه کسی مسئول نتیجه آن است؟»

اجزای فرآیند و جریان ارزش

برای اینکه یک فرآیند قابل فهم، قابل طراحی و بعداً قابل پایش شود، چند جزء باید روشن باشند.

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

ورودی و خروجی؛ دو نقطه‌ای که مرز فرآیند را روشن می‌کنند

ورودی چیزی است که فرآیند برای کارکردن به آن نیاز دارد و خروجی نتیجه‌ای است که فرآیند ایجاد می‌کند.

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

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

نقش و مسئولیت؛ چه کسی چه کاری انجام می‌دهد؟

یک فرآیند ممکن است ده‌ها نقش داشته باشد، اما هر نقش باید بداند در چه مرحله‌ای مسئول اقدام، تصمیم، تأیید یا اطلاع است.

ابزارهایی مانند RACI می‌توانند در مرحله طراحی برای شفاف‌کردن مسئولیت‌ها استفاده شوند. در مدل خدمات BPM گروه توسعه اقتصادی نگار نیز RACI در کنار BPMN، SOP و SIPOC بخشی از مستندسازی وضعیت موجود و مطلوب محسوب می‌شود.

مالک فرآیند کیست و چرا اهمیت دارد؟

یکی از مهم‌ترین مفاهیم در نگاه فرآیندی، مالک فرآیند یا Process Owner است.

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

مالک فرآیند باید نسبت به عملکرد کل فرآیند نگاه انتها‌به‌انتها داشته باشد.

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

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

در طراحی BPM گروه توسعه اقتصادی نگار نیز تعریف «مالک فرآیند» در کنار مسئولیت‌ها، Rule، استثناها و زمان‌بندی جزو اجزای طراحی نقش و SLA در نظر گرفته شده است.

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

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

فرآیندهای اصلی، پشتیبان و مدیریتی چه تفاوتی دارند؟

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

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

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

برای مثال، در یک شرکت صنعتی «تولید و تحویل محصول» می‌تواند فرآیند اصلی باشد، «تأمین و نگهداری تجهیزات» نقش پشتیبان داشته باشد و «برنامه‌ریزی و پایش عملکرد» در لایه مدیریتی قرار گیرد.

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

مثال عملی؛ از درخواست تا تحویل خدمت

فرض کنیم کارکنان یک سازمان برای دریافت خدمات IT درخواست ثبت می‌کنند.

در وضعیت فعلی، کاربر از طریق پیام یا تماس موضوع را اعلام می‌کند. کارشناس IT درخواست را بررسی می‌کند و اگر مسئله مربوط به دسترسی باشد، باید تأیید مدیر واحد دریافت شود. در موارد دیگر ممکن است درخواست به زیرساخت یا تیم نرم‌افزار منتقل شود.

اگر فقط از منظر فعالیت‌ها نگاه کنیم، همه افراد «کاری انجام می‌دهند».

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

محرک فرآیند ایجاد نیاز کاربر است.

ورودی شرح مسئله، مشخصات کاربر و در برخی موارد اطلاعات تجهیز است.

خروجی باید رفع درخواست یا ارائه پاسخ رسمی باشد، نه صرفاً «ارجاع تیکت».

مشتری فرآیند کاربری است که خدمت IT را دریافت می‌کند.

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

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

وقتی فرآیند به این شکل دیده شود، تازه سؤال‌های بهبود معنی پیدا می‌کنند:

آیا تأیید مدیر برای همه درخواست‌ها لازم است؟

کدام درخواست‌ها را می‌توان خودکار ارجاع داد؟

چه داده‌ای فقط یک‌بار باید ثبت شود؟

SLA مناسب چیست؟

و کدام مرحله بیشترین زمان انتظار را ایجاد می‌کند؟

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

مثال سازمانی؛ واحدها کارشان را انجام می‌دهند، اما فرآیند نتیجه نمی‌دهد

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

هر واحد دستورالعمل خودش را دارد.

خرید روی انتخاب تأمین‌کننده تمرکز دارد.

حقوقی مفاد قرارداد را کنترل می‌کند.

مالی شرایط پرداخت را بررسی می‌کند.

مدیر مربوطه نیز مجوز نهایی را صادر می‌کند.

بااین‌حال زمان عقد قرارداد طولانی است و کسی نمی‌تواند دقیقاً بگوید بیشترین تأخیر کجا اتفاق می‌افتد.

اگر مسئله را واحدمحور ببینیم، هر واحد ممکن است گزارش دهد که وظیفه خود را در زمان مناسب انجام داده است.

اما در نگاه فرآیندی، معیار اصلی این است:

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

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

در چنین سناریویی، اصلاح فرآیند می‌تواند شامل تعریف ورودی استاندارد، مسئول هر مرحله، Rule تصمیم، SLA، مسیر استثنا و مالک کل فرآیند باشد. سپس در صورت نیاز می‌توان همین مدل را به گردش کار، فرم و کارتابل اجرایی تبدیل کرد.

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

اشتباهات رایج و گام بعدی پیشنهادی

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

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

خطای سوم، شروع مستقیم از رسم BPMN است. مدل‌سازی زمانی ارزش دارد که ابتدا معلوم باشد کدام مسئله را بررسی می‌کنیم و مرز فرآیند چیست.

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

و خطای پنجم، شروع مکانیزاسیون پیش از روشن‌شدن وضع مطلوب است. سامانه نمی‌تواند به‌تنهایی تعیین کند کدام تأیید لازم است، چه کسی مسئول است یا چه SLAای منطقی است.

به همین دلیل در مدل ورود BPM گروه توسعه اقتصادی نگار نیز تأکید شده است که نقطه شروع الزاماً خرید یک سامانه بزرگ نیست؛ بهتر است یک فرآیند اولویت‌دار، مالک آن و معیار موفقیتش ابتدا روشن شوند.

گام بعدی

وقتی سازمان توانست فرآیندهای خود را از ورودی تا خروجی، نقش‌ها و مالک فرآیند شناسایی کند، سؤال بعدی این است که چگونه مجموعه فرآیندها را اولویت‌بندی، معماری و به یک برنامه مرحله‌ای برای بهبود و مکانیزاسیون تبدیل کنیم؟

ادامه مسیر: «نقشه راه BPM؛ از معماری فرآیند تا بهبود مستمر»

این مسیر دقیقاً مطابق نقشه لینک داخلی تقویم است؛ BPM-A02 باید از صفحه ستون BPM پشتیبانی کند، مخاطب را به مقاله نقشه راه BPM هدایت کند و در سطح Awareness نیز با مقاله «BPM چیست؟» ارتباط مکمل داشته باشد.

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

شناخت فرآیند کسب‌وکار برای چه سازمان‌هایی اهمیت بیشتری دارد؟

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

مهم‌ترین پیش‌نیاز برای تحلیل یک فرآیند چیست؟

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

چه خطا یا ریسکی باید پیش از شروع کنترل شود؟

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

برای شروع با دامنه محدود چه گامی پیشنهاد می‌شود؟

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