در اين نوشته، نگاهي خواهم داشت به مقدمات مفاهيم انبارکردن داده ها بدون ورود به بحث هاي تخصصي مرتبط تا در آينده بتوانم در مطلب مستقلي به مفهوم داده در سازمانهاي امروزي نگاهي داشته باشم علمي + تجربي.
 تعريف:
مي توان تعاريف مختلفي را براي  Datawarehouse:
1-  تعريف Ralhp Kimball از انباره داده : يک DW نسخه اي از داده هاي تراکنشي است که به صورت اختصاصي براي پرس و جو ها و گزارش گيري ،سازمان دهي شده است.
A data warehouse is a copy of transaction data specifically structured for querying and reporting.
گرچند به اين تعريف دو ايراد وارد است:که اولاً گاهي داده هايي که در يک DW ذخيره مي شوند ،غيرتراکنشي هستند . اگرچه معمولاً 95 تا 99 درصد داده ها تراکنشي هستند . ثانياً خروجي اصلي سيستم هاي  DW ، ليست گيري هاي فهرست وار (queries) در حجم کم و يا گزارش هاي اداري در حجم زياد هستند

2- اگر تعاريف زير برقرار باشد:
  داده  : حقحيقت قابل مشاهده ، فايل ضبط
  اطلاع : مجموعه سازماندهي شده از حقيقت ها ؛ داده هاي با ارتباط و هدف
  سيستم عملياتي : محيطي از داده ها و برنامه هاي لازم براي ادامه فعاليتهاي يک سازمان
  انبار داده ي اطلاعي :مجموعه اي از داده و برنامه ها، براي "تحليل " و "تصميم گيري "، جدا از سيستم عملياتي

يک انباره داده(DW)  معماري جداگانه اي است براي نگهداري داه هاي حساس تاريخي که اين داده ها از انبار داده هاي عملياتي به دست آمده اند و به صورتي قابل درک براي عمليات تحليل سازمان درآمده اند.

3- يک تعريف از W.H.INMON
يک DW مجموعه اي از اطلاعات يکپارچه که داراي قابليت آناليز کردن و استخراج داده ها (query)ميباشد
"repository of integrated information, available for querying and analysis "

بعضي از خصوصيات Data warehouse  ها از اين قرارند :
•يکپارچه بودن
•متغير با زمان
•غير فرار
•موضوع گرا (Subject-oriented)

تاريخچه:
بعد از رشد استفاده از TPS ها به عنوان سيستمهاي پرداش تراکنش در بخش هاي عملياتي سازمان، نياز جدي به سيستمهاي اطلاعاتي که بتوانند عمليات گزارش گيري را علي الخصوص در رده گزارشهاي مديريتي ساماندهي کنند احساس مي شد. علي الخصوص بوجود آمدن جزاير فنآوري، سيستمهايي که به صورت جد از هم فعاليت مي کرد و امکان تهيه گزارشات ترکيبي از اطلاعات سيستمهاي مختلف و انجام پرس و جو ها را مشکل و يا غير ممکن مي نمود. بنابراين حرکت به سمت سيستمهاي اطلاعات مديريت (Management Information System) و بويژه سيستمهاي گزارشگيري مديريتي (MRS:Management Reporting System) آغاز شد. اما مشکل آنجا بود که اين سيستمها به شدت به TPS ها وابسته بودند و داده هاشان اغلب يکي بود. اين باعث مي شد که تغيير يکي باعث انتشار تغييرات در همه سيستمها شود. از سوي ديگر ساختار داده اي مشابه، امکان تهيه گزارشات زماني و موضوعي را مشکل مي ساخت. اين شد که مدل جديدي از تفکر ايجاد شد به نام انباره داده ها

دلايل استفاده از DW ها :
1- تهيه گزارشات (Reports) و انجام پرس و جو هايي (Query) که نياز به عمليات ورودي/خروجي (IO) بسياري هستند: از اهداف سيستمهاي پردازش تراکنش (TPS:Transaction Processing System) آن است که گزارشات مورد نياز بخش هاي عملياتي و مديريتي را توليد کنند. تهيه اين گزارشات معمولا سخت و باحجم زياد IO همراه است و باعث کند شدن خود سيستمها مي گردد. بنابراين شرکت هاي تجاري به دنبال راهي هستند تا در کمترين زمان و با کمترين هزينه به سيستم هايي دست يابند که زمان پردازش تراکنش ها در آن ها قابل قبول باشد . بهترين راهکار استفاده از DW هايي بود که از منابع IO مجزايي براي گزارش گيري و انجام پرس و جو استفاده مي کردند.

