جديدترين مقالات مرتبط با مدیریت فناوری اطلاعات IT
ارسال شده توسط احمد محمدی | 10 12, 2013 | بازدید‌ها (4822)
بررسی معماری Client/Server در مدلهای تک لايه، دو لايه، سه لايه و چند لايه و اصول طراح معماری برنامه های تحت وب 

در اواسط دهه ۸۰ ميلادی و زمانيكه اولين بار توليدكنندگان تجهيزات شبكه، محصولات خود را به بازار عرضه كردند، واژه Client/Server وارد عرصه كامپيوتر گرديد. در آن زمان واژه فوق صرفا در رابطه با تجهيزات سخت افزاری ( كامپيوتر ) استفاده می شد و كامپيوتری كه از آن بعنوان مركز ثقل ارائه خدمات در يك شبكه ياد می شد، را با نام Server و كامپيوتری كه از اين امكانات استفاده می كرد را بعنوان Client می شناختند ( سايه نرم افزار بر اين واژه حضور سنگينی نداشت ).

امروزه واژه فوق دارای يك معنی خاص است كه چندان مرتبط با سخت افرار نمی گردد. اغلب مردم هنوز واژه Client را به يك كامپيوتر فيزيكی نسبت داده و واژه Server را به كامپيوتر فيزيكی ديگری كه به آن متصل و سرويس هائی را ارائه می نمايد، اطلاق می نمايند. مطلب فوق با اينكه درست است ولی صرفا يك بخش اندك از تمامی واقعيت های موجود در اين زمينه است. واژه فوق امروزه در مقياس وسيعتری به خدمت گرفته می شود. بمنظور آشنائی بيشتر با اين واژه لازم است در ابتدا با ساختار و يا معماری عمومی يك نرم افزار آشنا شويم.

اغلب برنامه های كاربردی دارای سه لايه اصلی می باشند :

لايه Presentation: ( بالاترين لايه ) اين لايه مسئول ايجاد ارتباط متقابل بين انسان و كامپيوتر است ( رابط كاربر). لايه فوق مسئوليت گرفتن اطلاعات ورودی از صفحه كليد، ماوس و ساير دستگاههای ورودی و نمايش اطلاعات ذيربط بر روی دستگاههای خروجی نظير صفحه نمايشگر است. 

لايه Application يا Business Logic: لايه فوق مسئول اعمال و پياده سازی سياست های مورد نظر در يك نرم افزار است، در حقيقت با عملكرد لايه فوق است كه می توان تفاوت بين يك نرم افزار از نرم افزار ديگر را مشاهده و بعنوان مثال تفاوت بين يك نرم افزار ثبت سفارش و يا انبارداری را حس كرد.

لايه Service: اين لايه مسئول ارائه سرويس های خاص و مورد نياز برای ساير لايه ها نظير سرويس های مربوط به فايل، چاپ، ارتباطی و از همه مهمتر دسترسی به بانك های اطلا عاتی است. در ادامه بحث خود را بر روی مجموعه ای از نرم افزارها ئی متمركز خواهيم كرد كه نيازمند سرويس های بانك اطلاعاتی باشند.

تعداد طبقات ( Tires )، در يك نرم افزار Client Server به نحوه ارتباط ( متراكم، معمولی ) هر يك از سه لايه گفته شده بستگی خواهد داشت. در ادامه به بررسی مدل های رايج در اين زمينه خواهيم پرداخت.

مدل One-Tire
در اين نوع نرم افزارها سه لايه گفته شده بصورت متراكم و فشرده در كنار يكديگر قرار می گيرند. در مدل فوق لايه Presentation دارای آگاهی خاص و جزئی از ساختار بانك اطلاعاتی است. لايه Application اغلب بصورت موجی با لايه های Presentation و Service مرتبط خواهد بود. تمام سه لايه گفته شده بهمراه بانك اطلاعاتی، اغلب بر روی يكدستگاه كامپيوتر قرار گرفته و اجرا خواهند شد. نرم افزارهائی با اين خصوصيت بسادگی طراحی شده و بكمك ابزارهای برنامه نويسی امروزی بسرعت نوشته خواهند شد.

در صورتيكه بخواهيم يك نرم افزار One-tire با چندين كاربر را طراحی نمائيم، می توان نرم افزار را بر روی چندين كامپيوتر اجرا و با به اشتراك گذاشتن بانك اطلاعاتی زمينه استفاده از داده های موجود در بانك را برای ساير كاربران نيز فراهم نمود. بانك اطلاعاتی را می توان بر روی يكدستگاه كامپيوتر معمولی در يك شبكه نظير به نظير ( Peer to Peer ) و يا بر روی يك سرويس دهنده فايل ( File Server ) نصب نمود. در اين حالت هر يك از كامپيوترهائی كه برنامه بر روی آنها اجرا می گردد می بايست دارای يك نسخه از Database Engine بوده تا قادر به استفاده از داده های موجود در بانك اطلاعاتی باشند. در اين مدل صرفا داده ها به اشتراك گذاشته شده و منطق بانك اطلاعاتی به اشتراك گذاشته نشده است. اين نوع از نرم افزارها ( چند كاربره One Tire ) تا زمانيكه تعداد كاربران كم باشد موفق عمل می نمايند ولی با افزايش تعداد كاربران، با مشكل مواجه می شوند.

علت عمده بروز مشكل پايبند بودن اين نوع از نرم افزارها به انجام عمليات مربوط به بانك های اطلاعاتی بر روی هر يك از سرويس گيرندگان است. مثلا اگر برنامه ای از اين نوع نياز داشته باشد كه ليست تمامی كاربرانی را كه نام آنها Reza است، را نمايش دهد، می بايست تمامی اطلاعات ( ركوردهای داده و ايندكس های مربوطه ) بمنظور پاسخگوئی به درخواست واصل شده، بر روی شبكه فرستاده شود. در برخی حالا ت خاص و با توجه به پيچيدگی درخواست های صادر شده برای اطلاعاتی خاص، ممكن است تمامی بانك اطلاعاتی برای سرويس گيرنده ارسال گردد.

اگر از يك سطح فنی به مسئله فوق نگاه كنيم، مديريت Database Engine های مستقل بر روی سرويس گيرندگان بمنظور ممانعت از بروز تعارض ( Conflict ) بين دو سرويس گيرنده جهت تلاش برای دستيابی و يا بهنگام سازی برخی ركوردها مشكل است ( مسئله Record Locking ).

مدل Two Tire
بمنظور حل مشكل مطرح شده در مدل One-tire از بعد كارائی و مسائل فنی مربوطه، مدل فوق معرفی گرديد. نرم افزارهائی كه با اتكا بر مدل فوق طراحی و پياده سازی می گردنند در اغلب موارد دارای عملكردی مشابه مدل One Tire بوده با اين تفاوت مهم كه Database Engine بر روی سرويس گيرنده ها اجرا نخواهد شد.

در مدل فوق بانك اطلاعاتی بر روی سرويس دهنده اجرا می گردد. از روش های متعددی برای ارتباط بين لايه Application(Logic) و Database Service استفاده می گردد. SQL ( زبان ساختيافته پرس و جو ) از متداولترين روش های موجود در اين زمينه است. دستورات SQL به سرويس دهنده بانك اطلاعاتی ارسال شده و در آنجا عمليات مربوطه بصورت محلی انجام و نتيجه ( اطلاعات مربوط به درخواست ارسال شده ) برای سرويس گيرنده ها ارسال خواهد شد. در مدل فوق صرفا سرويس دهنده بانك اطلاعاتی از برنامه مجزا شده و لايه های Presentation و Busines Logic همچنان در هم تنيده هستند. دو لايه فوق همچنان دارای آگاهی اساسی ( محرمانه ) از بانك اطلاعاتی خواهند بود.

نوشتن برنامه هائی از اين قبيل تا اندازه ای پيچيده تر از مدل قبل است. امروزه ابزارهای برنامه نويسی نيز مجهز به پتانسيل هائی شده اند كه طراحی و نوشتن اين نوع از برنامه ها را سرعت می بخشد. اغلب ابزارهای برنامه نويسی دارای امكاناتی جهت استفاده از DataBase Engines بوده كه می توان از آنها در طراحی برنامه های One-Tire استفاده كرد ( نظير Jet Engine كه توسط اكسس و ويژوال بيسيك استفاده می گردد) اما نرم افزارهای Two Tire نيازمند محصولات مجزای بانك اطلاعاتی نظير Oracle , IBM DB2 , Sybase و SQL Sever می باشند.

مدل Three Tire
اين مدل همانگونه كه احتمالا حدس زده ايد تمامی سه لايه گفته شده را در بخش های مستقل قرار می دهد. در مدل فوق Business Logic يك سرويس است و می تواند بر روی كامپيوتر اختصاصی خود فعال و اجرا گردد. زمانيكه Business بصورت يك سرويس دهنده در نظر گرفته می شود با نام Application Server ناميده می شود. يك Application Server اغلب ممكن است بر روی همان كامپيوتری كه DataBase Engine قرار دارد، نصب گردد. شايد يكی از دلايل مهم جهت انجام اين كار افزايش كارآئی سيستم باشد.

يكی از مزايای مهم و كليدی، داشتن يك Application Server اين است كه بتوان آن را در محلی قرار داد كه به بهترين نوع ممكن خدمات خود را ارائه نمايد. در اين مدل مسئله حائز اهميت در اين است كه تمامی Application Serverها بتوانند و می بايست سرويس بانك اطلاعاتی خود را از يك كامپيوتر مركزی دريافت دارند. ( ممكن است در برخی حالات تعدادی از كاربران نرم افزار از يك Application Server كه بر روی يك كامپيوتر مجزا قرار گرفته است استفاده نمايند و يك كاربر از راه دور ممكن است Application Server را بر روی يكدستگاه كامپيوتر اختصاصی اجرا نمايد.) بهرحال محل Application Server و Database Server ارتباطی با كاربر نداشته و تمامی آنها با يك روش يكسان از نرم افزار و توانائی آن استفاده می نمايند.

در مدل فوق لايه Presentation دارای آگاهی خصوصی از بانك اطلاعاتی نبوده و لايه فوق از طريق لايه Application Server و بكمك يك استراتژی خاص با بانك اطلاعاتی مرتبط خواهد بود. مرورگرها در حالت خاص دارای هيچگونه شناختی از ساختار بانك اطلاعاتی در سايت Amazon.com نمی باشند ولی با اين حال قادر به ارتباط با بانك اطلاعاتی و خريد يك كتاب هستند. در مدل فوق با نگرش وب، سرويس گيرنده از طريق يك پروتكل خاص با يك Application Server مرتبط می گردد. برنامه هائی از اين نوع ( مدل Three Tire ) پيچيده تر از مدل های قبلی بوده و هنوز ابزارهای برنامه نويسی خاصی در اين زمينه وجود ندارد و برنامه نويسان مجبور به نوشتن حجم بالائی از كدها خواهند بود.

مدل N Tire
اين مدل امروزه بسرعت رايج و مطرح شده است. در حقيقت مدل Three Tire در حالت خاص به سمت N-Tire ميل خواهد كرد. در اين حالت يك Application Server می تواند درخواست خود را از چندين سرويس ديگر داشته باشد. هر يك از سرويس های صدا زده شده نيز خود می توانند سرويس های ديگری را جهت پاسخگوئی به درخواست واصل شده، فعال نمايند. واژه MiddleWare اغلب جهت تشريح ارتباط يك برنامه يا Business Logic بر روی يك Application Server استفاده می گردد.

چه ميزان از Bussines Logic می بايست بر روی Application Server قرار گيرد؟
بدون شك يكی از بخش های مهم هر نرم افزار كه دائما می تواند دستخوش تغييرات گردد، مجموعه قوانينی است كه با اعمال آنها سياست عملكردی يك نرم افزار تعيين می گردد. مثلا در يك سيستم بازرگانی می توان قانونی را داشته باشيم كه برای خريدهای بالای يكصد هزار تومان مجوز مدير مربوطه فرض است. در اين حالت می توان قانون فوق را بصورت يك روتين ( سرويس ) و بصورت جامع طراحی و در لايه Application قرار داد، سرويس فوق می تواند توسط ساير سرويس های موجود در اين لايه و يا ساير لايه ها مورد استفاده قرار گيرد. بديهی است در صورتيكه اين سياست به نوعی تغيير نمايد و قرار شود از اين پس خريدهای بالای يكصد و پنجاه هزار تومان مكلف به تاييد مديريت مربوطه باشند، بسادگی با اعمال تغيير در روتين فوق و تزريق سياست جديد، زمينه استفاده اتوماتيك از آن برای ساير سرويس های استفاده كننده فراهم می گردد.

نحوه و زمان تغيير سياست فوق از ديدگاه استفاده كننده و لايه Presentation مهم نبوده و تغييرات بصورت خودكار در تمامی سرويس های موجود در ساير لايه ها حس خواهد شد. بنابراين مجموعه قوانين و سياست هائی كه در روند عملياتی يك نرم افزار نقش تعيين كننده ای را دارند، می بايست در لايه Application قرار گرفته تا بدينوسيله امكان درج تغييرات و اعمال سياست های جديد مركزيت يافته و مسائل مربوط به پشتيبانی و ارتقا يك نرم افزار با اطمينان خاطر و صرف كمترين زمان و هزينه صورت پذيرد.

در برخی از موارد می توان اين سياست ها را در قالب مجموعه ای از سرويس ها در لايه Presentation قرار داد. بررسی صحت داده های ورودی يك نمونه مناسب در اين زمينه است. در اين مورد اغلب قوانين جهت بررسی اعتبار و صحت داده های ورودی بر روی لايه Presentation قرار خواهد گرفت. بديهی است در چنين حالتی بجای ارسال اطلاعات بررسی نشده به لايه Application و بكارگيری يك روتين جهت بررسی صحت داده ها، می توان اين عمليات را در لايه Presentation قرار داد تا بدينوسيله از يكطرف ترافيك محيط انتقال داده ها افزايش نيابد و از طرف ديگر كاربران رودرو با لايه Presentation بازخوردهای سريعی را از سيستم داشته باشند. بهرحال در چنين حالاتی بخشی از منطق عملكرد يك نرم افزار را در لايه Presentation قرار داده ايم. در صورتيكه حجم Logic اضافه شده در لايه Presentation كم و ناچيز باشد، در اينصورت لايه فوق بصورت انحصاری مسئوليت های پيش فرض خود را دنبال خواهد كرد. در چنين وضعيتی سرويس گيرنده را Thin Client می گويند. در حالتيكه بر روی سرويس گيرنده، Logic بالائی قرار گرفته باشد، به آن Fat Client می گويند.بهترين نمونه از يك Thin Client، مرورگرهای وب بوده كه قادر به ارتباط با انواع نرم افزهائی است كه بر روی وب سايت قرار دارند.

جمع بندی
واژه Client Server دارای معانی بمراتب بيشتری نسبت به جداسازی يك كامپيوتر سرويس گيرنده و سرويس دهنده از يكديگر است واژه فوق بسرعت در دنيای نرم افزار نيز مطرح و دارای جايگاه ويژه ای در اين زمينه شده است. از ديدگاه فوق يك روتين ( سرويس ) می تواند ارائه دهنده خدمات خاصی به ساير سرويس ها باشد. در چنين وضعيتی سرويس ارائه دهنده خدمات را Server و سرويس استفاده كننده از يك خدمات را Client می گويند. با تعميم سياست های طراحی نرم افزار از مدل های One Tire به Two-Tire و Three Tire و نهايتا N-Tire و تاكيد بر نگرش ساختيافته و اصولی به عملكرد هر يک از لايه ها، مفهوم روتين های سرويس دهنده ( Server ) و روتين های سرويس گيرنده (Client) جايگاه ممتازی را پيدا نمودند.

يك سرويس می تواند در عين خدمات دهی به ساير سرويس های متقاضی، خود نيز از خدمات ساير سرويس ها استفاده نمايد. بنابراين يك سرويس دهنده در چنين حالتی بصورت اختصاصی صرفا رسالت سرويس دهی و يا سرويس گيری را انجام نخواهد داد. اگر از ديگاه هر لايه به عملكرد سرويس ها نظری داشته باشيم، قطعا تمامی آنها مسئوليت ارائه يك سرويس خاص را در لايه مربوطه برعهده خواهند داشته و قدرمطلق تمامی آنها ارائه خدمات است. مهمترين مزيت نگرش فوق حركت بi سمت توليد سرويس هائی خواهد بود كه اولا امكان استفاده از آنان در چندين نرم افزار فراهم شده و ثانيا زمينه تحقق اصل بسيار مهم استفاده مجدد از كدهای نوشته شده (Reusable Code) نيز فراهم می گردد. امروزه با توجه به نياز روزافزون به طراحی و پياده سازی نرم افزارهای متكی بر وب، مدل های Three Tire و N-Tire بشدت مورد توجه طراحان و پياده كنندگان نرم افزارهای متكی بر بستر وب قرار گرفته است.

ارسال شده توسط احمد محمدی | 10 12, 2013 | بازدید‌ها (3163)

برنامه ریزی منابع انسانی با رویکردی استراتژیک
مولف/مترجم: احمدرضا طالبیان
موضوع: مدیریت منابع انسانی / برنامه ریزی راهبردی
سال انتشار(میلادی): 2003


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

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

پیوند میان برنامه ریزی راهبردی و منابع انسانی
همانگونه که گفته شد، برنامه ریزی عبارت است از طریقه و روش نیل به اهداف سازمانی، و به تبع آن استراتژی عبارت از تمام امکانات لازم برای انجام موفقیت آمیز وظایف سازمانی است.(2) از این رو، برنامه ریزی استراتژیک فرایندی است که ضمن آن اهداف بلندمدت سازمانی تعیین و تصمیم گیری برمبنای روشها، جهت دستیابی به این اهداف را دربرمی گیرد که از قبل پیش بینی شده اند. یا به عبارتی، تلاش سازمان یافته و منظم برای تصمیم گیری اساسی و انجام اقدامات بنیادی است که جهت گیری فعالیتهای یک سازمان با دیگر نهادها را در چارچوب قانونی شکل می دهند.(3)
برنامه زمانی، برای فرایند برنامه ریزی استراتژیک به ماهیت، نیازهای سازمان و محیط خارجی آن بستگی دارد. برنامه ریزی در سازمانها درقالب تولیدی و خدماتـــی انجام می گیرد که سریعاً درحال تغییراند. در چنین موقعیتی، برنامه ریزی ممکن است یک یا دو بار در سال به صورت یک سری مراحل جامع و جزئـــــی تدریجی با توجه به ماموریت، چشم انداز، ارزشها، کنکاش محیطی، اهداف، استراتژی ها، مسئولیتها، جدول زمانی، بودجه و غیره انجام گیرد. به عبارتی، اگر سازمانی سالهای زیادی در بازار ثابت فعالیت می کند برنامه ریزی ممکن است در سال یک بار و فقط در بخشهای مشخصی صورت گیرد. برای مثال، برنامه ریزی درحین کار (ACTION PLANNING) ازطریق اهداف&، مسئول یتها، جدول زمانی، بودجه و غیره هر ســال به روز می شوند. توجه به راهنماییهای زیر می تواند موسسات را در برنامه ریزی استراتژیک یاری کند.(4)
اجرای برنامه ریزی استراتژیک همزمان با آغاز فعالیت سازمان است. برنامه ریزی استراتژیک معمـــولاً بخشی از یک برنامه کسب و کار تجاری، همراه با برنامه بازاریابی، برنامه مالی و عملیاتی است؛ برنامه ریزی استراتژیک با آمادگی موسسه برای سرمایه گذاری جدید انجام می شود. برای مثال توسعه یک بخش جدید، تولید عمده کالای جدید یا خط تولید جدید؛
برنامه ریزی استراتژیک باید حداقل سالی یک بار به منظور آماده سازی سازمان جهت سال مالی جدید اجــــرا شود. به عبارتی، برنامه ریزی استراتژیک باید در یک زمان مشخصی باتوجه به اهداف سازمانی تعیین شده و منابع دردسترس برای نیل به اهداف در طول سال مالی انجام شود. فرایند برنامه ریزی استراتژیک باید حداقل در سه سال اجرا شود و اگر سازمان درحال تغییر و دگرگونی است این فعالیتها باید هر سال اعمال گردد؛ هر سال برنامه های حین کار به روز گردند؛
در طول اجرای برنامه های استراتژیک، پیشرفتهای اجرای برنامه باید بازبینی شود.
برنامه ریزی استراتژیک ازطریق روشهای مختلفی در سازمانها به کار گرفته می شود که مزایایی را برای سازمانها وموسسات به ارمغان می آورد، این مزایا عبارتند از:(5)
تعریف واضح از اهداف سازمان درجهت سازگاری با ماموریت سازمان باتوجه به ظرفیت و چارچوب زمانی تعیین شده برای سازمان؛
ارتباط اهداف و مقاصد سازمان با اجزاء و عناصر سازمانی مشخص می گردد توسعه حس مشارکت در برنامه ها
اطمینان از به کارگیری اثربخش تر منابع سازمان
تمرکز بر اولویتها و منابع کلیدی
فراهم آوردن مبنایی برای پیشرفت کارکنان و سازوکارهایی جهت تغییر توجه بیشتر به کارایی و اثربخشی؛
پل ارتباطی بین کارکنان و هیئت مدیره و مدیران؛
تیم سازی قوی در هیئت مدیره و کارکنان؛
برقراری ارتباط بین اعضای هیئت مدیره؛
ایجاد رضایت بیشتر بین برنامه ریزان با یک چشم انداز مشترک؛ افزایش بهره وری ازطریق ارتقا کارایی و اثربخشی.
از دیگرسو، برنامه ریزی منابع انسانی فرایندی برای ارزیابی تقاضا، اندازه، ماهیت و عرضه منابع انسانی برای نیل به تقاضای موردنیاز است. از این رو، نخستین مرحله هر برنامه مدیریت امـــــور کارکنان و منابع انسانی، برنامه ریزی منابع انسانی است.(6)

همان طوری که گفته شد، برنامه ریزی استراتژیک فرایندی است که ضمن آن اهداف کلی، فعالیتها و ماموریتهای سازمان در درازمدت تعیین می شود. بنابراین، با بیان اهداف کلی سازمان، روشهای دستیابی به این اهداف، منابع، شرایط بازار، تغییرات تکنولوژیک، توسعه و بهبود محصول و سرمایه ازجمله مواردی هستند کــــــه در فرایند برنامه ریزی استراتژیک موردتوجه هستند. برنامه ریزی منابع انسانی به طور مستقیم با برنامه ریزی استراتژیک پیوند می یابد و مهمترین عامل و ابــــــزاری که اهداف و خط مشی های سازمانی را به اهـــداف و برنامه های منابع انســـانی ارتباط می دهد. برنامه ریزی استراتژیک منابع انسانی است. از این رو، بین برنامـــه ریزی منابع انسانی و برنامه ریزی استراتژیک ارتباط تنگاتنگی وجود دارد. (شکل 1)(7)
 
برنامه ریزی استراتژیک منابع انسانی
به عقیده دوچینزو و رابینز (DECENZO ROBBINS) برنامه ریزی منابع انسانی فرایندی است که به وسیله آن سازمان معین می کند که برای نیل به اهداف خود به چه تعداد کارمند، با چه تخصص و مهارتهایی برای چه مشاغلی و درچه زمانی نیاز دارد. (8) هدف برنامه ریزی منابع انسانی تجزیه و بررسی تعادل عرضه و تقاضا با یک روش ساختاریافته است، این امر با یک تصویر روشن و با حرکت سریع باتوجه به آینــده آغاز می گردد و مقصود آن است که زمینه های عملی را به عنوان یک نتیجه، تجزیه وتحلیل و تعیین کرد. در برنامه ریزی منابع انسانی ما به شناخت اعضا و مهارتهای موردنیاز برای انجام وظایف روزمره و تغییراتی که ممکن است ظرفیت کار را در آینده و حجم فعالیتهای تعهد شده را تغییر دهد نیازمندیم. این درک خوبی از استراتژی و برنامه های تجاری جزئی تر را دربرمی گیرد. بعد از آن ما باید وضعیت عرضه نیروی انسانی را ازنظر فهرست موجودی نیروی انسانی جاری و نیازهای آنان که چقدر باید تغییر کند را درنظر داشته باشیم. این موضوع بیانگر آن است که سازمانها نیاز به شناخت دقیق از اعضا و ویژگیها و روابط بین آنان با سازمان دارد.
برنامه ریزی استراتژیک منابع انسانی فرایندی است درجهت برقراری اهداف منابع انسانی و توسعه استراتژی های منابع انسانی برای نیل به اهداف، سیاستها ازطریق بسیج، توسعه و نگهداری منابع انسانی.(9) برنامه ریزی منابع انسانی با مفاهیم محیط و عملیات سازمان در ارتباط بوده و شامل عوامل داخلی وخارجی می شود. عوامل خارجی همچون فشارهای اقتصادی، تغییرات تکنولوژی، قوانین و مقررات، وضعیت سیاسی، بازار نیروی کار و آموزش، عوامل داخلی شامل هدف و مقاصد سازمان، فرهنگ، ساختار، منابع انسانی و ذینفعان می گردد. برنامه ریزی منابع انسانی ویژگیهای ممتاز و مشخصه ذیل را داراست:(10)
1 - آگاهی: مفروضات روشن و آشکار را در مبحث منابع انسانی به وجود آورد؛
2 - تحلیلی: بر یک سری قضاوتها و واقعیات متکی است؛
3 - هدف گرایی: ابزاری برای تصمیم گیری سازمانی درجهت نیل به اهداف
منابع انسانی بویژه مقاصد سازمانی است؛ 4 - چشم انداز به آینده: مسائل منابع انسانی را پیش بینی و آینده نگری می کند؛
5 - اجتماعی یا جمع گرایی: بر گروهها توجه دارد نه به افراد؛
6 - کمـــی : به افراد و اعضای سازمان توجه می کند.

