Communicate system organization ideas to 'laymen'?

Hi folks.

I'm in a bit of a pickle here, as I've been trying to sell a project
on process organization to somebody who only see day-to-day
tasks and impending deadlines, not strategic organization or
company survival.

The process is a 24/7 data processing line, that is working under
tight deadlines, where specs usually are 24 or 48 hrs from end of
survey to 99.9% finished product is to be available. The remaining
0.1% of finished product is, for all intents and purposes, adding
company-specific binders with logos and contact phone numbers
in the right places.

Today, this production process disorganized, in the sense that
there easily are 5-10 different software packages involved, each with
very little responsibility. For instance, items like navigation,
survey,
processing, reporting are subtasks of the project, and are handled
by different software packages. It is not unusual to to have one or
two additional software packages in some of these subtasks, to
re-format data or to cater for client's perticular requirements.

This process is very manual, in the sense that people are 'driving'
the process by selecting data through menus, invoking all the
processing tasks, starting and stopping software, etc.

The concept of 'scripts' or 'batch files' are totally foreign to
the people in charge, as they usually have background as
operators and technicians, and are not used to think in
terms of strategies or process organization.

Add to this that 'databases' are not known or understood, and
thus that all data are stored all over the place, in any format,
accessible to any operator to do what they want, you have
pandemonium.

I once did the numbers of counting the number of files generated
by the process and the number of manual interactions they
had to go through, and timed the average time needed for
each manual operation. I found that one must expect at least
on the order of 12-18 hrs of time wasted on manhandling the
data, per 24 hrs survey. Which leaves 6 hrs to actually process
the same data, if the deadlines are to be honored.

The processing line is chaotic and human operators are worn
down by the pressure and stersses. The fact that lots of this
takes place at sea, with no way to escape the job, maybe
bad weather etc, doesn't help.

Now, I have been trying to guide people into organizing the
data flow differently:

- Set up a database where all the data are to be stored
- Specify exactly what data formats are used where
- Have each application program communicate data back
  and forth to the database, and not to files
- Use scripts and batch files wherever possible
- Maybe write an overall data flow control application
  which runs the applciation programs sequentially on
  the data
- Set up automated status and reporting software to
  let managment see whic data are where in the pipeline
- Include specialized software to handle bottlenecks
  in the data processing

These kinds of things would remove all the non-essential
man-handling (operations not directly associated with
data processing), saving ridiculous amounts of time
and pressure on the crew.

The problem is that these pople know me, and know that
I'm able to handle the _data processing_bottlenecks_ that
cripple them. While those bottlenecks have to be handled,
they are at present insignificant compared to the general
mess. However, the people I talk with just don't see the big
picture I've tried to paint, about strategic organization of
the process and all the benefits obtained by reorganization.

I get feedbacks that "yeah, the bottleneck processing
is interesting but wee don't write in-house processing code.
Why don't you contact [the vendor of processing SW]?"

So at last my question: How can one communicate
these big-picture ideas to the potential clients?

I can see only one way, to implement most of the
functionality myself, and demonstrate with their own data.
But that would take far too long to implement, and would
likely not work, since the people in charge presumably
would see flaws in the details and not a sketch of an
efficient process.

Any suggestions?

Rune

On Tue, 24 Mar 2009 03:55:01 -0700, Rune Allnor wrote:

