IC行业PLM需求分析

某IC研发企业主要进行通信芯片的研发工作,在全国很多地方都建有分公司,公司主要的业务内容是研发芯片的量产销售。公司致力于开发成熟的移动芯片产品,为客户提供IC产品引入后

产品应用

plm

需求分析

IC行业

1.1 系统业务需求描述
1.1.1 某IC设计企业现状

某IC研发企业主要进行通信芯片的研发工作,在全国很多地方都建有分公司,公司主要的业务内容是研发芯片的量产销售。公司致力于开发成熟的移动芯片产品,为客户提供IC产品引入后的整体解决方案,保障客户从引进初期到最终量产出货的全程支持。公司产品类别广泛用于不同网络制式的移动通信领域,包括GSM,WCDMA,TD-SCDMA等。
 
   
在信息化建设方面,企业较早使用了一些信息系统软件,包括SAP,用友财务统计等行业软件。此外,公司还自己开发了用于企业和供应商之间沟通协作的B2B平台,内部技术评估的技术评审系统。基于IBM的lotus notes平台,开发了企业日常工作的lotus系统审批流。在研发的日常开发中,使用了PADS Layout,等大型研发软件。
这篇论文中,主要关注公司PLM系统的运作。
 

1.1.2 PLM项目必要性分析
1.1.2.1 整体业务内容

由于半导体行业的高速发展,和人们日常数字消费理念的不断更新,对移动技术和产品都提出了新的需求,为了匹配这些要求,谋求更大的发展,移动研发的技术信息必然越来越先进化,多样化,这对企业也提出了更高的要求。对于IC设计公司来说,为了顺应潮流,更好的发展,企业就得不断扩大研发水平,提高竞争力,设计出更多更好更符合市场需要的产品。伴随研发设计的不断发展提高,必然产生大量产品研发数据,包括设计数据、技术规范、工艺资料、项目计划,产品信息,电子表格等。这就对技术数据的流转和管理提出了要求:技术信息内容越多越深,流转和管理就越复杂。
 
   
在某IC研发企业里,从发展规划、产品开发、支持服务、外包生产到销售,产品经历了一个复杂的过程。从人员组织角度来看,产品的过程涉及到公司内部部门之间,企业与企业之间,公司与客户之间供应商之间多种组合关系。不同关系之间交互信息各不相同,但需要进行统一的控制。从业务角度来看,公司各领域信息系统应用广泛,购买的商业软件和自己开发的信息系统同时存在,各司其职,运作良好,IT应用得到普及,包括ERP、B2B、SCM等。在这些应用运作的背后都是业务流信息,我们需要一套系统对业务流的信息进行管理,保证数据的有序、准确、标准规范。综上所述,无论从产品相关信息还是产品相关过程来说,我们都需要一套系统在产品的生命周期内,对相应的业务人员来组织协同,监督管理。
 

1.1.2.2 待改进问题
   在引入PLM系统之前,我们对企业内部做了个整体的评估,发现在日常的工作当中存在了不少问题,包括:
   (1)企业在过程管理中缺乏监督和管理途径;

   (2)对于技术资料的管理处于无序的一个状态;

   (3)搜索信息效率低下;

   (4)不同系统之间交互效率低;

   (5)由于企业是半导体行业,所以对信息的安全要求非常高,但就老的状态来看,大量信息交互缺乏管理监控机制,信息安全程度偏低;

   (6)公司没有一套系统的产品生命周期管理规范。
 
   针对这些问题,就需要进行系统的改造,引入流程管理。促进不同信息系统间数据同步交互,并对流程和文件引入安全权限管理等措施。
 

1.1.2.1 PLM的引出
在梳理了整体的业务和查找存在的问题后,我们意识到,无论是业务运作的管理还是已有缺陷的治理都需要一套新的东西,所以PLM的引入就显得尤为必要了。通过PLM,企业以多方协同为基础,产生标准集中的信息,利用这些信息对集团进行全面的管理。
 
   
PLM系统是如何运作的呢?为了清晰的说明这个过程,我们借助经典的IDEF0数据模型来进行表述。IDEF是用于描述企业内部运作的一套建模方法,由美国空军发明。IDEF0是以结构化分析和设计技术(Structured Analysisand Design Technique,SADT)为基础所发展出来的一种系统菜单表达的工具。藉由图形化及结构化的方式,清楚严谨的将一个系统当中的功能、以及功能彼此之间的限制、关系、相关信息与对象表达出来。PLM从生成到执行的IDEF0模型如图1-1所示:
PLM运作IDEF模型
PLM运作IDEF模型 
图1-1 PLM运作IDEF模型
 
