PLM Migration : Part 2

This is continuation of my previous blog on PLM Migration Part 1. In this blog I am going to discuss about other PLM migration consideration . On my previous blog we discuss about

·         What to Migrate

·         How to Migrate

·         Before you start

In this blog we will discuss in brief about remaining factors

·         Design Approach

·         CAD Migration

·         CAD vs Meta Data Migration

Design Approach:

Design of Migration required having better architect and validation mechanism. Also log and Report creation mechanism should be in place. Most of complex migration is done through ETL process mainly through staging data base where transformation, normalization and cleaning is done. Following point should be considered while doing Design through ETL process.

1)      Clean interface data load and Staging Table design should be defined. It is recommended to have separate table for input data and for transformation. This will help in better traceability and data validation.

2)      All exception related should be log in Error table and appropriate report should generated for further action on those exceptions. This will help in saving lot of time at upload stage since most of issue can be caught in transformation stage.

3)      Sequence of interdependent upload should be well defined and documented. Since in PLM is a complex web of interlink data the hierarchy of data dependency as well sequence data load is important to defined.

4)      If there is multi system migration then proper validation procedure should be written for integrity of data and its accuracy from different system

Typically following High Level flow involved in ETL migration.

1)      Extraction from legacy system.

a.       Meta Data Extraction

b.      Non CAD Files

c.       CAD extraction

2)      Load Meta data to staging

3)      Input data Validation

4)      Transformation

5)      Post Transfer Validation

6)      Staging Extraction for upload

7)      Data Upload.

a.       CAD Upload

b.      Metadata and Volume files Upload

It is important to do Design for sync of Metadata, File and CAD files upload. All three are interdependent on each other. For example CAD load will may required property like type, part number etc from staging for CAD upload.

CAD Migration:

CAD Migration is one of the difficult aspects of PLM migration. Usually CAD migration is usually done through third party tool which has CAD integration capability with the given system.  For example Siemens PLM provide UG NX tool like ug_export/ug_import and ug_clone for export/import CAD part from Teamcenter. These tools provide lot of configuration option for doing custom export/import to the PLM system. These types of tools are usually used for migrating CAD part by providing proper configuration file.

The most consideration for CAD migration is to understand modeling philosophy of organization like master model concept and inter part relation. For in NX you can create CAD model which are dependent on other part through expression or geometry. The above understanding is very important to define the process and sequence of CAD data. Following should be considered before deciding on CAD migration.

1)      Modeling concept used in Organization.

2)      Interdependent part relation in CAD model like expression, wave link, pattern, template etc in NX.

3)      Categorization of part in different bucket to decide on sequence of migration like library part, assembly or sub assembly etc.

4)      Understand if non master file like CNC or drafting file etc. Understand there dependency on other parts.

 Based on above analysis defined the CAD migration strategy.

CAD vs Meta Data Migration:

It is also important to understand dependency between Meta data and CAD in PLM system. In most of PLM system CAD integration with PLM system also depends on objects relation in the System. For example wave link in NX also create a Teamcenter relation.  Also CAD migration will also required migrating CAD files based on new part number and types. This information is a part of metadata but required for correct migration of CAD in new system. Hence this information will available from staging DB.

This closes my discussion on Migration. I try covering important aspect of migration Analysis to Design phase. There are other important aspects of Migration like testing which itself is a topic on its own. I will try to cover it seperate blog.

See also :

PLM Migration : Part 1

PLM Migration : Part 1

One of the most challenging aspect  in PLM field  is data migration. It not only required metadata migration but also vault files system specially CAD files and this create higher degree of complexitiy. Not only it required to make sure that all object and relation are migrated correctly but also sanity of interpart relation related to CAD should also maintain. In this blog I will discuss the factor required to be consider for PLM migration. Since migration it big topic, hence I will split the contain in to two parts.  

Migration Consideration:

Following are the important steps  for PLM Migration

·         What to Migrate

·         How to Migrate

·         Before you start

·         Design Approach

·         CAD Migration

