Managing BOM complexity between PLM and ERP

Posted on by
Reply

As a follow up on Mathias post, I want to introduce some customer use cases we have seen in the past and which we are still facing today, showing that there are reasonable approaches to handle product complexity as an end to end process.

The Engineering to Order Process

Companies providing configurable standard products and solutions, also allowing customer specific changes, are most likely facing the situation that the engineering BOM (eBOM) has to be modified due to some customer requests during the order process.  Sales configurators, allowing to configure customer specific standard products, are often part of or integrated to an ERP solution. Typically the outcome of a customer configuration process results in an order BOM. To have the possibility to add new engineering parts to the order BOM, it has to be transferred back to the PLM system. In the best case, the PLM ERP integration already creates new items for the new engineering parts, while transferring the 100% order BOM to the PLM system. To be able to configure a 100% order BOM in the ERP system, the generic 150% product eBOM has be transferred from PLM to ERP system including all options and variants defined in the PLM system.

Besides transferring the customer orders as bill of materials another possible solution is to exchange the customer specific configuration as variant condition information between the ERP and the PLM system and vice versa. The PLM-ERP integration solution synchronizes the options and values between the two systems. The customer product configuration of the sales configurator results in a stored option set in the ERP system, this is transferred to the PLM system as a variant rule. This customer specific variant rule is applied to the generic 150% BOM and results in a 100% customer order BOM which is then transferred back to the ERP system. The advantage of transferring variant rules back to the PLM system instead of 100% BOMs,  is that the same rule can be applied to the 150% BOP (bill of process). The configured 100% BOP is then also transferred back to the ERP system as a customer specific routing.

The T4x Plus extension

To close the loop customers are thinking about bringing the information from the MES system back to the MRO module of the PLM system as an “as built” structure. This loop can be closed using the Teamcenter Gateway Plus extensions. These extensions enhance the Teamcenter Gateway solutions to a PLM integration platform, providing generic adapters to integrate other enterprise application. I will soon post another entry in the “Behind the scenes” section, describing the T4x Plus extensions in more detail.

Best,
Dirk

How does PLM, and a PLM-ERP integration, help manage complexity ?

Posted on by
Reply

This is a guest post by Mathias Mond, Managing Director, TESIS PLMware

Managing complexity is something almost everyone dealing with PLM is talking about and there is a good reason for it. Managing complexity is one of the great challenges in product development and product manufacturing.  Not only products become more and more complex, the processes to handle them are becoming more complex as well.

Now, maybe processes haven’t become more complex lately, they may have been that way for a while already. Why, then, is ‘managing complexity’ gaining so much attention now ?

Without an integrated product creation landscape in place that provides pervasive access to information by managing data from a range of diverse systems (aka ‘PLM’), processes have been essentially unmanaged or managed only partially. Processes rely on verbal communication and individual experience/knowledge to function, and that way complexity can be dealt with ad hoc – but the results can vary from excellent to very poor, depending on the effectiveness of the communication and the ability of the people involved to make the right decisions.

When end to end support of product creation processes is introduced via a PLM backbone, all the little things that were dealt with on an ad hoc basis in the past now need to be formalized. These ‘special situations’ aren’t usually documented anywhere, and a lot of time and energy needs to be spent on digging up what they are, how they affect results, and who is doing what if such a situation arises. If an analysis finds that there are exceptions, a decision must be made if those should be allowed in the future. If so, it must be determined how such situations can be handled within the formalized system of rules, as they are being defined in the PLM system.

So, to be able to take advantage of integrated information from a PLM backbone, a thorough analysis of the as-is and to-be state needs to happen, and tough decisions must be made. A PLM backbone will ensure that processes are handled in a controlled manner, eliminating errors and making sure that everybody has access to the information they need. This will however work only if the data model and business processes are defined properly, a PLM system cannot provide these benefits out of the box.

