- ghc-devs - Haskell.org

RE: GHC 7.8 release status
by Simon Peyton-Jones 11 Sep '13

11 Sep '13

I do need more than a patch, please, please. A wiki page explaining the design, as seen by the user (of the GHC API), the problems it solves, and the use-cases it enables, would be most helpful. Simon | -----Original Message----- | From: Thomas Schilling [mailto:nominolo@googlemail.com] | Sent: 04 September 2013 17:26 | To: Simon Peyton-Jones; Luite Stegeman | Cc: Nicolas Frisby; "Pedro Magalhães (dreixel(a)gmail.com)"; Richard | Eisenberg (eir(a)cis.upenn.edu) Geoffrey Mainland | (mainland(a)cs.drexel.edu) Iavor Diatchki; Austin Seipp; Edsko de Vries; | Ryan Newton (rrnewton(a)gmail.com) David Luposchainsky; ghc- | devs(a)haskell.org | Subject: Re: GHC 7.8 release status | | | On 4 Sep 2013, at 15:52, Simon Peyton-Jones <simonpj(a)microsoft.com> | wrote: | | > Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be | jolly soon. At the moment I don't even know the motivation or design, | let alone implementation. Could you make a wiki page explaining the | proposed design? Is it really important to do this for 7.8? | | Yes, it is quite important to get this into 7.8. Not having these | features in GHC makes it very difficult for people to adopt GHCJS. One | could argue that GHCJS is not yet production-ready anyway and users that | want to try it can figure out building GHC from source to use it, but | this doesn't quite apply. | | 1. GHCJS targets a wider audience than users brave enough to compile | GHC from source. In addition, the next chance to get these features into | GHC is in a year from now, so when GHCJS becomes more mature then this | will be a major hurdle for adoption. | | 2. These changes are also required for IDE tools which really mustn't | require users to build a custom version of GHC. | | | Luite's design is actually very flexible. It simply allows GHC API | users to provide functions that are called instead of (or in addition | to) existing functions in GHC. Instead of calling, say, "genHardCode", | the driver now looks up whether the user has specified a hook for | genHardCode and calls that instead. | | Currently we only specify a small number of hooks that are sufficient | for our use cases. Future releases of GHC can be extended to include | more hooks, if that is needed. | | Hooks are stored as an untyped map inside the DynFlags (to avoid issues | with circular dependencies). Each hook is looked up using a single- | constructor type and type families are used to make this type safe. | There is one use of unsafeCoerce to avoid having to make every hook | function an instance of Typeable. | | Unlike CorePlugins, it is only a GHC API feature, and users cannot | specify plugins to be added via command line options. If we can come up | with a good design, then we could add this in GHC 7.10, but it is not | necessary at this point. | | Luite: Do you have a link to your latest patch?

6 12

extending GHC plugins with Hooks
by Luite Stegeman 11 Sep '13

11 Sep '13