·         CAD vs Meta Data Migration.

What to Migrate:

For any migration you have to know what required to be migrated. In PLM migration there will three aspect of migration

1)      Meta Data Migration

2)      Document File Migration

3)      CAD Migration

Meta Data Migration is migration of data stored in DB from one system to other. Where Document migration of actual files which is maintain by one system to other. CAD migration e

From system migration perspective it can be either of this

1)      Single System migration i.e from one system to other system migration

2)      Multi System migration. It can either of

a.       Multiple to Single System Migration.

b.       Multiple System to Multiple System.

For complexitiy perpective Multiple System to Multiple System will be most complex. But they are usually break down to various project to make them Multiple to Single System migration.

To define what to migrate we have to do first have good understanding of old and new system. Also required to have understanding of Buisness process. As in many cases moving to new system also involved change in Buisness process to leverage the advance functionality of new system. Hence proper analysis required to be done for Old vs New process as well GAP analysis for finding any short coming in new system functionality.

Once the above analysis is done then it come what data required to be migrated. In all cases metadata mapping  play prominent role as they represent real mapping of Buisness process to Object. Following aspect of Metadata mapping has to understand properly.

1)      What are Buisness object from present system are required to migrated to new system.

2)      What are the property of Buisness object required to be Migrated.

3)       What relation between objects  is there in old vs new system

Object Mapping is most important aspect of migration. Success of any migration will depend on effectively and correctly the mapping is done. Mapping with will be usually boil down one of this scenario.

1)      One to One Mapping : One object map to similar object in new system.

 Ex Part to Part migration

2)      One to Many Mapping : One object map to many object in new system:

 Ex SAP Routing can map to Item and Item Revision.

3)      Many to One Mapping : Many object map to one object in new system.

 Ex: Two Object with relation object merge to single object in new system.

4)      Property to Object Mapping : Any Property in old system will map to Business object in new system.

Ex : Work Area property of Routing Operation in SAP map to Workcell Item in Teamcenter.

Next step for migration is related to approach to Migration

 How to Migrate:

Once the What context of Migration is clear, then come How. The approach is defined by considering many factory. Factor can be categorize in following points

1)      Bulk vs Phase wise migration

2)      Custom Migration vs Thrid Party MigrationTools.

Bulk vs Phase wise migration : Bulk migration involve full migration in one go. Following are the characterictic of Bulk Migration

ü  Complete movement of all data to new system at once.

ü  All users switch over at the same time.

ü  All processes move to New System at once.

ü  Source system should not be modified after migration (read only)

Phase wise Migration : This involved migrating phase wise in a specific duration may be few months to few years.  This required to have both old and new system to be co-existing  for whole migration duration. Also may required to have sync interface between old and new system during migration period. Following are the charactertic of Phase wise Migration

• Movement of specific data to new system based on certain criteria. Ex Group wise, project wise, workflow based etc.
• Set of users switch over the time.
• Co-existence of old and new system for some duration (From months to a year or so).

Bulk Migration	Phase Migration
Lower overall costs	Overall Higher Cost as two system required to maintain
No synchronization required between multiple legacy and new system	Synchronization required between old and new system
Change Management  and Training challenge is high.	Better Change and Training Management due to Phase wise migration
High impact in case of Migration failure.	Roll back can be easily done as old system coexist with new system
Suitable for Simple to Medium Complex Data. Also simple CAD with few BOM Line and depth	Suitable for Complex data mode and huge CAD assembly.

Custom Migration vs Thrid Party Migration: Second decision point is too made on Migration tools. Basically Migration tools can be either Custom Tools required specifically for migration or Vendor Tools. Most of Vendors provide offer Out of Self tools to migrate in their native system. For example Siemens PLM offer GMS for migration from Legacy system to Tc UA. Similarly other PLM Vendor provides similar tools. Analysis required to be done whether those tools are suitable for migration use case or not.  It is observed that PLM vendor usually claim to cover all use cases but in reality there GAP. This is truer if new PLM system has own migration tool.  This can lead to have more effort and cost then having custom approach.