Extending the integrated information landscape to also include ERP, by integrating PLM with ERP, means that business processes and mindsets must be taken into account that may be quite different from what is available or planned on just the PLM side. This obviously adds to the complexity, and that is at least one of the primary reasons why PLM-ERP integration is usually regarded as being ‘difficult’. Just like the introduction of a PLM system, integrating that system with ERP requires a lot of thought. One of the considerations to be kept in mind is the extent to which the ERP side requirements may have an influence on how data models or business processes need to be designed on the PLM side. The impact can be minimal, or it can be extensive – either way it needs to be looked at closely.

My conclusion: Introducing PLM, and even more introducing a PLM system integrated with ERP, exposes complexity and the need to manage it. Fortunately, these systems also provide the tools to handle complexity, of products as well as processes, properly. It just takes a well planned and designed implementation of both PLM and PLM-ERP to achieve the benefits. There is a choice to be made: Tackle the challenge of managing complexity head on, or continue to live in blissful ignorance about the underlying complexity, hoping that nothing bad will happen.

In a follow up post Dirk will share his thoughts on some specific examples of complexity, and how they can be managed using well-designed business processes supported by a capable PLM-ERP integration.

We would like to hear from you, so please add your comments below.

Mathias

Behind the scenes – Initiating a transfer from SAP

Posted on by
Reply

This is going to be my first blog entry for our new “behind the scenes” category. The idea of the new category is to explain functionality provided by Teamcenter Gateway solutions in more detail.

In a comment to our YouTube video Teamcenter Gateway for use with SAP ERP (T4S) Version 9 – The Next Level of PLM-ERP Integration I was asked how a transfer can be initiated from SAP. The video is focussing on transfers from Teamcenter to SAP, as shown below:

This is the transfer direction that is used most frequently, and so, to give some background information, I will briefly explain the Teamcenter Gateway process flow for Teamcenter to SAP transfers.

Transferring an object from the PLM system, for example an item in Teamcenter, and creating a material master in object in SAP, always happens in two steps. The first part of the process is the so called forward mapping, it reads the item information including a configurable set of attributes from Teamcenter, creates the material master object in SAP and applies the attribute values from the item to the corresponding material master object as defined in the business rule layer. The second step of the transfer (reverse mapping), gives the possibility to read information from the SAP material master object and applying that to the Teamcenter item the transfer was initiated from. That means that every Teamcenter Gateway transfer from Teamcenter to SAP is in reality a bidirectional communication, providing the possibility of transfer information from Teamcenter to SAP and vice versa in one process.Anyways there are of course situations where it is necessary to initiate a transfer from SAP. Typical are migration scenarios or cases in which the customer’s material creation process starts in the ERP system. For SAP customers using the classic SAP GUI, initiating a data transfer from SAP always is an asynchronous process based on a SAP user exit that creates a job in a Z-Table (a SAP transport package and documentation to set up the Z-Table is available as part of the Teamcenter Gateway for SAP). The Teamcenter Gateway schedule service reads the jobs from the Z-Table and processes them as T4S import batch jobs. That batch job creates the Teamcenter object with all necessary attributes. A transfer initiated from SAP has the same flexibility and configuration capabilities as the one initiated from PLM, except that no data is flowing back from Teamcenter to SAP.  This is because no standard fields are typically configured in SAP to hold such data. For SAP customers using the Netweaver Business Client GUI, interactive methods of sending data from SAP to Teamcenter will be made available in a future release of the Teamcenter Gateway for SAP.

I hope that I could shed some light on the way we initiate the data transfer from SAP to Teamcenter. If you have any further questions, I would appreciate if you leave a comment.

Best,

Dirk

 

Seamless material and parts management from a PLM ERP perspective

Posted on by
Reply