在IDEF0图中,盒子代表系统功能(活动)。箭头代表数据(信息或对象)。活动的边表示所进入或离开的箭头作用,它们左、上、右、下的箭头分别是输入、控制、输出与机制的定义。从上面图中我们可以清楚理解PLM的机制主要涵盖到了信息数据整理,流程审批和全面发布三个过程。
 

1.1.1 企业业务分析
1.1.1.1 研发管理

研发部门的主要职能是新产品的研发,老产品的升级换代以及一些复杂问题的三线支持。研发部门在企业运作中根据不同的职能领域,划分为软件和硬件两块。具体工作内容包括:

   (1)新技术调研和产品发展策略中长期规划;

   (2)新产品创新研发,老产品升级开发;

   (3)方案,技术编写和评审发布;

   (4)根据项目要求开发项目产品;

   (5)确认产品使用元器件,解决元器件使用中产品出现的问题;

   (6)研发技术资料编撰管理,对外技术资料信息的编写审核。
 
   
在IC设计行业,技术要求不但新而且快,所以研发部门工作强度大。为了保证公司的竞争力,企业对研发提出了尽量提高效率,保证质量的要求。新产品开发大多根据已有的设计知识或设计成果,大约40%-50%是重用过去的部件设计,约10%-40%是对已有的零部件稍作修改,而只有10%-20%是全新的设计。在研发过程中,由于技术资料多,涉及面广,研发部门也对自己提出要求,要求科学管理技术资料,保证技术信息正确合规,建立团队评审,避免个人独断决策风险的要求。在编写给第三方技术资料信息的时候,研发部门要求数据正确,技术资料的格式要标准规范。此外,对整体的研发技术信息,公司提出了保障数据安全可靠的要求。
 
   基于研发日常的业务内容,考虑在引入PLM系统后进行如下方面的管控和运作机制:
   (1)建立完善灵活的各类产品技术信息审核机制,确保技术信息的正确规范;

   (2)集中管理技术文档,建立强大的搜索机制,便于研发人员快速找到需要的内容;

   (3)对技术信息进行严格的权限管控,非相关人员无法查阅到技术信息;

   (4)建立文档存储的内外网结构,安全要求高的放在内网,安全要求低的存储于外网,在需要时,提供内网信息转入外网的通道;

   (5)为了保障数据安全,对系统的数据信息引入备份机制。

   (6)对硬件版本和软件版本的发布建立流程审核,确保版本安全发布,知会所有相干人员,实时生效。
 

1.1.1.2 产品管理
产品管理部门的主要职能是公司产品测试,客户技术支持和公司已有产品的信息维护,从总体结构上来分,包括测试部门,技术支持部门和技术信息维护部门,其主要的工作内容包括:


   (1)公司产品的各类测试,包括系统测试、外场测试、自动化测试、准入测试等;

   (2)在发现公司产品问题后,通过各种途径及时解决;

   (3)作为公司和外部的技术信息通道,提供给客户或第三方需要的技术信息,包括技术规范、参数、产品工作机制等信息;

   (4)提供对客户的一线、二线支持,帮助客户引入公司的产品,并顺利应用到客户业务

   (5)在处理产品故障问题时,起到公司外部客户和内部研发间沟通的桥梁纽带作用。(6)对公司成熟产品的技术信息,进行维护和更新。
 
   
