首页 理论教育 混合应用分享策略探析

混合应用分享策略探析

时间:2023-06-09 理论教育 版权反馈
【摘要】:扩展后的PPS任务为必要的信息交流提供了启发,这一信息交流是在待开发的应用—沟通中发生的。接下来我们将借助对协同形式和协同媒介所做的总结来更为详细地探讨连续计划中的PPS任务,以便利用协同机制进一步确定应用—沟通。计划这一协同机制和阶段性被确定的计划值一起发挥作用,这些计划值能在全网范围内协同PPS任务。

混合应用分享策略探析

扩展后的PPS任务为必要的信息交流提供了启发,这一信息交流是在待开发的应用—沟通中发生的。2.1.2小节中已经提到的亚琛PPS模型对连续计划内为了可变的生产网络而发生改变的任务安排进行了阐述。和传统的任务模型一样,扩展后的模型也具有普遍适用性,也就是说适用于各种类型的生产网络。这样可以很好地覆盖生产网络中PPS具有的广泛的协同可能性和协同需求。

在应用—分享中,需要具备连续的、以中心企业为基础的生产流程计划。对于生产需求计划和控制,我们会使用有关变化的短期控制信息,以抵消由长期性造成的不确定性和生产流程计划中较粗略的处理方式。

接下来我们将借助对协同形式和协同媒介所做的总结来更为详细地探讨连续计划中的PPS任务,以便利用协同机制进一步确定应用—沟通。

与标准化的数据库一样,应用—沟通也是通过利用协同机制得以实现的。阶层式管控作为中心个体通过计划得以完善。由市场确定的价格会在网络运行过程中接受计划的不确定性。集中化的阶层式生产流程计划通过在网络合约中确定的计划得以体现;在分散的生产需求计划和控制中则是使用价格来应对可能对整个网络造成损失的行为。网络中只存在一个短期的协同需求,分散的订单调节起到了连接各个网络企业中的MES的作用。

计划这一协同机制和阶段性被确定的计划值一起发挥作用,这些计划值能在全网范围内协同PPS任务。生产流程计划中的计划值依据由通用数据库规定的流程得以处理。借助通用数据库已经可以得出,为了计划必须处理哪些信息。

目标设定被转化为计划值,因为它们已经被表述为具体的、可被实施的数值,并且可以得以控制。计划值以在具体情况中占主导的条件为导向,也就是说,一方面依据外部要求(如某一最迟的交货期限),另一方面依据企业内部的前提条件(如可支配的资产)。

在生产链的连续顺序中,计划值从最开始便发挥作用。全网范围内生产流程计划任务的实现取决于是否达到了相应的计划值。接下来我们将对计划值的得来做一般性描述。由此可以得出对具体解决方案的生产流程计划提出的要求。

与共同的生产流程计划一样,销售计划也是在全网范围内得以实施的。为下一周期计划出的终端产品的销售值对于整个网络而言有着决定性意义,我们会对它从种类、数量和交付时间等方面做出规定。而要由活跃终端市场的中心企业完成的计划值,则为我们提供了一个粗略的计划性数量框架。对于具体的不同类别(如不同车型)还会有所差异。下文的内容还遵循一个前提,即所有产品的具体属性(物理特征、规格型号等)在研发阶段或者进入网络之时都已经具备了完整的数据说明,所以不再被视为销售计划对象。

依靠企业内部的零件清单,中心企业可以确定(潜在的)直接供应商必须生产多少初产品和半成品(临时的二级需求)。也就是说,中心企业在网络范围内的销售计划中需要确定临时的、企业内部的二级需求。这是网络合约的基础,并会被直接的供货商加以利用,以便为他们自己潜在的供货商提供临时的二级需求,从而得到一个临时的生产计划。它被视为是接下来的库存和物料计划以及计算最终的二级需求的基础,只有在对销售计划进行了汇总和分配之后,才能为个体企业计算最终的二级需求。

根据中心企业为战略定位规定的目标,可以得出单个网络参与企业的PPS目标。在将网络目标展开的过程中必须注意,局部目标之间具有相互协同关系,即个体企业的生产计划相互协同,它们的计划内容互为补充。这样我们不会忽视网络中存在的潜力和特征,也会使得个体企业独立的目标设定可能有所不同。基于此,我们可以利用协同使个体企业中的产能所受的负荷较小,客户需要配备的库存量也明显减少。

