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

[Alla_c]

Добрый день.

Пожалуйста, подскажите, поделитесь опытом, как правильно (наваш взгляд) составлять документ as-is. Какие разделы, что стоит расписывать словами и т.д.

Большое спасибо.

ps: если кто-нибудь сможет выслать пример или шаблон, буду очень благодарна)
alla_consult@inbox.ru

[Nic]

Думаю сдесь вы найдете ответы на большинство вопросов.

[kosenkov]

На мой взгляд, правильно документ "AS-IS" в чистом виде не составлять , а совместить его с туби, так, чтобы на выходе этапа было уже то, что можно назвать "требования к системе, как-то классифицированные по бизнес-процессам и т.д".
Если, конечно, проект - это внедрение например Аксапты, а не больше реорганизация бизнеса.

[Nic]

Цитата:

Сообщение от kosenkov

На мой взгляд, правильно документ "AS-IS" в чистом виде не составлять , а совместить его с туби.

А что плохого в том, что бы эти документы разделить? Ведь "TO-BE" пишется на основании данный "AS-IS".

[Alla_c]

Соединять не надо. Просто мне важно знать, как примерно оформлять документ. Ведь набор диаграмм это же не все, есть люди, которые вообще не могут себя адекватно вести при виде тех же IDEF0 диаграмм, каждый понимает так, как ему захочется...

ведь кто-нибудь составлял такой документ, поделитесь) хотя бы структурой, содержанием...

[Serge Kotov]

Цитата:

Сообщение от Alla_c

... Просто мне важно знать, как примерно оформлять документ. Ведь набор диаграмм это же не все, есть люди, которые вообще не могут себя адекватно вести при виде тех же IDEF0 диаграмм, каждый понимает так, как ему захочется...

ведь кто-нибудь составлял такой документ, поделитесь) хотя бы структурой, содержанием...

Оформление может быть различным. Рекомендую поинтересоваться чем пользуется заказчик для подобных вещей или к чему привык и сделать в удобной и понятной ему форме.

Чем проще представление - тем лучше. IDEF хорош, если нужно чтобы заказчик ничего не понял Но это аукнется на последующих стадиях проекта.

Есть одно правило, которое нужно обязательно соблюдать. Представление AS-IS должно содержать графическое представление и текстовую описательную часть. Как Вы точно заметили, графическое представление зачастую можно толковать по разному, удобным для себя способом, а текстовое без графики очень трудно связать в одну ясную картину.

[Nic]

Цитата:

Сообщение от Serge Kotov

Оформление может быть различным. Рекомендую поинтересоваться чем пользуется заказчик для подобных вещей или к чему привык и сделать в удобной и понятной ему форме.

Хм. Как быть в том случае, когда заказчик "ничем" не пользуется?

[Recoilme]

Цитата:

Сообщение от Serge Kotov

Чем проще представление - тем лучше. IDEF хорош, если нужно чтобы заказчик ничего не понял Но это аукнется на последующих стадиях проекта.

+1.
Вот ещё статья на эту тему.

Цитата:

При этом мы последовательно столкнулись с нотациями IDEF и ARIS. Что из этого вышло? Если вкратце, то ничего.

[kosenkov]

Цитата:

Сообщение от Nic

А что плохого в том, что бы эти документы разделить? Ведь "TO-BE" пишется на основании данный "AS-IS".

Все те разы, какие я участвовал в этапе проекта "описание того, что есть" основных итогов этапа было два:
1. Толстый документ, который никто больше не читает (если только проектную команду не меняют полностью).
2. Консультанты начинают понимать, о чем тут вообще и как, и перестают путать Марью Ивановну из бухгалтерии и Марью Ивановну из отдела управленческого учета.

Ценность этих результатов непосредственно для заказчика в общем и целом нулевая. Добавленная стоимость не рождается. Не выносите же вы в отдельный этап организацию проектного офиса - а ведь штука для проекта тоже необходимая.

[Nic]

Цитата:

Сообщение от kosenkov

Все те разы, какие я участвовал в этапе проекта "описание того, что есть" основных итогов этапа было два:
1. Толстый документ, который никто больше не читает (если только проектную команду не меняют полностью).
2. Консультанты начинают понимать, о чем тут вообще и как, и перестают путать Марью Ивановну из бухгалтерии и Марью Ивановну из отдела управленческого учета.

Ценность этих результатов непосредственно для заказчика в общем и целом нулевая. Добавленная стоимость не рождается. Не выносите же вы в отдельный этап организацию проектного офиса - а ведь штука для проекта тоже необходимая.

Хм...
А что собственно плохого в разделении, я так и не понял?
Думаю, что как раз было бы удобнее разделить эти документы, чем иметь один большой толмут.
А то что документ читают или нет, это уже маленько из другой области, так же как и понимание бизнес-процессов консультантами.

[kosenkov]

Цитата:

Сообщение от Nic