Custom Migration approach is more suited if migration is from multiple system and data model is complex. Custom Migration gives more flexibility and control in migration. But at the same time it requires more effort and upfront cost for development and regressive testing. Most of time Custom Approach is done through ETL (Extract, Transform and Load) process where transformation is done in staging database. Following are the characteristic of both approach.

Custom Migration Approach	Third Party Tool Migration
Higher Upfront Cost	Only License cost involved
Suitable for Multi System Complete Migration	Suitable for simple migration supported tool
Regressive testing required	Limited testing required as it certified by provider.
Flexibility in case change in Business cases	Can be costly and time consuming if the Tool doesn’t support those use cases

Custom Migration approach also not really means developing everything from scratch. Most of time custom solution also involved using out of box utility provide by PLM system. Usually wrapper is written on top of them to make seamless migration. For example migrating CAD data always involves Vendor provided import/export tool which required to in sync with Meta data which can done through custom tools.

Before you start:

Before we start actual migration design it most important to have following aspect should be closed.

1)      Data mapping is completed.

2)       Also all Gap analysis and accordingly approach should be finalize.

3)      Expected Duration of actual Migration and delta approach.

4)      Infrastructure requirement mainly Server Capacity, Space etc.

We already discuss about Data Mapping and Migration Approach. It is also important to plan for expected duration because that will also defined strategy for delta consideration during migration process. Delta means all changes done between actual migration start and completion in native system. Since user can start working in new system only when the whole migration is completed, it is import to bring transition changes also in new system. This is done through Delta Migration planning. Delta migration comes in to picture when the migration is expected to take more few days and changes can moved from old to new system manually.

Infrastructure requirement is also important factory as it required considerable planning. Typically infrastructure requirement is calculated based on amount metadata as well volume required to be migrated.

This closes the first part of PLM migration blog. In this we discuss about factor required to be consider for migration. In the next blog we will discuss about Design and CAD aspect of migration.

See also :

PLM Migration : Part 2

Basic of PLMXML Export/Import

Basic of PLMXML Export/Import

PLMXML is a very powerful tools for importing/exporting data and file from Teamcenter to external system and vice-verse. PLMXML is Siemens PLM sponsors XML schema for exporting/importing metadata as well files from Teamcenter to other system,

  The advantage of PLMXML is its flexibility of defining rule for data extraction and import make it one of the widely use tool for integration and data exchange. It is also widely used in teamcenter other module like report builder and integration. For defining the rules, admin module is present where new rules can be created or modified existing rules. This rules are called Transfermode. In this blog we will discuss in detail the transfermode and its child rules.

Transfer Mode:

Transfermode encapsulate the rules which defines import/export data from teamcenter. It basically govern the Export/Import rules and meta data which required to be extracted from Teamcenter. Transfer mode mainly consist of

·         Closure Rule

·         Filter Rule

·         Property Set

Closure rule: It defines scope of data transfer. Basically it tells how to traverse from target object to its related object and whether to process or skip the object. For example if you are exporting Item Revision and also you required to export attach dataset with specific relation and type, you required to defined this detail in Closure rule.

Closure rule compromises five fields, primary object selector, secondary object selector, relation selector, action, and an optional conditional clause.

Primary object selector is the target object from which the traverse will be defined for its related object which is called secondary object selector. So as in our example for Item Revision to Dataset, Item Revision will become Primary object and Dataset will become secondary object selector as rule will be traverse from Item Revision to Dataset. Primary or Secondary object selector can be either of Buisness Type or Class. The third field relation selection defines how the primary and secondary object are related. Object in teamcenter can be either related through relation, attribute ,property. Other is refby which tell that secondary object refer the primary object. Also there is other two specific to BOM which is occurencetype and content.

Action field tell the system what required to done with secondary object. It take this words.

Skip : The secondary object should not be exported and no further traversing from object is required.

Process: Process the secondary object (extract object), but no further traversing.

