Составление документа as-is, помогите...

[ALEG]

Еще можно посмотреть Consultant Toolkit. Там есть руководство по составлению.
Мне кажется, резульата это Gap/Fit Analysis. И это за что непосредственно платит клиент. Проведение полного анализа AS IS оправдано при крупных внедрениях, на небольших, наверное, нужен баланс.
------------------------------
примеры
-----------------------------
Gap\fit
Contents

Purpose
Description

--------------------------------------------------------------------------------

Purpose
To document the gaps between the required functionality and the standard systems capability.

To document the gaps between the current business processes and new , optimized, ones.


--------------------------------------------------------------------------------
Description

This activity is the same when performed as part of the Pre-analysis as when performed in the Analysis. Therefore the following description will refer to "business processes" as either the "business critical processes", i.e. the processes analyzed in the Pre-analysis, or the "business processes" covering all business processes being analyzed.

The Gap/Fit analysis can be carried out once the current business processes (business critical processes in the Pre-analysis) have been described and reviewed by customer key staff.

The Product Consultant and customer key staff walk through the use cases describing the business processes. During this walk through, they investigate how the standard application can support the use cases. This is best done by actually trying to perform the activity in the system. For every activity in each use case the workshop participants must decide to what extent the standard package fulfills the business needs, that the company poses to the activity, and which are described in the business critical process use cases. Every discrepancy between the business support needed and the functionality offered must be identified as a “gap”. Every gap must be described in the Gap-fit worksheet accordingly.

While walking through the standard application, the revised, and now optimized, business processes must be documented in terms of use cases and activity diagrams.

Remember to make notes of any specific requirements for setting parameters in the system, in case this is necessary in order to achieve adequate support for business processes.

For every activity walked through, discuss and agree with the customer, what reports, if any, must be input to, or output from, the activity. This is a simple yet effective way of maximizing the probability that the project team remembers to include all relevant reports needed.

For each gap identified, a decision has to be taken by the client:

Change the corresponding activity to accommodate it to the standard system.
Make a customization to the standard application to accommodate the activity.

[PartnerLogo]














Modeling Tool Guideline

Activity Diagrams



Prepared by: [Partner]
[Customer]
[Project]
[Date]
Purpose:
• To describe using UML the client’s current business processes in scope.


Pre-Conditions:
Modeling tool has been initialised.
Use cases in scope have been identified.


Post-Conditions:
• Use cases in scope have been described using UML notation in the Modeling tool.
• For each use case an activity diagram has been created.
• Each activity in the use cases has been described to the level of detail required for the project.


Description:
A use case is a sequence of actions performed by one or more actors. It is a relatively large-scale process that typically will include many activities, for example direct sales, wholesales operations, production of parts and purchases of raw materials.

When documenting use cases reflecting current business behaviour it is important to describe processes as they really occur. The reason for documenting current business processes is that it gives the project team an opportunity to identify ineffective conduct and to improve business processes. However, if current processes are documented untruthfully or inaccurately, ineffective activities might avoid discovery or the benefit of business process improvement (BPI) might be diluted.

If, during the process of documenting the way things are currently being done, workshop participants come up with good ideas for improving business processes, these ideas can be recorded as Notes directly in the Business Model.