> Hi folks.
> 
> I'm in a bit of a pickle here, as I've been trying to sell a project on
> process organization to somebody who only see day-to-day tasks and
> impending deadlines, not strategic organization or company survival.
> 
> The process is a 24/7 data processing line, that is working under tight
> deadlines, where specs usually are 24 or 48 hrs from end of survey to
> 99.9% finished product is to be available. The remaining 0.1% of
> finished product is, for all intents and purposes, adding
> company-specific binders with logos and contact phone numbers in the
> right places.
> 
> Today, this production process disorganized, in the sense that there
> easily are 5-10 different software packages involved, each with very
> little responsibility. For instance, items like navigation, survey,
> processing, reporting are subtasks of the project, and are handled by
> different software packages. It is not unusual to to have one or two
> additional software packages in some of these subtasks, to re-format
> data or to cater for client's perticular requirements.
> 
> This process is very manual, in the sense that people are 'driving' the
> process by selecting data through menus, invoking all the processing
> tasks, starting and stopping software, etc.
> 
> The concept of 'scripts' or 'batch files' are totally foreign to the
> people in charge, as they usually have background as operators and
> technicians, and are not used to think in terms of strategies or process
> organization.
> 
> Add to this that 'databases' are not known or understood, and thus that
> all data are stored all over the place, in any format, accessible to any
> operator to do what they want, you have pandemonium.
> 
> I once did the numbers of counting the number of files generated by the
> process and the number of manual interactions they had to go through,
> and timed the average time needed for each manual operation. I found
> that one must expect at least on the order of 12-18 hrs of time wasted
> on manhandling the data, per 24 hrs survey. Which leaves 6 hrs to
> actually process the same data, if the deadlines are to be honored.
> 
> The processing line is chaotic and human operators are worn down by the
> pressure and stersses. The fact that lots of this takes place at sea,
> with no way to escape the job, maybe bad weather etc, doesn't help.
> 
> Now, I have been trying to guide people into organizing the data flow
> differently:
> 
> - Set up a database where all the data are to be stored - Specify
> exactly what data formats are used where - Have each application program
> communicate data back
>   and forth to the database, and not to files
> - Use scripts and batch files wherever possible - Maybe write an overall
> data flow control application
>   which runs the applciation programs sequentially on the data
> - Set up automated status and reporting software to
>   let managment see whic data are where in the pipeline
> - Include specialized software to handle bottlenecks
>   in the data processing
> 
> These kinds of things would remove all the non-essential man-handling
> (operations not directly associated with data processing), saving
> ridiculous amounts of time and pressure on the crew.
> 
> The problem is that these pople know me, and know that I'm able to
> handle the _data processing_bottlenecks_ that cripple them. While those
> bottlenecks have to be handled, they are at present insignificant
> compared to the general mess. However, the people I talk with just don't
> see the big picture I've tried to paint, about strategic organization of
> the process and all the benefits obtained by reorganization.
> 
> I get feedbacks that "yeah, the bottleneck processing is interesting but
> wee don't write in-house processing code. Why don't you contact [the
> vendor of processing SW]?"
> 
> So at last my question: How can one communicate these big-picture ideas
> to the potential clients?
> 
> I can see only one way, to implement most of the functionality myself,
> and demonstrate with their own data. But that would take far too long to
> implement, and would likely not work, since the people in charge
> presumably would see flaws in the details and not a sketch of an
> efficient process.
> 
> Any suggestions?

First, accept that perhaps you'll never get your target audience to see 
what you're trying to say.  Some people just aren't capable of seeing the 
forest for the trees; force them on a plane ride over the forest and they 
just get frustrated that the trees are too far away to see clearly.  If 
this is the case you may as well find a nice rock to give your 
presentations to.

Second, if this is a big corporation or a government entity, the layers 
of management who have a chance at changing this may be well above the 
layer of management that you're trying to convince.  If this is the case 
you may as well find a nice poodle to give your presentations to.  
Whether you want to accept this or go chasing higher levels of management 
-- I don't know.

Third, think of ways to present this that make sense in their domain, not 
yours.  E.g., if it's the ship's captain, ask him if faster engines would 
get him into harbor quicker when the problem is that it takes half a day 
to wait for a bridge to open -- then point out that in this case he owns 
the "bridge" and can do something about it.  Be ready to whip out an easy 
to read chart that shows the problem (this may be a good place for a pie 
chart, with "wasted time" as a nice big slice).

Fourth (this is a corollary to the second point), should you be talking 
to the guy's boss instead of the guy?  Or the boss's boss?  Can you get 
access to the right person, and can you do it without fatally pissing off 
the folks you work with?

Good luck.  I have had both successes and failures with this kind of 
stuff.

-- 
http://www.wescottdesign.com

