این آمار تحقیق و توسعه را برای کسب و کار خود نادیده نگیرید.

بسیاری از کسب و کارها تحقیق و توسعه را به عنوان یک ردیف بودجه در نظر می گیرند که می تواند سالی یک بار بررسی شود. من مشکلی در این رویکرد می بینم. تحقیق و توسعه بر کیفیت محصول، زمان راه اندازی، هزینه های عملیاتی، حفظ مشتری و درآمد آتی تأثیر می گذارد. وقتی رهبران فقط به کل هزینه ها نگاه می کنند، ممکن است پروژه های هدر رفته، توسعه آهسته یا محصولی را که قبل از آماده شدن مشتریان به بازار می رسد، از دست بدهند. من از مجموعه کوچکی از معیارهای تحقیق و توسعه برای ارتباط کار فنی با نتایج کسب و کار استفاده می کنم. هدف اندازه گیری هر فعالیتی نیست. هدف این است که بفهمیم پول، زمان و استعداد کجا ارزش ایجاد می کنند. ** مخارج تحقیق و توسعه به عنوان سهمی از درآمد ** این معیار نشان می دهد که چه مقدار از درآمد شرکت صرف تحقیق و توسعه محصول می شود. فرمول: شدت تحقیق و توسعه = هزینه تحقیق و توسعه ÷ درآمد کل × 100 یک شرکت نرم افزاری با 2 میلیون دلار درآمد سالانه و 300000 دلار در تحقیق و توسعه، شدت تحقیق و توسعه 15% دارد. این عدد به من نمی گوید که آیا شرکت به خوبی هزینه می کند یا خیر. این به من نقطه شروعی برای مقایسه می دهد. من نتیجه را در چندین دوره و با شرکت هایی با مدل تجاری مشابه مقایسه می کنم. یک شرکت نرم افزاری جوان ممکن است در هنگام ساخت محصول اصلی خود به نسبت بالاتری نیاز داشته باشد. یک شرکت بالغ ممکن است در حالی که پلتفرم ایجاد شده را بهبود می بخشد، کمتر به عنوان سهم درآمد هزینه کند. نسبت رو به افزایش نیاز به زمینه دارد. ممکن است نشان دهنده سرمایه گذاری محصول باشد، اما ممکن است به تاخیر در راه اندازی، کارهای فنی مکرر یا اولویت های پروژه نامشخص اشاره کند. هزینه تحقیق و توسعه برای هر پروژه کل هزینه های تحقیق و توسعه می تواند پروژه های گران قیمت را پنهان کند. من ترجیح می دهم هزینه ها را بر اساس محصول، ویژگی یا برنامه تحقیقاتی دنبال کنم. برای هر پروژه، موارد زیر را ثبت می‌کنم: - هزینه کارکنان - پیمانکاران خارجی - آزمایش و تجهیزات - نرم‌افزار و ابزارهای داده - هزینه‌های نمونه اولیه - کار انطباق و صدور گواهینامه - پشتیبانی از تیم‌های فروش، خدمات یا عملیات، یک پروژه ممکن است زمانی مقرون به صرفه به نظر برسد که فقط حقوق مهندسی محاسبه شود. هنگامی که تست، پشتیبانی مشتری و کار مجدد گنجانده شود، هزینه می تواند بسیار متفاوت به نظر برسد. این معیار به من کمک می کند پروژه هایی را با اهداف مشابه مقایسه کنم. همچنین نشان می‌دهد که کدام کار بدون نزدیک‌تر کردن محصول به عرضه، منابع را مصرف می‌کند. زمان از ایده تا راه اندازی اگر تیم نتواند آن را به محصول قابل استفاده تبدیل کند، یک ایده قوی ارزش محدودی دارد. من زمان بین: - مفهوم تایید شده - نمونه اولیه کار - تست داخلی - تست مشتری - راه اندازی بازار چرخه های توسعه طولانی می تواند ناشی از الزامات نامشخص، لایه های تایید بیش از حد، مهارت های فنی از دست رفته، یا تغییرات مکرر مدیریت باشد. من سیکل کوتاه را به طور خودکار بهتر نمی دانم. یک دستگاه پزشکی، پلت فرم مالی یا محصول صنعتی ممکن است به آزمایش طولانی تری نسبت به یک ویژگی ساده موبایل نیاز داشته باشد. سوال مفید این است که آیا زمان با ریسک و هدف محصول مطابقت دارد یا خیر. وقتی پروژه ای تاریخ راه اندازی خود را از دست می دهد، من به جای اینکه تیم را مقصر بدانم، علت را بررسی می کنم. یک تصمیم تاخیری در شروع کار می تواند هفته ها بعد کار ایجاد کند. ** حقوق و دستمزد تحقیق و توسعه و ظرفیت تیم ** نتایج تحقیق و توسعه به افراد بستگی دارد، نه تنها به بودجه. من ردیابی می‌کنم: - تعداد نیروی مهندسی - تعداد کار محصولات و تحقیقات - نقش‌های فنی باز - جابجایی کارکنان - زمان صرف شده برای تعمیر و نگهداری - زمان صرف شده برای کار محصول جدید - ساعت‌های توسعه خارجی یک تیم ممکن است کاملاً پرکار به نظر برسد در حالی که بیشتر وقتش به رفع اشکال‌ها و درخواست‌های مشتری می‌پردازد. که ظرفیت کمی برای توسعه جدید باقی می گذارد. اگر شرکتی بخواهد دو محصول را روانه بازار کند اما فقط ظرفیت کافی برای نگهداری یکی از آنها را داشته باشد، مشکل همیشه کمبود تلاش نیست. این طرح ممکن است بزرگتر از تیم موجود باشد. اینجاست که برنامه ریزی ظرفیت مفید می شود. من کار متعهد را از کار اختیاری جدا می‌کنم و بررسی می‌کنم که آیا برنامه ساعات کاری واقعی کارکنان را منعکس می‌کند یا خیر. نرخ نمونه اولیه تا راه اندازی یک شرکت می تواند نمونه های اولیه زیادی تولید کند و همچنان ارزش تجاری کمی ایجاد کند. نرخ نمونه اولیه تا راه اندازی نشان می دهد که چه تعداد از مفاهیم آزمایش شده به محصولات، ویژگی ها یا خدماتی تبدیل می شوند که مشتریان می توانند از آنها استفاده کنند. فرمول: نرخ نمونه اولیه به راه اندازی = پروژه های راه اندازی شده ÷ نمونه های اولیه آزمایش شده × 100 نرخ پایین همیشه یک ضعف نیست. پژوهش نیاز به فضایی برای ایده هایی دارد که کار نمی کنند. زمانی که پروژه ها بدون نیازهای مشتری مشخص، بررسی های فنی یا معیارهای تجاری تایید شوند، نتیجه کم به یک نگرانی تبدیل می شود. من برای هر پروژه سه سوال می پرسم: - چه مشکل مشتری را برطرف می کند؟ - چه شواهدی این تقاضا را تأیید می کند؟ - چه نتیجه ای باعث توقف یا تغییر جهت ما می شود؟ این سوالات خطر زنده نگه داشتن یک پروژه را تنها به این دلیل کاهش می دهد که تیم قبلاً روی آن سرمایه گذاری کرده است. درآمد حاصل از محصولاتی که اخیراً راه اندازی شده اند تحقیق و توسعه باید با نتایج بازار مرتبط باشد و در عین حال انتظارات را واقع بینانه نگه دارد. من سهم درآمد تولید شده توسط محصولات یا ویژگی های اصلی راه اندازی شده در یک دوره تعریف شده، مانند سه سال گذشته را اندازه گیری می کنم. این معیار برای شرکت هایی که محصولات قابل تکرار می فروشند بهتر عمل می کند. یک پروژه ساختمانی بزرگ، یک قرارداد صنعتی طولانی مدت، یا یک برنامه دارویی سنگین تحقیقاتی ممکن است به دوره اندازه گیری متفاوتی نیاز داشته باشد. این معیار همچنین به تعریف واضحی از "جدید" نیاز دارد. یک تغییر جزئی در طراحی نباید مانند یک خط محصول جدید حساب شود. شرکت‌های دولتی اغلب در گزارش‌های سالانه خود درباره هزینه‌های تحقیق و توسعه و درآمد حاصل از گروه‌های محصول بحث می‌کنند. خواندن هر دو شکل با هم دید بهتری نسبت به خواندن عدد تحقیق و توسعه به تنهایی می دهد. یک شرکت ممکن است هنگام ساخت یک دسته محصول جدید بیشتر هزینه کند، یا در حالی که درآمد بیشتری از یک پایه محصول بالغ به دست می آورد، کمتر هزینه کند. ** پذیرش مشتری پس از عرضه ** راه اندازی ثابت نمی کند که یک محصول در بازار کار می کند. من رفتار مشتری را پس از انتشار دنبال می‌کنم: - تبدیل آزمایشی به پولی - استفاده فعال - خرید تکراری - پذیرش ویژگی - درخواست‌های پشتیبانی مشتری - رد کردن - بازپرداخت یا برگرداندن یک محصول ممکن است توجه زیادی به راه‌اندازی دریافت کند اما تکرار ضعیف را مشاهده کند. این الگو به من می گوید که بازار ممکن است این ایده را دوست داشته باشد اما ارزش روزانه کافی را پیدا نکند. من همچنین پذیرش را در بین گروه های مشتری مقایسه می کنم. یک ویژگی ساخته شده برای مشاغل بزرگ ممکن است در بین شرکت های کوچک کاربرد کمی داشته باشد و همچنان در بخش مورد نظر خود عملکرد خوبی داشته باشد. کیفیت تحقیق و توسعه و نرخ نقص سرعت و اعداد فروش می توانند مشکلات محصول را پنهان کنند. من نقص‌ها را بر اساس مرحله پیگیری می‌کنم: - آزمایش نمونه اولیه - انتشار داخلی - آزمایش مشتری - راه‌اندازی عمومی - به‌روزرسانی‌های پس از راه‌اندازی هزینه رفع مشکل اغلب زمانی افزایش می‌یابد که مشکل به مشتریان برسد. نقصی که در آزمایش اولیه پیدا می شود ممکن است نیاز به یک کد یا تغییر طراحی کوچک داشته باشد. همین نقص پس از راه‌اندازی می‌تواند کار پشتیبانی، بازپرداخت، اعتماد از دست رفته و انتشار اضطراری ایجاد کند. برای مشاغل سخت‌افزاری، نرخ‌های بازگشت، ادعاهای گارانتی، آزمایش‌های ناموفق و رد تولید را نیز بررسی می‌کنم. برای کسب‌وکارهای نرم‌افزاری، اقدامات مفید شامل حوادث بحرانی، استقرار ناموفق، و زمان مورد نیاز برای بازگردانی سرویس است. پتنت و خروجی تحقیق ثبت اختراع، انتشارات و اکتشافات فنی می تواند به برخی از مشاغل کمک کند. آنها نباید به عنوان مدرک اصلی موفقیت تحقیق و توسعه در نظر گرفته شوند. من به موارد زیر نگاه می کنم: - پتنت های متصل به محصولات فعال - نتایج تحقیقات مورد استفاده در توسعه - مشکلات فنی حل شده - سیستم های قابل استفاده مجدد ایجاد شده - درآمد صدور مجوز، در صورت لزوم تعداد زیاد پتنت ممکن است فعالیت تحقیقاتی قوی را نشان دهد، اما به خودی خود ارزش مشتری را نشان نمی دهد. یک پیشرفت فنی مفید می تواند بیش از بسیاری از براده های استفاده نشده اهمیت داشته باشد. من خروجی تحقیق را به برنامه های محصول متصل می کنم. اگر یک نتیجه تحقیق مسیر مشخصی برای آزمایش، صدور مجوز یا استفاده از محصول نداشته باشد، آن را جدا از توسعه تجاری ثبت می کنم. بازده تحقیق و توسعه بر اساس پروژه من از قضاوت هر پروژه با فرمول مالی یکسان اجتناب می کنم. برای یک محصول تجاری، من ممکن است سود ناخالص مورد انتظار را با کل هزینه توسعه مقایسه کنم. برای یک سیستم داخلی، ممکن است هزینه‌های خدمات کمتر، خطاهای کمتر یا تحویل سریع‌تر را اندازه‌گیری کنم. برای تحقیقات اولیه، ممکن است به جای درآمد از نقاط عطف یادگیری استفاده کنم. یک بررسی ساده پروژه می‌تواند شامل موارد زیر باشد: - کل هزینه تحقیق و توسعه - اندازه بازار مورد انتظار - حاشیه ناخالص مورد انتظار - تاریخ راه‌اندازی تخمینی - خطرات فنی اصلی - شواهد مشتری - هزینه تاخیر پروژه - شرایط توقف کار لازم نیست ارقام در مرحله ایده دقیق باشند. آنها باید نشان دهند که شرکت چه چیزهایی را می داند، چه چیزهایی را نمی داند و چه چیزهایی باید بعداً آزمایش شوند. چگونه یک داشبورد تحقیق و توسعه بسازم داشبورد را به اندازه ای کوچک نگه می دارم که رهبران بتوانند هر ماه بخوانند. دیدگاه اصلی من شامل موارد زیر است: - هزینه تحقیق و توسعه در مقابل بودجه - هزینه تحقیق و توسعه به عنوان سهمی از درآمد - هزینه پروژه و برنامه زمانبندی - ظرفیت تیم - نرخ نمونه اولیه تا راه اندازی - درآمد محصول جدید - پذیرش مشتری - روندهای نقص و پشتیبانی هر معیار به یک مالک، یک منبع داده و یک دوره بررسی نیاز دارد. بدون این جزئیات، داشبورد می‌تواند به مجموعه‌ای از اعداد تبدیل شود که هیچ اقدامی ضمیمه نشده است. من همچنین اقدامات پیشرو و عقب مانده را جدا می کنم. ساعات توسعه، پیشرفت آزمایش، و خطرات باز می تواند به من در مورد مشکلات آینده هشدار دهد. ادعاهای درآمد، نگهداری و ضمانت نشان می دهد که قبلاً چه اتفاقی افتاده است. جلسه بررسی عملی باید با یک تصمیم پایان یابد: ادامه، تنظیم، مکث یا توقف. اعداد مهم هستند زیرا از یک انتخاب پشتیبانی می کنند. آمار تحقیق و توسعه جایگزینی برای قضاوت نیست. آن‌ها به من کمک می‌کنند ببینم که آیا شرکت در حال تامین بودجه کار مفید، ساختن با سرعت عملی و یادگیری از بازار است یا خیر. بهترین داشبورد داشبوردی نیست که بیشترین نمودار را داشته باشد. این چیزی است که به تیم کمک می کند تا ضایعات را زود تشخیص دهد، از تحقیقات مفید محافظت کند و تصمیمات محصول را با نیازهای مشتری مرتبط کند.

