WBS در مدیریت ارزش کسب‌شده؛ چرا تغییر دادن اون می‌تونه فاجعه درست کنه؟

مقدمه

ساختار شکست کار یا همون WBS توی یه سیستم مدیریت ارزش کسب‌شده (EVM) مثل ستون فقراته. خیلی از سازمان‌هایی که تازه وارد این حوزه می‌شن، بدون اینکه پروتکل درست و حسابی برای مدیریت تغییر داشته باشن، میان WBS رو تغییر می‌دن. نتیجه؟ موقع گزارش‌گیری، یه عالمه از داده‌های پروژه بهم می‌ریزه و عملاً بخشی از تاریخچه کار پاک میشه.
توی این مقاله می‌خوایم توضیح بدیم چرا داشتن یه WBS پایدار و تحت کنترل تغییرات انقدر مهمه و چرا تغییر اشتباه اون می‌تونه سیستم رو به چیزی تبدیل کنه که به شوخی بهش میگیم: Woefully Broken System یا همون “سیستم به‌شدت خراب”!  در این مقاله به موضوع نقش WBS در مدیریت ارزش کسب‌شده پرداختیم.

در ابتدا پیشنهاد میکنیم مقاله ” مشکلات سیستم مدیریت ارزش کسب‌شده (EVMS) در پروژه‌های ساخت‌ ” را مطالعه کنید.

اهمیت WBS توی EVM

هر سیستم یکپارچه‌ی کسب‌وکار، یه کلید داده (Data Key) لازم داره؛ یعنی یه کد یا شناسه‌ی یکتا که همه‌چی با اون ردیابی بشه. توی EVM هم این کلید معمولاً همون کدی هست که به المان‌های WBS پروژه اختصاص داده میشه.
وقتی پروژه بیس‌لاین (Baseline) شد، دیگه این کدها نباید تغییر کنن؛ مگر با رعایت کامل پروسه‌های رسمی. پس توسعه و نگهداری درست WBS حیاتی‌ترین بخش ماجراست.

ساخت و توسعه WBS

بهترین زمان برای توسعه WBS، اول پروژه‌ست. این ساختار باید همه‌ی کارهای پروژه رو پوشش بده و حداقل تا سطح Control Account پایین بره (جایی که WBS با OBS یا ساختار شکست سازمانی تلاقی پیدا می‌کنه).

یه ساختار معمولی WBS چیزی شبیه اینه:

• ریشه (سازمان)

• پروژه

• سیستم اصلی

• زیرسیستم‌ها

• کامپوننت‌ها

معمولاً سطح کامپوننت‌ها بهترین جا برای تعریف Control Account حساب میشه. توی این سطح، یه تیم تخصصی کار رو مدیریت می‌کنه و مدیر اون تیم به‌عنوان Control Account Manager (CAM) شناخته میشه.

کارها باز هم می‌تونن خردتر بشن:

• Work Package (بسته‌های کاری)

• Task (وظایف جزئی‌تر)

اما نکته اینجاست: هرچی Control Accountها در سطح بالاتری تعریف بشن، دردسر گزارش‌گیری و مدیریت تغییرات کمتره.

فرهنگ‌سازی با دیکشنری WBS

بعد از ساخت WBS، باید یه WBS Dictionary درست بشه. این دیکشنری می‌تونه یه اکسل ساده باشه که شامل این ستون‌هاست:

• کد WBS

• توضیحات

• بودجه (ساعت یا هزینه)

• CLIN (شماره خط آیتم قراردادی)

• CAM (مدیر حساب کنترلی)

• OBS (ساختار شکست سازمانی)

• ارجاع به SOW (شرح کار پروژه)

وقتی این دیکشنری کامل شد، مدیر پروژه اون رو تأیید می‌کنه و از اون به بعد، فقط با کنترل تغییرات رسمی قابل ویرایشه.

تغییر دادن WBS؛ خط قرمز!

هر تغییری توی WBS باید از مسیر رسمی مدیریت تغییرات بگذره. یعنی با حضور همه:

• برنامه‌ریزان پروژه

• متخصص‌های سیستم EVM

• کارشناسان مالی

• و هر بخشی که به سیستم یکپارچه وصله

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

مثلاً اگه یه کد WBS از 1.4.6.1 تغییر کنه به 1.4.7.0 بدون هماهنگی رسمی، سیستم فکر می‌کنه این یه کد جدیده و ارتباطش با داده‌های قبلی قطع میشه. نتیجه:

• داده‌های ارزش کسب‌شده مخدوش میشن

• تاریخچه از بین میره

• گزارش‌ها دیگه قابل اعتماد نیستن

یکی از ابزارهایی که خیلی روی این موضوع حساسه Deltek wInsight هست. چون این نرم‌افزار براساس تاریخچه ترند می‌سازه. پس تغییر یه کد فعال، یعنی پاک کردن تاریخچه!

اصل طلایی در EVM

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

برای مطالعه بیشتر میتوانید مقاله ” واریانس در مدیریت ارزش کسب شده (EVM) ” را مطالعه کنید.

جمع‌بندی

به طور خلاصه:

• تا جایی که میشه WBS رو تغییر ندین.

• اگه مجبور شدید، همه‌چی باید با مستندات رسمی و امضای متخصص‌ها باشه.

• یه WBS پایدار و درست یعنی داده‌های دقیق، گزارش‌های معتبر و یه پروژه قابل کنترل.

برای کسب اطلاعات بیشتر میتوانید به مقاله ” WBS In An Integrated Earned Value Management System ” مراجعه کنید.