Material or Parts Management from a  PLM – ERP perspective, should ensure a consistent process chain across systems for providing components from design to manufacturing and production. Usually the key factors are on-time delivery and data reliability. The business reasons to use a PLM or ERP environment, the philosophy behind PLM and ERP systems, and therefore the way people work with them as well as the data model, are very different and that is at least one reason why I think people consider a PLM – ERP integration project complex and challenging. One of the technical challenges such an integration has to achieve is a mapping between the objects and attributes represented in the data models of the two systems, to provide a platform that allows automated data exchange. Who now may think that once the technical hurdle is taken, material management is just transferring one object with its attributes from the PLM system to the ERP system or vice versa, may be right if the customers needs are not that complex and the data models are quite simple, but experience shows that often the information needed to create a material or part is spread across multiple sources (objects) in PLM. Also, system restrictions, e.g. access rights, and process dependencies have to be accommodated as well.
One simple, but good example is the support of mandatory fields in the ERP. Depending on the customers ERP process, certain attributes of the material master or part object may be mandatory for a successful material master creation. A user working in PLM trying to transfer an item to the ERP system may not be aware of those dependencies. Sure an obvious way of solving that problem would be to make the same fields mandatory in PLM as in the ERP system, but sometimes the information needed cannot be provided be that person or is not associated with the item directly, or it simply makes no sense to require those attributes to be mandatory in PLM. In such cases in my opinion a more reasonable approach is to define business rules that a PLM – ERP integration applies during the material or part transfer, to cover those system constraints. One example where not all the necessary information is not directly located on the item, which I see at a lot of our customers, is plant specific information. Depending on the company’s PLM data model the plant representation in PLM is a separate item type, with a whole set of plant specific attributes, related to the transferred item. Therefore, the PLM – ERP integration needs a deep integration to the PLM system with the ability to follow those relations and provide additional information needed for the material creation in the ERP system.

Some of our customers define the mandatory ERP material type automatically based on the PLM item type, that way the designer defines the material type in his daily environment and design process, without the need of knowing which material types are available in the ERP system to choose from. Another challenge are system dependencies, for example in SAP providing purchase information to a material master object requires a set of attributes (depending on the company’s business process), to be defined before a purchasing view can be created, a common scenario we see at companies making a make or buy decision in the PLM system. In that example the PLM – ERP integration creates the purchasing view only for items that are classified as buy items.

Another common pitfall that occurs when a data transfer is started is that the information provided by the PLM system is not accepted by the ERP system, that typically happens when ERP attributes with underlying list of values are updated. To avoid that, customers attach list of values to the corresponding attributes in the PLM system. To ensure that the list of values contain valid values the PLM – ERP integration synchronizes the list of values content on demand or on a scheduled base.

What is my conclusion – No doubt, moving from an manual integration scenario of adding or changing data in the ERP system based on information from the PLM system by hand, to an automated integration solution is a big step forward, but in my opinion that can only be a starting point. One of the typical key performance indicators (KPI), in my view, is the amount of time people are saving during their daily business and at least from my perspective the KPI rate increases depending on the level process automation and the reduction of errors. Therefore  PLM -ERP integrations, like the Teamcenter Gateway, have to have capabilities to support an end to end process for material or parts management. I will show more capabilities and needs for supporting this material management process, based on customer solutions in one of my next posts.

How can a PLM – ERP integration support your master data management process?

Posted on by
Reply

Master data management (MDM) enables the approach of having a single source of truth for business critical data. The typical business benefits are a high level of data quality and the prevention of duplicates. I found an interesting post about master data management by Rob Karel on the Forrester Blog MDM Remains A Top Technology Trend For 2011 And Beyond where the following statement really caught my attention.


Data governance is not – and should never have been – about the data. High-quality and trustworthy data sitting in some repository somewhere does not in fact increase revenue, reduce risk, improve operational efficiencies, or strategically differentiate any organization from its competitors. It’s only when this trusted data can be delivered and consumed within the most critical business processes and decisions that run your business that these business outcomes can become reality. So what is data governance all about? It’s all about business process, of course.

The idea that not the data, but the business processes should be in the main focus of a master data management approach, leads me to the question -  Is it possible to support (or even cover) the master data governance process for material master or parts data with a PLM-ERP integration solution?