hi all, Sorry for taking so long to get back with this. I'm proposing a somewhat general way for adding 'hooks' to the GHC API, where users can override parts of the default compiling pipeline. Hooks are simply functions or actions that replace existing compiler functionality. This means that usually only one application can use a specific hook at a time. The obvious data structure to store the hooks is DynFlags. Unfortunately defining hooks in DynFlags directly would give birth to the mother of all import cycles, and it would also break the split-dll scheme on Windows. So here's the idea: - Define each hook in the module where it's exported - For each hook make a 'phantom' DataType and an instance for the Hook type familiy - Add a TypeRep based map in DynFlags [0] - For each hooked function, check for existence of a hook in DynFlags, otherwise run the default. Example: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… Now this approach does have some disadvantages: - No clear integration with existing plugins (I've tried adding an onLoadPlugin field to Plugin, where the Plugin could update DynFlags when it's loaded, but it was a bit messy, and plugins would not be loaded in time for some hooks, particularly what Edsko needs) - More of GHC depends on type families - Decentralized hooks definitions feel a bit messy So I'm open to suggestions for improvements (or replacements) of this scheme. I have some time the coming weeks to clean up or change the patch. We've been testing some hooks with GHCJS for a while, and so far they seem to provide what we need (but I'm going to doublecheck the coming weeks that we don't have missing functionality): - Customizations for linking JavaScript code with our own library locations [1] - Hooking into the DriverPipeline so we can use the compilation manager [2] - Desugaring customizations to remove some C-isms from the FFI code [3] - Typechecking foreign import javascript imports [4] - Override the built-in GHC.Prim so we can customize primop types [5] I think it's easy to add those for Edsko and Thomas as well. luite [0] https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [1] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44 [2] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [3] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [4] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [5] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… (sorry the linked patch also contains other modifications required for GHCJS, that i'm going to submit separately)

6 9

Re: [core libraries] RE: Alex and new Bool primops
by Jan Stolarek 11 Sep '13

11 Sep '13

Also got email error for my last message, so I'm reposting it below with some more information. From a technical point of view changes to Alex and Happy are simple and already implemented on my branch: https://github.com/jstolarek/alex/commit/32d4244894ae2702d965415483d0479d91… https://github.com/jstolarek/happy/commit/430ebe1f82744818cc488cd45fee0effa… I say we bite the bullet - this moment is as good as any other. There is one important thing to point out. After updating Alex and Happy you will need to update HEAD and rebase your older branches on top of HEAD containing new primops. Again, this is unavoidable no matter when we decide to make the change. Given that my changes affect 7 libraries (and only one of them is a submodule) you would need to rebase anyway. Janek ----- Oryginalna wiadomość ----- Od: "Michael Snoyman" <michael(a)snoyman.com> Do: "Simon Peyton-Jones" <simonpj(a)microsoft.com> DW: core-libraries-committee(a)haskell.org, "ghc-devs" <ghc-devs(a)haskell.org>, "Geoffrey Mainland" <mainland(a)apeiron.net>, "Jan Stolarek" <jan.stolarek(a)p.lodz.pl>, "Simon Marlow" <marlowsd(a)gmail.com> Wysłane: środa, 11 wrzesień 2013 5:04:24 Temat: Re: [core libraries] RE: Alex and new Bool primops I got a mail delivery error on this, so I'm going to resend. Apologies to those who get this twice. On Tue, Sep 10, 2013 at 6:37 PM, Michael Snoyman <michael(a)snoyman.com>wrote: > Having a requirement to manually install a newer Alex doesn't seem too > onerous to me. That would be my recommendation. > > > On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones < > simonpj(a)microsoft.com> wrote: > >> (Simon M: are you ok with updating Alex? You were the one of those who >> argued strongly for using the old names for the new primops.)**** >> >> ** ** >> >> The difficulty is this. **** >> >> **· **Alex generates Haskell code, by transforming Foo.x into >> Foo.hs**** >> >> **· **The generated Foo.hs contains references to comparison >> primops, say (>#) :: Int# -> Int# -> Bool**** >> >> **· **Therefore Foo.hs will not work with GHC 7.8 if we have >> changed the type of (>#), which is what I think we have agreed to do.**** >> >> **· **The solution is to make Alex generates a Foo.hs that is >> compilable either with GHC 7.8 or 7.6, by including enough CPP directives. >> Alex already does this for compatibility with earlier GHCs**** >> >> **· **However, until there is a new version of Alex, you simply >> won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD).**** >> >> ** ** >> >> That’s all there is to it. It’s tiresome and trivial in a sense, but >> it’s a choice we have to make.**** >> >> ** ** >> >> It might be perfectly reasonable to say **** >> >> **· **You can’t build GHC 7.8 from source with the Haskell >> Platform until a new HP comes out with the new Alex (which will be soon). >> **** >> >> **· **Unless you install the new Alex manually**** >> >> ** ** >> >> This seems not too bad; people who build GHC from source are generally >> pretty savvy. The choice between the two is what we seek your guidance on. >> **** >> >> ** ** >> >> (Incidentally, a very similar situation has arisen for Happy: see >> http://ghc.haskell.org/trac/ghc/ticket/8022. But there the cost of >> perpetuating the status quo for another release cycle seems minimal.)**** >> >> ** ** >> >> Simon**** >> >> ** ** >> >> *From:* michael.snoyman(a)gmail.com [mailto:michael.snoyman@gmail.com] *On >> Behalf Of *Michael Snoyman >> *Sent:* 10 September 2013 05:28 >> *To:* Simon Peyton-Jones >> *Cc:* core-libraries-committee(a)haskell.org; ghc-devs; Geoffrey Mainland; >> Jan Stolarek >> *Subject:* Re: [core libraries] RE: Alex and new Bool primops**** >> >> ** ** >> >> I'll admit a fair amount of ignorance of the GHC build process. But >> wouldn't it be standard that any tool used in the GHC build process itself, >> and built by GHC itself, would need to have some conditional compilation in >> place to handle API changes? It seems like the questions here are whether >> we should ever allow breaking changes in the API, and in this case whether >> the changes are coming too late in the development cycle. It seems like >> we've agreed on the first count that it's beneficial to allow breaking API >> changes. It could be that in this case we're too late in the dev cycle.** >> ** >> >> ** ** >> >> In this case, it sounds like including the compatibility module in Alex >> would be most expedient, but I'd defer to those who understand the process >> better than me.**** >> >> ** ** >> >> On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones <simonpj(a)microsoft.com> >> wrote:**** >> >> Dear Core Libraries Committee >> >> I think we need your advice. >> >> This thread (mostly on ghc-devs) shows that if the shim-package and >> boolean-primop decision goes as currently proposed, then we'll need a new >> release of Alex >> * Either to generate an import of GHC.Exts.Compat >> (ie depend on the shim package) >> * Or to make its own local tiny shim module for the primops it uses >> * Or maybe some other plan >> (Alex already has quite a bit of stuff designed to make it generate code >> that will be compilable with a variety of GHCs.) >> >> Moreover this new release of Alex will be necessary simply in order to >> allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current >> HP could not be used to build GHC. >> >> How would you like us to proceed? Thanks!**** >> >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >> | Geoffrey Mainland**** >> >> | Sent: 09 September 2013 16:14 >> | To: Jan Stolarek >> | Cc: ghc-devs >> | Subject: Re: Alex and new Bool primops >> |**** >> >> | I say this only somewhat facetiously, but this is *exactly* the sort of >> | problem that the pro-backwards compatibility camp anticipates, and I >> | mean the "pro-backwards compatibility camp" in the most general possible >> | way :) The point is that you can never anticipate all the ways in which >> | breaking backwards compatibility breaks things. How much "technical >> | debt" is really accrued with backwards compatible primops? What is >> | preventing us from doing the so-called "Right Thing" *after* the 7.8 >> | release? >> | >> | Anyway, the one solution I can think of off the top of my head is to >> | patch Alex's templates to use an #ifdef to pick primops based on the >> | version of GHC being used for compilation. That will need to be done >> | anyway. >> | >> | As an aside, I think any discussion that involves making decisions that >> | effect the community as a whole should have a public mail archive. >> | >> | Geoff >> | >> | On 09/09/2013 11:02 AM, Jan Stolarek wrote: >> | > I think the there was a general agreement in the committee that we >> | should follow the best long-term solution, not the best short-term one. >> | Here are two arguments (Plan B = break backwards compatibility): >> | > >> | > > I'd rather not hamstring GHC.* with a rats nest of backwards >> | compatibility decisions, >> | > > which all come at accreted costs, the mortgage for which is to be >> | paid down forever >> | > > by future development efforts. >> | > >> | > > I vote for plan B on the grounds that it's the Right Thing and the >> | > > group that it breaks is both small and savvy. >> | > >> | > > [implementing backwards compatibility solution] only works once, >> | though. We're in exactly the same boat on all future primop redesigns. >> | > >> | > There was also a decision of providing a backwards compatibility >> | package that would make it easy for library authors to create packages >> | that are compatible both with 7.6 and 7.8 (summarized here: >> | http://www.haskell.org/haskellwiki/Compatibility_Modules) Sadly, >> | there's no web archive for that list so I can't point you to the >> | discussion. >> | > >> | > Anyway, this is clearly something no one has anticipated and the >> | question is whether we have a good way to solve that problem? >> | > >> | > Janek >> | > >> | > ----- Oryginalna wiadomość ----- >> | > Od: "Geoffrey Mainland" <mainland(a)apeiron.net> >> | > Do: "Jan Stolarek" <jan.stolarek(a)p.lodz.pl> >> | > DW: "ghc-devs" <ghc-devs(a)haskell.org> >> | > Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09 >> | > Temat: Re: Alex and new Bool primops**** >> >> | > >> | > Perhaps the core libraries committee should reconsider their decision? >> | > :) Backwards compatibility is good. If HEAD implements the backwards >> | > compatibility plan that Simon PJ and I suggested and said plan is >> | > working, there should be a compelling reason to break compatibility >> | and >> | > have to go chasing down all the follow-on breakage (in, e.g., Alex) so >> | > close to release. >> | > >> | > What was the committee's reasoning? >> | > >> | > Geoff >> | > >> | > On 09/09/2013 10:08 AM, Jan Stolarek wrote: >> | >> I am refactoring new Bool primops (#6135). There was a discussion on >> | core-libraries-commitee list and the decision was made that we should >> | keep names of primops we used so far and change their type signature >> | (right now HEAD has different names for new primops and reuses old names >> | for compatibility wrappers). I've changed names of the primops and >> | removed the wrappers but I can't bootstrap GHC because old primops are >> | hardwired into Alex. I get this build error when attempting to build >> | stage 2 compiler: >> | >> >> | >> compiler/stage2/build/Lexer.hs:2348:34: >> | >> Couldn't match expected type 'Bool' with actual type 'Int#' >> | >> In the first argument of '(&&)', namely '(offset >=# 0#)' >> | >> In the expression: (offset >=# 0#) && (check ==# ord_c) >> | >> In the expression: >> | >> if (offset >=# 0#) && (check ==# ord_c) then >> | >> alexIndexInt16OffAddr alex_table offset >> | >> else >> | >> alexIndexInt16OffAddr alex_deflt s >> | >> >> | >> compiler/stage2/build/Lexer.hs:2348:53: >> | >> Couldn't match expected type 'Bool' with actual type 'Int#' >> | >> In the second argument of '(&&)', namely '(check ==# ord_c)' >> | >> In the expression: (offset >=# 0#) && (check ==# ord_c) >> | >> In the expression: >> | >> if (offset >=# 0#) && (check ==# ord_c) then >> | >> alexIndexInt16OffAddr alex_table offset >> | >> else >> | >> alexIndexInt16OffAddr alex_deflt s >> | >> >> | >> And indeed, looking at Lexer.hs I see: >> | >> >> | >> alex_scan_tkn user orig_input len input s last_acc = >> | >> (...) -- some irrelevant code here >> | >> (!(new_s)) = if (offset >=# 0#) && (check ==# ord_c) >> | >> then alexIndexInt16OffAddr alex_table >> | offset >> | >> else alexIndexInt16OffAddr alex_deflt s >> | >> >> | >> So to compile GHC, Alex would need to generate different code for GHC >> | 7.6.3 and below, and different for GHC 7.7 and above (or alternatively >> | it could generate #if pragmas), but this means we'd need to update Alex. >> | I created compatibility module within GHC called ExtsCompat46 and tried >> | adding it to list of imported modules, but in generated Lexer.hs Alex >> | adds a bunch of other modules among which is GHC.Exts, which conflicts >> | with import of ExtsCompat46: >> | >> >> | >> compiler/stage1/build/Lexer.hs:2349:41: >> | >> Ambiguous occurrence `>=#' >> | >> It could refer to either `ExtsCompat46.>=#', >> | >> imported from `ExtsCompat46' at >> | compiler/parser/Lexer.x:79:1-19 >> | >> or `GHC.Exts.>=#', >> | >> imported from `GHC.Exts' at >> | compiler/stage1/build/Lexer.hs:75:1-15 >> | >> (and originally defined in `ghc- >> | prim:GHC.Prim') >> | >> >> | >> Again, we would need updated version of Alex to generate correct code >> | (also, this would break in the future after removing that compatibility >> | module). I don't see a way out of this. Help? >> | >> >> | >> Janek >> | >> >> | >> _______________________________________________ >> | >> ghc-devs mailing list >> | >> ghc-devs(a)haskell.org >> | >> http://www.haskell.org/mailman/listinfo/ghc-devs >> | > >> | >> | >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs(a)haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out.**** >> >> ** ** >> > >

1 0

A bug of linebuffering
by Kazu Yamamoto 11 Sep '13

11 Sep '13

Hi, While I support GHC head for "doctest", I encountered the following bug. "doctest" uses a GHCi subprocess to evaluate an expression represented in String. Stderr from GHCi is merged into stdout by hDuplicateTo in the GHCi side. Even evaluating an error expression, for instance "1 `div` 0", the line buffering does not work. "doctest" waits for output from GHCi forever. This does not happen if stderr is not merged into stdout. The following code demonstrates this bug. Running it with GHC head waits forever. Running it with GHC 7.6.3 prints: "*** Exception: divide by zero" "3" If you change "1 `div` 0" into "1 `div` 0\nprint 10", this code run by GHC head prints: "*** Exception: divide by zero" "10" This is a serious behavior change for "doctest". I hope this will be fixed. --Kazu module Main where import System.Process import System.IO myProc :: CreateProcess myProc = (proc "ghc" ["-v0", "--interactive", "-ignore-dot-ghci"]) { std_in = CreatePipe , std_out = CreatePipe , std_err = Inherit } setMode :: Handle -> IO () setMode hdl = do hSetBinaryMode hdl False hSetBuffering hdl LineBuffering newInterpreter :: IO (Handle, Handle) newInterpreter = do (Just stdin_, Just stdout_, _, _) <- createProcess myProc setMode stdin_ setMode stdout_ hPutStrLn stdin_ "import System.IO" hPutStrLn stdin_ "import GHC.IO.Handle" hPutStrLn stdin_ "hDuplicateTo stdout stderr" hFlush stdin_ return (stdin_, stdout_) eval :: Handle -> Handle -> String -> IO String eval hin hout expr = do hPutStrLn hin expr hFlush hin hGetLine hout main :: IO () main = do (stdin_, stdout_) <- newInterpreter eval stdin_ stdout_ "1 `div` 0" >>= print eval stdin_ stdout_ "1 + 2" >>= print return ()

1 1

the spam should stop now
by Carter Schonwald 10 Sep '13

10 Sep '13

I pingged the haskell infrastructure folks, and they've hopefully fixed it up properly.

1 0

如何构建人力资源管理系统
by 沛菡姐 10 Sep '13

10 Sep '13

4 3

Re：劳-动法律法规、政策如何渗透
by 祁烟芷 10 Sep '13

10 Sep '13

1 0

不同发展阶段中试管理模式与实践
by ytzkqmho＠jxda.com 10 Sep '13

10 Sep '13

　产品中试管理——从样品到量产 ======================================================================================　培训时间：2013年9月22-23上海、9月25-26深圳、9月28-29北京培训对象：企业CEO/总经理、研发总经理/副总、测试部经理、中试/试产部经理、制造部经理、工艺/工程部经理、质量部经理、项目经理/产品经理、高级制造工程师等培训费用：2800元/1人| 4300元/2人（含资料费、午餐、茶点、发票等) 　热线电话：400-633-0030 深圳/市场部：0755-61282649 刘小姐上海/市场部：021-31200290 金小姐　课程背景：我们在为企业提供研发管理咨询服务的过程中发现，很多企业的新产品开发从样机到量产的过程中（产品化过程）存在着共同的问题： 1.新品没有经过中试或中试的时间很短，制造部门戏称研发的新品是“三无”产品，没有生产文件、没有工装、生产现场出了问题没人管； 2.转产没有标准，研发想快点转产，生产对有问题的产品又不愿接收，希望研发把问题都解决了才转过来，而市场又催得急，经常被迫接收，长此以往，导致研发与生产的矛盾激化； 3.有些企业开始成立中试部门，希望在中试阶段把产品质量问题解决掉，但中试的定位与运作也很困惑，发生质量与进度的冲突时，如何取舍与平衡，以前研发与制造的矛盾转化为研发与中试、中试与生产的矛盾，中试成了矛盾集散中心； 4.市场的压力并不因中试的产生而减少，中试需要从哪些方面努力才能满足产品的质量、进度的要求？中试的业务是面向研发还是面向制造，还是兼而有之？ 5.量产后才发现产品可制造性差、成品率低、经常返工，影响发货； 6.产品到了生产后还发生大量的设计变更； 7.产品到了客户手中还冒出各种各样的问题以致要研发人员到处去“救火”。。。。。。本课程将基于多年的实践、长期的研发咨询积累，总结出一套理论与实践相结合的可操作的方法，配以大量实际案例，以指导研发/试产/制造部门主管如何高效的实现产品从样品走向量产。　课程收益： 1.了解业界公司在不同发展阶段的产品中试管理模式与实践 2.掌握面向制造系统的产品设计（DFM）的方法与实施过程 3.掌握面向生产测试的产品设计（DFT）的方法与实施过程 4.掌握面向制造系统的新产品验证的过程与方法 5.掌握在满足质量标准的前提下缩短产品试制周期的方法和技巧 6.了解如何建立从样品到量产的管理机制　导师简介：[Charles] 　　研发咨询品牌资深顾问　　INCOSE 国际系统工程师联合会会员　　16年的高科技企业从业背景，具有丰富的产品研发、新产品导入、工艺工程、售前与售后等领域的实践与管理经验。曾在多家高科技企业中担任产品开发工程师（电子）、工艺工程师、售后服务工程师、项目经理、产品经理、设计工程部经理、工艺工程部经理、新产品导入部经理、技术管理部经理、企业管理顾问等职务；　　在某著名通信公司工作7年（97~03），期间长期与国际顶尖咨询顾问一起工作，全程参与推动该公司研发管理体系的变革工作，并成功主导了新产品导入平台的建设工作，作为产品经理主导了某产品线多个大型项目的产品研发工作。　研发管理咨询经验：　　从事研发管理咨询工作以来，作为项目总监成功的主持了格林威尔、广州威创日新、某电子科技集团研究所、国人通信等数十家企业的产品规划流程体系设计、试验局流程设计、知识管理体系设计、中试业务管理体系梳理、研发IT规划、研发项目管理体系设计、研发质量管理体系、研发绩效管理体系设计、研发KPI 体系设计等方面的管理咨询项目。　　　曾在各地多次举办研发质量管理、研发项目管理、新产品开发流程优化与管理、从样品走向量产等公开课，为数千家企业提供了研发管理公开课的培训，为数百家企业进行了研发管理的内训；从事研发管理咨询工作以来，作为项目总监成功的主持完成了数十个研发管理咨询项目体系的建设 <产品规划流程体系设计、试验局流程设计、知识管理体系设计、中试业务管理体系梳理、研发IT规划、研发项目管理体系设计、研发质量管理体系、研发绩效管理体系设计、研发KPI体系设计等方面>，有着丰富的研发管理咨询经验，涉及的行业包括通信、软件、家电、电信运营商、芯片、医疗器械、交通运输等，帮助这些企业建立高效、完备的研发管理体系，对中国企业研发管理体系及创新体制有着深刻的研究和理解，受到客户的高度评价。曾为科达通信、中电集团、TCL集团、威创、和记奥普泰、国人通信、京信科技、天碁科技、格林威尔、兴大豪科技、星星集团、山特电子、富港电子、宇龙通信、聚光科技、绿盟科技、天津内燃机研究所、同方威视、中集集团、高斯贝尔、星网锐捷、OPPO电子、特变电工、思源电器、海格客车、美的集团、国光电子、雷沃重汽、上汽五凌、东风汽车、威科姆、同洲电子、科立讯、新北洋、光迅科技、沈阳机床等近300家企业提供了专业的研发管理培训。　课程大纲：　一、案例研讨　二、从样品到量产概述 1.企业在追求什么：技术？样品？产品？商品？ 2.研发与制造的矛盾： 1）.制造系统如何面对研发的三无产品？ 2）.研发如何面对制造系统越来越高的门槛？ 3.研发与制造矛盾的激化：中试的产生成为必然 4.中试的定位与发展： 1）.研发（RD）、中试（D&P）、生产（P）的关系 2）.中试的使命是什么？ 3）.中试如何定位？ 4）.中试的发展问题： a 大而全？ b 专业化分工？ c 产品线划分与共享平台 d 中试人员的发展定位：广度与深度问题 5.中试的业务范围 1）.中试业务：新产品导入（NPI） 2）.承上：如何面向产品的研发？ 3）.启下：如何面向产品的制造？ 4）.桥梁：中试作为连接研发与制造的桥梁，独木桥还是阳关道？ 6.演练与问题讨论 1）.根据企业的实际情况，是否需要建立并发展中试的职能? 　三、新产品导入团队 1.新产品导入团队的构成 1）.工艺工程 2）.设备工程 3）.测试工程 4）.工业工程 5）.产品验证 6）.试生产（计划、生产、质量） 2.新产品导入团队的职责 3.新产品导入团队与产品开发团队的关系 1）.开发模式的演变：串行变并行 2）.并行工程在产品开发中如何体现？ 3）.新产品导入团队如何提前介入研发？ a 为什么要提前介入？ b 提前到什么时候介入？ c 提前介入做什么？ 4）.新产品导入团队的管理 a 新产品导入团队与产品开发团队、职能部门的沟通 b 新产品导入团队成员的汇报、考核和管理机制 4.演练与问题讨论 1）.根据企业的实际情况，研讨建立新产品导入团队的时机　四、面向制造系统的产品设计（DFM） 1.如何在产品设计与开发过程中进行可制造性设计 1）.从制造的角度来看产品设计 2）.工艺人员介入产品开发过程的切入点：从立项就开始 3）.工艺管理的三个阶段：工艺设计、工艺调制与验证、工艺管制 4）.工艺设计： a 如何提出可制造性需求？ b 需要哪些典型的工艺规范？ c 可制造性需求如何落实到产品设计方案中？ d工艺设计与产品设计如何并行？ e 产品工艺流程设计 f 电装、整装、包装与物流的可制造性设计分析 g 如何确保可制造性需求在产品开发中已被实现？ h 工艺评审如何操作？ i 什么时候考虑工装？ j 如何在开发过程中同步输出工艺文件与生产操作指导文件 5）.工艺调制与验证 a 工艺验证的时机 b 工艺验证方案包括哪些内容？ c 如何实施工艺验证？ d 工艺验证报告的内容 e 如何推动工艺验证的问题解决？ f 研发人员如何配合新产品的工艺验证？ g 制造外包模式下的工艺如何验证？ 6）.工艺管制 a 工艺管制的困惑：救火何时是尽头？ b 工艺转产评审（标准、流程、责任） c 量产过程中的例行监控与异常管理 2.演练与问题讨论 1）.分析学员企业的工艺管理工作做到什么程度？存在哪些差距？ 3.工艺管理平台建设 1）.谁负责工艺平台的建设？ 2）.工艺委员会的产生：责任与运作模式 3）.如何进行工艺规划？ 4）.基础工艺研究与应用 5）.支撑工艺管理平台的四大规范： a 品质规范 b 设备规范 c 工艺规范 d 设计规划 6）.工艺管理部门如何推动DFM业务的开展？ 7）.工艺体系的组织构成、发展与演变 8）.工艺人员的培养与技能提升 4.演练与问题讨论 1）.分析学员企业的工艺平台建设工作做到什么程度？存在哪些差距？如何改进？　五、面向生产测试的产品设计（DFT） 1.基于产品生命周期全流程的测试策略 1）.研发测试（Alpha）、试验局测试（Beta）、生产测试 2.研发测试（Alpha）与BETA测试 1）.测试人员介入产品开发过程的时机（提可测试性需求的时机） 2）.可测试性需求需要考虑的内容（示例） 3）.单元测试、模块测试、系统集成测试、专业化测试、BETA测试的重点分析 4）.产品开发过程中测试业务流程分析 5）.企业在不同的发展阶段如何开展测试的相关工作（短平快的项目测试工作如何开展） 3.面向生产测试业务的产品设计与开发 1）.生产测试业务流程分析 2）.典型的部品测试、整机测试方法介绍 3）.开发专门的生产测试工装的条件分析 4）.生产测试工装的开发管理 5）.在产品开发过程中如何实施面向生产测试的产品设计？ a 如何提出可测试性需求？ b 可测试性需求如何落实到产品设计方案中？ c 研发面对众多的需求如何取舍？可测试性需求的优先级分析 d 如何在产品开发过程中同步开发生产测试工装？ e 如何在产品开发过程中同步输出生产测试所需的操作指导文件？ f 如何进行测试工装的验证？ g 如何推动测试验证问题的解决？ 6）.如何推动可测试性设计（DFT）业务的开展 7）.如何进行测试平台的建设？ 4.演练与问题讨论 1）.分析学员企业的DFT工作做到什么程度？存在哪些差距？如何改进？　六、产品试制验证管理 1.影响产品试制周期的因素分析 2.研发人员对试制准备提供的支持 3.试制团队的构成、职责与定位（设置试制部门的时机与优缺点分析） 4.试制人员介入产品开发过程的时机 1）.如何进行试制准备（准备要素示例） 5.面向制造系统的验证 1）.研发人员如何在试制过程中进行产品设计的优化 2）.制造系统的验证策略与计划 3）.制造系统的验证方案 4）.如何实施制造系统的验证： a 工艺验证（工艺流程、工艺路线、单板工艺、整机工艺、包装工艺、物流工艺） b 工装验证（装配工装、测试工装、生产设备） c 结构验证 d 产品数据验证（BOM验证、制造文档验证） e 产品试制验证（质量、效率、成本） 5）.批次验证报告，验证多少批才合适？ 6）.如何推动验证问题的解决？ 6.转产评审 1）.研发人员如何支持新产品的转产工作 2）.转产评审的评审组织如何构成？ 3）.评审标准是什么？ 4）.如何判定是否转产？ 5）.评审流程与运作机制 7.产品转产后的管理 1）.新产品的试制效果评价 2）.新产品的质量目标达成情况 3）.工程变更管理 4）.缺陷与问题管理 5）.质量审计 8.演练与问题讨论 1）.分析学员企业的产品试制验证过程，分析差距，提出改进建议。　七、总结　本课程可针对企业需求，上门服务，组织内训，欢迎咨询。　

