为什么企业不喜欢标准成本法?

本文对比了ERP系统中标准成本法与实际成本法在账务处理上的差异,通过具体案例展示了两种方法的不同之处,强调了标准成本法在复杂业务场景下的优势。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

导读:
  许多人都认为成本核算是ERP中十分重要的部分,正在选型的公司也往往对成本功能非常关注。我也认为其十分重要,甚至认为应该把成本核算能否自动完成作为ERP实施是否成功的标志之一。
  
  ERP软件中一般都有多种成本核算方法可供选择,通常分为两大类:标准成本法和实际成本法。实际成本法中一般再分为移动加权平均法、先进先出法、后进先出法等等。说起来各种方法并无优劣之分,然而为什么顾问常常推荐采用标准成本法?为什么企业中(尤其是国有企业)却总有人不喜欢标准成本法?这就成了不得不解释清楚的问题了。
  先说说为什么顾问常常推荐采用标准成本法,原因是外资企业多采用标准成本法,或者说在西方国家多数企业采用标准成本法。我常常听到看到有人这样解释,有时还会加上一句“这是先进管理思想的体现”。更多的人可能是更糊涂了,因为他们不明白标准成本法何处体现“先进”二字。我不认为标准成本先进,实际成本落后,前面说过各种方法无优劣之分。我认为西方多数企业采用标准成本的原因是:
  
  o 标准成本简单
  
  o 标准成本有效
  
  说标准成本简单,对应的就是说实际成本复杂。事实确实如此,假定遇到以下业务:物料A库存数量为0,有两个采购订单,价格分别是1元和1.1元,数量都是100个。两个订单到货后,物料A被生产消耗160个,库存剩余40个。发票收到后,价格略有不同,分别是1元和1.05元。这样的情景是经常遇到的,来看看标准成本和实际成本是如何进行帐务处理的,假定相关科目的初始余额都为0。
  
  先看标准成本,首先假定物料A标准成本是1元。那么在入库时,分录如下:
  借:存货100 -订单1
  贷:材料采购100-订单1
  借:存货100 -订单2
  借:采购价格差异10 -订单2
  贷:材料采购110 -订单2
  领用时,分录如下:
  借:在制品160
  贷:存货160
  收到发票后,分录如下:
  借:材料采购100 -订单1
  贷:应付款100-订单1
  借:材料采购110 -订单2
  贷:应付款105 -订单2
  贷:采购价格差异5 -订单2
  这时相关科目的余额分别为存货40,在制品160,应付款-205,采购价格差异5,材料采购0。
  
  再看一下实际成本,以移动加权平均法为例。入库时分录如下:
  借:存货100 -订单1
  贷:材料采购100-订单1
  借:存货110 -订单2
  贷:材料采购110 -订单2
  领用时分录如下:
  借:在制品168
  贷:存货168
  收到发票后分录如下:
  借:材料采购100 -订单1
  贷:应付款100-订单1
  借:材料采购110 -订单2
  贷:应付款105 -订单2
  贷:存货1
  贷:在制品4
  这时相关科目的余额分别为存货41,在制品164,应付款-205,材料采购0。
  
  比较一下标准成本和实际成本,入库业务分录,差不多,标准成本多出一个价格差异而已,一看就懂。领用业务分录,有区别,标准成本很简单,不作解释了。移动加权平均法中168如何得来?是1.05 x 160 =168。单位成本1.05如何得来,是(1 x 100 + 1.1 x 100) / 200 = 1.05。看起来已经复杂不少了。再看发票业务分录,标准成本不过是按发票价格调整了价格差异,很容易理解。移动加权平均法则要根据材料领用的情况调整存货和在制品,也复杂了不少。
  
  有人会说,你做的比较很好,但是实际成本的业务分录我都看得懂,不觉得复杂。是的,从上面的例子,虽然实际成本有些复杂,但是套上计算公式还能理解。可是事情没完,在企业的实际业务活动中,不会总是只有这样的情景。考虑一下如果收到发票时成品加工完毕,在制品已经转出该怎么办?如果收到发票时成品已经发货了,该怎么办?如果是部分成品完工和发货该怎么办?如果部分材料退回供应商该怎么办?
  
  采用标准成本法,成品是否完工,是否发货,是部分完工发货还是全部,以上列出的业务分录都没有变化,材料退回供应商,只要把入库分录按退货数量借贷反一下即可。每天的业务有很多也还是这样,没有什么变化,很简单。
  
  如果采用实际成本法,你得考虑追加多少销售成本,调整成品存货,在制品存货,退货时如何还原,如果是先进先出或后进先出,还要考虑批次。而且每天的业务不只有两三笔,多了怎么办?
  
  
  采用实际成本法的企业,尤其是采用手工记帐或采用模拟手工记帐的财务软件的企业,有几个能做到按订单核算成本,不都是按月汇总吗?这都是实际成本法中的复杂性造成的。
  
  标准成本有效,对应的就是说实际成本无效,什么地方无效?就是成本控制上无效。有人说我虽然采用实际成本,可是也设置了计划成本,一样可以体现出偏差多少。是的,根据计划成本,可以知道偏差多少。可是有一个前提,就是你首先要知道手上的实际成本是如何计算得出的,然后比较计划成本才可以得出每个需要的控制点-如采购价格、材料用量、人工等等偏差多少。从前面的叙述可以看出,你如何知道成品成本与计划成本的偏差多少出于原材料价格差,多少出于材料消耗差,由于计算过程的复杂性,很多企业只能得出每月的总数,没办法明细到具体的业务,眉毛胡子一把抓,所以也没有几个企业能根据计划成本实现真正的控制。
  
  当然,现在有了计算机系统,可以部分减轻人工计算的复杂,但人们对其理解分析的过程还是复杂的。管理中,简单有效的方法,比复杂有效的方法好,更比复杂无效的方法好。谁都明白这个道理。为什么还不在实践中应用呢?

