متدولوژی عملیاتی BPM – قسمت پنجم

در قسمت چهارم این مطلب، فاز سوم متدولوژی عملیاتی BPM ارائه گردید. در این مطلب فاز ۴ یعنی طراحی (Design)  ارائه می‌شود.

فاز 4: طراحی (Design)

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

بهینه‌سازی طراحی فرآیندهای کسب و کار

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

ساخت نمونه اولیه (Prototype) فرآیند

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

تکمیل جزئیات راهکار

• چارت سازمانی را بر اساس طراحی جدید به روز رسانی کنید.
• جزئیات جریان فرآیند را طراحی کنید.
• مدل فنی راهکار فرآیند را پیاده سازی کنید.
• مستندات طراحی عملیاتی (Functional Design) را کامل کنید.

تیم تغییر کسب و کار، مسئول طراحی فرآیند در این فاز است. برای دریافت سناریوی فرآیند و نظرات، جلسات و کارگاه‌های آموزشی با تمامی‌ذینفعان کسب و کار برگزار می‌شود. پس از دریافت نظرات ذینفعان، تیم تغییر با کمک کارشناسان طراحی، به یک جمع بندی کلی از فرآیند طراحی شده دست می‌یابد. فرآیند طراحی شده بوسیله ابزار طراحی فرآیند BPMS  و شبیه‌سازها اجرا می‌گردد تا مناسب‌ترین فرآیند جایگزین گردد. به عبارت ساده‌تر،فرآیندها همانند لایه‌های یک پیاز هستند که هنگام بررسی هر لایه جزئیات بیشتری مطرح می‌گردد. بنابراین فرآیند انتخاب شده همانند دنیای واقعی در چرخه شبیه‌سازی و پالایش قرار می‌گیرد تا تمامی‌نقاط تصمیم‌گیری، مسیرهای فرآیندی و استثنائات آن مورد بازبینی قرار گیرد. علاقه‌مندان به مطالب بیشتر در رابطه با تکنیک‌های تحلیل و طراحی فرآیند می‌توانند کتاب‌های Harmon  و Burlton  در این زمینه را مطالعه کنند.

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

• شرح شغل‌ها
• نقش‌ها
• فعالیت‌ها
• فرآیندهای کسب و کار

در انتهای این فاز باید نقش‌های درگیر در فرآیندها و فعالیت‌های آتی (to-be) نهایی شده باشند.

برای مشخص شدن امکان پیاده‌سازی فرآیند آتی، باید یک نمونه اولیه از آن ساخته شود. نمونه اولیه باید شامل ویژگی‌های اصلی فرآیند باشد. مثلاً اگر قرار باشد فرآیند با سایر برنامه‌های کاربردی سازمان یکپارچه شود؛ در نمونه اولیه حداقل یکی از این یکپارچگی‌ها پیاده‌سازی شود. نمونه اولیه حاصل تلاش مشترک تیم‌های “تغییر کسب و کار” و “توسعه” است. در این میان تیم توسعه این شانس را دارد که تا حدودی با فرآیند آشنا شود و میزان کدنویسی آن را پیش بینی کند. در حالی که در متدولوژی آبشاری، توسعه‌دهندگان بعد از اتمام کار تیم اجرایی می‌توانستند درگیر پروژه شوند.

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

معمار برنامه‌های کاربردی سازمان برای ساخت نمونه اولیه فرآیند یک مدل فنی سطح بالا طراحی می‌کند. مدلسازی او شامل یک مدل داده (Data Model) و یک مدل مولفه (Component Model) است.

در گذشته در متدولوژی شی گرا برای ثبت تغییرات وضعیت شی و جریان فعالیت‌های فرآیند از نمودارهای توالی (Sequence Diagram)   و انتقال وضعیت (State transition) استفاده می‌شد؛ در صورتی که طبق رویکرد طراحی در BPMS‌ها این دو نمودار به عنوان قسمتی از طراحی فرآیند در ابزار بصورت گرافیکی مدل می‌شوند. این امر مزیت یکپارچگی بین مدلسازی و توسعه را به همراه دارد؛ زیرا توسعه دهنده می‌تواند به سادگی منطق کد نویسی را به فرآیند مدل شده اضافه کند و معمار برنامه‌های کاربردی سازمان نیز به جای وقت گذاشتن بر روی طراحی نمودارهای برهم کنش (Interaction) تنها به طراحی توابع (Function) هر مولفه می‌پردازد.

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

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

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

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

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

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

ادامه در متدولوژی عملیاتی BPM – قسمت ششم

ترجمه و گردآوری: تیم مدیریت محتوای رایورز