产品部门的工作,主要涉及到公司研发生产出产成品后的系列相关事务。需要对产品问题持续检测改善,在日常测试中,测试部门会提出各种测试规格或标准,在确认通过后会应用到实际的工作当中。在和第三方的交流协作中,支持部门会根据实际需要外发一些技术资料或信息,以提供给第三方参考,基于安全和规范的原因,需要根据具体情况,建立审核机制,以保障信息的正确和安全。对于公司已有产品的信息维护,在相关信息变动后,也需要经过具体的审核,无论是原材料的变更替换还是技术资料的修改,都需要经过专门的审核流转,在各相关功能部门人员确认通过后,才能予以正式的发布。
 
   根据日常的产品部门工作需求,考虑引入以下机制,以匹配产品部门业务运作的日常需要:

   (1)建立测试标准审核流程,在通过各相关职能部门的认可确认后才能予以正式发布,并供测试人员查询参考;

   (2)建立文件外发流程,集中管理公司所有外发第三方的文件,以保证技术信息的安全正确;

   (3)建立新物料替换审核流程,以确保物料更换信息的安全透明,对部件替换形成监督;

   (4)建立技术资料更新替换的审核流转,在各方确认通过后才能予以正式发布,以保障资料信息的安全更新,避免给公司带来损失的风险。
 

1.1.1.1 项目管理
项目管理的职能主要是新产品的研发项目管理,成熟产品的日常运作管理等。从行业特点来看,一个研发项目的确定关联到三方面的因素,包括:

   (1)通讯制式—移动行业的通讯制式标准很多,包括GSM、TD-SCDMA、WCDMA、LTE等;


   (2)软件版本—A公司主要运作的是在Android系统平台上的开发,企业开发的软件版本也在不断变化,包括如Android2.4,Android4.0、Android4.1等;

   (3)CPU性能—从硬件角度来说,CPU更新换代迅速,包括单核,双核,四核,多核等。
 
   基于以上的因素及分类,就衍生出很多的项目,可以看到,项目管理运作的项目数量非常巨大,项目管理涉及的内容包括:

   (1)项目的建立,在分析市场需求,结合研发部门讨论后,项目部门确定行业三方面的因素和分类,建立项目;

   (2)组织研发销售部门开会,讨论确定项目内容,制定项目计划;

   (3)规划调配项目资源,督促项目按计划进行;

   (4)对项目过程中涉及的信息流转进行审核把关,确保项目的安全有序进行。项目的运作过程,如图1-2所示:
项目运行过程图 
图1-2 项目运行过程图
 
项目的运作,最开始从项目决策开始,先进行定义后开始建立计划,在按计划执行的过程中如果发现需要及时反馈到项目组决策层,根据实际情况调整后,变更计划在执行,在执行后会产生许多实际成果和信息,包括文档、产品、新技术应用等。
 
   
在实际运作中,项目管理部门需要管理所有项目的基础信息,包括项目人员信息、项目内容信息和项目计划信息。另外在项目的运作过程中,项目管理部门还需要组织相关项目活动,跟进项目进度,项目质量,项目风险等各类因素,支持并引导项目按计划运行。
 
   
综合以上分析,我们把项目管理部门的职能规划到两个范畴:一方面项目管理人员建立分配任务,监督日常运作;另外一方面,项目管理人员进入项目事务的具体环节,履行监督审核职责。考虑通过以下手段实现相关职能体现:

   (1)在需要的审核流程中加入项目管理审批环节,以实现具体事务中的项目管理功能,符合遵循项目要求的予以审核通过,不符合要求的予以拒绝退回,如果没有项目管理审核,流程就不能流转;


   (2)建立项目管理功能模块,要求项目经理通过该模块设置项目节点,建立分发项目任务;

   (3)支持任务的层层分发功能,以保障复杂项目,多层次组织的任务下发分解,以实现项目任务的灵活管理,集中运作。
 

1.1.1.4 合规管理
合规管理,可以理解为是对企业遵循规则、企业信息流转标准化的管理。合规管理的主要职能是确保信息的标准化规范,业务操作的标准化审核和所有资源的统一编码化。其具体内容包括:

   (1)通过文控中心,确定统一公司文档资料的唯一性、正式性、合法性、有效性。

   (2)促进各类文档的格式标准,符合其所属文档类别的规范。

   (3)对于日常操作,敏感地方进行管控约束。确保业务运作符合公司和法律的规定,避免可能的风险给公司带来的损失。

   (4)对各类资源信息实行统一编码,确保内容清晰,业务流转中,一目了然,不产生歧义。
 
   
