ISO9001/ISO9000/ISO14001/ISO14000管理体系认证费用价格大约多少钱
一、总认证费用由以下部分组成：
(1) 认证费用
(2) 咨询费用
(3) 产品检测费用（涉及标准，必要时，如食品企业、农产品企业都需要）
(4) 差旅费费用（吃住行费用）
(5) 计量器校准费用（测量重量、长度、宽度、速度等测量设备）
二、ISO9001或是ISO14001单独办理，60人以下认证费用和咨询费用一般在8000，不含产品检测、差旅、计量器校准等其它费用：
(1) 60人以下企业行业收费在8000.00左右，具体较终价格会根据人数调整；
(2) 60以上需要确定你所在行业，生产的产品，人数来决定价格。
三、ISO9001和ISO14001合并办理，60人以下认证费用和咨询费用一般在14000左右，不含产品检测、差旅、计量器校准等其它费用：
(1) 60人以下企业收费在14000左右，具体价格跟人数和产品有关系。
（1）业务架构
业务架构是指企业通过分析自身所处的外界环境，自身面临的机遇和挑战，同时剖析自身的结构特点和资源情况，明确自身优劣势，从而选择和制定企业发展目标，制定具体的实施方案和计划。核心要素主要包括业务目标、资源能力、业务流程和组织结构。放在企业层面是企业业务目标，放在部门层面是部门业务目标。对业务架构我们要思考一下的问题：
达成的目标是什么；
做什么业务；
资源和能力在哪里；
什么样方式在什么样的组织里做；
举例来说：企业采购业务的业务架构
业务目标：合理、合规、高效、节约的方式为集团各部门提供寻源、合同签订、订单执行等服务，保障和保本各运营业务线的运行。
资源能力：品类丰富、规模优势、采购模式多样，具备一定的市场话语权
业务流程：以集团统管的方式，实现供应商交付，需求部门验收的上下游流程一体化的格局
组织结构：建立集采、分采等采购团队，集中管控+授权自购的组织体系。
（2）数据架构
数据架构是基于数据管理领域知识经验的总结，提炼指导未来数据管理的过程。主要包括数据治理和数据管理。数据治理包括数据管理政策，原则，规范和标准等；数据管理包括数据总体视图和数据结构，数据库设计等。
（3）技术架构
技术架构是将数据架构和应用架构落实下去，通过技术的手段实现出来。主要包括架构规划和技术选型等事项。架构规划包括网络、平台、语言、中台、微服务等概念规划；技术选型主要是具体到某个产品时技术方案的选型，包括开源框架、语言、架构风格、数据库、中间件等。
（4）应用架构
应用架构是描述一个企业各个相互独立的应用系统的部署以及核心业务流程之间的关系。目的是建立业务架构与数据架构和其他架构之间的关联。它能连接业务架构的流程，功能，人员，也能够连接数据架构中的数据管理和使用，还能提出对技术架构的要求。主要分为表现层、应用层和数据层来表示
为什么产品架构图
画产品架构图目的是为了将业务架构拆解并梳理出产品思路，整体上把握产品的发展方向，把控产品的核心功能，决定了产品功能的实现路径和大体规划。当然，架构本身也是需要随业务的发展逐步的演进，具备一定的扩展性。这里阐述几条做架构的好处：
1、梳理产品方向和规划路径
这种图本身就体现了整个产品的结构，包括已实现的和未实现的，为产品的迭代指明方向，判断产品之间的依赖和关系。
2、为团队提供明确的目标
团队成员，包括，研发、测试、运营、市场和销售，能够根据这张图了解产品的规划，相应的团队可采取对应的策略。比如，研发可思考技术方案，市场和销售可制定产品的推销策略等。
3、建立业务全景图
产品规划是从业务架构中抽象出来的，反过来，可以帮助业务部门完善业务制度、和管理标准化，实现整个链条上的闭环。
03
构建产品架构图
构建产品架构图是需要产品人具备较高的综合能力，包括不限于：
相关的业务知识；
对相关成熟的商业产品了如指掌；
一定的技术知识储备；
产品战略和规划的能力；
抽象、归纳和结构化思维能力；
这里提供一个方法：6步构建To B产品架构图
1、梳理用户故事，全面认识业务需求，形成业务闭环
不管是从0到1构建一款产品，还是1到N迭代一款产品，当新的业务场景进来时，我们先要进行用户分析和需求调研，全面的认识需求，从组织级，用户级，开发级三个层面考虑不同类型的功能需求、质量需求和约束条件。比如，我们看一个企业采购需求到合同签订的场景。
图片
这里用户提交需求，中间经过招投标，较后才签订合同，涉及多个角色，多个业务场景，我们在分析的时候，就要全面的调研整个业务环节的用户，并记录其相应的业务诉求和现状。
2、识别业务链条的业务领域以及问题域
用户的需求陈述可能是模糊，可能是清晰的，我们在获取用户需求后，先要判断业务领域，再识别该领域内的问题。
（1）业务领域，是一个组织所做的事情以及其中所包含的一切。狭义上，如采购领域、生产领域、销售领域等。这里领域是采购领域，子领域是采购里的细分领域。我们将上面的例子进行领域划分后，分为需求领域、招投标领域和合同领域，如下：
（2）问题域，是指产品能够解决的所有问题的集合。架构设计是没有时间对所有需求进行深入分析，也没必要对所有的需求进行深入分析，只要抓住关键需求即可。关键需求决定架构，将核心需求当前要解决的，以及未来要解决的问题归集起来，作为问题域。比如，上面的例子包括不限于以下问题：
怎么识别该需求需要招投标；
招投标需求是否需要策略；
招投标如何制定比价模板；
招投标如何进行比价；
招投标如何进行定标；
合同签订有多方吗；
建立问题域是需要产品人具备一定的业务知识和结构化思维，可阅读相关业务书籍，比如采购，财务书籍等，提问过程可基于实际业务操作流来积累每个环节可能会出现的问题。
3、画出业务闭环流程图，并拆分出初步的解决方案域
通过前面的调研和领域划分，基本上能够确定业务场景现有的或将来的业务流程图。业务流程图的画法，可参考相应的书籍或后续文章会单独进行分享如何画好业务流程图。
基于业务流程图和需求，我们需要抽象和归纳同类型事物，用更高层次来表达。比如，苹果和梨子都是水果。上述案例我们基本可以得出整个流程上的初步解决方案功能。图片
4、明确产品定位，划分好范围
回到定位，不要走错了路。可参考：《战略（4）：TO B产品定位，千万不要忽略这两层！》。梳理完需求和业务流程以及初步的解决方案域，我们能够评估那些是当前产品或待规划产品的范围，不是当前产品定位内的需求，要果断的让另一个产品承接。比如，审批流的需求，当前产品内只能是部门内审批，涉及到外部门的审批，审批流的功能必须放在企业OA系统完成。
5、架构分层
清晰的产品架构图至少包括这三层：
表现层：用户接触产品的途径；产品展示给用户的界面、风格；
应用层：产品的功能模块划分、数据流向、接口集成；
数据层：产品的数据存储方式；
在进行产品架构分层时，我们可以采用自上而下的方法分别对展示层、业务逻辑层和数据层进行信息分类和排版。在信息分类时可以使用金字塔原理将每层核心信息尽量完全穷尽，相互独立。
分层之前需注意以下几项：
明确不同信息层级的边界：架构的层级表达有一定的信息流转逻辑，同一层级的上下信息流转要一致
明确同一层级的子模块边界：同一层级不同模块的边界要清晰，模块之间要做到可独立开发和部署
明确产品边界：产品边界要清晰，明确区分不同产品的颜色
（1）表现层
主要是用户的接触渠道，用户通过这个登录使用产品功能，获取相应的服务，一般可分为PC端和APP端。
（2）应用层
这个层将具体的功能进行分类组合成模块单元，先将大的模块填充，再将大模块下的功能点填充。
模块和功能的颗粒度如何界定？
模块的划分颗粒度可参照业务领域模型来划分，比如招投标领域的业务功能点归类到招投标模块，合同领域的功能点归类到合同模块；
功能点划分颗粒度可采用面向对象方法的实体颗粒度或者按完成某一项业务工作事项，比如，立项这个功能点，就是按采购员要完成发标前立项要做的工作任务来划分。
颗粒度大小没有明确标准，只要能表述一项工作任务即可。
另外，一些主数据，用户，组织架构，消息组件，日志管理、接口服务等服务能力可单独放在支撑层或者作为应用层的一些基础数据也是可以。
（3）数据层
这里主要是描述产品主要的数据存储数据库和存储方式。比如，涉及到结构化数据一般存储在Mysql，sql server等关系型数据库；涉及到文件，可能一般存储在对象存储。