تجزیه و تحلیل کسب و کار با مدیریت فرآیندها؛از طراحی تا اجرا

تجزیه و تحلیل کسب و کار با مدیریت فرآیندها؛از طراحی تا اجرا

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

مرحله دوم ( برنامه‌ریزی)
نقش 2) مدیریت نیازمندی‌های فرآیندها
تحلیلگر کسب و کار وظیفه مدیریت مجموعۀ نیازمندی‌هایی که در مرحله شروع ایجاد شده است را داراست و از آنجایی که هر سازمان افراد و نقش های خاص خود را دارد، یک تحلیلگر کسب وکار می‌بایست مشاوره‌های فردی انجام داده و در نهایت باید همه ذینفعان را در نظر بگیرد. برای مدیریت نیازمندی‌های فرآیندها، باید درک عمیقی از آنچه سازمان در حال حاضر انجام می‌دهد و آنچه باعث کاراتر شدن سازمان خواهد شد، داشته باشیم. برای دستیابی به این اطلاعات از ابزارهای زیر استفاده می‌شود:
فلوچارت‌ها
گزارشات کاربران
نمودارهای زمینه‌ای
در پروژه شرکا به شما اجازه می‌دهند که آنچه آنها می‌خواهند را بدانید،  اما مشکل از جایی آغاز می‌شود که آنها بر راه خودشان پافشاری می‌کنند. بدون فرآیند، مدیریت این نیازمندی‌ها دشوار خواهد بود. باید فرآیندی برای مدیریت نیازمندی‌ها طراحی کنید.
در ادامه 4 مرحله اصلی برای پشتیبانی از چرخه حیات نیازمندی‌ها را بررسی خواهیم کرد:
اول: اطمینان از اینکه فقط نیازمندی‌هایی را جمع آوری‌کرده‌اید که مناسب پروژه شما است و خروجی‌ها و انتظارات را ارائه می‌دهد. برای جمع‌آوری اطلاعات می‌توان از مصاحبه، جلسات طوفان فکری،  مشاهده شغل و فرآیند، بررسی نظری، جلسات مشترک استفاده کرد.
دوم: فرآیند اصلاح نیازمندی‌ها> فقط به دلیل درخواست یک ذینفع نمی‌توان یک نیازمندی را در نظر گرفت، باید تعیین کنید که این نیازمندی تا چه حد متناسب با کل پروژه است. نیازمندی‌ها باید اولویت‌بندی شوند.
سوم: تایید نتایج
چهارم: تایید نیازمندی‌ها

به هنگام تایید نیازمندی‌ها باید به موارد زیر توجه شود:
توجه 1) مشکلات تایید که باید از آن آگاه باشیم:

  • محدود کردن تایید اعتبار فقط به پرسنل تضمین کیفیت یا تست‌کننده‌ها
  • فلج شدن و وقفه در تحلیل با ناامید شدن پرسنلی که در نیازمندی‌ها مشارکت دارند.
  • عدم دستیابی به یک نقطه نظر جامع
  • در نظر گرفتن تایید به عنوان یک رویداد یکباره

توجه 2) ساختار نیازمندی‌ها
نیازمندی‌ها می‌توانند در 4 دسته طبقه‌بندی شوند:
کسب و کار
ذینفعان
کارکردی
غیرکارکردی

توجه 3)قرار دادن اولویت‌ها
اولیت‌ها شامل موارد زیر می‌توانند باشند:

  • اجباری
  • مهم
  • خوب است اگر باشد

توجه4) انجام تست SMART
نیازمندی‌هایی که برای پروژه تعریف می‌شوند باید ویژگی‌های زیر را داشته باشند:
همه نیازمندی‌ها باید SMARTباشند یعنی :

  • مشخص و خاص باشد (Specific)
  • قابل اندازه‌گیری باشد (Measurable)
  • قابل دستیابی باشد (Achivable)
  • واقعی باشد (Realistic)
  • قابل پیگیری باشد (Traceable)

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

  • نیازمندی‌های غیر کارکردی

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