2- استفاده از مدل هاي داده اي و يا تکنولوژي هاي سرور به منظور بالا بردن سرعت عمليات گزارش گيري و پرس و جو ها که سيستم هاي عادي پردازش تراکنش ها(TPS) براي آن ها مناسب نيست.
3- ايجاد محيطي براي براي تسهيل و آسان نمودن به دست آوردن گزارش ها و پرس و جو ها و يا ايجاد وسيله اي براي سرعت بخشيدن به عمليات گزارش گيري: اغلب مي توان DW اي ساخت که کاربراني باسطح آگاهي کمتر بتوانند گزارش ها و پرس و جوهاي ساده اي را تهيه کنند .
4- براي ايجاد انباري از داده هاي تصفيه شده ي سيستم هاي پردازش تراکنش ها (TPS)که مي توانند به طور پيوسته گزارش از آن تهيه نمود. اين انبار الزاماً احتياجي به ثابت بودت TPS ها ندارد :DW ها اين امکان را به شما مي دهند که داده ها را بدون تغيير دادن سيستم هاي پردازش تراکنش ها ،تصفيه کنند. (clean up) توجه کنيد که در برخي از پياده سازي ها ، DW ها به گونه اي هستند که در آن ها امکان يافتن اصلاحات انجام شده بر روي داده هاي DW و فرستادن feedback به TPS ها براي اعلام اين تغييرات ، وجود دارد. گاهي اوقات اين گونه رفتار کردن با تغييرات داده ها بامعناتر از اين است که تغييرات را به طور مستقيم بر روي خود TPS ها اعمال کنيم .
5- براي آن که بر اساس قواعد ، گزارش گيري و پژوهش را بر روي داده هايي که از چندين TPS مختلف مي آيند و يا از يک منبع داده اي خارجي مي آيند، يا اينکه داده هايي هستند که تنها براي گزارش گيري و انجام تحقيقات بايد ذخيره شوند ، تسهيل بخشيم:براي مدت زمان مديدي ، شرکت هايي که نياز به گزارش هايي بر پايه ي داده هاي چندين TPS مختلف ، داشتند ؛ مجبور بودند داده هاي هر TPS را بيرون کشيده ، سپس آن ها را مرتب نموده و در هم ادغام نمايند تا به داده ي چکيده اي برسند که مناسب گزارش گيري است .در بسياري از موارد اين روش مناسب است.اما در شرکت هايي که با حجم عظيمي از داده هايي مواجه هستند که مرتباً نياز به مرتب سازي و ادغام دارند ؛ در صورتي که نياز به گزارش گيري از داده هاي تصفيه شده ي TPS ها داشته باشيم ؛ DW ها کارايي بيشتري دارند.
6-براي ايجاد مخزني از داده هاي TPS ها ، که شامل داده هاي يک بازه ي زماني بسيار طولاني هستند وبه همين دليل کارايي کنترل آن ها توسط خود TPS پايين مي آيد . :داده هاي قديمي تر غالباً از يک TPS خالي مي شوند تا زمان پاسخ مورد انتظار دراين سيستم ها ، به راحتي کنترل شود .براي انجام تحقيقات و گزارش ها ممکن است داده هاي قديمي و داده هاي جاري مورد نياز باشند که در اين موارد استفاده از DW به علت مهم نبودن زمان انتظار براي پاسخ ، موثر خواهد بود.

روش کار:
در DW فرايندي داريم به نام ETL: Extract, Transform,Load که در طي آن داده ها از سيستمهاي پرادزش تراکنش استخراج مي شود (E) تغيير فرمت هاي لازم در آن صورت مي گيرد (T) و سپس در قالب داده اي جديد مناسب براي گزارشگيري آماده مي شود (L) پس از آن از طريق داده کاوي (Data Mining ) و مکانيزم هايي مانند OLAP پرس و جو ها ايجاد و گزارشات مورد نياز تهيه مي شود. (در مورد داده کاوي و ... در مطلبي در آينده مقدمه اي خواهم آورد)

اما ...
در اين نوشته همانگونه که گفتم قصد ورود به جزييات ندارم و هدفش مروري است بر کاربرد داده پردازي در سازمانها. بنابراين براي کسب اطلاعات بيشتر درمورد Data warehouse و بحث مهمي تحت عنوان معماري هاي مختلف DW به مطالب تخصصي مراجعه کنيد.

همين!

یکی از دوستان لینکی برایم �?رستاد که در آن اشاره شده به دلیل نام گذاری Delphi، اینکه چطور و چرا Borland به این نتیجه رساند که محیط برنامه سازی Visual خود را که بر مبنای Object Pascal تهیه شده بود Delphi  بنامد. جالب بود برایم که به خاطر oracle نام محصول جدید Delphi گذاشته شد. 
 توصیه می کنم اصلش را بخوانید با عنوان:

Borland History: Why the Name "Delphi"? by David Intersimone  
Danny Thorpe, Senior Engineer, Delphi R&D Inprise Corp 

  همین!

