المحاسبة عن تكاليف تطوير البرمجيات للاستخدام الخارجي في بيئة رشيقة 

 By Ryan P. Bouray, CPA, and Glenn E. Richards, CPA

  ( sleimanshaaban@gmail.com)SULEIMAN SHAABAN

March 12, 2018

تغيرت الأساليب التي تستخدمها شركات التكنولوجيا لتطوير برامج جديدة لعملائها في السنوات الأخيرة ، مما يجعل تطبيق قواعد رسملة تكلفة تطوير البرامج أكثر صعوبة.

 تستخدم العديد من الشركات نموذجًا رشيقًا لتطوير البرامج ليتم بيعها ، أو ترخيصها ، أو تسويقها بطريقة أخرى (المعروفة باسم برنامج الاستخدام الخارجي) ، وفي نفس الوقت تنفيذ أنشطة مثل التطوير والاختبار على المكونات المختلفة للبرنامج. في حين أن هذا النموذج شائع في ممارسة اليوم ، فإن القواعد في إطار المباديء المحاسبية المقبولة عموما GAAP تحدد متطلبات الرسملة استنادًا إلى المنهج التدفقي  (راجع مخطط "المنهج التدفقي") ، حيث يتم تنفيذ الأنشطة بترتيب تسلسلي محدد. كان المخطط التدفقي  يستخدم عادة لإدارة مشاريع تطوير البرمجيات في الماضي.

 المخطط التدفقي إن التغييرات في عملية تطوير البرامج منذ أن تم تطويرها في الأصل قد تجعل من الصعب على الكيانات التي تستخدم نموذجًا رشيقًا (راجع "مخطط رشيق") تطبيق قواعد GAAP بشكل مناسب لأنشطة تطوير البرامج ، خاصة في تحديد التكاليف التي يتم رسمتها وأيها تكاليف يتم تحميلها. يجب على المسؤولين عن المحاسبة والإبلاغ عن تكاليف تطوير برامج الاستخدام الخارجي مناقشة هذه القضايا مع فريق إدارة المشروع قبل إطلاق أي مشروع تطوير رئيسي ، حيث أن رسملة تكاليف تطوير البرامج تكون مطلوبة عندما يتم استيفاء العتبات تحت GAAP.

 المخطط التدفقي

إن التغييرات في عملية تطوير البرامج منذ أن تم تطويرها في الأصل قد تجعل من الصعب على الكيانات التي تستخدم نموذجًا رشيقًا (راجع "مخطط رشيق") تطبيق قواعد GAAP بشكل مناسب لأنشطة تطوير البرامج ، خاصة في تحديد التكاليف التي يتم رسمتها وأيها تكاليف يتم تحميلها. يجب على المسؤولين عن المحاسبة والإبلاغ عن تكاليف تطوير برامج الاستخدام الخارجي مناقشة هذه القضايا مع فريق إدارة المشروع قبل إطلاق أي مشروع تطوير رئيسي ، حيث أن رسملة تكاليف تطوير البرامج تكون مطلوبة عندما يتم استيفاء العتبات تحت GAAP.

 

 قد يؤدي الفشل في اتخاذ هذا الإجراء المبدئي إلى صعوبة فصل التكاليف بشكل صحيح بين تلك التي يجب أن يتم رسملتها وتلك التي يجب أن يتم صرفها. قد يؤدي ذلك إلى حدوث أخطاء في تطبيق مبادئ المحاسبة المقبولة عموماً بالإضافة إلى أخطاء في مبلغ صافي بيان الدخل أو الخسارة. تم تصميم هذه المقالة لمساعدة القراء على الإجابة على هذا السؤال: ما هي تكاليف البرامج التي يجب رسمتها وأي النفقات يجب أن يتم إنفاقها عندما يقوم كيان ببناء برامج استخدام خارجي باستخدام بيئة تطوير ذكية؟