چرا سازمانها برنامه ریزی منابع انسانی را به کار می برند. دلایلی وجود دارد که سازمانها خود را بــا برنامه ریزی منابع انسانی سازگار می سازند:
1 - خوش بینی نسبت به استفاده از منابع و یا انعطاف پذیری بیشتر منابع؛
2 - کسب و پرورش مهارتهایی که برای توسعه ضروری است؛
3 - تعیین و تبیین مشکلات بالقوه؛
4 - به حداقل رساندن فرصت تصمیم گیریهای نامناسب؛
5 - درک و شناخت از وضع موجود به منظور مواجه با آینده؛
6 - مفروضات چالشی و تفکر آزاد؛
7 - اتخاذ تصمیمات آشکار که می تواند چالشی گردد؛
8 - پیــوند میان برنامه های منابع انسانی با برنامه های کسب و کار؛
9 - هماهنگــــی و انسجام بین اعمال و تصمیم گیریهای سازمانی؛
10 - به دست آوردن کنترل واحدهای عملیاتی سازمان.
بــه طور خلاصه سازمانها به آسانی با برنامه ریزی منابع انسانی به طرق زیر سازگار می شوند:(11)
برنامه ریزی اساسی (بنیادی): این برنامه ریزی بیانگر آن است که برنامه ریزی منابع انسانی دارای اثر علمی است؛
برنامه ریزی فرایندی: این نوع برنامه ریزی نشانگر آن است که برنامه ریزی منابع انسانی دارای فرایند سودمندی برای سازمان است؛
برنامه ریزی سازمانی: این نوع برنامه ریزی، منابع و مسائل سازمانی را دربرمی گیرد.
برنامه ریزی منابع انسانی هدفهای مشخص و معینی را برای سازمانها دارد، واضح ترین آن تصمیم گیری درمورد منابع انسانی است که ازطریق تلاش درجهت منبع یابی منعطف تر با نوآوری، الگوهای ساعات کاری و اشکال قراردادهای کاری به وضوح مشاهده می شود. برخی از سازمانها به ارتقا تواناییهایشان ازطریق نقل و انتقال کارکنان (گردش شغلی) و بعضی دیگر به مهارتهای کمیاب و درحال پرورش آنها در دوره بلنــدمدت تمایل نشان می دهند. برنامه ریزی منابع انسانی به همه سازمانها اجازه می دهد روش تفکر و مفروضاتی را که براساس آنهـــا تصمیم گیری می شود را چالشی کنند. به علاوه، بدون تفکر آگاهانه این شالوده فکری شکل نخواهدگرفت. آن فرصتی را برای سازمانها فراهم می آورد که رؤسای آنها به طور معمولی مواردی که در آینــــده به آن توجه می کنند را درنظر داشته باشند.
فرایند برنامه ریزی منابع انسانی مزایایی را برای کلیه سازمانها بویژه برای سازمانهایی دارد که سازماندهی مجدد را انجام می دهند و آنهایی که قدرت تصمیم گیری را به واحدهای عملیاتی واگذار کرده اند. درحالی که شایستگی بایستی در فعالیتهای سازمان تبلور یابد ولی خوش بینی به منابع مزایایی برای سازمان به همراه دارد. برنامه ریزی منابع انسانی می تواند به عنوان یک سازوکار نفوذ و هماهنگی برای بخشهای مختلف تجاری و بازرگانی مدنظر قرارگیرد. ارتباطات و هماهنگی روشی است که ازطریق آن استراتژی تجاری شناسایی و با استراتژی منابع انسانی پیوند برقرار می کند. ما شاهد آن هستیم کــــه سازمانها نظامهای برنامه ریزی منابع انسانی را به دلایل فرایندی و سازمانی به کار می برند. یکی از مواردی که در اداره موفقیت آمیز منابع کاربرد دارد، دیدگاه سیستمی و منسجم نسبت بـــه سازمان و برنامه ریزی منابع انسانی است.

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

الگوهای برنامه ریزی استراتژیک منابع انسانی
الگوی برنامه ریزی استراتژیک منابع انسانی (13) مفهومی برای انسجام برنامه ریزی منابع انسانی و برنامه ریزی استراتژیک موسسه است. این الگو با هدف و مفهوم کاربردی که بیانگر استقلال سازمانی است طراحی و در سطوح متفاوت ساختارهای سازمانی می تواند به کار رود. اهداف و مقاصد الگو به شرح زیر است:
مشارکت در بهبود کلی عملکرد سازمانی؛
نمایش اهمیت نقش منابع انسانی. نقش فعال در توسعه منابع انسانی موردی
است که از بهبود مستمر سازمانها حمایت می کند؛ ایجاد ارتباط روشن بین فعالیتهای اصلی تجاری و منابع انسانی؛
طراحی ابزار برنامه ریزی که حمایتها و تسهیلات لازم بـــــرای توسعه منابع انسانی به وجود آورد.

عناصر الگوی برنامه ریزی استراتژیک منابع انسانی
1 - فرایند استراتژیک؛
2 - فرایند برنامه ریزی منابع انسانی؛
3 - برنامه ها؛
فرایند استراتژیک: این جزء شامل تبیین و تعریف موقعیت راهبردی، اهداف و تصمیمات استراتژیک و تجزیه وتحلیل محیط داخلی و خارجی است. برای تعریف وضعیت استراتژیک بایستی عوامل داخلی و خارجی تعیین و تبیین گردد. اجزاء و عناصر این فرایند عبارتند از: (شکل 2)
 
تصمیمات استراتژیک: ابزاری برای نیل به اهداف نهایی واستراتژیک موسسه هستند و اهداف استراتژیک همان مقاصد نهایی موسسه اند که کلیه عوامل درجهت دستیابی به آن فعالیت می کنند. مقصد استراتژیک به بخشهای وظیفه ای مختلف برای ارزیابی پیامدهای عملیاتی راهبردی کمک می کند.
تجزیه و تحلیل محیط داخلـــــی: شامل تجزیه وتحلیل خرد از مسائل درون سازمانی، تعداد کارکنان، مهارتهای شغلی، ساختار سازمان، توانایی عرضه، سهام، فروش وغیره، تعریف و تبیین وضعیت منابع انسانی و طراحی برنامه ها برای نیل به اهداف است، آنچه که در این مرحله حساس به نظر می رســــــد تجزیـــــه و تحلیل منابع انسانی موجود و پیش بینی منابع انسانی موردنیاز که عوامل متعددی از محیط درون سازمانی بر تصمیمات مدیریت اثر می گذارد ولی عمده ترین اثر را ویژگیهای کمی و کیفی منابع انسانی، فرهنگ سازمانی. ساختار سازمانی، مهارتهای شغلی هستند که باید مدنظر کارشناسان و مدیران برنامه ریزی منابع انسانی قرارگیرد.
تجزیه و تحلیل محیط خارجی: این جزء شامل شناسایی و تجزیه و تحلیل از عوامل کلیدی در محیط خارج موسسه که تاثیر بالقوه بر مدیریت منابع انسانی سازمان دارد. تغییراتی در تکنولوژی اقتصاد، بازار سرمایه، وضعیت آموزشی و فرهنگی، جمعیت شناسی و عوامل سیاسی صورت گیرد باید تاثیر آنها بر برنامه ها و خط مشی های منابع انسانی شناسایی گردد. و از این عوامل شرایط اقتصادی، اجتماعی و فرهنگی، عرضه نیروی کار و توسعه تکنولوژی اثر چشمگیرتر و قابل لمس تری را از سایر شرایط در منابع انسانی دارد چرا که زندگی روزمره کارکنان سازمانها و امرار معاش آنان و همچنین شناخت فرهنگ افراد داوطلب استخدام در سازمانها و گزینش افراد همسو با فرهنگ سازمانی، استراتژی موثری در مدیریت منابع انسانی است، و از طرفی بازار کار و عرضه نیروی انسانی یک پدیده ملموس بویژه درکشورهای صنعتی مطرح شده است که در هر مقطع زمانی نوع بازار کار برای هر حرفه و تخصص تاثیر خاصی دارد.
تجزیه و تحلیل قوتها و ضعفها، فرصتها و تهدیدات (SWOT):
 این تجزیه و تحلیل براین منطق استوار است که استراتژی اثربخش، قوتها و فرصتها را حداکثر می کند درعین حال که ضعفها و تهدیدات آن را به حـــــــــداقل می رساند.(14) فرصتها، موقعیتهای مطلوب در محیط موسسه است، عوامل کلیدی یکی از منابع فرصت تلقی می شود، شناخت بازار، تغییر در رقابت، تغییرات تکنولوژی و غیره برای موسسه فرصت به حساب می آید. تهدیدات بر وضعیتهای نامطلوب در محیط موسسه تاثیر عمده دارد. رشد بازار، قوانین و مقررات و غیره می تواند جزء تهدیدات باشد. قوتها، منابع، مهارتها یا مزایای دیگری نسبت به رقبا و نیازهای بازارهایی که موسسه در آنها کار می کند یا خواهدکرد. ضعفها، محدودیتها یا کمبودها در منابع، مهارتها و تواناییهایی است که مانع اثربخشی می شود، تجهیزات، منابع مالی، تواناییهای مدیریتی، بازاریابی می تواند منبع ضعف باشند.
برنامه ها: در ایـــــن فرایند، استراتژی ها و خط مشی های منابع انسانی مشخص می شوند که چگونه یک شرکت کارکنانش را برای نیل به اهداف سازمانی اداره کند و چارچوبهای توسعه منابع انسانی ازطرق متعدد (آموزش، گردش شغلی، ارتقا و...) موردبررسی قرار گیرد و پیامدهای اقتصادی برنامه های شرکت و بهبود تولید و بازاریابی معین و اعلام می گردد.
فرایند برنامه ریزی منابع انسانی: این جزء شامل تجزیه وتحلیل خرد و کلان از متغیرهای موجود منابع انسانی، جو و فرهنگ سازمانی، ساختار سازمانی، کیفیت زندگی کاری، مهارتهای شغلی، سطح شایستگی، الگوبرداری از بهترینها، ارزیابی پیامدهای منابع انسانی، بررسی پیامدهای توسعه منابع انسانی، ابزارهای اندازه گیری توسعه منابع انسانی و اعمال اصلاحی است.
تصویربرداری از وضع موجود و تجزیه و تحلیل از وضع موجود دو وظیفه اصلی هستند که باید تصویری مناسب و شایسته از منابع انسانی را نشان دهند. تصویربرداری از وضع موجود وظایف کارکنان براساس شرایط احراز و شرح شغل مشخص و سطح شایستگی آنان نیز ازطریق شرایط احراز و مهارتها و صلاحیتی معین می گردد که از خود بروز می دهنـــــــــد. آنچه که در وظیفه تجزیه و تحلیل مدنظر است الگوبرداری از روی بهترینها است که موجب بهبود عملکرد ازطریق شناسایی و به کارگیری بهترین مهارتهایی می گردد که در زمینه توسعه منابع انسانی وجود دارد. هدف از الگوبرداری، یافتن نمونه هایی از عملکرد عالی و آگاهی یافتن از فرایندهای برنامه ریزی منابع انسانی است که سبب بروز عملکرد موردنظر می شود. تاکید فرایند برنامه ریزی منابع انسانی بر بررسی و مطالعه پیامدهای توسعه منابع انسانی، طراحی فرایندها، ارزیابی پیامدهای منابع انسانی، استراتژی ها و برنامه هاست که ازطریق بخشهای وظیفه ای تثبیت می گردد. براساس ارزیابی صورت گرفته از منابع انسانی، تصمیم نهایی درمـــــورد برنامه های موسسه اتخاذ می شود. به هرحال، گاهی سازگاری مقصد استراتژی و پیامدهای ارزیابی قبل از تصمیم نهایــی مفید است، که در برنامه موسسه اتفاق می افتد. ستاده تصمیمات استراتژیک به عنوان چارچوبی برای توسعه برنامه ها به کار می رود. بخش منابع انسانی یک فرایند مدیریت و نقش مشاوره برای اطمینان از اجرای برنامه های منابع انسانی است. بخش منابع انسانی به طراحی فرایندها، اجرای چارچوبهای زمانی، مسئولیتهــــــا و بهبود روش شناسی کاری می پردازد.
این بخش نقش فعالی در برنامه های توسعه منابع انسانی دارد و به صورت منسجمی باعث توسعه تجاری می شود. پیامدهای همه طرحها و برنامه ها در واژه منابع انسانی است و وقتی به اتمام برسد به عنوان الگوی منابع انسانی عمل می کند. بعد از تبیین الگو، تفاوتها تجزیه و تحلیل و بـــررسی می گردد، مقایسه نتایج تجزیه و تحلیل منابع انسانی با مرحله پیامدهای توسعه منابع انسانی است. درحال حاضر، ما به مسایلی چون: اشتباه یا خطا کجاست؟ شما چگونه مرتکب اشتباه می شوید؟ ابــــزار اندازه گیری شکافها چیست؟ برای منابع انسانی چه نــوع کاری انجام شده است؟ کمتر توجه می کنیم.
در تجزیه و تحلیل الگوی حاضر و ابزارهای اندازه گیری آن، میزان نیاز به نیروی انسانی در برنامه ریزی منابع انسانی را مطرح می کند؛ برنامه باید قبل از اجرا به تصویب مدیریت برسد. به کارگیری ابزار اندازه گیری باید با همکاری مدیریت و باتوجه به تغییر وظایف منــــابع انسانی اجرا شود. اجرای برنامه ریزی، تعیین عملکرد و شاخصهای فعالیت وعوامل موفقیت در این مرحله موضوعهای مهمی هستند. آخرین جزء الگو شامل نظارت بر پیشرفتها و اعمال اصلاحی است. برنامه اجرایی باید به طور مستمر مطابق با طرح درجهت نیل به اعمال اصلاحی به کار روند تا جواب مناسبی برای سازمان به ارمغان آورد.

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

منابع و ماخذ:
1 - پاتریک. ج.بیلو؛ راهنمای اجرایی برنامه ریزی استراتژیک؛ ترجمه:
منصور شریفی کلویی، نشر آردین، تهران، 1376، ص 17. 2 - جیمز دبلیو واکر؛ برنامه ریزی استراتژیک منابع انسانی؛ ترجمه:
خدابخش داشگرزاده، انتشارات موسسه نشر فرهنگی زند، چاپ اول، 1375، ص 5. 3 - منوریان، عباس؛ فرایند برنامه ریزی استراتژیک؛ فصلنامه مدیریت
دولتی، انتشارات مرکز آموزش مدیریت دولتی، شماره 10 پاییز 1369، ص 67.
4 - CARTER MCNAMARD “STRATEGIC PLANNING (IN NONPROFIT OR FOR PROFIT
ORGANIZATIONS) INTERNET” P.4. 5 - M.G.SINGER “HUMAN RESOURCE MANAGEMENT” PWS-KENT CO.1990” P.100.
6 - MR. MOSES M. SIMELANE “THE HUMAN RESOURCE PLANNING NATIONAL AND
REGIONAL APPROACH BENCHMARKING AND RE-ENGINEERING “2000” P.1. 7 - MR. MOSES & M SINELANE” OP.CIT. P.5.
8 - سعادت، اسفندیار؛ مدیریت منابع انسانی؛ انتشارات سمت، چاپ اول،
1375، ص 57. 9 - زارعی متین، حسن، برنامه ریزی استراتژیک برای منابع استراتژیک؛
فصلنامه دانش مدیریت، انتشارات دانشگاه تهران، شماره 17، تابستان 71، ص 66.
10 - MR. MOSES M SINELANE “OP.CIT. P.2.
11 - IBID. P.3.
12 - IBID. P.4.
13 - IBID. P.5.
14 - پیرس و رابینسون؛ برنامه ریزی و مدیریت استراتژیک؛ ترجمه: سهراب خلیلی شورینی، انتشارات یادواره کتاب، چاپ دوم، 1380، ص 307.

 

ارسال شده توسط احمد محمدی | 10 12, 2013 | بازدید‌ها (881)
رویکردی به ساخت و پیاده‌سازی سیستم هوش تجاری
 

مولف/مترجم: ترجمه: مهدی محمودی
موضوع: مدیریت بازرگانی
سال انتشار(میلادی): 2009
وضعیت: تمام متن
منبع: Olszak, Celina. M, and Eweio Ziemba, Approach to Building and Implementing Business Intelligence System, Inter disciplinary Journal of Information, Knowledge and Management, Volume 2,2007

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

مقدمه
حقیقت اجتماعی - اقتصادی سازمانهای معاصر، آنها را ملزم به جستجوی ابزارهایی برای تسهیل فرایند کسب اثربخش داده ها، پردازش و تحلیل وسیع آنها از منابع مختلف و پراکنده کرده است تا براساس آن پایه ای را برای کشف دانش جدید بنا نهند.
برای سالیان متمادی، سیستم‌های اطلاعات مدیریت (MIS)، سازمانها را در انجام وظایف مختلفشان مورد حمایت قرار داده اند؛ هر چند ، امروزه به سیستم‌های اطلاعاتی ، توجه کمی می شود. تاکنون سیستم‌های اطلاعات مدیریت موجود مانند: (MIS، DSS،ES ،EIS ) نتوانسته است انتظارات تصمیم گیرندگان سازمانی را، به ویژه در موارد زیر برآورده سازد :
_ گرفتن تصمیمات در فوریتهای زمانی،
_ صد کردن رقابت،
_ به دست آوردن اطلاعات مختلف با دیدگاه‌های متفاوت،
_ برای انجام تحلیلهای مداوم روی داده‌های بیشمار و ملاحظه متغیرهای مختلف مربوط به عملکرد سازمان .
به طور ساده، سیستم‌های اطلاعات مدیریت که به آنها اشاره شد، قادر به ایجاد یکپارچگی میان داده های مختلف، پراکنده و ناهمگن نبوده اند و همچنین آنها نتوانسته‌اند داده ها را با توجه به زمینه‌های وسیع موجود، به گونه‌ای اثربخش تفسیر کنند و قادر به شناسایی مناسب وابستگی‌های موجود میان داده های جدید نبوده اند.
دلایل موجود حکایت از وجود تکنیکهای نامناسب برای دستیابی، تحلیل، کشف و تفسیر
داده ها دارد ( شکل 1). برای اینکه سازمانها قادر به واکنش سریع در برابر تغییرات بازار باشند، نیاز به سیستم‌های اطلاعات مدیریتی دارند که بتوانند از سازمان و محیط آن تحلیلهای علت و معلولی مختلف را انجام دهند.
سیستمهای هوش تجاری ابزاری را فراهم می کنند که براساس آن نیازهای اطلاعاتی سازمان به شکل مناسبی پاسخ داده شود. وظایف اصلی که توسط سیستمهای هوش تجاری مورد توجه قرار می گیرد، شامل : شناسایی هوشمندانه داده‌های اطلاعاتی، تجمیع آنها و تحلیل چند بعدی داده هایی است که از منابع اطلاعاتی مختلف به دست آمده است. سیستم‌های هوش تجاری، داده های مربوط به سیستمهای اطلاعاتی درون سازمانی را با داده هایی که از محیط سازمان به دست می آید ، تجمیع می کنند . این داده های محیطی می تواند شامل آمارها ، پایگاه‌های اطلاعاتی مربوط به مراکز سرمایه گذاری و مالی و پایگاه های داده متفرقه باشند‌. چنین سیستم‌هایی به عنوان رابط هاو واسط گرهایی هستند که برای کسب اطلاعات روزآمد ، قابل اطمینان و کافی، نسبت به فعالیت های مختلف شرکت عمل می‌کنند.
نتایج حاصل از پژوهشها نشان می‌دهند که سیستم‌های هوش تجاری مورد بحث در اصلاح و شفاف سازی جریانهای اطلاعاتی و مدیریت دانش مشارکت کرده، سازمانها را برای موارد زیر توانمند می سازند :
_ استمرار سوددهی از فروش محصولات،
_ تحلیل هزینه ها ،
_ نظارت بر محیط اطراف،
_ کشف کلاهبرداریها و قانون شکنی‌ها.
 


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

روش شناسی ساخت سیستم‌های هوش تجاری
ساخت واجرای سیستم های هوش تجاری، مستلزم سازمانهایی است که فرهنگ کار در آنها با اطلاعات و فناوریهای آن هماهنگی داشته باشد. در این رابطه به موارد زیر می‌توان اشاره کرد:
- تحقیق مداوم و مستمر درباره نیازهای اطلاعاتی سازمان (نیازهای فعلی و آتی).
- همکاری توأم با اعتماد بهره‌گیران سازمانی مانند: (تصمیم‌گیرندگان و کارکنان عملیاتی سازمان) با بخش‌های IT و مراکز مدیریت دانش.
- به اشتراک گذاری اطلاعات. و:
- توانایی در انجام فراتحلیل‌ها و استفاده از آنها برای مدیریت مناسب.
برای پیشنهاد متدولوژی ساخت و اجرای سیستم‌های هوش تجاری، نویسندگان این مقاله، از شیوه‌های تجاری تجربه شده به وسیله شرکت‌های موفق در زمینه ساخت سیستم‌های هوش تجاری بهره گرفته‌اند. هر مدل جامعی که برای این منظور پیشنهاد شود، ممکن است که مجموعه‌ای از دستورکارها و انواعی از الگوها را به سازمانها معرفی کند. مدل مورد نظر، توجه ویژه‌ای به نقش بهره‌گیران نهایی شرکت دارد که در کل چرخه زندگی سیستم‌های هوش تجاری، به طور موثری آن را بکار می‌گیرند. درک درست قدرت تأثیر بهره گیران نهایی شرکت بر روی عملکرد سیستم هوش تجاری، به ما اجازه می‌دهد که دو مرحله مهم در رویکرد ساخت و اجرای سیستم‌های مورد بحث را پیشنهاد کنیم:
_ ایجاد سیستم هوش تجاری،
_ به کارگیری سیستم هوش تجاری.
خلق سیستم هوش تجاری بیشترین زمان را صرف خودش کرده و این مرحله مستلزم بهره‌گیری از بیشترین منابع مالی و انسانی شرکت در فرایند کلی چرخه زندگی سیستم هوش تجاری است. ایجاد سیستم هوش تجاری دربرگیرنده مراحل بیشماری ، به ویژه مراحل زیراست:
- تعیین اینکه چه کسی عهده‌دار اجرای سیستم است. برای مثال تعیین استراتژی‌های توسعه سیستم هوش تجاری،
- شناسایی و آماده‌سازی منبع داده،
- انتخاب ابزارهای سیستم هوش تجاری،
- طراحی و پیاده سازی سیستم هوش تجاری،
- کشف و جستجوی نیازهای اطلاعاتی جدید و کاربردهای دیگر مربوط به سیستم هوش تجاری.
مرحله به کارگیری سیستم هوش تجاری، به طور برجسته وابسته به درخواست‌های بهره گیران نهایی شرکت است. بیشترین نقش در این مرحله، مربوط به فعالیت‌های ترویج و توسعه سیستم های هوش تجاری و تحلیل داده‌ها می‌شود. ممکن است که این مرحله در چندین مرحله مختلف ، براساس تشخیص بهره‌گیران نهایی شرکت و بر اساس نیازها و وظایف آنها تقسیم شود. اساساً این مراحل شامل موارد ذیل است:
_ تحلیلهای منطقی که به شناسایی شرکای زنجیره تأمین کمک می‌کند،
_ دستیابی، بازبینی و تحلیل واقعیت‌ها،
_ توسعه گزینه‌های مختلف تصمیم‌گیری،
_ تقسیم و تشریک مساعی .
_ تغییر در اثر عملکرد شرکت .

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

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

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

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

 
ارسال شده توسط احمد محمدی | 10 12, 2013 | بازدید‌ها (2060)
 مرروی بر تجربیات پیاده‎سازی سیستم‌های برنامه‎ریزی منابع سازمان در ایران تعریف ERP و مرروی بر تجربیات پیاده‎سازی سیستم‌های برنامه‎ریزی منابع سازمان در ایران
 

چکیده :

مدتی است واژه هایی نظیر ERP, MIS …   اذهان شرکت های دولتی و خصوصی را به خود مشغول ساخته و برخی از آنها فعالیت های خود را برای پیاده سازی این سیستم ها آغاز نموده اند. اما پیش از آغاز هر حرکت و تلاشی می بایست این مفاهیم در بستر کاری کشور به دقت مورد مطالعه قرار گرفته و شناخته شوند تا سیستمی مطابق با انتظارات و فرهنگ اداری کشور پیاده شده و بهره وری از سرمایه صرف شده حاصل گردد . بدین ترتیب در این مقاله به تعریف ERP و عوامل موفقیت ، دلایل شکست، مزایا ، معایب و...آن پرداخته است.

 

مقدمه

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

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

 

طرح مساله

قبل از تعریف ERP و شفاف تر شدن بحث، بهتر است ابتدا منابع یک شرکت یا سازمان را بشناسیم.

به‌طور کلی منابع شرکت را به چهار منبع اساسی تقسیم می کنند.

 

1.منابع انسانی

2. تجهیزات و امکانات (Material)

3. ماشین‌‌آلات (Machine)

4. پول (Money)

در این میان باارزش ترین آنها منابع انسانی (MAN) است که دانش و مهارتهای افراد را در برمی‌گیرد .

 

 

 

 دانش خود به دو نوع تقسیم می‌شود.

 

  • .دانش واضح و قابل لمس (Explicit Knowledge)، مثل سخنرانی ها، کتب و مقالات.
  • دانش غیر قابل لمس(Tacit Knowledge) ، یعنی دانشی که در حافظه انسان نهفته است.

 

این دانش باید از حافظه دریافت شود و در نهایت در قالب نوآوری و خلاقیت وارد سازوکارهای اداری و سازمانی گردد.

ضرورت برنامه‌ریزی منابع چیست؟
اگر برنامه ریزی ضروری است، ERP نیز ضرورت خواهد داشت.
ما باتوجه به شرایط جهانی و به دلیل گسترش فناوری اطلاعات و ارتباطات نیاز داریم خودمان را به بهترین و پیشرفته‌ترین تکنیک‌ها، مدل‌ها و روشهای مدیریتی و برنامه ریزی تجهیز کنیم تا در نهایت جامعه به رفاه مادی و معنوی برسد و در جهان الگو باشد.

انتخابERP مناسب

 

انتخابERP  مناسب

برای انتخاب ERP مناسب  باید فاکتورهای زیر مدنظر قرار گیرد:

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

 

در این صورت ERP مناسب انتخاب یا تهیه شده است و می‌توان به افزایش نرخ بازگشت سرمایه امیدوار بود.

 

تعاریف مختلف از ERP

 

 

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

 

 

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

 

نقطه قوت راه حل‌های ERP

 

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

 

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

 

مجری بایستی خاک نرم‌افزار را در ایران خورده باشد!!!

 

چالش‌های برنامه‌ریزی منابع در ERP

  • هنوز نیازهای مدیریتی شفاف نشده است.
  • هنوز رقابت جدی بر کسب و کارها حاکم نیست.
  • دانش برنامه‌ریزی در کشور ضعیف است.
  • محیط بیرونی کسب و کار پذیرای برنامه‌ریزی نیست.

 

چالش‌های نرم‌افزاری ERP

  • معماری سازمانی (وضع مطلوب یا مقدور)
  • تفکیک مراحل تولید از تطبیق و اجراء
  • امنیت اطلاعات
  • سیستم جامع، MIS، ERP، یا KMS
  • Work Flow
  • محیط اجراء

 

