MTC047--工程开发变更作业流程(业务变更需求)(ENG)

反审核作业流程

设计变更作业流程

设计变更作业流程 Prepared on 22 November 2020

1.目的为使设计与开发变更作业能循一定程序执行,以维护技术数据之正确性及产品质量的可靠度,同时规范设计与开发变更之识别、记录、审查、核准与传达等相关事项，特制定本流程。 2.适用范围凡本公司生产的产品及其附属之原物料、零组件因功能需求、客户要求、设计错误、制造或组装问题等，而对原设计进行修改或加强之设计变更均适用之。 3.名词解释： ECR：Engineering Change Request，设计变更申请。 ECN：Engineering Change Notice，设计变更通知。 4.权责：各单位权责（1）设计变更的申请： A.本公司内部任一单位若有设计变更之需求时,皆可依本设计变更的申请流程提出申请。 B.客户要求设计变更时,由业务单位提出申请。 C.本公司第三方建议设计变更时，由采购单位提出申请。（2）工程单位： A.负责受理设计变更之申请与编号,并做必要性可行性与影响性的评估与判定。 B.实施与督导设计变更案件的进行。 C.设计变更案件执行后，应将信息传达本公司各相关单位。（3）生管单位： A.协助调查厂内待设变物料状况。 B.设计变更后，督导生产单位、仓储单位管制设计变更前后物料，避免混料。（4）采购单位： A.协助调查厂商处待设变之物料状况。 B.设计变更后，应对厂商发行设变后工程图面，回收设变前图面，同时督导厂商处理设变前之物料。（5）生产部门： A.依ECN规定管制设变前后物料,避免混料。 B.设计变更后，修订相关作业标准及治工具。（6）品管部门： A.协助生产单位管制设变前后物料。 B.设计变更后，修订相关检验标准及治具。本流程由工程单位负责制定,推动与检讨改善。 5.内容：如作业流程所示。

设计变更管理工作程序与流程

工作行为规范系列设计变更管理工作程序（标准、完整、实用、可修改）

编号：FS-QG-22346设计变更管理工作程序 Design Change Management Work Procedure 说明：为规范化、制度化和统一化作业行为，使人员管理工作有章可循，提高工作效率和责任感、归属感，特此编写。设计变更管理程序 1目的对设计变更进行评审、验证与确认，保证设计变更的及时性、合理性和经济性，消除设计变更对工程成本和进度带来的消极影响。 2适用范围适用于施工图完成后的设计变更管理。 3术语和定义设计变更:指由设计单位或设计部对设计成果进行的修改。 4职责(由各单位自己决定，以下为参考职责) 4.1设计部 4.1.1设计变更信息收集、整理;

4.1.2负责组织相关部门对设计变更进行设计技术论证; 4.1.3负责设计修改和设计单位的联系管理; 4.1.4填写设计变更单下发项目经理部同时送现场销售备案; 4.2工程管理部:参与设计变更的技术论证; 4.3成本管理部 4.3.1负责变更成本测算; 4.3.2成本管理部经理负责审定单项大于2万元的变更; 4.4公司管理层:负责审定单项金额大于5万元的变更。 5程序 5.1设计变更的一般来源: 5.1.1设计缺陷或设计错误引起的设计变更。 5.1.2客户需求变更:在项目施工过程中，来自营销、业主、物业管理等方面提出的修改建议进行的变更设计。 5.1.3现场施工管理引起的设计变更:在施工过程中，因施工错误、材料/设备变更、施工现场条件误差、施工工艺技术等原因引起的设计变更。 5.2设计变更控制原则

5.2.1事先变更原则:不管是设计缺陷与错误、客户需求，还是现场施工管理引起的设计变更，尽量在需要变更的部分施工之前进行变更，避免返工、浪费成本和影响工期。 5.2.2先算后做原则:对设计变更必须事先测算成本，经相关领导批准后才能施工。 5.2.3设计变更完工确认原则:设计变更完工后必须予以确认，避免重复计算或“变而不做或少做”。 5.3设计变更流程(由各单位自己决定，以下为参考职责) 5.3.1设计部根据现场情况提出设计变更或接受其它部门的“设计变更申请单”。 5.3.2设计部组织相关工程师进行技术论证，做出是否可行的结论，如可行，由现场成本组进行成本测算;测算结果在2-5万元的变更，需成本管理部经理审定，设计部项目负责人填写《设计变更单》，设计部经理签字确认。 5.3.3测算结果大于5万元的变更，需报公司管理层审批，公司管理层不批准的则不通过。公司管理层批准的，审批过程结束。 5.3.4设计部发《设计变更单》或将变更要求提供给设

公司业务工作流程.综述

公司业务工作流程一、办公室（一）请假流程 1、男工请假填写标准请假条→班组长审批→部门负责人审批（请假3天以内）→公司主管领导审批（请假7天以内）→公司总经理审批（请假8天以上，30天以内）→集团人力资源部经理审批（请假1个月以上）。 2、女工请假填写标准请假条→班组长审批→部门负责人审批→公司女工主任审批→公司计划生育工作主管领导审批→公司总经理审批→集团人力资源部经理→集团计生办备案。备注：女工请假一次只能请7天的假期，7天后到单位履行续假手续。产假一次只能请3个月，3个月后到单位续假。 3、管理层请假填写标准请假条→公司主管领导审批→公司总经理审批（请假3天以内）→板块总经理审批（请假3天以上）→报送特铝办公室存档。（二）工资、各种奖金审核流程办公室劳资员造册工资表（奖金表）→办公室主任审批→公司行

