ساختن یا خریدن مسئله این است. (BPMS vs COTS)

همواره یکی از مهمترین دغدغه ها در حوزه فناوری اطلاعات، رویکرد مناسب برای تامین سیستم های اطلاعاتی بوده و هست. همیشه دو رویکرد اصلی برای تامین سیستم های اطلاعاتی وجود داشته است. خرید یک سیستم آماده (Commercial Off The Shelf) و یا تولید یک سیستم از صفر (Custom made)

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

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

BPMS وارد میشود…

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

از آن زمان تا کنون پروژه های زیادی در سطح جهان و حتی کشور خودمان با این تکنولوژی اجرا شده است؛ شرکتهای نرم افزاری کمی را میبینید که در قابلیتهایشان به BPMS اشاره نکنند. این تکنولوژی نسبت به ۱۰ سال پیش بلوغ بیشتری پیدا کرده است، اما با وجود این تکنولوژی هنوز هم بسیاری از پروژه های نرم افزاری شکست می خورند و اتفاقا سهم پروژه های مبتنی بر BPMS ها اصلا کمتر از بقیه روشهای تولید نیست! اما چرا؟

 

همه یک سیستم اطلاعاتی کد نیست

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

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

یک پکیج فقط یک سیستم اطلاعاتی نیست

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

 مقایسه دو رویکرد تامین 

با این اوصاف BPMS ها هم نمی توانند همه مشکلات را حل کنند و واقعیت آن است که هر کدام از این رویکردها مزایا و معایب خود را دارند. در جدول زیر مزیتهای هر یک از دو روش خرید پکیج (COTS) و تولید از طریق BPMS به شکل خلاصه آورده شده است.

COTS BPMS
عموما هزینه پایین تر انطباق بالای سیستم با نیازمندیهای سازمان
بهره مندی از دانش رسوب یافته در سیستم امکان توسعه آتی سیستم در داخل سازمان
ریسک پایینتر اجرای پروژه خرید نسبت به اجرای پروژه تولید امکان توسعه سیستم های ساده با دانش برنامه نویسی کمتر

 رویکرد ترکیبی

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

 

نویسنده : امیر یزدانی

شما ممکن است این را هم بپسندید

دیدگاهتان را بنویسید

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