شرط موفقیت (ERP ایرانی یا ERP خارجی)

 

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

یک مشاور با تجربه می‌تواند در کاهش هزینه‌ها، انتخاب مناسب، و در اجرای موفقیت‌آمیز پروژه ERP نقش تعیین‌کننده‌ای داشته باشد.

       اگر بهترینERP  انتخاب شود اما پیاده‌سازی کننده مناسبی برای آن انتخاب نشود، ممکن است این پروژه به شکست منتهی شود.

       سازمان های مختلفی با شرکت‌های خارجی وارد بحث و مذاکره شده اند تا ERPهای آنها را بومی و متناسب‌سازی کرده و یا دست کم، از ماژول های تولیدات آنها استفاده کنند.در نتیجه این تحقیقات مشخص شد که بومی‌سازی نرم افزارهای ERP خارجی در ایران ناممکن است.

موفقیت به معنی استقرار تمام موارد و مؤلفه‌های سازمان از یک نرم‌افزار ERP تاکنون اتفاق نیفتاده است.

 

بدون درگیری مدیران سازمان در پیاده‌سازی ERP، که یک تغییر فرهنگ بنیادی در سازمان است، محال است، که استقرار ERP موفق شود.

 

عوامل مؤثر در اجرای اثربخش پروژه‌هایERP

1- کارفرما

2- شرکت مجری

3- تیم ناظر و مشاورین

4- کاربران سیستم

 

کارفرما

 

1- نقش مدیر قهرمان (Champion)

2- جایگاه و نقش مدیر پروژه ERP از سوی کارفرما

3- روشن شدن حد تطبیق (بهبود یا تحول)

4- صبر و حوصله (قرن بیست و یکم قرن سرعت است، اما نه سرعت در تغییر مسئولین)

5- آگاهی کامل از اینکه قرار است به کجا برویم

6-عدم ناامیدی در کنار عدم ذوق‌زدگی

7- توجه به سطح و درجه آمادگی سازمان کارفرما و درگیر نکردن مجری برای ارتقاء سطح آمادگی کارفرما

 

شرکت مجری

 

1- نقش مدیر پروژه

2- داشتن تجربه در پیاده سازی و استقرار در ایران

3- داشتن تعداد مناسب مشاور، تکنولوگ و ... در کنار تیم نرم‌افزاری

4- جداسازی محیط تولید از محیط تطبیق

5- قالب شدن تفکر ERP بر تفکر صرف نرم‌افزاری