On Mar 24, 6:55&#4294967295;am, Rune Allnor <all...@tele.ntnu.no> wrote:
> Hi folks.
>
> I'm in a bit of a pickle here, as I've been trying to sell a project
> on process organization to somebody who only see day-to-day
> tasks and impending deadlines, not strategic organization or
> company survival.
>
> The process is a 24/7 data processing line, that is working under
> tight deadlines, where specs usually are 24 or 48 hrs from end of
> survey to 99.9% finished product is to be available. The remaining
> 0.1% of finished product is, for all intents and purposes, adding
> company-specific binders with logos and contact phone numbers
> in the right places.
>
> Today, this production process disorganized, in the sense that
> there easily are 5-10 different software packages involved, each with
> very little responsibility. For instance, items like navigation,
> survey,
> processing, reporting are subtasks of the project, and are handled
> by different software packages. It is not unusual to to have one or
> two additional software packages in some of these subtasks, to
> re-format data or to cater for client's perticular requirements.
>
> This process is very manual, in the sense that people are 'driving'
> the process by selecting data through menus, invoking all the
> processing tasks, starting and stopping software, etc.
>
> The concept of 'scripts' or 'batch files' are totally foreign to
> the people in charge, as they usually have background as
> operators and technicians, and are not used to think in
> terms of strategies or process organization.
>
> Add to this that 'databases' are not known or understood, and
> thus that all data are stored all over the place, in any format,
> accessible to any operator to do what they want, you have
> pandemonium.
>
> I once did the numbers of counting the number of files generated
> by the process and the number of manual interactions they
> had to go through, and timed the average time needed for
> each manual operation. I found that one must expect at least
> on the order of 12-18 hrs of time wasted on manhandling the
> data, per 24 hrs survey. Which leaves 6 hrs to actually process
> the same data, if the deadlines are to be honored.
>
> The processing line is chaotic and human operators are worn
> down by the pressure and stersses. The fact that lots of this
> takes place at sea, with no way to escape the job, maybe
> bad weather etc, doesn't help.
>
> Now, I have been trying to guide people into organizing the
> data flow differently:
>
> - Set up a database where all the data are to be stored
> - Specify exactly what data formats are used where
> - Have each application program communicate data back
> &#4294967295; and forth to the database, and not to files
> - Use scripts and batch files wherever possible
> - Maybe write an overall data flow control application
> &#4294967295; which runs the applciation programs sequentially on
> &#4294967295; the data
> - Set up automated status and reporting software to
> &#4294967295; let managment see whic data are where in the pipeline
> - Include specialized software to handle bottlenecks
> &#4294967295; in the data processing
>
> These kinds of things would remove all the non-essential
> man-handling (operations not directly associated with
> data processing), saving ridiculous amounts of time
> and pressure on the crew.
>
> The problem is that these pople know me, and know that
> I'm able to handle the _data processing_bottlenecks_ that
> cripple them. While those bottlenecks have to be handled,
> they are at present insignificant compared to the general
> mess. However, the people I talk with just don't see the big
> picture I've tried to paint, about strategic organization of
> the process and all the benefits obtained by reorganization.
>
> I get feedbacks that "yeah, the bottleneck processing
> is interesting but wee don't write in-house processing code.
> Why don't you contact [the vendor of processing SW]?"
>
> So at last my question: How can one communicate
> these big-picture ideas to the potential clients?
>
> I can see only one way, to implement most of the
> functionality myself, and demonstrate with their own data.
> But that would take far too long to implement, and would
> likely not work, since the people in charge presumably
> would see flaws in the details and not a sketch of an
> efficient process.
>
> Any suggestions?
>
> Rune

In my experience, management speaks a very limited vocabulary (usually
limited to liberal use of the words "cost", "schedule", "savings",
etc.). From your description, although their process may look horrific
from an engineering standpoint, to them, if it "works," then there's
no perceived benefit to investing the NRE to streamline the process.
You indicate that it would mitigate the use of the crew's time, but is
that something that they would truly appreciate?

Jason