Making sure that data is created and continuously updated across systems according to the needs of people dealing with the data and use them in their business activities helps ensuring data reliability, which at least in my view is one of the main reasons why people try to follow a single source of truth approach. A benefit for making data available across systems alongside business processes is that information is captured as and where it originates. That way data entered or modified becomes part of a business process, in many cases one that touches multiple systems, and thereby gets transmitted as the business process propagates. Data is being validated and enriched along the way which I think leads to a better data quality by having people with the best knowledge providing the information. To give an example -
Some of our customers, especially the ones having a PLM-CAD integration, create items in the PLM system which will be transferred as material master objects to the ERP system as they reach a certain level of maturity. Most likely the transfer is part of a release workflow containing check routines and review or approval steps. During the life cycle process, besides a greater maturity of the CAD model design, the item is also enriched with information needed by the downstream ERP processes. Examples are weight, unit of measure, type of material and so on. As part of the transfer process, business rules ensure that the information is mapped to the right attribute of the material master object in ERP. Besides one to one attribute mapping, business rules also allow the handling of more complex business cases, for example to classify the material master object in ERP based on a few attributes management in PLM. One of our customers even fills all business relevant attributes of the material master object based on attributes managed in PLM. That of course implies business process and rules allowing to apply values to attributes programmatically. I am certain that a workflow and therewith a business process supported material creation and update process helps achieving a greater data quality and reliability and that is why in my opinion PLM-ERP integrations, like the Teamcenter Gateway, can be key enablers for cross-system master data governance if the opportunity is being used.

Some of our customers running SAP as their ERP system are thinking about introducing SAP’s Master Data Governance for Material Master Data to cover their master data management needs, so -

What is SAP Master Data Governance for Material Master Data (MDG MM)?

The SAP Community Network Blogs post SAP Master Data Governance in SAP Business Suite 7 Innovations 2011 by Markus Kuppe in my opinion provides a very good overview of SAP’s capabilities and philosophy behind MDG, for MM and other areas.

Here is what I have understood from the post. The idea behind Master Data Governance is to combine the “classic” MDM approach to ensure data quality and prevent duplicates across all business divisions with a workflow based change management process. The creation and update process of a material master object starts with a workflow supported change request, where defined persons add particular information. For example one person adds data to the basic data view, another one, from the purchasing department, adds purchasing information to the purchasing view of a material master object and so on. The idea behind this approach is that information is provided by the person having the best knowledge in his particular area, to ensure a higher level of data quality and reliability. As long as the workflow has not passed the approval step the data is stored in a staging table. The approval completes the material master creation process and the data is moved from the staging table to the productive environment and is therewith for example available in the ERP system. Besides the workflow based material master creation, MDG MM provides possibilities to prevent duplicates, by verifying, based on business rules, if a material master with same characteristics already exists.
Having SAP MDG MM enabled in SAP in my opinion provides similar functionality as the workflow based  material creation process of a PLM system combined with an PLM-ERP integration and ensures that the data has a certain maturity before spreading it out to other business divisions.

Does a PLM-ERP integration solution need to support the MDM process when SAP’s MDG MM is in place?

For data created in SAP, MDG MM can really help improving the data quality across an SAP landscape for the benefit of business divisions using SAP. By time the data is transferred to the PLM system, the master data management process responsibility changes to the PLM system and this the point where in my view PLM-ERP integrations, like the Teamcenter Gateway, can ensure a seamless master data management process across systems.
Customers having a material creation process starting in PLM and using the PLM-ERP integration capabilities, combined with master data management aligned business processes, at least from my point of view, do not typically require a double check by SAP’s MDG MM before the material master data is transferred to the ERP system. This is true if the data entered in PLM is properly validated either as part of the processes executed in PLM, or during transfer to ERP, and the same also applies to a material master update processes initiated from the PLM system. Again that really depends on the customer’s processes and the amount of ERP relevant information managed in the PLM system. Scenarios where the material master creation and update process initiated from PLM integrates to SAP’s MDG MM can also be conceivable. In those cases other PLM-ERP use cases like BOM creation and update, also have to support the staging table concept, by for example checking the material master existence in SAP before creating or updating the BOM. This is already a long post, so let me only add a quick note here: To help achieve good data quality, the PLM-ERP integration should make the list of valid values from the ERP system available to the PLM user. Thereby, the PLM user as the one with authority over e.g. the raw material to be used, can enter only values acceptable to the ERP system, eliminating a common source of data entry errors and leaving the point of data entry where it belongs.