政经理审批→公司总经理审批→板块总经理审批→集团人力资源部审批（内部的奖励不需要集团审核）→财务经理审批。（三）员工内退、辞职等流程 1、提前内退、内退手续办理填写员工个人手续申请表和提前内退（内退）协议→部门负责人审批→办公室主任审批→行政领导审批→公司总经理审批→集团人力资源部经理审批。 2、员工辞职手续办理流程填写员工个人手续申请表和辞职汇签表→部门负责人审批→办公室主任审批→行政领导审批→公司总经理审批→集团人力资源部经理审批。（四）报告呈递流程 1、生产类生产科起草→总工审核→总经理审批→办公室加章→特铝办公室→板块主管经理审批→板块总经理审批。 2、行政类办公室起草→办公室主任审批→行政副总审批→总经理审批→办公室加章→板块办公室→板块主管经理审批→板块总经理审批。二、生产科流程汇总 1、生产计划（月度） ①依据订单结构定产量计划及主要指标计划②生产科核定检修及废

配送中心-业务流程作业

配送中心业务操作流程配送中心的主要活动是订货、进货、发货、仓储、订单拣货和配送作业。首先确定配送中心主要活动及其程序之后，才能规划设计。有的配送中心还要进行流通加工、贴标签和包装等作业。当有退货作业时，还要进行退货品的分类、保管和退回等作业。如图2-1。

图2-1 配送中心作业流程图一、配送中心业务流程内容 1．进货进货就是配送中心根据客户的需要，为配送业务的顺利实施，而从事的组织商品货源和进行商品存储的一系列活动。进货是配送的准备工作或基础工作，它是配送的基础环节，又是决定配送成败与否、规模大小的最基础环节。同时，也是决定配送效益高低的关键环节。 2．订单处理从接到客户订单开始到着手准备拣货之间的作业阶段，称之为订单处理。订单处理是与客户直接沟通的作业阶段，对后续的拣选作业、调度和配送产生直接的影响，是其他各项作业的基础。订单是配送中心开展配送业务的依据，配送中心接到客户订单以后需要对订单加以处理，据以安排分拣、补货、配货、送货等作业环节。订单处理方式：人工处理和计算机处理。目前主要采用计算机处理方式。 3．拣货拣货作业是依据顾客的订货要求或配送中心的送货计划，迅速、准确地将商品向从其储位或其他区域拣取出来，并按一定的方式进行分类、集中，等待配装送货的作业过程。拣货过程是配送不同于一般形式的送货以及其他物流形式的重要的功能要素，是整个配送中心作业系统的核心工序。拣货作业的种类：按分拣的手段不同，可分为人工分拣、机械分拣和自动分拣三大类。 4．补货补货是库存管理中的一项重要的内容，根据以往的经验，或者相关的统计技术方法，或者计算机系统的帮助确定的最优库存水平和最优订购量，并根据所确定的最优库存水平和最优订购量，在库

设计变更作业流程

1.目的为使设计与开发变更作业能循一定程序执行,以维护技术数据之正确性及产品质量的可靠度,同时规范设计与开发变更之识别、记录、审查、核准与传达等相关事项，特制定本流程。 2.适用范围凡本公司生产的产品及其附属之原物料、零组件因功能需求、客户要求、设计错误、制造或组装问题等，而对原设计进行修改或加强之设计变更均适用之。 3.名词解释： 3.1 ：，设计变更申请。 3.2 ：，设计变更通知。 4.权责： 4.1各单位权责（1）设计变更的申请： A.本公司内部任一单位若有设计变更之需求时,皆可依本设计变更的申请流程提出申请。 B.客户要求设计变更时,由业务单位提出申请。 C.本公司第三方建议设计变更时，由采购单位提出申请。（2）工程单位： A.负责受理设计变更之申请与编号,并做必要性可行性与影响性的评估与判定。 B.实施与督导设计变更案件的进行。 C.设计变更案件执行后，应将信息传达本公司各相关单位。（3）生管单位： A.协助调查厂内待设变物料状况。 B.设计变更后，督导生产单位、仓储单位管制设计变更前后物料，避免混料。（4）采购单位： A.协助调查厂商处待设变之物料状况。 B.设计变更后，应对厂商发行设变后工程图面，回收设变前图面，同时督导厂商处理设变前之物料。（5）生产部门： A.依规定管制设变前后物料,避免混料。 B.设计变更后，修订相关作业标准及治工具。（6）品管部门： A.协助生产单位管制设变前后物料。 B.设计变更后，修订相关检验标准及治具。