از وقتی اینترنت در ایران همه گیر شده است، هر روز چیز جدیدی روی آن مد می شود و خیلی سریع هم از مد می ا�?تد.خسته شدم از بس چیز جدید شنیدم!
یادم نمی رود ابتدای کار را ، از ایمیل یاهو گر�?ته تا چت کردن، است�?اده از مسنجر ها چقدر محبوب بود و مایه کلاس ... عضویت در گروه ها ،... روز دیگر orkut  و بعد هجوم زیاد سایت های مشابه ،... روز بعد وبلاگ و وب سایت شخصی داشتن، ....حالا هم که انگار تویتر (twitter) ...
تا روز دیگر چه چیزی مد شود ....

همین!

با رشد کاربردهای ICT در موارد مختل�?، یکی از مهمترین جایگاه های ارائه خدمات و تسهیلات �?نآوری اطلاعات و ارتباطات، امر آموزش و مدیریت آموزشی شد و به دلیل پویایی ذاتی مساله آموزش، این کاربردها هر روز گسترده تر و جدی تر شد، به شکلی که امروزه شاهد واژگان جدیدی در آموزش و مديريت آموزشي هستیم. وآژه هایی مانند سیستم های مدیریت آموزشی (LMS)، سیستمهای مدیریت محتوی آموزشی (LCMS ) آموزش الکترونیک (eLearning)  آموزش مجازی (Virtual)، آموزش از راه دور (Distance Learning) ، مدرسه مجازي و یا دانشگاه مجازی (Virtual School, Virtual University)  ، مدرسه الکترونیک،  مدرسه هوشمند (Smart School)  و .....

واژه هایی که هر روز بحث های مت�?اوتی در مورد آنها می شود و گاهی به اشتباه به جای همدیگر هم به کار می رود.
در سلسله مطالب دنباله دار و یا مقطعی و در قالب دسته بندی جدید آموزش و �?نآوری اطلاعات به مسائل مرتبط با بهره گیری از ICT در آموزش و تاثیرات آن در خود �?رآیند های آموزشی و یا مدیریت آموزشی خواهم پرداخت.
علی الحساب نگاهی بیاندازید به �?صل ششم کتاب "پیش به سوی جامعه اطلاعاتی"  نوشته  دکتر محمد �?تحیان و مهندس سید حاتم مهدوی نور، انتشارات دیباگران تهران (1383) تحت عنوان �?نآوری اطلاعات و آموزش که نسخه الکترونیک این �?صل را در اینجا یا اینجا  پیدا خواهید کرد.
همین!

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

همین!

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

در مطلب قبلي يک آشنايي کلي با مدل تعالي و يا سرآمدي EFQM   آورده شد.
ارزيابي با اين مدل معمولا به دو شکل صورت مي گيرد، يا توسط ارزيابان حر�?ه اي و يا در کارگاه هاي خود ارزيابي. سازمانها در طي دوره هاي مشخص و به صورت پيوسته (براي مثال هر سال يکبار و يا قبل و بعد از انجام پروژه هاي بهبود) خود را بر مبناي اين مدل اندازه گيري مي کنند.
حسن اين مدل آن است که در تمامي جنبه ها (9 معيار) و به صورت جزيي (در سطح زيرمعيارها و يا نکات) ، پارامترهاي کي�?ي سازمان را به صورت کمي تبديل کرده و اندازه گيري مي نمايد. سپس با گر�?تن يک ميانگين وزني از بين اندازه گيريهاي صورت گر�?ته، يک مجموعه عدد نهايي براي سازمان بدست مي آيد که نشان دهند جايگاه آن سازمان در زمينه تعالي است.
نکته جالب در این مدل آن است که این اعداد نهایی صر�?ا مهم نیستند، بلکه مجموعه مشاهدات ارزیابان که در قالب نقاط قوت و نواحی قابل بهبود برای هر نکته ای تدوین می شود هم در نهایت راهگشای سازمان برای تدوین برنامه های استراتژیک خود برای بهبود سازمانی است. بگذارید بحث بیشتر در مورد این مدل را از متخصصان آن بدانیم پس براي اطلاعات بيشتر در اين زمينه مراجعه شود به سايت www.efqm.org  و يا www.eraghi.com
در رادمان برای انجام �?رآیند ارزیابی و یا خودارزیابی با همکاری شرکت مشاوران تعالی سازان، نرم ا�?زاری ساخته ایم به نام EFQM Accelerator که در یک معماری تحت وب به طور همزمان قابلیت انجام ارزیابی حر�?ه ای و هم خودارزیابی را به مجموعه مورد نظر می دهد. این نرم ا�?زار که به صورت ASP: Application Service Provider در اختیار سازمانها قرار می گیرد، پس از انجام ارزیابی، امکان هماهنگ سازی نظرات را بر مبنای پارامتر های آماری و در نهایت اجماع را �?راهم ساخته و کارنامه نهایی گروه های خود ارزیابی و  یا کل سیستم را آماده می کند و در نهایت قابل کلی گزارش ارزیابی سازمان بر اساس مدل سرآمدي EFQM �?راهم می شود.
برای اطلاعات بیشتر مراجعه شود به مطالب مرتبط EFQM در وب سایت رادمان:
-بخش معر�?ی EFQM Accelerator
- کاتالوگ سیستم (�?ایل PDF)
- دموی سیستم (یک اسلاید PDF شده)