用于协同的目标设定会被中心企业打破,而中心企业自身的库存计划和产能计划已经进入了供应商的计划值。但是这些计划值不允许成为供应商库存和产能利用的直接规定,因为如果那样操作,PPS协同问题就会最终在中心企业处集中化。当我们对所有生产阶段的库存和产能的不同类别和内容进行观察时,会发现很难通过中心企业对其进行控制。这样会使网络运行的复杂程度上升到集中化、阶层式计划的复杂程度上。资源计划的基础是遍及全网的、有关实际产能供应(即计划产能减去因为干扰而损失掉的产能)的透明度,或者一些更加细化的、可以说明机器的作用和局限的信息,如种类、技术、安装(即生产时间)等。这一点不论对于库存还是产能都适用。有关库存和产能的过程值不受集中化控制,从而便于保留网络相对于企业的优势。

许多计划值并不对PPS流程做出规定,而仅规定流程的结果,因此需要对结果进行成果控制。这些计划值也并不是要求企业层面上的库存和产能作为成本局部降低,而是要求它们尽可能地接近全网范围内的优化值。当然这也无法排除在网络企业内、在后续阶段,随意利用诸多为投入、产出制订的细化的目标值和控制值。而这些数值只有利于企业内部的目标,而并非我们所关心的网络层面的协同目标。

从库存计划和物料计划我们可以发现网络的优势,那就是不但可以影响自身企业的产能供应,还能影响伙伴的产能供应。我们可以在网络企业中进行检测,看其依靠现有资源能否实现销售计划和临时生产计划。我们依据种类、数量和期限制订的产量需求只是一种粗略计划,网络成员可以依据实际占有的资源对计算得到的产能需求进行调整。如果资源需求大大超出当前网络成员的资源供应,那么可以考虑引入新成员,或者扩大现有成员的产能。

利用遍及全网的资源计划可以即时发现瓶颈,并使网络内的资源总量与网络战略目标的实现相吻合。在全网范围内使产能供应与供货商需求相适应是在战略型网络内才具备的可能性,它来源于网络合约的长期性以及对订购量做出的承诺。实际上,生产流程计划只有在可变的生产网络中才能产生优化结果。在待开发的、为遍及全网的PPS协同机制提供的解决方案中,产能供应量可变。

就资源而言,我们在对网络进行考察时,需要对运输手段和装载手段进行扩充。根据生产企业和物流提供商之间的分工程度不同,运输体系在网络中也会发挥不同程度的作用。例如,在区域上非常分散的生产网络中运输体系发挥的作用与在地理位置上相近的伙伴间发挥的作用就不尽相同。因为在企业之间运输手段发挥了重要作用,这往往也涉及物流提供商,所以我们也需要将这部分供应商根据其作用大小纳入资源类别加以考虑。运输手段需求计划可以被称为资源计划的分任务,在这一范围内我们可以制订相互融合的路线计划。

我们这里并没有考虑对运输系统进行的全网范围内的地理优化,因为我们要么是在较复杂的运输物流中将带有物流提供商的运输网络设为前提条件,要么是在简单情况中将运输能力视为生产能力。在下文中,为了便于阐述,我们将物流运输看作是另外一个“生产过程”。

在二级需求的计算中,我们将建立标准化的产品清单作为生产流程计划的一部分,这样可以使网络成员的基础数据互为补充。要实现这一点,必须使得产品清单中描述的效率可以被自由聚合(参见3.4.1小节)。这样的产品清单可以存放在通用数据库中,因为它们可能在产品开发过程中或者在对资源计划进行反馈的过程中就已经生成了。根据产品清单,会对所有的生产计划以及被计划的产能和库存分散地进行调整,并沿生产链反馈给数据库。

借助这些标准化的产品清单、计划产能清单和计划库存清单,我们在之后遇到偏差或者要重新下发订单时,能够很快地做出决定。此外,借助这些清单我们还能够获得一些有助于我们了解概况的参数,如全网范围的部件使用频率等,这些参数可以作为采购网络的基础。