4.2本流程由工程单位负责制定,推动与检讨改善。 5.内容：如作业流程所示。 6.附则：本作业流程经总经理核准后实施，修改时亦同。 7.附件： 7.1设计变更申请单()（2-3-01-01） 7.2设计变更管制记录表（2-3-01-02） 7.3物料调查表（2-3-01-03） 7.4设计变更通知单() （2-3-01-04） 8.相关文件： 8.1试模试作管理办法 8.2图面管理办法 8.3厂商管理流程设计变更作业流程流程图权责单位作业重点使用窗体

如何做好需求变更管理——需求变更流程规范

如何做好需求变更管理——需求变更流程规范一、引言由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。二、目的控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。三、角色与职责 1、市场人员 1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2）负责与客户的沟通确认，并及时反馈客户最新需求。 3）负责与项目经理的沟通 4）负责与客户协调沟通需求变更中需求部分存在的差异 5）负责将需求变更中的需求提供给客户签字确认 2、项目组长 1）负责协调变更的需求并对变更的需求有拒绝的权利 2）负责对变更的需求部分设计的修改 3）保证项目的开发与需求的一致性 4）确定开发进度是否需要进行变更 5）分配新需求给相关开发人员 3、测试组长 1）负责相应测试需求分析书的修改 2）负责把最新需求及时传达到测试人员 3）保证测试进度与开发进度一致性 4）负责与项目组长及时确认最新需求 4、测试人员 1）负责更改测试用例，保证用例与需求同步 2）调控测试进度，保证任务的正常完成 5、项目经理 1）参与需求修改的评审工作 2）最终确认需求是否进行修改 6、配置管理员 1）负责更新需求文档，记录需求更改记录

2）负责需求变更信息的发布与跟踪四、需求变更处理流程图需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图： 1、需求变更流程(客户提出需求变更) 1）执行条件：客户提出需求变更图：需求变更流程(客户提出需求变更) 2）流程说明：需求来源：客户提交相关需求变更

软件开发项目需求变更管理及应对之

软件开发工程需求变更经管及应对之道研究变化并不是人们最害怕的，最怕的是跟不上变化的步伐。同样，在软件开发过程中需求的变更会给开发带来不确定性，但只要把需求变更作为重点、难点小心加以控制，软件开发的进度、成本和质量也就有了"安全"的基础。需求变更经管的需求需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。需求变更的出现主要是因为在工程的需求确定阶段，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式。或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想

到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。这时，如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来经管需求变更，那么很可能造成工程进度拖延、成本不足、人力紧缺，甚至导致整个工程失败。当然，即使按照需求变更控制流程进行经管，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求经管会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更经管的目的所在。六大原则实施需求变更经管需要遵循如下原则： 1.建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。

需求变更处理流程

需求变更处理流程 1、需求变更的原因分析需求变更的表现形式是多方面的，如老板临时改变想法、项目预算增加或减少、客户对功能的需求改变等。在IT项目中，变更可能来自方案服务商、客户或产品供应商等，也可能来源于项目组内部。虽然需求变更的表现形式千差万别，但究其根本不外乎以下几种原因：（1）、范围没有圈定就开始细化细化工作是由需求分析人员完成的，一般是根据用户提出的描述性的、总结性的短短几句话去细化的，提取其中的一个个功能，并给出描述（正常执行时的描述和意外发生时的描述）。当细化到一定程度后并开始系统设计时，范围会发生变化，那细节用例的描述可能就有很多要改动。如原来是手工添人的数据，要改成根据信息系统计算出来，而原来的一个属性的描述要变成描述一个实体等。（2）、没有指定需求的基线需求的基线是指是否容许需求变更的分界线。随着项目的进展，需求的基线也在变化。是否容许变更的依据是合同以及对成本的影响，比如软件整体结构已经设计出来是不容许改变需求范围的，因为整体结构会对整个项目的进度和成本有初步预算。随着项目的进展，基线将越定越高（容许的变更将越少），其过程如下：变更请求à比较基线à变更实现。（3）、没有良好的软件结构适应变化组件式的软件结构就是提供了快速适应需求变化的体系结构，数据层封装了数据访间逻辑，业务层封装了业务逻辑，表示层展现用户表示逻辑。但适应变化必须遵循一些松祸合原则，各层之间还是存在一些联系的，设计要力求减少会对接口入口参数产生变化。如果业务逻辑封装好了，则表示层界面上的一些排列或减少信息的要求是很容易适应的。如果接口定义得合理，那么即使业务流程有变化，也能够快速适应变化。因此，在成本影响的容许范围内可以降低需求的基线，提高客户的满意度。

业务员每日工作流程