الاتجاه نحو التنمية رشيقة

 أصبحت طريقة تطوير البرمجيات المعروفة باسم رشيقة شعبية في صناعة البرمجيات في السنوات الأخيرة. نظرًا لأن المنهجية الرشيقة (انظر مخطط "مقاربة رشيقة") يُنظر إليها على نطاق واسع على أنها أسرع وأكثر استجابة للمتطلبات المتغيرة بسرعة ، فإن العديد من الشركات تستخدمها الآن كبديل مفضل للنهج التقليدي لتنمية المخطط التدفقي كمدخل .

 ينطوي النهج التقليدي لتطوير المخطط التدفقي  على تنظيم مشروع في سلسلة من المراحل التقليدية ، مثل التصور والبدء والتحليل والتصميم والبناء والاختبار والإنتاج والتنفيذ والصيانة. تتميز هذه المراحل بأنشطة تستخدم التوجيهات كإطار لعمل استنتاج حول موعد تحقيق الجدوى التكنولوجية ويمكن رسملة تكاليف مشروع تطوير البرمجيات.

 في إطار نموذج رشيق ، من ناحية أخرى ، يتم تنظيم المشروع في وحدات منفصلة ، ويتم العمل على تطوير واختبار هذه الوحدات في سباقات قصيرة. تحديد متى الأنشطة التقليدية للنهج التدفقي تحدث يتطلب تحليلا كبيرا وحكم في تطوير رشيقة ، والتي يمكن أن تجعل من الصعب تطبيق توجيه مبادئ المحاسبة المقبولة عموما لرسملة النفقات.

 في نهاية المطاف ، يمكن أن تنتج كل من النموذجين الرشيقة والمخطط التدفق مشروعًا ناجحًا ؛ ومع ذلك ، فإن تحديد النقطة في عملية تطوير البرامج لبدء ونهاية تكلفة الرسملة يمكن أن يكون أكثر صعوبة مع النموذج السريع.

 مجموعتان من قواعد رسملة نفقات كتابة البرامج

 كنقطة انطلاق للاستفادة بشكل مناسب من تكاليف تطوير البرامج ، من المهم تحديد التوجيه المناسب. وبموجب المباديء المحاسبية المقبولة عموما (GAAP) ، قد يتم تطبيق مجموعتين محتملتين من القواعد الرئيسية عند تحديد ما إذا كان يجب رسملة تكاليف تطوير البرامج أو زيادتها.

 تم تصميم مجموعة واحدة من القواعد (FASB Accounting Standards Codification (ASC) Topic 985، Software) لتكاليف البرامج التي يعتزم الكيان بيعها أو تأجيرها. هذه القواعد ، التي يشار إليها عادة باسم قواعد استخدام البرمجيات للبرامج الخاصة باستخدام خارجي ، هي المحور الأساسي لهذه المقالة. وتحكم مجموعة القواعد الأخرى (ASC Topic 350، Intangibles - Goodwill and Other) البرامج التي لا ينوي الكيان بيعها أو تأجيرها. ويشار إلى هذه القواعد عادة باسم قواعد استخدام الأحرف البرمجية للبرامج الداخلية للاستخدام.

 من المهم ملاحظة أن الحد الأدنى للرسملة هو أقل بالنسبة لبرامج الاستخدام الداخلي. بموجب قواعد برامج الاستخدام الداخلي ، يمكن رسملة تكاليف التطوير بشكل عام بعد انتهاء مرحلة المشروع الأولي. إن الحد الأدنى لتكاليف تطوير البرمجيات الخاصة بالبيع أو الترخيص الخارجي - محور هذه المقالة - أكثر صرامة ، مما يعني ضرورة إجراء المزيد من التحليل لتحديد تكاليف التطوير التي يجب أن يتم رسملتها.

أين لا يتم محاذاة المباديء المحاسبية المقبولة عموما  (GAAP)  و البيئة الرشيدة:

تحت الموضوع 985 ، فإن القضية الحاسمة في تحديد ما إذا كانت تكاليف تطوير البرمجيات للاستخدام الخارجي يجب أن تتم رسملتها حول مصطلح "الجدوى التكنولوجية". أي تكاليف لتطوير البرامج التي يتم تكبدها قبل النقطة التي أثبتت المشروع أنها أثبتت جدواها التكنولوجية كمصاريف يتم تكبدها.

وبمجرد تحديد الجدوى التكنولوجية ، يمكن رسملة معظم تكاليف التطوير (وليس كلها). وأخيرًا ، بمجرد اكتمال التطوير وإتاحة البرنامج لإصداره للعملاء ، لم تعد الكتابة بالأحرف الكبيرة مناسبة لأن أي تكاليف متبقية تعتبر صيانة مستمرة ودعمًا. يجب أن يتم تحميل هذه التكاليف دائمًا عند تكبدها.

لذلك فإن تعريف "الجدوى التكنولوجية" هو العامل الحاسم في تحديد متى يتعين على الشركة البدء في رسملة تكاليف التطوير الخاصة بها. يقول الموضوع 985 ، "إن الجدوى التكنولوجية لمنتج برامج الكمبيوتر تنشأ عندما تكمل المنشأة جميع أنشطة التخطيط والتصميم والترميز والاختبار الضرورية لإثبات أن المنتج يمكن إنتاجه لتلبية مواصفات التصميم بما في ذلك الوظائف والميزات ومن المهم أيضًا ملاحظة أن تكاليف تطوير البرامج تخضع لهذه القواعد بغض النظر عما إذا كانت التكاليف قد تم إنشاؤها داخليًا (مثل وقت الموظف) أو خارجياً (مثل رسوم البائع).