Traverse: Don’t process the object (no data extraction), but traverse further for other related object as defined in closure rule.

Alter_closure_rule: Change closure rule for secondary object

Only Skip action can’t be combined will other. Process+Traverse means process the secondary object and traverse further to process its related object.

The closure rule is sequential, means the secondary object will become primary if you want to extract data which is related to secondary object. For example if you want to extract the file of Dataset when Item Revision is exported then we required to define new rule in closure rule which define the traverse rule from dataset to Imanfile.

Property Set: It defines what property can extracted from process object. Closure rule which object required to be process, whereas Property set defined what data/property required to be extracted for those object. By default Teamcenter extracted some set of property for different type of object.  For example revision id for item revision. But user required to extract further information then those required to defined in Property Set and add in transfer mode.

It constitute this following field.

Class or Type : Defined class or type name.

Property or Attribute: Define the attribute required to be exported.

Action: Define whether to process the property or skip.

So for example if we required to extract the description property of Item Revision, it required to be defined as shown in below figure

Filter rules : Filter rules allow a finer level of control over the data that gets translated along with

the primary objects by specifying that a user-written function is called to determine

the filter applied against a given object. Basically it is required for complex scenario where closure rule can be in sufficient to control PLM Data Export/Import. Mainly for condition like if, else if cases and required customization.

Action rule : Action rules are set of method which can be call for before, during, and after the

Translation. Teamcenter provide some of out of box action rule. But client specific cases usually required customization. In TcUA action rule are depreciated and replace by BMIDE extension mechanism

Approach for Successfull PLM Implementation in a Enterprise

PLM implementation is a complex system integration which not only involved technology implementation but also process streamlining and organization change. More often than not the PLM system fails to fulfill its promise not due to technology limitation but failure by organization on process and change management. In this blog I will try to explore various reason of failure due to inability of Enterprise to do good Change Management and approach to overcome this limitation for successfull PLM implementation.

Organization Change Management
Adaptation of PLM in any enterprise usually starts with big fun fare and expectation. But down the lane people realize that technology implementation is only one aspect of it. The other aspect is related to process and Change Management within the organization. For example there is a big giant company which has spent hundreds of millions of dollar on PLM system, but still struggle to stream line the part management and retire there old legacy system. The part of problem lies on the approach the company usually takes for PLM and part lies on the Vendor whose product they implement. The company usually starts approaching PLM purely from IT perspective rather than core business process management. Hence it results in PLM system selection purely on technology and functional richness, rather than its adaptation and suitability to the company. Since PLM looks from IT perspective, it also lead to internal team selection from IT department only. Where as it should be mix of business and IT people.

PLM Vendor Selection
PLM vendor ]are more interested in selling their product rather than providing business solution to the client. This makes them to blend the actual business process issue of the client to suit their product offering. This always led to less user level adaptability once the PLM is implemented and extra millions dollar by enterprise to make in adaptable by heavily customization which earlier avoided due to vendor promise of configuration rich product. Also PLM vendor are usually not good in Organization Change Management which usually a key attribute for PLM successful adaptation in any Enterprise.

Enterprise PLM Vision
The other aspect which usually define failure or sucess of PLM is managing future implementation and changes . Usually PLM started in any Organization with good long term vision. But as time goes, the vision goes on back seat and focus shift from strategy to providing immediate solution to user problem and requirement. This usually makes PLM system more complicate and less agile in long run. This change of track can be seen most of time in big organization and the reason can be many. One of the reasons is lack of any PLM strategy management team which basically should define and track long term goal of company. Second mainly in big enterprise is that in many cases there are independent powerful businesses vertical which want drive the change in PLM system based on their narrow vision and requirement rather than looking at broader vision and strategy on enterprise. This lead to deviation from vision defined in early stage of PLM implementation. Hence the best approach is to have PLM strategic team having from Top Management of different business unit which monitor the progress in a specific time interval. Any deviation from vision should be approved by this strategic team.

