Page 1 - Welcome Page 2 - Update Page 3 - News Page 4 - Brief lines |
* Welcome * Welcome to 2PLM, an e-zine distributed about every two weeks. This issue includes :
The Product Lifecycle Management Interest Group (PLMIG) announced PLM Benefits Workshops to be held:
The objectives of the two Workshops are the same:- to bring together PLM practitioners and enable them to examine and evaluate their experiences in defining and measuring PLM benefits; to work through the whole scope of what an industry-standard Benefits Reference Model should be; and to generate all of the draft material to create a workshop view of a PLM Benefits Framework. The Workshops will enable participants to:
* Top 10 PLM Pitfalls To Avoid * Many readers have written to us about the Top 10 PLM Pitfalls white paper. We're planning an update to this document in the March timeframe in the light of these and other inputs. This week we include comments from Larry Gurule (LG), President of I-Infusion, a consulting organization specializing in Operational Business Process Modeling, and Dennis Baus (DB), a PLM Implementer. The original list of Pitfalls was: 1. Starting before everyone is informed 2. Proceeding before everyone agrees 3. Having unclear project objectives 4. Not planning for setbacks and rejection 5. Proceeding without a sense of reality 6. Running a major product risk 7. Thinking PLM is only about managing product data 8. Thinking you can hold off on PLM a little longer 9. Believing you can't fail 10. Not measuring and promoting your success We published Don Frank's (DF) comments in the February 13 issue of 2PLM. In this issue we add the comments of LG and DB. DF : Global comment: most of these pitfalls seem to be negative in nature and almost sound like a self-fulfilling prophesy of failure. Number 9, 'Believing you can't fail', I've found, is what makes difficult projects succeed. LG : With an overall success rate of 28% for PLM projects, self-fulfilling or not, the chances are good that your project will either not meet expectations and/or fail completely. DB : Failure is relative to what your expectations are. We had established long-term and short-term goals. I think the short term left no option for failure (although we did have a fallback plan). Long term we're still pursuing and gaining ground slowly, failure no, persistence yes. DF : What seems to be missing from the set is: 'Management's lack of commitment to put the necessary resources in place to ensure that the program can succeed'. LG : Primarily due to management's lack of in-depth understanding and project complexity prior to making the decision to go forward with a PLM project. DB : I can attest to that because we watched the business progress and benefit all around us while we waited for our turn (PLM). Our turn was last and suffered the consequences being the last on the list by developers and business priorities. DF : Number 3, 'Having unclear project objectives' should be at the top of your list. Having a set of critical success factors (CSFs) means that you know where you are going, what the expected results are and what resources are needed for success. Number 10, 'Not measuring and promoting your success' is a key corollary to Number 1, since in-process measurements against CSFs is critical to success. LG : An operational process view allows the business executives, directors, managers, solution architects and the employees the opportunity to implement capabilities the business truly needs to impact their business. DB :We had a clear "short term" objective - to maintain, yet change from, PDM, to a PLM baseline vault system. This was a challenge in itself since it involved cleaning up a world of past sins in order just to lay the groundwork for our long-term goals. The biggest challenge for our long-term goals was the timing and readiness of the PLM software. Measurement is a must! DF : Number 2, 'Proceeding before everyone agrees' seems unrealistic because some Neanderthals will have to be brought kicking and screaming to the PLM table and really won't get on the bandwagon until some real successes are in place and advertised. DB : I just love this one, nothing much more to be said. I'm still fighting this battle at every turn. Oh, just one comment, I love working with recent grads or co-ops, they are not yet set in their ways. LG : Too often, in a rush to deliver, companies default to a systems/technical approach to process and product implementation. This approach is technically-based and focuses on the physical and electronic infrastructure, as well as the high level systems/technical processes that link components and aspects of the organization. The systems/technical approach may appear easier to deliver than others and, with compressed delivery schedules, is often embraced just to get something defined and/or in production. It does not however, usually meet the needs of the community for which the solution was/is intended. It's important to recognize as early as possible in a project that this path is being taken, and act quickly to refocus the solution back to the operational needs of the company. DF : Number 4, 'Not planning for setbacks and rejection', should change, I think, to 'Not planning to overcome setbacks and rejection'. LG : All projects encounter change. The goal should be to minimize the effects of change and not let them result in project setbacks and rejections. This can be accomplished through clearer requirements and proactive, not reactive, project orchestration. DB : I recently got blind-sided because I believed that introducing a new application within PLM was so great it could not fail. Well it almost did, and was certainly not received as well as anticipated by my audience, not the way I anticipated to say the least. This caused me to quickly re-think why, and quickly change my target audience. I then received the anticipated response. (That's called a rebound in basketball.) DF : Number 5, 'Proceeding without a sense of reality', becomes a no-brainer if the CSFs in Number 3 and realistic planning for Number 4 are clearly understood and in place. DB : Number 5 was a painful one for me. To follow trends, sales hype, etc. is sometimes a battle. I fought to postpone the PLM implementation to the point I was thought be one of the Neanderthals. My engineering background along with knowledge of the maturity of the PLM application software forced me to stand my ground. This got PLM postponed for a year and was thanked by many later. LG : Operational Process Business Modeling (OPBM) can be done by accurately capturing and cataloging process information along with process-related detail in context to the processes being modeled. By capturing operational process related information, companies are better suited to make smarter, realistic decisions regarding their direction and goals. The business will also be better equipped to audit and gage the effectiveness of all their business related activities and solutions. DF : I'd like to see Number 7, 'Thinking PLM is only about managing product data', replaced by, 'Thinking that PLM is only an engineering enterprise' LG : However you say it, businesses need to understand that a PLM solution should not be relegated to one application or department. A PLM solution can realistically serve and service any department or application that relies on shared information and is capable of bi-directional electronic communication. DB : I commented on this one in a recent presentation. Once PLM was completed, and links to the "other" business systems were established, everyone around benefited greatly - but the engineering enterprise was still looking for their big bang. (Remember, the major efforts and resources to support this PLM project were primarily from the engineering areas). LG : What is missing from the original set is:
Top 12 PLM Stereotypes by Menno Huijben Reading the Harvard Business Review type of magazine, one easily stumbles on articles stereotyping management styles. You can read about the "Narcissistic CEO", or the "Compulsive Manager", etc. Having seen a lot of PDM / PLM projects, I decided to have a go at stereotyping PDM project managers and their team members. As with all stereotypes, there is nobody fitting them exactly. We are all some combinations of these. Some fit a bit better, some a bit less. Here's the list: 1. The Academic 2. The Developer 3. The Doer 4. The Macho 5. The Marketer 6. The Perfectionist 7. The Pragmatist 8. The Prototyper 9. The Quality Guy 10. The Technologist 11. The Visionary 12. The Waterfaller The Academic The Academic is a person approaching the project with data-models, objects and relations, STEP standards, and XML. The Academic tends to lose connection with the future user base, but does not suffer the "Not Invented Here" syndrome, and knows when and how to use standards. The Developer In the Developer we have a person who loves the possibilities of tweaking and customizing the PLM platform to the exact business needs. Nice features bringing business value are developed, but complexity and costs are on the increase when he/she really gets going. The Doer The Doer wants to keep it all simple and easy, this to get quick results - in 3 months preferably. Some planning phases are skipped, as that is all too woozy. The Doer is making mistakes that the "Lessons Learned" and "PLM Pitfalls" booklets show how to avoid, but things get done eventually. At the end of the project burn-outs are possible. The Macho The Macho is the guy of the "optimistic project plan and sticking to the milestones" set. The project has to deliver as promised, no matter that on the way we obtained new insights that made the project plan obsolete. The Macho won't listen, but the schedule will be kept. The Marketer The Marketer understands the importance of communication and explaining the project. Sometimes though, the marketing of the project and the Marketer's own accomplishments get somewhat mixed. But overall, people will hear about the project - be sure. The Perfectionist "At last a tool to start to model our products and business correctly", the Perfectionist thinks. The Perfectionist had tried before in Excel, but it did not really work out. Complete, perfect product models are conceived, but nobody seems to understand them. The Pragmatist This Pragmatist is somewhat related to the Doer, but smarter. The Pragmatist does not put himself on the line, and compromises are made easily. We might end-up with a PLM system that does "Nothing for Everybody", but the Pragmatist makes sure that at least it won't be "All for Nobody". The Prototyper The Prototyper understands the importance of trying out, and learning by doing. Good demonstrators are built, but arranging the rollout and production scale-up is too boring to be bothered with. The Quality Guy She/he comes from the 6-sigma, ISO and regulatory world. Workflow is his favored feature of a PDM system and designing watertight business process her strength. Beware your inbox, because it will be soon filled with all kind of notifications. The Technologist The Technologist would like to be back at the beginning of the project, when we did all the evaluation of the different PDM systems and vendors. The Technologist still doubts if we made the right decisions - shouldn't we do a new performance benchmark? The Visionary The Visionary fully understands the PLM vision related to the business strategy. And more importantly, is able to explain this to senior management and inspire the future users. But the Visionary couldn't care less about all the nitty gritty that will follow. The Waterfaller The Waterfaller knows how to run an IT project: first we collect the requirements, then we specify, then we implement and do some testing. The Waterfaller is often confused by the Prototyper, who is just messing things up. Has something in common with the Macho, but the Waterfaller thinks the method is more important than the project. Well, perhaps I missed some stereotypes, and I was somewhat cynical about the ones portrayed, pointing out their flaws. However, I do think that a successful PDM / PLM initiative is run by a project manager and team representing each of these stereotypes, with their flaws - in the right dose. Menno Huijben is a senior advisor at Sofigate Oy. Sofigate is dedicated to improving the performance of Information Management in organizations, hands-on and down-to-earth. 
Powering New Product Development and Introduction (NPDI): Teamcenter 2005 support for NPDI By Bill Boswell Industry analyst surveys suggest that by 2010, products that represent close to 70 percent of most companies' revenues today will be obsolete. Based on a survey of 650 companies, some 86 percent of new product ideas never make it to market, and of those that do, between 50 percent and 70 percent fail. Clearly, generating good, new ideas; defining market-savvy requirements; and establishing a product development process that brings those products to market in record time is essential to survival. With Teamcenter 2005, UGS addresses new product development and introduction (NPDI) with robust new capabilities to support ideation, requirements creation and management, and collaboration. With Teamcenter, customers can optimize the steps that need to be taken in the process of selecting a new product idea and executing upon it: Innovation capture: Gather ideas with a wide net A key element of company success is the ability to get closer to market needs and generate, understand, and evaluate ideas. There's usually no shortage of ideas. The key is to be able to actively encourage, source and embrace ideas with as wide a net as possible; and then to build upon the ideas through a managed process of discussion and collaboration. Teamcenter provides a flexible, collaborative environment where ideas can be fostered, gathered, shared and discussed within your organization, your partners and your market. Innovation exploitation: Link innovative ideas to product development With the identification of promising innovations, it's critical to ensure that product development can meet the challenges of bringing those innovations to profitable reality. All ideas, be they disruptive or sustaining, need to be objectively evaluated with respect to their ability to support the investments and profit cycles that products represent. Teamcenter provides a collaborative, decision-support framework where promising ideas can be objectively investigated, evaluated, compared and communicated among all key participants in the product lifecycle. By tightly linking the up-front process of innovation to functional execution, innovative ideas and market requirements can be tied directly to the product development process. Innovation execution: Manage and coordinate NPDI The ability to efficiently execute on innovation relies on having the most effective downstream processes synchronized and aligned to deliver products that meet market needs. Teamcenter provides the most comprehensive portfolio of product lifecycle management solutions to enable the process of product development, design, manufacture, production and delivery. More specifically, Teamcenter helps organizations more efficiently manage and coordinate new product development and introduction to accelerate success. Teamcenter provides a framework for product portfolio management. Its program and project management solution, married to repeatable process execution, offers the first truly sustainable platform for portfolio management. With Teamcenter, executive visibility isn't limited to the planning process. The integration of product portfolio management with the overall PLM infrastructure allows product requirements and program performance to be tracked and sustained through the entire product lifecycle. Combined with NX, UGS' digital product development portfolio, and Tecnomatix, UGS' digital manufacturing portfolio, Teamcenter leads the industry in harnessing the creative currency of innovation, validating it and delivering it. Innovation delivery: Successfully package and introduce new products Innovation does not stop with development and manufacture. Innovations need to be packaged and rolled out to their target markets to achieve maximum business success. Teamcenter provides a framework of lightweight planning and execution tools for sales and marketing to help ensure that the whole company can support their endeavors. In addition, Teamcenter provides key capabilities to provide development with immediate feedback from customers and field sales. Innovation network: Harness innovation for enterprise-wide performance The process of nurturing, developing and bringing new products to market is one of the most misunderstood and poorly managed business processes. The vast majority of executives feel that their new product development and introduction process are not under financial or strategic control. Teamcenter drives performance and productivity across programs, and across the wider enterprise, by harnessing innovation from distributed divisions, partners, and suppliers. Teamcenter's flexible portfolio of process-focused solutions links all participants throughout all phases of the lifecycle in an innovation network to balance functional excellence with connection to the wider enterprise. Teamcenter delivers a modular suite of industry-leading solutions for product development that allow all contributors -- engineers, designers, analysts, machinists, production planners, suppliers, sales and marketing, distributors and partners -- to work with a combined sense of purpose within a single, shared, source of product and process knowledge. For more information on UGS' approach to NPDI, please visit www.ugs.com/products/teamcenter. Bill Boswell is Senior Director of Marketing, UGS Inc. 
The Value of Operational Business Process Modeling by A. Larry Gurule For years, industry experts, as well as product and service vendors have attempted to communicate to us the value of understanding the processes that define and control organizations. Entire markets and initiatives have been created to refine and improve organizational processes. Products aimed at improving how the company operates such as PLM, ERP, MRP, CRM, and initiatives like TQM, LEAN, Six Sigma, have all experienced tremendous popularity and growth. Despite attempting one or all of these activities, many businesses are still struggling with getting their arms around the operational processes that define their business (let alone executing against what they do have captured). My Vendor says he can rescue me Regardless of what they tell you, no single vendor can supply you with an application that will meet all of your company's end-to-end needs. Vendors sell their solutions and applied processes hoping that there will be a close resemblance to your business (how many times have you heard "we've 80 to 90% of what you are asking for") and relying on customization for the rest. Often, requirements for these projects are communicated by individuals with their own "wish lists" supported by whatever process-related information is available with little or no regard for overall company objectives. An effective set of requirements for any project should contain a robust operational business process model quantifying the intended use, participants and information needs of the intended environment. If you can't quantify your requirements how will you know when they are met? Companies need to "Write down the music they want others to play to". By taking the time to effectively and accurately capture your processes from an operational view or perspective, as opposed to a systems or technical view, companies will be in a better position to demonstrate, communicate and manage requirements, development, planning and execution for all aspects of their business. Additionally an organization will be able to audit and gage the effectiveness of any and all initiatives. Understanding the chess board, Operational vs. Systems/Technical Process View One of the lessons learned over the past few years is the importance of taking an operational approach to process capture and modeling. An operational process view allows the business executives, directors, managers, solution architects and the employees the opportunity to implement capabilities the business truly needs to impact their business. Too often, in a rush to deliver, companies default to a systems/technical approach to process and product implementation. This approach is technically-based and focuses on the physical and electronic infrastructure, as well as the high level systems/technical processes that link components and aspects of the organization. Systems/Technical approach is much easier to deliver and with compressed delivery schedules, it is often embraced just to get something defined and/or in production. It does not however, usually meet the needs of the community to which the solution was/is intended. The key is to recognize as early as possible in a project that this path is being taken and act quickly and accordingly to refocus the solution being defined, back to the operational needs of the company. It's your business; shouldn't you know how it works? In order to achieve the operational process control needed to support a company's planned growth and any global activities, the existing processes that enable the company to produce its products and/or service its customers, need to be better understood and managed. The trick is to find a way to capture and make sense of current operational business processes quickly and easily. Operational Process Business Modeling, Valuable, Quantifiable, Deliverable Operational Process Business Modeling (OPBM) can be done by accurately capturing and cataloging process information along with process related detail in context to the processes being modeled. Additional strategic value can be gained by performing OPBM in a single environment that can be easily maintained (validated, released and revised), investigated (queried and reported against), and bi-directionally communicated with simple (transport of data to and from via a standard protocol such as xml or through commonly used tools like Visio, Word and Excel). By capturing operational process related information in this fashion, companies are better suited to make smarter decisions regarding their direction and goals. The business will also be better equipped to audit and gage the effectiveness of all their business-related activities. An Operational Business Process Model can help companies predict the impact of, as well as aid in the execution of proposed changes and business reengineering, while realizing their impact through higher customer satisfaction and increased profitability. A. Larry Gurule is President of I-Infusion, a consulting organization specializing in Operational Business Process Modeling. |