في مشاريع تطوير البرمجيات التقليدية ذات المراحل المتتابعة والمحددة جيداً ، تظهر الجدوى التكنولوجية بشكل عام إما من خلال تصميم برنامج تفصيلي ، أو عندما يكون تصميم برنامج مفصل غائباً ، نموذج عمل جاهز لاختبار العميل. هذه هي افي بيئة مشروع رشيقة ، ومع ذلك ، يتم تطوير الوظائف والميزات الفردية بشكل منفصل في سلسلة من سباقات السرعة. كل تصور أو وحدة يتم تصورها وتخطيطها وتمويلها وتطويرها واختبارها بشكل فردي ليتم دمجها في المشروع ككل عندما تكون جاهزة.لمعالم المألوفة للمشاريع التي تستخدم المنهج التدفقي .

في بيئة مشروع رشيقة ، ومع ذلك ، يتم تطوير الوظائف والميزات الفردية بشكل منفصل في سلسلة من سباقات السرعة. كل تصور أو وحدة يتم تصورها وتخطيطها وتمويلها وتطويرها واختبارها بشكل فردي ليتم دمجها في المشروع ككل عندما تكون جاهزة.

في مثل هذه البيئة ، غالباً ما تكون تصاميم البرامج الشاملة أو نماذج العمل غير عملية أو غير ذات صلة. قد تستنتج الشركات التي تستخدم نهجًا رشيقًا لتطوير البرمجيات بشكل غير مناسب أن الجدوى التكنولوجية لم تتحقق بشكل كبير قبل إتاحة تحسين البرامج للعملاء ، مما أدى إلى تحمل التكاليف عند تكبدها بدلاً من أن يتم رسملتها. إذا تراوحت تكاليف كبيرة بين وقت الوصول إلى الجدوى التكنولوجية وعندما يكون البرنامج متاحًا للعملاء ، فقد تكون الحسابات الناتجة غير متوافقة مع مبادئ GAAP.

تطبيق GAAP في بيئة رشيقة:

على الرغم من أن إرشادات GAAP الحالية الخاصة ببرمجيات الاستخدام الخارجي لا تتناسب مع البيئة الرشيقة ، فإن هذا لا يعني أنه لا يمكن رسملة تكاليف التطوير المرنة على الإطلاق. هناك ، بعد كل شيء ، مستويات متفاوتة من خفة الحركة. في حين أن مشروع رشيق نقي قد يبدأ بفكرة وتصميم قليل نسبيًا ، إلا أن بعض المشاريع الرشيقة لديها تصميمات تفصيلية للبرامج مع قصص مبسطة متعمقة ودراسات قبول السوق ووثائق عمل التصميم الأخرى مجتمعة قبل بدء التطوير الفعلي. يمكن استخدام هذه الوثائق للمساعدة في تقييم الجدوى التكنولوجية.

النقطة الحاسمة التي يجب تذكرها هي أنه من أجل تقييم التكاليف التي يجب رسملة ، يجب أن يكون هناك تخطيط كاف للمشروع لإثبات أن معايير "التصميم التفصيلي للبرنامج" قد تم الوفاء بها. الخطر هو أن فرق المشروع قد لا تقوم بالتخطيط المسبق الكافي أو الاحتفاظ بالوثائق الكافية لإثبات أنها قد حققت هذا الحد. من المحتمل أن يتطلب إثبات الجدوى التقنية أن يقوم فريق المشروع بالمزيد من التخطيط وتجميع المزيد من الوثائق أكثر مما هو معتاد في معظم المشاريع الرشيقة.

هناك اعتبارات مهمة أخرى عند تحديد الجدوى التقنية تتعلق بخصائص التنمية عالية المخاطر. على سبيل المثال ، هل المشروع عبارة عن منصة برمجيات جديدة تمامًا ، أم هل هو تحسين أو إعادة إنشاء شيء تم إنجازه من قبل؟ هل تقوم الشركة بتطوير برامج من الألف إلى الياء ، أم أنها تجمع مكونات برمجية متعددة موجودة بالفعل؟ قد تتطلب السمات التنموية عالية المخاطر تحليلاً إضافيًا عند الوصول إلى الجدوى التكنولوجية ، وفي بعض الحالات ، حساب التكاليف  في بعض الأحيان ، قد تؤدي تحسينات المنتجات التي لا تعتبر أنشطة صيانة إلى تلبية عتبة إمكانية الجدوى التكنولوجية لأن المطورين يقومون بإضافة وظائف إلى منتج ناجح بالفعل. وتشمل العوامل الحاسمة في مثل هذه الحالات نوع البرمجيات ومستوى التعديل المطلوب ومستوى أعمال التصميم التي تم إنجازها قبل بدء التطوير.الرأسمالية السابقة.