在二级需求计算之后进行的采购种类实际是企业内部关于“制造、合作还是购买”的决定,它并不属于我们这里探讨的采购网络。我们之所以关注它,是因为那些被决定要采用“合作”的订单会受它的影响。在网络中,成员之间的多重连接占主导地位(参见2.2.1小节)。从网络企业的角度来看,这种多重联系使它可以在网络内部对供应商进行选择。通常由于网络内部存在的多余性,往往会有数家企业可以完成同一产品或者零部件的生产。

利用订单分配,我们可以对全网范围内的采购种类划分进行调节。为此我们在需求方和供应方之间采用了拍卖这种订单分配方式。拍卖人是需求方,而在中心企业进行的全球计划和拍卖人这一角色之间并不存在任何一致性。供应方根据它们在当地的目标和当地的生产计划及生产控制来计划订单,并计算出产生的成本和他们将要提出的报价。

为了实现网络目标和产能、库存以及进程时间之间的协同而拟订的计划值,是与需求方为了达到计划值愿意支付的最高价格联系在一起的。同样,供应方的价格是与当地的PPS参数相联系的。采购种类划分会标记出走向市场效率以及走向依靠价格的生产需求计划和控制的过渡阶段。

在获取价格之后,需求方会决定将计划中的订单交付给哪个企业,这同时也完成了多个订单的分配。需求方和供应方之间会依照生产流程计划以框架合约的形式来签订网络合约。这一框架合约有可能是已有的、关于通用数据库的网络合约的补充,尤其是当产品的寿命周期超出生产流程计划的时间范围时,或者从这一刻开始企业才加入某一个网络,才与通用数据库产生连接。

在网络合约中,我们必须对生产流程计划的结果进行详细说明。在这一过程中,可以对所有与价格相关的计划值进行谈判,包括由价格决定的潜在变量和合同变量。提出最低报价的供应方即是最佳供应方,也会获得相应数量的生产订单。也就是说,在一开始就会展开竞争,这部分时间也会算在框架合约之内,除非出现了干扰。在传统的PPS系统中,通常的情况则是,只有在向外购买的计划和控制中才会选择最佳供应商。而时间上相对于向外购买计划和控制的提前量则取决于生产流程计划的有效期限。这一时间段的长短往往又和产品的寿命周期以及生产技术相关。如果不能保证产能负荷持续足够长的时间,就不能要求供应商建立产能。

在生产计划需求和生产计划控制中,我们要确保被确定的计划值具有有效性,并与中心企业算出的网络目标相兼容,因为这些目标值以及由它们得到的计划值其实都是一种承诺,实现这些承诺可以防止某一个企业单方面获利的情况发生。成果分配可以帮助我们依据实际效率再一次对价格做出调整。在这一过程中,我们需要对协同形式实行管控,也就是对生产需求计划和生产需求控制中的规定值和实际偏差进行检测,并以此为基础进行高效的成果分配。规定值/实际值偏差包括规定值/计划值偏差和计划值/实际值偏差。规定值/计划值偏差属于计划错误,是由计划的不确定性及其与实际要求之间的偏差造成的。计划值/实际值偏差则属于实现过程中的错误,是实际效果与计划之间的差异。

网络成员中承担客户角色的企业应该对计划与实际之间的偏差负有责任,因为是他制订的生产流程计划和相关的计划值。我们必须意识到,准确的计划是避免造成成本的关键性因素,如在仓储方面。例如生产商有可能通过提出过高的计划量来增加成本,以防止供应商的转包行为,但往往又难以避免发生退货状况。德国汽车工业联合会(VDA)的数据显示,一些生产商在近期供货需求中的浮动率竟高达60%。

计划值与实际值之间的偏差可能会对供应商造成影响。客户或者供应商处发生的计划偏差又必定会对被交换的物料的价格产生影响,也就是说会引起价格波动。因此我们在网络合约中已经做出规定,在发生偏差时,为了实现高效的成果分配,价格这一协同机制该如何上调或者下调。我们依据的前提是,环境数据的大部分变动仅涉及战略性参数,即物流效率方面的参数。就如我们后续描述的一样,我们可以很大程度地缩短新谈判的进程或者让新谈判自动形成。(www.xing528.com)