همین!

خوش به حال فرانسوی ها! در خبر ها آمده بود:رشته پولساز فرانسه،  انفورماتیک، مخابرات و بازرگانی در صدر.
در ميان فارغ التحصيلان رشته هاي گوناگون دانشگاههاي فرانسه، متخصصان رشته‌هاي انفورماتيک، مخابرات و مولتي مديا با درآمدي معادل 29 هزار يورو در سال (2416 يورو در ماه) بالاترين ميزان درآمد را نسبت به ساير فارغ‌التحصيلان دارا مي باشند.
خوش به حالشان!

همین!

مصاحبه وحید هاشمیان را خواندم. در جایی از مصاحبه، ارجاعی شده بود به وب سایت شخصیش(www.hashemian.net)  که گویا این بازیکن ملی ، علاقه دارد به جز اطلاعات شخصی خود در وب سایتش اخبار فرهنگی و آموزشی هم بگذارد. سری زدم به سایت این بازیکن فوتبال. صفحه اول هم همان عنوان "سایت خبری، فرهنگی و آموزشی" را داشت و در صفحات بعدی، رویکرد خبری ورزشی کاملا به چشم می خورد؟
اینکه ایده اینکار از کجا آمده که یک فرد معروف، وب سایت خودش را با محتوی عمومی پرکند  را نمی دانم خودش داده است و یا شرکت کامپیوتری سازنده یا مشاورانش طرح کرده ؟ اما به هر حال ایده جذابی است.
استفاده از یک دامنه شخصی به نام یک فرد مشهور به خودی خود عامل جذابیتی است که علاقه مندان وی با جستجو در موتورهای جستجو به این سایت برسند و سری بزنند به آن سایت. افراد مختلفی به این سایت لینک بدهند و در دایرکتوری ها به عنوان یک سایت مرجع ثبت شود. در کنار این وجود محتوی پویا و کلی باعث می شود که این مراجعه فقط محدود به یکبار نشود و مراجعات بعدی هم صورت گیرد. از طرف دیگر وجود کلمات کلیدی متعدد در محتوی سایت، رتبه جستجو را برای این سایت بالا می برد.
این عوامل در کنار هم باعث پربیننده تر شدن سایت شده و می توان از آن طریق تبلیغات نیز داشت (کما اینکه در این سایت هم همین چیز پیش بینی شده است) و کسب منافع مالی حتی به اندازه هزینه نگهداری سایت را مد نظر قرار داد.

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

همین!

قسمت سوم، مجموعه "نیروی انسانی به عنوان یک سرمایه" که به موضوع مدیریت دانش سازمانی اشاره  می کند مورد توجه سرویس نگاهی به وبلاگ های سایت خبرگزاری دانشجویان ایران (ایسنا) قرار گر�?ته است و تحت عنوان "نیروی انسانی با تجربه محل انباشت دانش سازمانی است" در آنجا منتشر شده است.
ایده نگاهی به وبلاگ ها، در یک سایت خبری ، ایده جالبی است. برای آن مجموعه آرزوی مو�?قیت می کنم.

همین!

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

دلایل مرگ نرم افزار را می توان در موارد زیر برشمرد:
- تغییر نیازهای سازمان استفاده کننده
- عدم پشتیبانی سازنده
- ارتقاء تکنولوژی و فنآوری ساخت و یا محیط استفاده (نرم افزاری و یا سخت افزاری)
- نقص نرم افزار (علی الخصوص نقص های غیر قابل برطرف شدن)
- به بازار آمدن نرم افزار با قیمت مناسبتر و یا کیفیت برتر
- مشکلات قراردادی بین خریدار و فروشنده که گاهی به لغو پروژه ساخت و کنارگذاشتن محصول آماده شده می گردد.
-...
دقت شود در برخی موارد فوق نرم افزار به صورت کامل از بین نمی رود، بلکه زمان استفاده از آن برای یک مشتری خاص به پایان می رسد که می توان آن را به مرگ آن نسخه  خاص از نرم افزار تعبیر کرد. شاید بهتر باشد به جای لغت Software Death  از Software Shoutdown  برای این پدیده استفاده کرد. به هر حال، باید پذیرفت که نرم افزار هم روزی می میرد. اما نکته مهم آن است که در مورد مرگ نرم افزار چه باید کرد؟
باید پذیرفت، آنقدری که در مورد تولد نرم افزار کار شده است (در قالب فرآیندهای ساخت سیستم و متدولوژی های تحلیل، طراحی و پیاده سازی) و یا در مورد رشد و نگهداری نرم افزار(در قالب فرآیند های پشتیبانی و نگهداشت نرم افزار)، در مورد مرگ نرم افزار کار نشده است و متخصصان نظر نداده اند.
چرا برای مرگ نرم افزار باید فکر کرد؟ پاسخ روشن است، تاثیری که مرگ یک نرم افزار روی تولید کننده و یا مصرف کننده می گذارد. تاثیری که شاید اهمیتش کمتر از مرگ واقعی یک انسان برای آن مجموعه ها نباشد.

