Составление документа 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 диаграмм, каждый понимает так, как ему захочется...

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

[kosenkov]

Цитата:

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

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

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

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

[Nic]

Цитата:

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

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

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

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

[kosenkov]

Цитата:

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

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

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

[2A]

Цитата:

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

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

Был такой один заказчик делали для него as-is ...
Все работает там хорошо ... просто внедрение было на 2 месяца длиннее

P.S. Там еще есть одна стадия бизнес-моделирования, между as-is и to-be

[Zabr]

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

[Serge Kotov]

Цитата:

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

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

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

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

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

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

[kosenkov]

Цитата:

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

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

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

[Nic]

Цитата:

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

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

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

[Serge Kotov]

Цитата:

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

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

Несколько лет назад у меня была подобная ситуация. А еще ранее я предварительно заготовил несколько вариантов графического представления. Это были различные примеры, причем из разных отраслей. Просто схемы с квадратиками, IDEF, алгоритмическое представление и пр. Бизнес - руководителю более понравилось представление, которое имеется в шаблоне MS Visio под наименованием cross-functional flowchart (вертикальная ориентация) из раздела бизнес - процессов. Кстати эта форма мне тоже нравится.

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

ИМХО Гораздо хуже заявить примерно следующее: "Мы крутая компания с собственной милион раз проверенной методологией СуперЗаводчик, рекомендуемой Ассоциацией собаководов России. Этот процесс у нас всегда делается вот так и именно в такой форме."
Реально крутые парни при выражении своих мыслей должны владеть многими инструментами, а не одним зазубренным.

[Nic]

Цитата:

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

... Мы крутая компания ... рекомендуемой Ассоциацией собаководов России.

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

[Nic]

Цитата:

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

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

[Recoilme]

Цитата:

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

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

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

Цитата:

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

[Spider]

Цитата:

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

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

Из статьи и предыдущего опыта можно вынести то, что руководство упорно считает, что методики описания БП -- инструмент очкарика-программиста, а не управленца. Если клиент придерживается такой точки зрения и не удается убедить в обратном (хотя бы отчасти), то никто не будет вникать в методику и обследование, в лучшем случае, превращается в "соглашательство" с консультантом.