(تفکر فرایندی، جذب دانش به روش‌ها، تفکر برنامه‌ریزی

 

تیم ناظر و مشاورین

 

1- تفکیک وظایف ناظر از وظایف مشاورین کافرما

2- کمک‌گیری از مشاورین متخصص برای مهیاسازی شرایط جذب ERP

3- کمک‌گیری از انواع مشاوران آموزشی برای ارتقاء میزان آمادگی کارفرما

4- کمک‌گیری از انواع مشاوران مدیریتی و انجام طرح های بهبود

5- مدیریت کامل پروژه با تکیه روش‌های استاندارد (BMBOK) توسط ناظر پروژه

6- ایجاد هماهنگی و یکپارچگی فکری بین تیم‌های کارفرما، مجری، ناظر و مشاورین

 

کاربران سیستم

 

1- ضرورت بسترسازی فرهنگی

2- برنامه‌ریزی آموزشی گسترده و قوی در زمینه‌های خدمات مدیریتی، انفورماتیکی و انگیزشی

3- برنامه‌ریزی آموزشی تخصصی موضوعی (مثال: آموزشABC برای صاحبان فرایندهای مرتبط با فرایندهای مالی)

4- تعیین درست کاربران اصلی (Power User) و تعیین حداقل یک قائم‌مقام تمام وقت برای هر یک از آنان

5- آماده سازی کاربران سیستم‌ها و مهیاسازی محیط کار برای حذف مقاومت در مقابل تغییر

 

 

جمع بندی

شرط موفقیت ERP در ایران یکپارچگی در تفکر شرکت‌های نرم‌افزاری، شرکت‌های خدمات مدیریتی، مدیران ارشد کسب و کارها، مؤسسات فرهنگی و مشاوران ارشد این رشته است.

نیاز مندیهای استقرار ERP

 

 

•          تصمیم گیری هییت مدیره

•          تعریف پروژه نمونه

•          ایجاد ساختار مناسب برای اجرای پروژه

•          انتخاب ERP مناسب

•          مهندسی مجدد فرآیند ها به میزان تشخیص و صلاحدید سازمان

•          ایجاد بستر مخابراتی لازم

•          بومی کردن ERP

•          بررسی نتایج

•          تعمیم

 

هزینه ERP

  1. 60% پیاده سازی
  2. 20% هزینه ایجاد زیر ساختهای لازم
  3. 20% هزینه نرم افزار

 

هزینه های پنهان ERP

  1. آموزش
  2. آزمایش و یکپارچه سازی
  3. سفارشی سازی
  4. تبدیل داده ها
  5. مشاوره
  6. جایگزینی بهترین ها

 

 

 

عوامل موفقیت ERP

 

•          چشم اندازی را ایجاد کنید

•          برگشت سرمایه بکاررفته را درک کنید

•          تلاشهایتان را اولویت بندی کنید.

•          لازم و ملزومات یسستم را بشناسید

•          فرایند ها را یکپارچه کنید

•          اجرا را کنترل کنید

•          تغییرات را کنترل کنید

 

دلایل شکست پروژه های ERP

  1. مقاوت افراد برای استفاده از نرم افزار
  2. تخمین نادرست سطوح منابع مورد نیاز جهت اجرای سیستم
  3. نگرش نزدیک بینانه به پروژه

 

مزایای ERP

•          نسبت هزینه های استقراربه منافع ایجاد شده در سازمان 1 به 10 است

•          افزایش بازدهی سازمان در زمان کوتاه

•          کنترل بهتر و موثرتر بودجه در نتیجه بهبود برنامه ریزی و فرآیند های ما لی

•          فرصتی برای مهندسی مجدد سازمان

•          ساده سازی و استاندارد شدن روشها

•          رضایت مشتریان

 

معایب ERP

•          سرمایه گذاری اولیه نسبتا زیاد

•          ریسک بالا

•          قسمتهای زیادی از سازمان درگیر می شوند

•          برای ERP منابع زیادی مورد نیاز است

•          زمان نسبتا طولانی برای پیاده سازی در سازمان های بزرگ مورد نیاز است

 

 تجربه جهانی و تجربه در ایران در مورد به‌کارگیری ERP چگونه است؟

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

 

نیاز مندیهای استقرار ERP

 

 

•          تصمیم گیری هییت مدیره

•          تعریف پروژه نمونه

•          ایجاد ساختار مناسب برای اجرای پروژه

•          انتخاب ERP مناسب

•          مهندسی مجدد فرآیند ها به میزان تشخیص و صلاحدید سازمان

•          ایجاد بستر مخابراتی لازم

•          بومی کردن ERP

•          بررسی نتایج

•          تعمیم

 

هزینه ERP

  1. 60% پیاده سازی
  2. 20% هزینه ایجاد زیر ساختهای لازم
  3. 20% هزینه نرم افزار

 

هزینه های پنهان ERP

  1. آموزش
  2. آزمایش و یکپارچه سازی
  3. سفارشی سازی
  4. تبدیل داده ها
  5. مشاوره
  6. جایگزینی بهترین ها

 

 

 

عوامل موفقیت ERP

 

•          چشم اندازی را ایجاد کنید

•          برگشت سرمایه بکاررفته را درک کنید

•          تلاشهایتان را اولویت بندی کنید.

•          لازم و ملزومات یسستم را بشناسید

•          فرایند ها را یکپارچه کنید

•          اجرا را کنترل کنید

•          تغییرات را کنترل کنید

 

دلایل شکست پروژه های ERP

  1. مقاوت افراد برای استفاده از نرم افزار
  2. تخمین نادرست سطوح منابع مورد نیاز جهت اجرای سیستم
  3. نگرش نزدیک بینانه به پروژه

 

مزایای ERP

•          نسبت هزینه های استقراربه منافع ایجاد شده در سازمان 1 به 10 است

•          افزایش بازدهی سازمان در زمان کوتاه

•          کنترل بهتر و موثرتر بودجه در نتیجه بهبود برنامه ریزی و فرآیند های ما لی

•          فرصتی برای مهندسی مجدد سازمان

•          ساده سازی و استاندارد شدن روشها

•          رضایت مشتریان

 

معایب ERP

•          سرمایه گذاری اولیه نسبتا زیاد

•          ریسک بالا

•          قسمتهای زیادی از سازمان درگیر می شوند

•          برای ERP منابع زیادی مورد نیاز است

•          زمان نسبتا طولانی برای پیاده سازی در سازمان های بزرگ مورد نیاز است

 

 تجربه جهانی و تجربه در ایران در مورد به‌کارگیری ERP چگونه است؟

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

 
ارسال شده توسط احمد محمدی | 9 12, 2013 | بازدید‌ها (1350)
Open Source ERP -Dolibarr(ERP\CRM)
مستندات کاربر
استفاده از (ماژول)
ویژگی هایDolibarr ماژول بندی شده است. برایآگاهی از چگونگی استفاده از Dolibarr باید منوها و عملکرد ماژول های فعال شده را بدانید.انواع مختلفی از ماژول وجود دارد:
•    ماژول های اصلی
•    فایرفاکس
•    ماژول های رابط
•    پلاگین ها
ماژول های اصلی آنهایی هستند که برای Dolibarr و نرم افزار ضروری عملیاتی هستند.
فایرفاکس ها موجب اضافه شدنافزودنیهای مفید به ویژگی های  Dolibarr که  ضروری نیستند، به عنوان مثال، مدیریت ورود به سیستم، اگر Dolibarr در یک سرور اختصاصی نصب شده باشد،مفید است.
ماژول های رابط ماژول های اختیاری فراهم کردن ارتباط کاربر با ویژگی های اضافی هستند، به عنوان مثال برای دسترسی به Dolibarr از محیط های دیگر از جمله سایت های خارجی، FTP، سرور های پی پال، و غیره می باشد.
در نهایت، پلاگین در ماژول های استاندارد در Dolibarr گنجانده نشده است.آنها را می توان از طریق بسیاری از وسایل مختلف از جمله دانلود از بازار برای ماژول های خارجی www.dolistore.comدانلودنمود.
اما در ابتدا به طور کلیمعرفی و یا استفاده از مد را ببینید:
Dolibarr چیست؟
Dolibarr ERP / CRMنرم افزار ماژولار (فعال شدنفقط توسط توابع مورد نظر) مدیریت SOHO / SME، خود کار، کارآفرینان و یا انجمن است.این پروژه  opensource که در یک وب سرور اجرا می شوند می توانند از هر نقطه با اتصال به اینترنت استفاده شود.
ویژگی های Dolibarr  :
•    نصب ساده
•    استفاده آسان(توابع ماژولار منوها و ...)
•    توسعه آسان (برای هر توسعه دهنده عملیاتی بدون هیچ دانش خاصی غیر از( PHP .
این نسخههای نصبی Dolibarr تنها به نام:
•    DoliWamp، یک برنامه ی خود نصب exe برای کاربران ویندوز.
•    DoliMamp، یک برنامه ی خودنصب exe برای کاربران سیستم عامل Mac OS X
•    DoliDeb، نصب برای کاربران لینوکس / اوبونتو.
•    DoliRpm، نصب برای لینوکس / فدورا / لینوکس / مندریوا / Mageia کاربران برRed .
ماژول های اصلی (همه اختیاری)
•    دایرکتوری از چشم انداز و / یا مشتریان و / یا تامین کنندگان
•    دایرکتوری از تماس / آدرس
•    کاتالوگ محصولات و خدمات
•    مدیریت انبار
•    مدیریت حساب های بانکی
•    مدیریت سفارش
•    مدیریت طرح کسب و کار
•    خدمات مدیریت قرارداد
•    مدیریت مشتریان و تامین کننده فاکتورها
•    مدیریت پرداخت
•    مدیریت نقل و انتقالات بانکی
•    مدیریت حمل و نقل
•    مدیریت اعضای انجمن
•    مدیریت مرخصی کارمند
•    تقویم به اشتراک گذاشته شده
•    ثبت نامPOSنقدی
•    انجام بررسی
•    ایمیل توده به مشتریان، کاربران آینده نگر Dolibarr
•    حاشیه مانیتورینگ
•    کمک های برداشت
•    بوک مارک ها
•    گزارش و آمار
•    PDF صادرات تمامی اقلام (فاکتورها، پیشنهادات، سفارشات، حمل و نقل، و غیره ... )
•    واردات و صادرات( CSVو یا اکسل).
•    مدیریت مالیات بر ارزش افزوده(NPR غیر قابل بازیابی درک - برای کاربران فرانسه DOM-TOM  )
•    اتصال LDAP
•    بسیاری از ویژگی های دیگر از ماژول های رسمی یا غیر رسمی (AWStats، بیت تورنت، Gravatar ، گوگل، ...  )
•    تمدید توسط بسیاری از ماژول های دیگر از محل بازار Dolistore
دیگر ویژگی های متفرقه
•    نرم افزار چند کاربره با سطوح مختلف از مجوز ها توسط ماژول.
•    چند مدیران منوها (امکان افتراق منوها برای کاربران داخلی backoffice و یا دفتر جلو برای مشتریان یا تامین کنندگان)
•    استفاده آسان از نرم افزار.
•    قابلیت تنظیم آسان (فعال سازی حساب کاربری ماژول های مورد نظر، زمینه های سفارشی، انتخاب موضوع، ...  ).
•    با PHP 5.2.1 +و MySQL 4.1 +یا PostgreSQL 8.1.4 +نسخهها کار میکند.
•    سازگاری با  PHP، MySQL یا PostgreSQL
مشکلاتDolibarr
این ویژگی هادر آخرین نسخه در دسترس نیست :
•    فاقد حسابداری هزینه (فقط مدیریت پول نقد).
•    مدیریت یک ارز در یک بار (تک ارز).
•    مدیریت یک شرکت / پایه (تک شرکت). اگر می خواهید مدیریت چندین شرکت و یا پایه داشته باشید، باید چند بار نرم افزار را (در همان سرور یا سرور دیگر) نصب کنید. راه حل دیگر گسترش Dolibarr با افزونه ماژول MultiCompanyاست که مدیریت چندین شرکت در یک نمونه را اجازه می دهد(Dolibarr یک پایگاه داده، اما با انزوا منطقی از دادهها).
•    Dolibarr شاملماژولحقوق و دستمزد نیست.
•    Dolibarr اخبار ندارد.
•    Dolibarr هیچ پست الکترونیکی را شامل نمی شود.
پیش نیازها
OS
•    از همهسیستم عامل هایشناخته شده پشتیبانی می شوند.
به عنوان مثال: لینوکس، BSD، ویندوز، MacOS، AIX ...
پایگاه داده ها
•    MySQL(4.1 +)
•    PostgreSQL (8.1.4 +)
•    MSSQL
•    حجم مورد نیاز 1MB  بازاء هر 100 مشتریان / تامین کنندگان است.
PHP
•    نسخه 5.2.1 +
•    پشتیبانی از جلسه باید (این به طور پیش فرض در PHP است) فعال باشد
•    این نسخهها صرف نظر از register_globals برای تنظیمکار میکند
•    با این نسخهها بدون در نظر گرفتن magick_quotes کار تنظیم را انجام می دهد
•    پارامتر safe_modeفعال باشد
•    پیکربندی PHP باید به اندازه حافظه در هر جلسه حداقل 64 (پارامتر memory_limit را) باشد.
فضای هارد دیسک
•    فایل های برنامه کمتر از 80MB.
با این حال، بهتر است برای فایل های  آپلود شده و یا برای ذخیره فایل های PDF تولید شده و یا ODTفضای بیشتری داشته باشید .حجم به تعداد فایل های پیوست بستگی دارد.
قدرت CPU
هر سرور به اندازه کافی برای اجرای Dolibarr با کمتر از 50 کاربر، حتی قدیمی 386  پاسخگواست.برای کاربرانبیشتر از  50، حداقل سرعتسرور 1GHz توصیه می شود.
راه اندازی نرم افزار
برای شروع، راه اندازی برنامه: با کلیک کردن بر روی آیکون نصب شده بر روی دسکتاپ شما توسط بسته های نصب، و یا با تایپ کردن URL در مرورگر خود(http:// / localhost/ dolibarr/برای نصب و راه اندازی محلی اما در مورد نصب دستی متفاوت است و به تنظیمات وب سرور شما بستگی دارد).
زمانی که این برنامه را راه اندازی نمودید، پنجره ورود به ، اطلاعات زیر را درخواست می نماید:
•    ورود:این حساب کاربری است.اگر برای اولین استفاده است، حساب کاربری انتخاب شده در مرحله اول از نصب و راه اندازی حساب کاربری  شما خواهد بود (به عنوان مثال مدیر).
•    رمز عبور:این رمز عبور کاربر است.اگر این اولین استفاده است، رمز عبور انتخاب شده در مرحله اول از نصب و راه اندازیرمز عبور خواهد بود (به عنوان مثال changeme)

خانه
پس از ورود، شما به صفحه اصلی می رسید.این شامل منو (بالا و سمت) و چند مورددیگر است:
استفاده از منوها
برای این کار، به صفحه Premiers_paramétragesمی رویم .
برای استفاده از یک ماژول در منوی بر روی ماژول کلیک کنید.
به عنوان مثال، لیست محصولات در بورس،ماژول های تابع ارائه شده توسط محصولاتو سهام، با کلیک بر روی منو / محصولات.

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

فهرست ماژول ها
«فهرست ماژول ها"
•    ماژول کاربران
•    ماژول دستور کار
•    ماژول بانک ها
•    ماژول ثبت نام
•    ماژول دسته بندی ها
•    ClickToDial ماژول
•    ماژول کدهای نوار
•     ماژول مشتریان سفارشات
•    ماژول حسابداری
•    ماژول قرارداد
•    ماژول کمک
•    ماژول صادرات
•    ماژول حمل و نقل
•    ماژول فاکتورها مشتریان
•    مداخلات IR
•    ماژول تولید کنندگان سفارشات
•    ماژول تولید کنندگان فاکتورها
•    FTP ماژول
•    ماژول واردات
•    ماژول LDAP
•    ماژول پستی
•    ماژول حاشیه ها
•    ماژول صفحات برند
•    ماژول هشدار از طریق چاپی
•    ماژول محصولات
•    ماژول پروژه ها
•    ماژول طرح کسب و کار
•    ماژول مالیات بانک
•    ماژول خدمات
•    ماژول خدمات وب
•    ماژول سهام
•    ماژول مالیات و سود سهام
•    ماژول سوم
•    ماژول کاربران
•    ماژول گردش کار
•    پیمانه Márgenes
•    الگو: NoInstallModuleF

تنظیمات نخست
پس از نصب واقعی Dolibarr، شما باید آن را با توجه به نیازهای خود قبل از استفاده پیکربندی کنید.
شرکت / مؤسسه
برای شروع، از صفحه اصلی، بهمنو"تنظیمات ->شرکت / مؤسسه"بروید و اطلاعات مربوط به موسسه خود را ویرایش نمایید.
•    نام و نام خانوادگی: نام شرکت و یا ارتباط
•    لوگو:اضافه کردن لوگوی خود در اینجا (فعلی، JPG یا GIF ... )در حال حاضر هیچ فرمتی توصیه نمی شود اما PNG بدون پس زمینه شفافبهتر استیا ، استفاده از یک لوگو در قالب فایل jpg بر روی زمینه سفید.
•    کشور: مجموعه کشور خود را به عنوان گزینه های وابستهفراموش نکنید
•    مالیات بر ارزش افزوده:تنظیم یا عدم تنظیم مالیات بر ارزش افزوده.
ماژول ها
فعال شدن ماژول بسیار مهم است.این بسیار بعید است که شما به تمام ماژول ها نیاز داشته باشید.بنابراین شما نیاز به فعال سازی ماژول هایی کهاحتمال زیاد می دهید نیاز باشد، دارید.به عنوان مثال: صورت حساب شرکت در حسابداری نهایی.
برای فعال کردن ماژول:منو"تنظیمات ->ماژول" و کلیک بر روی "فعال".
لیست ماژول های استاندارد در صفحه تعریف شده در لیست ماژول .
هنگامی که فعال شده، برخی از ماژول نیاز به تنظیمات اضافی دارند (با کلیک بر روی آیکون که در همان خط به سمت راست ظاهر می شود).
منوها
نمایش
در این بخش به شما اجازه داده می شود زبان و نمایش صفحات را انتخاب کنید.در ابتدا شما باید گزینه های پیش فرض را نگه دارید.
گزینه های چند زبانه به شما برای مدیریت ترجمه های مختلف در ترجمه ی محصول و انتخاب مشتریان زبان پیش فرض برای ویرایش اسناد PDF به زبان به طور پیش فرض از ردیف را اجازه می دهد.
دیگر ورودی ها در منوی تنظیمات گزینه های پیشرفته می باشد.که اجباری نیست.
•    تنظیم جعبه
•    تنظیم هشدارها
•    تنظیمات امنیتی
•    ایجاد محدودیت و جزئیات
•    PDF
•    تنظیم ایمیل
•    تنظیم SMS
•    تنظیم واژهنامهها
•    تنظیمات مختلف

کاربران
آخرین مرحله ایجادکاربران و اختصاص مجوزهااست.تقریبا تمام ماژول ها حتی پیش از که فعال شده باشند، اگر شما اجازه ندهید،در دسترس هستند.برای این کار، شما می توانید به منوی اصلی بروید ->کاربران و گروه برای تعریف کاربران و حقوق آنها است.توجه کنید که باید مطمئن شد که برای بررسی و تنظیم مجدد حقوق کاربر زمانی ،شما ماژول های جدید را دوباره فعال می کنید.لیست حقوق موجود بسته به نوع ماژول های فعال و مجوز به طور پیش فرض است، توصیه می شود بعد فعال کردن ماژول های مورد نظرتنظیم این قسمت را انجام دهید.برای دادن حقوق به یک کاربر و یا خود اگر شما یک مدیر هستید، صفحه نخست ->کاربران و گروه ها، را انتخاب کنید مشخصات برای کاربر مورد نظر، و سپس بر روی زبانه مجوزکلیک کنید.
این امکان وجود دارد برای جلوگیری از این مراحل پیکربندی برای هر کاربر جدید مجوز پیش فرضپیکربندی شود (به عنوان خوانده شده حقوق به طور خودکار به هر کاربر جدید ایجاد اختصاص داده)، دسترسیها به طور پیش فرض در صفحه Paramétrage_Sécurité است.
افزودنیهای فایرفاکس
افزودنیهای فایرفاکس ویژگی هایی است که می تواند بهفایل Dolibarr اضافه شده و موجب اضافه کردن اجزای سازنده باشد.
وب سایت DoliStore دانلود ماژول خارجی فراهم می کند DoliStore.com .
«افزودنیهای فایرفاکس"
•    برنامه آندروید - DoliDroid FR
•    Agefodd ماژول
•    ماژول طبقه بندی
•    AWStats ماژول
•    بلژیک
•    بیت تورنت
•    ماژول کابینه پزشکی
•    تلفن
•    EN کاتالوگ
•    چسبانده PDF FR
•    CustomFields FR
•    اسناد FR
•    DoliPos FR
•    EsAEB FR
•    ماژول مدیریت فایل
•    گوگل
•    میزبانی وب FR
•    برچسب FR
•    Massorders FR
•    ماژول MemCached
•    MLM
•    NumberingPack FR
•    NumberWords ماژول FR
•    ماژول OVH (SMS، ClickToDial ...) FR
•    اطلاعات php
•    Pibarcode
•    ماژول گزارش FR
•    پاداش FR
•    SkinEditor FR
•    SpeedFinder FR
•    Thelia
•    ThomsonPhoneBook
•    ماژول بلیط
•    Ultimatepdf FR
•    رویدادهای  نام

ثابت ها
معرفی
تنظیمات Dolibarr در 2 سطح است.عمومی(مشترک به تمام تنظیمات کاربران) و سطح هر کاربر (تنظیمات خاص هر کاربر).
پیکربندی کلی (هر کاربر)
کلپیکربندی عمومیdolibarr در جدول llx_const ..ذخیره می شود هر پارامتر پیکربندی شده توسط یک کلید (نام پارامتر) (نام حوزه)و ارزش (مقدار فیلد) تعریف شده است.موارد دیگر اختیاری هستند.درست است توجه داشته باشیدشرح شامل نقش پارامتر می شود.
همه این ثابت ها را می توان از منوی ویرایش "صفحه اصلی - راه اندازی»و همه زیر منوها مشاهده کرد.آنها همچنین می توانند از طریق صفحه "- تمامی سیستم های اطلاعات ثابت - صفحه اصلی. Dolibarr"دیده می شود
هر کاربر تنظیمات
کل پیکربندیکاربرdolibarr در جدول llx_user_paramذخیره می شود .در این زمینه fk_userکه حاوی شناسه ی کاربر است.
همه این ثابت می توان از سابقه کاربر ویرایش، زبانه "تنظیمات کاربری"
متفرقه
•    چند کاربر با سطوح مجوز های متعدد برای هر ویژگی ها.
•    چند مدیران منو استفاده کنید (می تواند توسط کاربران داخلی به عنوان یک دفتر با یک منوی خاص و یا کاربران خارجی به عنوان یک جلو دفتر با یکدیگر استفاده می شود).
•    بسیار کاربر پسند و آسان برای استفاده.
•    بسیار قابل تنظیم (فقط فعال کردن ماژول های مورد نیاز، رشته های کاربر شخصی، انتخاب پوسته خود).
•    با PHP 5.2.1 +، 4.1MySQL+یا PostgreSQL 8.1.4 +نسخهها کار میکند.
•    سازگار با (2006/112/CE ... 2010/45/UE) ( http://europa.eu/legislation_summaries/taxation/l31057_en.htm )
بازیگران و نقش آنها درDolibarr
تیم Dolibarr فعلی از مقامات مختلف، حمایت توسط شرکت های مختلف فیزیکی و اخلاقی (شرکت ها، انجمن ها) تشکیل شده است.خطوط زیر نقش و موقعیت در پروژه Dolibarr مدیریت برگزار مختلفرا نشان می دهد و در نتیجه ما را قادر به درک عملکرد درونی پروژه می سازد.بسیاری از نقش ها و موقعیت ها به طور دائم پر شده است.

موارد زیر در ابتدا توسعه دهندگان نقش های مختلف و سپس همه نقش ها غیر از توسعه دهندگان را نشان می دهد.همه این نقش ها بخشی از موتور پیشرفت Dolibarrهستند.
توسعه دهندگان نقش
نقش A: خدمات میزبانی وب سایت ( http://www.dolibarr.orgو یا سایت های محلی)
هدف: مطالعه برای ارائه و حفظ پلت فرم میزبانی وب مبتنی بر جوملاوب سایتDolibarr.
نقش B: میزبانی وب نسخه ی نمایشی ( http://demo.dolibarr.org/public/demo )
نقش C1: ویکی اسکان ( http://wiki.dolibarr.org )
نقشC2 :بازار اسکان ( http://wwww.dolistore.com )
نقش D: doliforge اسکان ( http://wwww.doliforge.org )
E1 نقش: DoliWamp مسئول (نصب برای ویندوز)
E2 نقش: مسئول DoliDeb + DoliRpm (نصب اوبونتو / دبیان / فدورا / مندریوا / رد هت / لینوکس)
E3 نقش: DoliMamp مسئول (نصب برای سیستم عامل Mac OS X)
نقش F: ابزار برای ایجاد ماژول های MDA (UML2Dolibarr)
G نقش: مدیر عامل بنیاد Dolibarr
نقشH: توسعه / ارتباط برای Dolibarr
نقش تستر Dolibarr
نقش J: اداره حوزه
دسترسی GIT
سرور GIT توسط http://www.github.comمیزبانی می شود.
نصب و راه اندازی - به روز رسانی
روش های چگونگی نصب یا به روز رسانی Dolibarr:
محتویات
•    1روش نصب و راه اندازی
o    1.1/ گوشی شما و سرور اختصاصی
    DoliWamp(1.1.1با بسته ویندوز. EXE
    DoliDeb(1.1.2با دبیان / اوبونتو بسته. دب
     DoliRpm (1.1.3با بسته فدورا، رد هت، مندریوا، Mageia و یا لینوکس. دور در دقیقه
    Dolibarr(1.1.4با بسته بندی استاندارد. نوع tgz
o    1.2در یک سرور میزبانی مشترک (دسترسی محدود)
o    1.3در یک SaaS یا ابر میزبانی
•    2روش به روز رسانی
o     DoliWamp(2.1با بسته ویندوز. EXE)
o     DoliDeb(2.2با بسته بندی (دبیان / اوبونتو. دب)
o     DoliRpm (2.3با بسته فدورا، رد هت، مندریوا، Mageia و یا لینوکس. دور در دقیقه
o    Dolibarr(2.4با بسته بندی استاندارد. نوع tgz
•    3پیکربندی اتصال LDAP
•    4ورود داده های خارجی
•    5تنظیمات
روش نصب و راه اندازی
در این فصل به توصیف روش های مختلف (ساده، راهنما) ممکن برای نصب می پردازیم
در ایستگاه های کاری / سرور خود اختصاص داده
 با DoliWamp (بسته ویندوز. EXE
- پیش نیاز:ویندوز
- سطح:مبتدی
اگر چگونگی نصب سرور آپاچی وب، پی اچ پی و خروجی زیر را می دانید ، فصل بعد برای شما مناسب تر است.برای افراد کم تجربه که Dolibarr تحت ویندوز را می خواهند، یک توزیع Dolibarr نام DoliWamp وجود دارد که اجازه ی نصب و راه اندازی Dolibarr تحت ویندوز با تمام پیش نیازهای آن (آپاچی، خروجی زیر، پی اچ پی) بدون دانش کامپیوتر را می دهد.در اینجا چگونگی نصب را می بینید:
•    بازیابی نسخه از Dolibarr برای ویندوز.
•    راه اندازی exe. دانلود و به دنبال دستورالعمل.
 با DoliDeb دبیان / اوبونتو. بسته ی deb
- پیش نیازها:لینوکس دبیان، اوبونتو، ...
- سطح:مبتدی
DoliRpm بابسته فدورا، رد هت، مندریوا، Mageia و یا لینوکس
- پیش نیازها:لینوکس فدورا، رد هت، مندریوا، Mageia و یا لینوکس (ممکن است برای aussi کار هر توزیع لینوکس دور در دقیقه)
- سطح:مبتدی
Dolibarr بابسته بندی استاندارد. نوع tgz
- پیش نیاز:آپاچی، پی اچ پی و سرور پایگاه داده( MySQL یا PostgreSQL) حاضر و فعال ، و رمز عبور دسترسی ورود / رمز عبور (یک پایگاه داده جدید و یا سرورشناخته شده).
- سطح:دانش کامپیوتر کمی در مدیریت وب.
این روش چگونگینصب دستی را توضیح می دهدکه به علت طولانی بودن از توضیح کامل صرف نظر می کنیم.
روش به روز رسانی
این فصل چگونگی به روز رسانی نصب موجود Dolibarr نسخه قدیمی را نشان می دهد.این فرآیند بدون در نظر گرفتن نسخه های قبلی و بعدی یکی است، اما با توجه به توزیع و یا سیستم عامل برای اولین بار نصب و راه اندازی شما متفاوت خواهد بود. به استفاده از همان نوع از توزیع برای به روز رسانی که برای نصب و راه اندازی برای اولین بار مورد استفاده قرار گرفت ،توصیه می شود.
 DoliWamp بابسته ویندوز. EXE
اگر شما نصب نسخه خاصی از Dolibarr با نام DoliWamp (که ادغام وب، پی اچ پی و سرور خروجی زیر)را دارید، روش به شرح زیر است (در هر مورد دیگر، استفاده از یکی از روش های فصل های زیر):
•    دانلود نسخه جدید DoliWamp.
•    راه اندازی exe. بگذارید و راهنمای شما در تمام مراحل مهاجرت را با کلیک کردن بعدی، در کنار ...هر زمان مقادیر پیش فرض بدون تغییر ارائه شده است.
 DoliDeb بادبیان / اوبونتو. بسته ی deb
اگر شما از طریق یک Dolibarr Packagage دبیان اوبونتو را نصب نمودید، بروز رسانی فقط به همان روش نصب اول است.فقط بسته جدید را نصب کنید. به عنوان مثال بعد از عمل Dolibarr برای اوبونتو یا دبیان .
 DoliRpm بابسته فدورا، رد هت، مندریوا، Mageia و یا لینوکس.
 Dolibarr بابسته بندی استاندارد. نوع tgz
این روش چگونگی به روز رسانی Dolibarr از نسخه قدیمی به نسخه های جدیدتر به روش کتابچه راهنمای کاربر، با توزیع استاندارد را توضیح می دهد.
پیکربندی اتصال LDAP
واردات داده های خارجی
تنظیمات - تنظیمات
Dolibarr برای ویندوز (DoliWamp)
DoliWampیک نسخه از Dolibarr ERP / CRM بسته بندی شده با آپاچی، MySQL، PHP، است و نصب برنامه به طور خودکار برای کاربران ویندوز که مهارت های کامپیوتر دارند ، انجام می شود.
در عرض چند ثانیه پس از راه اندازی DoliWamp خودکار نصب قادر به کار با Dolibarr، حتی بدون هیچ سرویس دهنده وب و یا شناخته شده به آپاچی، MySQL و یا PHP نخواهد بود.همه چیز برای شما نصب شده است.توجه داشته باشید که اگر شما DoliWamp  را انتخاب کنید ، همه به روز رسانی به یک نسخه جدید از Dolibarr باید با استفاده از نسخه جدید DoliWamp انجام می شود.
DoliWamp یک بسته است که می تواند از صفحه اداره DoliWamp NLTechno دانلود شود.
موضوع کنفرانس C: DEMO TAKE IT EASY
عنوان / مدت زمان
چرا استفاده از   Dolibarr بسیار آسان است؟
مدت زمان: 7mn حداکثر
هدف :نشان دهد که چگونه Dolibarr آسان برای استفاده است.
معرفی برنامه
Dolibarr  یکنرم افزار ERP و CRM است، بنابراین نرم افزاری برای مدیریت روابط مشتریان و آگهی منابع شرکت می باشد که آن را از نرم افزار های دیگر در گروه های مشابه متفاوت می نماید زیرا استراتژی و فن آوری اش متفاوت است.
•    سایر نرم افزار های opensource برای رسیدن به شرکت بازار متوسط ووسیعسعی می کنند.
•    Dolibarr هر گونه پایه و اساس شرکت هدف را تأیید نکرده است (مانند موزیلا فایرفاکس) و هدف رسیدن به شرکت های کوچک و متوسط، و کاربران آزاد بدون دانش فنی است.برای رسیدن به این هدف، تمامی آثار در 5 کلمه متمرکز شد:
آسان - آسان - آسان - آسان - آسان (نصب آسان، آسان به نصب، آسان برای استفاده، آسان به بهبود، آسان به توسعه)
تم ها
عبارتند از:
•    تم 1: فنی مستندات
•    موضوع 2: دسترسی به داده ها (DAO)
•    تم 3: طراحی و MVC موتور قالب
•    تم 4: اجرا
•    موضوع 5: ترجمه
•    تم 6: حمل
•    تم 7: امنیت
•    تم 8: تست واحد / رگرسیون
بازنگری کاربردی
فهرستی از ویژگی ها
بازنگری فنی
لیست مشخصات
ارائه تاریخی
سابقه و هدف توسعه نرم افزار.
نمودار مقایسه
مزیت / ضرر    موتور الگو (ناقلا...)    PHP الگو بومی (Dolibarr انتخاب)
"فنی" کد عایق تضمین / ارائه    بله    نه
نگهداری    راحت تر   
مقیاس پذیری    بیشتر بسته    بیشتر انعطاف پذیر
ویژگی ها       
کارایی    بدتر (تبلیغات سازمان دیده بان "حافظه پنهان";).120    پایه 100
مقایسه لایه انتزاعی PDO و از Dolibarr
مزیت / ضرر    PDO    روکش Dolibarr
قابلیت حمل DDL
(انتخاب، درج ...)    بله    بله
حمل دستور DML
(ایجاد، حذف، ...)    نه    بله
کد خطا قابل حمل    ناقص    بله
تو در تو مدیریت معاملات    نه    بله
•    نتیجه
نتیجه در Dolibarr به دست آمده قابلیت حمل بدون نگهداری دو برابر شود.
رمزگذاری فایل سیستم (ویندوز ANSI / UTF لینوکس)
پایه و اساس ایجاد Dolibarr
ایجاد پایه و اساس Dolibarr
مجلس موسسان بنیاد Dolibarr در 2009 فوریه 24 در پاریس صورت گرفت.
هدف آن توسعه، مستند سازی، حفاظت، ترویج، توزیع و مدیریت نرم افزار رایگان Dolibarr ERP / CRM است.
زبان ها و استانداردها
در اینجا برخی از قواعد زبان، نحو، و توسعه استانداردها در محل پروژه Dolibarr عبارتند از:
نسخه
•    Dolibarrباید در کار:
1.    تمام سیستم عامل (ویندوز، لینوکس، MAC OS  ...)
2.    PHP 5.2.1 +باید بدون هیچ ماژول PHP اضافی از ماژول های دسترسی به پایگاه داده کار می کنند
3.    خروجی زیر 4.1 +
استانداردهای PHP
•    Dolibarr در PHP نوشته شده و از تمام نسخه های بالاتر PHP 5.2.1 +پشتیبانی می نماید. همه فایل ها باید پسوند. پی اچ پی داشته باشند.
استاندارد SQL
ساختار جداول و زمینه های
•    تمام جداول دارای  پیشوند برای جلوگیری از تکرار نامگذاری است.که، پیشوند است قابل تغییر است .مقدار پیش فرض آن llx_ است.
کلید اولیه
کلید اصلی یک جدول به نام ROWID است.
کلید خارجی
نام کلید خارجی با پیشوندFK_ و به دنبال آن نام جدول مرتبط
به عنوان مثال: fk_facture_fourn_fk_soc
کلید های جایگزین
گاهی اوقات کلید اصلی منحصر به فرد وجود ندارد.از این رو ممکن است یک شاخص کلیدی جایگزین منحصر به فرد اضافه کنید.این شاخص از یک نام است که با پیشوندuk_و به دنبال آن نام جدول به زیر به عنوان مثال: uk_societe_code_client
عملکرد صفحه اول
برخی از زمینه ها اغلب به عنوان ضوابط جستجو ، طبقه بندی، و یا پیوستناستفاده می شود.باید در این مورد، برای قرار دادن شاخص عملکرد باشد.این شاخص باپیشوندidx_ سپس نام جدول و نام فیلد که در آن شاخص نام است.
به عنوان مثال: idx_societe_user_creat
فرمت فایل DDL
فایل ها که حاوی تعریف ساختار پایگاه داده (DDL) است
این فایل ها در دایرکتوری نصب / مای / جداول استاندارد و یا mymodule /فایل برای جداول آورده شده توسط جداول ماژول قرار داده است.
جدول فایل نمونه llx_matable.sql:
کپی رایت
-- این برنامه نرم افزار رایگان است، شما می توانید آن را بازتوزیع کرده و / یا تغییر دهید
- این تحت شرایط مجوز مستندات آزاد گنو به همان شکلیت که منتشر شده است-
- این برنامه به این امید  توزیع شده که مفید باشد،
- اما بدون هرگونه ضمانت
- مشاهده قابلیت تجاری یا تناسب برای یک منظور خاص.
- مجوز عمومی کلی گنو برای جزئیات بیشتر.
الگوهای طراحی و برنامه نویسی شی گرا
الگوهای طراحی ایجاد (GOF)
الگوهای طراحی ساختار (GOF)
الگوهای طراحی رفتار (GOF)
الگوهای طراحی شرکت (مارتین فاولر)
هيئت مدیره
•    لوران Destailleur - مدیر پروژه در GIE IT و نویسنده AWStats تحلیل وارد شوید.مدیر پروژه Dolibarr
•    فیلیپ بزرگ - شرکت مدیر Atoo.Net
•    گیلبرت مارین - مدیر PrestaInfo
•    سیریل لامبرت - مدیر Auguria
•    سیمون Tosser - رئیس شرکت KORNOG رایانه
•    جان Heimburger - مدیر Tiaris


ارسال شده توسط احمد محمدی | 8 12, 2013 | بازدید‌ها (3489)

مقاله کارت امتیازی متوازن؛ سیستم جامع مدیریت و ارزیابی استراتژی

عنوان مقاله : کارت امتیازی متوازن؛ سیستم جامع مدیریت و ارزیابی استراتژی

نویسنده : دکتر فرشید محمدنژاد

1- کارت امتیازی متوازن در یک نگاه
ارزیابی و مدیریت عملکرد، منتج از برنامه های استراتژیک و برنامه های عملیاتی سازمان است. اگرچه تدوین برنامه‌های استراتژیک و عملیاتی، فرایندی پیچیده و دشوار است ولی اجرای موفقیت‌آمیز آنها به مراتب دشوارتر است. سازمان های زیادی در پیاده‌سازی کامل استراتژی های خود، شکست می‌خورند. این مساله ناشی از تعریف ناقص استراتژی ها و برنامه‌های عملیاتی سازمان نیست بلکه احتمالاً به این خاطر است که چارچوب مستحکمی برای همسوسازی کارکنان و فرایندهای عملیاتی با اهداف سازمان، وجود ندارد (Creelman & Makhijani, 2008).
سازمان های امروزی به خوبی دریافته اند که 80 درصد ارزش افزایی آنها از طریق دارایی های نامشهودشان شامل سرمایه های انسانی (دانش و مهارت های کارکنان)، سرمایه های سازمانی (فرهنگ سازمان و ارزش های حاکم بر آن) و سرمایه های اطلاعاتی (منابع اطلاعاتی و داده های آماری) ایجاد می شود و دیگر نمی توانند صرفاً با اتکاء به دارایی های مشهود، ارزیابی عملکرد و در پی آن مدیریت عملکرد جامعی انجام دهند (Kaplan & Norton 2008; Kaplan & Norton 2004).
پروفسور رابرت کاپلان و دکتر دیوید نورتون با درک الزامات و نیازمندی های سازمان های نوین و برای اجرای اثربخش استراتژی و ایجاد یک سیستم جامع مدیریت و بهبود عملکرد، در سال 1992 سیستم مدیریتی نوینی را تحت عنوان کارت امتیازی متوازن، معرفی نمودند. سیستم مدیریتی کارت امتیازی متوازن، به عنوان چارچوب جامع ارزیابی عملکرد و پیشبرد استراتژی، مطرح بوده که به ایجاد توازن بین اهداف کوتاه مدت و بلند مدت، سنجه‌های مالی و غیر مالی، عملکرد داخلی و خارجی، ذینفعان درونی و بیرونی، شاخص های هادی و تابع عملکرد، منجر می‌شود. کارت امتیازی متوازن چارچوب اثبات شده ای است که استراتژی سازمان را تشریح و عملیاتی می کند (Creelman & Makhijani, 2008; Niven, 2006).
کارت امتیازی متوازن، یک سیستم مدیریتی است که می تواند اجرای استراتژی ها را مدیریت کرده و عملکرد سازمان را در چهار منظر مالی، ‌ مشتری، فرایندهای داخلی، و رشد و یادگیری، اندازه گیری کند و باعث انتقال و تفهیم ماموریت، چشم انداز، استراتژی ها و انتظارات عملکردی به کلیه ذینفعان درونی و بیرونی سازمان شود. به عبارت دیگر، کارت امتیازی متوازن می تواند چشم انداز و ماموریت سازمان را در قالب مجموعه ای از روابط علّت و معلولی در چهار منظر ذکر شده نشان دهد (Nissen, 2006; Achterbergh et. al. , 2003).
سیستم مدیریتی کارت امتیازی متوازن، ترکیبی است از معیارهای ارزیابی عملکرد که شاخص های عملکرد گذشته، جاری و نیز آینده را شامل شده و معیارهای غیر مالی را در کنار معیارهای مالی قرار می دهد. ضمن اینکه از آنچه در داخل و خارج سازمان اتفاق می افتد، بینش و دید همه جانبه ای را به مدیران سازمان ارائه می کند (Akkermans & von Oorschot, 2000; Linard & Yoon 2000).
چارچوب کارت امتیازی متوازن از چهار مولفه به هم وابسته تشکیل شده است (Creelman & Makhijani, 2008). این چهار مولفه عبارتند از:
الف- نقشه استراتژی که اهداف استراتژیک سازمان را شناسایی می کند و در قالب روابط علّت و معلولی، ارایه می کند. اگر این اهداف محقق شوند یعنی استراتژی با موفقیت اجرا شده است. کارکرد اصلی نقشه استراتژی این است که به صورت روابط علّت و معلولی نشان می‌دهد که برای اجرای استراتژی، چگونه اهداف استراتژیک می بایست با یکدیگر تعامل کنند.
ب- سنجه‌های عملکردی که میزان پیشروی به سمت اهداف استراتژیک را ردیابی کرده و ارایه می کنند.
ج- اهداف کمّی که برای تحقق هر یک از سنجه های عملکردی، تعیین می‌شوند.
د- طراحی (انتخاب) و اجرای ابتکارات استراتژیک (طرح های ابتکاری) برای اینکه عملکرد سازمان به اهداف کمّی متصل شود و در نهایت، اهداف استراتژیک محقق شوند.
باید توجه کرد که ترسیم نقشه استراتژی، مهمترین مولفه برای ایجاد کارت امتیازی متوازن است و لذا باید در اولین مرحله طراحی و اجرای سیستم کارت امتیازی متوازن قرار گیرد (Creelman & Makhijani, 2008).
کارت امتیازی متوازن می تواند یک سیستم ارزیابی و سنجش عملکرد ارایه کند که فراتر و جامع تر از سیستم های مرسوم حسابداری مدیریت است (Creelman & Makhijani, 2005). در این روش، علاوه بر شاخص های مالی، وضعیت سازمان با شاخص های سه منظر دیگر، در یک رابطه علّت و معلولی مورد سنجش و ارزیابی قرار می گیرد. در واقع، کارت امتیازی متوازن بین اجزای مختلف سازمان یک ارتباط علّت و معلولی برقرار می کند و به سازمان به مثابه یک پیکر واحد و یکپارچه می نگرد (Blokdijk, 2008; Bukh & Malmi, 2005).
همچنین، کارت امتیازی متوازن قادر است استراتژی را به اهداف و برنامه های اجرایی و عملیاتی سازمان در قالب یک سیستم جامع مدیریتی، متصل نماید. تبدیل جهت گیری های استراتژیک به اهداف و برنامه های مشخص از یکسو و اجرایی سازی یک سیستم اندازه گیری جهت کنترل چگونگی تحقق اهداف و پیشرفت برنامه ها از سوی دیگر، جذابیت و کاربرد سیستم مدیریتی کارت امتیازی متوازن را افزایش داده است. سیستم مدیریتی کارت امتیازی متوازن تنها چارچوب موجود در دنیا است که قادر است استراتژی ها را با عملکرد و بودجه تلفیق نماید (Kaplan & Norton 2008; Cobbold & Lawrie, 2002).
سیستم مدیریتی کارت امتیازی متوازن، پس از قریب 15 سال تجربه پیاده سازی و اجرایی در سازمان ها و شرکت های مختلف بخش خصوصی و دولتی، در حال حاضر تنها رویکرد اثر بخش تجربه شده برای استقرار یک نظام جامع مدیریت عملکرد به همراه 40 نرم افزار تولید شده در دنیا می باشد و آنچنان نتایج موفق و دستاوردهایی را در حوزه مدیریت عملکرد و پیاده سازی و کنترل استراتژی ایجاد نموده که همچنان در رأس رویکردهای موفق استقرار نظام جامع مدیریت در سازمان محسوب می شود. به همین خاطر است که مبدعان کارت امتیازی متوزان در آخرین کتاب خود آن را سیستم مدیریتی حلقه بسته نامیده اند (Creelman & Makhijani, 2005; Niven, 2008).
در ادامه، اجزای اصلی سیستم کارت امتیازی متوازن توضیح داده می شوند.

2- نقشه استراتژی؛ مهمترین فرایند کارت امتیازی متوازن
مبدعان کارت امتیازی متوازن، معتقدند که اجرای موفقیت آمیز استراتژی های سازمان، بستگی به این دارد که افراد سازمان، استراتژی ها را فهمیده و درک نمایند. باید توجه کرد که این امر نیز به نوبه خود، نیازمند ایجاد فرآیندهای پیچیده ای است که باعث می شود سرمایه‌ها و دارایی های نامشهود سازمانی به خروجی‌های ملموس و مشهود تبدیل شوند. برای اینکه تمامی افراد سازمان بتوانند در یک نمای کلّی و کلان، استراتژی های سازمان را بفهمند و آن را درک نمایند و نیز به منظور ساده سازی فرآیندهای پیچیده ای که باعث می شود سرمایه‌ها و دارایی های نامشهود سازمانی به خروجی‌های ملموس و مشهود تبدیل شوند، مبدعان کارت امتیازی متوازن، ابزاری را معرفی کرده اند که می تواند با شناسایی و استخراج اهداف کلیدی (استراتژیک) سازمان و به تصویر کشیدن روابط علّت و معلولی بین آنها پیوند بین ساختار استرتژی های سازمان را ارایه نماید. این ابزار، نقشه استراتژی نام دارد (Kaplan & Norton 2000).
در نقشه استراتژی، سازمان به چهار منظر (یا بیشتر)، افراز می شود و اهداف کلیدی (استراتژیک) سازمان که مندرج در برنامه استراتژیک سازمان است، در این چهار منظر، دسته بندی می شود. این چهار منظر، عملاً نشان دهنده کلیه اجزاء و فرایندهای سازمان هستند و عبارتند از: منظر مالی، منظر مشتری، منظر فرایندهای داخلی، منظر رشد و یادگیری. هر سازمان می تواند بسته به ساختار صنعت و نیز دینامیک های خود، مناظر نقشه استراتژی خود را زیاد یا کم نماید. اهدافی مانند توسعه کسب وکارهای ارزش آفرین، اشتغالزایی و درآمدزایی، بهبود رضایت مندی مشتریان، پرورش استعدادها و ابتکارات نوآورانه در گروه شرکت ها، افزایش رضایت مندی ذینفعان و کارکنان، می تواند از جمله اهداف استراتژیک سازمان باشد (Chytas, 2008; Kaplan & Norton 2000).
با ترسیم دقیق روابط علّت و معلولی بین اهداف استراتژیک سازمان در این چهار منظر، مبنایی به دست می آید که می تواند به عنوان شالوده کارت امتیازی متوازن قرار گیرد. به عبارت دیگر، با مبنا قرار دادن نقشه استراتژی به عنوان شالوده و مبنای کارت امتیازی متوازن، الگویی حاصل می شود که باعث می شود پیاده سازی موفقیت آمیز کارت امتیازی متوازن، تسریع شود. نقشه استراتژی شرکت Saatchi & Saatchi در شکل (1) آمده است (Creelman & Makhijani, 2008).
اعتقاد بر این است که بهترین راه ترسیم نقشه استراتژی استفاده از رویکرد بالا به پایین است. به این معنا که مدیران سازمان، می بایست ابتدا فرایند تدوین و طراحی برنامه استراتژیک سازمان را به انجام برسانند و با استفاده از برنامه استراتژیک تدوین شده، اهداف کلیدی (استراتژیک) را استخراج و در مناظر تدوین شده قرار داده و روابط علّت و معلولی بین آنها را برقرار نمایند. ترسیم نقشه استراتژی، مهمترین مولفه برای ایجاد کارت امتیازی متوازن است. ترسیم ساختار اهداف استراتژیک و کلیدی سازمان، شالوده و مبنای کارت امتیازی متوازن را تشکیل می‌دهد که به عنوان وجه تمایز سیستم مدیریتی کارت امتیازی متوازن با سایر تکنیک ها می باشد. ترسیم درست نقشه استراتژی، باعث می‌شود که سنجه‌ها، اهداف کمّی و طرح های ابتکاری سازمانی به صورت کاربردی تری انتخاب شوند (Smith, 2006).
متاسفانه سازمان ها و شرکت های زیادی در مسیر کارت امتیازی خود با مشکلات عدیده‌ای مواجه می‌شوند، چراکه در ترسیم نقشه استراتژی شان، اشتباهات جدی مرتکب می شوند. تجربه نشان داده است که سازمان ها برای طراحی نقشه استراتژی خود، عموماً تمایل دارند اهداف متعددی را انتخاب کنند که معمولاً تعداد آنها به 40، 50 یا حتی60 هدف هم می‌رسد. باید گفت خروجی این کار، نقشه‌ای خواهد بود که تمام کارهایی که سازمان انجام می‌دهد را تشریح می‌کند (که می‌توان آنرا نقشه‌ سازمان نامید نه نقشه استراتژی) Creelman & Makhijani, 2008).
نقشه استراتژی باید فقط اهداف کلیدی سازمان را شامل شود. اهداف کلیدی سازمان، اهدافی هستند که الزاماً می بایست استراتژی را به خوبی تبیین و توصیف نمایند. اگر تعداد اهداف، زیاد باشد، کارت امتیازی کاملاً غیرقابل مدیریت می‌شود و در نتیجه، کل برنامه اجرایی آن، از بین می‌رود. اگر هم اجرای کارت امتیازی تداوم داشته باشد به پایین‌ترین اولویت سازمانی تبدیل می‌شود، چراکه افراد از طولانی شدن و مدیریت کار، خسته خواهند شد. تحقیقات نشان می‌دهد که 15 تا 20 هدف کلیدی برای هر نوع سازمانی می تواند کفایت کند. حدود 40 درصد این اهداف هم باید در منظر فرایندهای داخلی قرار گیرند؛ چراکه عملیات اصلی اجرای استراتژی در این منظر انجام می‌شود. برای طراحی ساختار اثربخش سازمانی، الزاماً باید همسویی بین ساختار اهداف کلیدی و وظایف استراتژیک سازمان رعایت شود (Creelman & Makhijani, 2008; Kaplan & Norton 2004).
به نظر می رسد که متناسب با چارچوب ارایه شده توسط مبدعان کارت امتیازی متوازن، سازمان های مختلف اغلب بدون در نظر گرفتن روابط علّت و معلولی میان اهداف استراتژیک و تنها از طریق نظرات و اتفاق نظر مدیران ارشد و متخصصان و کارکنان با تجربه سازمان و طی سلسله جلسات متعدد مدیریتی، مناظر نقشه استراتژی و اهداف استراتژیک مندرج در آن را انتخاب می‌کنند. با توجه به تحقیقات صورت گرفته و منتشر شده، معیار و راهکاری مشخصی برای تعیین ساختار اهداف و سنجه‌های کلیدی سازمان و برقراری رابطه علّت و معلولی بین آنها در قالب نقشه استراتژی و در نتیجه ارایه نقشه استراتژی، ‌ ارایه نشده است (Bukh & Malmi, 2005; Akkermans & von Oorschot, 2000; Linard & Yoon 2000)
مستند به فرایندها و اقداماتی که سازمان ها برای طراحی نقشه استراتژی خود انجام می دهند، به نوعی می توان گفت که این الگوها در ذات خود از رویکردی قضاوت محور برخوردارند و نمی توانند مبنایی اثربخش و کارا برای نقشه طراحی شده، ارایه دهند. به همین دلیل است که در چند سال گذشته، تحقیقات متعددی برای استفاده از الگوریتم ها و سیستم های پشتیبان تصمیم و خبره برای این منظور، آغاز شده است (Bobillo et. al. , 2009; Kardaras & Mentzas 1997).
از طرف دیگر یکی از مهمترین و کلیدی ترین مسایل موجود در نقشه استراتژی و داشبوردهای عملیاتی، این است که سنجه های مورد نظر در اهداف استراتژیک، ترکیبی از سنجه های کمّی و کیفی هستند. به عبارت دیگر برخی از این سنجه ها/اهداف، باید از داده های تاریخی و عملیاتی استفاده کنند و برخی دیگر نیز نیازمند ارزیابی های کیفی هستند. باید گفت که به دلیل پیچیدگی در استفاده از این داده ها و زمانبر بودن شناسایی و استخراج آنها است که استفاده از دانش و تخصص افراد به پیشبرد مساله طراحی و تدوین نقشه استراتژی، کمک می کند (Parmenter, 2010).
نکته بسیار مهم دیگر این است که عملاً نمی توان قضاوت(های) تیم ارشد را (چه برای داده های تاریخی و یا داده های کیفی) به صورت همزمان در نظر گرفت. بنابر این، اصلی ترین عاملی که روی طراحی نقشه استراتژی تاثیرگذار است، تجربه و دانش تیم مدیریت و بدنه کارشناسی سازمان است و سایر عوامل نقش بسیار پایینی دارند. الگویی که بتواند تلفیق این موارد را در نظر بگیرد به سختی قابل دسترسی است (Rydzak et. al. , 2004).


کارت امتیازی متوازن


شکل (1):  نقشه استراتژی شرکت Saatchi & Saatchi

3- انتخاب سنجه های استراتژیک
اهداف استراتژیک و نقشه های استراتژی سازمان عملاً می توانند اهداف کلان سازمان را برای ارایه عملکرد کوتاه مدت و بلند مدت در قالب کلمات و نمودارها نشان دهند. اما برای اجرایی سازی این اهداف، می بایست آنها را قابل اندازه گیری و سنجش نماییم (Parmenter, 2010).
پیتر دراکر، بزرگمرد مدیریت گفته است «چیزی را که می توان اندازه گیری (سنجش) کرد، می توان اجرا هم کرد». باید گفت که اگر سازمان ها می خواهند اهداف استراتژیک مندرج در نقشه استراتژی سازمان و فرایندهای عملیاتی مستخرج از آنها را بهبود بخشند، لازم است که آنها را قابل اندازه گیری و سنجش نمایند. این کار با استفاده از سنجه های استراتژیک انجام می شود. در واقع با انتخاب سنجه های استراتژیک می توان اهداف استراتژیک را معنادار و اجرایی کرد (Niven, 2006).
سازمان‌ها در مسیر ارتقای سیستم‌های مدیریت عملکرد خود، عموماً این حقیقت را فراموش می‌کنند که اندازه گیری (سنجش)، یک علم است. بنابر این برای استفاده کارا از سنجه ها باید پایه‌های علم اندازه گیری را درک کرد. مفاهیمی مثل دقت، صحت و نوسان در این علم وجود دارد (De Waal, 2001).
اگر مدیران نتوانند مفاهیم پایه ای و اصلی اندازه گیری را به خوبی درک کنند، ممکن است استفاده از سنجه ها نتایج ضعیفی را در سطح سازمان ایجاد کند. مثالی می زنیم. فرض کنید که برای اندازه گیری رضایت مندی مشتریان (به عنوان هدف استراتژیک)، سنجه دفعات خرید محصول، تعریف شده باشد. این سنجه در فصل اول، 50 بار، فصل دوم، 46 بار و فصل سوم سال، 39 بار شده است. واضح است که مطابق این سنجه، کاهش خرید می تواند ناشی از نارضایتی مشتری باشد. طبیعی است که این اعداد باعث نگرانی مدیران شده و آنها را به اقدام وادار کند. اما ممکن است با توجه به تحلیل های سطح صنعت و تحلیل روند فروش سال های قبل، این نوسان طبیعی باشد. به عبارت دیگر مدیران توجه نکرده اند که رضایت مندی مشتریانشان به طور طبیعی بین همین اعداد و ارقام در نوسان بوده است. به عبارت دیگر در این مثال، عملاً اتفاق خاصی نیفتاده و این نوسان طبیعی است و مدیران بدون توجه به اصول علم اندازه گیری و تحلیل روندهای موجود، اقدام به تعریف سنجه کرده اند. بنابر این، برای جلوگیری از هزینه‌های فراوان واحتمالاً بحران‌هایی که از مداخله در بهبود عملکرد ناشی می‌شود، درک سنجه ها و پارامترهای کنترلی، واقعاً حیاتی است (Creelman & Makhijani, 2008).
همانطور که تعداد اهداف استراتژیک باید به حدی باشد که بتوان به صورت استراتژیک روی آنها تمرکز کرد، تعداد سنجه ها نیز باید محدود باشد. شاید برای هر هدف، 2 سنجه کافی باشد یعنی 30 سنجه برای 15 هدف کفایت می‌کند (Niven, 2008).
مدیران می بایست توجه کنند که عموماً سنجه ها در سطح کلان سازمان تعریف می شوند. توجه داریم که یک شرکت ممکن است عملکردش را از راه های مختلفی بسنجد. بنابر این، عملکرد یک قسمت سازمان را نمی‌توان دقیقاً با قسمت دیگر مقایسه کرد. به همین نحو، تعریف سنجه ها نیز در واحدهای مختلف سازمان با یکدیگر تفاوت خواهد کرد. بنابر این، سنجه ها علاوه بر استراتژیک بودن، می-بایست الزاماً با استانداردهای مستند و منتشر شده در سطح عالیه سازمان نیز سازگاری و همسویی داشته باشند (Niven, 2008; Niven, 2006).

4- هدف‌گذاری
همانطور که گفته شد در سیستم مدیریتی کارت امتیازی متوازن، تمامی اهداف استراتژیک باید دارای سنجه های پشتیان باشند. به همین نحو، تمامی سنجه ها نیز باید یک هدف کمّی داشته باشند. تعیین اهداف کمّی، ریشه در بیانیه چشم انداز سازمان دارد. در بیانیه چشم-انداز، مدیریت عالیه سازمان، هدفی بزرگ و آرمانی را برای سازمان تعریف می کند. این هدف بین فرایندهای عملیاتی جاری و آرمان سازمان، شکافی ایجاد می کند که قابل لمس است. استراتژی های سازمان باید به نحوی طراحی و تدوین شوند که بتوانند این شکاف را پر کنند. مدیران ارشد، وظیفه دارند که شکاف ایجاد شده را با تبیین و تدوین اهداف جزئی تر و کمّی تر که منتج از استراتژی های سازمان است، پوشش دهند. بنابر این، اهداف کمّی می تواند تأثیر نسبی لازم برای اجرای استراتژی ها را به صورت عملیاتی بیان کند (Parmenter, 2010; Niven, 2008).
مدیران باید توجه کنند که هدف کمّی یعنی مقدار عملکردی که سازمان باور دارد در دوره زمانی خاص، می بایست الزاماً برآورده شود. باید بدانیم که هدف‌گذاری و پیش بینی کاملاً با یکدیگر متفاوتند. بجارت بوگسنس، یکی از مدیران ارشد شرکتStatoil Hydro  و یکی از تحسین برانگیزترین مجریان کارت امتیازی متوازن، معتقد است که «هدف کمّی و پیش‌بینی، مثل هم نیستند و نباید هم باشند. هدف کمّی، آرزویی است که می‌خواهید به آن برسید. پیش‌بینی، چیزی است که انتظار دارید به آن برسید. بنابر این، برای مدیریت و تعیین آنها باید اعداد متفاوت و فرایندهای متفاوتی داشته باشید. وقتی به صورت مصنوعی، هدف کمّی و پیش‌بینی را با یکدیگر عجین کنید احتمالاً یا هدف کمّی بدی انتخاب کرده اید یا پیش‌بینی داشته اید و غالباً هر دوی آنها» (Creelman & Makhijani, 2008).
اهداف کمّی می بایست انتظارات عملکردی مورد نظر سازمان را به صورت واضح و شفاف نشان دهند. بنابر این، باید مبتنی بر تحلیل عملکرد مورد انتظار و توانمندی‌های داخلی سازمان، ارایه شوند. به عبارت دیگر، اهداف کمّی در سیستم مدیریتی کارت امتیازی متوازن باید تغییرات لازم در عملکرد را نشان دهند. افزایش عملکرد نیز باید با اهداف کمّی در تناسب باشد (Parmenter, 2007).
این مطلب، یکی از ضعف‌هایی موجود در فرایند‌های سنتی هدف‌گذاری را نشان می دهد. کارکنان عموماً نسبت به تحقق اهداف کمّی، خود را مسوول نمی دانند و عملاً به سمت اهداف و آرمان‌هایی تمایل دارند که در دسترسشان قرار داشته باشد. متقاعد کردن کارکنان برای توجه به اهداف کمّی، نیازمند غلبه بر معمولترین معضل پیاده‌سازی کارت امتیازی است؛ فرهنگ سازمانی. مدیران عالیه سازمان نیز وظیفه دارند که با ایجاد زیرساخت های لازم، این حس را به کارکنان منتقل کنند که کارت امتیازی متوازن (خصوصاً اهداف کمّی مندرج در  آن) ناظر به بهبود پیوسته عملکرد و یادگیری است، نه یک سیستم پاداش و تنبیه. اگر کارکنان از اثرات نرسیدن به اهداف کمّی بترسند، به شدت مقاومت می‌کنند و اگر این امر به آنها تحمیل شود همیشه نرسیدن به اهداف را توجیه خواهند کرد  (Creelman & Makhijani, 2008).
نکته آخر اینکه شرکت‌های پیشرو عموماً به انتظارات عملکردی داخلی خود توجه نمی کنند و در عوض، نتایج عملکردی رقبا را مبنای کارشان قرار می دهند. نتیجه آن است که مدیران شرکت به جای آنکه اهداف کمّی داخلی را برآورده کنند، می بایست شاخص هایی را ارتقاء دهند که باعث پیروزی در رقابت خواهد شد. اما گفتن این مطلب از عمل به آن بسیار ساده‌‌تر است (Parmenter, 2007).

5- انتخاب ابتکارات استراتژیک (طرح های ابتکاری)
برای اینکه عملکرد به اهداف کمّی متصل شود و در نهایت، اهداف استراتژیک محقق شوند، به مجموعه اقدامات و فرایندهایی (پروژه هایی) نیاز است که ابتکارات استراتژیک نام دارند. هدف از اجرای ابتکارات استراتژیک این است که شکاف شناسایی شده بین عملکرد واقعی و مورد انتظار (مطلوب) برای رسیدن به یک هدف استراتژیک، پوشش داده شود. معیار اصلی برای انتخاب ابتکارات این است که می بایست مستقیماً به اهداف موجود در نقشه استراتژی متصل شوند. اگر ابتکاری به نقشه استراتژی متصل نباشد به هیچ وجه نباید اجرا یا تامین مالی شود مگر اینکه اتصال آن به نقشه استراتژی به وضوح برقرار شده باشد (Kaplan & Norton 2008).
مطالعات نشان می دهد که اگر کارت  امتیازی به خوبی معماری شده باشد، به راحتی 40 تا80 درصد پروژه‌های جاری، از بین خواهند رفت. لغو پروژه‌های با اهمیت، ممکن است مقاومت مدیریت عالی سازمان را در پی داشته باشد که عموماً حامی مالی پروژه‌ها هستند. اگر بتوان با استفاده از کارت امتیازی متوازن، توضیح داد که چرا ابتکار مطرح شده از نگاه استراتژیک به سازمان مربوط می شود آنگاه می توان مقاومت را کاهش داد. در غیر این صورت، مسولیت مقامات عالی رتبه سازمان، ایجاب می کند که لغو پروژه در دستور کار قرار گیرد. اینجا است که پیچیدگی‌های سیاسی حاصل از چنین دستوراتی، به وضوح نشان می دهد که چرا مقامات عالیه سازمان، نباید به کارت‌ امتیازی متوازن نگاهی سطحی داشته باشند؛ بلکه باید با تمام قوا از آن حمایت کند (Brown, 2007; Creelman & Makhijani, 2005).
طبیعی است که وقتی واحدهای مختلف سازمان روی موضوع مشابهی کار می کنند و از اقدامات یکدیگر اطلاع ندارند، ممکن است ابتکارات دیگری نیز پیدا شود. شفافیت فعالیت‌ها و عملکردی که نتیجه کارت‌ امتیازی متوازن است، مدیران را قادر می‌سازد تا تیم‌های مختلف را دور هم جمع کنند که در نتیجه، تعداد ابتکارات و هزینه‌های مازاد نیز کاهش خواهد یافت (Niven, 2008; Creelman & Makhijani, 2005).
در جدول زیر فرایند شناسایی و گزینش ابتکارات استراتژیک، نشان داده شده است (Creelman & Makhijani, 2008).

 


مراحل

توضیحات

ایجاد فهرستی از تمام ابتکارات استراتژیک سازمان

اولین و اصلی­ترین قدم برای اولویت­بندی ابتکارات استراتژیک، این است که در قالب کارگروه­های منسجم متشکل از مدیران ارشد و میانی سازمان، ابتکارات موجود را شناسایی و فهرست کنید. این فرایند، تمرین ساده­ای است برای شناخت بهتر سازمان. توجه داریم که سازمان­ها ابتکارات زیادی در حال اجرا دارند

ایجاد معیارهایی برای اولویت‌بندی ابتکارات با اهداف استراتژیک مندرج در کارت امتیازی

برای مقایسه ارزش­افزایی ابتکارات، از یک سیستم وزن‌دهی یا امتیازدهی کارا استفاده کنید و سعی کنید که این سیستم را در سازمان­تان، اجرایی کنید

همسوسازی ابتکارات استراتژیک در مسیر اهداف استراتژیک کارت امتیازی

باید با استفاده از سیستم­های پشتیبان تصمیم کارا مشخص کنید که با ارزش‌ترین ابتکارات کدامند و کدامیک می­بایست در مرحله اول اجرا و تأمین مالی شوند

رهاسازی ابتکارات غیر استراتژیک

برای رهاسازی ابتکارات غیر استراتژیک، می­بایست مؤلفه‌های سیاسی مدیریت عالی سازمان را نیز مد نظر قرار دهید

عقلانی کردن تداخل ابتکارات در سازمان

تیم­های به هم پیوسته­ای ایجاد کنید تا کارکنان بتوانند به صورت موازی روی پروژه‌های مشابه کار ‌کنند

واگذاری مسئولیت اجرای ابتکارات

مدیران باید برای ارائه ابتکارات یا اقدامات استراتژیک پاسخگو باشند

ردگیری پیشرفت و تاثیر ابتکارات

پیشرفت را باید ردگیری کنید تا مطمئن شوید که ابتکارات روی اهداف کارت‌ امتیازی تأثیر می­‌گذارند


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
6- چالش‌های اجرایی
هنگامی که نقشه استراتژی و کارت امتیازی متوازن در کلان ترین سطح سازمان طراحی شدند، باید درون سازمان اجرا شوند. باید توجه کرد که همانند تمامی پروژه های سازمانی، اجرایی سازی کارت امتیازی متوازن نیز در ذات خود، چالش‌هایی به همراه دارد که عموماً در دو دسته چالش های ساختاری و چالش های فرهنگی دسته بندی می شوند (Creelman & Makhijani, 2005).
1-6- چالش‌های ساختاری
اگر مدیریت عالیه سازمان بخواهد از همسویی نقشه ها و کارت‌های امتیازی سطوح مختلف سازمان با نقشه و کارت امتیازی سطح کلان سازمان، اطلاع پیدا کند و بداند که آیا می تواند الزامات و نیازمندی های عملکردی واحد مربوطه را تامین کند، آنگاه چالش های ساختاری به وجود می آیند. چالش های ساختاری، ناظر به تعداد کارت های امتیازی و سطحی است که می بایست اجرایی شود. البته تعداد و سطح جاری سازی آنها کاملاً بستگی به استراتژی ها و اهداف سازمان دارد. واحد وسایل نقلیه شرکت Tata Motors حدوداً 350، شرکت StatoilHydro بیش از 700 و شرکت Saatchi & Saatchi فقط یک کارت امتیازی را به کار گرفته اند.
2-6- چالش‌های فرهنگی
علیرغم چالش‌های ساختاری باید گفت که فرهنگ، بزرگ‌ترین تهدید برای موفقیت کارت امتیازی متوزان است. بیشتر کارت‌های امتیازی که به کامیابی نمی‌رسند به علت عامل فرهنگ است. اگر سیستم کارت امتیازی به خوبی اجرایی شده باشد به دو نتیجه مشابه منجر می شود: شفافیت عملکرد و پاسخگویی. این نتایج برای برخی از کارکنان، ایجاد ابهام می کند و برای برخی نیز ترسناک است و باعث می-شود در مقابل آن موضع گیری کنند. این موانع فرهنگی را باید معرفی و بر آنها غلبه کرد.
شناسایی و اعلام این موانع بسیار اهمیت دارد. بسیاری از سازمان‌ها تصیم می‌گیرند که کارت امتیازی متوازن را اجرایی کنند؛ چراکه به دنبال پاسخگویی و شفافیت بیشتری هستند. اما باید ابتدا به الزامات و عادت های فرهنگی خود بیش از پیش توجه کنند. سازمان می تواند تشخیص دهد مقاومت کارکنان، کجا و چرا به وجود می آید که الزامات و زیرساخت های فرهنگ سازمانی خود را به وضوح درک کرده باشد.

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


8- منابع
1)    Achterbergh, J. , Beeres, R. , & Vriens D. (2003). Does the balanced scorecard support organizational viability?, Kybernetes, 32, 1387-1404.
2)    Akkermans, H. , & von Oorschot, K. (2000). Developing a balanced scorecard with system dynamics, Journal of the Operational Research Society, May.
3)    Blokdijk, G. (2008). Balanced scorecard 100 success secrets, 100 most asked questions on approach, development, management, measures, performance and strategy, Emereo Pty Ltd.
4)    Bobillo, F. , Delgado M. , Gómez-Rom J. , & Lo´pez, E. (2009). A semantic fuzzy expert system for fuzzy balanced scorecard, Expert Systems with the Application, 36, 423-433.
5)    Brown M. G. (2007) Beyond the balanced scorecard: Improving business intelligence with analytics, Productivity Press.
6)    Bukh, P. N. , & Malmi, T. (2005). Reexamining cause-and-effect principal of the balanced scorecard, In J Mourtisen, S Jönsson eds. : Northern Lights in Accounting Stockholm, Liber.
7)    Chytas P. (2008). A proactive fuzzy cognitive balanced scorecard, IEEE World Congress on Computational Intelligence Systems.
8)    Cobbold, I. , & Lawrie, G. (2002). The development of the balanced scorecard as a strategic management tool, Presented at PMA Conference, Boston, USA.
9)    Creelman, J. , Makhijani, N. (2008). How leading organizations successfully implement corporate strategy with the balanced scorecard, The OTI Thought Leadership Series, 1, 1-16.
10)    Creelman J. , & Makhijani N. (2005). Succeeding with the balanced scorecard in the mastering business in Asia series, Wiley Executive.
11)    De Waal, A. A. (2001). The future of the balanced scorecard: an interview with Professor Dr Robert S. Kaplan, Measuring Business Excellence, 7, 1, 30-35.
12)    Kaplan R. , & Norton D. (2008). Execution premium, Harvard Business School Press.
13)    Kaplan R. , & Norton D. (2004). Strategy Maps: Converting Intangible Assets into Tangible Outcomes, Harvard Business School Press.  
14)    Kaplan R. , & Norton D. (2000). The strategy-focused organization: How balanced scorecard companies thrive in the new business environment, Harvard Business School Press.
15)    Kardaras D. , & Mentzas M. (1997). Using fuzzy cognitive maps to model and analyze business performance assessment, In Prof. Int. Conf. on Advances Advances in Industrial Engineering Applications and Practice II, Jacob Chen and Anil Milal (eds. ), 63-68.
16)    Linard, K, & Yoon, J. (2000). The dynamics of organizational performance development of a dynamic balanced scorecard, The First International Conference of System Thinking in Management, 359-364.
17)    Nissen, V. (2006). Modeling corporate strategy with the fuzzy balanced scorecard, In: Hüllermeier, E. , Kruse R. , Nürnberger A. , Strackeljan J. , (eds. ): Proceedings Symposium on Fuzzy Systems in Computer Science FSCS 2006, Magdeburg, 121-138.  
18)    Niven P. R. (2008). Balanced scorecard: Step-by-step for government and nonprofit agencies, Wiley; 2 Edition.
19)    Niven P. , R. (2006). Balanced scorecard step-by-step: Maximizing performance and maintaining results, 2 Edition, John Wiley & Sons, 2006.
20)    Parmenter D. (2010). Key Performance Indicators (KPI): Developing, Implementing, and Using Winning KPIs, Wiley; 2 edition.
21)    Smith, R. (2006). Business Process Management and the Balanced Scorecard: Focusing Processes on Strategic Drivers, Kindle Edition.
ارسال شده توسط احمد محمدی | 8 12, 2013 | بازدید‌ها (1923)
پروژه ERP ايران خودرو
تعریف ERP
ERP مخفف Enterprise Recourse Planning بوده و از لحاظ لغوی به معنای برنامه ريزی جامع منابع يك سازمان مي باشد. در زير سه تعريف از ERP بیان شده است:
    يك راه حل مبتني بر فناوری اطلاعات است كه تمام منابع سازمان ) مواد اولیه ، ماشین آلات ، نیروی انساني و پول (را توسط يك سیستم به هم پیوسته با سرعت، دقت و كیفیت بالا در كنترل مديران سطوح مختلف قرار مي دهد تا مديران بتوانند بطور مناسب فرآيند برنامه ريزی و عملیات سازمان را مديريت نمايند.

    يك نگرش فناورانه و سیستماتیك برای مديريت موثرتر تمام منابع در يك سازمان است كه اين مديريت از طريق اتوماسیون و يكپارچه كردن تمام فرآيندها و در نتیجه بالا بردن كارايي سازمان ها اعمال مي شود.
    ERP  يك بسته كامل نرم افزاری كاربردی درون سازماني ، جامع و سازمان نگر ، ماژولار ، استاندارد و شامل يك مجموعه از ماژولهای يكپارچه ، آماده راه اندازی ، از پیش طراحي شده و از پیش مهندسي شده ولي قابل تنطیم و منعطف ،پیكر بندی بر اساس نیازهای پويای سازمانها مي باشد. اين راه حل كاملا انعطاف پذير ، فرايندگرا و اطلاعات محور مي باشد و شامل كلیه فعالیتها و فرايندهای اصلي و موثر در ايجاد ارزش افزوده سازمان مي باشد . فرايندهای از پیش تعريف شده در سیستم بر اساس بهترين تجارب دنیا ( (Best practiceاستخراج شده اند.

ضرورت نیاز به ERP در سازمان ها
    افزونگي حجم اطلاعات و نیاز به مدیریت اطلاعات به منظور یكپارچگي، امنیت و در دسترس بودن اطلاعات
    پیچیده شدن فرآیندهاي كاري و نیاز به استفاده از Best Practice هاي دنیا
    محدودیت منابع (4M : Material, Money, Machine, Man) و نیاز به برنامه ریزي منابع
    رقابت شدید نیازمند بستري است كه مدیران بتوانند به سرعت تصمیم گیري نمایند و این كار بدون داشتن اطلاعات به موقع، صحیح و دقیق امكانپذیر نیست. همچنین براي رقابت، نیاز به امنیت اطلاعات در سازمان كاملا ضروري است.
    افزایش فعالیتها و به طبع آن مدیریت سازمان نیازمند وجود سیستمي است كه به آنها كمك كند شرح وظایف هر شخص با توجه به فعالیتها شفاف گردد و از تداخل كاري و دوباره كاریها جلوگیري نماید.
    نیاز به مدیریت عملیاتي سازمان كه این سیستم ها امكان مونیتور كردن فعالیتها را براي مدیران سازمان به منظور مشخص و برطرف نمودن گلوگاههاي كاري ارائه مي دهند.
    ایجاد استانداردهاي كاري و اطلاعاتي در جهت افزایش كیفیت ، كاهش قیمت تمام شده و متعاقب آن رضایت مشتریان
    نیاز به توسعه در سازمان و در همین راستا، وجود سیستمي انعطاف پذیر كه توسعه و بهبودهاي سازمان را به راحتي پشتیباني كند.
    پرستیژ كاري براي سازمان. عملا وجود چنین سیستمهایي در هر شركتي به مشتریان ، پیمانكاران ، تامین كنندگان اطمینان خاطري را القا مي كند.
    ایجاد بستري براي پیاد هسازي سیستمهاي ارتباط با مشتریان و پیمانكاران (CRM, SRM)
    ایجاد بستر اطلاعاتي مناسب براي پیاده سازي سیستمهاي پیشرفته مدیریتي مانند :
    هوش تجاري  Business Intelligence
    مدیریت استراتژیك  Strategic Enterprise Management
    سیستم هاي تصمیم گیري  Decision Making
    مدیریت عملكرد  Performance Management
    مدیریت دانش  Knowledge Management
    بدون پیاده سازي ERP ، عملا پیاده سازي موثر سیستمهاي فوق عملا امكانپذیر نمي باشد.
    ایجاد بستري براي وارد شدن به بحث هاي دهكده جهاني )مباحث e-Business ، Core Banking  )
مزایا و ارزش افزوده حاصل از پیاده سازي ERP
    یكپارچگي روال ها و فرایندهاي عملیاتي و استاندارد كردن فعالیت ها
    یكپارچگي اطلاعات سازمان - ایجاد هماهنگي اطلاعاتي
    قابل دسترس بودن، سرعت و امنیت اطلاعات
    به روز بودن اطلاعات
    بهبود فرآیندها و مهندسي مجدد
    بهبود چارت سازماني
    ایجاد فرهنگ سازماني - بوجود آوردن هماهنگي و هم زباني دركل سازمان
    ایجاد محیطي منعطف در برابر تغییرات سازمان
    استاندارد سازي فناوري اطلاعات و زیر ساخت هاي استفاده شده
    كاهش خطاها به كمك همگرایي سیستم ها
    هم راستا نمودن ماموریت سازمان و فناوري اطلاعات
    كاهش دوباره كاري ها
    كاهش هزینه و زمان توسعه سیستم هاي اطلاعاتي
    امكان برنامه ریزي منابع سازمان
    امكان تهیه انواع گزارشات داینامیك
    امكان محاسبه KPI هاي سازمان و تهیه انواع داشبوردهاي مدیریتي
    سهولت در امر پشتیباني به دلیل عدم وجود Bug و Error
    امكان مونیتور كردن تمامي فعالیت ها
    استفاده از Best Practice هاي دنیا در جهت بهبود فرایندهاي كاري و چارت سازماني

کاهش قیمت تمام شده
 

 
انواع ERP
 
مقایسه انواع ERP
 
تاریخچه SAP
شرکت SAP در سال 1972 در آلمان با چشم انداز ایجاد و توسعه یک نرم افزار کاربردی استاندارد برای پردازش اطلاعات یک سازمان در تاسیس گردید. در حال حاضر SAP جایگاه نخست را در بین رقبای تامین کننده ERP در سطح دنیا دارا می باشد. این شرکت با داشتن 53 هزار کارمند در سطح دنیا و 109 هزار مشتری در 120 کشور و گردش مالی 12464 میلیون یورو در بین بهترین شرکتهای دنیا رتبه 12 را به خود اختصاص داده است. در حالیکه بسیاری از بهترین شرکتهای دنیا در صنایع مختلف کسب وکار خود مشتری SAP  میباشند.
 

استفاده بهترین ها از SAP
 
مزایای پیاده سازی SAP در شرکتهای خودرو ساز
ارزش افزوده
 
 
 
چرا SAP ؟
 

متدولوژی پیاده سازی SAP:
ASAP Methodology
 
بررسی عوامل موفقیت و شکست پروژه های SAP:
    عدم حمایت موثر و به موقع مدیریت ارشد سازمان- Very High
    مقاومت سازمان در مقابل تغییر–  Very High
    عدم حمايت و همكاری مديران ارشد–   High
    عدم تخصیص مشاوران مناسب SAP-  High
    عدم تجربه كافي مدير پروژه–  High
    عدم تخصیص Key User های مناسب–  High
    عدم وجود  Clean Data-  Very High
    ايجاد استثنا های غیر منطقي به عنوان رويه سازمان–   High
    عدم آموزش مناسب كاربران كلیدی–   Very High
    عدم آموزش مناسب كاربران نهايي-  Very High
    طسوت يفاك نامز صیصخت مدع Key user ها-  Medium
    درخواست تغییرات بنیادی در فرايندهای استاندارد سپ- Medium
    تغییر اعضای تیم key User يا مشاوران SAP - Medium
    عدم تهیه داده های مورد نیاز در زمان مقرر- Medium
    آماده نبودن محل پروژه-Low
    آماده نبودن بستر سخت افزاری ) سرور ، اينترنت و .... )- Low
    تغییر در اسكوپ قراردادی Low–
