Single long flowchart vs multiple flowcharts for a multiprocessworkflow

[John]

Hi,

I am drawing a cross-functionality flowchart, to document the process
between 2 disjointed software systems. The first system can initiate
functionality in the second, and the second system ques changes which
need to be retrieved and acted upon with in the first system. Right
now a Windows Service looks like the best way for me to handle this;
the service would listen for events in the second system and initiate
the appropriate actions in the first system.

So, I started drawing a cross-functional flowchart to a) confirm /
nail down the business process with our managers, b) find all the
touch points with their api, and c) communicate this to the second
system’s developers, who insist we don’t need a piece of functionality
(maybe their right, hopefully this will communicate the flaws in one
of our processes).

The question comes up once the Windows Service ‘listener’ app got
involved, it seemed logical to break each listener process into a
separate diagram. However, I feel that passing the business users a
stack of 10 diagrams instead of one might confuse them.

Has anybody thought about this before? Is there a general rule for
doing this? Am I over thinking this?

Thanks in advance for your comments.

Regards,
John

 

[Paul Herber]

Hi,

I am drawing a cross-functionality flowchart, to document the process
between 2 disjointed software systems. The first system can initiate
functionality in the second, and the second system ques changes which
need to be retrieved and acted upon with in the first system. Right
now a Windows Service looks like the best way for me to handle this;
the service would listen for events in the second system and initiate
the appropriate actions in the first system.

So, I started drawing a cross-functional flowchart to a) confirm /
nail down the business process with our managers, b) find all the
touch points with their api, and c) communicate this to the second
system’s developers, who insist we don’t need a piece of functionality
(maybe their right, hopefully this will communicate the flaws in one
of our processes).

The question comes up once the Windows Service ‘listener’ app got
involved, it seemed logical to break each listener process into a
separate diagram. However, I feel that passing the business users a
stack of 10 diagrams instead of one might confuse them.

Has anybody thought about this before? Is there a general rule for
doing this? Am I over thinking this?

This is a common process scenario.
One rule of thumb, don't let the flow exceed one page, that may mean
breaking down your process into smaller blocks, this is usually a good
thing anyway, then each diagram can be subtitled with things like "get
order details", "get customer details", "create invoice", etc etc.

If the processes meet at various points then watch out for deadlocks,
i.e. process A is waiting for input 1 from process B but process B is
waiting for input 2 from process B, but I'm sure your developers know
about such things.

 

[John]

This is a common process scenario.
One rule of thumb, don't let the flow exceed one page, that may mean
breaking down your process into smaller blocks, this is usually a good
thing anyway, then each diagram can be subtitled with things like "get
order details", "get customer details", "create invoice", etc etc.

If the processes meet at various points then watch out for deadlocks,
i.e. process A is waiting for input 1 from process B but process B is
waiting for input 2 from process B, but I'm sure your developers know
about such things.

--
Regards, Paul Herber, Sandrila Ltd.
DFD/SSADM for Visio      http://www.visio-dfd.sandrila.co.uk/- Hidequoted text -

- Show quoted text -

Thanks Paul,

That sounds like a good idea.

BTW-I'm the developer, but I usually don't draw these diagrams. So I
hadn't actually made that connection yet.

Thanks again,
John