58
December
2014
HYDROCARBON
ENGINEERING
make sure of is that what one purchases is no worse than
what anyone else has purchased. Every company’s needs are
unique and it is important that the unique challenges that
drive a business are what buyers should focus on.
‘I was sold a lemon’
Over the years, the author has often been in sales situations
where the buyer has gotten it wrong.
However, when the buyer gets it right typically both
buyers and customers arrive at a long term relationship that
benefits both parties.
But what about the seller, do they not have a
responsibility? Can they not also be at fault? Well, yes of
course that is often the case, and a substantial factor in
customers settling on the wrong solution. Ultimately though
‘buyer beware’ defines the final responsibility, so it is the
buyer that needs to ensure that they get what they really
need. But how is that best done?
Features, features, features
Buyers should not get into the habit of selecting software
based purely on features, or worse still the number of
features listed. It may be a surprise but most users deploy
only a small fraction of what a software solution can deliver.
So it would be best for the buyer to establish, as early as
possible, what that fraction actually is and if they can also
leverage some of the other capabilities that are so often
overlooked.
So, do features not matter? Well they do because they
are a means to an end. But if buyers want something that is
going to hold them in good stead for years to come they
ought not look at just features, but on the value of what the
tool can do for them.
So how can value be measured? It is all very subjective,
right? Well, here is a novel concept, how about using $, £,
e
,
¥ to measure value? Return on investment (ROI) calculations
are a good way of doing this, but if one really wants to get a
good feel of the day to day benefit of a proposed solution,
why not start with work processes?
Workflows
The bottom line is that software, in and of itself, is no cure
for an inefficient or inadequate workflow. Plugging a plant
design or engineering solution into a flawed work process
will not ensure that one will deliver optimal results.
In this process of picking, not only a solution to do a
job, but also a multi year partnership, one is much better off
formalising work processes and practices before starting to
look at software. Work processes are the best way to work
out where one is (one's starting point) and to identify where
one's best opportunities for improvement are (one's
destination).
So if one is reading this and saying, ‘Of course all
companies should have this!’ and most would agree, but the
sad fact is that the majority of companies seldom have
anything that they can point to that codifies how they work
and what they need to do to get their work done.
A simplified workflow for the creation of plant design
deliverables is shown in Figure 1.
In plant design and engineering most workflow examples
follow something close to this and, truth be told, most
people working in engineering firms would be able to
come up with something similar and in a relatively short
time. But for design and engineering companies or
workgroups, who are attempting to define what may be
needed from a software solution, it is not what is
currently done that should drive the buying decision, but
what needs to be done, or produced, that should drive it.
The start of an optimised
workflow
If a ‘destination’ is truly to be identified then something
else needs to be quantified, and it is so simple that it is
surprising that more people do not do it. It is the
procedure of defining stakeholder requirements and
deliverables at each stage of the process by asking:
n
What has to be produced?
n
Who is the creator of the required deliverable?
n
What the creator needs before creating deliverables?
n
How is that deliverable created?
n
Who it is to be consumer of what is produced?
n
What information the consumer needs from what is
produced?
n
In what format is that info best delivered?
By identifying the above one is trying to define the input
that each stakeholder needs to create the deliverables that
are required of them by those downstream of them. By
doing this for every stakeholder, in a chain of influence, one
can begin to see exactly how things measure up at each
stage of the process. The idea here is to not only layout a
complete chain of requirements and deliverables for
immediate areas of responsibility, but to identify how what
others require can be best optimised for their use.
Workflows: Do not go it alone
A few months ago, the author and six others got together to
define the workflow of someone doing a form of pipe stress
analysis, using Intergraph® CAESER II®, that incorporated the
inclusion of finite element analysis (FEA) to determine the true
stiffness (stress intensification factor (SIF)) of branches using
Paulin Research Group® FEATools
™
. Each of those in the group
had piping design, pipe stress analysis, or industry experience,
and some over 40 years. If this assignment had been given
separately to each individual then each person may have
finished the task in 30 - 60 mins.
The surprising thing is that, at the beginning, none of those in
attendance agreed on either the stakeholder requirements, or
the basic workflow, or even the software workflow. It eventually
took five hours to work out the stakeholder’s requirements, the
workflow without the above software and the workflow
including the above software, and how that final workflow could
improve a company’s efficiencies and quality of output.
The point here is that having the ‘brightest person in the
room’ work all of this out is OK, as long as there are other bright
persons in the room that are engaged in validating any
assumptions any individual may make. When one thinks about it
it makes sense as buying decisions, that may involve millions
