Thursday, June 27, 2013

Challenges – starting PLM Projects till Rollout and Go-Live

Previous posts were discussed on PLM, start of PLM implementation till Roll Out of project. While executing the project most of the PLM vendors will face many challenges, I just want to record the challenges what we faced in two implementation for typical domains, one in Thermal Power Energy & Plant Design Organization and another one Mid-sized Mechanical Design and development for Defense products and automotive supplier Organization.

Ø  Lack of preparations and sudden call to start the PLM Implementation.
Ø  New domain and cumbersome Plant Design process of execution
Ø  Very tight project schedule to complete implementation as per the PO size.
Ø  No prior case studies and expertise guidance in the combination of chosen PLM tool and Plant Design domain.
Ø  Social responsibilities and other organizational regularities.
Ø  Pressure to meet over promises and commitments in presales phase.
Ø  Management Mind set about old PDM system and new PDM system.
Ø  Very beginning of project and no clear visionary path and objectives to drive and setting project best methodology.
Ø  Prestige and Egoism issues between many people, lack of openness, blame games etc.
Above challengers are common in the PLM implementation and we handle effectively the above stoppers, then confidently PLM implementation will be succeeded.
Bye for now,
Anil Kumar J R

Friday, May 31, 2013

Testing Environment and Deployment of Production database of PLM configuration Go-Live phase

Many hands make light work ! ! !As discussed in last post PLM service vendor develops plan of architecture of PLM system, hardware setups and other security prerequisites and later once all set in, the test Database which included OOTB offerings of PLM tool and the special functional Requirements can be customized in the tool as agreed at the scope sign-off level by both customer and service vendor. Once Test DB configured fully, service vendor will start test the system rigorously to get the output properly and effectively in front of customer’s representative. In case if any issues or miss-matches found during the testing phases will be recorded and again discussions will be done to settle out the required solutions and configuration. Once both Customer and Service vendors agreed and sign-off on the Testing Acceptance Certificate, vendor will plan for configuring the Production environment. This phase will take minimum one month to six months depending upon the Technical Scope and functional requirements in the respective organizations.
Deployment phase comes once after testing done and both representitive will be present while deploying the testing configured Database to production environment. Testing Environment database can be replicated to Prodcution ENvironemnt and in most of the PLM systems this the case and the fully tested and approved configured database will be replicated to Production environment to establish strong and robust system in place. Again after deploying Production system, one more round of testing with respect to functional, performance, hardware, will be done till it comes to level of declaring the production system is live and ready to work with users. This phase takes again a month of time depending upon the number client setup and functional setup. Once Server application, database server, vault server, PLM client installations & configurations, Integrations, etc. are completed, training will be given on functional scope of Imlemented PLM system. Once Training completed and users feel comfortable to start work in the system the service vendor will declare PLM Implementation is completed successfully and Proejct is Roll Out and its Go Live, it should be sign-off mutually to agree the project is Live phase.
Depending upon the project and its situation we can set this Go-Livep hase, service vendor will provide handhold support to users at cleitns premises for two to three weeks or a month as decided by both.
Bye for now,
Anil Kumar J R

Thursday, May 16, 2013

PLM Implementation Configuration Plan

As we discussed in previous post  As-Is and To-Be process document, which will be base for Technical Scope for whole project, including all the technical statement of work, functions and way of execution of the things are going to implement as per organization’s requirements. Once detailed technical scope is prepared by PLM vendor and it will be submitting to Organization’s team to review and approval. This will be reviewed and modified several times by both PLM vendors and Organization teams to get into good technical scope before starting up configuration phase of PLM tool.  Once after sign-off for Technical Scope done, vendor should plan configuration plan with the Project Manager and other technical experts in place.
PLM Configuration Phase contains:
Ø  PLM Architecture and networking Plan
Ø  Hardware and Software Requirements  
Ø  Database configuration Plan and Precautions
Ø  Details Technical functionalities coverage
Ø  Technical Experts Resource Planning
Ø  Test Environment Plan
Ø  Certificate and Deliverables
o   Test Plan with scenarios
o   Sign-off certificates
o   Installation sign-off
o   Acceptance Test Plan
o   Change Request forms
Next we can discuss about testing and deployment phase
Bye for now,
Anil Kumar J R


Monday, April 22, 2013

As-Is and To-Be Process after Requirement Phase