业务员每日工作流程终端或流通业务人员工作内容流程及要求一、工作内容及流程 1、准备工作： a、路线安排或按固定路线 b、答应客户应办未办事项 c、销售工具：广宣品、样品、抹布、价格表、订货单等。 2、每天早上07:50分出发。 3、拜访(销售及铺货) (1)、新客户拜访：问候(老板或大哥、大姐等，您好！)→自我介绍(公司、职务、姓名)→产品介绍(特点、产品展示、品尝)→推介利益(产品进货价、零售价、政策)→广宣品的张贴→收集信息(竞争产品的价格、促销、销量、新品上市、客户心理)。拜访成功：下订单(详细的有标志性建筑物的地址、店名、联系方式、准确的数量及价格、订货日期与送货日期必须填写、客户签字确认、留下业务及公司电话、有异议或特殊情况在订单右上角标明)→礼貌的再见→拜访下一客户。拜访失败：留下业务及公司电话→礼貌的再见→拜访下一客户。 (2)、老客户拜访：问候(老板或大哥、大姐等，您好！)→询问产品销售情况→规范陈列(生动化、好位置、大排面、清洁产品)→点库存→销售好→介绍老品政策、新品推介→销售不好→介绍老品政策、新品推介→(争取)订单→广宣品的张贴→建议、意见收集处理(售后服务)→竟品信息收集→礼貌的再见→拜访下一客户。 4、下午3:00至5:00电话报单。 (1)、电话报单时必须口齿清淅，店名、品名、数量等详细准确，单子开好后交楼下物流部安排配送。 (2)、新客户必须提供有效证件加入档案并通知销售内勤。 (3)、信息整理好后反馈给销售内勤并交销售经理。 (4)、尽量做到货到付款，不欠款。 (5)、每拜访一个客户，拍照上传到业务群。 (6)、有遗留问题及客诉等问题要及时解决处理。 (7)、到店查看退货情况，是否可退，不能退的坚决不退。 (8)、查看是否有窜货，有窜货的必须提供有效证据，照片、箱码、数量、单据等。 (9)、写工作日记。二、工作要求 1、每天按照拜访路线拜访所有客户包括沿途增加拜访频率的重点客户)，每户拜访时间不要过长，自行掌握。 2、每周一上交周工作拜访路线。 3、每周日上交周工作总结，每月25日交月工作总结及下月工作计划。 4、工作总结的内容：具体的工作内容、销售情况、销售额、竟品情况及分析(表格)、所遇问题、下周或月的工作计划、内容真实准确。 5、电话二十四小时开机，如果没能接听公司电话，在看到未接电话后，必须立即回复。如遇关机情况每次扣5元(在补助话费中扣除)。 6、业务人员在工作时间内不得随意窜区或做与业务无关的事，发现一次罚款20元，发现3次，立即开除。 7、每周一对竟品进行一次市场调研，填写竞争品牌市场调查表，主要是对竞争对手目前的销售状况、销售政策进行及时的掌握，以便公司做出正确的调整。要求认真详细填写，晚上交到内勤处。三、特殊情况有特殊情况时，应该及时与领导沟通，得到答复后，按照领导指示进行办理。有特殊工作时，必须服从领导安排，按时完成交待工作。产品陈列工作重点

ECN变更作业流程

目的为使本公司EC变更流程化、系统化，特制定本作业标准 1.2 使工程变更的各个环节处于受控状态，确保产品品质，生产效率提升和生产成本下降范围适用所有工程变更申请单、工程变更通知单。包括（对旧产品工程、性能、结构、物料、工艺、制程条件等方面的变更管理、新产品设计变更定义工程变更申请单通知( Engineering Change Request Notice) )：是指通常使用于新产品完成后，非工程单位就本身之需要发出工程变更申请，交工程单位、项目组研究设变可行性，由申请者提出工程变更申请。变更内容包括：设计更改、改进、供应商改变供应商制造过程改变、零件图纸更改、尺寸更改、客户端零件更改等职责项目经理负责协调变更团队，评审变更的可行性工程变更申请者提出申请，并会签到各相关部门：技术、前期采购、项目、工艺、物流、质量、销售、技术总监、各相关部门负责人要对所会签的变更单负责物流部门负责协调零件的断点：供应商断点及客户端断点、新旧零件

库存统计、设变后产品/零件的交付实施质量部门负责变更零件/产品的检验、特殊标识及记录的实施 SQE/前期采购负责设变阶段的样件追踪，OTS认可后转入量产的由物料计划追踪 ECN协调员协调所有相关环节的进度：包括库存统计进度、零件设变后在QA更改进度（包括物流参数重新设置）新旧零件库存结转进度前期采购负责QA系统设变后新件号采购日程维护、采购百分比维护产品部负责E-BOM修改、更新及图纸更新工艺部负责M-BO修改、更新 IT负责依照已发布的设变单更新QAD系统BOM状态释放，并邮件通知各部门QAD BOMg新结果财务负责依照已发布设变后新件号成本卷积 QE依照已发布设变后新件号更改检规 SQE提交设变后新件号PPA认可单5作业流程参见流程图第2页/第3页序号作业流程（申请ECN I —ES ￥核 ECN申客户核丁依据文件或说明职责使用表单责任部门支持任何部门可以就以下方面目的提出工程变更申请，从而变更产品功能、性能结构、物料、工艺、制程条件等：客户要求、降低成本、产品改良、采购需求、制程改善提交设变单位各部门工程变更申请单不同意变更时应说明理由并退回申请部门提交设技术产工程变更申请单出 NG 提 2

需求变更的代价

需求变更的代价让我们先来看一个需求变更的典型案例：Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。对软件需求和需

业务流程操作流程图

·风险控制部业务流程图：

