Corporately managed systems and Process Software

Published by Graham Foss on

Corporate Management Systems

Even in occupations that are not directly to do with computers, the chances are that most people have interacted with CMS software or ERP (Enterprise Resource Planning) software of some kind as part of their job, whether it is filling in timesheets, stock reports, invoices and such like.

Anyone that has been around industry and manufacturing for any significant amount of time will have seen literally dozens of different computerised systems for work logging, permit tracking and fault recording. Those that work in IT or Software Engineering may have helped develop some of these systems themselves, for both internal use by their company and for external use as a product.

Throughout any career in the modern world an individual will be expected to interface with multiple and various forms of CMS software, Timesheet or Work Logging software, QMS (Quality Management System) software, ERP (Enterprise Resource Planning) software, CRM (customer-relationship management) software and any combination of the above.

There are a lot of terms, a lot of acronyms and a lot of jargon, but put simply these are systems for recording, tracking and reporting on data. CMS and ERP software tend to share common features and have generally similar interfaces. Some may be small, in-house or open source, while some may be fully featured software packages rolled out across an organisation globally. They all often have the same issues around usability and adaptability.

Larger organisations may use multiple different software packages across different sites for performing the same or similar functions and they may not always interface to each other smoothly or at all.

Things that CMS does well

Compliance management, Configuration Change Management, Disaster Recovery Solutions

Well maintained CMS and ERP software, planned and targeted correctly, and utilised by well-trained users will bring many benefits to a business. A good CMS will speed up repetitive activities, help to integrate processes and organise data. It should allow better communication between users and offer a common interface.

For management it should offer metrics and analysis that aids the answering of business questions and monitors targets and KPIs. CMS software can also manage inventories and workflows, record customer interactions and speed up decision making. A good CMS should also aim to reduce duplication, speed up reporting and reduce errors.

All software systems, including CMS and ERP have been moving towards the Cloud in the last decade, with data stored on one or more servers and accessed through thin clients or web based interfaces. In tandem with this has been an increased use of mobile devices. Technology is constantly shrinking and getting faster which has led to users of CMS systems being able to access them anywhere, not just at a desk in their office.

Some systems have also added social media functions. Ranging from simple personnel profile pages all the way through to full blown social network applications that include timeline posts, blogs and liking/sharing functions.

Finally, larger organisations may attempt to implement two-tier systems, tier 1 being at the corporate global level and tier 2 for smaller locations or to address specific functions.

CMS and Process Software

There are many instances of large organisations using multiple different types of CMS and ERP through no co-ordinated plan, but simply because this is the system that has grown up over time.

A CMS’s primary function is to record, organise and interpret business critical data, and for companies who have already spent a good deal of money for an integrated CMS or ERP the temptation to deal with process software within it can be overwhelming. There are good arguments for doing so in many cases, but this is generally not what it was designed for and problems can occur.

It is next to impossible to get departments across a business to use a CMS in the same way, or even users in the same department, when the system being used to take and store backups is not specifically designed for this purpose. Individuals will inevitably start using work arounds to suit the actions that they need to undertake.

CMS software that routinely handles documents and reports may not the best place to store software, particularly when there are very large files involved. It is also unlikely to have all the version tracking and file checking functions that are required for cyber-security and efficient disaster recovery.

CMS may also be too slow and cumbersome for some users’ needs when it comes the fault tracking of software. If a CMS already has a process in place for the tracking of faults in plant machinery, this may at first seem like the best place to also track software faults, but it will almost certainly decrease efficiency and lead to users working around the system or abandoning it all together.

Case Study

A successful industrial company, heavily automated and computerised, used a combination of COTS (commercial off the shelf), bespoke and in-house built software to operate its machinery and processes.

Going back for decades, backups had been taken of their automation systems’ software (PLCs, SCADA systems etc.) and stored in a fire safe located in the bowels of the main building. Once the fire safe became full, disks were stored in various desk drawers and later, with the advance of technology, network drives.

Backups stored on the network drivers were lost multiple times, usually during major IT upgrades, and had to be replaced with a new round of backups taken from the plant. In addition, backups were in constant danger of being deleted off the drives in error by untrained staff.

A new CMS was introduced to the company in the mid-2000s. It was decided not to store backups in it, other than new configurations and executables. Even this, however, was handled in a rather haphazard way, as the new CMS was not designed for the specific needs of software version control.

Much to the chagrin of the engineers involved, the final solution was that software was developed using one system for configuration management, another separate system for fault tracking, a third system for storing the new software (the CMS), a fourth system (network drives) for storing plant backups and finally a fifth paper based system for out-of-hours support.

It was the work of weeks to get a new engineer up to speed with the Byzantium twists and turns of the process which led to inefficiency and frustration for all involved. Add onto that the fact that different departments, locations and regions all had their own ways of doing things and some regions missed out parts of the process altogether.

However, the new CMS was a huge success in all other regards and had a great positive effect overall on efficiency, control, recording, and reporting across the company. Process software control was little more than a forgotten minor annoyance to upper management.

This set of affairs continued for many years, but things finally came to a head when an upgrade project in a safety critical area of the plant went so badly wrong that it had to be abandoned. It was discovered that the processes and procedures in place for producing, managing and testing the software were not sufficient to meet the needs of the SIL (Safety Integrity Level) requirements of the planned upgrade. It took a long time for the company to even understand the nature of the problem that they had and an even longer time to fix it. 

As is often the case, the scale of the company’s problems was not known until something had gone wrong.

The Asset Guardian Solution

Server Hierarchy Diagram for the AG Sync™ Model

CMS software, while being great at what it does, is not the place to perform standard-compliant backup taking functions. It will surely lead to data loss, non-conformities and inefficacy. CMS software is also not the best place to keep software in the event of Disaster Recovery.

Asset Guardian’s primary function is the safe and secure storage of process control software. Asset Guardian is compliant to industry standards and can be used as part of a Business Continuity Plan or Disaster Recovery Plan. It can also function as a CSMS (Cyber Security Management System), can be used across multiple sites and be accessed with a thin or web client securely from any location. Asset Guardian has fault and change request features as standard, fully integrated into the software version control functions. It can be customised to meet specific workflow requirements and the interface may be modified to suit the preferences of individual users. Online training is available so that all users have access to all the training they require to use Asset Guardian to their best advantage.

To download the PDF version, click here

If you would like any further information on Asset Guardian, please fill out the contact form below and a member of our team will be in contact with you. 

Written by Graham Foss. As one of AGSL’s team of Technical Consultants, Graham Foss is responsible for implementing the company’s product development and technology strategy. Before joining AGSL in 2016, Graham was employed for 12 years as a lead software engineer at Aker Solutions Subsea Ltd, where he worked on projects in the North Sea, North Atlantic and Norway. Graham holds a degree in Computing from Edinburgh’s Napier University in Edinburgh, where he graduated with distinction. A Chartered Engineer, he is a member of the Institution ofEngineering and Technology (IET).