همانگونه که یک انسان پیش از مرگ باید وصیت کند و حساب خودش را با سایرین روشن کند (به اصطلاح حلالیت بطلبد) و پس از مرگ هم، نزدیکان باید مراحل کفن و دفن را به طور کامل انجام دهند، در هنگام مرگ یک نرم افزار باید عمل نمود!
به من ایراد نگیرید که اینها چیست می نویسم، صبر کنید، توضیح می دهم!
از پارامتر های که در کیفیت نرم افزار مود توجه قرار می گیرد بحث جامعیت یا Integrity است. این پارامتر به محافظت نرم ا�?زار از اجزاء خود در مقابل دسترسی های مجاز و غیر مجاز بر می گردد. بدین شکل که یک نرم افزار باید مکانیزم های امنیتی (security) و ایمنی (Safety) مختلفی را برای مخفی سازی جزییات و ساختار داده های خود رعایت کنند.
این پارامتر در مدت زمان حیات نرم افزار منطقی است و رعایت آن توسط هر نرم افزار حسن آن محسوب می شود. چون باعث می شود نرم افزار در مقابل دسترسی ها مستحکم باشد و نتوان به سادگی آن به آن نفوذ کرد و ساختارهای اطلاعاتی و عملیاتی آن را کشف کرد.
اما زمانی که یک نرم افزار از چرخه کاری سازمان خارج می شود (به اصطلاح همان مرگ) تکلیف چیست؟ در آن موقع باید در صورت لزوم اطلاعات از نرم افزار خارج شده و در قالب جدید و یا نرم افزار جدید قابل بارگذاری بشود و در مواردی تکلیف الگوریتم های پیجیده روشن شده و روش کار آنها در اختیار کاربر قرار گیرد تا بتواند در سیستم جدید احتمالی آن ها را استفاده کند، از سوی دیگر چنین نرم افزاری باید به صورت کامل از سازمان کاری فعال حذف شود بدون آنکه آسیب جدی به فرآیندهای جاری وارد نماید. به عبارت دیگر همانگونه یک نرم افزار را از روی یک دستگاه Uninstall می کنیم و با اینکار همه اجزاء نرم افزار از روی کامپیوتر برداشته می شود. به همان شکل هم باید بتوان یک نرم افزار را از روی یک سازمان Uninstall نمود.
با این توضیح، بهتر است یک نرم افزار هنگام مرگ خود کارهای زیر را انجام دهد (تسویه حساب و وصیت کردن میت!) :
- افشای ساختارداده خود در حدی که بتوان داده را از سیستم به سیستم دیگر انتقال داد.
- ارسال اطلاعات به یک فرمت استاندارد (برای مثال XML ) برای فراهم سازی امکان Import/Export
-افشای متن برنامه و علی الخصوص الگوریتم های پیچیده در صورت عدم متن باز (Open Source) بودن برنامه در حدی که بتوان روابط علی و معلولی تراکنش ها و ورود اطلاعات تا تهیه گزارشات را شناسایی کرد.
-معرفی همه بخش های خود برای آنکه با Uninstall کردن آنها از روی سیستم های سرور و استفاده کننده
-از کار افتادن بخش ها به صورت تدریجی و نه مقطعی برای عدم اخلال در کارهای جاری سازمان
-...
و یک تیم متخصص تولید کننده بایستی موارد زیر را در قبل و بعد از مرگ یک نرم افزار مد نظر قراردهند:
- فراهم کردن امکانات ساختاری برای زمان مرگ نرم افزار (موارد فوق)
- ارائه خدمات پشتیبانی در زمان آغاز فرآیند از کار انداختن نرم افزار (فرآیند تجاری)
- انتشار کد نرم افزار به صورت عمومی و یا خصوصی در صورت خاتمه همه فعالیت ها روی آن نرم فزار
-فراهم ساختن امکاناتی برای افزایش طول عمر نرم افزار از جمله قابلیت های توسعه، گسترش، انعطاف و سازگاری
- ...
وبرای یک استفاده کننده در زمان حذف یک نرم افزار سازمانی از چرخه کاری توصیه می شود:
- عدم شیفتگی در مقابل فنآوری های نوین، لزومی ندارد با هر ارتقاء نرم فزار و سخت افزار، نرم افزاری سازمانی ارتقآء یابد و یا جایگزین گردد.
- دقت در زمان مرگ نرم افزار: سازمانها پس از مدتی استفاده از یک نرم افزار، به شدت به آن وابسته می شوند و عوض کردن آن هزینه زیادی تحمیل می کند. تشخیص زمان درست کنارگذاشتن یک نرم افزار و جایگزینی آن و محاسبه تاثیرات و هزینه های احتمالی آن بسیار مهم است تا سازمان به صورت آگاهانه اقدام به انجام این کار بنمایند.
- دقت در زمان خرید نرم افزار: چنانچه نرم افزاری حساس خریداری می شود، فقط به موارد زمان راه اندازی توجه نشود، این شرط لازم است ولی کافی نیست. بهتر است در مورد آنکه آن نرم افزار در صورت نیاز به حذف چگونه عمل می کند هم ی تواند به عنوان یک پارامتر تصمیم گیری مطرح شود (هر چند با وزن تصمیم گیری پایین تر از سایر موارد).
- بکارگیری یک متدولوژی و یک روش گام به گام برای حذف یک نرم افزار: با خرید یک سیستم جدید، در بسیاری از موراد نمی توان به صورت انقلابی سیستم جدید را جایگزین قدیمی کرد. بلکه باید در یک دوره زمانی و با اطمینان از صحت عملکرد سیستم جدید و انتقال اطلاعات به آن و تکمیل فرآیند آموزشی کاربران به مرور نرم افزار قدیمی را از کار بیاندازند.
- هر نرم افزاری بالاخره می میرد، منتظر مرگ آن نباشند، آن را نکشند و یا وادار به خودکشی نکنند!: اغلب دیده ام سازمانها نگاهشان به یک نرم افزار شبیه نگاه به یک آدم در بستر مرگ است، هر روز آرزوی مرگش را می کنند و یا با دستکاری آن، زمینه مرگش را ساده تر می کنند، حتی گاهی با ساخت دعواهای الکی یا بهانه گیری، کاری می کنند که یک فروشنده نرم افزار، خود دست به خودکشی نرم افزارش بزند و عطای سازمان را به لقایش ببخشد. همه اینها زمانی فاجعه است که نرم افزار بدون مشکل و یا با ایرادات جزیی کار کند، ایراداتی که بحرانی هم نیست و صرفا استفاده کننده به دلیل شرایط احساسی و یا علاقه به کم کاری و یا ارتباط با یک فروشنده دیگر، مایل به ادامه کار یک نرم افزار نیست. (این مورد را به وضوح در پروژه ای که چند ماه پیش مشاور و ناظرش بودم دیدم که یک مجموعه از طرف کارفرما، چون خودش مجری اصلی نبود، در کار پروژه اخلال ایجاد می کرد تا بتواند نرم افزاری که تازه کمتر از یکسال از بهره برداریش می گذرد را با یک سیستم جدید جایگزین کند)