如果与签订的效率之间出现了较大的负偏差,可以规定重新进行招标。我们一方面要为了防止单方面获益增加而测量偏差,另一方面也是因为大量随机出现的对实际效率产生影响的因素。我们在对生产需求计划和控制进行调整时,必须考虑这些因素。

生产需求计划可以在内部网络分散地进行,也就是在单个的网络企业中进行,这一过程不需要对有关计划偏差之外的信息进行交流。面对价格这一协同机制,网络企业和普通个体企业一样做出反应,他们会购买网络合约中约定的产品数量,并根据有可能出现的价格上升或下降来对其进行优化处理。网络中的批量大小计划则与在普通连续计划中一样,与生产流程计划相互依存,无法在网络中被优化确定。我们之所以考虑这个因素,是因为交付的产品对于个体企业而言意味着一定的安装费用,因此也被视为一个成本因素。如果没有遍及全网的批量大小计划,生产批量就无法在网络范围内实现优化,这样便会在遇到过小批量时产生较长的安装时间。一旦遭遇瓶颈,就会出现问题。批量大小计划的问题由于在遭遇瓶颈时会产生较大影响,所以与资源计划紧密关联,而资源计划已在生产流程计划中得以完成。

我们必须要为时间安排计划和机器安排计划找到一个解决方案,这一解决方案应该是分散式的,与网络组织的理念兼容的,而且能够避免集中化的、阶层式计划的复杂性。要实现这一点,必须使企业内部的时间安排计划和机器安排计划能跟随价格波动自动发生,以便优化网络目标,并且尽早地汇报计划偏差。

相对于生产流程计划中的主要参数出现的较大偏差,需要在修改计划值的基础上向网络伙伴进行汇报,使他们对偏差造成的网络范围内的后果引起重视,并通过灵活排除瓶颈来有所应对。这种对偏差进行的即时汇报会受到相应的激励,以便可持续地促进这一行为。

我们找到的解决方案,一方面规定了对生产需求计划以及向网络即时汇报偏差的有效激励,另一方面利用了从资源计划中得到的有关现有产能的概况,可以快速地在网络内进行重新分配。获取有关现有产能概况这一要求对于生产控制而言,比对于生产需求计划有着更重大的意义。

生产控制由于与生产进行之间的时间间隔太小,因此无法在全网范围内得以实现,而且必须自动化,以便保证临时的解决方案。生产控制以分散且独立的方式来观察偏差,因为尽早向网络汇报偏差会以价格浮动的方式得到激励,这样可以保证分散化的生产控制正常运转。

如同在时间安排计划和机器安排计划中一样,我们在生产计划和生产控制中也需要注意,利用价格浮动来实现的控制尽管涉及整个网络,但却是在企业内部得以确保的。生产控制中购买计划和购买控制会在网络中以实际发生的、网络外的购买得以展开,这一购买属于某一采购网络的任务领域,而订单分配则是在网络内部进行的。对于网络外的购买,我们要将各个企业的订购数量联合起来,从而确定出合理的订购数量,这也是在采购网络中有待解决的一个问题。我们不必计算网络内部的订单数量,因为批量大小已经在批量规模计划中得以确定。

网络内部的供应及其评估可以在采购类型分类和签署网络合约之后借助对这一过程实施标准化来得以大幅度缩减。当需求方提出要加大网络合约中既定的供应量时,有可能需要重新进行招标。在这种情况下,我们可以利用效率信息(可支配产能的种类和数量以及可行的交货时间)和来自于新一次招标的价格信息找到可以承担这部分附加供应量的最适合的网络企业。

同样地,如果遇到生产需求计划中告知的交货时间延长,并且超出可被允许的范围,我们也可以在网络外部或者内部考虑选择其他供应商,当然要求新选供应商能够以同样价格,在更短时间内完成规定数量,或者以更低的价格,在同样时间内完成规定数量。

如果进行了新一次的招标,那么就会要求所有与这次产品供应相关的网络成员都重新进行报价,以便在考虑网络外供应商之前,为网络成员提供最后一次机会,可以让他们在了解了目前的生产现状后对自己的报价做出改进。