Хм...
А что собственно плохого в разделении, я так и не понял?
Думаю, что как раз было бы удобнее разделить эти документы, чем иметь один большой толмут.
А то что документ читают или нет, это уже маленько из другой области, так же как и понимание бизнес-процессов консультантами.

Хорошо, скажу по-другому.
Если бы я был заказчиком, и нанимал консультантов для внедрения Аксапта, я бы низачто не согласился закрывать этап проекта (платить за это деньги, и считать обязательства выполнеными) - если в результате этапа я получаю только документ, в котором мой бизнес описан "как есть глазами консультантов". Это не самодостаточный результат, он как таковой отдельно не нужен.

[Zabr]

Косенкову: иногда проект состоит только из as-is, и по результатам смотрится: автоматизировать ли вообще этот бардак, и если да - то на чем. То есть to-be может быть разный. В сообщениях от Alla_c вообще не говорится, что кто-то что-то собирается внедрять. Может быть, она пишет as-is в качестве подготовки к тендеру.

[kosenkov]

Цитата:

Сообщение от Zabr

Косенкову: иногда проект состоит только из as-is, и по результатам смотрится: автоматизировать ли вообще этот бардак, и если да - то на чем. То есть to-be может быть разный. В сообщениях от Alla_c вообще не говорится, что кто-то что-то собирается внедрять. Может быть, она пишет as-is в качестве подготовки к тендеру.

Да, Вы правы. Делаю оговорку: считаю, что в рамках проекта внедрения ИС этап описания as-is (на выходе - документ с описанием) не является самоценным и неотделим от чего-то большего (выработки требований к системе, принятия неких решений и т.д).

[Alla_c]

ОГРОМНОЕ СПАСИБО!!! только проверила почту) есть же люди хорошие, чмок!

[Nic]

Цитата:

Сообщение от Alla_c

ОГРОМНОЕ СПАСИБО!!! только проверила почту) есть же люди хорошие, чмок!

[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.

[Recoilme]

моё имхо такое:
1. Все завист от целей.
2. Чем проще описание тем лучше.
Лирическое отступление:
Когда 4 года назад внедрял системы выглядело это так :
садились с ком. диром и рисовали на бумажке
1. грузовичок
2. человечка
грузовичок - символизировал склад в системе, человечек мат.отв.лицо
потом МОЛ брал бутылку водки - пил горькую (стрелочка такая) => вместо него другой человечек (МОЛ) садился в грузовичок.
Каой из этого вывод? Есть справочник складов, есть справочник мат.отв.лиц. В справочнике складов должен быть указан МОЛ по умолчанию, но в момент выписки накладной, мол может быть другой, и должна быть возможность его выбора.

Потом я рисовал диаграмы в АРИСе и прочей ерунде - и наблюдал как люди который этот арис в глаза не видели и ещё 100 лет не видели бы на эти диаграммы пялятся и пытаются "втыкнуть"

ЗЫ: Я вернулся к рисованию грузовичков с человечками если мне нужно достичь эффекта, а не подписать документ.
Вот и всё. АРИС,ИДЕФ и т.п. идут лесом вместе с TAG

[Recoilme]

2 Шрэк & Spider
Нет, ну всё таки у Вас правда ключевые пользователи во всей этой мути разбираются??:
Сравнительный анализ нотаций ARIS/IDEF и продуктов их поддерживающих (ARIS Toolset/BPWin).

[Spider]

Цитата:

Сообщение от Recoilme

2 Шрэк & Spider
Нет, ну всё таки у Вас правда ключевые пользователи во всей этой мути разбираются??:

По наглядности для пользователей IDEFы однозначно фтопку, хотя лично мне они нравятся. ARIS проще для понимания, если приложить усилия, то можно получить более или менее наглядные модели... Конечно, надо выбрать более удобное заказчику представление. Но, IMHO, скатываясь до человечков и машинок сомнительно получить нормальные модели as is , тем более to be.

В статье так и сказано, мол мы отказались от IDEF и ARIS в пользу непонятно чего и в результате получили непонятно что.

А вообще, насколько мне известно, управленцам сейчас преподают методологии исследования и проектирования. [пошла философия] По крайней мере должны. Надо уходить от совдеповских методов. До тех пор, пока мы будем человечов да машинок рисовать, тот же АвтоВАЗ, при наличии дешевых рабочей силы, материалов, и энергии будет умудрятся выпускать железяки по стоимости подержанных Porsche.

[Шрэк]

Цитата:

Сообщение от Recoilme

2 Шрэк & Spider
Нет, ну всё таки у Вас правда ключевые пользователи во всей этой мути разбираются??:

Я ничего не утверждал по поводу того, как ключевым пользователям предоставлять информацию. В этом случае я согласен с другими участниками, что это нужно согласовывать с заказчиком и представлять ему в удобоваримой для него форме.
А в этой "мути" я сам разбираюсь и более того от некоторых заказчиков получал диаграммы, выполненные в ARIS. Лично для себя ничего такого сложного во всех диаграммах не вижу, для меня это гораздо понятнее чем словесное описание.