What is my conclusion – I really like the idea of discussing master data management supported business processes rather than data repositories. I think people should refrain from the idea that successful master data management is complete when information is kept cleanly and unambiguously in one repository. In my view making reliable data available to the right people at the right time, and having the data entered where the requisite knowledge is available, is a key part of a true master data management approach. In scenarios where SAP’s MDG MM is supporting the master data management process in SAP, suitable business processes have to be defined ensuring a seamless MDM process across the PLM-ERP landscape.

~Dirk

Why train users on a PLM-ERP integration?

Posted on by
Reply

In my experience, when people think about integrating systems, they most likely think about data ownership, data models, protocols and business process rather then user training and that is in my opinion absolutely reasonable. Why should user be trained when a company decides to bring in a system integration solution? Typically the solution should not be noticed in first place by any user. Taking an example out of the PLM-ERP process, where a user is releasing a BOM in PLM using a workflow. In that example the workflow has some review tasks where certain people have to do an approval, some automatic checks are done and at some step in the workflow the BOM is transferred from the PLM system to ERP system. In that scenario there is no user interaction necessary to make sure that the BOM is transferred to the ERP system, frankly spoken, if no error occurs in that particular step most users probably would not even notice that a transfer has happend in the background. So why train the users on a PLM – ERP integration?

Train the user

In my opinion the user does not need to know about the integration itself, but he has to know and get trained on the “new” way of working. If the user never learns how to handle data, and how his handling of data impacts others, bad things can happen of course, and nobody could blame her. Again from a PLM-ERP integration perspective she has to know that certain business requirements have to be met before transferring information across systems. Just one example: A customer is working with plant specific BOMs, and in order to create such a BOM in ERP, the user has to add a change object to a BOM in the PLM system before transferring it to the ERP system to make sure that the BOM is created or updated in context of a ERP change number. How does the user know which change # to use, and which plant to define as the target ? How can he be sure that his BOM is complete and will be accepted by the ERP system ?
The user training in my view should typically be a customer specific training based on the customer use cases, because the exchange prerequisites and expected results are mostly different at every customer I have been to. Besides that training should include common pitfalls and where to find the necessary information in case something goes wrong. This of course requires that the integration solution clearly shows the reason or at least the source that raised the error.

Train system administration & support

In most of the companies I have been to, the IT department is responsible for the company’s software products and integrations at least from an operational and support point of view. In cases where errors occur during the data transfer, their first level support has to be able to provide an answer to the users. Those errors do not necessarily have to be systems errors, the experiences I have made are that in most cases, business requirements necessary for a successful data transfer have not been met before trying to transfer the data from one system to the other. In my opinion, the training provided to first (and second) level support should therefore be a mixture of customer (business process) and integration (architecture, technology) specific topics.
In many cases the operations team has to provide health and throughput status on a regular base, at the very least the team is responsible for making sure that systems are operating smoothly and with sufficient performance. To that end, the people from the operational team should be trained to gather the needed monitoring indicators. Also, installation and software distribution should be part of the training. Some of the customers I have met are keen on implementing or enhancing their integration to cover new or changed use cases themselves. In those cases it makes sense to train the configuration and implementation possibilities based on scenarios already implemented, or at least based on a defined system design specification.But I have also seen customers successfully extending their use cases, by training themselves purely based on the documentation available.

Training on the job

Thinking about larger companies where tens or hundreds of PLM or ERP users have to be trained, in my opinion training a defined group of people, i.e. key users, can be a reasonable training approach. Key users should be those willing and able to share their knowledge and help the regular users in difficult situations. That at least in my view of course depends on the key user availability. I have seen companies following the “training on the job” approach, but at the time the key users were needed by the users, they were not available, because the had to do some other important work.

