<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های Farazinux</title>
        <link>https://virgool.io/feed/@farazinux</link>
        <description>اسیر عرصه تحلیل داده</description>
        <language>fa</language>
        <pubDate>2026-06-10 12:32:21</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/6638/avatar/avatar.png?height=120&amp;width=120</url>
            <title>Farazinux</title>
            <link>https://virgool.io/@farazinux</link>
        </image>

                    <item>
                <title>آیا به همه داده ها نیاز داریم؟!</title>
                <link>https://virgool.io/@farazinux/%D8%A2%DB%8C%D8%A7-%D8%A8%D9%87-%D9%87%D9%85%D9%87-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7%DB%8C-%D9%86%DB%8C%D8%A7%D8%B2-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85-vt2oyj37icxr</link>
                <description>سازمان عاشق داده ها هستند: اعداد، گزارش ها، روندهای فروش، گراف ها و ..هرچه بیشتر، بهتر! و در نهایت بسیاری از سازمان ها یک کارخانه داخلی قابل توجه برای تولید انبوه داده دارند و در کنار آن منابع خارجی نیز در قبال سایر سوالات و درخواست های داده محور وجود دارند. ولی آیا نشانه ای مبنی بر این که این داده ها منجر به یک تصمیم بهینه در کسب و کار شده باشد، وجود دارد؟! آیا بخشی از داده هایی که جمع آوری می شوند غیرضروری نیستند؟ آیا به منجر به پیچیدگی و ابهام بیشتری نمی شوند؟!اجازه دهید که به یک مطالعه موردی بپردازیم: برای سال های متمادی مدیرعامل یک شرکت تولید کننده مواد مصرفی بر روی اجرای فرآیند گزارش های کسب و کار ماهیانه اصرار داشت، گزارش هایی که نیاز به داده های زیادی داشت. این گزارش ها در واقع تبدیل به یک کتاب شده بودند که داده های مربوط به هزینه، فروش و توزیع تولیدات کارخانه در واحدها، کانال ها و شعب مختلف را شامل می شد. این کتاب ( اگر چه به صورت الکترونیکی بود ولی همیشه برای تیم های اجرای پرینت گرفته می شد!) چندین اینچ قطر داشت! این گزارش ها به صورت ماهیانه توسط صدها نیروی مالی، مدیریت محصول و فناروی اطلاعات تهیه می شد و در مجموع هزاران ساعت را صرف جمع آوری، ارزیابی، تحلیل، تطبیق و مرتب سازی این داده ها می کردند.از آنجایی که فرآیند تهیه این گزارش ها توسط مدیرعامل درخواست شده بود، هیچ کسی نمی پرسید که آیا این گزارش ها واقع ارزشمند هستند یا خیر، در حالی که همیشه به مدت زمان مورد نیاز برای تهیه این گزارش ها معترض بودند. پس از چند سال، یک مدیرعامل جدید روی کار آمد و تصمیم گرفت که کسب و کار را بر اساس بررسی های فصلی و بعضا گزارش های موردی پیش ببرد. پس از این تصمیم، تولید داده شرکت به شدت کاهش پیدا کرد در حالیکه شرکت چیزی را از دست نداد!واضح است که مدیرعامل های مختلف، نیازهای متفاوتی هم در خصوص داده ها دارند. بعضی از آن ها به هر آنچه که از داده های معتبر و اثبات شده قابل دسترسی است، نیاز دارند، برخی صرفا به داده هایی نیاز دارند که با آن ها از تصمیمات خود حمایت کنند یا آن ها را به چالش بکشانند و برخی دیگر ترکیبی از این دو حالت را ترجیح می دهند. با این وجود، در همه موارد ، مدیران بهتر است از خودشان چهار سؤال در مورد فرآیند پردازش یا به دست آوردن داده ها،  به عنوان راهی برای بهبود بازده آنچه که اغلب یک سرمایه گذاری اساسی (البته همیشه قابل مشاهده نیست!) است، بپرسند:1- آیا سوال درستی پرسیدیم؟بسیاری از شرکت ها از داده ها هر آنچه را که در دسترس می باشد، جمع آوری میکنند فارغ از اینکه آیا این داده ها به پیشبرد اهداف کسب و کار آن ها یا تصمیم گیری ها کمکی می کند یا خیر. پس به عنوان یک نقطه آغازین می بایست نسبت به سوال هایی کلیدی محدودی که می خواهید با استفاده از داده ها به آن ها پاسخ دهید، آگاهی کامل داشته باشید و بر اساس سوال ها، داده های مورد نیاز را جمع آوری کنید تا اینکه هر آنچه را که از داده ها در دسترس است، ذخیره نمایید.2- آیا داده های ما روایتگر  داستان کسب و کار ماست؟بیشتر داده ها به صورت بخش هایی جداگانه به دست ما می رسند. به منظور مفید واقع شدن می بایست این داده ها در یک قالب منسجم و متناسب با وضعیت کسب و کار و نیاز های آن در کنار هم قرار بگیرند تا بتوانند روایتگر داستان(وضعیت) کسب و کار باشند. اگر چه سیستم های اطلاعاتی سازمان در خصوص جمع آوری و ذخیره داده ها در یک روال ثابت عملکرد قابل قبولی دارند به نحوی که داده ها به مرور زمان در کنار یکدیگر قرار میگرند و قابلیت مقایسه نقاط مختلف از داده وجود دارد ولی توجه داشته باشید از این طریق به صورت خودکار داستان سرایی توسط داده ها شکل نخواهد گرفت. در عوض، مدیران می بایست با نگاه شگرف تری بررسی کنند که چه داده هایی نیاز دارند تا داستان مدنظرشان را روایت کنند.3- آیا داده های ما کمک می کنند تا به جای نگاه به گذشته، نگاه به آینده داشته باشیم؟اغلب داده هایی که در شرکت ها جمع آوری می باشد به مدیران می گوید که چه اتفاقاتی در گذشته رخ داده است و کارآیی بسیار پایینی در پیش بینی عملکرد آینده دارند. بنابراین، بسیار حائز اهمیت خواهد بود که بپرسیم چه داده هایی در چه بازه زمانی ای به ما کمک میکند تا به جای واکنش در لحظه به اتفاقات قابل مشاهده بر اساس داده ها، نمودار تغییرات را پیش بینی و خود را برای اتفاقات آینده آماده کنیم.4- آیا ما ترکیب مناسبی از داده های کمی و کیفی داریم؟داده های کیفی یا کمی به تنهایی نمی توانند روایتگر تمام داستان کسب و کار باشند. به عنوان مثال برای تصمیم گیری در خصوص ویژگی محصول خوب یا قیمت گذاری مناسب، ما علاوه بر اینکه نیاز داریم بدانیم چه محصولی به چه شخصی فروخته شده، می بایست بدانیم که کدام محصول ما بیشتر از بقیه فروش داشته است.جمع بندی:داده های کسب و کار و تحلیل آن ها برای موفقیت سازمان ها بسیار حیاتی هستند. شرکت های عظیمی مانند IBM این واقعیت را درک کرده اند و میلیاردها دلار صرف سیستم های هوشمندی کسب و کار و تحلیل داده های خود کرده اند. ولی حتی بهترین ابزارهای خودکار در این حوزه نیز به موفقیتی دست پیدا نخواهند کرد در صورتی که مدیران نسبت به 4 سوال بالا آگاهی کامل نداشته باشند.نویسنده : Ron Ashkenas - مشاور کسب و کار منبع : مبانی تجزیه و تحلیل داده ها برای مدیران - انتشارات Harvard Business Review </description>
                <category>Farazinux</category>
                <author>Farazinux</author>
                <pubDate>Wed, 25 Mar 2020 13:08:39 +0430</pubDate>
            </item>
                    <item>
                <title>آشنایی با  DataOps</title>
                <link>https://virgool.io/@farazinux/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-dataops-p5ofrkrlkzga</link>
                <description> در این نوشتار سعی خواهم کرد تا معرفی مختصری از DataOps‌ داشته باشم و به این موضوع بپردازم که چه لزومی دارد به سمت این مفهوم جدید حرکت کنیم.برای شروع تشریح مفهوم DataOps، فرض می‌کنیم شما با مفهوم DevOps آشنا هستید( در غیر این صورت شما را به تعریف یک خطی RackSpace از DevOps ارجاع می‌دهم که می گوید: رویکردی که در آن توسعه دهندگان نرم‌افزار با تیم عملیات پشتیبانی با یکدیگر همکاری می‌کنند تا به صورت مداوم، قابل اعتماد و استاندارد شده همراه با فرآیندهای خودکار نرم‌افزار و بستر مورد نیاز آن را ایجاد نمایند.)در نگاه اول به نظر می‌آید که DevOps‌و DataOps به دلیل اینکه هر دو برای پاسخ به نیاز مقیاس کردن تحویل سرویس (‌به عبارت بهتر پاسخ سریع به نیاز مشتری یا سازمان) ایجاد شده اند، خاستگاه یکسانی دارند.امروزه DevOps یک ضرورت برای مواجهه با چالش های تیم توسعه، اضافه کردن کدها به سیستم یا نرم‌افزار و در نهایت پیچیده‌تر شدن سیستم‌ها می باشد. DataOps‌ نیز یک ضرورت برای مواجهه با فضایی است که در آن با رشد روزافزونی تولید و توسعه پروژه های تحلیل داده در جریان می باشد. بنابراین تفاوت بنیادین بین این دو مفهوم وجود دارد: نقطه تأثیر این دو ! دواپس در حوزه توسعه و تحلیل سیستم‌ها و نرم‌افزارها مطرح می‌شود که شامل رسیدگی و بررسی مولفه ها، وابستگی‌ها و کانتینرها ( container‌) در چرخه حیات سیستم می شود. در این تعریف، چرخه حیات داده، جایی است که DevOps دغدغه  یا نگرانی درباره آن ندارد.  اگر ما از یک داشبورد اطلاعاتی مشتمل بر چارت‌ها یا سیستم‌های پیشنهاد دهنده استفاده کنیم، داده و اطلاعات بیش از پیش برای ما اهمیت پیدا می کند. واضح و مبرهن است که هر سیستم یا اپلیکیشن داده مصرف و تولید می‌کند.  یکی از اصلی‌ترین تفاوت‌های این دو مفهوم این است که داده همیشه در محیط عملیاتی وجود دارد. وقتی یک دانشمند داده بر روی مدل یادگیری ماشین در حال کار می باشد، پس به داده‌های بلادرنگ ‌(داده های عملیاتی) نیاز دارد. در‌واقع نیاز است تا تیم داده و تیم عملیات در مرحله راه اندازی و اساساً در کلیه مراحل پروژه با یکدیگر همکاری داشته باشند.انتخاب فرمت ذخیره سازها، مدل محاسباتی، مدل عملکرد، نظارت بر سیستم‌ها و سازوکارها و محدودیت‌های تکنلوژیکی، مواردی هستند که بدون نگاه از هر دو منظر ( داده و عملیات) نمی‌توان آن‌ها را به انجام رساند.اگر DevOps چابکی را برای سازمان به ارمغان می‌آورد، می‌توان ادعا کرد که نتیجه DataOps همکاری تنگاتنگ بین دو تیم یا دو واحد در یک سازمان می باشد. به عنوان مثال اگر تغییر ناگهانی در داده‌ها رخ دهد که بر اساس آن مدل سازی و تصمیم گیری در محیط عملیاتی صورت می گرفته است، تیم کسب و کار باید از این تغییر مطلع شود تا تغییرات لازم را سمت خود اعمال کند.در مجموع DataOps‌ وظایف زیر را شامل می‌شود :  خودکاری سازی سیر تکامل پلتفرمها، پروژه ها و محصولات، تبیین نحوه انجام تست در محیط های عملیاتی و نظارت فنی بر اساس معیارهای کسب و کار و در نظر گرفتن قابلیت‌های تطابق منابع فنی.زمانی می‌توان  DataOps‌را در یک سازمان مطرح نمود که میزان و تنوع داده ها، ارزش بیشتری نسبت به اپلیکیشن و سیستم‌های سازمان پیدا کند که با توجه به روند پیشرفت مباحثی نظیر اینترنت اشیاء، این زمان برای بسیاری از سازمان ها فرارسیده است یا نزدیک می باشد.  سؤال آخر این است که DataOps یک استاندارد است یا موقعیت شغلی؟ همانطور که اشاره شد DataOps در مورد قرار دادن و نگاهداری از داده ها، مدل ها، دانش و جریان های کاری در محیط عملیاتی می باشد. متناسب با اندازه سازمان و فرآیندهای آن ممکن است این وظایف به دانشمند داده یا مهندس داده نیز محول شود.ولی در نهایت، این وظایف نیاز به یک کمیته با دانش و آگاهی نسبت به سیستم‌ها و محیط های عملیاتی دارد که می‌توانند بر روی عمل‌کرد دانشمند یا مهندس داده تأثیر گذار باشند.  انتظار می‌رود که در آینده نه چندان دور، DataOps به طور گسترده و به خودی خود به عنوان یک موقعیت شغلی بیشتر مطرح شود.</description>
                <category>Farazinux</category>
                <author>Farazinux</author>
                <pubDate>Mon, 23 Apr 2018 23:07:27 +0430</pubDate>
            </item>
                    <item>
                <title>کارکرد مدیریت داده در سازمان</title>
                <link>https://virgool.io/@farazinux/%DA%A9%D8%A7%D8%B1%DA%A9%D8%B1%D8%AF-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D8%AF%D8%A7%D8%AF%D9%87-%D8%AF%D8%B1-%D8%B3%D8%A7%D8%B2%D9%85%D8%A7%D9%86-warsmkxtb3w6</link>
                <description>مدیریت داده که در برخی سازمان ها با عنوان CDO – Chief data office مطرح می شود، مسئولیت نظارت بر کلیه فعالیت‌های داده محور سازمان را بر عهده دارد. یکی از راه‌های نظارت بر این فعالیت ها، تفکیک آن‌ها به مولفه های مختلف مانند حاکمیت داده، استراتژی داده، استانداردهای داده و کیفیت داده می باشد. مولفه حاکمیت داده از این حیث اهمیت پیدا می‌کند که فعالیت‌های داده محور و متوالی را هدایت می‌کند مانند همکاری با تیم برنامه نویسی یا واحد مدیریت تغییر و پروژه ها. استراتژی داده به درک درست داده‌ها و استفاده کارآمد از آن‌ها در سازمان کمک می کند. استاندارد داده، مولفه ای در راستای حصول اطمینان از درک واحد از داده در  کلیه بخش‌هایی است که از داده‌های به اشتراک گذاشته شده، استفاده می کنند. این مهم از طریق تبیین و توسعه استاندارد برای عناصر و مدل های داده حاصل می شود.  مولفه کیفیت داده برای پاکسازی داده‌ها و حصول اطمینان از اینکه داده‌ها برای اهداف مورد نظر و از پیش تعیین شده مناسب باشد، به کار گرفته می شود. از همین رو در تمامی تصمیم گیری های سازمان به ایفای نقش می پردازد. تیم کیفیت داده باید همکاری نزدیکی با واحد استراتژی داده داشته باشد.  مدیریت داده از جمله کارکردها و واحدهای سازمان می‌باشد که باید همکاری تنگاتنگی با سایر واحد ها نظیر واحد کسب و کار و تیم های برنامه نویسی داشته باشد تا مطمئن شود که داده‌های مورد نیاز سایر واحد ها در راستای اهداف مورد نظر سازمان به درستی تأمین گردد.  مدیریت داده می بایست ویژگی‌های کلیدی زیر را دارا باشد :‌رهبری مشخص و حمایت از سوی مدیران ارشد سازماناهداف کلیدی داده محورتصویر کاملی از حوزه های مورد هدف به صورت اولویت بندی شدههمسو سازی عملکرد با اهداف اصلی سازمانمشخص نمودن دستاوردهای سازمانیدر پست های بعدی بیشتر در خصوص مدیریت کیفیت داده صحبت خواهیم کرد. </description>
                <category>Farazinux</category>
                <author>Farazinux</author>
                <pubDate>Mon, 23 Apr 2018 11:12:28 +0430</pubDate>
            </item>
                    <item>
                <title>درک اهمیت کیفیت داده</title>
                <link>https://virgool.io/@farazinux/%D8%AF%D8%B1%DA%A9-%D8%A7%D9%87%D9%85%DB%8C%D8%AA-%DA%A9%DB%8C%D9%81%DB%8C%D8%AA-%D8%AF%D8%A7%D8%AF%D9%87-rvxizsobehip</link>
                <description> دکتر گنیچی تاگوچی که به عنوان یک مهندس کیفیت در جهان مطرح می باشد، برای اولین به تبیین رابطه بین کیفیت پایین و ضرر حاصله از آن در کلیه بخش‌های یک سازمان پرداخت. تاگوچی  یک تابع برای اندازه‌گیری میزان ضرری که از این حیث به سازمان تحمیل می شود، معرفی کرد. این تابع که به اختصار QLF نامیده می شود، میزان ضرر و خسارت را بر اساس یک سری از متغیرهای قابل اندازه‌گیری محاسبه می‌کند. شکل زیر رفتار تابع مذکور را در صورتی که از نقطه مطلوب فاصله می گیرد، نمایش می دهد. لزوماً این تغییر در دو سمت نقطه مطلوب همواره متقارن نیست و ممکن است در برخی موارد شیب فاصله گرفتن از نقطه مطلوب تندتر یا کندتر از شکل زیر باشد. نتیجه این ضرر و زیان می‌تواند نتایجی مانند تجزیه سازمان یا ورشکستگی آن را به همراه داشته باشد.  در این شکل، نمایش داده شده که ضرر و زیان در صورتی که مشخصه های کیفیت از نقطه مطلوب m‌ فاصله بگیرد، افزایش خواهد یافت. این رابطه از طریق فرمول زیر قابل بیان می‌باشد :L(y) = k(y-m)^2در این فرمول، k‌ فاکتوری است بر حسب دلار که بر اساس هزینه‌های مستقیم و غیرمستقیم، خدمات پس از فروش و اعتبار از دست رفته و همچنین هزینه‌های که با از دست دادن مشتریان و هزینه‌های کار مجدد به سازمان تحمیل می شود، تعیین می گردد. راهکارهای آماده‌ای برای محاسبه k‌ در حال حاضر وجود دارد که می‌توانید به آن‌ها رجوع کنید.بر اساس اظهار نظر دمینگ (‌۱۹۶۰) لزومی وجود ندارد که این فرمول دقیق باشد و اساساً دست یابی به یک فرمول برای محاسبه دقیق میزان ضرر و زیان بسیار سخت و دشوار می باشد.  در بیشتر محاسبات در حال حاضر  به یک تقریب نسبتاً نزدیک به واقعیت اکتفا می شود.  مفهوم فرمول محاسبه ضرر و زیان به درستی در حوضه کیفیت داده و مشخصاً اندازه‌گیری کیفیت داده بر اساس عناصر داده ای مختلف مانند شناسه مشتریان، شماره ملی و گردش حساب پیاده‌سازی شده است. طبق معمول، عناصر داده بر اساس معیارهای معینی اولویت بندی می‌شوند و سطح کیفیت عناصر داده در قالب درصد اندازه‌گیری می گردد.  به عناصر داده اولویت بندی شده، عناصر داده حیاتی(CDE) نیز گفته می شود.  اگر کیفیت بدست آمده از CDE‌ها یا همان عناصر داده‌ حیاتی در سطح مطلوبی نباشد احتمال تصمیم گیری های اشتباه بالا می رود که در نهایت تبعات ویرانگری برای یک سازمان به همراه خواهد داشت که به برخی از این تبعات منفی پیش تر از این اشاره شد.  با توجه به اینکه سطح کیفیت داده از جنس متغیرهایی «هرچه بیشتر،‌بهتر» می‌باشد بنابراین شکل زیر می‌تواند ترسیم بهتری از این شرایط باشد. در واقعی در رابطه با کیفیت داده نیمی از نمودار قبلی قابل تفسیر و کاربردی می باشد. در این شکل نشان داده شده است که هر چقدر از نقطه مطلوب به سمت منفی حرکت کنیم( کیفیت پایین داده) میزان ضرر و زیان افزایش می‌یابد ولی با توجه به اینکه در نقطه m‌ در حداقل ممکن ضرر و زیان هستیم هر چقدر به سمت مثبت حرکت کنیم تغییری در نتیجه ( کاهش ضرر و زیان )‌حاصل نخواهد شد و بنابراین منطقی نخواهد بود که پس از دستیبابی به نقطه بهینه تلاش مضاعفی در رابطه با افزایش کیفیت داده‌ها صورت بگیرد. ضرر و زیان ناشی از داده‌های بی کیفیت می‌تواند نمودهای مختلفی داشته باشد، به عنوان مثال ممانعت از ورود دانشجو به دانشگاه، رد کردن درخواست وام مشتریان، نسخه داروی اشتباه، اختلال در حرکت زیردریایی ها و برچسب گذاری اشتباه بر روی مواد غذایی. در حوزه اقتصادی، شرایطی را تصور کنید که با درخواست وام یک مشتری بر اساس گزارش اشتباه گردش حساب وی، مخالفت می شود. اشتباهی که بر اساس نقص در جست‌و‌جوی گردش حساب بر اساس شماره ملی مشتری پیش آمده است. چنین اشتباهاتی می‌تواند تبعات و زیان های سنگینی برای یک مؤسسه مالی به همراه داشته باشد و آن را تا مرز ورشکستگی پیش ببرد. یک مؤسسه اقتصادی در سال ۲۰۱۱ یکی از علل اصلی بحران اقتصادی سال ۲۰۰۷ را بهره گیری ناقص از فناوری اطلاعات و همچنین ضعف در معماری اطلاعات عنوان کرده است. این مثال‌ها همگی در راستای تبیین اهمیت بالای کیفیت داده در دنیای امروز می‌باشند و مؤید این نکته می‌باشد که تأثیر داده‌های بی کیفیت را در بحران های اقتصادی نمی‌توان نادیده گرفت.  طی این بحران، بسیاری از بانک ها،‌ موسسات مالی و شرکت های بیمه میلیون‌ها دلار از سرمایه خود را از دست دادند. تأثیرات چنین اتفاقاتی می‌تواند بسیار سنگین باشد، مانند : رکود اقتصادی، افزایش بیکاری، تخلیه صندوق های بازنشستگی و از دست اعتماد و اعتبار در صنعت و نزد دولت ها.تمامی تاثیراتی  اشاره شده را می‌توان بر اساس تعریف تاگوچی در ۲ دسته قرار داد :‌۱ – ضرر قابل محاسبه بر اساس توابع و فرمول ها ، ۲-  تأثیرات مضر غیرملموس  که هر دوی آن ها در شکل زیر نشان داده شده است.  در این نوشتار به بحث در مورد کیفیت داده و تأثیرات داده‌ها بی کیفیت بر عمل‌کرد سازمان ها پرداختیم. واضح است که داده‌های بی کیفیت می‌توانند تأثیرات منفی بزرگی برای یک سازمان به همراه داشته باشند. بنابراین مدیریت مؤثر  منابع کلیدی داده در راستای به حداقل رساندن زیان ناشی از منابع اطلاعاتی ناقص، یک اصل مهم و حیاتی به شمار می رود. از همین رو نیاز به مدیریت داده  که در قبال سطح کیفیت داده‌ها پاسخگو  باشد بیش از پیش احساس می شود. در قسمت بعدی به طور خلاصه به راه اندازی چنین عمل‌کردی در سازمان و وظایف آن می پردازیم.  </description>
                <category>Farazinux</category>
                <author>Farazinux</author>
                <pubDate>Sat, 21 Apr 2018 19:41:50 +0430</pubDate>
            </item>
            </channel>
</rss>