1 0

领导力与执行力强化
by lgk＠xrjlcrojo.net 10 Sep '13

10 Sep '13

　从技术走向管理——研发经理的领导力与执行力 ======================================================================================　培训时间：2013年9月22-23日深圳、9月25-26日北京、9月28-29日上海培训对象：企业CEO/总经理、研发总经理/副总、公司总工/ 技术总监、研发项目经理/产品经理、中试部经理、研发质量部经理、PMO（项目管理办公室）主任、管理岗位的技术人员培训费用：2800元/1人| 4300元/2人（含资料费、午餐、茶点、发票等) 　热线电话：400-633-0030 深圳/市场部：0755-61282649 刘小姐上海/市场部：021-31200290 金小姐　课程背景：　根据我们多年从事研发管理咨询的经验发现中国企业95% 以上的研发中基层主管都是从技术能力比较强的工程师中提拔起来的: 很多刚刚走上管理岗位的研发人员角色不能转换，过度关注技术细节；认真帮助下属可是他们并不买账；凡事亲力亲为，忙得焦头烂额，可是上司却嫌效率太低；希望下属多提意见，可是他们却什么都不说，不愿意承担责任；上司让制定工作计划，可却无从下手；不知道如何分派工作，如何领导团队，更不知道如何确保你的团队不出差错致使疲惫不堪却还不能有效达到整体目标。从一名只对技术负责的技术人员转变为对全流程负责的项目经理和对某一专业领域负责的部门经理，在这个转变的过程中，技术人员要实现哪些蜕变、要掌握哪些管理技能、如何培养自己的领导力等是本课程重点探讨的内容。　课程收益： 1.分享讲师上百场研发管理培训的专业经验，通过现场的互动帮助学员理清走向管理的困惑 2.总结和分析技术人员从技术走向管理过程中常见的问题 3.掌握实现从技术走向管理的过程中要实现的几个转变 4.了解从技术走向管理的五个好习惯（结果导向、综观全局、聚焦重点、发挥优势、集思广益） 5.掌握与领导沟通的方法技巧 6.掌握走上管理工作岗位后需要掌握的四个核心管理技能（目标与计划、组织与分派工作、控制与纠偏、领导与激励） 7.了解成功实现从技术走向管理转变的几个关键要素 8.分享讲师数十个咨询项目的研发管理的案例资料（模板、表格、样例…），帮助学员制定Action Plan，使得学员参训后回到自己的公司能够很好实践　导师简介：[Giles] -- 国际系统工程师联合会会员 ■专业背景：十几年高科技行业从业背景，丰富的研发管理咨询经验，在国内某大型知名企业工作近10年，主持和参与过多个大型产品的研发工作，先后担任过开发工程师、项目经理、产品经理、新产品导入部总监、研发项目管理部总监等职位。在任研发项目管理总监期间，成功组织建立了适合当时情况的研发流程管理、项目管理、技术管理体系。并作为核心组成员全程参与了集成产品开发变革项目，与IBM顶尖咨询顾问一起工作了四年. 全面负责了集成产品开发管理变革项目在某产品线的具体流程落地和推行工作，对整个管理变革项目的成功起到了至关重要的作用。后又与IBM顾问合作,成功主导了功能领域能力提升项目――新产品导入流程与平台的建设；在国内某大型知名企业工作期间，经历了该公司研发管理从不规范到规范化的整个过程，熟练掌握将国际先进的研发管理经验与中国企业实际情况相结合来构建研发管理体系的方法。后应某知名通讯公司的邀请，以顾问的身份进入该公司的技术中心主导研发管理体系、研发IT规划,MARKETI NG管理体系的平台建设工作。　 ■研发管理咨询经验从事研发管理咨询工作以来，作为项目总监成功的主持了格林威尔、广州威创日新、某电子科技集团研究所、国人通信等数十家企业的产品规划流程体系设计、试验局流程设计、知识管理体系设计、中试业务管理体系梳理、研发IT规划、研发项目管理体系设计、研发质量管理体系、研发绩效管理体系设计、研发KP I体系设计等方面的管理咨询项目。　 ■研发管理培训经验：曾在各地多次举办研发质量管理、研发项目管理、新产品开发流程优化与管理、从样品走向量产等公开课，为数千家企业提供了研发管理公开课的培训，为数百家企业进行了研发管理的内训；从事研发管理咨询工作以来，作为项目总监成功的主持完成了数十个研发管理咨询项目体系的建设，产品规划流程体系设计、试验局流程，设计知识管理体系设计、中试业务管理体系梳理、研发IT规划、研发项目管理体系设计、研发质量管理体系、研发绩效管理体系设计、研发KPI体系设计等方面>，有着丰富的研发管理咨询经验，涉及的行业包括通信、软件、家电、电信运营商、芯片、医疗器械、交通运输等，帮助这些企业建立高效、完备的研发管理体系，对中国企业研发管理体系及创新体制有着深刻的研究和理解，受到客户的高度评价。　课程大纲：一、案例分析（0.5） 1)讨论：技术走向管理的烦恼　二、从技术走向管理的角色定位和角色转换（1.5） 1)为什么要从技术走向管理（背景、原因） 2)技术人员的角色定位和素质模型 3)管理人员的角色定位和素质模型 4)技术型管理者的角色与核心工作（技术管理者的不是说不要技术，而是层次越高的技术管理者，越需要技术广度、技术敏锐度与市场敏锐度，而且更需要沟通、管理与领导技能） 5)技术人员与管理人员的特质 6)研发人员的特点 7)角色转换过程中常见的问题分析 8）角色转换的成长之路（角色、态度、知识、技能） 9）演练与问题讨论　三、从技术走向管理必备的好习惯（3.5） 1)习惯的价值与培养 2)习惯与原则 3)习惯之一：成果导向 4)习惯之二：综观全局 5)习惯之三：聚焦重点 6)习惯之四：发挥优势 7)习惯之五：集思广益　四、研发管理者如何与领导沟通（1.5） 1)研发管理者自己沟通能力不强而领导又不懂技术怎么办？ 2)为什么研发工作自己觉得开展的很好却得不到老板或领导的认可？ 3)与领导沟通的重要性 4)无数“革命先烈”的教训分享 5)领导的沟通类型 6)领导的沟通类型对沟通的影响 7)与领导沟通的难题（尤其是没有技术背景的领导） 8)与领导沟通的要点 9)高层领导喜欢的沟通方式 10)与领导沟通的方式、方法与技巧 11)与领导沟通谨慎换位思考 12)向领导汇报方式和工具 13)汇报会上领导常问的问题分类 14)为什么领导在会上总是不断追着问？ 15)高层管理者对研发的沟通信息需求（开发状况、资源状况、管理优化状况）详细介绍和模板演示 16)分辨领导的真正需求 17)要想成功从技术走向管理首先做个成功的下属 18)如何做个成功的下属 19)研讨：学习本单元的体会列出以后改进的三个要点　五、从技术走向管理的四个核心管理技能之一：目标与计划（1.0） 1)目标对我们的影响 2)个人目标和团队目标的关系 3)如何根据公司的战略要求制定研发部门和研发项目的目标 4)研发部门和项目的目标如何分解到个人 5)如何帮助下属制定工作目标 6)目标的制定与下达（SMART化、愿景化、共享化、承诺化（PBC）） 7)研发项目的目标为什么不容易SMART 8)为什么培训了很多次SMART研发项目目标还是做不到SMART 9)研发工作计划的PDCA循环 10)产品平台规划、产品路标规划和产品计划、版本计划、特性计划之间的关系 11)研发流程与计划的关系 12)研发项目计划制定的流程 13)PERT、关键路径和GANNT 14)为什么研发项目计划不用PERT图 15)产品开发计划如何分成四级（这四级计划的责任主体和制定时间点） 16)研发计划与资源计划的管理 17)资源计划指导书举例 18)资源实施对开发进度的影响 19)演练：每个小组制定一个半年计划，发表！　六、从技术走向管理的四个核心管理技能之二：组织与分派工作（2.0） 1)常见研发组织形式及优缺点 2)如何对研发工作进行分解 3)给研发人员分派工作的原则 4)给研发人员分派工作的步骤 5)给研发人员分派工作中容易出现的问题 6)研发沟通管理的内容 7)沟通的目的与功能 8)沟通的种类与方式 9)有效沟通的障碍/约哈里窗 10)面对面沟通避免的小动作 11)如何给其它部门分派研发工作 12)研发执行力缺失的原因分析 13)研发管理人员在分派工作中容易存在的问题、原因和克服 14)给研发技术人员创造愿景、描绘愿景，尤其是关于项目与团队前途 15)目标共享与任务分配（目标的共享化、目标的承诺化、目标的系统化、任务分配的原则、分配时的抗拒处理、分配时的控制紧度、分配后的跟踪与控制、结果反馈） 16)给研发技术人员空间（猴子管理、授权的五个原则、共享与参与管理） 17)活动演练 30 分钟：扑克游戏——上中下三层互动（体验：管理对人与对事，三层角色定位，目标下达，控制与跟踪，愿景与目标共享，结果反馈等） 18)案例研讨：研发技术型团队的成员常被迫承担紧急的项目周期，该如何处理？ 19)案例研讨：给予研发技术人员的空间到底多大，犯什么样的错误可以接受？ 20)案例研讨：任务下达后完成得不好但因为是碰到困难又怎么处理？ 21)案例研讨：一个人承担多个项目遇到资源冲突怎么办 22)案例研讨：两个领导意见不一致，怎么办？　七、从技术走向管理的四个核心管理技能之三：控制与纠偏（1.5） 1)研发工作为什么难以控制 2)研发工作的问题管理与风险管理 3)研发工作追踪的步骤 4)研发工作控制方法之一：会议（具体操作与模板） 5)研发工作控制方法之二：报告机制（具体操作与模板） 6)研发工作控制方法之三：审计（具体操作与模板） 7)研发工作控制方法之四：合同书与任务书（具体操作与模板） 8)研发工作控制方法之五：预警系统（具体操作与模板） 9)研发工作控制方法之六：经验教训总结（具体操作与模板） 10)研发工作控制方法之七：测评（具体操作与模板） 11)研发工作控制方法之八：非正规控制（具体操作与模板） 12)研发工作如何度量、量化管理（有哪些量化指标、PCB） 13)研发部门中的“因人而异”的管理方法 14)研发财经与成本管理的最佳实践 15)研发费用和成本的控制要点 16)贯穿开发全流程的研发费用跟踪和控制要点 17)研发费用管理的全流程 18)设计成本的管理方法——目标成本法及应用 19)产品生命周期成本的定义与沟通要素 20)如何控制产品生命周期成本 21)如何从财务和投资角度控制研发多项目资源 22)关于控制的误区（用人不疑、甩手掌柜、与创新的矛盾） 23)关于研发执行力　八、从技术走向管理的四个核心管理技能之四：领导与激励（2.0） 1)研发领导权威力的来源 2)研发领导如何发展个人魅力 3)如何针对不同环境和不同的研发人员进行情景领导 4)讨论：如何增进研发团队的凝聚力和士气 5)研发领导如何授权 6)研发领导如何辅导下属和培养接班人 7)研发人员的考核与激励（专题讲解） 8)建立功能型团队与项目型团队面向结果的绩效考核办法 9)研发技术型人才的培育与任职资格管理 10)研发技术型人才的非物质激励与物质激励方法 11)演练与讨论　九、成功实现从技术走向管理转变的关键（0.5） 1)成功的实现角色换位 2)管理技能的培养 3)个人修炼（习惯、领导力、沟通能力） 4)组织的融合和团队的打造 5)给刚走上管理岗位的技术人员推荐的书籍和电影本课程可针对企业需求，上门服务，组织内训，欢迎咨询。　