To summarize: I hope I have been able to make it clear why training, especially business process oriented end user training, is an important part of an integration project. According to our experience this is often taken

~Dirk

 

How long does it take to implement a PLM-ERP integration ?

Posted on by
Reply

I am often asked what the effort is for a PLM-ERP integration project.

Of course that question is not easy to answer and I think it is necessary to differentiate a few aspects to get an idea of the implementation effort. I have seen a lot of presentations and webinars showing efforts in the range of days for a successful integration project. Of course that is something that is achievable when the integration needs are not very deep, and the customer knows exactly what his processes look like and has clear understanding which part of the process should be done in PLM and which part in the ERP system. The last point at least in my experience is always a discussion point.

Let’s take a look at the implementation steps that in my opinion have to be part of a PLM-ERP implementation project.

The implementation blueprint

  • Understanding the customer needs
    The implementation begins with gathering the customer requirements and transferring them to use cases. This is a key factor of the implementation project to make sure that the right things are done and the customer has a good chance of being successful. I have seen customers who really know what they want, but there are also others where the requirement phase is an iteration process over a period of time.
    For example the question which system has data ownership in which part of the process could be assumed a rather simple question, but my experience is that questions like that more or less kick off the discussion of the requirement phase and sometimes lead to the point that not everything was thought about in the beginning.
    Another experience I have made is that a lot of customers have a pretty good view on the functional requirements of their company, but the non functional requirements are often not in focus. I think especially in business critical processes, which include PLM-ERP integration scenarios, the non functional requirements are an important factor for being successful in the long run. Of course it is not as easy to define them as the functional requirements are, but I think it is usually a good approach to define ranges like 90% of the data has to be transferred in a short period of time, 8% medium term, and the other 2% within a longer time span (e.g. 24 hours).
  • How will the customer needs be implemented? – The functional specification phase
    This phase of the implementation is very important to the customer, it typically shows if the supplier has understood the customer requirements. The functional specification or system design specification picks up the use cases defined in the requirement specification, describes the way the requirements will be reflected in software configuration and possibly customization, and defines the necessary test cases. This is, again, often an iterative process and sometimes this process leads a step back to the requirement side and customers rethink or change their requirements. In my opinion this not an indicator that something is going wrong, it is rather a necessary part of the implementation process and in the end leads to the point that the customer really gets what he expects.
  • The “real” implementation
    In this step it really comes to the implementation phase, meaning the previously specified customer requirements are configured and the business rules are defined.
    This is typically the phase of the project where the effort is pretty clearly known, and it usually can be completed within days.
  • Testing
    Testing is something that is in my opinion often underrated, I have met people who think that testing is something that only makes sense in an production environment and therefore there is no need for testing before the go live. Often the excuse for that is that in a test environment not all the necessary data is available. In my opinion that may make sense for testing the non-functional requirements like performance and throughput, but not for the unit and integration tests. For example testing a material master transfer from PLM to ERP and checking if the attributes are transferred and it behaves as defined in the functional specification described is a test case which can be easily set up and tested in a test environment before going live. In my opinion it is also important to invite key users during the testing phase. This usually is the indicator showing if the implementation is user friendly and really meets the users expectations.
  • Go live support
    This is the phase where the training documentation of the customer use cases is created and the key users or all relevant users are trained and the software and the configuration moves from the test environment to the productive environment. The users may not even notice that there is an integration in place now, nevertheless they need to know in what way the workflows thy will work with are impacting the processes of other people, and how they can make sure that data is ‘clean’. The training should therefore cover cross-system business cases, data ownership and mandatory steps before initiating transfers, as well as what to do if something goes wrong.

Conclusion

Of course the implementation effort is different for every customer, for a variety of reasons, but I think these steps are all necessary for a successful integration project. Some customers for example have a pretty good view on their business processes which can shorten the requirement phase. Another factor on the effort is the complexity of the use cases, use cases that are very well spread among various customers are typically easier to define and implement. One of my next articles will show a customer example where the implementation time was rather short, contrasting with another one where business processes were streamlined extensively, creating great value for the business, and where the overall process took a lot longer.
As you can see the question regarding the effort for a PLM – ERP integration project is not so easy to answer straight away, but taking a look at the customers requirements and use cases helps making a reliable effort estimation.

