Integration overview
Integration is one of those words that means different things to different people, and therefore usually winds up with a bad reputation. In this appendix, we have a very specific meaning of integration. It is the set of processes that exchange data between P6 and one of the three Oracle ERP systems.
ERP stands for Enterprise Resource Planning. If you think this sounds a lot like P6, you are right. But P6 and ERP systems have different origins and end-goals. P6 grew out of construction and engineering scheduling, while ERP systems generally grew out of accounting and other processes and systems used to run a business. Such systems include components for:
Accounts Payable for paying vendors, suppliers, and subcontractors
Accounts Receivable for being paid by customers
Human Resources for managing employees
Payroll for paying employees
Address Book Management for tracking other people and businesses
Contract Management for managing the terms and deliverables of contracts
These systems are fairly generic across companies. Your corner bakery needs Accounts Payable, as does your neighborhood bank and your national rail line. There are many such systems out in the world, each being popular in some subset of industries. Among the top ERP systems worldwide are the Oracle Big Three: JD Edwards, PeopleSoft, and E-Business Suite. Their main competitor at the top tier is SAP. These are the ERP systems used by most Fortune 500 companies and by many governments. These systems are designed to handle massive amounts of data with thousands of simultaneous users.
Below this level are a plethora of ERP systems, including Timberline, Lawson, MRI, and Microsoft Dynamics, all the way down to Quickbooks. And of course, many companies, large and small, run their businesses with a disparate set of home grown systems.
Besides the ERP systems, there are also domain-specific applications that perform some of the functionality of ERP systems, but in a more focused manner. One example would be Maximo, which is a widely used Work Order management system, or Hard Dollar, used in project estimation.
Integration benefits
For integrations between P6 and ERP there are often two points of view involved:
Project Management sees things at the project level, in terms of delivering the full scope of the project on time and within budget
Accounting sees the project as a cost center, where the dollars allocated and spent need to be accounted for accurately, often in compliance with government regulations and Generally Accepted Accounting Principles (GAAP)
A few of the concerns of Project Management versus Accounting are listed in the following table:
|
Project Management |
Accounting |
|---|---|
|
|
Often, companies may treat their Project Management and ERP systems as two completely independent entities. And given the level of a specific company's process maturity, this may be the right approach. However, integrating systems can bring about a number of benefits, including:
Enforcing best practices
Ensuring data integrity
Scaling to a large volume of projects
Enforcing best practices
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.
Ensuring data integrity
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.
Fewer people handling more projects
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.
Integration pitfalls
Integration is not trivial, and there are a number of pitfalls to avoid.
Over-analysis
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.
Imposing external culture
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.
Underestimating technical skillset
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.