توجه 5) اطمینان از همراستایی
اولویت ما مانند اولویت Portfolio باشد.
تمرکز بر هم افزایی‌ها و مغایرت‌ها بین کسب و کار و نیازهای کاربران
همچنین تکنیک‌ها و ابزارهایی برای تایید نیازمندی‌ها وجود دارد که به برخی از آنها اشاره خواهیم کرد:

نیازمندی‌ها همواره در حال تغییر هستند و تحلیلگر کسب و کار نیازمند ابزارهای تایید نیازمندی‌هاست.

تکنیک‌های بررسی اسناد

  • بررسی Peer-Review
  • از رسمیت کمتری برخوردار است.
  • با شناسایی یک منبع ماهر (یعنی کسی که درگیر جمع‌آوری نیازمندی ها نشده) شروع می‌شود.
  • بررسی رسمی
  • تکنیکی منظم است.
  • شامل کارشناسان Subject-matter، یک مدیر، یاداشت کننده و جمع‌آوری کننده نیازمندی‌ها می‌شود. کل متن را مرور کرده، هر نیازمندی که اهداف پروژه را فراهم می‌کنند را تایید می‌کنیم.

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

ویژگی‌های معیارهای پذیرش :

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

تصور کنید که پروژه شما مانند یک هرم است که دارای 4 لایه است. بالاترین لایه، نیازهای پروژه و لایه بعدی نیازمندی‌های شماست.

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

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

دستورالعمل ها:
هدف آن توضیح چگونگی انجام فرآیند است.چه کسی چه کاری را در چه زمانی با چه توالی و با چه استانداردی انجام می‌دهد.
دستورالعمل باید ویژگی‌های زیر را داشته باشد.

  • خوانا باشد.
  • شامل جزییات باشد اما پیچیده نباشد.
  • شامل متن و نمودار باشد.
  • در برگیرنده اطلاعات کامل باشد.

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

  • اطمینان از درک همراستایی
  • دیدن تفاوت‌نظرها
  • دیدن نیازمندی های غیرمعتبر یا از قلم افتاده
  • جستجوی همراستایی بین مدیرها و کارمندان

مرحله سوم (اجرا)
نقش مدیریت تغییرات
تحلیلگر کسب و کار وظیفۀ اعتبار سنجی تغییرات، تایید تغییرات، تشخیص زمانی که تغییرات مورد نیاز است، ترویج تغییرات، مدیریت فشار زمان‌بندی برای تغییرات و در نهایت حمایت از برنامه‌های تغییر را داراست.

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

نقش 4) مدیریت تست محصولات
ذینفعان پروژه تا زمانی که آنچه را خواسته‌اند دریافت نکنند، راضی نخواهند بود و این زمانی است که نقش تست پر رنگ می‌شود. تست به عنوان یک فرآیند مشخص برای تلاش و ارزیابی تعریف می‌شود. نقش تحلیلگر کسب و کار در طی تست، سازمان به سازمان متفاوت است؛ اما برای همه مشترکاتی وجود دارد. این مشتراک شامل موارد زیر می‌شود:
الف) در طی تست،  نیاز به ایجاد‌Test Case های پذیرش دارید.
Test Case‌ها بر پایه عناصر قابل اندازه‌گیری از نیازمندی‌های ثبت شده در پکیج نیازمندی‌ها هستند.
Test Case در وقع برای نمایش مقبولیت و تایید راه حل از دید کاربر نهایی است. اگر پروژه طولانی باشد باید حتما چک شود که آیا نیازمندی‌های قبلی هنوز معتبر هستند.
مشخصاتTest Case خوب :

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

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

سند استراتژیک تست

      • سندی سطح بالا که مشخص می‌کند رویکرد های تست برای دست یافتن به اهداف تست دارای ویژگی‌های زیر است:
      • از پکیج نیازمندی‌ها مشتق می‌شود.
      • سندی ایستاست (به ندرت آپدیت می‌شود).

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

      • دامنه و اهداف پروژه
      • نقش‌های تست‌ها
      • ابزارها و مستندات

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

چالش‌ها :

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

قسمت پایانی

درخواست دموی نرم‌افزار BPMS دیدگاه

نظرات کاربران 0 نظر

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

15 − دوازده =