Engineering bills are different from Planning or Manufacturing bills. In my post on “The Product Definition Challenge”, I asserted the interdependencies of various BOM’s and also the common types you find in an enterprise. I also wrote about “product decomposition” and “bom-lets”, i.e. the assemblies that are aggregated in ’super structures’. Super structures are different product representations and provide product context for the various integrated product teams (see my post on this topic in Collaboration). Super structures ’should’ be the ’system engineering’ oriented view of the product.

Having worked with several companies I came across different patterns preparing the cPDM implementation for it to exchange bills with ERP. It is not the technological trick… rather understanding the business rational. Key in ‘understanding’ what it is that is exchanged we first need to review the commercial ‘product positioning strategies’ that companies operate and the ‘product definitions’ in support of these models.

The illustration below is an overview of these models.

Product Positioning Models

1.    An Engineer(ed)-to-Order (ETO) product, in its core the product is a technical ‘template’. The product has proven itself in some form and such there is demand for this product. In the ‘old’ days there would be a set of master blue prints of the product concept. Let’s take a nuclear submarine or power plant example. The product concept exists, ‘template’ designs are available. Safety certification takes place while in production, at final assembly and at delivery. The configured end-product requires substantial engineering effort. Much effort goes into interfaces between systems, models, assemblies and components. Re-use of ‘components’ is of major benefit given that historical analysis says that only 20% of the components of a product are really new. Engineering one or a small series makes a substantial difference as the ‘template’ may server different customer orders. Design in WIP and its ‘improvements’ ripple through all the products that are in production WIP and this is a major configuration challenge.

Clients enter into a contract with an ‘OEM’. Public and large (semi) private institutions are typical customers. The processes are ‘contract’ and usually project driven. The focus is on full lifecycle support, product conformance, production efficiency and WIP management.

2.    In a Make-to-Order (MTO) (also Build-to-Order) situation, the ‘design’ of the product and production processes is ‘ready’ (and maintained) for ’serial’ production. Typically the product may have obtained some form of ‘type’ approval regarding safety. As a business policy a company may define a base (stable) product with several categories of stable, reusable and maintained modular options. Yet some level of engineering may be needed and to accommodate for specific client requirements some portion of the product can be Engineered-to-Order.

Improvements are ‘blocked’ and changes are ‘batched’ and ripple through in a very controlled manner. Some category of changes are scheduled for new orders while other must be incorporated in production WIP and products in the field. Improvements may include categories of technical and cost optimizations. Interchangeability is model and configuration specific. Aircraft are examples of this strategy model and product type.

Subject to the go-to-market concept the enterprise would have for example a 50-60% standard base product, 20-30% standard options, and maybe 10-20% custom options. This kind of division is the base for sales, engineering and material management efficiency. Most processes are contract and/or order driven. All possible configurations are technically fully certified at product launch, including production and supply chain processes. There is a degree of similarity with ETO and ATO. The focus is on full lifecycle support, product reliability and production efficiency.

3.    An Assembled-to-Order (ATO) product is in fact a variant of MTO with the exception that as a principle no custom engineering effort is required, the product is ‘ready’ to produce to client order. Some modules are forecast and may already be in stock, while others may be ordered ‘just-in-time’. Improvements are ‘batched’ and may be introduced in the next product model. Improvements are typically market driven and may include categories of technical and cost optimizations while assuring full interchangeability. Autos, rolling stock or computers may be in this category. All possible configurations are technically fully ‘proofed’ before product launch, including the production and supply chain processes. The focus is aftermarket support, consistent quality, reliability and production efficiency.

4.    The last product positioning strategy is Pick-to-Order (PTO). Here a completely assembled end product of a limited number of configurations is ordered. PTO is a variant to ATO in as much that the final configuration is forecast as a Make-to-Stock. Change and Improvement management follows a similar process to ATO. Interchangeability may be less of a topic as, like-for-like (commodities) will be replaced in the field and in some cases the product may not be serviced rather disposed of completely at the end of its useful life. Consumer products (and also computers) are examples of PTO. The engineering process is (cost) improvement and (flow line) production processes are market demand driven. All end products are technically fully ‘proofed’ before product launch, including the production and supply chain processes. The focus is on consistent quality and production efficiency.

Note: Literature may call different names for these product positioning strategies.

Considering these four scenarios you appreciate that the resulting forms of ERP coexistence differ.

So let’s put the above in the context of PLM and ERP. In ERP there are two types of bills, the ‘generic/master’ planning and the ‘derived’ order specific. In PLM you basically have the same, the ‘generic product structure’ (GPS), an approach that comprises modules and incorporates all targeted design variants, and a derived ‘end item’ specific configuration. It may not be a product ‘platform’ or ‘family’ definition as a transition to a ‘variant’ master structure may be required. Product Engineering assures that different combinations of module options technically fit together as defined by ‘rules’. The same goes for the manufacturing engineers, this discipline assures that the ‘master’ planning follows this modular approach and from the master planning a specific order bill can be configured.  The following illustration explains some of the principles. I listened to many expert opinions and this is basically what can be considered the common denominator.

In this illustration I also included the end ‘ state’ of the product i.e. the As-Built and the As-Delivered as well as the As-Serviced/As-Maintained. The observant reader will realize that this As-Serviced definition is not based on the produced product as this does not define item positions and their maintainability aspects, critical in ETO and MTO. Also appreciate where product configurators may be utilized. You appreciate that engineers working on a ‘total’ product structure (all variations) cannot do without such ‘configurator’ function. How would you suppress undesirable components from being loaded into the 3D-model or mock-up when you are just interested in a specific configuration you are working on. This is probably worth another post… (see also my post on Digital Mock-up).

Notionally the ERP ‘master’ production planning bill is the super structure of the production build sequence. From this master build sequence, order specific final assembly bills can be defined. The build sequence will have a related bill of routing (BOR). Although this name is not consistent throughout the industry, e.g according to APICS it is bill of operations (BOO). There will further be a component manufacture, (sub)assembly and a final assembly BOR’s. Different from the Engineering/Manufacturing super structure, the BOR definition is the decomposition of the production build sequence with detailed operations and manufacturing steps.

The above illustration is notional, I do not pretend it to be complete.

‘Operations and steps’ define work instructions and ‘resources’ needed at each step. At these steps assembly/sub-assembly bom-lets are ‘consumed’ from the bottom up during the (final) assembly process of the end product. The BOR ‘consumes’  the Engineering defined (sub) Assemblies. I referred to these in other posts as ‘bom-lets’. Considering these constructs, the BOR is not a BOM… rather a ‘process’ structure and has a association with the Manufacturing BOM. There have been several publications concerned with ‘fusion’ of MBOM and BOR (BOMO). Purposely I have been vague how these are fused as there would be several solutions. I would like to assert that when done right you would not need an MBOM as the BOR describes the MBOM build sequence. Unfortunately, today’s PLM and ERP technology still requires both a MBOM and BOR, and are maintained separated. A joint definition would bring significant benefits. For example the BOR constructs can be defined within the MBOM and a BOR filter would suppress these constructs for those who would not need to work with them. This approach would then also support routing variability and overall, it would make maintenance, synchronisation and reconciliation with the EBOM more auditable, secure and easy.

Defining the BOR involves several Production Engineering specialists: Those responsible for the:

• The build sequence work breakdown structure
• The ‘line’ equipment and other resources
• Required tooling, but also the numerical control programs and information for machining centers and robots
• The production method consuming assembly, sub-assembly, component and (raw)material level
• The Assembly work instructions
• The Component production work instructions
• Standards and Norms (documents) that control quality at the process and its steps
• The quality assurance in all its aspects, including discrepancy and corrective action register(s).

The BOR can be defined in either the PLM or ERP domain. The trend is for PLM, the reason being that engineers today need to have access to a lot of critical design information. The authoring capability in PLM is usually referred to as a digital manufacturing solution (computer aided process planning (CAPP)). The strength of CAPP is that it essentially keeps all of the above elements ‘together’ as a single source of manufacturing information in the context of the (configured) product including the Production and Manufacturing Information (PMI) source that may be stored in for example JT. This lightweight 3D experience is dependent on the 3D-model and the trend is that it obsoletes 2D drawings. PMI typically stores dimensions, dimensional tolerances, position tolerances and surface finish. This is also a strong case in favor of CAPP in PLM.

Returning to our main topic: ERP, among other things, depends on a master bill from which order bills are derived to determine ‘material’ requirements. I came across some ETO and MTO product positioning model companies that prepare and simulate this ‘master’ WBS (Planning bill) in Microsoft Project prior to entering in ERP.

In ETO this Planning Bill and BOR typically is a one-off effort as each ‘end product’ order may be unique. If there is some form of a series, the end product can be considered a master definition and some companies use classical unit number effectivity to define an As-Built. The Planning bill follows the Systems Engineering decompositions defined by Product Engineering. Early alignment between these two disciplines reduces later synchronization effort.

MTO is a variant of ETO and ATO, with the key difference that a client configuration assembly bill for a specific order is configured by engineers. All of the configurable modules are pre-loaded in ERP from which an order specific final assembly bill can be configured with their corresponding ’standard’ routings.

The Manufacturing bill including the super structures and modules I talked about earlier are converted to suit manufacturing, and populated with the required bom-lets i.e. assemblies, sub-assemblies, components, (raw) materials. As you interface with ERP all of these bom-lets revisions are brought across and kept synced against the ‘master’ definition. Once brought across you then need to set revision (date) effectivities. That is the crux of interfacing PLM with ERP. Product Engineers negotiate with Manufacturing and Production Planning Engineers what bom-lets are transferred. If products are in production WIP you then need to determine in the Change Introduction Board (CIB) how these ‘mods’ are introduced into the order specific MBOM/BORs derived from the engineering master definition. This CIB together with a Change Review Board (CRB) are organizational entities in classic closed loop Change Management. The dispositioning of these mods is also the reason that it is absolutely critical for the PLM application to also exchange Change Notices to ERP and not just the changed BOMs themselves as I came across frequently while also leaving a paper change trail. Ignoring this (whatever the reason) makes reconciliation and the verification and validation very difficult, see earlier post in which I talk about the V-model.

A brief note again on As-Maintained BOM… (see illustration regarding the source). In Aerospace the manufacturing method and the work instructions are key sources regarding maintenance, repair and overhaul (MRO). This effectively applies to all ETO and MTO cases (Engineer-to-Maintain/Sustain) in which product sustainment and life cycle support scenarios are an important topic (see earlier posts on Enterprise Asset Management). Example; aircraft cannot be certified without this principle while it assures safe operation and reliability backed by periodical maintenance requirements and principles. All of the production methods and experience are key input to maintenance work cards. Considering that today, the assembly process can be digitally simulated, the same benefit goes for maintenance which is in effect the reverse order. The Build Sequence becomes the Disassembly order and this is also the background why there is Service BOM (see posts on Product Definitions).

In summary, Engineering owned System Engineering oriented super structures are the base for manufacturing bill and the bill of routing. This super structure is pushed from PLM into ERP. The MBOM/BOR is concerned how these super structures are assembled into end products. The MBOM/BOR is a ’standard’ or order specific routing depending on the product positioning model. The BOR consumes (sub)-assemblies as defined by product engineering against the super structures. Updates of (sub)-assemblies, components and (raw) materials are pushed into ERP subject to status. The CRB and CIB process determine what changes are introduced in the product and production WIP. Effectivity (date) is a critical function to schedule changes in and out.

PLM would be concerned with knowledge processes for design and manufacturing engineering, ERP would be concerned with production execution driving final assembly. Work instructions support the production process and are also the foundation for  MRO.

Considering the volume of information that is stored against the MBOM/BOR and also the critical collaboration required between ‘product’ engineering and ‘production process’ engineering, that in itself is a sound case to support these processes in PLM. A large ERP vendor also appreciates this as it recently acquired Visiprise well know for it digital manufacturing and execution suite.

I have worked with several client regarding the principles of change management. What I found was, all in different forms follow CMII principles however the DYNAMICS in which change is implemented into the product and the management process differ. They all operate the specific objects to record change, and also the ‘back-office’ organizations, such as the Change Control Board and some operate also a dedicated Change Introduction Board.

What do I mean with this ‘dynamics’. The change dynamics is the business rational how change introduction ripples through into the product and specifically aspects surrounding product sustainment i.e. sustainment being the process to maintain a product and secure save operation from an engineering perspective. There is a name for it emerging: Sustainment Lifecycle Management.

Not only is there sustainment to products already in the field, also with new product development (NPD) there is a form of ’sustainment’ on a micro level. When you read my post on Digital Mockup and the WIP, I stated that the DMU cannot be dynamically changed without impacting configuration management principles. In this post I discuss that there is also a ‘delay’ to decide which modifications are incorporated when. This is a formal process, you can consider this a form of sustainment during product development.

When you consider the development of a vehicle body and all of the cross functional team that are involved and the synchronization complexities, you then must coordinate the change moment with all partners. Also you need to consider that the car body development has the biggest program influence on time, cost and impact (consumer acceptance) to the market. Consider also the current difficulties with the Boeing 787 wing to fuselage connection design and the same applies to aircraft air frames.

Working with a developer/producer of military aircraft we discussed principles of change dynamics and to be frank, I have seen the same principles also in other industries. What I found; there are three approaches to change introduction, change driven by:

1. Improvements during development at IPT level (also cross functional teams, see also post on IPT in Collaboration)

2. Modifications after certain Design Reviews (gates) have taken place i.e. when substantial resources are needed and consumed to make corrections/improvements.

3. Improvements that will be introduced in newer versions/models of the product.

In scenario 1, changes are processed and incorporated by specialists. For the ‘record’ the ‘background’ to the change is recorded. As a generalization this is the ‘fast track’ principle of CMII.

In scenario 2, changes are processed and incorporated again by specialists, but the change introduction board decides when this takes place as (external) resources need to be planned and accounted for. For purposes of efficiency changes are collected and are ‘put on hold’, i.e. they will be batch processed according to e.g. priority and product zones. Subject to criticality changes may also be retrofitted to products in production. There can be conditions that these ‘mods’ need to be fitted to relevant products in the field, either mandatory or at owner choice.

In scenario 3, and last scenario; all mandatory changes and product improvements are ‘collected’ and retrofitted back into the original baseline and this now creates the baseline for a new ‘Mark #’ product, or the technical lessons learnt as a base for the next model upgrade. To manage change effective you need some additional capabilities.

Managing change Dynamic and the process behind this as I touched on in my intro, you appreciate that it is critical that Change Request and Notices are ‘collected’ i.e. a ‘record’ that a group or series of changes have been incorporated. In an object oriented engineering collaboration solution, Change objects have relations to the affected and resulting items. Change objects can be collected in a container object; ‘baseline’. The baseline will describe the purpose, for example the Platform/Model and the Review Gate (+iteration number). In an automotive context you would have complete overview of what changes were incorporated at any point in time and you could also compare one baseline with another. If costs would be collected against the Change object (for example the authorizing task as discussed in one of my post on Business Activity Management) a program manager would have complete overview and could easily report on costs and the increases caused addressing what technical issues.