و یک توصیه همدردانه با تولید کنندگان نرم افزار: هر نرم افزاری روزی می میرد، زیاد غصه اش را نخورید، به فکر تولد سایر نرم افزار ها و خلق نرم افزارهای جدید باشید!
همین!

در مطلب پيشين به اهميت نيروي انساني و اهميت نگرش سرمايه اي به آن در شرکتهاي نرم افزاري نوشته بودم.اينبار نگاهي خواهم داشت به نگاه سازمانهاي مدرن به اين مطلب، بدون آنکه بخواهم وارد جزييات تئوريک آن بشوم. اماقبلش از کامنت شخصي به نام مهسا تشکر مي کنم که هر چند ايميل من را به عنوان ايميل خودشان وارد کرده اند اما به نکته مهمي اشاره کرده اند که در اين مطلب به آن اشاره مي کنم.
اما بعد ....
با جدي تر شدن بحث اطلاعات در سازمانها و نگرش جدي به آن و با توجه به اهميت نيروي انساني و تجاربي که در بازه زماني کسب مي کند، بحث ايجاد سيستمهاي مديريت دانش پيش آمد. سيستمهاي مديريت دانش (Knowledge Managment ) سيستمها، موظف به ثبت و به روز نگهداري تجربيات افراد در سازمانها را بر عهده دارند.
دکتر زرگر در کتاب اصول و مفاهيم فنآوري اطلاعات ، "مديريت دانش را متشکل از استراتژيهاي مديريت، روشها و فن آوري براي مديريت سرمايه معنوي و روشهاي سيستماتيکي که موجب توسعه عملکرد منابع انساني در سازمان و موقعيت برتر آن در رقابت" مي داند و در جايي ديگر اشاره مي کند که "مديريت دانش عبارت است از فرآيند جمع آوري دانش متعلق به سازمان، تجزيه تحليل و انتقال آن در  فرمهاي ساده براي مصرف انبوه است"
یکی از محل های انباشته شدن دانش سازمانی، نیروی انسانی باتجربه است.  این تجربه که در طول زمان بدست آمده است، در صورت شناسایی و نگهداری به دانش سازمانی مناسبی تبدیل خواهد شد که می تواند در اختیار سایر کارکنان -علی الخصوص کارکنان جدید- قرار گیرد.
این مدیریت دانش اگر چه در سازمانهای مدرن امروزی به صورت نرم افزاری و مکانیزه صورت می گیرد. اما در سازمان ها مسبوق به سابقه است. در مدل سازمانهای ژاپنی، افراد بازنشسته از کار برکنار نمی شوند -درست بر عکس ایران- بلکه از کار اجرایی کنار رفته و در قالب یک کار مشاوره ای در کنار کارکنان جوان قرار گیرد و آنها را هدایت نماید.
اما ویژگی های یک شرکت نرم افزاری در مدیریت دانش چیست؟

