]project-open[ is capable of serving diverse customers in many different business sectors. In order to provide this capability, ]project-open[ includes a number of mechanisms to "configure" (adapt without changing the source code) the application for the specific customer. This page lists some of the most pronounced variation of ]project-open[ that have been the most frequent in our customer base.
Project Management Office (PMO)
Formal PM in larger Organizations |
Embedded
"Isolated PM" on Department Level in large Organizations |
Projectized Organization /
Agency Type |
PM in IT Service Organizations
|
Industrial / Workshop
|
Other
|
|
INDUSTRIES |
|
|
|
|
|
|
TYPES/CATEGORIZATION |
|
|
|
|
||
CHARACTERISTICS |
|
|
|
|
|
|
FOCUS |
|
|
|
|
]project-open[ can serve organizations from 3 to 3.000 "Employees". Employees is a broad term, since we have to include all freelancers, contributing customers, and infrequent or one time users. Clearly, larger organizations need to formalize processes a lot more then their smaller counterparts - functionality that is essential for large customers tends to be perceived as unnecessary overhead by smaller ones. Individual customer needs should determine the final look of ]project-open[, there is no set out-of-the-box pre-made installation for any industry sector or company size.
]project-open[ can serve customers in different business sectors:
To deal with these different business sectors, ]project-open[ includes a number of add-on packages to the "base" that can deal with the specifics of each business sector.
These specific add-on packages can extend the ]project-open[ "core" using "Plugin Portlet Components", DynFields, DynViews and Menus. This way, they don't add additional complexity to the "core".
Should a normal Employee be able to see the full customer list of a company? In some companies (in particular ones with high fluctuation and a low barrier of entry) employees should only be able to see their projects and their customer contacts, while by default companies should be as permissive as possible to reduce overhead costs for authorization services and to improve knowledge flow within the company. Basically there is no correct answer, there is only what is best for the customer, and security and trust decisions should be made on a case by case basis, after fully understanding the company and their intended use of ]project-open[.
A member of the [ERP-SELECT] mailing list once put it like this: "An ERP system is merely a place where some people can store data and other people trust that this data are correct". However, companies vary a great deal with respect to employees trusting each other to enter "clean" information into an ERP system.
Roll-outs in "coherent" companies are usually very difficult, because every employee wants to make sure during the evaluation period that the system will be able to capture his information well. While the first couple weeks and the roll-out experience in general might plant early doubts and frustrations, this is only temporary and operations usually go very smooth afterward. This is because the Users had specific expectations on what they would be using ]project-open[ to do, it just took a transitional period in order to learn how using a new system. The contrary is the case in less coherent companies, when customers realize that either their requirements were not complete, or that they only now fully understand their automation processes, but only after a quick and painless roll-out of a product that has done little to add value to their company. Not to say that an easy or hard roll-out experience will be indicative of future success with ]project-open[, but be aware of these concerns and recognize them when they happen.
]project-open[ is designed to deal with these differences by means of its default "flexibility" i.e., ]project-open[ in its default configuration provides users with relatively little restrictions on how to enter data and how to structure data. This default configuration is useful for smaller companies and for a quick roll-out at larger organizations. However, large "coherent" companies will typically ask for additional rules (data checks, workflows) after the initial roll-out and "incoherent" companies will need special reports in order to deal with partially inconsistent data.
This describes the larger context in which ]project-open[ customer organizations work:
In order to deal with this type of variability, the most important tool is the capability to disable portlets and menus in ]project-open[, plus there are several add-on packages (auditibility extension, cost-center permissions, SAP-import, ...) in order to reamain conscincious of a business's "autonomy".
Most obviously, language is one the most important difference between countries. Please see the localization section for details. Other differences include:
]proejct-open[ deals with languages using its localization subsystem and is developed using American English as the base language. Trust and coherence are handled as detailed above, and the presentation of invoices and quotes can be configured using "templates" in the financial system.
Calle Aprestadora 19, 12o-2a
08902 Hospitalet de Llobregat (Barcelona)
Spain
Tel Europe: +34 609 953 751
Tel US: +1 415 200 2465
Mail: info@project-open.com