|
22.11.2005, 11:30 | #1 |
Участник
|
Добрый день, не подскажете, кто на практике сталкивался с аудитом проекта? Майкрософт рекомендует только одну компанию (DNV), хотя сделать готовы многие...
Интересует именно практический опыт проведения аудита, какие были результаты, и во что примерно вылилось это удовольствие... |
|
23.11.2005, 14:42 | #2 |
Участник
|
Цитата:
Сообщение от inetd
Добрый день, не подскажете, кто на практике сталкивался с аудитом проекта? Майкрософт рекомендует только одну компанию (DNV), хотя сделать готовы многие...
Интересует именно практический опыт проведения аудита, какие были результаты, и во что примерно вылилось это удовольствие... Вы-то какие цели ставите (кроме получения удовольствия :-)? Зачем вам аудит проекта? Ответ на какой вопрос вы хотите получить? |
|
23.11.2005, 15:04 | #3 |
Участник
|
Оценить качество документации, выявить риски, по ссылке в принципе все описано. Практическая цель - независимость от проекта от конкретного партнера...
|
|
23.11.2005, 15:13 | #4 |
Шаман форума
|
Аудит даст ответ о соответствии проекта предписанным процедурам. Ни работоспособной системы, ни независимости от партнера аудит вам не даст.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
23.11.2005, 18:31 | #5 |
Участник
|
Цитата:
Сообщение от komar
Аудит даст ответ о соответствии проекта предписанным процедурам. Ни работоспособной системы, ни независимости от партнера аудит вам не даст.
|
|
25.11.2005, 17:44 | #6 |
Участник
|
Цитата:
Сообщение от inetd
Мои представления - если проект соответствует методологии (общей), если документация соответствующего качества, то продолжить его другому партнеру вполне реально.
Если так, то думаю, что DNV вам не поможет, а поможет опытный консультант :-) |
|
25.11.2005, 18:01 | #7 |
Moderator
|
Цитата:
Сообщение от inetd
Цитата:
Сообщение от komar
Аудит даст ответ о соответствии проекта предписанным процедурам. Ни работоспособной системы, ни независимости от партнера аудит вам не даст.
Учтите, что стоимость проекта складывается из 2 частей: стоимости лицензий и стоимости внедрения. Соответственно 1-й внедренец получает и то и другое, а второй только ... что? Только совсем небольшую сумму от стоимости проекта. Соответственно, 2-й внедренец может запускать только очень ограниченный функционал. Если 1-й внедренец проект завалил, он всеравно получил деньги за лицензию. Когда приходит 2-й "поднимать проект", он должен разгрести траблы 1-го, переосмыслить проблемы и заначать почти все заново, а это дорогая работа. Таким образом, на мой взгляд, не стоит даже заморачиваться на переходе к другому партнеру. И выходит, что задача аудита - определить соответствие между доработками стандартной системы и изменениями бизнес-процессов компании. |
|
25.11.2005, 18:18 | #8 |
Участник
|
Dzemon, до внедрения еще надо дойти - сделать обследование, написать методологию, выбрать решение, да и "деньги за лицензию" получает вовсе не внедренец, как вам кажется. Внедренцы вообще готовы продавать лицензии без прибыли, чтоб записать их себе в партнерский актив...
Задачу аудита вы все-таки неверно себе представляете. |
|
30.11.2005, 11:49 | #9 |
Участник
|
Правильно ли я вас понимаю, что ваш проект еще не начался и вы предполагаете вести его так, чтобы еще не завершенный проект можно было "если что" передать другому партнеру с минимальными потерями времени?
|
|
30.11.2005, 18:19 | #10 |
Шаман форума
|
Цитата:
Сообщение от inetd
Dzemon, до внедрения еще надо дойти - сделать обследование, написать методологию, выбрать решение, да и "деньги за лицензию" получает вовсе не внедренец, как вам кажется. Внедренцы вообще готовы продавать лицензии без прибыли, чтоб записать их себе в партнерский актив...
Задачу аудита вы все-таки неверно себе представляете. Что касается аргументов насчет независимости - пожалуйста: --если вы хотите, чтобы систему довнедрял или поддерживал другой партнер, то необходима документация в первую очередь на системные разработки, а как раз документирование модификаций стандартной методологией поддерживается не очень хорошо (как правило, партнеры или используют свои стандарты или вообще ничего не документируют). Наличие или отсутствие задницеприкрывательных документов, составляющих 90% любой методологии, Вас, как клиента вряд ли заинтересует. В общем случае - все зависит от причины, по которой вы хотите сменить внедренца.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
30.11.2005, 19:03 | #11 |
Участник
|
Цитата:
Не мог бы ты конкретизировать, какие именно документы ты имеешь в виду под этими 90% не нужных клиенту документов, или, если тебе так будет проще, под оставшимися 10%? |
|
01.12.2005, 13:01 | #12 |
Участник
|
Цитата:
Сообщение от komar
Если кто-то начнет продавать лицензии без прибыли, то Майкрософт может сделаться сильно несчастным, так как это означает снижение установленной для всех цены. На практике как раз доходами от лицензий партнеры покрывают убытки от неудачных внедрений.
Что касается аргументов насчет независимости - пожалуйста: --если вы хотите, чтобы систему довнедрял или поддерживал другой партнер, то необходима документация в первую очередь на системные разработки, а как раз документирование модификаций стандартной методологией поддерживается не очень хорошо (как правило, партнеры или используют свои стандарты или вообще ничего не документируют). Наличие или отсутствие задницеприкрывательных документов, составляющих 90% любой методологии, Вас, как клиента вряд ли заинтересует. В общем случае - все зависит от причины, по которой вы хотите сменить внедренца. -Еще раз - я говорю о проекте который находится непосредственно ПЕРЕД внедрением, при этом создана вся документация по методической части. Осталось только оценить качество этой документации, выбрать решение и понять кому отдать собственно внедрение. |
|
03.12.2005, 12:41 | #13 |
Участник
|
Цитата:
Если у вас предполагается большой, длительный проект, и следование определенной методике становится довольно важным, то можно посоветовать вам как заказчику назначить менеджера проекта, обязав его лично изучить методику, рекомендованную производителем ПО, чтобы вы имели возможность: 1. при выборе внедренца, сравнить предлагаемые методики; 2. при выборе внедренца, оценить степень его понимания предлагаемой им методики; 3. в ходе проекта, контролировать следование методике; 4. в ходе проекта, оптимизировать методику под специфику проекта. Я думаю, что внешний аудитор вам мало поможет в решении этих задач, по той причине, что задачи 3 и 4 носят сквозной, а не разовый характер. |
|
01.12.2005, 12:02 | #14 |
Шаман форума
|
Не не нужных клиенту, а не нужных в случае передачи проекта. Здесь есть некоторая разница.
Под оставшимися 10% я понимаю описание процедур, заложенных в систему (Дизайн или подобный документ). При этом при передаче проекта они так же могут осказаться бесполезными (ведь предыдущий внедренец не смог из этого выжать готовую систему, значит что-то в них не так). Остальные создаваемые в процессе проекта документы имеют своей целью ограничение рамок проекта и разделение ответственности за проект между внедренцем и клиентом (что, на мой взгляд вполне правильно, но при передаче проекта абсолютно бесполезно, так как клиент фактически уже завершил проект в предыдущим подрядчиком). Что же касается собственно методологии внедрения... В общем случае, внедрение по методологии очень похоже на езду по правилам дорожного движения. Если не соблюдать правила, то доехать можно быстрее, но и в аварию можно попасть с большей вероятностью. С другой стороны, в аварию всегда можно попасть, но при последующий разбирательствах встанет вопрос "кто виноват" - одно из назначений методологии внедрения и есть страховка от лишней ответственности. Или я не прав?
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
03.12.2005, 12:21 | #15 |
Участник
|
Цитата:
Сообщение от komar
Под оставшимися 10% я понимаю описание процедур, заложенных в систему (Дизайн или подобный документ). При этом при передаче проекта они так же могут осказаться бесполезными (ведь предыдущий внедренец не смог из этого выжать готовую систему, значит что-то в них не так). Остальные создаваемые в процессе проекта документы имеют своей целью ограничение рамок проекта и разделение ответственности за проект между внедренцем и клиентом (что, на мой взгляд вполне правильно, но при передаче проекта абсолютно бесполезно, так как клиент фактически уже завершил проект в предыдущим подрядчиком).
1. Исходную ситуацию заказчика; 2. Цель, для достижения которой был затеян проект (проблемы, которые предполагалось решить); 3. Что предполагалось сделать для достижения этой цели (задачи); 4. Какими ресурсами предполагалось это сделать. Эту информацию следующему подрядчику невозможно получить иначе как из проктной документации, тогда как более-менее достоверную информацию о том, что было сделано фактически, можно получить обычно как непосредственно из Аксапты, так и от заказчика. Если этой информации нет, то при продолжении неудачного проекта, следующий подрядчик, скорее всего, не сможет воспользоваться опытом предыдущего, будет быстрее (и дешевле) сразу начать все с чистого листа. Цитата:
Сообщение от komar
Что же касается собственно методологии внедрения...
В общем случае, внедрение по методологии очень похоже на езду по правилам дорожного движения. Если не соблюдать правила, то доехать можно быстрее, но и в аварию можно попасть с большей вероятностью. С другой стороны, в аварию всегда можно попасть, но при последующий разбирательствах встанет вопрос "кто виноват" - одно из назначений методологии внедрения и есть страховка от лишней ответственности. Или я не прав? 1. Внедрение на основании исключительно личного опыта 2. Внедрение на основании явно прописанной, желательно стандартизированной методики Так? |
|
05.12.2005, 18:16 | #16 |
Шаман форума
|
Цитата:
Бывало ли хоть раз выдано отрицательное заключение по итогам аудита проекта? Бывали ли отрицательные заключения в российской практике?
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately. |
|
05.12.2005, 18:26 | #17 |
Участник
|
Цитата:
Да. И пожалуйста... Если ты называешь отрицательным заключением высказывание "весь мир бардак, все бабы...", то может быть таких и не было. Если же "отрицательным заключением" заключение о несоответствии сделанного и обещанного - такое было неоднократно. |
|
06.12.2005, 09:36 | #18 |
Участник
|
Цитата:
Почему-то многие воспринимают аудит как самоцель, и строят свои домыслы на неверных предпосылках. А на самом деле это средство, например, прожать другие ставки или сроки или еще что-нибудь |
|
06.12.2005, 12:33 | #19 |
Участник
|
Цитата:
Вы, вместо того чтобы заставлять нас строить предпосылки, задали бы прямой вопрос - могу ли я решить такую-то задачу с помощью внешнего аудитора... :-) |
|
05.12.2005, 18:05 | #20 |
Гость
|
Имхо, аудит может быть полезен для облегчения работы менеджера проекта, как со стороны заказчика, так и со стороны исполнителя.
Аудит имеет смысл проводить не только конце проекта, а в нескольких контрольных точках: -После анализа -После дизайна -Перед вводом в пром. эксплуатацию Аудит может реально помочь вскрыть халяву со стороны внедренца, отклонения от первоначальных целей и т д. Или показать, что проект очень мутный, документации нет, ничего не понятно, риски - очень большие. Однако, если внедренец оформляет по проекту необходимые документы , стороны придерживается любой нормальной методологии внедрения... пользы от аудита для проекта нет. Польза только в том, что проект получит хорошую независимую оценку, полученный сертификат можно заключить в рамочку, повесить на стену и показывать потенциальным клиентам. Какая цена вопроса - я не знаю. Подозреваю, что процентов 5 от общей суммы проекта. На месте DNV я бы вывесил парочку примеров с описанием конкретной пользы от мероприятия. Причем с российскими конторами. |
|