یکی از ویژگی های اصلی در پروژه های نرم افزاری آن است که ما به مفهومی که در سایر پروژه ها موجود است تجربه موفق (Best Practice) نداریم. تجربه های موفق، به حاصل تجربیات یک فرد یا گروه در یک پروژه اطلاق می شود که از آن می توان درس گرفت و سایر پروژه ها را به خوبی انجام داد. مشخص است که به دلیل رشد سریع تکنولوژی و تغییر متدولوژی های تولید، کمتر بتوان از این تجربیات استفاده نمود. برای مثال چنانچه یک پروژه به صورت ساختیافته و با متدولوژی SSADM ساخته شود، از تجربه آموخته شده کمتر می توان در یک پروژه شیء گرا با متدولوژی RUP بهره برد. در مورد ابزارها هم همینطور است. تنها جایی که شاید بتوان در یک پروژه تولید نرم افزار به خوبی ثبت نمود، اول بحث طراحی مفهومی و معماری نرم افزار است و بعد بحث مؤلفه های ساخته شده در یک پروژه است که اگر به شکل مناسبی ساخته شده باشند می تواند به عنوان عاملی برای انتقال دانش از یک پروژه به پروژه دیگر استفاده شود.
بر خلاف پروژه های تولید نرم افزار، در بخش های دیگر می توان دانش را از یک فرد به فرد دیگر به صورت مدون منتقل نمود. برای مثال در بخش های مهندسی فروش، با تهیه طرح های فروش و بازاریابی و تدوین متدولوژی مهندسی فروش و یا در بخش پشتیبانی نرم افزار با تهیه مستندات پشتیبانی، مجموعه پاسخ به پرسشهای متداول (FAQ) و راهنماهای خطایابی اینکار شدنی است.
بنابراین به مدیران بخش های فنآوری اطلاعات و ارتباطات و مدیران شرکت های نرم افزاری پیشنهاد می شود با در پیش گرفتن راهکاری مناسب بحث انتقال تجربه و تبدیل آن را به دانش سازمانی را به ویژه در بخشهای تولید جدی بگیرند و با ایجاد یک رویه مدیریت ریسک مناسب، از بروز خطاهای ناشی از جابجایی نیروی انسانی و یا ترک کار وی جلوگیری کرده و یا آثار و تبعات ناشی از آن را کاهش دهند.
دو روش عمده برای اینکار پیشنهاد می شود:
- روش کلاسیک: مستند سازی نرم افزار و بعد مدیریت مستندات توسط مدیر پروژه، تشکیل کمیته های محصول و یا دوره های بازآموزی
- روشهای مدرن تری نظیر PairProgramming در متدولوژی های XP که تولید را برای هر کامپیوتر دو نفر در نظر می گیرند تا در همان هنگام توسعه، فرآیند توسعه و انتقال دانش را نیز انجام دهند.

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

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

1- همه ما نرم افزاری ها،  محصولاتمان را مانند بچه هایمان دوست داریم، چرا مانند مراقبت از اطفال برای پشتیبانی نرم افزار عمل نکنیم؟
2- هفته هایی که گذشت به خاطر یکی از آشنایان، گذرم به صورت مداوم به بیمارستان ..... افتاد، مطابق معمول کنجکاویم گل کرد و سری زدم به بخش های اطلاعاتی آنها و نحوه نگهداری از بیماران، سرویس های منظم و غیر منظمی که باید به بیمار بدهند و نحوه تبادل اطلاعات بین دو پرستار از دو شیفت مختلف و پرستار با پزشکش و .....[مطمئن هستم که بسیاری از شما متاسفانه  حداقل حضوری به عنوان یک بیمار ، همراه بیمار و یا یک ملاقات کننده به بیمارستان داشته اید و می توانید وضعیت را در ذهنتان شبیه سازی کنید.]