اشاره
يكى از شركتهاى بزرگ كشور كه اقدام به پياده سازى ERP نموده شركت ايران خودرو مى باشد كه محصول شركت SAP  را خريدارى كرده است. به منظور آگاهى از مراحل و چگونگى  نجام اين كار گفت وگويى با مديران پروژه، آقاى دكتر اقدسى و آقاى مهندس تجعفرى انجام داده ايم.
از نگاه شما ERP  یا سيستم هاى برنامه ريزى منابع سازمانى چيست؟
دكتر اقدسى: كاربرد رايانه در كسب و كار سابقه ای طولانى دارد. كسب و كارها نيز بخش های مختلفى دارند كه رايانه مى تواند در آنها موثر واقع شود. سابقة كمك رايانه در حوزۀ برنامه ريزى به حدود 30 يا 40 سال پيش برمى گردد. در آن زمان نرم افزارهايى ارائه شد كه برنامه ريزى(MRP)  احتياجات نام داشت. توليد به عبارت ديگر، اين نرم افزار ها، نيازمندی های اصلى براى توليد يك سازمان را برنامه ريزی و زمان بندى مي كرد. مهم ترين منابع براى يك خودروساز، قطعات و تجهيزاتى است كه بايد به هم وصل شوند تا يك خودرو ساخته شود. اين منابع به علاوۀ منابع انسانى، اگر از طريق برنامه ای مناسب با همديگر به كار گرفته شوند، خودرو توليد خواهد شد. برنامه ريزی تركيبي تمام نيازمندی های مواد، قطعات و نيروی انساني مستلزم نرم افزارهای رايانه ای است. اولين بار از رايانه براى برنامه ريزى در قسمت های توليدی شركت ها استفاده شد. پس از آن، اين كاربرد گسترده تر شد و رايانه توانست تمام منابع سازمان را با جزئيات كامل دربرگيرد. يعني دامنة كاربرد كامپيوتر براى برنامه ريزى در ساير حوزه هاى سازمان نيز گسترش يافت. به عنوان مثال، براى حوزه هاى مالى، فروش، منابع انسانى و... كامپيوتر به كار گرفته شد. البته، بديهي است كه برنامه ريزی بدون كنترل در اجرا و بازخورد برای برنامه های بعدی معنايي ندارد. در ابتدا، هر كدام از اين حوزه ها متناسب با نياز
خاص خود برنامه ريزى شدند. بنابراين، نرم افزارهاى مختلفى براى اين كاركردها توسعه يافت و انواع نرم افزارهاى مالى، انواع نرم افزارهاى فروش، انواع نرم افزارهاى مرتبط با منابع انسانى توسعه پيدا كردند. اما، شركت ها به صورت يك مجموعه نياز داشتند كه اين نرم افزارها و تسهيلات رايانه ای با همديگر ارتباط داشته باشند تا اينكه سازمان از يكپارچگي منطقي سود ببرد. در غير اين صورت، عدم همخواني اطلاعات نه تنها امر تصميم گيری صحيح را ناممكن مي سازد. بلكه، انجام عمليات ارائه خدمت را نيز با اختلال و اشكال مواجه مي كند. به عنوان مثال، يكي از نمايندگي های خدمات پس از فروش ممكن است مدت ها از تغيير يكي از قطعات توسط سازندگان قطعه اطلاع نداشته باشد و نتواند در ارائه خدمت مناسب موفق عمل كند.
به همين دليل، برنامه هايي كه در قسمت های مختلف يك بنگاه اقتصادی به كار گرفته مي شود بايد ضمن انجام يك عمليات مستقل، در يك حوزۀ خاص نيز پاسخگوی كارگر، كارمند و مدير باشند. بايد با همديگر تبادل اطلاعات كنند و اطلاعات فرايندهايي كه توسط آنها به روز و يا كامل مي شود، يكپارچه باشد. به عنوان مثال، اگر مهندس طراح قطعه ای را برای عملكرد بهتر تغيير داد. اطلاعات قطعه جديد تنها در برنامة واحد مهندسي وارد نشود. بلكه اين تغيير در برنامه های مورد استفادۀ بخش توليد، فروش و نمايندگي ها و خدمات پس از فروش نيز تأثير گذار باشد.
برای اين كار تنها برقراری ارتباط بين اين برنامه ها كافي نيست. بايد تمام اين برنامه ها از منابع داده ای يكسان تغذيه كنند و عمليات و كارهای واحدهای مختلف مطابق با وظيفه خاص آنها انجام شود و تغييرات و تأثيرات خود را بر اين پايگاهای اطلاعاتي مشترک بگذارد. اگر برای اطلاعات پايه ای شركت از پايگاه های داده ای متفاوتي استفاده شود.
به عنوان مثال، فرض كنيد پايگاه داده ای مشترى در بخش فروش و نمايندگي ها با همديگر متفاوت باشد. در آن وقت ممكن است كه يكي از مشتريان برای انجام گارانتي به يكي از نمايندگي ها مراجعه كند اما، به دليل اينكه نام او در فهرست مشتريان نمايندگي ها وجود ندارد، او نتواند سرويس گارانتي را دريافت كند. نام اين مشتری بايد در ليست فروش، تعميرات، قسمت مالى، قسمت تعمير و تدارک و... وارد شده باشد.
اين فهرست به يك باره تهيه نشده است و ثابت نمي ماند بلكه، در طول زمان دستخوش تغيير مي شود و اگر از جايي تغذيه نشود مشكلات اساسي براى كسب و كار پيدا مي شود. در واقع، موضوع تنها به اطلاعات و كامپيوتر مربوط نمى شود بلكه، فرايندهاى  انجام كار، كه بسيارى از بخش هاى آن توسط رايانه انجام مى شود، بسيار اهميت دارد.
نرم افزارهاى ERP  در نتيجة اين فكر به وجود آمده اند كه فرايند هاى كسب و كار همراه با يك سيستم رايانه ای يكپارچه كه داراى پايگاه اطلاعاتى ERP مركزى است، انجام گيرد. اين روند شكل گيرى است وشركت هاى نرم افزارى كه در تمام اين مراحل، با كسب و كارهاى مختلف همراه بوده اند و نرم افزارها را توسعه داده و انواع خدمات رايانه ای را به آنها ارائه دادند، يك تجربه غنى از كسب و كارهاى مختلف را به دست آوردند و توانستند بهترين فرايندهاى آن شركت ها را آن كه) Best Practice عده ای آن را به روش مى نامند). ناميده مي شود در نرم افزارهاى ERP خود لحاظ كنند. بنابراين، نرم افزار هاى ERP ها مى توانند با يكديگر تفاوت BP از نظر توجه به زيادی داشته باشند.
استقرار و پياده سازى ERP براى شركت ايران خودرو چه ضرورت، منافع ومزيت هايى دارد؟
مهندس تجعفرى: زمانى كه من برای انجام اين پروژه به ايران خودرو منتقل شدم، درخواست مديريت ارشد، تنها راه اندازى نرم افزار نبود. در واقع، مأموريت من انتقال اين تكنولوژى به مملكت بود و نه يك نرم افزار. اگر شما از تيم هاى نرم افزارى در خارج از كشور بازديد كنيد متوجه مي شويد كه مهندسان موفقي در ميان آنها وجود دارند كه توسعه دهندۀ نرم افزار ايرانى هستند. در ايران نيز مهندسان فارسى زبان ايرانى زياد هستند. تفاوت در چيست؟ به خاطر دارم كه در يك جلسه بحث شد كه آيا ERP  ؟ خوب است يا خير؟ SAP خوب است يا خير؟ از اين سيستم استفاده بكنيم يا نه؟ من گفتم نمى توانم در يك جلسه كوتاه جواب بدهم و بگويم چه منافعى را به همراه دارد. اما، سوأل اين است كه چرا براى چيزى كه به نظر شما خيلى مفيد نيست به مدت 3 سال در تحريم خريد بوديم؟ در حال حاضر نيز، به ازای هر قدمى كه در راستای اين پروژه برداشته مي شود با موانع و تحريم های زيادی روبرو هستيم. به طورى كه براى آوردن يك Tools استقرار (Solution Manager)  بيشتر از يك سال زمان صرف شد تا به ايران آورده شود. با وجود اينكه، بر اساس قرارداد با SAP  هزينه ای ، را نيز در بر نداشت.
دكتر اقدسى: در صنعت خودروسازی برای مدت زيادى پيش از انقلاب و مدتى هم بعد از انقلاب صرفاً يك مونتاژكنندۀ ساده بوديم. بيشتر از يك دهه است كه خودروسازى ايران نيز در يك مسير صعودى به سمت خودرو ساز شدن در انداه های جهاني گام برداشته است. ما براى انتقال تكنولوژى در حوزه های متعددی با خارجى ها ارتباط داشتيم و همواره در فراز و نشيب هاى تحريم و موانع قرار گرفته ايم. اما، هيچ وقت در تحريم هاى سخت افزار هاى صنعتى به اندازۀ نرم افزار مشكل نداشتيم. يعنى، در زمينة تكنولوژى هاى نرم حساسيت وجود دارد اما، در مورد سخت افزار اين گونه نيست.
مهندس تجعفرى: در حال حاضر، در اين شركت مشاهده مى كنيد، ماشين هايى (تجهيزات خطوط توليد) وجود دارد، زماني كه مشاوران آلماني پروژۀ استقرار آنها را ديدند، تعجب كردند كه ما چقدر در تكنولوژى سخت افزار پيشرفت كرده ايم. امكان تهيه كتاب در مورد هر موضوعى نيز به راحتي فراهم است. پس جای چه چيزى خالي است؟ در ايران، وضعيت سخت افزارى خوب است و اطلاعات را نيز دريافت مي كنيم اما، به نظر من بايد به مدل كسب و كار دست يافت. دانشى كه با ابزارى مانند ERP وارد مملكت مي شود. به عنوان مثال، چگونه مي توان برنامه ريزى كرد تا سمند را بتوان 8 ميليون تومان فروخت. يكى از وضعيت هاى رقابتى ما با دنيا ارزان بودن نيروى انسانى در ايران است. هزينة نيروى انسانى در ايران فوق العاده پايين و قيمت مواد اوليه خيلي بالا است. بر خلاف آنچه كه درساير كشورها وجود دارد. حال، چرا آنها از ما جلوتر هستند؟ چرا ما نمى توانيم به عنوان مثال با تويوتا رقابت كنيم؟ چرا كل طول دوره توليد آنها فقط چند روز است و مدام در حال كاهش آن هستند؟ قطعات (مواد اوليه) يكى از مولفه هاى مهم در قيمت تمام شده خودرو است. آنچه كه باعث افزايش قيمت مواد اوليه مي شود، انبار است. چگونه مى توان هزينه انبار را كاهش داد؟ چگونه مي توان پول را در گروه مديريت كرد؟ يكي از امكانات مورد نياز مديران، ابزارهايى براى اجراى اين نوع كارها است تا آنها بتوانند قيمت تمام شده را كاهش دهند.
آيا ايران خودرو نمى تواند شركت يا شركت هاى داخلي را برای ايجاد چنين امكاناتى انتخاب كند تا آنها با كمك دانش خودروسازى و مدل هاى كسب و كار خودروسازى معروف دنيا كه توسط مشاورين بين المللى قابل دستيابى پروژه را اجرا نماييد؟
مهندس تجعفرى : ERP  يك روش تهيه دانش مدل كسب و كار خودروسازى است.
دكتراقدسى: فرايند و تكنولوژى manufacturing يا ساخت با فرايند و تكنولوژى توليد متفاوت است.
تصور عموم بر اين است كه تكنولوژى ساخت دشوار است. در صورتى كه دشوارى مهم تر تحصيل تكنولوژى توليد است كه بدون فرايند هاى تأمين و فروش كه داراى تكنولوژى هاى نرم است مقدور نمى باشد مشكل موجود در خصوص مسأله برنامه ريزى تأمين تكنولوژى است.
يك سر فرايند توليد را بازار و مشترى تشكيل مي دهد كه نزديك به چند ميليون نفر ذينفع دارد. حوزۀ فروش مركزى، مناطق فروش و نمايندگى هاى فروش، خدمات و تعمير گاه ها در يك سوی فرايند توليد قرار دارند و در طرف مقابل، پس از كارگاه بدنه و پرس، نزديك به چند صد شركت تأمين كنندۀ قطعات قرارگرفته اند. اكنون، در نظر بگيريد كه به عنوان مثال، قصد داريم به مشترى بگوييم كه با هر مدل و رنگ و آپشن كه مايل باشى مي توانيم در مدت چند روز آن را توليد كنيم. علاوه بر اين، نمى خواهيم ميزان انبار قطعات نيز از دو سه روز تجاوز كند. چگونه مى توانيم در برابر تقاضاهاى متنوع مشتريان، بدون هزينه هاى اضافى براى تأمين قطعات، پاسخگو باشيم. در اينجا بايد در نظر گرفت كه قطعه ساز نمي تواند هر لحظه تغييرات عجيب و غريب را در توليد خود اعمال كند.
و لازم است كه توليد صرفة اقتصادی داشته باشد. در اينجا تكنولوژى نرم كه همان  BP ها يا به روش هاى  فرايندهاى تأمين به موقع(Just In Time)  هستند به كمك ما مى آيند.
آيا اين تكنولوژى و نرم افزار با استقرارى كه شما مطرح مي كنيد، به هم پيوسته هستند يا اينكه قابليت جداشدن از همديگر را دارند؟
دكتراقدسى : سيستم تأمين شامل سه جزء اصلى است. يك نرم افزار كه به شما اين قابليت را مي دهد كه ارتباط برقرار كرده و بتوانيد برنامه را بسازيد. جزء دوم، نيروى انسانى و جزء سوم نيز ساختار ها و مدل هاى تجارى شركت هاى تأمين كننده است. يعنى نرم افزار در چهارچوب مدل هاى تجارى و دانايى نيروى انسانى تكنولوژى نرم تأمين را تشكيل مى دهند. بنابراين، ما در پياده كردن SAP  تنها قسمت نرم افزار را پياده نمى كنيم. اگر اين چنين بود، سخن شما درست بود. ما در اين سيستم به نيروى انسانى، چگونه كار كردن او، چگونگي برقراری ارتباط و برنامه ريزى كردن او توجه مي كنيم و مدل تجارى شركت و تأمين كنندگان بر اساس دانايى ها و تجارب فرايند های برتر در صنعت خودرو (BP) شكل مى گيرد.
منظور شما از  "ما "چه كسي است؟
دكتر اقدسى: در پروژه SAP مجموعه تمهيداتى را براى دو تيم اصلى داريم؛ يك تيم مشاور كه بيشتر ساختار نرم افزار را درک مى كند و با استفاده از تجارب پياده سازى متوجه مي شود كه چگونه بايد مولفه های نرم افزار را براى نياز يك خودرو ساز شخصي سازی كند. تيم ديگر متشكل از افراد شركت ايران خودرو هستند كه كه با فرايند هاى فعلى ايران خودرو را به 8 ماه در - خوبى آشنايي دارند. اين دو تيم به مدت 9 كنار همديگر كار مى كنند تا تمام فرايند هاى مورد نظر را كه در دامنة پروژه قرار دارند بر اساس BP ها و با جزييات ممكن و خاص ايران خودرو در نرم افزار تعبييه شود. با اين رويكرد، در كنار پياده كردن نرم افزار، نيروى انسانى نيز پرورش يافته و به عنوان مثال، مى داند كه براى سفارش بايد چه كند؟ يعنى فرايندها، و ترتيب آنها و ظرافت كارى هاى فرايند سفارش را در كنار پياده كردن نرم افزار ياد مى گيرد. اين موضوع تجارب SAP بسيار مهم است كه از طريق پياده سازى را به ايران خودرو مى آوريم و نيروى انسانى (BP) برتر ياد مى گيرد كه روش هاى كار را با آن هماهنگ كند.
آيا بايد اين نرم افزار را الزاما از SAP  خريد يا اينكه مى توان مانند ساير تكنولوژى ها دانش فنى را تهيه و نرم فزار را ايجاد كرد؟
مهندس تجعفرى: فكر نمى كنم كه تنها راه آن خريد ERP باشد. موضوع فقط منفعت- هزينه است. داستان نوشتن ERP هايى كه گاهى در ايران طرح مي شود- با احترام نسبت به همة همكاران صنعت IT - اما، من نمى دانم كه آنها چگونه دانش Best Practice  مورد نياز را فراهم كرده اند. قرار نيست همان مدلي را كه ما كار مى كنيم آنها كد كنند. قرار است BPR انجام بدهند. يك روش اين است كه به جاى اينكه من فرايند را تدوين كرده و آن را بهبود دهم، يك مدل پيشرفته تمام شده را انتخاب كرده و از آن استفاده مي كنم. اين در حقيقت دانش مدل كسب و كار پيشرفته است كه به نرم افزار تبديل شده و اين نرم افزار وجود دارد.
اين "ما" يى كه آقاى دكتر بيان كردند،  معمولاً براى شروع پروژه يك تيم استقرار دهنده (Implementer) استفاده مي شود. ما اين سرويس را طي قرارداد با يك شركت آلمانى در اختيار گرفتيم. كار اين تيم، استقرار سيستم است.
روش ما به اين صورت است كه تعدادی كارگاه برگزار مي شود كه در آنها مدل هاى كسب و كار استاندارد سيستم ارائه مي شود. سپس، برخي از شاخص هاى اندازه گيرى توافقى فرايند بايد تعريف شود و سپس، آنها را برای فرايندها اندازه گيری مي كنيم. فرض كنيد فرايند دريافت كالا تا پرداخت فاكتور در ايران خودرو 12 روز و در ERP سه روزطول بكشد. برای رسيدن به سه روز ، بايد تغييراتي صورت پذيرد كه كمي هزينه دارد. اين هزينه به اين بستگي دارد كه شما مى خواهيد شاخص اين فرآيند را به چند برسانيد. پس از تصميم گيری در مورد ميزان تغيير شاخص (با توجه به هزينه آن) در فاز بعدی، سيستم براساس اين شاخص ها و مدل ها، بومي مي شود. يكى از فازهاى پروژه، فاز طراحى است كه در واقع در آنجا همين بحث ها مطرح مي شود. كه البته مهم ترين فاز پروژه نيز تلقي مي شود. زمانى كه اين طراحي به تمام شد، مي توان فهميد كه بعد از استقرار ERP  كجا خواهيم رسيد.
با اين توضيح زماني كه پروژه تمام شد، ما مدل های كامل به Best Practice نرسيده ايم (يعنى تقريبا هيچ جا نمى رسند)، اما، تغييری كه در سازمان اتفاق افتاده است نشان دهندۀ جهش است. باقي آن را مي توان در مرحله بهبود مستمر انجام داد. برای همين ما يك تيم كارشناسي در كنار مشاوران خارجى پرورش داديم تا آنها در ادامه مسير نقش متولي كار را بر عهده بگيرند.
مشاوران استقراردهنده اروپايي نيستند و در كشورهای ديگر مانند كشورهای آسيايي نيز وجود دارند. موضوع خريد سيستم و استقرار آن دو موضوع است و مي توان سرويس استقرار را از شركت های غير از توليد كننده سيستم دريافت كرد.
دكتر اقدسى: من يك توضيح در مورد اين تيم بدهم. اين تيم جداى از پرسنل بيزينس نبوده است. ما بخش مالى را كه پياده كرديم، حدود صد نفر از پرسنل مالى در اين تيم بودند و فقط هشت نفر افراد ثابت پروژه بودند. بقيه از افراد شاغل در فرايند مالى چهار شركت ايران خودرو، ايران خودرو خراسان، ايساكو و ساپكو بودند، كسانى كه كارشان را دارند و در پروژه نيز نقش مهمى به عهده آنها است به طورى كه موقعيت يادگيرى فرايند BP  براى آنها فراهم است. بنابراين تيمى كه گفتم منظورم دكتر اقدسى، مهندس تجعفرى و پنج شش نفرى كه با آنها كار مى كردند نبود.
سوال من اين است كه آيا بايد نرم افزار حتماً از SAP مى آمد؟ يا همان طور كه شما بيان كرديد تكنولوژى آن كه وجود داشت، اين امكان بود كه با استخدام گروهي از مشاوران نرم افزار مورد نياز در داخل كشور نوشته شود.
همان طور كه ما از سال 47 تاكنون هزينه كرده ايم و مانع از واردات شديم تا شما خودروساز شويد. شما هم تحمل مى كرديد تا ما توليدكننده نرم افزار شويم؟
مهندس تجعفرى: مدت زمان اين كار مهم است. به عنوان مثال، مى توان يك ماشين را از پايه طراحى كرد. همان طور، كه چند سال طول كشيد تا سمند طراحي و توليد شود. اين يك روش كار است. روش ديگری نيز وجود دارد. فرض كنيد چند سال مدت زمان زيادی است و قصد داريم در يك زمان كوتاه تر ( به عنوان مثال پژو 206 ) را راه اندازی كنيم. پژو 206 نيز را مي توان مانند سمند توليد كرد. در واقع مى توان تكنولوژى در بحث IT  نيز به همين شكل است. را وارد كرد. يعني، بايد در نظر گرفت كه مي خواهيد چقدر زمان و هزينه صرف كنيد.
بحث شدن يا نشدن نيست. اگر ما از سال47 دروازه ای كشور را به روى واردات بستيم تا ايران خودرو، خودروساز شود و بتواند سمند توليد كند. چرا نمى توان همين اقدام را تكرار كرد تا ما نيز نرم افزار در سطح جهانى توليد كنيم و Best Practice داشته باشيم؟
مهندس تجعفرى: چرا شما به عنوان متوليان IT ايران چنين كاری را انجام نمي دهيد؟ سوال من نيز همين است، چرا اين كار را انجام نمي دهيد؟ چرا بايد از آلمان متخصص آورده شود؟ چرا بايد پول مملكت را به متخصصان خارجى داد؟
دكتر اقدسى: شما عضو يك گروه نرم افزارى هستيد و تصور مي كنيد كه بنده نيز در طرف ديگر، عضو گروه خودروسازها هستم و سوال مي كنيد كه چرا براى حمايت از نرم افزار هاى داخلى اقدام مهمى صورت نگرفته است؟ اول اينكه، من در جايگاه تصميم سازى هاى كشور براى صنعت نرم افزار نيستم. شما مى توانيد از مسئولان مربوط به آن پاسخ مناسبى دريافت كنيد. من، به عنوان يك مدير شاغل در خودروسازى، نظر خود را با شما در ميان مي گذارم.
در فضاى اقتصادى كشور، صنايع مختلفى فعال هستند. متوليان اين صنايع با نيروهاى تصميم گير كشور ارتباط
برقرار مى كنند تا به عنوان مثال، قانوني را تصويب كنند يا نكنند؟ اين موقعيت براى همة صنايع وجود دارد. بديهي است خودروسازان در برابر توليد كنندگان نرم افزار نايستاده اند. اگر لازم است حمايت شوند بايد خود آنها اقدام كنند.
از زاويه ديد يك دانشگاهى - نه از زاويه ديد يك خودروساز - نيز مي توان در مورد انتقال تكنولوژی و سياست ها و دشواری های آن صحبت كرد. انتقال تكنولوژى رابطة بسيار نزديكى با نوع تكنولوژى دارد و تكنولوژى هاى نرم افزارى و انسانى پيچيده ترين تكنولوژى ها به شمار مي روند. اگردقت كرده باشيد بيشتر اوقات شنيده مي شود كه مى گويند ما مشكل مديريتى داريم. عده اى ممكن است تصور كنند كه ما مشكل مديران را داريم. در صورتى كه مشكل مديريتى است و نه مشكل مديران! مديران باهوش و خلاق بسياری وجود دارند. مديرانى كه با متغيرهاى بسيار زياد و در شرايط نامطمئن تصميم مى گيرند و مسائل را حل مى كنند. به طور قطع، اين مدير در فضايي قرار مي گرفت كه همة متغيرهاى لازم برای اعمال مديريت وجود نداشت و اگر تعداد زيادی از متغير ها توسط سيستم مديريت ارائه مي شد مي توانست عملكرد بهتری داشته باشد. بنابراين، سيستمى مورد نياز است كه مدير را حمايت كند. به عبارت ديگر، سيستم های مديريت يك تكنولوژى است. با پياده سازى فرايند هاى BP  تكنولوژى مديريت وارد كشور مى شود.
تكنولوژى مديريت با تكنولوژى ساخت تفاوت دارد. براى تهية نرم افزار ها به دانش كامپيوتر و به دانش فنى مرتبط با كاربرد آن نرم افزار نياز است. اين دانش فنى پشتوانة آن نرم افزار است. پشتوانة نرم افزارى كه پزشكان با آن مي توانند به راحتي كار كنند، دانش پزشكى است. بنابراين، هر نرم افزارى يك پشتوانه دارد. پشتوانة نرم افزارهاى ERP نيز تكنولوژى مديريت است كه در گروه دشوارترين تكنولوژى ها قرار مي گيرد. شركتى مانند SAP  طي دو يا سه سال براى ادارۀ كسب و كار نرم افزار ساخته نشده است بلكه، نزديك به 40 سال است كه تلاش مي كند تا راه حل هاى برنامه ريزى، مديريت و فرايند هاى كسب و كارهاى مختلف را در نرم افزار هاى ERP پياده كند.
در حال حاضر پروژۀ ايران خودرو در چه مرحله اى قرار دارد؟ به نظر شما، آيا نمى توان اعضاء تيم فعال در آن را از ميان شركت هاى داخلى انتخاب كرد؟
مهندس تجعفرى: قرارداد دوم استقرار با يك شركت داخلى منعقد شده است. قرار نيست كه ما همه متخصص عملياتي ،ERP كاره باشيم. در بحث استقرار كه - (Change Management) مديريت تغييرات يكي از حساس ترين قسمت های استقرار است - وجود ندارد. از خارج نيز نمى توان دعوت به همكاری كرد و ظاهراً كسي هم نيست كه حاضر باشد در اين زمينه تلاش كند و متحمل زحمت بشود.
براى پياده كردن نرم افزار چقدر هزينه شد؟
مهندس تجعفرى: هزينه استقرار بيشتر از خريد است. نزديك به 2 سال طول كشيد تا بخش مالى استقرار پيدا كرد.
گمان مى كنيد در چه زمانى كل پروژه ERP درگروه صنعتى ايران خودرو مستقر مى شود؟
مهندس تجعفرى: تعداد زيادی شركت وجود دارد. به عنوان مثال، استقرار سيستم در كارخانه ال90 (تندر90 ) تا هفت ماه آينده به پايان مى رسد. اين قرارداد با يك شركت داخلى منعقد شده است.
دكتر اقدسى: از دو سال قبل بخش مالى چهار شركت آغاز شده است كه در حال حاضر به پايان رسيده است. در ايران بى سابقه است كه شركت هايى كه از قانوني مستقل اما، به يك بنگاه اقتصادى متعلق هستند و در يك زنجيره ارزش با همديگر داد و ستد دارند، بر روى يك زير ساخت مالى و نرم افزارى فعاليت كنند.
اين كه ERP نيست. زيرا تنها بحث مالى را  پوشش مى دهد!
مهندس تجعفرى: اين نمونه مانند ساختماني است كه تاكنون، پاية آن ساخته شده است. استقرار دو مدل دارد:
مدل يكجا (Big Bang) و مدل مرحله به مرحله ، .(Step By Step)
در ايران خودرو با توجه به بزرگي شركت (كه معمولا شركت هاى بزرگ به اين روش عمل مي كنند)، مدل مرحله به مرحله پياده مي شود. ابتدا، از مالى شروع شد و براى قسمت های اصلى گروه به اضافة ايران خودرو ( پنج مجموعه) استقرار داده شد.
حال اگر بخواهيد در همين پنج مجموعه را پياده كنيد، چقدر طول ERP ساير اجزاى مى كشد؟
مهندس تجعفرى: اين موضوع به پروژه ها بستگى دارد.
دكتر اقدسى: اگر زمان پروژۀ مالى در اين پنج تا شركت را در نظر بگيريد متوجه مي شويد كه دو قسمت دارد. زمان خالص انجام كار و زمان هم سو سازى بين ذينفعان. به عنوان مثال، ممكن است تمام ماژول هاى مورد نياز اين پنج شركت، پانزده پروژه و زمان خالص آن كمتر از دو سال باشد. اما، اگر ساير زمان ها را به آن اضافه كنيم بيشتر از دو سال خواهد بود. حتى، در اين پروژه مالى دو قسمت وجود داشت. يكى، از جنس اول كه شايد كمتر از هفت ماه بود و ديگرى از جنس دوم كه وقتى در كنار آن قرار گرفت نزديك به دو سال طول كشيد. جنس دوم از اين نوع است كه شما مى خواهيد در مورد سهم تصميم گيری، نوع و ميزان تصميم و مسئوليت مربوط به يك فرايند كه متوجه تعدادی از افراد است تصميم بگيريد و متغيرها و پارامتر های سيستم را برمبنای آن تنظيم كنيد. جلسه ای كه تمام اين ذينفعان - كه همان مديران پر مشغله هستند- سه بار و هر بار به مدت دو هفته به تأخير مي افتد.
بنابراين، زمان تصميم سازی در مورد پارامتر های سيستم نزديك به يك ماه و دو هفته مي شود. ( جنس دوم زمان) و زمان اعمال اين پارامتر ها در سيستم دو روز است.(جنس اول زمان) مسائل تصميم سازى بسيار زياد است كه باعث افزايش زمان خالص مي شود. البته، كم و بيش بسياری از شر كت هايي كه در جهت تغيير فرايند ها گام بر مي دارند با اين چالش ها مواجه هستند. اين چالش ها در ايران خودرو به قدری است كه پيش بيني زمان را دشوار مي كند. اين نوع زمان ها قابل پيش بينى نيست يا دست كم من در موقعيتى نيستم كه بتوانم اين زمان ها راپيش بینى كنم.
مسأله ديگر اين است كه از همان ابتدا كه اين پروژه به دستور مديريت آغاز شد. مدير عامل و كادر مديريت ارشد ايران خودرو، خودروسازى را به عنوان موتورصنايع ساخت و توليد در كشور قلمداد مى كردند و مسأله اصلى كه مطرح كردند اين بود كه تكنولوژى پياده كردن SAP بايد در كشور نهادينه  شود و فقط اجازه دادند در زمينة مالى با خارجى ها قرارداد منعقد شود و با پياده سازى آن، ساير پروژه ها با توانمندى كارشناسان ايرانى انجام شود. بنابراين، ما بايد در مسيرى حركت كنيم كه يك نهاد با استعداد درست شود. كه خوشبختانه با پياده SAP پياده سازى سازى پروژه مالى اين اتفاق افتاد. قرارداد بعدى با يك شركت ايرانى است و اين شركت به جاى اينكه فقط از پياده ساز خارجى استفاده كند بخشى از كار را خودش انجام مى دهد. به اين ترتيب، در گام بعدى هزينه و زمان كاهش مي يابد.
جناب عالي بيان كرديد كه به هر صورت اين نگاه مديريتى بوده كه با يك رويكرد كلى وارد شده اند. اگر به اين شكل است و آثار مثبت ERP را نيز در سازمان خود مشاهده  كرده ايد پس، چرا به اين پروژه اولويت نمى دهيد تا مدت زمان آن كمتر شود؟
دكتراقدسى: تمام زمانى كه براى اين كار لازم است به تصميم سازى مديريت ارشد مربوط نيست. در اين قضيه يك مجموعة صد نفره از مديران ميانى بايد تصميم سازى كنند. اين مجموعه از مديران ميانى اولويت هاى كارى متفاوت و متنوعى دارند. ضمن اينكه، در بعضى موارد نيز عقايد آنها با يكديگر مغايرت دارد كه البته در مجموعة بزرگى مانند ايران خودرو كاملاً طبيعى است. بنابراين، مدت زمان انجام كار از پيش بينى هاى اوليه طولانى تر مى شود