开始风险控制部搜集企业相关信息业务经理尽职企业调查，完整收集资料后与风控专员对接风控专员核对资料，与业务经理及时沟通完善企业资料审部、授信部、法务部开会通过提出否定原因制定风险控制部意见书申请召开贷审会法务部制定合同

签署合同风险控制部办理反担保物登记手续资料归档（填写归档登记表） ·风险控制业务流程操作细则：

1、基本对接：业务经理在去企业调查之前与风险控制部基本对接，包括贷款企业名称，贷款金额，贷款期限，担保费率，企业从属行业性质。 2、搜集信息：风险控制部基本了解企业情况之后搜集企业基本信息与从属行业相关信息。 3、风控专员对接：通过业务部尽职调查，风险控制部根据企业所处行业及经营状况、借款人实际情况的不同，秉承务实高效，抓大放小且实质重于形式的原则，对企业的贷款用途及信用状况，经营管理能力、经营理念、发展趋势及近期财务指标主项核证（应收、应付主要客户往来记录，其他应付项目落实、成本分布明细等）进行详细对接。 4、审核及完善资料：通过对借款人的贷前，贷中审核内容主要有：◆借款方的实际贷款用途； ◆借款方的基本信息（包括其基础资料，充分了解借款方的偿还能力及信誉程度）； ◆抵押物的基本情况，质押物的基本情况； ◆第三方保证情况等相关的资料的核证 5、风险控制部论证风险：风险控制部贯穿整个贷款业务操作的全过程，组织内审、授信、法务，秉承齐抓共管，协调一致，从企业内部管理上把握贷款担保风险，其主要风险论证包括： ◆担保申请人的基本资料

A、法人 1、营业执照、税务登记证、组织机构代码证、工商信息查询单； 2、公司简介、验资报告、公司章程； 3、法人代表身份证、法人代表证明书和授权委托书； 4、申请担保的董事（股东）会决议及董事（股东）会成员签字样本； 5、借款用途有关的证明材料（购销合同、合作协议等）； 6、内审部审核近二年财务审计报告、近三个月财务报表（资产负债表、损益表、现金流量表）、银行对账单和近三个月的税单及水电费清单； 7、贷款卡及银行信贷登记咨询系统信息单，与报表不符应详细说明； 8、内审部审验存货明细、固定资产明细、应收账款明细及账龄分析表、或有负债情况表等； 9、反担保人\物\企业的有关资料； 10、其他有关资料。 B、自然人 1、个人简介； 2、身份证件及婚姻证明（如身份证、公务员证、教师证、警官证等）； 3、银行征信报告；

猎头业务操作流程

顾问猎聘流程操作手册一、拿到JD(job description)后应该在找寻人才前做哪些工作？ 1.上网了解客户背景：股权结构（股东是谁？各占多少？什么来历？）产业结构（主营业务？各占多少？规模？）行业排名（前后四位都是你将要找寻的企业）发展计划（3到5年的企业规划和计划）职位的汇报对象、下属结构、任职空间、职位是否是替换、新增；企业文化特点、用人的特色（资格要求、形象要求）薪酬在行业中的幅度； 2.确定找寻的人：目标行业目标企业：知名大型企业、规模相近，行业排名靠前目标职位：汇报对象、下属层级、人数目标学历：正规学历大网可查，第一学历本科，本科以下不考虑，函授自考不考虑。目标经历：大型企业集团任该职位3-5年目标人群：参考相应的资格证书、相关的工作经历、相关的熟练程度形象气质：总体身体比例均匀，形象气质中上等，言谈举止文雅，獐头鼠目者禁。地域考虑：就近找寻，用排除法，逐渐扩大。 Match原则：同规模（营业额）、同职位结构（汇报对象、下属层级）、同工作内容、同Case经历。 3、列出目标企业、排行榜前四位，确定合适的找寻渠道上网了解相应的候选人姓名、设定关键词（切莫本末倒臵）收索量：20个CV=6份邮件回传=3份面试通过=3份推荐报告=2位面试通过=1个Offer 4、一周二个职位，AC和RC必须完成5-7份报告一个月28份报告一个月14个人面试一个月6个复试一个月2-3个Offer 一个月1-2个开票或回款二、动手找人，需要统一以下条件，不可逾越！ 1.工作经历中有10年跳三家的，再优秀也不考虑； 2.第一学历本科以下的不考虑；后面哪怕读到任何高学历也不考虑； 3.学历中存在正在进行时的，没有毕业证书的学历，视同无效。 4.学历中出现本科3年等不符字样的不考虑； 5.中途自主创业的不考虑； 6.工作期间休息超过1年的不考虑； 7.有相应的工作资格证书，优先考虑； 8.有任何绑定协议、竞业协议、培训协议、住房协议、有重大违纪行为的拒不推荐。

IT项目需求变更表申请表(实例)

