Clover SA (Pty) Ltd - IS³ | AVEVA Select Partner
Clover SA (Pty) Ltd
Customer StoriesFood and Beverage

Clover SA (Pty) Ltd

By 20th Jul 2017 May 23rd, 2021 No Comments

Clover SA improves software project development life cycle through standardisation and simplicity

FOOD & BEVERAGE

Goals

  • Standardised project development
  • Rapid implementation
  • Reduced development costs
  • Implementation simplicity
  • Improved operator decision-making

Challenges

  • Formalising a process flow and software structure to allow for the documentation of the process and to ensure the desired result is achieved

Results

  • Clear objective and predictable results
  • Involvement of multi-disciplinary parties in the design phase
  • Clear mandate for the software developer(s)
  • Measurable results
  • Easier and predictable commissioning
  • Faster implementation
  • Repeatability with other projects
  • Mechanism for continuous improvement by incorporating new technologies and approaches
  • Ability to outsource software development to third parties

Solutions & Products

“In my view, software standards should not only simplify the work of the developer but also provide structure and simplicity throughout the project life-cycle.”

Francois Theron, Engineering Manager: Electrical and Control Systems, Clover SA

Any of Clover SA’s numerous facilities throughout Southern Africa

In a dynamic organisation such as Clover SA, automation systems standardisation can deliver great value in project implementation, maintainability, and operability.

The successful implementation of these standards ensures seamless integration with all stakeholders in the system lifecycle with significant improvements in project and development costs as well as project execution time and commercialisation. Elegant design principles at the visualisation level have a positive impact on training, project hand-over dates and help operational staff react to abnormal conditions quickly.

“When I started with Clover, I made it my business to visit a number of our 14 sites in South Africa and Botswana and discovered something of concern,” says Francois Theron, Engineering Manager: Electrical and Control Systems. “Although Clover has extremely competent and dedicated people who work in the automation space, they worked in complete isolation of one another.”

Theron found that adherence to project and implementation standards varied from absolute to less than perfect and that anything in between was subject to time, money and production-consuming experimental trial and error. This prompted an initiative to define the best possible implementation methodology and standards for Clover’s many projects that would also help the company achieve its business goals.

Business objectives

  • Rapid commercialisation – Being a very dynamic company with the constant release of new products, flavours, etc., Clover needs to beat their competitors to the supermarket top shelf by going from concept to product as quickly as possible.
  • Increased complexity – Consumers are constantly demanding more complex products as well as an ever-increasing range of product choices which leads to a huge variety of products that must all comply to strict quality standards. And this all has to be handled by the same infrastructure.
  • Increased asset utilisation – This means decreasing downtimes and changeover times to cope with a growing product range.
  • Operator efficiency – Operators need the right assistance to make their lives easier and therefore more effective
  • Process and production information – The HMI screens of the past are no longer sufficient. Today, operators want contextualised, real information that helps them make the right decisions quicker.
  • Cost control – Always a major consideration in spite of having to do more.

If this sound familiar, you’re doing it wrong

A typical life cycle for a software development project to address an industrial automation need within a company may go something like this:

  • Requirements definition – This usually comes from an end user or process engineer and is often described in very technical terms or not very well at all. “But quite often, the brief may have originated from a quick phone call,” says Theron.
  • Design – This should be the domain of the best available engineering knowledge but a lot seems to get lost in the translation between requirements and design as this appears to be one of the primary gaps in the exchange of information in the implementation chain.
  • Development – With a somewhat sketchy brief, the software engineer writes code based on his understanding of what should be done but not necessarily with the same understanding of the needs of the industrial automation world of his clients.
  • Testing – With the results as unclear as for their requirements, who’s to say what works?
  • Commissioning – This is usually an iterative process where change requests are the order of the day but eventually, the solution works the way it was intended – but maybe not.

After a while, the client decides that the results would be that much more useful if A,B and C were included – but wait, weren’t they part of the original spec?

If not, they were surely implied. Someone must be blamed and the software engineer seems to be the most likely target because he couldn’t read people’s minds and be all things to all engineers.

Doing it right

“If I give someone a block of clay with the instruction to make a model racing car and some time later I’m presented with a clay racing car, what is my recourse if it’s the wrong shape, colour or anything else I had in mind? None.”

According to Theron, the answer to successful project implementation lies with breaking down the task into standard building blocks that, when assembled, will yield the desired result. “The responsibility for the granularity and detail with which I specify how my lump of clay must result in the kind of racing car model I’m looking for lies with me. But after all that, the final product may still need some work.”

Comments have been made that outsourcing software functionality to third parties is simply not possible in industry because processes are so proprietary. “This is the kind of thinking that I want to challenge,” says Theron. “A functional software specification must give the intended result irrespective of who generates it and it starts by defining standard building blocks necessary to achieve that result. It’s through this increased granularity and clarification that we can get the functionality we need.”

By using this standard framework and documentation flow, the project lifecycle now looks like this:

  • Requirements definition – The process engineer now has a structure to describe the process in terms familiar to everyone involved.
  • Design – Because everyone speaks the same language, the design review phase is that much easier as the standards provide the framework for detailed design and even allow for the inclusion of inputs from multi-disciplinary sources such as quality and control personnel, HAZOP, HACCP and others. “This allows us to do much of the design documentation up-front,” says Theron. “Without this process, we would be locking up our IP in an inaccessible black box. Instead, we now have a document without this IP component and that anyone can interpret.”
  • Development – The software engineer now has clear guidance as to the desired result and the requirements that led to it.
  • Testing – This is no longer a haphazard affair as what the software engineer delivers can be measured against the documented functional requirements.
  • Commissioning – Deploying the solution becomes far more predictable and easier. There are no surprises because all involved are familiar with what was specified and they now see it in practice.

“Some tips and considerations to bear in mind when defining standards include the use international standards wherever possible – we’ve found ISA 106 to be most useful and concise,” says Theron. “Something else to bear in mind is that standards are not static. They need to evolve to incorporate new technologies and modern automation strategies such as Situational Awareness. It’s important to keep two sets of documentation – the design document and the implementation guide which can be given to a system integrator to ensure that your standards are maintained. And lastly, because technology allows us to get lost in details, a guiding principle is to keep things as simple as possible.”

Benefits of standardised software project development

  • Clear objective and predictable results
  • Involvement and consensus of all concerned parties in the requirements specifications
  • Involvement of multi-disciplinary parties in the design phase
  • Clear mandate for the software developer(s)
  • Measurable results
  • Easier and predictable commissioning
  • Faster implementation
  • Repeatability with other projects
  • Mechanism for continuous improvement by incorporating new technologies and approaches
  • Ability to outsource software development to third parties without compromising the company’s intellectual property while ensuring they conform to set standards

About Clover SA

Clover is a leading and competitive branded consumer goods and products group operating in South Africa and other selected African countries with core competencies in the production, distribution and sales of dairy and non-dairy beverage consumer products

Clover delivers product to approximately 14 913 delivery points across South Africa. The Group was converted from a co-operative society into a public company in 2003.

The company is located in Queensburgh and Pinetown in Kwa-Zulu Natal and is a household favourite with its milk products as well as its range of juices (Tropika, Krush and Nectar). Clover also produces Amasi and Super-M flavoured milk.

Clover was voted the most reputable company in South Africa for 2016 and is recognised for the attention paid to the delivery of healthy products.