راهی برای کسب جریان نقدینگی یا تله بزرگ کاهش حاشیه سود

وقتی به اکثر شرکت های نرم افزاری نگاه می کنیم ، عموماً با مدیرانی روبه رو می شویم که سابقاً تمامی سمت های اجرایی در یک شرکت مهندسی نرم افزار را طی کرده و امروز پس از کسب تجربیاتی در حوزه برنامه نویسی ، تحلیل و طراحی ، مدیریت پروژه ، مالی و اداری ، منابع انسانی و … امروز مسؤولیت فروش یا مدیریت عاملی شرکت های خود یا شرکت هایی که در آن مشغول به کار هستند را بر عهده گرفته اند.

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

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

شاید شما هم تجربه کرده باشد و در مواجه با نرم افزارهایی که چندین سال از ورود آنها به بازار و فروش به تعداد زیادی مشتری گذشته است ، حتماً در هنگام کار کردن با سورپرایز های جدیدی رو به رو شده اید که عموماً ناشی از ذهن پیچیده یک برنامه نویس یا تحلیل گر است که به احتمال زیاد در هیچ یک از جلسات آموزشی ( به شرط برگزاری ) یا مستندات راهنما ( به شرط به روز بودن) شما ردی از آنها نخواهید دید و حتی در تماس با پشتیبانی شرکت ها هم ممکن است با این جمله رو به رو شوید که ” جداً چنین اتفاقی رخ میده !” .

اما به نظر شما این مشکل ناشی از کجاست ؟ از خواسته های مشتری ، از خواسته های تیم تحلیل ، از روش های پیاده سازی تیم برنامه نویس و یا از یک نقطه تاریک دیگر در حوزه مدیریت مالی شرکت های نرم افزاری.

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

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

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

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

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

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

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

باور کنید بسیاری از خصوصیاتی که به نرم افزارها با این رویه اضافه می شوند ، هیچگاه توسط مشتری مورد استفاده قرار نخواهد گرفت .

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

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

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

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

سید عزیزالله بنی هاشمی

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

2 دیدگاه

  1. خوبه ، به هر حال تیم همیشه سرمایه اصلی شرکت های نرم افزاری بوده اند و تمرکز روی تیم هدف نهایی رو نشونه می گیره . مطلب خوبی بود

  2. Pingback: لینک‌های هفته (۲۴4) | گزاره‌ها

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *