Аудит проектов

[inetd_imported]

Добрый день, не подскажете, кто на практике сталкивался с аудитом проекта? Майкрософт рекомендует только одну компанию (DNV), хотя сделать готовы многие...
Интересует именно практический опыт проведения аудита, какие были результаты, и во что примерно вылилось это удовольствие...

[bobkov_imported]

Цитата:

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

Добрый день, не подскажете, кто на практике сталкивался с аудитом проекта? Майкрософт рекомендует только одну компанию (DNV), хотя сделать готовы многие...
Интересует именно практический опыт проведения аудита, какие были результаты, и во что примерно вылилось это удовольствие...

<{POST_SNAPBACK}>

Результаты обычно соответствуют целям, поставленным заказчиком перед аудитором. :-)
Вы-то какие цели ставите (кроме получения удовольствия :-)? Зачем вам аудит проекта? Ответ на какой вопрос вы хотите получить?

[inetd_imported]

Оценить качество документации, выявить риски, по ссылке в принципе все описано. Практическая цель - независимость от проекта от конкретного партнера...

[komar]

Аудит даст ответ о соответствии проекта предписанным процедурам. Ни работоспособной системы, ни независимости от партнера аудит вам не даст.

[inetd_imported]

Цитата:

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

Аудит даст ответ о соответствии проекта предписанным процедурам. Ни работоспособной системы, ни независимости от партнера аудит вам не даст.

<{POST_SNAPBACK}>

Спасибо, насчет первого я как-то и не сомневался, а вот по поводу второго - можно чуть больше аргументов? Мои представления - если проект соответствует методологии (общей), если документация соответствующего качества, то продолжить его другому партнеру вполне реально.

[bobkov_imported]

Цитата:

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

Мои представления - если проект соответствует методологии (общей), если документация соответствующего качества, то продолжить его другому партнеру вполне реально.

<{POST_SNAPBACK}>

Тогда, видимо, достаточно аудита эксплуатационной документации (руководство пользователя, администратора и т.д.), регламентов работы пользователей (типа, описание документооборота).
Если так, то думаю, что DNV вам не поможет, а поможет опытный консультант :-)

[Dzemon]

Цитата:

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

Цитата:

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

Аудит даст ответ о соответствии проекта предписанным процедурам. Ни работоспособной системы, ни независимости от партнера аудит вам не даст.

<{POST_SNAPBACK}>

Спасибо, насчет первого я как-то и не сомневался, а вот по поводу второго - можно чуть больше аргументов? Мои представления - если проект соответствует методологии (общей), если документация соответствующего качества, то продолжить его другому партнеру вполне реально.

<{POST_SNAPBACK}>

А что значит "продолжить другому партнеру"?
Учтите, что стоимость проекта складывается из 2 частей: стоимости лицензий и стоимости внедрения. Соответственно 1-й внедренец получает и то и другое, а второй только ... что? Только совсем небольшую сумму от стоимости проекта. Соответственно, 2-й внедренец может запускать только очень ограниченный функционал. Если 1-й внедренец проект завалил, он всеравно получил деньги за лицензию. Когда приходит 2-й "поднимать проект", он должен разгрести траблы 1-го, переосмыслить проблемы и заначать почти все заново, а это дорогая работа. Таким образом, на мой взгляд, не стоит даже заморачиваться на переходе к другому партнеру.
И выходит, что задача аудита - определить соответствие между доработками стандартной системы и изменениями бизнес-процессов компании.

[inetd_imported]

Dzemon, до внедрения еще надо дойти - сделать обследование, написать методологию, выбрать решение, да и "деньги за лицензию" получает вовсе не внедренец, как вам кажется. Внедренцы вообще готовы продавать лицензии без прибыли, чтоб записать их себе в партнерский актив...
Задачу аудита вы все-таки неверно себе представляете.

[bobkov_imported]

Цитата:

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

Dzemon, до внедрения еще надо дойти - сделать обследование, написать методологию, выбрать решение...

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

[komar]

Цитата:

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