The baseline further provides a different ‘view’ compared with classic unit effectivity; a key configuration management concept. To understand the extent of changes introduced; a great report would be what group of changes resulted in what new product state. Such report provides a ‘time’ based view regarding a product. It would also provide a concise view what engineering effort would be needed to ‘port’ improvements back into the new product base e.g. to creating the new Mark II or your new 2010 model. Further great insights would be gained from a comparison between a specific unit effectivity with the new Mark II baseline. This kind of comparison allows an OEM to plan specific field upgrade packages and would provide the ultimate lean Sustainment Lifecycle Management support.

Can you imagine the tremendous effect such reports would have on productivity gain and the risk you could reduce in case of service level agreements ’selling’ your product based on usage-by-the-hour.

In this post I would like to introduce an all embracing view regarding the purpose of a Digital Mockup or DMU. When you research the topic there are different opinions what a DMU is. It depends where you come from. The AutoVue’s view is that the DMU is the lightweight product representation derived from a 3D CAD model. If you are a vendor of 3D CAD, then DMU is the source product representation created with the CAD application. Wikipedia I believe is pretty close: Digital MockUp or DMU is a concept that allows the description of a product, usually in 3D…. although what is meant with ‘concept’.

A DMU is also a product configuration, consolidating other DMUs, such as structural details, purchased and standard items that are part of the construction in accordance with design specifications. Most publications state that a DMU is a mechanism to create a Digital prototype (or Virtual) and that a DMU allows engineers to design and configure products and validate designs without ‘ever needing’ to build a physical model… well the word ‘ever’ means; until you really need a prototype to for example test fly a plane.

So, a DMU is a 3D digital product representation. It represents the ‘real thing’ i.e. it is what engineers work on and ‘release’ to produce. It may comprise a derived and synchronized lightweight representation to support information consumers that do not have or need a native 3D CAD application or to exchange designs with an external party without having to worry about intellectual property. Although it is not the original 3D CAD application; still, it lets users visualize, animate, check dimensions and tolerances, manipulate, explode, fly through, cut away, and check clearance and interference of parts and assemblies… oh and lastly it is also the source for product documentation for example, part catalogs or product operating manual.

So this pretty well sums it up where we start from… the virtual prototype in 3D CAD that may have dependent representations.

Consulting with several clients in Automotive and Aerospace on the topic Digital Mockup and the purpose of it in the engineering process we talked about several topics and their challenges:

• Collaboration between an organization’s internal teams and external partners.
• Work-in-progress management and the establishment of (Allocated) Baselines.
• Managing different configurations, you may call these product platforms and its derived variants.
• The dynamics of updating, configuration management, design reviews against major schedule management Gates, etc.

Let me home in on each of them.

What I meant with this Collaboration topic is the sharing of the engineering task among teams within an enterprise but also with external partners. These external partners also use 3D CAD and in the extreme case not even the same version or even a different CAD vendor labels. With today’s technology you can overcome data exchange challenges, what remains is the collaboration principles and best practices.

Some of the companies I worked with, stressed the point that the fundamentals of the DMU are the same as with a physical prototype. You cannot just change and replace things. With each change you need to validate its fit for purpose. Also you need to baseline a configuration when you do your virtual tests and record what improvements you applied for your next baseline.

In Aerospace the configuration management plan typically calls for the role of a DMU manager. A person or entity that secures the state and status of the virtual product. This implies, and this is consistent with Automotive, that your Work in Progress, i.e. the engineering WIP, is conducted outside from what is contained in the DMU. Call it a WIP area. To receive into and to move completed work from the WIP back into the DMU is a formal process. Renault for example operates the so called DMDR process and corresponding gate review. DMDR stands for Digital Mockup and Design Review. DMU synchronization is a prerequisite for the gated design review.

To prepare for a ‘change’ to be worked on, any areas in the surrounding ‘assembly’ envelop you need to ‘check out’ or for example the work that you want submit to an ‘external’ party. Once changes are edited or additions are received, validated, verified and proofed you can ‘check in’ these items back into the DMU. Again this is a formal process as there could be several disciplines involved.