تیم‌های تحقیق و توسعه روزانه مقدار زیادی داده تولید می‌کنند: نتایج آزمایش، تغییرات طراحی، بازخورد مشتری، سوابق شکست، یادداشت‌های تولید و هزینه‌های پروژه. مشکل این است که این اطلاعات اغلب در سیستم های جداگانه باقی می مانند. مهندسان ممکن است از صفحات گسترده استفاده کنند، مدیران محصول ممکن است به یادداشت‌های جلسه تکیه کنند و تیم‌های فروش فقط محصول نهایی را ببینند. وقتی این قطعات به هم متصل نمی شوند، یک شرکت می تواند ماه ها را صرف بهبود ویژگی هایی کند که مشتریان به آن نیاز ندارند. من معتقدم داده‌های تحقیق و توسعه زمانی ارزشمند می‌شوند که به مردم کمک کند تصمیم‌های بهتری بگیرند. هدف جمع آوری داده های بیشتر نیست. هدف این است که داده های مفید را با انتخاب های محصول، نیازهای مشتری و نتایج کسب و کار مرتبط کنیم. ### با یک سوال تجاری شروع کنید بسیاری از شرکت ها با یک پایگاه داده یا ابزار تجزیه و تحلیل شروع می کنند. ترجیح می دهم با یک سوال شروع کنم. ممکن است یک سوال مفید به نظر برسد: - کدام ویژگی محصول منجر به خرید مجدد می شود؟ - چرا برخی از نمونه های اولیه در طول آزمایش میدانی شکست می خورند؟ - کدام شکایات مشتری باید بر نسخه محصول بعدی تأثیر بگذارد؟ - هر تغییر طراحی چقدر به پروژه اضافه می کند؟ - کدام پروژه های تحقیقاتی مسیر روشنی برای تقاضای بازار دارند؟ یک سوال واضح به تیم کمک می کند تا داده های مناسب را انتخاب کند. بدون این مرحله، گزارش تحقیق و توسعه می‌تواند به مجموعه‌ای از نمودارها تبدیل شود که مفید به نظر می‌رسند، اما اقدامات را هدایت نمی‌کنند. به عنوان مثال، یک شرکت لوازم الکترونیکی مصرفی ممکن است متوجه شود که کاربران به ندرت یک ویژگی نرم افزار جدید را فعال می کنند. تیم توسعه می‌تواند این یافته را با بلیط‌های پشتیبانی، داده‌های استفاده از برنامه و بررسی‌های محصول مقایسه کند. نسخه بعدی ممکن است به جای توابع بیشتر نیاز به نصب بهتر داشته باشد. ### داده‌های تحقیق و توسعه را در میان تیم‌ها وصل کنید داده‌های تحقیق و توسعه اغلب در مکان‌های جداگانه قرار می‌گیرند: - سیستم‌های مدیریت چرخه عمر محصول - پلت‌فرم‌های مدیریت ارتباط با مشتری - سوابق تست و کیفیت - پایگاه‌های داده تولید - ابزارهای بلیط پشتیبانی - فایل‌های تحقیقات بازار - نرم‌افزار مدیریت پروژه این سیستم‌ها نیازی ندارند که به یک پلتفرم بزرگ تبدیل شوند. من معمولاً ایجاد یک ساختار داده مشترک حول چند زمینه مشترک را توصیه می کنم: - نام محصول یا پروژه - شماره نسخه - گروه مشتری - تاریخ آزمایش - تغییر طراحی - نتیجه آزمایش - هزینه - زمان تحویل - مشکل گزارش شده - نتیجه کسب و کار ساختار مشترک سردرگمی را کاهش می دهد. هنگامی که یک مهندس، مدیر محصول و رهبر فروش از نسخه محصول و برچسب های یکسان استفاده می کنند، بحث های آنها متمرکزتر می شود. کیفیت داده نیز مهم است. عدم وجود شماره نسخه می تواند تشخیص این که آیا نقص ناشی از تغییر طراحی است یا از یک فرآیند تولید دشوار است. یک برچسب مبهم مانند "مشکل عملکرد" ​​به تیم هدایت کمی می دهد. عبارات واضح تجزیه و تحلیل بهتری ایجاد می کنند. ### نتایج آزمایش را به تصمیمات محصول تبدیل کنید داده های آزمایش باید منجر به تصمیم شوند، نه اینکه در یک گزارش بنشینند. من از یک فرآیند بررسی ساده استفاده می کنم: 1. هدف آزمون را تعریف کنید. 2. نتیجه مورد انتظار را ثبت کنید. 3. نتیجه واقعی را ثبت کنید. 4. به شرایط آزمون توجه کنید. 5. نتیجه را با نیازهای مشتری یا بازار مقایسه کنید. 6. تصمیم بگیرید که آیا کار را ادامه دهید، تغییر دهید، مکث کنید یا متوقف کنید. برای مثال، یک سازنده باتری ممکن است ماده جدیدی را آزمایش کند که ظرفیت را بهبود می بخشد اما هزینه تولید را افزایش می دهد. نتیجه به طور خودکار موفقیت محصول نیست. این تیم باید ظرفیت، ایمنی، محدودیت های تولید، انتظارات قیمت مشتری و خدمات مورد نیاز را مقایسه کند. این رویکرد به جلوگیری از قضاوت عملکرد فنی در انزوا کمک می کند. ### از بازخورد مشتری در طول توسعه استفاده کنید بازخورد مشتری نباید پس از راه‌اندازی شروع شود. این می تواند انتخاب محصول را در زمانی که محصول هنوز در حال توسعه است هدایت کند. من به دنبال الگوهای تکراری در این موارد می‌گردم: - گفتگوهای پشتیبانی - بررسی محصول - اعتراضات فروش - ادعاهای گارانتی - مصاحبه‌های کاربر - پروژه‌های آزمایشی - دلایل بازگشت محصول یک شکایت ممکن است نیاز گسترده‌ای را نشان ندهد. شکایات مکرر در مشتریان مختلف مستحق توجه بیشتر است. یک شرکت نرم افزاری ممکن است متوجه شود که کاربران نمودارهای داشبورد بیشتری را درخواست نمی کنند. آنها ممکن است راه‌های سریع‌تری برای صادرات گزارش‌ها و به اشتراک گذاشتن آنها با مدیران بخواهند. این تفاوت می تواند برنامه توسعه را تغییر دهد. بهبود مفید محصول ممکن است پشتیبانی از گردش کار باشد، نه لیست ویژگی های بزرگتر. ### تحقیق را با یادگیری اندازه گیری کنید، نه تنها با راه اندازی برخی از پروژه های تحقیق و توسعه به محصول تبدیل نمی شوند. این بدان معنا نیست که کار ارزشی ندارد. یک پروژه ممکن است نشان دهد که: - یک ماده برای بازار هدف بسیار گران است - یک روش فنی نمی تواند نیازهای ایمنی را برآورده کند - یک گروه مشتری مورد استفاده متفاوتی دارد - یک فرآیند تولید به زمان بیشتری نیاز دارد - یک ویژگی پیشنهادی مشکل مشتری قوی را حل نمی کند. این به مدیران دید بهتری از ارزش تحقیقاتی نسبت به تعداد ساده محصولات عرضه شده می دهد. یک رکورد مفید ممکن است شامل موارد زیر باشد: | سوال تحقیق | شواهد جمع آوری شده | تصمیم | پیگیری | |---|---|---|---| | آیا این ماده می تواند استفاده روزانه را تحمل کند؟ | تست استرس و گرما | تغییر ترکیب مواد | تست یک گزینه کم هزینه | | آیا کاربران از این ویژگی استفاده خواهند کرد؟ | بازخورد آزمایشی و داده های استفاده | ساده کردن گردش کار | بررسی استفاده پس از انتشار | | آیا تولید می تواند تقاضا را برآورده کند؟ | داده ظرفیت خط | تنظیم طرح | اجرای یک دسته تولید کوچک | ### داشبورد تحقیق و توسعه عملی بسازید یک داشبورد باید در چند دقیقه به سوالات تجاری پاسخ دهد. به ده ها معیار نیاز ندارد. اقدامات مفید ممکن است شامل موارد زیر باشد: - زمان از ایده تا نمونه اولیه - زمان از نمونه اولیه تا طرح تایید شده - تعداد تغییرات طراحی - میزان شکست تست - ساعت های مجدد کار - هزینه تحقیق بر اساس پروژه - تعداد دفعات مشکل مشتری - نرخ نقص پس از انتشار - پذیرش ویژگی های جدید - درآمد یا حفظ مرتبط با محصول. نرخ شکستی که از 4% به 7% می رسد نیاز به زمینه دارد. این افزایش ممکن است ناشی از آزمایش سخت‌تر، تامین‌کننده جدید یا تغییر طراحی باشد. یک داشبورد خوب همچنین نشان می دهد که چه کسی مالک عمل بعدی است. داده‌های بدون مالکیت می‌توانند تصمیم‌گیری‌ها را به جای حمایت از آنها کند کنند. ### پیوند داده های فنی با نتایج مالی رهبران تحقیق و توسعه اغلب نیاز دارند که انتخاب های فنی را برای تیم های مالی و اجرایی توضیح دهند. یک مدل داده مشترک این مکالمه را آسان تر می کند. برای هر پروژه بزرگ، من ردیابی را پیشنهاد می‌کنم: - هزینه تحقیق و توسعه - گروه مشتری مورد انتظار - هزینه تخمینی تولید - محدوده قیمت هدف - زمان مورد انتظار برای عرضه به بازار - ریسک‌های فنی شناخته شده - نیازهای پشتیبانی و خدمات - شواهد تقاضای مشتری این بدان معنا نیست که هر پروژه تحقیقاتی باید وعده بازدهی ثابت را بدهد. تحقیقات اولیه حاوی عدم قطعیت است. هدف این است که مفروضات قابل مشاهده و به روز کردن آنها با ظاهر شدن شواهد جدید است. یک پروژه ممکن است زمانی جذاب به نظر برسد که تنها از طریق نتایج فنی مشاهده شود. پس از اینکه برآوردهای تولید و تحقیقات مشتری اضافه شد، تیم ممکن است بازار کوچکتر یا موقعیت محصول متفاوتی را انتخاب کند. این تنظیم می تواند از منابع محافظت کند و در عین حال بخش مفید تحقیق را حفظ کند. ### حفاظت از دسترسی به داده ها و اعتماد به داده های تحقیق و توسعه ممکن است حاوی اسرار تجاری، اطلاعات مشتری، روش های آزمایش و جزئیات تامین کننده باشد. دسترسی باید با نقش هر فرد مطابقت داشته باشد. کنترل‌های اساسی عبارتند از: - پاک کردن مجوزهای کاربر - تاریخچه نسخه - تعاریف داده‌های تایید شده - پشتیبان‌گیری منظم - سوابق حسابرسی - قوانین مربوط به اطلاعات مشتری - فرآیندی برای تصحیح خطاها تیم‌ها همچنین باید بدانند که یک معیار از کجا آمده است. اگر دو گزارش میزان شکست متفاوتی را نشان دهند، ممکن است افراد دیگر به هر دو گزارش اعتماد نکنند. یک تعریف مشترک و یک مالک داده با نام می تواند این مشکل را کاهش دهد. اعتماد زمانی افزایش می یابد که افراد بتوانند منبع را بررسی کنند و محدودیت های داده ها را درک کنند. ### قبل از عرضه گسترده‌تر از یک پایلوت کوچک استفاده کنید یک شرکت نیازی به اتصال همه سیستم‌ها در روز اول ندارد. یک خلبان متمرکز می تواند نشان دهد که چه چیزی کار می کند. یک خط محصول یا پروژه تحقیقاتی را انتخاب کنید. مجموعه کوچکی از نقاط داده را ردیابی کنید. افرادی را از تحقیق و توسعه، محصول، فروش، عملیات و امور مالی دور هم جمع کنید. نتایج را در یک برنامه منظم مرور کنید. یک آزمایش آزمایشی عملی ممکن است به این صورت اجرا شود: - هفته 1: تعریف سؤالات تجاری و فیلدهای داده - هفته 2: پاک کردن سوابق موجود - هفته 3: اتصال آزمایش، مشتری و داده های پروژه - هفته 4: بررسی اولین یافته ها - هفته 5: توافق بر روی اقدامات محصول یا فرآیند - هفته 6: بررسی کنید که آیا اقدامات نتیجه را تغییر داده است یا خیر. اگر تیم متوجه شد که یک فیلد داده ارزشی ندارد، آن را حذف کنید. اگر یک فیلد از دست رفته تجزیه و تحلیل را مسدود می کند، آن را با مالک واضح اضافه کنید. ### یک مسیر بهتر از داده ها به رشد داده های تحقیق و توسعه زمانی می تواند از رشد حمایت کند که به شرکت کمک کند انتخاب هایی را انجام دهد که مشتریان ارزش قائل هستند و عملیات می توانند از آن پشتیبانی کنند. من روی یک زنجیره ساده تمرکز می‌کنم: شواهد تحقیق → تصمیم محصول → پاسخ مشتری → نتیجه کسب‌وکار اندازه‌گیری زنجیره ممکن است زمان ببرد، به‌ویژه برای چرخه‌های توسعه طولانی. این طبیعی است. این تیم همچنان می‌تواند سیگنال‌های اولیه مانند کیفیت تست، سرعت توسعه، بازخورد مشتری، پذیرش و آمادگی تولید را ردیابی کند. وقتی یک طرح داده تحقیق و توسعه را بررسی می کنم، یک سوال می پرسم: "این اطلاعات چه تصمیمی را بهبود می بخشد؟" اگر پاسخ نامشخص باشد، ممکن است داده ها شایسته جایی در گردش کار نباشند. هنگامی که پاسخ مشخص باشد، ارتباط R&D با برنامه ریزی محصول، نیازهای مشتری و رشد مداوم کسب و کار آسان تر می شود.