只要存在一个长期的、考虑了价格浮动因素的价格方面的一致认可,那么短期的干扰就并不一定意味着立即更换伙伴。真正重新举行招标在生产控制中也属于例外情况。我们会利用尽可能简单的、自动的计算成果分配的方法来应对来自于供应方和需求方有可能出现的与约定效率发生偏差的情况。

为了能为网络内的成员提供重要信息,并在此基础上形成协同一致的行动,我们需要对传统的订单分配方式进行扩展。网络中订单调节的任务即在前文中已经提到过的在分散的MES与由遍及全网的生产流程计划提供的计划值,以及在生产需求计划和控制中规定的对价格浮动的调节之间建立起关联。自动的数据收集是快速对计划偏差进行说明的前提条件,它也符合所有网络企业的利益。自动的数据收集能够实现不仅快速而且高质量的反馈。

在借助少量的额外消耗时,我们还可以将相应的实际库存反馈给数据库。当我们要对来自网络外部的有关交货时间的询问做出快速回答时,就可以利用这一信息。在全网仓储管理的框架内,我们必须将所有的实际库存和半成品向通用数据库进行反馈。只有这样,我们才能为网络的快速反应能力提供遍及全网的实际库存清单(有可能还需要计划好的或者预定的入库和出库时间)和仓库管理情况的数据,后者包含了对物料状态的评估以及库存持续期。

在不持续获取库存状况的情况下,我们也可以快速说明利用现有零部件可以生产哪些产品。因为在仓储体系中并不包含有计划的、强制的行动,而仅涉及带有服务性特征的局部任务,所以为了实现PPS连接,我们需要将这一服务提供给整个网络。我们还可以为这一服务配备售后服务。由此我们还可以提出有关建立超出生产网络的服务网络的问题,但我们不在这里对这一问题进行探讨。

订单调节的另外一个任务就是结合资源计划实现运输手段控制。为了实现这一目标,我们必须就运输期限、运输线路以及运输成本等相关信息进行交流,并采取相应的优化措施。这方面的相关信息也需要提供给全网的数据管理中心。与产能清单中的资源不同,跨企业的运输数据可以作为全新的数据类型进入数据库,它同时也是销售网络的基础。

此外,我们还需要为订单调节提供一个遍及全网的基准化分析。这一分析借助目标设定、控制以及订单分配来得以定义,它的用途不仅在于显示改进潜力,还在于作为跨组织的信息系统在网络伙伴之间起到协同作用。这样的一个基准化分析能为我们提供较高的透明度,以防止在合作关系中出现单方面获益增加的情况。

在实践中,我们在汽车行业中采用的基准化分析系统包括DFL(福特)、PICOS(欧宝)、Tandem(奔驰)、POZ(宝马)、KVPC(大众/奥迪)和POLE(保时捷),它们为流程、产品、成本、时间和质量提供参照值。这些参照值会进入数据管理系统。但在我们实际应用的基准化分析中,被关注的不是具有战略重要性的结果值,而是过程值,这些过程值起到的作用往往在于以完全阶层化的方式来对中心企业进行协同。如果在基准化分析中获得的数据超出了已被确定的目标值,那么我们不禁会问,这些数值还具有重要性吗?所以,我们只能借助在数据库中得以考察的数据来布置基准化分析,让它存在于已经提及的协同机制的组件中。我们不需要在订单调节中对它进行特殊考虑。

除了存在于网络企业中的MES与应用—分享之间的联系之外,上述订单协同的任务中没有哪一项是全网PPS协同必不可少的。它们更多地是起到一些辅助作用,为网络的其他方面(采购、销售以及售后等)创造前提,但却并非纯粹有益,就像对基准化分析所体现出的一样。

表3.7再一次总结了对网络中的混合应用—沟通提出的要求。

3.7 对战略型生产网络中待开发的协同机制的应用沟通提出的要求

978-7-111-58319-6-Chapter03-11.jpg

(续)

978-7-111-58319-6-Chapter03-12.jpg

来源:作者。

表3.7中包含的要求如同对通用数据库提出的要求一样,都对适用范围有一定限制,以便保证在网络中实现目标一致的PPS协同。为了开发适用于全网的PPS协同机制,表3.7中提出的要求必须在内容上和对通用数据库提出的要求一同得以实施(见表3.6)。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