ه‍.ش. ۱۳۹۰ مهر ۷, پنجشنبه

کلیک کلیک تا تامین سه هزار میلیارد تومن


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

ه‍.ش. ۱۳۹۰ شهریور ۳۱, پنجشنبه

توسعه سیستم رمزگذار و دسترسی تکمیلی در سفارشها

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

ه‍.ش. ۱۳۹۰ شهریور ۲۲, سه‌شنبه

کاهنده های هوشمند و شرایط خاص

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