需求、设计和开发变更表产品名称龙岗政府在线升级改造项目项目名称龙岗政府在线升级改造项目项目经理霍军良变更申请人郭昊申请时间2007年7 月19 日变更类型 □新增需求需求变更□内部改进□产品缺陷 □系统环境变更□其他变更描述变更前的描述（若是新需求，则不需填写此栏）：区长信箱的管理部门（区长专线办）只能指定一个部门处理区长来信。新需求或变更后的描述：区长信箱收获的区长来信，区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果要求集中在前台按照各个部门的处理结果按照列表显示。变更影响的配置项序号配置项影响描述当前版本需求变更受影响的文档版本号的更新 2.0.1 变更评审方式项目组裁决□召开评审会议□会签评审评审负责人霍军良评审成员宋雷鸣、郭昊、卞兆洋、梁伟评审意见更改对产品组成部分的影响：在区长信箱多了一些功能操作。增加了多部门处理方法！更改方案描述：在页面中选择好要分发的部门，然后在后台将部门数据传入到集合内，循环遍历集合中数据属性存入数据库相关表中。并删除原来数据。最后在系统的工作任务中建立任务调度时间设置在每天22：00。变更对进度的影响（天）由于工作量不大，而且通过加班工作，对进度的影响可以忽略不计。第1 页共2 页

变更对成本的影响由于工作量不大，而且通过加班工作，对进度的影响可以忽略不计。变更对质量的影响添加这个新的需求会对系统测试案例等文档产生影响。对配置库的影响是：受影响的文档版本号的更新。变更引起的风险无技术评审结论可以更改□拒绝变更是否属不合格□是不是评审人员签字评审负责人评审人评审人评审人评审人评审人评审人霍军良郭昊宋雷鸣卞兆洋梁伟 CCB意见立即更改□推迟更改□拒绝变更签字林文涛日期2007年7 月19 日项目经理确认卞兆洋、郭昊在2007-7-18中午晚上加班修改完成。签字霍军良日期2007年7 月19 日变更当前状态□已指派□已打开□已更改已验证更改情况已经对区长信箱收获的区长来信，区长专线办可以分发给多个部门处理。各个部门能够按照自己的处理方式反馈。处理结果集中在前台按照各个部门的处理结果显示在列表中。更改人签字郭昊、卞兆洋日期2007年7 月19 日更改验证情况通过任务调度，已经测试通过，实现了分发给多个部门处理。验证人签字刘艳君日期2007年7 月19 日变更配置项验证变更的配置项责任人完成日期版本CMO审核结论需求变更宋志强2007年7月19 日 1.01 已更改完成第2 页共2 页

项目需求申请表

需求变更流程规范文件编号Document Number 文件名称Document Title 版本号Document Version 起草人Written By 姓名Name 职位Position 签字Signature 日期Date 审核人Reviewed By 姓名Name 职位Position 签字Signature 日期Date 批准人Approved By 姓名Name 职位Position 签字Signature 日期Date

目录一、目的 (3) 二、角色与职责 (3) 3.1 需求分析人员 (3) 3.2 项目研发人员 (3) 3.3 方案设计部中心 (4) 3.4 测试人员 (4) 3.5项目经理 (4) 3.6文档负责人 (4) 三、需求变更处理流程图 (5) 4.1 常见的3种变更情况 (5) 4.2 对应变更情况的处理流程 (5) 四、需求变更相关附件 (8) 附件一：文档编号01-01 (8) 附件二：文档编号01-02 (8)

一、目的控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。二、角色与职责 3.1 需求分析人员 1、负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2、负责与客户的沟通确认，并及时反馈客户最新需求。 3、负责与项目经理的沟通 4、负责与客户协调沟通需求变更中需求部分存在的差异 5、负责将需求变更中的需求提供给客户签字确认 3.2 项目研发人员 1、负责协调变更的需求并对变更的需求有拒绝的权利 2、负责对变更的需求部分设计的修改 3、保证项目的开发与需求的一致性而无偏差 4、确定开发进度是否需要进行变更

外包项目需求变更流程规范

外包项目需求变更流程规范 XXXX有限公司

目录一、目的 (3) 二、角色与职责 (3) 三、需求变更处理流程图 (4) 四、附件 (9)

一、目的控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。二、角色与职责 1、市场人员 1）负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2）负责与项目经理的沟通 3）负责与客户协调沟通需求变更中需求部分存在的差异 4）对于无法通过技术手段解决的需求，负责与客户进行协商 2、项目经理 1）负责与客户的沟通确认，并及时反馈客户最新需求。 2）负责协调变更的需求并对变更的需求有拒绝的权利 3）负责对变更的需求部分设计的修改 4）保证项目的开发与需求的一致性 5）确定开发进度是否需要进行变更 6）与供应商协调时间、开发费用 7）负责将需求变更中的需求提供给客户签字确认 3、测试组长

1）负责相应测试需求分析书的修改 2）负责把最新需求及时传达到测试人员 3）保证测试进度与开发进度一致性 4）负责与项目组长及时确认最新需求 4、测试人员 1）负责更改测试用例，保证用例与需求同步 2）调控测试进度，保证任务的正常完成 5、项目助理 1）参与需求修改的评审工作 2）最终确认需求是否进行修改 3）负责更新需求文档，记录需求更改记录 4）负责需求变更信息的发布与跟踪 6、公司领导 1）参与需求修改评审工作，对需求修改过程具有知情权 2) 对技术手段无法解决的需求，与客户进行协商三、需求变更处理流程图传统的需求变更有3种情况，一种是客户提出来要进行修改，增加需求等；一种是公司内部人员提交的建议；还有就是开发人员自己修改流程（修改后的效果比前面的更加好）。结合公司的具体情况，需求变更主要有以下3种情况。