Summary
Below finer points summarize the above discussion.
1) Looking PLM purely from IT perspective is a mistake. Always look PLM from Buisness process perpective rather than information management tool.
2) Internal PLM implementation of a company should have both from IT and business user.
3) PLM system evaluation should be purely done from organization requirement and long term vision rather than feature offering of PLM Vendors.
4) Strict validation of Vendor product offering should be done against business requirement.
5) Organization Change Management is most important but often ignored aspect in PLM. It is recommended to have strong change management team. Prefer to engage external professional with dominant experience organization change management.
This is my view on it. Please open to provide your view and comments.

PLM in a Cloud : Limitation and Approach

For last couple of years we are lot of buzz is created regarding cloud computing and its promised benefits. Still required to be seen its benefit as word are going around as Enterprise are still struggling to get best way to approach it. As with other domain in IT, PLM in a cloud is also hot topic around in PLM world. Well lot of noise about its obvious benefits and cost saving, but there is basic different on PLM to other areas. In this blog I will discuss this limitation and some architect approach to implement PLM in cloud.
PLM Cloud Limitation:
When we talk about PLM, it not just includes information stored in byte as Meta data somewhere in database. It is much more than just discrete Meta data. It include product information which can be Big CAD geometric file which can in hundred of MB or can be some excel information storing some patented engineering information. Also all this complex data files are associated through relation provided by different PLM tools. So making these diverged files available in cloud itself is a big challenge. Secondly PLM is usually fully implemented by mid size to big corporation whose main objective is to stream line product development and safe guard know how rather than cost saving on this critical IT piece. So looking at the above aspect probably full offering of PLM in cloud will not be a good idea. To summarize this are the limitation of PLM in a cloud.

• PLM is not just about metadata. The major chunk is vault or file management. Managing this files which can be as big as some hundred MB is difficult.



• Company will be reluctant to have their core product knowledge information in cloud.



• PLM is cluster of different tool which make the overall PLM system in any organization. This cluster of tool can be varied from Enterprise to Enterprise. Offering homogenous PLM tool in a cloud can’t solve the problem.



• Full implementation of PLM is usually done by mid to large size enterprises with deep pocket. Cost saving can’t be only reason to move to cloud.

Having said that, still there is scope of implementing PLM in cloud with some clever architect and defining it scope. For example vendor collaboration can be done through Cloud so that they don’t required to access you core PLM system or network. I am proposing some PLM cloud architect which can come some of limitation.

PLM in a Cloud Architect proposal :
Option 1 : Vault in local environment and PLM in a cloud :
This can solve the problem of transferring data from cloud to local environment. For example CAD data which can Mega bytes. Also Company will feel more secure as their core product information lies with in Enterprise Network.

Option 2 : Partial PLM in a Cloud for Collaboration :
This can be effective use for vendor collaboration as well for multi site environment. This will help the enterprise to define access in a better way


Conclusion: Although Cloud computing is a promising technology, but looking from PLM it has some limitation as discussed in the blog. But still if we apply right approach on implementing it rather than going with full PLM in a cloud, enterprise can still leverage advantage of cloud. I discuss two conceptual approaches for it. I am sure there will many other approaches for it. I welcome all to comment and discuss on this topic.

PLM Implementation : Design for Support

One aspect of software design which rarely given due attention is design for support. It means that design of support is done is such a way that the Support activity in case of any break down or failure can be easily traceable and resolved in quick time. As the PLM deployment is at enterprise level, the support consideration has to be taken during implementation stage. But I rarely seen that due importance is given to it as it required to be given. There are many reason for it, but one of the reason is the time line and complexity which required to be deal for PLM implementation and support accept only come once the system goes to go live. Here I will discuss some critical consideration required to given while designing PLM solution.
What we mean by design to support? In sort it mean design should be done in such a way that all unexpected cases can be handled appropriately and propagated to relevant system so that proper action can be taken. One question arises how it is different from error handling? There is quite different between generic error handling and exception handling due to environment instability. Example of generic error handling is string size to large short of thing. Exception handling for support usually required corrective action from admin or support person.
Support Consideration during Design:
While Designing the PLM system it is important to list down all exception which will require corrective action from support. Ideally a Design review should be done with Support team before signoff. But it is rarely done in new PLM implementation project as implementation is done by one vendor and support activity is done by other vendor. So coordination and making them in sync is always a challenge. Based on my experience following point should be considering from support perspective while designing the PLM system.