通过业务分析,发现在实际运作中,对于关系重大的文档,企业目前仍然缺乏一些强制关联的手段,很多时候,是当事人想到了就找相关人员审核,想不到就直接通过邮件或公司平台直接发布出去。对于有明确分类和标准的文档,一些人并没有意识到要遵循一定的规则,随意提交流转,导致信息混乱。在日常操作中,对于一些敏感操作,很多业务人员并不重视,贪图方便,给公司带来了一定的风险。在资源编码这一块,没有具体的规范可循,各部门有编码管理的意识,但各自为政,导致在部门内部都知道什么编码是什么,一出了部门,其他部门就弄不清楚编码的具体意义,形成了资源管理的混乱。
 
   针对以上暴露的一些弊端,考虑新的系统需做到如下几点设计:
   (1)建立重要文档信息发布流程,实现文档的审核发布,以保障文档的正确。

   (2)在标准文档审核中,加入规范审核环节,以确保标准文档需符合所属类别的规范。

   (3)对敏感操作建立流程审核,经过一定的过程审核通过后,才能进行操作,以保障公司的安全,清除该操作可能带来的风险。

   (4)在不同的文档流转中设置统一的编码规范,让公司员工知道。

   (5)在公司整个范围内,建立统一的物料编码规范,以便公司员工,不论哪个部门,只要看到编码就能够知道是什么东西。
 

1.1.1.5 运营管理
运营部门的日常运作主要是在研发部门完成产品研发后,从公司样品转化为最终到客户处的产成品的整个过程,主要包括:

   (1)物料管理,包括原材料、半成品和成品的管理。管理日常物料组数据信息,包括供应商、库存量、物料组、物料编号、物料基本信息、物料数量、价格等方面。

   (2)对生产用原材料和产品用元器件的采购和采购收货、发货管理。

   (3)对外包生产封装流程厂商的采购,包括晶圆生产、晶圆中测(CP测试)、晶圆封装、成品测试(FT测试)等各个环节供应商的采购管理。

   (4)生产管理,组织公司产品的外包生产制造,对外包生产的每个环节进行管理、监控生产进度、检查生产状况等。


   (5)生产资料技术信息管理,提供给外部厂商管理作为外包生产的参照。

   (6)芯片新产品封装项目立项,封装设计,组织封装生产。
 
   
运营管理集成了供应链的大部分环节,在接到公司研发出的样品和生产需要的技术资料后,运营部门开始后续到成品的全部工作。由产品工程部门对产品生产过程进行开发以达到量产标准,封装管理部门设计封装方式,生产管理部门整理生产用技术信息,组织物料管理、外包生产制造。采购部门根据生产计划和技术信息采购生产用原材料和外包的生产、测试、封装。在整个运营过程中,QA贯穿流转中的每个环节。外包供应商在运营部门的管理下,经过光罩制作、晶圆生产、晶圆针测、封装、成品测试等过程后成为产品正式入库。运营流程如图1-3所示:

IC生产运营流程 
图1-3 IC生产运营流程
 
针对整个运营流程,不难看出涉及到多个部门,业务信息量巨大。为了实现公司和外包商的良好交互,公司已经开发了与供应商之间的B2B系统。为了公司资源的良好运营,引入上线了SAP系统。由于采购价格直接影响产品成本;生产和封装是外包其他供应商来做,需要实现对过程进行及时详尽,有据可查的管控。
 
   针对以上的情况,在新系统设计中,我们要求引入以下设计要求:
   (1)建立物品采购的价格审核过程,以建立采购价格的审核发布过机制,降低采购风险;

   (2)对生产制造的过程进行控制,在企业内部建立测试数据的提交审核过程用来与外包生产数据进行测试比对,以管控外包生产制造过程是否规范;

   (3)建立对封装设计进行审核发布的过程,并提供给供应商,以确保供应商按照要求在进行封装。

   (4)建立项目管理机制,每次新品从样品到产品的过程,都作为一个项目,需进行监控管理,以保证产品的顺利完成。
 

