مدیریت فناوری اطلاعات

ارائه مقالات مدیریت و فناوری اطلاعات، پسوردهای دانشگاه ها ( sciencedirect, IEEE,Emerald, Proquest )، کنفرانس ها و عمره دانشجویی

مدیریت فناوری اطلاعات

ارائه مقالات مدیریت و فناوری اطلاعات، پسوردهای دانشگاه ها ( sciencedirect, IEEE,Emerald, Proquest )، کنفرانس ها و عمره دانشجویی

ERP چیست ؟

http://blog.taragana.com/wp-content/uploads/2009/02/erp.gif



تعریفE.R.P


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

یکی از بهترین تعاریفی که برای ERP وجود دارد عبارت است از:

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

دست یابی به حداکثر کارایی در پیاده سازی این نرم افزار با هماهنگ سازی آن با نیازهای سازمانی، بسیار پیچیده است.ERP به سازمان برای فعالیت در محیطی یکپارچه از نظر اطلاعاتی و فرایند گرا و اطلاعات محور و بصورت Real-time کمک بسیار زیادی می کند."

در تعریف فوق نکات قابل توجهی وجود دارد که قبل از پرداختن به سایر تعریف ها بهتر است آنها را مورد بررسی قرار دهیم.

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

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

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

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

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

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

معماری سازمان ( جان زکمن )

ابتدا نگاهی به گذشته:

می توان چهار دلیل عمده آورد که چرا معماری سازمانی انطور که باید پیشرفت نکرد.

الف: معماری مقابل فرهنگ بودمعماری مقابل فرهنگ بود. در طول 50 سال گذشته، چالش اصلی در سیستم های اطلاعاتی تلاش برای ساده سازی تولید و استفاده از نرم افزار ها بوده است. تمام همت ما "تولید کد برنامه" بود و معیارهای اندازه گیری کارائی نرم افزار ها محدود به چند معیار بود: تعداد خط کد برنامه، میزان نفر-ماه کار برنامه نویسی، زمان پاسخ برنامه، بودجه، هزینه و ...
در فرایند تولید نرم افزار سعی کردیم تا بطور ضمنی استانداردها را رعایت کنیم، برنامه قابل استفاده مجدد، قابل انتقال، شیء گرا و...  باشد درحالیکه واقعیت این است که ما هیچکدام از این موارد را به درستی رعایت نمی کردیم!
با مثالی موضوع را توضیح می دهیم، آیا تا کنون فروشگاهی را دیده اید که بتوان در آن برای راه ها، جاده ها، پل ها، معماری ها و دیگر زیربنا ها قیمت تعیین کرد؟ مثلما نه! مشکل آنجاست که این موارد بسیار مهم قابل ارزش گذاری نیستند و معمولا زمانی که به انها احتیاج ضروری است، آنها وجود ندارند! مگر اینکه در گذشته کسی با پیش بینی و آینده نگری آنها را فراهم کرده باشد.
حال مفهوم مقابل فرهنگ روشن شد. نمی دانیم چگونه "معماری" را ارزش گذاری کنیم، در نتیجه نمی توانیم آنرا بدست آوریم! چون کسی احساس نیاز حیاتی به آن نکرده(علی رغم ضرورت حیاتی آن) و تلاشی در جهت تهیه آن نشده است، زمانی که فهمیدیم چقدر به آن احتیاج داریم آنرا نداشتیم.

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

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

ستون 1(داده):
- Chen(4)، Brown(5)، Finkelstein(6) و Bachman(7) بر روی توصیف و طراحی این ستون متمرکز شدند.
ستون 2 (فرایند):
- Hammer و Champy(3) بر روی سطر دوم کارهای مفیدی در زمینه مهندسی مجدد فرایند حرفه(BPR) انجام دادند.
 - Demarco(1) نیز در توصیف جنبه عملکرد معماری سازمان در سطر 3 و 4 تلاشهای فراوانی کرد.
ستون 3(مکان):
 - در خصوص این جنبه کمتر کاری انجام شده
ستون 4 (اشخاص):
-  Drucker(8) در مفاهیم سازمانی و کنشگران، کارهای باارزشی روی سطر 2 انجام داه ولی در خصوص سطرهای پائین تر هنوز باید چیزهای زیادی بیاموزیم.
ستون 5 (زمان):
- Senge(9)  تلاشهای زیادی در توصیف مدلهای پویائی سیستمها () انجام داده ولی ارتباط این مدلها با سطر سوم مشخص نیست
ستون 6(انگیزه):
- Ross(10) و Lam در زمینه ارائه تعریف برای قوانین حرفه(Business Rules) و رابطه ان با اهداف و استراتژی سازمان در سطر 2 پیشرفتهای خوبی کرده اند ولی در بقیه سطرها هنوز کاری نشده است.

خلاصه مدلهای معماری سازمان و چگونگی پیاده سازی آنها به درستی مشخص نبود و احتیاج به کار بیشتری داشت. هنوز ذهن مدیران پروژه مایل بود به "تو برنامه نویسی را شروع کن تا بعد ببینیم نیاز مشتریان چیست! معماری را فراموش کن" !