Design for Support Consideration and Approach
1) Define or discover present support strategy of Organization.
2) Find out the tools presently use by Organization of Infrastructure management. For example some Enterprises use standard tool like System Center Operations Manager (SCOM) which also monitor health of application in remote system. Understand the infrastructure management tool so that PLM system can be integrated with it.
3) List all exception for all Business cases where user can required help of support.
4) Categorize each exception based on priority. Here a Business analyst can be consulted.
5) Define appropriate message for each exception.
6) Define and document appropriate corrective action for each exception.
7) Design PLM Implementation to accommodate this Exception cases and required appropriate exception output from PLM system so that it can be handle by Infrastructure management tool.
8) Have an approval from all stake holder mainly from support team who is going to own the support activity.
Design for Support is important aspect for PLM implementation but rarely given much consideration. If due consideration is given during design stage will help to reduce the support resolution time and also can save considerable amount of cost for a organization in long run.

Configuration Based PLM Implementation

Presently configuration based Software development is highly desirable and demanded by client. PLM products are coming with high level configuration with the aim of reducing the solution cost to client. But in most of cases in PLM domain client have some way or other unique feature which can’t be satisfied with configuration and some customization required to be done. Client prefers to have custom solution developed so that future changes can be incorporated through configuration rather than new implementation and the solution can be reused in similar requirement situation. This can reduce the future cost to them. In this blog I will discuss different way of configuration in Teamcenter and balancing between configurations driven development. As overloaded configuration based implemented may kill the real benefits and increase cost of development and maintenance.

Configuration Driven Implementation:
Configuration driven implementation can be define as development which can incorporate future change of requirement through change in some property or attribute define in a system. Basically it can be said that change can be done without changing the code. So configuration driven implantation laid its foundation at requirement itself, as the constraint of requirement define how much configuration approach can be taken. If the requirement is too specific and unique than configuration approach may be not a good idea. But if requirement is generic enough that configuration driven approach can be taken. For example if requirement presently is to process some logic for specific part type only but it future other part type can also have same business process. Also while doing design of configuration approach it should also be taken in to account whether there is any possibility of change in requirement. For example rarely any Organization changes there Change Management process once develop. Making this solution, too much configuration based may not be sound approach. Also other factor is reusability, usually for example Workflow Handler can be written in such a way that it driven by argument and can be reusable for similar case but with different business object type and status. To summarize this are the three factor which define for going for Configuration approach.

1) Requirement is generic or too specific.
2) Expected change in future.
3) Reusability of implementation.

Configuration based approach in Teamcenter:
In teamcenter you can drive configuration based approach through various means. The main tool which is also use in Product provided Configuration is Preferences. Preferences are internal Teamcenter environment variables store in database. Teamcenter provide various API both at server and client side to access those preferences. One of the advantages of preference based approach is that Teamcenter provide different level of preference control based on Site, Group, role and use. Also access control for edit for preferences is also defined. Hence different configuration can be wisely used . Second approach usually is through Configuration file. We define set of property in specific format which is read by code during runtime. The config file usually help in specific location usually in tcdata directory. This approach has its limitation as specific code to be developed to read and understand the config file. Also it not store in Teamcenter environment. Third approach is used for Workflow Handler development which can be configured by providing argument and its value while designing the Workflow. This approach widely used for making Handler behavior generic enough to be driven by argument. For example Handler can check state of target object type. The object type can be defined in argument.
To summarize different approach Configuration driven implementation in Teamcenter usually can be categorize in three types.

1) Preference based approach.
2) Configuration File based approach.
3) Argument based approach.

Usually implementation is driven by mixed of the above, but most prefer way should be preference based approach.