گفتوگوی شرکت راه پرداخت با مهندس امید حسینی، مدیر پروژههای BPMS شرکت مهندسی تذرو افزار در خصوص پیادهسازی BPMS در شرکتهای PSP
شرکتهای PSP به خاطر حساسیتهای بالای مالی و اطلاعاتی که دارند، بهشدت فرایندهای پیچیدهای دارند؛ شناسایی پیچیدگی این فرایندها وقتی سختتر میشود که متوجه میشویم بخش زیادی از این پیچیدگیها مدون نیستند و در ذهن افراد کلیدی شکلگرفتهاند. همین موضوع، کار را برای پیادهسازی موفقیتآمیز یک BPMS یا همان سامانه مدیریت فرایند کسبوکار سختتر و پیچیدهتر میکند؛ شرکت مهندسی تذرو افزار که از سال ۱۳۷۶ در ایران در حوزه تولید و ارائه راهکارهای نرمافزاری فعالیت میکند، مدعی است که با چالشهای این حوزه بهخوبی آشنا است و میتواند BPMS را به معنای واقعی در شرکتهای PSP پیادهسازی کند. به همین بهانه گفتوگوی نسبتاً بلندی با مهندس امید حسینی، مدیر پروژههای BPMS شرکت مهندسی تذرو افزار داشتیم تا ببینیم این ادعا چقدر صحت دارد.
بشناس، طراحی کن؛ در آخر اجرا کن
در ابتدا توضیح کوتاهی از چیستی BPMS به ما بدهید.
بلوغ BPMS باهدف گردش عملیات و داده یا فرآیندها در سازمان صورت گرفته است تا هدررفتهای نرمافزار را به حداقل برساند تا یک کسبوکار به جریان بیفتد. BPMS میگوید که شما ابتدا یک کسبوکار را درست بشناس، سپس طراحی کن و در مرحله بعد آن را اجرا کن.
معمولاً فاز شناخت توسط تیم تحلیل شرکت مهندسی تذرو افزار و بر اساس تجربیات و بهروشهای موجود در تیم صورت میپذیرد. در این فاز تیم تحلیل ما به اهداف اصلی کسبوکار سازمان توجه و اهمیت ویژهای میدهد زیرا در پایان اجرایی شدن فرآیندها سازمان باید به اهداف خود نزدیک و نزدیکتر شود.
در این جریان، با در نظر گرفتن اهداف کسبوکار، فرآیند طراحی و پیادهسازی میشود. پس از استقرار فرآیند و اجرای آنها در سازمان، اهداف تعیین شده را رصد میکنیم و اگر به اهداف پیشبینیشده دست یافتیم همان مسیر را ادامه میدهیم در غیر این صورت لازم است وضعیت موجود را بهبود بخشیم تا به اهداف موردنظر برسیم. این اصل مفهومی BPMS است. ازآنجاییکه نظام تولید فرآیندها در شرکت مهندسی تذرو افزار با اصول مهندسی نرمافزار طراحی شده است و در چندین پروژه عملیاتی مورد بهبود و اصلاح قرار گرفته است، تضمین پیادهسازی و استقرار فرآیندها دور از دسترس نیست.
شکلگیری تیم شما به چه صورت است؟
حدود هشت سال پیش که فعالیتمان را در این حوزه آغاز کردیم این هدف را داشتیم که سازمان را بهصورت مهندسی شکل بدهیم. تیمی را بر اساس چارچوبهای علمی در زمینه نرمافزار تشکیل دادیم. آن زمان BPMS در جاهای زیادی اجرایی نشده بود و همهچیز در حد نظریه بود. با توجه به اینکه ما تجربه پیادهسازی نرمافزار را داشتیم، سازمان پروژههای BPMS را بر اساس متدولوژی محکم و قابل اتکایی بنا کردیم.
بر همین اساس نقشهایی نظیر مدیر پروژه، سرپرست فنی پروژه، تیم تحلیل، تیم طراحی و پیادهسازی، تیم تست، تیم پیکربندی، آموزش و استقرار را شکل دادیم تا بتوانیم مسئولیتها و دستورالعملها را بهدرستی مشخص کنیم. به دلیل وجود این رویکرد، این قابلیت وجود دارد که بر اساس ابعاد پروژهها نقشها و ساختار تیم مهندسی را مشخص کنیم.
بر اساس همین مهم و الگوهایی که طراحی کردهایم میتوانیم حدود کاری که در پروژه خواسته شده است را تخمین بزنیم. اگر بتوان مشخص کرد چه ورودی، خروجی، نقشها و مسئولیتهایی در فرآیندها وجود دارد، تخمین درستتری قابلارائه خواهد بود. ازآنجاکه در تذرو افزار حوزه BPMS متشکل از چندین تیم است، کلیه مراحل انجام پروژه مانند مستندسازی و الگوهای آنها، وظایف و نقشهای تعامل با مشتری و چکلیستهای انجام وظایف، مشخص است؛ و بر اساس همین داشتهها تیم را برای هر پروژهای سازماندهی کرده و کار را انجام میدهیم.
کمک به مدیریت تغییر
شرکتهای PSP و بهطورکلی صنعت پرداخت یکی از حوزههایی هستند که شما بهطور تخصصی در حوزه BPMS به آنها سرویس میدهید. دقیقاً به کدام نیاز، چالش و مسئله این شرکتها پاسخ میدهید؟
میدانیم که PSPها شرکتهایی پویا و با تغییرات بالا هستند و از طرف دیگر چند اصل مهم دارند که در این بخشها کمتر تغییر میکنند. برای مثال، آنها ازنظر کاربران نهایی و کسبوکار مرتبط، مشتریان و خدماتی که باید به آنها ارائه دهند وضعیت مشخص دارند که شرکت شاپرک سازمان نظارتی آنها است.
با توجه به الزامات شاپرک در زمینه نظارت و پیگیری این شرکتها میبایست ساختار خود را بهگونهای شکل دهند تا بتوانند در راستای این الزامات گام بردارند. این دو بخش PSPها ثابت هستند و یا تغییرات اندکی دارند اما در بقیه موارد مانند ساختار داخلی، دادهها، فرآیندها و گردش کاری داخلی دائماً در حال تغییر هستند که اینجا اهمیت BPMS خودش را نشان میدهد.
میتوانیم بگوییم شما در مدیریت تغییر به شرکتها کمک میکنید؟
دقیقاً؛ ماهیت BPMS یک جمله است: «تغییر». درباره این مفهوم باید گفت تغییر در این قالب خیلی سریعتر از تغییر یک نرمافزار است. BPMS راحتتر میتواند پاسخ یک سازمان بزرگ مثل PSP را بدهد. BPMS میگوید تنها چیزی که قرار نیست تغییر کند، خود تغییر است و میگوید من آزاد هستم تا تغییر را برای تو جاری کنم. من هرلحظه با تغییر بزرگ میشوم و با فرض تغییر ایجاد میشوم. در مراحل بعدی در حال رصد اهداف، باید بتوان اصلاح و تغییر ایجاد کرد تا نهایتاً به اهداف والای سازمانی رسید. باید تغییر را اعمال کنید تا بدانید که آیا به اهداف نزدیک یا دور شدهاید، این یعنی BPMS.
پیچیدگیهای شناخت فرایندها در شرکتهای PSP
این کمک چگونه انجام خواهد شد؟
فازهای این کار شامل شناخت، طراحی، پیادهسازی و استقرار است. ابتدا تحلیل و شناخت انجام میدهیم، سپس طراحی و پیادهسازی میکنیم و در آخر استقرار میکنیم.
ازآنجاییکه شرکتهای PSP ساختار سازمانی پویایی دارند وظایف و متولی انجام فرآیندها نیز همیشه ثابت نیستند، شروع کار کمی سخت و پیچیده است؛ برای مثال شرکت PSP فعالیتی را در حال حاضر بدون مشکل خاصی و بهصورت روتین انجام میدهد اما معلوم نیست نقشها چگونه است و چه کسی طی چه پروتکلهایی این کار را جلو میبرد، درنتیجه در طراحی فرایند، این موضوعات خودشان را نشان میدهند و سازمان بر آن میشود تا متولیان و نقشها را شفاف کند.
ارائه نمونه اولیه
راهحلی برای این مسئله دارید؟
همواره سعی میکنیم اگر مشکلی هست به استانداردهای حوزه رجوع کنیم. این الزامات اصولی است که بر اساس آن سازمان شکلگرفته است، ما در کنار سازمان با تکیهبر این الزامات کمک میکنیم که این فرایندها بهتر و سریعتر انجام شود،
واقعیت این است که نرمافزار یک مفهوم ذهنی است و ملموس نیست. پس از اتمام پیادهسازی و ارائه نرمافزار به بهرهبردار است که آنها نسبت به آن، حس پیدا میکنند. ما در حرفه نرمافزار و برای انتقال این حس، از طریق نمونه اولیه اقدام میکنیم. یک سری مستندات و مدلهای نرمافزاری وجود دارد که یک متخصص تولید نرمافزار آن را درک میکند اما بهرهبرداری که لزوماً هم دانش نرمافزاری ندارد، ممکن است آن را درک نکند. بنابراین یک سری نمونه و شبیهساز از نرمافزار، فرم، گزارش و آنچه قرار است در نرمافزار اتفاق بیفتد درست کرده، آن را به صاحب کسبوکار نشان میدهیم و میگوییم که قرار است نرمافزار این ظاهر و رفتار را داشته باشد. با این عمل، فرد حس میکند که قرار است چه اتفاقی رخ دهد و با این روش با او در اسناد و طراحی همنظر میشویم.
چالش این است که فرد نمیداند دقیقاً چه میخواهد یا نمیداند آن را چگونه بیان کند. شبیهسازی بخشی از راهحل تعامل در جهت تصریح نیازهای استخراج شده است. پس از انجام مرحله شبیهسازی و پیش از شروع پیادهسازی تا حد زیادی جزئیات نیاز سازمان روشن میشود؛ که این موضوع بسیار موفقیت پروژه را تضمین میکند.
از زمانی که یک شرکت PSP مسائل خود را مطرح میکند و قصد پیادهسازی BPMS را دارد تا زمان اجرای آن، چقدر طول میکشد؟
BPMS همواره بهصورت مرحلهای یعنی بهصورت تکاملی کار را پیش میبرد، چراکه فرآیندمحور است. اگر از قبل، نقشه راه سازمان تشکیل شده باشد، کار ما سادهتر است. از زمان شروع کار، میتوان بین یک تا دو ماه به فرآیندهای پیاده شده و اجرایی رسید. در مدلی که نقشه راه سازمان تشکیل شده ما از اول میدانیم قرار است در سازمان چه کار کنیم و فرآیندها و دادهها چه ارتباطی با هم دارند. بر اساس نقشه راه و وضعیت بلوغ بخشهای مختلف سازمان، فرآیندها جهت طراحی، انتخاب و تحلیل میشوند. اگر این نقشه راه مشخص نباشد، یک بازه زمانی یک تا شش ماهه با توجه به پیچیدگیهای هر سازمان و فرآیند به این زمان اضافه میشود تا بتوانیم با کمک متولیان کسبوکار آن سازمان و متخصصین مشاور ما در آن حوزه، نقشه راه را تدوین کرده و مابقی مسیر را طی کنیم.
چالش پیادهسازی BPMS در شرکتهای PSP
چالشهایی که در مرحله استقرار با آن مواجه هستید، چه هستند؟
وقتی به یک سازمان میرویم و با مدیر بخش موردنظر گفتوگو میکنیم، مدیران معمولاً، شرایط ایدهآل مدنظر را مطرح میکنند اما در واقعیت کارشناس و بهرهبردار مستقیم مسیر و کار متفاوتی انجام میدهند. به همین دلیل قبل از توافق نهایی با مدیر مربوطه تأییدیه بهرهبردار که قرار است از آن سیستم استفاده کند را نیز میگیریم. این یکی از بزرگترین چالشهای ما بوده است که توانستهایم آن را حل کنیم.
بهعنوان راهحل، ما دو کمیته کاربری و راهبری تشکیل میدهیم. کمیته راهبری برای این است که درباره سیاستهای کلی پروژه گفتوگو و هدفگذاریها انجام شود. کمیته کاربری هم وظیفه دارد تا بهرهبرداران را دعوت کند که در پنل طراحی و شناخت به ما کمک کنند. انجام موفقیتآمیز این کار، چالش ما در انتهای پروژه را خیلی کمتر میکند.
علاوه بر اینها، ما در ابتدای پروژه، نقشه استقرار سرویسها را مشخص کرده و شرایط سرور، محیط و بستر و غیره را تعیین میکنیم. با این روش ریسکهای عملیاتی سازی فرآیندها کاهش پیدا میکند.
اما بههرحال ممکن است موقع استقرار به شرایط محیطیای برخورد کنیم که از سرورها، شبکه و یا مسائل امنیتی باشد. بررسی کردن و یافتن راهحل برای این موضوعات و شرایط خاص ممکن است زمان بیشتری به پروژه تحمیل کند. این موضوع زمانی حاد میشود که شرایط بهطور کامل به ما منتقل نشده یا آمادگی لازم برای مواجه با آن فرض نشده باشد. بهویژه در شرکتهای PSP که تدابیر ویژه امنیتی باید در آنها رعایت شود، این موارد بسیار چشمگیر بوده و ما همیشه توجه ویژهای به این قبیل مسائل داریم.
مضاف بر این موارد، ما در سه سطح کاربری، مدیریتی و راهبری آموزش میدهیم. معمولاً وقتی آموزشهای دوره اول را میدهیم، فرد درگیر کار اجرایی و روزمره است لذا تمرکز کافی ندارد. لذا پسازاینکه مسئولیت انجام کار با سیستم به او داده شد، متوجه میشود به مواردی توجه نکرده، بنابراین ما مجبور هستیم آموزشها را تکرار کنیم و چندین باره آموزش را انجام دهیم.
در مرحله پیادهسازی نرمافزار، چالش اصلی از قبل و از بحث شناخت و تحلیل تحمیل شده است. پیادهسازی برای ما خیلی چالش ندارد اما در استقرار بهصورت پررنگ نمایان میگردد. مثلاً وقتی ما فرآیند پیادهسازی شده را تحویل میدهیم، ممکن است فرد بگوید نیاز من مرتفع نمیشود و عامل بازدارنده وجود دارد. باید همهچیز را دستهبندی و مشخص کنیم که آیا واقعاً عوامل مطرح شده بازدارنده است یا خیر؟
بهترین روش، اولویتبندی عوامل بازدارنده بر اساس بودجه و زمانبندی تغییرات است؛ بنابراین در همان ابتدای اعلام موارد، باید زمان، هزینه و از همه مهمتر تأثیر تغییر در فرآیند را در نظر داشته باشیم.
از دیگر چالشهای سازمانی این است که دستاوردهای پیادهسازی یک سیستم BPM شفاف نیست. لذا باید پس از هدف اصلی که اجرایی سازی فرآیندها است، رسیدن یا نزدیک شدن به اهداف و معیارهای کسبوکار، دائماً پایش شود.
ایجاد حس و نمایانسازی تأثیر BPMS بر کسبوکار عملاً حلقه گم شده در این بحث است. معمولاً همه سازمان درگیر طراحی و اجرا میشوند اما رصد کردن، مدیریت کسبوکار و بهبود انجام نمیشود. ما سعی کردهایم از همان ابتدا آنچه یک کسبوکار بعد از پیادهسازی BPMS به دست میآورد را برایش روشن کنیم تا ضمن شفافسازی تأثیر اجرای این سیستم، توقعات غیرواقعی را کاهش دهیم.