How to Realize the universality of project management software

Projects are inherently different. In actual projects, there are large differences between projects due to many factors. Especially after the project contracting system is implemented, even different projects of the same company with the same professional nature and scale may be very different. The focus of the project is usually determined by the project manager and the project chief engineer, some pay attention to technology, some pay attention to materials, and some pay attention to costs. Therefore, it is difficult to create a "finished product" to meet the needs of most projects.
To this end, let's analyze where it is difficult. I personally think there is a dilemma: 1) Permission mechanism; 2) meeting the management philosophy.
1. How to satisfy the management philosophy?
Currently, project management software integrates transactions and analysis, while transaction processing meets the needs of daily transactions, and analysis is managed by managers.
Transaction processing is actually the easiest way to achieve universal. For example, material management, Progress Management, and quality management are similar to large and small projects. The difference lies in the data volume.
The analysis process is different. This is the key to meeting the management philosophy. It is hard to imagine that hundreds of millions of large projects and hundreds of thousands of small projects have the same management mode.
When transactions and analysis are mixed together, project differences will lead to huge system differences and the reusability of system modules will not be too high.
Therefore, in my opinion, the first step is to set up a separate transaction processing subsystem and a separate analysis subsystem. Even so, the analysis system is difficult to achieve general purpose, but the software reusability and scalability are greatly enhanced.
2. Permission Mechanism
Transaction systems are commonly implemented. There are not many problems with transaction processing, and process management is now easy. The problem lies in permission management.
Permissions are divided into coarse-grained and fine-grained permissions. Coarse-grained permissions are class-level, so there is not much problem in implementation. Fine-grained permissions are instance-level and bound to specific businesses: for example, some require contract makers R1 to delete contract C1, while others require financial section chiefs R2 to delete contract C1, there must be a process for deleting a contract. This type of permissions closely related to specific services cannot be customized in use, or even unpredictable.
3. Basic Business Platform
We must face up to the two problems above: the complexity of the analysis system, the close correlation between the fine-grained permission mechanism and the business-these two problems are basically unsolved, so only solutions rather than products can be implemented.

To achieve this goal, we will refer to the fashionable concept: basic business platform. It can be considered that the basic business platform is a public component + internal script + Interface (this understanding is correct or not ). We use it to work together with solutions, instead of using advanced languages for programming. The script is the adhesive, which is also the most difficult to implement. (As SAP does .) I always think that this may be the final solution.