On Mar 24, 6:55&#4294967295;am, Rune Allnor <all...@tele.ntnu.no> wrote:
> Hi folks.
>
> I'm in a bit of a pickle here, as I've been trying to sell a project
> on process organization to somebody who only see day-to-day
> tasks and impending deadlines, not strategic organization or
> company survival.
>
> The process is a 24/7 data processing line, that is working under
> tight deadlines, where specs usually are 24 or 48 hrs from end of
> survey to 99.9% finished product is to be available. The remaining
> 0.1% of finished product is, for all intents and purposes, adding
> company-specific binders with logos and contact phone numbers
> in the right places.
>
> Today, this production process disorganized, in the sense that
> there easily are 5-10 different software packages involved, each with
> very little responsibility. For instance, items like navigation,
> survey,
> processing, reporting are subtasks of the project, and are handled
> by different software packages. It is not unusual to to have one or
> two additional software packages in some of these subtasks, to
> re-format data or to cater for client's perticular requirements.
>
> This process is very manual, in the sense that people are 'driving'
> the process by selecting data through menus, invoking all the
> processing tasks, starting and stopping software, etc.
>
> The concept of 'scripts' or 'batch files' are totally foreign to
> the people in charge, as they usually have background as
> operators and technicians, and are not used to think in
> terms of strategies or process organization.
>
> Add to this that 'databases' are not known or understood, and
> thus that all data are stored all over the place, in any format,
> accessible to any operator to do what they want, you have
> pandemonium.
>
> I once did the numbers of counting the number of files generated
> by the process and the number of manual interactions they
> had to go through, and timed the average time needed for
> each manual operation. I found that one must expect at least
> on the order of 12-18 hrs of time wasted on manhandling the
> data, per 24 hrs survey. Which leaves 6 hrs to actually process
> the same data, if the deadlines are to be honored.
>
> The processing line is chaotic and human operators are worn
> down by the pressure and stersses. The fact that lots of this
> takes place at sea, with no way to escape the job, maybe
> bad weather etc, doesn't help.
>
> Now, I have been trying to guide people into organizing the
> data flow differently:
>
> - Set up a database where all the data are to be stored
> - Specify exactly what data formats are used where
> - Have each application program communicate data back
> &#4294967295; and forth to the database, and not to files
> - Use scripts and batch files wherever possible
> - Maybe write an overall data flow control application
> &#4294967295; which runs the applciation programs sequentially on
> &#4294967295; the data
> - Set up automated status and reporting software to
> &#4294967295; let managment see whic data are where in the pipeline
> - Include specialized software to handle bottlenecks
> &#4294967295; in the data processing
>
> These kinds of things would remove all the non-essential
> man-handling (operations not directly associated with
> data processing), saving ridiculous amounts of time
> and pressure on the crew.
>
> The problem is that these pople know me, and know that
> I'm able to handle the _data processing_bottlenecks_ that
> cripple them. While those bottlenecks have to be handled,
> they are at present insignificant compared to the general
> mess. However, the people I talk with just don't see the big
> picture I've tried to paint, about strategic organization of
> the process and all the benefits obtained by reorganization.
>
> I get feedbacks that "yeah, the bottleneck processing
> is interesting but wee don't write in-house processing code.
> Why don't you contact [the vendor of processing SW]?"
>
> So at last my question: How can one communicate
> these big-picture ideas to the potential clients?
>
> I can see only one way, to implement most of the
> functionality myself, and demonstrate with their own data.
> But that would take far too long to implement, and would
> likely not work, since the people in charge presumably
> would see flaws in the details and not a sketch of an
> efficient process.
>
> Any suggestions?
>
> Rune

Hello Rune,

Well, I agree with Tim, that you may be talking to a bunch of rocks.
But figure out what they spend now on the process and offer to do it
for them at 90% of that cost saving them 10%. Then go hire some
contractors to use your streamlined process and pocket the profit.
Your boss may be happy to not have that headache.

Clay

On 24 Mar, 15:00, cincy...@gmail.com wrote:

> In my experience, management speaks a very limited vocabulary (usually
> limited to liberal use of the words "cost", "schedule", "savings",
> etc.). From your description, although their process may look horrific
> from an engineering standpoint, to them, if it "works," then there's
> no perceived benefit to investing the NRE to streamline the process.
> You indicate that it would mitigate the use of the crew's time, but is
> that something that they would truly appreciate?

Well, one offshore 100% personnel slot binds up 4 people:
one on-board day- and night-watch, one replacement for
each on on-shore free watch. Multiply that by your local
personnel cost times two or thre, to cover overhead for
administration, around-the-world travels, ship/shore
logistics, onboard food and and lodging etc.

Vessel operations costs are influenced by accomodated crew
and staff; vessels presently being decommisioned were
designed for 70 personnel onboard; new vessels are classed
for 100-120 personnel onboard. And believe me, when
crew exceeds 80% of full capacity, life onboard the vessel
becomes cramped.

Then there are the deliveries. Except for 20-30 hrs
priority surveys (usually following some sort of accident)
I have never seen the deadlines actually be honored.
My worst case was when we should do the finishing survey
of some 700 km of pipes. The actual survey took something
like 12 hrs per 10 km, but we were never even close to
process in that speed.

Of course, under the financial crisis cists must come
down and the company which actually can deliver according
to spec and on time, will be the one that survives.

