ساخت داشبورد با هوش مصنوعی؛ فروش این چند روز چقدر بوده؟

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

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

نسخهٔ اول داشبورد می‌تواند کوچک باشد: روزانه مبلغ فروش و تعداد فاکتور را وارد کنی، بازه را ببینی و اگر اشتباهی بود همان روز را اصلاح کنی. نتیجهٔ مورد انتظار ما هم روشن است: پنج ردیف، ۴ میلیون تومان فروش و ۱۲ فاکتور.

دربارهٔ تصاویر: این نماها از HTML نمایشی در قاب روشن کُندا تهیه شده‌اند. رفتار رابط را توضیح می‌دهند؛ ذخیره در سرور، اتصال اکسل یا خروجی گرفتن واقعی را اثبات نمی‌کنند. عددها ساختگی‌اند.

۱. مشخص کن داشبورد قرار است به چه تصمیمی کمک کند

برای این فروشگاه، سؤال اول این است: «در بازهٔ انتخاب‌شده چقدر فروش ثبت کرده‌ایم؟» دو سؤال بعدی هم تعداد فاکتور و مبلغ متوسط هر فاکتور است. همین سه عدد برای شروع کافی‌اند.

اگر فقط می‌خواهی یک فایل را یک بار تحلیل کنی، شاید گفت‌وگو با یک ابزار تحلیل داده کار را انجام دهد. اما وقتی قرار است هر روز اطلاعات تازه ثبت شود، همکارت گزارش را ببیند و اشتباه‌ها اصلاح شوند، به یک گردش کار تکرارپذیر نیاز داری. این مقاله دربارهٔ ساخت همان گردش کار است.

این گزارش را با سود اشتباه نگیر. ما فعلاً مبلغ فروش ثبت‌شده را جمع می‌کنیم؛ هزینه، مرجوعی، مالیات و زمان دریافت وجه را وارد محاسبه نکرده‌ایم.

۲. پنج روز نمونه و جواب درست را از قبل بنویس

هر ردیف این تمرین، جمع یک روز است؛ نه یک فاکتور جدا. واحد مبلغ هم در تمام صفحه تومان است.

فایل پنج ردیف نمونه را می‌توانی برای تمرین دریافت کنی. جمع این پنج ردیف، ۴ میلیون تومان و ۱۲ فاکتور است. میانگین مبلغ هر فاکتور از تقسیم ۴ میلیون بر ۱۲ به دست می‌آید: حدود ۳۳۳٬۳۳۳ تومان، با گردکردن به نزدیک‌ترین تومان.

این عدد با «میانگین فروش روزانه» فرق دارد. میانگین روزانهٔ این بازه ۸۰۰ هزار تومان است، چون ۴ میلیون را بر پنج روز تقسیم می‌کنیم. کنار هر کارت، عنوان و واحد روشن بنویس تا دو معنی با هم قاطی نشوند.

۳. پرامپت را با همین سؤال و داده بنویس

به جای «یک داشبورد حرفه‌ای بساز»، بگو چه چیزی ثبت می‌کنی، عددها چطور حساب شوند و چه کسی اجازهٔ تغییر دارد. نمودار را بعد از این قواعد بخواه.

متن را برای نوع کسب‌وکارت تغییر بده و در داشبورد کُندا بازبینی کن. انتقال پرامپت به داشبورد، ساخت را خودکار شروع نمی‌کند. قبل از ساخت، درخواست و شرایط اعتبار حسابت را بررسی می‌کنی.

۴. اشتباه یک روز را اصلاح کن؛ ردیف تازه نساز

حالا فرض کن فروش ۶ آبان را اشتباه وارد کرده‌ای: به جای ۶۰۰ هزار تومان، ۵۰۰ هزار تومان نوشته‌ای. باید همان ردیف را اصلاح کنی. اضافه‌کردن یک ردیف دیگر برای همان تاریخ می‌تواند جمع گزارش را خراب کند.

بعد از اصلاح، تعداد ردیف‌ها باید پنج و تعداد فاکتورها همچنان ۱۲ باشد. فقط جمع فروش به ۴ میلیون و ۱۰۰ هزار تومان تغییر می‌کند. این یک معیار ساده برای بررسی نسخهٔ واقعی است؛ هم فرم را امتحان می‌کند، هم محاسبه را.

اگر برای روز موجود دوباره سراغ «ثبت» رفتی، پیام مفید این است: «این روز قبلاً ثبت شده؛ برای تغییر مبلغ از اصلاح استفاده کن.» لازم نیست کاربر اصطلاح خطای سرور یا کد فنی را بفهمد تا راه ادامه را پیدا کند.