需求变更文档

办公系统需求文档 -版本V1.00 GTEC

编写人:李亮广东国通电子商务有限公司 2011年09月修订历史记录表：一、目标通过OA办公系统实现人员沟通顺畅，部门协调，内部管理实现办公的无纸化。二、项目组成具体参考厂家提供的文档.

三、内部系统需求 3.1. 提供一个公共文档目录，让文档可以共享，可以通过设置相应的权限限制上传，下载，删除功能。所对应的OA系统中已经该部分功能修改部分可能实现，是否需要新增？ 3.2.部门成员对部门组长/经理、公司领导层的工作日报、周报、月报表的提交功能，要求能选择日期后直接填写及递交；每个部门有个提交报表的目录，部门组长，经理，或更高权限有权限查看，提交人可删除不能修改。类是于公共文档，区别在于查看权限不同。对应的功能可以通过修改工作管理-我的汇报可以实现该部分功能。注:工作日志，周报，月报我们理解上就是向上级汇报的，并不需要审批，只是让上级知道下属的工作情况。如需要审批可以在工作流程中定义工作审批流程。

3.3.部门内成员间、对其他部门(组长及以上职务才有权限)的工作委派单，包括委派者、委派对象、任务描述、完成期限、完成效果评价等功能；委派单下发之后在相对应的委派对象的工作任务中展现。可以通过修改工作流程—表单设计实现次功能是否令增加新的菜单功能？ 3.4.问题提交功能，如内部员工发现系统有bug 或者OA系统已经不能满足部门的使用，可以通过提交功能提交上来，领导审批之后，任务直接下发到产品技术部负责人的工作任务中。 3.5 .工作管理-菜单中增加汇报类别如：工作日志，周工作总结，可以实现自定义类别. 添加工作汇报的时，可选择具体汇报的类别，如每日工作日志提交，可选择工作日志，周报提交可以选择周报类别，类别可通过有权限的用户自定义。实现该功能后，在汇报管理中就能很清晰筛选出下属向上级汇报的工作，不会出现不具体的类别。增加：汇报类别汇报类别方便上级筛选具体的工作汇报类别进行查看。

业务操作流程

第一部分：询价报价及接单注意事项一，询价向船东提供目的港口（有的港口会有多个码头则一定要说明）、柜型、货物名称（普通、危险品、冻货、食品、特殊货物等等）以及询问运价所包含的内容（有无含ORC/BAF/DDC/THC/WAR/PSS 等等）以及船期、航程和是否中转。二，报价 1). 了解运价（在市场上有无优势以及客人对市场的了解程度）及舱位情况（特别是旺季），报价时首推公司优势航线；运费做PREPAID还是COLLECT（有些船东不接受COLLECT）；2). 内陆港口中转费要先落实好后再报价，特别是有些中转港的DTHC或其它费用需由SHIPPER支付的；美国及加拿大港口特别注意货名、货重及报价中有无含DDC/BAF/AMS等等； 3). 公司有特价航线及主推航线时，要及时主动打电话给客户通知价格；发E-MAIL或传真报价不要注明船公司名称，只能用电话说明； 4). 如客户需要到付运费，要注意我司是否在目的港有代理，报价要含手续费； 5). 注意所报运价的构成（全包价还是ORC、BAF、报关、码头、拖车等费用分列开来）以及利润是否符合公司要求等。三. 接单、审单、写（业务）单及录电脑 1). 客户接受报价后无论使用客户委托单或我司委托单格式，都要注意审核：托运人、起运港、目的港、柜型、柜量、货名、毛重、体积、运价、运输条款、所配船东、提单类型、最后装船期限、客户特殊要求或注意事项等，还有是否有加盖公章或签名，新客户还要留下联系电话； 2). 有些特殊港口，如中东港口是否有船证要求，同时亦应询问客户是否要根据信用证初单，信用证有无特殊要求等，如有，要提前传真与船东确认； 3). 确认有否舱位，如暴舱要及时告知客户，并给客户其它航线建议； 4). 写单：即填写业务联系单，共三联，货主（四字简称）、应收应付金额、预（倒）付、代理使用等。填写业务单要求字迹清楚工整，运价填写准确，运费预 /到付清晰；如做到付哪些费用需预付，哪些需到付要清楚；利润是否合乎公司要求；如客户有特殊要求一定注明（并盖上醒目的“特别注意事项”章）提醒操作注意； 5). 登本：即把工作号及其它信息登记上大本，分广州出运和深圳出运；如果深圳出运还需

需求变更流程规范详细列表

需求变更流程规范软件工程项目管理经验之一一、引言由于目前公司内部对产品的需求变动都只是口头或邮件中进行通知，并没有进行内部评审和相关需求变动后的记录，导致后续出的产品某些需求增加了，某些没有进行增加。这样就会导致测试得到的信息不完整，以及后续产品的维护困难。在这里书写一份规范说明书，希望能得到一些改善。二、目的控制需求变化引起的开发、测试与需求不一致的情况，约束需求分析的完整性。保证每一次的需求改动都能有相关的记录。三、角色与职责 1、市场人员 1、负责产品需求的提交以及解答项目开发过程中遇到的需求问题。 2、负责与客户的沟通确认，并及时反馈客户最新需求。