~Dirk

My thoughts about providing the right information to the right person at the right time

Posted on by
Reply

What is your opinion on real time information availability?

With respect to cross system process and information exchange in a collaborative environment there is often a discussion about the acceptable time frame for information availability. Dealing with different time zones reduces the so called “nightly” time frame to a minimum and raises the challenge for bulk information updates. Especially in a decision making process you can’t rely on poor data, you really want to be sure to make your decision on the right information.
One approach in my opinion is to classify the information regarding what is relevant vs. not relevant for a decision. Decisions not taken can stop the process and prevent people from doing their downstream work. Therefore I think it is a good idea to think about possibilities to differentiate the type information needed and therewith the speed of information availability.
One example for handling information differentiation is providing possibilities to support persistent and non persistent data availability. Accessing data non persistently is a nice way of having information available in real time,showing for example the actual status or other attributes from an ERP system before taking a decision on the PLM side. Transferring data persistently on the other hand, in my opinion is a handy way for processes that rely on a transfer of data ownership from ERP to PLM or vice versa or on information that is processed by downstream activities, most likely the speed of information availability is not a key factor for that kind of information.
A customer solution we have implemented using non persistent information shows for example the available parts (materials) and bill of materials in the specific plants they are manufactured at, inside the PLM system. The customer accesses information in real time to check if a material or BOM is missing in a plant without the need to leave his PLM environment.

How do you tackle the information flood?

Besides the information availability, in my opinion sharing the right information with the right person also helps achieving an effective decision making process. As many of you have noticed the amount of information grows tremendously in our days and figuring out which information is important to whom is becoming a great challenge. One approach handling the information flood is sharing all information with anybody and let the people decide themselves what is important to them. That may be a solution for small teams with people who are working very independently, and who don’t have any security requirements. Following a collaborative approach of having cross-team or cross-department processes and decisions, distributing information selectively in my opinion leads to greater success. Integrating information exchange in workflow engines is just one example how to tackle the information flood, but for my point of view a pretty good one. Using the possibilities of review and deliverable tasks of a workflow engine helps tracking and achieving the desired information quality in multidisciplinary processes and responsibilities. Adding the data exchange to that workflow process is a possible way of ensuring that the achieved data quality is also kept across system boundaries.

Providing the right information to the right person at the right time without a doubt is a big challenge, but I think it is very important for a successful decision making process to take the challenge and find ways to tackle the information flood.
I am very interested in your opinion and experiences of handling cross system information and processes.

~Dirk

Welcome to plmerp.com

Posted on by
Reply

Dear reader,

looking at today’s IT landscapes at companies who produce and sell products, you will typically find a more or less complex combination of various software products. Such landscapes are mostly historically grown, mergers and acquisitions make them even more complex, at least for a period of time. Many companies however consciously decide to use a variety software products to run their business, simply because there is no system available which is able to satisfy every need. MS Office and CAD are just two examples, but more relevant in this context are PLM and ERP platforms.

This blog is meant to contribute to the discussion on how best to live with a landscape of (maybe even multiple) PLM and ERP systems. Some may argue that it really is a good idea to “take the best out of both worlds” which may indeed be true but is besides the point for me. The challenges are indeed not that different even if PLM and ERP are from the same vendor, or even are leveraging the same IT platform. We will get to that in a post on its own in the future.
Regardless of how you get there, in reality most companies indeed have different environments in place to support their product development processes (PLM) vs. business process support and transactions (ERP). So, what is really possible these days if you want to enable collaboration across system boundaries ?
Expect to see contributions that we hope will shed a light on the realities. We invite you to provide your comments, please understand however that we reserve the right to moderate these comments.

Mathias Mond

Managing Director
TESIS PLMware GmbH