بسیاری از تصمیمات تجاری بزرگتر از آنچه هستند به نظر می رسند زیرا داستان تحقیق و توسعه اغلب به یک عدد کاهش می یابد: بودجه تحقیق سالانه. این عدد می تواند توجه را به خود جلب کند، اما به من نمی گوید که آیا یک شرکت در حال ساخت محصولات مفید است، تصمیمات دشوار را به تأخیر می اندازد، یا هزینه های سنگینی را بدون مسیر مشخص برای درآمد خرج می کند. وقتی طرح تحقیق و توسعه را بررسی می کنم، به الگوی پشت شکل نگاه می کنم. بودجه بالاتر ممکن است از رشد حمایت کند. همچنین ممکن است انتخاب ضعیف پروژه، چرخه های توسعه طولانی، یا افزایش هزینه ها با پیشرفت اندک را پنهان کند. سوال مفید این نیست که "شرکت چقدر هزینه می کند؟" این است که "هر دلار از هزینه تحقیق و توسعه چه چیزی به شرکت کمک می کند تا یاد بگیرد، بسازد یا بفروشد؟" ## فراتر از بودجه تحقیق و توسعه نگاه کنید، من با مقایسه هزینه های تحقیق و توسعه با درآمد شرکت شروع می کنم. محاسبات اساسی این است: ** شدت تحقیق و توسعه = هزینه تحقیق و توسعه ÷ درآمد × 100** یک شرکت نرم افزاری ممکن است 20٪ از درآمد خود را صرف تحقیق و توسعه کند، زیرا محصولاتش به مهندسی و توسعه ابری وابسته هستند. یک تولیدکننده بالغ ممکن است 4 درصد هزینه کند در حالی که بر ارتقای فرآیند، کیفیت محصول و کارایی تولید تمرکز دارد. درصد زمینه ایجاد می کند، اما به خودی خود تصمیمی ایجاد نمی کند. من همچنین رقم فعلی را با نتایج گذشته شرکت مقایسه می کنم. اگر هزینه تحقیق و توسعه از 50 میلیون دلار به 70 میلیون دلار افزایش یابد در حالی که درآمد ثابت بماند و عرضه محصول کند شود، می خواهم بدانم چرا. این افزایش می تواند از یک پلتفرم جدید پشتیبانی کند که به زمان بیشتری نیاز دارد. همچنین می تواند به کنترل ضعیف پروژه اشاره کند. یک جدول ساده می تواند جهت را نشان دهد: | اندازه گیری | سال 1 | سال 2 | سال 3 | |---|---:|---:|---:| | هزینه تحقیق و توسعه | 50 میلیون دلار | 60 میلیون دلار | 70 میلیون دلار | | درآمد | 500 میلیون دلار | 520 میلیون دلار | 525 میلیون دلار | | عرضه محصول | 6 | 5 | 3 | | شدت تحقیق و توسعه | 10 درصد | 11.5 درصد | 13.3 درصد | این الگو سزاوار بررسی دقیق تر است. کسب و کار بیشتر هزینه می کند، در حالی که راه اندازی و رشد درآمد کند می شود. ## تحقیق جدا از توسعه یک بودجه R&D بزرگ ممکن است شامل فعالیت های بسیار متفاوت باشد. تحقیقات می تواند شامل کارهای آزمایشگاهی، کشف مشتری، آزمایش های فنی و نمونه های اولیه باشد. توسعه می تواند شامل مهندسی محصول، صدور گواهینامه، آماده سازی تولید، انتشار نرم افزار و نگهداری باشد. این فعالیت ها دارای بازه های زمانی و ریسک های متفاوتی هستند. از مدیریت یا تیم عملیاتی می‌خواهم که بودجه را به گروه‌های واضح تقسیم کنند: - تحقیقات اولیه - توسعه محصول - آزمایش و صدور گواهینامه - افزایش مقیاس تولید - نگهداری محصول موجود - ابزارهای داخلی و زیرساخت - مشارکت‌های خارجی این تفکیک به من کمک می‌کند ببینم پول به کجا می‌رود. یک شرکت ممکن است رشد قوی R&D را گزارش کند در حالی که بیشتر بودجه از محصولات موجود به جای مناطق رشد جدید پشتیبانی می کند. که به طور خودکار یک مشکل نیست. نگهداری از درآمد فعلی محافظت می کند. نباید طوری ارائه شود که انگار همان پتانسیل رشد یک پلتفرم محصول جدید را دارد. ## نقاط عطف را دنبال کنید، نه تنها خرج کردن پول خرج شده با پیشرفت برابری نمی کند. برای هر پروژه بزرگ، من می‌خواهم مجموعه کوچکی از نقاط عطف قابل اندازه‌گیری را ببینم: - نمونه اولیه تکمیل شده - هدف فنی به دست آمده است - آزمایش مشتری شروع شده است - تست ایمنی یا نظارتی گذرانده شده است - هزینه تولید کاهش می‌یابد - قرارداد پرداخت شده امضا شده است - انتشار محصول تکمیل می‌شود. نقطه عطف باید شامل تاریخ، مالک و تعریف واضح موفقیت باشد. به عنوان مثال، یک شرکت باتری ممکن است گزارش دهد که یک نمونه اولیه به چگالی انرژی مورد نظر رسیده است. این مفید است، اما من همچنین باید بدانم که آیا نتیجه در یک نمونه آزمایشگاهی به دست آمده است یا در یک فرآیند تولید قابل تکرار. شکاف بین این دو مرحله می تواند بر طرح تجاری تأثیر بگذارد. همین مشکل در نرم افزار ظاهر می شود. یک شرکت ممکن است نشان دهد که یک مدل هوش مصنوعی در آزمایش عملکرد خوبی دارد. من همچنین هزینه استنباط، زمان پاسخ، حفظ مشتری، حقوق داده ها و تعداد کاربران پرداخت کننده را بررسی می کنم. یک نتیجه فنی زمانی مفیدتر می شود که به یک نتیجه تجاری متصل شود. ## خط لوله پروژه را مرور کنید من یک استراتژی تحقیق و توسعه را بر اساس هیجان انگیزترین پروژه آن قضاوت نمی کنم. کل خط لوله را ترسیم می کنم: ** ایده → نمونه اولیه → آزمایشی → راه اندازی → پذیرش → درآمد ** سپس تعداد پروژه ها را در هر مرحله می شمارم. شرکتی با 30 ایده اولیه و تنها یک محصول در بازار ممکن است قبل از اینکه R&D از فروش پشتیبانی کند با انتظار طولانی مواجه شود. شرکتی با چندین محصول که وارد آزمایش‌های آزمایشی می‌شوند ممکن است خط لوله متعادل‌تری داشته باشد، حتی اگر کل بودجه آن کمتر باشد. من همچنین به دنبال خطر تمرکز هستم. اگر یک پروژه 60 درصد از بودجه توسعه را مصرف کند، تاخیر می تواند کل طرح تجاری را تحت تاثیر قرار دهد. یک بررسی سالم‌تر شامل سوالاتی مانند: - اگر پروژه اصلی هدف خود را از دست بدهد، چه اتفاقی می‌افتد؟ - کدام پروژه ها را می توان بدون آسیب رساندن به کسب و کار اصلی متوقف کرد؟ - چه شواهدی به یک پروژه اجازه ادامه می دهد؟ - چه کسی صلاحیت توقف یک پروژه ضعیف را دارد؟ - آیا تیم ها برای یادگیری پاداش می گیرند یا فقط برای زنده نگه داشتن پروژه ها؟ توقف یک پروژه همیشه شکست نیست. ادامه تامین مالی یک پروژه پس از منفی شدن شواهد می تواند مشکل بزرگتری ایجاد کند. ## اتصال تحقیق و توسعه به تقاضای مشتری تیم های فنی می توانند مشکلاتی را که مشتریان ندارند حل کنند. من ارتباط بین کار توسعه و رفتار خریدار را آزمایش می کنم. مصاحبه‌های مشتری، توافق‌نامه‌های آزمایشی، نرخ‌های تمدید، داده‌های استفاده و سفارش‌های خرید امضا شده می‌توانند شواهد مفیدی ارائه دهند. یک شرکت تجهیزات پزشکی ممکن است نتایج آزمایش قوی داشته باشد، اما بیمارستان ها ممکن است هنوز پذیرش را به تاخیر بیاندازند، زیرا آموزش کارکنان بیش از حد طول می کشد یا تجهیزات با جریان کاری موجود مطابقت ندارند. یک محصول با انرژی پاک ممکن است در یک محیط کنترل شده به خوبی کار کند، در حالی که هزینه های نصب آن را برای مشتریان دشوار می کند. من برنامه‌های تحقیق و توسعه را ترجیح می‌دهم که مشکل مشتری را به زبان ساده نشان دهد: "ما زمان بازرسی را از چهار ساعت به یک ساعت برای این نوع کارخانه کاهش می‌دهیم." این جمله قابل آزمایش است. این به تیم هدف واضح تری نسبت به «توسعه پلت فرم بازرسی نسل بعدی» می دهد. ## اندازه گیری مسیر بازگشت بازده تحقیق و توسعه به ندرت در صنایع با سرعت یکسانی به دست می آید. من از قضاوت در مورد هر پروژه با چرخه فروش کوتاه اجتناب می کنم. من به مسیری نیاز دارم که قابل توضیح باشد. اقدامات مفید عبارتند از: - درآمد حاصل از محصولات راه‌اندازی شده در سه سال گذشته - حاشیه ناخالص بر اساس محصول جدید - هزینه جذب مشتری - دوره بازپرداخت - هزینه توسعه در هر راه‌اندازی - زمان از نمونه اولیه تا آزمایشی پولی - نرخ تکرار خرید یا تمدید - سهم درآمد مرتبط با پروژه‌های تحقیق و توسعه فعلی آمازون مثال مفیدی از این که چرا مقیاس به زمینه نیاز دارد ارائه می‌کند. گزارش‌های سالانه آن هزینه‌های فناوری و محتوا بسیار زیادی را نشان می‌دهد که منعکس‌کننده حوزه‌هایی مانند توسعه محصول، خدمات ابری، تدارکات و محتوای دیجیتال است. این رقم را نمی توان به عنوان تحقیقات آزمایشگاهی خالص خواند. شرکتی که اعداد خود را بررسی می کند، باید قبل از مقایسه خود با آمازون، همان تمایز را قائل شود. گزارش های سالانه آلفابت نیز هزینه های قابل توجهی در تحقیق و توسعه را نشان می دهد. ارزش این هزینه در جستجو، ابر، هوش مصنوعی، سخت افزار و سایر محصولات پخش می شود. درس ساده است: اثر تجاری بستگی به این دارد که پول در کجا تخصیص داده شود و پیشرفت چگونه اندازه گیری شود. ## یک برگه تصمیم بسازید وقتی باید تصمیم بگیرم که بودجه تحقیق و توسعه را افزایش دهم، حفظ کنم یا کاهش دهم، از یک کارت امتیازی کوتاه استفاده می کنم. | سوال | شواهد | |---|---| | آیا مشکل مشتری مشخص است؟ | مصاحبه ها، داده های استفاده، خلبان های امضا شده | | آیا ریسک فنی کاهش یافته است؟ | نتایج آزمایش، نمونه های اولیه، صدور گواهینامه | | آیا هزینه به سمت هدف حرکت می کند؟ | اقتصاد واحد، به نقل از تامین کننده | | آیا پروژه با نقاط قوت شرکت مطابقت دارد؟ | مهارت ها، دارایی ها، توزیع | | آیا بازار به اندازه کافی بزرگ است که از این تلاش حمایت کند؟ | تعداد خریدار، قیمت گذاری، تقاضا | | آیا تیم می تواند به نقطه عطف بعدی برسد؟ | مردم، بودجه، جدول زمانی | | آیا قانون توقف وجود دارد؟ | کتبی موفقیت و شرایط خروج | کارت امتیازی عدم قطعیت را برطرف نمی کند. بحث عدم قطعیت را آسان تر می کند. نظر من این است که حرکت تجاری بزرگ بعدی نباید بر اساس بزرگترین عدد تحقیق و توسعه باشد. باید بر اساس واضح ترین ارتباط بین هزینه، یادگیری، ارزش مشتری و جریان نقدی آینده باشد. یک پروژه کوچکتر با نیاز مشتری ثابت شده ممکن است مستحق حمایت بیشتری نسبت به یک پروژه بزرگ با زبان فنی چشمگیر اما شواهد پذیرش ضعیف باشد. قوی ترین تصمیم تحقیق و توسعه اغلب تصمیمی نیست که جسورانه به نظر برسد. این جایی است که اعداد توضیح می دهند که چه اتفاقی می افتد. برای کسب اطلاعات بیشتر ژو هونگمینگ، امروز با ما تماس بگیرید: zjsp-yxx@super.ac.cn/WhatsApp +8618767989127.

OECD (2015) Frascati Manual 2015 Guidelines for Collecting and Reporting Data on Research and Experimental Development Project Management Institute (2021) راهنمای مجموعه دانش مدیریت پروژه راهنمای PMBOK Eric Ries (2011) استارتاپ ناب چگونه کارآفرینان امروزی از کسب و کار موفق استفاده می کنند. کوپر (2019) محرک های موفقیت در توسعه محصول جدید کلایتون کریستنسن (1997) معضل مبتکر هنگامی که فناوری های جدید باعث شکست شرکت های بزرگ می شوند کاپلان رابرت اس و نورتون دیوید پی (1996) کارت امتیازی متوازن تبدیل استراتژی به عمل