۱۳۸۹ مهر ۱۵, پنجشنبه

مدلسازی و پیاده سازی قواعد کسب و کار

این ترم یک درسی داریم به نام طراحی سیستمهای مدیریت قواعد کسب و کار که توسط لارش فرنبرو تدریس میشه. راستش برام جالب بود این درس. چون ما توی پروژه های معماری سازمانی این بحث قواعد کسب و کار رو به عنوان یکی از ابعاد معماری سازمانی داریم و معمولا کار زیادی براش انجام نمی دادیم. توی معماری بر اساس چارچوب زکمن که فقط از دیدگاه طراح کسب و کار یه کمی از راهبردها و اهداف راهبردی و این حوزه ها صحبت می گردیم و اگه خیلی می خواستیم کامل کار کنیم از مدل BMM, OMG استفاده می کردیم برای اینکار ولی توی حوزه تعریف قواعد کسب و کار، کار خوبی انجام نمی شد. چون خروجیهاش کاربرد زیادی برای کسب و کار یا پیاده سازی سیستمها نداشت. یادمه حتی ما وقتی مبتنی بر چارچوب DoDAF کار می کردیم و محصولات OV-6a , SV-10a که خاص قواعد کسب و کار و سیستم هستند رو تولید می کردیم محصولات پیشنهادی DoDAF برای OV-6a همون انگلیسی ساختیافته بود و برای SV-10a هم زبان مدلسازی مثل درخت تصمیم و اینها مطرح می شد که ما معمولا به دلیلی که بالا اشاره کردم سراعش نمی رفتیم. جالب هستش برام توی این درس که استادش اتفاقا معماری سازمانی هم درس می ده بر اساس کتاب اخیر فینکل اشتاین، ببینم چه نسخه ای برای حوزه قواعد کسب و کار داده میشه. از اول ترم بحثهای مختلفی مطرح شد از جمله:
1- مدلسازی مفهومی کسب و کار (Conceptual Model) که یه جورایی موجودیتها و روابط بین اونها رو از منظر قواعد کسب و کار توصیف می کنه
2- همینطور مدل Term-Fact که همون انگلیسی ساختیافته خودمون بود توی OV-6a در چارچوب DoDAF اینها بقول خود لارش برای پوشش به دیدگاه های کسب و کار بکار می رند (که به اعتقاد من برای پوشش به دیدگاه برنامه ریز کسب و کار باید استفاده از BMM هم مدنظر قرار بگیره با توجه به اینکه توی BMM جایگاه قواعد کسب و کار که مربوط به دیدگاه مالک کسب و کار هستش )
3- استفاده از ابزارهای پیاده سازی قواعد کسب و کار مثل Prolog که برنامه نویسی Declarative  رو برای مدلسازی قواعد و تعریف روابط تجربه کردیم
4- پیاده سازی قواعد کسب و کار با استفاده از ابزارهای جدید و پیشرفته مثل Visual Rules و برقراری ارتباط اون با سیستمهای مدیریت پایگاه داده مثل SQLServer رو یاد گرفتیم

و در نهایت چیزی که امروز جمع بندی کردیم از مقوله های ارائه شده این بود که اگر رویکرد اجرای پروژه های بعد از معماری سازمانی برای پیاده سازی سیستمها استفاده از این فناوری ها باشه، خوب مدلسازی قواعد کسب و کار در معماری سازمانی می تونه بسیار مفید باشه. حتی اگه رویکرد استفاده از ابزارهای خیلی پیشرفته هم مطرح نباشه استفاده از مدلسازی قواعد کسب و کار تا حد زیادی به افزایش دقت در پیاده سازی قواعد کسب و کار و سهولت در نگهداشت اون منجر میشه. البته استراتژی استفاده از ابزارهای پیاده سازی قواعد کسب و کار بر اساس مسائل مختلفی مثل معماری نرم افزار، پیچیدگی قواعد کسب و کار، نرخ تغییرات اونها، ویژگیهای کیفی سیستمها و ... می تونه متفاوت باشه که میشه توی کتاب مورگان(Morgan) بیشتر راجع بهش مطالعه کرد. همچنین جمع بندی دیگه ای که من داشتم و مورد تأیید لارش هم بود اینه که برای پوشش به مراحل مختلف مدلسازی قواعد از دیدگاه کسب و کار، منطق سیستمی و فناوری های پیاده سازی متدولوژی یکپارچه و مدونی وجود نداره. حتی زبان مدلسازی و ابزارهای استانداردی که همه مراحل رو پوشش بده هنوز وجود نداره گرچه OMG فعالیتهای خوبی داره انجام می ده و این موضوع رو به  پیشرفت هستش. من شخصا استفاده از مدلسازی کسب و کار و ابزارهای پیاده سازی پیشرفته رو برای تولید و نگهداشت سیستمهایی با قواعد پیچیده و متعدد و نرخ تغییرات بالا (مثل سیستم حقوق و دستمزد یا سیستمهای مالی و بانکی) مفید می دونم. گرچه باید در استفاده از روش و استاندارد و ابزارهای پیاده سازی دقت فراوانی کرد و ازتجارب موفق و آزمایش شده استفاده کرد. البته با توسعه معماری سرویس گرا استفاده از موتورهای مدیریت قواعد کسب و کار (Rule Engine) خیلی مفید و کاربردی به نظر می رسه. اینه که توسعه سیستمهای سرویس گرا با رویکرد مدلسازی قواعد کسب و کار الان مورد توجه قرار گرفته که می تونید مطالب خوبی در کتاب مدیریت قواعد کسب و کار و معماری سرویس گرا نوشته آقای یان گراهام (Ian Graham) ببینید.