Oh well.

Rune

On 24 Mar, 15:07, c...@claysturner.com wrote:

> Well, I agree with Tim, that you may be talking to a bunch of rocks.
> But figure out what they spend now on the process and offer to do it
> for them at 90% of that cost saving them 10%. Then go hire some
> contractors to use your streamlined process and pocket the profit.
> Your boss may be happy to not have that headache.

The idea has occured to me. But the main problem
remains: I need a fully functional system up and
running to do that. I'm not out to revolusionalize
the industry, just to make a living. Helping the
people to use the tools they alrady have to meet
their obligations ought to be more than sufficent
to do that.

Rune

On 24 Mar, 14:09, Tim Wescott <t...@seemywebsite.com> wrote:

> Fourth (this is a corollary to the second point), should you be talking
> to the guy's boss instead of the guy? &#4294967295;Or the boss's boss?

I've tried to work my way up the chain. The guy who
has operational responsibility sees many of my points,
but doesn't have the power to act on my suggestions.
People further up the chain, who have that power, don't
have the operational experience needed to see the
seemingly trivial details clog up the works.

> Can you get
> access to the right person, and can you do it without fatally pissing off
> the folks you work with?

Right, I suppose I'll have to put my comp.dsp persona
on hold for a while... thanks for the reminder.

Rune

On Tue, 24 Mar 2009 07:40:26 -0700, Rune Allnor wrote:

> On 24 Mar, 14:09, Tim Wescott <t...@seemywebsite.com> wrote:
> 
>> Fourth (this is a corollary to the second point), should you be talking
>> to the guy's boss instead of the guy? &nbsp;Or the boss's boss?
> 
> I've tried to work my way up the chain. The guy who has operational
> responsibility sees many of my points, but doesn't have the power to act
> on my suggestions. People further up the chain, who have that power,
> don't have the operational experience needed to see the seemingly
> trivial details clog up the works.

This was why I suggested instruction by analogy, and a pretty chart.  You 
can talk to someone all day saying essentially "I'm an expert in my 
field, this is in my field, and it's messed up".  But if they don't see 
it, they won't believe it.  On the other hand, putting a picture in their 
head from _their_ field, i.e. "you're waiting on a broken drawbridge", 
will make them say "Oog!  Broken drawbridge bad!  Broken process like 
broken drawbridge?!?  Broken process bad!  Oog!"

Then follow it up with a nice colorized pie chart.  Upper management 
can't resist a pie chart.

>> Can you get
>> access to the right person, and can you do it without fatally pissing
>> off the folks you work with?
> 
> Right, I suppose I'll have to put my comp.dsp persona on hold for a
> while... thanks for the reminder.
> 
> Rune





-- 
http://www.wescottdesign.com

On Mar 24, 10:07�am, c...@claysturner.com wrote:
>
> Hello Rune,
>
> Well, I agree with Tim, that you may be talking to a bunch of rocks.
> But figure out what they spend now on the process and offer to do it
> for them at 90% of that cost saving them 10%. Then go hire some
> contractors to use your streamlined process and pocket the profit.
> Your boss may be happy to not have that headache.
>
> Clay

Further, I think it is also good to think of how committed you are to
this
effort.  Are you looking for short-term gains or long-term goals?
Often,
the two objectives conflict.

Sometimes it takes a lot of "education" in terms of showing examples,
demonstrations, persuasion, etc.  And the horizons can be widely
varying.

Sounds like you have an interesting problem that you have thought
deeply about, and it would be a pity if your suggestions are not
given their deserving consideration.

Julius

Rune Allnor wrote:
> Hi folks.

Hi. I've read the comments you've gotten. Most are worth thinking about. 
I have a piece of non-specific advice that might be worth something too.

Whatever you propose, have a sensible plan for introducing it. 
Developing and perfecting the new procedures, then saying, "OK. Tomorrow 
we switch over" is a nearly sure route to disaster. The new and old ways 
need to run in parallel until management and crew are convinced that the 
quirks are all dealt with and the operators know how to proceed.

With the tight schedules you describe, that may require two teams 
working in parallel during the changeover shakedown. If that's out of 
the question, you may get by with dummy runs of old data on the new 
software, keeping careful track of the time spent to work through the 
analysis. If there are separate teams using the old and new methods, it 
is important that both be motivated to see the new method succeed.

Good luck.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������