60
December
2014
HYDROCARBON
ENGINEERING
of dollars, will be based on what assumptions are established
here.
Creating an optimal workflow
During this process it may quickly become apparent that one
is developing a workflow that may not align with current
work practices, it may even seem like a fantasy, but that is
OK. If one is going to invest in a plant design or engineering
software solution, would it not be best if, instead of the navel
gazing and picking apart everything that is currently done,
one comes up with a list of things that one wishes it to
achieve?
For that a workflow needs to be identified that will give
the best chance of selecting the right tool. That workflow will
likely not be the one that is currently employed, but one that
would be an optimal workflow for the workgroup(s). Software
will not automatically make up for bad practices, but
deploying the right solution can make good practices better,
even if those practices are not even part of current work
processes!
If after the above exercise one discovers that best
practices are not currently employed and workflow is less
than optimal, one may feel that this method of defining what
one wants from a solution may be too risky. If that is so
please consider that defining what success will look like will
put evaluators well ahead of the majority of people that are
looking to optimise their plant design and engineering
processes. It is easy to fall into the trap of just wanting things
to be better than they currently are, but really is that enough?
If that is the case, it really does not matter which solution
one settles on, because the truth is that very few solutions
are so bad that they would not give you some degree of
improved performance.
Perspective, reality and fear
It will not be a surprise to hear that, given unlimited funds, and
time, software can be made to do almost anything that may
be required, but the reality is that neither resource is
unlimited, and every company needs to determine what they
absolutely must have, what would be nice to have, and what
they can develop workarounds for and, yes, what they can do
without.
The author has gone through many sales cycles, as part of
a purchase team, in sales support and also as a salesperson,
and one thing that is the worse thing that can happen, at any
point of the sales cycle, is when fear, on both sides, sets in. Do
not get the author wrong, a good amount of skepticism on the
buyer’s side is healthy, and concern on the seller’s side that
they are hitting all of the buyers main points, is also to be
expected. Even so, fear on the buyers side often comes from
not being sure that they are giving more than they will be
getting and that the solution will not measure up to the
salesperson’s promises.
As fear enters the equation the focus devolves into the
mitigation of risk and concentration on features. And with
that, gone are thoughts of the great things that the software
can do for the buyer and how it can make the buyer’s life
better. The thing is that the process does not have to be
fearful if the buyer can, at any point in the process, be sure
that they are getting a good deal, that they will see value in,
not only the software, but the long term relationship that the
implementation of the tool will entail. So as long as value is
assured, and is the continual focus on both sides, fear can be
replaced with focus.
Defining value
If one has read this far one may feel that something is missing,
and that this article, that seems to be dismissive of current
work practices and workflow, to help determine what a client
wants the software to do, is foolish or, at best, just plain naïve.
But there is actually great value in establishing current
workflow and it plays a large part in calculating the value of
implementing an ideal system, and removing the fear of
moving forward.
As mentioned earlier, current workflow should not be the
main factor in deciding what a client wants to achieve with a
software solution. But when used in conjunction with a
specific optimised workflow it is a great way to help
determine the following:
n
n
Inefficient work practices.
n
n
Where the software can help.
n
n
Where the software cannot help.
n
n
Team skill level.
n
n
Training needs.
n
n
Implementation requirements.
Value is the delta between where one currently is with
one’s current workflow, practices and tools and when
compared with where one wants to be with the solution
installed, and with a specific optimised workflow in place. ROI,
on the other hand, is the difference between the deployment
costs and that value.
So should the cost of the software be ignored? Well no,
not at all, it would be deleterious to go into this process
Figure 1.
Simplified piping design workflow.