۱۳۸۹ مهر ۱۰, شنبه

Enterprsie 2.0 Architecture

امروزه مفهوم Enterprise 2.0 که مبتنی بر قابلیتها و فناوریهای WEB 2.0 شکل می گیره توی دنیا خیلی جدی مطرحه. ارکان و بخشهای اصلی این نوع Enterprise مفاهیم نوینی هستند که بر پایه نسل دوم اینترنت یعنی اینترنت بین افراد تعریف می شن. اگر نسل اول اینترنت رو اینترنت بین صفحات بدونیم، نسل دوم، اینترنت بین افراد هستش که تبلورش ایجاد شبکه های اجتماعی مثل فیس بوک و ... هستش و الان حتی نسل سوم اینترنت و بالتبع اون Enterprise 3.0 رو اینترنت اشیاء تعریف میکنند. که توی این نوع اینترنت این اشیا هستند که توی شبکه با هم قرار می گیرند و تعامل می کنند مثلا موتور اتوموبیل شما به کمپانی سازنده اش متصل میشه و از طریق نرم افزار عیب یابی،عیبش رو پیدا میکنه و اگه بشه بصورت تنظیم نرم افزار مشکل رو حل کرد خودش برنامه رو دانلود می کنه و خودش رو تنظیم می کنه و مشکل حل میشه. Enterprise 2.0 در واقع شکل گیری شبکه هایی برای ثبت و به اشتراک گذاری اطلاعات و دانش بصورت غیر رسمی در سازمانها است که در خلال اون دانش و اطلاعات بصورت غیر رسمی و غیر ساخت یافته شکل و ساختار پیدا می کنه. نمونه های این نوع سازمانها، سازمانهایی هستند که افراد اطلاعات رو در ویکیها و وبلاگهای شخصی ثبت و تگ گذاری می کنند و بدین ترتیب مجموعه غیر ساخت یافته ای از اطلاعات پدید میاد که میشه از اون استفاده کرد به نفع سازمان. مسأله ای که وجود داره اینه که در این نوع از سازمان، تعاریف و مرزهای رسمی و سنتی سازمانی تغییر می کنه. فرض کنید اطلاعات سازمانی توی بلاگ شخصی یکی از کارمندان آزادانه ذکر بشه در صورتی که سازمان نخواد اون اطلاعات به یک مشتری یا رقیب یا هر کس دیگه ای برسه. یا مثلا اطلاعات راجع به افراد با نفوذ سازمان منتشر بشه. خوب شکل مدیریت و هدایت این سازمانها متفاوت هستش و باید باشه. در اینجا این مسأله مطرح میشه که اصولا معماری Enterprise 2.0 چجوری باید انجام بشه. آیا از همون ارکان معماری سازمانی معمولی میشه استفاده کرد یا چارچوب و مفاهیمش متفاوته. این ایده یکی از دوستان خوبم اقای احمدی بود. به هر حال این موضوع جای کار زیاد داره و حتی در شکل جدیدتر Enterprise 3.0 شیوه معماری چجوری میشه؟ اگر علاقه مند باشید می تونیم روی این موضوعات بحث کنیم.

۱۳۸۹ شهریور ۱۳, شنبه

شروع مجدد در فضای جدید

با سلام به همه دوستان عزیز. من یه دوره ارشد سیستمهای اطلاعاتی رو در دانشگاه لوند شروع کردم و می خوام در این فضای جدید دوباره نوشتن بلاگ رو شروع کنم. امیدوارم بتونم مطالب جدیدی رو به رویکردهای قبلی اضافه کنم.

۱۳۸۹ فروردین ۹, دوشنبه

معماری سازمانی مسأله محور- Problem Oriented Enterprise Architecture

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

۱۳۸۸ بهمن ۱۱, یکشنبه

دلایل عدم اجرای نتایج معماری سازمانی (3)

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

۱۳۸۸ دی ۳۰, چهارشنبه

دلایل عدم اجرای نتایج معماری سازمانی (2)

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