As we discussed in last post, after requirements captured by all cross functional teams in the organization, it is very important to develop As-Is process documentation.As-Is process is working methodology of an organization at present without any new system implementaion. Once As-Is process document is ready, submit it to management team for review. Management team should review the As-Is process document and reviewed process should be used to create To-Be process with respect to captured information by the organization and PLM tools offerings. It is very important to prepare first level To-Be process document before starting project and organization people and PLM service vendor both should again review To-be process together. To-Be process documents should include the future PLM system technical scope which will be implementing after mutual agreement between both organization and PLM service vendor.
To-Be process is a document which should clearly indicates what and all PLM functionalities will be implemented as per organization requirements, if some of requirements are not able to implement at present chosen PLM software then those functionalities should be clearly mentioned with proper workarounds or customized ways to get it done to match organization’s requirements. And To-Be process document is overview of scope of work document before elaborating the technical scope document of whole PLM implementation project.
Simple Example:
As-Is process:
a.       At present Engineers are generating Part Numbers manually in excel sheet and later entering Part Numbers from excel sheet to CAD model and Drawing manually.
To-Be process:
a.       Automatic Part Number Generation module will be built in out of the box PLM system offering as per Number Logic.
b.      And engineers will use this function to generate Part Number directly in CAD tool and later assign to new CAD Model and same way another Part Number will be generated for respective drawing automatically.
c.       In case of complicated Part Number generation and other reference variable Part Number logic, customization needs to be done and same will be evaluated later.

Some the PLM vendors prepares whole Project Plan before proceeding to requirements phase and some vendors develops Project Resource and Time plan after To-Be process signed-off by the organization team. Both the way is suitable as per their internal process. We developed Project Plan before and after To-be process sign-off again we changed some the Project Plan in our Project.
Next post we can discuss how the technical configuration plan can be preparation and how we can start PLM software configuration.

Bye for now,
Anil Kumar J R

Monday, April 1, 2013

Understand and Capture Requirements across X-functional Teams

As we discussed in previous post about PLM Implementation and egoism, it kills the whole project jointly. The first and most important phase to post sales of PLM tool is to “Understand and Capture Requirements across cross functional Teams in the Organization”. What does it mean by “Requirements” in PLM and how we can define requirements? , are the main concerns.  Requirements come from any organization and its management from beginning of its product establishment. I meant to say every organization have their own objectives with respect to their product output that as product should be Qualitative, competitive, economical, market best etc.
While fulfilling these objectives there are lot of challenges to overcome and for any organization there is a need of strong solution to overcome challenges around the way of their product development. To setup a strong solution in place organization must know their necessity, needs, wants to match and establish a solution to make work to overcome challenges. 

Collecting information on the above said necessity, needs and wants are called as Requirements Phase. As PLM tool will be finalized based on organization basic visionary requirements and post sales of PLM tool is very much important to collect technical requirements across cross functional teams (Design, Production, Suppliers, Inventory, Sales etc.) to defines As-Is and To-Be process documentation which will help to define base of PLM implementation Scope as what and how to configure the PLM Software to address their requirements.
One simple live example from an Organization: Total 100 members in Design Department and in that 50 Design engineers are working concurrently on complex product assemblies and generates various types of 3D models and 2d Drawings with their standard Part Numbering system, having modification writes. 20 Engineers are working in Quality Departments and they check the models generated by Design Engineers only in viewers and do comments and notify design Engineers for changes, 10 engineers are from Supplier Coordinators and they responsible for BOM generation and 10 people are Team Leads they acts as reviewers and for all deliveries from Design Departments and 10 people Project Managers which they approve the Design and delivers to Production Team. Design engineer should send their work to review Team Leads after QC and TL will review for accept or reject. Mangers to approve finally to Production Manager.
In the above scenario we need to identify every need of engineers to fulfill their working ways and it should increase the productivity and efficiency while working with PLM system,
Design Engineers needs various Attributes to create a 3D model, Unique Part Number, User friendly working methods, secured data to save in central server, better performance, quick sharing and viewing others design data, drafting standards in 2D, attributes mapping to 3D to 2D, various drawing templates, BOM generation templates, various report formats, quick viewing of reports, Reviewing workflows, quick change communications, change history track for future references, various reviewing processes: Check Process, Change Request and Order Processes, Release Processes, BOM creation & Modification processes etc.
Collecting all the above important requirements and need to develop As-Is process to get to know the To-Be process. This phase is the first step for good start up of PLM Implementation.

Next post we will discuss about what is To-Be process and how we can build it.

Bye for now,

Anil Kumar J R