Written by: Theko Letsie (Pr. Engineer & Head of COMOS implementation at FrequencyShift)

As one of the early adopters and users of COMOS, it has become apparent to us that COMOS can deliver on all the promises Siemens has promised. However, most EPCMs seem to be hesitant in adopting COMOS to meet their Clients’ needs. In our research at FrequencyShift, we have identified some challenges facing the implementation of COMOS in the African market. In this article, we will unpack 12 challenges that we have identified that slow down the full implementation of COMOS within the African market. We will also examine the impact of these challenges as well as explore our ideas of how we can overcome the challenges to realise a future in which every engineering professional enjoys the full benefits of COMOS design.

1. The African market is still in the early stages of the COMOS learning curve.

The adoption of COMOS in the African market is still in its infancy. As such the engineering design industry must go through a learning phase. As we learn more, we become more experienced and therefore can visualise the endless possibilities with COMOS. The more we use COMOS, the more capabilities we unpack, and envision the extent of what is possible with the design software. It is only after the African market gets over the early learning curve stage that we will fully access its full potential. Meanwhile engineering design companies that have adopted COMOS do not yet fully realize their Return on Investment. This, in turn, leads to Design and Engineering companies preferring to stick with traditional design tools.

2. COMOS implementation can be complicated & complex.

For beginners, COMOS can be complicated due to the visual basic scripting that is still needed on new client databases. COMOS has multiple ways projects can be configured and executed, which introduces complexity for basic users of the software. Object properties can also be defined in different places and as a result, flow of information between different modules (such as Process, Electrical and Instrumentation) can be inconsistent. It is through all these complications and complexities that team efficiency within an organisation can be tested as Cross-departmental nature of COMOS can expose poor team dynamics within a project. 

3. Single Discipline Engineering Companies & Projects.

A majority of past and present small to medium sized projects are single discipline projects. Similarly, some engineering companies are single discipline companies. As a result, designs keep being carried in siloed legacy systems. With more COMOS design service providers and targeted training and support, various projects (though they made be single discipline projects carried out by single discipline engineers) can be carried out in COMOS.

4. Database templates and configurations vs clients’ standards and specifications.

The new COMOS industrial database is not yet populated with templates that match clients’ or industry standards and specifications. Database structures that were built in the earlier classic database (cDB) were not carried over to the new COMOS industrial database (iDB), early adopters of COMOS have found it lacking in capabilities, whereas it is through making use of the software more that we can uncover the full capabilities. This does not, however, address the immediate problem that it takes time and money to get database templates configured, as this is a skill that most engineering designers and engineers have not yet developed. 

5. COMOS Capabilities not yet fully understood.

As the African market is still in the early learning stage for COMOS, a large portion of the plant engineering software solution’s capabilities and features are not yet understood. More worryingly, a sizeable portion of COMOS features might hardly ever be used. Therefore, COMOS capabilities are not appreciated, and the accompanying benefits not realized.

6. Low COMOS customer base

In Africa, there are a few customers that have adopted COMOS as their engineering and design tool. This low number of COMOS requiring customers gives little or no incentive for most engineering and design companies to invest towards COMOS implementation in their organisations. 

7. Inadequate COMOS Support

There are very limited COMOS support vendors in Africa, which means at times these vendors are stretched to support projects. The impact is that it takes longer than acceptable on some projects for COMOS issues to be resolved and this in turn leads to COMOS not being considered for fast-pace projects.   

8. Underdeveloped COMOS Ecosystem

The African COMOS ecosystem is underdeveloped, with not enough COMOS implementation service providers, not enough projects that have COMOS as a pre-requisite, limited trained and experienced COMOS designers and limited COMOS support vendors. Consequently, there is limited sharing of COMOS knowledge between all the COMOS ecosystem members, there is slow development of COMOS solutions and general apathy towards the uptake of COMOS as a design solution.

9. Lack of Capable Resources

In its local infancy in the African market, there are not enough COMOS trained designers to get around on multiple projects at once, should a need arise. There are also not enough COMOS experienced designers should the need arise. There is a growing need to couple COMOS capabilities with industry experience with a different set of skills, interests, capabilities, and habits required for success in database and software-based design environments. If an organization decides to take on a COMOS project without a readily available COMOS resources, there are likely to be disastrous consequences on the project.

10. Paradigm Shift 

For some engineering disciplines, some engineers and some designers, a total integrated database design is a paradigm shift. Generation X engineers and designers are less likely to adopt COMOS as a new design package. As a result, the older generation of designers and engineers give little or no support to COMOS as an engineering design tool. This translates to little probability of COMOS being adopted as the preferred new design package.

11. Misaligned Expectations

From the onset engineering companies have expected the COMOS database complete with industry standards whereas COMOS vendors expect the database to be configured by its users. Furthermore, COMOS vendors expect to be compensated for any template developments whereas COMOS users expect the database to contain the required templates. These misaligned expectations further discourage users to embrace COMOS as it does not come without these frustrations. These challenges then lead to engineering companies being selective on the scope that is completed on COMOS while clients require the full COMOS capabilities to be utilized. These can lead to unplanned COMOS administration and support costs, unplanned project delays, and unmet expectations between industry players.

12. Capital and Maintenance Costs & Lack of Capable Resources

Getting started with COMOS can be an expensive undertaking. Setting up the COMOS database and application software requires secure and reliable IT infrastructure; this is costly. COMOS licenses are also relatively expensive. Moreover, securing the services of experienced COMOS designers can be time consuming and costly, while on the other hand the lack of experience with implementation teams can bring about unplanned COMOS support costs. This simply means that smaller engineering companies are not able to afford the upfront capital costs required to implement projects in COMOS. 

How do we overcome these challenges?

To overcome the challenges listed above we (all COMOS projects’ stakeholders – vendors, implementation stakeholders, customers, engineers, and project managers) would collectively need a varied approach on each challenge mixing and matching the various guidelines listed below:

• We need to allocate Time for the market to uptake COMOS.
• We need to invest in more Training and Support for COMOS.
• We need to develop a COMOS talent pipeline that takes beginners through detailed training to get them knowledgeable enough to catch up with their skilled counterparts quicker than is currently happening.
• We need to work towards improving the interaction between different engineering disciplines and enforce more interaction between the COMOS design teams and discipline engineers.
• We need to allow for suitable slack within project schedules for learning and uptake to take place.
• We need to ensure that smaller EPCs are supported for COMOS designs, by means of subsidies or loans, and incentivize EPCs adopting COMOS.
• We need to encourage and develop more COMOS implementation service providers.
• We need to develop more COMOS vendors to increase healthy competition and increase the COMOS support footprint.
• We need to nurture more COMOS super users / administrators and create a culture of allocating more resources and time to configuration and template development, so it is a thing of the past to worry about organisational templates before the start of any project. 

We need to carry out more industry awareness campaigns.