|
|
www.johnstark.com |
|
|
|
It's important to get a good understanding of the 'to-be' situation that meets the business objectives and user requirements. This is not as simple as it sounds. First of all, nobody knows exactly what the 'to-be' situation will look like, so it's impossible to provide a detailed description. Secondly, there an infinite number of future situations. It is highly unlikely that the 'to-be' state that is targeted will ever be achieved. New opportunities will appear, and the very act of changing creates a new and unexpected situation. And of course, even if you did get to the targeted 'to-be' situation, you'd immediately try to make further improvements. Realistically, most of the change experience will be spent in 'intermediate' states rather than in the 'to-be' state. Thirdly, there are an infinite number of possible 'to-be' situations, so it will be necessary to identify several potential 'to-be' situations (or scenarios), and to show why one is preferred to the others. It's usually best to investigate three or four scenarios. Each scenario should be described in detail along with its strengths and weaknesses. This activity helps get an in-depth understanding of a proposed solution. Often it is by trying to understand the strengths of a scenario that the weaknesses of other scenarios become apparent. Fourthly, there are many reasons for not defining a 'to-be' state in a lot of detail. Wouldn't this result in many people assuming that they are not empowered to make change themselves? And don't you think that most of the people probably have a better handle on the details of their job than you do? The 'to-be' description has several closely related components:
In the same way that an architect of a building links the concept of the building through plans to the installation and use of the building, PDM architects have to be able to design and express usable PDM architectures. In the same way that the cabling and piping of a building, and the position of the elevators, doors and windows of the building, must all be clearly and uniquely defined, the key components of a PDM architecture must be described. They include:
Underneath the architecture will be more detailed descriptions. For each major function (of both the business and the PDM solution) the major data sets need to be identified. Data can be grouped in different ways, e.g. parts data vs documents, parts master vs product structure, new products vs existing products, purchasing data vs manufacturing data, paper-based vs computer-based. Within each data set, the individual entities need to be identified. The most important identifiers for each set have to be identified. The definition data elements that can be supported need to be defined. The potential states of data need to be defined (e.g., initial user development, in process, in-review, released, under revision, withdrawn) for each data element. The attributes to be associated with each data entity have to be agreed. The links between the various entities have to be identified. Data ownership issues must be resolved, and rights and responsibilities defined for both the owners of private data, and the administrators of shared data. Access, security, collection, quality, maintenance and documentation issues must be resolved for data and metadata. Detailed answers to many questions will be given. How will release management really work? How will Engineering and Manufacturing BOMs be handled? Will it be possible to handle parametric BOMs? How will users access the system? Which users and managers should be trained first? What will the user interface look like? How will screen and report formats be chosen? Where will master copies be kept? How will data be distributed? Which library symbols will be allowed? How will users be given different access rights on different projects? How will security be maintained? Will it be possible to maintain several levels of confidentiality? How will long drawings be handled by a scanner? Should all existing drawings be scanned? How will the system run on an everyday basis? What interfaces to other systems will be required? How will workflow be streamlined? The main aim of introducing a PDM system is to improve the company's business position. Typically PDM will lead to benefits in reduced lead times and reduced product costs. Benefits could also include reduced scrap or reduced rework, increased time spent on productive work, and reduced time spent on tasks that do not add value (such as searching for lost drawings and carrying out administrative tasks). It will be necessary to show how the benefits arise in the proposed 'to-be' state. Among the organizational aspects of the 'to-be' state that will need to be described are system installation, training, development of procedures and documentation, use of standards, standardization, system management and support, security, work methods, work flow, information management, management roles and responsibilities, and potential re-assignment of roles and responsibilities. Financial aspects of the 'to-be' state to consider include costs not only for system purchase but also for maintenance, installation, new versions, expansion of the system, and interfaces to other systems. Vendor aspects to consider include criteria such as commitment to PDM, development plan, ability to develop and upgrade, maintenance record, growth record, user group, delivery time, and availability of technical assistance. |