در نسخهٔ واقعی، بعد از اصلاح صفحه را ببند و دوباره باز کن. باقی‌ماندن مقدار جدید را جدا بررسی کن. بستن فرم یا دیدن پیام «ذخیره شد»، به‌تنهایی نشانهٔ ماندگاری داده نیست.

۵. روز بدون فروش را از روز ثبت‌نشده جدا ببین

در دادهٔ ما، ۴ آبان با صفر تومان و صفر فاکتور ثبت شده است. یعنی برای آن روز اطلاعات داریم و فروش ثبت‌شده صفر بوده است. اما برای ۷ آبان هنوز ردیفی نداریم؛ نمی‌دانیم فروشش چقدر بوده است.

اگر هر دو را در نمودار صفر نشان بدهی، گزارش می‌تواند گمراه‌کننده شود. در جدول بنویس «فروش صفر» یا «هنوز ثبت نشده»؛ برای نبود داده هم به‌جای عدد صفر از خط تیره یا پیام روشن استفاده کن.

بازه را هم با یک جواب کوچک بسنج. از ۴ تا ۶ آبان، با احتساب هر دو روز ابتدا و انتها، باید ۲ میلیون تومان و ۷ فاکتور داشته باشی. اگر یکی از روزهای مرزی حذف شد، قبل از اعتماد به گزارش فیلتر را اصلاح کن.

۶. همکارت گزارش را ببیند؛ تغییر مبلغ دست مدیر بماند

برای همکاری که فقط گزارش لازم دارد، حالت بیننده کافی است. مسیر مشاهده را ساده نگه دار و دکمه‌های ثبت و اصلاح را برای این نقش در دسترس نگذار.

بستن دکمه در ظاهر، تمام کار نیست. در نسخهٔ واقعی باید درخواست ثبت یا ویرایش از حساب بیننده هم روی سرور رد شود. این بررسی را با دو حساب آزمایشی متعلق به خودت انجام بده و از دادهٔ مشتری استفاده نکن.

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

۷. قبل از استفادهٔ روزانه، نتیجه را با این برگه بسنج

• پنج روز اول: ۴ میلیون تومان، ۱۲ فاکتور، میانگین حدود ۳۳۳٬۳۳۳ تومان.
• بازهٔ ۴ تا ۶ آبان: ۲ میلیون تومان و ۷ فاکتور.
• اصلاح روز آخر از ۵۰۰ به ۶۰۰ هزار تومان: جمع ۴٫۱ میلیون، با همان پنج ردیف و ۱۲ فاکتور.
• روز صفر، روز ثبت‌نشده و خطای دریافت اطلاعات، پیام یکسان نداشته باشند.
• پس از بازکردن دوباره، دادهٔ ذخیره‌شده باقی بماند و بیننده نتواند آن را تغییر دهد.

برگهٔ آزمون قابل تکمیل و جواب‌های مورد انتظار را کنار نسخهٔ خودت نگه دار.

اگر خروجی فایل لازم داری، دانلودش کن و چند ردیف را با گزارش مقایسه کن. نمایش دکمهٔ «خروجی» کافی نیست. اتصال اکسل، دیتابیس بیرونی و ارسال زمان‌بندی‌شدهٔ گزارش هم هرکدام مسیر جدا برای اتصال و آزمون می‌خواهند.

قدم بعدی: اول یک هفتهٔ کوچک را درست ببین

از همان سؤال اول شروع کن: «فروش این چند روز چقدر بوده؟» پنج ردیف ساختگی وارد کن، جمع را حساب کن و یک اشتباه را اصلاح کن. وقتی این مسیر روشن شد، دادهٔ واقعی و شاخص‌های بعدی را اضافه کن.

در کُندا می‌توانی از سناریوی گزارش و داشبورد یا یک قالب نزدیک به نیازت شروع کنی. به جای زیادکردن کارت‌ها، اول مطمئن شو یک گزارش مشخص به تو جواب قابل بررسی می‌دهد.

برای انتخاب نوع خروجی، راهنمای ساخت اپلیکیشن را ببین. اگر داده‌ها از سفارش‌های فروشگاه می‌آیند، مسیر ثبت سفارش را دنبال کن. پیش از استفادهٔ واقعی هم تفاوت پیش‌نمایش و نسخهٔ آمادهٔ استفاده و چک‌لیست دسترسی وب‌اپ را بررسی کن.

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