In order to integrate data between two or more systems, the people working in those systems must use the systems in a consistent manner. You cannot have schedules on one project updated biweekly, and on another project updated at the whim of the manager, and expect to have meaningful ways to compare progress on both jobs. In order to have working integrations, you must establish how projects will be managed in a consistent manner. This is not to say that you must manage a $30,000 project in exactly the same way as a $30,000,000 project, but you do need to have all interested parties first sit down and talk face-to-face about how the company wants to manage projects. In many ways, the plan to integrate data is successful before it even begins, simply by requiring that these conversations take place.

You know the old adage, garbage in, garbage out. When you integrate systems, the integration processes themselves require that certain rules be enforced before any data can be exchanged. For example, your committed costs should not exceed your budgeted dollars. Cost accounts and vendor identification in one system must match those in the other system.

Calendars must be consistent so that, for example, the P6 calendar does not have one day as a working day while the same day is a holiday in the ERP system. These requirements need not be onerous. In a well-designed set of integrations, any discrepancies are quickly identified and flagged, and the appropriate parties are notified. This tight feedback loop ensures that current people learn how to use the system consistently, and that new people can quickly learn the rules of the system.

Integrated data systems ultimately remove information silos, as well as duplication of effort and other manual activities that keep people doing "busy work" rather than pushing projects to completion and profitability. Rather than waiting until project completion to learn whether you've made or lost money, you know in real time. Rather than fighting claims after the fact, you can see problems arising before they become an issue. As project personnel are moved from one project to another, there is a consistent, professional approach to handling project information. And because projects are managed consistently, you can measure results and improve your project management processes.

The first item is over-analysis . As with any endeavor, you should aim first to solve the easy situations. For example, we can all agree that the budgets in P6 should reflect the budgeted project costs in ERP. And fortunately, project-level budgeting in P6 is fairly simple so that this is easy to accomplish. However, mapping budgets down to the WBS-level can quickly become a quagmire, as different projects with different WBS structures can generate lively debate. As you will see later, in the Oracle integrations if you can agree that WBS will match at a fairly high level, you can integrate budgets easily. This is because budgeting is a general concept that is handled pretty consistently across a wide range of companies.

Work orders, on the other hand, can mean many things to many people, and can vary widely among industries. Do you mean a work order to fertilize an oak tree the next time your crew is in the area during regular maintenance, or do you mean a work order to bring in an emergency team to replace a leaking vessel? To integrate work orders, you need to evaluate carefully all the ways they are used in your company, and then come up with some common rules that handle 80 percent of the most common situations.

For the small percentage of work orders that will not simply flow between ERP and P6, just let these go, and resolve that you will continue to use manual and redundant processes in these situations. You will find that by handling the majority with integrated processes, the remaining "squeaky wheels" are much less of an issue.

To this same point, evaluate the cost benefits of integration. In one recent integration consulting project, the client was treating subcontracts and purchase orders at the same level. The subcontract integration was fairly simple, while the purchase order integration rules were quickly running out of control. When one of the project sponsors was asked what percentage of project costs were purchase orders, he replied, "Less than one percent." That settled the matter: energy was put into integrating subcontracts while leaving purchase orders alone.

Often a company will bring in a well-known consultancy to tell them what to do. And the consultants will do just that, showing how the company is currently doing so many things wrong, not following the latest management theories, and not using the latest technologies. They will then lay out how the company should alter its work flows, change its project management structure, and apply integration technology as a silver bullet to solve all their woes.

What people in this situation do not realize is that the company that hired them obviously knows what they are doing or else they would not have a budget to hire a team of expensive consultants. Also, that no one knows their own business better than the people running the business day-to-day. When companies look to integration, they are not actually looking to fundamentally change how they work. They are looking for help in identifying inefficiencies that can be solved by automating certain processes and replacing manual, duplicate data-entry with reliable, automated processes. The non-automated processes that are currently in place are not in and of themselves terrible, but they could be improved if someone who knew integration asked the right questions.

To this same end, the integration team needs to understand that the integrations are not only about communications between data systems, but are first and foremost about communications between individuals. It is true that an accountant should not be making decisions about project scheduling, and that a project scheduler should not be making decisions about the chart of accounts. However, each should understand and respect the point of view of the other. In this respect, the role of integration consultant is less that of a dictator, and more that of a marriage counselor, or an orchestra conductor.

In a well-run integration project, all stakeholders involved in a project should feel that their needs and concerns are being met, and that the integrations are helping them all to make the company and its projects successful.

P6 and ERP integration is not rocket science. Yet if you expect to hire top-notch business gurus, take their advice, and then hire a kid off the street, or your brother-in-law working out of his garage to implement your business-critical integrations, then you do not appreciate the complexities involved, and are in for a world of suffering. The relatively accessible APIs of both P6 and the Oracle ERP systems make it technically fairly simple to integrate data. Yet this also makes it quite simple for the insufficiently careful person to completely ruin the systems upon which your company relies. Anyone who has the power to send data into your systems should also have experience doing such work and a healthy professional background working with both systems.

Make sure that the person who is ultimately responsible for your integrations is in constant in-depth communication with both your ERP and P6 system owners. Make sure that they understand how the integrations work, and the possible impacts the integrations will have on both ERP and P6 systems.

We mention these cautionary tales not because we believe that integrations are problematic, but because we know that properly implemented integrations can have a tremendously positive impact on a company.