本文转自
http://silverw0396.javaeye.com/blog/90595

<think>好的,我现在要帮用户解答关于搭建内部管理系统的第一步需要了解哪些方面的识。首先,回顾用户之前的对话,他们之前询问了公司内部管理系统的常见模块,现在想道搭建的第一步需要什么识。这说明用户可能正在考虑自己搭建这样一个系统,或者负责相关项目,需要指导从哪里开始。 用户可能是企业中的IT人员、管理者,或者是创业者,他们可能没有太多系统开发的经验,所以需要基础指导。接下来,我需要分析搭建系统的第一步涉及哪些关键点。通常,搭建系统的第一步是需求分析,但用户可能想道更具体的识领域。 首先,我需要明确用户的问题重点。他们可能想道在技术、业务流程、团队协作等方面需要哪些识。可能需要分步骤说明,先了解业务需求,再考虑技术架构,然后是团队和资源,最后是合规性等方面。 接下来,我需要考虑用户的潜在需求。他们可能希望有一个清晰的步骤指南,或者了解需要哪些专业领域的识,比如项目管理、系统设计、技术选型等。此外,用户可能关心如何避免常见错误,或者如何高效地启动项目。 需要确保回答涵盖以下几个方面: 1. 业务需求分析:如何收集和明确需求。 2. 技术基础识:比如系统架构、数据库设计、API集成等。 3. 团队协作与项目管理:如何组织团队,使用什么方法管理项目。 4. 合规与安全:数据保护、法律法规等。 5. 现有系统评估:是否需要集成现有工具或系统。 另外,用户可能需要了解一些工具或方法论,比如敏捷开发、微服务架构、云服务选择等。需要以简明的方式解释这些概念,避免过于技术化,让用户容易理解。 还要注意之前的回答结构,用户可能喜欢分点说明,比如使用数字或项目符号,使信息更清晰。同时,可能需要给出实施建议,比如推荐使用开源工具或云服务来降低成本。 最后,确保回答逻辑清晰,覆盖用户可能关心的各个方面,同时提供实用建议,帮助用户迈出第一步。搭建</think>企业内部管理系统是一项系统工程,需要从业务、技术和组织三方面同步推进。以下是分阶段的关键识储备和实施步骤建议: --- ### **一、业务需求梳理(决定系统方向)** #### 1. **业务场景地图绘制** - **核心问题诊断** • 现有管理痛点(如审批流程平均耗时3天/库存盘点误差率15%) • 高频业务场景(每日超50次的报销申请/跨部门协作需求) - **工具推荐** • 用 **BPMN流程图** 标注关键节点,使用Lucidchart或ProcessOn在线工具 #### 2. **优先级矩阵制定** | 紧急度 | 高影响(ROI>30%) | 低影响(ROI<10%) | |--------|---------------------------|--------------------------| | **高** | 第一阶段实施(如财务审批自动化) | 简化方案(如基础考勤模块) | | **低** | 长期规划(如AI预测分析) | 暂实施(如VR培训系统) | #### 3. **合规性扫描** - GDPR/《个人信息保护法》对员工数据存储的要求 - 行业特殊规范(如医疗机构的HIPAA合规需求) --- ### **二、技术架构认(避免选型错误)** #### 1. **基础技术栈选择** | 类型 | 自建方案 | SaaS方案 | 混合方案 | |--|--------------------------| | **优点** | 数据完全自主控制 | 快速上线(1周内) | 核心模块自建+外围SaaS集成| | **缺点** | 需专业运维团队 | 定制化能力受限 | 接口开发成本较高 | | **成本** | 初期投入>50万 | 年费3-10万 | 初期20万+年费5万 | #### 2. **关键组件认** - **数据库**:MySQL(事务型业务) vs MongoDB(日志/审批流) - **权限框架**:Spring Security(Java) vs CAS(多系统集成) - **流程引擎**:开源Activiti vs 商业版Flowable #### 3. **集成预研** - 现有系统API文档分析(如ERP系统的WebService接口) - 第三方服务对接测试(如企业微信消息推送成功率测试) --- ### **三、资源评估(降低实施风险)** #### 1. **团队能力矩阵** | 角色 | 必需技能 | 替代方案 | |--------------|-----------------------------------|------------------------------| | 后端开发 | Spring Boot微服务开发 | 使用低代码平台(明道云/简道云)| | 前端开发 | Vue3+TypeScript | 采购标准化UI组件库(Ant Design Pro)| | 运维工程师 | Kubernetes集群管理 | 直接使用阿里云ACK托管服务 | #### 2. **预算分配建议** - **初期建设**(6个月周期): • 人力成本:3-5人团队约30-50万 • 硬件/云服务:自建机房约20万 vs 阿里云年付8万 - **持续运营**: • 年度维护费≈初期投入的15%-20% #### 3. **时间管理技巧** - 关键路径示例: ```mermaid gantt title 系统建设关键路径 section 基础模块 权限系统 :done, des1, 2023-10-01, 15d 工作流引擎 :active, des2, 2023-10-16, 20d section 业务模块 CRM开发 :crit, des3, 2023-11-05, 30d ``` --- ### **四、实施路径推荐(分阶段推进)** #### **第一阶段:最小可行产品(MVP)** 1. **45天快速落地** - 核心功能:组织架构+RBAC权限+电子审批流 - 技术方案:若缺乏开发能力,可直接采用钉钉宜搭搭建基础版 2. **验证指标** - 审批流程平均耗时从3天缩短至<4小时 - 权限配置错误率<5% #### **第二阶段:业务系统扩展** - 优先开发ROI最高的模块(如库存管理系统降低损耗率) - 建立 **API网关** 对接已有ERP/OA系统 #### **第三阶段:智能化升级** - 引入RPA处理重复操作(如自动对账) - 搭建数据仓库进行经营分析 --- ### **五、避坑指南** 1. **数据迁移陷阱** - 旧系统数据清洗建议分三步走: (1) 静态数据(组织架构) (2) 动态数据(审批记录) (3) 遗留异常数据(手动补录) 2. **用户接受度提升** - 在开发期建立 **关键用户委员会**(Key User Group) - 采用渐进式上线策略(如先试点财务部再全公司推广) 3. **技术债控制** - 强制代码规范(使用SonarQube进行静态扫描) - 文档留存要求(每个API接口必须有Swagger注释) --- **建议第一步行动**:立即启动《业务需求调研清单》编制,包含: 1. 核心部门访谈计划(2周内完成) 2. 现有系统接口文档收集 3. 合规性检查清单(法务参与) 4. 预算审批流程启动 这套方法论可确保在投入开发前建立清晰的实施框架,避免后期出现方向性错误。实际项目中,需求理解偏差导致的返工约占开发总成本的40%,前期充分准备至关重要。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值