3- اگر چه می توان برای بدست آوردن الگوی مناسب برای پشتیبانی از صنایع نیز بهره بردای کرد (سیستم های تعمیر و نگهداری معروف به سیستمهای PM الگوی بسیار مناسبی برای پشتیبانی از یک محصول می باشند.) اما شاید ماهیت نرم افزار نیاز به نگهداری دقیق تر و حساس تری دارد.
با ذکر این سه نکته، شاید تشکیل یک بیمارستان نرم افزار برای محصولات تولیدی یک شرکت و یا در ایده کلی برای یک سری محصولات معروف ایده بدی نباشد. این بیمارستان می تواند به بخش های زیر تقسیم شود:
- بخش CheckUP : در این بخش طی یک سری بازدیدهای مشخص (به صورت متناوب و طی یک الگوی زمانبندی و یا به صورت مداومی) سیستم نرم افزاری چک می شود تا از سالم بودن آن اطمینان حاصل شود. این چک شدن از طریق آزمایش های مختل�? صورت می گیرد، بررسی رفتار نرم افزار در مقابل ورودی های مختلف و بررسی LOG File های عملکرد نرم افزار، بررسی رفتار گذشته نرم افزار، شبیه سازی حالات خطا و سنجش عملکرد نرم افزار نسبت به آن، سنجش میزان حافظه استفاده شده و پیش بینی میزان مورد نیاز در آینده برای جلوگیری از بروز خطا در آینده، سنحش قدرت سخت افزار مورد نیاز از طریق گزارشهای مورد نیاز و ارائه به صاحب نرم افزار برای تقویت احتمالی سخت افزار، بررسی استفاده های غلط از نرم افزار و ارائه راهنمایی های لازم برای کاربری صحیح و ....
- بخش اورژانس: در این بخش برای نرم افزارهای بحرانی در زمان بروز خطاهای بحرانی ، پیش بینی لازم صورت می کیرد. ارائه خدمات پشتیبانی به صورت ONline ، مراجعه به محل استفاده نرم افزار و رفع خطای بحرانی آن، وجود متخصصان کشیک برای فراخوانی به صورت Oncall در هنگام بروز خطا و معرفی به سایر بخش های بیمارستان نرم افزار پس از رفع خطاهای بحرانی و تثبیت فعالیت های جاری نرم افزار برای انجام اصلاحات اساسی تر
- بخش های نگهداری: این بخش ها می تواند شامل بخش های متفاوتی باشد، اما نکته یکسان در همه آنها، نگهداری و رفع عیب اصولی نرم افزار در صورت بروز خطا می باشد. در این بخش ها با سرکشی منطم، وضعیت نرم افزار در یک بازه زمانی سنجیده می شود و نواحی بحرانی شناسایی می شود و قبل از بروز خطای جدی اصلاح می شوند. (علاج واقعه قبل از وقوع) نرم افزارهای معرفی شده از بخش های دیگر ، در این بخش (ها) مورد مطالعه جدی تر قرار گرفته و اشکالاتشان از طریق اصلاح ساختاری نرم افزار (درست مانند یک عمل جراحی و یا پیوند) و یا غیر ساختاری (مانند دارو ها و جراحی های سرپایی) برطرف می شود.
- بخش زایمان[!]: خدا را شکر بیمارستان ما فعلا این بخش را ندارد!

نکته مهم در این بیمارستان تهیه یک CPR از نرم افزارهاست. CPR مخفف Clinical Patient Record است که حاوی اطلاعات بالینی بیمار است که به دفت و با نظم خاصی تهیه می شود و به عنوان عاملی برای هماهنگ سازی خدمات بالینی بیمارستان استفاده می شود. به نحوی که هر خدمتی که بیمار دریافت نمود و یا هر تغییر وضعیتی که در بیمار رخ داد در آن ثبت می شود تا همه افراد مسؤول -برای مثال پزشک برای پرستاران و یا افراد یک شیفت کاری برای شیفت دیگر- از آن مطلع شوند و از انجام دوباره کاری و یا تجویز های غلط جلوگیری نمایند.
با تشکیل این پرونده و راه اندازی یک HIS: Hospital Information System می توان وضعیت بیمار را به صورت online بررسی نمود و از گم شدن و یا اشتباه شدن ورود اطلاعات جلوگیری نمود.
راه اندازی چنین سیستمی برای بیمارستان نرم افزار ما هم بسیار راهگشا است. هر چند می دانم که بسیاری از شرکتها برای ارائه خدمات پشتیبانی به نرم افزارهای خود، چنین پرونده ای را برای هر مشتری تشکیل داده اند، اما متاس�?انه در بسیاری از موارد خیلی خوب پرونده ها تشکیل نمی شود و یا به روز نمی شود و یا به اشتراک گذاشته نمی شود.
به نظر من در بخش پشتیبانی، نگاه انسانی به نرم افزار، نگاه مناسب تری است نسبت به نگاه صنعتی. یادتان باشد پیشتر در مورد تولد، حیات و مرگ نرم افزار نوشته بودم. این نگاه شاید جدی تر و حساس تر به مساله پشتیبانی نگاه کند و استفاده کنندگان نرم افزار هم راحت تر با آن کنار بیاییند.
این ایده هم مانند ایده Software FastFood نیاز به کار بیشتری دارد تا پخته شود. شاید هم ماننده همان قبلی، قبلا کسی رویش کار کرده باشد، هنوز جستجو نکرده ام، به هر حال دوست دارم روی مساله پشتیبانی نرم افزار بیشتر کار کنم. شاید به زودی یک دسته بندی جدید به همین نام در وبلاگ تشکیل دادیم، شاید ....
همین!