BPMN زبان مشترک «چه اتفاقی میافتد بعدش؟»
سؤال «بعد از submit فرم، چه کسی تأیید میکند و ظرف چند روز؟» اغلب فقط در سر مدیر پروژه است. واحد مالی، HR و عملیات هر کدام نسخه ذهنی خود را دارند. BPMN (Business Process Model and Notation — نماد مدلسازی فرایند کسبوکار) diagram سادهای میدهد که همه بفهمند: شروع، task، gateway (تصمیم)، پایان.
این راهنما BPMN را برای تیم کسبوکار توضیح میدهد — نه فقط مهندسان نرمافزار.
علائم فرایند پنهان در سر افراد
- onboarding مشتری «میدانیم چطور است» — hire جدید هر بار از صفر.
- approval chain در email — کسی در vacation کل flow میایستد.
- audit «چه کسی تأیید کرد؟» — پاسخ در inbox شخصی.
- IT diagram دارد؛ business نمیخواند — دو truth.
- استثنا («این بار VIP بود») بدون مسیر رسمی.
چارچوب ۵ مرحله BPMN برای business
-
یک فرایند آزمایشی انتخاب کنید — مثلاً تأیید خرید زیر ۵۰ میلیون یا onboarding کارمند.
-
swimlane بکشید: هر نقش (درخواستدهنده، مدیر، مالی) lane خود را دارد.
-
gateway صریح: «مبلغ > X؟» → مسیر A یا B. حدس حذف شود.
-
ProcessInstance در WKFGo — هر اجرای واقعی instance قابل ردیابی است.
-
جلسهٔ بازبینی فصلی: diagram با واقعیت match میکند؟ بهروز کنید.
اشتباهات رایج
- diagram ۵۰ صفحه — هیچکس نمیخواند. یک صفحه برای ۸۰٪ case کافی است.
- فقط IT نگه میدارد — business owner ندارد.
- BPMN روی کاغذ، اجرا در email — model و reality diverge.
- بدون SLA روی task — «منتظر مالی» بیپایان.
- عدم audit trail — compliance risk.
WKFGo و BPMN
- ویرایشگر/viewer BPMN در
/workflows. - ProcessInstance — وضعیت هر اجرا: کجا گیر کرده؟
- اتصال به تسk — handoff از workflow به Kanban.
- ویکی — نسخه انسان-readable کنار diagram.
مثال: تأیید سند
[درخواست] → [بررسی PM] → (<50M?) → [تأیید مدیر] → [Done]
↓ بله
[تأیید CFO] → [Done]
سوالات متداول
BPMN سنگین نیست برای startup؟
برای ۳–۵ فرایند تکراری ارزش دارد — نه برای هر bug fix.
جایگزین checklist ساده؟
checklist برای linear؛ BPMN وقتی branch و approval chain دارید.
Camunda لازم است؟
WKFGo ProcessInstance برای many teams کافی است؛ integration عمیقتر optional.
business باید XML بخواند؟
خیر — diagram visual + ویکی خلاصه فارسی.
هزینه فرایند پنهان در سر افراد
وقتی «بعدش چه کسی؟» documented نیست، هر استثنا مسیر جدید میسازد. audit compliance fail. onboarding ۳ ماه طول میکشد. وقتی PM leave میکند، half فرآیند میرود.
ادغام با rhythm هفتگی
یک فرایند آزمایشی را در اسپرینت اول map کنید. هر جلسهٔ بازبینی: «کجا reality از diagram فاصله گرفت؟» — یک بهروزرسانی ویکی.
ماه دوم
ذینفع business diagram را در جلسه میخواند — کمتر «IT دوباره توضیح بده». approval time measurable میشود.
محدودیت صادقانه
BPMN without execution in ابزار = poster. ProcessInstance باید زنده باشد.
سوالات تکمیلی
چقدر طول میکشد ارزش را ببینیم؟
بیشتر تیمها با rhythm هفتگی ثابت در هفته سوم تا ششم improvement measurable میبینند.
آیا نیاز به تغییر ابزار داریم؟
اغلب فرآیند و عادت مهمتر است — WKFGo وقتی ارزش دارد که تیم در همان جایی که کار میکند داده را بهروز نگه دارد.
داده ناقص چطور؟
در جلسه صریح بگویید چه چیزی را نمیبینید — gap را با حدس پر نکنید.
از کجا شروع کنیم؟
یک پروژه آزمایشی، یک چارچوب از این مقاله، چهار هفته اندازهگیری، بعد گسترش.
چکلیست عملی این هفته
| روز | اقدام |
|---|---|
| دوشنبه | یک گام چارچوب روی پروژه آزمایشی |
| سهشنبه | مانع داده یا مجوز را رفع کنید |
| چهارشنبه | نتیجه را با لید همخوان کنید |
| پنجشنبه | یک تصمیم یا unblock در ابزار ثبت کنید |
| جمعه | جلسهٔ بازبینی: چه سیگنال زودتر از هفته قبل آمد؟ |
سناریوی عملی در تیم ایرانی
onboarding کارمند: HR فکر میکند IT access day ۱ هست؛ IT فکر میکند manager approve لازم است. کارمند ۵ روز بیکار. BPMN swimlane یک صفحه + ProcessInstance → هر step owner و SLA.
همترازی با ذینفعان
| نقش | سؤال هفتگی | اقدام در WKFGo |
|---|---|---|
| مدیر پроژه | surprise این هفته؟ | برد + ماندگی کار |
| لید فنی | چه کسی block؟ | my_queue + comment |
| مدیر اجرایی | چه تصمیمی لازم؟ | decision_inbox |
| مالی | هزینه همخوان؟ | finance_summary |
اشتباهات رایج که دوباره تکرار میشوند
- ابزار بدون rhythm: قابلیت فعال شد اما جلسه هفتگی همان slide دستی است.
- سرزنش فرد: داده برای fix سیستم نیست score شخص.
- دقت ساختگی: فیلد خالی با عدد حدسی پر میشود تا جلسه راحت شود.
- سیستم موازی: email approval کنار workflow ابزار — کدام رسمی؟
- بدون log تصمیم: verbal OK — ماه بعد همان بحث ۴۰ دقیقهای.
گام بعدی
یک قانون از این مقاله را در ویکی پروژه بنویسید و در جلسهٔ بازبینی اسپرینت بعد بپرسید: «رعایت شد یا نه؟» اگر سه اسپرینت همان مشکل تکرار شد، ریشه را در decision log ثبت کنید — شاید محدوده (محدوده) مبهم، ظرفیت کم، یا تأخیر تصمیم باشد.
- ثبتنام رایگان · ویژگیها · قیمتگذاری · مستندات API · بلاگ · تماس