1.1.1.6 质量管理
质量管理部门涉及到产品从立项研发设计开始到生产为产品整个过程中的管理,主要体现在以下几方面:


   (1)在研发过程中对研发的环节进行监控,确保流程没有缺失。

   (2)组织技术评审活动,查阅审核其他专家对具体研发技术的意见观点;对研发信息,从质量角度检查,提出改进建议;必要时,对未达到要求的研发内容,进行拒绝退回,要求研发人员重新进行相关工作。

   (3)在生产制造过程中,对某些环节数据进行检测对比,管理生产制造环节。

   (4)在成为产品后,测试部门和客户都会提出很多的产品故障和问题,质量部门需要对这些问题进行跟踪,问题都解决了,产品质量就好;如果问题解决率低,产品质量就差。

 
   质量部门的管理控制行为始终贯穿在日常研发生产的每个环节,基于其职责要求,引入以下设计:
   (1)根据质量管理要求,在需要质量控制的环节流程中,加入质量审核。

   (2)建立技术评审流程,加入质量部门管控环节。

   (3)在运营领域,将内部测试审核发布的数据提供给质量部门读取,质量部门再搜集外包供应商相应测试信息,进行对比,以确定外包生产是否达到公司要求。

   (4)建立每月产品故障问题,解决情况列表,经质量人员审核后,进行正式发布。




 
1.2 系统功能需求分析
1.2.1 用户及管理需求分析

一家普通公司对信息系统的数据安全是有一定要求,而作为IC设计企业,对信息安全要求就更高一些。作为基本功能,系统需要有用户管理、权限管理的功能,以便控制用户对系统内信息的访问。在控制用户对信息的访问时,要从流程使用、表单数据、信息提交、信息审核条件等多个角度综合考虑,系统管理员在安全管理方面做得事情用例如图1-4所示:
权限管理用例图 
图1-4 权限管理用例图
 
1.2.2 物料编码管理功能需求分析
为了加强企业的统一管理,需要规范和标准化编码信息,系统可以建立统一的编码规则,涵盖到所有业务领域,在系统各角色日常应用中流转顺畅,便捷易用。这就要求编码从建立到使用都能够操作方便,强制涵盖。在编码业务领域的用例如图1-6所示:
编码应用用例图 
图1-6 编码应用用例图
 
1.2.3 数据发布到其他业务系统功能需求分析
PLM系统发布的数据,需要及时无缝的同步到其他业务系统中,如ERP、B2B等。这样保证其他业务信息系统基础数据的标准化,避免由于不同业务系统的数据不一致而给公司带来的管理混乱。
 

1.2.4 邮件通知功能需求分析
由于使用人员不会一直开着PLM系统来查看,所以需要建立邮件通知机制。无论流程单是什么内容,只要在状态改变时,就要触发邮件自动通知机制,发送邮件信息提醒到所有关系人员,相应人员接到邮件后及时登入PLM系统进行处理,从而保证系统高效运作,不被耽误。




 
1.3 非功能性需求分析
PLM系统主要分为PLM基础平台,二次开发的PLM综合信息系统两部分。
 

1.3.1 基于PLM基础平台的非功能性需求分析
基于PLM的基础平台,我们要求:


   (1)图形界面内容结构清晰,什么条目里是关于哪方面的内容要一目了然,哪里做模板,哪里做流程,哪里管权限,进入系统后一看即知道;

   (2)要求一个单据模板只对应一个流程,而一个流程里面可引入多个模板。尽量保持流程和模板的一一对应,特殊情况下允许多个模板复用一个流程;


   (3)可定制化程度高,无论什么样的模板,多么复杂的流程,都能够通过基础平台的开发来实现。
 

1.3.2 基于二次开发中的非功能性需求分析
基于二次开发的系统,我们要求:


   (1)在基础平台上的二次开发即要能够进行网页页面的功能开发,又能进行程序的功能开发;

   (2)综合应用信息系统,要界面逻辑清楚,容易操作;

   (3)与其他系统的数据交互灵活及时,要有定期的数据同步机制和流程审批到特定环节下的触发同步机制;

   (4)系统PLM综合应用系统的应用要易推广、易维护。



 
1.4 本章小结
该章在对某企业的技术现状进行分析后,提出了PLM引入的必要性。在企业的业务层面,对各不同业务领域的应用进行了详细的需求分析。从系统应用的角度,对系统的本体需求,进行了全面地分析,涵盖了功能和非功能性系统需求。本章对PLM系统引入的整体需求,进行了多角度、全方位的分析。