1 0

(PMC)生产与物控运作体系
by ac＠mhefeqjye.org 10 Sep '13

10 Sep '13

　　生产计划与物料控制PMC高级研修班 ======================================================================================　培训时间：2013年9月14-15日上海、10月26-27日深圳、培训对象：生产计划、物料计划、采购、生产、销售、物流、研发、PIE、IT... 培训费用：3600元/人（含资料费、午餐、茶点、发票等) 　热线电话：400-633-0030 深圳/市场部：0755-61282649 刘小姐上海/市场部：021-31200290 金小姐　课程背景：生产计划和物料控制（PMC）部门是一个企业“心脏”，掌握着企业生产及物料运作的总调度和命脉，统筹营运资金、物流、信息等动脉，直接涉及影响生产部、生产工程部、采购、货仓、品控部、开发与设计部、设备工程、人力资源及财务成本预算控制等，其制度和流程决定公司盈利成败.因此PMC部门和相关管理层必须充分了解：物料计划、请购、物料调度、物料控制（收、发、退、借、备料等）、生产计划与生产进度控制，并谙熟运用这门管理技术来解决问题，学习拉动计划价值流（VSM）图，从拉动计划价值流切入剖析工厂制造成本和缩短制造周期，提高物流过程循环效率（库存、资金的周转率）及客户满意率；为降低或消除物流过程中的非增值活动。　课程目标： 1、建立制定完善的生产与物控运作体系?提升准时交货和降低库存成本 2、预测及制定合理的短、中、长期销售计划?达成公司策略管理目标 3、对自身的生产能力负荷预先进行详细分析并建立完善产品数据机制协助公司建立产品工程数据 4、生产前期做好完整的生产排程和周生产计划?——?提高备料准确率，保持生产顺畅 5、配合生产计划做到良好物料损耗控制和备料?——?完善降低物料损耗机制和停工待料工时 6、对生产进度及物料进度及时跟进和沟通协调?——?缩短生产周期，提高企业竞争力　课程风格： “60/40”时间原则(学员40%，讲师60%)、小组讨论/发表、管理电影分享/ 研讨、案例分析、情景仿真、自带企业资料现场诊断和实作对策、游戏分享、学员与学员、讲师互动相辅而成、少讲理论多讲实践经验，要求学员课堂结合本公司实际情况量身订做提出问题（可在课堂打断讲师思路），不是纯粹填鸭灌输，也不是研究客观案例.而是让学员体验执行过程，关注现实事例. 面对面向老师提出公司问题，老师需要提成解决问题措施/方案.请同学先在公司开会收集问题.带问题来，带方案走。　导师简介：[雷卫旭] 不是职业培训师，而是在职执行管理者+富有实践经验培训师+公司负责人香港理工大学MBA，香港生产力促进局特约讲师、美国管理学会(AMA)授权专业培训师、清华大学/北京大学/上海交大/中山大学 EMBA班特邀实战型讲师，2005/2006/2007/2008/2009年被培训论坛推誉为“ 十大实战派培训师”、专业课程讲授专家、资深顾问。曽任某大型日港合资企业副总经理，拥有二十年的生产/物料采购管理经验. 讲授经验非常丰富，讲授/辅导过5632家中外企业(至2009底)、融集欧美.中、港、台多家企业经验之精华。并由北京大学出版《如何做好生产/物料采购计划控制》系列丛书和时代光华出版光碟，特别是200 5/2006/2007年间辅导顺德美的集团/ 富士康供应链管理项目,讲解深入浅出或浅入深出，不仅案例丰富，且提供多种实用的解决问题之工具及技巧。　至今有六万七仟以上人次接受专业课程训练，务实作风深受厂家好评如潮。　课程大纲：第一室:销售计划/生产计划/物料计划协调接口管理 1．销售计划/生产计划角色和定位---订单总导演／总指挥 2．销售计划/生产计划/物料计划先进组织架构 ◆东莞诺基亚公司销售计划/生产计划/物料计划组织架构 3．生产计划/物料控制五大职能----欠料分析跟进／备料功能/呆料预防--处理 4．生产计划与销售业务链接流程 ◆准时生产计划VS市场业务部VS客户“三赢”规则 ◆中兴通讯销售计划/生产计划/物料计划接口职能图/资源图实例分析 ◆美的滚动周计划负荷分析和三天生产计划不能变职能图 ◆控制扦单、急单、补单/加单五种措施--某公司 ◆通过市场调查/信息反馈提高订单预测准确率三大做法 5．销售预测与主生产计划（MPS）与月/周生产计划/物料计划（MRP）链接流程--ordermanagemen ◆销售预测/生产计划变化反馈和预测库存控制协调-- 销售预测微调制度化降低预测库存成本原理分析 ◆销售计划流程――销售预测流程／销售计划流程／备货计划流程／生产计划流程 6．制造业生产计划控制三种模式――预期滚动计划系统／推进式生产控制系统／拉动式生产控制系统 ◆世界五百强企业.施耐德电气Schneider新产品推进式生产控制系统 7．同一产品不同物流策略决定不同五大计划（销售/生产/物料/采购计/库存计划） ◆华为计划管理手册分析　第二室销售计划/生产计划控制流程---ordermanagement （包括项目计划） 1．销售预测计划/主生产计划（MPS）与月/周生产计划控制流程七途径-- 讲师/学员点评某公司现场诊断 ◆提升编制销售预测计划编制准确性六大步骤 ◆华润集团销售预测计划编制六大步骤实例分析 ◆青岛海尔新产品项目计划总体方案控制流程实例分析--ordermanagement ◆西门子月/周/项目计划时间节点协调流程分析 ◆富士康SAP系统主生产计划流程案例---ordermanagement ◆大金空调计划控制流程ERP-ORACLE系统主界面实例分析 ◆青岛海尔月/周/日项目计划协调流程实例分析 ◆富士康集团（台湾）公司月度滚动产能负荷分析/ 三天生产计划不能变的滚动产能负荷分析实例分析 2．透过准时化生产机制解决订单频繁变更三种方法--Productionplanchangemanagement ◆顺德美的日用集团扦单、急单、补单/加单/生产计划紧急控制流程实例分析 ◆飞利浦扦单/急单计划紧急控制流程案例分析-Productionplanchangemanagement ◆飞利浦生产查询界面/生产删改信息查询界面/产品工艺流程查询界面/产品作业报表查询界面实例解析 3．生产计划控制管理(精益)模式---均衡化/柔性化拉动计划 ◆准时化/均衡化生产方式(JIT)运用方法四大独特之处 ◆准时化生产方式---柔性化与同步化与均衡化 ◆某法国著名企业（拉动）一周生产计划不能变控制流程实例分析（现场超市双箱广告牌拉动） ◆某公司拉动式生产计划控制流程实物图片系列分析 ◆准时化生产方式双广告牌管理的基本原理解析 ◆杭州博世（BOSCH）均衡化（拉动）一周生产计划板不能变（生产广告牌）实例图片及说明分析 ◆苏州某汽车配件公司三天均衡化生产计划板（生产广告牌）图片及说明分析 ◆在线半成品KANBAN计算 ◆负荷瓶颈库存量设定方法 ◆飞利浦负荷瓶颈库存量设定实例—离散型生产模式　第三室生产计划进度控制----deliverymanagement 1．缩短产品周期流程--leadtimereduction ◆西门子产品周期缩短流程价值流案例分享 ◆某公司缩短产品周期电脑系统（用友）流程主界面实例分析 2．月/周生产计划产能连续滚动负荷分析制度化 ◆中国某著名公司月度主排产计划制定十三依据 ◆中国某著名公司三天生产计划依据制定九依据 3．月/周生产计划排程表制定与执行重点演练-- 上海某公司五张订单月/周生产计划排程表制定个案演练 4．分析产能负荷七要素方面---人力负荷/机器负荷-- ◆广州某公司2007/04月产能负荷分析会实录文件 5．生产进度监控三个阶段------事前/事中/事后（1）如何统计分析生产数据（2）通过生产数据采集计算机系统图监控计划与进度---东莞某集团公司 6．协调沟通处理生产异常问题---八条改善措施（NCRgoodsmanagement）/跨部门生产进度控制七步骤 7．飞利浦各部门异常工时/各部门产能损失图案例分析----生产能力效率表/综合效率分析----事后管理　第四室物流计划跟进与存量管制 ◆物流计划流程七步骤----某公司学员现场诊断(学员与讲师互动点评) ◆扦单、急单、补单/加单/生产计划紧急update物料计划流程解析 ◆上海西门子ERP—SAP/R3系统RUN-MRP流程主界面分析 ◆北京某公司NormalOrder/CONSIGNMENT/VMI/JIT/BufferControl 四种采购工作流程 1．供货商交期管制十大之道--leadtimereduction ◆伟创力（Flextronics）在物料欠料分析表实例分析 ◆物料短缺八大原因和七种预防对策 2．物料管理相辅相成十四流程--warehousemanagement 物料管理精髓三个盲点和八大死穴--― 伟创力美资公司呆料预防／处理制度实例/工程更改流程分析 ◆美的/一汽马自达公司/精工集团（日资）补料/损耗控制案例分析--降低内循环成本 3．最新先进物流管理(精益)流程模式 ◆物料管理---JIT三Ａ政策六措施 ◆深圳某著名台资企业（雷卫旭辅导）JIT供货推行十二步骤计划表实例解析（1）内部物流配送管理流程解析--Internallogisticmanagement ◆格力空调JIT物料操作指导书解析--warehousemanagement ◆博世（BOSCH）现场利用电子标签发料实例分析 ◆在线补充物料(RIP)KANBAN计算 ◆物料补充时间间隔计算 ◆在线物料标识及KANBAN卡设计 ◆博世配送系统物料广告牌实物/图片实例分析 ◆华晨宝马现场超市广告牌请购图片实例分析 ◆ABB/AREVA现场超市双箱广告牌请购图片实例分析（2）外部供应物流配送管理流程解析 ◆通用汽车JIT供应商物流评审标准解析（SQE） ◆供应商管理库存（VMI）-某著名企业VMI协议实录分析 ◆华强三洋供应商驻厂代表配送/退料/换料广告牌实物图片实例分析/集货配送（Milk-Run）管理方法 ◆供应商JIT直送工位管理方法/ ◆使用条形码及与供货商进行电子数据交换(EDI)实例展示4存量管制--inventorymanagement ◆需求预测、物料计划与库存控制原理/四大策略 ◆青岛海尔公司需求预测变化和库存相应调整控制流程实例 ◆长虹采购订单模式实例分析----大陆标准/通用物料采购/海外leantime长物料采购 ◆安全存量VS最高存量VS.最低存量定义 ◆安全存量三种设定方法 ◆ABC控制法--warehousemanagement ◆长周期采购批量、库存控制与销售预测的量变关系 ◆库存量降低五大方法 ◆库存周转率定量计算 ◆提高库存周转率的途径 ◆深圳某实业有限公司物料周转速度/周转率/存料率实例 ◆透过现场诊断,运用六种存量管制模式设置恰当库存管理方法（MTO/ROP/MOQ）降低外循环成本实例分析　尾声：当头棒喝—捅破窗纸 1．结合公司实际情况通过学员体会分享 2．讲师点评 3．实践/活用所学五步本课程可针对企业需求，上门服务，组织内训，欢迎咨询。　

1 0