3、负责与项目经理的沟通 4、负责与客户协调沟通需求变更中需求部分存在的差异 5、负责将需求变更中的需求提供给客户签字确认 2、项目组长 1、负责协调变更的需求并对变更的需求有拒绝的权利 2、负责对变更的需求部分设计的修改 3、保证项目的开发与需求的一致性 4、确定开发进度是否需要进行变更 5、分配新需求给相关开发人员 3、测试组长 1、负责相应测试需求分析书的修改 2、负责把最新需求及时传达到测试人员 3、保证测试进度与开发进度一致性 4、负责与项目组长及时确认最新需求

4、测试人员 1、负责更改测试用例，保证用例与需求同步 2、调控测试进度，保证任务的正常完成 5、项目经理 1、参与需求修改的评审工作 2、最终确认需求是否进行修改 1、负责更新需求文档，记录需求更改记录 2、负责需求变更信息的发布与跟踪四、需求变更处理流程图需求变更有3种情况，一种是客户提出来要进行修改，增加需求等，一种是公司内部人员提交的建议，还有就是开发人员自己修改流程（修改后的效果比前面的更加好），另外需求变更可能是比较小的改动，另外一种就是可能涉及到整个产品流程，这就是比较大的需求改动。下面就按照上面的3种情况进行画出流程图：

需求变更申请表模板

项目需求变更申请表项目需求变更申请表填表说明 1.变更类型为：增加、删除、修改； 2.变更阶段为：需求阶段、详细设计阶段、开发阶段、测试阶段； 3.变更原因为：业务改变、新增需求、需求取消、其他（需明确原因）； 4.需求确定时间以QC人员收到项目负责人发送的项目需求确认文档的工作邮件时间为标准，项目需求文档包括但不限于项目需求原型和项目需求说明书。 5.项目需求确认文档必须发送到开发负责人、QC人员、开发部经理邮箱，QC人员做好备案管理。 6.变更优先级为：特级、普通、建议，对于建议级的变更“不参与讨论，不做处理”，仅作为给开发人员的参考，项目开发不做任何变动，QC人员做备档处理；特级和普通级的任何一个变更一经提出必须有明确的处理结果，QC人员做好全部过程中的备档处理。 7.基线影响只能填写“有”或者“没有”影响； 8.增加工作量：明确增加的具体工时，以“人/天”为标准计量单位，最低为0.5人/天； 9.项目进度影响：明确项目进度受影响的时间，明确项目要延期交付的时间，以天为计量单位，最低为一天； 10.项目性能（功能）影响：明确对某一个功能（性能）产生的影响； 11.QC(quality controller)质量控制员职责：在产品（项目）生产（开发）各个过程的（质量、规范）管理控制，并协同相关部门开展工作的职责。工作范畴为：原料（需求分析）生产（开发）过程成品产出（项目验收交付）。项目中所有的工作邮件包括但不限于需求变更邮件、人员异动邮件、人员外出支持申请邮件、需求（原型）变化邮件、项目会议记录邮件等必须抄送项目QC人员备案，未抄送邮件视为无效邮件。QC人员对所有的项目邮件进行收集、整理、统计备档。 12.对于无效邮件所有项目人员均可以不予理会，QC人员只对有效邮件做处理。 13.工作邮件的回复必须标准、简洁、明确。邮件第一行必须包括但不限于这行内容“邮件已收到，收到时间： 2011-10-20 12:01。”时间小时采用24小时制，精确到分钟。 14.项目基本信息、变更需求编号、分析者、需求分析日期由QC人员填写； 15.变更类型、变更阶段、变更原因、变更优先级由项目负责人填写； 16.变更申请人、变更申请日期、变更模块、变更前后内容（或者功能、性能、界面展示）描述由产品人员填写； 17.进度影响分析、功能影响分析由开发负责人填写； 18.审核签字：每位签字人员必须明确表示“同意变更”或者“不同意变更”并签名； 19.分析者包括但不限于产品人员，开发负责人，项目负责人，开发部经理； 20.所有填表处严禁出现语义表述模糊字样，必须明确表态“同意”“不同意”“是”“否”“有”“无”等；

MTC047--工程开发变更作业流程(业务变更需求)(ENG)

设计变更作业流程

设计变更管理工作程序与流程

公司业务工作流程.综述

配送中心-业务流程作业

设计变更作业流程

如何做好需求变更管理——需求变更流程规范

软件开发项目需求变更管理及应对之

最新产品和过程变更管理程序资料

需求变更处理流程

业务员每日工作流程

ECN变更作业流程

需求变更的代价

业务流程操作流程图

猎头业务操作流程

IT项目需求变更表申请表(实例)

项目需求申请表

外包项目需求变更流程规范

需求变更文档

业务操作流程

需求变更流程规范详细列表

需求变更申请表模板