When engineering divides its work following a ’system’ product breakdown and also following a top-down design approach it would reduce team interference challenges. The WIP is what is being worked on i.e. the status working. Automotive is very successful working in this manner and this is proven by today’s relatively short car development cycles, see Wikipedia for car systems example at: http://tinyurl.com/nrawmk. (make sure you press the show button).

In addition to the WIP area there is also an DMZ collaboration area, i.e. the place to collaborate with external partners. Partners would upload contract deliverables here and also download the essential material from the OEM. See my post on Collaboration and the discussion surrounding Sharepoint. The vendor material uploaded would be received in the DMU WIP. Here the correctness and fit can be validated, the same as you would do with a physical prototype. Once all the procedures are completed the vendor material can be loaded into the DMU. In Aerospace these procedures basically is a certification, for insiders almost like a First Article Inspection or a kind of PPAP as with Automotive.

Continuing with the topic Managing Different Configurations, how can Engineering be effective if it does not have capabilities to set a specific Engineering context. It would mean an engineer would not be able to load a specific ‘view’ of the product. If working with a base platform that supports different models then you would not need to maintain different product definition copies for each model. You realize that a Engineering context capability would make the DMU WIP validation and verification more efficient.

Nearing the end of the post, the DMU and the ’system’ product decomposition would be driven from the Schedule Manager as can be found in my blog category Business Activity Management. So, the Schedule follows the same breakdown as your product. Each of the deliverables would be defined against the car systems example (see Wikipedia link). Many Automotive Automotive OEM still have a challenge to manage the various Design Review gates specifically collecting all the deliverables and freezing the DMU is THE challenge. A frozen DMU implies that certain financial commitments are made and budgets are released and this would mean that from this freezing point going forward all changes must follow a formal change process and each ‘check out’ into WIP can only be accomplished by a formal authorization.

So, with the DMU in a different context, you appreciate that it is more than just a 3D digital model of a product. The processes in support of the DMU are complex and challenging and must be thought through and planned for carefully. More companies are exploring DMU capabilities how it can used to bring bottom line value increasing engineering effectiveness overall.

Do you have challenges in this area and should you like to know more about these concepts and how this may apply to your operations, the About page has a form to contact us.

Having observed many projects I believe that there are four success attention categories. Change must:

1. Be customer focused
2. Enable corporate goals
3. Consider how current IT technology is/should be utilized (the good and the bad)
4. Be outcome driven such that the results can be measured by metrics and used to tweak improvements (continuous)

Considering these important criteria, how should companies drive a change management initiative. As a general observation many business leaders these days rush implementing cost saving and productivity increasing measures. Few are thinking about the (unintended) consequences that their initiatives will have on relationships with those most affected. Change management in any form are messages of what an organization believes to be critical and necessary to key stakeholders such as, employees, business partners and customers and those that have invested money in the business.

One of the biggest challenges to change is confidence from those that need to drive the change initiative, so you basically start with a challenge.
For implementing a defined change initiative, a very important group that must be mobilized is line management. After all, they are responsible for the results and be responsible to follow is through. They can hinder or accelerate, purposely or sometimes unintended. Implementing new, cost shaving technology or functions to bring your product to market faster; how were they involved (including subject matter experts) with the choice and also do they understand the critical success factors. The best supporters are your personnel that is passionate about the new plans they help to develop to generate these improvements. It makes them feel owner.

Making your personnel more passionate and to make them owner requires you to communicate what needs to be achieved. So, a Change Management charter is a key object for the whole team to ‘own’. What is it that we need to achieve, and even more important, how do we want to achieve this new state of improvement and or excellence. In my experience, too many times companies just jump-on-it to write a series of requirements without a comprehensive description of the overall goal and the background to the planned changes. In many cases I also found that the input from other groups were just missing.
With that goal, next steps are development of an understanding what the inhibitors or impediments are that work against the planned change. As pointed out previous, early involvement of critical personnel is key, so what is the best approach to start. Any change initiative, and now is the right moment to refer to this as a Business Process Improvement (BPI) initiative, is driven from the following three elements:

