18.04.2013 Views

B2B Integration : A Practical Guide to Collaborative E-commerce

B2B Integration : A Practical Guide to Collaborative E-commerce

B2B Integration : A Practical Guide to Collaborative E-commerce

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

138 <strong>B2B</strong> <strong>Integration</strong> — A <strong>Practical</strong> <strong>Guide</strong> <strong>to</strong> <strong>Collaborative</strong> E-<strong>commerce</strong><br />

levels of risk involved in terms of things going wrong and different<br />

levels of impact on maintaining the system's integrity.<br />

Using a logical approach process execution engine executes business<br />

process models without the need <strong>to</strong> change states at either the source<br />

or the target applications. This approach is recommended when no<br />

risk of making any real changes <strong>to</strong> the organization systems is <strong>to</strong> be<br />

taken. However, it does not inform about the problems ahead in real<br />

implementation.<br />

A physical read-only approach allows the process execution engine<br />

<strong>to</strong> only read information from the source systems. This approach allows<br />

the analyst <strong>to</strong> read and move information, but avoids updating the target<br />

systems. The read-only approach is second in terms of risk and has low<br />

risk in terms of the system's integrity. The model allows lesser power in<br />

terms of applicability, but has better value than the logical approach.<br />

The reading and processing of information has limited use if the target<br />

systems remain unaffected. The approach could be a compromise if the<br />

trading partners have differing attitudes <strong>to</strong> risk-taking.<br />

A physical read-write approach provides process execution engine<br />

with complete access <strong>to</strong> try the model on the source and target systems,<br />

which is the aim of full integration. As one would expect, this approach<br />

comes with the highest risk of the three approaches. Detachment of test<br />

systems from the organization's key systems could reduce the risk. The<br />

reason for minimizing the risk is the fact that any bug in the process<br />

model would result in an unstable state in the target or the source<br />

system which might not be acceptable <strong>to</strong> most organizations.<br />

Analyze<br />

For any process <strong>to</strong> work, it has <strong>to</strong> be supported with statistical analysis<br />

and data from organizations and moni<strong>to</strong>red for improvement. Regular<br />

moni<strong>to</strong>ring, recording and reporting of business operations will provide<br />

a wealth of information for analysis, interpretation and improvement of<br />

business processes.<br />

The analysis part of processes is extremely important, as that is<br />

where an organization learns from its inefficiencies and mistakes. There<br />

is a feedback involved in this phase from all interested parties, in order<br />

<strong>to</strong> design a meaningful process.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!