ارسال شده توسط احمد محمدی | 7 12, 2013 | بازدید‌ها (8763)

بررسی روند تکاملی متدولوژی های توسعه سیستم های اطلاعاتی در موقعیت های مختلف سازمانی

  مقدمه

تلاش ها و اقدامات مرتبط با توسعه سیستم ها ، در ابتدا وابسته به روش های تصادفی و غیرسیستماتیک بودند. در اواخر دهه 1960 ، مشکلات توسعه سیستم ها ، منجر به پدیده ای تحت عنوان بحران نرم افزار گردید. این عارضه به معنی نگاه و تمرکز سیستم ها بر توسعه ، همراه با هزینه زیاد ، عدم کارکرد و زمان طولانی ، است[3]. با توجه به پیچیدگی سیستم ها ، نیاز شدیدی به توسعه بود ، در حالی که وضعیت ، روز به روز بحرانی تر می شد. به همین دلیل رویکردهای متدولوژی به توسعه سیستم ها پدیدار گشت. توجه به متدولوژی در دهه 70 تا 80 بسیار زیاد بود. در این دهه ها بحث ، بیشتر روی دو رویکرد سخت و نرم از توسعه سیستم های اطلاعاتی قرار داشت. در این دوران سازمان های بزرگ و دولت ها از متدولوژی های خاصی برای مدیریت پروژه های IT خود استفاده کردند. مثلا SSADM توسط دولت UK و IDEF توسط US بکار گرفته شد. این دو متدولوژی مبتنی بر رویکرد سخت بودند. استفاده از این متدولوژی ها با مشکلاتی همراه شد. مثلا اینکه آن ها هرگز کار نمی کردند یا با تاخیر طولانی کار می کردند و یا با عملکرد پایین خود انتظارات کاربران را برآورده نمی نمودند. در اواخر دهه 80 انتقادات نسبت به متدولوژی افزایش یافت و در دهه 90 مطالعات روی این  موضوع کاهش یافت و آن هم به دلیل مخالفت با مکتب متدولوژی و شکست های پی در پی آن و مورد دیگر تغییر الزامات و نیازمندی های سازمان ها بود. تحول در تکنولوژی و ساختار سازمان ها عللی دیگر بر عدم پذیرش متدولوژی ها بود[8].
با تغییرات در محیط کسب و کار و افزایش سرعت تغییر تکنولوژی و ساختار سازمان ها و الزامات و نیازمندی های کاربران ، نیاز به متدولوژی هایی برای توسعه سیستم های اطلاعاتی بود که پاسخ گوی فعل و انفعالات محیط امروزی باشد. به همین دلیل رویکردهای چابک ، ترکیبی و چند نگرشی به متدولوژی های توسعه سیستم ها پا به عرصه وجود گذاشتند. اقتصاد دیجیتالی بر روی متدولوژی های توسعه اثر گذاشته و آن ها را پویا کرده است. این مقاله در ابتدا به توصیف متدولوژی ، ویژگی ها ، مزایا و معایب آن می پردازد و سپس به تحلیل و بررسی متدولوژی های مختلف در موقعیت های متنوع سازمانی اشاره می کند.