حتى عندما يتم تأسيس الجدوى التقنية ، لا يمكن رسملة جميع تكاليف التطوير المرنة. في معظم الحالات ، يمكن رسملة بعض التكاليف فقط في كل سباق. وتشمل التكاليف التي لا ينبغي رسملتها التحليل المسبق ، واكتساب المعرفة ، والتخطيط المبدئي للمغير أنه ينبغي في كثير من الأحيان رسملة أجزاء كبيرة من التكاليف المتكبدة لتطوير هذه الميزات واختبارها إذا تم تحقيق الجدوى التكنولوجية. وتشمل هذه التكاليف الترميز الفعلي والاختبار وتكاليف اليد العاملة المرتبطة.شروع ، والنماذج الأولية ، وعمل التصميم المتشابه الذي يجب القيام به لتحقيق فهم الميزات والمزايا المرغوبة للمنتج.

ومع ذلك ، ضع في اعتبارك أن أي تكاليف تتعلق بالصيانة أو تصحيح الخطأ التي يتم تكبدها أثناء العجلة قد تحتاج إلى أن يتم إنفاقها بدلاً من أن يتم رسملتها ، حيث أن العديد من الأنشطة خلال السباق قد لا يتم ترميزها واختبارها ولكن قد تكون أنشطة مثل استكشاف الأخطاء وإصلاحها والاكتشاف. علاوة على ذلك ، تنتهي الكتابة بالأحرف الكبيرة بمجرد اكتمال المشروع ويكون البرنامج جاهزًا للاستخدام.

يمكن أن يؤدي التمييز بين التكاليف التي يمكن رسملتها وتلك التي لا يمكن رسملتها إلى تعقيد خطوات محاسبة المشروع وإعداد التقارير والوثائق داخل كل سباق. لكن العمل الإداري الإضافي لا يجب أن يكون مرهقاً. في معظم الحالات ، يمكن تقسيم المهام المختلفة والتسليمات داخل كل مشروع إلى فئات واسعة ، بحيث يمكن أن تكون جميع التكاليف المرتبطة بتلك المهمة إما مصاريف أو رأس مال.

التحضير والاتصال: الخطوات الحاسمة:

إن تحديد أي من تكاليف تطوير البرمجيات الخاصة بالاستعمال الخارجي يمكن أن يتم رسملتها في بيئة مشروع رشيقة ينطوي على قدر معين من الحكم. في العديد من الحالات ، ستقود الحقائق والظروف المحددة المحيطة بنوع البرامج التي يتم تطويرها إلى معالجة التكاليف. يمكن للتخطيط الدقيق أن يساعد في تحليل تكاليف التكلفة مقابل المصروفات.

لهذا السبب ، فإنه من المستحسن عادة مناقشة المعالجة المحاسبية مع فريق إدارة المشروع والخبراء الموضوعيين قبل البدء في أي مشروع تطوير كبير. من المهم أيضًا أن نفهم من بداية المشروع مستوى الدعم والوثائق اللازمة لاتخاذ القرارات المناسبة بشأن رسملة التكاليف. بالإضافة إلى ذلك ، هناك حاجة إلى فهم واضح لمستوى الوثائق التي سوف تحتاج إلى الحفاظ على مراجعي الحسابات لتقييم وتأكيد القرارات المتعلقة بالقيمة الكبيرة والصرف.

على سبيل المثال ، يجب على فريق المشروع توثيق وثيقة دور كل شخص في المشروع بشكل دقيق بحيث يمكن للمحاسبة التمييز بين الأفراد الذين من المحتمل أن يخضع وقتهم وأنشطتهم للرسملة وأولئك الذين لن تقع أنشطتهم أبداً في هذه الفئة. من المهم أيضًا الحفاظ على ضوابط داخلية إضافية مثل المراجعات الشهرية للأنشطة والمبالغ الرأسمالية والمصروفات ونماذج الاتصال التي يمكن لمديري المشروعات ملءها للتحقق من أن وقت الموظف قد تم تشفيره بشكل صحيح.

على الرغم من حدوث بعض المناقشات حول تحديث المعايير ذات الصلة لجعلها أكثر قابلية للتطبيق على إطار العمل السريع ، فإن مثل هذه التحديثات تستتبع عادة عدة سنوات من التخطيط والمناقشة والاقتراحات والتعليقات الصناعية. وهذا يعني أنه بالنسبة للمستقبل المنظور ، يتعين على الشركات التي تستخدم نموذجًا رشيقًا لتطوير برامج لبيعها أو ترخيصها الخارجي مواصلة التنسيق عن كثب مع فرق المحاسبة الخاصة بها لتطبيق إرشادات GAAP الحالية ورسملة تكاليف التطوير بشكل مناسب.