5 گام برای طراحی یک پروژه موفق BPM سازمانی
پروژههای نرم‌افزاری سازمانی معمولا به این معروفند که در زمان و بودجه فراتر از انتظار انجام می‌شوند و یا در نهایت به شکست می‌خورند. با توجه به آمار «گاتنر» بیش از 50 درصد پروژههای BPM نتایج مورد انتظار را ارائه نمی‌دهند. با آمار مشابه منتشرشده، مشخص می‌شود که در واقع، مجریان پروژه نیاز دارند تا راه‌هایی را پیدا کنند که موفقیت آنها را در زمان پیاده‌سازی نرم‌افزار تضمین کنند. در کتاب راهنمای«گاتنر» به مجموعه‌ای از توصیه‌های طلایی و کلیدی اشاره شده که به سازمان‌ها اطمینان می‌دهند با توجه ویژه به این توصیه‌ها می‌توانند در پیاده‌سازی نرم افزار BPM موفق شوند. در این کتاب آمده است:
برای شروع، مکانی را انتخاب کنید که البته این به سادگی شنیدن نیست؛ بلکه در این مرحله چیزهای پنهان زیادی وجود دارد که به آنها اندیشید، مثلا سازمان مشتری و نوع آن. در واقع دو نوع مشتری هستند که همواره به پیاده‌سازی BPMS تمایل دارند: به صورت یکپارچه یا پلت‌فرم.
مشتری یکپارچه
بعضی مشتری‌های یک فرآیند اصلی خاص و قابل شناسایی دارند که می‌خواهند اتوماتیک شود. این فرآیند معمولا استراتژی بنیادی کسب کار آنهاست. ما از اصطلاح «کلان فرآیندها» برای توصیف این مشتری‌ها استفاده می‌کنیم. این سازمان‌ها با حمایت داخلی از پروژه یا تعریف شاخص‌های موفقیت، روند سختی برای اتوماتیک شدن ندارند. در نوع سازمان مشتری، سخت‌ترین تصمیم در ابتدای پروژه معمولا درباره هزینه پروژه (COTS) است که آیا BPMS فناوری مناسبی برای استفاده است یا اینکه شرکت باید نرم‌افزار سفارشی (ERP) را برای اتوماتیک کردن فرآیند خود، تهیه کند.
پلت‌فرم
این نوع مشتری را « نمونه‌ساز» نیز می‌نامیم. برخلاف « کلان فرآیندها» این مشتری تمایل دارد تا فرآیندهای زیادی را به صورت خودکار انجام دهد. این نوع سازمان تمایل دارد به این نتیجه برسد که به نرم افزار BPM نیاز دارد! درصورتی که دسته اول مشتریان در یک راه تدریجی‌تر، غیرشفاف و با تجربه‌اندوزی به داشتن نرم‌افزار BPMS متمایل می‌شوند.
در موارد زیادی این سازمان‌ها چندین فرآیند کاغذی دارند، موارد دیگری که از طریق ترکیب سنگین و پر زحمت اکسل و ایمیل انجام می‌شود و یا دیگر فرآیندهایی که ممکن است قبلا به وسیله کدهای سفارشی اتوماتیک شده باشد. فرآیندها به طور کلی در سراسر سازمان گسترش دارند و هزینه آنها با درجه‌های مختلفی از اهمیت ( ضرورت ) در بخش‌های مختلف احساس می‌شوند. برای این نوع مشتری، سئوالات کمی سخت‌ترند، این نوع مشتری اغلب وقتی مشکلات سازمان را شرح می‌دهد درباره اطلاعات واحدها صحبت می‌کند.
اگرچه تفاوت‌های قابل توجهی بین« کلان فرآیندها » و «نمونه ساز» وجود دارند؛ اما آنها یک شباهت هم با هم دارند. هر دو به تعریف یک مکان برای شروع نیاز دارند. پلتفرم‌ها نیاز دارند تا ابتدا یکی از چندین فرآیند را برای خودکارسازی، شناسایی کنند. در نهایت وقتی یک تیم، مهارت انتخاب تکنولوژی BPMS را به دست آورد بعد از آن می‌تواند خودکارکردن فرآیندهای چندگانه را به صورت هم‌زمان آغاز کند.
« کلان فرآیندها» راه بسیار واضح‌تری برای خودکارسازی اولین فرآیند دارند. با این حال، هنوز هم با چالش‌هایی برای تصمیم‌گیری درباره شروع اتوماسیون خود مواجه هستند. یک فرایند پیچیده نمی‌تواند و نباید یک‌دفعه حل شود. این که برای پیاده‌سازی و خودکارسازی، رویکردی چابک و تکراری داشته باشیم ایده خیلی بهتری است حتی برای یک فرآیند واحد.
قدم اول:
متدولوژی SIR
در BPMS Didgah برای تجزیه و تحلیل نقطه شروع پروژه شما، روش شناسایی SIR را توصیه می‌کنیم. SIR مخفف موفقیت (Success) ، تاثیر (Impact) و تکرار (Repeatability) است.
موفقیت
اولین سؤالی که سازمان شما باید از خود بپرسد این است: آیا ما موفق به خودکارسازی این فرآیند می‌شویم؟
ممکن است مشکلی داشته باشید که ارزش حل‌کردن داشته باشد؛ اما موفقیت در اون قابل اعتماد نباشد، پس قبل از شروع به خودکارسازی فرآیند باید مطمئن باشیم که با شکست مواجه نمی‌شود. دلایل زیادی وجود دارد که حل یک فرآیند را سخت کند؛ اما در نهایت همه آنها به کمبود منابع فنی، زمان و استراتژی سازمانی مربوط می‌شود.
تاثیر
پس از اینکه یک فرآیند پیدا کردیم که مطمئنیم می‌توانیم آن را با موفقیت انجام دهیم، این سوال پیش میایدکه چه کسی از آن مراقبت می‌کند؟ آیا به اندازه کافی برای سازمان مهم است؟ آیا با ابتکار عمل و استراتژی‌های مهم سازمان، هم‌جهت است؟ وجه تعادل بسیار حساس در پیداکردن فرآیند اولیه این است که هم قابل دستیابی باشد و هم تاثیر مثبت قابل توجهی بر سازمان داشته باشد. شکست از نامناسبی انتخاب فرآیند با شکست از اجرای ناموفق برابرست. در هر دو نوع شکست تقریبا مطمئنیم که سرمایه اجتماعی و پروژه از بین می‌روند. توصیه می‌کنیم زمانی که برای تعیین تاثیر فرآیند تلاش می‌کنید اهداف کلیدی کسب و کار سازمان را در نظر بگیرید.
تکرار
سوال نهایی اینکه آیا این فرآیند قابل تکرار است؟ یعنی اگر فرآیندهای زیادی را برای خودکارسازی شناسایی کردید آیا نقاط شروع مشترک دارید که در پروژههای بعدی مفید باشد؟ آیا می‌خواهید بلوک‌های ساختمانی ایجاد کنید که مجددا قابل استفاده باشند؟ تکرارپذیری یعنی برای فرآیندهای دیگر به نفع خود عمل‌کنید. این مورد مهمی است زیرا ذینفعان انتظار دارند بعد از پیاده‌سازی اولین فرآیند، توسعه فرآیندهای بعدی سریع‌تر شود. بعضی دستاوردها بدون برنامه‌ریزی و تلاش خاصی اتفاق می‌افتند؛ به عنوان مثال، وقتی اولین فرایند را اجرا می‌کنید، باید مواردی مانند پیاده‌سازی سلسله مراتب را بررسی کنید که برای فرآیندهای بعدی این کار انجام شده باشد.
قدم دوم: نقشه موفقیت
در این مرحله باید تعریف کنید که چطور همه چیز بعد از اجرای خودکار فرآیند اتفاق می‌افتد. فرآیند دقیق اجرا چیست؟ برای کنترل فرآیند چه گزارش‌هایی لازم است؟ فرآیند شامل چه سخت‌افزار، نرم‌افزار و لوازم جانبی است؟ فرآیند شامل چه ادغامی است؟ انتظارات از آن چیست؟ حجم، زمان، آسیب‌ها و نقص‌ها و میزان رضایتمندی آن چقدر است؟ خودکارکردن فرآیند چقدر طول می‌کشد و چند بار تست لازم دارد تا انجام شود؟
گزارش شناخت
در BPMS Didgah ما برخی از نکات را در یک جلسه شناخت تعریف می‌کنیم در حالی که بقیه موارد در گزارش شناخت می‌آیند. گزارش شناخت در واقع جایی است که انتظارات و محدودیت‌های کاری که قرار است انجامشود در آن مشخص شده است. این سند، اولین سندی است که با مشتری هماهنگ شده و توسط هر دو تیم ارائه‌دهنده خدمات و مشتری امضا می‌شود؛ بنابراین اصرار داریم همه ذینفعان این سند را بخوانند و امضاء کنند.
قدم سوم: ایجاد تیم
این موضوع که مشتری از آغاز بفهمد که پروژه بدون مشارکت تیمش نمی‌تواند به موفق برسد بسیار مهم است. این مشارکت به هیچ وجه با یک شخص قابل توسعه و پیشبرد نیست و مشتری باید از ابتدای پروژه چند نفر از سازمانش را در این مشارکت، وارد کند. تیم مشتری باید نقش‌های زیر را داشته باشد:
حامی اجرایی: باید یک مدیر اجرایی از سازمان باشد
صاحب پروسه: این شخص، فعال‌ترین نقش را در پروژه دارد و باید دانشی جامع و کامل از فرآیندها داشته باشد.
نماینده فناوری اطلاعات: برای اتصال به سیستم‌های خارجی و پیاده سازی فنی فرآیندها
کاربران نهایی: از فرآیند درپایان شکل‌گیری، استفاده کند.
قدم چهارم
طراحی فرآیند اول
هر نرم‌افزار BPM این قسمت را کمی متفاوت پیاده‌سازی می‌کند؛ مثلا در برخی از ابزارها قبل از ایجاد فرم‌های ورودی باید یک مدل داده ایجاد کنید، در حالی که دیگران آن را به صورت خودکار برای کاربر در پشت صحنه انجام می‌دهند. طراحان BPMS از فرایند کشیدن و رهاکردن ایکن‌ها در صفحه استفاده می‌کنند.
طراحی مدل داده‌ها و فرم‌ها
فرآیند چه اطلاعاتی را باید جذب کند؟ در مورد ظاهر فرم‌ها باید فکر کنیم، چه اطلاعات اضافی ضروری‌اند تا از سایر سیستم‌ها استخراج و یا چه اسنادی در طول فرایند باید اضافه یا ایجاد شوند.
طراحی ارتباطات
وقتی در حال ایجاد مدل داده‌ای برای سیستم هستیم به اطلاعاتی که در سایر سیستم‌ها ذخیره می‌شوند می‌رسیم یا ممکن است همان فرآیند خروجی مورد نظر ما باشد که می‌خواهیم آن را در سیستم‌های دیگر ذخیره کنیم. این فنی‌ترین بخش طراحی است. این اتصالات در نهایت شما را وادار می‌کند که برای دسترسی به سیستم‌های دیگر با تیم IT تصمیم‌گیری کنید که آیا از طریق یک وب سرویسREST یا SOAP شدنی است؟ آیا می‌خواهید یک صفحه اکسل واردکنید و خروجی بگیرید؟
عناصر اضافی
طراحی شما احتمالا علاوه بر فرآیند، داده، وب سرویس یا دیگر اتصالات به عناصر دیگری مانند پیام ها، هشدارها و مستندات نیاز دارند. پیام‌ها مثل اطلاع‌رسانی‌ها یا انواع دیگری که باید با فرآیند تولید شوند. هشدارها ممکن است طبیعی باشند و خروجی اسناد می‌تواند هر نوع از سند قابل چاپی باشد که شما برای تولید به آن نیاز دارید.
طراحی رابط‌ها
بیشتر نرم‌افزارهای BPM یک کارتابل استاندارد برای استفاده کاربر و دسترسی دادن به وظایف و داده‌ها دارند ؛ با این حال، تعدادی از پروژههای BPM هم رابط‌های سفارشی نیاز دارند. مشتریان شما انتظار دارند چگونه با سیستم ارتباط برقرار کنند؟
گزارشها و داشبوردها
اینکه از ابتدا به گزارشها و داشبوردها فکر کنید نکته مهمی است که نشان می‌دهد موفقیت یک پروژه مستقیما به تصمیم‌گیری درباره گزارشها و داشبورد ها مربوط است . این بخش فرآیند بسیار حیاتی است و باید تمام تمرکز و تلاشتان را روی فرآیند اصلی و بخش اصلی فرآیند بگذارید.
عملیات سفارشی
بیشتر پروژههای BPM بزرگ، الزامات سفارشی دارند که به برنامه‌نویسی سفارشی نیاز دارند. به طور کلی مطمئن شوید که می‌دانید داخل BPM چه چیز متناسب است و چه قسمت‌های سفارشی دیگری از یک سیستم برای پروژه نیاز دارید.
قدم پنجم:
پیاده‌سازی سریع
در این مرحله شما یک طرح دارید برای رسیدن به موفقیت. عبور از مراحل بالا و رسیدن به پیاده‌سازی ساده نیست. سوئیت‌های BPM به نظر ساده می آید و در بیشتر قسمت ها همینطور است؛ اما با این وجود، طراحی فرآیند و پیاده‌سازی پروژه هرگز ساده نیست، ذینفعان شما ایده و پیشنهادهای ثابتی ندارند؛ بنابراین اگرشما هم شناخت کافی نداشته باشید فرآیندی را خودکار می‌کنید که ذینفعان موافقش نیستند و از آن استفاده نخواهند کرد. در BPM معمولا برای هر پروژه در تیم‌های 4 تا 6 نفره کار می‌کنیم که معتقدیم باعث ترکیب مناسبی از چابکی، افزونگی و تداوم است.
با وجود همه تلاش‌ها برای ایجاد بهترین طرح، اطمینان از اینکه همه ذینفعان یک چیز می‌خواهند . به طور کلی تخمین دقیق موفقیت، کار سختی است. اینکه اکثیریت تمایل دارند با استفاده از روش‌های سریع، توسعه را پیش ببریم از مشکلات دیگر است. در BPMS Didgah روند کار با حداکثر سرعت، یک هفته است که در آن، هدف تولید نسخه‌های تکراری از محصول نهایی است. این یک هفته، فرصت مناسبی است برای تیم ما و تیم مشتری تا مشارکت کنند و نسبت به آنچه در حال انجام است واکنش نشان دهند. تشخیص اینکه ایده‌ها ی اولیه، اشتباه است یا نیاز به تغییر دارد، بسیار ساده می‌شود. این که بتوان قبل از اینکه زمان زیادی صرف کنید اشتباهات را اصلاح کنید و به سرعت تغییر دهید، ریسک را کاهش می‌دهد. می‌توان از تجربیات کاربر برای یافتن بهترین راه‌حل‌ها که بعدها به عنوان فرآیند معرفی می‌شوند، استفاده کرد. آموزش دادن کاربران نهایی به روش متداول و استفاده از آن کاربران اولیه به عنوان آموزش‌دهنده به سایرین و توسعه یک روش معمول برای تغییر به آسانی می‌توان ناسازگاری‌های طبیعی که در سازمان ایجاد می‌شوند را مدیریت کرد.
نتیجه‌گیری
یک نظریه قدیمی می‌گوید« پروژه‌ها هیچگاه به دلیل نرم‌افزارهای بد، شکست نمی‌خورند؛ بلکه آنها به دلیل عدم شناخت صحیح، شکست می‌خورند». شرکت‌ها معمولا در زمان خرید BPMS بیشتر وقت خود را صرف ارزیابی ویژگی‌های محصول می‌کنند. این یک تله متداول است. این یک فرهنگ مناسب یا متداول بین شرکت‌هاست که در زمان یک پروژه جدید به ارزیابی تیم‌های پروژه و آنالیز می‌پردازند. این کار به همان اندازه آسان نیست که در زمان خرید یک محصول به مقایسه ویژگی‌ها و قیمت می‌پردازیم . قطعا این آنالیزها لازم است؛ اما ما معتقدیم اگر شرکت‌ها زمان بیشتری را صرف تجزیه و تحلیل و سازماندهی تیم‌های اجرایی، درک استراتژی، فلسفه پیاده‌سازی و تضمین مناسب بودن فرهنگ کنند، ریسک‌های پیاده‌سازی تا حد زیادی کاهش می‌یابند. نگران نباشید که کدام محصول را انتخاب می‌کنید؛ بلکه بیشتر به تجزیه تحلیل پروژه و کسانی که آن را پیاده‌سازی و برنامه‌ریزی می‌کنند، توجه کنید.
درخواست دموی نرم‌افزار BPMS دیدگاه