تعریف متدولوژی توسعه سیستم های اطلاعاتی

در ارتباط با تعریف متدولوژی دیدگاه ها و نظرات متفاوتی موجود است. همین طور از نگاه ها ومنظرهای متنوعی به متدولوژی نگریسته شده است. Olerup در سال 1991 متدولوژی را اینگونه تعریف می کند: یک استراتژی که دلالت بر زیربخش های فرایند توسعه دارد. اصل تقسیم و تسخیر ، یک رویکرد مهندسی و ریاضی برای حل مسائل پیچیده می باشد[3]. متدولوژی های اولیه خیلی تحت تاثیر رشته های فنی و مهندسی بودند. شخصی به نام Langefors در سال 1973 توسعه سیستم ها را به عنوان یک فرایند علمی و عقلایی در نظر گرفت. متدولوژی در دو موضوع زیر تصمیم گیری می کند یک سیستم اطلاعاتی چه کاری را باید انجام دهد و یک سیستم اطلاعاتی بهتر است چگونه آن کار را انجام دهد[3].
Olerup در 1991 با پذیرفتن این نگرش علمی عقلایی ، فرایند پیچیده توسعه را به مراحل زیر تقسیم کرد: تجزیه و تحلیل نیازمندی ها ، طراحی راه حل ، و اجرای راه حل. افراد دیگری مثل Downs در 1992  فازهای دیگری را به این مراحل افزودند. مثل تحقیق و بررسی مقدماتی و نگهداری[3].
یک تعریف قدیمی تر از متدولوژی توسعه سیستم های اطلاعاتی توسط 1987 ، Checkland ، 1995 ، Hirschheim ، 1990 ، R.J Boland وجود دارد و عبارت است از: یک مجموعه ای از مفاهیم ، عقاید ، ارزش ها و اصول هنجاری که توسط منابع مورد حمایت قرار می گیرند[2].
در زمینه متدولوژی ، دو نقطه نظر وجود دارد: 1 – تعریف خاصی از متدولوژی وجود ندارد و این تعاریف موجود ممکن است با هم سازگاری نداشته باشند. 2 – ویژگی های متدولوژی که تقریبا در همه یا بخش کثیری از تعاریف مشترک است. بعضی از اندیشمندان مثل ، 1981 Chechland ، 1995 Hirschheim  و 1990 Vonk بین متد و متدولوژی تفاوت قائل شدند. متدولوژی جامع تر از متد است. متدولوژی برای ارزیابی میزان منطقی و سیستماتیک بودن یک متد معین بکار می رود. در حالی که متد ، روشی برای اجرای فعالیت در حالت ساخت یافته می باشد[8].


ویژگی های متدولوژی ها و اجزای آن ها

متدولوژی های توسعه سیستم های اطلاعاتی دارای ویژگی هایی می باشند که توسط این خصوصیات می توان آن ها را طبقه بندی کرده و مطالعه نمود و در موقعیت های متفاوت از آن ها استفاده کرد.
متدولوژی از سه بخش اصلی تشکیل شده است[8] : 1 – ساختار شکست کار : توسط این بخش می توان فهمید که چه کاری باید انجام داد و همچنین زمان انجام این کار مشخص می شود. 2 – تکنیک های چگونگی انجام کارها و ابزار مورد نیاز 3 – چگونگی مدیریت کیفیت نتایج.
هدف یک متدولوژی این است که در تغییر و توسعه سیستم های هدف به گروه کمک کرده تا این گروه به درک ، ایجاد ، ارزیابی ، کنترل و اجرای تغییرات در سیستم پیشنهادی بپردازد. متدولوژی ها باعث ایجاد نظم و سازماندهی یک سری از قوانین رفتاری و فنی مبتنی بر یک رویکرد منطقی می شوند و مشکلات بنیادی توسعه را بررسی می کنند. آن ها مجموعه ای از قوانین تصادفی نیستند و به ایجاد یکپارچگی و ارتباط منطقی بین اجزای خود می پردازند. متدولوژی ها شامل یک سری از مفاهیم و عقاید هستند که به تعریف محتوا و رفتار سیستم هدف و همچنین تغییرات در آن می پردازند. آن ها ارزش یک سیستم را تعریف می کنند ، یعنی چه ویژگی هایی از سیستم ، خوب و مورد تمایل است. روش های انجام کار و رویه هایی برای اجرای فعالیت ها لازم است ، و اصول هنجاری که انتظارات رفتاری را مشخص می کنند ، در حیطه وظایف یک متدولوژی است.
برای نائل شدن به اهداف و وظایف ، متدولوژی ها باید مکتوب بوده ، مورد تفکر قرار گیرند و یادگیری و انتقال آن ها با مشکل مواجه نشود ، مورد پذیرش اعضای سازمان بوده ، اجرای آن ها همراه با پاداش و ضمانت اجرایی باشد. متدولوژی ها باید قانونی بوده و منابع مورد استفاده در آن ها مورد تایید و پذیرش تصمیم گیرندگان و مسئولان پروژه ها قرار گیرد و باید به این نکته توجه کرد که آن ها نیاز به سرمایه گذاری در نیروی انسانی و مواد دارند.
متدولوژی های توسعه یک فونداسیون و چارچوب ساختاری را برای فرایندهای توسعه ایجاد می کنند که این کار توسط طبقه بندی فعالیت های جزئی و ضروری توسعه ، صورت می گیرد. فعالیت های غیر منطقی و غیر بهره ور در اینجا ، حذف ، و اجرای کارهای مهم ، ضمانت می شود.
در سال 1984 ، شخصی به نام Ahituv ، ابعاد توسعه را شامل بعد فعالیت ، بعد کنترل و بعد نیروی انسانی ، تعریف کرد و این در حالی است که متدولوژی توسعه می تواند با ایجاد یک چارچوب ، ابعاد ذکر شده را بهینه کند[3]. نکته آخر در این بخش این است ، فرایند توسعه از یک سری فازها تشکیل شده که حاکی از اصل تقسیم نیروی کار است. هر فاز تعدادی فعالیت را شامل می شود و افراد متنوعی روی آن ها کار می کنند.


مزایای متدولوژی ها

متدولوژی ها در ابتدا توسط تجربه و تمرین روی پروژه های موفق ایجاد شده اند و سپس به صورت رویه ها و فرمول هایی مکتوب شده و به عنوان اصول راهنما در فرایند توسعه مورد استفاده قرار گرفته اند. Ward در 1992 گفت : قبل از اینکه یک متدولوژی در توسعه سیستم مورد استفاده قرار گیرد ، بهتر است از لحاظ اصول مفهومی ، اجتماعی ، فیزیکی و تئوریکی ، درجه قابلیت استفاده از آن ، مورد بررسی و تحلیل قرار گیرد[3]. اما نکته مهم اینجاست که اصولا متدولوژی ها چه مزیت هایی دارند. باید به این موضوع اشاره کرد که متدولوژی ها باعث سهولت کنترل در پروژه ها شده و این کار مهم را توسط ایجاد ساختاری منطقی از استراتژی ها ، تکنیک ها ، رویه های ممیزی ، فعالیت های بازرسی و کنترل کیفیت ، انجام می دهند. مدیریت پروژه فرایندهای توسعه با استفاده از متدولوژی ها راحت تر است. زیرا در متدولوژی ها ، چیزهایی قابل مشاهده وجود دارد که توسط آن ها می توان به بررسی پیشرفت پروژه و پایش هزینه و سود و مقایسه اینها با برنامه مورد انتظار ، و در نهایت ارزیابی ریسک پرداخت. ضمنا تهیه مستندات که یکی از الزامات مهم در مدیریت و کنترل پروژه است ، آسان تر می شود.
Stage در 1991 اذعان کرد که متدولوژی ها باعث ذخیره دانش به طور سیستماتیک می شوند و انتشار و مبادله آنرا تسهیل می کنند[3]. این موضوع باعث می شود دانش و مهارت از افراد ماهر به افراد نیمه ماهر ،  انتقال یابد. یکی از نتایج ذخیره دانش ، استانداردسازی فرایند توسعه است. Avison و Fitzgerald در 1988عقیده داشتند استاندارد توسعه باعث بوجود آمدن زبان مشترک برای برقراری یک ارتباط آسان در میان افراد مشارکت کننده در فرایند توسعه می شود و در نتیجه ، همکاری و مشارکت بیشتر و وفاداری آن ها به حرفه و شغل خود افزایش و نهایتا حفظ و نگهداری فرایند توسعه میسر می گردد[3].
با استفاه از متدولوژی ها ، وظایف و فعالیت های فرایند توسعه دارای ساختاری مشخص می شوند ، کنترل هزینه و کنترل پروژه راحت تر صورت می گیرد ، و در نتیجه عدم اطمینان کاهش می یابد ، توسط استانداردها و کنترل می توان به هدایت نیروی انسانی پرداخت ، امنیت افزایش یافته و یادگیری فردی و گروهی تسهیل می گردد.




مشکلات متدولوژی ها

علی رغم مزایای فراوان و توصیه های اکید در اجرای متدولوژی ها ، تجربیات توسعه دهندگان و مطالعات و تحقیقات دانشمندان نشان داده است که اجرای متدولوژی ها با چالش هایی روبرو می شود. به طور مثال Paul در 1993 ابراز کرد که مشکلات اجرای متدولوژی ها مربوط به ماهیت و ساختار بنیادی خود آن ها است. و Fitzgerald در 1999 گفت ، تغییرات سریع در محیط تجارت و کسب و کار عامل اصلی در عدم اجرای موفق پروژه های توسعه سیستم های اطلاعاتی با استفاده از متدولوژی ها است[8].
به نظر می رسد برای سازمان هایی که در محیط پویا و پر از آشوب همراه با تغییرات سریع ، زندگی می کنند ، اجرای متدولوژی که رویکردی زمانبر است ، چندان مناسب نباشد. از لحاظ هزینه نیز می توان آن ها را به چالش افکند. سازمان هایی که دارای بودجه کافی برای فعالیت های خود نیستند ،  نمی توانند به راحتی متدولوژی های توسعه سیستم های اطلاعاتی را اجرا کنند. یکی دیگر از مسائل پیش روی سازمان ها ،  انطباق و یکپارچگی متدولوژی ها با ساختارهای موجود در محیط داخلی شرکت ها است. بنابراین توسعه دهندگان باید فرایندهای توسعه را مطابق با فرایندهای درون سازمان خود انجام دهند یا فعالیت های سازمانی خود را به تبعیت از متدولوژی ها ، اجرا کنند. همچنین قابلیت استفاده مجدد از متدولوژی ها در محیط پر از تغییر و همراه با محدودیت منابع سازمان های امروزی ،  مطالعه و بررسی بیشتری را می طلبد و این موضوع به عنوان یک چالش جدی ، فرا روی سازمان ها قرار گرفته است.


متدولوژی های فرموله شده

همان طور که قبلا اشاره کردیم در گذشته متدولوژی ها از نتایج و تجربه اجرای پروژه های موفق ، ایجاد می شدند. یعنی اصول ، رویه ها و فرایندهای موفقیت آمیز این پروژه ها به صورت مکتوب در آمده و در موارد بعدی از آن ها استفاده می شد. اما امروزه نمی توان به راحتی از این استراتژی استفاده کرد. دلایل متفاوتی برای این موضوع وجود دارد که قبلا به آن ها اشاره گردید. ولی در سال 1989 شخصی به نام Constantine رویکردهای توسعه را از سه منظر نگریست[3] : تمایز محصول ، سن کارمندان و ضرورت موقعیت و محل در اجرای فرایند توسعه. Fitzgerald و Avison در 1988 تفاوت بین متدولوژی ها را در فلسفه ، اهداف و تکنیک های آن ها ، دانستند [3]. متدولوژی ها را  می توان به دو نوع سخت مثل SSADM و نرم و مبتنی بر نیروی انسانی ، تقسیم کرد. نوع تمرکز آن ها نیز می تواند متفاوت باشد. مثلا بعضی از آن ها بیشتر متمرکز بر فاز تجزیه و تحلیل هستند در حالی که برخی دیگر به اجرا تاکید دارند.
اجرای متدولوژی توسعه سیستم های اطلاعاتی فرموله شده ، یک فرایند سازمان دهی کارها و فعالیت ها و اثرگذاری بر روش تفکر اعضای تیم نسبت به توسعه می باشد. بنابراین اگر افراد در یک سازمان بدون مشارکت یک متدولوژی ، بتوانند به سازمان دهی تفکرات و فعالیت های خود بپردازند ، در این صورت استفاده از متدولوژی ها بی ارزش می شود. بعضی تحلیل گران با تجربه ای که دارند ، بدون استفاده و کمک از متدولوژی ها ، بر مشکلات و موقعیت های سخت سازمان فائق می آیند. آن ها از قبل با این وضعیت ها به طور مشابه ، مواجه شده اند. علاوه بر اینها بعضی مواقع تیم و پروژه ها در مقیاس کوچک هستند و استفاده از متدولوژی ها ، تنها مشکل آفرین می شود و منفعتی برای فرایند توسعه ندارد.
متدولوژی های فرموله شده ، پشتوانه سال ها تحقیق هستند. بسیاری از افراد که در توسعه سیستم ها تخصص دارند ، معتقدند که برای حل مشکلات اساسی سیستم ها در سازمان خود ، بهتر است از متدولوژی های فرموله شده همان سازمان استفاده کرد. Chapin در 1980 گفت: اگر در توسعه سیستم ها از استانداردهای محلی و فرموله شده استفاده شود ، کارمندان احساس راحتی بیشتری می کنند[3]. مثال هایی از متدولوژی های فرموله شده در گذشته موجود است. یکی از آن ها SSADM می باشد که توسط دولت UK برای اجرای پروژه های توسعه سیستم های اطلاعاتی ایجاد گردید و در حال حاضر بسیاری از کشورها نیز از این متدولوژی استفاده می کنند. ولی از طرفی می توان گفت که کشورهای فرانسه ، هلند و ایتالیا هر یک متدولوژی خاص خودشان را دارند. در نهایت اینکه Jayava در 1994 ابراز کرد که بیش از 1000 متدولوژی فرموله شده در سازمان ها وجود دارد[3].