ت: معماری نیاز به کار واقعی داردچهارمین و اخرین دلیل برای عدم پیشرفت معماری، نیاز به زمان و تلاش برای پیاده سازی بود. لازم بود تجربه هایی در این زمینه انجام شود تا راه برای نمونه های موفق باز شود. مشکل ما این است که در هر موردی دنبال راه حلهای سریع و بی دردسر هستیم. در خصوص سازمان نیز مدت 40سال دنبال جوابهای ساده بودیم.
حال که فهمیده ایم کامپیوتر یک وسیله ساده نیست که بتوان به راحتی از آن در سازمان استفاده کرد، بلکه "مالک"، "طراح" و "سازنده" باید با همکاری هم معماری را پیاده سازی کنند که این مورد احتیاج به کار عملی دارد و این موضوع زمان می برد.
سازمانها پیچیده تر از آن هستند که مشکل انها با راه حلهای ساده و سریع حل شود. برای توضیح مثالی را ذکر می کنیم، مهندسین راه و ساختمان باید پس از سالها درس خواندن در مقاطع دبیرستان و پیش دانشگاهی، 4 سال در دانشگاه درس تخصصی بخوانند انگاه به مدت 10 سال یا بیشتر به عنوان کار اموز به کسب تجربه در طراحی و پیاده سازی جاده ها، پل ها و ... بپردازند تا سرانجام قادر به ساخت پروژه های واقعی شوند، درحالیکه ما در مهندسی کامپیوتر با فرستادن شاگردان به کلاس برنامه نویسی فلان زبان برای فقط چند روز انها را برای انجام پروژه های واقعی اعزام می کنیم !
نتیجه آنکه معماری سازمانی که به مراتب پیچیده تر از ساخت یک پل یا راه نیز است نیاز به زمان و کار فراوان دارد.

خلاصه از گذشته
چهار دلیل اصلی برای پیشرفت کند معماری سازمانی و عدم توجه لازم به ان در گزشته عبارت بود از:
- معماری مقابل فرهنگ بود.
 - درک درستی از اهمیت حیاتی ان وجود نداشت.
 - نمی دانستیم دقیقا چگونه باید معماری را پیاده ساز ی کنیم.
- احتیاج به کار و زمان دارد.

نگاهی به آیندهبا توجه به شرایط حال و با نگاهی به اینده می توان 4 دلیل اصلی برای پیشرفت و به عبارتی انقلاب در معماری سازمانی بر شمرد.

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

ب: معماری یک موضوع حیاتی شده استبرای روشن شدن مطلب نگاهی به شرکت معروف IBM می اندازیم. سئوال اینجاست که چرا این شرکت نتوانسته جایگاه خود در زمینه "تکنولوژی اطلاعات" را حفظ کند؟ ایا مسئولین IBM نادان بوده اند ؟ یا تغییر بازار را درک نکرده اند؟ من به قطع می گویم که هیچکدام از این دو موضوع نیست. انها نتوانستند مطابق تغییر در بازار عمل کنند چون فاقد معماری بودند! وقتی معماری نباشد، تغییر در سیستمها ممکن نیست و در نتیجه تغییر در سازمان(به یاد بیاورید که سیستم ها همان سازمان هستند) قابل اعمال نخواهد بود. مدیران IBM نمی دانستند "چگونه" و "چه چیز" را باید تغییر دهند.
یا در خصوص شرکت جنرال موتور، چرا این شرکت جایگاه خود را در بازار از دست داد، ده ها هزار نفر را اخراج کرد و تعداد زیادی از واحدهای خود را تعطیل کرد؟ مدیران جنرال موتور هم تغییرات بازار را درک کرده بودند ولی از انجا که برای سازمان خود معماری نداشتند، اصلا نمی دانستند سازمانشان دقیقا چگونه کار میکند! پس نمی دانستند "چه چیز" را باید "چگونه" تغییر دهند تا با تغییرات بازار هماهنگ شوند.

پ: می دانیم چگونه معماری را پیاده سازی کنیمسوم اینکه اکنون تقریبا می دانیم چگونه معماری را پیاده سازی کنیم. اخیرا دو کتاب نوشته شده که در نوع خود قابل تقدیر است.
- Boar(15) در کتاب اخیر خود علامت گذاری رسمی برای برای سطر 3 در ستون فرایند و مکان پیشنهاد داده است.
- Loosley(16) و Douglas در خصوص مکان قرار گرفتن جنبه های "فرایند"، "داده" و "اشخاص" بحث کرده است.
- Ross(17) و Lam در خصوص ستون "انگیزه" و در سطرهای 2و 3 بر روی توصیف و طراحی قوانین حرفه(Business Rules) کارهای خود را ادامه داده و به نتایج خوبی رسیده اند.
 - Bruce(18) کتابی در خصوص ستون 1، مدلسازی داده، نگاشته است.
- Cook(19) و Spewak(20) در خصوص ستونهای 1و2و3 (داده، عملکرد، مکان) و در سطرهای 1 و تاحدی 2 کارهای خوبی انجام داده اند، مخصوصا Spewak(20) که با معرفی متدولوژی معماری سازمانی(Enterprise Architecture Planning) گامهای موثری در پیاده سازی معماری سازمانی برداشته است.
- تنها جائی که هنوز به کار بیشتری نیاز دارد ستون "انگیزه" در سطر 4  و ستونهای "اشخاص" و "زمان" در سطر 3 است.
بهرحال در جمع بندی باید گفت، اکنون دیگر می دانیم چگونه معماری را پیاده سازی کنیم.

ت: ابزارها برای کار پیاده سازی معماری فراهم شدهدلیل چهارم برای پیشرفت معماری، تولید و توسعه سریع ابزارهائی برای پشتیبانی معماری است. بدین ترتیب اخرین مانع برای کار عملی در معماری سازمانی نیز برداشته شده.

اخیرا ابزارهای زیادی تولید شده که چند مورد ان معرفی می شود:
 - System Architect یک ابزار موثر از شرکت Popkin
 - PETCH، ابزاری برای مدلسازی گرافیکی سازمان
 - METIS وسیله برای مدلسازی سازمان، تهیه شده توسط NCR
 -  Design Bank از گروه Metadata که یک انبار از چارچوب هاست

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

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

فراموش نکنید که "معماری سازمانی" موضوع قرن 21 ام است