1. People (the groups, the disciplines, the roles)
2. Process (the processes, the interaction, the forms of collaboration)
3. Technology (the tools that are and should be utilized)

Considering this trio and to develop an understand how well this trio is integrated, I worked with companies to conducting assessments to defining the goals of this BPI. These assessments, I believe. are the corner stone for any change program. Customers experience such assessments critical to align company goals, needs, impediments, solutions and priorities. It will help to clearly define priorities: What makes sense doing first, what does an improvement bring relative to needed investments, what effort does it take and what are the risks. With this knowledge you can then start to select the technology and solution capabilities.

With the assessment as your baseline, you then look at your processes. So from the above 3 elements item 2); Process, is the center element. Your current processes are key, i.e. they should be documented, and you then link with People and Technology.
Typically Enterprise processes, i.e. your process maps, are documented at 4 levels. Level 1 is the overarching top level and you then drill down till level 3; the details. This 3-level detail should be income, outcome and/or results driven. It should document ‘lead’ indicators such as: Time, Quality, Cost, Customer, Satisfaction etc. It is my experience that Visio and Excel are great tools to start. If it gets a information management burden you can always switch to more advanced tools. Oh yes, and don’t forget requirements (bom of requirements) that you can link with each level of detail.
The deepest level 4 is the integration with the IT capabilities that your personnel use, i.e. the capabilities that support users and the specific actions needed using the capabilities. I recommended companies to use snippets of menu actions and screen input. Don’t under estimate the effort to get it right. The effort is not a waste as is can be reused to support development of corporate guides and training material and ultimately you can use it to support your internal Process Wiki knowledge base.

Getting to the end of this post, below is a list of (implementation) challenges I collected over the years. It also comprises aspects I talked about earlier. The identifier between square brackets T = Tangible [T], easy to measure the effect; without it, intangible, the more ’soft’ factor.

• Mindset and attitude (do stakeholders support/commit the initiative, do they have faith in the results)
• Excitement among those involved (is everybody on board)
• The culture (the ability and willingness to change)
• Underestimating the challenges (how risky is it to carry this through, what road blocks may lie ahead)
• The right resources (do we know what is needed) [T]
• The right methods to enable change (build on methods of earlier experience) [T]
• Wrong or incomplete start-up information (are the facts as they really are) [T]
• Lack of alignment with an organization’s needs and wants regarding processes and solution capabilities [T]
• Technological barriers (e.g. unproven paths) [T]

The About page has a form to contact us should you like to know more about these concepts and how this may apply to your operations.

Much of this ’stuff’ is developed under the umbrella of Web 2.0. It concerns the changing trends in the use of World Wide Web technology and web design, with the aim to enhance creativity, communication and secure information sharing. Web 2.0 concepts have led to the development and evolution of web culture communities and hosted services, such as social-networking sites, video sharing sites, wikis, blogs.

In a series of posts I’ll be writing about various functions and capabilities and how they may be used in a PLM context.

The technology basically provides an efficient user experience between the different applications and the place of storage of objects. This technology help stores our documents on file servers and directories without having to remember where. With collaboration technology and specifically SharePoint you can provide a ‘team site’ to these (user) locations. Also you can plugin certain web applications for example in the case of again SharePoint, these are so called web parts. These web parts provide for specific functions and capabilities and these days more PLM vendors bring out specific web parts associated with their solution capabilities/technology.

Web parts provide a complete work experience as critical information would be available in an application integrated manner. I would call such ‘user experience’ a workbench. An engineer starting his work in the morning would open his/her ‘engineering workbench’. In this workbench (s)he would find the files being worked on and also ‘messages’ of work others have been doing in which the person’s involvement is required. It may even include some level of work routing. Specifically I would not like to call this workflow, as the intent is basically routing of objects and does not represent an enterprise process. In a previous post I talked about Ideation, well this could be a set of capabilities in the workbench. Other functions may include fill out forms for objects such as problem reports or time sheets. There could also be a series of reports on the ‘home page’ for example project score cards i.e. the things that matter and that participants should be sensitive about.