طبقه بندی متدولوژی های توسعه سیستم های اطلاعاتی

متدولوژی ها را می توان به روش های مختلفی همان طور که در قبل ذکر شد ، طبقه بندی کرد. یکی از طبقه بندی های جامع را در این بخش می خواهیم بررسی کنیم. این طبقه بندی بر اساس وضعیت های مختلفی صورت می گیرد که سازمان ها با آن مواجه می شوند. 5 کلاس برای طبقه بندی متدولوژی ها وجود دارد که در زیر به آن ها اشاره شده است[1]:
وضعیت ها و مسائل ساخت یافته همراه با الزامات و نیازمندی های تعریف شده به صورت واضح
مسائل ساخت یافته با اهداف واضح و الزامات و نیازمندی های نامعین کاربران
مسائل غیرساخت یافته همراه با اهداف نامشخص
مسائل و وضعیت هایی که در آن ها نیاز به تعامل زیادی بین کاربر و سیستم است.
مسائل و وضعیت های پیچیده ، یعنی ترکیب چهار کلاس بالا که احتیاج به یک رویکرد اقتضایی در توسعه است.
اینک به توضیح مختصری از هر یک و متدولوژی های آن ها می پردازیم.
1 – مسائل ساخت یافته همراه با نیازمندی های تعریف شده به صورت واضح
در اینجا از متدولوژی های توسعه سیستم های اطلاعاتی سنتی مبتنی بر رویکردهای سخت استفاده می شود. متدولوژی های توسعه سیستم های کامپیوتری اولیه ، در این طبقه یا کلاس هستند. رویکرد SDLC سنتی را که مرکز محاسبات ملی UK ارائه داده است ، می توان در اینجا قرار داد که دارای فازها و مراحل زیر است : مطالعه امکان سنجی ، بررسی و تحقیق سیستم ، تحلیل سیستم ، طراحی سیستم ، اجرا ، بازنگری و نگهداری. این متدولوژی در جایی کاربرد دارد که افراد در آن سازمان خواستار تغییرات بنیادی نیستند. این متدولوژی در سازمان هایی با عملیات روتین ، فرایندهای ایستا ، قابل اجرا بوده و اصولا در سازمان های کوچک یا دپارتمان های سازمان های بزرگ می توان از آن استفاده کرد. کاربران در این متدولوژی به صورت خیلی محدود دخالت داده می شوند و این متدولوژی از تصمیمات مدیریتی کمتر حمایت می کند.
2 – مسائل ساخت یافته با اهداف واضح و نیازمندی های نا معین کاربران
این طبقه از متدولوژی ها بعضی از مشکلات کلاس قبل را حل کرده اند و برای سازمان های امروزی مناسب تر هستند. در اینجا فرض بر این است که الزامات کاربران نامعین هستند. این طبقه دارای متدولوژی های ساخت یافته ، تحلیل داده مثل مهندسی اطلاعات ، و نمونه سازی ، است.
رویکردهای ساخت یافته متمرکز بر اجرای فعالیت ها در کسب اهداف معین هستند. آن ها از تکنیک هایی مثل DFD ، درخت و جدول تصمیم استفاده می کنند. این تکنیک ها به تحلیل گر در فهم بهتر الزامات کاربران کمک می کند. این رویکرد به مستندسازی تفکرات هر فرد در مورد یک مشکل یا وضعیت می پردازد و این کار باعث تسهیل انتقال تفکرات افراد به یکدیگر می شود. مشارکت و درگیری کارکنان در فرایند توسعه بیشتر شده و تجزیه و تحلیل برای ارائه نتایج رسمی و واضح ، راحت تر صورت می گیرد.
در جایی که فرایندها کمتر ایستا هستند ، رویکرد تحلیل داده ها مناسب تر است. در این رویکرد تاکید بر مدلسازی داده است تا مدلسازی فرایند. طرفداران این روش می گویند ، حتی اگر فرایندهای توسعه در یک سازمان تغییر کند ، باز هم می توان از بلوک های داده که از قبل ساخته شده است ، استفاده کرد. یکی از تکنیک های اصلی این رویکرد ، مدل رابطه – موجودیت می باشد که توسط Chen در 1976 ابداع گردید. مدلسازی داده ها به ساخت یک مدل مفهومی داده برای تعیین الزامات سیستم اطلاعاتی بکار می رود.
اگر چه طرفداران زیادی برای متدولوژی مبتنی بر داده وجود دارند ، اما اشخاصی مثل Benyon ، Skidmore  در سال 1987 ابراز کردند که تاکید بر داده ها و تکنیک های مرتبط با آن ، ممکن است منجر به نادیده گرفتن واقعیات شود[1]. این متدولوژی ها در جایی که درجه تعارض بالا است کاربرد آنچنانی ندارد. به همین دلیل دو متدولوژی ساخت یافته و تحلیل داده با هم ترکیب شدند و از تکنیک هایی مثل DFD و ERD استفاده گردید. SSADM بر طبق این منطق توسعه داده شد. با اینکه ترکیب دو متدولوژی قبل باعث پوشش بعضی نقاط ضعف آن ها گردید ، ولی باز هم نمی شد از آن ها در محیط های با تعارض بالا استفاده کرد. به همین دلیل متدولوژی نمونه سازی بوجود آمد.
این متدولوژی برای وضعیت هایی مفید است که نیازمندی های کاربران غیر واضح است. در چنین رویکردی ابتدا نیازمندی ها و الزامات استخراج شده ، سپس آن ها ارائه می شوند و در پایان توسعه می یابند و این کار به همین ترتیب ادامه دارد تا کاربران سیستم رضایت کامل را کسب کنند. بنابراین ابتدا توسط یک مدل کاری ، سیستم نهایی ساخته می شود و این کار باید سریعا صورت گیرد و از بیان جزئیات خودداری شود. در ادامه مسائل بالقوه در طراحی مشخص می گردد و مرتبا تحلیل گر می تواند متوجه شود که نیازهای کاربران و مدیریت چیست. کاربران و مدیریت همراه با دیگر اعضای فرایند توسعه به طور مکرر با هم بحث و مذاکره می کنند و متدولوژی نمونه سازی به تناوب اجرا می شود. این رویکرد به تسهیل برقراری رابطه با کاربر تاکید دارد.
3 – مسائل غیرساخت یافته همراه با اهداف نا مشخص
متدولوژی هایی که در دو کلاس قبلی به آن ها اشاره شد ، دارای رویکرد سخت بودند. در بسیاری از مواقع اهداف اجرای توسعه سیستم نامشخص بوده و یا اصولا خود سازمان یا ارگان دارای اهداف غیرواضح است ، و همچنین ممکن است بعضی از گروه ها یا افراد در آن سازمان دارای اهداف واضح باشند ، ولی تعارضات بالایی بین آن ها برقرار است. در چنین مواقعی از رویکردهای نرم استفاده می کنیم. یعنی جایی که می خواهیم به اهداف بهینه و توافق شده دست یابیم. یکی از معروف ترین متدولوژی هایی که در این دسته قرار می گیرد ، متدولوژی سیستم های نرم است که توسط Checkland ارائه شد[1]. او معتقد بود که سیستم های فعالیت های انسانی تنها در ذهن افراد وجود دارند و بنابراین چشم انداز افراد است که بر روی نگرش آن ها از وضعیت مساله و اهداف سیستم ، اثر می گذارد. تکنیک دیاگرام تصویر غنی ، با مدلسازی تمام ابعاد وضعیت مساله باعث ایجاد یک تصویر غنی می شود که توسط آن مباحث ، مشکلات و تعارضات را می توان تشخیص داد.
4 – مسائل و وضعیت هایی که در آن ها نیاز به تعامل زیادی بین کاربر و سیستم است.
در بسیاری از سیستم های اطلاعاتی ، مشارکت کارکنان و کاربران تاثیر زیادی روی اجرای آن ها می گذارد. در چنین پروژه هایی باید از متدولوژی استفاده کرد که علاوه بر توجه به مسائل ایستایی فنی ، مشارکت و درگیری کاربران را نیز در نظر بگیرد. یکی از متدولوژی های مهم در این طبقه ، متدولوژی ETHICS است که توسط Mumford در سال 1995 پایه گذاری گردید. این متدولوژی به معنی سیستم های اجرایی انسانی و فنی و کامپیوتر محور است که به تشویق مشارکت کاربران می پردازد و باعث تعهد بیشتر آن ها به پروژه می شود[1]. ETHICS مبتنی بر رویکرد فنی و اجتماعی است. به تامین ابزارها برای تحلیل و هدفگذاری با مشارکت کاربران ، متمرکز است. نکته مهم اینجاست که رویکرد مشارکتی در مسائلی که کاربران و افراد تمایل به درگیری در پروژه ندارند و یا مجبور باشند با استفاده از زور در پروژه دخیل شوند ، کارساز نخواهد بود ، بلکه سازمان باید در این زمینه فرهنگ سازی کرده و سیاست ها و نگرش های خود و افراد سازمان را تغییر دهد. سازمان باید سطوح سلسله مراتبی بوروکراتیک خود را تغییر دهد و درجه انعطاف پذیری را بالا برد.
5 – مسائل و وضعیت های پیچیده
بسیاری از محققین اذعان کرده اند که یک نوع از بهترین متدولوژی برای همه وضعیت ها و مسائل وجود ندارد. انتخاب متدولوژی بستگی به ویژگی و ماهیت پروژه دارد. و برای اجرای یک پروژه سیستم اطلاعاتی بهتر است به بررسی متغیرهای درونی و بیرونی آن پروژه پرداخت. طبقه بندی متدولوژی ها ، صرفا برای این است که ما با ویژگی های هر یک به طور جداگانه آشنا شویم و با این کار نمی خواهیم بگوییم که یکی بر دیگری برتری دارد. بلکه باید به بررسی وضعیت کل پروژه و حتی بخش های یک پروژه پرداخت و سپس متدولوژی مورد نظر را انتخاب کرد. در این حالت ، متدولوژی مقتضیانه بهترین تصمیم است.
در این کلاس ، رویکرد Multiview یا نگرش چندگانه مورد بررسی قرار می گیرد. به جای انتخاب هر یک از متدولوژی ها ، در هنگام مواجه شدن با مسائل بهتر است از رویکرد مقتضیانه در فرایند توسعه استفاده نمود. رویکرد چند نگرشی دارای یک ساختار منعطف است و با توجه به وضعیت های خاص یک مساله ، تکنیک ها و ابزارهای مرتبط را پیشنهاد می دهد. این متدولوژی دارای 5 فاز می باشد که عبارتند از : تحلیل سیستم های فعالیت انسانی ، تحلیل اطلاعات ، تحلیل و طراحی سیستم های اجتماعی – فنی ، طراحی روابط متعامل انسان با کامپیوتر و طراحی جنبه های فنی. در ارتباط با این رویکرد باید به سوالات زیر پاسخ داد تا بعد از تحلیل پاسخ ها ، اقدامات مناسب را به عمل آورد[1].
از سیستم های اطلاعاتی که برای اجرای فعالیت های سازمانی توسعه می یابند ، چگونه حمایت می شود؟
سیستم های اطلاعاتی در سازمان ، چگونه با زندگی کاری افراد تناسب پیدا می کنند؟
افراد چگونه می توانند به بهترین وجه با کامپیوتر در تعامل باشند؟
برای پردازش اطلاعات در اجرای سیستم از چه فرمول ها و توابعی استفاده می شود؟
چه مشخصات فنی از سیستم با تجهیزات شناسایی شده ، در ارتباط هستند؟
در متدولوژی چندگانه می توان از رویکرد ترکیب در استفاده از متدولوژی های توسعه سیستم های اطلاعاتی استفاده کرد. در این روش ، سازمان ها با استفاده از برون سپاری بعضی فرایندها و اجرای توسعه روی فرایندهای کلیدی خود ،  هزینه های خود را کاهش می دهند. آن ها بر اساس موقعیت های مختلف یک پروژه ، از متدولوژی خاص آن وضعیت استفاده کرده و در انتها برای بستن پروژه ، متدولوژی های برون سپاری شده و درونی را با هم ترکیب می کنند[8]. این کار باعث افزایش کیفیت و تخصصی شدن بخش های پروژه شده ، قابلیت نگهداری افزایش می یابد و بهره وری رشد می کند. از این استراتژی ، جدیدا در فرایند توسعه نرم افزار در محیط های شی گرایی و ایجاد کلاس ها و شناسایی اجزا ، استفاده می کنند. نتیجاتا اینکه بهره گیری از این فلسفه در محیط های پویا و همراه با تغییرات زیاد ، بسیار مفید است. زیرا علی رغم تغییرات در فرایندها ، اشیا و اجزای یک سیستم را می توان جداگانه با متدولوژی های مختلف و با استفاده از برون سپاری ، توسعه داد.


متدهای چابک و پویا در توسعه سیستم های اطلاعاتی

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


از ترکیب این دو استراتژی ، پنج استراتژی شکل می گیرد که عبارتند از[2]:
DSDM خطی: که در آن تنها یک بار از استراتژی تکاملی استفاده می شود.
One – pass DSDM: این استراتژی با ترکیب یک رویکرد تکاملی و چند رویکرد تکرار ، بوجود می آید.
Hybrid DSDM: به معنی استراتژی است که شامل چند رویکرد تکاملی بوده در بعضی از این رویکردها چند بار از رویکرد تکرار استفاده می شود.
Full DSDM : ترکیبی از رویکردهای تکاملی و تکرار و از هر کدام چند بار
Phased DSDM : استفاده از رویکردهای تکاملی در چندین مرحله و بدون بهره بردن از رویکرد تکرار
در انتخاب هر یک از اینها باید به نوع پروژه و وضعیت مشارکت کاربران توجه کرد. قبل از اجرای این متدولوژی ها ، بهتر است بین مدیران و مربیان ،  توافقاتی بر سر زمان و بودجه پروژه ها صورت گیرد. نکته برجسته در اجرای این رویکردها ، رضایت مندی و مشارکت کاربر در فرایند توسعه می باشد. گرفتن بازخور از کاربر علاوه بر اینکه باعث تقویت مداخله کاربر در پروژه می گردد ، اصولا عملی مهم در موفقیت هر یک از رویکردهای افزایشی و تکرار است.


متدولوژی Fujitsu در توسعه سیستم های اطلاعاتی

شخصی به نام Fujitsu به توسعه یک سیستم اطلاعاتی پرداخته است که معماری و پشتیبانی توسعه سیستم (SDAS) نام دارد[7]. این متدولوژی برای تکنولوژی های جدید کاربرد زیادی دارد. استفاده از این متدولوژی باعث بهبود کیفیت و کاهش زمان توسعه سیستم می گردد. به تعریف دقیق الزامات و نیازمندی ها می پردازد. قابلیت های توسعه و نگهداری فرایند توسعه در این متدولوژی ، بالاست و از ابزارهای موثری برای اتومات کردن تست و مستندسازی استفاده می کند.
SDAS یک متدولوژی جامع توسعه سیستم است که نخستین نسخه آن در سال 1980 توسط Fujitsu برای حمایت از زیرساخت های COBOL ایجاد گردید. سپس در سال 1990 ، این متدولوژی برای پشتیبانی از سیستم های Client – Server ، مورد تجدید نظر قرار گرفت. در نهایت نسخه جدید آن برای بهبود کیفیت و کاهش زمان توسعه در سیستم های مبتنی بر وب و در کل چرخه تکاملی سیستم ، ساخته شد.
ساختار این متدولوژی همان طور که در شکل زیر نشان داده شده ، از موارد زیر تشکیل یافته است : برنامه ریزی سیستم سازمان ، پشتیبانی از توسعه کاربردی (شامل : الزامات ، طراحی ، اجرا و تست) ، فرایندهای توسعه و مدیریت پروژه ، نگهداری.


شکل 1: ساختار متدولوژی SDAS

اهداف SDAS شامل بهبود کیفیت توسعه سیستم و کاهش دوره زمانی آن با استفاده از تکنیک ها و فنون زیر است[7].
1 – تعریف دقیق نیازمندی ها و الزامات و به اشتراک گذاشتن اطلاعات با مشتریان : یکی از مشکلات توسعه سیستم های اطلاعاتی ، وجود ابهام در اطلاعات است. حتی در بعضی مواقع مشتریان فرایند توسعه سیستم نیز نمی دانند که واقعا چه می خواهند. عدم وضوح اطلاعات باعث ایجاد تغییرات در طراحی می گردد که این موضوع به نوبه خود تاخیراتی را در تحویل پروژه توسعه سیستم به مشتری ، دارد. در نتیجه شناسایی الزامات دقیق مشتری مهم و حیاتی است. SDAS ابزارهایی را برای افزایش فهم و تفسیر در الزامات و نیازمندی های مشتریان فراهم می کند. یکی از این ابزارها ، جریانات کاری است ، تا عملیات و فرایندهای تجاری در سیستم به طور استاندارد تعریف گردد.
2 – ابزارهای بهبود کیفیت و اثربخشی : Fujitsu از ابزارهای تست و توسعه برای پشتیبانی تست و مستندسازی زیرساختارهای سیستم استفاده کرده است. ابزارهای تست باعث کاهش هزینه و زمان مورد نیاز برای تست ، می شوند. ابزارهای پشتیبانی مستندات ، باعث بهبود کیفیت و اثربخشی توسعه فرایندها می شوند. کلیه این کارها توسط اتومات کردن فرایندها صورت می گیرد.

جنبه های فرهنگی و اجتماعی متدولوژی های توسعه سیستم های اطلاعاتی

اکثر متدولوژی های توسعه سیستم های اطلاعاتی در سال های 1967 تا 1977 ظهور کرده اند. فنونی مثل دیاگرام جریان داده، مدل روابط موجودیت و مفاهیمی مثل شی گرایی و چرخه زندگی توسعه سیستم در مراحل بعدی پا به عرصه وجود گذاشتند. در این دهه بیشتر محققین با رویکرد مهندسی و ریاضی به توسعه سیستم ها می پرداختند. به عنوان مثال Davis در 1988 و Orr در 1989 اعتقاد داشتند که SDLC پایه ای برای متدولوژی های دیگر در توسعه سیستم ها است [4]. این واژه در بسیاری از رشته های مهندسی وجود دارد. Friedman در 1989 و Kraft در 1977 اشاره کرده اند که معرفی این مفهوم در توسعه سیستم همزمان با تمایل به برقراری یک رویکرد مهندسی در توسعه سیستم بود.[4]از طرفی در چهل سال گذشته رویکردهای سخت نسبت به توسعه سیستم وجود داشتند؛ سپس متدهای نرم جای آن ها را گرفتند. SDLC به توسعه سیستم نگاهی سخت داشت. Laudon در 1995 ضعف های اصلی SDLC را این گونه برشمرد[6]: هزینه زیاد سیکل توسعه، زمانبر بودن چرخه، عدم انعطاف پذیری و سستی در تغییرات ایجاد شده توسط SDLC.
نکته اساسی این است که استفاده از متدولوژی های مرسوم، ضامن موفقیت اجرای سیستم های اطلاعاتی نیست. بعضی از متدها تنها بخشی از نیازهای سیستم را برطرف می کنند. به عنوان مثال مرکز محاسبات ملی در UK، فرایند توسعه سیستم را اینگونه تعریف می کند[6]: مطالعه امکان سنجی، تحلیل و بررسی سیستم، توسعه سیستم، اجرا، بازنگری و نگهداری. این تعریف، بیشتر جنبه تکنیکی دارد. متدولوژی هایی که این تعریف را انتخاب کرده اند به متدولوژی سخت معروف اند. چنین رویکردی نیازهای فنی کارکنان را در توسعه برطرف می سازد ولی تضمین کننده الزامات غیرفنی نمی باشد. Sawyer در سال 1994 اذعان کرد که SDLC یک اکسیر نیست بلکه هنوز هم می توان پروژه هایی را پیدا کرد که هنگام اجرای این متد در توسعه با شکست مواجه می شوند. این نگرش که تنها بعد فنی و کاربردی در توسعه سیستم مطرح است، به شکست توسعه منجر می شود[6]. شکل زیر نشانگر این است که چگونه مباحث فنی در فرایند توسعه سیستم غالب شده اند.


شکل 2: غالب بودن مباحث فنی در فرایند توسعه سیستم
اگر چه اندیشمندانی مثل Klein و Hirschheim در سال 1987 به توسعه سیستم نگاهی فنی و تکنیکی داشتند، Land در سال 1985 اعتقاد داشت که سیستم های اطلاعاتی، سیستم هایی اجتماعی هستند که فناوری اطلاعات در آن قرار گرفته است[6] ؛ Lyytinen در 1987 اشاره کرد که در طراحی سیستم ها باید به ابعاد فرهنگی، اجتماعی و سیاسی نیز همانند تکنیکی توجه گردد. بدین ترتیب مشارکت کارکنان در توسعه سیستم امری الزامی و حیاتی است. می توان توسعه سیستم های اطلاعاتی را از دو بعد نگریست: 1- بعد تکنیکی 2- بعد رفتاری،فرهنگی،اقتصادی،اجتماعی و سیاسی. نکته مهم اینکه درنظر گرفتن تنها جنبه های تکنیکی در توسعه، مباحثی مثل پیچیدگی و تغییرات محیطی را لحاظ نمی کند. اگر کارمندان در توسعه سیستم مرتبا به سمت ابعاد تکنیکی روی آورند، شاید یک موفقیت فنی حاصل شود ولی سازمان با شکست مواجه می گردد. پس بهتر است در توسعه به مشکلات و مسائل رویکردی کل نگر داشته باشیم. شکل زیر از جنبه ای دیگر به توسعه سیستم های اطلاعاتی می نگرد[6]. یعنی فرض می کند که ابتدا سیستم اطلاعاتی وارد سازمان می شود، سپس با مباحثی روبرو می گردد که برای موفقیت توسعه الزامی و حیاتی است.


شکل 3: برخورد سیستم های اطلاعاتی با مباحث مختلف در ابتدای ورود به سازمان

Avison در 1995 متدولوژی های توسعه مثل SSADM را مورد نقد قرار داد[9] او معتقد بود که این روش ها تنها بر ابعاد رسمی و فنی متکی هستند و اینکه توسعه سیستم بهتر است از جنبه تکنیکی به نگرش های رفتاری و اجتماعی انتقال یابد. همچنین Wood Harper در سال 1996 اذعان کرد که در توسعه سیستم های اطلاعاتی بهتر است موارد زیر نیز در نظر گرفته شود[9]: میزان اثرگذاری جنبه های رفتاری در توسعه سیستم، تعیین نوع متدولوژی متناسب با نوع رفتار در سازمان، اتخاذ رویکردی مناسب در توسعه در هنگام مواجه شدن با تعارضات سازمانی.
فرهنگ نیز یکی از مهم ترین مباحث در سازمان های امروزی می باشد. سیستم های اطلاعاتی به عنوان یکی از رویکردهای نوین در سازمان ها از این قاعده مستثنی نیستند. به محض ورود یک سیستم اطلاعاتی جدید در سازمان نیاز به تغییر فرهنگ است. Boynton در سال 1987 اعتقاد داشت که توسعه سیستم های اطلاعاتی نیاز به موارد زیر دارد[5]: تحلیل فرهنگ درون سازمانی، ارزیابی سیاست و توزیع قدرت در سازمان، تعیین میزان پذیرش سیستم های اطلاعاتی توسط کارکنان، ارزیابی ریسک، اطمینان از مشارکت اعضای سازمان در توسعه و شناسایی موارد بحرانی اجرای سیستم های اطلاعاتی در سازمان.









نتیجه

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














مراجع


[1] Avison D.E.; Taylor V.,”Information Systems Development Methodologies: A Classification According To Problem Situation”,Journal of Information Technology,1997,73-81.
[2] Aydin Mehmet Naflz; Harmsen Frank; Slooten Kees Van;Stegwee Robert A,”An Agile Information Systems Development Method in Use”,Turk J Elec,Vol.12,No.2, 2004.
[3] Fitzgerald Brian, “Formalised Systems Development Methodologies: A Critical Perspective”,forthcoming in Information Systems Journal,1996.
[4] Fitzgerald Brian,”Systems development methodologies: the problem of tenses”,http://WWW.emerald-library.com,Information Technology & People, Vol.13 No.3,2000, pp.174-185.
[5] Maguire Stuart;Redman Tom,”The role of human resource management in information systems development”,http://WWW.emerald-library.com,Management Decision Vol.45 No.2,2007,pp.252-264.
[6] Maguire Stuart,”Towards a business-led approach to information systems development”,http://WWW.emerald-library.com,Information Management & Computer Security, 8/5 [2000],230-238.
[7] Oshima Takeshi;Kashiwagi Masayuki;Fukao Hiroshi,“Fujitsus System Development Methdologies: SDAS”FUJITSU Sci.Tech.J.,42,3,2006,p.277-285.
[8] Papatsoutsos Dimitrios,“Information Systems Development Methodologies in the Age of Digital Economy”,University of Athens Department of Informatics University Campus TYPA Buildings, 2005.
[9] Rogerson Simon; Weckert John; Simpson Chris,”An ethical review of information systems development”,http://WWW.emerald-library.com,Information Technology & People, Vol.13 No.2, 2000, pp, 121-136.
«قبلي   1 2 3

درباره من

  • 9163858398
  • احمد محمدی (کارشناس ارشد مدیریت فناوری اطلاعات و مهندس نرم افزار)

    مشاور و عضو کمیسیون نظارت و ارزشیابی سازمان نظام مهندسی رایانه ای خراسان رضوی

    جديدترين مقالات مرتبط با مدیریت فناوری اطلاعات

    ahmad.mohammadi.a@gmail.com

آخرين مطالب بروز شده