Dzemon, до внедрения еще надо дойти - сделать обследование, написать методологию, выбрать решение, да и "деньги за лицензию" получает вовсе не внедренец, как вам кажется. Внедренцы вообще готовы продавать лицензии без прибыли, чтоб записать их себе в партнерский актив...
Задачу аудита вы все-таки неверно себе представляете.

Если кто-то начнет продавать лицензии без прибыли, то Майкрософт может сделаться сильно несчастным, так как это означает снижение установленной для всех цены. На практике как раз доходами от лицензий партнеры покрывают убытки от неудачных внедрений.
Что касается аргументов насчет независимости - пожалуйста:
--если вы хотите, чтобы систему довнедрял или поддерживал другой партнер, то необходима документация в первую очередь на системные разработки, а как раз документирование модификаций стандартной методологией поддерживается не очень хорошо (как правило, партнеры или используют свои стандарты или вообще ничего не документируют). Наличие или отсутствие задницеприкрывательных документов, составляющих 90% любой методологии, Вас, как клиента вряд ли заинтересует. В общем случае - все зависит от причины, по которой вы хотите сменить внедренца.

[bobkov_imported]

Цитата:

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

Наличие или отсутствие задницеприкрывательных документов, составляющих 90% любой методологии, Вас, как клиента вряд ли заинтересует. В общем случае - все зависит от причины, по которой вы хотите сменить внедренца.

Дима, привет!
Не мог бы ты конкретизировать, какие именно документы ты имеешь в виду под этими 90% не нужных клиенту документов, или, если тебе так будет проще, под оставшимися 10%?

[komar]

Не не нужных клиенту, а не нужных в случае передачи проекта. Здесь есть некоторая разница.
Под оставшимися 10% я понимаю описание процедур, заложенных в систему (Дизайн или подобный документ). При этом при передаче проекта они так же могут осказаться бесполезными (ведь предыдущий внедренец не смог из этого выжать готовую систему, значит что-то в них не так). Остальные создаваемые в процессе проекта документы имеют своей целью ограничение рамок проекта и разделение ответственности за проект между внедренцем и клиентом (что, на мой взгляд вполне правильно, но при передаче проекта абсолютно бесполезно, так как клиент фактически уже завершил проект в предыдущим подрядчиком).

Что же касается собственно методологии внедрения...
В общем случае, внедрение по методологии очень похоже на езду по правилам дорожного движения. Если не соблюдать правила, то доехать можно быстрее, но и в аварию можно попасть с большей вероятностью. С другой стороны, в аварию всегда можно попасть, но при последующий разбирательствах встанет вопрос "кто виноват" - одно из назначений методологии внедрения и есть страховка от лишней ответственности. Или я не прав?

[inetd_imported]

Цитата:

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

Если кто-то начнет продавать лицензии без прибыли, то Майкрософт может сделаться сильно несчастным, так как это означает снижение установленной для всех цены. На практике как раз доходами от лицензий партнеры покрывают убытки от неудачных внедрений.
Что касается аргументов насчет независимости - пожалуйста:
--если вы хотите, чтобы систему довнедрял или поддерживал другой партнер, то необходима документация в первую очередь на системные разработки, а как раз документирование модификаций стандартной методологией поддерживается не очень хорошо (как правило, партнеры или используют свои стандарты или вообще ничего не документируют). Наличие или отсутствие задницеприкрывательных документов, составляющих 90% любой методологии, Вас, как клиента вряд ли заинтересует. В общем случае - все зависит от причины, по которой вы хотите сменить внедренца.

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

[bobkov_imported]

Цитата:

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

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

Я исхожу из предположения, что проект по внедрению целенаправлен (проблемно ориентирован). Тогда из проектной документации следующий подрядчик должен понять:
1. Исходную ситуацию заказчика;
2. Цель, для достижения которой был затеян проект (проблемы, которые предполагалось решить);
3. Что предполагалось сделать для достижения этой цели (задачи);
4. Какими ресурсами предполагалось это сделать.