SharePoint today also includes Blog and Wiki functions (see my follow up posts). So this workbench really would be the starting point of work-in-progress knowledge and  management. Having these core functions available at a single application and information point obviously brings substantial efficiencies. There is a large offering of collaboration software available these days and Wikipedia provides a comprehensive list. Not all are appropriate in an engineering context though, so an assessment regarding business needs and requirements should be a critical step prior to making choices for such solution.

Another company was struggling with the ever shorter product cycles (and need for faster innovation). Working with this company we realized that innovation to them meant to always using the same development approach and also understand the critical parameters that make-up the product. The same process meant the foundation for continuous improvement so we worked on the introduction of principles developed in other industries. We then developed and approach tagged as ‘house styles’. These house styles could be considered a series of templates that capture product platform ‘design rules’. In a previous post I talked about ‘front loading’, as a framework to comprise such house styles. House styles would be a combination of technical and organization rules. 1) Technical being the parameters that affect for example the product upscaling and corresponding output. 2) Organizational are rules how to drive the development forward from early concept, validation to production and delivery.

Two different situations, in the last case, as the stepping stone to the house styles, we recommended introduction of a Wiki as the foundation to capture tacit (the informal) knowledge. Basically it is to with digitization of the engineers ‘black note book’. The fact that our recommendation made sense is proven by the fact that more companies today use Wiki to ‘capture’ product and process knowledge. Engineers are encouraged to share their knowledge. That knowledge is stored against pre-created topics to provide an ‘knowledge structure’. Some Wiki using companies create incentives to this Wiki form of knowledge capture, as there may be reluctance for engineers to share it and also the fact that it would take effort from an engineer to write it down. In general one could argue rather than writing a reply to a question in an email, it makes more sense to first make an entry in a Wiki and then point to this instead. Knowledge reuse would be instant and creates double digit improved effectiveness and vast savings to avoid reinventing the wheel… and this is what knowledge capture is all about.

My observations: With an established (Twitter) name, people interested in your ‘messages’ will ‘follow’ you, i.e. they take a subscription on tweets that you post. You may have an announcement and this you can post with a link to an (tiny) url if there is an external source. Key challenge in an extranet Twitter, how get to get people interested to ‘follow’ you. In the Yammer (intranet) example, engineers may want to create a Yammer project group, for example the project for a new engine development. Such group will have a ‘moderator’ to controlling who should be member. All team/group members would ‘follow’ this project. The nice thing; … with a posted tweet you can instantly reach all project followers. It allows you to post a question, an announcement and then expect the social network principles to ‘instantly’ provide you with the answer or opinions you are hoping for. A mobility aspect and this based on personal experience tweets in Yammer, and at member’s choice, can be forwarded as text message to ‘company’ mobile devices or even to a Twitter client installed. So even while you are on the go you can still follow and submit specific project tweets. Having worked with many engineers over the years I believe that such functions are extremely useful and would increase the effectiveness of engineering tasks because you can post an instant question or notice to the team for example: What have we decided regarding…, Where can I find…, Be careful with… I am now working on…

Twitter type of functionality is not the same as IM because the IM intent is to provide conversational messaging to an individual and invitees whereas with Twitter you reach a group. If needed you can reply to the individual directly (including privately).
Finishing this post. This technology is developing with the speed of light. You see plug-ins emerging everywhere and I would be curious which PLM vendor would be first to support this trend its collaboration platform. For example in Twitter with specific tags you can ‘push’ post to Yammer… so from the extranet to the intranet…. or suppose you would create a part, and you want to consult the group, you would create a Twitter part number tag and replies would come back against the user and the part number tag. To create some last confusion, posts on Yammer are in fact still called tweets and not something like Yams