Эту информацию следующему подрядчику невозможно получить иначе как из проктной документации, тогда как более-менее достоверную информацию о том, что было сделано фактически, можно получить обычно как непосредственно из Аксапты, так и от заказчика.

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

Цитата:

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

Что же касается собственно методологии внедрения...
В общем случае, внедрение по методологии очень похоже на езду по правилам дорожного движения. Если не соблюдать правила, то доехать можно быстрее, но и в аварию можно попасть с большей вероятностью. С другой стороны, в аварию всегда можно попасть, но при последующий разбирательствах встанет вопрос "кто виноват" - одно из назначений методологии внедрения и есть страховка от лишней ответственности. Или я не прав?

Ты, как я понимаю, рассматриваешь следующую альтернативу:
1. Внедрение на основании исключительно личного опыта
2. Внедрение на основании явно прописанной, желательно стандартизированной методики
Так?

[bobkov_imported]

Цитата:

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

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

Вы хотите принять решение о выборе решения и внедренца на основании "документации по методической части"? Мне кажется, это далеко не самый важный фактор успеха проекта. Я думаю, на фоне остальных факторов, им часто можно даже пренебречь :-)

Если у вас предполагается большой, длительный проект, и следование определенной методике становится довольно важным, то можно посоветовать вам как заказчику назначить менеджера проекта, обязав его лично изучить методику, рекомендованную производителем ПО, чтобы вы имели возможность:
1. при выборе внедренца, сравнить предлагаемые методики;
2. при выборе внедренца, оценить степень его понимания предлагаемой им методики;
3. в ходе проекта, контролировать следование методике;
4. в ходе проекта, оптимизировать методику под специфику проекта.

Я думаю, что внешний аудитор вам мало поможет в решении этих задач, по той причине, что задачи 3 и 4 носят сквозной, а не разовый характер.

Имхо, аудит может быть полезен для облегчения работы менеджера проекта, как со стороны заказчика, так и со стороны исполнителя.

Аудит имеет смысл проводить не только конце проекта, а в нескольких контрольных точках:

-После анализа
-После дизайна
-Перед вводом в пром. эксплуатацию

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

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

Польза только в том, что проект получит хорошую независимую оценку, полученный сертификат можно заключить в рамочку, повесить на стену и показывать потенциальным клиентам.

Какая цена вопроса - я не знаю. Подозреваю, что процентов 5 от общей суммы проекта.
На месте DNV я бы вывесил парочку примеров с описанием конкретной пользы от мероприятия.
Причем с российскими конторами.

[komar]

Цитата:

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

Ты, как я понимаю, рассматриваешь следующую альтернативу:
1. Внедрение на основании исключительно личного опыта
2. Внедрение на основании явно прописанной, желательно стандартизированной методики
Так?

Я не рассматриваю никаких альтернатив. Вопрошающий вопросил, будет ли толк от аудита проектов. Я и высказал мнение - толку не будет.
Бывало ли хоть раз выдано отрицательное заключение по итогам аудита проекта?

Цитата:

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

Какая цена вопроса - я не знаю. Подозреваю, что процентов 5 от общей суммы проекта.
На месте DNV я бы вывесил парочку примеров с описанием конкретной пользы от мероприятия.
Причем с российскими конторами.

Бывали ли отрицательные заключения в российской практике?

[mazzy]

Цитата:

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

Бывало ли хоть раз выдано отрицательное заключение по итогам аудита проекта?

Да.

Цитата:

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

Бывали ли отрицательные заключения в российской практике?

Да.

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

[inetd_imported]

Цитата:

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

Я не рассматриваю никаких альтернатив. Вопрошающий вопросил, будет ли толк от аудита проектов. Я и высказал мнение - толку не будет.

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

[bobkov_imported]

Цитата:

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

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

Например, уволить координатора проекта со стороны Заказчика? :-)
Вы, вместо того чтобы заставлять нас строить предпосылки, задали бы прямой вопрос - могу ли я решить такую-то задачу с помощью внешнего аудитора... :-)